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
<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>
<TIME_VALUES>
[ <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
ignored.
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]