Internet Draft                             Fiffi Hellstrand
Multi-Protocol Label Switching             Loa Andersson
Expiration Date: January 2001              Nortel Networks

                                           July 2000



       Extensions to CR-LDP and RSVP-TE for setup
         of pre-established recovery tunnels

      <draft-hellstrand-mpls-recovery-merge-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
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



Hellstrand, Andersson.                                  [Page 1]

Internet Draft draft-hellstrand-mpls-00.txt            July 2000

merge operation differs in a number of details from that employed for
a normal MP2P 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.


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

4.0 Security Considerations
5.0 Intellectual Property Considerations
6.0 Author's Addresses
7.0 References

1.0 Introduction

Protection of traffic is growing in importance and especially
recovery schemes that can provide fast restoration. 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.


Hellstrand, Andersson.                                  [Page 2]

Internet Draft draft-hellstrand-mpls-00.txt            July 2000

2.0 Protection of ER-LSP

To protect from a link or node failure an ER-LSP recovery tunnel is
setup between the switching and the merging node to form an LDP
adjacency. To protect an ER-LSP the recovery path is explicitly
routed to circumvent a potential failure point. 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.

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.


Hellstrand, Andersson.                                  [Page 3]

Internet Draft draft-hellstrand-mpls-00.txt            July 2000

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.

The encoding for the R-LSP TLV is as follows:

                   1                   2                   3
 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.


Hellstrand, Andersson.                                  [Page 4]

Internet Draft draft-hellstrand-mpls-00.txt            July 2000

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 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 andallow 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. Ifthat codepoint cannot be used a new flag code
is proposed to be added to the FLAGS field.


Hellstrand, Andersson.                                  [Page 5]

Internet Draft draft-hellstrand-mpls-00.txt            July 2000

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 can be used in the Path Message of the
recovery tunnel.

Whether further extensions to cover this case are needed is for
further study.

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.

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 AuthorsÆ Addresses

Fiffi Hellstrand
Nortel Networks
St Eriksgatan 115, PO Box 6701
 85 Stockholm, Sweden
Ph: +46 8 5088 3687
e-mail: fiffi@nortelnetworks.com

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


Hellstrand, Andersson.                                  [Page 6]

Internet Draft draft-hellstrand-mpls-00.txt            July 2000

7.0 References

[FRMWK] Makam, S. et al, "A Framework for MPLS-based Recovery", Work
in Progress, Internet Draft, draft-makam-mpls-recovery-frmwrk-00.txt,
Dec. 2000.

[CR-LDP] Jamoussi et al, ôConstraint-Based LSP Setup using LDPö work
in progress (draft-ietf-mpls-cr-ldp-04.txt), July 2000

[RSVP-TE] Awduche, D, et al, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", Internet Draft, Work in Progress, draft-ietf-mpls-revp-lsp
-tunnel-05.txt,February, 1999.

[LDP] Andersson et al, "Label Distribution Protocol Specification",
work in progress (draft-ietf-mpls-ldp-08), June 2000.