idnits 2.17.1 draft-ietf-pwe3-protocol-layer-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 33 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 181 has weird spacing: '...Edge to att...' == Line 454 has weird spacing: '...ing PWs as pa...' == Line 455 has weird spacing: '...his can be ac...' == Line 457 has weird spacing: '...nt. In that ...' == Line 458 has weird spacing: '...W would need ...' == (1 more instance...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2002) is 8010 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: 'RFC-1958' is mentioned on line 393, but not defined == Missing Reference: 'VPLS' is mentioned on line 455, but not defined == Missing Reference: 'Figure 3' is mentioned on line 995, but not defined == Unused Reference: 'RFC1958' is defined on line 1381, but no explicit reference was found in the text == Unused Reference: 'RFC1981' is defined on line 1384, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BGPAUTO' -- Possible downref: Non-RFC (?) normative reference: ref. 'ETSI' -- Possible downref: Non-RFC (?) normative reference: ref. 'PPPoL2TP' ** Downref: Normative reference to an Informational RFC: RFC 1958 ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 3022 ** Obsolete normative reference: RFC 1889 (ref. 'RTP') (Obsoleted by RFC 3550) Summary: 8 errors (**), 0 flaws (~~), 13 warnings (==), 5 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 Lloyd Wood 3 Document: Mark Townsley 4 Expires: November 2002 Cisco Systems Ltd 6 Danny McPherson 7 TCB 9 May 2002 11 Protocol Layering in PWE3 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 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt The list of 30 Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This draft proposes a unified protocol layering approach for pseudo- 36 wire emulation edge-to-edge (PWE3). It adopts the principle that PWE3 37 should be a single transport type operating over a common packet- 38 switched network (PSN) service model using, wherever possible, 39 existing IETF protocols. The draft defines the protocol layering 40 model for pseudo-wires, guidelines for the design of a specific 41 encapsulation type, and the service requirements on the underlying 42 PSN tunneling mechanism. 44 Table of Contents 46 1. Introduction............................................. 3 48 2. Terminology.............................................. 3 50 3. Protocol Layering Model.................................. 5 51 3.1 Protocol Layers...................................... 5 52 3.2 Domain of PWE3....................................... 7 53 3.3 Payload Types........................................ 7 55 4. Architecture of Pseudo-wires............................. 10 56 4.1 Network Reference Model.............................. 10 57 4.2 PWE3 Pre-processing.................................. 11 58 4.3 Maintenance Reference Model.......................... 15 59 4.4 Protocol Stack Reference Model....................... 15 60 4.5 Pre-processing Extension to Protocol Stack Reference 61 Model................................................ 16 63 5. PW Encapsulation......................................... 17 64 5.1 Payload Convergence Layer............................ 18 65 5.2 Payload-independent PW Encapsulation Layers.......... 20 66 5.3 Fragmentation........................................ 22 67 5.4 Instantiation of the Protocol Layers................. 23 69 6. PW Demultiplexer Layer and PSN Requirements.............. 25 70 6.1 Multiplexing......................................... 26 71 6.2 Fragmentation........................................ 26 72 6.3 Length and Delivery.................................. 26 74 7. Control Plane............................................ 26 75 7.1 Set-up or Teardown of Pseudo-Wires................... 26 76 7.2 Status Monitoring.................................... 27 77 7.3 Notification of Pseudo-wire Status Changes........... 27 78 7.4 Keep-alive........................................... 29 79 7.5 Handling Control Messages of the Native Services..... 29 81 8. IANA considerations...................................... 29 83 9. Security Considerations.................................. 29 84 9.1 PW Tunnel End-Point and PW Demultiplexer Security.... 30 85 9.2 Validation of PW Encapsulation....................... 30 86 9.3 End-to-End Security.................................. 30 88 1. Introduction 90 This document presents a unified protocol layering approach for 91 pseudo-wire emulation edge-to-edge (PWE3). Wherever possible, 92 existing IETF protocols [RFC-1958] are used. PWE3 is intended to 93 provide only the necessary and sufficient functionality to emulate 94 the wire with the required degree of faithfulness for the given 95 service definition. A pseudo-wire (PW) may be point-to-point, 96 multipoint-to-point or point-to-multipoint. Any required switching 97 functionality, is the responsibility of a forwarder function. Any 98 translation or other operation needing a knowledge of the payload 99 semantics is carried out by native service processing (NSP) elements. 100 The functional definition of any forwarder of NSP elements is outside 101 the scope of PWE3. 103 This document defines the protocol layering model for pseudo-wires 104 (PW), guidelines for the design of a pseudowire encapsulations, and 105 the service requirements on the underlying PSN tunneling mechanism. 107 2. Terminology 109 This document uses the following definition of terms. These terms 110 are illustrated in context in Figure 2. 112 Attachment Circuit The circuit or virtual circuit attaching 113 (AC) a CE to a PE. 115 CE-bound The traffic direction where PW-PDUs are 116 received on a PW via the PSN, processed 117 and then sent to the destination CE. 119 CE Signaling Messages sent and received by the CEs 120 control plane. It may be desirable or 121 even necessary for the PE to participate 122 in or monitor this signaling in order 123 to effectively emulate the service. 125 Customer Edge (CE) A device where one end of a service 126 originates and/or terminates. The CE is not 127 aware that it is using an emulated service 128 rather than a native service. 130 Forwarder A PE sub-system that determines which PW 131 a payload received on an AC must be sent over. 133 Fragmentation When a packet MTU is greater than that 134 supported by the PSN, either the PSN 135 packet or the payload is fragmented into 136 smaller data units which are transmitted 137 separately and reassembled elsewhere in the 138 network. 140 Inter-working Interactions between networks, between end 141 systems, or between parts thereof, with the 142 aim of providing a functional entity 143 capable of supporting an end-to-end 144 communication. 146 Inter-working A function that facilitates inter-working 147 Function (IWF) between two dissimilar services. NSP may 148 perform the IWF function. 150 Native Service Processing of the data received by the PE 151 Processing (NSP) from the CE before presentation to the PW 152 for transmission across the core. 154 Packet Switched A network using IP or MPLS as the mechanism 155 Network (PSN) for packet forwarding. 157 Protocol Data The unit of data output to, or received 158 Unit (PDU) from, the network by a protocol layer. 160 Provider Edge (PE) A device that provides PWE3 to a CE. 162 PE-bound The traffic direction where information 163 from a CE is adapted to a PW, and PW-PDUs 164 are sent into the PSN. 166 PE/PW Maintenance Used by the PEs to set up, maintain and 167 tear down the PW. It may be coupled with 168 CE Signaling in order to effectively manage 169 the PW. 171 Pseudo Wire (PW) A mechanism that carries the essential 172 elements of an emulated service from one PE 173 to one or more other PEs over a PSN. 175 PW End Service The interface between a PE and a CE. This 176 (PWES) can be a physical interface like a T1 or 177 Ethernet, or a virtual interface like a VC 178 or VLAN. 180 Pseudo Wire A mechanism that emulates the essential 181 Emulation Edge to attributes of service (such as a T1 leased 182 Edge (PWE3) line or frame relay) over a PSN. 184 Pseudo Wire PDU A PDU sent on the PW that contains all of 185 (PW-PDU) the data and control information necessary 186 to emulate the desired service. 188 PSN Tunnel A tunnel across a PSN inside which one or 189 more PWs can be carried. 191 PSN Tunnel Used to set up, maintain and tear down the 192 Signaling underlying PSN tunnel. 194 PW Demultiplexer Data-plane method of identifying PW terminating 195 at a PE. 197 Tunnel A method of transparently carrying information 198 over a network. 200 3. Protocol Layering Model 202 The PWE3 protocol-layering model is intended to minimise the 203 differences between PWs operating over different PSN types. The 204 design of the protocol-layering model thus has the goals of making 205 each PW definition independent of the underlying PSN, and maximizing 206 the reuse of IETF protocol definitions and their implementations. 208 3.1 Protocol Layers 210 The logical protocol-layering model required to support a PW is shown 211 in Figure 1. 213 +---------------------------+ 214 | Payload | 215 +---------------------------+ 216 | Encapsulation | <==== May be empty 217 +---------------------------+ 218 | PW Demultiplexer | 219 +---------------------------+ 220 | PSN Convergence | <==== May be empty 221 +---------------------------+ 222 | PSN | 223 +---------------------------+ 224 | MAC/Data-link | 225 +---------------------------+ 226 | Physical | 227 +---------------------------+ 229 Figure 1: Logical Protocol Layering Model 231 The payload is transported over the Encapsulation Layer. The 232 Encapsulation Layer carries any information, not already present 233 within the payload itself, that is needed by the PW CE-bound PE 234 interface to send the payload to the CE via the physical interface. 235 If no information is needed beyond that in the payload itself, this 236 layer is empty. 238 If needed, this layer also provides support for real-time processing, 239 and also sequencing, if needed. 241 The PW Demultiplexer Layer provides the ability to deliver multiple 242 PWs over a single PSN tunnel. The PW demultiplexer value used to 243 identify the PW in the data-plane may be unique per PE, but this is 244 not a PWE3 requirement. It must however be unique per tunnel. If it 245 is necessary to identify a particular tunnel, then that is the 246 responsibility of the PSN layer. 248 The PSN Convergence Layer provides the enhancements needed to make 249 the PSN conform to the assumed PSN service requirement. This layer 250 therefore provides a consistent interface to the PW, making the PW 251 independent of the PSN type. If the PSN already meets the service 252 requirements, this layer is empty. 254 The PSN header, MAC/Data-link and Physical Layer definitions are 255 outside the scope of this document. The PSN can be any PSN type 256 defined by the IETF. These are currently IPv4, IPv6 and MPLS. 258 3.2 Domain of PWE3 260 PWE3 defines the Encapsulation Layer, the method of carrying various 261 payload types, and the interface to the PW Demultiplexer Layer. It 262 is expected that the other layers will be provided by tunneling 263 methods such as L2TP or MPLS over the PSN. 265 3.3 Payload Types 267 The payload is classified into the following generic types of native 268 data unit: 270 o Bit-stream 271 o Structured bit-stream 272 o Cell 273 o Packet 275 Within these generic types there are specific service types. For 276 example: 278 Generic Payload Type PW Service 279 -------------------- ---------- 280 Bit-stream SONET, TDM (e.g. DS1, DS3, E1). 282 Structured bit-stream SONET, TDM. 284 Cell ATM. 286 Packet Ethernet (all types), HDLC, 287 frame-relay, ATM AAL5 PDU. 289 3.3.1. Bit-stream 291 A bit-stream payload is created by capturing, transporting and 292 replaying the bit pattern on the emulated wire, without taking 293 advantage of any structure that, on inspection, may be visible within 294 the relayed traffic. The Encapsulation Layer submits an identical 295 number of bits for transport in each PW-PDU. 297 This service will require sequencing and real-time support. 299 3.3.2. Structured bit-stream 301 A bit-stream payload is created by using some knowledge of the 302 underlying structure of the bit-stream to capture, transport and 303 replay the bit pattern on the emulated wire. 305 Two important points distinguish structured and unstructured bit- 306 streams: 308 o Some part of the original (unstructured) bit stream are 309 stripped by, for example, the PSN-bound direction of the 310 NSP block. For example, in Structured SONET the section 311 and line overhead (and, possibly, more) may be stripped. 313 o The PW must preserve the structure across the PSN so that 314 the CE-bound NSP block can insert it correctly into the 315 reconstructed unstructured bit stream. 317 The Encapsulation Layer may also perform silence/idle suppression or 318 similar compression on a structured bit stream. 320 Structured bit streams are distinguished from cells in that the 321 structures may be too long to be carried in a single packet (i.e. 322 structured SONET). Note that "short" structures are 323 indistinguishable from cells and may benefit from the use of cell 324 encapsulations. 326 This service will require sequencing and real-time support. 328 3.3.3. Cell Payload 330 A cell payload is created by capturing, transporting and replaying 331 groups of bits presented on the wire in a fixed-size format. The 332 delineation of the group of bits that comprise the cell is specific 333 to the encapsulation type. Two common examples of cell payloads are 334 53-octet cells carrying ATM AAL2, and the larger 188-octet MPEG 335 Transport Stream packets [ETSI]. 337 To reduce per-PSN packet overhead, multiple cells may be concatenated 338 into a single payload. The Encapsulation Layer may consider the 339 payload complete on the expiry of a timer, or after a fixed number of 340 cells have been received. The benefit of concatenating multiple PDUs 341 should be weighed against the resulting increase in jitter and the 342 larger penalty incurred by packet loss. In some cases, it may be 343 appropriate for the Encapsulation Layer to perform a silence 344 suppression or a similar compression. 346 The generic cell payload service will normally need sequence number 347 support, and may also need real-time support. The generic cell 348 payload service would not normally require fragmentation. 350 The Encapsulation Layer may apply some form of compression to some of 351 these sub-types. 353 In some instances, the cells to be incorporated in the payload may be 354 selected by filtering them from the stream of cells presented on the 355 wire. For example, an ATM PWE3 service may select cells based on 356 their VCI or VPI fields. This is an NSP function, and the selection 357 would therefore be made before the packet was presented to the PW 358 Encapsulation Layer. 360 3.3.4. Packet Payload 362 A packet payload is a variable-size data unit presented to the PE on 363 the AC. A packet payload may be large compared to the PSN MTU. The 364 delineation of the packet boundaries is encapsulation-specific. HDLC 365 or Ethernet PDUs can be considered as examples of packet payloads. 366 Typically a packet will be stripped of transmission overhead such as 367 HDLC flags and stuffing bits before transmission over the PW. 369 A packet payload would normally be relayed across the PW as a single 370 unit. However, there will be cases where the combined size of the 371 packet payload and its associated PWE3 and PSN headers exceeds the 372 PSN path MTU. In this case some fragmentation methodology needs to 373 be applied. This is likely to be the case when a user is providing 374 the service and attaching to the service provider via an Ethernet, or 375 where nested pseudo-wires are involved. Fragmentation is discussed in 376 more detail in Section 5. 378 A packet payload may need sequencing and real-time support. 380 In some situations, the packet payload may be selected from the 381 packets presented on the emulated wire on the basis of some sub- 382 multiplexing technique. For example, one or more frame-relay PDUs 383 may be selected for transport over a particular pseudo-wire based on 384 the frame-relay Data-Link Connection Identifier (DLCI), or, in the 385 case of Ethernet payloads, on the basis of the VLAN identifier. This 386 is an NSP function, and this selection would therefore be made before 387 the packet was presented to the PW Encapsulation Layer. 389 3.3.5. Principle of Minimum Intervention 391 To minimise the scope of information, and to improve the efficiency 392 of data flow through the Encapsulation Layer, the payload should be 393 transported as received with as few modifications as possible [RFC- 394 1958]. 396 This minimum intervention approach decouples payload development from 397 PW development and requires fewer translations at the NSP in a system 398 with similar CE interfaces at each end. It also prevents any 399 unwanted side-effects due to subtle mis-representation of the payload 400 in the intermediate format. 402 An intervention approach can be more wire-efficient in some cases and 403 may result in fewer translations at the NSP where the the CE 404 interfaces are of different types. 406 The intermediate format is effectively a new framing type. 408 4. Architecture of Pseudo-wires 410 This section describes the PWE3 architectural model. 412 4.1 Network Reference Model 414 Figure 2 illustrates the network reference model for point-to-point 415 PWs. 417 |<-------------- Emulated Service ---------------->| 418 | | 419 | |<------- Pseudo Wire ------>| | 420 | | | | 421 | | |<-- PSN Tunnel -->| | | 422 | PW End V V V V PW End | 423 V Service +----+ +----+ Service V 424 +-----+ | | PE1|==================| PE2| | +-----+ 425 | |----------|............PW1.............|----------| | 426 | CE1 | | | | | | | | CE2 | 427 | |----------|............PW2.............|----------| | 428 +-----+ ^ | | |==================| | | ^ +-----+ 429 ^ | +----+ +----+ | | ^ 430 | | Provider Edge 1 Provider Edge 2 | | 431 | | | | 432 Customer | | Customer 433 Edge 1 | | Edge 2 434 | | 435 | | 436 native service native service 438 Figure 2: PWE3 Network Reference Model 440 The two PEs (PE1 and PE2) need to provide one or more PWs on behalf 441 of their client CEs (CE1 and CE2) to enable the client CEs to 442 communicate over the PSN. A PSN tunnel is established to provide a 443 data path for the PW. The PW traffic is invisible to the core 444 network, and the core network is transparent to the CEs. Native data 445 units (bits, cells or packets) presented at the PW End Service (PWES) 446 are encapsulated in a PW-PDU and carried across the underlying 447 network via the PSN tunnel. The PEs perform the necesssary 448 encapsulation and decapsulation of PW-PDUs, as well as handling any 449 other functions required by the PW service, such as sequencing or 450 timing. 452 There are situations in which a particular packet payload needs to be 453 multicast so that it is received by a number of CEs. This is useful 454 when using PWs as part of a "virtual LAN" service (see, e.g., 455 [VPLS]). This can be achieved by replicating the payload and 456 transmitting the replicas on PWs, but it may also be useful to have a 457 type of PW which is inherently point-to-multipoint. In that case, 458 the PW would need to be carried through a point-to-multipoint PSN 459 tunnel, employing a multicast mechanism provided by the PSN. 461 4.2 PWE3 Pre-processing 463 In some applications, there is a need to perform operations on the 464 native data units received from the CE (including both payload and 465 signalling traffic) before they are transmitted across the PW by the 466 PE. Examples include Ethernet bridging, SONET cross-connect, 467 translation of locally-significant identifiers such as VCI/VPI, or 468 translation to another service type. These operations could be 469 carried out in external equipment, and the processed data sent to the 470 PE over one or more physical interfaces. In most cases, there are 471 cost and operational benefits in undertaking these operations within 472 the PE. This processed data is then presented to the PW via a 473 virtual interface within the PE. 475 These pre-processing operations are included in the PWE3 reference 476 model to provide a common reference point, but the detailed 477 description of these operations is outside the scope of the PW 478 definition given here. 480 PW 481 End Service 482 | 483 |<------- Pseudo Wire ------>| 484 | | 485 | |<-- PSN Tunnel -->| | 486 V V V V PW 487 +-----+----+ +----+ End Service 488 +-----+ |PREP | PE1|==================| PE2| | +-----+ 489 | | | |............PW1.............|----------| | 490 | CE1 |----| | | | | | | CE2 | 491 | | ^ | |............PW2.............|----------| | 492 +-----+ | | | |==================| | | ^ +-----+ 493 | +-----+----+ +----+ | | 494 | ^ | | 495 | | | | 496 | |<------- Emulated Service ------->| | 497 | | | 498 | Virtual physical | 499 | termination | 500 | ^ | 501 CE1 native | CE2 native 502 service | service 503 | 504 CE2 native 505 service 507 Figure 3: Pre-processing within the PWE3 Network Reference Model 509 Figure 3 shows the inter-working of one PE with pre-processing 510 (PREP), and a second without this functionality. This is a useful 511 reference point because it emphasises that the functional interface 512 between PREP and the PW is that represented by a physical interface 513 carrying the service. This effectively defines the necessary inter- 514 working specification. 516 The operation of a system in which both PEs include PREP 517 functionality is also supported. 519 The required pre-processing can be divided into two components: 520 o Forwarding (FWD) 522 o Native Service Processing (NSP) 524 4.2.1. Forwarders 526 In some applications there is the need to selectively forward payload 527 elements from one of more ACs to one or more PWs. In such cases there 528 will also be the need to perform the inverse function on PWE3-PDUs 529 received by a PE from the PSN. This is the function of the Forwarder 530 (FWD). 532 The forwarder selects the PW based on for example: the incoming AC, 533 the contents of the payload, or some statically or dynamically 534 configured forwarding information. 536 +----------------------------------------+ 537 | PE Device | 538 +----------------------------------------+ 539 Single | | | 540 PWES | | Single | PW Instance 541 <------>o Forwarder + PW IWF X<===========> 542 | | Instance | 543 +----------------------------------------+ 545 Figure 4a: Simple point-to-point service 547 +----------------------------------------+ 548 | PE Device | 549 +----------------------------------------+ 550 Multiple| | Single | PW Instance 551 PWES | + PW IWF X<===========> 552 <------>o | Instance | 553 | |----------------------| 554 <------>o | Single | PW Instance 555 | + PW IWF X<===========> 556 <------>o | Instance | 557 | Forwarder |----------------------| 558 <------>o | Single | PW Instance 559 | + PW IWF X<===========> 560 <------>o | Instance | 561 | |----------------------| Multipoint 562 | | Multipoint | PW Instance 563 | + PW IWF X<===========> 564 | | Instance | 565 +----------------------------------------+ 567 Figure 4b: Multiple PWEs to Multiple PW Forwarding 569 Figure 4a shows a simple forwarder that performs some type of 570 filtering operation. Figure 4b shows a more general forwarding 571 situation where payloads are extracted from one or more PWESs and 572 directed to one or more PWs, including, in this instance, a 573 multipoint PW. 575 4.2.2. Native Service Processing 577 In some applications some form of data or address translation, or 578 other operation requiring knowledge of the semantics of the payload, 579 will be required. This is the function of the Native Service 580 Processor (NSP). 582 The use of the NSP approach simplifies the design of the PW by 583 restricting a PW to homogeneous operation. NSP is included in the 584 reference model to provide a defined interface to this functionality. 585 The specification of the various types of NSP is outside the scope of 586 PWE3. 588 +----------------------------------------+ 589 | PE Device | 590 Multiple+----------------------------------------+ 591 PWES | | | Single | PW Instance 592 <------>o NSP # + PW IWF X<===========> 593 | | | Instance | 594 |------| |----------------------| 595 | | | Single | PW Instance 596 <------>o NSP # + PW IWF X<===========> 597 | | | Instance | 598 |------|Forwarder |----------------------| 599 | | | Single | PW Instance 600 <------>o NSP # + PW IWF X<===========> 601 | | | Instance | 602 |------| |----------------------| Multipoint 603 | | | Multipoint | PW Instance 604 <------>o NSP # + PW IWF X<===========> 605 | | | Instance | 606 +----------------------------------------+ 608 Figure 5: NSP in a Multiple PWEs to Multiple 609 PW Forwarding PE 611 Figure 5 illustrates the relationship between NSP, Forwarding and PWs 612 in a PE. The NSP function may apply any transformation operation 613 (modification, injection, etc.) on the payloads as they pass between 614 the physical interface to the CE and the virtual interface to the 615 Forwarder. A PE device may contain more than one Forwarder. 617 The operation of a system in which the NSP functionality includes 618 terminating the data-link and applying network layer processing to 619 the payload is also supported. 621 4.3 Maintenance Reference Model 623 Figure 6 illustrates the maintenance reference model for PWs. 625 |<------- CE (end-to-end) Signaling ------>| 626 | |<---- PW/PE Maintenance ----->| | 627 | | |<-- PSN Tunnel -->| | | 628 | | | Signaling | | | 629 | V V (out of scope) V V | 630 v +-----+ +-----+ v 631 +-----+ | PE1 |==================| PE2 | +-----+ 632 | |-----|.............PW1..............|-----| | 633 | CE1 | | | | | | CE2 | 634 | |-----|.............PW2..............|-----| | 635 +-----+ | |==================| | +-----+ 636 +-----+ +-----+ 637 Customer Provider Provider Customer 638 Edge 1 Edge 1 Edge 2 Edge 2 640 Figure 6: PWE3 Maintenance Reference Model 642 The following signaling mechanisms are required: 644 o The CE (end-to-end) signaling is between the CEs. This 645 signaling could be frame relay PVC status signaling, ATM SVC 646 signaling, etc. 648 o The PW/PE Maintenance is used between the PEs (or NSPs) to set 649 up, maintain and tear down PWs, including any required 650 coordination of parameters. 652 o The PSN Tunnel signaling controls the PW multiplexing and some 653 elements of the underlying PSN. Examples are L2TP control protocol, 654 MPLS LDP and RSVP-TE. This type of signaling is not within the 655 scope of PWE3. 657 4.4 Protocol Stack Reference Model 659 Figure 7 illustrates the protocol stack reference model for PWs. 661 +-----------------+ +-----------------+ 662 |Emulated Service | |Emulated Service | 663 |(e.g. TDM, ATM) |<==== Emulated Service ===>|(e.g. TDM, ATM) | 664 +-----------------+ +-----------------+ 665 | Payload | | Payload | 666 | Encapsulation |<====== Pseudo Wire ======>| Encapsulation | 667 +-----------------+ +-----------------+ 668 |PW Demultiplexer | |PW Demultiplexer | 669 | PSN Tunnel, |<======= PSN Tunnel ======>| PSN Tunnel, | 670 | PSN & Physical | | PSN & Physical | 671 | Layers | | Layers | 672 +-------+---------+ ___________ +---------+-------+ 673 | / \ | 674 +===============/ PSN \================+ 675 \ / 676 \_____________/ 678 Figure 7: PWE3 Protocol Stack Reference Model 680 The PW provides the CE with an emulated physical or virtual 681 connection to its peer at the far end. Native data units from the CE 682 are passed through an encapsulation layer at the sending PE, and then 683 sent over the PSN. The receiving PE removes the encapsulation and 684 restores the payload to its native format for transmission to the 685 destination CE. 687 4.5 Pre-processing Extension to Protocol Stack Reference Model 689 Figure 8 illustrates how the protocol stack reference model is 690 extended to include the provision of pre-processing (Fowarding and 691 NSP). This shows the ideal placement of the physical interface 692 relative to the CE. 694 /======================================\ 695 H Forwarder H<----Pre-processing 696 H----------------======================/ 697 H Native Service H | | 698 H Processing H | | 699 \================/ | | 700 | | | Emulated | 701 | Service | | Service | 702 | Interface | | (TDM, ATM, | 703 | (TDM, ATM, | | Ethernet, |<== Emulated Service == 704 | Ethernet, | | frame relay, | 705 | frame relay, | | etc.) | 706 | etc.) | +-----------------+ 707 | | | Payload | 708 | | | Encapsulation |<=== Pseudo Wire ====== 709 | | +-----------------+ 710 | | |PW Demultiplexer | 711 | | | PSN Tunnel, | 712 | | | PSN & Physical |<=== PSN Tunnel ======= 713 | | | Headers | 714 +----------------+ +-----------------+ 715 | Physical | | Physical | 716 +-------+--------+ +-------+---------+ 717 | | 718 | | 719 | | 720 | | 721 | | 722 | | 723 To CE <---+ +---> To PSN 725 Figure 8: Protocol Stack Reference Model with Pre-processing 727 5. PW Encapsulation 729 The PW Encapsulation Layer provides the necessary infrastructure to 730 adapt the specific payload type being transported over the PW to the 731 PW Demultiplexer Layer that is used to carry the PW over the PSN. 733 The PW Encapsulation Layer consists of three sub-layers: 735 o Payload Convergence 736 o Timing 737 o Sequencing 739 The PW Encapsulation sub-layering and its context with the protocol 740 stack are shown, in Figure 9. 742 +---------------------------+ 743 | Payload | 744 /===========================\ <------ Encapsulation 745 H Payload Convergence H Layer 746 H---------------------------H 747 H Timing H 748 H---------------------------H 749 H Sequencing H 750 \===========================/ 751 | PW Demultiplexer | 752 +---------------------------+ 753 | PSN Convergence | 754 +---------------------------+ 755 | PSN | 756 +---------------------------+ 757 | MAC/Data-link | 758 +---------------------------+ 759 | Physical | 760 +---------------------------+ 762 Figure 9: PWE3 Encapsulation Layer in Context 764 The Payload Convergence Sub-layer is highly tailored to the specific 765 payload type, but, by grouping a number of target payload types into 766 a generic class, and then providing a single convergence sub-layer 767 type common to the group, we achieve a reduction in the number of 768 payload convergence sub-layer types. This decreases implementation 769 complexity. The provision of per-packet signalling and other out-of- 770 band information (other than sequencing or timing) is undertaken by 771 this layer. 773 The Timing Layer and the Sequencing Layer provide generic services to 774 the Payload Convergence Layer for all payload types, when required. 776 5.1 Payload Convergence Layer 778 5.1.1. Encapsulation 780 The primary task of the Payload Convergence Layer is the 781 encapsulation of the payload in PW-PDUs. The native data units to be 782 encapsulated may or may not contain L2 or L1 header information. 783 This is service specific. The Payload Convergence header carries the 784 additional information needed to replay the native data units at the 785 CE-bound physical interface. The PW Demultiplexer header is not 786 considered as part of the PW header. 788 Not all the additional information needed to replay the native data 789 units need to be carried in the PW header of the PW PDUs. Some 790 information (e.g. service type of a PW) may be stored as state 791 information at the destination PE during PW set-up. 793 5.1.2. PWE3 Channel Types 795 The PW Encapsulation Layer and its associated signaling require one 796 or more of the following types of channel from its underlying PW 797 Demultiplexer and PSN Layers: 799 1. A reliable control channel for signaling line events, status 800 indications, and, in some exceptional cases, CE-CE events 801 which must be translated and sent reliably between PEs. 803 For example, this capability is needed in [PPPoL2TP] 804 (PPP negotiation has to be split between the two ends of the 805 tunnel). PWE3 may also need this type of control channel to 806 provide faithful emulation of complex data-link protocols. 808 plus one or more data channels with the following characteristics: 810 2. A high-priority, unreliable, sequenced channel. A typical use 811 is for CE-to-CE signaling. "High priority" may simply be 812 indicated via DSCP/EXP bits for priority during transit. 813 This channel type could also use a bit in the tunnel header 814 itself to indicate that packets received at the PE should be 815 processed with higher priority. 817 3. A sequenced channel for data traffic that is sensitive to 818 packet reordering (one classification for use could be for 819 any non-IP traffic). 821 4. An un-sequenced channel for data traffic insensitive to packet 822 order. 824 The data channels (2, 3 and 4 above) should be carried "in band" with 825 one another to as much of a degree as is reasonably possible on a 826 PSN. 828 Where end-to-end connectivity may be disrupted by address translation 829 [RFC3022], access-control lists, firewalls etc., there exists the 830 possibility that the control channel may be able to pass traffic and 831 set up the PW, but the PW data-path data traffic is blocked by one or 832 more of these mechanisms. In these cases unless the control channel 833 is also carried "in band" the signalling to set-up the PW will not 834 confirms the existence of an end-to-end data path. 836 In some cases there is a need to synchronize some CE events with the 837 data carried over a PW. This is especially the case with TDM 838 circuits (e.g., on-hook/off-hook events in PSTN switches). 840 PWE3 channel types that are not needed by the supported PWs need not 841 be included in such an implementation. 843 5.1.3. Quality of Service Considerations 845 Where possible, it is desirable to employ mechanisms to provide PW 846 Quality of Service (QoS) support over PSNs. Specification of a QoS 847 design common to all PW Service types needs further investigation. 849 5.2 Payload-independent PW Encapsulation Layers 851 Two PWE3 Encapsulation Sub-layers provide common services to all 852 payload types: Sequencing and Timing. These services are optional 853 and are only used if needed by a particular PW instance. If the 854 service is not needed, the associated header may be omitted in order 855 to conserve processing and network resources. 857 There will be instances where a specific payload type will be 858 required to be transported with or without sequence and/or real-time 859 support. For example, an invariant of frame relay transport is the 860 preservation of packet order. Some frame-relay applications expect 861 in-order delivery, and may not cope with reordering of the frames. 862 However, where the frame relay service is itself only being used to 863 carry IP, it may be desirable to relax that constraint in return for 864 reduced per-packet processing cost. 866 The guiding principle is that, where possible, an existing IETF 867 protocol should be used to provide these services. Where a suitable 868 protocol is not available, the existing protocol should be extended 869 or modified to meet the PWE3 requirements, thereby making that 870 protocol available for other IETF uses. In the particular case of 871 timing, more than one general method may be necessary to provide for 872 the full scope of payload timing requirements. 874 5.2.1. Sequencing 876 The sequencing function provides three services: frame ordering, 877 frame duplication detection and frame loss detection. These services 878 allow the invariant properties of a physical wire to be emulated. 879 Support for sequencing depends on the payload type, and may be 880 omitted if not needed. 882 The size of the sequence-number space depends on the speed of the 883 emulated service, and the maximum time of the transient conditions in 884 the PSN. A sequence number space greater than approximately 2^16 may 885 therefore be needed to prevent the sequence number space wrapping 886 during the transient. 888 5.2.1.1 Frame Ordering 890 When packets carrying the PW-PDUs traverse a PSN, they may arrive out 891 of order at the destination PE. For some services, the frames 892 (control frames, data frames, or both control and data frames) must 893 be delivered in order. For such services, some mechanism must be 894 provided for ensuring in-order delivery. Providing a sequence number 895 in the sequence sub-layer header for each packet is one possible 896 approach to out-of-sequence detection. Alternatively it can be noted 897 that sequencing is a subset of the problem of delivering timed 898 packets, and that a single combined mechanism such as [RTP] may be 899 employed. 901 There are two possible misordering strategies: 903 o Drop misordered PW PDUs. 905 o Try to sort PW PDUs into the correct order. 907 The choice of strategy will depend on: 909 o How critical the loss of packets is to the operation of 910 the PW (e.g. the acceptable bit error rate). 912 o The speeds of the PW and PSN. 914 o The acceptable delay (since delay must be introduced to reorder) 916 o The incidence of expected misordering. 918 5.2.1.2 Frame Duplication Detection 920 In rare cases, packets traversing a PW may be duplicated by the 921 underlying PSN. For some services, frame duplication is not 922 acceptable. For such services, some mechanism must be provided to 923 ensure that duplicated frames will not be delivered to the 924 destination CE. The mechanism may or may not be the same as the 925 mechanism used to ensure in-order frame delivery. 927 5.2.1.3 Frame Loss Detection 929 A destination PE can determine whether a frame has been lost by 930 tracking the sequence numbers of the received PW PDUs. 932 In some instances, a destination PE will have to presume that a PW 933 PDU is lost if it fails to arrive within a certain time. If a PW-PDU 934 that has been processed as lost subsequently arrives, the destination 935 PE must discard it. 937 5.2.2. Timing 939 A number of native services have timing expectations based on the 940 characteristics of the networks that they were designed to travel 941 over, and it can be necessary for the emulated service to duplicate 942 these network characteristics as closely as possible, e.g. in 943 delivering native traffic with the same jitter, bit-rate and timing 944 characteristics as it was sent. 946 In such cases, it is necessary for the receiving PE to play out the 947 native traffic as it was received at the sending PE. This relies on 948 either timing information sent between the two PEs, or in some case 949 timing information received from an external reference. 951 The Timing Sub-layer must therefore support two timing functions: 952 clock recovery and timed payload delivery. A particular payload type 953 may require either or both of these services. 955 5.2.2.1 Clock Recovery 957 Clock recovery is the extraction of output transmission bit timing 958 information from the delivered packet stream, and requires a phase- 959 locking mechanism. A physical wire provides this naturally, but it 960 is a relatively complex task to extract this from a highly jittered 961 source such as packet stream. It is therefore desirable that an 962 existing real-time protocol such as [RTP] be used for this purpose, 963 unless it can be shown that this is unsuitable or unnecessary for a 964 particular payload type. 966 5.2.2.2 Timed delivery 968 Timed delivery is the delivery of non-contiguous PW PDUs to the PW 969 output interface with a constant phase relative to the input 970 interface. The timing of the delivery may be relative to a clock 971 derived from the packet stream via clock recovery, or via an external 972 clock. 974 5.3 Fragmentation 976 A payload would normally be relayed across the PW as a single unit. 977 However, there will be cases where the combined size of the payload 978 and its associated PWE3 and PSN headers exceeds the PSN path MTU. 979 When a packet exceeds the MTU of a given network, fragmentation and 980 reassembly may have to be performed in order for the packet to be 981 delivered. Since fragmentation and reassembly generally consume a 982 large amount of network resource as compared to simply switching a 983 packet in its entirety, efforts should be made to reduce or eliminate 984 the need for fragmentation and reassembly as much as possible 985 throughout a network. Of particular concern for fragmentation and 986 reassembly are aggregation points where large numbers of pseudowires 987 are processed (e.g. at the PE). 989 Ideally, the equipment originating the traffic being sent over the PW 990 will be configured to have adaptive measures [e.g. [RFC1191], 991 [RFC1981]] in place such that it never sends a packet which must be 992 fragmented. When this fails, the point closest to the sending host 993 with fragmentation and reassembly capabilities should attempt to 994 reduce the size of packets further into the network. Thus, in the 995 reference model for PWE3 [Figure 3] fragmentation should first be 996 performed at the CE if at all possible. If and only if the CE cannot 997 adhere to an acceptable MTU size for the PW should the PE attempt its 998 own fragmentation methods. Further, if an adequate general 999 fragmentation method exists (e.g. as part of the native protocol 1000 being carried by the PW, or the PSN itself) then this should be 1001 employed when possible. 1003 Examining fragmentation mechanisms for PWE3 is a current work item. 1004 Further study may establish the need for a common PWE3 specific 1005 method. 1007 It is acceptable for a PE implementation not to support 1008 fragmentation. A PE that does not support fragmentation will drop 1009 packets that exceed the PSN MTU, and the management plane of the 1010 encapsulating PE may be notified. 1012 If the length of a L2/L1 frame, restored from a PW PDU, exceeds the 1013 MTU of the destination PWES, it must be dropped. In this case, the 1014 management plane of the destination PE may be notified. 1016 5.4 Instantiation of the Protocol Layers 1018 This document does not address the detailed mapping of the Protocol 1019 Layering model to existing or future IETF standards. The 1020 instantiation of the logical Protocol Layering model is shown in 1021 Figure 9. 1023 5.4.1. PWE3 over an IP PSN 1025 The protocol definition of PWE3 over an IP PSN therefore should 1026 employ existing IETF protocols where possible. 1028 +---------------------+ +-------------------------+ 1029 | Payload |------------->| Raw payload if possible | 1030 /=====================\ +-------------------------+ 1031 H Payload Convergence H------------->| As Needed | 1032 H---------------------H +-------------------------+ 1033 H Timing H----------+-->| RTP | 1034 H---------------------H / +-------------+ | 1035 H Sequencing H----one of | | 1036 \=====================/ \ | +-----------+ 1037 | PW Demultiplexer |----------+-->| L2TP, GRE, IPSec, MPLS | 1038 +---------------------+ +-------------------------+ 1039 | PSN Convergence |------------->| Not needed | 1040 +---------------------+ +-------------------------+ 1041 | PSN |------------->| IP | 1042 +---------------------+ +-------------------------+ 1043 | MAC/Data-link |------------->| MAC/Data-link | 1044 +---------------------+ +-------------------------+ 1045 | Physical |------------->| Physical | 1046 +---------------------+ +-------------------------+ 1048 Figure 10: PWE3 over an IP PSN 1050 Figure 10 shows the protocol layering for PWE3 over an IP PSN. As a 1051 rule, the payload should be carried as received from the NSP, with 1052 the Payload Convergence Layer provided when needed. (It is accepted 1053 that there may sometimes be good reason not to follow this rule, but 1054 the exceptional circumstances need to be documented in the 1055 encapsulation layer definition for that payload type). 1057 Where appropriate, timing is provided by RTP, which when used also 1058 provides a sequencing service. PW demultiplexing may be provided by 1059 a number of existing IETF tunnel protocols. Some of these tunnel 1060 protocols provide an optional sequencing service. (Sequencing is 1061 provided either by RTP, or by the PW Demultiplexer Layer, but not 1062 both). A PSN convergence layer is not needed, because all the tunnel 1063 protocols shown above are designed to operate directly over an IP 1064 PSN. 1066 As a special case, if the PW demultiplexer label is MPLS, the 1067 protocol architecture of section 5.4.2 can be used instead of the 1068 protocol architecture of this section. 1070 5.4.2. PWE3 over an MPLS PSN 1072 The MPLS ethos places importance on wire efficiency. By using a 1073 control word, some components of the PWE3 protocol layers can be 1074 compressed to increase wire efficiency. 1076 +---------------------+ 1077 | Payload | 1078 /=====================\ 1079 H Payload Convergence H-----------------+ 1080 H---------------------H | 1081 H Timing H | 1082 H---------------------H | 1083 H Sequencing H------------------------------------+ 1084 \=====================/ | | 1085 | PW Demultiplexer |---+ | | 1086 +---------------------+ | | | 1087 | PSN Convergence |-----------------------+----+----+ | 1088 +---------------------+ | | | | | | 1089 | PSN |-+ | v v v v v 1090 +---------------------+ | | +--------------------------------+ 1091 | MAC/Data-link | | | | Flags |Frag| Len |Seq # | 1092 +---------------------+ | | +--------------------------------+ 1093 | Physical | | +->| Inner Label | 1094 +---------------------+ | +--------------------------------+ 1095 +--->| Outer Label or MPLS-in-IP encap| 1096 +--------------------------------+ 1098 Figure 11: PWE3 over an MPLS PSN using a control word 1100 Figure 11 shows the protocol layering for PWE3 over an MPLS PSN. An 1101 inner MPLS label is used to provide the PW demultiplexing function. 1102 A control word is used to carry most of the information needed by the 1103 PWE3 Encapsulation Layer and the PSN Convergence Layer in a compact 1104 format. The flags in the control word provide the necessary payload 1105 convergence. A sequence field provides support for both in-order 1106 payload delivery and (supported by fragmentation control bits) a PSN 1107 fragmentation service within the PSN Convergence Layer. To allow 1108 PWE3 carried in MPLS to correctly pass over an Ethernet data-link, a 1109 length correction field is needed in the control word. 1111 In some networks it may be necessary to carry PWE3 over MPLS over IP. 1112 In these circumstances, the PW is encapsulated for carriage over MPLS 1113 as described in this section, and then a standard method of carrying 1114 MPLS over an IP PSN is applied to the resultant PW-PDU. 1116 6. PW Demultiplexer Layer and PSN Requirements 1118 PWE3 places three service requirements on the protocol layers used to 1119 carry it across the PSN: 1121 o Multiplexing 1122 o Fragmentation 1123 o Length and Delivery 1125 6.1 Multiplexing 1127 The purpose of the PW Demultiplexer Layer is to allow multiple PWs to 1128 be carried in a single tunnel. This minimizes complexity and 1129 conserves resources. 1131 Some types of native service are capable of grouping multiple 1132 circuits into a "trunk", e.g. multiple ATM VCs in a VP, multiple 1133 Ethernet VLANs in a port, or multiple DS0 services within a T1 or E1. 1134 A PW may interconnect two end-trunks. That trunk would have a single 1135 multiplexing value. 1137 6.2 Fragmentation 1139 Fragmentation is discussed in Section 5.3. 1141 If the PSN provides a fragmentation service of adequate performance, 1142 that mechanism may be used by the PE to fragment and reassemble PW 1143 PDUs which exceed the PSN MTU. This fragmentation service is 1144 transparent to the PW Encapsulation Layer. 1146 6.3 Length and Delivery 1148 PDU delivery to the egress PE is the function of the PSN Layer. 1150 If the underlying PSN does not provide all the information necessary 1151 to determine the length of a PW-PDU, the encapsulation layer will 1152 provide it. 1154 7. Control Plane 1156 This section describes PWE3 control plane services. 1158 7.1 Set-up or Teardown of Pseudo-Wires 1160 A PW must be set up before an emulated service can be established, 1161 and must be torn down when an emulated service is no longer needed. 1163 Set up or teardown of a PW can be triggered by a CLI command, from 1164 the management plane of a PE, by signaling (i.e., set-up or teardown) 1165 of a PWES, e.g., an ATM SVC, or by an auto-discovery mechanism e.g. 1166 [BGPAUTO]. 1168 During the set-up process, the PEs need to exchange some information 1169 (e.g. learn each others' capabilities). The tunneling control 1170 protocol may be extended to provide mechanisms to enable the PEs to 1171 exchange all necessary information on behalf of the PW. 1173 Manual configuration of PWs can be considered a special kind of 1174 signaling, and is explicitly allowed. 1176 7.2 Status Monitoring 1178 Some native services have mechanisms for status monitoring. For 1179 example, ATM supports OAM for this purpose. For such services, the 1180 corresponding emulated services must specify how to perform status 1181 monitoring. 1183 7.3 Notification of Pseudo-wire Status Changes 1185 7.3.1. Pseudo-wire Up/Down Notification 1187 If a native service requires bi-directional connectivity, the 1188 corresponding emulated service can only be signaled up when the 1189 associated PWs, and PSN tunnels if any, are functional in both 1190 directions. 1192 Because the two CEs of an emulated service are not adjacent, a 1193 failure may occur at a place such that one or both physical links 1194 between the CEs and PEs remain up. For example, in Figure 2, if the 1195 physical link between CE1 and PE1 fails, the physical link between 1196 CE2 and PE2 will not be affected and will remain up. Unless CE2 is 1197 notified about the remote failure, it will continue to send traffic 1198 over the emulated service to CE1. Such traffic will be discarded at 1199 PE1. Some native services have failure notification so that when the 1200 services fail, both CEs will be notified. For such native services, 1201 the corresponding PWE3 service must provide a failure notification 1202 mechanism. 1204 Similarly, if a native service has notification mechanisms so that 1205 when a network failure is fixed, all the affected services will 1206 change status from "Down" to "Up", the corresponding emulated service 1207 must provide a similar mechanism for doing so. 1209 These mechanisms may already be built into the tunneling protocol. 1210 For example, the L2TP control protocol has this capability and LDP 1211 has the ability to withdraw the corresponding MPLS label. 1213 7.3.2. Misconnection and Payload Type Mismatch 1215 With PWE3, misconnection and payload type mismatch can occur. If a 1216 misconnection occurs it can breach the integrity of the system. If a 1217 payload mismatch occurs it can disrupt the customer network. In both 1218 instances, there are security concerns. 1220 The services of the underlying tunneling mechanism, and its 1221 associated control protocol, can be used to mitigate this. 1223 This area needs further study. 1225 7.3.3. Packet Loss, Corruption, and Out-of-order Delivery 1227 A PW can incur packet loss, corruption, and out-of-order delivery on 1228 the PSN path between the PEs. This can impact the working condition 1229 of an emulated service. For some payload types, packet loss, 1230 corruption, and out-of-order delivery can be mapped to either a bit 1231 error burst, or loss of carrier on the PW. If a native service has 1232 some mechanism to deal with bit error, the corresponding PWE3 service 1233 should provide a similar mechanism. 1235 7.3.4. Other Status Notification 1237 A PWE3 approach may provide a mechanism for other status 1238 notification, if any. 1240 7.3.5. Collective Status Notification 1242 Status of a group of emulated services may be affected identically by 1243 a single network incident. For example, when the physical link (or 1244 sub-network) between a CE and a PE fails, all the emulated services 1245 that go through that link (or sub-network) will fail. It is likely 1246 that there exists a group of emulated services that all terminate at 1247 a remote CE. There may also be multiple such CEs affected by the 1248 failure. Therefore, it is desirable that a single notification 1249 message be used to notify failure of the whole group of emulated 1250 services. 1252 A PWE3 approach may provide some mechanism for notifying status 1253 changes of a group of emulated circuits. One possible method is to 1254 associate each emulated service with a group ID when the PW for that 1255 emulated service is set up. Multiple emulated services can then be 1256 grouped by associating them with the same group ID. In status 1257 notification, that group ID can be used to refer all the emulated 1258 services in that group. 1260 This should be a mechanism provided by the underlying tunneling 1261 protocol. 1263 7.4 Keep-alive 1265 If a native service has a keep-alive mechanism, the corresponding 1266 emulated service needs to use a mechanism to propagate this across 1267 the PW. An approach following the principle of minimum intervention 1268 would be to transparently transport keep-alive messages over the PW. 1269 However, to accurately reproduce the semantics of the native 1270 mechanism, some PWs may require an alternative approach, such as 1271 piggy-backing on the PW signalling mechanism. 1273 7.5 Handling Control Messages of the Native Services 1275 Some native services use control messages for maintaining the 1276 circuits. These control messages may be in-band, e.g. Ethernet flow 1277 control or ATM performance management, or out-of-band, e.g. the 1278 signaling VC of an ATM VP. 1280 From the principle of minimum intervention, it is desirable that the 1281 PEs participate as little as possible in the signaling and 1282 maintenance of the native services. This principle should not, 1283 however, override the need to satisfactorily emulate the native 1284 service. 1286 If control messages are passed through, it may be desirable to send 1287 them using a reliable channel provided by the PW Demultiplexer layer. 1288 See Bearer Channel Types. 1290 8. IANA considerations 1292 There are no IANA considerations for this document. 1294 9. Security Considerations 1296 PWE3 provides no means of protecting the contents or delivery of the 1297 native data units. PWE3 may, however, leverage security mechanisms 1298 provided by the PW Demultiplexer or PSN Layers, such as IPSec 1299 [RFC2401]. This section addresses the PWE3 vulnerabilities, and the 1300 mechanisms available to protect the emulated native services. 1302 The PW Tunnel End-Point, PW demultiplexing mechanism, and the 1303 payloads of the native service are all vulnerable to attack. 1305 The security aspects of PWE3 need further study. 1307 9.1 PW Tunnel End-Point and PW Demultiplexer Security 1309 Protection mechanisms must be considered for the PW Tunnel end-point 1310 and PW Demultiplexer mechanism in order to avoid denial-of-service 1311 attacks upon the native service, and to prevent spoofing of the 1312 native data units. Exploitation of vulnerabilities from within the 1313 PSN may be directed to the PW Tunnel end-point so that PW 1314 Demultiplexer and PSN tunnel services are disrupted. Controlling PSN 1315 access to the PW Tunnel end-point may protect against this. 1317 By restricting PW Tunnel end-point access to legitimate remote PE 1318 sources of traffic, the PE may reject traffic that would interfere 1319 with the PW demultiplexing and PSN tunnel services. 1321 9.2 Validation of PW Encapsulation 1323 Protection mechanisms must address the spoofing of tunneled PW data. 1324 The validation of traffic addressed to the PW demultiplexer end-point 1325 is paramount in ensuring integrity of PW encapsulation. Security 1326 protocols such as IPSec [RFC2401] may be used by the PW Demultiplexer 1327 Layer in order to maintain the integrity of the PW by authenticating 1328 data between the PW Demultiplexer End-points. IPSec may provide 1329 authentication, integrity, non-repudiation, and confidentiality of 1330 data transferred between two PE. It cannot provide the equivalent 1331 services to the native service. 1333 Based on the type of data being transferred, the PW may indicate to 1334 the PW Demultiplexer Layer that enhanced security services are 1335 required. The PW Demultiplexer Layer may define multiple protection 1336 profiles based on the requirements of the PW emulated service. CE- 1337 to-CE signaling and control events emulated by the PW and some data 1338 types may require additional protection mechanisms. Alternatively, 1339 the PW Demultiplexer Layer may use peer authentication for every PSN 1340 packet to prevent spoofed native data units from being sent to the 1341 destination CE. 1343 9.3 End-to-End Security 1345 Protection of the PW encapsulated data stream between PEs should not 1346 be considered equivalent to end-to-end security, because the CE-PE 1347 interface and the PE processing element remain unprotected. PW 1348 service emulation does not preclude the application of additional 1349 security mechanisms, such as IPSec, that are implemented end-to-end. 1350 Likewise, end-to-end security mechanisms applied in the native 1351 service do not protect the PW demultiplexing and PSN tunnel services 1352 provided by the PE for PW encapsulation. 1354 Acknowledgments 1356 We thank Sasha Vainshtein for his work on Native Service Processing 1357 and advice on bit-stream over PW services. We thank Scott Wainner 1358 Stephen Casner, Andy Malis and Eric Rosen for their comments and 1359 contributions. 1361 References 1363 Internet-drafts are works in progress available from 1364 1366 [BGPAUTO] Using BGP as an Auto-Discovery Mechanism for Network-based 1367 VPNs. Ould-Brahim et al. 1368 , work in progress. 1370 [ETSI] EN 300 744 Digital Video Broadcasting (DVB); Framing 1371 structure, channel coding and modulation for digital 1372 terrestrial television (DVB-T), European Telecommunications 1373 Standards Institute (ETSI) 1375 [PPPoL2TP] PPP Tunneling Using Layer Two Tunneling Protocol, 1376 J Lau et al. , 1377 work in progress. 1379 [RFC1191] RFC-1191: Path MTU discovery. J.C. Mogul, S.E. Deering. 1381 [RFC1958] RFC-1958: Architectural Principles of the Internet, 1382 B. Carpenter et al. 1384 [RFC1981] RFC-1981: Path MTU Discovery for IP version 6. J. McCann, 1385 S. Deering, J.Mogul. 1387 [RFC2401] RFC-2401: Security Architecture for the Internet Protocol. 1388 S. Kent, R. Atkinson. 1390 [RFC3022] RFC-3022: Traditional IP Network Address Translator 1391 (Traditional NAT). P Srisuresh et al. 1393 [RTP] RFC-1889: A Transport Protocol for Real-Time Applications, H. 1394 Schulzrinne et al. 1396 Authors' Addresses 1398 Stewart Bryant 1399 Cisco Systems, 1400 4, The Square, 1401 Stockley Park, 1402 Uxbridge UB11 1BL, 1403 United Kingdom. Email: stbryant@cisco.com 1405 Danny McPherson 1406 TCB. Email: danny@tcb.net 1408 W. Mark Townsley 1409 Cisco Systems, 1410 7025 Kit Creek Road, 1411 PO Box 14987, 1412 Research Triangle Park, 1413 NC 27709 Email: mark@townsley.net 1415 Lloyd Wood 1416 Cisco Systems, 1417 4, The Square, 1418 Stockley Park, 1419 Uxbridge UB11 1BL, 1420 United Kingdom. Email: lwood@cisco.com 1422 Full copyright statement 1424 Copyright (C) The Internet Society (2002). All Rights Reserved. 1426 This document and translations of it may be copied and furnished to 1427 others, and derivative works that comment on or otherwise explain it 1428 or assist in its implementation may be prepared, copied, published 1429 and distributed, in whole or in part, without restriction of any 1430 kind, provided that the above copyright notice and this paragraph are 1431 included on all such copies and derivative works. However, this 1432 document itself may not be modified in any way, such as by removing 1433 the copyright notice or references to the Internet Society or other 1434 Internet organizations, except as needed for the purpose of 1435 developing Internet standards in which case the procedures for 1436 copyrights defined in the Internet Standards process must be 1437 followed, or as required to translate it into languages other than 1438 English. 1440 The limited permissions granted above are perpetual and will not be 1441 revoked by the Internet Society or its successors or assigns. 1443 This document and the information contained herein is provided on an 1444 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1445 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1446 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1447 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1448 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.