Internet Draft Fiffi Hellstrand
Multi-Protocol Label Switching Loa Andersson
Expiration Date: May 2001
Nortel Networks
November 2000
Extensions to CR-LDP and RSVP-TE for setup
of pre-established recovery tunnels
<draft-hellstrand-mpls-recovery-merge-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."
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
To protect an Explicit Routed Label Switched Path (ER-LSP) an
explicitly routed LSP can be used as a recovery path. We consider a
repair scheme where a Recovery LSP (R-LSP) spans one or several hops.
After a switchover of traffic to the R-LSP we want to allow the
traffic to merge onto the original LSP at the merging node downstream
of the fault without causing any extra resource reservation. This
merge operation differs in a number of details from that employed for
a normal MP2P LSP. Also, if any resource allocation is associated
with the recovery paths carefulness should be taken to avoid multiple
resource reservation on the same path for the protection of one LSP.
Our objective is to define extensions to both CR-LDP and RSVP-TE that
address these differences. CR-LDP and RSVP-TE are defined in [CR-LDP]
and [RSVP-TE], respectively, for path setup within a MPLS domain. In
this draft we specify mechanisms required to support this merge.
Hellstrand, et al. [Page 1]
Internet Draft draft-hellstrand-mpls-recovery-merge-01.txt Nov 2000
Table of Contents
1.0 Introduction
2.0 Protection of LSP
2.1 Protection Merge
2.2 Explicit Merge
3.0 Proposal
3.1 Extensions to CR-LDP
3.1.1 Error Notifications
3.2 Extensions to RSVP-TE
3.3 Recovery Path Resource Reservations
4.0 Security Considerations
5.0 Intellectual Property Considerations
6.0 Acknowledgements
7.0 Author's Addresses
8.0 References
1.0 Introduction
Protection of traffic is growing in importance and especially
recovery schemes that can provide fast restoration at layer 3. MPLS-
based recovery has been pointed out as strong candidate in this area,
see [FRMWK].
To provide protection, recovery paths are established so that
potential failure points are circumvented. The recovery path may have
a common point with the original path at some arbitrary point
downstream of the failure. If a failure is detected, a switchover to
the recovery path(s) is performed. Our objective is to let the
traffic flowing on the recovery path physically merge onto the
original working path at a common node downstream. This applies to
both local and global repair.
To protect Explicit Routed LSPs (ER-LSPs), we consider the setup of
pre-established recovery LSPs to allow for a merge at the Path Merge
LSR (PML, [FRMWK]). How to find a disjoint path between the Path
Switch LSR (PSL, [FRMWK]) and the PML or how the switchover is
performed is not discussed in this ID.
2.0 Protection of ER-LSP
To protect from a link or node failure an ER-LSP recovery tunnel may
be setup between the switching and the merging node on a path
disjoint from the potential failure point. For each ER-LSP to protect
, an recovery LSP is setup through the tunnel. The Recovery LSP
originates at the PSL and the PML terminates it and merge the traffic
onto the primary LSP. At the setup of the recovery LSP, the PML need
information about which primary path it belongs to and allow for
merging of traffic.
Hellstrand et al. [Page 2]
Internet Draft draft-hellstrand-mpls-recovery-merge-01.txt Nov 2000
CR-LDP and RSVP-TE are defined in [CR-LDP] and [RSVP], respectively.
They both support explicitly routed label switched paths. Therefore,
it is natural to extend them to allow for merging of a recovery LSP
with the primary LSP.
2.1 Protection Merging
At the Path Merging LSR (PML) the recovery LSP terminates and the
recovered traffic should be merged onto the primary LSP. To be able
to accomplish the merge the recovery LSP setup procedure must be able
to identify the primary LSP. The identification of the LSP is done by
the use of the unique LSPID that is defined for every ER-LSP. By
including the LSPID of the primary LSP in the setup of the associated
recovery LSP the PML may be able to perform an identification.
2.2 Explicit merging
A recovery scenario is a special case of merging of two LSPs. In a
normal case an LSP may explicitly not allow another LSP to merge onto
the same path or, if it is allowed, an update of any resource
allocations should be made for the merged LSP. In a recovery scenario
when the traffic is switched over to the recovery path, the primary
path does not longer work and hence does not forward any traffic. At
the merging point, the PML, there is only one traffic stream that
either comes, at normal conditions, on the primary path or, at
failure situations, on the recovery path. Traffic only runs on one
path at the same time - either the recovery path or the primary path.
The traffic stream is not doubled on the merged LSP and hence no
update of any resource allocation is needed.
To allow for this special case an indication is needed to explicitly
inform that recovery merge is requested.
3.0 Proposal
To support the merge of an explicitly routed recovery LSP with the
primary ER-LSP, extensions are proposed for CR-LDP and RSVP-TE.
3.1 Extensions to CR-LDP
A new optional TLV is proposed for the Label Request Message to
support the setup of a Recovery LSP. The Label Request Message
defined in [LDP] optionally carries one or more of the optional
Constraint-based Routing TLVs (CR-TLVs) defined in [CR-LDP]. This
Recovery-TLV (R-TLV) is proposed to be an optional CR-TLV. The R-TLV
includes information about which primary LSP the recovery LSP should
merge onto in form of the primary LSP's LSPID. Also, a flag may be
set to indicate compulsorily merge.
Hellstrand et al. [Page 3]
Internet Draft draft-hellstrand-mpls-recovery-merge-01.txt Nov 2000
The encoding for the R-LSP TLV is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0824 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | Local Primary CR-LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primary Ingress LSR Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A fourteen-bit field carrying the value of the
R-TLV Type = 0x0824.
Length
Specifies the length of the value field in bytes = 4.
M flag
The M flag if set indicates compulsorily merge is
allowed and that no extra resource allcotation
should be made for the merged LSP.
Reserved
Zero on transmission. Ignored on receipt.
Local Primary CR-LSP ID
The Local Primary LSP ID is an identifier of the
primary CR-LSP the recovery LSP should be merge with.
The Local Primary LSP ID is locally unique within the
Ingress LSR originating the Primary CR-LSP.
Primary Ingress LSR Router ID
The LSR which originates the primary CR-LSP. An LSR
may use any of its own IPv4 addresses in this field.
3.1.1 Error Notifications
A Notification Message carries a Status TLV, both defined in [LDP],
to signal error notifications associated with the establishment of a
CR-LSP and the processing of the CR-TLV. The proposed R-TLV adds some
new status codes as follows:
Status code Type
Primary LSP not identified 0x44000--
LSR not merge capable 0x44000--
3.2 Extensions to RSVP-TE
In [RSVP-TE] a reroute option is included. It is possible to setup a
recovery LSP that is disjoint with the primary LSP for one or several
hops. The recovery LSP terminates at the same egress LSR as the
Hellstrand et al. [Page 4]
Internet Draft draft-hellstrand-mpls-recovery-merge-01.txt Nov 2000
Primary LSP does and hence may have links in common downstream of a
potential failure point. By using a shared SESSION object the
recovery LSP allows for sharing resources with the Primary LSP on
common links. Once traffic is flowing on the recovery LSP, the
primary LSP is torn down.
The extensions proposed in this draft aim at allow for the recovery
path to have a different egress LSR (termination point) than the
primary LSP and allow for a physical merge of traffic back onto the
primary LSP at this termination point. To accomplish that an
extension is proposed as follows.
The LSP TUNNEL Session Attribute Object [RSVP-TE] can be added to the
Path message and includes additional control information. There is a
code point called "local protection" in [RSVP-TE] but the use of it
is unclear. If that codepoint cannot be used a new flag code is
proposed to be added to the FLAGS field.
0x09 Recovery path
This flag indicates that the tunnel is setup
as a pre-established recovery tunnel and should
be physical merged with the primary LSP at the
node where they share same session object.
To identify the Primary LSP at the PML the existing SESSION object,
instead of the LSPID, SHALL be used in the Path Message of the
recovery tunnel.
Whether further extensions to cover this case are needed is for
further study.
3.3 Recovery Path Resource Reservations
When protecting constraint based routed LSPs, resources may have been
allocated along their original route. When applying protection,
resource reservation may be desired to reserve for the recovery paths
as well. In case of segmenting the protection of the LSP, e.g.
applying local repair at each node, the recovery LSPs created to
protect the same LSP may share paths and nodes in the network.
Usually that would not be a problem but when resource reservations
are involved multiple allocations can be made for the same traffic.
To avoid this nodes along the recovery path MAY note the
- The primary LSPID carried in the Recovery TLV in the Label Request
Message defined for CR-LDP, or
- The Recovery path flag carried in the LSP TUNNEL Session Attribute
Object in RSVP-TE,
to identify the protected LSP and take further actions to prevent
multiple resource reservations.
4.0 Security Considerations
The MPLS extension that is specified herein does not raise any
security issues that are not already present in the MPLS
architecture.
Hellstrand et al. [Page 5]
Internet Draft draft-hellstrand-mpls-recovery-merge-01.txt Nov 2000
5.0 Intellectual Property Considerations
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
6.0 Acknowledgements
We would like to thank Philip Matthews, David Allan and Don Fedyk for
valuable input and comments.
7.0 Authors' Addresses
Fiffi Hellstrand
Nortel Networks
St Eriksgatan 115, PO Box 6701
113 85 Stockholm, Sweden
Ph: +46 8 5088 3687
e-mail: fiffi@nortelnetworks.com
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
8.0 References
[FRMWK] Makam, S. et al, "A Framework for MPLS-based Recovery",
Work in Progress, Internet Draft draft-ietf-mpls-recovery-frmwrk-
01.txt, November 2000.
[CR-LDP] Jamoussi et al, _Constraint-Based LSP Setup using LDP_
Work in progress, Internet Draft draft-ietf-mpls-cr-ldp-04.txt,
July 2000
[RSVP-TE] Awduche, D, et al, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", Work in Progress, Internet Draft draft-ietf-mpls-rsvp-
lsp-tunnel-05.txt, February, 1999.
[LDP] Andersson et al, "Label Distribution Protocol Specification",
Work in Progress, Internet Draft draft-ietf-mpls-ldp-08.txt, June
2000.
Hellstrand et al. [Page 6]