Subject: [Mpls-interop] Emailing: draft-blb-mpls-tp-framework-01-darft-for comment.txt

From: Huub van Helvoort <[email-masked]>
Date: Fri, 17 Oct 2008 15:30:15 +0200

FYI:

The message is ready to be sent with the following file or link attachments:

draft-blb-mpls-tp-framework-01-darft-for comment.txt

Regards, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

MPLS                                                       M. Bocci, Ed.
Internet-Draft                                            Alcatel-Lucent
Intended status: Informational                            S. Bryant, Ed.
Expires: March 24, 2009                                    Cisco Systems
                                                        M. Lasserre, Ed.
                                                          Alcatel-Lucent
                                                      September 20, 2008

               A Framework for MPLS in Transport Networks
                     draft-blb-mpls-tp-framework-01

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 March 24, 2009.

Abstract

   This document specifies an archiectectural framework for the
   application of MPLS in transport networks.  It describes a profile of
   MPLS that enables operational models typical in transport networks
   networks, while providing additional OAM, survivability and other
   maintenance functions not currently supported by MPLS.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Bocci, et al.            Expires March 24, 2009                 [Page 1]

Internet-Draft              MPLS TP Framework             September 2008

   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [1].

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Motivation and Background  . . . . . . . . . . . . . . . .  3
     1.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Summary of Requirements  . . . . . . . . . . . . . . . . . . .  4
   3.  Transport Profile Overview . . . . . . . . . . . . . . . . . .  4
     3.1.  Architecture . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Generic-ACH Label (GAL)  . . . . . . . . . . . . . . . . .  5
     3.3.  Generic Associated Channel Header(GE-ACH)  . . . . . . . .  6
     3.4.  Forwarding . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.5.  Operations and Management (OAM)  . . . . . . . . . . . . . 10
     3.6.  Control Plane  . . . . . . . . . . . . . . . . . . . . . . 11
       3.6.1.  PW Control Plane . . . . . . . . . . . . . . . . . . . 12
       3.6.2.  LSP Control Plane  . . . . . . . . . . . . . . . . . . 12
       3.6.3.  Static Operation of LSP  . . . . . . . . . . . . . . . 13
     3.7.  Survivability  . . . . . . . . . . . . . . . . . . . . . . 13
     3.8.  Network Management . . . . . . . . . . . . . . . . . . . . 14
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 18

Bocci, et al.            Expires March 24, 2009                 [Page 2]

Internet-Draft              MPLS TP Framework             September 2008

1.  Introduction

1.1.  Motivation and Background

   Existing transport technologies (e.g.  SDH, ATM, OTN) have been
   designed with specific characteristics:

   o  Strictly connection oriented

      *  Long-lived connections

      *  Manually provisioned connections

   o  High level of protection and availability

   o  Quality of service

   o  Extended OAM capabilities

   The development of MPLS-TP has been driven by the carriers needing to
   evolve SONET/SDH networks to support packet based services and
   networks, and the desire to take advantage of the flexibility and
   cost benefits of packet switching technology.  There are two
   objectives one is to enable MPLS to be deployed in a transport
   network and operated in a similar manner to existing transport
   technologies.  The other is to enable MPLS to support packet
   transport services with a similar degree of predictability to that
   found in existing transport networks.

   MPLS-TP defines a profile of MPLS targeted at transport applications.
   This profile specifies the specific MPLS characteristics and
   extensions required to meet transport requirements.  An equipment
   conforming to MPLS-TP must support this profile.  An MPLS-TP
   conformant equipment MAY support additional MPLS features.  A carrier
   may deploy some of those additional features in the transport layer
   of their network if they find them to be beneficial.

1.2.  Scope

   This document specifies the high-level functionality of MPLS-TP
   required for adding transport-oriented capabilities to MPLS

Bocci, et al.            Expires March 24, 2009                 [Page 3]

Internet-Draft              MPLS TP Framework             September 2008

1.3.  Terminology

   Term Definition
   ---- -------------------
   LSP  Label Switched Path

