Internet Draft 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 draft-davie-mpls-explicit-routes-00.txt 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). Abstract 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. Contents 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 traffic. 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::= [ ] [ ... ] [ ] ::= 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: ::= [ ] [ ] [ ] [ ... ]