[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-jenkins-mpls-mpls-tp-requirements) 00 01 02 03 04 05 06 07 08 09 10 RFC 5654

Network Working Group                              B. Niven-Jenkins, Ed.
Internet-Draft                                                        BT
Intended status: Informational                          D. Brungard, Ed.
Expires: July 7, 2009                                               AT&T
                                                           M. Betts, Ed.
                                                         Nortel Networks
                                                             N. Sprecher
                                                  Nokia Siemens Networks
                                                                 S. Ueno
                                                                     NTT
                                                         January 3, 2009


                          MPLS-TP Requirements
                   draft-ietf-mpls-tp-requirements-02

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 7, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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



Niven-Jenkins, et al.     Expires July 7, 2009                  [Page 1]


Internet-Draft            MPLS-TP Requirements              January 2009


   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   This document specifies the requirements of an MPLS Transport Profile
   (MPLS-TP).  This document is a product of a joint International
   Telecommunications Union (ITU)-IETF effort to include an MPLS
   Transport Profile within the IETF MPLS architecture 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 architecture
   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.

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 [RFC2119].
























Niven-Jenkins, et al.     Expires July 7, 2009                  [Page 2]


Internet-Draft            MPLS-TP Requirements              January 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
     1.2.  Transport network overview . . . . . . . . . . . . . . . .  7
   2.  MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . .  8
     2.1.  General requirements . . . . . . . . . . . . . . . . . . .  9
     2.2.  Layering requirements  . . . . . . . . . . . . . . . . . . 11
     2.3.  Data plane requirements  . . . . . . . . . . . . . . . . . 11
     2.4.  Control plane requirements . . . . . . . . . . . . . . . . 12
     2.5.  Network Management (NM) requirements . . . . . . . . . . . 13
     2.6.  Operation, Administration and Maintenance (OAM)
           requirements . . . . . . . . . . . . . . . . . . . . . . . 14
     2.7.  Network performance management (PM) requirements . . . . . 14
     2.8.  Recovery & Survivability requirements  . . . . . . . . . . 14
       2.8.1.  Data plane behavior requirements . . . . . . . . . . . 15
       2.8.2.  Triggers for protection, restoration, and reversion  . 17
       2.8.3.  Management plane operation of protection and
               restoration  . . . . . . . . . . . . . . . . . . . . . 17
       2.8.4.  Control plane and in-band OAM operation of recovery  . 18
       2.8.5.  Topology-specific recovery mechanisms  . . . . . . . . 18
     2.9.  QoS requirements . . . . . . . . . . . . . . . . . . . . . 22
     2.10. Security requirements  . . . . . . . . . . . . . . . . . . 22
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 23
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25





















Niven-Jenkins, et al.     Expires July 7, 2009                  [Page 3]


Internet-Draft            MPLS-TP Requirements              January 2009


1.  Introduction

   For many years, Synchronous Optical Networking (SONET)/Synchronous
   Digital hierarchy (SDH) has provided carriers with a high benchmark
   for reliability and operational simplicity.  With the accelerating
   growth and penetration of:

   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 QoS requirements.

   Carriers are in need of technologies capable of efficiently
   supporting packet-based services and applications on their transport
   networks.  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.

   Carriers are considering migrating or evolving to packet transport
   networks in order to reduce their costs and to improve their ability
   to support services with guaranteed Service Level Agreements (SLAs).
   For carriers it is important that migrating from SONET/SDH to packet
   transport networks should not involve dramatic changes in network
   operation, should not necessitate extensive retraining, and should
   not require major changes to existing work practices.  The aim is to
   preserve the look-and-feel to which carriers have become accustomed
   in deploying their SONET/SDH networks, while providing common, multi-
   layer operations, resiliency, control and management for packet,
   circuit and lambda transport networks.

   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 (Operations Support System (OSS)
   based) or dynamic (control plane) provisioning of deterministic,
   protected and secured services and their associated resources.

   Carriers will still need to cope with legacy networks (which are
   composed of many layers and technologies), thus the packet transport
   network should interwork with other packet and transport networks
   (both horizontally and vertically).  Vertical interworking is also
   known as client/server or network interworking.  Horizontal
   interworking is also known as peer-partition or service interworking.
   For more details on each type of interworking and some of the issues
   that may arise (especially with horizontal interworking) see



