draft-ietf-opsawg-oam-overview-01.txt		draft-ietf-opsawg-oam-overview-02.txt
	Operations and Management Area Working Group T. Mizrahi		Operations and Management Area Working Group T. Mizrahi
	Internet Draft Marvell		Internet Draft Marvell
	Intended status: Informational July 12, 2010		Intended status: Informational N. Sprecher
	Expires: January 2011		Expires: April 2011 Nokia Siemens Networks
			E. Bellagamba
			Ericsson
			Y. Weingarten
			Nokia Siemens Networks
			October 7, 2010
	An Overview of		An Overview of
	Operations, Administration, and Maintenance (OAM) Mechanisms		Operations, Administration, and Maintenance (OAM) Mechanisms
	draft-ietf-opsawg-oam-overview-01.txt		draft-ietf-opsawg-oam-overview-02.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		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), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 32		skipping to change at page 1, line 37
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 12, 2011.		This Internet-Draft will expire on April 7, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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 respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Abstract		Abstract
	Operations, Administration, and Maintenance (OAM) is a general term		Operations, Administration, and Maintenance (OAM) is a general term
	that refers to detecting and reporting link failures. OAM mechanisms		that refers to a toolset that can be used for detecting and reporting
	have been defined for various layers in the protocol stack, and are		connection failures or measurement of connection performance
	used with a variety of protocols.		parameters. OAM mechanisms have been defined for various layers in
			the protocol stack, and are used with a variety of protocols.
	This document presents an overview of the OAM mechanisms that have		This document presents an overview of the OAM mechanisms that have
	been defined and are currently being defined by the IETF, as well as		been defined and are currently being defined by the IETF, as well as
	a comparison to other OAM mechanisms that have been defined by the		a comparison to other OAM mechanisms that have been defined by the
	IEEE and ITU-T.		IEEE and ITU-T.
	Table of Contents		Table of Contents
	1. Introduction................................................4		1. Introduction................................................4
	2. Conventions used in this document............................8		2. Conventions used in this document............................8
	3. Basic Terminology...........................................8		3. Basic Terminology...........................................8
	3.1. Abbreviations..........................................8		3.1. Abbreviations..........................................8
	3.2. Terminology used in OAM Standards.......................9		3.2. Terminology used in OAM Standards.......................9
	3.2.1. General Terms......................................9		3.2.1. General Terms......................................9
	3.2.2. OAM Maintenance Entities...........................9		3.2.2. OAM Maintenance Entities and Communication Links...10
	3.2.3. OAM Maintenance Points............................10		3.2.3. OAM Maintenance Points............................10
	3.2.4. OAM Link Failures.................................10		3.2.4. Link Failures.....................................11
	3.2.5. Summary of OAM Terms used in the Standards.........10		3.2.5. Connectivity Verification and Continuity Checks....11
	4. OAM Functions..............................................12		3.2.6. Summary of OAM Terms used in the Standards.........11
	4.1. ICMP Ping.............................................12		4. OAM Functions..............................................13
	4.2. Bidirectional Forwarding Detection (BFD)...............12		4.1. ICMP Ping.............................................13
	4.2.1. Overview.........................................12		4.2. Bidirectional Forwarding Detection (BFD)...............13
	4.2.2. BFD Control.......................................12		4.2.1. Overview.........................................13
	4.2.3. BFD Echo.........................................13		4.2.2. BFD Control.......................................13
	4.3. LSP Ping..............................................13		4.2.3. BFD Echo.........................................14
	4.4. PWE3 Virtual Circuit Connectivity Verification (VCCV)...13		4.3. LSP Ping..............................................14
	4.5. IP Performance Metrics (IPPM)..........................14		4.4. PWE3 Virtual Circuit Connectivity Verification (VCCV)...15
	4.5.1. Overview.........................................14		4.5. IP Performance Metrics (IPPM)..........................15
	4.5.2. OWAMP/TWAMP Control...............................14		4.5.1. Overview.........................................15
	4.5.3. OWAMP/TWAMP Test..................................14		4.5.2. Control and Test Protocols........................16
	4.6. ITU-T Y.1711..........................................14		4.5.3. OWAMP............................................16
	4.6.1. Overview.........................................14		4.5.4. TWAMP............................................17
	4.6.2. Connectivity Verification (CV)....................15		4.6. ITU-T Y.1711..........................................17
	4.6.3. Fast Failure Detection (FFD)......................15		4.6.1. Overview.........................................17
	4.6.4. Forward Defect Indication (FDI)...................15		4.6.2. Connectivity Verification (CV)....................18
	4.6.5. Backward Defect Indication (BDI)..................15		4.6.3. Fast Failure Detection (FFD)......................18
			4.6.4. Forward Defect Indication (FDI)...................18
	4.7. ITU-T Y.1731..........................................16		4.6.5. Backward Defect Indication (BDI)..................19
	4.7.1. Overview.........................................16		4.7. ITU-T Y.1731..........................................19
	4.7.2. ETH-CC...........................................16		4.7.1. Overview.........................................19
	4.7.3. ETH-LB...........................................17		4.7.2. ETH-CC...........................................19
	4.7.4. ETH-TST..........................................17		4.7.3. ETH-LB...........................................20
	4.7.5. ETH-LT...........................................17		4.7.4. ETH-TST..........................................20
	4.7.6. ETH-AIS..........................................17		4.7.5. ETH-LT...........................................20
	4.7.7. ETH-LCK..........................................17		4.7.6. ETH-AIS..........................................20
	4.7.8. ETH-RDI..........................................18		4.7.7. ETH-LCK..........................................20
	4.7.9. ETH-APS..........................................18		4.7.8. ETH-RDI..........................................21
	4.7.10. ETH-LM..........................................18		4.7.9. ETH-APS..........................................21
	4.7.11. ETH-DM..........................................18		4.7.10. ETH-LM..........................................21
	4.8. IEEE 802.1ag..........................................19		4.7.11. ETH-DM..........................................21
	4.8.1. Overview.........................................19		4.8. IEEE 802.1ag..........................................22
	4.8.2. Continuity Check..................................19		4.8.1. Overview.........................................22
	4.8.3. Loopback.........................................19		4.8.2. Continuity Check..................................22
	4.8.4. Linktrace........................................20		4.8.3. Loopback.........................................22
	4.9. IEEE 802.3ah..........................................20		4.8.4. Linktrace........................................23
	4.9.1. Overview.........................................20		4.9. IEEE 802.3ah..........................................23
	4.9.2. Remote Failure Indication.........................20		4.9.1. Overview.........................................23
	4.9.3. Remote Loopback...................................20		4.9.2. Remote Failure Indication.........................23
	4.9.4. Link Monitoring...................................20		4.9.3. Remote Loopback...................................23
	4.10. MPLS-TP OAM..........................................20		4.9.4. Link Monitoring...................................23
	4.10.1. Overview........................................20		4.10. MPLS-TP OAM..........................................23
	4.10.2. Continuity Checks................................21		4.10.1. Overview........................................23
	4.10.3. Connectivity Verification........................21		4.10.2. Generic Associated Channel.......................24
	4.10.4. Diagnostic Tests.................................21		4.10.3. MPLS-TP OAM Toolset..............................24
	4.10.5. Route Tracing....................................22		4.10.3.1. Continuity Check and Connectivity Verification25
	4.10.6. Lock Instruct....................................22		4.10.3.2. Diagnostic Tests............................25
	4.10.7. Lock Reporting...................................22		4.10.3.3. Route Tracing...............................25
	4.10.8. Alarm Reporting..................................22		4.10.3.4. Lock Instruct...............................25
	4.10.9. Remote Defect Indication.........................22		4.10.3.5. Lock Reporting..............................26
	4.10.10. Client Failure Indication.......................22		4.10.3.6. Alarm Reporting.............................26
	4.10.11. Packet Loss Measurement.........................22		4.10.3.7. Remote Defect Indication....................26
	4.10.12. Packet Delay Measurement........................22		4.10.3.8. Client Failure Indication...................26
	4.11. Summary of OAM Functions..............................22		4.10.3.9. Packet Loss Measurement.....................26
	4.12. Summary of Unidirectional Connectivity Check Mechanisms24		4.10.3.10. Packet Delay Measurement...................27
	5. Security Considerations.....................................25		4.11. Summary of OAM Functions..............................27
	6. IANA Considerations........................................25		4.12. Summary of Continuity Check Mechanisms................29
	7. Acknowledgments............................................25		5. Security Considerations.....................................30
	8. References.................................................25		6. IANA Considerations........................................30
	8.1. Normative References...................................25		7. Acknowledgments............................................30
	8.2. Informative References.................................28		8. References.................................................30
			8.1. Normative References...................................30
			8.2. Informative References.................................32
	1. Introduction		1. Introduction
	OAM is a general term that refers to detecting and reporting link		OAM is a general term that refers to a toolset that can be used for
	failures and defects. The term OAM has been used over the years in		detecting and reporting connection failures or measurement of
	several different contexts, as discussed in [OAM Soup]. In the		connection performance parameters. The term OAM has been used over
	context of this document OAM refers to Operations, Administration,		the years in several different contexts, as discussed in [OAM Soup].
	and Maintenance, i.e., this document refers to OAM in the context of		In the context of this document OAM refers to Operations,
	monitoring communication links. Other aspects associated with the OAM		Administration, and Maintenance, i.e., this document refers to OAM in
	acronym, such as management, are not described in this document.		the context of monitoring communication links. Other aspects
			associated with the OAM acronym, such as management, are not
			described in this document.
	OAM was originally used in the world of telephony, and has been		OAM was originally used in the world of telephony, and has been
	adopted in packet based networks. OAM mechanisms are used in various		adopted in packet based networks. OAM mechanisms are used in various
	layers in the protocol stack, and are applied to a variety of		layers in the protocol stack, and are applied to a variety of
	different protocols.		different protocols.
	The IETF has defined OAM for several protocols, and is currently		The IETF has defined OAM for several protocols, and is currently
	working on defining several new OAM protocols. A summary of these		working on defining several new OAM protocols. A summary of these
	protocols, old and new, is listed below:		protocols, old and new, is listed below:
	skipping to change at page 4, line 39		skipping to change at page 4, line 42
	o Virtual Circuit Connectivity Check (VCCV) for Pseudowires, as		o Virtual Circuit Connectivity Check (VCCV) for Pseudowires, as
	defined in [VCCV].		defined in [VCCV].
	o ICMP Echo request, also known as Ping, as defined in [ICMPv4], and		o ICMP Echo request, also known as Ping, as defined in [ICMPv4], and
	[ICMPv6]. ICMP Ping is a very simple and basic mechanism in		[ICMPv6]. ICMP Ping is a very simple and basic mechanism in
	failure diagnosis, and is not traditionally associated with OAM,		failure diagnosis, and is not traditionally associated with OAM,
	but it is presented in this document for the sake of completeness,		but it is presented in this document for the sake of completeness,
	since both LSP Ping and VCCV are to some extent based on ICMP		since both LSP Ping and VCCV are to some extent based on ICMP
	Ping.		Ping.
	o Bidirectional Forwarding Detection (BFD) is a family of standards		o Bidirectional Forwarding Detection (BFD) is defined in [BFD] as a
	that are currently being defined by the IETF. BFD is intended to		framework for a lightweight generic OAM mechanism. The intention
	be a generic OAM mechanism that can be used with various		is to define a base mechanism that can be used with various
	encapsulation types, and in various medium types.		encapsulation types, network environments, and in various medium
			types.
	o OAM for MPLS-TP is currently being defined in the MPLS working		o The OAM requirements for MPLS Transport Profile (MPLS-TP) are
	group.		defined in [MPLS-TP OAM], and the toolset is described in [MPLS-TP
			OAM FW]. The OAM toolset for MPLS-TP is currently being defined in
			the MPLS working group.
	o IP Performance Metrics (IPPM) is a working group in the IETF that		o IP Performance Metrics (IPPM) is a working group in the IETF that
	defined common metrics for performance measurement, as well as a		defined common metrics for performance measurement, as well as a
	protocol for measuring delay and packet loss in IP networks.		protocol for measuring delay and packet loss in IP networks.
	While performance measurement is not directly related to link		Alternative protocols for performance measurement are defined, for
	failures, it is often associated with OAM. Alternative protocols		example, in MPLS-TP OAM [MPLS-TP OAM], and in Ethernet OAM [ITU-T
	for performance measurement are defined, for example, in MPLS-TP		Y.1731].
	OAM [MPLS-TP OAM], and in Ethernet OAM [ITU-T Y.1731].
	In addition to the OAM mechanisms defined by the IETF, the IEEE and		In addition to the OAM mechanisms defined by the IETF, the IEEE and
	ITU-T have also defined various OAM mechanisms. These various		ITU-T have also defined various OAM mechanisms. These various
	mechanisms defined by the three standard organizations are often		mechanisms defined by the three standard organizations are often
	tightly coupled, and have had a mutual effect on each other. For		tightly coupled, and have had a mutual effect on each other. The ITU-
	example, the emerging MPLS-TP OAM is in many ways based on [ITU-T		T and IETF have both defined OAM mechanisms for MPLS LSPs, [ITU-T
	Y.1731]. The ITU-T and IETF have both defined OAM mechanisms for MPLS		Y.1711] and [LSP Ping]. The following OAM standards by the IEEE and
	LSPs, [ITU-T Y.1711] and [LSP Ping]. The following OAM standards by		ITU-T are to some extent linked to IETF OAM mechanisms listed above,
	the IEEE and ITU-T are to some extent linked to IETF OAM mechanisms		and are also discussed in this document:
	listed above, and are also discussed in this document:
	o OAM mechanisms for Ethernet based networks have been defined by		o OAM mechanisms for Ethernet based networks have been defined by
	both the ITU-T in [ITU-T Y.1731], and by the IEEE in [IEEE		both the ITU-T in [ITU-T Y.1731], and by the IEEE in [IEEE
	802.1ag]. The IEEE 802.3 standard defines OAM for one-hop Ethernet		802.1ag]. The IEEE 802.3 standard defines OAM for one-hop Ethernet
	links [IEEE 802.3ah].		links [IEEE 802.3ah].
	o The ITU-T has defined OAM for MPLS LSPs in [ITU-T Y.1711].		o The ITU-T has defined OAM for MPLS LSPs in [ITU-T Y.1711].
	This document summarizes the OAM mechanisms defined in the standards		This document summarizes the OAM mechanisms defined in the standards
	above. The focus is on OAM mechanisms defined by the IETF, compared		above. The focus is on OAM mechanisms defined by the IETF. These
	with the relevant OAM mechanisms defined by the ITU-T and IEEE. We		mechanisms will be compared with the relevant OAM mechanisms defined
	first present a comparison of the terminology used in various OAM		by the ITU-T and IEEE, where applicable. We first present a
	standards, and then summarize the OAM functions that each OAM		comparison of the terminology used in various OAM standards, and then
	standard provides.		summarize the OAM functions that each OAM standard provides.
	Table 1 summarizes the OAM standards discussed in this document.		Table 1 summarizes the OAM standards discussed in this document.
	+-----------+--------------------------------------+---------------+		+-----------+--------------------------------------+---------------+
	| | Title |Standard |		| | Title |Standard/Draft |
	+-----------+--------------------------------------+---------------+		+-----------+--------------------------------------+---------------+
	|ICMPv4 Ping| Internet Control Message Protocol | RFC 792 |		|ICMPv4 Ping| Internet Control Message Protocol | RFC 792 |
	| | | |		| | | |
	+-----------+--------------------------------------+---------------+		+-----------+--------------------------------------+---------------+
	|ICMPv6 Ping| Internet Control Message Protocol | RFC 4443 |		|ICMPv6 Ping| Internet Control Message Protocol | RFC 4443 |
	| | (ICMPv6) for the Internet Protocol | |		| | (ICMPv6) for the Internet Protocol | |
	| | Version 6 (IPv6) Specification | |		| | Version 6 (IPv6) Specification | |
	+-----------+--------------------------------------+---------------+		+-----------+--------------------------------------+---------------+
	|BFD | Bidirectional Forwarding Detection | RFC 5880 |		|BFD | Bidirectional Forwarding Detection | RFC 5880 |
	| +--------------------------------------+---------------+		| +--------------------------------------+---------------+
	skipping to change at page 6, line 36		skipping to change at page 6, line 39
	| | Label Switching (MPLS) Operations | |		| | Label Switching (MPLS) Operations | |
	| | and Management (OAM) | |		| | and Management (OAM) | |
	| +--------------------------------------+---------------+		| +--------------------------------------+---------------+
	| | Detecting Multi-Protocol Label | RFC 4379 |		| | Detecting Multi-Protocol Label | RFC 4379 |
	| | Switched (MPLS) Data Plane Failures | |		| | Switched (MPLS) Data Plane Failures | |
	| +--------------------------------------+---------------+		| +--------------------------------------+---------------+
	| | Operations and Management (OAM) | RFC 4687 |		| | Operations and Management (OAM) | RFC 4687 |
	| | Requirements for Point-to-Multipoint | |		| | Requirements for Point-to-Multipoint | |
	| | MPLS Networks | |		| | MPLS Networks | |
	+-----------+--------------------------------------+---------------+		+-----------+--------------------------------------+---------------+
			|MPLS-TP | Requirements for OAM in MPLS-TP | RFC 5860 |
			|OAM +--------------------------------------+---------------+
			| | MPLS Generic Associated Channel | RFC 5586 |
			| +--------------------------------------+---------------+
			| | MPLS-TP OAM Framework |[MPLS-TP OAM FW|
			| | |] - work in |
			| | |progress |
			| +--------------------------------------+---------------+
			| | MPLS-TP OAM Analysis |[OAM Analysis] |
			| | | - work in |
			| | |progress |
			+-----------+--------------------------------------+---------------+
	|PW VCCV | Pseudowire Virtual Circuit | RFC 5085 |		|PW VCCV | Pseudowire Virtual Circuit | RFC 5085 |
	| | Connectivity Verification (VCCV): | |		| | Connectivity Verification (VCCV): | |
	| | A Control Channel for Pseudowires | |		| | A Control Channel for Pseudowires | |
	+-----------+--------------------------------------+---------------+		+-----------+--------------------------------------+---------------+
	|IPPM | Framework for IP Performance Metrics | RFC 2330 |		|IPPM | Framework for IP Performance Metrics | RFC 2330 |
	| +--------------------------------------+---------------+		| +--------------------------------------+---------------+
	| | IPPM Metrics for Measuring | RFC 2678 |		| | IPPM Metrics for Measuring | RFC 2678 |
	| | Connectivity | |		| | Connectivity | |
	| +--------------------------------------+---------------+		| +--------------------------------------+---------------+
	| | A One-way Delay Metric for IPPM | RFC 2679 |		| | A One-way Delay Metric for IPPM | RFC 2679 |
	skipping to change at page 7, line 28		skipping to change at page 7, line 43
	| +--------------------------------------+---------------+		| +--------------------------------------+---------------+
	| | Assignment of the 'OAM Alert Label' | RFC 3429 |		| | Assignment of the 'OAM Alert Label' | RFC 3429 |
	| | for Multiprotocol Label Switching | |		| | for Multiprotocol Label Switching | |
	| | Architecture (MPLS) Operation and | |		| | Architecture (MPLS) Operation and | |
	| | Maintenance (OAM) Functions | |		| | Maintenance (OAM) Functions | |
	+-----------+--------------------------------------+---------------+		+-----------+--------------------------------------+---------------+
	|ITU-T | OAM Functions and Mechanisms for |[ITU-T Y.1731] |		|ITU-T | OAM Functions and Mechanisms for |[ITU-T Y.1731] |
	|Ethernet | Ethernet-based Networks | |		|Ethernet | Ethernet-based Networks | |
	|OAM | | |		|OAM | | |
	+-----------+--------------------------------------+---------------+		+-----------+--------------------------------------+---------------+
	|MPLS-TP | Requirements for OAM in MPLS | RFC 5860 |
	|OAM +--------------------------------------+---------------+
	| | MPLS Generic Associated Channel | RFC 5586 |
	+-----------+--------------------------------------+---------------+
	|IEEE | Connectivity Fault Management |[IEEE 802.1ag] |		|IEEE | Connectivity Fault Management |[IEEE 802.1ag] |
	|CFM | | |		|CFM | | |
	+-----------+--------------------------------------+---------------+		+-----------+--------------------------------------+---------------+
	|IEEE | Media Access Control Parameters, |[IEEE 802.3ah] |		|IEEE | Media Access Control Parameters, |[IEEE 802.3ah] |
	|802.3 | Physical Layers, and Management | |		|802.3 | Physical Layers, and Management | |
	|link level | Parameters for Subscriber Access | |		|link level | Parameters for Subscriber Access | |
	|OAM | Networks | |		|OAM | Networks | |
	+-----------+--------------------------------------+---------------+		+-----------+--------------------------------------+---------------+
	Table 1 Summary of OAM Standards		Table 1 Summary of OAM Standards
	skipping to change at page 9, line 44		skipping to change at page 10, line 9
	A wide variety of terms is used in various OAM standards. Each of the		A wide variety of terms is used in various OAM standards. Each of the
	OAM standards listed in the reference section includes a section that		OAM standards listed in the reference section includes a section that
	defines the relevant terms. A thesaurus of terminology for MPLS-TP		defines the relevant terms. A thesaurus of terminology for MPLS-TP
	terms is presented in [MPLS-TP Term], and provides a good summary of		terms is presented in [MPLS-TP Term], and provides a good summary of
	some of the OAM related terminology.		some of the OAM related terminology.
	This section presents a comparison of the terms used in various OAM		This section presents a comparison of the terms used in various OAM
	standards, without fully quoting the definition of each term. For a		standards, without fully quoting the definition of each term. For a
	formal definition of each term, refer to the references at the end of		formal definition of each term, refer to the references at the end of
	this document. The comparison focuses on three basic terms, and is		this document. The comparison focuses on three basic terms, and is
	summarized in section 3 ..2.5.		summarized in section 3 ..2.6.
	3.2.2. OAM Maintenance Entities		3.2.2. OAM Maintenance Entities and Communication Links
	A Maintenance Entity (ME) can be either a point-to-point or a point-		A Maintenance Entity (ME) can be either a point-to-point or a point-
	to-multipoint relationship between two or more Maintenance Points.		to-multipoint relationship between two or more Maintenance Points
			(MP). The connectivity between these Maintenance Points is managed
			and monitored by the OAM protocol.
	The connectivity between these Maintenance Points is mangaged and		A pair of MPs engaged in an ME are connected by a communication Link.
	monitored by the OAM protocol.		Link in this context may refer to a physical connection, or to a
			logical path such as an MPLS LSP. The term Link is used throughout
			this document to refer to the connection between the MPs that is
			monitored by an OAM protocol.
	The term Maintenance Entity (ME) is defined in ITU-T standards (e.g.		The term Maintenance Entity (ME) is defined in ITU-T standards (e.g.
	[ITU-T Y.1731]). Various terms are used to refer to an ME. For		[ITU-T Y.1731]). Various terms are used to refer to an ME. For
	example, in MPLS terminology, an ME is simply referred to as an LSP.		example, in MPLS terminology, an ME is simply referred to as an LSP.
	BFD does not explicitly use a term that is equivalent to ME, but		BFD does not explicitly use a term that is equivalent to ME, but
	rather uses the term "session", referring to the relationship between		rather uses the term "session", referring to the relationship between
	two nodes using a BFD protocol.		two nodes using a BFD protocol.
			MPLS-TP has defined the terms ME and Maintenance Entity Group (MEG)
			in [MPLS-TP OAM FW], similar to the terms defined by ITU-T.
	3.2.3. OAM Maintenance Points		3.2.3. OAM Maintenance Points
	A Maintenance Point (MP) is a node that uses an OAM protocol. A		A Maintenance Point (MP) is a function that is defined at a node in
	Maintenance End Point (MEP) is one of the end points of an ME. A		the network, and either initiates or reacts to OAM messages. A
	Maintenance Intermediate Point (MIP) is a point between two MEPs,		Maintenance End Point (MEP) is one of the end points of an ME, and
	that is able to respond to OAM frames, but does not initiate them.		can initiate OAM messages and respond to them. A Maintenance
			Intermediate Point (MIP) is a point between two MEPs, that is able to
			respond to OAM frames, but does not initiate them.
	The terms MEP and MIP are defined in ITU-T standards (e.g. [ITU-T		The terms MEP and MIP are defined in ITU-T standards (e.g. [ITU-T
	Y.1731]). The term Maintenance Point is a general term for MEPs and		Y.1731]). The term Maintenance Point is a general term for MEPs and
	MIPs, and is used in [IEEE 802.1ag].		MIPs, and is used in [IEEE 802.1ag].
	3.2.4. OAM Link Failures		MPLS-TP has defined the terms MEP and MIP and their functional
			characteristics in [MPLS-TP OAM FW], similar to the terms defined by
			ITU-T.
			3.2.4. Link Failures
	The terms Failure, Fault, and Defect are intermittently used in the		The terms Failure, Fault, and Defect are intermittently used in the
	standards. In some standards, such as [IEEE 802.1ag], there is no		standards. In some standards, such as [IEEE 802.1ag], there is no
	distinction between these terms, while in other standards each of		distinction between these terms, while in other standards each of
	these terms refers to a different type of malfunction.		these terms refers to a different type of malfunction.
	The ITU-T distinguishes between these terms in [ITU-T G.806]. The		The ITU-T distinguishes between these terms in [ITU-T G.806]. The
	term Fault refers to an inability to perform a required action, e.g.,		term Fault refers to an inability to perform a required action, e.g.,
	an unsuccessful attempt to deliver a packet. The term Defect refers		an unsuccessful attempt to deliver a packet. The term Defect refers
	to an interruption in the normal operation, such as a consecutive		to an interruption in the normal operation, such as a consecutive
	period of time where no packets are delivered successfully. The term		period of time where no packets are delivered successfully. The term
	Failure refers to the termination of the required function. While a		Failure refers to the termination of the required function. While a
	Defect typically refers to a limited period of time, a failure refers		Defect typically refers to a limited period of time, a failure refers
	to a long period of time.		to a long period of time.
	3.2.5. Summary of OAM Terms used in the Standards		3.2.5. Connectivity Verification and Continuity Checks
			Two distinct classes of failure management functions are used in OAM
			protocols, connectivity verification and continuity checks. The
			distinction between these terms is defined in [MPLS-TP OAM], and is
			used similarly in this document.
			Continuity checks are used to verify the liveness of a link, and are
			typically sent proactively, though they can be invoked on-demand as
			well.
			A connectivity verification function allows an MP to check whether it
			is connected to a peer MP or not. A connectivity verification (CV)
			protocol typically uses a CV message, followed by a CV reply that is
			sent back to the originator. A CV function can be applied proactively
			or on-demand.
			Connectivity verification and continuity checks are considered
			complementary mechanisms, and are often used in conjunction with each
			other.
			3.2.6. Summary of OAM Terms used in the Standards
	Table 2 provides a comparison of the terminology used in different		Table 2 provides a comparison of the terminology used in different
	OAM standards.		OAM standards.
	+-----------+-------------+-----------+----------------------------+		+-----------+-------------+-----------+----------------------------+
	| |Maintenance |Maintenance|Link Failure Terminology |		| |Maintenance |Maintenance|Link Failure Terminology |
	| |Point |Entity | |		| |Point |Entity | |
	| |Terminology |Terminology| |		| |Terminology |Terminology| |
	+-----------+-------------+-----------+----------------------------+		+-----------+-------------+-----------+----------------------------+
	|ICMPv4 Ping|-Host | | |		|ICMPv4 Ping|-Host | | |
	skipping to change at page 11, line 33		skipping to change at page 12, line 33
	| | | | a path with a measurement |		| | | | a path with a measurement |
	| | | | value "false". |		| | | | value "false". |
	+ --------- + ----------- + --------- + -------------------------- +		+ --------- + ----------- + --------- + -------------------------- +
	|ITU-T | LSR | LSP |-Fault, Defect, Failure: as |		|ITU-T | LSR | LSP |-Fault, Defect, Failure: as |
	|Y.1711 | | | defined in [ITU-T G.806] |		|Y.1711 | | | defined in [ITU-T G.806] |
	+ --------- + ----------- + --------- + -------------------------- +		+ --------- + ----------- + --------- + -------------------------- +
	|ITU-T |-MEP | ME |-Fault, Defect, Failure: as |		|ITU-T |-MEP | ME |-Fault, Defect, Failure: as |
	|Y.1731 |-MIP | | defined in [ITU-T G.806] |		|Y.1731 |-MIP | | defined in [ITU-T G.806] |
	| | | | |		| | | | |
	+ --------- + ----------- + --------- + -------------------------- +		+ --------- + ----------- + --------- + -------------------------- +
	|MPLS-TP |-End Point |-LSP |-Fault, Defect, Failure: as |		|MPLS-TP |-End Point, |-LSP |-Fault, Defect, Failure: as |
	|OAM |-Intermediate|-PW | defined in [ITU-T G.806] |		|OAM | MEP |-PW | defined in [ITU-T G.806] |
	| |Point |-Section | |		| |-Intermediate|-Section | |
			| | Point, MIP | | |
	+ --------- + ----------- + --------- + -------------------------- +		+ --------- + ----------- + --------- + -------------------------- +
	|IEEE |-MEP | ME |-Failure |		|IEEE |-MEP | ME |-Failure |
	|802.1ag |-MIP | |-Fault |		|802.1ag |-MIP | |-Fault |
	| |-MP | |-Defect |		| |-MP | |-Defect |
	+ --------- + ----------- + --------- + -------------------------- +		+ --------- + ----------- + --------- + -------------------------- +
	|IEEE | DTE | Link |-Failure |		|IEEE | DTE | Link |-Failure |
	|802.3ah | | |-Fault |		|802.3ah | | |-Fault |
	+-----------+-------------+-----------+----------------------------+		+-----------+-------------+-----------+----------------------------+
	Table 2 Summary of OAM Terms		Table 2 Summary of OAM Terms
	4. OAM Functions		4. OAM Functions
	4.1. ICMP Ping		4.1. ICMP Ping
	ICMP provides a bidirectional connectivity check for the Internet		ICMP provides a connectivity verification function for the Internet
	Protocol. The originator transmits an echo request packet, and the		Protocol. The originator transmits an echo request packet, and the
	receiver replies with an echo reply. ICMP ping is defined in two		receiver replies with an echo reply. ICMP ping is defined in two
	variants, [ICMPv4] is used for IPv4, and [ICMPv6] is used for IPv6.		variants, [ICMPv4] is used for IPv4, and [ICMPv6] is used for IPv6.
	4.2. Bidirectional Forwarding Detection (BFD)		4.2. Bidirectional Forwarding Detection (BFD)
	4.2.1. Overview		4.2.1. Overview
	While multiple OAM mechanisms have been defined for various protocols		While multiple OAM mechanisms have been defined for various protocols
	in the protocol stack, Bidirectional Forwarding Detection [BFD],		in the protocol stack, Bidirectional Forwarding Detection [BFD],
	skipping to change at page 12, line 32		skipping to change at page 13, line 33
	various medium types. The IETF has defined variants of the protocol		various medium types. The IETF has defined variants of the protocol
	for IP ([BFD IP], [BFD Multi]), for MPLS LSPs [BFD LSP], and for PWE3		for IP ([BFD IP], [BFD Multi]), for MPLS LSPs [BFD LSP], and for PWE3
	[BFD VCCV]. BFD for MPLS-TP is currently evolving in the MPLS working		[BFD VCCV]. BFD for MPLS-TP is currently evolving in the MPLS working
	group (e.g. [MPLS-TP Ping BFD]).		group (e.g. [MPLS-TP Ping BFD]).
	BFD includes two main OAM functions, using two types of BFD packets:		BFD includes two main OAM functions, using two types of BFD packets:
	BFD Control packets, and BFD Echo packets.		BFD Control packets, and BFD Echo packets.
	4.2.2. BFD Control		4.2.2. BFD Control
	BFD supports a unidirectional connectivity check, using BFD control		BFD supports a bidirectional continuity check, using BFD control
	packets. BFD control packets are be sent in one of two modes:		packets, that are exchanged within a BFD session. BFD sessions
			operate in one of two modes:
	o Asynchronous mode: in this mode BFD control packets are sent		o Asynchronous mode: in this mode BFD control packets are sent
	periodically. When the receiver detects that no BFD control packet		periodically. When the receiver detects that no BFD control packet
	have been received during a predetermined period of time, a		have been received during a predetermined period of time, a
	failure is detected.		failure is detected.
	o Demand mode: in this mode, BFD control packets are sent on-demand.		o Demand mode: in this mode, BFD control packets are sent on-demand.
	Upon need, a system initiates a series of BFD control packets to		Upon need, a system initiates a series of BFD control packets to
	verify the link. BFD control packets are sent independently in		verify the link. BFD control packets are sent independently in
	each direction of the link.		each direction of the link.
	The transmission interval of BFD packets that are sent periodically,		Each of the end-points of the monitored path maintains its own
	is a result of negotiation between the two systems. Each BFD Control		session identification, called a Discriminator, both of which are
	packet includes the desired transmission interval, and the desired		included in the BFD Control Packets that are exchanged between the
	reception interval, allowing the two systems to agree on common		end-points. At the time of session establishment, the Discriminators
	intervals.		are exchanged between the two-end points. In addition, the
			transmission (and reception) rate is negotiated between the two end-
			points, based on information included in the control packets. These
			transmission rates may be renegotiated during the session.
	If no BFD Control packets are received during a fixed period of time		During normal operation of the session, i.e. no failures are
	called the Detection Time, the session is declared to be down. The		detected, the BFD session is in the Up state. If no BFD Control
	detection time is a function of the negotiated transmission time, and		packets are received during a fixed period of time, called the
	a parameter called Detect Mult. Detect Mult determines the number of		Detection Time, the session is declared to be Down. The detection
			time is a function of the negotiated transmission time, and a
			parameter called Detect Mult. Detect Mult determines the number of
	missing BFD Control packets that cause the session to be declared as		missing BFD Control packets that cause the session to be declared as
	down. This parameter is included in the BFD Control packet.		Down. This parameter is included in the BFD Control packet.
	The BFD Control packet also includes two fields that specify the
	transmitting and receiving systems, called My Discriminator and Your
	Discriminator, respectively.
	4.2.3. BFD Echo		4.2.3. BFD Echo
	The echo function is a bidirectional connectivity check. A BFD echo		The echo function is used for connectivity verification. A BFD echo
	packet is sent to a peer system, and is looped back to the		packet is sent to a peer system, and is looped back to the
	originator. The echo function can be used proactively, or on-demand.		originator. The echo function can be used proactively, or on-demand.
	4.3. LSP Ping		4.3. LSP Ping
	The IETF MPLS working group has defined OAM for MPLS LSPs. The		The IETF MPLS working group has defined OAM for MPLS LSPs. The
	requirements and framework of this effort was defined in [MPLS OAM		requirements and framework of this effort was defined in [MPLS OAM
	FW] and [MPLS OAM], respectively. The corresponding OAM mechanism		FW] and [MPLS OAM], respectively. The corresponding OAM mechanism
	that was defined in this context is LSP Ping [LSP Ping]. LSP ping is		defined, in this context, is LSP Ping [LSP Ping].
	used to detect data plain failures in MPLS LSPs. The transmitting LSR
	sends an echo request to a remote LSR, and in turn receives an echo		LSP Ping is based on ICMP Ping and just like its predecessor may be
	reply. LSP ping is used in one of two modes:		used in one of two modes:
	o "Ping" mode: In this mode LSP ping is used for end-to-end		o "Ping" mode: In this mode LSP ping is used for end-to-end
	connectivity verification between two LSRs.		connectivity verification between two LSRs.
	o "Traceroute" mode: This mode is used for hop-by-hop fault		o "Traceroute" mode: This mode is used for hop-by-hop fault
	localization.		localization.
			LSP Ping extends the basic ICMP Ping operation (of data-plane
			connectivity and continuity check) with functionality to verify
			data-plane vs. control-plane consistency for a Forwarding Equivalence
			Class (FEC) and also Maximum Transmission Unit (MTU) problems. The
			traceroute functionality may be used to isolate and localize the MPLS
			faults, using the Time-to-live (TTL) indicator to incrementally
			identify the sub-path of the LSP that is successfully traversed
			before the faulty link or node.
			It should be noted that LSP Ping does support unique identification
			of the LSP within an addressing domain. The identification is checked
			using the full FEC identification. LSP Ping is easily extensible to
			include additional information needed to support new functionality,
			by use of Type-Length-Value (TLV) constructs.
			LSP Ping supports both asynchronous, as well as, on-demand
			activation. In addition, extensions for LSP Ping are being defined
			for point-to-multipoint LSPs in [P2MP LSP Ping] and for MPLS Tunnels
			in [MPLS LSP Ping].
	4.4. PWE3 Virtual Circuit Connectivity Verification (VCCV)		4.4. PWE3 Virtual Circuit Connectivity Verification (VCCV)
	VCCV, as defined in [VCCV], maintains the connectivity status of a		VCCV, as defined in [VCCV], provides end-to-end fault detection
	pseudowire. VCCV is supported for both MPLS PWs and L2TPv3 PWs.		and diagnostics for PWs (regardless of the underlying tunneling
			technology). The VCCV switching function provides a control channel
			associated with each PW (based on the PW Associated Channel Header
			(ACH) which is defined in [PW ACH]), and allows sending OAM packets
			in-band with PW data (using CC Type 1: In-band VCCV).
	VCCV supports two possible Connectivity Verification (CV) types,		VCCV currently supports the following OAM mechanisms: ICMP Ping, LSP
	i.e., two modes of operation:		Ping, and BFD. ICMP and LSP Ping are IP encapsulated before being
			sent over the PW ACH. BFD for VCCV supports two modes of
			encapsulation - either IP/UDP encapsulated (with IP/UDP header) or
			PW-ACH encapsulated (with no IP/UDP header) and provides support to
			signal the AC status. The use of the VCCV control channel provides
			the context, based on the MPLS-PW label, required to bind and
			bootstrap the BFD session to a particular pseudo wire (FEC),
			eliminating the need to exchange Discriminator values.
	o ICMP Ping: In this mode the CV is performed using an ICMP ping		VCCV consists of two components: (1) signaled component to
	packet format, as defined in [ICMPv4] or [ICMPv6].		communicate VCCV capabilities as part of VC label, and (2) switching
			component to cause the PW payload to be treated as a control packet.
	o LSP Ping: In this mode the LSP Ping packet format, as defined in		VCCV is not directly dependent upon the presence of a control plane.
	[LSP Ping] is used for CV.		The VCCV capability negotiation may be performed as part of the PW
			signaling when LDP is used. In case of manual configuration of the
			PW, it is the responsibility of the operator to set consistent
			options at both ends.
	4.5. IP Performance Metrics (IPPM)		4.5. IP Performance Metrics (IPPM)
	4.5.1. Overview		4.5.1. Overview
	The IPPM working group [IPPM FW] in the IETF defines common criteria		The IPPM working group [IPPM FW] in the IETF defines common criteria
	and metrics for measuring performance of IP traffic. Some of the key		and metrics for measuring performance of IP traffic. Some of the key
	RFCs published by this working group have defined metrics for		RFCs published by this working group have defined metrics for
	measuring connectivity [rfc2678], delay [RFC2679, RFC 2681], and		measuring connectivity [rfc2678], delay [RFC2679, RFC 2681], and
	packet loss [RFC2681].		packet loss [RFC2681].
	The IPPM working group has defined not only metrics for performance		The IPPM working group has defined not only metrics for performance
	measurement, but also protocols that define how the measurement is		measurement, but also protocols that define how the measurement is
	carried out. The One-way Active Measurement Protocol [OWAMP] and the		carried out. The One-way Active Measurement Protocol [OWAMP] and the
	Two-Way Active Measurement Protocol [TWAMP] define a method and		Two-Way Active Measurement Protocol [TWAMP] define a method and
	protocol for measuring delay and packet loss in IP networks.		protocol for measuring delay and packet loss in IP networks.
			OWAMP [OWAMP] enables measurement of one-way characteristics of IP
			networks, such as one-way packet loss and one-way delay. For its
			proper operation OWAMP requires accurate time of day setting at its
			end points.
			TWAMP [TWAMP] is a similar protocol that enables measurement of two-
			way (round trip) characteristics. TWAMP does not require accurate
			time of day, and, furthermore, allows the use of a simple session
			reflector, making it an attractive alternative to OWAMP.
	OWAMP and TWAMP use two separate protocols: a Control plane protocol,		OWAMP and TWAMP use two separate protocols: a Control plane protocol,
	and a Test plane protocol.		and a Test plane protocol.
	4.5.2. OWAMP/TWAMP Control		4.5.2. Control and Test Protocols
	Each of these standards defines a Control protocol. This protocol is		OWAMP and TWAMP control protocols run over TCP, while the test
	layered over TCP, and is used to initiate measurement sessions, and		protocols run over UDP. The purpose of the control protocols is to
	to communicate their results.		initiate, start, and stop test sessions, and for OWAMP to fetch
			results. The test protocols introduce test packets (which contain
			sequence numbers and timestamps) along the IP path under test
			according to a schedule, and record statistics of packet arrival.
			Multiple sessions may be simultaneously defined, each with a session
			identifier, and defining the number of packets to be sent, the amount
			of padding to be added (and thus the packet size), the start time,
			and the send schedule (which can be either a constant time between
			test packets or exponentially distributed pseudo-random). Statistics
			recorded conform to the relevant IPPM RFCs.
	4.5.3. OWAMP/TWAMP Test		OWAMP and TWAMP test traffic is designed with security in mind. Test
			packets are hard to detect because they are simply UDP streams
			between negotiated port numbers, with potentially nothing static in
			the packets. OWAMP and TWAMP also include optional authentication
			and encryption for both control and test packets.
	The Test protocol is layered over UDP, and is used to measure delay		4.5.3. OWAMP
	and packet loss between the session endpoints. The Test session is
	initiated by a Request/Response negotiation, followed by a set of		OWAMP defines the following logical roles: Session-Sender, Session-
	active test packets that are used for the measurement.		Receiver, Server, Control-Client, and Fetch-Client. The Session-
			Sender originates test traffic that is received by the Session-
			Receiver. The Server configures and manages the session, as well as
			returning the results. The Control-Client initiates requests for
			test sessions, triggers their start, and may trigger their
			termination. The Fetch-Client requests the results of a completed
			session. Multiple roles may be combined in a single host - for
			example, one host may play the roles of Control-Client, Fetch-Client,
			and Session-Sender, and a second playing the roles of Server and
			Session-Receiver.
			In a typical OWAMP session the Control-Client establishes a TCP
			connection to port 861 of the Server, which responds with a server
			greeting message indicating supported security/integrity modes. The
			Control-Client responds with the chosen communications mode and the
			Server accepts the modes. The Control-Client then requests and fully
			describes a test session to which the Server responds with its
			acceptance and supporting information. More than one test session
			may be requested with additional messages. The Control-Client then
			starts a test session and the Server acknowledges. The Session-
			Sender then sends test packets with pseudorandom padding to the
			Session-Receiver until the session is complete or until the Control-
			client stops the session. Once finished, the Fetch-Client sends a
			fetch request to the server, which responds with an acknowledgement
			and immediately thereafter the result data.
			4.5.4. TWAMP
			TWAMP defines the following logical roles: session-sender, session-
			reflector, server, and control-client. These are similar to the
			OWAMP roles, except that the Session-Reflector does not collect any
			packet information, and there is no need for a Fetch-Client.
			In a typical TWAMP session the Control-Client establishes a TCP
			connection to port 862 of the Server, and mode is negotiated as in
			OWAMP. The Control-Client then requests sessions and starts them.
			The Session-Sender sends test packets with pseudorandom padding to
			the Session-Reflector which returns them with insertion of
			timestamps.
	4.6. ITU-T Y.1711		4.6. ITU-T Y.1711
	4.6.1. Overview		4.6.1. Overview
	As mentioned above (4.3.), the IETF defined LSP Ping as an OAM		As mentioned above (4.3.), the IETF defined LSP Ping as an OAM
	mechanism for MPLS. The ITU-T has also defined an OAM protocol for		mechanism for MPLS. The ITU-T has also defined an OAM protocol for
	MPLS, defined in [ITU-T Y.1711]. The standard defines mechanisms for		MPLS, defined in recommendation [ITU-T Y.1711]. This recommendation
	connectivity verification and fast failure detection, as well as		defines mechanisms for connectivity verification and fast failure
	mechanism for reporting defects that have been identified in an LSP.		detection, as well as mechanism for reporting defects that have been
			identified in an LSP.
	MPLS OAM packets per Y.1711 are detected by a reserved MPLS label		MPLS OAM packets per Y.1711 are detected by a reserved MPLS label
	value. The reserved value is 14, and is defined in [OAM Label] as the		value. The reserved value is 14, and is defined in [OAM Label] as the
	'OAM Alert Label'.		'OAM Alert Label'.
	4.6.2. Connectivity Verification (CV)		4.6.2. Connectivity Verification (CV)
	The CV function is used to detect connectivity defects in an LSP. CV		The CV function is used to detect connectivity defects in an LSP. CV
	frames are sent proactively at a rate of 1 per second. Each frame		frames are sent proactively at a rate of 1 per second. Each frame
	contains the Trail-Termination Source Identifier (TTSI), indicating		contains the Trail-Termination Source Identifier (TTSI), indicating
	skipping to change at page 16, line 9		skipping to change at page 19, line 17
	The BDI function is used to inform the LSR at an LSP trail		The BDI function is used to inform the LSR at an LSP trail
	termination source point about a defect condition in the forward		termination source point about a defect condition in the forward
	direction of an LSP. The LSR at the LSP trail termination sink point		direction of an LSP. The LSR at the LSP trail termination sink point
	transmits the BDI to the upstream LSR through the return path. BDI		transmits the BDI to the upstream LSR through the return path. BDI
	packets are sent at the same transmission rate as FDI.		packets are sent at the same transmission rate as FDI.
	4.7. ITU-T Y.1731		4.7. ITU-T Y.1731
	4.7.1. Overview		4.7.1. Overview
	The [ITU-T Y.1731] is a protocol for Ethernet OAM. It is presented in		The [ITU-T Y.1731] defines a protocol for Ethernet OAM. It is
	this document as a reference point, since the OAM mechanisms that are		presented in this document as a reference point. Y.1731 defines
	currently being defined by the IETF for MPLS-TP are in many ways		various OAM functions, including continuity and connectivity
	based on this standard. The standard defines various OAM functions,		verification, and functions for performance monitoring.
	including unidirectional and bidirectional continuity check, and
	functions for performance monitoring.
	4.7.2. ETH-CC		4.7.2. ETH-CC
	The Ethernet Continuity Check function is a proactive function that		The Ethernet Continuity Check function is a proactive function that
	allows a MEP to detect loss of continuity with any of the other MEPs		allows a MEP to detect loss of continuity with any of the other MEPs
	in the MEG. This function also allows detection of other defect		in the MEG. This function also allows detection of other defect
	conditions, such as unintended connectivity between two MEGs. The		conditions, such as unintended connectivity between two MEGs. The
	ETH-CC function is used for one of three possible applications: fault		ETH-CC function is used for one of three possible applications: fault
	management, performance monitoring (see 4.6.10.), and protection		management, performance monitoring (see 4.6.10.), and protection
	switching.		switching.
	skipping to change at page 20, line 43		skipping to change at page 23, line 43
	Link monitoring provides an event notification function, allowing		Link monitoring provides an event notification function, allowing
	peer devices to communicate defect conditions and diagnostic		peer devices to communicate defect conditions and diagnostic
	information.		information.
	4.10. MPLS-TP OAM		4.10. MPLS-TP OAM
	4.10.1. Overview		4.10.1. Overview
	The MPLS working group is currently working on defining the OAM		The MPLS working group is currently working on defining the OAM
	requirements and mechanisms for MPLS-TP. The requirements of MPLS-TP		toolset that fulfill the requirements for MPLS-TP OAM. The full set
	OAM are defined in [MPLS-TP OAM], and are described below.		of requirements for MPLS-TP OAM are defined in [MPLS-TP OAM], and
			include both general requirements for the behavior of the OAM
			mechanisms and a set of operations that should be supported by the
			OAM toolset. The set of mechanisms required are further elaborated
			in [MPLS-TP OAM FW], that describes the general architecture of the
			OAM system as well as giving overviews of the functionality of the
			OAM toolset.
	MPLS-TP OAM traffic uses a Generic Associated Channel (G-ACh),		Some of the basic requirements for the OAM toolset for MPLS-TP are:
	defined in [G-ACh]. This standard defines that MPLS-TP OAM traffic
	uses:
	o An Associated Channel Header (ACH), also known as a Control Word		o MPLS-TP OAM must be able to support both an IP based and non-IP
	in the PWE3 terminology, is a 4-byte header that is added to OAM		based environment. If the network is IP based, i.e. IP routing and
			forwarding are available, then the MPLS-TP OAM toolset should rely
			on the IP routing and forwarding capabilities. On the other hand,
			in environments where IP functionality is not available, the OAM
			tools must still be able to operate without dependence on IP
			forwarding and routing.
			o OAM packets and the user traffic are required to be congruent
			(i.e. OAM packets are transmitted in-band) and there is a need to
			differentiate OAM packets from user-plane ones. Inherent in this
			requirement is the principle that MPLS-TP OAM be independent of
			any existing control-plane, although it should not preclude use of
			the control-plane functionality.
			4.10.2. Generic Associated Channel
			In order to address the requirement for in-band transmission of MPLS-
			TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh),
			defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based
			on the same concepts as the PWE3 ACH and VCCV mechanisms. However,
			to address the needs of LSPs as differentiated from PW, the following
			concepts were defined for [G-ACh]:
			o An Associated Channel Header (ACH), that uses a format similar to
			the PW Control Word, is a 4-byte header that is added to OAM
	packets.		packets.
	o A Generic Associated Label (GAL). The GAL is a reserved MPLS label		o A Generic Associated Label (GAL). The GAL is a reserved MPLS label
	value. The reserved value is 13, and identifies the packet as an		value. The reserved value is 13, and indicates the existence of
	MPLS-TP OAM packet. A GAL indicates the existence of the ACH		the ACH immediately after it.
	immediately after it.
	The analysis in [OAM Analysis] discusses various OAM mechanism that		4.10.3. MPLS-TP OAM Toolset
	were considered in order to satisfy the requirements in [MPLS-TP
	OAM]. The MPLS working group currently plans to use a mixture of OAM		To address the functionality that is required of the OAM toolset, the
			MPLS WG conducted an analysis of the existing IETF and ITU-T OAM
			mechanisms and their ability to fulfill the required functionality.
			The conclusions of this analysis are documented in [OAM Analysis].
			The MPLS working group currently plans to use a mixture of OAM
	mechanisms that are based on various existing standards, and adapt		mechanisms that are based on various existing standards, and adapt
	them to the requirements of [MPLS-TP OAM]. Some of the main building		them to the requirements of [MPLS-TP OAM]. Some of the main building
	blocks of this solution are based on:		blocks of this solution are based on:
	o Bidirectional Forwarding Detection ([BFD], [BFD LSP]) for		o Bidirectional Forwarding Detection ([BFD], [BFD LSP]) for
	proactive connectivity verification.		proactive continuity check and connectivity verification.
	o LSP Ping as defined in [LSP Ping] for on-demand connectivity		o LSP Ping as defined in [LSP Ping] for on-demand connectivity
	verification.		verification.
	o Y.1731 per the [ITU-T Y.1731], mainly for performance measurement.		o New protocol packets, using G-ACH, to address different
			functionality.
	The requirements of MPLS-TP OAM are summarized below.		o Performance measurement protocols that are based on the
			functionality that is described in [ITU-T Y.1731].
	4.10.2. Continuity Checks		The following sub-sections describe the OAM tools that will be
			defined for MPLS-TP as described in [MPLS-TP OAM FW].
	The continuity check is a proactive function that allows an End Point		4.10.3.1. Continuity Check and Connectivity Verification
	to determine whether or not it receives traffic from its peer End
	Points.
	4.10.3. Connectivity Verification		Continuity Check and Connectivity Verification (CC-V) are OAM
			operations generally used in tandem, and compliment each other. These
			functions are generally run proactively, but may also be used on-
			demand, either due to bandwidth considerations or for diagnoses of a
			specific condition. Proactively [MPLS-TP OAM] states that the
			function should allow the MEPs to monitor the liveness and
			connectivity of a transport path. In on-demand mode, this function
			should support monitoring between the MEPs and, in addition, between
			a MEP and MIP.[MPLS-TP OAM FW] highlights the need for the CC-V
			messages to include unique identification of the MEG that is being
			monitored and the MEP that originated the message. The function, both
			proactively and in on-demand mode, need to be transmitted at regular
			rates pre-configured by the operator.
	The connectivity verification is a function that allows an End Point		4.10.3.2. Diagnostic Tests
	to verify its connectivity to a peer node. The connectivity check is
	performed by sending a connectivity verification PDU to the peer
	node, and receiving a reply within an expected time frame. This
	function can be performed proactively or on-demand.
	4.10.4. Diagnostic Tests		Diagnostic testing is a protocol that allows a network to send
			special test data on a transport path. For example, this could be
			used as part of bandwidth utilization measurement.
	This function allows an End Point to perform an on-demand test, e.g.,		4.10.3.3. Route Tracing
	for bandwidth measurement.
	4.10.5. Route Tracing		[MPLS-TP OAM] defines that there is a need for functionality that
			would allow a path end-point to identify the intermediate and end-
			points of the path. This function would be used in on-demand mode.
			Normally, this path will be used for bidirectional PW, LSP, and
			sections, however, unidirectional paths may be supported only if a
			return path exists.
	This on-demand function is used for path discovery and for locating		4.10.3.4. Lock Instruct
	link failures.
	4.10.6. Lock Instruct		The Lock Instruct function is used to notify a transport path end-
			point of an administrative need to disable the transport path. This
			functionality will generally be used in conjunction with some
			intrusive OAM function, e.g. Performance measurement, Diagnostic
			testing, to minimize the side-effect on user data traffic.
	The lock instruct function allows an End Point to instruct its peers		4.10.3.5. Lock Reporting
	to enter an administrative status where all traffic is halted except
	the test traffic and OAM PDUs.
	4.10.7. Lock Reporting		Lock Reporting is a function used by an end-point of a path to report
			to its far-end end-point that a lock condition has been affected on
			the path.
	This function allows an Intermediate Point to report to an End Point		4.10.3.6. Alarm Reporting
	about a lock condition.
	4.10.8. Alarm Reporting		Alarm Reporting is a function used by an intermediate point of a
			path, that becomes aware of a fault on the path, to report to the
			end-points of the path. [MPLS-TP OAM FW] states that this may occur
			as a result of a defect condition discovered at a server sub-layer.
			This generates an Alarm Indication Signal (AIS) that continues until
			the fault is cleared. The consequent action of this function is
			detailed in [MPLS-TP OAM FW].
	This function allows an Intermediate Point to report to an End Point		4.10.3.7. Remote Defect Indication
	about a defect condition.
	4.10.9. Remote Defect Indication		Remote Defect Indication (RDI) is used proactively by a path end-
			point to report to its peer end-point that a defect is detected on a
			bidirectional connection between them. [MPLS-TP OAM] points out that
			this function may be applied to a unidirectional LSP only if there a
			return path exists. [MPLS-TP OAM FW] points out that this function
			is associated with the proactive CC-V function.
	This is a proactive function that allows the sender to indicate that		4.10.3.8. Client Failure Indication
	it encountered a defect conditions.
	4.10.10. Client Failure Indication		Client Failure Indication (CFI) is defined in [MPLS-TP OAM] to allow
			the propagation information from one edge of the network to the
			other. The information concerns a defect to a client, in the case
			that the client does not support alarm notification.
	This function allows the MPLS-TP network to relay information about a		4.10.3.9. Packet Loss Measurement
	fault condition in a client network, allowing the failure indication
	to propagate from end to end over the MPLS-TP network.
	4.10.11. Packet Loss Measurement		Packet Loss Measurement is a function used to verify the quality of
			the service. This function indicates the ratio of packets that are
			not delivered out of all packets that are transmitted by the path
			source.
	This function measures the packet loss ratio between two peer End		There are two possible ways of determining this measurement:
	Points. It can be performed proactively or on-demand.
	4.10.12. Packet Delay Measurement		o Using OAM packets, it is possible to compute the statistics based
			on a series of OAM packets. This, however, has the disadvantage of
			being artificial, and may not be representative since part of the
			packet loss may be dependent upon packet sizes.
	This function measures the frame delay between two peer End Points.		o Sending delimiting messages for the start and end of a measurement
	Two modes of operation are supported, one-way DM, and two-way DM.		period during which the source and sink of the path count the
			packets transmitted and received. After the end delimiter, the
			ratio would be calculated by the path OAM entity.
			4.10.3.10. Packet Delay Measurement
			Packet Delay Measurement is a function that is used to measure one-
			way or two-way delay of a packet transmission between a pair of the
			end-points of a path (PW, LSP, or Section). Where:
			o One-way packet delay is the time elapsed from the start of
			transmission of the first bit of the packet by a source node until
			the reception of the last bit of that packet by the destination
			node.
			o Two-way packet delay is the time elapsed from the start of
			transmission of the first bit of the packet by a source node until
			the reception of the last bit of the loop-backed packet by the
			same source node, when the loopback is performed at the packet's
			destination node.
			Similarly to the packet loss measurement this could be performed in
			either of the two ways outlined above.
	4.11. Summary of OAM Functions		4.11. Summary of OAM Functions
	Table 3 summarizes the OAM functions that are supported in each of		Table 3 summarizes the OAM functions that are supported in each of
	the standards that were analyzed in this section.		the standards that were analyzed in this section.
	+-----------+-------+--------+--------+-----------+-------+--------+		+-----------+-------+--------+--------+-----------+-------+--------+
	| Standard |Unidire|Bidirect|Path |Defect |Perform|Other |		| Standard |Continu|Connecti|Path |Defect |Perform|Other |
	| |ctional|ional |Discover|Indications|ance |Function|		| |ity |vity |Discover|Indications|ance |Function|
	| |Connect|Connecti|y | |Monitor|s |		| |Check |Verifica|y | |Monitor|s |
	| |ivity |vity | | |ing | |		| | |tion | | |ing | |
	| |Check |Check | | | | |
	+-----------+-------+--------+--------+-----------+-------+--------+		+-----------+-------+--------+--------+-----------+-------+--------+
	|ICMP Ping | | Echo | | | | |		|ICMP Ping | |Echo | | | | |
	+ --------- + ----- + ------ + ------ + --------- + ----- + ------ +		+ --------- + ----- + ------ + ------ + --------- + ----- + ------ +
	|BFD |BFD |BFD | | | | |		|BFD |BFD |BFD | | | | |
	| |Control|Echo | | | | |		| |Control|Echo | | | | |
	+ --------- + ----- + ------ + ------ + --------- + ----- + ------ +		+ --------- + ----- + ------ + ------ + --------- + ----- + ------ +
	|LSP Ping | |"Ping" |"Tracero| | | |		|LSP Ping | |"Ping" |"Tracero| | | |
	| | |mode |ute" | | | |		| | |mode |ute" | | | |
	| | | |mode | | | |		| | | |mode | | | |
	+ --------- + ----- + ------ + ------ + --------- + ----- + ------ +		+ --------- + ----- + ------ + ------ + --------- + ----- + ------ +
	|PW VCCV | |VCCV | | | | |		|PW VCCV | |VCCV | | | | |
	+ --------- + ----- + ------ + ------ + --------- + ----- + ------ +		+ --------- + ----- + ------ + ------ + --------- + ----- + ------ +
	skipping to change at page 24, line 16		skipping to change at page 29, line 5
	|OAM | | |Tracing | Reporting |-DM | tic Tes|		|OAM | | |Tracing | Reporting |-DM | tic Tes|
	| | | | |-Client | | s |		| | | | |-Client | | s |
	| | | | | Failure | |-Lock |		| | | | | Failure | |-Lock |
	| | | | | Indication| | |		| | | | | Indication| | |
	| | | | |-Remote | | |		| | | | |-Remote | | |
	| | | | | Defect | | |		| | | | | Defect | | |
	| | | | | Indication| | |		| | | | | Indication| | |
	+-----------+-------+--------+--------+-----------+-------+--------+		+-----------+-------+--------+--------+-----------+-------+--------+
	Table 3 Summary of OAM Functions		Table 3 Summary of OAM Functions
	4.12. Summary of Unidirectional Connectivity Check Mechanisms		4.12. Summary of Continuity Check Mechanisms
	A key element in some of the OAM standards that are analyzed in this		A key element in some of the OAM standards that are analyzed in this
	document is the unidirectional connectivity check. It is thus		document is the continuity check. It is thus interesting to present a
	interesting to present a more detailed comparison of the connectivity		more detailed comparison of the connectivity check mechanisms defined
	check mechanisms defined in OAM standards. Table 4 can be viewed as		in OAM standards. Table 4 can be viewed as an extension of Table 3,
	an extension of Table 3, but is presented separately for convenience.		but is presented separately for convenience. The table compares the
	The table compares the OAM standards that support a unidirectional		OAM standards that support a continuity check. MPLS-TP is not
	connectivity check. MPLS-TP is not included in the comparison, as the		included in the comparison, as the continuity check mechanism in
	continuity check mechanism in MPLS-TP has not yet been defined.		MPLS-TP has not yet been defined.
	The "Tx Interval" column in the table specifies the period between		The "Tx Interval" column in the table specifies the period between
	two consequent message transmissions, while the "Source Identifier"		two consequent message transmissions, while the "Source Identifier"
	column specifies the name of the field in the OAM packet that is used		column specifies the name of the field in the OAM packet that is used
	as the identifier of the transmitter. The "Error Codes" column		as the identifier of the transmitter. The "Error Codes" column
	specifies the possible error codes when the unidirectional		specifies the possible error codes when the unidirectional
	connectivity check detects a failure.		connectivity check detects a failure.
	+-----------+-------+--------+---+--------+------------------------+		+-----------+-------+--------+---+--------+------------------------+
	| |Mechani|Tx |UC/|Source | Error |		| |Mechani|Tx |UC/|Source | Error |
	skipping to change at page 28, line 7		skipping to change at page 32, line 39
	[ITU-T Y.1711]"Operation & Maintenance mechanism for MPLS networks",		[ITU-T Y.1711]"Operation & Maintenance mechanism for MPLS networks",
	February 2004.		February 2004.
	[IEEE 802.3ah]"Media Access Control Parameters, Physical Layers, and		[IEEE 802.3ah]"Media Access Control Parameters, Physical Layers, and
	Management Parameters for Subscriber Access Networks",		Management Parameters for Subscriber Access Networks",
	clause 57, September 2004.		clause 57, September 2004.
	8.2. Informative References		8.2. Informative References
	[P2MP Ping] Saxena, S., Farrel, A. , Yasukawa, S., "Detecting Data
	Plane Failures in Point-to-Multipoint Multiprotocol
	Label Switching (MPLS) - Extensions to LSP Ping",
	draft-ietf-mpls-p2mp-lsp-ping, March 2010.
	[OAM Soup] Andersson, L., Van Helvoort, H., Bonica, R., Romascanu,		[OAM Soup] Andersson, L., Van Helvoort, H., Bonica, R., Romascanu,
	D., Mansfield, S., "The OAM Acronym Soup", draft-ietf-		D., Mansfield, S., "The OAM Acronym Soup", draft-ietf-
	opsawg-mpls-tp-oam-def, June 2010.		opsawg-mpls-tp-oam-def, June 2010.
	[ITU-T G.806] "Characteristics of transport equipment - Description		[OAM Analysis] Sprecher, N., Bellagamba, E., Weingarten, Y., "MPLS-TP
	methodology and generic functionality", January 2009.		OAM Analysis", draft-ietf-mpls-tp-oam-analysis, July
			2010.
			[MPLS-TP OAM FW] Busi, I., Niven-Jenkins, B., Allan, D., "MPLS-TP OAM
			Framework", work-in-progress, draft-ietf-mpls-tp-oam-
			framework, July, 2010.
	[MPLS-TP Term]Van Helvoort, H., Andersson, L., Sprecher, N., "A		[MPLS-TP Term]Van Helvoort, H., Andersson, L., Sprecher, N., "A
	Thesaurus for the Terminology used in Multiprotocol		Thesaurus for the Terminology used in Multiprotocol
	Label Switching Transport Profile (MPLS-TP)		Label Switching Transport Profile (MPLS-TP)
	drafts/RFCs and ITU-T's Transport Network		drafts/RFCs and ITU-T's Transport Network
	Recommendations", draft-ietf-mpls-tp-rosetta-stone,		Recommendations", draft-ietf-mpls-tp-rosetta-stone,
	May 2010.		May 2010.
	[MPLS-TP Ping BFD] Bahadur, N., Aggarwal, R., Ward, D., Nadeau, T.,		[MPLS-TP Ping BFD] Bahadur, N., Aggarwal, R., Ward, D., Nadeau, T.,
	Sprecher, N., Weingarten, Y., "LSP-Ping and BFD		Sprecher, N., Weingarten, Y., "LSP-Ping and BFD
	encapsulation over ACH", draft-ietf-mpls-tp-lsp-ping-		encapsulation over ACH", draft-ietf-mpls-tp-lsp-ping-
	bfd-procedures, March 2010.		bfd-procedures, March 2010.
	[OAM Analysis] Sprecher, N., Bellagamba, E., Weingarten, Y., "MPLS-TP		[P2MP Ping] Saxena, S., Farrel, A. , Yasukawa, S., "Detecting Data
	OAM Analysis", draft-ietf-mpls-tp-oam-analysis, July		Plane Failures in Point-to-Multipoint Multiprotocol
	2010.		Label Switching (MPLS) - Extensions to LSP Ping",
			draft-ietf-mpls-p2mp-lsp-ping, March 2010.
			[ITU-T G.806] "Characteristics of transport equipment - Description
			methodology and generic functionality", January 2009.
	Authors' Addresses		Authors' Addresses
	Tal Mizrahi		Tal Mizrahi
	Marvell		Marvell
			6 Hamada St.
			Yokneam, 20692
			Israel
	Email: talmi@marvell.com		Email: talmi@marvell.com
			Nurit Sprecher
			Nokia Siemens Networks
			3 Hanagar St. Neve Ne'eman B
			Hod Hasharon, 45241
			Israel
			Email: nurit.sprecher@nsn.com
			Elisa Bellagamba
			Ericsson
			6 Farogatan St.
			Stockholm, 164 40
			Sweden
			Phone: +46 761440785
			Email: elisa.bellagamba@ericsson.com
			Yaacov Weingarten
			Nokia Siemens Networks
			3 Hanagar St. Neve Ne'eman B
			Hod Hasharon, 45241
			Israel
			Phone: +972-9-775 1827
			Email: yaacov.weingarten@nsn.com
End of changes. 82 change blocks.
	246 lines changed or deleted		489 lines changed or added
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/