idnits 2.17.1 draft-ietf-pwe3-control-protocol-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 246 has weird spacing: '...re also proto...' == Line 462 has weird spacing: '... The highe...' == Line 463 has weird spacing: '...resence of a...' == Line 546 has weird spacing: '...sist of an At...' == Line 549 has weird spacing: '...ntifier may b...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2003) is 7740 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3036' is mentioned on line 122, but not defined ** Obsolete undefined reference: RFC 3036 (Obsoleted by RFC 5036) == Missing Reference: 'PWE3-FRAME' is mentioned on line 150, but not defined == Missing Reference: 'LDP' is mentioned on line 657, but not defined == Missing Reference: '32768' is mentioned on line 886, but not defined == Unused Reference: '4' is defined on line 947, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3036 (ref. '1') (Obsoleted by RFC 5036) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- No information found for draft-ietf-pwe3-frame-encap - is the name correct? -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-14) exists of draft-ietf-pwe3-sonet-01 -- Possible downref: Non-RFC (?) normative reference: ref. '9' == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-atm-encap-00 -- Possible downref: Normative reference to a draft: ref. '11' == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-ethernet-encap-01 -- Possible downref: Normative reference to a draft: ref. '13' == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-iana-allocation-00 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 5 errors (**), 0 flaws (~~), 16 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini 3 Internet Draft Nasser El-Aawar 4 Expiration Date: August 2003 Level 3 Communications, LLC. 6 Toby Smith Eric C. Rosen 7 Laurel Networks, Inc. Cisco Systems, Inc. 8 Giles Heron 9 PacketExchange Ltd. 11 February 2003 13 Pseudowire Setup and Maintenance using LDP 15 draft-ietf-pwe3-control-protocol-02.txt 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 Layer 2 services (such as Frame Relay, ATM, ethernet) can be 40 "emulated" over an IP and/or MPLS backbone by encapsulating the layer 41 2 PDUs and then transmitting them over "pseudowires". It is also 42 possible to use pseudowires to provide SONET circuit emulation over 43 an IP and/or MPLS network. This document specifies a protocol for 44 establishing and maintaining the pseudowires, using extensions to 45 LDP. Procedures for encapsulating layer 2 PDUs are specified in a 46 set of companion documents. 48 Table of Contents 50 1 Specification of Requirements .......................... 3 51 2 Introduction ........................................... 3 52 3 The Pseudowire Label ................................... 5 53 4 Details Specific to Particular Emulated Services ....... 6 54 4.1 Frame Relay ............................................ 6 55 4.2 ATM .................................................... 6 56 4.2.1 ATM AAL5 SDU VCC Transport ............................. 6 57 4.2.2 ATM Transparent Cell Transport ......................... 7 58 4.2.3 ATM n-to-one VCC and VPC Cell Transport ................ 7 59 4.2.4 OAM Cell Support ....................................... 7 60 4.2.5 ILMI Support ........................................... 8 61 4.2.6 IP Layer2 Transport .................................... 8 62 4.2.7 ATM AAL5 PDU VCC Transport ............................. 8 63 4.2.8 ATM one-to-one VCC and VPC Cell Transport .............. 9 64 4.3 Ethernet VLAN .......................................... 9 65 4.4 Ethernet ............................................... 9 66 4.5 HDLC and PPP ........................................... 9 67 5 LDP .................................................... 10 68 5.1 The PWid FEC Element ................................... 10 69 5.2 The Generalized ID FEC Element ......................... 12 70 5.2.1 Attachment Identifiers ................................. 12 71 5.2.2 Encoding the Generalized ID FEC Element ................ 14 72 5.2.3 Procedures ............................................. 15 73 5.3 Interface Parameters Field ............................. 16 74 5.3.1 PW types for which the control word is REQUIRED ........ 18 75 5.3.2 PW types for which the control word is NOT mandatory ... 18 76 5.3.3 Status codes ........................................... 19 77 5.4 LDP label Withdrawal procedures ........................ 20 78 5.5 Sequencing Considerations .............................. 20 79 5.5.1 Label Mapping Advertisements ........................... 20 80 5.5.2 Label Mapping Release .................................. 21 81 6 IANA Considerations .................................... 21 82 7 Security Considerations ................................ 21 83 8 References ............................................. 22 84 9 Author Information ..................................... 23 85 10 Additional Contributing Authors ........................ 24 86 11 Appendix A - C-bit Handling Procedures Diagram ......... 27 88 1. Specification of Requirements 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119. 94 2. Introduction 96 In [7], [10], and [12] it is explained how to encapsulate a layer 2 97 Protocol Data Unit (PDU) for transmission over an IP and/or MPLS 98 network. Those specifications that a "pseudowire header", consisting 99 of a demultiplexor field, will be prepended to the encapsulated PDU. 100 The pseudowire demultiplexor field is put on before transmitting a 101 packet on a pseudowire. When the packet arrives at the remote 102 endpoint of the pseudowire, the demultiplexor is what enables the 103 receiver to identify the particular pseudowire on which the packet 104 has arrived. To actually transmit the packet from one pseudowire 105 endpoint to another, the packet may need to travel through a "PSN 106 tunnel header"; this will require an additional header to be 107 prepended to the packet. 109 An accompanying document [8] also describes a method for transporting 110 time division multiplexed (TDM) digital signals (TDM circuit 111 emulation) over a packet-oriented MPLS network. The transmission 112 system for circuit-oriented TDM signals is the Synchronous Optical 113 Network (SONET)[5]/Synchronous Digital Hierarchy (SDH) [6]. To 114 support TDM traffic, which includes voice, data, and private leased 115 line service, the pseudowires must emulate the circuit 116 characteristics of SONET/SDH payloads. The TDM signals and payloads 117 are encapsulated for transmission over pseudowires. To this 118 encapsulation is prepended a pseudowire demultiplexor and a PSN 119 tunnel header. 121 In this document, we specify the use of the MPLS Label Distribution 122 Protocol, LDP [RFC3036], as a protocol a protocol for setting up and 123 maintaining the pseudowires. In particular, we define new TLVs for 124 LDP, which enable LDP to identify pseudowires and to signal 125 attributes of pseudowires. We specify how a pseudowire endpoint uses 126 these TLVs in LDP to bind a demultiplexor field value to a 127 pseudowire, and how it informs the remote endpoint of the binding. 128 We also specify procedures for reporting pseudowire status changes, 129 passing additional information about the pseudowire as needed, and 130 for releasing the bindings. 132 In the protocol specified herein, the pseudowire demultiplexor field 133 is an MPLS label. Thus the packets which are transmitted from one 134 end of the pseudowire to the other are MPLS packets. Unless the 135 pseudowire endpoints are immediately adjacent, these MPLS packets 136 must be transmitted through a PSN tunnel. Any sort of PSN tunnel can 137 be used, as long as it is possible to transmit MPLS packets through 138 it. The PSN tunnel can itself be an LSP, but it could equally well 139 be an IP tunnel, a GRE tunnel, an IPsec tunnel, or any other sort of 140 tunnel which can carry MPLS packets. Procedures for setting up and 141 maintaining the PSN tunnels are outside the scope of this document. 143 This document deals only with the setup and maintenance of point-to- 144 point pseudowires. Neither point-to-multipoint nor multipoint-to- 145 point pseudowires are discussed. 147 QoS related issues are not discussed in this document. 149 The following two figures describe the reference models which are 150 derived from [PWE3-FRAME] to support the Ethernet PW emulated 151 services. 153 Native |<----- Pseudo Wire ---->| Native 154 Layer2 | | Layer2 155 Service | |<-- PSN Tunnel -->| | Service 156 | V V V V | 157 | +----+ +----+ | 158 +----+ | | PE1|==================| PE2| | +----+ 159 | |----------|............PW1.............|----------| | 160 | CE1| | | | | | | |CE2 | 161 | |----------|............PW2.............|----------| | 162 +----+ | | |==================| | | +----+ 163 ^ +----+ +----+ | ^ 164 | Provider Edge 1 Provider Edge 2 | 165 | | 166 |<-------------- Emulated Service ---------------->| 168 Figure 1: PWE3 Reference Model 170 +-------------+ +-------------+ 171 | Layer2 | | Layer2 | 172 | Emulated | | Emulated | 173 | Services | Emulated Service | Services | 174 | |<==============================>| | 175 +-------------+ Pseudo Wire +-------------+ 176 |Demultiplexor|<==============================>|Demultiplexor| 177 +-------------+ +-------------+ 178 | PSN | PSN Tunnel | PSN | 179 | MPLS |<==============================>| MPLS | 180 +-------------+ +-------------+ 181 | Physical | | Physical | 182 +-----+-------+ +-----+-------+ 183 Figure 2: Ethernet PWE3 Protocol Stack Reference Model 185 For the purpose of this document, PE1 will be defined as the ingress 186 router, and PE2 as the egress router. A layer 2 PDU will be received 187 at PE1, encapsulated at PE1, transported, decapsulated at PE2, and 188 transmitted out of PE2. 190 3. The Pseudowire Label 192 Suppose it is desired to transport layer 2 PDUs from ingress LSR PE1 193 to egress LSR PE2, across an intervening PSN. We assume that there is 194 a PSN tunnel from PE1 to PE2. That is, we assume that PE1 can cause a 195 packet to be delivered to PE2 by encapsulating the packet in a "PSN 196 tunnel header" and sending the result to one of its adjacencies. If 197 the PSN tunnel is an MPLS Label Switched Path (LSP), then putting on 198 a PSN tunnel encapsulation is a matter of pushing on an additional 199 MPLS label; if the PSN tunnel is, e.g., a GRE tunnel, then putting on 200 the tunnel encapsulation requires prepending an IP header and a GRE 201 header. 203 We presuppose that an arbitrary number of pseudowires can be carried 204 through a single PSN tunnel. Thus it is never necessary to maintain 205 state in the network core for individual pseudowires. We do not 206 presuppose that the PSN tunnels are point-to-point; although the 207 pseudowires are point-to-point, the PSN tunnels may be multipoint- 208 to-point. We do not presuppose that PE 2 will even be able to 209 determine the PSN tunnel through which a received packet was 210 transmitted. (E.g., if the PSN tunnel is an LSP, and penultimate hop 211 popping is used, when the packet arrives at PE2 it will contain no 212 information identifying the tunnel.) 214 When PE2 receives a packet over a pseudowire, it must be able to 215 determine that the packet was in fact received over a pseudowire, and 216 it must be able to associate that packet with a particular 217 pseudowire. PE2 is able to do this by examining the MPLS label which 218 serves as the pseudowire demultiplexor field. Call this label the 219 "PW label". 221 So when PE1 sends a layer 2 PDU to PE2, it first pushes a PW label on 222 its label stack, thereby creating an MPLS packet. It then (if PE1 is 223 not adjacent to PE2) encapsulates that MPLS packet in a PSN tunnel 224 header. (If the PSN tunnel is an LSP, this is just a matter of 225 pushing on a second label.) The PW label is not visible again until 226 the MPLS packet reaches PE2. PE2's disposition of the packet is based 227 on the PW label. 229 Note that the PW label must always be at the bottom of the packet's 230 label stack. 232 This document specifies a protocol for assigning and distributing the 233 PW label. This protocol is LDP, extended as specified in the 234 remainder of this document. An LDP session must be set up between 235 the pseudowire endpoints. LDP MUST be used in its "downstream 236 unsolicited" mode. LDP's "liberal label retention" mode SHOULD be 237 used. 239 In addition to the protocol specified herein, static assignment of PW 240 labels MAY be used, and implementations of this protocol SHOULD 241 provide support for static assignment. 243 This document specifies all the procedures necessary to set up and 244 maintain the pseudowires needed to support "unswitched" point-to- 245 point services, where each endpoint of the pseudowire is provisioned 246 with the identify of the other endpoint. There are also protocol 247 mechanisms specified herein which can be used to support switched 248 services, and which can be used to support other provisioning models. 249 However, the use of the protocol mechanisms to support those other 250 models and services is not described in this document. 252 4. Details Specific to Particular Emulated Services 254 4.1. Frame Relay 256 When emulating a frame relay service, the Frame Relay PDUs are 257 encapsulated according to the procedures defined in [7]. The PE MUST 258 provide Frame Relay PVC status signaling to the Frame Relay network. 259 If the PE detects a service affecting condition for a particular 260 DLCI, as defined in [2] Q.933 Annex A.5 sited in IA FRF1.1, PE MUST 261 withdraw the PW label that corresponds to the frame relay DLCI. The 262 Egress PE SHOULD generate the corresponding errors and alarms as 263 defined in [2] on the egress Frame relay VC. 265 4.2. ATM 267 4.2.1. ATM AAL5 SDU VCC Transport 269 ATM AAL5 CSPS-SDUs are encapsulated according to [10] ATM AAL5 CPCS- 270 SDU mode. This mode allows the transport of ATM AAL5 CSPS-SDUs 271 traveling on a particular ATM PVC across the network to another ATM 272 PVC. 274 4.2.2. ATM Transparent Cell Transport 276 This mode is similar to the Ethernet port mode. Every cell that is 277 received at the ingress ATM port on the ingress PE, PE1, is 278 encapsulated according to [10], ATM cell mode n-to-one, and sent 279 across the PW to the egress PE, PE2. This mode allows an ATM port to 280 be connected to only one other ATM port. [10] ATM cell n-to-one mode 281 allows for grouping of multiple cells into a single MPLS frame. 282 Grouping of ATM cells is OPTIONAL for transmission at the ingress PE, 283 PE1. If the Egress PE PE2 supports cell concatenation the ingress PE, 284 PE1, should only concatenate cells up to the "Maximum Number of 285 concatenated ATM cells" parameter received as part of the FEC 286 element. 288 4.2.3. ATM n-to-one VCC and VPC Cell Transport 290 This mode is similar to the ATM AAL5 VCC transport except that cells 291 are transported. Every cell that is received on a pre-defined ATM 292 PVC, or ATM PVP, at the ingress ATM port on the ingress PE, PE1, is 293 encapsulated according to [10], ATM cell mode, and sent across the 294 LSP to the egress PE PE2. Grouping of ATM cells is OPTIONAL for 295 transmission at the ingress PE, PE1. If the Egress PE PE2 supports 296 cell concatenation the ingress PE, PE1, MUST only concatenate cells 297 up to the "Maximum Number of concatenated ATM cells in a frame" 298 parameter received as part of the FEC element. 300 4.2.4. OAM Cell Support 302 OAM cells MAY be transported on the VC LSP. When the PE is operating 303 in AAL5 CPCS-SDU transport mode if it does not support transport of 304 ATM cells, the PE MUST discard incoming MPLS frames on an ATM VC LSP 305 that contain a VC label with the T bit set [10]. When operating in 306 AAL5 SDU transport mode an PE that supports transport of OAM cells 307 using the T bit defined in [7], or an PE operating in any of the 308 three cell transport modes MUST follow the procedures outlined in [9] 309 section 8 for mode 0 only, in addition to the applicable procedures 310 specified in [6]. 312 4.2.4.1. OAM Cell Emulation Mode 314 AN PE that does not support transport of OAM cells across an LSP MAY 315 provide OAM support on ATM PVCs using the following procedures: 317 A pair of PEs MAY emulate a bi-directional ATM VC by two uni- 318 directional LSPs. If an F5 end-to-end OAM cell is received from a 319 ATM VC, by either PE that is transporting this ATM VC, with a 320 loopback indication value of 1, and the PE has a label mapping for 321 the ATM VC, then the PE MUST decrement the loopback indication value 322 and loop back the cell on the ATM VC. Otherwise the loopback cell 323 MUST be discarded by the PE. 325 The ingress PE, PE1, may also optionally be configured to 326 periodically generate F5 end-to-end loopback OAM cells on a VC. If 327 the PE fails to receive a response to an F5 end-to-end loopback OAM 328 cell for a pre-defined period of time it MUST withdraw the label 329 mapping for the VC. 331 If an ingress PE, PE1, receives an AIS F5 OAM cell, fails to receive 332 a pre-defined number of the End-to-End loop OAM cells, or a physical 333 interface goes down, it MUST withdraw the label mappings for all VCs 334 associated with the failure. When a PW label mapping is withdrawn, 335 the egress PE, PE2, MUST generate AIS F5 OAM cells on the VC 336 associated with the withdrawn label mapping. In this mode it is very 337 useful to apply a unique group ID to each interface. In the case 338 where a physical interface goes down, a wild card label withdraw can 339 be sent to all LDP neighbors, greatly reducing the signaling response 340 time. 342 4.2.5. ILMI Support 344 An MPLS edge PE MAY provide an ATM ILMI to the ATM edge switch. If an 345 ingress PE receives an ILMI message indicating that the ATM edge 346 switch has deleted a VC, or if the physical interface goes down, it 347 MUST withdraw the label mappings for all VCs associated with the 348 failure. When a PW label mapping is withdrawn, the egress PE SHOULD 349 notify its client of this failure by deleting the VC using ILMI. 351 4.2.6. IP Layer2 Transport 353 This mode switches IP packets into a Peudo-Wire. the encapsulation 354 used is according to [3]. IP interworking is implementation specific, 355 part of the NSP function [13], and is outside the scope of this 356 document. 358 4.2.7. ATM AAL5 PDU VCC Transport 360 ATM AAL5 CSPS-PDUs are encapsulated according to [10] ATM AAL5 CPCS- 361 PDU mode. This mode allows the transport of ATM AAL5 CSPS-PDUs 362 traveling on a particular ATM PVC across the network to another ATM 363 PVC. This mode supports fragmentation of the ATM AAL5 CPCS-PDU in 364 order to maintain the position of the OAM cells with respect to the 365 user cells. Fragmentation may also be performed to maintain the size 366 of the packet carrying the AAL5 PDU within the MTU of the link. 368 4.2.8. ATM one-to-one VCC and VPC Cell Transport 370 This mode is similar to the ATM AAL5 n-to-one cell transport except 371 an encapsulation method that maps one ATM VCC or one ATM VPC to one 372 Pseudo-Wire is used. Every cell that is received on a pre-defined ATM 373 PVC, or ATM PVP, at the ingress ATM port on the ingress PE, PE1, is 374 encapsulated according to [10], ATM one-to-one cell mode, and sent 375 across the LSP to the egress PE PE2. Grouping of ATM cells is 376 OPTIONAL for transmission at the ingress PE, PE1. If the Egress PE 377 PE2 supports cell concatenation the ingress PE, PE1, MUST only 378 concatenate cells up to the "Maximum Number of concatenated ATM cells 379 in a frame" parameter received as part of the FEC element. 381 4.3. Ethernet VLAN 383 The Ethernet frame will be encapsulated according to the procedures 384 in [12] tagged mode. It should be noted that if the VLAN identifier 385 is modified by the egress PE, according to the procedures outlined 386 above, the Ethernet spanning tree protocol might fail to work 387 properly. If the PE detects a failure on the Ethernet physical port, 388 or the port is administratively disabled, it MUST withdraw the label 389 mappings for all PWs associated with the port. 391 4.4. Ethernet 393 The Ethernet frame will be encapsulated according to the procedures 394 in [12]. If the PE detects a failure on the Ethernet physical port, 395 or the port is administratively disabled, the corresponding PW label 396 mapping MUST be withdrawn. 398 4.5. HDLC and PPP 400 HDLC and PPP frames are encapsulated according to the procedures in 401 [11]. If the MPLS edge PE detects that the physical link has failed, 402 or the port is administratively disabled, it MUST withdraw the label 403 mapping that corresponds to the HDLC or PPP link. 405 5. LDP 407 The PW label bindings are distributed using the LDP downstream 408 unsolicited mode described in [1]. The PEs will establish an LDP 409 session using the Extended Discovery mechanism described in [1, 410 section 2.4.2 and 2.5]. 412 An LDP Label Mapping message contains a FEC TLV, a Label TLV, and 413 zero or more optional parameter TLVs. 415 The FEC TLV is used to indicate the meaning of the label. In the 416 current context, the FEC TLV would be used to identify the particular 417 pseudowire that a particular label is bound to. In this 418 specification, we define two new FEC TLVs to be used for identifying 419 pseudowires. When setting up a particular pseudowire, only one of 420 these FEC TLVs is used. The one to be used will depend on the 421 particular service being emulated and on the particular provisioning 422 model being supported. 424 LDP allows each FEC TLV to consist of a set of FEC elements. For 425 setting up and maintaining pseudowires, however, each FEC TLV MUST 426 contain exactly one FEC element. 428 LDP has several kinds of label TLVs. For setting up and maintaining 429 pseudowires, the Generic Label TLV MUST be used. 431 5.1. The PWid FEC Element 433 The PWid FEC element may be used whenever both pseudowire endpoints 434 have been provisioned with the same 32-bit identifier for the 435 pseudowire. 437 For this purpose a new type of FEC element is defined. The FEC 438 element type is 128 [note1], and is defined as follows: 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | VC tlv |C| PW type |VC info Length | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Group ID | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | PW ID | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Interface parameters | 450 | " | 451 | " | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 - PW type 456 A 15 bit quantity containing a value which represents the type of 457 PW. Assigned Values are specified in "IANA Allocations for pseudo 458 Wire Edge to Edge Emulation (PWE3)" [14]. 460 - Control word bit (C) 462 The highest order bit (C) of the PW type is used to flag the 463 presence of a control word ( defined in [7] ) as follows: 465 bit 15 = 1 control word present on this VC. 466 bit 15 = 0 no control word present on this VC. 468 Please see the section "C-Bit Handling Procedures" for further 469 explanation. 471 - VC information length 473 Length of the PW ID field and the interface parameters field in 474 octets. If this value is 0, then it references all PWs using the 475 specified group ID and there is no PW ID present, nor any 476 interface parameters. 478 - Group ID 480 An arbitrary 32 bit value which represents a group of PWs that is 481 used to create groups in the VC space. The group ID is intended 482 to be used as a port index, or a virtual tunnel index. To 483 simplify configuration a particular PW ID at ingress could be 484 part of the virtual tunnel for transport to the egress router. 485 The Group ID is very useful to send wild card label withdrawals 486 to remote PEs upon physical port failure. 488 - PW ID 490 A non-zero 32-bit connection ID that together with the PW type, 491 identifies a particular PW. Note that the PW ID and the PW type 492 must be the same at both endpoints. 494 - Interface parameters 496 This variable length field is used to provide interface specific 497 parameters, such as interface MTU. 499 Note that as the "interface parameters" are part of the FEC, the 500 rules of LDP make it impossible to change the interface 501 parameters once the pseudowire has been set up. Thus the 502 interface parameters field must not be used to pass information, 503 such as status information, which may change during the life of 504 the pseudowire. Optional parameter TLVs should be used for that 505 purpose. 507 Using the PWid FEC, each of the two pseudowire endpoints 508 independently initiates the set up of a unidirectional LSP. An 509 outgoing LSP and an incoming LSP are bound together into a single 510 pseudowire if they have the same PW ID and PW type. 512 5.2. The Generalized ID FEC Element 514 There are cases where the PWid FEC element cannot be used, because 515 both endpoints have not been provisioned with a common 32-bit PWid. 516 In such cases, the "Generalized ID FEC Element" is used instead. 517 This is FEC type 129 (provisionally, subject to assignment by IANA). 518 It differs from the PWid FEC element in that the PWid and the group 519 id are eliminated, and their place is taken by a generalized 520 identifier field as described below. The Generalized ID FEC element 521 includes a PW type field, a C bit, and an interface parameters field; 522 these three fields are identical to those in the PWid FEC, and are 523 used as discussed in the previous section. 525 5.2.1. Attachment Identifiers 527 As discussed in [13], a pseudowire can be thought of as connecting 528 two "forwarders". The protocol used to setup a pseudowire must allow 529 the forwarder at one end of a pseudowire to identify the forwarder at 530 the other end. We use the term "attachment identifier", or "AI", to 531 refer to the field which the protocol uses to identify the 532 forwarders. In the PWid FEC, the PWid field serves as the AI. In 533 this section we specify a more general form of AI which is structured 534 and of variable length. 536 Every Forwarder in a PE must be associated with an Attachment 537 Identifier (AI), either through configuration or through some 538 algorithm. The Attachment Identifier must be unique in the context 539 of the PE router in which the Forwarder resides. The combination must be globally unique. 542 It is frequently convenient to a set of Forwarders as being members 543 of a particular "group", where PWs may only be set up among members 544 of a group. In such cases, it is convenient to identify the 545 Forwarders relative to the group, so that an Attachment Identifier 546 would consist of an Attachment Group Identifier (AGI) plus an 547 Attachment Individual Identifier (AII). 549 An Attachment Group Identifier may be thought of as a VPN-id, or 550 a VLAN identifier, some attribute which is shared by all the 551 Attachment VCs (or pools thereof) which are allowed to be connected. 553 The details of how to construct the AGI and AII fields identifying 554 the pseudowire endpoints are outside the scope of this specification. 555 Different pseudowire application, and different provisioning models, 556 will require different sorts of AGI and AII fields. The 557 specification of each such application and/or model must include the 558 rules for constructing the AGI and AII fields. 560 As previously discussed, a (bidirectional) pseudowire consists of a 561 pair of unidirectional LSPs, one in each direction. If a particular 562 pseudowire connects PE1 with PE2, the LSP in the PE1-->PE2 direction 563 can be identified as: 565 , PE2, >, 567 and the LSP in the PE2--PE1 direction can be identified by: 569 , PE1, >. 571 Note that the AGI must be the same at both endpoints, but the AII 572 will in general be different at each endpoint. Thus from the 573 perspective of a particular PE, each pseudowire has a local or 574 "Source AII", and a remote or "Target AII". The pseudowire setup 575 protocol can carry all three of these quantities: 577 - Attachment Group Identifier (AGI). 579 - Source Attachment Individual Identifier (SAII) 581 - Target Attachment Individual Identifier (TAII) 583 If the AGI is non-null, then the Source AI (SAI) consists of the AGI 584 together with the SAII, and the Target AI (TAI) consists of the TAII 585 together with the AGI. If the AGI is null, then the SAII and TAII 586 are the SAI and TAI respectively. 588 The interpretation of the SAI and TAI is a local matter at the 589 respective endpoint. 591 The association of two unidirectional LSPs into a single 592 bidirectional pseudowire depends on the SAI and the TAI. Each 593 application and/or provisioning model which uses the Generalized ID 594 FEC element must specify the rules for performing this association. 596 5.2.2. Encoding the Generalized ID FEC Element 598 FEC element type 129 is used. The FEC element is encoded as 599 follows: 601 0 1 2 3 602 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 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | 129 |C| VC Type |VC info Length | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Parameters | 607 | " | 608 | " | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 additional Parameters are: 613 - SAII, encoded as a one byte length field followed by the SAI. 615 - TAII, encoded as a one byte length field followed by the TAI. 617 - AGI, encoded as a one byte length field followed by the AGI. 619 The SAII, TAII, and AGI are simply carried as octet strings. The 620 length byte specifies the size of the field, excluding the length 621 byte itself. The null string can be sent by setting the length 622 byte to 0. 624 5.2.3. Procedures 626 In order for PE1 to begin signaling PE2, PE1 must know the address of 627 the remote PE2, and a TAI. This information may have been configured 628 at PE1, or it may have been learned dynamically via some 629 autodiscovery procedure. 631 To begin the signaling procedure, a PE (PE1) that has knowledge of 632 the other endpoint (PE2) initiates the setup of the LSP in the 633 incoming (PE2-->PE1) direction by sending a Label Mapping message 634 containing the FEC type 129. The FEC element includes the SAII, AGI, 635 and TAII. 637 What happens when PE2 receives such a Label Mapping message? 639 PE2 interprets the message as a request to set up a PW whose endpoint 640 (at PE2) is the Forwarder identified by the TAI. From the 641 perspective of the signaling protocol, exactly how PE2 maps AIs to 642 Forwarders is a local matter. In some VPWS provisioning models, the 643 TAI might, e.g., be a string which identifies a particular Attachment 644 Circuit, such as "ATM3VPI4VCI5", or it might, e.g., be a string such 645 as "Fred" which is associated by configuration with a particular 646 Attachment Circuit. In VPLS, the TAI would be a VPN-id, identifying 647 a particular VPLS instance. 649 If PE2 cannot map the TAI to one of its Forwarders, then PE2 sends a 650 Label Release message to PE1, with a Status Code meaning "invalid 651 TAI", and the processing of the Mapping message is complete. 653 If the Label Mapping Message has a valid TAI, PE2 must decide whether 654 to accept it or not. The procedures for so deciding will depend on 655 the particular type of Forwarder identified by the TAI. Of course, 656 the Label Mapping message may be rejected due to standard LDP error 657 conditions as detailed in [LDP]. 659 If PE2 decides to accept the Label Mapping message, then it has to 660 make sure that an LSP is set up in the opposite (PE1-->PE2) 661 direction. If it has already signaled for the corresponding LSP in 662 that direction, nothing more need be done. Otherwise, it must 663 initiate such signaling by sending a Label Mapping message to PE1. 664 This is very similar to the Label Mapping message PE2 received, but 665 with the SAI and TAI reversed. 667 5.3. Interface Parameters Field 669 This field specifies interface specific parameters. When applicable, 670 it MUST be used to validate that the PEs, and the ingress and egress 671 ports at the edges of the circuit, have the necessary capabilities to 672 interoperate with each other. The field structure is defined as 673 follows: 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Parameter ID | Length | Variable Length Value | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Variable Length Value | 681 | " | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 The parameter ID Values are specified in "IANA Allocations for pseudo 685 Wire Edge to Edge Emulation (PWE3)" [14]. 687 The Length field is defined as the length of the interface parameter 688 including the parameter id and length field itself. Processing of the 689 interface parameters should continue when encountering unknown 690 interface parameters and they MUST be silently ignored. 692 - Interface MTU 694 A 2 octet value indicating the MTU in octets. This is the Maximum 695 Transmission Unit, excluding encapsulation overhead, of the 696 egress packet interface that will be transmitting the 697 decapsulated PDU that is received from the MPLS network. This 698 parameter is applicable only to PW types 1, 2, 4, 5, 6, and 7, 699 and is REQUIRED for these PW types. If this parameter does not 700 match in both directions of a specific PW, that PW MUST NOT be 701 enabled. 703 - Maximum Number of concatenated ATM cells 705 A 2 octet value specifying the maximum number of concatenated ATM 706 cells that can be processed as a single PDU by the egress PE. An 707 ingress PE transmitting concatenated cells on this PW can 708 concatenate a number of cells up to the value of this parameter, 709 but MUST NOT exceed it. This parameter is applicable only to PW 710 types 3, 9, and 0x0a, and is REQUIRED for these PWC types. This 711 parameter does not need to match in both directions of a specific 712 PW. 714 - Optional Interface Description string 716 This arbitrary, OPTIONAL, interface description string is used to 717 send a human-readable administrative string describing the 718 interface to the remote. This parameter is OPTIONAL, and is 719 applicable to all PW types. The interface description parameter 720 string length is variable, and can be from 0 to 80 octets. 721 Human-readable text MUST be provided in the UTF-8 charset using 722 the Default Language [RFC2277]. 724 - Payload Bytes 726 A 2 octet value indicating the number of TDM payload octets 727 contained in all packets on the CEM stream, from 48 to 1,023 728 octets. All of the packets in a given CEM stream have the same 729 number of payload bytes. Note that there is a possibility that 730 the packet size may exceed the SPE size in the case of an STS-1 731 SPE, which could cause two pointers to be needed in the CEM 732 header, since the payload may contain two J1 bytes for 733 consecutive SPEs. For this reason, the number of payload bytes 734 must be less than or equal to 783 for STS-1 SPEs. 736 - CEP Options. An optional 16 Bit value of CEM Flags. See [8] for 737 the definition of the bit values. 739 - Requested VLAN ID. An Optional 16 bit value indicating the 740 requested VLAN ID. This parameter MAY be used by an PE that is 741 incapable of rewriting the 802.1Q ethernet VLAN tag on output. If 742 the ingress PE receives this request it MAY rewrite the VLAN ID 743 tag in input to match the requested VLAN ID. If this is not 744 possible, and the VLAN ID does not already match configured 745 ingress VLAN ID the PW should not be enabled.This parameter is 746 applicable only to PW type 4. 748 - CEP/TDM bit rate. This 32-bit integer is mandatory for CEP. For 749 other PWs carrying TDM traffic it is mandatory if the bit-rate 750 cannot be directly inferred from the service type. If present, it 751 expresses the bit rate of the attachment circuit as known to the 752 advertizing PE in "units" of 64 kbit/s. I.e., the value 26 must 753 be used for CEP carrying VT1.5 SPE, 35 - for CEP carrying a VT2 754 SPE, 99 - for VT6 SPE, 783 - for STS-1 SPE and n*783 - for STS- 755 nc, n = 3, 12, 48, 192. Attempts to establish a PWC between a 756 pair of TDM ports with different bit-rates MUST be rejected with 757 the appropriate status code (see section "Status codes" below). 759 5.3.1. PW types for which the control word is REQUIRED 761 The Label Mapping messages which are sent in order to set up these 762 PWs MUST have c=1. When a Label Mapping message for a PW of one of 763 these types is received, and c=0, a Label Release MUST be sent, with 764 an "Illegal C-bit" status code. In this case, the PW will not be 765 enabled. 767 5.3.2. PW types for which the control word is NOT mandatory 769 If a system is capable of sending and receiving the control word on 770 PW types for which the control word is not mandatory, then each such 771 PW endpoint MUST be configurable with a parameter that specifies 772 whether the use of the control word is PREFERRED or NOT PREFERRED. 773 For each PW, there MUST be a default value of this parameter. This 774 specification does NOT state what the default value should be. 776 If a system is NOT capable of sending and receiving the control word 777 on PWC types for which the control word is not mandatory, then it 778 behaves as exactly as if it were configured for the use of the 779 control word to be NOT PREFERRED. 781 If a Label Mapping message for the PW has already been received, but 782 no Label Mapping message for the PW has yet been sent, then the 783 procedure is the following: 785 -i. If the received Label Mapping message has c=0, send a Label 786 Mapping message with c=0, and the control word is not used. 787 -ii. If the received Label Mapping message has c=1, and the PW is 788 locally configured such that the use of the control word is 789 preferred, then send a Label Mapping message with c=1, and 790 the control word is used. 791 -iii. If the received Label Mapping message has c=1, and the PW is 792 locally configured such that the use of the control word is 793 not preferred or the control word is not supported, then act 794 as if no Label Mapping message for the PW had been received 795 (i.e., proceed to the next paragraph). 797 If a Label Mapping message for the PW has not already been received 798 (or if the received Label Mapping message had c=1 and either local 799 configuration says that the use of the control word is not preferred 800 or the control word is not supported), then send a Label Mapping 801 message in which the c bit is set to correspond to the locally 802 configured preference for use of the control word. (I.e., set c=1 if 803 locally configured to prefer the control word, set c=0 if locally 804 configured to prefer not to use the control word or if the control 805 word is not supported). 807 The next action depends on what control message is next received for 808 that PW. The possibilities are: 810 -i. A Label Mapping message with the same c bit value as 811 specified in the Label Mapping message that was sent. PW 812 setup is now complete, and the control word is used if c=1 813 but not used if c=0. 814 -ii. A Label Mapping message with c=1, but the Label Mapping 815 message that was sent has c=0. In this case, ignore the 816 received Label Mapping message, and continue to wait for the 817 next control message for the PW. 818 -iii. A Label Mapping message with c=0, but the Label Mapping 819 message that was sent has c=1. In this case, send a Label 820 Withdraw message with a "Wrong c-bit" status code, followed 821 by a Label Mapping message that has c=0. PW setup is now 822 complete, and the control word is not used. 823 -iv. A Label Withdraw message with the "Wrong c-bit" status code. 824 Treat as a normal Label Withdraw, but do not respond. 825 Continue to wait for the next control message for the PW. 827 If at any time after a Label Mapping message has been received, a 828 corresponding Label Withdraw or Release is received, the action taken 829 is the same as for any Label Withdraw or Release that might be 830 received at any time. Note that receiving a Label Withdraw should not 831 cause a corresponding Label Release to be sent. 833 If both endpoints prefer the use of the control word, this procedure 834 will cause it to be used. If either endpoint prefers not to use the 835 control word, or does not support the control word, this procedure 836 will cause it not to be used. If one endpoint prefers to use the 837 control word but the other does not, the one that prefers not to use 838 it is has no extra protocol to execute, it just waits for a Label 839 Mapping message that has c=0. 841 The diagram in Appendix A illustrates the above procedure. 843 5.3.3. Status codes 845 RFC 3036 has a range of Status Code values which are assigned by IANA 846 on a First Come, First Served basis. These additional status codes, 847 and assigned Values are specified in "IANA Allocations for pseudo 848 Wire Edge to Edge Emulation (PWE3)" [14]. 850 5.4. LDP label Withdrawal procedures 852 As mentioned above the Group ID field can be used to withdraw all PW 853 labels associated with a particular group ID. This procedure is 854 OPTIONAL, and if it is implemented the LDP label withdraw message 855 should be as follows: the PW information length field is set to 0, 856 the PW ID field is not present, and the interface parameters field is 857 not present. For the purpose of this document this is called the 858 "wild card withdraw procedure", and all PEs implementing this design 859 are REQUIRED to accept such a withdraw message, but are not required 860 to send it. 862 The interface parameters field MUST NOT be present in any LDP PW 863 label withdrawal message or release message. A wildcard release 864 message MUST include only the group ID. A Label Release message 865 initiated from the imposition router must always include the PW ID. 867 5.5. Sequencing Considerations 869 In the case where the router considers the sequence number field in 870 the control word, it is important to note the following when 871 advertising labels 873 5.5.1. Label Mapping Advertisements 875 After a label has been withdrawn by the disposition router and/or 876 released by the imposition router, care must be taken to not re- 877 advertise (re-use) the released label until the disposition router 878 can be reasonably certain that old packets containing the released 879 label no longer persist in the MPLS network. 881 This precaution is required to prevent the imposition router from 882 restarting packet forwarding with sequence number of 1 when it 883 receives the same label mapping if there are still older packets 884 persisting in the network with sequence number between 1 and 32768. 885 For example, if there is a packet with sequence number=n where n is 886 in the interval[1,32768] traveling through the network, it would be 887 possible for the disposition router to receive that packet after it 888 re-advertises the label. Since the label has been released by the 889 imposition router, the disposition router SHOULD be expecting the 890 next packet to arrive with sequence number to be 1. Receipt of a 891 packet with sequence number equal to n will result in n packets 892 potentially being rejected by the disposition router until the 893 imposition router imposes a sequence number of n+1 into a packet. 894 Possible methods to avoid this is for the disposition router to 895 always advertise a different PW label, or for the disposition router 896 to wait for a sufficient time before attempting to re-advertised a 897 recently released label. This is only an issue when sequence number 898 processing at the disposition router is enabled. 900 5.5.2. Label Mapping Release 902 In situations where the imposition router wants to restart forwarding 903 of packets with sequence number 1, the router shall 1) Send to 904 disposition router a label mapping release, and 2) Send to 905 disposition router a label mapping request. When sequencing is 906 supported, advertisement of a PW label in response to a label mapping 907 request MUST also consider the issues discussed in the section on 908 Label Mapping Advertisements. 910 6. IANA Considerations 912 As specified in this document, a Virtual Circuit FEC element contains 913 the PW Type field. PW type value 0 is reserved. PW type values 1 914 through 10 are defined in this document. PW type values 11 through 63 915 are to be assigned by IANA using the "IETF Consensus" policy defined 916 in [RFC2434]. PW type values 64 through 127 are to be assigned by 917 IANA, using the "First Come First Served" policy defined in [RFC 918 2434]. PW type values 128 through 32767 are vendor-specific, and 919 values in this range are not to be assigned by IANA. 921 As specified in this document, a Pseudo Wire FEC element contains the 922 Interface Parameters field, which is a list of one or more 923 parameters, and each parameter is identified by the Parameter ID 924 field. Parameter ID value 0 is reserved. Parameter ID values 1 925 through 6 are defined in this document. Parameter ID values 7 926 through 63 are to be assigned by IANA using the "IETF Consensus" 927 policy defined in RFC2434. Parameter ID values 64 through 127 are to 928 be assigned by IANA, using the "First Come First Served" policy 929 defined in RFC2434. Parameter ID values 128 through 255 are vendor- 930 specific, and values in this range are not to be assigned by IANA. 932 7. Security Considerations 934 This document does not affect the underlying security issues of MPLS. 936 8. References 938 [1] "LDP Specification." L. Andersson, P. Doolan, N. Feldman, A. 939 Fredette, B. Thomas. January 2001. RFC3036 941 [2] ITU-T Recommendation Q.933, and Q.922 Specification for Frame 942 Mode Basic call control, ITU Geneva 1995 944 [3] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter, D. Tappan, G. 945 Fedorkow, D. Farinacci, T. Li, A. Conta. RFC3032 947 [4] "IEEE 802.3ac-1998" IEEE standard specification. 949 [5] American National Standards Institute, "Synchronous Optical 950 Network Formats," ANSI T1.105-1995. 952 [6] ITU Recommendation G.707, "Network Node Interface For The 953 Synchronous Digital Hierarchy", 1996. 955 [7] "Encapsulation Methods for Transport of Frame-Relay Over IP and 956 MPLS Networks", draft-ietf-pwe3-frame-encap-01.txt. ( work in 957 progress ) 959 [8] "SONET/SDH Circuit Emulation Service Over Packet (CEP)", 960 draft-ietf-pwe3-sonet-01.txt ( Work in progress ) 962 [9] ATM Forum Specification fb-fbatm-0151.000 (2000) ,Frame Based ATM 963 over SONET/SDH Transport (FAST) 965 [10] "Encapsulation Methods for Transport of ATM Cells/Frame Over IP 966 and MPLS Networks", draft-ietf-pwe3-atm-encap-00.txt ( work in 967 progress ) 969 [11] "Encapsulation Methods for Transport of PPP/HDLC Frames Over IP 970 and MPLS Networks", draft-martini-ppp-hdlc-encap-mpls-00.txt. ( work 971 in progress ) 973 [12] "Encapsulation Methods for Transport of Ethernet Frames Over 974 IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap-01.txt. ( work in 975 progress ) 977 [13] "Protocol Layering in PWE3" Bryant, et al., draft-ietf-pwe3- 978 protocol-layer-00.txt ( work in progress ), November 2002. 980 [14] "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)" 981 Martini, Townsley, draft-ietf-pwe3-iana-allocation-00.txt ( work in 982 progress ), February 2003 984 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 985 IANA Considerations section in RFCs", BCP 26, RFC 2434, October 1998. 987 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 988 Languages", BCP 18, RFC 2277, January 1998. 990 [note1] FEC element type 128 is pending IANA approval. 992 [note2] Status codes assigment is pending IANA approval. 994 9. Author Information 996 Luca Martini 997 Level 3 Communications, LLC. 998 1025 Eldorado Blvd. 999 Broomfield, CO, 80021 1000 e-mail: luca@level3.net 1002 Nasser El-Aawar 1003 Level 3 Communications, LLC. 1004 1025 Eldorado Blvd. 1005 Broomfield, CO, 80021 1006 e-mail: nna@level3.net 1008 Giles Heron 1009 PacketExchange Ltd. 1010 The Truman Brewery 1011 91 Brick Lane 1012 LONDON E1 6QL 1013 United Kingdom 1014 e-mail: giles@packetexchange.net 1016 Eric Rosen 1017 Cisco Systems, Inc. 1018 250 Apollo Drive 1019 Chelmsford, MA, 01824 1020 e-mail: erosen@cisco.com 1021 Dan Tappan 1022 Cisco Systems, Inc. 1023 250 Apollo Drive 1024 Chelmsford, MA, 01824 1025 e-mail: tappan@cisco.com 1027 10. Additional Contributing Authors 1029 Dimitri Stratton Vlachos 1030 Mazu Networks, Inc. 1031 125 Cambridgepark Drive 1032 Cambridge, MA 02140 1033 e-mail: d@mazunetworks.com 1035 Jayakumar Jayakumar, 1036 Cisco Systems Inc. 1037 225, E.Tasman, MS-SJ3/3, 1038 San Jose, CA, 95134 1039 e-mail: jjayakum@cisco.com 1041 Alex Hamilton, 1042 Cisco Systems Inc. 1043 285 W. Tasman, MS-SJCI/3/4, 1044 San Jose, CA, 95134 1045 e-mail: tahamilt@cisco.com 1047 Steve Vogelsang 1048 Laurel Networks, Inc. 1049 Omega Corporate Center 1050 1300 Omega Drive 1051 Pittsburgh, PA 15205 1052 e-mail: sjv@laurelnetworks.com 1054 John Shirron 1055 Omega Corporate Center 1056 1300 Omega Drive 1057 Pittsburgh, PA 15205 1058 Laurel Networks, Inc. 1059 e-mail: jshirron@laurelnetworks.com 1060 Toby Smith 1061 Omega Corporate Center 1062 1300 Omega Drive 1063 Pittsburgh, PA 15205 1064 Laurel Networks, Inc. 1065 e-mail: tob@laurelnetworks.com 1067 Andrew G. Malis 1068 Vivace Networks, Inc. 1069 2730 Orchard Parkway 1070 San Jose, CA 95134 1071 Phone: +1 408 383 7223 1072 Email: Andy.Malis@vivacenetworks.com 1074 Vinai Sirkay 1075 Vivace Networks, Inc. 1076 2730 Orchard Parkway 1077 San Jose, CA 95134 1078 e-mail: sirkay@technologist.com 1080 Vasile Radoaca 1081 Nortel Networks 1082 600 Technology Park 1083 Billerica MA 01821 1084 e-mail: vasile@nortelnetworks.com 1086 Chris Liljenstolpe 1087 Cable & Wireless 1088 11700 Plaza America Drive 1089 Reston, VA 20190 1090 e-mail: chris@cw.net 1092 Dave Cooper 1093 Global Crossing 1094 960 Hamlin Court 1095 Sunnyvale, CA 94089 1096 e-mail: dcooper@gblx.net 1097 Kireeti Kompella 1098 Juniper Networks 1099 1194 N. Mathilda Ave 1100 Sunnyvale, CA 94089 1101 e-mail: kireeti@juniper.net 1103 11. Appendix A - C-bit Handling Procedures Diagram 1105 ------------------ 1106 Y | Received Label | N 1107 -------| Mapping Msg? |-------------- 1108 | ------------------ | 1109 -------------- | 1110 | | | 1111 ------- ------- | 1112 | C=0 | | C=1 | | 1113 ------- ------- | 1114 | | | 1115 | ---------------- | 1116 | | Control Word | N | 1117 | | Capable? |----------- | 1118 | ---------------- | | 1119 | Y | | | 1120 | | | | 1121 | ---------------- | | 1122 | | Control Word | N | | 1123 | | Preferred? |---- | | 1124 | ---------------- | | | 1125 | Y | | | | 1126 | | | | ---------------- 1127 | | | | | Control Word | 1128 | | | | | Preferred? | 1129 | | | | ---------------- 1130 | | | | N | Y | 1131 | | | | | | 1132 Send Send Send Send Send Send 1133 C=0 C=1 C=0 C=0 C=0 C=1 1134 | | | | 1135 ---------------------------------- 1136 | If receive the same as sent, | 1137 | PW setup is complete. If not: | 1138 ---------------------------------- 1139 | | | | 1140 ------------------- ----------- 1141 | Receive | | Receive | 1142 | C=1 | | C=0 | 1143 ------------------- ----------- 1144 | | 1145 Wait for the Send 1146 next message Wrong C-Bit 1147 | 1148 Send Label 1149 Mapping Message