Niven-Jenkins, et al.     Expires July 7, 2009                  [Page 4]


Internet-Draft            MPLS-TP Requirements              January 2009


   [ITU.Y1401.2008].

   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 is therefore the need to
   define an MPLS Transport Profile (MPLS-TP) in order to support the
   capabilities and functionalities needed for packet transport network
   services and operations through combining the packet experience of
   MPLS with the operational experience of SONET/SDH.

   MPLS-TP will enable the migration of SONET/SDH networks to a packet-
   based network 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 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
   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-IETF effort to include an
   MPLS Transport Profile within the IETF MPLS architecture to support
   the capabilities and functionalities of a packet transport network as
   defined by ITU-T.

   This work is based on two sources of requirements, MPLS architecture
   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 are included in MPLS-TP, except where explicitly
   excluded.

   Although both static and dynamic configuration of MPLS-TP transport
   paths (including Operations, Administration and Maintenance (OAM) and
   protection capabilities) is required by this document, it MUST be
   possible for operators to be able to completely operate (including
   OAM and protection capabilities) an MPLS-TP network in the absence of
   any control plane protocols for dynamic configuration.







Niven-Jenkins, et al.     Expires July 7, 2009                  [Page 5]


Internet-Draft            MPLS-TP Requirements              January 2009


1.1.  Terminology

   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,
   survivability techniques, distributions of control functionality,
   etc.  Examples of such domains include IGP areas and Autonomous
   Systems.

   Layer network: A layer network as defined in G.805 [ITU.G805.2000]
   provides for the transfer of client information and independent
   operations (OAM) of the client OAM.  For an explanation of how a
   layer network as described by G.805 relates to the OSI concept of
   layering see Appendix I of Y.2611 [ITU.Y2611.2006].

   Link: A link as defined in G.805 [ITU.G805.2000] is used to describe
   a fixed relationship between two ports within a layer network.  A
   link is not necessarily a physical link but can also be supported by
   a transport path in the server layer (e.g.  SONET/SDH, OTN or
   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 MSPL-TP
   pseudowires) and physical data links that form a ring topology.

   Path: See Transport path.

   Physical Ring: An MPLS-TP physical ring is constructed from a set of
   LSRs and physical data links that form a ring topology.

   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 data 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: A section is a server layer (which may be MPLS-TP or a
   different technology) which provides for encapsulation and OAM of a
   MPLS-TP transport path client layer.  A section layer may provide for
   aggregation of multiple MPLS-TP clients.

   Segment: A segment is a single resource or a set of cross-connected
   resources that constitutes part of a path.  A segment may be a single
   link (hop) within a path, a series of adjacent links (hops) within a



Niven-Jenkins, et al.     Expires July 7, 2009                  [Page 6]


Internet-Draft            MPLS-TP Requirements              January 2009


   path, or the entire end-to-end-path.

   Tandem Connection: A tandem connection is an arbitrary part of a
   transport path that can be monitored (via OAM) independently from the
   end-to-end monitoring (OAM).  It may be a segment or any other
   ordered sequence of contiguous links and/or segments of a transport
   path.

   Transport path: A network connection as defined in G.805
   [ITU.G805.2000].  A Transport path corresponds to an MPLS-TP LSP or
   to an MPLS-TP LSP and its associated PW or PWs (Single Segment or
   Multi-Segment).

   Transport path layer: A layer network which provides point-to-point
   or point-to-multipoint transport paths which are used to carry a
   higher (client) layer network or aggregates of higher (client) layer
   networks, for example the transport service layer.  It provides for
   independent OAM (of the client OAM) in the transport of the clients.

   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 which provides sections
   (two-port point-to-point connections) to carry the aggregate of
   network transport path or network service layers on various physical
   media.

1.2.  Transport network overview

   The connection (or transport path) service is the basic service
   provided by a transport network.  The purpose of a transport network
   is to carry its clients (i.e. the stream of client PDUs or client
   bits) between endpoints in the network (typically over several
   intermediate nodes).  These endpoints may be service switching points
   or service terminating points.  The connection services offered to
   customers are aggregated into large transport paths with long-holding
   times and independent OAM (of the client OAM), which contribute to
   enabling the efficient and reliable operation of the transport
   network.  These transport paths are modified infrequently.

   Aggregation and hierarchy are beneficial for achieving scalability
   and security since:

   1.  They reduce the number of provisioning and forwarding states in
       the network core.




