doc: Add RFC documents

1 files changed, 1739 insertions, 0 deletions

diff --git a/doc/rfc/rfc5654.txt b/doc/rfc/rfc5654.txt
new file mode 100644
index 0000000..e98869b
--- /dev/null
+++ b/doc/rfc/rfc5654.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group                              B. Niven-Jenkins, Ed.
+Request for Comments: 5654                                            BT
+Category: Standards Track                               D. Brungard, Ed.
+                                                                    AT&T
+                                                           M. Betts, Ed.
+                                                     Huawei Technologies
+                                                             N. Sprecher
+                                                  Nokia Siemens Networks
+                                                                 S. Ueno
+                                                      NTT Communications
+                                                          September 2009
+
+
+               Requirements of an MPLS Transport Profile
+
+Abstract
+
+   This document specifies the requirements of an MPLS Transport Profile
+   (MPLS-TP).  This document is a product of a joint effort of the
+   International Telecommunications Union (ITU) and IETF to include an
+   MPLS Transport Profile within the IETF MPLS and PWE3 architectures to
+   support the capabilities and functionalities of a packet transport
+   network as defined by International Telecommunications Union -
+   Telecommunications Standardization Sector (ITU-T).
+
+   This work is based on two sources of requirements: MPLS and PWE3
+   architectures as defined by IETF, and packet transport networks as
+   defined by ITU-T.
+
+   The requirements expressed in this document are for the behavior of
+   the protocol mechanisms and procedures that constitute building
+   blocks out of which the MPLS Transport Profile is constructed.  The
+   requirements are not implementation requirements.
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright and License Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                     [Page 1]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  5
+     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
+       1.2.1.  Abbreviations  . . . . . . . . . . . . . . . . . . . .  6
+       1.2.2.  Definitions  . . . . . . . . . . . . . . . . . . . . .  7
+     1.3.  Transport Network Overview . . . . . . . . . . . . . . . . 10
+     1.4.  Layer Network Overview . . . . . . . . . . . . . . . . . . 11
+   2.  MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 12
+     2.1.  General Requirements . . . . . . . . . . . . . . . . . . . 13
+     2.2.  Layering Requirements  . . . . . . . . . . . . . . . . . . 16
+     2.3.  Data Plane Requirements  . . . . . . . . . . . . . . . . . 17
+     2.4.  Control Plane Requirements . . . . . . . . . . . . . . . . 18
+     2.5.  Recovery Requirements  . . . . . . . . . . . . . . . . . . 19
+       2.5.1.  Data-Plane Behavior Requirements . . . . . . . . . . . 20
+         2.5.1.1.  Protection . . . . . . . . . . . . . . . . . . . . 20
+         2.5.1.2.  Sharing of Protection Resources  . . . . . . . . . 21
+       2.5.2.  Restoration  . . . . . . . . . . . . . . . . . . . . . 21
+       2.5.3.  Triggers for Protection, Restoration, and Reversion  . 22
+       2.5.4.  Management-Plane Operation of Protection and
+               Restoration  . . . . . . . . . . . . . . . . . . . . . 22
+       2.5.5.  Control Plane and In-Band OAM Operation of Recovery  . 23
+       2.5.6.  Topology-Specific Recovery Mechanisms  . . . . . . . . 24
+         2.5.6.1.  Ring Protection  . . . . . . . . . . . . . . . . . 24
+     2.6.  QoS Requirements . . . . . . . . . . . . . . . . . . . . . 27
+   3.  Requirements Discussed in Other Documents  . . . . . . . . . . 27
+     3.1.  Network Management Requirements  . . . . . . . . . . . . . 27
+     3.2.  Operation, Administration, and Maintenance (OAM)
+           Requirements . . . . . . . . . . . . . . . . . . . . . . . 27
+     3.3.  Network Performance-Monitoring Requirements  . . . . . . . 28
+     3.4.  Security Requirements  . . . . . . . . . . . . . . . . . . 28
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
+   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
+   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
+     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 29
+     6.2.  Informative References . . . . . . . . . . . . . . . . . . 29
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                     [Page 2]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+1.  Introduction
+
+   Bandwidth demand continues to grow worldwide, stimulated by the
+   accelerating growth and penetration of new packet-based services and
+   multimedia applications:
+
+   o  Packet-based services such as Ethernet, Voice over IP (VoIP),
+      Layer 2 (L2) / Layer 3 (L3) Virtual Private Networks (VPNs), IP
+      television (IPTV), Radio Access Network (RAN) backhauling, etc.
+
+   o  Applications with various bandwidth and Quality of Service (QoS)
+      requirements.
+
+   This growth in demand has resulted in dramatic increases in access
+   rates that are, in turn, driving dramatic increases in metro and core
+   network bandwidth requirements.
+
+   Over the past two decades, the evolving optical transport
+   infrastructure (Synchronous Optical Networking (SONET) / Synchronous
+   Digital Hierarchy (SDH), Optical Transport Network (OTN)) has
+   provided carriers with a high benchmark for reliability and
+   operational simplicity.
+
+   With the movement towards packet-based services, the transport
+   network has to evolve to encompass the provision of packet-aware
+   capabilities while enabling carriers to leverage their installed, as
+   well as planned, transport infrastructure investments.
+
+   Carriers are in need of technologies capable of efficiently
+   supporting packet-based services and applications on their transport
+   networks with guaranteed Service Level Agreements (SLAs).  The need
+   to increase their revenue while remaining competitive forces
+   operators to look for the lowest network Total Cost of Ownership
+   (TCO).  Investment in equipment and facilities (Capital Expenditure
+   (CAPEX)) and Operational Expenditure (OPEX) should be minimized.
+
+   There are a number of technology options for carriers to meet the
+   challenge of increased service sophistication and transport
+   efficiency, with increasing usage of hybrid packet-transport and
+   circuit-transport technology solutions.  To realize these goals, it
+   is essential that packet-transport technology be available that can
+   support the same high benchmarks for reliability and operational
+   simplicity set by SDH/SONET and OTN technologies.
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                     [Page 3]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   Furthermore, for carriers it is important that operation of such
+   packet transport networks should preserve the look-and-feel to which
+   carriers have become accustomed in deploying their optical transport
+   networks, while providing common, multi-layer operations, resiliency,
+   control, and multi-technology management.
+
+   Transport carriers require control and deterministic usage of network
+   resources.  They need end-to-end control to engineer network paths
+   and to efficiently utilize network resources.  They require
+   capabilities to support static (management-plane-based) or dynamic
+   (control-plane-based) provisioning of deterministic, protected, and
+   secured services and their associated resources.
+
+   It is also important to ensure smooth interworking of the packet
+   transport network with other existing/legacy packet networks, and
+   provide mappings to enable packet transport carriage over a variety
+   of transport network infrastructures.  The latter has been termed
+   vertical interworking, and is also known as client/server or network
+   interworking.  The former has been termed horizontal interworking,
+   and is also known as peer-partition or service interworking.  For
+   more details on interworking and some of the issues that may arise
+   (especially with horizontal interworking), see G.805 [ITU.G805.2000]
+   and Y.1401 [ITU.Y1401.2008].
+
+   Multi-Protocol Label Switching (MPLS) is a maturing packet technology
+   and it is already playing an important role in transport networks and
+   services.  However, not all of MPLS's capabilities and mechanisms are
+   needed and/or consistent with transport network operations.  There
+   are also transport technology characteristics that are not currently
+   reflected in MPLS.  Therefore, there is the need to define an MPLS
+   Transport Profile (MPLS-TP) that supports the capabilities and
+   functionalities needed for packet-transport network services and
+   operations through combining the packet experience of MPLS with the
+   operational experience and practices of existing transport networks.
+
+   MPLS-TP will enable the deployment of packet-based transport networks
+   that will efficiently scale to support packet services in a simple
+   and cost-effective way.  MPLS-TP needs to combine the necessary
+   existing capabilities of MPLS with additional minimal mechanisms in
+   order that it can be used in a transport role.
+
+   This document specifies the requirements of an MPLS Transport Profile
+   (MPLS-TP).  The requirements are for the behavior of the protocol
+   mechanisms and procedures that constitute building blocks out of
+   which the MPLS Transport Profile is constructed.  That is, the
+   requirements indicate what features are to be available in the MPLS
+   toolkit for use by MPLS-TP.  The requirements in this document do not
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                     [Page 4]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   describe what functions an MPLS-TP implementation supports.  The
+   purpose of this document is to identify the toolkit and any new
+   protocol work that is required.
+
+   This document is a product of a joint ITU-T and IETF effort to
+   include an MPLS Transport Profile within the IETF MPLS and PWE3
+   architectures to support the capabilities and functionalities of a
+   packet transport network as defined by ITU-T.  The document is a
+   requirements specification, but is presented on the Standards Track
+   so that it can be more easily cited as a normative reference from
+   within the work of the ITU-T.
+
+   This work is based on two sources of requirements, MPLS and PWE3
+   architectures as defined by IETF and packet transport networks as
+   defined by ITU-T.  The requirements of MPLS-TP are provided below.
+   The relevant functions of MPLS and PWE3 are included in MPLS-TP,
+   except where explicitly excluded.  Any new functionality that is
+   defined to fulfill the requirements for MPLS-TP must be agreed within
+   the IETF through the IETF consensus process as per [RFC4929].
+
+   MPLS-TP transport paths may be established using static or dynamic
+   configuration.  It should be noted that the MPLS-TP network and its
+   transport paths can always be operated fully (including OAM and
+   protection capabilities) in the absence of any control plane.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+   Although this document is not a protocol specification, the use of
+   this language clarifies the instructions to protocol designers
+   producing solutions that satisfy the requirements set out in this
+   document.
+
+1.2.  Terminology
+
+   Note: Mapping between the terms in this section and ITU-T terminology
+   is described in [TP-TERMS].
+
+   The recovery requirements in this document use the recovery
+   terminology defined in RFC 4427 [RFC4427]; this is applied to both
+   control-plane- and management-plane-based operations of MPLS-TP
+   transport paths.
+
+
+
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                     [Page 5]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+1.2.1.  Abbreviations
+
+   ASON: Automatically Switched Optical Network
+
+   ATM: Asynchronous Transfer Mode
+
+   CAPEX: Capital Expenditure
+
+   CE: Customer Edge
+
+   FR: Frame Relay
+
+   GMPLS: Generalized Multi-Protocol Label Switching
+
+   IGP: Interior Gateway Protocol
+
+   IPTV: IP Television
+
+   L2: Layer 2
+
+   L3: Layer 3
+
+   LSP: Label Switched Path
+
+   LSR: Label Switching Router
+
+   MPLS: Multi-Protocol Label Switching
+
+   OAM: Operations, Administration, and Maintenance
+
+   OPEX: Operational Expenditure
+
+   OSI: Open Systems Interconnection
+
+   OTN: Optical Transport Network
+
+   P2MP: Point to Multipoint
+
+   P2P: Point to Point
+
+   PDU: Protocol Data Unit
+
+   PSC: Protection State Coordination
+
+   PW: Pseudowire
+
+   QoS: Quality of Service
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                     [Page 6]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   SDH: Synchronous Digital Hierarchy
+
+   SLA: Service Level Agreement
+
+   SLS: Service Level Specification
+
+   S-PE: Switching Provider Edge
+
+   SONET: Synchronous Optical Network
+
+   SRLG: Shared Risk Link Group
+
+   TCO: Total Cost of Ownership
+
+   T-PE: Terminating Provider Edge
+
+   VoIP: Voice over IP
+
+   VPN: Virtual Private Network
+
+   WDM: Wavelength Division Multiplexing
+
+1.2.2.  Definitions
+
+   Note: The definition of "segment" in a GMPLS/ASON context (i.e., as
+   defined in RFC4397 [RFC4397]) encompasses both "segment" and
+   "concatenated segment" as defined in this document.
+
+   Associated bidirectional path: A path that supports traffic flow in
+   both directions but that is constructed from a pair of unidirectional
+   paths (one for each direction) that are associated with one another
+   at the path's ingress/egress points.  The forward and backward
+   directions are setup, monitored, and protected independently.  As a
+   consequence, they may or may not follow the same route (links and
+   nodes) across the network.
+
+   Client layer network: In a client/server relationship (see G.805
+   [ITU.G805.2000]), the client layer network receives a (transport)
+   service from the lower server layer network (usually the layer
+   network under consideration).
+
+   Concatenated Segment: A serial-compound link connection as defined in
+   G.805 [ITU.G805.2000].  A concatenated segment is a contiguous part
+   of an LSP or multi-segment PW that comprises a set of segments and
+   their interconnecting nodes in sequence.  See also "Segment".
+
+
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                     [Page 7]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   Control Plane: Within the scope of this document, the control plane
+   performs transport path control functions.  Through signalling, the
+   control plane sets up, modifies and releases transport paths, and may
+   recover a transport path in case of a failure.  The control plane
+   also performs other functions in support of transport path control,
+   such as routing information dissemination.
+
+   Co-routed Bidirectional path: A path where the forward and backward
+   directions follow the same route (links and nodes) across the
+   network.  Both directions are setup, monitored and protected as a
+   single entity.  A transport network path is typically co-routed.
+
+   Domain: A domain represents a collection of entities (for example
+   network elements) that are grouped for a particular purpose, examples
+   of which are administrative and/or managerial responsibilities, trust
+   relationships, addressing schemes, infrastructure capabilities,
+   aggregation, survivability techniques, distributions of control
+   functionality, etc.  Examples of such domains include IGP areas and
+   Autonomous Systems.
+
+   Layer network: Layer network is defined in G.805 [ITU.G805.2000].  A
+   layer network provides for the transfer of client information and
+   independent operation of the client OAM.  A layer network may be
+   described in a service context as follows: one layer network may
+   provide a (transport) service to a higher client layer network and
+   may, in turn, be a client to a lower-layer network.  A layer network
+   is a logical construction somewhat independent of arrangement or
+   composition of physical network elements.  A particular physical
+   network element may topologically belong to more than one layer
+   network, depending on the actions it takes on the encapsulation
+   associated with the logical layers (e.g., the label stack), and thus
+   could be modeled as multiple logical elements.  A layer network may
+   consist of one or more sublayers.  Section 1.4 provides a more
+   detailed overview of what constitutes a layer network.  For
+   additional explanation of how layer networks relate to the OSI
+   concept of layering, see Appendix I of Y.2611 [ITU.Y2611.2006].
+
+   Link: A physical or logical connection between a pair of LSRs that
+   are adjacent at the (sub)layer network under consideration.  A link
+   may carry zero, one, or more LSPs or PWs.  A packet entering a link
+   will emerge with the same label-stack entry values.
+
+   MPLS-TP Logical Ring: An MPLS-TP logical ring is constructed from a
+   set of LSRs and logical data links (such as MPLS-TP LSP tunnels or
+   MPLS-TP pseudowires) and physical data links that form a ring
+   topology.
+
+   Path: See Transport Path.
+
+
+
+Niven-Jenkins, et al.       Standards Track                     [Page 8]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   MPLS-TP Physical Ring: An MPLS-TP physical ring is constructed from a
+   set of LSRs and physical data links that form a ring topology.
+
+   MPLS-TP Ring Topology: In an MPLS-TP ring topology, each LSR is
+   connected to exactly two other LSRs, each via a single point-to-point
+   bidirectional MPLS-TP capable link.  A ring may also be constructed
+   from only two LSRs where there are also exactly two links.  Rings may
+   be connected to other LSRs to form a larger network.  Traffic
+   originating or terminating outside the ring may be carried over the
+   ring.  Client network nodes (such as CEs) may be connected directly
+   to an LSR in the ring.
+
+   Section Layer Network: A section layer is a server layer (which may
+   be MPLS-TP or a different technology) that provides for the transfer
+   of the section-layer client information between adjacent nodes in the
+   transport-path layer or transport-service layer.  A section layer may
+   provide for aggregation of multiple MPLS-TP clients.  Note that G.805
+   [ITU.G805.2000] defines the section layer as one of the two layer
+   networks in a transmission-media layer network.  The other layer
+   network is the physical-media layer network.
+
+   Segment: A link connection as defined in G.805 [ITU.G805.2000].  A
+   segment is the part of an LSP that traverses a single link or the
+   part of a PW that traverses a single link (i.e., that connects a pair
+   of adjacent {Switching|Terminating} Provider Edges).  See also
+   "Concatenated Segment".
+
+   Server Layer Network: In a client/server relationship (see G.805
+   [ITU.G805.2000]), the server layer network provides a (transport)
+   service to the higher client layer network (usually the layer network
+   under consideration).
+
+   Sublayer: Sublayer is defined in G.805 [ITU.G805.2000].  The
+   distinction between a layer network and a sublayer is that a sublayer
+   is not directly accessible to clients outside of its encapsulating
+   layer network and offers no direct transport service for a higher
+   layer (client) network.
+
+   Switching Provider Edge (S-PE): See [MS-PW-ARCH].
+
+   Terminating Provider Edge (T-PE): See [MS-PW-ARCH].
+
+   Transport Path: A network connection as defined in G.805
+   [ITU.G805.2000].  In an MPLS-TP environment, a transport path
+   corresponds to an LSP or a PW.
+
+
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                     [Page 9]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   Transport Path Layer: A (sub)layer network that provides point-to-
+   point or point-to-multipoint transport paths.  It provides OAM that
+   is independent of the clients that it is transporting.
+
+   Transport Service Layer: A layer network in which transport paths are
+   used to carry a customer's (individual or bundled) service (may be
+   point-to-point, point-to-multipoint, or multipoint-to-multipoint
+   services).
+
+   Transmission Media Layer: A layer network, consisting of a section
+   layer network and a physical layer network as defined in G.805
+   [ITU.G805.2000], that provides sections (two-port point-to-point
+   connections) to carry the aggregate of network-transport path or
+   network-service layers on various physical media.
+
+   Unidirectional Path: A path that supports traffic flow in only one
+   direction.
+
+1.3.  Transport Network Overview
+
+   The connectivity service is the basic service provided by a transport
+   network.  The purpose of a transport network is to carry its customer
+   traffic (i.e., the stream of customer PDUs or customer bits,
+   including overhead) between end points in the transport network
+   (typically over several intermediate nodes).  The connectivity
+   services offered to customers are typically aggregated into large
+   transport paths with long holding times and OAM that is independent
+   (of the client OAM), which contribute to enabling the efficient and
+   reliable operation of the transport network.  These transport paths
+   are modified infrequently.
+
+   Quality-of-service mechanisms are required in the packet transport
+   network to ensure the prioritization of critical services, to
+   guarantee bandwidth, and to control jitter and delay.  A transport
+   network must provide the means to meet the quality-of-service
+   objectives of its clients.  This is achieved by providing a mechanism
+   for client network service demarcation for the network path together
+   with an associated network resiliency mechanism.
+
+   Aggregation is beneficial for achieving scalability and security
+   since:
+
+   1.  It reduces the number of provisioning and forwarding states in
+       the network core.
+
+   2.  It reduces load and the cost of implementing service assurance
+       and fault management.
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 10]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   3.  Customer traffic is encapsulated and layer-associated OAM
+       overhead is added.  This allows complete isolation of customer
+       traffic and its management from carrier operations.
+
+   An important attribute of a transport network is that it is able to
+   function regardless of which clients are using its connection service
+   or over which transmission media it is running.  From a functional
+   and operational point of view, the client, transport network, and
+   server layers are independent layer networks.  Another key
+   characteristic of transport networks is the capability to maintain
+   the integrity of the client across the transport network.  A
+   transport network must also provide a method of service monitoring in
+   order to verify the delivery of an agreed quality of service.  This
+   is enabled by means of carrier-grade OAM tools.
+
+   Customer traffic is first encapsulated within the transport-service
+   layer network.  The transport service layer network signals may then
+   be aggregated into a transport-path layer network for transport
+   through the network in order to optimize network management.
+   Transport-service layer network OAM is used to monitor the transport
+   integrity of the customer traffic, and transport-path layer network
+   OAM is used to monitor the transport integrity of the aggregates.  At
+   any hop, the aggregated signals may be further aggregated in lower-
+   layer transport network paths for transport across intermediate
+   shared links.  The transport service layer network signals are
+   extracted at the edges of aggregation domains, and are either
+   delivered to the customer or forwarded to another domain.  In the
+   core of the network, only the transport path layer network signals
+   are monitored at intermediate points; individual transport service
+   layer network signals are monitored at the network boundary.
+   Although the connectivity of the transport-service layer network may
+   be point-to-point, point-to-multipoint, or multipoint-to-multipoint,
+   the transport-path layer network only provides point-to-point or
+   point-to-multipoint transport paths, which are used to carry
+   aggregates of transport service layer network traffic.
+
+1.4.  Layer Network Overview
+
+   A layer network provides its clients with a transport service and the
+   operation of the layer network is independent of whatever client
+   happens to use the layer network.  Information that passes between
+   any client to the layer network is common to all clients and is the
+   minimum needed to be consistent with the definition of the transport
+   service offered.  The client layer network can be connectionless,
+   connection-oriented packet switched, or circuit switched.  The
+   transport service transfers a payload such that the client can
+   populate the payload without affecting any operation within the
+   serving layer network.  Here, payload means:
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 11]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   o  an individual packet payload (for connectionless networks),
+
+   o  a sequence of packet payloads (for connection-oriented packet-
+      switched networks), or
+
+   o  a deterministic schedule of payloads (for circuit-switched
+      networks).
+
+   The operations within a layer network that are independent of its
+   clients include the control of forwarding, the control of resource
+   reservation, the control of traffic de-merging, and the OAM and
+   recovery of the transport service.  All of these operations are
+   internal to a layer network.  By definition, a layer network does not
+   rely on any client information to perform these operations, and
+   therefore all information required to perform these operations is
+   independent of whatever client is using the layer network.
+
+   A layer network will have consistent features in order to support the
+   control of forwarding, resource reservation, OAM, and recovery.  For
+   example, a layer network will have a common addressing scheme for the
+   end points of the transport service and a common set of transport
+   descriptors for the transport service.  However, a client may use a
+   different addressing scheme or different traffic descriptors
+   (consistent with performance inheritance).
+
+   It is sometimes useful to independently monitor a smaller domain
+   within a layer network (or the transport services that traverse this
+   smaller domain), but the control of forwarding or the control of
+   resource reservation involved retain their common elements.  These
+   smaller monitored domains are sublayers.
+
+   It is sometimes useful to independently control forwarding in a
+   smaller domain within a layer network, but the control of resource
+   reservation and OAM retain their common elements.  These smaller
+   domains are partitions of the layer network.
+
+2.  MPLS-TP Requirements
+
+   The MPLS-TP requirements set out in this section are for the behavior
+   of the protocol mechanisms and procedures that constitute building
+   blocks out of which the MPLS Transport Profile is constructed.  That
+   is, the requirements indicate what features are to be available in
+   the MPLS toolkit for use by MPLS-TP.
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 12]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+2.1.  General Requirements
+
+   1   The MPLS-TP data plane MUST be a subset of the MPLS data plane as
+       defined by the IETF.  When MPLS offers multiple options in this
+       respect, MPLS-TP SHOULD select the minimum subset (necessary and
+       sufficient subset) applicable to a transport network application.
+
+   2   The MPLS-TP design SHOULD as far as reasonably possible reuse
+       existing MPLS standards.
+
+   3   Mechanisms and capabilities MUST be able to interoperate with
+       existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and
+       data planes where appropriate.
+
+       A.  Data-plane interoperability MUST NOT require a gateway
+           function.
+
+   4   MPLS-TP and its interfaces, both internal and external, MUST be
+       sufficiently well-defined that interworking equipment supplied by
+       multiple vendors will be possible both within a single domain and
+       between domains.
+
+   5   MPLS-TP MUST be a connection-oriented packet-switching technology
+       with traffic-engineering capabilities that allow deterministic
+       control of the use of network resources.
+
+   6   MPLS-TP MUST support traffic-engineered point-to-point (P2P) and
+       point-to-multipoint (P2MP) transport paths.
+
+   7   MPLS-TP MUST support unidirectional, co-routed bidirectional, and
+       associated bidirectional point-to-point transport paths.
+
+   8   MPLS-TP MUST support unidirectional point-to-multipoint transport
+       paths.
+
+   9   The end points of a co-routed bidirectional transport path MUST
+       be aware of the pairing relationship of the forward and reverse
+       paths used to support the bidirectional service.
+
+   10  All nodes on the path of a co-routed bidirectional transport path
+       in the same (sub)layer as the path MUST be aware of the pairing
+       relationship of the forward and the backward directions of the
+       transport path.
+
+   11  The end points of an associated bidirectional transport path MUST
+       be aware of the pairing relationship of the forward and reverse
+       paths used to support the bidirectional service.
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 13]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   12  Nodes on the path of an associated bidirectional transport path
+       where both the forward and backward directions transit the same
+       node in the same (sub)layer as the path SHOULD be aware of the
+       pairing relationship of the forward and the backward directions
+       of the transport path.
+
+   13  MPLS-TP MUST support bidirectional transport paths with symmetric
+       bandwidth requirements, i.e., the amount of reserved bandwidth is
+       the same between the forward and backward directions.
+
+   14  MPLS-TP MUST support bidirectional transport paths with
+       asymmetric bandwidth requirements, i.e., the amount of reserved
+       bandwidth differs between the forward and backward directions.
+
+   15  MPLS-TP MUST support the logical separation of the control and
+       management planes from the data plane.
+
+   16  MPLS-TP MUST support the physical separation of the control and
+       management planes from the data plane.  That is, it must be
+       possible to operate the control and management planes out-of-
+       band, and no assumptions should be made about the state of the
+       data-plane channels from information about the control or
+       management-plane channels when they are running out-of-band.
+
+   17  MPLS-TP MUST support static provisioning of transport paths via
+       the management plane.
+
+   18  A solution MUST be defined to support dynamic provisioning and
+       restoration of MPLS-TP transport paths via a control plane.
+
+   19  Static provisioning MUST NOT depend on the presence of any
+       element of a control plane.
+
+   20  MPLS-TP MUST support the coexistence of statically and
+       dynamically provisioned/managed MPLS-TP transport paths within
+       the same layer network or domain.
+
+   21  Mechanisms in an MPLS-TP layer network that satisfy functional
+       requirements that are common to general transport-layer networks
+       (i.e., independent of technology) SHOULD be operable in a way
+       that is similar to the way the equivalent mechanisms are operated
+       in other transport-layer technologies.
+
+   22  MPLS-TP MUST support the capability for network operation via the
+       management plane (without the use of any control-plane
+       protocols).  This includes the configuration and control of OAM
+       and recovery functions.
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 14]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   23  The MPLS-TP data plane MUST be capable of
+
+       A.  forwarding data independent of the control or management
+           plane used to configure and operate the MPLS-TP layer
+           network.
+
+       B.  taking recovery actions independent of the control or
+           management plane used to configure the MPLS-TP layer network.
+
+       C.  operating normally (i.e., forwarding, OAM, and protection
+           MUST continue to operate) if the management plane or control
+           plane that configured the transport paths fails.
+
+   24  MPLS-TP MUST support mechanisms to avoid or minimize traffic
+       impact (e.g., packet delay, reordering, and loss) during network
+       reconfiguration.
+
+   25  MPLS-TP MUST support transport paths through multiple homogeneous
+       domains.
+
+   26  MPLS-TP SHOULD support transport paths through multiple non-
+       homogeneous domains.
+
+   27  MPLS-TP MUST NOT dictate the deployment of any particular network
+       topology either physical or logical, however:
+
+       A.  It MUST be possible to deploy MPLS-TP in rings.
+
+       B.  It MUST be possible to deploy MPLS-TP in arbitrarily
+           interconnected rings with one or two points of
+           interconnection.
+
+       C.  MPLS-TP MUST support rings of at least 16 nodes in order to
+           support the upgrade of existing Time-Division Multiplexing
+           (TDM) rings to MPLS-TP.  MPLS-TP SHOULD support rings with
+           more than 16 nodes.
+
+   28  MPLS-TP MUST be able to scale at least as well as existing
+       transport technologies with growing and increasingly complex
+       network topologies as well as with increasing amounts of
+       customers, services, and bandwidth demand.
+
+   29  MPLS-TP SHOULD support mechanisms to safeguard against the
+       provisioning of transport paths which contain forwarding loops.
+
+
+
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 15]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+2.2.  Layering Requirements
+
+   30  A generic and extensible solution MUST be provided to support the
+       transport of one or more client layer networks (e.g., MPLS-TP,
+       IP, MPLS, Ethernet, ATM, FR, etc.) over an MPLS-TP layer network.
+
+   31  A generic and extensible solution MUST be provided to support the
+       transport of MPLS-TP transport paths over one or more server
+       layer networks (such as MPLS-TP, Ethernet, SONET/SDH, OTN, etc.).
+       Requirements for bandwidth management within a server layer
+       network are outside the scope of this document.
+
+   32  In an environment where an MPLS-TP layer network is supporting a
+       client layer network, and the MPLS-TP layer network is supported
+       by a server layer network, then operation of the MPLS-TP layer
+       network MUST be possible without any dependencies on the server
+       or client layer network.
+
+       A.  The server layer MUST guarantee that the traffic-loading
+           imposed by other clients does not cause the transport service
+           provided to the MPLS-TP layer to fall below the agreed level.
+           Mechanisms to achieve this are outside the scope of these
+           requirements.
+
+       B.  It MUST be possible to isolate the control and management
+           planes of the MPLS-TP layer network from the control and
+           management planes of the client and server layer networks.
+
+   33  A solution MUST be provided to support the transport of a client
+       MPLS or MPLS-TP layer network over a server MPLS or MPLS-TP layer
+       network.
+
+       A.  The level of coordination required between the client and
+           server MPLS(-TP) layer networks MUST be minimized (preferably
+           no coordination will be required).
+
+       B.  The MPLS(-TP) server layer network MUST be capable of
+           transporting the complete set of packets generated by the
+           client MPLS(-TP) layer network, which may contain packets
+           that are not MPLS packets (e.g., IP or Connectionless Network
+           Protocol (CNLP) packets used by the control/management plane
+           of the client MPLS(-TP) layer network).
+
+   34  It MUST be possible to operate the layers of a multi-layer
+       network that includes an MPLS-TP layer autonomously.
+
+
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 16]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   The above are not only technology requirements, but also operational
+   requirements.  Different administrative groups may be responsible for
+   the same layer network or different layer networks.
+
+   35  It MUST be possible to hide MPLS-TP layer network addressing and
+       other information (e.g., topology) from client layer networks.
+       However, it SHOULD be possible, at the option of the operator, to
+       leak a limited amount of summarized information (such as SRLGs or
+       reachability) between layers.
+
+2.3.  Data Plane Requirements
+
+   36  It MUST be possible to operate and configure the MPLS-TP data
+       plane without any IP forwarding capability in the MPLS-TP data
+       plane.  That is, the data plane only operates on the MPLS label.
+
+   37  It MUST be possible for the end points of an MPLS-TP transport
+       path that is carrying an aggregate of client transport paths to
+       be able to decompose the aggregate transport path into its
+       component client transport paths.
+
+   38  A transport path on a link MUST be uniquely identifiable by a
+       single label on that link.
+
+   39  A transport path's source MUST be identifiable at its destination
+       within its layer network.
+
+   40  MPLS-TP MUST be capable of using P2MP server (sub)layer
+       capabilities as well as P2P server (sub)layer capabilities when
+       supporting P2MP MPLS-TP transport paths.
+
+   41  MPLS-TP MUST be extensible in order to accommodate new types of
+       client layer networks and services.
+
+   42  MPLS-TP SHOULD support mechanisms to enable the reserved
+       bandwidth associated with a transport path to be increased
+       without impacting the existing traffic on that transport path
+       provided enough resources are available.
+
+   43  MPLS-TP SHOULD support mechanisms to enable the reserved
+       bandwidth of a transport path to be decreased without impacting
+       the existing traffic on that transport path, provided that the
+       level of existing traffic is smaller than the reserved bandwidth
+       following the decrease.
+
+
+
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 17]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   44  MPLS-TP MUST support mechanisms that ensure the integrity of the
+       transported customer's service traffic as required by its
+       associated SLA.  Loss of integrity may be defined as packet
+       corruption, reordering, or loss during normal network conditions.
+
+   45  MPLS-TP MUST support mechanisms to detect when loss of integrity
+       of the transported customer's service traffic has occurred.
+
+   46  MPLS-TP MUST support an unambiguous and reliable means of
+       distinguishing users' (client) packets from MPLS-TP control
+       packets (e.g., control plane, management plane, OAM, and
+       protection-switching packets).
+
+2.4.  Control Plane Requirements
+
+   This section defines the requirements that apply to an MPLS-TP
+   control plane.  Note that it MUST be possible to operate an MPLS-TP
+   network without using a control plane.
+
+   The ITU-T has defined an architecture for Automatically Switched
+   Optical Networks (ASONs) in G.8080 [ITU.G8080.2006] and G.8080
+   Amendment 1 [ITU.G8080.2008].  The control plane for MPLS-TP MUST fit
+   within the ASON architecture.
+
+   An interpretation of the ASON signaling and routing requirements in
+   the context of GMPLS can be found in [RFC4139] and [RFC4258].
+
+   Additionally:
+
+   47  The MPLS-TP control plane MUST support control-plane topology and
+       data-plane topology independence.  As a consequence, a failure of
+       the control plane does not imply that there has also been a
+       failure of the data plane.
+
+   48  The MPLS-TP control plane MUST be able to be operated
+       independently of any particular client- or server-layer control
+       plane.
+
+   49  MPLS-TP SHOULD define a solution to support an integrated control
+       plane encompassing MPLS-TP together with its server and client
+       layer networks when these layer networks belong to the same
+       administrative domain.
+
+   50  The MPLS-TP control plane MUST support establishing all the
+       connectivity patterns defined for the MPLS-TP data plane (i.e.,
+       unidirectional P2P, associated bidirectional P2P, co-routed
+       bidirectional P2P, unidirectional P2MP) including configuration
+       of protection functions and any associated maintenance functions.
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 18]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   51  The MPLS-TP control plane MUST support the configuration and
+       modification of OAM maintenance points as well as the activation/
+       deactivation of OAM when the transport path or transport service
+       is established or modified.
+
+   52  An MPLS-TP control plane MUST support operation of the recovery
+       functions described in Section 2.8.
+
+   53  An MPLS-TP control plane MUST scale gracefully to support a large
+       number of transport paths, nodes, and links.
+
+   54  If a control plane is used for MPLS-TP, following a control-plane
+       failure, the control plane MUST be capable of restarting and
+       relearning its previous state without impacting forwarding.
+
+   55  An MPLS-TP control plane MUST provide a mechanism for dynamic
+       ownership transfer of the control of MPLS-TP transport paths from
+       the management plane to the control plane and vice versa.  The
+       number of reconfigurations required in the data plane MUST be
+       minimized (preferably no data-plane reconfiguration will be
+       required).
+
+2.5.  Recovery Requirements
+
+   Network survivability plays a critical role in the delivery of
+   reliable services.  Network availability is a significant contributor
+   to revenue and profit.  Service guarantees in the form of SLAs
+   require a resilient network that rapidly detects facility or node
+   failures and restores network operation in accordance with the terms
+   of the SLA.
+
+   56  MPLS-TP MUST provide protection and restoration mechanisms.
+
+       A.  MPLS-TP recovery techniques SHOULD be identical (or as
+           similar as possible) to those already used in existing
+           transport networks to simplify implementation and operations.
+           However, this MUST NOT override any other requirement.
+
+       B.  Recovery techniques used for P2P and P2MP SHOULD be identical
+           to simplify implementation and operation.  However, this MUST
+           NOT override any other requirement.
+
+   57  MPLS-TP recovery mechanisms MUST be applicable at various levels
+       throughout the network including support for link, transport
+       path, segment, concatenated segment, and end-to-end recovery.
+
+   58  MPLS-TP recovery paths MUST meet the SLA protection objectives of
+       the service.
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 19]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+       A.  MPLS-TP MUST provide mechanisms to guarantee 50ms recovery
+           times from the moment of fault detection in networks with
+           spans less than 1200 km.
+
+       B.  For protection it MUST be possible to require protection of
+           100% of the traffic on the protected path.
+
+       C.  Recovery MUST meet SLA requirements over multiple domains.
+
+   59  Recovery objectives SHOULD be configurable per transport path.
+
+   60  The recovery mechanisms SHOULD be applicable to any topology.
+
+   61  The recovery mechanisms MUST support the means to operate in
+       synergy with (including coordination of timing) the recovery
+       mechanisms present in any client or server transport networks
+       (for example, Ethernet, SDH, OTN, WDM) to avoid race conditions
+       between the layers.
+
+   62  MPLS-TP recovery and reversion mechanisms MUST prevent frequent
+       operation of recovery in the event of an intermittent defect.
+
+2.5.1.  Data-Plane Behavior Requirements
+
+   General protection and survivability requirements are expressed in
+   terms of the behavior in the data plane.
+
+2.5.1.1.  Protection
+
+   Note: Only nodes that are aware of the pairing relationship between
+   the forward and backward directions of an associated bidirectional
+   transport path can be used as end points to protect all or part of
+   that transport path.
+
+   63  It MUST be possible to provide protection for the MPLS-TP data
+       plane without any IP forwarding capability in the MPLS-TP data
+       plane.  That is, the data plane only operates on the MPLS label.
+
+   64  MPLS-TP protection mechanisms MUST support revertive and non-
+       revertive behavior.
+
+   65  MPLS-TP MUST support 1+1 protection.
+
+       A.  Bidirectional 1+1 protection for P2P connectivity MUST be
+           supported.
+
+       B.  Unidirectional 1+1 protection for P2P connectivity MUST be
+           supported.
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 20]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+       C.  Unidirectional 1+1 protection for P2MP connectivity MUST be
+           supported.
+
+   66  MPLS-TP MUST support the ability to share protection resources
+       amongst a number of transport paths.
+
+   67  MPLS-TP MUST support 1:n protection (including 1:1 protection).
+
+       A.  Bidirectional 1:n protection for P2P connectivity MUST be
+           supported and SHOULD be the default behavior for 1:n
+           protection.
+
+       B.  Unidirectional 1:n protection for P2MP connectivity MUST be
+           supported.
+
+       C.  Unidirectional 1:n protection for P2P connectivity is not
+           required and MAY be omitted from the MPLS-TP specifications.
+
+       D.  The action of protection-switching MUST NOT cause the user
+           data to enter an uncontrolled loop.  The protection-switching
+           system MAY cause traffic to pass over a given link more than
+           once, but it must do so in a controlled way such that
+           uncontrolled loops do not form.
+
+   Note: Support for extra traffic (as defined in [RFC4427]) is not
+   required in MPLS-TP and MAY be omitted from the MPLS-TP
+   specifications.
+
+2.5.1.2.  Sharing of Protection Resources
+
+   68  MPLS-TP SHOULD support 1:n (including 1:1) shared mesh recovery.
+
+   69  MPLS-TP MUST support sharing of protection resources such that
+       protection paths that are known not to be required concurrently
+       can share the same resources.
+
+2.5.2.  Restoration
+
+   70  The restoration transport path MUST be able to share resources
+       with the transport path being replaced (sometimes known as soft
+       rerouting).
+
+   71  Restoration priority MUST be supported so that an implementation
+       can determine the order in which transport paths should be
+       restored (to minimize service restoration time as well as to gain
+       access to available spare capacity on the best paths).
+
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 21]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   72  Preemption priority MUST be supported to allow restoration to
+       displace other transport paths in the event of resource
+       constraint.
+
+   73  MPLS-TP restoration mechanisms MUST support revertive and non-
+       revertive behavior.
+
+2.5.3.  Triggers for Protection, Restoration, and Reversion
+
+   Recovery actions may be triggered from different places as follows:
+
+   74  MPLS-TP MUST support fault indication triggers from lower layers.
+       This includes faults detected and reported by lower-layer
+       protocols, and faults reported directly by the physical medium
+       (for example, loss of light).
+
+   75  MPLS-TP MUST support OAM-based triggers.
+
+   76  MPLS-TP MUST support management-plane triggers (e.g., forced
+       switch, etc.).
+
+   77  There MUST be a mechanism to distinguish administrative recovery
+       actions from recovery actions initiated by other triggers.
+
+   78  Where a control plane is present, MPLS-TP SHOULD support control-
+       plane restoration triggers.
+
+   79  MPLS-TP protection mechanisms MUST support priority logic to
+       negotiate and accommodate coexisting requests (i.e., multiple
+       requests) for protection-switching (e.g., administrative requests
+       and requests due to link/node failures).
+
+2.5.4.  Management-Plane Operation of Protection and Restoration
+
+   All functions described here are for control by the operator.
+
+   80  It MUST be possible to configure protection paths and protection-
+       to-working path relationships (sometimes known as protection
+       groups).
+
+   81  There MUST be support for pre-calculation of recovery paths.
+
+   82  There MUST be support for pre-provisioning of recovery paths.
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 22]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   83  The external controls as defined in [RFC4427] MUST be supported.
+
+       A.  External controls overruled by higher priority requests
+           (e.g., administrative requests and requests due to link/node
+           failures) or unable to be signaled to the remote end (e.g.,
+           due to a coordination failure of the protection state) MUST
+           be dropped.
+
+   84  It MUST be possible to test and validate any protection/
+       restoration mechanisms and protocols:
+
+       A.  Including the integrity of the protection/recovery transport
+           path.
+
+       B.  Without triggering the actual protection/restoration.
+
+       C.  While the working path is in service.
+
+       D.  While the working path is out of service.
+
+   85  Restoration resources MAY be pre-planned and selected a priori,
+       or computed after failure occurrence.
+
+   86  When preemption is supported for restoration purposes, it MUST be
+       possible for the operator to configure it.
+
+   87  The management plane MUST provide indications of protection
+       events and triggers.
+
+   88  The management plane MUST allow the current protection status of
+       all transport paths to be determined.
+
+2.5.5.  Control Plane and In-Band OAM Operation of Recovery
+
+   89  The MPLS-TP control plane (which is not mandatory in an MPLS-TP
+       implementation) MUST be capable of supporting:
+
+       A.  establishment and maintenance of all recovery entities and
+           functions
+
+       B.  signaling of administrative control
+
+       C.  protection state coordination (PSC).  Since control plane
+           network topology is independent from the data plane network
+           topology, the PSC supported by the MPLS-TP control plane MAY
+           run on resources different than the data plane resources
+           handled within the recovery mechanism (e.g., backup).
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 23]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   90  In-band OAM MUST be capable of supporting:
+
+       A.  signaling of administrative control
+
+       B.  protection state coordination (PSC).  Since in-band OAM tools
+           share the data plane with the carried transport service, in
+           order to optimize the usage of network resources, the PSC
+           supported by in-band OAM MUST run on protection resources.
+
+2.5.6.  Topology-Specific Recovery Mechanisms
+
+   91  MPLS-TP MAY support recovery mechanisms that are optimized for
+       specific network topologies.  These mechanisms MUST be
+       interoperable with the mechanisms defined for arbitrary topology
+       (mesh) networks to enable protection of end-to-end transport
+       paths.
+
+2.5.6.1.  Ring Protection
+
+   Several service providers have expressed a high level of interest in
+   operating MPLS-TP in ring topologies and require a high level of
+   survivability function in these topologies.  The requirements listed
+   below have been collected from these service providers and from the
+   ITU-T.
+
+   The main objective in considering a specific topology (such as a
+   ring) is to determine whether it is possible to optimize any
+   mechanisms such that the performance of those mechanisms within the
+   topology is significantly better than the performance of the generic
+   mechanisms in the same topology.  The benefits of such optimizations
+   are traded against the costs of developing, implementing, deploying,
+   and operating the additional optimized mechanisms noting that the
+   generic mechanisms MUST continue to be supported.
+
+   Within the context of recovery in MPLS-TP networks, the optimization
+   criteria considered in ring topologies are as follows:
+
+   a.  Minimize the number of OAM entities that are needed to trigger
+       the recovery operation, such that it is less than is required by
+       other recovery mechanisms.
+
+   b.  Minimize the number of elements of recovery in the ring, such
+       that it is less than is required by other recovery mechanisms.
+
+   c.  Minimize the number of labels required for the protection paths
+       across the ring, such that it is less than is required by other
+       recovery mechanisms.
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 24]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   d.  Minimize the amount of control and management-plane transactions
+       during a maintenance operation (e.g., ring upgrade), such that it
+       is less than the amount required by other recovery mechanisms.
+
+   e.  When a control plane is supported, minimize the impact on
+       signaling and routing information exchange during protection,
+       such that it is less than the impact caused by other recovery
+       mechanisms.
+
+   It may be observed that the requirements in Section 2.5.6.1 are fully
+   compatible with the generic requirements expressed in Section 2.5
+   through Section 2.5.6 inclusive, and that no requirements that are
+   specific to ring topologies have been identified.
+
+   92   MPLS-TP MUST include recovery mechanisms that operate in any
+        single ring supported in MPLS-TP, and continue to operate within
+        the single rings even when the rings are interconnected.
+
+   93   When a network is constructed from interconnected rings, MPLS-TP
+        MUST support recovery mechanisms that protect user data that
+        traverses more than one ring.  This includes the possibility of
+        failure of the ring-interconnect nodes and links.
+
+   94   MPLS-TP recovery in a ring MUST protect unidirectional and
+        bidirectional P2P transport paths.
+
+   95   MPLS-TP recovery in a ring MUST protect unidirectional P2MP
+        transport paths.
+
+   96   MPLS-TP 1+1 and 1:1 protection in a ring MUST support switching
+        time within 50 ms from the moment of fault detection in a
+        network with a 16-node ring with less than 1200 km of fiber.
+
+   97   The protection switching time in a ring MUST be independent of
+        the number of LSPs crossing the ring.
+
+   98   The configuration and operation of recovery mechanisms in a ring
+        MUST scale well with:
+
+        A.  the number of transport paths (MUST be better than linear
+            scaling)
+
+        B.  the number of nodes on the ring (MUST be at least as good as
+            linear scaling)
+
+        C.  the number of ring interconnects (MUST be at least as good
+            as linear scaling)
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 25]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   99   Recovery techniques used in a ring MUST NOT prevent the ring
+        from being connected to a general MPLS-TP network in any
+        arbitrary way, and MUST NOT prevent the operation of recovery
+        techniques in the rest of the network.
+
+   100  Recovery techniques in a ring SHOULD be identical (or as similar
+        as possible) to those in general transport networks to simplify
+        implementation and operations.  However, this MUST NOT override
+        any other requirement.
+
+   101  Recovery techniques in logical and physical rings SHOULD be
+        identical to simplify implementation and operation.  However,
+        this MUST NOT override any other requirement.
+
+   102  The default recovery scheme in a ring MUST be bidirectional
+        recovery in order to simplify the recovery operation.
+
+   103  The recovery mechanism in a ring MUST support revertive
+        switching, which MUST be the default behavior.  This allows
+        optimization of the use of the ring resources, and restores the
+        preferred quality conditions for normal traffic (e.g., delay)
+        when the recovery mechanism is no longer needed.
+
+   104  The recovery mechanisms in a ring MUST support ways to
+        distinguish administrative protection-switching from protection-
+        switching initiated by other triggers.
+
+   105  It MUST be possible to lockout (disable) protection mechanisms
+        on selected links (spans) in a ring (depending on the operator's
+        need).  This may require lockout mechanisms to be applied to
+        intermediate nodes within a transport path.
+
+   106  MPLS-TP recovery mechanisms in a ring:
+
+        A.  MUST include a mechanism to allow an implementation to
+            handle and coordinate coexisting requests or triggers for
+            protection-switching based on priority.  (For example, this
+            includes multiple requests that are not necessarily arriving
+            simultaneously and that are located anywhere in the ring.)
+            Note that such coordination of the ring is equivalent to the
+            use of shared protection groups.
+
+        B.  SHOULD protect against multiple failures
+
+   107  MPLS-TP recovery and reversion mechanisms in a ring MUST offer a
+        way to prevent frequent operation of recovery in the event of an
+        intermittent defect.
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 26]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   108  MPLS-TP MUST support the sharing of protection bandwidth in a
+        ring by allowing best-effort traffic.
+
+   109  MPLS-TP MUST support sharing of ring protection resources such
+        that protection paths that are known not to be required
+        concurrently can share the same resources.
+
+2.6.  QoS Requirements
+
+   Carriers require advanced traffic-management capabilities to enforce
+   and guarantee the QoS parameters of customers' SLAs.
+
+   Quality-of-service mechanisms are REQUIRED in an MPLS-TP network to
+   ensure:
+
+   110  Support for differentiated services and different traffic types
+        with traffic class separation associated with different traffic.
+
+   111  Enabling the provisioning and the guarantee of Service Level
+        Specifications (SLSs), with support for hard and relative end-
+        to-end bandwidth guaranteed.
+
+   112  Support of services, which are sensitive to jitter and delay.
+
+   113  Guarantee of fair access, within a particular class, to shared
+        resources.
+
+   114  Guaranteed resources for in-band control and management-plane
+        traffic, regardless of the amount of data-plane traffic.
+
+   115  Carriers are provided with the capability to efficiently support
+        service demands over the MPLS-TP network.  This MUST include
+        support for a flexible bandwidth allocation scheme.
+
+3.  Requirements Discussed in Other Documents
+
+3.1.  Network Management Requirements
+
+   For requirements related to network management functionality
+   (Management Plane in ITU-T terminology) for MPLS-TP, see the MPLS-TP
+   Network Management requirements document [TP-NM-REQ].
+
+3.2.  Operation, Administration, and Maintenance (OAM) Requirements
+
+   For requirements related to OAM functionality for MPLS-TP, see the
+   MPLS-TP OAM requirements document [TP-OAM-REQS].
+
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 27]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+3.3.  Network Performance-Monitoring Requirements
+
+   For requirements related to performance-monitoring functionality for
+   MPLS-TP, see the MPLS-TP OAM requirements document [TP-OAM-REQS].
+
+3.4.  Security Requirements
+
+   For a description of the security threats relevant in the context of
+   MPLS and GMPLS and the defensive techniques to combat those threats,
+   see "Security Framework for MPLS and GMPLS Networks" [G/MPLS-SEC].
+
+   For a description of additional security threats relevant in the
+   context of MPLS-TP and the defensive techniques to combat those
+   threats see "Security Framework for MPLS-TP" [TP-SEC-FMWK].
+
+4.  Security Considerations
+
+   See Section 3.4.
+
+5.  Acknowledgements
+
+   The authors would like to thank all members of the teams (the Joint
+   Working Team, the MPLS Interoperability Design Team in the IETF, and
+   the T-MPLS Ad Hoc Group in the ITU-T) involved in the definition and
+   specification of the MPLS Transport Profile.
+
+   The authors would also like to thank Loa Andersson, Dieter Beller,
+   Lou Berger, Italo Busi, John Drake, Adrian Farrel, Annamaria
+   Fulignoli, Pietro Grandi, Eric Gray, Neil Harrison, Jia He, Huub van
+   Helvoort, Enrique Hernandez-Valencia, Wataru Imajuku, Kam Lam, Andy
+   Malis, Alan McGuire, Julien Meuric, Greg Mirsky, Tom Nadeau, Hiroshi
+   Ohta, Tom Petch, Andy Reid, Vincenzo Sestito, George Swallow, Lubo
+   Tancevski, Tomonori Takeda, Yuji Tochio, Alexander Vainshtein, Eve
+   Varma, and Maarten Vissers for their comments and enhancements to the
+   text.
+
+   An ad hoc discussion group consisting of Stewart Bryant, Italo Busi,
+   Andrea Digiglio, Li Fang, Adrian Farrel, Jia He, Huub van Helvoort,
+   Feng Huang, Harald Kullman, Han Li, Hao Long, and Nurit Sprecher
+   provided valuable input to the requirements for deployment and
+   survivability in ring topologies.
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 28]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
+                     Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3031]         Rosen, E., Viswanathan, A., and R. Callon,
+                     "Multiprotocol Label Switching Architecture",
+                     RFC 3031, January 2001.
+
+   [RFC3985]         Bryant, S. and P. Pate, "Pseudo Wire Emulation
+                     Edge-to-Edge (PWE3) Architecture", RFC 3985,
+                     March 2005.
+
+   [RFC4929]         Andersson, L. and A. Farrel, "Change Process for
+                     Multiprotocol Label Switching (MPLS) and
+                     Generalized MPLS (GMPLS) Protocols and Procedures",
+                     BCP 129, RFC 4929, June 2007.
+
+   [ITU.G805.2000]   International Telecommunications Union, "Generic
+                     functional architecture of transport networks",
+                     ITU-T Recommendation G.805, March 2000.
+
+   [ITU.G8080.2006]  International Telecommunications Union,
+                     "Architecture for the automatically switched
+                     optical network (ASON)", ITU-T Recommendation
+                     G.8080, June 2006.
+
+   [ITU.G8080.2008]  International Telecommunications Union,
+                     "Architecture for the automatically switched
+                     optical network (ASON) Amendment 1", ITU-T
+                     Recommendation G.8080 Amendment 1, March 2008.
+
+6.2.  Informative References
+
+   [RFC4139]         Papadimitriou, D., Drake, J., Ash, J., Farrel, A.,
+                     and L. Ong, "Requirements for Generalized MPLS
+                     (GMPLS) Signaling Usage and Extensions for
+                     Automatically Switched Optical Network (ASON)",
+                     RFC 4139, July 2005.
+
+   [RFC4258]         Brungard, D., "Requirements for Generalized Multi-
+                     Protocol Label Switching (GMPLS) Routing for the
+                     Automatically Switched Optical Network (ASON)",
+                     RFC 4258, November 2005.
+
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 29]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+   [RFC4397]         Bryskin, I. and A. Farrel, "A Lexicography for the
+                     Interpretation of Generalized Multiprotocol Label
+                     Switching (GMPLS) Terminology within the Context of
+                     the ITU-T's Automatically Switched Optical Network
+                     (ASON) Architecture", RFC 4397, February 2006.
+
+   [RFC4427]         Mannie, E. and D. Papadimitriou, "Recovery
+                     (Protection and Restoration) Terminology for
+                     Generalized Multi-Protocol Label Switching
+                     (GMPLS)", RFC 4427, March 2006.
+
+   [TP-SEC-FMWK]     Fang, L. and B. Niven-Jenkins, "Security Framework
+                     for MPLS-TP", Work in Progress, July 2009.
+
+   [G/MPLS-SEC]      Fang, L., Ed., "Security Framework for MPLS and
+                     GMPLS Networks", Work in Progress, July 2009.
+
+   [TP-NM-REQ]       Lam, H., Mansfield, S., and E. Gray, "MPLS TP
+                     Network Management Requirements", Work in Progress,
+                     June 2009.
+
+   [TP-TERMS]        van Helvoort, H., Ed., Andersson, L., Ed., and N.
+                     Sprecher, Ed., "A Thesaurus for the Terminology
+                     used in Multiprotocol Label Switching Transport
+                     Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport
+                     Network Recommendations", Work in Progress,
+                     June 2009.
+
+   [TP-OAM-REQS]     Vigoureux, M., Ed., Ward, D., Ed., and M. Betts,
+                     Ed., "Requirements for OAM in MPLS Transport
+                     Networks", Work in Progress, June 2009.
+
+   [MS-PW-ARCH]      Bocci, M. and S. Bryant, "An Architecture for
+                     Multi-Segment Pseudowire Emulation Edge-to-Edge",
+                     Work in Progress, July 2009.
+
+   [ITU.Y1401.2008]  International Telecommunications Union, "Principles
+                     of interworking", ITU-T Recommendation Y.1401,
+                     February 2008.
+
+   [ITU.Y2611.2006]  International Telecommunications Union, "High-level
+                     architecture of future packet-based networks",
+                     ITU-T Recommendation Y.2611, December 2006.
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 30]
+
+RFC 5654                  MPLS-TP Requirements            September 2009
+
+
+Authors' Addresses
+
+   Ben Niven-Jenkins (editor)
+   BT
+   PP8a, 1st Floor, Orion Building, Adastral Park
+   Ipswich, Suffolk  IP5 3RE
+   UK
+
+   EMail: benjamin.niven-jenkins@bt.com
+
+
+   Deborah Brungard (editor)
+   AT&T
+   Rm. D1-3C22 - 200 S. Laurel Ave.
+   Middletown, NJ  07748
+   USA
+
+   EMail: dbrungard@att.com
+
+
+   Malcolm Betts (editor)
+   Huawei Technologies
+
+   EMail: malcolm.betts@huawei.com
+
+
+   Nurit Sprecher
+   Nokia Siemens Networks
+   3 Hanagar St. Neve Ne'eman B
+   Hod Hasharon,   45241
+   Israel
+
+   EMail: nurit.sprecher@nsn.com
+
+
+   Satoshi Ueno
+   NTT Communications
+
+   EMail: satoshi.ueno@ntt.com
+
+
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.       Standards Track                    [Page 31]
+