Updated SXP docs with Filtering feature 66/27766/2
authorMartin Mihálek <mamihale@cisco.com>
Thu, 1 Oct 2015 20:43:59 +0000 (22:43 +0200)
committerMartin Mihálek <mamihale@cisco.com>
Thu, 12 Nov 2015 11:33:56 +0000 (12:33 +0100)
Change-Id: Iccde9c91f3e118af895dca9805f7bebc940bb6c1
Signed-off-by: Martin Mihálek <mamihale@cisco.com>
manuals/developer-guide/src/main/asciidoc/sxp/odl-sxp-dev.adoc
manuals/user-guide/src/main/asciidoc/sxp/odl-sxp-user.adoc

index ad59f4d51866c6b673c005245a306e78b5c943f1..b5027f0e51166afd0f2aebf146e26e01d061c21e 100644 (file)
@@ -1,7 +1,7 @@
 == SXP Developer Guide
 
 === Overview
-SXP (Source-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 https://tools.ietf.org/html/draft-smith-kandula-sxp-02[IETF draft]. 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 (Source-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 https://tools.ietf.org/html/draft-smith-kandula-sxp-04[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.
@@ -18,6 +18,8 @@ The IP-SGT Manager also contains RPCs that can be used by other OpenDaylight plu
 
 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 outcoming and incoming IP-SGT bindings according to BGP filtering using ACL and Prefix List syntax for specifiing filter.
+
 === 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.
@@ -37,4 +39,4 @@ Main logic and core features
 
 === API Reference Documentation
 https://wiki.opendaylight.org/images/9/91/SXP_Restconf_Interface_and_Dynamic_Tree.pdf[RESTCONF Interface and Dynamic Tree]
-
+https://wiki.opendaylight.org/images/6/6e/SXP_Specification_and_Architecture_v03.pdf[Specification and Architecture]
index c57e14226a9c71b23335f1dd38a1fe258bd7cba7..c4454efefe1f350a3bb3402f5a9290fd3152c54a 100644 (file)
@@ -1,7 +1,7 @@
 == SXP User Guide
 
 === Overview
-SXP (Source-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 https://tools.ietf.org/html/draft-smith-kandula-sxp-02[IETF draft]. 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 (Source-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 https://tools.ietf.org/html/draft-smith-kandula-sxp-04[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.
@@ -18,6 +18,8 @@ The IP-SGT Manager also contains RPCs that can be used by other OpenDaylight plu
 
 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 outcoming and incoming IP-SGT bindings according to BGP filtering using ACL and Prefix List syntax for specifiing filter.
+
 === Configuring SXP
 The OpenDaylight Karaf distribution comes pre-configured with baseline SXP
 configuration.
@@ -157,6 +159,8 @@ OpenDaylight can aggregate the binding information from many devices and communi
 
 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 recieving IP-SGTT 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.