One document matched: draft-andersson-reroute-frmwrk-00.txt

Internet Draft						Loa Andersson
							Brad Cain
							Bilel Jamoussi
							Nortel Networks


           Requirement Framework for Fast Re-route with MPLS
                <draft-andersson-reroute-frmwrk-00.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


 Abstract

 Interest has recently grown in using MPLS for the creation of 
 engineered backup paths.  To evaluate the merits of these proposals we
 discuss the a framework of general requirements for fast re-route 
 schemes.  This document attempts to document the areas against which 
 proposals can be considered.  



1.  Introduction

 This memo describes a requirement framework for evaluation of MPLS 
 re-routing schemes.  We discuss the areas where providers may have
 specific requirements.  This document does not propose a specific
 re-route scheme but can be used as a framework for evaluation. 







Expires April 2000                                        [Page 1]

INTERNET-DRAFT  Framework for Fast Re-route with MPLS  October 1999


1.1.  Background

 Through the use of dynamic routing protocols, IP networks have the 
 capability to re-route traffic around node or link failures.
 Using the current routing protocols this re-routing process may take
 several seconds to minutes.  During this period of time black holes or
 transient loops may occur in the network, causing trafic delivery to 
 be interupted.  For a certain types of applications (e.g. www, mail 
 and file tranfer) this is, if not optimal, at least acceptable.  For 
 other applications (e.g. real time applications) it is greater 
 concern.  The need to provide a much faster re-routing mechanism has 
 been identified.

 Fast protection/re-route of LSP's in cases of link and/or node 
 failure by means of alternative label switched paths (LSP)
 has been suggested [haskins] and [krishnan].  In [haskins] the 
 ability to quickly re-route data traffic around a failure or 
 congestion on a alternative label switched path is described.  This 
 can be important for in mission critical applications.  When a link or
 node failure occurs, recovery is through the use of re-routing data 
 over an alternative path.  Such alternative paths can be established 
 after a primary path failure is detected or, alternatively, it can be 
 established beforehand in order to reduce the path failover time.


1.2.  Backup Schemes
 
 In this section we explain the use of MPLS backup routing methods and
 describe in general how these schemes work.

1.2.1.  Definitions

 MPLS backup schemes use secondary paths when routing on primary paths 
 is unavailable.  We now define the definitions for these two terms:

	- Primary path: We define the primary path as the path on which
          the traffic is directed by the routing protocol or a TE 
          mechanism and which is (from some aspect) considered optimal 
          for that traffic.

	- Secondary path: We define the secondary path as the path on 
          which the traffic is directed by the re-routing mechanism.  
          This is considered to be a potential sub-optimal.  We 
          consider networks in which traffic is using secondary paths 
          to be in a semi-stable state.  We also use the term "backup 
          path" to describe a secondary path.





Expires April 2000                                        [Page 2]
^L
INTERNET-DRAFT  Framework for Fast Re-route with MPLS  October 1999


1.2.2.  Generalization of Schemes

 MPLS backup schemes both establish backup paths and dynamically route
 traffic to these paths during failures.  We now discuss the components
 of a backup schemes to frame the requirements.

 - Path Algorithms: Backup paths can be either pre-established or
   established dynamically (after a failure).  Schemes may differ in 
   the types of algorithms used to compute backup paths as well as 
   whether the computation is on-line or off-line.  

 - MPLS Use: Closely related to the path algorithm is the manner in 
   which MPLS is utilized to construct and create the backup paths.  
   Schemes may differ in the use of bi-directional paths, 
   label-stacking, etc.  

 - Failure Detection: Once a failure is detected, a notification must be
   sent to a router which either has a pre-established backup or can 
   dynamically establish one.  Schemes may differ in how the 
   notification signal is propagated.  For example, a notification 
   could be explicit (e.g. RSVP or LDP) or data driven.


1.2.3.  The Recovery Cycle

 We now present a generalized set of events which occur in a network 
 when a failure occurs when a re-routing mechanism is active.

	1. Link/Node failure occurs
	2. Failure is detected (signaling initiated)
	3. Signaling indicating the failure arrives at an entity which 
           can perform the switch-over
	4. The switch-over of traffic from the primary to the secondary
           occurs 
	5. The network enters a semi-stable state
	6. Dynamic routing protocols converge after failure
	7. New primary paths are established (through dynamic protocols)
	8. New secondary paths may be established
	9. Traffic switched over to the new primary paths 

 While in the semi-stable state another failure might occur for the
 secondary path, the cycle could, if the the secondary path is 
 protected, begin again. This however is a one way scheme, the 
 abandoned primary path is not taken in to operation again, unless 
 verified by the routing protocol after convergence.





Expires April 2000                                        [Page 3]
^L
INTERNET-DRAFT  Framework for Fast Re-route with MPLS  October 1999

2.  Requirements for MPLS Re-Route

 The traffic engineering of routed networks in general and the 
 fast re-route area in particular are emerging technologies.  We see a
 need for defining a set of general requirement areas by which MPLS
 fast re-route schemes can be measured and evaluated.  We specifically
 do not specify and hard (e.g. numerical)  requirements at this time 
 but give a framework for these specifications.