2.  Summary of Requirements

   This section summarizes the requirements for the MPLS transport
   profile.  Such requirements are specified in more detail in [21],
   [22], and [23].

   Solutions MUST NOT modify the MPLS forwarding architecture.

   Solutions MUST be based on existing pseudowire and LSP constructs.

   New mechanisms and capabilities added to support transport networks
   must be able to interoperate with existing MPLS and pseudowire
   control and forwarding planes.

   Point to point LSPs MAY be unidirectional or bi-directional.  It MUST
   be possible to construct congruent Bi-directional LSPs.  Point to
   multipoint LSPs are unidirectional.

   MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR.  It is
   possible to detect that a merged LSP has been created.

   It MUST be possible to forward packets solely based on switching the
   MPLS or PW label.  It MUST also be possible to establish and maintain
   LSPs and/or pseudowires both in the absence or presence of a dynamic
   control plane.  When static provisioning is used, there MUST be no
   dependency on dynamic routing or signaling.

   OAM, protection and forwarding of data packets MUST be able to
   operate without IP forwarding support.

   It MUST be possible to monitor LSPs and pseudowires through the use
   of OAM in the absence of control plane or routing functions.  In this
   case information gained from the OAM functions is used to initiate
   path recovery actions at either the PW or LSP layers.

3.  Transport Profile Overview

3.1.  Architecture

   The architecture for a transport profile of MPLS (MPLS-TP) is based
   on the MPLS-TE [2], pseudowire [3], and multi-segment pseudowire [4]
   architectures

Bocci, et al.            Expires March 24, 2009                 [Page 4]

Internet-Draft              MPLS TP Framework             September 2008

   The MPLS-TP forwarding plane is a profile of the MPLS LSP PW, and
   MS-PW forwarding architecture as detailed in section Section 3.4.

   Editor's Note we need to import some diagrams from the JWT report
   here

   MPLS-TP supports a comprehensive set of OAM and protection-switching
   capabilities for packet transport applications, with equivalent
   capabilities to existing SONET/SDH OAM and protection, as described
   in sections Section 3.5 and Section 3.7.  MPLS-TP may be operated
   with centralized Network Management Systems with or without the
   support of a distributed control plane as described in sections
   Section 3.6 and Section 3.8.

   MPLS-TP defines mechanisms to differentiate specific packets (e.g.
   OAM, APS, MCC or SCC) from those carrying user data packets on the
   same LSP.  These mechanisms are described in sections Section 3.2and
   Section 3.3.

3.2.  Generic-ACH Label (GAL)

   For correct operation of the OAM it is important that the OAM packets
   fate share with the data packets.  In addition in MPSL-TP it is
   necessary to indicate that the payload carried over an LSP in not
   user data.  For example the packet may contain SCC, or APS data.  The
   presence of the ACH indicates that the packet is not user data and
   identifies its type.

   PWE3 uses the first nibble of the control word to provide the initial
   discrimination between data packets and "other" packets [5].  When
   the first nibble of a PWE3 packet has a value of one, then the first
   32 bits that follow the bottom of stack have a defined format called
   an ACH, and which further defines the content of the PWE3 packet.
   For MPLS-TP this mechanism is further generalized Section 3.2.

   When the OAM, or a similar message is carried over an LSP, rather
   than over a pseudowire, it is necessary to provide an indication in
   the packet that the payload is something other than a regular data
   packet.  This is acheived by including ia new reserved label in the
   label stack.  This reserved label is referred to as the 'Generic-ACH
   Label (GAL)', and is defined in [6].  When a GAL is found anywhere
   within the label stack it indicates that the payload begins with an
   ACH.  Note however that MPLS-TP forwarding follows the normal MPLS
   model, and that a GAL is invisible to an LSR unless it is the label
   being popped.  The only circumstance under which the label stack may
   be inspected for a GAL is when the TTL has expired.  Any MPLS-TP
   component which intentionally triggers this inspection must assume
   that the inspection to be asynchronous with respect to the forwarding

Bocci, et al.            Expires March 24, 2009                 [Page 5]

Internet-Draft              MPLS TP Framework             September 2008

   of other packets.

   In MPLS-TP, the 'Generic-ACH Label (GAL)' always appears at the
   bottom of the label stack (i.e.  S bit set to 1), however this does
   not preclude its use elsewhere in the label stack in other
   applications.

3.3.  Generic Associated Channel Header(GE-ACH)

   As described in Section 3.3 MPLS-TP makes use of a generic associated
   channel (GE-ACH) to support Fault, Configuration, Accounting,
   Performance and Security (FCAPS) functions by carrying packets
   related to OAM, APS, SCC, MCC or other packet types in band over LSPs
   or PWs.  The GE-ACH is defined in [7]and it is similar to the PWE3
   Associated Channel, which is used to carry OAM packets across
   pseudowires.  The GE-ACH is indicated by a generic associated channel
   header, similar to the PWE3 VCCV control word, and this is present
   for all LSPs and PWs making use of FCAPS functions supported by the
   GE-ACH.

   The GE-ACH MUST only be used for channels that are an adjunct to the
   data service.  Examples of these are OAM, APS, MCC and SCC, but the
   use is not resticted to those names services.  The GE-ACH MUST NOT be
   used to carry additional data for use in the forwarding path, i.e. it
   MUST NOT be used as an alternative to a PW control word, or to define
   a PW type.

   The messages transfered over the GE-ACH MUST conform to the security
   and congestion considerations described in [7].  They must also take
   into consideration the throughput, latency and congestion
   requirements of the main data channel.

   Figure 1 shows the reference model depicting how the control channel
   is associated with the pseudowire protocol stack, as per [8].

Bocci, et al.            Expires March 24, 2009                 [Page 6]

Internet-Draft              MPLS TP Framework             September 2008

         +-------------+                                +-------------+
          |  Layer2     |                                |  Layer2     |
          |  Emulated   |       < Emulated Service >     |  Emulated   |
          |  Services   |                                |  Services   |
          +-------------+                                +-------------+
          |             |            VCCV/PW             |             |
          |Demultiplexer|    < Associated Channel >      |Demultiplexer|
          +-------------+                                +-------------+
          |    PSN      |          < PSN Tunnel >        |    PSN      |
          +-------------+                                +-------------+
          |  Physical   |                                |  Physical   |
          +-----+-------+                                +-----+-------+
                |                                              |
                |             ____     ___       ____          |
                |           _/    \___/   \    _/    \__       |
                |          /               \__/         \_     |
                |         /                               \    |
                +--------|      MPLS/MPLS-TP Network       |---+
                          \                               /
                           \   ___      ___     __      _/
                            \_/   \____/   \___/  \____/

      Figure 1: PWE3 Protocol Stack Reference Model including the PW
                        Associated Control Channel

   PW associated channel messages are encapsulated using the PWE3
   encapsulation, so that they are handled and processed in the same
   manner (or in some cases, an analogous manner) as the PW PDUs for
   which they provide a control channel.

   Figure 2 shows the reference model depicting how the control channel
   is associated with the LSP protocol stack.

Bocci, et al.            Expires March 24, 2009                 [Page 7]

Internet-Draft              MPLS TP Framework             September 2008

          +-------------+                                +-------------+
          |             |                                |             |
          |  Payload    |          < Service >           |   Payload   |
          |  Services   |                                |             |
          +-------------+                                +-------------+
          |             |            LSP                 |             |
          |Demultiplexer|     < Associated Channel >     |Demultiplexer|
          +-------------+                                +-------------+
          |    GAL      |                                |    GAL      |
          +-------------+                                +-------------+
          |    PSN      |            < LSP >             |    PSN      |
          +-------------+                                +-------------+
          |  Physical   |                                |  Physical   |
          +-----+-------+                                +-----+-------+
                |                                              |
                |             ____     ___       ____          |
                |           _/    \___/   \    _/    \__       |
                |          /               \__/         \_     |
                |         /                               \    |
                +--------|      MPLS/MPLS-TP Network       |---+
                          \                               /
                           \   ___      ___     __      _/
                            \_/   \____/   \___/  \____/

      Figure 2: MPLS Protocol Stack Reference Model including the LSP
                        Associated Control Channel

   LSP associated channel messages are encapsulated using a generic
   associated control channel header (GE-ACH).  The presence of the GE-
   ACH is indicated by the inclusion of an additional 'Generic-ACH Label
   (GAL)'.  This arrangement means that both normal data packets and
   packets carrying an ACH are carried over LSPs in a similar manner.

   Note that where a traffic engineered LSP is used the paths will be
   identical.  If for any reason a non-traffic engineered path (for
   example an LDP path) were to be used the ECMP behaviour may be
   modified by the presence of the GAL.