Niven-Jenkins, et al.     Expires July 7, 2009                  [Page 7]


Internet-Draft            MPLS-TP Requirements              January 2009


   2.  They reduce load and the cost of implementing service assurance
       and fault management.

   3.  Clients are 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.  The client,
   transport network and server layers are from a functional and
   operations point of view 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 provide the means to commit quality of service
   objectives to clients.  This is achieved by providing a mechanism for
   client network service demarcation for the network path together with
   an associated network resiliency mechanism.  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.

   Clients are first encapsulated.  These encapsulated client signals
   may then be aggregated into a connection for transport through the
   network in order to optimize network management.  Server layer OAM is
   used to monitor the transport integrity of the client layer or client
   aggregate.  At any hop, the aggregated signals may be further
   aggregated in lower layer transport network paths for transport
   across intermediate shared links.  The encapsulated client signals
   are extracted at the edges of aggregation domains, and are either
   delivered to the client or forwarded to another domain.  In the core
   of the network, only the server layer aggregated signals are
   monitored; individual client signals are monitored at the network
   boundary in the client layer network.  Although the connectivity of
   the client of the transport path layer may be point-to-point, point-
   to-multipoint or multipoint-to-multipoint, the transport path layer
   itself only provides point-to-point or point-to-multipoint transport
   paths which are used to carry the client.

   Quality-of-service mechanisms are required in the packet transport
   network to ensure the prioritization of critical services, to
   guarantee BW and to control jitter and delay.


2.  MPLS-TP Requirements






Niven-Jenkins, et al.     Expires July 7, 2009                  [Page 8]


Internet-Draft            MPLS-TP Requirements              January 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 sub-set (necessary and
       sufficient subset) applicable to a transport network application.

   2   Any new functionality that is defined to fulfil the requirements
       for MPLS-TP MUST be agreed within the IETF through the IETF
       consensus process and MUST re-use (as far as practically
       possible) existing MPLS standards.

   3   Mechanisms and capabilities MUST be able to interoperate, without
       a gateway function, with existing IETF MPLS [RFC3031] and IETF
       PWE3 [RFC3985] control and data planes where appropriate.

   4   MPLS-TP MUST be a connection-oriented packet switching model with
       traffic engineering capabilities that allow deterministic control
       of the use of network resources.

   5   MPLS-TP MUST support traffic engineered point to point (P2P) and
       point to multipoint (P2MP) transport paths.

   6   MPLS-TP MUST support the logical separation of the control and
       management planes from the data plane.

   7   MPLS-TP MUST allow the physical separation of the control and
       management planes from the data plane.

   8   MPLS-TP MUST support static provisioning of transport paths via
       an OSS, i.e. via the management plane.

   9   Mechanisms in an MPLS-TP network that satisfy functional
       requirements that are common to general transport networks (i.e.,
       independent of technology) SHOULD be manageable in a way that is
       coherent with the way the equivalent mechanisms are managed in
       other transport networks.

   10  Static provisioning MUST NOT depend on the presence of any
       element of a control plane.

   11  MPLS-TP MUST support the capability for network operation
       (including OAM and recovery) via the management plane (without
       the use of any control plane protocols).







Niven-Jenkins, et al.     Expires July 7, 2009                  [Page 9]


