idnits 2.17.1 draft-ietf-pwe3-arch-06.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 270 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 (October 2003) is 7498 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 1115, but not defined -- 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) == Outdated reference: A later version (-08) exists of draft-ietf-pwe3-requirements-06 Summary: 5 errors (**), 0 flaws (~~), 5 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: April 2004 Prayson Pate 5 Overture Networks, Inc. 7 Editors 9 October 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 Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in [RFC2119]. 61 Table of Contents 63 1. Introduction............................................. 5 64 1.1 Pseudo Wire Definition............................... 5 65 1.2 PW Service Functionality............................. 6 66 1.3 Non-Goals of this document........................... 6 67 1.4 Terminology.......................................... 6 69 2. PWE3 Applicability....................................... 9 71 3. Protocol Layering Model.................................. 9 72 3.1 Protocol Layers...................................... 9 73 3.2 Domain of PWE3....................................... 11 74 3.3 Payload Types........................................ 11 76 4. Architecture of Pseudo-wires............................. 14 77 4.1 Network Reference Model.............................. 14 78 4.2 PWE3 Pre-processing.................................. 15 79 4.3 Maintenance Reference Model.......................... 19 80 4.4 Protocol Stack Reference Model....................... 19 81 4.5 Pre-processing Extension to Protocol Stack Reference 82 Model................................................ 20 84 5. PW Encapsulation......................................... 21 85 5.1 Payload Convergence Layer............................ 22 86 5.2 Payload-independent PW Encapsulation Layers.......... 24 87 5.3 Fragmentation........................................ 27 88 5.4 Instantiation of the Protocol Layers................. 27 90 6. PW Demultiplexer Layer and PSN Requirements.............. 32 91 6.1 Multiplexing......................................... 32 92 6.2 Fragmentation........................................ 33 93 6.3 Length and Delivery.................................. 33 94 6.4 PW-PDU Validation.................................... 33 95 6.5 Congestion Considerations............................ 33 97 7. Control Plane............................................ 34 98 7.1 Set-up or Teardown of Pseudo-Wires................... 34 99 7.2 Status Monitoring.................................... 35 100 7.3 Notification of Pseudo-wire Status Changes........... 35 101 7.4 Keep-alive........................................... 37 102 7.5 Handling Control Messages of the Native Services..... 37 104 8. Management and Monitoring................................. 37 105 8.1 Status and Statistics................................ 37 106 8.2 PW SNMP MIB Architecture............................. 38 107 8.3 Connection Verification and Traceroute................ 41 109 9. IANA considerations...................................... 41 111 10. Security Considerations................................. 41 113 1. Introduction 115 This document describes an architecture for Pseudo Wire Emulation 116 Edge-to-Edge (PWE3) in support of [XIAO]. It discusses the emulation 117 of services (such as Frame Relay, ATM, Ethernet, TDM and SONET/SDH) 118 over packet switched networks (PSNs) using IP or MPLS. It presents 119 the architectural framework for pseudo wires (PWs), defines 120 terminology, specifies the various protocol elements and their 121 functions. 123 1.1 Pseudo Wire Definition 125 PWE3 is a mechanism that emulates the essential attributes of a 126 telecommunications service (such as a T1 leased line or Frame Relay) 127 over a PSN. PWE3 is intended to provide only the minimum necessary 128 functionality to emulate the wire with the required degree of 129 faithfulness for the given service definition. Any required switching 130 functionality is the responsibility of a forwarder function (FWRD). 131 Any translation or other operation needing knowledge of the payload 132 semantics is carried out by native service processing (NSP) elements. 133 The functional definition of any FWRD or NSP elements is outside the 134 scope of PWE3. 136 The required functions of PWs include encapsulating service-specific 137 bit-streams, cells or PDUs arriving at an ingress port, and carrying 138 them across a IP path or MPLS tunnel. In some cases it is necessary 139 to perform other operation such as managing their timing and order, 140 to emulate the behavior and characteristics of the service to the 141 required degree of faithfulness. 143 From the perspective of a Customer Edge Equipment (CE), the PW is 144 characterised as an unshared link or circuit of the chosen service. 145 In some cases, there may be deficiencies in the PW emulation that 146 impact the traffic carried over a PW, and hence limit the 147 applicability of this technology. These limitations must be fully 148 described in the appropriate service-specific documentation. 150 For each service type, there will be one default mode of operation 151 that all PEs offering that service type MUST support. However, 152 OPTIONAL modes MAY be defined to improve the faithfulness of the 153 emulated service, if it can be clearly demonstrated that the 154 additional complexity associated with the OPTIONAL mode is offset by 155 the value it offers to PW users. 157 1.2 PW Service Functionality 159 PWs provide the following functions in order to emulate the behavior 160 and characteristics of the native service. 161 o Encapsulation of service-specific PDUs or circuit data arriving 162 at the PE-bound port (logical or physical). 163 o Carriage of the encapsulated data across a PSN tunnel. 164 o Establishment of the PW including the exchange and/or 165 distribution of the PW identifiers used by the PSN 166 tunnel endpoints. 167 o Managing the signaling, timing, order or other aspects of the 168 service at the boundaries of the PW. 169 o Service-specific status and alarm management. 171 1.3 Non-Goals of this document 173 The following are non-goals for this document: 175 o The on-the-wire specification of PW encapsulations. 176 o The detailed definition of the protocols involved in PW 177 set-up and maintenance. 179 The following are outside the scope of PWE3: 180 o Any multicast service not native to the emulated medium. 181 Thus, Ethernet transmission to a "multicast" IEEE-48 address 182 is in scope, while multicast services like MARS [RFC2022] that 183 are implemented on top of the medium are out of scope. 184 o Methods to signal or control the underlying PSN. 186 1.4 Terminology 188 This document uses the following definitions of terms. These terms 189 are illustrated in context in Figure 2. 191 Attachment Circuit The physical or virtual circuit attaching 192 (AC) a CE to a PE. An attachment Circuit may be 193 for example a Frame Relay DLCI, an ATM 194 VPI/VCI, an Ethernet port, a VLAN, a PPP 195 connection on a physical interface, a 196 PPP session from an L2TP tunnel, an MPLS 197 LSP, etc. If both physical and virtual ACs 198 are of the same technology (e.g., both ATM, 199 both Ethernet, both Frame Relay) the PW 200 is said to provide "homogeneous transport"; 201 otherwise it is said to provide 202 "heterogeneous transport". 204 CE-bound The traffic direction where PW-PDUs are 205 received on a PW via the PSN, processed 206 and then sent to the destination CE. 208 CE Signaling Messages sent and received by the CEs 209 control plane. It may be desirable or 210 even necessary for the PE to participate 211 in or monitor this signaling in order 212 to effectively emulate the service. 214 Control Word (CW) A four octet header used in some encapsulations 215 to carry per packet information when the PSN 216 is MPLS. 218 Customer Edge (CE) A device where one end of a service 219 originates and/or terminates. The CE is not 220 aware that it is using an emulated service 221 rather than a native service. 223 Forwarder (FWRD) A PE subsystem that selects the PW to use to 224 transmit a payload received on an AC. 226 Fragmentation The action of dividing a single PDU into 227 multiple PDUs before transmission with the 228 intent of the original PDU being reassembled 229 elsewhere in the network. Fragmentation MAY be 230 performed in order to allow sending of packets 231 of a larger size than the network MTU which 232 they will traverse. 234 Maximum transmission The packet size (excluding data link header) 235 unit (MTU) that an interface can transmit without 236 needing to fragment. 238 Native Service Processing of the data received by the PE 239 Processing (NSP) from the CE before presentation to the PW 240 for transmission across the core, or 241 processing of the data received from a PW 242 by a PE before it is output on the AC. 243 NSP functionality is defined by standards 244 bodies other than the IETF, such as ITU-T, 245 ANSI, ATMF, etc.) 247 Packet Switched Within the context of PWE3, this is a 248 Network (PSN) network using IP or MPLS as the mechanism 249 for packet forwarding. 251 PE-bound The traffic direction where information 252 from a CE is adapted to a PW, and PW-PDUs 253 are sent into the PSN. 255 PE/PW Maintenance Used by the PEs to set up, maintain and 256 tear down the PW. It may be coupled with 257 CE Signaling in order to effectively manage 258 the PW. 260 Protocol Data The unit of data output to, or received 261 Unit (PDU) from, the network by a protocol layer. 263 Provider Edge (PE) A device that provides PWE3 to a CE. 265 Pseudo Wire (PW) A mechanism that carries the essential 266 elements of an emulated service from one PE 267 to one or more other PEs over a PSN. 269 Pseudo Wire A mechanism that emulates the essential 270 Emulation Edge to attributes of service (such as a T1 leased 271 Edge (PWE3) line or frame relay) over a PSN. 273 Pseudo Wire PDU A PDU sent on the PW that contains all of 274 (PW-PDU) the data and control information necessary 275 to emulate the desired service. 277 PSN Tunnel A tunnel across a PSN inside which one or 278 more PWs can be carried. 280 PSN Tunnel Used to set up, maintain and tear down the 281 Signaling underlying PSN tunnel. 283 PW Demultiplexer Data-plane method of identifying a PW 284 terminating at a PE. 286 PWE3 Payload Type A identifier used to distinguish between 287 Identifier an MPLS IP payload and a CW that is not 288 (PWE3-PID) ECMP safe. 290 Time Domain Time Division Multiplexing. Frequently used 291 Multiplexing (TDM) to refer to the synchronous bit-streams at 292 rates defined by G.702. 294 Tunnel A method of transparently carrying information 295 over a network. 297 2. PWE3 Applicability 299 The PSN carrying a PW will subject payload packets to loss, delay, 300 delay variation, and re-ordering. During a network transient there 301 may be a sustained period of impaired service. The applicability of 302 PWE3 to a particular service depends on the sensitivity of that 303 service (or the CE implementation) to these effects, and the ability 304 of the adaptation layer to mask them. Some services, such as IP over 305 FR over PWE3, may prove quite resilient to IP and MPLS PSN 306 characteristics. Other services, such as the interconnection of PBX 307 systems via PWE3, will require more careful consideration of the PSN 308 and adaptation layer characteristics. In some instances, traffic 309 engineering of the underlying PSN will be required, and in some 310 cases, the constraints may be such that it is not possible to provide 311 the required service guarantees. 313 3. Protocol Layering Model 315 The PWE3 protocol-layering model is intended to minimise the 316 differences between PWs operating over different PSN types. The 317 design of the protocol-layering model has the goals of making each PW 318 definition independent of the underlying PSN, and maximizing the 319 reuse of IETF protocol definitions and their implementations. 321 3.1 Protocol Layers 323 The logical protocol-layering model required to support a PW is shown 324 in Figure 1. 326 +---------------------------+ 327 | Payload | 328 +---------------------------+ 329 | Encapsulation | <==== MAY be null 330 +---------------------------+ 331 | PW Demultiplexer | 332 +---------------------------+ 333 | PSN Convergence | <==== MAY be null 334 +---------------------------+ 335 | PSN | 336 +---------------------------+ 337 | Data-link | 338 +---------------------------+ 339 | Physical | 340 +---------------------------+ 342 Figure 1: Logical Protocol Layering Model 344 The payload is transported over the Encapsulation Layer. The 345 Encapsulation Layer carries any information, not already present 346 within the payload itself, that is needed by the PW CE-bound PE 347 interface to send the payload to the CE via the physical interface. 348 If no information is needed beyond that in the payload itself, this 349 layer is empty. 351 This layer also provides support for real-time processing, and 352 sequencing, if needed. 354 The PW Demultiplexer Layer provides the ability to deliver multiple 355 PWs over a single PSN tunnel. The PW demultiplexer value used to 356 identify the PW in the data-plane may be unique per PE, but this is 357 not a PWE3 requirement. It MUST, however, be unique per tunnel 358 endpoint. If it is necessary to identify a particular tunnel, then 359 that is the responsibility of the PSN layer. 361 The PSN Convergence Layer provides the enhancements needed to make 362 the PSN conform to the assumed PSN service requirement. This layer 363 therefore provides a consistent interface to the PW, making the PW 364 independent of the PSN type. If the PSN already meets the service 365 requirements, this layer is empty. 367 The PSN header, MAC/Data-link and Physical Layer definitions are 368 outside the scope of this document. The PSN can be IPv4, IPv6 or 369 MPLS. 371 3.2 Domain of PWE3 373 PWE3 defines the Encapsulation Layer, the method of carrying various 374 payload types, and the interface to the PW Demultiplexer Layer. It 375 is expected that the other layers will be provided by tunneling 376 methods such as L2TP or MPLS over the PSN. 378 3.3 Payload Types 380 The payload is classified into the following generic types of native 381 data unit: 383 o Packet 384 o Cell 385 o Bit-stream 386 o Structured bit-stream 388 Within these generic types there are specific service types. For 389 example: 391 Generic Payload Type PW Service 392 -------------------- ---------- 393 Packet Ethernet (all types), HDLC framing, 394 frame-relay, ATM AAL5 PDU. 396 Cell ATM. 398 Bit-stream Unstructured E1, T1, E3, T3. 400 Structured bit-stream SONET/SDH (e.g. SPE, VT, NxDS0). 402 3.3.1. Packet Payload 404 A packet payload is a variable-size data unit delivered to the PE via 405 the AC. A packet payload may be large compared to the PSN MTU. The 406 delineation of the packet boundaries is encapsulation-specific. HDLC 407 or Ethernet PDUs can be considered as examples of packet payloads. 408 Typically a packet will be stripped of transmission overhead such as 409 HDLC flags and stuffing bits before transmission over the PW. 411 A packet payload would normally be relayed across the PW as a single 412 unit. However, there will be cases where the combined size of the 413 packet payload and its associated PWE3 and PSN headers exceeds the 414 PSN path MTU. In these cases, some fragmentation methodology needs 415 to be applied. This may, for example, be the case when a user is 416 providing the service and attaching to the service provider via 417 Ethernet, or where nested pseudo-wires are involved. Fragmentation is 418 discussed in more detail in Section 5.3 420 A packet payload may need sequencing and real-time support. 422 In some situations, the packet payload MAY be selected from the 423 packets presented on the emulated wire on the basis of some sub- 424 multiplexing technique. For example, one or more frame-relay PDUs 425 may be selected for transport over a particular pseudo-wire based on 426 the frame-relay Data-Link Connection Identifier (DLCI), or, in the 427 case of Ethernet payloads, using a suitable MAC bridge filter. This 428 is a forwarder function, and this selection would therefore be made 429 before the packet was presented to the PW Encapsulation Layer. 431 3.3.2. Cell Payload 433 A cell payload is created by capturing, transporting and replaying 434 groups of octets presented on the wire in a fixed-size format. The 435 delineation of the group of bits that comprise the cell is specific 436 to the encapsulation type. Two common examples of cell payloads are 437 ATM 53-octet cells, and the larger 188-octet MPEG Transport Stream 438 packets [DVB]. 440 To reduce per-PSN packet overhead, multiple cells MAY be concatenated 441 into a single payload. The Encapsulation Layer MAY consider the 442 payload complete on the expiry of a timer, after a fixed number of 443 cells have been received or when a significant cell (e.g. an ATM OAM 444 cell) has been received. The benefit of concatenating multiple PDUs 445 should be weighed against a possible increase in packet delay 446 variation and the larger penalty incurred by packet loss. In some 447 cases, it may be appropriate for the Encapsulation Layer to perform 448 some type of compression, such as silence suppression or voice 449 compression. 451 The generic cell payload service will normally need sequence number 452 support, and may also need real-time support. The generic cell 453 payload service would not normally require fragmentation. 455 The Encapsulation Layer MAY apply some form of compression to some of 456 these sub-types (e.g. idle cells MAY be suppressed). 458 In some instances, the cells to be incorporated in the payload MAY be 459 selected by filtering them from the stream of cells presented on the 460 wire. For example, an ATM PWE3 service may select cells based on 461 their VCI or VPI fields. This is a forwader function, and the 462 selection would therefore be made before the packet was presented to 463 the PW Encapsulation Layer. 465 3.3.3. Bit-stream 467 A bit-stream payload is created by capturing, transporting and 468 replaying the bit pattern on the emulated wire, without taking 469 advantage of any structure that, on inspection, may be visible within 470 the relayed traffic (i.e. the internal structure has no effect on the 471 fragmentation into packets). 473 In some instances it is possible to apply suppression to bit-streams. 474 For example, E1 and T1 send "all-ones" to indicate failure. This 475 condition can be detected without any knowledge of the structure of 476 the bit-stream, and transmission of packetized data suppressed. 478 This service will require sequencing and real-time support. 480 3.3.4. Structured bit-stream 482 A structured bit-stream payload is created by using some knowledge of 483 the underlying structure of the bit-stream to capture, transport and 484 replay the bit pattern on the emulated wire. 486 Two important points distinguish structured and unstructured bit- 487 streams: 489 o Some parts of the original bit-stream MAY be stripped in the 490 PSN-bound direction by NSP block. For example, in Structured 491 SONET the section and line overhead (and, possibly more) may 492 be stripped. A framer is required to enable such stripping. 493 It is also required for frame/payload alignment for 494 fractional T1/E1 applications. 496 o The PW MUST preserve the structure across the PSN so that 497 the CE-bound NSP block can insert it correctly into the 498 reconstructed unstructured bit-stream. The stripped 499 information (such as SONET pointer justifications) may 500 appear in the encapsulation layer to facilitate this 501 reconstitution. 503 As an option, the Encapsulation Layer MAY also perform silence/idle 504 suppression or similar compression on a structured bit-stream. 506 Structured bit-streams are distinguished from cells in that the 507 structures may be too long to be carried in a single packet. Note 508 that "short" structures are indistinguishable from cells and may 509 benefit from the use of methods described in section 3.3.2. 511 This service REQUIRES sequencing and real-time support. 513 3.3.5. Principle of Minimum Intervention 515 To minimise the scope of information, and to improve the efficiency 516 of data flow through the Encapsulation Layer, the payload SHOULD be 517 transported as received with as few modifications as possible 518 [RFC1958]. 520 This minimum intervention approach decouples payload development from 521 PW development and requires fewer translations at the NSP in a system 522 with similar CE interfaces at each end. It also prevents unwanted 523 side-effects due to subtle misrepresentation of the payload in the 524 intermediate format. 526 An approach which does intervene can be more wire-efficient in some 527 cases and may result in fewer translations at the NSP where the CE 528 interfaces are of different types. Any intermediate format 529 effectively becomes a new framing type, requiring documentation and 530 assured interoperability. This increases the amount of work for 531 handling the protocol the intermediate format carries, and is 532 undesirable. 534 4. Architecture of Pseudo-wires 536 This section describes the PWE3 architectural model. 538 4.1 Network Reference Model 540 Figure 2 illustrates the network reference model for point-to-point 541 PWs. 543 |<-------------- Emulated Service ---------------->| 544 | | 545 | |<------- Pseudo Wire ------>| | 546 | | | | 547 | | |<-- PSN Tunnel -->| | | 548 | PW End V V V V PW End | 549 V Service +----+ +----+ Service V 550 +-----+ | | PE1|==================| PE2| | +-----+ 551 | |----------|............PW1.............|----------| | 552 | CE1 | | | | | | | | CE2 | 553 | |----------|............PW2.............|----------| | 554 +-----+ ^ | | |==================| | | ^ +-----+ 555 ^ | +----+ +----+ | | ^ 556 | | Provider Edge 1 Provider Edge 2 | | 557 | | | | 558 Customer | | Customer 559 Edge 1 | | Edge 2 560 | | 561 | | 562 native service native service 564 Figure 2: PWE3 Network Reference Model 566 The two PEs (PE1 and PE2) need to provide one or more PWs on behalf 567 of their client CEs (CE1 and CE2) to enable the client CEs to 568 communicate over the PSN. A PSN tunnel is established to provide a 569 data path for the PW. The PW traffic is invisible to the core 570 network, and the core network is transparent to the CEs. Native data 571 units (bits, cells or packets) arrive via the AC, are encapsulated in 572 a PW-PDU and are carried across the underlying network via the PSN 573 tunnel. The PEs perform the necessary encapsulation and decapsulation 574 of PW-PDUs, as well as handling any other functions required by the 575 PW service, such as sequencing or timing. 577 4.2 PWE3 Pre-processing 579 In some applications, there is a need to perform operations on the 580 native data units received from the CE (including both payload and 581 signaling traffic) before they are transmitted across the PW by the 582 PE. Examples include Ethernet bridging, SONET cross-connect, 583 translation of locally-significant identifiers such as VCI/VPI, or 584 translation to another service type. These operations could be 585 carried out in external equipment, and the processed data sent to the 586 PE over one or more physical interfaces. In most cases, there are 587 cost and operational benefits in undertaking these operations within 588 the PE. This processed data is then presented to the PW via a 589 virtual interface within the PE. 591 These pre-processing operations are included in the PWE3 reference 592 model to provide a common reference point, but the detailed 593 description of these operations is outside the scope of the PW 594 definition given here. 596 PW 597 End Service 598 | 599 |<------- Pseudo Wire ------>| 600 | | 601 | |<-- PSN Tunnel -->| | 602 V V V V PW 603 +-----+----+ +----+ End Service 604 +-----+ |PREP | PE1|==================| PE2| | +-----+ 605 | | | |............PW1.............|----------| | 606 | CE1 |----| | | | | | | CE2 | 607 | | ^ | |............PW2.............|----------| | 608 +-----+ | | | |==================| | | ^ +-----+ 609 | +-----+----+ +----+ | | 610 | ^ | | 611 | | | | 612 | |<------- Emulated Service ------->| | 613 | | | 614 | Virtual physical | 615 | termination | 616 | ^ | 617 CE1 native | CE2 native 618 service | service 619 | 620 CE2 native 621 service 623 Figure 3: Pre-processing within the PWE3 Network Reference Model 625 Figure 3 shows the inter-working of one PE with pre-processing 626 (PREP), and a second without this functionality. This is a useful 627 reference point because it emphasises that the functional interface 628 between PREP and the PW is that represented by a physical interface 629 carrying the service. This effectively defines the necessary inter- 630 working specification. 632 The operation of a system in which both PEs include PREP 633 functionality is also supported. 635 The required pre-processing can be divided into two components: 636 o Forwarder (FWRD) 638 o Native Service Processing (NSP) 640 4.2.1. Forwarders 642 In some applications there is the need to selectively forward payload 643 elements from one or more ACs to one or more PWs. In such cases there 644 will also be the need to perform the inverse function on PWE3-PDUs 645 received by a PE from the PSN. This is the function of the forwarder. 647 The forwarder selects the PW based on, for example: the incoming AC, 648 the contents of the payload, or some statically and/or dynamically 649 configured forwarding information. 651 +----------------------------------------+ 652 | PE Device | 653 +----------------------------------------+ 654 Single | | | 655 AC | | Single | PW Instance 656 <------>o Forwarder + PW Instance X<===========> 657 | | | 658 +----------------------------------------+ 660 Figure 4a: Simple point-to-point service 662 +----------------------------------------+ 663 | PE Device | 664 +----------------------------------------+ 665 Multiple| | Single | PW Instance 666 AC | + PW Instance X<===========> 667 <------>o | | 668 | |----------------------| 669 <------>o | Single | PW Instance 670 | Forwarder + PW Instance X<===========> 671 <------>o | | 672 | |----------------------| 673 <------>o | Single | PW Instance 674 | + PW Instance X<===========> 675 <------>o | | 676 +----------------------------------------+ 678 Figure 4b: Multiple AC to Multiple PW Forwarding 680 Figure 4a shows a simple forwarder that performs some type of 681 filtering operation. Because the forwarder has a single input and a 682 single output interface, filtering is the only type of forwarding 683 operation that applies. Figure 4b shows a more general forwarding 684 situation where payloads are extracted from one or more ACs and 685 directed to one or more PWs. In this case filtering, direction and 686 combination operations MAY be performed on the payloads. For 687 example, if the AC were frame relay, the forwarder might perform 688 frame relay switching and the PW instances might be the inter-switch 689 links. 691 4.2.2. Native Service Processing 693 In some applications some form of data or address translation, or 694 other operation requiring knowledge of the semantics of the payload, 695 will be required. This is the function of the Native Service 696 Processor (NSP). 698 The use of the NSP approach simplifies the design of the PW by 699 restricting a PW to homogeneous operation. NSP is included in the 700 reference model to provide a defined interface to this functionality. 701 The specification of the various types of NSP is outside the scope of 702 PWE3. 704 +----------------------------------------+ 705 | PE Device | 706 Multiple+----------------------------------------+ 707 AC | | | Single | PW Instance 708 <------>o NSP # + PW Instance X<===========> 709 | | | | 710 |------| |----------------------| 711 | | | Single | PW Instance 712 <------>o NSP #Forwarder + PW Instance X<===========> 713 | | | | 714 |------| |----------------------| 715 | | | Single | PW Instance 716 <------>o NSP # + PW Instance X<===========> 717 | | | | 718 +----------------------------------------+ 720 Figure 5: NSP in a Multiple AC to Multiple 721 PW Forwarding PE 723 Figure 5 illustrates the relationship between NSP, forwarder and PWs 724 in a PE. The NSP function MAY apply any transformation operation 725 (modification, injection, etc.) on the payloads as they pass between 726 the physical interface to the CE and the virtual interface to the 727 forwarder. These transformation operations will of course be limited 728 to those that have been implemented in the data path, and which are 729 enabled by the PE configuration. A PE device MAY contain more than 730 one forwarder. 732 This model also supports the operation of a system in which the NSP 733 functionality includes terminating the data-link, and applying 734 Network Layer processing to the payload is also supported. 736 4.3 Maintenance Reference Model 738 Figure 6 illustrates the maintenance reference model for PWs. 740 |<------- CE (end-to-end) Signaling ------>| 741 | |<---- PW/PE Maintenance ----->| | 742 | | |<-- PSN Tunnel -->| | | 743 | | | Signaling | | | 744 | V V (out of scope) V V | 745 v +-----+ +-----+ v 746 +-----+ | PE1 |==================| PE2 | +-----+ 747 | |-----|.............PW1..............|-----| | 748 | CE1 | | | | | | CE2 | 749 | |-----|.............PW2..............|-----| | 750 +-----+ | |==================| | +-----+ 751 +-----+ +-----+ 752 Customer Provider Provider Customer 753 Edge 1 Edge 1 Edge 2 Edge 2 755 Figure 6: PWE3 Maintenance Reference Model 757 The following signaling mechanisms are REQUIRED: 759 o The CE (end-to-end) signaling is between the CEs. This 760 signaling could be frame relay PVC status signaling, ATM SVC 761 signaling, TDM CAS signaling, etc. 763 o The PW/PE Maintenance is used between the PEs (or NSPs) to set 764 up, maintain and tear down PWs, including any required 765 coordination of parameters. 767 o The PSN Tunnel signaling controls the PW multiplexing and some 768 elements of the underlying PSN. Examples are L2TP control 769 protocol, MPLS LDP and RSVP-TE. The definition of the 770 information that PWE3 needs to be signaled is within the scope 771 of PWE3, but the signaling protocol itself is not. 773 4.4 Protocol Stack Reference Model 775 Figure 7 illustrates the protocol stack reference model for PWs. 777 +-----------------+ +-----------------+ 778 |Emulated Service | |Emulated Service | 779 |(e.g. TDM, ATM) |<==== Emulated Service ===>|(e.g. TDM, ATM) | 780 +-----------------+ +-----------------+ 781 | Payload | | Payload | 782 | Encapsulation |<====== Pseudo Wire ======>| Encapsulation | 783 +-----------------+ +-----------------+ 784 |PW Demultiplexer | |PW Demultiplexer | 785 | PSN Tunnel, |<======= PSN Tunnel ======>| PSN Tunnel, | 786 | PSN & Physical | | PSN & Physical | 787 | Layers | | Layers | 788 +-------+---------+ ___________ +---------+-------+ 789 | / \ | 790 +===============/ PSN \===============+ 791 \ / 792 \_____________/ 794 Figure 7: PWE3 Protocol Stack Reference Model 796 The PW provides the CE with an emulated physical or virtual 797 connection to its peer at the far end. Native service PDUs from the 798 CE are passed through an Encapsulation Layer at the sending PE, and 799 then sent over the PSN. The receiving PE removes the encapsulation 800 and restores the payload to its native format for transmission to the 801 destination CE. 803 4.5 Pre-processing Extension to Protocol Stack Reference Model 805 Figure 8 illustrates how the protocol stack reference model is 806 extended to include the provision of pre-processing (Forwarding and 807 NSP). This shows the placement of the physical interface relative to 808 the CE. 810 /======================================\ 811 H Forwarder H<----Pre-processing 812 H----------------======================/ 813 H Native Service H | | 814 H Processing H | | 815 \================/ | | 816 | | | Emulated | 817 | Service | | Service | 818 | Interface | | (TDM, ATM, | 819 | (TDM, ATM, | | Ethernet, |<== Emulated Service == 820 | Ethernet, | | frame relay, | 821 | frame relay, | | etc.) | 822 | etc.) | +-----------------+ 823 | | | Payload | 824 | | | Encapsulation |<=== Pseudo Wire ====== 825 | | +-----------------+ 826 | | |PW Demultiplexer | 827 | | | PSN Tunnel, | 828 | | | PSN & Physical |<=== PSN Tunnel ======= 829 | | | Headers | 830 +----------------+ +-----------------+ 831 | Physical | | Physical | 832 +-------+--------+ +-------+---------+ 833 | | 834 | | 835 | | 836 | | 837 | | 838 | | 839 To CE <---+ +---> To PSN 841 Figure 8: Protocol Stack Reference Model with Pre-processing 843 5. PW Encapsulation 845 The PW Encapsulation Layer provides the necessary infrastructure to 846 adapt the specific payload type being transported over the PW to the 847 PW Demultiplexer Layer that is used to carry the PW over the PSN. 849 The PW Encapsulation Layer consists of three sub-layers: 851 o Payload Convergence 852 o Timing 853 o Sequencing 855 The PW Encapsulation sub-layering and its context with the protocol 856 stack are shown, in Figure 9. 858 +---------------------------+ 859 | Payload | 860 /===========================\ <------ Encapsulation 861 H Payload Convergence H Layer 862 H---------------------------H 863 H Timing H 864 H---------------------------H 865 H Sequencing H 866 \===========================/ 867 | PW Demultiplexer | 868 +---------------------------+ 869 | PSN Convergence | 870 +---------------------------+ 871 | PSN | 872 +---------------------------+ 873 | Data-link | 874 +---------------------------+ 875 | Physical | 876 +---------------------------+ 878 Figure 9: PWE3 Encapsulation Layer in Context 880 The Payload Convergence Sub-layer is highly tailored to the specific 881 payload type, but, by grouping a number of target payload types into 882 a generic class, and then providing a single convergence sub-layer 883 type common to the group, we achieve a reduction in the number of 884 payload convergence sub-layer types. This decreases implementation 885 complexity. The provision of per-packet signaling and other out-of- 886 band information (other than sequencing or timing) is undertaken by 887 this layer. 889 The Timing Layer and the Sequencing Layer provide generic services to 890 the Payload Convergence Layer for all payload types that require 891 them. 893 5.1 Payload Convergence Layer 895 5.1.1. Encapsulation 897 The primary task of the Payload Convergence Layer is the 898 encapsulation of the payload in PW-PDUs. The native data units to be 899 encapsulated MAY contain a L2 header or L1 overhead. This is service 900 specific. The Payload Convergence header carries the additional 901 information needed to replay the native data units at the CE-bound 902 physical interface. The PW Demultiplexer header is not considered as 903 part of the PW header. 905 Not all the additional information needed to replay the native data 906 units need to be carried in the PW header of the PW PDUs. Some 907 information (e.g. service type of a PW) MAY be stored as state 908 information at the destination PE during PW set-up. 910 5.1.2. PWE3 Channel Types 912 The PW Encapsulation Layer and its associated signaling require one 913 or more of the following types of channels from its underlying PW 914 Demultiplexer and PSN Layers: 916 1. A reliable control channel for signaling line events, status 917 indications, and, in some exceptional cases, CE-CE events 918 that must be translated and sent reliably between PEs. 920 For example, this capability is needed in [PPPoL2TP] 921 (PPP negotiation has to be split between the two ends of the 922 tunnel). PWE3 may also need this type of control channel to 923 provide faithful emulation of complex data-link protocols. 925 plus one or more data channels with the following characteristics: 927 2. A high-priority, unreliable, sequenced channel. A typical use 928 is for CE-to-CE signaling. "High priority" may simply be 929 indicated via the DSCP bits for IP or the EXP bits for MPLS, 930 giving the packet priority during transit. This channel type 931 could also use a bit in the tunnel header itself to indicate 932 that packets received at the PE SHOULD be processed with higher 933 priority [RFC2474]. 935 3. A sequenced channel for data traffic that is sensitive to 936 packet reordering (one classification for use could be for 937 any non-IP traffic). 939 4. An un-sequenced channel for data traffic insensitive to packet 940 order. 942 The data channels (2, 3 and 4 above) SHOULD be carried "in band" with 943 one another to as much of a degree as is reasonably possible on a 944 PSN. 946 Where end-to-end connectivity may be disrupted by address translation 947 [RFC3022], access-control lists, firewalls etc., there exists the 948 possibility that the control channel may be able to pass traffic and 949 set-up the PW, but the PW data traffic is blocked by one or more of 950 these mechanisms. In these cases unless the control channel is also 951 carried "in band" the signaling to set-up the PW will not confirm the 952 existence of an end-to-end data path. 954 In some cases there is a need to synchronize CE events with the data 955 carried over a PW. This is especially the case with TDM circuits 956 (e.g., the on-hook/off-hook events in PSTN switches might be carried 957 over a reliable control channel, whilst the associated bit-stream is 958 carried over a sequenced data channel). 960 PWE3 channel types that are not needed by the supported PWs need not 961 be included in such an implementation. 963 5.1.3. Quality of Service Considerations 965 Where possible, it is desirable to employ mechanisms to provide PW 966 Quality of Service (QoS) support over PSNs. 968 5.2 Payload-independent PW Encapsulation Layers 970 Two PWE3 Encapsulation Sub-layers provide common services to all 971 payload types: Sequencing and Timing. These services are optional 972 and are only used if needed by a particular PW instance. If the 973 service is not needed, the associated header MAY be omitted in order 974 to conserve processing and network resources. 976 There will be instances where a specific payload type will be 977 required to be transported with or without sequence and/or real-time 978 support. For example, an invariant of frame relay transport is the 979 preservation of packet order. Some frame-relay applications expect 980 in-order delivery, and may not cope with reordering of the frames. 981 However, where the frame relay service is itself only being used to 982 carry IP, it may be desirable to relax that constraint in return for 983 reduced per-packet processing cost. 985 The guiding principle is that, where possible, an existing IETF 986 protocol SHOULD be used to provide these services. Where a suitable 987 protocol is not available, the existing protocol should be extended 988 or modified to meet the PWE3 requirements, thereby making that 989 protocol available for other IETF uses. In the particular case of 990 timing, more than one general method may be necessary to provide for 991 the full scope of payload timing requirements. 993 5.2.1. Sequencing 995 The sequencing function provides three services: frame ordering, 996 frame duplication detection and frame loss detection. These services 997 allow the emulation of the invariant properties of a physical wire. 998 Support for sequencing depends on the payload type, and MAY be 999 omitted if not needed. 1001 The size of the sequence-number space depends on the speed of the 1002 emulated service, and the maximum time of the transient conditions in 1003 the PSN. A sequence number space greater than 2^16 may therefore be 1004 needed to prevent the sequence number space wrapping during the 1005 transient. 1007 5.2.1.1 Frame Ordering 1009 When packets carrying the PW-PDUs traverse a PSN, they may arrive out 1010 of order at the destination PE. For some services, the frames 1011 (control frames, data frames, or both control and data frames) MUST 1012 be delivered in order. For such services, some mechanism MUST be 1013 provided for ensuring in-order delivery. Providing a sequence number 1014 in the sequence sub-layer header for each packet is one possible 1015 approach to out-of-sequence detection. Alternatively it can be noted 1016 that sequencing is a subset of the problem of delivering timed 1017 packets, and that a single combined mechanism such as [RFC3550] MAY 1018 be employed. 1020 There are two possible misordering strategies: 1022 o Drop misordered PW PDUs. 1024 o Try to sort PW PDUs into the correct order. 1026 The choice of strategy will depend on: 1028 o How critical the loss of packets is to the operation of 1029 the PW (e.g. the acceptable bit error rate). 1031 o The speeds of the PW and PSN. 1033 o The acceptable delay (since delay must be introduced to 1034 reorder) 1036 o The incidence of expected misordering. 1038 5.2.1.2 Frame Duplication Detection 1040 In rare cases, packets traversing a PW may be duplicated by the 1041 underlying PSN. For some services frame duplication is not 1042 acceptable. For such services, some mechanism MUST be provided to 1043 ensure that duplicated frames will not be delivered to the 1044 destination CE. The mechanism MAY be the same as the mechanism used 1045 to ensure in-order frame delivery. 1047 5.2.1.3 Frame Loss Detection 1049 A destination PE can determine whether a frame has been lost by 1050 tracking the sequence numbers of the received PW PDUs. 1052 In some instances, a destination PE will have to presume that a PW 1053 PDU is lost if it fails to arrive within a certain time. If a PW-PDU 1054 that has been processed as lost subsequently arrives, the destination 1055 PE MUST discard it. 1057 5.2.2. Timing 1059 A number of native services have timing expectations based on the 1060 characteristics of the networks that they were designed to travel 1061 over, and it can be necessary for the emulated service to duplicate 1062 these network characteristics as closely as possible, e.g. in 1063 delivering native traffic with bit-rate, jitter, wander and delay 1064 characteristics similar to those received at the sending PE. 1066 In such cases, it is necessary for the receiving PE to play out the 1067 native traffic as it was received at the sending PE. This relies on 1068 either timing information sent between the two PEs, or in some case 1069 timing information received from an external reference. 1071 The Timing Sub-layer must therefore support two timing functions: 1072 clock recovery and timed payload delivery. A particular payload type 1073 may require either or both of these services. 1075 5.2.2.1 Clock Recovery 1077 Clock recovery is the extraction of output transmission bit timing 1078 information from the delivered packet stream, and requires a suitable 1079 mechanism. A physical wire carries the timing information natively, 1080 but it is a relatively complex task to extract timing from a highly 1081 jittered source such as packet stream. It is therefore desirable 1082 that an existing real-time protocol such as [RFC3550] be used for 1083 this purpose, unless it can be shown that this is unsuitable or 1084 unnecessary for a particular payload type. 1086 5.2.2.2 Timed delivery 1088 Timed delivery is the delivery of non-contiguous PW PDUs to the PW 1089 output interface with a constant phase relative to the input 1090 interface. The timing of the delivery may be relative to a clock 1091 derived from the packet stream received over the PSN clock recovery, 1092 or with reference to an external clock. 1094 5.3 Fragmentation 1096 A payload would ideally be relayed across the PW as a single unit. 1097 However, there will be cases where the combined size of the payload 1098 and its associated PWE3 and PSN headers exceeds the PSN path MTU. 1099 When a packet size exceeds the MTU of a given network, fragmentation 1100 and reassembly have to be performed in order for the packet to be 1101 delivered. Since fragmentation and reassembly generally consume a 1102 considerable network resources as compared to simply switching a 1103 packet in its entirety, efforts SHOULD be made to reduce or eliminate 1104 the need for fragmentation and reassembly throughout a network to the 1105 extent possible. Of particular concern for fragmentation and 1106 reassembly are aggregation points where large numbers of PWs are 1107 processed (e.g. at the PE). 1109 Ideally, the equipment originating the traffic being sent over the PW 1110 will be configured to have adaptive measures (e.g. [RFC1191], 1111 [RFC1981]) in place that ensure that packets that need to be 1112 fragmented are not sent. When this fails, the point closest to the 1113 sending host with fragmentation and reassembly capabilities SHOULD 1114 attempt to reduce the size of packets to satisfy the PSN MTU. Thus, 1115 in the reference model for PWE3 [Figure 3] fragmentation SHOULD first 1116 be performed at the CE if at all possible. If and only if the CE 1117 cannot adhere to an acceptable MTU size for the PW should the PE 1118 attempt its own fragmentation method. 1120 In cases where MTU management fails to limit the payload to a size 1121 suitable for transmission of the PW, the PE MAY fall back to either a 1122 generic PW fragmentation method, or, if available the fragmentation 1123 service of the underlying PSN. 1125 It is acceptable for a PE implementation not to support 1126 fragmentation. A PE that does not support fragmentation will drop 1127 packets that exceed the PSN MTU, and the management plane of the 1128 encapsulating PE MAY be notified. 1130 If the length of a L2/L1 frame, restored from a PW PDU, exceeds the 1131 MTU of the destination AC, it MUST be dropped. In this case, the 1132 management plane of the destination PE MAY be notified. 1134 5.4 Instantiation of the Protocol Layers 1136 This document does not address the detailed mapping of the Protocol 1137 Layering model to existing or future IETF standards. The 1138 instantiation of the logical Protocol Layering model is shown in 1139 Figure 9. 1141 5.4.1. PWE3 over an IP PSN 1143 The protocol definition of PWE3 over an IP PSN SHOULD employ existing 1144 IETF protocols where possible. 1146 +---------------------+ +-------------------------+ 1147 | Payload |------------->| Raw payload if possible | 1148 /=====================\ +-------------------------+ 1149 H Payload Convergence H-----------+->| As Needed | 1150 H---------------------H / +-------------------------+ 1151 H Timing H---------/--->| RTP | 1152 H---------------------H / +-------------+ | 1153 H Sequencing H----one of | | 1154 \=====================/ \ | +-----------+ 1155 | PW Demultiplexer |---------+--->| L2TP, MPLS etc. | 1156 +---------------------+ +-------------------------+ 1157 | PSN Convergence |------------->| Not needed | 1158 +---------------------+ +-------------------------+ 1159 | PSN |------------->| IP | 1160 +---------------------+ +-------------------------+ 1161 | Data-link |------------->| Data-link | 1162 +---------------------+ +-------------------------+ 1163 | Physical |------------->| Physical | 1164 +---------------------+ +-------------------------+ 1166 Figure 10: PWE3 over an IP PSN 1168 Figure 10 shows the protocol layering for PWE3 over an IP PSN. As a 1169 rule, the payload SHOULD be carried as received from the NSP, with 1170 the Payload Convergence Layer provided when needed. (It is accepted 1171 that there MAY sometimes be good reason not to follow this rule, but 1172 the exceptional circumstances need to be documented in the 1173 Encapsulation Layer definition for that payload type). 1175 Where appropriate, timing is provided by RTP [RFC3550], which when 1176 used also provides a sequencing service. PW Demultiplexing may be 1177 provided by a number of existing IETF tunnel protocols. Some of 1178 these tunnel protocols provide an optional sequencing service. 1179 (Sequencing is provided either by RTP, or by the PW Demultiplexer 1180 Layer, but not both). 1182 RTP is normally carried over UDP, however the tunnel protcols that 1183 are capable of carrying a PW, provide sufficient functionality to 1184 carry RTP without an intervening transport layer. UDP MAY therefore 1185 be omitted from the protocol stack. 1187 A PSN Convergence Layer is not needed, because all the tunnel 1188 protocols shown above are designed to operate directly over an IP 1189 PSN. 1191 As a special case, if the PW Demultiplexer is an MPLS label, the 1192 protocol architecture of section 5.4.2 can be used instead of the 1193 protocol architecture of this section. 1195 5.4.2. PWE3 over an MPLS PSN 1197 The MPLS ethos places importance on wire efficiency. By using a 1198 control word, some components of the PWE3 protocol layers can be 1199 compressed to increase this efficiency. 1201 +---------------------+ 1202 | Payload | 1203 /=====================\ 1204 H Payload Convergence H--+ 1205 H---------------------H | +--------------------------------+ 1206 H Timing H--------->| RTP | 1207 H---------------------H | +--------------------------------+ 1208 H Sequencing H--+------>| Flags, Frag, Len, Seq #, etc | 1209 \=====================/ | +--------------------------------+ 1210 | PW Demultiplexer |----+ | PWE3 Payload Type Identifier | 1211 +---------------------+ | | +--------------------------------+ 1212 | PSN Convergence |--+ +---->| PW Label | 1213 +---------------------+ +--------------------------------+ 1214 | PSN |--------->| Outer Label or MPLS-in-IP encap| 1215 +---------------------+ +--------------------------------+ 1216 | Data-link | 1217 +---------------------+ 1218 | Physical | 1219 +---------------------+ 1221 Figure 11: PWE3 over an MPLS PSN using a control word 1223 Figure 11 shows the protocol layering for PWE3 over an MPLS PSN. An 1224 inner MPLS label is used to provide the PW demultiplexing function. 1225 A control word is used to carry most of the information needed by the 1226 PWE3 Encapsulation Layer and the PSN Convergence Layer in a compact 1227 format. The flags in the control word provide the necessary payload 1228 convergence. A sequence field provides support for both in-order 1229 payload delivery and (supported by a fragmentation control method) a 1230 PSN fragmentation service within the PSN Convergence Layer. Ethernet 1231 pads all frames to a minimum size of 64 bytes. The MPLS header does 1232 not include a length indicator. Therefore to allow PWE3 to be carried 1233 in MPLS to correctly pass over an Ethernet data-link, a length 1234 correction field is needed in the control word. Where the design of 1235 the control word would alias an IP packet, a PWE3 Payload Type 1236 Identifier (PWE3 PID) should be interposed between the PW label and 1237 the control word (see 5.4.4). As with an IP PSN, where appropriate, 1238 timing is provided by RTP [RFC3550]. 1240 In some networks it may be necessary to carry PWE3 over MPLS over IP. 1241 In these circumstances, the PW is encapsulated for carriage over MPLS 1242 as described in this section, and then a method of carrying MPLS over 1243 an IP PSN (such as GRE [RFC2784], [RFC2890]) is applied to the 1244 resultant PW-PDU. 1246 5.4.3. PW over MPLS Generic Control Word 1248 To allow accurate packet inspection in an MPLS PSN, and/or to operate 1249 correctly over MPLS PSNs that have deployed equal-cost multiple-path 1250 load-balancing (ECMP), a PW packet MUST NOT alias an IP packet. IP 1251 packets are carried in MPLS label stacks without any protocol 1252 identifier. Historic values of the IP version number [RFC791] 1253 [RFC1883] are therefore used to distinguish between IP and non-IP 1254 MPLS payloads. 1256 To disambiguate the PW from an IP flow the PW SHOULD employ either 1257 the generic PW control word shown in Figure 12, or a PWE3 PID. Note 1258 that an MPLS payload with bits 0..3 = 4 is an IPv4 packet and an MPLS 1259 payload with bits 0..3 = 6 is an IPv6 packet. 1261 0 1 2 3 1262 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 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 |0 0 0 0| Specified by PW Encapsulation | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 Figure 12: Generic PW Control Word 1269 The PW set-up protocol determines whether a PW uses a control word. 1270 When a control word is used, it SHOULD have the following preferred 1271 form: 1273 0 1 2 3 1274 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 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 |0 0 0 0| Flags |FRG| Length | Sequence Number | 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 Figure 13: MPLS Preferred Control Word 1281 The meaning of the fields of the MPLS Preferred Control Word (Figure 1282 13) is as follows: 1284 Flags (bits 4 to 7): 1285 These bits are available for per payload signaling. Their 1286 definition is encapsulation specific. 1288 FRG (bits 8 and 9): 1289 These bits are used when fragmenting a PW payload. Their use 1290 is defined in [FRAG]. When the PW is of a type that will 1291 never need payload fragmentation, these bits may be used as 1292 general purpose flags. 1294 Length (bits 10 to 15): 1295 The length field is used to determine the size of a PW 1296 payload that might have been padded to the minimum Ethernet 1297 MAC frame size during its transit across the PSN. If the 1298 MPLS payload (defined as the CW + the PW payload + any 1299 additional PW headers is less than 46 bytes, the length MUST 1300 be set to the length of the MPLS payload. If the MPLS 1301 payload is between 46 bytes and 63 bytes the implementation 1302 MAY either set to the length to the length of the MPLS 1303 payload, or it MAY set it to 0. If the length of the MPLS 1304 payload is greater than 63 bytes the length MUST be set to 0. 1306 Sequence number (Bit 16 to 31): 1307 If the sequence number is not used, it is set to zero by 1308 the sender and ignored by the receiver. Otherwise it 1309 specifies the sequence number of a packet. A circular list 1310 of sequence numbers is used. A sequence number takes a value 1311 from 1 to 65535 (2**16-1). If the payload is an OAM packet 1312 the sequence number MAY be used to mark the position in the 1313 sequence, in which case it has the same value as the last 1314 data PDU sent. The use of the sequence number is optional 1315 for OAM payloads. 1317 5.4.4. PWE3 Payload Type Identifier 1319 If technical considerations result in a PW control word that may 1320 alias an IP packet, the control word SHOULD be preceded by an PWE3 1321 payload type identifier (PWE3 PID). 1323 The PWE3 PID is defined as follows: 1325 0 1 2 3 1326 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 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 |0 0 0 1| reserved = 0 | PA | Protocol ID | 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 | As defined by PPP DLL protocol definition | 1331 | | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 Figure 14: PWE3 PID 1336 The meaning of the fields of the PWE3 PID (Figure 14) is as follows: 1338 PA protocol authority for the user plane or the control plane 1339 protocol ID 1340 0 = PPP DLL 1341 1-15 = Reserved 1343 Protocol ID 1344 Protocol ID following the format defined by the protocol 1345 authority identified in PA. 1347 Bits 4 to 11 inclusive are reserved for future use and must be zero. 1349 6. PW Demultiplexer Layer and PSN Requirements 1351 PWE3 places three service requirements on the protocol layers used to 1352 carry it across the PSN: 1354 o Multiplexing 1355 o Fragmentation 1356 o Length and Delivery 1358 6.1 Multiplexing 1360 The purpose of the PW Demultiplexer Layer is to allow multiple PWs to 1361 be carried in a single tunnel. This minimizes complexity and 1362 conserves resources. 1364 Some types of native service are capable of grouping multiple 1365 circuits into a "trunk", e.g. multiple ATM VCs in a VP, multiple 1366 Ethernet VLANs on a physical media, or multiple DS0 services within a 1367 T1 or E1. A PW MAY interconnect two end-trunks. That trunk would 1368 have a single multiplexing identifier. 1370 When a MPLS label is used as a PW Demultiplexer setting of the TTL 1371 value [RFC3032] in the PW label is application specific, however in a 1372 strict point to point application the TTL SHOULD be set to 2. 1374 6.2 Fragmentation 1376 If the PSN provides a fragmentation and reassembly service of 1377 adequate performance, it MAY be used to obtain an effective MTU that 1378 is large enough to transport the PW PDUs. See Section 5.3 for a full 1379 discussion of the PW fragmentation issues. 1381 6.3 Length and Delivery 1383 PDU delivery to the egress PE is the function of the PSN Layer. 1385 If the underlying PSN does not provide all the information necessary 1386 to determine the length of a PW-PDU, the Encapsulation Layer MUST 1387 provide it. 1389 6.4 PW-PDU Validation 1391 It is a common practice to use an error detection mechanism such as a 1392 CRC or similar mechanism to assure end-to-end integrity of frames. 1393 The PW service-specific mechanisms MUST define whether the packet's 1394 checksum shall be preserved across the PW, or be removed from PE- 1395 bound PDUs and then be re-calculated for insertion in CE-bound data. 1397 The former approach saves work, while the latter saves bandwidth. For 1398 a given implementation the choice may be dictated by hardware 1399 restrictions, which may not allow the preservation of the checksum. 1401 For protocols such as ATM and FR, the scope of the checksum is 1402 restricted to a single link. This is because the circuit identifiers 1403 (e.g. FR DLCI or ATM VPI/VCI) have only local significance and are 1404 changed on each hop or span. If the circuit identifier (and thus 1405 checksum) were going to change as a part of the PW emulation, it 1406 would be more efficient to strip and re-calculate the checksum. 1408 The service specific document for each protocol MUST describe the 1409 validation scheme to be used. 1411 6.5 Congestion Considerations 1413 The PSN carrying the PW may be subject to congestion. The congestion 1414 characteristics will vary with the PSN type, the network architecture 1415 and configuration, and the loading of the PSN. 1417 Where the traffic carried over the PW is known to be TCP friendly 1418 (by, for example, packet inspection), packet discard in the PSN will 1419 trigger the necessary reduction in offered load, and no additional 1420 congestion avoidance action is necessary. 1422 If the PW is operating over a PSN that provides enhanced delivery, 1423 the PEs SHOULD monitor packet loss to ensure that the service that 1424 was requested is actually being delivered. If it is not, then the PE 1425 SHOULD assume that the PSN is providing a best-effort service, and 1426 SHOULD use the best-effort service congestion avoidance measures 1427 described below. 1429 If best-effort service is being used and the traffic is not known to 1430 be TCP friendly, the PEs SHOULD monitor packet loss to ensure that 1431 the packet loss rate is within acceptable parameters. Packet loss is 1432 considered acceptable if a TCP flow across the same network path and 1433 experiencing the same network conditions would achieve an average 1434 throughput, measured on a reasonable timescale, that is not less than 1435 the PW flow is achieving. This condition can be satisfied by 1436 implementing a rate-limiting measure in the NSP, or by shutting down 1437 one or more PWs. The choice of which approach to use depends upon 1438 the type of traffic being carried. Where congestion is avoided by 1439 shutting down a PW, a suitable mechanism MUST be provided to prevent 1440 it immediately returning to service, causing a series of congestion 1441 pulses. 1443 The comparison to TCP cannot be specified exactly, but is intended as 1444 an "order-of-magnitude" comparison in timescale and throughput. The 1445 timescale on which TCP throughput is measured is the round-trip time 1446 of the connection. In essence, this requirement states that it is not 1447 acceptable to deploy an application (using PWE3 or any other 1448 transport protocol) on the best-effort Internet which consumes 1449 bandwidth arbitrarily and does not compete fairly with TCP within an 1450 order of magnitude. One method of determining an acceptable PW 1451 bandwidth is described in [RFC3448]. 1453 7. Control Plane 1455 This section describes PWE3 control plane services. 1457 7.1 Set-up or Teardown of Pseudo-Wires 1459 A PW MUST be set up before an emulated service can be established, 1460 and MUST be torn down when an emulated service is no longer needed. 1462 Set up or teardown of a PW can be triggered by an operator command, 1463 from the management plane of a PE, by signaling (i.e., set-up or 1464 teardown) of an AC, e.g., an ATM SVC, or by an auto-discovery 1465 mechanism. 1467 During the set-up process, the PEs need to exchange some information 1468 (e.g. learn each other's capabilities). The tunnel signaling 1469 protocol MAY be extended to provide mechanisms to enable the PEs to 1470 exchange all necessary information on behalf of the PW. 1472 Manual configuration of PWs can be considered a special kind of 1473 signaling, and is allowed. 1475 7.2 Status Monitoring 1477 Some native services have mechanisms for status monitoring. For 1478 example, ATM supports OAM for this purpose. For such services, the 1479 corresponding emulated services MUST specify how to perform status 1480 monitoring. 1482 7.3 Notification of Pseudo-wire Status Changes 1484 7.3.1. Pseudo-wire Up/Down Notification 1486 If a native service REQUIRES bi-directional connectivity, the 1487 corresponding emulated service can only be signaled as being up when 1488 the associated PWs, and PSN tunnels if any, are functional in both 1489 directions. 1491 Because the two CEs of an emulated service are not adjacent, a 1492 failure may occur at a place such that one or both physical links 1493 between the CEs and PEs remain up. For example, in Figure 2, if the 1494 physical link between CE1 and PE1 fails, the physical link between 1495 CE2 and PE2 will not be affected and will remain up. Unless CE2 is 1496 notified about the remote failure, it will continue to send traffic 1497 over the emulated service to CE1. Such traffic will be discarded at 1498 PE1. Some native services have failure notification so that when the 1499 services fail, both CEs will be notified. For such native services, 1500 the corresponding PWE3 service MUST provide a failure notification 1501 mechanism. 1503 Similarly, if a native service has notification mechanisms so that 1504 when a network failure is fixed, all the affected services will 1505 change status from "Down" to "Up", the corresponding emulated service 1506 MUST provide a similar mechanism for doing so. 1508 These mechanisms may already be built into the tunneling protocol. 1509 For example, the L2TP control protocol [RFC2661] [L2TPv3] has this 1510 capability and LDP has the ability to withdraw the corresponding MPLS 1511 label. 1513 7.3.2. Misconnection and Payload Type Mismatch 1515 With PWE3, misconnection and payload type mismatch can occur. If a 1516 misconnection occurs it can breach the integrity of the system. If a 1517 payload mismatch occurs it can disrupt the customer network. In both 1518 instances, there are security and operational concerns. 1520 The services of the underlying tunneling mechanism, and its 1521 associated control protocol, can be used to mitigate this. As part 1522 of the PW set-up a PW-TYPE identifier is exchanged. This is then used 1523 by the forwarder and the NSP to verify the compatibility of the ACs. 1525 7.3.3. Packet Loss, Corruption, and Out-of-order Delivery 1527 A PW can incur packet loss, corruption, and out-of-order delivery on 1528 the PSN path between the PEs. This can impact the working condition 1529 of an emulated service. For some payload types, packet loss, 1530 corruption, and out-of-order delivery can be mapped to either a bit 1531 error burst, or loss of carrier on the PW. If a native service has 1532 some mechanism to deal with bit error, the corresponding PWE3 service 1533 should provide a similar mechanism. 1535 7.3.4. Other Status Notification 1537 A PWE3 approach MAY provide a mechanism for other status 1538 notification, if any are needed. 1540 7.3.5. Collective Status Notification 1542 Status of a group of emulated services may be affected identically by 1543 a single network incident. For example, when the physical link (or 1544 sub-network) between a CE and a PE fails, all the emulated services 1545 that go through that link (or sub-network) will fail. It is likely 1546 that there exists a group of emulated services that all terminate at 1547 a remote CE. There may also be multiple such CEs affected by the 1548 failure. Therefore, it is desirable that a single notification 1549 message be used to notify failure of the whole group of emulated 1550 services. 1552 A PWE3 approach MAY provide some mechanism for notifying status 1553 changes of a group of emulated circuits. One possible method is to 1554 associate each emulated service with a group ID when the PW for that 1555 emulated service is set up. Multiple emulated services can then be 1556 grouped by associating them with the same group ID. In status 1557 notification, that group ID can be used to refer all the emulated 1558 services in that group. The group ID mechanism should be a mechanism 1559 provided by the underlying tunnel signaling protocol. 1561 7.4 Keep-alive 1563 If a native service has a keep-alive mechanism, the corresponding 1564 emulated service MUST provide a mechanism to propagate this across 1565 the PW. An approach following the principle of minimum intervention 1566 would be to transparently transport keep-alive messages over the PW. 1567 However, to accurately reproduce the semantics of the native 1568 mechanism, some PWs MAY REQUIRE an alternative approach, such as 1569 piggy-backing on the PW signaling mechanism. 1571 7.5 Handling Control Messages of the Native Services 1573 Some native services use control messages for circuit maintenance. 1574 These control messages MAY be in-band, e.g. Ethernet flow control, 1575 ATM performance management, or TDM tone signaling, or they MAY be 1576 out-of-band, e.g. the signaling VC of an ATM VP, or TDM CCS 1577 signaling. 1579 From the principle of minimum intervention, it is desirable that the 1580 PEs participate as little as possible in the signaling and 1581 maintenance of the native services. This principle SHOULD NOT, 1582 however, override the need to satisfactorily emulate the native 1583 service. 1585 If control messages are passed through, it may be desirable to send 1586 them using either a higher priority or a reliable channel provided by 1587 the PW Demultiplexer layer. See PWE3 Channel Types. 1589 8. Management and Monitoring 1591 This section describes the management and monitoring architecture for 1592 PWE3. 1594 8.1 Status and Statistics 1596 The PE should report the status of the interface and tabulate 1597 statistics that help monitor the state of the network, and to help 1598 with measurement of service level agreements (SLAs). Typical counters 1599 include: 1601 o Counts of PW-PDUs sent and received, with and without errors. 1602 o Counts of sequenced PW-PDUs lost. 1603 o Counts of service PDUs sent and received over the PSN, with 1604 and without errors (non-TDM). 1605 o Service-specific interface counts. 1607 o One way delay and delay variation. 1609 These counters would be contained in a PW-specific MIB, and they 1610 should not replicate existing MIB counters. 1612 8.2 PW SNMP MIB Architecture 1614 This section describes the general architecture for SNMP MIBs used to 1615 manage PW services and the underlying PSN. The intent here is to 1616 provide a clear picture of how all of the pertinent MIBs fit together 1617 to form a cohesive management framework for deploying PWE3 services. 1619 8.2.1. MIB Layering 1621 The SNMP MIBs created for PWE3 should fit the architecture shown in 1622 Figure 15. 1624 +-----------+ +-----------+ +-----------+ 1625 Service | CEM | | Ethernet | | ATM | 1626 Layer |Service MIB| |Service MIB| ... |Service MIB| 1627 +-----------+ +-----------+ +-----------+ 1628 \ | / 1629 \ | / 1630 - - - - - - - - - - - - \ - - - | - - - - / - - - - - - - 1631 \ | / 1632 +-------------------------------------------+ 1633 Generic PW | Generic PW MIBs | 1634 Layer +-------------------------------------------+ 1635 / \ 1636 - - - - - - - - - - - - / - - - - - - - - \ - - - - - - - 1637 / \ 1638 / \ 1639 +-----------+ +-----------+ 1640 PSN VC |L2TP VC MIB| |MPLS VC MIB| 1641 Layer +-----------+ +-----------+ 1642 | | 1643 - - - - - - - - - | - - - - - - - - - - - - - - - | - - - 1644 | | 1645 +-----------+ +-----------+ 1646 PSN |L2TP MIB(s)| |MPLS MIB(s)| 1647 Layer +-----------+ +-----------+ 1649 Figure 15: Relationship of SNMP MIBs 1651 Figure 16 shows an example for a SONET PW carried over MPLS. 1653 +-----------------+ 1654 | SONET MIB | RFC2558 1655 +-----------------+ 1656 | 1657 +-----------------+ 1658 Service |SONET Service MIB| pw-cem-mib 1659 Layer +-----------------+ 1660 - - - - - - - - - - | - - - - - - - - - - - - - - - 1661 +-----------------+ 1662 Generic PW | Generic PW MIBS | pw-tc-mib 1663 Layer +-----------------+ pw-mib 1664 - - - - - - - - - - | - - - - - - - - - - - - - - - 1665 +-----------------+ 1666 PSN VC | MPLS VC MIBS | pw-mpls-mib 1667 Layer +-----------------+ 1668 - - - - - - - - - - | - - - - - - - - - - - - - - - 1669 +-----------------+ 1670 PSN | MPLS MIBs | mpls-te-mib 1671 Layer +-----------------+ mpls-lsr-mib 1673 Figure 16: Service-specific Example for MIBs 1675 Note that there is a separate MIB for each emulated service as well 1676 as one for each underlying PSN. These MIBs MAY be used in various 1677 combinations as needed. 1679 8.2.2. Service Layer MIBs 1681 The first layer is referred to as the Service Layer. It contains 1682 MIBs for PWE3 services such as Ethernet, ATM, circuits and Frame 1683 Relay. This layer contains those corresponding MIBs used to mate or 1684 adapt those emulated services to the underlying services. This 1685 working group should not produce any MIBs for managing the general 1686 service; rather, it should produce just those MIBs that are used to 1687 interface or adapt the emulated service onto the PWE3 management 1688 framework. For example, the standard SONET MIB [RFC2558] is designed 1689 and maintained by another working group. Also, the SONET MIB is 1690 designed to manage the native service without PW emulation. Since 1691 the PWE3 working group is chartered to produce the corresponding 1692 adaptation MIB, in this case, it would produce the PW-CEM-MIB 1693 [PWMPLSMIB] that would be used to adapt SONET services to the 1694 underlying PSN that carries the PWE3 service. 1696 8.2.3. Generic PW MIBs 1698 The second layer is referred to as the Generic PW Layer. This layer 1699 is composed of two MIBs: the PWE-TC-MIB [PWTCMIB] and the PWE-MIB 1700 [PWMIB]. These MIBs are responsible for providing general PWE3 1701 counters and service models used for monitoring and configuration of 1702 PWE3 services over any supported PSN service. That is, this MIB 1703 provides a general model of PWE3 abstraction for management purposes. 1704 This MIB is used to interconnect the Service Layer MIBs to the PSN VC 1705 Layer MIBs. The latter will be described in the next section. This 1706 layer also provides the PW-TC-MIB [PWTCMIB]. This MIB contains 1707 common SMI textual conventions [RFC1902] that MAY be used by any PW 1708 MIB. 1710 8.2.4. PSN VC Layer MIBs 1712 The third layer in the PWE3 management architecture is referred to as 1713 the PSN VC layer. This layer is comprised of MIBs that are 1714 specifically designed to interface general PWE3 services (VCs) onto 1715 those underlying PSN services. In general this means that the MIB 1716 provides a means with which an operator can map the PW service onto 1717 the native PSN service. For example, in the case of MPLS, it is 1718 required that the general VC service be layered onto MPLS LSPs or 1719 Traffic Engineered (TE) Tunnels [RFC3031]. In this case, the PW- 1720 MPLS-MIB [PWMPLSMIB] was created to adapt the general PWE3 circuit 1721 services onto MPLS. Like the Service Layer described above the PWE3 1722 working group should produce these MIBs. 1724 8.2.5. PSN Layer MIBs 1726 The fourth and final layer in the PWE3 management architecture is 1727 referred to as the PSN layer. This layer is comprised of those MIBs 1728 that control the PSN service-specific services. For example, in the 1729 case of the MPLS [RFC3031] PSN service, the MPLS-LSR-MIB [LSRMIB] and 1730 the MPLS-TE-MIB [TEMIB] are used to interface the general PWE3 VC 1731 services onto native MPLS LSPs and/or TE tunnels to carry the 1732 emulated services. In addition, the MPLS-LDP-MIB [LDPMIB] MAY be 1733 used to reveal the MPLS labels that are distributed over the MPLS PSN 1734 in order to maintain the PW service. The MIBs in this layer are 1735 produced by other working groups that design and specify the native 1736 PSN services. These MIBs should contain the appropriate mechanisms 1737 for monitoring and configuring the PSN service such that the emulated 1738 PWE3 service will function correctly. 1740 8.3 Connection Verification and Traceroute 1742 A connection verification mechanism should be supported by PWs. 1743 Connection verification as well as other alarm mechanisms can alert 1744 the operator that a PW has lost its remote connection. The opaque 1745 nature of a PW means that it is not possible to specify a generic 1746 connection verification or traceroute mechanism that passes this 1747 status to the CEs over the PW. If connection verification status of 1748 the PW is needed by the CE, it MUST be mapped to the native 1749 connection status method. 1751 For troubleshooting purposes, it is sometimes desirable to know the 1752 exact functional path of a PW between PEs. This is provided by the 1753 traceroute service of the underlying PSN. The opaque nature of the 1754 PW means that this traceroute information is only available within 1755 the provider network, e.g., at the PEs. 1757 9. IANA considerations 1759 Sections 5.4.3 and 5.4.4 discuss the issue of aliasing between PW and 1760 IP packets on an MPLS PSN. This aliasing is resolved by using two 1761 historic IP version numbers to indicate that the payload is an MPLS 1762 preferred control word, or a PWE3 PID. The IP version number 1763 registry needs to be updated to allocate IP version number 0 1764 (currently reserved) to MPLS preferred control word, and IP version 1765 number 1 (currently unassigned) to PWE3 PID. 1767 10. Security Considerations 1769 PWE3 provides no means of protecting the integrity, confidentiality 1770 or delivery of the native data units. The use of PWE3 can therefore 1771 expose a particular environment to additional security threats. 1772 Assumptions that might be appropriate when all communicating systems 1773 are interconnected via a point to point or circuit-switched network 1774 may no longer hold when they are interconnected using an emulated 1775 wire carried over some types of PSN. It is outside the scope of this 1776 specification, to fully analyze and review the risks of PWE3, 1777 particularly as these risks will depend on the PSN. An example should 1778 make the concern clear. A number of IETF standards employ relatively 1779 weak security mechanisms when communicating nodes are expected to be 1780 connected to the same local area network. The Virtual Router 1781 Redundancy Protocol [RFC2338] is one instance. The relatively weak 1782 security mechanisms represent a greater vulnerability in an emulated 1783 Ethernet connected via a PW. 1785 Exploitation of vulnerabilities from within the PSN may be directed 1786 to the PW Tunnel end-point so that PW Demultiplexer and PSN tunnel 1787 services are disrupted. Controlling PSN access to the PW Tunnel 1788 end-point is one way to protect against this. By restricting PW 1789 Tunnel end-point access to legitimate remote PE sources of traffic, 1790 the PE may reject traffic that would interfere with the PW 1791 Demultiplexing and PSN tunnel services. 1793 Protection mechanisms MUST also address the spoofing of tunneled PW 1794 data. The validation of traffic addressed to the PW Demultiplexer 1795 end-point is paramount in ensuring integrity of PW encapsulation. 1796 Security protocols such as IPSec [RFC2401] MAY be used by the PW 1797 Demultiplexer Layer in order to maintain the integrity of the PW by 1798 authenticating data between the PW Demultiplexer End-points. 1800 IPSec MAY provide authentication, integrity, non-repudiation, and 1801 confidentiality of data transferred between two PEs. It cannot 1802 provide the equivalent services to the native service. 1804 Based on the type of data being transferred, the PW MAY indicate to 1805 the PW Demultiplexer Layer that enhanced security services are 1806 required. The PW Demultiplexer Layer MAY define multiple protection 1807 profiles based on the requirements of the PW emulated service. CE- 1808 to-CE signaling and control events emulated by the PW and some data 1809 types may require additional protection mechanisms. Alternatively, 1810 the PW Demultiplexer Layer may use peer authentication for every PSN 1811 packet to prevent spoofed native data units from being sent to the 1812 destination CE. 1814 The unlimited transformation capability of the NSP may be perceived 1815 as a security risk. In practise the type of operation that the NSP 1816 may perform will be limited to those that have been implemented in 1817 the data path. The access controls that are in place in the PE to 1818 protect and validate its configuration will be sufficient to ensure 1819 that the NSP performs as expected. 1821 Acknowledgments 1823 We thank: Sasha Vainshtein for his work on Native Service Processing 1824 and advice on bit-stream over PW services. Thomas K. Johnson for his 1825 work on the background and motivation for PWs. 1827 We also thank: Ron Bonica, Stephen Casner, Durai Chinnaiah, Jayakumar 1828 Jayakumar, Ghassem Koleyni, Danny McPherson, Eric Rosen, John 1829 Rutemiller, Scott Wainner and David Zelig for their comments and 1830 contributions. 1832 Normative References 1834 Internet-drafts are works in progress available from 1835 1837 [FRAG] Malis and Townsley, "PWE3 Fragmentation and 1838 Reassembly", , 1839 work in progress, June 2003. 1841 [L2TPv3] Layer Two Tunneling Protocol (Version 3)'L2TPv3', J Lau, 1842 et. al. , work 1843 in progress, June 2003. 1845 [RFC791] RFC-791: DARPA Internet Program, Protocol Specification, 1846 ISI, September 1981. 1848 [RFC1883] RFC-1883: Internet Protocol, Version 6 (IPv6), 1849 S. Deering, et al, December 1995 1851 [RFC1902] RFC-1902: Structure of Management Information for 1852 Version 2 of the Simple Network Management Protocol 1853 (SNMPv2), Case et al, January 1996. 1855 [RFC2119] RFC-2119, BCP-14: Key words for use in RFCs to Indicate 1856 Requirement Levels, S. Bradner. 1858 [RFC2401] RFC-2401: Security Architecture for the Internet 1859 Protocol. S. Kent, R. Atkinson. 1861 [RFC2474] RFC-2474: Definition of the Differentiated Services 1862 Field (DS Field) in the IPv4 and IPv6 Headers, 1863 K. Nichols, et. al. 1865 [RFC2558] K. Tesink, "Definitions of Managed Objects for the 1866 SONET/SDH Interface Type", RFC2558, March 1999. 1868 [RFC2661] RFC-2661: Layer Two Tunneling Protocol "L2TP". 1869 W. Townsley, et. al. 1871 [RFC2784] RFC-2784: Generic Routing Encapsulation (GRE). 1872 D. Farinacci et al. 1874 [RFC2890] RFC-2890: Key and Sequence Number Extensions to GRE. 1875 G. Dommety. 1877 [RFC3031] RFC3031: Multiprotocol Label Switching Architecture, 1878 E. Rosen, January 2001. 1880 [RFC3032] RFC3032: MPLS Label Stack Encoding, E. Rosen, 1881 January 2001. 1883 [RFC3550] RFC-3550: RTP: A Transport Protocol for Real-Time 1884 Applications. H. Schulzrinne et. al. 1886 Informative References 1888 Internet-drafts are works in progress available from 1889 1891 [DVB] EN 300 744 Digital Video Broadcasting (DVB); Framing 1892 structure, channel coding and modulation for digital 1893 terrestrial television (DVB-T), European 1894 Telecommunications Standards Institute (ETSI) 1896 [LDPMIB] Cucchiara, J., Sjostrand, H., and Luciani, J., 1897 "Definitions of Managed Objects for the Multiprotocol 1898 Label Switching, Label Distribution Protocol (LDP)", 1899 , work in progress, 1900 June 2003. 1902 [LSRMIB] Srinivasan et al, "MPLS Label Switch Router Management 1903 Information Base Using SMIv2", 1904 , work in progress, 1905 June 2003. 1907 [PPPoL2TP] PPP Tunneling Using Layer Two Tunneling Protocol, 1908 J Lau et al. , 1909 work in progress, June 2002. 1911 [PWMIB] Zelig et al, "Pseudo Wire (PW) Management Information 1912 Base Using SMIv2", , 1913 work in progress, June 2003. 1915 [PWTCMIB] Nadeau et al, "Definitions for Textual Conventions and 1916 OBJECT-IDENTITIES for Pseudo-Wires Management" 1917 , work in progress, 1918 June 2003. 1920 [PWMPLSMIB] Danenberg et al, "SONET/SDH Circuit Emulation Service 1921 Over MPLS (CEM) Management Information Base Using 1922 SMIv2", , work in 1923 progress, October 2002. 1925 [RFC1191] RFC-1191: Path MTU discovery. J.C. Mogul, S.E. Deering. 1927 [RFC1958] RFC-1958: Architectural Principles of the Internet, 1928 B. Carpenter et al. 1930 [RFC1981] RFC-1981: Path MTU Discovery for IP version 6. J. McCann, 1931 S. Deering, J. Mogul. 1933 [RFC2022] RFC-2022: Support for Multicast over UNI 3.0/3.1 based 1934 ATM Networks, G. Armitage. 1936 [RFC2338] RFC-2338: Virtual Router Redundancy Protocol, 1937 S. Knight, M. Shand et. al. 1939 [RFC3022] RFC-3022: Traditional IP Network Address Translator 1940 (Traditional NAT). P Srisuresh et al. 1942 [RFC3448] RFC3448: TCP Friendly Rate Control (TFRC): Protocol 1943 Specification, M. Handley et al. January 2003. 1945 [TEMIB] Srinivasan et al, "Traffic Engineering Management 1946 Information Base Using SMIv2", 1947 , work in progress, 1948 June 2003. 1950 [XIAO] Xiao et al, "Requirements for Pseudo-Wire Emulation 1951 Edge-to-Edge (PWE3)", 1952 (draft-ietf-pwe3-requirements-06.txt), X Xiao et al. 1953 work in progress, June 2002. 1955 Editors' Addresses 1957 Stewart Bryant 1958 Cisco Systems, 1959 250, Longwater, 1960 Green Park, 1961 Reading, RG2 6GB, 1962 United Kingdom. Email: stbryant@cisco.com 1964 Prayson Pate 1965 Overture Networks, Inc. 1966 507 Airport Boulevard 1967 Morrisville, NC, USA 27560 Email: prayson.pate@overturenetworks.com 1968 Full copyright statement 1970 Copyright (C) The Internet Society (2002). 1971 All Rights Reserved. 1973 This document and translations of it may be copied and 1974 furnished to others, and derivative works that comment 1975 on or otherwise explain it or assist in its implementation 1976 may be prepared, copied, published and distributed, in 1977 whole or in part, without restriction of any kind, 1978 provided that the above copyright notice and this 1979 paragraph are included on all such copies and derivative works. 1980 However, this document itself may not be modified in any way, 1981 such as by removing the copyright notice or references to the 1982 Internet Society or other Internet organizations, except as 1983 needed for the purpose of developing Internet standards in 1984 which case the procedures for copyrights defined in the 1985 Internet Standards process must be followed, or as required to 1986 translate it into languages other than English. 1988 The limited permissions granted above are perpetual and will 1989 not be revoked by the Internet Society or its successors or assigns. 1991 This document and the information contained herein is provided 1992 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1993 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1994 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 1995 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 1996 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1997 FOR A PARTICULAR PURPOSE.