From c1033ec7f51c091c14640cc80738443cb6b5a2f4 Mon Sep 17 00:00:00 2001 From: Thanh Ha Date: Mon, 10 Sep 2018 11:01:37 -0400 Subject: [PATCH] Add intersphinx for SXP and remove them from docs SXP is now available at https://docs.opendaylight.org/projects/sxp so remove them from local docs, we can link to them instead. Issue: DOCS-69 Change-Id: I3e6f4120aad19fd2d5e8ac1dba333467f930243c Signed-off-by: Thanh Ha Signed-off-by: Ivan Hrasko --- docs/conf.py | 1 + docs/developer-guide/index.rst | 1 - docs/developer-guide/sxp-developer-guide.rst | 117 ----- docs/index.rst | 3 +- docs/project-indexes/sxp-index.rst | 19 - docs/user-guide/index.rst | 1 - docs/user-guide/sxp-user-guide.rst | 447 ------------------- 7 files changed, 2 insertions(+), 587 deletions(-) delete mode 100644 docs/developer-guide/sxp-developer-guide.rst delete mode 100644 docs/project-indexes/sxp-index.rst delete mode 100644 docs/user-guide/sxp-user-guide.rst diff --git a/docs/conf.py b/docs/conf.py index f79d761f6..82840e9ac 100755 --- a/docs/conf.py +++ b/docs/conf.py @@ -27,6 +27,7 @@ intersphinx_mapping['netvirt'] = ('https://docs.opendaylight.org/projects/netvir intersphinx_mapping['openflowplugin'] = ('https://docs.opendaylight.org/projects/openflowplugin/en/stable-fluorine/', None) intersphinx_mapping['ovsdb'] = ('https://docs.opendaylight.org/projects/ovsdb/en/stable-fluorine/', None) intersphinx_mapping['tsdr'] = ('https://docs.opendaylight.org/projects/tsdr/en/stable-fluorine/', None) +intersphinx_mapping['sxp'] = ('https://docs.opendaylight.org/projects/sxp/en/stable-fluorine/', None) # OpenDaylight Documentation Releases intersphinx_mapping['odl-fluorine'] = ('https://docs.opendaylight.org/en/stable-fluorine/', None) diff --git a/docs/developer-guide/index.rst b/docs/developer-guide/index.rst index 2ea7c48f0..e46562913 100644 --- a/docs/developer-guide/index.rst +++ b/docs/developer-guide/index.rst @@ -64,7 +64,6 @@ Project-specific Developer Guides p4plugin-developer-guide service-function-chaining snmp4sdn-developer-guide - sxp-developer-guide topology-processing-framework-developer-guide transportpce-developer-guide ttp-model-developer-guide diff --git a/docs/developer-guide/sxp-developer-guide.rst b/docs/developer-guide/sxp-developer-guide.rst deleted file mode 100644 index f87e81469..000000000 --- a/docs/developer-guide/sxp-developer-guide.rst +++ /dev/null @@ -1,117 +0,0 @@ -.. _sxp-dev-guide: - -SXP Developer Guide -=================== - -Overview --------- - -SXP (Scalable-Group Tag eXchange Protocol) project is an effort to enhance -OpenDaylight platform with IP-SGT (IP Address to Source Group Tag) -bindings that can be learned from connected SXP-aware network nodes. The -current implementation supports SXP protocol version 4 according to the -Smith, Kandula - SXP `IETF -draft `__ and -grouping of peers and creating filters based on ACL/Prefix-list syntax -for filtering outbound and inbound IP-SGT bindings. All protocol legacy -versions 1-3 are supported as well. Additionally, version 4 adds -bidirectional connection type as an extension of a unidirectional one. - -SXP Architecture ----------------- - -The SXP Server manages all connected clients in separate threads and a -common SXP protocol agreement is used between connected peers. Each SXP -network peer is modelled with its pertaining class, e.g., SXP Server -represents the SXP Speaker, SXP Listener the Client. The server program -creates the ServerSocket object on a specified port and waits until a -client starts up and requests connect on the IP address and port of the -server. The client program opens a Socket that is connected to the -server running on the specified host IP address and port. - -The SXP Listener maintains connection with its speaker peer. From an -opened channel pipeline, all incoming SXP messages are processed by -various handlers. Message must be decoded, parsed and validated. - -The SXP Speaker is a counterpart to the SXP Listener. It maintains a -connection with its listener peer and sends composed messages. - -The SXP Binding Handler extracts the IP-SGT binding from a message and -pulls it into the SXP-Database. If an error is detected during the -IP-SGT extraction, an appropriate error code and sub-code is selected -and an error message is sent back to the connected peer. All transitive -messages are routed directly to the output queue of SXP Binding -Dispatcher. - -The SXP Binding Dispatcher represents a selector that will decides how -many data from the SXP-database will be sent and when. It is responsible -for message content composition based on maximum message length. - -The SXP Binding Filters handles filtering of outgoing and incoming -IP-SGT bindings according to BGP filtering using ACL and Prefix List -syntax for specifying filter or based on Peer-sequence length. - -The SXP Domains feature provides isolation of SXP peers and bindings -learned between them, also exchange of Bindings is possible across -SXP-Domains by ACL, Prefix List or Peer-Sequence filters - -Key APIs and Interfaces ------------------------ - -As this project is fairly small, it provides only few features that -install and provide all APIs and implementations for this project. - -- sxp-api - -- spx-core - -- sxp-controller - -- sxp-cluster-route - -- sxp-karaf - -- sxp-robot - -- sxp-system-tests - -sxp-api -~~~~~~~ - -Contains data holders and entities - -spx-core -~~~~~~~~ - -Main logic and core features - -sxp-controller -~~~~~~~~~~~~~~ - -RPC request handling - -sxp-cluster-route -~~~~~~~~~~~~~~~~~ - -Performs managing of SXP devices in cluster environment - -sxp-karaf -~~~~~~~~~ - -Defines Karaf4 dependencies - -sxp-robot -~~~~~~~~~ - -Contains JRobot libraries used in `CSIT Robot tests `__ - -sxp-system-tests -~~~~~~~~~~~~~~~~ - -Contains REST client used for testing purposes - -API Reference Documentation ---------------------------- - -* `RESTCONF Interface and Dynamic Tree `__ -* `Specification and Architecture `__ diff --git a/docs/index.rst b/docs/index.rst index 3398a6891..dc9cd0cb5 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -47,7 +47,7 @@ Managed Projects Self-Managed Projects ~~~~~~~~~~~~~~~~~~~~~ -* :doc:`SXP Documentation ` +* :doc:`SXP Documentation ` * :doc:`TransportPCE Documentation ` * :doc:`TSDR Documentation ` @@ -89,7 +89,6 @@ OpenDaylight Contributor Guides project-indexes/bgpcep-index project-indexes/daexim-index project-indexes/lispflowmapping-index - project-indexes/sxp-index project-indexes/transportpce-index project-indexes/controller-index project-indexes/sfc-index diff --git a/docs/project-indexes/sxp-index.rst b/docs/project-indexes/sxp-index.rst deleted file mode 100644 index a1dc8dab7..000000000 --- a/docs/project-indexes/sxp-index.rst +++ /dev/null @@ -1,19 +0,0 @@ -SXP Project Documentation -========================= -This page provides pointers to the existing documentation for the SXP project. - -Developer Guides ----------------- - -.. toctree:: - :maxdepth: 1 - - ../developer-guide/sxp-developer-guide - -User Guides ------------ - -.. toctree:: - :maxdepth: 1 - - ../user-guide/sxp-user-guide diff --git a/docs/user-guide/index.rst b/docs/user-guide/index.rst index c27a0ab27..ca6167190 100644 --- a/docs/user-guide/index.rst +++ b/docs/user-guide/index.rst @@ -57,7 +57,6 @@ Project-specific User Guides service-function-chaining snmp-plugin-user-guide snmp4sdn-user-guide - sxp-user-guide transportpce-user-guide ttp-cli-tools-user-guide uni-manager-plug-in-project diff --git a/docs/user-guide/sxp-user-guide.rst b/docs/user-guide/sxp-user-guide.rst deleted file mode 100644 index 43ec3427c..000000000 --- a/docs/user-guide/sxp-user-guide.rst +++ /dev/null @@ -1,447 +0,0 @@ -.. _sxp-user-guide: - -SXP User Guide -============== - -Overview --------- - -SXP (Scalable-Group Tag eXchange Protocol) project is an effort to enhance -OpenDaylight platform with IP-SGT (IP Address to Source Group Tag) -bindings that can be learned from connected SXP-aware network nodes. The -current implementation supports SXP protocol version 4 according to the -Smith, Kandula - SXP `IETF -draft `__ and -grouping of peers and creating filters based on ACL/Prefix-list syntax -for filtering outbound and inbound IP-SGT bindings. All protocol legacy -versions 1-3 are supported as well. Additionally, version 4 adds -bidirectional connection type as an extension of a unidirectional one. - -SXP Architecture ----------------- - -The SXP Server manages all connected clients in separate threads and a -common SXP protocol agreement is used between connected peers. Each SXP -network peer is modelled with its pertaining class, e.g., SXP Server -represents the SXP Speaker, SXP Listener the Client. The server program -creates the ServerSocket object on a specified port and waits until a -client starts up and requests connect on the IP address and port of the -server. The client program opens a Socket that is connected to the -server running on the specified host IP address and port. - -The SXP Listener maintains connection with its speaker peer. From an -opened channel pipeline, all incoming SXP messages are processed by -various handlers. Message must be decoded, parsed and validated. - -The SXP Speaker is a counterpart to the SXP Listener. It maintains a -connection with its listener peer and sends composed messages. - -The SXP Binding Handler extracts the IP-SGT binding from a message and -pulls it into the SXP-Database. If an error is detected during the -IP-SGT extraction, an appropriate error code and sub-code is selected -and an error message is sent back to the connected peer. All transitive -messages are routed directly to the output queue of SXP Binding -Dispatcher. - -The SXP Binding Dispatcher represents a selector that will decides how -many data from the SXP-database will be sent and when. It is responsible -for message content composition based on maximum message length. - -The SXP Binding Filters handles filtering of outgoing and incoming -IP-SGT bindings according to BGP filtering using ACL and Prefix List -syntax for specifying filter or based on Peer-sequence length. - -The SXP Domains feature provides isolation of SXP peers and bindings -learned between them, also exchange of Bindings is possible across -SXP-Domains by ACL, Prefix List or Peer-Sequence filters - -Configuring SXP ---------------- - -SXP requires no manual configuration. - -Administering or Managing SXP ------------------------------ - -By RPC (response is XML document containing requested data or operation -status): - -- Get Connections POST - http://127.0.0.1:8181/restconf/operations/sxp-controller:get-connections - -:: - - - global - 0.0.0.100 - - -- Add Connection POST - http://127.0.0.1:8181/restconf/operations/sxp-controller:add-connection - -:: - - - 0.0.0.100 - global - - - 172.20.161.50 - 64999 - - default - - speaker - version4 - Connection to ASR1K - - - - 45 - 30 - - - - 172.20.161.178 - 64999 - - default - - listener - version4 - Connection to ISR - - - - 120 - 90 - 90 - 180 - - - - - -- Delete Connection POST - http://127.0.0.1:8181/restconf/operations/sxp-controller:delete-connection - -:: - - - 0.0.0.100 - global - 172.20.161.50 - - -- Add/Update Bindings POST - http://127.0.0.1:8181/restconf/operations/sxp-controller:add-bindings - -:: - - - 0.0.0.100 - global - LOCAL - - - 50 - 192.168.2.1/32 - 192.168.2.2/32 - - - 100 - 192.168.3.1/32 - 192.168.3.2/32 - - - - -- Delete Bindings POST - http://127.0.0.1:8181/restconf/operations/sxp-controller:delete-bindings - -:: - - - 0.0.0.100 - global - - 50 - 192.168.2.2/32 - - - 100 - 192.168.3.2/32 - - - -- Get Node Bindings - - This RPC gets particular device bindings. An SXP-aware node is - identified with a unique Node-ID. If a user requests bindings for a - Speaker 20.0.0.2, the RPC will search for an appropriate path, which - contains 20.0.0.2 Node-ID, within locally learnt SXP data in the SXP - database and replies with associated bindings. POST - http://127.0.0.1:8181/restconf/operations/sxp-controller:get-node-bindings - -:: - - - 20.0.0.2 - all - global - - -- Get Binding SGTs POST - http://127.0.0.1:8181/restconf/operations/sxp-controller:get-binding-sgts - -:: - - - 0.0.0.100 - global - 192.168.12.2/32 - - -- Add PeerGroup with or without filters to node. POST - http://127.0.0.1:8181/restconf/operations/sxp-controller:add-peer-group - -:: - - - 127.0.0.1 - - TEST - - - - outbound - - deny - 1 - 1 - 100 - - - permit - 45 - 1 - 3 - 5 - - - - - -- Delete PeerGroup with peer-group-name from node request-node. POST - http://127.0.0.1:8181/restconf/operations/sxp-controller:delete-peer-group - -:: - - - 127.0.0.1 - TEST - - -- Get PeerGroup with peer-group-name from node request-node. POST - http://127.0.0.1:8181/restconf/operations/sxp-controller:get-peer-group - -:: - - - 127.0.0.1 - TEST - - -- Add Filter to peer group on node request-node. POST - http://127.0.0.1:8181/restconf/operations/sxp-controller:add-filter - -:: - - - 127.0.0.1 - TEST - - outbound - - deny - 1 - 1 - 100 - - - permit - 45 - 1 - 3 - 5 - - - - -- Delete Filter from peer group on node request-node. POST - http://127.0.0.1:8181/restconf/operations/sxp-controller:delete-filter - -:: - - - 127.0.0.1 - TEST - outbound - - -- Update Filter of the same type in peer group on node request-node. - POST - http://127.0.0.1:8181/restconf/operations/sxp-controller:update-filter - -:: - - - 127.0.0.1 - TEST - - outbound - - deny - 1 - 1 - 100 - - - permit - 45 - 1 - 3 - 5 - - - - -- Add new SXP aware Node POST - http://127.0.0.1:8181/restconf/operations/sxp-controller:add-node - -:: - - - 1.1.1.1 - 0.0.0.0 - - 5 - 120 - 120 - 90 - 120 - 90 - 180 - 30 - - 150 - - password - - 64999 - version4 - ODL SXP Controller - - -- Delete SXP aware node POST - http://127.0.0.1:8181/restconf/operations/sxp-controller:delete-node - -:: - - - 1.1.1.1 - - -- Add SXP Domain on node request-node. POST - http://127.0.0.1:8181/restconf/operations/sxp-controller:add-domain - -:: - - - 1.1.1.1 - global - - -- Delete SXP Domain on node request-node. POST - http://127.0.0.1:8181/restconf/operations/sxp-controller:delete-domain - -:: - - - 1.1.1.1 - global - - -- Add Route Adds route to leader Node. PUT - http://127.0.0.1:8181/restconf/config/sxp-cluster-route:sxp-cluster-route/ - -:: - - - - 80.12.43.2 - eth1:0 - 255.255.255.0 - - - -Use cases for SXP -~~~~~~~~~~~~~~~~~ - -Cisco has a wide installed base of network devices supporting SXP. By -including SXP in OpenDaylight, the binding of policy groups to IP -addresses can be made available for possible further processing to a -wide range of devices, and applications running on OpenDaylight. The -range of applications that would be enabled is extensive. Here are just -a few of them: - -OpenDaylight based applications can take advantage of the IP-SGT binding -information. For example, access control can be defined by an operator -in terms of policy groups, while OpenDaylight can configure access -control lists on network elements using IP addresses, e.g., existing -technology. - -Interoperability between different vendors. Vendors have different -policy systems. Knowing the IP-SGT binding for Cisco makes it possible -to maintain policy groups between Cisco and other vendors. - -OpenDaylight can aggregate the binding information from many devices and -communicate it to a network element. For example, a firewall can use the -IP-SGT binding information to know how to handle IPs based on the -group-based ACLs it has set. But to do this with SXP alone, the firewall -has to maintain a large number of network connections to get the binding -information. This incurs heavy overhead costs to maintain all of the SXP -peering and protocol information. OpenDaylight can aggregate the -IP-group information so that the firewall need only connect to -OpenDaylight. By moving the information flow outside of the network -elements to a centralized position, we reduce the overhead of the CPU -consumption on the enforcement element. This is a huge savings - it -allows the enforcement point to only have to make one connection rather -than thousands, so it can concentrate on its primary job of forwarding -and enforcing. - -OpenDaylight can relay the binding information from one network element -to others. Changes in group membership can be propagated more readily -through a centralized model. For example, in a security application a -particular host (e.g., user or IP Address) may be found to be acting -suspiciously or violating established security policies. The defined -response is to put the host into a different source group for -remediation actions such as a lower quality of service, restricted -access to critical servers, or special routing conditions to ensure -deeper security enforcement (e.g., redirecting the host’s traffic -through an IPS with very restrictive policies). Updated group membership -for this host needs to be communicated to multiple network elements as -soon as possible; a very efficient and effective method of propagation -can be performed using OpenDaylight as a centralized point for relaying -the information. - -OpenDaylight can create filters for exporting and receiving IP-SGT -bindings used on specific peer groups, thus can provide more complex -maintaining of policy groups. - -Although the IP-SGT binding is only one specific piece of information, -and although SXP is implemented widely in a single vendor’s equipment, -bringing the ability of OpenDaylight to process and distribute the -bindings, is a very specific immediate useful implementation of policy -groups. It would go a long way to develop both the usefulness of -OpenDaylight and of policy groups. -- 2.36.6