One document matched: draft-guerin-expl-path-rsvp-00.txt
Setting up Reservations on Explicit Paths using RSVP
draft-guerin-expl-path-rsvp-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 not appropriate to use Internet Drafts as
reference material, or to cite them other than as a ``working draft''
or ``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 ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
This document presents motivations for extensions to RSVP in order to
enable setting up of reservations on explicit routes. The advantages
of providing this support are discussed in the context of MPLS and
QoS routing. An approach to providing these extensions by means of
opaque routing objects in RSVP messages is presented.
Guerin, et al. Expires 3 February 1998 [Page i]
Internet Draft RSVP on Explicit Paths 29 July 1997
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Bandwidth Reservation for Explicit Route in an MPLS Environment 1
3. QoS Routing with Explicit Routes 3
3.1. QoS path management . . . . . . . . . . . . . . . . . . . 4
3.2. Enforcing high level admission control policies . . . . . 6
4. Mechanism for Reservation Set Up on Explicit Paths 7
4.1. Explicit Route Object . . . . . . . . . . . . . . . . . . 7
4.2. Processing of Explicit Route Objects . . . . . . . . . . 8
5. Conclusions 8
Guerin, et al. Expires 3 February 1998 [Page ii]
Internet Draft RSVP on Explicit Paths 29 July 1997
1. Introduction
The purpose of this document is to introduce and motivate extensions
to RSVP to enable setting up of reservations on explicit routes.
Enabling reservations on explicit routes can be useful in several
different contexts. In particular, it can be used to ensure that
certain flows use a ``label switched'' path as in the MPLS context
[CDF+97] or to facilitate the management of QoS paths computed by a
QoS capable router as in [GKO+97]. In this document, we describe
further these potential benefits, and show how they can be attained
with minimal impact to RSVP. It should be pointed out that the focus
of this document is on unicast flows as there are many other issues
that need to be addressed to consider the use of explicit routes for
multicast flows.
In the context of unicast flows, explicit routes are to be specified
through a new Explicit_Route object in RSVP. This object, like policy
objects, is opaque to RSVP which only needs to ensure its delivery to
routing. Routing is responsible for processing the Explicit_Route
object, and will use the information it contains to construct its
response to a Route_Query from RSVP.
Sections 2 and 3 motivate the need for explicit route support within
RSVP in the context of MPLS and QoS routing respectively. Section
4 describes the specific mechanism of setting up reservations on
explicit paths. This includes specification of a format for the
Explicit_Route object and the interactions between RSVP and routing
in this context.
2. Bandwidth Reservation for Explicit Route in an MPLS Environment
Consider the following topology:
A---B---C---D
| |
E-------F
Let us suppose that this topology exists in the network of an
Internet Service Provider (ISP). We suppose further that node A has
an interface to one of the ISP's subscribers, S1, and node B has
an interface to a different subscriber, S2. Finally, we suppose
that both subscribers are generating packets that are addressed to
destinations reachable only through node D.
Guerin, et al. Expires 3 February 1998 [Page 1]
Internet Draft RSVP on Explicit Paths 29 July 1997
In order to make the best provisioning of its bandwidth, the ISP may
decide that such packets from S1 should follow the route A-B-E-F-D,
while such packets from S2 should follow the route B-C-D. Further,
the ISP may want to reserve resources for each of these "flows", so
that it can schedule transmissions along the respective routes in a
way which corresponds to whatever agreements the ISP has made to the
particular subscribers.
Putting this decision into effect in a conventional IP network is
extremely difficult, since it requires that two packets going through
B, with the same destination, be sent on separate routes. Therefore,
ISPs tend to use ATM or Frame Relay networks to provide this level of
bandwidth management. ATM and Frame Relay networks also provide the
capability to support whatever resources reservations are necessary.
MPLS [CDF+97] provides a way for an ISP to obtain this functionality
without the need to resort to ATM or Frame Relay. In MPLS, node A
can apply a "label" to packets from S1 which must pass through D;
node B can apply a label to packets from S2 which must pass through
D. When a labeled packet is transmitted, the label is sent along with
it. Once a packet is labeled, the forwarding decision is based only
on the label, NOT on the contents of the packet header. Thus there
is nothing to prevent packet P1 from traveling the A-B-E-F-D path,
while packet P2 travels the B-C-D path, even if P1 and P2 happen to
have the very same destination address.
Of course, MPLS must incorporate some "path setup" procedure whereby
paths that differ from the "normal" IP routing can get explicitly set
up. MPLS must also incorporate some means of performing resource
reservation along these paths. While a resource reservation protocol
could be designed exclusively for MPLS, it would seem to make most
sense to use RSVP for that purpose; after all, RSVP was designed to
be the resource reservation protocol of the internet.
This requires some modification of RSVP. As currently specified,
there is no way to force an RSVP Path message to follow any path
other than the "normal" path to a particular destination. So if a
different MPLS path were set up for certain flows, there is currently
no way to get the Path message to follow that path.
If RSVP control messages could carry opaque objects that are
meaningful to routing and RSVP's interface to routing is broadened
as in [GKR97] so that RSVP could pass such objects to routing, then
this difficulty can be overcome. The Path messages could carry an
explicit route object. To determine the next hop for the flow, RSVP
would pass the Explicit Route Object (and other opaque objects if
present) to routing, which would pass back the identity of the next
hop, and a modified Explicit Route Object. This would force the Path
Guerin, et al. Expires 3 February 1998 [Page 2]
Internet Draft RSVP on Explicit Paths 29 July 1997
message to follow the path of the corresponding MPLS flow and ensure
that resources are reserved along the MPLS path.
The general ability to carry an opaque routing object in RSVP
messages further enables one to combine the setup of an MPLS path
with resource reservation along the same path. This could be
achieved by having a second opaque routing object carry an MPLS flow
identifier (label) in conjunction with the explicit route object.
Clearly, this approach has the advantage of avoiding a second round
trip to make reservations along the MPLS path when the path set up
itself must be done first. The need to have a second round trip
seems to simply add latency and complexity, without adding any value.
3. QoS Routing with Explicit Routes
An objective of QoS routing is to choose for each flow the path that
has the best likelihood of meeting the flow's QoS requirements,
while still making efficient use of network resources. In order
to achieve this goal, QoS routing requires knowledge of network
resources availability and of the QoS requirements of the flows.
This information can be provided in a number of ways (e.g., see
[CNRS97, GKR97] for possible approaches) and is then used by a QoS
path selection algorithm to identify an appropriate path for a flow.
The selection of a path and the distribution of the information
needed to make that selection, however, only represent a subset of
the functions needed to support QoS routing. There are two other
important issues that a QoS routing solution must address to meet its
objectives. These are:
1. Management of QoS paths of individual flows, and
2. Enforcing high level admission control policies.
Management of QoS paths includes not only setting up the paths
correctly, but also maintaining or adjusting them in response to
failures and changes in the network. High level (call) admission
policies are needed (see [CNRS97] for a discussion of this issue) to
control how selected paths are being used so as to preserve the long
term efficiency of the network. For example, a suitable path might
be found for a flow, but rejected by the high level admission control
because of its cost to the network, e.g., it is using a large number
of links which could alternatively be used to support several such
other calls to different destinations.
In the rest of this section, we articulate how explicit routes can
facilitate handling of these two issues. However, before doing
so, we briefly compare, in the context of QoS routing, the use of
Guerin, et al. Expires 3 February 1998 [Page 3]
Internet Draft RSVP on Explicit Paths 29 July 1997
explicit routes versus the hop-by-hop routing approach presented in
[GKO+97].
A hop-by-hop routing solution has the benefits of requiring the
least changes to RSVP and possibly offering added flexibility (see
[GKH97] for details), but this does come at a cost. Specifically,
with hop-by-hop routing, there are multiple decision points (each
hop) involved in selecting a path, with each making independent
decisions. As a result, end-to-end control of a path requires
coordination between the multiple decision points, and this can
often be a complex task. For example, even in the context of a link
state routing protocol such as OSPF where all routers in a domain
compute their routes using the same algorithm applied to a common
topology database, no single router has complete knowledge of the
actual path being followed. This is because inconsistencies during
routing transients as well as equal cost multi-path considerations,
independently affect local path selection decisions. Additional
mechanisms are, therefore, needed to coordinate these independent
decisions.
On the other hand, when explicit routes are used, selection of the
entire path is made at a single decision point (the first router in
the path). In the rest of this section, we expand on the benefits of
a single decision point in the context of both QoS path management
and high level call admission.
3.1. QoS path management
In best-effort routing, route changes occur relatively infrequently,
and mostly when local interfaces change state or when routing
updates are received from the routing protocol. With QoS routing,
changes that would result in the selection of a new route for a
given destination and QoS requirements are much more frequent, as
they typically occur each time a metric update is received. If such
changes were to trigger re-routing of existing QoS flows, this would
translate into disruption of service to already established flows.
Furthermore, this could also increase routing instability as such
re-routing may trigger additional metric updates and cause further
re-routing. Keeping a flow's routing state, i.e., the path on which
it has established a reservation, ``pinned'' as long as the path
remains satisfactory for the flow (and the network) is one possible
approach to this problem. Path pinning, however, has a number of
implications for QoS routing.
First, path pinning requires knowledge that the path being pinned is
adequate. This includes several aspects. First and foremost, the
pinned path should be loop free. When an explicit route is used,
Guerin, et al. Expires 3 February 1998 [Page 4]
Internet Draft RSVP on Explicit Paths 29 July 1997
this is readily achieved as the node selecting the explicit route can
ensure it is free of any loop. In contrast, when hop-by-hop routing
is used, the coordination of the multiple decision points involved in
the selection of the path requires not only that all nodes rely on
the same routing algorithm, but also imposes close coupling with RSVP
states to detect the formation of loops (see [GKH97] for details).
Such a coupling adds some complexity, but more importantly, it can
prevent the flow of data on the pinned path until after resources
have been successfully reserved on the entire path (see again [ref]
for details). In the case where reservations are successful on only
a portion of the path, this means that the data may not be able to
take advantage of such partial reservations. This is obviously
undesirable, and while this can possibly be remedied (see also
[GKH97] for possible approaches), solutions come at the cost of added
signaling and processing complexity.
Besides being loop free, a pinned path must also be capable of
satisfying the QoS requirements of the flow. Hence, it is important
either to ensure the availability of resources on a pinned path,
or to provide simple mechanisms to unpin it in case the required
resources are not available when they are being requested, e.g., when
an RSVP RESV message is received. Hence, the ability to detect such
conditions and trigger the unpinning of a path is required. This can
be achieved using similar mechanisms in both the explicit route and
hop-by-hop routing cases, and is further detailed in the next section
which expands on the approach of [GKH97]. Note that unpinning a path
only implies that QoS routing is being queried anew to determine if
the current path is still the correct one, or to find if a new and
better one now exists. In particular, unpinning a path does not
result in removal of existing path or reservation states. This is
because although the existing pinned path may not fully satisfy the
requirements of the flow, it may be the best one currently available.
In that case any (partial) reservation that may exist on the current
path should be maintained as it represents the best possible QoS
available to the flow.
There are other instances where a path needs to be unpinned. For
example, when one of the links or nodes on the path fails. In such
cases, it is important to notify all nodes on the current path, so
that they can unpin it and query QoS routing to possibly find an
alternate path. This can again be achieved using similar mechanisms
in both the explicit route and hop-by-hop routing cases [GKH97].
However, when a reservation is already in place, it is also desirable
to identify links on which resources are already reserved for the
flow. This is important so that these existing reservations be
taken into account when searching for an alternate path, i.e., avoid
the ``stepping on one's shadow'' problem. This is made easier in
the case of explicit route by the knowledge of the entire path.
Guerin, et al. Expires 3 February 1998 [Page 5]
Internet Draft RSVP on Explicit Paths 29 July 1997
Knowledge of the entire path is also useful in the context of high
level admission control, and we now briefly review this issue and the
benefits of explicit routes in that context.
3.2. Enforcing high level admission control policies
As pointed out in the framework document for QoS routing [CNRS97],
some form of higher level admission control and administrative
control of routing behavior may be necessary within an AS. This
is because QoS routing has to balance the sometimes conflicting
requirements of high network resource utilization and improved
chances of successful resource reservation for individual flows.
For example, when current load in the network suggests a QoS path
that is much longer than the ``usual'' path, admitting the flow
along such a path may actually deny service to later flows that
would have been admissible along segments of this long path. Hence,
this could negatively affect the overall network utilization. In
such situations, a high level admission control policy may find it
desirable not to admit the flow based on routing decision alone. One
possible approach is to compare the length of the path returned by
QoS routing to that of a ``usual'' path, and decide whether or not
to use the path depending on this comparison as well as possibly
other factors such as overall network load. Conversely, if a flow
has been already set up and later a much more efficient path becomes
available, it might be desirable to reroute the flow along the new
path. This is particularly true if the current path only supports a
fraction of the desired reservation, while the new path may be able
to accommodate the complete reservation.
In all such instances, these decisions are greatly facilitated when
a single entity is responsible for determining and controlling
the entire path. Hence, such controls are more readily performed
when routing is done using explicit routes instead of hop-by-hop
routing. This is not to say that they are not feasible with
hop-by-hop routing, but distributed decisions and knowledge generally
complicate such tasks. For example, transient inconsistent routing
information at multiple routers can lead to the pinning of a long
but loop-free path, without any single router on the path being
aware of the problem. Hence, it becomes difficult to identify and
rectify such bad routing choices. Solutions to this problem require
the introduction of additional signaling information to coordinate
information and decisions across the nodes on the path, e.g., a
policy object carried in PATH messages that specifies a limit on
the acceptable path length. This would in turn add to the overall
signalling and processing overhead, and may all but eliminate the
potentially greater simplicity of hop-by-hop routing. On the other
Guerin, et al. Expires 3 February 1998 [Page 6]
Internet Draft RSVP on Explicit Paths 29 July 1997
hand, the single decision point of explicit routes avoids most of
these problems.
4. Mechanism for Reservation Set Up on Explicit Paths
4.1. Explicit Route Object
As stated earlier, explicit routes are to be specified through a
new Explicit_Route object in RSVP. RSVP PATH messages will carry
this object. The format of the Explicit_Route object as shown below
consists of a (strict/loose) source route and a pointer indicating
the current position within the source route.
+-------------+-------------+-------------+-------------+
| Code | Length | Pointer | |
+-------------+-------------+-------------+-------------+
| IPv4 Hop 0 (src) Address (4 bytes) |
+-------------+-------------+-------------+-------------+
// //
+-------------+-------------+-------------+-------------+
| IPv4 Hop N (dst) Address (4 bytes) |
+-------------+-------------+-------------+-------------+
This is a new object class, with the C-type indicating IPv4. The
value of the Code field will indicate whether the sequence of IP
addresses represents a loose or a strict source route.
Semantics of Explicit Route Object correspond to the semantics of
the IP Strict or Loose Source Route Option as specified in RFC
1812, "Requirements for IP Version 4 Routers". As in the case of
processing of IP header source route option processing, routing at
intermediate gateways will overwrite the items in the address list
with their local network addresses, in effect recording the actual
traversed route. This facilitates avoidance of loops which may arise
in the case of a loose source route.
As described in Section 2 when MPLS is enabled, it may also be
desirable to combine the setup of an MPLS with the reservation of
resources along that path. This can be achieved through the use
of other opaque routing objects, that will carry the MPLS flow
information required for the associated path setup. Details on the
formats of those object are deferred to other documents dedicated to
the setup of MPLS flows.
Guerin, et al. Expires 3 February 1998 [Page 7]
Internet Draft RSVP on Explicit Paths 29 July 1997
4.2. Processing of Explicit Route Objects
Certain additional processing is involved when dealing with explicit
route objects as compared to processing a similar source route
option in an IP datagram. First, in case the source route object
suggests more than one possible outgoing interfaces, routing is free
to choose one from among them by any local means. However, it must
remember which one it chose, and make the same choice in response
to subsequent route queries from RSVP with the same explicit route
object. Second, in the event of errors in processing the route
object, in stead of generating ICMP messages as in the case of IP
datagram processing, routing will notify RSVP of an error. This
would trigger a PathErr message to the source with a new error code
("Cannot satisfy source route").
During the processing of the PATH message, RSVP will extract any
routing objects (if present) and pass them to routing. Routing
will parse these objects implementing their associated semantics
and return new opaque objects to replace the original ones in the
outgoing messages. As specified in [GKR97] this is achieved by means
of Route_Query and Route_Response interfaces:
- Route_Query interface is of the form:
Route_Query( flow_id, Network header, Transport Header,
notify_flag, sender_TSPEC, ADSPEC, opaque_object1,
opaque_object2, ...)
- Route_Reply is of the form: Route_Reply(flow_id, notify_flag,
outgoing_interface_mask, opaque_object1, opaque_object2, ...)
5. Conclusions
This document provides a motivation for supporting opaque routing
objects in RSVP to enable setting up resource reservations on
explicit routes. The benefits of this approach in the contexts of
MPLS and QoS routing were expounded and a mechanism for supporting
this feature was discussed.
References
[CDF+97] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow,
and A. Viswanathan. A Framework for Multi-Protocol
Label Switching (draft-ietf-mpls-framework-00.txt).
INTERNET-DRAFT, Internet Engineering Task Force, May 1997.
Guerin, et al. Expires 3 February 1998 [Page 8]
Internet Draft RSVP on Explicit Paths 29 July 1997
[CNRS97] E. Crawley, R. Nair, B. Rajagopalan, and H. Sandick.
A Framework for QoS-based Routing in the Internet
(draft-ietf-qosr-framework-00.txt). INTERNET-DRAFT,
Internet Engineering Task Force, March 1997.
[GKH97] R. Guerin, S. Kamat, and S. Herzog. QoS Path Management
with RSVP, (draft-guerin-qos-path-mgt-rsvp-00.txt).
INTERNET-DRAFT, Internet Engineering Task Force, March
1997.
[GKO+97] R. Guerin, S. Kamat, A. Orda, T. Przygienda, and
D. Williams. QoS Routing Mechanisms and OSPF Extensions,
(draft-guerin-qos-routing-ospf-01.txt). INTERNET-DRAFT,
Internet Engineering Task Force, March 1997.
[GKR97] R. Guerin, S. Kamat, and E. Rosen. Extended RSVP-Routing
Interface (draft-guerin-ext-rsvp-rtng-intf-00.txt).
INTERNET-DRAFT, Internet Engineering Task Force, July 1997.
Authors' Address
Roch Guerin
IBM T.J. Watson Research Center
P.O. Box 704
Yorktown Heights, NY 10598
EMAIL: guerin@watson.ibm.com
VOICE +1 914 784-7038
FAX +1 914 784-6205
Sanjay Kamat
IBM T.J. Watson Research Center
P.O. Box 704
Yorktown Heights, NY 10598
EMAIL: sanjay@watson.ibm.com
VOICE +1 914 784-7402
FAX +1 914 784-6205
Eric Rosen
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
EMAIL: erosen@cisco.com
Guerin, et al. Expires 3 February 1998 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-22 07:19:59 |