<pre>Network Working Group                                     S. Bryant, Ed.
Request for Comments: 3985                                 Cisco Systems
Category: Informational                                     P. Pate, Ed.
                                                 Overture Networks, Inc.
                                                              March 2005


         <span class="h1">Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture</span>

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes an architecture for Pseudo Wire Emulation
   Edge-to-Edge (PWE3).  It discusses the emulation of services such as
   Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched
   networks (PSNs) using IP or MPLS.  It presents the architectural
   framework for pseudo wires (PWs), defines terminology, and specifies
   the various protocol elements and their functions.

Table of Contents

   <a href="#section-1">1</a>.   Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-2">2</a>
        <a href="#section-1.1">1.1</a>.  Pseudo Wire Definition. . . . . . . . . . . . . . . . .  <a href="#page-2">2</a>
        <a href="#section-1.2">1.2</a>.  PW Service Functionality. . . . . . . . . . . . . . . .  <a href="#page-3">3</a>
        <a href="#section-1.3">1.3</a>.  Non-Goals of This Document. . . . . . . . . . . . . . .  <a href="#page-4">4</a>
        <a href="#section-1.4">1.4</a>.  Terminology . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-4">4</a>
   <a href="#section-2">2</a>.   PWE3 Applicability. . . . . . . . . . . . . . . . . . . . . .  <a href="#page-6">6</a>
   <a href="#section-3">3</a>.   Protocol Layering Model . . . . . . . . . . . . . . . . . . .  <a href="#page-6">6</a>
        <a href="#section-3.1">3.1</a>.  Protocol Layers . . . . . . . . . . . . . . . . . . . .  <a href="#page-7">7</a>
        <a href="#section-3.2">3.2</a>.  Domain of PWE3. . . . . . . . . . . . . . . . . . . . .  <a href="#page-8">8</a>
        <a href="#section-3.3">3.3</a>.  Payload Types . . . . . . . . . . . . . . . . . . . . .  <a href="#page-8">8</a>
   <a href="#section-4">4</a>.   Architecture of Pseudo Wires. . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
        <a href="#section-4.1">4.1</a>.  Network Reference Model . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
        <a href="#section-4.2">4.2</a>.  PWE3 Pre-processing . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
        <a href="#section-4.3">4.3</a>.  Maintenance Reference Model . . . . . . . . . . . . . . <a href="#page-16">16</a>
        <a href="#section-4.4">4.4</a>.  Protocol Stack Reference Model. . . . . . . . . . . . . <a href="#page-17">17</a>
        4.5.  Pre-processing Extension to Protocol Stack Reference
              Model . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
   <a href="#section-5">5</a>.   PW Encapsulation. . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>



<span class="grey">Bryant &amp; Pate               Standards Track                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


        <a href="#section-5.1">5.1</a>.  Payload Convergence Layer . . . . . . . . . . . . . . . <a href="#page-19">19</a>
        <a href="#section-5.2">5.2</a>.  Payload-independent PW Encapsulation Layers . . . . . . <a href="#page-21">21</a>
        <a href="#section-5.3">5.3</a>.  Fragmentation . . . . . . . . . . . . . . . . . . . . . <a href="#page-24">24</a>
        <a href="#section-5.4">5.4</a>.  Instantiation of the Protocol Layers. . . . . . . . . . <a href="#page-24">24</a>
   <a href="#section-6">6</a>.   PW Demultiplexer Layer and PSN Requirements . . . . . . . . . <a href="#page-27">27</a>
        <a href="#section-6.1">6.1</a>.  Multiplexing. . . . . . . . . . . . . . . . . . . . . . <a href="#page-27">27</a>
        <a href="#section-6.2">6.2</a>.  Fragmentation . . . . . . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
        <a href="#section-6.3">6.3</a>.  Length and Delivery . . . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
        <a href="#section-6.4">6.4</a>.  PW-PDU Validation . . . . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
        <a href="#section-6.5">6.5</a>.  Congestion Considerations . . . . . . . . . . . . . . . <a href="#page-28">28</a>
   <a href="#section-7">7</a>.   Control Plane . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-29">29</a>
        <a href="#section-7.1">7.1</a>.  Set-up or Teardown of Pseudo Wires. . . . . . . . . . . <a href="#page-29">29</a>
        <a href="#section-7.2">7.2</a>.  Status Monitoring . . . . . . . . . . . . . . . . . . . <a href="#page-30">30</a>
        <a href="#section-7.3">7.3</a>.  Notification of Pseudo Wire Status Changes. . . . . . . <a href="#page-30">30</a>
        <a href="#section-7.4">7.4</a>.  Keep-alive. . . . . . . . . . . . . . . . . . . . . . . <a href="#page-31">31</a>
        <a href="#section-7.5">7.5</a>.  Handling Control Messages of the Native Services. . . . <a href="#page-32">32</a>
   <a href="#section-8">8</a>.   Management and Monitoring . . . . . . . . . . . . . . . . . . <a href="#page-32">32</a>
        <a href="#section-8.1">8.1</a>.  Status and Statistics . . . . . . . . . . . . . . . . . <a href="#page-32">32</a>
        <a href="#section-8.2">8.2</a>.  PW SNMP MIB Architecture. . . . . . . . . . . . . . . . <a href="#page-33">33</a>
        <a href="#section-8.3">8.3</a>.  Connection Verification and Traceroute. . . . . . . . . <a href="#page-36">36</a>
   <a href="#section-9">9</a>.   IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-37">37</a>
   <a href="#section-10">10</a>.  Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-37">37</a>
   <a href="#section-11">11</a>.  Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . <a href="#page-38">38</a>
   <a href="#section-12">12</a>.  References. . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-38">38</a>
        <a href="#section-12.1">12.1</a>.  Normative References . . . . . . . . . . . . . . . . . <a href="#page-38">38</a>
        <a href="#section-12.2">12.2</a>.  Informative References . . . . . . . . . . . . . . . . <a href="#page-39">39</a>
   <a href="#section-13">13</a>.  Co-Authors. . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-40">40</a>
   <a href="#section-14">14</a>.  Editors' Addresses. . . . . . . . . . . . . . . . . . . . . . <a href="#page-41">41</a>
        Full Copyright Statement. . . . . . . . . . . . . . . . . . . <a href="#page-42">42</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   This document describes an architecture for Pseudo Wire Emulation
   Edge-to-Edge (PWE3) in support of [<a href="./rfc3916" title="&quot;Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)&quot;">RFC3916</a>].  It discusses the
   emulation of services such as Frame Relay, ATM, Ethernet, TDM, and
   SONET/SDH over packet switched networks (PSNs) using IP or MPLS.  It
   presents the architectural framework for pseudo wires (PWs), defines
   terminology, and specifies the various protocol elements and their
   functions.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Pseudo Wire Definition</span>

   PWE3 is a mechanism that emulates the essential attributes of a
   telecommunications service (such as a T1 leased line or Frame Relay)
   over a PSN.  PWE3 is intended to provide only the minimum necessary
   functionality to emulate the wire with the required degree of
   faithfulness for the given service definition.  Any required
   switching functionality is the responsibility of a forwarder function



<span class="grey">Bryant &amp; Pate               Standards Track                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   (FWRD).  Any translation or other operation needing knowledge of the
   payload semantics is carried out by native service processing (NSP)
   elements.  The functional definition of any FWRD or NSP elements is
   outside the scope of PWE3.

   The required functions of PWs include encapsulating service-specific
   bit streams, cells, or PDUs arriving at an ingress port and carrying
   them across an IP path or MPLS tunnel.  In some cases it is necessary
   to perform other operations such as managing their timing and order,
   to emulate the behavior and characteristics of the service to the
   required degree of faithfulness.

   From the perspective of Customer Edge Equipment (CE), the PW is
   characterized as an unshared link or circuit of the chosen service.
   In some cases, there may be deficiencies in the PW emulation that
   impact the traffic carried over a PW and therefore limit the
   applicability of this technology.  These limitations must be fully
   described in the appropriate service-specific documentation.

   For each service type, there will be one default mode of operation
   that all PEs offering that service type must support.  However,
   optional modes may be defined to improve the faithfulness of the
   emulated service, if it can be clearly demonstrated that the
   additional complexity associated with the optional mode is offset by
   the value it offers to PW users.

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  PW Service Functionality</span>

   PWs provide the following functions in order to emulate the behavior
   and characteristics of the native service.

       o Encapsulation of service-specific PDUs or circuit data arriving
         at the PE-bound port (logical or physical).
       o Carriage of the encapsulated data across a PSN tunnel.
       o Establishment of the PW, including the exchange and/or
         distribution of the PW identifiers used by the PSN tunnel
         endpoints.
       o Managing the signaling, timing, order, or other aspects of the
         service at the boundaries of the PW.
       o Service-specific status and alarm management.











<span class="grey">Bryant &amp; Pate               Standards Track                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>.  Non-Goals of This Document</span>

   The following are non-goals for this document:

      o  The on-the-wire specification of PW encapsulations.
      o  The detailed definition of the protocols involved in PW setup
         and maintenance.

   The following are outside the scope of PWE3:

      o  Any multicast service not native to the emulated medium.  Thus,
         Ethernet transmission to a "multicast" IEEE-48 address is in
         scope, but multicast services such as MARS [<a href="./rfc2022" title="&quot;Support for Multicast over UNI 3.0/3.1 based ATM Networks&quot;">RFC2022</a>] that are
         implemented on top of the medium are not.
      o  Methods to signal or control the underlying PSN.