Internet-Draft            MPLS-TP Requirements              January 2009


   12  A solution MUST be provided to support dynamic provisioning of
       MPLS-TP transport paths via a control plane.

   13  The MPLS-TP data plane MUST be capable of forwarding data and
       taken recovery actions independently of the control or management
       plane used to operate the MPLS-TP layer network.  That is, the
       MPLS-TP data plane MUST continue to operate normally if the
       management plane or control plane that configured the transport
       paths fails.

   14  MPLS-TP SHOULD support mechanisms to avoid or minimize traffic
       impact (e.g. packet delay, reordering and loss) during network
       reconfiguration.

   15  MPLS-TP MUST support transport paths through multiple homogeneous
       domains.

   16  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 TDM rings to MPLS-TP.
           MPLS-TP SHOULD support rings with more than 16 nodes.

       D.  It MUST be possible to construct rings from equipment
           supplied by different vendors and to interconnect rings made
           wholly from equipment from different vendors.  [Editor's
           note: This requirement comes from work provided by ITU-T
           Q9/15.  Unless someone can provide a reason why this would
           not be the case we should remove this requirement.  It is
           equivalent to saying that all correct implementations of
           MPLS-TP MUST interwork.]

   17  MPLS-TP MUST be able to scale gracefully with growing and
       increasingly complex network topologies as well as with
       increasing bandwidth demands, number of customers, and number of
       services.

   18  MPLS-TP SHOULD support mechanisms to safeguard against the
       provisioning of transport paths which contain forwarding loops.





Niven-Jenkins, et al.     Expires July 7, 2009                 [Page 10]


Internet-Draft            MPLS-TP Requirements              January 2009


2.2.  Layering requirements

   19  An MPLS-TP network MUST be able to support one or more client
       network layers, and MUST be able to use one or more server
       network layers.

   20  A solution MUST be provided to support the transport of MPLS-TP
       transport paths over MPLS-TP (MPLS-TP as a client of MPLS-TP)

   21  A generic and extensible solution MUST be provided to support the
       transport of any client layer network (e.g.  Ethernet, ATM, FR,
       etc.) over an MPLS-TP layer network.

   22  A solution MUST be provided to support the transport of MPLS-TP
       transport paths over any server layer network (such as Ethernet,
       SONET/SDH, OTN, etc.).

   23  In an environment where an MPLS-TP layer network is supporting a
       client 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
       network.

   24  It MUST be possible to operate the layers of a multi-layer
       network that includes an MPLS-TP layer autonomously.

   The above are not only technology requirements, but also operational.
   Different administrative groups may be responsible for the same layer
   network or different layer networks.

   25  It MUST be possible to hide MPLS-TP layer network addressing and
       other information (e.g. topology) from client layers.

2.3.  Data plane requirements

   26  The identification of each transport path within its aggregate
       MUST be supported.

   27  A label in a particular link MUST uniquely identify the transport
       path within that link.

   28  A transport path's source MUST be identifiable at its destination
       within its layer network.

   29  MPLS-TP MUST support MPLS labels that are assigned by the
       downstream (with respect to data flow) node per [RFC3031] and
       [RFC3473] and MAY support context-specific MPLS labels as defined
       in [RFC5331].



Niven-Jenkins, et al.     Expires July 7, 2009                 [Page 11]


Internet-Draft            MPLS-TP Requirements              January 2009


   30  It MUST be possible to operate and configure the MPLS-TP data
       (transport) plane without any IP forwarding capability in the
       MPLS-TP data plane.

   31  MPLS-TP MUST support both unidirectional and bidirectional point-
       to-point transport paths.

   32  An MPLS-TP network MUST require the forward and backward
       directions of a bidirectional transport path to follow the same
       path at each layer.

   33  The intermediate nodes at each layer MUST be aware about the
       pairing relationship of the forward and the backward directions
       belonging to the same bi-directional transport path.

   34  MPLS-TP MAY support transport paths with asymmetric bandwidth
       requirements, i.e. the amount of reserved bandwidth differs
       between the forward and backward directions.

   35  MPLS-TP MUST support unidirectional point-to-multipoint transport
       paths.

   36  MPLS-TP MUST be extensible in order to accommodate new types of
       client networks and services.

   37  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

   38  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.

   39  MPLS-TP MUST support mechanisms which ensure the integrity of the
       transported customer's service traffic.

   40  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 MPLS-TP when a
   control plane is deployed.




Niven-Jenkins, et al.     Expires July 7, 2009                 [Page 12]


