idnits 2.17.1 draft-ietf-pwe3-iccp-09.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document 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 (July 30, 2012) is 4287 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 3307, but not defined ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.1AX' == Outdated reference: A later version (-09) exists of draft-ietf-pwe3-redundancy-bit-07 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 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: January 30, 2013 Cisco 7 Matthew Bocci Satoru Matsushima 8 Alcatel-Lucent Softbank 10 Thomas Nadeau 11 Juniper Networks 12 July 30, 2012 14 Inter-Chassis Communication Protocol for L2VPN PE Redundancy 16 draft-ietf-pwe3-iccp-09.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 January 30, 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 ............................................ 40 93 7.1.3.3 Generalized PW ID TLV ................................ 41 94 7.1.4 PW-RED State TLV ..................................... 42 95 7.1.5 PW-RED Synchronization Request TLV ................... 43 96 7.1.6 PW-RED Synchronization Data TLV ...................... 45 97 7.2 Multi-chassis LACP (mLACP) Application TLVs .......... 46 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 ........................... 48 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.3.1 Independent Mode ..................................... 66 116 9.1.3.2 Master/Slave Mode .................................... 67 117 9.1.4 PE Node Failure ...................................... 67 118 9.2 Attachment Circuit Redundancy Application Procedures . 68 119 9.2.1 Common AC Procedures ................................. 68 120 9.2.1.1 AC Failure ........................................... 68 121 9.2.1.2 PE Node Failure ...................................... 68 122 9.2.1.3 PE Isolation ......................................... 68 123 9.2.1.4 Determining Pseudowire State ......................... 68 124 9.2.2 Multi-chassis LACP (mLACP) Application Procedures .... 69 125 9.2.2.1 Initial Setup ........................................ 69 126 9.2.2.2 mLACP Aggregator and Port Configuration .............. 71 127 9.2.2.3 mLACP Aggregator and Port Status Synchronization ..... 72 128 9.2.2.4 Failure and Recovery ................................. 74 129 10 Security Considerations .............................. 75 130 11 IANA Considerations .................................. 75 131 11.1 MESSAGE TYPE NAME SPACE .............................. 75 132 11.2 TLV TYPE NAME SPACE .................................. 76 133 11.3 ICC RG Parameter Type Space .......................... 76 134 11.4 STATUS CODE NAME SPACE ............................... 77 135 12 Acknowledgments ...................................... 77 136 13 Normative References ................................. 78 137 14 Informative References ............................... 78 138 15 Author's Addresses ................................... 78 140 1. Specification of Requirements 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119. 146 2. Introduction 148 Network availability is a critical metric for service providers as it 149 has a direct bearing on their profitability. Outages translate not 150 only to lost revenue but also to potential penalties mandated by 151 contractual agreements with customers running mission-critical 152 applications that require tight SLAs. This is true for any carrier 153 network, and networks employing Layer 2 Virtual Private Network 154 (L2VPN) technology are no exception. Network high-availability can 155 be achieved by employing intra and inter-chassis redundancy 156 mechanisms. The focus of this document is on the latter. The document 157 defines an Inter-Chassis Communication Protocol (ICCP) that allows 158 synchronization of state and configuration data between a set of two 159 or more PEs forming a Redundancy Group (RG). The protocol supports 160 multi-chassis redundancy mechanisms that can be employed on either 161 the attachment circuit or pseudowire front. 163 3. ICCP Overview 165 3.1. Redundancy Model & Topology 167 The focus of this document is on PE node redundancy. It is assumed 168 that a set of two or more PE nodes are designated by the operator to 169 form a Redundancy Group (RG). Members of a Redundancy Group fall 170 under a single administration (e.g. service provider) and employ a 171 common redundancy mechanism towards the access (attachment circuits 172 or access pseudowires) and/or towards the core (pseudowires) for any 173 given service instance. It is possible, however, for members of an RG 174 to make use of disparate redundancy mechanisms for disjoint services. 175 The PE devices may be offering any type of L2VPN service, i.e. VPWS 176 or VPLS. As a matter of fact, the use of ICCP may even be applicable 177 for Layer 3 service redundancy, but this is considered to be outside 178 the scope of this document. 180 The PEs in an RG offer multi-homed connectivity to either individual 181 devices (e.g. CE, DSLAM, etc...) or entire networks (e.g. access 182 network). Figure 1 below depicts the model. 184 +=================+ 185 | | 186 Mutli-homed +----+ | +-----+ | 187 Node ------------> | CE |-------|--| PE1 ||<------|---Pseudowire-->| 188 | |--+ -|--| ||<------|---Pseudowire-->| 189 +----+ | / | +-----+ | 190 | / | || | 191 |/ | || ICCP |--> Towards Core 192 +-------------+ / | || | 193 | | /| | +-----+ | 194 | Access |/ +----|--| PE2 ||<------|---Pseudowire-->| 195 | Network |-------|--| ||<------|---Pseudowire-->| 196 | | | +-----+ | 197 | | | | 198 +-------------+ | Redundancy | 199 ^ | Group | 200 | +=================+ 201 | 202 Multi-homed Network 204 Figure 1: Generic Multi-chassis Redundancy Model 206 In the topology of Figure 1, the redundancy mechanism employed 207 towards the access node/network can be one of a multitude of 208 technologies, e.g. it could be IEEE 802.1AX Link Aggregation Groups 209 with Link Aggregation Control Protocol (LACP), or SONET APS. The 210 specifics of the mechanism are out of the scope of this document. 211 However, it is assumed that the PEs in the RG are required to 212 communicate amongst each other in order for the access redundancy 213 mechanism to operate correctly. As such, it is required to run an 214 inter-chassis communication protocol among the PEs in the RG in order 215 to synchronize configuration and/or running state data. 217 Furthermore, the presence of the inter-chassis communication channel 218 allows simplification of the pseudowire redundancy mechanism. This is 219 primarily because it allows the PEs within an RG to run some 220 arbitration algorithm to elect which pseudowire(s) should be in 221 active or standby mode for a given service instance. The PEs can then 222 advertise the outcome of the arbitration to the remote-end PE(s), as 223 opposed to having to embed a hand-shake procedure into the pseudowire 224 redundancy status communication mechanism, and every other possible 225 Layer 2 status communication mechanism. 227 3.2. ICCP Interconnect Scenarios 229 When referring to 'interconnect' in this section, we are concerned 230 with the links or networks over which Inter-Chassis Communication 231 Protocol messages are transported, and not normal data traffic 232 between PEs. The PEs which are members of an RG may be either 233 physically co-located or geo-redundant. Furthermore, the physical 234 interconnect between the PEs over which ICCP is to run may comprise 235 of either dedicated back-to-back links or a shared connection through 236 the packet switched network (PSN); for e.g., MPLS core network. This 237 gives rise to a matrix of four interconnect scenarios, described 238 next. 240 3.2.1. Co-located Dedicated Interconnect 242 In this scenario, the PEs within an RG are co-located in the same 243 physical location (POP, CO). Furthermore, dedicated links provide the 244 interconnect for ICCP among the PEs. 246 +=================+ +-----------------+ 247 |CO | | | 248 | +-----+ | | | 249 | | PE1 |________|_____| | 250 | | | | | | 251 | +-----+ | | | 252 | || | | | 253 | || ICCP | | Core | 254 | || | | Network | 255 | +-----+ | | | 256 | | PE2 |________|_____| | 257 | | | | | | 258 | +-----+ | | | 259 | | | | 260 +=================+ +-----------------+ 262 Figure 2: ICCP Co-located PEs Dedicated Interconnect Scenario 264 Given that the PEs are connected back-to-back in this case, it is 265 possible to rely on Layer 2 redundancy mechanisms to guarantee the 266 robustness of the ICCP interconnect. For example, if the interconnect 267 comprises of IEEE 802.3 Ethernet links, it is possible to provide 268 link redundancy by means of IEEE 802.1AX Link Aggregation Groups. 270 3.2.2. Co-located Shared Interconnect 272 In this scenario, the PEs within an RG are co-located in the same 273 physical location (POP, CO). However, unlike the previous scenario, 274 there are no dedicated links between the PEs. The interconnect for 275 ICCP is provided through the core network to which the PEs are 276 connected. Figure 3 depicts this model. 278 +=================+ +-----------------+ 279 |CO | | | 280 | +-----+ | | | 281 | | PE1 |________|_____| | 282 | | |<=================+ | 283 | +-----+ ICCP | | || | 284 | | | || | 285 | | | || Core | 286 | | | || Network | 287 | +-----+ | | || | 288 | | PE2 |________|_____| || | 289 | | |<=================+ | 290 | +-----+ | | | 291 | | | | 292 +=================+ +-----------------+ 294 Figure 3: ICCP Co-located PEs Shared Interconnect Scenario 296 Given that the PEs in the RG are connected over the packet switched 297 network (PSN), then PSN Layer mechanisms can be leveraged to ensure 298 the resiliency of the interconnect against connectivity failures. For 299 example, it is possible to employ RSVP LSPs with Fast Re-Route (FRR) 300 and/or end-to-end backup LSPs. 302 3.2.3. Geo-redundant Dedicated Interconnect 304 In this variation, the PEs within a Redundancy Group are located in 305 different physical locations to provide geographic redundancy. This 306 may be desirable, for example, to protect against natural disasters 307 or the like. A dedicated interconnect is provided to link the PEs, 308 which is a costly option, especially when considering the possibility 309 of providing multiple such links for interconnect robustness. The 310 resiliency mechanisms for the interconnect are similar to those 311 highlighted in the co-located interconnect counterpart. 313 +=================+ +-----------------+ 314 |CO 1 | | | 315 | +-----+ | | | 316 | | PE1 |________|_____| | 317 | | | | | | 318 | +-----+ | | | 319 +=====||==========+ | | 320 || ICCP | Core | 321 +=====||==========+ | Network | 322 | +-----+ | | | 323 | | PE2 |________|_____| | 324 | | | | | | 325 | +-----+ | | | 326 |CO 2 | | | 327 +=================+ +-----------------+ 329 Figure 4: ICCP Geo-redundant PEs Dedicated Interconnect Scenario 331 3.2.4. Geo-redundant Shared Interconnect 333 In this scenario, the PEs of an RG are located in different physical 334 locations and the interconnect for ICCP is provided over the PSN 335 network to which the PEs are connected. This interconnect option is 336 more likely to be the one used for geo-redundancy as it is more 337 economically appealing compared to the geo-redundant dedicated 338 interconnect. The resiliency mechanisms that can be employed to 339 guarantee the robustness of the ICCP transport are PSN Layer 340 mechanisms as has been described in the "Co-located Shared 341 Interconnect" section above. 343 +=================+ +-----------------+ 344 |CO 1 | | | 345 | +-----+ | | | 346 | | PE1 |________|_____| | 347 | | |<=================+ | 348 | +-----+ ICCP | | || | 349 +=================+ | || | 350 | || Core | 351 +=================+ | || Network | 352 | +-----+ | | || | 353 | | PE2 |________|_____| || | 354 | | |<=================+ | 355 | +-----+ | | | 356 |CO 2 | | | 357 +=================+ +-----------------+ 359 Figure 5: ICCP Geo-redundant PEs Shared Interconnect Scenario 361 3.3. ICCP Requirements 363 The Inter-chassis Communication Protocol SHOULD satisfy the following 364 requirements: 366 -i. Provide a control channel for communication between PEs in a 367 Redundancy Group (RG). Nodes may be co-located or remote 368 (refer to "Interconnect Scenarios" section above). It is 369 expected that client applications which make use of ICCP 370 services will only use this channel to communicate control 371 information and not data-traffic. As such the protocol 372 should cater for relatively low bandwidth, low-delay and 373 highly reliable message transfer. 375 -ii. Accommodate multiple client applications (e.g. multi-chassis 376 LACP, PW redundancy, SONET APS, etc...). This implies that 377 the messages should be extensible (e.g. TLV-based) and the 378 protocol should provide a robust application registration 379 and versioning scheme. 381 -iii. Provide reliable message transport and in-order delivery 382 between nodes in a RG with secure authentication mechanisms 383 built into the protocol. The redundancy applications that 384 are clients of ICCP expect reliable message transfer, and as 385 such will assume that the protocol takes care of flow- 386 control and retransmissions. Furthermore, given that the 387 applications will rely on ICCP to communicate data used to 388 synchronize state-machines on disparate nodes, it is 389 critical that ICCP guarantees in-order message delivery. 390 Loss of messages or out-of-sequence messages would have 391 adverse side-effects to the operation of the client 392 applications. 394 -iv. Provide a common mechanism to actively monitor the health of 395 PEs in an RG. This mechanism will be used to detect PE node 396 failure and inform the client applications. The applications 397 require this to trigger failover according to the procedures 398 of the employed redundancy protocol on the AC and PW. It is 399 desired to achieve sub-second detection of loss of remote 400 node (~ 50 - 150 msec) in order to give the client 401 applications (redundancy mechanisms) enough reaction time to 402 achieve sub-second service restoration time. 404 -v. Provide asynchronous event-driven state update, independent 405 of periodic messages, for immediate notification of client 406 applications' state changes. In other words, the 407 transmission of messages carrying application data should be 408 on-demand rather than timer-based to minimize inter-chassis 409 state synchronization delay. 411 -vi. Accommodate multi-link and multi-hop interconnect between 412 nodes. When the devices within an RG are located in 413 different physical locations, the physical interconnect 414 between them will comprise of a network rather than a link. 415 As such, ICCP should accommodate the case where the 416 interconnect involves multiple hops. Furthermore, it is 417 possible to have multiple (redundant) paths or interconnects 418 between a given pair of devices. This is true for both the 419 co-located and geo-redundant scenarios. ICCP should handle 420 this as well. 422 -vii. Ensure transport security between devices in an RG. This is 423 especially important in the scenario where the members of an 424 RG are located in different physical locations and connected 425 over a shared network (e.g. PSN). 427 -viii. Must allow operator to statically configure members of RG. 428 Auto-discovery may be considered in the future. 430 -ix. Allow for flexible RG membership. It is expected that only 431 two nodes per an RG will cover most of the redundancy 432 applications for common deployments. ICCP should not 433 preclude supporting more than two nodes in an RG by virtue 434 of design. Furthermore, it is required to allow a single 435 node to be member of multiple RGs simultaneously. 437 4. ICC LDP Protocol Extension Specification 439 To address the requirements identified in the previous section, ICCP 440 is modeled to comprise of three layers: 442 -i. Application Layer: This provides the interface to the 443 various redundancy applications that make use of the 444 services of ICCP. ICCP is concerned with defining common 445 connection management procedures and the formats of the 446 messages exchanged at this layer; however, beyond that, it 447 does not impose any restrictions on the procedures or 448 state-machines of the clients, as these are deemed 449 application-specific and lie outside the scope of ICCP. 450 This guarantees implementation inter-operability without 451 placing any unnecessary constraints on internal design 452 specifics. 454 -ii. Inter Chassis Communication (ICC) Layer: This layer 455 implements the common set of services which ICCP offers to 456 the client applications. It handles protocol versioning, RG 457 membership, Redundant Object identification, PE node 458 identification and ICCP connection management. 460 -iii. Transport Layer: This layer provides the actual ICCP message 461 transport. It is responsible for addressing, route 462 resolution, flow-control, reliable and in-order message 463 delivery, connectivity resiliency/redundancy and finally PE 464 node failure detection. The Transport layer may differ 465 depending on the Physical Layer of the inter-connect. 467 4.1. LDP ICCP Capability Advertisement 469 When an RG is enabled on a particular PE, the capability of 470 supporting ICCP must be advertised to all LDP peers in that RG. This 471 is achieved by using the methods in [RFC5561] and advertising the 472 ICCP LDP capability TLV. If an LDP peer supports the dynamic 473 capability advertisement, this can be done by sending a new 474 capability message with the S bit set for the ICCP capability TLV 475 when the first RG is enabled on the PE. If the peer does not support 476 dynamic capability advertisement, then the ICCP TLV MUST be included 477 in the LDP initialization procedures in the capability parameter 478 [RFC5561]. 480 4.2. RG Membership Management 482 ICCP defines a mechanism that enables PE nodes to manage their RG 483 membership. When a PE is configured to be a member of an RG, it will 484 first advertise the ICCP capability to its peers. Subsequently, the 485 PE sends an RG Connect message to the peers that have also advertised 486 ICCP capability. The PE then waits for the peers to send their own RG 487 Connect messages, if they haven't done so already. For a given RG, 488 the ICCP connection between two devices is considered to be 489 operational only when both have sent and received ICCP RG Connect 490 messages for that RG. 492 If a PE that has sent a particular RG Connect message doesn't receive 493 a corresponding RG Connect (or a Notification message with NAK) from 494 a destination, it will remain in a state expecting the corresponding 495 RG Connect message (or Notification message). The RG will not become 496 operational until the corresponding RG Connect Message has been 497 received. If a PE that has sent an RG Connect message receives a 498 Notification message with a NAK, it will stop attempting to bring up 499 the ICCP connection immediately. The PE MUST resume bringing up the 500 connection after it receives an RG Connect message from the peer PE 501 for the RG in question. This is achieved by responding to the 502 incoming RG Connect message with an appropriate RG Connect. 504 A device MUST send a NAK for an RG Connect message if at least one of 505 the following conditions is satisfied: 507 -i. the PE is not a member of the RG; 509 -ii. the maximum number of simultaneous ICCP connections that the 510 PE can handle is exceeded. 512 A PE sends an RG Disconnect message to tear down the ICCP connection 513 for a given RG. This is a unilateral operation and doesn't require 514 any acknowledgement from the other PEs. Note that the ICCP connection 515 for an RG MUST be operational before any client application can make 516 use of ICCP services in that RG. 518 4.2.1. ICCP Connection State Machine 520 The ICCP Connection state machine is defined to have six states as 521 depicted in the state transition table and state transition diagram 522 that follow. 524 ICCP Connection State Transition Table 525 STATE EVENT NEW STATE 527 NON EXISTENT LDP session established INITIALIZED 529 INITIALIZED Transmit LDP ICCP Capability CAPSENT 531 Receive LDP ICCP Capability CAPREC 532 Action: Transmit LDP ICCP Capability 534 LDP session torn down NON EXISTENT 536 CAPSENT Receive LDP ICCP Capability CAPREC 538 LDP session torn down NON EXISTENT 540 CAPREC Transmit RG Connect Message CONNECTING 542 Receive acceptable RG Connect Message OPERATIONAL 543 Action: Transmit RG Connect Message 545 Receive any other ICCP Message CAPREC 546 Action: Transmit NAK in RG 547 Notification Message 549 LDP session torn down NON EXISTENT 551 CONNECTING Receive acceptable RG Connect Message OPERATIONAL 553 Receive any other ICCP Message CAPREC 554 Action: Transmit NAK in RG 555 Notification Message 557 LDP session torn down NON EXISTENT 559 OPERATIONAL Receive acceptable RG Disconnect Message CAPREC 561 Transmit RG Disconnect Message CAPREC 563 LDP session torn down NON EXISTENT 565 ICCP Connection State Transition Diagram 566 +------------+ 567 | | 568 +------------------>|NON EXISTENT| LDP session torn down 569 | | |<--------------------------+ 570 | +------------+ | 571 | LDP session | ^ LDP session | 572 | established | | torn down | 573 | V | | 574 | +-----------+ | 575 LDP | | | Tx LDP ICCP | 576 session| |INITIALIZED| capability | 577 torn | +---| |---------------+ | 578 down | Rx other | +-----------+ | | 579 | ICCP msg/ |Rx LDP ICCP | | 580 | Tx NAK | capability/ | | 581 | +---+ |Tx LDP ICCP capability | | 582 | | | | | | 583 | V | V V | 584 | +-----------+ Rx LDP ICCP +--------+ | 585 +---| | capability | | | 586 |CAPREC |<----------------------|CAPSENT |---------->+ 587 +---| |-------------------+ | | | 588 | +-----------+ | +--------+ | 589 | ^ ^ | | 590 Tx | | | | | 591 RG | | |Rx RG Disconnect msg | | 592 Connect| | | or |Rx RG Connect msg / | 593 Msg | | |Tx RG Disconnect msg | Tx RG Connect msg | 594 | | | V | 595 | | | +------------+ | 596 | | +--------------------| | | 597 | | |OPERATIONAL |------------>+ 598 | | | | | 599 | |Rx other ICCP msg/ +------------+ | 600 | | Tx NAK ^ | 601 | | | | 602 | +----------+ Rx RG Connect msg | | 603 | | |---------------------+ | 604 +----->|CONNECTING| | 605 | |----------------------------------------->+ 606 +----------+ 608 4.3. Redundant Object Identification 610 ICCP offers its client applications a uniform mechanism for 611 identifying links, ports, forwarding constructs and more generally 612 objects (e.g. interfaces, pseudowires, VLANs, etc...) that are being 613 protected in a redundant setup. These are referred to as Redundant 614 Objects (RO). An example of an RO is a multi-chassis link-aggregation 615 group that spans two PEs. ICCP introduces a 64-bit opaque identifier 616 to uniquely identify ROs in an RG. This identifier, referred to as 617 Redundant Object ID (ROID), MUST match between RG members for the 618 protected object in question. That allows separate systems in an RG 619 to use a common handle to reference the protected entity irrespective 620 of its nature (e.g. physical or virtual) and in a manner that is 621 agnostic to implementation specifics. Client applications that need 622 to synchronize state pertaining to a particular RO SHOULD embed the 623 corresponding ROID in their TLVs. 625 4.4. Application Connection Management 627 ICCP provides a common set of procedures by which applications on one 628 PE can connect to their counterparts on another PE, for purpose of 629 inter-chassis communication in the context of a given RG. The 630 prerequisite for establishing an application connection is to have an 631 operational ICCP RG connection between the two endpoints. It is 632 assumed that the association of applications with RGs is known a 633 priori, e.g. by means of device configuration. ICCP then sends an 634 Application-specific Connect TLV (carried in RG Connect message), on 635 behalf of each client application, to each remote PE within the RG. 636 The client may piggyback application-specific information in that 637 Connect TLV, which for example can be used to negotiate parameters or 638 attributes prior to bringing up the actual application connection. 639 The procedures for bringing up the application connection are similar 640 to those of the ICCP connection: An application connection between 641 two nodes is up only when both nodes have sent and received RG 642 Connect Messages with the proper Application-specific Connect TLVs. A 643 PE MUST send a Notification Message to NAK an application connection 644 request if one of the following conditions is encountered: 646 -i. the application doesn't exist or is not configured for that 647 RG; 649 -ii. the application connection count exceeds the PE's 650 capabilities. 652 When a PE receives such a NAK notification, it MUST stop attempting 653 to bring up the application connection until it receives a new 654 application connection request from the remote PE. This is done by 655 responding to the incoming RG Connect message (carrying an 656 Application-specific Connect TLV) with an appropriate RG Connect 657 message (carrying a corresponding Application-specific Connect TLV). 659 When an application is stopped on a device or it is no longer 660 associated with an RG, it MUST signal ICCP to trigger sending an 661 Application-specific Disconnect TLV (in the RG Disconnect message). 662 This is a unilateral notification to the other PEs within an RG, and 663 as such doesn't trigger any response. 665 4.4.1. Application Versioning 667 During application connection setup time, a given application on one 668 PE can negotiate with its counterpart on a peer PE the proper 669 application version to use for communication. If no common version is 670 agreed upon, then the application connection is not brought up. This 671 is achieved through the following set of rules: 673 - If an application receives an Application-specific Connect TLV 674 with a version number that is higher than its own, it MUST send a 675 Notification message with a NAK TLV indicating status code 676 "Incompatible Protocol Version" and supplying the version that is 677 locally supported by the PE. 679 - If an application receives an Application-specific Connect TLV 680 with a version number that is lower than its own, it MAY respond 681 with an RG Connect that has an Application-specific Connect TLV 682 using the same version that was received. Alternatively, the 683 application MAY respond with a Notification message to NAK the 684 request using the "Incompatible Protocol Version" code, and 685 supplying the version that is supported. The above allows an 686 application to operate in either backwards compatible or 687 incompatible mode. 689 - If an application receives an Application-specific Connect TLV 690 with a version that is equal to its own, then the application 691 MUST honor or reject the request based on whether the application 692 is configured for the RG in question, and whether or not the 693 application connection count has been exceeded. 695 4.4.2. Application Connection State Machine 697 The Application Connection state machine has six states as described 698 in the state transition table and diagram that follow. 700 ICCP Application Connection State Transition Table 701 STATE EVENT NEW STATE 703 NON EXISTENT ICCP connection established RESET 705 RESET ICCP connection torn down NON EXISTENT 707 Transmit Application Connect TLV CONNSENT 709 Receive Application Connect TLV CONNREC 711 Receive any other Application TLV RESET 712 Action: Transmit NAK TLV 714 CONNSENT Receive NAK TLV RESET 716 Receive Application Connect TLV OPERATIONAL 717 with A-bit=1 718 Action: Transmit Application Connect 719 TLV with A-bit=1 721 Receive any other Application TLV RESET 722 Action: Transmit NAK TLV 724 ICCP connection torn down NON EXISTENT 726 CONNREC Transmit NAK TLV RESET 728 Transmit Application Connect TLV CONNECTING 729 with A-bit=1 731 Receive any Application TLV except RESET 732 Connect 733 Action: Transmit NAK TLV 735 ICCP connection torn down NON EXISTENT 737 CONNECTING Receive Application Connect TLV OPERATIONAL 738 with A-bit=1 740 Receive any other Application TLV RESET 741 Action: Transmit NAK TLV 743 ICCP connection torn down NON EXISTENT 745 OPERATIONAL Receive Application Disconnect TLV RESET 747 Transmit Applicaton Disconnect TLV RESET 748 ICCP connection torn down NON EXISTENT 750 ICCP Application Connection State Transition Diagram 751 +------------+ 752 | | 753 +---------------->|NON EXISTENT| ICCP connection torn down 754 | | |<--------------------------+ 755 | +------------+ | 756 | ICCP connection| ^ ICCP connection | 757 | established | | torn down | 758 | | | | 759 | V | Rx other App TLV/ | 760 | +-----------+<-----+ Tx NAK | 761 ICCP | Rx App | | | | 762 connect| Connect TLV | RESET |------+ | 763 torn | +-------------| |---------------+ | 764 down | | +-----------+ Tx App | | 765 | | ^ ^ ^ ^ Connect TLV| | 766 | | Tx NAK | | | | | | 767 | | or | | | | | | 768 | | Rx non | | | | | | 769 | | Connect | | | | | | 770 | V TLV/Tx NAK | | |Rx NAK TLV V | 771 | +-----------+ | | | |or +--------+ | 772 +-| |---+ | | +---------| | | 773 |CONNREC | | | Rx other |CONNSENT|---------->+ 774 +-| | | | App TLV/ | | | 775 | +-----------+ | | Tx NAK +--------+ | 776 | | | |Rx App Connect | 777 | Tx App Connect | | |TLV (A=1) / | 778 | TLV (A=1) | |Rx App Disconn | Tx App | 779 | | |or | Connect TLV | 780 | | |Tx App Disconn V (A=1) | 781 | | | +------------+ | 782 | | +------| | | 783 | Rx other App | |OPERATIONAL |------------>+ 784 | TLV / Tx NAK | | | | 785 | +------+ +------------+ | 786 | | ^ Rx App Connect | 787 | +----------+ | TLV (A=1) | 788 | | |---------------------+ | 789 +--->|CONNECTING| | 790 | |----------------------------------------->+ 791 +----------+ 793 4.5. Application Data Transfer 795 When an application has information to transfer over ICCP it triggers 796 the transmission of an Application Data message. ICCP guarantees in- 797 order and loss-less delivery of data. An application may NAK a 798 message or a set of one or more TLVs within a message by using the 799 Notification Message with NAK TLV. Furthermore, an application may 800 implement its own ACK mechanism, if deemed required, by defining an 801 application-specific TLV to be transported in an Application Data 802 message. 804 It is left up to the application to define the procedures to handle 805 the situation where a PE receives a NAK in response to a transmitted 806 Application Data message. Depending on the specifics of the 807 application, it may be favorable to have the PE, which sent the NAK, 808 explicitly request retransmission of data. On the other hand, for 809 certain applications it may be more suitable to have the original 810 sender of the Application Data message handle retransmissions in 811 response to a NAK. ICCP supports both models. 813 4.6. Dedicated Redundancy Group LDP session 815 For certain ICCP applications, it is required to exchange a fairly 816 large amount of RG information in a very short period of time. In 817 order to better distribute the load in a multiple processor system, 818 and to avoid head of line blocking to other LDP applications, it may 819 be required to initiate a separate TCP/IP session between the two LDP 820 speakers. 822 This procedure is OPTIONAL, and does not change the operation of LDP 823 or ICCP. 825 A PE that requires a separate LDP session will advertise a separate 826 LDP adjacency with a non-zero label space identifier. This will cause 827 the remote peer to open a separate LDP session for this label space. 828 No labels need to be advertised in this label space, as it is only 829 used for one or a set of ICCP RGs. All relevant LDP and ICCP 830 procedures still apply as described in the relevant documents. 832 5. ICCP PE Node Failure Detection Mechanism 834 ICCP provides its client applications a notification when a remote PE 835 that is member of the RG fails. This is used by the client 836 applications to trigger failover according to the procedures of the 837 employed redundancy protocol on the AC and PW. To that end, ICCP does 838 not define its own KeepAlive mechanism for purpose of monitoring the 839 health of remote PE nodes, but rather reuses existing fault detection 840 mechanisms. The following mechanisms may be used by ICCP to detect PE 841 node failure: 843 - BFD 845 Run a BFD session [RFC5880] between the PEs that are members of a 846 given RG, and use that to detect PE node failure. This assumes 847 that resiliency mechanisms are in place to protect connectivity 848 to the remote PE nodes, and hence loss of BFD periodic messages 849 from a given PE node can only mean that the node itself has 850 failed. 852 - IP Reachability Monitoring 854 It is possible for a PE to monitor IP layer connectivity to other 855 members of an RG that are participating in IGP/BGP. When 856 connectivity to a given PE is lost, the local PE interprets that 857 to mean loss of the remote PE node. This assumes that resiliency 858 mechanisms are in place to protect the route to the remote PE 859 nodes, and hence loss of IP reachability to a given node can only 860 mean that the node itself has failed. 862 It is worth noting here that loss of the LDP session with a PE in an 863 RG is not a reliable indicator that the remote PE itself is down. It 864 is possible, for e.g. that the remote PE encounters a local event 865 that leads to resetting the LDP session, while the PE node remains 866 operational for purpose of traffic forwarding. 868 6. ICCP Message Formats 870 This section defines the messages exchanged at the Application and 871 ICC layers. 873 6.1. Encoding ICC into LDP Messages 875 ICCP requires reliable, in-order, state-full message delivery, as 876 well as capability negotiation between PEs. The LDP protocol offers 877 all these features, and is already in wide use in the applications 878 that would also require the ICCP protocol extensions. For these 879 reasons, ICCP takes advantage of the already defined LDP protocol 880 infrastructure. 882 [RFC5036] Section 3.5 defines a generic LDP message structure. A new 883 set of LDP message types is defined to communicate the ICCP 884 information. LDP message types in the range of 0x700 to 0x7ff will be 885 used for ICCP. 887 Message types are allocated by IANA, and requested in the IANA 888 section below. 890 6.1.1. ICC Header 892 Every ICCP message comprises of an ICC specific LDP Header followed 893 by message data. The format of the ICC Header is as follows: 895 0 1 2 3 896 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 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 |U| Message Type | Message Length | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Message ID | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Type=0x0005 (ICC RG ID) | Length=4 | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | ICC RG ID | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | | 907 + + 908 | Mandatory Parameters | 909 ~ ~ 910 + + 911 | | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | | 914 + + 915 | Optional Parameters | 916 ~ ~ 917 + + 918 | | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 - U-bit 922 Unknown message bit. Upon receipt of an unknown message, if U is 923 clear (=0), a notification is returned to the message originator; 924 if U is set (=1), the unknown message is silently ignored. The 925 following sections which define messages specify a value for the 926 U-bit. 928 - Message Type 930 Identifies the type of the ICCP message, must be in the range of 931 0x0700 to 0x07ff. 933 - Message Length 935 Two octet integer specifying the total length of this message in 936 octets, excluding the U-bit, Message Type and Length fields. 938 - Message ID 940 Four octet value used to identify this message. Used by the 941 sending PE to facilitate identifying RG Notification messages 942 that may apply to this message. A PE sending an RG Notification 943 message in response to this message SHOULD include this Message 944 ID in the "NAK TLV" of the RG Notification message; see Section 945 "RG Notification Message". 947 - ICC RG ID TLV 949 A TLV of type 0x0005, length 4, containing 4 octets unsigned 950 integer designating the Redundancy Group which the sending device 951 is member of. RG ID value 0x00000000 is reserved by the protocol. 953 - Mandatory Parameters 955 Variable length set of required message parameters. Some 956 messages have no required parameters. 958 For messages that have required parameters, the required 959 parameters MUST appear in the order specified by the individual 960 message specifications in the sections that follow. 962 - Optional Parameters 964 Variable length set of optional message parameters. Many 965 messages have no optional parameters. 967 For messages that have optional parameters, the optional 968 parameters may appear in any order. 970 6.1.2. Message Encoding 972 The generic format of an ICC parameter is: 974 0 1 2 3 975 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 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 |U|F| Type | Length | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | TLV(s) | 980 ~ ~ 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 - U-bit 985 Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear 986 (=0), a notification MUST be returned to the message originator 987 and the entire message MUST be ignored; if U is set (=1), the 988 unknown TLV MUST be silently ignored and the rest of the message 989 processed as if the unknown TLV did not exist. The sections 990 following that define TLVs specify a value for the U-bit. 992 - F-bit 994 Forward unknown TLV bit. This bit applies only when the U-bit is 995 set and the LDP message containing the unknown TLV is to be 996 forwarded. If F is clear (=0), the unknown TLV is not forwarded 997 with the containing message; if F is set (=1), the unknown TLV is 998 forwarded with the containing message. The sections following 999 that define TLVs specify a value for the F-bit. By setting both 1000 the U- and F-bits, a TLV can be propagated as opaque data through 1001 nodes that do not recognize the TLV. 1003 - Type 1005 Fourteen bits indicating the parameter type. 1007 - Length 1009 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1010 Length fields. 1012 - TLV(s): A set of 0 or more TLVs, that vary according to the 1013 message type. 1015 6.1.3. ROID Encoding 1017 The Redundant Object Identifier (ROID) is a generic opaque handle 1018 that uniquely identifies a Redundant Object (e.g. link, bundle, VLAN, 1019 etc...) which is being protected in an RG. It is encoded as follows: 1021 0 1 2 3 1022 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 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | ROID | 1025 + + 1026 | | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 where: ROID is an 8 octets field encoded as an unsigned integer. The 1030 ROID value of 0 is reserved. 1032 The ROID is carried within application specific TLVs. 1034 6.2. RG Connect Message 1036 The RG Connect Message is used to establish the ICCP RG connection in 1037 addition to individual Application connections between PEs in an RG. 1038 An RG Connect message with no "Application-specific connect TLV" 1039 signals establishment of the ICCP RG connection. Whereas, an RG 1040 Connect message with a valid "Application-specific connect TLV" 1041 signals the establishment of an Application connection, in addition 1042 to the ICCP RG connection if the latter is not already established. 1044 An implementation MAY send a dedicated RG Connect message to set up 1045 the ICCP RG connection and a separate RG Connect message per client 1046 application. However, all implementations MUST support the receipt of 1047 an RG Connect message that triggers the setup of the ICCP RG 1048 connection as well as a single Application connection simultaneously. 1050 A PE sends an RG Connect Message to declare its membership in a 1051 Redundancy Group. One such message should be sent to each PE that is 1052 member of the same RG. The set of PEs to which RG Connect Messages 1053 should be transmitted is known via configuration or an auto-discovery 1054 mechanism that is outside the scope of this specification. If a 1055 device is member of multiple RGs, it MUST send separate RG Connect 1056 Messages for each RG even if the receiving device(s) happen to be the 1057 same. 1059 The format of the RG Connect Message is as follows: 1061 -i. ICC header with Message type = "RG Connect Message" (0x0700) 1062 -ii. ICC Sender Name TLV 1063 -iii. Zero or one Application-specific connect TLV 1065 The currently defined Application-specific connect TLVs are: 1067 - PW Redundancy Connect TLV 1069 - mLACP Connect TLV 1071 The details of these TLVs are discussed in the "Application TLVs" 1072 section. 1074 The RG Connect message can contain zero or one Application-specific 1075 connect TLV, but no application connect TLV can be sent more than 1076 once. 1078 6.2.1. ICC Sender Name TLV 1080 A TLV that carries the hostname of the sender encoded in UTF-8. This 1081 is used primarily for purpose of management of the RG and easing 1082 network operations. The specific format is shown below: 1084 0 1 2 3 1085 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 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 |U|F| Type = 0x0001 | Length | 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 | Sender Name | 1090 + +-+-+-+-+-+-+-+-+-+ 1091 ~ ~ 1092 | ... | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 - U=F=0 1097 - Type set to 0x0001 (from ICC parameter name space). 1099 - Length 1101 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1102 Length fields. 1104 - Sender Name 1106 Hostname of sending device encoded in UTF-8, and SHOULD NOT 1107 exceed 80 characters. 1109 6.3. RG Disconnect Message 1111 The RG Disconnect Message serves dual-purpose: to signal that a 1112 particular Application connection is being closed within an RG, or 1113 that the ICCP RG connection itself is being disconnected because the 1114 PE wishes to leave the RG. The format of this message is: 1116 0 1 2 3 1117 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 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 |U| Message Type=0x0701 | Message Length | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | Message ID | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | Type=0x0005 (ICC RG ID) | Length=4 | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | ICC RG ID | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | Disconnect Code TLV | 1128 + + 1129 | | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | Optional Application-specific Disconnect TLV | 1132 ~ ~ 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 | Optional Parameter TLVs | 1135 + + 1136 | | 1137 ~ ~ 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 - U-bit 1142 U=0 1144 - Message Type 1146 The message type for RG Disconnect Message is set to (0x0701) 1148 - Length 1150 Length of the TLV in octets excluding the U-bit, Message Type, 1151 and Message Length fields. 1153 - Message ID 1155 Defined in the "ICC Header" section above. 1157 - ICC RG ID 1159 Defined in the "ICC Header" section above. 1161 - Disconnect Code TLV 1163 The format of this TLV is as follows: 1165 0 1 2 3 1166 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 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 |U|F| Type=0x0004 | Length | 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 | ICCP Status Code | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 - U,F Bits 1175 both U and F are set to 0. 1177 - Type 1179 set to "Disconnect Code TLV" (0x0004) 1181 - Length 1183 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1184 Length fields. 1186 - ICCP Status Code 1188 A status code that reflects the reason for the disconnect 1189 message. Allowed values are "ICCP RG Removed" and "ICCP 1190 Application Removed from RG". 1192 - Optional Application-specific Disconnect TLV 1194 Zero or one Application-specific Disconnect TLVs which are 1195 defined later in the document. If the RG Disconnect message has 1196 a status code of "RG Removed", then it MUST NOT contain any 1197 Application-specific Disconnect TLVs, as the sending PE is 1198 signaling that it has left the RG and, thus, is disconnecting the 1199 ICCP RG connection, with all associated client application 1200 connections. If the message has a status code of "Application 1201 Removed from RG", then it MUST contain exactly one Application- 1202 specific Disconnect TLV, as the sending PE is only tearing down 1203 the connection for the specified application. Other applications, 1204 and the ICCP RG connection are not to be affected. 1206 - Optional Parameter TLVs 1208 None are defined for this message in this document. This is 1209 specified to allow for future extensions. 1211 6.4. RG Notification Message 1213 A PE sends an RG Notification Message to indicate one of the 1214 following: to reject an ICCP connection, to reject an application 1215 connection, to NAK an entire message or to NAK one or more TLV(s) 1216 within a message. The Notification message can only be sent to a PE 1217 that is already part of an RG. 1219 The RG Notification Message MUST NOT be used to NAK messages or TLVs 1220 corresponding to multiple ICCP applications simultaneously. In other 1221 words, there is a limit of at most a single ICCP application per RG 1222 Notification Message. 1224 The format of the RG Notification Message is: 1226 -i. ICC header with Message type = "RG Notification Message" 1227 (0x0702) 1228 -ii. Notification Message TLVs. 1230 The currently defined Notification message TLVs are: 1232 -i. ICC Sender Name TLV 1233 -ii. NAK TLV. 1235 6.4.1. Notification Message TLVs 1237 The ICC Sender Name TLV uses the same format as in the RG Connect 1238 message, and was described above. 1240 The NAK TLV is defined as follows: 1242 0 1 2 3 1243 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 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 |U|F| Type=0x0002 | Length | 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | ICCP Status Code | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | Rejected Message ID | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 | Optional TLV(s) | 1252 + + 1253 | | 1254 ~ ~ 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 - U,F Bits 1259 both U and F are set to 0. 1261 - Type 1263 set to "NAK TLV" (0x0002) 1265 - Length 1267 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1268 Length fields. 1270 - ICCP Status Code 1272 A status code that reflects the reason for the NAK TLV. Allowed 1273 values are: 1274 -i. Unknown RG (0x00010001) 1276 This code is used to reject a new incoming ICCP 1277 connection for an RG that is not configured on the local 1278 PE. When this code is used, the Rejected Message ID 1279 field MUST contain the message ID of the rejected "RG 1280 Connect" message. 1282 -ii. ICCP Connection Count Exceeded (0x00010002) 1284 This is used to reject a new incoming ICCP connection 1285 that would cause the local PE's ICCP connection count to 1286 exceed its capabilities. When this code is used, the 1287 Rejected Message ID field MUST contain the message ID of 1288 the rejected "RG Connect" message. 1290 -iii. Application Connection Count Exceeded (0x00010003) 1292 This is used to reject a new incoming application 1293 connection that would cause the local PE's ICCP 1294 connection count to exceed its capabilities. When this 1295 code is used, the Rejected Message ID field MUST contain 1296 the message ID of the rejected "RG Connect" message and 1297 the corresponding Application Connect TLV MUST be 1298 included in the "Optional TLV". 1300 -iv. Application not in RG (0x00010004) 1302 This is used to reject a new incoming application 1303 connection when the local PE doesn't support the 1304 application, or the application is not configured in the 1305 RG. When this code is used, the Rejected Message ID 1306 field MUST contain the message ID of the rejected "RG 1307 Connect" message and the corresponding Application 1308 Connect TLV MUST be included in the "Optional TLV". 1310 -v. Incompatible Protocol Version (0x00010005) 1312 This is used to reject a new incoming application 1313 connection when the local PE has an incompatible version 1314 of the application. When this code is used, the Rejected 1315 Message ID field MUST contain the message ID of the 1316 rejected "RG Connect" message and the corresponding 1317 Application Connect TLV MUST be included in the 1318 "Optional TLV". 1320 -vi. Rejected Message (0x00010006) 1322 This is used to reject an RG Application Data message, 1323 or one or more TLV(s) within the message. When this code 1324 is used, the Rejected Message ID field MUST contain the 1325 message ID of the rejected "RG Application Data" 1326 message. 1328 -vii. ICCP Administratively Disabled (0x00010007) 1330 This is used to reject any ICCP messages from a peer 1331 from which the PE is not allowed to exchange ICCP 1332 messages due to local administrative policy. 1334 - Rejected Message ID 1336 If non-zero, four octets value that identifies the peer message 1337 to which the NAK TLV refers. If zero, no specific peer message is 1338 being identified. 1340 - Optional TLV(s) 1342 A set of one or more optional TLVs. If the status code is 1343 "Rejected Message" then this field contains the TLV(s) that were 1344 rejected. If the entire message is rejected, all its TLVs MUST be 1345 present in this field; otherwise, the subset of TLVs that were 1346 rejected MUST be echoed in this field. 1348 If the status code is "Incompatible Protocol Version" then this 1349 field contains the original "Application Connect TLV" sent by the 1350 peer, in addition to the "Requested Protocol Version TLV" defined 1351 below: 1353 0 1 2 3 1354 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 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 |U|F| Type=0x0003 | Length | 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | Connection Reference | Requested Version | 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 - U and F Bits 1363 Both are set to 0. 1365 - Type 1367 set to 0x0003 for "Requested Protocol Version TLV" 1369 - Length 1371 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1372 Length fields. 1374 - Connection Reference 1376 This field is set to the Type field of the Application specific 1377 Connect TLV that was rejected because of incompatible version. 1379 - Requested Version 1381 The version of the application supported by the transmitting 1382 device. For this version of the protocol it is set to 0x0001. 1384 6.5. RG Application Data Message 1386 The RG Application Data Message is used to transport application data 1387 between PEs within an RG. A single message can be used to carry data 1388 from only one application. Multiple application TLVs are allowed in a 1389 single message, as long as all of these TLVs belong to the same 1390 application. The format of the Application Data Message is: 1392 -i. ICC header with Message type = "RG Application Data Message" 1393 (0x703) 1394 -ii. "Application specific TLVs" 1396 The details of these TLVs are discussed in the "Application TLVs" 1397 section. All application specific TLVs in one RG Application Data 1398 Message MUST belong to a single application but MAY reference 1399 different ROs. 1401 7. Application TLVs 1403 7.1. Pseudowire Redundancy (PW-RED) Application TLVs 1405 This section discusses the ICCP TLVs for the Pseudowire Redundancy 1406 application. 1408 7.1.1. PW-RED Connect TLV 1410 This TLV is included in the RG Connect message to signal the 1411 establishment of PW-RED application connection. 1413 0 1 2 3 1414 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 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 |U|F| Type=0x0010 | Length | 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 | Protocol Version |A| Reserved | 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 | Optional Sub-TLVs | 1421 ~ ~ 1422 | | 1423 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 | ... | 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 - U and F Bits 1429 Both are set to 0. 1431 - Type 1433 set to 0x0010 for "PW-RED Connect TLV" 1435 - Length 1437 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1438 Length fields. 1440 - Protocol Version 1442 The version of this particular protocol for the purposes of ICCP. 1443 This is set to 0x0001. 1445 - A bit 1447 Acknowledgement Bit. Set to 1 if the sender has received a PW-RED 1448 Connect TLV from the recipient. Otherwise, set to 0. 1450 - Reserved 1452 Reserved for future use. 1454 - Optional Sub-TLVs 1456 There are no optional Sub-TLVs defined for this version of the 1457 protocol. 1459 7.1.2. PW-RED Disconnect TLV 1461 This TLV is used in an RG Disconnect Message to indicate that the 1462 connection for the PW-RED application is to be terminated. 1464 0 1 2 3 1465 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 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 |U|F| Type=0x0011 | Length | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | Optional Sub-TLVs | 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 - U and F Bits 1474 Both are set to 0. 1476 - Type 1478 set to 0x0011 for "PW-RED Disconnect TLV" 1480 - Length 1482 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1483 Length fields. 1485 - Optional Sub-TLVs 1487 The only optional Sub-TLV defined for this version of the 1488 protocol is the "PW-RED Disconnect Cause" TLV defined next: 1490 7.1.2.1. PW-RED Disconnect Cause TLV 1492 0 1 2 3 1493 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 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 |U|F| Type=0x0019 | Length | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 | Disconnect Cause String | 1498 ~ ~ 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 - U and F Bits 1502 Both are set to 0. 1504 - Type 1506 set to 0x0019 for "PW-RED Disconnect Cause TLV" 1508 - Length 1510 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1511 Length fields. 1513 - Disconnect Cause String 1515 Variable length string specifying the reason for the disconnect. 1516 Used for network management. 1518 7.1.3. PW-RED Config TLV 1520 The PW-RED Config TLV is used in the RG Application Data message and 1521 has the following format: 1523 0 1 2 3 1524 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 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 |U|F| Type = 0x0012 | Length | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 | ROID | 1529 + + 1530 | | 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 | PW Priority | Flags | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 | Service Name TLV | 1535 ~ ~ 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | PW ID TLV or Generalized PW ID TLV | 1538 ~ ~ 1539 | | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 - U and F Bits 1543 Both are set to 0. 1545 - Type 1547 set to 0x0012 for "PW-RED Config TLV" 1549 - Length 1551 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1552 Length fields. 1554 - ROID 1556 As defined in the ROID section above. 1558 - PW Priority 1560 Two octets Pseudowire Priority. Used to indicate which PW has 1561 better priority to go into Active state. Numerically lower 1562 numbers are better priority. In case of a tie, the PE with the 1563 numerically lower identifier (i.e. IP Address) has better 1564 priority. 1566 - Flags 1568 Valid values are: 1570 -i. Synchronized (0x01) 1572 Indicates that the sender has concluded transmitting all 1573 pseudowire configuration for a given service. 1575 -ii. Purge Configuration (0x02) 1577 Indicates that the pseudowire is no longer configured 1578 for PW-RED operation. 1580 -iii. Independent Mode (0x04) 1582 Indicates that the pseudowire is configured for 1583 redundancy using the Independent Mode of operation, per 1584 section 5.1 of [RED-BIT]. 1586 -iv. Independent Mode with Request Switchover (0x08) 1588 Indicates that the pseudowire is configured for 1589 redundancy using the Independent Mode of operation with 1590 the use of the "Request Switchover" bit, per section 6.3 1591 of [RED-BIT]. 1593 -v. Master Mode (0x10) 1595 Indicates that the pseudowire is configured for 1596 redundancy using the Master/Slave Mode of operation, 1597 with the advertising PE acting as Master, per section 1598 5.2 of [RED-BIT]. 1600 -vi. Slave Mode (0x20) 1602 Indicates that the pseudowire is configured for 1603 redundancy using the Master/Slave Mode of operation, 1604 with the advertising PE acting as Slave, per section 5.2 1605 of [RED-BIT]. 1607 - Sub-TLVs 1609 The "PW-RED Config TLV" includes the following two sub-TLVs: 1611 -i. Service Name TLV 1613 -ii. PW ID TLV or Generalized PW ID TLV 1615 The format of the sub-TLVs is as follows: 1617 7.1.3.1. Service Name TLV 1619 0 1 2 3 1620 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 1621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 |U|F| Type | Length | 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 | Service Name | 1625 ~ ~ 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 - U and F Bits 1629 Both are set to 0. 1631 - Type 1633 set to 0x0013 for "Service Name TLV" 1635 - Length 1637 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1638 Length fields. 1640 - Service Name 1642 The name of the L2VPN service instance encoded in UTF-8 format 1643 and up to 80 character in length. 1645 7.1.3.2. PW ID TLV 1647 This TLV is used to communicate the configuration of PWs for VPWS. 1649 0 1 2 3 1650 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 1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1652 |U|F| Type | Length | 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | Peer ID | 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 | Group ID | 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 | PW ID | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 - U and F Bits 1663 Both are set to 0. 1665 - Type 1667 set to 0x0014 for "PW ID TLV" 1669 - Length 1671 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1672 Length fields. 1674 - Peer ID 1676 Four octet LDP Router ID of the peer at the far end of the PW. 1678 - Group ID 1680 Same as Group ID in [RFC4447] section 5.2. 1682 - PW ID 1684 Same as PW ID in [RFC4447] section 5.2. 1686 7.1.3.3. Generalized PW ID TLV 1688 This TLV is used to communicate the configuration of PWs for VPLS. 1690 0 1 2 3 1691 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 1692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1693 |U|F| Type = 0x0015 | Length | 1694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1695 | AGI Type | Length | Value | 1696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1697 ~ AGI Value (contd.) ~ 1698 | | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | AII Type | Length | Value | 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 ~ SAII Value (contd.) ~ 1703 | | 1704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1705 | AII Type | Length | Value | 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 ~ TAII Value (contd.) ~ 1708 | | 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 - U and F bits 1713 both set to 0. 1715 - Type 1717 set to 0x0015 1719 - Length 1721 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1722 Length fields. 1724 - AGI, AII, SAII and TAII 1726 defined in [RFC4447] section 5.3.2. 1728 7.1.4. PW-RED State TLV 1730 The PW-RED State TLV is used in the RG Application Data Message. This 1731 TLV is used by a device to report its PW status to other members in 1732 the RG. 1734 The format of this TLV is as follows: 1736 0 1 2 3 1737 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 1738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1739 |U|F| Type=0x0016 | Length | 1740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 | ROID | 1742 + + 1743 | | 1744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 | Local PW State | 1746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1747 | Remote PW State | 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 - U and F Bits 1752 Both are set to 0. 1754 - Type 1756 set to 0x0016 for PW-RED State TLV. 1758 - Length 1760 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1761 Length fields. 1763 - ROID 1765 As defined in the ROID section above. 1767 - Local PW State 1769 The status of the PW as determined by the sending PE, encoded in 1770 the same format as the "Status Code" field of the "PW Status TLV" 1771 defined in [RFC4447] and extended in [RED-BIT]. 1773 - Remote PW State 1775 The status of the PW as determined by the remote peer of the 1776 sending PE. Encoded in the same format as the "Status Code" field 1777 of the "PW Status TLV" defined in [RFC4447] and extended in 1778 [RED-BIT]. 1780 7.1.5. PW-RED Synchronization Request TLV 1782 The PW-RED Synchronization Request TLV is used in the RG Application 1783 Data message. This TLV is used by a device to request from its peer 1784 to retransmit configuration or operational state. The following 1785 information can be requested: 1787 - configuration and/or state for one or more pseudowires 1789 - configuration and/or state for all pseudowires 1791 - configuration and/or state for all pseudowires in a given service 1793 The format of the TLV is as follows: 1795 0 1 2 3 1796 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 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1798 |U|F| Type=0x0017 | Length | 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 | Request Number |C|S| Request Type | 1801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 | Optional Sub-TLVs | 1803 ~ ~ 1804 | | 1805 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | ... | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 - U and F Bits 1811 Both are set to 0. 1813 - Type 1815 set to 0x0017 for "PW-RED Synchronization Request TLV" 1817 - Length 1819 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1820 Length fields. 1822 - Request Number 1824 2 octets. Unsigned integer uniquely identifying the request. Used 1825 to match the request with a response. The value of 0 is reserved 1826 for unsolicited synchronization, and MUST NOT be used in the PW- 1827 RED Synchronization Request TLV. 1829 - C Bit 1831 Set to 1 if request is for configuration data. Otherwise, set to 1832 0. 1834 - S Bit 1836 Set to 1 if request is for running state data. Otherwise, set to 1837 0. 1839 - Request Type 1841 14-bits specifying the request type, encoded as follows: 1843 0x00 Request Data for specified pseudowire(s) 1844 0x01 Request Data for all pseudowires in specified service(s) 1845 0x3FFF Request All Data 1847 - Optional Sub-TLVs 1849 A set of zero or more TLVs, as follows: 1851 If the Request Type field is set to (0x00), then this field 1852 contains one or more PW ID TLV(s) or Generalized PW ID TLV(s). If 1853 the Request Type field is set to (0x01), then this field contains 1854 one or more Service Name TLV(s). If the Request Type field is set 1855 to (0x3FFF), then this field MUST be empty. 1857 7.1.6. PW-RED Synchronization Data TLV 1859 The PW-RED Synchronization Data TLV is used in the RG Application 1860 Data mesage. A pair of these TLVs is used by a device to delimit a 1861 set of TLVs that are sent in response to a PW-RED Synchronization 1862 Request TLV. The delimiting TLVs signal the start and end of the 1863 synchronization data, and associate the response with its 1864 corresponding request via the Request Number field. 1866 The PW-RED Synchronization Data TLVs are also used for unsolicited 1867 advertisements of complete PW-RED configuration and operational state 1868 data. In this case, the Request Number field MUST be set to 0. 1870 This TLV has the following format: 1872 0 1 2 3 1873 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 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 |U|F| Type=0x0018 | Length | 1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 | Request Number | Flags | 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1880 - U and F Bits 1882 Both are set to 0. 1884 - Type 1886 set to 0x0018 for "PW-RED Synchronization Data TLV" 1888 - Length 1890 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1891 Length fields. 1893 - Request Number 1895 2 octets. Unsigned integer identifying the Request Number from 1896 the "PW-RED Synchronization Request TLV" which solicited this 1897 synchronization data response. 1899 - Flags 1901 2 octets, response flags encoded as follows: 1903 0x00 Synchronization Data Start 1904 0x01 Synchronization Data End 1906 7.2. Multi-chassis LACP (mLACP) Application TLVs 1908 This section discusses the ICCP TLVs for Ethernet attachment circuit 1909 redundancy using the multi-chassis LACP (mLACP) application. 1911 7.2.1. mLACP Connect TLV 1913 This TLV is included in the RG Connect message to signal the 1914 establishment of mLACP application connection. 1916 0 1 2 3 1917 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 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 |U|F| Type=0x0030 | Length | 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 | Protocol Version |A| Reserved | 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 | Optional Sub-TLVs | 1924 ~ ~ 1925 | | 1926 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1927 | ... | 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 - U and F Bits 1932 Both are set to 0. 1934 - Type 1936 set to 0x0030 for "mLACP Connect TLV" 1938 - Length 1940 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1941 Length fields. 1943 - Protocol Version 1945 The version of this particular protocol for the purposes of ICCP. 1946 This is set to 0x0001. 1948 - A Bit 1950 Acknowledgement Bit. Set to 1 if the sender has received an mLACP 1951 Connect TLV from the recipient. Otherwise, set to 0. 1953 - Reserved 1955 Reserved for future use. 1957 - Optional Sub-TLVs 1959 There are no optional Sub-TLVs defined for this version of the 1960 protocol. 1962 7.2.2. mLACP Disconnect TLV 1964 This TLV is used in an RG Disconnect Message to indicate that the 1965 connection for the mLACP application is to be terminated. 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=0x0031 | Length | 1971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 | Optional Sub-TLVs | 1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 - U and F Bits 1977 Both are set to 0. 1979 - Type 1981 set to 0x0031 for "mLACP Disconnect TLV" 1983 - Length 1985 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1986 Length fields. 1988 - Optional Sub-TLVs 1990 The only optional Sub-TLV defined for this version of the 1991 protocol is the "mLACP Disconnect Cause" TLV defined next: 1993 7.2.2.1. mLACP Disconnect Cause TLV 1995 0 1 2 3 1996 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 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1998 |U|F| Type=0x003A | Length | 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2000 | Disconnect Cause String | 2001 ~ ~ 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 - U and F Bits 2006 Both are set to 0. 2008 - Type 2010 set to 0x003A for "mLACP Disconnect Cause TLV" 2012 - Length 2014 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2015 Length fields. 2017 - Disconnect Cause String 2019 Variable length string specifying the reason for the disconnect. 2020 Used for network management. 2022 7.2.3. mLACP System Config TLV 2024 The mLACP System Config TLV is sent in the RG Application Data 2025 message. This TLV announces the local node's LACP System Parameters 2026 to the RG peers. 2028 0 1 2 3 2029 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 2030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2031 |U|F| Type=0x0032 | Length | 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2033 | System ID | 2034 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2035 | | System Priority | 2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 | Node ID | 2038 +-+-+-+-+-+-+-+-+ 2039 - U and F Bits 2041 Both are set to 0. 2043 - Type 2045 set to 0x0032 for "mLACP System Config TLV" 2047 - Length 2049 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2050 Length fields. 2052 - System ID 2054 6 octets field encoding the System ID used by LACP as specified 2055 in [IEEE-802.1AX] section 5.3.2. 2057 - System Priority 2059 2 octets encoding the LACP System Priority as defined in [IEEE- 2060 802.1AX] section 5.3.2. 2062 - Node ID 2064 One octet, LACP node ID. Used to ensure that the LACP Port 2065 Numbers are unique across all devices in an RG. Valid values are 2066 in the range 0 - 7. Uniqueness of the LACP Port Numbers across 2067 RG members is ensured by encoding the Port Numbers as follows: 2069 - Most significant bit always set to 1 2070 - The next 3 most significant bits set to Node ID 2071 - Remaining 12 bits freely assigned by the system 2073 7.2.4. mLACP Aggregator Config TLV 2075 The mLACP Aggregator Config TLV is sent in the RG Application Data 2076 message. This TLV is used to notify RG peers about the local 2077 configuration state of an aggregator. 2079 0 1 2 3 2080 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 2081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2082 |U|F| Type=0x0036 | Length | 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 | ROID | 2085 + + 2086 | | 2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2088 | Aggregator ID | MAC Address | 2089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2090 | | 2091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2092 | Actor Key | Member Ports Priority | 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 | Flags | Agg Name Len | Aggregator Name | 2095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2096 ~ ~ 2097 | ... | 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2100 - U and F Bits 2102 Both are set to 0. 2104 - Type 2106 set to 0x0036 for "mLACP Aggregator Config TLV" 2108 - Length 2110 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2111 Length fields. 2113 - ROID 2115 Defined in the 'ROID Encoding' section above. 2117 - Aggregator ID 2119 Two octets, LACP Aggregator Identifier as specified in [IEEE- 2120 802.1AX] section 5.4.6 2122 - MAC Address 2124 Six octets encoding the Aggregator MAC address. 2126 - Actor Key 2128 Two octets, LACP Actor Key for the corresponding Aggregator, as 2129 specified in [IEEE-802.1AX] section 5.3.5. 2131 - Member Ports Priority 2133 Two octets, LACP administrative port priority associated with all 2134 interfaces bound to the Aggregator. This field is valid only when 2135 the "Flags" field has "Priority Set" asserted. 2137 - Flags 2139 Valid values are: 2141 -i. Synchronized (0x01) 2143 Indicates that the sender has concluded transmitting all 2144 Aggregator configuration information. 2146 -ii. Purge Configuration (0x02) 2148 Indicates that the Aggregator is no longer configured 2149 for mLACP operation. 2151 -iii. Priority Set (0x04) 2153 Indicates that the "Member Ports Priority" field is 2154 valid. 2156 - Agg Name Len 2158 One octet, length of the "Aggregator Name" field in octets. 2160 - Aggregator Name 2162 Aggregator name encoded in UTF-8 format, up to a maximum of 20 2163 characters. Used for ease of management. 2165 7.2.5. mLACP Port Config TLV 2167 The mLACP Port Config TLV is sent in the RG Application Data message. 2168 This TLV is used to notify RG peers about the local configuration 2169 state of a port. 2171 0 1 2 3 2172 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 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 |U|F| Type=0x0033 | Length | 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 | Port Number | MAC Address | 2177 +-------------------------------+ + 2178 | | 2179 +---------------------------------------------------------------+ 2180 | Actor Key | Port Priority | 2181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2182 | Port Speed | 2183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2184 | Flags | Port Name Len | Port Name | 2185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2186 ~ ~ 2187 | ... | 2188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2190 - U and F Bits 2192 Both are set to 0. 2194 - Type 2196 set to 0x0033 for "mLACP Port Config TLV" 2198 - Length 2200 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2201 Length fields. 2203 - Port Number 2205 Two octets, LACP Port Number for the corresponding interface as 2206 specified in [IEEE-802.1AX] section 5.3.4. The Port Number MUST 2207 be encoded with the Node ID as was discussed above. 2209 - MAC Address 2211 Six octets encoding the port MAC address. 2213 - Actor Key 2215 Two octets, LACP Actor Key for the corresponding interface, as 2216 specified in [IEEE-802.1AX] section 5.3.5. 2218 - Port Priority 2220 Two octets, LACP administrative port priority for the 2221 corresponding interface, as specified in [IEEE-802.1AX] section 2222 5.3.4. This field is valid only when the "Flags" field has 2223 "Priority Set" asserted. 2225 - Port Speed 2227 Four octets integer encoding the port's current bandwidth in 2228 units of 1,000,000 bits per second. This field corresponds to the 2229 ifHighSpeed object of IF-MIB [RFC2863]. 2231 - Flags 2233 Valid values are: 2235 -i. Synchronized (0x01) 2237 Indicates that the sender has concluded transmitting all 2238 member link port configurations for a given Aggregator. 2240 -ii. Purge Configuration (0x02) 2242 Indicates that the port is no longer configured for 2243 mLACP operation. 2245 -iii. Priority Set (0x04) 2247 Indicates that the "Port Priority" field is valid. 2249 - Port Name Len 2251 One octet, length of the "Port Name" field in octets. 2253 - Port Name 2255 Port (interface) name encoded in UTF-8 format, up to a maximum of 2256 20 characters. 2258 7.2.6. mLACP Port Priority TLV 2260 The mLACP Port Priority TLV is sent in the RG Application Data 2261 message. This TLV is used by a device to either advertise its 2262 operational Port Priority to other members in the RG, or to 2263 authoritatively request that a particular member of an RG change its 2264 port priority. 2266 0 1 2 3 2267 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 2268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2269 |U|F| Type=0x0034 | Length | 2270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2271 | OpCode | Port Number | 2272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2273 | Aggregator ID | Last Port Priority | 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2275 | Current Port Priority | 2276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2278 - U and F Bits 2280 Both are set to 0. 2282 - Type 2284 set to 0x0034 for "mLACP Port Priority TLV" 2286 - Length 2288 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2289 Length fields. 2291 - OpCode 2293 Two octets identifying the operational code-point for the TLV, 2294 encoded as follows: 2296 0x00 Local Priority Change Notification 2297 0x01 Remote Request for Priority Change 2299 - Port Number 2301 2 octets field representing the LACP Port Number as specified in 2302 [IEEE-802.1AX] section 5.3.4. When the value of this field is 0, 2303 it denotes all ports bound to the Aggregator specified in the 2304 "Aggregator ID" field. When non-zero, the Port Number MUST be 2305 encoded with the Node ID as was discussed above. 2307 - Aggregator ID 2309 Two octets, LACP Aggregator Identifier as specified in [IEEE- 2310 802.1AX] section 5.4.6 2312 - Last Port Priority 2314 Two octets, LACP port priority for the corresponding interface, 2315 as specified in [IEEE-802.1AX] section 5.3.4. For local ports, 2316 this field encodes the previous operational value of port 2317 priority. For remote ports, this field encodes the operational 2318 port priority last known to the PE via notifications received 2319 from its peers in the RG. 2321 - Current Port Priority 2323 Two octets, LACP port priority for the corresponding interface, 2324 as specified in [IEEE-802.1AX] section 5.3.4. For local ports, 2325 this field encodes the new operational value of port priority 2326 being advertised by the PE. For remote ports, this field 2327 specifies the new port priority being requested by the PE. 2329 7.2.7. mLACP Port State TLV 2331 The mLACP Port State TLV is used in the RG Application Data message. 2332 This TLV is used by a device to report its LACP port status to other 2333 members in the RG. 2335 0 1 2 3 2336 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 2337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2338 |U|F| Type=0x0035 | Length | 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2340 | Partner System ID | 2341 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2342 | | Partner System Priority | 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2344 | Partner Port Number | Partner Port Priority | 2345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2346 | Partner Key | Partner State | Actor State | 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2348 | Actor Port Number | Actor Key | 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 | Selected | Port State | Aggregator ID | 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2353 - U and F Bits 2355 Both are set to 0. 2357 - Type 2359 set to 0x0035 for "mLACP Port State TLV" 2361 - Length 2363 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2364 Length fields. 2366 - Partner System ID 2368 6 octets, the LACP Partner System ID for the corresponding 2369 interface, encoded as a MAC address as specified in [IEEE- 2370 802.1AX] section 5.4.2.2 item r. 2372 - Partner System Priority 2374 2 octets field specifying the LACP Partner System Priority as 2375 specified in [IEEE-802.1AX] section 5.4.2.2 item q. 2377 - Partner Port Number 2379 2 octets encoding the LACP Partner Port Number as specified in 2380 [IEEE-802.1AX] section 5.4.2.2 item u. The Port Number MUST be 2381 encoded with the Node ID as was discussed above. 2383 - Partner Port Priority 2385 2 octets field encoding the LACP Partner Port Priority as 2386 specified in [IEEE-802.1AX] section 5.4.2.2 item t. 2388 - Partner Key 2390 2 octets field representing the LACP Partner Key as defined in 2391 [IEEE-802.1AX] section 5.4.2.2 item s. 2393 - Partner State 2395 1 octet field encoding the LACP Partner State Variable as defined 2396 in [IEEE-802.1AX] section 5.4.2.2 item v. 2398 - Actor State 2400 1 octet encoding the LACP Actor's State Variable for the port as 2401 specified in [IEEE-802.1AX] section 5.4.2.2 item m. 2403 - Actor Port Number 2405 2 octets field representing the LACP Actor Port Number as 2406 specified in [IEEE-802.1AX] section 5.3.4. The Port Number MUST 2407 be encoded with the Node ID as was discussed above. 2409 - Actor Key 2411 2 octet field encoding the LACP Actor Operational Key as 2412 specified in [IEEE-802.1AX] section 5.3.5. 2414 - Selected 2416 1 octet encoding the LACP 'Selected' variable, defined in [IEEE- 2417 802.1AX] section 5.4.8, as follows: 2419 0x00 SELECTED 2420 0x01 UNSELECTED 2421 0x02 STANDBY 2423 - Port State 2425 1 octet encoding the operational state of the port as follows: 2426 0x00 Up 2427 0x01 Down 2428 0x02 Administrative Down 2429 0x03 Test (e.g. IEEE 802.3ah OAM Intrusive Loopback mode) 2431 - Aggregator ID 2433 Two octets, LACP Aggregator Identifier to which this port is 2434 bound based on the outcome of the LACP selection logic. 2436 7.2.8. mLACP Aggregator State TLV 2438 The mLACP Aggregator State TLV is used in the RG Application Data 2439 message. This TLV is used by a device to report its Aggregator status 2440 to other members in the RG. 2442 0 1 2 3 2443 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 2444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2445 |U|F| Type=0x0037 | Length | 2446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2447 | Partner System ID | 2448 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2449 | | Partner System Priority | 2450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2451 | Partner Key | Aggregator ID | 2452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2453 | Actor Key | Agg State | 2454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2456 - U and F Bits 2458 Both are set to 0. 2460 - Type 2462 set to 0x0037 for "mLACP Aggregator State TLV" 2464 - Length 2466 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2467 Length fields. 2469 - Partner System ID 2471 6 octets, the LACP Partner System ID for the corresponding 2472 interface, encoded as a MAC address as specified in [IEEE- 2473 802.1AX] section 5.4.2.2 item r. 2475 - Partner System Priority 2477 2 octets field specifying the LACP Partner System Priority as 2478 specified in [IEEE-802.1AX] section 5.4.2.2 item q. 2480 - Partner Key 2482 2 octets field representing the LACP Partner Key as defined in 2483 [IEEE-802.1AX] section 5.4.2.2 item s. 2485 - Aggregator ID 2487 Two octets, LACP Aggregator Identifier as specified in [IEEE- 2488 802.1AX] section 5.4.6 2490 - Actor Key 2492 2 octet field encoding the LACP Actor Operational Key as 2493 specified in [IEEE-802.1AX] section 5.3.5. 2495 - Agg State 2497 1 octet encoding the operational state of the Aggregator as 2498 follows: 2499 0x00 Up 2500 0x01 Down 2501 0x02 Administrative Down 2502 0x03 Test (e.g. IEEE 802.3ah OAM Intrusive Loopback mode) 2504 7.2.9. mLACP Synchronization Request TLV 2506 The mLACP Synchronization Request TLV is used in the RG Application 2507 Data message. This TLV is used by a device to request from its peer 2508 to re-transmit configuration or operational state. The following 2509 information can be requested: 2511 - system configuration and/or state 2513 - configuration and/or state for a specific port 2515 - configuration and/or state for all ports with a specific LACP key 2517 - configuration and/or state for all mLACP ports 2519 - configuration and/or state for a specific aggregator 2521 - configuration and/or state for all aggregators with a specific 2522 LACP key 2524 - configuration and/or state for all mLACP aggregators 2526 The format of the TLV is as follows: 2528 0 1 2 3 2529 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 2530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2531 |U|F| Type=0x0038 | Length | 2532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2533 | Request Number |C|S| Request Type | 2534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2535 | Port Number / Aggregator ID | Actor Key | 2536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2538 - U and F Bits 2540 Both are set to 0. 2542 - Type 2544 set to 0x0038 for "mLACP Synchronization Request TLV" 2546 - Length 2548 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2549 Length fields. 2551 - Request Number 2553 2 octets. Unsigned integer uniquely identifying the request. Used 2554 to match the request with a response. The value of 0 is reserved 2555 for unsolicited synchronization, and MUST NOT be used in the 2556 mLACP Synchronization Request TLV. 2558 - C Bit 2560 Set to 1 if request is for configuration data. Otherwise, set to 2561 0. 2563 - S Bit 2565 Set to 1 if request is for running state data. Otherwise, set to 2566 0. 2568 - Request Type 2570 14-bits specifying the request type, encoded as follows: 2572 0x00 Request System Data 2573 0x01 Request Aggregator Data 2574 0x02 Request Port Data 2575 0x3FFF Request All Data 2577 - Port Number / Aggregator ID 2579 2 octets. When Request Type field is set to 'Request Port Data', 2580 this field encodes the LACP Port Number for the requested port. 2581 When the Request Type field is set to 'Request Aggregator Data', 2582 this field encodes the Aggregator ID of the requested Aggregator. 2583 When the value of this field is 0, it denotes that all ports (or 2584 Aggregators), whose LACP Key is specified in the "Actor Key" 2585 field, are being requested. 2587 - Actor Key 2589 Two octets, LACP Actor key for the corresponding port or 2590 Aggregator. When the value of this field is 0 (and the Port 2591 Number/Aggregator ID field is 0 as well), it denotes that 2592 information for all ports or Aggregators in the system is being 2593 requested. 2595 7.2.10. mLACP Synchronization Data TLV 2597 The mLACP Synchronization Data TLV is used in the RG Application Data 2598 message. A pair of these TLVs is used by a device to delimit a set of 2599 TLVs that are being transmitted in response to an mLACP 2600 Synchronization Request TLV. The delimiting TLVs signal the start and 2601 end of the synchronization data, and associate the response with its 2602 corresponding request via the 'Request Number' field. 2604 The mLACP Synchronization Data TLVs are also used for unsolicited 2605 advertisements of complete mLACP configuration and operational state 2606 data. The 'Request Number' field MUST be set to 0 in this case. For 2607 such unsolicited synchronization, the PE MUST advertise all system, 2608 Aggregator and port information as done during the initialization 2609 sequence. 2611 This TLV has the following format: 2613 0 1 2 3 2614 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 2615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2616 |U|F| Type=0x0039 | Length | 2617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2618 | Request Number | Flags | 2619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2621 - U and F Bits 2623 Both are set to 0. 2625 - Type 2627 set to 0x0039 for "mLACP Synchronization Data TLV" 2629 - Length 2631 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2632 Length fields. 2634 - Request Number 2636 2 octets. Unsigned integer identifying the Request Number from 2637 the "mLACP Synchronization Request TLV" which solicited this 2638 synchronization data response. 2640 - Flags 2642 2 octets, response flags encoded as follows: 2644 0x00 Synchronization Data Start 2645 0x01 Synchronization Data End 2647 8. LDP Capability Negotiation 2649 As requited in [RFC5561] the following TLV is defined to indicate the 2650 ICCP capability: 2651 0 1 2 3 2652 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 2653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2654 |U|F| TLV Code Point=0x700 | Length | 2655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2656 |S| Reserved | Reserved | VER/Maj | Ver/Min | 2657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2658 where: 2660 - U-bit 2662 SHOULD be 1 (ignore if not understood). 2664 - F-bit 2666 SHOULD be 0 (don't forward if not understood). 2668 - TLV Code Point 2670 The TLV type, which identifies a specific capability. The ICCP 2671 code point is requested in the IANA allocation section below. 2673 - S-bit The State Bit indicates whether the sender is advertising 2674 or withdrawing the ICCP capability. The State bit is used as 2675 follows: 2676 1 - The TLV is advertising the capability specified by the 2677 TLV Code Point. 2679 0 - The TLV is withdrawing the capability specified by the 2680 TLV Code Point. 2682 - Ver/Maj 2684 The major version revision of the ICCP protocol, this document 2685 specifies 1.0. This field is then set to 1 2687 - Ver/Min 2689 The minor version revision of the ICCP protocol, this document 2690 specifies 1.0. This field is then set to 0 2692 ICCP capability is advertised to a LDP peer if there is at least one 2693 RG enabled on the local PE. 2695 9. Client Applications 2697 9.1. Pseudowire Redundancy Application Procedures 2699 This section defines the procedures for the Pseudowire Redundancy 2700 (PW-RED) Application. 2702 It should be noted that the PW-RED application SHOULD NOT be enabled 2703 together with an AC Redundancy application for the same service 2704 instance. This simplifies the operation of the multi-chassis 2705 redundancy solution (Figure 1) and eliminates the possibility of 2706 deadlock conditions between the AC and PW redundancy mechanisms. 2708 9.1.1. Initial Setup 2710 When an RG is configured on a system and multi-chassis pseudowire 2711 redundancy is enabled in that RG, the PW-RED application MUST send an 2712 "RG Connect" message with "PW-RED Connect TLV" to each PE that is a 2713 member of the same RG. The sending PE MUST set the A bit to 1 if it 2714 has already received a "PW-RED Connect TLV" from its peer; otherwise, 2715 the PE MUST set the A bit to 0. If a PE, that has sent the TLV with 2716 the A bit set to 0, receives a "PW-RED Connect TLV" from a peer, it 2717 MUST repeat its advertisement with the A bit set to 1. The PW-RED 2718 application connection is considered to be operational when both PEs 2719 have sent and received "PW-RED Connect TLVs" with the A bit set to 1. 2720 Once the application connection becomes operational, the two devices 2721 can start exchanging "RG Application Data" messages for the PW-RED 2722 application. 2724 If a system receives an "RG Connect" message with "PW-RED Connect 2725 TLV" that has a differing Protocol Version, it must follow the 2726 procedures outlined in the "Application Versioning" section above. 2728 When the PW-RED application is disabled on the device, or is 2729 unconfigured for the RG in question, the system MUST send an "RG 2730 Disconnect" message with "PW-RED Disconnect TLV". 2732 9.1.2. Pseudowire Configuration Synchronization 2734 A system MUST advertise its local PW configuration to other PEs that 2735 are members of the same RG. This allows the PEs to build a view of 2736 the redundant nodes and pseudowires that are protecting the same 2737 service instances. The advertisement MUST be initiated when the PW- 2738 RED application connection first comes up. To that end, the system 2739 sends "RG Application Data" messages with "PW-RED Config TLVs" as 2740 part of an unsolicited synchronization. A PE MUST use a pair of "PW- 2741 RED Synchronization Data TLVs" to delimit the set of TLVs that are 2742 being sent as part of this unsolicited advertisement. 2744 In the case of a configuration change, a PE MUST re-advertise the 2745 most up to date information for the affected pseudowires. 2747 As part of the configuration synchronization, a PE advertises the 2748 ROID associated with the pseudowire. This is used to correlate the 2749 pseudowires that are protecting each other on different PEs. As well, 2750 a PE advertises the configured PW redundancy mode. This can be one of 2751 the following four options: Master Mode, Slave Mode, Independent Mode 2752 or Independent Mode with Request Switchover. If the received 2753 redundancy mode does not match the locally configured mode for the 2754 same ROID, then the PE MUST respond with an "RG Notification Message" 2755 to NAK the "PW-RED Config TLV". The PE MUST disable the associated 2756 local pseudowire until a satisfactory "PW-RED Config TLV" is received 2757 from the peer. This guarantees that device mis-configuration does not 2758 lead to network wide problems (e.g. by creating forwarding loops). 2759 The PE SHOULD also raise an alarm to alert the operator. If a PE 2760 receives a NAK for an advertised "PW-RED Config TLV", it MUST disable 2761 the associated pseudowire and SHOULD raise an alarm to alert the 2762 operator. 2764 Furthermore, a PE advertises in its "PW-RED Config TLVs" a priority 2765 value that is used to determine the precedence of a given pseudowire 2766 to assume the Active role in a redundant setup. A PE also adverties a 2767 Service Name that is global in the context of an RG and is used to 2768 identify which pseudowires belong to the same service. Finally, a PE 2769 also advertises the pseudowire identifier as part of this 2770 synchronization. 2772 9.1.3. Pseudowire Status Synchronization 2774 PEs, that are member of an RG, synchronize pseudowire status for the 2775 purpose of identifying, on a per ROID basis, which pseudowire will be 2776 actively used for forwarding and which pseudowire(s) will be placed 2777 in standby state. 2779 Synchronization of pseudowire status is done by sending the "PW-RED 2780 State TLV" whenever the pseudowire state changes on a PE. This 2781 includes changes to the local end as well as the remote end of the 2782 pseudowire. 2784 A PE may request that its peer retransmit previously advertised PW- 2785 RED state. This is useful for instance when the PE is recovering from 2786 a soft failure. To request such retransmission, a PE MUST send a set 2787 of one or more "PW-RED Synchronization Request TLVs". 2789 A PE MUST respond to a "PW-RED Synchronization Request TLV" by 2790 sending the requested data in a set of one or more PW-RED TLVs 2791 delimited by a pair of "PW-RED Synchronization Data TLVs". The TLVs 2792 comprising the response MUST be ordered such that the Synchronization 2793 Response TLV with the "Synchronization Data Start" flag precedes the 2794 various other PW-RED TLVs encoding the requested data. These, in 2795 turn, MUST precede the Synchronization Data TLV with the 2796 "Synchronization Data End" flag. It is worth noting that the response 2797 may span across multiple RG Application Data messages; however, the 2798 above TLV ordering MUST be retained across messages, and only a 2799 single pair of Synchronization Data TLVs must be used to delimit the 2800 response across all Application Data Messages. 2802 A PE MAY re-advertise its PW-RED state in an unsolicited manner. This 2803 is done by sending the appropriate config and state TLVs delimited by 2804 a pair of "PW-RED Synchronization Data TLVs" and using a 'Request 2805 Number' of 0. 2807 While a PE has a pending synchronization request for a pseudowire or 2808 a service, it SHOULD silently ignore all TLVs for said pseudowire or 2809 service that are received prior to the synchronization response and 2810 which carry the same type of information being requested. This saves 2811 the system from the burden of updating state that will ultimately be 2812 overwritten by the synchronization response. Note that TLVs 2813 pertaining to other pseudowires or services are to continue to be 2814 processed per normal in the interim. 2816 If a PE receives a synchronization request for a pseudowire or 2817 service that doesn't exist or is not known to the PE, then it MUST 2818 trigger an unsolicited synchronization of all pseudowire information 2819 (i.e. replay the initialization sequence). 2821 In the subsections that follow, we describe the details of pseudowire 2822 status synchronization for each of the PW redundancy modes defined in 2823 [RED-BIT]. 2825 9.1.3.1. Independent Mode 2827 This section covers the operation in Independent Mode with or without 2828 Request Switchover capability. 2830 In this mode, the operator must ensure that for a given RO, the PW 2831 Priority values configured for all associated pseudowires on a given 2832 PE are collectively higher (or lower) than those configured on other 2833 PEs in the same RG. If this condition is not satisfied after the PEs 2834 have exchanged "PW-RED State TLVs", a PE MUST disable the associated 2835 pseudowire(s) and SHOULD raise an alarm to alert the operator. Note 2836 that the PW Priority MAY be the same as the PW Precedence defined in 2837 [RED-BIT]. 2839 For a given RO, after the all the PEs in an RG have exchanged their 2840 "PW-RED State TLVs", the PE with the best PW Priority (i.e. least 2841 numeric value) advertises Active preferential forwarding status in 2842 LDP on all its associated pseudowires. Whereas, all other PEs in the 2843 RG advertise Standby preferential forwarding status in LDP on their 2844 associated pseudowires. 2846 If the service is VPWS, then only a single pseudowire per service 2847 will be selected for forwarding. This is the pseudowire that is 2848 independently advertised with Active preferential forwarding status 2849 on both endpoints, as described in [RED-BIT]. 2851 If the service is VPLS, then one or multiple pseudowires per service 2852 will be selected for forwarding. These are the pseudowires that are 2853 independently advertised with Active preferential forwarding status 2854 on both PW endpoints, as described in [RED-BIT]. 2856 9.1.3.2. Master/Slave Mode 2858 In this mode, the operator must ensure that for a given RO, the PW 2859 Priority values configured for all associated pseudowires on a given 2860 PE are collectively higher (or lower) than those configured on other 2861 PEs in the same RG. If this condition is not satisfied after the PEs 2862 have exchanged "PW-RED State TLVs", a PE MUST disable the associated 2863 pseudowire(s) and SHOULD raise an alarm to alert the operator. Note 2864 that the PW Priority MAY be the same as the PW Precedence defined in 2865 [RED-BIT]. In addition, the operator must ensure that, for a given 2866 RO, all the PEs in the RG are consistently configured as Master or 2867 Slave. 2869 In the context of a given RO, if the PEs in the RG are acting as 2870 Master, then the PE with the best PW Priority (i.e. least numeric 2871 value) advertises Active preferential forwarding status in LDP on 2872 only a single pseudowire, following the procedures in sections 5.2 2873 and 6.2 of [RED-BIT]. Whereas, all the other pseudowires on other PEs 2874 in the RG are advertised with Standby preferential forwarding status 2875 in LDP. 2877 9.1.4. PE Node Failure 2879 When a PE node detects that a remote PE, that is member of the same 2880 RG, has gone down, the local PE examines if it has redundant PWs for 2881 the affected services. If the local PE has the highest priority 2882 (after the failed PE) then it becomes the active node for the 2883 services in question, and subsequently activates its associated 2884 PW(s). 2886 9.2. Attachment Circuit Redundancy Application Procedures 2888 9.2.1. Common AC Procedures 2890 This section describes generic procedures for AC Redundancy 2891 applications, independent of the type of the AC (ATM, FR or 2892 Ethernet). 2894 9.2.1.1. AC Failure 2896 When the AC Redundancy mechanism on the Active PE detects a failure 2897 of the AC, it should send an ICCP Application Data message to inform 2898 the redundant PEs of the need to take over. The AC failures can be 2899 categorized into the following scenarios: 2901 - Failure of CE interface connecting to PE 2903 - Failure of CE uplink to PE 2905 - Failure of PE interface connecting to CE 2907 9.2.1.2. PE Node Failure 2909 When a PE node detects that a remote PE, that is member of the same 2910 RG, has gone down, the local PE examines if it has redundant ACs for 2911 the affected services. If the local PE has the highest priority 2912 (after the failed PE) then it becomes the active node for the 2913 services in question, and subsequently activates its associated ACs. 2915 9.2.1.3. PE Isolation 2917 When a PE node detects that is has been isolated from the core 2918 network (i.e. all core facing interfaces/links are not operational), 2919 then it should ensure that its AC Redundancy mechanism will change 2920 the status of any active ACs to Standby. The AC Redundancy 2921 application should then send ICCP Application Data messages in order 2922 to trigger failover to a standby PE. 2924 9.2.1.4. Determining Pseudowire State 2926 If the PEs in an RG are running an AC Redundancy application over 2927 ICCP, then the Independent Mode of PW Redundancy, as defined in 2928 [RED-BIT], MUST be used. On a given PE, the Preferential Forwarding 2929 status of the PW (Active or Standby) is derived from the state of the 2930 associated AC(s). This simplifies the operation of the multi-chassis 2931 redundancy solution (Figure 1) and eliminates the possibility of 2932 deadlock conditions between the AC and PW redundancy mechanisms. The 2933 rules by which the PW status is derived from the AC status are as 2934 follows: 2936 - VPWS 2938 For VPWS, there's a single AC per service instance. If the AC is 2939 Active, then the PW status should be Active. If the AC is 2940 Standby, then the PW status should be Standby. 2942 - VPLS 2944 For VPLS, there could be multiple ACs per service instance (i.e. 2945 VFI). If AT LEAST ONE AC is Active, then the PW status should be 2946 Active. If ALL ACs are Standby, then the PW status should be 2947 Standby. 2949 In this case, the PW-RED application is not used to synchronize PW 2950 status between PEs. Rather, the AC Redundancy application should 2951 synchronize AC status between PE, in order to establish which AC (and 2952 subsequently which PE) is Active or Standby for a given service. When 2953 that is determined, each PE will then derive its local PWs state 2954 according to the rules described above. The Preferential Forwarding 2955 status bit, described in [RED-BIT], is used to advertise PW status to 2956 the remote peers. 2958 9.2.2. Multi-chassis LACP (mLACP) Application Procedures 2960 This section defines the procedures that are specific to the multi- 2961 chassis LACP (mLACP) application, which is applicable for Ethernet 2962 ACs. 2964 9.2.2.1. Initial Setup 2966 When an RG is configured on a system and mLACP is enabled in that RG, 2967 the mLACP application MUST send an "RG Connect" message with "mLACP 2968 Connect TLV" to each PE that is member of the same RG. The sending PE 2969 MUST set the A bit to 1 in the said TLV if it has received a 2970 corresponding "mLACP Connect TLV" from its peer PE; otherwise, the 2971 sending PE MUST set the A bit to 0. If a PE receives an "mLACP 2972 Connect TLV" from its peer after sending the said TLV with the A bit 2973 set to 0, it MUST resend the TLV with the A bit set to 1. A system 2974 considers the mLACP application connection to be operational when it 2975 has sent and received "mLACP Connect TLVs" with the A bit set to 1. 2976 When the mLACP application connection between a pair of PEs is 2977 operational, the two devices can start exchanging "RG Application 2978 Data" messages for the mLACP application. This involves having each 2979 PE advertise its mLACP configuration and operational state in an 2980 unsolicited manner. A PE SHOULD subscribe to the following order when 2981 advertising its mLACP state upon initial application connection 2982 setup: 2984 - Advertise system configuration 2985 - Advertise Aggregator configuration 2986 - Advertise port configuration 2987 - Advertise Aggregator state 2988 - Advertise port state 2990 A PE MUST use a pair of "mLACP Synchronization Data TLVs" to delimit 2991 the entire set of TLVs that are being sent as part of this 2992 unsolicited advertisement. 2994 If a system receives an "RG Connect" message with "mLACP Connect TLV" 2995 that has a differing Protocol Version, it MUST follow the procedures 2996 outlined in the "Application Versioning" section above. 2998 After the mLACP application connection has been established, every PE 2999 MUST communicate its system level configuration to its peers via the 3000 use of "mLACP System Config TLV". This allows every PE to discover 3001 the Node ID and the locally configured System ID and System Priority 3002 values of its peers. 3004 If a PE receives an "mLACP System Config TLV" from a remote peer 3005 advertising the same Node ID value as the local system, then the PE 3006 MUST respond with an "RG Notification Message" to NAK the "mLACP 3007 System Config TLV". The PE MUST suspend the mLACP application until a 3008 satisfactory "mLACP System Config TLV" is received from the peer. It 3009 SHOULD also raise an alarm to alert the operator. Furthermore, if a 3010 PE receives a NAK for an "mLACP System Config TLV" that it has 3011 advertised, the PE MUST suspend the mLACP application and SHOULD 3012 raise an alarm to alert the network operator of potential device 3013 mis-configuration. 3015 If a PE receives an "mLACP System Config TLV" from a new peer 3016 advertising the same Node ID value as another existing peer with 3017 which the local system has an established mLACP Application 3018 connection, then the PE MUST respond to the new peer with an "RG 3019 Notification Message" to NAK the "mLACP System Config TLV" and MUST 3020 ignore the offending TLV. 3022 If the Node ID of a particular PE changes due to administrative 3023 configuration action, the PE MUST then inform its peers to purge the 3024 configuration of all previously advertised ports and/or aggregators, 3025 and MUST replay the initialization sequence by sending an unsolicited 3026 synchronization of: the system configuration, Aggregator 3027 configuration, port configuration, Aggregator state and port state. 3029 It is necessary for all PEs in an RG to agree upon the System ID and 3030 System Priority values to be used ubiquitously. To achieve this, 3031 every PE MUST use the values for the two parameters that are supplied 3032 by the PE with the numerically lowest value (among RG members) of 3033 System Aggregation Priority. This guarantees that the PEs always 3034 agree on uniform values, which yield the highest System Priority. 3036 When the mLACP application is disabled on the device, or is 3037 unconfigured for the RG in question, the system MUST send an "RG 3038 Disconnect" message with "mLACP Disconnect TLV". 3040 9.2.2.2. mLACP Aggregator and Port Configuration 3042 A system MUST synchronize the configuration of its mLACP enabled 3043 Aggregators and ports with other RG members. This is achieved via the 3044 use of "mLACP Aggregator Config TLVs" and "mLACP Port Config TLVs", 3045 respectively. An implementation MUST advertise the configuration of 3046 Aggregators prior to advertising the configuration of any of their 3047 associated member ports. 3049 The PEs in an RG MUST all agree on the MAC address to be associated 3050 with a given Aggregator. It is possible to achieve this via 3051 consistent configuration on member PEs. However, in order to protect 3052 against possible misconfiguration, a system MUST use, for any given 3053 Aggregator, the MAC address supplied by the PE with the numerically 3054 lowest System Aggregation Priority in the RG. 3056 A system that receives an "mLACP Aggregator Config TLV" with an ROID 3057 to Key association that is different from its local association MUST 3058 NAK the corresponding TLV and disable the Aggregator with the same 3059 ROID. Furthermore, it SHOULD raise an alarm to alert the operator. 3060 Similarly, a system that receives a NAK in response to a transmitted 3061 "mLACP Aggregator Config TLV" MUST disable the associated Aggregator 3062 and SHOULD raise an alarm to alert the network operator. 3064 A system MAY enforce a restriction that all ports that are to be 3065 bundled together on a given PE share the same Port Priority value. If 3066 so, the system MUST advertise this common priority in the "mLACP 3067 Aggregator Config TLV" and assert the "Priority Set" flag in such 3068 TLV. Furthermore, the system in this case MUST NOT advertise 3069 individual Port Priority values in the associated "mLACP Port Config 3070 TLVs" (i.e. the "Priority Set" flag in these TLVs should be 0). 3072 A system MAY support individual Port Priority values to be configured 3073 on ports that are to be bundled together on a PE. If so, the system 3074 MUST advertise the individual Port Priority values in the appropriate 3075 "mLACP Port Config TLVs", and MUST NOT assert the "Priority Set" flag 3076 in the corresponding "mLACP Aggregator Config TLV". 3078 When the configurations of all ports for member links associated with 3079 a given Aggregator have been sent by a device, it asserts that fact 3080 by setting the "Synchronized" flag in the last port's "mLACP Port 3081 Config TLV". If an Aggregator doesn't have any candidate member ports 3082 configured, this is indicated by asserting the "Synchronized" flag in 3083 its "mLACP Aggregator Config TLV". 3085 Furthermore, for a given port/Aggregator, an implementation MUST 3086 advertise the port/Aggregator configuration prior to advertising its 3087 state (via the "mLACP Port State TLV" or "mLACP Aggregator State 3088 TLV"). If a PE receives an "mLACP Port State TLV" or "mLACP 3089 Aggregator State TLV" for a port or Aggregator that it had not 3090 learned of before via an appropriate Port or Aggregator Config TLV, 3091 then the PE MUST request synchronization of the configuration and 3092 state of all mLACP ports as well as all mLACP Aggregators from its 3093 respective peer. If during a synchronization (solicited or 3094 unsolicited), a PE receives a State TLV for a port or Aggregator that 3095 it has not learned of before, then the PE MUST send a NAK for the 3096 offending TLV. The PE MUST NOT request re-synchronization in this 3097 case. 3099 When mLACP is unconfigured on a port/Aggregator, a PE MUST send a 3100 "Port/Aggregator Config TLV" with the "Purge Configuration" flag 3101 asserted. This allows receiving PEs to purge any state maintained for 3102 the decommissioned port/Aggregator. If a PE receives a 3103 "Port/Aggregator Config TLV" with the "Purge Configuration" flag 3104 asserted, and the PE is not maintaining any state for that 3105 port/Aggregator, then it MUST silently discard the TLV. 3107 9.2.2.3. mLACP Aggregator and Port Status Synchronization 3109 PEs within an RG need to synchronize their state-machines for proper 3110 mLACP operation with a multi-homed device. This is achieved by having 3111 each system advertise its Aggregators and ports running state in 3112 "mLACP Aggregator State TLVs" and "mLACP Port State TLVs", 3113 respectively. Whenever any LACP parameter for an Aggregator or a 3114 port, whether on the Partner (i.e. multi-homed device) or the Actor 3115 (i.e. PE) side, is changed a system MUST transmit an updated TLV for 3116 the affected Aggregator and/or port. Moreover, when the 3117 administrative or operational state of an Aggregator or port changes, 3118 the system MUST transmit an updated Aggregator or port state TLV to 3119 its peers. 3121 If a PE receives an Aggregator or port state TLV where the 'Actor 3122 Key' doesn't match what was previously received in a corresponding 3123 Aggregator or port config TLV, the PE MUST then request 3124 synchronization of the configuration and state of the affected 3125 Aggregator or port. If such a mismatch occurs between the config and 3126 state TLVs as part of a synchronization (solicited or unsolicited), 3127 then the PE MUST send a NAK for the state TLV. Furthermore, if a PE 3128 receives a port state TLV with the 'Aggregator ID' set to a value 3129 that doesn't map to some Aggregator that the PE had learned of via a 3130 previous Aggregator config TLV, then the PE MUST request 3131 synchronization of the configuration and state of all Aggregators and 3132 ports. If the above anomaly occurs during a synchronization, then the 3133 PE MUST send a NAK for the offending port state TLV. 3135 A PE MAY request that its peer retransmit previously advertised 3136 state. This is useful for example when the PE is recovering from a 3137 soft failure and attempting to relearn state. To request such 3138 retransmissions, a PE MUST send a set of one or more "mLACP 3139 Synchronization Request TLVs". 3141 A PE MUST respond to an "mLACP Synchronization Request TLV" by 3142 sending the requested data in a set of one or more mLACP TLVs 3143 delimited by a pair of "mLACP Synchronization Data TLVs". The TLVs 3144 comprising the response MUST be ordered in the RG Application Data 3145 message(s) such that the Synchronization Response TLV with the 3146 "Synchronization Data Start" flag precedes the various other mLACP 3147 TLVs encoding the requested data. These, in turn, MUST precede the 3148 Synchronization Data TLV with the "Synchronization Data End" flag. 3149 Note that the response may span across multiple RG Application Data 3150 messages, for example when MTU limits are exceeded; however, the 3151 above ordering MUST be retained across messages, and only a single 3152 pair of Synchronization Data TLVs MUST be used to delimit the 3153 response across all Application Data Messages. 3155 A PE device MAY re-advertise its mLACP state in an unsolicited 3156 manner. This is done by sending the appropriate Config and State TLVs 3157 delimited by a pair of "mLACP Synchronization Data TLVs" and using a 3158 'Request Number' of 0. 3160 While a PE has a pending synchronization request for a system, 3161 Aggregator or port, it SHOULD silently ignore all TLVs for said 3162 system, Aggregator or port that are received prior to the 3163 synchronization response and which carry the same type of information 3164 being requested. This saves the system from the burden of updating 3165 state that will utlimately be overwritten by the synchronization 3166 response. Note that TLVs pertaining to other systems, Aggregators or 3167 ports are to continue to be processed per normal in this case. 3169 If a PE receives a synchronization request for an Aggregator, port or 3170 Key that doesn't exist or is not known to the PE, then it MUST 3171 trigger an unsolicited synchronization of all system, Aggregator and 3172 port information (i.e. replay the initialization sequence). 3174 If a PE learns, as part of a synchronization operation from its peer, 3175 that the latter is advertising a Node ID value which is different 3176 from the value previously advertised, then the PE MUST purge all 3177 port/aggregator data previously learnt from that peer prior to the 3178 last synchronization. 3180 9.2.2.4. Failure and Recovery 3182 When a PE that is active for a multi-chassis link aggregation group 3183 encounters a fault, it SHOULD attempt to fail-over to a peer PE which 3184 hosts the same RO. To that effect, the faulty PE SHOULD lower its 3185 port priority (by using a larger numeric value) and advertise this 3186 change in the "mLACP Port Priority TLV". If the PE is not capable of 3187 lowering its own port priority any further, it SHOULD trigger a 3188 failover to the redundant PE by sending an "mLACP Port Priority TLV" 3189 in which it requests the redundant PE to raise the latter's port 3190 priority to the maximum permitted in [IEEE-802.1AX] (i.e. the 3191 smallest allowed numeric value) for the Aggregator in question. 3192 Furthermore, the PE SHOULD set its own port priority to the next 3193 smallest numeric value. 3195 Upon recovery from a previous fault, a PE MAY reclaim active role for 3196 a multi-chassis link aggregation group if configured for revertive 3197 protection. Otherwise, the recovering PE may assume standby role 3198 when configured for non-revertive protection. In the revertive 3199 scenario, a PE SHOULD assume active role within the RG by sending an 3200 "mLACP Port Priority TLV" to the currently active PE, requesting that 3201 the latter change its port priority to a value that is lower (i.e. 3202 numerically larger) for the Aggregator in question. 3204 If a system is operating in a mode where different ports of a bundle 3205 are configured with different Port Priorities, then the system MUST 3206 NOT advertise or request change of Port Priority values for 3207 aggregated ports collectively (i.e. by using a 'Port Number' of 0 in 3208 the "mLACP Port Priority TLV"). This is to avoid ambiguity in the 3209 interpretation of the 'Last Port Priority' field. 3211 If a PE receives an "mLACP Port Priority TLV" requesting a priority 3212 change for a port or Aggregator that is not local to the device, then 3213 the PE MUST re-advertise the local configuration of the system, as 3214 well as the configuration and state of all its mLACP ports and 3215 Aggregators. 3217 If a PE receives an "mLACP Port Priority TLV" in which the remote 3218 system is advertising priority change for a port or Aggregator that 3219 the local PE had not learned of before via an appropriate Port or 3220 Aggregator Config TLV, then the PE MUST request synchronization of 3221 the configuration and state of all mLACP ports as well as all mLACP 3222 Aggregators from its respective peer. 3224 10. Security Considerations 3226 The security considerations described in [RFC5036] and [RFC4447] that 3227 apply to the base LDP specification, and to the PW LDP control 3228 protocol extensions apply to the capability mechanism described in 3229 this document. 3231 The ICCP protocol is not intended to be applicable when the 3232 redundancy group spans PE in different administrative domains. 3233 Furthermore, implementations SHOULD provide a mechanism to select to 3234 which LDP peers the ICCP capability will be advertised, and from 3235 which LDP peers the ICCP messages will be accepted. 3237 11. IANA Considerations 3239 11.1. MESSAGE TYPE NAME SPACE 3241 This document uses several new LDP message types, IANA already 3242 maintains a registry of name "MESSAGE TYPE NAME SPACE" defined by 3243 [RFC5036]. The following values are suggested for assignment: 3245 Message type Description 3246 0x0700 RG Connect Message 3247 0x0701 RG Disconnect Message 3248 0x0702 RG Notification Message 3249 0x0703 RG Application Data Message 3251 11.2. TLV TYPE NAME SPACE 3253 This document use a new LDP TLV type, IANA already maintains a 3254 registry of name "TLV TYPE NAME SPACE" defined by [RFC5036]. The 3255 following value is suggested for assignment: 3256 TLV Type Description 3257 0x700 ICCP capability TLV. 3259 11.3. ICC RG Parameter Type Space 3261 IANA needs to set up a registry of "ICC RG parameter type". These are 3262 14-bit values. Parameter Type values 1 through 0x000F are specified 3263 in this document, Parameter Type values 0x0010 through 0x1FFF are to 3264 be assigned by IANA, using the "Expert Review" policy defined in 3265 [RFC5226]. Parameter Type values 0x2000 through 0x2FFF, 0x3FFF, and 0 3266 are to be allocated using the IETF consensus policy defined in 3267 [RFC5226]. Parameter Type values 0x3000 through 0x3FFE are reserved 3268 for vendor proprietary extensions and are to be assigned by IANA, 3269 using the "First Come First Served" policy defined in [RFC5226]. A 3270 Parameter Type description is required for any assignment from this 3271 registry. Additionally, for the vendor proprietary extensions range a 3272 citation of a person or company name is also required. A document 3273 reference should also be provided. 3275 Initial ICC RG parameter type space value allocations are specified 3276 below: 3278 Parameter Type Description Reference 3279 -------------- --------------------------------- --------- 3280 0x0001 ICC Sender Name [RFCxxxx] 3281 0x0002 NAK TLV [RFCxxxx] 3282 0x0003 Requested Protocol Version TLV [RFCxxxx] 3283 0x0004 Disconnect Code TLV [RFCxxxx] 3284 0x0005 ICC RG ID TLV [RFCxxxx] 3286 0x0010 PW-RED Connect TLV [RFCxxxx] 3287 0x0011 PW-RED Disconnect TLV [RFCxxxx] 3288 0x0012 PW-RED Config TLV [RFCxxxx] 3289 0x0013 Service Name TLV [RFCxxxx] 3290 0x0014 PW ID TLV [RFCxxxx] 3291 0x0015 Generalized PW ID TLV [RFCxxxx] 3292 0x0016 PW-RED State TLV [RFCxxxx] 3293 0x0017 PW-RED Synchronization Request TLV [RFCxxxx] 3294 0x0018 PW-RED Synchronization Data TLV [RFCxxxx] 3295 0x0019 PW-RED Disconnect Cause TLV [RFCxxxx] 3297 0x0030 mLACP Connect TLV [RFCxxxx] 3298 0x0031 mLACP Disconnect TLV [RFCxxxx] 3299 0x0032 mLACP System Config TLV [RFCxxxx] 3300 0x0033 mLACP Port Config TLV [RFCxxxx] 3301 0x0034 mLACP Port Priority TLV [RFCxxxx] 3302 0x0035 mLACP Port State TLV [RFCxxxx] 3303 0x0036 mLACP Aggregator Config TLV [RFCxxxx] 3304 0x0037 mLACP Aggregator State TLV [RFCxxxx] 3305 0x0038 mLACP Synchronization Request TLV [RFCxxxx] 3306 0x0039 mLACP Synchronization Data TLV [RFCxxxx] 3307 0x003A mLACP Disconnect Cause TLV [RFCxxxx] 3309 11.4. STATUS CODE NAME SPACE 3311 This document use several new Status codes, IANA already maintains a 3312 registry of name "STATUS CODE NAME SPACE" defined by [RFC5036]. The 3313 following values is suggested for assignment: The "E" column is the 3314 required setting of the Status Code E-bit. 3315 Range/Value E Description Reference 3316 ------------- ----- ---------------------- --------- 3317 0x00010001 0 Unknown ICCP RG 3318 0x00010002 0 ICCP Connection Count Exceeded 3319 0x00010003 0 ICCP Application Connection 3320 Count Exceeded 3321 0x00010004 0 ICCP Application not in RG 3322 0x00010005 0 Incompatible ICCP Protocol Version 3323 0x00010006 0 ICCP Rejected Message 3324 0x00010007 0 ICCP Administratively Disabled 3325 0x00010010 0 ICCP RG Removed 3326 0x00010011 0 ICCP Application Removed from RG 3328 12. Acknowledgments 3330 The authors wish to acknowledge the important contributions of Dennis 3331 Cai, Neil McGill, Amir Maleki, Dan Biagini, Robert Leger, Sami 3332 Boutros, Neil Ketley and Mark Christopher Sains. 3334 The authors also thank Daniel Cohn, Lizhong Jin and Ran Chen for the 3335 valuable input, discussions and comments. 3337 13. Normative References 3339 [RFC5036] L. Andersson et al, "LDP Specification", RFC 5036, 3340 October 2007. 3342 [RFC5561] "LDP Capabilities", RFC5561, July 2009. 3344 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., 3345 et al., rfc4447 April 2006. 3347 [IEEE-802.1AX] IEEE Std. 802.1AX-2008, "IEEE Standard for Local and 3348 metropolitan area networks- Link Aggregation", IEEE Computer 3349 Society, November 2008. 3351 [RFC2863] K. McCloghrie, F. Kastenholz, "The Interfaces Group MIB", 3352 rfc2863, June 2000. 3354 14. Informative References 3356 [RED-BIT] Praveen Muley, Mustapha Aissaoui, "Pseudowire 3357 Preferential Forwarding Status Bit", 3358 draft-ietf-pwe3-redundancy-bit-07.txt, May 2012, 3359 Work in progress. 3361 [RFC5880] D. Katz, D. Ward, "Bidirectional Forwarding Detection", 3362 RFC5880, June 2010 3364 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3365 IANA Considerations section in RFCs", BCP 26, RFC 5226, May 2008 3367 15. Author's Addresses 3369 Luca Martini 3370 Cisco Systems, Inc. 3371 9155 East Nichols Avenue, Suite 400 3372 Englewood, CO, 80112 3373 e-mail: lmartini@cisco.com 3375 Samer Salam 3376 Cisco Systems, Inc. 3377 595 Burrard Street, Suite 2123 3378 Vancouver, BC V7X 1J1 3379 Canada 3380 e-mail: ssalam@cisco.com 3381 Ali Sajassi 3382 Cisco Systems, Inc. 3383 170 West Tasman Drive 3384 San Jose, CA 95134 3385 e-mail: sajassi@cisco.com 3387 Matthew Bocci 3388 Alcatel-Lucent 3389 Grove House, Waltham Road Rd 3390 White Waltham, Berks, UK. SL6 3TN 3391 e-mail: matthew.bocci@alcatel-lucent.co.uk 3393 Satoru Matsushima 3394 Softbank Telecom 3395 1-9-1, Higashi-Shinbashi, Minato-ku 3396 Tokyo 105-7313, JAPAN 3397 e-mail: satoru.matsushima@tm.softbank.co.jp 3399 Thomas Nadeau 3400 Juniper Networks 3401 10 Technology Park Drive, 3402 Westford, MA 01886 3403 USA 3404 e-mail: tnadeau@juniper.net 3406 Copyright Notice 3408 Copyright (c) 2012 IETF Trust and the persons identified as the 3409 document authors. All rights reserved. 3411 This document is subject to BCP 78 and the IETF Trust's Legal 3412 Provisions Relating to IETF Documents 3413 (http://trustee.ietf.org/license-info) in effect on the date of 3414 publication of this document. Please review these documents 3415 carefully, as they describe your rights and restrictions with respect 3416 to this document. Code Components extracted from this document must 3417 include Simplified BSD License text as described in Section 4.e of 3418 the Trust Legal Provisions and are provided without warranty as 3419 described in the Simplified BSD License. 3421 This document may contain material from IETF Documents or IETF 3422 Contributions published or made publicly available before November 3423 10, 2008. The person(s) controlling the copyright in some of this 3424 material may not have granted the IETF Trust the right to allow 3425 modifications of such material outside the IETF Standards Process. 3426 Without obtaining an adequate license from the person(s) controlling 3427 the copyright in such materials, this document may not be modified 3428 outside the IETF Standards Process, and derivative works of it may 3429 not be created outside the IETF Standards Process, except to format 3430 it for publication as an RFC or to translate it into languages other 3431 than English. 3433 Expiration Date: January 2013