<span class="h3"><a class="selflink" id="section-1.4" href="#section-1.4">1.4</a>.  Terminology</span>

   This document uses the following definitions of terms.  These terms
   are illustrated in context in Figure 2.


   Attachment Circuit   The physical or virtual circuit attaching
   (AC)                 a CE to a PE. An attachment Circuit may be, for
                        example, a Frame Relay DLCI, an ATM VPI/VCI, an
                        Ethernet port, a VLAN, a PPP connection on a
                        physical interface, a PPP session from an L2TP
                        tunnel, or an MPLS LSP.  If both physical and
                        virtual ACs are of the same technology (e.g.,
                        both ATM, both Ethernet, both Frame Relay), the
                        PW is said to provide "homogeneous transport";
                        otherwise, it is said to provide "heterogeneous
                        transport".

   CE-bound             The traffic direction in which PW-PDUs are
                        received on a PW via the PSN, processed, and
                        then sent to the destination CE.

   CE Signaling         Messages sent and received by the CE's control
                        plane.  It may be desirable or even necessary
                        for the PE to participate in or to monitor this
                        signaling in order to emulate the service
                        effectively.

   Control Word (CW)    A four-octet header used in some encapsulations
                        to carry per-packet information when the PSN is
                        MPLS.




<span class="grey">Bryant &amp; Pate               Standards Track                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   Customer Edge (CE)   A device where one end of a service originates
                        and/or terminates.  The CE is not aware that it
                        is using an emulated service rather than a
                        native service.

   Forwarder (FWRD)     A PE subsystem that selects the PW to use in
                        order to transmit a payload received on an AC.

   Fragmentation        The action of dividing a single PDU into
                        multiple PDUs before transmission with the
                        intent of the original PDU being reassembled
                        elsewhere in the network.  Packets may undergo
                        fragmentation if they are larger than the MTU of
                        the network they will traverse.

   Maximum Transmission The packet size (excluding data link header)
   unit (MTU)           that an interface can transmit without needing
                        to fragment.

   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, or processing of
                        the data received from a PW by a PE before it is
                        output on the AC.  NSP functionality is defined
                        by standards bodies other than the IETF, such as
                        ITU-T,ANSI, or ATMF.)

   Packet Switched      Within the context of PWE3, this is a
   Network (PSN)        network using IP or MPLS as the mechanism for
                        packet forwarding.

   PE-Bound             The traffic direction in which 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 manage the PW effectively.

   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.

   Pseudo Wire (PW)     A mechanism that carries the essential elements
                        of an emulated service from one PE to one or
                        more other PEs over a PSN.




<span class="grey">Bryant &amp; Pate               Standards Track                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   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
   (PW-PDU)             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.

   PW Demultiplexer     Data-plane method of identifying a PW
                        terminating at a PE.

   Time Domain          Time Division Multiplexing.  Frequently used
   Multiplexing (TDM)   to refer to the synchronous bit streams at rates
                        defined by G.702.

   Tunnel               A method of transparently carrying information
                        over a network.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  PWE3 Applicability</span>

   The PSN carrying a PW will subject payload packets to loss, delay,
   delay variation, and re-ordering.  During a network transient there
   may be a sustained period of impaired service.  The applicability of
   PWE3 to a particular service depends on the sensitivity of that
   service (or the CE implementation) to these effects, and on the
   ability of the adaptation layer to mask them.  Some services, such as
   IP over FR over PWE3, may prove quite resilient to IP and MPLS PSN
   characteristics.  Other services, such as the interconnection of PBX
   systems via PWE3, will require more careful consideration of the PSN
   and adaptation layer characteristics.  In some instances, traffic
   engineering of the underlying PSN will be required, and in some cases
   the constraints may make the required service guarantees impossible
   to provide.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Protocol Layering Model</span>

   The PWE3 protocol-layering model is intended to minimize the
   differences between PWs operating over different PSN types.  The
   design of the protocol-layering model has the goals of making each PW
   definition independent of the underlying PSN, and of maximizing the
   reuse of IETF protocol definitions and their implementations.




<span class="grey">Bryant &amp; Pate               Standards Track                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Protocol Layers</span>

   The logical protocol-layering model required to support a PW is shown
   in Figure 1.

          +---------------------------+
          |         Payload           |
          +---------------------------+
          |      Encapsulation        | &lt;==== may be empty
          +---------------------------+
          |     PW Demultiplexer      |
          +---------------------------+
          |     PSN Convergence       | &lt;==== may be empty
          +---------------------------+
          |           PSN             |
          +---------------------------+
          |         Data-Link         |
          +---------------------------+
          |          Physical         |
          +---------------------------+

                    Figure 1.  Logical Protocol Layering Model

   The payload is transported over the Encapsulation Layer.  The
   Encapsulation Layer carries any information, not already present
   within the payload itself, that is needed by the PW CE-bound PE
   interface to send the payload to the CE via the physical interface.
   If no further information is needed in the payload itself, this layer
   is empty.

   The Encapsulation Layer also provides support for real-time
   processing, and if needed for sequencing.

   The PW Demultiplexer layer provides the ability to deliver multiple
   PWs over a single PSN tunnel.  The PW demultiplexer value used to
   identify the PW in the data plane may be unique per PE, but this is
   not a PWE3 requirement.  It must, however, be unique per tunnel
   endpoint.  If it is necessary to identify a particular tunnel, then
   that is the responsibility of the PSN layer.

   The PSN Convergence layer provides the enhancements needed to make
   the PSN conform to the assumed PSN service requirement.  Therefore,
   this layer 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.






<span class="grey">Bryant &amp; Pate               Standards Track                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   The PSN header, MAC/Data-Link, and Physical Layer definitions are
   outside the scope of this document.  The PSN can be IPv4, IPv6, or
   MPLS.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Domain of PWE3</span>

   PWE3 defines the Encapsulation Layer, the method of carrying various
   payload types, and the interface to the PW Demultiplexer Layer.  It
   is expected that the other layers will be provided by tunneling
   methods such as L2TP or MPLS over the PSN.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Payload Types</span>

   The payload is classified into the following generic types of native
   data units:

       o Packet
       o Cell
       o Bit stream
       o Structured bit stream

   Within these generic types there are specific service types:

       Generic Payload Type    PW Service
       --------------------    ----------
       Packet                  Ethernet (all types), HDLC framing,
                               Frame Relay, ATM AAL5 PDU.

       Cell                    ATM.

       Bit stream              Unstructured E1, T1, E3, T3.

       Structured bit stream   SONET/SDH (e.g., SPE, VT, NxDS0).

<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>.  Packet Payload</span>

   A packet payload is a variable-size data unit delivered to the PE via
   the AC.  A packet payload may be large compared to the PSN MTU.  The
   delineation of the packet boundaries is encapsulation specific.  HDLC
   or Ethernet PDUs can be considered examples of packet payloads.
   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.  In these cases, some fragmentation methodology has to
   be applied.  This may, for example, be the case when a user provides



<span class="grey">Bryant &amp; Pate               Standards Track                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   the service and attaches to the service provider via Ethernet, or
   when nested pseudo-wires are involved.  Fragmentation is discussed in
   more detail in <a href="#section-5.3">section 5.3</a>.

   A packet payload may need sequencing and real-time support.

   In some situations, 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, by using a suitable MAC bridge filter.
   This is a forwarder function, and this selection would therefore be
   made before the packet was presented to the PW Encapsulation Layer.

<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>.  Cell Payload</span>

   A cell payload is created by capturing, transporting, and replaying
   groups of octets 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
   ATM 53-octet cells, and the larger 188-octet MPEG Transport Stream
   packets [<a href="#ref-DVB" title="channel coding and modulation for digital terrestrial television (DVB-T)">DVB</a>].

   To reduce per-PSN packet overhead, multiple cells may be concatenated
   into a single payload.  The Encapsulation Layer may consider the
   payload complete on the expiry of a timer, after a fixed number of
   cells have been received or when a significant cell (e.g., an ATM OAM
   cell) has been received.  The benefit of concatenating multiple PDUs
   should be weighed against a possible increase in packet delay
   variation and the larger penalty incurred by packet loss.  In some
   cases, it may be appropriate for the Encapsulation Layer to perform
   some type of compression, such as silence suppression or voice
   compression.

   The generic cell payload service will normally need sequence number
   support and may also need real-time support.  The generic cell
   payload service would not normally require fragmentation.

   The Encapsulation Layer may apply some form of compression to some of
   these sub-types (e.g., idle cells may be suppressed).

   In some instances, the cells to be incorporated in the payload may be
   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.  This is a forwarder function, and the
   selection would therefore be made before the packet was presented to
   the PW Encapsulation Layer.



<span class="grey">Bryant &amp; Pate               Standards Track                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


<span class="h4"><a class="selflink" id="section-3.3.3" href="#section-3.3.3">3.3.3</a>.  Bit Stream</span>

   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 (i.e., the internal structure has no effect on
   the fragmentation into packets).

   In some instances it is possible to apply suppression to bit streams.
   For example, E1 and T1 send "all-ones" to indicate failure.  This
   condition can be detected without any knowledge of the structure of
   the bit stream, and transmission of packetized can be data
   suppressed.

   This service will require sequencing and real-time support.

<span class="h4"><a class="selflink" id="section-3.3.4" href="#section-3.3.4">3.3.4</a>.  Structured Bit Stream</span>

   A structured 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.

   Two important points distinguish structured and unstructured bit
   streams:

       o Some parts of the original bit stream may be stripped in the
         PSN-bound direction by an NSP block.  For example, in
         Structured SONET the section and line overhead (and possibly
         more) may be stripped.  A framer is required to enable such
         stripping.  It is also required for frame/payload alignment for
         fractional T1/E1 applications.

       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 stripped
         information (such as SONET pointer justifications) may appear
         in the encapsulation layer to facilitate this reconstitution.

   As an option, the Encapsulation Layer may also perform silence/idle
   suppression or similar 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.  Note
   that "short" structures are indistinguishable from cells and may
   benefit from the use of methods described in <a href="#section-3.3.2">section 3.3.2</a>.

   This service requires sequencing and real-time support.




<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


<span class="h4"><a class="selflink" id="section-3.3.5" href="#section-3.3.5">3.3.5</a>.  Principle of Minimum Intervention</span>

   To minimize the scope of information, and to improve the efficiency
   of data flow through the Encapsulation Layer, the payload should be
   transported as received, with as few modifications as possible
   [<a href="./rfc1958" title="&quot;Architectural Principles of the Internet&quot;">RFC1958</a>].

   This minimum intervention approach decouples payload development from
   PW development and requires fewer translations at the NSP in a system
   with similar CE interfaces at each end.  It also prevents unwanted
   side effects due to subtle misrepresentation of the payload in the
   intermediate format.

   An approach that does intervene can be more wire efficient in some
   cases and may result in fewer translations at the NSP whereby the CE
   interfaces are of different types.  Any intermediate format
   effectively becomes a new framing type, requiring documentation and
   assured interoperability.  This increases the amount of work for
   handling the protocol that the intermediate format carries and is
   undesirable.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Architecture of Pseudo Wires</span>

   This section describes the PWE3 architectural model.



























<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Network Reference Model</span>

   Figure 2 illustrates the network reference model for point-to-point
   PWs.

            |&lt;-------------- Emulated Service ----------------&gt;|
            |                                                  |
            |          |&lt;------- Pseudo Wire ------&gt;|          |
            |          |                            |          |
            |          |    |&lt;-- PSN Tunnel --&gt;|    |          |
            |          V    V                  V    V          |
            V    AC    +----+                  +----+     AC   V
      +-----+    |     | PE1|==================| PE2|     |    +-----+
      |     |----------|............PW1.............|----------|     |
      | CE1 |    |     |    |                  |    |     |    | CE2 |
      |     |----------|............PW2.............|----------|     |
      +-----+  ^ |     |    |==================|    |     | ^  +-----+
            ^  |       +----+                  +----+     | |  ^
            |  |   Provider Edge 1         Provider Edge 2  |  |
            |  |                                            |  |
      Customer |                                            | Customer
      Edge 1   |                                            | Edge 2
               |                                            |
               |                                            |
         Native service                               Native service

                   Figure 2.  PWE3 Network Reference Model

   The two PEs (PE1 and PE2) have to provide one or more PWs on behalf
   of their client CEs (CE1 and CE2) to enable the client CEs to
   communicate over the PSN.  A PSN tunnel is established to provide a
   data path for the PW.  The PW traffic is invisible to the core
   network, and the core network is transparent to the CEs.  Native data
   units (bits, cells, or packets) arrive via the AC, are encapsulated
   in a PW-PDU, and are carried across the underlying network via the
   PSN tunnel.  The PEs perform the necessary encapsulation and
   decapsulation of PW-PDUs and handle any other functions required by
   the PW service, such as sequencing or timing.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  PWE3 Pre-processing</span>

   Some applications have to perform operations on the native data units
   received from the CE (including both payload and signaling traffic)
   before they are transmitted across the PW by the PE.  Examples
   include Ethernet bridging, SONET cross-connect, translation 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 could be sent to the PE



<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   over one or more physical interfaces.  In most cases, could be in
   undertaking these operations within the PE provides cost and
   operational benefits.  Processed data is then presented to the PW via
   a virtual interface within the PE.  These pre-processing operations
   are included in the PWE3 reference model to provide a common
   reference point, but the detailed description of these operations is
   outside the scope of the PW definition given here.

                       PW
                    End Service
                        |
                        |&lt;------- Pseudo Wire ------&gt;|
                        |                            |
                        |    |&lt;-- PSN Tunnel --&gt;|    |
                        V    V                  V    V     PW
                  +-----+----+                  +----+ End Service
       +-----+    |PREP | PE1|==================| PE2|     |    +-----+
       |     |    |     |............PW1.............|----------|     |
       | CE1 |----|     |    |                  |    |     |    | CE2 |
       |     | ^  |     |............PW2.............|----------|     |
       +-----+ |  |     |    |==================|    |     | ^  +-----+
               |  +-----+----+                  +----+     | |
               |        ^                                  | |
               |        |                                  | |
               |        |&lt;------- Emulated Service -------&gt;| |
               |        |                                    |
               | Virtual physical                            |
               |  termination                                |
               |        ^                                    |
          CE1 native    |                                CE2 native
           service      |                                service
                        |
                   CE2 native
                    service

       Figure 3.  Pre-processing within the PWE3 Network Reference Model

   Figure 3 shows the interworking of one PE with pre-processing (PREP),
   and a second without this functionality.  This reference point
   emphasizes that the functional interface between PREP 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 PREP
   functionality is also supported.






<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   The required pre-processing can be divided into two components:

       o Forwarder (FWRD)
       o Native Service Processing (NSP)

<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>.  Forwarders</span>

   Some applications have to forward payload elements selectively from
   one or more ACs to one or more PWs.  In such cases, there will also be
   a need to perform the inverse function on PWE3-PDUs received by a PE
   from the PSN.  This is the function of the forwarder.

   The forwarder selects the PW based on, for example, the incoming AC,
   the contents of the payload, or some statically and/or dynamically
   configured forwarding information.

               +----------------------------------------+
               |                PE Device               |
               +----------------------------------------+
        Single |                 |                      |
        AC     |                 |        Single        | PW Instance
       &lt;------&gt;o   Forwarder     +      PW Instance     X&lt;===========&gt;
               |                 |                      |
               +----------------------------------------+

                   Figure 4a.  Simple Point-to-Point Service

               +----------------------------------------+
               |                PE Device               |
               +----------------------------------------+
       Multiple|                 |        Single        | PW Instance
       AC      |                 +      PW Instance     X&lt;===========&gt;
       &lt;------&gt;o                 |                      |
               |                 |----------------------|
       &lt;------&gt;o                 |        Single        | PW Instance
               |    Forwarder    +      PW Instance     X&lt;===========&gt;
       &lt;------&gt;o                 |                      |
               |                 |----------------------|
       &lt;------&gt;o                 |        Single        | PW Instance
               |                 +      PW Instance     X&lt;===========&gt;
       &lt;------&gt;o                 |                      |
               +----------------------------------------+

               Figure 4b.  Multiple AC to Multiple PW Forwarding

   Figure 4a shows a simple forwarder that performs some type of
   filtering operation.  Because the forwarder has a single input and a
   single output interface, filtering is the only type of forwarding



<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   operation that applies.  Figure 4b shows a more general forwarding
   situation where payloads are extracted from one or more ACs and
   directed to one or more PWs.  In this case filtering, direction, and
   combination operations may be performed on the payloads.  For
   example, if the AC were Frame Relay, the forwarder might perform
   Frame Relay switching and the PW instances might be the inter-switch
   links.

<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>.  Native Service Processing</span>

   Some applications required some form of data or address translation,
   or some other operation requiring knowledge of the semantics of the
   payload.  This is the function of the Native Service Processor (NSP).

   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.

                +----------------------------------------+
                |                PE Device               |
        Multiple+----------------------------------------+
        AC      |      |          |        Single        | PW Instance
        &lt;------&gt;o  NSP #          +      PW Instance     X&lt;===========&gt;
                |      |          |                      |
                |------|          |----------------------|
                |      |          |        Single        | PW Instance
        &lt;------&gt;o  NSP #Forwarder +      PW Instance     X&lt;===========&gt;
                |      |          |                      |
                |------|          |----------------------|
                |      |          |        Single        | PW Instance
        &lt;------&gt;o  NSP #          +      PW Instance     X&lt;===========&gt;
                |      |          |                      |
                +----------------------------------------+

          Figure 5.  NSP in a Multiple AC to Multiple PW Forwarding PE

   Figure 5 illustrates the relationship between NSP, forwarder, and PWs
   in a PE.  The NSP function may apply any transformation operation
   (modification, injection, etc.) on the payloads as they pass between
   the physical interface to the CE and the virtual interface to the
   forwarder.  These transformation operations will, of course, be
   limited to those that have been implemented in the data path, and
   that are enabled by the PE configuration.  A PE device may contain
   more than one forwarder.





<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   This model also supports the operation of a system in which the NSP
   functionality includes terminating the data-link, and the application
   of Network Layer processing to the payload.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Maintenance Reference Model</span>

   Figure 6 illustrates the maintenance reference model for PWs.

             |&lt;------- CE (end-to-end) Signaling ------&gt;|
             |     |&lt;---- PW/PE Maintenance -----&gt;|     |
             |     |     |&lt;-- PSN Tunnel --&gt;|     |     |
             |     |     |    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 6.  PWE3 Maintenance Reference Model

   The following signaling mechanisms are required:

       o The CE (end-to-end) signaling is between the CEs.  This
         signaling could be Frame Relay PVC status signaling, ATM SVC
         signaling, TDM CAS 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 PW multiplexing and some
         elements of the underlying PSN.  Examples are L2TP control
         protocol, MPLS LDP, and RSVP-TE.  The definition of the
         information that PWE3 needs signaled is within the scope of
         PWE3, but the signaling protocol itself is not.











