Internet DRAFT - draft-guerin-ext-rsvp-routing-intf
draft-guerin-ext-rsvp-routing-intf
Internet Engineering Task Force R. Guerin/S. Kamat/E. Rosen
INTERNET DRAFT IBM/IBM/Cisco
29 July 1997
Extended RSVP-Routing Interface
draft-guerin-ext-rsvp-routing-intf-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 describes an extended interface between RSVP and
routing, whose purpose is to support a broader range of routing
mechanisms than allowed by the current recommended interface [Zap96].
The extensions being proposed aim at ensuring that RSVP provides
routing with ALL the information that routing may need in order to
make its decision.
Guerin, et al. Expires 3 February 1998 [Page i]
Internet Draft Extended RSVP-Routing Interface 29 July 1997
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Interface Requirements 2
2.1. Explicit Route Support . . . . . . . . . . . . . . . . . 3
2.2. QoS Routing Support . . . . . . . . . . . . . . . . . . . 3
3. Conclusions 7
Guerin, et al. Expires 3 February 1998 [Page ii]
Internet Draft Extended RSVP-Routing Interface 29 July 1997
1. Introduction
The purpose of RSVP is to set up resource reservations for specified
``flows''. In order to do so, the RSVP module at a given router
must be able to find out a flow's ``next hop''. RSVP does not do
any routing itself; the only way it can find out a flow's next hop
is through an interface to routing. RSVP messages must carry enough
information about a flow to enable routing to determine the next
hop for that flow. RSVP must pass this information to routing, and
routing must pass back the next hop.
In the internet routing schemes which are most commonly deployed
today, a packet's next hop is a function of its destination address,
or perhaps of both its source and destination addresses. In the
existing interface between RSVP and routing, RSVP passes these
addresses to routing, and routing passes back the corresponding next
hop.
While this interface may be sufficient for existing routing schemes,
there are IETF working groups actively working on enhanced routing
schemes for which this interface is not sufficient.
In the context of policy routing, for example, it may be desirable to
use different routes for flows belonging to different applications
-- perhaps video conference traffic should use a different route
than web traffic, even if the packets of these two flows have the
same source and destination addresses. Alternatively, certain
applications may be restricted to using only secure links. If RSVP
is to support this type of routing, its interface to routing must
allow it to pass information such as port numbers in addition to IP
addresses. In general, we want RSVP to make available to routing ALL
the information that might be of relevance for routing to make its
decision.
However, RSVP should NOT need to know which bits in the packet header
are significant to routing. To maintain true independence from
routing, RSVP should, therefore, pass the entire header across its
routing interface, and even this may not suffice in all cases. For
example, when MPLS or QoS routing with explicit routes are in use,
the choice of a next hop will typically depend on information above
and beyond what is specified in the network and transport layer
headers. With both MPLS and explicit QoS routes, different routes
may have been selected for flows with identical network/transport
layer headers, and it is important that RSVP allow conveying of this
information. A possible approach that preserves the independence of
RSVP from routing is to allow RSVP to pass ``opaque'' objects across
its interface to routing. These objects would not be interpreted
by RSVP and would carry information meaningful only to a particular
Guerin, et al. Expires 3 February 1998 [Page 1]
Internet Draft Extended RSVP-Routing Interface 29 July 1997
routing scheme, i.e., enable the identification of the specific next
hop for the flow.
It should be noted that the assignment of different routes to
individual flows headed to the same destination address implies
that the forwarding decision itself is extended to support such a
differentiation. In the case of QoS routes for RSVP flows, this
could be achieved by linking the flow classifier and forwarding
functions, i.e., include information such as source and destination
address and port numbers into the forwarding decisions. In this
case, the extension of the forwarding function is achieved using
information already present in the network and transport headers. In
other instances such as MPLS, where the forwarding decision is made
on the basis of labels, it is necessary to correlate label and route
information. This can again be achieved through the use of opaque
objects carried by RSVP, e.g., a ``route'' and a ``label'' object,
that should both be made available to routing.
This document describes an extended interface between RSVP and
routing, which is capable of supporting routing enhancements such as
QoS routing, policy routing, MPLS, etc.
In the next section, we motivate further the need for an expanded
interface between RSVP and routing, and illustrate its use in the
case of explicit and QoS routes. In Section III, we present a
candidate interface that provides the desired functionality.
2. Interface Requirements
In general, the interface between RSVP and routing should allow
communication of any information necessary to characterize individual
flows, as well as all the information that may be needed to identify
an appropriate route for a given flow. For example, this would
include, in addition to source and destination addresses and port
numbers, information such as TSpec, ADSPEC, EXPLICIT_ROUTE object,
and an MPLS label (if any). The basic principle to be applied to the
design of this interface, is that RSVP should not second guess what
routing needs in order to make appropriate decisions. In particular,
it is preferable that the interface between RSVP and routing allow
passing of more information than may be strictly needed by routing,
and that routing discard any unnecessary information. In Section
III, we outline a possible definition for such an extended interface,
but illustrate first how additional information made available across
this interface can be used in the context of two specific examples.
Guerin, et al. Expires 3 February 1998 [Page 2]
Internet Draft Extended RSVP-Routing Interface 29 July 1997
2.1. Explicit Route Support
Currently, there is no provision to carry explicit route information
within RSVP control messages. However, in the context of
unicast flows, explicit routes could be specified through a
new Explicit_Route object in RSVP. A possible format for the
Explicit_Route object is described in [GKR97] wich shows an
Explicit_Route object consisting of a (loose) source route and a
pointer indicating the current position within the source route.
This object, like policy objects, is opaque to RSVP. It can be
generated anywhere on the path of a flow, and specifies a subset of
links on which the flow is to be routed. RSVP's only responsibility
and involvement is to carry the object in PATH messages, and to make
it available to routing.
Processing of the Explicit-Route object is performed entirely
by routing, that uses the information contained in the object to
determine the next hop on which the PATH message should be forwarded.
In doing so, routing will identify the outgoing link currently
pointed to in the Explicit_Route object, and update the pointer
before returning the modified Explicit_Route object and the next
hop information to RSVP. This is similar to the interactions that
take place between RSVP and policy, where RSVP provides policy with
an incoming policy object, and where policy returns to RSVP both an
outgoing policy object and a policy decision (accept, reject, etc.).
Support for explicit routes, therefore, only requires from RSVP
that it make available to routing the information needed by routing
to identify the appropriate next hop. This does not impact RSVP's
semantics or functionality, or increase its involvement in routing
decisions. It only requires that RSVP carry the relevant information
in an opaque object, just as it does for policy information, and that
it make that object available to routing.
2.2. QoS Routing Support
Another case which benefits from an extended interface between RSVP
and routing is that of QoS routing. The objective of a QoS sensitive
path selection 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. The first step towards achieving
this goal is to make the QoS requirements of individual flows known
to routing. In particular, knowledge of a sender TSpec can help
routing estimate the likely resource requirements of the flow and
choose a path for the flow accordingly. Hence, it is important that
RSVP make that information available to routing when initiating its
Route_Query.
Guerin, et al. Expires 3 February 1998 [Page 3]
Internet Draft Extended RSVP-Routing Interface 29 July 1997
Another important aspect of QoS routing is QoS path management,
that deals with maintaining or adjusting existing paths to ensure
that they remain adequate. In particular, this involves preventing
service disruption to existing flows by avoiding unnecessary
rerouting of these flows when their current resource reservations
are satisfactory, while also reacting appropriately to link or
reservation failures that affect the flow's quality of service
guarantees.
Path management can be performed by either RSVP or routing. However,
in order to avoid burdening RSVP with functions that fall outside of
the scope of a resource reservation setup protocol, path management
should be the responsibility of QoS routing and not of RSVP. This is
consistent with the use of the notify flag defined in the current
interface between RSVP and routing, where routing is responsible
for detecting the failure of the path of an existing flow and
asynchronously notifying RSVP of this event. In the case of QoS path
management, additional failure conditions need to be considered,
e.g., reservation failures, so that a single flag is not sufficient
to support this function. This is best illustrated by an example
that will motivate the need for extended notification capabilities
between RSVP and routing.
Consider the case where QoS routing has selected a path for a given
flow, and pins it, i.e., remembers that the flow has been assigned to
this path, to avoid continuous rerouting of the flow as the network
load conditions change. Pinning prevents unwanted changes, but
requires additional steps to unpin the path in case of failures. For
example, it may turn out that when flow actually attempts to reserve
resources on the path it has been assigned (a RESV message is sent),
the reservation fails at some link. Alternatively, a link failure at
a node may also invalidate an existing path. In those instances, it
is important that RSVP and routing be able to notify each other of
any such event (RSVP would notify routing of a reservation failure
and routing would inform RSVP of a link failure), so that alternate
paths can be explored. Rerouting around a failure can be attempted
either at the node where the failure occurred (local repair), or
at some upstream node (local repair fails or is not attempted).
If rerouting is to take place at an upstream node, that node must
then be informed that it needs to perform such a task. This can be
achieved [GKH97] through the use of PATH_ERR messages with specific
error codes (reservation failure or link failure), but this would
again require that RSVP notify routing of the receipt of such a
message.
In general, QoS path management is best supported using a generic
asynchronous notification interface between RSVP and routing.
In the next section, we outline a possible interface definition
Guerin, et al. Expires 3 February 1998 [Page 4]
Internet Draft Extended RSVP-Routing Interface 29 July 1997
that satisfies this requirement, and allows communication of all
the information that routing may need to make flow specific path
assignments.
III. RSVP Routing Interface
The interface described here is an extension of the asynchronous
query reply interface described in [Zap96]. As motivated in the
previous section, the extension involves:
1. inclusion of additional parameters in Route_Query and Route_Reply
to enable reservation setup on explicit paths and paths selected
using QoS routing, and
2. addition of two new APIs RSVP_Event and Routing_Event that can
be used by RSVP and routing, respectively, to asynchronously
notify each other of events that are significant for QoS path
management.
Details on the interface are provided next.
- 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_Query is used by RSVP to find the outgoing interface for
sending out a PATH message.
* flow_id is a local handle that defines the context for RSVP
query for a flow. It is used to match the later asynchronous
Query_Reply and Routing_Event messages from routing.
* network and transport headers are used by routing to
individuate flows
* TSpec and ADSPEC information facilitate selection of a path
likely to meet the QoS requirements of the flow
* a variable number of opaque objects that RSVP PATH message
may carry without any interpretation are also passed to
routing. An example of such object is the explicit route
object defined in [GKR97].
- Routing responds to a Route_Query with a Route_Reply that
identifies the outgoing interface(s) on which the PATH message is
Guerin, et al. Expires 3 February 1998 [Page 5]
Internet Draft Extended RSVP-Routing Interface 29 July 1997
to be forwarded and provides a list of opaque objects that should
be transmitted in the outgoing PATH message.
Thus Route_Reply is of the form:
Route_Reply(flow_id, notify_flag, outgoing_interface_mask,
opaque_object1, opaque_object2, ...)
* notify_flag is used to inform RSVP of the status of a route
notification request made in the corresponding Route_Query,
i.e., whether it is supported or not.
- In addition to extensions to Route_Query and Route_Reply, the
interface also allows RSVP and routing to asynchronously notify
each other of significant events in their respective domains.
Specifically, this is supported through two generic API's as
follows:
1. RSVP_Event(flow_id, event_code, event_value)
RSVP_Event is used by RSVP to notify routing of a specific
event concerning a flow. The following events are defined
for this purpose:
* local reservation failure (event_code, event_value TBD)
* receipt of a PATH_ERR message with an error code that
indicates a link or reservation failure downstream, or
inability to support the requested explicit route. The
actual type of error would be specified through the use
of (event_codes, event_values TBD). event_value would
typically include the IP address of the node where the
failure occurred as specified in the Error_Node field of
the received PATH_ERR message.
* removal of a PATH state due to time out or receipt of a
PATH_TEAR message. (event_code, event_value TBD)
* change in PHOP or IP_TTL value in the path state of a
flow. (event_code, event_value TBD) (NB. This event
has significance for loop avoidance in case of QoS path
management when hop by hop routing instead of explicit
routes are used. See [GKH97] for details. It is listed
here for the sake of completeness.)
Conversely, routing will notify RSVP using the following API:
2. Routing_Event(flow_id, event_code, event_value)
Guerin, et al. Expires 3 February 1998 [Page 6]
Internet Draft Extended RSVP-Routing Interface 29 July 1997
Currently, only one following event is defined that
generalizes the existing notify flag.
* failure of the current path that needs to be notified to
upstream routers. (event_code, event_value TBD).
Routing will use this event to notify RSVP of a local link
failure that affects the path of the specified flow. Upon
being notified of such a failure, RSVP is expected to either
query routing anew to attempt to locally reroute the flow
(if supported), or to send a PATH_ERR message with the
appropriate event_code (link failure) to upstream routers so
that rerouting can be attempted there.
3. Conclusions
This document provides a rationale for extending the interface
between RSVP and routing, so as to support additional routing
capabilities. The examples of explicit routes and QoS routes
were presented to both illustrate and motivate the needs for such
an extension.
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.
[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.
[GKR97] R. Guerin, S. Kamat, and E. Rosen. Setting
up Reservations on Explicit Paths Using
RSVP (draft-guerin-expl-path-rsvp-00.txt).
INTERNET-DRAFT, Internet Engineering Task Force,
July 1997.
[Zap96] D. Zappala. RSRR: A Routing Interface for RSVP
(draft-ietf-rsvp-routing-01.ps). INTERNET-DRAFT,
Internet Engineering Task Force - RSVP WG, November
1996.
Guerin, et al. Expires 3 February 1998 [Page 7]
Internet Draft Extended RSVP-Routing Interface 29 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 8]
