Tech-invite   3GPPspecs   RFCs   Search in Tech-invite

in Index   Prev   Next

RFC 5921

A Framework for MPLS in Transport Networks

Pages: 56
Group: MPLS
Updated by:  62157274
Part 3 of 3 – Pages 36 to 56
First   Prev   None

Top   ToC   RFC5921 - Page 36   prevText
3.7.  Operations, Administration, and Maintenance (OAM)

   The MPLS-TP OAM architecture supports a wide range of OAM functions
   to check continuity, to verify connectivity, to monitor path
   performance, and to generate, filter, and manage local and remote
   defect alarms.  These functions are applicable to any layer defined
   within MPLS-TP, i.e., to MPLS-TP sections, LSPs, and PWs.

   The MPLS-TP OAM tool-set is able to operate without relying on a
   dynamic control plane or IP functionality in the data path.  In the
   case of an MPLS-TP deployment in a network in which IP functionality
   is available, all existing IP/MPLS OAM functions (e.g., LSP Ping,
   BFD, and VCCV) may be used.  Since MPLS-TP can operate in
   environments where IP is not used in the forwarding plane, the
   default mechanism for OAM demultiplexing in MPLS-TP LSPs and PWs is
   the Generic Associated Channel (Section 3.6).  Forwarding based on IP
   addresses for OAM or user data packets is not required for MPLS-TP.

   [RFC4379] and BFD for MPLS LSPs [RFC5884] have defined alert
   mechanisms that enable an MPLS LSR to identify and process MPLS OAM
   packets when the OAM packets are encapsulated in an IP header.  These
   alert mechanisms are based on TTL expiration and/or use an IP
   destination address in the range 127/8 for IPv4 and that same range
   embedded as IPv4-mapped IPv6 addresses for IPv6 [RFC4379].  When the
Top   ToC   RFC5921 - Page 37
   OAM packets are encapsulated in an IP header, these mechanisms are
   the default mechanisms for MPLS networks (in general) for identifying
   MPLS OAM packets, although the mechanisms defined in [RFC5586] can
   also be used.  MPLS-TP is able to operate in environments where IP
   forwarding is not supported, and thus the G-ACh/GAL is the default
   mechanism to demultiplex OAM packets in MPLS-TP in these

   MPLS-TP supports a comprehensive set of OAM capabilities for packet
   transport applications, with equivalent capabilities to those
   provided in SONET/SDH.

   MPLS-TP requires [RFC5860] that a set of OAM capabilities is
   available to perform fault management (e.g., fault detection and
   localization) and performance monitoring (e.g., packet delay and loss
   measurement) of the LSP, PW, or section.  The framework for OAM in
   MPLS-TP is specified in [OAM-FRAMEWORK].

   MPLS-TP OAM packets share the same fate as their corresponding data
   packets, and are identified through the Generic Associated Channel
   mechanism [RFC5586].  This uses a combination of an Associated
   Channel Header (ACH) and a G-ACh Label (GAL) to create a control
   channel associated to an LSP, section, or PW.

   OAM and monitoring in MPLS-TP is based on the concept of maintenance
   entities, as described in [OAM-FRAMEWORK].  A Maintenance Entity (ME)
   can be viewed as the association of two Maintenance Entity Group End
   Points (MEPs).  A Maintenance Entity Group (MEG) is a collection of
   one or more MEs that belongs to the same transport path and that are
   maintained and monitored as a group.  The MEPs that form an ME limit
   the OAM responsibilities of an OAM flow to within the domain of a
   transport path or segment, in the specific layer network that is
   being monitored and managed.

   A MEG may also include a set of Maintenance Entity Group Intermediate
   Points (MIPs).

   A G-ACh packet may be directed to an individual MIP along the path of
   an LSP or MS-PW by setting the appropriate TTL in the label stack
   entry for the G-ACh packet, as per the traceroute mode of LSP Ping
   [RFC4379] and the vccv-trace mode of [SEGMENTED-PW].  Note that this
   works when the location of MIPs along the LSP or PW path is known by
   the MEP.  There may be circumstances where this is not the case,
   e.g., following restoration using a facility bypass LSP.  In these
   cases, tools to trace the path of the LSP may be used to determine
   the appropriate setting for the TTL to reach a specific MIP.
Top   ToC   RFC5921 - Page 38
   Within an LSR or PE, MEPs and MIPs can only be placed where MPLS
   layer processing is performed on a packet.  The MPLS architecture
   mandates that MPLS layer processing occurs at least once on an LSR.

   Any node on an LSP can send an OAM packet on that LSP.  Likewise, any
   node on a PW can send OAM packets on a PW, including S-PEs.

   An OAM packet can only be received to be processed at an LSP
   endpoint, a PW endpoint (T-PE), or on the expiry of the TTL in the
   LSP or PW label stack entry.

