draft-ietf-mpls-tp-gach-gal-05.txt		draft-ietf-mpls-tp-gach-gal-06.txt
	MPLS Working Group M. Bocci, Ed.		MPLS Working Group M. Bocci, Ed.
	Internet-Draft M. Vigoureux, Ed.		Internet-Draft M. Vigoureux, Ed.
	Updates: 3032, 4385, 5085 Alcatel-Lucent		Updates: 3032, 4385, 5085 Alcatel-Lucent
	(if approved) G. Swallow		(if approved) S. Bryant
	Intended status: Standards Track D. Ward		Intended status: Standards Track Cisco
	Expires: November 17, 2009 S. Bryant		Expires: November 22, 2009
	Cisco
	R. Aggarwal		May 21, 2009
	Juniper Networks
	May 16, 2009
	MPLS Generic Associated Channel		MPLS Generic Associated Channel
	draft-ietf-mpls-tp-gach-gal-05		draft-ietf-mpls-tp-gach-gal-06
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 38		skipping to change at page 1, line 36
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 17, 2009.		This Internet-Draft will expire on November 22, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 36		skipping to change at page 2, line 36
	3.1. ACH TLV Payload Structure . . . . . . . . . . . . . . . . 7		3.1. ACH TLV Payload Structure . . . . . . . . . . . . . . . . 7
	3.2. ACH TLV Header . . . . . . . . . . . . . . . . . . . . . . 8		3.2. ACH TLV Header . . . . . . . . . . . . . . . . . . . . . . 8
	3.3. ACH TLV Object . . . . . . . . . . . . . . . . . . . . . . 8		3.3. ACH TLV Object . . . . . . . . . . . . . . . . . . . . . . 8
	4. Generalized Exception Mechanism . . . . . . . . . . . . . . . 9		4. Generalized Exception Mechanism . . . . . . . . . . . . . . . 9
	4.1. Relationship with Existing MPLS OAM Alert Mechanisms . . . 9		4.1. Relationship with Existing MPLS OAM Alert Mechanisms . . . 9
	4.2. GAL Applicability and Usage . . . . . . . . . . . . . . . 10		4.2. GAL Applicability and Usage . . . . . . . . . . . . . . . 10
	4.2.1. GAL Processing . . . . . . . . . . . . . . . . . . . . 10		4.2.1. GAL Processing . . . . . . . . . . . . . . . . . . . . 10
	4.3. Relationship with RFC 3429 . . . . . . . . . . . . . . . . 13		4.3. Relationship with RFC 3429 . . . . . . . . . . . . . . . . 13
	5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14		5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14
	6. Congestion Considerations . . . . . . . . . . . . . . . . . . 15		6. Congestion Considerations . . . . . . . . . . . . . . . . . . 15
	7. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 15		7. Major Contributing Authors . . . . . . . . . . . . . . . . . . 15
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 15		9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 17		11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	11.2. Informative References . . . . . . . . . . . . . . . . . . 18		11.2. Informative References . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	There is a need for Operations, Administration and Maintenance (OAM)		There is a need for Operations, Administration and Maintenance (OAM)
	mechanisms that can be used for fault detection, diagnostics,		mechanisms that can be used for fault detection, diagnostics,
	maintenance and other functions on a pseudowire (PW) and a Label		maintenance and other functions on a pseudowire (PW) and a Label
	Switched Path (LSP). These functions can be used between any two		Switched Path (LSP). These functions can be used between any two
	Label Edge Routers (LERs) / Label Switching Router (LSRs) or		Label Edge Routers (LERs) / Label Switching Router (LSRs) or
	Terminating Provider Edge routers (T-PEs) / Switching Provider Edge		Terminating Provider Edge routers (T-PEs) / Switching Provider Edge
	routers (S-PEs) along the path of an LSP or PW respectively [11].		routers (S-PEs) along the path of an LSP or PW respectively [11].
	skipping to change at page 5, line 33		skipping to change at page 5, line 33
	The terms 'Section' and 'Concatenated Segment' are defined in [16] as		The terms 'Section' and 'Concatenated Segment' are defined in [16] as
	follows (note that the terms 'Section' and 'Section Layer Network'		follows (note that the terms 'Section' and 'Section Layer Network'
	are synonymous):		are synonymous):
	Concatenated Segment: A serial-compound link connection as defined in		Concatenated Segment: A serial-compound link connection as defined in
	[17]. A concatenated segment is a contiguous part of an LSP or		[17]. A concatenated segment is a contiguous part of an LSP or
	multi-segment PW that comprises a set of segments and their		multi-segment PW that comprises a set of segments and their
	interconnecting nodes in sequence.		interconnecting nodes in sequence.
	Section Layer Network: A section is a server layer (which may be		Section Layer Network: A section layer is a server layer (which may
	MPLS-TP or a different technology) which provides for encapsulation		be MPLS-TP or a different technology) which provides for the transfer
	and OAM of a client layer network. A section layer may provide for		of the section layer client information between adjacent nodes in the
	aggregation of multiple MPLS-TP clients. Note that G.805 [17]		transport path layer or transport service layer. Note that G.805
	defines the section layer as one of the two layer networks in a		[17] defines the section layer as one of the two layer networks in a
	transmission media layer network. The other layer network is the		transmission media layer network. The other layer network is the
	physical media layer network.		physical media layer network.
	2. Generic Associated Channel Header		2. Generic Associated Channel Header
	VCCV [1] defines three Control Channel (CC) Types that may be used to		VCCV [1] defines three Control Channel (CC) Types that may be used to
	exchange OAM messages through a PW: CC Type 1 uses an ACH and is		exchange OAM messages through a PW: CC Type 1 uses an ACH and is
	referred to as "In-band VCCV"; CC Type 2 uses the MPLS Router Alert		referred to as "In-band VCCV"; CC Type 2 uses the MPLS Router Alert
	Label to indicate VCCV packets and is referred to as "Out of Band		Label to indicate VCCV packets and is referred to as "Out of Band
	VCCV"; CC Type 3 uses the TTL to force the packet to be processed by		VCCV"; CC Type 3 uses the TTL to force the packet to be processed by
	skipping to change at page 6, line 27		skipping to change at page 6, line 27
	|0 0 0 1|Version| Reserved | Channel Type |		|0 0 0 1|Version| Reserved | Channel Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Associated Channel Header		Figure 1: Associated Channel Header
	In the above figure, the first nibble is set to 0001b to indicate a		In the above figure, the first nibble is set to 0001b to indicate a
	control channel associated with a PW, an LSP or a Section. The		control channel associated with a PW, an LSP or a Section. The
	Version field is set to 0, as specified in RFC 4385 [2]. Bits 8 to		Version field is set to 0, as specified in RFC 4385 [2]. Bits 8 to
	15 of the ACH are reserved and MUST be set to 0 and ignored on		15 of the ACH are reserved and MUST be set to 0 and ignored on
	reception. Bits 16 to 31 are used to encode the possible Channel		reception. Bits 16 to 31 are used to encode the possible Channel
	Types.		Types. This 16 bit field is in network byte order.
	Note that VCCV [1] also includes mechanisms for negotiating the		Note that VCCV [1] also includes mechanisms for negotiating the
	Control Channel and Connectivity Verification (i.e., OAM function)		Control Channel and Connectivity Verification (i.e., OAM function)
	Types between PEs. It is anticipated that similar mechanisms will be		Types between PEs. It is anticipated that similar mechanisms will be
	applied to LSPs. Such application will require further		applied to LSPs. Such application will require further
	specification. However, such specification is beyond the scope of		specification. However, such specification is beyond the scope of
	this document.		this document.
	The G-ACh MUST NOT be used to transport user traffic.		The G-ACh MUST NOT be used to transport user traffic.
	skipping to change at page 8, line 44		skipping to change at page 8, line 44
	The Length field specifies the length in octets of the complete set		The Length field specifies the length in octets of the complete set
	of TLVs including sub-TLVs that follow the ACH TLV header. A length		of TLVs including sub-TLVs that follow the ACH TLV header. A length
	of zero indicates that no ACH TLV follow this header. Note that no		of zero indicates that no ACH TLV follow this header. Note that no
	padding is required for the set of ACH TLVs.		padding is required for the set of ACH TLVs.
	The Reserved field is for future use and MUST be set to zero on		The Reserved field is for future use and MUST be set to zero on
	transmission and ignored on reception.		transmission and ignored on reception.
	3.3. ACH TLV Object		3.3. ACH TLV Object
	The structure of ACH TLVs that MAY follow an ACH TLV Header is		ACH TLVs MAY follow an ACH TLV header. The structure of ACH TLVs is
	defined and described in this section.		defined and described in this section.
	An ACH TLV consists of a 16-bit Type field, followed by a 16-bit		An ACH TLV consists of a 16-bit Type field, followed by a 16-bit
	Length field which specifies the number of octets of the Value field		Length field which specifies the number of octets of the Value field
	which follows the Length field. This 32-bit word is followed by zero		which follows the Length field. This 32-bit word is followed by zero
	or more octets of Value information. The format and semantics of the		or more octets of Value information. The format and semantics of the
	Value information are defined by the TLV Type as recorded in the TLV		Value information are defined by the TLV Type as recorded in the TLV
	Type registry. See Section 10 for further details. Note that the		Type registry. See Section 10 for further details. Note that the
	Value field of ACH TLVs MAY contain sub-TLVs. Note that no padding		Value field of ACH TLVs MAY contain sub-TLVs. Note that no padding
	is required for individual TLVs or sub-TLVs.		is required for individual TLVs or sub-TLVs.
	skipping to change at page 12, line 12		skipping to change at page 12, line 12
	LSRs MUST NOT modify the G-ACh message, the ACH or the GAL towards		LSRs MUST NOT modify the G-ACh message, the ACH or the GAL towards
	the targeted destination.		the targeted destination.
	Note: This is because once a G-ACh packet has been sent on an LSP,		Note: This is because once a G-ACh packet has been sent on an LSP,
	no node has visibility of it unless the LSP label TTL expires or		no node has visibility of it unless the LSP label TTL expires or
	the GAL is exposed when the LSP label is popped. If this is at		the GAL is exposed when the LSP label is popped. If this is at
	the targeted destination, for example indicated by an address in		the targeted destination, for example indicated by an address in
	an ACH TLV, then processing can proceed as specified below. If		an ACH TLV, then processing can proceed as specified below. If
	this is not the targeted destination, but the node has agreed to		this is not the targeted destination, but the node has agreed to
	process packets on that ACH channel, then the processing applied		process packets on that ACH channel, then the processing applied
	to the packet is out of scope of this docuemnt. However, the ACH		to the packet is out of scope of this document.
	type MUST be maintained if the packet is forwarded unmodified to
	another node.
	Upon reception of the labeled packet, the targeted destination, after		Upon reception of the labeled packet, the targeted destination, after
	having checked both the LSP Label and GAL LSEs fields, SHOULD pass		having checked both the LSP Label and GAL LSEs fields, SHOULD pass
	the whole packet to the appropriate processing entity.		the whole packet to the appropriate processing entity.
	4.2.1.2. MPLS Section		4.2.1.2. MPLS Section
	The following figure (Figure 7) depicts an example of an MPLS		The following figure (Figure 7) depicts an example of an MPLS
	Section.		Section.
	skipping to change at page 15, line 10		skipping to change at page 15, line 10
	o The ACH version is not recognized.		o The ACH version is not recognized.
	In addition, the LER, LSR or PE MAY increment an error counter and		In addition, the LER, LSR or PE MAY increment an error counter and
	MAY also issue a system and/or SNMP notification.		MAY also issue a system and/or SNMP notification.
	6. Congestion Considerations		6. Congestion Considerations
	The congestion considerations detailed in RFC 5085 [1] apply.		The congestion considerations detailed in RFC 5085 [1] apply.
	7. Contributing Authors		7. Major Contributing Authors
	The editors gratefully acknowledge the contributions of Sami Boutros,		The editors would like to thank George Swallow, David Ward, and Rahul
	Italo Busi, Marc Lasserre, Lieven Levrau and Siva Sivabalan		Aggarwal, who made a major contribution to the developement of this
			document.
	8. Acknowledgments		8. Acknowledgments
	The authors would like to thank Malcolm Betts, ITU-T Study Group 15,		The editors gratefully acknowledge the contributions of Sami Boutros,
	and all members of the teams (the Joint Working Team, the MPLS		Italo Busi, Marc Lasserre, Lieven Levrau and Siva Sivabalan.
			The authors would also like to thank Malcolm Betts, ITU-T Study Group
			15, and all members of the teams (the Joint Working Team, the MPLS
	Interoperability Design Team in IETF and the MPLS-TP Ad-Hoc Team in		Interoperability Design Team in IETF and the MPLS-TP Ad-Hoc Team in
	ITU-T) involved in the definition and specification of the MPLS		ITU-T) involved in the definition and specification of the MPLS
	Transport Profile.		Transport Profile.
	9. Security Considerations		9. Security Considerations
	The security considerations for the associated control channel are		The security considerations for the associated control channel are
	described in RFC 4385 [2]. Further security considerations MUST be		described in RFC 4385 [2]. Further security considerations MUST be
	described in the relevant associated channel type specification.		described in the relevant associated channel type specification.
	skipping to change at page 16, line 22		skipping to change at page 16, line 30
	optimizations or extensions to OAM and other control protocols		optimizations or extensions to OAM and other control protocols
	running in an associated channel to be experimented without resorting		running in an associated channel to be experimented without resorting
	to the IETF standards process, by supporting experimental code		to the IETF standards process, by supporting experimental code
	points. This would prevent code points used for such functions from		points. This would prevent code points used for such functions from
	being used from the range allocated through the IETF standards and		being used from the range allocated through the IETF standards and
	thus protects an installed base of equipment from potential		thus protects an installed base of equipment from potential
	inadvertent overloading of code points. In order to support this		inadvertent overloading of code points. In order to support this
	requirement, this document requests that the code point allocation		requirement, this document requests that the code point allocation
	scheme for the PW Associated Channel Type be changed as follows:		scheme for the PW Associated Channel Type be changed as follows:
	0 - 32751 : IETF Consensus		0 - 32751 : IETF Review
	32760 - 32767 : Experimental		32760 - 32767 : Experimental
	Code points in the experimental range MUST be used according to the		Code points in the experimental range MUST be used according to the
	guidelines of RFC 3692 [10]. Functions using experimental G-ACh code		guidelines of RFC 3692 [10]. Functions using experimental G-ACh code
	points MUST be disabled by default. The Channel Type value used for		points MUST be disabled by default. The Channel Type value used for
	a given experimental OAM function MUST be configurable, and care MUST		a given experimental OAM function MUST be configurable, and care MUST
	be taken to ensure that different OAM functions that are not inter-		be taken to ensure that different OAM functions that are not inter-
	operable are configured to use different Channel Type values.		operable are configured to use different Channel Type values.
	skipping to change at page 18, line 31		skipping to change at page 18, line 45
	Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-04		Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-04
	(work in progress), May 2009.		(work in progress), May 2009.
	[15] Vigoureux, M., Ward, D., and M. Betts, "Requirements for OAM in		[15] Vigoureux, M., Ward, D., and M. Betts, "Requirements for OAM in
	MPLS Transport Networks",		MPLS Transport Networks",
	draft-ietf-mpls-tp-oam-requirements-01 (work in progress),		draft-ietf-mpls-tp-oam-requirements-01 (work in progress),
	March 2009.		March 2009.
	[16] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and		[16] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and
	S. Ueno, "MPLS-TP Requirements",		S. Ueno, "MPLS-TP Requirements",
	draft-ietf-mpls-tp-requirements-06 (work in progress),		draft-ietf-mpls-tp-requirements-08 (work in progress),
	April 2009.		May 2009.
	[17] International Telecommunication Union, "Generic Functional		[17] International Telecommunication Union, "Generic Functional
	Architecture of Transport Networks", ITU-T G.805, March 2000.		Architecture of Transport Networks", ITU-T G.805, March 2000.
	[18] Ohta, H., "Assignment of the 'OAM Alert Label' for		[18] Ohta, H., "Assignment of the 'OAM Alert Label' for
	Multiprotocol Label Switching Architecture (MPLS) Operation and		Multiprotocol Label Switching Architecture (MPLS) Operation and
	Maintenance (OAM) Functions", RFC 3429, November 2002.		Maintenance (OAM) Functions", RFC 3429, November 2002.
	Authors' Addresses		Authors' Addresses
	skipping to change at page 19, line 4		skipping to change at page 19, line 16
	Authors' Addresses		Authors' Addresses
	Matthew Bocci (editor)		Matthew Bocci (editor)
	Alcatel-Lucent		Alcatel-Lucent
	Voyager Place, Shoppenhangers Road		Voyager Place, Shoppenhangers Road
	Maidenhead, Berks SL6 2PJ		Maidenhead, Berks SL6 2PJ
	UK		UK
	Email: matthew.bocci@alcatel-lucent.com		Email: matthew.bocci@alcatel-lucent.com
	Martin Vigoureux (editor)		Martin Vigoureux (editor)
	Alcatel-Lucent		Alcatel-Lucent
	Route de Villejust		Route de Villejust
	Nozay, 91620		Nozay, 91620
	France		France
	Email: martin.vigoureux@alcatel-lucent.com		Email: martin.vigoureux@alcatel-lucent.com
			Stewart Bryant
			Cisco
			Email: stbryant@cisco.com
	George Swallow		George Swallow
	Cisco		Cisco
	Email: swallow@cisco.com		Email: swallow@cisco.com
	David Ward		David Ward
	Cisco		Cisco
	Email: dward@cisco.com		Email: dward@cisco.com
	Stewart Bryant
	Cisco
	Email: stbryant@cisco.com
	Rahul Aggarwal		Rahul Aggarwal
	Juniper Networks		Juniper Networks
	Email: rahul@juniper.net		Email: rahul@juniper.net
End of changes. 17 change blocks.
	34 lines changed or deleted		35 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/