idnits 2.17.1 draft-ietf-pwe3-iccp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2009) is 5297 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: 'IEEE802.3ad' is mentioned on line 2493, but not defined == Missing Reference: 'RFCxxxx' is mentioned on line 2606, but not defined ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.3' == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-09 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Luca Martini 3 Internet Draft Samer Salam 4 Intended status: Standards Track Cisco 5 Expires: April 24, 2010 7 Matthew Bocci Satoru Matsushima 8 Alcatel-Lucent Softbank 10 Thomas D. Nadeau 11 BT 12 October 24, 2009 14 Inter-Chassis Communication Protocol for L2VPN PE Redundancy 16 draft-ietf-pwe3-iccp-02.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 April 24, 2009 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.3 Redundant Object Identification ...................... 13 67 4.4 Application Connection Management .................... 14 68 4.5 Application Versioning ............................... 15 69 4.6 Application Data Transfer ............................ 15 70 4.7 Dedicated Redundancy Group LDP session ............... 16 71 5 ICCP PE Node Failure Detection Mechanism ............. 16 72 6 ICCP Message Formats ................................. 17 73 6.1 Encoding ICC into LDP Messages ...................... 17 74 6.1.1 ICC Header ........................................... 17 75 6.1.2 Message Encoding ..................................... 19 76 6.1.3 ROID Encoding ........................................ 20 77 6.2 RG Connect Message ................................... 21 78 6.2.1 ICC Sender Name TLV .................................. 22 79 6.3 RG Disconnect Message ................................ 22 80 6.4 RG Notification Message .............................. 25 81 6.4.1 Notification Message TLVs ............................ 25 82 6.5 RG Application Data Message .......................... 29 83 7 Application TLVs ..................................... 29 84 7.1 Pseudowire Redundancy (PW-RED) Application TLVs ...... 29 85 7.1.1 PW-RED Connect TLV ................................... 29 86 7.1.2 PW-RED Disconnect TLV ................................ 30 87 7.1.3 PW-RED Config TLV .................................... 31 88 7.1.4 Service Name TLV ..................................... 31 89 7.1.5 PW ID TLV ............................................ 32 90 7.1.6 Generalized PW ID TLV ................................ 33 91 7.2 Multi-chassis LACP (mLACP) Application TLVs .......... 34 92 7.2.1 mLACP Connect TLV .................................... 34 93 7.2.2 mLACP Disconnect TLV ................................. 35 94 7.2.3 mLACP System Config TLV .............................. 35 95 7.2.4 mLACP Aggregator Config TLV .......................... 37 96 7.2.5 mLACP Port Config TLV ................................ 39 97 7.2.6 mLACP Port Priority TLV .............................. 41 98 7.2.7 mLACP Port State TLV ................................. 42 99 7.2.8 mLACP Aggregator State TLV ........................... 45 100 7.2.9 mLACP Synchronization Request TLV .................... 46 101 7.2.10 mLACP Synchronization Data TLV ....................... 48 102 8 LDP Capability Negotiation ........................... 49 103 9 Client Applications .................................. 51 104 9.1 Pseudowire Redundancy Application Procedures ......... 51 105 9.1.1 Initial Setup ........................................ 51 106 9.1.2 Pseudowire Configuration ............................. 51 107 9.1.3 Pseudowire Status Synchronization .................... 52 108 9.1.4 PE Node Failure ...................................... 52 109 9.2 Attachment Circuit Redundancy Application Procedures . 52 110 9.2.1 Common AC Procedures ................................. 52 111 9.2.2 AC Failure ........................................... 53 112 9.2.3 PE Node Failure ...................................... 53 113 9.2.4 PE Isolation ......................................... 53 114 9.2.5 ATM AC Procedures .................................... 53 115 9.2.6 Frame Relay AC Procedures ............................ 53 116 9.2.7 Ethernet AC Procedures ............................... 53 117 9.2.8 Multi-chassis LACP (mLACP) Application Procedures .... 53 118 9.2.8.1 Initial Setup ........................................ 54 119 9.2.8.2 mLACP Aggregator and Port Configuration .............. 55 120 9.2.8.3 mLACP Aggregator and Port Status Synchronization ..... 56 121 9.2.8.4 Failure and Recovery ................................. 58 122 10 Security Considerations .............................. 59 123 11 IANA Considerations .................................. 59 124 11.1 MESSAGE TYPE NAME SPACE .............................. 59 125 11.2 TLV TYPE NAME SPACE .................................. 59 126 11.3 ICC RG Parameter Type Space .......................... 60 127 11.4 STATUS CODE NAME SPACE ............................... 61 128 12 Acknowledgments ...................................... 61 129 13 Normative References ................................. 61 130 14 Informative References ............................... 62 131 15 Author's Addresses ................................... 62 133 1. Specification of Requirements 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119. 139 2. Introduction 141 Network availability is a critical metric for service providers as it 142 has a direct bearing on their profitability. Outages translate not 143 only to lost revenue but also to potential penalties mandated by 144 contractual agreements with customers running mission-critical 145 applications that require tight SLAs. This is true for any carrier 146 network, and networks employing Layer 2 Virtual Private Network 147 (L2VPN) technology are no exception. Network high-availability can 148 be achieved by employing intra and inter-chassis redundancy 149 mechanisms. The focus of this document is on the latter. The document 150 defines an Inter-Chassis Communication Protocol (ICCP) that allows 151 synchronization of state and configuration data between a set of two 152 or more PEs forming a Redundancy Group (RG). The protocol supports 153 multi-chassis redundancy mechanisms that can be employed on either 154 the attachment circuit or pseudowire front. 156 3. ICCP Overview 158 3.1. Redundancy Model & Topology 160 The focus of this document is on PE node redundancy. It is assumed 161 that a set of two or more PE nodes are designated by the operator to 162 form a Redundancy Group (RG). Members of a Redundancy Group fall 163 under a single administration (e.g. service provider) and employ a 164 common redundancy mechanism towards the access (attachment circuits 165 or access pseudowires) and/or towards the core (pseudowires) for any 166 given service instance. It is possible, however, for members of an RG 167 to make use of disparate redundancy mechanisms for disjoint services. 168 The PE devices may be offering any type of L2VPN service, i.e. VPWS 169 or VPLS. As a matter of fact, the use of ICCP may even be applicable 170 for Layer 3 service redundancy, but this is considered to be outside 171 the scope of this document. 173 The PEs in an RG offer multi-homed connectivity to either individual 174 devices (e.g. CE, DSLAM, etc...) or entire networks (e.g. access 175 network). Figure 1 below depicts the model. 177 +=================+ 178 | | 179 Mutli-homed +----+ | +-----+ | 180 Node ------------> | CE |-------|--| PE1 ||<------|---Pseudowire-->| 181 | |--+ -|--| ||<------|---Pseudowire-->| 182 +----+ | / | +-----+ | 183 | / | || | 184 |/ | || ICCP |--> Towards Core 185 +-------------+ / | || | 186 | | /| | +-----+ | 187 | Access |/ +----|--| PE2 ||<------|---Pseudowire-->| 188 | Network |-------|--| ||<------|---Pseudowire-->| 189 | | | +-----+ | 190 | | | | 191 +-------------+ | Redundancy | 192 ^ | Group | 193 | +=================+ 194 | 195 Multi-homed Network 197 Figure 1: Generic Multi-chassis Redundancy Model 199 In the topology of Figure 1, the redundancy mechanism employed 200 towards the access node/network can be one of a multitude of 201 technologies, e.g. it could be IEEE 802.3ad Link Aggregation Groups 202 with Link Aggregation Control Protocol (LACP), or SONET APS. The 203 specifics of the mechanism are out of the scope of this document. 204 However, it is assumed that the PEs in the RG are required to 205 communicate amongst each other in order for the access redundancy 206 mechanism to operate correctly. As such, it is required to run an 207 inter-chassis communication protocol among the PEs in the RG in order 208 to synchronize configuration and/or running state data. 210 Furthermore, the presence of the inter-chassis communication channel 211 allows simplification of the pseudowire redundancy mechanism. This is 212 primarily because it allows the PEs within an RG to run some 213 arbitration algorithm to elect which pseudowire(s) should be in 214 active or standby mode for a given service instance. The PEs can then 215 advertise the outcome of the arbitration to the remote-end PE(s), as 216 opposed to having to embed a hand-shake procedure into the pseudowire 217 redundancy status communication mechanism, and every other possible 218 Layer 2 status communication mechanism. 220 3.2. ICCP Interconnect Scenarios 222 When referring to 'interconnect' in this section, we are concerned 223 with the links or networks over which Inter-Chassis Communication 224 Protocol messages are transported, and not normal data traffic 225 between PEs. The PEs which are members of an RG may be either 226 physically co-located or geo-redundant. Furthermore, the physical 227 interconnect between the PEs over which ICCP is to run may comprise 228 of either dedicated back-to-back links or a shared connection through 229 the packet switched network (PSN); for e.g., MPLS core network. This 230 gives rise to a matrix of four interconnect scenarios, described 231 next. 233 3.2.1. Co-located Dedicated Interconnect 235 In this scenario, the PEs within an RG are co-located in the same 236 physical location (POP, CO). Furthermore, dedicated links provide the 237 interconnect for ICCP among the PEs. 239 +=================+ +-----------------+ 240 |CO | | | 241 | +-----+ | | | 242 | | PE1 |________|_____| | 243 | | | | | | 244 | +-----+ | | | 245 | || | | | 246 | || ICCP | | Core | 247 | || | | Network | 248 | +-----+ | | | 249 | | PE2 |________|_____| | 250 | | | | | | 251 | +-----+ | | | 252 | | | | 253 +=================+ +-----------------+ 255 Figure 2: ICCP Co-located PEs Dedicated Interconnect Scenario 257 Given that the PEs are connected back-to-back in this case, it is 258 possible to rely on Layer 2 redundancy mechanisms to guarantee the 259 robustness of the ICCP interconnect. For example, if the interconnect 260 comprises of IEEE 802.3 Ethernet links, it is possible to provide 261 link redundancy by means of IEEE 802.3ad Link Aggregation Groups. 263 3.2.2. Co-located Shared Interconnect 265 In this scenario, the PEs within an RG are co-located in the same 266 physical location (POP, CO). However, unlike the previous scenario, 267 there are no dedicated links between the PEs. The interconnect for 268 ICCP is provided through the core network to which the PEs are 269 connected. Figure 3 depicts this model. 271 +=================+ +-----------------+ 272 |CO | | | 273 | +-----+ | | | 274 | | PE1 |________|_____| | 275 | | |<=================+ | 276 | +-----+ ICCP | | || | 277 | | | || | 278 | | | || Core | 279 | | | || Network | 280 | +-----+ | | || | 281 | | PE2 |________|_____| || | 282 | | |<=================+ | 283 | +-----+ | | | 284 | | | | 285 +=================+ +-----------------+ 287 Figure 3: ICCP Co-located PEs Shared Interconnect Scenario 289 Given that the PEs in the RG are connected over the packet switched 290 network (PSN), then PSN Layer mechanisms can be leveraged to ensure 291 the resiliency of the interconnect against connectivity failures. For 292 example, it is possible to employ RSVP LSPs with Fast Re-Route (FRR) 293 and/or end-to-end backup LSPs. 295 3.2.3. Geo-redundant Dedicated Interconnect 297 In this variation, the PEs within a Redundancy Group are located in 298 different physical locations to provide geographic redundancy. This 299 may be desirable, for example, to protect against natural disasters 300 or the like. A dedicated interconnect is provided to link the PEs, 301 which is a costly option, especially when considering the possibility 302 of providing multiple such links for interconnect robustness. The 303 resiliency mechanisms for the interconnect are similar to those 304 highlighted in the co-located interconnect counterpart. 306 +=================+ +-----------------+ 307 |CO 1 | | | 308 | +-----+ | | | 309 | | PE1 |________|_____| | 310 | | | | | | 311 | +-----+ | | | 312 +=====||==========+ | | 313 || ICCP | Core | 314 +=====||==========+ | Network | 315 | +-----+ | | | 316 | | PE2 |________|_____| | 317 | | | | | | 318 | +-----+ | | | 319 |CO 2 | | | 320 +=================+ +-----------------+ 322 Figure 4: ICCP Geo-redundant PEs Dedicated Interconnect Scenario 324 3.2.4. Geo-redundant Shared Interconnect 326 In this scenario, the PEs of an RG are located in different physical 327 locations and the interconnect for ICCP is provided over the PSN 328 network to which the PEs are connected. This interconnect option is 329 more likely to be the one used for geo-redundancy as it is more 330 economically appealing compared to the geo-redundant dedicated 331 interconnect. The resiliency mechanisms that can be employed to 332 guarantee the robustness of the ICCP transport are PSN Layer 333 mechanisms as has been described in the "Co-located Shared 334 Interconnect" section above. 336 +=================+ +-----------------+ 337 |CO 1 | | | 338 | +-----+ | | | 339 | | PE1 |________|_____| | 340 | | |<=================+ | 341 | +-----+ ICCP | | || | 342 +=================+ | || | 343 | || Core | 344 +=================+ | || Network | 345 | +-----+ | | || | 346 | | PE2 |________|_____| || | 347 | | |<=================+ | 348 | +-----+ | | | 349 |CO 2 | | | 350 +=================+ +-----------------+ 352 Figure 5: ICCP Geo-redundant PEs Shared Interconnect Scenario 354 3.3. ICCP Requirements 356 The Inter-chassis Communication Protocol SHOULD satisfy the following 357 requirements: 359 -i. Provide a control channel for communication between PEs in a 360 Redundancy Group (RG). Nodes may be co-located or remote 361 (refer to "Interconnect Scenarios" section above). It is 362 expected that client applications which make use of ICCP 363 services will only use this channel to communicate control 364 information and not data-traffic. As such the protocol 365 should cater for relatively low bandwidth, low-delay and 366 highly reliable message transfer. 368 -ii. Accommodate multiple client applications (e.g. multi-chassis 369 LACP, PW redundancy, SONET APS, etc...). This implies that 370 the messages should be extensible (e.g. TLV-based) and the 371 protocol should provide a robust application registration 372 and versioning scheme. 374 -iii. Provide reliable message transport and in-order delivery 375 between nodes in a RG with secure authentication mechanisms 376 built into the protocol. The redundancy applications that 377 are clients of ICCP expect reliable message transfer, and as 378 such will assume that the protocol takes care of flow- 379 control and retransmissions. Furthermore, given that the 380 applications will rely on ICCP to communicate data used to 381 synchronize state-machines on disparate nodes, it is 382 critical that ICCP guarantees in-order message delivery. 383 Loss of messages or out-of-sequence messages would have 384 adverse side-effects to the operation of the client 385 applications. 387 -iv. Provide a common mechanism to actively monitor the health of 388 PEs in an RG. This mechanism will be used to detect PE node 389 failure and inform the client applications. The applications 390 require this to trigger failover according to the procedures 391 of the employed redundancy protocol on the AC and PW. It is 392 desired to achieve sub-second detection of loss of remote 393 node (~ 50 - 150 msec) in order to give the client 394 applications (redundancy mechanisms) enough reaction time to 395 achieve sub-second service restoration time. 397 -v. Provide asynchronous event-driven state update, independent 398 of periodic messages, for immediate notification of client 399 applications' state changes. In other words, the 400 transmission of messages carrying application data should be 401 on-demand rather than timer-based to minimize inter-chassis 402 state synchronization delay. 404 -vi. Accommodate multi-link and multi-hop interconnect between 405 nodes. When the devices within an RG are located in 406 different physical locations, the physical interconnect 407 between them will comprise of a network rather than a link. 408 As such, ICCP should accommodate the case where the 409 interconnect involves multiple hops. Furthermore, it is 410 possible to have multiple (redundant) paths or interconnects 411 between a given pair of devices. This is true for both the 412 co-located and geo-redundant scenarios. ICCP should handle 413 this as well. 415 -vii. Ensure transport security between devices in an RG. This is 416 especially important in the scenario where the members of an 417 RG are located in different physical locations and connected 418 over a shared network (e.g. PSN). 420 -viii. Must allow operator to statically configure members of RG. 421 Auto-discovery may be considered in the future. 423 -ix. Allow for flexible RG membership. It is expected that only 424 two nodes per an RG will cover most of the redundancy 425 applications for common deployments. ICCP should not 426 preclude supporting more than two nodes in an RG by virtue 427 of design. Furthermore, it is required to allow a single 428 node to be member of multiple RGs simultaneously. 430 4. ICC LDP Protocol Extension Specification 432 To address the requirements identified in the previous section, ICCP 433 is modeled to comprise of three layers: 435 -i. Application Layer: This provides the interface to the 436 various redundancy applications that make use of the 437 services of ICCP. ICCP is concerned with defining common 438 connection management procedures and the formats of the 439 messages exchanged at this layer; however, beyond that, it 440 does not impose any restrictions on the procedures or 441 state-machines of the clients, as these are deemed 442 application-specific and lie outside the scope of ICCP. 443 This guarantees implementation inter-operability without 444 placing any unnecessary constraints on internal design 445 specifics. 447 -ii. Inter Chassis Communication (ICC) Layer: This layer 448 implements the common set of services which ICCP offers to 449 the client applications. It handles protocol versioning, RG 450 membership, Redundant Object identification, PE node 451 identification and ICCP connection management. 453 -iii. Transport Layer: This layer provides the actual ICCP message 454 transport. It is responsible for addressing, route 455 resolution, flow-control, reliable and in-order message 456 delivery, connectivity resiliency/redundancy and finally PE 457 node failure detection. The Transport layer may differ 458 depending on the Physical Layer of the inter-connect. 460 4.1. LDP ICCP Capability Advertisement 462 When an RG is enabled on a particular PE, the capability of 463 supporting ICCP must be advertised to all LDP peers in that RG. This 464 is achieved by using the methods in [RFC5561] and advertising the 465 ICCP LDP capability TLV. If an LDP peer supports the dynamic 466 capability advertisement, this can be done by sending a new 467 capability message with the S bit set for the ICCP capability TLV 468 when the first RG is enabled on the PE. If the peer does not support 469 dynamic capability advertisement, then the ICCP TLV MUST be included 470 in the LDP initialization procedures in the capability parameter 471 [RFC5561]. 473 4.2. RG Membership Management 475 ICCP defines a mechanism that enables PE nodes to manage their RG 476 membership. When a PE is configured to be a member of an RG, it will 477 first advertise the ICCP capability to its peers. Subsequently, the 478 PE sends an RG Connect message to the peers that have also advertised 479 ICCP capability. The PE then waits for the peers to send their own RG 480 Connect messages, if they haven't done so already. For a given RG, 481 the ICCP connection between two devices is considered to be 482 operational only when both have sent and received ICCP RG Connect 483 messages for that RG. 485 If a PE that has sent a particular RG Connect message doesn't receive 486 a corresponding RG Connect (or a Notification message with NAK) from 487 a destination, it will remain in a state expecting the corresponding 488 RG Connect message (or Notification message). The RG will not become 489 operational until the corresponding RG Connect Message has been 490 received. If a PE that has sent an RG Connect message receives a 491 Notification message with a NAK, it will stop attempting to bring up 492 the ICCP connection immediately. The PE MUST resume bringing up the 493 connection after it receives an RG Connect message from the peer PE 494 for the RG in question. This is achieved by responding to the 495 incoming RG Connect message with an appropriate RG Connect. 497 A device MUST send a NAK for an RG Connect message if at least one of 498 the following conditions is satisfied: 500 -i. the PE is not a member of the RG; 502 -ii. the maximum number of simultaneous ICCP connections that the 503 PE can handle is exceeded. 505 A PE sends an RG Disconnect message to tear down the ICCP connection 506 for a given RG. This is a unilateral operation and doesn't require 507 any acknowledgement from the other PEs. Note that the ICCP connection 508 for an RG MUST be operational before any client application can make 509 use of ICCP services in that RG. 511 4.3. Redundant Object Identification 513 ICCP offers its client applications a uniform mechanism for 514 identifying links, ports, forwarding constructs and more generally 515 objects (e.g. interfaces, pseudowires, VLANs, etc...) that are being 516 protected in a redundant setup. These are referred to as Redundant 517 Objects (RO). An example of an RO is a multi-chassis link-aggregation 518 group that spans two PEs. ICCP introduces a 64-bit opaque identifier 519 to uniquely identify ROs in an RG. This identifier, referred to as 520 Redundant Object ID (ROID), MUST match between RG members for the 521 protected object in question. That allows separate systems in an RG 522 to use a common handle to reference the protected entity irrespective 523 of its nature (e.g. physical or virtual) and in a manner that is 524 agnostic to implementation specifics. Client applications that need 525 to synchronize state pertaining to a particular RO SHOULD embed the 526 corresponding ROID in their TLVs. 528 4.4. Application Connection Management 530 ICCP provides a common set of procedures by which applications on one 531 PE can connect to their counterparts on another PE, for purpose of 532 inter-chassis communication in the context of a given RG. The 533 prerequisite for establishing an application connection is to have an 534 operational ICCP RG connection between the two endpoints. It is 535 assumed that the association of applications with RGs is known a 536 priori, e.g. by means of device configuration. ICCP then sends an 537 Application-specific Connect TLV (carried in RG Connect message), on 538 behalf of each client application, to each remote PE within the RG. 539 The client may piggyback application-specific information in that 540 Connect TLV, which for example can be used to negotiate parameters or 541 attributes prior to bringing up the actual application connection. 542 The procedures for bringing up the application connection are similar 543 to those of the ICCP connection: An application connection between 544 two nodes is up only when both nodes have sent and received RG 545 Connect Messages with the proper Application-specific Connect TLVs. A 546 PE MUST send a Notification Message to NAK an application connection 547 request if one of the following conditions is encountered: 549 -i. the application doesn't exist or is not configured for that 550 RG; 552 -ii. the application connection count exceeds the PE's 553 capabilities. 555 When a PE receives such a NAK notification, it MUST stop attempting 556 to bring up the application connection until it receives a new 557 application connection request from the remote PE. This is done by 558 responding to the incoming RG Connect message (carrying an 559 Application-specific Connect TLV) with an appropriate RG Connect 560 message (carrying a corresponding Application-specific Connect TLV). 562 When an application is stopped on a device or it is no longer 563 associated with an RG, it MUST signal ICCP to trigger sending an 564 Application-specific Disconnect TLV (in the RG Disconnect message). 565 This is a unilateral notification to the other PEs within an RG, and 566 as such doesn't trigger any response. 568 4.5. Application Versioning 570 During application connection setup time, a given application on one 571 PE can negotiate with its counterpart on a peer PE the proper 572 application version to use for communication. If no common version is 573 agreed upon, then the application connection is not brought up. This 574 is achieved through the following set of rules: 576 - If an application receives an Application-specific Connect TLV 577 with a version number that is higher than its own, it MUST send a 578 Notification message with a NAK TLV indicating status code 579 "Incompatible Protocol Version" and supplying the version that is 580 locally supported by the PE. 582 - If an application receives an Application-specific Connect TLV 583 with a version number that is lower than its own, it MAY respond 584 with an RG Connect that has an Application-specific Connect TLV 585 using the same version that was received. Alternatively, the 586 application MAY respond with a Notification message to NAK the 587 request using the "Incompatible Protocol Version" code, and 588 supplying the version that is supported. The above allows an 589 application to operate in either backwards compatible or 590 incompatible mode. 592 - If an application receives an Application-specific Connect TLV 593 with a version that is equal to its own, then the application 594 MUST honor or reject the request based on whether the application 595 is configured for the RG in question, and whether or not the 596 application connection count has been exceeded. 598 4.6. Application Data Transfer 600 When an application has information to transfer over ICCP it triggers 601 the transmission of an Application Data message. ICCP guarantees in- 602 order and loss-less delivery of data. An application may NAK a 603 message or a set of one or more TLVs within a message by using the 604 Notification Message with NAK TLV. Furthermore, an application may 605 implement its own ACK mechanism, if deemed required, by defining an 606 application-specific TLV to be transported in an Application Data 607 message. 609 It is left up to the application to define the procedures to handle 610 the situation where a PE receives a NAK in response to a transmitted 611 Application Data message. Depending on the specifics of the 612 application, it may be favorable to have the PE, which sent the NAK, 613 explicitly request retransmission of data. On the other hand, for 614 certain applications it may be more suitable to have the original 615 sender of the Application Data message handle retransmissions in 616 response to a NAK. ICCP supports both models. 618 4.7. Dedicated Redundancy Group LDP session 620 For certain ICCP applications, it is required to exchange a fairly 621 large amount of RG information in a very short period of time. In 622 order to better distribute the load in a multiple processor system, 623 and to avoid head of line blocking to other LDP applications, it may 624 be required to initiate a separate TCP/IP session between the two LDP 625 speakers. 627 This procedure is OPTIONAL, and does not change the operation of LDP 628 or ICCP. 630 A PE that requires a separate LDP session will advertise a separate 631 LDP adjacency with a non-zero label space identifier. This will cause 632 the remote peer to open a separate LDP session for this label space. 633 No labels need to be advertised in this label space, as it is only 634 used for one or a set of ICCP RGs. All relevant LDP and ICCP 635 procedures still apply as described in the relevant documents. 637 5. ICCP PE Node Failure Detection Mechanism 639 ICCP provides its client applications a notification when a remote PE 640 that is member of the RG fails. This is used by the client 641 applications to trigger failover according to the procedures of the 642 employed redundancy protocol on the AC and PW. To that end, ICCP does 643 not define its own KeepAlive mechanism for purpose of monitoring the 644 health of remote PE nodes, but rather reuses existing fault detection 645 mechanisms. The following mechanisms may be used by ICCP to detect PE 646 node failure: 648 - BFD 650 Run a BFD session [BFD] between the PEs that are members of a 651 given RG, and use that to detect PE node failure. This assumes 652 that resiliency mechanisms are in place to protect connectivity 653 to the remote PE nodes, and hence loss of BFD periodic messages 654 from a given PE node can only mean that the node itself has 655 failed. 657 - IP Reachability Monitoring 659 It is possible for a PE to monitor IP layer connectivity to other 660 members of an RG that are participating in IGP/BGP. When 661 connectivity to a given PE is lost, the local PE interprets that 662 to mean loss of the remote PE node. This assumes that resiliency 663 mechanisms are in place to protect the route to the remote PE 664 nodes, and hence loss of IP reachability to a given node can only 665 mean that the node itself has failed. 667 It is worth noting here that loss of the LDP session with a PE in an 668 RG is not a reliable indicator that the remote PE itself is down. It 669 is possible, for e.g. that the remote PE encounters a local event 670 that leads to resetting the LDP session, while the PE node remains 671 operational for purpose of traffic forwarding. 673 6. ICCP Message Formats 675 This section defines the messages exchanged at the Application and 676 ICC layers. 678 6.1. Encoding ICC into LDP Messages 680 ICCP requires reliable, in-order, state-full message delivery, as 681 well as capability negotiation between PEs. The LDP protocol offers 682 all these features, and is already in wide use in the applications 683 that would also require the ICCP protocol extensions. For these 684 reasons, ICCP takes advantage of the already defined LDP protocol 685 infrastructure. 687 [RFC5036] Section 3.5 defines a generic LDP message structure. A new 688 set of LDP message types is defined to communicate the ICCP 689 information. LDP message types in the range of 0x700 to 0x7ff will be 690 used for ICCP. 692 Message types are allocated by IANA, and requested in the IANA 693 section below. 695 6.1.1. ICC Header 697 Every ICCP message comprises of an ICC specific LDP Header followed 698 by message data. The format of the ICC Header is as follows: 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 |U| Message Type | Message Length | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Message ID | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Type=0x0005 (ICC RG ID) | Length=4 | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | ICC RG ID | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | | 712 + + 713 | Mandatory Parameters | 714 ~ ~ 715 + + 716 | | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | | 719 + + 720 | Optional Parameters | 721 ~ ~ 722 + + 723 | | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 - U-bit 728 Unknown message bit. Upon receipt of an unknown message, if U is 729 clear (=0), a notification is returned to the message originator; 730 if U is set (=1), the unknown message is silently ignored. The 731 following sections which define messages specify a value for the 732 U-bit. 734 - Message Type 736 Identifies the type of the ICCP message, must be in the range of 737 0x0700 to 0x07ff. 739 - Message Length 741 Two octet integer specifying the total length of this message in 742 octets, excluding the U-bit, Message Type and Length fields. 744 - Message ID 746 Four octet value used to identify this message. Used by the 747 sending PE to facilitate identifying RG Notification messages 748 that may apply to this message. A PE sending an RG Notification 749 message in response to this message SHOULD include this Message 750 ID in the "NAK TLV" of the RG Notification message; see Section 751 "RG Notification Message". 753 - ICC RG ID TLV 755 A TLV of type 0x0005, length 4, containing 4 octets unsigned 756 integer designating the Redundancy Group which the sending device 757 is member of. RG ID value 0x00000000 is reserved by the protocol. 759 - Mandatory Parameters 761 Variable length set of required message parameters. Some 762 messages have no required parameters. 764 For messages that have required parameters, the required 765 parameters MUST appear in the order specified by the individual 766 message specifications in the sections that follow. 768 - Optional Parameters 770 Variable length set of optional message parameters. Many 771 messages have no optional parameters. 773 For messages that have optional parameters, the optional 774 parameters may appear in any order. 776 6.1.2. Message Encoding 778 The generic format of an ICC parameter is: 780 0 1 2 3 781 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 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 |U|F| Type | Length | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | TLV(s) | 786 ~ ~ 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 - U-bit 790 Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear 791 (=0), a notification MUST be returned to the message originator 792 and the entire message MUST be ignored; if U is set (=1), the 793 unknown TLV MUST be silently ignored and the rest of the message 794 processed as if the unknown TLV did not exist. The sections 795 following that define TLVs specify a value for the U-bit. 797 - F-bit 799 Forward unknown TLV bit. This bit applies only when the U-bit is 800 set and the LDP message containing the unknown TLV is to be 801 forwarded. If F is clear (=0), the unknown TLV is not forwarded 802 with the containing message; if F is set (=1), the unknown TLV is 803 forwarded with the containing message. The sections following 804 that define TLVs specify a value for the F-bit. By setting both 805 the U- and F-bits, a TLV can be propagated as opaque data through 806 nodes that do not recognize the TLV. 808 - Type 810 Fourteen bits indicating the parameter type. 812 - Length 814 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 815 Length fields. 817 - TLV(s): A set of 0 or more TLVs, that vary according to the 818 message type. 820 6.1.3. ROID Encoding 822 The Redundant Object Identifier (ROID) is a generic opaque handle 823 that uniquely identifies a Redundant Object (e.g. link, bundle, VLAN, 824 etc...) which is being protected in an RG. It is encoded as follows: 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | ROID | 830 + + 831 | | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 where: ROID is an 8 octets field encoded as an unsigned integer. 835 The ROID is carried within application specific TLVs. 837 6.2. RG Connect Message 839 The RG Connect Message is used to establish the ICCP RG connection in 840 addition to individual Application connections between PEs in an RG. 841 An RG Connect message with no "Application-specific connect TLV" 842 signals establishment of the ICCP RG connection. Whereas, an RG 843 Connect message with a valid "Application-specific connect TLV" 844 signals the establishment of an Application connection, in addition 845 to the ICCP RG connection if the latter is not already established. 847 An implementation MAY send a dedicated RG Connect message to set up 848 the ICCP RG connection and a separate RG Connect message per client 849 application. However, all implementations MUST support the receipt of 850 an RG Connect message that triggers the setup of the ICCP RG 851 connection as well as a single Application connection simultaneously. 853 A PE sends an RG Connect Message to declare its membership in a 854 Redundancy Group. One such message should be sent to each PE that is 855 member of the same RG. The set of PEs to which RG Connect Messages 856 should be transmitted is known via configuration or an auto-discovery 857 mechanism that is outside the scope of this specification. If a 858 device is member of multiple RGs, it MUST send separate RG Connect 859 Messages for each RG even if the receiving device(s) happen to be the 860 same. 862 The format of the RG Connect Message is as follows: 864 -i. ICC header with Message type = "RG Connect Message" (0x0700) 865 -ii. ICC Sender Name TLV 866 -iii. Zero or one Application-specific connect TLV 868 The currently defined Application-specific connect TLVs are: 870 - PW Redundancy Connect TLV 872 - mLACP Connect TLV 874 The details of these TLVs are discussed in the "Application TLVs" 875 section. 877 The RG Connect message can contain zero or one Application-specific 878 connect TLV, but no application connect TLV can be sent more than 879 once. 881 6.2.1. ICC Sender Name TLV 883 A TLV that carries the hostname of the sender encoded in UTF-8. This 884 is used primarily for purpose of management of the RG and easing 885 network operations. The specific format is shown below: 887 0 1 2 3 888 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 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 |U|F| Type = 0x0001 | Length | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Sender Name | 893 + +-+-+-+-+-+-+-+-+-+ 894 ~ ~ 895 | ... | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 - U=F=0 900 - Type set to 0x0001 (from ICC parameter name space). 902 - Length 904 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 905 Length fields. 907 - Sender Name 909 Hostname of sending device encoded in UTF-8, and SHOULD NOT 910 exceed 80 characters. 912 6.3. RG Disconnect Message 914 The RG Disconnect Message serves dual-purpose: to signal that a 915 particular Application connection is being closed within an RG, or 916 that the ICCP RG connection itself is being disconnected because the 917 PE wishes to leave the RG. The format of this message is: 919 0 1 2 3 920 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 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 |U| Message Type=0x0701 | Message Length | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Message ID | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Type=0x0005 (ICC RG ID) | Length=4 | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | ICC RG ID | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | Disconnect Code TLV | 931 + + 932 | | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Optional Application-specific Disconnect TLV | 935 ~ ~ 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | Optional Parameter TLVs | 938 + + 939 | | 940 ~ ~ 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 - U-bit 945 U=0 947 - Message Type 949 The message type for RG Disconnect Message is set to (0x0701) 951 - Length 953 Length of the TLV in octets excluding the U-bit, Message Type, 954 and Message Length fields. 956 - Message ID 958 Defined in the "ICC Header" section above. 960 - ICC RG ID 962 Defined in the "ICC Header" section above. 964 - Disconnect Code TLV 966 The format of this TLV is as follows: 968 0 1 2 3 969 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 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 |U|F| Type=0x0004 | Length | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | ICCP Status Code | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 - U,F Bits 978 both U and F are set to 0. 980 - Type 982 set to "Disconnect Code TLV" (0x0004) 984 - Length 986 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 987 Length fields. 989 - ICCP Status Code 991 A status code that reflects the reason for the disconnect 992 message. Allowed values are "ICCP RG Removed" and "ICCP 993 Application Removed from RG". 995 - Optional Application-specific Disconnect TLV 997 Zero or one Application-specific Disconnect TLVs which are 998 defined later in the document. If the RG Disconnect message has 999 a status code of "RG Removed", then it MUST NOT contain any 1000 Application-specific Disconnect TLVs, as the sending PE is 1001 signaling that it has left the RG and, thus, is disconnecting the 1002 ICCP RG connection, with all associated client application 1003 connections. If the message has a status code of "Application 1004 Removed from RG", then it MUST contain exactly one Application- 1005 specific Disconnect TLV, as the sending PE is only tearing down 1006 the connection for the specified application. Other applications, 1007 and the ICCP RG connection are not to be affected. 1009 - Optional Parameter TLVs 1011 None are defined for this message in this document. This is 1012 specified to allow for future extensions. 1014 6.4. RG Notification Message 1016 A PE sends an RG Notification Message to indicate one of the 1017 following: to reject an ICCP connection, to reject an application 1018 connection, to NAK an entire message or to NAK one or more TLV(s) 1019 within a message. The Notification message can only be sent to a PE 1020 that is already part of an RG. 1022 The RG Notification Message MUST NOT be used to NAK messages or TLVs 1023 corresponding to multiple ICCP applications simultaneously. In other 1024 words, there is a limit of at most a single ICCP application per RG 1025 Notification Message. 1027 The format of the RG Notification Message is: 1029 -i. ICC header with Message type = "RG Notification Message" 1030 (0x0702) 1031 -ii. Notification Message TLVs. 1033 The currently defined Notification message TLVs are: 1035 -i. ICC Sender Name TLV 1036 -ii. NAK TLV. 1038 6.4.1. Notification Message TLVs 1040 The ICC Sender Name TLV uses the same format as in the RG Connect 1041 message, and was described above. 1043 The NAK TLV is defined as follows: 1045 0 1 2 3 1046 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 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 |U|F| Type=0x0002 | Length | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | ICCP Status Code | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | Rejected Message ID | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | Optional TLV(s) | 1055 + + 1056 | | 1057 ~ ~ 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 - U,F Bits 1062 both U and F are set to 0. 1064 - Type 1066 set to "NAK TLV" (0x0002) 1068 - Length 1070 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1071 Length fields. 1073 - ICCP Status Code 1075 A status code that reflects the reason for the NAK TLV. Allowed 1076 values are: 1077 -i. Unknown RG (0x00010001) 1079 This code is used to reject a new incoming ICCP 1080 connection for an RG that is not configured on the local 1081 PE. When this code is used, the Rejected Message ID 1082 field MUST contain the message ID of the rejected "RG 1083 Connect" message. 1085 -ii. ICCP Connection Count Exceeded (0x00010002) 1087 This is used to reject a new incoming ICCP connection 1088 that would cause the local PE's ICCP connection count to 1089 exceed its capabilities. When this code is used, the 1090 Rejected Message ID field MUST contain the message ID of 1091 the rejected "RG Connect" message. 1093 -iii. Application Connection Count Exceeded (0x00010003) 1095 This is used to reject a new incoming application 1096 connection that would cause the local PE's ICCP 1097 connection count to exceed its capabilities. When this 1098 code is used, the Rejected Message ID field MUST contain 1099 the message ID of the rejected "RG Connect" message and 1100 the corresponding Application Connect TLV MUST be 1101 included in the "Optional TLV". 1103 -iv. Application not in RG (0x00010004) 1105 This is used to reject a new incoming application 1106 connection when the local PE doesn't support the 1107 application, or the application is not configured in the 1108 RG. When this code is used, the Rejected Message ID 1109 field MUST contain the message ID of the rejected "RG 1110 Connect" message and the corresponding Application 1111 Connect TLV MUST be included in the "Optional TLV". 1113 -v. Incompatible Protocol Version (0x00010005) 1115 This is used to reject a new incoming application 1116 connection when the local PE has an incompatible version 1117 of the application. When this code is used, the Rejected 1118 Message ID field MUST contain the message ID of the 1119 rejected "RG Connect" message and the corresponding 1120 Application Connect TLV MUST be included in the 1121 "Optional TLV". 1123 -vi. Rejected Message (0x00010006) 1125 This is used to reject an RG Application Data message, 1126 or one or more TLV(s) within the message. When this 1127 code is used, the Rejected Message ID field MUST contain 1128 the message ID of the rejected "RG Application Data" 1129 message. 1131 -vii. ICCP Administratively Disabled (0x00010007) 1133 This is used to reject any ICCP messages from a peer 1134 from which the PE is not allowed to exchange ICCP 1135 messages due to local administrative policy. 1137 - Rejected Message ID 1139 If non-zero, four octets value that identifies the peer message 1140 to which the NAK TLV refers. If zero, no specific peer message is 1141 being identified. 1143 - Optional TLV(s) 1145 A set of one or more optional TLVs. If the status code is 1146 "Rejected Message" then this field contains the TLV(s) that were 1147 rejected. If the entire message is rejected, all its TLVs MUST be 1148 present in this field; otherwise, the subset of TLVs that were 1149 rejected MUST be echoed in this field. 1151 If the status code is "Incompatible Protocol Version" then this 1152 field contains the original "Application Connect TLV" sent by the 1153 peer, in addition to the "Requested Protocol Version TLV" defined 1154 below: 1156 0 1 2 3 1157 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 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 |U|F| Type=0x0003 | Length | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 | Connection Reference | Requested Version | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 - U and F Bits 1166 Both are set to 0. 1168 - Type 1170 set to 0x0003 for "Requested Protocol Version TLV" 1172 - Length 1174 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1175 Length fields. 1177 - Connection Reference 1179 This field is set to the Type field of the Application specific 1180 Connect TLV that was rejected because of incompatible version. 1182 - Requested Version 1184 The version of the application supported by the transmitting 1185 device. For this version of the protocol it is set to 0x0001. 1187 6.5. RG Application Data Message 1189 The RG Application Data Message is used to transport application data 1190 between PEs within an RG. A single message can be used to carry data 1191 from only one application. Multiple application TLVs are allowed in a 1192 single message, as long as all of these TLVs belong to the same 1193 application. The format of the Application Data Message is: 1195 -i. ICC header with Message type = "RG Application Data Message" 1196 (0x703) 1197 -ii. "Application specific TLVs" 1199 The details of these TLVs are discussed in the "Application TLVs" 1200 section. All application specific TLVs in one RG Application Data 1201 Message MUST belong to a single application but MAY reference 1202 different ROs. 1204 7. Application TLVs 1206 7.1. Pseudowire Redundancy (PW-RED) Application TLVs 1208 This section discusses the ICCP TLVs for the Pseudowire Redundancy 1209 application. 1211 7.1.1. PW-RED Connect TLV 1213 This TLV is included in the RG Connect message to signal the 1214 establishment of PW-RED application connection. 1216 0 1 2 3 1217 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 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 |U|F| Type=0x0010 | Length | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | Protocol Version | Optional Sub-TLVs | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1223 ~ ~ 1224 | | 1225 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | ... | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 - U and F Bits 1230 Both are set to 0. 1232 - Type 1234 set to 0x0010 for "PW-RED Connect TLV" 1236 - Length 1238 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1239 Length fields. 1241 - Protocol Version 1243 The version of this particular protocol for the purposes of ICCP. 1244 This is set to 0x0001. 1246 - Optional Sub-TLVs 1248 There are no optional Sub-TLVs defined for this version of the 1249 protocol. 1251 7.1.2. PW-RED Disconnect TLV 1253 This TLV is used in an RG Disconnect Message to indicate that the 1254 connection for the PW-RED application is to be terminated. 1256 0 1 2 3 1257 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 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 |U|F| Type=0x0011 | Length | 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Optional Sub-TLVs | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 - U and F Bits 1266 Both are set to 0. 1268 - Type 1270 set to 0x0011 for "PW-RED Disconnect TLV" 1272 - Length 1274 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1275 Length fields. 1277 - Optional Sub-TLVs 1279 There are no optional Sub-TLVs defined for this version of the 1280 protocol. 1282 7.1.3. PW-RED Config TLV 1284 The PW-RED Config TLV is used in the RG Application Data message and 1285 is composed of the following TLVs in the following order: 1286 -i. Service Name TLV 1287 -ii. PW ID TLV or Generalized PW ID TLV 1289 In the PW-RED Config TLV the U and F Bits are both are set to 0, and 1290 the TLV type is set to 0x0012. 1292 7.1.4. Service Name TLV 1294 0 1 2 3 1295 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 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 |U|F| Type | Length | 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 | Service Name | 1300 ~ ~ 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 - U and F Bits 1305 Both are set to 0. 1307 - Type 1309 set to 0x0013 for "Service Name TLV" 1311 - Length 1313 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1314 Length fields. 1316 - Service Name 1318 The name of the L2VPN service instance encoded in UTF-8 format 1319 and up to 80 character in length. 1321 7.1.5. PW ID TLV 1323 This TLV is used to communicate the configuration of PWs for VPWS. 1325 0 1 2 3 1326 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 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 |U|F| Type | Length | 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 | Peer ID | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | Group ID | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | PW ID | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 - U and F Bits 1339 Both are set to 0. 1341 - Type 1343 set to 0x0014 for "PW ID TLV" 1345 - Length 1347 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1348 Length fields. 1350 - Peer ID 1352 Four octet LDP Router ID of the peer at the far end of the PW. 1354 - Group ID 1356 Same as Group ID in [RFC4447] section 5.2. 1358 - PW ID 1360 Same as PW ID in [RFC4447] section 5.2. 1362 7.1.6. Generalized PW ID TLV 1364 This TLV is used to communicate the configuration of PWs for VPLS. 1366 0 1 2 3 1367 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 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 |U|F| Type = 0x0015 | Length | 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | AGI Type | Length | Value | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 ~ AGI Value (contd.) ~ 1374 | | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 | AII Type | Length | Value | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 ~ SAII Value (contd.) ~ 1379 | | 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 | AII Type | Length | Value | 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 ~ TAII Value (contd.) ~ 1384 | | 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 - U and F bits 1389 both set to 0. 1391 - Type 1393 set to 0x0015 1395 - Length 1397 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1398 Length fields. 1400 - AGI, AII, SAII and TAII 1402 defined in [RFC4447] section 5.3.2. 1404 7.2. Multi-chassis LACP (mLACP) Application TLVs 1406 This section discusses the ICCP TLVs for Ethernet attachment circuit 1407 redundancy using the multi-chassis LACP (mLACP) application. 1409 7.2.1. mLACP Connect TLV 1411 This TLV is included in the RG Connect message to signal the 1412 establishment of mLACP application connection. 1414 0 1 2 3 1415 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 |U|F| Type=0x0030 | Length | 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 | Protocol Version | Optional Sub-TLVs | 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1421 ~ ~ 1422 | | 1423 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 | ... | 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 - U and F Bits 1429 Both are set to 0. 1431 - Type 1433 set to 0x0030 for "mLACP 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 - Optional Sub-TLVs 1447 There are no optional Sub-TLVs defined for this version of the 1448 protocol. 1450 7.2.2. mLACP Disconnect TLV 1452 This TLV is used in an RG Disconnect Message to indicate that the 1453 connection for the mLACP application is to be terminated. 1455 0 1 2 3 1456 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 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 |U|F| Type=0x0031 | Length | 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | Optional Sub-TLVs | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 - U and F Bits 1465 Both are set to 0. 1467 - Type 1469 set to 0x0031 for "mLACP Disconnect TLV" 1471 - Length 1473 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1474 Length fields. 1476 - Optional Sub-TLVs 1478 There are no optional Sub-TLVs defined for this version of the 1479 protocol. 1481 7.2.3. mLACP System Config TLV 1483 The mLACP System Config TLV is sent in the RG Application Data 1484 message. This TLV announces the local node's LACP System Parameters 1485 to the RG peers. 1487 0 1 2 3 1488 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 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 |U|F| Type=0x0032 | Length | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | System ID | 1493 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | | System Priority | 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 | Node ID | 1497 +-+-+-+-+-+-+-+-+ 1499 - U and F Bits 1501 Both are set to 0. 1503 - Type 1505 set to 0x0032 for "mLACP System Config TLV" 1507 - Length 1509 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1510 Length fields. 1512 - System ID 1514 6 octets field encoding the System ID used by LACP as specified 1515 in [IEEE-802.3] section 43.3.2. 1517 - System Priority 1519 2 octets encoding the LACP System Priority as defined in [IEEE- 1520 802.3] section 43.3.2. 1522 - Node ID 1524 One octet, LACP node ID. Used to ensure that the LACP Port 1525 Numbers are unique across all devices in an RG. Valid values are 1526 in the range 0 - 7. Uniqueness of the LACP Port Numbers across RG 1527 members is ensured by encoding the Port Numbers as follows: 1528 - Most significant bit always set to 1 1529 - The next 3 most significant bits set to Node ID 1530 - Remaining 12 bits freely assigned by the system 1532 7.2.4. mLACP Aggregator Config TLV 1534 The mLACP Aggregator Config TLV is sent in the RG Application Data 1535 message. This TLV is used to notify RG peers about the local 1536 configuration state of an aggregator. 1538 0 1 2 3 1539 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 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 |U|F| Type=0x0036 | Length | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 | ROID | 1544 + + 1545 | | 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 | Aggregator ID | MAC Address | 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1549 | | 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 | Actor Key | Member Ports Priority | 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 | Flags | Agg Name Len | Aggregator Name | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1555 ~ ~ 1556 | ... | 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 - U and F Bits 1561 Both are set to 0. 1563 - Type 1565 set to 0x0036 for "mLACP Aggregator Config TLV" 1567 - Length 1569 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1570 Length fields. 1572 - ROID 1574 Defined in the 'ROID Encoding' section above. 1576 - Aggregator ID 1578 Two octets, LACP Aggregator Identifier as specified in [IEEE- 1579 802.3] section 43.4.6 1581 - MAC Address 1583 Six octets encoding the Aggregator MAC address. 1585 - Actor Key 1587 Two octets, LACP Actor Key for the corresponding Aggregator, as 1588 specified in [IEEE-802.3] section 43.3.5. 1590 - Member Ports Priority 1592 Two octets, LACP administrative port priority associated with all 1593 interfaces bound to the Aggregator. This field is valid only when 1594 the "Flags" field has "Priority Set" asserted. 1596 - Flags 1598 Valid values are: 1600 -i. Synchronized (0x01) 1602 Indicates that the sender has concluded transmitting all 1603 Aggregator configuration information. 1605 -ii. Purge Configuration (0x02) 1607 Indicates that the Aggregator is no longer configured 1608 for mLACP operation. 1610 -iii. Priority Set (0x04) 1612 Indicates that the "Member Ports Priority" field is 1613 valid. 1615 - Agg Name Len 1617 One octet, length of the "Aggregator Name" field in octets. 1619 - Aggregator Name 1621 Aggregator name encoded in UTF-8 format, up to a maximum of 20 1622 characters. Used for ease of management. 1624 7.2.5. mLACP Port Config TLV 1626 The mLACP Port Config TLV is sent in the RG Application Data message. 1627 This TLV is used to notify RG peers about the local configuration 1628 state of a port. 1630 0 1 2 3 1631 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 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 |U|F| Type=0x0033 | Length | 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | Port Number | MAC Address | 1636 +-------------------------------+ + 1637 | | 1638 +---------------------------------------------------------------+ 1639 | Actor Key | Port Priority | 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 | Port Speed | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 | Flags | Port Name Len | Port Name | 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1645 ~ ~ 1646 | ... | 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 - U and F Bits 1651 Both are set to 0. 1653 - Type 1655 set to 0x0033 for "mLACP Port Config TLV" 1657 - Length 1659 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1660 Length fields. 1662 - Port Number 1664 Two octets, LACP Port Number for the corresponding interface as 1665 specified in [IEEE-802.3] section 43.3.4. The Port Number MUST be 1666 encoded with the Node ID as was discussed above. 1668 - MAC Address 1670 Six octets encoding the port MAC address. 1672 - Actor Key 1674 Two octets, LACP Actor Key for the corresponding interface, as 1675 specified in [IEEE-802.3] section 43.3.5. 1677 - Port Priority 1679 Two octets, LACP administrative port priority for the 1680 corresponding interface, as specified in [IEEE-802.3] section 1681 43.3.4. This field is valid only when the "Flags" field has 1682 "Priority Set" asserted. 1684 - Port Speed 1686 Four octets integer encoding the port's current bandwidth in 1687 units of 1,000,000 bits per second. This field corresponds to the 1688 ifHighSpeed object of IF-MIB [RFC2863]. 1690 - Flags 1692 Valid values are: 1694 -i. Synchronized (0x01) 1696 Indicates that the sender has concluded transmitting all 1697 member link port configurations for a given Aggregator. 1699 -ii. Purge Configuration (0x02) 1701 Indicates that the port is no longer configured for 1702 mLACP operation. 1704 -iii. Priority Set (0x04) 1706 Indicates that the "Port Priority" field is valid. 1708 - Port Name Len 1710 One octet, length of the "Port Name" field in octets. 1712 - Port Name 1714 Port (interface) name encoded in UTF-8 format, up to a maximum of 1715 20 characters. 1717 7.2.6. mLACP Port Priority TLV 1719 The mLACP Port Priority TLV is sent in the RG Application Data 1720 message. This TLV is used by a device to either advertise its 1721 operational Port Priority to other members in the RG, or to 1722 authoritatively request that a particular member of an RG change its 1723 port priority. 1725 0 1 2 3 1726 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 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 |U|F| Type=0x0034 | Length | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 | OpCode | Port Number | 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 | Aggregator ID | Last Port Priority | 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 | Current Port Priority | 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 - U and F Bits 1739 Both are set to 0. 1741 - Type 1743 set to 0x0034 for "mLACP Port Priority TLV" 1745 - Length 1747 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1748 Length fields. 1750 - OpCode 1752 Two octets identifying the operational code-point for the TLV, 1753 encoded as follows: 1755 0x00 Local Priority Change Notification 1756 0x01 Remote Request for Priority Change 1758 - Port Number 1760 2 octets field representing the LACP Port Number as specified in 1761 [IEEE-802.3] section 43.3.4. When the value of this field is 0, 1762 it denotes all ports bound to the Aggregator specified in the 1763 "Aggregator ID" field. When non-zero, the Port Number MUST be 1764 encoded with the Node ID as was discussed above. 1766 - Aggregator ID 1768 Two octets, LACP Aggregator Identifier as specified in [IEEE- 1769 802.3] section 43.4.6 1771 - Last Port Priority 1773 Two octets, LACP port priority for the corresponding interface, 1774 as specified in [IEEE-802.3] section 43.3.4. For local ports, 1775 this field encodes the previous operational value of port 1776 priority. For remote ports, this field encodes the operational 1777 port priority last known to the PE via notifications received 1778 from its peers in the RG. 1780 - Current Port Priority 1782 Two octets, LACP port priority for the corresponding interface, 1783 as specified in [IEEE-802.3] section 43.3.4. For local ports, 1784 this field encodes the new operational value of port priority 1785 being advertised by the PE. For remote ports, this field 1786 specifies the new port priority being requested by the PE. 1788 7.2.7. mLACP Port State TLV 1790 The mLACP Port State TLV is used in the RG Application Data message. 1791 This TLV is used by a device to report its LACP port status to other 1792 members in the RG. 1794 0 1 2 3 1795 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 1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1797 |U|F| Type=0x0035 | Length | 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 | Partner System ID | 1800 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 | | Partner System Priority | 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 | Partner Port Number | Partner Port Priority | 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1805 | Partner Key | Partner State | Actor State | 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 | Actor Port Number | Actor Key | 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 | Selected | Port State | Aggregator ID | 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 - U and F Bits 1814 Both are set to 0. 1816 - Type 1818 set to 0x0035 for "mLACP Port State TLV" 1820 - Length 1822 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1823 Length fields. 1825 - Partner System ID 1827 6 octets, the LACP Partner System ID for the corresponding 1828 interface, encoded as a MAC address as specified in [IEEE-802.3] 1829 section 43.4.2.2 item r. 1831 - Partner System Priority 1833 2 octets field specifying the LACP Partner System Priority as 1834 specified in [IEEE-802.3] section 43.4.2.2 item q. 1836 - Partner Port Number 1838 2 octets encoding the LACP Partner Port Number as specified in 1839 [IEEE-802.3] section 43.4.2.2 item u. The Port Number MUST be 1840 encoded with the Node ID as was discussed above. 1842 - Partner Port Priority 1844 2 octets field encoding the LACP Partner Port Priority as 1845 specified in [IEEE-802.3] section 43.4.2.2 item t. 1847 - Partner Key 1849 2 octets field representing the LACP Partner Key as defined in 1850 [IEEE-802.3] section 43.4.2.2 item s. 1852 - Partner State 1854 1 octet field encoding the LACP Partner State Variable as defined 1855 in [IEEE-802.3] section 43.4.2.2 item v. 1857 - Actor State 1859 1 octet encoding the LACP Actor's State Variable for the port as 1860 specified in [IEEE-802.3] section 43.4.2.2 item m. 1862 - Actor Port Number 1864 2 octets field representing the LACP Actor Port Number as 1865 specified in [IEEE-802.3] section 43.3.4. The Port Number MUST be 1866 encoded with the Node ID as was discussed above. 1868 - Actor Key 1870 2 octet field encoding the LACP Actor Operational Key as 1871 specified in [IEEE-802.3] section 43.3.5. 1873 - Selected 1875 1 octet encoding the LACP 'Selected' variable, defined in [IEEE- 1876 802.3] section 43.4.8, as follows: 1878 0x00 SELECTED 1879 0x01 UNSELECTED 1880 0x02 STANDBY 1882 - Port State 1884 1 octet encoding the operational state of the port as follows: 1885 0x00 Up 1886 0x01 Down 1887 0x02 Administrative Down 1888 0x03 Test (e.g. IEEE 802.3ah OAM Intrusive Loopback mode) 1890 - Aggregator ID 1892 Two octets, LACP Aggregator Identifier to which this port is 1893 bound based on the outcome of the LACP selection logic. 1895 7.2.8. mLACP Aggregator State TLV 1897 The mLACP Aggregator State TLV is used in the RG Application Data 1898 message. This TLV is used by a device to report its Aggregator status 1899 to other members in the RG. 1901 0 1 2 3 1902 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 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1904 |U|F| Type=0x0037 | Length | 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 | Partner System ID | 1907 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1908 | | Partner System Priority | 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 | Partner Key | Aggregator ID | 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1912 | Actor Key | Agg State | 1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 - U and F Bits 1917 Both are set to 0. 1919 - Type 1921 set to 0x0037 for "mLACP Aggregator State TLV" 1923 - Length 1925 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1926 Length fields. 1928 - Partner System ID 1930 6 octets, the LACP Partner System ID for the corresponding 1931 interface, encoded as a MAC address as specified in [IEEE-802.3] 1932 section 43.4.2.2 item r. 1934 - Partner System Priority 1936 2 octets field specifying the LACP Partner System Priority as 1937 specified in [IEEE-802.3] section 43.4.2.2 item q. 1939 - Partner Key 1941 2 octets field representing the LACP Partner Key as defined in 1942 [IEEE-802.3] section 43.4.2.2 item s. 1944 - Aggregator ID 1946 Two octets, LACP Aggregator Identifier as specified in [IEEE- 1947 802.3] section 43.4.6 1949 - Actor Key 1951 2 octet field encoding the LACP Actor Operational Key as 1952 specified in [IEEE-802.3] section 43.3.5. 1954 - Agg State 1956 1 octet encoding the operational state of the Aggregator as 1957 follows: 1958 0x00 Up 1959 0x01 Down 1960 0x02 Administrative Down 1961 0x03 Test (e.g. IEEE 802.3ah OAM Intrusive Loopback mode) 1963 7.2.9. mLACP Synchronization Request TLV 1965 The mLACP Synchronization Request TLV is used in the RG Application 1966 Data message. This TLV is used by a device to request from its peer 1967 to re-transmit configuration or operational state. The following 1968 information can be requested: 1970 - system configuration and/or state 1972 - configuration and/or state for a specific port 1974 - configuration and/or state for all ports with a specific LACP key 1976 - configuration and/or state for all mLACP ports 1977 - configuration and/or state for a specific aggregator 1979 - configuration and/or state for all aggregators with a specific 1980 LACP key 1982 - configuration and/or state for all mLACP aggregators 1984 The format of the TLV is as follows: 1986 0 1 2 3 1987 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 1988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1989 |U|F| Type=0x0038 | Length | 1990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1991 | Request Number |C|S| Request Type | 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 | Port Number / Aggregator ID | Actor Key | 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1996 - U and F Bits 1998 Both are set to 0. 2000 - Type 2002 set to 0x0038 for "mLACP Synchronization Request TLV" 2004 - Length 2006 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2007 Length fields. 2009 - Request Number 2011 2 octets. Unsigned integer uniquely identifying the request. Used 2012 to match the request with a response. The value of 0 is reserved 2013 for unsolicited synchronization, and MUST NOT be used in the 2014 mLACP Synchronization Request TLV. 2016 - C Bit 2018 Set to 1 if request is for configuration data. Otherwise, set to 2019 0. 2021 - S Bit 2023 Set to 1 if request is for running state data. Otherwise, set to 2024 0. 2026 - Request Type 2028 14-bits specifying the request type, encoded as follows: 2030 0x00 Request System Data 2031 0x01 Request Aggregator Data 2032 0x02 Request Port Data 2034 - Port Number / Aggregator ID 2036 2 octets. When Request Type field is set to 'Request Port Data', 2037 this field encodes the LACP Port Number for the requested port. 2038 When the Request Type field is set to 'Request Aggregator Data', 2039 this field encodes the Aggregator ID of the requested Aggregator. 2040 When the value of this field is 0, it denotes that all ports (or 2041 Aggregators), whose LACP Key is specified in the "Actor Key" 2042 field, are being requested. 2044 - Actor Key 2046 Two octets, LACP Actor key for the corresponding port or 2047 Aggregator. When the value of this field is 0 (and the Port 2048 Number/Aggregator ID field is 0 as well), it denotes that 2049 information for all ports or Aggregators in the system is being 2050 requested. 2052 7.2.10. mLACP Synchronization Data TLV 2054 The mLACP Synchronization Data TLV is used in the RG Application Data 2055 message. A pair of these TLVs is used by a device to delimit a set of 2056 TLVs that are being transmitted in response to an mLACP 2057 Synchronization Request TLV. The delimiting TLVs signal the start and 2058 end of the synchronization data, and associate the response with its 2059 corresponding request via the 'Request Number' field. 2061 The mLACP Synchronization Data TLVs are also used for unsolicited 2062 advertisements of complete mLACP configuration and operational state 2063 data. The 'Request Number' field MUST be set to 0 in this case. For 2064 such unsolicited synchronization, the PE MUST advertise all system, 2065 Aggregator and port information as done during the initialization 2066 sequence. 2068 This TLV has the following format: 2070 0 1 2 3 2071 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 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 |U|F| Type=0x0039 | Length | 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 | Request Number | Flags | 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2078 - U and F Bits 2080 Both are set to 0. 2082 - Type 2084 set to 0x0039 for "mLACP Synchronization Data TLV" 2086 - Length 2088 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2089 Length fields. 2091 - Request Number 2093 2 octets. Unsigned integer identifying the Request Number from 2094 the "mLACP Synchronization Request TLV" which solicited this 2095 synchronization data response. 2097 - Flags 2099 2 octets, response flags encoded as follows: 2101 0x00 Synchronization Data Start 2102 0x01 Synchronization Data End 2104 8. LDP Capability Negotiation 2106 As requited in [RFC5561] the following TLV is defined to indicate the 2107 ICCP capability: 2109 0 1 2 3 2110 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 2111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2112 |U|F| TLV Code Point=0x405 | Length | 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 |S| Reserved | Reserved | VER/Maj | Ver/Min | 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2117 where: 2119 - U-bit 2121 SHOULD be 1 (ignore if not understood). 2123 - F-bit 2125 SHOULD be 0 (don't forward if not understood). 2127 - TLV Code Point 2129 The TLV type, which identifies a specific capability. The ICCP 2130 code point is requested in the IANA allocation section below. 2132 - S-bit The State Bit indicates whether the sender is advertising 2133 or withdrawing the ICCP capability. The State bit is used as 2134 follows: 2135 1 - The TLV is advertising the capability specified by the 2136 TLV Code Point. 2138 0 - The TLV is withdrawing the capability specified by the 2139 TLV Code Point. 2141 - Ver/Maj 2143 The major version revision of the ICCP protocol, this document 2144 specifies 1.0. This field is then set to 1 2146 - Ver/Min 2148 The minor version revision of the ICCP protocol, this document 2149 specifies 1.0. This field is then set to 0 2151 ICCP capability is advertised to a LDP peer if there is at least one 2152 RG enabled on the local PE. 2154 9. Client Applications 2156 9.1. Pseudowire Redundancy Application Procedures 2158 This section defines the procedures for the Pseudowire Redundancy 2159 (PW-RED) Application. 2161 9.1.1. Initial Setup 2163 When an RG is configured on a system and multi-chassis pseudowire 2164 redundancy is enabled in that RG, the PW-RED application should send 2165 an "RG Connect" message with "PW-RED Connect TLV" to each PE that is 2166 a member of the same RG. When the system receives a similar "RG 2167 Connect" messages from a PE, the two devices can start exchanging "RG 2168 Application Data" messages for the PW-RED application. 2170 If a system receives an "RG Connect" message with "PW-RED Connect 2171 TLV" that has a differing Protocol Version, it must follow the 2172 procedures outlined in the "Application Versioning" section above. 2174 When the PW-RED application is disabled on the device, or is 2175 unconfigured for the RG in question, the system should send an "RG 2176 Disconnect" message with "PW-RED Disconnect TLV". 2178 9.1.2. Pseudowire Configuration 2180 A system should advertise its local PW configuration to other PEs 2181 that are members of the same RG. This allows the PEs to build a view 2182 of the redundant nodes and pseudowires that are protecting the same 2183 service instances. The advertisement should be initiated when the 2184 PW-RED application connection first comes up, as well as upon any 2185 subsequent PW configuration change. To that end, the system should 2186 send "RG Application Data" messages with "PW-RED Config TLV". It is 2187 possible to send configuration information for multiple PWs in a 2188 single "RG Application Data" message. 2190 The "Service Name TLV" is used on the receiving system for the 2191 purpose of associating PW information advertised by some PE with the 2192 corresponding AC information received over ICCP from that PE's AC 2193 redundancy application. The Service Name has a global context in an 2194 RG, so redundant PWs for the same service on disparate member PEs 2195 should share the same Service Name, in order to be correlated. 2197 9.1.3. Pseudowire Status Synchronization 2199 On a given PE, the forwarding status of the PW (Active or Standby) is 2200 derived from the state of the associated AC(s). This simplifies the 2201 operation of the multi-chassis redundancy solution (Figure 1) and 2202 eliminates the possibility of deadlock conditions between the AC and 2203 PW redundancy mechanisms. The rules by which the PW state is derived 2204 from the AC state are as follows: 2206 - VPWS 2208 For VPWS, there's a single AC per service instance. If the AC is 2209 Active, then the PW status should be Active. If the AC is 2210 Standby, then the PW status should be Standby. 2212 - VPLS 2214 For VPLS, there could be multiple ACs per service instance (i.e. 2215 VFI). If AT LEAST ONE AC is Active, then the PW status should be 2216 Active. If ALL ACs are Standby, then the PW status should be 2217 Standby. 2219 The PW-RED application does not synchronize PW status across chassis, 2220 per se. Rather, the AC Redundancy application should synchronize AC 2221 status between chassis, in order to determine which AC (and 2222 subsequently which PE) is Active or Standby for a given service. When 2223 that is determined, each PE will then adjust its local PWs state 2224 according to the rules described above. 2226 9.1.4. PE Node Failure 2228 When a PE node detects that a remote PE, that is member of the same 2229 RG, has gone down, the local PE examines if it has redundant PWs for 2230 the affected services. If the local PE has the highest priority 2231 (after the failed PE) then it becomes the active node for the 2232 services in question, and subsequently activates its associated PWs. 2234 9.2. Attachment Circuit Redundancy Application Procedures 2236 9.2.1. Common AC Procedures 2238 This section describes generic procedures for AC Redundancy 2239 applications, independent of the type of the AC (ATM, FR or 2240 Ethernet). 2242 9.2.2. AC Failure 2244 When the AC Redundancy mechanism on the Active PE detects a failure 2245 of the AC, it should send an ICCP Application Data message to inform 2246 the redundant PEs of the need to take over. The AC failures can be 2247 categorized into the following scenarios: 2249 - Failure of CE interface connecting to PE 2251 - Failure of CE uplink to PE 2253 - Failure of PE interface connecting to CE 2255 9.2.3. PE Node Failure 2257 When a PE node detects that a remote PE, that is member of the same 2258 RG, has gone down, the local PE examines if it has redundant ACs for 2259 the affected services. If the local PE has the highest priority 2260 (after the failed PE) then it becomes the active node for the 2261 services in question, and subsequently activates its associated ACs. 2263 9.2.4. PE Isolation 2265 When a PE node detects that is has been isolated from the core 2266 network (i.e. all core facing interfaces/links are not operational), 2267 then it should instruct its AC Redundancy mechanism to change the 2268 status of any active ACs to Standby. The AC Redundancy application 2269 should then send ICCP Application Data messages in order to trigger 2270 failover to a standby PE. 2272 9.2.5. ATM AC Procedures 2274 9.2.6. Frame Relay AC Procedures 2276 9.2.7. Ethernet AC Procedures 2278 9.2.8. Multi-chassis LACP (mLACP) Application Procedures 2280 This section defines the procedures that are specific to the multi- 2281 chassis LACP (mLACP) application. 2283 9.2.8.1. Initial Setup 2285 When an RG is configured on a system and mLACP is enabled in that RG, 2286 the mLACP application MUST send an "RG Connect" message with "mLACP 2287 Connect TLV" to each PE that is member of the same RG. When the 2288 system receives similar "RG Connect" message from a PE, the two 2289 devices can start exchanging "RG Application Data" messages for the 2290 mLACP application. This involves having each PE advertise its mLACP 2291 configuration and operational state in an unsolicited manner. A PE 2292 SHOULD subscribe to the following order when advertising its mLACP 2293 state upon initial application connection setup: 2295 - Advertise system configuration 2296 - Advertise Aggregator configuration 2297 - Advertise port configuration 2298 - Advertise Aggregator state 2299 - Advertise port state 2301 A PE MUST use a pair of "mLACP Synchronization Data TLVs" to delimit 2302 the entire set of TLVs that are being sent as part of this 2303 unsolicited advertisement. 2305 If a system receives an "RG Connect" message with "mLACP Connect TLV" 2306 that has a differing Protocol Version, it MUST follow the procedures 2307 outlined in the "Application Versioning" section above. 2309 After the mLACP application connection has been established, every PE 2310 MUST communicate its system level configuration to its peers via the 2311 use of "mLACP System Config TLV". This allows every PE to discover 2312 the Node ID and the locally configured System ID and System Priority 2313 values of its peers. 2315 If a PE receives an "mLACP System Config TLV" from a remote peer 2316 advertising the same Node ID value as the local system, then the PE 2317 MUST respond with an "RG Notification Message" to NAK the "mLACP 2318 System Config TLV" and disconnect the mLACP Application connection. 2319 It SHOULD also raise an alarm to alert the operator. Furthermore, if 2320 a PE receives a NAK for an "mLACP System Config TLV" that it has 2321 advertised, the PE MUST respond to this NAK by disconnecting the 2322 mLACP Application connection and SHOULD raise an alarm to alert the 2323 network operator of potential device mis-configuration. 2325 If a PE receives an "mLACP System Config TLV" from a new peer 2326 advertising the same Node ID value as another existing peer with 2327 which the local system has an established mLACP Application 2328 connection, then the PE MUST respond to the new peer with an "RG 2329 Notification Message" to NAK the "mLACP System Config TLV" and MUST 2330 disconnect the mLACP Application connection with the new peer. 2332 If the Node ID of a particular PE changes due to administrative 2333 configuration action, the PE MUST then replay the initialization 2334 sequence by sending an unsolicited synchronization of: the system 2335 configuration, Aggregator configuration, port configuration, 2336 Aggregator state and port state. 2338 It is necessary for all PEs in an RG to agree upon the System ID and 2339 System Priority values to be used ubiquitously. To achieve this, 2340 every PE MUST use the values for the two parameters that are supplied 2341 by the PE with the numerically lowest value (among RG members) of 2342 System Aggregation Priority. This guarantees that the PEs always 2343 agree on uniform values, which yield the highest System Priority. 2345 When the mLACP application is disabled on the device, or is 2346 unconfigured for the RG in question, the system MUST send an "RG 2347 Disconnect" message with "mLACP Disconnect TLV". 2349 9.2.8.2. mLACP Aggregator and Port Configuration 2351 A system MUST synchronize the configuration of its mLACP enabled 2352 Aggregators and ports with other RG members. This is achieved via the 2353 use of "mLACP Aggregator Config TLVs" and "mLACP Port Config TLVs", 2354 respectively. An implementation MUST advertise the configuration of 2355 Aggregators prior to advertising the configuration of any of their 2356 associated member ports. 2358 The PEs in an RG MUST all agree on the MAC address to be associated 2359 with a given Aggregator. It is possible to achieve this via 2360 consistent configuration on member PEs. However, in order to protect 2361 against possible misconfiguration, a system MUST use, for any given 2362 Aggregator, the MAC address supplied by the PE with the numerically 2363 lowest System Aggregation Priority in the RG. 2365 A system that receives an "mLACP Aggregator Config TLV" with an ROID 2366 to Key association that is different from its local association MUST 2367 NAK the corresponding TLV and disable the Aggregator with the same 2368 ROID. Furthermore, it SHOULD raise an alarm to alert the operator. 2369 Similarly, a system that receives a NAK in response to a transmitted 2370 "mLACP Aggregator Config TLV" MUST disable the associated Aggregator 2371 and SHOULD raise an alarm to alert the network operator. 2373 A system MAY enforce a restriction that all ports that are to be 2374 bundled together on a given PE share the same Port Priority value. If 2375 so, the system MUST advertise this common priority in the "mLACP 2376 Aggregator Config TLV" and assert the "Priority Set" flag in such 2377 TLV. Furthermore, the system in this case MUST NOT advertise 2378 individual Port Priority values in the associated "mLACP Port Config 2379 TLVs" (i.e. the "Priority Set" flag in these TLVs should be 0). 2381 A system MAY support individual Port Priority values to be configured 2382 on ports that are to be bundled together on a PE. If so, the system 2383 MUST advertise the individual Port Priority values in the appropriate 2384 "mLACP Port Config TLVs", and MUST NOT assert the "Priority Set" flag 2385 in the corresponding "mLACP Aggregator Config TLV". 2387 When the configurations of all ports for member links associated with 2388 a given Aggregator have been sent by a device, it asserts that fact 2389 by setting the "Synchronized" flag in the last port's "mLACP Port 2390 Config TLV". If an Aggregator doesn't have any candidate member ports 2391 configured, this is indicated by asserting the "Synchronized" flag in 2392 its "mLACP Aggregator Config TLV". 2394 Furthermore, for a given port/Aggregator, an implementation MUST 2395 advertise the port/Aggregator configuration prior to advertising its 2396 state (via the "mLACP Port State TLV" or "mLACP Aggregator State 2397 TLV"). If a PE receives an "mLACP Port State TLV" or "mLACP 2398 Aggregator State TLV" for a port or Aggregator that it had not 2399 learned of before via an appropriate Port or Aggregator Config TLV, 2400 then the PE MUST request synchronization of the configuration and 2401 state of all mLACP ports as well as all mLACP Aggregators from its 2402 respective peer. If during a synchronization (solicited or 2403 unsolicited), a PE receives a State TLV for a port or Aggregator that 2404 it has not learned of before, then the PE MUST send a NAK for the 2405 offending TLV. The PE MUST NOT request re-synchronization in this 2406 case. 2408 When mLACP is unconfigured on a port/Aggregator, a PE MUST send a 2409 "Port/Aggregator Config TLV" with the "Purge Configuration" flag 2410 asserted. This allows receiving PEs to purge any state maintained for 2411 the decommissioned port/Aggregator. If a PE receives a 2412 "Port/Aggregator Config TLV" with the "Purge Configuration" flag 2413 asserted, and the PE is not maintaining any state for that 2414 port/Aggregator, then it MUST silently discard the TLV. 2416 9.2.8.3. mLACP Aggregator and Port Status Synchronization 2418 PEs within an RG need to synchronize their state-machines for proper 2419 mLACP operation with a multi-homed device. This is achieved by having 2420 each system advertise its Aggregators and ports running state in 2421 "mLACP Aggregator State TLVs" and "mLACP Port State TLVs", 2422 respectively. Whenever any LACP parameter for an Aggregator or a 2423 port, whether on the Partner (i.e. multi-homed device) or the Actor 2424 (i.e. PE) side, is changed a system MUST transmit an updated TLV for 2425 the affected Aggregator and/or port. Moreover, when the 2426 administrative or operational state of an Aggregator or port changes, 2427 the system MUST transmit an updated Aggregator or port state TLV to 2428 its peers. 2430 If a PE receives an Aggregator or port state TLV where the 'Actor 2431 Key' doesn't match what was previously received in a corresponding 2432 Aggregator or port config TLV, the PE MUST then request 2433 synchronization of the configuration and state of the affected 2434 Aggregator or port. If such a mismatch occurs between the config and 2435 state TLVs as part of a synchronization (solicited or unsolicited), 2436 then the PE MUST send a NAK for the state TLV. Furthermore, if a PE 2437 receives a port state TLV with the 'Aggregator ID' set to a value 2438 that doesn't map to some Aggregator that the PE had learned of via a 2439 previous Aggregator config TLV, then the PE MUST request 2440 synchronization of the configuration and state of all Aggregators and 2441 ports. If the above anomaly occurs during a synchronization, then the 2442 PE MUST send a NAK for the offending port state TLV. 2444 A PE MAY request that its peer retransmit previously advertised 2445 state. This is useful for example when the PE is recovering from a 2446 soft failure and attempting to relearn state. To request such 2447 retransmissions, a PE MUST send a set of one or more "mLACP 2448 Synchronization Request TLVs". 2450 A PE MUST respond to an "mLACP Synchronization Request TLV" by 2451 sending the requested data in a set of one or more mLACP TLVs 2452 delimited by a pair of "mLACP Synchronization Data TLVs". The TLVs 2453 comprising the response MUST be ordered in the RG Application Data 2454 message(s) such that the Synchronization Response TLV with the 2455 "Synchronization Data Start" flag precedes the various other mLACP 2456 TLVs encoding the requested data. These, in turn, MUST precede the 2457 Synchronization Data TLV with the "Synchronization Data End" flag. 2458 Note that the response may span across multiple RG Application Data 2459 messages, for example when MTU limits are exceeded; however, the 2460 above ordering MUST be retained across messages, and only a single 2461 pair of Synchronization Data TLVs MUST be used to delimit the 2462 response across all Application Data Messages. 2464 A PE device MAY re-advertise its mLACP state in an unsolicited 2465 manner. This is done by sending the appropriate Config and State TLVs 2466 delimited by a pair of "mLACP Synchronization Data TLVs" and using a 2467 'Request Number' of 0. 2469 While a PE has a pending synchronization request for a system, 2470 Aggregator or port, it SHOULD silently ignore all TLVs for said 2471 system, Aggregator or port that are received prior to the 2472 synchronization response and which carry the same type of information 2473 being requested. This saves the system from the burden of updating 2474 state that will utlimately be overwritten by the synchronization 2475 response. Note that TLVs pertaining to other systems, Aggregators or 2476 ports are to continue to be processed per normal in this case. 2478 If a PE receives a synchronization request for an Aggregator, port or 2479 Key that doesn't exist or is not known to the PE, then it MUST 2480 trigger an unsolicited synchronization of all system, Aggregator and 2481 port information (i.e. replay the initialization sequence). 2483 9.2.8.4. Failure and Recovery 2485 When a PE that is active for a multi-chassis link aggregation group 2486 encounters a fault, it SHOULD attempt to fail-over to a peer PE which 2487 hosts the same RO. To that effect, the faulty PE SHOULD lower its 2488 port priority (by using a larger numeric value) and advertise this 2489 change in the "mLACP Port Priority TLV". If the PE is not capable of 2490 lowering its own port priority any further, it SHOULD trigger a 2491 failover to the redundant PE by sending an "mLACP Port Priority TLV" 2492 in which it requests the redundant PE to raise the latter's port 2493 priority to the maximum permitted in [IEEE802.3ad] (i.e. the smallest 2494 allowed numeric value) for the Aggregator in question. Furthermore, 2495 the PE SHOULD set its own port priority to the next smallest numeric 2496 value. 2498 Upon recovery from a previous fault, a PE MAY reclaim active role for 2499 a multi-chassis link aggregation group if configured for revertive 2500 protection. Otherwise, the recovering PE may assume standby role 2501 when configured for non-revertive protection. In the revertive 2502 scenario, a PE SHOULD assume active role within the RG by sending an 2503 "mLACP Port Priority TLV" to the currently active PE, requesting that 2504 the latter change its port priority to a value that is lower (i.e. 2505 numerically larger) for the Aggregator in question. 2507 If a system is operating in a mode where different ports of a bundle 2508 are configured with different Port Priorities, then the system MUST 2509 NOT advertise or request change of Port Priority values for 2510 aggregated ports collectively (i.e. by using a 'Port Number' of 0 in 2511 the "mLACP Port Priority TLV"). This is to avoid ambiguity in the 2512 interpretation of the 'Last Port Priority' field. 2514 If a PE receives an "mLACP Port Priority TLV" requesting a priority 2515 change for a port or Aggregator that is not local to the device, then 2516 the PE MUST re-advertise the local configuration of the system, as 2517 well as the configuration and state of all its mLACP ports and 2518 Aggregators. 2520 If a PE receives an "mLACP Port Priority TLV" in which the remote 2521 system is advertising priority change for a port or Aggregator that 2522 the local PE had not learned of before via an appropriate Port or 2523 Aggregator Config TLV, then the PE MUST request synchronization of 2524 the configuration and state of all mLACP ports as well as all mLACP 2525 Aggregators from its respective peer. 2527 10. Security Considerations 2529 The security considerations described in [RFC5036] and [RFC4447] that 2530 apply to the base LDP specification, and to the PW LDP control 2531 protocol extensions apply to the capability mechanism described in 2532 this document. 2534 The ICCP protocol is not intended to be applicable when the 2535 redundancy group spans PE in different administrative domains. 2536 Furthermore, implementations SHOULD provide a mechanism to select to 2537 which LDP peers the ICCP capability will be advertised, and from 2538 which LDP peers the ICCP messages will be accepted. 2540 11. IANA Considerations 2542 11.1. MESSAGE TYPE NAME SPACE 2544 This document uses several new LDP message types, IANA already 2545 maintains a registry of name "MESSAGE TYPE NAME SPACE" defined by 2546 [RFC5036]. The following values are suggested for assignment: 2548 Message type Description 2549 0x0700 RG Connect Message 2550 0x0701 RG Disconnect Message 2551 0x0702 RG Notification Message 2552 0x0703 RG Application Data Message 2554 11.2. TLV TYPE NAME SPACE 2556 This document use a new LDP TLV type, IANA already maintains a 2557 registry of name "TLV TYPE NAME SPACE" defined by [RFC5036]. The 2558 following value is suggested for assignment: 2559 TLV Type Description 2560 0x700 ICCP capability TLV. 2561 0x701 LDP TCP/IP Port TLV. 2563 11.3. ICC RG Parameter Type Space 2565 IANA needs to set up a registry of "ICC RG parameter type". These are 2566 14-bit values. Parameter Type values 1 through 0x000F are specified 2567 in this document, Parameter Type values 0x0010 through 0x1FFF are to 2568 be assigned by IANA, using the "Expert Review" policy defined in 2569 [RFC5226]. Parameter Type values 0x2000 through 0x2FFF, 0x3FFF, and 0 2570 are to be allocated using the IETF consensus policy defined in 2571 [RFC5226]. Parameter Type values 0x3000 through 0x3FFE are reserved 2572 for vendor proprietary extensions and are to be assigned by IANA, 2573 using the "First Come First Served" policy defined in [RFC5226]. A 2574 Parameter Type description is required for any assignment from this 2575 registry. Additionally, for the vendor proprietary extensions range a 2576 citation of a person or company name is also required. A document 2577 reference should also be provided. 2579 Initial ICC RG parameter type space value allocations are specified 2580 below: 2582 Parameter Type Description Reference 2583 -------------- --------------------------------- --------- 2584 0x0001 ICC Sender Name [RFCxxxx] 2585 0x0002 NAK TLV [RFCxxxx] 2586 0x0003 Requested Protocol Version TLV [RFCxxxx] 2587 0x0004 Disconnect Code TLV [RFCxxxx] 2588 0x0005 ICC RG ID TLV [RFCxxxx] 2590 0x0010 PW-RED Connect TLV [RFCxxxx] 2591 0x0011 PW-RED Disconnect TLV [RFCxxxx] 2592 0x0012 PW-RED Config TLV [RFCxxxx] 2593 0x0013 Service Name TLV [RFCxxxx] 2594 0x0014 PW ID TLV [RFCxxxx] 2595 0x0015 Generalized PW ID TLV [RFCxxxx] 2597 0x0030 mLACP Connect TLV [RFCxxxx] 2598 0x0031 mLACP Disconnect TLV [RFCxxxx] 2599 0x0032 mLACP System Config TLV [RFCxxxx] 2600 0x0033 mLACP Port Config TLV [RFCxxxx] 2601 0x0034 mLACP Port Priority TLV [RFCxxxx] 2602 0x0035 mLACP Port State TLV [RFCxxxx] 2603 0x0036 mLACP Aggregator Config TLV [RFCxxxx] 2604 0x0037 mLACP Aggregator State TLV [RFCxxxx] 2605 0x0038 mLACP Synchronization Request TLV [RFCxxxx] 2606 0x0039 mLACP Synchronization Data TLV [RFCxxxx] 2608 11.4. STATUS CODE NAME SPACE 2610 This document use several new Status codes, IANA already maintains a 2611 registry of name "STATUS CODE NAME SPACE" defined by [RFC5036]. The 2612 following values is suggested for assignment: The "E" column is the 2613 required setting of the Status Code E-bit. 2614 Range/Value E Description Reference 2615 ------------- ----- ---------------------- --------- 2616 0x00010001 0 Unknown ICCP RG 2617 0x00010002 0 ICCP Connection Count Exceeded 2618 0x00010003 0 ICCP Application Connection 2619 Count Exceeded 2620 0x00010004 0 ICCP Application not in RG 2621 0x00010005 0 Incompatible ICCP Protocol Version 2622 0x00010006 0 ICCP Rejected Message 2623 0x00010007 0 ICCP Administratively Disabled 2624 0x00010010 0 ICCP RG Removed 2625 0x00010011 0 ICCP Application Removed from RG 2627 12. Acknowledgments 2629 The authors wish to acknowledge the important contributions of Dennis 2630 Cai, Neil McGill, Amir Maleki, Dan Biagini, Robert Leger, Sami 2631 Boutros, Neil Ketley and Mark Christopher Sains. 2633 13. Normative References 2635 [RFC5036] L. Andersson et al, "LDP Specification", RFC 5036, 2636 October 2007. 2638 [RFC5561] "LDP Capabilities", RFC5561, July 2009. 2640 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., 2641 et al., rfc4447 April 2006. 2643 [IEEE-802.3] IEEE Std. 802.3-2005, "Part 3: Carrier Sense Multiple 2644 Access with Collision Detection (CSMA/CD) Access Method and 2645 Physical Layer Specifications", IEEE Computer Society, December 2646 2005. 2648 [RFC2863] K. McCloghrie, F. Kastenholz, "The Interfaces Group MIB", 2649 rfc2863, June 2000. 2651 14. Informative References 2653 [BFD] D. Katz, D. Ward, "Bidirectional Forwarding Detection", 2654 draft-ietf-bfd-base-09.txt, February 2009 (Work in Progress) 2656 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2657 IANA Considerations section in RFCs", BCP 26, RFC 5226, May 2008 2659 15. Author's Addresses 2661 Luca Martini 2662 Cisco Systems, Inc. 2663 9155 East Nichols Avenue, Suite 400 2664 Englewood, CO, 80112 2665 e-mail: lmartini@cisco.com 2667 Samer Salam 2668 Cisco Systems, Inc. 2669 595 Burrard Street, Suite 2123 2670 Vancouver, BC V7X 1J1 2671 Canada 2672 e-mail: ssalam@cisco.com 2674 Ali Sajassi 2675 Cisco Systems, Inc. 2676 170 West Tasman Drive 2677 San Jose, CA 95134 2678 e-mail: sajassi@cisco.com 2680 Matthew Bocci 2681 Alcatel-Lucent 2682 Grove House, Waltham Road Rd 2683 White Waltham, Berks, UK. SL6 3TN 2684 e-mail: matthew.bocci@alcatel-lucent.co.uk 2686 Satoru Matsushima 2687 Softbank Telecom 2688 1-9-1, Higashi-Shinbashi, Minato-ku 2689 Tokyo 105-7313, JAPAN 2690 e-mail: satoru.matsushima@tm.softbank.co.jp 2691 Thomas D. Nadeau 2692 BT 2693 BT Centre 2694 81 Newgate Street 2695 London, EC1A 7AJ 2696 United Kingdom 2697 e-mail: tom.nadeau@bt.com 2699 Full Copyright Statement 2701 Copyright (c) 2009 IETF Trust and the persons identified as the 2702 document authors. All rights reserved. 2704 This document is subject to BCP 78 and the IETF Trust's Legal 2705 Provisions Relating to IETF Documents in effect on the date of 2706 publication of this document (http://trustee.ietf.org/license-info). 2707 Please review these documents carefully, as they describe your rights 2708 and restrictions with respect to this document. 2710 Expiration Date: April 2010