< draft-owens-te-network-survivability-02.txt		draft-owens-te-network-survivability-03.txt >
	Traffic Engineering Working Group Ken Owens (Erlang Technology)		Traffic Engineering Working Group Ken Owens (Erlang Technology)
	Internet Draft Vishal Sharma (Metanoia, Inc.)		Internet Draft Vishal Sharma (Metanoia, Inc.)
	Expiration Date: November 2002 Mathew Oommen (Optical Datacom)		Expiration Date: November 2002 Mathew Oommen (Optical Datacom)
			Fiffi Hellstrand (Nortel)
	May 2002		May 2002
	Network Survivability Considerations for Traffic Engineered IP Networks		Network Survivability Considerations for Traffic Engineered IP Networks
	draft-owens-te-network-survivability-02.txt		draft-owens-te-network-survivability-03.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with all		This document is an Internet-Draft and is in full conformance with all
	provisions of Section 10 of RFC2026.		provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering Task		Internet-Drafts are working documents of the Internet Engineering Task
	Force (IETF), its areas, and its working groups. Note that other groups		Force (IETF), its areas, and its working groups. Note that other groups
	may also distribute working documents as Internet-Drafts.		may also distribute working documents as Internet-Drafts.
	skipping to change at line 48 ¶		skipping to change at line 49 ¶
	services. With the increasing sophistication of network technologies,		services. With the increasing sophistication of network technologies,
	survivability capabilities are becoming available at multiple layers,		survivability capabilities are becoming available at multiple layers,
	allowing for protection and restoration to occur at any layer of the		allowing for protection and restoration to occur at any layer of the
	network. This makes it important to: scrutinize the recovery features		network. This makes it important to: scrutinize the recovery features
	of different network layers, understand the pros and cons of performing		of different network layers, understand the pros and cons of performing
	recovery at each layer, and assess how the interactions between layers		recovery at each layer, and assess how the interactions between layers
	impact network survivability. With these objectives in mind, this draft		impact network survivability. With these objectives in mind, this draft
	examines the considerations for network survivability at different		examines the considerations for network survivability at different
	layers of the network.		layers of the network.
	Owens/Sharma/Oommen Expires November 2002 1		Owens et al Expires November 2002 1
	Table of Contents Page		Table of Contents Page
	Abstract		Abstract
	1. Introduction 2		1. Introduction 2
	2. Overview of Survivability in Traffic Engineered Networks 3		2. Overview of Survivability in Traffic Engineered Networks 3
	3. Purpose of This Document 5		3. Purpose of This Document 5
	4. Motivation 5		4. Motivation 5
	5. Network Survivability Objectives 6		5. Network Survivability Objectives 6
	6. Network Survivability Parameter Considerations 7		6. Network Survivability Parameter Considerations 7
	6.1 Time-scale of Operations 8		6.1 Time-scale of Operations 8
	skipping to change at line 96 ¶		skipping to change at line 97 ¶
	multiple layers.		multiple layers.
	At the lowest layer of the stack, optical networks are now becoming		At the lowest layer of the stack, optical networks are now becoming
	capable of providing dynamic ring and mesh restoration functionality as		capable of providing dynamic ring and mesh restoration functionality as
	well as traditional 1+1 or 1:1 protection functionality. A considerable		well as traditional 1+1 or 1:1 protection functionality. A considerable
	body of work in the research community has dealt with the capacity and		body of work in the research community has dealt with the capacity and
	efficiency considerations inherent in the layout of optical lightpaths		efficiency considerations inherent in the layout of optical lightpaths
	for traffic protection, and work is ongoing [2],[3],[4],[5], [7] to		for traffic protection, and work is ongoing [2],[3],[4],[5], [7] to
	develop a signaling framework to support even more sophisticated		develop a signaling framework to support even more sophisticated
	Owens/Sharma/Oommen Expires November 2002 2		Owens et al Expires November 2002 2
	restoration features at the optical layer for future IP-over-WDM		restoration features at the optical layer for future IP-over-WDM
	networks. Moving up the layered stack, the SONET/SDH layer provides		networks. Moving up the layered stack, the SONET/SDH layer provides
	survivability capability with automatic protection switching (APS), as		survivability capability with automatic protection switching (APS), as
	well as self-healing ring and mesh architectures. A similar		well as self-healing ring and mesh architectures. A similar
	functionality is provided by the ATM Layer, with work ongoing to also		functionality is provided by the ATM Layer, with work ongoing to also
	provide such functionality using technologies such as MPLS [8]. At the		provide such functionality using technologies such as MPLS [8]. At the
	IP layer, rerouting is used to restore service continuity following		IP layer, rerouting is used to restore service continuity following
	link and node outages. Rerouting at the IP layer, however, occurs after		link and node outages. Rerouting at the IP layer, however, occurs after
	a period of routing convergence, which may require from a few seconds		a period of routing convergence, which may require from a few seconds
	to several minutes to complete.		to several minutes to complete.
	skipping to change at line 146 ¶		skipping to change at line 147 ¶
	milliseconds.		milliseconds.
	With the increasing need for explicit engineering of network traffic		With the increasing need for explicit engineering of network traffic
	loads, however, it has become imperative for traffic engineering		loads, however, it has become imperative for traffic engineering
	mechanisms to take network survivability considerations into account.		mechanisms to take network survivability considerations into account.
	An important objective of contemporary and future Internet traffic		An important objective of contemporary and future Internet traffic
	engineering, in fact, is to facilitate reliable network operations by		engineering, in fact, is to facilitate reliable network operations by
	providing mechanisms that enhance network integrity and by adopting		providing mechanisms that enhance network integrity and by adopting
	policies that accommodate network survivability [1]. This is important		policies that accommodate network survivability [1]. This is important
	Owens/Sharma/Oommen Expires November 2002 3		Owens et al Expires November 2002 3
	for two reasons. First, to minimize the vulnerability of the network		for two reasons. First, to minimize the vulnerability of the network
	to service outages arising from errors, faults, and failures that occur		to service outages arising from errors, faults, and failures that occur
	within the infrastructure. Second, to optimize the performance of		within the infrastructure. Second, to optimize the performance of
	operational IP networks by rapidly converging to a stable state while		operational IP networks by rapidly converging to a stable state while
	not even letting TCP stacks know about the failure.		not even letting TCP stacks know about the failure.
	Network faults, be they link outages (fiber cuts, transmitter failures,		Network faults, be they link outages (fiber cuts, transmitter failures,
	etc.) or node outages (mis-configuration, processor or line card		etc.) or node outages (mis-configuration, processor or line card
	failures, power glitches, power supply failures, etc.), will continue		failures, power glitches, power supply failures, etc.), will continue
	to be a fact of life that network engineering will have to accommodate.		to be a fact of life that network engineering will have to accommodate.
	skipping to change at line 196 ¶		skipping to change at line 197 ¶
	(i) The most important is its ability to ensure stable network		(i) The most important is its ability to ensure stable network
	operation, which is a major consideration in real-time network		operation, which is a major consideration in real-time network
	performance optimization. A major challenge for Internet traffic		performance optimization. A major challenge for Internet traffic
	engineering today is to ôexpect the unexpected.ö In other words,		engineering today is to ôexpect the unexpected.ö In other words,
	integrate automated control capabilities that can adapt quickly and at		integrate automated control capabilities that can adapt quickly and at
	a reasonable cost to significant changes in network state, while		a reasonable cost to significant changes in network state, while
	maintaining network stability [1]. Clearly, this challenge cannot be		maintaining network stability [1]. Clearly, this challenge cannot be
	met without accounting for potential network outages, and including		met without accounting for potential network outages, and including
	them in - traffic engineering calculations.		them in - traffic engineering calculations.
	Owens/Sharma/Oommen Expires November 2002 4		Owens et al Expires November 2002 4
	(ii) Survivability considerations also impact the manner in which		(ii) Survivability considerations also impact the manner in which
	traffic is groomed at different layers (more on this in Sections 5 and		traffic is groomed at different layers (more on this in Sections 5 and
	6), and the manner in which it is mapped to the underlying physical or		6), and the manner in which it is mapped to the underlying physical or
	logical topology at different layers of the network. An important		logical topology at different layers of the network. An important
	function of TE is to control the distribution of traffic across the		function of TE is to control the distribution of traffic across the
	network, a task that is strongly influenced by the manner in which		network, a task that is strongly influenced by the manner in which
	traffic is protected at different layers, and by how much traffic is		traffic is protected at different layers, and by how much traffic is
	protected at different network layers. An objective could be to provide		protected at different network layers. An objective could be to provide
	adequate protection schemes at layer 0 that can classify and treat		adequate protection schemes at layer 0 that can classify and treat
	different traffic types, and dynamically assign the traffic to a		different traffic types, and dynamically assign the traffic to a
	skipping to change at line 244 ¶		skipping to change at line 245 ¶
	facilitate fast and efficient network protection. The document is		facilitate fast and efficient network protection. The document is
	intended to expose those areas pertaining to network survivability that		intended to expose those areas pertaining to network survivability that
	require further work by the Internet community, and to serve as a basis		require further work by the Internet community, and to serve as a basis
	for the Traffic Engineering Working Group design team to make		for the Traffic Engineering Working Group design team to make
	recommendations to other Working Groups about network survivability		recommendations to other Working Groups about network survivability
	issues that require further consideration in the respective Working		issues that require further consideration in the respective Working
	Groups.		Groups.
	4.Motivation		4.Motivation
	Owens/Sharma/Oommen Expires November 2002 5		Owens et al Expires November 2002 5
	The need for network survivability and for open standards in		The need for network survivability and for open standards in
	protection/restoration at different network layers arises because of		protection/restoration at different network layers arises because of
	the following:		the following:
	-- Lower layer mechanisms (Optical Layer and SONET/SDH Layer) have no		-- Lower layer mechanisms (Optical Layer and SONET/SDH Layer) have no
	visibility into higher layer operations (for example protocol errors,		visibility into higher layer operations (for example protocol errors,
	priority identification, and reroute calculation). Thus, while they		priority identification, and reroute calculation). Thus, while they
	may provide link protection for example, they cannot easily provide		may provide link protection for example, they cannot easily provide
	node protection unless these optical devices speak the same ôlanguageö.		node protection unless these optical devices speak the same ôlanguageö.
	skipping to change at line 293 ¶		skipping to change at line 294 ¶
	-- Maximize network reliability and availability.		-- Maximize network reliability and availability.
	-- Facilitate fast recovery times where appropriate.		-- Facilitate fast recovery times where appropriate.
	-- Take into consideration the recovery actions of different layers.		-- Take into consideration the recovery actions of different layers.
	For instance, if lower layer mechanisms are utilized in conjunction		For instance, if lower layer mechanisms are utilized in conjunction
	with higher layer survivability mechanisms, the lower layers should		with higher layer survivability mechanisms, the lower layers should
	have an opportunity to restore traffic before the higher layers do. If		have an opportunity to restore traffic before the higher layers do. If
	lower layer restoration is slower than higher layer restoration, the		lower layer restoration is slower than higher layer restoration, the
	lower layer may communicate failure information to the higher layer(s),		lower layer may communicate failure information to the higher layer(s),
	Owens/Sharma/Oommen Expires November 2002 6		Owens et al Expires November 2002 6
	and allow it to perform recovery. The coordination functionality		and allow it to perform recovery. The coordination functionality
	between layers must be tunable.		between layers must be tunable.
	-- Avoid network layering violations. That is, defects at higher		-- Avoid network layering violations. That is, defects at higher
	layer(s) should not normally trigger recovery actions at lower layers.		layer(s) should not normally trigger recovery actions at lower layers.
	-- Minimize the loss of data and packet reordering during recovery		-- Minimize the loss of data and packet reordering during recovery
	operations.		operations.
	-- Minimize the additive latency that may be incurred when recovery is		-- Minimize the additive latency that may be incurred when recovery is
	activated.		activated.
	-- Minimize the state overhead of maintaining recovery information		-- Minimize the state overhead of maintaining recovery information
	(such as additional paths, the association between traffic streams and		(such as additional paths, the association between traffic streams and
	skipping to change at line 343 ¶		skipping to change at line 344 ¶
	5.3. Survivability Techniques		5.3. Survivability Techniques
	Network survivability techniques SHOULD:		Network survivability techniques SHOULD:
	-- Be specifiable for dedicated or shared protection of working		-- Be specifiable for dedicated or shared protection of working
	traffic.		traffic.
	-- Be specifiable on an end-to-end basis or on a segment basis. (For		-- Be specifiable on an end-to-end basis or on a segment basis. (For
	example, at the ATM , MPLS, or IP layer survivability should be		example, at the ATM , MPLS, or IP layer survivability should be
	specifiable for an end-to-end path or for a segment of a path.)		specifiable for an end-to-end path or for a segment of a path.)
	Owens/Sharma/Oommen Expires November 2002 7		Owens et al Expires November 2002 7
	-- Be specifiable for protection of traffic at different granularities		-- Be specifiable for protection of traffic at different granularities
	(for example, temporal, bandwidth, and QoS granularities; more on this		(for example, temporal, bandwidth, and QoS granularities; more on this
	in Section 6).		in Section 6).
	-- Be specifiable for protection of traffic having different		-- Be specifiable for protection of traffic having different
	transmission and/or preemption priorities.		transmission and/or preemption priorities.
	-- Be able to fallback on different protection schemes, should the		-- Be able to fallback on different protection schemes, should the
	primary scheme be unavailable.		primary scheme be unavailable.
	-- Be able to maintain BGP state (where appropriate), if at all		-- Be able to maintain BGP state (where appropriate), if at all
	possible.		possible.
	-- Not allow the provisioning of additional traffic if the		-- Not allow the provisioning of additional traffic if the
	skipping to change at line 391 ¶		skipping to change at line 392 ¶
	In order to perform end-to-end and segment recovery operations, there		In order to perform end-to-end and segment recovery operations, there
	has to exist a signaling mechanism to notify the network recovery		has to exist a signaling mechanism to notify the network recovery
	operation. Some layers have this capability inherently (for example IP		operation. Some layers have this capability inherently (for example IP
	Layer), others (for example optical layer) -may not. (Although recently		Layer), others (for example optical layer) -may not. (Although recently
	there have been proposals that integrate the optical layer with Layer 3		there have been proposals that integrate the optical layer with Layer 3
	routing and that allow, for example, BGP updates to be triggered upon		routing and that allow, for example, BGP updates to be triggered upon
	the detection of a fault at the optical layer.) The signaling		the detection of a fault at the optical layer.) The signaling
	mechanisms initiate the recovery operations and must be considered when		mechanisms initiate the recovery operations and must be considered when
	choosing the network survivability mechanism.		choosing the network survivability mechanism.
	Owens/Sharma/Oommen Expires November 2002 8		Owens et al Expires November 2002 8
	6.4. Recovery Granularity		6.4. Recovery Granularity
	The recovery granularity of the different layer recovery operations		The recovery granularity of the different layer recovery operations
	should be a key requirement in network survivability. In a generic		should be a key requirement in network survivability. In a generic
	sense, the higher the layer, the finer the granularity. The Optical and		sense, the higher the layer, the finer the granularity. The Optical and
	SONET Layers can only recover full pipes (i.e. OC48 Granularity),		SONET Layers can only recover full pipes (i.e. OC48 Granularity),
	whereas IP Layers can recover individual packets or groups of packets.		whereas IP Layers can recover individual packets or groups of packets.
	The recovery granularity must be considered when choosing the network		The recovery granularity must be considered when choosing the network
	survivability mechanism. It is conceivable that the more granularity at		survivability mechanism. It is conceivable that the more granularity at
	the optical layer the better it may be for recovery. However, the		the optical layer the better it may be for recovery. However, the
	skipping to change at line 438 ¶		skipping to change at line 439 ¶
	considered when choosing the network survivability mechanism.		considered when choosing the network survivability mechanism.
	6.7. Fault Monitoring/Reporting		6.7. Fault Monitoring/Reporting
	The key aspect of recovery operations is the ability to detect faults.		The key aspect of recovery operations is the ability to detect faults.
	It is important to understand the various faults that each layer can		It is important to understand the various faults that each layer can
	detect, the fault monitoring capabilities and the fault reporting		detect, the fault monitoring capabilities and the fault reporting
	mechanism. The fault monitoring and reporting mechanisms must be		mechanism. The fault monitoring and reporting mechanisms must be
	considered when choosing the network survivability mechanism. The		considered when choosing the network survivability mechanism. The
	Owens/Sharma/Oommen Expires November 2002 9		Owens et al Expires November 2002 9
	reports may include not only the failed/unplaced circuits, but also		reports may include not only the failed/unplaced circuits, but also
	information on circuits that were placed/routed but have violated their		information on circuits that were placed/routed but have violated their
	performance or QoS constraints.		performance or QoS constraints.
	6.8. Interlayer Considerations/Layer Interactions		6.8. Interlayer Considerations/Layer Interactions
	As previously mentioned in the coverage considerations, there are many		As previously mentioned in the coverage considerations, there are many
	advantages to providing a recovery mechanism that interoperates across		advantages to providing a recovery mechanism that interoperates across
	one or more layers. Any such mechanism must not violate any one-layer		one or more layers. Any such mechanism must not violate any one-layer
	recovery operations or cause another layer to incorrectly recover due		recovery operations or cause another layer to incorrectly recover due
	skipping to change at line 488 ¶		skipping to change at line 489 ¶
	a backup lightpath, if configured.		a backup lightpath, if configured.
	Large switching granularity: the optical layer has the capacity to		Large switching granularity: the optical layer has the capacity to
	restore very large numbers of higher layer flows. For example, hundreds		restore very large numbers of higher layer flows. For example, hundreds
	of LSPs or ATM VCs that would ordinarily be affected by a single link		of LSPs or ATM VCs that would ordinarily be affected by a single link
	failure (such as a fiber cut) could be restored simultaneously at the		failure (such as a fiber cut) could be restored simultaneously at the
	optical layer without the need to invoke higher layer signaling, which		optical layer without the need to invoke higher layer signaling, which
	can be computationally expensive and slow (since it may require		can be computationally expensive and slow (since it may require
	processing by intermediate nodes, and must invariably encounter		processing by intermediate nodes, and must invariably encounter
	propagation delay).		propagation delay).
	Owens/Sharma/Oommen Expires November 2002 10		Owens et al Expires November 2002 10
	Some current limitations of the optical layer are:		Some current limitations of the optical layer are:
	Limited range of granularity: The optical layer can only restore the		Limited range of granularity: The optical layer can only restore the
	traffic at lightpath or sub-lightpath granularity, and is therefore		traffic at lightpath or sub-lightpath granularity, and is therefore
	suitable when all the data on a lightpath or sub-lightpath requires		suitable when all the data on a lightpath or sub-lightpath requires
	protection/restoration. It cannot restore individual circuits or paths.		protection/restoration. It cannot restore individual circuits or paths.
	No discrimination between different traffic types: The optical layer		No discrimination between different traffic types: The optical layer
	being bit-transparent is oblivious to actual traffic content on a		being bit-transparent is oblivious to actual traffic content on a
	lightpath and cannot, in general, differentiate between different		lightpath and cannot, in general, differentiate between different
	traffic types. We note that some discrimination may be possible based		traffic types. We note that some discrimination may be possible based
	purely on the physical and transmission properties of the lightpaths		purely on the physical and transmission properties of the lightpaths
	skipping to change at line 539 ¶		skipping to change at line 540 ¶
	deployment of newer, bandwidth efficient protection options, such as		deployment of newer, bandwidth efficient protection options, such as
	shared mesh protection.		shared mesh protection.
	Another consideration for the optical layer is that it cannot, in		Another consideration for the optical layer is that it cannot, in
	general, detect faults in the router or switching node, and so may not		general, detect faults in the router or switching node, and so may not
	be able to provide true path protection at the LSP or ATM VC level,		be able to provide true path protection at the LSP or ATM VC level,
	since faults in the switching equipment would not be detected by the		since faults in the switching equipment would not be detected by the
	optical layer. It is conceivable, in this case, that the reverse of the		optical layer. It is conceivable, in this case, that the reverse of the
	process described above could be used. Namely, if there was		process described above could be used. Namely, if there was
	Owens/Sharma/Oommen Expires November 2002 11		Owens et al Expires November 2002 11
	communication between the routing/switching equipment and the optical		communication between the routing/switching equipment and the optical
	equipment, the optical layer on learning of a router/switch failure (it		equipment, the optical layer on learning of a router/switch failure (it
	would still not detect faults at higher layers due to misconfiguration		would still not detect faults at higher layers due to misconfiguration
	of the switching equipment), could initiate protection at the optical		of the switching equipment), could initiate protection at the optical
	layer (by causing an deliberate loss of light condition).		layer (by causing an deliberate loss of light condition).
	Appropriate grooming of traffic on to a lightpath must be another		Appropriate grooming of traffic on to a lightpath must be another
	consideration at the optical layer that would impact traffic		consideration at the optical layer that would impact traffic
	engineering and network planning. The grooming algorithms, which		engineering and network planning. The grooming algorithms, which
	traditionally are geared to most efficiently pack higher layer traffic		traditionally are geared to most efficiently pack higher layer traffic
	skipping to change at line 587 ¶		skipping to change at line 588 ¶
	Limited topological scope: SONET protection is largely limited to ring		Limited topological scope: SONET protection is largely limited to ring
	topologies, which reduces the flexibility to deploy somewhat more		topologies, which reduces the flexibility to deploy somewhat more
	complex, but potentially more efficient, mesh-based restoration		complex, but potentially more efficient, mesh-based restoration
	schemes.		schemes.
	Lack of traffic priority: As with the optical layer, the SONET layer		Lack of traffic priority: As with the optical layer, the SONET layer
	also cannot distinguish between different priorities of traffic. For		also cannot distinguish between different priorities of traffic. For
	example, it is not possible in SONET to switch EF (expedited		example, it is not possible in SONET to switch EF (expedited
	forwarding) and AF (assured forwarding) streams based on priority.		forwarding) and AF (assured forwarding) streams based on priority.
	Owens/Sharma/Oommen Expires November 2002 12		Owens et al Expires November 2002 12
	(iv) Oblivious to higher layer failure: Like the optical layer, the		(iv) Oblivious to higher layer failure: Like the optical layer, the
	SONET layer too is oblivious to higher layer errors or faults. Thus,		SONET layer too is oblivious to higher layer errors or faults. Thus,
	SONET cannot detect ATM (or MPLS) layer errors. For instance, a		SONET cannot detect ATM (or MPLS) layer errors. For instance, a
	corruption of packets at the ATM layer will not be detected by SONET		corruption of packets at the ATM layer will not be detected by SONET
	processing.		processing.
	7.2.1 Considerations for the SONET Layer		7.2.1 Considerations for the SONET Layer
	As with the optical layer, an important area of consideration at the		As with the optical layer, an important area of consideration at the
	SONET layer, from a TE perspective, is also one of traffic grooming.		SONET layer, from a TE perspective, is also one of traffic grooming.
	skipping to change at line 638 ¶		skipping to change at line 639 ¶
	the router/switch resulting in corrupted ATM or MPLS control packets),		the router/switch resulting in corrupted ATM or MPLS control packets),
	which can be detected by the ATM or MPLS layer. The ATM layer can do so		which can be detected by the ATM or MPLS layer. The ATM layer can do so
	via the F1-F5 errors and via its peering capability, whereas the MPLS		via the F1-F5 errors and via its peering capability, whereas the MPLS
	layer may do so via an appropriately implemented liveness message (for		layer may do so via an appropriately implemented liveness message (for
	example, the LDP Liveness message).		example, the LDP Liveness message).
	Capability to detect misconfigurations: Both the ATM and MPLS layer can		Capability to detect misconfigurations: Both the ATM and MPLS layer can
	detect node or software misconfiguration by the counting of errored or		detect node or software misconfiguration by the counting of errored or
	corrupted packets, which may be identified by looking at the ATM header		corrupted packets, which may be identified by looking at the ATM header
	or MPLS label. In ATM, this may involve tracking VPI/VCI mismatches,		or MPLS label. In ATM, this may involve tracking VPI/VCI mismatches,
	Owens/Sharma/Oommen Expires November 2002 13		Owens et al Expires November 2002 13
	while in MPLS this may be accomplished by counting TTL errors or label		while in MPLS this may be accomplished by counting TTL errors or label
	mismatches		mismatches
	Other advantages of the ATM layer are the existence of an in-band OAM		Other advantages of the ATM layer are the existence of an in-band OAM
	functionality that can help to detect path errors along a virtual		functionality that can help to detect path errors along a virtual
	circuit or virtual path, and also provides faster detection and		circuit or virtual path, and also provides faster detection and
	restoration than is possible by relying on routing protocols alone.		restoration than is possible by relying on routing protocols alone.
	Some of the current limitations of the MPLS layer are:		Some of the current limitations of the MPLS layer are:
	skipping to change at line 686 ¶		skipping to change at line 687 ¶
	layers.		layers.
	7.4 IP Layer		7.4 IP Layer
	The IP layer is central to the IP network infrastructure. Some of the		The IP layer is central to the IP network infrastructure. Some of the
	advantages of the IP layer for survivability include:		advantages of the IP layer for survivability include:
	The ability to find optimal routes: The IP layer runs routing		The ability to find optimal routes: The IP layer runs routing
	algorithms that can be tuned to propagate information that facilitates		algorithms that can be tuned to propagate information that facilitates
	Owens/Sharma/Oommen Expires November 2002 14		Owens et al Expires November 2002 14
	the calculation of optimal routes through the network, and perform		the calculation of optimal routes through the network, and perform
	constraint-based routing [12]		constraint-based routing [12]
	Better granularity of protection: Clearly, at the IP layer one obtains		Better granularity of protection: Clearly, at the IP layer one obtains
	a fine level of granularity at which protection can be done. This layer		a fine level of granularity at which protection can be done. This layer
	allows a path selection algorithm to pick paths based on priority and		allows a path selection algorithm to pick paths based on priority and
	other requirements of the traffic.		other requirements of the traffic.
	Load balancing ability: At the IP layer, one has the maximum		Load balancing ability: At the IP layer, one has the maximum
	flexibility to perform load sharing by distributing traffic across		flexibility to perform load sharing by distributing traffic across
	different paths (for example, by hashing using the source and		different paths (for example, by hashing using the source and
	destination address), and the flexibility to select a better path if it		destination address), and the flexibility to select a better path if it
	skipping to change at line 737 ¶		skipping to change at line 738 ¶
	The ability to provide positive acknowledgement with retransmission		The ability to provide positive acknowledgement with retransmission
	(ACK).		(ACK).
	The finest granularity of protection-application level: Clearly, at the		The finest granularity of protection-application level: Clearly, at the
	TCP layer one obtains a fine level of granularity at which protection		TCP layer one obtains a fine level of granularity at which protection
	can be done. This layer allows a path selection algorithm to pick paths		can be done. This layer allows a path selection algorithm to pick paths
	based on priority and other requirements of the application.		based on priority and other requirements of the application.
	Some of the drawbacks of the Transport layers in terms of survivability		Some of the drawbacks of the Transport layers in terms of survivability
	are:		are:
	Owens/Sharma/Oommen Expires November 2002 15		Owens et al Expires November 2002 15
	A well-known drawback of the Transport layer, of course, is that		A well-known drawback of the Transport layer, of course, is that
	recovery operations here are quite slow relative to the lower layers.		recovery operations here are quite slow relative to the lower layers.
	Connectionless recovery, due to its dependence on IP routing, can take		Connectionless recovery, due to its dependence on IP routing, can take
	seconds to detect loss of connectivity (via ACKS and sequence		seconds to detect loss of connectivity (via ACKS and sequence
	violations (TCP) or routing protocol (UDP)) thereby slowing down the		violations (TCP) or routing protocol (UDP)) thereby slowing down the
	recovery action.		recovery action.
	Another problem with the Transport layer is that it too cannot detect		Another problem with the Transport layer is that it too cannot detect
	physical layer faults, and fault isolation may be an issue if the		physical layer faults, and fault isolation may be an issue if the
	intent is not to always rely on fault recovery based on IP rerouting.		intent is not to always rely on fault recovery based on IP rerouting.
	skipping to change at line 786 ¶		skipping to change at line 787 ¶
	layer fault that is not visible at the higher layer, so the ability to		layer fault that is not visible at the higher layer, so the ability to
	communicate such fault information across layers may enable a lower		communicate such fault information across layers may enable a lower
	layer, such as the optical layer, to take advantage of finer-scale		layer, such as the optical layer, to take advantage of finer-scale
	protection capabilities of the higher layers by enabling them much		protection capabilities of the higher layers by enabling them much
	quicker than they normally would. Some major impacts that designing		quicker than they normally would. Some major impacts that designing
	coordination between the different layers is how to efficiently design		coordination between the different layers is how to efficiently design
	the network with high reliability and availability. Additionally, the		the network with high reliability and availability. Additionally, the
	nature of SLAs that a provider could sign with customers will provide		nature of SLAs that a provider could sign with customers will provide
	another degree of design considerations.		another degree of design considerations.
	Owens/Sharma/Oommen Expires November 2002 16		Owens et al Expires November 2002 16
	8. Service Provider Considerations		8. Service Provider Considerations
	This section provides an overview of some aspects related to network		This section provides an overview of some aspects related to network
	survivability that service providers may consider when defining their		survivability that service providers may consider when defining their
	requirements. Our objective here is to lay down some initial thoughts,		requirements. Our objective here is to lay down some initial thoughts,
	and solicit feedback from individuals in the service provider arena.		and solicit feedback from individuals in the service provider arena.
	-- Understanding how important network survivability is to the service		-- Understanding how important network survivability is to the service
	provider organization		provider organization
	. Service providers might place different degrees of importance on		. Service providers might place different degrees of importance on
	skipping to change at line 836 ¶		skipping to change at line 837 ¶
	have insight to the TE requirements of the operator environment		have insight to the TE requirements of the operator environment
	(through policies for example), and could therefore find a more optimal		(through policies for example), and could therefore find a more optimal
	route. Or is it that each layer should only provide survivability for		route. Or is it that each layer should only provide survivability for
	itself and leave survivability of other layers to mechanisms within		itself and leave survivability of other layers to mechanisms within
	those layers.		those layers.
	-- Collect service provider survivability strategies, performance		-- Collect service provider survivability strategies, performance
	objectives, and requirements to identify framework level requirements		objectives, and requirements to identify framework level requirements
	on survivability.		on survivability.
	Owens/Sharma/Oommen Expires November 2002 17		Owens et al Expires November 2002 17
	-- Define the switch-over time objectives, granularity of traffic that		-- Define the switch-over time objectives, granularity of traffic that
	must be supported, and scope (end-to-end, segment, node, link,		must be supported, and scope (end-to-end, segment, node, link,
	combinations) of survivability strategies.		combinations) of survivability strategies.
	-- Identify the extent to which excess traffic would be utilized on		-- Identify the extent to which excess traffic would be utilized on
	backup paths during normal operating conditions.		backup paths during normal operating conditions.
	9. Security Considerations		9. Security Considerations
	This document raises no new security issues for any of the protocols		This document raises no new security issues for any of the protocols
	skipping to change at line 878 ¶		skipping to change at line 879 ¶
	Work in Progress, draft-ietf-ipo-framework-01.txt, February 2002.		Work in Progress, draft-ietf-ipo-framework-01.txt, February 2002.
	[4] Lang. J., et al, "Link Management Protocol for Optical Networks,"		[4] Lang. J., et al, "Link Management Protocol for Optical Networks,"
	Work in Progress, Internet Draft, Work in Progress, draft-ietf-ccamp-		Work in Progress, Internet Draft, Work in Progress, draft-ietf-ccamp-
	lmp-03.txt, March 2002.		lmp-03.txt, March 2002.
	[5] Awduche, D. O., Rekhter, Y, ôMulti-Protocol Lambda Switching:		[5] Awduche, D. O., Rekhter, Y, ôMulti-Protocol Lambda Switching:
	Combining MPLS Traffic Engineering Control With Optical Crossconnects,ö		Combining MPLS Traffic Engineering Control With Optical Crossconnects,ö
	IEEE Commun. Magazine, vol. 39, no. 3, March 2001, pp. 111-116.		IEEE Commun. Magazine, vol. 39, no. 3, March 2001, pp. 111-116.
	Owens/Sharma/Oommen Expires November 2002 18		Owens et al Expires November 2002 18
	[7]Berger. L. (Editor), "Generalized MPLS Signaling Functional		[7]Berger. L. (Editor), "Generalized MPLS Signaling Functional
	Description", draft-ietf-mpls-generalized-signaling-08.txt, Internet		Description", draft-ietf-mpls-generalized-signaling-08.txt, Internet
	Draft, Work in Progress, April 2002.		Draft, Work in Progress, April 2002.
	[8]Sharma, V., Hellstrand, F. (Editors) "A Framework for MPLS-based		[8]Sharma, V., Hellstrand, F. (Editors) "A Framework for MPLS-based
	Recovery," Work in Progress, Internet Draft, draft-ietf-mpls-recovery-		Recovery," Work in Progress, Internet Draft, draft-ietf-mpls-recovery-
	frmwrk-04.txt, May 2002.		frmwrk-04.txt, May 2002.
	[9]Huang, C., V. Sharma, K. Owens, V. Makam "Building Reliable MPLS		[9]Huang, C., V. Sharma, K. Owens, V. Makam "Building Reliable MPLS
	Networks Using a Path Protection Mechanism," IEEE Commun. Magazine,		Networks Using a Path Protection Mechanism," IEEE Commun. Magazine,
	skipping to change at line 911 ¶		skipping to change at line 912 ¶
	11. AuthorsÆ Addresses		11. AuthorsÆ Addresses
	Ken Owens Vishal Sharma		Ken Owens Vishal Sharma
	Erlang Technology, Inc. Metanoia, Inc.		Erlang Technology, Inc. Metanoia, Inc.
	1106 Fourth Street 305 Elan Village Lane, Unit 121		1106 Fourth Street 305 Elan Village Lane, Unit 121
	St. Louis, MO 63126 San Jose, CA 95134-2545		St. Louis, MO 63126 San Jose, CA 95134-2545
	Phone: 314-918-1579 Phone: 408-955-0910		Phone: 314-918-1579 Phone: 408-955-0910
	keno@erlangtech.com v.sharma@ieee.org		keno@erlangtech.com v.sharma@ieee.org
	Mathew Oommen		Mathew Oommen Fiffi Hellstrand
	Optical Datacom		Optical Datacom Nortel Networks
	4150 S. 100th East Avenue		4150 S. 100th East Avenue St Eriksgatan 115
	Suite 402		Suite 402 PO Box 6701
	Tulsa, OK 74146		Tulsa, OK 74146 113 85 Stockholm, Sweden
	720 873 3723		720 873 3723 Phone: +46 8 5088 3687
	moommen@ieee.org		moommen@ieee.org Fiffi@nortelnetworks.com
	Full Copyright Statement		Full Copyright Statement
	Owens/Sharma/Oommen Expires November 2002 19		Owens et al Expires November 2002 19
	"Copyright (C) The Internet Society (March 2000). All Rights Reserved.		"Copyright (C) The Internet Society (March 2000). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it or		others, and derivative works that comment on or otherwise explain it or
	assist in its implementation may be prepared, copied, published and		assist in its implementation may be prepared, copied, published and
	distributed, in whole or in part, without restriction of any kind,		distributed, in whole or in part, without restriction of any kind,
	provided that the above copyright notice and this paragraph are		provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing the		document itself may not be modified in any way, such as by removing the
	copyright notice or references to the Internet Society or other		copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of developing		Internet organizations, except as needed for the purpose of developing
	Internet standards in which case the procedures for copyrights defined		Internet standards in which case the procedures for copyrights defined
	in the Internet Standards process must be followed, or as required to		in the Internet Standards process must be followed, or as required to
	translate it into languages other than English.		translate it into languages other than English.
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assigns.
	Owens/Sharma/Oommen Expires November 2002 20		Owens et al Expires November 2002 20
End of changes. 23 change blocks.
	27 lines changed or deleted		28 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/