<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Protocol Stack Reference Model</span>

   Figure 7 illustrates the protocol stack reference model for PWs.

    +-----------------+                           +-----------------+
    |Emulated Service |                           |Emulated Service |
    |(e.g., TDM, ATM) |&lt;==== Emulated Service ===&gt;|(e.g., TDM, ATM) |
    +-----------------+                           +-----------------+
    |    Payload      |                           |    Payload      |
    |  Encapsulation  |&lt;====== Pseudo Wire ======&gt;|  Encapsulation  |
    +-----------------+                           +-----------------+
    |PW Demultiplexer |                           |PW Demultiplexer |
    |   PSN Tunnel,   |&lt;======= PSN Tunnel ======&gt;|  PSN Tunnel,    |
    | PSN &amp; Physical  |                           | PSN &amp; Physical  |
    |     Layers      |                           |    Layers       |
    +-------+---------+        ___________        +---------+-------+
            |                /             \                |
            +===============/     PSN       \===============+
                            \               /
                             \_____________/

               Figure 7.  PWE3 Protocol Stack Reference Model

   The PW provides the CE with an emulated physical or virtual
   connection to its peer at the far end.  Native service PDUs 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.

<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>.  Pre-processing Extension to Protocol Stack Reference Model</span>

   Figure 8 illustrates how the protocol stack reference model is
   extended to include the provision of pre-processing (forwarding and
   NSP).  This shows the placement of the physical interface relative to
   the CE.















<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


     /======================================\
     H             Forwarder                H&lt;----Pre-processing
     H----------------======================/
     H Native Service H   |                 |
     H  Processing    H   |                 |
     \================/   |                 |
     |                |   | Emulated        |
     | Service        |   | Service         |
     | Interface      |   | (TDM, ATM,      |
     | (TDM, ATM,     |   | Ethernet,       |&lt;== Emulated Service ==
     | Ethernet,      |   | Frame Relay,    |
     | Frame Relay,   |   | etc.)           |
     | etc.)          |   +-----------------+
     |                |   |    Payload      |
     |                |   | Encapsulation   |&lt;=== Pseudo Wire ======
     |                |   +-----------------+
     |                |   |PW Demultiplexer |
     |                |   |  PSN Tunnel,    |
     |                |   | PSN &amp; Physical  |&lt;=== PSN Tunnel =======
     |                |   |    Headers      |
     +----------------+   +-----------------+
     |   Physical     |   |   Physical      |
     +-------+--------+   +-------+---------+
             |                    |
             |                    |
             |                    |
             |                    |
             |                    |
             |                    |
   To CE &lt;---+                    +---&gt; To PSN

       Figure 8.  Protocol Stack Reference Model with Pre-processing

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  PW Encapsulation</span>

   The PW Encapsulation Layer provides the necessary infrastructure to
   adapt the specific payload type being transported over the PW to the
   PW Demultiplexer Layer used to carry the PW over the PSN.

   The PW Encapsulation Layer consists of three sub-layers:

       o Payload Convergence
       o Timing
       o Sequencing

   The PW Encapsulation sub-layering and its context with the protocol
   stack are shown in Figure 9.




<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


          +---------------------------+
          |         Payload           |
          /===========================\ &lt;------ Encapsulation
          H    Payload Convergence    H         Layer
          H---------------------------H
          H          Timing           H
          H---------------------------H
          H        Sequencing         H
          \===========================/
          |     PW Demultiplexer      |
          +---------------------------+
          |     PSN Convergence       |
          +---------------------------+
          |           PSN             |
          +---------------------------+
          |         Data-Link         |
          +---------------------------+
          |          Physical         |
          +---------------------------+

                  Figure 9.  PWE3 Encapsulation Layer in Context

   The Payload Convergence sub-layer is highly tailored to the specific
   payload type.  However grouping a number of target payload types into
   a generic class, and then providing a single convergence sub-layer
   type common to the group, reduces the number of payload convergence
   sub-layer types.  This decreases implementation complexity.  The
   provision of per-packet signaling and other out-of-band information
   (other than sequencing or timing) is undertaken by this layer.

   The Timing and Sequencing Layers provide generic services to the
   Payload Convergence Layer for all payload types that require them.

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Payload Convergence Layer</span>

<span class="h4"><a class="selflink" id="section-5.1.1" href="#section-5.1.1">5.1.1</a>.  Encapsulation</span>

   The primary task of the Payload Convergence Layer is the
   encapsulation of the payload in PW-PDUs.  The native data units to be
   encapsulated may contain an L2 header or L1 overhead.  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 PW Demultiplexer header is not
   considered part of the PW header.







<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   Not all the additional information needed to replay the native data
   units have to be carried in the PW header of the PW PDUs.  Some
   information (e.g., service type of a PW) may be stored as state
   information at the destination PE during PW set up.

<span class="h4"><a class="selflink" id="section-5.1.2" href="#section-5.1.2">5.1.2</a>.  PWE3 Channel Types</span>

   The PW Encapsulation Layer and its associated signaling require one
   or more of the following types of channels from its underlying PW
   Demultiplexer and PSN Layers (channel type 1 plus one or more of
   channel types 2 through 4):

   1. A reliable control channel for signaling line events, status
      indications, and, in exceptional cases, CE-CE events that must be
      translated and sent reliably between PEs.  PWE3 may 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 indicated
      via the DSCP bits for IP or the EXP bits for MPLS, giving the
      packet priority during transit.  This channel type could also use
      a bit in the tunnel header itself to indicate that packets
      received at the PE should be processed with higher priority
      [<a href="./rfc2474" title="&quot;Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers&quot;">RFC2474</a>].

   3. A sequenced channel for data traffic that is sensitive to packet
      reordering (one classification for use could be for any non-IP
      traffic).

   4. An unsequenced channel for data traffic insensitive to packet
      order.

   The data channels (2, 3, and 4 above) should be carried "in band"
   with one another to as much of a degree as is reasonably possible on
   a PSN.

   Where end-to-end connectivity may be disrupted by address translation
   [<a href="./rfc3022" title="&quot;Traditional IP Network Address Translator (Traditional NAT)&quot;">RFC3022</a>], access-control lists, firewalls, etc., the control channel
   may be able to pass traffic and setup the PW, while the PW data
   traffic is blocked by one or more of these mechanisms.  In these
   cases unless the control channel is also carried "in band", the
   signaling to set up the PW will not confirm the existence of an end-
   to-end data path.  In some cases there is a need to synchronize CE
   events with the data carried over a PW.  This is especially the case






<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   with TDM circuits (e.g., the on-hook/off-hook events in PSTN switches
   might be carried over a reliable control channel whereas the
   associated bit stream is carried over a sequenced data channel).

   PWE3 channel types that are not needed by the supported PWs need not
   be included in such an implementation.

<span class="h4"><a class="selflink" id="section-5.1.3" href="#section-5.1.3">5.1.3</a>.  Quality of Service Considerations</span>

   Where possible, it is desirable to employ mechanisms to provide PW
   Quality of Service (QoS) support over PSNs.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Payload-Independent PW Encapsulation Layers</span>

   Two PWE3 Encapsulation sub-layers provide common services to all
   payload types: Sequencing and Timing.  These services are optional
   and are only used if a particular PW instance needs them.  If the
   service is not needed, the associated header may be omitted in order
   to conserve processing and network resources.

   Sometimes a specific payload type will require transport with or
   without sequence and/or real-time support.  For example, an invariant
   of Frame Relay transport is the preservation of packet order.  Some
   Frame Relay applications expect delivery in order and may not cope
   with reordering of the frames.  However, where the Frame Relay
   service is itself only being used to carry IP, it may be desirable to
   relax this constraint to reduce per-packet processing cost.

   The guiding principle is that, when possible, an existing IETF
   protocol should be used to provide these services.  When a suitable
   protocol is not available, the existing protocol should be extended
   or modified 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 timing requirements.

<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>.  Sequencing</span>

   The sequencing function provides three services: frame ordering,
   frame duplication detection, and frame loss detection.  These
   services allow the emulation of the invariant properties of a
   physical wire.  Support for sequencing depends on the payload type
   and may be omitted if it is not needed.








<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   The size of the sequence-number space depends on the speed of the
   emulated service, and on the maximum time of the transient conditions
   in the PSN.  A sequence number space greater than 2^16 may therefore
   be needed to prevent the sequence number space from wrapping during
   the transient.

<span class="h5"><a class="selflink" id="section-5.2.1.1" href="#section-5.2.1.1">5.2.1.1</a>.  Frame Ordering</span>

   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) must be delivered in order.
   For these services, some mechanism must be provided for ensuring in-
   order delivery.  Providing a sequence number in the sequence sub-
   layer header for each packet is one possible approach.
   Alternatively, it can be noted that sequencing is a subset of the
   problem of delivering timed packets, and that a single combined
   mechanism such as [<a href="./rfc3550" title="&quot;RTP: A Transport Protocol for Real-Time Applications&quot;">RFC3550</a>] may be employed.

   There are two possible misordering strategies:

       o Drop misordered 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 (as delay must be introduced to reorder),
         and

       o the expected incidence of misordering.

