SXP Specification and Architecture. Implementation of SXP Protocol. OpenDaylight SDN Controller. v.05

Transcription

1 SXP Specification and Architecture Implementation of SXP Protocol OpenDaylight SDN Controller v.05 (March 2017)

2 Table of Contents Introduction... 3 SXP Versions... 4 Architecture... 4 Security... 4 Client-Server Architecture... 4 Components Interaction Diagram... 6 SXP Filtering... 7 SXP Cluster-routing... 8 SXP Class Diagrams... 9 Binding Databases Yang Models Definition Configuration File Functional Diagrams TCP Keep-alive Mechanism Initial 3-way Handshake State Transition Diagram SXP Keep-alive and Hold-time Mechanism Database Update Mechanism Capabilities Advertisement Administrative Shutdown Messaging Messages Compositions UPDATE Message Validation UPDATE Message Processing Requirements Common Requirements SXP Speaker Functionality SXP Listener Functionality Timers Retry Open Timer Delete Hold-down Timer Reconciliation Timer Hold Timer (optional) Keep-alive Timer (optional) P a g e

3 SXP Lab Configurations YANG model overview Introduction The purpose of this document is to provide an architecture overview of the SXPv4 (Source-Group Tag exchange Protocol version 5) as it has been specified by the IETF informal internet draft (January 17, 201. SXP will be implemented as a plugin to the OpenDaylight (ODL) Software-Defined Networking (SDN) platform. SXP is a control-plane protocol used to transport IP address to Source Group Tag (SGT, see Figure 1) binding information from one SGT-aware network device to another. Source groups represent endpoints connected to network that have common network policies. Each source group is identified by a unique SGT value that can be used as a classifier in network policies demarcation. Figure 1: IP/SGT binding. SXP has both Speaker and Listener peer profiles. Both will be implemented in ODL. The SXP Listener component provides the ability for the IP/SGT bindings to be propagated to the controller from SXP-aware devices. The SXP Speaker component enables ODL to act as an aggregator and relay by forwarding IP/SGT bindings to SXP aware devices, e.g. the ODL controller will act as a SGT-aware network peer that can be used for static IP/SGT binding configuration and propagation to its subordinate network system. At first we will be focusing on the architecture specification. In the following, we continue with protocol functional overview and message composition. The last part will cover requirements for both Speaker and Listener component and several test cases tailored to validate the expected functionality. 3 P a g e

4 SXP Versions SXP implementation always supports the highest version and any version lower than that. SXP version negotiation is per connection base, i.e. the highest possible supported version between two peers is used. In summary, following table shows differences between available SXP versions. Version IPv4 Bindings IPv6 Bindings Subnet Binding Expansion Loop Detection SXP Capability Exchange 2 Yes Yes No No No 3 Yes Yes Yes No No 4 Yes Yes Yes Yes Yes Architecture Security As protocol defines SXP is using plain mode without any security options enabled where traffic is send between SXP peers without any encryption and option with TCP-MD5 where each message contains MD5 hash that is uses for verification of remote peers. Starting with Carbon release SXP adds SSL security option that uses 2 way authentification of peers. All traffic is encrypted between peers while using this option. Currently this security option is available only in ODL environment as it is not defined as part of RFC. Using this Security option does not break usage of previous options and can be used simultaneously. Client-Server Architecture Typically, servers provide resources or services to service requesters, called clients. A server host runs one or more server programs which share their resources with clients. Clients therefore initiate communication sessions with servers to request hosted content or a service function and await incoming requests. From our SXP point of view the SXP Speaker represents the server/provider side of the distributed application, because it provides data to a SXP Listener, which is the client, a service requester. Mentioned distributed client-server application structure partitions tasks or workloads between the service providers and service requesters and can be described by the following client-server computing model, see Figure 2. 4 P a g e

5 Figure 2: The SXP Client-Server class diagram. A number of SXP connections are set between various network devices to allow the flow of SGT tags. 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, i.e. 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. DataInputStream and DataOutputStream classes are used to handle the sending encoded data. The above client-server architecture will be implemented within the Netty framework ( Netty is Java library and API that simplifies development of network applications. It is primarily aimed at writing highly concurrent asynchronous networked and networking applications and services. Its model simplifies network application development. A socket is bound with a Netty channel pipeline where multiple data handlers can be specified. There are two kinds of threads: The Boss Threads create and connect/bind sockets and then pass them off to the worker threads. In the server, there is one boss thread allocated per listening socket. In the client, there is only one boss thread. The Worker Threads perform all the asynchronous I/O in the channel pipeline. 5 P a g e

6 SXP will be implemented as a library to the ODL above the Netty framework, so at the beginning the SXP core can be tested more easily without whole running ODL. The minimal Netty version used in ODL is Final. introductionhttp://seeallhearall.blogspot.com/2012/05/netty-tutorial-part-1-introduction-to.htmlto.html Components Interaction Diagram The components interaction overview (see Figure 3) visualizes main SXP components and their encapsulation within the ODL platform. SXP can be configured through an input XML file that contains protocol configuration parameters, e.g. global password, node ID, role, local binding definition etc.; and the definitions of node connections to selected peers. The configuration is directly loaded into ODL data store and processed by SXP Configuration Manager, which is responsible for SXP node setup. 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. 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. Binding Handler handles bindings from multiple connections. If a new data has been added into or deleted from the SXPDatabase, or binding s contributor change is detected, the manager performs an arbitration process above the SXPDatabase to resolve the binding duplicity and prevent possible informastion loops. Finally, it updates the IP-SGT-Master database that consists only of valid and unique bindings, i.e. a single binding per IP address. The SXP Binding Dispatcher represents a selector that will solve how many data from the Master database will be sent and when. It is responsible for message content composition based on maximum message length. 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 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 The SXP route feature provides service on top of existing SXP cluster solution, that simplify managing of SXP peers connected to cluster as from view point of SXP devices SXP cluster would look like single device instead of n-node setup. SXP Listener components are depicted in green (Figure 3), the Speaker components in red, and the common components are in yellow. SXP Speaker or Listener is encapsulated in the ODL provider southbound MD-SAL plugin which provides notifications to other plugins or performs RPCs. The following notifications are generated: Bindings that have been received in an UPDATE message Bindings that have been sent to or deleted from the Master database Bindings that have been sent in a new UPDATE message to the node peer 6 P a g e

7 The IP-SGT Manager contains RPCs that can be used by other ODL plugins, or by UI REST calls, to add, update or to delete bindings in or from the Master database, filters and peer manipulation. SXP configuration data is stored in the MD-SAL configuration data store. Periodic snapshots of the SXP database and the IP-SGT Master database are stored in the MDSAL operational data store. Figure 3: Components interaction diagram. SXP Filtering Filtering capability of bindings is provided by sxp-core component. By this capability the flow of bindings can be adjusted based on various conditions, and reduce impact of sending big Update messages that may flood the network and devices. Filters are applied before adding bindings into SXP-Database, Master-Database or during export of bindings to peers. It is critical to preserve order of filtering and manipulation of bindings as it may easily lead to race conditions and thus inconsistent databases. Logic of filters is driven by ACL and Prefix List logic based on first/best match logic. Each filter can specify its criteria based on ip-prefix sgt or peer-sequence length. Filers can be applied per peer or per group of peers. Additionally they may be used within inter-domain sharing of bindings. From architectural aspect SXP Filters are applied in two main components SXP before propagating bindings to SXP Database in Binding Handler, before adding them to Master Database and in Binding Dispatcher before generating and propagation of Update messages. 7 P a g e

8 SXP Cluster-routing From Carbon SXP provides cluster capabilities with 3,5 Node setups. While using SXP in cluster only one cluster Node have actively running SXP-Controller instance. Running instance behaves as single Node setup of SXP in term of external view. Internally the major difference is that the Configuration defined in SXP is populated to all nodes of cluster, so in case of failure of current leader of SXP-Controller instance old instance of SXP-Controller will close all its connections to remote peers and one of remaining active cluster nodes will instantiate new instance of SXP-Controller that will reconnect to all previously defined peers. Downsides of this approach are that each peer needs to have 3 connections defined to cluster instead of 1 and after each reconnection each device will hold double the amount of bindings from Cluster until Delete Hold Down timer runs out. This is mainly caused by devices unawareness of cluster. To reduce impact of issues described above SXP-Routing feature is provided. The whole purpose of this feature is to provide virtual-ip that will be used for communication between SXP devices and SXP Cluster. Using this feature puts restriction to environment that runs ODL distribution as it needs arping and ifconfig to be installed on host system. Using these binaries the feature is able to route the traffic through virtual interface to virtual-ip. 8 P a g e

9 SXP Class Diagrams In this section we provide class diagrams that show current state of the SXP protocol core and SXP ODL plugin implementation. Figure 4: SXP messaging package. 9 P a g e

10 Figure 5: SXP node and per-connection timers. 10 P a g e

11 Figure 6: SXP core Behaviour strategy pattern that supports protocol legacy versions incorporation. 11 P a g e

12 Figure 7: SXP controller Overall overview. Figure 9: SXP route Overall overview. 12 P a g e

13 Figure 9: SXP core Overall overview. Binding Databases If a new binding from a connection is received it s stored to the SXP-Database. After the arbitration process is finished, IPSGT Manager updates new learned bindings or binding changes in the IP-SGT-Master database. Master contains only a single binding per IP address and expanded subnet binding. SXP Binding Dispatcher then exports Master s bindings to a node connected peer. 13 P a g e

14 SXP-Database PeerID SGT Type Address Prefix String Representation 1 SGT-1 IPv SGT-1 IPv SGT-1 IPv SGT-2 IPv6 2607:f0d0:1002:0051:0000:0000:0000: :f0d0:1002:51::4 4 SGT-2 IPv6 2001:0db8:85a3:0000:0000:8a2e:0370: :db8:85a3::8a2e:370: SGT-2 IPv6 2607:f0d0:1002:0051:0000:0000:0000: :f0d0:1002:51::4 4 SGT-2 IPv6 2001:0db8:85a3:0000:0000:8a2e:0370: :db8:85a3::8a2e:370: SGT-2 IPv6 2607:f0d0:1002:0051:0000:0000:0000: :f0d0:1002:51::4 6 SGT-2 IPv6 2001:0db8:85a3:0000:0000:8a2e:0370: :db8:85a3::8a2e:370:7334 IP-SGT-Master DB Source SGT Type Address Prefix String Representation SXP SGT-1 IPv LOCAL SGT-2 IPv LOCAL SGT-3 Subnet LOCAL SGT-3 Expanded P a g e

15 LOCAL SGT-3 Expanded LOCAL SGT-3 Expanded LOCAL SGT-3 Expanded LOCAL SGT-3 Expanded LOCAL SGT-3 Expanded LOCAL SGT-3 Expanded SXP SGT-2 IPv6 2607:f0d0:1002:0051:0000:0000:0000: :f0d0:1002:51::4 SXP SGT-2 IPv6 2001:0db8:85a3:0000:0000:8a2e:0370: :db8:85a3::8a2e:370:7334 Yang Models Definition Following Yang models have been constructed to fulfil SXP MD-SAL storage requirements for configuration and state data: Configuration File 22-sxp-controller-one-node.xml 1 local ODL aware node Functional Diagrams TCP Keep-alive Mechanism SXP device default behaviour is to maintain connectivity with its peers. In case of failures, the SXP device continues to retry connection setup with all the peers with which the SXP connections have not been established until (Figure 12): Either a connection is established or The peer is removed from the peer set by a change in configuration. If both ends set up the TCP connection at the same time, the end with source IP address higher than the peer IP address wins, i.e. the TCP connection initiated from that end is kept and the reflecting one inside the peer is torn down. 15 P a g e

16 Figure 12: Peers TCP Keep-alive mechanisms. Initial 3-way Handshake After a TCP connection is established, the end that initiates the TCP connection starts the SXP negotiation by sending the OPEN message with attributes like SXP version, mode, and hold time; and if this end is a listener, SXP capabilities are attached. The receiving device responds with an OPEN_RESP message that includes similar attributes (see Figure 13). SXP uses the underlying TCP MD5 option for message authenticity. Peers pre-configured password will be used for forming the MD5 digest that is negotiated during the initial SXP 3-way handshake. Figure 13: Initial SXP handshake after the TCP connection establishment. After the SXP connection is established, binding information can be sent from speaker to listener with an UPDATE message. Whenever the SXP connection has to be closed the underlying TCP connection is closed. State Transition Diagram Each SXP connection maintains four following states: OFF PENDING ON A connection initiation has not been started, retry establishing of the TCP connection can be performed. An SXP OPEN message has been sent to the peer and a response from the peer is expected. DELETE HOLD DOWN A connection that was previously in ON state has been terminated. Only a listener can be in this state. 16 P a g e

17 ON SXP OPEN or SXP OPEN RESP message has been received and SXP connection has been setup successfully. Binding propagation is enabled. Figure 14 depicts the SXP peer state transition diagram. Possible failure messages that lead to peer OFF state are shown in red; the green ones aim a connection to be alive. Figure 14: SXP peer state transition diagram. SXP Keep-alive and Hold-time Mechanism SXPv4 added optional negotiation for keep-alive mechanism to provide timely detection of connection loss (Figure 15). The mechanism is based on two timers: Hold Timer used by a Listener - elapsing time if no KEEPALIVE and/or UPDATE message is received. Keep-alive Timer used by a Speaker - triggering sending KEEPALIVE messages if no UPDATE message is sent. Figure 15: SXP Keep-alive and Hold-time mechanism. During the initial SXP 3-way handshake after TCP connection establishment, the negotiation of hold down timer value (T H) may be performed. After the hold down timer value negotiation, SXP Speaker sets its Keep-alive timer value (T KA) to 17 P a g e

18 Negotiation process: A listener s Hold Time range period can be configured locally or a default range <90, 180> seconds can be used. <0xFFFF, 0xFFFF> implies to disabled keep-alive mechanism. A speaker s minimum acceptable Hold Time period can be con5d locally or a default 120 sec. can be used. 0xFFFF implies to disabled keep-alive mechanism. The negotiation succeeds when the speaker's minimum acceptable Hold Time falls below or within the desirable Hold Time range of the listener (Figure 16). If one end turns off the keep-alive mechanism, the other end should also turn it off to make the negotiation success. The selected Hold Time period of a successful negotiation is the maximum of the speaker's minimum acceptable Hold Time and the lower bound of the listener's Hold Time range. The speaker calculates the Keep-alive Time to 1/3 of the selected Hold Time by default unless a different Keepalive Time is locally configured (see a random jitter in the Timers section). Figure 16: The hold-time negotiation process illustration. Database Update Mechanism If the SXP connection goes down and the device learned bindings from the peer previously, a delete hold down timer is started for that connection: Once the timer expires, all binding entries that were learned from the failed peer are deleted. If the failed peer was the only source for a deleted binding, the master binding database is notified. If the connection recovers before the delete hold down timer expires, a reconcile timer is started to clean up old bindings that didn't get informed to be removed because of the loss of connectivity. 18 P a g e

19 Figure 17: SXP update mechanism. Capabilities Advertisement During the SXP 3-way handshake a listener advertises its capabilities to speaker about its supported SXP features. This allows the speaker to tailor relevant connection behaviour to what the listener could process. A speaker shall not send to listener information that isn t supported for processing in a listener. A speaker ignores a capability advertised from a listener which it does not itself support or recognize. Neither ERROR message is generated, nor an SXP session is terminated in this case. Figure 18: Capabilities advertisement. SXPv4 supports three types of capabilities: 19 P a g e

20 Subnet Bindings - A listener that supports Subnet bindings must inform a speaker peer about this capability. If a speaker is informed about this listener capability, it should export bindings as regular bindings without any expansion, or may expand subnet bindings exhaustively or selectively and export individual bindings within a subnet. The expansion can be limited by implementation to a reasonable subnet size with a limit on the total number of bindings expanded. IPv6 Unicast - A listener that supports IPv6 bindings must informed a speaker peer about this capability. If a speaker is not informed about this listener capability, it must not send IPv6 bindings within well-known attributes; however, it should send IPv6 bindings within Optional Transitive attributes. IPv4 Unicast - This capability is handled in the same way as IPv6 Unicast capability. Administrative Shutdown This message not contains a payload. When an SXP Speaker connection is administratively deleted or whole SXP feature is administratively disabled, the node must send PURGE-ALL messages to all relevant SXP listeners remote ends. In this case the connection is torn down administratively and it s not the case of an intermittent loss of communication. The listener will immediately delete all bindings that were received on that connection, i.e. no Delete Hold-Down timer is initiated. Figure 19: SXP PURGE-ALL message propagation on administratively shut down, both connection and the node SXP participation. Messaging Messages Compositions This section provides overview of SXP messages structure in the byte scheme. Each column represents a message field that has a given byte quantity. Finer diagrams of messages representation are presented in the referenced informational internet-draft. Message composition 20 P a g e

21 SXP HEADER Length Type Payload 4 4 X Available message types (message length can t be greater than 4096 bytes): Max Length OPEN 2 OPEN_RESP 3 UPDATE 4 ERROR 5 PURGE_ALL MSG TYPE 6 KEEPALIVE SXP OPEN and OPEN_RESP message composition SXP OPEN AND OPEN_RESP MSG Version Mode Node-ID Capabilities Other Attributes X X SXP ATTRIBUTES 21 P a g e

22 SXP message attribute composition Each SXP attribute is composed from leading ONPCE flags, type, length and value (TLV) fields. SXP ATTRIBUTE O N P C E Type TLV Length Reserved Value 1 1 or 4 TLV Extended Length TLV Length 1-2 or 4 Available flags: optional (O), non-transitive (N), partial (P), compact (C), extended length (E) Allowed SXP attribute variants and defined types: Defined Attributes Types Name Type Add-IPv4 1 Add-IPv6 2 Del-IPv4 3 Del-IPv6 4 SXP Node ID 5 Capabilities 6 Hold-Time 7 IPv4-Add-Prefix 11 IPv6-Add-Prefix 12 IPv4-Delete-Prefix 13 Attributes Variants COMPACT COMPACT EXTENDED LENGTH NON COMPACT NON COMPACT EXTENDED LENGTH Defined Sub-Attributes Types Name Type SGT 1 Prefix-Length 2 IPv6-Delete-Prefix 14 Peer-Sequence 16 Security-Group-Tag 17 IPv4-Add-Table 21 IPv6-Add-Table 22 SXP message capability attributes composition 22 P a g e

23 SXP CAPABILITY ATTRIBUTE O N P C E Type TLV Length Reserved Cap. Code N Cap. Length N Reserved Capability Value N TLV Extended Length X 1 1 or or 4 Supported SXP version 4 capabilities: 1 IPv4 Unicast 2 IPv6 Unicast CAPABILITY TYPE 3 Subnet Bindings SXP message hold-time attributes composition SXP HOLD-TIME ATTRIBUTE O N P C E Type TLV Length Reserved Hold Time Min. Value Hold Time Max. Value 1 7 TLV Extended Length or or 4 SXP UPDATE Message Composition SXP UPDATE MSG ATTRIBUTE 1 ATTRIBUTE 2 ATTRIBUTE N 23 P a g e

24 SXP UPDATE attributes An UPDATE message may contain one or more attributes. Following update attributes are available to be used, each one is more detailed described in the informational internet draft with a few UPDATE message examples. IPv4 Delete Prefix Attribute IPv6 Delete Prefix Attribute Peer-Sequence Attribute Source-Group-Tag Attribute IPv4-Add-Prefix Attribute IPv6-Add-Prefix Attribute IPv4-Add-Table Attribute IPv6-Add-Table Attribute SXP ERROR Message Composition Available ERROR message codes: SXP ERROR MSG 1 Message Header Error 2 OPEN Message Error Ex. Error Code Sub. Error Code Reserved 3 UPDATE Message Error -.1 Malformed Attribute List Unrecognized Well-known Attribute ERROR CODES -.3 Missing Well-known Attribute -.4 Attribute Flags Error -.5 Attribute Length Error -.6 Malformed Attribute -.7 Optional Attribute Error -.8 Unsupported Version Number -.9 Unsupported Optional Attribute -.10 Unacceptable Hold Time 24 P a g e

25 UPDATE Message Validation All errors detected while processing the UPDATE message must be indicated by sending the ERROR message with the appropriate Error Code (UPDATE Message Error) to the SXP speaker from which the UPDATE message was received. Figure 20 shows a Petri net representation of decision making via UPDATE message validation process. Figure 20: Petri net describing UPDATE message validation process and ERROR messages generation. SXP version mismatch and SXP message parse error will result in the device sending an Error TLV. When sending an ERROR message, the error code is passed as part of the TLV and the action decision is left up to the peer device, e.g. error logging for debugging purposes. The SXP connection is closed and retries to setup after sending the SXP ERROR message. 25 P a g e

26 Figure 21: Generated ERROR message on invalid UPDATE message. UPDATE Message Processing Processing of an UPDATE message by an SXP listener follows the organization of the message according to the high level steps that are represented by following Petri net (see Figure 22). Figure 22: Petri net describing high level steps of UPDATE message processing. Requirements Common Requirements TCP will be used as transport layer protocol. Binding information should be propagated from a speaker to a listener. The best IP address of a device will be used to reach the specified peer IP address. IPv4 and IPv6 support for the source and peer source IP addresses. The connection can only be setup on IPv4 with one end configured as a speaker and the other end as a listener. Connected SXP entities will use same SXP password for authentication. There should be at least a default password for connections and an optional per-connection password can be defined. The SXP password can be up to 80 ASCII characters. SXP password will authenticate all further messages using the MD5 algorithm, payload is not encrypted. Each packet needs to be "signed" with the 16 bytes MD5 digest formed using the password as the key. 26 P a g e

27 The key used with TCP MD5 [RFC1321] should be chosen to be long and have high entropy to provide as much protection from dictionary attacks as possible. If the password changed for an existing TCP connection, the peer resets the existing TCP connection with a new password (default password will resets all SXP connections). A system should have a master binding database for reconciling binding information from multiple SXP connections. The database should consist of a single binding per IP address. The usage of Hold Timer and KEEPALIVE messages is negotiated during OPEN/OPEN_RESP exchange. SXP Speaker Functionality Speaker is responsible for sending the IP-SGT bindings. KEEPALIVE and PURGE-ALL messages propagation. If a speaker does not expand a subnet binding it should export it unmodified as a subnet binding. This will allow the listener to propagate such bindings even when it cannot use it locally. If a speaker expands a subnet binding it must not export it as both subnet and expanded bindings since the listener or any further SXP peers along the SXP propagation path cannot distinguish expanded bindings from other host bindings and relate them to the subnet bindings they are originate from. SXP Listener Functionality Listener is responsible for collecting IP-SGT bindings. There should be a mechanism to handle same bindings from multiple SXP connections. If the device has learnt any bindings from the peer where the SXP connection goes down, a delete hold down timer is started for that connection. UPDATE messages handling only in the ON state. UPDATE messages validation and processing. If subnet binding capability is not supported in listener s forwarding path but the listener has the capability to expand subnet bindings locally, it must send Subnet Bindings capability in order to prevent the listener from unnecessarily expanding subnet bindings. If subnet binding capability is not supported but the listener might be able to support the volume of expanded bindings, it may include Subnet Bindings capabilities. Timers The SXP defines 5 SXP timers to handle communication agility and binding completeness. An additional one is used to minimize the data flow through ODL data store: Retry Open Timer Retry open timer is triggered as long as there is one SXP connection on the device that is not up. The retry continues until the SXP connection is setup or the retry timer is configured to be P a g e

28 Default timer value is 120 sec. If zero, timer won t be used. Delete Hold-down Timer Trigger when a connection on listener side is torn down. The bindings are deleted upon the timer expiration. Default timer value is 120 sec. and it s not configurable. Reconciliation Timer Timer starts right after the connection is brought up to wait for the new bindings to be forwarded from the peer. The old bindings learnt before the connection goes down still holds. Upon the timer expiry, SXP checks the bindings in its input binding database and delete any stale bindings, i.e. bindings that could have been deleted on the remote side while the connection was down. Default timer value is 120 sec. If zero, timer won t be used. Hold Timer (optional) Its use is negotiated during SXP initialization. The interval is set to the negotiated Hold Time. Used by an SXP Listener to detect lifeless connections. Timer starts when the connection reached ON state. Timer is restarted if a listener receives a KEEPALIVE or an UPDATE message. If timer expires, SXP must send an ERROR message with Hold Timer Expired code and tear down the connection. If timer expires, the Delete Hold Down timer is restarted for delayed deletion of bindings. Default timer value is 90 sec. and can be configurable. The actual value used for a connection is negotiated. Keep-alive Timer (optional) Its use is negotiated during SXP initialization. The interval is set to one third of the negotiated Hold Time. Used by an SXP speaker to trigger sending KEEPALIVE messages. Timer is restarted for the first time when the connection reaches its ON state. Timer is restarted if an UPDATE or KEEPALIVE message is sent. Upon timer expiry, SXP speaker must send KEEPALIVE message. Default timer value is 30 sec. and can be configurable. The actual value used for a connection is set to 1/3 of negotiated Hold Time. Timer is restarted with a random jitter. The actual period of the Timer is set to a random value between <0.75, 1.0> of the negotiated Keep-alive Time, which is re-calculated every time the timer is restarted. 28 P a g e

29 SXP Lab Configurations Figure 23: Native SXP lab configuration. Figure 24: NAG lab configuration. 29 P a g e

30 Figure 25: Native SXP lab and NAG lab cross connection. 30 P a g e

31 YANG model overview 31 P a g e

32 32 P a g e

33 33 P a g e

34 34 P a g e

35 35 P a g e