tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6371

 
 
 

Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks

Part 3 of 3, p. 48 to 62
Prev RFC Part

 


prevText      Top      Up      ToC       Page 48 
6.  OAM Functions for On-Demand Monitoring

   In contrast to proactive monitoring, on-demand monitoring is
   initiated manually and for a limited amount of time, usually for
   operations such as diagnostics to investigate a defect condition.

   On-demand monitoring covers a combination of "in-service" and "out-
   of-service" monitoring functions.  The control and measurement
   implications are:

   1. A MEG can be directed to perform an "on-demand" functions at
      arbitrary times in the lifetime of a transport path.

   2. "Out-of-service" monitoring functions may require a priori
      configuration of both MEPs and intermediate nodes in the MEG
      (e.g., data-plane loopback) and the issuance of notifications into
      client layers of the transport path being removed from service
      (e.g., lock reporting)

   3. The measurements resulting from "on-demand" monitoring are
      typically harvested in real time, as they are frequently initiated
      manually.  These do not necessarily require different harvesting
      mechanisms than for harvesting proactive monitoring telemetry.

   The functions that are exclusively out-of-service are those described
   in Section 6.3.  The remainder are applicable to both in-service and
   out-of-service transport paths.

6.1.  Connectivity Verification

   The on-demand connectivity verification function, as required in
   Section 2.2.3 of RFC 5860 [11], is a transaction that flows from the
   originating MEP to a target MIP or MEP to verify the connectivity
   between these points.

   Use of on-demand CV is dependent on the existence of a bidirectional
   ME or an associated return ME, or the availability of an out-of-band
   return path, because it requires the ability for target MIPs and MEPs
   to direct responses to the originating MEPs.

   One possible use of on-demand CV would be to perform fault management
   without using proactive CC-V, in order to preserve network resources,
   e.g., bandwidth, processing time at switches.  In this case, network
   management periodically invokes on-demand CV.

Top      Up      ToC       Page 49 
   An additional use of on-demand CV would be to detect and locate a
   problem of connectivity when a problem is suspected or known to be
   based on other tools.  In this case, the functionality will be
   triggered by the network management in response to a status signal or
   alarm indication.

   On-demand CV is based upon generation of on-demand CV packets that
   should uniquely identify the MEG that is being checked.  The on-
   demand functionality may be used to check either an entire MEG (end-
   to-end) or between the originating MEP and a specific MIP.  This
   functionality may not be available for associated bidirectional
   transport paths or unidirectional paths, as the MIP may not have a
   return path to the originating MEP for the on-demand CV transaction.

   When on-demand CV is invoked, the originating MEP issues a sequence
   of on-demand CV packets that uniquely identifies the MEG being
   verified.  The number of packets and their transmission rate should
   be pre-configured at the originating MEP to take into account normal
   packet-loss conditions.  The source MEP should use the mechanisms
   defined in Sections 3.3 and 3.4 when sending an on-demand CV packet
   to a target MEP or target MIP, respectively.  The target MEP/MIP
   shall return a reply on-demand CV packet for each packet received.
   If the expected number of on-demand CV reply packets is not received
   at the originating MEP, this is an indication that a connectivity
   problem may exist.

   On-demand CV should have the ability to carry padding such that a
   variety of MTU sizes can be originated to verify the MTU transport
   capability of the transport path.

   MIPs that are not targeted by on-demand CV packets, as well as
   intermediate nodes, do not process the CV information; they forward
   these on-demand CV OAM packets as regular data packets.

6.1.1.  Configuration Considerations

   For on-demand CV, the originating MEP should support the
   configuration of the number of packets to be transmitted/received in
   each sequence of transmissions and their packet size.

   In addition, when the CV packet is used to check connectivity toward
   a target MIP, the number of hops to reach the target MIP should be
   configured.

   For E-LSPs, the PHB of the on-demand CV packets should be configured
   as well.  This permits the verification of correct operation of QoS
   queuing as well as connectivity.

