[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 draft-ietf-mpls-tp-requirements

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


                          MPLS-TP Requirements
               draft-jenkins-mpls-mpls-tp-requirements-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 January 4, 2009.

Abstract

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



Niven-Jenkins, et al.    Expires January 4, 2009                [Page 1]


Internet-Draft            MPLS-TP Requirements                 July 2008


   as defined by IETF and packet transport networks as defined by ITU-T.

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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Transport network overview . . . . . . . . . . . . . . . .  5
   2.  MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  General requirements . . . . . . . . . . . . . . . . . . .  6
     2.2.  Layering requirements  . . . . . . . . . . . . . . . . . .  7
     2.3.  Data plane requirements  . . . . . . . . . . . . . . . . .  8
     2.4.  Control plane requirements . . . . . . . . . . . . . . . .  9
     2.5.  Network Management (NM) requirements . . . . . . . . . . . 11
     2.6.  OAM requirements . . . . . . . . . . . . . . . . . . . . . 12
     2.7.  Network performance management (PM) requirements . . . . . 12
     2.8.  Protection & Survivability requirements  . . . . . . . . . 12
     2.9.  QoS requirements . . . . . . . . . . . . . . . . . . . . . 15
     2.10. Security requirements  . . . . . . . . . . . . . . . . . . 16
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   6.  Informative References . . . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 19




















Niven-Jenkins, et al.    Expires January 4, 2009                [Page 2]


Internet-Draft            MPLS-TP Requirements                 July 2008


1.  Introduction

   For many years, SONET/SDH has provided service providers with a high
   benchmark for reliability and operational simplicity.  With the
   accelerating growth of packet-based services (such as Ethernet, VoIP,
   L2/L3 VPN, IPTV, RAN backhauling, etc.), service providers are in
   need of capabilities to efficiently support packet-based services 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 both Capital
   Expenditure (CAPEX) and Operational Expense (OPEX) should be minimal.

   Carriers are considering migrating to packet transport networks in
   order to reduce their costs and to improve their ability to support
   services with guaranteed SLAs.  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.

   Service providers 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 (OSS based) or dynamic (control plane)
   provisioning of deterministic, protected and secured services and
   their associated resources as well as alternative control-plane
   options.

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



Niven-Jenkins, et al.    Expires January 4, 2009                [Page 3]


Internet-Draft            MPLS-TP Requirements                 July 2008


   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 easily 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 for a MPLS Transport Profile
   (MPLS-TP).  This document is a product of a joint ITU-IETF effort to
   include a 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.

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

1.1.  Terminology

   Section: A section is a network segment between two LSRs that are
   immediately adjacent at the MPLS-TP layer.

   Service layer: A network layer 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).

   Tandem Connection: A tandem connection corresponds to a segment of a
   path.  This may be either a segment of an LSP (i.e. a sub-path), or
   one or more segment(s) of a PW.

   Transport path: A connection as define in G.805 [ITU.G805.2000].

   Transport path layer: A network layer which provides point-to-point
   or point-to-multipoint transport paths which are used to carry
   aggregates of the network service layer.

   Transmission media layer: A network layer 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.




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


Internet-Draft            MPLS-TP Requirements                 July 2008


1.2.  Transport network overview

   The connectivity service is the basic service provided by a transport
   network.  The purpose of a transport network is to transparently
   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 connectivity services offered to customers
   are aggregated into large transport paths with long-holding times,
   which enable 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.

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

   3.  Client signals are completely encapsulated and isolated from each
       other.  This also allows complete isolation of customer traffic
       from carrier operations.

   An important attribute of a transport network is its ability to
   function independently from both its client and server (transmission
   media) layer networks.  It should be capable of transmitting over any
   media.  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.

   Client signals are first transparently encapsulated.  These
   encapsulated client signals are then aggregated 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
   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



Niven-Jenkins, et al.    Expires January 4, 2009                [Page 5]


Internet-Draft            MPLS-TP Requirements                 July 2008


   monitored; individual client signals are monitored at the network
   boundary in the client layer network.

   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

