idnits 2.17.1 draft-martini-pwe3-iccp-01.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.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 17, 2009) is 5540 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCxxxx' is mentioned on line 2024, but not defined == Outdated reference: A later version (-04) exists of draft-ietf-mpls-ldp-capabilities-02 ** 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 (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini 3 Internet Draft Samer Salam 4 Expiration Date: August 2009 Ali Sajassi 5 Intended status: Standards Track Cisco 7 Satoru Matsushima Thomas D. Nadeau 8 Softbank BT 10 February 17, 2009 12 Inter-Chassis Communication Protocol for L2VPN PE Redundancy 14 draft-martini-pwe3-iccp-01.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 17, 2009 39 Abstract 41 This document specifies an inter-chassis communication protocol 42 (ICCP) that enables PE redundancy for Virtual Private Wire Service 43 (VPWS) and Virtual Private LAN Service (VPLS) applications. The 44 protocol runs within a set of two or more PEs, forming a redundancy 45 group, for the purpose of synchronizing data amongst the systems. It 46 accommodates multi-chassis attachment circuit as well as pseudowire 47 redundancy mechanisms. 49 Table of Contents 51 1 Specification of Requirements ........................ 3 52 2 Acknowledgments ...................................... 4 53 3 Introduction ......................................... 4 54 4 ICCP Overview ........................................ 4 55 4.1 Redundancy Model & Topology .......................... 4 56 4.2 ICCP Interconnect Scenarios .......................... 6 57 4.2.1 Co-located Dedicated Interconnect .................... 6 58 4.2.2 Co-located Shared Interconnect ....................... 7 59 4.2.3 Geo-redundant Dedicated Interconnect ................. 7 60 4.2.4 Geo-redundant Shared Interconnect .................... 8 61 4.3 ICCP Requirements .................................... 9 62 5 ICC LDP Protocol Extension Specification ............. 10 63 5.1 LDP ICCP Capability Advertisement .................... 11 64 5.2 RG Membership Management ............................. 11 65 5.3 Application Connection Management .................... 12 66 5.4 Application Versioning ............................... 13 67 5.5 Application Data Transfer ............................ 14 68 5.6 Dedicated Redundancy Group LDP session ............... 14 69 6 ICCP PE Node Failure Detection Mechanism ............. 14 70 7 ICCP Message Formats ................................. 15 71 7.1 Encoding ICC into LDP Messages ...................... 15 72 7.1.1 ICC Header ........................................... 16 73 7.1.2 Message Encoding ..................................... 17 74 7.2 RG Connect Message ................................... 19 75 7.2.1 Sender Name TLV ...................................... 19 76 7.3 RG Disconnect Message ................................ 20 77 7.4 RG Notification Message .............................. 23 78 7.4.1 Notification Message TLVs ............................ 23 79 7.5 RG Application Data Message .......................... 26 80 8 Application TLVs ..................................... 27 81 8.1 Pseudowire Redundancy (PW-RED) Application TLVs ...... 27 82 8.1.1 PW-RED Connect TLV ................................... 27 83 8.1.2 PW-RED Disconnect TLV ................................ 28 84 8.1.3 PW-RED Config TLV .................................... 29 85 8.1.4 Service Name TLV ..................................... 29 86 8.1.5 PW ID TLV ............................................ 29 87 8.1.6 Generalized PW ID TLV ................................ 30 88 8.2 Multi-chassis LACP (mLACP) Application TLVs .......... 31 89 8.2.1 mLACP Connect TLV .................................... 32 90 8.2.2 mLACP Disconnect TLV ................................. 33 91 8.2.3 mLACP System Config TLV .............................. 33 92 8.2.4 mLACP Port Config TLV ................................ 35 93 8.2.5 mLACP Change Port Priority TLV ....................... 36 94 8.2.6 mLACP Port State TLV ................................. 37 95 9 LDP Capability Negotiation ........................... 40 96 10 Client Applications .................................. 41 97 10.1 Pseudowire Redundancy Application Procedures ......... 41 98 10.1.1 Initial Setup ........................................ 41 99 10.1.2 Pseudowire Configuration ............................. 41 100 10.1.3 Pseudowire Status Synchronization .................... 42 101 10.1.4 PE Node Failure ...................................... 42 102 10.2 Attachment Circuit Redundancy Application Procedures . 42 103 10.2.1 Common AC Procedures ................................. 42 104 10.2.2 AC Failure ........................................... 43 105 10.2.3 PE Node Failure ...................................... 43 106 10.2.4 PE Isolation ......................................... 43 107 10.2.5 ATM AC Procedures .................................... 43 108 10.2.6 Frame Relay AC Procedures ............................ 43 109 10.2.7 Ethernet AC Procedures ............................... 43 110 10.2.8 Multi-chassis LACP (mLACP) Application Procedures .... 43 111 10.2.8.1 Initial Setup ........................................ 44 112 10.2.8.2 mLACP Port Configuration ............................. 44 113 10.2.8.3 mLACP Port Status Synchronization .................... 45 114 10.2.8.4 Triggering Failover .................................. 45 115 11 Security Considerations .............................. 45 116 12 IANA Considerations .................................. 46 117 12.1 MESSAGE TYPE NAME SPACE .............................. 46 118 12.2 TLV TYPE NAME SPACE .................................. 46 119 12.3 ICC RG Parameter Type Space .......................... 46 120 12.4 STATUS CODE NAME SPACE ............................... 47 121 13 Normative References ................................. 48 122 14 Informative References ............................... 48 123 15 Author's Addresses ................................... 48 125 1. Specification of Requirements 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119. 131 2. Acknowledgments 133 The authors wish to acknowledge the important contributions of Dennis 134 Cai, Neil McGill and Amir Maleki. 136 3. Introduction 138 Network availability is a critical metric for service providers as it 139 has a direct bearing on their profitability. Outages translate not 140 only to lost revenue but also to potential penalties mandated by 141 contractual agreements with customers running mission-critical 142 applications that require tight SLAs. This is true for any carrier 143 network, and networks employing Layer2 Virtual Private Network 144 (L2VPN) technology are no exception. Network high-availability can 145 be achieved by employing intra and inter-chassis redundancy 146 mechanisms. The focus of this document is on the latter. The document 147 defines an Inter-Chassis Communication Protocol (ICCP) that allows 148 synchronization of state and configuration data between a set of two 149 or more PEs forming a Redundancy Group (RG). The protocol supports 150 multi-chassis redundancy mechanisms that can be employed on either 151 the attachment circuit or pseudowire front. 153 4. ICCP Overview 155 4.1. Redundancy Model & Topology 157 The focus of this document is on PE node redundancy. It is assumed 158 that a set of two or more PE nodes are designated by the operator to 159 form a Redundancy Group (RG). Members of a Redundancy Group fall 160 under a single administration (e.g. service provider) and employ a 161 common redundancy mechanism towards the access (attachment circuits 162 or access pseudowires) and/or towards the core (pseudowires) for any 163 given service instance. It is possible, however, for members of a RG 164 to make use of disparate redundancy mechanisms for disjoint services. 165 The PE devices may be offering any type of L2VPN service, i.e. VPWS 166 or VPLS. As a matter of fact, the use of ICCP may even be applicable 167 for Layer 3 service redundancy, but this is considered to be outside 168 the scope of this document. 170 The PEs in a RG offer multi-homed connectivity to either individual 171 devices (e.g. CE, DSLAM, etc...) or entire networks (e.g. access 172 network). Figure 1 below depicts the model. 174 +=================+ 175 | | 176 Mutli-homed +----+ | +-----+ | 177 Node ------------> | CE |-------|--| PE1 ||<------|---Pseudowire-->| 178 | |--+ -|--| ||<------|---Pseudowire-->| 179 +----+ | / | +-----+ | 180 | / | || | 181 |/ | || ICCP |--> Towards Core 182 +-------------+ / | || | 183 | | /| | +-----+ | 184 | Access |/ +----|--| PE2 ||<------|---Pseudowire-->| 185 | Network |-------|--| ||<------|---Pseudowire-->| 186 | | | +-----+ | 187 | | | | 188 +-------------+ | Redundancy | 189 ^ | Group | 190 | +=================+ 191 | 192 Multi-homed Network 194 Figure 1: Generic Multi-chassis Redundancy Model 196 In the topology of Figure 1, the redundancy mechanism employed 197 towards the access node/network can be one of a multitude of 198 technologies, e.g. it could be IEEE 802.3ad Link Aggregation Groups 199 with Link Aggregation Control Protocol (LACP), or SONET APS. The 200 specifics of the mechanism are out of the scope of this document. 201 However, it is assumed that the PEs in the RG are required to 202 communicate amongst each other in order for the access redundancy 203 mechanism to operate correctly. As such, it is required to run an 204 inter-chassis communication protocol among the PEs in the RG in order 205 to synchronize configuration and/or running state data. 207 Furthermore, the presence of the inter-chassis communication channel 208 allows simplification of the pseudowire redundancy mechanism. This is 209 primarily because it allows the PEs within a RG to run some 210 arbitration algorithm to elect which pseudowire(s) should be in 211 active or standby mode for a given service instance. The PEs can then 212 advertise the outcome of the arbitration to the remote-end PE(s), as 213 opposed to having to embed a hand-shake procedure into the pseudowire 214 redundancy status communication mechanism, and every other possible 215 Layer 2 status communication mechanism. 217 4.2. ICCP Interconnect Scenarios 219 When referring to 'interconnect' in this section, we are concerned 220 with the links or networks over which Inter-Chassis Communication 221 Protocol messages are transported, and not normal data traffic 222 between PEs. The PEs which are members of a RG may be either 223 physically co-located or geo-redundant. Furthermore, the physical 224 interconnect between the PEs over which ICCP is to run may comprise 225 of either dedicated back-to-back links or a shared connection through 226 the PSN network (e.g., core). This gives rise to a matrix of four 227 interconnect scenarios, described next. 229 4.2.1. Co-located Dedicated Interconnect 231 In this scenario, the PEs within a RG are co-located in the same 232 physical location (POP, CO). Furthermore, dedicated links provide the 233 interconnect for ICCP among the PEs. 235 +=================+ +-----------------+ 236 |CO | | | 237 | +-----+ | | | 238 | | PE1 |________|_____| | 239 | | | | | | 240 | +-----+ | | | 241 | || | | | 242 | || ICCP | | Core | 243 | || | | Network | 244 | +-----+ | | | 245 | | PE2 |________|_____| | 246 | | | | | | 247 | +-----+ | | | 248 | | | | 249 +=================+ +-----------------+ 251 Figure 2: ICCP Co-located PEs Dedicated Interconnect Scenario 253 Given that the PEs are connected back-to-back in this case, it is 254 possible to rely on Layer 2 redundancy mechanisms to guarantee the 255 robustness of the links carrying the ICCP. For example, if the 256 interconnect comprises of IEEE 802.3 Ethernet links, it is possible 257 to provide redundant interconnect by means of IEEE 802.3ad Link 258 Aggregation Groups. 260 4.2.2. Co-located Shared Interconnect 262 In this scenario, the PEs within a RG are co-located in the same 263 physical location (POP, CO). However, unlike the previous scenario, 264 there are no dedicated links between the PEs. The interconnect for 265 ICCP is provided through the core network to which the PEs are 266 connected. Figure 3 depicts this model. 268 +=================+ +-----------------+ 269 |CO | | | 270 | +-----+ | | | 271 | | PE1 |________|_____| | 272 | | |<=================+ | 273 | +-----+ ICCP | | || | 274 | | | || | 275 | | | || Core | 276 | | | || Network | 277 | +-----+ | | || | 278 | | PE2 |________|_____| || | 279 | | |<=================+ | 280 | +-----+ | | | 281 | | | | 282 +=================+ +-----------------+ 284 Figure 3: ICCP Co-located PEs Shared Interconnect Scenario 286 Given that the PEs in the RG are connected over the Packet Switched 287 Network (PSN), then PSN Layer mechanisms can be leveraged to ensure 288 the resiliency of the interconnect against connectivity failures. For 289 example, it is possible to employ RSVP LSPs with Fast ReRoute (FRR) 290 and/or end-to-end backup LSPs. 292 4.2.3. Geo-redundant Dedicated Interconnect 294 In this variation, the PEs within a Redundancy Group are located in 295 different physical locations to provide geographic redundancy. This 296 may be desirable, for example, to protect against natural disasters 297 or the like. A dedicated interconnect is provided to link the PEs, 298 which is a costly option, especially when considering the possibility 299 of providing multiple such links for interconnect robustness. The 300 resiliency mechanisms for the interconnect are similar to those 301 highlighted in the co-located interconnect counterpart. 303 +=================+ +-----------------+ 304 |CO 1 | | | 305 | +-----+ | | | 306 | | PE1 |________|_____| | 307 | | | | | | 308 | +-----+ | | | 309 +=====||==========+ | | 310 || ICCP | Core | 311 +=====||==========+ | Network | 312 | +-----+ | | | 313 | | PE2 |________|_____| | 314 | | | | | | 315 | +-----+ | | | 316 |CO 2 | | | 317 +=================+ +-----------------+ 319 Figure 4: ICCP Geo-redundant PEs Dedicated Interconnect Scenario 321 4.2.4. Geo-redundant Shared Interconnect 323 In this scenario, the PEs of a RG are located in different physical 324 locations and the interconnect for ICCP is provided over the PSN 325 network to which the PEs are connected. This interconnect option is 326 more likely to be the one used for geo-redundancy as it is more 327 economically appealing compared to the geo-redundant dedicated 328 interconnect. The resiliency mechanisms that can be employed to 329 guarantee the robustness of the ICCP transport are PSN Layer 330 mechanisms as has been described in a previous section. 332 +=================+ +-----------------+ 333 |CO 1 | | | 334 | +-----+ | | | 335 | | PE1 |________|_____| | 336 | | |<=================+ | 337 | +-----+ ICCP | | || | 338 +=================+ | || | 339 | || Core | 340 +=================+ | || Network | 341 | +-----+ | | || | 342 | | PE2 |________|_____| || | 343 | | |<=================+ | 344 | +-----+ | | | 345 |CO 2 | | | 346 +=================+ +-----------------+ 348 Figure 5: ICCP Geo-redundant PEs Shared Interconnect Scenario 350 4.3. ICCP Requirements 352 The Inter-chassis Communication Protocol should satisfy the following 353 requirements: 355 -i. Provide a control channel for communication between PEs in 356 Redundancy Group (RG). Nodes maybe co-located or remote 357 (refer to Interconnect Scenarios section above). It is 358 expected that client applications which make use of ICCP 359 services will only use this channel to communicate control 360 information and not data-traffic. As such the protocol 361 should cater for low-bandwidth, low-delay and highly 362 reliable message transfer. 364 -ii. Accommodate multiple client applications (e.g. multi-chassis 365 LACP, PW redundancy, SONET APS, etc...). This implies that 366 the messages should be extensible (e.g. TLV-based) and the 367 protocol should provide a robust application registration 368 and versioning scheme. 370 -iii. Provide reliable message transport and in-order delivery 371 between nodes in a RG with secure authentication mechanisms 372 built into the protocol. The redundancy applications that 373 are clients of ICCP expect reliable message transfer, and as 374 such will assume that the protocol takes care of flow- 375 control and retransmissions. Furthermore, given that the 376 applications will rely on ICCP to communicate data used to 377 synchronize state-machines on disparate nodes, it is 378 critical that ICCP guarantees in-order message delivery. 379 Loss of messages or out-of-sequence messages would have 380 adverse side-effects to the operation of the client 381 applications. 383 -iv. Provide a common mechanism to actively monitor the health of 384 PEs in a RG. This mechanism will be used to detect PE node 385 failure and inform the client applications. The applications 386 require this to trigger failover according to the procedures 387 of the employed redundancy protocol on the AC and PW. It is 388 desired to achieve sub-second detection of loss of remote 389 node (~ 50 - 150 msec) in order to give the client 390 applications (redundancy mechanisms) enough reaction time to 391 achieve sub-second service restoration time. 393 -v. Provide asynchronous event-driven state update, independent 394 of periodic messages, for immediate notification of client 395 applications' state changes. In other words, the 396 transmission of messages carrying application data should be 397 on-demand rather than timer-based to minimize inter-chassis 398 state synchronization delay. 400 -vi. Accommodate multi-link and multi-hop interconnect between 401 nodes. When the devices within a RG are located in different 402 physical locations, the physical interconnect between them 403 will comprise of a network rather than a link. As such, ICCP 404 should accommodate the case where the interconnect involves 405 multiple hops. Furthermore, it is possible to have multiple 406 (redundant) paths or interconnects between a given pair of 407 devices. This is true for both the co-located and geo- 408 redundant scenarios. ICCP should handle this as well. 410 -vii. Ensure transport security between devices in a RG. This is 411 especially important in the scenario where the members of a 412 RG are located in different physical locations and connected 413 over a shared (e.g. PSN) network. 415 -viii. Must allow operator to statically configure members of RG. 416 Auto-discovery may be considered in the future. 418 -ix. Allow for flexible RG membership. It is expected that only 419 two nodes per an RG will cover most of the redundancy 420 applications for common deployments. However, ICCP should 421 not preclude supporting more than two nodes in a RG by 422 virtue of design. Furthermore, it is required to allow a 423 single node to be member of multiple RGs simultaneously. 425 5. ICC LDP Protocol Extension Specification 427 To address the requirements identified in the previous section, ICCP 428 is modeled to comprise of three layers: 430 -i. Application Layer: This provides the interface to the 431 various redundancy applications that make use of the 432 services of ICCP. ICCP is concerned with defining common 433 connection management procedures and the formats of the 434 messages exchanged at this layer; however, beyond that, it 435 does not impose any restrictions on the procedures or 436 state-machines of the clients, as these are deemed 437 application-specific and lie outside the scope of ICCP. 438 This guarantees implementation inter-operability without 439 placing any unnecessary constraints on internal design 440 specifics. 442 -ii. Inter Chassis Communication (ICC) Layer: This layer 443 implements the common set of services which ICCP offers to 444 the client applications. It handles protocol versioning, RG 445 membership, PE node identification and ICCP connection 446 management. 448 -iii. Transport Layer: This layer provides the actual ICCP message 449 transport. It is responsible for addressing, route 450 resolution, flow-control, reliable and in-order message 451 delivery, connectivity resiliency/redundancy and finally PE 452 node failure detection. The Transport layer may differ 453 depending on the Physical Layer of the inter-connect. 455 5.1. LDP ICCP Capability Advertisement 457 When a RG is enabled on a particular PE, the capability of supporting 458 ICCP must be advertised to all LDP peers in that RG. This is achieved 459 by using the methods in [LDP-CAP] and advertising the ICCP LDP 460 capability TLV. If an LDP peer supports the dynamic capability 461 advertisement, this can be done by sending a new capability message 462 with the S bit set for the ICCP capability TLV when the first RG is 463 enabled on the PE. If the peer does not support dynamic capability 464 advertisement, then the ICCP TLV MUST be included in the LDP 465 initialization procedures in the capability parameter [LDP-CAP]. 467 5.2. RG Membership Management 469 ICCP defines a mechanism that enables PE nodes to manage their RG 470 membership. When a PE is configured to be a member of a RG, it will 471 first advertise the ICCP capability to its peers. Subsequently, the 472 PE sends a RG Connect message to the peers that have also advertised 473 ICCP capability. The PE then waits for the peers to send their own RG 474 Connect messages, if they haven't already. For a given RG, the ICCP 475 connection between two devices is considered to be operational only 476 when both have sent and received ICCP RG Connect messages for that 477 RG. 479 If a PE that has sent a particular RG Connect message doesn't receive 480 a corresponding RG Connect (or a Notification message with NAK) from 481 a destination, it will remain in a state expecting the corresponding 482 RG Connect message (or Notification message). The RG will not become 483 operational until the corresponding RG Connect Message has been 484 received. If a PE that has sent an RG Connect message receives a 485 Notification message with a NAK, it will stop attempting to bring up 486 the ICCP connection immediately. The PE MUST resume bringing up the 487 connection after it receives a RG Connect message from the peer PE 488 for the RG in question. This is achieved by responding to the 489 incoming RG Connect message with an appropriate RG Connect. 491 A device MUST send a NAK for a RG Connect message if at least one of 492 the following conditions is satisfied: 494 -i. the PE is not a member of the RG; 496 -ii. the maximum number of simultaneous ICCP connections that the 497 PE can handle is exceeded. 499 A PE sends a RG Disconnect message to tear down the ICCP connection 500 for a given RG. This is a unilateral operation and doesn't require 501 any acknowledgement from the other PEs. Note that the ICCP connection 502 for a RG MUST be operational before any client application can make 503 use of ICCP services in that RG. 505 5.3. Application Connection Management 507 ICCP provides a common set of procedures by which applications on one 508 PE can connect to their counterparts on another PE, for purpose of 509 inter-chassis communication in the context of a given RG. The 510 prerequisite for establishing an application connection is to have an 511 operational ICCP RG connection between the two endpoints. It is 512 assumed that the association of applications with RGs is known 513 apriori, e.g. by means of device configuration. ICCP then sends an 514 Application-specific Connect TLV (carried in RG Connect message), on 515 behalf of each client application, to each remote PE within the RG. 516 The client may piggyback application-specific information in that 517 Connect TLV, which for example can be used to negotiate parameters or 518 attributes prior to bringing up the actual application connection. 519 The procedures for bringing up the application connection are similar 520 to those of the ICCP connection: An application connection between 521 two nodes is up only when both nodes have sent and received RG 522 Connect Messages with the proper Application-specific Connect TLVs. A 523 PE MUST send a Notification Message to NAK an application connection 524 request if one of the following conditions is encountered: 526 -i. the application doesn't exist or is not configured for that 527 RG; 529 -ii. the application connection count exceeds the PE's 530 capabilities. 532 When a PE receives such a NAK notification, it should stop attempting 533 to bring up the application connection until it receives a new 534 application connection request from the remote PE. This is done by 535 responding to the incoming RG Connect message (carrying an 536 Application-specific Connect TLV) with an appropriate RG Connect 537 message (carrying a corresponding Application-specific Connect TLV). 539 When an application is stopped on a device or it is no longer 540 associated with a RG, it should signal ICCP to trigger sending an 541 Application-specific Disconnect TLV (in RG Disconnect message). This 542 is a unilateral notification to the other PEs within a RG, and as 543 such doesn't trigger any response. 545 5.4. Application Versioning 547 During application connection setup time, a given application on one 548 PE can negotiate with its counterpart on a peer PE the proper 549 application version to use for communication. If no common version is 550 agreed upon, then the application connection is not brought up. This 551 is achieved through the following simple rules: 553 - If an application receives an Application-specific Connect TLV 554 with a version that is higher than its own, it MUST send a 555 Notification message with a NAK TLV indicating status code 556 "Incompatible Protocol Version" and supplying the version that is 557 locally supported by the PE. 559 - If an application receives an Application-specific Connect TLV 560 with a version that is lower than its own, it MAY respond with a 561 RG Connect that has an Application-specific Connect TLV using the 562 same version that was received. Alternatively, the application 563 MAY respond with a Notification message to NAK the request using 564 the "Incompatible Protocol Version" code, and supplying the 565 version that is supported. The above allows an application to 566 operate in either backwards compatible or incompatible modes. 568 - If an application receives an Application-specific Connect TLV 569 with a version that is equal to its own, then the application 570 MUST honor or reject the request based on whether the application 571 is configured for the RG in question, and whether or not the 572 application connection count has been exceeded. 574 5.5. Application Data Transfer 576 When an application has information to transfer over ICCP it triggers 577 the transmission of an Application Data message. ICCP guarantees in- 578 order and loss-less delivery of data. An application may NAK a 579 message or a set of one or more TLVs within a message by using the 580 Notification Message with NAK TLV. Furthermore, an application may 581 implement its own ACK mechanism, if deemed required, by defining an 582 application-specific TLV to be transported in an Application Data 583 message. 585 5.6. Dedicated Redundancy Group LDP session 587 In some ICCP applications there is a requirement to exchange a fairly 588 large amount of RG information in a very short period of time. In 589 order to better distribute the load in a multiple processor system, 590 and to avoid head of line blocking to other LDP appications, it may 591 be required to inititate a separate TCP/IP session between the two 592 LDP speakers. 594 This procedure is OPTIONAL, and does not change the operation of LDP 595 or ICCP. 597 An LSR that requires a separate LDP session will advertise a separate 598 LDP adjacency with a non-zero label space identifier. This will cause 599 the remote peer to open a separate LDP session for this label space. 600 No labels need be advertised in in this label space , as it is only 601 used for a particular , or particular set of ICCP RGs. All relevant 602 LDP , and ICCP procedures still apply as described in the relevant 603 documents. 605 6. ICCP PE Node Failure Detection Mechanism 607 ICCP provides its client applications a notification when a remote PE 608 that is member of the RG fails. This is used by the client 609 applications to trigger failover according to the procedures of the 610 employed redundancy protocol on the AC and PW. To that end, ICCP does 611 not define its own KeepAlive mechanism for purpose of monitoring the 612 health of remote PE nodes, but rather reuses existing fault detection 613 mechanisms. The following mechanisms may be used by ICCP to detect PE 614 node failure: 616 - BFD 618 Run a BFD session [BFD] between the PEs that are members of a 619 given RG, and use that to detect PE node failure. This assumes 620 that resiliency mechanisms are in place to protect connectivity 621 to the remote PE nodes, and hence loss of BFD periodic messages 622 from a given PE node can only mean that the node itself has 623 failed. 625 - IP Reachability Monitoring 627 It is possible for a PE to monitor IP layer connectivity to other 628 members of a RG that are participating in IGP/BGP. When 629 connectivity to a given PE is lost, the local PE interprets that 630 to mean loss of the remote PE node. This assumes that resiliency 631 mechanisms are in place to protect the route to the remote PE 632 nodes, and hence loss of IP reachability to a given node can only 633 mean that the node itself has failed. 635 It is worth noting here that loss of the LDP session with a PE in a 636 RG is not a reliable indicator that the remote PE itself is down. It 637 is possible, for e.g. that the remote PE encounters a local event 638 that leads to resetting the LDP session, while the PE node remains 639 operational for purpose of traffic forwarding. 641 7. ICCP Message Formats 643 This section defines the messages exchanged at the Application and 644 ICC layers. 646 7.1. Encoding ICC into LDP Messages 648 ICCP requires reliable, in order, state-full message delivery, as 649 well as capability negotiation between PEs. The LDP protocol offers 650 all these features, and is already in wide use in the applications 651 that would also require the ICCP protocol extensions. For these 652 reasons, ICCP takes advantage of the already defined LDP protocol 653 infrastructure. [RFC5036] Section 3.5 defines a generic LDP message 654 structure. A new set of LDP message types is defined to communicate 655 the ICCP information. LDP message types in the range of 0x700 to 656 0x7ff will be used for ICCP. 658 Message types are allocated by IANA, and requested in the IANA 659 section below. 661 7.1.1. ICC Header 663 Every ICCP message comprises of an ICC specific LDP Header followed 664 by an ICCP message. The format of the ICC Header is as follows: 666 0 1 2 3 667 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 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 |U| Message Type | Message Length | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Message ID | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Type=0x0005 (ICC RG ID) | Length=4 | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | ICC RG ID | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | | 678 + + 679 | Mandatory Parameters | 680 ~ ~ 681 + + 682 | | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | | 685 + + 686 | Optional Parameters | 687 ~ ~ 688 + + 689 | | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 - U-bit 694 Unknown message bit. Upon receipt of an unknown message, if U is 695 clear (=0), a notification is returned to the message originator; 696 if U is set (=1), the unknown message is silently ignored. The 697 following sections which define messages specify a value for the 698 U-bit. 700 - Message Type 702 Identifies the type of the ICCP message, must be in the range of 703 0x0700 to 0x07ff. 705 - Message Length 707 Two octet integer specifying the total length of this message in 708 octets, excluding the U-bit, Message Type and Length fields. 710 - Message ID 712 Four octet value used to identify this message. Used by the 713 sending PE to facilitate identifying RG Notification messages 714 that may apply to this message. A PE sending a RG Notification 715 message in response to this message SHOULD include this Message 716 ID in the "NAK TLV" of the RG Notification message; see Section 717 "RG Notification Message". 719 - ICC RG ID 721 A TLV of type 0x0005, length 4, containing 4 octects unsigned 722 integer designating the Redundancy Group which the sending device 723 is member of. RG ID value 0x00000000 is reserved by the protocol. 725 - Mandatory Parameters 727 Variable length set of required message parameters. Some 728 messages have no required parameters. 730 For messages that have required parameters, the required 731 parameters MUST appear in the order specified by the individual 732 message specifications in the sections that follow. 734 - Optional Parameters 736 Variable length set of optional message parameters. Many 737 messages have no optional parameters. 739 For messages that have optional parameters, the optional 740 parameters may appear in any order. 742 7.1.2. Message Encoding 744 The generic format of an ICC parameter is: 746 0 1 2 3 747 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 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 |U|F| Type | Length | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | TLV(s) | 752 ~ ~ 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 - U-bit 757 Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear 758 (=0), a notification MUST be returned to the message originator 759 and the entire message MUST be ignored; if U is set (=1), the 760 unknown TLV MUST be silently ignored and the rest of the message 761 processed as if the unknown TLV did not exist. The sections 762 following that define TLVs specify a value for the U-bit. 764 - F-bit 766 Forward unknown TLV bit. This bit applies only when the U-bit is 767 set and the LDP message containing the unknown TLV is to be 768 forwarded. If F is clear (=0), the unknown TLV is not forwarded 769 with the containing message; if F is set (=1), the unknown TLV is 770 forwarded with the containing message. The sections following 771 that define TLVs specify a value for the F-bit. By setting both 772 the U- and F-bits, a TLV can be propagated as opaque data through 773 nodes that do not recognize the TLV. 775 - Type 777 Fourteen bits indicating the parameter type. 779 - Length 781 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 782 Length fields. 784 - TLV(s): A set of 0 or more TLVs, that vary according to the 785 message type. 787 7.2. RG Connect Message 789 The RG Connect Message is used to establish ICCP connection in 790 addition to individual Application connections between PEs in a RG: a 791 RG Connect message with no "Application-specific connect TLVs" 792 signals establishment of the base ICCP connection. RG Connect 793 messages with appropriate "Application-specific connect TLVs" signal 794 the establishment of Application connections, in addition to the base 795 ICCP connection (if not already established). A PE sends a RG 796 Connect Message to declare its membership in a Redundancy Group. One 797 such message should be sent to each PE that is member of the same RG. 798 The set of PEs to which RG Connect Messages should be transmitted is 799 known via configuration or an auto-discovery mechanism that is 800 outside the scope of this specification. If a device is member of 801 multiple RGs, it must send separate RG Connect Messages for each RG 802 even if the receiving device(s) happen to be the same. 804 The format of the RG Connect Message is as follows: 806 -i. ICC header with Message type = "RG Connect Message" (0x0700) 807 -ii. "Sender Name TLV" 808 -iii. "Application specific connect TLV" 810 The currently defined Application-specific connect TLVs are: 812 - PW Redundancy Connect TLV 814 - mLACP Connect TLV 816 The details of these TLVs are discussed in the "Application TLVs" 817 section. 819 The RG Connect message can contain zero, one or more Application- 820 specific connect TLVs. Multiple application connect TLVs can be sent 821 in a single message, or multiple messages can be sent containing 822 different application connect TLVs, but no application connect TLV 823 can be sent more than once. 825 7.2.1. Sender Name TLV 827 A TLV that carries the hostname of the sender encoded in UTF-8. This 828 is used primarily for purpose of management of the RG and easing 829 network operations. The specific format is shown below: 831 0 1 2 3 832 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 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 |U|F| Type | Length | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Sender Name | 837 + +-+-+-+-+-+-+-+-+-+ 838 ~ ~ 839 | ... | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 - U=F=0 844 - Type set to "ICC sender name" Parameter type (from ICC parameter 845 name space). 847 - Length 849 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 850 Length fields. 852 - Sender Name 854 Hostname of sending device encoded in UTF-8, and SHOULD NOT 855 exceed 80 characters. 857 7.3. RG Disconnect Message 859 The RG Disconnect Message serves dual-purpose: to signal that a 860 particular Application connection is being closed within a RG, or 861 that the ICCP connection itself is being disconnected because the PE 862 wishes to leave the RG. The format of this message is: 864 0 1 2 3 865 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 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 |U| Message Type=0x0701 | Message Length | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Message ID | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Type=0x0005 (ICC RG ID) | Length=4 | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | ICC RG ID | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Disconnect Code TLV | 876 + + 877 | | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Optional Application-specific Disconnect TLVs | 880 ~ ~ 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Optional Parameter TLVs | 883 + + 884 | | 885 ~ ~ 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 - U-bit 890 U=0 892 - Message Type 894 The message type for RG Disconnect Message is set to (0x0701) 896 - Length 898 Length of the TLV in octets excluding the U-bit, Message Type, 899 and Message Length fields. 901 - Message ID 903 Defined in the "ICC Header" section above. 905 - ICC RG ID 907 Defined in the "ICC Header" section above. 909 - Disconnect Code TLV 911 The format of this TLV is as follows: 913 0 1 2 3 914 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 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 |U|F| Type=0x0004 | Length | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | ICCP Status Code | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 - U,F Bits 923 both U and F are set to 0. 925 - Type 927 set to "Disconnect Code TLV" (0x0004) 929 - Length 931 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 932 Length fields. 934 - ICCP Status Code 936 A status code that reflects the reason for the disconnect 937 message. Allowed values are "ICCP RG Removed" and "ICCP 938 Application Removed from RG". 940 - Optional Application-specific Disconnect TLVs 942 Zero, one or more Application-specific Disconnect TLVs which are 943 defined later in the document. If the RG Disconnect message has a 944 status code of "RG Removed", then it should not contain any 945 Application-specific Disconnect TLVs, as the sending PE is 946 signaling that it has left the RG and, thus, is disconnecting the 947 entire ICCP connection, with all associated client application 948 connections. If the message has a status code of "Application 949 Removed from RG", then it should contain one or more 950 Application-specific Disconnect TLVs, as the sending PE is only 951 tearing down the connection for the specified applications. Other 952 applications, and the base ICCP connection are not to be 953 affected. 955 - Optional Parameter TLVs 957 None are defined for this message in this document. 959 7.4. RG Notification Message 961 A PE sends a RG Notification Message to indicate one of the 962 following: to reject an ICCP connection, to reject an application 963 connection, to NAK an entire message or to NAK one or more TLV(s) 964 within a message. The Notification message can only be sent to a PE 965 that is already part of a RG. 967 The format of the Notification Message is: 969 -i. ICC header with Message type = "RG Notification Message" 970 (0x0702) 971 -ii. Notification Message TLVs. 973 The currently defined Notification message TLVs are: 975 -i. Sender Name TLV 976 -ii. NAK TLV. 978 7.4.1. Notification Message TLVs 980 The Sender Name TLV uses the same format as in the RG Connect 981 message, and was described above. 983 The NAK TLV is defined as follows: 985 0 1 2 3 986 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 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 |U|F| Type=0x0002 | Length | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | ICCP Status Code | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Rejected Message ID | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | Optional TLV(s) | 995 + + 996 | | 997 ~ ~ 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 - U,F Bits 1001 both U and F are set to 0. 1003 - Type 1005 set to "NAK TLV" (0x0002) 1007 - Length 1009 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1010 Length fields. 1012 - ICCP Status Code 1014 A status code the reflects the reason for the NAK TLV. Allowed 1015 values are: 1016 -i. Unknown RG (0x00010001) 1018 This code is used to reject a new incoming ICCP 1019 connection for a RG that is not configured on the local 1020 PE. When this code is used, the Rejected Message ID 1021 field must contain the message ID of the rejected "RG 1022 Connect" message. 1024 -ii. ICCP Connection Count Exceeded (0x00010002) 1026 This is used to reject a new incoming ICCP connection 1027 that would cause the local PE's ICCP connection count to 1028 exceed its capabilities. When this code is used, the 1029 Rejected Message ID field must contain the message ID of 1030 the rejected "RG Connect" message. 1032 -iii. Application Connection Count Exceeded (0x00010003) 1034 This is used to reject a new incoming application 1035 connection that would cause the local PE's ICCP 1036 connection count to exceed its capabilities. When this 1037 code is used, the Rejected Message ID field must contain 1038 the message ID of the rejected "RG Connect" message and 1039 the corresponding Application Connect TLV must be 1040 included in the "Optional TLV". 1042 -iv. Application not in RG (0x00010004) 1044 This is used to reject a new incoming application 1045 connection when the local PE doesn't support the 1046 application, or the application is not configured in the 1047 RG. When this code is used, the Rejected Message ID 1048 field must contain the message ID of the rejected "RG 1049 Connect" message and the corresponding Application 1050 Connect TLV must be included in the "Optional TLV". 1052 -v. Incompatible Protocol Version (0x00010005) 1054 This is used to reject a new incoming application 1055 connection when the local PE has an incompatible version 1056 of the application. When this code is used, the Rejected 1057 Message ID field must contain the message ID of the 1058 rejected "RG Connect" message and the corresponding 1059 Application Connect TLV must be included in the 1060 "Optional TLV". 1062 -vi. Rejected Message (0x00010006) 1064 This is used to reject a RG Application Data message, or 1065 one or more TLV(s) within the message. When this code 1066 is used, the Rejected Message ID field must contain the 1067 message ID of the rejected "RG Application Data" 1068 message. 1070 -vii. ICCP Administratively Disabled (0x00010007) 1072 This is used to reject any ICCP messages from a peer 1073 from which the PE is not allowed to exchenge ICCP 1074 messages due to local administrative policy. 1076 - Rejected Message ID 1078 If non-zero, 32-bit value that identifies the peer message to 1079 which the NAK TLV refers. If zero, no specific peer message is 1080 being identified. 1082 - Optional TLV(s) 1084 A set of one or more optional TLVs. If the status code is 1085 "Rejected Message" then this field contains the TLV(s) that were 1086 rejected. If the entire message is rejected, all its TLVs MUST be 1087 present in this field; otherwise, the subset of TLVs that were 1088 rejected MUST be echoed in this field. 1090 If the status code is "Incompatible Protocol Version" then this 1091 field contains the "Requested Protocol Version TLV" defined as 1092 follows: 1094 0 1 2 3 1095 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 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 |U|F| Type=0x0003 | Length | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Connection Reference | Requested Version | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 - U and F Bits 1104 Both are set to 0. 1106 - Type 1108 set to 0x0003 for "Requested Protocol Version TLV" 1110 - Length 1112 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1113 Length fields. 1115 - Connection Reference 1117 This field is set to the Type field of the Application specific 1118 Connect TLV that was rejected because of incompatible version. 1120 - Requested Version 1122 The version of the application supported by the transmitting 1123 device. For this version of the protocol it is set to 0x0001. 1125 7.5. RG Application Data Message 1127 The RG Application Data Message is used to transport application data 1128 between PEs within a RG. A single message can be used to carry data 1129 from multiple applications, as long as all these applications are 1130 part of the same RG. Such multiplexing is possible because the 1131 transported TLVs are application specific which allows for 1132 identifying the target application for each TLV at the receiving 1133 side. The format of the Application Data Message is: 1135 -i. ICC header with Message type = "RG Application Data Message" 1136 (0x703) 1138 -ii. "Application specific TLVs" 1140 The details of these TLVs are discussed in the "Application TLVs" 1141 section. 1143 8. Application TLVs 1145 8.1. Pseudowire Redundancy (PW-RED) Application TLVs 1147 This section discusses the ICCP TLVs for the Pseudowire Redundancy 1148 application. 1150 8.1.1. PW-RED Connect TLV 1152 This TLV is included in the RG Connect message to signal the 1153 establishment of PW-RED application connection. 1155 0 1 2 3 1156 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 |U|F| Type=0x0010 | Length | 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | Protocol Version | Optional Sub-TLVs | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1162 ~ ~ 1163 | | 1164 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | ... | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 - U and F Bits 1170 Both are set to 0. 1172 - Type 1174 set to 0x0010 for "PW-RED Connect TLV" 1176 - Length 1178 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1179 Length fields. 1181 - Protocol Version 1183 The version of this particular protocol for the purposes of ICCP. 1184 This is set to 0x0001. 1186 - Optional Sub-TLVs 1188 There are no optional Sub-TLVs defined for this version of the 1189 protocol. 1191 8.1.2. PW-RED Disconnect TLV 1193 This TLV is used in a RG Disconnect Message to indicate that the 1194 connection for the PW-RED application is to be terminated. 1196 0 1 2 3 1197 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 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 |U|F| Type=0x0011 | Length | 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | Optional Sub-TLVs | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 - U and F Bits 1206 Both are set to 0. 1208 - Type 1210 set to 0x0011 for "PW-RED Disconnect TLV" 1212 - Length 1214 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1215 Length fields. 1217 - Optional Sub-TLVs 1219 There are no optional Sub-TLVs defined for this version of the 1220 protocol. 1222 8.1.3. PW-RED Config TLV 1224 The PW-RED Config TLV is used in RG Application Data message and is 1225 composed of the following TLVs in the following order: 1226 -i. Service Name TLV 1227 -ii. PW ID TLV or Generalized PW ID TLV 1229 In the PW-RED Config TLV the U and F Bits are both are set to 0, and 1230 the TLV type is set to 0x0012. 1232 8.1.4. Service Name TLV 1234 0 1 2 3 1235 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 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 |U|F| Type | Length | 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 | Service Name | 1240 ~ ~ 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 - U and F Bits 1245 Both are set to 0. 1247 - Type 1249 set to 0x0013 for "Service Name TLV" 1251 - Length 1253 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1254 Length fields. 1256 - Service Name 1258 The name of the L2VPN service instance encoded in UTF-8 format 1259 and up to 80 character in length. 1261 8.1.5. PW ID TLV 1263 This TLV is used to communicate the configuration of PWs for VPWS. 1265 0 1 2 3 1266 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 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 |U|F| Type | Length | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Peer ID | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | Group ID | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | PW ID | 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 - U and F Bits 1279 Both are set to 0. 1281 - Type 1283 set to 0x0014 for "PW ID TLV" 1285 - Length 1287 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1288 Length fields. 1290 - Peer ID 1292 Four octet LDP Router ID of the peer at the far end of the PW. 1294 - Group ID 1296 Same as Group ID in [RFC4447] section 5.2. 1298 - PW ID 1300 Same as PW ID in [RFC4447] section 5.2. 1302 8.1.6. Generalized PW ID TLV 1304 This TLV is used to communicate the configuration of PWs for VPLS. 1306 0 1 2 3 1307 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 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 |U|F| Type = 0x0015 | Length | 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 | AGI Type | Length | Value | 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 ~ AGI Value (contd.) ~ 1314 | | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | AII Type | Length | Value | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 ~ SAII Value (contd.) ~ 1319 | | 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 | AII Type | Length | Value | 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 ~ TAII Value (contd.) ~ 1324 | | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 - U and F bits 1329 both set to 0. 1331 - Type 1333 set to 0x0015 1335 - Length 1337 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1338 Length fields. 1340 - AGI, AII, SAII and TAII 1342 defined in [RFC4447] section 5.3.2. 1344 8.2. Multi-chassis LACP (mLACP) Application TLVs 1346 This section discusses the ICCP TLVs for Ethernet attachment circuit 1347 redundancy using the multi-chassis LACP (mLACP) application. 1349 8.2.1. mLACP Connect TLV 1351 This TLV is included in the RG Connect message to signal the 1352 establishment of mLACP application connection. 1354 0 1 2 3 1355 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 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 |U|F| Type=0x0030 | Length | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 | Protocol Version | Optional Sub-TLVs | 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1361 ~ ~ 1362 | | 1363 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 | ... | 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 - U and F Bits 1369 Both are set to 0. 1371 - Type 1373 set to 0x0030 for "mLACP Connect TLV" 1375 - Length 1377 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1378 Length fields. 1380 - Protocol Version 1382 The version of this particular protocol for the purposes of ICCP. 1383 This is set to 0x0001. 1385 - Optional Sub-TLVs 1387 There are no optional Sub-TLVs defined for this version of the 1388 protocol. 1390 8.2.2. mLACP Disconnect TLV 1392 This TLV is used in a RG Disconnect Message to indicate that the 1393 connection for the mLACP application is to be terminated. 1395 0 1 2 3 1396 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 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 |U|F| Type=0x0031 | Length | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | Optional Sub-TLVs | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 - U and F Bits 1405 Both are set to 0. 1407 - Type 1409 set to 0x0031 for "mLACP Disconnect TLV" 1411 - Length 1413 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1414 Length fields. 1416 - Optional Sub-TLVs 1418 There are no optional Sub-TLVs defined for this version of the 1419 protocol. 1421 8.2.3. mLACP System Config TLV 1423 The mLACP System Config TLV is sent in the RG Application Data 1424 message. This TLV announces the local node's LACP System Parameters 1425 to the RG peers. 1427 0 1 2 3 1428 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 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 |U|F| Type=0x0032 | Length | 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | System ID | 1433 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 | | System Priority | 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 | Node ID | 1437 +-+-+-+-+-+-+-+-+ 1439 - U and F Bits 1441 Both are set to 0. 1443 - Type 1445 set to 0x0032 for "mLACP System Config TLV" 1447 - Length 1449 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1450 Length fields. 1452 - System ID 1454 6 octets field encoding the System ID used by LACP as specified 1455 in [IEEE-802.3] section 43.3.2. 1457 - System Priority 1459 2 octets encoding the LACP System Priority as defined in [IEEE- 1460 802.3] section 43.3.2. 1462 - Node ID 1464 One octet, LACP node ID. Used to ensure that the LACP Port IDs 1465 are unique across all devices in a RG. Valid values are in the 1466 range 0 - 7. 1468 8.2.4. mLACP Port Config TLV 1470 The mLACP Port Config TLV is sent in the RG Application Data message. 1471 This TLV is used to notify RG peers about the local configuration 1472 state of a port. 1474 0 1 2 3 1475 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 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 |U|F| Type=0x0033 | Length | 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 | Port Number | MAC Address | 1480 +-------------------------------+ + 1481 | | 1482 +---------------------------------------------------------------+ 1483 | Admin Key | Port Priority | 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 | Flags | IF Name Len | Interface Name | 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1487 ~ ~ 1488 | ... | 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 - U and F Bits 1493 Both are set to 0. 1495 - Type 1497 set to 0x0033 for "mLACP Port Config TLV" 1499 - Length 1501 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1502 Length fields. 1504 - Port Number 1506 Two octets, LACP Port Number for the corresponding interface as 1507 specified in [IEEE-802.3] section 43.3.4. When the value of this 1508 field is 0, it denotes the Aggregator whose key is specified in 1509 the "Admin Key" field. 1511 - MAC Address 1513 Six octets encoding the port MAC address. 1515 - Admin Key 1517 Two octets, LACP Admin key for the corresponding interface, as 1518 specified in [IEEE-802.3] section 43.3.5. 1520 - Port Priority 1522 Two octets, LACP port priority for the corresponding interface, 1523 as specified in [IEEE-802.3] section 43.3.4. This field is valid 1524 only when the "Flags" field has "Priority Set" asserted. 1526 - Flags 1528 Valid values are: 1530 -i. Synchronized (0x01) 1532 Indicates that the sender has concluded transmitting all 1533 member link port configurations for a given Aggregator. 1534 Also, indicates to the receiving device that its local 1535 port priorities will not be overridden. 1537 -ii. Purge Configuration (0x02) 1539 Indicates that the port is no longer configured for 1540 mLACP operation. 1542 -iii. Priority Set (0x04) 1544 Indicates that the "Port Priority" field is valid. 1546 - IF Name Len 1548 One octet, length of the "Interface Name" field in octets. 1550 - Interface Name 1552 Interface name encoded in UTF-8 format, up to a maximum of 20 1553 characters. 1555 8.2.5. mLACP Change Port Priority TLV 1557 The mLACP Port State TLV is used in RG Application Data message. This 1558 TLV is used by a device to authoritatively request that a particular 1559 member of a RG change its port priority. 1561 0 1 2 3 1562 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 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 |U|F| Type=0x0034 | Length | 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | Port Number | Port Key | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | Port Priority | 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 - U and F Bits 1573 Both are set to 0. 1575 - Type 1577 set to 0x0034 for "mLACP Change Port Priority TLV" 1579 - Length 1581 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1582 Length fields. 1584 - Port Number 1586 2 octets field representing the LACP Port Number as specified in 1587 [IEEE-802.3] section 43.3.4. When the value of this field is 0, 1588 it denotes all ports bound to the Aggregator whose key is 1589 specified in the "Port Key" field. 1591 - Port Key 1593 Two octets, LACP port key for the corresponding interface, as 1594 specified in [IEEE-802.3] section 43.3.5. 1596 - Port Priority 1598 Two octets, LACP port priority for the corresponding interface, 1599 as specified in [IEEE-802.3] section 43.3.4. 1601 8.2.6. mLACP Port State TLV 1603 The mLACP Port State TLV is used in RG Application Data message. This 1604 TLV is used by a device to report its LACP port status to other 1605 members in the RG. 1607 0 1 2 3 1608 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 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 |U|F| Type=0x0035 | Length | 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 | Partner System ID | 1613 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 | | Partner System Priority | 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 | Partner Port Number | Partner Port Priority | 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 | Partner Key | Partner State | Actor State | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 | Actor Port Number | Actor Key | 1621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 | Port State | 1623 +-+-+-+-+-+-+-+-+ 1625 - U and F Bits 1627 Both are set to 0. 1629 - Type 1631 set to 0x0035 for "mLACP Port State TLV" 1633 - Length 1635 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1636 Length fields. 1638 - LACP Partner System ID 1640 6 octets, the LACP Partner System ID for the corresponding 1641 interface, encoded as a MAC address as specified in [IEEE-802.3] 1642 section 43.4.2.2 item r. 1644 - LACP Partner System Priority 1646 2 octets field specifying the LACP Partner System Priority as 1647 specified in [IEEE-802.3] section 43.4.2.2 item q. 1649 - LACP Partner Port Number 1651 2 octets encoding the LACP Partner Port Number as specified in 1652 [IEEE-802.3] section 43.4.2.2 item u. 1654 - LACP Partner Port Priority 1656 2 octets field encoding the LACP Partner Port Priority as 1657 specified in [IEEE-802.3] section 43.4.2.2 item t. 1659 - LACP Partner Oper Key 1661 2 octets field representing the LACP Partner Key as defined in 1662 [IEEE-802.3] section 43.4.2.2 item s. 1664 - LACP Partner Oper State 1666 1 octet field encoding the LACP Partner State Variable as defined 1667 in [IEEE-802.3] section 43.4.2.2 item v. 1669 - LACP Actor Oper State 1671 1 octet encoding the LACP Actor's State Variable for the port as 1672 specified in [IEEE-802.3] section 43.4.2.2 item m. 1674 - LACP Actor Port Number 1676 2 octets field representing the LACP Actor Port Number as 1677 specified in [IEEE-802.3] section 43.3.4. When the value of this 1678 field is 0, it denotes the Aggregator whose key is specified in 1679 the "Actor Operational Key" field. 1681 - LACP Actor Oper Key 1683 2 octet field encoding the LACP Actor Operational Key as 1684 specified in [IEEE-802.3] section 43.3.5. 1686 - Port State 1688 1 octet encoding the operational state of the port as follows: 1689 0x00 Up 1690 0x01 Down 1691 0x02 Administrative Down 1692 0x03 Test (e.g. IEEE 802.3ah OAM Intrusive Loopback mode) 1694 9. LDP Capability Negotiation 1696 As requited in [LDP-CAP] the following TLV is defined to indicate the 1697 ICCP capability: 1698 0 1 2 3 1699 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 1700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1701 |U|F| TLV Code Point=0x405 | Length | 1702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1703 |S| Reserved | Reserved | VER/Maj | Ver/Min | 1704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 where: 1708 - U-bit 1710 SHOULD be 1 (ignore if not understood). 1712 - F-bit 1714 SHOULD be 0 (don't forward if not understood). 1716 - TLV Code Point 1718 The TLV type, which identifies a specific capability. For the 1719 ICCP code point is requested in the IANA allocation section 1720 below. 1722 - S-bit The State Bit indicates whether the sender is advertising 1723 or withdrawing the ICCP capability. The State bit is used as 1724 follows: 1725 1 - The TLV is advertising the capability specified by the 1726 TLV Code Point. 1728 0 - The TLV is withdrawing the capability specified by the 1729 TLV Code Point. 1731 - Ver/Maj 1733 The major version revision of the ICCP protocol, this document 1734 specifies 1.0. This field is then set to 1 1736 - Ver/Min 1738 The minor version revision of the ICCP protocol, this document 1739 specifies 1.0. This field is then set to 0 1741 ICCP capability is advertised to a LDP peer if there is at least one 1742 RG enabled on the local PE. 1744 10. Client Applications 1746 10.1. Pseudowire Redundancy Application Procedures 1748 This section defines the procedures for the Pseudowire Redundancy 1749 (PW-RED) Application. 1751 10.1.1. Initial Setup 1753 When a RG is configured on a system and multi-chassis pseudowire 1754 redundancy is enabled in that RG, the PW-RED application should send 1755 an "RG Connect" message with "PW-RED Connect TLV" to each PE that is 1756 member of the same RG. When the system receives similar "RG Connect" 1757 messages from a PE, the two devices can start exchanging "RG 1758 Application Data" messages for the PW-RED application. 1760 If a system receives an "RG Connect" message with "PW-RED Connect 1761 TLV" that has a differing Protocol Version, it must follow the 1762 procedures outlined in the "Application Versioning" section above. 1764 When the PW-RED application is disabled on the device, or is 1765 unconfigured for the RG in question, the system should send an "RG 1766 Disconnect" message with "PW-RED Disconnect TLV". 1768 10.1.2. Pseudowire Configuration 1770 A system should advertise its local PW configuration to other PEs 1771 that are members of the same RG. This allows the PEs to build a view 1772 of the redundant nodes and pseudowires that are protecting the same 1773 service instances. The advertisement should be initiated when the 1774 PW-RED application connection first comes up, as well as upon any 1775 subsequent PW configuration change. To that end, the system should 1776 send "RG Application Data" messages with "PW-RED Config TLV". It is 1777 possible to send configuration information for multiple PWs in a 1778 single "RG Application Data" message. 1780 The "Service Name TLV" is used on the receiving system for the 1781 purpose of associating PW information advertised by some PE with the 1782 corresponding AC information received over ICCP from that PE's AC 1783 redundancy application. The Service Name has a global context in a 1784 RG, so redundant PWs for the same service on disparate member PEs 1785 should share the same Service Name, in order to be correlated. 1787 10.1.3. Pseudowire Status Synchronization 1789 On a given PE, the forwarding status of the PW (Active or Standby) is 1790 derived from the state of the associated AC(s). This simplifies the 1791 operation of the multi-chassis redundancy solution (Figure 1) and 1792 eliminates the possibility of deadlock conditions between the AC and 1793 PW redundancy mechanisms. The rules by which the PW state is derived 1794 from the AC state are as follows: 1796 - VPWS 1798 For VPWS, there's a single AC per service instance. If the AC is 1799 Active, then the PW status should be Active. If the AC is 1800 Standby, then the PW status should be Standby. 1802 - VPLS 1804 For VPLS, there could be multiple ACs per service instance (i.e. 1805 VFI). If AT LEAST ONE AC is Active, then the PW status should be 1806 Active. If ALL ACs are Standby, then the PW status should be 1807 Standby. 1809 The PW-RED application does not synchronize PW status across chassis, 1810 per se. Rather, the AC Redundancy application should synchronize AC 1811 status between chassis, in order to determine which AC (and 1812 subsequently which PE) is Active or Standby for a given service. When 1813 that is determined, each PE will then adjust its local PWs state 1814 according to the rules described above. 1816 10.1.4. PE Node Failure 1818 When a PE node detects that a remote PE, that is member of the same 1819 RG, has gone down, the local PE examines if it has redundant PWs for 1820 the affected services. If the local PE has the highest priority 1821 (after the failed PE) then it becomes the active node for the 1822 services in question, and subsequently activates its associated PWs. 1824 10.2. Attachment Circuit Redundancy Application Procedures 1826 10.2.1. Common AC Procedures 1828 This section describes generic procedures for AC Redundancy 1829 applications, independent of the type of the AC (ATM, FR or 1830 Ethernet). 1832 10.2.2. AC Failure 1834 When the AC Redundancy mechanism on the Active PE detects a failure 1835 of the AC, it should send an ICCP Application Data message to inform 1836 the redundant PEs of the need to take over. The AC failures can be 1837 categorized into the following scenarios: 1839 - Failure of CE interface connecting to PE 1841 - Failure of CE uplink to PE 1843 - Failure of PE interface connecting to CE 1845 10.2.3. PE Node Failure 1847 When a PE node detects that a remote PE, that is member of the same 1848 RG, has gone down, the local PE examines if it has redundant ACs for 1849 the affected services. If the local PE has the highest priority 1850 (after the failed PE) then it becomes the active node for the 1851 services in question, and subsequently activates its associated ACs. 1853 10.2.4. PE Isolation 1855 When a PE node detects that is has been isolated from the core 1856 network (i.e. all core facing interfaces/links are not operational), 1857 then it should instruct its AC Redundancy mechanism to change the 1858 status of any active ACs to Standby. The AC Redundancy application 1859 should then send ICCP Application Data messages in order to trigger 1860 failover to a standby PE. 1862 10.2.5. ATM AC Procedures 1864 10.2.6. Frame Relay AC Procedures 1866 10.2.7. Ethernet AC Procedures 1868 10.2.8. Multi-chassis LACP (mLACP) Application Procedures 1870 This section defines the procedures that are specific to the multi- 1871 chassis LACP (mLACP) application. 1873 10.2.8.1. Initial Setup 1875 When a RG is configured on a system and mLACP is enabled in that RG, 1876 the mLACP application should send an "RG Connect" message with "mLACP 1877 Connect TLV" to each PE that is member of the same RG. When the 1878 system receives similar "RG Connect" message from a PE, the two 1879 devices can start exchanging "RG Application Data" messages for the 1880 mLACP application. 1882 If a system receives an "RG Connect" message with "mLACP Connect TLV" 1883 that has a differing Protocol Version, it must follow the procedures 1884 outlined in the "Application Versioning" section above. 1886 After the mLACP application connection has been established, every PE 1887 must communicate its system level configuration to its peers via the 1888 use of "mLACP System Config TLV". This allows every PE to discover 1889 the Node ID and the locally configured System ID and System Priority 1890 values of its peers. It is necessary for all PEs in a RG to agree 1891 upon the System ID and System Priority values to be used 1892 ubiquitously. To achieve this, every PE MUST use the numerically 1893 lowest value (among RG members) for each of the two parameters. This 1894 guarantees that the PEs always agree on uniform values, which yield 1895 the highest System Priority. 1897 When the mLACP application is disabled on the device, or is 1898 unconfigured for the RG in question, the system should send an "RG 1899 Disconnect" message with "mLACP Disconnect TLV". 1901 10.2.8.2. mLACP Port Configuration 1903 A system must synchronize the configuration of its mLACP operating 1904 ports with other RG members. To that end, a system must use the "Port 1905 Config TLVs". An implementation must advertise the configuration of 1906 Aggregators prior to advertising the configuration of any of their 1907 associated member links. Aggregators are identified by using the Port 1908 Number 0 (which is not a valid LACP port number) and the associated 1909 Key. If the "Priority Set" flag is asserted in such TLV, it indicates 1910 that the same Port Priority applies to all member links that are 1911 attached to the Aggregator in question. When the configuration of all 1912 ports for member links associated with a given Aggregator has been 1913 sent by a device, it asserts that fact by setting the "Synchronized" 1914 flag in the last port's "Port Config TLV". This also serves as a cue 1915 for the receiving system that its local port priorities will not be 1916 remotely overridden by the sending PE. 1918 Furthermore, for a given port, an implementation must advertise the 1919 port's configuration prior to advertising its state (via the "mLACP 1920 Port State TLV"). 1922 When mLACP is unconfigured on a port, a PE must send a "Port Config 1923 TLV" with the "Purge Configuration" flag asserted. This allows 1924 receiving PEs to purge any state maintained for the decommissioned 1925 port. 1927 10.2.8.3. mLACP Port Status Synchronization 1929 PEs within a RG need to synchronize their state-machines for proper 1930 mLACP operation with a multi-homed device. This is achieved by having 1931 each system advertise its ports' running state in "mLACP Port State 1932 TLVs". Whenever any port parameter, whether on the Partner (i.e. 1933 multi-homed device) or the Actor (i.e. PE) side, is changed a system 1934 MUST transmit an updated "mLACP Port State TLV" for the affected 1935 port. 1937 10.2.8.4. Triggering Failover 1939 A PE MAY trigger a failover to a redundant PE within the RG by 1940 sending an "mLACP Change Port Priority TLV" specifying the affected 1941 Aggregator and a priority value that causes the remote PE to have a 1942 higher Port Priority thereby moving to active forwarding state. 1944 A PE MAY assume active role within the RG by sending an "mLACP Change 1945 Port Priority TLV" to the currently active PE, specifying the 1946 affected Aggregator and a port priority value that is less than its 1947 local port priority for the links associated with that Aggregator. 1949 11. Security Considerations 1951 The security considerations described in [RFC5036] and [RFC4447] that 1952 apply to the base LDP specification, and to the PW LDP control 1953 protocol extensions apply to the capability mechanism described in 1954 this document. 1956 The ICCP protocol is not intended to be applicable when the 1957 redundancy group spans PE in different administrative domains. 1958 Furthermore, implementations MUST provide a mechanism to select to 1959 which LDP peers the ICCP capability will be advertised, and from wich 1960 LDP peers the ICCP messages will be accepted. 1962 12. IANA Considerations 1964 12.1. MESSAGE TYPE NAME SPACE 1966 This document uses several new LDP message types, IANA already 1967 maintains a registry of name "MESSAGE TYPE NAME SPACE" defined by 1968 [RFC5036]. The following values are suggested for assignment: 1970 Message type Description 1971 0x0700 RG Connect Message 1972 0x0701 RG Disconnect Message 1973 0x0702 RG Notification Message 1974 0x0703 RG Application Data Message 1976 12.2. TLV TYPE NAME SPACE 1978 This document use a new LDP TLV type, IANA already maintains a 1979 registry of name "TLV TYPE NAME SPACE" defined by [RFC5036]. The 1980 following value is suggested for assignment: 1981 TLV Type Description 1982 0x700 ICCP capability TLV. 1983 0x701 LDP TCP/IP Port TLV. 1985 12.3. ICC RG Parameter Type Space 1987 IANA needs to set up a registry of "ICC RG parameter type". These are 1988 14-bit values. Parameter Type values 1 through 0x000F are specified 1989 in this document, Parameter Type values 0x0010 through 0x1FFF are to 1990 be assigned by IANA, using the "Expert Review" policy defined in 1991 [RFC5226]. Parameter Type values 0x2000 through 0x2FFF, 0x3FFF, and 0 1992 are to be allocated using the IETF consensus policy defined in 1993 [RFC5226]. Parameter Type values 0x3000 through 0x3FFE are reserved 1994 for vendor proprietary extensions and are to be assigned by IANA, 1995 using the "First Come First Served" policy defined in [RFC5226]. A 1996 Parameter Type description is required for any assignment from this 1997 registry. Additionally, for the vendor proprietary extensions range a 1998 citation of a person or company name is also required. A document 1999 reference should also be provided. 2001 Initial ICC RG parameter type space value allocations are specified 2002 below: 2004 Parameter Type Description Reference 2005 -------------- --------------------------------- --------- 2006 0x0001 ICC sender name [RFCxxxx] 2007 0x0002 NAK TLV [RFCxxxx] 2008 0x0003 Requested Protocol Version TLV [RFCxxxx] 2009 0x0004 Disconnect Code TLV [RFCxxxx] 2010 0x0005 ICC RG ID TLV [RFCxxxx] 2012 0x0010 PW-RED Connect TLV [RFCxxxx] 2013 0x0011 PW-RED Disconnect TLV [RFCxxxx] 2014 0x0012 PW-RED Config TLV [RFCxxxx] 2015 0x0013 Service Name TLV [RFCxxxx] 2016 0x0014 PW ID TLV [RFCxxxx] 2017 0x0015 Generalized PW ID TLV [RFCxxxx] 2019 0x0030 mLACP Connect TLV [RFCxxxx] 2020 0x0031 mLACP Disconnect TLV [RFCxxxx] 2021 0x0032 mLACP System Config TLV [RFCxxxx] 2022 0x0033 mLACP Port Config TLV [RFCxxxx] 2023 0x0034 mLACP Change Port Priority TLV [RFCxxxx] 2024 0x0035 mLACP Port State TLV [RFCxxxx] 2026 12.4. STATUS CODE NAME SPACE 2028 This document use several new Status codes, IANA already maintains a 2029 registry of name "STATUS CODE NAME SPACE" defined by [RFC5036]. The 2030 following values is suggested for assignment: The "E" column is the 2031 required setting of the Status Code E-bit. 2032 Range/Value E Description Reference 2033 ------------- ----- ---------------------- --------- 2034 0x00010001 0 Unknown ICCP RG 2035 0x00010002 0 ICCP Connection Count Exceeded 2036 0x00010003 0 ICCP Application Connection 2037 Count Exceeded 2038 0x00010004 0 ICCP Application not in RG 2039 0x00010005 0 Incompatible ICCP Protocol Version 2040 0x00010006 0 ICCP Rejected Message 2041 0x00010007 0 ICCP Administratively Disabled 2042 0x00010010 0 ICCP RG Removed 2043 0x00010011 0 ICCP Application Removed from RG 2045 13. Normative References 2047 [RFC5036] L. Andersson et al, "LDP Specification", RFC 5036, 2048 October 2007. 2050 [LDP-CAP] "LDP Capabilities", draft-ietf-mpls-ldp-capabilities-02.txt 2051 April 2008, (Work in Progress) 2053 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., 2054 et al., rfc4447 April 2006. 2056 [IEEE-802.3] IEEE Std. 802.3-2005, "Part 3: Carrier Sense Multiple 2057 Access with Collision Detection (CSMA/CD) Access Method and 2058 Physical Layer Specifications", IEEE Computer Society, December 2059 2005. 2061 14. Informative References 2063 [BFD] D. Katz, D. Ward, "Bidirectional Forwarding Detection", 2064 draft-ietf-bfd-base-09.txt, February 2009 (Work in Progress) 2066 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2067 IANA Considerations section in RFCs", BCP 26, RFC 5226, May 2008 2069 15. Author's Addresses 2071 Luca Martini 2072 Cisco Systems, Inc. 2073 9155 East Nichols Avenue, Suite 400 2074 Englewood, CO, 80112 2075 e-mail: lmartini@cisco.com 2077 Samer Salam 2078 Cisco Systems, Inc. 2079 595 Burrard Street, Suite 2123 2080 Vancouver, BC V7X 1J1 2081 Canada 2082 e-mail: ssalam@cisco.com 2083 Ali Sajassi 2084 Cisco Systems, Inc. 2085 170 West Tasman Drive 2086 San Jose, CA 95134 2087 e-mail: sajassi@cisco.com 2089 Satoru Matsushima 2090 Softbank Telecom 2091 1-9-1, Higashi-Shinbashi, Minato-ku 2092 Tokyo 105-7313, JAPAN 2093 e-mail: satoru.matsushima@tm.softbank.co.jp 2095 Thomas D. Nadeau 2096 BT 2097 BT Centre 2098 81 Newgate Street 2099 London, EC1A 7AJ 2100 United Kingdom 2101 e-mail: tom.nadeau@bt.com 2103 Full Copyright Statement 2105 Copyright (c) 2009 IETF Trust and the persons identified as the 2106 document authors. All rights reserved. 2108 This document is subject to BCP 78 and the IETF Trust's Legal 2109 Provisions Relating to IETF Documents in effect on the date of 2110 publication of this document (http://trustee.ietf.org/licenseinfo). 2111 Please review these documents carefully, as they describe your rights 2112 and restrictions with respect to this document. 2114 This document may contain material from IETF Documents or IETF 2115 Contributions published or made publicly available before November 2116 10, 2008. The person(s) controlling the copyright in some of this 2117 material may not have granted the IETF Trust the right to allow 2118 modifications of such material outside the IETF Standards Process. 2119 Without obtaining an adequate license from the person(s) controlling 2120 the copyright in such materials, this document may not be modified 2121 outside the IETF Standards Process, and derivative works of it may 2122 not be created outside the IETF Standards Process, except to format 2123 it for publication as an RFC or to translate it into languages other 2124 than English. 2126 Acknowledgments 2128 The authors wish to acknowledge the contributions of Satoru 2129 Matsushima, Wei Luo, Neil Mcgill, Skip Booth, Neil Hart, Michael Hua, 2130 and Tiberiu Grigoriu. 2132 Expiration Date: August 2009