<span class="h5"><a class="selflink" id="section-5.2.1.2" href="#section-5.2.1.2">5.2.1.2</a>.  Frame Duplication Detection</span>

   In rare cases, packets traversing a PW may be duplicated by the
   underlying PSN.  For some services, frame duplication is not
   acceptable.  For these services, some mechanism must be provided to
   ensure that duplicated frames will not be delivered to the
   destination CE.  The mechanism may be the same as that used to ensure
   in-order frame delivery.







<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


<span class="h5"><a class="selflink" id="section-5.2.1.3" href="#section-5.2.1.3">5.2.1.3</a>.  Frame Loss Detection</span>

   A destination PE can determine whether a frame has been lost by
   tracking the sequence numbers of the PW PDUs received.

   In some instances, if a PW PDU fails to arrive within a certain time,
   a destination PE will have to presume that it is lost.  If a PW-PDU
   that has been processed as lost subsequently arrives, the destination
   PE must discard it.

<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>.  Timing</span>

   A number of native services have timing expectations based on the
   characteristics of the networks they were designed to travel over.
   The emulated service may have to duplicate these network
   characteristics as closely as possible: e.g., in delivering native
   traffic with bitrate, jitter, wander, and delay characteristics
   similar to those received at the sending PE.

   In such cases, the receiving PE has to play out the native traffic as
   it was received at the sending PE.  This relies on timing information
   either sent between the two PEs, or in some cases received from an
   external reference.

   Therefore, Timing Sub-layer must support two timing functions:  clock
   recovery and timed payload delivery.  A particular payload type may
   require either or both of these services.

<span class="h5"><a class="selflink" id="section-5.2.2.1" href="#section-5.2.2.1">5.2.2.1</a>.  Clock Recovery</span>

   Clock recovery is the extraction of output transmission bit timing
   information from the delivered packet stream, and it requires a
   suitable mechanism.  A physical wire carries the timing information
   natively, but extracting timing from a highly jittered source, such
   as packet stream, is a relatively complex task.  Therefore, it is
   desirable that an existing real-time protocol such as [<a href="./rfc3550" title="&quot;RTP: A Transport Protocol for Real-Time Applications&quot;">RFC3550</a>] be
   used for this purpose, unless it can be shown that this is unsuitable
   or unnecessary for a particular payload type.

<span class="h5"><a class="selflink" id="section-5.2.2.2" href="#section-5.2.2.2">5.2.2.2</a>.  Timed Delivery</span>

   Timed delivery is the delivery of non-contiguous PW PDUs to the PW
   output interface with a constant phase relative to the input
   interface.  The timing of the delivery may be relative to a clock
   derived from the packet stream received over the PSN clock recovery,
   or to an external clock.





<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Fragmentation</span>

   Ideally, a payload would be relayed across the PW as a single unit.
   However, there will be cases where the combined size of the payload
   and its associated PWE3 and PSN headers will exceed the PSN path MTU.
   When a packet size exceeds the MTU of a given network, fragmentation
   and reassembly have to be performed for the packet to be delivered.
   Since fragmentation and reassembly generally consume considerable
   network resources, as compared to simply switching a packet in its
   entirety, the need for fragmentation and reassembly throughout a
   network should be reduced or eliminated to the extent possible.  Of
   particular concern for fragmentation and reassembly are aggregation
   points where large numbers of PWs are processed (e.g., at the PE).

   Ideally, the equipment originating the traffic sent over the PW will
   have adaptive measures in place (e.g., [<a href="./rfc1191" title="&quot;Path MTU discovery&quot;">RFC1191</a>], [<a href="./rfc1981" title="&quot;Path MTU Discovery for IP version 6&quot;">RFC1981</a>]) that
   ensure that packets needing to be fragmented are not sent.  When this
   fails, the point closest to the sending host with fragmentation and
   reassembly capabilities should attempt to reduce the size of packets
   to satisfy the PSN MTU.  Thus, in the reference model for PWE3
   (Figure 3), fragmentation should first be performed at the CE if
   possible.  Only if the CE cannot adhere to an acceptable MTU size for
   the PW should the PE attempt its own fragmentation method.

   In cases where MTU management fails to limit the payload to a size
   suitable for transmission of the PW, the PE may fall back to either a
   generic PW fragmentation method or, if available, the fragmentation
   service of the underlying PSN.

   It is acceptable for a PE implementation not to support
   fragmentation.  A PE that does not will drop packets that exceed the
   PSN MTU, and the management plane of the encapsulating PE may be
   notified.

   If the length of a L2/L1 frame, restored from a PW PDU, exceeds the
   MTU of the destination AC, it must be dropped.  In this case, the
   management plane of the destination PE may be notified.

<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>.  Instantiation of the Protocol Layers</span>

   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 is shown in
   Figure 9.







<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


<span class="h4"><a class="selflink" id="section-5.4.1" href="#section-5.4.1">5.4.1</a>.  PWE3 over an IP PSN</span>

   The protocol definition of PWE3 over an IP PSN should employ existing
   IETF protocols where possible.

       +---------------------+              +-------------------------+
       |      Payload        |-------------&gt;| Raw payload if possible |
       /=====================\              +-------------------------+
       H Payload Convergence H-----------+-&gt;|     Flags, seq #, etc.  |
       H---------------------H          /   +-------------------------+
       H       Timing        H---------/---&gt;|            RTP          |
       H---------------------H        /     +-------------+           |
       H     Sequencing      H----one of    |             |
       \=====================/        \     |             +-----------+
       |  PW Demultiplexer   |---------+---&gt;|     L2TP, MPLS, etc.    |
       +---------------------+              +-------------------------+
       |  PSN Convergence    |-------------&gt;|       Not needed        |
       +---------------------+              +-------------------------+
       |        PSN          |-------------&gt;|            IP           |
       +---------------------+              +-------------------------+
       |      Data-Link      |-------------&gt;|         Data-link       |
       +---------------------+              +-------------------------+
       |       Physical      |-------------&gt;|          Physical       |
       +---------------------+              +-------------------------+

                        Figure 10.  PWE3 over an IP PSN

   Figure 10 shows the protocol layering for PWE3 over an IP PSN.  As a
   rule, the payload should be carried as received from the NSP, with
   the Payload Convergence Layer provided when needed.  However, in
   certain circumstances it may be justifiable to transmit the payload
   in some processed form.  The reasons for this must be documented in
   the Encapsulation Layer definition for that payload type.

   Where appropriate, explicit timing is provided by RTP [<a href="./rfc3550" title="&quot;RTP: A Transport Protocol for Real-Time Applications&quot;">RFC3550</a>],
   which, when used, also provides a sequencing service.  When the PSN
   is UDP/IP, the RTP header follows the UDP header and precedes the PW
   control field.  For all other cases the RTP header follows the PW
   control header.

   The encapsulation layer may additionally carry a sequence number.
   Sequencing is to be provided either by RTP or by the PW encapsulation
   layer, but not by both.








<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   PW Demultiplexing is provided by the PW label, which may take the
   form specified in a number of IETF protocols;  e.g., an MPLS label
   [<a href="#ref-MPLSIP" title="&quot;Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)&quot;">MPLSIP</a>], an L2TP session ID [<a href="./rfc3931" title="and I. Goyret">RFC3931</a>], or a UDP port number
   [<a href="./rfc768" title="&quot;User Datagram Protocol&quot;">RFC768</a>].  When PWs are carried over IP, the PSN Convergence Layer
   will not be needed.

   As a special case, if the PW Demultiplexer is an MPLS label, the
   protocol architecture of <a href="#section-5.4.2">section 5.4.2</a> can be used instead of the
   protocol architecture of this section.

<span class="h4"><a class="selflink" id="section-5.4.2" href="#section-5.4.2">5.4.2</a>.  PWE3 over an MPLS PSN</span>

   The MPLS ethos places importance on wire efficiency.  By using a
   control word, some components of the PWE3 protocol layers can be
   compressed to increase this efficiency.

   +---------------------+
   |      Payload        |
   /=====================\
   H Payload Convergence H--+
   H---------------------H  |       +--------------------------------+
   H       Timing        H---------&gt;|              RTP               |
   H---------------------H  |       +--------------------------------+
   H     Sequencing      H--+------&gt;| Flags, Frag, Len, Seq #, etc   |
   \=====================/  |       +--------------------------------+
   |  PW Demultiplexer   |---------&gt;|           PW Label             |
   +---------------------+  |       +--------------------------------+
   |  PSN Convergence    |--+  +---&gt;| Outer Label or MPLS-in-IP encap|
   +---------------------+     |    +--------------------------------+
   |        PSN          |-----+
   +---------------------+
   |      Data-Link      |
   +---------------------+
   |       Physical      |
   +---------------------+

          Figure 11.  PWE3 over an MPLS PSN Using a Control Word

   Figure 11 shows the protocol layering for PWE3 over an MPLS PSN.  An
   inner MPLS label is used to provide the PW demultiplexing function.
   A control word is used to carry most of the information needed by the
   PWE3 Encapsulation Layer and the PSN Convergence Layer in a compact
   format.  The flags in the control word provide the necessary payload
   convergence.  A sequence field provides support for both in-order
   payload delivery and a PSN fragmentation service within the PSN
   Convergence Layer (supported by a fragmentation control method).
   Ethernet pads all frames to a minimum size of 64 bytes.  The MPLS
   header does not include a length indicator.  Therefore, to allow PWE3



