idnits 2.17.1 draft-smith-kandula-sxp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 8, 2019) is 1817 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5926' is defined on line 2269, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Smith 3 Internet-Draft R. Kandula 4 Intended status: Informational S. Appala 5 Expires: October 10, 2019 Cisco Systems 6 April 8, 2019 8 Scalable-Group Tag eXchange Protocol (SXP) 9 draft-smith-kandula-sxp-08 11 Abstract 13 This document discusses scalable-group tag exchange protocol (SXP), a 14 control protocol to propagate IP address to Scalable Group Tag (SGT) 15 binding information across network devices. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 10, 2019. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may not be modified, and derivative works of it may not 56 be created, except to format it for publication as an RFC or to 57 translate it into languages other than English. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. SXP Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. SXP Operation . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. SXP Connection Management . . . . . . . . . . . . . . . . 5 66 3.1.1. SXP Connection . . . . . . . . . . . . . . . . . . . 5 67 3.1.2. SXP Message integrity/authenticity . . . . . . . . . 6 68 3.1.3. SXP Connectivity Discovery and Connection Recovery . 7 69 3.1.4. SXP Connection Setup Sequence . . . . . . . . . . . . 7 70 3.1.5. SXP Connection States . . . . . . . . . . . . . . . . 8 71 3.2. Binding Database . . . . . . . . . . . . . . . . . . . . 9 72 3.2.1. SXP Learned IP-SGT Binding recovery . . . . . . . . . 9 73 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.1. Bit and Octet Numbering Convention . . . . . . . . . . . 9 75 4.2. SXP Message Header . . . . . . . . . . . . . . . . . . . 10 76 4.3. Attribute Formats . . . . . . . . . . . . . . . . . . . . 10 77 4.4. SXP OPEN and OPEN_RESP Message . . . . . . . . . . . . . 13 78 4.4.1. Node-ID . . . . . . . . . . . . . . . . . . . . . . . 14 79 4.4.2. Capabilities Advertisement . . . . . . . . . . . . . 14 80 4.4.3. Keep-alive and Hold Time Negotiation . . . . . . . . 17 81 4.5. SXP UPDATE Message . . . . . . . . . . . . . . . . . . . 22 82 4.5.1. UPDATE Attributes . . . . . . . . . . . . . . . . . . 23 83 4.5.2. UPDATE Message Samples . . . . . . . . . . . . . . . 32 84 4.6. SXP ERROR Message . . . . . . . . . . . . . . . . . . . . 35 85 4.6.1. Error Codes . . . . . . . . . . . . . . . . . . . . . 36 86 4.7. SXP PURGE-ALL Message . . . . . . . . . . . . . . . . . . 37 87 4.8. SXP KEEPALIVE Message . . . . . . . . . . . . . . . . . . 37 88 5. Update Message Handling . . . . . . . . . . . . . . . . . . . 37 89 5.1. UPDATE Message Validation . . . . . . . . . . . . . . . . 37 90 5.2. UPDATE Message processing . . . . . . . . . . . . . . . . 39 91 5.3. Generating UPDATE Message . . . . . . . . . . . . . . . . 43 92 6. SXP Failure Scenarios . . . . . . . . . . . . . . . . . . . . 44 93 7. SXP Timers . . . . . . . . . . . . . . . . . . . . . . . . . 44 94 8. SXP Version Negotiation . . . . . . . . . . . . . . . . . . . 47 95 8.1. SXP Versions . . . . . . . . . . . . . . . . . . . . . . 47 96 8.2. Error Handling in Older SXP Versions . . . . . . . . . . 48 97 8.2.1. SXP Version 1 . . . . . . . . . . . . . . . . . . . . 48 98 8.2.2. SXP Version 2 . . . . . . . . . . . . . . . . . . . . 48 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 48 100 10. Implementation Note . . . . . . . . . . . . . . . . . . . . . 49 101 10.1. Bi-Directional SXP . . . . . . . . . . . . . . . . . . . 49 102 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 103 12. IPR Disclosure . . . . . . . . . . . . . . . . . . . . . . . 49 104 13. Copyright Notice and Disclaimer . . . . . . . . . . . . . . . 50 105 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 106 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 107 15.1. Normative References . . . . . . . . . . . . . . . . . . 50 108 15.2. Informative References . . . . . . . . . . . . . . . . . 51 109 Appendix A. SGT as MetaData in Data Plane . . . . . . . . . . . 51 110 A.1. CMD Format . . . . . . . . . . . . . . . . . . . . . . . 51 111 A.1.1. Metadata Header . . . . . . . . . . . . . . . . . . . 52 112 A.1.2. Metadata Payload . . . . . . . . . . . . . . . . . . 52 113 A.1.3. Header Protection . . . . . . . . . . . . . . . . . . 53 114 A.1.4. Header Insertion, Removal, and Relocation . . . . . . 53 115 A.2. Assigned Ethernet Type . . . . . . . . . . . . . . . . . 54 116 Appendix B. SGT in Network Services Header (NSH) . . . . . . . . 54 117 Appendix C. SGT CMD in GRE . . . . . . . . . . . . . . . . . . . 54 118 Appendix D. SGT NSH in GRE . . . . . . . . . . . . . . . . . . . 55 119 Appendix E. SGT in VXLAN . . . . . . . . . . . . . . . . . . . . 55 120 Appendix F. SGT tagging exemption for L2 control traffic . . . . 55 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 123 1. Introduction 125 SXP stands for the Scalable Group Tag (SGT) eXchange Protocol. 126 Scalable Group Tags are assigned to endpoints connecting to the 127 network that have common network policies. Each Scalable Group Tag 128 is identified by a unique SGT value. The SGT to which an endpoint 129 belongs can be assigned statically or dynamically, and the SGT can be 130 used as a classifier in network policies. SXP is a control-plane 131 mechanism used to transport an endpoint's SGT along with the IP 132 address from one SGT-aware network device to another. The data that 133 SXP transports is referred to as the IP-SGT binding in the rest of 134 the document. 136 Conveying this information allows SGT-aware network devices to make 137 policy decisions based on the role or intent of an endpoint, which is 138 expressed as a Scalable Group and represented by an SGT. 140 Implementations currently use SGT classifiers to apply policy 141 enforcement in a number of ways - 143 o Apply different access control decisions through an SGT-aware 144 access control list or firewall policy 146 o Apply micro-segmentation on network devices such as switches and 147 WLAN access points 149 o Invoke different security inspection functions, such as intrusion 150 detection to traffic based on the SGT of the endpoint 152 In addition to providing policy enforcement, implementations also 153 currently use SGT functions to - 155 o Provide logging information which includes the SGT to indicate the 156 role of an endpoint to analytics tools 158 o Apply different Quality of Service policies based on the SGT of 159 the endpoint 161 o Apply a different forwarding decision based on the SGT of the 162 endpoint 164 1.1. Terminology 166 This document frequently uses the following terms: 168 SGT Scalable Group Tag 170 SXP Scalable-Group Tag (SGT) eXchange Protocol 172 IP-SGT The IP Address to SGT binding that is exchanged over SXP 173 connection 175 SXP Speaker The peer that sends the IP-SGT bindings over the SXP 176 connection 178 SXP Listener The peer that receives the IP-SGT bindings over the SXP 179 connection 181 Binding Database The database of IP-SGT bindings that the SXP Speaker 182 uses to export to the peer 184 2. SXP Overview 186 SXP uses TCP as its transport protocol to set up SXP connection 187 between 2 separate network devices. Each SXP connection has one peer 188 designated as SXP speaker and the other peer as SXP listener. The 189 peers can also be configured in a bi-directional (both) mode where 190 each of them act as both speaker & listener. Connections can be 191 initiated by either peer but binding information is always propagated 192 from a speaker to a listener. 194 At a very high level, SXP comprises of the following - 196 - SXP connection establishment 198 - IP-SGT bindings propagation 200 A typical deployment scenario of SXP is illustrated below - 202 +---------------+ +----------------+ 203 | | | | 204 | | | | 205 | | | | 206 | SXP Speaker |----------------------------->| SXP Listener | 207 | | IP-SGT Bindings | | 208 | | | | 209 | | | | 210 +---------------+ +----------------+ 211 | | 212 | | 213 | | 214 | | 215 +------------------------------------------------+ 217 SXP Connection 219 3. SXP Operation 221 The SXP connections are point-to-point and uses TCP as the underlying 222 transport protocol. The summary of operations is illustrated in each 223 of the sections below. 225 3.1. SXP Connection Management 227 An SXP connection consists of the following parts: 229 3.1.1. SXP Connection 231 o The peer IP address, source IP address (the best IP address of 232 local device used to reach the specified peer IP address) 234 * Used to construct TCP connection 236 o The connection mode 238 * An SXP connection can be configured for uni-directional or bi- 239 directional communication. For each direction, one peer must 240 act as an sxp speaker and the other act as an sxp listener. 242 * The SXP speaker is responsible for sending the IP-SGT bindings. 244 * The SXP listener is responsible for collecting the IP-SGT 245 bindings received from the speaker peer and also merge the 246 bindings received from multiple connections. 248 o SXP connection password 250 * If SXP data integrity and authentication are required, then 251 both the peer devices must have same authentication mechanism 252 (MD5 or TCP-AO). The passwords should match on both the peers 253 in case of MD5 and similarly the key-chains in case of TCP-AO. 255 3.1.2. SXP Message integrity/authenticity 257 3.1.2.1. SXP Connection Using MD5 259 The connection peers on the 2 network devices supply the same SXP 260 password to the TCP layer which will authenticate all further 261 messages using the MD5 algorithm (RFC 2385). The SXP payload is not 262 encrypted because the main requirement is for the receiving device to 263 determine that the message originated from a valid source and not to 264 prevent snooping of message (discussed in security considerations 265 section) payload. SXP uses the underlying TCP MD5 option for message 266 integrity/authenticity. The TCP MD5 is exchanged (negotiated) during 267 the initial TCP 3 way handshake. Both sides (peers) are pre- 268 configured with the keys (password) which will be used for forming 269 the MD5 digest. Each packet (segment) needs to be "signed" with the 270 MD5 digest (16 bytes) formed using the password as the key. 272 Whenever the password needs to be changed for an existing TCP 273 connection, the peer resets the existing TCP connection and sets up a 274 new TCP connection with the new password. Changing the default 275 password will cause all SXP connections using the default password to 276 be re-established. 278 3.1.2.2. SXP Connection Using TCP-AO 280 The connection peers on the 2 network devices can authenticate each 281 other using TCP-AO (RFC 5925). SXP uses the underlying TCP-AO option 282 for message integrity/authenticity. The TCP-AO option is exchanged 283 (negotiated) during the initial TCP 3 way handshake. Both sides 284 (peers) are pre-configured with the keys which will be used for 285 forming the HMAC. The TCP module will populate the TCP-AO option in 286 each outgoing segment by generating the HMAC using the traffic keys. 287 On the receiver, TCP will generate the HMAC using the traffic keys 288 and incoming segment header to validate the HMAC in the incoming TCP- 289 AO option. 291 Whenever the TCP-AO key-chain needs to be changed for an existing TCP 292 connection, the peer resets the existing TCP connection and sets up a 293 new TCP connection with the new key-chain. Changing the default key- 294 chain will cause all SXP connections using the default key-chain to 295 be re-established. 297 3.1.3. SXP Connectivity Discovery and Connection Recovery 299 SXP uses the TCP keep alive mechanism with the default behavior to 300 maintain SXP connectivity. A SXP device attempts to maintain 301 connectivity with each peer. In case of failures, the SXP device 302 continues to retry connection setup with all the peers with which the 303 SXP connections have not been established. This continues until 304 either a connection is established or the peer is removed from the 305 peer set by a change in configuration. This mechanism ensures 306 automatic recovery of the SXP connection once the connectivity issue 307 is resolved. The SXP connection can be re-established by either 308 device and hence the connection can be brought up sooner without 309 relying on the retry timers of the peer devices. Note that this is 310 just an optimization and not a requirement for SXP connection 311 recovery. If both ends of an SXP connection set up the TCP 312 connection at the same time, the end with source IP address higher 313 than the peer IP address wins: i.e. the TCP connection initiated from 314 that end is kept and the other TCP connection is torn down. 316 3.1.4. SXP Connection Setup Sequence 318 When a SXP connection is configured, it initiates a TCP connection 319 set-up request. SXP communication starts after TCP connection has 320 been established between the two network devices. The end that 321 initiates the TCP connection starts the exchange by sending the OPEN 322 message to negotiate SXP version, SXP mode, and if that end is a 323 listener, SXP capabilities attribute. Capabilities advertisement and 324 Capabilities Attribute are described with additional details in 325 section 5.4.1. The receiving device responds with an OPEN_RESP 326 message that includes similar attributes. The connection can only be 327 set-up with one end configured as a speaker and the other end 328 configured as a listener. See the following sections regarding 329 version negotiation and capability exchange process descriptions. 330 Along with version negotiation, the hold time required for the 331 connection is also negotiated. The following sections explain the 332 hold time negotiation in detail. 334 After SXP connection is established, binding information can be sent 335 from speaker to listener with UPDATE message. Whenever the SXP 336 connection has to be closed the underlying TCP connection is closed. 338 3.1.5. SXP Connection States 340 An SXP connection maintains following states: OFF, PENDING_ON, 341 DELETE_HOLD_DOWN, ON. 343 OFF: In this state, a connection initiation has not been started. 344 This is the only state that an SXP connection will retry establishing 345 the TCP connection. 347 PENDING_ON: In this state, an SXP OPEN message has been sent to the 348 peer and a response from the peer SXP is expected. 350 DELETE_HOLD_DOWN: In this state, a connection that was previously in 351 ON state has been terminated. Only a listener can be in this state. 353 ON: SXP is in ON state when SXP OPEN or SXP OPEN RESP message has 354 been received. SXP connection has been setup successfully. An SXP 355 connection will only propagates bindings in the ON state. 357 +-------+ 358 T7 | |---------------+ 359 +------------>| OFF | |T1 360 | | |<---------+ | 361 | +-------+ T2 | | 362 +--------+ | A +-----v-+ 363 |DELETE | | | |PENDING | 364 |HOLDDOWN| T5| | T4 | ON | 365 +---A----+ | | +--------+ 366 | +-v-----+ | 367 | T6 | ON | |T3 368 +-------------| |<-------------+ 369 +-------+ 371 T1-T7: State Transitions 373 T1: The connection sends a TCP connect request and an SXP OPEN 374 message to the peer. The connection then transits to the PENDING ON 375 state. 377 T2: TCP connection setup failure; 379 T3: The connection received an SXP OPEN RESPONSE or SXP OPEN message. 380 If the delete hold down timer is running, the timer is stopped and 381 the reconciliation timer is started. 383 T4: TCP connection failure; SXP message process failure; SXP 384 configuration change. 386 T5: The TCP connection is setup and an SXP OPEN message is received. 387 If the delete hold down timer is running, the timer is stopped and 388 the reconciliation timer is started. 390 T6: TCP connection failure when a connection is in listener mode. 391 The delete hold down timer is started with this state transition. 393 T7: The delete hold down timer expired or TCP connection setup 394 failure. 396 In failure scenarios, the connection transits to OFF state and an 397 attempt is made to re-establish the connection. 399 3.2. Binding Database 401 A system should have a master binding database for reconciling 402 binding information from multiple SXP connections. The database 403 should consist of a single binding per IP address and there should be 404 a mechanism to handle same bindings from multiple SXP connections. 406 3.2.1. SXP Learned IP-SGT Binding recovery 408 When an SXP connection goes down on a network device, SXP continues 409 to learn/advertise IP-SGT bindings on other SXP connections that are 410 alive. If the device has learnt any bindings from the peer where the 411 SXP connection goes down, a delete hold down timer is started for 412 that connection: 414 o Once the timer expires, all binding entries that were learned from 415 the failed peer are deleted. The deletion of the bindings for 416 which the failed peer was the only source are reported to the 417 master binding database. 419 o If the connection recovers before the delete hold down timer 420 expiry, a reconcile timer is started to clean up old bindings that 421 didn't get informed to be removed because of the loss of 422 connectivity. 424 4. Message Formats 426 The SXP Messages and their formats are described in detail in this 427 section. 429 4.1. Bit and Octet Numbering Convention 431 Throughout this section, the following numbering convention is used 432 to depict the SXP message formats: 434 Each diagram depicts the format and size of each field in bits. 435 Implementations MUST send the bits in each diagram as they are shown, 436 traversing the diagram from top to bottom and then from left to right 437 within each line (which represents a 32-bit quantity). Multi-byte 438 fields representing numeric values must be sent in network (big 439 endian) byte order. Descriptions of bit field (e.g., flag) values 440 are described referring to the position of the bit within the field. 441 These bit positions are numbered from the most significant bit 442 through the least significant bit, so a 1-octet field with only bit 0 443 set has the value 0x80. 445 4.2. SXP Message Header 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 448 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 449 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 451 | SXP Message Length (4 octets) | 452 +---------------------------------------------------------------+ 453 | SXP Message Type (4 octets) | 454 +---------------------------------------------------------------+ 455 | SXP payload (variable) | 456 +---------------------------------------------------------------+ 458 +---------+----------+----------------------------------------------+ 459 | Field | Length | Description | 460 +---------+----------+----------------------------------------------+ 461 | SXP | 4 | This 4-octet unsigned integer indicates the | 462 | Message | | total length of the message, including the | 463 | Length | | header but excluding authentication tag. The | 464 | | | maximum message length is 4096 | 465 | SXP | 4 | This 4-octet unsigned integer indicates the | 466 | Message | | type code of the SXP message. The following | 467 | Type | | type codes are defined: 1 - OPEN 2 - | 468 | | | OPEN_RESP 3 - UPDATE 4 - ERROR 5 - PURGE_ALL | 469 | | | 6 - KEEPALIVE | 470 | SXP | Variable | SXP message payload is an optional field. | 471 | Payload | | Its content when present depends on the | 472 | | | message type | 473 +---------+----------+----------------------------------------------+ 475 4.3. Attribute Formats 477 SXP payloads can contain a variable number of fields. Some fields 478 are fixed and mandatory to support. Other fields are called 479 attributes and they have an extended {Type, Length, Value} (TLV) 480 format in order to allows for gradual introduction of a new feature 481 without requiring a protocol version change. Each attribute is 482 tagged and includes a length field. This allows for newer versions 483 of SXP to add capabilities and co-exist with old versions of SXP in 484 the same deployment. Each attribute includes a Flags field to 485 control processing. The format of an attribute {flags, type, length, 486 value} (TLV) is encoded as follows: 488 Compact TLV 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 491 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 492 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 494 |O|N|P|C|E| | | | Type | TLV Length | | 495 +-+-+-+-+-+-+-+-+---------------+---------------+ | 496 | Value (Variable: TLV Length octets long) | 497 +---------------------------------------------------------------+ 499 Compact Extended Length TLV 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 502 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 503 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 505 |O|N|P|C|E| | | | Type | TLV Extended Length | 506 +-+-+-+-+-+-+-+-+---------------+-------------------------------+ 507 | Value (Variable: TLV Extended Length octets long) | 508 +---------------------------------------------------------------+ 510 Non-Compact TLV 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 513 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 514 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 516 |O|N|P|C| Type | 517 | |T| |0| | 518 +-+-+-+-+-+-+-+-+-----------------------------------------------+ 519 | Non-Compact TLV Length | 520 +---------------------------------------------------------------+ 521 | Value (Variable: Non-Compact TLV Length octets long) | 522 +---------------------------------------------------------------+ 524 +----------------+------+-------------------------------------------+ 525 | Flags | Bits | Description | 526 +----------------+------+-------------------------------------------+ 527 | Optional (O) | 0 | 1 - Attribute is optional and MAY be | 528 | | | ignored 0 - Attribute is mandatory (well- | 529 | | | known and MUST be recognized) | 530 | Non-Transitive | 1 | 0 - Attribute shall be forwarded even if | 531 | (N) | | it is not recognized 1 - Attribute shall | 532 | | | not be forwarded | 533 | Partial (P) | 2 | 1 - When a transitive attribute is | 534 | | | forwarded but not recognized 0 - | 535 | | | Otherwise | 536 | Compact (C) | 3 | 1 - TLV is using compact Type and Length | 537 | | | encoding 0 - TLV is encoded using all the | 538 | | | 4 octets for Type and Length. All other | 539 | | | flags are 0 | 540 | Extended | 4 | 0 - Length is a single octet long 1 - | 541 | Length (E) | | Length is 2 octets long | 542 | Reserved | 5-7 | Reserved for future use. Must be | 543 | | | transmitted as 0 and ignored on receive | 544 +----------------+------+-------------------------------------------+ 546 +--------+----------+-----------------------------------------------+ 547 | Field | Length | Description | 548 +--------+----------+-----------------------------------------------+ 549 | Flags | 1 | Attribute Flags | 550 | Type | 1 or 4 | TLV Type | 551 | Length | 1, 2 or | Length (in octets) of the TLV Value field | 552 | | 4 | (i.e. not including the 3, 4, or 8-octets | 553 | | | attribute header. Unsigned integer in the | 554 | | | following range: [0..255] - For Compact non- | 555 | | | Extended Length attribute. [256..4084] - For | 556 | | | Compact Extended Length attribute. | 557 | Value | Variable | TLV values, which depend on the TLV type | 558 +--------+----------+-----------------------------------------------+ 560 If an optional non-transitive attribute is unrecognized, it is 561 quietly ignored. 563 If an optional transitive attribute is unrecognized, the Partial bit 564 (the third high-order bit) in the attribute flags octet is set to 1, 565 and the attribute is retained for export according to the scope in 566 which the attribute appears. 568 Attribute Length field of Compact attributes SHOULD be only as large 569 as necessary to hold an unsigned integer that specifies the number of 570 octets in the attribute Value field. This implies that Extended- 571 Length field SHOULD contain a value greater than 256 (or the first 572 octet of an Extended-Length field SHOULD be non-zero). The largest 573 allowed value of an Extended-Length field is 4084, considering 574 maximum SXP message length of 4096. The largest allowed value of a 575 non-Compact attribute Length field is thus 4080. SXP Listener MUST 576 accept and process Compact Extended-Length attributes with Length 577 field in the range [0..255] without issuing any errors. In the rest 578 of this document diagrams showing usage of Compact normal and/or 579 Extended-Length attribute are only illustration of expected usage. 580 They do not imply that only the illustrated class of attribute or 581 attribute Length is supported. 583 Attribute Value field consists of well defined sub-fields which are 584 defined in this protocol spec. Attribute Value field MAY contain 585 additional, possibly optional, sub-attributes which are encoded like 586 other attributes. 588 4.4. SXP OPEN and OPEN_RESP Message 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 591 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 592 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 594 | Version (4 octets) | 595 +---------------------------------------------------------------+ 596 | SXP Mode (4 octets) | 597 +---------------------------------------------------------------+ 598 | SXP Node-ID Attribute (7 octets) | 599 +---------------------------------------------------------------+ 600 | Capabilities Attribute (variable) | 601 +---------------------------------------------------------------+ 602 | Other Optional Attributes (variable) | 603 +---------------------------------------------------------------+ 605 +--------------+----------+-----------------------------------------+ 606 | Field | Length | Description | 607 +--------------+----------+-----------------------------------------+ 608 | Version | 4 | Unsigned integer value. The SXP Version | 609 | | | is set to the highest version that is | 610 | | | supported on the network device | 611 | SXP Mode | 4 | Unsigned integer value used to convey | 612 | | | the SXP role that the device uses on | 613 | | | the SXP connection. The following | 614 | | | values are used: 1 - SXP Speaker 2 - | 615 | | | SXP Listener | 616 | SXP Node-Id | 7 | REQUIRED non-transitive attribute (in | 617 | | | SXP version 4 and above) an SXP | 618 | | | Listener SHALL include in OPEN or | 619 | | | OPEN_RESP to convey its unique 32 bits | 620 | | | Node ID. The attribute type used for | 621 | | | Node ID Attribute is 6 | 622 | Capabilities | Variable | REQUIRED non-transitive attribute (in | 623 | | | SXP version 4 and above) an SXP | 624 | | | Listener SHALL include in OPEN or | 625 | | | OPEN_RESP to convey its capabilities | 626 | | | for processing data on the connection | 627 +--------------+----------+-----------------------------------------+ 629 4.4.1. Node-ID 631 In the OPEN message, Node-ID has to be included only by the speaker. 632 The listener must not send the Node-ID in OPEN message and the 633 speaker has to return an error if it receives a Node-ID from a 634 listener. 636 SXP Node-ID with value 0 is reserved for denoting bindings that are 637 received from connections that use older versions of the SXP 638 protocol. 640 The Implementation Note Section has more details on how the Node-ID 641 value is selected. 643 4.4.2. Capabilities Advertisement 645 SXP Listeners are REQUIRED to include the Capabilities attribute when 646 they send an OPEN message or when they respond to such message with 647 OPEN_RESP message. The Capabilities attribute describes the SXP 648 features supported by the Listener. This allows the SXP Speaker to 649 tailor the behavior of the connection to what the Listener could 650 process. An SXP speaker receiving Capabilities attribute from an SXP 651 Listener SHALL NOT send to that listener in UPDATE messages any 652 mandatory attributes that were not indicated as supported in the 653 Capabilities attribute. However, the Listener must be able to 654 process the optional attributes to act as a relay agent. If an SXP 655 speaker receives from its listener peer a capability that it does not 656 itself support or recognize, it MUST ignore that capability. In 657 particular, ERROR message MUST NOT be generated and the SXP session 658 MUST NOT be terminated in response to reception of a capability that 659 is not supported by the local SXP speaker. 661 4.4.2.1. Capabilities Attribute 663 This is a REQUIRED attribute that is used by an SXP Listener to 664 convey to its peer SXP Speaker the list of capabilities supported by 665 the listener. The attribute contains one or more triples : 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 669 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 670 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 672 |O|N|P|C|E| | | | Capabilities |TLV Length (C=1| | 673 | | | | | | | | | Type 6 | EL=0) | | 674 |0|1|0|1| | | | | +---------------+---------------+ 675 | | | | | | | | | |TLV Extended Length (C=1 EL=1) | 676 +-+-+-+-+-+-+-+-+---------------+-------------------------------+ 677 |Cap Code 1 |Cap Length 1 |Reserved | 678 |---------------+---------------+-------------------------------+ 679 | Capability 1 Value (Variable) | 680 +---------------------------------------------------------------+ 681 x ***** x 682 x---------------------------------------------------------------x 683 |Cap Code N |Cap Length N |Reserved | 684 |---------------+---------------+-------------------------------+ 685 | Capability N Value (Variable) | 686 +---------------------------------------------------------------+ 688 +------------+----------+-------------------------------------------+ 689 | Field | Length | Description | 690 +------------+----------+-------------------------------------------+ 691 | Capability | 1 | Unsigned integer that unambiguously | 692 | Code | | identifies individual capabilities | 693 | Capability | 1 | Unsigned integer that contains the length | 694 | Length | | of the Capability Value field in octets | 695 | Capability | Variable | Variable-length field that is interpreted | 696 | Value | | according to the value of the Capability | 697 | | | Code field. Could have zero length | 698 +------------+----------+-------------------------------------------+ 699 The encoding and meaning of the capabilities defines by this version 700 of the SXP protocol spec are as follows: 702 +------------+------------+------------+----------------------------+ 703 | Capability | Capability | Capability | Description | 704 | Name | Code | Length | | 705 +------------+------------+------------+----------------------------+ 706 | IPv4 | 1 | 0 | Listener is capable of | 707 | Unicast | | | receiving and handling | 708 | | | | IPv4 unicast bindings | 709 | IPv6 | 2 | 0 | Listener is capable of | 710 | Unicast | | | receiving and handling | 711 | | | | IPv6 unicast bindings | 712 | Subnet | 3 | 0 | Listener is capable of | 713 | Bindings | | | receiving and handling | 714 | | | | subnet bindings | 715 +------------+------------+------------+----------------------------+ 717 4.4.2.2. Handling of Capabilities Attribute 719 Subnet Bindings - This capability indicates to the speaker that 720 subnet bindings SHOULD be exported as regular bindings without any 721 expansion. A listener that fully supports bindings associated with 722 IP prefixes other than host addresses (IPv4 /32 or IPv6/128) MUST 723 include the Subnet Bindings capability. 725 A listener that does not support subnet bindings in its forwarding 726 path but has the capability to expand subnet bindings locally MUST 727 send Subnet Bindings capability in order to prevent the listener from 728 unnecessarily expanding subnet bindings. A listener which does not 729 support subnet bindings but might be able to support the volume of 730 expanded bindings MAY include Subnet Bindings capabilities. 732 A speaker receiving such capability MAY expand subnet bindings 733 exhaustively or selectively and export individual bindings within a 734 subnet. The expansion of subnet bindings COULD be limited by 735 implementation to a reasonable subnet size with a limit on the total 736 number of bindings expanded. Therefore there could be subnet 737 bindings which are not expanded. 739 When a speaker does not expand a subnet binding it SHOULD export it 740 unmodified as a subnet binding. This will allow the listener to 741 propagate such bindings even when it cannot use it locally. 743 When a speaker expands a subnet binding it MUST NOT export it as both 744 subnet and expanded bindings since the listener or any further SXP 745 peers along the SXP propagation path cannot distinguish expanded 746 bindings from other host bindings and relate them to the subnet 747 bindings they are originate from. 749 IPv6 Unicast - This capability indicates to the speaker that the 750 listener is capable of handling and using bindings associated with 751 IPv6 unicast addresses. A listener that support IPv6 bindings MUST 752 include this capability. When this capability is not included, the 753 speaker MUST NOT send IPv6 bindings as mandatory attributes. A 754 speaker, however, SHOULD send IPv6 bindings within Optional 755 Transitive attributes when the IPv6 Unicast capability is omitted. 756 This will allow an SXP node to relay IPv6 bindings even when it could 757 not process them locally. 759 IPv4 Unicast - This capability should be handled in the same way as 760 IPv6 Unicast capability is handled. It is unlikely for any SXP 761 listener to omit IPv4 Unicast capability at least until pure IPv6 762 networks would become common. 764 4.4.3. Keep-alive and Hold Time Negotiation 766 SXP uses TCP-based, keep-alive mechanism to determine if a connection 767 is live. This mechanism has been used in all prior versions of the 768 protocol. SXP version 4 adds a discretionary negotiated keep-alive 769 mechanism within the protocol itself in order to provide more 770 predictable and timely detection of connection loss. 772 SXP connections are asymmetric with almost all of the protocol 773 messages (except for OPEN/OPEN_RESP and ERROR) being sent from an SXP 774 speaker to an SXP listener. 776 SXP listener could also keep potentially large volume of state per 777 connection which includes all the binding information learnt on a 778 connection. Therefore, it is only meaningful to have a keep-alive 779 mechanism that allows a listener to detect the loss of connection 780 with a speaker. 782 The mechanism is based on two timers: 784 Hold Timer - Used by a listener for detection of elapsing time 785 without successive KEEPALIVE and/or UPDATE messages from a speaker. 787 Keep-alive Timer - Used by a speaker to trigger sending of KEEPALIVE 788 messages during intervals when no other information is exported via 789 UPDATE messages. 791 The keep-alive timer is one-thirds of the negotiated hold-timer 792 value. 794 Hold Timer for the keep-alive mechanism MAY be negotiated during the 795 OPEN/OPEN_RESP exchange at connection setup. 797 o A listener MAY have desirable range for Hold Time period locally 798 configured or a default of [90..180] seconds. A value of 799 [0xFFFF..0xFFFF] implies that the keep-alive mechanism is not 800 used. 802 o A speaker MAY have a minimum acceptable Hold Time period locally 803 configured or a default of 120 seconds. This is the shortest 804 period of time a speaker is willing to send KEEPALIVE messages for 805 keeping the connection alive. Any shorter Hold Time period would 806 require a faster KEEPALIVE rate from the rate the speaker is ready 807 to support. A value of 0xFFFF implies that the keep-alive 808 mechanism is not used 810 o The negotiation succeeds when the speaker's minimum acceptable 811 Hold Time falls below or within the desirable Hold Time range of 812 the listener. If one end turns off the keep-alive mechanism, the 813 other end should also turn it off to make the negotiation success. 815 o The negotiation fails when the speaker's minimum acceptable Hold 816 Time is greater than the upper bound of the listener's Hold Time 817 range. 819 o The selected Hold Time period of a successful negotiation is the 820 maximum of the speaker's minimum acceptable Hold Time and the 821 lower bound of the listener's Hold Time range. 823 o The speaker calculates the Keep-alive Time to 1/3 of the selected 824 Hold Time by default unless a different Keep-alive Time is locally 825 configured. 827 o The negotiation process is designed such that the outcome is the 828 same regardless of the mode of the initiator. 830 The diagram below illustrates the Hold Time negotiation process. 832 +------+ +------+ 833 | Min | | Max | 834 | | | | 835 +------+ +------+ 836 Listener | | 837 | | 838 -----------------V<---------------------------------->V-------- 839 Speaker | | | 840 | | | 841 1| 2| |3 842 +-v---------+ +--v--------+ +--------v---+ 843 | Selected | | Selected | |Unacceptable| 844 | Hold | | Hold | | Hold | 845 | Time | | Time | | Time | 846 | | | | | | 847 +-----------+ +-----------+ +------------+ 849 Connection initiated by Listener 851 o A listener MAY include a Hold-Time Attribute in the OPEN message 852 with minimum and maximum values set to its configured range of 853 Hold Time period. Hold-Time Attribute with just a minimum value 854 set to 0xFFFF would indicate to the speaker that the keep-alive 855 mechanism is not used. 857 o When a speaker received an OPEN message it will react as follows: 859 * If the Hold-Time attribute is not present or if it contains a 860 minimum value that is set to 0xFFFF, the speaker will set its 861 Keepalive Time to 0xFFFF to indicate that keep-alive mechanism 862 is disabled. 864 * If the received Hold-Time attribute contains a valid range, the 865 speaker MUST include Hold-Time attribute in its OPEN_RESP 866 message with a minimum value set as follows: 868 + 0xFFFF if the speaker does not support the keep-alive 869 mechanism or if the mechanism is supported but disabled due 870 to local configuration which sets the Keep-alive Time to 871 0xFFFF 873 + If the speaker's minimum acceptable Hold Time value is 874 greater than the upper bound of the offered range, the 875 speaker MUST send and Open ERROR message with sub-code set 876 to Unacceptable Hold Time and terminate the connection. 878 + Otherwise the speaker's will set the selected Hold Time to 879 the maximum of its minimum acceptable Hold Time value and 880 the lower bound of the offered Hold Time range. 882 + The speaker will calculate a new value for its Keep-alive 883 Time as 1/3 of that selected Hold Time. 885 + The speaker will set the minimum Hold Time value of the Hold 886 Time attribute to the selected Hold Time. 888 o When the listener receives the OPEN_RESP from the speaker it will 889 look for Hold Time Attribute: 891 * If Hold-Time attribute is present and contains a minimum Hold 892 Time value of 0xFFFF. The listener will set its Hold Time 893 value to 0xFFFF to indicate that keep-alive mechanism is not 894 used. 896 * If the minimum Hold Time value is within the range offered by 897 the listener, the listener will set its Hold-Time period to the 898 selected value it has received in the OPEN_RESP. 900 * If the minimum Hold Time value is outside the offered range, 901 the listener will send Open ERROR message with sub-code set to 902 Unacceptable Hold Time and terminate the connection. 904 Connection initiated by Speaker 906 o A speaker MAY include a Hold-Time Attribute in the OPEN message 907 with minimum value set to its minimum acceptable Hold Time period. 908 Hold-Time Attribute with just a minimum value set to 0xFFFF would 909 indicate to the listener that the keep-alive mechanism is not 910 used. 912 o When a listener receives an OPEN message it will react as follows: 914 * If the Hold-Time attribute is not present or if it contains a 915 minimum value that is set to 0xFFFF, the listener will set its 916 Hold Time to 0xFFFF to indicate that keep-alive mechanism is 917 disabled. 919 * If the received Hold-Time attribute contains a valid value, the 920 listener MUST include Hold-Time attribute in its OPEN_RESP 921 message with a minimum value set as follows: 923 + 0xFFFF if the listener does not support the keep-alive 924 mechanism or if the mechanism is supported but disabled due 925 to local configuration which sets the Keep-alive Time to 926 0xFFFF 928 + If the received Hold Time value is greater than the upper 929 bound of the listener's configured Hold Time range, the 930 listener MUST send an Open ERROR message with sub-code set 931 to Unacceptable Hold Time and terminate the connection. 933 + If the received Hold Time value falls within the listener's 934 configured Hold Time range, the listener will make it the 935 selected Hold Time. 937 + If the received Hold Time value is less than the lower bound 938 of the listener's configured Hold Time range, the listener 939 will set the selected Hold Time to the lower bound of its 940 Hold Time range. 942 + The listener will set the minimum Hold Time value of the 943 Hold Time attribute to the selected Hold Time. 945 o When the speaker receives the OPEN_RESP from the listener it will 946 look for Hold Time Attribute: 948 * If Hold-Time attribute is present and contains a minimum Hold 949 Time value of 0xFFFF. The speaker will set its Hold Time value 950 to 0xFFFF to indicate that keep-alive mechanism is not used. 952 * If the received Hold Time value is greater or equal to the 953 speaker minimum acceptable Hold Time, the speaker will 954 calculate a new value for its Keep-alive Time as 1/3 of that 955 received Hold Time. 957 * If the received Hold Time value is lower than the minimum 958 acceptable Hold Time, the speaker MUST send and Open ERROR 959 message with sub-code set to Unacceptable Hold Time and 960 terminate the connection. 962 4.4.3.1. Hold-Time Attribute 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 965 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 966 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 968 |O|N|P|C|E| | | |Hold-Time (7) | TLV Length 2/4|Reserved | 969 +-+-+-+-+-+-+-+-+---------------+-------------------------------+ 970 | Hold Time Minimum Value | Hold Time Maximum Value | 971 +---------------------------------------------------------------+ 973 +-------------------+--------+--------------------------------------+ 974 | Field | Length | Description | 975 +-------------------+--------+--------------------------------------+ 976 | Optional(O) | 1 Bit | Value is 0 | 977 | Non-Transitive(N) | 1 Bit | Value is 0 | 978 | Partial (P) | 1 Bit | Value is 0 | 979 | Compact (C) | 1 Bit | Value is 1 | 980 | Extended Length | 1 Bit | Value is 0 | 981 | (E) | | | 982 | Attribute Type | 1 | Hold-Time (7) | 983 | Attribute Value | 1 | 2 - when only Hold Time Minimum | 984 | Length | | Value is present. 4 - when both Hold | 985 | | | Time Minimum and Maximum values are | 986 | | | present | 987 | Hold Time Minimum | 2 | Unsigned integer indicating the | 988 | Value | | number of seconds the sender | 989 | | | proposes as a lower bound for the | 990 | | | Hold Timer period or the Hold Time | 991 | | | period selected by a responder. 0 or | 992 | | | at least 3 seconds | 993 | Hold Time Maximum | 2 | Unsigned integer indicating the | 994 | Value | | number of seconds the sender | 995 | | | proposes as a upper bound for the | 996 | | | Hold Timer period. MUST be greater | 997 | | | than Hold Time Minimum Value | 998 +-------------------+--------+--------------------------------------+ 1000 Hold-Time is a well-known discretionary attribute an initiator of a 1001 connection MAY include in an OPEN message and a responder MAY be 1002 REQUIRED to include in an OPEN_RESP in order to negotiate the timer 1003 periods used for keep-alive mechanism. The Hold-Time attribute has 1004 to be marked as Non-Transitive and an error has to be returned if 1005 it's not marked as Non-Transitive. 1007 4.5. SXP UPDATE Message 1009 Prior versions of SXP protocol specify that an UPDATE message 1010 contains one or more SXP mappings. This version of SXP protocol 1011 generalizes the UPDATE message. An UPDATE message MAY contain one or 1012 more attributes. Some attributes are well-known and additional 1013 attributes COULD be added in the future without affecting existing 1014 implementations of SXP version 4. This document defines the format 1015 of the attributes used within UPDATE message and how they are 1016 combined to carry the SXP binding information. 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1019 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 1020 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 1021 +---------------------------------------------------------------+ 1022 | Attribute 1 (Variable) | 1023 +---------------------------------------------------------------+ 1024 x ***** x 1025 +---------------------------------------------------------------+ 1026 | Attribute N (Variable) | 1027 +---------------------------------------------------------------+ 1029 4.5.1. UPDATE Attributes 1031 4.5.1.1. IPv4-Delete-Prefix Attribute 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1034 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 1035 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1037 |O|N|P|C|E| | | |IPv4-Delete- | TLV Length |Reserved | 1038 | | | | | | | | | Prefix | C = 1 EL = 0 | | 1039 |0|0|0|1| | | | | Type = 13 +-------------------------------+ 1040 | | | | | | | | | |TLV Extended Length (C=1 EL=1) | 1041 +-+-+-+-+-+-+-+-+---------------+-------------------------------+ 1042 | IPv4 Prefix 1 (Variable) | 1043 +---------------------------------------------------------------+ 1044 x ***** x 1045 +---------------------------------------------------------------+ 1046 | IPv4 N Value (Variable) | 1047 +---------------------------------------------------------------+ 1049 This attribute is used to convey the withdrawal of one or more IPv4 1050 bindings which are unambiguously identified by their IPv4 prefix. 1051 This attribute contains a set of IPv4 prefixes. Each IPv4 prefix is 1052 encoded as a 2-tuple of the form , whose fields are 1053 encoded as: 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1056 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 1057 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1059 | Length = | Reserved | 1060 | [0..32] | | 1061 +---------------+-----------------------------------------------+ 1062 | Prefix | 1063 +---------------------------------------------------------------+ 1064 | 0 < Length | 9 <= Length | 17 <= Length |25 <= Length | 1065 +---------------+---------------+---------------+---------------+ 1067 +--------+------------+---------------------------------------------+ 1068 | Field | Length (in | Description | 1069 | | Octets) | | 1070 +--------+------------+---------------------------------------------+ 1071 | Length | 1 | Unsigned integer. The length in bits of the | 1072 | | | IP address prefix. A length of zero | 1073 | | | indicates a prefix that matches all IP | 1074 | | | addresses (with Prefix field filled with | 1075 | | | zero in all octets) | 1076 | Prefix | Variable | An IP address prefix, followed by the | 1077 | | (Length/8) | minimum number of trailing bits needed to | 1078 | | | make the end of the field fall on an octet | 1079 | | | boundary. The value of trailing bits is | 1080 | | | irrelevant | 1081 +--------+------------+---------------------------------------------+ 1083 4.5.1.2. IPv6-Delete-Prefix Attribute 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1086 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 1087 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1089 |O|N|P|C|E| | | |IPv4-Delete- | TLV Length |Reserved | 1090 | | | | | | | | | Prefix | C = 1 EL = 0 | | 1091 |0|0|0|1| | | | | Type = 14 +-------------------------------+ 1092 | | | | | | | | | |TLV Extended Length (C=1 EL=1) | 1093 +-+-+-+-+-+-+-+-+---------------+-------------------------------+ 1094 | IPv6 Prefix 1 (Variable) | 1095 +---------------------------------------------------------------+ 1096 x ***** x 1097 +---------------------------------------------------------------+ 1098 | IPv6 N Value (Variable) | 1099 +---------------------------------------------------------------+ 1101 This attribute is used to convey the withdrawal of one or more IPv6 1102 bindings which are unambiguously identified by their IPv6 prefix. 1103 This attribute contains a set of IPv6 prefixes. Each IPv6 prefix is 1104 encoded as a 2-tuple of the form , whose fields are 1105 encoded as: 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1108 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 1109 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1111 | Length = | Reserved | 1112 | [0..128] | | 1113 +---------------+-----------------------------------------------+ 1114 | Prefix[1..4] | 1115 +---------------------------------------------------------------+ 1116 | 0 < Length | 9 <= Length | 17 <= Length |25 <= Length | 1117 +---------------+---------------+---------------+---------------+ 1118 | Prefix[5..8] | 1119 +---------------------------------------------------------------+ 1120 | 33 < Length | 41 <= Length | 49 <= Length |57 <= Length | 1121 | | | | | 1122 +---------------+---------------+---------------+---------------+ 1123 | Prefix[9..12] | 1124 +---------------------------------------------------------------+ 1125 | 65 < Length | 73 <= Length | 81 <= Length |89 <= Length | 1126 +---------------+---------------+---------------+---------------+ 1127 | Prefix[13..16] | 1128 +---------------------------------------------------------------+ 1129 | 97 < Length | 105 <= Length | 113 <= Length |121 <= Length | 1130 +---------------+---------------+---------------+---------------+ 1132 +--------+------------+---------------------------------------------+ 1133 | Field | Length (in | Description | 1134 | | Octets) | | 1135 +--------+------------+---------------------------------------------+ 1136 | Length | 1 | Unsigned integer. The length in bits of the | 1137 | | | IP address prefix. A length of zero | 1138 | | | indicates a prefix that matches all IP | 1139 | | | addresses (with Prefix field filled with | 1140 | | | zero in all octets) | 1141 | Prefix | Variable | An IP address prefix, followed by the | 1142 | | (Length/8) | minimum number of trailing bits needed to | 1143 | | | make the end of the field fall on an octet | 1144 | | | boundary. The value of trailing bits is | 1145 | | | irrelevant | 1146 +--------+------------+---------------------------------------------+ 1148 4.5.1.3. Peer-Sequence Attribute 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1150 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 1151 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1153 |O|N|P|C|E| | | |Peer-Sequence | TLV Length | Reserved | 1154 |0|0|0|1|0| | | | Type = 16 | 4 * N | | 1155 +-+-+-+-+-+-+-+-+---------------+-------------------------------+ 1156 | SXP ID 1 | 1157 +---------------------------------------------------------------+ 1158 | SXP ID 2 | 1159 +---------------------------------------------------------------+ 1160 x ***** x 1161 +---------------------------------------------------------------+ 1162 | SXP ID N | 1163 +---------------------------------------------------------------+ 1165 This attribute contains the SXP nodes through which exported bindings 1166 has traversed. Each SXP node is identified by a 4 octet SXP ID. SXP 1167 ID MUST be unique for every SXP node in an SXP deployment. As 1168 exported bindings are propagated by an SXP Speaker, the speaker SHALL 1169 prepend its own SXP ID to the sequence of SXP IDs of the Peer- 1170 Sequence attribute that was received by an SXP Listener on the same 1171 node. If the exported binding is originated by the local node, the 1172 Peer-Sequence will contain a single SXP ID identifying the local 1173 node. When an UPDATE message is received by an SXP Listener, the 1174 first SXP ID within each Peer-Sequence attribute is the SXP node ID 1175 of the SXP Speaker on the remote end of the connection the message is 1176 received on. The last SXP ID is the node ID of the SXP Speaker that 1177 originates the bindings associated with a Peer-Sequence attribute. 1178 UPDATE message SHALL contain one Peer-Sequence attribute and MAY 1179 contain multiple Peer-Sequence attributes. Each Peer-Sequence 1180 attribute is associated with the bindings that follow it up to the 1181 next Peer-Sequence attribute if more than one Peer-Sequence attribute 1182 is present or up to the end of the UPDATE message. 1184 4.5.1.4. Source-Group-Tag Attribute 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1187 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 1188 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1190 |O|N|P|C|E| | | |SGT Type = 17 | TLV Length 2 | Reserved | 1191 |0|0|0|1|0| | | | Group Tag | 2 | | 1192 +-+-+-+-+-+-+-+-+---------------+---------------+---------------+ 1193 | SGT Value | Reserved | 1194 +-------------------------------+-------------------------------+ 1196 +-------------------+-----------------+-----------------------------+ 1197 | Field | Length (in | Description | 1198 | | Octets) | | 1199 +-------------------+-----------------+-----------------------------+ 1200 | Attribute Type | 1 | Scalable-Group-Tag (17) | 1201 | Attribute Value | 1 | | 1202 | Length | | | 1203 | SGT Value | 2 | Unsigned integer value of | 1204 | | | an SGT | 1205 +-------------------+-----------------+-----------------------------+ 1207 4.5.1.5. IPv4-Add-Prefix Attribute 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1210 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 1211 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1213 | | | | | | | | |IPv4-Add-Prefix|TLV Length (C=1| Reserved | 1214 |O|N|P|C|E| | | | Type = 11 | EL=0) | | 1215 | | | | | | | | | +---------------+---------------+ 1216 |0|0|0|1| | | | | |TLV Extended Length (C=1 EL=1) | 1217 +-+-+-+-+-+-+-+-+---------------+-------------------------------+ 1218 | IPv4 Prefix 1 (Variable) | 1219 +---------------------------------------------------------------+ 1220 x ***** x 1221 |---------------------------------------------------------------+ 1222 | IPv4 N Value (Variable) | 1223 +---------------------------------------------------------------+ 1225 This attribute is used to convey the binding of one or more IPv4 1226 prefixes with an SGT value or other information. The encoding of 1227 each IPv4 prefix is described above in IPv4-Delete-Prefix Attribute 1228 section. 1230 The unbundling of IP prefixes from the information associated with 1231 them achieves two major objectives: 1233 o Allows for efficient sharing of common attributes such as Peer- 1234 Sequence, and Scalable-Group-Tag with multiple IP prefixes. 1236 o Allows for future introduction of new information for association 1237 with IP prefixes via optional attributes. 1239 The associated SGT is the value specified by the latest preceding 1240 occurrence of Scalable-Group-Tag attribute within the same UPDATE 1241 message. An IPv4-Add-Prefix attribute SHALL be preceded with an 1242 occurrence of Peer-Sequence attribute. The latest preceding 1243 occurrence provides the path along which the bindings of all the 1244 prefixes contained in the IPv4-Add-Prefix have been traversed. 1246 4.5.1.6. IPv6-Add-Prefix Attribute 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1249 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 1250 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1252 | | | | | | | | |IPv6-Add-Prefix|TLV Length (C=1| Reserved | 1253 |O|N|P|C|E| | | | Type = 12 | EL=0) | | 1254 | | | | | | | | | +---------------+---------------+ 1255 |0|0|0|1| | | | | |TLV Extended Length (C=1 EL=1) | 1256 +-+-+-+-+-+-+-+-+---------------+-------------------------------+ 1257 | IPv6 Prefix 1 (Variable) | 1258 +---------------------------------------------------------------+ 1259 x ***** x 1260 |---------------------------------------------------------------+ 1261 | IPv6 N Value (Variable) | 1262 +---------------------------------------------------------------+ 1264 This attribute is used to convey the binding of one or more IPv6 1265 prefixes with an SGT value or other information. The encoding of 1266 each IPv6 prefix is described above in IPv6-Delete-Prefix Attribute 1267 section. The handling of this attribute and its relationship with 1268 preceding attributes such as Peer-Sequence or Scalable-Group-Tag are 1269 the same as what is described above in IPv4-Add-Prefix section except 1270 for a different attribute type (12) and possibly longer IPv6 1271 prefixes. 1273 4.5.1.7. IPv4-Add-Table Attribute 1275 This attribute provides a flexible tabular representation of bindings 1276 information. It is provided for efficient aggregation of multiple 1277 bindings information when an implementation cannot aggregate multiple 1278 IP prefixes that are associated with the same SGT or other common 1279 attributes. 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1282 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 1283 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1285 |O|N|P|C|E| | | | IPv4-Add-Table| TLV Length | Reserved | 1286 |0|0|0|1| | | | | Type = 21 | (C = 1 EL = 0)| | 1287 | | | | | | | | | |-------------------------------+ 1288 | | | | | | | | | | TLV Extended Length (C=1 EL=1)| 1289 +-+-+-+-+-+-+-+-+---------------+---------------+---------------+ 1290 | Number of | Reserved | 1291 | Columns C | | 1292 +---------------+---------------+---------------+---------------+ 1293 |'1'Column Type | '1'Column Type| '1'Column |'2'Column Type | 1294 | Flags | | Width | Flags | 1295 +---------------+---------------+---------------+---------------+ 1296 |'2'Column Type | '2'Column | | 1297 | | Width | *** | 1298 +---------------+---------------+---------------+---------------+ 1299 x *** x 1300 +---------------+---------------+---------------+---------------+ 1301 |'C'Column Type | 'C'Column Type| 'C'Column | Reserved | 1302 | Flags | | Width | | 1303 +---------------+---------------+------------------------------+--+ 1304 | '1''1' Value | *** |'1''C'Value |'1'IPv4 Prefix | 1305 | | *** | | (Variable) | 1306 +---------------+---------------+---------------+-----------------+ 1307 x *** x *** x *** x *** x 1308 x *** x *** x *** x *** x 1309 x---------------+---------------+---------------+-----------------x 1310 | 'R''1' Value | *** |'R''C'Value |'R'IPv4 Prefix | 1311 | | *** | | (Variable) | 1312 +---------------+---------------+---------------+-----------------+ 1314 +---------+----------+----------------------------------------------+ 1315 | Field | Bits | Description | 1316 +---------+----------+----------------------------------------------+ 1317 | Number | 1 | 1 - Unsigned integer which specifies the | 1318 | of | | number of columns of information (not | 1319 | Columns | | including the trailing IP prefix) associated | 1320 | | | with each prefix | 1321 | [i] | 1 | 0 - An Attribute Type Flags value defining | 1322 | Column | | the flag of the attribute in the I'th column | 1323 | Type | | on each row | 1324 | Flags | | | 1325 | [i] | 1 | 1 - An Attribute Type value defining what | 1326 | Column | | each row have in the i'th column position | 1327 | Type | | | 1328 | [i] | 1 | 1 - The length in octets of the attribute | 1329 | Column | | value in the i'th column on each row | 1330 | Width | | | 1331 | [j] | Variable | 0 - An IP prefix which is associated with | 1332 | IPv4 | | the C-tuple of attribute values on the j'th | 1333 | Prefix | | row of the table. The format of is the same | 1334 | | | as the IP prefix field in the IPv4-Add- | 1335 | | | Prefix attribute | 1336 +---------+----------+----------------------------------------------+ 1338 Below is an example of an IPv4-Add-Table attribute which contain a 1339 single SGT attribute value on each row. 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1342 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 1343 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1345 |O|N|P|C|E| | | | IPv4-Add- | TLV Length | Reserved | 1346 | | | | | | | | | Table | (C = 1 EL = 0)| | 1347 |0|0|0|1| | | | | Type = 21 |-------------------------------+ 1348 | | | | | | | | | | TLV Extended Length (C=1 EL=1)| 1349 +-+-+-+-+-+-+-+-+---------------+---------------+---------------+ 1350 | Number of | Reserved | 1351 | Columns 1 | | 1352 +-------------------------------+-------------------------------+ 1353 |Scalable-Group | Column | Reserved | 1354 | Tag Type = 17 | Width = 2 | | 1355 +-------------------------------+-------------------------------+--+ 1356 | '1'SGT Value |'1'Prefix |'1'IPv4 Prefix | 1357 | | Length | | 1358 +-------------------------------+---------------+------------------+ 1359 x *** x *** x *** x 1360 x-------------------------------+---------------+------------------x 1361 | 'R'SGT Value |'R'Prefix |'R'IPv4 Prefix | 1362 | | Length | | 1363 +-------------------------------+---------------+------------------+ 1365 4.5.1.8. IPv6-Add-Table Attribute 1367 This attribute provides a flexible tabular representation of IPv6 1368 bindings information. 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1371 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 1372 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1374 |O|N|P|C|E| | | | IPv6-Add- | TLV Length | Reserved | 1375 | | | | | | | | | Table | (C = 1 EL = 0)| | 1376 |0|0|0|1| | | | | Type = 22 |-------------------------------+ 1377 | | | | | | | | | | TLV Extended Length (C=1 EL=1)| 1378 +-+-+-+-+-+-+-+-+---------------+-------------------------------+ 1379 | Number of | Reserved | 1380 | Columns C | | 1381 +---------------+---------------+---------------+---------------+ 1382 |'1'Column Type | '1'Column Type| '1'Column |'2'Column Type | 1383 | Flags | | Width | Flags | 1384 +---------------+---------------+---------------+---------------+ 1385 |'2'Column Type | '2'Column | | 1386 | | Width | *** | 1387 +---------------+---------------+---------------+---------------+ 1388 x *** x 1389 +---------------+---------------+---------------+---------------+ 1390 |'C'Column Type | 'C'Column Type| 'C'Column | Reserved | 1391 | Flags | | Width | | 1392 +---------------+---------------+-------------------------------+--+ 1393 | '1''1' Value | *** |'1''C'Value |'1'IPv6 Prefix | 1394 | | *** | | (Variable) | 1395 +---------------+---------------+---------------+------------------+ 1396 x *** x *** x *** x *** x 1397 x---------------+---------------+---------------+------------------x 1398 | 'R''1' Value | *** |'R''C'Value |'R'IPv6 Prefix | 1399 | | *** | | (Variable) | 1400 +---------------+---------------+---------------+------------------+ 1402 The format and handling of IPv6-Add-Table attribute are the same as 1403 what is described above in IPv4-Add-Table section except that the 1404 attribute type (22) is used and the trailing IPv6 Prefix field in 1405 each row could be potentially longer than the corresponding trailing 1406 IPv4 Prefix fields. 1408 4.5.2. UPDATE Message Samples 1410 Single IPv4 host binding as exported by the first Speaker away from 1411 the originating node: 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1414 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 1415 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+------ 1417 | SXP Message Length = 32 |SXP 1418 +---------------------------------------------------------------+Msg 1419 | SXP Message Type = UPDATE (3) |Header 1420 +---------------------------------------------------------------+------ 1421 |O|N|P|C|E| | | |Peer-Sequence | TLV Length | Reserved | 1422 |0|0|0|1|0| | | | Type = 16 | 8 | | 1423 +-+-+-+-+-+-+-+-+---------------+-------------------------------+Peer- 1424 | Local SXP ID |Seq- 1425 | |Attr 1426 +---------------------------------------------------------------+ 1427 |SXP ID of Speaker end of the connection on which it was | 1428 | originally received | 1429 +---------------------------------------------------------------+----- 1430 |O|N|P|C|E| | | |Scalable-Group-| TLV Length | Reserved | 1431 | | | | | | | | | Tag | 2 | |Src- 1432 |0|0|0|1|0| | | | Type = 17 | | |Grp- 1433 +-+-+-+-+-+-+-+-+---------------+-------------------------------+Tag 1434 | SGT Value = | Reserved |Attr 1435 | | | 1436 +---------------------------------------------------------------+----- 1437 |O|N|P|C|E| | | |IPv4-Add-Prefix| TLV Length |Prefix Length |IPv4- 1438 | | | | | | | | | Type = 11 | 5 | 32 |Add- 1439 |0|0|0|1|0| | | | | | |Pre- 1440 +-+-+-+-+-+-+-+-+---------------+-------------------------------+fix 1441 | IPv4 Host Address |Attr 1442 +---------------------------------------------------------------+----- 1444 Multiple IPv4 host and subnet bindings sharing the same Peer-Sequence 1445 as exported by the first Speaker away from the originating node. 11 1446 subnets bindings of length between 17 and 24 and as many host 1447 bindings as SXP total message size allowed are packed into this 1448 message: 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1451 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 1452 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+------ 1454 | SXP Message Length = 4096 |SXP 1455 +---------------------------------------------------------------+Msg 1456 | SXP Message Type = UPDATE (3) |Header 1457 +---------------------------------------------------------------+------ 1458 |O|N|P|C|E| | | |Peer-Sequence | TLV Length | Reserved | 1459 |0|0|0|1|0| | | | Type = 16 | 8 | | 1460 +-+-+-+-+-+-+-+-+---------------+-------------------------------+Peer- 1461 | Local SXP ID |Seq- 1462 | |Attr 1463 +---------------------------------------------------------------+ 1464 |SXP ID of Speaker end of the connection on which it was | 1465 | originally received | 1466 +---------------------------------------------------------------+----- 1467 |O|N|P|C|E| | | |IPv4-Add-Table | TLV Length | Reserved |IPv4- 1468 | | | | | | | | | |3 + 11x6 +572x7| |Add- 1469 |0|0|0|1|0| | | | Type = 21 | = 4073 | |Table 1470 +-+-+-+-+-+-+-+-+---------------+-------------------------------+Attri- 1471 |Number of | Reserved |-bute 1472 |Columns 1 | | 1473 +---------------------------------------------------------------+------ 1474 |Scalable | Column | Reserved |Col 1475 |Group Tag | Width = 2 | |Head 1476 |Type = 17 | | |ers 1477 +-+-+-+-+-+-+-+-+---------------+-------------------------------+------ 1478 | '1' SGT Value |'1'Prefix | Reserved | 1479 | |Length = | | 1480 | | [17..24] | | 1481 |-------------------------------+---------------+---------------+ 1482 | '1' IPv4 Subnet Prefix | Reserved |Subnet 1483 +-----------------------------------------------+---------------+Bind- 1484 * * |ings 1485 * * Reserved |Rows 1486 * '2..10' rows * | 1487 +-----------------------------------------------+---------------+ 1488 | '11' SGT Value |'11'Prefix | Reserved | 1489 | |Length = | | 1490 | | '17..24' | | 1491 |-------------------------------+---------------+---------------+ 1492 | '11' IPv4 Subnet Prefix | Reserved | 1493 +-----------------------------------------------+---------------+---- 1494 | '1' SGT Value |'1'Prefix | Reserved | 1495 | |Length = 32 | | 1496 |-------------------------------+---------------+---------------+ 1497 | '1'IPv4 Host Address | 1498 +-----------------------------------------------+---------------+ 1499 x | Reserved |Host 1500 x '2..571' | |Bind- 1501 x +---------------+ing 1502 x |Rows 1503 x---------------------------------------------------------------+ 1504 | '572' SGT Value |'572'Prefix | Reserved | 1505 | |Length = 32 | | 1506 +-------------------------------+---------------+---------------+ 1507 | '572'IPv4 Host Address | 1508 +---------------------------------------------------------------+----- 1510 4.6. SXP ERROR Message 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1513 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 1514 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 1516 | | 0 (E=0) | 0 (E=0) | non-Extended Error Code (E=0)| 1517 |E+-------------+---------------+-------------------------------| 1518 | |Error Code |Error Sub-code | | 1519 | | (E=1) | (E=1) | | 1520 +-+-----------------------------+ | 1521 | Data (Variable) | 1522 +---------------------------------------------------------------+ 1524 +--------------+--------+----------+--------------------------------+ 1525 | Field | Bits | Length | Description | 1526 | | | (in | | 1527 | | | Octets) | | 1528 +--------------+--------+----------+--------------------------------+ 1529 | Extended | 0 | | 1 - Extended Error format, | 1530 | | | | which includes code, sub-code, | 1531 | | | | and variable data 0 - Legacy | 1532 | | | | non-Extended Error | 1533 | Error Code | [1..7] | 0 | Unsigned integer in the range | 1534 | | | | [0..127] - indicates the type | 1535 | | | | of ERROR | 1536 | Error Sub- | | 1 | Unsigned integer in the range | 1537 | Code | | | [0..255] - Provides extended | 1538 | | | | information about the nature | 1539 | | | | of the reported error. Each | 1540 | | | | Error code may have one or | 1541 | | | | more Error Sub-codes | 1542 | | | | associated with it. If no | 1543 | | | | appropriate Error Sub-code is | 1544 | | | | defined, then zero | 1545 | | | | (Unspecified) value is used | 1546 | non-Extended | | 2 | Error code values: 0 - No | 1547 | Error Code | | | error 1 - Version Mismatch 2 - | 1548 | | | | Message Parse Error | 1549 | Data | | Variable | Additional data for diagnosing | 1550 | | | Message | the reason for the ERROR | 1551 | | | Length - | message. The content depends | 1552 | | | 10 | on the values of Error Code | 1553 | | | | and Error Sub-code | 1554 +--------------+--------+----------+--------------------------------+ 1556 4.6.1. Error Codes 1558 +-----------+-----------+-------------------------------------+ 1559 | Error | Error | Symbolic Name | 1560 | Code | Sub-code | | 1561 +-----------+-----------+-------------------------------------+ 1562 | 1 | - | Message Header Error | 1563 | | | | 1564 +-----------+-----------+-------------------------------------+ 1565 | 2 | - | OPEN Message Error | 1566 | | | | 1567 +-----------+-----------+-------------------------------------+ 1568 | 3 | - | UPDATE Message Error | 1569 | | | | 1570 +-----------+-----------+-------------------------------------+ 1571 | | 1 | Malformed Attribute List | 1572 | | | | 1573 + +-----------+-------------------------------------+ 1574 | | 2 | Unexpected Attribute | 1575 | | | | 1576 + +-----------+-------------------------------------+ 1577 | | 3 | Missing Well-known Attribute | 1578 | | | | 1579 + +-----------+-------------------------------------+ 1580 | | 4 | Attribute Flags Error | 1581 | | | | 1582 + +-----------+-------------------------------------+ 1583 | | 5 | Attribute Length Error | 1584 | | | | 1585 + +-----------+-------------------------------------+ 1586 | | 6 | Malformed Attribute | 1587 | | | | 1588 + +-----------+-------------------------------------+ 1589 | | 7 | Optional Attribute Error | 1590 | | | | 1591 + +-----------+-------------------------------------+ 1592 | | 8 | Unsupported Version Number | 1593 | | | | 1594 + +-----------+-------------------------------------+ 1595 | | 9 | Unsupported Optional Attribute | 1596 | | | | 1597 + +-----------+-------------------------------------+ 1598 | | 10 | Unacceptable Hold Time | 1599 | | | | 1600 +-----------+-----------+-------------------------------------+ 1602 The error codes and the error sub-codes are used to interpret the 1603 type of error and the specific attributes that have caused the error 1604 need not be sent back with the error message. 1606 4.7. SXP PURGE-ALL Message 1608 There is no payload corresponding to this message type. 1610 When an SXP connection on which the local SXP node is a speaker is 1611 administratively deleted, SXP MUST send a PURGE-ALL message to the 1612 SXP listener at the remote end. This will provide the speaker timely 1613 knowledge that the connection is about to be torn down and that it is 1614 not an intermittent loss of communication. The listener will 1615 immediately delete all bindings that were received on that connection 1616 and will not go through Delete Hold-Down timer before removal of 1617 bindings. 1619 When SXP feature gets administratively disabled, SXP MUST send PURGE- 1620 ALL message on all the connections on which the local end is a 1621 speaker. 1623 Upon receiving a PURGE-ALL message, an SXP speaker MUST immediately 1624 delete all the bindings that were received on that connection. 1625 PURGE-ALL message should have the same effect as an UPDATE message 1626 with IPv4-Delete-Prefix or IPv6-Delete-Prefix attributes that contain 1627 all bindings which has been exported on the connection. A PURGE-ALL 1628 is simply an optimization of such delete at-once case. 1630 4.8. SXP KEEPALIVE Message 1632 There is no payload corresponding to this message type. This message 1633 is sent by the speaker to the listener side when KEEPALIVE timer 1634 expires. 1636 5. Update Message Handling 1638 An SXP UPDATE message may be received only in the ON state. 1639 Receiving an UPDATE message in any other state is an error. When an 1640 UPDATE message is received, each field is checked for validity. 1642 5.1. UPDATE Message Validation 1644 UPDATE message SHALL be organized as illustrated below: 1646 +-------------------------------------------------------------+ 1647 |Zero or more global optional attributes which are unrelated | 1648 |to any of the binding delete or add attributes or groups | 1649 | below them | 1650 +-------------------------------------------------------------+ 1651 |At most one each IPv4-Delete-Prefix or IPv6-Delete-Prefix | 1652 +-------------------------------------------------------------+ 1653 |Zero or more Del-IPv4 or Del-IPv6 (non-zero only when neither| 1654 | IPv4-Delete-Prefix nor IPv6-Delete-Prefix are present) | 1655 +-------------------------------------------------------------+ 1657 All errors detected while processing the UPDATE message MUST be 1658 indicated by sending the ERROR message with the Error Code UPDATE 1659 Message Error to the SXP speaker from which the UPDATE message was 1660 received. The Error Sub-code provides additional information about 1661 the error. UPDATE message is a sequence of attributes. Attributes 1662 could be further classified as compact, compact with extended length, 1663 or non-compact attributes. Each attribute consists of a fixed-size 1664 header, 3, 4, or 8 octets long respectively, which contains TLV 1665 Length field. The total length of each attribute is thus: Attribute 1666 Length = 3/4/8 + TLV Length If the length of any attribute is larger 1667 than the SXP Message length or the sum of Attribute Length of all 1668 attributes is larger than the SXP Message length, the Error Sub-code 1669 MUST be set to Malformed Attribute List. If any recognized attribute 1670 has Attribute Flags that conflicts with its Attribute Type, then the 1671 Error Sub-code MUST be set to Attribute Flags Error. The Data field 1672 MUST contain the erroneous attribute (flags, type, length, and 1673 value). If any recognized attribute has Attribute Length that 1674 conflicts with the expected length (based on its Attribute Type), 1675 then the Error Sub-code MUST be set to Attribute Length Error. The 1676 Data field MUST contain the erroneous attribute (flags, type, length, 1677 and value). 1679 If any recognized attribute does not conform to the attribute 1680 specification in UPDATE Attributes section, then Error Sub-code MUST 1681 be set to Malformed Attribute. The Data field MUST contain the 1682 erroneous attribute (flags, type, length, and value). Cases of 1683 malformed attributes: 1685 o IP Prefix length field is outside of the permitted range 1686 [0..32]/[0..128] for IPv4/IPv6 respectively. 1688 o Implied length of IP Prefix field which extends the prefix beyond 1689 the extent of the containing attribute. 1691 If any attribute appears more than once when at most one occurrence 1692 is permitted then the Error Sub-code MUST be set to Malformed 1693 Attribute List. 1695 If any attribute appears in a location where it is not expected (such 1696 as IPv4-Add-Prefix/IPv6-Add-Prefix without preceding Scalable-Group- 1697 Tag) then the Error Sub-code MUST be set to Malformed Attribute List. 1699 If an optional non-transitive attribute is unrecognized, it is 1700 quietly ignored. 1702 If an optional transitive attribute is unrecognized, the Partial bit 1703 (the third high-order bit) in the attribute flags octet is set to 1, 1704 and the attribute is retained for export according to the scope in 1705 which the attribute appears. A global attribute is exported along 1706 every binding specified in this UPDATE message on all connections for 1707 which the local peer is a speaker. A path attribute is exported 1708 along the bindings from a single path. A per 1709 attribute is exported along bindings received from a single path 1710 which share a single Scalable-Group-Tag attribute. If an optional 1711 attribute is recognized and has a valid value, then, depending on the 1712 type of the optional attribute, it is processed locally, retained, 1713 and updated, if necessary, for possible export to listener peers. A 1714 Peer-Sequence attributes is checked for syntactic correction. If the 1715 path is syntactically incorrect (e.g. length is not a multiple of 4), 1716 then an ERROR message MUST be sent to the speaker with Error Sub-code 1717 set to Malformed Attribute. SXP listener learns the SXP Node-ID from 1718 the SXP Node-ID in the OPEN or OPEN_RESP it receives at connection 1719 establishment. This Node-ID is used to validate subsequent Peer- 1720 Sequence attributes from the same peer. SXP MUST check whether the 1721 leftmost (with respect to the position of octets in the protocol 1722 message) SXP Node-ID in the Peer-Sequence is equal to the SXP Node-ID 1723 of the peer that sent the UPDATE message. If the checks determines 1724 that this is not the case, then an ERROR message MUST be sent to the 1725 speaker with Error Sub-code set to Malformed Attribute. 1727 5.2. UPDATE Message processing 1729 Processing of an UPDATE message by an SXP listener follows the 1730 organization of the message according to the following high level 1731 steps: 1733 1. UPDATE Message validation as described in section 5.1. 1735 2. Processing of global optional attributes. 1737 3. Processing of binding delete attributes. Binding delete 1738 attributes include any of IPv4-Del-Prefix, IPv6-Del-Prefix, Del- 1739 IPv4, or Del-IPv6 attributes. 1741 4. Processing path-groups. 1743 A. Process per-path common optional attributes 1745 B. Add-Prefix groups. Each Add-Prefix group starts with a 1746 Scalable-Group-Tag attribute. 1748 i. Process per optional attributed. 1750 ii. Process IPv4-Add-Prefix attribute 1752 iii. Process IPv6-Add-Prefix attribute 1754 C. Processing IPv4-Add-Table attribute 1756 D. Processing IPv6-Add-Table attribute 1758 E. Processing Add-IPv4 attributes 1760 F. Processing Add-IPv6 attributes 1762 5. Processing trailing optional non-transitive attributes 1764 Each path-group starts with an instance of Peer-Sequence attribute. 1766 Processing Binding Delete Attributes (step 3) 1768 If the UPDATE message contains a non-empty IPv4-Del-Prefix/IPv6-Del- 1769 Prefix or one or more Del-IPv4/Del-IPv6 attributes, the previously 1770 received bindings from the remote speaker peer, whose IP/IPv6 1771 addresses are contained in any of those attributes, SHALL be removed 1772 from the SXP input bindings database. Additional processing of a 1773 deleted binding depends on whether it was the SXP contributed binding 1774 for its IPv4/IPv6 address and whether it was the selected and 1775 exported binding by the master binding data-base: 1777 o Non-contributed binding - No further processing is needed. 1779 o Contributed but not exported - The binding was the preferred 1780 binding by SXP and was reported to the master binding database. 1781 However, the binding was not exported by SXP due to higher 1782 priority contributors in the master binding database. SXP SHALL 1783 select a new contribution for the IPv4/IPv6 address of the deleted 1784 binding from the input bindings database, and, upon change of SGT 1785 or other associated data that are reported to the master bindings 1786 database, report the newly selected binding to the master binding 1787 database. The newly selected contribution will not affect the 1788 exported binding since this is a non-contributed binding that was 1789 not exported to the master binding database. 1791 o Contributed and Exported - The binding was the preferred binding 1792 by SXP and was the selected binding for the IPv4/IPv6 address by 1793 the master binding database. SXP contribution was either the only 1794 binding contributor or the highest priority contributor. 1796 SXP SHALL select a new contribution for the IPv4/IPv6 address of the 1797 deleted binding among the bindings for that address from other peers. 1799 SXP SHALL apply the following rules for selecting a binding for 1800 reporting to the master binding database: 1802 1. Shortest Path rule 1804 Choose a binding which has the shortest Peer-Sequence among all the 1805 bindings for the same IP address. A binding received without Peer- 1806 Sequence attribute (i.e. from an earlier version speaker) is 1807 considered as being received with a Peer-Sequence that contains a 1808 single NULL SXP Node-ID (value 0). 1810 1. Most Recently Received rule 1812 If there are more than one bindings with the shortest Peer-Sequence, 1813 the binding which has been most recently received is selected. 1815 If the deleted binding was the only binding for its IP address in the 1816 SXP input binding database, SXP SHALL report it to the master binding 1817 database. The external outcome when no other contributors to the 1818 same IP address is present, is that a deletion of the binding using 1819 IPv4-Del-Prefix/IPv6-Del-Prefix or Del-IPv4/Del-IPv6 attribute MUST 1820 be exported on all connections on which the local end is a speaker. 1822 If there is one or more additional contributors in the master binding 1823 database, a new binding is selected and it MUST be exported using 1824 IPv4-Add-Prefix/IPv6-Add-Prefix, IPv4-Add-Table/IPv6-Add-Table, or 1825 Add-IPv4/Add-IPv6 and associated with a Peer-Sequence that includes 1826 only the SXP Node ID of the local instance. 1828 If the binding selection rule has yielded a newly selected binding 1829 from SXP input binding database it SHALL be compared to the binding 1830 it is replacing, and 1832 o upon change of SGT, or, other associated data that are reported to 1833 the master binding database, report the newly selected binding to 1834 the master binding database. The newly selected contribution will 1835 become the selected contribution and will trigger export. 1837 o If the SGT of the newly selected binding, and all other associated 1838 data that are reported to the master binding database, remain the 1839 same as those of the deleted binding, SXP SHOULD NOT report a new 1840 contribution to the master binding database. However, the newly 1841 selected binding has a different Peer-Sequence attribute because 1842 binding from a different peer is selected. There could also be 1843 changes in optional transitive attributes. SXP SHALL export the 1844 newly selected binding directly and include all transitive 1845 attributes, thus bypassing the usual notification path from the 1846 master bindings database. 1848 Processing Binding Add Attributes (step 4) 1850 I. Implicit delete of current bindings 1852 If the UPDATE message contains a non-empty IPv4-Add-Prefix/IPv6- 1853 Add-Prefix/IPv4-Add-Table/IPv6-Add-Table or one or more Add-IPv4/ 1854 Add-IPv6 attributes, the previously received bindings from the 1855 remote speaker peer (if any), whose IP/IPv6 addresses are 1856 contained in any of those attributes, SHALL be removed from the 1857 SXP input bindings database and replaced with the new bindings for 1858 those IPv4/IPv6 addresses. An added binding is an implicit delete 1859 of an existing binding for the same IP address from the same peer. 1860 The external behavior of the implicit deletion is as described for 1861 the processing of IPv4-Del-Prefix/IPv6-Del-Prefix or Del-IPv4/Del- 1862 IPv6 attributes where the deleted binding is the last binding for 1863 its IP address. 1865 II. Loop Detection 1867 SXP MUST check the Peer-Sequence associated with each added 1868 binding for the presence of loops before accepting the binding as 1869 a new binding or as a replacement for an implicitly deleted 1870 binding. SXP loop detection is done by scanning the entire Peer- 1871 Sequence attribute, and checking that the SXP Node ID of the local 1872 system does not appear in the Peer-Sequence. 1874 III. New or Replaced Bindings 1876 SXP SHALL keep the most recently received binding for each IP 1877 address in the input binding database. SXP SHALL keep all the 1878 mandatory attributes and any optional transitive attributes and 1879 MAY keep other non-transitive attributes. A subset of the 1880 attributes, such as Scalable-Group-Tag, are used locally on the 1881 system and have to be reported to the master binding database. 1882 The master binding database arbitrates among multiple binding 1883 contributors for the same IP address. SXP SHALL report new 1884 bindings to the master binding database along with the attributes 1885 the master database is aware of. The arbitration process in the 1886 master binding database yields a selected binding contributor for 1887 each IP address. The binding contributor could be a binding 1888 source other than SXP. SXP MUST NOT export any binding it has 1889 received in UPDATE message unless it has survived the arbitration 1890 process in the master binding database to become the selected 1891 binding. 1893 SXP SHALL become aware of the outcome of the arbitration process 1894 within the master binding database. The arbitration process could 1895 be triggered by binding add or delete reported by SXP or binding 1896 changes from other binding contributors. SXP NEED NOT be aware of 1897 the presence of other binding contributors, their nature, or how 1898 many such contributors exist. SXP is only aware of the possible 1899 existence of such binding contributors and only need to know 1900 whether a selected binding was contributed by SXP itself or by 1901 some other contributor. The mechanism by which SXP becomes aware 1902 of changes of selected bindings in the master binding database is 1903 an implementation detail. 1905 5.3. Generating UPDATE Message 1907 Binding Removal Event 1909 If SXP becomes aware of a deletion of a binding for an IPv4/IPv6 1910 prefix it then processes the event as follows: 1912 o The IPv4/IPv6 prefix SHALL be included in either an IPv4-Del- 1913 Prefix/IPv6-Del-Prefix or a single Del-IPv4/Del-IPv6 attribute of 1914 an outgoing UPDATE message. SXP MAY delay exporting of such event 1915 for a small and bound duration in order to allow for aggregation 1916 as long as such aggregation will not exhibit different external 1917 behavior from individually exported events. 1919 Binding Change Event 1921 If SXP becomes aware of a new or changed binding for an IPv4/IPv6 1922 prefix it then processes the event as follows: 1924 o If the selected contributor is not SXP, SXP SHALL associate the 1925 binding with a Peer-Sequence that contains the local SXP Node ID 1926 as the only peer and export the binding in one of IPv4-Add-Prefix/ 1927 IPv6-Add-Prefix, IPv4-Add-Table/IPv6-Add-Table, or Add-IPv4/Add- 1928 IPv6. SXP SHALL include in the outgoing UPDATE message the 1929 attributes that are available from the master binding database. 1931 o If the selected contributor is SXP, SXP MUST locate the 1932 contributed binding in its input binding database and extract the 1933 Peer-Sequence that was associated with the binding when it was 1934 originally received. SXP SHALL prepend the local SXP Node ID to 1935 the Peer-Sequence when it is added to an outgoing UPDATE message. 1936 SXP SHALL include in the UPDATE message the mandatory attributes 1937 reported by the master binding database and any additional well- 1938 known or optional transitive attributes that were associated with 1939 the binding upon its arrival. SXP MAY add additional optional 1940 transitive or non-transitive attributes. 1942 SXP SHALL flag an SXP originated binding in its input bindings 1943 database in order to support UPDATE message processing as specified 1944 in this section. 1946 6. SXP Failure Scenarios 1948 The following SXP failure scenarios are analyzed in this section: 1950 o SXP Connection Failure 1952 o Operational (Hardware) Failures 1954 SXP connection can fail for various reasons: 1956 o Peer device offline 1958 o Loss of network connectivity 1960 o Loss message authentication key synchronization with the peer. In 1961 this case the device re-attempts message exchange for a fixed 1962 number of times and if the problem persists then the connection is 1963 torn down. 1965 o Software processing failures, e.g. SXP message decode failure. 1966 SXP version mismatch and SXP message parse error will result in 1967 the device sending an Error TLV. When sending an error message, 1968 the error code is passed as part of the TLV and the action 1969 decision is left up to the peer device. This error code COULD be 1970 simply logged for debugging purposes. The SXP connection is 1971 closed and retries to setup after sending the SXP ERROR message. 1973 7. SXP Timers 1975 There are 5 SXP timers defined in SXP protocol. The details of the 1976 timers and the default values of them are described below: 1978 +------------------------+---------------------------------+ 1979 | Timer | Default Value (seconds) | 1980 +------------------------+---------------------------------+ 1981 | Retry Open Timer | 120 | 1982 | Delete Hold Down Timer | 120 | 1983 | Reconciliation Timer | 120 | 1984 | Hold Timer | 90 (actual value is negotiated) | 1985 | Keep-alive Timer | 30 (one-third of Hold Timer) | 1986 +------------------------+---------------------------------+ 1988 o Retry open timer 1990 * Retry open timer is triggered as long as there is one SXP 1991 connection on the device that is not up. 1993 * The default timer value is 120 seconds. Value 0 means retry 1994 timer will not be started. 1996 * The retry continues until the SXP connection is setup or the 1997 retry timer is configured to be 0. 1999 o Delete Hold Down Timer 2001 * Delete hold down timer is triggered when a connection on 2002 listener side is torn down. The bindings learnt are not 2003 deleted immediately but held off for the delete hold down timer 2004 period. 2006 * The bindings are deleted upon the expiry of this timer. 2008 * The timer value is set to 120 seconds and it is not 2009 configurable. 2011 o Reconciliation Timer 2013 * If a SXP connection is brought up within the delete hold down 2014 timer period, bindings are re-populated from the speaker side. 2015 At the same time, the old bindings learnt before the connection 2016 went down still hold. 2018 * Reconciliation timer starts right after the connection is 2019 brought up to wait for the new bindings to be forwarded from 2020 the peer. 2022 * Upon timer expiry, SXP checks the bindings in its input binding 2023 database and deletes any stale bindings. Those are bindings 2024 that could have been deleted on the remote side while the 2025 connection was down. 2027 * The default timer value is 120 seconds. Value 0 means 2028 reconciliation timer will not be started. 2030 o Hold Timer 2032 * Hold Timer MAY be used by an SXP Listener to detect when a 2033 connection is no longer live. 2035 * The usage of Hold Timer and KEEPALIVE is negotiated during 2036 OPEN/OPEN_RESP exchange. 2038 * The Hold Timer is started when the connection reaches ON state. 2039 The interval is set to the negotiated Hold Time. 2041 * The Hold Timer is restarted whenever a listener receives a 2042 KEEPALIVE or an UPDATE message. 2044 * If a listener does not receive KEEPALIVE, and/or UPDATE 2045 messages within the period negotiated for the Hold Time of a 2046 connection, the Hold Timer expires. 2048 * Upon the timer expiry, SXP MUST send an ERROR message with Hold 2049 Timer Expired code and tear down the connection. 2051 * The rest of the behavior is the same as when TCP indicates to 2052 SXP the loss of a connection. The Delete Hold Down timer is 2053 restarted for delayed deletion of bindings as described above. 2055 * The suggested period of the Hold Timer is 90 seconds. SXP 2056 implementation MAY allow for local configuration of Hold Time 2057 for a listener. The actual value of the Hold Time used for a 2058 connection is negotiated. 2060 o Keepalive Timer 2062 * Keepalive Timer MAY be used by an SXP Listener for triggering 2063 sending KEEPALIVE messages to the listener peer which monitors 2064 a connection using Hold Timer. 2066 * The usage of Keepalive Timer and KEEPALIVE messages is 2067 negotiated during OPEN/OPEN_RESP exchange. 2069 * The Keepalive Timer is started for the first time when the 2070 connection reaches its ON state. 2072 * The Keepalive Timer is restarted thereafter, when a speaker 2073 sends an UPDATE or KEEPALIVE message. 2075 * Upon timer expiry, SXP speaker MUST send KEEPALIVE message in 2076 order to indicate to the listener that the connection remains 2077 live. 2079 * The suggested period of the Keepalive Timer is 30 seconds. SXP 2080 implementation MAY allow for local configuration of Keepalive 2081 Time for a speaker. The actual value of the Keepalive Time 2082 used for a connection is set to 1/3 of the negotiated Hold 2083 Time. 2085 * The Keepalive Timer is restarted with a random jitter. The 2086 actual period of the Keepalive Timer is set to a random value 2087 between 0.75 to 1.0 of the negotiated Keepalive Time which is 2088 re-calculated every time the timer is restarted. 2090 8. SXP Version Negotiation 2092 In a software release, SXP always supports the highest version in 2093 that release and any version lower than that. SXP version 2094 negotiation is per connection base. On the same device, the 2095 connections established between this device and the peer devices may 2096 have difference versions, depending on the SXP version running on the 2097 peer devices. 2099 If the two ends of a SXP connection run the same SXP version, the 2100 running version is used. If the two ends are running different 2101 versions, the version of the connection is decided with following 2102 process: 2104 When the initiator of a connection sends a SXP OPEN message, the 2105 highest supported version is coded in the OPEN message. 2107 On the receiver side, if the version in the OPEN message is higher 2108 than the version it can support, it sends back OPEN RESPONSE message 2109 with the highest version it supports (which is lower than the version 2110 in OPEN message). When the OPEN RESPONSE message is received by the 2111 initiator, it accepts the version coded in the OPEN RESPONSE. The 2112 receiver side's version is used as the connection's version. 2114 In summary, SXP connection picks the highest version that is 2115 supported on both sides. 2117 8.1. SXP Versions 2119 SXP supports three versions starting from version 2 to 4. The 2120 details of what is supported in each of the version follows - 2121 +-----+----------+----------+------------+-----------+--------------+ 2122 | Ver | IPv4 | IPv6 | Subnet | Loop | SXP | 2123 | | Bindings | Bindings | Binding | Detection | Capability | 2124 | | | | Expansion | | Exchange | 2125 +-----+----------+----------+------------+-----------+--------------+ 2126 | 2 | Yes | Yes | No | No | No | 2127 | 3 | Yes | Yes | Yes | No | No | 2128 | 4 | Yes | Yes | Yes | Yes | Yes | 2129 +-----+----------+----------+------------+-----------+--------------+ 2131 8.2. Error Handling in Older SXP Versions 2133 The error handling scenarios in SXP Version1 & Version 2 are listed 2134 below: 2136 8.2.1. SXP Version 1 2138 o Unknown message type causes connection to be disconnected 2140 o Extra fileds in OPEN & OPEN_RESP messages causes connection to be 2141 disconnected 2143 o Unknown TLV in UPDATE message causes a parser error message sent 2144 to the peer and connection is disconnected 2146 o Extra parameters in the ERROR message cause a parser error message 2147 sent to the peer and connection is disconnected 2149 8.2.2. SXP Version 2 2151 o Unknown message type is ignored 2153 o Extra fileds in OPEN & OPEN_RESP messages is ignored 2155 o Unknown TLV received in UPDATE message is ignored and no other 2156 action is taken. Unknown opcode is also ignored 2158 o Extra parameter in ERROR message is ignored 2160 9. Security Considerations 2162 SXP carries mappings between IP addresses and scalable groups. An 2163 adversary that can modify the data can potentially gain an advantage 2164 over the system. This specification defines the use of TCP MD5 2165 Signature Option [RFC5925] to provide integrity protection for the 2166 information. The key used with TCP MD5[RFC1321] should be chosen to 2167 be long and have high entropy to provide as much protection from 2168 dictionary attacks as possible. 2170 MD5 has been shown to contain weaknesses so this protection may not 2171 be sufficient in many environments. In addition, an adversary who 2172 can observe the data may be able to use the information learned to 2173 identify weak or highly valued targets so it is desirable that 2174 confidentiality also be provided. A future revision of this 2175 specification will provide more robust security mechanisms such as 2176 ones based on IPSEC or TLS. 2178 10. Implementation Note 2180 Current implementations of the protocol support source and peer IP 2181 addresses to be IPv4 only. However, the implementation should take 2182 care of being able to support IPv6 addresses as well in the future. 2183 As such, there are not changes expected to be done in the protocol 2184 itself to support IPv6 address based connections. 2186 The SXP password can be upto 80 ASCII characters. 2188 The Node-id used has to be a unique IP address on the device. 2189 Current implementations use the highest local IP address on the 2190 device and some use the first IP address on the device. 2192 10.1. Bi-Directional SXP 2194 The current implementation of SXP protocol supports bindings to be 2195 exchanged in one direction only per connection. In scenarios where 2196 bindings have to be sent and received with the same peer, two 2197 connections have to be configured with one as Listener and the other 2198 one as Speaker. In order to avoid configuring two different 2199 connections with the same peer, the procotol supports bi-directional 2200 mode. When a connection is configured in bi-directional mode, on 2201 either ends only the Listener initiates the socket connection unlike 2202 the normal case where either Speaker/Listener can initiate the 2203 connection. Once the two socket connections are up the rest of the 2204 connection management, bindings updates, etc are same as the uni- 2205 directional connection. 2207 11. IANA Considerations 2209 TBD 2211 12. IPR Disclosure 2213 "By submitting this Internet-Draft, each author represents that any 2214 applicable patent or other IPR claims of which he or she is aware 2215 have been or will be disclosed, and any of which he or she becomes 2216 aware will be disclosed, in accordance with Section 6 of BCP 79." 2218 13. Copyright Notice and Disclaimer 2220 "Copyright (C) The IETF Trust (year). This document is subject to 2221 the rights, licenses and restrictions contained in BCP 78, and except 2222 as set forth therein, the authors retain all their rights." 2223 Additional copyright notices are not permitted in IETF Documents 2224 except in the case where such document is the product of a joint 2225 development effort between the IETF and another standards development 2226 organization or the document is a republication of the work of 2227 another standards organization. Such exceptions must be approved on 2228 an individual basis by the IAB. 2230 "This document and the information contained herein are provided on 2231 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2232 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY , THE 2233 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 2234 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 2235 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 2236 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 2237 PARTICULAR PURPOSE." 2239 14. Acknowledgements 2241 Special acknowledgements are due to the following contributors. The 2242 protocol was originally developed by Michael Smith, Michael Fine and 2243 Awais Nemat. Enhancements have been made over the years by Ronen 2244 Arad, Rajesh Bhandari, Lei Fu and Paddy Nallur. Darrin Miller and 2245 Kevin Regan provided significant inputs into requirements for later 2246 versions of the protocol. Fabio Maino specified the data plane 2247 format. Sandeep Rao has contributed to the SGT format in NSH, GRE, 2248 VxLan and also the section on tagging exemption for L2 control 2249 traffic. Thanks to Joe Salowey and Susan Thomson for edits and 2250 review. 2252 15. References 2254 15.1. Normative References 2256 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 2257 DOI 10.17487/RFC1321, April 1992, 2258 . 2260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2261 Requirement Levels", BCP 14, RFC 2119, 2262 DOI 10.17487/RFC2119, March 1997, 2263 . 2265 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 2266 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 2267 June 2010, . 2269 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 2270 for the TCP Authentication Option (TCP-AO)", June 2010, 2271 . 2273 15.2. Informative References 2275 [I-D.draft-guichard-sfc-nsh-dc-allocation] 2276 Guichard, J., Smith, M., Kumar, S., Majee, S., Agarwal, 2277 P., Glavin, K., and Y. Laribi, "Network Service Header 2278 (NSH) Context Header Allocation (Data Center)", December 2279 2014. 2281 [I-D.draft-quinn-sfc-nsh] 2282 Quinn, P., Guichard, J., Surendra, S., Smith, M., 2283 Henderickx, W., Nadeau, T., Agarwal, P., Manur, R., 2284 Chauhan, A., Majee, S., Elzur, U., Melman, D., Garg, P., 2285 McConnell, B., Wright, C., and K. Kevin, "Network Service 2286 Header", January 2015. 2288 [I-D.draft-smith-vxlan-group-policy] 2289 Guichard, J., Smith, M., Kumar, S., Majee, S., Agarwal, 2290 P., Glavin, K., and Y. Laribi, "Network Service Header 2291 (NSH) Context Header Allocation (Data Center)", December 2292 2014. 2294 Appendix A. SGT as MetaData in Data Plane 2296 The Scalable Group Tag can be carried in the control plane (using SXP 2297 described in the main body of this I-D), or in the data plane. SGT 2298 can be carried inline as metadata in Cisco MetaData (CMD) or Network 2299 Service Header (NSH). CMD can be carried in L2 or as a GRE payload. 2301 The following sections describe format of SGT metadata in CMD and 2302 NSH. 2304 This section describes Cisco Metadata (CMD) Version 1, the format for 2305 carrying SGT in the data plane at L2. Appendix B describes SGT in 2306 NSH, while C and D describes format of SGT CMD and SGT NSH in GRE. 2308 A.1. CMD Format 2310 The CMD format is comprised of a header and payload. The fields are 2311 transmitted in network byte order from left to right. 2313 A.1.1. Metadata Header 2315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 2316 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 2317 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 2319 | Metadata Ethertype | Version | Length | 2320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 2321 | Metadata Payload (4-12 bytes) | 2322 + + 2323 | ... | 2324 + ... + 2325 | | 2326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 2328 Metadata Ethertype: 2330 The Metadata field is 2 bytes and contains the ethertype assigned by 2331 IEEE for Cisco Metadata (0x8909). 2333 Version 2335 The Version field is 1 byte, and is set to 1 for CMD Header version 1 2336 described in this document. 2338 Length 2340 The Length field is 1 byte, and specifies the length of the CMD in 2341 4-byte units, not including the first 4 bytes. Valid values are in 2342 the range of 1-3. 2344 A.1.2. Metadata Payload 2346 Metadata payload is composed of 1 or more options. Only one option 2347 is defined in this document. 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 2350 | | | | | | | | | | |1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3| 2351 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| 2352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 2353 | Len | Option Type | | 2354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2355 | Value (2-6 bytes) | 2356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+ 2358 Len 2359 The most significant three bits of the Option are the Option Length, 2360 expressed in a multiple of 4 bytes not including the first 4 bytes. 2362 Option Type 2364 After Len, the next 13 bits are the Option Type. For SGT Option, the 2365 value is 1. 2367 Value 2369 The Value field is 2-6 bytes of data. For SGT Option, the value is 2 2370 bytes, and contains a 16-bit Scalable Group Tag (SGT). If an Option 2371 of Type 1 (SGT Option) is present in the Metadata Payload, it must be 2372 included as the first Option in the Payload. 2374 A.1.3. Header Protection 2376 The CMD header does not have a checksum or CRC, and relies on the 2377 underlying ethernet CRC for integrity protection. 2379 A.1.4. Header Insertion, Removal, and Relocation 2381 The useful lifespan of a metadata header is expected to be a single 2382 zone of authority, such as an enterprise or service provider, where 2383 all routers and switches within that zone are under the control of 2384 that authority. CMD headers should be inserted upon entrance to a 2385 zone of authority or while traversing the zone, and removed just 2386 prior to exit from the zone. 2388 A.1.4.1. Insertion 2390 A CMD header can be inserted in a packet at any point during network 2391 traversal. Any device wishing to add metadata to a packet should 2392 check for a pre-existing header, and add a new header if one is not 2393 present. 2395 When used at layer 2, in order to simplify parsing and allow bridging 2396 of frames through CMD-unaware bridges, the CMD header shall be 2397 inserted after the .1Q tag, if present. If the .1Q tag is not 2398 present the CMD header will immediately follow the MAC Source 2399 Address. Below is a non-exhaustive list of L2 frames with CMD. 2401 CMD Insertion only: 2403 DA,SA,L3pld -> DA,SA,CMD,L3pld 2405 DA,SA,1Q,L3pld -> DA,SA,1Q,CMD,L3pld 2406 DA,SA,1Q,1Q,L3pld -> DA,SA,1Q,1Q,CMD,L3pld 2408 DA,SA,1Q,MPLS,L3pld -> DA,SA,1Q,CMD,MPLS,L3pld 2410 CMD and MACsec Insertion: 2412 DA,SA,L3pld -> DA,SA,MACsec,CMD,L3pld 2414 DA,SA,1Q,L3pld -> DA,SA,MACsec,1Q,CMD,L3pld 2416 DA,SA,1Q,1Q,L3pld -> DA,SA,MACsec,1Q,1Q,CMD,L3pld 2418 A.1.4.2. Removal 2420 A CMD header should be removed prior to exit from the zone of 2421 authority, regardless of contents. 2423 A.2. Assigned Ethernet Type 2425 IEEE has assigned the Ethernet Type Field Number 0x8909 to the CMD 2426 protocol. 2428 Appendix B. SGT in Network Services Header (NSH) 2430 NSH Is defined in [I-D.draft-quinn-sfc-nsh]. 2431 [I-D.draft-guichard-sfc-nsh-dc-allocation] provides a recommended 2432 default allocation for the fixed context headers within NSH. Using 2433 the recommended default, SGT is carried as follows in the NSH: 2435 Source Class: Set to SGT associated with source IP address in packet 2437 Destination Class: Set to SGT associated with destination IP address 2438 in packet (when known) 2440 Appendix C. SGT CMD in GRE 2442 The format of SGT CMD in GRE (IPv4 Packet) is as shown below: 2444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+ 2445 | L2 Header | L3 Header, proto=47| GRE Header, PT=0x8909 | 2446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------+ 2447 | CMD | 2448 +---------------+-----------------+ 2449 | PT=0x800 | Original Packet | 2450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---+ 2452 The format of CMD is as per Appendix A. 2454 Appendix D. SGT NSH in GRE 2456 The format of SGT NSH in GRE (IPv4 Packet) is as shown below: 2458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+ 2459 | L2 Header | L3 Header, proto=47| GRE Header, PT=0x8909 | 2460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------+ 2461 | NSH | 2462 +---------------+-----------------+ 2463 | PT=0x800 | Original Packet | 2464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---+ 2466 Appendix E. SGT in VXLAN 2468 The VXLAN Group Based Policy (VXLAN-GBP) Extension is defined in 2469 [I-D.draft-smith-vxlan-group-policy]. SGT can be carried in VXLAN- 2470 GBP Extension header in the Group Policy ID field with the G-bit set 2471 as shown below: 2473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+ 2474 |G|R|R|R|I|R|R|R|R|D|R|R|A|R|R|R| Group Policy ID | 2475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------+----------------+ 2476 | VXLAN Network Identifier (VNI) | Reserved | 2477 +---------------+-----------------+---------+----------------+ 2479 Appendix F. SGT tagging exemption for L2 control traffic 2481 There are many Ethernet L2 control protocols (L2CP) that govern 2482 various operational and link states on a device. This includes 2483 protocols such as Spanning Tree BPDUs, EPoL, LACP, VTP, PVST, UDLD, 2484 LLDP, PAUSE Frames and so on. Typically these protocols have 2485 predesignated destination MAC address or ranges. In order to 2486 facilitate seamless flow and native processing of these control 2487 protocols, insertion of CMD to these protocols SHOULD be exempted. 2489 Authors' Addresses 2491 Michael Smith 2492 Cisco Systems 2493 210 West Tasman Drive 2494 San Jose, California 95134 2495 United States 2497 Email: michsmit@cisco.com 2498 Rakesh Reddy Kandula 2499 Cisco Systems 2500 Cessna Business Park, Kadubeesanahalli Village 2501 Sarjapur/Marathahalli Outer Ring Road 2502 Bangalore, Karnataka 560103 2503 India 2505 Email: krreddy@cisco.com 2507 Syam Appala 2508 Cisco Systems 2509 510 McCarthy Blvd. 2510 Milpitas, California 95035 2511 United States 2513 Email: syam1@cisco.com