draft-ietf-mpls-tp-mip-mep-map-00.txt		draft-ietf-mpls-tp-mip-mep-map-01.txt
	Network Working Group A. Farrel		Network Working Group A. Farrel
	Internet-Draft Huawei Technologies		Internet-Draft Juniper Networks
	Intended status: Informational H. Endo		Intended status: Informational H. Endo
	Expires: June 21, 2012 Hitachi, Ltd.		Expires: September 13, 2012 Hitachi, Ltd.
	R. Winter		R. Winter
	NEC		NEC
	Y. Koike		Y. Koike
	NTT		NTT
	M. Paul		M. Paul
	Deutsche Telekom		Deutsche Telekom
	December 19, 2011		March 12, 2012
	Handling MPLS-TP OAM Packets Targeted at Internal MIPs		Handling MPLS-TP OAM Packets Targeted at Internal MIPs
	draft-ietf-mpls-tp-mip-mep-map-00		draft-ietf-mpls-tp-mip-mep-map-01
	Abstract		Abstract
	The Framework for Operations, Administration and Maintenance (OAM)		The Framework for Operations, Administration and Maintenance (OAM)
	within the MPLS Transport Profile (MPLS-TP) describes how Maintenance		within the MPLS Transport Profile (MPLS-TP) describes how Maintenance
	Entity Group Intermediate Points (MIPs) may be situated within		Entity Group Intermediate Points (MIPs) may be situated within
	network nodes at the incoming and outgoing interfaces.		network nodes at the incoming and outgoing interfaces.
	This document describes a way of forming OAM messages so that they		This document describes a way of forming OAM messages so that they
	can be targeted at MIPs on incoming or MIPs on outgoing interfaces,		can be targeted at MIPs on incoming or MIPs on outgoing interfaces,
	forwarded correctly through the "switch fabric", and handled		forwarded correctly through the "switch fabric", and handled
	efficiently in node implementations where there is no distinction		efficiently in node implementations where there is no distinction
	between the incoming and outgoing MIP.		between the incoming and outgoing MIP.
	The material in this document is provided for discussion within the
	MPLS-TP community in the expectation that this idea or some similar
	mechanism will be subsumed into a more general MPLS-TP OAM document.
	This document is a product of a joint Internet Engineering Task Force		This document is a product of a joint Internet Engineering Task Force
	(IETF) / International Telecommunication Union Telecommunication		(IETF) / International Telecommunication Union Telecommunication
	Standardization Sector (ITU-T) effort to include an MPLS Transport		Standardization Sector (ITU-T) effort to include an MPLS Transport
	Profile within the IETF MPLS and PWE3 architectures to support the		Profile within the IETF MPLS and PWE3 architectures to support the
	capabilities and functionalities of a packet transport network.		capabilities and functionalities of a packet transport network.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 2, line 10		skipping to change at page 2, line 6
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on June 21, 2012.		This Internet-Draft will expire on September 13, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 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. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 22		skipping to change at page 3, line 22
	5.1. Rejected Partial Solution . . . . . . . . . . . . . . . . 10		5.1. Rejected Partial Solution . . . . . . . . . . . . . . . . 10
	6. Per-Interface MIP Message Handling . . . . . . . . . . . . . . 11		6. Per-Interface MIP Message Handling . . . . . . . . . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 12		10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	10.2. Informative References . . . . . . . . . . . . . . . . . . 13		10.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Appendix A. Previously considered solutions . . . . . . . . . . . 13		Appendix A. Previously considered solutions . . . . . . . . . . . 13
	A.1. GAL TTL . . . . . . . . . . . . . . . . . . . . . . . . . 13		A.1. GAL TTL . . . . . . . . . . . . . . . . . . . . . . . . . 13
	A.2. A separate channel type for the out-MIP . . . . . . . . . 13		A.2. A separate channel type for the out-MIP . . . . . . . . . 14
	A.3. Decrement TTL once per MIP . . . . . . . . . . . . . . . . 13		A.3. Decrement TTL once per MIP . . . . . . . . . . . . . . . . 14
	A.4. Using an ACH reserved bit . . . . . . . . . . . . . . . . 14		A.4. Using an ACH reserved bit . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	The Framework for Operations, Administration and Maintenance (OAM)		The Framework for Operations, Administration and Maintenance (OAM)
	within the MPLS Transport Profile (MPLS-TP)(the MPLS-TP OAM		within the MPLS Transport Profile (MPLS-TP)(the MPLS-TP OAM
	Framework, [RFC6371]) distinguishes two configurations for		Framework, [RFC6371]) distinguishes two configurations for
	Maintenance Entity Group Intermediate Points (MIPs) on a node. It		Maintenance Entity Group Intermediate Points (MIPs) on a node. It
	defines per-node MIPs and per-interface MIPs, where a per-node MIP is		defines per-node MIPs and per-interface MIPs, where a per-node MIP is
	skipping to change at page 4, line 28		skipping to change at page 4, line 28
	pseudowires (PWs) or Label Switched Paths (LSPs) are delivered using		pseudowires (PWs) or Label Switched Paths (LSPs) are delivered using
	the expiration of the MPLS shim header time-to-live (TTL) field. OAM		the expiration of the MPLS shim header time-to-live (TTL) field. OAM
	messages for the end points of PWs and LSPs are simply delivered as		messages for the end points of PWs and LSPs are simply delivered as
	normal.		normal.
	OAM messages delivered to end points or transit points are		OAM messages delivered to end points or transit points are
	distinguished from other (data) packets so that they can be processed		distinguished from other (data) packets so that they can be processed
	as OAM. In LSPs, the mechanism used is the presence of the Generic		as OAM. In LSPs, the mechanism used is the presence of the Generic
	Associated Channel Label (GAL) in the Label Stack Entry (LSE) under		Associated Channel Label (GAL) in the Label Stack Entry (LSE) under
	the top LSE [RFC5586]. In PWs, the mechanism used is the presence of		the top LSE [RFC5586]. In PWs, the mechanism used is the presence of
	the PW Associated Channel Header (PWACH) [RFC4385].		the PW Associated Channel Header (PWACH) [RFC4385] or the presence of
			a GAL [RFC6423].
	In case multiple MIPs are present on a single node, these mechanisms		In case multiple MIPs are present on a single node, these mechanisms
	alone provide no way to address one particular MIP out of the set of		alone provide no way to address one particular MIP out of the set of
	MIPs.		MIPs.
	This document describes a way of forming OAM messages so that they		This document describes a way of forming OAM messages so that they
	can be targeted at incoming MIPs and outgoing MIPs, forwarded		can be targeted at incoming MIPs and outgoing MIPs, forwarded
	correctly through the "switch fabric", and handled efficiently in		correctly through the "switch fabric", and handled efficiently in
	node implementations where there is no distinction between the		node implementations where there is no distinction between the
	incoming and outgoing MIP.		incoming and outgoing MIP.
	skipping to change at page 5, line 43		skipping to change at page 5, line 43
	------------------------		------------------------
	Figure 1: Abstract Functional Representation of an MPLS-TP Node		Figure 1: Abstract Functional Representation of an MPLS-TP Node
	Several distinct OAM functions are required within this architectural		Several distinct OAM functions are required within this architectural
	model such as:		model such as:
	o CV between a MEP and a MIP		o CV between a MEP and a MIP
	o traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing		o traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing
	MIPs		MIPs
	o OAM control at a MIP
	o data-plane loopback at a MIP		o data-plane loopback at a MIP
	o diagnostic tests		o diagnostic tests
	The MIPs in these OAM functions may equally be the MIPs at the		The MIPs in these OAM functions may equally be the MIPs at the
	incoming or outgoing interfaces.		incoming or outgoing interfaces.
	Per-interface MIPs have the advantage that they enable a more		Per-interface MIPs have the advantage that they enable a more
	accurate localization and identification of faults and targeted		accurate localization and identification of faults and targeted
	performance monitoring or diagnostic test. In particular, the		performance monitoring or diagnostic test. In particular, the
	identification of whether a problem is located between nodes or on a		identification of whether a problem is located between nodes or on a
	skipping to change at page 8, line 13		skipping to change at page 8, line 11
	points of PWs or LSPs are delivered using the expiration of the time-		points of PWs or LSPs are delivered using the expiration of the time-
	to-live (TTL) field in the top LSE of the MPLS packet header. OAM		to-live (TTL) field in the top LSE of the MPLS packet header. OAM
	messages for the end points of PWs and LSPs are simply delivered as		messages for the end points of PWs and LSPs are simply delivered as
	normal.		normal.
	OAM messages delivered to end points or transit points are		OAM messages delivered to end points or transit points are
	distinguished from other (data) packets so that they can be processed		distinguished from other (data) packets so that they can be processed
	as OAM. In LSPs, the mechanism used is the presence of the Generic		as OAM. In LSPs, the mechanism used is the presence of the Generic
	Associated Channel Label (GAL) in the LSE under the top LSE		Associated Channel Label (GAL) in the LSE under the top LSE
	[RFC5586]. In PWs, the mechanism used is the presence of the PW		[RFC5586]. In PWs, the mechanism used is the presence of the PW
	Associated Channel Header [RFC4385].		Associated Channel Header [RFC4385] or the presence of a GAL
			[RFC6423].
	Any solution for sending OAM to the in and out-MIPs must fit within		Any solution for sending OAM to the in and out-MIPs must fit within
	these existing models of handling OAM.		these existing models of handling OAM.
	Additionally, many MPLS-TP nodes contain an optimization such that		Additionally, many MPLS-TP nodes contain an optimization such that
	all queuing and the forwarding function is performed at the incoming		all queuing and the forwarding function is performed at the incoming
	interface. The abstract functional representation of such a node is		interface. The abstract functional representation of such a node is
	shown in Figure 4. As shown in the figure, the outgoing interfaces		shown in Figure 4. As shown in the figure, the outgoing interfaces
	are minimal and for this reason it may not be possible to include MIP		are minimal and for this reason it may not be possible to include MIP
	functions on those interfaces. This is in particular the case for		functions on those interfaces. This is in particular the case for
	skipping to change at page 11, line 22		skipping to change at page 11, line 22
	presented in this section. The appendix of this document contains a		presented in this section. The appendix of this document contains a
	few solutions that the authors have discarded which have been left in		few solutions that the authors have discarded which have been left in
	the document for informational purposes.		the document for informational purposes.
	Per-interface MIP addressing should not require changes to existing		Per-interface MIP addressing should not require changes to existing
	OAM solutions. Therefore, ID information that specific OAM		OAM solutions. Therefore, ID information that specific OAM
	mechanisms already contain should be (re-)used to address the MIPs on		mechanisms already contain should be (re-)used to address the MIPs on
	a node. Upcoming OAM solutions therefore need to individually make		a node. Upcoming OAM solutions therefore need to individually make
	sure that enough of that information is present to support the per-		sure that enough of that information is present to support the per-
	interface model. In particular, the MIP identifiers as described in		interface model. In particular, the MIP identifiers as described in
	[RFC6370] need to be present in OAM messages. [RFC6370] defines a		[RFC6370] or [I-D.ietf-mpls-tp-itu-t-identifiers] need to be present
	format that supports the per-interface model which is sufficient for		in OAM messages. [RFC6370] and [I-D.ietf-mpls-tp-itu-t-identifiers]
	this purpose. In addition, some constraints must be agreed on.		define formats that support the per-interface model which is
			sufficient for this purpose. In addition, some constraints must be
			agreed on.
	Regarding the features we required earlier from a solution this		Regarding the features we required earlier from a solution this
	translates to:		translates to:
	o Feature 1: "Forwarding of OAM packets exactly as data packets"		o Feature 1: "Forwarding of OAM packets exactly as data packets"
	* This way of internal-MIP addressing has no implications on the		* Using existing ID information in OAM messages for internal-MIP
	way data packets and non-local OAM packets are handled as the		addressing has no implications on the way data packets and non-
	label stack is not altered for the purpose of MIP addressing.		local OAM packets are handled as the label stack is not altered
	Also the TTL processing remains untouched. This means that the		for the purpose of MIP addressing. Also the TTL processing
	TTL will expire on the ingress.		remains untouched. This means that the TTL will expire on the
			ingress.
	o Feature 2: "Delivery of OAM messages to the correct MPLS-TP node"		o Feature 2: "Delivery of OAM messages to the correct MPLS-TP node"
	* The node itself is addresses using TTL expiry, comparable to		* The node itself is addresses using TTL expiry, comparable to
	the per-node MIP addressing case.		the per-node MIP addressing case.
	o Feature 3: "Delivery of OAM instructions to the correct MIP within		o Feature 3: "Delivery of OAM instructions to the correct MIP within
	an MPLS-TP node"		an MPLS-TP node"
	* The ID information containted in the OAM packet is used to tell		* The ID information containted in the OAM packet is used to tell
	whether the packet is for the in or out-MIP.		whether the packet is for the in-MIP or the out-MIP.
	o Feature 4: "Packet inspection at the incoming and outgoing		o Feature 4: "Packet inspection at the incoming and outgoing
	interfaces must be minimized"		interfaces must be minimized"
	* Additional packet inspection compared to the per-node case is		* Additional packet inspection compared to the per-node case is
	inevitably needed. The ID information indside the OAM message		inevitably needed. The ID information indside the OAM message
	needs to be considered in order to deliver the packet to the		needs to be considered in order to deliver the packet to the
	right MIP.		correct MIP.
	The above illustrates how in principle per-MIP addressing operates.		The above illustrates how in principle per-MIP addressing operates.
	Another issue of concern was the correct filtering of OAM messages at		Another issue of concern was the correct filtering of OAM messages at
	a downstream node, that were intended for an upstream node's outgoing		a downstream node, that were intended for an upstream node's outgoing
	MIP. Since OAM messages expire on the ingress, the legacy upstream		MIP. Since OAM messages expire on the ingress, the legacy upstream
	neighbor will actually process the packet. Since the ID information		neighbor will actually process the packet. Since the ID information
	is not correct, the node should discard that packet. Leakage should		is not correct, the node should discard that packet. Leakage should
	therefore not occur.		therefore not occur.
	7. Security Considerations		7. Security Considerations
	skipping to change at page 12, line 40		skipping to change at page 12, line 44
	9. Acknowledgments		9. Acknowledgments
	The authors gratefully acknowledge the substantial contributions of		The authors gratefully acknowledge the substantial contributions of
	Zhenlong Cui. We would also like to thank Eric Gray and Sami Boutros		Zhenlong Cui. We would also like to thank Eric Gray and Sami Boutros
	for interesting input to this document through discussions.		for interesting input to this document through discussions.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
			[I-D.ietf-mpls-tp-itu-t-identifiers]
			Winter, R., Gray, E., Helvoort, H., and M. Betts, "MPLS-TP
			Identifiers Following ITU-T Conventions",
			draft-ietf-mpls-tp-itu-t-identifiers-03 (work in
			progress), March 2012.
	[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., Swallow, G., Martini, L., and D. McPherson,		[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
	"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for		"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
	Use over an MPLS PSN", RFC 4385, February 2006.		Use over an MPLS PSN", RFC 4385, February 2006.
	[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic		[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
	Associated Channel", RFC 5586, June 2009.		Associated Channel", RFC 5586, June 2009.
	[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport		[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
	Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.		Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
	[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and		[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
	Maintenance Framework for MPLS-Based Transport Networks",		Maintenance Framework for MPLS-Based Transport Networks",
	RFC 6371, September 2011.		RFC 6371, September 2011.
			[RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the
			Generic Associated Channel Label for Pseudowire in the
			MPLS Transport Profile (MPLS-TP)", RFC 6423,
			November 2011.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-mpls-tp-security-framework]		[I-D.ietf-mpls-tp-security-framework]
	Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP		Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP
	Security Framework",		Security Framework",
	draft-ietf-mpls-tp-security-framework-01 (work in		draft-ietf-mpls-tp-security-framework-01 (work in
	progress), May 2011.		progress), May 2011.
	[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,		[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
	D., and S. Mansfield, "Guidelines for the Use of the "OAM"		D., and S. Mansfield, "Guidelines for the Use of the "OAM"
	skipping to change at page 14, line 23		skipping to change at page 14, line 40
	out-MIP is addressed. An advantage of this approach is that there is		out-MIP is addressed. An advantage of this approach is that there is
	no semantic overlap with anything that exists today, as the bits are		no semantic overlap with anything that exists today, as the bits are
	not in use. Existing implementations need to ignore it. That means		not in use. Existing implementations need to ignore it. That means
	that existing implementations will process the OAM packets at the in-		that existing implementations will process the OAM packets at the in-
	MIP/per-node MIP. ID information is still needed however for the		MIP/per-node MIP. ID information is still needed however for the
	P2MP case as a single bit is not enough.		P2MP case as a single bit is not enough.
	Authors' Addresses		Authors' Addresses
	Adrian Farrel		Adrian Farrel
	Huawei Technologies		Juniper Networks
	Email: adrian.farrel@huawei.com		Email: adrian@olddog.co.uk
	Hideki Endo		Hideki Endo
	Hitachi, Ltd.		Hitachi, Ltd.
	Email: hideki.endo.es@hitachi.com		Email: hideki.endo.es@hitachi.com
	Rolf Winter		Rolf Winter
	NEC		NEC
	Email: rolf.winter@neclab.eu		Email: rolf.winter@neclab.eu
	Yoshinori Koike		Yoshinori Koike
	NTT		NTT
	Email: koike.yoshinori@lab.ntt.co.jp		Email: koike.yoshinori@lab.ntt.co.jp
End of changes. 20 change blocks.
	28 lines changed or deleted		38 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/