Network Working Group Robert Goguen
Internet Draft Cisco Systems, Inc.
Expiration Date: May 2001
George Swallow
Cisco Systems, Inc.
November 2000
RSVP Label Allocation for Backup Tunnels
draft-swallow-rsvp-bypass-label-01.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."
To view the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
Directory, see http://www.ietf.org/shadow.html.
Abstract
This document describes the use of RSVP, to establish backup tunnels
for local repair of LSP tunnels.
Goguen & Swallow [Page 1]
Internet Draft draft-swallow-rsvp-bypass-label-01.txt November 2000
Contents
1 Introduction .......................................... 3
2 Labels for backup tunnels .............................. 4
3 Signaling for backup tunnels ........................... 5
3.1 Identification and association of backup LSP tunnels ... 5
3.2 ERO contents ........................................... 7
4 Efficient signaling for the global label case .......... 7
5 Notification of local repair ........................... 7
6 Security Considerations ................................ 8
7 Intellectual Property Considerations ................... 8
8 References ............................................. 8
9 Authors' Addresses ..................................... 8
Goguen & Swallow [Page 2]
Internet Draft draft-swallow-rsvp-bypass-label-01.txt November 2000
1. Introduction
This document describes the use of RSVP[RFC2205], to establish backup
tunnels for local repair of LSP tunnels. The RSVP extensions for
setting up LSP tunnels are described in [2].
In order to meet the needs of realtime applications such as Voice
over IP, it is highly desirable to be able to repair LSP tunnels in
10s of milliseconds. We use the term local repair to when referring
to techniques which accomplish this. There are two basic strategies
for effecting local repair. These are one to one backup and one to
many backup.
In the one to one case, a label switched path is established which
intersects the original tunnel somewhere downstream of the point of
local repair. For each LSP which is backed up, another backup LSP is
established.
[R1]---[R2]-----[R3]----[R4]---[R5]
\ /
[R6]---[R7]
For example, suppose that in the simple topology above, R1 creates a
tunnel to R5 via the path [R1->R2->R3->R4->R5]. R2 can provide local
repair by creating a partial backup tunnel [R2->R6->R7->R4] which
merges with the original tunnel [R1->R2->R3->R4->R5] at R4.
A second means of backing up LSPs is to take advantage of the label
stack. Instead of creating a separate LSP for every backed-up LSP
tunnel, a single LSP is created which serves to backup up a set of
tunnels. We call such a tunnel a bypass tunnel. The bypass tunnel
itself is established just like any other LSP tunnel.
Again the bypass tunnel must intersect the original tunnel(s)
somewhere downstream of the point of local repair. This of course
implies that the set of tunnels being backed up all pass through some
common downstream node. All tunnels which pass through the point of
local repair and through this common node which do not use the
facilities being bypassed are candidates for this set of tunnels.
To effect the repair of the backed up tunnels, packets belonging to a
repaired tunnel are redirected onto the bypass tunnel. An additional
label representing the bypass tunnel is stacked onto the redirected
packets. At the penultimate hop of the bypass tunnel, the label for
the bypass tunnel is popped off the stack, revealing the label which
represents the tunnel being backed up.
Returning to the above example, R2 in this case would build a bypass
Goguen & Swallow [Page 3]
Internet Draft draft-swallow-rsvp-bypass-label-01.txt November 2000
tunnel [R2->R6->R7->R4]. The doubled lines represent this tunnel.
The backup path for [R1->R2->R3->R4->R5] again rejoins the original
path at R4, but its path is now [R1->R2->R4->R5] with the bypass
tunnel as the connection between R2 and R4.
[R8]
\
[R1]---[R2]----[R3]----[R4]---[R5]
\ // \
[R6]===[R7] [R9]
The scalability improvement comes in that this bypass tunnel can also
be a backup for tunnels from any of R1, or R2, R8 to any of R4, R5,
or R9 which traverse the link R2->R3.
2. Labels for backup tunnels
In this section we consider the issues of binding labels to these
various backup entities. In this discussion we refer to the point of
local repair as PLR or the PLR node depending on context. Similarly,
we refer to the point at which the backup tunnel merges back into the
original tunnel as the merge point or merge node. Note that it is
possible that the merge node is also the tunnel tail.
In MPLS, a node may have a single label space which is global to the
node, or it may have multiple label spaces, some of which are
specific to particular interfaces.
Whether one to one backup or many to one backup is used, a means for
obtaining labels which properly represent the backed up tunnels is
required.
The simplest case is when the merge node is the next hop of both the
original tunnel and of the backup tunnel and the merge node has a
global label space. In the one to one case this situation would
arise as follows. There exist multiple links between the local-
repair node and the merge node. An LSP tunnel crosses one of these
links. A parallel link will be used as the backup should the primary
link fail. Since the merge node is using a global label space, it
would properly recognize packets which were sent on the parallel
link.
In the many to one case, the above situation arises in a more general
way. Consider any two neighbor nodes, L and M. If L wishes to
backup the tunnels crossing the link to M it could establish a backup
tunnel to M via any available route which avoids the backed up link.
Again, since M is using a global label space, to effect the bypass, L
Goguen & Swallow [Page 4]
Internet Draft draft-swallow-rsvp-bypass-label-01.txt November 2000
would simply do the normal label swap, and then push on the label for
the backup tunnel. The penultimate hop of the backup tunnel would
pop the label for the backup tunnel, revealing the label which M
expects.
When a failure occurs and the backup comes into use, a means of
maintaining the RSVP state is required. In this simple case the Path
messages can simply be sent via the backup link or tunnel as the case
may be.
Except for these specific cases, additional labels must be assigned
and a means of signaling is required.
Returning to the bypass tunnel example above, if R4 does not use a
global label space then a label must be assigned out of the label
space used by R4 on the interface terminating the link from R7. if,
however, R4 has a global label space then the label which R2 uses
during the backup could be the same label value which is used by R3.
In the next section we describe a general means of obtaining backup
labels. In the following section we describe an efficient means
communicating labels where global label spaces are used.
3. Signaling for backup tunnels
A number of objectives must be met to obtain a satisfactory signaling
solution. These are summarized as follows:
1. Unambiguously and uniquely identify backup tunnels
2. Unambiguously associate primary tunnels with their backup
tunnels
3. Work with both global and non-global label spaces
4. Allow for merging of backup tunnels
5. Maintain RSVP state during and after fail-over.
3.1. Identification and association of backup LSP tunnels
LSP tunnels are identified by a combination of the SESSION and
SENDER_TEMPLATE objects. The relevant fields are:
IPv4 tunnel end point address
IPv4 address of the egress node for the tunnel.
Goguen & Swallow [Page 5]
Internet Draft draft-swallow-rsvp-bypass-label-01.txt November 2000
Tunnel ID
A 16-bit identifier used in the SESSION that remains constant
over the life of the tunnel.
Extended Tunnel ID
A 32-bit identifier used in the SESSION that remains constant
over the life of the tunnel. Normally set to all zeros.
Ingress nodes that wish to narrow the scope of a SESSION to the
ingress-egress pair may place their IPv4 address here as a
globally unique identifier.
IPv4 tunnel sender address
IPv4 address for a sender node
LSP ID
A 16-bit identifier used in the SENDER_TEMPLATE and the
FILTER_SPEC that can be changed to allow a sender to share
resources with itself.
The first three of these are in the SESSION object and are the basic
identification of the tunnel. The last two are in the
SENDER_TEMPLATE.
The LSP_ID is used to differentiate multiple LSPs during a tunnel
reroute procedure. During this procedure, multiple LSPs each with
their own LSP_ID may be active simultaneously. It is quite possible
that a node which is downstream of the point of local repair on the
LSP being backed up is also upstream of the point of local repair for
some other LSP associated with the tunnel. It is thus necessary to
properly associate the LSP_ID of a backup tunnel with the LSP_ID of
the tunnel being backed up.
We therefore propose that backup tunnels be identified as follows.
The SESSION object and the LSP_ID are copied from the LSP tunnel
being backed up. The IPv4 tunnel sender address is set to an address
of the PLR node. If the head-end of a tunnel is also acting as the
PLR, it must choose an IP address different from the one used in the
SENDER_TEMPLATE of the original LSP tunnel.
Goguen & Swallow [Page 6]
Internet Draft draft-swallow-rsvp-bypass-label-01.txt November 2000
3.2. ERO contents
The PLR creates an ERO for the backup LSP tunnel. It does this by
operating on the original ERO or on the contents of a received RRO.
Abstract nodes which precede the merge point are removed. In the
case of signaling over a bypass tunnel, the procedure is now
complete. In the one-to-one backup case the, an explicit route from
the PLR node to the merge node is prepended to the ERO.
4. Efficient signaling for the global label case
When global labels are in use and bypass tunnels are used as the
means of local repair, a more efficient means of backup label
distribution can be employed. When using a bypass tunnel, the backed
up tunnels are only one LSP hop from rejoining their primary LSPs.
If the merge node is using a global label space, then the label
necessary for the back up tunnel is the label already assigned by the
merge node.
By using the label record option of the ROUTE_RECORD procedure,
downstream labels can be known by upstream nodes without further
protocol interactions. In this case no Path message is sent down the
bypass tunnel prior to a failure. When a failure occurs, the PLR
updates the ERO as above and begins refreshing the LSP down the
bypass tunnel. This ensures that the LSP state is refreshed in the
merge node and nodes further downstream.
5. Notification of local repair
In many situations, the route used during a local repair will be less
than optimal. The point of the local repair is to keep high priority
and loss sensitive traffic flowing while a more optimal rerouting of
the tunnel can be effected by the head-end of the tunnel. Thus the
head-end needs to know of the failure.
To provide this notification, the point of local repair SHOULD send a
PathErr message with error code of "Notify" and an error value of
"Notification of local repair".
Goguen & Swallow [Page 7]
Internet Draft draft-swallow-rsvp-bypass-label-01.txt November 2000
6. Security Considerations
These procedures do not change the trust model of RSVP [RFC2205] and
draft-ietf-mpls-rsvp-tunnel-07.txt[RSVP-TE]. As such no additional
security risks are posed.
7. Intellectual Property Considerations
Cisco Systems may have intellectual property rights claimed in regard
to some or all of the specification contained in this document.
8. References
[RFC2205] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) --
Version 1, Functional Specification", RFC 2205, September 1997.
[RSVP-TE] Awduche, D. et al., "Extensions to RSVP for LSP Tunnels",
Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, August,
2000.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement
Levels", RFC 2119, March 1997.
9. Authors' Addresses
Robert Goguen
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Voice: +1 978 244 8095
Email: rgoguen@cisco.com
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Voice: +1 978 244 8143
Email: swallow@cisco.com
Goguen & Swallow [Page 8]