2.1.  General requirements

   o  MPLS-TP MUST offer as much commonality as possible with the MPLS
      data plane as defined by 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.

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

   o  Mechanisms and capabilities MUST be able to interoperate with
      existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and
      data planes where appropriate.

   o  MPLS-TP MUST support a connection-oriented packet switching
      paradigm with traffic engineering capabilities that allow
      deterministic control of the use of network resources.

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

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

   o  MPLS-TP MUST support point to point (P2P) or point to multipoint
      (P2MP) transport paths.

   o  MPLS-TP MUST support static provisioning of transport paths via an
      NMS/OSS (i.e. via the management plane).

   o  Static provisioning MUST NOT depend on routing or signaling
      protocols (e.g.  GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.).

   o  MPLS-TP MUST support the capability for network operation
      (including OAM) via an NMS/OSS (without the use of any control
      plane protocols).



Niven-Jenkins, et al.    Expires January 4, 2009                [Page 6]


Internet-Draft            MPLS-TP Requirements                 July 2008


   o  MPLS-TP MUST support dynamic provisioning of transport paths via a
      control plane.

   o  The MPLS-TP data plane MUST be capable of functioning
      independently of the control or management plane used to operate
      the MPLS-TP layer network.  That is the MPLS-TP data plane
      operation MUST continue to operate normally if the management
      plane or control plane that configured the transport paths fails.

   o  MPLS-TP MUST support any network topology and be able to support
      increasing bandwidth demands, topology, number of customers or
      number of services incrementally.

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

2.2.  Layering requirements

   o  An MPLS-TP network MUST operate in a multiple layer network
      environment consisting of independent service, transport path and
      transmission media layers.

   MPLS-TP may be used as the service layer (for P2P and P2MP services)
   and/or as the transport path layer within a packet transport network.

   o  An MPLS-TP layer network MUST support the transparent transport of
      MPLS-TP and non MPLS-TP client layer networks.

   o  An MPLS-TP layer network MUST be able to be transparently carried
      over MPLS-TP and non MPLS-TP server layer networks (such as
      Ethernet, OTN, etc.)

   o  It MUST be possible to operate the MPLS-TP layer network
      independently of other layer networks (either MPLS-TP or non
      MPLS-TP).

   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, and require the capability for
   autonomous network operations.

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








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


Internet-Draft            MPLS-TP Requirements                 July 2008


2.3.  Data plane requirements

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

   o  A label in a particular section MUST uniquely identify the
      transport path.

   o  A transport path's source MUST be identifiable at its destination.

   Transport paths can be aggregated into trunks by pushing and de-
   aggregated by popping labels.  MPLS-TP labels are swapped within a
   transport path in a layer network instance when the traffic is
   forwarded from one MPLS-TP link to another MPLS-TP link.

   o  Labeling MUST make use of the MPLS label and label stack entry as
      defined in RFC3032.

   o  It MUST be possible to operate and configure the MPLS-TP data
      (transport) plane without any IP functionality.

   o  MPLS-TP MUST support both unidirectional and bi-directional point-
      to-point transport paths.

   o  The forward and backward directions of a bi-directional transport
      path MUST be capable of following the same path within the MPLS-TP
      network.

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

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

   o  MPLS-TP transport paths MUST NOT perform merging in a way that
      prevents the unique identification of the source at the
      destination (e.g. no use of LDP mp2p signaling in order to avoid
      losing LSP head-end information, no use of PHP, etc).

   o  MPLS-TP MUST support transport paths through a single domain.

   o  MPLS-TP MUST support transport paths through multiple domains.

   o  MPLS-TP MUST be able to accommodate new traffic types.

   o  MPLS-TP SHOULD support mechanisms to minimize traffic impact
      during network reconfiguration.



Niven-Jenkins, et al.    Expires January 4, 2009                [Page 8]


Internet-Draft            MPLS-TP Requirements                 July 2008


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

   o  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

   o  A distributed control plane MAY be supported to enable fast,
      dynamic and reliable service provisioning in multi-vendor and
      multi-domain environments using standardized protocols that
      guarantee interoperability.

   o  If a control plane is used for configuration of MPLS-TP transport
      paths then:

      *  Failure of the control plane MUST NOT impact the MPLS-TP data
         plane.

      *  Recovery of the control plane MUST NOT impact the MPLS-TP data
         plane any more than is necessary to re-establish the control
         plane.

      *  It MUST support the setup, modification, and release of MPLS-TP
         transport paths and protection paths.

      *  It MUST support mechanisms to provide traffic engineering,
         constraint-based routing and explicit path control.

      *  It MUST provide mechanisms to address QoS and performance
         requirements (such as throughput, delay, packet loss, etc.)
         while utilizing network resources efficiently and reliably.

   o  MPLS-TP SHOULD support off-path (out-of-band) control and
      management planes.

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

   o  The control plane SHOULD facilitate the implementation of the
      service by providing end-to-end seamless connectivity and service
      assurance.

   o  The MPLS-TP control plane MUST support establishing all the
      connectivity patterns defined for the MPLS-TP data plane (e.g.,
      uni-directional and bidirectional P2P, uni-directional P2MP, etc.)



Niven-Jenkins, et al.    Expires January 4, 2009                [Page 9]


Internet-Draft            MPLS-TP Requirements                 July 2008


      including configuration of protection functions and any associated
      maintenance functions.

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

   o  An MPLS-TP control plane MUST support topology hiding and address
      independence between domains.

   o  At the boundary of a domain an MPLS-TP control plane MUST support
      unique control plane identifiers or addresses identifying boundary
      points to be interconnected.

   o  At the boundary of a domain an MPLS-TP control plane MUST support
      group control plane identifiers or addresses identifying sets of
      boundary points to be interconnected.

   o  MPLS-TP data plane layer network access points (or connection
      points that proxy for access points) SHOULD be able to be assigned
      control plane identifiers which are available to clients to
      identify endpoints in call or connection requests.

   o  An MPLS-TP control plane MUST support translation between
      externally visible endpoint control plane identifiers and internal
      network addresses.

   o  An MPLS-TP control plane MUST support constraint-based route
      calculation.

   o  An MPLS-TP control plane MUST support provisioning and application
      of routing constraint policies.

   o  An MPLS-TP control plane MUST support pre-provisioned path
      protection.

   In some situations it is impractical to expect acceptable recovery
   performance to be achieved using dynamic recalculation of transport
   path routes.  For this reason, it is necessary to allow for pre-
   planning of protection routes for selected transport paths.

   o  The MPLS-TP control plane MUST support fast restoration.

   o  An MPLS-TP control plane MUST scale gracefully to support a large
      number of transport paths.





Niven-Jenkins, et al.    Expires January 4, 2009               [Page 10]


Internet-Draft            MPLS-TP Requirements                 July 2008


   o  An MPLS-TP control plane MUST clearly distinguish resources
      belonging to the MPLS-TP layer network from those in other layer
      networks that may also be under control plane control.

   o  An MPLS-TP control plane MUST support the independent unique
      identification of control plane elements as needed to support
      interoperability.

   o  It MUST be possible to identify and provision these elements
      independently, in order to reorganize the control plane components
      without impacting the data plane services and vice-versa.

   Architecturally distinct elements in a control plane include: nodes
   and links, control plane functional components, protocol controllers,
   etc.

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

   o  An MPLS-TP control plane MUST support mechanisms for partitioning
      the network under control into separate peer or hierarchical
      control domains.

   o  To enable the deployment of a unified control plane aimed at
      controlling the set of transport technologies used in a transport
      network, the MPLS-TP control plane MUST also be applicable to
      other transport layer networks and provide common operations
      across multiple layers.  In order to maintain independence between
      MPLS-TP and its respective client and server layer networks, the
      capability to support separate control plane instances SHOULD be
      possible for control of transport multilayer networks.

   o  MPLS-TP SHOULD detect and recover from control plane failures and
      degradations using graceful operations.

2.5.  Network Management (NM) requirements

   o  MPLS-TP MUST operate under a common operation, control and
      management paradigm with respect to other transport technologies
      (e.g.  SDH, OTN or WDM).

   o  An MPLS-TP network MUST be able to be operated with a centralized
      NMS system.

   o  An MPLS-TP network SHOULD be able to be operated by a centralized
      NMS system with the support of a distributed control plane.





Niven-Jenkins, et al.    Expires January 4, 2009               [Page 11]


Internet-Draft            MPLS-TP Requirements                 July 2008


   o  The MPLS-TP management plane MUST be able to operate independently
      of any particular client or server layer management plane.

   o  The MPLS-TP management plane 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.

   For the complete set of requirements related to NM functionality for
   MPLS-TP, see the MPLS-TP NM requirements document [REF].

