Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 5921

A Framework for MPLS in Transport Networks

Pages: 56
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 provisioning.
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 U. 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 document.

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 [SURVIVE-FWK]. 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 [SURVIVE-FWK]. 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 ---->| |LER1|---|LER2|---|LSR|---|LER3|-------|LER4|---|LSR|---|LER5|---|LER6| |====== 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 functionality. 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 1995. [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) Alcatel-Lucent Voyager Place, Shoppenhangers Road Maidenhead, Berks SL6 2PJ United Kingdom EMail: Stewart Bryant (editor) Cisco Systems 250 Longwater Ave Reading RG2 6GB United Kingdom EMail: Dan Frost (editor) Cisco Systems EMail: Lieven Levrau Alcatel-Lucent 7-9, Avenue Morane Sulnier Velizy 78141 France EMail: Lou Berger LabN Consulting, L.L.C. EMail: