< draft-zhao-mpls-rsvp-te-multi-topology-00.txt		draft-zhao-mpls-rsvp-te-multi-topology-01.txt >
	Internet Engineering Task Force Q. Zhao		Internet Engineering Task Force Quintin Zhao
	Internet-Draft H. Chen		Internet-Draft Huawei Technology
	Intended status: Standards Track Huawei Technology		Intended status: Standards Track Chao Zhou
	Expires: January 7, 2011 N. So		Expires: September 13, 2011 Luyuan Fang
	Verison Business
	L. Fang
	C. Zhou
	Cisco Systems		Cisco Systems
	L. Li		Lianyuan Li
	China Mobile		China Mobile
	R. Torvi		Ning So
			Verison Business
			Raveendra Torvi
	Juniper Networks		Juniper Networks
	July 6, 2010		March 12, 2011
	RSVP-TE Extension for Multi Topology Support		RSVP-TE Extension for Multi Topology Support
	draft-zhao-mpls-rsvp-te-multi-topology-00.txt		draft-zhao-mpls-rsvp-te-multi-topology-01.txt
	Abstract		Abstract
	This document describes options to extend the existing MPLS		This document describes options to extend the existing MPLS
	signalling protocol RSVP for creating and maintaining Label Switching		signalling protocol RSVP for creating and maintaining Label Switching
	Paths (LSPs) in a Multi-Topology environments.		Paths (LSPs) in a Multi-Topology environments.
	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
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 40 ¶
	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 January 7, 2011.		This Internet-Draft will expire on September 13, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2011 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 2, line 21 ¶		skipping to change at page 2, line 24 ¶
	Table of Contents		Table of Contents
	1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Application Scenarios . . . . . . . . . . . . . . . . . . . . 4		3. Application Scenarios . . . . . . . . . . . . . . . . . . . . 4
	3.1. Simplified Data-plane . . . . . . . . . . . . . . . . . . 5		3.1. Simplified Data-plane . . . . . . . . . . . . . . . . . . 5
	3.2. Automation of inter-layer interworking . . . . . . . . . . 5		3.2. Automation of inter-layer interworking . . . . . . . . . . 5
	3.3. Migration without service disruption . . . . . . . . . . . 6		3.3. Migration without service disruption . . . . . . . . . . . 6
	3.4. Service Separation . . . . . . . . . . . . . . . . . . . . 6		3.4. Service Separation . . . . . . . . . . . . . . . . . . . . 6
	4. Associating a RSVP message with MT-ID . . . . . . . . . . . . 6		3.5. simplified Inter Domain TE LSP Setup . . . . . . . . . . . 6
			3.6. Simplified inter-AS VPN Solution . . . . . . . . . . . . . 6
			4. Associating a RSVP message with MT-ID . . . . . . . . . . . . 7
	4.1. Session Object . . . . . . . . . . . . . . . . . . . . . . 7		4.1. Session Object . . . . . . . . . . . . . . . . . . . . . . 7
	4.1.1. P2P LSP TUNNEL IPv4 Session Object . . . . . . . . . . 7		4.1.1. P2P LSP TUNNEL IPv4 Session Object . . . . . . . . . . 7
	4.1.2. P2P LSP TUNNEL IPv6 Session Object . . . . . . . . . . 8		4.1.2. P2P LSP TUNNEL IPv6 Session Object . . . . . . . . . . 8
	4.1.3. P2MP LSP TUNNEL IPv4 Session Object . . . . . . . . . 9		4.1.3. P2MP LSP TUNNEL IPv4 Session Object . . . . . . . . . 10
	4.1.4. P2MP LSP TUNNEL IPv6 Session Object . . . . . . . . . 10		4.1.4. P2MP LSP TUNNEL IPv6 Session Object . . . . . . . . . 11
	5. Processing of Message with MT ID . . . . . . . . . . . . . . . 10		5. Processing of Message with MT ID . . . . . . . . . . . . . . . 11
	6. MPLS Forwarding in MT . . . . . . . . . . . . . . . . . . . . 10		6. MPLS Forwarding in MT . . . . . . . . . . . . . . . . . . . . 11
	6.1. Use Label for (FEC, MT-ID) Tuple . . . . . . . . . . . . . 10		6.1. Use Label for (FEC, MT-ID) Tuple . . . . . . . . . . . . . 11
	6.2. Overlapping Label Spaces for MT . . . . . . . . . . . . . 11		6.2. Overlapping Label Spaces for MT . . . . . . . . . . . . . 12
	7. Reserved MT ID Values . . . . . . . . . . . . . . . . . . . . 12		7. Reserved MT ID Values . . . . . . . . . . . . . . . . . . . . 13
	8. Security Consideration . . . . . . . . . . . . . . . . . . . . 12		8. Security Consideration . . . . . . . . . . . . . . . . . . . . 13
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12		10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 13		11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	11.2. Informative References . . . . . . . . . . . . . . . . . . 13		11.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Terminology		1. Terminology
	Terminology used in this document		Terminology used in this document
	MT-ID: A 12 bit value to represent Multi-Topology ID.		MT-ID: A 12 bit value to represent Multi-Topology ID.
	Default Topology: A topology that is built using the MT-ID value		Default Topology: A topology that is built using the MT-ID value
	0.		0.
	skipping to change at page 6, line 34 ¶		skipping to change at page 6, line 34 ¶
	3.4. Service Separation		3.4. Service Separation
	MPLS-MT procedures allow establishing two distinct LSPs for the same		MPLS-MT procedures allow establishing two distinct LSPs for the same
	FEC, by advertising separate label mapping for each configured		FEC, by advertising separate label mapping for each configured
	topology. Service providers can implement CoS using MPLS-MT		topology. Service providers can implement CoS using MPLS-MT
	procedures without requiring to create separate FEC address for each		procedures without requiring to create separate FEC address for each
	class. MPLS-MT can also be used separate multicast and unicast		class. MPLS-MT can also be used separate multicast and unicast
	traffic.		traffic.
			3.5. simplified Inter Domain TE LSP Setup
			When the TE lsp is crossing multiple domains, the LSP setup process
			can be simplified by configuring a set of routers which are in
			different domains into a new single domain with a new toplogy ID
			using the RSVP-TE multiple topology. All the routers belong this new
			topology will be used to carry the traffic acrossing multiple domains
			and since they are in a sinle domain, so the TE lsp set up can be
			done easily.
			3.6. Simplified inter-AS VPN Solution
			When the TE lsp is crossing multiple domains for the inter-as VPN
			scenarios, the LSP setup process can be simplified by configuring a
			set of routers which are in different domains into a new single
			domain with a new toplogy ID using the LDP multiple topology. All
			the routers belong this new topology will be used to carry the
			traffic acrossing multiple domains and since they are in a sinle
			domain with the new topology ID, so the TE lsp set up can be done
			easily without the complex inter-as VPN solution's option A, option B
			and option C.
	4. Associating a RSVP message with MT-ID		4. Associating a RSVP message with MT-ID
	RSVP-TE objects may be utilized to indicate MT information by adding		RSVP-TE objects may be utilized to indicate MT information by adding
	the multi-topology information in an RSVP-TE object carried in a		the multi-topology information in an RSVP-TE object carried in a
	RSVP-TE message.		RSVP-TE message.
	A preferred RSVP-TE object may be a session object.		A preferred RSVP-TE object may be a session object.
	The capability for supporting multi-topology in RSVP can be		The capability for supporting multi-topology in RSVP can be
	advertised during RSVP session initialization stage by including the		advertised during RSVP session initialization stage by including the
	skipping to change at page 15, line 4 ¶		skipping to change at page 16, line 4 ¶
	Email: czhou@cisco.com		Email: czhou@cisco.com
	Lianyuan Li		Lianyuan Li
	China Mobile		China Mobile
	53A, Xibianmennei Ave.		53A, Xibianmennei Ave.
	Xunwu District, Beijing 01719		Xunwu District, Beijing 01719
	China		China
	Email: lilianyuan@chinamobile.com		Email: lilianyuan@chinamobile.com
			Lu Huang
			China Mobile
			53A, Xibianmennei Ave.
			Xunwu District, Beijing 01719
			China
			Email: huanglu@chinamobile.com
			Chen Li
			China Mobile
			53A, Xibianmennei Ave.
			Xunwu District, Beijing 01719
			China
			Email: lichenyj@chinamobile.com
	Raveendra Torvi		Raveendra Torvi
	Juniper Networks		Juniper Networks
	10, Technoogy Park Drive		10, Technoogy Park Drive
	Westford, MA 01886-3140		Westford, MA 01886-3140
	US		US
	Email: pratiravi@juniper.com		Email: pratiravi@juniper.com
End of changes. 11 change blocks.
	28 lines changed or deleted		67 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/