idnits 2.17.1 draft-bryant-pwe3-protocol-layer-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 4 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 158 has weird spacing: '...Edge to att...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2002) is 8105 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'PPPoL2TP' ** Obsolete normative reference: RFC 1889 (ref. 'RTP') (Obsoleted by RFC 3550) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Stewart Bryant 3 Document: Lloyd Wood 4 Expires: August 2002 Mark Townsley 5 cisco Systems Ltd 7 Danny McPherson 8 TCB 10 February 2002 12 Protocol Layering in PWE3 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-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 (PW), guidelines for the design of a specific 41 encapsulation type, and the service requirements of the underlying 42 PSN tunneling mechanism. 44 Table of Contents 46 1. Introduction............................................. 3 48 2. Terminology.............................................. 3 50 3. Architecture of Pseudo-wires............................. 5 51 3.1 Network Reference Model.............................. 5 52 3.2 Native Service Processing............................ 5 53 3.3 Maintenance Reference Model.......................... 9 54 3.4 Protocol Stack Reference Model....................... 10 55 3.5 NSP Extension to Protocol Stack Reference Model...... 11 57 4. Protocol Layering Model.................................. 12 58 4.1 Protocol Layers...................................... 13 59 4.2 Domain of PWE3....................................... 14 60 4.3 Payload Types........................................ 15 62 5. PW Encapsulation......................................... 16 63 5.1 Payload Convergence Layer............................ 17 64 5.2 Payload independent PW Encapsulation Layers.......... 18 65 5.3 Instantiation of the Protocol Layers................. 21 67 6. PSN Tunnel Layer......................................... 21 68 6.1 Multiplexing......................................... 21 69 6.2 Segmentation and Reassembly.......................... 21 70 6.3 Length and Delivery.................................. 22 72 7. Control Plane............................................ 22 73 7.1 Set-up or Teardown of Pseudo-Wires................... 22 74 7.2 Status Monitoring.................................... 23 75 7.3 Notification of Pseudo-wire Status Changes........... 23 76 7.4 Keep-alive........................................... 24 77 7.5 Handling Control Messages of the Native Services..... 25 79 8. IANA considerations...................................... 25 81 9. Security Considerations.................................. 25 82 9.1 Tunnel End-Point Security............................ 25 83 9.2 Validation of PW Encapsulation....................... 26 84 9.3 End to End Security.................................. 26 86 1. Introduction 88 This document presents a unified protocol layering approach for 89 pseudo-wire emulation edge-to-edge (PWE3). It adopts the principle 90 that PWE3 should be a single transport type operating over a common 91 packet-switched network (PSN) service model using, wherever possible, 92 existing IETF protocols. This document defines the protocol layering 93 model for pseudo-wires (PW), guidelines for the design of a specific 94 encapsulation type, and the service requirements of the underlying 95 PSN tunneling mechanism. 97 2. Terminology 99 This document uses the following definition of terms. A number of 100 these terms are further clarified by reference to Figure 1. 102 CE-bound The traffic direction where PW-PDUs are 103 received on a PW via the PSN, decapsulated 104 to retrieve the emulated service, and then 105 sent to the destination CE. 107 CE Signaling Messages sent and received by the CEs 108 control plane. It may be desirable or 109 even necessary for the PE to participate 110 in or monitor this signaling in order 111 to effectively emulate the service. 113 Customer Edge (CE) A device where one end of a service 114 originates and terminates. The CE is not 115 aware that it is using an emulated service 116 rather than a native service. 118 Inter-working Interactions between networks, between end 119 systems, or between parts thereof, with the 120 aim of providing a functional entity 121 capable of supporting an end-to-end 122 communication. 124 Inter-working A function that facilitates inter-working 125 Function (IWF) between two dissimilar networks. NSP may 126 perform the IWF function. 128 Native Service Processing of the data received by the PE 129 Processing (NSP) from the CE before presentation to the PW 130 for transmission across the core. 132 Packet Switched A network using IP or MPLS as the mechanism 133 Network (PSN) of packet forwarding. 135 Protocol Data The unit of data output to, or received 136 Unit (PDU) from, the network by a protocol layer. 138 Provider Edge (PE) A device that provides PWE3 to a CE. 140 PE-bound The traffic direction where information 141 from a CE is adapted to a PW, and PW-PDUs 142 are sent into the PSN. 144 PE/PW Maintenance Used by the PEs to set up, maintain and 145 tear down the PW. It may be coupled with 146 CE Signaling in order to effectively manage 147 the PW. 149 Pseudo Wire (PW) A connection between two PEs carried over a 150 PSN. 152 PW End Service The interface between a PE and a CE. This 153 (PWES) can be a physical interface like a T1 or 154 Ethernet, or a virtual interface like a VC 155 or VLAN. 157 Pseudo Wire A mechanism that emulates the essential 158 Emulation Edge to attributes of service (such as a T1 leased 159 Edge (PWE3) line or frame relay) over a PSN. 161 Pseudo Wire PDU A PDU sent on the PW that contains all of 162 the data and control information necessary 163 to emulate the desired service. 165 PSN Tunnel A tunnel across a PSN inside which one or 166 more PWs can be carried. 168 PSN Tunnel Used to set up, maintain and tear down the 169 Signaling underlying PSN tunnel. 171 SAR Segmentation and reassembly. 173 Tunnel A method of transparently carrying information 174 over a network. 176 3. Architecture of Pseudo-wires 178 This section describes the PWE3 architectural model. 180 3.1 Network Reference Model 182 Figure 1 illustrates the network reference model for PWs. 184 |<-------------- Emulated Service ---------------->| 185 | | 186 | |<------- Pseudo Wire ------>| | 187 | | | | 188 | | |<-- PSN Tunnel -->| | | 189 | PW End V V V V PW End | 190 V Service +----+ +----+ Service V 191 +-----+ | | PE1|==================| PE2| | +-----+ 192 | |----------|............PW1.............|----------| | 193 | CE1 | | | | | | | | CE2 | 194 | |----------|............PW2.............|----------| | 195 +-----+ ^ | | |==================| | | ^ +-----+ 196 ^ | +----+ +----+ | | ^ 197 | | Provider Edge 1 Provider Edge 2 | | 198 | | | | 199 Customer | | Customer 200 Edge 1 | | Edge 2 201 | | 202 | | 203 native service native service 205 Figure 1: PWE3 Network Reference Model 207 The two PEs (PE1 and PE2) need to provide one or more PWs on behalf 208 of their client CEs (CE1 and CE2) to enable them to communicate over 209 the PSN. A PSN tunnel is established to provide a data path for the 210 PW that is transparent to the network core. Native data units (bits, 211 cells or packets) presented at the PW End Service (PWES) are 212 encapsulated in a PW-PDU and carried across the underlying network 213 via the PSN tunnel. The PEs perform the necessary encapsulation, 214 decapsulation, sequencing, timing and any other functions required by 215 the PW service. 217 3.2 Native Service Processing 219 In some applications, there is a need to perform operations on the 220 native data units received from the CE (both payload and control 221 information) before it is transmitted across the PW by the PE. 222 Examples include Ethernet bridging, SONET cross-connect, translation 223 of locally significant identifiers such as VCI/VPI, or translation to 224 another service type. These operations could be carried out in 225 external equipment, and the processed data sent to the PE over one or 226 more physical interfaces. In most cases, there are cost and 227 operational benefits in undertaking this native service processing 228 (NSP) within the PE. This processed data is then presented to the PW 229 via a virtual interface within the PE. It must be emphasized that 230 this processing uses operations that are outside the scope of the PW 231 defined here. 233 The use of the NSP approach simplifies the design of the PW by 234 restricting a PW to homogeneous operation. NSP is included in the 235 reference model to provide a defined interface to this functionality. 236 The specification of the various types of NSP is outside the scope of 237 PWE3. 239 Figure 2 illustrates the relationship between NSP and the network 240 reference model for PWs. The PW may provide connectivity to a virtual 241 interface with the PE equipment. The NSP function may apply any 242 transformation operation (modification, injection, etc) on data as it 243 passes between the physical interface to the CE and the virtual 244 interface to the PW. It may also combine or split data between the 245 physical interfaces to the CE and the virtual interface to one or 246 more PWs. 248 PW 249 End Service 250 | 251 |<------- Pseudo Wire ------>| 252 | | 253 | |<-- PSN Tunnel -->| | 254 V V V V PW 255 +-----+----+ +----+ End Service 256 +-----+ |NSP1 | PE1|==================| PE2| | +-----+ 257 | | | |............PW1.............|----------| | 258 | CE1 |----| | | | | | | CE2 | 259 | | ^ | |............PW2.............|----------| | 260 +-----+ | | | |==================| | | ^ +-----+ 261 | +-----+----+ +----+ | | 262 | ^ | | 263 | | | | 264 | |<------- Emulated Service ------->| | 265 | | | 266 | Virtual physical | 267 | termination | 268 | ^ | 269 CE1 native | CE2 native 270 service | service 271 | 272 CE2 native 273 service 275 Figure 2: NSP within the PWE3 Network Reference Model 277 Figure 2 shows the inter-working of one PE with NSP, and a second 278 without this functionality. This is a useful reference point because 279 it emphasises that the functional interface between NSP and the PW is 280 that represented by a physical interface carrying the service. This 281 effectively defines the necessary inter-working specification. 283 The operation of a system in which both PEs include NSP is also 284 supported. 286 The operation of a system in which the NSP functionality includes 287 terminating the data-link, and applying network layer processing to 288 the payload, is also supported. 290 Internally, a PE with NSP has the following functional structure: 292 +----------------------------------------+ 293 | PE Device | 294 Single +----------------------------------------+ 295 PWES | | | Single | PW Instance 296 <--------->o NSP O<-->+ PW IWF X<===========> 297 | | | Instance | 298 | | | | 299 +----------------------------------------+ 301 Figure 3a: A simple point-to-point service 303 +----------------------------------------+ 304 | PE Device | 305 +----------------------------------------+ 306 | | | Single | PW Instance 307 | O<-->+ PW IWF X<===========> 308 | | | Instance | 309 | | |-----------------| 310 Single | O<-->+ Single | PW Instance 311 PWES | | | PW IWF X<===========> 312 <--------->o NSP | | Instance | 313 | | |-----------------| 314 | | | ... | 315 | | |-----------------| 316 | O<-->+ Single | PW Instance 317 | | | PW IWF X<===========> 318 | | | Instance | 319 +----------------------------------------+ 321 Figure 3b: A point-to-multipoint service 323 +----------------------------------------+ 324 | PE Device | 325 |----------------------------------------| 326 Multiple | | | Single | PW Instance 327 PWES | O<..>+ PW IWF X<===========> 328 <--------->o | | Instance | 329 | | |-----------------| 330 <--------->o O<..>+ Single | PW Instance 331 | | | PW IWF X<===========> 332 <--------->o NSP | | Instance | 333 | | |-----------------| 334 <--------->o | | ... | 335 ... | | |-----------------| 336 | O<..>+ Single | PW Instance 337 <--------->o | | PW IWF X<===========> 338 | | | Instance | 339 +----------------------------------------+ 341 Figure 3c: A full switch/bridge/cross-connect 342 multipoint-multipoint service 344 Notation: 345 o A physical CE-bound PE port 347 O An NSP virtual interface to a PW IWF instance. 349 + A PW IWF instance interface to the NSP. 351 X A PE PSN-bound port. 353 Figure 3: PE internals showing NSP 355 3.3 Maintenance Reference Model 357 Figure 4 illustrates the maintenance reference model for PWs. 359 |<------- CE (end-to-end) Signaling ------>| 360 | |<---- PW/PE Maintenance ----->| | 361 | | |<-- PSN Tunnel -->| | | 362 | | | Signaling | | | 363 | V V (out of scope) V V | 364 v +-----+ +-----+ v 365 +-----+ | PE1 |==================| PE2 | +-----+ 366 | |-----|.............PW1..............|-----| | 367 | CE1 | | | | | | CE2 | 368 | |-----|.............PW2..............|-----| | 369 +-----+ | |==================| | +-----+ 370 +-----+ +-----+ 371 Customer Provider Provider Customer 372 Edge 1 Edge 1 Edge 2 Edge 2 374 Figure 4: PWE3 Maintenance Reference Model 376 The following signaling mechanisms are required: 378 o The CE (end-to-end) signaling is between the CEs. This 379 signaling can include frame relay PVC status signaling, ATM SVC 380 signaling, etc. 382 o The PW/PE Maintenance is used between the PEs (or NSPs) to set 383 up, maintain and tear down PWs, including any required 384 coordination of parameters. 386 o The PSN Tunnel signaling controls the underlying PSN. Examples 387 are L2TP control protocol, or MPLS LDP. This type of signaling 388 is not within the scope of PWE3. 390 3.4 Protocol Stack Reference Model 392 Figure 5 illustrates the protocol stack reference model for PWs. 394 +----------------+ +----------------+ 395 |Emulated Service| |Emulated Service| 396 |(e.g. TDM, ATM) |<===== Emulated Service ====>|(e.g. TDM, ATM) | 397 +----------------+ +----------------+ 398 | Payload | | Payload | 399 | Encapsulation |<======= Pseudo Wire =======>| Encapsulation | 400 +----------------+ +----------------+ 401 | PSN Tunnel, |<======== PSN Tunnel =======>| PSN Tunnel, | 402 | PSN & Physical | | PSN & Physical | 403 | Layers | | Layers | 404 +-------+--------+ _____________ +--------+-------+ 405 | / \ | 406 +===============/ PSN \===============+ 407 \ / 408 \_____________/ 410 Figure 5: PWE3 Protocol Stack Reference Model 412 The PW provides the CE with what appears to be a direct physical 413 connection to its peer at the far end. Native data units from the CE 414 are passed through an encapsulation layer at the sending PE, and then 415 sent over the PSN. The receiving PE removes the encapsulation and 416 restores the payload to its native format for transmission to the 417 destination CE. 419 3.5 NSP Extension to Protocol Stack Reference Model 421 Figure 6 illustrates how the protocol stack reference model extended 422 to include the provision of native service processing. This shows the 423 correct placement of the physical interface relative to the CE. 425 +-----------------------------------+ 426 | Native Service Processing | 427 +--------------+---+----------------+ 428 | | | Emulated | 429 | Service | | Service | 430 | Interface | | (TDM, ATM, | 431 | (TDM, ATM, | | Ethernet, |<=== Emulated Service == 432 | Ethernet, | | frame relay, | 433 | frame relay, | | etc.) | 434 | etc.) | +----------------+ 435 | | | Payload | 436 | | | Encapsulation |<==== Pseudo Wire ====== 437 | | +----------------+ 438 | | | PSN Tunnel, | 439 | | | PSN & Physical |<==== PSN Tunnel ======= 440 | | | Headers | 441 +--------------+ +----------------+ 442 | Physical | | Physical | 443 +-------+------+ +-------+--------+ 444 | | 445 | | IP or MPLS Network 446 | | ----- --- 447 | | / \---/ \ 448 | | / \ 449 | | / \ 450 v +=========/ PSN | 451 To CE \ / 452 \ --- / 453 -----/ \-----/ 455 Figure 6: Protocol Stack Reference Model with NSP 457 4. Protocol Layering Model 459 The PWE3 protocol-layering model is intended to minimise the 460 differences between PWs operating over different PSN types. The 461 design of the protocol-layering model thus has the goals of making 462 each PW definition independent of the underlying PSN, and maximizing 463 the reuse of IETF protocol definitions. 465 4.1 Protocol Layers 467 The logical protocol-layering model required to support a PW is 468 expanded to provide more detail as shown in Figure 7. 470 +---------------------------+ 471 | Payload | 472 +---------------------------+ 473 | Encapsulation | <==== May be empty 474 +---------------------------+ 475 | PSN Tunnel | 476 +---------------------------+ 477 | PSN Convergence | <==== May be empty 478 +---------------------------+ 479 | PSN | 480 +---------------------------+ 481 | MAC/Data-link | 482 +---------------------------+ 483 | Physical | 484 +---------------------------+ 486 Figure 7: Logical Protocol Layering Model 488 The payload is transported over the Encapsulation Layer. The 489 Encapsulation Layer carries any information, not in the payload 490 itself, that is required by the PW CE-bound PE interface to send the 491 payload to the CE via the physical interface. 493 If needed, this layer also provides support for real-time processing, 494 and sequencing. 496 The PSN Tunnel Layer provides the ability to deliver multiple PWs 497 over a single PSN tunnel. 499 The PSN header, MAC/Data-link and Physical Layer definitions are 500 outside the scope of this framework. 502 The PSN Convergence Layer provides the enhancements needed to make 503 the PSN conform to the assumed PSN service requirement. This layer 504 therefore provides a consistent interface to the PW, making the PW 505 independent of the PSN type. If the PSN already meets the service 506 requirements, this layer is empty. 508 The PSN can be any PSN type defined by the IETF. These are currently 509 IPv4, IPv6 and MPLS. 511 4.2 Domain of PWE3 513 PWE3 defines the Encapsulation Layer, the method of carrying various 514 payload types, and the interface to the PSN Tunnel Layer. It is 515 expected that the other layers will be provided by tunneling methods 516 such as L2TP or MPLS over the PSN. 518 4.3 Payload Types 520 The payload is classified into the following generic types of native 521 data unit: 523 o Bit-stream 524 o Structured bit-stream 525 o Cell 526 o Packet 528 Within these generic types there are specific service types. For 529 example: 531 Generic Payload Type PW Service 532 -------------------- ---------- 533 Bit-stream SONET, TDM (e.g. DS1, DS3, E1). 535 Structured bit-stream SONET, TDM. 537 Cell ATM. 539 Packet Ethernet (all types), HDLC, 540 frame relay, ATM AAL5 PDU. 542 4.3.1. Bit-stream 544 A bit-stream payload is created by capturing, transporting and 545 replaying the bit pattern on the emulated wire, without taking 546 advantage of any structure that, on inspection, may be visible within 547 the relayed traffic. The Encapsulation Layer submits an identical 548 number of bits for transport in each PW-PDU. 550 This service will require sequencing and real-time support. 552 4.3.2. Structured bit-stream 554 A bit-stream payload is created by using some knowledge of the 555 underlying structure of the bit-stream to capture, transport and 556 replay the bit pattern on the emulated wire. 558 Two important points distinguish structured and unstructured bit- 559 streams: 561 o Some part of the original (unstructured) bit stream is 562 stripped by, for example, the PSN-bound direction of the 563 NSP block. For example, in Structured SONET the section 564 and line overhead (and, possibly, more) may be stripped. 566 o The PW must preserve the structure across the PSN so that 567 the CE-bound NSP block can insert it correctly into the 568 reconstructed unstructured bit stream. 570 The Encapsulation Layer may also perform silence/idle suppression or 571 similar a compression on a structured bit stream. 573 Structured bit streams are distinguished from cells in that the 574 structures may be too long to be carried in a single packet (i.e. 575 structured SONET). Note that "short" structures are undistinguishable 576 from cells and may benefit from the use of cell encapsulations. 578 This service will require sequencing and real-time support. 580 4.3.3. Cell Payload 582 A cell payload is created by capturing, transporting and replaying 583 groups of bits presented on the wire in a fixed-size format. The 584 delineation of the group of bits that comprise the cell is specific 585 to the encapsulation type. Two common examples of cell payloads are 586 53-octet cells carrying ATM AAL2, and the larger 188-octet DVB 587 Transport Stream packets. 589 To reduce PSN tunnel header overhead, multiple cells may be 590 concatenated into a single payload. The Encapsulation Layer may 591 consider the payload complete on the expiry of a timer, or when a 592 fixed number of cells have been received. The benefit of 593 concatenating multiple PDUs should be weighed against the resulting 594 larger penalty incurred by packet loss. In some cases, it may be 595 appropriate for the Encapsulation Layer to perform a silence 596 suppression or a similar compression. 598 The generic cell payload service will normally need sequence number 599 support, and may also need real-time support. The cell generic 600 payload service would not normally require fragmentation. 602 The Encapsulation Layer may apply some form of compression to some of 603 these sub-types. 605 In some instances, the cells to be incorporated in the payload may be 606 selected by filtering them from the stream of cells presented on the 607 wire. For example, an ATM PWE3 service may select cells based on 608 their VCI or VPI fields. That is an NSP function, and the selection 609 would therefore be made before the packet was presented to the PW 610 Encapsulation Layer. 612 4.3.4. Packet Payload 614 A packet payload is one that operates by capturing, transporting and 615 replaying groups of bits of varying sizes that are presented on the 616 wire. The delineation of the packet boundaries is encapsulation- 617 specific. Common examples of packet payloads are HDLC and Ethernet 618 PDUs. Typically a packet will be stripped of transmission overhead 619 such as HDLC flags and stuffing bits before transmission over the PW. 621 A packet payload would normally be relayed across the PW as a single 622 unit. However, there will be cases where the combined size of the 623 packet payload and its associated PWE3 and PSN headers exceeds the 624 PSN path MTU. This is likely to be the case when a user is providing 625 the service and attaching to the service provider via an Ethernet, or 626 where nested pseudo-wires are involved. The pseudo-wire would in 627 these cases require the use of the fragmentation support of the 628 underlying PSN or PSN Convergence Layer. 630 A packet payload may need sequencing and real-time support. 632 In some instances the packet payload may be selected from the packets 633 presented on the emulated wire on the basis of some sub-multiplexing 634 technique. For example, one or more frame relay PDUs may be selected 635 for transport over a particular pseudo-wire based on the frame relay 636 Data-Link Connection Identifier (DLCI), or, in the case of Ethernet 637 payloads, on the basis of the VLAN identifier. This is an NSP 638 function, and this selection would therefore be made before the 639 packet was presented to the PW Encapsulation Layer. 641 4.3.5. Principle of Minimum Intervention 643 To minimise the scope of information, and to improve the efficiency 644 of data flow through the Encapsulation Layer, the payload should, 645 where possible, be transported as received without modification. 647 5. PW Encapsulation 649 The PW Encapsulation Layer provides the necessary infrastructure to 650 adapt the specific payload type being transported over the PW to the 651 PSN Tunneling Layer that is used to carry the PW over the PSN. 653 The PW Encapsulation Layer consists of three sub-layers: 655 o Payload Convergence 656 o Sequencing 657 o Timing 659 The Payload Convergence Sub-layer is highly tailored to the specific 660 payload type, but, by grouping a number of target payload types into 661 a generic class, and then providing a single convergence sub-layer 662 type common to the group, we achieve a reduction in the number of 663 payload convergence sub-layer types. The provision of per-packet 664 signalling and other out-of-band information (other than sequencing 665 or timing) is undertaken by this layer. 667 The Sequencing Layer and the Timing Layer provide a generic services 668 to the Payload Convergence Layer for all payload types. 670 5.1 Payload Convergence Layer 672 5.1.1. Encapsulation 674 The primary task of the Payload Convergence Layer is the 675 encapsulation of the payload in PDUs. The native data units to be 676 encapsulated may or may not contain L2 or L1 header information. This 677 is service specific. The Payload Convergence header carries the 678 additional information needed to replay the native data units at the 679 CE-bound physical interface. The PSN tunnel header is not considered 680 as part of the PW header. 682 It should be noted that not all such information needs to be carried 683 in the PW header of the PW PDUs. Some information (e.g. service type 684 of a PW) can be stored as state information at the destination PE 685 during PW set-up. 687 5.1.2. Bearer Channel Types 689 The PW Encapsulation Layer and its associated signaling require one 690 or more of the following types of channel from its underlying PSN 691 Tunnel and PSN Layers: 693 1. A reliable control channel for signaling line events, status 694 indications, and, in some exceptional cases, CE-CE events 695 which must be translated and sent reliably between PEs. 697 For example, this capability is needed in [PPPoL2TP], because 698 PPP negotiation has to be split between the two ends of the 699 tunnel. PWE3 may also need this type of control channel to 700 provide faithful emulation of complex data-link protocols. 702 2. A high priority, unreliable, sequenced channel. A typical use 703 is for CE to CE signaling. "High priority" may simply be 704 reflected via DSCP/EXP bits for priority during transit. It may 705 also use a bit in the tunnel header itself to indicate that 706 packets received at the PE should be processed with higher 707 quality of service. 709 3. A sequenced channel for data traffic that is intolerant to 710 packet reordering (one classification for use could be for 711 any non-IP traffic). 713 4. An un-sequenced channel for data traffic insensitive to packet 714 order. 716 These channels should be carried "in band" with one another to as 717 much of a degree as is reasonably possible on a PSN. 719 In some cases there is a need to synchronize some CE events with the 720 data carried over a PW. This is especially the case with TDM circuits 721 (e.g., on-hook/off-hook events in PSTN switches). 723 Bearer channel types not needed by the supported PWs need not be 724 included in an implementation. 726 5.1.3. Quality of Service Considerations 728 Where possible, it is desirable to employ mechanisms to provide PW 729 Quality of Service (QoS) support over PSNs. Specification of a QoS 730 framework common to all PW Service types needs further investigation. 732 5.2 Payload independent PW Encapsulation Layers 734 Two PWE3 Encapsulation Sub-layers provide a common service to all 735 payload types: Sequencing and Timing. These services are optional and 736 are only used if needed by a particular PW instance. If the service 737 is not needed, the associated header may be omitted in order to 738 conserve processing and network resources. 740 There will be instances where a specific payload type will be 741 required to be transported with or without sequence and/or real-time 742 support. For example, an invariant of frame relay transport is the 743 preservation of packet order. However, where the frame relay service 744 is itself only being used to carry IP, it may be desirable to relax 745 that constraint in return for reduced per-packet processing cost. 747 The guiding principle is that, where possible an existing IETF 748 protocol should be used to provide these services. Where a suitable 749 protocol is not available, the existing protocol should be extended 750 to meet the PWE3 requirements, thereby making that protocol available 751 for other IETF uses. In the particular case of timing, more than one 752 general method may be necessary to provide for the full scope of 753 payload requirements. 755 5.2.1. Sequencing 757 The sequencing function provides three services: frame ordering, 758 frame duplication detection and frame loss detection. These are 759 invariant properties of a physical wire. Support for sequencing 760 depends on the payload type, and may be omitted if not needed. 762 The size of the sequence number space depends on the speed of the 763 emulated service, and the maximum time of the transient conditions in 764 the PSN. A sequence number space greater than 2^16-1 may therefore be 765 needed. 767 5.2.1.1 Frame Ordering 769 When packets carrying the PW PDUs traverse a PSN, they may arrive out 770 of order at the destination PE. For some services, the frames 771 (control frames, data frames, or both control and data frames) must 772 be delivered in order. For such services, some mechanism must be 773 provided for ensuring in-order delivery. Providing a sequence number 774 in the PW header for each packet is one possible approach to out-of- 775 sequence detection. Alternatively it can be noted that sequencing is 776 a sub-set of the problem of delivering timed packets, and that a 777 single combined mechanism such as [RTP] may be employed. 779 There are two possible misordering strategies: 781 o Drop miss-ordered PW PDUs. 783 o Try to sort PW PDUs into the correct order. 785 The choice of strategy will depend on: 787 o How critical the loss of packets is to the operation of 788 the PW (e.g. the acceptable bit error rate). 790 o The speeds of the PW and PSN. 792 o The acceptable delay (since delay must be introduced to reorder) 794 o The incidence of misordering. 796 5.2.1.2 Frame Duplication Detection 798 In rare cases, packets traversing a PW may be duplicated by the 799 underlying PSN. For some services, frame duplication is not 800 acceptable. For such services, some mechanism must be provided to 801 ensure that duplicated frames will not be delivered to the 802 destination CE. The mechanism may or may not be the same as the 803 mechanism used to ensure in-order frame delivery. 805 5.2.1.3 Frame Loss Detection 807 A destination PE can determine whether a frame has been lost by 808 tracking the sequence numbers of the received PW PDUs. 810 In some instances, a destination PE will have to assume that a PW PDU 811 is lost, if it fails to arrive within a certain time. If a PW PDU, 812 that has been processed as lost, subsequently arrives, the 813 destination PE must discard it. 815 5.2.2. Timing 817 A number of native services have timing expectations based on the 818 characteristics of the networks that they were designed to travel 819 over, and it can be necessary for the emulated service to duplicate 820 these network characteristics as closely as possible, e.g. in 821 delivering traffic with the same jitter, bit-rate and timing 822 characteristics as it was sent. 824 In such cases, it is necessary for the receiving PE to play out the 825 native traffic as it was received at the sending PE. This relies on 826 timing information sent between the two PEs. 828 The Timing Sub-layer must therefore support two timing functions: 829 clock recovery and timed payload delivery. A particular payload type 830 may require either or both of these services. 832 5.2.1.1 Clock Recovery 834 Clock recovery is the extraction of output transmission bit timing 835 information from the delivered packet stream, and requires a phase- 836 locking mechanism. A physical wire provides this naturally, but it is 837 a relatively complex task to extract this from a highly jittered 838 source such as packet stream. It is therefore desirable that an 839 existing real-time protocol such as [RTP] be used for this purpose, 840 unless it can be shown that this is unsuitable for a particular 841 payload type. 843 5.2.1.2 Timed delivery 845 Timed delivery is the delivery of non-contiguous PW PDUs to the PW 846 output interface with a constant phase-shift relative to the input 847 interface. The timing of the delivery may be relative to a clock 848 derived from the packet stream via clock recovery, or via an external 849 clock. 851 5.3 Instantiation of the Protocol Layers 853 This document does not address the detailed mapping of the Protocol 854 Layering model to existing or future IETF standards. 856 The instantiation of the logical Protocol Layering model of Figure 7 857 should, where possible, use existing IETF standards and common work 858 in progress. Where such protocols do not exist, the goal should be to 859 call for the design of components that have the wider application 860 within the IETF. 862 6. PSN Tunnel Layer 864 PWE3 places three service requirements on the underlying PSN: 866 o Multiplexing 867 o Segmentation and Reassembly 868 o Length and Delivery 870 6.1 Multiplexing 872 The purpose of the PSN Tunnel Layer is to allow multiple PWs to 873 originate and terminate at a single interface address within a PE. 874 This minimizes complexity and conserves resources. 876 If a service in its native form is capable of grouping multiple 877 circuits into a "trunk", e.g. multiple ATM VCs in a VP, multiple 878 Ethernet VLANs in a port, or Multiple DS0 services within a T1 or E1, 879 then a single PW may connect two end-trunks. 881 6.2 Segmentation and Reassembly 883 It is desirable to avoid the processing and storage overhead of 884 packet segmentation and reassembly (SAR). One way to do this is to 885 set the MTU of the links between the CEs and the corresponding PEs to 886 a value smaller than (PW_Path_MTU - PW_header - PSN_tunnel_header), 887 if that is possible. If segmentation cannot be completely avoided at 888 an encapsulating PE (because, for example, the length of a packet 889 after encapsulation would exceed the PW_Path_MTU), the PDU may be 890 dropped. In this case, the management plane of the encapsulating PE 891 may be notified. Alternatively the SAR mechanism in the underlying 892 PSN may be used. 894 If the length of a L2/L1 frame, restored from a PW PDU, exceeds the 895 MTU of the destination PWES, it must be dropped. In this case, the 896 management plane of the destination PE may be notified. 898 6.3 Length and Delivery 900 PDU length and delivery is the function of the PSN Layer. Where a 901 length service is not provided by the underlying PSN, this becomes a 902 requirement of the PSN Convergence Layer. 904 The three PSN types within the scope of the IETF are IPv4, IPv6 and 905 MPLS. IPv4 and IPv6 both provide the necessary switching, length and 906 fragmentation services needed to support all IETF specified Transport 907 protocols. When the PSN is IPv4 or IPv6, no PSN Convergence Layer is 908 needed. 910 MPLS provides a switching service, but does not provide length or 911 fragmentation information. When MPLS is used as the PSN, a suitable 912 convergence layer providing length and fragmentation services is 913 needed. The definition of this length and fragmentation service is 914 outside the scope of PWE3, and should be undertaken by the MPLS WG. 916 7. Control Plane 918 This section describes PWE3 control plane services. 920 7.1 Set-up or Teardown of Pseudo-Wires 922 A PW must be set-up before an emulated service can be established, 923 and must be torn down when an emulated service is no longer needed. 925 Set-up or teardown of a PW can be triggered by a CLI command from the 926 management plane of a PE, or by signaling (i.e., set-up or teardown) 927 of a PWES, e.g., an ATM SVC. 929 During the set-up process, the PEs need to exchange some information 930 (i.e., learn each others' capabilities). The tunneling control 931 protocol may be extended to provide mechanisms to enable the PEs to 932 exchange all necessary information on behalf of the PW. 934 Manual configuration of PWs can be considered a special kind of 935 signaling, and is explicitly allowed. 937 7.2 Status Monitoring 939 Some native services have mechanisms for status monitoring. For 940 example, ATM supports OAM for this purpose. For such services, the 941 corresponding emulated services must specify how to perform status 942 monitoring. 944 7.3 Notification of Pseudo-wire Status Changes 946 7.3.1. Pseudo-wire Up/Down Notification 948 If a native service is bi-directional, the corresponding emulated 949 service can only be signaled up when the associated PWs, and PSN 950 tunnels if any, are functional in both directions. 952 Because the two CEs of an emulated service are not adjacent, a 953 failure may occur at a place such that one or both physical links 954 between the CEs and PEs remain up. For example in Figure 1, if the 955 physical link between CE1 and PE1 fails, the physical link between 956 CE2 and PE2 will not be affected and will remain up. Unless CE2 is 957 notified about the remote failure, it will continue to send traffic 958 over the emulated service to CE1. Such traffic will be discarded at 959 PE1. Some native services have failure notification so that when the 960 services fail, both CEs will be notified. For such native services, 961 the corresponding PWE3 service must provide a failure notification 962 mechanism. 964 Similarly, if a native service has notification mechanisms so that 965 when a network failure is fixed, all the affected services will 966 change status from "Down" to "Up", the corresponding emulated service 967 must provide a similar mechanism for doing so. 969 These mechanisms may already be built into the tunneling protocol. 970 For example the L2TP control protocol has this capability and LDP has 971 the ability to withdraw the corresponding MPLS label. 973 7.3.2. Misconnection and Payload Type Mismatch 975 With PWE3, misconnection and payload type mismatch can occur. If a 976 misconnection occurs it can breach the integrity of the system. If a 977 payload mismatch occurs it can disrupt the customer network. In both 978 instances, there are security concerns. 980 The services of the underlying tunneling mechanism, and its 981 associated control protocol, can be used to mitigate this. 983 This area needs further study. 985 7.3.3. Packet Loss, Corruption, and Out-of-order Delivery 987 A PW can incur packet loss, corruption, and out-of-order delivery on 988 the PSN path between the PEs. This can impact the working condition 989 of an emulated service. For some payload types, packet loss, 990 corruption, and out-of-order delivery can be mapped to a bit error on 991 the PW. If a native service has some mechanism to deal with bit 992 error, the corresponding PWE3 service should provide a similar 993 mechanism. 995 7.3.4. Other Status Notification 997 A PWE3 approach may provide a mechanism for other status 998 notification, if any. 1000 7.3.5. Collective Status Notification 1002 Status of a group of emulated services may be affected identically by 1003 a single network incidence. For example, when the physical link 1004 between a CE and a PE fails, all the emulated services that go 1005 through that link will fail. It is likely that there exists a group 1006 of emulated services which all terminate at a remote CE. (There can 1007 be multiple such CEs). Therefore, it is desirable that a single 1008 notification message be used to notify failure of the whole group of 1009 emulated services. 1011 A PWE3 approach may provide some mechanism for notifying status 1012 changes of a group of emulated circuits. One possible approach is to 1013 associate each emulated service with a group ID when the PW for that 1014 emulated service is set-up. Multiple emulated services can then be 1015 grouped by associating them with identical group ID. In status 1016 notification, that group ID can be used to refer all the emulated 1017 services in that group. 1019 This should be a mechanism provided by the underlying tunneling 1020 protocol. 1022 7.4 Keep-alive 1024 If a native service has a keep-alive mechanism, the corresponding 1025 emulated service needs to use a mechanism to propagate this across 1026 the PW. One strategy is to transparently transport keep-alive 1027 messages over the PW. Another strategy is to piggy-back them on the 1028 tunnel signaling mechanism. The principle of minimum intervention 1029 implies that the former strategy is the preferred approach. 1031 7.5 Handling Control Messages of the Native Services 1033 Some native services use control messages for maintaining the 1034 circuits. These control messages may be in-band, e.g. Ethernet flow 1035 control or ATM performance management, or out-of-band, e.g. the 1036 signaling VC of an ATM VP. 1038 From the principle of minimum intervention, it is desirable that the 1039 PEs participate as little as possible in the signaling and 1040 maintenance of the native services. 1042 If control messages are passed through, it may be desirable to send 1043 them using a reliable channel provided by the PSN tunnel layer. See 1044 Bearer Channel Types. 1046 8. IANA considerations 1048 There are no IANA considerations for this document. 1050 9. Security Considerations 1052 PWE3 provides no means of protecting the contents or delivery of the 1053 native data units. PWE3 may, however, leverage security mechanisms 1054 provided by the PSN Tunnel Layer. This section addresses the PWE3 1055 vulnerabilities, and the mechanisms available to protect the native 1056 services. 1058 Vulnerabilities exist at the tunnel end-point, the PW Encapsulation 1059 Layer, and the payload of the native service. 1061 The security aspects of PWE3 need further study. 1063 9.1 Tunnel End-Point Security 1065 Protection mechanisms must be considered for the tunnel end-point in 1066 order to avoid denial-of-service attacks to the native service, and 1067 to prevent spoofing of the native data units. Exploitation of 1068 vulnerabilities from within the PSN may be directed to the tunnel 1069 end-point such that PSN tunnel services are disrupted. Controlling 1070 PSN access to the tunnel end-point may protect against this. 1072 By restricting Tunnel End-point access to legitimate remote PE 1073 sources of traffic destined for the Tunnel End-point, the PE may 1074 reject traffic that interferes with the PSN tunnel services. 1076 9.2 Validation of PW Encapsulation 1078 Protection mechanisms must address the spoofing of tunneled PW data. 1079 The validation of traffic addressed to the tunnel end-point is 1080 paramount in ensuring integrity of PW encapsulation. Security 1081 protocols such as IPSec may be used by the PSN Tunnel Layer in order 1082 to maintain the integrity of the PW by authenticating data between 1083 the PE Tunnel End-points. IPSec may provide authentication, 1084 integrity, non-repudiation, and confidentiality of data transferred 1085 between two PE. It cannot provide the equivalent services to the 1086 native service. 1088 Based on the type of data being transferred, the PW may indicate to 1089 the PSN Tunnel Layer that enhanced security services are required. 1090 The PSN Tunnel Layer may define multiple protection profiles based on 1091 the requirements of the PW emulated service. CE-to-CE signaling and 1092 control events emulated by the PW and some data types may require 1093 additional protection mechanisms. Alternatively, the Tunnel End-point 1094 may use peer authentication for every PSN packet to prevent spoofed 1095 native data units from being sent to the destination CE. 1097 9.3 End to End Security 1099 Protection of the PW encapsulated data stream between PE should not 1100 be considered equivalent to end-to-end security since the CE-PE 1101 interface and the PE processing element remains unprotected. PW 1102 service emulation does not preclude the application of additional 1103 security mechanisms such as IPSec that are implemented end-to-end. 1104 Likewise, end-to-end security mechanisms applied in the native 1105 service do not protect the PSN tunnel services provided by the PE for 1106 PW encapsulation. 1108 Acknowledgments 1110 We thank Sasha Vainshtein for his work on Native Service Processing 1111 and advice on bit-stream over PW services. We thank Scott Wainner and 1112 Stephen Casner for their comments and contributions. 1114 References 1116 Internet-drafts are works in progress available from 1117 1119 [PPPoL2TP] PPP Tunneling Using Layer Two Tunneling Protocol, 1120 J Lau et al. , 1121 work in progress. 1123 [RTP] RFC-1889: A Transport Protocol for Real-Time Applications, H. 1124 Schulzrinne et al. 1126 Authors' Addresses 1128 Stewart Bryant 1129 Cisco Systems, 1130 4, The Square, 1131 Stockley Park, 1132 Uxbridge UB11 1BL, Email: stbryant@cisco.com 1133 United Kingdom. Phone: +44-20-8756-8828 1135 Danny McPherson Email: danny@tcb.net 1136 TCB. Phone: +1-303-470-9257 1138 Lloyd Wood 1139 Cisco Systems, 1140 4, The Square, 1141 Stockley Park, 1142 Uxbridge UB11 1BL, Email: lwood@cisco.com 1143 United Kingdom. Phone:+44-20-8734-4236 1145 W. Mark Townsley 1146 Cisco Systems, 1147 7025 Kit Creek Road, 1148 PO Box 14987, 1149 Research Triangle Park, Email: mark@townsley.net 1150 NC 27709 1152 Full copyright statement 1154 Copyright (C) The Internet Society (2002). All Rights Reserved. 1156 This document and translations of it may be copied and furnished to 1157 others, and derivative works that comment on or otherwise explain it 1158 or assist in its implementation may be prepared, copied, published 1159 and distributed, in whole or in part, without restriction of any 1160 kind, provided that the above copyright notice and this paragraph are 1161 included on all such copies and derivative works. However, this 1162 document itself may not be modified in any way, such as by removing 1163 the copyright notice or references to the Internet Society or other 1164 Internet organizations, except as needed for the purpose of 1165 developing Internet standards in which case the procedures for 1166 copyrights defined in the Internet Standards process must be 1167 followed, or as required to translate it into languages other than 1168 English. 1170 The limited permissions granted above are perpetual and will not be 1171 revoked by the Internet Society or its successors or assigns. 1173 This document and the information contained herein is provided on an 1174 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1175 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1176 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1177 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1178 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.