draft-ietf-mpls-tp-gach-gal-01.txt		draft-ietf-mpls-tp-gach-gal-02.txt
	MPLS 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) G. Swallow
	Intended status: Standards Track D. Ward		Intended status: Standards Track D. Ward
	Expires: July 10, 2009 Cisco		Expires: August 27, 2009 S. Bryant
			Cisco
	R. Aggarwal		R. Aggarwal
	Juniper Networks		Juniper Networks
	January 6, 2009		February 23, 2009
	MPLS Generic Associated Channel		MPLS Generic Associated Channel header
	draft-ietf-mpls-tp-gach-gal-01		draft-ietf-mpls-tp-gach-gal-02
	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 36		skipping to change at page 1, line 38
	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 July 10, 2009.		This Internet-Draft will expire on August 27, 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document.		to this document.
	Abstract		Abstract
	This document generalises the applicability of the pseudowire		This document generalises the applicability of the pseudowire (PW)
	Associated Channel Header (ACH), enabling the realization of a		Associated Channel Header (ACH), enabling the realization of a
	control channel associated to MPLS Label Switched Paths (LSP), MPLS		control channel associated to MPLS Label Switched Paths (LSPs) and
	pseudowires (PW) and MPLS Sections. In order to identify the		MPLS Sections in addition to MPLS pseudowires. In order to identify
	presence of the Generic ACH (G-ACH), this document also assigns of		the presence of this Associated Channel Header in the label stack,
	one of the reserved MPLS label values to the 'Generic Associated		this document also assigns one of the reserved MPLS label values to
	channel header Label (GAL)', to be used as a label based exception		the Generic Associated channel Label (GAL), to be used as a label
	mechanism.		based exception mechanism.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [1].		document are to be interpreted as described in RFC 2119 [1].
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 5		1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 5
	1.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
	2. Generic Associated Channel Header . . . . . . . . . . . . . . 6		2. Generic Associated Channel Header . . . . . . . . . . . . . . 6
	2.1. Allocation of Channel Types . . . . . . . . . . . . . . . 7		2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Generalised Exception Mechanism . . . . . . . . . . . . . . . 7		2.2. Allocation of Channel Types . . . . . . . . . . . . . . . 7
	3.1. Relationship with Existing MPLS OAM Alert Mechanisms . . . 8		3. ACH TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2. GAL Applicability and Usage . . . . . . . . . . . . . . . 8		3.1. ACH TLV Payload Structure . . . . . . . . . . . . . . . . 8
	3.2.1. GAL Processing . . . . . . . . . . . . . . . . . . . . 8		3.2. ACH TLV Header . . . . . . . . . . . . . . . . . . . . . . 8
	3.3. Relationship wth RFC 3429 . . . . . . . . . . . . . . . . 11		3.3. ACH TLV Object . . . . . . . . . . . . . . . . . . . . . . 9
	4. Compatability . . . . . . . . . . . . . . . . . . . . . . . . 11		4. Generalised Exception Mechanism . . . . . . . . . . . . . . . 9
	5. Congestion Considerations . . . . . . . . . . . . . . . . . . 12		4.1. Relationship with Existing MPLS OAM Alert Mechanisms . . . 10
	6. Security Consderations . . . . . . . . . . . . . . . . . . . . 12		4.2. GAL Applicability and Usage . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		4.2.1. GAL Processing . . . . . . . . . . . . . . . . . . . . 10
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13		4.3. Relationship wth RFC 3429 . . . . . . . . . . . . . . . . 13
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		5. Compatability . . . . . . . . . . . . . . . . . . . . . . . . 13
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 13		6. Congestion Considerations . . . . . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . . 14		7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
			9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
			10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
			10.2. Informative References . . . . . . . . . . . . . . . . . . 17
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	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 edge-to-edge (i.e. between		mechanisms that can be used for fault detection, diagnostics,
	originating and terminating LSRs or T-PEs) and segment (e.g. between		maintenance and other functions on a PW and an LSP. These functions
	any two LSRs or T-PEs/S-PEs along the path of a LSP or PW [15]) fault		can be used between any two Label Edge Routers (LERs) / Label
	detection, diagnostics, maintenance and other functions for a PW and		Switching Router (LSRs) or Terminating Provider Edge routers (T-PEs)
	a LSP. Some of these functions can be supported using tools such as		/ Switching Provider Edge routers (S-PEs) along the path of an LSP or
	VCCV [2], BFD [3], or LSP-Ping [4]. However, a requirement has been		PW respectively [15]. Some of these functions can be supported using
	indicated to augment the set of maintenance functions, in particular		existing tools such as Virtual Circuit Connectivity Verification
	where MPLS networks are used for packet transport services and		(VCCV) [2], Bidirectional Forwarding Detection for MPLS LSPs (BFD-
	network operations [16]. Examples include performance monitoring,		MPLS)[3], LSP-Ping [4], or BFD-VCCV [5]. However, a requirement has
	automatic protection switching, and support for management and		been indicated to augment this set of maintenance functions, in
	signaling communication channels. These tools must be applicable to,		particular when MPLS networks are used for packet transport services
	and function in essentially the same manner (from an operational		and transport network operations [16]. Examples of these functions
	point of view) on both MPLS PWs and MPLS LSPs. They must also		include performance monitoring, automatic protection switching, and
	operate in-band on the PW or LSP such that they do not depend on PSN		support for management and signaling communication channels. These
	routing, user data traffic or ultimately on PSN or other dynamic		tools MUST be applicable to, and function in essentially the same
	control plane functions.		manner (from an operational point of view) on MPLS PWs, MPLS LSPs and
			MPLS Sections. They MUST also operate in-band on the PW or LSP such
			that they do not depend on Packet Switched Network (PSN) routing or
			on user data traffic, and MUST also not depend on dynamic control
			plane functions.
	Virtual Circuit Connectivity Verification (VCCV) can use an		VCCV can use an Associated Channel Header (ACH) to provide a PW-
	associated channel to provide a control channel between a PW's		associated control channel between a PW's end points, over which OAM
	ingress and egress points and over which OAM and other control		and other control messages can be exchanged. This document
	messages can be exchanged. In this document, we propose a generic		generalises the use of the ACH to enable the same associated control
	associated channel header (G-ACH) to enable the same control channel		channel mechanism to be used for Sections, LSPs and PWs. The
	mechanism be used for MPLS Sections, LSPs and PWs. The associated		associated control channel thus generalized is known as the Generic
	channel header (ACH) specified in RFC 4385 [5] is used with		Associated Channel (G-ACh). The ACH, specified in RFC 4385 [6], may
	additional code points to support additional MPLS maintenance		be used with additional code points to support additional MPLS
	functions.		maintenance functions on the G-ACh.
	Generalizing the ACH mechanism to MPLS LSPs and MPLS Sections also		Generalizing the associated control channel mechanism to LSPs and
	requires a method to identify that a packet contains a G-ACH followed		Sections also requires a method to identify that a packet contains an
	by a non-service payload. This document therefore also defines a		ACH followed by a non-service payload. Therefore, this document also
	label based exception mechanism (the Generic Associated channel		defines a label based exception mechanism that serves to inform an
	header Label, or GAL) that serves to inform an LSR that a packet that		LSR (or LER) that a packet it receives on an LSP or Section belongs
	it receives on an LSP or section belongs to an associated channel.		to an associated control channel for that LSP or Section.
	RFC 4379 [4] and BFD for MPLS LSPs [3] have defined alert mechanisms		RFC 4379 [4] and BFD-MPLS [3] define alert mechanisms that enable an
	that enable a MPLS LSR to identify and process MPLS OAM packets when		MPLS LSR to identify and process MPLS OAM packets when these are
	the OAM packets are encapsulated in an IP header. These alert		encapsulated in an IP header. These alert mechanisms are based on
	mechanisms are based on TTL expiration and/or use an IP destination		MPLS or PW label Time to Live (TTL) expiration and/or on the use of
	address in the range 127/8. These mechanisms are the default		an IP destination address in the range 127/8. These mechanisms are
	mechanisms for identifying MPLS OAM packets when the OAM packets are		the default mechanisms for identifying MPLS OAM packets when
	encapsulated in an IP header. However it may not always be possible		encapsulated in an IP header. However it may not always be possible
	to use these mechanisms in some MPLS applications, (e.g. MPLS-TP		to use these mechanisms in some MPLS applications, e.g. MPLS
	[15]) particularly when IP based demultiplexing cannot be used. This		Transport Profile (MPLS-TP) [15], particularly when IP based
	document proposes an OPTIONAL mechanism that is RECOMMENDED for		demultiplexing cannot be used. This document defines a mechanism
	identifying and demultiplexing MPLS OAM and other maintenance		that is RECOMMENDED for identifying and encapsulating MPLS OAM and
	messages when IP based mechanisms such as those in [4] and [3] are		other maintenance messages when IP based mechanisms such as those in
	not available.		[4] and [3] are not available. This mechanism MAY be used in
			addition to IP-based mechanisms.
	The G-ACH and GAL mechanisms are defined to work together.		The GAL mechanism is defined to work together with the ACH for LSPs
			and MPLS Sections.
	Note that, in this document, maintenace functions and packets should		Note that, in this document, maintenance functions and packets should
	be understood in the broad sense, that is, as a set of FCAPS		be understood in the broad sense. That is, a set of maintenance and
	mechanisms that include OAM, Automatic Protection Switching (APS),		management mechanisms that include OAM, Automatic Protection
	Signalling Communication Channel (SCC) and Management Communication		Switching (APS), Signalling Communication Channel (SCC) and
	Channel (MCC) messages.		Management Communication Channel (MCC) messages.
	Note that the GAL and G-ACH are applicable to MPLS in general. Their		Also note that the GAL and ACH are applicable to MPLS in general.
	applicability to specific applications is outside the scope of this		Their applicability to specific applications of MPLS is outside the
	document. For example, the applicability of the GAL and G-ACH to		scope of this document.
	MPLS-TP is described in [15] and [17].
	1.1. Contributing Authors		1.1. Contributing Authors
	The editors gratefully acknowledge the contibution of Stewart Bryant,		The editors gratefully acknowledge the contributions of Sami Boutros,
	Italo Busi, Marc Lasserre, and Lieven Levrau.		Italo Busi, Marc Lasserre, Lieven Levrau and Siva Sivabalan
	1.2. Objectives		1.2. Objectives
	This document proposes a mechanism to provide for the extended		This document defines a mechanism that provides a solution to the
	maintenance needs of emerging applications for MPLS. It creates a		extended maintenance needs of emerging applications for MPLS. It
	generic control channel identification mechanism that may be applied		creates a generic control channel mechanism that may be applied to
	to all MPLS LSPs, while maintaining compatibility with the PW		MPLS LSPs and Sections, while maintaining compatibility with the PW
	associated channel header (ACH) . It also normalizes the use of the		associated channel. It also normalises the use of the ACH for PWs in
	ACH for PWs in a transport context.		a transport context, and defines a label based exception mechanism to
			alert LERs/LSRs of the presence of an ACH after the bottom of the
			stack.
	1.3. Scope		1.3. Scope
	This document defines the encapsulation header for LSP, MPLS Section		This document defines the encapsulation header for LSP, MPLS Section
	and PW associated channel messages.		and PW associated channel messages.
	It does not define how associated channel capabilities are signaled		It does not define how associated control channel capabilities are
	or negotiated between LSRs or PEs, the operation of various OAM		signaled or negotiated between LERs/LSRs or PEs, or the operation of
	functions, nor how the messages transmitted on the associated		various OAM functions.
	channel.
	This document does not deprecate existing MPLS and PW OAM mechanisms.		This document does not deprecate existing MPLS and PW OAM mechanisms.
	1.4. Terminology		1.4. Terminology
	G-ACH: Generic Associated Channel Header		ACH: Associated Channel Header
	GAL: Generic Associated Channel Header Label		G-ACh: Generic Associated Channel
	MPLS Section: A network segment between two LSRs that are immediately
	adjacent at the MPLS layer
	Maintenance Packet: Any packet containing a message belonging to a		GAL: G-ACh Label
	maintenace protocol that is carried on a PW, LSP or MPLS Section
	associated channel. Examples of such maintenance protocols include		Maintenance packet: Any packet containing a message belonging to a
	OAM functions, signaling communications or management communications.		maintenance protocol that is carried on a PW, LSP or MPLS Section
			associated control channel. Examples of such maintenance protocols
			include OAM functions, signaling communications or management
			communications.
			The terms 'Section' and 'Concatenated Segment' are defined in [17].
	2. Generic Associated Channel Header		2. Generic Associated Channel Header
	VCCV [2] defines three MPLS Control Channel (CC) Types that may be		VCCV [2] defines three MPLS Control Channel (CC) Types that may be
	used to multiplex OAM messages onto a PW: CC Type 1 uses an		used to exchange OAM messages through a PW: CC Type 1 uses an ACH and
	associated channel header and is referred to as "In-band VCCV"; CC		is referred to as "In-band VCCV"; CC Type 2 uses the MPLS Router
	Type 2 uses the MPLS Router Alert Label to indicate VCCV packets and		Alert Label to indicate VCCV packets and is referred to as "Out of
	is referred to as "Out of Band VCCV"; CC Type 3 uses the TTL to force		Band VCCV"; CC Type 3 uses the TTL to force the packet to be
	the packet to be processed by the targeted router control plane and		processed by the targeted router control plane and is referred to as
	is referred to as "MPLS PW Label with TTL == 1".		"MPLS PW Label with TTL == 1".
	The use of the CC Type 1, currently limited to MPLS PWs, is here		2.1. Definition
	extended to apply to MPLS LSPs as well as to MPLS Sections. This
	associated channel header is called the Generic Associated Channel
	Header (G- ACH). The PWE3 control word MUST be present in the
	encapsulation of user packets when the G-ACH is used to demultiplex
	the associated channel packet on a PW.
	The CC Type 1 channel header is depicted in figure below:		The use of the CC Type 1, previously limited to PWs, is here extended
			to also apply to LSPs and to Sections. Note that for PWs, the PWE3
			control word [6] MUST be present in the encapsulation of user packets
			when the ACH is used to realize the associated control channel.
			The CC Type 1 control channel header is depicted in figure 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|A| Reserved | Channel Type |		|0 0 0 1|Version| Reserved | Channel Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Generic 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
	channel associated with a PW, a LSP or a Section. The Version field		control channel associated with a PW, an LSP or a Section. The
	is set to 0, as specified in RFC 4385 [5]. This draft allocates Bit		Version field is set to 0, as specified in RFC 4385 [6]. Bits 8 to
	8 of the ACH to the ACH TLV bit. This bit is set to 1 to indicate		14 of the G-ACH are reserved and MUST be set to 0 and ignored on
	that an object defined in the ACH TLV registry immediately follows		reception.
	the G-ACH, otherwise it is set to 0. Bits 8 to 14 of the G-ACH are
	reserved and MUST be set to 0..
	Note that VCCV also includes mechanisms for negotiating the Control		Note that VCCV also includes mechanisms for negotiating the Control
	Channel and Connectivity Verification (i.e. OAM functions) Types		Channel and Connectivity Verification (i.e. OAM functions) Types
	between PEs. It is anticipated that similar mechanisms will be		between PEs. It is anticipated that similar mechanisms will be
	applied to existing MPLS 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.
	2.1. Allocation of Channel Types		2.2. Allocation of Channel Types
	The Channel Type field indicates the type of message carried on the		The Channel Type field indicates the type of message carried on the
	associated channel e.g. IPv4 or IPv6 if IP demultiplexing is used		associated control channel e.g. IPv4 or IPv6 if IP demultiplexing is
	for messages on the G-ACH, or OAM or other FCAPS function if IP		used for messages sent on the associated control channel, or OAM or
	demultiplexing is not used. For G-ACH packets where IP is not used		other maintenance function if IP demultiplexing is not used. For
	as the multiplexer, the Channel Type SHOULD indicate the specific		associated control channel packets where IP is not used as the
	maintenance protocol carried in the associated channel.		multiplexer, the Channel Type SHOULD indicate the specific
			maintenance protocol carried in the associated control channel.
	Values for the Channel Type field currently used for VCCV are		Values for the Channel Type field currently used for VCCV are
	specified in RFC 4446 [6]. The functionality of any additional		specified elsewhere, e.g. in RFC 4446 [7]and RFC 4385[6] .
	channel types will be defined in another document. Each associated		Additional Channel Type values and the associated maintenance
	channel protocol solution document must specify the value to use for		functionality will be defined in other documents. Each document
	any additional channel types.		specifying a protocol solution relying on the ACH MUST also specify
			the applicable Channel Type field value.
	Note that these values are allocated from the PW Associated Channel		Note that these values are allocated from the PW Associated Channel
	Type registry, but this document modifies the existing policy to		Type registry, but this document modifies the existing policy to
	accomodate a level of experimentation. See Section 7 for further		accommodate a level of experimentation. See Section 8 for further
	details.		details.
	3. Generalised Exception Mechanism		3. ACH TLVs
	The above mechanism enables the multiplexing of various maintenace		In some applications of the "In-band VCCV" associated control channel
	packets onto a PW, LSP or Section and provides information on the		it is necessary to include one or more ACH TLVs to provide additional
	type of function being performed. In the case of a PW, the use of a		context information to the maintenance packet. One use of these ACH
	control word is negotiated or configured at the time of the PW		TLVs might be to identify the source and/or intended destination of
	establishment. A special case of the control word (the G-ACH) is		the associated control channel maintenance message. However, the use
	used to identify packets belonging to a PW associated channel.		of this construct is not limited to providing addressing information
			nor is the applicability restricted to transport network
			applications.
	Generalizing the ACH mechanism to MPLS LSPs and MPLS Sections also		If the maintenance message MAY be preceded by one or more ACH TLVs,
	requires a method to identify that a packet contains a G-ACH followed		then this MUST be explicitly specified in the definition of an ACH
	by a non-service payload. This document specifies that a label be		Channel Type. If the ACH Channel Type definition does state that one
	used and calls this special label the 'Generic Associated channel		or more ACH TLVs MAY precede the maintenance message, an ACH TLV
	header Label (GAL)'. One of the reserved label values defined in RFC		Header MUST follow the ACH. If no ACH TLVs are required in a
	3032 [7] is assigned for this purpose. The value of the label is to		specific associated control channel packet, but the Channel Type
	be allocated by IANA; this document suggests the value 13.		nevertheless defines that ACH TLVs MAY be used, an ACH TLV Header
			MUST be present but with a length field set to zero to indicate that
			no ACH TLV follow this header.
	The GAL provides a generalised exception mechanism to:		If a channel type specification does not explicitly specify that ACH
			TLVs MAY be used, then an ACH TLV Header MUST NOT be used.
	o Differentiate specific packets (e.g. those containing OAM		3.1. ACH TLV Payload Structure
	messages) from others, such as normal user-plane ones,
	o Indicate that the Generic Associated Channel Header (G-ACH)		This section defines and describes the structure of an ACH payload
	appears immediately after the bottom of the label stack.		when an ACH TLV Header is present. The structure of ACH TLVs that
			MAY follow an ACH TLV Header is defined and described in the
			following sections.
	The 'Generic Associated channel header Label (GAL)' MUST only be used		The following figure (Figure 2) shows the structure of a G-ACh packet
	where both of these purposes are applicable.		payload.
	3.1. Relationship with Existing MPLS OAM Alert Mechanisms		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| ACH |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| ACH TLV Header |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| ~
			~ zero or more ACH TLVs ~
			~ |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| ~
			~ Maintenance Message ~
			~ |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	RFC 4379 [4] and BFD for MPLS LSPs [3] have defined alert mechanisms		Figure 2: ACH TLV Payload Structure
	that enable a MPLS LSR to identify and process MPLS OAM packets when
	the OAM packets are encapsulated in an IP header. These alert
	mechanisms are based on TTL expiration and/or use an IP destination
	address in the range 127/8.
	These alert mechanisms SHOULD preferably be used in non MPLS-TP		3.2. ACH TLV Header
	environments. The mechanism defined in this document MAY also be
	used.
	3.2. GAL Applicability and Usage		The ACH TLV Header defines the length of the set of ACH TLVs that
			follow.
	The 'Generic Associated channel header Label (GAL)' MUST only be used		0 1 2 3
	with Label Switched Paths (LSPs), with their associated Tandem		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
	Connection Monitoring Entities (see [17] for definitions of TCMEs)		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	and with MPLS Sections.		| Length | Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The GAL applies to both P2P and P2MP LSPs, unless otherwise stated.		Figure 3: ACH TLV Header
			The length field specifies the length in octets of the complete set
			of TLVs including TLVs that follow the ACH TLV header. A length of
			zero indicates that no ACH TLV follow this header.
			The reserved field is for future use and MUST be set to zero on
			transmission and ignored on reception.
			3.3. ACH TLV Object
			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
			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
			value information are defined by the TLV Type as recorded in the TLV
			Type registry. See Section 8 for further details. Note that the
			Value field of ACH TLVs MAY contain sub-TLV objects.
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| TLV Type | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| ~
			~ Value ~
			~ |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 4: ACH TLV Format
			4. Generalised Exception Mechanism
			Generalizing the associated channel mechanism to LSPs and Sections
			also requires a method to identify that a packet contains an ACH
			followed by a non-service payload. This document specifies that a
			label is used for that purpose and calls this special label the G-ACh
			Label (GAL). One of the reserved label values defined in RFC 3032
			[8] is assigned for this purpose. The value of the label is to be
			allocated by IANA; this document suggests the value 13.
			The GAL provides an alert based exception mechanism to:
			o differentiate specific packets (e.g. maintenance messages) from
			others, such as normal user-plane ones,
			o indicate that the ACH appears immediately after the bottom of the
			label stack.
			The GAL MUST only be used where both of these purposes apply.
			4.1. Relationship with Existing MPLS OAM Alert Mechanisms
			RFC 4379 [4] and BFD-MPLS [3] have defined alert mechanisms that
			enable a MPLS LSR to identify and process MPLS OAM packets when the
			OAM packets are encapsulated in an IP header. These alert mechanisms
			are based on TTL expiration and/or use an IP destination address in
			the range 127/8.
			These alert mechanisms SHOULD be used in non MPLS-TP environments,
			although the mechanism defined in this document MAY also be used.
			4.2. GAL Applicability and Usage
			The GAL MUST only be used with LSPs, concatenated segments of LSPs,
			and with Sections.
	In MPLS-TP, the GAL MUST always be at the bottom of the label stack		In MPLS-TP, the GAL MUST always be at the bottom of the label stack
	(i.e. S bit set to 1). However, in other MPLS environments, this		(i.e. S bit set to 1). However, in other MPLS environments, this
	document places no restrictions on where the GAL may appear within		document places no restrictions on where the GAL may appear within
	the label stack.		the label stack.
	The GAL MUST NOT appear in the label stack when transporting normal		The GAL MUST NOT appear in the label stack when transporting normal
	user-plane packets. Furthermore, the GAL MUST only appear once in		user-plane packets. Furthermore, when present, the GAL MUST only
	the label stack for packets on the generic associated channel.		appear once in the label stack.
	3.2.1. GAL Processing		4.2.1. GAL Processing
	The Traffic Class (TC) field (formerly known as the EXP field) of the		The Traffic Class (TC) field (formerly known as the EXP field) of the
	label stack entry containing the GAL follows the definition and		label stack entry containing the GAL follows the definition and
	processing rules specified and referenced in [8].		processing rules specified and referenced in [9].
	The Time-To-Live (TTL) field of the label stack entry that contains		The Time-To-Live (TTL) field of the label stack entry that contains
	the GAL follows the definition and processing rules specified in [9].		the GAL follows the definition and processing rules specified in
			[10].
	3.2.1.1. MPLS Section		4.2.1.1. MPLS Label Switched Paths and Segments
	The following figure (Figure 2) depicts two MPLS LSRs immediately		The following figure (Figure 5) depicts two LERs (A and D) and two
	adjacent at the MPLS layer.		LSRs (B and C) for a given LSP which is established from A to D and
			switched in B and C.
	+---+ +---+		+---+ +---+ +---+ +---+
	| A |-------------| Z |		| A |-------------| B |-------------| C |-------------| D |
	+---+ +---+		+---+ +---+ +---+ +---+
	Figure 2: Maintenance over an MPLS Section Associated Channel		Figure 5: MPLS-TP maintenance over a LSP
	With regards to the MPLS Section, both LERs are Maintenance End		In this example, a G-ACh exists on an LSP that extends between LERs A
	Points (see [17] for definitions of MEPs).		and D, via LSRs B and C. Only these nodes may insert, extract or
			process packets on this G-ACh.
	The following figure (Figure 3) depicts the format of a labelled OAM		The following figure (Figure 6) depicts the format of a MPLS-TP
	packet on an associated channel when used for MPLS Section		maintenance message when used for an LSP.
	maintenance.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| LSP Label | TC |S| TTL |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| GAL | TC |S| TTL |		| GAL | TC |S| TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Generic-ACH |		| ACH |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| .		| ACH TLV Header (if present) |
	. Maintenance Message .		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	. |		| ~
			~ Zero or more ACH TLVs ~
			~ (if present) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| ~
			~ Maintenance Message ~
			~ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Maintenance Packet Format for MPLS Section		Figure 6: MPLS-TP maintenance message format for a LSP
	To send a MPLS-TP maintenance packet on an associated channel of the		Note that it is possible that the LSP may be tunnelled in another LSP
	MPLS Section, the head-end LSR (A) of the MPLS Section generates a		(e.g. if a MPLS Tunnel exists between B and C), and as such other
	maintenance packet with a G-ACH to which it pushes a GAL.		labels may be present in the label stack.
	o The TTL field of the GAL SHOULD be set to 1.		To send a maintenance message on the LSP associated control channel,
			the LER (A) generates a maintenance message, to which it MAY
			prepended an ACH TLV header and appropriate ACH TLVs, and with a ACH
			to which it pushes a GAL and finally the LSP label.
	o The S bit of the GAL MUST be set to 1 in MPLS-TP.		o The TTL field of the GAL MUST be set to at least 1. The exact
			value of the TTL is application specific.
	The maintenance packet, the G-ACH and the GAL SHOULD NOT be modified		o The S bit of the GAL MUST be set according to its position in the
	towards the tail-end LSR (Z). Upon reception of the labelled packet,		label stack.
	the tail-end LSR (Z), after having checked the GAL fields, SHOULD
	pass the whole packet to the appropriate processing entity.
	3.2.1.2. Label Switched Paths		o The setting of the TC field is application specific.
	The following figure (Figure 4) depicts four LSRs. A LSP is		The maintenance message, the ACH or the GAL SHOULD NOT be modified
	established from A to D and switched in B and C.		towards the targeted destination. Upon reception of the labelled
			packet, the targeted destination, after having checked both the LSP
			label and GAL fields, SHOULD pass the whole maintenance message to
			the appropriate processing entity.
	+---+ +---+ +---+ +---+		4.2.1.2. MPLS Section
	| A |-------------| B |-------------| C |-------------| D |
	+---+ +---+ +---+ +---+
	Figure 4: Maintenance over an LSP Associated Channel		The following figure (Figure 7) depicts an example of a MPLS Section.
	LERs A and D are Maintenance End Points (MEPs) with respect to this		+---+ +---+
	LSP. Furthermore, LSRs B and C could also be Maintenance		| A |-------------| Z |
	Intermediate Points (MIPs) with respect to this LSP (see [17] for		+---+ +---+
	definitions of MEPs and MIPs).
	The following figure (Figure 5) depicts the format of a labelled		Figure 7: Maintenance over an MPLS Section
	maintenance packet when used for a MPLS-TP LSP.
			With regard to the MPLS Section, a G-ACh exists between A and Z. Only
			A and Z can insert, extract or process packets on this G-ACh.
			The following figure (Figure 8) depicts the format of a maintenance
			message when used for a MPLS Section. The GAL MAY provide the
			exception mechanism for a control channel in its own right without
			being associated with a specific LSP, thus providing maintenance
			related communications across a specific link interconnecting two
			LSRs. In this case, the GAL is the only label in the stack.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LSP Label | TC |S| TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| GAL | TC |S| TTL |		| GAL | TC |S| TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Generic-ACH |		| ACH |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| .		| ACH TLV Header (if present) |
	. Maintenance Message .		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	. |		| ~
			~ Zero or more ACH TLVs ~
			~ (if present) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| ~
			~ Maintenance Message ~
			~ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5: Maintenance Packet Format for MPLS-TP LSP		Figure 8: Maintenance message format for a MPLS Section
	Note that it is possible that the LSP MAY also be tunnelled in
	another LSP (e.g. if a MPLS Tunnel exists between B and C), and as
	such other labels MAY be present above it in the label stack.
	To send a maintenance packet on the LSP associated channel, the head-
	end LSR (A) generates a OAM message with a G-ACH on which it first
	pushes a GAL followed by the LSP label.
	o The TTL field of the GAL SHOULD be set to 1.		To send a maintenance message on a control channel associated to the
			Section, the head-end LSR (A) of the Section generates a maintenance
			message, to which it MAY prepend an ACH TLV Header and appropriate
			ACH TLVs, and with a ACH to which it pushes a GAL.
	o The S bit of the GAL SHOULD be set to 1 in MPLS-TP.		o The TTL field of the GAL MUST be set to at least 1. The exact
			value of the TTL is application specific.
	The maintenance message, the G-ACH or the GAL SHOULD NOT be modified		o The S bit of the GAL MUST be set according to its position in the
	towards the targeted destination. Upon reception of the labelled		label stack. For MPLS Sections, the S bit MUST be set to 1.
	packet, the targeted destination, after having checked both the LSP
	label and GAL fields, SHOULD pass the whole packet to the appropriate
	processing entity.
	3.2.1.3. Tandem Connection Monitoring Entity		o The setting of the TC field is application specific.
	Tandem Connection Monitoring will be specified in a separate		The maintenance message, the ACH and the GAL SHOULD NOT be modified
	document.		towards the tail-end LSR (Z). Upon reception of the labelled packet,
			the tail-end LSR (Z), after having checked the GAL fields, SHOULD
			pass the whole packet to the appropriate processing entity.
	3.3. Relationship wth RFC 3429		4.3. Relationship wth RFC 3429
	RFC 3429 [18] describes the assignment of one of the reserved label		RFC 3429 [18] describes the assignment of one of the reserved label
	values, defined in RFC 3032 [7], to the 'OAM Alert Label' that is		values, defined in RFC 3032 [8], to the 'OAM Alert Label' that is
	used by user-plane MPLS OAM functions for the identification of MPLS		used by user-plane MPLS OAM functions for the identification of MPLS
	OAM packets. The value of 14 is used for that purpose.		OAM packets. The value of 14 is used for that purpose.
	Both this document and RFC 3429 [18] therefore describe the		Both this document and RFC 3429 [18] therefore describe the
	assignment of reserved label values for similar purposes. The		assignment of reserved label values for similar purposes. The
	rationale for the assignment of a new reserved label can be		rationale for the assignment of a new reserved label can be
	summarized as follows:		summarized as follows:
	o Unlike the mechanisms described and referenced in RFC 3429 [18],		o Unlike the mechanisms described and referenced in RFC 3429 [18],
	MPLS-TP OAM packet payloads will not reside immediately after the		MPLS-TP maintenance messages will not reside immediately after the
	GAL but instead behind the G-ACH, which itself resides immediately		GAL but instead behind the ACH, which itself resides after the
	after the bottom of the label stack when the GAL is present. This		bottom of the label stack. This ensures that OAM, using the
	ensures that OAM using the generic associated channel complies		G-ACh, complies with RFC 4928 [11].
	with RFC 4928 [10].
	o The set of maintenance functions potentially operated in the		o The set of maintenance functions potentially operated in the
	context of the generic associated channel is wider than the set of		context of the G-ACh is wider than the set of OAM functions
	OAM functions referenced in RFC 3429 [18].		referenced in RFC 3429 [18].
	o It has been reported that there are existing implementations and		o It has been reported that there are existing implementations and
	running deployments using the 'OAM Alert Label' as described in		running deployments using the 'OAM Alert Label' as described in
	RFC 3429 [18]. It is therefore not possible to modify the 'OAM		RFC 3429 [18]. It is therefore not possible to modify the 'OAM
	Alert Label' allocation, purpose or usage. Nevertheless, it is		Alert Label' allocation, purpose or usage. Nevertheless, it is
	RECOMMENDED by this document that no further OAM extensions based		RECOMMENDED by this document that no further OAM extensions based
	on 'OAM Alert Label' (Label 14) usage be specified or developed.		on 'OAM Alert Label' (Label 14) usage be specified or developed.
	4. Compatability		5. Compatability
	An LER, LSR or PE MUST discard received G-ACH packets if it is not G-		Procedures for handling a packet received with an invalid incoming
	ACH capable, if it is not capable of processing packets on the		label are specified in RFC 3031[12].
	indicated G-ACH channel, or if it has not, through means outside the
	scope of this document, indicated to the sending LSR, LER or PE that
	it will process G-ACH packets received on the indicated channel. The
	LER, LSR or PE MAY increment an error counter and MAY also optionally
	issue a system and/or SNMP notification.
	5. Congestion Considerations		An LER, LSR or PE MUST discard received associated channel packets on
			which all of the MPLS or PW labels have been popped if any one of the
			following conditions is true:
			o It is not capable of processing packets on the Channel Type
			indicated by the ACH of the received packet.
			o It has not, through means outside the scope of this document,
			indicated to the sending LSR, LER or PE that it will process
			associated channel packets on the Channel Type indicated by the
			ACH of the received packet.
			o If the ACH was indicated by the presence of a GAL, and the first
			nibble of the ACH of the received packet is not 0b0001.
			o The ACH version is not recognised.
			In addition, it MAY increment an error counter and MAY also
			optionally issue a system and/or SNMP notification.
			6. Congestion Considerations
	The congestion considerations detailed in RFC 5085 [2] apply.		The congestion considerations detailed in RFC 5085 [2] apply.
	Further generic associated channel-specific congestion considerations
	will be detailed in a future revision of this document.
	6. Security Consderations		7. Security Considerations
	The security considerations detailed in RFC 5085 [2], the MPLS		The security considerations for the associated control channel are
	architecture [11], the PWE3 architecture [12] and the MPLS-TP		described in RFC 4385[6]. Further security considerations MUST be
	framework [15] apply.		described in the relevant associated channel type specification.
	7. IANA Considerations		RFC 5085 [2] provides data plane related security considerations.
			These also apply to a G-ACh, whether the alert mechanism uses a GAL
			or only an ACH.
	This document requests that IANA allocates a Label value, to the		8. IANA Considerations
	'Generic Associated channel header Label (GAL)', from the pool of
	reserved labels, and suggests this value to be 13.
	Channel Types for the Generic Associated Channel are allocated from		This document requests that IANA allocates a label value, to the GAL,
	the IANA PW Associated Channel Type registry [6]. The PW Associated		from the pool of reserved labels, and suggests this value to be 13.
			Channel Types for the Associated Channel Header are allocated from
			the IANA PW Associated Channel Type registry [7]. The PW Associated
	Channel Type registry is currently allocated based on the IETF		Channel Type registry is currently allocated based on the IETF
	consensus process, described in[13]. This allocation process was		consensus process, described in[13]. This allocation process was
	chosen based on the consensus reached in the PWE3 working group that		chosen based on the consensus reached in the PWE3 working group that
	pseudowire associated channel mechanisms should be reviewed by the		pseudowire associated channel mechanisms should be reviewed by the
	IETF and only those that are consistent with the PWE3 architecture		IETF and only those that are consistent with the PWE3 architecture
	and requirements should be allocated a code point.		and requirements should be allocated a code point.
	However, a requirement has emerged (see [16]) to allow for		However, a requirement has emerged (see [16]) to allow for
	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 with without		running in an associated channel to be experimented without resorting
	resorting to the IETF standards process, by supporting experimental		to the IETF standards process, by supporting experimental code
	code points. This would prevent code points used for such functions		points. This would prevent code points used for such functions from
	from being used from the range allocated through the IETF standards		being used from the range allocated through the IETF standards and
	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 Consensus
	32752 - 32767 : Experimental		32752 - 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 [14]. Experimental OAM functions MUST be		guidelines of RFC 3692 [14]. Experimental OAM functions MUST be
	disabled by default. The channel type value used for a given		disabled by default. The Channel Type value used for a given
	experimental OAM function MUST be configurable, and care MUST be		experimental OAM function MUST be configurable, and care MUST be
	taken to ensure that different OAM functions that are not		taken to ensure that different OAM functions that are not inter-
	interoperable are configured to use different channel type values.		operable are configured to use different Channel Type values.
	8. Acknowledgements		The PW Associated Channel Type registry needs to be updated to
			include a column indicating whether the ACH is followed by a ACH TLV
			header (Yes/No). There are two ACH Channel Type code-points
			currently assigned and in both cases no ACH TLV header is used. Thus
			the new format of the PW Channel Type registry is:
			Registry:
			Value Description TLV Follows Reference
			----- ---------------------------- ----------- ---------
			0x21 ACH carries an IPv4 packet No [RFC4385]
			0x57 ACH carries an IPv6 packet No [RFC4385]
			Figure 9: PW Channel Type registry
			IANA is requested create a new registry called the Associated Channel
			TLV Registry. The allocation policy for this registry is IETF
			consensus. This registry MUST record the following information.
			There are no initial entries.
			Name Type Length Description Reference
			(octets)
			Figure 10: PW ACH TLV registry
			9. Acknowledgements
	The authors would like to thank all members of the teams (the Joint		The authors would like to thank all members of the teams (the Joint
	Working Team, the MPLS Interoperability Design Team in IETF and the		Working Team, the MPLS Interoperability Design Team in IETF and the
	T-MPLS Ad Hoc Group in ITU-T) involved in the definition and		MPLS-TP Ad-Hoc Team in ITU-T) involved in the definition and
	specification of MPLS Transport Profile.		specification of MPLS Transport Profile.
	9. References		10. References
	9.1. Normative References		10.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit		[2] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
	Connectivity Verification (VCCV): A Control Channel for		Connectivity Verification (VCCV): A Control Channel for
	Pseudowires", RFC 5085, December 2007.		Pseudowires", RFC 5085, December 2007.
	[3] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD		[3] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD
	For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress),		For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress),
	June 2008.		June 2008.
	[4] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label		[4] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label
	Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.		Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
	[5] Bryant, S., Swallow, G., Martini, L., and D. McPherson,		[5] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
			Detection (BFD) for the Pseudowire Virtual Circuit
			Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-03
			(work in progress), February 2009.
			[6] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
	"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use		"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use
	over an MPLS PSN", RFC 4385, February 2006.		over an MPLS PSN", RFC 4385, February 2006.
	[6] Martini, L., "IANA Allocations for Pseudowire Edge to Edge		[7] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
	Emulation (PWE3)", BCP 116, RFC 4446, April 2006.		Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
	[7] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci,		[8] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci,
	D., Li, T., and A. Conta, "MPLS Label Stack Encoding",		D., Li, T., and A. Conta, "MPLS Label Stack Encoding",
	RFC 3032, January 2001.		RFC 3032, January 2001.
	[8] Andersson, L. and R. Asati, "Multi-Protocol Label Switching		[9] Andersson, L. and R. Asati, "Multi-Protocol Label Switching
	(MPLS) label stack entry: "EXP" field renamed to "Traffic		(MPLS) label stack entry: "EXP" field renamed to "Traffic
	Class" field", draft-ietf-mpls-cosfield-def-08 (work in		Class" field", draft-ietf-mpls-cosfield-def-08 (work in
	progress), December 2008.		progress), December 2008.
	[9] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in		[10] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in
	Multi-Protocol Label Switching (MPLS) Networks", RFC 3443,		Multi-Protocol Label Switching (MPLS) Networks", RFC 3443,
	January 2003.		January 2003.
	[10] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost		[11] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost
	Multipath Treatment in MPLS Networks", BCP 128, RFC 4928,		Multipath Treatment in MPLS Networks", BCP 128, RFC 4928,
	June 2007.		June 2007.
	[11] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label		[12] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
	Switching Architecture", RFC 3031, January 2001.		Switching Architecture", RFC 3031, January 2001.
	[12] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge
	(PWE3) Architecture", RFC 3985, March 2005.
	[13] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA		[13] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
	Considerations Section in RFCs", BCP 26, RFC 2434,		Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
	October 1998.
	[14] Narten, T., "Assigning Experimental and Testing Numbers		[14] Narten, T., "Assigning Experimental and Testing Numbers
	Considered Useful", BCP 82, RFC 3692, January 2004.		Considered Useful", BCP 82, RFC 3692, January 2004.
	9.2. Informative References		10.2. Informative References
	[15] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in		[15] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in
	Transport Networks", draft-ietf-mpls-tp-framework-00 (work in		Transport Networks", draft-ietf-mpls-tp-framework-00 (work in
	progress), November 2008.		progress), November 2008.
	[16] Vigoureux, M., Ward, D., and M. Betts, "Requirements for OAM in		[16] Vigoureux, M., Ward, D., and M. Betts, "Requirements for OAM in
	MPLS Transport Networks",		MPLS Transport Networks",
	draft-ietf-mpls-tp-oam-requirements-00 (work in progress),		draft-ietf-mpls-tp-oam-requirements-00 (work in progress),
	December 2008.		December 2008.
	[17] Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM Framework and		[17] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and
	Overview", draft-busi-mpls-tp-oam-framework-00 (work in		S. Ueno, "MPLS-TP Requirements",
	progress), October 2008.		draft-ietf-mpls-tp-requirements-04 (work in progress),
			February 2009.
	[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
	Matthew Bocci (editor)		Matthew Bocci (editor)
	Alcatel-Lucent		Alcatel-Lucent
			Voyager Place, Shoppenhangers Road
			Maidenhead, Berks SL6 2PJ
			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
			Nozay, 91620
			France
	Email: martin.vigoureux@alcatel-lucent.com		Email: martin.vigoureux@alcatel-lucent.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. 115 change blocks.
	299 lines changed or deleted		466 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/