idnits 2.17.00 (12 Aug 2021) /tmp/idnits28059/draft-bocci-pwe3-app-frame-over-psn-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [3], [4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 28 has weird spacing: '... at any ti...' == Line 31 has weird spacing: '... The list ...' == Line 95 has weird spacing: '... This draft...' == Line 96 has weird spacing: '...tion in draft...' == Line 110 has weird spacing: '... 5 of this ...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2002) is 7304 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: '1' is mentioned on line 20, but not defined == Unused Reference: '7' is defined on line 988, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 998, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' == Outdated reference: draft-ietf-pwe3-requirements has been published as RFC 3916 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-requirements (ref. '6') == Outdated reference: draft-martini-l2circuit-encap-mpls has been published as RFC 4905 ** Downref: Normative reference to an Historic draft: draft-martini-l2circuit-encap-mpls (ref. '7') -- Possible downref: Normative reference to a draft: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '10' == Outdated reference: draft-ietf-l2tpext-l2tp-base has been published as RFC 3931 == Outdated reference: draft-ietf-mpls-diff-ext has been published as RFC 3270 Summary: 8 errors (**), 0 flaws (~~), 15 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Transport Working Group Matthew Bocci 2 Internet Draft Mustapha Aissaoui 3 Expiration Date: November 2002 John Fischer 4 Alcatel 6 Ghassem Koleyni 7 Nortel Networks 9 May 2002 11 Applicability Statement for AAL5 Transparent Frame Encapsulation 12 over PSN 14 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026 [1]. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet- Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 1. Abstract 39 This draft provides an applicability statement for the transparent 40 AAL5 PDU frame mode encapsulation in draft-fischer [4]. 42 Draft-fischer describes methods to carry ATM services over IP, L2TP 43 or MPLS. The PSN (e.g. MPLS) is used to transport ATM layer services 44 such as those defined by ITU-T as ATM transfer capabilities [2] and 45 the ATM Forum as ATM service categories [3]. The basic requirement is 46 to transparently transport ATM VCC service related information (e.g., 47 traffic parameters, QoS, OAM, etc.) over the Pseudo Wire (PW), over 48 the packet network. Transparent PDU frame mode enables bandwidth 49 efficiency gains to be realized for ATM VCCs that use AAL5, yet still 50 provide full ATM transparency, including the correct sequencing of 51 OAM cells on an AAL5 flow. 53 Table of contents 55 1. Abstract........................................................1 56 2. Introduction....................................................2 57 3. Conventions used in this document...............................3 58 4. Terminology.....................................................3 59 5. Applicability Statement.........................................4 60 5.1 Applicability..................................................4 61 5.2 Implementation and deployment considerations...................6 62 5.3. Limitations...................................................6 63 6 ATM Service Encapsulation........................................7 64 6.1 Length and Sequence Number.....................................7 65 6.1.1 Setting the length field.....................................8 66 6.1.2 Processing the length field..................................9 67 6.1.3 Setting the sequence number..................................9 68 6.1.4 Processing the sequence number...............................9 69 7 ATM VCC Services................................................10 70 7.1 Transparent AAL5 PDU Frame Service............................10 71 7.1.1 OAM Cell Support............................................12 72 7.1.2 Fragmentation...............................................12 73 7.1.2.1 Procedures in the ATM-to-MPLS Direction...................12 74 7.1.2.2 Procedures in the MPLS-to-ATM Direction...................13 75 8 ILMI support....................................................13 76 9 QoS considerations..............................................13 77 10 ATM Pseudo-Wire over MPLS specific requirements................15 78 10.1 MPLS Transport Label.........................................16 79 10.2 MPLS Pseudo Wire Label.......................................16 80 11 ATM Pseudo-Wire over L2TP specific requirements................17 81 11.1 L2TP Session ID..............................................18 82 11.2 Cookie.......................................................18 83 12 ATM Pseudo-Wire over IP specific requirements..................18 84 12.1 C, K, and S bits.............................................19 85 12.2 Protocol Type field..........................................19 86 12.3 Key Field....................................................19 87 12.4 GRE Sequence Number Field....................................19 88 13. Security Considerations.......................................20 89 14. References....................................................20 90 15. Acknowledgement...............................................21 91 16. Author's Addresses............................................21 93 2. Introduction 95 This draft provides an applicability statement for the AAL5 96 transparent frame mode encapsulation in draft-fischer [4]. 98 Draft-fischer describes methods to carry ATM services over an IP, 99 L2TP or MPLS based PSN. The PSN is used to transport ATM layer 100 services such as those defined by ITU-T as ATM transfer capabilities 102 [2] and by the ATM Forum as ATM service categories [3]. The basic 103 requirement is to transparently transport the ATM VCC service related 104 information (e.g., traffic parameters, QoS, OAM, etc.) over the 105 Pseudo Wire (PW), over the packet network. The transparent AAL5 PDU 106 mode is intended to be more efficient than the basic cell mode of 107 draft-fischer [4], yet still provide full ATM transparency including 108 the correct sequencing of OAM cells on an AAL5 flow. 110 Section 5 of this draft presents the applicability statement. 111 Sections 6 to 13 are taken from draft-fischer [4]. They provide the 112 details of the encapsulation methods as well as the OAM, ILMI, and 113 QoS procedures for the basic cell mode. 115 3. Conventions used in this document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [16]. 121 4. Terminology 122 Packet Switched Network - A Packet Switched Network (PSN) is a 123 network using IP, MPLS or L2TP as the unit of switching. 125 Pseudo Wire Emulation Edge to Edge - Pseudo Wire Emulation Edge to 126 Edge (PWE3) is a mechanism that emulates the essential attributes of 127 a service (such as a T1 leased line or Frame Relay) over a PSN. 129 Customer Edge - A Customer Edge (CE) is a device where one end of an 130 emulated service originates and terminates. The CE is not aware that 131 it is using an emulated service rather than a "real" service. 133 Provider Edge - A Provider Edge (PE) is a device that provides PWE3 134 to a CE. 136 Pseudo Wire - A Pseudo Wire (PW) is a connection between two PEs 137 carried over a PSN. The PE provides the adaptation between the CE 138 and the PW. 140 Pseudo Wire PDU - A Pseudo Wire PDU is a PDU sent on the PW that 141 contains all of the data and control information necessary to provide 142 the desired service. 144 PSN Tunnel - A PSN Tunnel is a tunnel inside which multiple PWs can 145 be nested so that they are transparent to core network devices. 147 Ingress - The point where the ATM service is encapsulated into a 148 Pseudo Wire PDU (ATM to PSN direction.) 150 Egress - The point where the ATM service is de-capsulated from a 151 Pseudo Wire PDU (PSN to ATM direction.) 152 CTD Cell Transfer Delay 153 MTU Maximum Transfer Unit 154 OAM Operations, Administration, and Maintenance. 155 PVC Permanent Virtual Connection. An ATM connection that is 156 provisioning via a network management interface. The 157 connection is not signalled. 158 VCC Virtual Circuit Connection. An ATM connection that is 159 switched based on the cell header's VCI. 161 5. Applicability Statement 163 5.1 Applicability 165 The primary application supported by AAL5 PDU frame encapsulation 166 over PSN is the transparent carriage of ATM layer services that use 167 AAL5 to carry higher layer frames. The PDU frame mode takes advantage 168 of the delineation of higher layer frames in the ATM layer to provide 169 increased bandwidth efficiency compared with the basic cell 170 encapsulation mode of draft-fischer [4]. The nature of the service, 171 as defined by the ATM service category [3] or the ATM transfer 172 capability [2] should be preserved. To provide this, the basic 173 requirement of the ATM-PSN interworking function is to map the AAL5 174 PDU frames belonging to a VCC, together with any related OAM and 175 protocol control information, into a PW. 177 Two network applications that utilize the PDU frame mode 178 encapsulation described in draft-fischer [4] are: 180 a. The transport of multi-service ATM over a packet core network 181 where AAL5 is used as the adaptation layer. Many service providers 182 have multiple service networks and the Operational Support System 183 capabilities needed to support these existing service offerings. 184 Packet Switched Networks (PSNs) have the potential to reduce the 185 complexity of a service provider's infrastructure by allowing 186 virtually any existing digital service to be supported over a single 187 networking infrastructure. 189 The benefits of this model to a service provider are threefold: 191 i. Leveraging of the existing systems and services to 192 provide increased capacity from a packet switched core. 193 ii. Preserving existing network operational processes and 194 procedures used to maintain the legacy services e.g. ATM OAM and 195 ATM security. 196 iii. Using the common packet switched network infrastructure 197 to support both the core capacity requirements of existing 198 services and the requirements of new services supported natively 199 over the packet switched network. 201 b. L2 VPN service over a PSN infrastructure. In this case, VPN sites 202 are connected through ATM VCCs, as in today's L2 VPNs. The 203 transparent PDU frame mode encapsulation allows the VPN service 204 provider to transparently extend this L2 connectivity over its PSN 205 while achieving bandwidth efficiency gains over the basic cell mode 206 and supporting ATM layer applications of the VPN customer, such as 207 ATM security. The advantage is for the service provider to combine L2 208 and L3 services over the same PSN. 210 Figure 1 shows the reference model for carrying ATM services over a 211 PSN. This model is adapted from [6]. 213 |<------- Pseudo Wire ------>| 214 | | 215 | |<-- PSN Tunnel -->| | 216 V V V V 217 ATM Service+----+ +----+ ATM Service 218 +-----+ | | PE1|==================| PE2| | +-----+ 219 | |----------|............PW1.............|----------| | 220 | CE1 | | | | | | | | CE2 | 221 | |----------|............PW2.............|----------| | 222 +-----+ | | |==================| | | +-----+ 223 ^ | +----+ +----+ | ^ 224 | | Provider Provider | | 225 | | Edge 1 Edge 2 | | 226 | | 227 |<-------------- Emulated Service ---------------->| 229 Customer Customer 230 Edge 1 Edge 2 232 Figure 1: ATM-over-PSN Service Reference Model 234 An ATM VCC is carried over a PW. The PW corresponding to any VCC may 235 be further tunneled in a transport PSN tunnel to achieve multiplexing 236 gain and bandwidth efficiency. 238 When the QoS considerations in Section 10 are respected, this ATM 239 over PSN service encapsulation method provides end users with the 240 same quality of service on any given VCC as per corresponding SLA, 241 traffic contracts and the QoS commitments for that connection. 243 One important consideration to make when interworking is to allow 244 OAM information to be treated as in the original network. The 245 interworking function allows this transparency while performing AAL5 246 frame encapsulation. Fragmentation may be performed in order to 247 maintain the position of the OAM cells with respect to the user 248 cells. 250 Fragmentation may also be performed to maintain the size of the 251 packet carrying the AAL5 PDU within the MTU of the link. 253 Cell Loss priority (CLP) field conveys the priority of the cell in 254 the connection. The Explicit Forward Congestion Indicator (EFCI) 255 field conveys the congestion state of ATM network. Information on 256 both of these fields is obtained from the ATM cell header. CLP and 257 EFCI fields are both part of the ATM service specific information 258 header. 260 For ease of operation and to achieve transparency, the whole AAL5- 261 PDU is encapsulated. In this case all necessary parameters such as 262 CPCS-UU (CPCS User-to-User indicator), CPI (Common Part Indicator), 263 Length (Length of the CPCS-SDU) and CRC (Cyclic Redundancy Check) 264 are transported as part of the payload. Note that carrying of the 265 full PDU also allows the simplification of the fragmentation 266 operation since it is performed at cell boundaries and the CRC in 267 the trailer of the AAL5 PDU can be used to check the integrity of 268 the reassembled fragments. 270 5.2 Implementation and deployment considerations 272 AAL5 transparent mode is only applicable to services that use AAL5 to 273 carry higher layer frames over ATM VCCs. 275 5.3. Limitations 277 AAL5 frame encapsulation only supports point-to-point LSPs. Multi- 278 point-to-point and point-to-multi-point are for further study (FFS). 280 To have bi-directional connectivity, as required in ATM, two LSPs 281 should be configured, one for each direction (ATM-to-MPLS and MPLS- 282 to-ATM) of the ATM connection. 284 Length of AAL5 frame may exceed the MTU of the PSN. This requires 285 fragmentation, which may not be available to all nodes at the PW 286 endpoint. 288 The maximum number of cells of an AAL5 PDU that may be reassembled 289 before transport across the PSN may be limited by the cell transfers 290 delay (CTD) and cell delay variation (CDV) objectives of the 291 connection. 293 This mode does not preserve the value of the CLP bit for every ATM 294 cell within an AAL5 PDU. Therefore, transparency of the CLP setting 295 may be violated. Additionally, tagging of some cells may occur when 296 tagging is not allowed by the conformance definition. 298 This mode does not preserve the EFCI state for every ATM cell within 299 an AAL5 PDU. Therefore, transparency of the EFCI state may be 300 violated. 302 6 ATM Service Encapsulation 304 This section describes the general encapsulation format for ATM over 305 PSN pseudo wires, such as IP, L2TP, or MPLS. The specifics pertaining 306 to each packet technology are covered in later sections. All 307 encapsulation formats and procedures contained in the following 308 sections are from draft-fischer [4]. 310 Figure 2 provides a general format for encapsulation of ATM cells 311 into packets. 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | PSN Transport Header (As Required) | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Pseudo Wire Header | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Optional Length and Sequence Number | ATM Specific | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | ATM Service Payload | 323 | | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Figure 2: General format for ATM encapsulation over PSNs 328 The PSN Transport Header depends on the packet technology: IP, L2TP 329 or MPLS. This header is used to transport the encapsulated ATM 330 information through the packet switched core. This header is always 331 present if the Pseudo Wire is MPLS. 333 The Pseudo Wire Header depends on the packet technology: IP, L2TP or 334 MPLS. It identifies a particular ATM service within the PSN tunnel. 336 The Length and Sequence Number is inserted after the Pseudo Wire 337 Header. This field is optional. 339 The ATM Specific Header is inserted before the ATM service payload. 340 The ATM Specific Header contains control bits needed to carry the 341 service. These are defined in the ATM service descriptions below. 342 The length of ATM specific header may not always be one octet. It 343 depends on the service type. 345 The ATM payload octet group is the payload of the service that is 346 being encapsulated. 348 6.1 Length and Sequence Number 349 The length and sequence number are not required for all services. 350 Length and sequence number are to satisfy these requirements. 352 - Order may need to be preserved. 353 - Small packets may need to be padded in order to be transmitted on a 354 medium where the minimum transport unit is larger than the actual 355 packet size. 357 The one-octet Length indicates length of the packet payload that 358 includes, length of the length field, Sequence number length, the ATM 359 specific header length and the payload length (i.e., Pseudo Wire 360 PDU). The Length field is set to 0 by the ingress PE if not used and 361 is ignored by the egress PE. 363 If the Pseudo Wire traverses a network link that requires a minimum 364 frame size such as Ethernet as a practical example, with a minimum 365 frame size of 64 octets, then such links will apply padding to the 366 Pseudo Wire PDU to reach its minimum frame size. In this case the 367 length field MUST be set to the PDU length. A mechanism is required 368 for the egress PE to detect and remove such padding. 370 The Sequence Number is a 2-octet field that may be used to track 371 packet order delivery. This field is set to 0 by the ingress PE if 372 not used and is ignored by the egress PE. The sequence number space 373 is a 16-bit, unsigned circular space. Processing of the sequence 374 number field is OPTIONAL. 376 In all cases the egress PE MUST be aware of whether the ingress PE 377 will send the length and sequence number over a specific Pseudo Wire. 378 This may be achieved using static configuration or using Pseudo Wire 379 specific signaling. 381 Length field is not required for cell mode 383 6.1.1 Setting the length field 385 The length field is required to enable the egress PE to remove any 386 padding that may have resulted if the pseudo-wire traversed a network 387 link that enforces a minimum frame size (e.g. Ethernet). Ethernet 388 applies padding to frames that are smaller than 64 bytes, where this 389 includes a minimum of 18 bytes for the Ethernet header and trailer. 391 The length field represents the size of the packet in bytes including 392 the length, sequence number, ATM specific header and ATM service 393 payload. If the size of the packet is larger than can be 394 represented by the length field, the field MUST be set to 0. In 395 addition, the length field MAY be set to 0 if the size of the packet 396 prevents any padding from being applied. 398 The AAL5 SDU Frame service is the only service that can generate 399 packets smaller than the Ethernet minimum and MUST set the length 400 field accordingly. The length field MUST either be set to the size 401 of the packet if the size is less than 46 bytes or to 0. 403 All cell transport services MUST always set the length field to 0 to 404 indicate to the remote PE that no padding was applied. 406 6.1.2 Processing the length field 408 Since length field is not used for cell mode, no processing is 409 required. 411 6.1.3 Setting the sequence number 413 The following procedures SHOULD be used by the ingress PE if 414 sequencing is desired for a given ATM service: 416 - the initial PDU transmitted on the Pseudo Wire MUST use sequence 417 number 1 418 - the PE MUST increment the sequence number by one for each 419 subsequent PDU 420 - when the transmit sequence number reaches the maximum 16 bit value 421 (65535) the sequence number MUST wrap to 1 423 If the ingress PE does not support sequence number processing, then 424 the sequence number field in the control word MUST be set to 0. 426 6.1.4 Processing the sequence number 428 If the egress PE supports receive sequence number processing, then 429 the following procedures SHOULD be used: 431 When an ATM service is initially created, the "expected sequence 432 number" associated with it MUST be initialized to 1. 434 When a PDU is received on the Pseudo Wire associated with the ATM 435 service, the sequence number SHOULD be processed as follows: 437 - if the sequence number on the packet is 0, then the PDU passes the 438 sequence number check 440 - otherwise if the PDU sequence number >= the expected sequence 441 number and the PDU sequence number - the expected sequence number < 442 32768, then the PDU is in order. 444 - otherwise if the PDU sequence number < the expected sequence 445 number and the expected sequence number - the PDU sequence number >= 446 32768, then the PDU is in order. 448 - otherwise the PDU is out of order. 450 If a PDU passes the sequence number check, or is in order then, it 451 can be delivered immediately. If the PDU is in order, then the 452 expected sequence number SHOULD be set using the algorithm: 454 expected_sequence_number := PDU_sequence_number + 1 mod 2**16 455 if (expected_sequence_number = 0) 456 then expected_sequence_number := 1; 458 Pseudo Wire PDUs that are received out of order MAY be dropped or 459 reordered at the discretion of the egress PE. 461 If the egress PE does not support receive sequence number processing, 462 then the sequence number field MAY be ignored. 464 7 ATM VCC Services 466 This section defines ATM AAL5 VCC services that may be supported over 467 the PSN. 469 7.1 Transparent AAL5 PDU Frame Service 471 In this mode, the ingress PE encapsulates the entire CPCS-PDU 472 including the PAD and trailer. 474 This mode MAY support fragmentation in order to maintain OAM cell 475 sequencing. 477 Like the ATM AAL5 payload VCC service, the AAL5 transparent VCC 478 service is intended to be more efficient than the VCC cell transport 479 service. However, the AAL5 transparent VCC service carries the 480 entire AAL5 CPCS-PDU, including the PAD and trailer. Note that the 481 AAL5 CPCS-PDU is not processed _ i.e. an AAL5 frame with an invalid 482 CRC or length field will be transported. One reason for this is that 483 there may be a security agent that has scrambled the ATM cell 484 payloads that form the AAL5 CPCS-PDU. 486 This service supports all OAM cell flows by using a fragmentation 487 procedure that ensures that OAM cells are not repositioned in respect 488 to AAL5 composite cells. 490 The AAL5 transparent VCC service is OPTIONAL. 492 0 1 2 3 493 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 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | PSN Transport Header (As Required) | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Pseudo Wire Header | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Optional Length and Sequence Number |M|V|Res|Frg|E|C| 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 + " | 502 | AAL5 CPCS-PDU | 503 | (n * 48 bytes) | 504 | " | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 Figure 3: AAL5 transparent service encapsulation 509 The first octet following the Pseudo Wire Header carries control 510 information. The M, V, Res, and C bits are as defined earlier for 511 VCC cell mode. 513 * Frg (Fragmentation) Bits 515 This field is used to support the fragmentation functionality 516 described later in this section. 518 - 11 Single Segment Message (Beginning and End of Message) 519 - 10 Beginning of Message 520 - 00 Continuation of Message 521 - 01 End of Message 523 * E (EFCI) bit 525 This field is used to convey the EFCI state of the ATM cells. 526 The EFCI state is indicated in the middle bit of each ATM 527 cell's PTI field. 529 ATM-to-PSN direction (ingress): The EFCI field of the 530 control byte is set to the EFCI state of the last cell of 531 the AAL5 PDU or AAL5 fragment. 533 PSN-to-ATM direction (egress): The EFCI state of all 534 constituent cells of the AAL5 PDU or AAL5 fragment is set to 535 the value of the EFCI field in the control byte. 537 * C (CLP) bit 539 This field is used to convey the cell loss priority of the ATM 540 cells. 542 ATM-to-PSN direction (ingress): The CLP field of the 543 control byte is set to 1 if any of the constituent cells of 544 the AAL5 PDU or AAL5 fragment has its CLP bit set to 1; 545 otherwise this field is set to 0. 547 PSN-to-ATM direction (egress): The CLP bit of all 548 constituent cells for an AAL5 PDU or AAL5 fragment is set to 549 the value of the CLP field in the control byte. 550 The payload consists of the re-assembled AAL5 CPCS-PDU, 551 including the AAL5 padding and trailer or the AAL5 fragment. 553 7.1.1 OAM Cell Support 555 When configured for the AAL5 transparent VCC service, both PE's 556 SHOULD act as a VC switch, in accordance with the OAM procedures 557 defined in [5]. 559 The PEs SHOULD be able to pass the following OAM cells transparently: 560 - F5 AIS (segment and end-to-end) 561 - F5 RDI (segment and end-to-end) 562 - F5 loopback (segment and end-to-end) 563 - Resource Management 564 - Performance Management 565 - Continuity Check 566 - Security 568 The PEs SHALL use the single ATM VCC cell mode encapsulation (Section 569 6.1, draft-fischer[4]) when passing an OAM cell. 571 The ingress PE SHOULD be able to generate an F5 AIS upon reception of 572 a corresponding F4 AIS or lower layer defect (such as LOS). 574 The egress PE SHOULD be able to generate an F5 AIS based on a PSN 575 failure (such as a PSN tunnel failure or LOS on the PSN port). 577 If the ingress PE cannot support the generation of OAM cells, it MAY 578 notify the egress PE using a Pseudo Wire specific maintenance 579 mechanism to be defined. For example, the ingress PE MAY withdraw 580 the Pseudo Wire (VC label) associated with the service. Upon 581 receiving such a notification, the egress PE SHOULD generate the 582 appropriate F5 AIS. 584 7.1.2 Fragmentation 586 The ingress PE may not always be able to reassemble a full AAL5 587 frame. This may be due to the AAL5 PDU exceeding the Pseudo Wire MTU 588 or when OAM cells arrive during reassembly of the AAL5 PDU. In these 589 cases, the AAL5 PDU shall be fragmented. In addition, fragmentation 590 may be desirable to bound ATM cell delay. 592 If no fragmentation occurs, then the fragmentation bits are set to 11 593 (SSM, Single Segment Message). 595 When fragmentation occurs, the procedures described in the following 596 subsections shall be followed. 598 7.1.2.1 Procedures in the ATM-to-MPLS Direction 600 The following procedures shall apply while fragmenting AAL5 PDUs: 601 - Fragmentation shall always occur at cell boundaries within the 602 AAL5 PDU. 603 - For the first fragment, the FRG bits shall be set to 10 (BOM, 604 Beginning Of Message). 605 - For the last fragment, the FRG bits shall be set to 01 (EOM, 606 End Of Message). 607 - For all other fragments, the FRG bits shall be set to 00 (COM, 608 Continuation Of Message). 609 - The E and C bits of the fragment shall be set as defined 610 earlier in section 7. 612 7.1.2.2 Procedures in the MPLS-to-ATM Direction 614 The following procedures shall apply: 615 - The 3-bit PTI field of each ATM cell header is constructed as 616 follows: 617 + The most significant bit is set to 0, indicating a user 618 data cell. 619 + The middle bit is set to the E bit value of the 620 fragment. 621 + The least significant bit is set to 1 for the last ATM 622 cell of a fragment where the FRG bits are 01 (EOM) or 623 11(SSM); otherwise this bit is set to 0. 624 - The C bit of each ATM cell header is set to the value of the C 625 bit of the control byte in Figure 5. 627 8 ILMI support 629 Integrated Local Management Interface (ILMI) typically is used in ATM 630 networks for neighbor resource availability detection, address 631 registration, auto-configuration, and loss of connectivity detection. 632 ILMI messages are sent as SNMP PDU's within ATM AAL5 cells. 634 A PE MAY provide an ATM ILMI to its attached CE. If the ingress PE 635 receives an ILMI message indicating that the ATM service (VCC) is 636 down, it MAY use a Pseudo Wire specific mechanism to notify the 637 egress PE of the ATM service status. For example, a PE using an MPLS 638 based Pseudo Wire may withdraw its advertised VC label. 640 When receiving such a notification, the egress PE MAY use ILMI to 641 signal the ATM service status to its attached CE. 643 9 QoS considerations 645 This section provides guidelines for the provision of QoS for the 646 individual ATM PWs over the PSN. The objective is to provide the 647 ability to support the traffic contracts and the QoS commitments made 648 to the ATM connections [8]. This section is informational and the 649 provided guidelines SHOULD be treated as good practices and the 650 mappings as examples only. 652 When ATM PW service is configured over a PSN, each ATM service 653 category SHOULD be mapped to a compatible class of service in the PSN 654 network. A compatible class of service maintains the integrity of 655 the service end to end. For example, the CBR service category SHOULD 656 be mapped to a class of service with stringent loss and delay 657 objectives. If the PSN implements the IP Diff-Serv framework to 658 provide QoS classes, a class of service based on the EF PHB is a good 659 candidate. 661 Furthermore, ATM service categories have support for multiple 662 conformance definitions. A conformance definition specifies the 663 conformance of cells of a connection at an interface, e.g., public 664 UNI, in relation to the conformance algorithm and corresponding 665 parameters specified in the connection traffic descriptor [15]. For 666 example, the conformance definition specifies if the requested QoS 667 parameters, e.g., CLR, apply to the aggregate CLP0+1 conforming cell 668 flow or to the CLP0 conforming flow only. Thus, the conformance 669 definition SHOULD be respected in the selected PSN class of service. 671 For example, a connection CLP1 cell flow in a VBR.3 conformance 672 definition is treated as excess traffic in the ATM network and thus 673 has no QoS guarantees associated with it. This flow SHOULD be 674 provided a treatment no better than the treatment of the CLP0 cell 675 flow in the PSN. This does not mean however that the PSN network 676 should mirror the various conformance definitions of the ATM service 677 categories. 679 In the remainder of this section, it is assumed that the PSN 680 implements IP Diff-Serv framework to provide QoS. 682 All ATM traffic management functions specified in [3] are applicable 683 for the ATM part of the ATM PW in the ingress PE and egress PE. In 684 the ATM-to-PSN direction, each ATM connection MAY be policed and/or 685 shaped to conform to its traffic descriptor in the ATM endpoint of 686 the ATM PW in the PE. Whenever allowed by the conformance 687 definition, a non-conforming CLP0 cell may be turned into a CLP1 cell 688 and becomes conforming. Connection admission SHOULD be applied to 689 make sure sufficient resources are available to carry the ATM PW over 690 the transport LSP. The mapping of ATM service category and 691 conformance definition to the Diff-Serv PHB determines the outgoing 692 PHB. This is the PHB to be applied to the cells or packets of the 693 ATM PW in the ingress PE and egress PE and inside the PSN. The PSN 694 transport header of the outgoing PSN packet SHOULD be marked to 695 identify the selected PHB. This consists of marking the DS field in 696 the IP header in the case of IP PSN, or the EXP field in the 697 transport shim header in the case of a MPLS PSN. 699 Figure 4 provides an example of mapping ATM service category and 700 conformance definition to a Diff-Serv PHB. 702 ATM Service Conformance CLP Diff-Serv DSCP 703 Category Definition Setting PHB Marking 704 ---------------------------------------------------------------- 705 CBR CBR.1 0/1 EF 101110 706 rt-VBR VBR.1 0/1 EF 101110 707 VBR.2/VBR.3 0 AF11 001010 708 1 AF12 001100 709 nrt-VBR VBR.1 0/1 AF21 010010 710 VBR.2/VBR.3 0 AF21 010010 711 1 AF22 010100 712 ABR ABR 0 AF31 011010 713 UBR+MDCR UBR.1/UBR.2 0/1 AF31 011010 714 GFR GFR.1/GFR.2 0 AF31 011010 715 1 AF32 011100 716 UBR UBR.1/UBR.2 0/1 DF 000000 718 Figure 4: Example of ATM Service Category to PHB Mapping 720 Note that an alternative mapping may not distinguish between the 721 conformance definitions in a given ATM service category. In this 722 case, the CLP0 and CLP1 flows of a ATM connection are provided with 723 the same QoS in the PSN. As an example, all conformance definitions 724 of the nrt-VBR service category MAY be mapped to the AF21 PHB in 725 Figure 9. 727 When the PSN is MPLS based, the selected PHB for the ATM PW is 728 conveyed in different ways depending if the transport LSP is an L- 729 LSP or an E-LSP [15]. In the case of an L-LSP, the PHB Scheduling 730 Class is signaled at the transport LSP establishment and is therefore 731 inferred from the transport label value. The Drop Precedence of the 732 individual PW packets is conveyed in the EXP field of the transport 733 LSP shim header. In the case of an E-LSP, the PHB is conveyed in the 734 EXP field of the transport LSP shim header. The actual values to be 735 marked in the EXP field to reflect the example in Figure 9 is outside 736 the scope of this document. 738 In the presence of congestion, the PE MAY mark the EFCI bit and MAY 739 perform selective cell discard based on CLP setting, if allowed by 740 the conformance definition, and in accordance with [15]. The method 741 used to transfer the CLP and EFCI information of the individual cells 742 into the ATM specific field of the PW packet is described in details 743 in sections 7 and 8. 745 In the PSN-to-ATM direction, the ATM service category and conformance 746 definition is obtained from the context accessed via the pseudo wire 747 label of the ATM PW. The information needed to reconstruct the ATM 748 header, including the setting of the CLP and EFCI fields, for the 749 individual cells is contained in the ATM specific information field 750 of the PW packet. The method used to determine the CLP and EFCI 751 information of the individual cells from the ATM specific information 752 field of the PW packet is described in details in sections 6 and 7. 754 10 ATM Pseudo-Wire over MPLS specific requirements 755 Figure 5 provides a general format for interworking between ATM and 756 MPLS. The ATM information is encapsulated inside two MPLS labels as 757 defined in [9]. 759 The Pseudo Wire Endpoint uses a unique MPLS label, the pseudo wire 760 label, to identify each direction of an ATM connection. This label 761 allows the PWE to access context information for the connection. As 762 an example, the context may contain the information regarding 763 connection type such as VCC or VPI/VCI value that need to be inserted 764 into the ATM cell header in the MPLS-to-ATM direction. 766 0 1 2 3 767 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 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | MPLS Transport Label | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | MPLS Pseudo Wire Label | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | Optional Length and Sequence Number | ATM Specific | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | ATM Service Payload | 776 | | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 Figure 5: Format for ATM PW over a MPLS PSN 781 10.1 MPLS Transport Label 783 The 4-octet MPLS transport label identifies an LSP used to transport 784 traffic between two ATM-MPLS pseudo wire endpoints. This label is 785 used to switch the transport LSP between core LSRs. Since an MPLS LSP 786 is unidirectional, for the case of bi-directional traffic there will 787 be two different pseudo wire LSPs, one for each direction of the 788 connection. These may have different label values. Setting of the 789 EXP and TTL is for further study. The S bit is set to 0 since this 790 is not the last label in the MPLS label stack. 792 10.2 MPLS Pseudo Wire Label 794 The 4-octet interworking label uniquely identifies one pseudo wire 795 LSP, carried inside a MPLS transport LSP. The pseudo wire label has 796 the structure of a standard MPLS shim header. More than one pseudo 797 wire LSP may be supported by one MPLS transport LSP. The pseudo wire 798 endpoint provides the association between the ATM connection or the 799 ATM port and MPLS LSP by means of the 20-bit label field of the 800 pseudo wire LSP. In this association, in the ATM-to-MPLS direction a 801 mapping of the VCI/VPI of the ATM connection or the Port to the 20- 802 bit label is performed, while in the MPLS-to-ATM direction the 20-bit 803 label is mapped to a VPI/VCI of the ATM connection or to a Port. This 804 association is signalled or provisioned between the two pseudo-wire 805 endpoints. 807 Since an MPLS LSP is unidirectional, for the case of bi-directional 808 ATM VCCs there will be two different pseudo wire LSPs, one for each 809 direction of the connection. These may have different label values. 810 Setting of the EXP and TTL is for further study. The S bit is set to 811 1 since this is the last label in the bottom of the MPLS stack. The 812 pseudo wire label is not visible to the LSRs within the MPLS core 813 network. 815 11 ATM Pseudo-Wire over L2TP specific requirements 817 Figure 6 provides a general format for interworking between ATM and 818 L2TP. This draft refers to L2TPv3, or L2TP base, as described in 819 [11]. L2TP base extends the original L2TP [12] to operate directly 820 over an IP PSN and to further generalize the control procedures to 821 carry any tunneled Layer 2 protocol other than PPP. Any further 822 reference to L2TP in this document assumes L2TPv3 or L2TP base as 823 specified in [11]. 825 The ATM information is encapsulated inside a L2TP tunnel packet. The 826 L2TP tunnel is setup over an IPv4 PSN. The IPv4 protocol in the IPv4 827 header is set to 115 to indicate that the L2TP packet is encapsulated 828 in an IPv4 packet [11]. Furthermore, L2TP can operate over IP or over 829 UDP. The use of either mode is outside the scope of this document. 830 The encapsulation format shown in Figure 11 represents the common 831 headers for carrying L2TP packet over UDP and IP. If UDP is used, 832 additional header information is required and is defined in [11]. 834 The Pseudo Wire Endpoint uses a unique L2TP session ID to identify 835 each direction of an ATM connection. This session ID is local to each 836 PE and allows the PWE to identify each ATM PW in the L2TP tunnel in 837 order to access context information for the ATM connection. As an 838 example, the context may contain the information regarding connection 839 type such as VCC VPI/VCI value that need to be inserted into the ATM 840 cell header in the L2TP-to-ATM direction. Multiple PWs with locally 841 unique Session IDs at each PE can be multiplexed into a L2TP tunnel. 843 0 1 2 3 844 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 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | L2TP Session ID | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Cookie (optional, up to 64 bits) | 849 | | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Optional Length and Sequence Number | ATM Specific | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | ATM Service Payload | 854 | | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 Figure 6: Format for ATM PW over a L2TP PSN 858 11.1 L2TP Session ID 860 This is 32-bit field containing a non-zero identifier for a session, 861 or a PW in this case. L2TP sessions are named by identifiers that 862 have local significance only at each PE [11]. 864 Each PE for the life of the session will give different Session IDs 865 the same PW. Multiple PWs with locally unique Session IDs at each PE 866 can be multiplexed into a L2TP tunnel. When the L2TP control 867 connection is used for session establishment, Session IDs are 868 selected and exchanged as Local Session ID Attribute Value Pairs 869 (AVPs) during the creation of a PW. A session ID of zero is reserved 870 for the carriage of L2TP control messages [11]. 872 11.2 Cookie 874 The optional Cookie field contains a variable length (maximum 64 875 bits), long word-aligned value used to check the association of a 876 received packet with the PW identified by the Session ID. The Cookie 877 MUST be configured with a random value utilizing all bits in the 878 field [11]. The Cookie provides an additional level of guarantee, 879 beyond the Session ID lookup, that a packet has been directed to the 880 proper PW identified by the Session ID. 882 When the L2TP control connection is used for PW session 883 establishment, random Cookie values are selected and exchanged as 884 Assigned Cookie AVPs during the creation of a PW. The maximum size 885 of the Cookie field is 64 bits. 887 12 ATM Pseudo-Wire over IP specific requirements 889 Figure 7 provides a general format for carrying an ATM PW over an IP 890 PSN. This is an alternative encapsulation to the one using L2TP, as 891 described in Section 11. The GRE encapsulation is used as specified 892 in [13] and [14]. The IPv4 protocol in the IPv4 header is set to 47 893 to indicate that the GRE packet is encapsulated in an IPv4 packet 894 [13]. 896 The ATM information is encapsulated inside a GRE/IP packet. The 897 Pseudo Wire Endpoint uses a unique GRE Key to identify each direction 898 of an ATM connection. As an example, the context may contain the 899 information regarding connection type such as VCC VPI/VCI value that 900 need to be inserted into the ATM cell header in the IP-to-ATM 901 direction. Multiple PWs with unique GRE Keys can be multiplexed into 902 a GRE/IP tunnel. 904 0 1 2 3 905 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 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | IPv4 Header (N words) | 908 | | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 |C| |K|S| Reserved0 | Ver | Protocol Type | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Key | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | GRE Sequence Number (Optional) | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Optional Length and Sequence Number | ATM Specific | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | ATM Service Payload | 919 | | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 Figure 7: Format for ATM PW over an IP PSN 924 12.1 C, K, and S bits 926 The Checksum field in the GRE header is not required for carrying 927 ATM PW over IP PSN. Therefore the C bit is set to zero. 929 The Key field in the GRE header is always used (see Section 12.3). 930 Therefore, the K bit is always set to 1. 932 If the GRE Sequence Number field is used, then the value of the K 933 bit is set to 1. Otherwise, its value is set to zero. 935 12.2 Protocol Type field 937 The Protocol Type field is set to a number to be allocated by IEEE 938 for the purpose of encapsulating ATM PW over GRE. 940 12.3 Key Field 942 The Key field contains a four-octet number that is inserted by the 943 transmitting PE. The Key field is used by the receiving PE for 944 identifying an individual ATM PW within a GRE/IP tunnel. Multiple PWs 945 with unique GRE Keys can be multiplexed into a GRE/IP tunnel. The 946 method by which the Key field value is negotiated between the 947 transmitting PE and a receiving PE is further study. 949 12.4 GRE Sequence Number Field 951 If the Sequence Number Present bit is set to 1, then it indicates 952 that the Sequence Number field is present in the GRE header. 953 Otherwise, the Sequence Number field is not present in the GRE 954 header. The use of the Sequence Number field MUST comply to [14]. 956 A specific ATM PWE network may choose to rely on the GRE protocol to 957 track in-order delivery of ATM PW packets. Another way of tracking 958 in-order delivery is to use the PW Sequence number field as explained 959 in Section 5.1. 961 13. Security Considerations 963 No additional security issues are introduced in this document. As 964 ATM encapsulation to MPLS packet is related to MPLS. AAL5 frame 965 encapsulation shares the security concerns associated with MPLS. 967 14. References 969 [1} Bradner, S., "The Internet Standards Process -- Revision 3", BCP 970 9, RFC 2026, October 1996. 972 [2] ITU-T Recommendation I.371 (2000), Traffic control and 973 congestion control in B-ISDN. 975 [3] ATM Forum Specification af-tm-0121.000 (1999), Traffic 976 Management Specification Version 4.1. 978 [4] IETF draft-fischer-pwe3-atm-service-03.txt(March 2002, work in 979 progress), PWE3: ATM service description 981 [5] ITU-T Recommendation I.610, (1999), B-ISDN operation and 982 maintenance principles and functions. 984 [6] IETF draft-ietf-pwe3-requirements-02.txt (November 2001, work in 985 progress,), Requirements for pseudo Wire Emulation Edge-to-Edge 986 (PWE3). 988 [7] IETF draft-martini-l2circuit-encap-mpls-04.txt Martini (November 989 2001, Work in Progress), Encapsulation Methods for Transport of 990 Layer 2 Frames Over IP and MPLS Networks. 992 [8] IETF draft-koleyni-pwe3-atm-over-mpls-04.txt (January 2002, Work 993 in Progress), Requirements and framework for ATM network 994 interworking over MPLS 996 [9] IETF RFC 3032 (2001), MPLS Label Stack Encoding. 998 [10] ATM Forum af-aic-0178.000 (2001), ATM-MPLS Network Interworking. 1000 [11] IETF draft-ietf-l2tpext-l2tp-base-01.txt (October 2001, Work in 1001 Progress), Layer Two Tunneling Protocol (L2TP). 1003 [12] IETF RFC 2661 (1999), Layer Two Tunneling Layer Two Tunneling 1004 Protocol (L2TP). 1006 [13] IETF RFC 2784(2000), Generic Routing Encapsulation (GRE). 1008 [14] IETF RFC 2890(2000), Key and Sequence Number Extensions to GRE. 1010 [15] IETF draft-ietf-mpls-diff-ext-09.txt (April 2001, Work in 1011 Progress), MPLS Support of Differentiated Services. 1013 [16] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1014 Levels", BCP 14, RFC 2119, March 1997. 1016 15. Acknowledgements 1018 The authors like to acknowledge the contribution to this work by: TBD 1020 16. Author's Addresses 1022 John Fischer 1023 Alcatel 1024 600 March Rd 1025 Kanata, ON, Canada. K2K 2E6 1026 Email: john.fischer@alcatel.com 1028 Matthew Bocci 1029 Alcatel 1030 Grove House, Waltham Road Rd 1031 White Waltham, Berks, UK. SL6 3TN 1032 Email: matthew.bocci@alcatel.co.uk 1034 Mustapha Aissaoui 1035 Alcatel 1036 600 March Rd 1037 Kanata, ON, Canada. K2K 2E6 1038 Email: mustapha.aissaoui@alcatel.com 1040 Ghassem Koleyni 1041 Nortel Networks 1042 P O Box 3511, Station C Ottawa, Ontario, 1043 K1Y 4H7 Canada 1044 Email: ghassem@nortelnetworks.com 1046 Full Copyright Statement 1048 "Copyright (C) The Internet Society (May 2002). All Rights Reserved. 1049 This document and translations of it may be copied and furnished to 1050 others, and derivative works that comment on or otherwise explain it 1051 or assist in its implementation may be prepared, copied, published 1052 and distributed, in whole or in part, without restriction of any 1053 kind, provided that the above copyright notice and this paragraph 1054 are included on all such copies and derivative works. However, this 1055 document itself may not be modified in any way, such as by removing 1056 the copyright notice or references to the Internet Society or other 1057 Internet organizations, except as needed for the purpose of 1058 developing Internet standards in which case the procedures for 1059 copyrights defined in the Internet Standards process must be 1060 followed, or as required to translate it into