3.8.  Return Path

   Management, control, and OAM protocol functions may require response
   packets to be delivered from the receiver back to the originator of a
   message exchange.  This section provides a summary of the return path
   options in MPLS-TP networks.  Although this section describes the
   case of an MPLS-TP LSP, it is also applicable to a PW.

   In this description, U and D are LSRs that terminate MPLS-TP LSPs
   (i.e., LERs), and Y is an intermediate LSR along the LSP.  Note that
   U is the upstream LER, and D is the downstream LER with respect to a
   particular direction of an LSP.  This reference model is shown in
   Figure 15.

                 LSP         LSP

           U ========= Y ========= D

          LER         LSR         LER

           ---------> Direction of user traffic flow

                  Figure 15: Return Path Reference Model

   The following cases are described for the various types of LSPs:

   Case 1  Return path packet transmission from D to U

   Case 2  Return path packet transmission from Y to U

   Case 3  Return path packet transmission from D to Y

   Note that a return path may not always exist (or may exist but be
   disabled), and that packet transmission in one or more of the above
   cases may not be possible.  In general, the existence and nature of
   return paths for MPLS-TP LSPs is determined by operational
Top   ToC   RFC5921 - Page 39
3.8.1.  Return Path Types

   There are two types of return path that may be used for the delivery
   of traffic from a downstream node D to an upstream node U.  Either:

   a.  The LSP between U and D is bidirectional, and therefore D has a
       path via the MPLS-TP LSP to return traffic back to U, or

   b.  D has some other unspecified means of directing traffic back to

   The first option is referred to as an "in-band" return path, the
   second as an "out-of-band" return path.

   There are various possibilities for "out-of-band" return paths.  Such
   a path may, for example, be based on ordinary IP routing.  In this
   case, packets would be forwarded as usual to a destination IP address
   associated with U.  In an MPLS-TP network that is also an IP/MPLS
   network, such a forwarding path may traverse the same physical links
   or logical transport paths used by MPLS-TP.  An out-of-band return
   path may also be indirect, via a distinct Data Communication Network
   (DCN) (provided, for example, by the method specified in [RFC5718]);
   or it may be via one or more other MPLS-TP LSPs.

3.8.2.  Point-to-Point Unidirectional LSPs

   Case 1  If an in-band return path is required to deliver traffic from
           D back to U, it is recommended for reasons of operational
           simplicity that point-to-point unidirectional LSPs be
           provisioned as associated bidirectional LSPs (which may also
           be co-routed) whenever return traffic from D to U is
           required.  Note that the two directions of such an LSP may
           have differing bandwidth allocations and QoS characteristics.
           The discussion below for such LSPs applies.

   As an alternative, an out-of-band return path may be used.

   Case 2  In this case, only the out-of-band return path option is
           available.  However, an additional out-of-band possibility is
           worthy of note here: if D is known to have a return path to
           U, then Y can arrange to deliver return traffic to U by first
           sending it to D along the original LSP.  The mechanism by
           which D recognizes the need for and performs this forwarding
           operation is protocol specific.

   Case 3  In this case, only the out-of-band return path option is
           available.  However, if D has a return path to U, then (in a
           manner analogous to the previous case) D can arrange to
Top   ToC   RFC5921 - Page 40
           deliver return traffic to Y by first sending it to U along
           that return path.  The mechanism by which U recognizes the
           need for and performs this forwarding operation is protocol

3.8.3.  Point-to-Point Associated Bidirectional LSPs

   For Case 1, D has a natural in-band return path to U, the use of
   which is typically preferred for return traffic, although out-of-band
   return paths are also applicable.

   For Cases 2 and 3, the considerations are the same as those for
   point-to-point unidirectional LSPs.

3.8.4.  Point-to-Point Co-Routed Bidirectional LSPs

   For all of Cases 1, 2, and 3, a natural in-band return path exists in
   the form of the LSP itself, and its use is preferred for return
   traffic.  Out-of-band return paths, however, are also applicable,
   primarily as an alternative means of delivery in case the in-band
   return path has failed.

3.9.  Control Plane

   A distributed dynamic control plane may be used to enable dynamic
   service provisioning in an MPLS-TP network.  Where the requirements
   specified in [RFC5654] can be met, the MPLS Transport Profile uses
   existing standard control-plane protocols for LSPs and PWs.

   Note that a dynamic control plane is not required in an MPLS-TP
   network.  See Section 3.11 for further details on statically
   configured and provisioned MPLS-TP services.

   Figure 16 illustrates the relationship between the MPLS-TP control
   plane, the forwarding plane, the management plane, and OAM for point-
   to-point MPLS-TP LSPs or PWs.