3.4.  Forwarding

   Mpls-TP LSPs use the MPLS label switching operations defined in [2].
   These operations are highly optimized for performance and MUST NOT be
   modified by the MPLS-TP profile.

   During forwarding a label is pushed to describe the processing
   operaton to be performed at the next hop at that level of
   encapsulation.  A swap of this label is an atomic operation in which
   the contents of the packet after the swapped label are opaque to the

Bocci, et al.            Expires March 24, 2009                 [Page 8]

Internet-Draft              MPLS TP Framework             September 2008

   forwarder.  The only circumstance that disrupts a swap operation is
   TTL expiry, in which case the packet may be discarded or subjected to
   further scrutinity within the LSR.  Operations on a packet with an
   expired TTL are asynchronous to the other packets in the LSP.  Thus
   the only way to cause a P (intermediate) LSR to inspect a packet (for
   example for OAM purposes) is to set the TTL to expiry at that LSR.

   Editor's Note - RFC3031 says that a packet SHOULD emerge with the
   same TTL value as it would if it traversed the same sequence of
   routers.  RFC791 says that TTL MUST be decremented by at least one.
   This implies that architecturally TTL change cannot be assumed to be
   synonymous with hop count.  Is TTL decrement of greater that one a
   concern in a practical network and what (if anything) do we need to
   say on this subject in this document.

   MPLS-TP PWs support the PW and MS-PW forwarding operations defined
   in[3] and [4].

   The Class of Service (CoS) field (former MPLS EXP field) follows the
   definition and processing rules of [9] and [10], only the pipe and
   short-pipe models are supported in MPLS-TP.

   The MPLS encapsulation format is as defined in RFC 3032[11].  Per-
   platform or the per-interface label space can be selected.  Standard
   PW encapsulation mechanisms are applicable to the different client
   layers as defined by the IETF PWE3 WG.

   MPLS-TP LSPs can be unidirectional or bidirectional point-to-point.
   As for MPLS, point-to-multipoint MPLS-TP LSPs are unidirectional.

   Point-to-multipont PWs are currently in definition in the IETF and
   may be incorporated in MPLS-TP if required.

   It MUST be possible to configure an MPLS-TP LSP such that the forward
   and backward directions of bidirectional MPLS-TP LSPs congruent: i.e.
   they follow the same path.  The pairing relationship between the
   forward and the backward directions must be known at each MEP, MIP or
   segment protection endpoint on a bidirectional LSP.

   Per-packet equal cost multi-path (ECMP) load balancing is not
   applicable to MPLS-TP LSPs, however PWs or LSPs that emulate link
   bundles may be employed.

   Editor's note: need to check whether transport networks incorporate
   link bundeling.

   Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by default.

Bocci, et al.            Expires March 24, 2009                 [Page 9]

Internet-Draft              MPLS TP Framework             September 2008

   Both E-LSP and L-LSP are supported in MPLS-TP, as defined in RFC 3270
   [10].