<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   to be carried in MPLS to pass correctly over an Ethernet data-link, a
   length correction field is needed in the control word.  As with an IP
   PSN, where appropriate, timing is provided by RTP [<a href="./rfc3550" title="&quot;RTP: A Transport Protocol for Real-Time Applications&quot;">RFC3550</a>].

   In some networks, it may be necessary to carry PWE3 over MPLS over
   IP.  In these circumstances, the PW is encapsulated for carriage over
   MPLS as described in this section, and then a method of carrying MPLS
   over an IP PSN (such as GRE [<a href="./rfc2784" title="&quot;Generic Routing Encapsulation (GRE)&quot;">RFC2784</a>], [<a href="./rfc2890" title="&quot;Key and Sequence Number Extensions to GRE&quot;">RFC2890</a>]) is applied to the
   resultant PW-PDU.

<span class="h4"><a class="selflink" id="section-5.4.3" href="#section-5.4.3">5.4.3</a>.  PW-IP Packet Discrimination</span>

   For MPLS PSNs, there is an additional constraint on the PW packet
   format.  Some label switched routers detect IP packets based on the
   initial four bits of the packet content.  To facilitate proper
   functioning, these bits in PW packets must not be the same as an IP
   version number in current use.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  PW Demultiplexer Layer and PSN Requirements</span>

   PWE3 places three service requirements on the protocol layers used to
   carry it across the PSN:

       o Multiplexing
       o Fragmentation
       o Length and Delivery

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Multiplexing</span>

   The purpose of the PW Demultiplexer Layer is to allow multiple PWs to
   be carried in a single tunnel.  This minimizes complexity and
   conserves resources.

   Some types of native service are capable of grouping multiple
   circuits into a "trunk"; e.g., multiple ATM VCs in a VP, multiple
   Ethernet VLANs on a physical media, or multiple DS0 services within a
   T1 or E1.  A PW may interconnect two end-trunks.  That trunk would
   have a single multiplexing identifier.

   When a MPLS label is used as a PW Demultiplexer, setting of the TTL
   value [<a href="./rfc3032" title="&quot;MPLS Label Stack Encoding&quot;">RFC3032</a>] in the PW label is application specific.










<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Fragmentation</span>

   If the PSN provides a fragmentation and reassembly service of
   adequate performance, it may be used to obtain an effective MTU that
   is large enough to transport the PW PDUs.  See <a href="#section-5.3">section 5.3</a> for a full
   discussion of the PW fragmentation issues.

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>.  Length and Delivery</span>

   PDU delivery to the egress PE is the function of the PSN Layer.

   If the underlying PSN does not provide all the information necessary
   to determine the length of a PW-PDU, the Encapsulation Layer must
   provide it.

<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>.  PW-PDU Validation</span>

   It is a common practice to use an error detection mechanism such as a
   CRC or similar mechanism to ensure end-to-end integrity of frames.
   The PW service-specific mechanisms must define whether the packet's
   checksum shall be preserved across the PW or be removed from PE-bound
   PDUs and then be recalculated for insertion in CE-bound data.

   The former approach saves work, whereas the latter saves bandwidth.
   For a given implementation, the choice may be dictated by hardware
   restrictions, which may not allow the preservation of the checksum.

   For protocols such as ATM and FR, the scope of the checksum is
   restricted to a single link.  This is because the circuit identifiers
   (e.g., FR DLCI or ATM VPI/VCI) only have local significance and are
   changed on each hop or span.  If the circuit identifier (and thus
   checksum) were going to change as part of the PW emulation, it would
   be more efficient to strip and recalculate the checksum.

   The service-specific document for each protocol must describe the
   validation scheme to be used.

<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>.  Congestion Considerations</span>

   The PSN carrying the PW may be subject to congestion.  The congestion
   characteristics will vary with the PSN type, the network architecture
   and configuration, and the loading of the PSN.

   If the traffic carried over the PW is known to be TCP friendly (by,
   for example, packet inspection), packet discard in the PSN will
   trigger the necessary reduction in offered load, and no additional
   congestion avoidance action is necessary.




