Internet Engineering Task Force                            Juha Heinanen
INTERNET DRAFT                                             Telia Finland
Expires August 2000                                       February, 2000


                     Soft Permanent LSPs for CR-LDP
                   <draft-heinanen-mpls-splsp-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.

   Distribution of this memo is unlimited.

Abstract

   This document extends CR-LDP with capability to establish Soft
   Permanent LSPs (SPLSPs).  A SPLSP is an LSP which originates or
   terminates at a label switched interface of an MPLS node.

1. Introduction

   A Soft Permanent LSP (SPLSP) is an LSP, which originates, terminates,
   or both originates and terminates at a label switched interface of an
   MPLS node.  SPLSPs are useful, for example, in cases where an MPLS
   domain does not want to dynamically exchange MPLS control information
   with another MPLS domain or where an MPLS node, such as a CPE node,
   does not implement an MPLS control protocol.  SPLSPs are also useful
   for the dynamic reestablishment of LSPs following node or trunk
   failures if the MPLS network does not support other protection



Heinanen             Soft Permanent LSPs for CR-LDP             [Page 1]

INTERNET DRAFT                                            February, 2000


   mechanisms.  In this case, the originating MPLS node would detect
   when an established SPLSP fails, and would then automatically reissue
   the required Label Request Message to reestablish the SPLSP.

   This document defines the SPLSP capability for CR-LDP [1].

2. Messages

   The MPLS node where an SPLSP originates from "owns" the SPLSP and is
   responsible for establishing and (in case of failure) reestablishing
   it.

   If an SPLSP terminates at an interface of an MPLS node, the
   originating MPLS node initiates the SPLSP establishment by a CR-LDP
   Label Request Message.  In the Label Request Message the terminating
   interface is identified by an IP host address carried in the last ER-
   Hop of the ER-TLV, whereas the label to be used at that interface for
   the SPLSP is carried in the Label TLV.

   If an SPLSP terminates at an MPLS node itself, the originating MPLS
   node initiates the SPLSP establishment using a normal CR-LDP Label
   Request Message, where the terminating MPLS node is identified by an
   IP host address carried in the last ER-Hop of the ER-TLV.

   In the originating MPLS node the method of identifying the origin of
   the SPLSP (the node itself or one of its interfaces as well as the
   label to be used for the SPLSP at the possible interface) is a local
   matter and thus outside the scope of this document.

3. Procedures

   If a CR-LDP Label Request Message includes a Label TLV, it is a Label
   Request Message for SPLSP establishment.  The procedures of Label
   Request Message for SPLSP establishment are as follows.

   A Label Request Message for SPLSP establishment is processed at the
   originating MPLS node and at all intermediate nodes according to
   normal CR-LDP rules except that the normally nonexistent Label TLV is
   forwarded opaquely.

   At the terminating MPLS node, a Label Request Message for SPLSP
   establishment is processed according to the normal CR-LDP rules
   except that the last ER-Hop of the ER-TLV identifies the interface
   where the SPLSP terminates and the Label TLV contains the value of
   the label to be used for the SPLSP at that interface.  If the
   requested label value is not available at the terminating interface,
   the terminating MPLS node sends a Notification message to the
   originating MPLS node with Status Code "Label Value Not Available".



Heinanen             Soft Permanent LSPs for CR-LDP             [Page 2]

INTERNET DRAFT                                            February, 2000


4. Security Considerations

   SPLSPs share the security concerns of regular CR-LDP LSPs.  It is
   also worth noting that when an SPLSP originates or terminates at an
   interface of an MPLS node, the entity using the SPLSP at that
   interface is dependent on the provider of the SPLSP for routing of
   the SPLSP to or from the correct other entity.

5. Acknowledgements

   The author thanks Eric Gray and Andrew Malis both from Lucent for
   their comments on an earlier version of this document.

5. Author Address

   Juha Heinanen
   Telia Finland, Inc.
   Myyrmaentie 2
   01600 Vantaa, Finland
   Email: jh@telia.fi































Heinanen             Soft Permanent LSPs for CR-LDP             [Page 3]