Internet Draft Stewart Bryant Document: Lloyd Wood Expires: August 2002 Mark Townsley cisco Systems Ltd Danny McPherson TCB February 2002 Protocol Layering in PWE3 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft proposes a unified protocol layering approach for pseudo- wire emulation edge-to-edge (PWE3). It adopts the principle that PWE3 should be a single transport type operating over a common packet- switched network (PSN) service model using, wherever possible, existing IETF protocols. The draft defines the protocol layering model for pseudo-wires (PW), guidelines for the design of a specific encapsulation type, and the service requirements of the underlying PSN tunneling mechanism. Bryant, et al. Informational [Page 1] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 Table of Contents 1. Introduction............................................. 3 2. Terminology.............................................. 3 3. Architecture of Pseudo-wires............................. 5 3.1 Network Reference Model.............................. 5 3.2 Native Service Processing............................ 5 3.3 Maintenance Reference Model.......................... 9 3.4 Protocol Stack Reference Model....................... 10 3.5 NSP Extension to Protocol Stack Reference Model...... 11 4. Protocol Layering Model.................................. 12 4.1 Protocol Layers...................................... 13 4.2 Domain of PWE3....................................... 14 4.3 Payload Types........................................ 15 5. PW Encapsulation......................................... 16 5.1 Payload Convergence Layer............................ 17 5.2 Payload independent PW Encapsulation Layers.......... 18 5.3 Instantiation of the Protocol Layers................. 21 6. PSN Tunnel Layer......................................... 21 6.1 Multiplexing......................................... 21 6.2 Segmentation and Reassembly.......................... 21 6.3 Length and Delivery.................................. 22 7. Control Plane............................................ 22 7.1 Set-up or Teardown of Pseudo-Wires................... 22 7.2 Status Monitoring.................................... 23 7.3 Notification of Pseudo-wire Status Changes........... 23 7.4 Keep-alive........................................... 24 7.5 Handling Control Messages of the Native Services..... 25 8. IANA considerations...................................... 25 9. Security Considerations.................................. 25 9.1 Tunnel End-Point Security............................ 25 9.2 Validation of PW Encapsulation....................... 26 9.3 End to End Security.................................. 26 Bryant, et al. Informational [Page 2] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 1. Introduction This document presents a unified protocol layering approach for pseudo-wire emulation edge-to-edge (PWE3). It adopts the principle that PWE3 should be a single transport type operating over a common packet-switched network (PSN) service model using, wherever possible, existing IETF protocols. This document defines the protocol layering model for pseudo-wires (PW), guidelines for the design of a specific encapsulation type, and the service requirements of the underlying PSN tunneling mechanism. 2. Terminology This document uses the following definition of terms. A number of these terms are further clarified by reference to Figure 1. CE-bound The traffic direction where PW-PDUs are received on a PW via the PSN, decapsulated to retrieve the emulated service, and then sent to the destination CE. CE Signaling Messages sent and received by the CEs control plane. It may be desirable or even necessary for the PE to participate in or monitor this signaling in order to effectively emulate the service. Customer Edge (CE) A device where one end of a service originates and terminates. The CE is not aware that it is using an emulated service rather than a native service. Inter-working Interactions between networks, between end systems, or between parts thereof, with the aim of providing a functional entity capable of supporting an end-to-end communication. Inter-working A function that facilitates inter-working Function (IWF) between two dissimilar networks. NSP may perform the IWF function. Native Service Processing of the data received by the PE Processing (NSP) from the CE before presentation to the PW for transmission across the core. Bryant, et al. Informational [Page 3] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 Packet Switched A network using IP or MPLS as the mechanism Network (PSN) of packet forwarding. Protocol Data The unit of data output to, or received Unit (PDU) from, the network by a protocol layer. Provider Edge (PE) A device that provides PWE3 to a CE. PE-bound The traffic direction where information from a CE is adapted to a PW, and PW-PDUs are sent into the PSN. PE/PW Maintenance Used by the PEs to set up, maintain and tear down the PW. It may be coupled with CE Signaling in order to effectively manage the PW. Pseudo Wire (PW) A connection between two PEs carried over a PSN. PW End Service The interface between a PE and a CE. This (PWES) can be a physical interface like a T1 or Ethernet, or a virtual interface like a VC or VLAN. Pseudo Wire A mechanism that emulates the essential Emulation Edge to attributes of service (such as a T1 leased Edge (PWE3) line or frame relay) over a PSN. Pseudo Wire PDU A PDU sent on the PW that contains all of the data and control information necessary to emulate the desired service. PSN Tunnel A tunnel across a PSN inside which one or more PWs can be carried. PSN Tunnel Used to set up, maintain and tear down the Signaling underlying PSN tunnel. SAR Segmentation and reassembly. Tunnel A method of transparently carrying information over a network. Bryant, et al. Informational [Page 4] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 3. Architecture of Pseudo-wires This section describes the PWE3 architectural model. 3.1 Network Reference Model Figure 1 illustrates the network reference model for PWs. |<-------------- Emulated Service ---------------->| | | | |<------- Pseudo Wire ------>| | | | | | | | |<-- PSN Tunnel -->| | | | PW End V V V V PW End | V Service +----+ +----+ Service V +-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1.............|----------| | | CE1 | | | | | | | | CE2 | | |----------|............PW2.............|----------| | +-----+ ^ | | |==================| | | ^ +-----+ ^ | +----+ +----+ | | ^ | | Provider Edge 1 Provider Edge 2 | | | | | | Customer | | Customer Edge 1 | | Edge 2 | | | | native service native service Figure 1: PWE3 Network Reference Model The two PEs (PE1 and PE2) need to provide one or more PWs on behalf of their client CEs (CE1 and CE2) to enable them to communicate over the PSN. A PSN tunnel is established to provide a data path for the PW that is transparent to the network core. Native data units (bits, cells or packets) presented at the PW End Service (PWES) are encapsulated in a PW-PDU and carried across the underlying network via the PSN tunnel. The PEs perform the necessary encapsulation, decapsulation, sequencing, timing and any other functions required by the PW service. 3.2 Native Service Processing In some applications, there is a need to perform operations on the native data units received from the CE (both payload and control information) before it is transmitted across the PW by the PE. Examples include Ethernet bridging, SONET cross-connect, translation Bryant, et al. Informational [Page 5] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 of locally significant identifiers such as VCI/VPI, or translation to another service type. These operations could be carried out in external equipment, and the processed data sent to the PE over one or more physical interfaces. In most cases, there are cost and operational benefits in undertaking this native service processing (NSP) within the PE. This processed data is then presented to the PW via a virtual interface within the PE. It must be emphasized that this processing uses operations that are outside the scope of the PW defined here. The use of the NSP approach simplifies the design of the PW by restricting a PW to homogeneous operation. NSP is included in the reference model to provide a defined interface to this functionality. The specification of the various types of NSP is outside the scope of PWE3. Figure 2 illustrates the relationship between NSP and the network reference model for PWs. The PW may provide connectivity to a virtual interface with the PE equipment. The NSP function may apply any transformation operation (modification, injection, etc) on data as it passes between the physical interface to the CE and the virtual interface to the PW. It may also combine or split data between the physical interfaces to the CE and the virtual interface to one or more PWs. Bryant, et al. Informational [Page 6] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 PW End Service | |<------- Pseudo Wire ------>| | | | |<-- PSN Tunnel -->| | V V V V PW +-----+----+ +----+ End Service +-----+ |NSP1 | PE1|==================| PE2| | +-----+ | | | |............PW1.............|----------| | | CE1 |----| | | | | | | CE2 | | | ^ | |............PW2.............|----------| | +-----+ | | | |==================| | | ^ +-----+ | +-----+----+ +----+ | | | ^ | | | | | | | |<------- Emulated Service ------->| | | | | | Virtual physical | | termination | | ^ | CE1 native | CE2 native service | service | CE2 native service Figure 2: NSP within the PWE3 Network Reference Model Figure 2 shows the inter-working of one PE with NSP, and a second without this functionality. This is a useful reference point because it emphasises that the functional interface between NSP and the PW is that represented by a physical interface carrying the service. This effectively defines the necessary inter-working specification. The operation of a system in which both PEs include NSP is also supported. The operation of a system in which the NSP functionality includes terminating the data-link, and applying network layer processing to the payload, is also supported. Bryant, et al. Informational [Page 7] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 Internally, a PE with NSP has the following functional structure: +----------------------------------------+ | PE Device | Single +----------------------------------------+ PWES | | | Single | PW Instance <--------->o NSP O<-->+ PW IWF X<===========> | | | Instance | | | | | +----------------------------------------+ Figure 3a: A simple point-to-point service +----------------------------------------+ | PE Device | +----------------------------------------+ | | | Single | PW Instance | O<-->+ PW IWF X<===========> | | | Instance | | | |-----------------| Single | O<-->+ Single | PW Instance PWES | | | PW IWF X<===========> <--------->o NSP | | Instance | | | |-----------------| | | | ... | | | |-----------------| | O<-->+ Single | PW Instance | | | PW IWF X<===========> | | | Instance | +----------------------------------------+ Figure 3b: A point-to-multipoint service Bryant, et al. Informational [Page 8] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 +----------------------------------------+ | PE Device | |----------------------------------------| Multiple | | | Single | PW Instance PWES | O<..>+ PW IWF X<===========> <--------->o | | Instance | | | |-----------------| <--------->o O<..>+ Single | PW Instance | | | PW IWF X<===========> <--------->o NSP | | Instance | | | |-----------------| <--------->o | | ... | ... | | |-----------------| | O<..>+ Single | PW Instance <--------->o | | PW IWF X<===========> | | | Instance | +----------------------------------------+ Figure 3c: A full switch/bridge/cross-connect multipoint-multipoint service Notation: o A physical CE-bound PE port O An NSP virtual interface to a PW IWF instance. + A PW IWF instance interface to the NSP. X A PE PSN-bound port. Figure 3: PE internals showing NSP 3.3 Maintenance Reference Model Figure 4 illustrates the maintenance reference model for PWs. Bryant, et al. Informational [Page 9] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 |<------- CE (end-to-end) Signaling ------>| | |<---- PW/PE Maintenance ----->| | | | |<-- PSN Tunnel -->| | | | | | Signaling | | | | V V (out of scope) V V | v +-----+ +-----+ v +-----+ | PE1 |==================| PE2 | +-----+ | |-----|.............PW1..............|-----| | | CE1 | | | | | | CE2 | | |-----|.............PW2..............|-----| | +-----+ | |==================| | +-----+ +-----+ +-----+ Customer Provider Provider Customer Edge 1 Edge 1 Edge 2 Edge 2 Figure 4: PWE3 Maintenance Reference Model The following signaling mechanisms are required: o The CE (end-to-end) signaling is between the CEs. This signaling can include frame relay PVC status signaling, ATM SVC signaling, etc. o The PW/PE Maintenance is used between the PEs (or NSPs) to set up, maintain and tear down PWs, including any required coordination of parameters. o The PSN Tunnel signaling controls the underlying PSN. Examples are L2TP control protocol, or MPLS LDP. This type of signaling is not within the scope of PWE3. 3.4 Protocol Stack Reference Model Figure 5 illustrates the protocol stack reference model for PWs. Bryant, et al. Informational [Page 10] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 +----------------+ +----------------+ |Emulated Service| |Emulated Service| |(e.g. TDM, ATM) |<===== Emulated Service ====>|(e.g. TDM, ATM) | +----------------+ +----------------+ | Payload | | Payload | | Encapsulation |<======= Pseudo Wire =======>| Encapsulation | +----------------+ +----------------+ | PSN Tunnel, |<======== PSN Tunnel =======>| PSN Tunnel, | | PSN & Physical | | PSN & Physical | | Layers | | Layers | +-------+--------+ _____________ +--------+-------+ | / \ | +===============/ PSN \===============+ \ / \_____________/ Figure 5: PWE3 Protocol Stack Reference Model The PW provides the CE with what appears to be a direct physical connection to its peer at the far end. Native data units from the CE are passed through an encapsulation layer at the sending PE, and then sent over the PSN. The receiving PE removes the encapsulation and restores the payload to its native format for transmission to the destination CE. 3.5 NSP Extension to Protocol Stack Reference Model Figure 6 illustrates how the protocol stack reference model extended to include the provision of native service processing. This shows the correct placement of the physical interface relative to the CE. Bryant, et al. Informational [Page 11] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 +-----------------------------------+ | Native Service Processing | +--------------+---+----------------+ | | | Emulated | | Service | | Service | | Interface | | (TDM, ATM, | | (TDM, ATM, | | Ethernet, |<=== Emulated Service == | Ethernet, | | frame relay, | | frame relay, | | etc.) | | etc.) | +----------------+ | | | Payload | | | | Encapsulation |<==== Pseudo Wire ====== | | +----------------+ | | | PSN Tunnel, | | | | PSN & Physical |<==== PSN Tunnel ======= | | | Headers | +--------------+ +----------------+ | Physical | | Physical | +-------+------+ +-------+--------+ | | | | IP or MPLS Network | | ----- --- | | / \---/ \ | | / \ | | / \ v +=========/ PSN | To CE \ / \ --- / -----/ \-----/ Figure 6: Protocol Stack Reference Model with NSP 4. Protocol Layering Model The PWE3 protocol-layering model is intended to minimise the differences between PWs operating over different PSN types. The design of the protocol-layering model thus has the goals of making each PW definition independent of the underlying PSN, and maximizing the reuse of IETF protocol definitions. Bryant, et al. Informational [Page 12] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 4.1 Protocol Layers The logical protocol-layering model required to support a PW is expanded to provide more detail as shown in Figure 7. +---------------------------+ | Payload | +---------------------------+ | Encapsulation | <==== May be empty +---------------------------+ | PSN Tunnel | +---------------------------+ | PSN Convergence | <==== May be empty +---------------------------+ | PSN | +---------------------------+ | MAC/Data-link | +---------------------------+ | Physical | +---------------------------+ Figure 7: Logical Protocol Layering Model The payload is transported over the Encapsulation Layer. The Encapsulation Layer carries any information, not in the payload itself, that is required by the PW CE-bound PE interface to send the payload to the CE via the physical interface. If needed, this layer also provides support for real-time processing, and sequencing. The PSN Tunnel Layer provides the ability to deliver multiple PWs over a single PSN tunnel. The PSN header, MAC/Data-link and Physical Layer definitions are outside the scope of this framework. The PSN Convergence Layer provides the enhancements needed to make the PSN conform to the assumed PSN service requirement. This layer therefore provides a consistent interface to the PW, making the PW independent of the PSN type. If the PSN already meets the service requirements, this layer is empty. The PSN can be any PSN type defined by the IETF. These are currently IPv4, IPv6 and MPLS. Bryant, et al. Informational [Page 13] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 4.2 Domain of PWE3 PWE3 defines the Encapsulation Layer, the method of carrying various payload types, and the interface to the PSN Tunnel Layer. It is expected that the other layers will be provided by tunneling methods such as L2TP or MPLS over the PSN. 4.3 Payload Types The payload is classified into the following generic types of native data unit: o Bit-stream o Structured bit-stream o Cell o Packet Within these generic types there are specific service types. For example: Generic Payload Type PW Service -------------------- ---------- Bit-stream SONET, TDM (e.g. DS1, DS3, E1). Structured bit-stream SONET, TDM. Cell ATM. Packet Ethernet (all types), HDLC, frame relay, ATM AAL5 PDU. 4.3.1. Bit-stream A bit-stream payload is created by capturing, transporting and replaying the bit pattern on the emulated wire, without taking advantage of any structure that, on inspection, may be visible within the relayed traffic. The Encapsulation Layer submits an identical number of bits for transport in each PW-PDU. This service will require sequencing and real-time support. 4.3.2. Structured bit-stream A bit-stream payload is created by using some knowledge of the underlying structure of the bit-stream to capture, transport and replay the bit pattern on the emulated wire. Bryant, et al. Informational [Page 14] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 Two important points distinguish structured and unstructured bit- streams: o Some part of the original (unstructured) bit stream is stripped by, for example, the PSN-bound direction of the NSP block. For example, in Structured SONET the section and line overhead (and, possibly, more) may be stripped. o The PW must preserve the structure across the PSN so that the CE-bound NSP block can insert it correctly into the reconstructed unstructured bit stream. The Encapsulation Layer may also perform silence/idle suppression or similar a compression on a structured bit stream. Structured bit streams are distinguished from cells in that the structures may be too long to be carried in a single packet (i.e. structured SONET). Note that "short" structures are undistinguishable from cells and may benefit from the use of cell encapsulations. This service will require sequencing and real-time support. 4.3.3. Cell Payload A cell payload is created by capturing, transporting and replaying groups of bits presented on the wire in a fixed-size format. The delineation of the group of bits that comprise the cell is specific to the encapsulation type. Two common examples of cell payloads are 53-octet cells carrying ATM AAL2, and the larger 188-octet DVB Transport Stream packets. To reduce PSN tunnel header overhead, multiple cells may be concatenated into a single payload. The Encapsulation Layer may consider the payload complete on the expiry of a timer, or when a fixed number of cells have been received. The benefit of concatenating multiple PDUs should be weighed against the resulting larger penalty incurred by packet loss. In some cases, it may be appropriate for the Encapsulation Layer to perform a silence suppression or a similar compression. The generic cell payload service will normally need sequence number support, and may also need real-time support. The cell generic payload service would not normally require fragmentation. The Encapsulation Layer may apply some form of compression to some of these sub-types. In some instances, the cells to be incorporated in the payload may be Bryant, et al. Informational [Page 15] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 selected by filtering them from the stream of cells presented on the wire. For example, an ATM PWE3 service may select cells based on their VCI or VPI fields. That is an NSP function, and the selection would therefore be made before the packet was presented to the PW Encapsulation Layer. 4.3.4. Packet Payload A packet payload is one that operates by capturing, transporting and replaying groups of bits of varying sizes that are presented on the wire. The delineation of the packet boundaries is encapsulation- specific. Common examples of packet payloads are HDLC and Ethernet PDUs. Typically a packet will be stripped of transmission overhead such as HDLC flags and stuffing bits before transmission over the PW. A packet payload would normally be relayed across the PW as a single unit. However, there will be cases where the combined size of the packet payload and its associated PWE3 and PSN headers exceeds the PSN path MTU. This is likely to be the case when a user is providing the service and attaching to the service provider via an Ethernet, or where nested pseudo-wires are involved. The pseudo-wire would in these cases require the use of the fragmentation support of the underlying PSN or PSN Convergence Layer. A packet payload may need sequencing and real-time support. In some instances the packet payload may be selected from the packets presented on the emulated wire on the basis of some sub-multiplexing technique. For example, one or more frame relay PDUs may be selected for transport over a particular pseudo-wire based on the frame relay Data-Link Connection Identifier (DLCI), or, in the case of Ethernet payloads, on the basis of the VLAN identifier. This is an NSP function, and this selection would therefore be made before the packet was presented to the PW Encapsulation Layer. 4.3.5. Principle of Minimum Intervention To minimise the scope of information, and to improve the efficiency of data flow through the Encapsulation Layer, the payload should, where possible, be transported as received without modification. 5. PW Encapsulation The PW Encapsulation Layer provides the necessary infrastructure to adapt the specific payload type being transported over the PW to the Bryant, et al. Informational [Page 16] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 PSN Tunneling Layer that is used to carry the PW over the PSN. The PW Encapsulation Layer consists of three sub-layers: o Payload Convergence o Sequencing o Timing The Payload Convergence Sub-layer is highly tailored to the specific payload type, but, by grouping a number of target payload types into a generic class, and then providing a single convergence sub-layer type common to the group, we achieve a reduction in the number of payload convergence sub-layer types. The provision of per-packet signalling and other out-of-band information (other than sequencing or timing) is undertaken by this layer. The Sequencing Layer and the Timing Layer provide a generic services to the Payload Convergence Layer for all payload types. 5.1 Payload Convergence Layer 5.1.1. Encapsulation The primary task of the Payload Convergence Layer is the encapsulation of the payload in PDUs. The native data units to be encapsulated may or may not contain L2 or L1 header information. This is service specific. The Payload Convergence header carries the additional information needed to replay the native data units at the CE-bound physical interface. The PSN tunnel header is not considered as part of the PW header. It should be noted that not all such information needs to be carried in the PW header of the PW PDUs. Some information (e.g. service type of a PW) can be stored as state information at the destination PE during PW set-up. 5.1.2. Bearer Channel Types The PW Encapsulation Layer and its associated signaling require one or more of the following types of channel from its underlying PSN Tunnel and PSN Layers: 1. A reliable control channel for signaling line events, status indications, and, in some exceptional cases, CE-CE events which must be translated and sent reliably between PEs. For example, this capability is needed in [PPPoL2TP], because PPP negotiation has to be split between the two ends of the Bryant, et al. Informational [Page 17] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 tunnel. PWE3 may also need this type of control channel to provide faithful emulation of complex data-link protocols. 2. A high priority, unreliable, sequenced channel. A typical use is for CE to CE signaling. "High priority" may simply be reflected via DSCP/EXP bits for priority during transit. It may also use a bit in the tunnel header itself to indicate that packets received at the PE should be processed with higher quality of service. 3. A sequenced channel for data traffic that is intolerant to packet reordering (one classification for use could be for any non-IP traffic). 4. An un-sequenced channel for data traffic insensitive to packet order. These channels should be carried "in band" with one another to as much of a degree as is reasonably possible on a PSN. In some cases there is a need to synchronize some CE events with the data carried over a PW. This is especially the case with TDM circuits (e.g., on-hook/off-hook events in PSTN switches). Bearer channel types not needed by the supported PWs need not be included in an implementation. 5.1.3. Quality of Service Considerations Where possible, it is desirable to employ mechanisms to provide PW Quality of Service (QoS) support over PSNs. Specification of a QoS framework common to all PW Service types needs further investigation. 5.2 Payload independent PW Encapsulation Layers Two PWE3 Encapsulation Sub-layers provide a common service to all payload types: Sequencing and Timing. These services are optional and are only used if needed by a particular PW instance. If the service is not needed, the associated header may be omitted in order to conserve processing and network resources. There will be instances where a specific payload type will be required to be transported with or without sequence and/or real-time support. For example, an invariant of frame relay transport is the preservation of packet order. However, where the frame relay service is itself only being used to carry IP, it may be desirable to relax that constraint in return for reduced per-packet processing cost. Bryant, et al. Informational [Page 18] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 The guiding principle is that, where possible an existing IETF protocol should be used to provide these services. Where a suitable protocol is not available, the existing protocol should be extended to meet the PWE3 requirements, thereby making that protocol available for other IETF uses. In the particular case of timing, more than one general method may be necessary to provide for the full scope of payload requirements. 5.2.1. Sequencing The sequencing function provides three services: frame ordering, frame duplication detection and frame loss detection. These are invariant properties of a physical wire. Support for sequencing depends on the payload type, and may be omitted if not needed. The size of the sequence number space depends on the speed of the emulated service, and the maximum time of the transient conditions in the PSN. A sequence number space greater than 2^16-1 may therefore be needed. 5.2.1.1 Frame Ordering When packets carrying the PW PDUs traverse a PSN, they may arrive out of order at the destination PE. For some services, the frames (control frames, data frames, or both control and data frames) must be delivered in order. For such services, some mechanism must be provided for ensuring in-order delivery. Providing a sequence number in the PW header for each packet is one possible approach to out-of- sequence detection. Alternatively it can be noted that sequencing is a sub-set of the problem of delivering timed packets, and that a single combined mechanism such as [RTP] may be employed. There are two possible misordering strategies: o Drop miss-ordered PW PDUs. o Try to sort PW PDUs into the correct order. The choice of strategy will depend on: o How critical the loss of packets is to the operation of the PW (e.g. the acceptable bit error rate). o The speeds of the PW and PSN. o The acceptable delay (since delay must be introduced to reorder) o The incidence of misordering. Bryant, et al. Informational [Page 19] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 5.2.1.2 Frame Duplication Detection In rare cases, packets traversing a PW may be duplicated by the underlying PSN. For some services, frame duplication is not acceptable. For such services, some mechanism must be provided to ensure that duplicated frames will not be delivered to the destination CE. The mechanism may or may not be the same as the mechanism used to ensure in-order frame delivery. 5.2.1.3 Frame Loss Detection A destination PE can determine whether a frame has been lost by tracking the sequence numbers of the received PW PDUs. In some instances, a destination PE will have to assume that a PW PDU is lost, if it fails to arrive within a certain time. If a PW PDU, that has been processed as lost, subsequently arrives, the destination PE must discard it. 5.2.2. Timing A number of native services have timing expectations based on the characteristics of the networks that they were designed to travel over, and it can be necessary for the emulated service to duplicate these network characteristics as closely as possible, e.g. in delivering traffic with the same jitter, bit-rate and timing characteristics as it was sent. In such cases, it is necessary for the receiving PE to play out the native traffic as it was received at the sending PE. This relies on timing information sent between the two PEs. The Timing Sub-layer must therefore support two timing functions: clock recovery and timed payload delivery. A particular payload type may require either or both of these services. 5.2.1.1 Clock Recovery Clock recovery is the extraction of output transmission bit timing information from the delivered packet stream, and requires a phase- locking mechanism. A physical wire provides this naturally, but it is a relatively complex task to extract this from a highly jittered source such as packet stream. It is therefore desirable that an existing real-time protocol such as [RTP] be used for this purpose, unless it can be shown that this is unsuitable for a particular payload type. Bryant, et al. Informational [Page 20] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 5.2.1.2 Timed delivery Timed delivery is the delivery of non-contiguous PW PDUs to the PW output interface with a constant phase-shift relative to the input interface. The timing of the delivery may be relative to a clock derived from the packet stream via clock recovery, or via an external clock. 5.3 Instantiation of the Protocol Layers This document does not address the detailed mapping of the Protocol Layering model to existing or future IETF standards. The instantiation of the logical Protocol Layering model of Figure 7 should, where possible, use existing IETF standards and common work in progress. Where such protocols do not exist, the goal should be to call for the design of components that have the wider application within the IETF. 6. PSN Tunnel Layer PWE3 places three service requirements on the underlying PSN: o Multiplexing o Segmentation and Reassembly o Length and Delivery 6.1 Multiplexing The purpose of the PSN Tunnel Layer is to allow multiple PWs to originate and terminate at a single interface address within a PE. This minimizes complexity and conserves resources. If a service in its native form is capable of grouping multiple circuits into a "trunk", e.g. multiple ATM VCs in a VP, multiple Ethernet VLANs in a port, or Multiple DS0 services within a T1 or E1, then a single PW may connect two end-trunks. 6.2 Segmentation and Reassembly It is desirable to avoid the processing and storage overhead of packet segmentation and reassembly (SAR). One way to do this is to set the MTU of the links between the CEs and the corresponding PEs to a value smaller than (PW_Path_MTU - PW_header - PSN_tunnel_header), Bryant, et al. Informational [Page 21] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 if that is possible. If segmentation cannot be completely avoided at an encapsulating PE (because, for example, the length of a packet after encapsulation would exceed the PW_Path_MTU), the PDU may be dropped. In this case, the management plane of the encapsulating PE may be notified. Alternatively the SAR mechanism in the underlying PSN may be used. If the length of a L2/L1 frame, restored from a PW PDU, exceeds the MTU of the destination PWES, it must be dropped. In this case, the management plane of the destination PE may be notified. 6.3 Length and Delivery PDU length and delivery is the function of the PSN Layer. Where a length service is not provided by the underlying PSN, this becomes a requirement of the PSN Convergence Layer. The three PSN types within the scope of the IETF are IPv4, IPv6 and MPLS. IPv4 and IPv6 both provide the necessary switching, length and fragmentation services needed to support all IETF specified Transport protocols. When the PSN is IPv4 or IPv6, no PSN Convergence Layer is needed. MPLS provides a switching service, but does not provide length or fragmentation information. When MPLS is used as the PSN, a suitable convergence layer providing length and fragmentation services is needed. The definition of this length and fragmentation service is outside the scope of PWE3, and should be undertaken by the MPLS WG. 7. Control Plane This section describes PWE3 control plane services. 7.1 Set-up or Teardown of Pseudo-Wires A PW must be set-up before an emulated service can be established, and must be torn down when an emulated service is no longer needed. Set-up or teardown of a PW can be triggered by a CLI command from the management plane of a PE, or by signaling (i.e., set-up or teardown) of a PWES, e.g., an ATM SVC. During the set-up process, the PEs need to exchange some information (i.e., learn each others' capabilities). The tunneling control Bryant, et al. Informational [Page 22] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 protocol may be extended to provide mechanisms to enable the PEs to exchange all necessary information on behalf of the PW. Manual configuration of PWs can be considered a special kind of signaling, and is explicitly allowed. 7.2 Status Monitoring Some native services have mechanisms for status monitoring. For example, ATM supports OAM for this purpose. For such services, the corresponding emulated services must specify how to perform status monitoring. 7.3 Notification of Pseudo-wire Status Changes 7.3.1. Pseudo-wire Up/Down Notification If a native service is bi-directional, the corresponding emulated service can only be signaled up when the associated PWs, and PSN tunnels if any, are functional in both directions. Because the two CEs of an emulated service are not adjacent, a failure may occur at a place such that one or both physical links between the CEs and PEs remain up. For example in Figure 1, if the physical link between CE1 and PE1 fails, the physical link between CE2 and PE2 will not be affected and will remain up. Unless CE2 is notified about the remote failure, it will continue to send traffic over the emulated service to CE1. Such traffic will be discarded at PE1. Some native services have failure notification so that when the services fail, both CEs will be notified. For such native services, the corresponding PWE3 service must provide a failure notification mechanism. Similarly, if a native service has notification mechanisms so that when a network failure is fixed, all the affected services will change status from "Down" to "Up", the corresponding emulated service must provide a similar mechanism for doing so. These mechanisms may already be built into the tunneling protocol. For example the L2TP control protocol has this capability and LDP has the ability to withdraw the corresponding MPLS label. 7.3.2. Misconnection and Payload Type Mismatch With PWE3, misconnection and payload type mismatch can occur. If a misconnection occurs it can breach the integrity of the system. If a payload mismatch occurs it can disrupt the customer network. In both instances, there are security concerns. Bryant, et al. Informational [Page 23] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 The services of the underlying tunneling mechanism, and its associated control protocol, can be used to mitigate this. This area needs further study. 7.3.3. Packet Loss, Corruption, and Out-of-order Delivery A PW can incur packet loss, corruption, and out-of-order delivery on the PSN path between the PEs. This can impact the working condition of an emulated service. For some payload types, packet loss, corruption, and out-of-order delivery can be mapped to a bit error on the PW. If a native service has some mechanism to deal with bit error, the corresponding PWE3 service should provide a similar mechanism. 7.3.4. Other Status Notification A PWE3 approach may provide a mechanism for other status notification, if any. 7.3.5. Collective Status Notification Status of a group of emulated services may be affected identically by a single network incidence. For example, when the physical link between a CE and a PE fails, all the emulated services that go through that link will fail. It is likely that there exists a group of emulated services which all terminate at a remote CE. (There can be multiple such CEs). Therefore, it is desirable that a single notification message be used to notify failure of the whole group of emulated services. A PWE3 approach may provide some mechanism for notifying status changes of a group of emulated circuits. One possible approach is to associate each emulated service with a group ID when the PW for that emulated service is set-up. Multiple emulated services can then be grouped by associating them with identical group ID. In status notification, that group ID can be used to refer all the emulated services in that group. This should be a mechanism provided by the underlying tunneling protocol. 7.4 Keep-alive If a native service has a keep-alive mechanism, the corresponding emulated service needs to use a mechanism to propagate this across the PW. One strategy is to transparently transport keep-alive messages over the PW. Another strategy is to piggy-back them on the Bryant, et al. Informational [Page 24] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 tunnel signaling mechanism. The principle of minimum intervention implies that the former strategy is the preferred approach. 7.5 Handling Control Messages of the Native Services Some native services use control messages for maintaining the circuits. These control messages may be in-band, e.g. Ethernet flow control or ATM performance management, or out-of-band, e.g. the signaling VC of an ATM VP. From the principle of minimum intervention, it is desirable that the PEs participate as little as possible in the signaling and maintenance of the native services. If control messages are passed through, it may be desirable to send them using a reliable channel provided by the PSN tunnel layer. See Bearer Channel Types. 8. IANA considerations There are no IANA considerations for this document. 9. Security Considerations PWE3 provides no means of protecting the contents or delivery of the native data units. PWE3 may, however, leverage security mechanisms provided by the PSN Tunnel Layer. This section addresses the PWE3 vulnerabilities, and the mechanisms available to protect the native services. Vulnerabilities exist at the tunnel end-point, the PW Encapsulation Layer, and the payload of the native service. The security aspects of PWE3 need further study. 9.1 Tunnel End-Point Security Protection mechanisms must be considered for the tunnel end-point in order to avoid denial-of-service attacks to the native service, and to prevent spoofing of the native data units. Exploitation of vulnerabilities from within the PSN may be directed to the tunnel end-point such that PSN tunnel services are disrupted. Controlling PSN access to the tunnel end-point may protect against this. Bryant, et al. Informational [Page 25] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 By restricting Tunnel End-point access to legitimate remote PE sources of traffic destined for the Tunnel End-point, the PE may reject traffic that interferes with the PSN tunnel services. 9.2 Validation of PW Encapsulation Protection mechanisms must address the spoofing of tunneled PW data. The validation of traffic addressed to the tunnel end-point is paramount in ensuring integrity of PW encapsulation. Security protocols such as IPSec may be used by the PSN Tunnel Layer in order to maintain the integrity of the PW by authenticating data between the PE Tunnel End-points. IPSec may provide authentication, integrity, non-repudiation, and confidentiality of data transferred between two PE. It cannot provide the equivalent services to the native service. Based on the type of data being transferred, the PW may indicate to the PSN Tunnel Layer that enhanced security services are required. The PSN Tunnel Layer may define multiple protection profiles based on the requirements of the PW emulated service. CE-to-CE signaling and control events emulated by the PW and some data types may require additional protection mechanisms. Alternatively, the Tunnel End-point may use peer authentication for every PSN packet to prevent spoofed native data units from being sent to the destination CE. 9.3 End to End Security Protection of the PW encapsulated data stream between PE should not be considered equivalent to end-to-end security since the CE-PE interface and the PE processing element remains unprotected. PW service emulation does not preclude the application of additional security mechanisms such as IPSec that are implemented end-to-end. Likewise, end-to-end security mechanisms applied in the native service do not protect the PSN tunnel services provided by the PE for PW encapsulation. Acknowledgments We thank Sasha Vainshtein for his work on Native Service Processing and advice on bit-stream over PW services. We thank Scott Wainner and Stephen Casner for their comments and contributions. Bryant, et al. Informational [Page 26] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 References Internet-drafts are works in progress available from [PPPoL2TP] PPP Tunneling Using Layer Two Tunneling Protocol, J Lau et al. , work in progress. [RTP] RFC-1889: A Transport Protocol for Real-Time Applications, H. Schulzrinne et al. Authors' Addresses Stewart Bryant Cisco Systems, 4, The Square, Stockley Park, Uxbridge UB11 1BL, Email: stbryant@cisco.com United Kingdom. Phone: +44-20-8756-8828 Danny McPherson Email: danny@tcb.net TCB. Phone: +1-303-470-9257 Lloyd Wood Cisco Systems, 4, The Square, Stockley Park, Uxbridge UB11 1BL, Email: lwood@cisco.com United Kingdom. Phone:+44-20-8734-4236 W. Mark Townsley Cisco Systems, 7025 Kit Creek Road, PO Box 14987, Research Triangle Park, Email: mark@townsley.net NC 27709 Full copyright statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published Bryant, et al. Informational [Page 27] INTERNET DRAFT draft-bryant-pwe3-protocol-layering-01 February 2002 and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Bryant, et al. Informational [Page 28]