2.1.  Backup restoration time

 We define backup restoration time as the time required for a backup 
 path to be activated (and traffic flowing) after a failure.  Backup 
 Restoration Time is the sum of the Detection Time and the Signal 
 Propagation Time.  

	- Detection Time: We define detection time as the time lapsed 
	between a failure of a node or link in the network and the time
	that any *local* action (at the point of failure) is taken in 
        response to the failure.  This time may be highly dependent on 
        lower layer protocols.

	- Signal Propagation Time: We define signal propagation time 
        as the time laspsed between the detection time and the time 
        before a backup path is installed.  An example of signal 
        propagation time is the time required to signal a failure 
        back to a node which can re-route traffic on a backup path.


2.2.  Full Restoration Time

 We define full restoration time as the time required for a suitable 
 semi-permanent restoration.  This is the time required for traffic to 
 be routed onto links which are capable or have been engineered 
 sufficiently to handle excess traffic in failure scenarios.  Note that
 this time may or may not be different from the "Backup Restoration 
 Time" depending on the complexity of a scheme or the capacity of a 
 network.  

 A network that is in a semi-stable state (i.e. traffic flowing over
 sub-optimal paths), may show deteriating service over time.  The 
 network needs to be put back in a condition where "optimal paths" are 
 used.  


2.3.  Holddown Time

 We define the holddown period as a bounded time for which
 a backup path must be used.  In some scenarios it may be difficult
 to determine if the primary path is stable.  In these cases a
 holddown time may be used to  prevent excess flapping of traffic 
 between a primary and secondary path.

Expires April 2000                                        [Page 4]
^L
INTERNET-DRAFT  Framework for Fast Re-route with MPLS  October 1999


2.4.  Backup Capacity

 Backup schemes may require differing amounts of "backup capacity" 
 in the advent of a failure.  This capacity will be dependant on the
 traffic characteristics of the network.  However, it may also be
 dependant on the particular backup path selection algorithms as well 
 as the signaling and re-routing methods.

2.5.  Additive Latency

 Backup schemes may introduce additive latency traffic.  For example, 
 a backup path may take many more hops.  This may be dependent on the 
 backup path selection algorithms as well as the signaling and 
 re-routing methods.

2.6.  Failure Types

 Backup schemes may account for only link failures or both node and 
 link failures.  For example, a scheme may require more backup paths to
 take node failures into account.

2.7.  Re-ordering

 Backup schemes may introduce re-ordering of packets.  This occurs when
 packets are re-routed back to the re-route point and fall behind 
 packets which are now already on the backup path.  For example, 
 re-ordering may occur during detection and signaling time.  Also the 
 action of putting traffic back on optimal paths might cause packet 
 re-ordering. 


2.8.  State Overhead

 As the number of backup paths grows, the state required to maintain 
 them also grows.  Schemes may require differing numbers of paths to 
 maintain certain levels of coverage, etc.   The state required may 
 also depend on the particular scheme used to re-route packets.  In 
 many cases the state overhead will be in proportion to the number of 
 backup LSPs.

2.9.  Loss

 Backup schemes may introduce a certain amount of packet loss during 
 switchover to a backup path.  Schemes which introduce loss during 
 detection and signaling time can measure this loss by evaluating
 restoration times in proportion to the link speed.

 In case of link or node failure a certain packet loss is inevitable.  
 The packet loss is a function of packets per second times the full 
 restoration time.

Expires April 2000                                        [Page 5]
^L
INTERNET-DRAFT  Framework for Fast Re-route with MPLS  October 1999


2.10.  Coverage

 Backup schemes may offer various types of failover coverage.  The 
 total coverage may be defined in terms of several metrics:
        
	- Number of concurrent failures: dependent on the 
 	layout of backup paths, multiple failure scenarios
	may be able to be restored.

	- Number of backup paths: for a given failure, there
	may be one or more backup paths.

	- Percentage of coverage: dependent on a scheme and
	its implementation, a certain percentage of failures
	may be covered.  This may be subdivided into percentage
	of link failures and percentage of node failures.

 The number of protected LSP's will highly effect how fast the total
 set of LSP's affected by a failure could be re-routed. The ratio of
 protected is n/N, there n is the number of protected LSPs and N is the
 total number of LSPs.






























Expires April 2000                                        [Page 6]
^L
INTERNET-DRAFT  Framework for Fast Re-route with MPLS  October 1999



3.  References


[haskin] Dimitry Haskin, Ram Krishnan "A Method for Setting an 
Alternative Label Switched Paths to Handle Fast Reroute", 
draft-haskin-mpls-fast-reroute-01.txt, 1999, Work in progress.

[krishnan] Dimitry Haskin, Ram Krishnan "Extensions to RSVP 
to Handle Establishment of Alternate Label-Switched Paths 
for Fast Re-route", 
draft-krishnan-mpls-reroute-rsvpext-01.txt, 1999, Work in progress.

[makan] S. Makam, V. Sharma, K. Owens, C. Haung, "Protection/
Restoration of MPLS Networks", 
draft-makam-mpls-protection-00.txt, 1999, Work in progress.


4.  Author's Addresses

Loa Andersson
Nortel Networks
St Eriksgatan 115, PO Box 6701
113 85 Stockholm, Sweden
phone: +46 8 50 88 36 34
e-mail: loa.andersson@nortelnetworks.com


Brad Cain
Email: bcain@baynetworks.com
Bilel Jamoussi
Email: jamoussi@nortelnetworks.com
Nortel Networks
3 Federal Street, BL3-03
Billerica, MA 01821, USA
















Expires April 2000                                        [Page 7]