idnits 2.17.1 draft-ietf-pwe3-arch-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 264 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 (March 2003) is 7685 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 1106, but not defined == Unused Reference: 'FRAG' is defined on line 1735, but no explicit reference was found in the text == Unused Reference: 'RFC791' is defined on line 1745, but no explicit reference was found in the text == Unused Reference: 'RFC1883' is defined on line 1748, but no explicit reference was found in the text == Unused Reference: 'RFC1902' is defined on line 1751, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1755, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 1777, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FRAG' -- Possible downref: Non-RFC (?) normative reference: ref. 'L2TPv3' ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1902 (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2558 (Obsoleted by RFC 3592) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 2338 (Obsoleted by RFC 3768) -- Obsolete informational reference (is this intentional?): RFC 3448 (Obsoleted by RFC 5348) Summary: 5 errors (**), 0 flaws (~~), 10 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: September 2004 Prayson Pate 5 Overture Networks, Inc. 7 Editors 9 March 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 Tellabs 48 Thomas D. Nadeau Cisco Systems 49 Tricci So Caspian Networks 50 W. Mark Townsley Cisco Systems 51 Craig White Level 3 Communications, LLC. 52 Lloyd Wood Cisco Systems 53 XiPeng Xiao Riverstone Networks 55 Table of Contents 57 1. Introduction............................................. 5 58 1.1 Pseudo Wire Definition............................... 5 59 1.2 PW Service Functionality............................. 6 60 1.3 Non-Goals of this document........................... 6 61 1.4 Terminology.......................................... 6 63 2. PWE3 Applicability....................................... 9 65 3. Protocol Layering Model.................................. 9 66 3.1 Protocol Layers...................................... 9 67 3.2 Domain of PWE3....................................... 11 68 3.3 Payload Types........................................ 11 70 4. Architecture of Pseudo-wires............................. 14 71 4.1 Network Reference Model.............................. 14 72 4.2 PWE3 Pre-processing.................................. 15 73 4.3 Maintenance Reference Model.......................... 19 74 4.4 Protocol Stack Reference Model....................... 19 75 4.5 Pre-processing Extension to Protocol Stack Reference 76 Model................................................ 20 78 5. PW Encapsulation......................................... 21 79 5.1 Payload Convergence Layer............................ 22 80 5.2 Payload-independent PW Encapsulation Layers.......... 24 81 5.3 Fragmentation........................................ 27 82 5.4 Instantiation of the Protocol Layers................. 27 84 6. PW Demultiplexer Layer and PSN Requirements.............. 30 85 6.1 Multiplexing......................................... 30 86 6.2 Fragmentation........................................ 31 87 6.3 Length and Delivery.................................. 31 88 6.4 PW-PDU Validation.................................... 31 89 6.5 Congestion Considerations............................ 31 91 7. Control Plane............................................ 32 92 7.1 Set-up or Teardown of Pseudo-Wires................... 32 93 7.2 Status Monitoring.................................... 33 94 7.3 Notification of Pseudo-wire Status Changes........... 33 95 7.4 Keep-alive........................................... 34 96 7.5 Handling Control Messages of the Native Services..... 35 98 8. Management and Monitoring................................. 35 99 8.1 Status and Statistics................................ 35 100 8.2 PW SNMP MIB Architecture............................. 36 101 8.3 Connection Verification and Traceroute................ 39 103 9. IANA considerations...................................... 40 105 10. Security Considerations................................. 40 107 1. Introduction 109 This document describes an architecture for Pseudo Wire Emulation 110 Edge-to-Edge (PWE3) in support of [XIAO]. It discusses the emulation 111 of services (such as Frame Relay, ATM, Ethernet, TDM and SONET/SDH) 112 over packet switched networks (PSNs) using IP or MPLS. It presents 113 the architectural framework for pseudo wires (PWs), defines 114 terminology, specifies the various protocol elements and their 115 functions. 117 1.1 Pseudo Wire Definition 119 PWE3 is a mechanism that emulates the essential attributes of a 120 telecommunications service (such as a T1 leased line or Frame Relay) 121 over a PSN. PWE3 is intended to provide only the minimum necessary 122 functionality to emulate the wire with the required degree of 123 faithfulness for the given service definition. Any required switching 124 functionality is the responsibility of a forwarder function (FWRD). 125 Any translation or other operation needing knowledge of the payload 126 semantics is carried out by native service processing (NSP) elements. 127 The functional definition of any FWRD or NSP elements is outside the 128 scope of PWE3. 130 The required functions of PWs include encapsulating service-specific 131 bit-streams, cells or PDUs arriving at an ingress port, and carrying 132 them across a IP path or MPLS tunnel. In some cases it is necessary 133 to perform other operation such as managing their timing and order, 134 to emulate the behavior and characteristics of the service to the 135 required degree of faithfulness. 137 From the perspective of a Customer Edge Equipment (CE), the PW is 138 characterised as an unshared link or circuit of the chosen service. 139 In some cases, there may be deficiencies in the PW emulation that 140 impact the traffic carried over a PW, and hence limit the 141 applicability of this technology. These limitations must be fully 142 described in the appropriate service-specific documentation. 144 For each service type, there will be one default mode of operation 145 that all PEs offering that service type must support. However, 146 optional modes may be defined to improve the faithfulness of the 147 emulated service, if it can be clearly demonstrated that the 148 additional complexity associated with the optional mode is offset by 149 the value it offers to PW users. 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 PE-bound 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 PW encapsulations. 170 o The detailed definition of the protocols involved in PW 171 set-up 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 This document uses the following definitions of terms. These terms 183 are illustrated in context in Figure 2. 185 Attachment Circuit The physical or virtual circuit attaching 186 (AC) a CE to a PE. An attachment Circuit may be 187 for example a Frame Relay DLCI, an ATM 188 VPI/VCI, an Ethernet port, a VLAN, a PPP 189 connection on a physical interface, a 190 PPP session from an L2TP tunnel, an MPLS 191 LSP, etc. If both physical and virtual ACs 192 are of the same technology (e.g., both ATM, 193 both Ethernet, both Frame Relay) the PW 194 is said to provide "homogeneous transport"; 195 otherwise it is said to provide 196 "heterogeneous transport". 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 Control Word (CW) A four octet header used in some encapsulations 209 to carry per packet information when the PSN 210 is MPLS. 212 Customer Edge (CE) A device where one end of a service 213 originates and/or terminates. The CE is not 214 aware that it is using an emulated service 215 rather than a native service. 217 Forwarder (FWRD) A PE subsystem that selects the PW to use to 218 transmit a payload received on an AC. 220 Fragmentation The action of dividing a single PDU into 221 multiple PDUs before transmission with the 222 intent of the original PDU being reassembled 223 elsewhere in the network. Fragmentation may be 224 performed in order to allow sending of packets 225 of a larger size than the network MTU which 226 they will traverse. 228 Maximum transmission The packet size (excluding data link header) 229 unit (MTU) that an interface can transmit without 230 needing to fragment. 232 Native Service Processing of the data received by the PE 233 Processing (NSP) from the CE before presentation to the PW 234 for transmission across the core, or 235 processing of the data received from a PW 236 by a PE before it is output on the AC. 237 NSP functionality is defined by standards 238 bodies other than the IETF, such as ITU-T, 239 ANSI, ATMF, etc.) 241 Packet Switched Within the context of PWE3, this is a 242 Network (PSN) network using IP or MPLS as the mechanism 243 for packet forwarding. 245 PE-bound The traffic direction where information 246 from a CE is adapted to a PW, and PW-PDUs 247 are sent into the PSN. 249 PE/PW Maintenance Used by the PEs to set up, maintain and 250 tear down the PW. It may be coupled with 251 CE Signaling in order to effectively manage 252 the PW. 254 Protocol Data The unit of data output to, or received 255 Unit (PDU) from, the network by a protocol layer. 257 Provider Edge (PE) A device that provides PWE3 to a CE. 259 Pseudo Wire (PW) A mechanism that carries the essential 260 elements of an emulated service from one PE 261 to one or more other PEs over a PSN. 263 Pseudo Wire A mechanism that emulates the essential 264 Emulation Edge to attributes of service (such as a T1 leased 265 Edge (PWE3) line or frame relay) over a PSN. 267 Pseudo Wire PDU A PDU sent on the PW that contains all of 268 (PW-PDU) the data and control information necessary 269 to emulate the desired service. 271 PSN Tunnel A tunnel across a PSN inside which one or 272 more PWs can be carried. 274 PSN Tunnel Used to set up, maintain and tear down the 275 Signaling underlying PSN tunnel. 277 PW Demultiplexer Data-plane method of identifying a PW 278 terminating at a PE. 280 PWE3 Payload Type A identifier used to distinguish between 281 Identifier an MPLS IP payload and a CW that is not 282 (PWE3-PID) ECMP safe. 284 Time Domain Time Division Multiplexing. Frequently used 285 Multiplexing (TDM) to refer to the synchronous bit-streams at 286 rates defined by G.702. 288 Tunnel A method of transparently carrying information 289 over a network. 291 2. PWE3 Applicability 293 The PSN carrying a PW will subject payload packets to loss, delay, 294 delay variation, and re-ordering. During a network transient there 295 may be a sustained period of impaired service. The applicability of 296 PWE3 to a particular service depends on the sensitivity of that 297 service (or the CE implementation) to these effects, and the ability 298 of the adaptation layer to mask them. Some services, such as IP over 299 FR over PWE3, may prove quite resilient to IP and MPLS PSN 300 characteristics. Other services, such as the interconnection of PBX 301 systems via PWE3, will require more careful consideration of the PSN 302 and adaptation layer characteristics. In some instances, traffic 303 engineering of the underlying PSN will be required, and in some 304 cases, the constraints may be such that it is not possible to provide 305 the required service guarantees. 307 3. Protocol Layering Model 309 The PWE3 protocol-layering model is intended to minimise the 310 differences between PWs operating over different PSN types. The 311 design of the protocol-layering model has the goals of making each PW 312 definition independent of the underlying PSN, and maximizing the 313 reuse of IETF protocol definitions and their implementations. 315 3.1 Protocol Layers 317 The logical protocol-layering model required to support a PW is shown 318 in Figure 1. 320 +---------------------------+ 321 | Payload | 322 +---------------------------+ 323 | Encapsulation | <==== may be null 324 +---------------------------+ 325 | PW Demultiplexer | 326 +---------------------------+ 327 | PSN Convergence | <==== may be null 328 +---------------------------+ 329 | PSN | 330 +---------------------------+ 331 | Data-link | 332 +---------------------------+ 333 | Physical | 334 +---------------------------+ 336 Figure 1: Logical Protocol Layering Model 338 The payload is transported over the Encapsulation Layer. The 339 Encapsulation Layer carries any information, not already present 340 within the payload itself, that is needed by the PW CE-bound PE 341 interface to send the payload to the CE via the physical interface. 342 If no information is needed beyond that in the payload itself, this 343 layer is empty. 345 This layer also provides support for real-time processing, and 346 sequencing, if needed. 348 The PW Demultiplexer Layer provides the ability to deliver multiple 349 PWs over a single PSN tunnel. The PW demultiplexer value used to 350 identify the PW in the data-plane may be unique per PE, but this is 351 not a PWE3 requirement. It must, however, be unique per tunnel 352 endpoint. If it is necessary to identify a particular tunnel, then 353 that is the responsibility of the PSN layer. 355 The PSN Convergence Layer provides the enhancements needed to make 356 the PSN conform to the assumed PSN service requirement. This layer 357 therefore provides a consistent interface to the PW, making the PW 358 independent of the PSN type. If the PSN already meets the service 359 requirements, this layer is empty. 361 The PSN header, MAC/Data-link and Physical Layer definitions are 362 outside the scope of this document. The PSN can be IPv4, IPv6 or 363 MPLS. 365 3.2 Domain of PWE3 367 PWE3 defines the Encapsulation Layer, the method of carrying various 368 payload types, and the interface to the PW Demultiplexer Layer. It 369 is expected that the other layers will be provided by tunneling 370 methods such as L2TP or MPLS over the PSN. 372 3.3 Payload Types 374 The payload is classified into the following generic types of native 375 data unit: 377 o Packet 378 o Cell 379 o Bit-stream 380 o Structured bit-stream 382 Within these generic types there are specific service types. For 383 example: 385 Generic Payload Type PW Service 386 -------------------- ---------- 387 Packet Ethernet (all types), HDLC framing, 388 frame-relay, ATM AAL5 PDU. 390 Cell ATM. 392 Bit-stream Unstructured E1, T1, E3, T3. 394 Structured bit-stream SONET/SDH (e.g. SPE, VT, NxDS0). 396 3.3.1. Packet Payload 398 A packet payload is a variable-size data unit delivered to the PE via 399 the AC. A packet payload may be large compared to the PSN MTU. The 400 delineation of the packet boundaries is encapsulation-specific. HDLC 401 or Ethernet PDUs can be considered as examples of packet payloads. 402 Typically a packet will be stripped of transmission overhead such as 403 HDLC flags and stuffing bits before transmission over the PW. 405 A packet payload would normally be relayed across the PW as a single 406 unit. However, there will be cases where the combined size of the 407 packet payload and its associated PWE3 and PSN headers exceeds the 408 PSN path MTU. In these cases, some fragmentation methodology needs 409 to be applied. This may, for example, be the case when a user is 410 providing the service and attaching to the service provider via 411 Ethernet, or where nested pseudo-wires are involved. Fragmentation is 412 discussed in more detail in Section 5.3 414 A packet payload may need sequencing and real-time support. 416 In some situations, the packet payload may be selected from the 417 packets presented on the emulated wire on the basis of some sub- 418 multiplexing technique. For example, one or more frame-relay PDUs 419 may be selected for transport over a particular pseudo-wire based on 420 the frame-relay Data-Link Connection Identifier (DLCI), or, in the 421 case of Ethernet payloads, using a suitable MAC bridge filter. This 422 is a forwarder function, and this selection would therefore be made 423 before the packet was presented to the PW Encapsulation Layer. 425 3.3.2. Cell Payload 427 A cell payload is created by capturing, transporting and replaying 428 groups of octets presented on the wire in a fixed-size format. The 429 delineation of the group of bits that comprise the cell is specific 430 to the encapsulation type. Two common examples of cell payloads are 431 ATM 53-octet cells, and the larger 188-octet MPEG Transport Stream 432 packets [DVB]. 434 To reduce per-PSN packet overhead, multiple cells may be concatenated 435 into a single payload. The Encapsulation Layer may consider the 436 payload complete on the expiry of a timer, after a fixed number of 437 cells have been received or when a significant cell (e.g. an ATM OAM 438 cell) has been received. The benefit of concatenating multiple PDUs 439 should be weighed against a possible increase in packet delay 440 variation and the larger penalty incurred by packet loss. In some 441 cases, it may be appropriate for the Encapsulation Layer to perform 442 some type of compression, such as silence suppression or voice 443 compression. 445 The generic cell payload service will normally need sequence number 446 support, and may also need real-time support. The generic cell 447 payload service would not normally require fragmentation. 449 The Encapsulation Layer may apply some form of compression to some of 450 these sub-types (e.g. idle cells may be suppressed). 452 In some instances, the cells to be incorporated in the payload may be 453 selected by filtering them from the stream of cells presented on the 454 wire. For example, an ATM PWE3 service may select cells based on 455 their VCI or VPI fields. This is a forwader function, and the 456 selection would therefore be made before the packet was presented to 457 the PW Encapsulation Layer. 459 3.3.3. Bit-stream 461 A bit-stream payload is created by capturing, transporting and 462 replaying the bit pattern on the emulated wire, without taking 463 advantage of any structure that, on inspection, may be visible within 464 the relayed traffic (i.e. the internal structure has no effect on the 465 fragmentation into packets). 467 In some instances it is possible to apply suppression to bit-streams. 468 For example, E1 and T1 send "all-ones" to indicate failure. This 469 condition can be detected without any knowledge of the structure of 470 the bit-stream, and transmission of packetized data suppressed. 472 This service will require sequencing and real-time support. 474 3.3.4. Structured bit-stream 476 A structured bit-stream payload is created by using some knowledge of 477 the underlying structure of the bit-stream to capture, transport and 478 replay the bit pattern on the emulated wire. 480 Two important points distinguish structured and unstructured bit- 481 streams: 483 o Some parts of the original bit-stream may be stripped in the 484 PSN-bound direction by NSP block. For example, in Structured 485 SONET the section and line overhead (and, possibly more) may 486 be stripped. A framer is required to enable such stripping. 487 It is also required for frame/payload alignment for 488 fractional T1/E1 applications. 490 o The PW must preserve the structure across the PSN so that 491 the CE-bound NSP block can insert it correctly into the 492 reconstructed unstructured bit-stream. The stripped 493 information (such as SONET pointer justifications) may 494 appear in the encapsulation layer to facilitate this 495 reconstitution. 497 As an option, the Encapsulation Layer may also perform silence/idle 498 suppression or similar compression on a structured bit-stream. 500 Structured bit-streams are distinguished from cells in that the 501 structures may be too long to be carried in a single packet. Note 502 that "short" structures are indistinguishable from cells and may 503 benefit from the use of methods described in section 3.3.2. 505 This service requires sequencing and real-time support. 507 3.3.5. Principle of Minimum Intervention 509 To minimise the scope of information, and to improve the efficiency 510 of data flow through the Encapsulation Layer, the payload should be 511 transported as received with as few modifications as possible 512 [RFC1958]. 514 This minimum intervention approach decouples payload development from 515 PW development and requires fewer translations at the NSP in a system 516 with similar CE interfaces at each end. It also prevents unwanted 517 side-effects due to subtle misrepresentation of the payload in the 518 intermediate format. 520 An approach which does intervene can be more wire-efficient in some 521 cases and may result in fewer translations at the NSP where the CE 522 interfaces are of different types. Any intermediate format 523 effectively becomes a new framing type, requiring documentation and 524 assured interoperability. This increases the amount of work for 525 handling the protocol the intermediate format carries, and is 526 undesirable. 528 4. Architecture of Pseudo-wires 530 This section describes the PWE3 architectural model. 532 4.1 Network Reference Model 534 Figure 2 illustrates the network reference model for point-to-point 535 PWs. 537 |<-------------- Emulated Service ---------------->| 538 | | 539 | |<------- Pseudo Wire ------>| | 540 | | | | 541 | | |<-- PSN Tunnel -->| | | 542 | V V V V | 543 V AC +----+ +----+ AC V 544 +-----+ | | PE1|==================| PE2| | +-----+ 545 | |----------|............PW1.............|----------| | 546 | CE1 | | | | | | | | CE2 | 547 | |----------|............PW2.............|----------| | 548 +-----+ ^ | | |==================| | | ^ +-----+ 549 ^ | +----+ +----+ | | ^ 550 | | Provider Edge 1 Provider Edge 2 | | 551 | | | | 552 Customer | | Customer 553 Edge 1 | | Edge 2 554 | | 555 | | 556 native service native service 558 Figure 2: PWE3 Network Reference Model 560 The two PEs (PE1 and PE2) need to provide one or more PWs on behalf 561 of their client CEs (CE1 and CE2) to enable the client CEs to 562 communicate over the PSN. A PSN tunnel is established to provide a 563 data path for the PW. The PW traffic is invisible to the core 564 network, and the core network is transparent to the CEs. Native data 565 units (bits, cells or packets) arrive via the AC, are encapsulated in 566 a PW-PDU and are carried across the underlying network via the PSN 567 tunnel. The PEs perform the necessary encapsulation and decapsulation 568 of PW-PDUs, as well as handling any other functions required by the 569 PW service, such as sequencing or timing. 571 4.2 PWE3 Pre-processing 573 In some applications, there is a need to perform operations on the 574 native data units received from the CE (including both payload and 575 signaling traffic) before they are transmitted across the PW by the 576 PE. Examples include Ethernet bridging, SONET cross-connect, 577 translation of locally-significant identifiers such as VCI/VPI, or 578 translation to another service type. These operations could be 579 carried out in external equipment, and the processed data sent to the 580 PE over one or more physical interfaces. In most cases, there are 581 cost and operational benefits in undertaking these operations within 582 the PE. This processed data is then presented to the PW via a 583 virtual interface within the PE. 585 These pre-processing operations are included in the PWE3 reference 586 model to provide a common reference point, but the detailed 587 description of these operations is outside the scope of the PW 588 definition given here. 590 PW 591 End Service 592 | 593 |<------- Pseudo Wire ------>| 594 | | 595 | |<-- PSN Tunnel -->| | 596 V V V V PW 597 +-----+----+ +----+ End Service 598 +-----+ |PREP | PE1|==================| PE2| | +-----+ 599 | | | |............PW1.............|----------| | 600 | CE1 |----| | | | | | | CE2 | 601 | | ^ | |............PW2.............|----------| | 602 +-----+ | | | |==================| | | ^ +-----+ 603 | +-----+----+ +----+ | | 604 | ^ | | 605 | | | | 606 | |<------- Emulated Service ------->| | 607 | | | 608 | Virtual physical | 609 | termination | 610 | ^ | 611 CE1 native | CE2 native 612 service | service 613 | 614 CE2 native 615 service 617 Figure 3: Pre-processing within the PWE3 Network Reference Model 619 Figure 3 shows the inter-working of one PE with pre-processing 620 (PREP), and a second without this functionality. This is a useful 621 reference point because it emphasises that the functional interface 622 between PREP and the PW is that represented by a physical interface 623 carrying the service. This effectively defines the necessary inter- 624 working specification. 626 The operation of a system in which both PEs include PREP 627 functionality is also supported. 629 The required pre-processing can be divided into two components: 630 o Forwarder (FWRD) 632 o Native Service Processing (NSP) 634 4.2.1. Forwarders 636 In some applications there is the need to selectively forward payload 637 elements from one or more ACs to one or more PWs. In such cases there 638 will also be the need to perform the inverse function on PWE3-PDUs 639 received by a PE from the PSN. This is the function of the forwarder. 641 The forwarder selects the PW based on, for example: the incoming AC, 642 the contents of the payload, or some statically and/or dynamically 643 configured forwarding information. 645 +----------------------------------------+ 646 | PE Device | 647 +----------------------------------------+ 648 Single | | | 649 AC | | Single | PW Instance 650 <------>o Forwarder + PW Instance X<===========> 651 | | | 652 +----------------------------------------+ 654 Figure 4a: Simple point-to-point service 656 +----------------------------------------+ 657 | PE Device | 658 +----------------------------------------+ 659 Multiple| | Single | PW Instance 660 AC | + PW Instance X<===========> 661 <------>o | | 662 | |----------------------| 663 <------>o | Single | PW Instance 664 | Forwarder + PW Instance X<===========> 665 <------>o | | 666 | |----------------------| 667 <------>o | Single | PW Instance 668 | + PW Instance X<===========> 669 <------>o | | 670 +----------------------------------------+ 672 Figure 4b: Multiple AC to Multiple PW Forwarding 674 Figure 4a shows a simple forwarder that performs some type of 675 filtering operation. Because the forwarder has a single input and a 676 single output interface, filtering is the only type of forwarding 677 operation that applies. Figure 4b shows a more general forwarding 678 situation where payloads are extracted from one or more ACs and 679 directed to one or more PWs. In this case filtering, direction and 680 combination operations may be performed on the payloads. For 681 example, if the AC were frame relay, the forwarder might perform 682 frame relay switching and the PW instances might be the inter-switch 683 links. 685 4.2.2. Native Service Processing 687 In some applications some form of data or address translation, or 688 other operation requiring knowledge of the semantics of the payload, 689 will be required. This is the function of the Native Service 690 Processor (NSP). 692 The use of the NSP approach simplifies the design of the PW by 693 restricting a PW to homogeneous operation. NSP is included in the 694 reference model to provide a defined interface to this functionality. 695 The specification of the various types of NSP is outside the scope of 696 PWE3. 698 +----------------------------------------+ 699 | PE Device | 700 Multiple+----------------------------------------+ 701 AC | | | Single | PW Instance 702 <------>o NSP # + PW Instance X<===========> 703 | | | | 704 |------| |----------------------| 705 | | | Single | PW Instance 706 <------>o NSP #Forwarder + PW Instance X<===========> 707 | | | | 708 |------| |----------------------| 709 | | | Single | PW Instance 710 <------>o NSP # + PW Instance X<===========> 711 | | | | 712 +----------------------------------------+ 714 Figure 5: NSP in a Multiple AC to Multiple 715 PW Forwarding PE 717 Figure 5 illustrates the relationship between NSP, forwarder and PWs 718 in a 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 forwarder. These transformation operations will of course be limited 722 to those that have been implemented in the data path, and which are 723 enabled by the PE configuration. A PE device may contain more than 724 one forwarder. 726 This model also supports the operation of a system in which the NSP 727 functionality includes terminating the data-link, and applying 728 Network Layer processing to the payload is also supported. 730 4.3 Maintenance Reference Model 732 Figure 6 illustrates the maintenance reference model for PWs. 734 |<------- CE (end-to-end) Signaling ------>| 735 | |<---- PW/PE Maintenance ----->| | 736 | | |<-- PSN Tunnel -->| | | 737 | | | Signaling | | | 738 | V V (out of scope) V V | 739 v +-----+ +-----+ v 740 +-----+ | PE1 |==================| PE2 | +-----+ 741 | |-----|.............PW1..............|-----| | 742 | CE1 | | | | | | CE2 | 743 | |-----|.............PW2..............|-----| | 744 +-----+ | |==================| | +-----+ 745 +-----+ +-----+ 746 Customer Provider Provider Customer 747 Edge 1 Edge 1 Edge 2 Edge 2 749 Figure 6: PWE3 Maintenance Reference Model 751 The following signaling mechanisms are required: 753 o The CE (end-to-end) signaling is between the CEs. This 754 signaling could be frame relay PVC status signaling, ATM SVC 755 signaling, TDM CAS signaling, etc. 757 o The PW/PE Maintenance is used between the PEs (or NSPs) to set 758 up, maintain and tear down PWs, including any required 759 coordination of parameters. 761 o The PSN Tunnel signaling controls the PW multiplexing and some 762 elements of the underlying PSN. Examples are L2TP control 763 protocol, MPLS LDP and RSVP-TE. The definition of the 764 information that PWE3 needs to be signaled is within the scope 765 of PWE3, but the signaling protocol itself is not. 767 4.4 Protocol Stack Reference Model 769 Figure 7 illustrates the protocol stack reference model for PWs. 771 +-----------------+ +-----------------+ 772 |Emulated Service | |Emulated Service | 773 |(e.g. TDM, ATM) |<==== Emulated Service ===>|(e.g. TDM, ATM) | 774 +-----------------+ +-----------------+ 775 | Payload | | Payload | 776 | Encapsulation |<====== Pseudo Wire ======>| Encapsulation | 777 +-----------------+ +-----------------+ 778 |PW Demultiplexer | |PW Demultiplexer | 779 | PSN Tunnel, |<======= PSN Tunnel ======>| PSN Tunnel, | 780 | PSN & Physical | | PSN & Physical | 781 | Layers | | Layers | 782 +-------+---------+ ___________ +---------+-------+ 783 | / \ | 784 +===============/ PSN \===============+ 785 \ / 786 \_____________/ 788 Figure 7: PWE3 Protocol Stack Reference Model 790 The PW provides the CE with an emulated physical or virtual 791 connection to its peer at the far end. Native service PDUs from the 792 CE are passed through an Encapsulation Layer at the sending PE, and 793 then sent over the PSN. The receiving PE removes the encapsulation 794 and restores the payload to its native format for transmission to the 795 destination CE. 797 4.5 Pre-processing Extension to Protocol Stack Reference Model 799 Figure 8 illustrates how the protocol stack reference model is 800 extended to include the provision of pre-processing (Forwarding and 801 NSP). This shows the placement of the physical interface relative to 802 the CE. 804 /======================================\ 805 H Forwarder H<----Pre-processing 806 H----------------======================/ 807 H Native Service H | | 808 H Processing H | | 809 \================/ | | 810 | | | Emulated | 811 | Service | | Service | 812 | Interface | | (TDM, ATM, | 813 | (TDM, ATM, | | Ethernet, |<== Emulated Service == 814 | Ethernet, | | frame relay, | 815 | frame relay, | | etc.) | 816 | etc.) | +-----------------+ 817 | | | Payload | 818 | | | Encapsulation |<=== Pseudo Wire ====== 819 | | +-----------------+ 820 | | |PW Demultiplexer | 821 | | | PSN Tunnel, | 822 | | | PSN & Physical |<=== PSN Tunnel ======= 823 | | | Headers | 824 +----------------+ +-----------------+ 825 | Physical | | Physical | 826 +-------+--------+ +-------+---------+ 827 | | 828 | | 829 | | 830 | | 831 | | 832 | | 833 To CE <---+ +---> To PSN 835 Figure 8: Protocol Stack Reference Model with Pre-processing 837 5. PW Encapsulation 839 The PW Encapsulation Layer provides the necessary infrastructure to 840 adapt the specific payload type being transported over the PW to the 841 PW Demultiplexer Layer that is used to carry the PW over the PSN. 843 The PW Encapsulation Layer consists of three sub-layers: 845 o Payload Convergence 846 o Timing 847 o Sequencing 849 The PW Encapsulation sub-layering and its context with the protocol 850 stack are shown, in Figure 9. 852 +---------------------------+ 853 | Payload | 854 /===========================\ <------ Encapsulation 855 H Payload Convergence H Layer 856 H---------------------------H 857 H Timing H 858 H---------------------------H 859 H Sequencing H 860 \===========================/ 861 | PW Demultiplexer | 862 +---------------------------+ 863 | PSN Convergence | 864 +---------------------------+ 865 | PSN | 866 +---------------------------+ 867 | Data-link | 868 +---------------------------+ 869 | Physical | 870 +---------------------------+ 872 Figure 9: PWE3 Encapsulation Layer in Context 874 The Payload Convergence Sub-layer is highly tailored to the specific 875 payload type, but, by grouping a number of target payload types into 876 a generic class, and then providing a single convergence sub-layer 877 type common to the group, we achieve a reduction in the number of 878 payload convergence sub-layer types. This decreases implementation 879 complexity. The provision of per-packet signaling and other out-of- 880 band information (other than sequencing or timing) is undertaken by 881 this layer. 883 The Timing Layer and the Sequencing Layer provide generic services to 884 the Payload Convergence Layer for all payload types that require 885 them. 887 5.1 Payload Convergence Layer 889 5.1.1. Encapsulation 891 The primary task of the Payload Convergence Layer is the 892 encapsulation of the payload in PW-PDUs. The native data units to be 893 encapsulated may contain a L2 header or L1 overhead. This is service 894 specific. The Payload Convergence header carries the additional 895 information needed to replay the native data units at the CE-bound 896 physical interface. The PW Demultiplexer header is not considered as 897 part of the PW header. 899 Not all the additional information needed to replay the native data 900 units need to be carried in the PW header of the PW PDUs. Some 901 information (e.g. service type of a PW) may be stored as state 902 information at the destination PE during PW set-up. 904 5.1.2. PWE3 Channel Types 906 The PW Encapsulation Layer and its associated signaling require one 907 or more of the following types of channels from its underlying PW 908 Demultiplexer and PSN Layers: 910 1. A reliable control channel for signaling line events, status 911 indications, and, in some exceptional cases, CE-CE events 912 that must be translated and sent reliably between PEs. 913 PWE3 may need this type of control channel to provide 914 faithful emulation of complex data-link protocols. 916 plus one or more data channels with the following characteristics: 918 2. A high-priority, unreliable, sequenced channel. A typical use 919 is for CE-to-CE signaling. "High priority" may simply be 920 indicated via the DSCP bits for IP or the EXP bits for MPLS, 921 giving the packet priority during transit. This channel type 922 could also use a bit in the tunnel header itself to indicate 923 that packets received at the PE should be processed with higher 924 priority [RFC2474]. 926 3. A sequenced channel for data traffic that is sensitive to 927 packet reordering (one classification for use could be for 928 any non-IP traffic). 930 4. An un-sequenced channel for data traffic insensitive to packet 931 order. 933 The data channels (2, 3 and 4 above) should be carried "in band" with 934 one another to as much of a degree as is reasonably possible on a 935 PSN. 937 Where end-to-end connectivity may be disrupted by address translation 938 [RFC3022], access-control lists, firewalls etc., there exists the 939 possibility that the control channel may be able to pass traffic and 940 set-up the PW, but the PW data traffic is blocked by one or more of 941 these mechanisms. In these cases unless the control channel is also 942 carried "in band" the signaling to set-up the PW will not confirm the 943 existence of an end-to-end data path. 945 In some cases there is a need to synchronize CE events with the data 946 carried over a PW. This is especially the case with TDM circuits 947 (e.g., the on-hook/off-hook events in PSTN switches might be carried 948 over a reliable control channel, whilst the associated bit-stream is 949 carried over a sequenced data channel). 951 PWE3 channel types that are not needed by the supported PWs need not 952 be included in such an implementation. 954 5.1.3. Quality of Service Considerations 956 Where possible, it is desirable to employ mechanisms to provide PW 957 Quality of Service (QoS) support over PSNs. 959 5.2 Payload-independent PW Encapsulation Layers 961 Two PWE3 Encapsulation Sub-layers provide common services to all 962 payload types: Sequencing and Timing. These services are optional 963 and are only used if needed by a particular PW instance. If the 964 service is not needed, the associated header may be omitted in order 965 to conserve processing and network resources. 967 There will be instances where a specific payload type will be 968 required to be transported with or without sequence and/or real-time 969 support. For example, an invariant of frame relay transport is the 970 preservation of packet order. Some frame-relay applications expect 971 in-order delivery, and may not cope with reordering of the frames. 972 However, where the frame relay service is itself only being used to 973 carry IP, it may be desirable to relax that constraint in return for 974 reduced per-packet processing cost. 976 The guiding principle is that, where possible, an existing IETF 977 protocol should be used to provide these services. Where a suitable 978 protocol is not available, the existing protocol should be extended 979 or modified to meet the PWE3 requirements, thereby making that 980 protocol available for other IETF uses. In the particular case of 981 timing, more than one general method may be necessary to provide for 982 the full scope of payload timing requirements. 984 5.2.1. Sequencing 986 The sequencing function provides three services: frame ordering, 987 frame duplication detection and frame loss detection. These services 988 allow the emulation of the invariant properties of a physical wire. 989 Support for sequencing depends on the payload type, and may be 990 omitted if not needed. 992 The size of the sequence-number space depends on the speed of the 993 emulated service, and the maximum time of the transient conditions in 994 the PSN. A sequence number space greater than 2^16 may therefore be 995 needed to prevent the sequence number space wrapping during the 996 transient. 998 5.2.1.1 Frame Ordering 1000 When packets carrying the PW-PDUs traverse a PSN, they may arrive out 1001 of order at the destination PE. For some services, the frames 1002 (control frames, data frames, or both control and data frames) must 1003 be delivered in order. For such services, some mechanism must be 1004 provided for ensuring in-order delivery. Providing a sequence number 1005 in the sequence sub-layer header for each packet is one possible 1006 approach to out-of-sequence detection. Alternatively it can be noted 1007 that sequencing is a subset of the problem of delivering timed 1008 packets, and that a single combined mechanism such as [RFC3550] may 1009 be employed. 1011 There are two possible misordering strategies: 1013 o Drop misordered PW PDUs. 1015 o Try to sort PW PDUs into the correct order. 1017 The choice of strategy will depend on: 1019 o How critical the loss of packets is to the operation of 1020 the PW (e.g. the acceptable bit error rate). 1022 o The speeds of the PW and PSN. 1024 o The acceptable delay (since delay must be introduced to 1025 reorder) 1027 o The incidence of expected misordering. 1029 5.2.1.2 Frame Duplication Detection 1031 In rare cases, packets traversing a PW may be duplicated by the 1032 underlying PSN. For some services frame duplication is not 1033 acceptable. For such services, some mechanism must be provided to 1034 ensure that duplicated frames will not be delivered to the 1035 destination CE. The mechanism may be the same as the mechanism used 1036 to ensure in-order frame delivery. 1038 5.2.1.3 Frame Loss Detection 1040 A destination PE can determine whether a frame has been lost by 1041 tracking the sequence numbers of the received PW PDUs. 1043 In some instances, a destination PE will have to presume that a PW 1044 PDU is lost if it fails to arrive within a certain time. If a PW-PDU 1045 that has been processed as lost subsequently arrives, the destination 1046 PE must discard it. 1048 5.2.2. Timing 1050 A number of native services have timing expectations based on the 1051 characteristics of the networks that they were designed to travel 1052 over, and it can be necessary for the emulated service to duplicate 1053 these network characteristics as closely as possible, e.g. in 1054 delivering native traffic with bit-rate, jitter, wander and delay 1055 characteristics similar to those received at the sending PE. 1057 In such cases, it is necessary for the receiving PE to play out the 1058 native traffic as it was received at the sending PE. This relies on 1059 either timing information sent between the two PEs, or in some case 1060 timing information received from an external reference. 1062 The Timing Sub-layer must therefore support two timing functions: 1063 clock recovery and timed payload delivery. A particular payload type 1064 may require either or both of these services. 1066 5.2.2.1 Clock Recovery 1068 Clock recovery is the extraction of output transmission bit timing 1069 information from the delivered packet stream, and requires a suitable 1070 mechanism. A physical wire carries the timing information natively, 1071 but it is a relatively complex task to extract timing from a highly 1072 jittered source such as packet stream. It is therefore desirable 1073 that an existing real-time protocol such as [RFC3550] be used for 1074 this purpose, unless it can be shown that this is unsuitable or 1075 unnecessary for a particular payload type. 1077 5.2.2.2 Timed delivery 1079 Timed delivery is the delivery of non-contiguous PW PDUs to the PW 1080 output interface with a constant phase relative to the input 1081 interface. The timing of the delivery may be relative to a clock 1082 derived from the packet stream received over the PSN clock recovery, 1083 or with reference to an external clock. 1085 5.3 Fragmentation 1087 A payload would ideally be relayed across the PW as a single unit. 1088 However, there will be cases where the combined size of the payload 1089 and its associated PWE3 and PSN headers exceeds the PSN path MTU. 1090 When a packet size exceeds the MTU of a given network, fragmentation 1091 and reassembly have to be performed in order for the packet to be 1092 delivered. Since fragmentation and reassembly generally consume a 1093 considerable network resources as compared to simply switching a 1094 packet in its entirety, efforts should be made to reduce or eliminate 1095 the need for fragmentation and reassembly throughout a network to the 1096 extent possible. Of particular concern for fragmentation and 1097 reassembly are aggregation points where large numbers of PWs are 1098 processed (e.g. at the PE). 1100 Ideally, the equipment originating the traffic being sent over the PW 1101 will be configured to have adaptive measures (e.g. [RFC1191], 1102 [RFC1981]) in place that ensure that packets that need to be 1103 fragmented are not sent. When this fails, the point closest to the 1104 sending host with fragmentation and reassembly capabilities should 1105 attempt to reduce the size of packets to satisfy the PSN MTU. Thus, 1106 in the reference model for PWE3 [Figure 3] fragmentation should first 1107 be performed at the CE if at all possible. If and only if the CE 1108 cannot adhere to an acceptable MTU size for the PW should the PE 1109 attempt its own fragmentation method. 1111 In cases where MTU management fails to limit the payload to a size 1112 suitable for transmission of the PW, the PE may fall back to either a 1113 generic PW fragmentation method, or, if available the fragmentation 1114 service of the underlying PSN. 1116 It is acceptable for a PE implementation not to support 1117 fragmentation. A PE that does not support fragmentation will drop 1118 packets that exceed the PSN MTU, and the management plane of the 1119 encapsulating PE may be notified. 1121 If the length of a L2/L1 frame, restored from a PW PDU, exceeds the 1122 MTU of the destination AC, it must be dropped. In this case, the 1123 management plane of the destination PE may be notified. 1125 5.4 Instantiation of the Protocol Layers 1127 This document does not address the detailed mapping of the Protocol 1128 Layering model to existing or future IETF standards. The 1129 instantiation of the logical Protocol Layering model is shown in 1130 Figure 9. 1132 5.4.1. PWE3 over an IP PSN 1134 The protocol definition of PWE3 over an IP PSN should employ existing 1135 IETF protocols where possible. 1137 +---------------------+ +-------------------------+ 1138 | Payload |------------->| Raw payload if possible | 1139 /=====================\ +-------------------------+ 1140 H Payload Convergence H-----------+->| Flags, seq # etc. | 1141 H---------------------H / +-------------------------+ 1142 H Timing H---------/--->| RTP | 1143 H---------------------H / +-------------+ | 1144 H Sequencing H----one of | | 1145 \=====================/ \ | +-----------+ 1146 | PW Demultiplexer |---------+--->| L2TP, MPLS etc. | 1147 +---------------------+ +-------------------------+ 1148 | PSN Convergence |------------->| Not needed | 1149 +---------------------+ +-------------------------+ 1150 | PSN |------------->| IP | 1151 +---------------------+ +-------------------------+ 1152 | Data-link |------------->| Data-link | 1153 +---------------------+ +-------------------------+ 1154 | Physical |------------->| Physical | 1155 +---------------------+ +-------------------------+ 1157 Figure 10: PWE3 over an IP PSN 1159 Figure 10 shows the protocol layering for PWE3 over an IP PSN. As a 1160 rule, the payload should be carried as received from the NSP, with 1161 the Payload Convergence Layer provided when needed. However in 1162 certain circumstances it may be justifiable to transmit the payload 1163 in some processed form. The reasons for this must be documented in 1164 the Encapsulation Layer definition for that payload type. 1166 Where appropriate, explicit timing is provided by RTP [RFC3550], 1167 which when used also provides a sequencing service. When the PSN is 1168 UDP/IP, the RTP header follows the UDP header and precedes the PW 1169 control field, while for all other cases the RTP header follows the 1170 PW control header. 1172 The encapsulation layer may additionally carry a sequence number; 1173 sequencing is to be provided either by RTP, or by the PW 1174 encapsulation layer but not both. 1176 PW Demultiplexing is provided by the PW label, which may take the 1177 form specified in a number of IETF protocols, e.g. an MPLS label 1178 [MPLSIP], an L2TP session ID [L2TPv3], or a UDP port number [RFC768]. 1180 When PWs are carried over IP the PSN Convergence Layer will not be 1181 needed. 1183 As a special case, if the PW Demultiplexer is an MPLS label, the 1184 protocol architecture of section 5.4.2 can be used instead of the 1185 protocol architecture of this section. 1187 5.4.2. PWE3 over an MPLS PSN 1189 The MPLS ethos places importance on wire efficiency. By using a 1190 control word, some components of the PWE3 protocol layers can be 1191 compressed to increase this efficiency. 1193 +---------------------+ 1194 | Payload | 1195 /=====================\ 1196 H Payload Convergence H--+ 1197 H---------------------H | +--------------------------------+ 1198 H Timing H--------->| RTP | 1199 H---------------------H | +--------------------------------+ 1200 H Sequencing H--+------>| Flags, Frag, Len, Seq #, etc | 1201 \=====================/ | +--------------------------------+ 1202 | PW Demultiplexer |--------->| PW Label | 1203 +---------------------+ | +--------------------------------+ 1204 | PSN Convergence |--+ +--->| Outer Label or MPLS-in-IP encap| 1205 +---------------------+ | +--------------------------------+ 1206 | PSN |-----+ 1207 +---------------------+ 1208 | Data-link | 1209 +---------------------+ 1210 | Physical | 1211 +---------------------+ 1213 Figure 11: PWE3 over an MPLS PSN using a control word 1215 Figure 11 shows the protocol layering for PWE3 over an MPLS PSN. An 1216 inner MPLS label is used to provide the PW demultiplexing function. 1217 A control word is used to carry most of the information needed by the 1218 PWE3 Encapsulation Layer and the PSN Convergence Layer in a compact 1219 format. The flags in the control word provide the necessary payload 1220 convergence. A sequence field provides support for both in-order 1221 payload delivery and (supported by a fragmentation control method) a 1222 PSN fragmentation service within the PSN Convergence Layer. Ethernet 1223 pads all frames to a minimum size of 64 bytes. The MPLS header does 1224 not include a length indicator. Therefore to allow PWE3 to be carried 1225 in MPLS to correctly pass over an Ethernet data-link, a length 1226 correction field is needed in the control word. As with an IP PSN, 1227 where appropriate, timing is provided by RTP [RFC3550]. 1229 In some networks it may be necessary to carry PWE3 over MPLS over IP. 1230 In these circumstances, the PW is encapsulated for carriage over MPLS 1231 as described in this section, and then a method of carrying MPLS over 1232 an IP PSN (such as GRE [RFC2784], [RFC2890]) is applied to the 1233 resultant PW-PDU. 1235 5.4.3. PW-IP Packet Discrimination 1237 For MPLS PSNs there is an additional constraint on the PW packet 1238 format. In order to facilitate proper functioning of label switched 1239 routers that detect IP packets based on the initial four bits of the 1240 packet content, these bits in PW packets must not be the same as an 1241 IP version number in current use. 1243 The use of this field for PWs is work in progress. 1245 .sp 1246 6. PW Demultiplexer Layer and PSN Requirements 1248 PWE3 places three service requirements on the protocol layers used to 1249 carry it across the PSN: 1251 o Multiplexing 1252 o Fragmentation 1253 o Length and Delivery 1255 6.1 Multiplexing 1257 The purpose of the PW Demultiplexer Layer is to allow multiple PWs to 1258 be carried in a single tunnel. This minimizes complexity and 1259 conserves resources. 1261 Some types of native service are capable of grouping multiple 1262 circuits into a "trunk", e.g. multiple ATM VCs in a VP, multiple 1263 Ethernet VLANs on a physical media, or multiple DS0 services within a 1264 T1 or E1. A PW may interconnect two end-trunks. That trunk would 1265 have a single multiplexing identifier. 1267 When a MPLS label is used as a PW Demultiplexer setting of the TTL 1268 value [RFC3032] in the PW label is application specific, however in a 1269 strict point to point application the TTL should be set to 2. 1271 6.2 Fragmentation 1273 If the PSN provides a fragmentation and reassembly service of 1274 adequate performance, it may be used to obtain an effective MTU that 1275 is large enough to transport the PW PDUs. See Section 5.3 for a full 1276 discussion of the PW fragmentation issues. 1278 6.3 Length and Delivery 1280 PDU delivery to the egress PE is the function of the PSN Layer. 1282 If the underlying PSN does not provide all the information necessary 1283 to determine the length of a PW-PDU, the Encapsulation Layer must 1284 provide it. 1286 6.4 PW-PDU Validation 1288 It is a common practice to use an error detection mechanism such as a 1289 CRC or similar mechanism to assure end-to-end integrity of frames. 1290 The PW service-specific mechanisms must define whether the packet's 1291 checksum shall be preserved across the PW, or be removed from PE- 1292 bound PDUs and then be re-calculated for insertion in CE-bound data. 1294 The former approach saves work, while the latter saves bandwidth. For 1295 a given implementation the choice may be dictated by hardware 1296 restrictions, which may not allow the preservation of the checksum. 1298 For protocols such as ATM and FR, the scope of the checksum is 1299 restricted to a single link. This is because the circuit identifiers 1300 (e.g. FR DLCI or ATM VPI/VCI) have only local significance and are 1301 changed on each hop or span. If the circuit identifier (and thus 1302 checksum) were going to change as a part of the PW emulation, it 1303 would be more efficient to strip and re-calculate the checksum. 1305 The service specific document for each protocol must describe the 1306 validation scheme to be used. 1308 6.5 Congestion Considerations 1310 The PSN carrying the PW may be subject to congestion. The congestion 1311 characteristics will vary with the PSN type, the network architecture 1312 and configuration, and the loading of the PSN. 1314 Where the traffic carried over the PW is known to be TCP friendly 1315 (by, for example, packet inspection), packet discard in the PSN will 1316 trigger the necessary reduction in offered load, and no additional 1317 congestion avoidance action is necessary. 1319 If the PW is operating over a PSN that provides enhanced delivery, 1320 the PEs should monitor packet loss to ensure that the service that 1321 was requested is actually being delivered. If it is not, then the PE 1322 should assume that the PSN is providing a best-effort service, and 1323 should use the best-effort service congestion avoidance measures 1324 described below. 1326 If best-effort service is being used and the traffic is not known to 1327 be TCP friendly, the PEs should monitor packet loss to ensure that 1328 the packet loss rate is within acceptable parameters. Packet loss is 1329 considered acceptable if a TCP flow across the same network path and 1330 experiencing the same network conditions would achieve an average 1331 throughput, measured on a reasonable timescale, that is not less than 1332 the PW flow is achieving. This condition can be satisfied by 1333 implementing a rate-limiting measure in the NSP, or by shutting down 1334 one or more PWs. The choice of which approach to use depends upon 1335 the type of traffic being carried. Where congestion is avoided by 1336 shutting down a PW, a suitable mechanism must be provided to prevent 1337 it immediately returning to service, causing a series of congestion 1338 pulses. 1340 The comparison to TCP cannot be specified exactly, but is intended as 1341 an "order-of-magnitude" comparison in timescale and throughput. The 1342 timescale on which TCP throughput is measured is the round-trip time 1343 of the connection. In essence, this requirement states that it is not 1344 acceptable to deploy an application (using PWE3 or any other 1345 transport protocol) on the best-effort Internet which consumes 1346 bandwidth arbitrarily and does not compete fairly with TCP within an 1347 order of magnitude. One method of determining an acceptable PW 1348 bandwidth is described in [RFC3448]. 1350 7. Control Plane 1352 This section describes PWE3 control plane services. 1354 7.1 Set-up or Teardown of Pseudo-Wires 1356 A PW must be set up before an emulated service can be established, 1357 and must be torn down when an emulated service is no longer needed. 1359 Set up or teardown of a PW can be triggered by an operator command, 1360 from the management plane of a PE, by signaling (i.e., set-up or 1361 teardown) of an AC, e.g., an ATM SVC, or by an auto-discovery 1362 mechanism. 1364 During the set-up process, the PEs need to exchange some information 1365 (e.g. learn each other's capabilities). The tunnel signaling 1366 protocol may be extended to provide mechanisms to enable the PEs to 1367 exchange all necessary information on behalf of the PW. 1369 Manual configuration of PWs can be considered a special kind of 1370 signaling, and is allowed. 1372 7.2 Status Monitoring 1374 Some native services have mechanisms for status monitoring. For 1375 example, ATM supports OAM for this purpose. For such services, the 1376 corresponding emulated services must specify how to perform status 1377 monitoring. 1379 7.3 Notification of Pseudo-wire Status Changes 1381 7.3.1. Pseudo-wire Up/Down Notification 1383 If a native service REQUIRES bi-directional connectivity, the 1384 corresponding emulated service can only be signaled as being up when 1385 the associated PWs, and PSN tunnels if any, are functional in both 1386 directions. 1388 Because the two CEs of an emulated service are not adjacent, a 1389 failure may occur at a place such that one or both physical links 1390 between the CEs and PEs remain up. For example, in Figure 2, if the 1391 physical link between CE1 and PE1 fails, the physical link between 1392 CE2 and PE2 will not be affected and will remain up. Unless CE2 is 1393 notified about the remote failure, it will continue to send traffic 1394 over the emulated service to CE1. Such traffic will be discarded at 1395 PE1. Some native services have failure notification so that when the 1396 services fail, both CEs will be notified. For such native services, 1397 the corresponding PWE3 service must provide a failure notification 1398 mechanism. 1400 Similarly, if a native service has notification mechanisms so that 1401 when a network failure is fixed, all the affected services will 1402 change status from "Down" to "Up", the corresponding emulated service 1403 must provide a similar mechanism for doing so. 1405 These mechanisms may already be built into the tunneling protocol. 1406 For example, the L2TP control protocol [RFC2661] [L2TPv3] has this 1407 capability and LDP has the ability to withdraw the corresponding MPLS 1408 label. 1410 7.3.2. Misconnection and Payload Type Mismatch 1412 With PWE3, misconnection and payload type mismatch can occur. If a 1413 misconnection occurs it can breach the integrity of the system. If a 1414 payload mismatch occurs it can disrupt the customer network. In both 1415 instances, there are security and operational concerns. 1417 The services of the underlying tunneling mechanism, and its 1418 associated control protocol, can be used to mitigate this. As part 1419 of the PW set-up a PW-TYPE identifier is exchanged. This is then used 1420 by the forwarder and the NSP to verify the compatibility of the ACs. 1422 7.3.3. Packet Loss, Corruption, and Out-of-order Delivery 1424 A PW can incur packet loss, corruption, and out-of-order delivery on 1425 the PSN path between the PEs. This can impact the working condition 1426 of an emulated service. For some payload types, packet loss, 1427 corruption, and out-of-order delivery can be mapped to either a bit 1428 error burst, or loss of carrier on the PW. If a native service has 1429 some mechanism to deal with bit error, the corresponding PWE3 service 1430 should provide a similar mechanism. 1432 7.3.4. Other Status Notification 1434 A PWE3 approach may provide a mechanism for other status 1435 notification, if any are needed. 1437 7.3.5. Collective Status Notification 1439 Status of a group of emulated services may be affected identically by 1440 a single network incident. For example, when the physical link (or 1441 sub-network) between a CE and a PE fails, all the emulated services 1442 that go through that link (or sub-network) will fail. It is likely 1443 that there exists a group of emulated services that all terminate at 1444 a remote CE. There may also be multiple such CEs affected by the 1445 failure. Therefore, it is desirable that a single notification 1446 message be used to notify failure of the whole group of emulated 1447 services. 1449 A PWE3 approach may provide some mechanism for notifying status 1450 changes of a group of emulated circuits. One possible method is to 1451 associate each emulated service with a group ID when the PW for that 1452 emulated service is set up. Multiple emulated services can then be 1453 grouped by associating them with the same group ID. In status 1454 notification, that group ID can be used to refer all the emulated 1455 services in that group. The group ID mechanism should be a mechanism 1456 provided by the underlying tunnel signaling protocol. 1458 7.4 Keep-alive 1460 If a native service has a keep-alive mechanism, the corresponding 1461 emulated service must provide a mechanism to propagate this across 1462 the PW. An approach following the principle of minimum intervention 1463 would be to transparently transport keep-alive messages over the PW. 1464 However, to accurately reproduce the semantics of the native 1465 mechanism, some PWs may require an alternative approach, such as 1466 piggy-backing on the PW signaling mechanism. 1468 7.5 Handling Control Messages of the Native Services 1470 Some native services use control messages for circuit maintenance. 1471 These control messages may be in-band, e.g. Ethernet flow control, 1472 ATM performance management, or TDM tone signaling, or they may be 1473 out-of-band, e.g. the signaling VC of an ATM VP, or TDM CCS 1474 signaling. 1476 From the principle of minimum intervention, it is desirable that the 1477 PEs participate as little as possible in the signaling and 1478 maintenance of the native services. This principle should not, 1479 however, override the need to satisfactorily emulate the native 1480 service. 1482 If control messages are passed through, it may be desirable to send 1483 them using either a higher priority or a reliable channel provided by 1484 the PW Demultiplexer layer. See PWE3 Channel Types. 1486 8. Management and Monitoring 1488 This section describes the management and monitoring architecture for 1489 PWE3. 1491 8.1 Status and Statistics 1493 The PE should report the status of the interface and tabulate 1494 statistics that help monitor the state of the network, and to help 1495 with measurement of service level agreements (SLAs). Typical counters 1496 include: 1498 o Counts of PW-PDUs sent and received, with and without errors. 1499 o Counts of sequenced PW-PDUs lost. 1500 o Counts of service PDUs sent and received over the PSN, with 1501 and without errors (non-TDM). 1502 o Service-specific interface counts. 1503 o One way delay and delay variation. 1505 These counters would be contained in a PW-specific MIB, and they 1506 should not replicate existing MIB counters. 1508 8.2 PW SNMP MIB Architecture 1510 This section describes the general architecture for SNMP MIBs used to 1511 manage PW services and the underlying PSN. The intent here is to 1512 provide a clear picture of how all of the pertinent MIBs fit together 1513 to form a cohesive management framework for deploying PWE3 services. 1514 Note that the names of MIB modules used below are suggestions, and do 1515 not necessarily require the actual modules used to realize the 1516 components in the architecture to be named exactly so. 1518 8.2.1. MIB Layering 1520 The SNMP MIBs created for PWE3 should fit the architecture shown in 1521 Figure 15. The architecture provides a layered modular model into 1522 which any supported emulated service can be connected to any 1523 supported PSN type. This model fosters reuse of as much functionality 1524 as possible. For instance, the emulated service layer MIB modules do 1525 not redefine the existing emulated service MIB module; rather, they 1526 only associate it with the pseudowires used to carry the emulated 1527 service over the configured PSN. In this way, the PWE3 MIB 1528 architecture follows the overall PWE3 archiecture. 1530 The archtecture does allow for the joining of unsupported emulated 1531 service or PSN types by simply defining additional MIB modules to 1532 associate these new types with existing ones. These new modules can 1533 subsequently be standardized. Note that there is a separate MIB 1534 module for each emulated service as well as one for each underlying 1535 PSN. These MIB modules may be used in various combinations as 1536 needed. 1538 Native 1539 Service MIBs ... ... ... 1540 | | | 1541 +-----------+ +-----------+ +-----------+ 1542 Service | CEP | | Ethernet | | ATM | 1543 Layer |Service MIB| |Service MIB| ... |Service MIB| 1544 +-----------+ +-----------+ +-----------+ 1545 \ | / 1546 \ | / 1547 - - - - - - - - - - - - \ - - - | - - - - / - - - - - - - 1548 \ | / 1549 +-------------------------------------------+ 1550 Generic PW | Generic PW MIBs | 1551 Layer +-------------------------------------------+ 1552 / \ 1553 - - - - - - - - - - - - / - - - - - - - - \ - - - - - - - 1554 / \ 1555 / \ 1556 +--------------+ +----------------+ 1557 PSN VC |L2TP VC MIB(s)| | MPLS VC MIB(s) | 1558 Layer +--------------+ +----------------+ 1559 | | 1560 Native +-----------+ +-----------+ 1561 PSN |L2TP MIB(s)| |MPLS MIB(s)| 1562 MIBs +-----------+ +-----------+ 1564 Figure 15: MIB Module Layering Relationship 1566 Figure 16 shows an example for a SONET PW carried over MPLS Traffic 1567 Engineering Tunnel and an LDP-signaled LSP. 1569 +-----------------+ 1570 | SONET MIB | RFC2558 1571 +-----------------+ 1572 | 1573 +------------------------------+ 1574 Service | Circuit Emulation Service MIB| 1575 Layer +------------------------------+ 1576 - - - - - - - - - - - - - | - - - - - - - - - - - - - 1577 +-----------------+ 1578 Generic PW | Generic PW MIB | 1579 Layer +-----------------+ 1580 - - - - - - - - - - - - - | - - - - - - - - - - - - - 1581 +-----------------+ 1582 PSN VC | MPLS VC MIBs | 1583 Layer +-----------------+ 1584 | | 1585 +-----------------+ +------------------+ 1586 | MPLS-TE-STD-MIB | | MPLS-LSR-STD-MIB | 1587 +-----------------+ +------------------+ 1589 Figure 16: SONET PW over MPLS PSN Service-specific Example 1591 8.2.2. Service Layer MIB Modules 1593 This conceptual layer in the model contains MIB modules used to 1594 represent the relationship between emulated PWE3 services such as 1595 Ethernet, ATM, or Frame Relay and the pseudo-wire used to carry that 1596 service across the PSN. This layer contains those corresponding MIB 1597 modules used to mate or adapt those emulated services to the generic 1598 pseudo-wire representation, which are represented in the "Generic PW 1599 MIB" functional block in Figure 16 above. This working group should 1600 not produce any MIB modules for managing the general service; rather, 1601 it should produce just those modules that are used to interface or 1602 adapt the emulated service onto the PWE3 management framework as 1603 shown above. For example, the standard SONET-MIB [RFC2558] is 1604 designed and maintained by another working group. The SONET-MIB is 1605 designed to manage the native service without PW emulation. However, 1606 since the PWE3 working group is chartered to produce standards which 1607 show how to emulate existing technologies such as SONET/SDH over 1608 pseudo-wires rather than re-inventing those modules. 1610 8.2.3. Generic PW MIB Modules 1612 The middle layer in the architecture is referred to as the Generic PW 1613 Layer. MIB in this layer are responsible for providing pseudo-wire 1614 specific counters and service models used for monitoring and 1615 configuration of PWE3 services over any supported PSN service. That 1616 is, this layer provides a general model of PWE3 abstraction for 1617 management purposes. This MIB is used to interconnect the MIB modules 1618 residing in the Service Layer to the PSN VC Layer MIBs (see section 1619 8.2.4). 1621 8.2.4. PSN VC Layer MIB Modules 1623 The third layer in the PWE3 management architecture is referred to as 1624 the PSN VC Layer. It is comprised of MIBs that are specifically 1625 designed to associate pseudo-wires onto those underlying PSN 1626 transport technologies that carry the pseudo-wire payloads across the 1627 PSN. In general this means that the MIB module provides a mapping 1628 between the emulated service that is mapped to the pseudo-wire via 1629 the Service Layer and Generic PW MIB Layer onto the native PSN 1630 service. For example, in the case of MPLS for example, it is required 1631 that the general VC service be mapped into MPLS LSPs via the MPLS- 1632 LSR-STD-MIB [LSRMIB] or Traffic Engineered (TE) Tunnels via the 1633 MPLS-TE-STD-MIB [TEMIB]. In addition, the MPLS-LDP-STD-MIB [LDPMIB] 1634 may be used to reveal the MPLS labels that are distributed over the 1635 MPLS PSN in order to maintain the PW service. As with the native 1636 service MIB modules described earlier, the MIB modules used to manage 1637 the native PSN services are produced by other working groups that 1638 design and specify the native PSN services. These MIBs should contain 1639 the appropriate mechanisms for monitoring and configuring the PSN 1640 service such that the emulated PWE3 service will function correctly. 1642 8.3 Connection Verification and Traceroute 1644 A connection verification mechanism should be supported by PWs. 1645 Connection verification as well as other alarm mechanisms can alert 1646 the operator that a PW has lost its remote connection. The opaque 1647 nature of a PW means that it is not possible to specify a generic 1648 connection verification or traceroute mechanism that passes this 1649 status to the CEs over the PW. If connection verification status of 1650 the PW is needed by the CE, it must be mapped to the native 1651 connection status method. 1653 For troubleshooting purposes, it is sometimes desirable to know the 1654 exact functional path of a PW between PEs. This is provided by the 1655 traceroute service of the underlying PSN. The opaque nature of the 1656 PW means that this traceroute information is only available within 1657 the provider network, e.g., at the PEs. 1659 9. IANA considerations 1661 IANA considerations will be identified in the PWE3 documents that 1662 define the PWE3 encapsulation, control and management protocols. 1664 10. Security Considerations 1666 PWE3 provides no means of protecting the integrity, confidentiality 1667 or delivery of the native data units. The use of PWE3 can therefore 1668 expose a particular environment to additional security threats. 1669 Assumptions that might be appropriate when all communicating systems 1670 are interconnected via a point to point or circuit-switched network 1671 may no longer hold when they are interconnected using an emulated 1672 wire carried over some types of PSN. It is outside the scope of this 1673 specification, to fully analyze and review the risks of PWE3, 1674 particularly as these risks will depend on the PSN. An example should 1675 make the concern clear. A number of IETF standards employ relatively 1676 weak security mechanisms when communicating nodes are expected to be 1677 connected to the same local area network. The Virtual Router 1678 Redundancy Protocol [RFC2338] is one instance. The relatively weak 1679 security mechanisms represent a greater vulnerability in an emulated 1680 Ethernet connected via a PW. 1682 Exploitation of vulnerabilities from within the PSN may be directed 1683 to the PW Tunnel end-point so that PW Demultiplexer and PSN tunnel 1684 services are disrupted. Controlling PSN access to the PW Tunnel 1685 end-point is one way to protect against this. By restricting PW 1686 Tunnel end-point access to legitimate remote PE sources of traffic, 1687 the PE may reject traffic that would interfere with the PW 1688 Demultiplexing and PSN tunnel services. 1690 Protection mechanisms must also address the spoofing of tunneled PW 1691 data. The validation of traffic addressed to the PW Demultiplexer 1692 end-point is paramount in ensuring integrity of PW encapsulation. 1693 Security protocols such as IPSec [RFC2401] may be used by the PW 1694 Demultiplexer Layer in order to maintain the integrity of the PW by 1695 authenticating data between the PW Demultiplexer End-points. 1697 IPSec may provide authentication, integrity, and confidentiality of 1698 data transferred between two PEs. It cannot provide the equivalent 1699 services to the native service. 1701 Based on the type of data being transferred, the PW may indicate to 1702 the PW Demultiplexer Layer that enhanced security services are 1703 required. The PW Demultiplexer Layer may define multiple protection 1704 profiles based on the requirements of the PW emulated service. CE- 1705 to-CE signaling and control events emulated by the PW and some data 1706 types may require additional protection mechanisms. Alternatively, 1707 the PW Demultiplexer Layer may use peer authentication for every PSN 1708 packet to prevent spoofed native data units from being sent to the 1709 destination CE. 1711 The unlimited transformation capability of the NSP may be perceived 1712 as a security risk. In practise the type of operation that the NSP 1713 may perform will be limited to those that have been implemented in 1714 the data path. A PE designed and managed to best current practise 1715 will have controls in place that protect and validate its 1716 configuration and these will be sufficient to ensure that the NSP 1717 behaves as expected. 1719 Acknowledgments 1721 We thank: Sasha Vainshtein for his work on Native Service Processing 1722 and advice on bit-stream over PW services. Thomas K. Johnson for his 1723 work on the background and motivation for PWs. 1725 We also thank: Ron Bonica, Stephen Casner, Durai Chinnaiah, Jayakumar 1726 Jayakumar, Ghassem Koleyni, Danny McPherson, Eric Rosen, John 1727 Rutemiller, Scott Wainner and David Zelig for their comments and 1728 contributions. 1730 Normative References 1732 Internet-drafts are works in progress available from 1733 1735 [FRAG] Malis and Townsley, "PWE3 Fragmentation and 1736 Reassembly", , 1737 work in progress, February 2004. 1739 [L2TPv3] Layer Two Tunneling Protocol (Version 3)'L2TPv3', J Lau, 1740 et. al. , work 1741 in progress, October 2003. 1743 [RFC768] RFC-768: User Datagram Protocol, J. Postel, Aug-28-1980. 1745 [RFC791] RFC-791: DARPA Internet Program, Protocol Specification, 1746 ISI, September 1981. 1748 [RFC1883] RFC-1883: Internet Protocol, Version 6 (IPv6), 1749 S. Deering, et al, December 1995 1751 [RFC1902] RFC-1902: Structure of Management Information for 1752 Version 2 of the Simple Network Management Protocol 1753 (SNMPv2), Case et al, January 1996. 1755 [RFC2119] RFC-2119, BCP-14: Key words for use in RFCs to Indicate 1756 Requirement Levels, S. Bradner. 1758 [RFC2401] RFC-2401: Security Architecture for the Internet 1759 Protocol. S. Kent, R. Atkinson. 1761 [RFC2474] RFC-2474: Definition of the Differentiated Services 1762 Field (DS Field) in the IPv4 and IPv6 Headers, 1763 K. Nichols, et. al. 1765 [RFC2558] K. Tesink, "Definitions of Managed Objects for the 1766 SONET/SDH Interface Type", RFC2558, March 1999. 1768 [RFC2661] RFC-2661: Layer Two Tunneling Protocol "L2TP". 1769 W. Townsley, et. al. 1771 [RFC2784] RFC-2784: Generic Routing Encapsulation (GRE). 1772 D. Farinacci et al. 1774 [RFC2890] RFC-2890: Key and Sequence Number Extensions to GRE. 1775 G. Dommety. 1777 [RFC3031] RFC3031: Multiprotocol Label Switching Architecture, 1778 E. Rosen, January 2001. 1780 [RFC3032] RFC3032: MPLS Label Stack Encoding, E. Rosen, 1781 January 2001. 1783 [RFC3550] RFC-3550: RTP: A Transport Protocol for Real-Time 1784 Applications. H. Schulzrinne et. al. 1786 Informative References 1788 Internet-drafts are works in progress available from 1789 1791 [DVB] EN 300 744 Digital Video Broadcasting (DVB); Framing 1792 structure, channel coding and modulation for digital 1793 terrestrial television (DVB-T), European 1794 Telecommunications Standards Institute (ETSI) 1796 [LDPMIB] Cucchiara, J., Sjostrand, H., and Luciani, J., 1797 "Definitions of Managed Objects for the Multiprotocol 1798 Label Switching, Label Distribution Protocol (LDP)", 1799 , work in progress, 1800 November 2003. 1802 [LSRMIB] Srinivasan et al, "MPLS Label Switch Router Management 1803 Information Base Using SMIv2", 1804 , work in progress, 1805 November 2003. 1807 [MPLSIP] Rosen et al, "Encapsulating MPLS in IP or Generic 1808 Routing Encapsulation (GRE)", 1809 , work in progress, 1810 March 2004 1812 [RFC1191] RFC-1191: Path MTU discovery. J.C. Mogul, S.E. Deering. 1814 [RFC1958] RFC-1958: Architectural Principles of the Internet, 1815 B. Carpenter et al. 1817 [RFC1981] RFC-1981: Path MTU Discovery for IP version 6. J. McCann, 1818 S. Deering, J. Mogul. 1820 [RFC2022] RFC-2022: Support for Multicast over UNI 3.0/3.1 based 1821 ATM Networks, G. Armitage. 1823 [RFC2338] RFC-2338: Virtual Router Redundancy Protocol, 1824 S. Knight, M. Shand et. al. 1826 [RFC3022] RFC-3022: Traditional IP Network Address Translator 1827 (Traditional NAT). P Srisuresh et al. 1829 [RFC3448] RFC3448: TCP Friendly Rate Control (TFRC): Protocol 1830 Specification, M. Handley et al. January 2003. 1832 [TEMIB] Srinivasan et al, "Traffic Engineering Management 1833 Information Base Using SMIv2", 1834 , work in progress, 1835 November 2003. 1837 [XIAO] Xiao et al, "Requirements for Pseudo-Wire Emulation 1838 Edge-to-Edge (PWE3)", 1839 (draft-ietf-pwe3-requirements-08.txt), X Xiao et al. 1840 work in progress, December 2002. 1842 Editors' Addresses 1844 Stewart Bryant 1845 Cisco Systems, 1846 250, Longwater, 1847 Green Park, 1848 Reading, RG2 6GB, 1849 United Kingdom. Email: stbryant@cisco.com 1851 Prayson Pate 1852 Overture Networks, Inc. 1853 507 Airport Boulevard 1854 Morrisville, NC, USA 27560 Email: prayson.pate@overturenetworks.com 1856 Full copyright statement 1858 Copyright (C) The Internet Society (2002). 1859 All Rights Reserved. 1861 This document and translations of it may be copied and 1862 furnished to others, and derivative works that comment 1863 on or otherwise explain it or assist in its implementation 1864 may be prepared, copied, published and distributed, in 1865 whole or in part, without restriction of any kind, 1866 provided that the above copyright notice and this 1867 paragraph are included on all such copies and derivative works. 1868 However, this document itself may not be modified in any way, 1869 such as by removing the copyright notice or references to the 1870 Internet Society or other Internet organizations, except as 1871 needed for the purpose of developing Internet standards in 1872 which case the procedures for copyrights defined in the 1873 Internet Standards process must be followed, or as required to 1874 translate it into languages other than English. 1876 The limited permissions granted above are perpetual and will 1877 not be revoked by the Internet Society or its successors or assigns. 1879 This document and the information contained herein is provided 1880 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1881 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1882 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 1883 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 1884 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1885 FOR A PARTICULAR PURPOSE.