3.5.  Operations and Management (OAM)

   MPLS-TP requires [22] that a set of OAM capabilities is available to
   perform fault management (e.g. fault detection and localization) and
   performance monitoring (e.g. signal quality measurement) of the
   MPLS-TP network and the services.

   The following OAM functions SHOULD be supported by MPLS-TP and are
   intended to be applicable to any layer defined within MPLS- TP, i.e.
   MPLS Section, LSP and PW:

   o  Continuity Check

   o  Connectivity verification

   o  Performance monitoring

   o  Alarm suppression

   o  Remote Integrity

   For all of the above listed functions, (except alarm suppression)
   both "continuous" and "on-demand" operation SHOULD be supported.

   Performance monitoring includes means for both "packet loss
   measurement" and "delay measurement".

   It is REQUIRED that MPLS-TP OAM packets share the same fate as their
   corresponding data packets and that a means exists to identify OAM
   packets.  The documents [6] and [7] propose specific mechanisms
   relying on the combination of the 'Generic-ACH Label (GAL)' and
   Generic Associated Channel Header for MPLS Sections and LSPs and
   using the Generic Associated Channel Header only for MPLS PWs.  This
   is described in more detail elsewhere in this document Section 3.3
   and Section 3.2.

   The MPLS-TP OAM toolset needs to be able to operate without relying
   on a dynamic control plane or IP functionality in the datapath.  In
   the case of MPLS-TP deployment with IP functionality, all existing
   IP-MPLS OAM functions, e.g.  LSP-Ping, BFD and VCCV, may be used.
   This does not preculde the use of other OAM tools in an IP
   addressable network.

   One use of OAM mechanisms is to detect link failures, node failures
   and performance outside the required specification which then may be

Bocci, et al.            Expires March 24, 2009                [Page 10]

Internet-Draft              MPLS TP Framework             September 2008

   used to trigger recovery actions, according to the requirements of
   the service.

3.6.  Control Plane

   The MPLS-TP may utilize a distributed control plane to enable fast,
   dynamic and reliable service provisioning in multi-vendor and multi-
   domain environments using standardized protocols that guarantee
   interoperability.

   Editor's note: There have been various discussions about GMPLS vs
   RSVP-TE.  We need to think about how that impacts the following
   sentence.  The sentence that follows - contains RSVP-TE - seems to
   conflict with the strict wording of the first sentence.  Do we wish
   operators be able to use regulary RSVP-TE is they choose?

   The MPLS-TP control plane is based on a combination of the MPLS
   control plane for pseudowires and the GMPLS control plane for MPLS-TP
   LSPs, respectively.  More specifically, LDP is used for PW signaling
   and RSVP-TE for LSP signaling.  The distributed MPLS-TP control plane
   provides the following basic functions:

   o  Signaling

   o  Routing

   o  Traffic engineering and constraint-based path computation

   In a multi-domain environment, the MPLS-TP control plane may provide
   different types of interfaces at domain boundaries or within the
   domains such as UNI, I-NNI, and E-NNI where different policies are in
   place that control what kind of information is exchanged across these
   different types of interfaces.

   Editor's note: Isn't the following a managment plane operation.  I
   can't think of a routing protocol triggering an OAM message.  Or do
   we mean that the control plane is capable of reacting to OAM events?

   The MPLS-TP control plane is capable of activating MPLS-TP OAM
   functions as described in the OAM section of this document
   Section 3.5 e.g. for fault detection and localization in the event of
   a failure in order to efficiently restore failed transport paths.

   The MPLS-TP control plane supports all MPLS-TP data plane
   connectivity patterns that are needed for establishing transport
   paths including protected paths as described in the survivability
   section Section 3.7 of this document.  Examples of the MPLS-TP data
   plane connectivity patterns are LSPs utilizing the fast reroute

Bocci, et al.            Expires March 24, 2009                [Page 11]

Internet-Draft              MPLS TP Framework             September 2008

   backup methods as defined in [12] and ingress-to-egress 1+1 or 1:1
   protected LSPs.

   Moreover, the MPLS-TP control plane needs to be capable of performing
   fast restoration in the event of network failures.

   The MPLS-TP control plane provides features to ensure its own
   survivavbility and to enable it to recover gracefully from failures
   and degredations.  These include graceful opetations and non-stop
   operations.  The MPLS-TP control plane is largely decoupled from the
   MPLS-TP data plane such that failures in the control plane do not
   impact the control plane and vice versa.

3.6.1.  PW Control Plane

   An MPLS-TP packet transport network provides many of its transport
   services in the form of single-segment or multi-segment pseudowires
   following the PWE3 architecture as defined in [3] and [4] .  The
   setup and maintenance of single-segment or multi- segment pseudowires
   is based on the Label Distribution Protocol (LDP) as per [13] and the
   use of LDP in this manner is applicable to PWs used to provide MPLS
   transport services.

   It shall be noted that multi-segment pseudowire signaling is still
   work in progress.  The control plane supporting multi-segment
   pseudowires is based on [14].