<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   If the PW is operating over a PSN that provides enhanced delivery,
   the PEs should monitor packet loss to ensure that the requested
   service is actually being delivered.  If it is not, then the PE
   should assume that the PSN is providing a best-effort service and
   should use the best-effort service congestion avoidance measures
   described below.

   If best-effort service is being used and the traffic is not known to
   be TCP friendly, the PEs should monitor packet loss to ensure that
   the loss rate is within acceptable parameters.  Packet loss is
   considered acceptable if a TCP flow across the same network path and
   experiencing the same network conditions would achieve an average
   throughput, measured on a reasonable timescale, not less than that
   which the PW flow is achieving.  This condition can be satisfied by
   implementing a rate-limiting measure in the NSP, or by shutting down
   one or more PWs.  The choice of which approach to use depends upon
   the type of traffic being carried.  Where congestion is avoided by
   shutting down a PW, a suitable mechanism must be provided to prevent
   it from immediately returning to service and causing a series of
   congestion pulses.

   The comparison to TCP cannot be specified exactly but is intended as
   an "order-of-magnitude" comparison in timescale and throughput.  The
   timescale on which TCP throughput is measured is the round-trip time
   of the connection.  In essence, this requirement states that it is
   not acceptable to deploy an application (using PWE3 or any other
   transport protocol) on the best-effort Internet, which consumes
   bandwidth arbitrarily and does not compete fairly with TCP within an
   order of magnitude.  One method of determining an acceptable PW
   bandwidth is described in [<a href="./rfc3448" title="&quot;TCP Friendly Rate Control (TFRC): Protocol Specification&quot;">RFC3448</a>].

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Control Plane</span>

   This section describes PWE3 control plane services.

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  Setup or Teardown of Pseudo Wires</span>

   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.

   Setup or teardown of a PW can be triggered by an operator command,
   from the management plane of a PE, by signaling set-up or teardown of
   an AC (e.g., an ATM SVC), or by an auto-discovery mechanism.

   During the setup process, the PEs have to exchange information (e.g.,
   learn each other's capabilities).  The tunnel signaling protocol may
   be extended to provide mechanisms that enable the PEs to exchange all
   necessary information on behalf of the PW.



<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   Manual configuration of PWs can be considered a special kind of
   signaling and is allowed.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  Status Monitoring</span>

   Some native services have mechanisms for status monitoring.  For
   example, ATM supports OAM for this purpose.  For these services, the
   corresponding emulated services must specify how to perform status
   monitoring.

<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>.  Notification of Pseudo Wire Status Changes</span>

<span class="h4"><a class="selflink" id="section-7.3.1" href="#section-7.3.1">7.3.1</a>.  Pseudo Wire Up/Down Notification</span>

   If a native service requires bi-directional connectivity, the
   corresponding emulated service can only be signaled as being up when
   the PW and PSN tunnels (if used), are functional in both directions.

   Because the two CEs of an emulated service are not adjacent, a
   failure may occur at a place so that one or both physical links
   between the CEs and PEs remain up.  For example, in Figure 2, 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 these native services,
   the corresponding PWE3 service must provide a failure notification
   mechanism.

   Similarly, if a native service has notification mechanisms so that
   all the affected services will change status from "Down" to "Up" when
   a network failure is fixed, 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 [<a href="./rfc2661" title="&quot;Layer Two Tunneling Protocol &quot;">RFC2661</a>] [<a href="./rfc3931" title="and I. Goyret">RFC3931</a>] has this
   capability, and LDP has the ability to withdraw the corresponding
   MPLS label.

<span class="h4"><a class="selflink" id="section-7.3.2" href="#section-7.3.2">7.3.2</a>.  Misconnection and Payload Type Mismatch</span>

   With PWE3, misconnection and payload type mismatch can occur.
   Misconnection can breach the integrity of the system.  Payload
   mismatch can disrupt the customer network.  In both instances, there
   are security and operational concerns.





<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   The services of the underlying tunneling mechanism and its associated
   control protocol can be used to mitigate this.  As part of the PW
   setup, a PW-TYPE identifier is exchanged.  This is then used by the
   forwarder and the NSP to verify the compatibility of the ACs.

<span class="h4"><a class="selflink" id="section-7.3.3" href="#section-7.3.3">7.3.3</a>.  Packet Loss, Corruption, and Out-of-Order Delivery</span>

   A PW can incur packet loss, corruption, and out-of-order delivery on
   the PSN path between the PEs.  This can affect the working condition
   of an emulated service.  For some payload types, packet loss,
   corruption, and out-of-order delivery can be mapped either to a bit
   error burst, or to loss of carrier on the PW.  If a native service
   has some mechanism to deal with bit error, the corresponding PWE3
   service should provide a similar mechanism.

<span class="h4"><a class="selflink" id="section-7.3.4" href="#section-7.3.4">7.3.4</a>.  Other Status Notification</span>

   A PWE3 approach may provide a mechanism for other status
   notifications, if any are needed.

<span class="h4"><a class="selflink" id="section-7.3.5" href="#section-7.3.5">7.3.5</a>.  Collective Status Notification</span>

   The status of a group of emulated services may be affected
   identically by a single network incident.  For example, when the
   physical link (or sub-network) between a CE and a PE fails, all the
   emulated services that go through that link (or sub-network) will
   fail.  It is likely that a group of emulated services all terminate
   at a remote CE.  There may also be multiple such CEs affected by the
   failure.  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 a mechanism for notifying status changes
   of a group of emulated circuits.  One possible method 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 the same group ID.  In status notification,
   this group ID can be used to refer all the emulated services in that
   group.  The group ID mechanism should be a mechanism provided by the
   underlying tunnel signaling protocol.

<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>.  Keep-Alive</span>

   If a native service has a keep-alive mechanism, the corresponding
   emulated service must provide a mechanism to propagate it across the
   PW.  Transparently transporting keep-alive messages over the PW would
   follow the principle of minimum intervention.  However, to reproduce




<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   the semantics of the native mechanism accurately, some PWs may
   require an alternative approach, such as piggy-backing on the PW
   signaling mechanism.

<span class="h3"><a class="selflink" id="section-7.5" href="#section-7.5">7.5</a>.  Handling Control Messages of the Native Services</span>

   Some native services use control messages for circuit maintenance.
   These control messages may be in-band (e.g., Ethernet flow control,
   ATM performance management, or TDM tone signaling) or out-of-band,
   (e.g., the signaling VC of an ATM VP, or TDM CCS signaling).

   Given 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.  This principle should not,
   however, override the need to emulate the native service
   satisfactorily.

   If control messages are passed through, it may be desirable to send
   them by using either a higher priority or a reliable channel provided
   by the PW Demultiplexer layer.  See <a href="#section-5.1.2">Section 5.1.2</a>, PWE3 Channel
   Types.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Management and Monitoring</span>

   This section describes the management and monitoring architecture for
   PWE3.

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  Status and Statistics</span>

   The PE should report the status of the interface and tabulate
   statistics that help monitor the state of the network and help
   measure service-level agreements (SLAs).  Typical counters include
   the following:

       o Counts of PW-PDUs sent and received, with and without errors.
       o Counts of sequenced PW-PDUs lost.
       o Counts of service PDUs sent and received over the PSN, with and
         without errors (non-TDM).
       o Service-specific interface counts.
       o One-way delay and delay variation.

   These counters would be contained in a PW-specific MIB, and they
   should not replicate existing MIB counters.








<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  PW SNMP MIB Architecture</span>

   This section describes the general architecture for SNMP MIBs used to
   manage PW services and the underlying PSN.  The intent here is to
   provide a clear picture of how all the pertinent MIBs fit together to
   form a cohesive management framework for deploying PWE3 services.
   Note that the names of MIB modules used below are suggestions and do
   not necessarily require that the actual modules used to realize the
   components in the architecture be named exactly so.

<span class="h4"><a class="selflink" id="section-8.2.1" href="#section-8.2.1">8.2.1</a>.  MIB Layering</span>

   The SNMP MIBs created for PWE3 should fit the architecture shown in
   Figure 12.  The architecture provides a layered modular model into
   which any supported emulated service can be connected to any
   supported PSN type.  This model fosters reuse of as much
   functionality as possible.  For instance, the emulated service layer
   MIB modules do not redefine the existing emulated service MIB module;
   rather, they only associate it with the pseudo wires used to carry
   the emulated service over the configured PSN.  In this way, the PWE3
   MIB architecture follows the overall PWE3 architecture.

   The architecture does allow for the joining of unsupported emulated
   service or PSN types by simply defining additional MIB modules to
   associate new types with existing ones.  These new modules can
   subsequently be standardized.  Note that there is a separate MIB
   module for each emulated service, as well as one for each underlying
   PSN.  These MIB modules may be used in various combinations as
   needed.






















<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


       Native
    Service MIBs    ...           ...               ...
                     |             |                 |
               +-----------+ +-----------+     +-----------+
     Service   |    CEP    | | Ethernet  |     |    ATM    |
      Layer    |Service MIB| |Service MIB| ... |Service MIB|
               +-----------+ +-----------+     +-----------+
                       \           |             /
                         \         |           /
   - - - - - - - - - - - - \ - - - | - - - - / - - - - - - -
                             \     |       /
               +-------------------------------------------+
    Generic PW |            Generic PW MIBs                |
      Layer    +-------------------------------------------+
                            /             \
   - - - - - - - - - - - - / - - - - - - - - \ - - - - - - -
                         /                     \
                       /                         \
               +--------------+             +----------------+
     PSN VC    |L2TP VC MIB(s)|             | MPLS VC MIB(s) |
      Layer    +--------------+             +----------------+
                      |                              |
     Native     +-----------+                  +-----------+
      PSN       |L2TP MIB(s)|                  |MPLS MIB(s)|
      MIBs      +-----------+                  +-----------+

               Figure 12.  MIB Module Layering Relationship
























<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   Figure 13 shows an example for a SONET PW carried over MPLS Traffic
   Engineering Tunnel and an LDP-signaled LSP.

                            +-----------------+
                            |    SONET MIB    |  <a href="./rfc3592">RFC3592</a>
                            +-----------------+
                                     |
                       +------------------------------+
            Service    | Circuit Emulation Service MIB|
             Layer     +------------------------------+
           - - - - - - - - - - - - - | - - - - - - - - - - - - -
                            +-----------------+
           Generic PW       | Generic PW MIB  |
             Layer          +-----------------+
           - - - - - - - - - - - - - | - - - - - - - - - - - - -
                            +-----------------+
             PSN VC         |   MPLS VC MIBs  |
             Layer          +-----------------+
                               |           |
                  +-----------------+  +------------------+
                  | MPLS-TE-STD-MIB |  | MPLS-LSR-STD-MIB |
                  +-----------------+  +------------------+

            Figure 13.  SONET PW over MPLS PSN Service-Specific Example

<span class="h4"><a class="selflink" id="section-8.2.2" href="#section-8.2.2">8.2.2</a>.  Service Layer MIB Modules</span>

   This conceptual layer in the model contains MIB modules used to
   represent the relationship between emulated PWE3 services such as
   Ethernet, ATM, or Frame Relay and the pseudo-wire used to carry that
   service across the PSN.  This layer contains corresponding MIB
   modules used to mate or adapt those emulated services to the generic
   pseudo-wire representation these are represented in the "Generic PW
   MIB" functional block in Figure 13 above.  This working group should
   not produce any MIB modules for managing the general service; rather,
   it should produce just those modules used to interface or adapt the
   emulated service onto the PWE3 management framework as shown above.
   For example, the standard SONET-MIB [<a href="./rfc3592" title="&quot;Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type&quot;">RFC3592</a>] is designed and
   maintained by another working group.  The SONET-MIB is designed to
   manage the native service without PW emulation.  However, the PWE3
   working group is chartered to produce standards that show how to
   emulate existing technologies such as SONET/SDH over pseudo-wires
   rather than reinvent those modules.








<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


<span class="h4"><a class="selflink" id="section-8.2.3" href="#section-8.2.3">8.2.3</a>.  Generic PW MIB Modules</span>

   The middle layer in the architecture is referred to as the Generic PW
   Layer.  MIBs in this layer are responsible for providing pseudo-wire
   specific counters and service models used for monitoring and
   configuration of PWE3 services over any supported PSN service.  That
   is, this layer provides a general model of PWE3 abstraction for
   management purposes.  This MIB is used to interconnect the MIB
   modules residing in the Service Layer to the PSN VC Layer MIBs (see
   <a href="#section-8.2.4">section 8.2.4</a>).

<span class="h4"><a class="selflink" id="section-8.2.4" href="#section-8.2.4">8.2.4</a>.  PSN VC Layer MIB Modules</span>

   The third layer in the PWE3 management architecture is referred to as
   the PSN VC Layer.  It is composed of MIBs that are specifically
   designed to associate pseudo-wires onto those underlying PSN
   transport technologies that carry the pseudo-wire payloads across the
   PSN.  In general, this means that the MIB module provides a mapping
   between the emulated service that is mapped to the pseudo-wire via
   the Service Layer and the Generic PW MIB Layer onto the native PSN
   service.  For example, in the case of MPLS, for example, it is
   required that the general VC service be mapped into MPLS LSPs via the
   MPLS-LSR-STD-MIB [<a href="./rfc3813" title="&quot;Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)&quot;">RFC3813</a>] or Traffic-Engineered (TE) Tunnels via the
   MPLS-TE-STD-MIB [<a href="./rfc3812" title="&quot;Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)&quot;">RFC3812</a>].  In addition, the MPLS-LDP-STD-MIB
   [<a href="./rfc3815" title="&quot;Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)&quot;">RFC3815</a>] may be used to reveal the MPLS labels that are distributed
   over the MPLS PSN in order to maintain the PW service.  As with the
   native service MIB modules described earlier, the MIB modules used to
   manage the native PSN services are produced by other working groups
   that design and specify the native PSN services.  These MIBs should
   contain the appropriate mechanisms for monitoring and configuring the
   PSN service that the emulated PWE3 service will function correctly.

<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>.  Connection Verification and Traceroute</span>

   A connection verification mechanism should be supported by PWs.
   Connection verification and other alarm mechanisms can alert the
   operator that a PW has lost its remote connection.  The opaque nature
   of a PW means that it is not possible to specify a generic connection
   verification or traceroute mechanism that passes this status to the
   CEs over the PW.  If connection verification status of the PW is
   needed by the CE, it must be mapped to the native connection status
   method.

   For troubleshooting purposes, it is sometimes desirable to know the
   exact functional path of a PW between PEs.  This is provided by the
   traceroute service of the underlying PSN.  The opaque nature of the
   PW means that this traceroute information is only available within
   the provider network; e.g., at the PEs.



<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  IANA Considerations</span>

   IANA considerations will be identified in the PWE3 documents that
   define the PWE3 encapsulation, control, and management protocols.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  Security Considerations</span>

   PWE3 provides no means of protecting the integrity, confidentiality,
   or delivery of the native data units.  The use of PWE3 can therefore
   expose a particular environment to additional security threats.
   Assumptions that might be appropriate when all communicating systems
   are interconnected via a point-to-point or circuit-switched network
   may no longer hold when they are interconnected with an emulated wire
   carried over some types of PSN.  It is outside the scope of this
   specification to fully analyze and review the risks of PWE3,
   particularly as these risks will depend on the PSN.  An example
   should make the concern clear.  A number of IETF standards employ
   relatively weak security mechanisms when communicating nodes are
   expected to be connected to the same local area network.  The Virtual
   Router Redundancy Protocol [<a href="./rfc3768" title="&quot;Virtual Router Redundancy Protocol (VRRP)&quot;">RFC3768</a>] is one instance.  The relatively
   weak security mechanisms represent a greater vulnerability in an
   emulated Ethernet connected via a PW.

   Exploitation of vulnerabilities from within the PSN may be directed
   to the PW Tunnel end point so that PW Demultiplexer and PSN tunnel
   services are disrupted.  Controlling PSN access to the PW Tunnel end
   point is one way to protect against this.  By restricting PW Tunnel
   end point access to legitimate remote PE sources of traffic, the PE
   may reject traffic that would interfere with the PW Demultiplexing
   and PSN tunnel services.

   Protection mechanisms must also address the spoofing of tunneled PW
   data.  The validation of traffic addressed to the PW Demultiplexer
   end-point is paramount in ensuring integrity of PW encapsulation.
   Security protocols such as IPSec [<a href="./rfc2401" title="&quot;Security Architecture for the Internet Protocol&quot;">RFC2401</a>] may be used by the PW
   Demultiplexer Layer in order provide authentication and data
   integrity of the data between the PW Demultiplexer End-points.

   IPSec may provide authentication, integrity, and confidentiality, of
   data transferred between two PEs.  It cannot provide the equivalent
   services to the native service.

   Based on the type of data being transferred, the PW may indicate to
   the PW Demultiplexer Layer that enhanced security services are
   required.  The PW Demultiplexer 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,



<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   the PW Demultiplexer Layer may use peer authentication for every PSN
   packet to prevent spoofed native data units from being sent to the
   destination CE.

   The unlimited transformation capability of the NSP may be perceived
   as a security risk.  In practice the type of operation that the NSP
   may perform will be limited to those that have been implemented in
   the data path.  A PE designed and managed to best current practice
   will have controls in place that protect and validate its
   configuration, and these will be sufficient to ensure that the NSP
   behaves as expected.

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  Acknowledgements</span>

   We thank Sasha Vainshtein for his work on Native Service Processing
   and advice on bit stream over PW services and Thomas K. Johnson for
   his work on the background and motivation for PWs.

   We also thank Ron Bonica, Stephen Casner, Durai Chinnaiah, Jayakumar
   Jayakumar, Ghassem Koleyni, Danny McPherson, Eric Rosen, John
   Rutemiller, Scott Wainner, and David Zelig for their comments and
   contributions.

<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>.  References</span>

<span class="h3"><a class="selflink" id="section-12.1" href="#section-12.1">12.1</a>.  Normative References</span>

   [<a id="ref-RFC3931">RFC3931</a>]   Lau, J., Townsley, M., and I. Goyret, "Layer Two
               Tunneling Protocol - Version 3 (L2TPv3), <a href="./rfc3931">RFC 3931</a>, March
               2005.

   [<a id="ref-RFC768">RFC768</a>]    Postel, J., "User Datagram Protocol", STD 6, <a href="./rfc768">RFC 768</a>,
               August 1980.

   [<a id="ref-RFC2401">RFC2401</a>]   Kent, S. and R. Atkinson, "Security Architecture for the
               Internet Protocol", <a href="./rfc2401">RFC 2401</a>, November 1998.

   [<a id="ref-RFC2474">RFC2474</a>]   Nichols, K., Blake, S., Baker, F., and D. Black,
               "Definition of the Differentiated Services Field (DS
               Field) in the IPv4 and IPv6 Headers", <a href="./rfc2474">RFC 2474</a>, December
               1998.

   [<a id="ref-RFC3592">RFC3592</a>]   Tesink, K., "Definitions of Managed Objects for the
               Synchronous Optical Network/Synchronous Digital Hierarchy
               (SONET/SDH) Interface Type", <a href="./rfc3592">RFC 3592</a>, September 2003.






