[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Internet Draft                                            Stewart Bryant
Document: <draft-bryant-pwe3-protocol-layer-01.txt>           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
   <http://www.ietf.org/internet-drafts/>

   [PPPoL2TP]  PPP Tunneling Using Layer Two Tunneling Protocol,
               J Lau et al. <draft-ietf-l2tpext-l2tp-ppp-01.txt>,
               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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/