< draft-fang-mpls-tp-oam-toolset-00.txt		draft-fang-mpls-tp-oam-toolset-01.txt >
	Network Working Group Luyuan Fang		Network Working Group Luyuan Fang
	Internet Draft Dan Frost		Internet Draft Dan Frost
	Intended status: Informational Cisco Systems		Intended status: Informational Cisco Systems
	Expires: September 07, 2011 Raymond Zhang		Expires: September 14, 2011 Nabil Bitar
	BT
	Nabil Bitar
	Verizon		Verizon
			Raymond Zhang
			BT
	Lei Wang		Lei Wang
	Telenor		Telenor
	Masahiro Daikoku		Kam Lee Yap
	KDDI		XO Communications
			Michael Fargano
			Qwest
			John Drake
			Juniper
			Thomas Nadeau
	March 7, 2011		March 14, 2011
	MPLS-TP OAM Toolset		MPLS-TP OAM Toolset
	draft-fang-mpls-tp-oam-toolset-00.txt		draft-fang-mpls-tp-oam-toolset-01.txt
	Abstract		Abstract
	This document provides an overview of MPLS-TP OAM tools, including		This document provides an overview of the MPLS-TP OAM toolset,
	MPLS-TP OAM functions, generic mechanisms for supporting MPLS-TP		which consists of MPLS-TP fault management and performance
	OAM; MPLS-TP Fault management tools; and Performance Management		monitoring. This overview includes a brief recap of MPLS-TP OAM
	tools defined in IETF, OAM toolset utilization, and IANA assigned		requirements and functions, and of the generic mechanisms created
	code point under G-Ach discussion. The protocol definitions for		in the MPLS data plane to support in-band OAM. The importance of
	each individual MPLS-TP OAM tool are specified in separate RFCs (or		using IANA assigned code point under G-Ach when supporting MPLS-TP
	Working Group documents while this document is work in progress)		OAM is also discussed. The protocol definitions for each individual
	which this document references.		MPLS-TP OAM tool are specified in separate RFCs or Working Group
			documents which are referenced by this document.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with		This Internet-Draft is submitted to IETF in full conformance with
	the provisions of BCP 78 and BCP 79.		the provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as reference		at any time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress.		material or to cite them other than as "work in progress.
	This Internet-Draft will expire on September 07, 2011.		This Internet-Draft will expire on September 14, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with		carefully, as they describe your rights and restrictions with
	respect to this document. Code Components extracted from this		respect to this document. Code Components extracted from this
	document must include Simplified BSD License text as described in		document must include Simplified BSD License text as described in
	Section 4.e of the Trust Legal Provisions and are provided without		Section 4.e of the Trust Legal Provisions and are provided without
	warranty as described in the Simplified BSD License..		warranty as described in the Simplified BSD License..
	Table of Contents		Table of Contents
	1. Introduction ..................................................		1. Introduction ..................................................3
	3		2. Terminology ...................................................3
	2. Terminology ...................................................		3. Brief Overview of MPLS-TP OAM Requirements ....................6
	3		3.1. Architectural Requirements .................................6
	3. Brief Overview of MPLS-TP OAM Requirements ....................		3.2. Functional Requirements ....................................6
	6		4. MPLS-TP OAM Mechanisms and Toolset Summary ....................7
	3.1. Architectural Requirements .................................		4.1. In-band OAM Mechanisms .....................................8
	6		4.2. Fault Management Toolset ...................................8
	3.2. Functional Requirements ....................................		4.3. Performance Monitoring Toolset ............................10
	6		5. OAM Toolset Utilization and Protocol Definitions .............10
	4. MPLS-TP OAM Mechanisms and Toolset Summary ....................		5.1. Connectivity Check and Connectivity Verification ..........10
	8		5.2 Diagnostic Tests and Lock Instruct. .......................11
	4.1. In-band OAM Mechanisms .....................................		5.3. Lock Reporting ............................................11
	8		5.4. Alarm Reporting and Link down Indication ..................12
	4.2. Fault Management Toolset ...................................		5.5. Remote Defect Indication ..................................12
	8		5.6. Packet Loss and Delay Measurement .........................13
	4.3. Performance Monitoring Toolset .............................		6. IANA assigned code points under G-Ach ........................14
	9		7. Security Considerations ......................................15
	5. OAM Toolset Functionalities and Utilization ..................		8. IANA Considerations ..........................................15
	10		9. Normative References .........................................15
	5.1. Connectivity Verifications ................................		10. Informative References .....................................16
	10		11. Authors' Addresses..........................................17
	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 ...................................
	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
	Requirements Language		Requirements Language
	Although this document is not a protocol specification, the key		Although this document is not a protocol specification, the key
	words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	this document are to be interpreted as described in RFC 2119 [RFC		this document are to be interpreted as described in RFC 2119 [RFC
	2119].		2119].
	1. Introduction		1. Introduction
	The Operations, Administration, and Maintenance (OAM) Requirements		The Operations, Administration, and Maintenance (OAM) Requirements
	for Transport Profile of Multiprotocol Label Switching (MPLS-TP)		for Transport Profile of Multiprotocol Label Switching (MPLS-TP)
	networks are defined in RFC 5860 [RFC 5860]. MPLS-TP OAM mechanisms		networks are defined in RFC 5860 [RFC 5860]. MPLS-TP OAM mechanisms
	and multiple OAM tools have been developed based on MPLS-TP OAM		and multiple OAM tools have been developed based on MPLS-TP OAM
	requirements.		requirements.
	This document provides an overview of MPLS-TP OAM tools, including		This document provides an overview of the MPLS-TP OAM toolset,
	MPLS-TP OAM functions, generic mechanisms for supporting MPLS-TP		which consists of MPLS-TP fault management and performance
	OAM; MPLS-TP Fault management tools; and Performance Management		monitoring. This overview includes a brief recap of MPLS-TP OAM
	tools, OAM toolset utilization, and IANA assigned code point under		requirements and functions, and of the generic mechanisms created
	G-Ach consideration.		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		The protocol definitions for each individual MPLS-TP OAM tool are
	defined in separate RFCs (or Working Group documents while this		defined in separate RFCs (or Working Group documents while this
	document is work in progress) this document references.		document is work in progress) referenced by this document.
	2. Terminology		2. Terminology
	This document uses MPLS-TP OAM specific terminology.		This document uses MPLS-TP OAM specific terminology.
	Term Definition		Term Definition
	----------------------------------------------------		----------------------------------------------------
	AC Attachment Circuit		AC Attachment Circuit
	AIS Alarm indication signal		AIS Alarm indication signal
	APS Automatic Protection Switching		APS Automatic Protection Switching
	ATM Asynchronous Transfer Mode		ATM Asynchronous Transfer Mode
	BFD Bidirectional Forwarding Detection		BFD Bidirectional Forwarding Detection
	CC Continuity Check		CC Continuity Check
	CE Customer-Edge device		CE Customer-Edge device
	CM Configuration Management		CM Configuration Management
	CoS Class of Service		CoS Class of Service
	skipping to change at page 4, line 32 ¶		skipping to change at page 4, line 36 ¶
	GMPLS Generalized Multi-Protocol Label Switching		GMPLS Generalized Multi-Protocol Label Switching
	LDI Link Down Indication		LDI Link Down Indication
	LDP Label Distribution Protocol		LDP Label Distribution Protocol
	LER Label Edge Router		LER Label Edge Router
	LKR Lock Report		LKR Lock Report
	L-LSP Label-Only-Inferred-PSC LSP
	LM Loss Measurement		LM Loss Measurement
	LMEG LSP ME Group		LMEG LSP ME Group
	LSP Label Switched PathLSR Label Switching Router		LOC Loss of Continuity
			LSP Label Switched Path
			LSR Label Switching Router
	LSME LSP SPME ME		LSME LSP SPME ME
	LSMEG LSP SPME ME Group		LSMEG LSP SPME ME Group
	ME Maintenance Entity		ME Maintenance Entity
	MEG Maintenance Entity Group		MEG Maintenance Entity Group
	MEP Maintenance Entity Group End Point		MEP Maintenance Entity Group End Point
	MIP Maintenance Entity Group Intermediate Point		MIP Maintenance Entity Group Intermediate Point
	MPLS MultiProtocol Label Switching		MPLS MultiProtocol Label Switching
	NMS Network Management System		NMS Network Management System
	NTP Network Time Protocol		NTP Network Time Protocol
	OAM Operations, Administration, and Management		OAM Operations, Administration, and Management
	PE Provider Edge		PE Provider Edge
	PHB Per-hop Behavior
	PM Performance Monitoring		PM Performance Monitoring
	PME PW Maintenance Entity		PME PW Maintenance Entity
	PMEG PW ME Group		PMEG PW ME Group
	PSC PHB Scheduling Class
	PSME PW SPME ME		PSME PW SPME ME
	PSMEG PW SPME ME Group		PSMEG PW SPME ME Group
	PW Pseudowire		PW Pseudowire
	QoS Quality of Service		QoS Quality of Service
	RDI Remote Defect Indication		RDI Remote Defect Indication
	skipping to change at page 6, line 14 ¶		skipping to change at page 6, line 14 ¶
	T-PE Terminating Provider Edge		T-PE Terminating Provider Edge
	3. Brief Overview of MPLS-TP OAM Requirements		3. Brief Overview of MPLS-TP OAM Requirements
	This following Architectural and Functional Requirements are		This following Architectural and Functional Requirements are
	defined by RFC 5860. They are captured here for easy reading before		defined by RFC 5860. They are captured here for easy reading before
	discussing the toolset.		discussing the toolset.
	3.1. Architectural Requirements		3.1. Architectural Requirements
	The MPLS OAM Supports point-to-point bidirectional PWs, point-to-		The MPLS-TP OAM Supports point-to-point bidirectional PWs, point-
	point co-routed bidirectional LSPs, point-to-point bidirectional		to-point co-routed bidirectional LSPs, point-to-point bidirectional
	Sections, point-to-point associated bidirectional LSPs, point-to-		Sections, point-to-point associated bidirectional LSPs, point-to-
	point unidirectional LSPs, and point-to-multipoint LSPs, support		point unidirectional LSPs, and point-to-multipoint LSPs. In
	LSPs and PWs in single domain and across domains.		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.
	The protocol solution(s) SHOULD be independent of the underlying		The protocol solution(s) SHOULD be independent of the underlying
	tunneling or point-to-point technology or transmission media. The		tunneling or point-to-point technology or transmission media. The
	protocol solution(s) SHOULD be independent of the service a PW may		protocol solution(s) SHOULD be independent of the service a PW may
	emulate.		emulate.
	In-band OAM MUST be implemented. OAM packets for a specific PW,		In-band OAM MUST be implemented. OAM packets for a specific PW,
	LSP, or Section MUST follow the exact same data path as user		LSP, or Section MUST follow the exact same data path as user
	traffic of the same.		traffic of the same.
	The solutions MUST operate OAM functions with or without relying on		The solutions MUST support OAM functions with or without relying on
	IP capabilities.		IP capabilities.
	It is REQUIRED that OAM interoperability is achieved between		It is REQUIRED that OAM interoperability be achieved between
	distinct domains with different operational models, e.g. with IP or		distinct domains with different operational models, e.g. with IP or
	without IP support in the data plane.		without IP support in the data plane.
	And OAM functions MUST be configurable even in the absence of a		And OAM functions MUST be configurable even in the absence of a
	control plane.		control plane.
	3.2. Functional Requirements		3.2. Functional Requirements
	In general, MPLS-TP OAM tools MUST provide functions to detect,		In general, MPLS-TP OAM tools MUST provide functions to detect,
	diagnose, localize, and notify the faults when occur. The mechanism		diagnose, localize, and notify the faults when occur. The mechanism
	skipping to change at page 7, line 18 ¶		skipping to change at page 7, line 11 ¶
	- Continuity Checks: a function to enable an End Point to monitor		- Continuity Checks: a function to enable an End Point to monitor
	the liveness of a PW, LSP, or Section.		the liveness of a PW, LSP, or Section.
	- Connectivity Verifications: a function to enable an End Point to		- Connectivity Verifications: a function to enable an End Point to
	determine whether or not it is connected to specific End Point(s)		determine whether or not it is connected to specific End Point(s)
	by means of the expected PW, LSP, or Section.		by means of the expected PW, LSP, or Section.
	- Route Tracing: the functionality to enable an End Point to		- Route Tracing: the functionality to enable an End Point to
	discover the Intermediate (if any) and End Point(s) along a PW,		discover the Intermediate (if any) and End Point(s) along a PW,
	LSP, or Section.		LSP, or Section, and more generically to trace the route of a PW,
			LSP or Section.
	- Diagnostic Tests: a function to enable conducting diagnostic		- Diagnostic Tests: a function to enable conducting diagnostic
	tests on a PW, LSP, or Section. For example, a loop-back function.		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,		- 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		LSP, or Section to instruct its associated End Point(s) to lock the
	PW, LSP, or Section.		PW, LSP, or Section.
	- Lock Reporting: a function to enable an Intermediate Point of a		- 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		PW or LSP to report, to an End Point of that same PW or LSP, a lock
	skipping to change at page 7, line 49 ¶		skipping to change at page 7, line 43 ¶
	Points.		Points.
	- Client Failure Indication: a function to enable the propagation,		- Client Failure Indication: a function to enable the propagation,
	from edge to edge of an MPLS-TP network, of information pertaining		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		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.		LSP, if the client layer OAM does not provide alarm notification.
	- Packet Loss Measurement: a function to enable the quantification		- Packet Loss Measurement: a function to enable the quantification
	of packet loss ratio over a PW, LSP, or Section.		of packet loss ratio over a PW, LSP, or Section.
	- Packet Loss Measurement: a function to enable the quantification		- Packet Delay Measurement: a function to enable the quantification
	of the one-way, and the two-way, delay ratio over a PW, LSP, or		of the one-way, and if appropriate, the two-way, delay ratio of a
	Section.		PW, LSP, or Section.
	4. MPLS-TP OAM Mechanisms and Toolset Summary		4. MPLS-TP OAM Mechanisms and Toolset Summary
	The following subsections provide the summary of MPLS-TP OAM Fault		The following subsections provide the summary of MPLS-TP OAM Fault
	Management and Performance Management toolset, with indication of		Management and Performance Management toolset, with indication of
	the corresponding IETF RFCs (or Internet drafts while this document		the corresponding IETF RFCs (or Internet drafts while this document
	is work in progress) to support the MPLS OAM functionalities		is work in progress) to support the MPLS-TP OAM functions defined
	defined in RFC 5860.		in RFC 5860.
	4.1. In-band OAM Mechanisms		4.1. In-band OAM Mechanisms
	To meet the In-band OAM requirements for MPLS-TP, Generic		To meet the In-band OAM requirements for MPLS-TP, Generic
	Associated Channel is created [RFC 5586]. It generalizes the		Associated Channel is created [RFC 5586]. It generalizes the
	applicability of the Pseudowire (PW) Associated Channel Header		applicability of the Pseudowire (PW) Associated Channel Header
	(ACH) to enable a control chancel associated to MPLS Label		(ACH) to MPLS Label Switching Paths (LSPs), and Sections.
	Switching Paths in addition to PW.
	The Generic Associated Label (GAL) is defined by assigning one of		The Generic Associated Label (GAL) [RFC 5586] is defined by
	the reserved MPLS label values to the G-Ach, to allow the		assigning one of the reserved MPLS label values to the G-Ach, GAL
	identification of the Associated Channel Header in the label stack.		identifies the presence of the Associated Channel Header following
			the label stack.
	The creation of G-Ach and GAL provided the necessary mechanisms for		The creation of G-Ach and GAL provided the necessary mechanisms for
	building in-band OAM MPLS-TP toolset.		building in-band OAM MPLS-TP toolset.
	RFC 5586 [RFC 5586] An-In-Band Data Communication Network for the		RFC 5718 [RFC 5718] An-In-Band Data Communication Network for the
	MPLS Transport Profile describes how the G-Ach may be used to for		MPLS Transport Profile describes how the G-Ach may be used for
	Management Communication and Signaling Communication.		Management and Signaling Communication.
	4.2. Fault Management Toolset		4.2. Fault Management Toolset
	The following tables provide the summary of MPLS-TP OAM Fault		The following tables provide the summary of MPLS-TP OAM toolset.
	Management toolset functions, protocol definitions, and the IETF
	RFCs or Internet drafts.		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,		The following table provide the Performance Monitoring Functions,
	protocol definitions, and corresponding RFCs or Internet Drafts.		protocol definitions, and corresponding RFCs or Internet Drafts.
	(Editor's note: only RFCs are referenced in the final version of		(Editor's note: only RFCs will be referenced in the final version
	the document).		of the document).
	+----------------------------------------------------------------+		+----------------------------------------------------------------+
	| Proactive Fault Management OAM Toolset |		| Proactive Fault Management OAM Toolset |
	|----------------------------------------------------------------|		|----------------------------------------------------------------|
	|OAM Functions |Protocols Definitions | RFCs / IDs |		|OAM Functions |OAM Tools/Protocols | RFCs / IDs |
	|------------------|------------------------|--------------------|		|------------------|------------------------|--------------------|
	|Continuity Check |Bidirectional Forwarding| draft-ietf-mpls-tp |		|Continuity Check |Bidirectional Forwarding| draft-ietf-mpls-tp |
	|(CV) & Continuity |Detection (BFD) | -cc-cv-rdi [cc-cv] |		|(CV) & Continuity |Detection (BFD) | -cc-cv-rdi [cc-cv] |
	|Verification(CV) | | |		|Verification(CV) | | |
	|------------------|------------------------|--------------------|		|------------------|------------------------|--------------------|
	|Remote Defect |Bidirectional Forwarding| draft-ietf-mpls-tp |		|Remote Defect |Bidirectional Forwarding| draft-ietf-mpls-tp |
	|Indication (RDI) |Detection (BFD) | -cc-cv-rdi |		|Indication (RDI) |Detection (BFD) | -cc-cv-rdi [cc-cv] |
	|------------------|------------------------|--------------------|		|------------------|------------------------|--------------------|
	|Alarm Indication |AIS message under G-Ach | draft-ietf-mpls-tp |		|Alarm Indication |AIS message under G-Ach | draft-ietf-mpls-tp |
	|Signal (AIS) | | -fault |		|Signal (AIS) | | -fault [fault] |
	|------------------|------------------------|--------------------|		|------------------|------------------------|--------------------|
	|Link Down |Flag in AIS message | draft-ietf-mpls-tp |		|Link Down |Flag in AIS message | draft-ietf-mpls-tp |
	||Indication (LDI) | | -fault [fault] |		|Indication (LDI) | | -fault [fault] |
	|------------------|------------------------|--------------------|		|------------------|------------------------|--------------------|
	|Lock Report (LKR) |LKR message under G-Ach | draft-ietf-mpls-tp |		|Lock Report (LKR) |LKR message under G-Ach | draft-ietf-mpls-tp |
	| | | -fault |		| | | -fault [fault] |
	+----------------------------------------------------------------+		+----------------------------------------------------------------+
	Table 1. Proactive Fault Management OAM Toolset		Table 1. Proactive Fault Management OAM Toolset
	+----------------------------------------------------------------+		+----------------------------------------------------------------+
	| On Demand Fault Management OAM Toolset |		| On Demand Fault Management OAM Toolset |
	|----------------------------------------------------------------|		|----------------------------------------------------------------|
	|OAM Functions |Protocols Definitions | RFCs / IDs |		|OAM Functions |OAM Tools/Protocols | RFCs / IDs |
	|------------------|------------------------|--------------------|		|------------------|------------------------|--------------------|
	|Continuity |LSP Ping and BFD | draft-ietf-mpls-tp |		|Continuity |LSP Ping and BFD | draft-ietf-mpls-tp |
	|Verification(CV) | | -cc-cv-rdi |		|Verification(CV) | | -cc-cv-rdi [cc-cv] |
	|------------------|------------------------|--------------------|		|------------------|------------------------|--------------------|
	|Loopback |1) In-band Loopback | draft-ietf-mpls-tp |		|Diagnostic: |1) In-band Loopback | draft-ietf-mpls-tp |
	|(LBM/LBR) | in G-Ach | -li-lb [li-lb] |		|Loopback, Lock | and Lock Instruct | -li-lb [li-lb] |
	| |2) LSP Ping | |		|and LSP Ping |2) LSP Ping | |
	|------------------|------------------------|--------------------|		|------------------|------------------------|--------------------|
	|Lock Instruct | In-band lock message | draft-ietf-mpls-tp |		|Lock Instruct | In-band lock message | draft-ietf-mpls-tp |
	|(LI) | in G-Ach | -li-lb |		|(LI) | in G-Ach | -li-lb [li-lb] |
	+----------------------------------------------------------------+		+----------------------------------------------------------------+
	Table 2. On Demand Fault Management OAM Toolset		Table 2. On Demand Fault Management OAM Toolset
	4.3. Performance Monitoring Toolset		4.3. Performance Monitoring Toolset
	The following table provide the Performance Monitoring Fuctions,
	protocol definitions, and corresponding RFCs or Internet Drafts.		Table 3 provides the Performance Monitoring Fuctions, protocol
			definitions, and corresponding RFCs or Internet Drafts.
	+----------------------------------------------------------------+		+----------------------------------------------------------------+
	| Performance Monitoring OAM Toolset |		| Performance Monitoring OAM Toolset |
	|----------------------------------------------------------------|		|----------------------------------------------------------------|
	|OAM Functions |Protocols Definitions | RFCs / IDs |		|OAM Functions |Protocols Definitions | RFCs / IDs |
	|------------------|------------------------|--------------------|		|------------------|------------------------|--------------------|
	|Packet loss |LM & DM query messages | draft-ietf-mpls-tp |		|Packet loss |LM & DM query messages | draft-ietf-mpls-tp |
	|measurement (LM) | | -loss-delay [lo-de]|		|measurement (LM) | | -loss-delay [lo-de]|
	|------------------|------------------------| |		|------------------|------------------------| |
	|Packet delay (DM) |LM & DM query messages | draft-ietf-mpls-tp |		|Packet delay (DM) |LM & DM query messages | draft-ietf-mpls-tp |
	|(LBM/LBR) | | -loss-delay |		|measurement | | -loss-delay |
	|measurement | | -profile [lo-de-p] |		|------------------|------------------------|-profile [tp-lo-de] |
	|------------------|------------------------| |		|Throughput |derived from Loss | |
	|Throughput |Supported by LM | |		|measurement |measurement | |
	|measurement | | |
	|------------------|------------------------| |		|------------------|------------------------| |
	|Delay Variation |Supported by DM | |		|Delay Variation |Supported from Delay | |
	|measurement | | |		|measurement |measurement | |
	+----------------------------------------------------------------+		+----------------------------------------------------------------+
	Table 3. Performance Monitoring OAM Toolset		Table 3. Performance Monitoring OAM Toolset
	5. OAM Toolset Functionalities and Utilization		5. OAM Toolset Utilization and Protocol Definitions
	(to be filled)		5.1. Connectivity Check and Connectivity Verification
	5.1. Connectivity Verifications		Continuity Check (CC) and Proactive Connectivity Verification (CV)
			functions are used to detect loss of continuity (LOC), and
			unintended connectivity between two MEPs.
	5.2. Route Tracing		Loss of connectivity, mis-merging, mis-connectivity, or unexpected
	5.3. Diagnostic Tests		Maintenance Entity Group End Points (MEPs) can be detected using
			the CC/CV tools.
	5.4. Lock Instruct		The CC/CV tools are used to support MPLS-TP fault management,
			performance management, and protection switching.
	5.5. Lock Reporting		Bidirectional Forwarding Detection (BFD) and LSP Ping are defined
			to support the CC/CV functions [cc-cv].
	5.6. Alarm Reporting		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.
	5.7. Remote Defect		The interval of BFD control packet can be configured. For example:
	5.8. Client Failure		- 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.9. Packet Loss Measurement		5.2. Diagnostic Tests and Lock Instruct
	5.10. Packet Delay Measurement		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
			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.
			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.
			- 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		6. IANA assigned code points under G-Ach
	OAM toolset/functions defined under G-Ach MUST use IANA assigned		OAM toolset/functions defined under G-Ach MUST use IANA assigned
	code points, using Experimental Code Point under G-Ach is		code points, using Experimental Code Point under G-Ach is
	inappropriate and it can lead to interoperability problems and		inappropriate and it can lead to interoperability problems and
	potential Code Point collision in production network.		potential Code Point collision in production network.
	RFC 5586 "MPLS Generic Associated Channel" stated the following in		RFC 5586 "MPLS Generic Associated Channel" stated the following in
	IANA consideration section: A requirement has emerged (see [RFC		IANA consideration section: A requirement has emerged (see [RFC
	5860]) to allow for optimizations or extensions to OAM and other		5860]) to allow for optimizations or extensions to OAM and other
	control protocols running in an associated channel to be		control protocols running in an associated channel to be
	experimented without resorting to the IETF standards process, by		experimented without resorting to the IETF standards process, by
	supporting experimental code points. This would prevent code points		supporting experimental code points. This would prevent code points
	used for such functions from being used from the range allocated		used for such functions from being used from the range allocated
	through the IETF standards and thus protects an installed base of		through the IETF standards and thus protects an installed base of
	equipment from potential inadvertent overloading of code points.		equipment from potential inadvertent overloading of code points.
	In order to support this requirement, IANA has changed the code		In order to support this requirement, IANA has changed the code
	point allocation scheme for the PW Associated Channel Type be		point allocation scheme for the PW Associated Channel as follows:
	changed as follows:
	0 - 32751: IETF Review		0 - 32751: IETF Review
	32760 - 32767: Experimental		32760 - 32767: Experimental
	Code points in the experimental range MUST be used according to the		Code points in the experimental range MUST be used according to the
	guidelines of RFC 3692 [RFC 3692]. Functions using experimental G-		guidelines of RFC 3692 [RFC 3692]. Functions using experimental G-
	Ach code points MUST be disabled by default.		Ach code points MUST be disabled by default.
	The guidelines on the usage of experimental numbers are defined in		The guidelines on the usage of experimental numbers are defined in
	IETF RFC 3692. As indicated by RFC 3692: The experimental numbers		IETF RFC 3692. As indicated by RFC 3692: The experimental numbers
	are useful when experimenting new protocols or extending existing		are useful when experimenting new protocols or extending existing
	protocols in order to test and experiment the new functions, as part		protocols in order to test and experiment with the new functions, as
	of implementation. RFC 3692 reserves a range of numbers for		part of implementation. RFC 3692 reserves a range of numbers for
	experimentation when the need of such experimentation has been		experimentation when the need of such experimentation has been
	identified.		identified.
	However, the experimental numbers "are reserved for generic testing		However, the experimental numbers "are reserved for generic testing
	purposes, and other implementations may use the same numbers for		purposes, and other implementations may use the same numbers for
	different experimental uses." "Experimental numbers are intended for		different experimental uses." "Experimental numbers are intended for
	experimentation and testing and are not intended for wide or general		experimentation and testing and are not intended for wide or general
	deployments." "Shipping a product with a specific value pre-enabled		deployments." "Shipping a product with a specific value pre-enabled
	would be inappropriate and can lead to interoperability problems		would be inappropriate and can lead to interoperability problems
	when the chosen value collides with a different usage, as it someday		when the chosen value collides with a different usage, as it someday
	skipping to change at page 12, line 35 ¶		skipping to change at page 15, line 33 ¶
	Similar statements can also be found in RFC4929 "Change Process for		Similar statements can also be found in RFC4929 "Change Process for
	Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)		Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
	Protocols and Procedures". As described in [RFC 4775], "non-		Protocols and Procedures". As described in [RFC 4775], "non-
	standard extensions, including experimental values, are not to be		standard extensions, including experimental values, are not to be
	portrayed as industrial standards whether by an individual vendor,		portrayed as industrial standards whether by an individual vendor,
	an industry forum, or a standards body."		an industry forum, or a standards body."
	7. Security Considerations		7. Security Considerations
	The document provides overview on MPLS-TP OAM requirements,		The document provides overview of MPLS-TP OAM requirements,
	functions, protocol definitions, and solution considerations. The		functions, protocol, and solution considerations. The actual
	actual protocols for the OAM toolset are defined in separate		protocols for the OAM toolset are defined in separate documents and
	documents and referenced by this document.		referenced by this document.
	The general security considerations are provided in MPLS-TP		The general security considerations are provided in Security
	Security Framework. [tp-sec-fr]		Framework for MPLS and GMPLS Networks [RFC 5920], and MPLS-TP
			Security Framework [tp-sec-fr].
	8. IANA Considerations		8. IANA Considerations
	This document contains no new IANA considerations.		This document contains no new IANA considerations.
	9. Normative References		9. Normative References
	[RFC 5586], M. Bocci, M. Vigoureux, S. Bryant, "MPLS Generic		[RFC 5586], M. Bocci, M. Vigoureux, S. Bryant, "MPLS Generic
	Associated Channel",RFC 5586, June 2009.		Associated Channel",RFC 5586, June 2009.
	[RFC 5654], Niven-Jenkins, B., et al, "MPLS-TP Requirements", RFC		[RFC 5654], Niven-Jenkins, B., et al, "MPLS-TP Requirements", RFC
	5654, September 2009.		5654, September 2009.
	[RFC 5718], D. Beller, and A. Farrel, "An In-Band Data Communication		[RFC 5718], D. Beller, and A. Farrel, "An In-Band Data
	Network For the MPLS Transport Profile", RFC 5718, Jan 2010.		Communication Network For the MPLS Transport Profile", RFC 5718,
			Jan 2010.
	[RFC 5860], M. Vigoureux, D. Ward, M. Betts, "Requirements for		[RFC 5860], M. Vigoureux, D. Ward, M. Betts, "Requirements for
	Operations, Administration, and Maintenance (OAM) in MPLS Transport		Operations, Administration, and Maintenance (OAM) in MPLS Transport
	Networks", RFC 5860, May 2010.		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		10. Informative References
	[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997		Requirement Levels", BCP 14, RFC 2119, March 1997
	[RFC 3692] T. Narten, "Assigning Experimental and Testing Numbers		[RFC 3692] T. Narten, "Assigning Experimental and Testing Numbers
	Considered Useful", RFC 3692, Jan. 2004.		Considered Useful", RFC 3692, Jan. 2004.
	[RFC 4775] S. Bradner, "Procedures for Protocol Extensions and		[RFC 4775] S. Bradner, "Procedures for Protocol Extensions and
	Variations", RFC 4775, Dec. 2006.		Variations", RFC 4775, Dec. 2006.
	[RFC 5920] L. Fang, et al, Security Framework for MPLS and GMPLS		[RFC 5920] L. Fang, et al, Security Framework for MPLS and GMPLS
	Networks, July 2010.		Networks, July 2010.
	[MPLS-TP NM REQ] Hing-Kam Lam, Scott Mansfield, Eric Gray, MPLS TP		[MPLS-TP NM REQ] Hing-Kam Lam, Scott Mansfield, Eric Gray, MPLS TP
	Network Management Requirements, draft-ietf-mpls-tp-nm-req-06.txt,		Network Management Requirements, draft-ietf-mpls-tp-nm-req-06.txt,
	October 2009.		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.
	[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		[tp-sec-fr] L. Fang, Niven-Jenkins, S. Mansfield, et. Al. MPLS-TP
	Security Framework, draft-ietf-mpls-tp-security-framework-00, Feb.		Security Framework, draft-ietf-mpls-tp-security-framework-00, Feb.
	2011.		2011.
	11. Author's Addresses		11. Authors' Addresses
	Luyuan Fang		Luyuan Fang
	Cisco Systems		Cisco Systems
	111 Wood Avenue South		111 Wood Avenue South
	Iselin, NJ 08830		Iselin, NJ 08830
	USA		USA
	Email: lufang@cisco.com		Email: lufang@cisco.com
	Dan Frost		Dan Frost
	Cisco Systems		Cisco Systems
	Email: danfrost@cisco.com		Email: danfrost@cisco.com
			Nabil Bitar
			Verizon
			40 Sylvan Road
			Waltham, MA 02145
			USA
			Email: nabil.bitar@verizon.com
	Raymond Zhang		Raymond Zhang
	British Telecom		British Telecom
	BT Center		BT Center
	81 Newgate Street		81 Newgate Street
	London, EC1A 7AJ		London, EC1A 7AJ
	United Kingdom		United Kingdom
	Email: raymond.zhang@bt.com		Email: raymond.zhang@bt.com
	Nabil Bitar
	Verizon
	40 Sylvan Road
	Waltham, MA 02145
	USA
	Email: nabil.bitar@verizon.com
	Lei Wang		Lei Wang
	Telenor		Telenor
	Telenor Norway		Telenor Norway
	Office Snaroyveien		Office Snaroyveien
	1331 Fornedbu		1331 Fornedbu
	Email: Lei.wang@telenor.com		Email: Lei.wang@telenor.com
	Masahiro DAIKOKU		Kam Lee Yap
	KDDI corporation		XO Communications
	3-11-11.Iidabashi, Chiyodaku, Tokyo		13865 Sunrise Valley Drive,
	Japan		Herndon, VA 20171
	Email: ms-daikoku@kddi.com		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
End of changes. 66 change blocks.
	188 lines changed or deleted		328 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/