Top      Up      ToC       Page 50 
6.2.  Packet Loss Measurement

   On-demand Packet Loss Measurement (LM) is one of the capabilities
   supported by the MPLS-TP Performance Monitoring function in order to
   facilitate the diagnosis of QoS performance for a transport path, as
   required in Section 2.2.11 of RFC 5860 [11].

   On-demand LM is very similar to proactive LM described in Section
   5.5.  This section focuses on the differences between on-demand and
   proactive LM.

   On-demand LM is performed by periodically sending LM OAM packets from
   a MEP to a peer MEP and by receiving LM OAM packets from the peer MEP
   (if a co-routed or associated bidirectional transport path) during a
   pre-defined monitoring period.  Each MEP performs measurements of its
   transmitted and received user data packets.  These measurements are
   then correlated to evaluate the packet-loss performance metrics of
   the transport path.

   Use of packet loss measurement in an out-of-service transport path
   requires a traffic source such as a test device that can inject
   synthetic traffic.

6.2.1.  Configuration Considerations

   In order to support on-demand LM, the beginning and duration of the
   LM procedures, the transmission rate, and, for E-LSPs, the PHB class
   (associated with the LM OAM packets originating from a MEP) must be
   configured as part of the on-demand LM provisioning.  LM OAM packets
   should be transmitted with the PHB that yields the lowest drop
   precedence as described in Section 5.5.1.

6.2.2.  Sampling Skew

   The same considerations described in Section 5.5.2 for the proactive
   LM are also applicable to on-demand LM implementations.

6.2.3.  Multilink Issues

   Multilink issues are as described in Section 5.5.3.

6.3.  Diagnostic Tests

   Diagnostic tests are tests performed on a MEG that has been taken out
   of service.

Top      Up      ToC       Page 51 
6.3.1.  Throughput Estimation

   Throughput estimation is an on-demand out-of-service function, as
   required in Section 2.2.5 of RFC 5860 [11], that allows verifying the
   bandwidth/throughput of an MPLS-TP transport path (LSP or PW) before
   it is put in service.

   Throughput estimation is performed between MEPs and between a MEP and
   a MIP.  It can be performed in one-way or two-way modes.

   According to RFC 2544 [12], this test is performed by sending OAM
   test packets at increasing rates (up to the theoretical maximum),
   computing the percentage of OAM test packets received, and reporting
   the rate at which OAM test packets begin to drop.  In general, this
   rate is dependent on the OAM test packet size.

   When configured to perform such tests, a source MEP inserts OAM test
   packets with a specified packet size and transmission pattern at a
   rate to exercise the throughput.

   The throughput test can create congestion within the network, thus
   impacting other transport paths.  However, the test traffic should
   comply with the traffic profile of the transport path under test, so
   the impact of the test will not be worse than the impact caused by
   the customers, whose traffic would be sent over that transport path,
   sending the traffic at the maximum rate allowed by their traffic
   profiles.  Therefore, throughput tests are not applicable to
   transport paths that do not have a defined traffic profile, such as
   LSPs in a context where statistical multiplexing is leveraged for
   network capacity dimensioning.

   For a one-way test, the remote sink MEP receives the OAM test packets
   and calculates the packet loss.  For a two-way test, the remote MEP
   loops the OAM test packets back to the original MEP, and the local
   sink MEP calculates the packet loss.

   It is worth noting that two-way throughput estimation is only
   applicable to bidirectional (co-routed or associated) transport paths
   and can only evaluate the minimum of available throughput of the two
   directions.  In order to estimate the throughput of each direction
   uniquely, two one-way throughput estimation sessions have to be set
   up.  One-way throughput estimation requires coordination between the
   transmitting and receiving test devices as described in Section 6 of
   RFC 2544 [12].

   It is also worth noting that if throughput estimation is performed on
   transport paths that transit oversubscribed links, the test may not
   produce comprehensive results if viewed in isolation because the

Top      Up      ToC       Page 52 
   impact of the test on the surrounding traffic needs to also be
   considered.  Moreover, the estimation will only reflect the bandwidth
   available at the moment when the measure is made.

   MIPs that are not targeted by on-demand test OAM packets, as well as
   intermediate nodes, do not process the throughput test information;
   they forward these on-demand test OAM packets as regular data
   packets.

