doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc3916.txt b/doc/rfc/rfc3916.txt
new file mode 100644
index 0000000..5e0cfce
--- /dev/null
+++ b/doc/rfc/rfc3916.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                       X. Xiao, Ed.
+Request for Comments: 3916                           Riverstone Networks
+Category: Informational                                D. McPherson, Ed.
+                                                          Arbor Networks
+                                                            P. Pate, Ed.
+                                                       Overture Networks
+                                                          September 2004
+
+
+       Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)
+
+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 (2004).
+
+Abstract
+
+   This document describes base requirements for the Pseudo-Wire
+   Emulation Edge to Edge Working Group (PWE3 WG).  It provides
+   guidelines for other working group documents that will define
+   mechanisms for providing pseudo-wire emulation of Ethernet, ATM, and
+   Frame Relay.  Requirements for pseudo-wire emulation of TDM (i.e.,
+   "synchronous bit streams at rates defined by ITU G.702") are defined
+   in another document.  It should be noted that the PWE3 WG
+   standardizes mechanisms that can be used to provide PWE3 services,
+   but not the services themselves.
+
+Table of Contents
+
+   1.   Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  2
+        1.1.  What Are Pseudo Wires?. . . . . . . . . . . . . . . . .  2
+        1.2.  Current Network Architecture. . . . . . . . . . . . . .  3
+        1.3.  PWE3 as a Path to Convergence . . . . . . . . . . . . .  4
+        1.4.  Suitable Applications for PWE3. . . . . . . . . . . . .  4
+        1.5.  Summary . . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.   Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   3.   Reference Model of PWE3 . . . . . . . . . . . . . . . . . . .  6
+   4.   Packet Processing . . . . . . . . . . . . . . . . . . . . . .  7
+        4.1.  Encapsulation . . . . . . . . . . . . . . . . . . . . .  7
+        4.2.  Frame Ordering. . . . . . . . . . . . . . . . . . . . .  8
+        4.3.  Frame Duplication . . . . . . . . . . . . . . . . . . .  8
+        4.4.  Fragmentation . . . . . . . . . . . . . . . . . . . . .  8
+
+
+
+Xiao, et al.                 Informational                      [Page 1]
+
+RFC 3916                   PWE3 Requirements              September 2004
+
+
+        4.5.  Consideration of Per-PSN Packet Overhead. . . . . . . .  9
+   5.   Maintenance of Emulated Services. . . . . . . . . . . . . . .  9
+        5.1.  Setup and Teardown of Pseudo-Wires. . . . . . . . . . .  9
+        5.2.  Handling Maintenance Message of the Native Services . . 10
+        5.3.  PE-initiated Maintenance Messages . . . . . . . . . . . 10
+   6.   Management of Emulated Services . . . . . . . . . . . . . . . 12
+        6.1.  MIBs. . . . . . . . . . . . . . . . . . . . . . . . . . 12
+        6.2.  General MIB Requirements. . . . . . . . . . . . . . . . 12
+        6.3.  Configuration and Provisioning. . . . . . . . . . . . . 13
+        6.4.  Performance Monitoring. . . . . . . . . . . . . . . . . 13
+        6.5.  Fault Management and Notifications. . . . . . . . . . . 13
+        6.6.  Pseudo-Wire Connection Verification and Traceroute. . . 13
+   7.   Faithfulness of Emulated Services . . . . . . . . . . . . . . 13
+        7.1.  Characteristics of an Emulated Service. . . . . . . . . 14
+        7.2.  Service Quality of Emulated Services. . . . . . . . . . 14
+   8.   Non-Requirements. . . . . . . . . . . . . . . . . . . . . . . 14
+   9.   Quality of Service (QoS) Considerations . . . . . . . . . . . 15
+   10.  Inter-domain Issues . . . . . . . . . . . . . . . . . . . . . 16
+   11.  Security Considerations . . . . . . . . . . . . . . . . . . . 16
+   12.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
+   13.  References. . . . . . . . . . . . . . . . . . . . . . . . . . 17
+        13.1. Normative References. . . . . . . . . . . . . . . . . . 17
+        13.2. Informative References. . . . . . . . . . . . . . . . . 17
+   14.  Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 18
+   15.  Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19
+
+1.  Introduction
+
+1.1.  What Are Pseudo Wires?
+
+   Pseudo Wire Emulation Edge-to-Edge (PWE3) is a mechanism that
+   emulates the essential attributes of a service such as ATM, Frame
+   Relay or Ethernet over a Packet Switched Network (PSN).  The required
+   functions of PWs include encapsulating service-specific PDUs arriving
+   at an ingress port, and carrying them across a path or tunnel,
+   managing their timing and order, and any other operations required to
+   emulate the behavior and characteristics of the service as faithfully
+   as possible.
+
+   From the customer perspective, the PW is perceived as an unshared
+   link or circuit of the chosen service.  However, there may be
+   deficiencies that impede some applications from being carried on a
+   PW.  These limitations should be fully described in the appropriate
+   service-specific documents and Applicability Statements.
+
+
+
+
+
+
+
+Xiao, et al.                 Informational                      [Page 2]
+
+RFC 3916                   PWE3 Requirements              September 2004
+
+
+1.2.   Current Network Architecture
+
+   The following sections give some background on where networks are
+   today and why they are changing.  It also talks about the motivation
+   to provide converged networks while continuing to support existing
+   services.  Finally, it discusses how PWs can be a solution for this
+   dilemma.
+
+1.2.1.  Multiple Networks
+
+   For any given service provider delivering multiple services, the
+   current infrastructure usually consists of parallel or "overlay"
+   networks.  Each of these networks implements a specific service, such
+   as Frame Relay, Internet access, etc.  This is expensive, both in
+   terms of capital expense and operational costs.  Furthermore, the
+   presence of multiple networks complicates planning.  Service
+   providers wind up asking themselves these questions:
+
+   - Which of my networks do I build out?
+   - How many fibers do I need for each network?
+   - How do I efficiently manage multiple networks?
+
+   A converged network helps service providers answer these questions in
+   a consistent and economical fashion.
+
+1.2.2.  Transition to a Packet-Optimized Converged Network
+
+   In order to maximize return on their assets and minimize their
+   operating costs, service providers often look to consolidate the
+   delivery of multiple service types onto a single networking
+   technology.
+
+   As packet traffic takes up a larger and larger portion of the
+   available network bandwidth, it becomes increasingly useful to
+   optimize public networks for the Internet Protocol.  However, many
+   service providers are confronting several obstacles in engineering
+   packet-optimized networks.  Although Internet traffic is the fastest
+   growing traffic segment, it does not generate the highest revenue per
+   bit.  For example, Frame Relay traffic currently generates higher
+   revenue per bit than native IP services do.  Private line TDM
+   services still generate even more revenue per bit than does Frame
+   Relay.  In addition, there is a tremendous amount of legacy equipment
+   deployed within public networks that does not communicate using the
+   Internet Protocol.  Service providers continue to utilize non-IP
+   equipment to deploy a variety of services, and see a need to
+   interconnect this legacy equipment over their IP-optimized core
+   networks.
+
+
+
+
+Xiao, et al.                 Informational                      [Page 3]
+
+RFC 3916                   PWE3 Requirements              September 2004
+
+
+1.3.  PWE3 as a Path to Convergence
+
+   How do service providers realize the capital and operational benefits
+   of a new packet-based infrastructure, while leveraging the existing
+   equipment and also protecting the large revenue stream associated
+   with this equipment? How do they move from mature Frame Relay or ATM
+   networks, while still being able to provide these lucrative services?
+
+   One possibility is the emulation of circuits or services via PWs.
+   Circuit emulation over ATM and interworking of Frame Relay and ATM
+   have already been standardized.  Emulation allows existing services
+   to be carried across the new infrastructure, and thus enables the
+   interworking of disparate networks.
+
+   Implemented correctly, PWE3 can provide a means for supporting
+   today's services over a new network.
+
+1.4.  Suitable Applications for PWE3
+
+   What makes an application suitable (or not) for PWE3 emulation?  When
+   considering PWs as a means of providing an application, the following
+   questions must be considered:
+
+   -  Is the application sufficiently deployed to warrant emulation?
+   -  Is there interest on the part of service providers in providing an
+      emulation for the given application?
+   -  Is there interest on the part of equipment manufacturers in
+      providing products for the emulation of a given application?
+   -  Are the complexities and limitations of providing an emulation
+      worth the savings in capital and operational expenses?
+
+   If the answer to all four questions is "yes", then the application is
+   likely to be a good candidate for PWE3.  Otherwise, there may not be
+   sufficient overlap between the customers, service providers,
+   equipment manufacturers and technology to warrant providing such an
+   emulation.
+
+1.5.  Summary
+
+   To maximize the return on their assets and minimize their operational
+   costs, many service providers are looking to consolidate the delivery
+   of multiple service offerings and traffic types onto a single IP-
+   optimized network.
+
+   In order to create this next-generation converged network, standard
+   methods must be developed to emulate existing telecommunications
+
+
+
+
+
+Xiao, et al.                 Informational                      [Page 4]
+
+RFC 3916                   PWE3 Requirements              September 2004
+
+
+   formats such as Ethernet, Frame Relay, and ATM over IP-optimized core
+   networks.  This document describes requirements for accomplishing
+   this goal.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119.
+
+   Some terms used throughout this document are listed below.
+
+   Attachment Circuit (AC)
+                         The physical or virtual circuit attaching a CE
+                         to a PE.  An AC can be a Frame Relay DLCI, an
+                         ATM VPI/VCI, an Ethernet port, a VLAN, a HDLC
+                         link, a PPP connection on a physical interface,
+                         a PPP session from an L2TP tunnel, an MPLS LSP,
+                         etc.
+
+   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.
+
+   Packet Switched Network (PSN)
+                         Within the context of PWE3, this is a network
+                         using IP or MPLS as the mechanism for packet
+                         forwarding.
+
+   Provider Edge (PE)    A device that provides PWE3 to a CE.
+
+   Pseudo Wire (PW)      A mechanism that carries the essential elements
+                         of an emulated circuit from one PE to another
+                         PE over a PSN.
+
+   Pseudo Wire Emulation Edge to Edge (PWE3)
+                         A mechanism that emulates the essential
+                         attributes of a service (such as a T1 leased
+                         line or Frame Relay) over a PSN.
+
+   Pseudo Wire PDU       A Protocol Data Unit (PDU) sent on the PW that
+                         contains all of the data and control
+                         information necessary to emulate the desired
+                         service.
+
+   PSN Tunnel            A tunnel across a PSN inside which one or more
+                         PWs can be carried.
+
+
+
+Xiao, et al.                 Informational                      [Page 5]
+
+RFC 3916                   PWE3 Requirements              September 2004
+
+
+3.  Reference Model of PWE3
+
+   A pseudo-wire (PW) is a connection between two provider edge (PE)
+   devices which connects two attachment circuits (ACs).  An AC can be a
+   Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, a HDLC
+   link, a PPP connection on a physical interface, a PPP session from an
+   L2TP tunnel, an MPLS LSP, etc.
+
+                    |<------- Pseudo Wire ------>|
+                    |                            |
+                    |    |<-- PSN Tunnel -->|    |
+                    V    V                  V    V
+                    +----+                  +----+
+   +-----+          | PE1|==================| PE2|          +-----+
+   |     |----------|............PW1.............|----------|     |
+   | CE1 |          |    |                  |    |          | CE2 |
+   |     |----------|............PW2.............|----------|     |
+   +-----+  ^       |    |==================|    |          +-----+
+         ^  |       +----+                  +----+          ^
+         |  |   Provider Edge 1         Provider Edge 2     |
+         |  |                                               |
+         | Attachment Circuit                               |
+         |                                                  |
+         |<-------------- Emulated Service ---------------->|
+
+   Customer                                                 Customer
+    Edge 1                                                   Edge 2
+
+                     Figure 1: PWE3 Reference Model
+
+   During the setup of a PW, the two PEs will be configured or will
+   automatically exchange information about the service to be emulated
+   so that later they know how to process packets coming from the other
+   end.  After a PW is set up between two PEs, frames received by one PE
+   from an AC are encapsulated and sent over the PW to the remote PE,
+   where native frames are re-constructed and forwarded to the other CE.
+   For a detailed PWE3 architecture overview, readers should refer to
+   the PWE3 architecture document [PWE3_ARCH].
+
+   This document does not assume that a particular type of PWs (e.g.,
+   [L2TPv3] sessions or [MPLS] LSPs) or PSNs (e.g., IP or MPLS) is used.
+   Instead, it describes generic requirements that apply to all PWs and
+   PSNs, for all services including Ethernet, ATM, and Frame Relay, etc.
+
+
+
+
+
+
+
+
+Xiao, et al.                 Informational                      [Page 6]
+
+RFC 3916                   PWE3 Requirements              September 2004
+
+
+4.  Packet Processing
+
+   This section describes data plane requirements for PWE3.
+
+4.1.  Encapsulation
+
+   Every PE MUST provide an encapsulation mechanism for PDUs from an AC.
+   It should be noted that the PDUs to be encapsulated may or may not
+   contain L2 header information.  This is service specific.  Every PWE3
+   service MUST specify what the PDU is.
+
+   A PW header consists of all the header fields in a PW PDU that are
+   used by the PW egress to determine how to process the PDU.  The PSN
+   tunnel header is not considered as part of the PW header.
+
+   Specific requirements on PDU encapsulation are listed below.
+
+4.1.1.  Conveyance of Necessary L2 Header Information
+
+   The egress of a PW needs some information, e.g., which native service
+   the PW PDUs belong to, and possibly some L2 header information, in
+   order to know how to process the PDUs received.  A PWE3 encapsulation
+   approach MUST provide some mechanism for conveying such information
+   from the PW ingress to the egress.  It should be noted that not all
+   such information must be carried in the PW header of the PW PDUs.
+   Some information (e.g., service type of a PW) can be stored as state
+   information at the egress during PW setup.
+
+4.1.2.  Support of Variable Length PDUs
+
+   A PWE3 approach MUST accommodate variable length PDUs, if variable
+   length PDUs are allowed by the native service.  For example, a PWE3
+   approach for Frame Relay MUST accommodate variable length frames.
+
+4.1.3.  Support of Multiplexing and Demultiplexing
+
+   If a service in its native form is capable of grouping multiple
+   circuits into a "trunk", e.g., multiple ATM VCCs in a VPC or multiple
+   Ethernet 802.1Q interfaces in a port, some mechanism SHOULD be
+   provided so that a single PW can be used to connect two end-trunks.
+   From encapsulation perspective, sufficient information MUST be
+   carried so that the egress of the PW can demultiplex individual
+   circuits from the PW.
+
+
+
+
+
+
+
+
+Xiao, et al.                 Informational                      [Page 7]
+
+RFC 3916                   PWE3 Requirements              September 2004
+
+
+4.1.4.  Validation of PW-PDU
+
+   Most L2 frames have a checksum field to assure frame integrity.
+   Every PWE3 service MUST specify whether the frame's checksum should
+   be preserved across the PW, or should be removed at the ingress PE
+   and then be re-calculated and inserted at the egress PE.  For
+   protocols such as ATM and FR, the checksum covers link-local
+   information such as the circuit identifiers (e.g., FR DLCI or ATM
+   VPI/VCI).  Therefore, such checksum MUST be removed at the ingress PE
+   and recalculated at the egress PE.
+
+4.1.5.  Conveyance of Payload Type Information
+
+   Under some circumstances, it is desirable to be able to distinguish
+   PW traffic from other types of traffic such as IPv4 or IPv6 or OAM.
+   For example, if Equal Cost Multi-Path (ECMP) is employed in a PSN,
+   this additional distinguishability can be used to reduce the chance
+   that PW packets get misordered by the load balancing mechanism.  Some
+   mechanism SHOULD provide this distinguishability if needed.  Such
+   mechanism MAY be defined in the PWE3 WG or other WGs.
+
+4.2.  Frame Ordering
+
+   When packets carrying the PW PDUs traverse a PW, they may arrive at
+   the egress out of order.  For some services, the frames (either
+   control frames only or both control and data frames) must be
+   delivered in order.  For such services, some mechanism MUST be
+   provided for ensuring in-order delivery.  Providing a sequence number
+   in the PW header for each packet is one possible approach to detect
+   out-of-order frames.  Mechanisms for re-ordering frames may be
+   provided by Native Service Processing (NSP) [PWE3_ARCH] but are out
+   of scope of PWE3.
+
+4.3.  Frame Duplication
+
+   In rare cases, packets traversing a PW may be duplicated.  For some
+   services, frame duplication is not allowed.  For such services some
+   mechanism MUST be provided to ensure that duplicated frames will not
+   be delivered.  The mechanism may or may not be the same as the
+   mechanism used to ensure in-order frame delivery.
+
+4.4.  Fragmentation
+
+   If the combined size of the L2 payload and its associated PWE3 and
+   PSN headers exceeds the PSN path MTU, the L2 payload may need to be
+   fragmented (Alternatively the L2 frame may be dropped).  For certain
+   native service, fragmentation may also be needed to maintain a
+   control frame's relative position to the data frames (e.g., an ATM PM
+
+
+
+Xiao, et al.                 Informational                      [Page 8]
+
+RFC 3916                   PWE3 Requirements              September 2004
+
+
+   cell's relative position).  In general, fragmentation has a
+   performance impact.  It is therefore desirable to avoid fragmentation
+   if possible.  However, for different services, the need for
+   fragmentation can be different.  When there is potential need for
+   fragmentation, each service-specific PWE3 document MUST specify
+   whether to fragment the frame in question or to drop it.  If an
+   emulated service chooses to drop the frame, the consequence MUST be
+   specified in its applicability statement.
+
+4.5.  Consideration of Per-PSN Packet Overhead
+
+   When the L2 PDU size is small, in order to reduce PSN tunnel header
+   overhead, multiple PDUs MAY be concatenated before a PSN tunnel
+   header is added.  Each encapsulated PDU still carries its own PW
+   header so that the egress PE knows how to process it.  However, the
+   benefit of concatenating multiple PDUs for header efficiency should
+   be weighed against the resulting increase in delay, jitter and the
+   larger penalty incurred by packet loss.
+
+5.  Maintenance of Emulated Services
+
+   This section describes maintenance requirements for PWE3.
+
+5.1.  Setup and Teardown of Pseudo-Wires
+
+   A PW must be set up before an emulated circuit can be established,
+   and must be torn down when an emulated circuit is no longer needed.
+   Setup and teardown of a PW can be triggered by a command from the
+   management plane of a PE, or by Setup/Teardown of an AC (e.g., an ATM
+   SVC), or by an auto-discovery mechanism.
+
+   Every PWE3 approach MUST define some setup mechanism for establishing
+   the PWs.  During the setup process, the PEs need to exchange some
+   information (e.g., to learn each other's capability).  The setup
+   mechanism MUST enable the PEs to exchange all necessary information.
+   For example, both endpoints must agree on methods for encapsulating
+   PDUs and handling frame ordering.  Which signaling protocol to use
+   and what information to exchange are service specific.  Every PWE3
+   approach MUST specify them.  Manual configuration of PWs can be
+   considered as a special kind of signaling and is allowed.
+
+   If a native circuit is bi-directional, the corresponding emulated
+   circuit can be signaled "Up" only when the associated PW and PSN
+   tunnels in both directions are functional.
+
+
+
+
+
+
+
+Xiao, et al.                 Informational                      [Page 9]
+
+RFC 3916                   PWE3 Requirements              September 2004
+
+
+5.2.  Handling Maintenance Message of the Native Services
+
+   Some native services have mechanisms for maintenance purpose, e.g.,
+   ATM OAM and FR LMI.  Such maintenance messages can be in-band (i.e.,
+   mixed with data messages in the same AC) or out-of-band (i.e., sent
+   in a dedicated control circuit).  For such services, all in-band
+   maintenance messages related to a circuit SHOULD be transported in-
+   band just like data messages through the corresponding PW to the
+   remote CE.  In other words, no translation is needed at the PEs for
+   in-band maintenance messages.  In addition, it MAY be desirable to
+   provide higher reliability for maintenance messages.  The mechanisms
+   for providing high reliability do not have to be defined in the PWE3
+   WG.
+
+   Out-of-band maintenance messages between a CE and a PE may relate to
+   multiple ACs between the CE and the PE.  They need to be processed at
+   the local PE and possibly at the remote PE as well.  If a native
+   service has some out-of-band maintenance messages, the corresponding
+   emulated service MUST specify how to process such messages at the
+   PEs.  In general, an out-of-band maintenance message is either
+   translated into an in-band maintenance message of the native service
+   or a PWE-specific maintenance message for every AC related to that
+   out-of-band message.  As an example, assume the ACs between a CE and
+   a PE are some ATM VCCs inside a VPC.  When a F4 AIS [UNI3.0] from the
+   CE is received by the PE, the PE should translate that F4 AIS into a
+   F5 AIS and send it to the remote CE for every VCC.  Alternatively,
+   the PE should generate a PWE-specific maintenance message (e.g.,
+   label withdrawal) to the remote PE for every VCC.  When the remote PE
+   receives such a PWE-specific maintenance message, it may need to
+   generate a maintenance message of the native service and send it to
+   the attached CE.
+
+5.3.  PE-initiated Maintenance Messages
+
+   A PE needs to initiate some maintenance messages under some
+   circumstances without being triggered by any native maintenance
+   messages from the CE.  These circumstances are usually caused by
+   fault, e.g., a PW failure in the PSN or a link failure between the CE
+   and the PE.
+
+   The reason the PEs need to initiate some maintenance messages under a
+   fault condition is because the existence of a PW between two CEs
+   would otherwise reduce the CEs' maintenance capability.  This is
+   illustrated in the following example.  If two CEs are directly
+   connected by a physical wire, a native service (e.g., ATM) can use
+   notifications from the lower layer (e.g., the physical link layer) to
+
+
+
+
+
+Xiao, et al.                 Informational                     [Page 10]
+
+RFC 3916                   PWE3 Requirements              September 2004
+
+
+   assist its maintenance.  For example, an ATM PVC can be signaled
+   "Down" if the physical wire fails.  However, consider the following
+   scenario.
+
+   +-----+ Phy-link +----+              +----+ Phy-link +-----+
+   | CE1 |----------| PE1|......PW......|PE2 |----------| CE2 |
+   +-----+          +----+              +----+          +-----+
+
+   If the PW between PE1 and PE2 fails, CE1 and CE2 will not receive
+   physical link failure notification.  As a result, they cannot declare
+   failure of the emulated circuit in a timely fashion, which will in
+   turn affect higher layer applications.  Therefore, when the PW fails,
+   PE1 and PE2 need to initiate some maintenance messages to notify the
+   client layer on CE1 and CE2 that use the PW as a server layer.  (In
+   this case, the client layer is the emulated service).  Similarly, if
+   the physical link between PE1-CE1 fails, PE1 needs to initiate some
+   maintenance message(s) so that the client layer at CE2 will be
+   notified.  PE2 may need to be involved in this process.
+
+   In the rare case when a physical wire between two CEs incurs many bit
+   errors, the physical link can be declared "Down" and the client layer
+   at the CEs be notified.  Similarly, a PW can incur packet loss,
+   corruption, and out-of-order delivery.  These can be considered as
+   "generalized bit error".  Upon detection of excessive "generalized
+   bit error", a PW can be declared "Down" and the detecting PE needs to
+   initiate a maintenance message so that the client layer at the CE is
+   notified.
+
+   In general, every emulated service MUST specify:
+     * Under what circumstances PE-initiated maintenance messages are
+       needed,
+     * Format of the maintenance messages, and
+     * How to process the maintenance messages at the remote PE.
+
+   Some monitoring mechanisms are needed for detecting such
+   circumstances, e.g., a PW failure.  Such mechanisms can be defined in
+   the PWE3 WG or elsewhere.
+
+   Status of a group of emulated circuits may be affected identically by
+   a single network incidence.  For example, when the physical link
+   between a CE and a PE fails, all the emulated circuits that go
+   through that link will fail.  It is desirable that a single
+   maintenance message be used to notify failure of the whole group of
+   emulated circuits connected to the same remote PE.  A PWE3 approach
+   MAY provide some mechanism for notifying status changes of a group of
+   emulated circuits.  One possible approach is to associate each
+
+
+
+
+
+Xiao, et al.                 Informational                     [Page 11]
+
+RFC 3916                   PWE3 Requirements              September 2004
+
+
+   emulated circuit with a group ID while setting up the PW for that
+   emulated circuit.  In a maintenance message, that group ID can be
+   used to refer to all the emulated circuits in that group.
+
+   If a PE needs to generate and send a maintenance message to a CE, the
+   PE MUST use a maintenance message of the native service.  This is
+   essential in keeping the emulated service transparent to the CEs.
+
+   The requirements stated in this section are aligned with the ITU-T
+   maintenance philosophy for telecommunications networks [G805] (i.e.,
+   client layer/server layer concept).
+
+6.  Management of Emulated Services
+
+   Each PWE3 approach SHOULD provide some mechanisms for network
+   operators to manage the emulated service.  These mechanisms can be in
+   the forms described below.
+
+6.1.  MIBs
+
+   SNMP MIBs [SMIV2] MUST be provided for managing each emulated circuit
+   as well as pseudo-wire in general.  These MIBs SHOULD be created with
+   the following requirements.
+
+6.2.  General MIB Requirements
+
+   New MIBs MUST augment or extend where appropriate, existing tables as
+   defined in other existing service-specific MIBs for existing services
+   such as MPLS or L2TP.  For example, the ifTable as defined in the
+   Interface MIB [IFMIB] MUST be augmented to provide counts of out-of-
+   order packets.  A second example is the extension of the MPLS-TE-MIB
+   [TEMIB] when emulating circuit services over MPLS.  Rather than
+   redefining the tunnelTable so that PWE can utilize MPLS tunnels, for
+   example, entries in this table MUST instead be extended to add
+   additional PWE-specific objects.  A final example might be to extend
+   the IP Tunnel MIB [IPTUNMIB] in such a way as to provide PWE3-
+   specific semantics when tunnels other than MPLS are used as PSN
+   transport.  Doing so facilitates a natural extension of those objects
+   defined in the existing MIBs in terms of management, as well as
+   leveraging existing agent implementations.
+
+   An AC MUST appear as an interface in the ifTable.
+
+
+
+
+
+
+
+
+
+Xiao, et al.                 Informational                     [Page 12]
+
+RFC 3916                   PWE3 Requirements              September 2004
+
+
+6.3.  Configuration and Provisioning
+
+   MIB Tables MUST be designed to facilitate configuration and
+   provisioning of the AC.
+
+   The MIB(s) MUST facilitate intra-PSN configuration and monitoring of
+   ACs.
+
+6.4.  Performance Monitoring
+
+   MIBs MUST collect statistics for performance and fault management.
+
+   MIBs MUST provide a description of how existing counters are used for
+   PW emulation and SHOULD not replicate existing MIB counters.
+
+6.5.  Fault Management and Notifications
+
+   Notifications SHOULD be defined where appropriate to notify the
+   network operators of any interesting situations, including faults
+   detected in the AC.
+
+   Objects defined to augment existing protocol-specific notifications
+   in order to add PWE functionality MUST explain how these
+   notifications are to be emitted.
+
+6.6.   Pseudo-Wire Connection Verification and Traceroute
+
+   For network management purpose, a connection verification mechanism
+   SHOULD be supported by PWs.  Connection verification as well as other
+   alarming mechanisms can alert network operators that a PW has lost
+   its remote connection.  It is sometimes desirable to know the exact
+   functional path of a PW for troubleshooting purpose, thus a
+   traceroute function capable of reporting the path taken by data
+   packets over the PW SHOULD be provided.
+
+7.  Faithfulness of Emulated Services
+
+   An emulated service SHOULD be as similar to the native service as
+   possible, but NOT REQUIRED to be identical.  The applicability
+   statement of a PWE3 service MUST report limitations of the emulated
+   service.
+
+   Some basic requirements on faithfulness of an emulated service are
+   described below.
+
+
+
+
+
+
+
+Xiao, et al.                 Informational                     [Page 13]
+
+RFC 3916                   PWE3 Requirements              September 2004
+
+
+7.1.  Characteristics of an Emulated Service
+
+   From the perspective of a CE, an emulated circuit is characterized as
+   an unshared link or circuit of the chosen service, although service
+   quality of the emulated service may be different from that of a
+   native one.  Specifically, the following requirements MUST be met:
+
+   1) It MUST be possible to define type (e.g., Ethernet, which is
+      inherited from the native service), speed (e.g., 100Mbps), and MTU
+      size for an emulated circuit, if it is possible to do so for a
+      native circuit.
+
+   2) If the two endpoints CE1 and CE2 of emulated circuit #1 are
+      connected to PE1 and PE2, respectively, and CE3 and CE4 of
+      emulated circuit #2 are also connected to PE1 and PE2, then the
+      PWs of these two emulated circuits may share the same physical
+      paths between PE1 and PE2.  But from each CE's perspective, its
+      emulated circuit MUST appear as unshared.  For example, CE1/CE2
+      MUST NOT be aware of existence of emulated circuit #2 or CE3/CE4.
+
+   3) If an emulated circuit fails (either at one of the ACs or in the
+      middle of the PW), both CEs MUST be notified in a timely manner,
+      if they will be notified in the native service (see Section 5.3
+      for more information).  The definition of "timeliness" is
+      service-dependent.
+
+   4) If a routing protocol (e.g., IGP) adjacency can be established
+      over a native circuit, it MUST be possible to be established over
+      an emulated circuit as well.
+
+7.2.  Service Quality of Emulated Services
+
+   It is NOT REQUIRED that an emulated service provide the same service
+   quality as the native service.  The PWE3 WG only defines mechanisms
+   for providing PW emulation, not the services themselves.  What
+   quality to provide for a specific emulated service is a matter
+   between a service provider (SP) and its customers, and is outside
+   scope of the PWE3 WG.
+
+8.  Non-Requirements
+
+   Some non-requirements are mentioned in various sections of this
+   document.  Those work items are outside scope of the PWE3 WG.  They
+   are summarized below:
+
+
+
+
+
+
+
+Xiao, et al.                 Informational                     [Page 14]
+
+RFC 3916                   PWE3 Requirements              September 2004
+
+
+   -  Service interworking;
+
+      In Service Interworking, the IWF (Interworking Function) between
+      two dissimilar protocols (e.g., ATM & MPLS, Frame Relay & ATM, ATM
+      & IP, ATM & L2TP, etc.) terminates the protocol used in one
+      network and translates (i.e., maps) its Protocol Control
+      Information (PCI) to the PCI of the protocol used in other network
+      for User, Control and Management Plane functions to the extent
+      possible.
+
+   -  Selection of a particular type of PWs;
+
+   -  To make the emulated services perfectly match their native
+      services;
+
+   -  Defining mechanisms for signaling the PSN tunnels;
+
+   -  Defining how to perform traffic management on packets that carry
+      PW PDUs;
+
+   -  Providing any multicast service that is not native to the emulated
+      medium.
+
+      To illustrate this point, Ethernet transmission to a multicast
+      IEEE-48 address is considered in scope, while multicast services
+      like [MARS] that are implemented on top of the medium are out of
+      scope;
+
+9.  Quality of Service (QoS) Considerations
+
+   Some native services such as ATM can offer higher service quality
+   than best effort Internet service.  QoS is therefore essential for
+   ensuring that emulated services are compatible (but not necessarily
+   identical) to their native forms.  It is up to network operators to
+   decide how to provide QoS - They can choose to rely on over-
+   provisioning and/or deploy some QoS mechanisms.
+
+   In order to take advantage of QoS mechanisms defined in other working
+   groups, e.g., the traffic management schemes defined in DiffServ WG,
+   it is desirable that some mechanisms exists for differentiating the
+   packets resulted from PDU encapsulation.  These mechanisms do not
+   have to be defined in the PWE3 approaches themselves.  For example,
+   if the resulted packets are MPLS or IP packets, their EXP or DSCP
+   field can be used for marking and differentiating.  A PWE3 approach
+   MAY provide guidelines for marking and differentiating.
+
+
+
+
+
+
+Xiao, et al.                 Informational                     [Page 15]
+
+RFC 3916                   PWE3 Requirements              September 2004
+
+
+   The applicability of PWE3 to a particular service depends on the
+   sensitivity of that service (or the CE implementation) to
+   delay/jitter etc and the ability of the application layer to mask
+   them.  PWE3 may not be applicable to services that have severe
+   constraints in this respect.
+
+10.  Inter-domain Issues
+
+   PWE is a matter between the PW end-points and is transparent to the
+   network devices between the PW end-points.  Therefore, inter-domain
+   PWE is fundamentally similar to intra-domain PWE.  As long as PW
+   end-points use the same PWE approach, they can communicate
+   effectively, regardless of whether they are in the same domain.
+   Security may become more important in the inter-domain case and some
+   security measure such as end-point authentication MAY be applied.
+   QoS may become more difficult to deliver too, as one service provider
+   has no control over another service provider's provisioning and
+   traffic management policy.  To solve the inter-domain QoS problem,
+   service providers have to cooperate.  Once they agree at a
+   contractual level to provider high quality of service to certain
+   traffic (e.g., PWE traffic), the mechanisms defined in other working
+   groups, e.g., Diffserv WG, can be used.
+
+   Inter-domain PSN tunnels are generally more difficult to set up, tear
+   down and maintain than intra-domain ones.  But that is an issue for
+   PSN tunneling protocols such as MPLS and L2TPv3 and is outside the
+   scope of PWE3.
+
+11.  Security Considerations
+
+   The PW end-point, PW demultiplexing mechanism, and the payloads of
+   the native service can all be vulnerable to attack.  PWE3 should
+   leverage security mechanisms provided by the PW Demultiplexer or PSN
+   Layers.  Such mechanisms SHOULD protect PW end-point and PW
+   Demultiplexer mechanism from denial-of-service (DoS) attacks and
+   spoofing of the native data units.  Preventing unauthorized access to
+   PW end-points and other network devices is generally effective
+   against DoS attacks and spoofing, and can be part of protection
+   mechanism.  Protection mechanisms SHOULD 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] can be
+   used.
+
+
+
+
+
+
+
+
+Xiao, et al.                 Informational                     [Page 16]
+
+RFC 3916                   PWE3 Requirements              September 2004
+
+
+12.  Acknowledgments
+
+   The authors would like to acknowledge input from M. Aissaoui, M.
+   Bocci, S. Bryant, R. Cohen, N. Harrison, G. Heron, T. Johnson, A.
+   Malis, L. Martini, E. Rosen, J. Rutemiller, T. So, Y. Stein, and S.
+   Vainshtein.
+
+13.  References
+
+13.1.  Normative References
+
+   [IFMIB]     McCloghrie, K. and F. Kastenholz, "The Interfaces Group
+               MIB", RFC 2863, June 2000.
+
+   [SMIV2]     McCloghrie, K., Perkins, D., and J. Schoenwaelder,
+               "Structure of Management Information Version 2 (SMIv2)",
+               STD 58, RFC 2578, April 1999.
+
+13.2.  Informative References
+
+   [G805]      "Generic Functional Architecture of Transport Networks",
+               ITU-T Recommendation G.805, 2000.
+
+   [IPTUNMIB]  Thaler, D., "IP Tunnel MIB", RFC 2667, August 1999.
+
+   [L2TPv3]    Lau, J., Townsley, M., and I. Goyret, et al., "Layer Two
+               Tunneling Protocol (Version 3)", Work in Progress, June
+               2004.
+
+   [MARS]      Armitage, G., "Support for Multicast over UNI 3.0/3.1
+               based ATM Networks", RFC 2022, November 1996.
+
+   [MPLS]      Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
+               Label Switching Architecture", RFC 3031, January 2001.
+
+   [PWE3_ARCH] S. Bryant and P. Pate, et. al., "PWE3 Architecture", Work
+               in Progress, March 2004.
+
+   [RFC2401]   Kent, S. and R. Atkinson, "Security Architecture for the
+               Internet Protocol", RFC 2401, November 1998.
+
+   [TEMIB]     Srinivasan, C., Viswanathan, A., and T. Nadeau,
+               "Multiprotocol Label Switching (MPLS) Traffic Engineering
+               (TE) Management Information Base (MIB)", RFC 3812, June
+               2004.
+
+   [UNI3.0]    ATM Forum, "ATM User-Network Interface Specification
+               Version 3.0", Sept. 1993.
+
+
+
+Xiao, et al.                 Informational                     [Page 17]
+
+RFC 3916                   PWE3 Requirements              September 2004
+
+
+14.  Authors' Addresses
+
+   XiPeng Xiao  (Editor)
+   Riverstone Networks
+   5200 Great America Parkway
+   Santa Clara, CA 95054
+
+   EMail: xxiao@riverstonenet.com
+
+   Danny McPherson (Editor)
+   Arbor Networks
+
+   EMail: danny@arbor.net
+
+   Prayson Pate (Editor)
+   Overture Networks
+   507 Airport Boulevard, Suite 111
+   Morrisville, NC, USA 27560
+
+   EMail: prayson.pate@overturenetworks.com
+
+   Vijay Gill
+   AOL Time Warner
+
+   EMail: vijaygill9@aol.com
+
+   Kireeti Kompella
+   Juniper Networks, Inc.
+   1194 N. Mathilda Ave.
+   Sunnyvale, CA 94089
+
+   EMail: kireeti@juniper.net
+
+   Thomas D. Nadeau
+   Cisco Systems, Inc.
+   300 Beaver Brook Drive
+   Boxborough, MA 01719
+   EMail: tnadeau@cisco.com
+
+   Craig White
+   Level 3 Communications, LLC.
+   1025 Eldorado Blvd.
+   Broomfield, CO, 80021
+
+   EMail: Craig.White@Level3.com
+
+
+
+
+
+
+Xiao, et al.                 Informational                     [Page 18]
+
+RFC 3916                   PWE3 Requirements              September 2004
+
+
+15.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).
+
+   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/S HE
+   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 IETF's procedures with respect to rights in IETF 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.
+
+
+
+
+
+
+
+Xiao, et al.                 Informational                     [Page 19]
+