3.6.2.   LSP Control Plane

   Editors note: The following must be reviewed by a CP specialist

   MPLS-TP provider edge nodes aggregate multiple pseudowires and carry
   them across the MPLS-TP network through MPLS-TP tunnels (MPLS-TP
   LSPs).  The generalized MPLS (GMPLS) protocol suite already supports
   packet-switched capable (PSC) technologies and is therefore used as
   control plane for MPLS-TP transport paths (LSPs).  The LSP control
   plane includes:

   o  RSVP-TE for signalling

   o  OSPF-TE for routing

   o  ISIS-TE for routing?

   RSVP-TE signaling in support of GMPLS as defined in [15]is used for
   the setup, modification, and release of MPLS-TP transport paths and
   protection paths.  It supports unidirectional, bi-directional and
   multicast types of LSPs.  The route of a transport path is typically

Bocci, et al.            Expires March 24, 2009                [Page 12]

Internet-Draft              MPLS TP Framework             September 2008

   calculated in the ingress node of a domain and the RSVP explicit
   route object (ERO) is utilized for the setup of the transport path
   exactly following the given route.

   OSPF-TE routing in support of GMPLS as defined in [16]is used for
   carrying link state information in a MPLS-TP network.

   For routing scalability reasons, parallel physical links in an MPLS-
   TP network are typically bundled into TE-links as defined in [17]and
   the OSPF-TE routing protocol disseminates link state information on a
   TE-link basis.

3.6.3.  Static Operation of LSP

   Where a control plane is not used to set up and manage the LSPs, the
   following considerations apply.  Static configuration of the LSP,
   either by direct configuration of the LSRs, or via a network
   management station must take care that loops to not form on an active
   LSP.  The OAM would normally detect a break in end to end
   connectivity as a consequence of a loop, and withdraw the LSP from
   use.  However the colateral damage that a loop can during the time
   taken to detect the failure is severe.  Therefore an LSP should not
   be brought into operation until it certain that loops do not exist.

3.7.  Survivability

   Editors note: This needs some work in the next version.

   A wide variety of resiliency schemes have been developed to meet the
   various network and service survivability objectives.  As part of the
   MPLS/PW paradigms, MPLS FRR [12]provides two methods for local repair
   using back-up LSP tunnels, while PWE redundancy [18]supports
   scenarios where the protection for the PW can not be fully provided
   by the PSN layer (i.e. where the backup PW terminates on a different
   target PE node than the working PW).  Additionally, GMPLS provides a
   set of control plane driven well known protection and restoration
   mechanisms [15].  Finally, as part of the transport networks and
   applications paradigms, APS-based linear and ring protection
   mechanisms are defined in [19]and [24].

   These schemes have different scopes.  They are protecting against
   link and/or node failures and can be applied end-to-end or on a
   segment of the considered connection.

   These protection schemes propose different levels of resiliency (e.g.
   1+1, 1:1, shared).

   The applicability of any given scheme to meet specific requirements

Bocci, et al.            Expires March 24, 2009                [Page 13]

Internet-Draft              MPLS TP Framework             September 2008

   is outside the current scope of this document.

   MPLS-TP resiliency mechanisms characteristics are listed below

   o  Linear, ring and meshed protection schemes are supported.

   o  As with all network layer protection schemes, MPLS-TP recovery
      mechanisms (protection and restoration), rely on OAM mechanisms to
      detect and localize network faults or service degenerations.

   o  APS-based protection mechanisms (linear and ring) rely on MPLS-TP
      APS mechanisms to coordinate and trigger protection switching
      actions.

   o  MPLS-TP recovery schemes are designed to be applicable at various
      levels (MPLS section, LSP and PW), providing segment and end-to-
      end recovery.

   o  MPLS-TP recovery mechanisms support means for avoiding race
      conditions in switching activity triggered by a fault condition
      detected both at server layer and at MPLS-TP layer.

   o  MPLS-TP recovery mechanisms can be data plane, control plane or
      management plane based.

   o  MPLS-TP allows for revertive and non-revertive behavior o Multiple
      resiliency mechanisms can be applied to any connection

