Network Working Group Luyuan Fang
Internet Draft Dan Frost
Intended status: Informational Cisco Systems
Expires: September 07, 2011 Raymond Zhang
BT
Nabil Bitar
Verizon
Lei Wang
Telenor
Masahiro Daikoku
KDDI
March 7, 2011
MPLS-TP OAM Toolset
draft-fang-mpls-tp-oam-toolset-00.txt
Abstract
This document provides an overview of MPLS-TP OAM tools, including
MPLS-TP OAM functions, generic mechanisms for supporting MPLS-TP
OAM; MPLS-TP Fault management tools; and Performance Management
tools defined in IETF, OAM toolset utilization, and IANA assigned
code point under G-Ach discussion. 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 this document references.
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
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 07, 2011.
[Page 1]
MPLS-TP OAM-Toolset March 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 ....................
8
4.1. In-band OAM Mechanisms .....................................
8
4.2. Fault Management Toolset ...................................
8
4.3. Performance Monitoring Toolset .............................
9
5. OAM Toolset Functionalities and Utilization ..................
10
5.1. Connectivity Verifications ................................
10
5.2. Route Tracing .............................................
10
5.3. Diagnostic Tests ..........................................
11
5.4. Lock Instruct .............................................
11
5.5. Lock Reporting ............................................
11
5.6. Alarm Reporting ...........................................
11
5.7. Remote Defect .............................................
11
5.8. Client Failure ............................................
11
5.9. Packet Loss Measurement ...................................
11
5.10. Packet Delay Measurement ..................................
11
6. IANA assigned code points under G-Ach ........................
11
7. Security Considerations ......................................
12
8. IANA Considerations ..........................................
12
9. Normative References .........................................
13
10. Informative References
......................................
13
11. Author's Addresses
..........................................
14
[Page 2]
MPLS-TP OAM-Toolset March 2011
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 MPLS-TP OAM tools, including
MPLS-TP OAM functions, generic mechanisms for supporting MPLS-TP
OAM; MPLS-TP Fault management tools; and Performance Management
tools, OAM toolset utilization, and IANA assigned code point under
G-Ach consideration.
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) this document references.
2. Terminology
This document uses MPLS-TP OAM specific terminology.
Term Definition
----------------------------------------------------
AC Attachment Circuit
AIS Alarm indication signal
APS Automatic Protection Switching
ATM Asynchronous Transfer Mode
[Page 3]
MPLS-TP OAM-Toolset March 2011
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
L-LSP Label-Only-Inferred-PSC LSP
LM Loss Measurement
LMEG LSP ME Group
LSP Label Switched PathLSR Label Switching Router
LSME LSP SPME ME
LSMEG LSP SPME ME Group
ME Maintenance Entity
MEG Maintenance Entity Group
MEP Maintenance Entity Group End Point
MIP Maintenance Entity Group Intermediate Point
[Page 4]
MPLS-TP OAM-Toolset March 2011
MPLS MultiProtocol Label Switching
NMS Network Management System
NTP Network Time Protocol
OAM Operations, Administration, and Management
PE Provider Edge
PHB Per-hop Behavior
PM Performance Monitoring
PME PW Maintenance Entity
PMEG PW ME Group
PSC PHB Scheduling Class
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 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, support
LSPs and PWs in single domain and across 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.
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 operate OAM functions with or without relying on
IP capabilities.
It is REQUIRED that OAM interoperability is 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
[Page 6]
MPLS-TP OAM-Toolset March 2011
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.
- 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.
- 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 Loss Measurement: a function to enable the quantification
of the one-way, and the two-way, delay ratio over a PW, LSP, or
Section.
[Page 7]
MPLS-TP OAM-Toolset March 2011
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
is work in progress) to support the MPLS OAM functionalities
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 enable a control chancel associated to MPLS Label
Switching Paths in addition to PW.
The Generic Associated Label (GAL) is defined by assigning one of
the reserved MPLS label values to the G-Ach, to allow the
identification of the Associated Channel Header in the label stack.
The creation of G-Ach and GAL provided the necessary mechanisms for
building in-band OAM MPLS-TP toolset.
RFC 5586 [RFC 5586] An-In-Band Data Communication Network for the
MPLS Transport Profile describes how the G-Ach may be used to for
Management Communication and Signaling Communication.
4.2. Fault Management Toolset
The following tables provide the summary of MPLS-TP OAM Fault
Management toolset functions, protocol definitions, and the IETF
RFCs or Internet drafts.
The following table provide the Performance Monitoring Functions,
protocol definitions, and corresponding RFCs or Internet Drafts.
(Editor's note: only RFCs are referenced in the final version of
the document).
[Page 8]
MPLS-TP OAM-Toolset March 2011
+----------------------------------------------------------------+
| Proactive Fault Management OAM Toolset |
|----------------------------------------------------------------|
|OAM Functions |Protocols Definitions | 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 |
|------------------|------------------------|--------------------|
|Alarm Indication |AIS message under G-Ach | draft-ietf-mpls-tp |
|Signal (AIS) | | -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 |
+----------------------------------------------------------------+
Table 1. Proactive Fault Management OAM Toolset
+----------------------------------------------------------------+
| On Demand Fault Management OAM Toolset |
|----------------------------------------------------------------|
|OAM Functions |Protocols Definitions | RFCs / IDs |
|------------------|------------------------|--------------------|
|Continuity |LSP Ping and BFD | draft-ietf-mpls-tp |
|Verification(CV) | | -cc-cv-rdi |
|------------------|------------------------|--------------------|
|Loopback |1) In-band Loopback | draft-ietf-mpls-tp |
|(LBM/LBR) | in G-Ach | -li-lb [li-lb] |
| |2) LSP Ping | |
|------------------|------------------------|--------------------|
|Lock Instruct | In-band lock message | draft-ietf-mpls-tp |
|(LI) | in G-Ach | -li-lb |
+----------------------------------------------------------------+
Table 2. On Demand Fault Management OAM Toolset
4.3. Performance Monitoring Toolset
[Page 9]
MPLS-TP OAM-Toolset March 2011
The following table provide 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 |
|(LBM/LBR) | | -loss-delay |
|measurement | | -profile [lo-de-p] |
|------------------|------------------------| |
|Throughput |Supported by LM | |
|measurement | | |
|------------------|------------------------| |
|Delay Variation |Supported by DM | |
|measurement | | |
+----------------------------------------------------------------+
Table 3. Performance Monitoring OAM Toolset
5. OAM Toolset Functionalities and Utilization
(to be filled)
5.1. Connectivity Verifications
5.2. Route Tracing
[Page 10]
MPLS-TP OAM-Toolset March 2011
5.3. Diagnostic Tests
5.4. Lock Instruct
5.5. Lock Reporting
5.6. Alarm Reporting
5.7. Remote Defect
5.8. Client Failure
5.9. Packet Loss Measurement
5.10. Packet Delay Measurement
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 Type be
changed 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
[Page 11]
MPLS-TP OAM-Toolset March 2011
protocols in order to test and experiment the new functions, as part
of implementation. RFC 3692 reserves a range of numbers for
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 on MPLS-TP OAM requirements,
functions, protocol definitions, 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 MPLS-TP
Security Framework. [tp-sec-fr]
8. IANA Considerations
This document contains no new IANA considerations.
[Page 12]
MPLS-TP OAM-Toolset March 2011
9. Normative References
[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.
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.
[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.
[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.
[lo-de] D. Frost, S. Bryant, Packet Loss and Delay Measurement for
the MPLS Transport Profile, June 2010.
[Page 13]
MPLS-TP OAM-Toolset March 2011
[lo-de-p] D. Frost, S. Bryant, A Packet Loss and Delay Measurement
Profile for MPLS-based Transport Networks, draft-frost-mpls-tp-loss-
delay-profile-00, Dec. 2010.
[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. Author's 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
Raymond Zhang
British Telecom
BT Center
81 Newgate Street
London, EC1A 7AJ
United Kingdom
Email: raymond.zhang@bt.com
Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02145
USA
Email: nabil.bitar@verizon.com
Lei Wang
Telenor
Telenor Norway
Office Snaroyveien
1331 Fornedbu
Email: Lei.wang@telenor.com
Masahiro DAIKOKU
KDDI corporation
3-11-11.Iidabashi, Chiyodaku, Tokyo
Japan
Email: ms-daikoku@kddi.com
[Page 14]
MPLS-TP OAM-Toolset March 2011
[Page 15]