idnits 2.17.00 (12 Aug 2021) /tmp/idnits52432/draft-ietf-pwe3-arch-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 263 has weird spacing: '...Edge to att...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2003) is 7034 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 1100, but not defined == Missing Reference: 'LDPMIB' is mentioned on line 1653, but not defined == Unused Reference: 'LDP-MIB' is defined on line 1752, but no explicit reference was found in the text == Unused Reference: 'VPLS' is defined on line 1843, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DVB' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRAG' -- Possible downref: Non-RFC (?) normative reference: ref. 'LDP-MIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'LSRMIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'L2TPv3' -- Possible downref: Non-RFC (?) normative reference: ref. 'PPPoL2TP' -- Possible downref: Non-RFC (?) normative reference: ref. 'PWMIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'PWTCMIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'PWMPLSMIB' ** 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 2338 (Obsoleted by RFC 3768) ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'TEMIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'TFRC' -- Possible downref: Non-RFC (?) normative reference: 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 (~~), 8 warnings (==), 14 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: August 2003 Prayson Pate 5 Overture Networks, Inc. 7 Editors 9 February 2003 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 Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in [RFC2119]. 62 1. Introduction............................................. 5 63 1.1 Pseudo Wire Definition............................... 5 64 1.2 PW Service Functionality............................. 6 65 1.3 Non-Goals of this document........................... 6 66 1.4 Terminology.......................................... 6 68 2. PWE3 Applicability....................................... 9 70 3. Protocol Layering Model.................................. 9 71 3.1 Protocol Layers...................................... 9 72 3.2 Domain of PWE3....................................... 11 73 3.3 Payload Types........................................ 11 75 4. Architecture of Pseudo-wires............................. 14 76 4.1 Network Reference Model.............................. 14 77 4.2 PWE3 Pre-processing.................................. 15 78 4.3 Maintenance Reference Model.......................... 19 79 4.4 Protocol Stack Reference Model....................... 19 80 4.5 Pre-processing Extension to Protocol Stack Reference. 81 Model................................................ 20 83 5. PW Encapsulation......................................... 21 84 5.1 Payload Convergence Layer............................ 22 85 5.2 Payload-independent PW Encapsulation Layers.......... 24 86 5.3 Fragmentation........................................ 27 87 5.4 Instantiation of the Protocol Layers................. 27 89 6. PW Demultiplexer Layer and PSN Requirements.............. 31 90 6.1 Multiplexing......................................... 31 91 6.2 Fragmentation........................................ 31 92 6.3 Length and Delivery.................................. 31 93 6.4 PW-PDU Validation.................................... 31 94 6.5 Congestion Considerations............................ 32 96 7. Control Plane............................................ 33 97 7.1 Set-up or Teardown of Pseudo-Wires................... 33 98 7.2 Status Monitoring.................................... 33 99 7.3 Notification of Pseudo-wire Status Changes........... 34 100 7.4 Keep-alive........................................... 35 101 7.5 Handling Control Messages of the Native Services..... 35 103 8. Management and Monitoring................................. 36 104 8.1 Status and Statistics................................ 36 105 8.2 PW SNMP MIB Architecture............................. 36 106 8.3 Connection Verification and Traceroute................ 40 108 9. IANA considerations...................................... 40 110 10. Security Considerations................................. 40 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 IP path or MPLS tunnel. In some cases it is necessary 137 to perform other operation such as managing their timing and order, 138 to 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. 148 For each service type, there will be one default mode of operation 149 that all PEs offering that service type MUST support. However, 150 OPTIONAL modes MAY be defined to improve the faithfulness of the 151 emulated service, if it can be clearly demonstrated that the 152 additional complexity associated with the OPTIONAL mode is offset by 153 the value it offers to PW users. 155 1.2 PW Service Functionality 157 PWs provide the following functions in order to emulate the behavior 158 and characteristics of the native service. 159 o Encapsulation of service-specific PDUs or circuit data arriving 160 at the PE-bound port (logical or physical). 161 o Carriage of the encapsulated data across a PSN tunnel. 162 o Establishment of the PW including the exchange and/or 163 distribution of the PW identifiers used by the PSN 164 tunnel endpoints. 165 o Managing the signaling, timing, order or other aspects of the 166 service at the boundaries of the PW. 167 o Service-specific status and alarm management. 169 1.3 Non-Goals of this document 171 The following are non-goals for this document: 173 o The on-the-wire specification of PW encapsulations. 174 o The detailed definition of the protocols involved in PW 175 set-up and maintenance. 177 The following are outside the scope of PWE3: 178 o Any multicast service not native to the emulated medium. 179 Thus, Ethernet transmission to a "multicast" IEEE-48 address 180 is in scope, while multicast services like MARS [RFC2022] that 181 are implemented on top of the medium are out of scope. 182 o Methods to signal or control the underlying PSN. 184 1.4 Terminology 186 This document uses the following definitions of terms. These terms 187 are illustrated in context in Figure 2. 189 Attachment Circuit The circuit or virtual circuit attaching 190 (AC) a CE to a PE. 192 CE-bound The traffic direction where PW-PDUs are 193 received on a PW via the PSN, processed 194 and then sent to the destination CE. 196 CE Signaling Messages sent and received by the CEs 197 control plane. It may be desirable or 198 even necessary for the PE to participate 199 in or monitor this signaling in order 200 to effectively emulate the service. 202 Control Word (CW) A four octet header used in some encapsulations 203 to carry per packet information when the PSN 204 is MPLS. 206 Customer Edge (CE) A device where one end of a service 207 originates and/or terminates. The CE is not 208 aware that it is using an emulated service 209 rather than a native service. 211 Forwarder (FWRD) A PE subsystem that selects the PW to use to 212 transmit a payload received on an AC. 214 Fragmentation The action of dividing a single PDU into 215 multiple PDUs before transmission with the 216 intent of the original PDU being reassembled 217 elsewhere in the network. Fragmentation MAY be 218 performed in order to allow sending of packets 219 of a larger size than the network MTU which 220 they will traverse. 222 Maximum transmission The packet size (excluding data link header) 223 unit (MTU) that an interface can transmit without 224 needing to fragment. 226 Native Service Processing of the data received by the PE 227 Processing (NSP) from the CE before presentation to the PW 228 for transmission across the core, or 229 processing of the data received from a PW 230 by a PE before it is output on the AC. 231 NSP functionality is defined by standards 232 bodies other than the IETF, such as ITU-T, 233 ANSI, ATMF, etc.) 235 Packet Switched Within the context of PWE3, this is a 236 Network (PSN) network using IP or MPLS as the mechanism 237 for packet forwarding. 239 Protocol Data The unit of data output to, or received 240 Unit (PDU) from, the network by a protocol layer. 242 Provider Edge (PE) A device that provides PWE3 to a CE. 244 PE-bound The traffic direction where information 245 from a CE is adapted to a PW, and PW-PDUs 246 are sent into the PSN. 248 PE/PW Maintenance Used by the PEs to set up, maintain and 249 tear down the PW. It may be coupled with 250 CE Signaling in order to effectively manage 251 the PW. 253 Pseudo Wire (PW) A mechanism that carries the essential 254 elements of an emulated service from one PE 255 to one or more other PEs over a PSN. 257 PW End Service The interface between a PE and a CE. This 258 (PWES) can be a physical interface like a T1 or 259 Ethernet, or a virtual interface like a VC 260 or VLAN. 262 Pseudo Wire A mechanism that emulates the essential 263 Emulation Edge to attributes of service (such as a T1 leased 264 Edge (PWE3) line or frame relay) over a PSN. 266 Pseudo Wire PDU A PDU sent on the PW that contains all of 267 (PW-PDU) the data and control information necessary 268 to emulate the desired service. 270 PSN Tunnel A tunnel across a PSN inside which one or 271 more PWs can be carried. 273 PSN Tunnel Used to set up, maintain and tear down the 274 Signaling underlying PSN tunnel. 276 PW Demultiplexer Data-plane method of identifying a PW 277 terminating at a PE. 279 Time Domain Time Division Multiplexing. Frequently used 280 Multiplexing (TDM) to refer to the synchronous bit-streams at 281 rates defined by G.702. 283 Tunnel A method of transparently carrying information 284 over a network. 286 2. PWE3 Applicability 288 The PSN carrying a PW will subject payload packets to loss, delay, 289 delay variation, and re-ordering. During a network transient there 290 may be a sustained period of impaired service. The applicability of 291 PWE3 to a particular service depends on the sensitivity of that 292 service (or the CE implementation) to these effects, and the ability 293 of the adaptation layer to mask them. Some services, such as IP over 294 FR over PWE3, may prove quite resilient to IP and MPLS PSN 295 characteristics. Other services, such as the interconnection of PBX 296 systems via PWE3, will require more careful consideration of the PSN 297 and adaptation layer characteristics. In some instances, traffic 298 engineering of the underlying PSN will be required, and in some 299 cases, the constraints may be such that it is not possible to provide 300 the required service guarantees. 302 3. Protocol Layering Model 304 The PWE3 protocol-layering model is intended to minimise the 305 differences between PWs operating over different PSN types. The 306 design of the protocol-layering model has the goals of making each PW 307 definition independent of the underlying PSN, and maximizing the 308 reuse of IETF protocol definitions and their implementations. 310 3.1 Protocol Layers 312 The logical protocol-layering model required to support a PW is shown 313 in Figure 1. 315 +---------------------------+ 316 | Payload | 317 +---------------------------+ 318 | Encapsulation | <==== MAY be null 319 +---------------------------+ 320 | PW Demultiplexer | 321 +---------------------------+ 322 | PSN Convergence | <==== MAY be null 323 +---------------------------+ 324 | PSN | 325 +---------------------------+ 326 | Data-link | 327 +---------------------------+ 328 | Physical | 329 +---------------------------+ 331 Figure 1: Logical Protocol Layering Model 333 The payload is transported over the Encapsulation Layer. The 334 Encapsulation Layer carries any information, not already present 335 within the payload itself, that is needed by the PW CE-bound PE 336 interface to send the payload to the CE via the physical interface. 337 If no information is needed beyond that in the payload itself, this 338 layer is empty. 340 This layer also provides support for real-time processing, and 341 sequencing, if needed. 343 The PW Demultiplexer Layer provides the ability to deliver multiple 344 PWs over a single PSN tunnel. The PW demultiplexer value used to 345 identify the PW in the data-plane may be unique per PE, but this is 346 not a PWE3 requirement. It MUST, however, be unique per tunnel 347 endpoint. If it is necessary to identify a particular tunnel, then 348 that is the responsibility of the PSN layer. 350 The PSN Convergence Layer provides the enhancements needed to make 351 the PSN conform to the assumed PSN service requirement. This layer 352 therefore provides a consistent interface to the PW, making the PW 353 independent of the PSN type. If the PSN already meets the service 354 requirements, this layer is empty. 356 The PSN header, MAC/Data-link and Physical Layer definitions are 357 outside the scope of this document. The PSN can be IPv4, IPv6 or 358 MPLS. 360 3.2 Domain of PWE3 362 PWE3 defines the Encapsulation Layer, the method of carrying various 363 payload types, and the interface to the PW Demultiplexer Layer. It 364 is expected that the other layers will be provided by tunneling 365 methods such as L2TP or MPLS over the PSN. 367 3.3 Payload Types 369 The payload is classified into the following generic types of native 370 data unit: 372 o Packet 373 o Cell 374 o Bit-stream 375 o Structured bit-stream 377 Within these generic types there are specific service types. For 378 example: 380 Generic Payload Type PW Service 381 -------------------- ---------- 382 Packet Ethernet (all types), HDLC framing, 383 frame-relay, ATM AAL5 PDU. 385 Cell ATM. 387 Bit-stream Unstructured E1, T1, E3, T3. 389 Structured bit-stream SONET/SDH (e.g. SPE, VT, NxDS0). 391 3.3.1. Packet Payload 393 A packet payload is a variable-size data unit presented to the PE on 394 the AC. A packet payload may be large compared to the PSN MTU. The 395 delineation of the packet boundaries is encapsulation-specific. HDLC 396 or Ethernet PDUs can be considered as examples of packet payloads. 397 Typically a packet will be stripped of transmission overhead such as 398 HDLC flags and stuffing bits before transmission over the PW. 400 A packet payload would normally be relayed across the PW as a single 401 unit. However, there will be cases where the combined size of the 402 packet payload and its associated PWE3 and PSN headers exceeds the 403 PSN path MTU. In these cases, some fragmentation methodology needs 404 to be applied. This may, for example, be the case when a user is 405 providing the service and attaching to the service provider via 406 Ethernet, or where nested pseudo-wires are involved. Fragmentation is 407 discussed in more detail in Section 5.3 409 A packet payload may need sequencing and real-time support. 411 In some situations, the packet payload MAY be selected from the 412 packets presented on the emulated wire on the basis of some sub- 413 multiplexing technique. For example, one or more frame-relay PDUs 414 may be selected for transport over a particular pseudo-wire based on 415 the frame-relay Data-Link Connection Identifier (DLCI), or, in the 416 case of Ethernet payloads, using a suitable MAC bridge filter. This 417 is an FWRD function, and this selection would therefore be made 418 before the packet was presented to the PW Encapsulation Layer. 420 3.3.2. Cell Payload 422 A cell payload is created by capturing, transporting and replaying 423 groups of octets presented on the wire in a fixed-size format. The 424 delineation of the group of bits that comprise the cell is specific 425 to the encapsulation type. Two common examples of cell payloads are 426 ATM 53-octet cells, and the larger 188-octet MPEG Transport Stream 427 packets [DVB]. 429 To reduce per-PSN packet overhead, multiple cells MAY be concatenated 430 into a single payload. The Encapsulation Layer MAY consider the 431 payload complete on the expiry of a timer, after a fixed number of 432 cells have been received or when a significant cell (e.g. an ATM OAM 433 cell) has been received. The benefit of concatenating multiple PDUs 434 should be weighed against a possible increase in packet delay 435 variation and the larger penalty incurred by packet loss. In some 436 cases, it may be appropriate for the Encapsulation Layer to perform 437 some type of compression, such as silence suppression or voice 438 compression. 440 The generic cell payload service will normally need sequence number 441 support, and may also need real-time support. The generic cell 442 payload service would not normally require fragmentation. 444 The Encapsulation Layer MAY apply some form of compression to some of 445 these sub-types (e.g. idle cells MAY be suppressed). 447 In some instances, the cells to be incorporated in the payload MAY be 448 selected by filtering them from the stream of cells presented on the 449 wire. For example, an ATM PWE3 service may select cells based on 450 their VCI or VPI fields. This is an FWRD function, and the selection 451 would therefore be made before the packet was presented to the PW 452 Encapsulation Layer. 454 3.3.3. Bit-stream 456 A bit-stream payload is created by capturing, transporting and 457 replaying the bit pattern on the emulated wire, without taking 458 advantage of any structure that, on inspection, may be visible within 459 the relayed traffic (i.e. the internal structure has no effect on the 460 fragmentation into packets). 462 In some instances it is possible to apply suppression to bit-streams. 463 For example, E1 and T1 send "all-ones" to indicate failure. This 464 condition can be detected without any knowledge of the structure of 465 the bit-stream, and transmission of packetized data suppressed. 467 This service will require sequencing and real-time support. 469 3.3.4. Structured bit-stream 471 A structured bit-stream payload is created by using some knowledge of 472 the underlying structure of the bit-stream to capture, transport and 473 replay the bit pattern on the emulated wire. 475 Two important points distinguish structured and unstructured bit- 476 streams: 478 o Some parts of the original bit-stream MAY be stripped in the 479 PSN-bound direction by NSP block. For example, in Structured 480 SONET the section and line overhead (and, possibly more) may 481 be stripped. A framer is required to enable such stripping. 482 It is also required for frame/payload alignment for 483 fractional T1/E1 applications. 485 o The PW MUST preserve the structure across the PSN so that 486 the CE-bound NSP block can insert it correctly into the 487 reconstructed unstructured bit-stream. The stripped 488 information (such as SONET pointer justifications) may 489 appear in the encapsulation layer to facilitate this 490 reconstitution. 492 As an option, the Encapsulation Layer MAY also perform silence/idle 493 suppression or similar compression on a structured bit-stream. 495 Structured bit-streams are distinguished from cells in that the 496 structures may be too long to be carried in a single packet. Note 497 that "short" structures are indistinguishable from cells and may 498 benefit from the use of methods described in section 3.3.2. 500 This service REQUIRES sequencing and real-time support. 502 3.3.5. Principle of Minimum Intervention 504 To minimise the scope of information, and to improve the efficiency 505 of data flow through the Encapsulation Layer, the payload SHOULD be 506 transported as received with as few modifications as possible 507 [RFC1958]. 509 This minimum intervention approach decouples payload development from 510 PW development and requires fewer translations at the NSP in a system 511 with similar CE interfaces at each end. It also prevents unwanted 512 side-effects due to subtle misrepresentation of the payload in the 513 intermediate format. 515 An approach which does intervene can be more wire-efficient in some 516 cases and may result in fewer translations at the NSP where the CE 517 interfaces are of different types. Any intermediate format 518 effectively becomes a new framing type, requiring documentation and 519 assured interoperability. This increases the amount of work for 520 handling the protocol the intermediate format carries, and is 521 undesirable. 523 4. Architecture of Pseudo-wires 525 This section describes the PWE3 architectural model. 527 4.1 Network Reference Model 529 Figure 2 illustrates the network reference model for point-to-point 530 PWs. 532 |<-------------- Emulated Service ---------------->| 533 | | 534 | |<------- Pseudo Wire ------>| | 535 | | | | 536 | | |<-- PSN Tunnel -->| | | 537 | PW End V V V V PW End | 538 V Service +----+ +----+ Service V 539 +-----+ | | PE1|==================| PE2| | +-----+ 540 | |----------|............PW1.............|----------| | 541 | CE1 | | | | | | | | CE2 | 542 | |----------|............PW2.............|----------| | 543 +-----+ ^ | | |==================| | | ^ +-----+ 544 ^ | +----+ +----+ | | ^ 545 | | Provider Edge 1 Provider Edge 2 | | 546 | | | | 547 Customer | | Customer 548 Edge 1 | | Edge 2 549 | | 550 | | 551 native service native service 553 Figure 2: PWE3 Network Reference Model 555 The two PEs (PE1 and PE2) need to provide one or more PWs on behalf 556 of their client CEs (CE1 and CE2) to enable the client CEs to 557 communicate over the PSN. A PSN tunnel is established to provide a 558 data path for the PW. The PW traffic is invisible to the core 559 network, and the core network is transparent to the CEs. Native data 560 units (bits, cells or packets) presented to the PW End Service (PWES) 561 are encapsulated in a PW-PDU and carried across the underlying 562 network via the PSN tunnel. The PEs perform the necessary 563 encapsulation and decapsulation of PW-PDUs, as well as handling any 564 other functions required by the PW service, such as sequencing or 565 timing. A PE MAY provide multiple PWESs. 567 4.2 PWE3 Pre-processing 569 In some applications, there is a need to perform operations on the 570 native data units received from the CE (including both payload and 571 signaling traffic) before they are transmitted across the PW by the 572 PE. Examples include Ethernet bridging, SONET cross-connect, 573 translation of locally-significant identifiers such as VCI/VPI, or 574 translation to another service type. These operations could be 575 carried out in external equipment, and the processed data sent to the 576 PE over one or more physical interfaces. In most cases, there are 577 cost and operational benefits in undertaking these operations within 578 the PE. This processed data is then presented to the PW via a 579 virtual interface within the PE. 581 These pre-processing operations are included in the PWE3 reference 582 model to provide a common reference point, but the detailed 583 description of these operations is outside the scope of the PW 584 definition given here. 586 PW 587 End Service 588 | 589 |<------- Pseudo Wire ------>| 590 | | 591 | |<-- PSN Tunnel -->| | 592 V V V V PW 593 +-----+----+ +----+ End Service 594 +-----+ |PREP | PE1|==================| PE2| | +-----+ 595 | | | |............PW1.............|----------| | 596 | CE1 |----| | | | | | | CE2 | 597 | | ^ | |............PW2.............|----------| | 598 +-----+ | | | |==================| | | ^ +-----+ 599 | +-----+----+ +----+ | | 600 | ^ | | 601 | | | | 602 | |<------- Emulated Service ------->| | 603 | | | 604 | Virtual physical | 605 | termination | 606 | ^ | 607 CE1 native | CE2 native 608 service | service 609 | 610 CE2 native 611 service 613 Figure 3: Pre-processing within the PWE3 Network Reference Model 615 Figure 3 shows the inter-working of one PE with pre-processing 616 (PREP), and a second without this functionality. This is a useful 617 reference point because it emphasises that the functional interface 618 between PREP and the PW is that represented by a physical interface 619 carrying the service. This effectively defines the necessary inter- 620 working specification. 622 The operation of a system in which both PEs include PREP 623 functionality is also supported. 625 The required pre-processing can be divided into two components: 626 o Forwarder (FWRD) 628 o Native Service Processing (NSP) 630 4.2.1. Forwarders 632 In some applications there is the need to selectively forward payload 633 elements from one of more ACs to one or more PWs. In such cases there 634 will also be the need to perform the inverse function on PWE3-PDUs 635 received by a PE from the PSN. This is the function of the FWRD. 637 The FWRD selects the PW based on, for example: the incoming AC, the 638 contents of the payload, or some statically and/or dynamically 639 configured forwarding information. 641 +----------------------------------------+ 642 | PE Device | 643 +----------------------------------------+ 644 Single | | | 645 PWES | | Single | PW Instance 646 <------>o Forwarder + PW Instance X<===========> 647 | | | 648 +----------------------------------------+ 650 Figure 4a: Simple point-to-point service 652 +----------------------------------------+ 653 | PE Device | 654 +----------------------------------------+ 655 Multiple| | Single | PW Instance 656 PWES | + PW Instance X<===========> 657 <------>o | | 658 | |----------------------| 659 <------>o | Single | PW Instance 660 | Forwarder + PW Instance X<===========> 661 <------>o | | 662 | |----------------------| 663 <------>o | Single | PW Instance 664 | + PW Instance X<===========> 665 <------>o | | 666 +----------------------------------------+ 668 Figure 4b: Multiple PWES to Multiple PW Forwarding 670 Figure 4a shows a simple FWRD that performs some type of filtering 671 operation. Because the FWRD has a single input and a single output 672 interface, filtering is the only type of forwarding operation that 673 applies. Figure 4b shows a more general forwarding situation where 674 payloads are extracted from one or more PWESs and directed to one or 675 more PWs, including, in this instance, a multipoint PW. In this case 676 both filtering and direction operations MAY be performed on the 677 payloads. 679 4.2.2. Native Service Processing 681 In some applications some form of data or address translation, or 682 other operation requiring knowledge of the semantics of the payload, 683 will be required. This is the function of the Native Service 684 Processor (NSP). 686 The use of the NSP approach simplifies the design of the PW by 687 restricting a PW to homogeneous operation. NSP is included in the 688 reference model to provide a defined interface to this functionality. 689 The specification of the various types of NSP is outside the scope of 690 PWE3. 692 +----------------------------------------+ 693 | PE Device | 694 Multiple+----------------------------------------+ 695 PWES | | | Single | PW Instance 696 <------>o NSP # + PW Instance X<===========> 697 | | | | 698 |------| |----------------------| 699 | | | Single | PW Instance 700 <------>o NSP #Forwarder + PW Instance X<===========> 701 | | | | 702 |------| |----------------------| 703 | | | Single | PW Instance 704 <------>o NSP # + PW Instance X<===========> 705 | | | | 706 +----------------------------------------+ 708 Figure 5: NSP in a Multiple PWEs to Multiple 709 PW Forwarding PE 711 Figure 5 illustrates the relationship between NSP, FWRD and PWs in a 712 PE. The NSP function MAY apply any transformation operation 713 (modification, injection, etc.) on the payloads as they pass between 714 the physical interface to the CE and the virtual interface to the 715 FWRD. A PE device MAY contain more than one FWRD. 717 This model also supports the operation of a system in which the NSP 718 functionality includes terminating the data-link, and applying 719 Network Layer processing to the payload is also supported. 721 4.3 Maintenance Reference Model 723 Figure 6 illustrates the maintenance reference model for PWs. 725 |<------- CE (end-to-end) Signaling ------>| 726 | |<---- PW/PE Maintenance ----->| | 727 | | |<-- PSN Tunnel -->| | | 728 | | | Signaling | | | 729 | V V (out of scope) V V | 730 v +-----+ +-----+ v 731 +-----+ | PE1 |==================| PE2 | +-----+ 732 | |-----|.............PW1..............|-----| | 733 | CE1 | | | | | | CE2 | 734 | |-----|.............PW2..............|-----| | 735 +-----+ | |==================| | +-----+ 736 +-----+ +-----+ 737 Customer Provider Provider Customer 738 Edge 1 Edge 1 Edge 2 Edge 2 740 Figure 6: PWE3 Maintenance Reference Model 742 The following signaling mechanisms are REQUIRED: 744 o The CE (end-to-end) signaling is between the CEs. This 745 signaling could be frame relay PVC status signaling, ATM SVC 746 signaling, TDM CAS signaling, etc. 748 o The PW/PE Maintenance is used between the PEs (or NSPs) to set 749 up, maintain and tear down PWs, including any required 750 coordination of parameters. 752 o The PSN Tunnel signaling controls the PW multiplexing and some 753 elements of the underlying PSN. Examples are L2TP control 754 protocol, MPLS LDP and RSVP-TE. The definition of the 755 information that PWE3 needs to be signaled is within the scope 756 of PWE3, but the signaling protocol itself is not. 758 4.4 Protocol Stack Reference Model 760 Figure 7 illustrates the protocol stack reference model for PWs. 762 +-----------------+ +-----------------+ 763 |Emulated Service | |Emulated Service | 764 |(e.g. TDM, ATM) |<==== Emulated Service ===>|(e.g. TDM, ATM) | 765 +-----------------+ +-----------------+ 766 | Payload | | Payload | 767 | Encapsulation |<====== Pseudo Wire ======>| Encapsulation | 768 +-----------------+ +-----------------+ 769 |PW Demultiplexer | |PW Demultiplexer | 770 | PSN Tunnel, |<======= PSN Tunnel ======>| PSN Tunnel, | 771 | PSN & Physical | | PSN & Physical | 772 | Layers | | Layers | 773 +-------+---------+ ___________ +---------+-------+ 774 | / \ | 775 +===============/ PSN \===============+ 776 \ / 777 \_____________/ 779 Figure 7: PWE3 Protocol Stack Reference Model 781 The PW provides the CE with an emulated physical or virtual 782 connection to its peer at the far end. Native service PDUs from the 783 CE are passed through an Encapsulation Layer at the sending PE, and 784 then sent over the PSN. The receiving PE removes the encapsulation 785 and restores the payload to its native format for transmission to the 786 destination CE. 788 4.5 Pre-processing Extension to Protocol Stack Reference Model 790 Figure 8 illustrates how the protocol stack reference model is 791 extended to include the provision of pre-processing (Forwarding and 792 NSP). This shows the placement of the physical interface relative to 793 the CE. 795 /======================================\ 796 H Forwarder H<----Pre-processing 797 H----------------======================/ 798 H Native Service H | | 799 H Processing H | | 800 \================/ | | 801 | | | Emulated | 802 | Service | | Service | 803 | Interface | | (TDM, ATM, | 804 | (TDM, ATM, | | Ethernet, |<== Emulated Service == 805 | Ethernet, | | frame relay, | 806 | frame relay, | | etc.) | 807 | etc.) | +-----------------+ 808 | | | Payload | 809 | | | Encapsulation |<=== Pseudo Wire ====== 810 | | +-----------------+ 811 | | |PW Demultiplexer | 812 | | | PSN Tunnel, | 813 | | | PSN & Physical |<=== PSN Tunnel ======= 814 | | | Headers | 815 +----------------+ +-----------------+ 816 | Physical | | Physical | 817 +-------+--------+ +-------+---------+ 818 | | 819 | | 820 | | 821 | | 822 | | 823 | | 824 To CE <---+ +---> To PSN 826 Figure 8: Protocol Stack Reference Model with Pre-processing 828 5. PW Encapsulation 830 The PW Encapsulation Layer provides the necessary infrastructure to 831 adapt the specific payload type being transported over the PW to the 832 PW Demultiplexer Layer that is used to carry the PW over the PSN. 834 The PW Encapsulation Layer consists of three sub-layers: 836 o Payload Convergence 837 o Timing 838 o Sequencing 840 The PW Encapsulation sub-layering and its context with the protocol 841 stack are shown, in Figure 9. 843 +---------------------------+ 844 | Payload | 845 /===========================\ <------ Encapsulation 846 H Payload Convergence H Layer 847 H---------------------------H 848 H Timing H 849 H---------------------------H 850 H Sequencing H 851 \===========================/ 852 | PW Demultiplexer | 853 +---------------------------+ 854 | PSN Convergence | 855 +---------------------------+ 856 | PSN | 857 +---------------------------+ 858 | Data-link | 859 +---------------------------+ 860 | Physical | 861 +---------------------------+ 863 Figure 9: PWE3 Encapsulation Layer in Context 865 The Payload Convergence Sub-layer is highly tailored to the specific 866 payload type, but, by grouping a number of target payload types into 867 a generic class, and then providing a single convergence sub-layer 868 type common to the group, we achieve a reduction in the number of 869 payload convergence sub-layer types. This decreases implementation 870 complexity. The provision of per-packet signaling and other out-of- 871 band information (other than sequencing or timing) is undertaken by 872 this layer. 874 The Timing Layer and the Sequencing Layer provide generic services to 875 the Payload Convergence Layer for all payload types that require 876 them. 878 5.1 Payload Convergence Layer 880 5.1.1. Encapsulation 882 The primary task of the Payload Convergence Layer is the 883 encapsulation of the payload in PW-PDUs. The native data units to be 884 encapsulated MAY contain a L2 header or L1 overhead. This is service 885 specific. The Payload Convergence header carries the additional 886 information needed to replay the native data units at the CE-bound 887 physical interface. The PW Demultiplexer header is not considered as 888 part of the PW header. 890 Not all the additional information needed to replay the native data 891 units need to be carried in the PW header of the PW PDUs. Some 892 information (e.g. service type of a PW) MAY be stored as state 893 information at the destination PE during PW set-up. 895 5.1.2. PWE3 Channel Types 897 The PW Encapsulation Layer and its associated signaling require one 898 or more of the following types of channels from its underlying PW 899 Demultiplexer and PSN Layers: 901 1. A reliable control channel for signaling line events, status 902 indications, and, in some exceptional cases, CE-CE events 903 that must be translated and sent reliably between PEs. 905 For example, this capability is needed in [PPPoL2TP] 906 (PPP negotiation has to be split between the two ends of the 907 tunnel). PWE3 may also need this type of control channel to 908 provide faithful emulation of complex data-link protocols. 910 plus one or more data channels with the following characteristics: 912 2. A high-priority, unreliable, sequenced channel. A typical use 913 is for CE-to-CE signaling. "High priority" may simply be 914 indicated via the DSCP bits for IP or the EXP bits for MPLS, 915 giving the packet priority during transit. This channel type 916 could also use a bit in the tunnel header itself to indicate 917 that packets received at the PE SHOULD be processed with higher 918 priority [RFC2474]. 920 3. A sequenced channel for data traffic that is sensitive to 921 packet reordering (one classification for use could be for 922 any non-IP traffic). 924 4. An un-sequenced channel for data traffic insensitive to packet 925 order. 927 The data channels (2, 3 and 4 above) SHOULD be carried "in band" with 928 one another to as much of a degree as is reasonably possible on a 929 PSN. 931 Where end-to-end connectivity may be disrupted by address translation 932 [RFC3022], access-control lists, firewalls etc., there exists the 933 possibility that the control channel may be able to pass traffic and 934 set-up the PW, but the PW data traffic is blocked by one or more of 935 these mechanisms. In these cases unless the control channel is also 936 carried "in band" the signaling to set-up the PW will not confirm the 937 existence of an end-to-end data path. 939 In some cases there is a need to synchronize CE events with the data 940 carried over a PW. This is especially the case with TDM circuits 941 (e.g., the on-hook/off-hook events in PSTN switches might be carried 942 over a reliable control channel, whilst the associated bit-stream is 943 carried over a sequenced data channel). 945 PWE3 channel types that are not needed by the supported PWs need not 946 be included in such an implementation. 948 5.1.3. Quality of Service Considerations 950 Where possible, it is desirable to employ mechanisms to provide PW 951 Quality of Service (QoS) support over PSNs. 953 5.2 Payload-independent PW Encapsulation Layers 955 Two PWE3 Encapsulation Sub-layers provide common services to all 956 payload types: Sequencing and Timing. These services are optional 957 and are only used if needed by a particular PW instance. If the 958 service is not needed, the associated header MAY be omitted in order 959 to conserve processing and network resources. 961 There will be instances where a specific payload type will be 962 required to be transported with or without sequence and/or real-time 963 support. For example, an invariant of frame relay transport is the 964 preservation of packet order. Some frame-relay applications expect 965 in-order delivery, and may not cope with reordering of the frames. 966 However, where the frame relay service is itself only being used to 967 carry IP, it may be desirable to relax that constraint in return for 968 reduced per-packet processing cost. 970 The guiding principle is that, where possible, an existing IETF 971 protocol SHOULD be used to provide these services. Where a suitable 972 protocol is not available, the existing protocol should be extended 973 or modified to meet the PWE3 requirements, thereby making that 974 protocol available for other IETF uses. In the particular case of 975 timing, more than one general method may be necessary to provide for 976 the full scope of payload timing requirements. 978 5.2.1. Sequencing 980 The sequencing function provides three services: frame ordering, 981 frame duplication detection and frame loss detection. These services 982 allow the emulation of the invariant properties of a physical wire. 983 Support for sequencing depends on the payload type, and MAY be 984 omitted if not needed. 986 The size of the sequence-number space depends on the speed of the 987 emulated service, and the maximum time of the transient conditions in 988 the PSN. A sequence number space greater than 2^16 may therefore be 989 needed to prevent the sequence number space wrapping during the 990 transient. 992 5.2.1.1 Frame Ordering 994 When packets carrying the PW-PDUs traverse a PSN, they may arrive out 995 of order at the destination PE. For some services, the frames 996 (control frames, data frames, or both control and data frames) MUST 997 be delivered in order. For such services, some mechanism MUST be 998 provided for ensuring in-order delivery. Providing a sequence number 999 in the sequence sub-layer header for each packet is one possible 1000 approach to out-of-sequence detection. Alternatively it can be noted 1001 that sequencing is a subset of the problem of delivering timed 1002 packets, and that a single combined mechanism such as [RFC1889] MAY 1003 be employed. 1005 There are two possible misordering strategies: 1007 o Drop misordered PW PDUs. 1009 o Try to sort PW PDUs into the correct order. 1011 The choice of strategy will depend on: 1013 o How critical the loss of packets is to the operation of 1014 the PW (e.g. the acceptable bit error rate). 1016 o The speeds of the PW and PSN. 1018 o The acceptable delay (since delay must be introduced to 1019 reorder) 1021 o The incidence of expected misordering. 1023 5.2.1.2 Frame Duplication Detection 1025 In rare cases, packets traversing a PW may be duplicated by the 1026 underlying PSN. For some services frame duplication is not 1027 acceptable. For such services, some mechanism MUST be provided to 1028 ensure that duplicated frames will not be delivered to the 1029 destination CE. The mechanism MAY be the same as the mechanism used 1030 to ensure in-order frame delivery. 1032 5.2.1.3 Frame Loss Detection 1034 A destination PE can determine whether a frame has been lost by 1035 tracking the sequence numbers of the received PW PDUs. 1037 In some instances, a destination PE will have to presume that a PW 1038 PDU is lost if it fails to arrive within a certain time. If a PW-PDU 1039 that has been processed as lost subsequently arrives, the destination 1040 PE MUST discard it. 1042 5.2.2. Timing 1044 A number of native services have timing expectations based on the 1045 characteristics of the networks that they were designed to travel 1046 over, and it can be necessary for the emulated service to duplicate 1047 these network characteristics as closely as possible, e.g. in 1048 delivering native traffic with bit-rate, jitter, wander and delay 1049 characteristics similar to those received at the sending PE. 1051 In such cases, it is necessary for the receiving PE to play out the 1052 native traffic as it was received at the sending PE. This relies on 1053 either timing information sent between the two PEs, or in some case 1054 timing information received from an external reference. 1056 The Timing Sub-layer must therefore support two timing functions: 1057 clock recovery and timed payload delivery. A particular payload type 1058 may require either or both of these services. 1060 5.2.2.1 Clock Recovery 1062 Clock recovery is the extraction of output transmission bit timing 1063 information from the delivered packet stream, and requires a suitable 1064 mechanism. A physical wire carries the timing information natively, 1065 but it is a relatively complex task to extract timing from a highly 1066 jittered source such as packet stream. It is therefore desirable 1067 that an existing real-time protocol such as [RFC1889] be used for 1068 this purpose, unless it can be shown that this is unsuitable or 1069 unnecessary for a particular payload type. 1071 5.2.2.2 Timed delivery 1073 Timed delivery is the delivery of non-contiguous PW PDUs to the PW 1074 output interface with a constant phase relative to the input 1075 interface. The timing of the delivery may be relative to a clock 1076 derived from the packet stream received over the PSN clock recovery, 1077 or with reference to an external clock. 1079 5.3 Fragmentation 1081 A payload would ideally be relayed across the PW as a single unit. 1082 However, there will be cases where the combined size of the payload 1083 and its associated PWE3 and PSN headers exceeds the PSN path MTU. 1084 When a packet size exceeds the MTU of a given network, fragmentation 1085 and reassembly have to be performed in order for the packet to be 1086 delivered. Since fragmentation and reassembly generally consume a 1087 considerable network resources as compared to simply switching a 1088 packet in its entirety, efforts SHOULD be made to reduce or eliminate 1089 the need for fragmentation and reassembly throughout a network to the 1090 extent possible. Of particular concern for fragmentation and 1091 reassembly are aggregation points where large numbers of PWs are 1092 processed (e.g. at the PE). 1094 Ideally, the equipment originating the traffic being sent over the PW 1095 will be configured to have adaptive measures (e.g. [RFC1191], 1096 [RFC1981]) in place that ensure that packets that need to be 1097 fragmented are not sent. When this fails, the point closest to the 1098 sending host with fragmentation and reassembly capabilities SHOULD 1099 attempt to reduce the size of packets to satisfy the PSN MTU. Thus, 1100 in the reference model for PWE3 [Figure 3] fragmentation SHOULD first 1101 be performed at the CE if at all possible. If and only if the CE 1102 cannot adhere to an acceptable MTU size for the PW should the PE 1103 attempt its own fragmentation method. 1105 In cases where MTU management fails to limit the payload to a size 1106 suitable for transmission of the PW, the PE MAY fall back to either a 1107 generic PW fragmentation method, or, if available the fragmentation 1108 service of the underlying PSN. 1110 It is acceptable for a PE implementation not to support 1111 fragmentation. A PE that does not support fragmentation will drop 1112 packets that exceed the PSN MTU, and the management plane of the 1113 encapsulating PE MAY be notified. 1115 If the length of a L2/L1 frame, restored from a PW PDU, exceeds the 1116 MTU of the destination PWES, it MUST be dropped. In this case, the 1117 management plane of the destination PE MAY be notified. 1119 5.4 Instantiation of the Protocol Layers 1121 This document does not address the detailed mapping of the Protocol 1122 Layering model to existing or future IETF standards. The 1123 instantiation of the logical Protocol Layering model is shown in 1124 Figure 9. 1126 5.4.1. PWE3 over an IP PSN 1128 The protocol definition of PWE3 over an IP PSN SHOULD employ existing 1129 IETF protocols where possible. 1131 +---------------------+ +-------------------------+ 1132 | Payload |------------->| Raw payload if possible | 1133 /=====================\ +-------------------------+ 1134 H Payload Convergence H------------->| As Needed | 1135 H---------------------H +-------------------------+ 1136 H Timing H----------+-->| RTP | 1137 H---------------------H / +-------------+ | 1138 H Sequencing H----one of | | 1139 \=====================/ \ | +-----------+ 1140 | PW Demultiplexer |----------+-->| L2TP, MPLS etc. | 1141 +---------------------+ +-------------------------+ 1142 | PSN Convergence |------------->| Not needed | 1143 +---------------------+ +-------------------------+ 1144 | PSN |------------->| IP | 1145 +---------------------+ +-------------------------+ 1146 | Data-link |------------->| Data-link | 1147 +---------------------+ +-------------------------+ 1148 | Physical |------------->| Physical | 1149 +---------------------+ +-------------------------+ 1151 Figure 10: PWE3 over an IP PSN 1153 Figure 10 shows the protocol layering for PWE3 over an IP PSN. As a 1154 rule, the payload SHOULD be carried as received from the NSP, with 1155 the Payload Convergence Layer provided when needed. (It is accepted 1156 that there MAY sometimes be good reason not to follow this rule, but 1157 the exceptional circumstances need to be documented in the 1158 Encapsulation Layer definition for that payload type). 1160 Where appropriate, timing is provided by RTP [RFC1889], which when 1161 used also provides a sequencing service. PW Demultiplexing may be 1162 provided by a number of existing IETF tunnel protocols. Some of 1163 these tunnel protocols provide an optional sequencing service. 1164 (Sequencing is provided either by RTP, or by the PW Demultiplexer 1165 Layer, but not both). A PSN Convergence Layer is not needed, because 1166 all the tunnel protocols shown above are designed to operate directly 1167 over an IP PSN. 1169 As a special case, if the PW Demultiplexer is an MPLS label, the 1170 protocol architecture of section 5.4.2 can be used instead of the 1171 protocol architecture of this section. 1173 5.4.2. PWE3 over an MPLS PSN 1175 The MPLS ethos places importance on wire efficiency. By using a 1176 control word, some components of the PWE3 protocol layers can be 1177 compressed to increase this efficiency. 1179 +---------------------+ 1180 | Payload | 1181 /=====================\ 1182 H Payload Convergence H-----+ 1183 H---------------------H | 1184 H Timing H------------------------+ 1185 H---------------------H | | 1186 H Sequencing H-----| | 1187 \=====================/ | | 1188 | PW Demultiplexer |---+ | v 1189 +---------------------+ | | +--------------------------------+ 1190 | PSN Convergence |-----| . . 1191 +---------------------+ | | . RTP . 1192 | PSN |-+ | | | | 1193 +---------------------+ | | | +--------------------------------+ 1194 | Data-link | | | +->| Flags, Frag, Len, Seq #, etc | 1195 +---------------------+ | | +--------------------------------+ 1196 | Physical | | +--->| PW Label | 1197 +---------------------+ | +--------------------------------+ 1198 +----->| Outer Label or MPLS-in-IP encap| 1199 +--------------------------------+ 1201 Figure 11: PWE3 over an MPLS PSN using a control word 1203 Figure 11 shows the protocol layering for PWE3 over an MPLS PSN. An 1204 inner MPLS label is used to provide the PW demultiplexing function. 1205 A control word is used to carry most of the information needed by the 1206 PWE3 Encapsulation Layer and the PSN Convergence Layer in a compact 1207 format. The flags in the control word provide the necessary payload 1208 convergence. A sequence field provides support for both in-order 1209 payload delivery and (supported by a fragmentation control method) a 1210 PSN fragmentation service within the PSN Convergence Layer. Ethernet 1211 pads all frames to a minimum size of 64 bytes. The MPLS header does 1212 not include a length indicator. Therefore to allow PWE3 to be carried 1213 in MPLS to correctly pass over an Ethernet data-link, a length 1214 correction field is needed in the control word. As with an IP PSN, 1215 where appropriate, timing is provided by RTP [RFC1889]. 1217 In some networks it may be necessary to carry PWE3 over MPLS over IP. 1218 In these circumstances, the PW is encapsulated for carriage over MPLS 1219 as described in this section, and then a method of carrying MPLS over 1220 an IP PSN (such as GRE [RFC2784], [RFC2890]) is applied to the 1221 resultant PW-PDU. 1223 5.4.3. PW over MPLS Generic Control Word 1225 The PW set-up protocol determines whether a particular PW uses a 1226 control word. When a control word is used, it MUST have the 1227 following form: 1229 0 1 2 3 1230 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 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | PID | Flags |FRG| Length | Sequence Number | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 Figure 12 - MPLS Generic Control Word 1237 The meaning of the fields of the MPLS Generic Control Word (Figure 1238 12) is as follows: 1240 PID (bits 0 to 3): 1241 In an environment in which all PWs use the control word, 1242 the payload type of an MPLS packet can be determined by 1243 inspecting the first four bits of the longword, which 1244 follows the bottom of the label stack. A value of 0 1245 indicates "pseudowire", 4 indicates IPv4, 6 indicates IPv6. 1247 Flags (bits 4 to 7): 1248 These bits are available for per payload signaling. Their 1249 definition is encapsulation specific. 1251 FRG (bits 8 and 9): 1252 These bits are used when fragmenting a PW payload. Their use 1253 is defined in [FRAG]. 1255 Length (bits 10 to 15): 1256 The length field is used to determine the size of a PW 1257 payload that might have been padded to the minimum Ethernet 1258 MAC frame size during its transit across the PSN. If the 1259 MPLS payload (defined as the CW + the PW payload + any 1260 additional PW headers is less than 46 bytes, the length MUST 1261 be set to the length of the MPLS payload. If the MPLS 1262 payload is between 46 bytes and 63 bytes the implementation 1263 MAY either set to the length to the length of the MPLS 1264 payload, or it MAY set it to 0. If the length of the MPLS 1265 payload is greater than 63 bytes the length MUST be set to 0. 1267 Sequence number (Bit 16 to 31): 1268 If the sequence number is not used, it is set to zero by 1269 the sender and ignored by the receiver. Otherwise it 1270 specifies the sequence number of a packet. A circular list 1271 of sequence numbers is used. A sequence number takes a value 1272 from 1 to 65535 (2**16-1). 1274 6. PW Demultiplexer Layer and PSN Requirements 1276 PWE3 places three service requirements on the protocol layers used to 1277 carry it across the PSN: 1279 o Multiplexing 1280 o Fragmentation 1281 o Length and Delivery 1283 6.1 Multiplexing 1285 The purpose of the PW Demultiplexer Layer is to allow multiple PWs to 1286 be carried in a single tunnel. This minimizes complexity and 1287 conserves resources. 1289 Some types of native service are capable of grouping multiple 1290 circuits into a "trunk", e.g. multiple ATM VCs in a VP, multiple 1291 Ethernet VLANs on a physical media, or multiple DS0 services within a 1292 T1 or E1. A PW MAY interconnect two end-trunks. That trunk would 1293 have a single multiplexing identifier. 1295 6.2 Fragmentation 1297 If the PSN provides a fragmentation and reassembly service of 1298 adequate performance, it MAY be used to obtain an effective MTU that 1299 is large enough to transport the PW PDUs. See Section 5.3 for a full 1300 discussion of the PW fragmentation issues. 1302 6.3 Length and Delivery 1304 PDU delivery to the egress PE is the function of the PSN Layer. 1306 If the underlying PSN does not provide all the information necessary 1307 to determine the length of a PW-PDU, the Encapsulation Layer MUST 1308 provide it. 1310 6.4 PW-PDU Validation 1312 It is a common practice to use an error detection mechanism such as a 1313 CRC or similar mechanism to assure end-to-end integrity of frames. 1315 The PW service-specific mechanisms MUST define whether the packet's 1316 checksum shall be preserved across the PW, or be removed from PE- 1317 bound PDUs and then be re-calculated for insertion in CE-bound data. 1319 The former approach saves work, while the latter saves bandwidth. For 1320 a given implementation the choice may be dictated by hardware 1321 restrictions, which may not allow the preservation of the checksum. 1323 For protocols such as ATM and FR, the scope of the checksum is 1324 restricted to a single link. This is because the circuit identifiers 1325 (e.g. FR DLCI or ATM VPI/VCI) have only local significance and are 1326 changed on each hop or span. If the circuit identifier (and thus 1327 checksum) were going to change as a part of the PW emulation, it 1328 would be more efficient to strip and re-calculate the checksum. 1330 The service specific document for each protocol MUST describe the 1331 validation scheme to be used. 1333 6.5 Congestion Considerations 1335 The PSN carrying the PW may be subject to congestion. The congestion 1336 characteristics will vary with the PSN type, the network architecture 1337 and configuration, and the loading of the PSN. 1339 Where the traffic carried over the PW is known to be TCP friendly 1340 (by, for example, packet inspection), packet discard in the PSN will 1341 trigger the necessary reduction in offered load, and no additional 1342 congestion avoidance action is necessary. 1344 If the PW is operating over a PSN that provides enhanced delivery, 1345 the PEs SHOULD monitor packet loss to ensure that the service that 1346 was requested is actually being delivered. If it is not, then the PE 1347 SHOULD assume that the PSN is providing a best-effort service, and 1348 SHOULD use the best-effort service congestion avoidance measures 1349 described below. 1351 If best-effort service is being used and the trafic is not known to 1352 be TCP friendly, the PEs SHOULD monitor packet loss to ensure that 1353 the packet loss rate is within acceptable parameters. Packet loss is 1354 considered acceptable if a TCP flow across the same network path and 1355 experiencing the same network conditions would achieve an average 1356 throughput, measured on a reasonable timescale, that is not less than 1357 the PW flow is achieving. This condition can be satisfied by 1358 implementing a rate-limiting measure in the NSP, or by shutting down 1359 one or more PWs. The choice of which approach to use depends upon 1360 the type of traffic being carried. Where congestion is avoided by 1361 shutting down a PW, a suitable mechanism MUST be provided to prevent 1362 it immediately returning to service, causing a series of congestion 1363 pulses. 1365 The comparison to TCP cannot be specified exactly, but is intended as 1366 an "order-of-magnitude" comparison in timescale and throughput. The 1367 timescale on which TCP throughput is measured is the round-trip time 1368 of the connection. In essence, this requirement states that it is not 1369 acceptable to deploy an application (using PWE3 or any other 1370 transport protocol) on the best-effort Internet which consumes 1371 bandwidth arbitrarily and does not compete fairly with TCP within an 1372 order of magnitude. One method of determining an acceptable PW 1373 bandwidth is described in [TFRC]. 1375 7. Control Plane 1377 This section describes PWE3 control plane services. 1379 7.1 Set-up or Teardown of Pseudo-Wires 1381 A PW MUST be set up before an emulated service can be established, 1382 and MUST be torn down when an emulated service is no longer needed. 1384 Set up or teardown of a PW can be triggered by an operator command, 1385 from the management plane of a PE, by signaling (i.e., set-up or 1386 teardown) of a PWES, e.g., an ATM SVC, or by an auto-discovery 1387 mechanism. 1389 During the set-up process, the PEs need to exchange some information 1390 (e.g. learn each other's capabilities). The tunnel signaling 1391 protocol MAY be extended to provide mechanisms to enable the PEs to 1392 exchange all necessary information on behalf of the PW. 1394 Manual configuration of PWs can be considered a special kind of 1395 signaling, and is allowed. 1397 7.2 Status Monitoring 1399 Some native services have mechanisms for status monitoring. For 1400 example, ATM supports OAM for this purpose. For such services, the 1401 corresponding emulated services MUST specify how to perform status 1402 monitoring. 1404 7.3 Notification of Pseudo-wire Status Changes 1406 7.3.1. Pseudo-wire Up/Down Notification 1408 If a native service REQUIRES bi-directional connectivity, the 1409 corresponding emulated service can only be signaled as being up when 1410 the associated PWs, and PSN tunnels if any, are functional in both 1411 directions. 1413 Because the two CEs of an emulated service are not adjacent, a 1414 failure may occur at a place such that one or both physical links 1415 between the CEs and PEs remain up. For example, in Figure 2, if the 1416 physical link between CE1 and PE1 fails, the physical link between 1417 CE2 and PE2 will not be affected and will remain up. Unless CE2 is 1418 notified about the remote failure, it will continue to send traffic 1419 over the emulated service to CE1. Such traffic will be discarded at 1420 PE1. Some native services have failure notification so that when the 1421 services fail, both CEs will be notified. For such native services, 1422 the corresponding PWE3 service MUST provide a failure notification 1423 mechanism. 1425 Similarly, if a native service has notification mechanisms so that 1426 when a network failure is fixed, all the affected services will 1427 change status from "Down" to "Up", the corresponding emulated service 1428 MUST provide a similar mechanism for doing so. 1430 These mechanisms may already be built into the tunneling protocol. 1431 For example, the L2TP control protocol [RFC2661] [L2TPv3] has this 1432 capability and LDP has the ability to withdraw the corresponding MPLS 1433 label. 1435 7.3.2. Misconnection and Payload Type Mismatch 1437 With PWE3, misconnection and payload type mismatch can occur. If a 1438 misconnection occurs it can breach the integrity of the system. If a 1439 payload mismatch occurs it can disrupt the customer network. In both 1440 instances, there are security and operational concerns. 1442 The services of the underlying tunneling mechanism, and its 1443 associated control protocol, can be used to mitigate this. As part 1444 of the PW set-up a PW-TYPE identifier is exchanged. This is then used 1445 by the FWRD and NSP to verify the compatibility of the PWESs. 1447 7.3.3. Packet Loss, Corruption, and Out-of-order Delivery 1449 A PW can incur packet loss, corruption, and out-of-order delivery on 1450 the PSN path between the PEs. This can impact the working condition 1451 of an emulated service. For some payload types, packet loss, 1452 corruption, and out-of-order delivery can be mapped to either a bit 1453 error burst, or loss of carrier on the PW. If a native service has 1454 some mechanism to deal with bit error, the corresponding PWE3 service 1455 should provide a similar mechanism. 1457 7.3.4. Other Status Notification 1459 A PWE3 approach MAY provide a mechanism for other status 1460 notification, if any are needed. 1462 7.3.5. Collective Status Notification 1464 Status of a group of emulated services may be affected identically by 1465 a single network incident. For example, when the physical link (or 1466 sub-network) between a CE and a PE fails, all the emulated services 1467 that go through that link (or sub-network) will fail. It is likely 1468 that there exists a group of emulated services that all terminate at 1469 a remote CE. There may also be multiple such CEs affected by the 1470 failure. Therefore, it is desirable that a single notification 1471 message be used to notify failure of the whole group of emulated 1472 services. 1474 A PWE3 approach MAY provide some mechanism for notifying status 1475 changes of a group of emulated circuits. One possible method is to 1476 associate each emulated service with a group ID when the PW for that 1477 emulated service is set up. Multiple emulated services can then be 1478 grouped by associating them with the same group ID. In status 1479 notification, that group ID can be used to refer all the emulated 1480 services in that group. The group ID mechanism should be a mechanism 1481 provided by the underlying tunnel signaling protocol. 1483 7.4 Keep-alive 1485 If a native service has a keep-alive mechanism, the corresponding 1486 emulated service MUST provide a mechanism to propagate this across 1487 the PW. An approach following the principle of minimum intervention 1488 would be to transparently transport keep-alive messages over the PW. 1489 However, to accurately reproduce the semantics of the native 1490 mechanism, some PWs MAY REQUIRE an alternative approach, such as 1491 piggy-backing on the PW signaling mechanism. 1493 7.5 Handling Control Messages of the Native Services 1495 Some native services use control messages for circuit maintenance. 1496 These control messages MAY be in-band, e.g. Ethernet flow control, 1497 ATM performance management, or TDM tone signaling, or they MAY be 1498 out-of-band, e.g. the signaling VC of an ATM VP, or TDM CCS 1499 signaling. 1501 From the principle of minimum intervention, it is desirable that the 1502 PEs participate as little as possible in the signaling and 1503 maintenance of the native services. This principle SHOULD NOT, 1504 however, override the need to satisfactorily emulate the native 1505 service. 1507 If control messages are passed through, it may be desirable to send 1508 them using either a higher priority or a reliable channel provided by 1509 the PW Demultiplexer layer. See PWE3 Channel Types. 1511 8. Management and Monitoring 1513 This section describes the management and monitoring architecture for 1514 PWE3. 1516 8.1 Status and Statistics 1518 The PE should report the status of the interface and tabulate 1519 statistics that help monitor the state of the network, and to help 1520 with measurement of service level agreements (SLAs). Typical counters 1521 include: 1523 o Counts of PW-PDUs sent and received, with and without errors. 1524 o Counts of sequenced PW-PDUs lost. 1525 o Counts of service PDUs sent and received over the PSN, with 1526 and without errors (non-TDM). 1527 o Service-specific interface counts. 1528 o One way delay and delay variation. 1530 These counters would be contained in a PW-specific MIB, and they 1531 should not replicate existing MIB counters. 1533 8.2 PW SNMP MIB Architecture 1535 This section describes the general architecture for SNMP MIBs used to 1536 manage PW services and the underlying PSN. The intent here is to 1537 provide a clear picture of how all of the pertinent MIBs fit together 1538 to form a cohesive management framework for deploying PWE3 services. 1540 8.2.1. MIB Layering 1542 The SNMP MIBs created for PWE3 should fit the architecture shown in 1543 Figure 13. 1545 +-----------+ +-----------+ +-----------+ 1546 Service | CEM | | Ethernet | | ATM | 1547 Layer |Service MIB| |Service MIB| ... |Service MIB| 1548 +-----------+ +-----------+ +-----------+ 1549 \ | / 1550 \ | / 1551 - - - - - - - - - - - - \ - - - | - - - - / - - - - - - - 1552 \ | / 1553 +-------------------------------------------+ 1554 Generic PW | Generic PW MIBs | 1555 Layer +-------------------------------------------+ 1556 / \ 1557 - - - - - - - - - - - - / - - - - - - - - \ - - - - - - - 1558 / \ 1559 / \ 1560 +-----------+ +-----------+ 1561 PSN VC |L2TP VC MIB| |MPLS VC MIB| 1562 Layer +-----------+ +-----------+ 1563 | | 1564 - - - - - - - - - | - - - - - - - - - - - - - - - | - - - 1565 | | 1566 +-----------+ +-----------+ 1567 PSN |L2TP MIB(s)| |MPLS MIB(s)| 1568 Layer +-----------+ +-----------+ 1570 Figure 13: Relationship of SNMP MIBs 1572 Figure 14 shows an example for a SONET PW carried over MPLS. 1574 +-----------------+ 1575 | SONET MIB | RFC2558 1576 +-----------------+ 1577 | 1578 +-----------------+ 1579 Service |SONET Service MIB| pw-cem-mib 1580 Layer +-----------------+ 1581 - - - - - - - - - - | - - - - - - - - - - - - - - - 1582 +-----------------+ 1583 Generic PW | Generic PW MIBS | pw-tc-mib 1584 Layer +-----------------+ pw-mib 1585 - - - - - - - - - - | - - - - - - - - - - - - - - - 1586 +-----------------+ 1587 PSN VC | MPLS VC MIBS | pw-mpls-mib 1588 Layer +-----------------+ 1589 - - - - - - - - - - | - - - - - - - - - - - - - - - 1590 +-----------------+ 1591 PSN | MPLS MIBs | mpls-te-mib 1592 Layer +-----------------+ mpls-lsr-mib 1594 Figure 14: Service-specific Example for MIBs 1596 Note that there is a separate MIB for each emulated service as well 1597 as one for each underlying PSN. These MIBs MAY be used in various 1598 combinations as needed. 1600 8.2.2. Service Layer MIBs 1602 The first layer is referred to as the Service Layer. It contains 1603 MIBs for PWE3 services such as Ethernet, ATM, circuits and Frame 1604 Relay. This layer contains those corresponding MIBs used to mate or 1605 adapt those emulated services to the underlying services. This 1606 working group should not produce any MIBs for managing the general 1607 service; rather, it should produce just those MIBs that are used to 1608 interface or adapt the emulated service onto the PWE3 management 1609 framework. For example, the standard SONET MIB [SONETMIB] is 1610 designed and maintained by another working group. Also, the SONET MIB 1611 is designed to manage the native service without PW emulation. Since 1612 the PWE3 working group is chartered to produce the corresponding 1613 adaptation MIB, in this case, it would produce the PW-CEM-MIB 1614 [PWMPLSMIB] that would be used to adapt SONET services to the 1615 underlying PSN that carries the PWE3 service. 1617 8.2.3. Generic PW MIBs 1619 The second layer is referred to as the Generic PW Layer. This layer 1620 is composed of two MIBs: the PWE-TC-MIB [PWTCMIB] and the PWE-MIB 1621 [PWMIB]. These MIBs are responsible for providing general PWE3 1622 counters and service models used for monitoring and configuration of 1623 PWE3 services over any supported PSN service. That is, this MIB 1624 provides a general model of PWE3 abstraction for management purposes. 1625 This MIB is used to interconnect the Service Layer MIBs to the PSN VC 1626 Layer MIBs. The latter will be described in the next section. This 1627 layer also provides the PW-TC-MIB [PWTCMIB]. This MIB contains 1628 common SMI textual conventions [RFC1902] that MAY be used by any PW 1629 MIB. 1631 8.2.4. PSN VC Layer MIBs 1633 The third layer in the PWE3 management architecture is referred to as 1634 the PSN VC layer. This layer is comprised of MIBs that are 1635 specifically designed to interface general PWE3 services (VCs) onto 1636 those underlying PSN services. In general this means that the MIB 1637 provides a means with which an operator can map the PW service onto 1638 the native PSN service. For example, in the case of MPLS, it is 1639 required that the general VC service be layered onto MPLS LSPs or 1640 Traffic Engineered (TE) Tunnels [RFC3031]. In this case, the PW- 1641 MPLS-MIB [PWMPLSMIB] was created to adapt the general PWE3 circuit 1642 services onto MPLS. Like the Service Layer described above the PWE3 1643 working group should produce these MIBs. 1645 8.2.5. PSN Layer MIBs 1647 The fourth and final layer in the PWE3 management architecture is 1648 referred to as the PSN layer. This layer is comprised of those MIBs 1649 that control the PSN service-specific services. For example, in the 1650 case of the MPLS [RFC3031] PSN service, the MPLS-LSR-MIB [LSRMIB] and 1651 the MPLS-TE-MIB [TEMIB] are used to interface the general PWE3 VC 1652 services onto native MPLS LSPs and/or TE tunnels to carry the 1653 emulated services. In addition, the MPLS-LDP-MIB [LDPMIB] MAY be 1654 used to reveal the MPLS labels that are distributed over the MPLS PSN 1655 in order to maintain the PW service. The MIBs in this layer are 1656 produced by other working groups that design and specify the native 1657 PSN services. These MIBs should contain the appropriate mechanisms 1658 for monitoring and configuring the PSN service such that the emulated 1659 PWE3 service will function correctly. 1661 8.3 Connection Verification and Traceroute 1663 A connection verification mechanism should be supported by PWs. 1664 Connection verification as well as other alarm mechanisms can alert 1665 the operator that a PW has lost its remote connection. The opaque 1666 nature of a PW means that it is not possible to specify a generic 1667 connection verification or traceroute mechanism that passes this 1668 status to the CEs over the PW. If connection verification status of 1669 the PW is needed by the CE, it MUST be mapped to the native 1670 connection status method. 1672 For troubleshooting purposes, it is sometimes desirable to know the 1673 exact functional path of a PW between PEs. This is provided by the 1674 traceroute service of the underlying PSN. The opaque nature of the 1675 PW means that this traceroute information is only available within 1676 the provider network, e.g., at the PEs. 1678 9. IANA considerations 1680 The control word PID bits need to be assigned by IANA. 1682 10. Security Considerations 1684 PWE3 provides no means of protecting the contents or delivery of the 1685 native data units. The use of PWE3 can therefore expose a particular 1686 environment to additional security threats. Assumptions that might be 1687 appropriate when all communicating systems are interconnected via a 1688 point to point or circuit-switched network may no longer hold when 1689 they are interconnected using an emulated wire carried over some 1690 types of PSN. It is outside the scope of this specification, to 1691 fully analyze and review the risks of PWE3, particularly as these 1692 risks will depend on the PSN. An example should make the concern 1693 clear. A number of IETF standards employ relatively weak security 1694 mechanisms when communicating nodes are expected to be connected to 1695 the same local area network. The Virtual Router Redundancy Protocol 1696 [RFC2338] is one instance. The relatively weak security mechanisms 1697 represent a greater vulnerability in an emulated Ethernet connected 1698 via a PW. 1700 Exploitation of vulnerabilities from within the PSN may be directed 1701 to the PW Tunnel end-point so that PW Demultiplexer and PSN tunnel 1702 services are disrupted. Controlling PSN access to the PW Tunnel 1703 end-point is one way to protect against this. By restricting PW 1704 Tunnel end-point access to legitimate remote PE sources of traffic, 1705 the PE may reject traffic that would interfere with the PW 1706 Demultiplexing and PSN tunnel services. 1708 Protection mechanisms MUST also address the spoofing of tunneled PW 1709 data. The validation of traffic addressed to the PW Demultiplexer 1710 end-point is paramount in ensuring integrity of PW encapsulation. 1711 Security protocols such as IPSec [RFC2401] MAY be used by the PW 1712 Demultiplexer Layer in order to maintain the integrity of the PW by 1713 authenticating data between the PW Demultiplexer End-points. IPSec 1714 MAY provide authentication, integrity, non-repudiation, and 1715 confidentiality of data transferred between two PEs. It cannot 1716 provide the equivalent services to the native service. 1718 Based on the type of data being transferred, the PW MAY indicate to 1719 the PW Demultiplexer Layer that enhanced security services are 1720 required. The PW Demultiplexer Layer MAY define multiple protection 1721 profiles based on the requirements of the PW emulated service. CE- 1722 to-CE signaling and control events emulated by the PW and some data 1723 types may require additional protection mechanisms. Alternatively, 1724 the PW Demultiplexer Layer may use peer authentication for every PSN 1725 packet to prevent spoofed native data units from being sent to the 1726 destination CE. 1728 Acknowledgments 1730 We thank: Sasha Vainshtein for his work on Native Service Processing 1731 and advice on bit-stream over PW services. Thomas K. Johnson for his 1732 work on the background and motivation for PWs. 1734 We also thank: Ron Bonica, Stephen Casner, Durai Chinnaiah, Jayakumar 1735 Jayakumar, Ghassem Koleyni, Eric Rosen, John Rutemiller, Scott 1736 Wainner and David Zelig for their comments and contributions. 1738 References 1740 Internet-drafts are works in progress available from 1741 1743 [DVB] EN 300 744 Digital Video Broadcasting (DVB); Framing 1744 structure, channel coding and modulation for digital 1745 terrestrial television (DVB-T), European 1746 Telecommunications Standards Institute (ETSI) 1748 [FRAG] Malis and Townsley, "PWE3 Fragmentation and 1749 Reassembly", , 1750 work in progress, October 2002. 1752 [LDP-MIB] Cucchiara, J., Sjostrand, H., and Luciani, J., 1753 "Definitions of Managed Objects for the Multiprotocol 1754 Label Switching, Label Distribution Protocol (LDP)", 1755 , work in progress, 1756 October 2002. 1758 [LSRMIB] Srinivasan et al, "MPLS Label Switch Router Management 1759 Information Base Using SMIv2", 1760 , work in progress, 1761 October 2002. 1763 [L2TPv3] Layer Two Tunneling Protocol (Version 3)'L2TPv3', J Lau, 1764 et. al. , work 1765 in progress, January 2003. 1767 [PPPoL2TP] PPP Tunneling Using Layer Two Tunneling Protocol, 1768 J Lau et al. , 1769 work in progress, June 2002. 1771 [PWMIB] Zelig et al, "Pseudo Wire (PW) Management Information 1772 Base Using SMIv2", , 1773 work in progress, June 2002. 1775 [PWTCMIB] Nadeau et al, "Definitions for Textual Conventions and 1776 OBJECT-IDENTITIES for Pseudo-Wires Management" 1777 , work in progress, 1778 June 2002. 1780 [PWMPLSMIB] Danenberg et al, "SONET/SDH Circuit Emulation Service 1781 Over MPLS (CEM) Management Information Base Using 1782 SMIv2", , work in 1783 progress, October 2002. 1785 [RFC1191] RFC-1191: Path MTU discovery. J.C. Mogul, S.E. Deering. 1787 [RFC1889] RFC-1889: RTP: A Transport Protocol for Real-Time 1788 Applications. H. Schulzrinne et. al. 1790 [RFC1902] RFC-1902: Structure of Management Information for 1791 Version 2 of the Simple Network Management Protocol 1792 (SNMPv2), Case et al, January 1996. 1794 [RFC1958] RFC-1958: Architectural Principles of the Internet, 1795 B. Carpenter et al. 1797 [RFC1981] RFC-1981: Path MTU Discovery for IP version 6. J. McCann, 1798 S. Deering, J. Mogul. 1800 [RFC2022] RFC-2022: Support for Multicast over UNI 3.0/3.1 based 1801 ATM Networks, G. Armitage. 1803 [RFC2119] RFC-2119, BCP-14: Key words for use in RFCs to Indicate 1804 Requirement Levels, S. Bradner. 1806 [RFC2338] RFC-2338: Virtual Router Redundancy Protocol, 1807 S. Knight, M. Shand et. al. 1809 [RFC2401] RFC-2401: Security Architecture for the Internet 1810 Protocol. S. Kent, R. Atkinson. 1812 [RFC2474] RFC-2474: Definition of the Differentiated Services 1813 Field (DS Field) in the IPv4 and IPv6 Headers, 1814 K. Nichols, et. al. 1816 [RFC2661] RFC-2661: Layer Two Tunneling Protocol "L2TP". 1817 W. Townsley, et. al. 1819 [RFC2784] RFC-2784: Generic Routing Encapsulation (GRE). 1820 D. Farinacci et al. 1822 [RFC2890] RFC-2890: Key and Sequence Number Extensions to GRE. 1823 G. Dommety. 1825 [RFC3022] RFC-3022: Traditional IP Network Address Translator 1826 (Traditional NAT). P Srisuresh et al. 1828 [RFC3031] RFC3031: Multiprotocol Label Switching Architecture, 1829 E. Rosen, January 2001. 1831 [SONETMIB] K. Tesink, "Definitions of Managed Objects for the 1832 SONET/SDH Interface Type", RFC2558, March 1999. 1834 [TEMIB] Srinivasan et al, "Traffic Engineering Management 1835 Information Base Using SMIv2", 1836 , work in progress, 1837 November 2002. 1839 [TFRC] M. Handley et al, "TCP Friendly Rate Control (TFRC): 1840 Protocol Specification" , 1841 work in progress, October 2002. 1843 [VPLS] M. Lasserre, "Virtual Private LAN Services over MPLS", 1844 , work in 1845 progress, January 2003. 1847 [XIAO] Xiao et al, "Requirements for Pseudo-Wire Emulation 1848 Edge-to-Edge (PWE3)", 1849 (draft-ietf-pwe3-requirements-04.txt), X Xiao et al. 1850 work in progress, December 2002. 1852 Editors' Addresses 1854 Stewart Bryant 1855 Cisco Systems, 1856 4, The Square, 1857 Stockley Park, 1858 Uxbridge UB11 1BL, 1859 United Kingdom. Email: stbryant@cisco.com 1861 Prayson Pate 1862 Overture Networks, Inc. 1863 Airport Boulevard 1864 Morrisville, NC, USA 27560 Email: prayson.pate@overturenetworks.com 1866 Full copyright statement 1868 Copyright (C) The Internet Society (2002). 1869 All Rights Reserved. 1871 This document and translations of it may be copied and 1872 furnished to others, and derivative works that comment 1873 on or otherwise explain it or assist in its implementation 1874 may be prepared, copied, published and distributed, in 1875 whole or in part, without restriction of any kind, 1876 provided that the above copyright notice and this 1877 paragraph are included on all such copies and derivative works. 1878 However, this document itself may not be modified in any way, 1879 such as by removing the copyright notice or references to the 1880 Internet Society or other Internet organizations, except as 1881 needed for the purpose of developing Internet standards in 1882 which case the procedures for copyrights defined in the 1883 Internet Standards process must be followed, or as required to 1884 translate it into languages other than English. 1886 The limited permissions granted above are perpetual and will 1887 not be revoked by the Internet Society or its successors or assigns. 1889 This document and the information contained herein is provided 1890 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1891 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1892 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 1893 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 1894 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1895 FOR A PARTICULAR PURPOSE.