draft-ietf-mpls-tp-oam-requirements-00.txt		draft-ietf-mpls-tp-oam-requirements-01.txt
	MPLS Working Group M. Vigoureux (Editor)
	Internet Draft Alcatel-Lucent
	Intended status: Informational
	Expires: May 2009 D. Ward (Editor)
	Cisco Systems, Inc.
	M. Betts (Editor)		MPLS Working Group M. Vigoureux, Ed.
			Internet-Draft Alcatel-Lucent
			Intended status: Informational D. Ward, Ed.
			Expires: September 10, 2009 Cisco Systems, Inc.
			M. Betts, Ed.
	Nortel Networks		Nortel Networks
			March 9, 2009
	November 28, 2008
	Requirements for OAM in MPLS Transport Networks		Requirements for OAM in MPLS Transport Networks
	draft-ietf-mpls-tp-oam-requirements-00		draft-ietf-mpls-tp-oam-requirements-01
	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 other		Task Force (IETF), its areas, and its working groups. Note that
	groups may also distribute working documents as Internet-Drafts.		other groups may also distribute working documents as Internet-
			Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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 May 28, 2009.		This Internet-Draft will expire on September 10, 2009.
	Abstract		Copyright Notice
	This document lists the requirements for Operations, Administration		Copyright (c) 2009 IETF Trust and the persons identified as the
	and Maintenance functionality in MPLS networks that are used for		document authors. All rights reserved.
	packet transport services and network operations.
	These requirements are derived from the set of requirements specified		This document is subject to BCP 78 and the IETF Trust's Legal
	by ITU-T and first published in the ITU-T Supplement Y.Sup4 [5].		Provisions Relating to IETF Documents in effect on the date of
			publication of this document (http://trustee.ietf.org/license-info).
			Please review these documents carefully, as they describe your rights
			and restrictions with respect to this document.
	Conventions used in this document		Abstract
			This document lists the requirements for the Operations,
			Administration and Maintenance functionality of MPLS Transport
			Profile. These requirements apply to pseudowires, Label Switched
			Paths, and Sections. Architectural, functional and operational
			requirements are covered in this document.
			Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [1].		document are to be interpreted as described in RFC 2119 [1].
	Table of Contents		Table of Contents
	1. Introduction...................................................2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Terminology...............................................3		1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2. Definitions...............................................3		1.2. Contributing Authors . . . . . . . . . . . . . . . . . . . 5
	1.3. Context and Motivations...................................4		2. OAM Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
	2. OAM Requirements...............................................5		2.1. Architectural Requirements . . . . . . . . . . . . . . . . 6
	2.1. Architectural Requirements................................5		2.1.1. Independence . . . . . . . . . . . . . . . . . . . . . 6
	2.2. Functional Requirements...................................7		2.1.2. Addressing, Routing and Forwarding . . . . . . . . . . 6
	2.2.1. General requirements.................................8		2.1.3. Interoperability and Interworking . . . . . . . . . . 6
	2.2.2. Connectivity and Continuity Verification.............8		2.1.4. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7
	2.2.3. Client Failure Indication............................8		2.1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.2.4. Remote Defect Indication.............................8		2.2. Functional Requirements . . . . . . . . . . . . . . . . . 7
	2.2.5. Alarm Suppression....................................8		2.2.1. General Requirements . . . . . . . . . . . . . . . . . 8
	2.2.6. Packet Loss..........................................9		2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 8
	2.2.7. Delay Measurement....................................9		2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 9
	2.2.8. Route Determination..................................9		2.2.4. Diagnostic . . . . . . . . . . . . . . . . . . . . . . 9
	2.2.9. Diagnostic..........................................10		2.2.5. Adjacency . . . . . . . . . . . . . . . . . . . . . . 9
	2.3. Operational Requirements.................................10		2.2.6. Route Tracing . . . . . . . . . . . . . . . . . . . . 10
	2.4. Performance Requirements.................................11		2.2.7. Lock . . . . . . . . . . . . . . . . . . . . . . . . . 10
	3. Security Considerations.......................................11		2.2.8. Alarm Notification . . . . . . . . . . . . . . . . . . 10
	4. Congestion Considerations.....................................12		2.2.9. Client Failure Indication . . . . . . . . . . . . . . 11
	5. IANA Considerations...........................................12		2.2.10. Remote Defect Indication . . . . . . . . . . . . . . . 11
	6. Acknowledgments...............................................12		2.2.11. Packet Loss . . . . . . . . . . . . . . . . . . . . . 11
	7. References....................................................13		2.2.12. Delay Measurement . . . . . . . . . . . . . . . . . . 12
	7.1. Normative References.....................................13		2.3. Operational Requirements . . . . . . . . . . . . . . . . . 12
	7.2. Informative References...................................13		3. Congestion Considerations . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses...............................................13		4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	Contributing Authors' Addresses..................................14		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	Intellectual Property Statement..................................15		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
	Disclaimer of Validity...........................................16		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	Copyright Statement..............................................17		7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
			7.2. Informative References . . . . . . . . . . . . . . . . . . 15
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	This document lists the requirements for Operations, Administration		In the context of MPLS Transport Profile (MPLS-TP, see [5] and [6]),
	and Maintenance functionality in MPLS networks that are used for		the rationales for Operations, Administration and Maintenance (OAM)
	packet transport services and network operations.		mechanisms are twofold as they can serve:
	1.1. Terminology
	AC Attachment Circuit
	CSF Client Signal Fail
	FCAPS Fault, Configuration, Accounting, Performance, Security
	LER Label Edge Router
	LSP Label Switched Path
	LSR Label Switching Router
	ME Maintenance Entity
	MEP Maintenance End Point
	MIP Maintenance Intermediate Point
	MP Maintenance Point
	MS-PW Multi Segment Pseudowire
	OAM Operations, Administration and Maintenance		o as a network-oriented mechanism (used by a transport network
			operator) to monitor his network infrastructure and to implement
			internal mechanisms in order to enhance the general behaviour and
			the level of performance of his network (e.g., protection
			mechanism in case of node or link failure). For example fault
			localization is typically associated to this use case.
	PE Provider Edge		o as a service-oriented mechanism (used by a transport service
			provider) to monitor offered services to end customers in order to
			be able to react rapidly in case of a problem and to be able to
			verify some of the Service Level Agreements (SLAs) parameters
			(e.g., using performance monitoring) negotiated with the end
			customer. Note that a transport service could be provided over
			several networks or administrative domains that may not be all
			owned and managed by the same transport service provider.
	PSN Packet Switched Network		More generally, OAM is an important and fundamental functionality in
			transport networks as it contributes to:
	PW Pseudowire		o the reduction of operational complexity and costs, by allowing
			efficient and automatic detection, localisation, handling, and
			diagnosis of defects, and by minimizing service interruptions and
			operational repair times.
	SLA Service Level Agreement		o the enhancement of network availability, by ensuring that defects,
			for example resulting in misdirected customer traffic, and faults,
			are detected, diagnosed and dealt with before a customer reports
			the problem.
	SS-PW Single Segment Pseudowire		o meet service and performance objectives, by running OAM
			functionality which allows SLA verification in a multi-maintenance
			domain environment and allows the determination of service
			degradation due, for example, to packet delay or packet loss.
	S-PE PW Switching Provider Edge		This document lists the requirements for the OAM functionality of
			MPLS-TP. These requirements apply to pseudowires (PWs), Label
			Switched Paths (LSPs), and Sections.
	T-PE PW Terminating Provider Edge		These requirements are derived from a set of requirements specified
			by ITU-T and first published in the ITU-T Supplement Y.Sup4 [7].
	TCME Tandem Connection Maintenance Entity		By covering transport specificities, these requirements stand as a
			complement to those identified in RFC 4377 [8].
	1.2. Definitions		1.1. Definitions
	In this document we refer to a fault as the inability of a function		In this document we refer to a fault as the inability of a function
	to perform a required action. This does not include an inability due		to perform a required action. This does not include an inability due
	to preventive maintenance, lack of external resources, or planned		to preventive maintenance, lack of external resources, or planned
	actions. See also ITU-T G.806 [3].		actions. See also ITU-T G.806 [2].
	In this document we refer to a defect as the situation for which		In this document we refer to a defect as the situation for which
	density of anomalies has reached a level where the ability to perform		density of anomalies has reached a level where the ability to perform
	a required function has been interrupted. See also ITU-T G.806 [3].		a required function has been interrupted. See also ITU-T G.806 [2].
	In this document, we refer to MPLS Transport Profile (MPLS-TP) as the
	set of MPLS functions used to support packet transport services and
	network operations.
	In this document we refer to a MPLS Section as a network segment
	between two LSRs that are immediately adjacent at the MPLS layer.
	For definitions of OAM functional components such as Maintenance
	Point, Maintenance End Point and Maintenance Intermediate Point,
	please refer to [7].
	Additional definitions can also be found in [8].
	1.3. Context and Motivations		In this document we refer to a Label Edge Router (LER), for a given
			LSP or Section, and to a PW Terminating Provider Edge (T-PE), for a
			given PW, as an End Point. Further, we refer to a Label Switching
			Router (LSR), for a given LSP, and to a PW Switching Provider Edge
			(S-PE), for a given PW, as an Intermediate Point. This document does
			not make any distinction between End Points (e.g., source and
			destination) as it can be inferred from the context of the sentences.
	Important attributes of MPLS-TP are that		In this document we use the term "node" as a general referral to End
			Points and Intermediate Points.
	o it is able to function regardless of which client signals are		Other definitions, relating to MPLS-TP, can be found in [6].
	using its connectivity service or over which transmission media it
	is running. The client, transport network and server layers are,
	from a functional point of view, independent layer networks. That
	is, demarcation points exist between MPLS-TP and the client layer,
	and between MPLS-TP and the underlying server layer.
	o it provides means to commit to Service Level Agreements (SLAs)		1.2. Contributing Authors
	negotiated with customers, as well as means to monitor compliance
	with these SLAs.
	o it is consistent with existing transport network OAM models.		The editors gratefully acknowledge the contributions of Matthew
			Bocci, Italo Busi, Thomas Dietz, Huub van Helvoort, Wataru Imajuku,
			Marc Lasserre, Lieven Levrau, Han Li, Julien Meuric, Philippe Niger,
			Benjamin Niven-Jenkins, Jing Ruiquan, Nurit Sprecher, Yuji Tochio,
			Satoshi Ueno and Yaacov Weingarten.
	In the context of MPLS-TP, the rationale for OAM mechanisms are		2. OAM Requirements
	twofold as they can serve:
	o as a network-oriented mechanism (used by a transport network		This section lists the requirements by which the OAM functionality of
	operator) to monitor his network infrastructure and to implement		MPLS-TP should abide. Note that some requirements for this
	internal mechanisms in order to enhance the general behaviour and		application of MPLS are similar to some of those listed in RFC 4377
	the level of performance of his network (e.g. protection mechanism		[8].
	in case of node or link failure). For example fault localization
	is typically associated to this use case.
	o as a service-oriented mechanism (used by a transport service		The requirements listed below may be met by one or more OAM
	provider) to monitor his offered services to end customers in		protocols; the definition or selection of these protocols is outside
	order to be able to react rapidly in case of a problem and to be		the scope of this document.
	able to verify some of the SLA parameters (i.e. performance
	monitoring) negotiated with the end customer. Note that a
	transport service could be provided over several networks or
	administrative domains that may not be all owned and managed by
	the same transport service provider.
	More generally, OAM is an important and fundamental functionality in		2.1. Architectural Requirements
	transport networks as it contributes to:
	o the reduction of operational complexity and costs, by allowing		2.1.1. Independence
	efficient and automatic detection, localisation, handling, and
	diagnosis of defects, and by minimizing service interruptions and
	operational repair times.
	o the enhancement of network availability, by ensuring that defects,		OAM functions SHOULD be independent of the underlying tunnelling or
	for example resulting in misdirected customer traffic are		point-to-point technology or transmission media.
	detected, diagnosed and dealt with before a customer reports the
	problem.
	o meet service and performance objectives, by running OAM		OAM functions SHOULD be independent of the service a PW may emulate.
	functionality which allows SLA verification in a multi-maintenance
	domain environment and allows the determination of service
	degradation due to, for example, packet delay or packet loss.
	This is achieved through the support of FCAPS functionality, as		The set of OAM functions operated on a PW, LSP or Section SHOULD be
	described in ITU-T M.3400 [2], itself relying on OAM related		independent of the set of OAM functions operated on a different PW,
	information.		LSP or Section. In other words, only the OAM functions available for
			e.g., a LSP should be used to achieve the OAM objectives for that
			LSP. Note that independence should not be understood here in terms
			of isolation as there can be interactions between OAM functions
			operated on e.g., a LSP and on another LSP or on a PW.
	2. OAM Requirements		OAM functions MUST operate and be configurable even in the absence of
			a control plane. Conversely, OAM functions SHOULD be configurable as
			part of connectivity (e.g., LSP or PW) management. Means for
			configuring OAM functions and for connectivity management are outside
			the scope of this document.
	This section lists the requirements by which the OAM functionality of		2.1.2. Addressing, Routing and Forwarding
	MPLS-TP should abide. Some requirements for this application are
	similar to some of those listed in RFC 4377 [6].
	The requirements listed below may be met by one or more OAM		The OAM functionality may be deployed in a variety of environments.
	protocols, the definition or selection of these protocols is outside
	the scope of this document. However, the specified solution MUST
	inter-work with the existing MPLS and PW OAM protocols.
	2.1. Architectural Requirements		o In some environments (e.g., IP/MPLS environments), IP routing and
			forwarding capabilities are inherently present. In this case, the
			OAM functionality MUST support the use of IP routing and
			forwarding capabilities.
	OAM functions SHOULD be independent of the underlying tunnelling or		o In some environments (e.g., MPLS-TP environments), IP routing and
	point-to-point technology or transmission media.		forwarding capabilities may not necessarily be present. In this
			case, the OAM functions and their operation MUST NOT require
			relying on IP routing and forwarding capabilities.
	OAM functions SHOULD be independent of the service a pseudowire may		In case OAM messages need to incorporate identification information
	emulate.		(e.g., of source and/or destination nodes), the protocol solution
			MUST at least support an IP addressing structure and MUST also be
			extensible to support additional addressing schemes.
	The set of OAM functions operated on each Maintenance Entity SHOULD		2.1.3. Interoperability and Interworking
	be independent one from another.
	Note that independence should not be understood here in terms of
	isolation but in terms of separate running processes. There should be
	one OAM process running per Maintenance Entity but different OAM
	running processes could interact (e.g. alarm summarization).
	OAM functionality MAY be deployed in a variety of environments. In		It is REQUIRED by this document that OAM interoperability is achieved
	some of these IP routing and forwarding capabilities are inherently		across the environments described in Section 2.1.2. It is also
	present (e.g. IP/MPLS) and the OAM functionality MUST also support		REQUIRED by this document that the two first requirements of Section
	their use. Other deployment scenarios exist where IP routing and		2.1.2 still hold and MUST thus still be met when interoperability is
	forwarding capabilities are not necessarily present (e.g. MPLS-TP).
	In these latter cases, the operation of OAM functions MUST NOT rely
	on IP routing and forwarding capabilities. Further, it is REQUIRED by
	this document that OAM interoperability is achieved across these
	environments. It is also REQUIRED by this document that the two above
	requirements are still met and still hold when interoperability is
	achieved.		achieved.
	Furthermore, in case OAM packets need to incorporate identification		When MPLS-TP is run with IP routing and forwarding capabilities, it
	information of source and/or destination nodes, an IP addressing		MUST be possible to operate any of the existing IP/MPLS and PW OAM
	structure MUST be supported.		functionalities (e.g., LSP-Ping [3], MPLS-BFD [9], VCCV [4] and VCCV-
			BFD [10]).
	When MPLS-TP is run with IP routing and forwarding capabilities, all
	existing IP/MPLS OAM functionality (e.g. LSP-Ping, BFD and VCCV) MUST
	be able to operate seamlessly.
	OAM functions MUST operate and be configurable even in the absence of		The protocol solution(s) developed to meet the requirements listed in
	a control plane. Conversely, OAM functions SHOULD be configurable as		this document MUST interwork with the existing IP/MPLS and PW OAM
	part of connectivity (LSP or PW) management. Note that means for		protocols.
	configuring OAM functions and for connectivity management are outside
	the scope of this document.
	The service emulated by a single segment or a multi-segment		2.1.4. Data Plane
	pseudowire may span multiple domains. A LSP may also span multiple
	domains. It MUST be possible to perform OAM functions on a per domain
	basis and across multiple domains. More generally it MUST be possible
	to perform OAM functions between any two switching elements of a PW
	or of a LSP. This is referred to as segment (or tandem connection)
	monitoring (see [7]). Furthermore, in case of a fault or defect on
	the service, means MUST be available for the service provider to be
	informed of the fault even if the fault is located outside of his
	domain.
	OAM functions operate in the data plane. OAM packets MUST run in-		OAM functions operate in the data plane. OAM packets MUST run in-
	band. That is, OAM packets for a specific Maintenance Entity MUST		band; that is, OAM packets for a specific PW, LSP or Section MUST
	follow the exact same data path as user traffic of that Maintenance		follow the exact same data path as user traffic of that PW, LSP or
	Entity. This is known as fate sharing.		Section.
	It MUST be possible to discriminate data traffic from OAM packets.		It MUST be possible to discriminate user traffic from OAM packets.
	This includes a means to differentiate OAM packets from user traffic		This includes a means to differentiate OAM packets from user traffic
	as well as the capability to apply specific treatment, to OAM		as well as the capability to apply specific treatment, to OAM
	packets, at the MIPs or MEPs targeted by these OAM packets.		packets, at the nodes targeted by these OAM packets.
	As part of the design of OAM mechanisms for MPLS-TP, a mechanism that		As part of the design of OAM protocol solutions for MPLS-TP, a
	enables the realization of a channel for general purpose signalling,		mechanism enabling to encapsulate and differentiate OAM messages, on
	e.g. for control, management and OAM information, associated with the		a PW, LSP or Section, MUST be provided. Such mechanism MUST also
	data plane paths, MUST be provided. Such mechanism SHOULD support the		support the encapsulation and differentiation of existing IP/MPLS and
	operation of existing IP/MPLS OAM.		PW OAM messages.
	OAM functions MUST be able to be used for PWs, LSPs and Sections.		2.1.5. Scope
	Furthermore, since LSPs MAY be stacked, OAM functions MUST be able to
	run on each LSP, regardless of the label stack depth.		The service emulated by a single segment or a multi-segment PW may
			span multiple domains. A LSP may also span multiple domains. It
			MUST be possible to perform OAM functions on a per domain basis and
			across multiple domains. More generally it MUST be possible to
			perform OAM functions between any two switching elements (e.g., LSR
			or S-PE) of a LSP or of PW. This is referred to as (concatenated)
			segment monitoring.
	2.2. Functional Requirements		2.2. Functional Requirements
	Hereafter are listed the required functions composing the MPLS-TP OAM		Hereafter are listed the required functions composing the MPLS-TP OAM
	tool-set. The list may not be exhaustive and as such the OAM		toolset. The list may not be exhaustive and as such the OAM
	mechanisms developed in support of the identified requirements SHALL		mechanisms developed in support of the identified requirements SHALL
	be extensible and thus SHALL NOT preclude the definition of		be extensible and thus SHALL NOT preclude the definition of
	additional OAM functions in the future. Furthermore, the design of		additional OAM functions, in the future.
	OAM mechanisms for MPLS-TP MUST allow the ability to support vendor
	specific and experimental OAM functions. Vendor specific and
	experimental OAM functions MUST be disabled by default and explicitly
	enabled by a service provider or network operator, between nodes that
	support them.
	Moreover, the use of OAM functions SHOULD be optional for the service		The design of OAM mechanisms, for MPLS-TP, MUST allow the ability to
	provider or network operator. A network operator or service provider		support vendor specific and experimental OAM functions. These
	SHOULD be able to choose which OAM functions to use and which		functions MUST be disabled by default.
	Maintenance Entities to apply them to.
	Note that the functions listed below can serve the purpose of fault		The use of any OAM function MUST be optional for the service provider
	and/or performance management. For example, connectivity verification		or network operator and a network operator or service provider MUST
	can be used for fault management application by detecting failure		be able to choose which OAM function(s) to use and on which PW, LSP
	conditions, but may also be used for performance management		or Section to apply it(them) to.
	application through its contribution to the evaluation of performance
	metrics (e.g. unavailability time). Nevertheless, it is outside the
	scope of this document to specify which function should be used for
	which application.
	2.2.1. General requirements		It is RECOMMENDED by this document that a protocol solution,
			realizing a given function, effectively provides a fully featured
			function, i.e., a function which is applicable to all the cases
			identified in the table in Section 2.3, for that function.
	If a defect or fault occurs, mechanisms MUST be provided to detect		The OAM functions MUST be able to be operated on PWs, LSPs and
	it, diagnose it, localize it, and notify the appropriate entities.		Sections.
	Corrective actions SHOULD be taken according to the type of defect or
	fault.
	In the case of the PW Maintenance Entity, OAM mechanisms SHOULD be		Note that the functions listed below can be used for fault
	provided to ensure that customers do not have to detect faults. The		management, performance monitoring and/or protection switching
	OAM functions SHOULD allow the service provider to automatically		applications. For example, connectivity verification can be used for
	detect and notify the faults associated with a PW Maintenance Entity.		fault management application by detecting failure conditions, but may
			also be used for performance monitoring application through its
			contribution to the evaluation of performance metrics (e.g.,
			unavailability time). Nevertheless, it is outside the scope of this
			document to specify which function should be used for which
			application.
	2.2.2. Connectivity and Continuity Verification		2.2.1. General Requirements
	The MPLS-TP OAM tool-set MUST provide a function to enable service		If a defect or fault occurs on a PW, LSP or Section, mechanisms MUST
	providers to detect loss of continuity but also mis-connectivity		be provided to detect it, diagnose it, localize it, and notify the
	between two points of a Maintenance Entity.		appropriate entities. Corrective actions SHOULD be taken according
			to the type of defect or fault.
	2.2.3. Client Failure Indication		Furthermore, in case of a fault or defect, affecting a service
			provided by a service provider, mechanisms MUST be available for the
			service provider to be informed of the fault or defect even if the
			fault or defect is located outside of his domain.
	The MPLS-TP OAM tool-set MUST provide a function to enable a MEP to		2.2.2. Continuity Checks
	propagate a client failure indication to its peer MEP when alarm
	suppression in the client layer is not supported.
	In cases where the OAM of the native service of an AC or a PW type		The MPLS-TP OAM toolset MUST provide a function to enable service
	does not provide mechanisms to propagate failure condition		providers and network operators to detect loss of continuity, but
	information, while a downstream indication of such state is needed,		also unintended connectivity, on a PW, LSP or Section.
	MPLS-TP OAM SHOULD provide mechanisms for propagating AC failures and
	their clearance across a MPLS-TP domain.
	2.2.4. Remote Defect Indication		This function SHOULD be performed pro-actively.
	The MPLS-TP OAM tool-set MUST provide a function to enable a MEP to		This function SHOULD be performed between End Points of PWs, LSPs and
	notify its peer MEP of the detection of a defect on a bi-directional		Sections.
	connection between them.
	2.2.5. Alarm Suppression		Means MUST be available to parameterize the frequency at which is
			performed this function as well as to parameterize the criteria, if
			any (e.g., number of consecutive OAM messages not received), based on
			which loss of continuity or unintended connectivity is detected. A
			default value MAY be defined.
	The MPLS-TP OAM tool-set MUST provide a function to enable a server		2.2.3. Connectivity Verifications
	layer MEP to notify a failure condition or an administrative locking
	to its client layer MEP(s) in order to suppress alarms that may be
	generated by maintenance domains of the client layer as a result of
	the failure condition or of the administrative locking in the server
	layer.
	The MPLS-TP OAM tool-set MUST allow the client layer to differentiate		The MPLS-TP OAM toolset MUST provide a function to enable service
	between a defect condition and an administrative locking action at		providers and network operators to verify the connectivity of a PW,
	the server layer ME.		LSP or Section.
	The server layer MEP and the client layer MEPs MAY reside on the same		This function SHOULD be performed on-demand.
	node or on different nodes. A mechanism MUST be provided for both
	cases.
	An alarm suppression and summarization mechanism MUST be provided.		This function SHOULD be performed between End Points and Intermediate
	For example, a fault detected at the LSP level MUST NOT trigger		Points of PWs and LSPs, and between End Points of PWs, LSPs and
	various alarms at the PW level.		Sections.
	2.2.6. Packet Loss		Note that, this function is sometime referred to as loopback as End
			Points expect to receive some level of information as a result of
			their action.
	The MPLS-TP OAM tool-set MUST provide a function to enable service		2.2.4. Diagnostic
	providers to measure packet loss ratio between a pair of MEPs. Packet
	loss ratio is the ratio of the user-plane packets not delivered to
	the total number of user-plane packets transmitted during a defined
	time interval. The number of user-plane packets not delivered is the
	difference between the number of user-plane packets transmitted by
	the source node and the number of user-plane packets received at the
	destination node.
	2.2.7. Delay Measurement		The MPLS-TP OAM toolset MAY provide a function to enable service
			providers and network operators to perform diagnostic tests (e.g.,
			verify bandwidth throughput) on a PW, LSP or Section.
	The MPLS-TP OAM tool-set MUST provide a function to enable service		This function SHOULD be performed on-demand.
	providers to measure the one-way or two-way delay of a packet
	transmission between a pair of MEPs. Where,
	o One-way packet delay is the time elapsed from the start of		This function SHOULD be performed between End Points and Intermediate
	transmission of the first bit of the packet by a source node until		Points of PWs and LSPs, and between End Points of PWs, LSPs and
	the reception of the last bit of that packet by the destination		Sections.
	node.
	o Two-way packet delay is the time elapsed from the start of		This function MAY be provided as part of the Connectivity
	transmission of the first bit of the packet by a source node until		Verifications function (see Section 2.2.3).
	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.
	2.2.8. Route Determination		2.2.5. Adjacency
	The MPLS-TP OAM tool-set MUST provide a function to enable service		The MPLS-TP OAM toolset MUST provide a function to enable an End
	providers to determine the route of a connection across the MPLS		Point to request, to, and receive from, any node along a PW, LSP or
	transport network.		Section, a certain level of information (e.g., identification,
			distance in hops).
	2.2.9. Diagnostic		This function SHOULD be performed on-demand.
	The MPLS-TP OAM tool-set MUST provide a function to enable service		This function SHOULD be performed between End Points and any node of
	providers to verify bandwidth throughput (and other diagnostic tests)		a PW, LSP and Section.
	between a pair of MEPs.
	2.3. Operational Requirements		This function MAY be provided jointly with the Route Tracing function
			(see Section 2.2.6).
	OAM functions such as connectivity and continuity verification MUST		2.2.6. Route Tracing
	NOT rely on user traffic. Dedicated OAM flows SHOULD be used to
	detect connectivity and continuity defects. See also ITU-T G.806 .
	[3].
	This document does not mandate the use of a particular OAM function,
	however, it is RECOMMENDED that connectivity and continuity
	verification is performed on every Maintenance Entity in order to
	reliably detect connectivity defects.
	OAM functions MUST be applicable to bidirectional point-to-point		The MPLS-TP OAM toolset MUST provide a function to enable service
	connections, and a subset of these OAM functions MUST be applicable		providers and network operators to trace the route a PW, LSP or
	to unidirectional point-to-point and point-to-multipoint connections.		Section. The information collected SHOULD include identifiers
	This subset is based on the nature of both the OAM functions and the		related to the nodes composing that route and MAY include interface
	connections to which they can apply.		identifiers.
	The following table describes how, on which Maintenance Entity and		This function SHOULD be performed on-demand.
	between which points of the Maintenance Entity SHOULD the required
	OAM functions be applied. In these tables, MEP stands for monitoring
	from MEP to MEP, MIP stands for monitoring from MEP to MIP, U stands
	for unidirectional, B stands for bidirectional. Crosses (x) indicate
	the way the considered function should be applied, numbers indicate
	the way the considered function should be applied while pointing to a
	footnote providing additional details.
	+-------------------------------------------+		This function SHOULD be performed between End Points and Intermediate
	| on-demand | proactive |		Points of PWs and LSPs, and between End Points of PWs, LSPs and
	|---------------------+----------+----------|		Sections.
	| MEP | MIP | MEP | MIP |
	|----------+----------+----------+----------|
	| P2P |P2MP| P2P |P2MP| P2P |P2MP| P2P |P2MP|
	|-----+----+----------+----------+-----+----|
	|U |B | U |U |B | U |U |B | U |U |B | U |
	+----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
	| cc verification | |x | | |x | |x |x | x | | | |
	|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
	| client fail. indic. | | | | | | | |x | | | | |
	|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
	| remote defect indic. | | | | | | | |x | | | | |
	|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
	| alarm suppression | | | | | | |x |x | x | | | |
	|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
	| packet loss measure | |1 | | | | |x |2 | x | | | |
	|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
	| delay measurement |x |3 | x | | | | | | | | | |
	|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
	| route determination | |x | | |x | | | | | | | |
	|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
	| diagnostic |x |x | x | | | | | | | | | |
	+----------------------+-------------------------------------------+
	1: single-ended packet loss measurements
	2: in both directions of the bi-directional connection		This function MAY be provided jointly with the Adjacency function
			(see Section 2.2.5).
	3: one-way and two-way packet delay measurements		2.2.7. Lock
	Table 1 : OAM functions and their applicability scope		The MPLS-TP OAM toolset MAY provide a function enabling to
			administratively shut down a PW, LSP or Section; that is, to stop
			user traffic being sent over that PW, LSP or Section.
	2.4. Performance Requirements		This function SHOULD be performed on-demand.
	OAM functions SHOULD continue to meet their objectives regardless of		This function SHOULD be performed between End Points of PWs, LSPs and
	congestion conditions. See also ITU-T Y.1541 [4].		Sections.
	Additional requirements will be incorporated in a future revision of		2.2.8. Alarm Notification
	this document.
	3. Security Considerations		The MPLS-TP OAM toolset MUST provide a function to enable server
			layer End Points to notify a fault condition or an administrative
			locking to the client layer End Points affected by this status. This
			would enable to suppress alarms that may be generated in the client
			layer as a result of the fault condition or of the administrative
			locking in the server layer.
	Mechanisms SHOULD be provided to ensure that unauthorized access is		The MPLS-TP OAM toolset MUST allow for the distinction between a
	prevented from triggering any OAM function.		fault condition and an administrative locking action.
	OAM messages MAY be authenticated.		The server layer End Points generating the notification and the
			client layer End Points receiving the notification may or may not be
			the same nodes. A mechanism MUST be provided to support both cases.
	An OAM packet for a Maintenance Entity MUST NOT leak out of the ME,		This function SHOULD be performed pro-actively.
	i.e. go beyond the terminating MEP.
	4. Congestion Considerations		This function SHOULD be performed between the End Points of PWs, LSPs
			and Sections and the End Points of the PWs and/or LSPs affected by
			the fault condition or administrative locking.
	A mechanism (e.g. rate limiting) MUST be provided to prevent OAM		2.2.9. Client Failure Indication
	messages from causing congestion in the PSN.
	5. IANA Considerations		The MPLS-TP OAM toolset MUST provide a function to enable the
			propagation of client fault condition information, across the MPLS-TP
			network, if the client layer OAM mechanisms do not provide an alarm
			notification/propagation mechanism.
	There are no IANA actions required by this draft.		This function SHOULD be performed pro-actively.
	6. Acknowledgments		This function SHOULD be performed between End Points of PWs, LSPs and
			Sections.
	The authors would like to thank all members of the teams (the Joint		2.2.10. Remote Defect Indication
	Working Team, the MPLS Interoperability Design Team in IETF and the
	T-MPLS Ad Hoc Group in ITU-T) involved in the definition and
	specification of MPLS Transport Profile.
	7. References		The MPLS-TP OAM toolset MUST provide a function to enable an End
			Point to notify its associated End Point of the detection of a fault
			or defect that it detects on a PW, LSP or Section between them.
	7.1. Normative References		This function SHOULD be performed pro-actively.
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		This function SHOULD be performed between End Points of PWs, LSPs and
	[2] ITU-T Recommendation M.3400 (2000), TMN management functions		Sections.
	[3] ITU-T Recommendation G.806 (2006), Characteristics of transport		2.2.11. Packet Loss
	equipment - Description methodology and generic functionality
	[4] ITU-T Recommendation Y.1541 (2006), Network performance		Packet loss ratio is the ratio of the user packets not delivered to
	objectives for IP-based services		the total number of user packets transmitted during a defined time
			interval. The number of user packets not delivered is the difference
			between the number of user packets transmitted by an End Point and
			the number of user packets received at an End Point.
	[5] ITU-T Supplement Y.Sup4 (2008), Transport Requirements for T-		The MPLS-TP OAM toolset MUST provide a function to enable service
	MPLS OAM and considerations for the application of IETF MPLS		providers and network operators to derive packet loss ratio over a
	Technology		PW, LSP or Section.
	7.2. Informative References		This OAM function MUST support the configurability of the interval of
			time during which the measure is performed.
	[6] Nadeau, T., et al., "Operations and Management (OAM)		This function SHOULD be performed pro-actively.
	Requirements for Multi-Protocol Label Switched (MPLS)
	Networks", RFC 4377, February 2006
	[7] Busi, I., Niven-Jenkins, B., "MPLS-TP OAM Framework and		This function SHOULD be performed between End Points of PWs, LSPs and
	Overview", draft-busi-mpls-tp-oam-framework, October 2008		Sections.
	[8] Niven-Jenkins, B., Brungard, D., Betts, M., "MPLS-TP		2.2.12. Delay Measurement
	Requirements", draft-ietf-mpls-tp-requirements, November 2008
	Authors' Addresses		The MPLS-TP OAM toolset MUST provide a function to enable service
			providers and network operators to measure the one-way, and if
			appropriate, the two-way, delay of a PW, LSP or Section.
	Martin Vigoureux		o One-way delay is the time elapsed from the start of transmission
	Alcatel-Lucent		of the first bit of an OAM packet by an End Point until the
			reception of the last bit of that OAM packet by the other End
			Point.
	Email: martin.vigoureux@alcatel-lucent.com		o Two-way delay is the time elapsed from the start of transmission
			of the first bit of an OAM packet by a End Point until the
			reception of the last bit of that OAM packet by the same End
			Point, when the loopback is performed at the other End Point.
	David Ward		This function SHOULD be performed on-demand.
	Cisco Systems, Inc.
	Email: dward@cisco.com		This function SHOULD be performed between End Points of PWs, LSPs and
	Malcolm Betts		Sections.
	Nortel Networks
	Email: betts01@nortel.com		2.3. Operational Requirements
	Contributing Authors' Addresses		The OAM functions MUST NOT rely on user traffic to achieve their
			objectives; that is, dedicated OAM messages MUST be used.
	Matthew Bocci		Some OAM functions require certain parameters for their operation.
	Alcatel-Lucent		These parameters MUST be configurable. A default value MAY be
			defined.
	Email: matthew.bocci@alcatel-lucent.com		The specification of certain parameters' values SHOULD be such that
			it accounts, at the design phase, for various possible network
			conditions (e.g., the continuity check function should continue to
			meet its objective (i.e. detect failures) even in the context of high
			traffic load (e.g., congestion)).
	Italo Busi		This document does not mandate the use of a particular OAM function.
	Alcatel-Lucent		However, it is RECOMMENDED that MPLS-TP enables continuity checks to
			be performed on every PW, LSP and Section in order to reliably detect
			connectivity defects and faults.
	Email: italo.busi@alcatel-lucent.it		OAM functions MUST be applicable to bidirectional point-to-point PWs,
			LSPs and Sections, and a subset of these OAM functions MUST be
			applicable to unidirectional point-to-point and point-to-multipoint
			PWs, LSPs and Sections. This subset is based on the nature of both
			the OAM functions and the connections to which they can apply.
	Huub van Helvoort		The following table describes how, between which points of PWs, LSPs
	Huawei Technologies Co.Ltd.		and Sections SHOULD the required OAM functions be applied. In these
			tables U stands for unidirectional; B stands for bidirectional; EP
			stands for an OAM function being performed between End Points; IP
			stands for an OAM function being performed between End Points and
			Intermediate Points. Crosses (x) indicate the way the considered
			function should be applied; numbers indicate the way the considered
			function should be applied while pointing to a footnote providing
			additional details.
			+-------------------------------------------+
			| on-demand | pro-active |
			|---------------------+----------+----------|
			| MEP | MIP | MEP | MIP |
			|----------+----------+----------+----------|
			| P2P |P2MP| P2P |P2MP| P2P |P2MP| P2P |P2MP|
			|-----+----+----------+----------+-----+----|
			|U |B | U |U |B | U |U |B | U |U |B | U |
			+----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
			| c. checks | | | | | | |x |x | x | | | |
			|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
			| c. verifications |1 |x | 1 |1 |x | 1 | | | | | | |
			|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
			| diagnostic |x |x | x |2 |2 | 2 | | | | | | |
			|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
			| adjacency |1 |x | 1 |1 |x | 1 | | | | | | |
			|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
			| route tracing |1 |x | 1 |1 |x | 1 | | | | | | |
			|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
			| lock |x |x | x | | | | | | | | | |
			|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
			| alarm notification | | | | | | |x |x | x | | | |
			|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
			| client fail. indic. | | | | | | |2 |x | 2 | | | |
			|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
			| remote defect indic. | | | | | | |1 |x | 1 | | | |
			|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
			| packet loss |2 |3 | 2 | | | |x |4 | x | | | |
			|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
			| delay measurement |x |x | x | | | |2 |2 | 2 | | | |
			+----------------------+--+--+----+--+--+----+--+--+----+--+--+----+
			1: the function MAY be provided if a return path exists
			2: the function MAY be performed
			3: the function SHOULD be performed in one direction
			4: the function SHOULD be performed in both directions
	Email: hhelvoort@huawei.com		OAM functions and their applicability scope
	Marc Lasserre		3. Congestion Considerations
	Alcatel-Lucent
	Email: mlasserre@alcatel-lucent.com		A mechanism (e.g., rate limiting) MUST be provided to prevent OAM
			packets from causing congestion in the PSN.
	Lieven Levrau		4. Security Considerations
	Alcatel-Lucent
	Email: llevrau@alcatel-lucent.com		This document, as itself, does not imply any security consideration
			but OAM, as such, is subject to several security considerations. OAM
			messages can reveal sensitive information such as passwords,
			performance data and details about e.g., the network topology.
	Han Li		The nature of OAM therefore suggests having some form of
	China Mobile Communications Corporation (CMCC)		authentication, authorization and encryption in place. This will
	Email: lihan@chinamobile.com		prevent unauthorized access to MPLS-TP equipment and it will prevent
	Julien Meuric		third parties from learning about sensitive information about the
	Orange		transport network.
	Email: julien.meuric@orange-ftgroup.com		In general, mechanisms SHOULD be provided to ensure that OAM
			functions cannot be accessed unauthorized.
	Philippe Niger		Further, OAM messages MAY be authenticated to prove their origin and
	Orange		to make sure that they are destined for the receiving node.
	Email: philippe.niger@orange-ftgroup.com		An OAM packet received over a PW, LSP or Section MUST NOT be
			forwarded beyond the End Point of that PW, LSP or Section, so as to
			avoid that the OAM packet leaves the current administrative domain.
	Benjamin Niven-Jenkins		5. IANA Considerations
	BT
	Email: benjamin.niven-jenkins@bt.com		There are no IANA actions required by this draft.
	Jing Ruiquan		6. Acknowledgements
	China Telecom
	Email: jingrq@ctbri.com.cn
	Nurit Sprecher		The authors would like to thank all members of the teams (the Joint
	Nokia-Siemens Networks		Working Team, the MPLS Interoperability Design Team in IETF and the
			MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and
			specification of MPLS-TP.
	Email: nurit.sprecher@nsn.com		7. References
	Yuji Tochio		7.1. Normative References
	Fujitsu
	Email: tochio@jp.fujitsu.com		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
			Levels", BCP 14, RFC 2119, March 1997.
	Yaacov Weingarten		[2] ITU-T Recommendation G.806, "Characteristics of transport
	Nokia-Siemens Networks		equipment - Description methodology and generic functionality",
			2009.
	Email: yaacov.weingarten@nsn.com		[3] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label
			Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
	Intellectual Property Statement		[4] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
			Connectivity Verification (VCCV): A Control Channel for
			Pseudowires", RFC 5085, December 2007.
	The IETF Trust takes no position regarding the validity or scope of		7.2. Informative References
	any Intellectual Property Rights or other rights that might be
	claimed to pertain to the implementation or use of the technology
	described in any IETF Document or the extent to which any license
	under such rights might or might not be available; nor does it
	represent that it has made any independent effort to identify any
	such rights.
	Copies of Intellectual Property disclosures made to the IETF		[5] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in
	Secretariat and any assurances of licenses to be made available, or		Transport Networks", draft-ietf-mpls-tp-framework-00 (work in
	the result of an attempt made to obtain a general license or		progress), November 2008.
	permission for the use of such proprietary rights by implementers or
	users of this specification can be obtained from the IETF on-line IPR
	repository at http://www.ietf.org/ipr
	The IETF invites any interested party to bring to its attention any		[6] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and
	copyrights, patents or patent applications, or other proprietary		S. Ueno, "MPLS-TP Requirements",
	rights that may cover technology that may be required to implement		draft-ietf-mpls-tp-requirements-04 (work in progress),
	any standard or specification contained in an IETF Document. Please		February 2009.
	address the information to the IETF at ietf-ipr@ietf.org
	The definitive version of an IETF Document is that published by, or		[7] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on
	under the auspices of, the IETF. Versions of IETF Documents that are		transport requirements for T-MPLS OAM and considerations for
	published by third parties, including those that are translated into		the application of IETF MPLS technology", 2008.
	other languages, should not be considered to be definitive versions
	of IETF Documents. The definitive version of these Legal Provisions
	is that published by, or under the auspices of, the IETF. Versions of
	these Legal Provisions that are published by third parties, including
	those that are translated into other languages, should not be
	considered to be definitive versions of these Legal Provisions.
	For the avoidance of doubt, each Contributor to the IETF Standards		[8] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
	Process licenses each Contribution that he or she makes as part of		Matsushima, "Operations and Management (OAM) Requirements for
	the IETF Standards Process to the IETF Trust pursuant to the		Multi-Protocol Label Switched (MPLS) Networks", RFC 4377,
	provisions of RFC 5378. No language to the contrary, or terms,		February 2006.
	conditions or rights that differ from or are inconsistent with the
	rights and licenses granted under RFC 5378, shall have any effect and
	shall be null and void, whether published or posted by such
	Contributor, or included with or in such Contribution.
	Disclaimer of Validity		[9] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD
			For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress),
			June 2008.
	All IETF Documents and the information contained therein are provided		[10] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
	on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		Detection (BFD) for the Pseudowire Virtual Circuit
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE		Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-03
	IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL		(work in progress), February 2009.
	WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
	WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
	ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
	FOR A PARTICULAR PURPOSE.
	Copyright Statement		Authors' Addresses
	Copyright (c) 2008 IETF Trust and the persons identified as the		Martin Vigoureux (editor)
	document authors. All rights reserved.		Alcatel-Lucent
	This document is subject to BCP 78 and the IETF Trust's Legal		Email: martin.vigoureux@alcatel-lucent.com
	Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		David Ward (editor)
	publication of this document. Please review these documents		Cisco Systems, Inc.
	carefully, as they describe your rights and restrictions with respect
	to this document.		Email: dward@cisco.com
			Malcolm Betts (editor)
			Nortel Networks
			Email: betts01@nortel.com
End of changes. 155 change blocks.
	490 lines changed or deleted		473 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/