idnits 2.17.1 draft-ietf-pwe3-iccp-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 82 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 27, 2014) is 3683 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) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.1AX' ** Downref: Normative reference to an Informational RFC: RFC 5920 ** Downref: Normative reference to an Informational RFC: RFC 6952 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-10) exists of draft-ietf-mpls-ldp-hello-crypto-auth-02 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Luca Martini 3 Internet Draft Samer Salam 4 Intended status: Standards Track Ali Sajassi 5 Expires: September 27, 2014 Cisco 7 Matthew Bocci Satoru Matsushima 8 Alcatel-Lucent Softbank 10 Thomas Nadeau 11 Brocade 12 March 27, 2014 14 Inter-Chassis Communication Protocol for L2VPN PE Redundancy 16 draft-ietf-pwe3-iccp-16.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 September 27, 2014 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 .................... 13 65 4.2 RG Membership Management ............................. 13 66 4.2.1 ICCP Connection State Machine ........................ 14 67 4.3 Redundant Object Identification ...................... 17 68 4.4 Application Connection Management .................... 17 69 4.4.1 Application Versioning ............................... 18 70 4.4.2 Application Connection State Machine ................. 19 71 4.5 Application Data Transfer ............................ 22 72 4.6 Dedicated Redundancy Group LDP session ............... 22 73 5 ICCP PE Node Failure / Isolation Detection Mechanism . 23 74 6 ICCP Message Formats ................................. 24 75 6.1 Encoding ICC into LDP Messages ...................... 24 76 6.1.1 ICC Header ........................................... 24 77 6.1.2 ICC Parameter Encoding ............................... 26 78 6.1.3 Redundant Object Identifier Encoding ................. 27 79 6.2 RG Connect Message ................................... 28 80 6.2.1 ICC Sender Name TLV .................................. 29 81 6.3 RG Disconnect Message ................................ 29 82 6.4 RG Notification Message .............................. 32 83 6.4.1 Notification Message TLVs ............................ 32 84 6.5 RG Application Data Message .......................... 36 85 7 Application TLVs ..................................... 36 86 7.1 Pseudowire Redundancy (PW-RED) Application TLVs ...... 36 87 7.1.1 PW-RED Connect TLV ................................... 36 88 7.1.2 PW-RED Disconnect TLV ................................ 37 89 7.1.2.1 PW-RED Disconnect Cause TLV .......................... 38 90 7.1.3 PW-RED Config TLV .................................... 39 91 7.1.3.1 Service Name TLV ..................................... 41 92 7.1.3.2 PW ID TLV ............................................ 42 93 7.1.3.3 Generalized PW ID TLV ................................ 43 94 7.1.4 PW-RED State TLV ..................................... 44 95 7.1.5 PW-RED Synchronization Request TLV ................... 45 96 7.1.6 PW-RED Synchronization Data TLV ...................... 47 97 7.2 Multi-chassis LACP (mLACP) Application TLVs .......... 48 98 7.2.1 mLACP Connect TLV .................................... 48 99 7.2.2 mLACP Disconnect TLV ................................. 49 100 7.2.2.1 mLACP Disconnect Cause TLV ........................... 50 101 7.2.3 mLACP System Config TLV .............................. 50 102 7.2.4 mLACP Aggregator Config TLV .......................... 51 103 7.2.5 mLACP Port Config TLV ................................ 53 104 7.2.6 mLACP Port Priority TLV .............................. 55 105 7.2.7 mLACP Port State TLV ................................. 57 106 7.2.8 mLACP Aggregator State TLV ........................... 59 107 7.2.9 mLACP Synchronization Request TLV .................... 61 108 7.2.10 mLACP Synchronization Data TLV ....................... 63 109 8 LDP Capability Negotiation ........................... 64 110 9 Client Applications .................................. 65 111 9.1 Pseudowire Redundancy Application Procedures ......... 65 112 9.1.1 Initial Setup ........................................ 66 113 9.1.2 Pseudowire Configuration Synchronization ............. 66 114 9.1.3 Pseudowire Status Synchronization .................... 67 115 9.1.3.1 Independent Mode ..................................... 68 116 9.1.3.2 Master/Slave Mode .................................... 69 117 9.1.4 PE Node Failure or Isolation ......................... 69 118 9.2 Attachment Circuit Redundancy Application Procedures . 70 119 9.2.1 Common AC Procedures ................................. 70 120 9.2.1.1 AC Failure ........................................... 70 121 9.2.1.2 Remote PE Node Failure or Isolation .................. 70 122 9.2.1.3 Local PE Isolation ................................... 70 123 9.2.1.4 Determining Pseudowire State ......................... 71 124 9.2.2 Multi-chassis LACP (mLACP) Application Procedures .... 71 125 9.2.2.1 Initial Setup ........................................ 71 126 9.2.2.2 mLACP Aggregator and Port Configuration .............. 73 127 9.2.2.3 mLACP Aggregator and Port Status Synchronization ..... 74 128 9.2.2.4 Failure and Recovery ................................. 76 129 10 Security Considerations .............................. 77 130 11 Manageability Considerations ......................... 78 131 12 IANA Considerations .................................. 78 132 12.1 MESSAGE TYPE NAME SPACE .............................. 78 133 12.2 TLV TYPE NAME SPACE .................................. 78 134 12.3 ICC RG Parameter Type Space .......................... 79 135 12.4 STATUS CODE NAME SPACE ............................... 80 136 13 Acknowledgments ...................................... 80 137 14 Normative References ................................. 80 138 15 Informative References ............................... 81 139 16 Author's Addresses ................................... 81 141 1. Specification of Requirements 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119. 147 2. Introduction 149 Network availability is a critical metric for service providers as it 150 has a direct bearing on their profitability. Outages translate not 151 only to lost revenue but also to potential penalties mandated by 152 contractual agreements with customers running mission-critical 153 applications that require tight SLAs. This is true for any carrier 154 network, and networks employing Layer 2 Virtual Private Network 155 (L2VPN) technology are no exception. Network high-availability can 156 be achieved by employing intra and inter-chassis redundancy 157 mechanisms. The focus of this document is on the latter. The document 158 defines an Inter-Chassis Communication Protocol (ICCP) that allows 159 synchronization of state and configuration data between a set of two 160 or more Provider Edge nodes (PEs) forming a Redundancy Group (RG). 161 The protocol supports multi-chassis redundancy mechanisms that can be 162 employed on either the attachment circuits or pseudowires. A formal 163 definition of the term chassis can be found in [RFC2922]. For the 164 purpose of this document, a chassis is an L2VPN PE node. 166 This document assumes that it is normal to run the Label Distribution 167 Protocol (LDP) between the PEs in the RG, and that LDP components 168 will in any case be present on the PEs to establish and maintain 169 pseudowires. Therefore, ICCP is built as a secondary protocol running 170 within LDP and taking advantage of the LDP session mechanisms and the 171 underlying TCP and TCP-based security mechanisms already necessary 172 for LDP operation. 174 3. ICCP Overview 176 3.1. Redundancy Model & Topology 178 The focus of this document is on PE node redundancy. It is assumed 179 that a set of two or more PE nodes are designated by the operator to 180 form a Redundancy Group (RG). Members of a Redundancy Group fall 181 under a single administration (e.g. service provider) and employ a 182 common redundancy mechanism towards the access (attachment circuits 183 or access pseudowires) and/or towards the core (pseudowires) for any 184 given service instance. It is possible, however, for members of an RG 185 to make use of disparate redundancy mechanisms for disjoint services. 186 The PE devices may be offering any type of L2VPN service, i.e. VPWS 187 or VPLS. As a matter of fact, the use of ICCP may even be applicable 188 for Layer 3 service redundancy, but this is considered to be outside 189 the scope of this document. 191 The PEs in an RG offer multi-homed connectivity to either individual 192 devices (e.g. CE, DSLAM, etc...) or entire networks (e.g. access 193 network). Figure 1 below depicts the model. 195 +=================+ 196 | | 197 Mutli-homed +----+ | +-----+ | 198 Node ------------> | CE |-------|--| PE1 ||<------|---Pseudowire-->| 199 | |--+ -|--| ||<------|---Pseudowire-->| 200 +----+ | / | +-----+ | 201 | / | || | 202 |/ | || ICCP |--> Towards Core 203 +-------------+ / | || | 204 | | /| | +-----+ | 205 | Access |/ +----|--| PE2 ||<------|---Pseudowire-->| 206 | Network |-------|--| ||<------|---Pseudowire-->| 207 | | | +-----+ | 208 | | | | 209 +-------------+ | Redundancy | 210 ^ | Group | 211 | +=================+ 212 | 213 Multi-homed Network 215 Figure 1: Generic Multi-chassis Redundancy Model 217 In the topology of Figure 1, the redundancy mechanism employed 218 towards the access node/network can be one of a multitude of 219 technologies, e.g. it could be IEEE 802.1AX Link Aggregation Groups 220 with Link Aggregation Control Protocol (LACP), or SONET APS. The 221 specifics of the mechanism are out of the scope of this document. 222 However, it is assumed that the PEs in the RG are required to 223 communicate amongst each other in order for the access redundancy 224 mechanism to operate correctly. As such, it is required to run an 225 inter-chassis communication protocol among the PEs in the RG in order 226 to synchronize configuration and/or running state data. 228 Furthermore, the presence of the inter-chassis communication channel 229 allows simplification of the pseudowire redundancy mechanism. This is 230 primarily because it allows the PEs within an RG to run some 231 arbitration algorithm to elect which pseudowire(s) should be in 232 active or standby mode for a given service instance. The PEs can then 233 advertise the outcome of the arbitration to the remote-end PE(s), as 234 opposed to having to embed a hand-shake procedure into the pseudowire 235 redundancy status communication mechanism, and every other possible 236 Layer 2 status communication mechanism. 238 3.2. ICCP Interconnect Scenarios 240 When referring to 'interconnect' in this section, we are concerned 241 with the links or networks over which Inter-Chassis Communication 242 Protocol messages are transported, and not normal data traffic 243 between PEs. The PEs which are members of an RG may be either 244 physically co-located or geo-redundant. Furthermore, the physical 245 interconnect between the PEs over which ICCP is to run may comprise 246 of either dedicated back-to-back links or a shared connection through 247 the packet switched network (PSN); for e.g., MPLS core network. This 248 gives rise to a matrix of four interconnect scenarios, described 249 next. 251 3.2.1. Co-located Dedicated Interconnect 253 In this scenario, the PEs within an RG are co-located in the same 254 physical location, e.g. point of presence (POP) or central office 255 (CO). Furthermore, dedicated links provide the interconnect for ICCP 256 among the PEs. 258 +=================+ +-----------------+ 259 |CO | | | 260 | +-----+ | | | 261 | | PE1 |________|_____| | 262 | | | | | | 263 | +-----+ | | | 264 | || | | | 265 | || ICCP | | Core | 266 | || | | Network | 267 | +-----+ | | | 268 | | PE2 |________|_____| | 269 | | | | | | 270 | +-----+ | | | 271 | | | | 272 +=================+ +-----------------+ 274 Figure 2: ICCP Co-located PEs Dedicated Interconnect Scenario 276 Given that the PEs are connected back-to-back in this case, it is 277 possible to rely on Layer 2 redundancy mechanisms to guarantee the 278 robustness of the ICCP interconnect. For example, if the interconnect 279 comprises of IEEE 802.3 Ethernet links, it is possible to provide 280 link redundancy by means of IEEE 802.1AX Link Aggregation Groups. 282 3.2.2. Co-located Shared Interconnect 284 In this scenario, the PEs within an RG are co-located in the same 285 physical location (POP, CO). However, unlike the previous scenario, 286 there are no dedicated links between the PEs. The interconnect for 287 ICCP is provided through the core network to which the PEs are 288 connected. Figure 3 depicts this model. 290 +=================+ +-----------------+ 291 |CO | | | 292 | +-----+ | | | 293 | | PE1 |________|_____| | 294 | | |<=================+ | 295 | +-----+ ICCP | | || | 296 | | | || | 297 | | | || Core | 298 | | | || Network | 299 | +-----+ | | || | 300 | | PE2 |________|_____| || | 301 | | |<=================+ | 302 | +-----+ | | | 303 | | | | 304 +=================+ +-----------------+ 306 Figure 3: ICCP Co-located PEs Shared Interconnect Scenario 308 Given that the PEs in the RG are connected over the packet switched 309 network (PSN), then PSN Layer mechanisms can be leveraged to ensure 310 the resiliency of the interconnect against connectivity failures. For 311 example, it is possible to employ RSVP LSPs with Fast Re-Route (FRR) 312 and/or end-to-end backup LSPs. 314 3.2.3. Geo-redundant Dedicated Interconnect 316 In this variation, the PEs within a Redundancy Group are located in 317 different physical locations to provide geographic redundancy. This 318 may be desirable, for example, to protect against natural disasters 319 or the like. A dedicated interconnect is provided to link the PEs, 320 which is a costly option, especially when considering the possibility 321 of providing multiple such links for interconnect robustness. The 322 resiliency mechanisms for the interconnect are similar to those 323 highlighted in the co-located interconnect counterpart. 325 +=================+ +-----------------+ 326 |CO 1 | | | 327 | +-----+ | | | 328 | | PE1 |________|_____| | 329 | | | | | | 330 | +-----+ | | | 331 +=====||==========+ | | 332 || ICCP | Core | 333 +=====||==========+ | Network | 334 | +-----+ | | | 335 | | PE2 |________|_____| | 336 | | | | | | 337 | +-----+ | | | 338 |CO 2 | | | 339 +=================+ +-----------------+ 341 Figure 4: ICCP Geo-redundant PEs Dedicated Interconnect Scenario 343 3.2.4. Geo-redundant Shared Interconnect 345 In this scenario, the PEs of an RG are located in different physical 346 locations and the interconnect for ICCP is provided over the PSN 347 network to which the PEs are connected. This interconnect option is 348 more likely to be the one used for geo-redundancy as it is more 349 economically appealing compared to the geo-redundant dedicated 350 interconnect. The resiliency mechanisms that can be employed to 351 guarantee the robustness of the ICCP transport are PSN Layer 352 mechanisms as has been described in the "Co-located Shared 353 Interconnect" section above. 355 +=================+ +-----------------+ 356 |CO 1 | | | 357 | +-----+ | | | 358 | | PE1 |________|_____| | 359 | | |<=================+ | 360 | +-----+ ICCP | | || | 361 +=================+ | || | 362 | || Core | 363 +=================+ | || Network | 364 | +-----+ | | || | 365 | | PE2 |________|_____| || | 366 | | |<=================+ | 367 | +-----+ | | | 368 |CO 2 | | | 369 +=================+ +-----------------+ 371 Figure 5: ICCP Geo-redundant PEs Shared Interconnect Scenario 373 3.3. ICCP Requirements 375 The requirements for the Inter-chassis Communication Protocol are as 376 follows: 378 -i. ICCP MUST Provide a control channel for communication 379 between PEs in a Redundancy Group (RG). PE nodes may be co- 380 located or remote (refer to "Interconnect Scenarios" section 381 above). Client applications which make use of ICCP services 382 MUST only use this channel to communicate control 383 information and not data-traffic. As such the protocol 384 SHOULD cater for relatively low bandwidth, low-delay and 385 highly reliable message transfer. 387 -ii. ICCP MUST accommodate multiple client applications (e.g. 388 multi-chassis LACP, PW redundancy, SONET APS, etc...). This 389 implies that the messages SHOULD be extensible (e.g. TLV- 390 based) and the protocol SHOULD provide a robust application 391 registration and versioning scheme. 393 -iii. ICCP MUST provide reliable message transport and in-order 394 delivery between nodes in a RG with secure authentication 395 mechanisms built into the protocol. The redundancy 396 applications that are clients of ICCP expect reliable 397 message transfer, and as such will assume that the protocol 398 takes care of flow-control and retransmissions. Furthermore, 399 given that the applications will rely on ICCP to communicate 400 data used to synchronize state-machines on disparate nodes, 401 it is critical that ICCP guarantees in-order message 402 delivery. Loss of messages or out-of-sequence messages would 403 have adverse side-effects to the operation of the client 404 applications. 406 -iv. ICCP MUST provide a common mechanism to actively monitor the 407 health of PEs in an RG. This mechanism will be used to 408 detect PE node failure (or isolation from the MPLS network 409 in case of shared interconnect), and inform the client 410 applications. The applications require this to trigger 411 failover according to the procedures of the employed 412 redundancy protocol on the AC and PW. The solution SHOULD 413 achieve sub-second detection of loss of remote node (~ 50 - 414 150 msec) in order to give the client applications 415 (redundancy mechanisms) enough reaction time to achieve 416 sub-second service restoration time.s 418 -v. ICCP SHOULD provide asynchronous event-driven state update, 419 independent of periodic messages, for immediate notification 420 of client applications' state changes. In other words, the 421 transmission of messages carrying application data SHOULD be 422 on-demand rather than timer-based to minimize inter-chassis 423 state synchronization delay. 425 -vi. ICCP MUST accommodate multi-link and multi-hop interconnect 426 between nodes. When the devices within an RG are located in 427 different physical locations, the physical interconnect 428 between them will comprise of a network rather than a link. 429 As such, ICCP MUST accommodate the case where the 430 interconnect involves multiple hops. Furthermore, it is 431 possible to have multiple (redundant) paths or interconnects 432 between a given pair of devices. This is true for both the 433 co-located and geo-redundant scenarios. ICCP MUST handle 434 this as well. 436 -vii. ICCP MUST ensure transport security between devices in an 437 RG. This is especially important in the scenario where the 438 members of an RG are located in different physical locations 439 and connected over a shared network (e.g. PSN). In 440 particular, ICCP MUST NOT accept connections arbitrarily 441 from any device; otherwise, the state of client applications 442 might be compromised. Furthermore, even if an ICCP 443 connection request appears to come from an eligible device, 444 its source address may have been spoofed. Therefore, some 445 means of preventing source address spoofing MUST be in 446 place. 448 -viii. ICCP MUST allow the operator to statically configure members 449 of RG. Auto-discovery may be considered in the future. 451 -ix. ICCP SHOULD allow for flexible RG membership. It is expected 452 that only two nodes per an RG will cover most of the 453 redundancy applications for common deployments. ICCP SHOULD 454 NOT preclude supporting more than two nodes in an RG by 455 virtue of design. Furthermore, ICCP MUST allow a single node 456 to be member of multiple RGs simultaneously. 458 4. ICC LDP Protocol Extension Specification 460 To address the requirements identified in the previous section, ICCP 461 is modeled to comprise of three layers: 463 -i. Application Layer: This provides the interface to the 464 various redundancy applications that make use of the 465 services of ICCP. ICCP is concerned with defining common 466 connection management procedures and the formats of the 467 messages exchanged at this layer; however, beyond that, it 468 does not impose any restrictions on the procedures or 469 state-machines of the clients, as these are deemed 470 application-specific and lie outside the scope of ICCP. 471 This guarantees implementation inter-operability without 472 placing any unnecessary constraints on internal design 473 specifics. 475 -ii. Inter Chassis Communication (ICC) Layer: This layer 476 implements the common set of services which ICCP offers to 477 the client applications. It handles protocol versioning, RG 478 membership, Redundant Object identification, PE node 479 identification and ICCP connection management. 481 -iii. Transport Layer: This layer provides the actual ICCP message 482 transport. It is responsible for addressing, route 483 resolution, flow-control, reliable and in-order message 484 delivery, connectivity resiliency/redundancy and finally PE 485 node failure detection. The Transport layer may differ 486 depending on the Physical Layer of the inter-connect. 488 4.1. LDP ICCP Capability Advertisement 490 When an RG is enabled on a particular PE, an LDP session MUST be 491 created to every remote PE in that RG, if one does not already exist. 492 Then, the capability of supporting ICCP MUST be advertised to all 493 those LDP peers in that RG. This is achieved by using the methods in 494 [RFC5561] and advertising the ICCP LDP capability TLV. If an LDP peer 495 supports the dynamic capability advertisement, this can be done by 496 sending a new capability message with the S bit set for the ICCP 497 capability TLV when the first RG is enabled on the PE. If the peer 498 does not support dynamic capability advertisement, then the ICCP TLV 499 MUST be included in the LDP initialization procedures in the 500 capability parameter [RFC5561]. 502 4.2. RG Membership Management 504 ICCP defines a mechanism that enables PE nodes to manage their RG 505 membership. When a PE is configured to be a member of an RG, it will 506 first advertise the ICCP capability to its peers. Subsequently, the 507 PE sends an RG Connect message to the peers that have also advertised 508 ICCP capability. The PE then waits for the peers to send their own RG 509 Connect messages, if they haven't done so already. For a given RG, 510 the ICCP connection between two devices is considered to be 511 operational only when both have sent and received ICCP RG Connect 512 messages for that RG. 514 If a PE that has sent a particular RG Connect message doesn't receive 515 a corresponding RG Connect (or a Notification message rejecting the 516 connection) from a destination, it will remain in a state expecting 517 the corresponding RG Connect message (or Notification message). The 518 RG will not become operational until the corresponding RG Connect 519 Message has been received. If a PE that has sent an RG Connect 520 message receives a Notification message rejecting the connection, 521 with a NAK TLV (section 6.4.1), it will stop attempting to bring up 522 the ICCP connection immediately. 524 A device MUST reject an incoming RG Connect message if at least one 525 of the following conditions is satisfied: 527 -i. the PE is not a member of the RG; 529 -ii. the maximum number of simultaneous ICCP connections that the 530 PE can handle is exceeded. 532 Otherwise, the PE MUST bring up the connection by responding to the 533 incoming RG Connect message with an appropriate RG Connect. 535 A PE sends an RG Disconnect message to tear down the ICCP connection 536 for a given RG. This is a unilateral operation and doesn't require 537 any acknowledgement from the other PEs. Note that the ICCP connection 538 for an RG MUST be operational before any client application can make 539 use of ICCP services in that RG. 541 4.2.1. ICCP Connection State Machine 543 A PE maintains an ICCP Connection State Machine instance for every 544 ICCP connection with a remote peer in the RG. This state machine is 545 separate from any Application Connection State Machine (section 546 4.4.2). The ICCP Connection State Machine reacts only to RG Connect, 547 RG Disconnect and RG Notification messages that do not contain any 548 Application TLVs. Actions and state transitions in the Application 549 Connection state machines have no effect on the ICCP Connection State 550 Machine. 552 The ICCP Connection state machine is defined to have six states as 553 follows: 555 -NON EXISTENT: This state is the starting point for the state 556 machine.It indicates that no ICCP connection exists and that 557 there's no LDP session established between the PEs. 559 -INITIALIZED: This state indicates that an LDP session exists between 560 the PEs but LDP ICCP Capabilitiy have not yet been exchanged between 561 them. 563 -CAPSENT: This state indicates that an LDP session exists between the 564 PEs and that the local PE has avertized LDP ICCP Capability to its 565 peer. 567 -CAPREC: This state indicates that an LDP session exists between the 568 PEs and that the local PE has both received and avertized LDP ICCP 569 Capability from/to its peer. 571 -CONNECTING: This state indicates that the local PE has initiated 572 an ICCP connection to its peer, and is awaiting its response. 574 -OPERATIONAL: This state indicates that the ICCP connection is 575 operational. 577 The state transition table and state transition diagram follow. 579 ICCP Connection State Transition Table 580 STATE EVENT NEW STATE 582 NON EXISTENT LDP session established INITIALIZED 584 INITIALIZED Transmit LDP ICCP Capability CAPSENT 586 Receive LDP ICCP Capability CAPREC 587 Action: Transmit LDP ICCP Capability 589 LDP session torn down NON EXISTENT 591 CAPSENT Receive LDP ICCP Capability CAPREC 593 LDP session torn down NON EXISTENT 595 CAPREC Transmit RG Connect Message CONNECTING 597 Receive acceptable RG Connect Message OPERATIONAL 598 Action: Transmit RG Connect Message 600 Receive any other ICCP Message CAPREC 601 Action: Transmit NAK TLV in RG 602 Notification Message 604 LDP session torn down NON EXISTENT 606 CONNECTING Receive acceptable RG Connect Message OPERATIONAL 608 Receive any other ICCP Message CAPREC 609 Action: Transmit NAK TLV in RG 610 Notification Message 612 LDP session torn down NON EXISTENT 614 OPERATIONAL Receive acceptable RG Disconnect Message CAPREC 616 Transmit RG Disconnect Message CAPREC 618 LDP session torn down NON EXISTENT 620 ICCP Connection State Transition Diagram 621 +------------+ 622 | | 623 +------------------>|NON EXISTENT| LDP session torn down 624 | | |<--------------------------+ 625 | +------------+ | 626 | LDP session | ^ LDP session | 627 | established | | torn down | 628 | V | | 629 | +-----------+ | 630 LDP | | | Tx LDP ICCP | 631 session| |INITIALIZED| capability | 632 torn | +---| |---------------+ | 633 down | Rx other | +-----------+ | | 634 | ICCP msg/ |Rx LDP ICCP | | 635 | Tx NAK TLV | capability/ | | 636 | +---+ |Tx LDP ICCP capability | | 637 | | | | | | 638 | V | V V | 639 | +-----------+ Rx LDP ICCP +--------+ | 640 +---| | capability | | | 641 |CAPREC |<----------------------|CAPSENT |---------->+ 642 +---| |-------------------+ | | | 643 | +-----------+ | +--------+ | 644 | ^ ^ | | 645 Tx | | | | | 646 RG | | |Rx RG Disconnect msg | | 647 Connect| | | or |Rx RG Connect msg / | 648 Msg | | |Tx RG Disconnect msg | Tx RG Connect msg | 649 | | | V | 650 | | | +------------+ | 651 | | +--------------------| | | 652 | | |OPERATIONAL |------------>+ 653 | | | | | 654 | |Rx other ICCP msg/ +------------+ | 655 | | Tx NAK TLV ^ | 656 | | | | 657 | +----------+ Rx RG Connect msg | | 658 | | |---------------------+ | 659 +----->|CONNECTING| | 660 | |----------------------------------------->+ 661 +----------+ 663 4.3. Redundant Object Identification 665 ICCP offers its client applications a uniform mechanism for 666 identifying links, ports, forwarding constructs and more generally 667 objects (e.g. interfaces, pseudowires, VLANs, etc...) that are being 668 protected in a redundant setup. These are referred to as Redundant 669 Objects (RO). An example of an RO is a multi-chassis link-aggregation 670 group that spans two PEs. ICCP introduces a 64-bit opaque identifier 671 to uniquely identify ROs in an RG. This identifier, referred to as 672 Redundant Object ID (ROID), MUST match between RG members for the 673 protected object in question. That allows separate systems in an RG 674 to use a common handle to reference the protected entity irrespective 675 of its nature (e.g. physical or virtual) and in a manner that is 676 agnostic to implementation specifics. Client applications that need 677 to synchronize state pertaining to a particular RO SHOULD embed the 678 corresponding ROID in their TLVs. 680 4.4. Application Connection Management 682 ICCP provides a common set of procedures by which applications on one 683 PE can connect to their counterparts on another PE, for purpose of 684 inter-chassis communication in the context of a given RG. The 685 prerequisite for establishing an application connection is to have an 686 operational ICCP RG connection between the two endpoints. It is 687 assumed that the association of applications with RGs is known a 688 priori, e.g. by means of device configuration. ICCP then sends an 689 Application-specific Connect TLV (carried in RG Connect message), on 690 behalf of each client application, to each remote PE within the RG. 691 The client may piggyback application-specific information in that 692 Connect TLV, which for example can be used to negotiate parameters or 693 attributes prior to bringing up the actual application connection. 694 The procedures for bringing up the application connection are similar 695 to those of the ICCP connection: An application connection between 696 two nodes is up only when both nodes have sent and received RG 697 Connect Messages with the proper Application-specific Connect TLVs. A 698 PE MUST send a Notification Message to reject an application 699 connection request if one of the following conditions is encountered: 701 -i. the application doesn't exist or is not configured for that 702 RG; 704 -ii. the application connection count exceeds the PE's 705 capabilities. 707 When a PE receives such a rejection notification, it MUST stop 708 attempting to bring up the application connection until it receives a 709 new application connection request from the remote PE. This is done 710 by responding to the incoming RG Connect message (carrying an 711 Application-specific Connect TLV) with an appropriate RG Connect 712 message (carrying a corresponding Application-specific Connect TLV). 714 When an application is stopped on a device or it is no longer 715 associated with an RG, it MUST signal ICCP to trigger sending an 716 Application-specific Disconnect TLV (in the RG Disconnect message). 717 This is a unilateral notification to the other PEs within an RG, and 718 as such doesn't trigger any response. 720 4.4.1. Application Versioning 722 During application connection setup time, a given application on one 723 PE can negotiate with its counterpart on a peer PE the proper 724 application version to use for communication. If no common version is 725 agreed upon, then the application connection is not brought up. This 726 is achieved through the following set of rules: 728 - If an application receives an Application-specific Connect TLV 729 with a version number that is higher than its own, it MUST send a 730 Notification message with a NAK TLV indicating status code 731 "Incompatible Protocol Version" and supplying the version that is 732 locally supported by the PE. 734 - If an application receives an Application-specific Connect TLV 735 with a version number that is lower than its own, it MAY respond 736 with an RG Connect that has an Application-specific Connect TLV 737 using the same version that was received. Alternatively, the 738 application MAY respond with a Notification message to reject the 739 request using the "Incompatible Protocol Version" code, and 740 supplying the version that is supported. The above allows an 741 application to operate in either backwards compatible or 742 incompatible mode. 744 - If an application receives an Application-specific Connect TLV 745 with a version that is equal to its own, then the application 746 MUST honor or reject the request based on whether the application 747 is configured for the RG in question, and whether or not the 748 application connection count has been exceeded. 750 4.4.2. Application Connection State Machine 752 A PE maintains an Application Connection State Machine instance per 753 ICCP application for every ICCP connection with a remote PE in the 754 RG. Each application's state machine reacts only to the RG Connect, 755 RG Disconnect and RG Notification messages that contain an 756 Application TLV specifying that particular application. 758 The Application Connection state machine has six states as follows: 760 -NON EXISTENT: This state indicates that the Application Connection 761 does not exist since there is no ICCP connection between the PEs. 763 -RESET: This state indicates that an ICCP connection is operational 764 between the PEs, but that the Application Connection has not been 765 initialized yet or has been resent. 767 -CONNSENT: This state indicates that the local PE has requested 768 initiation of an Application Connection with its peer, but has not 769 received a response yet. 771 -CONNREC: This state indicates that the local PE has received a 772 request to initiate an Application Connection from its peer but has 773 not responded yet. 775 -CONNECTING: This state indicates that the local PE has transmitted 776 to its peer an Application Connection message with the A-bit set 777 to 1, and is awaiting the peer's response 779 -OPERATIONAL: This state indicates that the Application Connection is 780 operational. 782 The state transition table and diagram follow. 784 ICCP Application Connection State Transition Table 785 STATE EVENT NEW STATE 787 NON EXISTENT ICCP connection established RESET 789 RESET ICCP connection torn down NON EXISTENT 791 Transmit Application Connect TLV CONNSENT 793 Receive Application Connect TLV CONNREC 795 Receive any other Application TLV RESET 796 Action: Transmit NAK TLV 798 CONNSENT Receive NAK TLV RESET 800 Receive Application Connect TLV OPERATIONAL 801 with A-bit=1 802 Action: Transmit Application Connect 803 TLV with A-bit=1 805 Receive any other Application TLV RESET 806 Action: Transmit NAK TLV 808 ICCP connection torn down NON EXISTENT 810 CONNREC Transmit NAK TLV RESET 812 Transmit Application Connect TLV CONNECTING 813 with A-bit=1 815 Receive Application Connect TLV CONNREC 817 Receive any Application TLV except RESET 818 Connect 819 Action: Transmit NAK TLV 821 ICCP connection torn down NON EXISTENT 823 CONNECTING Receive Application Connect TLV OPERATIONAL 824 with A-bit=1 826 Receive any other Application TLV RESET 827 Action: Transmit NAK TLV 829 ICCP connection torn down NON EXISTENT 831 OPERATIONAL Receive Application Disconnect TLV RESET 832 Transmit Applicaton Disconnect TLV RESET 834 ICCP connection torn down NON EXISTENT 836 ICCP Application Connection State Transition Diagram 837 +------------+ 838 | | 839 +---------------->|NON EXISTENT| ICCP connection torn down 840 | | |<--------------------------+ 841 | +------------+ | 842 | ICCP connection| ^ ICCP connection | 843 | established | | torn down | 844 | | | | 845 | V | Rx other App TLV/ | 846 | +-----------+<-----+ Tx NAK TLV | 847 ICCP | Rx App | | | | 848 connect| Connect TLV | RESET |------+ | 849 torn | +-------------| |---------------+ | 850 down | | +-----------+ Tx App | | 851 | | ^ ^ ^ ^ Connect TLV| | 852 | | Tx NAK | | | | | | 853 | | or | | | | | | 854 | | Rx non | | | | | | 855 | | Connect | | | | | | 856 | V TLV/Tx NAK | | |Rx NAK TLV V | 857 | +-----------+ | | | |or +--------+ | 858 +-| |---+ | | +---------| | | 859 |CONNREC | | | Rx other |CONNSENT|---------->+ 860 +-| |-+ | | App TLV/ | | | 861 | +-----------+ | | | Tx NAK +--------+ | 862 | ^---+ | | |Rx App Connect | 863 | Rx App | | |TLV (A=1) / | 864 | Connect TLV | |Rx App Disconn | Tx App | 865 | | |or | Connect TLV | 866 | Tx App Connect | |Tx App Disconn V (A=1) | 867 | TLV (A=1) | | +------------+ | 868 | | +------| | | 869 | Rx other App | |OPERATIONAL |------------>+ 870 | TLV / Tx NAK | | | | 871 | +------+ +------------+ | 872 | | ^ Rx App Connect | 873 | +----------+ | TLV (A=1) | 874 | | |---------------------+ | 875 +--->|CONNECTING| | 876 | |----------------------------------------->+ 877 +----------+ 879 4.5. Application Data Transfer 881 When an application has information to transfer over ICCP it triggers 882 the transmission of an Application Data message. ICCP guarantees in- 883 order and loss-less delivery of data. An application may reject a 884 message or a set of one or more TLVs within a message by using the 885 Notification Message with NAK TLV. Furthermore, an application may 886 implement its own ACK mechanism, if deemed required, by defining an 887 application-specific TLV to be transported in an Application Data 888 message. Note that this document does not define a common ACK 889 mechanism for applications. 891 It is left up to the application to define the procedures to handle 892 the situation where a PE receives a NAK TLV in response to a 893 transmitted Application Data message. Depending on the specifics of 894 the application, it may be favorable to have the PE, which sent the 895 NAK, explicitly request retransmission of data. On the other hand, 896 for certain applications it may be more suitable to have the original 897 sender of the Application Data message handle retransmissions in 898 response to a NAK. ICCP supports both models. 900 4.6. Dedicated Redundancy Group LDP session 902 For certain ICCP applications, it is required to exchange a fairly 903 large amount of RG information in a very short period of time. In 904 order to better distribute the load in a multiple processor system, 905 and to avoid head of line blocking to other LDP applications, it may 906 be required to initiate a separate TCP/IP session between the two LDP 907 speakers. 909 This procedure is OPTIONAL, and does not change the operation of LDP 910 or ICCP. 912 A PE that requires a separate LDP session will advertise a separate 913 LDP adjacency with a non-zero label space identifier. This will cause 914 the remote peer to open a separate LDP session for this label space. 915 No labels need to be advertised in this label space, as it is only 916 used for one or a set of ICCP RGs. All relevant LDP and ICCP 917 procedures still apply as described in the relevant documents. 919 5. ICCP PE Node Failure / Isolation Detection Mechanism 921 ICCP provides its client applications a notification when a remote PE 922 that is member of the RG is no longer reachable. In the case of 923 dedicated interconnect, this indicates that the remote PE node has 924 failed. Whereas, in the case of shared interconnect, this indicates 925 that either the remote PE node has failed or that it has become 926 isolated from the MPLS network. This is used by the client 927 applications to trigger failover according to the procedures of the 928 employed redundancy protocol on the AC and PW. To that end, ICCP does 929 not define its own Keep-Alive mechanism for purpose of monitoring the 930 health of remote PE nodes, but rather reuses existing fault detection 931 mechanisms. The following mechanisms may be used by ICCP to detect PE 932 node failure: 934 - BFD 936 Run a BFD session [RFC5880] between the PEs that are members of a 937 given RG, and use that to detect PE node failure. This assumes 938 that resiliency mechanisms are in place to protect connectivity 939 to the remote PE nodes, and hence loss of BFD periodic messages 940 from a given PE node can only mean that the node itself has 941 failed. 943 - IP Reachability Monitoring 945 It is possible for a PE to monitor IP layer connectivity to other 946 members of an RG that are participating in IGP/BGP. When 947 connectivity to a given PE is lost, the local PE interprets that 948 to mean loss of the remote PE node. This assumes that resiliency 949 mechanisms are in place to protect the route to the remote PE 950 nodes, and hence loss of IP reachability to a given node can only 951 mean that the node itself has failed. 953 It is worth noting here that loss of the LDP session with a PE in an 954 RG is not a reliable indicator that the remote PE itself is down. It 955 is possible, for e.g. that the remote PE encounters a local event 956 that leads to resetting the LDP session, while the PE node remains 957 operational for purpose of traffic forwarding. 959 6. ICCP Message Formats 961 This section defines the messages exchanged at the Application and 962 ICC layers. 964 6.1. Encoding ICC into LDP Messages 966 ICCP requires reliable, in-order, state-full message delivery, as 967 well as capability negotiation between PEs. The LDP protocol offers 968 all these features, and is already in wide use in the applications 969 that would also require the ICCP protocol extensions. For these 970 reasons, ICCP takes advantage of the already defined LDP protocol 971 infrastructure. 973 [RFC5036] Section 3.5 defines a generic LDP message structure. A new 974 set of LDP message types is defined to communicate the ICCP 975 information. LDP message types in the range 0x700 to 0x70F will be 976 used for ICCP. 978 Message types are allocated by IANA, and requested in the IANA 979 section below. 981 6.1.1. ICC Header 983 Every ICCP message comprises of an ICC specific LDP Header followed 984 by message data. The format of the ICC Header is as follows: 986 0 1 2 3 987 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 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 |U| Message Type | Message Length | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | Message ID | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | Type=0x0005 (ICC RG ID) | Length=4 | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | ICC RG ID | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | | 998 + + 999 | Mandatory ICC Parameters | 1000 ~ ~ 1001 + + 1002 | | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | | 1005 + + 1006 | Optional ICC Parameters | 1007 ~ ~ 1008 + + 1009 | | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 - U-bit 1014 Unknown message bit. Upon receipt of an unknown message, if U is 1015 clear (=0), a notification is returned to the message originator; 1016 if U is set (=1), the unknown message is silently ignored. The 1017 following sections which define messages specify a value for the 1018 U-bit. 1020 - Message Type 1022 Identifies the type of the ICCP message, must be in the range of 1023 0x0700 to 0x070F. 1025 - Message Length 1027 Two octet integer specifying the total length of this message in 1028 octets, excluding the U-bit, Message Type and Length fields. 1030 - Message ID 1032 Four octet value used to identify this message. Used by the 1033 sending PE to facilitate identifying RG Notification messages 1034 that may apply to this message. A PE sending an RG Notification 1035 message in response to this message SHOULD include this Message 1036 ID in the "NAK TLV" of the RG Notification message; see Section 1037 6.4 "RG Notification Message". 1039 - ICC RG ID TLV 1041 A TLV of type 0x0005, length 4, containing 4 octets unsigned 1042 integer designating the Redundancy Group which the sending device 1043 is member of. RG ID value 0x00000000 is reserved by the protocol. 1045 - Mandatory ICC Parameters 1047 Variable length set of required message parameters. Some 1048 messages have no required parameters. 1050 For messages that have required parameters, the required 1051 parameters MUST appear in the order specified by the individual 1052 message specifications in the sections that follow. 1054 - Optional ICC Parameters 1056 Variable length set of optional message parameters. Many 1057 messages have no optional parameters. 1059 For messages that have optional parameters, the optional 1060 parameters may appear in any order. 1062 6.1.2. ICC Parameter Encoding 1064 The generic format of an ICC parameter is: 1066 0 1 2 3 1067 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 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 |U|F| Type | Length | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | TLV(s) | 1072 ~ ~ 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 - U-bit 1076 Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear 1077 (=0), a notification MUST be returned to the message originator 1078 and the entire message MUST be ignored; if U is set (=1), the 1079 unknown TLV MUST be silently ignored and the rest of the message 1080 processed as if the unknown TLV did not exist. The sections 1081 following that define TLVs specify a value for the U-bit. 1083 - F-bit 1085 Forward unknown TLV bit. This bit applies only when the U-bit is 1086 set and the LDP message containing the unknown TLV is to be 1087 forwarded. If F is clear (=0), the unknown TLV is not forwarded 1088 with the containing message; if F is set (=1), the unknown TLV is 1089 forwarded with the containing message. The sections following 1090 that define TLVs specify a value for the F-bit. By setting both 1091 the U- and F-bits, a TLV can be propagated as opaque data through 1092 nodes that do not recognize the TLV. 1094 - Type 1096 Fourteen bits indicating the ICC Parameter type. 1098 - Length 1100 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1101 Length fields. 1103 - TLV(s): A set of 0 or more TLVs, that vary according to the 1104 message type. 1106 6.1.3. Redundant Object Identifier Encoding 1108 The Redundant Object Identifier (ROID) is a generic opaque handle 1109 that uniquely identifies a Redundant Object (e.g. link, bundle, VLAN, 1110 etc...) which is being protected in an RG. It is encoded as follows: 1112 0 1 2 3 1113 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 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | ROID | 1116 + + 1117 | | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 where: ROID is an 8 octets field encoded as an unsigned integer. The 1120 ROID value of 0 is reserved. 1122 The ROID is carried within application specific TLVs. 1124 6.2. RG Connect Message 1126 The RG Connect Message is used to establish the ICCP RG connection in 1127 addition to individual Application connections between PEs in an RG. 1128 An RG Connect message with no "Application-specific connect TLV" 1129 signals establishment of the ICCP RG connection. Whereas, an RG 1130 Connect message with a valid "Application-specific connect TLV" 1131 signals the establishment of an Application connection, in addition 1132 to the ICCP RG connection if the latter is not already established. 1134 An implementation MAY send a dedicated RG Connect message to set up 1135 the ICCP RG connection and a separate RG Connect message per client 1136 application. However, all implementations MUST support the receipt of 1137 an RG Connect message that triggers the setup of the ICCP RG 1138 connection as well as a single Application connection simultaneously. 1140 A PE sends an RG Connect Message to declare its membership in a 1141 Redundancy Group. One such message should be sent to each PE that is 1142 member of the same RG. The set of PEs to which RG Connect Messages 1143 should be transmitted is known via configuration or an auto-discovery 1144 mechanism that is outside the scope of this specification. If a 1145 device is member of multiple RGs, it MUST send separate RG Connect 1146 Messages for each RG even if the receiving device(s) happen to be the 1147 same. 1149 The format of the RG Connect Message is as follows: 1151 -i. ICC header with Message type = "RG Connect Message" (0x0700) 1152 -ii. ICC Sender Name TLV 1153 -iii. Zero or one Application-specific connect TLV 1155 The currently defined Application-specific connect TLVs are: 1157 - PW-RED Connect TLV (section 7.1.1) 1159 - mLACP Connect TLV (section 7.2.1) 1161 The details of these TLVs are discussed in the "Application TLVs" 1162 section. 1164 The RG Connect message can contain zero or one Application-specific 1165 connect TLV. 1167 6.2.1. ICC Sender Name TLV 1169 A TLV that carries the hostname of the sender encoded in UTF-8 1170 [RFC3629]. This is used primarily for purpose of management of the RG 1171 and easing network operations. The specific format is shown below: 1173 0 1 2 3 1174 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 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 |U|F| Type = 0x0001 | Length | 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | Sender Name | 1179 + +-+-+-+-+-+-+-+-+-+ 1180 ~ ~ 1181 | ... | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 - U=F=0 1186 - Type set to 0x0001 (from ICC parameter name space). 1188 - Length 1190 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1191 Length fields. 1193 - Sender Name 1195 An administratively-assigned name of the sending device encoded 1196 in UTF-8 and limited to a maximum of 80 octets. This field does 1197 not include a terminating null character. 1199 6.3. RG Disconnect Message 1201 The RG Disconnect Message serves dual-purpose: to signal that a 1202 particular Application connection is being closed within an RG, or 1203 that the ICCP RG connection itself is being disconnected because the 1204 PE wishes to leave the RG. The format of this message is: 1206 0 1 2 3 1207 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 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 |U| Message Type=0x0701 | Message Length | 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 | Message ID | 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 | Type=0x0005 (ICC RG ID) | Length=4 | 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | ICC RG ID | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | Disconnect Code TLV | 1218 + + 1219 | | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | Optional Application-specific Disconnect TLV | 1222 ~ ~ 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | Optional Parameter TLVs | 1225 + + 1226 | | 1227 ~ ~ 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 - U-bit 1232 U=0 1234 - Message Type 1236 The message type for RG Disconnect Message is set to (0x0701) 1238 - Length 1240 Length of the TLV in octets excluding the U-bit, Message Type, 1241 and Message Length fields. 1243 - Message ID 1245 Defined in the "ICC Header" section above. 1247 - ICC RG ID 1249 Defined in the "ICC Header" section above. 1251 - Disconnect Code TLV 1253 The format of this TLV is as follows: 1255 0 1 2 3 1256 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 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 |U|F| Type=0x0004 | Length | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | ICCP Status Code | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 - U,F Bits 1265 both U and F are set to 0. 1267 - Type 1269 set to "Disconnect Code TLV" (0x0004) 1271 - Length 1273 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1274 Length fields. 1276 - ICCP Status Code 1278 A status code that reflects the reason for the disconnect 1279 message. Allowed values are "ICCP RG Removed" and "ICCP 1280 Application Removed from RG". 1282 - Optional Application-specific Disconnect TLV 1284 Zero or one Application-specific Disconnect TLVs which are 1285 defined later in the document. If the RG Disconnect message has 1286 a status code of "RG Removed", then it MUST NOT contain any 1287 Application-specific Disconnect TLVs, as the sending PE is 1288 signaling that it has left the RG and, thus, is disconnecting the 1289 ICCP RG connection, with all associated client application 1290 connections. If the message has a status code of "Application 1291 Removed from RG", then it MUST contain exactly one Application- 1292 specific Disconnect TLV, as the sending PE is only tearing down 1293 the connection for the specified application. Other applications, 1294 and the ICCP RG connection are not to be affected. 1296 - Optional Parameter TLVs 1298 None are defined for this message in this document. This is 1299 specified to allow for future extensions. 1301 6.4. RG Notification Message 1303 A PE sends an RG Notification Message to indicate one of the 1304 following: to reject an ICCP connection, to reject an application 1305 connection, to reject an entire message or to reject one or more 1306 TLV(s) within a message. The Notification message MUST only be sent 1307 to a PE that is already part of an RG. 1309 The RG Notification Message MUST only be used to reject messages or 1310 TLVs corresponding to a single ICCP application. In other words, 1311 there is a limit of at most a single ICCP application per RG 1312 Notification Message. 1314 The format of the RG Notification Message is: 1316 -i. ICC header with Message type = "RG Notification Message" 1317 (0x0702) 1318 -ii. Notification Message TLVs. 1320 The currently defined Notification message TLVs are: 1322 -i. ICC Sender Name TLV 1323 -ii. Negative-Acknowledgement (NAK) TLV 1325 6.4.1. Notification Message TLVs 1327 The ICC Sender Name TLV uses the same format as in the RG Connect 1328 message, and was described above. 1330 The NAK TLV is defined as follows: 1332 0 1 2 3 1333 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 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 |U|F| Type=0x0002 | Length | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | ICCP Status Code | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | Rejected Message ID | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | Optional TLV(s) | 1342 + + 1343 | | 1344 ~ ~ 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 - U,F Bits 1349 both U and F are set to 0. 1351 - Type 1353 set to "NAK TLV" (0x0002) 1355 - Length 1357 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1358 Length fields. 1360 - ICCP Status Code 1362 A status code that reflects the reason for the NAK TLV. Allowed 1363 values are: 1364 -i. Unknown RG (0x00010001) 1366 This code is used to reject a new incoming ICCP 1367 connection for an RG that is not configured on the local 1368 PE. When this code is used, the Rejected Message ID 1369 field MUST contain the message ID of the rejected "RG 1370 Connect" message. 1372 -ii. ICCP Connection Count Exceeded (0x00010002) 1374 This is used to reject a new incoming ICCP connection 1375 that would cause the local PE's ICCP connection count to 1376 exceed its capabilities. When this code is used, the 1377 Rejected Message ID field MUST contain the message ID of 1378 the rejected "RG Connect" message. 1380 -iii. Application Connection Count Exceeded (0x00010003) 1382 This is used to reject a new incoming application 1383 connection that would cause the local PE's ICCP 1384 connection count to exceed its capabilities. When this 1385 code is used, the Rejected Message ID field MUST contain 1386 the message ID of the rejected "RG Connect" message and 1387 the corresponding Application Connect TLV MUST be 1388 included in the "Optional TLV". 1390 -iv. Application not in RG (0x00010004) 1392 This is used to reject a new incoming application 1393 connection when the local PE doesn't support the 1394 application, or the application is not configured in the 1395 RG. When this code is used, the Rejected Message ID 1396 field MUST contain the message ID of the rejected "RG 1397 Connect" message and the corresponding Application 1398 Connect TLV MUST be included in the "Optional TLV". 1400 -v. Incompatible Protocol Version (0x00010005) 1402 This is used to reject a new incoming application 1403 connection when the local PE has an incompatible version 1404 of the application. When this code is used, the Rejected 1405 Message ID field MUST contain the message ID of the 1406 rejected "RG Connect" message and the corresponding 1407 Application Connect TLV MUST be included in the 1408 "Optional TLV". 1410 -vi. Rejected Message (0x00010006) 1412 This is used to reject an RG Application Data message, 1413 or one or more TLV(s) within the message. When this code 1414 is used, the Rejected Message ID field MUST contain the 1415 message ID of the rejected "RG Application Data" 1416 message. 1418 -vii. ICCP Administratively Disabled (0x00010007) 1420 This is used to reject any ICCP messages from a peer 1421 from which the PE is not allowed to exchange ICCP 1422 messages due to local administrative policy. 1424 - Rejected Message ID 1426 If non-zero, four octets value that identifies the peer message 1427 to which the NAK TLV refers. If zero, no specific peer message is 1428 being identified. 1430 - Optional TLV(s) 1432 A set of one or more optional TLVs. If the status code is 1433 "Rejected Message" then this field contains the TLV(s) that were 1434 rejected. If the entire message is rejected, all its TLVs MUST be 1435 present in this field; otherwise, the subset of TLVs that were 1436 rejected MUST be echoed in this field. 1438 If the status code is "Incompatible Protocol Version" then this 1439 field contains the original "Application Connect TLV" sent by the 1440 peer, in addition to the "Requested Protocol Version TLV" defined 1441 below: 1443 0 1 2 3 1444 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 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 |U|F| Type=0x0003 | Length | 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 | Connection Reference | Requested Version | 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 - U and F Bits 1453 Both are set to 0. 1455 - Type 1457 set to 0x0003 for "Requested Protocol Version TLV" 1459 - Length 1461 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1462 Length fields. 1464 - Connection Reference 1466 This field is set to the Type field of the Application specific 1467 Connect TLV that was rejected because of incompatible version. 1469 - Requested Version 1471 The version of the application supported by the transmitting 1472 device. For this version of the protocol it is set to 0x0001. 1474 6.5. RG Application Data Message 1476 The RG Application Data Message is used to transport application data 1477 between PEs within an RG. A single message can be used to carry data 1478 from only one application. Multiple application TLVs are allowed in a 1479 single message, as long as all of these TLVs belong to the same 1480 application. The format of the Application Data Message is: 1482 -i. ICC header with Message type = "RG Application Data Message" 1483 (0x703) 1484 -ii. "Application specific TLVs" 1486 The details of these TLVs are discussed in the "Application TLVs" 1487 section. All application specific TLVs in one RG Application Data 1488 Message MUST belong to a single application but MAY reference 1489 different ROs. 1491 7. Application TLVs 1493 7.1. Pseudowire Redundancy (PW-RED) Application TLVs 1495 This section discusses the ICCP TLVs for the Pseudowire Redundancy 1496 application. 1498 7.1.1. PW-RED Connect TLV 1500 This TLV is included in the RG Connect message to signal the 1501 establishment of PW-RED application connection. 1503 0 1 2 3 1504 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 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 |U|F| Type=0x0010 | Length | 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 | Protocol Version |A| Reserved | 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 | Optional Sub-TLVs | 1511 ~ ~ 1512 | | 1513 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 | ... | 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 - U and F Bits 1518 Both are set to 0. 1520 - Type 1522 set to 0x0010 for "PW-RED Connect TLV" 1524 - Length 1526 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1527 Length fields. 1529 - Protocol Version 1531 The version of this particular protocol for the purposes of ICCP. 1532 This is set to 0x0001. 1534 - A bit 1536 Acknowledgement Bit. Set to 1 if the sender has received a PW-RED 1537 Connect TLV from the recipient. Otherwise, set to 0. 1539 - Reserved 1541 Reserved for future use. 1543 - Optional Sub-TLVs 1545 There are no optional Sub-TLVs defined for this version of the 1546 protocol. This document does not impose any resrictions on the 1547 length of the sub-TLVs. 1549 7.1.2. PW-RED Disconnect TLV 1551 This TLV is used in an RG Disconnect Message to indicate that the 1552 connection for the PW-RED application is to be terminated. 1554 0 1 2 3 1555 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 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 |U|F| Type=0x0011 | Length | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | Optional Sub-TLVs | 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 - U and F Bits 1563 Both are set to 0. 1565 - Type 1567 set to 0x0011 for "PW-RED Disconnect TLV" 1569 - Length 1571 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1572 Length fields. 1574 - Optional Sub-TLVs 1576 The only optional Sub-TLV defined for this version of the 1577 protocol is the "PW-RED Disconnect Cause" TLV defined in Section 1578 7.1.2.1. 1580 7.1.2.1. PW-RED Disconnect Cause TLV 1582 0 1 2 3 1583 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 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 |U|F| Type=0x0019 | Length | 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 | Disconnect Cause String | 1588 ~ ~ 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 - U and F Bits 1593 Both are set to 0. 1595 - Type 1597 set to 0x0019 for "PW-RED Disconnect Cause TLV" 1599 - Length 1601 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1602 Length fields. 1604 - Disconnect Cause String 1606 Variable length string specifying the reason for the disconnect, 1607 encoded in UTF-8. The string does not include a terminating null 1608 character. Used for network management. 1610 7.1.3. PW-RED Config TLV 1612 The PW-RED Config TLV is used in the RG Application Data message and 1613 has the following format: 1615 0 1 2 3 1616 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 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 |U|F| Type = 0x0012 | Length | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 | ROID | 1621 + + 1622 | | 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 | PW Priority | Flags | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 | Service Name TLV | 1627 ~ ~ 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 | PW ID TLV or Generalized PW ID TLV | 1630 ~ ~ 1631 | | 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 - U and F Bits 1636 Both are set to 0. 1638 - Type 1640 set to 0x0012 for "PW-RED Config TLV" 1642 - Length 1644 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1645 Length fields. 1647 - ROID 1649 As defined in Section 6.1.3. 1651 - PW Priority 1653 Two octets Pseudowire Priority. Used to indicate which PW has 1654 better priority to go into Active state. Numerically lower 1655 numbers are better priority. In case of a tie, the PE with the 1656 numerically lower identifier (i.e. IP Address) has better 1657 priority. 1659 - Flags 1661 Valid values are: 1663 -i. Synchronized (0x01) 1665 Indicates that the sender has concluded transmitting all 1666 pseudowire configuration for a given service. 1668 -ii. Purge Configuration (0x02) 1670 Indicates that the pseudowire is no longer configured 1671 for PW-RED operation. 1673 -iii. Independent Mode (0x04) 1675 Indicates that the pseudowire is configured for 1676 redundancy using the Independent Mode of operation, per 1677 section 5.1 of [RFC6870]. 1679 -iv. Independent Mode with Request Switchover (0x08) 1681 Indicates that the pseudowire is configured for 1682 redundancy using the Independent Mode of operation with 1683 the use of the "Request Switchover" bit, per section 6.3 1684 of [RFC6870]. 1686 -v. Master Mode (0x10) 1688 Indicates that the pseudowire is configured for 1689 redundancy using the Master/Slave Mode of operation, 1690 with the advertising PE acting as Master, per section 1691 5.2 of [RFC6870]. 1693 -vi. Slave Mode (0x20) 1695 Indicates that the pseudowire is configured for 1696 redundancy using the Master/Slave Mode of operation, 1697 with the advertising PE acting as Slave, per section 5.2 1698 of [RFC6870]. 1700 - Sub-TLVs 1702 The "PW-RED Config TLV" includes the following two sub-TLVs: 1704 -i. Service Name TLV 1706 -ii. One of PW ID TLV or Generalized PW ID TLV 1708 The format of the sub-TLVs is defined in Sections 7.1.3.1 through 1709 7.1.3.3. 1711 7.1.3.1. Service Name TLV 1713 0 1 2 3 1714 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 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 |U|F| Type | Length | 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 | Service Name | 1719 ~ ~ 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 - U and F Bits 1724 Both are set to 0. 1726 - Type 1728 set to 0x0013 for "Service Name TLV" 1730 - Length 1732 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1733 Length fields. 1735 - Service Name 1737 The name of the L2VPN service instance encoded in UTF-8 format 1738 and up to 80 octets in length. The string does not include a 1739 terminating null character. 1741 7.1.3.2. PW ID TLV 1743 This TLV is used to communicate the configuration of PWs for VPWS. 1745 0 1 2 3 1746 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 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 |U|F| Type | Length | 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | Peer ID | 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 | Group ID | 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1754 | PW ID | 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1757 - U and F Bits 1759 Both are set to 0. 1761 - Type 1763 set to 0x0014 for "PW ID TLV" 1765 - Length 1767 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1768 Length fields. 1770 - Peer ID 1772 Four octet LDP Router ID of the peer at the far end of the PW. 1774 - Group ID 1776 Same as Group ID in [RFC4447] section 5.2. 1778 - PW ID 1780 Same as PW ID in [RFC4447] section 5.2. 1782 7.1.3.3. Generalized PW ID TLV 1784 This TLV is used to communicate the configuration of PWs for VPLS. 1786 0 1 2 3 1787 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 1788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 |U|F| Type = 0x0015 | Length | 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1791 | AGI Type | Length | Value | 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 ~ AGI Value (contd.) ~ 1794 | | 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 | AII Type | Length | Value | 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1798 ~ SAII Value (contd.) ~ 1799 | | 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 | AII Type | Length | Value | 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 ~ TAII Value (contd.) ~ 1804 | | 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 - U and F bits 1809 both set to 0. 1811 - Type 1813 set to 0x0015 1815 - Length 1817 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1818 Length fields. 1820 - AGI, AII, SAII and TAII 1822 defined in [RFC4447] section 5.3.2. 1824 7.1.4. PW-RED State TLV 1826 The PW-RED State TLV is used in the RG Application Data Message. This 1827 TLV is used by a device to report its PW status to other members in 1828 the RG. 1830 The format of this TLV is as follows: 1832 0 1 2 3 1833 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 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 |U|F| Type=0x0016 | Length | 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 | ROID | 1838 + + 1839 | | 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 | Local PW State | 1842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1843 | Remote PW State | 1844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1846 - U and F Bits 1848 Both are set to 0. 1850 - Type 1852 set to 0x0016 for PW-RED State TLV. 1854 - Length 1856 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1857 Length fields. 1859 - ROID 1861 As defined in Section 6.1.3. 1863 - Local PW State 1865 The status of the PW as determined by the sending PE, encoded in 1866 the same format as the "Status Code" field of the "PW Status TLV" 1867 defined in [RFC4447] and extended in [RFC6870]. 1869 - Remote PW State 1871 The status of the PW as determined by the remote peer of the 1872 sending PE. Encoded in the same format as the "Status Code" field 1873 of the "PW Status TLV" defined in [RFC4447] and extended in 1874 [RFC6870]. 1876 7.1.5. PW-RED Synchronization Request TLV 1878 The PW-RED Synchronization Request TLV is used in the RG Application 1879 Data message. This TLV is used by a device to request from its peer 1880 to retransmit configuration or operational state. The following 1881 information can be requested: 1883 - configuration and/or state for one or more pseudowires 1885 - configuration and/or state for all pseudowires 1887 - configuration and/or state for all pseudowires in a given service 1889 The format of the TLV is as follows: 1891 0 1 2 3 1892 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 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 |U|F| Type=0x0017 | Length | 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1896 | Request Number |C|S| Request Type | 1897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1898 | Optional Sub-TLVs | 1899 ~ ~ 1900 | | 1901 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1902 | ... | 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 - U and F Bits 1907 Both are set to 0. 1909 - Type 1911 set to 0x0017 for "PW-RED Synchronization Request TLV" 1913 - Length 1915 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1916 Length fields. 1918 - Request Number 1920 2 octets. Unsigned integer uniquely identifying the request. Used 1921 to match the request with a response. The value of 0 is reserved 1922 for unsolicited synchronization, and MUST NOT be used in the PW- 1923 RED Synchronization Request TLV. Given the use of TCP, there are 1924 no issues associated with the wrap-around of the Request Number. 1926 - C Bit 1928 Set to 1 if request is for configuration data. Otherwise, set to 1929 0. 1931 - S Bit 1933 Set to 1 if request is for running state data. Otherwise, set to 1934 0. 1936 - Request Type 1938 14-bits specifying the request type, encoded as follows: 1940 0x00 Request Data for specified pseudowire(s) 1941 0x01 Request Data for all pseudowires in specified service(s) 1942 0x3FFF Request All Data 1944 - Optional Sub-TLVs 1946 A set of zero or more TLVs, as follows: 1948 If the Request Type field is set to (0x00), then this field 1949 contains one or more PW ID TLV(s) or Generalized PW ID TLV(s). If 1950 the Request Type field is set to (0x01), then this field contains 1951 one or more Service Name TLV(s). If the Request Type field is set 1952 to (0x3FFF), then this field MUST be empty. This document does 1953 not impose any restrictions on the length of the sub-TLVs. 1955 7.1.6. PW-RED Synchronization Data TLV 1957 The PW-RED Synchronization Data TLV is used in the RG Application 1958 Data mesage. A pair of these TLVs is used by a device to delimit a 1959 set of TLVs that are sent in response to a PW-RED Synchronization 1960 Request TLV. The delimiting TLVs signal the start and end of the 1961 synchronization data, and associate the response with its 1962 corresponding request via the Request Number field. 1964 The PW-RED Synchronization Data TLVs are also used for unsolicited 1965 advertisements of complete PW-RED configuration and operational state 1966 data. In this case, the Request Number field MUST be set to 0. 1968 This TLV has the following format: 1970 0 1 2 3 1971 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 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 |U|F| Type=0x0018 | Length | 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 | Request Number | Flags | 1976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 - U and F Bits 1980 Both are set to 0. 1982 - Type 1984 set to 0x0018 for "PW-RED Synchronization Data TLV" 1986 - Length 1988 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 1989 Length fields. 1991 - Request Number 1993 2 octets. Unsigned integer identifying the Request Number from 1994 the "PW-RED Synchronization Request TLV" which solicited this 1995 synchronization data response. 1997 - Flags 1999 2 octets, response flags encoded as follows: 2001 0x00 Synchronization Data Start 2002 0x01 Synchronization Data End 2004 7.2. Multi-chassis LACP (mLACP) Application TLVs 2006 This section discusses the ICCP TLVs for Ethernet attachment circuit 2007 redundancy using the multi-chassis LACP (mLACP) application. 2009 7.2.1. mLACP Connect TLV 2011 This TLV is included in the RG Connect message to signal the 2012 establishment of mLACP application connection. 2014 0 1 2 3 2015 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 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2017 |U|F| Type=0x0030 | Length | 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2019 | Protocol Version |A| Reserved | 2020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2021 | Optional Sub-TLVs | 2022 ~ ~ 2023 | | 2024 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2025 | ... | 2026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2028 - U and F Bits 2030 Both are set to 0. 2032 - Type 2034 set to 0x0030 for "mLACP Connect TLV" 2036 - Length 2038 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2039 Length fields. 2041 - Protocol Version 2043 The version of this particular protocol for the purposes of ICCP. 2044 This is set to 0x0001. 2046 - A Bit 2048 Acknowledgement Bit. Set to 1 if the sender has received an mLACP 2049 Connect TLV from the recipient. Otherwise, set to 0. 2051 - Reserved 2053 Reserved for future use. 2055 - Optional Sub-TLVs 2057 There are no optional Sub-TLVs defined for this version of the 2058 protocol. 2060 7.2.2. mLACP Disconnect TLV 2062 This TLV is used in an RG Disconnect Message to indicate that the 2063 connection for the mLACP application is to be terminated. 2065 0 1 2 3 2066 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 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2068 |U|F| Type=0x0031 | Length | 2069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2070 | Optional Sub-TLVs | 2071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 - U and F Bits 2075 Both are set to 0. 2077 - Type 2079 set to 0x0031 for "mLACP Disconnect TLV" 2081 - Length 2083 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2084 Length fields. 2086 - Optional Sub-TLVs 2088 The only optional Sub-TLV defined for this version of the 2089 protocol is the "mLACP Disconnect Cause" TLV defined in Section 2090 7.2.2.1. 2092 7.2.2.1. mLACP Disconnect Cause TLV 2094 0 1 2 3 2095 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 2096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2097 |U|F| Type=0x003A | Length | 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 | Disconnect Cause String | 2100 ~ ~ 2101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2103 - U and F Bits 2105 Both are set to 0. 2107 - Type 2109 set to 0x003A for "mLACP Disconnect Cause TLV" 2111 - Length 2113 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2114 Length fields. 2116 - Disconnect Cause String 2118 Variable length string specifying the reason for the disconnect. 2119 Used for network management. 2121 7.2.3. mLACP System Config TLV 2123 The mLACP System Config TLV is sent in the RG Application Data 2124 message. This TLV announces the local node's LACP System Parameters 2125 to the RG peers. 2127 0 1 2 3 2128 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 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 |U|F| Type=0x0032 | Length | 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | System ID | 2133 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 | | System Priority | 2135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2136 | Node ID | 2137 +-+-+-+-+-+-+-+-+ 2138 - U and F Bits 2140 Both are set to 0. 2142 - Type 2144 set to 0x0032 for "mLACP System Config TLV" 2146 - Length 2148 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2149 Length fields. 2151 - System ID 2153 6 octets field encoding the System ID used by LACP as specified 2154 in [IEEE-802.1AX] section 5.3.2. 2156 - System Priority 2158 2 octets encoding the LACP System Priority as defined in [IEEE- 2159 802.1AX] section 5.3.2. 2161 - Node ID 2163 One octet, LACP node ID. Used to ensure that the LACP Port 2164 Numbers are unique across all devices in an RG. Valid values are 2165 in the range 0 - 7. Uniqueness of the LACP Port Numbers across 2166 RG members is ensured by encoding the Port Numbers as follows: 2168 - Most significant bit always set to 1 2169 - The next 3 most significant bits set to Node ID 2170 - Remaining 12 bits freely assigned by the system 2172 7.2.4. mLACP Aggregator Config TLV 2174 The mLACP Aggregator Config TLV is sent in the RG Application Data 2175 message. This TLV is used to notify RG peers about the local 2176 configuration state of an aggregator. 2178 0 1 2 3 2179 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 2180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2181 |U|F| Type=0x0036 | Length | 2182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 | ROID | 2184 + + 2185 | | 2186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2187 | Aggregator ID | MAC Address | 2188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2189 | | 2190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2191 | Actor Key | Member Ports Priority | 2192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2193 | Flags | Agg Name Len | Aggregator Name | 2194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2195 ~ ~ 2196 | ... | 2197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2199 - U and F Bits 2201 Both are set to 0. 2203 - Type 2205 set to 0x0036 for "mLACP Aggregator Config TLV" 2207 - Length 2209 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2210 Length fields. 2212 - ROID 2214 Defined in the 'ROID Encoding' section above. 2216 - Aggregator ID 2218 Two octets, LACP Aggregator Identifier as specified in [IEEE- 2219 802.1AX] section 5.4.6 2221 - MAC Address 2223 Six octets encoding the Aggregator MAC address. 2225 - Actor Key 2227 Two octets, LACP Actor Key for the corresponding Aggregator, as 2228 specified in [IEEE-802.1AX] section 5.3.5. 2230 - Member Ports Priority 2232 Two octets, LACP administrative port priority associated with all 2233 interfaces bound to the Aggregator. This field is valid only when 2234 the "Flags" field has "Priority Set" asserted. 2236 - Flags 2238 Valid values are: 2240 -i. Synchronized (0x01) 2242 Indicates that the sender has concluded transmitting all 2243 Aggregator configuration information. 2245 -ii. Purge Configuration (0x02) 2247 Indicates that the Aggregator is no longer configured 2248 for mLACP operation. 2250 -iii. Priority Set (0x04) 2252 Indicates that the "Member Ports Priority" field is 2253 valid. 2255 - Agg Name Len 2257 One octet, length of the "Aggregator Name" field in octets. 2259 - Aggregator Name 2261 Aggregator name encoded in UTF-8 format, up to a maximum of 20 2262 octets. Used for ease of management. The string does not include 2263 a terminating null character. 2265 7.2.5. mLACP Port Config TLV 2267 The mLACP Port Config TLV is sent in the RG Application Data message. 2268 This TLV is used to notify RG peers about the local configuration 2269 state of a port. 2271 0 1 2 3 2272 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 2273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2274 |U|F| Type=0x0033 | Length | 2275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 | Port Number | MAC Address | 2277 +-------------------------------+ + 2278 | | 2279 +---------------------------------------------------------------+ 2280 | Actor Key | Port Priority | 2281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2282 | Port Speed | 2283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2284 | Flags | Port Name Len | Port Name | 2285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2286 ~ ~ 2287 | ... | 2288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2290 - U and F Bits 2292 Both are set to 0. 2294 - Type 2296 set to 0x0033 for "mLACP Port Config TLV" 2298 - Length 2300 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2301 Length fields. 2303 - Port Number 2305 Two octets, LACP Port Number for the corresponding interface as 2306 specified in [IEEE-802.1AX] section 5.3.4. The Port Number MUST 2307 be encoded with the Node ID as was discussed above. 2309 - MAC Address 2311 Six octets encoding the port MAC address. 2313 - Actor Key 2315 Two octets, LACP Actor Key for the corresponding interface, as 2316 specified in [IEEE-802.1AX] section 5.3.5. 2318 - Port Priority 2320 Two octets, LACP administrative port priority for the 2321 corresponding interface, as specified in [IEEE-802.1AX] section 2322 5.3.4. This field is valid only when the "Flags" field has 2323 "Priority Set" asserted. 2325 - Port Speed 2327 Four octets integer encoding the port's current bandwidth in 2328 units of 1,000,000 bits per second. This field corresponds to the 2329 ifHighSpeed object of IF-MIB [RFC2863]. 2331 - Flags 2333 Valid values are: 2335 -i. Synchronized (0x01) 2337 Indicates that the sender has concluded transmitting all 2338 member link port configurations for a given Aggregator. 2340 -ii. Purge Configuration (0x02) 2342 Indicates that the port is no longer configured for 2343 mLACP operation. 2345 -iii. Priority Set (0x04) 2347 Indicates that the "Port Priority" field is valid. 2349 - Port Name Len 2351 One octet, length of the "Port Name" field in octets. 2353 - Port Name 2355 This field corresponds to the ifName object of IF-MIB [RFC2863] 2356 encoded in UTF-8 format, and truncated to 20 octets. Port Name 2357 does not include a terminating null character. 2359 7.2.6. mLACP Port Priority TLV 2361 The mLACP Port Priority TLV is sent in the RG Application Data 2362 message. This TLV is used by a device to either advertise its 2363 operational Port Priority to other members in the RG, or to 2364 authoritatively request that a particular member of an RG change its 2365 port priority. 2367 0 1 2 3 2368 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 2369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2370 |U|F| Type=0x0034 | Length | 2371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2372 | OpCode | Port Number | 2373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2374 | Aggregator ID | Last Port Priority | 2375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2376 | Current Port Priority | 2377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2379 - U and F Bits 2381 Both are set to 0. 2383 - Type 2385 set to 0x0034 for "mLACP Port Priority TLV" 2387 - Length 2389 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2390 Length fields. 2392 - OpCode 2394 Two octets identifying the operational code-point for the TLV, 2395 encoded as follows: 2397 0x00 Local Priority Change Notification 2398 0x01 Remote Request for Priority Change 2400 - Port Number 2402 2 octets field representing the LACP Port Number as specified in 2403 [IEEE-802.1AX] section 5.3.4. When the value of this field is 0, 2404 it denotes all ports bound to the Aggregator specified in the 2405 "Aggregator ID" field. When non-zero, the Port Number MUST be 2406 encoded with the Node ID as was discussed above. 2408 - Aggregator ID 2410 Two octets, LACP Aggregator Identifier as specified in [IEEE- 2411 802.1AX] section 5.4.6 2413 - Last Port Priority 2415 Two octets, LACP port priority for the corresponding interface, 2416 as specified in [IEEE-802.1AX] section 5.3.4. For local ports, 2417 this field encodes the previous operational value of port 2418 priority. For remote ports, this field encodes the operational 2419 port priority last known to the PE via notifications received 2420 from its peers in the RG. 2422 - Current Port Priority 2424 Two octets, LACP port priority for the corresponding interface, 2425 as specified in [IEEE-802.1AX] section 5.3.4. For local ports, 2426 this field encodes the new operational value of port priority 2427 being advertised by the PE. For remote ports, this field 2428 specifies the new port priority being requested by the PE. 2430 7.2.7. mLACP Port State TLV 2432 The mLACP Port State TLV is used in the RG Application Data message. 2433 This TLV is used by a device to report its LACP port status to other 2434 members in the RG. 2436 0 1 2 3 2437 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 2438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2439 |U|F| Type=0x0035 | Length | 2440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2441 | Partner System ID | 2442 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2443 | | Partner System Priority | 2444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2445 | Partner Port Number | Partner Port Priority | 2446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2447 | Partner Key | Partner State | Actor State | 2448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2449 | Actor Port Number | Actor Key | 2450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2451 | Selected | Port State | Aggregator ID | 2452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2453 - U and F Bits 2455 Both are set to 0. 2457 - Type 2459 set to 0x0035 for "mLACP Port State TLV" 2461 - Length 2463 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2464 Length fields. 2466 - Partner System ID 2468 6 octets, the LACP Partner System ID for the corresponding 2469 interface, encoded as a MAC address as specified in [IEEE- 2470 802.1AX] section 5.4.2.2 item r. 2472 - Partner System Priority 2474 2 octets field specifying the LACP Partner System Priority as 2475 specified in [IEEE-802.1AX] section 5.4.2.2 item q. 2477 - Partner Port Number 2479 2 octets encoding the LACP Partner Port Number as specified in 2480 [IEEE-802.1AX] section 5.4.2.2 item u. The Port Number MUST be 2481 encoded with the Node ID as was discussed above. 2483 - Partner Port Priority 2485 2 octets field encoding the LACP Partner Port Priority as 2486 specified in [IEEE-802.1AX] section 5.4.2.2 item t. 2488 - Partner Key 2490 2 octets field representing the LACP Partner Key as defined in 2491 [IEEE-802.1AX] section 5.4.2.2 item s. 2493 - Partner State 2495 1 octet field encoding the LACP Partner State Variable as defined 2496 in [IEEE-802.1AX] section 5.4.2.2 item v. 2498 - Actor State 2500 1 octet encoding the LACP Actor's State Variable for the port as 2501 specified in [IEEE-802.1AX] section 5.4.2.2 item m. 2503 - Actor Port Number 2505 2 octets field representing the LACP Actor Port Number as 2506 specified in [IEEE-802.1AX] section 5.3.4. The Port Number MUST 2507 be encoded with the Node ID as was discussed above. 2509 - Actor Key 2511 2 octet field encoding the LACP Actor Operational Key as 2512 specified in [IEEE-802.1AX] section 5.3.5. 2514 - Selected 2516 1 octet encoding the LACP 'Selected' variable, defined in [IEEE- 2517 802.1AX] section 5.4.8, as follows: 2519 0x00 SELECTED 2520 0x01 UNSELECTED 2521 0x02 STANDBY 2523 - Port State 2525 1 octet encoding the operational state of the port as follows: 2526 0x00 Up 2527 0x01 Down 2528 0x02 Administrative Down 2529 0x03 Test (e.g. IEEE 802.3ah OAM Intrusive Loopback mode) 2531 - Aggregator ID 2533 Two octets, LACP Aggregator Identifier to which this port is 2534 bound based on the outcome of the LACP selection logic. 2536 7.2.8. mLACP Aggregator State TLV 2538 The mLACP Aggregator State TLV is used in the RG Application Data 2539 message. This TLV is used by a device to report its Aggregator status 2540 to other members in the RG. 2542 0 1 2 3 2543 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 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 |U|F| Type=0x0037 | Length | 2546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2547 | Partner System ID | 2548 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2549 | | Partner System Priority | 2550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2551 | Partner Key | Aggregator ID | 2552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2553 | Actor Key | Agg State | 2554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2556 - U and F Bits 2558 Both are set to 0. 2560 - Type 2562 set to 0x0037 for "mLACP Aggregator State TLV" 2564 - Length 2566 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2567 Length fields. 2569 - Partner System ID 2571 6 octets, the LACP Partner System ID for the corresponding 2572 interface, encoded as a MAC address as specified in [IEEE- 2573 802.1AX] section 5.4.2.2 item r. 2575 - Partner System Priority 2577 2 octets field specifying the LACP Partner System Priority as 2578 specified in [IEEE-802.1AX] section 5.4.2.2 item q. 2580 - Partner Key 2582 2 octets field representing the LACP Partner Key as defined in 2583 [IEEE-802.1AX] section 5.4.2.2 item s. 2585 - Aggregator ID 2587 Two octets, LACP Aggregator Identifier as specified in [IEEE- 2588 802.1AX] section 5.4.6 2590 - Actor Key 2592 2 octet field encoding the LACP Actor Operational Key as 2593 specified in [IEEE-802.1AX] section 5.3.5. 2595 - Agg State 2597 1 octet encoding the operational state of the Aggregator as 2598 follows: 2599 0x00 Up 2600 0x01 Down 2601 0x02 Administrative Down 2602 0x03 Test (e.g. IEEE 802.3ah OAM Intrusive Loopback mode) 2604 7.2.9. mLACP Synchronization Request TLV 2606 The mLACP Synchronization Request TLV is used in the RG Application 2607 Data message. This TLV is used by a device to request from its peer 2608 to re-transmit configuration or operational state. The following 2609 information can be requested: 2611 - system configuration and/or state 2613 - configuration and/or state for a specific port 2615 - configuration and/or state for all ports with a specific LACP key 2617 - configuration and/or state for all mLACP ports 2619 - configuration and/or state for a specific aggregator 2621 - configuration and/or state for all aggregators with a specific 2622 LACP key 2624 - configuration and/or state for all mLACP aggregators 2626 The format of the TLV is as follows: 2628 0 1 2 3 2629 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 2630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2631 |U|F| Type=0x0038 | Length | 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2633 | Request Number |C|S| Request Type | 2634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2635 | Port Number / Aggregator ID | Actor Key | 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2638 - U and F Bits 2640 Both are set to 0. 2642 - Type 2644 set to 0x0038 for "mLACP Synchronization Request TLV" 2646 - Length 2648 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2649 Length fields. 2651 - Request Number 2653 2 octets. Unsigned integer uniquely identifying the request. Used 2654 to match the request with a response. The value of 0 is reserved 2655 for unsolicited synchronization, and MUST NOT be used in the 2656 mLACP Synchronization Request TLV. 2658 - C Bit 2660 Set to 1 if request is for configuration data. Otherwise, set to 2661 0. 2663 - S Bit 2665 Set to 1 if request is for running state data. Otherwise, set to 2666 0. 2668 - Request Type 2670 14-bits specifying the request type, encoded as follows: 2672 0x00 Request System Data 2673 0x01 Request Aggregator Data 2674 0x02 Request Port Data 2675 0x3FFF Request All Data 2677 - Port Number / Aggregator ID 2679 2 octets. When Request Type field is set to 'Request Port Data', 2680 this field encodes the LACP Port Number for the requested port. 2681 When the Request Type field is set to 'Request Aggregator Data', 2682 this field encodes the Aggregator ID of the requested Aggregator. 2683 When the value of this field is 0, it denotes that all ports (or 2684 Aggregators), whose LACP Key is specified in the "Actor Key" 2685 field, are being requested. 2687 - Actor Key 2689 Two octets, LACP Actor key for the corresponding port or 2690 Aggregator. When the value of this field is 0 (and the Port 2691 Number/Aggregator ID field is 0 as well), it denotes that 2692 information for all ports or Aggregators in the system is being 2693 requested. 2695 7.2.10. mLACP Synchronization Data TLV 2697 The mLACP Synchronization Data TLV is used in the RG Application Data 2698 message. A pair of these TLVs is used by a device to delimit a set of 2699 TLVs that are being transmitted in response to an mLACP 2700 Synchronization Request TLV. The delimiting TLVs signal the start and 2701 end of the synchronization data, and associate the response with its 2702 corresponding request via the 'Request Number' field. 2704 The mLACP Synchronization Data TLVs are also used for unsolicited 2705 advertisements of complete mLACP configuration and operational state 2706 data. The 'Request Number' field MUST be set to 0 in this case. For 2707 such unsolicited synchronization, the PE MUST advertise all system, 2708 Aggregator and port information as done during the initialization 2709 sequence. 2711 This TLV has the following format: 2713 0 1 2 3 2714 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 2715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2716 |U|F| Type=0x0039 | Length | 2717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2718 | Request Number | Flags | 2719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2721 - U and F Bits 2723 Both are set to 0. 2725 - Type 2727 set to 0x0039 for "mLACP Synchronization Data TLV" 2729 - Length 2731 Length of the TLV in octets excluding the U-bit, F-bit, Type, and 2732 Length fields. 2734 - Request Number 2736 2 octets. Unsigned integer identifying the Request Number from 2737 the "mLACP Synchronization Request TLV" which solicited this 2738 synchronization data response. 2740 - Flags 2742 2 octets, response flags encoded as follows: 2744 0x00 Synchronization Data Start 2745 0x01 Synchronization Data End 2747 8. LDP Capability Negotiation 2749 As requited in [RFC5561] the following TLV is defined to indicate the 2750 ICCP capability: 2751 0 1 2 3 2752 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 2753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2754 |U|F| TLV Code Point=0x700 | Length | 2755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2756 |S| Reserved | Reserved | VER/Maj | Ver/Min | 2757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2758 where: 2760 - U-bit 2762 SHOULD be 1 (ignore if not understood). 2764 - F-bit 2766 SHOULD be 0 (don't forward if not understood). 2768 - TLV Code Point 2770 The TLV type, which identifies a specific capability. The ICCP 2771 code point is requested in the IANA allocation section below. 2773 - S-bit The State Bit indicates whether the sender is advertising 2774 or withdrawing the ICCP capability. The State bit is used as 2775 follows: 2776 1 - The TLV is advertising the capability specified by the 2777 TLV Code Point. 2779 0 - The TLV is withdrawing the capability specified by the 2780 TLV Code Point. 2782 - Ver/Maj 2784 The major version revision of the ICCP protocol, this document 2785 specifies 1.0. This field is then set to 1 2787 - Ver/Min 2789 The minor version revision of the ICCP protocol, this document 2790 specifies 1.0. This field is then set to 0 2792 ICCP capability is advertised to a LDP peer if there is at least one 2793 RG enabled on the local PE. 2795 9. Client Applications 2797 9.1. Pseudowire Redundancy Application Procedures 2799 This section defines the procedures for the Pseudowire Redundancy 2800 (PW-RED) Application. 2802 It should be noted that the PW-RED application SHOULD NOT be enabled 2803 together with an AC Redundancy application for the same service 2804 instance. This simplifies the operation of the multi-chassis 2805 redundancy solution (Figure 1) and eliminates the possibility of 2806 deadlock conditions between the AC and PW redundancy mechanisms. 2808 9.1.1. Initial Setup 2810 When an RG is configured on a system and multi-chassis pseudowire 2811 redundancy is enabled in that RG, the PW-RED application MUST send an 2812 "RG Connect" message with "PW-RED Connect TLV" to each PE that is a 2813 member of the same RG. The sending PE MUST set the A bit to 1 if it 2814 has already received a "PW-RED Connect TLV" from its peer; otherwise, 2815 the PE MUST set the A bit to 0. If a PE, that has sent the TLV with 2816 the A bit set to 0, receives a "PW-RED Connect TLV" from a peer, it 2817 MUST repeat its advertisement with the A bit set to 1. The PW-RED 2818 application connection is considered to be operational when both PEs 2819 have sent and received "PW-RED Connect TLVs" with the A bit set to 1. 2820 Once the application connection becomes operational, the two devices 2821 can start exchanging "RG Application Data" messages for the PW-RED 2822 application. 2824 If a system receives an "RG Connect" message with "PW-RED Connect 2825 TLV" that has a differing Protocol Version, it must follow the 2826 procedures outlined in the "Application Versioning" section above. 2828 When the PW-RED application is disabled on the device, or is 2829 unconfigured for the RG in question, the system MUST send an "RG 2830 Disconnect" message with "PW-RED Disconnect TLV". 2832 9.1.2. Pseudowire Configuration Synchronization 2834 A system MUST advertise its local PW configuration to other PEs that 2835 are members of the same RG. This allows the PEs to build a view of 2836 the redundant nodes and pseudowires that are protecting the same 2837 service instances. The advertisement MUST be initiated when the PW- 2838 RED application connection first comes up. To that end, the system 2839 sends "RG Application Data" messages with "PW-RED Config TLVs" as 2840 part of an unsolicited synchronization. A PE MUST use a pair of "PW- 2841 RED Synchronization Data TLVs" to delimit the set of TLVs that are 2842 being sent as part of this unsolicited advertisement. 2844 In the case of a configuration change, a PE MUST re-advertise the 2845 most up to date information for the affected pseudowires. 2847 As part of the configuration synchronization, a PE advertises the 2848 ROID associated with the pseudowire. This is used to correlate the 2849 pseudowires that are protecting each other on different PEs. As well, 2850 a PE advertises the configured PW redundancy mode. This can be one of 2851 the following four options: Master Mode, Slave Mode, Independent Mode 2852 or Independent Mode with Request Switchover. If the received 2853 redundancy mode does not match the locally configured mode for the 2854 same ROID, then the PE MUST respond with an "RG Notification Message" 2855 to reject the "PW-RED Config TLV". The PE MUST disable the associated 2856 local pseudowire until a satisfactory "PW-RED Config TLV" is received 2857 from the peer. This guarantees that device mis-configuration does not 2858 lead to network wide problems (e.g. by creating forwarding loops). 2859 The PE SHOULD also raise an alarm to alert the operator. If a PE 2860 receives a NAK TLV for an advertised "PW-RED Config TLV", it MUST 2861 disable the associated pseudowire and SHOULD raise an alarm to alert 2862 the operator. 2864 Furthermore, a PE advertises in its "PW-RED Config TLVs" a priority 2865 value that is used to determine the precedence of a given pseudowire 2866 to assume the Active role in a redundant setup. A PE also adverties a 2867 Service Name that is global in the context of an RG and is used to 2868 identify which pseudowires belong to the same service. Finally, a PE 2869 also advertises the pseudowire identifier as part of this 2870 synchronization. 2872 9.1.3. Pseudowire Status Synchronization 2874 PEs, that are member of an RG, synchronize pseudowire status for the 2875 purpose of identifying, on a per ROID basis, which pseudowire will be 2876 actively used for forwarding and which pseudowire(s) will be placed 2877 in standby state. 2879 Synchronization of pseudowire status is done by sending the "PW-RED 2880 State TLV" whenever the pseudowire state changes on a PE. This 2881 includes changes to the local end as well as the remote end of the 2882 pseudowire. 2884 A PE may request that its peer retransmit previously advertised PW- 2885 RED state. This is useful for instance when the PE is recovering from 2886 a soft failure. To request such retransmission, a PE MUST send a set 2887 of one or more "PW-RED Synchronization Request TLVs". 2889 A PE MUST respond to a "PW-RED Synchronization Request TLV" by 2890 sending the requested data in a set of one or more PW-RED TLVs 2891 delimited by a pair of "PW-RED Synchronization Data TLVs". The TLVs 2892 comprising the response MUST be ordered such that the Synchronization 2893 Response TLV with the "Synchronization Data Start" flag precedes the 2894 various other PW-RED TLVs encoding the requested data. These, in 2895 turn, MUST precede the Synchronization Data TLV with the 2896 "Synchronization Data End" flag. It is worth noting that the response 2897 may span across multiple RG Application Data messages; however, the 2898 above TLV ordering MUST be retained across messages, and only a 2899 single pair of Synchronization Data TLVs must be used to delimit the 2900 response across all Application Data Messages. 2902 A PE MAY re-advertise its PW-RED state in an unsolicited manner. This 2903 is done by sending the appropriate config and state TLVs delimited by 2904 a pair of "PW-RED Synchronization Data TLVs" and using a 'Request 2905 Number' of 0. 2907 While a PE has a pending synchronization request for a pseudowire or 2908 a service, it SHOULD silently ignore all TLVs for said pseudowire or 2909 service that are received prior to the synchronization response and 2910 which carry the same type of information being requested. This saves 2911 the system from the burden of updating state that will ultimately be 2912 overwritten by the synchronization response. Note that TLVs 2913 pertaining to other pseudowires or services are to continue to be 2914 processed per normal in the interim. 2916 If a PE receives a synchronization request for a pseudowire or 2917 service that doesn't exist or is not known to the PE, then it MUST 2918 trigger an unsolicited synchronization of all pseudowire information 2919 (i.e. replay the initialization sequence). 2921 In the subsections that follow, we describe the details of pseudowire 2922 status synchronization for each of the PW redundancy modes defined in 2923 [RFC6870]. 2925 9.1.3.1. Independent Mode 2927 This section covers the operation in Independent Mode with or without 2928 Request Switchover capability. 2930 In this mode, the operator must ensure that for a given RO, the PW 2931 Priority values configured for all associated pseudowires on a given 2932 PE are collectively higher (or lower) than those configured on other 2933 PEs in the same RG. If this condition is not satisfied after the PEs 2934 have exchanged "PW-RED State TLVs", a PE MUST disable the associated 2935 pseudowire(s) and SHOULD raise an alarm to alert the operator. Note 2936 that the PW Priority MAY be the same as the PW Precedence defined in 2937 [RFC6870]. 2939 For a given RO, after the all the PEs in an RG have exchanged their 2940 "PW-RED State TLVs", the PE with the best PW Priority (i.e. least 2941 numeric value) advertises Active preferential forwarding status in 2942 LDP on all its associated pseudowires. Whereas, all other PEs in the 2943 RG advertise Standby preferential forwarding status in LDP on their 2944 associated pseudowires. 2946 If the service is VPWS, then only a single pseudowire per service 2947 will be selected for forwarding. This is the pseudowire that is 2948 independently advertised with Active preferential forwarding status 2949 on both endpoints, as described in [RFC6870]. 2951 If the service is VPLS, then one or multiple pseudowires per service 2952 will be selected for forwarding. These are the pseudowires that are 2953 independently advertised with Active preferential forwarding status 2954 on both PW endpoints, as described in [RFC6870]. 2956 9.1.3.2. Master/Slave Mode 2958 In this mode, the operator must ensure that for a given RO, the PW 2959 Priority values configured for all associated pseudowires on a given 2960 PE are collectively higher (or lower) than those configured on other 2961 PEs in the same RG. If this condition is not satisfied after the PEs 2962 have exchanged "PW-RED State TLVs", a PE MUST disable the associated 2963 pseudowire(s) and SHOULD raise an alarm to alert the operator. Note 2964 that the PW Priority MAY be the same as the PW Precedence defined in 2965 [RFC6870]. In addition, the operator must ensure that, for a given 2966 RO, all the PEs in the RG are consistently configured as Master or 2967 Slave. 2969 In the context of a given RO, if the PEs in the RG are acting as 2970 Master, then the PE with the best PW Priority (i.e. least numeric 2971 value) advertises Active preferential forwarding status in LDP on 2972 only a single pseudowire, following the procedures in sections 5.2 2973 and 6.2 of [RFC6870]. Whereas, all the other pseudowires on other PEs 2974 in the RG are advertised with Standby preferential forwarding status 2975 in LDP. 2977 9.1.4. PE Node Failure or Isolation 2979 When a PE node detects that a remote PE, that is member of the same 2980 RG, is no longer reachable (using the mechanisms of Section 5), the 2981 local PE examines if it has redundant PWs for the affected services. 2982 If the local PE has the highest priority (after the failed PE) then 2983 it becomes the active node for the services in question, and 2984 subsequently activates its associated PW(s). 2986 9.2. Attachment Circuit Redundancy Application Procedures 2988 9.2.1. Common AC Procedures 2990 This section describes generic procedures for AC Redundancy 2991 applications, independent of the type of the AC (ATM, FR or 2992 Ethernet). 2994 9.2.1.1. AC Failure 2996 When the AC Redundancy mechanism on the Active PE detects a failure 2997 of the AC, it should send an ICCP Application Data message to inform 2998 the redundant PEs of the need to take over. The AC failures can be 2999 categorized into the following scenarios: 3001 - Failure of CE interface connecting to PE 3003 - Failure of CE uplink to PE 3005 - Failure of PE interface connecting to CE 3007 9.2.1.2. Remote PE Node Failure or Isolation 3009 When a PE node detects that a remote PE, that is member of the same 3010 RG, is no longer reachable (using the mechanisms of Section 5), the 3011 local PE examines if it has redundant ACs for the affected services. 3012 If the local PE has the highest priority (after the failed PE) then 3013 it becomes the active node for the services in question, and 3014 subsequently activates its associated ACs. 3016 9.2.1.3. Local PE Isolation 3018 When a PE node detects that is has been isolated from the core 3019 network (i.e. all core facing interfaces/links are not operational), 3020 then it should ensure that its AC Redundancy mechanism will change 3021 the status of any active ACs to Standby. The AC Redundancy 3022 application SHOULD then send ICCP Application Data messages in order 3023 to trigger failover to a standby PE. Note that this works only in the 3024 case of dedicated interconnect (Sections 3.2.1 and 3.2.3) since ICCP 3025 will still have a path to the peer, even though the PE is isolated 3026 from the MPLS core network. 3028 9.2.1.4. Determining Pseudowire State 3030 If the PEs in an RG are running an AC Redundancy application over 3031 ICCP, then the Independent Mode of PW Redundancy, as defined in 3032 [RFC6870], MUST be used. On a given PE, the Preferential Forwarding 3033 status of the PW (Active or Standby) is derived from the state of the 3034 associated AC(s). This simplifies the operation of the multi-chassis 3035 redundancy solution (Figure 1) and eliminates the possibility of 3036 deadlock conditions between the AC and PW redundancy mechanisms. The 3037 rules by which the PW status is derived from the AC status are as 3038 follows: 3040 - VPWS 3042 For VPWS, there's a single AC per service instance. If the AC is 3043 Active, then the PW status should be Active. If the AC is 3044 Standby, then the PW status should be Standby. 3046 - VPLS 3048 For VPLS, there could be multiple ACs per service instance (i.e. 3049 VFI). If AT LEAST ONE AC is Active, then the PW status should be 3050 Active. If ALL ACs are Standby, then the PW status should be 3051 Standby. 3053 In this case, the PW-RED application is not used to synchronize PW 3054 status between PEs. Rather, the AC Redundancy application should 3055 synchronize AC status between PE, in order to establish which AC (and 3056 subsequently which PE) is Active or Standby for a given service. When 3057 that is determined, each PE will then derive its local PWs state 3058 according to the rules described above. The Preferential Forwarding 3059 status bit, described in [RFC6870], is used to advertise PW status to 3060 the remote peers. 3062 9.2.2. Multi-chassis LACP (mLACP) Application Procedures 3064 This section defines the procedures that are specific to the multi- 3065 chassis LACP (mLACP) application, which is applicable for Ethernet 3066 ACs. 3068 9.2.2.1. Initial Setup 3070 When an RG is configured on a system and mLACP is enabled in that RG, 3071 the mLACP application MUST send an "RG Connect" message with "mLACP 3072 Connect TLV" to each PE that is member of the same RG. The sending PE 3073 MUST set the A bit to 1 in the said TLV if it has received a 3074 corresponding "mLACP Connect TLV" from its peer PE; otherwise, the 3075 sending PE MUST set the A bit to 0. If a PE receives an "mLACP 3076 Connect TLV" from its peer after sending the said TLV with the A bit 3077 set to 0, it MUST resend the TLV with the A bit set to 1. A system 3078 considers the mLACP application connection to be operational when it 3079 has sent and received "mLACP Connect TLVs" with the A bit set to 1. 3080 When the mLACP application connection between a pair of PEs is 3081 operational, the two devices can start exchanging "RG Application 3082 Data" messages for the mLACP application. This involves having each 3083 PE advertise its mLACP configuration and operational state in an 3084 unsolicited manner. A PE SHOULD subscribe to the following order when 3085 advertising its mLACP state upon initial application connection 3086 setup: 3088 - Advertise system configuration 3089 - Advertise Aggregator configuration 3090 - Advertise port configuration 3091 - Advertise Aggregator state 3092 - Advertise port state 3094 A PE MUST use a pair of "mLACP Synchronization Data TLVs" to delimit 3095 the entire set of TLVs that are being sent as part of this 3096 unsolicited advertisement. 3098 If a system receives an "RG Connect" message with "mLACP Connect TLV" 3099 that has a differing Protocol Version, it MUST follow the procedures 3100 outlined in the "Application Versioning" section above. 3102 After the mLACP application connection has been established, every PE 3103 MUST communicate its system level configuration to its peers via the 3104 use of "mLACP System Config TLV". This allows every PE to discover 3105 the Node ID and the locally configured System ID and System Priority 3106 values of its peers. 3108 If a PE receives an "mLACP System Config TLV" from a remote peer 3109 advertising the same Node ID value as the local system, then the PE 3110 MUST respond with an "RG Notification Message" to reject the "mLACP 3111 System Config TLV". The PE MUST suspend the mLACP application until a 3112 satisfactory "mLACP System Config TLV" is received from the peer. It 3113 SHOULD also raise an alarm to alert the operator. Furthermore, if a 3114 PE receives a NAK TLV for an "mLACP System Config TLV" that it has 3115 advertised, the PE MUST suspend the mLACP application and SHOULD 3116 raise an alarm to alert the network operator of potential device 3117 mis-configuration. 3119 If a PE receives an "mLACP System Config TLV" from a new peer 3120 advertising the same Node ID value as another existing peer with 3121 which the local system has an established mLACP Application 3122 connection, then the PE MUST respond to the new peer with an "RG 3123 Notification Message" to reject the "mLACP System Config TLV" and 3124 MUST ignore the offending TLV. 3126 If the Node ID of a particular PE changes due to administrative 3127 configuration action, the PE MUST then inform its peers to purge the 3128 configuration of all previously advertised ports and/or aggregators, 3129 and MUST replay the initialization sequence by sending an unsolicited 3130 synchronization of: the system configuration, Aggregator 3131 configuration, port configuration, Aggregator state and port state. 3133 It is necessary for all PEs in an RG to agree upon the System ID and 3134 System Priority values to be used ubiquitously. To achieve this, 3135 every PE MUST use the values for the two parameters that are supplied 3136 by the PE with the numerically lowest value (among RG members) of 3137 System Aggregation Priority. This guarantees that the PEs always 3138 agree on uniform values, which yield the highest System Priority. 3140 When the mLACP application is disabled on the device, or is 3141 unconfigured for the RG in question, the system MUST send an "RG 3142 Disconnect" message with "mLACP Disconnect TLV". 3144 9.2.2.2. mLACP Aggregator and Port Configuration 3146 A system MUST synchronize the configuration of its mLACP enabled 3147 Aggregators and ports with other RG members. This is achieved via the 3148 use of "mLACP Aggregator Config TLVs" and "mLACP Port Config TLVs", 3149 respectively. An implementation MUST advertise the configuration of 3150 Aggregators prior to advertising the configuration of any of their 3151 associated member ports. 3153 The PEs in an RG MUST all agree on the MAC address to be associated 3154 with a given Aggregator. It is possible to achieve this via 3155 consistent configuration on member PEs. However, in order to protect 3156 against possible misconfiguration, a system MUST use, for any given 3157 Aggregator, the MAC address supplied by the PE with the numerically 3158 lowest System Aggregation Priority in the RG. 3160 A system that receives an "mLACP Aggregator Config TLV" with an ROID 3161 to Key association that is different from its local association MUST 3162 reject the corresponding TLV and disable the Aggregator with the same 3163 ROID. Furthermore, it SHOULD raise an alarm to alert the operator. 3164 Similarly, a system that receives a NAK TLV in response to a 3165 transmitted "mLACP Aggregator Config TLV" MUST disable the associated 3166 Aggregator and SHOULD raise an alarm to alert the network operator. 3168 A system MAY enforce a restriction that all ports that are to be 3169 bundled together on a given PE share the same Port Priority value. If 3170 so, the system MUST advertise this common priority in the "mLACP 3171 Aggregator Config TLV" and assert the "Priority Set" flag in such 3172 TLV. Furthermore, the system in this case MUST NOT advertise 3173 individual Port Priority values in the associated "mLACP Port Config 3174 TLVs" (i.e. the "Priority Set" flag in these TLVs should be 0). 3176 A system MAY support individual Port Priority values to be configured 3177 on ports that are to be bundled together on a PE. If so, the system 3178 MUST advertise the individual Port Priority values in the appropriate 3179 "mLACP Port Config TLVs", and MUST NOT assert the "Priority Set" flag 3180 in the corresponding "mLACP Aggregator Config TLV". 3182 When the configurations of all ports for member links associated with 3183 a given Aggregator have been sent by a device, it asserts that fact 3184 by setting the "Synchronized" flag in the last port's "mLACP Port 3185 Config TLV". If an Aggregator doesn't have any candidate member ports 3186 configured, this is indicated by asserting the "Synchronized" flag in 3187 its "mLACP Aggregator Config TLV". 3189 Furthermore, for a given port/Aggregator, an implementation MUST 3190 advertise the port/Aggregator configuration prior to advertising its 3191 state (via the "mLACP Port State TLV" or "mLACP Aggregator State 3192 TLV"). If a PE receives an "mLACP Port State TLV" or "mLACP 3193 Aggregator State TLV" for a port or Aggregator that it had not 3194 learned of before via an appropriate Port or Aggregator Config TLV, 3195 then the PE MUST request synchronization of the configuration and 3196 state of all mLACP ports as well as all mLACP Aggregators from its 3197 respective peer. If during a synchronization (solicited or 3198 unsolicited), a PE receives a State TLV for a port or Aggregator that 3199 it has not learned of before, then the PE MUST send a NAK TLV for the 3200 offending TLV. The PE MUST NOT request re-synchronization in this 3201 case. 3203 When mLACP is unconfigured on a port/Aggregator, a PE MUST send a 3204 "Port/Aggregator Config TLV" with the "Purge Configuration" flag 3205 asserted. This allows receiving PEs to purge any state maintained for 3206 the decommissioned port/Aggregator. If a PE receives a 3207 "Port/Aggregator Config TLV" with the "Purge Configuration" flag 3208 asserted, and the PE is not maintaining any state for that 3209 port/Aggregator, then it MUST silently discard the TLV. 3211 9.2.2.3. mLACP Aggregator and Port Status Synchronization 3213 PEs within an RG need to synchronize their state-machines for proper 3214 mLACP operation with a multi-homed device. This is achieved by having 3215 each system advertise its Aggregators and ports running state in 3216 "mLACP Aggregator State TLVs" and "mLACP Port State TLVs", 3217 respectively. Whenever any LACP parameter for an Aggregator or a 3218 port, whether on the Partner (i.e. multi-homed device) or the Actor 3219 (i.e. PE) side, is changed a system MUST transmit an updated TLV for 3220 the affected Aggregator and/or port. Moreover, when the 3221 administrative or operational state of an Aggregator or port changes, 3222 the system MUST transmit an updated Aggregator or port state TLV to 3223 its peers. 3225 If a PE receives an Aggregator or port state TLV where the 'Actor 3226 Key' doesn't match what was previously received in a corresponding 3227 Aggregator or port config TLV, the PE MUST then request 3228 synchronization of the configuration and state of the affected 3229 Aggregator or port. If such a mismatch occurs between the config and 3230 state TLVs as part of a synchronization (solicited or unsolicited), 3231 then the PE MUST send a NAK TLV for the state TLV. Furthermore, if a 3232 PE receives a port state TLV with the 'Aggregator ID' set to a value 3233 that doesn't map to some Aggregator that the PE had learned of via a 3234 previous Aggregator config TLV, then the PE MUST request 3235 synchronization of the configuration and state of all Aggregators and 3236 ports. If the above anomaly occurs during a synchronization, then the 3237 PE MUST send a NAK TLV for the offending port state TLV. 3239 A PE MAY request that its peer retransmit previously advertised 3240 state. This is useful for example when the PE is recovering from a 3241 soft failure and attempting to relearn state. To request such 3242 retransmissions, a PE MUST send a set of one or more "mLACP 3243 Synchronization Request TLVs". 3245 A PE MUST respond to an "mLACP Synchronization Request TLV" by 3246 sending the requested data in a set of one or more mLACP TLVs 3247 delimited by a pair of "mLACP Synchronization Data TLVs". The TLVs 3248 comprising the response MUST be ordered in the RG Application Data 3249 message(s) such that the Synchronization Response TLV with the 3250 "Synchronization Data Start" flag precedes the various other mLACP 3251 TLVs encoding the requested data. These, in turn, MUST precede the 3252 Synchronization Data TLV with the "Synchronization Data End" flag. 3253 Note that the response may span across multiple RG Application Data 3254 messages, for example when MTU limits are exceeded; however, the 3255 above ordering MUST be retained across messages, and only a single 3256 pair of Synchronization Data TLVs MUST be used to delimit the 3257 response across all Application Data Messages. 3259 A PE device MAY re-advertise its mLACP state in an unsolicited 3260 manner. This is done by sending the appropriate Config and State TLVs 3261 delimited by a pair of "mLACP Synchronization Data TLVs" and using a 3262 'Request Number' of 0. 3264 While a PE has a pending synchronization request for a system, 3265 Aggregator or port, it SHOULD silently ignore all TLVs for said 3266 system, Aggregator or port that are received prior to the 3267 synchronization response and which carry the same type of information 3268 being requested. This saves the system from the burden of updating 3269 state that will utlimately be overwritten by the synchronization 3270 response. Note that TLVs pertaining to other systems, Aggregators or 3271 ports are to continue to be processed per normal in this case. 3273 If a PE receives a synchronization request for an Aggregator, port or 3274 Key that doesn't exist or is not known to the PE, then it MUST 3275 trigger an unsolicited synchronization of all system, Aggregator and 3276 port information (i.e. replay the initialization sequence). 3278 If a PE learns, as part of a synchronization operation from its peer, 3279 that the latter is advertising a Node ID value which is different 3280 from the value previously advertised, then the PE MUST purge all 3281 port/aggregator data previously learnt from that peer prior to the 3282 last synchronization. 3284 9.2.2.4. Failure and Recovery 3286 When a PE that is active for a multi-chassis link aggregation group 3287 encounters a core isolation fault, it SHOULD attempt to fail-over to 3288 a peer PE which hosts the same RO. The default fail-over procedure is 3289 to have the failed PE bring down the link(s) towards the multi-homed 3290 CE (e.g. by bringing down the line-protocol). This will cause the CE 3291 to fail-over to the other member link(s) of the bundle that are 3292 connected to the other PE(s) in the RG. Other procedures for 3293 triggering fail-over are possible, and are outside the scope of this 3294 document. 3296 Upon recovery from a previous fault, a PE MAY reclaim active role for 3297 a multi-chassis link aggregation group if configured for revertive 3298 protection. Otherwise, the recovering PE may assume standby role 3299 when configured for non-revertive protection. In the revertive 3300 scenario, a PE SHOULD assume active role within the RG by sending an 3301 "mLACP Port Priority TLV" to the currently active PE, requesting that 3302 the latter change its port priority to a value that is lower (i.e. 3303 numerically larger) for the Aggregator in question. 3305 If a system is operating in a mode where different ports of a bundle 3306 are configured with different Port Priorities, then the system MUST 3307 NOT advertise or request change of Port Priority values for 3308 aggregated ports collectively (i.e. by using a 'Port Number' of 0 in 3309 the "mLACP Port Priority TLV"). This is to avoid ambiguity in the 3310 interpretation of the 'Last Port Priority' field. 3312 If a PE receives an "mLACP Port Priority TLV" requesting a priority 3313 change for a port or Aggregator that is not local to the device, then 3314 the PE MUST re-advertise the local configuration of the system, as 3315 well as the configuration and state of all its mLACP ports and 3316 Aggregators. 3318 If a PE receives an "mLACP Port Priority TLV" in which the remote 3319 system is advertising priority change for a port or Aggregator that 3320 the local PE had not learned of before via an appropriate Port or 3321 Aggregator Config TLV, then the PE MUST request synchronization of 3322 the configuration and state of all mLACP ports as well as all mLACP 3323 Aggregators from its respective peer. 3325 10. Security Considerations 3327 ICCP SHOULD only be used in well managed and highly monitored 3328 networks. It ought not be deployed on or over the public Internet. 3329 The ICCP protocol is not intended to be applicable when the 3330 redundancy group spans PE in different administrative domains. 3332 The security considerations described in [RFC5036] and [RFC4447] that 3333 apply to the base LDP specification, and to the PW LDP control 3334 protocol extensions apply to the capability mechanism described in 3335 this document. In particular, ICCP implementations MUST provide a 3336 mechanism to select to which LDP peers the ICCP capability will be 3337 advertised, and from which LDP peers the ICCP messages will be 3338 accepted. Therefore, an incoming ICCP connection request MUST NOT be 3339 accepted unless its source IP address is known to be the source of an 3340 "eligible" ICCP peer. The set of eligible peers could be pre- 3341 configured (either as a list of IP addresses, or as a list of 3342 address/mask combinations), or it could be discovered dynamically via 3343 some secure discovery protocol. The TCP Authentication Option (TCP- 3344 AO), as defined in [RFC5925], SHOULD be used. This provides integrity 3345 and authentication for the ICCP messages and eliminates the 3346 possiblity of source address spoofing. However, for backwards 3347 compatibility and/or to accommodate the ease of migration, the LDP 3348 MD5 authentication key option, as described in section 2.9 of 3349 [RFC5036] MAY be used instead. 3351 The security framework and considerations for MPLS in general, and 3352 LDP in particular, described in [RFC5920] apply to this document. 3353 Moreover, the recommendations of [RFC6952] and mechanisms of [LDP- 3354 CRYPTO] aimed at addressing LDP's vulnerabilities are applicable as 3355 well. 3357 Furthermore, activitiy on the attachment ciruits may cause security 3358 threats or be exploited to create denial of service attackes. For 3359 example, a malicious CE implementation may trigger continuously 3360 variying LACP messages that lead to excessive ICCP exchanges. Also, 3361 excessive link bouncing of the attachment circuits may lead to the 3362 same effect. Similar arguments apply to the inter-PE MPLS links. 3363 Implementations SHOULD provide mechanisms to perform control-plane 3364 policing and mitigate such types of attacks. 3366 11. Manageability Considerations 3368 Implementations SHOULD generally minimize the number of parameters 3369 required to configure ICCP, as this contributes to the ease of use. 3370 Implementations SHOULD allow the user to control the RGID via 3371 configuration, as this is required to support flexible grouping of 3372 PEs in RGs. Furthermore, implementations SHOULD provide mechanisms to 3373 troubleshoot the correct operation of ICCP, this includes providing 3374 mechanisms to diagnose ICCP as well as Application connections. 3375 Implementations MUST provide a means for the user to indicate the IP 3376 addresses of remote PEs that are to be members of a given RG. 3377 Automatic discovery of RG membership MAY be supported, and is outside 3378 the scope of this specification. 3380 12. IANA Considerations 3382 12.1. MESSAGE TYPE NAME SPACE 3384 This document uses several new LDP message types, IANA already 3385 maintains a registry of name "MESSAGE TYPE NAME SPACE" defined by 3386 [RFC5036]. The following values are suggested for assignment: 3388 Message type Description 3389 0x0700 RG Connect Message 3390 0x0701 RG Disconnect Message 3391 0x0702 RG Notification Message 3392 0x0703 RG Application Data Message 3393 0x0704-0x070F Reserved for future ICCP use 3395 12.2. TLV TYPE NAME SPACE 3397 This document uses a new LDP TLV type, IANA already maintains a 3398 registry of name "TLV TYPE NAME SPACE" defined by [RFC5036]. The 3399 following value is suggested for assignment: 3400 TLV Type Description 3401 0x700 ICCP capability TLV. 3403 12.3. ICC RG Parameter Type Space 3405 IANA needs to set up a registry of "ICC RG parameter type", to be 3406 added to the list of "Pseudowire Name Spaces (PWE3)" registries. ICC 3407 RG parameter types are 14-bit values. Parameter Type values 1 through 3408 0x003A are specified in this document, Parameter Type values 0x003B 3409 through 0x1FFF are to be assigned by IANA, using the "Expert Review" 3410 policy defined in [RFC5226]. Parameter Type values 0x2000 through 3411 0x2FFF, 0x3FFF, and 0 are to be allocated using the IETF consensus 3412 policy defined in [RFC5226]. Parameter Type values 0x3000 through 3413 0x3FFE are reserved for vendor proprietary extensions and are to be 3414 assigned by IANA, using the "First Come First Served" policy defined 3415 in [RFC5226]. 3417 Initial ICC parameter type space value allocations are specified 3418 below: 3420 Parameter Type Description 3421 -------------- --------------------------------- 3422 0x0001 ICC Sender Name 3423 0x0002 NAK TLV 3424 0x0003 Requested Protocol Version TLV 3425 0x0004 Disconnect Code TLV 3426 0x0005 ICC RG ID TLV 3427 0x0006-0x000F Reserved 3428 0x0010 PW-RED Connect TLV 3429 0x0011 PW-RED Disconnect TLV 3430 0x0012 PW-RED Config TLV 3431 0x0013 Service Name TLV 3432 0x0014 PW ID TLV 3433 0x0015 Generalized PW ID TLV 3434 0x0016 PW-RED State TLV 3435 0x0017 PW-RED Synchronization Request TLV 3436 0x0018 PW-RED Synchronization Data TLV 3437 0x0019 PW-RED Disconnect Cause TLV 3438 0x001A-0x002F Reserved 3439 0x0030 mLACP Connect TLV 3440 0x0031 mLACP Disconnect TLV 3441 0x0032 mLACP System Config TLV 3442 0x0033 mLACP Port Config TLV 3443 0x0034 mLACP Port Priority TLV 3444 0x0035 mLACP Port State TLV 3445 0x0036 mLACP Aggregator Config TLV 3446 0x0037 mLACP Aggregator State TLV 3447 0x0038 mLACP Synchronization Request TLV 3448 0x0039 mLACP Synchronization Data TLV 3449 0x003A mLACP Disconnect Cause TLV 3451 12.4. STATUS CODE NAME SPACE 3453 This document use several new Status codes, IANA already maintains a 3454 registry of name "STATUS CODE NAME SPACE" defined by [RFC5036]. The 3455 following values is suggested for assignment: The "E" column is the 3456 required setting of the Status Code E-bit. 3457 Range/Value E Description 3458 ------------- ----- ---------------------- 3459 0x00010001 0 Unknown ICCP RG 3460 0x00010002 0 ICCP Connection Count Exceeded 3461 0x00010003 0 ICCP Application Connection 3462 Count Exceeded 3463 0x00010004 0 ICCP Application not in RG 3464 0x00010005 0 Incompatible ICCP Protocol Version 3465 0x00010006 0 ICCP Rejected Message 3466 0x00010007 0 ICCP Administratively Disabled 3467 0x00010010 0 ICCP RG Removed 3468 0x00010011 0 ICCP Application Removed from RG 3470 13. Acknowledgments 3472 The authors wish to acknowledge the important contributions of Dennis 3473 Cai, Neil McGill, Amir Maleki, Dan Biagini, Robert Leger, Sami 3474 Boutros, Neil Ketley and Mark Christopher Sains. 3476 The authors also thank Daniel Cohn, Lizhong Jin and Ran Chen for the 3477 valuable input, discussions and comments. 3479 14. Normative References 3481 [RFC5036] L. Andersson et al, "LDP Specification", RFC 5036, 3482 October 2007. 3484 [RFC5561] "LDP Capabilities", RFC5561, July 2009. 3486 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., 3487 et al., rfc4447 April 2006. 3489 [IEEE-802.1AX] IEEE Std. 802.1AX-2008, "IEEE Standard for Local and 3490 metropolitan area networks- Link Aggregation", IEEE Computer 3491 Society, November 2008. 3493 [RFC2863] K. McCloghrie, F. Kastenholz, "The Interfaces Group MIB", 3494 rfc2863, June 2000. 3496 [RFC6870] Praveen Muley, Mustapha Aissaoui, "Pseudowire 3497 Preferential Forwarding Status Bit", RFC 6870, 3498 February 2013. 3500 [RFC5920] L. Fang, "Security Framework for MPLS and GMPLS Networks", 3501 rfc5920, July 2010. 3503 [RFC6952] M. Jethanandani et al., "Analysis of BGP, LDP, PCEP, and 3504 MSDP Issues According to the Keying and Authentication for Routing 3505 Protocols (KARP) Design Guide", rfc6952, May 2013. 3507 [RFC5925] J. Touch et al., "The TCP Authentication Option", RFC 5925, 3508 June 2010. 3510 15. Informative References 3512 [RFC2922] Bierman & Jones, "Physical Topology MIB", 3513 RFC2922, September 2000. 3515 [RFC5880] D. Katz, D. Ward, "Bidirectional Forwarding Detection", 3516 RFC5880, June 2010 3518 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3519 IANA Considerations section in RFCs", BCP 26, RFC 5226, May 2008 3521 [RFC3629] F. Yergeau, "UTF-8, a transformation format of ISO 10646", 3522 STD 63, RFC 3629, November 2003. 3524 [LDP-CRYPTO] L. Zheng et al., "LDP Hello Cryptographic Autentication", 3525 draft-ietf-mpls-ldp-hello-crypto-auth-02, work in progress, 3526 August 2013. 3528 16. Author's Addresses 3530 Luca Martini 3531 Cisco Systems, Inc. 3532 9155 East Nichols Avenue, Suite 400 3533 Englewood, CO, 80112 3534 e-mail: lmartini@cisco.com 3535 Samer Salam 3536 Cisco Systems, Inc. 3537 595 Burrard Street, Suite 2123 3538 Vancouver, BC V7X 1J1 3539 Canada 3540 e-mail: ssalam@cisco.com 3542 Ali Sajassi 3543 Cisco Systems, Inc. 3544 170 West Tasman Drive 3545 San Jose, CA 95134 3546 e-mail: sajassi@cisco.com 3548 Matthew Bocci 3549 Alcatel-Lucent 3550 Grove House, Waltham Road Rd 3551 White Waltham, Berks, UK. SL6 3TN 3552 e-mail: matthew.bocci@alcatel-lucent.co.uk 3554 Satoru Matsushima 3555 Softbank Telecom 3556 1-9-1, Higashi-Shinbashi, Minato-ku 3557 Tokyo 105-7313, JAPAN 3558 e-mail: satoru.matsushima@gmail.com 3560 Thomas Nadeau 3561 Brocade 3562 e-mail: tnadeau@brocade.com 3564 Copyright Notice 3566 Copyright (c) 2014 IETF Trust and the persons identified as the 3567 document authors. All rights reserved. 3569 This document is subject to BCP 78 and the IETF Trust's Legal 3570 Provisions Relating to IETF Documents 3571 (http://trustee.ietf.org/license-info) in effect on the date of 3572 publication of this document. Please review these documents 3573 carefully, as they describe your rights and restrictions with respect 3574 to this document. Code Components extracted from this document must 3575 include Simplified BSD License text as described in Section 4.e of 3576 the Trust Legal Provisions and are provided without warranty as 3577 described in the Simplified BSD License. 3579 This document may contain material from IETF Documents or IETF 3580 Contributions published or made publicly available before November 3581 10, 2008. The person(s) controlling the copyright in some of this 3582 material may not have granted the IETF Trust the right to allow 3583 modifications of such material outside the IETF Standards Process. 3584 Without obtaining an adequate license from the person(s) controlling 3585 the copyright in such materials, this document may not be modified 3586 outside the IETF Standards Process, and derivative works of it may 3587 not be created outside the IETF Standards Process, except to format 3588 it for publication as an RFC or to translate it into languages other 3589 than English.