2.6.  OAM requirements

   o  MPLS-TP SHOULD provide a comprehensive set of capabilities (that
      are independent of and agnostic to the transmitted client
      services) to support fault management (e.g. fault detection and
      localization), performance monitoring (e.g. signal quality
      measurement) of the MPLS-TP network and the services) and
      protection switching.

   o  OAM mechanisms SHOULD detect and trigger recovery actions in case
      of facility and equipment failures and performance degradations
      according to the requirements of the service.

   o  MPLS-TP OAM and data MUST share the same fate.

   o  MPLS-TP OAM MUST be able to operate without IP functionality and
      without relying on control and/or management planes.  When MPLS-TP
      is run with IP functionality, all existing IP-MPLS OAM
      functionality, e.g.  LSP-Ping, BFD and VCCV, MUST be able to
      operate seamlessly.

   For the complete set of requirements related to OAM functionality for
   MPLS-TP, see the MPLS-TP OAM requirements document [REF].

2.7.  Network performance management (PM) requirements

   For the complete set of requirements related to PM functionality for
   MPLS-TP, see the MPLS-TP OAM requirements document [REF].

2.8.  Protection & Survivability requirements

   Network survivability plays a critical factor 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.



Niven-Jenkins, et al.    Expires January 4, 2009               [Page 12]


Internet-Draft            MPLS-TP Requirements                 July 2008


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

   o  MPLS-TP MUST support transport network style protection switching
      mechanisms (tandem network connection protection, LSP protection
      and PW protection) to provide the appropriate recovery time
      required to maintain customer SLAs when potentially thousands of
      services are simultaneously affected by a single failure.

   o  MPLS-TP recovery mechanisms SHOULD be applicable at various levels
      throughout the network including support for span, tandem
      connection and end-to-end recovery.

   o  MPLS-TP MUST support network restoration mechanisms controlled by
      a distributed control plane and MUST support network restoration
      mechanisms controlled by a management plane.

      *  The restoration resources MAY be pre-planned and selected a
         priori, or computed after failure occurrence.

      *  MPLS-TP MAY support shared-mesh restoration.

      *  MPLS-TP SHOULD support soft LSP restoration.

      *  MPLS-TP MAY support hard LSP restoration.

      *  The restoration mechanism MUST be applicable to any topology.

      *  Restoration priority MAY be implemented to 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).  Preemption priority MAY be
         used in the event that not all transport paths can be restored,
         in which case transport paths with lower preemption priority
         should be released.  When preemption is supported, its use MUST
         be operator configurable.

      *  The restoration mechanism SHOULD operate in synergy with other
         transport network technologies (SDH, OTN, WDM).

   o  MPLS-TP MUST support data plane driven protection mechanisms
      (without any dependency on a control plane or IP protocols) to
      enable fast recovery from failure.

   o  If protection is supported then:

      *  MPLS-TP protection mechanisms SHOULD be applied to LSPs and
         PWs.



Niven-Jenkins, et al.    Expires January 4, 2009               [Page 13]


Internet-Draft            MPLS-TP Requirements                 July 2008


      *  MPLS-TP MUST support mechanisms that rapidly detect, locate,
         notify and remedy network faults.

      *  MPLS-TP MAY support 1:1 bidirectional protection switching.  If
         bi-directional 1:1 protection switching is activated then the
         protection state of both ends of the protected entity MUST be
         synchronized.

      *  MPLS-TP MAY support 1+1 unidirectional protection switching.

      *  MPLS-TP protection mechanisms MUST be applicable to point-to-
         point and SHOULD be applicable to point-to-multipoint transport
         paths.

      *  Protection ratio MUST be of 100%, i.e. 100% of impaired working
         traffic MUST be protected for a failure on the working path.
         Additionally:

         +  The QoS objectives defined by the operator MUST also be met
            along the protection path.

         +  In the case of 1:1 protection mechanisms, the bandwidth
            reserved for the protection path MAY be available for other
            traffic when the working path is operational.

      *  Operator requests for manual control of protection switching
         such as clear, lockout of protection, forced-switch and manual-
         switch commands MUST be supported.  Prioritized protection
         between Signal Fail (SF), Signal Degradation (SD) and operator
         switch requests MUST be supported.

      *  MPLS-TP protection mechanisms MUST support revertive and non-
         revertive behaviour.

      *  MPLS-TP protection switching mechanisms MUST prevent frequent
         operation of the protection switch due to an intermittent
         defect.

      *  MPLS-TP protection mechanisms MUST ensure co-ordination of
         timing of protection switches at multiple layers to avoid races
         and to allow the protection switching mechanism of the server
         layer to fix the problem before switching at the MPLS-TP layer.

      *  MPLS-TP MAY support mechanisms that are optimized for specific
         network topologies (Ring, Mesh) in order to handle protection
         switching in an efficient manner.