Internet-Draft            MPLS-TP Requirements              January 2009


   The requirements for ASON signalling and routing and the requirements
   for multi-region and multi-layer networks as specified in [RFC4139],
   [RFC4258] and [RFC5212] respectively apply to MPLS-TP.

   [ITU-T Comment: the MPLS-TP control plane should meet the
   requirements for ASON architecture (G.8080, ...) unless explicitly
   excluded as well as the additional MPLS-TP specific requirements
   explicitly added.]

   [Editors' Note: Following other comments on above references, need to
   produce consolidated text that references correct documents &
   requirements.]

   Additionally:

   41  The MPLS-TP control pane SHOULD support control plane topology
       and data plane topology independence.

   42  The MPLS-TP control plane MUST be able to be operated independent
       of any particular client or server layer control plane.

   43  The MPLS-TP control plane MUST support establishing all the
       connectivity patterns defined for the MPLS-TP data plane (e.g.,
       unidirectional and bidirectional P2P, unidirectional P2MP, etc.)
       including configuration of protection functions and any
       associated maintenance functions.

   44  The MPLS-TP control pane MUST support the configuration and
       modification of OAM maintenance points as well as the activation/
       deactivation of OAM when the transport path is established or
       modified.

   45  An MPLS-TP control plane MUST support operation of the recovery
       functions described in Section 2.8.

   46  An MPLS-TP control plane MUST scale gracefully to support a large
       number of transport paths, nodes and links.

   47  An MPLS-TP control plane SHOULD provide a common control
       mechanism for architecturally similar operations.

2.5.  Network Management (NM) requirements

   For requirements related to NM functionality (Management Plane in
   ITU-T terminology) for MPLS-TP, see the MPLS-TP NM requirements
   document [I-D.gray-mpls-tp-nm-req].





Niven-Jenkins, et al.     Expires July 7, 2009                 [Page 13]


Internet-Draft            MPLS-TP Requirements              January 2009


2.6.  Operation, Administration and Maintenance (OAM) requirements

   For requirements related to OAM functionality for MPLS-TP, see the
   MPLS-TP OAM requirements document
   [I-D.vigoureux-mpls-tp-oam-requirements].

2.7.  Network performance management (PM) requirements

   For requirements related to PM functionality for MPLS-TP, see the
   MPLS-TP OAM requirements document
   [I-D.vigoureux-mpls-tp-oam-requirements].

2.8.  Recovery & Survivability 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.

   The requirements in this section use the recovery terminology defined
   in RFC 4427 [RFC4427].

   48  MPLS-TP MUST provide protection and restoration mechanisms.

       A.  Recovery techniques used for P2P and P2MP SHOULD be identical
           to simplify implementation and operation.  However, this MUST
           NOT override any other requirement.

   49  MPLS-TP recovery mechanisms MUST be applicable at various levels
       throughout the network including support for link, path segment
       and end-to-end path, and pseudowire segment, and end-to-end
       pseudowire recovery.

   50  MPLS-TP recovery paths MUST meet the SLA protection objectives of
       the service.

       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 objectives SHOULD be configurable per transport
           path, and SHOULD include bandwidth and QoS.




Niven-Jenkins, et al.     Expires July 7, 2009                 [Page 14]


Internet-Draft            MPLS-TP Requirements              January 2009


   51  The recovery mechanisms MUST all be applicable to any topology.

   52  The recovery mechanisms MUST operate in synergy with (including
       coordination of timing) the recovery mechanisms present in any
       underlying server transport network (for example, Ethernet, SDH,
       OTN, WDM) to avoid race conditions between the layers.

   53  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).

   54  MPLS-TP recovery and reversion mechanisms MUST prevent frequent
       operation of recovery in the event of an intermittent defect.

   [Editors' Note: ITU-T Q9/15 and Q12/15 will provide by <TBD> a
   requirement for protection switching time in case of linear
   protection (e.g. within 50 ms) together with a reference network.]

2.8.1.  Data plane behavior requirements

   General protection and survivability requirements are expressed in
   terms of the behavior in the data plane.

2.8.1.1.  Protection

   55  MPLS-TP MUST support 1+1 Protection.

       A.  MPLS-TP 1+1 support MUST include bidirectional protection
           switching for P2P connectivity, and this SHOULD be the
           default behavior.

       B.  Unidirectional 1+1 protection for P2MP connectivity MUST be
           supported.

       C.  Unidirectional 1+1 protection for P2P connectivity is NOT
           REQUIRED.

   56  MPLS-TP MUST support 1:n Protection (including 1:1 protection).

       A.  MPLS-TP 1:n support MUST include bidirectional protection
           switching for P2P connectivity, and this SHOULD be the
           default behavior.

       B.  Unidirectional 1:n protection for P2MP connectivity MUST be
           supported.