6.3.1.1.  Configuration Considerations

   Throughput estimation is an out-of-service tool.  The diagnosed MEG
   should be put into a locked state before the diagnostic test is
   started.

   A MEG can be put into a locked state either via an NMS action or
   using the Lock Instruct OAM tool as defined in Section 7.

   At the transmitting MEP, provisioning is required for a test signal
   generator that is associated with the MEP.  At a receiving MEP,
   provisioning is required for a test signal detector that is
   associated with the MEP.

   In order to ensure accurate measurement, care needs to be taken to
   enable throughput estimation only if all the MEPs within the MEG can
   process OAM test packets at the same rate as the payload data rates
   (see Section 6.3.1.2).

6.3.1.2.  Limited OAM Processing Rate

   If an implementation is able to process payload at much higher data
   rates than OAM test packets, then accurate measurement of throughput
   using OAM test packets is not achievable.  Whether OAM packets can be
   processed at the same rate as payload is implementation dependent.

6.3.1.3.  Multilink Considerations

   If multilink is used, then it may not be possible to perform
   throughput measurement, as the throughput test may not have a
   mechanism for utilizing more than one component link of the
   aggregated link.

6.3.2.  Data-Plane Loopback

   Data-plane loopback is an out-of-service function, as required in
   Section 2.2.5 of RFC 5860 [11].  This function consists in placing a
   transport path, at either an intermediate or terminating node, into a
   data-plane loopback state, such that all traffic (including both

Top      Up      ToC       Page 53 
   payload and OAM) received on the looped back interface is sent on the
   reverse direction of the transport path.  The traffic is looped back
   unmodified except for normal per-hop processing such as TTL
   decrement.

   The data-plane loopback function requires that the MEG is locked such
   that user data traffic is prevented from entering/exiting that MEG.
   Instead, test traffic is inserted at the ingress of the MEG.  This
   test traffic can be generated from an internal process residing
   within the ingress node or injected by external test equipment
   connected to the ingress node.

   It is also normal to disable proactive monitoring of the path as the
   MEP located upstream with respect to the node set in the data-plane
   loopback mode will see all the OAM packets originated by itself, and
   this may interfere with other measurements.

   The only way to send an OAM packet (e.g., to remove the data-plane
   loopback state) to the MIPs or MEPs hosted by a node set in the data-
   plane loopback mode is via TTL expiry.  It should also be noted that
   MIPs can be addressed with more than one TTL value on a co-routed
   bidirectional path set into data-plane loopback.

   If the loopback function is to be performed at an intermediate node,
   it is only applicable to co-routed bidirectional paths.  If the
   loopback is to be performed end to end, it is applicable to both co-
   routed bidirectional and associated bidirectional paths.

   It should be noted that data-plane loopback function itself is
   applied to data-plane loopback points that can reside on different
   interfaces from MIPs/MEPs.  Where a node implements data-plane
   loopback capability and whether it implements it in more than one
   point is implementation dependent.

6.3.2.1.  Configuration Considerations

   Data-plane loopback is an out-of-service tool.  The MEG that defines
   a diagnosed transport path should be put into a locked state before
   the diagnostic test is started.  However, a means is required to
   permit the originated test traffic to be inserted at the ingress MEP
   when data-plane loopback is performed.

   A transport path, at either an intermediate or terminating node, can
   be put into data-plane loopback state via an NMS action or using an
   OAM tool for data-plane loopback configuration.

Top      Up      ToC       Page 54 
   If the data-plane loopback point is set somewhere at an intermediate
   point of a co-routed bidirectional transport path, the side of the
   loopback function (east/west side or both sides) needs to be
   configured.

6.4.  Route Tracing

   It is often necessary to trace a route covered by a MEG from an
   originating MEP to the peer MEP(s) including all the MIPs in between.
   This may be conducted after provisioning an MPLS-TP transport path
   for, e.g., troubleshooting purposes such as fault localization.

   The route tracing function, as required in Section 2.2.4 of RFC 5860
   [11], is providing this functionality.  Based on the fate-sharing
   requirement of OAM flows, i.e., OAM packets receive the same
   forwarding treatment as data packets, route tracing is a basic means
   to perform connectivity verification and, to a much lesser degree,
   continuity check.  For this function to work properly, a return path
   must be present.

   Route tracing might be implemented in different ways, and this
   document does not preclude any of them.

   Route tracing should always discover the full list of MIPs and of
   peer MEPs.  In case a defect exists, the route tracing function will
   only be able to trace up to the defect, and it needs to be able to
   return the incomplete list of OAM entities that it was able to trace
   so that the fault can be localized.