3.8.  Network Management

   The network management architecture and requirements for MPLS-TP are
   specified in [23].  It derives from the generic specifications
   described in ITU-T G.7710/Y.1701 [20]for transport technologies.  It
   also leverages on the OAM requirements for MPLS Networks [25] and
   MPLS-TP Networks [22]and expands on the requirements to cover the
   modifications necessary for fault, configuration, performance, and
   security.

   The Equipment Management Function (EMF) of a MPLS-TP NE provides the
   means through which a management system manages the NE.  The
   Management Communication Channel (MCC), realized by the GE-ACH,
   provides a logical operations channel between NEs for transferring
   Management information.  For the management interface from a
   management system to a MPLS-TP NE, there is no restriction on which
   management protocol should be used.  It is allowed to provision and
   manage an end-to-end connection across a network where some segments
   are create/managed, for examples by Netconf or SNMP and other
   segments by XML or CORBA interfaces.  It is allowed to run

Bocci, et al.            Expires March 24, 2009                [Page 14]

Internet-Draft              MPLS TP Framework             September 2008

   maintenance operations on a connection which is independent of the
   provisioning mechanism.  An MPLS-TP NE is not required to offer more
   than one standard management interface.

   The Fault Management (FM) functions within the EMF of an MPLS-TP NE
   enable the supervision, detection, validation, isolation, correction,
   and alarm handling of abnormal operation of the MPLS-TP network and
   its environment.  Supervision for transmission (such as continuity,
   connectivity, etc.), software processing, hardware, and environment
   are essential for FM.  Alarm handling includes alarm severity
   assignment, alarm suppression/aggregation/correlation, alarm
   reporting control, and alarm reporting.

   Configuration Management (CM) provides functions to exercise control
   over, identify, collect data from, and provide data to MPLS-TP NEs.
   In addition to general configuration for hardware, software
   protection switching, alarm reporting control, and date/time setting,
   the EMF of the MPLS-TP NE also supports the configuration of
   maintenance entity identifiers (such as MEP ID and MIP ID).  The EMF
   also supports configuration of the OAM parameters as part of
   connectivity management to meet specific operational requirements,
   such as whether one-time on-demand or periodically based on a
   specified frequency.

   The Performance Management (PM) functions within the EMF of an MPLS-
   TP NE supports the evaluation and reporting upon the behaviour of the
   equipment, NE, and network with the objective of providing coherent
   and consistent interpretation of the network behaviour, in particular
   for hybrid network which consists of multiple transport technologies.
   Packet loss measurement and delay measurement are collected so that
   they can be used to detect performance degradation.  Performance
   degradation is reported via fault management for corrective actions
   (e.g. protection switch) and via performance monitoring for Service
   Level Agreement (SLA) verification and billing.  The performance data
   collection mechanisms should be flexible to be configured to operate
   on-demand or proactively.

4.  Security Considerations

   To be covered in a future revision of this document.

5.  IANA Considerations

   To be covered in a future revision of this document.

Bocci, et al.            Expires March 24, 2009                [Page 15]

Internet-Draft              MPLS TP Framework             September 2008

6.  Acknowledgements

   The editors wish to thank the following for their contribution to
   this document: Dieter Beller

   o  Dieter Beller

   o  Italo Busi

   o  Hing-Kam Lam

   o  Lieven Levrau

   o  Vincenzo Sestito

   o  Martin Vigoureux

7.  References

7.1.  Normative References

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

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

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

   [4]   Bocci, M. and S. Bryant, "An Architecture for Multi-Segment
         Pseudo Wire Emulation Edge-to-Edge",
         draft-ietf-pwe3-ms-pw-arch-04 (work in progress), June 2008.

   [5]   Bryant, S., Swallow, G., Martini, L., and D. McPherson,
         "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use
         over an MPLS PSN", RFC 4385, February 2006.

   [6]   Vigoureux, M., Swallow, G., Aggarwal, R., Ward, D., and M.
         Bocci, "Assignment of the Generic Associated Channel Header
         Label (GAL)", draft-vigoureux-mpls-tp-gal-00 (work in
         progress), June 2008.

   [7]   Bocci, M., Ward, D., Bryant, S., Busi, I., and M. Vigoureux,
         "MPLS Generic Associated Channel",
         draft-bocci-pwe3-mpls-tp-ge-ach-00 (work in progress),
         June 2008.

