< draft-ietf-pwe3-p2mp-pw-requirements-02.txt		draft-ietf-pwe3-p2mp-pw-requirements-03.txt >
	Network Working Group F. Jounay (Ed.)		Network Working Group F. Jounay (Ed.)
	Internet Draft P. Niger		Internet Draft P. Niger
	Category: Informational Track France Telecom		Category: Informational France Telecom Orange
	Expires: June 2010		Expires: January 2011
	Y. Kamite		Y. Kamite
	L. Martini NTT Communications		L. Martini NTT Communications
	Cisco		Cisco
	S. Delord		S. Delord
	R. Aggarwal Testra		R. Aggarwal Testra
	Juniper Networks		Juniper Networks
	L. Wang		L. Wang
	M. Bocci Telenor		M. Bocci Telenor
	M. Vigoureux		M. Vigoureux
	Alcatel-Lucent G. Heron		Alcatel-Lucent G. Heron
	BT		BT
	L. Jin		L. Jin
	ZTE Janvier 08, 2010		ZTE August 18, 2010
	Requirements for Point-to-Multipoint Pseudowire		Requirements for Point-to-Multipoint Pseudowire
	draft-ietf-pwe3-p2mp-pw-requirements-02.txt		draft-ietf-pwe3-p2mp-pw-requirements-03.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on June, 2010.		This Internet-Draft will expire on January, 2011.
	Abstract		Abstract
	This document presents a set of requirements for providing a Point-		This document presents a set of requirements for providing a Point-
	to-Multipoint PWE3 (Pseudowire Emulation Edge to Edge) emulation. The		to-Multipoint PWE3 (Pseudowire Emulation Edge to Edge) emulation. The
	requirements identified in this document are related to architecture,		requirements identified in this document are related to architecture,
	signaling and maintenance aspects of a Point-to-Multipoint PW		signaling and maintenance aspects of a Point-to-Multipoint PW
	operation. They are proposed as guidelines for the standardization of		operation. They are proposed as guidelines for the standardization of
	such mechanisms. Among other potential applications Point-to-		such mechanisms. Among other potential applications Point-to-
	Multipoint PWs SHOULD be used to optimize the support of multicast		Multipoint PWs SHOULD be used to optimize the support of multicast
	skipping to change at page 3, line 14 ¶		skipping to change at page 3, line 14 ¶
	4.5. Protection and Restoration...................................15		4.5. Protection and Restoration...................................15
	4.6. Scalability..................................................15		4.6. Scalability..................................................15
	5. Manageability considerations...................................15		5. Manageability considerations...................................15
	6. Backward Compatibility.........................................16		6. Backward Compatibility.........................................16
	7. Security Considerations........................................16		7. Security Considerations........................................16
	8. IANA Considerations............................................16		8. IANA Considerations............................................16
	9. Acknowledgments................................................16		9. Acknowledgments................................................16
	10. References....................................................17		10. References....................................................17
	10.1. Normative References........................................17		10.1. Normative References........................................17
	10.2. Informative References......................................17		10.2. Informative References......................................17
	Authors' Addresses.................................................18		Authors' Addresses............ ...................................18
	Copyright and Licence Notice.......................................19		Copyright and Licence Notice.. ...................................19
	1. Introduction		1. Introduction
	1.1. Problem Statement		1.1. Problem Statement
	As defined in the PWE3 WG charter, a Pseudowire (PW) emulates a		As defined in the PWE3 WG charter, a Pseudowire (PW) emulates a
	point-to-point bidirectional link over an IP/MPLS network, and		point-to-point bidirectional link over an IP/MPLS network, and
	provides a single service which is perceived by its user as an		provides a single service which is perceived by its user as an
	unshared link or circuit of the chosen service. A Pseudowire is used		unshared link or circuit of the chosen service. A Pseudowire is used
	to transport non IP traffic (e.g. Ethernet, TDM, ATM, and FR) in an		to transport non IP traffic (e.g. Ethernet, TDM, ATM, and FR) in an
	skipping to change at page 6, line 6 ¶		skipping to change at page 6, line 6 ¶
	PE connected to a traffic source to at least two Leaf PEs connected		PE connected to a traffic source to at least two Leaf PEs connected
	to traffic receivers. The PW endpoints connect the PW to its		to traffic receivers. The PW endpoints connect the PW to its
	Attachment Circuit (AC). As for a P2P PW, an AC can be a Frame Relay		Attachment Circuit (AC). As for a P2P PW, an AC can be a Frame Relay
	DLC, an ATM VP/VC, an Ethernet port, a VLAN, a HDLC link on a		DLC, an ATM VP/VC, an Ethernet port, a VLAN, a HDLC link on a
	physical interface.		physical interface.
	Figure 1 describes the P2MP SS-PW reference model which is derived		Figure 1 describes the P2MP SS-PW reference model which is derived
	from [RFC3985] to support P2MP emulated services.		from [RFC3985] to support P2MP emulated services.
	|<-----------P2MP SS-PW------------>|		|<-----------P2MP SS-PW------------>|
	Native | | Native		Native | | Native
	Service | |<----P2MP PSN tunnel --->| | Service		Service | |<----P2MP PSN tunnel --->| | Service
	(AC) V V V V (AC)		(AC) V V V V (AC)
	| +----+ +-----+ +----+ |		| +----+ +-----+ +----+ |
	| |PE1 | | P |=========|PE2 |AC2 | +----+		| |PE1 | | P |=========|PE2 |AC2 | +----+
	| | | | ......PW1.......>|---------->|CE2 |		| | | | ......PW1.......>|---------->|CE2 |
	| | | | . |=========| | | +----+		| | | | . |=========| | | +----+
	| | | | . | +----+ |		| | | | . | +----+ |
	| | |=========| . | |		| | |=========| . | |
	| | | | . | +----+ |		| | | | . | +----+ |
	+----+ | AC1 | | | . |=========|PE3 |AC3 | +----+		+----+ | AC1 | | | . |=========|PE3 |AC3 | +----+
	|CE1 |-------->|........PW1.............PW1.......>|---------->|CE3 |		|CE1 |-------->|........PW1.............PW1.......>|---------->|CE3 |
	+----+ | | | | . |=========| | | +----+		+----+ | | | | . |=========| | | +----+
	skipping to change at page 7, line 15 ¶		skipping to change at page 7, line 15 ¶
	3.2. P2MP SS-PW Underlying Layer		3.2. P2MP SS-PW Underlying Layer
	The P2MP SS-PW implies an underlying P2MP PSN tunnel. Figure 2 gives		The P2MP SS-PW implies an underlying P2MP PSN tunnel. Figure 2 gives
	an example of P2MP SS-PW topology relying on a P2MP LSP. The PW tree		an example of P2MP SS-PW topology relying on a P2MP LSP. The PW tree
	is composed of one Root PE (i1) and several Leaf PEs (e1, e2, e3,		is composed of one Root PE (i1) and several Leaf PEs (e1, e2, e3,
	e4).		e4).
	The P2MP PSN MAY be signaled with P2MP RSVP-TE [RFC4875] or MLDP		The P2MP PSN MAY be signaled with P2MP RSVP-TE [RFC4875] or MLDP
	[MLDP].		[MLDP].
	i1		i1
	/		/
	/ \		/ \
	/ \		/ \
	/ \		/ \
	/\ \		/\ \
	/ \ \		/ \ \
	/ \ \		/ \ \
	/ \ / \		/ \ / \
	e1 e2 e3 e4		e1 e2 e3 e4
	Figure 2 Example of P2MP Underlying Layer for P2MP SS-PW		Figure 2 Example of P2MP Underlying Layer for P2MP SS-PW
	The P2MP PW MAY be supported over multiple P2MP PSN tunnel. These		The P2MP PW MAY be supported over multiple P2MP PSN tunnel. These
	P2MP PSN tunnels MUST be able to serve more than one P2MP PW.		P2MP PSN tunnels MUST be able to serve more than one P2MP PW.
	The P2MP Tunnels MAY also be of different technology (ex. MPLS over		The P2MP Tunnels MAY also be of different technology (ex. MPLS over
	GRE, or P-to-MP MPLS LSP ) or just use different setup protocols.		GRE, or P-to-MP MPLS LSP ) or just use different setup protocols.
	(ex. MLDP, and P2MP RSVP-TE ).		(ex. MLDP, and P2MP RSVP-TE ).
	skipping to change at page 10, line 16 ¶		skipping to change at page 10, line 16 ¶
	An alternative protection scheme MAY rely on the PW layer.		An alternative protection scheme MAY rely on the PW layer.
	Leaf PEs MAY be protected via a P2MP PW redundancy mechanism. In the		Leaf PEs MAY be protected via a P2MP PW redundancy mechanism. In the
	example depicted below, a standby P2MP PW is used to protect the		example depicted below, a standby P2MP PW is used to protect the
	active P2MP. In that protection scheme the AC at the Root PE MUST		active P2MP. In that protection scheme the AC at the Root PE MUST
	serve both P2MP PWs. In this scenario, the condition when to do the		serve both P2MP PWs. In this scenario, the condition when to do the
	switchover should be implemented, e.g. one or all Leaf failure of		switchover should be implemented, e.g. one or all Leaf failure of
	active P2MP PW will course P2MP PW switchover.		active P2MP PW will course P2MP PW switchover.
	CE1		CE1
	|		|
	active PE1 standby		active PE1 standby
	P2MP PW .../ \....P2MP PW		P2MP PW .../ \....P2MP PW
	/ \		/ \
	P2 P3		P2 P3
	/ \ / \		/ \ / \
	/ \ / \		/ \ / \
	/ \ / \		/ \ / \
	PE4 PE5 PE6 PE7		PE4 PE5 PE6 PE7
	| | | |		| | | |
	| \ / |		| \ / |
	\ CE2 /		\ CE2 /
	\ /		\ /
	-------CE3------		-------CE3------
	Root PE MAY be protected via a P2MP PW redundancy mechanism. In the		Root PE MAY be protected via a P2MP PW redundancy mechanism. In the
	example depicted below, a standby P2MP PW is used to protect the		example depicted below, a standby P2MP PW is used to protect the
	active P2MP. A single AC at the Leaf PE MUST be used to attach the CE		active P2MP. A single AC at the Leaf PE MUST be used to attach the CE
	to the primary and the standby P2MP PW. The Leaf PE MUST support		to the primary and the standby P2MP PW. The Leaf PE MUST support
	protection mechanism in order to select the active P2MP PW.		protection mechanism in order to select the active P2MP PW.
	CE1		CE1
	/ \		/ \
	| |		| |
	active PE1 PE2 standby		active PE1 PE2 standby
	P2MP PW1 | | P2MP PW2		P2MP PW1 | | P2MP PW2
	| |		| |
	P2 P3		P2 P3
	/ \/ \		/ \/ \
	/ /\ \		/ /\ \
	/ / \ _\		/ / \ _\
	/ / \ \		/ / \ \
	PE4 PE5		PE4 PE5
	| |		| |
	CE2 CE3		CE2 CE3
	3.7. Scalability		3.7. Scalability
	The solution SHOULD scale at least as well as linearly with an		The solution SHOULD scale at least as well as linearly with an
	increase in the number of Leaf PEs.		increase in the number of Leaf PEs.
	An increase in the number of P2MP PW SHOULD NOT cause the P router to		An increase in the number of P2MP PW SHOULD NOT cause the P router to
	increase its forwarding table linearly.		increase its forwarding table linearly.
	The P2MP PW multiplexed/demultiplexed to P2MP PSN Tunnel can improve		The P2MP PW multiplexed/demultiplexed to P2MP PSN Tunnel can improve
	skipping to change at page 11, line 38 ¶		skipping to change at page 11, line 38 ¶
	| |T-PE| |S-PE1|=========|T-PE| | +----+		| |T-PE| |S-PE1|=========|T-PE| | +----+
	| | 1 | | ......PW2.....> 2|---------->|CE2 |		| | 1 | | ......PW2.....> 2|---------->|CE2 |
	| | | | . |=========| | | +----+		| | | | . |=========| | | +----+
	| | |=========| . | +----+ |		| | |=========| . | +----+ |
	| | | .....> | |		| | | .....> | |
	| | | . | . | +----+ |		| | | . | . | +----+ |
	| | | . | . |=========|T-PE| | +----+		| | | . | . |=========|T-PE| | +----+
	| | | . | ......PW3.....> 3|---------->|CE3 |		| | | . | ......PW3.....> 3|---------->|CE3 |
	| | | . | |=========| | | +----+		| | | . | |=========| | | +----+
	| | | . | | +----+ |		| | | . | | +----+ |
	| | | . +-----+		+----+ | | | . +-----+
	|CE1 |-------->|.......PW1... +-----+ +----+ |		|CE1 |-------->|.......PW1... +-----+ +----+ |
	| | | . |S-PE2|=========|T-PE| | +----+		+----+ | | | . |S-PE2|=========|T-PE| | +----+
	| | | . | | ......> 4|---------->|CE4 |		| | | . | | ......> 4|---------->|CE4 |
	| | | . | | . | | | +----+		| | | . | | . | | | +----+
	| | | . | | . +----+ |		| | | . | | . +----+ |
	| | | ......>...PW4.. |		| | | ......>...PW4.. |
	| | | | | . +----+ |		| | | | | . +----+ |
	| | |=========| | . |T-PE| | +----+		| | |=========| | . |T-PE| | +----+
	| | | | | ......> 5|---------->|CE5 |		| | | | | ......> 5|---------->|CE5 |
	| | | | |=========| | | +----+		| | | | |=========| | | +----+
	| | | | | +----+ |		| | | | | +----+ |
	| +----+ +-----+ |		| +----+ +-----+ |
	skipping to change at page 12, line 46 ¶		skipping to change at page 12, line 46 ¶
	packets or data received from b2 and send them to Leaf T-PEs e3 and		packets or data received from b2 and send them to Leaf T-PEs e3 and
	e4.		e4.
	However giving the fact that some PW segments MAY be supported over a		However giving the fact that some PW segments MAY be supported over a
	P2MP LSP, the traffic replication along the path of these PW segments		P2MP LSP, the traffic replication along the path of these PW segments
	can be performed as well at the underlying LSP level.		can be performed as well at the underlying LSP level.
	Figure 4 describes the case where each segment is supported over a		Figure 4 describes the case where each segment is supported over a
	P2P LSP except for the b1-b3b4 P2MP segment which is conveyed over a		P2P LSP except for the b1-b3b4 P2MP segment which is conveyed over a
	P2MP LSP on this section.		P2MP LSP on this section.
	i1		i1
	/ \		/ \
	b1 b2		b1 b2
	/ \		/ \
	/ \		/ \
	/\ \		/\ \
	/ \ \		/ \ \
	b3 b4 b5		b3 b4 b5
	/ \ / \		/ \ / \
	e1 e2 e3 e4		e1 e2 e3 e4
	Figure 4 Example of P2P and P2MP underlying Layer for P2MP MS-PW		Figure 4 Example of P2P and P2MP underlying Layer for P2MP MS-PW
	The P2MP PSN MAY be signaled with P2MP RSVP-TE [RFC4875] or MLDP		The P2MP PSN MAY be signaled with P2MP RSVP-TE [RFC4875] or MLDP
	[MLDP].		[MLDP].
	4.3. P2MP MS-PW Signaling Requirements		4.3. P2MP MS-PW Signaling Requirements
	4.3.1. Dynamically Instantiated P2MP MS-PW		4.3.1. Dynamically Instantiated P2MP MS-PW
	The PW tree could be statically configured at the T-PEs and each S-PE		The PW tree could be statically configured at the T-PEs and each S-PE
	skipping to change at page 16, line 27 ¶		skipping to change at page 16, line 27 ¶
	MUST have a mechanism to report an error for non-compliant PEs. In		MUST have a mechanism to report an error for non-compliant PEs. In
	this case, it SHOULD report which PE (S-PE and T-PEs) are not		this case, it SHOULD report which PE (S-PE and T-PEs) are not
	compliant.		compliant.
	In some cases, upstream traffic is required from downstream CE to		In some cases, upstream traffic is required from downstream CE to
	upstream CE. The P2MPPW solution SHOULD allow a return path (i.e.		upstream CE. The P2MPPW solution SHOULD allow a return path (i.e.
	from the Leaf to the Root) that provides upstream connection.		from the Leaf to the Root) that provides upstream connection.
	In particular, it is expected to be allowed that the same ACs are		In particular, it is expected to be allowed that the same ACs are
	shared between downstream and upstream direction. For downstream, a		shared between downstream and upstream direction. For downstream, a
	CE receives from its connected AC traffic originated by the Root PE		CE receives from its connected AC traffic originated by the Root PE
	transported over a P2MP PW. For upstream, the CE MAY also send over		transported over a P2MP PW. For upstream, the CE MAY also send over
	the same AC traffic destined to the same remote PE.		the same AC traffic destined to the same remote PE.
	7. Security Considerations		7. Security Considerations
	The security requirements common to PW are raised in Section 10 of		The security requirements common to PW are raised in Section 10 of
	[RFC3916] and common to MS-PW in section 7 of [RFC5254]. P2MP PW (SS		[RFC3916] and common to MS-PW in section 7 of [RFC5254]. P2MP PW (SS
	or MS) is a variant of the initial P2P PW definition, and that		or MS) is a variant of the initial P2P PW definition, and that
	statements also apply to P2MP PW.		statements also apply to P2MP PW.
	8. IANA Considerations		8. IANA Considerations
	skipping to change at page 17, line 44 ¶		skipping to change at page 17, line 44 ¶
	[RFC5659] Bocci, M., and Bryant, S.,T., " An Architecture for		[RFC5659] Bocci, M., and Bryant, S.,T., " An Architecture for
	Multi-Segment Pseudo Wire Emulation Edge-to-Edge",		Multi-Segment Pseudo Wire Emulation Edge-to-Edge",
	October 2009		October 2009
	10.2. Informative References		10.2. Informative References
	[MLDP] Minei, I., Wijnands, I., Thomas, B., "Label		[MLDP] Minei, I., Wijnands, I., Thomas, B., "Label
	Distribution Protocol Extensions for Point-to-		Distribution Protocol Extensions for Point-to-
	Multipoint and Multipoint-to-Multipoint Label Switched		Multipoint and Multipoint-to-Multipoint Label Switched
	Paths", Internet Draft, draft-ietf-mpls-ldp-p2mp-08,		Paths", Internet Draft, draft-ietf-mpls-ldp-p2mp-10,
	October 2009		July 2010
	[VPMS REQ] Kamite, Y., Jounay, F. "Framework and Requirements for		[VPMS REQ] Kamite, Y., Jounay, F. "Framework and Requirements for
	Virtual Private Multicast Service (VPMS)", Internet		Virtual Private Multicast Service (VPMS)", Internet
	Draft, draft-ietf-l2vpn-vpms-frmwk-requirements-02,		Draft, draft-ietf-l2vpn-vpms-frmwk-requirements-03,
	October 2009		July 2010
	Author's Addresses		Author's Addresses
	Frederic Jounay		Frederic Jounay
	France Telecom		France Telecom
	2, avenue Pierre-Marzin		2, avenue Pierre-Marzin
	22307 Lannion Cedex		22307 Lannion Cedex
	FRANCE		FRANCE
	Email: frederic.jounay@orange-ftgroup.com		Email: frederic.jounay@orange-ftgroup.com
	skipping to change at page 18, line 36 ¶		skipping to change at page 18, line 36 ¶
	Japan		Japan
	Email: y.kamite@ntt.com		Email: y.kamite@ntt.com
	Luca Martini		Luca Martini
	Cisco Systems, Inc.		Cisco Systems, Inc.
	9155 East Nichols Avenue, Suite 400		9155 East Nichols Avenue, Suite 400
	Englewood, CO, 80112		Englewood, CO, 80112
	EMail: lmartini@cisco.com		EMail: lmartini@cisco.com
	Giles Heron		Giles Heron
	Tellabs		BT
	Abbey Place
	24-28 Easton Street
	High Wycombe
	Bucks
	HP11 1NT
	UK		UK
	EMail: giles.heron@tellabs.com		EMail: giles.heron@gmail.com
	Simon Delord		Simon Delord
	Telstra		Telstra
	242 Exhibition St		242 Exhibition St
	Melbourne VIC 3000		Melbourne VIC 3000
	Australia		Australia
	Email: simon.a.delord@team.telstra.com		Email: simon.a.delord@team.telstra.com
	Lei Wang		Lei Wang
	Telenor		Telenor
	skipping to change at page 19, line 37 ¶		skipping to change at page 19, line 33 ¶
	Lizhong JIN		Lizhong JIN
	ZTE Corporation		ZTE Corporation
	889, Bibo Road,		889, Bibo Road,
	Shanghai, 201203, China		Shanghai, 201203, China
	Email: lizhong.jin@zte.com.cn		Email: lizhong.jin@zte.com.cn
	Copyright and License Notice		Copyright and License Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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 in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		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.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this		10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow		material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s)
	the copyright in such materials, this document may not be modified		controlling the copyright in such materials, this document may not
	outside the IETF Standards Process, and derivative works of it may		be modified outside the IETF Standards Process, and derivative
	not be created outside the IETF Standards Process, except to format		works of it may not be created outside the IETF Standards Process,
	it for publication as an RFC or to translate it into languages other		except to format it for publication as an RFC or to translate it
	than English.		into languages other than English.
End of changes. 22 change blocks.
	79 lines changed or deleted		76 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/