<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   [<a id="ref-RFC2661">RFC2661</a>]   Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
               G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
               <a href="./rfc2661">RFC 2661</a>, August 1999.

   [<a id="ref-RFC2784">RFC2784</a>]   Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
               Traina, "Generic Routing Encapsulation (GRE)", <a href="./rfc2784">RFC 2784</a>,
               March 2000.

   [<a id="ref-RFC2890">RFC2890</a>]   Dommety, G., "Key and Sequence Number Extensions to GRE",
               <a href="./rfc2890">RFC 2890</a>, September 2000.

   [<a id="ref-RFC3032">RFC3032</a>]   Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
               Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
               Encoding", <a href="./rfc3032">RFC 3032</a>, January 2001.

   [<a id="ref-RFC3550">RFC3550</a>]   Schulzrinne, H.,  Casner, S., Frederick, R., and V.
               Jacobson, "RTP: A Transport Protocol for Real-Time
               Applications", STD 64, <a href="./rfc3550">RFC 3550</a>, July 2003.

<span class="h3"><a class="selflink" id="section-12.2" href="#section-12.2">12.2</a>. Informative References</span>

   [<a id="ref-DVB">DVB</a>]       EN 300 744 Digital Video Broadcasting (DVB); Framing
               structure, channel coding and modulation for digital
               terrestrial television (DVB-T), European
               Telecommunications Standards Institute (ETSI).

   [<a id="ref-RFC3815">RFC3815</a>]   Cucchiara, J., Sjostrand, H., and J. Luciani,
               "Definitions of Managed Objects for the Multiprotocol
               Label Switching (MPLS), Label Distribution Protocol
               (LDP)", <a href="./rfc3815">RFC 3815</a>, June 2004.

   [<a id="ref-RFC3813">RFC3813</a>]   Srinivasan, C., Viswanathan, A., and T. Nadeau,
               "Multiprotocol Label Switching (MPLS) Label Switching
               Router (LSR) Management Information Base (MIB)", <a href="./rfc3813">RFC</a>
               <a href="./rfc3813">3813</a>, June 2004.

   [<a id="ref-MPLSIP">MPLSIP</a>]    Rosen et al, "Encapsulating MPLS in IP or Generic Routing
               Encapsulation (GRE)", Work in Progress, March 2004.

   [<a id="ref-RFC1191">RFC1191</a>]   Mogul, J. and S. Deering, "Path MTU discovery", <a href="./rfc1191">RFC 1191</a>,
               November 1990.

   [<a id="ref-RFC1958">RFC1958</a>]   Carpenter, B., "Architectural Principles of the
               Internet", <a href="./rfc1958">RFC 1958</a>, June 1996.

   [<a id="ref-RFC1981">RFC1981</a>]   McCann, J., Deering, S., and J. Mogul, "Path MTU
               Discovery for IP version 6", <a href="./rfc1981">RFC 1981</a>, August 1996.




<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   [<a id="ref-RFC2022">RFC2022</a>]   Armitage, G., "Support for Multicast over UNI 3.0/3.1
               based ATM Networks", <a href="./rfc2022">RFC 2022</a>, November 1996.

   [<a id="ref-RFC3768">RFC3768</a>]   Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
               <a href="./rfc3768">RFC 3768</a>, April 2004.

   [<a id="ref-RFC3022">RFC3022</a>]   Srisuresh, P. and K. Egevang, "Traditional IP Network
               Address Translator (Traditional NAT)", <a href="./rfc3022">RFC 3022</a>, January
               2001.

   [<a id="ref-RFC3448">RFC3448</a>]   Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
               Friendly Rate Control (TFRC): Protocol Specification",
               <a href="./rfc3448">RFC 3448</a>, January 2003.

   [<a id="ref-RFC3812">RFC3812</a>]   Srinivasan, C., Viswanathan, A., and T. Nadeau,
               "Multiprotocol Label Switching (MPLS) Traffic Engineering
               (TE) Management Information Base (MIB)", <a href="./rfc3812">RFC 3812</a>, June
               2004.

   [<a id="ref-RFC3916">RFC3916</a>]   Xiao, X., McPherson, D., and P. Pate, Eds, "Requirements
               for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", <a href="./rfc3916">RFC 3916</a>,
               September 2004.

<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>.  Co-Authors</span>

   The following are co-authors of this document:

   Thomas K. Johnson
   Litchfield Communications

   Kireeti Kompella
   Juniper Networks, Inc.

   Andrew G. Malis
   Tellabs

   Thomas D. Nadeau
   Cisco Systems

   Tricci So
   Caspian Networks

   W. Mark Townsley
   Cisco Systems







<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 40]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-41" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


   Craig White
   Level 3 Communications, LLC.

   Lloyd Wood
   Cisco Systems

<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>.  Editors' Addresses</span>

   Stewart Bryant
   Cisco Systems
   250, Longwater
   Green Park
   Reading, RG2 6GB,
   United Kingdom

   EMail: stbryant@cisco.com


   Prayson Pate
   Overture Networks, Inc.
   507 Airport Boulevard
   Morrisville, NC, USA 27560

   EMail: prayson.pate@overturenetworks.com



























<span class="grey">Bryant &amp; Pate               Standards Track                    [Page 41]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-42" ></span>
<span class="grey"><a href="./rfc3985">RFC 3985</a>                   PWE3 Architecture                  March 2005</span>


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Bryant &amp; Pate               Standards Track                    [Page 42]
</pre>