Bocci, et al.            Expires March 24, 2009                [Page 16]

Internet-Draft              MPLS TP Framework             September 2008

   [8]   Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
         Connectivity Verification (VCCV): A Control Channel for
         Pseudowires", RFC 5085, December 2007.

   [9]   Andersson, L., ""EXP field" renamed to "CoS Field"",
         draft-ietf-mpls-cosfield-def-04 (work in progress), July 2008.

   [10]  Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P.,
         Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol
         Label Switching (MPLS) Support of Differentiated Services",
         RFC 3270, May 2002.

   [11]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci,
         D., Li, T., and A. Conta, "MPLS Label Stack Encoding",
         RFC 3032, January 2001.

   [12]  Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to
         RSVP-TE for LSP Tunnels", RFC 4090, May 2005.

   [13]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron,
         "Pseudowire Setup and Maintenance Using the Label Distribution
         Protocol (LDP)", RFC 4447, April 2006.

   [14]  Martini, L., Bocci, M., Bitar, N., Shah, H., Aissaoui, M., and
         F. Balus, "Dynamic Placement of Multi Segment Pseudo Wires",
         draft-ietf-pwe3-dynamic-ms-pw-08 (work in progress), July 2008.

   [15]  Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
         Extensions in Support of End-to-End Generalized Multi-Protocol
         Label Switching (GMPLS) Recovery", RFC 4872, May 2007.

   [16]  Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of
         Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203,
         October 2005.

   [17]  Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in
         MPLS Traffic Engineering (TE)", RFC 4201, October 2005.

   [18]  Muley, P., Bocci, M., and J. Newton, "Pseudowire (PW)
         Redundancy", draft-muley-pwe3-redundancy-02 (work in progress),
         November 2007.

   [19]  "ITU-T Recommendation G.8131/Y.1382 (02/07) " Linear protection
         switching for Transport MPLS (T-MPLS) networks"", 2005.

   [20]  "ITU-T Recommendation G.7710/Y.1701 (07/07), "Common equipment
         management function requirements"", 2005.

Bocci, et al.            Expires March 24, 2009                [Page 17]

Internet-Draft              MPLS TP Framework             September 2008

7.2.  Informative References

   [21]  Niven-Jenkins, B., Brungard, D., Betts, M., and N. Sprecher,
         "MPLS-TP Requirements",
         draft-jenkins-mpls-mpls-tp-requirements-00 (work in progress),
         July 2008.

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

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

   [24]  "Draft ITU-T Recommendation G.8132/Y.1382, "T-MPLS shared
         protection ring",
         http://www.itu.int/md/T05-SG15-080211-TD-PLEN-0501/en", 2005.

   [25]  Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
         Matsushima, "Operations and Management (OAM) Requirements for
         Multi-Protocol Label Switched (MPLS) Networks", RFC 4377,
         February 2006.

Authors' Addresses

   Matthew Bocci (editor)
   Alcatel-Lucent

   Phone:
   Fax:
   EMail: [email-masked]
   URI:

   Stewart Bryant (editor)
   Cisco Systems
   250 Longwater Ave
   Reading  RG2 6GB
   United Kingdom

   Phone: +44-208-824-8828
   EMail: [email-masked]

Bocci, et al.            Expires March 24, 2009                [Page 18]

Internet-Draft              MPLS TP Framework             September 2008

   Marc Lasserre (editor)
   Alcatel-Lucent

   EMail: [email-masked]

Bocci, et al.            Expires March 24, 2009                [Page 19]

Internet-Draft              MPLS TP Framework             September 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
   [email-masked].

Bocci, et al.            Expires March 24, 2009                [Page 20]


_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop