Internet DRAFT - draft-fang-mpls-tp-oam-toolset
draft-fang-mpls-tp-oam-toolset
Network Working Group Luyuan Fang
Internet Draft Dan Frost
Intended status: Informational Cisco Systems
Expires: September 14, 2011 Nabil Bitar
Verizon
Raymond Zhang
BT
Lei Wang
Telenor
Kam Lee Yap
XO Communications
Michael Fargano
Qwest
John Drake
Juniper
Thomas Nadeau
March 14, 2011
MPLS-TP OAM Toolset
draft-fang-mpls-tp-oam-toolset-01.txt
Abstract
This document provides an overview of the MPLS-TP OAM toolset,
which consists of MPLS-TP fault management and performance
monitoring. This overview includes a brief recap of MPLS-TP OAM
requirements and functions, and of the generic mechanisms created
in the MPLS data plane to support in-band OAM. The importance of
using IANA assigned code point under G-Ach when supporting MPLS-TP
OAM is also discussed. The protocol definitions for each individual
MPLS-TP OAM tool are specified in separate RFCs or Working Group
documents which are referenced by this document.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
[Page 1]
MPLS-TP OAM-Toolset March 2011
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress.
This Internet-Draft will expire on September 14, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License..
Table of Contents
1. Introduction ..................................................3
2. Terminology ...................................................3
3. Brief Overview of MPLS-TP OAM Requirements ....................6
3.1. Architectural Requirements .................................6
3.2. Functional Requirements ....................................6
4. MPLS-TP OAM Mechanisms and Toolset Summary ....................7
4.1. In-band OAM Mechanisms .....................................8
4.2. Fault Management Toolset ...................................8
4.3. Performance Monitoring Toolset ............................10
5. OAM Toolset Utilization and Protocol Definitions .............10
5.1. Connectivity Check and Connectivity Verification ..........10
5.2 Diagnostic Tests and Lock Instruct. .......................11
5.3. Lock Reporting ............................................11
5.4. Alarm Reporting and Link down Indication ..................12
5.5. Remote Defect Indication ..................................12
5.6. Packet Loss and Delay Measurement .........................13
6. IANA assigned code points under G-Ach ........................14
7. Security Considerations ......................................15
8. IANA Considerations ..........................................15
[Page 2]
MPLS-TP OAM-Toolset March 2011
9. Normative References .........................................15
10. Informative References .....................................16
11. Authors' Addresses..........................................17
Requirements Language
Although this document is not a protocol specification, the key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [RFC
2119].
1. Introduction
The Operations, Administration, and Maintenance (OAM) Requirements
for Transport Profile of Multiprotocol Label Switching (MPLS-TP)
networks are defined in RFC 5860 [RFC 5860]. MPLS-TP OAM mechanisms
and multiple OAM tools have been developed based on MPLS-TP OAM
requirements.
This document provides an overview of the MPLS-TP OAM toolset,
which consists of MPLS-TP fault management and performance
monitoring. This overview includes a brief recap of MPLS-TP OAM
requirements and functions, and of the generic mechanisms created
in the MPLS data plane to support in-band OAM. The importance of
using IANA assigned code point under G-Ach when supporting MPLS-TP
OAM is also discussed.
The protocol definitions for each individual MPLS-TP OAM tool are
specified in separate RFCs or Working Group documents while this
document is work in progress, which are referenced by this
document.
The protocol definitions for each individual MPLS-TP OAM tool are
defined in separate RFCs (or Working Group documents while this
document is work in progress) referenced by this document.
2. Terminology
This document uses MPLS-TP OAM specific terminology.
Term Definition
----------------------------------------------------
AC Attachment Circuit
AIS Alarm indication signal
[Page 3]
MPLS-TP OAM-Toolset March 2011
APS Automatic Protection Switching
ATM Asynchronous Transfer Mode
BFD Bidirectional Forwarding Detection
CC Continuity Check
CE Customer-Edge device
CM Configuration Management
CoS Class of Service
CV Connectivity Verification
FM Fault Management
GAL Generic Alert Label
G-ACH Generic Associated Channel
GMPLS Generalized Multi-Protocol Label Switching
LDI Link Down Indication
LDP Label Distribution Protocol
LER Label Edge Router
LKR Lock Report
LM Loss Measurement
LMEG LSP ME Group
LOC Loss of Continuity
LSP Label Switched Path
LSR Label Switching Router
LSME LSP SPME ME
LSMEG LSP SPME ME Group
ME Maintenance Entity
[Page 4]
MPLS-TP OAM-Toolset March 2011
MEG Maintenance Entity Group
MEP Maintenance Entity Group End Point
MIP Maintenance Entity Group Intermediate Point
MPLS MultiProtocol Label Switching
NMS Network Management System
NTP Network Time Protocol
OAM Operations, Administration, and Management
PE Provider Edge
PM Performance Monitoring
PME PW Maintenance Entity
PMEG PW ME Group
PSME PW SPME ME
PSMEG PW SPME ME Group
PW Pseudowire
QoS Quality of Service
RDI Remote Defect Indication
SDH Synchronous Digital Hierarchy
SLA Service Level Agreement
SME Section Maintenance Entity
SMEG Section ME Group
SONET Synchronous Optical Network
SPME Sub-path Maintenance Element
S-PE Switching Provider Edge
SRLG Shared Risk Link Group
TC Traffic Class
[Page 5]
MPLS-TP OAM-Toolset March 2011
T-PE Terminating Provider Edge
3. Brief Overview of MPLS-TP OAM Requirements
This following Architectural and Functional Requirements are
defined by RFC 5860. They are captured here for easy reading before
discussing the toolset.
3.1. Architectural Requirements
The MPLS-TP OAM Supports point-to-point bidirectional PWs, point-
to-point co-routed bidirectional LSPs, point-to-point bidirectional
Sections, point-to-point associated bidirectional LSPs, point-to-
point unidirectional LSPs, and point-to-multipoint LSPs. In
addition, MPLS-TP OAM supports these LSPs and PWs when they span
single domain or multiple domains.
The protocol solution(s) SHOULD be independent of the underlying
tunneling or point-to-point technology or transmission media. The
protocol solution(s) SHOULD be independent of the service a PW may
emulate.
In-band OAM MUST be implemented. OAM packets for a specific PW,
LSP, or Section MUST follow the exact same data path as user
traffic of the same.
The solutions MUST support OAM functions with or without relying on
IP capabilities.
It is REQUIRED that OAM interoperability be achieved between
distinct domains with different operational models, e.g. with IP or
without IP support in the data plane.
And OAM functions MUST be configurable even in the absence of a
control plane.
3.2. Functional Requirements
In general, MPLS-TP OAM tools MUST provide functions to detect,
diagnose, localize, and notify the faults when occur. The mechanism
for correction actions trigged by fault detection SHOULD be
provided.
The following are the fault detection functional requirements
- Continuity Checks: a function to enable an End Point to monitor
the liveness of a PW, LSP, or Section.
[Page 6]
MPLS-TP OAM-Toolset March 2011
- Connectivity Verifications: a function to enable an End Point to
determine whether or not it is connected to specific End Point(s)
by means of the expected PW, LSP, or Section.
- Route Tracing: the functionality to enable an End Point to
discover the Intermediate (if any) and End Point(s) along a PW,
LSP, or Section, and more generically to trace the route of a PW,
LSP or Section.
- Diagnostic Tests: a function to enable conducting diagnostic
tests on a PW, LSP, or Section. For example, a loop-back function.
- Lock Instruct: the functionality to enable an End Point of a PW,
LSP, or Section to instruct its associated End Point(s) to lock the
PW, LSP, or Section.
- Lock Reporting: a function to enable an Intermediate Point of a
PW or LSP to report, to an End Point of that same PW or LSP, a lock
condition indirectly affecting that PW or LSP.
- Alarm Reporting: the functionality to enable an Intermediate
Point of a PW or LSP to report, to an End Point of that same PW or
LSP, a fault or defect condition indirectly affecting that PW or
LSP.
- Remote Defect Indication: a function to enable an End Point to
report, to its associated End Point, a fault or defect condition
that it detects on a PW, LSP, or Section for which they are the End
Points.
- Client Failure Indication: a function to enable the propagation,
from edge to edge of an MPLS-TP network, of information pertaining
to a client fault condition detected at an End Point of a PW or
LSP, if the client layer OAM does not provide alarm notification.
- Packet Loss Measurement: a function to enable the quantification
of packet loss ratio over a PW, LSP, or Section.
- Packet Delay Measurement: a function to enable the quantification
of the one-way, and if appropriate, the two-way, delay ratio of a
PW, LSP, or Section.
4. MPLS-TP OAM Mechanisms and Toolset Summary
The following subsections provide the summary of MPLS-TP OAM Fault
Management and Performance Management toolset, with indication of
the corresponding IETF RFCs (or Internet drafts while this document
[Page 7]
MPLS-TP OAM-Toolset March 2011
is work in progress) to support the MPLS-TP OAM functions defined
in RFC 5860.
4.1. In-band OAM Mechanisms
To meet the In-band OAM requirements for MPLS-TP, Generic
Associated Channel is created [RFC 5586]. It generalizes the
applicability of the Pseudowire (PW) Associated Channel Header
(ACH) to MPLS Label Switching Paths (LSPs), and Sections.
The Generic Associated Label (GAL) [RFC 5586] is defined by
assigning one of the reserved MPLS label values to the G-Ach, GAL
identifies the presence of the Associated Channel Header following
the label stack.
The creation of G-Ach and GAL provided the necessary mechanisms for
building in-band OAM MPLS-TP toolset.
RFC 5718 [RFC 5718] An-In-Band Data Communication Network for the
MPLS Transport Profile describes how the G-Ach may be used for
Management and Signaling Communication.
4.2. Fault Management Toolset
The following tables provide the summary of MPLS-TP OAM toolset.
Table 1 provides the summary of MPLS-TP OAM Fault Management
toolset functions, associated tool/protocol, and the corresponding
IETF RFCs or Internet drafts where they are defined.
Table 2 provides the Performance Monitoring Functions, associated
tool/protocol definitions, and the corresponding IETF RFCs or
Internet Drafts where they are defined.
The following table provide the Performance Monitoring Functions,
protocol definitions, and corresponding RFCs or Internet Drafts.
(Editor's note: only RFCs will be referenced in the final version
of the document).
[Page 8]
MPLS-TP OAM-Toolset March 2011
+----------------------------------------------------------------+
| Proactive Fault Management OAM Toolset |
|----------------------------------------------------------------|
|OAM Functions |OAM Tools/Protocols | RFCs / IDs |
|------------------|------------------------|--------------------|
|Continuity Check |Bidirectional Forwarding| draft-ietf-mpls-tp |
|(CV) & Continuity |Detection (BFD) | -cc-cv-rdi [cc-cv] |
|Verification(CV) | | |
|------------------|------------------------|--------------------|
|Remote Defect |Bidirectional Forwarding| draft-ietf-mpls-tp |
|Indication (RDI) |Detection (BFD) | -cc-cv-rdi [cc-cv] |
|------------------|------------------------|--------------------|
|Alarm Indication |AIS message under G-Ach | draft-ietf-mpls-tp |
|Signal (AIS) | | -fault [fault] |
|------------------|------------------------|--------------------|
|Link Down |Flag in AIS message | draft-ietf-mpls-tp |
|Indication (LDI) | | -fault [fault] |
|------------------|------------------------|--------------------|
|Lock Report (LKR) |LKR message under G-Ach | draft-ietf-mpls-tp |
| | | -fault [fault] |
+----------------------------------------------------------------+
Table 1. Proactive Fault Management OAM Toolset
+----------------------------------------------------------------+
| On Demand Fault Management OAM Toolset |
|----------------------------------------------------------------|
|OAM Functions |OAM Tools/Protocols | RFCs / IDs |
|------------------|------------------------|--------------------|
|Continuity |LSP Ping and BFD | draft-ietf-mpls-tp |
|Verification(CV) | | -cc-cv-rdi [cc-cv] |
|------------------|------------------------|--------------------|
|Diagnostic: |1) In-band Loopback | draft-ietf-mpls-tp |
|Loopback, Lock | and Lock Instruct | -li-lb [li-lb] |
|and LSP Ping |2) LSP Ping | |
|------------------|------------------------|--------------------|
|Lock Instruct | In-band lock message | draft-ietf-mpls-tp |
|(LI) | in G-Ach | -li-lb [li-lb] |
+----------------------------------------------------------------+
Table 2. On Demand Fault Management OAM Toolset
[Page 9]
MPLS-TP OAM-Toolset March 2011
4.3. Performance Monitoring Toolset
Table 3 provides the Performance Monitoring Fuctions, protocol
definitions, and corresponding RFCs or Internet Drafts.
+----------------------------------------------------------------+
| Performance Monitoring OAM Toolset |
|----------------------------------------------------------------|
|OAM Functions |Protocols Definitions | RFCs / IDs |
|------------------|------------------------|--------------------|
|Packet loss |LM & DM query messages | draft-ietf-mpls-tp |
|measurement (LM) | | -loss-delay [lo-de]|
|------------------|------------------------| |
|Packet delay (DM) |LM & DM query messages | draft-ietf-mpls-tp |
|measurement | | -loss-delay |
|------------------|------------------------|-profile [tp-lo-de] |
|Throughput |derived from Loss | |
|measurement |measurement | |
|------------------|------------------------| |
|Delay Variation |Supported from Delay | |
|measurement |measurement | |
+----------------------------------------------------------------+
Table 3. Performance Monitoring OAM Toolset
5. OAM Toolset Utilization and Protocol Definitions
5.1. Connectivity Check and Connectivity Verification
Continuity Check (CC) and Proactive Connectivity Verification (CV)
functions are used to detect loss of continuity (LOC), and
unintended connectivity between two MEPs.
Loss of connectivity, mis-merging, mis-connectivity, or unexpected
Maintenance Entity Group End Points (MEPs) can be detected using
the CC/CV tools.
The CC/CV tools are used to support MPLS-TP fault management,
performance management, and protection switching.
Bidirectional Forwarding Detection (BFD) and LSP Ping are defined
to support the CC/CV functions [cc-cv].
BFD control packets are sent by the source MEP to sink MEP. The
sink MEP monitors the arrival of the BFD control packets and
detects the defect.
The interval of BFD control packet can be configured. For example:
[Page 10]
MPLS-TP OAM-Toolset March 2011
- 3.3ms is the default interval for protection switching.
- 100ms is the default interval for performance monitoring.
- 1s is the default interval for fault management.
5.2. Diagnostic Tests and Lock Instruct
The OAM functions to support diagnostic tests are required in the
transport environment.
The Loopback mode is defined for management purpose in [li-lb]. The
mechanism is provided to Lock and unlock traffic (e.g. data and
control traffic) or specific OAM traffic at a specific LSR on the
path of the MPLS-TP LSP to allow loop back it to the source by [li-
lb].
These diagnostic functions apply to associated bidirectional MPLS-
TP LSPs, including MPLS-TP LSPs, bi-directional RSVP-TE tunnels
(which is relevant for MPLS-TP dynamic control plane option with
GMPLS), and single segment and multi-segment pseudowires.
The Lock operation instruction is carried in an MPLS Loopback
request message sent from a MEP to a trail-end MEP of the LSP to
request that the LSP be taken out of service. In response, the
Lock operation reply is carried in a Loopback response message sent
from the trail-end MEP back to the originating MEP to report the
result.
The loopback operations include [li-lb]:
- Lock: take an LSP out of service for maintenance.
- Unlock: Restore a previously locked LSP to service.
- Set_Full_Loopback and Set_OAM_Loopback
- Unset_Full_Loopback and Set_OAM_Loopback
Operators can use the loopback mode to test the connectivity or
performance (loss, delay, delay variation, and throughput) of given
LSP upto a specific node on the path of the LSP.
5.3. Lock Reporting
The Lock Report (LKR) function is used to communicate to the client
(sub-) layer MEPs the administrative locking of a server (sub-)
layer MEP, and consequential interruption of data traffic
forwarding in the client (sub-) layer [fault].
When operator is taking the LSP out of service for maintenance
other operational reason, using the LKR function can help to
[Page 11]
MPLS-TP OAM-Toolset March 2011
distinguish the condition as administrative locking from defect
condition.
The Lock Report function would also serve the purpose of alarm
suppression in the MPLS-TP network above the level of the Lock is
occurred. The receipt of an LKR message MAY be treated as the
equivalent of loss of continuity at the client layer [fault].
5.4. Alarm Reporting and Link down Indication
Alarm Indication Signal (AIS) message serves the purpose of alarm
suppression upon the failure detection in the server (-sub) layer.
When the Link Down Indication (RDI) is set, the AIS message MAY be
used to trigger recovery mechanisms [fault].
When a server MEP detects the failure, it asserts Loss of
Continuity (LOC) or signal fail which sets the flag up to generate
OAM packet with AIS message. The AIS message is forwarded to
downstream sink MEP in the client layer. This would enable the
client layer to suppress the generation of secondary alarms.
A Link Down Indication (LDI) flag is defined in the AIS message.
The LDI flag is set in the AIS message in response to detecting a
fatal failure in the server layer. Receipt of an AIS message with
this flag set MAY be interpreted by a MEP as an indication of
signal fail at the client layer. [fault]
Fault OAM messages are generated by intermediate nodes where an LSP
is switched, and propagated to the end points (MEPs).
From practical point of view, when both proactive CC functions and
LDI are used, one may consider to run the proactive CC functions at
a slower rate (e.g. longer BFD hello intervals), and reply on LDI
to trigger fast protection switch over upon failure detection in a
given LSP.
5.5. Remote Defect Indication
Remote Defect Indication (RDI) function enables an End Point to
report to the other End Point that a fault or defect condition is
detected on the PW, LSP, or Section they are the End Points.
The RDI OAM function is supported by the use of Bidirectional
Forwarding Detection (BFD) Control Packets [cc-cv]. RDI is only
used for bidirectional connections and is associated with proactive
CC/CV activation.
[Page 12]
MPLS-TP OAM-Toolset March 2011
When an end point (MEP) detects a signal failure condition, it sets
the flag up by setting the diagnostic field of the BFD control
packet to a particular value to indicate the failure condition on
the associated PW, LSP, or Section, and transmitting the BFD
control packet with the failure flag up to the other end point (its
peer MEP).
RDI function can be used to facilitate the protection switching by
synchronizing the two end points when unidirectional failure occurs
and is detected by one end.
5.6. Packet Loss and Delay Measurement
Packet loss and delay measurement toolset enables operators to
measure the quality of the packet transmission over a PW, LSP, or
Section.
The protocol for MPLS-TP loss and delay measurement functions is
defined in [lo-de] as profiled in [tp-lo-de]. These documents
specify how to measure Packet Loss, Packet Delay, Packet Delay
Variation, and Throughput.
The loss and delay protocols have the following characteristics and
capabilities:
- Support measurement of packet loss, delay and throughput
over Label Switched Paths (LSPs), pseudowires, and MPLS
sections (links).
- The same LM and DM protocols can be used for both
continuous/proactive and selective/on-demand measurement.
- The LM and DM protocols use a simple query/response model
for bidirectional measurement that allows a single node -
the querier - to measure the loss or delay in both
directions.
- The LM and DM protocols use query messages for
unidirectional loss and delay measurement. The measurement
can either be carried out at the downstream node(s) or at
the querier if an out-of-band return path is available.
- The LM and DM protocols do not require that the transmit and
receive interfaces be the same when performing bidirectional
measurement.
[Page 13]
MPLS-TP OAM-Toolset March 2011
- The LM protocol supports both 32-bit and 64-bit counters
although for simplicity only 32-bit packet counters are
currently included in the MPLS-TP profile.
- The LM protocol supports measurement in terms of both packet
counts and octet counts although for simplicity only packet
counters are currently included in the MPLS-TP profile.
- The LM protocol can be used to measure channel throughput as
well as packet loss.
- The DM protocol supports varying the measurement message
size in order to measure delays associated with different
packet sizes.
6. IANA assigned code points under G-Ach
OAM toolset/functions defined under G-Ach MUST use IANA assigned
code points, using Experimental Code Point under G-Ach is
inappropriate and it can lead to interoperability problems and
potential Code Point collision in production network.
RFC 5586 "MPLS Generic Associated Channel" stated the following in
IANA consideration section: A requirement has emerged (see [RFC
5860]) to allow for optimizations or extensions to OAM and other
control protocols running in an associated channel to be
experimented without resorting to the IETF standards process, by
supporting experimental code points. This would prevent code points
used for such functions from being used from the range allocated
through the IETF standards and thus protects an installed base of
equipment from potential inadvertent overloading of code points.
In order to support this requirement, IANA has changed the code
point allocation scheme for the PW Associated Channel as follows:
0 - 32751: IETF Review
32760 - 32767: Experimental
Code points in the experimental range MUST be used according to the
guidelines of RFC 3692 [RFC 3692]. Functions using experimental G-
Ach code points MUST be disabled by default.
The guidelines on the usage of experimental numbers are defined in
IETF RFC 3692. As indicated by RFC 3692: The experimental numbers
are useful when experimenting new protocols or extending existing
protocols in order to test and experiment with the new functions, as
part of implementation. RFC 3692 reserves a range of numbers for
[Page 14]
MPLS-TP OAM-Toolset March 2011
experimentation when the need of such experimentation has been
identified.
However, the experimental numbers "are reserved for generic testing
purposes, and other implementations may use the same numbers for
different experimental uses." "Experimental numbers are intended for
experimentation and testing and are not intended for wide or general
deployments." "Shipping a product with a specific value pre-enabled
would be inappropriate and can lead to interoperability problems
when the chosen value collides with a different usage, as it someday
surely will."
Further more, "it would be inappropriate for a group of vendors, a
consortia, or another Standards Development Organization to agree
among themselves to use a particular value for a specific purpose
and then agree to deploy devices using those values." Experimental
numbers are not guaranteed to be unique by definition. There is the
risk of code point collision when using Experimental Code Point in
production networks.
Similar statements can also be found in RFC4929 "Change Process for
Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Protocols and Procedures". As described in [RFC 4775], "non-
standard extensions, including experimental values, are not to be
portrayed as industrial standards whether by an individual vendor,
an industry forum, or a standards body."
7. Security Considerations
The document provides overview of MPLS-TP OAM requirements,
functions, protocol, and solution considerations. The actual
protocols for the OAM toolset are defined in separate documents and
referenced by this document.
The general security considerations are provided in Security
Framework for MPLS and GMPLS Networks [RFC 5920], and MPLS-TP
Security Framework [tp-sec-fr].
8. IANA Considerations
This document contains no new IANA considerations.
9. Normative References
[Page 15]
MPLS-TP OAM-Toolset March 2011
[RFC 5586], M. Bocci, M. Vigoureux, S. Bryant, "MPLS Generic
Associated Channel",RFC 5586, June 2009.
[RFC 5654], Niven-Jenkins, B., et al, "MPLS-TP Requirements", RFC
5654, September 2009.
[RFC 5718], D. Beller, and A. Farrel, "An In-Band Data
Communication Network For the MPLS Transport Profile", RFC 5718,
Jan 2010.
[RFC 5860], M. Vigoureux, D. Ward, M. Betts, "Requirements for
Operations, Administration, and Maintenance (OAM) in MPLS Transport
Networks", RFC 5860, May 2010.
[cc-cv] D. Allan, G. Swallow, J. Drake, Proactive Connectivity
Verification, Continuity Check and Remote Defect indication for
MPLS Transport Profile, draft-ietf-mpls-tp-cc-cv-rdi-03, Feb. 2011.
[fault] G. Swallow, A. Fulignoli, M. Vigoureux, MPLS Fault
Management OAM, draft-ietf-mpls-tp-fault-01, March 2011.
[li-lb] S. Boutros, S. Sivabalan, et,al., MPLS Transport Profile
Lock Instruct and Loopback Functions draft-ietf-mpls-tp-li-lb-
01.txt, March 2011.
[loopback] S. Boutros, S. Sivabalan, G. Swallow, R. Aggarwal, M.
Vigoureux, Operating MPLS Transport Profile LSP in Loopback Mode,
draft-boutros-mpls-tp-loopback-03.txt, March 2011.
[lo-de] D. Frost, S. Bryant, Packet Loss and Delay Measurement for
the MPLS Networks, draft-ietf-mpls-loss-delay-01, Feb. 2011.
[tp-lo-de] D. Frost, S. Bryant, A Packet Loss and Delay Measurement
Profile for MPLS-based Transport Networks, draft-frost-mpls-tp-loss-
delay-profile-02, Feb. 2011.
10. Informative References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[RFC 3692] T. Narten, "Assigning Experimental and Testing Numbers
Considered Useful", RFC 3692, Jan. 2004.
[RFC 4775] S. Bradner, "Procedures for Protocol Extensions and
Variations", RFC 4775, Dec. 2006.
[Page 16]
MPLS-TP OAM-Toolset March 2011
[RFC 5920] L. Fang, et al, Security Framework for MPLS and GMPLS
Networks, July 2010.
[MPLS-TP NM REQ] Hing-Kam Lam, Scott Mansfield, Eric Gray, MPLS TP
Network Management Requirements, draft-ietf-mpls-tp-nm-req-06.txt,
October 2009.
[tp-sec-fr] L. Fang, Niven-Jenkins, S. Mansfield, et. Al. MPLS-TP
Security Framework, draft-ietf-mpls-tp-security-framework-00, Feb.
2011.
11. Authors' Addresses
Luyuan Fang
Cisco Systems
111 Wood Avenue South
Iselin, NJ 08830
USA
Email: lufang@cisco.com
Dan Frost
Cisco Systems
Email: danfrost@cisco.com
Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02145
USA
Email: nabil.bitar@verizon.com
Raymond Zhang
British Telecom
BT Center
81 Newgate Street
London, EC1A 7AJ
United Kingdom
Email: raymond.zhang@bt.com
Lei Wang
Telenor
Telenor Norway
Office Snaroyveien
1331 Fornedbu
Email: Lei.wang@telenor.com
Kam Lee Yap
[Page 17]
MPLS-TP OAM-Toolset March 2011
XO Communications
13865 Sunrise Valley Drive,
Herndon, VA 20171
Email: klyap@xo.com
Michael Fargano
Qwest
5325 Zuni St, 224
Denver CO 80221-1499
Email: Michael.Fargano@qwest.com
John Drake
Juniper
Email: jdrake@juniper.net
Thomas Nadeau
Email: tnadeau@lucidvision.com
[Page 18]