6.4.1.  Configuration Considerations

   The configuration of the route tracing function must at least support
   the setting of the number of trace attempts before it gives up.

6.5.  Packet Delay Measurement

   Packet Delay Measurement (DM) is one of the capabilities supported by
   the MPLS-TP PM function in order to facilitate reporting of QoS
   information for a transport path, as required in Section 2.2.12 of
   RFC 5860 [11].  Specifically, on-demand DM is used to measure packet
   delay and packet delay variation in the transport path monitored by a
   pair of MEPs during a pre-defined monitoring period.

   On-demand DM is performed by sending periodic DM OAM packets from a
   MEP to a peer MEP and by receiving DM OAM packets from the peer MEP
   (if a co-routed or associated bidirectional transport path) during a
   configurable time interval.

Top      Up      ToC       Page 55 
   On-demand DM can be operated in two modes:

   o  One-way: a MEP sends a DM OAM packet to its peer MEP containing
      all the required information to facilitate one-way packet delay
      and/or one-way packet delay variation measurements at the peer
      MEP.  Note that this requires precise time synchronization at
      either MEP by means outside the scope of this framework.

   o  Two-way: a MEP sends a DM OAM packet with a DM request to its peer
      MEP, which replies with a DM OAM packet as a DM response.  The
      request/response DM OAM packets contain all the required
      information to facilitate two-way packet delay and/or two-way
      packet delay variation measurements from the viewpoint of the
      originating MEP.

   MIPs, as well as intermediate nodes, do not process the DM
   information; they forward these on-demand DM OAM packets as regular
   data packets.

6.5.1.  Configuration Considerations

   In order to support on-demand DM, the beginning and duration of the
   DM procedures, the transmission rate and, for E-LSPs, the PHB
   (associated with the DM OAM packets originating from a MEP) need to
   be configured as part of the DM provisioning.  DM OAM packets should
   be transmitted with the PHB that yields the lowest drop precedence
   within the measured PHB Scheduling Class (see RFC 3260 [17]).

   In order to verify different performances between long and short
   packets (e.g., due to the processing time), it should be possible for
   the operator to configure the packet size of the on-demand OAM DM
   packet.

7.  OAM Functions for Administration Control

7.1.  Lock Instruct

   The Lock Instruct (LKI) function, as required in Section 2.2.6 of RFC
   5860 [11], is a command allowing a MEP to instruct the peer MEP(s) to
   put the MPLS-TP transport path into a locked condition.

   This function allows single-side provisioning for administratively
   locking (and unlocking) an MPLS-TP transport path.

   Note that it is also possible to administratively lock (and unlock)
   an MPLS-TP transport path using two-side provisioning, where the NMS
   administratively puts both MEPs into an administrative lock
   condition.  In this case, the LKI function is not required/used.

Top      Up      ToC       Page 56 
   MIPs, as well as intermediate nodes, do not process the Lock Instruct
   information; they forward these on-demand LKI OAM packets as regular
   data packets.

7.1.1.  Locking a Transport Path

   A MEP, upon receiving a single-side administrative lock command from
   an NMS, sends an LKI request OAM packet to its peer MEP(s).  It also
   puts the MPLS-TP transport path into a locked state and notifies its
   client (sub-)layer adaptation function upon the locked condition.

   A MEP, upon receiving an LKI request from its peer MEP, can either
   accept or reject the instruction and replies to the peer MEP with an
   LKI reply OAM packet indicating whether or not it has accepted the
   instruction.  This requires either an in-band or out-of-band return
   path.  The LKI reply is needed to allow the MEP to properly report to
   the NMS the actual result of the single-side administrative lock
   command.

   If the lock instruction has been accepted, it also puts the MPLS-TP
   transport path into a locked state and notifies its client
   (sub-)layer adaptation function upon the locked condition.

   Note that if the client (sub-)layer is also MPLS-TP, Lock Report
   (LKR) generation at the client MPLS-TP (sub-)layer is started, as
   described in Section 5.4.