Niven-Jenkins, et al.     Expires July 7, 2009                 [Page 15]


Internet-Draft            MPLS-TP Requirements              January 2009


       C.  Unidirectional 1:n protection for P2P connectivity is NOT
           REQUIRED.

       D.  The action of protection switching MUST NOT cause user data
           to loop.  Backtracking is allowed.

   57  MPLS-TP SHOULD support extra traffic carried on 1:n protection
       resources when protection is not in use.

2.8.1.2.  Restoration

   58  The restoration LSP MUST be able to share resources with the LSP
       being replaced (sometimes known as soft rerouting).

   59  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).

   60  Preemption priority MUST be supported to allow restoration to
       displace other transport paths in the event of resource
       constraint.

   61  Recovery mechanisms MUST be bidirectional.

2.8.1.3.  Sharing of protection resources

   62  MPLS-TP SHOULD support 1:n (including 1:1) shared mesh
       restoration.

   63  MPLS-TP MUST support the sharing of protection bandwidth by
       allowing best effort traffic.

   64  MPLS-TP MUST support the definition of shared protection groups
       to allow the coordination of protection actions resulting from
       triggers caused by events at different locations in the network.

   65  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.8.1.4.  Reversion

   66  MPLS-TP protection mechanisms MUST support revertive and non-
       revertive behavior.  Reversion MUST be the default behavior.






Niven-Jenkins, et al.     Expires July 7, 2009                 [Page 16]


Internet-Draft            MPLS-TP Requirements              January 2009


   67  MPLS-TP restoration mechanisms MAY support revertive and non-
       revertive behavior.

2.8.2.  Triggers for protection, restoration, and reversion

   Recovery actions may be triggered from different places as follows:

   68  MPLS-TP MUST support physical layer fault indication triggers.

   69  MPLS-TP MUST support OAM-based triggers.

   70  MPLS-TP MUST support management plane triggers (e.g., forced
       switch, etc.).

   71  There MUST be a mechanism to allow administrative recovery
       actions to be distinguished from recovery actions initiated by
       other triggers.

   72  Where a control plane is present, MPLS-TP SHOULD support control
       plane triggers.

2.8.3.  Management plane operation of protection and restoration

   All functions described here are for control by the operator.

   73  It MUST be possible to configure of protection paths and
       protection-to-working path relationships (sometimes known as
       protection groups).

   74  There MUST be support for pre-calculation of recovery paths.

   75  There MUST be support for pre-provisioning of recovery paths.

   76  The following administrative control MUST be supported:

       A.  lockout

       B.  forced switchover

       C.  manual switchover

       D.  simulated fault

   77  There MUST be support for the configuration of timers used for
       recovery operation.






Niven-Jenkins, et al.     Expires July 7, 2009                 [Page 17]


Internet-Draft            MPLS-TP Requirements              January 2009


   78  Restoration resources MAY be pre-planned and selected a priori,
       or computed after failure occurrence.

   79  When preemption is supported for recovery purposes, it MUST be
       possible for the operator to configure it.

   80  The management plane MUST provide indications of protection
       events and triggers.

   81  The management plane MUST allow the current protection status of
       all transport paths to be determined.

2.8.4.  Control plane and in-band OAM operation of recovery

   82  The MPLS-TP control plane (which is not mandatory in an MPLS-TP
       implementation) MUST support:

       A.  establishment and maintenance of all recovery entities and
           functions

       B.  signaling of administrative control

       C.  protection state coordination (PSC)

   83  In-band OAM MAY be used for:

       A.  signaling of administrative control

       B.  protection state coordination

2.8.5.  Topology-specific recovery mechanisms

   84  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.

   Note that topology-specific recovery mechanisms are subject to the
   development of requirements using the normal IETF process.

2.8.5.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.



Niven-Jenkins, et al.     Expires July 7, 2009                 [Page 18]


