idnits 2.17.00 (12 Aug 2021) /tmp/idnits49552/draft-ietf-pwe3-arch-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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. RFC 2119 keyword, line 1251: '... performance, it MAY be used to obtain...' RFC 2119 keyword, line 1269: '... MUST define whether the packet's ch...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 260 has weird spacing: '...Edge to att...' == Line 940 has weird spacing: '...ied "in band"...' -- 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 (November 2002) is 7126 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: 'Figure 3' is mentioned on line 1104, but not defined == Missing Reference: 'LDPMIB' is mentioned on line 1573, but not defined == Unused Reference: 'LDP-MIB' is defined on line 1669, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ETSI' -- Possible downref: Non-RFC (?) normative reference: ref. 'LDP-MIB' == Outdated reference: draft-ietf-mpls-lsr-mib has been published as RFC 3813 -- Possible downref: Non-RFC (?) normative reference: ref. 'L2TPv3' -- Possible downref: Non-RFC (?) normative reference: ref. 'PPPoL2TP' == Outdated reference: draft-ietf-pwe3-pw-mib has been published as RFC 5601 == Outdated reference: draft-ietf-pwe3-pw-tc-mib has been published as RFC 5542 == Outdated reference: draft-ietf-pwe3-cep-mib has been published as RFC 6240 ** Obsolete normative reference: RFC 1889 (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 1902 (Obsoleted by RFC 2578) ** Downref: Normative reference to an Informational RFC: RFC 1958 ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 3022 ** Obsolete normative reference: RFC 2558 (ref. 'SONETMIB') (Obsoleted by RFC 3592) == Outdated reference: draft-ietf-mpls-te-mib has been published as RFC 3812 == Outdated reference: A later version (-04) exists of draft-lasserre-vkompella-ppvpn-vpls-02 -- Possible downref: Normative reference to a draft: ref. 'VPLS' == Outdated reference: draft-ietf-pwe3-requirements has been published as RFC 3916 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-requirements (ref. 'XIAO') Summary: 11 errors (**), 0 flaws (~~), 14 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Pseudo-Wire Edge-to-Edge (PWE3) Working Group Stewart Bryant 2 Internet Draft Cisco Systems 3 Document: 4 Expires: May 2003 Prayson Pate 5 Overture Networks, Inc. 7 Editors 9 November 2002 11 PWE3 Architecture 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt The list of 29 Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes an architecture for Pseudo Wire Emulation 35 Edge-to-Edge (PWE3). It discusses the emulation of services (such as 36 Frame Relay, ATM, Ethernet TDM and SONET/SDH) over packet switched 37 networks (PSNs) using IP or MPLS. It presents the architectural 38 framework for pseudo wires (PWs), defines terminology, specifies the 39 various protocol elements and their functions. 41 Co-Authors 43 The following are co-authors of this document: 45 Thomas K. Johnson Litchfield Communications 46 Kireeti Kompella Juniper Networks, Inc. 47 Andrew G. Malis Vivace Networks 48 Danny McPherson TCB 49 Thomas D. Nadeau Cisco Systems 50 Tricci So Caspian Networks 51 W. Mark Townsley Cisco Systems 52 Craig White Level 3 Communications, LLC. 53 Lloyd Wood Cisco Systems 54 XiPeng Xiao Redback Networks 56 Table of Contents 58 Status of this Memo.......................................... 1 60 1. Introduction............................................. 5 61 1.1 Pseudo Wire Definition............................... 5 62 1.2 PW Service Functionality............................. 6 63 1.3 Non-Goals of this document........................... 6 64 1.4 Terminology.......................................... 6 66 2. PWE3 Applicability....................................... 9 68 3. Protocol Layering Model.................................. 9 69 3.1 Protocol Layers...................................... 9 70 3.2 Domain of PWE3....................................... 10 71 3.3 Payload Types........................................ 10 73 4. Architecture of Pseudo-wires............................. 14 74 4.1 Network Reference Model.............................. 14 75 4.2 PWE3 Pre-processing.................................. 15 76 4.3 Maintenance Reference Model.......................... 19 77 4.4 Protocol Stack Reference Model....................... 19 78 4.5 Pre-processing Extension to Protocol Stack........... 79 Reference Model...................................... 20 81 5. PW Encapsulation......................................... 21 82 5.1 Payload Convergence Layer............................ 22 83 5.2 Payload-independent PW Encapsulation Layers.......... 24 84 5.3 Fragmentation........................................ 27 85 5.4 Instantiation of the Protocol Layers................. 27 87 6. PW Demultiplexer Layer and PSN Requirements.............. 30 88 6.1 Multiplexing......................................... 30 89 6.2 Fragmentation........................................ 30 90 6.3 Length and Delivery.................................. 30 91 6.4 PW-PDU Validation.................................... 31 92 6.5 Congestion Considerations............................ 31 94 7. Control Plane............................................ 31 95 7.1 Set-up or Teardown of Pseudo-Wires................... 31 96 7.2 Status Monitoring.................................... 32 97 7.3 Notification of Pseudo-wire Status Changes........... 32 98 7.4 Keep-alive........................................... 34 99 7.5 Handling Control Messages of the Native Services..... 34 101 8. Management and Monitoring................................. 34 102 8.1 Statistics........................................... 34 103 8.2 PW SNMP MIB Architecture............................. 35 104 8.3 Connection Verification and Traceroute................ 38 106 9. IANA considerations...................................... 38 108 10. Security Considerations................................. 38 109 10.1 PW Tunnel End-Point and PW Demultiplexer Security... 38 110 10.2 Validation of PW Encapsulation...................... 39 112 1. Introduction 114 This document describes an architecture for Pseudo Wire Emulation 115 Edge-to-Edge (PWE3) in support of [XIAO]. It discusses the emulation 116 of services (such as Frame Relay, ATM, Ethernet TDM and SONET/SDH) 117 over packet switched networks (PSNs) using IP or MPLS. It presents 118 the architectural framework for pseudo wires (PWs), defines 119 terminology, specifies the various protocol elements and their 120 functions. 122 1.1 Pseudo Wire Definition 124 PWE3 is a mechanism that emulates the essential attributes of a 125 service (such as a T1 leased line or Frame Relay) over a PSN. PWE3 is 126 intended to provide only the minimum necessary functionality to 127 emulate the wire with the required degree of faithfulness for the 128 given service definition. Any required switching functionality is the 129 responsibility of a forwarder function (FWRD). Any translation or 130 other operation needing knowledge of the payload semantics is carried 131 out by native service processing (NSP) elements. The functional 132 definition of any FWRD or NSP elements is outside the scope of PWE3. 134 The required functions of PWs include encapsulating service-specific 135 bit-streams, cells or PDUs arriving at an ingress port, and carrying 136 them across a path or tunnel. In some cases it is necessary to 137 perform other operation such as managing their timing and order, to 138 emulate the behavior and characteristics of the service to the 139 required degree of faithfulness. 141 From the perspective of a Customer Edge Equipment (CE), the PW is 142 characterised as an unshared link or circuit of the chosen service. 143 In some cases, there may be deficiencies in the PW emulation that 144 impact the traffic carried over a PW, and hence limit the 145 applicability of this technology. These limitations must be fully 146 described in the appropriate service-specific documentation. It is 147 possible that these limitations may lead to the definition of more 148 than one PW emulation method, each providing a different degree of 149 faithfulness. 151 1.2 PW Service Functionality 153 PWs provide the following functions in order to emulate the behavior 154 and characteristics of the native service. 155 o Encapsulation of service-specific PDUs or circuit data arriving 156 at the ingress port (logical or physical). 157 o Carriage of the encapsulated data across a PSN tunnel. 158 o Establishment of the PW including the exchange and/or 159 distribution of the PW identifiers used by the PSN 160 tunnel endpoints. 161 o Managing the signaling, timing, order or other aspects of the 162 service at the boundaries of the PW. 163 o Service-specific status and alarm management. 165 1.3 Non-Goals of this document 167 The following are non-goals for this document: 169 o The on-the-wire specification of services encapsulation. 170 o The detailed definition of the protocols involved in PW 171 setup and maintenance. 173 The following are outside the scope of PWE3: 174 o Any multicast service not native to the emulated medium. 175 Thus, Ethernet transmission to a "multicast" IEEE-48 address 176 is in scope, while multicast services like MARS [RFC2022] that 177 are implemented on top of the medium are out of scope. 178 o Methods to signal or control the underlying PSN. 180 1.4 Terminology 182 Editor's note: Although it was decided at IETF-54 that the PWE3 183 common terminology should be published in a separate document, there 184 is case for it remaining in the architecture document. If the PWE3-WG 185 confirms the desire to have a separate document, we will remove this 186 section in the next revision. 188 This document uses the following definitions of terms. These terms 189 are illustrated in context in Figure 2. 191 Attachment Circuit The circuit or virtual circuit attaching 192 (AC) a CE to a PE. 194 Applicability Each PW service will have an Applicability 195 Statement (AS) Statement (AS) that describes the applicability 196 of PWs for that service. 198 CE-bound The traffic direction where PW-PDUs are 199 received on a PW via the PSN, processed 200 and then sent to the destination CE. 202 CE Signaling Messages sent and received by the CEs 203 control plane. It may be desirable or 204 even necessary for the PE to participate 205 in or monitor this signaling in order 206 to effectively emulate the service. 208 Customer Edge (CE) A device where one end of a service 209 originates and/or terminates. The CE is not 210 aware that it is using an emulated service 211 rather than a native service. 213 Forwarder (FWRD) A PE subsystem that selects the PW to use to 214 transmit a payload received on an AC. 216 Fragmentation The action of dividing a single PDU into 217 multiple PDUs before transmission with the 218 intent of the original PDU being reassembled 219 elsewhere in the network. Fragmentation may be 220 performed in order to allow sending of packets 221 of a larger size than the network MTU which 222 they will traverse. 224 Maximum transmission The packet size (excluding data link header) 225 unit (MTU) that an interface can transmit without 226 needing to fragment. 228 Native Service Processing of the data received by the PE 229 Processing (NSP) from the CE before presentation to the PW 230 for transmission across the core. 232 Packet Switched Within the context of PWE3, this is a 233 Network (PSN) network using IP or MPLS as the mechanism 234 for packet forwarding. 236 Protocol Data The unit of data output to, or received 237 Unit (PDU) from, the network by a protocol layer. 239 Provider Edge (PE) A device that provides PWE3 to a CE. 241 PE-bound The traffic direction where information 242 from a CE is adapted to a PW, and PW-PDUs 243 are sent into the PSN. 245 PE/PW Maintenance Used by the PEs to set up, maintain and 246 tear down the PW. It may be coupled with 247 CE Signaling in order to effectively manage 248 the PW. 250 Pseudo Wire (PW) A mechanism that carries the essential 251 elements of an emulated service from one PE 252 to one or more other PEs over a PSN. 254 PW End Service The interface between a PE and a CE. This 255 (PWES) can be a physical interface like a T1 or 256 Ethernet, or a virtual interface like a VC 257 or VLAN. 259 Pseudo Wire A mechanism that emulates the essential 260 Emulation Edge to attributes of service (such as a T1 leased 261 Edge (PWE3) line or frame relay) over a PSN. 263 Pseudo Wire PDU A PDU sent on the PW that contains all of 264 (PW-PDU) the data and control information necessary 265 to emulate the desired service. 267 PSN Tunnel A tunnel across a PSN inside which one or 268 more PWs can be carried. 270 PSN Tunnel Used to set up, maintain and tear down the 271 Signaling underlying PSN tunnel. 273 PW Demultiplexer Data-plane method of identifying a PW 274 terminating at a PE. 276 Time Domain Synchronous bit-streams at rates defined by 277 Multiplexing (TDM) G.702. 279 Tunnel A method of transparently carrying information 280 over a network. 282 2. PWE3 Applicability 284 The PSN carrying a PW will subject payload packets to delay, jitter, 285 network transients and re-ordering. The applicability of PWE3 to a 286 particular service depends on the sensitivity of that service to 287 these effects, and the ability of the adaptation layer to mask them. 288 Some services, such as IP over FR over PWE3, may prove quite 289 resilient to IP and MPLS PSN characteristics. Other services, such as 290 the interconnection of PBX systems via PWE3, will require more 291 careful consideration of the PSN and adaptation layer 292 characteristics. In some instances, traffic engineering of the 293 underlying PSN will be required, and in some cases the constraints 294 may be such that it is not possible to provide the required service 295 guarantees. 297 3. Protocol Layering Model 299 The PWE3 protocol-layering model is intended to minimise the 300 differences between PWs operating over different PSN types. The 301 design of the protocol-layering model has the goals of making each PW 302 definition independent of the underlying PSN, and maximizing the 303 reuse of IETF protocol definitions and their implementations. 305 3.1 Protocol Layers 307 The logical protocol-layering model required to support a PW is shown 308 in Figure 1. 310 +---------------------------+ 311 | Payload | 312 +---------------------------+ 313 | Encapsulation | <==== May be empty 314 +---------------------------+ 315 | PW Demultiplexer | 316 +---------------------------+ 317 | PSN Convergence | <==== May be empty 318 +---------------------------+ 319 | PSN | 320 +---------------------------+ 321 | MAC/Data-link | 322 +---------------------------+ 323 | Physical | 324 +---------------------------+ 326 Figure 1: Logical Protocol Layering Model 328 The payload is transported over the Encapsulation Layer. The 329 Encapsulation Layer carries any information, not already present 330 within the payload itself, that is needed by the PW CE-bound PE 331 interface to send the payload to the CE via the physical interface. 332 If no information is needed beyond that in the payload itself, this 333 layer is empty. 335 This layer also provides support for real-time processing, and 336 sequencing, if needed. 338 The PW Demultiplexer Layer provides the ability to deliver multiple 339 PWs over a single PSN tunnel. The PW demultiplexer value used to 340 identify the PW in the data-plane may be unique per PE, but this is 341 not a PWE3 requirement. It must, however, be unique per tunnel 342 endpoint. If it is necessary to identify a particular tunnel, then 343 that is the responsibility of the PSN layer. 345 The PSN Convergence Layer provides the enhancements needed to make 346 the PSN conform to the assumed PSN service requirement. This layer 347 therefore provides a consistent interface to the PW, making the PW 348 independent of the PSN type. If the PSN already meets the service 349 requirements, this layer is empty. 351 The PSN header, MAC/Data-link and Physical Layer definitions are 352 outside the scope of this document. The PSN can be IPv4, IPv6 or 353 MPLS. 355 3.2 Domain of PWE3 357 PWE3 defines the Encapsulation Layer, the method of carrying various 358 payload types, and the interface to the PW Demultiplexer Layer. It 359 is expected that the other layers will be provided by tunneling 360 methods such as L2TP or MPLS over the PSN. 362 3.3 Payload Types 364 The payload is classified into the following generic types of native 365 data unit: 367 o Packet 368 o Cell 369 o Bit-stream 370 o Structured bit-stream 372 Within these generic types there are specific service types. For 373 example: 375 Generic Payload Type PW Service 376 -------------------- ---------- 377 Packet Ethernet (all types), HDLC, 378 frame-relay, ATM AAL5 PDU. 380 Cell ATM. 382 Bit-stream SONET, TDM (e.g. DS1, DS3, E1). 384 Structured bit-stream SONET, TDM. 386 3.3.1. Packet Payload 388 A packet payload is a variable-size data unit presented to the PE on 389 the AC. A packet payload may be large compared to the PSN MTU. The 390 delineation of the packet boundaries is encapsulation-specific. HDLC 391 or Ethernet PDUs can be considered as examples of packet payloads. 392 Typically a packet will be stripped of transmission overhead such as 393 HDLC flags and stuffing bits before transmission over the PW. 395 A packet payload would normally be relayed across the PW as a single 396 unit. However, there will be cases where the combined size of the 397 packet payload and its associated PWE3 and PSN headers exceeds the 398 PSN path MTU. In these cases, some fragmentation methodology needs 399 to be applied. This may, for example, be the case when a user is 400 providing the service and attaching to the service provider via an 401 Ethernet, or where nested pseudo-wires are involved. Fragmentation is 402 discussed in more detail in Section 5.3 404 A packet payload may need sequencing and real-time support. 406 In some situations, the packet payload may be selected from the 407 packets presented on the emulated wire on the basis of some sub- 408 multiplexing technique. For example, one or more frame-relay PDUs 409 may be selected for transport over a particular pseudo-wire based on 410 the frame-relay Data-Link Connection Identifier (DLCI), or, in the 411 case of Ethernet payloads, on the basis of the VLAN identifier. This 412 is an FWRD function, and this selection would therefore be made 413 before the packet was presented to the PW Encapsulation Layer. 415 3.3.2. Cell Payload 417 A cell payload is created by capturing, transporting and replaying 418 groups of bits presented on the wire in a fixed-size format. The 419 delineation of the group of bits that comprise the cell is specific 420 to the encapsulation type. Two common examples of cell payloads are 421 ATM 53-octet cells, and the larger 188-octet MPEG Transport Stream 422 packets [ETSI]. 424 To reduce per-PSN packet overhead, multiple cells may be concatenated 425 into a single payload. The Encapsulation Layer may consider the 426 payload complete on the expiry of a timer, after a fixed number of 427 cells have been received or when a significant cell (e.g. an ATM OAM 428 cell) has been received. The benefit of concatenating multiple PDUs 429 should be weighed against the resulting increase in jitter and the 430 larger penalty incurred by packet loss. In some cases, it may be 431 appropriate for the Encapsulation Layer to perform a silence 432 suppression or a similar compression. 434 The generic cell payload service will normally need sequence number 435 support, and may also need real-time support. The generic cell 436 payload service would not normally require fragmentation. 438 The Encapsulation Layer may apply some form of compression to some of 439 these sub-types (e.g. idle cells may be suppressed). 441 In some instances, the cells to be incorporated in the payload may be 442 selected by filtering them from the stream of cells presented on the 443 wire. For example, an ATM PWE3 service may select cells based on 444 their VCI or VPI fields. This is an FWRD function, and the selection 445 would therefore be made before the packet was presented to the PW 446 Encapsulation Layer. 448 3.3.3. Bit-stream 450 A bit-stream payload is created by capturing, transporting and 451 replaying the bit pattern on the emulated wire, without taking 452 advantage of any structure that, on inspection, may be visible within 453 the relayed traffic (i.e. the internal structure has no effect on the 454 fragmentation into packets). 456 In some instances it is possible to apply suppression to bit-streams. 457 For example, E1 and T1 send "all-ones" to indicate failure. This 458 condition can be detected without any knowledge of the structure of 459 the bit-stream, and transmission of packetized data suppressed. 461 This service will require sequencing and real-time support. 463 3.3.4. Structured bit-stream 465 A structured bit-stream payload is created by using some knowledge of 466 the underlying structure of the bit-stream to capture, transport and 467 replay the bit pattern on the emulated wire. 469 Two important points distinguish structured and unstructured bit- 470 streams: 472 o Some part of the original bit-stream are stripped in 473 the PSN-bound direction by NSP block. For example, 474 in Structured SONET the section and line overhead (and, 475 possibly, more) may be stripped. 477 o The PW must preserve the structure across the PSN so that 478 the CE-bound NSP block can insert it correctly into the 479 reconstructed unstructured bit-stream. 481 The Encapsulation Layer may also perform silence/idle suppression or 482 similar compression on a structured bit-stream. 484 Structured bit-streams are distinguished from cells in that the 485 structures may be too long to be carried in a single packet. Note 486 that "short" structures are indistinguishable from cells and may 487 benefit from the use of those PWE3 methods. 489 This service will require sequencing and real-time support. 491 3.3.5. Principle of Minimum Intervention 493 To minimise the scope of information, and to improve the efficiency 494 of data flow through the Encapsulation Layer, the payload should be 495 transported as received with as few modifications as possible 496 [RFC1958]. 498 This minimum intervention approach decouples payload development from 499 PW development and requires fewer translations at the NSP in a system 500 with similar CE interfaces at each end. It also prevents unwanted 501 side-effects due to subtle mis-representation of the payload in the 502 intermediate format. 504 An intervention approach can be more wire-efficient in some cases and 505 may result in fewer translations at the NSP where the CE interfaces 506 are of different types. Any intermediate format effectively becomes a 507 new framing type, requiring documentation and assured 508 interoperability. This increases the amount of work for handling the 509 protocol the intermediate format carries, and is undesirable. 511 4. Architecture of Pseudo-wires 513 This section describes the PWE3 architectural model. 515 4.1 Network Reference Model 517 Figure 2 illustrates the network reference model for point-to-point 518 PWs. 520 |<-------------- Emulated Service ---------------->| 521 | | 522 | |<------- Pseudo Wire ------>| | 523 | | | | 524 | | |<-- PSN Tunnel -->| | | 525 | PW End V V V V PW End | 526 V Service +----+ +----+ Service V 527 +-----+ | | PE1|==================| PE2| | +-----+ 528 | |----------|............PW1.............|----------| | 529 | CE1 | | | | | | | | CE2 | 530 | |----------|............PW2.............|----------| | 531 +-----+ ^ | | |==================| | | ^ +-----+ 532 ^ | +----+ +----+ | | ^ 533 | | Provider Edge 1 Provider Edge 2 | | 534 | | | | 535 Customer | | Customer 536 Edge 1 | | Edge 2 537 | | 538 | | 539 native service native service 541 Figure 2: PWE3 Network Reference Model 543 The two PEs (PE1 and PE2) need to provide one or more PWs on behalf 544 of their client CEs (CE1 and CE2) to enable the client CEs to 545 communicate over the PSN. A PSN tunnel is established to provide a 546 data path for the PW. The PW traffic is invisible to the core 547 network, and the core network is transparent to the CEs. Native data 548 units (bits, cells or packets) presented at the PW End Service (PWES) 549 are encapsulated in a PW-PDU and carried across the underlying 550 network via the PSN tunnel. The PEs perform the necessary 551 encapsulation and decapsulation of PW-PDUs, as well as handling any 552 other functions required by the PW service, such as sequencing or 553 timing. 555 There are situations in which a particular packet payload needs to be 556 multicast so that it is received by a number of CEs. This is useful 557 when using PWs as part of a "virtual LAN" service (see, e.g., 559 [VPLS]). This can be achieved by replicating the payload and 560 transmitting the replicas on PWs, but it may also be useful to have a 561 type of PW that is inherently point-to-multipoint. In that case, the 562 PW would need to be carried through a point-to-multipoint PSN tunnel, 563 employing a multicast mechanism provided by the PSN. 565 4.2 PWE3 Pre-processing 567 In some applications, there is a need to perform operations on the 568 native data units received from the CE (including both payload and 569 signaling traffic) before they are transmitted across the PW by the 570 PE. Examples include Ethernet bridging, SONET cross-connect, 571 translation of locally-significant identifiers such as VCI/VPI, or 572 translation to another service type. These operations could be 573 carried out in external equipment, and the processed data sent to the 574 PE over one or more physical interfaces. In most cases, there are 575 cost and operational benefits in undertaking these operations within 576 the PE. This processed data is then presented to the PW via a 577 virtual interface within the PE. 579 These pre-processing operations are included in the PWE3 reference 580 model to provide a common reference point, but the detailed 581 description of these operations is outside the scope of the PW 582 definition given here. 584 PW 585 End Service 586 | 587 |<------- Pseudo Wire ------>| 588 | | 589 | |<-- PSN Tunnel -->| | 590 V V V V PW 591 +-----+----+ +----+ End Service 592 +-----+ |PREP | PE1|==================| PE2| | +-----+ 593 | | | |............PW1.............|----------| | 594 | CE1 |----| | | | | | | CE2 | 595 | | ^ | |............PW2.............|----------| | 596 +-----+ | | | |==================| | | ^ +-----+ 597 | +-----+----+ +----+ | | 598 | ^ | | 599 | | | | 600 | |<------- Emulated Service ------->| | 601 | | | 602 | Virtual physical | 603 | termination | 604 | ^ | 605 CE1 native | CE2 native 606 service | service 607 | 608 CE2 native 609 service 611 Figure 3: Pre-processing within the PWE3 Network Reference Model 613 Figure 3 shows the inter-working of one PE with pre-processing 614 (PREP), and a second without this functionality. This is a useful 615 reference point because it emphasises that the functional interface 616 between PREP and the PW is that represented by a physical interface 617 carrying the service. This effectively defines the necessary inter- 618 working specification. 620 The operation of a system in which both PEs include PREP 621 functionality is also supported. 623 The required pre-processing can be divided into two components: 624 o Forwarder (FWRD) 626 o Native Service Processing (NSP) 628 4.2.1. Forwarders 630 In some applications there is the need to selectively forward payload 631 elements from one of more ACs to one or more PWs. In such cases there 632 will also be the need to perform the inverse function on PWE3-PDUs 633 received by a PE from the PSN. This is the function of the FWRD. 635 The FWRD selects the PW based on, for example: the incoming AC, the 636 contents of the payload, or some statically- or dynamically- 637 configured forwarding information. 639 +----------------------------------------+ 640 | PE Device | 641 +----------------------------------------+ 642 Single | | | 643 PWES | | Single | PW Instance 644 <------>o Forwarder + PW Instance X<===========> 645 | | | 646 +----------------------------------------+ 648 Figure 4a: Simple point-to-point service 650 +----------------------------------------+ 651 | PE Device | 652 +----------------------------------------+ 653 Multiple| | Single | PW Instance 654 PWES | + PW Instance X<===========> 655 <------>o | | 656 | |----------------------| 657 <------>o | Single | PW Instance 658 | + PW Instance X<===========> 659 <------>o | | 660 | Forwarder |----------------------| 661 <------>o | Single | PW Instance 662 | + PW Instance X<===========> 663 <------>o | | 664 | |----------------------| Multipoint 665 | | Multipoint | PW Instance 666 | + PW Instance X<===========> 667 | | | 668 +----------------------------------------+ 670 Figure 4b: Multiple PWEs to Multiple PW Forwarding 672 Figure 4a shows a simple FWRD that performs some type of filtering 673 operation. Because the FWRD has a single input and a single output 674 interface, filtering is the only type of forwarding operation that 675 applies. Figure 4b shows a more general forwarding situation where 676 payloads are extracted from one or more PWESs and directed to one or 677 more PWs, including, in this instance, a multipoint PW. In this case 678 both filtering and direction operations may be performed on the 679 payloads. 681 4.2.2. Native Service Processing 683 In some applications some form of data or address translation, or 684 other operation requiring knowledge of the semantics of the payload, 685 will be required. This is the function of the Native Service 686 Processor (NSP). 688 The use of the NSP approach simplifies the design of the PW by 689 restricting a PW to homogeneous operation. NSP is included in the 690 reference model to provide a defined interface to this functionality. 691 The specification of the various types of NSP is outside the scope of 692 PWE3. 694 +----------------------------------------+ 695 | PE Device | 696 Multiple+----------------------------------------+ 697 PWES | | | Single | PW Instance 698 <------>o NSP # + PW Instance X<===========> 699 | | | | 700 |------| |----------------------| 701 | | | Single | PW Instance 702 <------>o NSP # + PW Instance X<===========> 703 | | | | 704 |------|Forwarder |----------------------| 705 | | | Single | PW Instance 706 <------>o NSP # + PW Instance X<===========> 707 | | | | 708 |------| |----------------------| Multipoint 709 | | | Multipoint | PW Instance 710 <------>o NSP # + PW Instance X<===========> 711 | | | | 712 +----------------------------------------+ 714 Figure 5: NSP in a Multiple PWEs to Multiple 715 PW Forwarding PE 717 Figure 5 illustrates the relationship between NSP, FWRD and PWs in a 718 PE. The NSP function may apply any transformation operation 719 (modification, injection, etc.) on the payloads as they pass between 720 the physical interface to the CE and the virtual interface to the 721 FWRD. A PE device may contain more than one FWRD. 723 This model also supports the operation of a system in which the NSP 724 functionality includes terminating the data-link and applying Network 725 Layer processing to the payload is also supported. 727 4.3 Maintenance Reference Model 729 Figure 6 illustrates the maintenance reference model for PWs. 731 |<------- CE (end-to-end) Signaling ------>| 732 | |<---- PW/PE Maintenance ----->| | 733 | | |<-- PSN Tunnel -->| | | 734 | | | Signaling | | | 735 | V V (out of scope) V V | 736 v +-----+ +-----+ v 737 +-----+ | PE1 |==================| PE2 | +-----+ 738 | |-----|.............PW1..............|-----| | 739 | CE1 | | | | | | CE2 | 740 | |-----|.............PW2..............|-----| | 741 +-----+ | |==================| | +-----+ 742 +-----+ +-----+ 743 Customer Provider Provider Customer 744 Edge 1 Edge 1 Edge 2 Edge 2 746 Figure 6: PWE3 Maintenance Reference Model 748 The following signaling mechanisms are required: 750 o The CE (end-to-end) signaling is between the CEs. This 751 signaling could be frame relay PVC status signaling, ATM SVC 752 signaling, etc. 754 o The PW/PE Maintenance is used between the PEs (or NSPs) to set 755 up, maintain and tear down PWs, including any required 756 coordination of parameters. 758 o The PSN Tunnel signaling controls the PW multiplexing and some 759 elements of the underlying PSN. Examples are L2TP control 760 protocol, MPLS LDP and RSVP-TE. The definition of the 761 information that PWE3 needs to be signaled is within the scope 762 of PWE3, but the signaling protocol itself is not. 764 4.4 Protocol Stack Reference Model 766 Figure 7 illustrates the protocol stack reference model for PWs. 768 +-----------------+ +-----------------+ 769 |Emulated Service | |Emulated Service | 770 |(e.g. TDM, ATM) |<==== Emulated Service ===>|(e.g. TDM, ATM) | 771 +-----------------+ +-----------------+ 772 | Payload | | Payload | 773 | Encapsulation |<====== Pseudo Wire ======>| Encapsulation | 774 +-----------------+ +-----------------+ 775 |PW Demultiplexer | |PW Demultiplexer | 776 | PSN Tunnel, |<======= PSN Tunnel ======>| PSN Tunnel, | 777 | PSN & Physical | | PSN & Physical | 778 | Layers | | Layers | 779 +-------+---------+ ___________ +---------+-------+ 780 | / \ | 781 +===============/ PSN \===============+ 782 \ / 783 \_____________/ 785 Figure 7: PWE3 Protocol Stack Reference Model 787 The PW provides the CE with an emulated physical or virtual 788 connection to its peer at the far end. Native service PDUs from the 789 CE are passed through an Encapsulation Layer at the sending PE, and 790 then sent over the PSN. The receiving PE removes the encapsulation 791 and restores the payload to its native format for transmission to the 792 destination CE. 794 4.5 Pre-processing Extension to Protocol Stack Reference Model 796 Figure 8 illustrates how the protocol stack reference model is 797 extended to include the provision of pre-processing (Forwarding and 798 NSP). This shows the ideal placement of the physical interface 799 relative to the CE. 801 /======================================\ 802 H Forwarder H<----Pre-processing 803 H----------------======================/ 804 H Native Service H | | 805 H Processing H | | 806 \================/ | | 807 | | | Emulated | 808 | Service | | Service | 809 | Interface | | (TDM, ATM, | 810 | (TDM, ATM, | | Ethernet, |<== Emulated Service == 811 | Ethernet, | | frame relay, | 812 | frame relay, | | etc.) | 813 | etc.) | +-----------------+ 814 | | | Payload | 815 | | | Encapsulation |<=== Pseudo Wire ====== 816 | | +-----------------+ 817 | | |PW Demultiplexer | 818 | | | PSN Tunnel, | 819 | | | PSN & Physical |<=== PSN Tunnel ======= 820 | | | Headers | 821 +----------------+ +-----------------+ 822 | Physical | | Physical | 823 +-------+--------+ +-------+---------+ 824 | | 825 | | 826 | | 827 | | 828 | | 829 | | 830 To CE <---+ +---> To PSN 832 Figure 8: Protocol Stack Reference Model with Pre-processing 834 5. PW Encapsulation 836 The PW Encapsulation Layer provides the necessary infrastructure to 837 adapt the specific payload type being transported over the PW to the 838 PW Demultiplexer Layer that is used to carry the PW over the PSN. 840 The PW Encapsulation Layer consists of three sub-layers: 842 o Payload Convergence 843 o Timing 844 o Sequencing 846 The PW Encapsulation sub-layering and its context with the protocol 847 stack are shown, in Figure 9. 849 +---------------------------+ 850 | Payload | 851 /===========================\ <------ Encapsulation 852 H Payload Convergence H Layer 853 H---------------------------H 854 H Timing H 855 H---------------------------H 856 H Sequencing H 857 \===========================/ 858 | PW Demultiplexer | 859 +---------------------------+ 860 | PSN Convergence | 861 +---------------------------+ 862 | PSN | 863 +---------------------------+ 864 | MAC/Data-link | 865 +---------------------------+ 866 | Physical | 867 +---------------------------+ 869 Figure 9: PWE3 Encapsulation Layer in Context 871 The Payload Convergence Sub-layer is highly tailored to the specific 872 payload type, but, by grouping a number of target payload types into 873 a generic class, and then providing a single convergence sub-layer 874 type common to the group, we achieve a reduction in the number of 875 payload convergence sub-layer types. This decreases implementation 876 complexity. The provision of per-packet signaling and other out-of- 877 band information (other than sequencing or timing) is undertaken by 878 this layer. 880 The Timing Layer and the Sequencing Layer provide generic services to 881 the Payload Convergence Layer for all payload types, when required. 883 5.1 Payload Convergence Layer 885 5.1.1. Encapsulation 887 The primary task of the Payload Convergence Layer is the 888 encapsulation of the payload in PW-PDUs. The native data units to be 889 encapsulated may or may not contain a L2 header or L1 overhead. This 890 is service specific. The Payload Convergence header carries the 891 additional information needed to replay the native data units at the 892 CE-bound physical interface. The PW Demultiplexer header is not 893 considered as part of the PW header. 895 Not all the additional information needed to replay the native data 896 units need to be carried in the PW header of the PW PDUs. Some 897 information (e.g. service type of a PW) may be stored as state 898 information at the destination PE during PW set-up. 900 5.1.2. PWE3 Channel Types 902 The PW Encapsulation Layer and its associated signaling require one 903 or more of the following types of channels from its underlying PW 904 Demultiplexer and PSN Layers: 906 1. A reliable control channel for signaling line events, status 907 indications, and, in some exceptional cases, CE-CE events 908 that must be translated and sent reliably between PEs. 910 For example, this capability is needed in [PPPoL2TP] 911 (PPP negotiation has to be split between the two ends of the 912 tunnel). PWE3 may also need this type of control channel to 913 provide faithful emulation of complex data-link protocols. 915 plus one or more data channels with the following characteristics: 917 2. A high-priority, unreliable, sequenced channel. A typical use 918 is for CE-to-CE signaling. "High priority" may simply be 919 indicated via DSCP/EXP bits for priority during transit. 920 This channel type could also use a bit in the tunnel header 921 itself to indicate that packets received at the PE should be 922 processed with higher priority [RFC2474]. 924 3. A sequenced channel for data traffic that is sensitive to 925 packet reordering (one classification for use could be for 926 any non-IP traffic). 928 4. An un-sequenced channel for data traffic insensitive to packet 929 order. 931 The data channels (2, 3 and 4 above) should be carried "in band" with 932 one another to as much of a degree as is reasonably possible on a 933 PSN. 935 Where end-to-end connectivity may be disrupted by address translation 936 [RFC3022], access-control lists, firewalls etc., there exists the 937 possibility that the control channel may be able to pass traffic and 938 set up the PW, but the PW data traffic is blocked by one or more of 939 these mechanisms. In these cases unless the control channel is also 940 carried "in band" the signaling to set-up the PW will not confirm 941 the existence of an end-to-end data path. 943 In some cases there is a need to synchronize CE events with the data 944 carried over a PW. This is especially the case with TDM circuits 945 (e.g., the on-hook/off-hook events in PSTN switches might be carried 946 over a reliable control channel, whilst the associated bit-stream is 947 carried over a sequenced data channel). 949 PWE3 channel types that are not needed by the supported PWs need not 950 be included in such an implementation. 952 5.1.3. Quality of Service Considerations 954 Where possible, it is desirable to employ mechanisms to provide PW 955 Quality of Service (QoS) support over PSNs. 957 5.2 Payload-independent PW Encapsulation Layers 959 Two PWE3 Encapsulation Sub-layers provide common services to all 960 payload types: Sequencing and Timing. These services are optional 961 and are only used if needed by a particular PW instance. If the 962 service is not needed, the associated header may be omitted in order 963 to conserve processing and network resources. 965 There will be instances where a specific payload type will be 966 required to be transported with or without sequence and/or real-time 967 support. For example, an invariant of frame relay transport is the 968 preservation of packet order. Some frame-relay applications expect 969 in-order delivery, and may not cope with reordering of the frames. 970 However, where the frame relay service is itself only being used to 971 carry IP, it may be desirable to relax that constraint in return for 972 reduced per-packet processing cost. 974 The guiding principle is that, where possible, an existing IETF 975 protocol should be used to provide these services. Where a suitable 976 protocol is not available, the existing protocol should be extended 977 or modified to meet the PWE3 requirements, thereby making that 978 protocol available for other IETF uses. In the particular case of 979 timing, more than one general method may be necessary to provide for 980 the full scope of payload timing requirements. 982 5.2.1. Sequencing 984 The sequencing function provides three services: frame ordering, 985 frame duplication detection and frame loss detection. These services 986 allow the emulation of the invariant properties of a physical wire. 987 Support for sequencing depends on the payload type, and may be 988 omitted if not needed. 990 The size of the sequence-number space depends on the speed of the 991 emulated service, and the maximum time of the transient conditions in 992 the PSN. A sequence number space greater than approximately 2^16 may 993 therefore be needed to prevent the sequence number space wrapping 994 during the transient. 996 5.2.1.1 Frame Ordering 998 When packets carrying the PW-PDUs traverse a PSN, they may arrive out 999 of order at the destination PE. For some services, the frames 1000 (control frames, data frames, or both control and data frames) must 1001 be delivered in order. For such services, some mechanism must be 1002 provided for ensuring in-order delivery. Providing a sequence number 1003 in the sequence sub-layer header for each packet is one possible 1004 approach to out-of-sequence detection. Alternatively it can be noted 1005 that sequencing is a subset of the problem of delivering timed 1006 packets, and that a single combined mechanism such as [RFC1889] may 1007 be employed. 1009 There are two possible misordering strategies: 1011 o Drop misordered PW PDUs. 1013 o Try to sort PW PDUs into the correct order. 1015 The choice of strategy will depend on: 1017 o How critical the loss of packets is to the operation of 1018 the PW (e.g. the acceptable bit error rate). 1020 o The speeds of the PW and PSN. 1022 o The acceptable delay (since delay must be introduced to 1023 reorder) 1025 o The incidence of expected misordering. 1027 5.2.1.2 Frame Duplication Detection 1029 In rare cases, packets traversing a PW may be duplicated by the 1030 underlying PSN. For some services, frame duplication is not 1031 acceptable. For such services, some mechanism must be provided to 1032 ensure that duplicated frames will not be delivered to the 1033 destination CE. The mechanism may or may not be the same as the 1034 mechanism used to ensure in-order frame delivery. 1036 5.2.1.3 Frame Loss Detection 1038 A destination PE can determine whether a frame has been lost by 1039 tracking the sequence numbers of the received PW PDUs. 1041 In some instances, a destination PE will have to presume that a PW 1042 PDU is lost if it fails to arrive within a certain time. If a PW-PDU 1043 that has been processed as lost subsequently arrives, the destination 1044 PE must discard it. 1046 5.2.2. Timing 1048 A number of native services have timing expectations based on the 1049 characteristics of the networks that they were designed to travel 1050 over, and it can be necessary for the emulated service to duplicate 1051 these network characteristics as closely as possible, e.g. in 1052 delivering native traffic with the same jitter, bit-rate and timing 1053 characteristics as it was sent. 1055 In such cases, it is necessary for the receiving PE to play out the 1056 native traffic as it was received at the sending PE. This relies on 1057 either timing information sent between the two PEs, or in some case 1058 timing information received from an external reference. 1060 The Timing Sub-layer must therefore support two timing functions: 1061 clock recovery and timed payload delivery. A particular payload type 1062 may require either or both of these services. 1064 5.2.2.1 Clock Recovery 1066 Clock recovery is the extraction of output transmission bit timing 1067 information from the delivered packet stream, and requires a suitable 1068 mechanism. A physical wire provides this naturally, but it is a 1069 relatively complex task to extract this from a highly jittered source 1070 such as packet stream. It is therefore desirable that an existing 1071 real-time protocol such as [RFC1889] be used for this purpose, unless 1072 it can be shown that this is unsuitable or unnecessary for a 1073 particular payload type. 1075 5.2.2.2 Timed delivery 1077 Timed delivery is the delivery of non-contiguous PW PDUs to the PW 1078 output interface with a constant phase relative to the input 1079 interface. The timing of the delivery may be relative to a clock 1080 derived from the packet stream received over the PSN clock recovery, 1081 or with reference to an external clock. 1083 5.3 Fragmentation 1085 A payload would normally be relayed across the PW as a single unit. 1086 However, there will be cases where the combined size of the payload 1087 and its associated PWE3 and PSN headers exceeds the PSN path MTU. 1088 When a packet exceeds the MTU of a given network, fragmentation and 1089 reassembly may have to be performed in order for the packet to be 1090 delivered. Since fragmentation and reassembly generally consume a 1091 large amount of network resource as compared to simply switching a 1092 packet in its entirety, efforts should be made to reduce or eliminate 1093 the need for fragmentation and reassembly as much as possible 1094 throughout a network. Of particular concern for fragmentation and 1095 reassembly are aggregation points where large numbers of pseudowires 1096 are processed (e.g. at the PE). 1098 Ideally, the equipment originating the traffic being sent over the PW 1099 will be configured to have adaptive measures (e.g. [RFC1191], 1100 [RFC1981]) in place such that it never sends a packet that must be 1101 fragmented. When this fails, the point closest to the sending host 1102 with fragmentation and reassembly capabilities should attempt to 1103 reduce the size of packets further into the network. Thus, in the 1104 reference model for PWE3 [Figure 3] fragmentation should first be 1105 performed at the CE if at all possible. If and only if the CE cannot 1106 adhere to an acceptable MTU size for the PW should the PE attempt its 1107 own fragmentation method. 1109 In cases where MTU management fails to limit the payload to a size 1110 suitable for transmission of the PW, the PE may fall back to either a 1111 generic PW fragmentation method, or, if available the fragmentation 1112 service of the underlying PSN. 1114 It is acceptable for a PE implementation to not support 1115 fragmentation. A PE that does not support fragmentation will drop 1116 packets that exceed the PSN MTU, and the management plane of the 1117 encapsulating PE may be notified. 1119 If the length of a L2/L1 frame, restored from a PW PDU, exceeds the 1120 MTU of the destination PWES, it must be dropped. In this case, the 1121 management plane of the destination PE may be notified. 1123 5.4 Instantiation of the Protocol Layers 1125 This document does not address the detailed mapping of the Protocol 1126 Layering model to existing or future IETF standards. The 1127 instantiation of the logical Protocol Layering model is shown in 1128 Figure 9. 1130 5.4.1. PWE3 over an IP PSN 1132 The protocol definition of PWE3 over an IP PSN should employ existing 1133 IETF protocols where possible. 1135 +---------------------+ +-------------------------+ 1136 | Payload |------------->| Raw payload if possible | 1137 /=====================\ +-------------------------+ 1138 H Payload Convergence H------------->| As Needed | 1139 H---------------------H +-------------------------+ 1140 H Timing H----------+-->| RTP | 1141 H---------------------H / +-------------+ | 1142 H Sequencing H----one of | | 1143 \=====================/ \ | +-----------+ 1144 | PW Demultiplexer |----------+-->| L2TP, MPLS etc. | 1145 +---------------------+ +-------------------------+ 1146 | PSN Convergence |------------->| Not needed | 1147 +---------------------+ +-------------------------+ 1148 | PSN |------------->| IP | 1149 +---------------------+ +-------------------------+ 1150 | MAC/Data-link |------------->| MAC/Data-link | 1151 +---------------------+ +-------------------------+ 1152 | Physical |------------->| Physical | 1153 +---------------------+ +-------------------------+ 1155 Figure 10: PWE3 over an IP PSN 1157 Figure 10 shows the protocol layering for PWE3 over an IP PSN. As a 1158 rule, the payload should be carried as received from the NSP, with 1159 the Payload Convergence Layer provided when needed. (It is accepted 1160 that there may sometimes be good reason not to follow this rule, but 1161 the exceptional circumstances need to be documented in the 1162 Encapsulation Layer definition for that payload type). 1164 Where appropriate, timing is provided by RTP [RFC1889], which when 1165 used also provides a sequencing service. PW Demultiplexing may be 1166 provided by a number of existing IETF tunnel protocols. Some of 1167 these tunnel protocols provide an optional sequencing service. 1168 (Sequencing is provided either by RTP, or by the PW Demultiplexer 1169 Layer, but not both). A PSN Convergence Layer is not needed, because 1170 all the tunnel protocols shown above are designed to operate directly 1171 over an IP PSN. 1173 As a special case, if the PW Demultiplexer is an MPLS label, the 1174 protocol architecture of section 5.4.2 can be used instead of the 1175 protocol architecture of this section. 1177 5.4.2. PWE3 over an MPLS PSN 1179 The MPLS ethos places importance on wire efficiency. By using a 1180 control word, some components of the PWE3 protocol layers can be 1181 compressed to increase this efficiency. 1183 +---------------------+ 1184 | Payload | 1185 /=====================\ 1186 H Payload Convergence H-----+ 1187 H---------------------H | 1188 H Timing H------------------------+ 1189 H---------------------H | | 1190 H Sequencing H-----| | 1191 \=====================/ | | 1192 | PW Demultiplexer |---+ | v 1193 +---------------------+ | | +--------------------------------+ 1194 | PSN Convergence |-----| . . 1195 +---------------------+ | | . RTP . 1196 | PSN |-+ | | | | 1197 +---------------------+ | | | +--------------------------------+ 1198 | MAC/Data-link | | | +->| Flags, Frag, Len, Seq #, etc | 1199 +---------------------+ | | +--------------------------------+ 1200 | Physical | | +--->| Inner Label | 1201 +---------------------+ | +--------------------------------+ 1202 +----->| Outer Label or MPLS-in-IP encap| 1203 +--------------------------------+ 1205 Figure 11: PWE3 over an MPLS PSN using a control word 1207 Figure 11 shows the protocol layering for PWE3 over an MPLS PSN. An 1208 inner MPLS label is used to provide the PW demultiplexing function. 1209 A control word is used to carry most of the information needed by the 1210 PWE3 Encapsulation Layer and the PSN Convergence Layer in a compact 1211 format. The flags in the control word provide the necessary payload 1212 convergence. A sequence field provides support for both in-order 1213 payload delivery and (supported by a fragmentation control method) a 1214 PSN fragmentation service within the PSN Convergence Layer. Ethernet 1215 pads all frames to a minimum size of 64 bytes. The MPLS header does 1216 not include a length indicator. Therefore to allow PWE3 to be carried 1217 in MPLS to correctly pass over an Ethernet data-link, a length 1218 correction field is needed in the control word. As with an IP PSN, 1219 where appropriate, timing is provided by RTP [RFC1889]. 1221 In some networks it may be necessary to carry PWE3 over MPLS over IP. 1222 In these circumstances, the PW is encapsulated for carriage over MPLS 1223 as described in this section, and then a method of carrying MPLS over 1224 an IP PSN (such as GRE [RFC2784], [RFC2890]) is applied to the 1225 resultant PW-PDU. 1227 6. PW Demultiplexer Layer and PSN Requirements 1229 PWE3 places three service requirements on the protocol layers used to 1230 carry it across the PSN: 1232 o Multiplexing 1233 o Fragmentation 1234 o Length and Delivery 1236 6.1 Multiplexing 1238 The purpose of the PW Demultiplexer Layer is to allow multiple PWs to 1239 be carried in a single tunnel. This minimizes complexity and 1240 conserves resources. 1242 Some types of native service are capable of grouping multiple 1243 circuits into a "trunk", e.g. multiple ATM VCs in a VP, multiple 1244 Ethernet VLANs on a physical media, or multiple DS0 services within a 1245 T1 or E1. A PW may interconnect two end-trunks. That trunk would 1246 have a single multiplexing value. 1248 6.2 Fragmentation 1250 If the PSN provides a fragmentation and reassembly service of 1251 adequate performance, it MAY be used to obtain an effective MTU that 1252 is large enough to transport the PW PDUs. However, if the PSN does 1253 not offer an adequate service, and fragmentation at the PE cannot be 1254 avoided by any other means, then a PW-specific fragmentation method 1255 may be utilized here. See Section 5.3 for more details. 1257 6.3 Length and Delivery 1259 PDU delivery to the egress PE is the function of the PSN Layer. 1261 If the underlying PSN does not provide all the information necessary 1262 to determine the length of a PW-PDU, the Encapsulation Layer will 1263 provide it. 1265 6.4 PW-PDU Validation 1267 It is a common practice to use a CRC or similar mechanism to assure 1268 end-to-end integrity of frames. The PW service-specific mechanisms 1269 MUST define whether the packet's checksum shall be preserved across 1270 the PW or be removed from PE bound PDUs and then be re-calculated for 1271 insertion in CE bound data. 1273 The former approach saves work, while the latter saves bandwidth. For 1274 a given implementation the choice may be dictated by hardware 1275 restrictions. 1277 For protocols such as ATM and FR, the scope of the checksum is 1278 restricted to a single link. This is because the circuit identifiers 1279 (e.g. FR DLCI or ATM VPI/VCI) have only local significance and are 1280 changed on each hop or span. If the circuit identifier (and thus 1281 checksum) were going to change as a part of the PW emulation, it 1282 would be more efficient to strip and re-calculate the checksum. 1284 The service specific document for each protocol must describe the 1285 validation scheme to be used. 1287 6.5 Congestion Considerations 1289 The PSN carrying the PW may be subject to congestion. The congestion 1290 characteristics will vary with the PSN type, the network architecture 1291 and configuration, and the loading of the PSN. 1293 Each service specific document will have to specify whether it needs 1294 an appropriate mechanism for operating in the presence of this 1295 congestion, including methods of mapping between its native 1296 congestion reporting and avoidance mechanisms, and those provided by 1297 the PW. 1299 7. Control Plane 1301 This section describes PWE3 control plane services. 1303 7.1 Set-up or Teardown of Pseudo-Wires 1305 A PW must be set up before an emulated service can be established, 1306 and must be torn down when an emulated service is no longer needed. 1308 Set up or teardown of a PW can be triggered by a CLI command, from 1309 the management plane of a PE, by signaling (i.e., set-up or teardown) 1310 of a PWES, e.g., an ATM SVC, or by an auto-discovery mechanism. 1312 During the set-up process, the PEs need to exchange some information 1313 (e.g. learn each others' capabilities). The tunnel signalling 1314 protocol may be extended to provide mechanisms to enable the PEs to 1315 exchange all necessary information on behalf of the PW. 1317 Manual configuration of PWs can be considered a special kind of 1318 signaling, and is allowed. 1320 7.2 Status Monitoring 1322 Some native services have mechanisms for status monitoring. For 1323 example, ATM supports OAM for this purpose. For such services, the 1324 corresponding emulated services must specify how to perform status 1325 monitoring. 1327 7.3 Notification of Pseudo-wire Status Changes 1329 7.3.1. Pseudo-wire Up/Down Notification 1331 If a native service requires bi-directional connectivity, the 1332 corresponding emulated service can only be signaled up when the 1333 associated PWs, and PSN tunnels if any, are functional in both 1334 directions. 1336 Because the two CEs of an emulated service are not adjacent, a 1337 failure may occur at a place such that one or both physical links 1338 between the CEs and PEs remain up. For example, in Figure 2, if the 1339 physical link between CE1 and PE1 fails, the physical link between 1340 CE2 and PE2 will not be affected and will remain up. Unless CE2 is 1341 notified about the remote failure, it will continue to send traffic 1342 over the emulated service to CE1. Such traffic will be discarded at 1343 PE1. Some native services have failure notification so that when the 1344 services fail, both CEs will be notified. For such native services, 1345 the corresponding PWE3 service must provide a failure notification 1346 mechanism. 1348 Similarly, if a native service has notification mechanisms so that 1349 when a network failure is fixed, all the affected services will 1350 change status from "Down" to "Up", the corresponding emulated service 1351 must provide a similar mechanism for doing so. 1353 These mechanisms may already be built into the tunneling protocol. 1354 For example, the L2TP control protocol [RFC2661] [L2TPv3] has this 1355 capability and LDP has the ability to withdraw the corresponding MPLS 1356 label. 1358 7.3.2. Misconnection and Payload Type Mismatch 1360 With PWE3, misconnection and payload type mismatch can occur. If a 1361 misconnection occurs it can breach the integrity of the system. If a 1362 payload mismatch occurs it can disrupt the customer network. In both 1363 instances, there are security and operational concerns. 1365 The services of the underlying tunneling mechanism, and its 1366 associated control protocol, can be used to mitigate this. As part 1367 of the PW set-up a PW-TYPE identifier is exchanged. This is then used 1368 by the FWRD and NSP to verify the compatibility of the PWESs. 1370 7.3.3. Packet Loss, Corruption, and Out-of-order Delivery 1372 A PW can incur packet loss, corruption, and out-of-order delivery on 1373 the PSN path between the PEs. This can impact the working condition 1374 of an emulated service. For some payload types, packet loss, 1375 corruption, and out-of-order delivery can be mapped to either a bit 1376 error burst, or loss of carrier on the PW. If a native service has 1377 some mechanism to deal with bit error, the corresponding PWE3 service 1378 should provide a similar mechanism. 1380 7.3.4. Other Status Notification 1382 A PWE3 approach may provide a mechanism for other status 1383 notification, if any. 1385 7.3.5. Collective Status Notification 1387 Status of a group of emulated services may be affected identically by 1388 a single network incident. For example, when the physical link (or 1389 sub-network) between a CE and a PE fails, all the emulated services 1390 that go through that link (or sub-network) will fail. It is likely 1391 that there exists a group of emulated services that all terminate at 1392 a remote CE. There may also be multiple such CEs affected by the 1393 failure. Therefore, it is desirable that a single notification 1394 message be used to notify failure of the whole group of emulated 1395 services. 1397 A PWE3 approach may provide some mechanism for notifying status 1398 changes of a group of emulated circuits. One possible method is to 1399 associate each emulated service with a group ID when the PW for that 1400 emulated service is set up. Multiple emulated services can then be 1401 grouped by associating them with the same group ID. In status 1402 notification, that group ID can be used to refer all the emulated 1403 services in that group. The group ID mechanism should be a mechanism 1404 provided by the underlying tunnel signaling protocol. 1406 7.4 Keep-alive 1408 If a native service has a keep-alive mechanism, the corresponding 1409 emulated service needs to use a mechanism to propagate this across 1410 the PW. An approach following the principle of minimum intervention 1411 would be to transparently transport keep-alive messages over the PW. 1412 However, to accurately reproduce the semantics of the native 1413 mechanism, some PWs may require an alternative approach, such as 1414 piggy-backing on the PW signaling mechanism. 1416 7.5 Handling Control Messages of the Native Services 1418 Some native services use control messages for maintaining the 1419 circuits. These control messages may be in-band, e.g. Ethernet flow 1420 control or ATM performance management, or out-of-band, e.g. the 1421 signaling VC of an ATM VP. 1423 From the principle of minimum intervention, it is desirable that the 1424 PEs participate as little as possible in the signaling and 1425 maintenance of the native services. This principle should not, 1426 however, override the need to satisfactorily emulate the native 1427 service. 1429 If control messages are passed through, it may be desirable to send 1430 them using either a higher priority or a reliable channel provided by 1431 the PW Demultiplexer layer. See PWE3 Channel Types. 1433 8. Management and Monitoring 1435 This section describes the management and monitoring architecture for 1436 PWE3. 1438 8.1 Statistics 1440 The PE can tabulate statistics that help monitor the state of the 1441 network, and to help with measurement of service level agreements 1442 (SLAs). Typical counters include: 1444 o Counts of PW-PDUs sent and received, with and without errors. 1445 o Counts of sequenced PW-PDUs lost. 1446 o Counts of service PDUs sent and received over the PSN, with 1447 and without errors (non-TDM). 1448 o Service-specific interface counts. 1450 These counters would be contained in a PW-specific MIB, and they 1451 should not replicate existing MIB counters. 1453 8.2 PW SNMP MIB Architecture 1455 This section describes the general architecture for SNMP MIBs used to 1456 manage PW services and the underlying PSN. The intent here is to 1457 provide a clear picture of how all of the pertinent MIBs fit together 1458 to form a cohesive management framework for deploying PWE3 services. 1460 8.2.1. MIB Layering 1462 The SNMP MIBs created for PWE3 should fit the architecture shown in 1463 Figure 12. 1465 +-----------+ +-----------+ +-----------+ 1466 Service | CEM | | Ethernet | | ATM | 1467 Layer |Service MIB| |Service MIB| ... |Service MIB| 1468 +-----------+ +-----------+ +-----------+ 1469 \ | / 1470 \ | / 1471 - - - - - - - - - - - - \ - - - | - - - - / - - - - - - - 1472 \ | / 1473 +-------------------------------------------+ 1474 Generic PW | Generic PW MIBs | 1475 Layer +-------------------------------------------+ 1476 / \ 1477 - - - - - - - - - - - - / - - - - - - - - \ - - - - - - - 1478 / \ 1479 / \ 1480 +-----------+ +-----------+ 1481 PSN VC |L2TP VC MIB| |MPLS VC MIB| 1482 Layer +-----------+ +-----------+ 1483 | | 1484 - - - - - - - - - | - - - - - - - - - - - - - - - | - - - 1485 | | 1486 +-----------+ +-----------+ 1487 PSN |L2TP MIB(s)| |MPLS MIB(s)| 1488 Layer +-----------+ +-----------+ 1490 Figure 12: Relationship of SNMP MIBs 1492 Figure 13 shows an example for a TDM PW carried over MPLS. 1494 +-----------------+ 1495 | SONET MIB | RFC2558 1496 +-----------------+ 1497 | 1498 +-----------------+ 1499 Service |SONET Service MIB| pw-cem-mib 1500 Layer +-----------------+ 1501 - - - - - - - - - - | - - - - - - - - - - - - - - - 1502 +-----------------+ 1503 Generic PW | Generic PW MIBS | pw-tc-mib 1504 Layer +-----------------+ pw-mib 1505 - - - - - - - - - - | - - - - - - - - - - - - - - - 1506 +-----------------+ 1507 PSN VC | MPLS VC MIBS | pw-mpls-mib 1508 Layer +-----------------+ 1509 - - - - - - - - - - | - - - - - - - - - - - - - - - 1510 +-----------------+ 1511 PSN | MPLS MIBs | mpls-te-mib 1512 Layer +-----------------+ mpls-lsr-mib 1514 Figure 13: Service-specific Example for MIBs 1516 Note that there is a separate MIB for each emulated service as well 1517 as one for each underlying PSN. These MIBs may be used in various 1518 combinations as needed. 1520 8.2.2. Service Layer MIBs 1522 The first layer is referred to as the Service Layer. It contains 1523 MIBs for PWE3 services such as Ethernet, ATM, circuits and Frame 1524 Relay. This layer contains those corresponding MIBs used to mate or 1525 adapt those emulated services to the underlying services. This 1526 working group should not produce any MIBs for managing the general 1527 service; rather, it should produce just those MIBs that are used to 1528 interface or adapt the emulated service onto the PWE3 management 1529 framework. For example, the standard SONET MIB [SONETMIB] is 1530 designed and maintained by another working group. Also, the SONET MIB 1531 is designed to manage the native service without PW emulation. Since 1532 the PWE3 working group is chartered to produce the corresponding 1533 adaptation MIB, in this case, it would produce the PW-CEM-MIB 1534 [PWMPLSMIB] that would be used to adapt SONET services to the 1535 underlying PSN that carries the PWE3 service. 1537 8.2.3. Generic PW MIBs 1539 The second layer is referred to as the Generic PW Layer. This layer 1540 is composed of two MIBs: the PWE-TC-MIB [PWTCMIB] and the PWE-MIB 1541 [PWMIB]. These MIBs are responsible for providing general PWE3 1542 counters and service models used for monitoring and configuration of 1543 PWE3 services over any supported PSN service. That is, this MIB 1544 provides a general model of PWE3 abstraction for management purposes. 1545 This MIB is used to interconnect the Service Layer MIBs to the PSN VC 1546 Layer MIBs. The latter will be described in the next section. This 1547 layer also provides the PW-TC-MIB [PWTCMIB]. This MIB contains 1548 common SMI textual conventions [RFC1902] that may be used by any PW 1549 MIB. 1551 8.2.4. PSN VC Layer MIBs 1553 The third layer in the PWE3 management architecture is referred to as 1554 the PSN VC layer. This layer is comprised of MIBs that are 1555 specifically designed to interface general PWE3 services (VCs) onto 1556 those underlying PSN services. In general this means that the MIB 1557 provides a means with which an operator can map the PW service onto 1558 the native PSN service. For example, in the case of MPLS, it is 1559 required that the general VC service be layered onto MPLS LSPs or 1560 Traffic Engineered (TE) Tunnels [RFC3031]. In this case, the PW- 1561 MPLS-MIB [PWMPLSMIB] was created to adapt the general PWE3 circuit 1562 services onto MPLS. Like the Service Layer described above the PWE3 1563 working group should produce these MIBs. 1565 8.2.5. PSN Layer MIBs 1567 The fourth and final layer in the PWE3 management architecture is 1568 referred to as the PSN layer. This layer is comprised of those MIBs 1569 that control the PSN service-specific services. For example, in the 1570 case of the MPLS [RFC3031] PSN service, the MPLS-LSR-MIB [LSRMIB] and 1571 the MPLS-TE-MIB [TEMIB] are used to interface the general PWE3 VC 1572 services onto native MPLS LSPs and/or TE tunnels to carry the 1573 emulated services. In addition, the MPLS-LDP-MIB [LDPMIB] may be 1574 used to reveal the MPLS labels that are distributed over the MPLS PSN 1575 in order to maintain the PW service. The MIBs in this layer are 1576 produced by other working groups that design and specify the native 1577 PSN services. These MIBs should contain the appropriate mechanisms 1578 for monitoring and configuring the PSN service such that the emulated 1579 PWE3 service will function correctly. 1581 8.3 Connection Verification and Traceroute 1583 A connection verification mechanism should be supported by PWs. 1584 Connection verification as well as other alarming mechanisms can 1585 alert the operator that a PW has lost its remote connection. The 1586 opaque nature of a PW means that it is not possible to specify a 1587 generic connection verification or traceroute mechanism that passes 1588 this status to the CEs over the PW. If connection verification 1589 status of the PW is needed by the CE, it must be mapped to the native 1590 connection status method. 1592 For troubleshooting purposes, it is sometimes desirable to know the 1593 exact functional path of a PW between PEs. This is provided by the 1594 traceroute service of the underlying PSN. The opaque nature of the 1595 PW means that this traceroute information is only available within 1596 the provider network e.g. at the PEs. 1598 9. IANA considerations 1600 There are no IANA considerations for this document. 1602 10. Security Considerations 1604 PWE3 provides no means of protecting the contents or delivery of the 1605 native data units. PWE3 may, however, leverage security mechanisms 1606 provided by the PW Demultiplexer or PSN Layers, such as IPSec 1607 [RFC2401]. This section addresses the PWE3 vulnerabilities, and the 1608 mechanisms available to protect the emulated native services. 1610 The PW Tunnel End-Point, PW Demultiplexing mechanism, and the 1611 payloads of the native service are all vulnerable to attack. 1613 10.1 PW Tunnel End-Point and PW Demultiplexer Security 1615 Protection mechanisms must be considered for the PW Tunnel end-point 1616 and PW Demultiplexer mechanism in order to avoid denial-of-service 1617 attacks upon the native service, and to prevent spoofing of the 1618 native data units. Exploitation of vulnerabilities from within the 1619 PSN may be directed to the PW Tunnel end-point so that PW 1620 Demultiplexer and PSN tunnel services are disrupted. Controlling PSN 1621 access to the PW Tunnel end-point may protect against this. 1623 By restricting PW Tunnel end-point access to legitimate remote PE 1624 sources of traffic, the PE may reject traffic that would interfere 1625 with the PW Demultiplexing and PSN tunnel services. 1627 10.2 Validation of PW Encapsulation 1629 Protection mechanisms must address the spoofing of tunneled PW data. 1630 The validation of traffic addressed to the PW Demultiplexer end-point 1631 is paramount in ensuring integrity of PW encapsulation. Security 1632 protocols such as IPSec [RFC2401] may be used by the PW Demultiplexer 1633 Layer in order to maintain the integrity of the PW by authenticating 1634 data between the PW Demultiplexer End-points. IPSec may provide 1635 authentication, integrity, non-repudiation, and confidentiality of 1636 data transferred between two PEs. It cannot provide the equivalent 1637 services to the native service. 1639 Based on the type of data being transferred, the PW may indicate to 1640 the PW Demultiplexer Layer that enhanced security services are 1641 required. The PW Demultiplexer Layer may define multiple protection 1642 profiles based on the requirements of the PW emulated service. CE- 1643 to-CE signaling and control events emulated by the PW and some data 1644 types may require additional protection mechanisms. Alternatively, 1645 the PW Demultiplexer Layer may use peer authentication for every PSN 1646 packet to prevent spoofed native data units from being sent to the 1647 destination CE. 1649 Acknowledgments 1651 We thank: Sasha Vainshtein for his work on Native Service Processing 1652 and advice on bit-stream over PW services. Thomas K. Johnson for his 1653 work on the background and motivation for PWs. 1655 We also thank: Ron Bonica, Stephen Casner, Durai Chinnaiah, Jayakumar 1656 Jayakumar, Ghassem Koleyni, Eric Rosen, John Rutemiller, Scott 1657 Wainner and David Zelig for their comments and contributions. 1659 References 1661 Internet-drafts are works in progress available from 1662 1664 [ETSI] EN 300 744 Digital Video Broadcasting (DVB); Framing 1665 structure, channel coding and modulation for digital 1666 terrestrial television (DVB-T), European 1667 Telecommunications Standards Institute (ETSI) 1669 [LDP-MIB] Cucchiara, J., Sjostrand, H., and Luciani, J., 1670 "Definitions of Managed Objects for the Multiprotocol 1671 Label Switching, Label Distribution Protocol (LDP)", 1672 , work in progress, 1673 August 2001. 1675 [LSRMIB] Srinivasan et al, "MPLS Label Switch Router Management 1676 Information Base Using SMIv2", 1677 (draft-ietf-mpls-lsr-mib-08.txt, work in progress, 1678 January 2002. 1680 [L2TPv3] Layer Two Tunneling Protocol (Version 3)'L2TPv3', J Lau, 1681 et. al. (work in progress). 1683 [PPPoL2TP] PPP Tunneling Using Layer Two Tunneling Protocol, 1684 J Lau et al. , 1685 work in progress. 1687 [PWMIB] Zelig et al, "Pseudo Wire (PW) Management Information 1688 Base Using SMIv2", (draft-ietf-pwe3-pw-mib-00.txt), 1689 work in progress, June 2002. 1691 [PWTCMIB] Nadeau et al, "Definitions for Textual Conventions and 1692 OBJECT-IDENTITIES for Pseudo-Wires Management" 1693 (draft-ietf-pwe3-pw-tc-mib-00.txt), work in progress, 1694 June 2002. 1696 [PWMPLSMIB] Danenberg et al, "SONET/SDH Circuit Emulation Service 1697 Over MPLS (CEM) Management Information Base Using 1698 SMIv2", (draft-ietf-pwe3-cep-mib-00.txt), work in 1699 progress, August 2001. 1701 [RFC1191] RFC-1191: Path MTU discovery. J.C. Mogul, S.E. Deering. 1703 [RFC1889] RFC-1889: RTP: A Transport Protocol for Real-Time 1704 Applications. H. Schulzrinne et. al. 1706 [RFC1902] RFC-1902: Structure of Management Information for 1707 Version 2 of the Simple Network Management Protocol 1708 (SNMPv2), Case et al, January 1996. 1710 [RFC1958] RFC-1958: Architectural Principles of the Internet, 1711 B. Carpenter et al. 1713 [RFC1981] RFC-1981: Path MTU Discovery for IP version 6. J. McCann, 1714 S. Deering, J.Mogul. 1716 [RFC2022] RFC-2022: Support for Multicast over UNI 3.0/3.1 based 1717 ATM Networks, G. Armitage. 1719 [RFC2401] RFC-2401: Security Architecture for the Internet 1720 Protocol. S. Kent, R. Atkinson. 1722 [RFC2474] RFC-2474: Definition of the Differentiated Services 1723 Field (DS Field) in the IPv4 and IPv6 Headers, 1724 K. Nichols, et. al. 1726 [RFC2661] RFC-2661: Layer Two Tunneling Protocol "L2TP". 1727 W. Townsley, et. al. 1729 [RFC2784] RFC-2784: Generic Routing Encapsulation (GRE). 1730 D. Farinacci et al. 1732 [RFC2890] RFC-2890: Key and Sequence Number Extensions to GRE. 1733 G. Dommety. 1735 [RFC3022] RFC-3022: Traditional IP Network Address Translator 1736 (Traditional NAT). P Srisuresh et al. 1738 [RFC3031] RFC3031: Multiprotocol Label Switching Architecture, 1739 E. Rosen, January 2001. 1741 [SONETMIB] K. Tesink, "Definitions of Managed Objects for the 1742 SONET/SDH Interface Type", RFC2558, March 1999. 1744 [TEMIB] Srinivasan et al, "Traffic Engineering Management 1745 Information Base Using SMIv2", 1746 (draft-ietf-mpls-te-mib-08.txt), work in progress, 1747 January 2002. 1749 [VPLS] M. Lasserre, "Virtual Private LAN Services over MPLS", 1750 draft-lasserre-vkompella-ppvpn-vpls-02.txt, work in 1751 progress, June 2002. 1753 [XIAO] Xiao et al, "Requirements for Pseudo-Wire Emulation 1754 Edge-to-Edge (PWE3)", 1755 (draft-ietf-pwe3-requirements-03.txt), X Xiao et al. 1756 work in progress, December 2002. 1758 Editors' Addresses 1760 Stewart Bryant 1761 Cisco Systems, 1762 4, The Square, 1763 Stockley Park, 1764 Uxbridge UB11 1BL, 1765 United Kingdom. Email: stbryant@cisco.com 1767 Prayson Pate 1768 Overture Networks, Inc. 1769 P. O. Box 14864 1770 RTP, NC, USA 27709 Email: prayson.pate@overturenetworks.com 1772 Full copyright statement 1774 Copyright (C) The Internet Society (2002). 1775 All Rights Reserved. 1777 This document and translations of it may be copied and 1778 furnished to others, and derivative works that comment 1779 on or otherwise explain it or assist in its implementation 1780 may be prepared, copied, published and distributed, in 1781 whole or in part, without restriction of any kind, 1782 provided that the above copyright notice and this 1783 paragraph are included on all such copies and derivative works. 1784 However, this document itself may not be modified in any way, 1785 such as by removing the copyright notice or references to the 1786 Internet Society or other Internet organizations, except as 1787 needed for the purpose of developing Internet standards in 1788 which case the procedures for copyrights defined in the 1789 Internet Standards process must be followed, or as required to 1790 translate it into languages other than English. 1792 The limited permissions granted above are perpetual and will 1793 not be revoked by the Internet Society or its successors or assigns. 1795 This document and the information contained herein is provided 1796 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1797 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1798 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 1799 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 1800 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1801 FOR A PARTICULAR PURPOSE.