Niven-Jenkins, et al.    Expires January 4, 2009               [Page 14]


Internet-Draft            MPLS-TP Requirements                 July 2008


2.9.  QoS requirements

   Service providers require advanced traffic management capabilities to
   enforce and guarantee the QoS parameters of customers' SLAs.

   Quality of service mechanisms are required to ensure:

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

   o  Prioritization of critical services.

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

   o  Controlled jitter and delay.

   o  Guarantee of fair access to shared resources in an MPLS-TP
      network.

   o  Resources for control and management plane packets so that data
      plane traffic, regardless of the amount, will not cause control
      and management functions to become inoperative.

   MPLS-TP:

   o  MUST be able to deliver the same degree of QoS that has been
      delivered by SDH/SONET systems.

   o  MUST support a method to offer packet loss objectives comparable
      to those in TDM transport networks (only due to bit errors).

   o  SHOULD support transport and QoS mechanisms that can deliver
      statistical multiplexing gain.  Packets exceeding the agreed
      traffic profile may be marked or discarded by the traffic
      conditioning at the ingress of the MPLS-TP network.

   o  MUST support transport bandwidth allocation to any granularity
      without any restrictions based on a circuit-switched multiplexing
      hierarchy.  This will provide service providers with the
      capability to efficiently support service demands over the MPLS-TP
      network.

   [Should we refer here to the requirements specified in RFC 2702?]






Niven-Jenkins, et al.    Expires January 4, 2009               [Page 15]


Internet-Draft            MPLS-TP Requirements                 July 2008


2.10.  Security requirements

   o  MPLS-TP MUST ensure that the network and services are secured.

   o  Traffic flows from different users MUST NOT be intermingled, but
      if this does occur then this MUST be detectable and the
      appropriate consequent actions taken.

   o  MPLS-TP MUST ensure the separation of customer (client) and
      provider (server and peer network) addressing and other
      information.

   o  MPLS-TP MUST ensure that the control and management planes as well
      as OAM traffic are secure from external attack.

   o  MPLS-TP MUST provide mechanisms to ensure that the MPLS-TP network
      remains secure and stable under situations of extreme stress.

   Examples of attacks and situations of extreme stress include (but are
   not limited to) classical security attacks (e.g., hijacking, privacy,
   non-repudiation, etc.) and attacks on network availability (e.g.,
   denial of service (DoS) attacks).


3.  IANA Considerations

   This document makes no request of IANA.

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


4.  Security Considerations

   This document does not by itself raise any particular security
   considerations.


5.  Acknowledgements

   The authors would like to thank all members of the teams (the Joint
   Working Team, the MPLS Interoperability Design Team in IETF and the
   T-MPLS Ad Hoc Group in ITU-T) involved in the definition and
   specification of MPLS Transport Profile.

   The authors would also like to thank Italo Busi, Neil Harrison,
   Julien Meuric, Tom Nadeau, Hiroshi Ohta and Tomonori Takeda for their
   comments and enhancements to the text.



Niven-Jenkins, et al.    Expires January 4, 2009               [Page 16]


Internet-Draft            MPLS-TP Requirements                 July 2008


6.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

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

   [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








Niven-Jenkins, et al.    Expires January 4, 2009               [Page 17]


Internet-Draft            MPLS-TP Requirements                 July 2008


   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 January 4, 2009               [Page 18]


Internet-Draft            MPLS-TP Requirements                 July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Niven-Jenkins, et al.    Expires January 4, 2009               [Page 19]


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