idnits 2.17.00 (12 Aug 2021) /tmp/idnits32184/draft-ietf-pwe3-iccp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 20, 2012) is 3621 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCxxxx' is mentioned on line 3195, but not defined ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.1AX' == Outdated reference: draft-ietf-pwe3-redundancy-bit has been published as RFC 6870 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Luca Martini 3 Internet Draft Samer Salam 4 Intended status: Standards Track Ali Sajassi 5 Expires: December 20, 2012 Cisco 7 Matthew Bocci Satoru Matsushima 8 Alcatel-Lucent Softbank 10 Thomas Nadeau 11 CA Technologies 12 June 20, 2012 14 Inter-Chassis Communication Protocol for L2VPN PE Redundancy 16 draft-ietf-pwe3-iccp-08.txt 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on December 20, 2012 41 Abstract 43 This document specifies an inter-chassis communication protocol 44 (ICCP) that enables Provider Edge (PE) device redundancy for Virtual 45 Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) 46 applications. The protocol runs within a set of two or more PEs, 47 forming a redundancy group, for the purpose of synchronizing data 48 amongst the systems. It accommodates multi-chassis attachment circuit 49 as well as pseudowire redundancy mechanisms. 51 Table of Contents 53 1 Specification of Requirements ........................ 5 54 2 Introduction ......................................... 5 55 3 ICCP Overview ........................................ 5 56 3.1 Redundancy Model & Topology .......................... 5 57 3.2 ICCP Interconnect Scenarios .......................... 7 58 3.2.1 Co-located Dedicated Interconnect .................... 7 59 3.2.2 Co-located Shared Interconnect ....................... 8 60 3.2.3 Geo-redundant Dedicated Interconnect ................. 8 61 3.2.4 Geo-redundant Shared Interconnect .................... 9 62 3.3 ICCP Requirements .................................... 10 63 4 ICC LDP Protocol Extension Specification ............. 12 64 4.1 LDP ICCP Capability Advertisement .................... 12 65 4.2 RG Membership Management ............................. 13 66 4.2.1 ICCP Connection State Machine ........................ 13 67 4.3 Redundant Object Identification ...................... 16 68 4.4 Application Connection Management .................... 16 69 4.4.1 Application Versioning ............................... 17 70 4.4.2 Application Connection State Machine ................. 18 71 4.5 Application Data Transfer ............................ 21 72 4.6 Dedicated Redundancy Group LDP session ............... 21 73 5 ICCP PE Node Failure Detection Mechanism ............. 22 74 6 ICCP Message Formats ................................. 22 75 6.1 Encoding ICC into LDP Messages ...................... 23 76 6.1.1 ICC Header ........................................... 23 77 6.1.2 Message Encoding ..................................... 25 78 6.1.3 ROID Encoding ........................................ 26 79 6.2 RG Connect Message ................................... 26 80 6.2.1 ICC Sender Name TLV .................................. 27 81 6.3 RG Disconnect Message ................................ 28 82 6.4 RG Notification Message .............................. 30 83 6.4.1 Notification Message TLVs ............................ 31 84 6.5 RG Application Data Message .......................... 34 85 7 Application TLVs ..................................... 34 86 7.1 Pseudowire Redundancy (PW-RED) Application TLVs ...... 34 87 7.1.1 PW-RED Connect TLV ................................... 34 88 7.1.2 PW-RED Disconnect TLV ................................ 36 89 7.1.2.1 PW-RED Disconnect Cause TLV .......................... 36 90 7.1.3 PW-RED Config TLV .................................... 37 91 7.1.3.1 Service Name TLV ..................................... 39 92 7.1.3.2 PW ID TLV ............................................ 39 93 7.1.3.3 Generalized PW ID TLV ................................ 40 94 7.1.4 PW-RED State TLV ..................................... 41 95 7.1.5 PW-RED Synchronization Request TLV ................... 43 96 7.1.6 PW-RED Synchronization Data TLV ...................... 44 97 7.2 Multi-chassis LACP (mLACP) Application TLVs .......... 45 98 7.2.1 mLACP Connect TLV .................................... 46 99 7.2.2 mLACP Disconnect TLV ................................. 47 100 7.2.2.1 mLACP Disconnect Cause TLV ........................... 47 101 7.2.3 mLACP System Config TLV .............................. 48 102 7.2.4 mLACP Aggregator Config TLV .......................... 49 103 7.2.5 mLACP Port Config TLV ................................ 51 104 7.2.6 mLACP Port Priority TLV .............................. 53 105 7.2.7 mLACP Port State TLV ................................. 55 106 7.2.8 mLACP Aggregator State TLV ........................... 57 107 7.2.9 mLACP Synchronization Request TLV .................... 59 108 7.2.10 mLACP Synchronization Data TLV ....................... 61 109 8 LDP Capability Negotiation ........................... 62 110 9 Client Applications .................................. 63 111 9.1 Pseudowire Redundancy Application Procedures ......... 63 112 9.1.1 Initial Setup ........................................ 64 113 9.1.2 Pseudowire Configuration Synchronization ............. 64 114 9.1.3 Pseudowire Status Synchronization .................... 65 115 9.1.4 PE Node Failure ...................................... 66 116 9.2 Attachment Circuit Redundancy Application Procedures . 66 117 9.2.1 Common AC Procedures ................................. 66 118 9.2.2 AC Failure ........................................... 67 119 9.2.3 PE Node Failure ...................................... 67 120 9.2.4 PE Isolation ......................................... 67 121 9.2.5 Ethernet AC Procedures ............................... 67 122 9.2.6 Multi-chassis LACP (mLACP) Application Procedures .... 67 123 9.2.6.1 Initial Setup ........................................ 67 124 9.2.6.2 mLACP Aggregator and Port Configuration .............. 69 125 9.2.6.3 mLACP Aggregator and Port Status Synchronization ..... 70 126 9.2.6.4 Failure and Recovery ................................. 72 127 10 Security Considerations .............................. 73 128 11 IANA Considerations .................................. 73 129 11.1 MESSAGE TYPE NAME SPACE .............................. 73 130 11.2 TLV TYPE NAME SPACE .................................. 74 131 11.3 ICC RG Parameter Type Space .......................... 74 132 11.4 STATUS CODE NAME SPACE ............................... 75 133 12 Acknowledgments ...................................... 75 134 13 Normative References ................................. 76 135 14 Informative References ............................... 76 136 15 Author's Addresses ................................... 76 138 1. Specification of Requirements 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119. 144 2. Introduction 146 Network availability is a critical metric for service providers as it 147 has a direct bearing on their profitability. Outages translate not 148 only to lost revenue but also to potential penalties mandated by 149 contractual agreements with customers running mission-critical 150 applications that require tight SLAs. This is true for any carrier 151 network, and networks employing Layer 2 Virtual Private Network 152 (L2VPN) technology are no exception. Network high-availability can 153 be achieved by employing intra and inter-chassis redundancy 154 mechanisms. The focus of this document is on the latter. The document 155 defines an Inter-Chassis Communication Protocol (ICCP) that allows 156 synchronization of state and configuration data between a set of two 157 or more PEs forming a Redundancy Group (RG). The protocol supports 158 multi-chassis redundancy mechanisms that can be employed on either 159 the attachment circuit or pseudowire front. 161 3. ICCP Overview 163 3.1. Redundancy Model & Topology 165 The focus of this document is on PE node redundancy. It is assumed 166 that a set of two or more PE nodes are designated by the operator to 167 form a Redundancy Group (RG). Members of a Redundancy Group fall 168 under a single administration (e.g. service provider) and employ a 169 common redundancy mechanism towards the access (attachment circuits 170 or access pseudowires) and/or towards the core (pseudowires) for any 171 given service instance. It is possible, however, for members of an RG 172 to make use of disparate redundancy mechanisms for disjoint services. 173 The PE devices may be offering any type of L2VPN service, i.e. VPWS 174 or VPLS. As a matter of fact, the use of ICCP may even be applicable 175 for Layer 3 service redundancy, but this is considered to be outside 176 the scope of this document. 178 The PEs in an RG offer multi-homed connectivity to either individual 179 devices (e.g. CE, DSLAM, etc...) or entire networks (e.g. access 180 network). Figure 1 below depicts the model. 182 +=================+ 183 | | 184 Mutli-homed +----+ | +-----+ | 185 Node ------------> | CE |-------|--| PE1 ||<------|---Pseudowire-->| 186 | |--+ -|--| ||<------|---Pseudowire-->| 187 +----+ | / | +-----+ | 188 | / | || | 189 |/ | || ICCP |--> Towards Core 190 +-------------+ / | || | 191 | | /| | +-----+ | 192 | Access |/ +----|--| PE2 ||<------|---Pseudowire-->| 193 | Network |-------|--| ||<------|---Pseudowire-->| 194 | | | +-----+ | 195 | | | | 196 +-------------+ | Redundancy | 197 ^ | Group | 198 | +=================+ 199 | 200 Multi-homed Network 202 Figure 1: Generic Multi-chassis Redundancy Model 204 In the topology of Figure 1, the redundancy mechanism employed 205 towards the access node/network can be one of a multitude of 206 technologies, e.g. it could be IEEE 802.1AX Link Aggregation Groups 207 with Link Aggregation Control Protocol (LACP), or SONET APS. The 208 specifics of the mechanism are out of the scope of this document. 209 However, it is assumed that the PEs in the RG are required to 210 communicate amongst each other in order for the access redundancy 211 mechanism to operate correctly. As such, it is required to run an 212 inter-chassis communication protocol among the PEs in the RG in order 213 to synchronize configuration and/or running state data. 215 Furthermore, the presence of the inter-chassis communication channel 216 allows simplification of the pseudowire redundancy mechanism. This is 217 primarily because it allows the PEs within an RG to run some 218 arbitration algorithm to elect which pseudowire(s) should be in 219 active or standby mode for a given service instance. The PEs can then 220 advertise the outcome of the arbitration to the remote-end PE(s), as 221 opposed to having to embed a hand-shake procedure into the pseudowire 222 redundancy status communication mechanism, and every other possible 223 Layer 2 status communication mechanism. 225 3.2. ICCP Interconnect Scenarios 227 When referring to 'interconnect' in this section, we are concerned 228 with the links or networks over which Inter-Chassis Communication 229 Protocol messages are transported, and not normal data traffic 230 between PEs. The PEs which are members of an RG may be either 231 physically co-located or geo-redundant. Furthermore, the physical 232 interconnect between the PEs over which ICCP is to run may comprise 233 of either dedicated back-to-back links or a shared connection through 234 the packet switched network (PSN); for e.g., MPLS core network. This 235 gives rise to a matrix of four interconnect scenarios, described 236 next. 238 3.2.1. Co-located Dedicated Interconnect 240 In this scenario, the PEs within an RG are co-located in the same 241 physical location (POP, CO). Furthermore, dedicated links provide the 242 interconnect for ICCP among the PEs. 244 +=================+ +-----------------+ 245 |CO | | | 246 | +-----+ | | | 247 | | PE1 |________|_____| | 248 | | | | | | 249 | +-----+ | | | 250 | || | | | 251 | || ICCP | | Core | 252 | || | | Network | 253 | +-----+ | | | 254 | | PE2 |________|_____| | 255 | | | | | | 256 | +-----+ | | | 257 | | | | 258 +=================+ +-----------------+ 260 Figure 2: ICCP Co-located PEs Dedicated Interconnect Scenario 262 Given that the PEs are connected back-to-back in this case, it is 263 possible to rely on Layer 2 redundancy mechanisms to guarantee the 264 robustness of the ICCP interconnect. For example, if the interconnect 265 comprises of IEEE 802.3 Ethernet links, it is possible to provide 266 link redundancy by means of IEEE 802.1AX Link Aggregation Groups. 268 3.2.2. Co-located Shared Interconnect 270 In this scenario, the PEs within an RG are co-located in the same 271 physical location (POP, CO). However, unlike the previous scenario, 272 there are no dedicated links between the PEs. The interconnect for 273 ICCP is provided through the core network to which the PEs are 274 connected. Figure 3 depicts this model. 276 +=================+ +-----------------+ 277 |CO | | | 278 | +-----+ | | | 279 | | PE1 |________|_____| | 280 | | |<=================+ | 281 | +-----+ ICCP | | || | 282 | | | || | 283 | | | || Core | 284 | | | || Network | 285 | +-----+ | | || | 286 | | PE2 |________|_____| || | 287 | | |<=================+ | 288 | +-----+ | | | 289 | | | | 290 +=================+ +-----------------+ 292 Figure 3: ICCP Co-located PEs Shared Interconnect Scenario 294 Given that the PEs in the RG are connected over the packet switched 295 network (PSN), then PSN Layer mechanisms can be leveraged to ensure 296 the resiliency of the interconnect against connectivity failures. For 297 example, it is possible to employ RSVP LSPs with Fast Re-Route (FRR) 298 and/or end-to-end backup LSPs. 300 3.2.3. Geo-redundant Dedicated Interconnect 302 In this variation, the PEs within a Redundancy Group are located in 303 different physical locations to provide geographic redundancy. This 304 may be desirable, for example, to protect against natural disasters 305 or the like. A dedicated interconnect is provided to link the PEs, 306 which is a costly option, especially when considering the possibility 307 of providing multiple such links for interconnect robustness. The 308 resiliency mechanisms for the interconnect are similar to those 309 highlighted in the co-located interconnect counterpart. 311 +=================+ +-----------------+ 312 |CO 1 | | | 313 | +-----+ | | | 314 | | PE1 |________|_____| | 315 | | | | | | 316 | +-----+ | | | 317 +=====||==========+ | | 318 || ICCP | Core | 319 +=====||==========+ | Network | 320 | +-----+ | | | 321 | | PE2 |________|_____| | 322 | | | | | | 323 | +-----+ | | | 324 |CO 2 | | | 325 +=================+ +-----------------+ 327 Figure 4: ICCP Geo-redundant PEs Dedicated Interconnect Scenario 329 3.2.4. Geo-redundant Shared Interconnect 331 In this scenario, the PEs of an RG are located in different physical 332 locations and the interconnect for ICCP is provided over the PSN 333 network to which the PEs are connected. This interconnect option is 334 more likely to be the one used for geo-redundancy as it is more 335 economically appealing compared to the geo-redundant dedicated 336 interconnect. The resiliency mechanisms that can be employed to 337 guarantee the robustness of the ICCP transport are PSN Layer 338 mechanisms as has been described in the "Co-located Shared 339 Interconnect" section above. 341 +=================+ +-----------------+ 342 |CO 1 | | | 343 | +-----+ | | | 344 | | PE1 |________|_____| | 345 | | |<=================+ | 346 | +-----+ ICCP | | || | 347 +=================+ | || | 348 | || Core | 349 +=================+ | || Network | 350 | +-----+ | | || | 351 | | PE2 |________|_____| || | 352 | | |<=================+ | 353 | +-----+ | | | 354 |CO 2 | | | 355 +=================+ +-----------------+ 357 Figure 5: ICCP Geo-redundant PEs Shared Interconnect Scenario 359 3.3. ICCP Requirements 361 The Inter-chassis Communication Protocol SHOULD satisfy the following 362 requirements: 364 -i. Provide a control channel for communication between PEs in a 365 Redundancy Group (RG). Nodes may be co-located or remote 366 (refer to "Interconnect Scenarios" section above). It is 367 expected that client applications which make use of ICCP 368 services will only use this channel to communicate control 369 information and not data-traffic. As such the protocol 370 should cater for relatively low bandwidth, low-delay and 371 highly reliable message transfer. 373 -ii. Accommodate multiple client applications (e.g. multi-chassis 374 LACP, PW redundancy, SONET APS, etc...). This implies that 375 the messages should be extensible (e.g. TLV-based) and the 376 protocol should provide a robust application registration 377 and versioning scheme. 379 -iii. Provide reliable message transport and in-order delivery 380 between nodes in a RG with secure authentication mechanisms 381 built into the protocol. The redundancy applications that 382 are clients of ICCP expect reliable message transfer, and as 383 such will assume that the protocol takes care of flow- 384 control and retransmissions. Furthermore, given that the 385 applications will rely on ICCP to communicate data used to 386 synchronize state-machines on disparate nodes, it is 387 critical that ICCP guarantees in-order message delivery. 388 Loss of messages or out-of-sequence messages would have 389 adverse side-effects to the operation of the client 390 applications. 392 -iv. Provide a common mechanism to actively monitor the health of 393 PEs in an RG. This mechanism will be used to detect PE node 394 failure and inform the client applications. The applications 395 require this to trigger failover according to the procedures 396 of the employed redundancy protocol on the AC and PW. It is 397 desired to achieve sub-second detection of loss of remote 398 node (~ 50 - 150 msec) in order to give the client 399 applications (redundancy mechanisms) enough reaction time to 400 achieve sub-second service restoration time. 402 -v. Provide asynchronous event-driven state update, independent 403 of periodic messages, for immediate notification of client 404 applications' state changes. In other words, the 405 transmission of messages carrying application data should be 406 on-demand rather than timer-based to minimize inter-chassis 407 state synchronization delay. 409 -vi. Accommodate multi-link and multi-hop interconnect between 410 nodes. When the devices within an RG are located in 411 different physical locations, the physical interconnect 412 between them will comprise of a network rather than a link. 413 As such, ICCP should accommodate the case where the 414 interconnect involves multiple hops. Furthermore, it is 415 possible to have multiple (redundant) paths or interconnects 416 between a given pair of devices. This is true for both the 417 co-located and geo-redundant scenarios. ICCP should handle 418 this as well. 420 -vii. Ensure transport security between devices in an RG. This is 421 especially important in the scenario where the members of an 422 RG are located in different physical locations and connected 423 over a shared network (e.g. PSN). 425 -viii. Must allow operator to statically configure members of RG. 426 Auto-discovery may be considered in the future. 428 -ix. Allow for flexible RG membership. It is expected that only 429 two nodes per an RG will cover most of the redundancy 430 applications for common deployments. ICCP should not 431 preclude supporting more than two nodes in an RG by virtue 432 of design. Furthermore, it is required to allow a single 433 node to be member of multiple RGs simultaneously. 435 4. ICC LDP Protocol Extension Specification 437 To address the requirements identified in the previous section, ICCP 438 is modeled to comprise of three layers: 440 -i. Application Layer: This provides the interface to the 441 various redundancy applications that make use of the 442 services of ICCP. ICCP is concerned with defining common 443 connection management procedures and the formats of the 444 messages exchanged at this layer; however, beyond that, it 445 does not impose any restrictions on the procedures or 446 state-machines of the clients, as these are deemed 447 application-specific and lie outside the scope of ICCP. 448 This guarantees implementation inter-operability without 449 placing any unnecessary constraints on internal design 450 specifics. 452 -ii. Inter Chassis Communication (ICC) Layer: This layer 453 implements the common set of services which ICCP offers to 454 the client applications. It handles protocol versioning, RG 455 membership, Redundant Object identification, PE node 456 identification and ICCP connection management. 458 -iii. Transport Layer: This layer provides the actual ICCP message 459 transport. It is responsible for addressing, route 460 resolution, flow-control, reliable and in-order message 461 delivery, connectivity resiliency/redundancy and finally PE 462 node failure detection. The Transport layer may differ 463 depending on the Physical Layer of the inter-connect. 465 4.1. LDP ICCP Capability Advertisement 467 When an RG is enabled on a particular PE, the capability of 468 supporting ICCP must be advertised to all LDP peers in that RG. This 469 is achieved by using the methods in [RFC5561] and advertising the 470 ICCP LDP capability TLV. If an LDP peer supports the dynamic 471 capability advertisement, this can be done by sending a new 472 capability message with the S bit set for the ICCP capability TLV 473 when the first RG is enabled on the PE. If the peer does not support 474 dynamic capability advertisement, then the ICCP TLV MUST be included 475 in the LDP initialization procedures in the capability parameter 476 [RFC5561]. 478 4.2. RG Membership Management 480 ICCP defines a mechanism that enables PE nodes to manage their RG 481 membership. When a PE is configured to be a member of an RG, it will 482 first advertise the ICCP capability to its peers. Subsequently, the 483 PE sends an RG Connect message to the peers that have also advertised 484 ICCP capability. The PE then waits for the peers to send their own RG 485 Connect messages, if they haven't done so already. For a given RG, 486 the ICCP connection between two devices is considered to be 487 operational only when both have sent and received ICCP RG Connect 488 messages for that RG. 490 If a PE that has sent a particular RG Connect message doesn't receive 491 a corresponding RG Connect (or a Notification message with NAK) from 492 a destination, it will remain in a state expecting the corresponding 493 RG Connect message (or Notification message). The RG will not become 494 operational until the corresponding RG Connect Message has been 495 received. If a PE that has sent an RG Connect message receives a 496 Notification message with a NAK, it will stop attempting to bring up 497 the ICCP connection immediately. The PE MUST resume bringing up the 498 connection after it receives an RG Connect message from the peer PE 499 for the RG in question. This is achieved by responding to the 500 incoming RG Connect message with an appropriate RG Connect. 502 A device MUST send a NAK for an RG Connect message if at least one of 503 the following conditions is satisfied: 505 -i. the PE is not a member of the RG; 507 -ii. the maximum number of simultaneous ICCP connections that the 508 PE can handle is exceeded. 510 A PE sends an RG Disconnect message to tear down the ICCP connection 511 for a given RG. This is a unilateral operation and doesn't require 512 any acknowledgement from the other PEs. Note that the ICCP connection 513 for an RG MUST be operational before any client application can make 514 use of ICCP services in that RG. 516 4.2.1. ICCP Connection State Machine 518 The ICCP Connection state machine is defined to have six states as 519 depicted in the state transition table and state transition diagram 520 that follow. 522 ICCP Connection State Transition Table 523 STATE EVENT NEW STATE 525 NON EXISTENT LDP session established INITIALIZED 527 INITIALIZED Transmit LDP ICCP Capability CAPSENT 529 Receive LDP ICCP Capability CAPREC 530 Action: Transmit LDP ICCP Capability 532 LDP session torn down NON EXISTENT 534 CAPSENT Receive LDP ICCP Capability CAPREC 536 LDP session torn down NON EXISTENT 538 CAPREC Transmit RG Connect Message CONNECTING 540 Receive acceptable RG Connect Message OPERATIONAL 541 Action: Transmit RG Connect Message 543 Receive any other ICCP Message CAPREC 544 Action: Transmit NAK in RG 545 Notification Message 547 LDP session torn down NON EXISTENT 549 CONNECTING Receive acceptable RG Connect Message OPERATIONAL 551 Receive any other ICCP Message CAPREC 552 Action: Transmit NAK in RG 553 Notification Message 555 LDP session torn down NON EXISTENT 557 OPERATIONAL Receive acceptable RG Disconnect Message CAPREC 559 Transmit RG Disconnect Message CAPREC 561 LDP session torn down NON EXISTENT 563 ICCP Connection State Transition Diagram 564 +------------+ 565 | | 566 +------------------>|NON EXISTENT| LDP session torn down 567 | | |<--------------------------+ 568 | +------------+ | 569 | LDP session | ^ LDP session | 570 | established | | torn down | 571 | V | | 572 | +-----------+ | 573 LDP | | | Tx LDP ICCP | 574 session| |INITIALIZED| capability | 575 torn | +---| |---------------+ | 576 down | Rx other | +-----------+ | | 577 | ICCP msg/ |Rx LDP ICCP | | 578 | Tx NAK | capability/ | | 579 | +---+ |Tx LDP ICCP capability | | 580 | | | | | | 581 | V | V V | 582 | +-----------+ Rx LDP ICCP +--------+ | 583 +---| | capability | | | 584 |CAPREC |<----------------------|CAPSENT |---------->+ 585 +---| |-------------------+ | | | 586 | +-----------+ | +--------+ | 587 | ^ ^ | | 588 Tx | | | | | 589 RG | | |Rx RG Disconnect msg | | 590 Connect| | | or |Rx RG Connect msg / | 591 Msg | | |Tx RG Disconnect msg | Tx RG Connect msg | 592 | | | V | 593 | | | +------------+ | 594 | | +--------------------| | | 595 | | |OPERATIONAL |------------>+ 596 | | | | | 597 | |Rx other ICCP msg/ +------------+ | 598 | | Tx NAK ^ | 599 | | | | 600 | +----------+ Rx RG Connect msg | | 601 | | |---------------------+ | 602 +----->|CONNECTING| | 603 | |----------------------------------------->+ 604 +----------+ 606 4.3. Redundant Object Identification 608 ICCP offers its client applications a uniform mechanism for 609 identifying links, ports, forwarding constructs and more generally 610 objects (e.g. interfaces, pseudowires, VLANs, etc...) that are being 611 protected in a redundant setup. These are referred to as Redundant 612 Objects (RO). An example of an RO is a multi-chassis link-aggregation 613 group that spans two PEs. ICCP introduces a 64-bit opaque identifier 614 to uniquely identify ROs in an RG. This identifier, referred to as 615 Redundant Object ID (ROID), MUST match between RG members for the 616 protected object in question. That allows separate systems in an RG 617 to use a common handle to reference the protected entity irrespective 618 of its nature (e.g. physical or virtual) and in a manner that is 619 agnostic to implementation specifics. Client applications that need 620 to synchronize state pertaining to a particular RO SHOULD embed the 621 corresponding ROID in their TLVs. 623 4.4. Application Connection Management 625 ICCP provides a common set of procedures by which applications on one 626 PE can connect to their counterparts on another PE, for purpose of 627 inter-chassis communication in the context of a given RG. The 628 prerequisite for establishing an application connection is to have an 629 operational ICCP RG connection between the two endpoints. It is 630 assumed that the association of applications with RGs is known a 631 priori, e.g. by means of device configuration. ICCP then sends an 632 Application-specific Connect TLV (carried in RG Connect message), on 633 behalf of each client application, to each remote PE within the RG. 634 The client may piggyback application-specific information in that 635 Connect TLV, which for example can be used to negotiate parameters or 636 attributes prior to bringing up the actual application connection. 637 The procedures for bringing up the application connection are similar 638 to those of the ICCP connection: An application connection between 639 two nodes is up only when both nodes have sent and received RG 640 Connect Messages with the proper Application-specific Connect TLVs. A 641 PE MUST send a Notification Message to NAK an application connection 642 request if one of the following conditions is encountered: 644 -i. the application doesn't exist or is not configured for that 645 RG; 647 -ii. the application connection count exceeds the PE's 648 capabilities. 650 When a PE receives such a NAK notification, it MUST stop attempting 651 to bring up the application connection until it receives a new 652 application connection request from the remote PE. This is done by 653 responding to the incoming RG Connect message (carrying an 654 Application-specific Connect TLV) with an appropriate RG Connect 655 message (carrying a corresponding Application-specific Connect TLV). 657 When an application is stopped on a device or it is no longer 658 associated with an RG, it MUST signal ICCP to trigger sending an 659 Application-specific Disconnect TLV (in the RG Disconnect message). 660 This is a unilateral notification to the other PEs within an RG, and 661 as such doesn't trigger any response. 663 4.4.1. Application Versioning 665 During application connection setup time, a given application on one 666 PE can negotiate with its counterpart on a peer PE the proper 667 application version to use for communication. If no common version is 668 agreed upon, then the application connection is not brought up. This 669 is achieved through the following set of rules: 671 - If an application receives an Application-specific Connect TLV 672 with a version number that is higher than its own, it MUST send a 673 Notification message with a NAK TLV indicating status code 674 "Incompatible Protocol Version" and supplying the version that is 675 locally supported by the PE. 677 - If an application receives an Application-specific Connect TLV 678 with a version number that is lower than its own, it MAY respond 679 with an RG Connect that has an Application-specific Connect TLV 680 using the same version that was received. Alternatively, the 681 application MAY respond with a Notification message to NAK the 682 request using the "Incompatible Protocol Version" code, and 683 supplying the version that is supported. The above allows an 684 application to operate in either backwards compatible or 685 incompatible mode. 687 - If an application receives an Application-specific Connect TLV 688 with a version that is equal to its own, then the application 689 MUST honor or reject the request based on whether the application 690 is configured for the RG in question, and whether or not the 691 application connection count has been exceeded. 693 4.4.2. Application Connection State Machine 695 The Application Connection state machine has six states as described 696 in the state transition table and diagram that follow. 698 ICCP Application Connection State Transition Table 699 STATE EVENT NEW STATE 701 NON EXISTENT ICCP connection established RESET 703 RESET ICCP connection torn down NON EXISTENT 705 Transmit Application Connect TLV CONNSENT 707 Receive Application Connect TLV CONNREC 709 Receive any other Application TLV RESET 710 Action: Transmit NAK TLV 712 CONNSENT Receive NAK TLV RESET 714 Receive Application Connect TLV OPERATIONAL 715 with A-bit=1 716 Action: Transmit Application Connect 717 TLV with A-bit=1 719 Receive any other Application TLV RESET 720 Action: Transmit NAK TLV 722 ICCP connection torn down NON EXISTENT 724 CONNREC Transmit NAK TLV RESET 726 Transmit Application Connect TLV CONNECTING 727 with A-bit=1 729 Receive any Application TLV except RESET 730 Connect 731 Action: Transmit NAK TLV 733 ICCP connection torn down NON EXISTENT 735 CONNECTING Receive Application Connect TLV OPERATIONAL 736 with A-bit=1 738 Receive any other Application TLV RESET 739 Action: Transmit NAK TLV 741 ICCP connection torn down NON EXISTENT 743 OPERATIONAL Receive Application Disconnect TLV RESET 745 Transmit Applicaton Disconnect TLV RESET 746 ICCP connection torn down NON EXISTENT 748 ICCP Application Connection State Transition Diagram 749 +------------+ 750 | | 751 +---------------->|NON EXISTENT| ICCP connection torn down 752 | | |<--------------------------+ 753 | +------------+ | 754 | ICCP connection| ^ ICCP connection | 755 | established | | torn down | 756 | | | | 757 | V | Rx other App TLV/ | 758 | +-----------+<-----+ Tx NAK | 759 ICCP | Rx App | | | | 760 connect| Connect TLV | RESET |------+ | 761 torn | +-------------| |---------------+ | 762 down | | +-----------+ Tx App | | 763 | | ^ ^ ^ ^ Connect TLV| | 764 | | Tx NAK | | | | | | 765 | | or | | | | | | 766 | | Rx non | | | | | | 767 | | Connect | | | | | | 768 | V TLV/Tx NAK | | |Rx NAK TLV V | 769 | +-----------+ | | | |or +--------+ | 770 +-| |---+ | | +---------| | | 771 |CONNREC | | | Rx other |CONNSENT|---------->+ 772 +-| | | | App TLV/ | | | 773 | +-----------+ | | Tx NAK +--------+ | 774 | | | |Rx App Connect | 775 | Tx App Connect | | |TLV (A=1) / | 776 | TLV (A=1) | |Rx App Disconn | Tx App | 777 | | |or | Connect TLV | 778 | | |Tx App Disconn V (A=1) | 779 | | | +------------+ | 780 | | +------| | | 781 | Rx other App | |OPERATIONAL |------------>+ 782 | TLV / Tx NAK | | | | 783 | +------+ +------------+ | 784 | | ^ Rx App Connect | 785 | +----------+ | TLV (A=1) | 786 | | |---------------------+ | 787 +--->|CONNECTING| | 788 | |----------------------------------------->+ 789 +----------+ 791 4.5. Application Data Transfer 793 When an application has information to transfer over ICCP it triggers 794 the transmission of an Application Data message. ICCP guarantees in- 795 order and loss-less delivery of data. An application may NAK a 796 message or a set of one or more TLVs within a message by using the 797 Notification Message with NAK TLV. Furthermore, an application may 798 implement its own ACK mechanism, if deemed required, by defining an 799 application-specific TLV to be transported in an Application Data 800 message. 802 It is left up to the application to define the procedures to handle 803 the situation where a PE receives a NAK in response to a transmitted 804 Application Data message. Depending on the specifics of the 805 application, it may be favorable to have the PE, which sent the NAK, 806 explicitly request retransmission of data. On the other hand, for 807 certain applications it may be more suitable to have the original 808 sender of the Application Data message handle retransmissions in 809 response to a NAK. ICCP supports both models. 811 4.6. Dedicated Redundancy Group LDP session 813 For certain ICCP applications, it is required to exchange a fairly 814 large amount of RG information in a very short period of time. In 815 order to better distribute the load in a multiple processor system, 816 and to avoid head of line blocking to other LDP applications, it may 817 be required to initiate a separate TCP/IP session between the two LDP 818 speakers. 820 This procedure is OPTIONAL, and does not change the operation of LDP 821 or ICCP. 823 A PE that requires a separate LDP session will advertise a separate 824 LDP adjacency with a non-zero label space identifier. This will cause 825 the remote peer to open a separate LDP session for this label space. 826 No labels need to be advertised in this label space, as it is only 827 used for one or a set of ICCP RGs. All relevant LDP and ICCP 828 procedures still apply as described in the relevant documents. 830 5. ICCP PE Node Failure Detection Mechanism 832 ICCP provides its client applications a notification when a remote PE 833 that is member of the RG fails. This is used by the client 834 applications to trigger failover according to the procedures of the 835 employed redundancy protocol on the AC and PW. To that end, ICCP does 836 not define its own KeepAlive mechanism for purpose of monitoring the 837 health of remote PE nodes, but rather reuses existing fault detection 838 mechanisms. The following mechanisms may be used by ICCP to detect PE 839 node failure: 841 - BFD 843 Run a BFD session [RFC5880] between the PEs that are members of a 844 given RG, and use that to detect PE node failure. This assumes 845 that resiliency mechanisms are in place to protect connectivity 846 to the remote PE nodes, and hence loss of BFD periodic messages 847 from a given PE node can only mean that the node itself has 848 failed. 850 - IP Reachability Monitoring 852 It is possible for a PE to monitor IP layer connectivity to other 853 members of an RG that are participating in IGP/BGP. When 854 connectivity to a given PE is lost, the local PE interprets that 855 to mean loss of the remote PE node. This assumes that resiliency 856 mechanisms are in place to protect the route to the remote PE 857 nodes, and hence loss of IP reachability to a given node can only 858 mean that the node itself has failed. 860 It is worth noting here that loss of the LDP session with a PE in an 861 RG is not a reliable indicator that the remote PE itself is down. It 862 is possible, for e.g. that the remote PE encounters a local event 863 that leads to resetting the LDP session, while the PE node remains 864 operational for purpose of traffic forwarding. 866 6. ICCP Message Formats 868 This section defines the messages exchanged at the Application and 869 ICC layers. 871 6.1. Encoding ICC into LDP Messages 873 ICCP requires reliable, in-order, state-full message delivery, as 874 well as capability negotiation between PEs. The LDP protocol offers 875 all these features, and is already in wide use in the applications 876 that would also require the ICCP protocol extensions. For these 877 reasons, ICCP takes advantage of the already defined LDP protocol 878 infrastructure. 880 [RFC5036] Section 3.5 defines a generic LDP message structure. A new 881 set of LDP message types is defined to communicate the ICCP 882 information. LDP message types in the range of 0x700 to 0x7ff will be 883 used for ICCP. 885 Message types are allocated by IANA, and requested in the IANA 886 section below. 888 6.1.1. ICC Header 890 Every ICCP message comprises of an ICC specific LDP Header followed 891 by message data. The format of the ICC Header is as follows: 893 0 1 2 3 894 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 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 |U| Message Type | Message Length | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Message ID | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Type=0x0005 (ICC RG ID) | Length=4 | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | ICC RG ID | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | | 905 + + 906 | Mandatory Parameters | 907 ~ ~ 908 + + 909 | | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | | 912 + + 913 | Optional Parameters | 914 ~ ~ 915 + + 916 | | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 - U-bit 920 Unknown message bit. Upon receipt of an unknown message, if U is 921 clear (=0), a notification is returned to the message originator; 922 if U is set (=1), the unknown message is silently ignored. The 923 following sections which define messages specify a value for the 924 U-bit. 926 - Message Type 928 Identifies the type of the ICCP message, must be in the range of 929 0x0700 to 0x07ff. 931 - Message Length 933 Two octet integer specifying the total length of this message in 934 octets, excluding the U-bit, Message Type and Length fields. 936 - Message ID 938 Four octet value used to identify this message. Used by the 939 sending PE to facilitate identifying RG Notification messages 940 that may apply to this message. A PE sending an RG Notification 941 message in response to this message SHOULD include this Message 942 ID in the "NAK TLV" of the RG Notification message; see Section 943 "RG Notification Message". 945 - ICC RG ID TLV 947 A TLV of type 0x0005, length 4, containing 4 octets unsigned 948 integer designating the Redundancy Group which the sending device 949 is member of. RG ID value 0x00000000 is reserved by the protocol. 951 - Mandatory Parameters 953 Variable length set of required message parameters. Some 954 messages have no required parameters. 956 For messages that have required parameters, the required 957 parameters MUST appear in the order specified by the individual 958 message specifications in the sections that follow. 960 - Optional Parameters 962 Variable length set of optional message parameters. Many 963 messages have no optional parameters. 965 For messages that have optional parameters, the optional 966 parameters may appear in any order. 968 6.1.2. Message Encoding 970 The generic format of an ICC parameter is: 972 0 1 2 3 973 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 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 |U|F| Type | Length | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | TLV(s) | 978 ~ ~ 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 - U-bit 983 Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear 984 (=0), a notification MUST be returned to the message originator 985 and the entire message MUST be ignored; if U is set (=1), the 986 unknown TLV MUST be silently ignored and the rest of the message 987 processed as if the unknown TLV did not exist. The sections 988 following that define TLVs specify a value for the U-bit. 990 - F-bit 992 Forward unknown TLV bit. This bit applies only when the U-bit is 993 set and the LDP message containing the unknown TLV is to be 994 forwarded. If F is clear (=0), the unknown TLV is not forwarded 995 with the containing message; if F is set (=1), the unknown TLV is 996 forwarded with the containing message. The sections following 997 that define TLVs specify a value for the F-bit. By setting both 998 the U- and F-bits, a TLV can be propagated as opaque data through 999 nodes that do not recognize the TLV. 1001 - Type 1003 Fourteen bits indicating the parameter type. 1005 - Length 1007 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1008 Length fields. 1010 - TLV(s): A set of 0 or more TLVs, that vary according to the 1011 message type. 1013 6.1.3. ROID Encoding 1015 The Redundant Object Identifier (ROID) is a generic opaque handle 1016 that uniquely identifies a Redundant Object (e.g. link, bundle, VLAN, 1017 etc...) which is being protected in an RG. It is encoded as follows: 1019 0 1 2 3 1020 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | ROID | 1023 + + 1024 | | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 where: ROID is an 8 octets field encoded as an unsigned integer. The 1028 ROID value of 0 is reserved. 1030 The ROID is carried within application specific TLVs. 1032 6.2. RG Connect Message 1034 The RG Connect Message is used to establish the ICCP RG connection in 1035 addition to individual Application connections between PEs in an RG. 1036 An RG Connect message with no "Application-specific connect TLV" 1037 signals establishment of the ICCP RG connection. Whereas, an RG 1038 Connect message with a valid "Application-specific connect TLV" 1039 signals the establishment of an Application connection, in addition 1040 to the ICCP RG connection if the latter is not already established. 1042 An implementation MAY send a dedicated RG Connect message to set up 1043 the ICCP RG connection and a separate RG Connect message per client 1044 application. However, all implementations MUST support the receipt of 1045 an RG Connect message that triggers the setup of the ICCP RG 1046 connection as well as a single Application connection simultaneously. 1048 A PE sends an RG Connect Message to declare its membership in a 1049 Redundancy Group. One such message should be sent to each PE that is 1050 member of the same RG. The set of PEs to which RG Connect Messages 1051 should be transmitted is known via configuration or an auto-discovery 1052 mechanism that is outside the scope of this specification. If a 1053 device is member of multiple RGs, it MUST send separate RG Connect 1054 Messages for each RG even if the receiving device(s) happen to be the 1055 same. 1057 The format of the RG Connect Message is as follows: 1059 -i. ICC header with Message type = "RG Connect Message" (0x0700) 1060 -ii. ICC Sender Name TLV 1061 -iii. Zero or one Application-specific connect TLV 1063 The currently defined Application-specific connect TLVs are: 1065 - PW Redundancy Connect TLV 1067 - mLACP Connect TLV 1069 The details of these TLVs are discussed in the "Application TLVs" 1070 section. 1072 The RG Connect message can contain zero or one Application-specific 1073 connect TLV, but no application connect TLV can be sent more than 1074 once. 1076 6.2.1. ICC Sender Name TLV 1078 A TLV that carries the hostname of the sender encoded in UTF-8. This 1079 is used primarily for purpose of management of the RG and easing 1080 network operations. The specific format is shown below: 1082 0 1 2 3 1083 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 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 |U|F| Type = 0x0001 | Length | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | Sender Name | 1088 + +-+-+-+-+-+-+-+-+-+ 1089 ~ ~ 1090 | ... | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 - U=F=0 1095 - Type set to 0x0001 (from ICC parameter name space). 1097 - Length 1099 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1100 Length fields. 1102 - Sender Name 1104 Hostname of sending device encoded in UTF-8, and SHOULD NOT 1105 exceed 80 characters. 1107 6.3. RG Disconnect Message 1109 The RG Disconnect Message serves dual-purpose: to signal that a 1110 particular Application connection is being closed within an RG, or 1111 that the ICCP RG connection itself is being disconnected because the 1112 PE wishes to leave the RG. The format of this message is: 1114 0 1 2 3 1115 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 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 |U| Message Type=0x0701 | Message Length | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Message ID | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | Type=0x0005 (ICC RG ID) | Length=4 | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | ICC RG ID | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Disconnect Code TLV | 1126 + + 1127 | | 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | Optional Application-specific Disconnect TLV | 1130 ~ ~ 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | Optional Parameter TLVs | 1133 + + 1134 | | 1135 ~ ~ 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 - U-bit 1140 U=0 1142 - Message Type 1144 The message type for RG Disconnect Message is set to (0x0701) 1146 - Length 1148 Length of the TLV in octets excluding the U-bit, Message Type, 1149 and Message Length fields. 1151 - Message ID 1153 Defined in the "ICC Header" section above. 1155 - ICC RG ID 1157 Defined in the "ICC Header" section above. 1159 - Disconnect Code TLV 1161 The format of this TLV is as follows: 1163 0 1 2 3 1164 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 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 |U|F| Type=0x0004 | Length | 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 | ICCP Status Code | 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 - U,F Bits 1173 both U and F are set to 0. 1175 - Type 1177 set to "Disconnect Code TLV" (0x0004) 1179 - Length 1181 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1182 Length fields. 1184 - ICCP Status Code 1186 A status code that reflects the reason for the disconnect 1187 message. Allowed values are "ICCP RG Removed" and "ICCP 1188 Application Removed from RG". 1190 - Optional Application-specific Disconnect TLV 1192 Zero or one Application-specific Disconnect TLVs which are 1193 defined later in the document. If the RG Disconnect message has 1194 a status code of "RG Removed", then it MUST NOT contain any 1195 Application-specific Disconnect TLVs, as the sending PE is 1196 signaling that it has left the RG and, thus, is disconnecting the 1197 ICCP RG connection, with all associated client application 1198 connections. If the message has a status code of "Application 1199 Removed from RG", then it MUST contain exactly one Application- 1200 specific Disconnect TLV, as the sending PE is only tearing down 1201 the connection for the specified application. Other applications, 1202 and the ICCP RG connection are not to be affected. 1204 - Optional Parameter TLVs 1206 None are defined for this message in this document. This is 1207 specified to allow for future extensions. 1209 6.4. RG Notification Message 1211 A PE sends an RG Notification Message to indicate one of the 1212 following: to reject an ICCP connection, to reject an application 1213 connection, to NAK an entire message or to NAK one or more TLV(s) 1214 within a message. The Notification message can only be sent to a PE 1215 that is already part of an RG. 1217 The RG Notification Message MUST NOT be used to NAK messages or TLVs 1218 corresponding to multiple ICCP applications simultaneously. In other 1219 words, there is a limit of at most a single ICCP application per RG 1220 Notification Message. 1222 The format of the RG Notification Message is: 1224 -i. ICC header with Message type = "RG Notification Message" 1225 (0x0702) 1226 -ii. Notification Message TLVs. 1228 The currently defined Notification message TLVs are: 1230 -i. ICC Sender Name TLV 1231 -ii. NAK TLV. 1233 6.4.1. Notification Message TLVs 1235 The ICC Sender Name TLV uses the same format as in the RG Connect 1236 message, and was described above. 1238 The NAK TLV is defined as follows: 1240 0 1 2 3 1241 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 1242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 |U|F| Type=0x0002 | Length | 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 | ICCP Status Code | 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | Rejected Message ID | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | Optional TLV(s) | 1250 + + 1251 | | 1252 ~ ~ 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 - U,F Bits 1257 both U and F are set to 0. 1259 - Type 1261 set to "NAK TLV" (0x0002) 1263 - Length 1265 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1266 Length fields. 1268 - ICCP Status Code 1270 A status code that reflects the reason for the NAK TLV. Allowed 1271 values are: 1272 -i. Unknown RG (0x00010001) 1274 This code is used to reject a new incoming ICCP 1275 connection for an RG that is not configured on the local 1276 PE. When this code is used, the Rejected Message ID 1277 field MUST contain the message ID of the rejected "RG 1278 Connect" message. 1280 -ii. ICCP Connection Count Exceeded (0x00010002) 1282 This is used to reject a new incoming ICCP connection 1283 that would cause the local PE's ICCP connection count to 1284 exceed its capabilities. When this code is used, the 1285 Rejected Message ID field MUST contain the message ID of 1286 the rejected "RG Connect" message. 1288 -iii. Application Connection Count Exceeded (0x00010003) 1290 This is used to reject a new incoming application 1291 connection that would cause the local PE's ICCP 1292 connection count to exceed its capabilities. When this 1293 code is used, the Rejected Message ID field MUST contain 1294 the message ID of the rejected "RG Connect" message and 1295 the corresponding Application Connect TLV MUST be 1296 included in the "Optional TLV". 1298 -iv. Application not in RG (0x00010004) 1300 This is used to reject a new incoming application 1301 connection when the local PE doesn't support the 1302 application, or the application is not configured in the 1303 RG. When this code is used, the Rejected Message ID 1304 field MUST contain the message ID of the rejected "RG 1305 Connect" message and the corresponding Application 1306 Connect TLV MUST be included in the "Optional TLV". 1308 -v. Incompatible Protocol Version (0x00010005) 1310 This is used to reject a new incoming application 1311 connection when the local PE has an incompatible version 1312 of the application. When this code is used, the Rejected 1313 Message ID field MUST contain the message ID of the 1314 rejected "RG Connect" message and the corresponding 1315 Application Connect TLV MUST be included in the 1316 "Optional TLV". 1318 -vi. Rejected Message (0x00010006) 1320 This is used to reject an RG Application Data message, 1321 or one or more TLV(s) within the message. When this code 1322 is used, the Rejected Message ID field MUST contain the 1323 message ID of the rejected "RG Application Data" 1324 message. 1326 -vii. ICCP Administratively Disabled (0x00010007) 1328 This is used to reject any ICCP messages from a peer 1329 from which the PE is not allowed to exchange ICCP 1330 messages due to local administrative policy. 1332 - Rejected Message ID 1334 If non-zero, four octets value that identifies the peer message 1335 to which the NAK TLV refers. If zero, no specific peer message is 1336 being identified. 1338 - Optional TLV(s) 1340 A set of one or more optional TLVs. If the status code is 1341 "Rejected Message" then this field contains the TLV(s) that were 1342 rejected. If the entire message is rejected, all its TLVs MUST be 1343 present in this field; otherwise, the subset of TLVs that were 1344 rejected MUST be echoed in this field. 1346 If the status code is "Incompatible Protocol Version" then this 1347 field contains the original "Application Connect TLV" sent by the 1348 peer, in addition to the "Requested Protocol Version TLV" defined 1349 below: 1351 0 1 2 3 1352 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 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 |U|F| Type=0x0003 | Length | 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 | Connection Reference | Requested Version | 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 - U and F Bits 1361 Both are set to 0. 1363 - Type 1365 set to 0x0003 for "Requested Protocol Version TLV" 1367 - Length 1369 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1370 Length fields. 1372 - Connection Reference 1374 This field is set to the Type field of the Application specific 1375 Connect TLV that was rejected because of incompatible version. 1377 - Requested Version 1379 The version of the application supported by the transmitting 1380 device. For this version of the protocol it is set to 0x0001. 1382 6.5. RG Application Data Message 1384 The RG Application Data Message is used to transport application data 1385 between PEs within an RG. A single message can be used to carry data 1386 from only one application. Multiple application TLVs are allowed in a 1387 single message, as long as all of these TLVs belong to the same 1388 application. The format of the Application Data Message is: 1390 -i. ICC header with Message type = "RG Application Data Message" 1391 (0x703) 1392 -ii. "Application specific TLVs" 1394 The details of these TLVs are discussed in the "Application TLVs" 1395 section. All application specific TLVs in one RG Application Data 1396 Message MUST belong to a single application but MAY reference 1397 different ROs. 1399 7. Application TLVs 1401 7.1. Pseudowire Redundancy (PW-RED) Application TLVs 1403 This section discusses the ICCP TLVs for the Pseudowire Redundancy 1404 application. 1406 7.1.1. PW-RED Connect TLV 1408 This TLV is included in the RG Connect message to signal the 1409 establishment of PW-RED application connection. 1411 0 1 2 3 1412 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 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 |U|F| Type=0x0010 | Length | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | Protocol Version |A| Reserved | 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 | Optional Sub-TLVs | 1419 ~ ~ 1420 | | 1421 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 | ... | 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 - U and F Bits 1427 Both are set to 0. 1429 - Type 1431 set to 0x0010 for "PW-RED Connect TLV" 1433 - Length 1435 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1436 Length fields. 1438 - Protocol Version 1440 The version of this particular protocol for the purposes of ICCP. 1441 This is set to 0x0001. 1443 - A bit 1445 Acknowledgement Bit. Set to 1 if the sender has received a PW-RED 1446 Connect TLV from the recipient. Otherwise, set to 0. 1448 - Reserved 1450 Reserved for future use. 1452 - Optional Sub-TLVs 1454 There are no optional Sub-TLVs defined for this version of the 1455 protocol. 1457 7.1.2. PW-RED Disconnect TLV 1459 This TLV is used in an RG Disconnect Message to indicate that the 1460 connection for the PW-RED application is to be terminated. 1462 0 1 2 3 1463 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 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 |U|F| Type=0x0011 | Length | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 | Optional Sub-TLVs | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 - U and F Bits 1472 Both are set to 0. 1474 - Type 1476 set to 0x0011 for "PW-RED Disconnect TLV" 1478 - Length 1480 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1481 Length fields. 1483 - Optional Sub-TLVs 1485 The only optional Sub-TLV defined for this version of the 1486 protocol is the "PW-RED Disconnect Cause" TLV defined next: 1488 7.1.2.1. PW-RED Disconnect Cause TLV 1490 0 1 2 3 1491 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 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 |U|F| Type=0x0019 | Length | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | Disconnect Cause String | 1496 ~ ~ 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 - U and F Bits 1500 Both are set to 0. 1502 - Type 1504 set to 0x0019 for "PW-RED Disconnect Cause TLV" 1506 - Length 1508 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1509 Length fields. 1511 - Disconnect Cause String 1513 Variable length string specifying the reason for the disconnect. 1514 Used for network management. 1516 7.1.3. PW-RED Config TLV 1518 The PW-RED Config TLV is used in the RG Application Data message and 1519 has the following format: 1521 0 1 2 3 1522 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 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 |U|F| Type = 0x0012 | Length | 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | ROID | 1527 + + 1528 | | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 | PW Priority | Flags | 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 | Service Name TLV | 1533 ~ ~ 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 | PW ID TLV or Generalized PW ID TLV | 1536 ~ ~ 1537 | | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 - U and F Bits 1541 Both are set to 0. 1543 - Type 1545 set to 0x0012 for "PW-RED Config TLV" 1547 - Length 1549 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1550 Length fields. 1552 - ROID 1554 As defined in the ROID section above. 1556 - PW Priority 1558 Two octets Pseudowire Priority. Used to indicate which PW has 1559 better priority to go into Active state. Numerically lower 1560 numbers are better priority. In case of a tie, the PE with the 1561 numerically lower identifier (i.e. IP Address) has better 1562 priority. 1564 - Flags 1566 Valid values are: 1568 -i. Synchronized (0x01) 1570 Indicates that the sender has concluded transmitting all 1571 pseudowire configuration for a given service. 1573 -ii. Purge Configuration (0x02) 1575 Indicates that the pseudowire is no longer configured 1576 for PW-RED operation. 1578 - Sub-TLVs 1580 The "PW-RED Config TLV" includes the following two sub-TLVs: 1582 -i. Service Name TLV 1584 -ii. PW ID TLV or Generalized PW ID TLV 1586 The format of the sub-TLVs is as follows: 1588 7.1.3.1. Service Name TLV 1590 0 1 2 3 1591 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 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 |U|F| Type | Length | 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | Service Name | 1596 ~ ~ 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 - U and F Bits 1601 Both are set to 0. 1603 - Type 1605 set to 0x0013 for "Service Name TLV" 1607 - Length 1609 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1610 Length fields. 1612 - Service Name 1614 The name of the L2VPN service instance encoded in UTF-8 format 1615 and up to 80 character in length. 1617 7.1.3.2. PW ID TLV 1619 This TLV is used to communicate the configuration of PWs for VPWS. 1621 0 1 2 3 1622 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 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 |U|F| Type | Length | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 | Peer ID | 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 | Group ID | 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 | PW ID | 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 - U and F Bits 1635 Both are set to 0. 1637 - Type 1639 set to 0x0014 for "PW ID TLV" 1641 - Length 1643 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1644 Length fields. 1646 - Peer ID 1648 Four octet LDP Router ID of the peer at the far end of the PW. 1650 - Group ID 1652 Same as Group ID in [RFC4447] section 5.2. 1654 - PW ID 1656 Same as PW ID in [RFC4447] section 5.2. 1658 7.1.3.3. Generalized PW ID TLV 1660 This TLV is used to communicate the configuration of PWs for VPLS. 1662 0 1 2 3 1663 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 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1665 |U|F| Type = 0x0015 | Length | 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 | AGI Type | Length | Value | 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 ~ AGI Value (contd.) ~ 1670 | | 1671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1672 | AII Type | Length | Value | 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 ~ SAII Value (contd.) ~ 1675 | | 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | AII Type | Length | Value | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 ~ TAII Value (contd.) ~ 1680 | | 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 - U and F bits 1685 both set to 0. 1687 - Type 1689 set to 0x0015 1691 - Length 1693 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1694 Length fields. 1696 - AGI, AII, SAII and TAII 1698 defined in [RFC4447] section 5.3.2. 1700 7.1.4. PW-RED State TLV 1702 The PW-RED State TLV is used in the RG Application Data Message. This 1703 TLV is used by a device to report its PW status to other members in 1704 the RG. 1706 The format of this TLV is as follows: 1708 0 1 2 3 1709 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 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 |U|F| Type=0x0016 | Length | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | ROID | 1714 + + 1715 | | 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 | Local PW State | 1718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1719 | Remote PW State | 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 - U and F Bits 1724 Both are set to 0. 1726 - Type 1728 set to 0x0016 for PW-RED State TLV. 1730 - Length 1732 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1733 Length fields. 1735 - ROID 1737 As defined in the ROID section above. 1739 - Local PW State 1741 The status of the PW as determined by the sending PE, encoded in 1742 the same format as the "Status Code" field of the "PW Status TLV" 1743 defined in [RFC4447]. 1745 - Remote PW State 1747 The status of the PW as determined by the remote peer of the 1748 sending PE. Encoded in the same format as the "Status Code" field 1749 of the "PW Status TLV" defined in [RFC4447]. The same code points 1750 listed above are used here as well. 1752 7.1.5. PW-RED Synchronization Request TLV 1754 The PW-RED Synchronization Request TLV is used in the RG Application 1755 Data message. This TLV is used by a device to request from its peer 1756 to retransmit configuration or operational state. The following 1757 information can be requested: 1759 - configuration and/or state for one or more pseudowires 1761 - configuration and/or state for all pseudowires 1763 - configuration and/or state for all pseudowires in a given service 1765 The format of the TLV is as follows: 1767 0 1 2 3 1768 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 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 |U|F| Type=0x0017 | Length | 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1772 | Request Number |C|S| Request Type | 1773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1774 | Optional Sub-TLVs | 1775 ~ ~ 1776 | | 1777 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 | ... | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 - U and F Bits 1783 Both are set to 0. 1785 - Type 1787 set to 0x0017 for "PW-RED Synchronization Request TLV" 1789 - Length 1791 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1792 Length fields. 1794 - Request Number 1796 2 octets. Unsigned integer uniquely identifying the request. Used 1797 to match the request with a response. The value of 0 is reserved 1798 for unsolicited synchronization, and MUST NOT be used in the PW- 1799 RED Synchronization Request TLV. 1801 - C Bit 1803 Set to 1 if request is for configuration data. Otherwise, set to 1804 0. 1806 - S Bit 1808 Set to 1 if request is for running state data. Otherwise, set to 1809 0. 1811 - Request Type 1813 14-bits specifying the request type, encoded as follows: 1815 0x00 Request Data for specified pseudowire(s) 1816 0x01 Request Data for all pseudowires in specified service(s) 1817 0x3FFF Request All Data 1819 - Optional Sub-TLVs 1821 A set of zero or more TLVs, as follows: 1823 If the Request Type field is set to (0x00), then this field 1824 contains one or more PW ID TLV(s) or Generalized PW ID TLV(s). If 1825 the Request Type field is set to (0x01), then this field contains 1826 one or more Service Name TLV(s). If the Request Type field is set 1827 to (0x3FFF), then this field MUST be empty. 1829 7.1.6. PW-RED Synchronization Data TLV 1831 The PW-RED Synchronization Data TLV is used in the RG Application 1832 Data mesage. A pair of these TLVs is used by a device to delimit a 1833 set of TLVs that are sent in response to a PW-RED Synchronization 1834 Request TLV. The delimiting TLVs signal the start and end of the 1835 synchronization data, and associate the response with its 1836 corresponding request via the Request Number field. 1838 The PW-RED Synchronization Data TLVs are also used for unsolicited 1839 advertisements of complete PW-RED configuration and operational state 1840 data. In this case, the Request Number field MUST be set to 0. 1842 This TLV has the following format: 1844 0 1 2 3 1845 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 1846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1847 |U|F| Type=0x0018 | Length | 1848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1849 | Request Number | Flags | 1850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1852 - U and F Bits 1854 Both are set to 0. 1856 - Type 1858 set to 0x0018 for "PW-RED Synchronization Data TLV" 1860 - Length 1862 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1863 Length fields. 1865 - Request Number 1867 2 octets. Unsigned integer identifying the Request Number from 1868 the "PW-RED Synchronization Request TLV" which solicited this 1869 synchronization data response. 1871 - Flags 1873 2 octets, response flags encoded as follows: 1875 0x00 Synchronization Data Start 1876 0x01 Synchronization Data End 1878 7.2. Multi-chassis LACP (mLACP) Application TLVs 1880 This section discusses the ICCP TLVs for Ethernet attachment circuit 1881 redundancy using the multi-chassis LACP (mLACP) application. 1883 7.2.1. mLACP Connect TLV 1885 This TLV is included in the RG Connect message to signal the 1886 establishment of mLACP application connection. 1888 0 1 2 3 1889 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 1890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1891 |U|F| Type=0x0030 | Length | 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 | Protocol Version |A| Reserved | 1894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 | Optional Sub-TLVs | 1896 ~ ~ 1897 | | 1898 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 | ... | 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1902 - U and F Bits 1904 Both are set to 0. 1906 - Type 1908 set to 0x0030 for "mLACP Connect TLV" 1910 - Length 1912 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1913 Length fields. 1915 - Protocol Version 1917 The version of this particular protocol for the purposes of ICCP. 1918 This is set to 0x0001. 1920 - A Bit 1922 Acknowledgement Bit. Set to 1 if the sender has received an mLACP 1923 Connect TLV from the recipient. Otherwise, set to 0. 1925 - Reserved 1927 Reserved for future use. 1929 - Optional Sub-TLVs 1931 There are no optional Sub-TLVs defined for this version of the 1932 protocol. 1934 7.2.2. mLACP Disconnect TLV 1936 This TLV is used in an RG Disconnect Message to indicate that the 1937 connection for the mLACP application is to be terminated. 1939 0 1 2 3 1940 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 1941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1942 |U|F| Type=0x0031 | Length | 1943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1944 | Optional Sub-TLVs | 1945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1947 - U and F Bits 1949 Both are set to 0. 1951 - Type 1953 set to 0x0031 for "mLACP Disconnect TLV" 1955 - Length 1957 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1958 Length fields. 1960 - Optional Sub-TLVs 1962 The only optional Sub-TLV defined for this version of the 1963 protocol is the "mLACP Disconnect Cause" TLV defined next: 1965 7.2.2.1. mLACP Disconnect Cause TLV 1967 0 1 2 3 1968 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 1969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1970 |U|F| Type=0x003A | Length | 1971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 | Disconnect Cause String | 1973 ~ ~ 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1976 - U and F Bits 1978 Both are set to 0. 1980 - Type 1982 set to 0x003A for "mLACP Disconnect Cause TLV" 1984 - Length 1986 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1987 Length fields. 1989 - Disconnect Cause String 1991 Variable length string specifying the reason for the disconnect. 1992 Used for network management. 1994 7.2.3. mLACP System Config TLV 1996 The mLACP System Config TLV is sent in the RG Application Data 1997 message. This TLV announces the local node's LACP System Parameters 1998 to the RG peers. 2000 0 1 2 3 2001 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 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2003 |U|F| Type=0x0032 | Length | 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 | System ID | 2006 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2007 | | System Priority | 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 | Node ID | 2010 +-+-+-+-+-+-+-+-+ 2012 - U and F Bits 2014 Both are set to 0. 2016 - Type 2018 set to 0x0032 for "mLACP System Config TLV" 2020 - Length 2022 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2023 Length fields. 2025 - System ID 2027 6 octets field encoding the System ID used by LACP as specified 2028 in [IEEE-802.1AX] section 5.3.2. 2030 - System Priority 2032 2 octets encoding the LACP System Priority as defined in [IEEE- 2033 802.1AX] section 5.3.2. 2035 - Node ID 2037 One octet, LACP node ID. Used to ensure that the LACP Port 2038 Numbers are unique across all devices in an RG. Valid values are 2039 in the range 0 - 7. Uniqueness of the LACP Port Numbers across 2040 RG members is ensured by encoding the Port Numbers as follows: 2042 - Most significant bit always set to 1 2043 - The next 3 most significant bits set to Node ID 2044 - Remaining 12 bits freely assigned by the system 2046 7.2.4. mLACP Aggregator Config TLV 2048 The mLACP Aggregator Config TLV is sent in the RG Application Data 2049 message. This TLV is used to notify RG peers about the local 2050 configuration state of an aggregator. 2052 0 1 2 3 2053 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 2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2055 |U|F| Type=0x0036 | Length | 2056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2057 | ROID | 2058 + + 2059 | | 2060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 | Aggregator ID | MAC Address | 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2063 | | 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 | Actor Key | Member Ports Priority | 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 | Flags | Agg Name Len | Aggregator Name | 2068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2069 ~ ~ 2070 | ... | 2071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 - U and F Bits 2075 Both are set to 0. 2077 - Type 2079 set to 0x0036 for "mLACP Aggregator Config TLV" 2081 - Length 2083 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2084 Length fields. 2086 - ROID 2088 Defined in the 'ROID Encoding' section above. 2090 - Aggregator ID 2092 Two octets, LACP Aggregator Identifier as specified in [IEEE- 2093 802.1AX] section 5.4.6 2095 - MAC Address 2097 Six octets encoding the Aggregator MAC address. 2099 - Actor Key 2101 Two octets, LACP Actor Key for the corresponding Aggregator, as 2102 specified in [IEEE-802.1AX] section 5.3.5. 2104 - Member Ports Priority 2106 Two octets, LACP administrative port priority associated with all 2107 interfaces bound to the Aggregator. This field is valid only when 2108 the "Flags" field has "Priority Set" asserted. 2110 - Flags 2112 Valid values are: 2114 -i. Synchronized (0x01) 2116 Indicates that the sender has concluded transmitting all 2117 Aggregator configuration information. 2119 -ii. Purge Configuration (0x02) 2121 Indicates that the Aggregator is no longer configured 2122 for mLACP operation. 2124 -iii. Priority Set (0x04) 2126 Indicates that the "Member Ports Priority" field is 2127 valid. 2129 - Agg Name Len 2131 One octet, length of the "Aggregator Name" field in octets. 2133 - Aggregator Name 2135 Aggregator name encoded in UTF-8 format, up to a maximum of 20 2136 characters. Used for ease of management. 2138 7.2.5. mLACP Port Config TLV 2140 The mLACP Port Config TLV is sent in the RG Application Data message. 2141 This TLV is used to notify RG peers about the local configuration 2142 state of a port. 2144 0 1 2 3 2145 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 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2147 |U|F| Type=0x0033 | Length | 2148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2149 | Port Number | MAC Address | 2150 +-------------------------------+ + 2151 | | 2152 +---------------------------------------------------------------+ 2153 | Actor Key | Port Priority | 2154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2155 | Port Speed | 2156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2157 | Flags | Port Name Len | Port Name | 2158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2159 ~ ~ 2160 | ... | 2161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2163 - U and F Bits 2165 Both are set to 0. 2167 - Type 2169 set to 0x0033 for "mLACP Port Config TLV" 2171 - Length 2173 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2174 Length fields. 2176 - Port Number 2178 Two octets, LACP Port Number for the corresponding interface as 2179 specified in [IEEE-802.1AX] section 5.3.4. The Port Number MUST 2180 be encoded with the Node ID as was discussed above. 2182 - MAC Address 2184 Six octets encoding the port MAC address. 2186 - Actor Key 2188 Two octets, LACP Actor Key for the corresponding interface, as 2189 specified in [IEEE-802.1AX] section 5.3.5. 2191 - Port Priority 2193 Two octets, LACP administrative port priority for the 2194 corresponding interface, as specified in [IEEE-802.1AX] section 2195 5.3.4. This field is valid only when the "Flags" field has 2196 "Priority Set" asserted. 2198 - Port Speed 2200 Four octets integer encoding the port's current bandwidth in 2201 units of 1,000,000 bits per second. This field corresponds to the 2202 ifHighSpeed object of IF-MIB [RFC2863]. 2204 - Flags 2206 Valid values are: 2208 -i. Synchronized (0x01) 2210 Indicates that the sender has concluded transmitting all 2211 member link port configurations for a given Aggregator. 2213 -ii. Purge Configuration (0x02) 2215 Indicates that the port is no longer configured for 2216 mLACP operation. 2218 -iii. Priority Set (0x04) 2220 Indicates that the "Port Priority" field is valid. 2222 - Port Name Len 2224 One octet, length of the "Port Name" field in octets. 2226 - Port Name 2228 Port (interface) name encoded in UTF-8 format, up to a maximum of 2229 20 characters. 2231 7.2.6. mLACP Port Priority TLV 2233 The mLACP Port Priority TLV is sent in the RG Application Data 2234 message. This TLV is used by a device to either advertise its 2235 operational Port Priority to other members in the RG, or to 2236 authoritatively request that a particular member of an RG change its 2237 port priority. 2239 0 1 2 3 2240 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 2241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 |U|F| Type=0x0034 | Length | 2243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2244 | OpCode | Port Number | 2245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2246 | Aggregator ID | Last Port Priority | 2247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2248 | Current Port Priority | 2249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2251 - U and F Bits 2253 Both are set to 0. 2255 - Type 2257 set to 0x0034 for "mLACP Port Priority TLV" 2259 - Length 2261 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2262 Length fields. 2264 - OpCode 2266 Two octets identifying the operational code-point for the TLV, 2267 encoded as follows: 2269 0x00 Local Priority Change Notification 2270 0x01 Remote Request for Priority Change 2272 - Port Number 2274 2 octets field representing the LACP Port Number as specified in 2275 [IEEE-802.1AX] section 5.3.4. When the value of this field is 0, 2276 it denotes all ports bound to the Aggregator specified in the 2277 "Aggregator ID" field. When non-zero, the Port Number MUST be 2278 encoded with the Node ID as was discussed above. 2280 - Aggregator ID 2282 Two octets, LACP Aggregator Identifier as specified in [IEEE- 2283 802.1AX] section 5.4.6 2285 - Last Port Priority 2287 Two octets, LACP port priority for the corresponding interface, 2288 as specified in [IEEE-802.1AX] section 5.3.4. For local ports, 2289 this field encodes the previous operational value of port 2290 priority. For remote ports, this field encodes the operational 2291 port priority last known to the PE via notifications received 2292 from its peers in the RG. 2294 - Current Port Priority 2296 Two octets, LACP port priority for the corresponding interface, 2297 as specified in [IEEE-802.1AX] section 5.3.4. For local ports, 2298 this field encodes the new operational value of port priority 2299 being advertised by the PE. For remote ports, this field 2300 specifies the new port priority being requested by the PE. 2302 7.2.7. mLACP Port State TLV 2304 The mLACP Port State TLV is used in the RG Application Data message. 2305 This TLV is used by a device to report its LACP port status to other 2306 members in the RG. 2308 0 1 2 3 2309 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 2310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2311 |U|F| Type=0x0035 | Length | 2312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2313 | Partner System ID | 2314 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2315 | | Partner System Priority | 2316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2317 | Partner Port Number | Partner Port Priority | 2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2319 | Partner Key | Partner State | Actor State | 2320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2321 | Actor Port Number | Actor Key | 2322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2323 | Selected | Port State | Aggregator ID | 2324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2326 - U and F Bits 2328 Both are set to 0. 2330 - Type 2332 set to 0x0035 for "mLACP Port State TLV" 2334 - Length 2336 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2337 Length fields. 2339 - Partner System ID 2341 6 octets, the LACP Partner System ID for the corresponding 2342 interface, encoded as a MAC address as specified in [IEEE- 2343 802.1AX] section 5.4.2.2 item r. 2345 - Partner System Priority 2347 2 octets field specifying the LACP Partner System Priority as 2348 specified in [IEEE-802.1AX] section 5.4.2.2 item q. 2350 - Partner Port Number 2352 2 octets encoding the LACP Partner Port Number as specified in 2353 [IEEE-802.1AX] section 5.4.2.2 item u. The Port Number MUST be 2354 encoded with the Node ID as was discussed above. 2356 - Partner Port Priority 2358 2 octets field encoding the LACP Partner Port Priority as 2359 specified in [IEEE-802.1AX] section 5.4.2.2 item t. 2361 - Partner Key 2363 2 octets field representing the LACP Partner Key as defined in 2364 [IEEE-802.1AX] section 5.4.2.2 item s. 2366 - Partner State 2368 1 octet field encoding the LACP Partner State Variable as defined 2369 in [IEEE-802.1AX] section 5.4.2.2 item v. 2371 - Actor State 2373 1 octet encoding the LACP Actor's State Variable for the port as 2374 specified in [IEEE-802.1AX] section 5.4.2.2 item m. 2376 - Actor Port Number 2378 2 octets field representing the LACP Actor Port Number as 2379 specified in [IEEE-802.1AX] section 5.3.4. The Port Number MUST 2380 be encoded with the Node ID as was discussed above. 2382 - Actor Key 2384 2 octet field encoding the LACP Actor Operational Key as 2385 specified in [IEEE-802.1AX] section 5.3.5. 2387 - Selected 2389 1 octet encoding the LACP 'Selected' variable, defined in [IEEE- 2390 802.1AX] section 5.4.8, as follows: 2392 0x00 SELECTED 2393 0x01 UNSELECTED 2394 0x02 STANDBY 2396 - Port State 2398 1 octet encoding the operational state of the port as follows: 2399 0x00 Up 2400 0x01 Down 2401 0x02 Administrative Down 2402 0x03 Test (e.g. IEEE 802.3ah OAM Intrusive Loopback mode) 2404 - Aggregator ID 2406 Two octets, LACP Aggregator Identifier to which this port is 2407 bound based on the outcome of the LACP selection logic. 2409 7.2.8. mLACP Aggregator State TLV 2411 The mLACP Aggregator State TLV is used in the RG Application Data 2412 message. This TLV is used by a device to report its Aggregator status 2413 to other members in the RG. 2415 0 1 2 3 2416 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 2417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2418 |U|F| Type=0x0037 | Length | 2419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2420 | Partner System ID | 2421 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2422 | | Partner System Priority | 2423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 | Partner Key | Aggregator ID | 2425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2426 | Actor Key | Agg State | 2427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2429 - U and F Bits 2431 Both are set to 0. 2433 - Type 2435 set to 0x0037 for "mLACP Aggregator State TLV" 2437 - Length 2439 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2440 Length fields. 2442 - Partner System ID 2444 6 octets, the LACP Partner System ID for the corresponding 2445 interface, encoded as a MAC address as specified in [IEEE- 2446 802.1AX] section 5.4.2.2 item r. 2448 - Partner System Priority 2450 2 octets field specifying the LACP Partner System Priority as 2451 specified in [IEEE-802.1AX] section 5.4.2.2 item q. 2453 - Partner Key 2455 2 octets field representing the LACP Partner Key as defined in 2456 [IEEE-802.1AX] section 5.4.2.2 item s. 2458 - Aggregator ID 2460 Two octets, LACP Aggregator Identifier as specified in [IEEE- 2461 802.1AX] section 5.4.6 2463 - Actor Key 2465 2 octet field encoding the LACP Actor Operational Key as 2466 specified in [IEEE-802.1AX] section 5.3.5. 2468 - Agg State 2470 1 octet encoding the operational state of the Aggregator as 2471 follows: 2472 0x00 Up 2473 0x01 Down 2474 0x02 Administrative Down 2475 0x03 Test (e.g. IEEE 802.3ah OAM Intrusive Loopback mode) 2477 7.2.9. mLACP Synchronization Request TLV 2479 The mLACP Synchronization Request TLV is used in the RG Application 2480 Data message. This TLV is used by a device to request from its peer 2481 to re-transmit configuration or operational state. The following 2482 information can be requested: 2484 - system configuration and/or state 2486 - configuration and/or state for a specific port 2488 - configuration and/or state for all ports with a specific LACP key 2490 - configuration and/or state for all mLACP ports 2492 - configuration and/or state for a specific aggregator 2494 - configuration and/or state for all aggregators with a specific 2495 LACP key 2497 - configuration and/or state for all mLACP aggregators 2499 The format of the TLV is as follows: 2501 0 1 2 3 2502 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 2503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2504 |U|F| Type=0x0038 | Length | 2505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2506 | Request Number |C|S| Request Type | 2507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2508 | Port Number / Aggregator ID | Actor Key | 2509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2511 - U and F Bits 2513 Both are set to 0. 2515 - Type 2517 set to 0x0038 for "mLACP Synchronization Request TLV" 2519 - Length 2521 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2522 Length fields. 2524 - Request Number 2526 2 octets. Unsigned integer uniquely identifying the request. Used 2527 to match the request with a response. The value of 0 is reserved 2528 for unsolicited synchronization, and MUST NOT be used in the 2529 mLACP Synchronization Request TLV. 2531 - C Bit 2533 Set to 1 if request is for configuration data. Otherwise, set to 2534 0. 2536 - S Bit 2538 Set to 1 if request is for running state data. Otherwise, set to 2539 0. 2541 - Request Type 2543 14-bits specifying the request type, encoded as follows: 2545 0x00 Request System Data 2546 0x01 Request Aggregator Data 2547 0x02 Request Port Data 2548 0x3FFF Request All Data 2550 - Port Number / Aggregator ID 2552 2 octets. When Request Type field is set to 'Request Port Data', 2553 this field encodes the LACP Port Number for the requested port. 2554 When the Request Type field is set to 'Request Aggregator Data', 2555 this field encodes the Aggregator ID of the requested Aggregator. 2556 When the value of this field is 0, it denotes that all ports (or 2557 Aggregators), whose LACP Key is specified in the "Actor Key" 2558 field, are being requested. 2560 - Actor Key 2562 Two octets, LACP Actor key for the corresponding port or 2563 Aggregator. When the value of this field is 0 (and the Port 2564 Number/Aggregator ID field is 0 as well), it denotes that 2565 information for all ports or Aggregators in the system is being 2566 requested. 2568 7.2.10. mLACP Synchronization Data TLV 2570 The mLACP Synchronization Data TLV is used in the RG Application Data 2571 message. A pair of these TLVs is used by a device to delimit a set of 2572 TLVs that are being transmitted in response to an mLACP 2573 Synchronization Request TLV. The delimiting TLVs signal the start and 2574 end of the synchronization data, and associate the response with its 2575 corresponding request via the 'Request Number' field. 2577 The mLACP Synchronization Data TLVs are also used for unsolicited 2578 advertisements of complete mLACP configuration and operational state 2579 data. The 'Request Number' field MUST be set to 0 in this case. For 2580 such unsolicited synchronization, the PE MUST advertise all system, 2581 Aggregator and port information as done during the initialization 2582 sequence. 2584 This TLV has the following format: 2586 0 1 2 3 2587 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 2588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2589 |U|F| Type=0x0039 | Length | 2590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2591 | Request Number | Flags | 2592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2594 - U and F Bits 2596 Both are set to 0. 2598 - Type 2600 set to 0x0039 for "mLACP Synchronization Data TLV" 2602 - Length 2604 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2605 Length fields. 2607 - Request Number 2609 2 octets. Unsigned integer identifying the Request Number from 2610 the "mLACP Synchronization Request TLV" which solicited this 2611 synchronization data response. 2613 - Flags 2615 2 octets, response flags encoded as follows: 2617 0x00 Synchronization Data Start 2618 0x01 Synchronization Data End 2620 8. LDP Capability Negotiation 2622 As requited in [RFC5561] the following TLV is defined to indicate the 2623 ICCP capability: 2624 0 1 2 3 2625 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 2626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2627 |U|F| TLV Code Point=0x700 | Length | 2628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2629 |S| Reserved | Reserved | VER/Maj | Ver/Min | 2630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2631 where: 2633 - U-bit 2635 SHOULD be 1 (ignore if not understood). 2637 - F-bit 2639 SHOULD be 0 (don't forward if not understood). 2641 - TLV Code Point 2643 The TLV type, which identifies a specific capability. The ICCP 2644 code point is requested in the IANA allocation section below. 2646 - S-bit The State Bit indicates whether the sender is advertising 2647 or withdrawing the ICCP capability. The State bit is used as 2648 follows: 2649 1 - The TLV is advertising the capability specified by the 2650 TLV Code Point. 2652 0 - The TLV is withdrawing the capability specified by the 2653 TLV Code Point. 2655 - Ver/Maj 2657 The major version revision of the ICCP protocol, this document 2658 specifies 1.0. This field is then set to 1 2660 - Ver/Min 2662 The minor version revision of the ICCP protocol, this document 2663 specifies 1.0. This field is then set to 0 2665 ICCP capability is advertised to a LDP peer if there is at least one 2666 RG enabled on the local PE. 2668 9. Client Applications 2670 9.1. Pseudowire Redundancy Application Procedures 2672 This section defines the procedures for the Pseudowire Redundancy 2673 (PW-RED) Application. 2675 9.1.1. Initial Setup 2677 When an RG is configured on a system and multi-chassis pseudowire 2678 redundancy is enabled in that RG, the PW-RED application MUST send an 2679 "RG Connect" message with "PW-RED Connect TLV" to each PE that is a 2680 member of the same RG. The sending PE MUST set the A bit to 1 if it 2681 has already received a "PW-RED Connect TLV" from its peer; otherwise, 2682 the PE MUST set the A bit to 0. If a PE, that has sent the TLV with 2683 the A bit set to 0, receives a "PW-RED Connect TLV" from a peer, it 2684 MUST repeat its advertisement with the A bit set to 1. The PW-RED 2685 application connection is considered to be operational when both PEs 2686 have sent and received "PW-RED Connect TLVs" with the A bit set to 1. 2687 Once the application connection becomes operational, the two devices 2688 can start exchanging "RG Application Data" messages for the PW-RED 2689 application. 2691 If a system receives an "RG Connect" message with "PW-RED Connect 2692 TLV" that has a differing Protocol Version, it must follow the 2693 procedures outlined in the "Application Versioning" section above. 2695 When the PW-RED application is disabled on the device, or is 2696 unconfigured for the RG in question, the system MUST send an "RG 2697 Disconnect" message with "PW-RED Disconnect TLV". 2699 9.1.2. Pseudowire Configuration Synchronization 2701 A system MUST advertise its local PW configuration to other PEs that 2702 are members of the same RG. This allows the PEs to build a view of 2703 the redundant nodes and pseudowires that are protecting the same 2704 service instances. The advertisement MUST be initiated when the PW- 2705 RED application connection first comes up. To that end, the system 2706 sends "RG Application Data" messages with "PW-RED Config TLVs" as 2707 part of an unsolicited synchronization. A PE MUST use a pair of "PW- 2708 RED Synchronization Data TLVs" to delimit the set of TLVs that are 2709 being sent as part of this unsolicited advertisement. 2711 In the case of a configuration change, a PE MUST re-advertise the 2712 most up to date information for the affected pseudowires. 2714 As part of the configuration synchronization, a PE advertizes the 2715 ROID associated with the pseudowire. This is used to correlate the 2716 pseudowires that are protecting each other on different PEs. A PE 2717 also advertizes a priority value that is used to determine the 2718 precedence of a given pseudowire to assume the Active role in a 2719 redundant setup. Furthermore, a PE advertizes a Service Name that is 2720 global in the context of an RG and is used to identify which 2721 pseudowires belong to the same service. Finally, a PE also advertizes 2722 the pseudowire identifier as part of this synchronization. 2724 9.1.3. Pseudowire Status Synchronization 2726 The mechanism for synchronizing pseudowire state depends on whether 2727 or not an AC redundancy mechanism is in use. If an AC mechanism is in 2728 use, then on a given PE, the forwarding status of the PW (Active or 2729 Standby) is derived from the state of the associated AC(s). This 2730 simplifies the operation of the multi-chassis redundancy solution 2731 (Figure 1) and eliminates the possibility of deadlock conditions 2732 between the AC and PW redundancy mechanisms. The rules by which the 2733 PW state is derived from the AC state are as follows: 2735 - VPWS 2737 For VPWS, there's a single AC per service instance. If the AC is 2738 Active, then the PW status should be Active. If the AC is 2739 Standby, then the PW status should be Standby. 2741 - VPLS 2743 For VPLS, there could be multiple ACs per service instance (i.e. 2744 VFI). If AT LEAST ONE AC is Active, then the PW status should be 2745 Active. If ALL ACs are Standby, then the PW status should be 2746 Standby. 2748 In this case, the PW-RED application does not synchronize PW status 2749 across chassis, per se. Rather, the AC Redundancy application should 2750 synchronize AC status between chassis, in order to determine which AC 2751 (and subsequently which PE) is Active or Standby for a given service. 2752 When that is determined, each PE will then adjust its local PWs state 2753 according to the rules described above. The reduncancy bit described 2754 in [RED-BIT] is used for this purpose. 2756 On the other hand, if an AC redundancy mechanism is not in use, then 2757 the PW-RED application is used to synchronize pseudowire state. This 2758 is done by sending the "PW-RED State TLV" whenever the pseudowire 2759 state changes on a PE. This includes changes to the local end as 2760 well as the remote end of the pseudowire. 2762 A PE may request that its peer retransmit previously advertised PW- 2763 RED state. This is useful for instance when the PE is recovering from 2764 a soft failure. To request such retransmission, a PE MUST send a set 2765 of one or more "PW-RED Synchronization Request TLVs". 2767 A PE MUST respond to a "PW-RED Synchronization Request TLV" by 2768 sending the requested data in a set of one or more PW-RED TLVs 2769 delimited by a pair of "PW-RED Synchronization Data TLVs". The TLVs 2770 comprising the response MUST be ordered such that the Synchronization 2771 Response TLV with the "Synchronization Data Start" flag precedes the 2772 various other PW-RED TLVs encoding the requested data. These, in 2773 turn, MUST precede the Synchronization Data TLV with the 2774 "Synchronization Data End" flag. It is worth noting that the response 2775 may span across multiple RG Application Data messages; however, the 2776 above TLV ordering MUST be retained across messages, and only a 2777 single pair of Synchronization Data TLVs must be used to delimit the 2778 response across all Application Data Messages. 2780 A PE MAY re-advertise its PW-RED state in an unsolicited manner. This 2781 is done by sending the appropriate config and state TLVs delimited by 2782 a pair of "PW-RED Synchronization Data TLVs" and using a 'Request 2783 Number' of 0. 2785 While a PE has a pending synchronization request for a pseudowire or 2786 a service, it SHOULD silently ignore all TLVs for said pseudowire or 2787 service that are received prior to the synchronization response and 2788 which carry the same type of information being requested. This saves 2789 the system from the burden of updating state that will ultimately be 2790 overwritten by the synchronization response. Note that TLVs 2791 pertaining to other pseudowires or services are to continue to be 2792 processed per normal in the interim. 2794 If a PE receives a synchronization request for a pseudowire or 2795 service that doesn't exist or is not known to the PE, then it MUST 2796 trigger an unsolicited synchronization of all pseudowire information 2797 (i.e. replay the initialization sequence). 2799 9.1.4. PE Node Failure 2801 When a PE node detects that a remote PE, that is member of the same 2802 RG, has gone down, the local PE examines if it has redundant PWs for 2803 the affected services. If the local PE has the highest priority 2804 (after the failed PE) then it becomes the active node for the 2805 services in question, and subsequently activates its associated PWs. 2807 9.2. Attachment Circuit Redundancy Application Procedures 2809 9.2.1. Common AC Procedures 2811 This section describes generic procedures for AC Redundancy 2812 applications, independent of the type of the AC (ATM, FR or 2813 Ethernet). 2815 9.2.2. AC Failure 2817 When the AC Redundancy mechanism on the Active PE detects a failure 2818 of the AC, it should send an ICCP Application Data message to inform 2819 the redundant PEs of the need to take over. The AC failures can be 2820 categorized into the following scenarios: 2822 - Failure of CE interface connecting to PE 2824 - Failure of CE uplink to PE 2826 - Failure of PE interface connecting to CE 2828 9.2.3. PE Node Failure 2830 When a PE node detects that a remote PE, that is member of the same 2831 RG, has gone down, the local PE examines if it has redundant ACs for 2832 the affected services. If the local PE has the highest priority 2833 (after the failed PE) then it becomes the active node for the 2834 services in question, and subsequently activates its associated ACs. 2836 9.2.4. PE Isolation 2838 When a PE node detects that is has been isolated from the core 2839 network (i.e. all core facing interfaces/links are not operational), 2840 then it should instruct its AC Redundancy mechanism to change the 2841 status of any active ACs to Standby. The AC Redundancy application 2842 should then send ICCP Application Data messages in order to trigger 2843 failover to a standby PE. 2845 9.2.5. Ethernet AC Procedures 2847 9.2.6. Multi-chassis LACP (mLACP) Application Procedures 2849 This section defines the procedures that are specific to the multi- 2850 chassis LACP (mLACP) application. 2852 9.2.6.1. Initial Setup 2854 When an RG is configured on a system and mLACP is enabled in that RG, 2855 the mLACP application MUST send an "RG Connect" message with "mLACP 2856 Connect TLV" to each PE that is member of the same RG. The sending PE 2857 MUST set the A bit to 1 in the said TLV if it has received a 2858 corresponding "mLACP Connect TLV" from its peer PE; otherwise, the 2859 sending PE MUST set the A bit to 0. If a PE receives an "mLACP 2860 Connect TLV" from its peer after sending the said TLV with the A bit 2861 set to 0, it MUST resend the TLV with the A bit set to 1. A system 2862 considers the mLACP application connection to be operational when it 2863 has sent and received "mLACP Connect TLVs" with the A bit set to 1. 2864 When the mLACP application connection between a pair of PEs is 2865 operational, the two devices can start exchanging "RG Application 2866 Data" messages for the mLACP application. This involves having each 2867 PE advertise its mLACP configuration and operational state in an 2868 unsolicited manner. A PE SHOULD subscribe to the following order when 2869 advertising its mLACP state upon initial application connection 2870 setup: 2872 - Advertise system configuration 2873 - Advertise Aggregator configuration 2874 - Advertise port configuration 2875 - Advertise Aggregator state 2876 - Advertise port state 2878 A PE MUST use a pair of "mLACP Synchronization Data TLVs" to delimit 2879 the entire set of TLVs that are being sent as part of this 2880 unsolicited advertisement. 2882 If a system receives an "RG Connect" message with "mLACP Connect TLV" 2883 that has a differing Protocol Version, it MUST follow the procedures 2884 outlined in the "Application Versioning" section above. 2886 After the mLACP application connection has been established, every PE 2887 MUST communicate its system level configuration to its peers via the 2888 use of "mLACP System Config TLV". This allows every PE to discover 2889 the Node ID and the locally configured System ID and System Priority 2890 values of its peers. 2892 If a PE receives an "mLACP System Config TLV" from a remote peer 2893 advertising the same Node ID value as the local system, then the PE 2894 MUST respond with an "RG Notification Message" to NAK the "mLACP 2895 System Config TLV". The PE MUST suspend the mLACP application until a 2896 satisfactory "mLACP System Config TLV" is received from the peer. It 2897 SHOULD also raise an alarm to alert the operator. Furthermore, if a 2898 PE receives a NAK for an "mLACP System Config TLV" that it has 2899 advertised, the PE MUST suspend the mLACP application and SHOULD 2900 raise an alarm to alert the network operator of potential device 2901 mis-configuration. 2903 If a PE receives an "mLACP System Config TLV" from a new peer 2904 advertising the same Node ID value as another existing peer with 2905 which the local system has an established mLACP Application 2906 connection, then the PE MUST respond to the new peer with an "RG 2907 Notification Message" to NAK the "mLACP System Config TLV" and MUST 2908 ignore the offending TLV. 2910 If the Node ID of a particular PE changes due to administrative 2911 configuration action, the PE MUST then inform its peers to purge the 2912 configuration of all previously advertised ports and/or aggregators, 2913 and MUST replay the initialization sequence by sending an unsolicited 2914 synchronization of: the system configuration, Aggregator 2915 configuration, port configuration, Aggregator state and port state. 2917 It is necessary for all PEs in an RG to agree upon the System ID and 2918 System Priority values to be used ubiquitously. To achieve this, 2919 every PE MUST use the values for the two parameters that are supplied 2920 by the PE with the numerically lowest value (among RG members) of 2921 System Aggregation Priority. This guarantees that the PEs always 2922 agree on uniform values, which yield the highest System Priority. 2924 When the mLACP application is disabled on the device, or is 2925 unconfigured for the RG in question, the system MUST send an "RG 2926 Disconnect" message with "mLACP Disconnect TLV". 2928 9.2.6.2. mLACP Aggregator and Port Configuration 2930 A system MUST synchronize the configuration of its mLACP enabled 2931 Aggregators and ports with other RG members. This is achieved via the 2932 use of "mLACP Aggregator Config TLVs" and "mLACP Port Config TLVs", 2933 respectively. An implementation MUST advertise the configuration of 2934 Aggregators prior to advertising the configuration of any of their 2935 associated member ports. 2937 The PEs in an RG MUST all agree on the MAC address to be associated 2938 with a given Aggregator. It is possible to achieve this via 2939 consistent configuration on member PEs. However, in order to protect 2940 against possible misconfiguration, a system MUST use, for any given 2941 Aggregator, the MAC address supplied by the PE with the numerically 2942 lowest System Aggregation Priority in the RG. 2944 A system that receives an "mLACP Aggregator Config TLV" with an ROID 2945 to Key association that is different from its local association MUST 2946 NAK the corresponding TLV and disable the Aggregator with the same 2947 ROID. Furthermore, it SHOULD raise an alarm to alert the operator. 2948 Similarly, a system that receives a NAK in response to a transmitted 2949 "mLACP Aggregator Config TLV" MUST disable the associated Aggregator 2950 and SHOULD raise an alarm to alert the network operator. 2952 A system MAY enforce a restriction that all ports that are to be 2953 bundled together on a given PE share the same Port Priority value. If 2954 so, the system MUST advertise this common priority in the "mLACP 2955 Aggregator Config TLV" and assert the "Priority Set" flag in such 2956 TLV. Furthermore, the system in this case MUST NOT advertise 2957 individual Port Priority values in the associated "mLACP Port Config 2958 TLVs" (i.e. the "Priority Set" flag in these TLVs should be 0). 2960 A system MAY support individual Port Priority values to be configured 2961 on ports that are to be bundled together on a PE. If so, the system 2962 MUST advertise the individual Port Priority values in the appropriate 2963 "mLACP Port Config TLVs", and MUST NOT assert the "Priority Set" flag 2964 in the corresponding "mLACP Aggregator Config TLV". 2966 When the configurations of all ports for member links associated with 2967 a given Aggregator have been sent by a device, it asserts that fact 2968 by setting the "Synchronized" flag in the last port's "mLACP Port 2969 Config TLV". If an Aggregator doesn't have any candidate member ports 2970 configured, this is indicated by asserting the "Synchronized" flag in 2971 its "mLACP Aggregator Config TLV". 2973 Furthermore, for a given port/Aggregator, an implementation MUST 2974 advertise the port/Aggregator configuration prior to advertising its 2975 state (via the "mLACP Port State TLV" or "mLACP Aggregator State 2976 TLV"). If a PE receives an "mLACP Port State TLV" or "mLACP 2977 Aggregator State TLV" for a port or Aggregator that it had not 2978 learned of before via an appropriate Port or Aggregator Config TLV, 2979 then the PE MUST request synchronization of the configuration and 2980 state of all mLACP ports as well as all mLACP Aggregators from its 2981 respective peer. If during a synchronization (solicited or 2982 unsolicited), a PE receives a State TLV for a port or Aggregator that 2983 it has not learned of before, then the PE MUST send a NAK for the 2984 offending TLV. The PE MUST NOT request re-synchronization in this 2985 case. 2987 When mLACP is unconfigured on a port/Aggregator, a PE MUST send a 2988 "Port/Aggregator Config TLV" with the "Purge Configuration" flag 2989 asserted. This allows receiving PEs to purge any state maintained for 2990 the decommissioned port/Aggregator. If a PE receives a 2991 "Port/Aggregator Config TLV" with the "Purge Configuration" flag 2992 asserted, and the PE is not maintaining any state for that 2993 port/Aggregator, then it MUST silently discard the TLV. 2995 9.2.6.3. mLACP Aggregator and Port Status Synchronization 2997 PEs within an RG need to synchronize their state-machines for proper 2998 mLACP operation with a multi-homed device. This is achieved by having 2999 each system advertise its Aggregators and ports running state in 3000 "mLACP Aggregator State TLVs" and "mLACP Port State TLVs", 3001 respectively. Whenever any LACP parameter for an Aggregator or a 3002 port, whether on the Partner (i.e. multi-homed device) or the Actor 3003 (i.e. PE) side, is changed a system MUST transmit an updated TLV for 3004 the affected Aggregator and/or port. Moreover, when the 3005 administrative or operational state of an Aggregator or port changes, 3006 the system MUST transmit an updated Aggregator or port state TLV to 3007 its peers. 3009 If a PE receives an Aggregator or port state TLV where the 'Actor 3010 Key' doesn't match what was previously received in a corresponding 3011 Aggregator or port config TLV, the PE MUST then request 3012 synchronization of the configuration and state of the affected 3013 Aggregator or port. If such a mismatch occurs between the config and 3014 state TLVs as part of a synchronization (solicited or unsolicited), 3015 then the PE MUST send a NAK for the state TLV. Furthermore, if a PE 3016 receives a port state TLV with the 'Aggregator ID' set to a value 3017 that doesn't map to some Aggregator that the PE had learned of via a 3018 previous Aggregator config TLV, then the PE MUST request 3019 synchronization of the configuration and state of all Aggregators and 3020 ports. If the above anomaly occurs during a synchronization, then the 3021 PE MUST send a NAK for the offending port state TLV. 3023 A PE MAY request that its peer retransmit previously advertised 3024 state. This is useful for example when the PE is recovering from a 3025 soft failure and attempting to relearn state. To request such 3026 retransmissions, a PE MUST send a set of one or more "mLACP 3027 Synchronization Request TLVs". 3029 A PE MUST respond to an "mLACP Synchronization Request TLV" by 3030 sending the requested data in a set of one or more mLACP TLVs 3031 delimited by a pair of "mLACP Synchronization Data TLVs". The TLVs 3032 comprising the response MUST be ordered in the RG Application Data 3033 message(s) such that the Synchronization Response TLV with the 3034 "Synchronization Data Start" flag precedes the various other mLACP 3035 TLVs encoding the requested data. These, in turn, MUST precede the 3036 Synchronization Data TLV with the "Synchronization Data End" flag. 3037 Note that the response may span across multiple RG Application Data 3038 messages, for example when MTU limits are exceeded; however, the 3039 above ordering MUST be retained across messages, and only a single 3040 pair of Synchronization Data TLVs MUST be used to delimit the 3041 response across all Application Data Messages. 3043 A PE device MAY re-advertise its mLACP state in an unsolicited 3044 manner. This is done by sending the appropriate Config and State TLVs 3045 delimited by a pair of "mLACP Synchronization Data TLVs" and using a 3046 'Request Number' of 0. 3048 While a PE has a pending synchronization request for a system, 3049 Aggregator or port, it SHOULD silently ignore all TLVs for said 3050 system, Aggregator or port that are received prior to the 3051 synchronization response and which carry the same type of information 3052 being requested. This saves the system from the burden of updating 3053 state that will utlimately be overwritten by the synchronization 3054 response. Note that TLVs pertaining to other systems, Aggregators or 3055 ports are to continue to be processed per normal in this case. 3057 If a PE receives a synchronization request for an Aggregator, port or 3058 Key that doesn't exist or is not known to the PE, then it MUST 3059 trigger an unsolicited synchronization of all system, Aggregator and 3060 port information (i.e. replay the initialization sequence). 3062 If a PE learns, as part of a synchronization operation from its peer, 3063 that the latter is advertising a Node ID value which is different 3064 from the value previously advertised, then the PE MUST purge all 3065 port/aggregator data previously learnt from that peer prior to the 3066 last synchronization. 3068 9.2.6.4. Failure and Recovery 3070 When a PE that is active for a multi-chassis link aggregation group 3071 encounters a fault, it SHOULD attempt to fail-over to a peer PE which 3072 hosts the same RO. To that effect, the faulty PE SHOULD lower its 3073 port priority (by using a larger numeric value) and advertise this 3074 change in the "mLACP Port Priority TLV". If the PE is not capable of 3075 lowering its own port priority any further, it SHOULD trigger a 3076 failover to the redundant PE by sending an "mLACP Port Priority TLV" 3077 in which it requests the redundant PE to raise the latter's port 3078 priority to the maximum permitted in [IEEE-802.1AX] (i.e. the 3079 smallest allowed numeric value) for the Aggregator in question. 3080 Furthermore, the PE SHOULD set its own port priority to the next 3081 smallest numeric value. 3083 Upon recovery from a previous fault, a PE MAY reclaim active role for 3084 a multi-chassis link aggregation group if configured for revertive 3085 protection. Otherwise, the recovering PE may assume standby role 3086 when configured for non-revertive protection. In the revertive 3087 scenario, a PE SHOULD assume active role within the RG by sending an 3088 "mLACP Port Priority TLV" to the currently active PE, requesting that 3089 the latter change its port priority to a value that is lower (i.e. 3090 numerically larger) for the Aggregator in question. 3092 If a system is operating in a mode where different ports of a bundle 3093 are configured with different Port Priorities, then the system MUST 3094 NOT advertise or request change of Port Priority values for 3095 aggregated ports collectively (i.e. by using a 'Port Number' of 0 in 3096 the "mLACP Port Priority TLV"). This is to avoid ambiguity in the 3097 interpretation of the 'Last Port Priority' field. 3099 If a PE receives an "mLACP Port Priority TLV" requesting a priority 3100 change for a port or Aggregator that is not local to the device, then 3101 the PE MUST re-advertise the local configuration of the system, as 3102 well as the configuration and state of all its mLACP ports and 3103 Aggregators. 3105 If a PE receives an "mLACP Port Priority TLV" in which the remote 3106 system is advertising priority change for a port or Aggregator that 3107 the local PE had not learned of before via an appropriate Port or 3108 Aggregator Config TLV, then the PE MUST request synchronization of 3109 the configuration and state of all mLACP ports as well as all mLACP 3110 Aggregators from its respective peer. 3112 10. Security Considerations 3114 The security considerations described in [RFC5036] and [RFC4447] that 3115 apply to the base LDP specification, and to the PW LDP control 3116 protocol extensions apply to the capability mechanism described in 3117 this document. 3119 The ICCP protocol is not intended to be applicable when the 3120 redundancy group spans PE in different administrative domains. 3121 Furthermore, implementations SHOULD provide a mechanism to select to 3122 which LDP peers the ICCP capability will be advertised, and from 3123 which LDP peers the ICCP messages will be accepted. 3125 11. IANA Considerations 3127 11.1. MESSAGE TYPE NAME SPACE 3129 This document uses several new LDP message types, IANA already 3130 maintains a registry of name "MESSAGE TYPE NAME SPACE" defined by 3131 [RFC5036]. The following values are suggested for assignment: 3133 Message type Description 3134 0x0700 RG Connect Message 3135 0x0701 RG Disconnect Message 3136 0x0702 RG Notification Message 3137 0x0703 RG Application Data Message 3139 11.2. TLV TYPE NAME SPACE 3141 This document use a new LDP TLV type, IANA already maintains a 3142 registry of name "TLV TYPE NAME SPACE" defined by [RFC5036]. The 3143 following value is suggested for assignment: 3144 TLV Type Description 3145 0x700 ICCP capability TLV. 3146 0x701 LDP TCP/IP Port TLV. 3148 11.3. ICC RG Parameter Type Space 3150 IANA needs to set up a registry of "ICC RG parameter type". These are 3151 14-bit values. Parameter Type values 1 through 0x000F are specified 3152 in this document, Parameter Type values 0x0010 through 0x1FFF are to 3153 be assigned by IANA, using the "Expert Review" policy defined in 3154 [RFC5226]. Parameter Type values 0x2000 through 0x2FFF, 0x3FFF, and 0 3155 are to be allocated using the IETF consensus policy defined in 3156 [RFC5226]. Parameter Type values 0x3000 through 0x3FFE are reserved 3157 for vendor proprietary extensions and are to be assigned by IANA, 3158 using the "First Come First Served" policy defined in [RFC5226]. A 3159 Parameter Type description is required for any assignment from this 3160 registry. Additionally, for the vendor proprietary extensions range a 3161 citation of a person or company name is also required. A document 3162 reference should also be provided. 3164 Initial ICC RG parameter type space value allocations are specified 3165 below: 3167 Parameter Type Description Reference 3168 -------------- --------------------------------- --------- 3169 0x0001 ICC Sender Name [RFCxxxx] 3170 0x0002 NAK TLV [RFCxxxx] 3171 0x0003 Requested Protocol Version TLV [RFCxxxx] 3172 0x0004 Disconnect Code TLV [RFCxxxx] 3173 0x0005 ICC RG ID TLV [RFCxxxx] 3175 0x0010 PW-RED Connect TLV [RFCxxxx] 3176 0x0011 PW-RED Disconnect TLV [RFCxxxx] 3177 0x0012 PW-RED Config TLV [RFCxxxx] 3178 0x0013 Service Name TLV [RFCxxxx] 3179 0x0014 PW ID TLV [RFCxxxx] 3180 0x0015 Generalized PW ID TLV [RFCxxxx] 3181 0x0016 PW-RED State TLV [RFCxxxx] 3182 0x0017 PW-RED Synchronization Request TLV [RFCxxxx] 3183 0x0018 PW-RED Synchronization Data TLV [RFCxxxx] 3184 0x0019 PW-RED Disconnect Cause TLV [RFCxxxx] 3185 0x0030 mLACP Connect TLV [RFCxxxx] 3186 0x0031 mLACP Disconnect TLV [RFCxxxx] 3187 0x0032 mLACP System Config TLV [RFCxxxx] 3188 0x0033 mLACP Port Config TLV [RFCxxxx] 3189 0x0034 mLACP Port Priority TLV [RFCxxxx] 3190 0x0035 mLACP Port State TLV [RFCxxxx] 3191 0x0036 mLACP Aggregator Config TLV [RFCxxxx] 3192 0x0037 mLACP Aggregator State TLV [RFCxxxx] 3193 0x0038 mLACP Synchronization Request TLV [RFCxxxx] 3194 0x0039 mLACP Synchronization Data TLV [RFCxxxx] 3195 0x003A mLACP Disconnect Cause TLV [RFCxxxx] 3197 11.4. STATUS CODE NAME SPACE 3199 This document use several new Status codes, IANA already maintains a 3200 registry of name "STATUS CODE NAME SPACE" defined by [RFC5036]. The 3201 following values is suggested for assignment: The "E" column is the 3202 required setting of the Status Code E-bit. 3203 Range/Value E Description Reference 3204 ------------- ----- ---------------------- --------- 3205 0x00010001 0 Unknown ICCP RG 3206 0x00010002 0 ICCP Connection Count Exceeded 3207 0x00010003 0 ICCP Application Connection 3208 Count Exceeded 3209 0x00010004 0 ICCP Application not in RG 3210 0x00010005 0 Incompatible ICCP Protocol Version 3211 0x00010006 0 ICCP Rejected Message 3212 0x00010007 0 ICCP Administratively Disabled 3213 0x00010010 0 ICCP RG Removed 3214 0x00010011 0 ICCP Application Removed from RG 3216 12. Acknowledgments 3218 The authors wish to acknowledge the important contributions of Dennis 3219 Cai, Neil McGill, Amir Maleki, Dan Biagini, Robert Leger, Sami 3220 Boutros, Neil Ketley and Mark Christopher Sains. 3222 13. Normative References 3224 [RFC5036] L. Andersson et al, "LDP Specification", RFC 5036, 3225 October 2007. 3227 [RFC5561] "LDP Capabilities", RFC5561, July 2009. 3229 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., 3230 et al., rfc4447 April 2006. 3232 [IEEE-802.1AX] IEEE Std. 802.1AX-2008, "IEEE Standard for Local and 3233 metropolitan area networks- Link Aggregation", IEEE Computer 3234 Society, November 2008. 3236 [RFC2863] K. McCloghrie, F. Kastenholz, "The Interfaces Group MIB", 3237 rfc2863, June 2000. 3239 14. Informative References 3241 [RED-BIT] Praveen Muley, Mustapha Aissaoui, "Pseudowire 3242 Preferential Forwarding Status Bit", 3243 draft-ietf-pwe3-redundancy-bit-07.txt, May 2012, Work in progress. 3245 [RFC5880] D. Katz, D. Ward, "Bidirectional Forwarding Detection", 3246 RFC5880, June 2010 3248 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3249 IANA Considerations section in RFCs", BCP 26, RFC 5226, May 2008 3251 15. Author's Addresses 3253 Luca Martini 3254 Cisco Systems, Inc. 3255 9155 East Nichols Avenue, Suite 400 3256 Englewood, CO, 80112 3257 e-mail: lmartini@cisco.com 3259 Samer Salam 3260 Cisco Systems, Inc. 3261 595 Burrard Street, Suite 2123 3262 Vancouver, BC V7X 1J1 3263 Canada 3264 e-mail: ssalam@cisco.com 3265 Ali Sajassi 3266 Cisco Systems, Inc. 3267 170 West Tasman Drive 3268 San Jose, CA 95134 3269 e-mail: sajassi@cisco.com 3271 Matthew Bocci 3272 Alcatel-Lucent 3273 Grove House, Waltham Road Rd 3274 White Waltham, Berks, UK. SL6 3TN 3275 e-mail: matthew.bocci@alcatel-lucent.co.uk 3277 Satoru Matsushima 3278 Softbank Telecom 3279 1-9-1, Higashi-Shinbashi, Minato-ku 3280 Tokyo 105-7313, JAPAN 3281 e-mail: satoru.matsushima@tm.softbank.co.jp 3283 Thomas Nadeau 3284 CA Technologies 3285 273 Corporate Dr. 3286 Portsmouth, NH 03801 3287 USA 3288 e-mail: Thomas.Nadeau@ca.com 3290 Copyright Notice 3292 Copyright (c) 2012 IETF Trust and the persons identified as the 3293 document authors. All rights reserved. 3295 This document is subject to BCP 78 and the IETF Trust's Legal 3296 Provisions Relating to IETF Documents 3297 (http://trustee.ietf.org/license-info) in effect on the date of 3298 publication of this document. Please review these documents 3299 carefully, as they describe your rights and restrictions with respect 3300 to this document. Code Components extracted from this document must 3301 include Simplified BSD License text as described in Section 4.e of 3302 the Trust Legal Provisions and are provided without warranty as 3303 described in the Simplified BSD License. 3305 This document may contain material from IETF Documents or IETF 3306 Contributions published or made publicly available before November 3307 10, 2008. The person(s) controlling the copyright in some of this 3308 material may not have granted the IETF Trust the right to allow 3309 modifications of such material outside the IETF Standards Process. 3310 Without obtaining an adequate license from the person(s) controlling 3311 the copyright in such materials, this document may not be modified 3312 outside the IETF Standards Process, and derivative works of it may 3313 not be created outside the IETF Standards Process, except to format 3314 it for publication as an RFC or to translate it into languages other 3315 than English. 3317 Expiration Date: December 2012