< draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt		draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt >
	Network Working Group M. Chen		Network Working Group M. Chen
	Internet-Draft W. Cao		Internet-Draft W. Cao
	Intended status: Standards Track Huawei Technologies Co., Ltd		Intended status: Standards Track Huawei
	Expires: June 1, 2014 A. Takacs		Expires: March 16, 2015 A. Takacs
	Ericsson		Ericsson
	P. Pan		P. Pan
	Infinera		Infinera
	November 28, 2013		September 12, 2014
	LDP extensions for Pseudowire Binding to LSP Tunnels		LDP extensions for Pseudowire Binding to LSP Tunnels
	draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt		draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt
	Abstract		Abstract
	Many transport services require that user traffic, in the forms of		Many transport services require that user traffic, in the forms of
	Pseudowires (PW), to be delivered on a single co-routed bidirectional		Pseudowires (PW), to be delivered on a single co-routed bidirectional
	LSP or two LSPs that share the same routes. In addition, the user		LSP or two LSPs that share the same routes. In addition, the user
	traffic may traverse through multiple transport networks.		traffic may traverse through multiple transport networks.
	This document specifies an optional extension in LDP that enable the		This document specifies an optional extension in LDP that enable the
	binding between PWs and the underlying LSPs.		binding between PWs and the underlying LSPs.
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 1, 2014.		This Internet-Draft will expire on March 16, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the
			Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 4		2. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. PSN Tunnel Binding TLV . . . . . . . . . . . . . . . . . 5		2.1. PSN Tunnel Binding TLV . . . . . . . . . . . . . . . . . 5
	2.1.1. PSN Tunnel Sub-TLV . . . . . . . . . . . . . . . . . 6		2.1.1. PSN Tunnel Sub-TLV . . . . . . . . . . . . . . . . . 6
	3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 7		3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 8
	4. PSN Binding Operation for SS-PW . . . . . . . . . . . . . . . 8		4. PSN Binding Operation for SS-PW . . . . . . . . . . . . . . . 9
	5. PSN Binding Operation for MS-PW . . . . . . . . . . . . . . . 10		5. PSN Binding Operation for MS-PW . . . . . . . . . . . . . . . 11
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	7.1. LDP TLV Types . . . . . . . . . . . . . . . . . . . . . . 12		7.1. LDP TLV Types . . . . . . . . . . . . . . . . . . . . . . 13
	7.1.1. PSN Tunnel Sub-TLVs . . . . . . . . . . . . . . . . . 12		7.1.1. PSN Tunnel Sub-TLVs . . . . . . . . . . . . . . . . . 13
	7.2. LDP Status Codes . . . . . . . . . . . . . . . . . . . . 13		7.2. LDP Status Codes . . . . . . . . . . . . . . . . . . . . 13
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	9.1. Normative References . . . . . . . . . . . . . . . . . . 13		9.1. Normative References . . . . . . . . . . . . . . . . . . 13
	9.2. Informative References . . . . . . . . . . . . . . . . . 13		9.2. Informative References . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	Pseudowire (PW) Emulation Edge-to-Edge (PWE3) [RFC3985] is a		Pseudowire (PW) Emulation Edge-to-Edge (PWE3) [RFC3985] is a
	mechanism to emulate layer 2 services, such as Ethernet Point-to-		mechanism to emulate layer 2 services, such as Ethernet Point-to-
	Point (P2P) circuits. Such services are emulated between two		Point (P2P) circuits. Such services are emulated between two
	Attachment Circuits (ACs) and the PW encapsulated layer 2 service		Attachment Circuits (ACs) and the PW encapsulated layer 2 service
	payload is carried through Packet Switching Network (PSN) tunnels		payload is carried through Packet Switching Network (PSN) tunnels
	between Provider Edges (PEs). PWE3 typically uses Label Distribution		between Provider Edges (PEs). PWE3 typically uses Label Distribution
	skipping to change at page 9, line 4 ¶		skipping to change at page 9, line 19 ¶
	setup using FEC 129.		setup using FEC 129.
	4. PSN Binding Operation for SS-PW		4. PSN Binding Operation for SS-PW
	As illustrated in Figure-5, both PEs (say, PE1 and PE2) of a PW may		As illustrated in Figure-5, both PEs (say, PE1 and PE2) of a PW may
	independently initiate the setup. To perform PSN binding, the Label		independently initiate the setup. To perform PSN binding, the Label
	Mapping messages MUST carry a PSN Tunnel Binding TLV, and the PSN		Mapping messages MUST carry a PSN Tunnel Binding TLV, and the PSN
	Tunnel sub-TLV MUST contains the desired tunnel/LSPs of the sender.		Tunnel sub-TLV MUST contains the desired tunnel/LSPs of the sender.
	+----+ LSP1 +----+		+----+ LSP1 +----+
	+-----+ | PE1|====================| PE2| +-----+		+-----+ | PE1|====================| PE2| +-----+
	| |----| | | |----| |		| |----| | | |----| |
	| CE1 | |............PW................| | CE2 |		| CE1 | |............PW................| | CE2 |
	| |----| | | |----| |		| |----| | | |----| |
	+-----+ | |====================| | +-----+		+-----+ | |====================| | +-----+
	+----+ LSP2 +----+		+----+ LSP2 +----+
	Figure 6: PSN binding operation in SS-PW environment		Figure 6: PSN binding operation in SS-PW environment
	As outlined previously, there are two types of binding request: co-		As outlined previously, there are two types of binding request: co-
	routed and strict.		routed and strict.
	In strict binding, a PE (e.g., PE1) will mandate the other PE (e.g.,		In strict binding, a PE (e.g., PE1) will mandate the other PE (e.g.,
	PE2) to use a specified tunnel/LSP (e.g. LSP1) as the PSN tunnel on		PE2) to use a specified tunnel/LSP (e.g. LSP1) as the PSN tunnel on
	the reverse direction. In the PSN Tunnel Binding TLV, the S-bit MUST		the reverse direction. In the PSN Tunnel Binding TLV, the S-bit MUST
	be set, the C-bit MUST be reset, and the Source and Destination IDs/		be set, the C-bit MUST be reset, and the Source and Destination IDs/
	Numbers MUST be filled.		Numbers MUST be filled.
	On receive, if the S-bit is set, other than following the processing		On receive, if the S-bit is set, other than following the processing
	procedure defined in Section 5.3.3 of [RFC4447], the receiving PE		procedure defined in Section 5.3.3 of [RFC4447], the receiving PE
	(i.e. PE2) needs to determine whether to accept the indicated tunnel/		(i.e. PE2) needs to determine whether to accept the indicated
	LSP in PSN Tunnel Sub-TLV.		tunnel/LSP in PSN Tunnel Sub-TLV.
	If the receiving PE (PE2) is also an active PE, and may have		If the receiving PE (PE2) is also an active PE, and may have
	initiated the PSN binding requests to the other PE (PE1), if the		initiated the PSN binding requests to the other PE (PE1), if the
	received PSN tunnel/LSP is the same as it has been sent in the Label		received PSN tunnel/LSP is the same as it has been sent in the Label
	Mapping message by PE2, then the signaling has converged on a		Mapping message by PE2, then the signaling has converged on a
	mutually agreed Tunnel/LSP. The binding operation is completed.		mutually agreed Tunnel/LSP. The binding operation is completed.
	Otherwise, the receiving PE (PE2) MUST compare its own Node ID		Otherwise, the receiving PE (PE2) MUST compare its own Node ID
	against the received Source Node ID. If it is numerically lower, the		against the received Source Node ID. If it is numerically lower, the
	PE (PE2) will reply a Label Mapping message to complete the PW setup		PE (PE2) will reply a Label Mapping message to complete the PW setup
	skipping to change at page 13, line 43 ¶		skipping to change at page 14, line 13 ¶
	Distribution Protocol (LDP)", RFC 4447, April 2006.		Distribution Protocol (LDP)", RFC 4447, April 2006.
	[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.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-pwe3-dynamic-ms-pw]		[I-D.ietf-pwe3-dynamic-ms-pw]
	Martini, L., Bocci, M., and F. Balus, "Dynamic Placement		Martini, L., Bocci, M., and F. Balus, "Dynamic Placement
	of Multi-Segment Pseudowires", draft-ietf-pwe3-dynamic-ms-		of Multi-Segment Pseudowires", draft-ietf-pwe3-dynamic-ms-
	pw-19 (work in progress), October 2013.		pw-22 (work in progress), March 2014.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP		and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, December 2001.		Tunnels", RFC 3209, December 2001.
	[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching		[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
	(GMPLS) Signaling Functional Description", RFC 3471,		(GMPLS) Signaling Functional Description", RFC 3471,
	January 2003.		January 2003.
	[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching		[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
	skipping to change at page 14, line 28 ¶		skipping to change at page 14, line 46 ¶
	[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.		[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
	Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.		Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.
	[RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E.		[RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E.
	Gray, "MPLS Transport Profile (MPLS-TP) Control Plane		Gray, "MPLS Transport Profile (MPLS-TP) Control Plane
	Framework", RFC 6373, September 2011.		Framework", RFC 6373, September 2011.
	Authors' Addresses		Authors' Addresses
	Mach(Guoyi) Chen		Mach(Guoyi) Chen
	Huawei Technologies Co., Ltd		Huawei
	Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District
	Beijing 100095
	China
	Email: mach.chen@huawei.com		Email: mach.chen@huawei.com
	Wei Cao		Wei Cao
	Huawei Technologies Co., Ltd		Huawei
	Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District
	Beijing 100095
	China
	Email: wayne.caowei@huawei.com		Email: wayne.caowei@huawei.com
	Attila Takacs		Attila Takacs
	Ericsson		Ericsson
	Laborc u. 1.		Laborc u. 1.
	Budapest 1037		Budapest 1037
	Hungary		Hungary
	Email: attila.takacs@ericsson.com		Email: attila.takacs@ericsson.com
End of changes. 15 change blocks.
	27 lines changed or deleted		20 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/