7.1.2.  Unlocking a Transport Path

   A MEP, upon receiving a single-side administrative unlock command
   from NMS, sends an LKI removal request OAM packet to its peer MEP(s).

   The peer MEP, upon receiving an LKI removal request, can either
   accept or reject the removal instruction and replies with an LK
   removal reply OAM packet indicating whether or not it has accepted
   the instruction.  The LKI removal reply is needed to allow the MEP to
   properly report to the NMS the actual result of the single-side
   administrative unlock command.

   If the lock removal instruction has been accepted, it also clears the
   locked condition on the MPLS-TP transport path and notifies its
   client (sub-)layer adaptation function of this event.

   The MEP that has initiated the LKI clear procedure, upon receiving a
   positive LKI removal reply, also clears the locked condition on the
   MPLS-TP transport path and notifies this event to its client
   (sub-)layer adaptation function.

Top      Up      ToC       Page 57 
   Note that if the client (sub-)layer is also MPLS-TP, Lock Report
   (LKR) generation at the client MPLS-TP (sub-)layer is terminated, as
   described in Section 5.4.

8.  Security Considerations

   A number of security considerations are important in the context of
   OAM applications.

   OAM traffic can reveal sensitive information, such as performance
   data and details, about the current state of the network.  Insertion
   or modification of OAM transactions can mask the true operational
   state of the network, and in the case of transactions for
   administration control, such as lock or data-plane loopback
   instructions, these can be used for explicit denial-of-service
   attacks.  The effect of such attacks is mitigated only by the fact
   that, for in-band messaging, the managed entities whose state can be
   masked is limited to those that transit the point of malicious access
   to the network internals due to the fate-sharing nature of OAM
   messaging.  This is not true when an out-of-band return path is
   employed.

   The sensitivity of OAM data therefore suggests that one solution is
   that some form of authentication, authorization, and encryption is in
   place.  This will prevent unauthorized access to vital equipment, and
   it will prevent third parties from learning about sensitive
   information about the transport network.  However, it should be
   observed that the combination of the frequency of some OAM
   transactions, the need for timeliness of OAM transaction exchange,
   and all permutations of unique MEP to MEP, MEP to MIP, and
   intermediate-system-originated transactions mitigates against the
   practical establishment and maintenance of a large number of security
   associations per MEG either in advance or as required.

   For this reason, it is assumed that the internal links of the network
   are physically secured from malicious access such that OAM
   transactions scoped to fault and performance management of individual
   MEGs are not encumbered with additional security.  Further, it is
   assumed in multi-provider cases where OAM transactions originate
   outside of an individual provider's trusted domain that filtering
   mechanisms or further encapsulation will need to constrain the
   potential impact of malicious transactions.  Mechanisms that the
   framework does not specify might be subject to additional security
   considerations.

   In case of misconfiguration, some nodes can receive OAM packets that
   they cannot recognize.  In such a case, these OAM packets should be
   silently discarded in order to avoid malfunctions whose effects may

Top      Up      ToC       Page 58 
   be similar to malicious attacks (e.g., degraded performance or even
   failure).  Further considerations about data-plane attacks via G-ACh
   are provided in RFC 5921 [8].

9.  Acknowledgments

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

   The editors gratefully acknowledge the contributions of Adrian
   Farrel, Yoshinori Koike, Luca Martini, Yuji Tochio, and Manuel Paul
   for the definition of per-interface MIPs and MEPs.

   The editors gratefully acknowledge the contributions of Malcolm
   Betts, Yoshinori Koike, Xiao Min, and Maarten Vissers for the Lock
   Report and Lock Instruct descriptions.

   The authors would also like to thank Alessandro D'Alessandro, Loa
   Andersson, Malcolm Betts, Dave Black, Stewart Bryant, Rui Costa,
   Xuehui Dai, John Drake, Adrian Farrel, Dan Frost, Xia Liang, Liu
   Gouman, Peng He, Russ Housley, Feng Huang, Su Hui, Yoshionori Koike,
   Thomas Morin, George Swallow, Yuji Tochio, Curtis Villamizar, Maarten
   Vissers, and Xuequin Wei for their comments and enhancements to the
   text.

