[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                        Bruce Davie
Internet Draft                                       Cisco Systems, Inc.
Expiration Date: May 1998
                                                                 Tony Li
                                                        Juniper Networks

                                                              Eric Rosen
                                                     Cisco Systems, Inc.

                                                           Yakov Rekhter
                                                     Cisco Systems, Inc.

                                                           November 1997

                     Explicit Route Support in MPLS


Status of this Memo

   This document is an Internet-Draft.  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 learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


   We define an `explicit route' as a route which is explicitly
   specified as a sequence of hops rather than being determined solely
   by conventional routing algorithms on a hop by hop basis. Using the
   explicit route object proposed for use in RSVP [1] and the ability to
   bind MPLS labels to RSVP flows [2] we describe how explicit routes
   may be set up in an MPLS environment. The resulting label switched

Davie, et al.                                                   [Page 1]

Internet Draft  draft-davie-mpls-explicit-routes-00.txt    November 1997

   paths may have associated resource reservations, or may be purely
   best effort.


    1      Introduction  ...........................................   2
    2      Overview of operation  ..................................   3
    2.1    Nested ER-LSPs  .........................................   4
    3      Message Formats  ........................................   4
    3.1    Path Message  ...........................................   4
    3.2    Reservation Message  ....................................   5
    4      Object Definitions  .....................................   6
    5      Security Considerations  ................................   6
    6      References  .............................................   7
    7      Acknowledgments  ........................................   7
    8      Author's Addresses  .....................................   7

1. Introduction

   The purpose of this document is to propose a standard method for
   establishing explicitly routed paths in an MPLS environment [3]. We
   define an explicit route as a path which is specified as sequence of
   hops, rather than being determined at each hop independently as is
   done with conventional IP routing. The specification of hops may be
   under operator control or may be the result of a decision made at one
   point in the network, e.g., on the basis of QOS requirements for
   certain traffic. The motivation for explicit routes and a mechanism
   for specifying them is described elsewhere [1]. This mechanism uses
   an explicit route object (ERO) carried in RSVP messages as the means
   for distributing the explicit route information to nodes along the
   path, enabling resource reservations to be made along explicitly
   routed paths.

   It is possible to bind MPLS labels to RSVP flows [2]. By combining
   this capability with an explicitly routed RSVP reservation, it is
   possible to set up an explicitly routed label switched path (ER-LSP).
   Because packets are label switched at every node on the path except
   the first, the selection criteria for packets to be sent on the
   explicit path must be known only to the first router in the LSP.
   While packets could be selected using standard RSVP filterspecs,
   there is no particular requirement that this be done. Packets could
   be selected for transmission on a certain LSP using a purely local
   policy. Because such policies are local to a single router, they need

Davie, et al.                                                   [Page 2]

Internet Draft  draft-davie-mpls-explicit-routes-00.txt    November 1997

   not be standardized and are not specified in this document. We note,
   however, that such policies could certainly apply to best effort
   packets. For example, a simple policy would be `send all packets
   which match prefix X in the routing table down this LSP.'

   Using RSVP to establish explicit paths clearly enables the allocation
   of resources to a path. For example, one could allocate bandwidth to
   an explicitly routed LSP using standard RSVP reservations and int-
   serv service classes (e.g. [5]). While this may often be useful, it
   is not required. Thus an ER-LSP may be used to carry best effort

   This document specifies how RSVP, along with the explicit route
   object [1] and the label object [2], can be used to establish
   explicitly routed LSPs. It also specifies a new subtype of label
   object that is required when setting up explicitly routed LSPs. The
   document specifies only the unicast case. Explicitly routed multicast
   paths are for further study.

2. Overview of operation

   When using RSVP to establish an ER-LSP, the only sender to the
   session is the first node of the ER-LSP and the destination of the
   session is the last node of the ER-LSP. The creation of an ER-LSP is
   initiated by the sender to the session, i.e. the first node in the
   ER-LSP. This may be as the result of operator actions on that node or
   some other means beyond the scope of this document.

   The first node creates an RSVP PATH message and inserts an ERO into
   it. It also inserts a LABEL_REQUEST object. The LABEL_REQUEST object
   indicates that a label binding for this path is requested, and also
   provides an indication of the network layer protocol that is to be
   carried over this path. The reason for this is that the network layer
   protocol sent down an ER-LSP cannot be assumed to be IP, and cannot
   be deduced from the L2 header, which simply identifies the higher
   layer protocol as being MPLS.

   The PATH message is forwarded towards its destination along a path
   specified by the ERO. Each node along the path records the ERO in its
   path state block. Nodes may also modify the ERO before forwarding the
   PATH message, in which case the modified ERO should be stored in the
   path state block. The rules for processing EROs are specified in [1].

   When the PATH message reaches its destination, the destination node
   observes the presence of the LABEL_REQUEST object and as a result
   generates a reservation message for the corresponding session. The
   destination node allocates a label and places it in the LABEL object.

Davie, et al.                                                   [Page 3]

Internet Draft  draft-davie-mpls-explicit-routes-00.txt    November 1997

   The LABEL object is inserted in a RESV message, and the RESV message
   is sent back towards the sender. A node that receives a RESV
   containing a label uses that label for outgoing traffic on this path.
   It also allocates a new label and places that label in the LABEL
   object of the RESV message before sending it upstream. This is the
   label that this node will use for incoming traffic on this path. The
   procedures for label allocation and forwarding of packets are exactly
   as described in [2].

   As a result of these operations, a label switched path is established
   from the sender to the destination of the session, following the
   explicitly routed path specified in the ERO.

   When resources are to be allocated to an ER-LSP, the sender TSpec in
   the path message is used to specify the traffic that will be sent
   down the path. The last node in the ER-LSP uses that information to
   construct an appropriate Receiver TSpec and RSpec.

   If a PATH message containing a LABEL_REQUEST object reaches a node
   that cannot allocate a label for incoming data, that node must
   respond to the sender of the PATH message with a PATH_ERROR message.

2.1. Nested ER-LSPs

   In principle it is possible to nest ER-LSPs inside each other using a
   stack of labels. Such use of ER-LSPs is not discussed in this version
   of the document, and is for further study.

3. Message Formats

   This section defines the PATH and RESV message formats that will be
   used when setting up ER-LSPs.

3.1. Path Message

   The format of a Path message is as follows:

Davie, et al.                                                   [Page 4]

Internet Draft  draft-davie-mpls-explicit-routes-00.txt    November 1997

          <Path Message> ::= <Common Header> [ <INTEGRITY> ]
                                <SESSION> <RSVP_HOP>
                                <TIME_VALUES> <EXPLICIT_ROUTE> <LABEL_REQUEST>
                                [ <POLICY_DATA> ... ]
                                [ <sender descriptor> ]

          <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>

   All of these fields have the standard definitions as provided in [4],
   with the exception of the EXPLICIT_ROUTE object [1] and the
   LABEL_REQUEST object defined below. The SESSION object contains the
   address of the end point of the ER-LSP. In order to allow multiple
   tunnels to share the same set of end points, the SESSION object may
   contain a port number. The port number in this case effectively
   becomes an identifier for the ER-LSP. The SENDER_TEMPLATE contains
   the address of the first node in the ER-LSP. It need not contain port
   numbers. The SENDER_TSPEC may be a standard Integrated Services TSpec
   [5,6]. In the case of ER-LSPs which are for best effort traffic and
   thus require no resources to be allocated, the Controlled Load
   service should be used with burst size and rate of zero.

3.2. Reservation Message

   The format of a Reservation Message is as follows:

           <Resv Message> ::= <Common Header> [ <INTEGRITY> ]
                                   <SESSION>  <RSVP_HOP>
                                   [ <RESV_CONFIRM> ]  [ <SCOPE> ]
                                   [ <POLICY_DATA> ... ]
                                   <STYLE> <LABEL> [<flow descriptor>]

   All of these fields have the standard defintions as provided in [4],
   with the exception of the LABEL object [2]. The Session object is
   copied from the Path message which caused the ER-LSP to be set up. In
   the case where no resources are allocated to the ER-LSP, as indicated
   by a Sender TSpec in the Path message which has zero burst size and
   bandwidth, the flow descriptor should be absent. When the Sender
   TSpec indicates that resources are to be reserved, the style should
   be WF, and the flow descriptor is just a flowspec derived from the
   Sender TSpec. [It is straightforward to derive a controlled load

Davie, et al.                                                   [Page 5]

Internet Draft  draft-davie-mpls-explicit-routes-00.txt    November 1997

   flowspec from a Sender TSpec, so controlled load is recommended as
   the service class in this case.]

4. Object Definitions

   A Label object for use in RSVP messages is described in [2]. We
   introduce a new sub-object, the LABEL_REQUEST object.

        class = RSVP_LABEL, C_Type = 2

                   0             1              2             3
            |         Reserved          |           L3PID           |

   The L3PID is an identifier of the layer 3 protocol using this path.
   Standard Ethertype values are used.

5. Security Considerations

   We assume that the security procedures defined for RSVP will handle
   any security issues that arise from coupling label switching with
   RSVP. For example, mechanisms that are used to authenticate RSVP
   resource reservation requests may also be used to authenticate
   requests to establish explicitly routed label switched paths.

   It may be desirable to enable the setup of ER-LSPs without enabling
   general purpose resource reservations. This would be done using the
   policy mechanisms defined for RSVP. It is likely that explicitly
   routed paths would often be setup only within a single administrative
   domain, and thus RSVP requests from outside the domain would be

Davie, et al.                                                   [Page 6]

Internet Draft  draft-davie-mpls-explicit-routes-00.txt    November 1997

6. References

   [1] Guerin, R. et al. RSVP on Explicit Paths, Internet Draft, draft-
   guerin-expl-path-rsvp-01.txt, Nov. 1997.

   [2] Davie, B. et al. Use of Label Switching With RSVP, Internet
   Draft, draft-davie-mpls-rsvp-01.txt, Nov. 1997.

   [3] Rosen, E. et al. A Proposed Architecture for MPLS,  Internet
   Draft, draft-ietf-mpls-arch-00.txt, Aug. 1997.

   [4] Braden, R. et al. Resource ReSerVation Protocol (RSVP) -- Version
   1 Functional Specification, RFC 2205, Sep. 1997.

   [5] Shenker, S. et al. Specification of Guaranteed Quality of
   Service, RFC 2212, Sep. 1997.

   [6] Wroclawski, J. Specification of the Controlled-Load Network
   Element Service. RFC 2211, Sep. 1997.

7. Acknowledgments

   Significant contributions to this work have been made by

8. Author's Addresses

   Bruce Davie
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   E-mail: bsd@cisco.com

   Tony Li
   Juniper Networks
   385 Ravendale Dr.
   Mountain View, CA 94043

   E-mail: tli@juniper.net

Davie, et al.                                                   [Page 7]

Internet Draft  draft-davie-mpls-explicit-routes-00.txt    November 1997

   Eric Rosen
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   E-mail: erosen@cisco.com

   Yakov Rekhter
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA, 95134

   E-mail: yakov@cisco.com

Davie, et al.                                                   [Page 8]