Top   ToC   RFC5921 - Page 41
    |                                                                  |
    |                Network Management System and/or                  |
    |                                                                  |
    |           Control Plane for Point-to-Point Connections           |
    |                                                                  |
                  |     |         |     |          |     |
     .............|.....|...  ....|.....|....  ....|.....|............
     :          +---+   |  :  : +---+   |   :  : +---+   |           :
     :          |OAM|   |  :  : |OAM|   |   :  : |OAM|   |           :
     :          +---+   |  :  : +---+   |   :  : +---+   |           :
     :            |     |  :  :   |     |   :  :   |     |           :
    \: +----+   +--------+ :  : +--------+  :  : +--------+   +----+ :/
    /: +----+   |ing     | :  : |ing     |  :  : |ing     |   +----+ :\
     :          +--------+ :  : +--------+  :  : +--------+          :
     '''''''''''''''''''''''  '''''''''''''''  '''''''''''''''''''''''

      1) NMS may be centralized or distributed.  Control plane is
      2) 'Edge' functions refers to those functions present at
         the edge of a PSN domain, e.g., native service processing or
      3) The control plane may be transported over the server
         layer, an LSP, or a G-ACh.

           Figure 16: MPLS-TP Control Plane Architecture Context

   The MPLS-TP control plane is based on existing MPLS and PW control
   plane protocols, and is consistent with the Automatically Switched
   Optical Network (ASON) architecture [G.8080].  MPLS-TP uses:

   o  Generalized MPLS (GMPLS) signaling ([RFC3945], [RFC3471],
      [RFC3473]) for LSPs, and

   o  Targeted LDP (T-LDP) signaling ([RFC4447], [SEGMENTED-PW],
      [DYN-MS-PW]) for pseudowires.

   MPLS-TP requires that any control-plane traffic be capable of being
   carried over an out-of-band signaling network or a signaling control
   channel such as the one described in [RFC5718].  Note that while
   T-LDP signaling is traditionally carried in-band in IP/MPLS networks,
   this does not preclude its operation over out-of-band channels.
   References to T-LDP in this document do not preclude the definition
   of alternative PW control protocols for use in MPLS-TP.
Top   ToC   RFC5921 - Page 42
   PW control (and maintenance) takes place separately from LSP tunnel
   signaling.  The main coordination between LSP and PW control will
   occur within the nodes that terminate PWs.  The control planes for
   PWs and LSPs may be used independently, and one may be employed
   without the other.  This translates into the four possible scenarios:
   (1) no control plane is employed; (2) a control plane is used for
   both LSPs and PWs; (3) a control plane is used for LSPs, but not PWs;
   (4) a control plane is used for PWs, but not LSPs.  The PW and LSP
   control planes, collectively, need to satisfy the MPLS-TP control
   plane requirements reviewed in the MPLS-TP Control Plane Framework
   [CP-FRAMEWORK].  When client services are provided directly via LSPs,
   all requirements must be satisfied by the LSP control plane.  When
   client services are provided via PWs, the PW and LSP control planes
   operate in combination, and some functions may be satisfied via the
   PW control plane, while others are provided to PWs by the LSP control

   Note that if MPLS-TP is being used in a multi-layer network, a number
   of control protocol types and instances may be used.  This is
   consistent with the MPLS architecture, which permits each label in
   the label stack to be allocated and signaled by its own control

   The distributed MPLS-TP control plane may provide the following

   o  Signaling

   o  Routing

   o  Traffic engineering and constraint-based path computation

   In a multi-domain environment, the MPLS-TP control plane supports
   different types of interfaces at domain boundaries or within the
   domains.  These include the User-Network Interface (UNI), Internal
   Network-Network Interface (I-NNI), and External Network-Network
   Interface (E-NNI).  Note that different policies may be defined that
   control the information exchanged across these interface types.

   The MPLS-TP control plane is capable of activating MPLS-TP OAM
   functions as described in the OAM section of this document
   Section 3.7, 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 Section 3.12.
Top   ToC   RFC5921 - Page 43
   Examples of the MPLS-TP data-plane connectivity patterns are LSPs
   utilizing the fast reroute backup methods as defined in [RFC4090] and
   ingress-to-egress 1+1 or 1:1 protected LSPs.

   The MPLS-TP control plane provides functions to ensure its own
   survivability and to enable it to recover gracefully from failures
   and degradations.  These include graceful restart and hot redundant
   configurations.  Depending on how the control plane is transported,
   varying degrees of decoupling between the control plane and data
   plane may be achieved.  In all cases, however, the control plane is
   logically decoupled from the data plane such that a control-plane
   failure does not imply a failure of the existing transport paths.

3.10.  Inter-Domain Connectivity

   A number of methods exist to support inter-domain operation of
   MPLS-TP, including the data-plane, OAM, and configuration aspects,
   for example:

   o  Inter-domain TE LSPs [RFC4726]

   o  Multi-segment Pseudowires [RFC5659]

   o  LSP stitching [RFC5150]

   o  Back-to-back attachment circuits [RFC5659]

   An important consideration in selecting an inter-domain connectivity
   mechanism is the degree of layer network isolation and types of OAM
   required by the operator.  The selection of which technique to use in
   a particular deployment scenario is outside the scope of this

3.11.  Static Operation of LSPs and PWs

   A PW or LSP may be statically configured without the support of a
   dynamic control plane.  This may be either by direct configuration of
   the PEs/LSRs or via a network management system.  Static operation is
   independent for a specific PW or LSP instance.  Thus, it should be
   possible for a PW to be statically configured, while the LSP
   supporting it is set up by a dynamic control plane.  When static
   configuration mechanisms are used, care must be taken to ensure that
   loops are not created.  Note that the path of an LSP or PW may be
   dynamically computed, while the LSP or PW itself is established
   through static configuration.
Top   ToC   RFC5921 - Page 44
3.12.  Survivability

   The survivability architecture for MPLS-TP is specified in

   A wide variety of resiliency schemes have been developed to meet the
   various network and service survivability objectives.  For example,
   as part of the MPLS/PW paradigms, MPLS provides methods for local
   repair using back-up LSP tunnels ([RFC4090]), while pseudowire
   redundancy [PW-REDUNDANCY] supports scenarios where the protection
   for the PW cannot be fully provided by the underlying LSP (i.e.,
   where the backup PW terminates on a different target PE node than the
   working PW in dual-homing scenarios, or where protection of the S-PE
   is required).  Additionally, GMPLS provides a well-known set of
   control-plane-driven protection and restoration mechanisms [RFC4872].
   MPLS-TP provides additional protection mechanisms that are optimized
   for both linear topologies and ring topologies and that operate in
   the absence of a dynamic control plane.  These are specified in

   Different protection schemes apply to different deployment topologies
   and operational considerations.  Such protection schemes may provide
   different levels of resiliency, for example:

   o  two concurrent traffic paths (1+1).

   o  one active and one standby path with guaranteed bandwidth on both
      paths (1:1).

   o  one active path and a standby path the resources of which are
      shared by one or more other active paths (shared protection).

   The applicability of any given scheme to meet specific requirements
   is outside the scope of this document.

   The characteristics of MPLS-TP resiliency mechanisms are as follows:

   o  Optimized for linear, ring, or meshed topologies.

   o  Use OAM mechanisms to detect and localize network faults or
      service degenerations.

   o  Include protection mechanisms to coordinate and trigger protection
      switching actions in the absence of a dynamic control plane.

   o  MPLS-TP recovery schemes are applicable to all levels in the
      MPLS-TP domain (i.e., section, LSP, and PW) providing segment and
      end-to-end recovery.
Top   ToC   RFC5921 - Page 45
   o  MPLS-TP recovery mechanisms support the coordination of protection
      switching at multiple levels to prevent race conditions occurring
      between a client and its server layer.

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

   o  MPLS-TP supports revertive and non-revertive behavior.

3.13.  Sub-Path Maintenance

   In order to monitor, protect, and manage a portion (i.e., segment or
   concatenated segment) of an LSP, a hierarchical LSP [RFC3031] can be
   instantiated.  A hierarchical LSP instantiated for this purpose is
   called a Sub-Path Maintenance Element (SPME).  Note that by
   definition an SPME does not carry user traffic as a direct client.

   An SPME is defined between the edges of the portion of the LSP that
   needs to be monitored, protected or managed.  The SPME forms an
   MPLS-TP Section [DATA-PLANE] that carries the original LSP over this
   portion of the network as a client.  OAM messages can be initiated at
   the edge of the SPME and sent to the peer edge of the SPME or to a
   MIP along the SPME by setting the TTL value of the LSE at the
   corresponding hierarchical LSP level.  A P router only pushes or pops
   a label if it is at the end of a SPME.  In this mode, it is an LER
   for the SPME.

   For example, in Figure 17, two SPMEs are configured to allow
   monitoring, protection, and management of the LSP concatenated
   segments.  One SPME is defined between LER2 and LER3, and a second
   SPME is set up between LER4 and LER5.  Each of these SPMEs may be
   monitored, protected, or managed independently.

   |<============================= LSP =============================>|

          |<---- Carrier 1 ---->|       |<---- Carrier 2 ---->|


          |====== SPME =========|       |====== SPME =========|
                 (Carrier 1)                 (Carrier 2)

 Note 1: LER2, LER3, LER4, and LER5 are with respect to the SPME,
         but LSRs with respect to the LSP.
 Note 2: The LSP terminates in LERs outside of Carrier 1 and
         Carrier 2, for example, LER1 and LER6.

                 Figure 17: SPMEs in Inter-Carrier Network
Top   ToC   RFC5921 - Page 46
   The end-to-end traffic of the LSP, including data traffic and control
   traffic (OAM, Protection Switching Control, management and signaling
   messages) is tunneled within the hierarchical LSP by means of label
   stacking as defined in [RFC3031].

   The mapping between an LSP and a SPME can be 1:1, in which case it is
   similar to the ITU-T Tandem Connection Element [G.805].  The mapping
   can also be 1:N to allow aggregated monitoring, protection, and
   management of a set of LSP segments or concatenated LSP segments.
   Figure 18 shows a SPME that is used to aggregate a set of
   concatenated LSP segments for the LSP from LERx to LERt and the LSP
   from LERa to LERd.  Note that such a construct is useful, for
   example, when the LSPs traverse a common portion of the network and
   they have the same Traffic Class.

   The QoS aspects of a SPME are network specific.  [OAM-FRAMEWORK]
   provides further considerations on the QoS aspects of OAM.

  |LERx|--|LSRy|-+                                      +-|LSRz|--|LERt|
                 |                                      |
                 |  |<---------- Carrier 1 --------->|  |
                 |  +-----+   +---+   +---+    +-----+  |
                 +--|     |---|   |---|   |----|     |--+
                    |LER1 |   |LSR|   |LSR|    |LER2 |
                 +--|     |---|   |---|   |----|     |--+
                 |  +-----+   +---+   + P +    +-----+  |
                 |  |============ SPME ==============|  |
  |LERa|--|LSRb|-+            (Carrier 1)               +-|LSRc|--|LERd|

          Figure 18: SPME for a Set of Concatenated LSP Segments

   SPMEs can be provisioned either statically or using control-plane
   signaling procedures.  The make-before-break procedures which are
   supported by MPLS allow the creation of a SPME on existing LSPs in-
   service without traffic disruption, as described in [SURVIVE-FWK].  A
   SPME can be defined corresponding to one or more end-to-end LSPs.
   New end-to-end LSPs that are tunneled within the SPME can be set up,
   which may require coordination across administrative boundaries.
   Traffic of the existing LSPs is switched over to the new end-to-end
   tunneled LSPs.  The old end-to-end LSPs can then be torn down.

   Hierarchical label stacking, in a similar manner to that described
   above, can be used to implement Sub-Path Maintenance Elements on
   pseudowires, as described in [OAM-FRAMEWORK].
Top   ToC   RFC5921 - Page 47
3.14.  Network Management

   The network management architecture and requirements for MPLS-TP are
   specified in [NM-FRAMEWORK] and [NM-REQ].  These derive from the
   generic specifications described in ITU-T G.7710/Y.1701 [G.7710] for
   transport technologies.  They also incorporate the OAM requirements
   for MPLS Networks [RFC4377] and MPLS-TP Networks [RFC5860] and expand
   on those requirements to cover the modifications necessary for fault,
   configuration, performance, and security in a transport network.

   The Equipment Management Function (EMF) of an MPLS-TP Network Element
   (NE) (i.e., LSR, LER, PE, S-PE, or T-PE) provides the means through
   which a management system manages the NE.  The Management
   Communication Channel (MCC), realized by the G-ACh, provides a
   logical operations channel between NEs for transferring management
   information.  The Network Management System (NMS) can be used to
   provision and manage an end-to-end connection across a network.
   Maintenance operations are run on a connection (LSP or PW) in a
   manner that is independent of the provisioning mechanism.  Segments
   may be created or managed by, for example, Netconf [RFC4741], SNMP
   [RFC3411], or CORBA (Common Object Request Broker Architecture)
   interfaces, but not all segments need to be created or managed using
   the same type of interface.  Where an MPLS-TP NE is managed by an
   NMS, at least one of these standard management mechanisms is required
   for interoperability, but this document imposes no restriction on
   which of these standard management protocols is used.  In MPLS-TP,
   the EMF needs to support statically provisioning LSPs for an LSR or
   LER, and PWs for a PE, as well as any associated MEPs and MIPs, as
   per Section 3.11.

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

   Configuration Management (CM) provides functions to control,
   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 Maintenance Entity Group Endpoint (MEP) ID and
   MEG Intermediate Point (MIP) ID).  The EMF also supports the
   configuration of OAM parameters as a part of connectivity management
   to meet specific operational requirements.  These may specify whether
Top   ToC   RFC5921 - Page 48
   the operational mode is one-time on-demand or is periodic at a
   specified frequency.

   The Performance Management (PM) functions within the EMF of an
   MPLS-TP NE support the evaluation and reporting of the behavior of
   the NEs and the network.  One particular requirement for PM is to
   provide coherent and consistent interpretation of the network
   behavior in a hybrid network that uses multiple transport
   technologies.  Packet loss measurement and delay measurements may be
   collected and used to detect performance degradation.  This is
   reported via fault management to enable corrective actions to be
   taken (e.g., protection switching) and via performance monitoring for
   Service Level Agreement (SLA) verification and billing.  Collection
   mechanisms for performance data should be capable of operating on-
   demand or proactively.

4.  Security Considerations

   The introduction of MPLS-TP into transport networks means that the
   security considerations applicable to both MPLS [RFC3031] and PWE3
   [RFC3985] apply to those transport networks.  When an MPLS function
   is included in the MPLS transport profile, the security
   considerations pertinent to that function apply to MPLS-TP.
   Furthermore, when general MPLS networks that utilize functionality
   outside of the strict MPLS Transport Profile are used to support
   packet transport services, the security considerations of that
   additional functionality also apply.

   For pseudowires, the security considerations of [RFC3985] and
   [RFC5659] apply.

   MPLS-TP nodes that implement the G-ACh create a Control Channel (CC)
   associated with a pseudowire, LSP, or section.  This control channel
   can be signaled or statically configured.  Over this control channel,
   control channel messages related to network maintenance functions
   such as OAM, signaling, or network management are sent.  Therefore,
   three different areas are of concern from a security standpoint.

   The first area of concern relates to control plane parameter and
   status message attacks, that is, attacks that concern the signaling
   of G-ACh capabilities.  MPLS-TP Control Plane security is discussed
   in [RFC5920].

   A second area of concern centers on data-plane attacks, that is,
   attacks on the G-ACh itself.  MPLS-TP nodes that implement the G-ACh
   mechanisms are subject to additional data-plane denial-of-service
   attacks as follows:
Top   ToC   RFC5921 - Page 49
      An intruder could intercept or inject G-ACh packets effectively
      disrupting the protocols carried over the G-ACh.

      An intruder could deliberately flood a peer MPLS-TP node with
      G-ACh messages to deny services to others.

      A misconfigured or misbehaving device could inadvertently flood a
      peer MPLS-TP node with G-ACh messages that could result in denial
      of services.  In particular, if a node has either implicitly or
      explicitly indicated that it cannot support one or all of the
      types of G-ACh protocol, but is sent those messages in sufficient
      quantity, it could result in a denial of service.

   To protect against these potential (deliberate or unintentional)
   attacks, multiple mitigation techniques can be employed:

      G-ACh message throttling mechanisms can be used, especially in
      distributed implementations that have a centralized control-plane
      processor with various line cards attached by some control-plane
      data path.  In these architectures, G-ACh messages may be
      processed on the central processor after being forwarded there by
      the receiving line card.  In this case, the path between the line
      card and the control processor may become saturated if appropriate
      G-ACh traffic throttling is not employed, which could lead to a
      complete denial of service to users of the particular line card.
      Such filtering is also useful for preventing the processing of
      unwanted G-ACh messages, such as those which are sent on unwanted
      (and perhaps unadvertised) control channel types.

   A third and last area of concern relates to the processing of the
   actual contents of G-ACh messages.  It is necessary that the
   definition of the protocols using these messages carried over a G-ACh
   include appropriate security measures.

   Additional security considerations apply to each MPLS-TP solution.
   These are discussed further in [SEC-FRAMEWORK].

   The security considerations in [RFC5920] apply.

5.  IANA Considerations

   IANA considerations resulting from specific elements of MPLS-TP
   functionality will be detailed in the documents specifying that

   This document introduces no additional IANA considerations in itself.
Top   ToC   RFC5921 - Page 50
6.  Acknowledgements

   The editors wish to thank the following for their contributions to
   this document:

   o  Rahul Aggarwal

   o  Dieter Beller

   o  Malcolm Betts

   o  Italo Busi

   o  John E Drake

   o  Hing-Kam Lam

   o  Marc Lasserre

   o  Vincenzo Sestito

   o  Nurit Sprecher

   o  Martin Vigoureux

   o  Yaacov Weingarten

   o  The participants of ITU-T SG15

7.  References

7.1.  Normative References

   [G.7710]         ITU-T, "Common equipment management function
                    requirements", ITU-T Recommendation G.7710/Y.1701,
                    July 2007.

   [G.805]          ITU-T, "Generic Functional Architecture of Transport
                    Networks", ITU-T Recommendation G.805, November

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

   [RFC3032]        Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
                    Farinacci, D., Li, T., and A. Conta, "MPLS Label
                    Stack Encoding", RFC 3032, January 2001.
Top   ToC   RFC5921 - Page 51
   [RFC3270]        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

   [RFC3473]        Berger, L., "Generalized Multi-Protocol Label
                    Switching (GMPLS) Signaling Resource ReserVation
                    Protocol-Traffic Engineering (RSVP-TE) Extensions",
                    RFC 3473, January 2003.

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

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

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

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

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

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

   [RFC5586]        Bocci, M., Vigoureux, M., and S. Bryant, "MPLS
                    Generic Associated Channel", RFC 5586, June 2009.

7.2.  Informative References

   [CP-FRAMEWORK]   Andersson, L., Berger, L., Fang, L., Bitar, N.,
                    Takacs, A., Vigoureux, M., Bellagamba, E., and E.
                    Gray, "MPLS-TP Control Plane Framework", Work in
                    Progress, March 2010.
Top   ToC   RFC5921 - Page 52
   [DATA-PLANE]     Frost, D., Bryant, S., and M. Bocci, "MPLS Transport
                    Profile Data Plane Architecture", Work in Progress,
                    July 2010.

   [DYN-MS-PW]      Martini, L., Bocci, M., Balus, F., Bitar, N., Shah,
                    H., Aissaoui, M., Rusmisel, J., Serbest, Y., Malis,
                    A., Metz, C., McDysan, D., Sugimoto, J., Duckett,
                    M., Loomis, M., Doolan, P., Pan, P., Pate, P.,
                    Radoaca, V., Wada, Y., and Y. Seo, "Dynamic
                    Placement of Multi Segment Pseudo Wires", Work in
                    Progress, October 2009.

   [G.8080]         ITU-T, "Architecture for the automatically switched
                    optical network (ASON)", ITU-T Recommendation
                    G.8080/Y.1304, 2005.

   [IDENTIFIERS]    Bocci, M. and G. Swallow, "MPLS-TP Identifiers",
                    Work in Progress, March 2010.

   [NM-FRAMEWORK]   Mansfield, S., Ed., Gray, E., Ed., and H. Lam, Ed.,
                    "MPLS-TP Network Management Framework", Work in
                    Progress, February 2010.

   [NM-REQ]         Mansfield, S. and K. Lam, "MPLS TP Network
                    Management Requirements", Work in Progress, October

   [OAM-DEF]        Andersson, L., Helvoort, H., Bonica, R., Romascanu,
                    D., and S. Mansfield, "The OAM Acronym Soup", Work
                    in Progress, June 2010.

   [OAM-FRAMEWORK]  Busi, I., Ed., Niven-Jenkins, B., Ed., and D. Allan,
                    Ed., "MPLS-TP OAM Framework", Work in Progress,
                    April 2010.

   [PW-REDUNDANCY]  Muley, P., "Pseudowire (PW) Redundancy", Work in
                    Progress, May 2010.

   [RFC3209]        Awduche, D., Berger, L., Gan, D., Li, T.,
                    Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions
                    to RSVP for LSP Tunnels", RFC 3209, December 2001.

   [RFC3411]        Harrington, D., Presuhn, R., and B. Wijnen, "An
                    Architecture for Describing Simple Network
                    Management Protocol (SNMP) Management Frameworks",
                    STD 62, RFC 3411, December 2002.
Top   ToC   RFC5921 - Page 53
   [RFC3443]        Agarwal, P. and B. Akyol, "Time To Live (TTL)
                    Processing in Multi-Protocol Label Switching (MPLS)
                    Networks", RFC 3443, January 2003.

   [RFC3471]        Berger, L., "Generalized Multi-Protocol Label
                    Switching (GMPLS) Signaling Functional Description",
                    RFC 3471, January 2003.

   [RFC3945]        Mannie, E., "Generalized Multi-Protocol Label
                    Switching (GMPLS) Architecture", RFC 3945, October

   [RFC4364]        Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual
                    Private Networks (VPNs)", RFC 4364, February 2006.

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

   [RFC4379]        Kompella, K. and G. Swallow, "Detecting Multi-
                    Protocol Label Switched (MPLS) Data Plane Failures",
                    RFC 4379, February 2006.

   [RFC4664]        Andersson, L. and E. Rosen, "Framework for Layer 2
                    Virtual Private Networks (L2VPNs)", RFC 4664,
                    September 2006.

   [RFC4726]        Farrel, A., Vasseur, J., and A. Ayyangar, "A
                    Framework for Inter-Domain Multiprotocol Label
                    Switching Traffic Engineering", RFC 4726, November

   [RFC4741]        Enns, R., "NETCONF Configuration Protocol", RFC
                    4741, December 2006.

   [RFC5150]        Ayyangar, A., Kompella, K., Vasseur, JP., and A.
                    Farrel, "Label Switched Path Stitching with
                    Generalized Multiprotocol Label Switching Traffic
                    Engineering (GMPLS TE)", RFC 5150, February 2008.

   [RFC5254]        Bitar, N., Bocci, M., and L. Martini, "Requirements
                    for Multi-Segment Pseudowire Emulation Edge-to-Edge
                    (PWE3)", RFC 5254, October 2008.

   [RFC5309]        Shen, N. and A. Zinin, "Point-to-Point Operation
                    over LAN in Link State Routing Protocols", RFC 5309,
                    October 2008.
Top   ToC   RFC5921 - Page 54
   [RFC5331]        Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS
                    Upstream Label Assignment and Context-Specific Label
                    Space", RFC 5331, August 2008.

   [RFC5654]        Niven-Jenkins, B., Brungard, D., Betts, M.,
                    Sprecher, N., and S. Ueno, "Requirements of an MPLS
                    Transport Profile", RFC 5654, September 2009.

   [RFC5659]        Bocci, M. and S. Bryant, "An Architecture for Multi-
                    Segment Pseudowire Emulation Edge-to-Edge", RFC
                    5659, October 2009.

   [RFC5718]        Beller, D. and A. Farrel, "An In-Band Data
                    Communication Network For the MPLS Transport
                    Profile", RFC 5718, January 2010.

   [RFC5860]        Vigoureux, M., Ward, D., and M. Betts, "Requirements
                    for Operations, Administration, and Maintenance
                    (OAM) in MPLS Transport Networks", RFC 5860, May

   [RFC5884]        Aggarwal, R., Kompella, K., Nadeau, T., and G.
                    Swallow, "Bidirectional Forwarding Detection (BFD)
                    for MPLS Label Switched Paths (LSPs)", RFC 5884,
                    June 2010.

   [RFC5885]        Nadeau, T. and C. Pignataro, "Bidirectional
                    Forwarding Detection (BFD) for the Pseudowire
                    Virtual Circuit Connectivity Verification (VCCV)",
                    RFC 5885, June 2010.

   [RFC5920]        Fang, L., Ed., "Security Framework for MPLS and
                    GMPLS Networks", RFC 5920, July 2010.

   [ROSETTA-STONE]  Sprecher, N., "A Thesaurus for the Terminology used
                    in Multiprotocol Label Switching Transport Profile
                    (MPLS-TP) drafts/RFCs and ITU-T's Transport Network
                    Recommendations.", Work in Progress, May 2010.

   [SEC-FRAMEWORK]  Fang, L. and B. Niven-Jenkins, "Security Framework
                    for MPLS-TP", Work in Progress, March 2010.

   [SEGMENTED-PW]   Martini, L., Nadeau, T., Metz, C., Bocci, M., and M.
                    Aissaoui, "Segmented Pseudowire", Work in Progress,
                    June 2010.
Top   ToC   RFC5921 - Page 55
   [SURVIVE-FWK]    Sprecher, N. and A. Farrel, "Multiprotocol Label
                    Switching Transport Profile Survivability
                    Framework", Work in Progress, June 2010.

   [VPMS-REQS]      Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard,
                    D., and L. Jin, "Framework and Requirements for
                    Virtual Private Multicast Service (VPMS)", Work in
                    Progress, October 2009.

   [X.200]          ITU-T, "Information Technology - Open Systems
                    Interconnection - Basic reference Model: The Basic
                    Model", ITU-T Recommendation X.200, 1994.
Top   ToC   RFC5921 - Page 56
Authors' Addresses

   Matthew Bocci (editor)
   Voyager Place, Shoppenhangers Road
   Maidenhead, Berks  SL6 2PJ
   United Kingdom


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


   Dan Frost (editor)
   Cisco Systems


   Lieven Levrau
   7-9, Avenue Morane Sulnier
   Velizy  78141


   Lou Berger
   LabN Consulting, L.L.C.