draft-ietf-mpls-tp-gach-gal-00.txt		draft-ietf-mpls-tp-gach-gal-01.txt
	MPLS Working Group M. Vigoureux		MPLS M. Bocci, Ed.
	Internet Draft M. Bocci		Internet-Draft M. Vigoureux, Ed.
	Updates: 3032, 4385 Alcatel-Lucent		Updates: 3032, 4385, 5085 Alcatel-Lucent
	Intended status: Standard Track		(if approved) G. Swallow
	Expires: May 2009 G. Swallow		Intended status: Standards Track D. Ward
	D. Ward		Expires: July 10, 2009 Cisco
	Cisco Systems, Inc.
	R. Aggarwal		R. Aggarwal
	Juniper Networks		Juniper Networks
			January 6, 2009
	November 27, 2008
	MPLS Generic Associated Channel		MPLS Generic Associated Channel
	draft-ietf-mpls-tp-gach-gal-00		draft-ietf-mpls-tp-gach-gal-01
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79.
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that
	groups may also distribute working documents as Internet-Drafts.		other groups may also distribute working documents as Internet-
			Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress".		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 27, 2009.		This Internet-Draft will expire on July 10, 2009.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(http://trustee.ietf.org/license-info) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with respect
			to this document.
	Abstract		Abstract
	This document generalises the applicability of the pseudowire		This document generalises the applicability of the pseudowire
	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 (LSP), MPLS
	pseudowires (PW) and MPLS Sections. In order to identify the presence		pseudowires (PW) and MPLS Sections. In order to identify the
	of this G-ACH, this document also assigns of one of the reserved MPLS		presence of the Generic ACH (G-ACH), this document also assigns of
	label values to the 'Generic Alert Label (GAL)', to be used as a		one of the reserved MPLS label values to the 'Generic Associated
	label based exception mechanism.		channel header Label (GAL)', to be used as a label based exception
			mechanism.
	Conventions used in this document		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [1].		document are to be interpreted as described in RFC 2119 [1].
	Table of Contents		Table of Contents
	1. Introduction................................................3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Contributing Authors....................................4		1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 5
	1.2. Objectives.............................................4		1.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.3. Scope..................................................4		1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.4. Terminology............................................5		1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Generic Associated Channel...................................5		2. Generic Associated Channel Header . . . . . . . . . . . . . . 6
	2.1. Allocation of Channel Types.............................6		2.1. Allocation of Channel Types . . . . . . . . . . . . . . . 7
	3. Generalised Exception Mechanism..............................6		3. Generalised Exception Mechanism . . . . . . . . . . . . . . . 7
	3.1. Relationship with Existing MPLS OAM Alert Mechanisms.....6		3.1. Relationship with Existing MPLS OAM Alert Mechanisms . . . 8
	3.2. GAL Applicability and Usage.............................7		3.2. GAL Applicability and Usage . . . . . . . . . . . . . . . 8
	3.2.1. GAL Processing.....................................7		3.2.1. GAL Processing . . . . . . . . . . . . . . . . . . . . 8
	3.2.1.1. MPLS Section..................................7		3.3. Relationship wth RFC 3429 . . . . . . . . . . . . . . . . 11
	3.2.1.2. Label Switched Paths..........................8		4. Compatability . . . . . . . . . . . . . . . . . . . . . . . . 11
	3.2.1.3. Tandem Connection Monitoring Entity...........9		5. Congestion Considerations . . . . . . . . . . . . . . . . . . 12
	3.3. Relationship with RFC 3429.............................10		6. Security Consderations . . . . . . . . . . . . . . . . . . . . 12
	4. Compatibility..............................................10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	5. Congestion Considerations...................................10		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
	6. Security Considerations.....................................11		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations........................................11		9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	8. Acknowledgments............................................12		9.2. Informative References . . . . . . . . . . . . . . . . . . 14
	9. References.................................................12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References...................................12
	9.2. Informative References.................................13
	Authors' Addresses............................................14
	Contributing Authors' Addresses................................14
	Intellectual Property Statement................................15
	Disclaimer of Validity........................................15
	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 edge-to-edge (i.e. between
	originating and terminating LSRs or T-PEs) and segment fault		originating and terminating LSRs or T-PEs) and segment (e.g. between
	detection (e.g. between any two LSRs or T-PEs/S-PEs along the path of		any two LSRs or T-PEs/S-PEs along the path of a LSP or PW [15]) fault
	an LSP or PW or an MPLS section [17]), diagnostics, maintenance and		detection, diagnostics, maintenance and other functions for a PW and
	other functions for a Pseudowire and an LSP. Some of these functions		a LSP. Some of these functions can be supported using tools such as
	can be supported using tools such as VCCV [8], BFD [9], or LSP-Ping		VCCV [2], BFD [3], or LSP-Ping [4]. However, a requirement has been
	[6]. However, a requirement has been indicated to extend these		indicated to augment the set of maintenance functions, in particular
	toolsets, in particular where MPLS networks are used for packet		where MPLS networks are used for packet transport services and
	transport services and network operations [16]. These include		network operations [16]. Examples include performance monitoring,
	performance monitoring, automatic protection switching, and support		automatic protection switching, and support for management and
	for management and signaling communication channels. These tools must		signaling communication channels. These tools must be applicable to,
	be applicable to, and function in essentially the same manner (from		and function in essentially the same manner (from an operational
	an operational point of view) on both MPLS PWs and MPLS LSPs. They		point of view) on both MPLS PWs and MPLS LSPs. They must also
	must also operate in-band on the PW or LSP such that they do not		operate in-band on the PW or LSP such that they do not depend on PSN
	depend on PSN routing, user data traffic or ultimately on control		routing, user data traffic or ultimately on PSN or other dynamic
	plane functions.		control plane functions.
	Virtual Circuit Connectivity Verification (VCCV) can use an		Virtual Circuit Connectivity Verification (VCCV) can use an
	associated channel to provide a control channel between a PW's		associated channel to provide a control channel between a PW's
	ingress and egress points over which OAM and other control messages		ingress and egress points and over which OAM and other control
	can be exchanged. In this document, we propose a generic associated		messages can be exchanged. In this document, we propose a generic
	channel header (G-ACH) to enable the same control channel mechanism		associated channel header (G-ACH) to enable the same control channel
	be used for MPLS Sections, LSPs and PWs. The associated channel		mechanism be used for MPLS Sections, LSPs and PWs. The associated
	header (ACH) specified in RFC 4385 [11] is used with additional code		channel header (ACH) specified in RFC 4385 [5] is used with
	points to support additional MPLS OAM functions.		additional code points to support additional MPLS maintenance
			functions.
	Generalizing the ACH mechanism to MPLS LSPs and MPLS Sections also		Generalizing the ACH mechanism to MPLS LSPs and MPLS Sections also
	requires a method to identify that a packet contains a G-ACH followed		requires a method to identify that a packet contains a G-ACH followed
	by a non-service payload. This document therefore also defines a		by a non-service payload. This document therefore also defines a
	label based exception mechanism (the Generic Alert Label, or GAL)		label based exception mechanism (the Generic Associated channel
	that serves to inform an LSR that a packet that it receives on an LSP		header Label, or GAL) that serves to inform an LSR that a packet that
	or section belongs to an associated channel.		it receives on an LSP or section belongs to an associated channel.
	RFC 4379 [6] and BFD for MPLS LSPs [9] have defined alert mechanisms		RFC 4379 [4] and BFD for MPLS LSPs [3] have defined alert mechanisms
	that enable a MPLS LSR to identify and process MPLS OAM packets when		that enable a MPLS LSR to identify and process MPLS OAM packets when
	the OAM packets are encapsulated in an IP header. These alert		the OAM packets are encapsulated in an IP header. These alert
	mechanisms are based on TTL expiration and/or use an IP destination		mechanisms are based on TTL expiration and/or use an IP destination
	address in the range 127/8. These mechanisms are the default		address in the range 127/8. These mechanisms are the default
	mechanisms for identifying MPLS OAM packets when the OAM packets are		mechanisms for identifying MPLS OAM packets when the OAM packets are
	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-TP
	[17]) particularly when IP based demultiplexing cannot be used. This		[15]) particularly when IP based demultiplexing cannot be used. This
	document proposes an OPTIONAL mechanism that is RECOMMENDED for		document proposes an OPTIONAL mechanism that is RECOMMENDED for
	identifying and demultiplexing MPLS OAM packets when IP based		identifying and demultiplexing MPLS OAM and other maintenance
	mechanisms such as [6] and [9] are not available.		messages when IP based mechanisms such as those in [4] and [3] are
			not available.
	The G-ACH and GAL mechanisms are defined to work together.		The G-ACH and GAL mechanisms are defined to work together.
	Note that, in this document, OAM functions and packets should be		Note that, in this document, maintenace functions and packets should
	understood in the broad sense, that is, as a set of FCAPS mechanisms		be understood in the broad sense, that is, as a set of FCAPS
	that also include Automatic Protection Switching (APS), Signalling		mechanisms that include OAM, Automatic Protection Switching (APS),
	Control Channel (SCC) and Management Control Channel (MCC).		Signalling Communication Channel (SCC) and Management Communication
			Channel (MCC) messages.
	Note that the GAL and G-ACH are applicable to MPLS in general. Their		Note that the GAL and G-ACH are applicable to MPLS in general. Their
	applicability to specific applications is outside the scope of this		applicability to specific applications is outside the scope of this
	document. For example, the applicability of the GAL and G-ACH to		document. For example, the applicability of the GAL and G-ACH to
	MPLS-TP is described in [17] and [18].		MPLS-TP is described in [15] and [17].
	1.1. Contributing Authors		1.1. Contributing Authors
	The editors gratefully acknowledge the following additional		The editors gratefully acknowledge the contibution of Stewart Bryant,
	contributors: Stewart Bryant, Italo Busi, Marc Lasserre, Lieven		Italo Busi, Marc Lasserre, and Lieven Levrau.
	Levrau, and Lou Berger.
	1.2. Objectives		1.2. Objectives
	This document proposes a mechanism to provide for the extended OAM		This document proposes a mechanism to provide for the extended
	needs of emerging applications for MPLS. It creates a generic OAM		maintenance needs of emerging applications for MPLS. It creates a
	identification mechanism that may be applied to all MPLS LSPs, while		generic control channel identification mechanism that may be applied
	maintaining compatibility with the PW associated channel header (ACH)		to all MPLS LSPs, while maintaining compatibility with the PW
	[11]. It also normalizes the use of the ACH for PWs in a transport		associated channel header (ACH) . It also normalizes the use of the
	context.		ACH for PWs in a transport context.
	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 channel capabilities are signaled
	or negotiated between LSRs or PEs, the operation of various OAM		or negotiated between LSRs or PEs, the operation of various OAM
	functions, or the messages transmitted on the associated channel.		functions, nor how the messages transmitted on the associated
			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		G-ACH: Generic Associated Channel Header
	GAL: Generic Alert Label		GAL: Generic Associated Channel Header Label
			MPLS Section: A network segment between two LSRs that are immediately
			adjacent at the MPLS layer
	2. Generic Associated Channel		Maintenance Packet: Any packet containing a message belonging to a
			maintenace protocol that is carried on a PW, LSP or MPLS Section
			associated channel. Examples of such maintenance protocols include
			OAM functions, signaling communications or management communications.
	VCCV [8] defines three Control Channel Types that may be used to		2. Generic Associated Channel Header
	multiplex OAM messages onto a PW: CC Type 1 uses an associated
	channel header and is referred to as "In-band VCCV"; CC Type 2 uses
	the router alert 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 the targeted routers control plane and is referred to as
	"MPLS PW Label with TTL == 1".
	The use of the CC Type 1, currently limited to MPLS PWs, is extended		VCCV [2] defines three MPLS Control Channel (CC) Types that may be
	to apply to MPLS LSPs as well as to MPLS Sections. This associated		used to multiplex OAM messages onto a PW: CC Type 1 uses an
	channel header is called the Generic Associated Channel Header (G-		associated channel header and is referred to as "In-band VCCV"; CC
	ACH).		Type 2 uses the MPLS Router Alert 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 the targeted router control plane and
			is referred to as "MPLS PW Label with TTL == 1".
			The use of the CC Type 1, currently limited to MPLS PWs, is here
			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 CC Type 1 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| Reserved | Channel Type |		|0 0 0 1|Version|A| Reserved | Channel Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1 : Generic Associated Channel Header		Figure 1 : Generic 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 and		channel associated with a PW, a LSP or a Section. The Version field
	Reserved fields are set to 0, as specified in RFC 4385 [11].		is set to 0, as specified in RFC 4385 [5]. This draft allocates Bit
			8 of the ACH to the ACH TLV bit. This bit is set to 1 to indicate
			that an object defined in the ACH TLV registry immediately follows
			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. These mechanisms need to be extended when a Generalised		between PEs. It is anticipated that similar mechanisms will be
	associated channel is used for e.g. MPLS LSP OAM. This will most		applied to existing MPLS LSPs. Such application will require further
	likely require extensions to label distribution protocols and is		specification. However, such specification is beyond the scope of
	outside the scope of this document.		this document.
	2.1. Allocation of Channel Types		2.1. Allocation of Channel Types
	Values for the Channel Type field, currently used for VCCV, are		The Channel Type field indicates the type of message carried on the
	specified in RFC 4446 [12].		associated channel e.g. IPv4 or IPv6 if IP demultiplexing is used
			for messages on the G-ACH, or OAM or other FCAPS function if IP
			demultiplexing is not used. For G-ACH packets where IP is not used
			as the multiplexer, the Channel Type SHOULD indicate the specific
			maintenance protocol carried in the associated channel.
	The functionality of any additional channel types will be defined in		Values for the Channel Type field currently used for VCCV are
	another document. Each associated channel protocol solution document		specified in RFC 4446 [6]. The functionality of any additional
	must specify the value to use for any additional channel types.		channel types will be defined in another document. Each associated
			channel protocol solution document must specify the value to use for
			any additional channel types.
			Note that these values are allocated from the PW Associated Channel
			Type registry, but this document modifies the existing policy to
			accomodate a level of experimentation. See Section 7 for further
			details.
	3. Generalised Exception Mechanism		3. Generalised Exception Mechanism
	The above mechanism enables the multiplexing of various OAM packets		The above mechanism enables the multiplexing of various maintenace
	onto a PW, LSP or section and provides information on the type of OAM		packets onto a PW, LSP or Section and provides information on the
	function being performed. In the case of a PW, the use of a control		type of function being performed. In the case of a PW, the use of a
	word is negotiated at the time of the PW establishment. However, in		control word is negotiated or configured at the time of the PW
	the case of an MPLS LSP or section, there is a need to notify an LSR		establishment. A special case of the control word (the G-ACH) is
	of the presence of an associated channel packet i.e. LSPs and		used to identify packets belonging to a PW associated channel.
	sections require a mechanism to differentiate specific packets (e.g.
	OAM) from others, such as normal user-plane ones. This document		Generalizing the ACH mechanism to MPLS LSPs and MPLS Sections also
	proposes that a label be used and calls this special label the		requires a method to identify that a packet contains a G-ACH followed
	'Generic Alert Label (GAL)'. One of the reserved label values defined		by a non-service payload. This document specifies that a label be
	in RFC 3032 [3] is assigned for this purpose. The value of the label		used and calls this special label the 'Generic Associated channel
	is to be allocated by IANA; this document suggests the value 13.		header Label (GAL)'. One of the reserved label values defined in RFC
			3032 [7] 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 a generalised exception mechanism to:		The GAL provides a generalised exception mechanism to:
	o Differentiate specific packets (e.g. OAM) from others, such as		o Differentiate specific packets (e.g. those containing OAM
	normal user-plane ones,		messages) from others, such as normal user-plane ones,
	o Indicate that the Generic Associated Channel Header (G-ACH)		o Indicate that the Generic Associated Channel Header (G-ACH)
	appears immediately after the bottom of the label stack.		appears immediately after the bottom of the label stack.
	The 'Generic Alert Label (GAL)' MUST only be used where both of these		The 'Generic Associated channel header Label (GAL)' MUST only be used
	purposes are applicable.		where both of these purposes are applicable.
	3.1. Relationship with Existing MPLS OAM Alert Mechanisms		3.1. Relationship with Existing MPLS OAM Alert Mechanisms
	RFC 4379 [6] and BFD for MPLS LSPs [9] have defined alert mechanisms		RFC 4379 [4] and BFD for MPLS LSPs [3] have defined alert mechanisms
	that enable a MPLS LSR to identify and process MPLS OAM packets when		that enable a MPLS LSR to identify and process MPLS OAM packets when
	the OAM packets are encapsulated in an IP header. These alert		the OAM packets are encapsulated in an IP header. These alert
	mechanisms are based on TTL expiration and/or use an IP destination		mechanisms are based on TTL expiration and/or use an IP destination
	address in the range 127/8.		address in the range 127/8.
	These alert mechanisms SHOULD preferably be used in non MPLS-TP		These alert mechanisms SHOULD preferably be used in non MPLS-TP
	environments. The mechanism defined in this document MAY also be		environments. The mechanism defined in this document MAY also be
	used.		used.
	3.2. GAL Applicability and Usage		3.2. GAL Applicability and Usage
	The 'Generic Alert Label (GAL)' MUST only be used with Label Switched		The 'Generic Associated channel header Label (GAL)' MUST only be used
	Paths (LSPs), with their associated Tandem Connection Monitoring		with Label Switched Paths (LSPs), with their associated Tandem
	Entities (see [18] for definitions of TCMEs) and with MPLS Sections.		Connection Monitoring Entities (see [17] for definitions of TCMEs)
	An MPLS Section is a network segment between two LSRs that are		and with MPLS Sections.
	immediately adjacent at the MPLS layer.
	The GAL applies to both P2P and P2MP LSPs, unless otherwise stated.		The GAL applies to both P2P and P2MP LSPs, unless otherwise stated.
	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 G-ACH MUST be used for PWs when OAM functions that cannot be
	demultiplexed using the IP mechanisms described in section 1. The
	PWE3 control word MUST be present in the encapsulation of user
	packets when the G-ACH is used to demultiplex OAM on a PW.
	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 the		user-plane packets. Furthermore, the GAL MUST only appear once in
	label stack for OAM packets of a given layer.		the label stack for packets on the generic associated channel.
	3.2.1. GAL Processing		3.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 [10].		processing rules specified and referenced in [8].
	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 [4].		the GAL follows the definition and processing rules specified in [9].
	3.2.1.1. MPLS Section		3.2.1.1. MPLS Section
	The following figure (Figure 2) depicts two MPLS LSRs immediately		The following figure (Figure 2) depicts two MPLS LSRs immediately
	adjacent at the MPLS layer.		adjacent at the MPLS layer.
	+---+ +---+		+---+ +---+
	| A |-------------| Z |		| A |-------------| Z |
	+---+ +---+		+---+ +---+
	Figure 2 : MPLS-TP OAM over a MPLS Section		Figure 2: Maintenance over an MPLS Section Associated Channel
	With regards to the MPLS Section, both LERs contain Maintenance End
	Points (see [18] for definitions of MEPs).		With regards to the MPLS Section, both LERs are Maintenance End
			Points (see [17] for definitions of MEPs).
	The following figure (Figure 3) depicts the format of a labelled OAM		The following figure (Figure 3) depicts the format of a labelled OAM
	packet on an associated channel when used for MPLS Section OAM.		packet on an associated channel when used for MPLS Section
			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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| GAL | TC |S| TTL |		| GAL | TC |S| TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Generic-ACH |		| Generic-ACH |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| .		| .
	. MPLS-TP OAM packet .		. Maintenance Message .
	. |		. |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3 : Labelled MPLS-TP OAM packet for MPLS Section OAM		Figure 3: Maintenance Packet Format for MPLS Section
	To send an MPLS-TP OAM packet on an associated channel of the MPLS		To send a MPLS-TP maintenance packet on an associated channel of the
	Section, the head-end LSR (A) of the MPLS Section generates a OAM		MPLS Section, the head-end LSR (A) of the MPLS Section generates a
	packet with a G-ACH to which it pushes a GAL.		maintenance packet with a G-ACH to which it pushes a GAL.
	o The TTL field of the GAL SHOULD be set to 1.		o The TTL field of the GAL SHOULD be set to 1.
	o The S bit of the GAL MUST be set to 1.		o The S bit of the GAL MUST be set to 1 in MPLS-TP.
	The OAM packet, the G-ACH and the GAL SHOULD NOT be modified towards		The maintenance packet, the G-ACH and the GAL SHOULD NOT be modified
	the tail-end LSR (Z). Upon reception of the labelled packet, the		towards the tail-end LSR (Z). Upon reception of the labelled packet,
	tail-end LSR (Z), after having checked the GAL fields, SHOULD pass		the tail-end LSR (Z), after having checked the GAL fields, SHOULD
	the whole packet to the appropriate processing entity.		pass the whole packet to the appropriate processing entity.
	3.2.1.2. Label Switched Paths		3.2.1.2. Label Switched Paths
	The following figure (Figure 4) depicts four LSRs. A LSP is		The following figure (Figure 4) depicts four LSRs. A LSP is
	established from A to D and switched in B and C.		established from A to D and switched in B and C.
	+---+ +---+ +---+ +---+		+---+ +---+ +---+ +---+
	| A |-------------| B |-------------| C |-------------| D |		| A |-------------| B |-------------| C |-------------| D |
	+---+ +---+ +---+ +---+		+---+ +---+ +---+ +---+
	Figure 4 : MPLS-TP OAM over a LSP		Figure 4: Maintenance over an LSP Associated Channel
	LERs A and D contain Maintenance End Points (MEPs) with respect to		LERs A and D are Maintenance End Points (MEPs) with respect to this
	this LSP. Furthermore, LSRs B and C could also contain Maintenance		LSP. Furthermore, LSRs B and C could also be Maintenance
	Intermediate Points (MIPs) (see [18] for definitions of MEPs and		Intermediate Points (MIPs) with respect to this LSP (see [17] for
	MIPs).		definitions of MEPs and MIPs).
	The following figure (Figure 5) depicts the format of a labelled		The following figure (Figure 5) depicts the format of a labelled
	MPLS-TP OAM packet when used for LSP OAM.		maintenance packet when used for a MPLS-TP LSP.
	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 |		| LSP Label | TC |S| TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| GAL | TC |S| TTL |		| GAL | TC |S| TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Generic-ACH |		| Generic-ACH |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| .		| .
	. MPLS-TP OAM packet .		. Maintenance Message .
	. |		. |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5 : Labelled MPLS-TP OAM packet for LSP OAM		Figure 5: Maintenance Packet Format for MPLS-TP LSP
	Note that it is possible that the LSP MAY also be tunnelled in		Note that it is possible that the LSP MAY also be tunnelled in
	another LSP (e.g. if an MPLS Tunnel exists between B and C), and as		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.		such other labels MAY be present above it in the label stack.
	To send an MPLS-TP OAM packet on the LSP, the head-end LSR (A)		To send a maintenance packet on the LSP associated channel, the head-
	generates a MPLS-TP OAM packet with a G-ACH on which it first pushes		end LSR (A) generates a OAM message with a G-ACH on which it first
	a GAL followed by the LSP label.		pushes a GAL followed by the LSP label.
	o The TTL field of the GAL SHOULD be set to 1.		o The TTL field of the GAL SHOULD be set to 1.
	o The S bit of the GAL SHOULD be set to 1, in MPLS-TP.		o The S bit of the GAL SHOULD be set to 1 in MPLS-TP.
	The MPLS-TP OAM packet, the G-ACH or the GAL SHOULD NOT be modified		The maintenance message, the G-ACH or the GAL SHOULD NOT be modified
	towards the targeted destination. Upon reception of the labelled		towards the targeted destination. Upon reception of the labelled
	packet, the targeted destination, after having checked both the LSP		packet, the targeted destination, after having checked both the LSP
	label and GAL fields, SHOULD pass the whole packet to the appropriate		label and GAL fields, SHOULD pass the whole packet to the appropriate
	processing entity.		processing entity.
	3.2.1.3. Tandem Connection Monitoring Entity		3.2.1.3. Tandem Connection Monitoring Entity
	Tandem Connection Monitoring will be specified in a separate		Tandem Connection Monitoring will be specified in a separate
	document.		document.
	3.3. Relationship with RFC 3429		3.3. Relationship wth RFC 3429
	RFC 3429 [15] 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 [3], to the 'OAM Alert Label' that is		values, defined in RFC 3032 [7], 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 therefore describe the assignment of		Both this document and RFC 3429 [18] therefore describe the
	reserved label values for similar purposes. The rationale for the		assignment of reserved label values for similar purposes. The
	assignment of a new reserved label can be summarized as follows:		rationale for the assignment of a new reserved label can be
			summarized as follows:
	o Unlike the mechanisms described and referenced in RFC 3429, MPLS-		o Unlike the mechanisms described and referenced in RFC 3429 [18],
	TP OAM packet payloads will not reside immediately after the GAL		MPLS-TP OAM packet payloads will not reside immediately after the
	but instead behind the G-ACH, which itself resides immediately		GAL but instead behind the G-ACH, which itself resides immediately
	after the bottom of the label stack when the GAL is present. This		after the bottom of the label stack when the GAL is present. This
	ensures that OAM using the generic associated channel complies		ensures that OAM using the generic associated channel complies
	with RFC 4928 [7].		with RFC 4928 [10].
	o The set of OAM functions potentially operated in the context of		o The set of maintenance functions potentially operated in the
	the generic associated channel is wider than the set of OAM		context of the generic associated channel is wider than the set of
	functions referenced in RFC 3429.		OAM functions 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. It is therefore not possible to modify the 'OAM Alert		RFC 3429 [18]. It is therefore not possible to modify the 'OAM
	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. Compatibility		4. Compatability
	An LER, LSR or PE MUST discard received G-ACH packets if it is not G-		An LER, LSR or PE MUST discard received G-ACH packets if it is not G-
	ACH capable, it is not capable of processing packets on the indicated		ACH capable, if it is not capable of processing packets on the
	G-ACH channel, or it has not, through means outside the scope of this		indicated G-ACH channel, or if it has not, through means outside the
	document, indicated to the sending LSR, LER or PE that it will		scope of this document, indicated to the sending LSR, LER or PE that
	process G-ACH packets received on the indicated channel. The LER, LSR		it will process G-ACH packets received on the indicated channel. The
	or PE MAY increment an error counter and MAY also optionally issue a		LER, LSR or PE MAY increment an error counter and MAY also optionally
	system and/or SNMP notification.		issue a system and/or SNMP notification.
	5. Congestion Considerations		5. Congestion Considerations
	The congestion considerations detailed in RFC 5085 [8] apply. Further		The congestion considerations detailed in RFC 5085 [2] apply.
	generic associated channel-specific congestion considerations will be		Further generic associated channel-specific congestion considerations
	detailed in a future revision of this document.		will be detailed in a future revision of this document.
	6. Security Considerations		6. Security Consderations
	The security considerations detailed in RFC 5085 [1], the MPLS		The security considerations detailed in RFC 5085 [2], the MPLS
	architecture [2], the PWE3 architecture [5] and the MPLS-TP framework		architecture [11], the PWE3 architecture [12] and the MPLS-TP
	[17]apply.		framework [15] apply.
	7. IANA Considerations		7. IANA Considerations
	This document requests that IANA allocates a Label value, to the		This document requests that IANA allocates a Label value, to the
	'Generalised-ACH Label (GAL)', from the pool of reserved labels, and		'Generic Associated channel header Label (GAL)', from the pool of
	suggests this value to be 13.		reserved labels, and suggests this value to be 13.
	Channel Types for the Generic Associated Channel are allocated from		Channel Types for the Generic Associated Channel are allocated from
	the IANA PW Associated Channel Type registry [12]. The PW Associated		the IANA PW Associated Channel Type registry [6]. 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 with without
	resorting to the IETF standards process, by supporting experimental		resorting to the IETF standards process, by supporting experimental
	code points [14]. This would prevent code points used for such		code points. This would prevent code points used for such functions
	functions from being used from the range allocated through the IETF		from being used from the range allocated through the IETF standards
	standards and thus protects an installed base of equipment from		and thus protects an installed base of equipment from potential
	potential inadvertent overloading of code points. In order to		inadvertent overloading of code points. In order to support this
	support this requirement, this document requests that the code-point		requirement, this document requests that the code-point allocation
	allocation scheme for the PW Associated Channel Type be changed as		scheme for the PW Associated Channel Type be changed as follows:
	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
	interoperable are configured to use different channel type values.		interoperable are configured to use different channel type values.
	8. Acknowledgments		8. 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		T-MPLS Ad Hoc Group in ITU-T) involved in the definition and
	specification of MPLS Transport Profile.		specification of MPLS Transport Profile.
	9. References		9. References
	9.1. Normative References		9.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
	[2] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label		Levels", BCP 14, RFC 2119, March 1997.
	Switching Architecture", RFC 3031, January 2001
	[3] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032,
	January 2001
	[4] Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in
	Multi-Protocol Label Switching (MPLS) Networks", RFC 3443,
	January 2003
	[5] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge
	[6] Kompella, K., Swallow, G., "Detecting Multi-Protocol Label
	Switched (MPLS) Data Plane Failures", RFC 4379, February 2006
	[7] Swallow, G., Bryant, S., Andersson, L., "Avoiding Equal Cost
	Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, June
	2007
	[8] Nadeau, T., Pignataro, S., "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.
	[9] Aggarwal, R., Kompella, K., Swallow, G., Nadeau, T., "BFD For
	[10] Andersson, L., ""EXP field" renamed to "CoS Field"", draft-
	[11] Bryant, S., et al., "Pseudowire Emulation Edge-to-Edge (PWE3)
	Control Word for Use over an MPLS PSN", RFC 4385, February 2006
	[12] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
	[13] Narten, T., Alvestrand, H., " Guidelines for Writing an IANA
	Considerations Section in RFCs", RFC 2434, October 1998
	[14] Narten, T., "Assigning Experimental and Testing Numbers
	Considered Useful", RFC 3692, January 2004
	9.2. Informative References
	[15] Ohta, H., "Assignment of the 'OAM Alert Label' for		[3] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD
	Multiprotocol Label Switching Architecture (MPLS) Operation and		For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress),
	Maintenance (OAM) Functions", RFC 3429, November 2002		June 2008.
	[16] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in		[4] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label
	MPLS Transport Networks", draft-vigoureux-mpls-tp-oam-		Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
	[17] Bryant, S., Bocci, M., Lasserre, M., "A Framework for MPLS in
	Transport Networks", draft-ietf-mpls-tp-framework-00.txt,
	November 2008
	[18] Busi, I., Niven-Jenkins B., "MPLS-TP OAM Framework and		[5] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
	Overview", draft-busi-mpls-tp-oam-framework-00, October 2008		"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use
			over an MPLS PSN", RFC 4385, February 2006.
	Authors' Addresses		[6] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
			Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
	Martin Vigoureux (Editor)		[7] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci,
	Alcatel-Lucent		D., Li, T., and A. Conta, "MPLS Label Stack Encoding",
			RFC 3032, January 2001.
	Email: martin.vigoureux@alcatel-lucent.com		[8] Andersson, L. and R. Asati, "Multi-Protocol Label Switching
			(MPLS) label stack entry: "EXP" field renamed to "Traffic
			Class" field", draft-ietf-mpls-cosfield-def-08 (work in
			progress), December 2008.
	Matthew Bocci (Editor)		[9] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in
	Alcatel-Lucent		Multi-Protocol Label Switching (MPLS) Networks", RFC 3443,
			January 2003.
	Email: matthew.bocci@alcatel-lucent.com		[10] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost
			Multipath Treatment in MPLS Networks", BCP 128, RFC 4928,
			June 2007.
	David Ward (Editor)		[11] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
	Cisco Systems, Inc.		Switching Architecture", RFC 3031, January 2001.
	Email: dward@cisco.com		[12] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge
			(PWE3) Architecture", RFC 3985, March 2005.
	George Swallow (Editor)		[13] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
	Cisco Systems, Inc.		Considerations Section in RFCs", BCP 26, RFC 2434,
			October 1998.
	Email: swallow@cisco.com		[14] Narten, T., "Assigning Experimental and Testing Numbers
			Considered Useful", BCP 82, RFC 3692, January 2004.
	Rahul Aggarwal (Editor)		9.2. Informative References
	Juniper Networks
	Email: rahul@juniper.net		[15] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in
			Transport Networks", draft-ietf-mpls-tp-framework-00 (work in
			progress), November 2008.
	Contributing Authors' Addresses		[16] Vigoureux, M., Ward, D., and M. Betts, "Requirements for OAM in
			MPLS Transport Networks",
			draft-ietf-mpls-tp-oam-requirements-00 (work in progress),
			December 2008.
	Stewart Bryant		[17] Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM Framework and
	Cisco Systems, Inc.		Overview", draft-busi-mpls-tp-oam-framework-00 (work in
			progress), October 2008.
	Email: stbryant@cisco.com		[18] Ohta, H., "Assignment of the 'OAM Alert Label' for
			Multiprotocol Label Switching Architecture (MPLS) Operation and
			Maintenance (OAM) Functions", RFC 3429, November 2002.
	Italo Busi		Authors' Addresses
	Alcatel-Lucent
	Email: italo.busi@alcatel-lucent.it		Matthew Bocci (editor)
	Marc Lasserre
	Alcatel-Lucent		Alcatel-Lucent
	Email: mlasserre@alcatel-lucent.com		Email: matthew.bocci@alcatel-lucent.com
			Martin Vigoureux (editor)
	Lieven Levrau
	Alcatel-Lucent		Alcatel-Lucent
	Email: llevrau@alcatel-lucent.com		Email: martin.vigoureux@alcatel-lucent.com
	Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.
	Disclaimer of Validity
	This document and the information contained herein are provided on an		George Swallow
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		Cisco
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Email: swallow@cisco.com
	Copyright (C) The IETF Trust (2008).		David Ward
			Cisco
	This document is subject to the rights, licenses and restrictions		Email: dward@cisco.com
	contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.
	Acknowledgment		Rahul Aggarwal
			Juniper Networks
	Funding for the RFC Editor function is currently provided by the		Email: rahul@juniper.net
	Internet Society.
End of changes. 105 change blocks.
	332 lines changed or deleted		310 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/