idnits 2.17.1 draft-ietf-pwe3-atm-encap-11.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 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1505. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1512. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1518. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** 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. 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 158: '... preserved using the OPTIONAL sequence...' RFC 2119 keyword, line 281: '...he ECMP path, it MUST employ a mechani...' RFC 2119 keyword, line 297: '...he control word is not REQUIRED by the...' RFC 2119 keyword, line 300: '...and is therefore OPTIONAL. Early ATM P...' RFC 2119 keyword, line 303: '... implementations MUST be able to send ...' (98 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (May 2006) is 6549 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: 'RFC4029' is mentioned on line 238, but not defined == Missing Reference: 'RFC2914' is mentioned on line 1435, but not defined == Unused Reference: 'RFC4026' is defined on line 1554, but no explicit reference was found in the text == Unused Reference: 'RFC3270' is defined on line 1564, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-vccv-07 Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini 3 Internet Draft Jayakumar Jayakumar 4 Expiration Date: November 2006 Cisco Systems, Inc. 6 Nasser El-Aawar Jeremy Brayley 7 Level 3 Communications, LLC. ECI Telecom Inc. 9 Matthew Bocci Ghassem Koleyni 10 Alcatel Nortel Networks. 12 May 2006 14 Encapsulation Methods for Transport of ATM Over MPLS Networks 16 draft-ietf-pwe3-atm-encap-11.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 An ATM Pseudowire (PW) is used to carry ATM cells over an MPLS 43 network. This enables service providers to offer "emulated" ATM 44 services over existing MPLS networks. This document specifies methods 45 for the encapsulation of ATM cells within a pseudowire. It also 46 specifies the procedures for using a PW to provide a ATM service. 48 Table of Contents 50 1 Specification of Requirements .......................... 3 51 2 Introduction ........................................... 3 52 3 Applicability Statement ................................ 4 53 4 Terminology ............................................ 5 54 5 General encapsulation method ........................... 6 55 5.1 The Control Word ....................................... 7 56 5.1.1 The Generic Control Word ............................... 8 57 5.1.2 The Preferred Control Word ............................. 9 58 5.1.3 Setting the sequence number field in the control word .. 10 59 5.2 MTU Requirements ....................................... 10 60 5.3 MPLS Shim S Bit Value .................................. 10 61 5.4 MPLS Shim TTL Values ................................... 11 62 6 Encapsulation Mode Applicability ....................... 11 63 6.1 ATM N to 1 Cell Mode ................................... 12 64 6.2 ATM One-to-One Cell Encapsulation ...................... 13 65 6.3 AAL5 SDU Frame Encapsulation ........................... 13 66 6.4 AAL5 PDU Frame Encapsulation ........................... 14 67 7 ATM OAM Cell Support ................................... 15 68 7.1 VCC Case ............................................... 15 69 7.2 VPC Case ............................................... 16 70 7.3 SDU/PDU OAM Cell Emulation Mode ........................ 16 71 7.4 Defect Handling ........................................ 17 72 8 ATM N-to-one Cell Mode ................................. 18 73 8.1 ATM N-to-one Service Encapsulation ..................... 18 74 9 ATM One-to-one Cell Mode ............................... 21 75 9.1 ATM One-to-one Service Encapsulation ................... 21 76 9.2 Sequence Number ........................................ 22 77 9.3 ATM VCC Cell Transport Service ......................... 22 78 9.4 ATM VPC Services ....................................... 24 79 9.4.1 ATM VPC Cell Transport Services ........................ 24 80 10 ATM AAL5 CPCS-SDU Mode ................................. 26 81 10.1 Transparent AAL5 SDU Frame Encapsulation ............... 27 82 11 AAL5 PDU frame mode .................................... 28 83 11.1 Transparent AAL5 PDU Frame Encapsulation ............... 28 84 11.2 Fragmentation .......................................... 30 85 11.2.1 Procedures in the ATM-to-PSN Direction ................. 30 86 11.2.2 Procedures in the PSN-to-ATM Direction ................. 31 87 12 Mapping of ATM and PSN Classes of Service .............. 31 88 13 ILMI Support ........................................... 32 89 14 ATM Specific Interface Parameter Sub-TLVs .............. 32 90 15 Congestion Control ..................................... 32 91 16 IANA Considerations .................................... 33 92 17 Security Considerations ................................ 33 93 18 Full Copyright Statement ............................... 34 94 19 Intellectual Property Statement ........................ 34 95 20 Normative References ................................... 35 96 21 Informative References ................................. 35 97 22 Significant Contributors ............................... 36 98 23 Author Information ..................................... 39 100 1. Specification of Requirements 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 106 2. Introduction 108 Packet Switched Networks (PSNs) have the potential to reduce the 109 complexity of a service providers infrastructure by allowing 110 virtually any existing digital service to be supported over a single 111 networking infrastructure. The benefit of this model to a service 112 provider is threefold: 113 -i. Leveraging of the existing systems and services to provide 114 increased capacity from a packet switched core. 115 -ii. Preserving existing network operational processes and 116 procedures used to maintain the legacy services. 117 -iii. Using the common packet switched network infrastructure to 118 support both the core capacity requirements of existing 119 services and the requirements of new services supported 120 natively over the packet switched network. 122 This document describes a method to carry ATM services over MPLS. It 123 lists ATM specific requirements and provides encapsulation formats 124 and semantics for connecting ATM edge networks through a packet 125 switched network using MPLS. 127 Figure 1, below displays the ATM services reference model. This model 128 is adapted from [RFC3985]. 130 |<----- Pseudowire ----->| 131 | | 132 | |<-- PSN Tunnel -->| | 133 ATM Service V V V V ATM Service 134 | +----+ +----+ | 135 +----+ | | PE1|==================| PE2| | +----+ 136 | |----------|............PW1.............|----------| | 137 | CE1| | | | | | | |CE2 | 138 | |----------|............PW2.............|----------| | 139 +----+ | | |==================| | | +----+ 140 ^ +----+ +----+ | ^ 141 | Provider Edge 1 Provider Edge 2 | 142 | | 143 |<-------------- Emulated Service ---------------->| 144 Customer Customer 145 Edge 1 Edge 2 147 Figure 1: ATM Service Reference Model 149 3. Applicability Statement 151 The ATM over PW service is not intended to perfectly emulate a 152 traditional ATM service, but it can be used for applications that 153 need an ATM transport service. 155 The following are notable differences between traditional ATM 156 service, and the protocol described in this document: 158 - ATM cell ordering can be preserved using the OPTIONAL sequence 159 field in the control word, however implementations are not 160 required to support this feature. The use of this feature may 161 impact other ATM quality of service (QoS) commitments. 163 - The QoS model for traditional ATM can be emulated. However the 164 detailed specification of ATM QoS emulation is outside the scope 165 of this document. The emulation must be able to provide the 166 required ATM QoS commitments for the end user application. 168 - The ATM flow control mechanisms are transparent to the MPLS 169 network, and cannot reflect the status of the MPLS network. 171 - Control plane support for ATM SVCs SVPs, SPVCs and SPVPs is 172 outside the scope of this document. 174 4. Terminology 176 One-to-one mode: The One-to-one mode specifies an encapsulation 177 method which maps one ATM Virtual Channel Connection ( VCC ) (or one 178 ATM Virtual Path Connection (VPC) ) to one pseudowire. 180 N-to-one mode (N >= 1): The N-to-one mode specifies an encapsulation 181 method which maps one or more ATM VCCs (or one or more ATM VPCs) to 182 one pseudowire. 184 Packet Switched Network - A Packet Switched Network (PSN) is an IP or 185 MPLS network. 187 Pseudowire Emulation Edge to Edge - pseudowire Emulation Edge to Edge 188 (PWE3) is a mechanism that emulates the essential attributes of a 189 service (such as a T1 leased line or Frame Relay) over a PSN. 191 Customer Edge - A Customer Edge (CE) is a device where one end of a 192 service originates and/or terminates. The CE is not aware that it is 193 using an emulated service rather than a native service. 195 Provider Edge - A Provider Edge (PE) is a device that provides PWE3 196 to a CE. 198 Pseudowire - A pseudowire (PW) is a connection between two PEs 199 carried over a PSN. The PE provides the adaptation between the CE and 200 the PW. 202 Pseudowire PDU - A pseudowire PDU is a PDU sent on the PW that 203 contains all of the data and control information necessary to provide 204 the desired service. 206 PSN Tunnel - A PSN Tunnel is a tunnel inside which multiple PWs can 207 be nested so that they are transparent to core PSN devices. 209 PSN Bound - The traffic direction where information from a CE is 210 adapted to a PW, and PW-PDUs are sent into the PSN. 212 CE Bound - The traffic direction where PW-PDUs are received on a PW 213 from the PSN, re-converted back in the emulated service, and sent out 214 to a CE. 216 Ingress - The point where the ATM service is encapsulated into a 217 pseudowire PDU (ATM to PSN direction.) 219 Egress - The point where the ATM service is decapsulated from a 220 pseudowire PDU (PSN to ATM direction.) 221 CTD - Cell Transfer Delay 223 MTU - Maximum Transmission Unit 225 OAM - Operations And Maintenance. 227 PVC - Permanent Virtual Connection. An ATM connection that is 228 provisioned via a network management interface. The connection is 229 not signaled. 231 VCC - Virtual Circuit Connection. An ATM connection that is switched 232 based on the cell header's VCI. 234 VPC - Virtual Path Connection. An ATM connection that is switched 235 based on the cell header's VPI. 237 Additional terminology relevant to pseudowires and Layer 2 Virtual 238 Private Networking (L2VPN) in general may be found in [RFC4029]. 240 5. General encapsulation method 242 This section describes the general encapsulation format for ATM over 243 PSN pseudowires. 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | PSN Transport Header (As Required) | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Pseudowire Header | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | ATM Control Word | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | ATM Service Payload | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 2: General format for ATM encapsulation over PSNs 259 The PSN Transport Header depends on the particular tunneling 260 technology in use. This header is used to transport the encapsulated 261 ATM information through the packet switched core. 263 The Pseudowire Header identifies a particular ATM service on a 264 tunnel. In case of MPLS, the pseudowire header is one or more MPLS 265 labels at the bottom of the MPLS label stack. 267 The ATM Control Word is inserted before the ATM service payload. It 268 may contain a length and sequence number in addition to certain 269 control bits needed to carry the service. 271 5.1. The Control Word 273 The Control Words defined in this section are based on the Generic PW 274 MPLS Control Word as defined in [RFC4385]. They provide the ability 275 to sequence individual frames on the PW, avoidance of equal-cost 276 multiple-path load-balancing (ECMP) [RFC2992], and OAM mechanisms 277 including VCCV [VCCV]. 279 [RFC4385] states, "If a PW is sensitive to packet misordering and is 280 being carried over an MPLS PSN that uses the contents of the MPLS 281 payload to select the ECMP path, it MUST employ a mechanism which 282 prevents packet misordering." This is necessary due to the fact that 283 ECMP implementations may examine the first nibble after the MPLS 284 label stack to determine whether the labelled packet is IP or not. 285 Thus, if the VPI of an ATM connection carried over the PW using N- 286 to-one cell mode encapsulation without a control word present begins 287 with 0x4 or 0x6, it could be mistaken for an IPv4 or IPv6 packet. 288 This could, depending on the configuration and topology of the MPLS 289 network, lead to a situation where all packets for a given PW do not 290 follow the same path. This may increase out-of-order frames on a 291 given PW, or cause OAM packets to follow a different path than actual 292 traffic (see section 4.4.3 on Frame Ordering). 294 The features that the control word provides may not be needed for a 295 given ATM PW. For example, ECMP may not be present or active on a 296 given MPLS network, strict frame sequencing may not be required, etc. 297 If this is the case, and the control word is not REQUIRED by the 298 encapsulation mode for other functions such as length or the 299 transport of ATM protocol specific information, the control word 300 provides little value and is therefore OPTIONAL. Early ATM PW 301 implementations have been deployed that do not include a control word 302 or the ability to process one if present. To aid in backwards 303 compatibility, future implementations MUST be able to send and 304 receive frames without the control word present. 306 In all cases the egress PE MUST be aware of whether the ingress PE 307 will send a control word over a specific PW. This may be achieved by 308 configuration of the PEs, or by signaling, as defined in [RFC4447]. 310 If the pseudowire traverses a network link that requires a minimum 311 frame size such as Ethernet as a practical example, with a minimum 312 frame size of 64 octets, then such links will apply padding to the 313 pseudowire PDU to reach its minimum frame size. In this case the 314 control word must include a length field set to the PDU length. A 315 mechanism is required for the egress PE to detect and remove such 316 padding. 318 5.1.1. The Generic Control Word 320 This control word is used in the following encapsulation modes: 322 - ATM 1 to 1 Cell Mode 323 - AAL5 PDU Frame Mode 325 The PWE3 control word document [RFC4385] provides the following 326 structure for the generic control word: 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 |0 0 0 0| Specified by PW Encapsulation | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 The detailed structure for the ATM 1 to 1 Cell Mode and for the AAL5 335 PDU Frame Mode is as follows: 337 0 1 2 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 |0 0 0 0| Resvd | Sequence Number | ATM Specific | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 In the above diagram the first 4 bits MUST be set to 0 to indicate PW 344 data. They MUST be ignored by the receiving PE. 346 The next four bits are reserved and MUST be set to 0 upon 347 transmission and ignored upon reception. 349 The next 16 bits provide a sequence number that can be used to 350 guarantee ordered packet delivery. The processing of the sequence 351 number field is OPTIONAL. 353 The sequence number space is a 16 bit, unsigned circular space. The 354 sequence number value 0 is used to indicate that the sequence number 355 check alghorithm is not used. 357 The last 8 bits provide space for carrying ATM specific flags. These 358 are defined in the protocol-specific details below. 360 There is no requirement for a length field for the One-to-one cell 361 and PDU Frame modes because the PSN PDU is always greater than 64 362 bytes and so no padding is applied in Ethernet links in the PSN. 364 5.1.2. The Preferred Control Word 366 This control word is used in the following encapsulation modes: 367 - ATM N to 1 Cell Mode 368 - AAL5 SDU Frame Mode 370 It is defined as follows: 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 |0 0 0 0| Flags |Res| Length | Sequence Number | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 In the above diagram the first 4 bits MUST be set to 0 to indicate PW 378 data. They MUST be ignored by the receiving PE. 380 The next 4 bits provide space for carrying protocol specific flags. 381 These are defined in the protocol-specific details below. 383 The next 6 bits provide a length field, which is used as follows: If 384 the packet's length (defined as the length of the layer 2 payload 385 plus the length of the control word) is less than 64 bytes, the 386 length field MUST be set to the packet's length. Otherwise the length 387 field MUST be set to zero. The value of the length field, if non- 388 zero, can be used to remove any padding. When the packet reaches the 389 service provider's egress router, it may be desirable to remove the 390 padding before forwarding the packet. Note that the length field is 391 not used in the N-to-1 mode, and MUST be set to 0. 393 The last 16 bits provide a sequence number that can be used to 394 guarantee ordered packet delivery. The processing of the sequence 395 number field is OPTIONAL. 397 The sequence number space is a 16 bit, unsigned circular space. The 398 sequence number value 0 is used to indicate that the sequence number 399 check alghorithm is not used. 401 5.1.3. Setting the sequence number field in the control word 403 This section applies to the sequence number field of both the Generic 404 and Preferred Control Words. 406 For a given emulated VC, and a pair of routers PE1 and PE2, if PE1 407 supports packet sequencing then the sequencing procedures defined in 408 [RFC4385] MUST 409 be used. 411 Packets which are received out of order MAY be dropped or reordered 412 at the discretion of the receiver. 414 A simple extension of the processing algorithm in [RFC4385] MAY be 415 used to detect lost packets. 417 If a PE router negotiated not to use receive sequence number 418 processing, and it received a non zero sequence number, then it 419 SHOULD send a PW status message indicating a receive fault, and 420 disable the PW. 422 5.2. MTU Requirements 424 The network MUST be configured with an MTU that is sufficient to 425 transport the largest encapsulation frames. If MPLS is used as the 426 tunneling protocol, for example, this is likely to be 12 or more 427 bytes greater than the largest frame size. Other tunneling protocols 428 may have longer headers and require larger MTUs. If the ingress 429 router determines that an encapsulated layer 2 PDU exceeds the MTU of 430 the tunnel through which it must be sent, the PDU MUST be dropped. If 431 an egress router receives an encapsulated layer 2 PDU whose payload 432 length (i.e., the length of the PDU itself without any of the 433 encapsulation headers), exceeds the MTU of the destination layer 2 434 interface, the PDU MUST be dropped. 436 5.3. MPLS Shim S Bit Value 438 The ingress LSR, PE1, MUST set the S bit of the PW label to a value 439 of 1 to denote that the VC label is at the bottom of the stack. For 440 more information on setting the S Bit see RFC3032 [RFC3032]. 442 5.4. MPLS Shim TTL Values 444 The setting of the TTL value in the PW label is application 445 dependent, 447 6. Encapsulation Mode Applicability 449 This Document defines two methods for encapsulation of ATM cells, 450 namely, One-to-one mode and N-to-one mode. 452 The N-to-one mode (N >= 1) specifies an encapsulation method that 453 maps one or more ATM VCCs (or one or more ATM VPCs) to one 454 pseudowire. This is the only REQUIRED mode. One format is used for 455 both the VCC or VPC mapping to the tunnel. The 4-octet ATM header is 456 unaltered in the encapsulation, thus the VPI/VCI is always present. 457 Cells from one or more VCCs (or one or more VPCs) may be 458 concatenated. 460 The One-to-one mode specifies an encapsulation method that maps one 461 ATM VCC or one ATM VPC to one pseudowire. For VCCs, the VPI/VCI is 462 not included. For VPCs, the VPI is not included. Cells from one VCC 463 or one VPC may be concatenated. This mode is OPTIONAL. 465 Furthermore different OPTIONAL encapsulations are supported for ATM 466 AAL5 transport: one for ATM AAL5 SDUs, and another for ATM AAL5 PDUs. 468 Three deployment models are supported by the encapsulations described 469 in this document: 470 -i. Single ATM Connection: A PW carries the cells of only one 471 ATM VCC or VPC. This supports both the transport of 472 multiservice ATM and L2VPN service over a PSN for all AAL 473 types. 474 -ii. Multiple ATM Connections: A PW carries the cells of multiple 475 ATM VCCs and / or VPCs . This also supports both the 476 transport of multiservice ATM and L2VPN service over a PSN 477 for all AAL type. 478 -iii. AAL5: PW carries the AAL5 frames of only one ATM VCC. A 479 large proportion of the data carried on ATM networks is 480 frame based and therefore uses AAL5. The AAL5 mapping takes 481 advantage of the delineation of higher layer frames in the 482 ATM layer to provide increased bandwidth efficiency compared 483 with the basic cell mapping. The nature of the service, as 484 defined by the ATM service category [TM4.0] or the ATM 485 transfer capability [I.371] should be preserved. 487 6.1. ATM N to 1 Cell Mode 489 This encapsulation supports both the Single and Multiple ATM 490 Connection deployment models. This encapsulation is REQUIRED. 492 The encapsulation allows multiple VCCs/VPCs to be carried within a 493 single pseudowire. However, a service provider may wish to provision 494 a single VCC to a pseudowire in order to satisfy QoS or restoration 495 requirements. 497 The encapsulation also supports the binding of multiple VCCs/VPCs to 498 a single pseudowire. This capability is useful in order to make more 499 efficient use of the PW demultiplexing header space as well as to 500 ease provisioning of the VCC/VPC services. 502 In the simplest case, this encapsulation can be used to transmit a 503 single ATM cell per PSN PDU. However, in order to provide better PSN 504 bandwidth efficiency, several ATM cells may optionally be 505 encapsulated in a single PSN PDU. This process is called cell 506 concatenation. 508 The encapsulation has the following attributes: 509 -i. Supports all ATM Adaptation Layers Types. 510 -ii. Non-terminating OAM/Admin cells are transported among the 511 user cells in the same order as they are received. This 512 requirement enables the use of various performance 513 management and security applications. 514 -iii. In order to gain transport efficiency on the PSN, multiple 515 cells may be encapsulated in a single PW PDU. This process 516 is called cell concatenation. How many cells to insert or 517 how long to wait for cell arrival before sending a PW PDU is 518 an implementation decision. Cell concatenation adds latency 519 and delay variation to a cell relay service. 520 -iv. The CLP bit from each cell may be mapped to a corresponding 521 marking on the PW PDU. This allows the drop precedence to be 522 preserved across the PSN. 523 -v. If the Single ATM connection deployment model is used, then 524 it is simpler to provide an ATM layer service. The nature of 525 the service, as defined by the ATM service category [TM4.0] 526 or ATM transfer capability [I.371], should be preserved. 528 The limitations of the ATM N-to-one cell encapsulation are: 529 -vi. There is no currently defined method to translate the 530 forward congestion indication (EFCI) to a corresponding 531 function in the PSN. Nor is there a way to translate PSN 532 congestion to the EFCI upon transmission by the egress PE. 534 -vii. The ATM cell header checksum can detect a 2-bit error or 535 detect and correct a single bit error in the cell header. 536 Analogous functionality does not exist in most PSNs. A 537 single bit error in a PW PDU will most likely cause the 538 packet to be dropped due to a L2 FCS failure. 539 -viii. Cells can be concatenated from multiple VCCs or VPCs 540 belonging to different service cathegories and QoS 541 requirements. In this case the PSN packet must receive 542 treatment by the PSN to support the highest QoS of the ATM 543 VCCs/VPCs carried. 544 -ix. Cell encapsulation only supports point-to-point LSPs. 545 Multipoint-to-point and point-to-multi-point are for further 546 study (FFS). 547 -x. The number of concatenated ATM cells is limited by the MTU 548 size and the cell transfer delay (CTD) and cell delay 549 variation (CDV) objectives of multiple ATM connections that 550 are multiplexed into a single PW. 552 6.2. ATM One-to-One Cell Encapsulation 554 This OPTIONAL encapsulation supports the Single ATM Connection 555 deployment model. 557 Like the N-to-one cell encapsulation mode, the One-to-one mode 558 supports cell concatenation. The advantage of this encapsulation is 559 that it utilizes less bandwidth that the N-to-one encapsulation, for 560 a given number of concatenated cells. Since only one ATM VCC or VPC 561 is carried on a PW, the VCI and/or VPI of the ATM VCC or VPC can be 562 derived from the context of the PW using the PW label. These fields 563 therefore do not need to be encapsulated for a VCC, and only the VCI 564 needs to be encapsulated for a VPC. This encapsulation thus allows 565 service providers to achieve a higher bandwidth efficiency on PSN 566 links than the N-to-one encapsulation for a given number of 567 concatenated cells. 569 The limitations vi,vii,ix,x of N-to-one mode apply. 571 6.3. AAL5 SDU Frame Encapsulation 573 This OPTIONAL encapsulation supports the AAL5 model. This mode allows 574 the transport of ATM AAL5 CSPS-SDUs traveling on a particular ATM PVC 575 across the network to another ATM PVC. This encapsulation is used by 576 a PW of type 0x0002 "ATM AAL5 SDU VCC transport" as allocated in 577 [RFC4446]. 579 The AAL5 SDU encapsulation is more efficient for small AAL5 SDUs than 580 the VCC cell encapsulations. In turn it presents a more efficient 581 alternative to the cell relay service when carrying RFC 2684 582 encapsulated IP PDUs across a PSN. 584 The AAL5-SDU encapsulation requires Segmentation and Reassembly on 585 the PE-CE ATM interface. This SAR function is provided by common 586 off-the-shelf hardware components. Once reassembled, the AAL5-SDU is 587 carried via a pseudowire to the egress PE. Herein lies another 588 advantage of the AAL5-SDU encapsulation. 590 The limitations of the AAL5 SDU encapsulation are: 591 -i. If an ATM OAM cell is received at the ingress PE, it is sent 592 before the cells of the surrounding AAL5 frame. Therefore, 593 OAM cell reordering may occur, which may cause certain ATM 594 OAM performance monitoring and ATM security applications to 595 operate incorrectly. 596 -ii. If the ALL5 PDU is scrambled using ATM security standards, a 597 PE will not be able to exctract the ALL5 SDU and therefore 598 the whole PDU will be dropped. 599 -iii. The AAL5 PDU CRC is not transported across the PSN. The CRC 600 must therefore be regenerated at the egress PE. Since the 601 CRC has end-to-end significance in ATM security. This means 602 that the AAL5 CRC may not be used to accurately check for 603 errors on the end-to-end ATM VCC. 604 -iv. The Length of AAL5 frame may exceed the MTU of the PSN. This 605 requires fragmentation, which may not be available to all 606 nodes at the PW endpoint. 607 -v. This mode does not preserve the value of the CLP bit for 608 every ATM cell within an AAL5 PDU. Therefore, transparency 609 of the CLP setting may be violated. Additionally, tagging of 610 some cells may occur when tagging is not allowed by the 611 conformance definition [TM4.0]. 612 -vi. This mode does not preserve the EFCI state for every ATM 613 cell within an AAL5 PDU. Therefore, transparency of the EFCI 614 state may be violated. 616 6.4. AAL5 PDU Frame Encapsulation 618 This OPTIONAL encapsulation supports the AAL5 model. 620 The primary application supported by AAL5 PDU frame encapsulation 621 over PSN is the transparent carriage of ATM layer services that use 622 AAL5 to carry higher layer frames. The main advantage of this AAL5 623 mode is that it is transparent to ATM OAM and ATM security 624 applications. 626 One important consideration is to allow OAM information to be treated 627 as in the original network. This encapsulation mode allows this 628 transparency while performing AAL5 frame encapsulation. This mode 629 supports fragmentation, which may be performed in order to maintain 630 the position of the OAM cells with respect to the user cells. 632 Fragmentation may also be performed to maintain the size of the 633 packet carrying the AAL5 PDU within the MTU of the link. 634 Fragmentation provides a means for the PE to set the size of the PW 635 packet to a different value than that of the original AAL5 PDU. This 636 means that the PE has control on the delay and jitter provided to the 637 ATM cells. 639 The whole AAL5-PDU is encapsulated. In this case all necessary 640 parameters such as CPCS-UU (CPCS User-to-User indicator), CPI (Common 641 Part Indicator), Length (Length of the CPCS-SDU) and CRC (Cyclic 642 Redundancy Check) are transported as part of the payload. Note that 643 carrying of the full PDU also allows the simplification of the 644 fragmentation operation since it is performed at cell boundaries and 645 the CRC in the trailer of the AAL5 PDU can be used to check the 646 integrity of the PDU. 648 Reassembly is not required at the egress PE for the PSN-to-ATM 649 direction. 651 The limitations v and vi of the AAL5 SDU mode apply to this mode as 652 well. 654 7. ATM OAM Cell Support 656 7.1. VCC Case 658 In general when configured for ATM VCC service, both PEs SHOULD act 659 as a VC switch, in accordance with the OAM procedures defined in 660 [I.610]. 662 The PEs SHOULD be able to pass the following OAM cells transparently: 663 - F5 AIS (segment and end-to-end) 664 - F5 RDI (segment and end-to-end) 665 - F5 loopback (segment and end-to-end) 666 - Resource Management 667 - Performance Management 668 - Continuity Check 669 - Security 671 F4 OAM cells are inserted or extracted at the VP link termination. 672 These OAM cells are not seen at the VC link termination and are 673 therefore not sent across the PSN. 675 When the PE is operating in AAL5 CPCS-SDU transport mode if it does 676 not support transport of ATM cells, the PE MUST discard incoming MPLS 677 frames on an ATM PW that contain a PW label with the T bit set. 679 7.2. VPC Case 681 When configured for a VPC cell relay service, both PEs SHOULD act as 682 a VP cross-connect in accordance with the OAM procedures defined in 683 [I.610]. 685 The PEs SHOULD be able to process and pass the following OAM cells 686 transparently according to [I.610]: 687 - F4 AIS (segment and end-to-end) 688 - F4 RDI (segment and end-to-end) 689 - F4 loopback (segment and end-to-end) 691 F5 OAM are not inserted or extracted here. The PEs MUST be able to 692 pass the following OAM cells transparently: F5 AIS (segment and 693 end-to-end) 694 - F5 RDI (segment and end-to-end) 695 - F5 loopback (segment and end-to-end) 696 - Resource Management 697 - Performance Management 698 - Continuity Check 699 - Security 701 The OAM cell MAY be encapsulated together with other user data cells 702 if multiple cell encapsulation is used. 704 7.3. SDU/PDU OAM Cell Emulation Mode 706 A PE operating in ATM SDU, or PDU transport mode, that does not 707 support transport of OAM cells across a PW MAY provide OAM support on 708 ATM PVCs using the following procedures: 710 - Loopback cells response 712 If an F5 end-to-end OAM cell is received from a ATM VC, by either 713 PE that is transporting this ATM VC, with a loopback indication 714 value of 1, and the PE has a label mapping for the ATM VC, then 715 the PE MUST decrement the loopback indication value and loop back 716 the cell on the ATM VC. Otherwise the loopback cell MUST be 717 discarded by the PE. 719 - AIS Alarm. 721 If an ingress PE, PE1, receives an AIS F4/F5 OAM cell, it MUST 722 notify the remote PE of the failure. The remote PE , PE2, MUST in 723 turn send F5 OAM AIS cells on the respective PVCs. Note that if 724 the PE supports forwarding of OAM cells, then the received OAM 725 AIS alarm cells MUST be forwarded along the PW as well. 727 - Interface failure. 729 If the PE detects a physical interface failure, or the interface 730 is administratively disabled, the PE MUST notify the remote PE 731 for all VCs associated with the failure. 733 - PSN/PW failure detection. 735 If the PE detects a failure in the PW, by receiving a label 736 withdraw for a specific PW ID, or the targeted LDP session fails, 737 or a PW status TLV notification is received, then a proper AIS F5 738 OAM cell MUST be generated for all the affected atm PVCs. The AIS 739 OAM alarm will be generated on the ATM output port of the PE that 740 detected the failure. 742 7.4. Defect Handling 744 Figure 3 illustrates four possible locations for defects on the PWE3 745 service: 746 - (a) On the ATM connection from CE to PE 747 - (b) On the ATM side of the PW 748 - (c) On the PSN side of the PE 749 - (d) In the PSN 751 +----+ +----+ 752 +----+ | PE1|==================| PE2| +----+ 753 | |---a------|b..c........PW1...d.........|----------| | 754 | CE1| | | | | |CE2 | 755 | |----------|............PW2.............|----------| | 756 +----+ | |==================| | +----+ 757 ^ +----+ +----+ ^ 758 | Provider Edge 1 Provider Edge 2 | 759 | | 760 |<-------------- Emulated Service ---------------->| 761 Customer Customer 762 Edge 1 Edge 2 763 Figure 3: Defect Locations 765 For failures at (a) or (b) in the VPC case the ingress PE MUST be 766 able to generate an F4 AIS upon reception of a lower layer defect 767 (such as LOS). In the VCC case, the ingress PE SHOULD be able to 768 generate an F5 AIS upon reception of a corresponding F4 AIS or lower 769 layer defect (such as LOS). These messages are sent across the PSN. 771 For failures at (c) or (d), in the VCC case the egress PE SHOULD be 772 able to generate an F5 AIS based on a PSN failure (such as a PSN 773 tunnel failure or LOS on the PSN port). In the VPC case, the egress 774 PE SHOULD be able to generate an F4 AIS based on a PSN failure (such 775 as a PSN tunnel failure or LOS on the PSN port). 777 If the ingress PE cannot support the generation of OAM cells, it MAY 778 notify the egress PE using a pseudowire specific maintenance 779 mechanism such as the PW status message defined in [RFC4447]. 780 Alternatively, for example, the ingress PE MAY withdraw the 781 pseudowire (PW label) label associated with the service. Upon 782 receiving such a notification, the egress PE SHOULD generate the 783 appropriate F4 AIS (for VPC) or F5 AIS (for VCC). 785 If the PW in one direction fails, then the complete bidirectional 786 service is considered to have failed. 788 8. ATM N-to-one Cell Mode 790 The N-to-one mode (N >= 1) described in this document allows a 791 service provider to offer an ATM PVC or SVC based service across a 792 network. The encapsulation allows multiple ATM VCCs or VPCs to be 793 carried within a single PSN tunnel. A service provider may also use 794 N-to-one mode to provision either one VCC or one VPC on a tunnel. 795 This section defines the VCC and VPC cell relay services over a PSN 796 and their applicability. 798 8.1. ATM N-to-one Service Encapsulation 800 This section describes the general encapsulation format for ATM over 801 PSN pseudowires. 803 0 1 2 3 804 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 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | PSN Transport Header (As Required) | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | pseudowire Header | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 |0 0 0 0| Flags |Res| Length | Sequence Number | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | ATM Service Payload | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 Figure 4: General format for ATM encapsulation over PSNs 817 The PSN Transport Header depends on the particular tunneling 818 technology in use. This header is used to transport the encapsulated 819 ATM information through the packet switched core. 821 The Pseudowire Header identifies a particular ATM service on a 822 tunnel. Non-ATM services may also be carried on the PSN tunnel. 824 As shown above, in Figure 4, the ATM Control Word is inserted before 825 the ATM service payload. It may contain a length field and a sequence 826 number field in addition to certain control bits needed to carry the 827 service. 829 The ATM Service Payload is specific to the service being offered via 830 the pseudowire. It is defined in the following sections. 832 In this encapsulation mode ATM cells are transported individually. 833 The encapsulation of a single ATM cell is the only REQUIRED 834 encapsulation for ATM. The encapsulation of more than one ATM cell in 835 a PSN frame is OPTIONAL. 837 The ATM cell encapsulation consists of an OPTIONAL control word, and 838 one or more ATM cells - each consisting of a 4 byte ATM cell header 839 and the 48 byte ATM cell payload. This ATM cell header is defined as 840 in the FAST encapsulation [FBATM] section 3.1.1, but without the 841 trailer byte. The length of each frame, without the encapsulation 842 headers, is a multiple of 52 bytes long. The maximum number of ATM 843 cells that can be fitted in a frame, in this fashion, is limited only 844 by the network MTU and by the ability of the egress router to process 845 them. The ingress router MUST NOT send more cells than the egress 846 router is willing to receive. The number of cells that the egress 847 router is willing to receive may either be configured in the ingress 848 router or may be signaled, for example using the methods described 849 later in this document, and in [RFC4447]. The number of cells 850 encapsulated in a particular frame can be inferred by the frame 851 length. The control word is OPTIONAL. If the control word is used 852 then the flag, and length bits in the control word are not used, and 853 MUST be set to 0 when transmitting, and MUST be ignored upon receipt. 855 The EFCI and CLP bits are carried across the network in the ATM cell 856 header. The edge routers that implement this document MAY, when 857 either adding or removing the encapsulation described herein, change 858 the EFCI bit from zero to one in order to reflect congestion in the 859 network that is known to the edge router, and the CLP bit from zero 860 to one to reflect marking from edge policing of the ATM Sustained 861 Cell Rate. The EFCI and CLP bits SHOULD NOT be changed from one to 862 zero. 864 This diagram illustrates an encapsulation of two ATM cells: 866 0 1 2 3 867 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 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Control word ( Optional ) | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | VPI | VCI | PTI |C| 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | ATM Payload ( 48 bytes ) | 874 | " | 875 | " | 876 | " | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | VPI | VCI | PTI |C| 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | ATM Payload ( 48 bytes ) | 881 | " | 882 | " | 883 | " | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 Figure 5: Multiple Cell ATM Encapsulation 888 * When multiple VCCs or VPCs are transported in one pseudowire 889 VPI/VCI values MUST be unique. When the multiple VCCs or VPCs, 890 are from different a physical transmission path it may be 891 necessary to assign unique VPI/VCI values to the ATM connections. 892 If they are from the same physical transmission path, the VPI/VCI 893 values are unique. 895 * VPI 897 The ingress router MUST copy the VPI field from the incoming cell 898 into this field. For particular emulated VCs, the egress router 899 MAY generate a new VPI and ignore the VPI contained in this 900 field. 902 * VCI 904 The ingress router MUST copy the VCI field from the incoming ATM 905 cell header into this field. For particular emulated VCs, the 906 egress router MAY generate a new VCI. 908 * PTI & CLP ( C bit ) 910 The PTI and CLP fields are the PTI and CLP fields of the incoming 911 ATM cells. The cell headers of the cells within the packet are 912 the ATM headers (without Header Error Check (HEC) field) of the 913 incoming cell. 915 9. ATM One-to-one Cell Mode 917 The One-to-one mode described in this document allows a service 918 provider to offer an ATM PVC or SVC based service across a network. 919 The encapsulation allows one ATM VCC or VPC to be carried within a 920 single pseudowire. 922 9.1. ATM One-to-one Service Encapsulation 924 This section describes the general encapsulation format for ATM over 925 pseudowires on an MPLS PSN. Figure 6 provides a general format for 926 encapsulation of ATM cells into packets. 927 0 1 2 3 928 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 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | PSN Transport Header (As Required) | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | Pseudowire Header | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 |0 0 0 0| Resvd | Optional Sequence Number | ATM Specific | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | ATM Service Payload | 937 | | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 Figure 6: General format for One-to-one mode encapsulation over PSNs 942 The MPLS PSN Transport Header depends on how the MPLS network is 943 configured. The Pseudowire Header identifies a particular ATM 944 service within the PSN tunnel created by the PSN Transport Header. 946 This header is used to transport the encapsulated ATM information 947 through the packet switched core. 949 The generic control word is inserted after the Pseudowire Header. The 950 presence of the control word is REQUIRED. 952 The ATM Specific Header is inserted before the ATM service payload. 953 The ATM Specific Header contains control bits needed to carry the 954 service. These are defined in the ATM service descriptions below. The 955 length of ATM specific header may not always be one octet. It depends 956 on the service type. 958 The ATM payload octet group is the payload of the service that is 959 being encapsulated. 961 9.2. Sequence Number 963 The sequence number is not required for all services. 965 Treatment of the sequence number is according to previous sections 966 "Setting the sequence number", and "Processing the sequence number". 968 9.3. ATM VCC Cell Transport Service 970 The VCC cell transport service is characterized by the mapping of a 971 single ATM VCC (VPI/VCI) to a pseudowire. This service is fully 972 transparent to the ATM Adaptation Layer. The VCC single cell 973 transport service is OPTIONAL. This service MUST use the following 974 encapsulation format: 975 0 1 2 3 976 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 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | PSN Transport Header (As Required) | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Pseudowire Header | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 |0 0 0 0| Resvd | Optional Sequence Number |M|V|Res| PTI |C| 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | | 985 | ATM Cell Payload ( 48 bytes ) | 986 | | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 Figure 7: Single ATM VCC Cell Encapsulation 991 * M (transport mode) bit 993 Bit (M) of the control byte indicates whether the packet contains 994 an ATM cell or a frame payload. If set to 0, the packet contains 995 an ATM cell. If set to 1, the PDU contains an AAL5 payload. 997 * V (VCI present) bit 999 Bit (V) of the control byte indicates whether the VCI field is 1000 present in the packet. If set to 1, the VCI field is present for 1001 the cell. If set to 0, no VCI field is present. In the case of a 1002 VCC, the VCI field is not required. For VPC, the VCI field is 1003 required and is transmitted with each cell. 1004 * Reserved bits 1006 The reserved bits should be set to 0 at the transmitter and 1007 ignored upon reception. 1009 * PTI Bits 1011 The 3-bit Payload Type Identifier (PTI) incorporates ATM Layer 1012 PTI coding of the cell. These bits are set to the value of the 1013 PTI of the encapsulated ATM cell. 1015 * C (CLP) Bit 1017 The Cell Loss Priority (CLP) field indicates CLP value of the 1018 encapsulated cell. 1020 For increased transport efficiency, the ingress PE SHOULD be able to 1021 encapsulate multiple ATM cells into a pseudowire PDU. The ingress and 1022 egress PE MUST agree to a maximum number of cells in a single 1023 pseudowire PDU. This agreement may be accomplished via a pseudowire 1024 specific signaling mechanism or via static configuration. 1026 When multiple cells are encapsulated in the same PSN packet, the ATM 1027 specific byte MUST be repeated for each cell. This means that 49 1028 bytes are used to encapsulate each 53 byte ATM cell. 1030 0 1 2 3 1031 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 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | PSN Transport Header (As Required) | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | Pseudowire Header | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 |0 0 0 0| Resvd | Optional Sequence Number |M|V|Res| PTI |C| 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | | 1040 | ATM Cell Payload ( 48 bytes ) | 1041 | | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 |M|V|Res| PTI |C| | 1044 +-+-+-+-+-+-+-+-+ | 1045 | ATM Cell Payload ( 48 bytes ) | 1046 | | 1047 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | | 1049 +-+-+-+-+-+-+-+-+ 1051 Figure 8: Multiple ATM VCC Cell Encapsulation 1053 9.4. ATM VPC Services 1055 The VPC service is defined by mapping a single VPC (VPI) to a 1056 pseudowire. As such it emulates a Virtual Path cross-connect across 1057 the PSN. All VCCs belonging to the VPC are carried transparently by 1058 the VPC service. 1060 The egress PE may choose to apply a different VPI other than the one 1061 that arrived at the ingress PE. The egress PE MUST choose the 1062 outgoing VPI based solely upon the pseudowire header. As a VPC 1063 service, the egress PE MUST NOT change the VCI field. 1065 9.4.1. ATM VPC Cell Transport Services 1067 The ATM VPC cell transport service is OPTIONAL. 1069 This service MUST use the following cell mode encapsulation: 1071 0 1 2 3 1072 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 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | PSN Transport Header (As Required) | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | Pseudowire Header | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 |0 0 0 0| Resvd | Optional Sequence Number |M|V|Res| PTI |C| 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | VCI | | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1082 | | 1083 | ATM Cell Payload ( 48 bytes ) | 1084 | | 1085 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 Figure 9: Single Cell VPC Encapsulation 1091 The ATM control byte contains the same information as in the VCC 1092 encapsulation except for the VCI field. 1094 * VCI Bits 1096 The 16-bit Virtual Circuit Identifier (VCI) incorporates ATM 1097 Layer VCI value of the cell. 1099 For increased transport efficiency, the ingress PE SHOULD be able to 1100 encapsulate multiple ATM cells into a pseudowire PDU. The ingress and 1101 egress PE MUST agree to a maximum number of cells in a single 1102 pseudowire PDU. This agreement may be accomplished via a pseudowire 1103 specific signaling mechanism or via static configuration. 1105 If the Egress PE supports cell concatenation the ingress PE MUST only 1106 concatenate cells up to the "Maximum Number of concatenated ATM cells 1107 in a frame" interface parameter sub-TLV as received as part of the 1108 control protocol [RFC4447]. 1110 When multiple ATM cells are encapsulated in the same PSN packet, the 1111 ATM specific byte MUST be repeated for each cell. This means that 51 1112 bytes are used to encapsulate each 53 byte ATM cell. 1114 0 1 2 3 1115 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 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | PSN Transport Header (As Required) | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Pseudowire Header | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 |0 0 0 0| Resvd | Optional Sequence Number |M|V|Res| PTI |C| 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | VCI | | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1125 | | 1126 | ATM Cell Payload (48 bytes) | 1127 | | 1128 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | |M|V|Res| PTI |C| VCI | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | VCI | | 1132 +-+-+-+-+-+-+-+-+ | 1133 | ATM Cell Payload (48 bytes) | 1134 | | 1135 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | | 1137 +-+-+-+-+-+-+-+-+ 1139 Figure 10: Multiple Cell VPC Encapsulation 1141 10. ATM AAL5 CPCS-SDU Mode 1143 The AAL5 payload VCC service defines a mapping between the payload of 1144 an AAL5 VCC and a single pseudowire. The AAL5 payload VCC service 1145 requires ATM segmentation and reassembly support on the PE. 1147 The AAL5 payload CPCS-SDU service is OPTIONAL. 1149 Even the smallest TCP packet requires two ATM cells when sent over 1150 AAL5 on a native ATM device. It is desirable to avoid this padding on 1151 the pseudowire. Therefore, once the ingress PE reassembles the AAL5 1152 CPCS-PDU, the PE discards the PAD and CPCS-PDU trailer and then the 1153 ingress PE inserts the resulting payload into a pseudowire PDU. 1155 The egress PE MUST regenerate the PAD and trailer before transmitting 1156 the AAL5 frame on the egress ATM port. 1158 This service does allow the transport of OAM and RM cells, but does 1159 not attempt to maintain the relative order of these cells with 1160 respect to the cells that comprise the AAL5 CPCS-PDU. All OAM cells, 1161 regardless of their type, that arrive during the reassembly of a 1162 single AAL5 CPCS-PDU are sent immediately on the pseudowire using N- 1163 to-one cell encapsulation, followed by the AAL5 payload. Therefore, 1164 the AAL5 payload VCC service will not be suitable for ATM 1165 applications that require strict ordering of OAM cells (such as 1166 performance monitoring and security applications). 1168 10.1. Transparent AAL5 SDU Frame Encapsulation 1170 The AAL5 CPCS-SDU is prepended by the following header: 1172 0 1 2 3 1173 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 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 | Res |T|E|C|U|Res| Length | Sequence Number (Optional) | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | " | 1178 | ATM cell or AAL5 CPCS-SDU | 1179 | " | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 Figure 11: AAL5 CPCS-SDU Encapsulation 1184 The AAL5 payload service encapsulation requires the ATM control word. 1185 The Flag bits are described below. 1186 * Res (Reserved) These bits are reserved and MUST be set to 0 upon 1187 transmission and ignored upon reception. 1189 * T (transport type) bit 1191 Bit (T) of the control word indicates whether the packet contains 1192 an ATM admin cell or an AAL5 payload. If T = 1, the packet 1193 contains an ATM admin cell, encapsulated according to the VCC 1194 cell relay encapsulation, figure 8. If not set, the PDU contains 1195 an AAL5 payload. The ability to transport an ATM cell in the AAL5 1196 SDU mode is intended to provide a means of enabling 1197 administrative functionality over the AAL5 VCC (though it does 1198 not endeavor to preserve user-cell and admin-cell 1199 arrival/transport ordering). 1201 * E ( EFCI ) Bit 1203 The ingress router, PE1, SHOULD set this bit to 1 if the EFCI bit 1204 of the final cell of those that transported the AAL5 CPCS-SDU is 1205 set to 1, or if the EFCI bit of the single ATM cell to be 1206 transported in the packet is set to 1. Otherwise this bit SHOULD 1207 be set to 0. The egress router, PE2, SHOULD set the EFCI bit of 1208 all cells that transport the AAL5 CPCS-SDU to the value contained 1209 in this field. 1211 * C ( CLP ) Bit 1213 The ingress router, PE1, SHOULD set this bit to 1 if the CLP bit 1214 of any of the ATM cells that transported the AAL5 CPCS-SDU is set 1215 to 1, or if the CLP bit of the single ATM cell to be transported 1216 in the packet is set to 1. Otherwise this bit SHOULD be set to 1217 0. The egress router, PE2, SHOULD set the CLP bit of all cells 1218 that transport the AAL5 CPCS-SDU to the value contained in this 1219 field. 1221 * U ( Command / Response Field ) Bit 1223 When FRF.8.1 Frame Relay / ATM PVC Service Interworking [RFC3916] 1224 traffic is being transported, the CPCS-UU Least Significant Bit 1225 (LSB) of the AAL5 CPCS-PDU may contain the Frame Relay C/R bit. 1226 The ingress router, PE1, SHOULD copy this bit to the U bit of the 1227 control word. The egress router, PE2, SHOULD copy the U bit to 1228 the CPCS-UU Least Significant Bit (LSB) of the AAL5 CPCS PDU. 1230 11. AAL5 PDU frame mode 1232 The AAL5 payload PDU service is OPTIONAL. 1234 11.1. Transparent AAL5 PDU Frame Encapsulation 1236 In this mode, the ingress PE encapsulates the entire CPCS-PDU 1237 including the PAD and trailer. 1239 This mode MAY support fragmentation procedures described in the 1240 "Fragmentation" section below, in order to maintain OAM cell 1241 sequencing. 1243 Like the ATM AAL5 payload VCC service, the AAL5 transparent VCC 1244 service is intended to be more efficient than the VCC cell transport 1245 service. However, the AAL5 transparent VCC service carries the entire 1246 AAL5 CPCS-PDU, including the PAD and trailer. Note that the AAL5 1247 CPCS-PDU is not processed, i.e., an AAL5 frame with an invalid CRC or 1248 length field will be transported. One reason for this is that there 1249 may be a security agent that has scrambled the ATM cell payloads that 1250 form the AAL5 CPCS-PDU. 1252 This service supports all OAM cell flows by using a fragmentation 1253 procedure that ensures that OAM cells are not repositioned in respect 1254 to AAL5 composite cells. 1256 The AAL5 transparent VCC service is OPTIONAL. 1258 0 1 2 3 1259 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 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | PSN Transport Header (As Required) | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Pseudowire Header | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 |0 0 0 0| Resvd | Optional Sequence Number |M|V| Res |U|E|C| 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 | " | 1268 | AAL5 CPCS-PDU | 1269 | (n * 48 bytes) | 1270 | " | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 Figure 12: AAL5 transparent service encapsulation 1275 The generic control word is inserted after the Pseudowire Header. The 1276 presence of the control word is MANDATORY. 1278 The M, V, Res, and C bits are as defined earlier for VCC One-to-one 1279 cell mode. 1281 * U Bit 1283 This field indicates whether this frame contains the last cell of 1284 an AAL5 PDU and represents the value of the ATM User-to-User bit 1285 for the last ATM cell of the PSN frame. Note: The ATM User-to- 1286 User bit is the least significant bit of the PTI field in the ATM 1287 header. This field is used to support the fragmentation 1288 functionality described later in this section. 1290 * E (EFCI) bit 1292 This field is used to convey the EFCI state of the ATM cells. The 1293 EFCI state is indicated in the middle bit of each ATM cell's PTI 1294 field. 1296 ATM-to-PSN direction (ingress): The EFCI field of the control 1297 byte is set to the EFCI state of the last cell of the AAL5 PDU or 1298 AAL5 fragment. 1300 PSN-to-ATM direction (egress): The EFCI state of all constituent 1301 cells of the AAL5 PDU or AAL5 fragment is set to the value of the 1302 EFCI field in the control byte. 1304 * C (CLP) bit 1306 This field is used to convey the cell loss priority of the ATM 1307 cells. 1309 ATM-to-PSN direction (ingress): The CLP field of the control 1310 byte is set to 1 if any of the constituent cells of the AAL5 PDU 1311 or AAL5 fragment has its CLP bit set to 1; otherwise this field 1312 is set to 0. 1314 PSN-to-ATM direction (egress): The CLP bit of all constituent 1315 cells for an AAL5 PDU or AAL5 fragment is set to the value of the 1316 CLP field in the control byte. The payload consists of the re- 1317 assembled AAL5 CPCS-PDU, 1318 including the AAL5 padding and trailer or the AAL5 fragment. 1320 11.2. Fragmentation 1322 The ingress PE may not always be able to reassemble a full AAL5 1323 frame. This may be due to the AAL5 PDU exceeding the pseudowire MTU 1324 or when OAM cells arrive during reassembly of the AAL5 PDU. In these 1325 cases, the AAL5 PDU shall be fragmented. In addition, fragmentation 1326 may be desirable to bound ATM cell delay. 1328 When fragmentation occurs, the procedures described in the following 1329 subsections shall be followed. 1331 11.2.1. Procedures in the ATM-to-PSN Direction 1333 The following procedures shall apply while fragmenting AAL5 PDUs: 1334 - Fragmentation shall always occur at cell boundaries within the 1335 AAL5 PDU. 1336 - Set the UU bit to the value of the ATM User-to-User bit in the 1337 cell header of the most recently received ATM cell. 1338 - The E and C bits of the fragment shall be set as defined earlier 1339 in section 9. 1340 - If the arriving cell is an OAM or an RM cell, send the current 1341 PSN frame and then send the OAM or RM cell using One-to-one 1342 single cell encapsulation (VCC). 1344 11.2.2. Procedures in the PSN-to-ATM Direction 1346 The following procedures shall apply: 1347 - The 3-bit PTI field of each ATM cell header is constructed as 1348 follows: 1349 -i. The most significant bit is set to 0, indicating a user 1350 data cell. 1351 -ii. The middle bit is set to the E bit value of the 1352 fragment. 1353 -iii. The least significant bit for the last ATM cell in the 1354 PSN frame is set to the value of the UU bit of Figure 1355 12. 1356 -iv. The least significant PTI bit is set to 0 for all other 1357 cells in the PSN frame. 1358 - The CLP bit of each ATM cell header is set to the value of the C 1359 bit of the control byte in Figure 12. 1360 - When a fragment is received, each constituent ATM cell is sent in 1361 correct order. 1363 12. Mapping of ATM and PSN Classes of Service 1365 This section is provided for informational purposes, and for guidance 1366 only. This section should not be considered part of the standard 1367 proposed in this document. 1369 When ATM PW service is configured over a PSN, the ATM service 1370 category of a connection SHOULD be mapped to a compatible class of 1371 service in the PSN network. A compatible class of service maintains 1372 the integrity of the service end to end. For example, the CBR service 1373 category SHOULD be mapped to a class of service with stringent loss 1374 and delay objectives. If the PSN implements the IP Diff-Serv 1375 framework, a class of service based on the EF PHB is a good 1376 candidate. 1378 Furthermore, ATM service categories have support for multiple 1379 conformance definitions [TM4.0]. Some are CLP blind, e.g., CBR, 1380 meaning that the QoS objectives apply to the aggregate CLP0+1 1381 conforming cell flow. Some are CLP significant, e.g., VBR.3, meaning 1382 that the QoS objectives apply to the CLP0 conforming cell flow only. 1384 When the PSN is MPLS based, a mapping between the CLP bit and the EXP 1385 field can be performed to provide visibility of the cell loss 1386 priority in the MPLS network. The actual value to be marked in the 1387 EXP field depends on the ATM service category, the ATM conformance 1388 definition, and the type of tunnel LSP used (E-LSP or L-LSP). The 1389 details of this mapping are outside the scope of this document. 1390 Operators have the flexibility to design a specific mapping which 1391 satisfies their own requirements. 1393 In both the ATM-to-PSN and PSN-to-ATM directions, the method used to 1394 transfer the CLP and EFCI information of the individual cells into 1395 the ATM specific field, or flags, of the PW packet is described in 1396 details in sections 6 through 9 for each encapsulation mode. 1398 13. ILMI Support 1400 An MPLS edge PE MAY provide an ATM ILMI to the ATM edge switch. If an 1401 ingress PE receives an ILMI message indicating that the ATM edge 1402 switch has deleted a VC, or if the physical interface goes down, it 1403 MUST send a PW status notification message for all PWs associated 1404 with the failure. When a PW label mapping is withdrawn, or PW status 1405 notification message is received the egress PE MUST notify its client 1406 of this failure by deleting the VC using ILMI. 1408 14. ATM Specific Interface Parameter Sub-TLVs 1410 The Interface parameter TLV is defined in [RFC4447], the IANA 1411 registry with initial values for interface parameter sub-TLV types is 1412 defined in [RFC4446], but the ATM PW specific interface paramenter is 1413 specified as follows: 1415 - 0x02 Maximum Number of concatenated ATM cells.. 1417 A 2 octet value specifying the maximum number of concatenated ATM 1418 cells that can be processed as a single PDU by the egress PE. An 1419 ingress PE transmitting concatenated cells on this PW can 1420 concatenate a number of cells up to the value of this parameter, 1421 but MUST NOT exceed it. This parameter is applicable only to PW 1422 types 3, 9, 0x0a, 0xc, [RFC4446] and 0xd and is REQUIRED for 1423 these PWC types. This parameter does not need to match in both 1424 directions of a specific PW. 1426 15. Congestion Control 1428 As explained in [RFC3985], the PSN carrying the PW may be subject to 1429 congestion, with congestion characteristics depending on PSN type, 1430 network architecture, configuration, and loading. During congestion 1431 the PSN may exhibit packet loss that will impact the service carried 1432 by the ATM PW. In addition, since ATM PWs carry an variety of 1433 services across the PSN, including but not restricted to TCP/IP, they 1434 may or may not behave in a TCP-friendly manner prescribed by 1435 [RFC2914]. In the presence of services that reduce transmission rate, 1436 ATM PWs may thus consume more than their fair share and in that case 1437 SHOULD be halted. 1439 Whenever possible, ATM PWs should be run over traffic-engineered PSNs 1440 providing bandwidth allocation and admission control mechanisms. 1441 IntServ-enabled domains providing the Guaranteed Service (GS) or 1442 DiffServ-enabled domains using EF (expedited forwarding) are examples 1443 of traffic-engineered PSNs. Such PSNs will minimize loss and delay 1444 while providing some degree of isolation of the ATM PW's effects from 1445 neighboring streams. 1447 It should be noted that when transporting ATM, DiffServ-enabled 1448 domains may use AF (Assured Forwarding) and/or DF (Default 1449 Forwarding) instead of EF, in order to place less burden on the 1450 network and gain additional statistical multiplexing advantage. In 1451 particular, table 1 of Appendix "V" in [ATM-MPLS] contains a detailed 1452 mapping between ATM classes and diff-serv classes. 1454 The PEs SHOULD monitor for congestion (by using explicit congestion 1455 notification, [VCCV], or by measuring packet loss) in order to ensure 1456 that the service using the ATM PW may be maintained. When a PE 1457 detects significant congestion while receiving the PW PDUs, the PE 1458 MAY use RM cells for ABR connections to notify the remote PE. 1460 If the PW has been set up using the protocol defined in [RFC4447], 1461 then procedures specified in [RFC4447] for status notification can be 1462 used to disable packet transmission on the ingress PE from the egress 1463 PE. The PW may be restarted by manual intervention, or by automatic 1464 means after an appropriate waiting time. 1466 16. IANA Considerations 1468 This document has no IANA Actions. 1470 17. Security Considerations 1472 This document specifies only encapsulations, and not the protocols 1473 used to carry the encapsulated packets across the PSN. Each such 1474 protocol may have its own set of security issues [RFC4447][RFC3985], 1475 but those issues are not affected by the encapsulations specified 1476 herein. Note that the security of the transported ATM service will 1477 only be as good as the security of the PSN. This level of security 1478 might be less rigorous then a native ATM service. 1480 18. Full Copyright Statement 1482 Copyright (C) The Internet Society (2006). 1484 This document is subject to the rights, licenses and restrictions 1485 contained in BCP 78, and except as set forth therein, the authors 1486 retain all their rights. 1488 This document and the information contained herein are provided on an 1489 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1490 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1491 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1492 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1493 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1494 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1496 19. Intellectual Property Statement 1498 The IETF takes no position regarding the validity or scope of any 1499 Intellectual Property Rights or other rights that might be claimed to 1500 pertain to the implementation or use of the technology described in 1501 this document or the extent to which any license under such rights 1502 might or might not be available; nor does it represent that it has 1503 made any independent effort to identify any such rights. Information 1504 on the procedures with respect to rights in RFC documents can be 1505 found in BCP 78 and BCP 79. 1507 Copies of IPR disclosures made to the IETF Secretariat and any 1508 assurances of licenses to be made available, or the result of an 1509 attempt made to obtain a general license or permission for the use of 1510 such proprietary rights by implementers or users of this 1511 specification can be obtained from the IETF on-line IPR repository at 1512 http://www.ietf.org/ipr. 1514 The IETF invites any interested party to bring to its attention any 1515 copyrights, patents or patent applications, or other proprietary 1516 rights that may cover technology that may be required to implement 1517 this standard. Please address the information to the IETF at ietf- 1518 ipr@ietf.org. 1520 20. Normative References 1522 [RFC4447] "Pseudowire Setup and Maintenance using LDP", Luca Martini, 1523 et al., RFC4447, April 2006 1525 [RFC3032] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter, 1526 D. Tappan, G. Fedorkow, D. Farinacci, T. Li, A. Conta. RFC3032 1528 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 1529 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 1531 [RFC4385] "Pseudowire Emulation Edge-to-Edge (PWE3) 1532 Control Word for Use over an MPLS PSN", S. Bryant, G. Swallow, 1533 L. Martini, D. McPherson, February 2006. 1535 21. Informative References 1537 [FBATM] ATM Forum Specification af-fbatm-0151.000 (2000) , "Frame 1538 Based ATM over SONET/SDH Transport (FAST)" 1540 [TM4.0] ATM Forum Specification af-tm-0121.000 (1999), "Traffic 1541 Management Specification Version 4.1" 1543 [I.371] ITU-T Recommendation I.371 (2000), "Traffic control and 1544 congestion control in B-ISDN". 1546 [I.610] ITU-T Recommendation I.610, (1999), "B-ISDN operation and 1547 maintenance principles and functions". 1549 [RFC3985] "PWE3 Architecture", Bryant, et al., RFC3985. 1551 [RFC3916] "Requirements for Peudo Wire Emulation Edge-to-Edge PWE3", 1552 RFC3916 1554 [RFC4026] "Provider Provisioned Virtual Private Network (VPN) 1555 Terminology", Andersson et al, RFC4026 1557 [VCCV] T. D. Nadeau, R. Aggarwal, "Pseudowire Virtual Circuit 1558 Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-07.txt, 1559 August 2005. (work in progress) 1561 [RFC2992] RFC-2992: Analysis of an Equal-Cost Multi-Path Algorithm, 1562 C. Hopps, November 2000 1564 [RFC3270] F. Le Faucheur, et al., rfc3270,"Multi-Protocol Label 1565 Switching (MPLS) Support of Differentiated Services",May 2002 1567 [ATM-MPLS] ATM Forum Specification af-aic-0178.001, "ATM-MPLS 1568 Network Interworking Version 2.0", August 2003. 1570 22. Significant Contributors 1572 Giles Heron 1573 Tellabs 1574 Abbey Place 1575 24-28 Easton Street 1576 High Wycombe 1577 Bucks 1578 HP11 1NT 1579 UK 1580 e-mail: giles.heron@tellabs.com 1582 Dimitri Stratton Vlachos 1583 Mazu Networks, Inc. 1584 125 Cambridgepark Drive 1585 Cambridge, MA 02140 1586 e-mail: d@mazunetworks.com 1588 Dan Tappan 1589 Cisco Systems, Inc. 1590 1414 Massachusetts Avenue 1591 Boxborough, MA 01719 1592 e-mail: tappan@cisco.com 1594 Jayakumar Jayakumar, 1595 Cisco Systems Inc. 1596 170, W.Tasman, 1597 San Jose , CA, 95134 1598 e-mail: jjayakum@cisco.com 1600 Eric C. Rosen 1601 Cisco Systems, Inc. 1602 1414 Massachusetts Avenue 1603 Boxborough, MA 01719 1604 E-mail: erosen@cisco.com 1605 Steve Vogelsang 1606 Laurel Networks, Inc. 1607 Omega Corporate Center 1608 1300 Omega Drive 1609 Pittsburgh, PA 15205 1610 e-mail: sjv@laurelnetworks.com 1612 Gerald de Grace 1613 Laurel Networks, Inc. 1614 Omega Corporate Center 1615 1300 Omega Drive 1616 Pittsburgh, PA 15205 1617 e-mail: gdegrace@laurelnetworks.com 1619 John Shirron 1620 Laurel Networks, Inc. 1621 Omega Corporate Center 1622 1300 Omega Drive 1623 Pittsburgh, PA 15205 1624 e-mail: jshirron@laurelnetworks.com 1626 Andrew G. Malis 1627 Tellabs 1628 90 Rio Robles Dr. 1629 San Jose, CA 95134 1630 e-mail: Andy.Malis@tellabs.com 1632 Vinai Sirkay 1633 Reliance Infocomm 1634 Dhirubai Ambani Knowledge City 1635 Navi Mumbai 400 709 1636 India 1637 e-mail: vinai@sirkay.com 1639 Chris Liljenstolpe 1640 Alcatel 1641 11600 Sallie Mae Dr. 1642 9th Floor 1643 Reston, VA 20193 1644 e-mail: chris.liljenstolpe@alcatel.com 1645 Kireeti Kompella 1646 Juniper Networks 1647 1194 N. Mathilda Ave 1648 Sunnyvale, CA 94089 1649 e-mail: kireeti@juniper.net 1651 John Fischer 1652 Alcatel 1653 600 March Rd 1654 Kanata, ON, Canada. K2K 2E6 1655 e-mail: john.fischer@alcatel.com 1657 Mustapha Aissaoui 1658 Alcatel 1659 600 March Rd 1660 Kanata, ON, Canada. K2K 2E6 1661 e-mail: mustapha.aissaoui@alcatel.com 1663 Tom Walsh 1664 Lucent Technologies 1665 1 Robbins Road 1666 Westford, MA 01886 USA 1667 e-mail: tdwalsh@lucent.com 1669 John Rutemiller 1670 Marconi Networks 1671 1000 Marconi Drive 1672 Warrendale, PA 15086 1673 e-mail: John.Rutemiller@marconi.com 1675 Rick Wilder 1676 Alcatel 1677 45195 Business Court 1678 Loudoun Gateway II Suite 300 1679 M/S STERV-SMAE 1680 Sterling, VA 20166 1681 e-mail: Rick.Wilder@alcatel.com 1682 Laura Dominik 1683 Qwest Communications, Inc. 1684 600 Stinson Blvd. 1685 Minneapolis, MN, 55413 1686 Email: ldomini@qwest.com 1688 23. Author Information 1690 Luca Martini 1691 Cisco Systems, Inc. 1692 9155 East Nichols Avenue, Suite 400 1693 Englewood, CO, 80112 1694 e-mail: lmartini@cisco.com 1696 Matthew Bocci 1697 Alcatel 1698 Grove House, Waltham Road Rd 1699 White Waltham, Berks, UK. SL6 3TN 1700 e-mail: matthew.bocci@alcatel.co.uk 1702 Nasser El-Aawar 1703 Level 3 Communications, LLC. 1704 1025 Eldorado Blvd. 1705 Broomfield, CO, 80021 1706 e-mail: nna@level3.net 1708 Jeremy Brayley 1709 ECI Telecom Inc. 1710 Omega Corporate Center 1711 1300 Omega Drive 1712 Pittsburgh, PA 15205 1713 e-mail: jeremy.brayley@ecitele.com 1715 Ghassem Koleyni 1716 Nortel Networks 1717 P O Box 3511, Station C Ottawa, Ontario, 1718 K1Y 4H7 Canada 1719 e-mail: ghassem@nortelnetworks.com 1720 Jayakumar Jayakumar, 1721 Cisco Systems Inc. 1722 225, E.Tasman, MS-SJ3/3, 1723 San Jose , CA, 95134 1724 e-mail: jjayakum@cisco.com