idnits 2.17.1 draft-ietf-pwe3-control-protocol-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1564. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1550. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** There are 13 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 269 has weird spacing: '...re also proto...' == Line 494 has weird spacing: '... The highe...' == Line 495 has weird spacing: '...resence of a...' == Line 590 has weird spacing: '...ntifier may b...' == Line 591 has weird spacing: '...r, some attri...' == (1 more instance...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This mode switches IP packets into a Peudo-Wire. the encapsulation used is according to [3]. IP interworking is implementation specific, part of the NSP function [12], and is outside the scope of this document. The control word MUST not be used. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The PW FEC TLV SHOULD not include the interface parameters as they are ignored in the context of this message. When a PE's CE-facing interface encounters an error, use of the PW status message allows the PE to send a single "wild card" status message, using a PW FEC TLV with only the group ID set, to denote this change in status for all affected PW connections. This status message contains either the PW FEC TLV with only the group ID set, or else it contains the Generalized FEC TLV and the PW Grouping ID TLV. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: When a MPLS PSN is used to provide pseudowire service, there is a perception that security MUST be at least equal to the currently deployed layer2 native protocol networks that the MPLS/PW network combination is emulating. This means that the MPLS network SHOULD be isolated from outside packet insertion in such a way that it SHOULD not be possible to directly insert an MPLS packet into the network. To prevent unwanted packet insertion, it is also important to prevent unauthorized physical access to the PSN as well as unauthorized administrative access to individual network elements. The PSN transporting the PWs is an MPLS backbone, it should not accept MPLS packets from its external interfaces (i.e. interfaces to CE devices or to other providers' networks) unless the top label of the packet was legitimately distributed to the system from which the packet is being received. If the packet's incoming interface leads to a different SP (rather than to a customer), an appropriate trust relationship must also be present, including the trust that the other SP also provides appropriate security measures. -- 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 (July 2004) is 7218 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 143, but not defined ** Obsolete undefined reference: RFC 3036 (Obsoleted by RFC 5036) == Missing Reference: '32768' is mentioned on line 1172, but not defined == Unused Reference: '4' is defined on line 1380, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 1410, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3036 (ref. '1') (Obsoleted by RFC 5036) == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-frame-relay-02 == Outdated reference: A later version (-14) exists of draft-ietf-pwe3-sonet-07 == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-atm-encap-05 -- No information found for draft-ietf-pwe3-hdlc-ppp-encap - is the name correct? == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-ethernet-encap-06 == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-iana-allocation-04 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 10 errors (**), 0 flaws (~~), 20 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini 3 Internet Draft Eric C. Rosen 4 Expiration Date: January 2005 Cisco Systems, Inc. 6 Nasser El-Aawar Toby Smith 7 Level 3 Communications, LLC. Laurel Networks, Inc. 9 Giles Heron 10 Tellabs 11 July 2004 13 Pseudowire Setup and Maintenance using LDP 15 draft-ietf-pwe3-control-protocol-08.txt 17 Status of this Memo 19 By submitting this Internet-Draft, we certify that any applicable 20 patent or other IPR claims of which we are aware have been disclosed, 21 or will be disclosed, and any of which we become aware will be 22 disclosed, in accordance with RFC 3668. 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of RFC2026. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that other 29 groups may also distribute working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Abstract 44 Layer 2 services (such as Frame Relay, ATM, ethernet) can be 45 "emulated" over an IP and/or MPLS backbone by encapsulating the layer 46 2 PDUs and then transmitting them over "pseudowires". It is also 47 possible to use pseudowires to provide SONET circuit emulation over 48 an IP and/or MPLS network. This document specifies a protocol for 49 establishing and maintaining the pseudowires, using extensions to 50 LDP. Procedures for encapsulating layer 2 PDUs are specified in a 51 set of companion documents. 53 Table of Contents 55 1 Specification of Requirements .......................... 4 56 2 Introduction ........................................... 4 57 3 The Pseudowire Label ................................... 6 58 4 Details Specific to Particular Emulated Services ....... 7 59 4.1 Frame Relay ............................................ 8 60 4.2 ATM .................................................... 8 61 4.2.1 ATM AAL5 SDU VCC Transport ............................. 8 62 4.2.2 ATM Transparent Cell Transport ......................... 8 63 4.2.3 ATM n-to-one VCC and VPC Cell Transport ................ 8 64 4.2.4 OAM Cell Support ....................................... 9 65 4.2.5 ILMI Support ........................................... 10 66 4.2.6 ATM AAL5 PDU VCC Transport ............................. 10 67 4.2.7 ATM one-to-one VCC and VPC Cell Transport .............. 10 68 4.3 Ethernet Tagged Mode ................................... 10 69 4.4 Ethernet ............................................... 11 70 4.5 HDLC and PPP ........................................... 11 71 4.6 IP Layer2 Transport .................................... 11 72 5 LDP .................................................... 11 73 5.1 The PWid FEC Element ................................... 12 74 5.2 The Generalized ID FEC Element ......................... 14 75 5.2.1 Attachment Identifiers ................................. 14 76 5.2.2 Encoding the Generalized ID FEC Element ................ 16 77 5.2.3 Signaling Procedures ................................... 18 78 5.3 Signaling of Pseudo Wire Status ........................ 19 79 5.3.1 Use of Label Mappings. ................................. 19 80 5.3.2 Signaling PW status. ................................... 19 81 5.3.3 Pseudowire Status Negotiation Procedures ............... 21 82 5.4 Interface Parameters Field ............................. 23 83 5.4.1 PW types for which the control word is REQUIRED ........ 25 84 5.4.2 PW types for which the control word is NOT mandatory ... 25 85 5.4.3 Status codes ........................................... 27 86 5.5 LDP label Withdrawal procedures ........................ 27 87 5.6 Sequencing Considerations .............................. 27 88 5.6.1 Label Mapping Advertisements ........................... 27 89 5.6.2 Label Mapping Release .................................. 28 90 6 IANA Considerations .................................... 28 91 6.1 FEC Type Name Space .................................... 28 92 6.2 Pseudowire Type ........................................ 28 93 6.3 Interface Parameters ................................... 29 94 6.4 LDP Status Codes ....................................... 29 95 6.5 Pseudowire Status Codes ................................ 29 96 7 Security Considerations ................................ 29 97 7.1 Data-plane Security .................................... 30 98 7.2 Control Protocol Security .............................. 31 99 8 Acknowledgments ........................................ 32 100 9 Normative References ................................... 32 101 10 Informative References ................................. 32 102 11 Author Information ..................................... 33 103 12 Additional Contributing Authors ........................ 34 104 13 Intellectual Property Statement ........................ 37 105 14 Full Copyright Statement ............................... 37 106 15 Appendix A - C-bit Handling Procedures Diagram ......... 38 107 16 Appendix B - Notification Message of PW Status Diagram . 39 109 1. Specification of Requirements 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119. 115 2. Introduction 117 In [7], [9], and [11] it is explained how to encapsulate a layer 2 118 Protocol Data Unit (PDU) for transmission over an IP and/or MPLS 119 network. Those documents specify that a "pseudowire header", 120 consisting of a demultiplexor field, will be prepended to the 121 encapsulated PDU. The pseudowire demultiplexor field is put on before 122 transmitting a packet on a pseudowire. When the packet arrives at 123 the remote endpoint of the pseudowire, the demultiplexor is what 124 enables the receiver to identify the particular pseudowire on which 125 the packet has arrived. To actually transmit the packet from one 126 pseudowire endpoint to another, the packet may need to travel through 127 a "PSN tunnel"; this will require an additional header to be 128 prepended to the packet. 130 An accompanying document [8] also describes a method for transporting 131 time division multiplexed (TDM) digital signals (TDM circuit 132 emulation) over a packet-oriented MPLS network. The transmission 133 system for circuit-oriented TDM signals is the Synchronous Optical 134 Network (SONET)[5]/Synchronous Digital Hierarchy (SDH) [6]. To 135 support TDM traffic, which includes voice, data, and private leased 136 line service, the pseudowires must emulate the circuit 137 characteristics of SONET/SDH payloads. The TDM signals and payloads 138 are encapsulated for transmission over pseudowires. To this 139 encapsulation is prepended a pseudowire demultiplexor and a PSN 140 tunnel header. 142 In this document, we specify the use of the MPLS Label Distribution 143 Protocol, LDP [RFC3036], as a protocol for setting up and maintaining 144 the pseudowires. In particular, we define new TLVs for LDP, which 145 enable LDP to identify pseudowires and to signal attributes of 146 pseudowires. We specify how a pseudowire endpoint uses these TLVs in 147 LDP to bind a demultiplexor field value to a pseudowire, and how it 148 informs the remote endpoint of the binding. We also specify 149 procedures for reporting pseudowire status changes, passing 150 additional information about the pseudowire as needed, and for 151 releasing the bindings. 153 In the protocol specified herein, the pseudowire demultiplexor field 154 is an MPLS label. Thus the packets which are transmitted from one end 155 of the pseudowire to the other are MPLS packets. Unless the 156 pseudowire endpoints are immediately adjacent, these MPLS packets 157 must be transmitted through a PSN tunnel. Any sort of PSN tunnel can 158 be used, as long as it is possible to transmit MPLS packets through 159 it. The PSN tunnel can itself be an LSP, or any other sort of tunnel 160 which can carry MPLS packets. Procedures for setting up and 161 maintaining the PSN tunnels are outside the scope of this document. 163 This document deals only with the setup and maintenance of point-to- 164 point pseudowires. Neither point-to-multipoint nor multipoint-to- 165 point pseudowires are discussed. 167 QoS related issues are not discussed in this document. 169 The following two figures describe the reference models which are 170 derived from [12] to support the Ethernet PW emulated services. 172 |<-------------- Emulated Service ---------------->| 173 | | 174 | |<------- Pseudo Wire ------>| | 175 | | | | 176 | | |<-- PSN Tunnel -->| | | 177 | V V V V | 178 V AC +----+ +----+ AC V 179 +-----+ | | PE1|==================| PE2| | +-----+ 180 | |----------|............PW1.............|----------| | 181 | CE1 | | | | | | | | CE2 | 182 | |----------|............PW2.............|----------| | 183 +-----+ ^ | | |==================| | | ^ +-----+ 184 ^ | +----+ +----+ | | ^ 185 | | Provider Edge 1 Provider Edge 2 | | 186 | | | | 187 Customer | | Customer 188 Edge 1 | | Edge 2 189 | | 190 native service native service 191 Figure 1: PWE3 Reference Model 193 +-------------+ +-------------+ 194 | Layer2 | | Layer2 | 195 | Emulated | | Emulated | 196 | Services | Emulated Service | Services | 197 | |<==============================>| | 198 +-------------+ Pseudo Wire +-------------+ 199 |Demultiplexor|<==============================>|Demultiplexor| 200 +-------------+ +-------------+ 201 | PSN | PSN Tunnel | PSN | 202 | MPLS |<==============================>| MPLS | 203 +-------------+ +-------------+ 204 | Physical | | Physical | 205 +-----+-------+ +-----+-------+ 207 Figure 2: PWE3 Protocol Stack Reference Model 209 For the purpose of this document, PE1 will be defined as the ingress 210 router, and PE2 as the egress router. A layer 2 PDU will be received 211 at PE1, encapsulated at PE1, transported, decapsulated at PE2, and 212 transmitted out of PE2. 214 3. The Pseudowire Label 216 Suppose it is desired to transport layer 2 PDUs from ingress LSR PE1 217 to egress LSR PE2, across an intervening PSN. We assume that there is 218 a PSN tunnel from PE1 to PE2. That is, we assume that PE1 can cause a 219 packet to be delivered to PE2 by encapsulating the packet in a "PSN 220 tunnel header" and sending the result to one of its adjacencies. If 221 the PSN tunnel is an MPLS Label Switched Path (LSP), then putting on 222 a PSN tunnel encapsulation is a matter of pushing on an additional 223 MPLS label. 225 We presuppose that an arbitrary number of pseudowires can be carried 226 through a single PSN tunnel. Thus it is never necessary to maintain 227 state in the network core for individual pseudowires. We do not 228 presuppose that the PSN tunnels are point-to-point; although the 229 pseudowires are point-to-point, the PSN tunnels may be multipoint- 230 to-point. We do not presuppose that PE2 will even be able to 231 determine the PSN tunnel through which a received packet was 232 transmitted. (E.g., if the PSN tunnel is an LSP, and penultimate hop 233 popping is used, when the packet arrives at PE2 it will contain no 234 information identifying the tunnel.) 236 When PE2 receives a packet over a pseudowire, it must be able to 237 determine that the packet was in fact received over a pseudowire, and 238 it must be able to associate that packet with a particular 239 pseudowire. PE2 is able to do this by examining the MPLS label which 240 serves as the pseudowire demultiplexor field shown in Figure 2. Call 241 this label the "PW label". 243 So when PE1 sends a layer 2 PDU to PE2, it first pushes a PW label on 244 its label stack, thereby creating an MPLS packet. It then (if PE1 is 245 not adjacent to PE2) encapsulates that MPLS packet in a PSN tunnel 246 header. (If the PSN tunnel is an LSP, this is just a matter of 247 pushing on a second label.) The PW label is not visible again until 248 the MPLS packet reaches PE2. PE2's disposition of the packet is based 249 on the PW label. 251 Note that the PW label must always be at the bottom of the packet's 252 label stack and labels MUST be allocated from the per-platform label 253 space. 255 This document specifies a protocol for assigning and distributing the 256 PW label. This protocol is LDP, extended as specified in the 257 remainder of this document. An LDP session must be set up between 258 the pseudowire endpoints. LDP MUST be used in its "downstream 259 unsolicited" mode. LDP's "liberal label retention" mode SHOULD be 260 used. 262 In addition to the protocol specified herein, static assignment of PW 263 labels MAY be used, and implementations of this protocol SHOULD 264 provide support for static assignment. 266 This document specifies all the procedures necessary to set up and 267 maintain the pseudowires needed to support "unswitched" point-to- 268 point services, where each endpoint of the pseudowire is provisioned 269 with the identify of the other endpoint. There are also protocol 270 mechanisms specified herein which can be used to support switched 271 services, and which can be used to support other provisioning models. 272 However, the use of the protocol mechanisms to support those other 273 models and services is not described in this document. 275 4. Details Specific to Particular Emulated Services 276 4.1. Frame Relay 278 When emulating a frame relay service, the Frame Relay PDUs are 279 encapsulated according to the procedures defined in [7]. The PE MUST 280 provide Frame Relay PVC status signaling to the Frame Relay network. 281 If the PE detects a service-affecting condition for a particular 282 DLCI, as defined in [2] Q.933 Annex A.5 sited in IA FRF1.1, PE MUST 283 communicate to the remote PE the status of the PW corresponds to the 284 frame relay DLCI. The Egress PE SHOULD generate the corresponding 285 errors and alarms as defined in [2] on the egress Frame relay PVC. 287 4.2. ATM 289 4.2.1. ATM AAL5 SDU VCC Transport 291 ATM AAL5 CSPS-SDUs are encapsulated according to [9] ATM AAL5 CPCS- 292 SDU mode. This mode allows the transport of ATM AAL5 CSPS-SDUs 293 traveling on a particular ATM PVC across the network to another ATM 294 PVC. 296 4.2.2. ATM Transparent Cell Transport 298 This mode is similar to the Ethernet port mode. Every cell that is 299 received at the ingress ATM port on the ingress PE, PE1, is 300 encapsulated according to [9], ATM cell mode n-to-one, and sent 301 across the PW to the egress PE, PE2. This mode allows an ATM port to 302 be connected to only one other ATM port. [9] ATM cell n-to-one mode 303 allows for concatenation ( grouping ) of multiple cells into a single 304 MPLS frame. Concatenation of ATM cells is OPTIONAL for transmission 305 at the ingress PE, PE1. If the Egress PE PE2 supports cell 306 concatenation the ingress PE, PE1, should only concatenate cells up 307 to the "Maximum Number of concatenated ATM cells" parameter received 308 as part of the FEC element. 310 4.2.3. ATM n-to-one VCC and VPC Cell Transport 312 This mode is similar to the ATM AAL5 VCC transport except that cells 313 are transported. Every cell that is received on a pre-defined ATM 314 PVC, or ATM PVP, at the ingress ATM port on the ingress PE, PE1, is 315 encapsulated according to [9], ATM n-to-one cell mode, and sent 316 across the LSP to the egress PE PE2. Grouping of ATM cells is 317 OPTIONAL for transmission at the ingress PE, PE1. If the Egress PE 318 PE2 supports cell concatenation the ingress PE, PE1, MUST only 319 concatenate cells up to the "Maximum Number of concatenated ATM cells 320 in a frame" parameter received as part of the FEC element. 322 4.2.4. OAM Cell Support 324 OAM cells MAY be transported on the PW LSP. When the PE is operating 325 in AAL5 CPCS-SDU transport mode if it does not support transport of 326 ATM cells, the PE MUST discard incoming MPLS frames on an ATM PW LSP 327 that contain a PW label with the T bit set [9]. When operating in 328 AAL5 SDU transport mode an PE that supports transport of OAM cells 329 using the T bit defined in [9], or an PE operating in any of the cell 330 transport modes MUST follow the procedures outlined in [9] in 331 addition to the applicable procedures specified in [6]. 333 4.2.4.1. SDU/PDU OAM Cell Emulation Mode 335 A PE operating in ATM SDU, or PDU transport mode, that does not 336 support transport of OAM cells across an LSP MAY provide OAM support 337 on ATM PVCs using the following procedures: 339 - Loopback cells response 341 If an F5 end-to-end OAM cell is received from a ATM VC, by either 342 PE that is transporting this ATM VC, with a loopback indication 343 value of 1, and the PE has a label mapping for the ATM VC, then 344 the PE MUST decrement the loopback indication value and loop back 345 the cell on the ATM VC. Otherwise the loopback cell MUST be 346 discarded by the PE. 348 - AIS Alarm. 350 If an ingress PE, PE1, receives an AIS F4/F5 OAM cell, it MUST 351 notify the remote PE of the failure. The remote PE , PE2, MUST in 352 turn send F5 OAM AIS cells on the respective PVCs. Note that if 353 the PE supports forwarding of OAM cells, then the received OAM 354 AIS alarm cells MUST be forwarded along the PW as well. 356 - Interface failure. 358 If the PE detects a physical interface failure, or the interface 359 is administratively disabled, the PE MUST notify the remote PE 360 for all VCs associated with the failure. 362 - PSN/PW failure detection. 364 If the PE detects a failure in the PW, by receiving a label 365 withdraw for a specific PW ID, or the targeted LDP session fails, 366 or a PW status TLV notification is received, then a propper AIS 367 F5 OAM cell MUST be generated for all the affected atm PVCs. The 368 AIS OAM alarm will be generated on the ATM output port of the PE 369 that detected the failure. 371 4.2.5. ILMI Support 373 An MPLS edge PE MAY provide an ATM ILMI to the ATM edge switch. If an 374 ingress PE receives an ILMI message indicating that the ATM edge 375 switch has deleted a VC, or if the physical interface goes down, it 376 MUST send a PW status notification message for all PWs associated 377 with the failure. When a PW label mapping is withdrawn, or PW status 378 notification message is received the egress PE SHOULD notify its 379 client of this failure by deleting the VC using ILMI. 381 4.2.6. ATM AAL5 PDU VCC Transport 383 ATM AAL5 CSPS-PDUs are encapsulated according to [9] ATM AAL5 CPCS- 384 PDU mode. This mode allows the transport of ATM AAL5 CSPS-PDUs 385 traveling on a particular ATM PVC across the network to another ATM 386 PVC. This mode supports fragmentation of the ATM AAL5 CPCS-PDU in 387 order to maintain the position of the OAM cells with respect to the 388 user cells. Fragmentation may also be performed to maintain the size 389 of the packet carrying the AAL5 PDU within the MTU of the link. 391 4.2.7. ATM one-to-one VCC and VPC Cell Transport 393 This mode is similar to the ATM AAL5 n-to-one cell transport except 394 an encapsulation method that maps one ATM VCC or one ATM VPC to one 395 Pseudo-Wire is used. Every cell that is received on a pre-defined ATM 396 PVC, or ATM PVP, at the ingress ATM port on the ingress PE, PE1, is 397 encapsulated according to [9], ATM one-to-one cell mode, and sent 398 across the LSP to the egress PE PE2. Grouping of ATM cells is 399 OPTIONAL for transmission at the ingress PE, PE1. If the Egress PE 400 PE2 supports cell concatenation the ingress PE, PE1, MUST only 401 concatenate cells up to the "Maximum Number of concatenated ATM cells 402 in a frame" parameter received as part of the FEC element. 404 4.3. Ethernet Tagged Mode 406 The Ethernet frame will be encapsulated according to the procedures 407 in [11] tagged mode. It should be noted that if the VLAN identifier 408 is modified by the egress PE, according to the procedures outlined 409 above, the Ethernet spanning tree protocol might fail to work 410 properly. If the PE detects a failure on the Ethernet physical port, 411 or the port is administratively disabled, it MUST send PW status 412 notification message for all PWs associated with the port. This mode 413 uses service-delimiting tags to map input ethernet frames to 414 respective PWs. 416 4.4. Ethernet 418 The Ethernet frame will be encapsulated according to the procedures 419 in [11] "ethernet raw mode". If the PE detects a failure on the 420 Ethernet input port, or the port is administratively disabled, the PE 421 MUST send a corresponding PW status notification message. 423 4.5. HDLC and PPP 425 HDLC and PPP frames are encapsulated according to the procedures in 426 [10]. If the MPLS edge PE detects that the physical link has failed, 427 or the port is administratively disabled, it MUST send a PW status 428 notification message that corresponds to the HDLC or PPP PW. 430 4.6. IP Layer2 Transport 432 This mode switches IP packets into a Peudo-Wire. the encapsulation 433 used is according to [3]. IP interworking is implementation specific, 434 part of the NSP function [12], and is outside the scope of this 435 document. The control word MUST not be used. 437 5. LDP 439 The PW label bindings are distributed using the LDP downstream 440 unsolicited mode described in [1]. The PEs will establish an LDP 441 session using the Extended Discovery mechanism described in [1, 442 section 2.4.2 and 2.5]. 444 An LDP Label Mapping message contains a FEC TLV, a Label TLV, and 445 zero or more optional parameter TLVs. 447 The FEC TLV is used to indicate the meaning of the label. In the 448 current context, the FEC TLV would be used to identify the particular 449 pseudowire that a particular label is bound to. In this 450 specification, we define two new FEC TLVs to be used for identifying 451 pseudowires. When setting up a particular pseudowire, only one of 452 these FEC TLVs is used. The one to be used will depend on the 453 particular service being emulated and on the particular provisioning 454 model being supported. 456 LDP allows each FEC TLV to consist of a set of FEC elements. For 457 setting up and maintaining pseudowires, however, each FEC TLV MUST 458 contain exactly one FEC element. 460 LDP has several kinds of label TLVs. For setting up and maintaining 461 pseudowires, the Generic Label TLV MUST be used. 463 5.1. The PWid FEC Element 465 The PWid FEC element may be used whenever both pseudowire endpoints 466 have been provisioned with the same 32-bit identifier for the 467 pseudowire. 469 For this purpose a new type of FEC element is defined. The FEC 470 element type is 128 [note1], and is defined as follows: 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | PW tlv |C| PW type |PW info Length | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Group ID | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | PW ID | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Interface parameters | 482 | " | 483 | " | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 - PW type 488 A 15 bit quantity containing a value which represents the type of 489 PW. Assigned Values are specified in "IANA Allocations for pseudo 490 Wire Edge to Edge Emulation (PWE3)" [13]. 492 - Control word bit (C) 494 The highest order bit (C) of the PW type is used to flag the 495 presence of a control word ( defined in [7] ) as follows: 497 bit 15 = 1 control word present on this PW. 498 bit 15 = 0 no control word present on this PW. 500 Please see the section "C-Bit Handling Procedures" for further 501 explanation. 503 - PW information length 505 Length of the PW ID field and the interface parameters field in 506 octets. If this value is 0, then it references all PWs using the 507 specified group ID and there is no PW ID present, nor any 508 interface parameters. 510 - Group ID 512 An arbitrary 32 bit value which represents a group of PWs that is 513 used to create groups in the PW space. The group ID is intended 514 to be used as a port index, or a virtual tunnel index. To 515 simplify configuration a particular PW ID at ingress could be 516 part of the virtual tunnel for transport to the egress router. 517 The Group ID is very useful to send wild card label withdrawals, 518 or PW wild card status notification messages to remote PEs upon 519 physical port failure. 521 - PW ID 523 A non-zero 32-bit connection ID that together with the PW type, 524 identifies a particular PW. Note that the PW ID and the PW type 525 must be the same at both endpoints. 527 - Interface parameters 529 This variable length field is used to provide interface specific 530 parameters, such as CE-facing interface MTU. 532 Note that as the "interface parameters" are part of the FEC, the 533 rules of LDP make it impossible to change the interface 534 parameters once the pseudowire has been set up. Thus the 535 interface parameters field must not be used to pass information, 536 such as status information, which may change during the life of 537 the pseudowire. Optional parameter TLVs should be used for that 538 purpose. 540 Using the PWid FEC, each of the two pseudowire endpoints 541 independently initiates the set up of a unidirectional LSP. An 542 outgoing LSP and an incoming LSP are bound together into a single 543 pseudowire if they have the same PW ID and PW type. 545 5.2. The Generalized ID FEC Element 547 The PWid FEC element can be used if a unique 32-bit value has been 548 assigned to the PW, and if each endpoint has been provisioned with 549 that value. The Generalized ID FEC element requires that the PW 550 endpoints be uniquely identified; the PW itself is identified as a 551 pair of endpoints. In addition the endpoint identifiers are 552 structured to support applications where the identity of the remote 553 endpoints needs to be auto-discovered rather than statically 554 configured. 556 The "Generalized ID FEC Element" is FEC type 129 (provisionally, 557 subject to assignment by IANA). 559 The Generalized ID FEC Element not contain anything corresponding to 560 the "group id" of the PWid FEC element. The functionality of the 561 latter is provided by a separate optional LDP TLV, the "PW Grouping 562 TLV", described below. The Interface Parameters field of the PWid FEC 563 element is also absent; its functionality is replaced by the optional 564 Interface Parameters TLV, described below. 566 5.2.1. Attachment Identifiers 568 As discussed in [12], a pseudowire can be thought of as connecting 569 two "forwarders". The protocol used to setup a pseudowire must allow 570 the forwarder at one end of a pseudowire to identify the forwarder at 571 the other end. We use the term "attachment identifier", or "AI", to 572 refer to the field which the protocol uses to identify the 573 forwarders. In the PWid FEC, the PWid field serves as the AI. In 574 this section we specify a more general form of AI which is structured 575 and of variable length. 577 Every Forwarder in a PE must be associated with an Attachment 578 Identifier (AI), either through configuration or through some 579 algorithm. The Attachment Identifier must be unique in the context 580 of the PE router in which the Forwarder resides. The combination must be globally unique. 583 It is frequently convenient to regard a set of Forwarders as being 584 members of a particular "group", where PWs may only be set up among 585 members of a group. In such cases, it is convenient to identify the 586 Forwarders relative to the group, so that an Attachment Identifier 587 would consist of an Attachment Group Identifier (AGI) plus an 588 Attachment Individual Identifier (AII). 590 An Attachment Group Identifier may be thought of as a VPN-id, or 591 a VLAN identifier, some attribute which is shared by all the 592 Attachment PWs (or pools thereof) which are allowed to be connected. 594 The details of how to construct the AGI and AII fields identifying 595 the pseudowire endpoints are outside the scope of this specification. 596 Different pseudowire application, and different provisioning models, 597 will require different sorts of AGI and AII fields. The 598 specification of each such application and/or model must include the 599 rules for constructing the AGI and AII fields. 601 As previously discussed, a (bidirectional) pseudowire consists of a 602 pair of unidirectional LSPs, one in each direction. If a particular 603 pseudowire connects PE1 with PE2, the LSP in the PE1-->PE2 direction 604 can be identified as: 606 , PE2, >, 608 and the LSP in the PE2--PE1 direction can be identified by: 610 , PE1, >. 612 Note that the AGI must be the same at both endpoints, but the AII 613 will in general be different at each endpoint. Thus from the 614 perspective of a particular PE, each pseudowire has a local or 615 "Source AII", and a remote or "Target AII". The pseudowire setup 616 protocol can carry all three of these quantities: 618 - Attachment Group Identifier (AGI). 620 - Source Attachment Individual Identifier (SAII) 622 - Target Attachment Individual Identifier (TAII) 624 If the AGI is non-null, then the Source AI (SAI) consists of the AGI 625 together with the SAII, and the Target AI (TAI) consists of the TAII 626 together with the AGI. If the AGI is null, then the SAII and TAII 627 are the SAI and TAI respectively. 629 The interpretation of the SAI and TAI is a local matter at the 630 respective endpoint. 632 The association of two unidirectional LSPs into a single 633 bidirectional pseudowire depends on the SAI and the TAI. Each 634 application and/or provisioning model which uses the Generalized ID 635 FEC element must specify the rules for performing this association. 637 5.2.2. Encoding the Generalized ID FEC Element 639 FEC element type 129 [note1] is used. The FEC element is encoded as 640 follows: 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | 129 |C| PW Type |PW info Length | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | AGI | Length | Value | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 ~ Value (contd.) ~ 650 | | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | SAII | Length | Value | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 ~ Value (contd.) ~ 655 | | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | TAII | Length | Value | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 ~ Value (contd.) ~ 660 | | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 This document does not specify the SAII,TAII,AGI type field values; 664 specification of the type field values to use for a particular 665 application is part of the specification of that application. IANA 666 will assign these values based on IETF consensus. 668 The SAII, TAII, and AGI are simply carried as octet strings. The 669 length byte specifies the size of the Value field. The null string 670 can be sent by setting the length byte to 0. 672 If a particular application does not need all three of these sub- 673 elements, it MUST send all the sub-elements, but set the length to 0 674 for the unused sub-elements. 676 Note that the interpretation of a particular field as AGI, SAII, or 677 TAII depends on the order of its occurrence. The type field 678 identifies the type of the AGI, SAII, or TAII. When comparing two 679 occurrences of an AGI (or SAII or TAII), the two occurrences are 680 considered to be identical if the type, length, and value fields of 681 one are identical, respectively, to those of the other. 683 5.2.2.1. Interface Parameters TLV 685 This TLV MUST only be used when sending the Generalized PW FEC. It 686 specifies interface specific parameters. Specific parameters, when 687 applicable, MUST be used to validate that the PEs, and the ingress 688 and egress ports at the edges of the circuit, have the necessary 689 capabilities to interoperate with each other. 691 0 1 2 3 692 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 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 |0|0| PW Intf P. TLV (0x096B) | Length | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Parameter ID | Length | Variable Length Value | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Variable Length Value | 699 | " | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 [ note: TLV type 0x096B as defined in [13] pending IANA allocation ] 704 A more detailed description of this field can be found in the section 705 "Interface Parameters Field" below. 707 5.2.2.2. PW Grouping TLV 709 0 1 2 3 710 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 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 |0|0|PW Grouping ID TLV (0x096C)| Length | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Parameter ID | Length | Variable Length Value | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Variable Length Value | 717 | " | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 [ note: TLV type 0x096C as defined in [13] pending IANA allocation ] 722 The PW Grouping ID is an arbitrary 32 bit value which represents an 723 arbitrary group of PWs. It is used create groups PWs; for example, a 724 PW Grouping ID can be used as a port index, and assigned to all PWs 725 that lead to that port. Use of the PW Grouping ID enables one to 726 send "wild card" label withdrawals, or "wild card" status 727 notification messages to remote PEs upon physical port failure. 729 Note Well: The PW Grouping ID is different than, and has no relation 730 to, the Attachment Group Identifier. 732 The PW Grouping ID TLV is not part of the FEC, and will not be 733 advertised except in the initial PW FEC advertisement. The 734 advertising PE MAY use the wild card withdraw semantics, but the 735 remote PEs MUST implement support for wildcard messages. If the PW 736 Grouping ID is not going to be used for wild card messages, it MAY be 737 omitted. 739 To issue a wildcard command ( status or withdraw ): 741 -i. Set the PW Info Length to 0 in the Generalized ID FEC 742 Element. 743 -ii. Send only the PW Grouping ID TLV with the FEC ( No 744 AGI/SAII/TAII is sent ). 746 5.2.3. Signaling Procedures 748 In order for PE1 to begin signaling PE2, PE1 must know the address of 749 the remote PE2, and a TAI. This information may have been configured 750 at PE1, or it may have been learned dynamically via some 751 autodiscovery procedure. 753 To begin the signaling procedure, a PE (PE1) that has knowledge of 754 the other endpoint (PE2) initiates the setup of the LSP in the 755 incoming (PE2-->PE1) direction by sending a Label Mapping message 756 containing the FEC type 129. The FEC element includes the SAII, AGI, 757 and TAII. 759 What happens when PE2 receives such a Label Mapping message? 761 PE2 interprets the message as a request to set up a PW whose endpoint 762 (at PE2) is the Forwarder identified by the TAI. From the 763 perspective of the signaling protocol, exactly how PE2 maps AIs to 764 Forwarders is a local matter. In some VPWS provisioning models, the 765 TAI might, e.g., be a string which identifies a particular Attachment 766 Circuit, such as "ATM3VPI4VCI5", or it might, e.g., be a string such 767 as "Fred" which is associated by configuration with a particular 768 Attachment Circuit. In VPLS, the AGI could be a VPN-id, identifying 769 a particular VPLS instance. 771 If PE2 cannot map the TAI to one of its Forwarders, then PE2 sends a 772 Label Release message to PE1, with a Status Code meaning "invalid 773 TAI" ,[ note: Status Code 0x00000029 as defined in [13] pending IANA 774 allocation ] and the processing of the Mapping message is complete. 776 The FEC TLV sent in a Label Release is the same as the FEC TLV 777 received in the Label Mapping being released (but without the 778 interface parameters). More generally, the FEC TLV is the same in 779 all LDP messages relating to the same LSP. In a Label Release this 780 means that the SAII is the remote peer's AII and the TAII is the 781 sender's local AII. 783 If the Label Mapping Message has a valid TAI, PE2 must decide whether 784 to accept it or not. The procedures for so deciding will depend on 785 the particular type of Forwarder identified by the TAI. Of course, 786 the Label Mapping message may be rejected due to standard LDP error 787 conditions as detailed in [1]. 789 If PE2 decides to accept the Label Mapping message, then it has to 790 make sure that an LSP is set up in the opposite (PE1-->PE2) 791 direction. If it has already signaled for the corresponding LSP in 792 that direction, nothing more need be done. Otherwise, it must 793 initiate such signaling by sending a Label Mapping message to PE1. 794 This is very similar to the Label Mapping message PE2 received, but 795 with the SAI and TAI reversed. 797 Thus a bidirectional PW consists of two LSPs, where the FEC of one is 798 the "reverse" of the FEC of the other. 800 5.3. Signaling of Pseudo Wire Status 802 5.3.1. Use of Label Mappings. 804 The PEs MUST send PW label mapping messages to their peers as soon as 805 the PW is configured and administratively enabled, regardless of the 806 CE-facing interface state. The PW label should not be withdrawn 807 unless the user administratively configures the CE-facing interface 808 down (or the PW configuration is deleted entirely). Using the 809 procedures outlined in this section a simple label withdraw method 810 MAY also be supported as a primitive means of signaling PW status. It 811 is strongly RECOMMENDED that the PW status signaling procedures below 812 be fully implemented. In any case if the Label mapping is not 813 available the PW MUST be considered in the down state. 815 5.3.2. Signaling PW status. 817 The PE devices use an LDP TLV to indicate status to their remote 818 peers. This PW Status TLV contains more information than the 819 alternative simple Label Withdraw message. 821 The format of the PW Status TLV is: 823 0 1 2 3 824 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 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 |1|0| PW Status (0x096A) | Length | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Status Code | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 [ note: TLV type 0x096A as defined in [13] pending IANA allocation ] 833 Where the status code is a 4 octet bit field is specified in the PW 834 IANA Allocations document [13]. The length specifies the length of 835 the Status Code field in octets ( equal to 4 ). 837 Each bit in the status code field can be set individually to indicate 838 more then a single failure at once. Each fault can be cleared by 839 sending an appropriate status message with the respective bit 840 cleared. The presence of the lowest bit (PW Not Forwarding) acts only 841 as a generic failure indication when there is a link-down event for 842 which none of the other bits apply. 844 The Status TLV is transported to the remote PW peer via the LDP 845 notification message. The general format of the Notification Message 846 is: 848 0 1 2 3 849 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 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 |0| Notification (0x0001) | Message Length | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Message ID | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Status (TLV) | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | PW Status TLV | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | PWId FEC or Generalized ID FEC | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 The Status TLV status code is set to 0x00000028 "PW status", to 863 indicate that PW status follows. Since this notification does not 864 refer to any particular message the Message Id, and Message Type 865 fields are set to 0. [ note: Status Code 0x00000028 as defined in 866 [13] pending IANA allocation ] A more detailed diagram is shown in 867 Appendix B. 869 The PW FEC TLV SHOULD not include the interface parameters as they 870 are ignored in the context of this message. When a PE's CE-facing 871 interface encounters an error, use of the PW status message allows 872 the PE to send a single "wild card" status message, using a PW FEC 873 TLV with only the group ID set, to denote this change in status for 874 all affected PW connections. This status message contains either the 875 PW FEC TLV with only the group ID set, or else it contains the 876 Generalized FEC TLV and the PW Grouping ID TLV. 878 As mentioned above the Group ID field of the PWid FEC element, or the 879 PW Grouping ID TLV used with the Generalized ID FEC element, can be 880 used to send a status notification for all arbitrary sets of PWs. 881 This procedure is OPTIONAL, and if it is implemented the LDP 882 Notification message should be as follows. If the PWid FEC element 883 is used, the PW information length field is set to 0, the PW ID field 884 is not present, and the interface parameters field is not present. If 885 the Generalized FEC element is used, the AGI, SAII, and TAII are all 886 set to have length zero, the PW Grouping ID TLV is included, and the 887 Interface Parameters TLV is omitted. For the purpose of this 888 document this is called the "wild card PW status notification 889 procedure", and all PEs implementing this design are REQUIRED to 890 accept such a notification message, but are not required to send it. 892 5.3.3. Pseudowire Status Negotiation Procedures 894 When a PW is first set up the PEs MUST attempt to negotiate the usage 895 of the PW status TLV. This is accomplished as follows: A PE that 896 supports the PW Status TLV MUST include it the initial label mapping 897 signaling following label mapping TLV, the PW FEC, and the interface 898 parameters field. The PW Status TLV will then be used for the 899 lifetime of the Pseudowire. This is shown in the following diagram: 901 0 1 2 3 902 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 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | | 905 + PWId FEC or Generalized ID FEC + 906 | | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | Interface parameters | 909 | " | 910 | " | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 |0|0| Generic Label (0x0200) | Length | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Label | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 |1|0| PW Status (0x0???) | Length | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Status Code | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 If PW status TLV is sent following the label mapping TLV in the 922 initial PW FEC Message, but the remote PE corresponding FEC 923 advertisement does not include a PW status TLV, or the remote PE does 924 not support the PW Status TLV and the PW will revert to the label 925 withdraw method to signal PW status. Note that if the PW Status TLV 926 is not supported, by the remote peer, it will automatically be 927 ignored, since the LDP ignore bit is set. The PW Status TLV, 928 therefore, will not be present in the corresponding FEC advertisement 929 from the remote LDP peer resulting in exactly the above behavior. 931 If the PW Status TLV is not present following the label mapping TLV 932 in the initial PW FEC Message received by a PE, then the PW Status 933 TLV will not be used and both PEs supporting the pseudowire will 934 revert to the label withdraw procedure for signaling status changes. 936 If the negotiation process results in the usage of the PW status TLV, 937 then the actual PW status is determined by the PW status TLV that was 938 sent within the initial PW label mapping. Subsequent updates of PW 939 status are conveyed through the notification message 941 5.4. Interface Parameters Field 943 This field specifies interface specific parameters. When applicable, 944 it MUST be used to validate that the PEs, and the ingress and egress 945 ports at the edges of the circuit, have the necessary capabilities to 946 interoperate with each other. The field structure is defined as 947 follows: 949 0 1 2 3 950 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 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Parameter ID | Length | Variable Length Value | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | Variable Length Value | 955 | " | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 The parameter ID Values are specified in "IANA Allocations for pseudo 959 Wire Edge to Edge Emulation (PWE3)" [13]. 961 The Length field is defined as the length of the interface parameter 962 including the parameter id and length field itself. Processing of the 963 interface parameters should continue when encountering unknown 964 interface parameters and they MUST be silently ignored. 966 - Interface MTU 968 A 2 octet value indicating the MTU in octets. This is the Maximum 969 Transmission Unit, excluding encapsulation overhead, of the 970 egress packet interface that will be transmitting the 971 decapsulated PDU that is received from the MPLS network. This 972 parameter is applicable only to PW types 1, 2, 4, 5, 6, 7,14, and 973 15 and is REQUIRED for these PW types. If this parameter does not 974 match in both directions of a specific PW, that PW MUST NOT be 975 enabled. 977 - Maximum Number of concatenated ATM cells 979 A 2 octet value specifying the maximum number of concatenated ATM 980 cells that can be processed as a single PDU by the egress PE. An 981 ingress PE transmitting concatenated cells on this PW can 982 concatenate a number of cells up to the value of this parameter, 983 but MUST NOT exceed it. This parameter is applicable only to PW 984 types 3, 9, 0x0a, 0xc, and 0xd and is REQUIRED for these PWC 985 types. This parameter does not need to match in both directions 986 of a specific PW. 988 - Optional Interface Description string 990 This arbitrary, OPTIONAL, interface description string is used to 991 send a human-readable administrative string describing the 992 interface to the remote. This parameter is OPTIONAL, and is 993 applicable to all PW types. The interface description parameter 994 string length is variable, and can be from 0 to 80 octets. 995 Human-readable text MUST be provided in the UTF-8 charset using 996 the Default Language [RFC2277]. 998 - Payload Bytes 1000 A 2 octet value indicating the number of TDM payload octets 1001 contained in all packets on the CEM stream, from 48 to 1,023 1002 octets. All of the packets in a given CEM stream have the same 1003 number of payload bytes. Note that there is a possibility that 1004 the packet size may exceed the SPE size in the case of an STS-1 1005 SPE, which could cause two pointers to be needed in the CEM 1006 header, since the payload may contain two J1 bytes for 1007 consecutive SPEs. For this reason, the number of payload bytes 1008 must be less than or equal to 783 for STS-1 SPEs. 1010 - CEP Options. 1012 An optional 16 Bit value of CEM Flags. See [8] for the definition 1013 of the bit values. 1015 - Requested VLAN ID. 1017 An Optional 16 bit value indicating the requested VLAN ID. This 1018 parameter MAY be used by an PE that is incapable of rewriting the 1019 802.1Q ethernet VLAN tag on output. If the ingress PE receives 1020 this request it MAY rewrite the VLAN ID tag in input to match the 1021 requested VLAN ID. If this is not possible, and the VLAN ID does 1022 not already match configured ingress VLAN ID the PW should not be 1023 enabled.This parameter is applicable only to PW type 4. 1025 - CEP/TDM bit rate. 1027 This 32-bit integer is mandatory for CEP. For other PWs carrying 1028 TDM traffic it is mandatory if the bit-rate cannot be directly 1029 inferred from the service type. If present, it expresses the bit 1030 rate of the attachment circuit as known to the advertizing PE in 1031 "units" of 64 kbit/s. I.e., the value 26 must be used for CEP 1032 carrying VT1.5 SPE, 35 - for CEP carrying a VT2 SPE, 99 - for VT6 1033 SPE, 783 - for STS-1 SPE and n*783 - for STS-nc, n = 3, 12, 48, 1034 192. Attempts to establish a PWC between a pair of TDM ports 1035 with different bit-rates MUST be rejected with the appropriate 1036 status code (see section "Status codes" in [13]). 1038 - Frame-Relay DLCI length. 1040 An optional 16 bit value indicating the lenght of the frame-relay 1041 DLCI field. This OPTIONAL interface paremeter can have value of 2 1042 , or 4, with the default being equal to 2. If this interface 1043 parameter is not present the default value of 2 is assumed. 1045 5.4.1. PW types for which the control word is REQUIRED 1047 The Label Mapping messages which are sent in order to set up these 1048 PWs MUST have c=1. When a Label Mapping message for a PW of one of 1049 these types is received, and c=0, a Label Release MUST be sent, with 1050 an "Illegal C-bit" status code. In this case, the PW will not be 1051 enabled. 1053 5.4.2. PW types for which the control word is NOT mandatory 1055 If a system is capable of sending and receiving the control word on 1056 PW types for which the control word is not mandatory, then each such 1057 PW endpoint MUST be configurable with a parameter that specifies 1058 whether the use of the control word is PREFERRED or NOT PREFERRED. 1059 For each PW, there MUST be a default value of this parameter. This 1060 specification does NOT state what the default value should be. 1062 If a system is NOT capable of sending and receiving the control word 1063 on PWC types for which the control word is not mandatory, then it 1064 behaves as exactly as if it were configured for the use of the 1065 control word to be NOT PREFERRED. 1067 If a Label Mapping message for the PW has already been received, but 1068 no Label Mapping message for the PW has yet been sent, then the 1069 procedure is the following: 1071 -i. If the received Label Mapping message has c=0, send a Label 1072 Mapping message with c=0, and the control word is not used. 1073 -ii. If the received Label Mapping message has c=1, and the PW is 1074 locally configured such that the use of the control word is 1075 preferred, then send a Label Mapping message with c=1, and 1076 the control word is used. 1077 -iii. If the received Label Mapping message has c=1, and the PW is 1078 locally configured such that the use of the control word is 1079 not preferred or the control word is not supported, then act 1080 as if no Label Mapping message for the PW had been received 1081 (i.e., proceed to the next paragraph). 1083 If a Label Mapping message for the PW has not already been received 1084 (or if the received Label Mapping message had c=1 and either local 1085 configuration says that the use of the control word is not preferred 1086 or the control word is not supported), then send a Label Mapping 1087 message in which the c bit is set to correspond to the locally 1088 configured preference for use of the control word. (I.e., set c=1 if 1089 locally configured to prefer the control word, set c=0 if locally 1090 configured to prefer not to use the control word or if the control 1091 word is not supported). 1093 The next action depends on what control message is next received for 1094 that PW. The possibilities are: 1096 -i. A Label Mapping message with the same c bit value as 1097 specified in the Label Mapping message that was sent. PW 1098 setup is now complete, and the control word is used if c=1 1099 but not used if c=0. 1100 -ii. A Label Mapping message with c=1, but the Label Mapping 1101 message that was sent has c=0. In this case, ignore the 1102 received Label Mapping message, and continue to wait for the 1103 next control message for the PW. 1104 -iii. A Label Mapping message with c=0, but the Label Mapping 1105 message that was sent has c=1. In this case, send a Label 1106 Withdraw message with a "Wrong c-bit" status code, followed 1107 by a Label Mapping message that has c=0. PW setup is now 1108 complete, and the control word is not used. 1109 -iv. A Label Withdraw message with the "Wrong c-bit" status code. 1110 Treat as a normal Label Withdraw, but do not respond. 1111 Continue to wait for the next control message for the PW. 1113 If at any time after a Label Mapping message has been received, a 1114 corresponding Label Withdraw or Release is received, the action taken 1115 is the same as for any Label Withdraw or Release that might be 1116 received at any time. 1118 If both endpoints prefer the use of the control word, this procedure 1119 will cause it to be used. If either endpoint prefers not to use the 1120 control word, or does not support the control word, this procedure 1121 will cause it not to be used. If one endpoint prefers to use the 1122 control word but the other does not, the one that prefers not to use 1123 it is has no extra protocol to execute, it just waits for a Label 1124 Mapping message that has c=0. 1126 The diagram in Appendix A illustrates the above procedure. 1128 5.4.3. Status codes 1130 RFC 3036 has a range of Status Code values which are assigned by IANA 1131 on a First Come, First Served basis. These additional status codes, 1132 and assigned Values are specified in "IANA Allocations for pseudo 1133 Wire Edge to Edge Emulation (PWE3)" [13]. 1135 5.5. LDP label Withdrawal procedures 1137 As mentioned above the Group ID field can be used to withdraw all PW 1138 labels associated with a particular group ID. This procedure is 1139 OPTIONAL, and if it is implemented the LDP label withdraw message 1140 should be as follows: the PW information length field is set to 0, 1141 the PW ID field is not present, and the interface parameters field or 1142 TLV are not present. For the purpose of this document this is called 1143 the "wild card withdraw procedure", and all PEs implementing this 1144 design are REQUIRED to accept such a withdraw message, but are not 1145 required to send it. 1147 The interface parameters field, or TLV, MUST NOT be present in any 1148 LDP PW label withdrawal message or release message. A wildcard 1149 release message MUST include only the group ID. A Label Release 1150 message initiated from the imposition router must always include the 1151 PW ID. 1153 5.6. Sequencing Considerations 1155 In the case where the router considers the sequence number field in 1156 the control word, it is important to note the following when 1157 advertising labels 1159 5.6.1. Label Mapping Advertisements 1161 After a label has been withdrawn by the disposition router and/or 1162 released by the imposition router, care must be taken to not re- 1163 advertise (re-use) the released label until the disposition router 1164 can be reasonably certain that old packets containing the released 1165 label no longer persist in the MPLS network. 1167 This precaution is required to prevent the imposition router from 1168 restarting packet forwarding with sequence number of 1 when it 1169 receives the same label mapping if there are still older packets 1170 persisting in the network with sequence number between 1 and 32768. 1171 For example, if there is a packet with sequence number=n where n is 1172 in the interval[1,32768] traveling through the network, it would be 1173 possible for the disposition router to receive that packet after it 1174 re-advertises the label. Since the label has been released by the 1175 imposition router, the disposition router SHOULD be expecting the 1176 next packet to arrive with sequence number to be 1. Receipt of a 1177 packet with sequence number equal to n will result in n packets 1178 potentially being rejected by the disposition router until the 1179 imposition router imposes a sequence number of n+1 into a packet. 1180 Possible methods to avoid this is for the disposition router to 1181 always advertise a different PW label, or for the disposition router 1182 to wait for a sufficient time before attempting to re-advertised a 1183 recently released label. This is only an issue when sequence number 1184 processing at the disposition router is enabled. 1186 5.6.2. Label Mapping Release 1188 In situations where the imposition router wants to restart forwarding 1189 of packets with sequence number 1, the router shall 1) Send to 1190 disposition router a label mapping release, and 2) Send to 1191 disposition router a label mapping request. When sequencing is 1192 supported, advertisement of a PW label in response to a label mapping 1193 request MUST also consider the issues discussed in the section on 1194 Label Mapping Advertisements. 1196 6. IANA Considerations 1198 6.1. FEC Type Name Space 1200 This document uses two new FEC element types, 128 and 129. IANA 1201 already maintains a registry of values of the "FEC Type Name Space" 1202 for the Label Distribution Protocol (LDP). In that registry, values 1203 in the range 128-191 are assignable on a First Come, First Served 1204 basis. IANA should assign values 128 and 129 from that space as 1205 specified in this document. 1207 6.2. Pseudowire Type 1209 IANA needs to set up a registry of "Pseudowire Types". These are 1210 15-bit values. PW Type values 1 through 63 are to be assigned by 1211 IANA using the "IETF Consensus" policy defined in RFC2434. PW Type 1212 values 64 through 127 are to be assigned by IANA, using the "First 1213 Come First Served" policy defined in RFC2434. VC Type values 128 1214 through 32767 are vendor-specific, and values in this range are not 1215 to be assigned by IANA. 1217 PW type values in the range 1-24 are specified in draft-ietf-pwe3- 1218 iana-allocation, and should be incorporated by IANA into the 1219 registry. 1221 6.3. Interface Parameters 1223 IANA needs to set up a registry of "Pseudowire Interface Parameter 1224 Identifiers". Parameter ID values 1 through 63 are to be assigned by 1225 IANA using the "IETF Consensus" policy defined in RFC2434. Parameter 1226 ID values 64 through 127 are to be assigned by IANA, using the "First 1227 Come First Served" policy defined in RFC2434. Parameter ID values 128 1228 through 255 are vendor- specific, and values in this range are not to 1229 be assigned by IANA. 1231 Pseudowire Interface Parameter Identifier values 1-11 are specified 1232 in draft-ietf-pwe3-iana-allocation, and should be incorporated by 1233 IANA into the registry. 1235 6.4. LDP Status Codes 1237 IANA already maintains a registry of LDP status codes. This 1238 specification requires additional status codes, whose values are 1239 specified in draft-pwe3-iana-allocation; IANA should add these to the 1240 registry. 1242 6.5. Pseudowire Status Codes 1244 IANA needs to set up a registry of "Pseudowire Status Codes". These 1245 are bitstrings of length 32. Status bits 1-15 are to be assigned by 1246 IANA using the "IETF Consensus" policy defined in RFC2434. Bits 1-5 1247 are specified in draft-ietf-pwe3-iana-allocation, and should be 1248 incorporated by IANA into the registry. PW Status Bits 16 through 23 1249 are to be assigned by IANA, using the "First Come First Served" 1250 policy defined in RFC2434. PW Status Bits 24 through 31 are vendor- 1251 specific, and values in this range are not to be assigned by IANA. 1253 7. Security Considerations 1255 This document specifies the LDP extensions that are needed for 1256 setting up and maintaining Pseudowires. The purpose of setting up 1257 Pseudowires is to enable layer 2 frames to be encapsulated in MPLS 1258 [8,9,10,11] and transmitted from one end of a Pseudowire to the 1259 other. Therefore we treat the security considerations for both the 1260 data plane and the control plane. 1262 7.1. Data-plane Security 1264 With regard to the security of the data plane, the following areas 1265 must be considered: 1267 - MPLS PDU inspection. 1268 - MPLS PDU spoofing. 1269 - MPLS PDU alteration. 1270 - MPLS PSN protocol security. 1271 - Access Circuit security. 1272 - Denial of service prevention on the PE routers. 1274 When a MPLS PSN is used to provide pseudowire service, there is a 1275 perception that security MUST be at least equal to the currently 1276 deployed layer2 native protocol networks that the MPLS/PW network 1277 combination is emulating. This means that the MPLS network SHOULD 1278 be isolated from outside packet insertion in such a way that it 1279 SHOULD not be possible to directly insert an MPLS packet into the 1280 network. To prevent unwanted packet insertion, it is also 1281 important to prevent unauthorized physical access to the PSN as 1282 well as unauthorized administrative access to individual network 1283 elements. The PSN transporting the PWs is an MPLS backbone, it 1284 should not accept MPLS packets from its external interfaces (i.e. 1285 interfaces to CE devices or to other providers' networks) unless 1286 the top label of the packet was legitimately distributed to the 1287 system from which the packet is being received. If the packet's 1288 incoming interface leads to a different SP (rather than to a 1289 customer), an appropriate trust relationship must also be 1290 present, including the trust that the other SP also provides 1291 appropriate security measures. 1293 The three main security problem faced when using an MPLS network 1294 to transport PWs are spoofing, alteration, and inspection. First 1295 there is a possibility that the PW receive endpoint will get a 1296 PDU which appears to be from the PE encapsulating the PW into the 1297 PSN, but which was not actually transmitted by the PE originating 1298 the PW. (I.e., the specified encapsulations do not by themselves 1299 enable the decapsulator to authenticate the encapsulator.) A 1300 second problem is the possibility that the PW PDU will be altered 1301 between the time it enters PSN and the time it leaves the PSN. 1302 (I.e., the specified encapsulations do not by themselves assure 1303 the decapsulator of the packet's integrity.) A third problem is 1304 the possibility that the PDU's contents will be seen while the 1305 PDU is in transit through the PSN. (I.e., the specification 1306 encapsulations do not ensure privacy.) How significant these 1307 issues are in practice depends on the security requirements of 1308 the applications whose traffic is being sent through the tunnel, 1309 and how secure is the PSN itself. E.g. if the PSN is an MPLS 1310 backbone, with no external MPLS interfaces, then it might be 1311 secured enought to transport PW PDUs. 1313 7.2. Control Protocol Security 1315 General security considerations with regard to the use of LDP are 1316 specified in section 5 of RFC 3036. Those considerations apply as 1317 well to the case where LDP is used to set up Pseudowires. 1319 A Pseudowire connects two attachment circuits. It is important to 1320 make sure that LDP connections are not arbitrarily accepted from 1321 anywhere, or else a local attachment circuit might get connected to 1322 an arbitrary remote attachment circuit. Therefore an incoming LDP 1323 session request MUST NOT be accepted unless its IP source address is 1324 known to be the source of an "eligible" LDP peer. The set of 1325 eligible peers could be pre-configured (either as a list of IP 1326 addresses, or as a list of address/mask combinations), or it could be 1327 discovered dynamically via an auto-discovery protocol which is itself 1328 trusted. (Obviously if the auto-discovery protocol were not trusted, 1329 the set of "eligible peers" it produces could not be trusted.) 1331 Even if an LDP connection request appears to come from an eligible 1332 peer, its source address may have been spoofed. So some means of 1333 preventing source address spoofing must be in place. For example, if 1334 all the eligible peers are in the same network, source address 1335 filtering at the border routers of that network could eliminate the 1336 possibility of source address spoofing. 1338 For a greater degree of security, the LDP MD5 authentication key 1339 option, as described in section 2.9 of RFC 3036, MAY be used. This 1340 provides integrity and authentication for the LDP messages, and 1341 eliminates the possibility of source address spoofing. Use of the 1342 MD5 option does not provide privacy, but privacy of the LDP control 1343 messages is not usually considered to be important. As the MD5 1344 option relies on the configuration of pre-shared keys, it does not 1345 provide much protection against replay attacks. In addition, its 1346 reliance on pre-shared keys may make it very difficult to deploy when 1347 the set of eligible neighbors is determined by an auto-configuration 1348 protocol. 1350 When the Generalized ID FEC Element is used, it is possible that a 1351 particular LDP peer may be one of the eligible LDP peers, but may not 1352 be the right one to connect to the particular attachment circuit 1353 identified by the particular instance of the Generalized ID FEC 1354 element. However, given that the peer is known to be one of the 1355 eligible peers (as discussed above), this would be the result of a 1356 configuration error, rather than a security problem. Nevertheless, 1357 it may be advisable for a PE to associate each of its local 1358 attachment circuits with a set of eligible peers, rather than having 1359 just a single set of eligible peers associated with the PE as a 1360 whole. 1362 8. Acknowledgments 1364 The authors wish to acknowledge the contributions of Vach Kompella, 1365 Vanson Lim, Wei Luo, Himanshu Shah, and Nick Weeds. 1367 9. Normative References 1369 [1] "LDP Specification." L. Andersson, P. Doolan, N. Feldman, A. 1370 Fredette, B. Thomas. January 2001. RFC3036 1372 10. Informative References 1374 [2] ITU-T Recommendation Q.933, and Q.922 Specification for Frame Mode Basic 1375 call control, ITU Geneva 1995 1377 [3] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter, D. Tappan, G. 1378 Fedorkow, D. Farinacci, T. Li, A. Conta. RFC3032 1380 [4] "IEEE 802.3ac-1998" IEEE standard specification. 1382 [5] American National Standards Institute, "Synchronous Optical Network 1383 Formats," ANSI T1.105-1995. 1385 [6] ITU Recommendation G.707, "Network Node Interface For The Synchronous 1386 Digital Hierarchy", 1996. 1388 [7] "Frame Relay over Pseudo-Wires", draft-ietf-pwe3-frame-relay-02.txt 1389 (work in progress ) 1391 [8] "SONET/SDH Circuit Emulation Service Over Packet (CEP)", 1392 draft-ietf-pwe3-sonet-07.txt (work in progress) 1394 [9] "Encapsulation Methods for Transport of ATM Cells/Frame Over IP and 1395 MPLS Networks", draft-ietf-pwe3-atm-encap-05.txt (work in progress) 1397 [10] "Encapsulation Methods for Transport of PPP/HDLC Frames Over IP and 1398 MPLS Networks", draft-ietf-pwe3-hdlc-ppp-encap-03.txt (work in progress) 1400 [11] "Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS 1401 Networks", draft-ietf-pwe3-ethernet-encap-06.txt. (work in progress) 1403 [12] "PWE3 Architecture" Bryant, et al., draft-ietf-pwe3-arch-07.txt (work 1404 in progress), March 2004 1406 [13] "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)" 1407 Martini, Townsley, draft-ietf-pwe3-iana-allocation-04.txt (work in 1408 progress), April 2004 1410 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1411 Considerations section in RFCs", BCP 26, RFC 2434, October 1998. 1413 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1414 Languages", BCP 18, RFC 2277, January 1998. 1416 [note1] FEC element type 128,129 is pending IANA approval. 1418 11. Author Information 1420 Luca Martini 1421 Cisco Systems, Inc. 1422 9155 East Nichols Avenue, Suite 400 1423 Englewood, CO, 80112 1424 e-mail: lmartini@cisco.com 1426 Nasser El-Aawar 1427 Level 3 Communications, LLC. 1428 1025 Eldorado Blvd. 1429 Broomfield, CO, 80021 1430 e-mail: nna@level3.net 1432 Giles Heron 1433 Tellabs 1434 Abbey Place 1435 24-28 Easton Street 1436 High Wycombe 1437 Bucks 1438 HP11 1NT 1439 UK 1440 e-mail: giles.heron@tellabs.com 1441 Eric C. Rosen 1442 Cisco Systems, Inc. 1443 1414 Massachusetts Avenue 1444 Boxborough, MA 01719 1445 e-mail: erosen@cisco.com 1447 Dan Tappan 1448 Cisco Systems, Inc. 1449 1414 Massachusetts Avenue 1450 Boxborough, MA 01719 1451 e-mail: tappan@cisco.com 1453 Toby Smith 1454 Omega Corporate Center 1455 1300 Omega Drive 1456 Pittsburgh, PA 15205 1457 Laurel Networks, Inc. 1458 e-mail: tob@laurelnetworks.com 1460 12. Additional Contributing Authors 1462 Dimitri Stratton Vlachos 1463 Mazu Networks, Inc. 1464 125 Cambridgepark Drive 1465 Cambridge, MA 02140 1466 e-mail: d@mazunetworks.com 1468 Jayakumar Jayakumar, 1469 Cisco Systems Inc. 1470 225, E.Tasman, MS-SJ3/3, 1471 San Jose, CA, 95134 1472 e-mail: jjayakum@cisco.com 1474 Alex Hamilton, 1475 Cisco Systems Inc. 1476 285 W. Tasman, MS-SJCI/3/4, 1477 San Jose, CA, 95134 1478 e-mail: tahamilt@cisco.com 1479 Steve Vogelsang 1480 Laurel Networks, Inc. 1481 Omega Corporate Center 1482 1300 Omega Drive 1483 Pittsburgh, PA 15205 1484 e-mail: sjv@laurelnetworks.com 1486 John Shirron 1487 Omega Corporate Center 1488 1300 Omega Drive 1489 Pittsburgh, PA 15205 1490 Laurel Networks, Inc. 1491 e-mail: jshirron@laurelnetworks.com 1493 Andrew G. Malis 1494 Tellabs 1495 90 Rio Robles Dr. 1496 San Jose, CA 95134 1497 e-mail: Andy.Malis@tellabs.com 1499 Vinai Sirkay 1500 Reliance Infocomm 1501 Dhirubai Ambani Knowledge City 1502 Navi Mumbai 400 709 1503 e-mail: vinai@sirkay.com 1505 Vasile Radoaca 1506 Nortel Networks 1507 600 Technology Park 1508 Billerica MA 01821 1509 e-mail: vasile@nortelnetworks.com 1511 Chris Liljenstolpe 1512 Cable & Wireless 1513 11700 Plaza America Drive 1514 Reston, VA 20190 1515 e-mail: chris@cw.net 1516 Dave Cooper 1517 Global Crossing 1518 960 Hamlin Court 1519 Sunnyvale, CA 94089 1520 e-mail: dcooper@gblx.net 1522 Kireeti Kompella 1523 Juniper Networks 1524 1194 N. Mathilda Ave 1525 Sunnyvale, CA 94089 1526 e-mail: kireeti@juniper.net 1528 13. Intellectual Property Statement 1530 The IETF takes no position regarding the validity or scope of any 1531 Intellectual Property Rights or other rights that might be claimed to 1532 pertain to the implementation or use of the technology described in 1533 this document or the extent to which any license under such rights 1534 might or might not be available; nor does it represent that it has 1535 made any independent effort to identify any such rights. Information 1536 on the procedures with respect to rights in RFC documents can be 1537 found in BCP 78 and BCP 79. 1539 Copies of IPR disclosures made to the IETF Secretariat and any 1540 assurances of licenses to be made available, or the result of an 1541 attempt made to obtain a general license or permission for the use of 1542 such proprietary rights by implementers or users of this 1543 specification can be obtained from the IETF on-line IPR repository at 1544 http://www.ietf.org/ipr. 1546 The IETF invites any interested party to bring to its attention any 1547 copyrights, patents or patent applications, or other proprietary 1548 rights that may cover technology that may be required to implement 1549 this standard. Please address the information to the IETF at ietf- 1550 ipr@ietf.org. 1552 14. Full Copyright Statement 1554 Copyright (C) The Internet Society (2004). This document is subject 1555 to the rights, licenses and restrictions contained in BCP 78 and 1556 except as set forth therein, the authors retain all their rights. 1558 This document and the information contained herein are provided on an 1559 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1560 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1561 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1562 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1563 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1564 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1566 15. Appendix A - C-bit Handling Procedures Diagram 1568 ------------------ 1569 Y | Received Label | N 1570 -------| Mapping Msg? |-------------- 1571 | ------------------ | 1572 -------------- | 1573 | | | 1574 ------- ------- | 1575 | C=0 | | C=1 | | 1576 ------- ------- | 1577 | | | 1578 | ---------------- | 1579 | | Control Word | N | 1580 | | Capable? |----------- | 1581 | ---------------- | | 1582 | Y | | | 1583 | | | | 1584 | ---------------- | | 1585 | | Control Word | N | | 1586 | | Preferred? |---- | | 1587 | ---------------- | | | 1588 | Y | | | | 1589 | | | | ---------------- 1590 | | | | | Control Word | 1591 | | | | | Preferred? | 1592 | | | | ---------------- 1593 | | | | N | Y | 1594 | | | | | | 1595 Send Send Send Send Send Send 1596 C=0 C=1 C=0 C=0 C=0 C=1 1597 | | | | 1598 ---------------------------------- 1599 | If receive the same as sent, | 1600 | PW setup is complete. If not: | 1601 ---------------------------------- 1602 | | | | 1603 ------------------- ----------- 1604 | Receive | | Receive | 1605 | C=1 | | C=0 | 1606 ------------------- ----------- 1607 | | 1608 Wait for the Send 1609 next message Wrong C-Bit 1610 | 1611 Send Label 1612 Mapping Message 1614 16. Appendix B - Notification Message of PW Status Diagram 1616 0 1 2 3 1617 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 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1619 |0| Notification (0x0001) | Message Length | 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 | Message ID | 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 |0|1| Status (0x0300) | Length | 1624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 |0|1| Status Code=0x00000028 | 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 | Message ID=0 | 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 | Message Type=0 | PW Status TLV | 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 | PW Status TLV | 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 | PW Status TLV | PWId FEC | 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | | 1636 | | 1637 | PWId FEC or Generalized ID FEC | 1638 | | 1639 | | 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+