draft-ietf-mpls-tp-cc-cv-rdi-06.txt		rfc6428.txt
	MPLS Working Group Dave Allan, Ed.
	Internet Draft Ericsson
	Intended status: Standards Track
	Expires: February 2012 George Swallow Ed.
	Cisco Systems, Inc
	John Drake Ed.		Internet Engineering Task Force (IETF) D. Allan, Ed.
			Request for Comments: 6428 Ericsson
			Category: Standards Track G. Swallow, Ed.
			ISSN: 2070-1721 Cisco Systems, Inc.
			J. Drake, Ed.
	Juniper		Juniper
			November 2011
	August 2011		Proactive Connectivity Verification, Continuity Check, and
			Remote Defect Indication for the MPLS Transport Profile
	Proactive Connectivity Verification, Continuity Check and Remote
	Defect indication for MPLS Transport Profile
	draft-ietf-mpls-tp-cc-cv-rdi-06
	Abstract		Abstract
	Continuity Check, Proactive Connectivity Verification and Remote		Continuity Check, Proactive Connectivity Verification, and Remote
	Defect Indication functionalities are required for MPLS-TP OAM.		Defect Indication functionalities are required for MPLS Transport
			Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM).
	Continuity Check monitors a label switched path for any loss-of-		Continuity Check monitors a Label Switched Path for any loss of
	continuity defect. Connectivity Verification augments Continuity		continuity defect. Connectivity Verification augments Continuity
	Check in order to provide confirmation that the desired source is		Check in order to provide confirmation that the desired source is
	connected to the desired sink. Remote defect indication enables an		connected to the desired sink. Remote Defect Indication enables an
	End Point to report, to its associated End Point, a fault or defect		end point to report, to its associated end point, a fault or defect
	condition that it detects on a pseudo wire, label switched path or		condition that it detects on a pseudowire, Label Switched Path, or
	Section.		Section.
	This document specifies specific extensions to BFD and methods for		This document specifies specific extensions to Bidirectional
	proactive Continuity Check, Continuity Verification, and Remote		Forwarding Detection (BFD) and methods for proactive Continuity
	Defect Indication for MPLS-TP label switched paths, pseudo wires and		Check, Continuity Verification, and Remote Defect Indication for
	Sections using Bidirectional Forwarding Detection as extended by		MPLS-TP pseudowires, Label Switched Paths, and Sections using BFD as
	this memo.		extended by this memo.
	Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC2119 [1].
	Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance
	with the provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet
	Engineering Task Force (IETF), its areas, and its working
	groups. Note that other groups may also distribute working
	documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Status of This Memo
	months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-
	Drafts as reference material or to cite them other than as "work
	in progress".
	The list of current Internet-Drafts can be accessed at		This is an Internet Standards Track document.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		This document is a product of the Internet Engineering Task Force
	http://www.ietf.org/shadow.html.		(IETF). It represents the consensus of the IETF community. It has
			received public review and has been approved for publication by the
			Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 5741.
	This Internet-Draft will expire on February 9th, 2012.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc6428.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with		carefully, as they describe your rights and restrictions with respect
	respect to this document. Code Components extracted from this		to this document. Code Components extracted from this document must
	document must include Simplified BSD License text as described		include Simplified BSD License text as described in Section 4.e of
	in Section 4.e of the Trust Legal Provisions and are provided		the Trust Legal Provisions and are provided without warranty as
	without warranty as described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction...................................................3		1. Introduction ....................................................3
	2. Conventions used in this document..............................4		2. Conventions Used in This Document ...............................3
	2.1. Terminology..................................................4		2.1. Terminology ................................................3
	3. MPLS-TP CC, proactive CV and RDI Mechanism using BFD...........5		2.2. Requirements Language ......................................5
	3.1. Existing Capabilities........................................5		3. MPLS-TP CC, Proactive CV, and RDI Mechanism Using BFD ...........5
	3.2. CC, CV, and RDI Overview.....................................6		3.1. Existing Capabilities ......................................5
	3.3. ACH code points for CC and proactive CV......................7		3.2. CC, CV, and RDI Overview ...................................5
	3.4. MPLS-TP BFD CC Message format................................7		3.3. ACH Code Points for CC and Proactive CV ....................6
	3.5. MPLS-TP BFD proactive CV Message format......................8		3.4. MPLS-TP BFD CC Message Format ..............................7
	3.5.1. Section MEP-ID.............................................9		3.5. MPLS-TP BFD Proactive CV Message Format ....................8
	3.5.2. LSP MEP-ID................................................10		3.5.1. Section MEP-ID ......................................9
	3.5.3. PW Endpoint MEP-ID........................................10		3.5.2. LSP MEP-ID ..........................................9
	3.6. BFD Session in MPLS-TP terminology..........................11		3.5.3. PW End Point MEP-ID ................................10
	3.7. BFD Profile for MPLS-TP.....................................12		3.6. BFD Session in MPLS-TP Terminology ........................10
	3.7.1. Session initiation and Modification.......................13		3.7. BFD Profile for MPLS-TP ...................................11
	3.7.2. Defect entry criteria.....................................13		3.7.1. Session Initiation and Modification ................12
	3.7.3. Defect entry consequent action............................15		3.7.2. Defect Entry Criteria ..............................13
	3.7.4. Defect exit criteria......................................15		3.7.3. Defect Entry Consequent Action .....................14
	3.7.5. State machines............................................15		3.7.4. Defect Exit Criteria ...............................14
	3.7.6. Configuration of MPLS-TP BFD sessions.....................18		3.7.5. State Machines .....................................15
	3.7.7. Discriminator values......................................18		3.7.6. Configuration of MPLS-TP BFD Sessions ..............17
	4. Configuration Considerations..................................18		3.7.7. Discriminator Values ...............................17
	5. Acknowledgments...............................................19		4. Configuration Considerations ...................................18
	6. IANA Considerations...........................................19		5. IANA Considerations ............................................18
	7. Security Considerations.......................................20		6. Security Considerations ........................................19
	8. References....................................................20		7. References .....................................................19
	8.1. Normative References........................................20		7.1. Normative References ......................................19
	8.2. Informative References......................................21		7.2. Informative References ....................................20
			8. Acknowledgments ................................................20
			9. Contributing Authors ...........................................21
	1. Introduction		1. Introduction
	In traditional transport networks, circuits are provisioned on two or		In traditional transport networks, circuits are provisioned on two or
	more switches. Service Providers (SP) need Operations, Administration		more switches. Service providers need Operations, Administration,
	and Maintenance (OAM) tools to detect mis-connectivity and loss-of-		and Maintenance (OAM) tools to detect mis-connectivity and loss of
	continuity of transport circuits. Both pseudo wires (PWs) and MPLS-TP		continuity of transport circuits. Both pseudowires (PWs) and MPLS-TP
	label switched paths (LSPs) [12] emulating traditional transport		Label Switched Paths (LSPs) [12] emulating traditional transport
	circuits need to provide the same Continuity Check (CC), proactive		circuits need to provide the same Continuity Check (CC), proactive
	Continuity Verification (CV), and Remote Defect Indication (RDI)		Continuity Verification (CV), and Remote Defect Indication (RDI)
	capabilities as required in RFC 5860[3]. This document describes the		capabilities as required in RFC 5860 [3]. This document describes
	use of Bidirectional Forwarding Detection (BFD)[4] for CC, proactive		the use of Bidirectional Forwarding Detection (BFD) [4] for CC,
	CV, and RDI of a PW, LSP or sub-path maintenance entity (SPME)		proactive CV, and RDI of a PW, LSP, or Sub-Path Maintenance Entity
	between two Maintenance Entity Group End Points (MEPs).		(SPME) between two Maintenance Entity Group End Points (MEPs).
	As described in [13], CC and CV functions are used to detect loss-of-		As described in RFC 6371 [13], CC and CV functions are used to detect
	continuity (LOC), and unintended connectivity between two MEPs (e.g.		loss of continuity (LOC) and unintended connectivity between two MEPs
	mis-merging or mis-connectivity or unexpected MEP).		(e.g., mis-merging or mis-connectivity or unexpected MEP).
	RDI is an indicator that is transmitted by a MEP to communicate to		RDI is an indicator that is transmitted by a MEP to communicate to
	its peer MEP that a signal fail condition exists. RDI is only used		its peer MEP that a signal fail condition exists. RDI is only used
	for bidirectional LSPs and is associated with proactive CC & CV BFD		for bidirectional LSPs and is associated with proactive CC and CV BFD
	control packet generation.		control packet generation.
	This document specifies the BFD extension and behavior to satisfy the		This document specifies the BFD extension and behavior to satisfy the
	CC, proactive CV monitoring and the RDI functional requirements for		CC, proactive CV monitoring, and the RDI functional requirements for
	both co-routed and associated bi-directional LSPs. Supported		both co-routed and associated bidirectional LSPs. Supported
	encapsulations include generic alert label (GAL)/generic associated		encapsulations include Generic Associated Channel Label (GAL) /
	channel (G-ACh), virtual circuit connectivity verification (VCCV) and		Generic Associated Channel (G-ACh), Virtual Circuit Connectivity
	UDP/IP. Procedures for uni-directional point-to-point (p2p) and		Verification (VCCV), and UDP/IP. Procedures for unidirectional
	point-to-multipoint (p2mp) LSPs are for further study.		point-to-point (P2P) and point-to-multipoint (P2MP) LSPs are for
			further study.
	This document utilizes identifiers for MPLS-TP systems as defined in		This document utilizes identifiers for MPLS-TP systems as defined in
	[9]. Work is on-going in the ITU-T to define a globally-unique		RFC 6370 [9]. Work is ongoing in the ITU-T to define a globally-
	semantic for ITU Carrier Codes (ICCs), and future work may extend		unique semantic for ITU Carrier Codes (ICCs), and future work may
	this document to utilize ICCs as identifiers for MPLS-TP systems.		extend this document to utilize ICCs as identifiers for MPLS-TP
			systems.
	The mechanisms specified in this document are restricted to BFD		The mechanisms specified in this document are restricted to BFD
	asynchronous mode.		asynchronous mode.
	2. Conventions used in this document		2. Conventions Used in This Document
	2.1. Terminology		2.1. Terminology
	ACH: Associated Channel Header		ACH: Associated Channel Header
	BFD: Bidirectional Forwarding Detection		BFD: Bidirectional Forwarding Detection
			CC: Continuity Check
	CC: Continuity Check		CV: Connectivity Verification
	CV: Connectivity Verification		GAL: Generic Associated Channel Label
	GAL: G-ACh Label		G-ACh: Generic Associated Channel
	G-ACh: Generic Associated Channel		LDI: Link Down Indication
	LDI: Link Down Indication		LKI: Lock Instruct
	LKI: Lock Instruct		LKR: Lock Report
	LKR: Lock Report		LSP: Label Switched Path
	LSP: Label Switched Path		LSR: Label Switching Router
	LSR: Label Switching Router		ME: Maintenance Entity
	ME: Maintenance Entity		MEG: Maintenance Entity Group
	MEG: Maintenance Entity Group		MEP: Maintenance Entity Group End Point
	MEP: Maintenance Entity Group End Point		MIP: Maintenance Entity Group Intermediate Point
	MIP: Maintenance Entity Group Intermediate Point		MPLS: Multiprotocol Label Switching
	MPLS: Multi-Protocol Label Switching
	MPLS-OAM: MPLS Operations, Administration and Maintenance		MPLS-OAM: MPLS Operations, Administration and Maintenance
	MPLS-TP: MPLS Transport Profile		MPLS-TP: MPLS Transport Profile
	MPLS-TP LSP: Uni-directional or Bidirectional Label Switched Path		MPLS-TP LSP: Unidirectional or bidirectional Label Switched Path
	representing a circuit		representing a circuit
	MS-PW: Multi-Segment PseudoWire		MS-PW: Multi-Segment Pseudowire
	NMS: Network Management System		NMS: Network Management System
	OAM: Operations, Administration, and Maintenance [14]		OAM: Operations, Administration, and Maintenance [14]
	PW: Pseudo Wire		PW: Pseudowire
	PDU: Protocol Data Unit		PDU: Protocol Data Unit
	P/F: Poll-Final		P/F: Poll/Final
	RDI: Remote Defect Indication		RDI: Remote Defect Indication
			SPME: Sub-Path Maintenance Entity
	SPME: Sub-Path Maintenance Entity		TTL: Time To Live
	TTL: Time To Live		TLV: Type Length Value
	TLV: Type Length Value		VCCV: Virtual Circuit Connectivity Verification
	VCCV: Virtual Circuit Connectivity Verification		2.2. Requirements Language
	3. MPLS-TP CC, proactive CV and RDI Mechanism using BFD		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC 2119 [1].
	This document describes procedures for achieve combined CC, CV and		3. MPLS-TP CC, Proactive CV, and RDI Mechanism Using BFD
	RDI functionality within a single MPLS-TP MEG using BFD. This
			This document describes procedures for achieve combined CC, CV, and
			RDI functionality within a single MPLS-TP MEG using BFD. This
	augments the capabilities that can be provided for MPLS-TP LSPs using		augments the capabilities that can be provided for MPLS-TP LSPs using
	existing specified tools and procedures.		existing specified tools and procedures.
	3.1. Existing Capabilities		3.1. Existing Capabilities
	A CC-only mode may be provided via protocols and procedures described		A CC-only mode may be provided via protocols and procedures described
	in RFC 5885[7] with ACH channel 7. These procedures may be applied to		in RFC 5885 [7] with ACH channel 7. These procedures may be applied
	bi-directional LSPs (via the use of the GAL), as well as PWs.		to bidirectional LSPs (via the use of the GAL) as well as PWs.
	Implementations may also interoperate with legacy equipment by		Implementations may also interoperate with legacy equipment by
	implementing RFC 5884[8] for LSPs and RFC 5085[10] for PWs, in		implementing RFC 5884 [8] for LSPs and RFC 5085 [10] for PWs, in
	addition to the procedures documented in this memo. In accordance		addition to the procedures documented in this memo. In accordance
	with RFC 5586[2], when BFD control packets are encapsulated in an IP		with RFC 5586 [2], when BFD control packets are encapsulated in an IP
	header, the fields in the IP header are set as defined in RFC		header, the fields in the IP header are set as defined in RFC 5884
	5884[8]. When IP encapsulation is used CV mis-connectivity defect		[8]. When IP encapsulation is used, CV mis-connectivity defect
	detection can be performed by inferring a globally unique source on		detection can be performed by inferring a globally unique source on
	the basis of the combination of the source IP address and My		the basis of the combination of the source IP address and My
	Discriminator" fields.		Discriminator fields.
	3.2. CC, CV, and RDI Overview		3.2. CC, CV, and RDI Overview
	The combined CC, CV, and RDI functionality for MPLS-TP is achieved by		The combined CC, CV, and RDI functionality for MPLS-TP is achieved by
	multiplexing CC and CV PDUs within a single BFD session. The CV PDUs		multiplexing CC and CV PDUs within a single BFD session. The CV PDUs
	are augmented with a source MEP ID TLV to permit mis-connectivity		are augmented with a Source MEP-ID TLV to permit mis-connectivity
	detection to be performed by sink MEPs.		detection to be performed by sink MEPs.
	The interleaving of PDUs is achieved via the use of distinct		The interleaving of PDUs is achieved via the use of distinct
	encapsulations and code points for generic associated channel (G-ACh)		encapsulations and code points for generic associated channel (G-ACh)
	encapsulated BFD depending on whether the PDU format is CC or CV:		encapsulated BFD depending on whether the PDU format is CC or CV:
	o CC format: defines a new code point in the Associated Channel		o CC format: defines a new code point in the Associated Channel
	Header (ACH) described in RFC 5586[2].This format supports		Header (ACH) described in RFC 5586 [2]. This format supports
	Continuity Check and RDI functionalities.		Continuity Check and RDI functionalities.
	o CV format: defines a new code point in the Associated Channel		o CV format: defines a new code point in the Associated Channel
	Header (ACH) described in RFC 5586[2]. The ACH with "MPLS-TP		Header (ACH) described in RFC 5586 [2]. The ACH with "MPLS-TP
	Proactive CV" code point indicates that the message is an MPLS-TP		Proactive CV" code point indicates that the message is an MPLS-TP
	BFD proactive CV message, and information for CV processing is		BFD proactive CV message, and information for CV processing is
	appended in the form of the source MEP ID TLV.		appended in the form of the Source MEP-ID TLV.
	RDI is communicated via the BFD diagnostic field in BFD CC messages,		RDI is communicated via the BFD diagnostic field in BFD CC messages,
	and the diagnostic code field in CV messages MUST be ignored. It is		and the diagnostic code field in CV messages MUST be ignored. It is
	not a distinct PDU. As per [4], a sink MEP SHOULD encode a diagnostic		not a distinct PDU. As per [4], a sink MEP SHOULD encode a
	code of "1 - Control detection time expired" when the interval times		diagnostic code of "1 - Control Detection Time Expired" when the time
	detect multiplier have been exceeded. A sink MEP SHOULD encode a		since the last received BFD control packet exceeds the detection
	diagnostic code of "5 - Path Down" as a consequence of the sink MEP		time, which is equal to the remote system's Transmit Interval
	receiving LDI. A sink MEP MUST encode a diagnostic code of "XX - -		multiplied by the remote system's Detect Multiplier (which is set to
	Misconnectivity defect" (to be assigned by IANA) when CV PDU		3 in this document). A sink MEP SHOULD encode a diagnostic code of
	processing indicates a misconnectivity defect. A sink MEP that has		"5 - Path Down" as a consequence of the sink MEP receiving LDI. A
	started sending diagnostic code 5 SHOULD NOT change it to 1 when the		sink MEP MUST encode a diagnostic code of "9 - mis-connectivity
	detection timer expires.		defect" when CV PDU processing indicates a mis-connectivity defect.
			A sink MEP that has started sending diagnostic code 5 SHOULD NOT
			change it to 1 when the detection timer expires.
	3.3. ACH code points for CC and proactive CV		3.3. ACH Code Points for CC and Proactive CV
	Figure 1 illustrates the G-ACh encoding for BFD CC-CV-RDI		Figure 1 illustrates the G-ACh encoding for BFD CC-CV-RDI
	functionality.		functionality.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 1|Version| Flags | BFD CC/CV Code Point |		|0 0 0 1|Version| Flags | BFD CC/CV Code Point |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: ACH Indication of MPLS-TP CC/CV/RDI		Figure 1: ACH Indication of MPLS-TP CC/CV/RDI
	The first nibble (0001b) indicates the G-ACh as per RFC 5586[2].		The first nibble (0001b) indicates the G-ACh as per RFC 5586 [2].
	The version and the flags are set to 0 as specified in [2].		The version and the flags are set to 0 as specified in [2].
	The code point is either		The code point is either
	- BFD CC code point = XX1. [XX1 to be assigned by IANA from the PW		- BFD CC code point = 0x0022, or
	Associated Channel Type registry.] or,
	- BFD proactive CV code point = XX2. [XX2 to be assigned by IANA from		- BFD proactive CV code point = 0x0023.
	the PW Associated Channel Type registry.]
	CC and CV PDUs apply to all pertinent MPLS-TP structures, including		CC and CV PDUs apply to all pertinent MPLS-TP structures, including
	PWs, MPLS LSPs (including SPMEs), and Sections.		PWs, MPLS LSPs (including SPMEs), and Sections.
	CC and CV operation is simultaneously employed on a maintenance		CC and CV operations are simultaneously employed on a maintenance
	entity (ME) within a single BFD session. The expected usage is that		entity (ME) within a single BFD session. The expected usage is that
	normal operation is to send CC BFD protocol data units (PDUs)		normal operation is to send CC BFD protocol data units (PDUs)
	interleaved with a CV BFD PDU (augmented with a source MEP-ID and		interleaved with a CV BFD PDU (augmented with a Source MEP-ID and
	identified as requiring additional processing by the different ACh		identified as requiring additional processing by the different ACh
	channel type). The insertion interval for CV PDUs is one per second.		channel types). The insertion interval for CV PDUs is one per
	Detection of a loss-of-continuity defect is the detect multiplier		second. Detection of a loss of continuity defect occurs when the
	(fixed at 3 for the CC code point) times the session periodicity.		time since the last received BFD control packet exceeds the detection
			time, which is equal to the session periodicity times the remote
			system's Detect Multiplier (which is set to 3 for the CC code point).
	Mis-connectivity defects are detected in a maximum of one second.		Mis-connectivity defects are detected in a maximum of one second.
	3.4. MPLS-TP BFD CC Message format
	The format of an MPLS-TP CC Message is shown below.		3.4. MPLS-TP BFD CC Message Format
			The format of an MPLS-TP CC message is shown below.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0
	|0 0 0 1|Version| Flags | BFD CC Code point |		0 0 1|Version| Flags | BFD CC Code point |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| |		| ~ BFD Control Packet ~ |
	~ BFD Control Packet ~		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: MPLS-TP CC Message		Figure 2: MPLS-TP CC Message
	As shown in figure 2, the MPLS-TP CC message consists of the BFD		As shown in Figure 2, the MPLS-TP CC message consists of the BFD
	control packet as defined in [4] pre-pended by the G-ACh.		control packet as defined in [4] pre-pended by the G-ACh.
	3.5. MPLS-TP BFD proactive CV Message format		3.5. MPLS-TP BFD Proactive CV Message Format
	The format of an MPLS-TP CV Message is shown below.		The format of an MPLS-TP CV Message is shown below.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 1|Version| Flags | BFD CV Code Point |		|0 0 0 1|Version| Flags | BFD CV Code Point |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ BFD Control Packet ~		~ BFD Control Packet ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ MEP Source ID TLV ~		~ Source MEP-ID TLV ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: MPLS-TP CV Message		Figure 3: MPLS-TP CV Message
	As shown in figure 3, the MPLS-TP CV message consists of the BFD		As shown in Figure 3, the MPLS-TP CV message consists of the BFD
	control packet as defined in [4] pre-pended by the ACH, and appended		control packet as defined in [4], pre-pended by the ACH and appended
	by a MEP source ID TLV.		by a Source MEP-ID TLV.
	A MEP Source ID TLV is encoded as a 2 octet field that specifies a		A Source MEP-ID TLV is encoded as a 2-octet field that specifies a
	Type, followed by a 2 octet Length Field, followed by a variable		Type, followed by a 2-octet Length field, followed by a variable-
	length Value field. A BFD session will only use one encoding of the		length Value field. A BFD session will only use one encoding of the
	Source ID TLV.		Source ID TLV.
	The length in the BFD control packet is as per [4]; the length of the		The length in the BFD control packet is as per [4]; the length of the
	MEP Source ID TLV is not included. There are 3 possible Source MEP		Source MEP-ID TLV is not included. There are three possible Source
	TLVs (corresponding to the MEP-IDs defined in [9]) [type fields to be		MEP TLVs (corresponding to the MEP-IDs defined in [9]). The type
	assigned by IANA]. The type fields are:		fields are:
	X1 - Section MEP-ID		0 - Section MEP-ID
	X2 - LSP MEP-ID		1 - LSP MEP-ID
	X3 - PW MEP-ID		2 - PW MEP-ID
	When GAL label is used, the time to live (TTL) field of the GAL MUST		When the GAL is used, the TTL field of the GAL MUST be set to at
	be set to at least 1, and the GAL MUST be the end of stack label		least 1, and the GAL MUST be the end of stack label (S=1) as per [2].
	(S=1) as per [2].
	A node MUST NOT change the value in the MEP Source ID TLV.		A node MUST NOT change the value in the Source MEP-ID TLV.
	When digest based authentication is used, the Source ID TLV MUST NOT		When digest-based authentication is used, the Source ID TLV MUST NOT
	be included in the digest		be included in the digest.
	3.5.1. Section MEP-ID		3.5.1. Section MEP-ID
	The IP compatible MEP-IDs for MPLS-TP sections is the interface ID.		The IP-compatible MEP-ID for MPLS-TP Sections is the interface ID.
	The format of the Section MEP-ID TLV is:		The format of the Section MEP-ID TLV is:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MPLS-TP Global_ID |		| MPLS-TP Global_ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MPLS-TP Node Identifier |		| MPLS-TP Node Identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MPLS-TP Interface Number |		| MPLS-TP Interface Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: Section MEP-ID TLV format		Figure 4: Section MEP-ID TLV Format
	Where the type is of value 'X1' (to be assigned by IANA). The length		Where the Type is of value '0'. The Length is the length of the
	is the length of the value fields. The MPLS-TP Global ID, Node		value fields. The MPLS-TP Global_ID, Node Identifier, and Interface
	Identifier and Interface Numbers are as per [9].		Numbers are as per [9].
	3.5.2. LSP MEP-ID		3.5.2. LSP MEP-ID
	The fields for the LSP MEP-ID is as defined in [9]. This is		The fields for the LSP MEP-ID are as defined in [9]. This is
	applicable to both LSPs and SPMEs. This consists of 32-bit MPLS-TP		applicable to both LSPs and SPMEs. This consists of the 32-bit MPLS-
	Global ID, the 32-bit Node Identifier, followed by the 16-bit		TP Global_ID, the 32-bit Node Identifier, followed by the 16-bit
	Tunnel_Num (that MUST be unique within the context of the Node		Tunnel_Num (that MUST be unique within the context of the Node
	Identifier), and the 16-bit LSP_NUM (that MUST be unique with the		Identifier), and the 16-bit LSP_NUM (that MUST be unique within the
	context of the Tunnel Num). The format of the TLV is:		context of the Tunnel_Num). The format of the TLV is:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MPLS-TP Global_ID |		| MPLS-TP Global_ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MPLS-TP Node Identifier |		| MPLS-TP Node Identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Tunnel_Num | LSP_Num |		| Tunnel_Num | LSP_Num |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5: LSP MEP-ID TLV format		Figure 5: LSP MEP-ID TLV Format
	Where the type is of value 'X2' (to be assigned by IANA). The length		Where the type is of value '1'. The length is the length of the
	is the length of the value fields. The MPLS-TP Global ID, Node		value fields. The MPLS-TP Global_ID, Node Identifier, Tunnel_Num,
	Identifier, Tunnel Num and LSP_Num are as per [9].		and LSP_Num are as per [9].
	3.5.3. PW Endpoint MEP-ID		3.5.3. PW End Point MEP-ID
	The fields for the MPLS-TP PW Endpoint MEP-ID is as defined in [9].		The fields for the MPLS-TP PW End Point MEP-ID are as defined in [9].
	The format of the TLV is:		The format of the TLV is:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MPLS-TP Global_ID |		| MPLS-TP Global_ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MPLS-TP Node Identifier |		| MPLS-TP Node Identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| AC_ID |		| AC_ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| AGI Type | AGI Length | AGI Value |		| AGI Type | AGI Length | AGI Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ AGI Value (contd.) ~		~ AGI Value (contd.) ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 6: PW Endpoint MEP-ID TLV format		Figure 6: PW End Point MEP-ID TLV Format
	Where the type is value 'X3' (to be assigned by IANA). The length is		Where the type is value '2'. The length is the length of the
	the length of the following data. The Global ID, Node Identifier and		following data: the Global_ID, Node Identifier, and Attachment
	Attachment Circuit (AC)_ID are as per [9]. The Attachment Group		Circuit ID (AC_ID) are as per [9]. The Attachment Group Identifier
	Identifier (AGI) Type is as per [6], and the AGI length is the length		(AGI) Type is as per [6], and the AGI Length is the length of the AGI
	of the AGI value field.		value field.
	3.6. BFD Session in MPLS-TP terminology		3.6. BFD Session in MPLS-TP Terminology
	A BFD session corresponds to a CC and proactive CV OAM instance in		A BFD session corresponds to a CC and proactive CV OAM instance in
	MPLS-TP terminology. A BFD session is enabled when the CC and		MPLS-TP terminology. A BFD session is enabled when the CC and
	proactive CV functionality is enabled on a configured Maintenance		proactive CV functionality are enabled on a configured Maintenance
	Entity (ME).		Entity (ME).
	When the CC and proactive CV functionality is disabled on an ME, the		When the CC and proactive CV functionality are disabled on an ME, the
	BFD session transitions to the ADMIN DOWN State and the BFD session		BFD session transitions to the ADMIN DOWN state, and the BFD session
	ends.		ends.
	A new BFD session is initiated when the operator enables or re-		A new BFD session is initiated when the operator enables or
	enables the CC and CV functionality.		re-enables the CC and CV functionality.
	All BFD state changes and P/F exchanges MUST be done using CC		All BFD state changes and P/F exchanges MUST be done using CC
	packets. P/F and session state information in CV packets MUST be		packets. P/F and session state information in CV packets MUST be
	ignored.		ignored.
	3.7. BFD Profile for MPLS-TP		3.7. BFD Profile for MPLS-TP
	BFD operates in asynchronous mode utilizing the encapsulation defined		BFD operates in asynchronous mode utilizing the encapsulation defined
	in section 3 for all sessions in a given MEG. For LSPs, SPMEs and		in Section 3 for all sessions in a given MEG. For LSPs, SPMEs, and
	sections this is GAL/G-ACh encapsulated BFD using the code points		Sections, this is GAL/G-ACh-encapsulated BFD using the code points
	specified in section 3.3. For PWs, this is G-ACh or GAL/G-ACh		specified in Section 3.3. For PWs, this is G-ACh or GAL/G-ACh-
	encapsulated BFD using the code points specified in section 3.3. In		encapsulated BFD using the code points specified in Section 3.3. In
	this mode, the BFD Control packets are periodically sent at		this mode, the BFD control packets are periodically sent at a
	configurable time rate. This rate is a fixed value common for both		configurable time rate. This rate is a fixed value common for both
	directions of MEG for the lifetime of the MEG.		directions of MEG for the lifetime of the MEG.
	This document specifies bi-directional BFD for p2p transport LSPs;		This document specifies bidirectional BFD for P2P transport LSPs;
	hence all BFD packets MUST be sent with the M bit clear.		hence, all BFD packets MUST be sent with the M bit clear.
	There are two modes of operation for bi-directional LSPs. One in		There are two modes of operation for bidirectional LSPs: one in which
	which the session state of both directions of the LSP is coordinated		the session state of both directions of the LSP is coordinated, and
	and one constructed from BFD sessions in such a way that the two		one constructed from BFD sessions in such a way that the two
	directions operate independently but are still part of the same MEG.		directions operate independently but are still part of the same MEG.
	A single bi-directional BFD session is used for coordinated		A single bidirectional BFD session is used for coordinated operation.
	operation. Two independent BFD sessions are used for independent		Two independent BFD sessions are used for independent operation. It
	operation. It should be noted that independent operation treats		should be noted that independent operation treats session state and
	session state and defect state as independent entities. For example		defect state as independent entities. For example, an independent
	an independent session can be in the UP state while receiving RDI		session can be in the UP state while receiving RDI. For a
	indication. For a coordinated session, the session state will track		coordinated session, the session state will track the defect state.
	the defect state.
	In coordinated mode, an implementation SHOULD NOT reset		In coordinated mode, an implementation SHOULD NOT reset
	bfd.RemoteDiscr until it is exiting the DOWN state.		bfd.RemoteDiscr until it is exiting the DOWN state.
	In independent mode, an implementation MUST NOT reset bfd.RemoteDiscr		In independent mode, an implementation MUST NOT reset bfd.RemoteDiscr
	upon transitioning to the DOWN state.		upon transitioning to the DOWN state.
	Overall operation is as specified in [4] and augmented for MPLS in		Overall operation is as specified in RFC 5880 [4] and augmented for
	[8]. Coordinated operation is as described in [4]. Independent		MPLS in RFC 5884 [8]. Coordinated operation is as described in [4].
	operation requires clarification of two aspects of [4]. Independent		Independent operation requires clarification of two aspects of [4].
	operation is characterized by the setting of bfd.MinRxInterval to		Independent operation is characterized by the setting of
	zero by the MEP that is typically the session originator (referred to		bfd.MinRxInterval to zero by the MEP that is typically the session
	as the source MEP), and there will be a session originator at either		originator (referred to as the source MEP), and there will be a
	end of the bi-directional LSP. Each source MEP will have a		session originator at either end of the bidirectional LSP. Each
	corresponding sink MEP that has been configured to a Tx interval of		source MEP will have a corresponding sink MEP that has been
	zero.		configured to a transmission interval of zero.
	This memo specifies a preferred interpretation of the base spec on		This memo specifies a preferred interpretation of the base
	how a MEP with a BFD transmit rate set to zero behaves. One		specification on how a MEP behaves with a BFD transmit rate set to
	interpretation is that no periodic messages on the reverse component		zero. One interpretation is that no periodic messages on the reverse
	of the bi-directional LSP originate with that MEP, it will only		component of the bidirectional LSP originate with that MEP; it will
	originate messages on a state change.		only originate messages on a state change.
	The first clarification is that when a state change occurs a MEP set		The first clarification is that, when a state change occurs, a MEP
	to a transmit rate of zero sends BFD control messages with a one		set to a transmit rate of zero sends BFD control messages with a one-
	second period on the reverse component until such time that the state		second period on the reverse component until such time that the state
	change is confirmed by the session peer. At this point the MEP set to		change is confirmed by the session peer. At this point, the MEP set
	a transmit rate of zero can resume quiescent behavior. This adds		to a transmit rate of zero can resume quiescent behavior. This adds
	robustness to all state transitions in the RxInterval=0 case.		robustness to all state transitions in the RxInterval=0 case.
	The second is that the originating MEP (the one with a non-zero		The second clarification is that the originating MEP (the one with a
	bfd.TxInterval) will ignore a DOWN state received from a zero		non-zero bfd.TxInterval) will ignore a DOWN state received from a
	interval peer. This means that the zero interval peer will continue		zero-interval peer. This means that the zero-interval peer will
	to send DOWN state messages that include the RDI diagnostic code as		continue to send DOWN state messages that include the RDI diagnostic
	the state change is never confirmed. This adds robustness to the		code as the state change is never confirmed. This adds robustness to
	exchange of RDI indication on a uni-directional failure (for both		the exchange of RDI on a unidirectional failure (for both session
	session types DOWN with a diagnostic of either control detection		types DOWN with a diagnostic of either control detection period
	period expired or neighbor signaled session down offering RDI		expired or neighbor signaled session down offering RDI
	functionality).		functionality).
	A further extension to the base specification is that there are		A further extension to the base specification is that there are
	additional OAM protocol exchanges that act as inputs to the BFD state		additional OAM protocol exchanges that act as inputs to the BFD state
	machine; these are the Link Down Indication [5] and the Lock		machine. These are the Link Down Indication [5] and the Lock
	Instruct/Lock Report transactions; Lock Report interaction being		Instruct/Lock Report transactions, the Lock Report interaction being
	optional.		optional.
	3.7.1. Session initiation and Modification		3.7.1. Session Initiation and Modification
	Session initiation occurs starting from MinRx = 1 second, MinTx >= 1		Session initiation occurs starting from MinRx = 1 second, MinTx >= 1
	second and the detect multiplier = 3.		second, and the detect multiplier = 3.
	Once in the UP state, poll/final discipline is used to modify the
			Once in the UP state, Poll/Final discipline is used to modify the
	periodicity of control message exchange from their default rates to		periodicity of control message exchange from their default rates to
	the desired rates and set the detect multiplier to 3.		the desired rates and to set the detect multiplier to 3.
	Once the desired rate has been reached using the poll/final
			Note that in the Poll/Final process a receiver of a new timer value
			with a poll flag can reject the timer value by tearing the session,
			or it can return its preferred timer value with the final flag. Note
			also that the receiver of a new timer value with a final flag can
			reject the timer value by tearing the session, or it can return its
			preferred timer value with the poll flag.
			Once the desired rate has been reached using the Poll/Final
	mechanism, implementations SHOULD NOT attempt further rate		mechanism, implementations SHOULD NOT attempt further rate
	modification.		modification.
	In the rare circumstance where an operator has a reason to further		In the rare circumstance where an operator has a reason to further
	change session parameters, beyond the initial migration from default		change session parameters, beyond the initial migration from default
	values; poll/final discipline can be used with the caveat that a peer		values, Poll/Final discipline can be used with the caveat that a peer
	implementation may consider a session change unacceptable and/or		implementation may consider a session change unacceptable and/or
	bring the BFD session down via the use of the ADMIN DOWN state.		bring the BFD session down via the use of the ADMIN DOWN state.
	3.7.2. Defect entry criteria		3.7.2. Defect Entry Criteria
	There are further defect criteria beyond those that are defined in		There are further defect criteria beyond those that are defined in
	[4] to consider given the possibility of mis-connectivity defects.		[4] to consider given the possibility of mis-connectivity defects.
	The result is the criteria for a LSP direction to transition from the		The result is the criteria for an LSP direction to transition from
	defect free state to a defect state is a superset of that in the BFD		the defect-free state to a defect state is a superset of that in the
	base specification [4].		BFD base specification [4].
	The following conditions cause a MEP to enter the defect state for CC		The following conditions cause a MEP to enter the defect state for CC
	PDUs (in no particular order):		PDUs (in no particular order):
	1. BFD session times out (loss-of-continuity defect).
	2. Receipt of a link down indication or lock report.
	And the following will cause the MEP to enter the mis-connectivity		1. BFD session times out (loss of continuity defect).
	defect state for CV operation (again not in any particular order):
	1. BFD control packets are received with an unexpected
	encapsulation (mis-connectivity defect), these include:
	- receiving an IP encoded CC or CV BFD control packet on a
	LSP configured to use GAL/G-ACh, or vice versa
	(note there are other possibilities that can also alias as an
	OAM packet)
	2. Receipt of an unexpected globally unique Source MEP identifier
	(Mis-connectivity defect). Note that as each encoding of the
	Source MEP ID TLV contains unique information (there is no
	mechanical translation possible between MEP ID formats), receipt
	of an unexpected source MEP ID type is the same as receiving an
	unexpected value.
	3. Receipt of a session discriminator that is not in the local BFD
	database in the Your Discriminator field (mis-connectivity
	defect).
	4. Receipt of a session discriminator that is in the local database
	but does not have the expected label (mis-connectivity defect).
	5. IF BFD authentication is used, receipt of a message with
	incorrect authentication information (password, MD5 digest, or
	SHA1 hash).
	The effective defect hierarchy (order of checking) is		2. Receipt of a Link Down Indication or Lock Report.
	1. Receiving nothing.		The following will cause the MEP to enter the mis-connectivity defect
			state for CV operation (again, not in any particular order):
	2. Receiving link down indication. E.g. a local link failure, an		1. BFD control packets are received with an unexpected
	MPLS-TP LDI indication, or Lock Report.		encapsulation (mis-connectivity defect), these include:
	3. Receiving from an incorrect source (determined by whatever		- receiving an IP encoded CC or CV BFD control packet on an
	means).		LSP configured to use GAL/G-ACh, or
			- vice versa
			(Note there are other possibilities that can also alias as an
			OAM packet.)
	4. Receiving from a correct source (as near as can be determined),		2. Receipt of an unexpected globally unique Source MEP identifier
	but with incorrect session information).		(mis-connectivity defect). Note that as each encoding of the
			Source MEP-ID TLV contains unique information (there is no
			mechanical translation possible between MEP-ID formats),
			receipt of an unexpected Source MEP-ID type is the same as
			receiving an unexpected value.
	5. Receiving BFD control packets in all discernable ways correct.		3. Receipt of a session discriminator that is not in the local BFD
			database in the Your Discriminator field (mis-connectivity
			defect).
	3.7.3. Defect entry consequent action		4. Receipt of a session discriminator that is in the local
			database but does not have the expected label (mis-connectivity
			defect).
	Upon defect entry a sink MEP will assert signal fail into any client		5. If BFD authentication is used, receipt of a message with
	(sub-)layers. It will also communicate session DOWN to its session		incorrect authentication information (password, MD5 digest, or
			SHA1 hash).
			The effective defect hierarchy (order of checking) is:
			1. Receiving nothing.
			2. Receiving Link Down Indication, e.g., a local link failure, an
			MPLS-TP LDI, or Lock Report.
			3. Receiving from an incorrect source (determined by whatever
			means).
			4. Receiving from a correct source (as near as can be determined),
			but with incorrect session information.
			5. Receiving BFD control packets in all discernable ways correct.
			3.7.3. Defect Entry Consequent Action
			Upon defect entry, a sink MEP will assert signal fail into any client
			(sub-)layers. It will also communicate session DOWN to its session
	peer using CC messages.		peer using CC messages.
	The blocking of traffic as a consequent action MUST be driven only by		The blocking of traffic as a consequent action MUST be driven only by
	a defect's consequent action as specified in [13] section 5.1.1.2.		a defect's consequent action as specified in Section 5.1.1.2 of RFC
			6371 [13].
	When the defect is mis-connectivity, the section, LSP or PW		When the defect is mis-connectivity, the Section, LSP, or PW
	termination will silently discard all non-OAM traffic received. The		termination will silently discard all non-OAM traffic received. The
	sink MEP will also send a defect indication back to the source MEP		sink MEP will also send a defect indication back to the source MEP
	via the use of a diagnostic code of mis-connectivity defect to be		via the use of a diagnostic code of mis-connectivity defect (9).
	assigned by IANA.
	3.7.4. Defect exit criteria		3.7.4. Defect Exit Criteria
	3.7.4.1. Exit from a loss-of-continuity defect		3.7.4.1. Exit from a Loss of Continuity Defect
	For a coordinated session, exit from a loss-of-connectivity defect is		For a coordinated session, exit from a loss of connectivity defect is
	as described in figure 7 which updates [4].		as described in Figure 7, which updates RFC 5880 [4].
	For an independent session, exit from a loss-of-connectivity defect		For an independent session, exit from a loss of connectivity defect
	occurs upon receipt of a well formed BFD control packet from the peer		occurs upon receipt of a well-formed BFD control packet from the peer
	MEP as described in figures 8 and 9.		MEP as described in Figures 8 and 9.
	3.7.4.2. Exit from a mis-connectivity defect		3.7.4.2. Exit from a Mis-Connectivity Defect
	Exit from a mis-connectivity defect state occurs when no CV messages		Exit from a mis-connectivity defect state occurs when no CV messages
	with mis-connectivity defects have been received for a period of 3.5		with mis-connectivity defects have been received for a period of 3.5
	seconds.		seconds.
	3.7.5. State machines		3.7.5. State Machines
	The following state machines update [4]. They have been modified to		The following state machines update RFC 5880 [4]. They have been
	include LDI and LKR as specified in [5] as inputs to the state		modified to include LDI and LKR as specified in [5] as inputs to the
	machine and to clarify the behavior for independent mode. LKR is an		state machine and to clarify the behavior for independent mode. LKR
	optional input.		is an optional input.
	The coordinated session state machine has been augmented to indicate		The coordinated session state machine has been augmented to indicate
	LDI and optionally LKR as inputs to the state machine. For a session		LDI and optionally LKR as inputs to the state machine. For a session
	that is in the UP state, receipt of LDI or optionally LKR will		that is in the UP state, receipt of LDI or optionally LKR will
	transition the session into the DOWN state.		transition the session into the DOWN state.
	+--+		+--+
	| | UP, ADMIN DOWN, TIMER, LDI, LKR		| | UP, ADMIN DOWN, TIMER, LDI, LKR
	| V		| V
	DOWN +------+ INIT		DOWN +------+ INIT
	+------------| |------------+		+------------| |------------+
	| | DOWN | |		| | DOWN | |
	| +-------->| |<--------+ |		| +-------->| |<--------+ |
	| | +------+ | |		| | +------+ | |
	| | MISCONNECTIVITY,| |		| | MIS-CONNECTIVITY,| |
	| | ADMIN DOWN,| |		| | ADMIN DOWN,| |
	| |ADMIN DOWN, DOWN,| |		| |ADMIN DOWN, DOWN,| |
	| |TIMER TIMER,| |		| |TIMER TIMER,| |
	V |LDI,LKR LDI,LKR | V		V |LDI,LKR LDI,LKR | V
	+------+ +------+		+------+ +------+
	+----| | | |----+		+----| | | |----+
	DOWN| | INIT |--------------------->| UP | |INIT, UP		DOWN| | INIT |--------------------->| UP | |INIT, UP
	+--->| | INIT, UP | |<---+		+--->| | INIT, UP | |<---+
	+------+ +------+		+------+ +------+
	Figure 7: MPLS CC state machine for coordinated session operation		Figure 7: MPLS CC State Machine for Coordinated Session Operation
	For independent mode, there are two state machines. One for the		For independent mode, there are two state machines: one for the
	source MEP (which requested bfd.MinRxInterval=0) and the sink MEP		source MEP (which requested bfd.MinRxInterval=0) and one for the sink
	(which agreed to bfd.MinRxInterval=0).		MEP (which agreed to bfd.MinRxInterval=0).
	The source MEP will not transition out of the UP state once		The source MEP will not transition out of the UP state once
	initialized except in the case of a forced ADMIN DOWN. Hence LDI and		initialized except in the case of a forced ADMIN DOWN. Hence, LDI
	optionally LKR do not enter into the state machine transition from		and optionally LKR do not enter into the state machine transition
	the UP state, but do enter into the INIT and DOWN states.		from the UP state, but do enter into the INIT and DOWN states.
	+--+		+--+
	| | UP, ADMIN DOWN, TIMER, LDI, LKR		| | UP, ADMIN DOWN, TIMER, LDI, LKR
	| V		| V
	DOWN +------+ INIT		DOWN +------+ INIT
	+------------| |------------+		+------------| |------------+
	| | DOWN | |		| | DOWN | |
	| +-------->| |<--------+ |		| +-------->| |<--------+ |
	| | +------+ | |		| | +------+ | |
	| | | |		| | | |
	| |ADMIN DOWN ADMIN DOWN | |		| |ADMIN DOWN ADMIN DOWN | |
	| |TIMER, | |		| |TIMER, | |
	| |LDI, | |		| |LDI, | |
	V |LKR | V		V |LKR | V
	+------+ +------+		+------+ +------+
	skipping to change at page 17, line 20		skipping to change at page 16, line 24
	| |ADMIN DOWN ADMIN DOWN | |		| |ADMIN DOWN ADMIN DOWN | |
	| |TIMER, | |		| |TIMER, | |
	| |LDI, | |		| |LDI, | |
	V |LKR | V		V |LKR | V
	+------+ +------+		+------+ +------+
	+----| | | |----+		+----| | | |----+
	DOWN| | INIT |--------------------->| UP | | INIT, UP, DOWN,		DOWN| | INIT |--------------------->| UP | | INIT, UP, DOWN,
	+--->| | INIT, UP | |<---+ LDI, LKR		+--->| | INIT, UP | |<---+ LDI, LKR
	+------+ +------+		+------+ +------+
	Figure 8: MPLS CC State machine for source MEP for independent		Figure 8: MPLS CC State Machine for Source MEP for
	session operation		Independent Session Operation
	The sink MEP state machine (for which the transmit interval has been		The sink MEP state machine (for which the transmit interval has been
	set to zero) is modified to:		set to zero) is modified to:
	1) Permit direct transition from DOWN to UP once the session has been		1) Permit direct transition from DOWN to UP once the session has been
	initialized. With the exception of via the ADMIN DOWN state, the		initialized. With the exception of via the ADMIN DOWN state, the
	source MEP will never transition from the UP state, hence in normal		source MEP will never transition from the UP state; hence, in
	unidirectional fault scenarios will never transition to the INIT		normal unidirectional fault scenarios, it will never transition to
	state.		the INIT state.
	+--+		+--+
	| | ADMIN DOWN, TIMER, LDI, LKR		| | ADMIN DOWN, TIMER, LDI, LKR
	| V		| V
	DOWN +------+ INIT, UP		DOWN +------+ INIT, UP
	+------------| |------------+		+------------| |------------+
	| | DOWN | |		| | DOWN | |
	| +-------->| |<--------+ |		| +-------->| |<--------+ |
	| | +------+ | |		| | +------+ | |
	| | MISCONNECTIVITY,| |		| | MIS-CONNECTIVITY,| |
	| | ADMIN DOWN,| |		| | ADMIN DOWN,| |
	| |ADMIN DOWN, TIMER, | |		| |ADMIN DOWN, TIMER, | |
	| |TIMER, DOWN, | |		| |TIMER, DOWN, | |
	| |LDI, LDI, | V		| |LDI, LDI, | V
	V |LKR LKR | |		V |LKR LKR | |
	+------+ +------+		+------+ +------+
	+----| | | |----+		+----| | | |----+
	DOWN| | INIT |--------------------->| UP | |INIT, UP		DOWN| | INIT |--------------------->| UP | |INIT, UP
	+--->| | INIT, UP | |<---+		+--->| | INIT, UP | |<---+
	+------+ +------+		+------+ +------+
	Figure 9: MPLS CC State machine for the sink MEP for independent		Figure 9: MPLS CC State Machine for the Sink MEP
	session operation		for Independent Session Operation
	3.7.6. Configuration of MPLS-TP BFD sessions		3.7.6. Configuration of MPLS-TP BFD Sessions
	Configuration of MPLS-TP BFD session parameters and coordination of		The configuration of MPLS-TP BFD session parameters and the
	same between the source and sink MEPs is out of scope of this memo.		coordination of the same between the source and sink MEPs are out of
			scope of this memo.
	3.7.7. Discriminator values		3.7.7. Discriminator Values
	In the BFD control packet the discriminator values have either local		In the BFD control packet, the discriminator values either are local
	to the sink MEP or no significance (when not known).		to the sink MEP or have no significance (when not known).
	My Discriminator field MUST be set to a nonzero value (it can be a		The My Discriminator field MUST be set to a non-zero value (which can
	fixed value), the transmitted Your Discriminator value MUST reflect		be a fixed value). The transmitted Your Discriminator value MUST
	back the received value of My Discriminator field or be set to 0 if		reflect back the received value of the My Discriminator field or be
	that value is not known.		set to zero if that value is not known.
	Per RFC5884 Section 7 [8], a node MUST NOT change the value of the My		Per Section 7 of RFC 5884 [8], a node MUST NOT change the value of
	Discriminator" field for an established BFD session.		the My Discriminator field for an established BFD session.
	4. Configuration Considerations		4. Configuration Considerations
	The following is an example set of configuration parameters for a BFD		The following is an example set of configuration parameters for a BFD
	session:		session:
	Mode and Encapsulation		Mode and Encapsulation
			----------------------
	RFC 5884 - BFD CC in UDP/IP/LSP		RFC 5884 - BFD CC in UDP/IP/LSP
	RFC 5885 - BFD CC in G-ACh		RFC 5885 - BFD CC in G-ACh
	RFC 5085 - UDP/IP in G-ACh		RFC 5085 - UDP/IP in G-ACh
	MPLS-TP - CC/CV in GAL/G-ACh or G-ACh		MPLS-TP - CC/CV in GAL/G-ACh or G-ACh
	For MPLS-TP, the following additional parameters need to be		For MPLS-TP, the following additional parameters need to be
	configured:		configured:
	1) Session mode, coordinated or independent		1) Session mode, coordinated or independent
	2) CC periodicity		2) CC periodicity
	3) The MEP ID for the MEPs at either end of the LSP		3) The MEP-ID for the MEPs at either end of the LSP
	4) Whether authentication is enabled (and if so, the associated		4) Whether authentication is enabled (and if so, the associated
	parameters)		parameters)
	And the the discriminators used by each MEP, both bfd.LocalDiscr and		The discriminators used by each MEP, both bfd.LocalDiscr and
	bfd.RemoteDiscr can optionally be configured or locally assigned.		bfd.RemoteDiscr, can optionally be configured or locally assigned.
	Finally a detect multiplier of 3 is directly inferred from the code		Finally, a detect multiplier of 3 is directly inferred from the code
	points.		points.
	5. Acknowledgments		5. IANA Considerations
	Nitin Bahadur, Rahul Aggarwal, Tom Nadeau, Nurit Sprecher and Yaacov		IANA has allocated two channel types from the "Pseudowire Associated
	Weingarten also contributed to this document.		Channel Types" registry in RFC 4385 [15].
	6. IANA Considerations		0x0022 MPLS-TP CC message
			0x0023 MPLS-TP CV message
	This draft requires the allocation of two channel types from the IANA		IANA has created a "CC/CV MEP-ID TLV" registry. The parent registry
	"PW Associated Channel Type" registry in RFC4446 [6].		is the "Pseudowire Associated Channel Types" registry of RFC 4385
	XX1 MPLS-TP CC message		[15]. All code points within this registry shall be allocated
	XX2 MPLS-TP CV message		according to the "Standards Action" procedures as specified in [11].
	This draft requires the creations of a source MEP-ID TLV		The items tracked in the registry will be the type, associated name,
	registry. The parent registry will be the "PW Associated Channel		and reference.
	Type" registry of RFC4446 [6]. All code points within this
	registry shall be allocated according to the "Standards Action"
	procedures as specified in [11].
	The initial values are:		The initial values are:
	X1 - Section MEP-ID		0 - Section MEP-ID
			1 - LSP MEP-ID
	X2 - LSP MEP-ID		2 - PW MEP-ID
	X3 - PW MEP-ID
	The items tracked in the registry will be the type, and the
	associated name and reference. The source MEP-ID TLV will require
	standards action registration procedures for additional values.
	This memo requests a code point from the registry for BFD		IANA has assigned the following code point from the "Bidirectional
	diagnostic codes [4]:		Forwarding Detection (BFD) Parameters" registry, "BFD Diagnostic
			Codes" subregistry [4]:
	XX - - mis-connectivity defect		9 - mis-connectivity defect
	7. Security Considerations		6. Security Considerations
	The use of CV improves network integrity by ensuring traffic is		The use of CV improves network integrity by ensuring traffic is not
	not "leaking" between LSPs.		"leaking" between LSPs.
	Base BFD foresees an optional authentication section (see [4]		Base BFD foresees an optional authentication section (see Section 6.7
	section 6.7); that can be applied to this application. Although		of [4]) that can be applied to this application. Although the Source
	the source MEP-ID TLV is not included in the BFD authentication		MEP-ID TLV is not included in the BFD authentication digest, there is
	digest, there is a chain of trust such that the discriminator		a chain of trust such that the discriminator associated with the
	associated with the digest is also associated with the expected		digest is also associated with the expected MEP-ID; this will prevent
	MEP-ID which will prevent impersonation of CV messages in this		impersonation of CV messages in this application.
	application.
	This memo specifies the use of globally unique identifiers for		This memo specifies the use of globally unique identifiers for MEP-
	MEP IDs. This provides absolutely authoritative detection of		IDs. This provides absolutely authoritative detection of persistent
	persistent leaking of traffic between LSPs. Non-uniqueness can		leaking of traffic between LSPs. Non-uniqueness can result in
	result in undetected leaking in the scenario where two LSPs with		undetected leaking in the scenario where two LSPs with common MEP-IDs
	common MEP IDs are misconnected. This would be considered to be		are misconnected. This would be considered undesirable but rare; it
	undesirable but rare, it would also be difficult to exploit for		would also be difficult to exploit for malicious purposes as, at a
	malicious purposes as at a minimum, both a network end point,		minimum, both a network end point and a node that was a transit point
	and a node that was a transit point for the target MEG would		for the target MEG would need to be compromised.
	need to be compromised.
	8. References		7. References
	8.1. Normative References		7.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Bocci, M. et al., "MPLS Generic Associated Channel ", RFC		[2] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS
	5586 , June 2009		Generic Associated Channel", RFC 5586, June 2009.
	[3] Vigoureux, M., Betts, M. and D. Ward, "Requirements for		[3] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
	Operations Administration and Maintenance in MPLS		"Requirements for Operations, Administration, and Maintenance
	Transport Networks", RFC5860, May 2010		(OAM) in MPLS Transport Networks", RFC 5860, May 2010.
	[4] Katz, D. and D. Ward, "Bidirectional Forwarding		[4] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
	Detection", RFC 5880, June 2010		(BFD)", RFC 5880, June 2010.
	[5] Swallow, G. et al., "MPLS Fault Management OAM", draft-		[5] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed.,
	ietf-mpls-tp-fault-04 (work in progress), April 2011		Boutros, S., and D. Ward, "MPLS Fault Management Operations,
			Administration, and Maintenance (OAM)", RFC 6427, November
			2011.
	[6] Martini, L., "IANA Allocations for Pseudowire Edge to Edge		[6] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
	Emulation (PWE3)", RFC 4446, April 2006		Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
	[7] Nadeau, T. et al. "Bidirectional Forwarding Detection		[7] Nadeau, T., Ed., and C. Pignataro, Ed., "Bidirectional
	(BFD) for the Pseudowire Virtual Circuit Connectivity		Forwarding Detection (BFD) for the Pseudowire Virtual Circuit
	Verification (VCCV) ", IETF RFC 5885, June 2010		Connectivity Verification (VCCV)", RFC 5885, June 2010.
	[8] Aggarwal, R. et.al., "Bidirectional Forwarding Detection		[8] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
	(BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884,		"Bidirectional Forwarding Detection (BFD) for MPLS Label
	June 2010		Switched Paths (LSPs)", RFC 5884, June 2010.
	[9] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft-		[9] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile
	ietf-mpls-tp-identifiers-06 (work in progress), June 2011		(MPLS-TP) Identifiers", RFC 6370, September 2011.
	[10] Nadeau, T, et al., "Pseudowire Virtual Circuit		[10] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual
	Connectivity Verification (VCCV): A Control Channel for		Circuit Connectivity Verification (VCCV): A Control Channel for
	Pseudowires", RFC 5085, December 2007		Pseudowires", RFC 5085, December 2007.
	[11] Narten, T., Alvestrand, H., "Guidelines for Writing an		[11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
	IANA Considerations Section in RFCs", IETF RFC 5226, May		Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
	2008
	8.2. Informative References		7.2. Informative References
	[12] Bocci, M., et al., "A Framework for MPLS in Transport		[12] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L.,
	Networks", RFC5921, July 2010		and L. Berger, "A Framework for MPLS in Transport Networks",
			RFC 5921, July 2010.
	[13] Allan, D., and Busi, I. "MPLS-TP OAM Framework", draft-		[13] Busi, I., Ed., and D. Allan, Ed., "Operations, Administration,
	ietf-mpls-tp-oam-framework-11 (work in progress), February		and Maintenance Framework for MPLS-Based Transport Networks",
	2011		RFC 6371, September 2011.
	[14] Andersson et. al., "OAM Terminology", IETF RFC 6291, June		[14] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and
	2011		S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in
			the IETF", BCP 161, RFC 6291, June 2011.
	Authors' Addresses		[15] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
			"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use
			over an MPLS PSN", RFC 4385, February 2006.
	Dave Allan		8. Acknowledgments
	Ericsson
	Email: david.i.allan@ericsson.com
	John Drake		Nitin Bahadur, Rahul Aggarwal, Tom Nadeau, Nurit Sprecher, and Yaacov
	Juniper		Weingarten also contributed to this document.
	Email: jdrake@juniper.net
	George Swallow		9. Contributing Authors
	Cisco Systems, Inc.
	Email: swallow@cisco.com
	Annamaria Fulignoli		Annamaria Fulignoli
	Ericsson		Ericsson
	Email: annamaria.fulignoli@ericsson.com		EMail: annamaria.fulignoli@ericsson.com
	Sami Boutros		Sami Boutros
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Email: sboutros@cisco.com		EMail: sboutros@cisco.com
	Martin Vigoureux		Martin Vigoureux
	Alcatel-Lucent		Alcatel-Lucent
	Email: martin.vigoureux@alcatel-lucent.com		EMail: martin.vigoureux@alcatel-lucent.com
	Siva Sivabalan		Siva Sivabalan
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Email: msiva@cisco.com		EMail: msiva@cisco.com
	David Ward		David Ward
	Juniper		Juniper
	Email: dward@juniper.net		EMail: dward@juniper.net
	Robert Rennison		Robert Rennison
	ECI Telecom		ECI Telecom
	Email: robert.rennison@ecitele.com		EMail: robert.rennison@ecitele.com
			Editors' Addresses
			Dave Allan
			Ericsson
			EMail: david.i.allan@ericsson.com
			George Swallow
			Cisco Systems, Inc.
			EMail: swallow@cisco.com
			John Drake
			Juniper
			EMail: jdrake@juniper.net
End of changes. 202 change blocks.
	509 lines changed or deleted		514 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/