From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc3985.txt | 2355 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 2355 insertions(+)
 create mode 100644 doc/rfc/rfc3985.txt

(limited to 'doc/rfc/rfc3985.txt')

diff --git a/doc/rfc/rfc3985.txt b/doc/rfc/rfc3985.txt
new file mode 100644
index 0000000..42ece65
--- /dev/null
+++ b/doc/rfc/rfc3985.txt
@@ -0,0 +1,2355 @@
+
+
+
+
+
+
+Network Working Group                                     S. Bryant, Ed.
+Request for Comments: 3985                                 Cisco Systems
+Category: Informational                                     P. Pate, Ed.
+                                                 Overture Networks, Inc.
+                                                              March 2005
+
+
+         Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture
+
+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
+
+   1.   Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  2
+        1.1.  Pseudo Wire Definition. . . . . . . . . . . . . . . . .  2
+        1.2.  PW Service Functionality. . . . . . . . . . . . . . . .  3
+        1.3.  Non-Goals of This Document. . . . . . . . . . . . . . .  4
+        1.4.  Terminology . . . . . . . . . . . . . . . . . . . . . .  4
+   2.   PWE3 Applicability. . . . . . . . . . . . . . . . . . . . . .  6
+   3.   Protocol Layering Model . . . . . . . . . . . . . . . . . . .  6
+        3.1.  Protocol Layers . . . . . . . . . . . . . . . . . . . .  7
+        3.2.  Domain of PWE3. . . . . . . . . . . . . . . . . . . . .  8
+        3.3.  Payload Types . . . . . . . . . . . . . . . . . . . . .  8
+   4.   Architecture of Pseudo Wires. . . . . . . . . . . . . . . . . 11
+        4.1.  Network Reference Model . . . . . . . . . . . . . . . . 12
+        4.2.  PWE3 Pre-processing . . . . . . . . . . . . . . . . . . 12
+        4.3.  Maintenance Reference Model . . . . . . . . . . . . . . 16
+        4.4.  Protocol Stack Reference Model. . . . . . . . . . . . . 17
+        4.5.  Pre-processing Extension to Protocol Stack Reference
+              Model . . . . . . . . . . . . . . . . . . . . . . . . . 17
+   5.   PW Encapsulation. . . . . . . . . . . . . . . . . . . . . . . 18
+
+
+
+Bryant & Pate               Standards Track                     [Page 1]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+        5.1.  Payload Convergence Layer . . . . . . . . . . . . . . . 19
+        5.2.  Payload-independent PW Encapsulation Layers . . . . . . 21
+        5.3.  Fragmentation . . . . . . . . . . . . . . . . . . . . . 24
+        5.4.  Instantiation of the Protocol Layers. . . . . . . . . . 24
+   6.   PW Demultiplexer Layer and PSN Requirements . . . . . . . . . 27
+        6.1.  Multiplexing. . . . . . . . . . . . . . . . . . . . . . 27
+        6.2.  Fragmentation . . . . . . . . . . . . . . . . . . . . . 28
+        6.3.  Length and Delivery . . . . . . . . . . . . . . . . . . 28
+        6.4.  PW-PDU Validation . . . . . . . . . . . . . . . . . . . 28
+        6.5.  Congestion Considerations . . . . . . . . . . . . . . . 28
+   7.   Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 29
+        7.1.  Set-up or Teardown of Pseudo Wires. . . . . . . . . . . 29
+        7.2.  Status Monitoring . . . . . . . . . . . . . . . . . . . 30
+        7.3.  Notification of Pseudo Wire Status Changes. . . . . . . 30
+        7.4.  Keep-alive. . . . . . . . . . . . . . . . . . . . . . . 31
+        7.5.  Handling Control Messages of the Native Services. . . . 32
+   8.   Management and Monitoring . . . . . . . . . . . . . . . . . . 32
+        8.1.  Status and Statistics . . . . . . . . . . . . . . . . . 32
+        8.2.  PW SNMP MIB Architecture. . . . . . . . . . . . . . . . 33
+        8.3.  Connection Verification and Traceroute. . . . . . . . . 36
+   9.   IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
+   10.  Security Considerations . . . . . . . . . . . . . . . . . . . 37
+   11.  Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 38
+   12.  References. . . . . . . . . . . . . . . . . . . . . . . . . . 38
+        12.1.  Normative References . . . . . . . . . . . . . . . . . 38
+        12.2.  Informative References . . . . . . . . . . . . . . . . 39
+   13.  Co-Authors. . . . . . . . . . . . . . . . . . . . . . . . . . 40
+   14.  Editors' Addresses. . . . . . . . . . . . . . . . . . . . . . 41
+        Full Copyright Statement. . . . . . . . . . . . . . . . . . . 42
+
+1.  Introduction
+
+   This document describes an architecture for Pseudo Wire Emulation
+   Edge-to-Edge (PWE3) in support of [RFC3916].  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.
+
+1.1.  Pseudo Wire Definition
+
+   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
+
+
+
+Bryant & Pate               Standards Track                     [Page 2]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   (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.
+
+1.2.  PW Service Functionality
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+Bryant & Pate               Standards Track                     [Page 3]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+1.3.  Non-Goals of This Document
+
+   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 [RFC2022] that are
+         implemented on top of the medium are not.
+      o  Methods to signal or control the underlying PSN.
+
+1.4.  Terminology
+
+   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.
+
+
+
+
+Bryant & Pate               Standards Track                     [Page 4]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   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.
+
+
+
+
+Bryant & Pate               Standards Track                     [Page 5]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   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.
+
+2.  PWE3 Applicability
+
+   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.
+
+3.  Protocol Layering Model
+
+   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.
+
+
+
+
+Bryant & Pate               Standards Track                     [Page 6]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+3.1.  Protocol Layers
+
+   The logical protocol-layering model required to support a PW is shown
+   in Figure 1.
+
+          +---------------------------+
+          |         Payload           |
+          +---------------------------+
+          |      Encapsulation        | <==== may be empty
+          +---------------------------+
+          |     PW Demultiplexer      |
+          +---------------------------+
+          |     PSN Convergence       | <==== 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.
+
+
+
+
+
+
+Bryant & Pate               Standards Track                     [Page 7]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   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.
+
+3.2.  Domain of PWE3
+
+   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.
+
+3.3.  Payload Types
+
+   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).
+
+3.3.1.  Packet Payload
+
+   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
+
+
+
+Bryant & Pate               Standards Track                     [Page 8]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   the service and attaches to the service provider via Ethernet, or
+   when nested pseudo-wires are involved.  Fragmentation is discussed in
+   more detail in section 5.3.
+
+   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.
+
+3.3.2.  Cell Payload
+
+   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 [DVB].
+
+   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.
+
+
+
+Bryant & Pate               Standards Track                     [Page 9]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+3.3.3.  Bit Stream
+
+   A bit stream payload is created by capturing, transporting, and
+   replaying the bit pattern on the emulated wire, without taking
+   advantage of any structure that, on inspection, may be visible within
+   the relayed traffic (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.
+
+3.3.4.  Structured Bit Stream
+
+   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 section 3.3.2.
+
+   This service requires sequencing and real-time support.
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 10]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+3.3.5.  Principle of Minimum Intervention
+
+   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
+   [RFC1958].
+
+   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.
+
+4.  Architecture of Pseudo Wires
+
+   This section describes the PWE3 architectural model.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 11]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+4.1.  Network Reference Model
+
+   Figure 2 illustrates the network reference model for point-to-point
+   PWs.
+
+            |<-------------- Emulated Service ---------------->|
+            |                                                  |
+            |          |<------- Pseudo Wire ------>|          |
+            |          |                            |          |
+            |          |    |<-- PSN Tunnel -->|    |          |
+            |          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.
+
+4.2.  PWE3 Pre-processing
+
+   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
+
+
+
+Bryant & Pate               Standards Track                    [Page 12]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   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
+                        |
+                        |<------- Pseudo Wire ------>|
+                        |                            |
+                        |    |<-- PSN Tunnel -->|    |
+                        V    V                  V    V     PW
+                  +-----+----+                  +----+ End Service
+       +-----+    |PREP | PE1|==================| PE2|     |    +-----+
+       |     |    |     |............PW1.............|----------|     |
+       | CE1 |----|     |    |                  |    |     |    | CE2 |
+       |     | ^  |     |............PW2.............|----------|     |
+       +-----+ |  |     |    |==================|    |     | ^  +-----+
+               |  +-----+----+                  +----+     | |
+               |        ^                                  | |
+               |        |                                  | |
+               |        |<------- Emulated Service ------->| |
+               |        |                                    |
+               | 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.
+
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 13]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   The required pre-processing can be divided into two components:
+
+       o Forwarder (FWRD)
+       o Native Service Processing (NSP)
+
+4.2.1.  Forwarders
+
+   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
+       <------>o   Forwarder     +      PW Instance     X<===========>
+               |                 |                      |
+               +----------------------------------------+
+
+                   Figure 4a.  Simple Point-to-Point Service
+
+               +----------------------------------------+
+               |                PE Device               |
+               +----------------------------------------+
+       Multiple|                 |        Single        | PW Instance
+       AC      |                 +      PW Instance     X<===========>
+       <------>o                 |                      |
+               |                 |----------------------|
+       <------>o                 |        Single        | PW Instance
+               |    Forwarder    +      PW Instance     X<===========>
+       <------>o                 |                      |
+               |                 |----------------------|
+       <------>o                 |        Single        | PW Instance
+               |                 +      PW Instance     X<===========>
+       <------>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
+
+
+
+Bryant & Pate               Standards Track                    [Page 14]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   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.
+
+4.2.2.  Native Service Processing
+
+   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
+        <------>o  NSP #          +      PW Instance     X<===========>
+                |      |          |                      |
+                |------|          |----------------------|
+                |      |          |        Single        | PW Instance
+        <------>o  NSP #Forwarder +      PW Instance     X<===========>
+                |      |          |                      |
+                |------|          |----------------------|
+                |      |          |        Single        | PW Instance
+        <------>o  NSP #          +      PW Instance     X<===========>
+                |      |          |                      |
+                +----------------------------------------+
+
+          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.
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 15]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   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.
+
+4.3.  Maintenance Reference Model
+
+   Figure 6 illustrates the maintenance reference model for PWs.
+
+             |<------- CE (end-to-end) Signaling ------>|
+             |     |<---- PW/PE Maintenance ----->|     |
+             |     |     |<-- PSN Tunnel -->|     |     |
+             |     |     |    Signaling     |     |     |
+             |     V     V  (out of scope)  V     V     |
+             v     +-----+                  +-----+     v
+       +-----+     | PE1 |==================| PE2 |     +-----+
+       |     |-----|.............PW1..............|-----|     |
+       | CE1 |     |     |                  |     |     | CE2 |
+       |     |-----|.............PW2..............|-----|     |
+       +-----+     |     |==================|     |     +-----+
+                   +-----+                  +-----+
+       Customer   Provider                 Provider     Customer
+        Edge 1     Edge 1                   Edge 2       Edge 2
+
+                  Figure 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.
+
+
+
+
+
+
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 16]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+4.4.  Protocol Stack Reference Model
+
+   Figure 7 illustrates the protocol stack reference model for PWs.
+
+    +-----------------+                           +-----------------+
+    |Emulated Service |                           |Emulated Service |
+    |(e.g., TDM, ATM) |<==== Emulated Service ===>|(e.g., TDM, ATM) |
+    +-----------------+                           +-----------------+
+    |    Payload      |                           |    Payload      |
+    |  Encapsulation  |<====== Pseudo Wire ======>|  Encapsulation  |
+    +-----------------+                           +-----------------+
+    |PW Demultiplexer |                           |PW Demultiplexer |
+    |   PSN Tunnel,   |<======= PSN Tunnel ======>|  PSN Tunnel,    |
+    | PSN & Physical  |                           | PSN & 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.
+
+4.5.  Pre-processing Extension to Protocol Stack Reference Model
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 17]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+     /======================================\
+     H             Forwarder                H<----Pre-processing
+     H----------------======================/
+     H Native Service H   |                 |
+     H  Processing    H   |                 |
+     \================/   |                 |
+     |                |   | Emulated        |
+     | Service        |   | Service         |
+     | Interface      |   | (TDM, ATM,      |
+     | (TDM, ATM,     |   | Ethernet,       |<== Emulated Service ==
+     | Ethernet,      |   | Frame Relay,    |
+     | Frame Relay,   |   | etc.)           |
+     | etc.)          |   +-----------------+
+     |                |   |    Payload      |
+     |                |   | Encapsulation   |<=== Pseudo Wire ======
+     |                |   +-----------------+
+     |                |   |PW Demultiplexer |
+     |                |   |  PSN Tunnel,    |
+     |                |   | PSN & Physical  |<=== PSN Tunnel =======
+     |                |   |    Headers      |
+     +----------------+   +-----------------+
+     |   Physical     |   |   Physical      |
+     +-------+--------+   +-------+---------+
+             |                    |
+             |                    |
+             |                    |
+             |                    |
+             |                    |
+             |                    |
+   To CE <---+                    +---> To PSN
+
+       Figure 8.  Protocol Stack Reference Model with Pre-processing
+
+5.  PW Encapsulation
+
+   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.
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 18]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+          +---------------------------+
+          |         Payload           |
+          /===========================\ <------ 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.
+
+5.1.  Payload Convergence Layer
+
+5.1.1.  Encapsulation
+
+   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.
+
+
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 19]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   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.
+
+5.1.2.  PWE3 Channel Types
+
+   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
+      [RFC2474].
+
+   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
+   [RFC3022], 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
+
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 20]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   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.
+
+5.1.3.  Quality of Service Considerations
+
+   Where possible, it is desirable to employ mechanisms to provide PW
+   Quality of Service (QoS) support over PSNs.
+
+5.2.  Payload-Independent PW Encapsulation Layers
+
+   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.
+
+5.2.1.  Sequencing
+
+   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.
+
+
+
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 21]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   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.
+
+5.2.1.1.  Frame Ordering
+
+   When packets carrying the PW-PDUs traverse a PSN, they may arrive out
+   of order at the destination PE.  For some services, the frames
+   (control frames, data frames, or both) 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 [RFC3550] 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.
+
+5.2.1.2.  Frame Duplication Detection
+
+   In rare cases, packets traversing a PW may be duplicated by the
+   underlying PSN.  For some services, frame duplication is not
+   acceptable.  For 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.
+
+
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 22]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+5.2.1.3.  Frame Loss Detection
+
+   A destination PE can determine whether a frame has been lost by
+   tracking the sequence numbers of the 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.
+
+5.2.2.  Timing
+
+   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.
+
+5.2.2.1.  Clock Recovery
+
+   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 [RFC3550] be
+   used for this purpose, unless it can be shown that this is unsuitable
+   or unnecessary for a particular payload type.
+
+5.2.2.2.  Timed Delivery
+
+   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.
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 23]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+5.3.  Fragmentation
+
+   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., [RFC1191], [RFC1981]) 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.
+
+5.4.  Instantiation of the Protocol Layers
+
+   This document does not address the detailed mapping of the Protocol
+   Layering model to existing or future IETF standards.  The
+   instantiation of the logical Protocol Layering model is shown in
+   Figure 9.
+
+
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 24]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+5.4.1.  PWE3 over an IP PSN
+
+   The protocol definition of PWE3 over an IP PSN should employ existing
+   IETF protocols where possible.
+
+       +---------------------+              +-------------------------+
+       |      Payload        |------------->| Raw payload if possible |
+       /=====================\              +-------------------------+
+       H Payload Convergence H-----------+->|     Flags, seq #, etc.  |
+       H---------------------H          /   +-------------------------+
+       H       Timing        H---------/--->|            RTP          |
+       H---------------------H        /     +-------------+           |
+       H     Sequencing      H----one of    |             |
+       \=====================/        \     |             +-----------+
+       |  PW Demultiplexer   |---------+--->|     L2TP, MPLS, etc.    |
+       +---------------------+              +-------------------------+
+       |  PSN Convergence    |------------->|       Not needed        |
+       +---------------------+              +-------------------------+
+       |        PSN          |------------->|            IP           |
+       +---------------------+              +-------------------------+
+       |      Data-Link      |------------->|         Data-link       |
+       +---------------------+              +-------------------------+
+       |       Physical      |------------->|          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 [RFC3550],
+   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.
+
+
+
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 25]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   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
+   [MPLSIP], an L2TP session ID [RFC3931], or a UDP port number
+   [RFC768].  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 section 5.4.2 can be used instead of the
+   protocol architecture of this section.
+
+5.4.2.  PWE3 over an MPLS PSN
+
+   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--------->|              RTP               |
+   H---------------------H  |       +--------------------------------+
+   H     Sequencing      H--+------>| Flags, Frag, Len, Seq #, etc   |
+   \=====================/  |       +--------------------------------+
+   |  PW Demultiplexer   |--------->|           PW Label             |
+   +---------------------+  |       +--------------------------------+
+   |  PSN Convergence    |--+  +--->| 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
+
+
+
+Bryant & Pate               Standards Track                    [Page 26]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   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 [RFC3550].
+
+   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 [RFC2784], [RFC2890]) is applied to the
+   resultant PW-PDU.
+
+5.4.3.  PW-IP Packet Discrimination
+
+   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.
+
+6.  PW Demultiplexer Layer and PSN Requirements
+
+   PWE3 places three service requirements on the protocol layers used to
+   carry it across the PSN:
+
+       o Multiplexing
+       o Fragmentation
+       o Length and Delivery
+
+6.1.  Multiplexing
+
+   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 [RFC3032] in the PW label is application specific.
+
+
+
+
+
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 27]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+6.2.  Fragmentation
+
+   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 section 5.3 for a full
+   discussion of the PW fragmentation issues.
+
+6.3.  Length and Delivery
+
+   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.
+
+6.4.  PW-PDU Validation
+
+   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.
+
+6.5.  Congestion Considerations
+
+   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.
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 28]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   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 [RFC3448].
+
+7.  Control Plane
+
+   This section describes PWE3 control plane services.
+
+7.1.  Setup or Teardown of Pseudo Wires
+
+   A PW must be set up before an emulated service can be established and
+   must be torn down when an emulated service is no longer needed.
+
+   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.
+
+
+
+Bryant & Pate               Standards Track                    [Page 29]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   Manual configuration of PWs can be considered a special kind of
+   signaling and is allowed.
+
+7.2.  Status Monitoring
+
+   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.
+
+7.3.  Notification of Pseudo Wire Status Changes
+
+7.3.1.  Pseudo Wire Up/Down Notification
+
+   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 [RFC2661] [RFC3931] has this
+   capability, and LDP has the ability to withdraw the corresponding
+   MPLS label.
+
+7.3.2.  Misconnection and Payload Type Mismatch
+
+   With PWE3, misconnection and payload type mismatch can occur.
+   Misconnection can breach the integrity of the system.  Payload
+   mismatch can disrupt the customer network.  In both instances, there
+   are security and operational concerns.
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 30]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   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.
+
+7.3.3.  Packet Loss, Corruption, and Out-of-Order Delivery
+
+   A PW can incur packet loss, corruption, and out-of-order delivery on
+   the PSN path between the PEs.  This can 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.
+
+7.3.4.  Other Status Notification
+
+   A PWE3 approach may provide a mechanism for other status
+   notifications, if any are needed.
+
+7.3.5.  Collective Status Notification
+
+   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.
+
+7.4.  Keep-Alive
+
+   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
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 31]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   the semantics of the native mechanism accurately, some PWs may
+   require an alternative approach, such as piggy-backing on the PW
+   signaling mechanism.
+
+7.5.  Handling Control Messages of the Native Services
+
+   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 Section 5.1.2, PWE3 Channel
+   Types.
+
+8.  Management and Monitoring
+
+   This section describes the management and monitoring architecture for
+   PWE3.
+
+8.1.  Status and Statistics
+
+   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.
+
+
+
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 32]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+8.2.  PW SNMP MIB Architecture
+
+   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.
+
+8.2.1.  MIB Layering
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 33]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+       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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 34]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   Figure 13 shows an example for a SONET PW carried over MPLS Traffic
+   Engineering Tunnel and an LDP-signaled LSP.
+
+                            +-----------------+
+                            |    SONET MIB    |  RFC3592
+                            +-----------------+
+                                     |
+                       +------------------------------+
+            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
+
+8.2.2.  Service Layer MIB Modules
+
+   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 [RFC3592] 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.
+
+
+
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 35]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+8.2.3.  Generic PW MIB Modules
+
+   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
+   section 8.2.4).
+
+8.2.4.  PSN VC Layer MIB Modules
+
+   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 [RFC3813] or Traffic-Engineered (TE) Tunnels via the
+   MPLS-TE-STD-MIB [RFC3812].  In addition, the MPLS-LDP-STD-MIB
+   [RFC3815] 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.
+
+8.3.  Connection Verification and Traceroute
+
+   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.
+
+
+
+Bryant & Pate               Standards Track                    [Page 36]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+9.  IANA Considerations
+
+   IANA considerations will be identified in the PWE3 documents that
+   define the PWE3 encapsulation, control, and management protocols.
+
+10.  Security Considerations
+
+   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 [RFC3768] 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 [RFC2401] 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,
+
+
+
+Bryant & Pate               Standards Track                    [Page 37]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   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.
+
+11.  Acknowledgements
+
+   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.
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC3931]   Lau, J., Townsley, M., and I. Goyret, "Layer Two
+               Tunneling Protocol - Version 3 (L2TPv3), RFC 3931, March
+               2005.
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC2401]   Kent, S. and R. Atkinson, "Security Architecture for the
+               Internet Protocol", RFC 2401, November 1998.
+
+   [RFC2474]   Nichols, K., Blake, S., Baker, F., and D. Black,
+               "Definition of the Differentiated Services Field (DS
+               Field) in the IPv4 and IPv6 Headers", RFC 2474, December
+               1998.
+
+   [RFC3592]   Tesink, K., "Definitions of Managed Objects for the
+               Synchronous Optical Network/Synchronous Digital Hierarchy
+               (SONET/SDH) Interface Type", RFC 3592, September 2003.
+
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 38]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   [RFC2661]   Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
+               G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
+               RFC 2661, August 1999.
+
+   [RFC2784]   Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
+               Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
+               March 2000.
+
+   [RFC2890]   Dommety, G., "Key and Sequence Number Extensions to GRE",
+               RFC 2890, September 2000.
+
+   [RFC3032]   Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
+               Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
+               Encoding", RFC 3032, January 2001.
+
+   [RFC3550]   Schulzrinne, H.,  Casner, S., Frederick, R., and V.
+               Jacobson, "RTP: A Transport Protocol for Real-Time
+               Applications", STD 64, RFC 3550, July 2003.
+
+12.2. Informative References
+
+   [DVB]       EN 300 744 Digital Video Broadcasting (DVB); Framing
+               structure, channel coding and modulation for digital
+               terrestrial television (DVB-T), European
+               Telecommunications Standards Institute (ETSI).
+
+   [RFC3815]   Cucchiara, J., Sjostrand, H., and J. Luciani,
+               "Definitions of Managed Objects for the Multiprotocol
+               Label Switching (MPLS), Label Distribution Protocol
+               (LDP)", RFC 3815, June 2004.
+
+   [RFC3813]   Srinivasan, C., Viswanathan, A., and T. Nadeau,
+               "Multiprotocol Label Switching (MPLS) Label Switching
+               Router (LSR) Management Information Base (MIB)", RFC
+               3813, June 2004.
+
+   [MPLSIP]    Rosen et al, "Encapsulating MPLS in IP or Generic Routing
+               Encapsulation (GRE)", Work in Progress, March 2004.
+
+   [RFC1191]   Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
+               November 1990.
+
+   [RFC1958]   Carpenter, B., "Architectural Principles of the
+               Internet", RFC 1958, June 1996.
+
+   [RFC1981]   McCann, J., Deering, S., and J. Mogul, "Path MTU
+               Discovery for IP version 6", RFC 1981, August 1996.
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 39]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   [RFC2022]   Armitage, G., "Support for Multicast over UNI 3.0/3.1
+               based ATM Networks", RFC 2022, November 1996.
+
+   [RFC3768]   Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
+               RFC 3768, April 2004.
+
+   [RFC3022]   Srisuresh, P. and K. Egevang, "Traditional IP Network
+               Address Translator (Traditional NAT)", RFC 3022, January
+               2001.
+
+   [RFC3448]   Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
+               Friendly Rate Control (TFRC): Protocol Specification",
+               RFC 3448, January 2003.
+
+   [RFC3812]   Srinivasan, C., Viswanathan, A., and T. Nadeau,
+               "Multiprotocol Label Switching (MPLS) Traffic Engineering
+               (TE) Management Information Base (MIB)", RFC 3812, June
+               2004.
+
+   [RFC3916]   Xiao, X., McPherson, D., and P. Pate, Eds, "Requirements
+               for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
+               September 2004.
+
+13.  Co-Authors
+
+   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
+
+
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 40]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+   Craig White
+   Level 3 Communications, LLC.
+
+   Lloyd Wood
+   Cisco Systems
+
+14.  Editors' Addresses
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bryant & Pate               Standards Track                    [Page 41]
+
+RFC 3985                   PWE3 Architecture                  March 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, 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 BCP 78 and BCP 79.
+
+   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
+   http://www.ietf.org/ipr.
+
+   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 & Pate               Standards Track                    [Page 42]
+
-- 
cgit v1.2.3