10.  References

10.1.  Normative References

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

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

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

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

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

Top      Up      ToC       Page 59 
   [6]  Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in
        Multi-Protocol Label Switching (MPLS) Networks", RFC 3443,
        January 2003.

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

   [8]  Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and
        L. Berger, "A Framework for MPLS in Transport Networks", RFC
        5921, July 2010.

   [9]  Bocci, M., Levrau, L., and D. Frost, "MPLS Transport Profile
        User-to-Network and Network-to-Network Interfaces", RFC 6215,
        April 2011.

   [10] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS
        Transport Profile Data Plane Architecture", RFC 5960, August
        2010.

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

   [12] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
        Network Interconnect Devices", RFC 2544, March 1999.

   [13] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W.
        Weiss, "An Architecture for Differentiated Service", RFC 2475,
        December 1998.

   [14] ITU-T Recommendation G.806 (01/09), "Characteristics of
        transport equipment - Description methodology and generic
        functionality", January 2009.

10.2.  Informative References

   [15] Sprecher, N. and L. Fang, "An Overview of the OAM Tool Set for
        MPLS based Transport Networks", Work in Progress, June 2011.

   [16] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
        the Differentiated Services Field (DS Field) in the IPv4 and
        IPv6 Headers", RFC 2474, December 1998.

   [17] Grossman, D., "New Terminology and Clarifications for Diffserv",
        RFC 3260, April 2002.

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

Top      Up      ToC       Page 60 
   [19] ITU-T Recommendation G.707/Y.1322 (01/07), "Network node
        interface for the synchronous digital hierarchy (SDH)", January
        2007.

   [20] ITU-T Recommendation G.805 (03/00), "Generic functional
        architecture of transport networks", March 2000.

   [21] ITU-T Recommendation Y.1731 (02/08), "OAM functions and
        mechanisms for Ethernet based networks", February 2008.

   [22] IEEE Standard 802.1AX-2008, "IEEE Standard for Local and
        Metropolitan Area Networks - Link Aggregation", November 2008.

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

   [24] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile
        (MPLS-TP) Identifiers", RFC 6370, September 2011.

   [25] Winter, R., Ed., van Helvoort, H., and M. Betts, "MPLS-TP
        Identifiers Following ITU-T Conventions", Work in Progress, July
        2011.

11.  Contributing Authors

   Ben Niven-Jenkins
   Velocix

   EMail: ben@niven-jenkins.co.uk


   Annamaria Fulignoli
   Ericsson

   EMail: annamaria.fulignoli@ericsson.com


   Enrique Hernandez-Valencia
   Alcatel-Lucent

   EMail: Enrique.Hernandez@alcatel-lucent.com

Top      Up      ToC       Page 61 
   Lieven Levrau
   Alcatel-Lucent

   EMail: Lieven.Levrau@alcatel-lucent.com


   Vincenzo Sestito
   Alcatel-Lucent

   EMail: Vincenzo.Sestito@alcatel-lucent.com


   Nurit Sprecher
   Nokia Siemens Networks

   EMail: nurit.sprecher@nsn.com


   Huub van Helvoort
   Huawei Technologies

   EMail: hhelvoort@huawei.com


   Martin Vigoureux
   Alcatel-Lucent

   EMail: Martin.Vigoureux@alcatel-lucent.com


   Yaacov Weingarten
   Nokia Siemens Networks

   EMail: yaacov.weingarten@nsn.com


   Rolf Winter
   NEC

   EMail: Rolf.Winter@nw.neclab.eu

Top      Up      ToC       Page 62 
Authors' Addresses

   Dave Allan
   Ericsson

   EMail: david.i.allan@ericsson.com


   Italo Busi
   Alcatel-Lucent

   EMail: Italo.Busi@alcatel-lucent.com