draft-ietf-mpls-tp-gach-dcn-06.txt		rfc5718.txt
	Networking Working Group D. Beller
	Internet-Draft Alcatel-Lucent
	Intended Status: Standards Track A. Farrel
	Created: September 19, 2009 Old Dog Consulting
	Expires: March 19, 2010
	An Inband Data Communication Network For the MPLS Transport Profile
	draft-ietf-mpls-tp-gach-dcn-06.txt		Internet Engineering Task Force (IETF) D. Beller
			Request for Comments: 5718 Alcatel-Lucent
	Status of this Memo		Category: Standards Track A. Farrel
			ISSN: 2070-1721 Old Dog Consulting
	This Internet-Draft is submitted to IETF in full conformance with the		January 2010
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		An In-Band Data Communication Network For the MPLS Transport Profile
	http://www.ietf.org/shadow.html.
	Abstract		Abstract
	The Generic Associated Channel (G-ACh) has been defined as a		The Generic Associated Channel (G-ACh) has been defined as a
	generalization of the pseudowire (PW) associated control channel to		generalization of the pseudowire (PW) associated control channel to
	enable the realization of a control/communication channel associated		enable the realization of a control/communication channel that is
	with Multiprotocol Label Switching (MPLS) Label Switched Paths		associated with Multiprotocol Label Switching (MPLS) Label Switched
	(LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between		Paths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between
	adjacent MPLS-capable devices.		adjacent MPLS-capable devices.
	The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS		The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS
	architecture that identifies elements of the MPLS toolkit that may be		architecture that identifies elements of the MPLS toolkit that may be
	combined to build a carrier grade packet transport network based on		combined to build a carrier-grade packet transport network based on
	MPLS packet switching technology.		MPLS packet switching technology.
	This document describes how the G-ACh may be used to provide the		This document describes how the G-ACh may be used to provide the
	infrastructure that forms part of the Management Communication		infrastructure that forms part of the Management Communication
	Network (MCN) and a Signaling Communication Network (SCN).		Network (MCN) and a Signaling Communication Network (SCN).
	Collectively, the MCN and SCN may be referred to as the Data		Collectively, the MCN and SCN may be referred to as the Data
	Communication Network (DCN). This document explains how MCN and SCN		Communication Network (DCN). This document explains how MCN and SCN
	messages are encapsulated, carried on the G-ACh, and demultiplexed		messages are encapsulated, carried on the G-ACh, and demultiplexed
	for delivery to the management or signaling/routing control plane		for delivery to the management or signaling/routing control plane
	components on an MPLS-TP node.		components on an MPLS-TP node.
	It should be noted that the use of the G-ACh to provide connectivity		Status of This Memo
	for the DCN is intended for use only where the MPLS-TP network is not
	capable of encapsulating or delivering native DCN messages.
	Conventions used in this document		This is an Internet Standards Track document.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		This document is a product of the Internet Engineering Task Force
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		(IETF). It represents the consensus of the IETF community. It has
	document are to be interpreted as described in RFC-2119 [RFC2119].		received public review and has been approved for publication by the
			Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 5741.
	1. Introduction		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc5718.
	The associated channel header (ACH) is specified in [RFC4385]. It is		Copyright Notice
			Copyright (c) 2010 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. Code Components extracted from this document must
			include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
			described in the Simplified BSD License.
			1. Introduction
			The associated channel header (ACH) is specified in [RFC4385]. It is
	a packet header format for use on pseudowires (PWs) in order to		a packet header format for use on pseudowires (PWs) in order to
	identify packets used for OAM and similar functions.		identify packets used for Operations, Administration, and Maintenance
			(OAM) and similar functions.
	The use of the ACH is generalized in [RFC5586] and can be applied on		The use of the ACH is generalized in [RFC5586] and can be applied on
	any Multiprotocol Label Switching (MPLS) Label Switching Path (LSP).		any Multiprotocol Label Switching (MPLS) Label Switching Path (LSP).
	This is referred to as the Generic Associated Channel (G-ACh) and is		This is referred to as the Generic Associated Channel (G-ACh) and is
	intended to create a control/management communication channel		intended to create a control/management communication channel
	associated with the LSP that can be used to carry packets used for		associated with the LSP that can be used to carry packets used for
	OAM and similar functions (e.g., control/management plane messages).		OAM and similar functions (e.g., control/management plane messages).
	The purpose of a packet carried on the G-ACh is indicated by the		The purpose of a packet carried on the G-ACh is indicated by the
	value carried by the Channel Type field of the ACH and a registry of		value carried by the Channel Type field of the ACH and a registry of
	values is maintained by IANA ([RFC4446] and [RFC4385]). The		values is maintained by IANA ([RFC4446] and [RFC4385]). The ACH is
	ACH is referred in this document as the G-ACh header.		referred to in this document as the G-ACh header.
	The MPLS transport profile (MPLS-TP) is described in [MPLS-TP] and in		The MPLS transport profile (MPLS-TP) is described in [MPLS-TP] and in
	[TP-REQ]. MPLS-TP is the application of MPLS to construct a packet		[RFC5654]. MPLS-TP is the application of MPLS to construct a packet
	transport network. It constitutes a profile of MPLS that enables		transport network. It constitutes a profile of MPLS that enables
	operational models typical in transport networks, which includes		operational models typical in transport networks, which includes
	additional OAM, survivability and other maintenance functions not		additional OAM, survivability, and other maintenance functions not
	previously supported by MPLS.		previously supported by MPLS.
	Label Switching Routers (LSRs) in MPLS networks may be operated using		Label Switching Routers (LSRs) in MPLS networks may be operated using
	management protocols or control plane protocols. Messaging in these		management protocols or control plane protocols. Messaging in these
	protocols is normally achieved using IP packets exchanged over IP-		protocols is normally achieved using IP packets exchanged over IP-
	capable interfaces. However, some nodes in MPLS-TP networks may be		capable interfaces. However, some nodes in MPLS-TP networks may be
	constructed without support for direct IP encapsulation on their		constructed without support for direct IP encapsulation on their
	line-side interfaces, and without access to an out-of-fiber data		line-side interfaces and without access to an out-of-fiber data
	communication network. In order that such nodes can communicate using		communication network. In order that such nodes can communicate
	management plane or control plane protocols, channels must be		using management plane or control plane protocols, channels must be
	provided, and the only available mechanism is to use an MPLS label.		provided, and the only available mechanism is to use an MPLS label.
	The G-ACh provides a suitable mechanism for this purpose, and this		The G-ACh provides a suitable mechanism for this purpose, and this
	document defines processes and procedures to allow the G-ACh to be		document defines processes and procedures to allow the G-ACh to be
	used to build a management communication network (MCN) and a		used to build a Management Communication Network (MCN) and a
	signaling communication network (SCN) together known as the data		Signaling Communication Network (SCN), together known as the Data
	communication network (DCN) [G.7712].		Communication Network (DCN) [G.7712].
	1.1. Requirements		It should be noted that the use of the G-ACh to provide connectivity
			for the DCN is intended for use only where the MPLS-TP network is not
			capable of encapsulating or delivering native DCN messages.
			1.1. Requirements
	The requirements presented in this section are based on those		The requirements presented in this section are based on those
	communicated to the IETF by the ITU-T.		communicated to the IETF by the ITU-T.
	1. A packet encapsulation mechanism must be provided to support the		1. A packet-encapsulation mechanism must be provided to support the
	transport of MCN and SCN packets over the G-ACh.		transport of MCN and SCN packets over the G-ACh.
	2. The G-ACh carrying the MCN and SCN packets shall support the		2. The G-ACh carrying the MCN and SCN packets shall support the
	following application scenarios:		following application scenarios:
	a. The G-ACh interconnects two adjacent MPLS-TP nodes (used when		a. The G-ACh interconnects two adjacent MPLS-TP nodes (used when
	the server layer does not provide a Management Communication		the server layer does not provide a Management Communication
	Channel (MCC) or a Signalling Communication Channel (SCC)).		Channel (MCC) or a Signalling Communication Channel (SCC)).
	b. The G-ACh is carried by an MPLS-TP tunnel that traverses		b. The G-ACh is carried by an MPLS-TP tunnel that traverses
	another operator's domain (carrier's carrier scenario)		another operator's domain (the carrier's carrier scenario).
	3. The G-ACh shall provide two independent channels: an MCC to build		3. The G-ACh shall provide two independent channels: an MCC to build
	the MCN and an SCC to build the SCN. The G-ACh packet header shall		the MCN and an SCC to build the SCN. The G-ACh packet header
	indicate whether the packet is an MCC or an SCC packet in order to		shall indicate whether the packet is an MCC or an SCC packet in
	forward it to the management or control plane application for		order to forward it to the management or control plane application
	processing. This facilitates easy demultiplexing of control and		for processing. This facilitates easy demultiplexing of control
	management traffic from the DCN and enables separate or		and management traffic from the DCN, and enables separate or
	overlapping address spaces and duplicate protocol instances in the		overlapping address spaces and duplicate protocol instances in the
	management and control planes.		management and control planes.
	4. The channel separation mechanism shall not preclude the use of		4. The channel-separation mechanism shall not preclude the use of
	separate rate limiters and traffic shaping functions for each		separate rate limiters and traffic-shaping functions for each
	channel (MCC and SCC) ensuring that the flows do not exceed their		channel (MCC and SCC), ensuring that the flows do not exceed their
	assigned traffic profiles. The rate limiters and traffic shapers		assigned traffic profiles. The rate limiters and traffic shapers
	are outside the scope of the MCC and SCC definitions.		are outside the scope of the MCC and SCC definitions.
	5. The G-ACh that carries the MCC and SCC shall be capable of		5. The G-ACh that carries the MCC and SCC shall be capable of
	carrying different OSI layer 3 (network layer) PDUs. These shall		carrying different OSI layer 3 (network layer) PDUs. These shall
	include IPv4, IPv6, and OSI PDUs. The G-ACh header of the MCC/SCC		include IPv4, IPv6, and OSI PDUs. The G-ACh header of the MCC/SCC
	packet shall indicate which layer 3 PDU is contained in the		packet shall indicate which layer 3 PDU is contained in the
	payload field of the packet such that the packet can be delivered		payload field of the packet such that the packet can be delivered
	to the related layer 3 process within the management and control		to the related layer 3 process within the management and control
	plane application, respectively, for further processing.		plane application, respectively, for further processing.
	6. The G-ACh is not required to provide specific security mechanisms.		6. The G-ACh is not required to provide specific security mechanisms.
	However, the management or control plane protocols that operate		However, the management or control plane protocols that operate
	over the MCC or SCC are required to provide adequate security		over the MCC or SCC are required to provide adequate security
	mechanisms in order not to be susceptible to security attacks.		mechanisms in order to not be susceptible to security attacks.
	2. Procedures		1.2. Conventions Used in This Document
	Figure 1 depicts the format of an MCC/SCC packet that is sent on the		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
	G-ACh. The Channel Type field indicates the function of the ACH		NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
	message so, to send an MCC/SCC packet on the G-ACh, the MCC/SCC		in this document are to be interpreted as described in RFC-2119
	message is prepended with an ACH with the Channel Type set to		[RFC2119].
	indicate that the message is an MCC or SCC message. The ACH MUST NOT
	include the ACH TLV Header [RFC5586] meaning that no ACH TLVs can be
	included in the message. A two byte Protocol Identifier (PID) field
	indicates the protocol type of the payload DCN message.
	0 1 2 3		2. Procedures
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| PID | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| MCC/SCC Message |
	~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: G-ACh MCC/SCC Packet		Figure 1 depicts the format of an MCC/SCC packet that is sent on
			the G-ACh. The Channel Type field indicates the function of the
			ACH message and so, to send an MCC/SCC packet on the G-ACh, the
			MCC/SCC message is prepended with an ACH with the Channel Type set
			to indicate that the message is an MCC or SCC message. The ACH
			MUST NOT include the ACH TLV Header [RFC5586], meaning that no ACH
			TLVs can be included in the message. A two-byte Protocol
			Identifier (PID) field indicates the protocol type of the payload
			DCN message.
			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 0 0 1|Version| Reserved | Channel Type |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| PID | |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
			| MCC/SCC Message |
			~ ~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 1: G-ACh MCC/SCC Packet
	o The Channel Type field determines whether the message is an MCC or		o The Channel Type field determines whether the message is an MCC or
	an SCC message. See Section 5 for the codepoint assignments.		an SCC message. See Section 5 for the codepoint assignments.
	o The presence of the PID field is deduced from the Channel Type		o The presence of the PID field is deduced from the Channel Type
	value indicating MCC or SCC. The field contains an identifier of		value indicating MCC or SCC. The field contains an identifier of
	the payload protocol using the PPP protocol identifiers [RFC1661],		the payload protocol using the PPP protocol identifiers ([RFC1661],
	[RFC3818].		[RFC3818]).
	When the G-ACh sender receives an MCC message that is to be sent over		When the G-ACh sender receives an MCC message that is to be sent over
	the MCC, the sender creates the G-ACh header, sets the Channel		the MCC, the sender creates the G-ACh header, sets the Channel Type
	Type field to MCC, fills in the PID to indicate the MCC layer 3 PDU		field to MCC, fills in the PID to indicate the MCC layer 3 PDU type,
	type,and prepends the MCC message with the G-ACh header. The same		and prepends the MCC message with the G-ACh header. The same
	procedure is applied when a control plane message is to be sent over		procedure is applied when a control plane message is to be sent over
	the SCC. In this case, the sender sets the Channel Type field to SCC.		the SCC. In this case, the sender sets the Channel Type field to
			SCC.
	If the G-ACh is associated with an MPLS section, the GAL is added to		If the G-ACh is associated with an MPLS section, the Generic
	the message as defined in [RFC5586]. The TTL field MUST be set to 1,		Associated Channel Label (GAL) is added to the message as defined in
	and the S-bit of the GAL MUST be set to 1.		[RFC5586]. The Time to Live (TTL) field MUST be set to 1, and the
			S-bit of the GAL MUST be set to 1.
	If the G-ACh is associated with an LSP, the GAL is added to the		If the G-ACh is associated with an LSP, the GAL is added to the
	packet and the LSP label is pushed on top of the GAL as defined in		packet and the LSP label is pushed on top of the GAL as defined in
	[RFC5586]. The TTL field of the GAL MUST be set to 1, and the S-bit		[RFC5586]. The TTL field of the GAL MUST be set to 1, and the S-bit
	of the GAL MUST be set to 1.		of the GAL MUST be set to 1.
	Note that packet processing for DCN packets in the G-ACh is, in		Note that packet processing for DCN packets in the G-ACh is, in
	common with all G-ACh MPLS packets, subject to the normal processing		common with all G-ACh MPLS packets, subject to the normal processing
	of the Traffic Class (TC) field of the MPLS header. This could be		of the Traffic Class (TC) field of the MPLS header. This could be
	used to enable prioritisation of different DCN packets.		used to enable prioritization of different DCN packets.
	The DCN channel MUST NOT be used to transport user traffic and SHALL		The DCN channel MUST NOT be used to transport user traffic and SHALL
	only be used to carry management or control plane messages.		only be used to carry management or control plane messages.
	Procedures that ensure this (such as deep packet inspection) are		Procedures that ensure this (such as deep packet inspection) are
	outside the scope of this specification.		outside the scope of this specification.
	When a receiver has received a packet on the G-ACh with the ACH		When a receiver has received a packet on the G-ACh with the ACH
	Channel Type set to MCC or SCC, it SHALL look at the PID field. If		Channel Type set to MCC or SCC, it SHALL look at the PID field. If
	the PID value is known by the receiver it delivers the the MCC/SCC		the PID value is known by the receiver, it delivers the MCC/SCC
	message to the appropriate processing entity. If the PID value is		message to the appropriate processing entity. If the PID value is
	unknown, the receiver SHALL silently discard the received packet,		unknown, the receiver SHALL silently discard the received packet, MAY
	MAY increment a counter that records discarded or errored messages,		increment a counter that records discarded or errored messages, and
	and MAY log an event.		MAY log an event.
	It must be noted that according to [RFC5586] a receiver MUST NOT		It must be noted that according to [RFC5586], a receiver MUST NOT
	forward a GAL packet based on the GAL label as is normally the case		forward a GAL packet based on the GAL label as is normally the case
	for MPLS packets. If the GAL appears at the bottom of the label		for MPLS packets. If the GAL appears at the bottom of the label
	stack, it MUST be processed as described in the previous paragraph.		stack, it MUST be processed as described in the previous paragraph.
	Note that there is no requirement for MPLS-TP devices to support IP		Note that there is no requirement for MPLS-TP devices to support IP
	or OSI forwarding in the fast (forwarding) path. Thus, if a message		or OSI forwarding in the fast (forwarding) path. Thus, if a message
	is received on the MCC or SCC and is not targeted to an address of		is received on the MCC or SCC and is not targeted to an address of
	the receiving MPLS-TP node the packet might not be forwarded in the		the receiving MPLS-TP node, the packet might not be forwarded in the
	fast path. A node MAY apply layer 3 forwarding procedures in the slow		fast path. A node MAY apply layer 3 forwarding procedures in the
	or fast path and MAY discard or reject the message using the layer 3		slow or fast path and MAY discard or reject the message using the
	protocol if it is unable to forward it. Thus, protocols making use of		layer 3 protocol if it is unable to forward it. Thus, protocols
	the DCN should make no assumptions about the forwarding capabilities		making use of the DCN should make no assumptions about the forwarding
	unless they are determined a priori or through the use of a routing		capabilities unless they are determined a priori or through the use
	protocol. Furthermore it is important that user data (i.e., data		of a routing protocol. Furthermore, it is important that user data
	traffic) is not routed through the DCN as this would potentially		(i.e., data traffic) is not routed through the DCN, as this would
	cause the traffic to be lost or delayed, and might significantly		potentially cause the traffic to be lost or delayed and might
	congest the DCN.		significantly congest the DCN.
	2.1. Pseudowire Setup		2.1. Pseudowire Setup
	Provider Edge nodes may wish to set up PWs using a signaling protocol		Provider Edge nodes (PEs) may wish to set up PWs using a signaling
	that uses remote adjacencies (such as LDP [RFC5036]). In the absence		protocol that uses remote adjacencies (such as LDP [RFC5036]). In
	of an IP-based control plane network, these PEs MUST first set up an		the absence of an IP-based control plane network, these PEs MUST
	LSP tunnel across the MPLS-TP network. This tunnel can be used both		first set up an LSP tunnel across the MPLS-TP network. This tunnel
	to carry the PW once it has been set up and to provide a G-ACh based		can be used both to carry the PW once it has been set up and to
	DCN for control plane communications between the PEs.		provide a G-ACh-based DCN for control plane communications between
			the PEs.
	3. Applicability		3. Applicability
	The DCN is intended to provide connectivity between management		The DCN is intended to provide connectivity between management
	stations and network nodes, and between pairs of network nodes, for		stations and network nodes, and between pairs of network nodes, for
	the purpose of exchanging management plane and control plane		the purpose of exchanging management plane and control plane
	messages.		messages.
	Appendix A of [NM-REQ] describes how Control Channels (CCh) that are		Appendix A of [NM-REQ] describes how Control Channels (CCh) that are
	the links in an MPLS-TP DCN can be out-of-fiber and out-of-band, in-		the links in an MPLS-TP DCN can be out-of-fiber and out-of-band, in-
	fiber and out-of-band, or in-band with respect to the user data		fiber and out-of-band, or in-band with respect to the user data
	carried by the MPLS-TP network. The Appendix also explains how the		carried by the MPLS-TP network. That appendix also explains how the
	DCN can be constructed from a mix of different types of links and		DCN can be constructed from a mix of different types of links and how
	how routing and forwarding can be used within the DCN to facilitate		routing and forwarding can be used within the DCN to facilitate
	multi-hop delivery of management and control plane messages.		multi-hop delivery of management and control plane messages.
	The G-ACh used as described in this document allows the creation of		The G-ACh used as described in this document allows the creation of a
	a "data channel associated CCh" (type 6 in Appendix A of [NM-REQ])		"data channel associated CCh" (type 6 in Appendix A of [NM-REQ]) and
	and an "in-band CCh" (type 7 in Appendix A of [NM-REQ]). In the		an "in-band CCh" (type 7 in Appendix A of [NM-REQ]). In the former
	former case, the G-ACh is associated with an MPLS-TP section. In the		case, the G-ACh is associated with an MPLS-TP section. In the latter
	latter case, the G-ACh is associated with an MPLS-TP LSP or PW and		case, the G-ACh is associated with an MPLS-TP LSP or PW and may span
	may span one or more hops in the MPLS-TP network.		one or more hops in the MPLS-TP network.
	There is no need to create a CCh for every LSP between a pair of		There is no need to create a CCh for every LSP between a pair of
	Indeed, where the nodes are physically adjacent, the G-ACh associated		MPLS-TP nodes. Indeed, where the nodes are physically adjacent, the
	with the MPLS-TP section would normally be used. Where nodes are		G-ACh associated with the MPLS-TP section would normally be used.
	virtually adjacent (that is, connected by LSP tunnels), one or two of		Where nodes are virtually adjacent (that is, connected by LSP
	the LSPs might be selected to provide the CCh and a back-up CCh.		tunnels), one or two of the LSPs might be selected to provide the CCh
			and a back-up CCh.
	4. Security Considerations		4. Security Considerations
	The G-ACh provides a virtual link between MPLS-TP nodes and might be		The G-ACh provides a virtual link between MPLS-TP nodes and might be
	used to induce many forms of security attack. Protocols that operate		used to induce many forms of security attack. The MPLS data plane
	over the MCN or SCN are REQUIRED to include adequate security		does not include any security mechanisms of its own; therefore, it is
	mechanisms and implementations MUST allow operators to configure the		important that protocols using the DCN apply their own security.
	use of those mechanisms.		Protocols that operate over the MCN or SCN are REQUIRED to include
			adequate security mechanisms, and implementations MUST allow
			operators to configure the use of those mechanisms.
	5. IANA Considerations		5. IANA Considerations
	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 defined in [RFC4446] and		the IANA PW Associated Channel Type registry defined in [RFC4446] and
	updated by [RFC5586].		updated by [RFC5586].
	IANA is requested to allocate two further Channel Types as follows:		IANA has allocated two further Channel Types as follows:
	xx Management Communication Channel (MCC)		0x0001 Management Communication Channel (MCC)
	yy Signaling Communication Channel (SCC)		0x0002 Signaling Communication Channel (SCC)
	6. Normative References		6. References
			6.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4385] Bryant, S., et al., "Pseudowire Emulation Edge-to-Edge		[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
	(PWE3) Control Word for Use over an MPLS PSN", RFC 4385,		"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
	February 2006.		Use over an MPLS PSN", RFC 4385, February 2006.
	[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge		[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
	Emulation (PWE3)", RFC 4446, April 2006 .		Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
	[RFC5586] Bocci, M., Vigoureux, M., and Bryant, S., "MPLS Generic
	Associated Channel", RFC 5586, June 2009.
	7. Informative References
	[MPLS-TP] Bryant, S., Bocci, M., Lasserre, M., "A Framework for MPLS
	in Transport Networks", draft-ietf-mpls-tp-framework, work
	in progress.
	[TP-REQ] B. Niven-Jenkins, Ed., D. Brungard, Ed., M. Betts, Ed.,		[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
	N. Sprecher, S. Ueno, "MPLS-TP Requirements",		"MPLS Generic Associated Channel", RFC 5586, June 2009.
	draft-ietf-mpls-tp-requirements, work in progress.
	[NM-REQ] Lam, H.-K., Mansfield, S., and Gray, E., "MPLS TP Network		6.2. Informative References
	Management Requirements", draft-ietf-mpls-tp-nm-req, work
	in progress.
	[G.7712] ITU-T Recommendation G.7712, "Architecture and		[G.7712] ITU-T Recommendation G.7712, "Architecture and
	specification of data communication network", June 2008.		specification of data communication network", June 2008.
	[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,		[MPLS-TP] Bocci, M., Bryant, S., Frost, D., and L. Levrau, "A
	RFC 1661, July 1994.		Framework for MPLS in Transport Networks", Work in
			Progress, October 2009.
			[NM-REQ] Lam, K. and S. Mansfield, "MPLS TP Network Management
			Requirements", Work in Progress, October 2009.
			[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD
			51, RFC 1661, July 1994.
	[RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point		[RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point
	Protocol (PPP)", BCP 88, RFC 3818, June 2004.		Protocol (PPP)", BCP 88, RFC 3818, June 2004.
	[RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP		[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
	Specification", RFC 5036, October 2007.		"LDP Specification", RFC 5036, October 2007.
	8. Acknowledgements		[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
			Sprecher, N., and S. Ueno, "Requirements of an MPLS
			Transport Profile", RFC 5654, September 2009.
			7. Acknowledgements
	The editors wish to thank Pietro Grandi, Martin Vigoureux, Kam Lam,		The editors wish to thank Pietro Grandi, Martin Vigoureux, Kam Lam,
	Ben Niven-Jenkins, Francesco Fondelli, Walter Rothkegel, Shahram		Ben Niven-Jenkins, Francesco Fondelli, Walter Rothkegel, Shahram
	Davari, Liu Guoman, and Alexander Vainshtein for their contribution		Davari, Liu Guoman, and Alexander Vainshtein for their contribution
	to this document, and the MEAD team for thorough review.		to this document, and the MEAD team for thorough review.
	Study Group 15 of the ITU-T provided the basis for the requirements		Study Group 15 of the ITU-T provided the basis for the requirements
	text in Section 1.1.		text in Section 1.1.
	9. Authors' Addresses		Authors' Addresses
	Dieter Beller		Dieter Beller
	Alcatel-Lucent Germany		Alcatel-Lucent Germany
	EMail: dieter.beller@alcatel-lucent.com		EMail: dieter.beller@alcatel-lucent.com
	Adrian Farrel		Adrian Farrel
	Old Dog Consulting		Old Dog Consulting
	EMail: adrian@olddog.co.uk		EMail: adrian@olddog.co.uk
	Full Copyright Statement
	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 in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.
End of changes. 62 change blocks.
	180 lines changed or deleted		197 lines changed or added
This html diff was produced by rfcdiff 1.37b. The latest version is available from http://tools.ietf.org/tools/rfcdiff/