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]