Internet-Draft            MPLS-TP Requirements              January 2009


   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 MEs that are needed to trigger the
       recovery operation - less than are required by other recovery
       mechanisms.

   b.  Minimize the number of elements of recovery in the ring - less
       than are required by other recovery mechanisms.

   c.  Minimize the number of labels required for the protection paths
       across the ring - less than are required by other recovery
       mechanisms.

   d.  Minimize the amount of management plane transactions during a
       maintenance operation (e.g., ring upgrade) - less than are
       required by other recovery mechanisms.

   It may be observed that this list is fully compatible with the
   generic requirements expressed above, and that no requirements that
   are specific to ring topologies have been identified.  [Editors'
   Note: This statement is to be confirmed at the end of the work and
   may be removed if it does not hold.]

   In the list of requirements below, those requirements that are
   generic are marked "[G]"; those that are Ring-specific are marked
   "[R]".  [Editors' Note: Still need to mark up the requirements below
   as [R] and [G].]

   85  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.

   86  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.





Niven-Jenkins, et al.     Expires July 7, 2009                 [Page 19]


Internet-Draft            MPLS-TP Requirements              January 2009


   87  MPLS-TP recovery in a ring MUST protect unidirectional and
       bidirectional P2P transport paths.

   88  MPLS-TP recovery in a ring MUST protect unidirectional P2MP
       transport paths.

   89  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 nodes ring with less than 1200 km of fiber.  This is
       NOT REQUIRED when extra traffic is present.

   [Editor note: the opinion of some people in the T103 room in Geneva
   is that support for extra traffic is NOT REQUIRED in ring topologies.
   It may be further NOT REQUIRED in any topology.  This is for further
   discussion especially with respect to G.8131.]

   90   The protection switching time in a ring MUST be independent of
        the number of LSPs crossing the ring.

   91   Recovery actions in a ring MUST be data plane functions
        triggered by different elements of control.  The triggers are
        configured by management or control planes and are subject to
        configurable policy.

   92   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)

   93   MPLS-TP recovery in ring topologies MAY support multiple
        failures without reconfiguring the protection actions.

   94   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.

   95   MPLS-TP Recovery mechanisms applicable to a ring MUST be equally
        applicable in physical and logical rings.





Niven-Jenkins, et al.     Expires July 7, 2009                 [Page 20]


