draft-ietf-mpls-tp-mip-mep-map-07.txt		rfc7054.txt
	Network Working Group A. Farrel		Internet Engineering Task Force (IETF) A. Farrel
	Internet-Draft Juniper Networks		Request for Comments: 7054 Juniper Networks
	Intended status: Informational H. Endo		Category: Informational H. Endo
	Expires: October 24, 2013 Hitachi, Ltd.		ISSN: 2070-1721 Hitachi, Ltd.
	R. Winter		R. Winter
	NEC		NEC
	Y. Koike		Y. Koike
	NTT		NTT
	M. Paul		M. Paul
	Deutsche Telekom		Deutsche Telekom
	April 22, 2013		November 2013
	Per-Interface MIP Addressing Requirements and Design Considerations		Addressing Requirements and Design Considerations for
	draft-ietf-mpls-tp-mip-mep-map-07		Per-Interface Maintenance Entity Group Intermediate Points (MIPs)
	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 the
	Entity Group Intermediate Points (MIPs) may be situated within		Maintenance Entity Group Intermediate Points (MIPs) may be situated
	network nodes at the incoming and outgoing interfaces.		within network nodes at incoming and outgoing interfaces.
	This document elaborates on important considerations for internal MIP		This document elaborates on important considerations for internal MIP
	addressing. More precisely it describes important restrictions for		addressing. More precisely, it describes important restrictions for
	any mechanism that specifies a way of forming OAM messages so that		any mechanism that specifies a way of forming OAM messages so that
	they can be targeted at MIPs on incoming or MIPs on outgoing		they can be targeted at MIPs on either incoming or outgoing
	interfaces and forwarded correctly through the forwarding engine.		interfaces and forwarded correctly through the forwarding engine.
	Furthermore, the document includes considerations for node		Furthermore, the document includes considerations for node
	implementations where there is no distinction between the incoming		implementations where there is no distinction between the incoming
	and outgoing MIP.		and outgoing MIP.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		This document is not an Internet Standards Track specification; it is
	Task Force (IETF). Note that other groups may also distribute		published for informational purposes.
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Not all documents
			approved by the IESG are a candidate for any level of Internet
			Standard; see Section 2 of RFC 5741.
	This Internet-Draft will expire on October 24, 2013.		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/rfc7054.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction ....................................................2
	2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3		2. Terminology .....................................................3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Summary of the Problem Statement ................................3
	4. Summary of the Problem Statement . . . . . . . . . . . . . . . 4		4. Requirements and Design Considerations for Internal-MIP
	5. Requirements and Design Considerations for Internal-MIP		Addressing ......................................................6
	Adressing . . . . . . . . . . . . . . . . . . . . . . . . . . 6		5. Security Considerations ........................................10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6. Acknowledgments ................................................10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7. References .....................................................10
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		7.1. Normative References ......................................10
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		7.2. Informative References ....................................11
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	9.2. Informative References . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	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 the
	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
	a single MIP per node in an unspecified location within the node and		a single MIP per node in an unspecified location within the node and
	per-interface MIPs are two (or more) MIPs per node on each side of		per-interface MIPs are two (or more) MIPs per node on each side of
	the forwarding engine.		the forwarding engine.
	In-band OAM messages are sent using the Generic Associated Channel		In-band OAM messages are sent using the Generic Associated Channel
	(G-ACh) [RFC5586]. OAM messages for the transit points of		(G-ACh) [RFC5586]. OAM messages for the transit points of
	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] or the presence of		the PW Associated Channel Header (PWACH) [RFC4385] or the presence of
	a GAL [RFC6423].		a GAL [RFC6423].
	In case multiple MIPs are present on a single node, these mechanisms		If multiple MIPs are present on a single node, these mechanisms alone
	alone provide no way to address one particular MIP out of the set of		provide no way to address one particular MIP out of the set of MIPs.
	MIPs. A mechanism that addresses this shortcoming has to obey a few		A mechanism that addresses this shortcoming has to obey a few
	important design considerations which are discussed in this document.		important design considerations, which are discussed in this
			document.
	Note that the acronym "OAM" is used in conformance with [RFC6291].
	2. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].
	3. Terminology		2. Terminology
	In this document we use the term in-MIP (incoming MIP) to refer to		In this document, we use the term in-MIP (incoming MIP) to refer to
	the MIP which processes OAM messages before they pass through the		the MIP that processes OAM messages before they pass through the
	forwarding engine of a node. An out-MIP (outgoing MIP) processes OAM		forwarding engine of a node. An out-MIP (outgoing MIP) processes OAM
	messages after they have passed the forwarding engine of the node.		messages after they have passed the forwarding engine of the node.
	The two together are referred to as internal MIPs.		The two together are referred to as internal MIPs. The term
			"forwarding engine" is used as defined in [RFC6371].
	4. Summary of the Problem Statement		Note that the acronym "OAM" is used in conformance with [RFC6291].
			3. Summary of the Problem Statement
	Figure 1 shows an abstract functional representation of an MPLS-TP		Figure 1 shows an abstract functional representation of an MPLS-TP
	node. It is decomposed as an incoming interface, a forwarding engine		node. It is decomposed as an incoming interface (labeled "In"), a
	(FW), and an outgoing interface. As per the discussion in [RFC6371],		forwarding engine (FW), and an outgoing interface (labeled "Out").
	MIPs may be placed in each of the functional interface components.		As per the discussion in [RFC6371], MIPs may be placed in each of the
			functional interface components.
	------------------------		------------------------
	|----- -----|		|----- -----|
	| MIP | | MIP |		| MIP | | MIP |
	| | ---- | |		| | ---- | |
	----->-| In |->-| FW |->-| Out |->----		----->-| In |->-| FW |->-| Out |->----
	| i/f | ---- | i/f |		| i/f | ---- | i/f |
	|----- -----|		|----- -----|
	------------------------		------------------------
	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 for both PWs and LSPs such as:		model for both PWs and LSPs, such as:
			o Connectivity Verification (CV) between a Maintenance Entity Group
			End Point (MEP) and a MIP
	o Connectivity Verification (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 data-plane loopback configuration at a MIP		o data-plane loopback configuration 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 also be the MIPs at the incoming
	incoming or outgoing interfaces.		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 diagnostic		accurate localization and identification of faults and diagnostic
	tests. In particular, the identification of whether a problem is		tests. In particular, the identification of whether a problem is
	located between nodes or on a particular node and where on that node		located between nodes or on a particular node and where on that node
	is greatly enhanced. For obvious reasons, it is important to narrow		is greatly enhanced. For obvious reasons, it is important to narrow
	the cause of a fault down quickly to initiate a timely, and well-		down the cause of a fault quickly to initiate a timely and well-
	directed maintenance action to resume normal network operation.		directed maintenance action to resume normal network operation.
	The following two figures illustrate the fundamental difference of		The following two figures illustrate the fundamental difference
	using per-node and per-interface MEPs and MIPs for OAM. Figure 2		between using per-node and per-interface MEPs and MIPs for OAM.
	depicts OAM using per-node MIPs and MEPs. For reasons of exposition		Figure 2 depicts OAM using per-node MIPs and MEPs. For reasons of
	we pick a location for the MIPs on the nodes but the standard does		exposition, we pick a location for the MIPs on the nodes but the
	not mandate the exact location for the per-node model. Figure 3 on		standard does not mandate the exact location for the per-node model.
	the other hand shows the same basic network but for OAM operations		In the figure, a bidirectional LSP is depicted where in the forward
	per-interface maintenance points are configured. Note that these		(FWD) direction MEP1, MIP1, and MEP2 are located on the ingress
	figures are merely examples. It is important to note that per-		interface. In the backward (BWD) direction MEP1', MIP1' and MEP2'
	interface MEPs or per-interface MIPs MUST logically be placed at a		are located on the egress interface, i.e., the same interfaces. S1
	point before (for in-MIP) or after (for out-MIP) passing the		in the figure denotes the segment from PE1 In to P1 In and S2 denotes
	forwarding engine as defined in [RFC6371]. It MUST be assured that		the segment from PE1 In to P2 In. Figure 3, on the other hand, shows
	all traffic for which the MEP/MIP is associated with must pass		the same basic network, but per-interface maintenance points are
	through or be terminated at that point.		configured for OAM operations. Note that these figures are merely
			examples. It is important to note that per-interface MEPs or per-
			interface MIPs must logically be placed at a point before (for
			in-MIP) or after (for out-MIP) passing the forwarding engine as
			defined in [RFC6371]. All traffic associated with the MEP/MIP must
			pass through or be terminated at that point.
	Customer| Operator's administrative | Customer		Customer| Operator's Administrative | Customer
	Domain | Domain | Domain		Domain | Domain | Domain
	------> |<--------------------------------------->| <------		------> |<--------------------------------------->| <------
	CE1 | T-PE/PE1 S-PE/P1 T-PE/PE2 | CE2		CE1 | T-PE/PE1 S-PE/P1 T-PE/PE2 | CE2
	| <--------> <--------> <--------> |		| <--------> <--------> <--------> |
	+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+		+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
	| | | | | | | | | | | | | | | | | | | | | | | |		| | | | | | | | | | | | | | | | | | | | | | | |
	| | | | | | | | | | | | | | | | | | | | | | | |		| | | | | | | | | | | | | | | | | | | | | | | |
	+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+		+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
	| In FW Out In FW Out In FW Out |		| In FW Out In FW Out In FW Out |
	| |		| |
	FWD PW/LSP | o-------------------------- > |		FWD PW/LSP | o-------------------------- > |
	| V-------------*-------------V |		| V-------------*-------------V |
	| MEP1 MIP1 MEP2 |		| MEP1 MIP1 MEP2 |
	BWD PW/LSP | <---------------------------o |		BWD PW/LSP | <---------------------------o |
	| V-------------*-------------V |		| V-------------*-------------V |
	| MEP1' MIP1' MEP2'|		| MEP1' MIP1' MEP2'|
	(S1)<============>		(S1)<============>
	(S2)<==========================>		(S2)<==========================>
	Figure 2: Example of OAM relying on per-node MIPs and MEPs		Figure 2: Example of OAM Relying on Per-Node MIPs and MEPs
	To illustrate the difference between these two modes of operation, we		To illustrate the difference between these two modes of operation, we
	use fault detection as an example. Consider the case where the		use fault detection as an example. Consider the case where the
	client traffic between CE1 and CE2 experiences a fault. Also assume		client traffic between CE1 and CE2 experiences a fault. Also assume
	that an on-demand CV test between PE1 and PE2 was successful. The		that an on-demand CV test between PE1 and PE2 was successful. The
	scenario in Figure 2 therefore leaves the forwarding engine (FW) of		scenario in Figure 2 therefore leaves the forwarding engine (FW) of
	PE2, the out-going interface of PE2, the transmission line between		PE2, the out-going interface of PE2, the transmission line between
	PE2 and CE2 or CE2 itself as a potential location of the fault as on-		PE2 and CE2, or CE2 itself as a potential location of the fault as
	demand CV can only be performed on segment S2.		on-demand CV can only be performed on segment S2. Note that in this
			scenario, the PWs or LSPs are to be understood as two examples (not
			one), i.e., the figures do not show the layer structure of PWs and
			LSPs.
	The per-interface model in Figure 3 allows more fine-grained OAM		The per-interface model in Figure 3 allows more fine-grained OAM
	operations to be performed. At first, CV on segment S'4 and in		operations to be performed. At first, CV on segment S'4 and in
	addition CV on segment S'5 can help to rule out e.g. the forwarding		addition CV on segment S'5 can help to rule out, for example, the
	engine of PE2. This is of course only a single example, and other		forwarding engine of PE2. This is of course only a single example,
	OAM functions and scenarios are trivially conceivable. The basic		and other OAM functions and scenarios are trivially conceivable. The
	message is that with the per-interface OAM model, an operator can		basic message is that with the per-interface OAM model, an operator
	configure smaller segments on a transport path to which OAM		can configure smaller segments on a transport path to which OAM
	operations apply. This enables a more fine-grained scoping of OAM		operations apply. This enables a more fine-grained scoping of OAM
	operations such as fault localization and performance monitoring		operations, such as fault localization and performance monitoring,
	which gives operators better information to deal with adverse		which gives operators better information to deal with adverse
	networking conditions.		networking conditions.
	Customer Operator's administrative Customer		Customer| Operator's Administrative |Customer
	Domain Domain Domain		Domain | Domain |Domain
	------->|<--------------------------------------->|<------		------->|<--------------------------------------->|<------
	CE1 | T-PE/PE1 S-PE/P1 T-PE/PE2 | CE2		CE1 | T-PE/PE1 S-PE/P1 T-PE/PE2 | CE2
	| <--------> <--------> <--------> |		| <--------> <--------> <--------> |
	+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+		+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
	| | | | | | | | | | | | | | | | | | | | | | | |		| | | | | | | | | | | | | | | | | | | | | | | |
	| | | | | | | | | | | | | | | | | | | | | | | |		| | | | | | | | | | | | | | | | | | | | | | | |
	+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+		+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
	| In FW Out In FW Out In FW Out |		| In FW Out In FW Out In FW Out |
	| |		| |
	FWD PW/LSP | o-----------------------------------> |		FWD PW/LSP | o-----------------------------------> |
	| V-------*------*------*-----*-------V |		| V-------*------*------*-----*-------V |
	| MEP1 MIP1 MIP2 MIP3 MIP4 MEP2|		| MEP1 MIP1 MIP2 MIP3 MIP4 MEP2|
	| |		| |
	BWD PW/LSP | <-----------------------------------o |		BWD PW/LSP | <-----------------------------------o |
	| MEP1' MIP1' MIP2' MIP3' MIP4' MEP2'|		| MEP1' MIP1' MIP2' MIP3' MIP4' MEP2'|
	(S'1)<======>		(S'1)<======>
	(S'2)<=============>		(S'2)<=============>
	(S'3)<====================>		(S'3)<====================>
	(S'4)<==========================>		(S'4)<==========================>
	(S'5)<==================================>		(S'5)<==================================>
	Figure 3: Example of OAM relying on per-interface MIPs and MEPs		Figure 3: Example of OAM Relying on Per-Interface MIPs and MEPs
	5. Requirements and Design Considerations for Internal-MIP Adressing		4. Requirements and Design Considerations for Internal-MIP Addressing
	OAM messages for transit points of PWs or LSPs are delivered using		OAM messages for transit points of PWs or LSPs are delivered using
	the expiration of the time-to-live (TTL) field in the top LSE of the		the expiration of the TTL field in the top LSE of the MPLS packet
	MPLS packet header. OAM messages for the end points of PWs and LSPs		header. OAM messages for the end points of PWs and LSPs are simply
	are simply delivered as normal. These messages are distinguished		delivered as normal. These messages are distinguished from other
	from other (data) packets so that they can be processed as OAM. In		(data) packets so that they can be processed as OAM. In LSPs, the
	LSPs, the mechanism used is the presence of the Generic Associated		mechanism used is the presence of the GAL in the LSE under the top
	Channel Label (GAL) in the LSE under the top LSE [RFC5586]. In PWs,		LSE [RFC5586]. In PWs, the mechanism used is the presence of the PW
	the mechanism used is the presence of the PW Associated Channel		Associated Channel Header [RFC4385] or the presence of a GAL
	Header [RFC4385] or the presence of a GAL [RFC6423]. In addition,		[RFC6423]. In addition, two sets of identifiers exist that can be
	two sets of identifiers exist that can be used to address MIPs which		used to address MIPs, which are defined in [RFC6370] and [RFC6923]
	are defined in [RFC6370] and [I-D.ietf-mpls-tp-itu-t-identifiers]
	Any solution for sending OAM messages to the in and out-MIPs must fit		Any solution for sending OAM messages to the in- and out-MIPs must
	within these existing models of handling OAM.		fit within these existing models of handling OAM.
	Additionally, many MPLS-TP nodes are implemented in a way that all		Additionally, many MPLS-TP nodes are implemented in a way that all
	queuing and the forwarding function is performed at the incoming		queuing and the forwarding function are 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
	functions on those interfaces. This is in particular the case for		MIP functions on those interfaces. This is the case for existing
	existing deployed implementations.		deployed implementations in particular.
	Any solution that attempts to send OAM messages to the outgoing		Any solution that attempts to send OAM messages to the outgoing
	interface of an MPLS-TP node must not cause any problems when such		interface of an MPLS-TP node must not cause any problems when such
	implementations are present (such as leaking OAM packets with a TTL		implementations are present (such as leaking OAM packets with a TTL
	of 0).		of 0).
			---------------------
			|------------ |
			| MIP | |
			| ---- | |
			----->-| In | FW | |-->-Out-|->---
			| i/f ---- | i/f |
			|------------ |
			---------------------
	------------------		Figure 4: Abstract Functional Representation of
	|------------ |		Some Existing MPLS-TP Nodes
	| MIP | |
	| ---- | |
	----->-| In | FW | |-->--|->---
	| i/f ---- | |
	|------------ |
	------------------
	Figure 4: Abstract Functional Representation of Some Existing MPLS-TP
	Nodes
	OAM must operate on MPLS-TP nodes that are branch points on point-to-		OAM must operate on MPLS-TP nodes that are branch points on point-to-
	multipoint (P2MP) trees. That means that it must be possible to		multipoint (P2MP) trees. This means that it must be possible to
	target individual outgoing MIPs as well as all outgoing MIPs in the		target individual outgoing MIPs as well as all outgoing MIPs in the
	abstract functional representation shown in Figure 5, as well as to		abstract functional representation shown in Figure 5, and to handle
	handle the P2MP node implementations as shown in Figure 6 without		the P2MP node implementations as shown in Figure 6 without causing
	causing problems.		problems.
			--------------------------
	--------------------------		| -----|
	| -----|		| | MIP |
	| | MIP |		| ->-| |->----
	| ->-| |->----		| | | Out |
	| | | Out |		| | | i/f |
	| | | i/f |		| | -----|
	| | -----|		|----- | -----|
	|----- | -----|		| MIP | ---- | | MIP |
	| MIP | ---- | | MIP |		| | | |- | |
	| | | |- | |		----->-| In |->-| FW |--->-| Out |->----
	----->-| In |->-| FW |--->-| Out |->----		| i/f | | |- | i/f |
	| i/f | | |- | i/f |		|----- ---- | -----|
	|----- ---- | -----|		| | -----|
	| | -----|		| | | MIP |
	| | | MIP |		| | | |
	| | | |		| ->-| Out |->----
	| ->-| Out |->----		| | i/f |
	| | i/f |		| -----|
	| -----|		--------------------------
	--------------------------
	Figure 5: Abstract Functional Representation of an MPLS-TP Node
	Supporting P2MP
	------------------		Figure 5: Abstract Functional Representation of an
	| ->-|->----		MPLS-TP Node Supporting P2MP
	| | |		----------------------
	|------------ | |		| ->-Out-|->----
	| | | |		| | i/f |
	| MIP ---- | | |		|------------ | |
	| | | |- |		| | | |
	----->-| In | FW | |--->-|->----		| MIP ---- | | |
	| i/f | | |- |		| | | |- |
	| ---- | | |		----->-| In | FW | |--->-Out-|->----
	| | | |		| i/f | | |- i/f |
	|------------ | |		| ---- | | |
	| | |		| | | |
	| ->-|->----		|------------ | |
	------------------		| | Out |
			| ->-i/f-|->----
			----------------------
	Figure 6: Abstract Functional Representation of Some Existing MPLS-TP		Figure 6: Abstract Functional Representation of
	Nodes Supporting P2MP		Some Existing MPLS-TP Nodes Supporting P2MP
	In summary, the solution for OAM message delivery must behave as		In summary, the solution for OAM message delivery must behave as
	follows:		follows:
	o Delivery of OAM messages to the correct MPLS-TP node.		o Delivery of OAM messages to the correct MPLS-TP node.
	o Delivery of OAM instructions to the correct MIP within an MPLS-TP		o Delivery of OAM instructions to the correct MIP within an MPLS-TP
	node.		node.
	o Forwarding of OAM packets exactly as data packets.		o Forwarding of OAM packets exactly as data packets.
	o Packet inspection at the incoming and outgoing interfaces must be		o Packet inspection at the incoming and outgoing interfaces must be
	minimized.		minimized.
	The first and second bullet point are obvious. The third bullet		The first and second bullet points are obvious. However, the third
	point however is also vital. To illustrate the importance, a		bullet point is also vital. To illustrate the importance, a rejected
	rejected solution is depicted in Figure 7. In the figure, all data		solution is depicted in Figure 7. In the figure, all data and non-
	and non-local OAM is handled as normal. Local OAM is intercepted at		local OAM is handled as normal. Local OAM is intercepted at the
	the incoming interface and delivered to the MIP at the incoming		incoming interface and delivered to the MIP at the incoming
	interface. If the OAM is intended for the incoming MIP it is handled		interface. If the OAM is intended for the incoming MIP, it is
	there with no issue. If the OAM is intended for the outgoing MIP it		handled there with no issue. If the OAM is intended for the outgoing
	is forwarded to that MIP using some internal messaging system that is		MIP, it is forwarded to that MIP using some internal messaging system
	implementation-specific.		that is implementation specific.
	------------------------		------------------------
	|----- -----|		|----- -----|
	local OAM ----->-| MIP |----->------| MIP |		local OAM ----->-| MIP |----->------| MIP |
	| | ---- | |		| | ---- | |
	data =====>=| In |=>=| FW |=>=| Out |=>==== data		data =====>=| In |=>=| FW |=>=| Out |=>==== data
	non-local OAM ~~~~~>~| i/f |~>~| |~>~| i/f |~>~~~~ non-local OAM		non-local OAM ~~~~~>~| i/f |~>~| |~>~| i/f |~>~~~~ non-local OAM
	|----- ---- -----|		|----- ---- -----|
	------------------------		------------------------
	Figure 7: OAM Control Message Delivery Bypassing the Forwarding		Figure 7: OAM Control Message Delivery Bypassing
	Engine		the Forwarding Engine
	This solution is fully functional for the incoming MIP. It also		This solution is fully functional for the incoming MIP. It also
	supports control of data loopback for the outgoing MIP, and can		supports control of data loopback for the outgoing MIP and can
	adequately perform some OAM features such as interface identity		adequately perform some OAM features such as interface identity
	reporting at the outgoing MIP.		reporting at the outgoing MIP.
	However, because the OAM message is not forwarded through the		However, because the OAM message is not forwarded through the
	forwarding engine, this solution cannot correctly perform OAM		forwarding engine, this solution cannot correctly perform OAM
	loopback, connectivity verification, LSP tracing, or performance		loopback, connectivity verification, LSP tracing, or performance
	measurement.		measurement.
	The last bullet point is also an important requirement for any		The last bullet point is also an important requirement for any
	solution to the internal-MIP addressing problem. Since OAM packets		solution to the internal-MIP addressing problem. Since OAM packets
	that target an out-MIP need to be sent through the forwarding engine		that target an out-MIP need to be sent through the forwarding engine
	and treated exactly as regular data packets, the determination of		and treated exactly as regular data packets, the determination of
	whether to forward the packet or process it at the incoming MIP needs		whether to forward the packet or process it at the incoming MIP needs
	to be fast and therefore the processing overhead must be kept to a		to be fast; therefore, the processing overhead must be kept to a
	minimum. In addition, there are a few OAM procedures that operate at		minimum. In addition, there are a few OAM procedures that operate at
	line rate such as OAM loopback. This adds to the requirement of		line rate such as OAM loopback. This adds to the requirement of
	minimal processing overhead for both the in-MIP and out-MIP.		minimal processing overhead for both the in-MIP and out-MIP.
	Most of the above superficially appears to be an implementation		Most of the above superficially appears to be an implementation
	matter local to an individual node, the format of the message needs		matter local to an individual node; however, the format of the
	to be standardised so that:		message needs to be standardized so that:
	o A MEP can correctly target the outgoing MIP of a specific MPLS-TP		o A MEP can correctly target the outgoing MIP of a specific MPLS-TP
	node.		node.
	o A node can correctly filter out any OAM messages that were		o A node can correctly filter out any OAM messages that were
	intended for its upstream neighbor's outgoing MIP, but which were		intended for its upstream neighbor's outgoing MIP, but which were
	not handled there because the upstream neighbor is an		not handled there because the upstream neighbor is an
	implementation as shown in Figure 4 or Figure 6.		implementation as shown in Figures 4 and 6.
	Note that the last bullet point describes a safety net and an		Note that the last bullet point describes a safety net in case OAM
	implementation should avoid that this situation ever arises.		messages leak beyond their intended scope, but implementations should
			take care that messages do not leak so that the safety net does not
			need to be used.
	6. Security Considerations		5. Security Considerations
	OAM security is discussed in [RFC6371] and security aspects specific		OAM security is discussed in [RFC6371] and security aspects specific
	to MPLS-TP in general are outlined in		to MPLS-TP in general are outlined in [RFC6941].
	[I-D.ietf-mpls-tp-security-framework].
	OAM can provide useful information for detecting and tracing security		OAM can provide useful information for detecting and tracing security
	attacks.		attacks.
	OAM can also be used to illicitly gather information or for denial of		OAM can also be used to illicitly gather information or for denial-
	service attacks and other types of attack. Implementations therefore		of-service attacks and other types of attack. Implementations
	are required to offer security mechanisms for OAM. Deployments are		therefore are required to offer security mechanisms for OAM.
	strongly advised to use such mechanisms.		Deployments are therefore strongly advised to follow the security
			advice provided in RFCs 6371 and 6941.
	Mixing of per-node and per-interface OAM on a single node is not		Mixing of per-node and per-interface OAM on a single node is not
	advised as OAM message leakage could be the result.		advised as OAM message leakage could be the result.
	7. IANA Considerations		6. Acknowledgments
	This revision of this document does not make any requests of IANA.
	8. 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, Sami Boutros and		Zhenlong Cui. We would also like to thank Eric Gray, Sami Boutros,
	Shahram Davari for interesting input to this document through		and Shahram Davari for interesting input to this document through
	discussions.		discussions.
	9. References		7. References
	9.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-08 (work in
	progress), February 2013.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		7.1. Normative References
	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., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
	Associated Channel", RFC 5586, June 2009.		"MPLS Generic 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., Ed., and D. Allan, Ed., "Operations,
	Maintenance Framework for MPLS-Based Transport Networks",		Administration, and Maintenance Framework for MPLS-Based
	RFC 6371, September 2011.		Transport Networks", RFC 6371, September 2011.
	[RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the		[RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the
	Generic Associated Channel Label for Pseudowire in the		Generic Associated Channel Label for Pseudowire in the
	MPLS Transport Profile (MPLS-TP)", RFC 6423,		MPLS Transport Profile (MPLS-TP)", RFC 6423, November
	November 2011.		2011.
	9.2. Informative References		[RFC6923] Winter, R., Gray, E., van Helvoort, H., and M. Betts,
			"MPLS Transport Profile (MPLS-TP) Identifiers Following
			ITU-T Conventions", RFC 6923, May 2013.
	[I-D.ietf-mpls-tp-security-framework]		7.2. Informative References
	Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
	Graveman, "MPLS-TP Security Framework",
	draft-ietf-mpls-tp-security-framework-09 (work in
	progress), February 2013.
	[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"
	Acronym in the IETF", BCP 161, RFC 6291, June 2011.		Acronym in the IETF", BCP 161, RFC 6291, June 2011.
			[RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed.,
			and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP)
			Security Framework", RFC 6941, April 2013.
	Authors' Addresses		Authors' Addresses
	Adrian Farrel		Adrian Farrel
	Juniper Networks		Juniper Networks
	Email: adrian@olddog.co.uk		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
	Manuel Paul		Manuel Paul
	Deutsche Telekom		Deutsche Telekom
	Email: Manuel.Paul@telekom.de		EMail: Manuel.Paul@telekom.de
End of changes. 75 change blocks.
	272 lines changed or deleted		268 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/