< draft-sprecher-mpls-tp-migration-03.txt		draft-sprecher-mpls-tp-migration-04.txt >
	Network Working Group N. Sprecher		Network Working Group N. Sprecher
	Internet-Draft Y. Weingarten		Internet-Draft Y. Weingarten
	Intended status: Informational Nokia Siemens Networks		Intended status: Informational Nokia Siemens Networks
	Expires: July 8, 2011 K. Hong		Expires: December 25, 2011 K. Hong
	L. Fang		L. Fang
	Cisco Systems, Inc.		Cisco Systems, Inc.
	January 4, 2011		June 23, 2011
	Migration Considerations and Techniques for Multiprotocol Label		Migration Considerations and Techniques for Multiprotocol Label
	Switching Transport Profile based Networks and Services		Switching Transport Profile based Networks and Services
	draft-sprecher-mpls-tp-migration-03.txt		draft-sprecher-mpls-tp-migration-04.txt
	Abstract		Abstract
	MPLS-TP defines a packet-based network architecture and a		MPLS-TP defines a packet-based network architecture and a
	comprehensive set of tools that allow service providers to reliably		comprehensive set of tools that allow service providers to reliably
	deliver next generation services and applications, in a simple,		deliver next generation services and applications, in a simple,
	scalable, and cost-effective way. Such services are BW-hungry based		scalable, and cost-effective way. Such services are BW-hungry based
	and require strict guaranteed SLA. Delivering next generation		and require strict guaranteed SLA. Delivering next generation
	services over an MPLS-TP based network in an economic way, enables		services over an MPLS-TP based network in an economic way, enables
	service providers to remain competitive while increasing their		service providers to remain competitive while increasing their
	skipping to change at page 1, line 49 ¶		skipping to change at page 1, line 49 ¶
	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 July 8, 2011.		This Internet-Draft will expire on December 25, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 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
	skipping to change at page 3, line 12 ¶		skipping to change at page 3, line 12 ¶
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Overview of MPLS-TP . . . . . . . . . . . . . . . . . . . 4		1.1. Overview of MPLS-TP . . . . . . . . . . . . . . . . . . . 4
	1.2. Motivations for Upgrading Networks . . . . . . . . . . . . 5		1.2. Motivations for Upgrading Networks . . . . . . . . . . . . 5
	2. Terminology and References . . . . . . . . . . . . . . . . . . 6		2. Terminology and References . . . . . . . . . . . . . . . . . . 6
	2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6		2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. General Migration Strategies . . . . . . . . . . . . . . . . . 7		3. General Considerations and Strategies . . . . . . . . . . . . 7
	3.1. Island model . . . . . . . . . . . . . . . . . . . . . . . 8		3.1. Migration models . . . . . . . . . . . . . . . . . . . . . 8
	3.2. Phased model . . . . . . . . . . . . . . . . . . . . . . . 9		3.1.1. Island model . . . . . . . . . . . . . . . . . . . . . 8
	3.3. Integrated model . . . . . . . . . . . . . . . . . . . . . 10		3.1.2. Phased model . . . . . . . . . . . . . . . . . . . . . 10
	4. Migrating from TDM . . . . . . . . . . . . . . . . . . . . . . 11		3.1.3. Integrated model . . . . . . . . . . . . . . . . . . . 11
	4.1. Main motivation . . . . . . . . . . . . . . . . . . . . . 11		3.2. Migration strategies . . . . . . . . . . . . . . . . . . . 13
	4.2. Migration Activities and Techniques . . . . . . . . . . . 11		4. Migrating from TDM . . . . . . . . . . . . . . . . . . . . . . 13
	5. Migrating from ATM . . . . . . . . . . . . . . . . . . . . . . 11		4.1. Main motivation . . . . . . . . . . . . . . . . . . . . . 13
	5.1. Main motivation . . . . . . . . . . . . . . . . . . . . . 11		4.2. Migration Activities and Techniques . . . . . . . . . . . 13
	5.2. Migration activities and Techniques . . . . . . . . . . . 11		5. Migrating from ATM . . . . . . . . . . . . . . . . . . . . . . 14
	6. Migrating from Ethernet . . . . . . . . . . . . . . . . . . . 11		5.1. Main motivation . . . . . . . . . . . . . . . . . . . . . 14
	6.1. Main motivation . . . . . . . . . . . . . . . . . . . . . 11		5.2. Migration activities and Techniques . . . . . . . . . . . 14
	6.2. Migration activities and Techniques . . . . . . . . . . . 11		6. Migrating from Ethernet . . . . . . . . . . . . . . . . . . . 14
	7. Migrating from MPLS . . . . . . . . . . . . . . . . . . . . . 11		6.1. Main motivation . . . . . . . . . . . . . . . . . . . . . 14
	7.1. MPLS-TE . . . . . . . . . . . . . . . . . . . . . . . . . 11		6.2. Migration activities and Techniques . . . . . . . . . . . 14
	7.1.1. Main motivation . . . . . . . . . . . . . . . . . . . 11		7. Migrating from MPLS . . . . . . . . . . . . . . . . . . . . . 15
	7.1.2. Migration activities and Techniques . . . . . . . . . 11		7.1. General note on migrating MPLS . . . . . . . . . . . . . . 15
	7.2. IP/MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 11		7.2. MPLS-TE . . . . . . . . . . . . . . . . . . . . . . . . . 15
	7.2.1. Main motivation . . . . . . . . . . . . . . . . . . . 11		7.2.1. Main motivation . . . . . . . . . . . . . . . . . . . 15
	7.2.2. Migration activities and Techniques . . . . . . . . . 11		7.2.2. Migration activities and Techniques . . . . . . . . . 15
	8. Migrating from pre-standard MPLS-TP (T-MPLS) . . . . . . . . . 11		7.3. IP/MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 15
	8.1. Main motivation . . . . . . . . . . . . . . . . . . . . . 11		7.3.1. Main motivation . . . . . . . . . . . . . . . . . . . 15
	8.2. Migration activities and Techniques . . . . . . . . . . . 11		7.3.2. Migration activities and Techniques . . . . . . . . . 15
	9. Manageability Considerations . . . . . . . . . . . . . . . . . 12		8. Migrating from pre-standard MPLS-TP (T-MPLS) . . . . . . . . . 16
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 12		8.1. Main motivation . . . . . . . . . . . . . . . . . . . . . 16
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		8.2. Migration activities and Techniques . . . . . . . . . . . 16
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		9. Manageability Considerations . . . . . . . . . . . . . . . . . 16
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 12		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	13.2. Informative References . . . . . . . . . . . . . . . . . . 12		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
			13.1. Normative References . . . . . . . . . . . . . . . . . . . 16
			13.2. Informative References . . . . . . . . . . . . . . . . . . 17
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	Editors' Note:		Editors' Note:
	This Informational Internet-Draft is aimed at achieving IETF		This Informational Internet-Draft is aimed at achieving IETF
	Consensus before publication as an RFC and will be subject to an IETF		Consensus before publication as an RFC and will be subject to an IETF
	Last Call.		Last Call.
	[RFC Editor, please remove this note before publication as an RFC and		[RFC Editor, please remove this note before publication as an RFC and
	insert the correct Streams Boilerplate to indicate that the published		insert the correct Streams Boilerplate to indicate that the published
	RFC has IETF Consensus.]		RFC has IETF Consensus.]
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 5 ¶
	2. Terminology and References		2. Terminology and References
	2.1. Acronyms		2.1. Acronyms
	This draft uses the following acronyms:		This draft uses the following acronyms:
	MPLS-TP Multiprotocol Label Switching - Transport Protocol		MPLS-TP Multiprotocol Label Switching - Transport Protocol
	OAM Operations, Administration, and Maintenance		OAM Operations, Administration, and Maintenance
	3. General Migration Strategies		3. General Considerations and Strategies
			A migration strategy is necessary for service providers to ensure the
			smooth migration process in a cost-efficient and scalable way.
			Smooth migration is required to enable service providers to maintain
			their existing investments in the installed base for as long as
			economically justifiable.
			Smooth migration is required to enable service providers to maintain
			their existing investments in the installed base for as long as
			economically justifiable.
			For service providers, smooth migration path and seamless
			interworking between the installed networks and the MPLS-TP based
			network, also eliminates the risks associated with fork-lifting a
			new-technology or implementation upgrade onto the whole network in
			one day. Such an approach allows service providers to ensure that
			the new implementations work as expected in live networks and that
			the customers' quality of experience is maintained and not affected.
	A migration strategy is necessary for service providers to maintain
	their installed base and minimize the investment in new equipment.
	The migration should be a smooth and seamless transfer of technology		The migration should be a smooth and seamless transfer of technology
	while continuing to support the services that generate the revenues.		while continuing to support the services that generate the revenues.
	This means that the migration strategy should address the following		This means that the migration strategy should address the following
	considerations:		considerations:
	o Cost-effective - Minimize the number of migration steps, stay		o Cost-effective - Minimize the number of migration steps, stay
	within budget for both operating (OPEX) and capital (CAPEX)		within budget for both operating (OPEX) and capital (CAPEX)
	expenses.		expenses.
	o Service continuity - perform the switchover without a service		o Service continuity - perform the switchover without a service
	break to existing customers and their services.		break to existing customers and their services. Service
			performance, availability and subscriber experience should
			reaminremain unaffected.
	o Provide a reliable fall-back - don't burn your bridges until the		o Provide a reliable fall-back - don't burn your bridges until the
	new connections are secure and robust enough to maintain the		new connections are secure and robust enough to maintain the
	service-level agreements.		service-level agreements.
	o Minimum switchover time - when everything is in place need to		o Minimum switchover time - when everything is in place need to
	minimize the side-effects by minimizing the time needed to have		minimize the side-effects by minimizing the time needed to have
	the new service platform performing.		the new service platform performing.
	o Aspects of data-plane, OAM and recovery mechanisms, control plane		o Aspects of data-plane, OAM and recovery mechanisms, control plane
	and management-plane		and management-plane
	Different migration models have been discussed in the literature.		Different migration models have been discussed in the literature,
	The most basic model, forklifting the new technology, in our case		each with distinct advantages and disadvantages. The most basic
	MPLS-TP, onto the network involves simultaneously upgrading the		model, forklifting the new technology, in our case MPLS-TP, onto the
	entire network to work with the new technology. This type of		network involves simultaneously upgrading the entire network to work
	migration is very risky if the new technology does not work as		with the new technology. This type of migration is very risky if the
	expected in the live network after disabling the legacy technology.		new technology does not work as expected in the live network after
	In order to minimize the risk, it could be possible to install an		disabling the legacy technology. In order to minimize the risk, it
	entire parallel network based on MPLS-TP and then switch over from		could be possible to install an entire parallel network based on
	the legacy network to the MPLS-TP network. However, this would be		MPLS-TP and then switch over from the legacy network to the MPLS-TP
	very costly, i.e. purchasing equipment for two parallel networks, and		network. However, this would be very costly, i.e. purchasing
	again could not guarantee that the new technology network would work		equipment for two parallel networks, and again could not guarantee
	as planned. This, in turn, would cause a major disruption of		that the new technology network would work as planned. This, in
	services. Therefore, in the following descriptions we concentrate on		turn, would cause a major disruption of services.
	the following models:
			Note that, theoretically, one could build an entire parallel network,
			switch the traffic over to the new network and then pull down the old
			network. It is complicated or even impossible to coordinate such an
			upgrade across the entire network.
			The forklift migration is neither practical nor recommended.
			However, it can be performed locally across a section of the network.
			In the following descriptions we concentrate on the following models:
	o Island model - introducing the MPLS-TP in separate sub-domains of		o Island model - introducing the MPLS-TP in separate sub-domains of
	the network. The transport paths may cross the different		the network. The transport paths may cross the different
	technology domains that are connected by gateways. See section		technology domains that are interconnected by gateways. See
	3.1 for more details.		section 3.1 for more details.
	o Phased model - where the existing equipment is slowly upgraded		o Phased model - where the existing equipment is slowly upgraded
	with new MPLS-TP capabilities as needed. For more details see		with new MPLS-TP capabilities as needed. For more details see
	section 3.2.		section 3.2.
	o Integrated model - network nodes are either legacy nodes or dual-		o Integrated model - network nodes are either legacy nodes or dual-
	mode nodes supporting both legacy and MPLS-TP capabilities. See		mode nodes supporting both legacy and MPLS-TP capabilities. See
	section 3.3 for more details.		section 3.3 for more details.
	It should be noted that not all of these models are relevant to		It should be noted that not all of these models are relevant to
	migration from specific legacy technologies. The relevance for each		migration from specific legacy technologies. The relevance for each
	technology of the particular migration model will be discussed in the		technology of the particular migration model will be discussed in the
	sections below that discuss the specific technologies.		sections below that discuss the specific technologies.
	3.1. Island model		3.1. Migration models
			3.1.1. Island model
	In this migration model presented previously in [RFC5145] the service		In this migration model presented previously in [RFC5145] the service
	provider introduces clusters of MPLS-TP nodes that are interconnected		provider introduces clusters of MPLS-TP nodes that are interconnected
	with the legacy clusters through border nodes. The border nodes act		with the legacy clusters through border nodes. The border nodes act
	as gateways, that are responsible for the mapping or adaptation of		as gateways, that are responsible for the mapping or adaptation of
	protocol elements that may be transmitted between legacy and MPLS-TP		protocol elements that may be transmitted between legacy and MPLS-TP
	nodes.		nodes.
			The island model is applicable when new pieces of network are
			introduced, or when a localized forklift is performed.
	End-to-end services may traverse between the islands. The		End-to-end services may traverse between the islands. The
	configuration of the transport paths may be "balanced" or		configuration of the transport paths may be "balanced" or
	"unbalanced". In a balanced path configuration both endpoints of the		"unbalanced". In a balanced path configuration both endpoints of the
	path are nodes of the same technology, but the path may have crossed		path are nodes of the same technology, but the path may have crossed
	islands of the other technology in the middle of the path, see		islands of the other technology in the middle of the path, see
	Figure 1. An unbalanced path configuration would be if the path		Figure 1. An unbalanced path configuration would be if the path
	starts at a node of one technology and ends at a node supporting the		starts at a node of one technology and ends at a node supporting the
	second technology, see Figure 1.		second technology, see Figure 1.
	+----+ +--+ +----+ +--+ +----+ +--+ +----+		+----+ +--+ +----+ +--+ +----+ +--+ +----+
	skipping to change at page 9, line 25 ¶		skipping to change at page 10, line 24 ¶
	|<----Island---->| |<---Island--->|		|<----Island---->| |<---Island--->|
	LN - one or more Legacy Nodes		LN - one or more Legacy Nodes
	TP - one or more MPLS-TP LSR		TP - one or more MPLS-TP LSR
	Brdr Gtwy - Border node that acts as gateway		Brdr Gtwy - Border node that acts as gateway
	Lgcy Conn - Legacy node that where service connects		Lgcy Conn - Legacy node that where service connects
	TP Conn - MPLS-TP LER		TP Conn - MPLS-TP LER
	Figure 2: Unbalanced island path		Figure 2: Unbalanced island path
	The tools that may be used at the border, gateway, nodes may be based		The tools that may be used at the border, gateway nodes may be based
	on either layered networks - only when using balanced islands, or on		on either layered networks or on an interworking or mapping between
	an interworking or mapping function between protocols. An MPLS-TP		protocols. The layered network (which may be seen also as an overlay
	island would provide the layered network solution through the use of		network) tools are applicable only in the case of Layered networks
	an LSP between TE-links to carry legacy traffic, when possible.		are used to separate the domains belonging to different technologies.
			MPLS-TP LSPs provide TE-links to carry legacy traffic. The gateways
			adapt the legacy traffic and multiplex it over the TE-links. When
			interconnection is based on interworking or mapping tools, service or
			network interworking is used between the islands through gateways
			which are responsible for mapping protocols&apos elements.
	This model is very useful when upgrading the network in stages, where		This model is very useful when upgrading the network in stages, where
	new MPLS-TP equipment is upgraded in clusters that form an island.		new MPLS-TP equipment is upgraded in clusters that form an island.
	These islands can be slowly expanded and merged until they create a		These islands can be slowly expanded and merged until they create a
	single MPLS-TP network. Whenever the islands are expanded or merged		single MPLS-TP network. Whenever the islands are expanded or merged
	make-before-break procedures should be employed in order to keep		make-before-break procedures should be employed in order to keep
	services running.		services running.
	3.2. Phased model		3.1.2. Phased model
	In this model the existing equipment is upgraded with the features		In this model the existing equipment is upgraded with the features
	and functionality of the new technology. The new functionality is		and functionality of the new technology. The new functionality is
	introduced as needed, while ensuring interoperability with the legacy		introduced as needed, while ensuring interoperability with the legacy
	technology. This is highly dependent upon the equipment to support		technology. This is highly dependent upon the possibility to upgrade
	the new functionality and the support of all the vendors to implement		the equipment, either software or firmware, to support the new
	the same functionality.		functionality and upon the support of equipment from different
			vendors for the same set of capabilities.
	The advantage of this model is that it allows the service provider to		The advantage of this model is that it allows the service provider to
	quickly support enhanced capabilities on his existing equipment.		quickly support enhanced capabilities on his existing equipment.
	However, this model is not applicable to all legacy technologies.		However, this model is not applicable to all legacy technologies.
	For this to work the new capabilities need to be backward compatible		For this to work the new capabilities need to be backward compatible
	with the legacy technology, and all of the vendors, involved in the		with the legacy technology, and all of the vendors, involved in the
	migration, need to implement the new capabilities specified by the		migration, need to implement the new capabilities specified by the
	service provider.		service provider.
	3.3. Integrated model		3.1.3. Integrated model
	This model allows the operator to run services over two clouds of the		This model allows a network to have new "dual-mode" nodes, which
	network simultaneously. One cloud would continue to support the		support integrated MPLS-TP and legacy functionality, in the legacy
	legacy technology, while the second cloud would support the new		networks, as is depicted in Figure 3.
	MPLS-TP services. The services would be routed to the proper cloud
	by new "dual-mode" nodes that would support an integrated MPLS-TP and
	legacy functionality, see Figure 3. These dual-mode nodes would
	route the different services to the paths in the different technology
	clouds. This avoids the need for interworking that is required in
	the island model described in section 3.1.
	______________________________________		A mandatory requirement in this model is that the MPLS-TP and the
	_/ Service Provider's Network \		legacy technologies can co-exist in the same network. There is no
	/ ____ ___ ____ \___		requirement for interworking.
	_/ _/ \___/ \ _/ \__ \
	/ / \__/ ... \_ \___
	/ / ....... ... \ \
	| +--------| ...Legacy Logical Network .. |---+ |
	| |.........\.. .. .. ../....| |
	| |. \ ___.... ___ __ _/ .| |
	| +----+ \_/ \____/ \___/ \____/ +----+ |
	....|Dual| |Dual|...
	| | | | | |
	****|Mode| ____ ___ ____ |Mode|***
	| +----+ _/ \___/ \ _/ \__ +----+ |
	\ | * / \__/ \_ *| |
	\ | ******* /*** **\****| /
	\ +--------| ***MPLS-TP Logical Ntwrk*** |---+ /
	\____ \ *** ***** ***** / |
	\ \ ___ ****___ ***__ _/ /
	\ \_/ \____/ \___/ \____/ ___/
	\____________________________________/
	.... - Legacy service path		Existing services would be routed either through legacy nodes or
	**** - MPLS-TP service path		through the new dual-mode nodes. New services would be routed
			through new dual-mode nodes.
			-----------------------------------------
			| --- --- --- --- |
			| | L |---| L |---| L |---| L | |
			| --- --- --- --- |
			| \ / |
			| \ / |
			| \ / |
			| \ --- / --- --- |
			| | L |---| L |---| L | |
			| /| T |...| T |...| T | |
			| / --- --- --- |
			| / : : |
			| --- / : : |
			| | L |/ --- --- |
			| | T |.....| T |...........| T | |
			| --- --- --- |
			| : : |
			| : : |
			| --- --- --- --- |
			| | T |....| T |....| T |...| T | |
			| --- --- --- --- |
			| |
			-----------------------------------------
			Key:
			---
			| L | Legacy Node
			---
			---
			| D | Dual-Stack Node
			---
			---
			| T | MPLS-TP Node
			---
			--- Legacy MPLS LSP
			... MPLS-TP OAM-capable LSP
	Figure 3: Integrated model network		Figure 3: Integrated model network
	Gradual migration is supported by this model. The dual-mode nodes		Gradual migration is supported by this model. The dual-mode nodes
	are either legacy nodes that are upgraded to support MPLS-TP		are either legacy nodes that are upgraded to support MPLS-TP
	functionality. Services can be switched gradually from the legacy		functionality. Services can be switched gradually from the legacy
	transport paths to the MPLS-TP paths as they become available, using		transport paths to the MPLS-TP paths as they become available, using
	make-before-break procedures. Eventually, as all the service paths		make-before-break procedures. Eventually, as all the service paths
	are transferred to MPLS-TP the legacy technology cloud can be taken		are transferred to MPLS-TP the legacy technology cloud can be
	off-line.		switched off. New devices will support MPLS-TP functionality only.
			3.2. Migration strategies
			The migration process will be a gradual process and it should be
			tailored for each service provider&aposs network. Minimizing risks,
			controlling costs, and recognizing the impact on the end-customer are
			complicating factors that create a myriad of challenges to be
			addressed, monitored, measured and managed throughout the entire
			migration process.
			The network migration process, as well as the operation and
			management, and policy during the migration process needs to be
			planned.
			When selecting a migration model and defining the migration steps,
			issues such as the following need to be considered and evaluated:
			o Existing deployed networks and services.
			o Service provider&aposs network deployment plans and objectives
			(including the need for investment protection, window for the
			migration time, etc.).
			o Effects on the network operation, management costs.
			o Risks and reliable fallback.
			o End-customers&apos demand.
			o Security and operational policy
	4. Migrating from TDM		4. Migrating from TDM
	4.1. Main motivation		4.1. Main motivation
	4.2. Migration Activities and Techniques		4.2. Migration Activities and Techniques
			When considering the different strategies outlined in section 3 in
			relationship to migration from TDM-based networks, the service
			provider will need to realize that this type of migration involves a
			hardware upgrade for the network equipment. This indicates that it
			is not practical to plan a phased migration, that is based on
			upgrading the existing network elements.
			An integrated model migration would be a good candidate for this type
			of migration. The plan would involve installing dual-mode TDM/MPLS
			nodes into the network. Continuing the support of voice and control
			(e.g. timing information) traffic over the TDM sub-network, while
			simultaneously using the MPLS-TP capabilities to support existing and
			new data services. Transferring the existing data services would use
			make-before-break procedures defined by MPLS. As more and more
			services are transferred to the MPLS-TP environment native MPLS-TP
			nodes can be supported
			Another candidate for implementing a graduated migration strategy
			would be based on the Island model. The service provider would
			install new MPLS-TP nodes in well defined clusters within the
			network. Dual-mode border nodes would be used to interconnect
			between the native TDM islands that would support existing services
			and the MPLS-TP islands.
	5. Migrating from ATM		5. Migrating from ATM
	5.1. Main motivation		5.1. Main motivation
	5.2. Migration activities and Techniques		5.2. Migration activities and Techniques
	6. Migrating from Ethernet		6. Migrating from Ethernet
	6.1. Main motivation		6.1. Main motivation
	6.2. Migration activities and Techniques		6.2. Migration activities and Techniques
	7. Migrating from MPLS		When considering the different strategies outlined in section 3 in
			relationship to migration from Ethernet-based networks, the service
			provider will need to realize that this type of migration involves a
			hardware upgrade for the network equipment. This indicates that it
			is not practical to plan a phased migration, that is based on
			upgrading the existing network elements.
	7.1. MPLS-TE		An integrated model migration would be a good candidate for this type
			of migration. Both Ethernet and MPLS-TP can exist side-by-side
			within the network. In addition, it is possible to install dual-mode
			nodes that can support both Ethernet services and MPLS over Ethernet
			services. Continuing the support of legacy services over the
			Ethernet sub-network, while simultaneously using the MPLS-TP
			capabilities to slowly encapsulate some of these existing legacy
			(over either PWs or L2VPN structures) and support new data services.
			Transferring the existing data services would use make-before-break
			procedures defined by MPLS. As more and more services are
			transferred to the MPLS-TP environment native MPLS-TP nodes can be
			supported
	7.1.1. Main motivation		Another candidate for implementing a graduated migration strategy
			would be based on the Island model. The service provider would
			install new MPLS-TP nodes in well defined clusters within the
			network. Dual-mode border nodes would be used to interconnect
			between the native TDM islands that would support existing services
			and the MPLS-TP islands.
	7.1.2. Migration activities and Techniques		7. Migrating from MPLS
	7.2. IP/MPLS		7.1. General note on migrating MPLS
			MPLS-TP is a profile of the general MPLS toolkit which supports all
			of the tools required to ensure scalable, quality transport. Data
			services in MPLS-TP use the same forwarding mechanisms supported by
			standard MPLS. Many of the capabilities provided by MPLS-TP are
			already provided by MPLS and GMPLS, and there is no preclusion of
			using any of these capabilities in an MPLS-TP network.
			7.2. MPLS-TE
	7.2.1. Main motivation		7.2.1. Main motivation
	7.2.2. Migration activities and Techniques		7.2.2. Migration activities and Techniques
			7.3. IP/MPLS
			7.3.1. Main motivation
			7.3.2. Migration activities and Techniques
			As pointed out in the general note, MPLS-TP is a particular profile
			of the tools already supported by IP/MPLS. Therefore, for the most
			part, this migration is essentially a software upgrade of both the
			network equipment and possibly the management system. Any of the
			migration models presented in Section 3 are relevant candidates for
			implementing the migration plan from IP/MPLS to MPLS-TP.
			Gradually upgrading the MPLS network elements with the new MPLS-TP
			tools, by employing a phased migration plan, would enhance the
			general behavior of the network. This provides a very cost-effective
			switchover to the high-quality network service layer that is
			supported by the improved OAM tools of MPLS-TP.
			It is also possible to create islands of MPLS-TP nodes in order to
			offload services from the current IP routers while continuing to
			provide high-quality service by managing the transport paths using
			the advanced OAM tools. The two systems can work side-by-side.
			However, it is important to realize that the new MPLS-TP
			capabailities are only available, for a transport path, if supported
			by all hops that the path traverses.
	8. Migrating from pre-standard MPLS-TP (T-MPLS)		8. Migrating from pre-standard MPLS-TP (T-MPLS)
	8.1. Main motivation		8.1. Main motivation
	8.2. Migration activities and Techniques		8.2. Migration activities and Techniques
	9. Manageability Considerations		9. Manageability Considerations
	10. Security Considerations		10. Security Considerations
	11. IANA Considerations		11. IANA Considerations
	This informational document makes no requests for IANA action.		This informational document makes no requests for IANA action.
	12. Acknowledgments		12. Acknowledgments
End of changes. 29 change blocks.
	106 lines changed or deleted		277 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/