GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5654

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5654.txt · Last modified: 2009/09/24 14:24 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki