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