draft-ietf-mpls-tp-cc-cv-rdi-02.txt		draft-ietf-mpls-tp-cc-cv-rdi-03.txt
	MPLS Working Group Dave Allan, Ed.		MPLS Working Group Dave Allan, Ed.
	Internet Draft Ericsson		Internet Draft Ericsson
	Intended status: Standards Track		Intended status: Standards Track
	Expires: April 2011 George Swallow Ed.		Expires: August 2011 George Swallow Ed.
	Cisco Systems, Inc		Cisco Systems, Inc
	John Drake Ed.		John Drake Ed.
	Juniper		Juniper
	October 22, 2010		February 2, 2011
	Proactive Connectivity Verification, Continuity Check and Remote		Proactive Connectivity Verification, Continuity Check and Remote
	Defect indication for MPLS Transport Profile		Defect indication for MPLS Transport Profile
	draft-ietf-mpls-tp-cc-cv-rdi-02		draft-ietf-mpls-tp-cc-cv-rdi-03
	Abstract		Abstract
	Continuity Check (CC), Proactive Connectivity Verification (CV) and		Continuity Check (CC), Proactive Connectivity Verification (CV) and
	Remote Defect Indication (RDI) functionalities are required for MPLS-		Remote Defect Indication (RDI) functionalities are required for MPLS-
	TP OAM.		TP OAM.
	Continuity Check monitors the integrity of the continuity of the LSP		Continuity Check monitors the integrity of the continuity of the LSP
	for any loss of continuity defect. Connectivity verification monitors		for any loss of continuity defect. Connectivity verification monitors
	the integrity of the routing of the LSP between sink and source for		the integrity of the routing of the LSP between sink and source for
	skipping to change at page 2, line 19		skipping to change at page 2, line 19
	documents at any time. It is inappropriate to use Internet-		documents at any time. It is inappropriate to use Internet-
	Drafts as reference material or to cite them other than as "work		Drafts as reference material or to cite them other than as "work
	in progress".		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 November 28, 2010.		This Internet-Draft will expire on August 2nd 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with		carefully, as they describe your rights and restrictions with
	respect to this document. Code Components extracted from this		respect to this document. Code Components extracted from this
	document must include Simplified BSD License text as described		document must include Simplified BSD License text as described
	in Section 4.e of the Trust Legal Provisions and are provided		in Section 4.e of the Trust Legal Provisions and are provided
	without warranty as described in the Simplified BSD License.		without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction...................................................3		1. Introduction...................................................3
	1.1. Authors......................................................4		1.1. Authors......................................................4
	2. Conventions used in this document..............................4		2. Conventions used in this document..............................4
	2.1. Terminology..................................................4		2.1. Terminology..................................................4
	2.2. Issues for discussion........................................5
	3. MPLS CC, proactive CV and RDI Mechanism using BFD..............5		3. MPLS CC, proactive CV and RDI Mechanism using BFD..............5
	3.1. ACH code points for CC and proactive CV......................6		3.1. ACH code points for CC and proactive CV......................6
	3.2. MPLS BFD CC Message format...................................6		3.2. MPLS BFD CC Message format...................................6
	3.3. MPLS BFD proactive CV Message format.........................7		3.3. MPLS BFD proactive CV Message format.........................7
	3.4. BFD Session in MPLS-TP terminology...........................7		3.3.1. ICC-based MEP-ID...........................................8
	3.5. BFD Profile for MPLS-TP......................................8		3.3.2. LSP MEP-ID.................................................8
	3.5.1. Session initiation.........................................9		3.3.3. PW Endpoint MEP-ID.........................................8
	3.5.2. Defect entry criteria......................................9		3.4. BFD Session in MPLS-TP terminology...........................8
	3.5.3. Defect entry consequent action............................10		3.5. BFD Profile for MPLS-TP......................................9
	3.5.4. Defect exit criteria......................................11		3.5.1. Session initiation........................................10
	3.5.5. State machines............................................11		3.5.2. Defect entry criteria.....................................10
	3.5.6. Configuration of MPLS-TP BFD sessions.....................14		3.5.3. Defect entry consequent action............................11
	3.5.7. Discriminator values......................................14		3.5.4. Defect exit criteria......................................12
	4. Acknowledgments...............................................15		3.5.5. State machines............................................12
	5. IANA Considerations...........................................15		3.5.6. Configuration of MPLS-TP BFD sessions.....................15
	6. Security Considerations.......................................15		3.5.7. Discriminator values......................................15
	7. References....................................................15		4. Acknowledgments...............................................16
	7.1. Normative References........................................15		5. IANA Considerations...........................................16
	7.2. Informative References......................................16		6. Security Considerations.......................................16
			7. References....................................................16
			7.1. Normative References........................................16
			7.2. Informative References......................................17
	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 OAM tools to detect mis-		more switches. Service Providers (SP) need OAM tools to detect mis-
	connectivity and loss of continuity of transport circuits. Both PWs		connectivity and loss of continuity of transport circuits. Both PWs
	and MPLS-TP LSPs [7] emulating traditional transport circuits need to		and MPLS-TP LSPs [10] emulating traditional transport circuits need
	provide the same CC and proactive CV capabilities as required in		to provide the same CC and proactive CV capabilities as required in
	draft-ietf-mpls-tp-oam-requirements[3]. This document describes the		RFC 5860[3]. This document describes the use of BFD for CC, proactive
	use of BFD for CC, proactive CV, and RDI of a PW, LSP or SPME between		CV, and RDI of a PW, LSP or SPME between two Maintenance Entity Group
	two Maintenance Entity Group End Points (MEPs).		End Points (MEPs).
	As described in [9], Continuity Check (CC) and Proactive Connectivity		As described in [11], Continuity Check (CC) and Proactive
	Verification (CV) functions are used to detect loss of continuity		Connectivity Verification (CV) functions are used to detect loss of
	(LOC), and unintended connectivity between two MEPs (e.g. mismerging		continuity (LOC), and unintended connectivity between two MEPs (e.g.
	or misconnectivity or unexpected MEP).		mismerging or misconnectivity or unexpected MEP).
	The Remote Defect Indication (RDI) is an indicator that is		The Remote Defect Indication (RDI) is an indicator that is
	transmitted by a MEP to communicate to its peer MEP that a signal		transmitted by a MEP to communicate to its peer MEP that a signal
	fail condition exists. RDI is only used for bidirectional LSPs and is		fail condition exists. RDI is only used for bidirectional LSPs and is
	associated with proactive CC & CV packet generation.		associated with proactive CC & CV 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 bi-directional LSPs. Supported
	encapsulations include GAL/G-ACh, VCCV and UDP/IP. Procedures for		encapsulations include GAL/G-ACh, VCCV and UDP/IP. Procedures for
	skipping to change at page 5, line 10		skipping to change at page 5, line 10
	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. Issues for discussion
	1) Requirement for additional BFD diagnostic codes?
	1. When periodicity of CV cannot be supported
	3. MPLS CC, proactive CV and RDI Mechanism using BFD		3. MPLS CC, proactive CV and RDI Mechanism using BFD
	This document proposes distinct encapsulations and code points for		This document proposes distinct encapsulations and code points for
	ACh encapsulated BFD depending on whether the mode of operation is CC		ACh encapsulated BFD depending on whether the mode of operation is CC
	or CV:		or CV:
	o CC mode: defines a new code point in the Associated Channel Header		o CC mode: defines a new code point in the Associated Channel Header
	(ACH) described in [2].In this mode Continuity Check and RDI		(ACH) described in RFC 5586[2].In this mode Continuity Check and
	functionalities are supported.		RDI functionalities are supported.
	o CV mode: defines a new code point in the Associated Channel Header		o CV mode: defines a new code point in the Associated Channel Header
	(ACH) described in [2]. The ACH with "MPLS Proactive CV" code		(ACH) described in RFC 5586[2]. The ACH with "MPLS Proactive CV"
	point indicates that the message is an MPLS BFD proactive CV and		code point indicates that the message is an MPLS BFD proactive CV
	CC message and CC, CV and RDI functionalities are supported.		and CC message and CC, CV and RDI functionalities are supported.
	RDI: is communicated via the BFD diagnostic field in BFD CC and CV		RDI: is communicated via the BFD diagnostic field in BFD CC and CV
	messages. It is not a distinct PDU. A sink MEP will encode a		messages. It is not a distinct PDU. A sink MEP will encode a
	diagnostic code of "1- Control detection time expired" when the		diagnostic code of "1- Control detection time expired" when the
	interval times detect multipler have been exceeded, and with "3 -		interval times detect multipler have been exceeded, and with "3 -
	neighbor signaled session down" as a consequence of the sink MEP		neighbor signaled session down" as a consequence of the sink MEP
	receiving AIS with LDI set. A sink MEP that has started sending diag		receiving AIS with LDI set. A sink MEP that has started sending diag
	code 3 will NOT change it to 1 when the detection timer expires.		code 3 will NOT change it to 1 when the detection timer expires.
	In accordance with RFC 5586, when these packets are encapsulated in		In accordance with RFC 5586[2], when these packets are encapsulated
	an IP header the fields in the IP header are set as defined in RFC		in an IP header, the fields in the IP header are set as defined in
	5884. It should also be noted that existing ACh code points and		RFC 5884[8]. Further existing ACh code points and mechanisms for BFD
	mechanisms for negotiating the control channel and connectivity		VCCV are specified in RFC5885[7]. These MAY be applied to
	verification (i.e. OAM functions) between PEs are specified for		Pseudowires by configuration. Also by configuration, the BFD PW-ACH-
	VCCV[6].		encapsulated for PW fault detection only encapsulation can be applied
			to bi-directional LSPs by employing the GAL to indicate the presence
			of the ACh.
			A further artifact of IP encapsulation is that CV mis-connectivity
			defect detection can be performed by inferring MEP_ID on the basis of
			the combination of the source IP address and "my discriminator"
			fields.
	3.1. ACH code points for CC and proactive CV		3.1. ACH code points for CC and proactive CV
	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 |0xHH BFD CC/CV Code Point |		|0 0 0 1|Version| Flags |0xHH BFD CC/CV Code Point |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: ACH Indication of MPLS-TP Connectivity Verification		Figure 1: ACH Indication of MPLS-TP Connectivity Verification
	skipping to change at page 6, line 27		skipping to change at page 6, line 27
	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 = 0xHH. [HH to be assigned by IANA from the PW		- BFD CC code point = 0xHH. [HH to be assigned by IANA from the PW
	Associated Channel Type registry.] or,		Associated Channel Type registry.] or,
	- BFD proactive CV code point = 0xHH. [HH to be assigned by IANA from		- BFD proactive CV code point = 0xHH. [HH to be assigned by IANA from
	the PW Associated Channel Type registry.]		the PW Associated Channel Type registry.]
	Both CC and CV modes apply to PWs, MPLS LSPs (including tandem		Both CC and CV modes apply to PWs, MPLS LSPs (including SPMEs), and
	connection monitoring), and Sections.		Sections.
	CC and CV operation can be simultaneously employed on an ME within a		CC and CV operation can be simultaneously employed on an ME within a
	single BFD session. The expected usage is that normal operation is to		single BFD session. The expected usage is that normal operation is to
	send CC BFD PDUs with every nth BFD PDU augmented with a source MEP		send CC BFD PDUs with every nth BFD PDU augmented with a source MEP-
	ID and identified as requiring additional processing by the different		ID and identified as requiring additional processing by the different
	ACh channel type.		ACh channel type. When CC and CV are interleaved, the minimum
			insertion interval for CV PDUs is one per second.
	3.2. MPLS BFD CC Message format		3.2. MPLS BFD CC Message format
	The format of an MPLS CC Message is shown below.		The format of an MPLS 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 1|Version| Flags | 0xHH BFD CC Code point |		|0 0 0 1|Version| Flags | 0xHH BFD CC Code point |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 7, line 27		skipping to change at page 7, line 27
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Unique MEP-ID of source of the BFD packet ~		~ Unique MEP-ID of source of the BFD packet ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: MPLS CV Message		Figure 3: MPLS CV Message
	As shown in Figure 3, BFD Control packet as defined in [4] is		As shown in Figure 3, BFD Control packet as defined in [4] is
	transmitted as MPLS labeled packets along with the ACH. Appended to		transmitted as MPLS labeled packets along with the ACH. Appended to
	the BFD control packet is a MEP Source ID TLV. The length in the BFD		the BFD control packet is a MEP Source ID TLV.
	control packet is as per [4]. There are 4 possible Source MEP TLVs
	(corresponding to the MEP IDs defined in [8] [type fields to be
	assigned by IANA]. The type fields are:
	X1 - ICC encoded MEP ID		A MEP Source ID TLV is encoded as a 2 octet field that specifies a
			Type, followed by a 2 octet Length Field, followed by a variable
			length Value field.
	X2 - LSP-MEP_ID		The length in the BFD control packet is as per [4]. There are 3
			Source MEP TLVs (corresponding to the MEP-IDs defined in Error!
			Reference source not found. [type fields to be assigned by IANA]. The
			type fields are:
	X3 - PW MEP ID		X1 - ICC encoded MEP-ID
	X4 - PW Segment endpoint ID		X2 - LSP MEP-ID
			X3 - PW MEP-ID
	When GAL label is used, the TTL field of the GAL MUST be set to at		When GAL label is used, the TTL field of the GAL MUST be set to at
	least 1, and the GAL will be the end of stack label (S=1).		least 1, and the GAL will be the end of stack label (S=1).
			A node MUST NOT change the value in the MEP Source ID TLV.
			When digest based authentication is used, the Source ID TLV MUST NOT
			be included in the digest
			3.3.1. ICC-based MEP-ID
			As defined in [9], the ICC-based MEP_ID consists of the MEG_ID, a
			string of up to 13 characters (A-Z and 0-9), followed by the MEP
			Index, an unsigned 16 bit integer that MUST be unique within the
			context of the MEG_ID.
			3.3.2. LSP MEP-ID
			As defined in [9], the MPLS_TP LSP MEP-ID consists of the Node
			Identifier, a thirty two bit identifier that MUST be unique within
			the context of an operator's network, followed by the Tunnel_Num, an
			unsigned sixteen bit integer that MUST be unique within the context
			of the Node Identifier, and the LSP_NUM, an unsigned sixteen bit
			integer that MUST be unique with the context of the Tunnel Num.
			3.3.3. PW Endpoint MEP-ID
			As defined in [9], the PW Endpoint MEP-ID consists of the Node
			Identifier, a thirty two bit identifier that MUST be unique within
			the context of an operator's network, followed by the AC_ID, a thirty
			two bit identifier that MUST be unique within the context of the Node
			Identifier.
			In situations where global uniqueness is required, the Node
			Identifier is preceded by the Global ID, a thirty two bit identifier
			that contains the two-octet (right hand justified and preceded by
			sixteen bits of zero) or four-octet value of the operator's
			Autonomous System Number (ASN).
	3.4. BFD Session in MPLS-TP terminology		3.4. BFD Session in MPLS-TP terminology
	A BFD session corresponds to a CC or a proactive CV OAM instance in		A BFD session corresponds to a CC or a proactive CV OAM instance in
	MPLS-TP terminology.		MPLS-TP terminology.
	A BFD session is enabled when the CC or proactive CV functionality is		A BFD session is enabled when the CC or proactive CV functionality is
	enabled on a configured Maintenance Entity (ME)..		enabled on a configured Maintenance Entity (ME)..
	On a Sink MEP, a BFD session can be in DOWN, INIT or UP state as		On a Sink MEP, a BFD session can be in DOWN, INIT or UP state as
	detailed in [4].		detailed in [4].
	skipping to change at page 8, line 21		skipping to change at page 9, line 11
	A new BFD session is initiated when the operator enables or re-		A new BFD session is initiated when the operator enables or re-
	enables the CC or CV functionality on the same ME.		enables the CC or CV functionality on the same ME.
	3.5. BFD Profile for MPLS-TP		3.5. BFD Profile for MPLS-TP
	BFD MUST operate in asynchronous mode. In this mode, the BFD Control		BFD MUST operate in asynchronous mode. In this mode, the BFD Control
	packets are periodically sent at configurable time rate. This rate is		packets are periodically sent at configurable time rate. This rate is
	typically a fixed value for the lifetime of the session. In the rare		typically a fixed value for the lifetime of the session. In the rare
	circumstance where an operator has a reason to change session		circumstance where an operator has a reason to change session
	parameters, the session must be moved to the ADMIN DOWN state.		parameters, the session MUST be moved to the ADMIN DOWN state.
	Poll/final discipline can only used for VCCV and UDP/IP encapsulated		Poll/final discipline can only used for VCCV and UDP/IP encapsulated
	BFD.		BFD.
	The transport profile is designed to operate independent of the
	control plane; hence the C bit SHOULD be set.
	This document specifies bi-directional BFD for p2p transport LSPs,		This document specifies bi-directional BFD for p2p transport LSPs,
	hence the M bit MUST be clear.		hence the M bit MUST be clear.
	There are two modes of operation for bi-directional LSPs. One in		There are two modes of operation for bi-directional LSPs. One in
	which the session state of both directions of the LSP is coordinated		which the session state of both directions of the LSP is coordinated
	and one constructed from BFD sessions in such a way that the two		and one constructed from BFD sessions in such a way that the two
	directions operate independently. A single bi-directional BFD session		directions operate independently. A single bi-directional BFD session
	is used for coordinated operation. Two independent BFD sessions are		is used for coordinated operation. Two independent BFD sessions are
	used for independent operation.		used for independent operation.
	skipping to change at page 9, line 30		skipping to change at page 10, line 17
	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; Lock Report interaction being
	optional.		optional.
	3.5.1. Session initiation		3.5.1. Session initiation
	In all scenarios a BFD session starts with both ends in the DOWN		In all scenarios a BFD session starts with both ends in the DOWN
	state. DOWN state messages exchanged include the desired Tx and Rx		state. DOWN state messages exchanged include the desired Tx and Rx
	rates for the session. If a node cannot support the Min Tx rate		rates for the session. If a node cannot support the Min Tx rate
	desired by a peer MEP it does not transition from down to the INIT		desired by a peer MEP it does not transition from down to the INIT
	state and sends a diagnostic code (TBD) indicating that the requested		state and sends a diagnostic code of configuration error (to be
	Tx rate cannot be supported.		assigned by IANA) indicating that the requested Tx rate cannot be
			supported.
	Otherwise once a transition from DOWN to INIT has occurred, the		Otherwise once a transition from DOWN to INIT has occurred, the
	session progresses as per [4]. In both the DOWN and INIT states		session progresses as per [4]. In both the DOWN and INIT states
	messages are transmitted at a rate of one per second and the defect		messages are transmitted at a rate of one per second and the defect
	detection interval is fixed at 3.5 seconds. On transition to the UP		detection interval is fixed at 3.5 seconds. On transition to the UP
	state message periodicity changes to the negotiated rate and the		state, message periodicity changes to the negotiated and/or
	detect interval switches to detect multiplier times the session		configured rate and the detect interval switches to detect multiplier
	peer's Tx Rate.		times the session peer's Tx Rate.
	3.5.2. Defect entry criteria		3.5.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 and mis-		[4] to consider given the possibility of mis-connectivity and mis-
	configuration defects. The result is the criteria for a LSP direction		configuration defects. The result is the criteria for a LSP direction
	to transition from the defect free state to a defect state is a		to transition from the defect free state to a defect state is a
	superset of that in the BFD base specification [4].		superset of that in the 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
	or CV:		or CV:
	skipping to change at page 10, line 4		skipping to change at page 10, line 39
	3.5.2. Defect entry criteria		3.5.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 and mis-		[4] to consider given the possibility of mis-connectivity and mis-
	configuration defects. The result is the criteria for a LSP direction		configuration defects. The result is the criteria for a LSP direction
	to transition from the defect free state to a defect state is a		to transition from the defect free state to a defect state is a
	superset of that in the BFD base specification [4].		superset of that in the 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
	or CV:		or CV:
	1. BFD session times out (Loss of Continuity defect).		1. BFD session times out (Loss of Continuity defect).
	2. Receipt of a link down indication.		2. Receipt of a link down indication.
	3. Receipt of an unexpected M bit (Session Mis-configuration		3. Receipt of an unexpected M bit (Session Mis-configuration
	defect).		defect).
	And the following will cause the MEP to enter the defect state for CV		And the following will cause the MEP to enter the defect state for CV
	operation		operation
	1. BFD control packets are received with an unexpected		1. BFD control packets are received with an unexpected
	encapsulation (mis-connectivity defect), these include:		encapsulation (mis-connectivity defect), these include:
	- a PW receiving a packet with a GAL		- a PW receiving a packet with a GAL
	- an LSP receiving an IP header instead of a GAL		- receiving an IP encoded CC or CV packet on a LSP configured
			to use GAL/GaCH, or vice versa
	(note there are other possibilities that can also alias as an		(note there are other possibilities that can also alias as an
	OAM packet)		OAM packet)
	2. Receipt of an unexpected globally unique Source MEP identifier		2. Receipt of an unexpected globally unique Source MEP identifier
	(Mis-connectivity defect).		(Mis-connectivity defect).
	3. Receipt of an unexpected session discriminator in the your		3. Receipt of an unexpected session discriminator in the your
	discriminator field (mis-connectivity defect).		discriminator field (mis-connectivity defect).
	4. Receipt of an expected session discriminator with an unexpected		4. Receipt of an expected session discriminator with an unexpected
	label (mis-connectivity defect).		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		The effective defect hierarchy (order of checking) is
	1. Receiving nothing.		1. Receiving nothing.
	2. Receiving link down indication.		2. Receiving link down indication.
	3. Receiving from an incorrect source (determined by whatever		3. Receiving from an incorrect source (determined by whatever
	means).		means).
	skipping to change at page 10, line 46		skipping to change at page 11, line 40
	5. Receiving control packets in all discernable ways correct.		5. Receiving control packets in all discernable ways correct.
	3.5.3. Defect entry consequent action		3.5.3. Defect entry consequent action
	Upon defect entry a sink MEP will assert signal fail into any client		Upon defect entry a sink MEP will assert signal fail into any client
	(sub-)layers. It will also communicate session DOWN to its session		(sub-)layers. It will also communicate session DOWN to its session
	peer.		peer.
	The blocking of traffic as consequent action MUST be driven only by a		The blocking of traffic as consequent action MUST be driven only by a
	defect's consequent action as specified in draft-ietf-mpls-tp-oam-		defect's consequent action as specified in draft-ietf-mpls-tp-oam-
	framework [9] section 5.1.1.2.		framework [11] section 5.1.1.2.
	When the defect is mis-branching, the LSP termination will silently		When the defect is mis-branching, the LSP termination will silently
	discard all non-oam traffic received.		discard all non-oam traffic received.
	3.5.4. Defect exit criteria		3.5.4. Defect exit criteria
	3.5.4.1. Exit from a Loss of continuity defect		3.5.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 4 which updates [4].		as described in figure 4 which updates [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 control packet from the peer MEP		occurs upon receipt of a well formed control packet from the peer MEP
	as described in figures 5 and 6.		as described in figures 5 and 6.
	3.5.4.2. Exit from a session mis-configuration defect		3.5.4.2. Exit from a session mis-configuration defect
	[editors: for a future version of the document]		Exit from a misconfiguration defect occurs when two consecutive CC or
			CV frames have been received with the expected M bit setting.
	3.5.4.3. Exit from a mis-connectivity defect		3.5.4.3. Exit from a mis-connectivity defect
	[Editors node: The shift to CC with interleaved CV suggests the CV		Exit from a mis-connectivity defect state occurs when no CV messages
	periodicity may not be known by a sink MEP, hence exit criteria from		have been received with an incorrect source MEP-ID for a period of
	a mis-connectivity defect may not be able to be established. We		3.5 seconds.
	suggest two possible resolutions for this:
	1. Exit criteria is manual intervention.
	2. A minimum CV insertion rate (say 1/sec) be specified such that
	the exit criteria be specified as no mis-connected CV PDUs be
	received for a minimum of 3 times the minimum insertion rate]
	3.5.5. State machines		3.5.5. State machines
	The following state machines update [4]. They have been modified to		The following state machines update [4]. They have been modified to
	include AIS with LDI set and LKI as inputs to the state machine and		include AIS with LDI set and LKI as specified in [5] as inputs to the
	to clarify the behavior for independent mode. LKR is an optional		state machine and to clarify the behavior for independent mode. LKR
	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
	AIS with LDI set and optionally LKR as inputs to the state machine.		AIS with LDI set and optionally LKR as inputs to the state machine.
	For a session that is in the UP state, receipt of AIS with LDI set or		For a session that is in the UP state, receipt of AIS with LDI set or
	optionally LKR will transition the session into the DOWN state.		optionally LKR will transition the session into the DOWN state.
	+--+		+--+
	| | UP, ADMIN DOWN, TIMER, AIS-LDI, LKR		| | UP, ADMIN DOWN, TIMER, AIS-LDI, LKR
	| V		| V
	DOWN +------+ INIT		DOWN +------+ INIT
	skipping to change at page 14, line 30		skipping to change at page 15, line 30
	+----| | | |----+		+----| | | |----+
	DOWN| | INIT |--------------------->| UP | |INIT, UP		DOWN| | INIT |--------------------->| UP | |INIT, UP
	+--->| | INIT, UP | |<---+		+--->| | INIT, UP | |<---+
	+------+ +------+		+------+ +------+
	Figure 6: State machine for the sink MEP for independent session		Figure 6: State machine for the sink MEP for independent session
	operation		operation
	3.5.6. Configuration of MPLS-TP BFD sessions		3.5.6. Configuration of MPLS-TP BFD sessions
	[Editors note, for a future revision of the document]		Configuration of MPLS-TP BFD session paramters and coordination of
			same between the source and sink MEPs is out of scope of this memo.
	3.5.7. Discriminator values		3.5.7. Discriminator values
	In the BFD control packet the discriminator values have either local		In the BFD control packet the discriminator values have either local
	to the sink MEP or no significance (when not known).		to the sink MEP or no significance (when not known).
	My Discriminator field MUST be set to a nonzero value (it can be a		My Discriminator field MUST be set to a nonzero value (it can be a
	fixed value), the transmitted your discriminator value MUST reflect		fixed value), the transmitted your discriminator value MUST reflect
	back the received value of My discriminator field or be set to 0 if		back the received value of My discriminator field or be set to 0 if
	that value is not known.		that value is not known.
	Although the BFD base specification permits an implementation to		Per RFC5884 Section 7 [8], a node MUST NOT change the value of the
	change the my discriminator field at arbitrary times, this is not		"my discriminator" field for an established BFD session.
	permitted for CV mode in order to avoid race conditions in mis-
	connectivity defects.
	4. Acknowledgments		4. Acknowledgments
	To be added in a later version of this document		Nitin Bahadur, Rahul Aggarwal, Dave Ward, Tom Nadeau, Nurit
			Sprecher and Yaacov Weingarten also contributed to this
			document.
	5. IANA Considerations		5. IANA Considerations
	To be added in a later version of this document		This draft requires the allocation of two channel types from the
			the IANA "PW Associated Channel Type" registry in RFC4446 [6].
	6. Security Considerations		Xx MPLS-TP CC message
	The security considerations for the authentication TLV need further		Xx+1 MPLS-TP CV message
	study.
	Base BFD foresees an optional authentication section (see [4]		This draft requires the creations of a source MEP-ID TLV
	section 6.7); that can be extended also to the tool proposed in		registry with initial values of:
	this document.
	Authentication methods that require checksum calculation on the		Xx - ICC encoded MEP-ID
	outgoing packet must extend the checksum also on the ME
	Identifier Section. This is possible but seems uncorrelated with		Xx+1 - LSP MEP-ID
	the solution proposed in this document: it could be better to
	use the simple password authentication method.		Xx+2 - PW MEP-ID
			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
			diagnostic codes [4]:
			Xx - configuration error
			6. Security Considerations
			Base BFD foresees an optional authentication section (see [4]
			section 6.7); that can be applied to this application.
	7. References		7. References
	7.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 Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[2] Bocci, M. et al., " MPLS Generic Associated Channel ", RFC		[2] Bocci, M. et al., " MPLS Generic Associated Channel ", RFC
	5586 , June 2009		5586 , June 2009
	[3] Vigoureux, M., Betts, M. and D. Ward, "Requirements for		[3] Vigoureux, M., Betts, M. and D. Ward, "Requirements for
	Operations Administration and Maintenance in MPLS		Operations Administration and Maintenance in MPLS
	Transport Networks", RFC5860, May 2010		Transport Networks", RFC5860, May 2010
	[4] Katz, D. and D. Ward, "Bidirectional Forwarding		[4] Katz, D. and D. Ward, "Bidirectional Forwarding
	Detection", RFC 5880, June 2010		Detection", RFC 5880, June 2010
	[5] Swallow, G. et al., "MPLS Fault Management OAM", draft-		[5] Swallow, G. et al., "MPLS Fault Management OAM", draft-
	ietf-mpls-tp-fault-02 (work in progress), July 2010		ietf-mpls-tp-fault-03 (work in progress), October 2010
	[6] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit		[6] Martini, L., " IANA Allocations for Pseudowire Edge to
	Connectivity Verification (VCCV): A Control Channel for		Edge Emulation (PWE3)", RFC 4446, April 2006
	Pseudowires", RFC 5085, December 2007
	7.2. Informative References		[7] Nadeau, T. et al. "Bidirectional Forwarding Detection
			(BFD) for the Pseudowire Virtual Circuit Connectivity
			Verification (VCCV) ", IETF RFC 5885, June 2010
	[7] Bocci, M., et al., "A Framework for MPLS in Transport		[8] Aggarwal, R. et.al., "Bidirectional Forwarding Detection
	Networks", RFC5921, July 2010		(BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884,
			June 2010
	[8] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft-		[9] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft-
	swallow-mpls-tp-identifiers-02 (work in progress), July		ietf-mpls-tp-identifiers-03 (work in progress), October
	2010		2010
	[9] Allan, D., and Busi, I. "MPLS-TP OAM Framework", draft-		7.2. Informative References
	ietf-mpls-tp-oam-framework-09 (work in progress), October
			[10] Bocci, M., et al., "A Framework for MPLS in Transport
			Networks", RFC5921, July 2010
			[11] Allan, D., and Busi, I. "MPLS-TP OAM Framework", draft-
			ietf-mpls-tp-oam-framework-10 (work in progress), December
	2010		2010
	Authors' Addresses		Authors' Addresses
	Dave Allan		Dave Allan
	Ericsson		Ericsson
	Email: david.i.allan@ericsson.com		Email: david.i.allan@ericsson.com
	John Drake		John Drake
	Juniper		Juniper
End of changes. 47 change blocks.
	115 lines changed or deleted		172 lines changed or added
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/