Internet-Draft            MPLS-TP Requirements              January 2009


   96   Recovery techniques in a ring SHOULD be identical to those in
        general networks to simplify implementation.  However, this MUST
        NOT override any other requirement.

   97   Recovery techniques in logical and physical rings SHOULD be
        identical to simplify implementation and operation.  However,
        this MUST NOT override any other requirement.

   98   The default recovery scheme in a ring MUST be bidirectional
        recovery in order to simplify the recovery operation.

   99   The recovery mechanism in a ring MUST support revertive
        switching, which MUST be the default behaviour.  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.

   100  The recovery mechanisms in a ring MUST support ways to allow
        administrative protection switching, to be distinguished from
        protection switching initiated by other triggers.

   101  It MUST be possible to disable protection mechanisms on selected
        links in a ring (depending on operator's need).

   [Editor note: This requirement was originated from ITU-T Q9/15 and
   needs further clarification.  If it means that a lockout is required
   for use on specific spans, then this is already covered by a general
   requirement, and this requirement could be deleted or rewritten for
   clarity.  On the other hand, there may be another meaning in which
   case the requirement needs to be rewritten.]

   102  MPLS-TP recovery mechanisms in a ring MUST include a mechanism
        to allow an implementation to handle coexisting requests (i.e.,
        multiple requests - not necessarily arriving simultaneously) for
        protection switching based on priority.

   103  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.

   104  MPLS-TP MUST support the sharing of protection bandwidth in a
        ring by allowing best effort traffic.

   105  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.





Niven-Jenkins, et al.     Expires July 7, 2009                 [Page 21]


Internet-Draft            MPLS-TP Requirements              January 2009


   106  MUST support the coordination of triggers caused by events at
        different locations in a ring.  Note that this is the ring
        equivalent of the definition of shared protection groups.

2.9.  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:

   107  Support for differentiated services and different traffic types
        with traffic class separation associated with different traffic.

   108  Prioritization of critical services.

   109  Enabling the provisioning and the guarantee of Service Level
        Specifications (SLS), with support for hard and relative end-to-
        end bandwidth guaranteed.

   110  Support of services, which are sensitive to jitter and delay.

   111  Guarantee of fair access, within a particular class, to shared
        resources.

   112  Guaranteed resources for in-band control and management plane
        traffic regardless of the amount of data plane traffic.

   113  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.

   [Editors' Note: Should we refer here to the requirements specified in
   RFC 2702?]

2.10.  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 the Security Framework for MPLS & GMPLS Networks
   [I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework].


3.  IANA Considerations

   This document makes no request of IANA.




Niven-Jenkins, et al.     Expires July 7, 2009                 [Page 22]


Internet-Draft            MPLS-TP Requirements              January 2009


   Note to RFC Editor: this section may be removed on publication as an
   RFC.


4.  Security Considerations

   For a description of the security threats relevant in the context of
   MPLS and GMPLS and the defensive techniques to combat those threats
   see the Security Framework for MPLS & GMPLS Networks
   [I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework].


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 MPLS Transport Profile.

   The authors would also like to thank Loa Andersson, Lou Berger, Italo
   Busi, John Drake, Adrian Farrel, Neil Harrison, Wataru Imajuku,
   Julien Meuric, Tom Nadeau, Hiroshi Ohta and Tomonori Takeda 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.


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.

   [I-D.gray-mpls-tp-nm-req]
              Lam, H., Mansfield, S., and E. Gray, "MPLS TP Network
              Management Requirements", draft-gray-mpls-tp-nm-req-01
              (work in progress), July 2008.

   [I-D.vigoureux-mpls-tp-oam-requirements]
              Vigoureux, M., Ward, D., and M. Betts, "Requirements for
              OAM in MPLS Transport Networks",
              draft-vigoureux-mpls-tp-oam-requirements-00 (work in
              progress), July 2008.



Niven-Jenkins, et al.     Expires July 7, 2009                 [Page 23]


Internet-Draft            MPLS-TP Requirements              January 2009


6.2.  Informative References

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC3473]  Berger, L., "Multiprotocol Label Switching Architecture",
              RFC 3473, January 2003.

   [RFC3985]  Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
              Edge (PWE3) Architecture", RFC 3985, March 2005.

   [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.

   [RFC4427]  Mannie, E. and D. Papadimitriou, "Recovery (Protection and
              Restoration) Terminology for Generalized Multi-Protocol
              Label Switching (GMPLS)", RFC 4427, March 2006.

   [RFC5212]  Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
              M., and D. Brungard, "Requirements for GMPLS-Based Multi-
              Region and Multi-Layer Networks (MRN/MLN)", RFC 5212,
              July 2008.

   [RFC5331]  Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
              Label Assignment and Context-Specific Label Space",
              RFC 5331, August 2008.

   [I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework]
              Fang, L. and M. Behringer, "Security Framework for MPLS
              and GMPLS Networks",
              draft-ietf-mpls-mpls-and-gmpls-security-framework-03 (work
              in progress), July 2008.

   [ITU.Y2611.2006]
              International Telecommunications Union, "High-level
              architecture of future packet-based networks", ITU-
              T Recommendation Y.2611, December 2006.

   [ITU.Y1401.2008]
              International Telecommunications Union, "Principles of
              interworking", ITU-T Recommendation Y.1401, February 2008.




Niven-Jenkins, et al.     Expires July 7, 2009                 [Page 24]


Internet-Draft            MPLS-TP Requirements              January 2009


   [ITU.G805.2000]
              International Telecommunications Union, "Generic
              functional architecture of transport networks", ITU-
              T Recommendation G.805, March 2000.


Authors' Addresses

   Ben Niven-Jenkins (editor)
   BT
   208 Callisto House, 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)
   Nortel Networks
   3500 Carling Avenue
   Ottawa, Ontario  K2H 8E9
   Canada

   Email: betts01@nortel.com


   Nurit Sprecher
   Nokia Siemens Networks
   3 Hanagar St. Neve Ne'eman B
   Hod Hasharon,   45241
   Israel

   Email: nurit.sprecher@nsn.com









Niven-Jenkins, et al.     Expires July 7, 2009                 [Page 25]


Internet-Draft            MPLS-TP Requirements              January 2009


   Satoshi Ueno
   NTT


   Email: satoshi.ueno@ntt.com














































Niven-Jenkins, et al.     Expires July 7, 2009                 [Page 26]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/