Internet Engineering Task Force R.Guerin/D.Kandlur/L.Li/V.Srinivasan
INTERNET DRAFT IBM
L.Berger
Fore
30 July 1997
Support of Shortcuts for RSVP Flows Over ATM
draft-guerin-issll-rsvp-shortcut-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
Support for RSVP flows across an ATM network has been defined in
[BB97, GB97, Ber97a]. Although the use of shortcuts was mentioned in
[BB97, Sec. 3.7], and [Ber97a, Sec. 3.6] the current specifications
do not address this case in sufficient details so as to allow
interoperable implementations. The purpose of this document is to
identify issues in using ATM shortcuts for RSVP flows. For purposes
of illustrations, the NHRP protocol [LKPC97] will be assumed as
the mechanism used to discover shortcuts, and a possible interface
between RSVP and NHRP will be outlined. However, it should be noted
that other shortcut mechanisms are possible, e.g., PAR [J96], and
the general conclusions of this document should also hold in such
cases. Since the issue of shortcut discovery is significantly more
complex in the multicast case, for which in most instances has not
been defined, e.g., NHRP, this document is limited to the case of
unicast flows.
Guerin, et al. Expires 4 February 1998 [Page i]
Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997
Contents
Status of This Memo i
Abstract i
1. Overview and Issue 1
1.1. General Design Principles . . . . . . . . . . . . . . . . 3
2. RSVP Shortcut Interactions 5
2.1. RSVP Control Message Handling . . . . . . . . . . . . . . 5
2.2. Data VC Operations . . . . . . . . . . . . . . . . . . . 7
2.3. Error Handling Scenarios . . . . . . . . . . . . . . . . 8
3. Sample RSVP-NHRP Interface 9
4. Interaction with MPOA 11
5. Example of RSVP Shortcut 12
Guerin, et al. Expires 4 February 1998 [Page ii]
Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997
1. Overview and Issue
In order to understand the implications of establishing and using
shortcuts for RSVP flows across ATM networks, it is helpful to first
review how shortcuts are established and used. For purposes of
illustration, we focus on the case of the NHRP protocol (Next-Hop
Routing Protocol) [LKPC97]. However, most of the conclusions would
also hold when using other shortcut establishment mechanisms, e.g.,
PAR [J96].
NHRP is a next hop discovery protocol, that allows progressive
discovery of the layer 2 addresses of layer 3 next hops for a given
network (IP) destination address. In other words, NHRP allows a
network layer protocol such as IP to propagate a query to determine
whether, for a given destination (or sets of destinations), some of
the network layer routing hops can be bypassed by establishing a
shortcut across the layer 2 (ATM) topology. This is illustrated in
Figure 1, where ATM switches are represented with triangles, while
rectangles are used for IP routers.
_ _ _ _
|_|R2 |_|R3 |_|R4 |_|R5
\ \ \ /
\ \ \ /
_ _s1 \_s3 \_s5 \ _/ _s8 _
R1|_|---/_\-------/_\---------/_\---------/_\----/_\-----|_|R6
\ | | / s7 /
\ --- --- / /
\ \ / / /
\ _s2 \ _ / s6_ / /
/_\--------/_\---------/_\------/
s4
Routed path: R1-(s1-s3)-R2-(s3-s5)-R3-(s5-s7)-R4-(s7)-R5-(s7-s8)-R6
Shortcut: R1-(s1-s2-s4-s6-s8)-R6
Figure 1: Routed Path vs Shortcut.
Irrespective of whether they are obtained through NHRP or some
other means, the potential benefits of shortcuts are to off-load
network layer processing of the packets from the routing hops being
bypassed, and also to possibly achieve better delay and/or throughput
performance for the data flow between the source and the destination.
In the case of RSVP flows, another benefit is the opportunity to
Guerin, et al. Expires 4 February 1998 [Page 1]
Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997
better leverage the layer 2 topology to support QoS requirements,
i.e., improve the likelihood that the necessary resources (bandwidth
and buffer) are available.
There are two main aspects to the use of ATM shortcuts for
RSVP. The first concerns the internal (within the router or the
RSVP-ATM gateway) interactions between RSVP and the shortcut
establishment mechanism, e.g., NHRP. The second, and possibly more
important, aspect deals with the external flows associated with the
establishment of shortcuts, and in particular their coexistence with
existing uses of shortcut mechanisms, i.e., for non-RSVP flows.
In many implementations, the decision to establish a shortcut for
some best effort traffic flow is traffic dependent. For example,
a shortcut request is triggered only when the traffic volume to
the destination exceeds a certain threshold, and thus warrants the
overhead (signaling and support of an additional VC) of setting up
the shortcut. In addition, how long the shortcut remains in effect
is also typically traffic dependent, so that a shortcut will be taken
down if the amount of traffic falls below a given threshold, or
after some time-out period. This means that the "routes" associated
with shortcuts, in addition to violating network protocol rules by
crossing subnet boundaries, are also temporary in nature. As a
result, routes associated with shortcuts will normally NOT show-up in
the "standard" IP routing table, and will only be reflected in the
forwarding information base of the router.
The limited visibility, to IP routing, of shortcuts has some
implications for RSVP. Specifically, when RSVP queries IP routing
to obtain the NHOP to which to send a packet, the route that is
returned is the default (hop-by-hop) path and not the shortcut
path. As a result, RSVP control packets will flow on the default
hop-by-hop path, while the data packets of the associated flow will
be forwarded on the existing shortcut, if any, together with the rest
of the default traffic to that destination. However, if and when a
reservation is made and the classifier in the IP forwarding fastpath
is updated at the ingress router, the RSVP data packets will start
being forwarded on the routed path which is where the reservation
was made. In some instances, this may have the unfortunate effect
that the user may see lower performance (higher delay) once the
reservation is in place. This is clearly not desirable, and further
motivates the need for allowing RSVP flows to also use shortcuts.
As alluded to earlier, this requires the definition of an interface
between RSVP and the shortcut mechanism, that will support the
necessary interactions. In particular, RSVP, or the RSVP-ATM
gateway, must be able to query the shortcut mechanism, and to request
the establishment of a new shortcut VC. In addition, the management
Guerin, et al. Expires 4 February 1998 [Page 2]
Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997
of shortcuts for both RSVP and best-effort traffic to the same
destination needs to be coordinated, and this requires additional
interactions between RSVP and the shortcut mechanism. Before
proceeding with more detailed discussions on each of these aspects,
we briefly review some of the general design issues and choices in
using shortcuts for RSVP flows.
1.1. General Design Principles
The main design principle followed in this document to support
shortcuts for RSVP flows is:
Separate but consistent shortcuts for RSVP data and control
messages.
There are several implications of this principle.
1. Receipt of an RSVP PATH message will trigger the establishment
of a best-effort shortcut unless one is already in place for the
same destination.
Note that in the case where a shortcut is already in place,
it may be necessary to verify that this existing shortcut is
adequate, i.e., whether or not a more appropriate shortcut might
be available for the destination address of the RSVP flow. This
implies that for every new flow, RSVP should always check for
the most appropriate shortcut to the flow's destination. In
the case of NHRP, in order to ensure that the most appropriate
shortcut possible is indeed returned, e.g., that the query is
propagated as far as possible, some extensions to the current
NHRP operation are desirable. Specifically, it would be useful
to introduce and use QoS fields in NHRP queries (1) to carry the
traffic information (TSpec) present in the RSVP PATH message.
This information could then be used at each (NHRP) node as a
"hint" to keep forwarding the query, so as to yield the "longest"
possible shortcut consistent with the QoS requirements. For
example, a bandwidth threshold may be used to decide which flows
to forward over the hop-by-hop path and which to send over a
separate shortcut.
----------------------------
1. Note that such fields were present in earlier versions of the NHRP
draft, but were dropped because their use was not fully specified
at the time.
Guerin, et al. Expires 4 February 1998 [Page 3]
Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997
It should be noted that the availability of a best-effort
shortcut VC means that the data packets associated with the RSVP
flow will also be able, if permitted (more on this in Section 2),
to use the short and, therefore, bypass intermediate router hops
as well.
2. In order to allow the eventual establishment of a QoS shortcut
VC on which to forward the data packets of an RSVP flow, the
PATH messages must be forwarded over a shortcut VC with the same
endpoint.
3. Best-effort shortcuts should not be taken down as long as any
(associated) RSVP flow remains active, i.e., have a valid path
state.
This is required to ensure consistency between the forwarding of
RSVP control and data packets. It means that the best-effort
shortcut VC must stay in place as long as it is needed to forward
RSVP control messages. In particular, the best-effort shortcut
VC should not be taken down because of low traffic volume as is
often the case in current implementations of shortcut mechanisms,
e.g., NHRP. Note that a best-effort shortcut can be used to
forward RSVP control messages associated with multiple RSVP
flows, i.e., when the associated shortcut end-point is the same
for all the flows. As a result, the shortcut must remain in
place at least until all the flows have been removed.
4. Upon receipt of a RESV message, a new QoS shortcut VC is setup
with the same end-points as the existing best-effort shortcut,
but with the appropriate QoS characteristics based on the content
of the RESV message.
5. A QoS shortcut VC should remain active as long as the associated
RSVP reservation does.
Implicit here is the fact that "management" of a QoS shortcut
is closely coupled to the state of the associated RSVP flow.
However, responsibility for actually managing the QoS shortcut
VCs can lie either with RSVP or with the shortcut mechanism
itself. For example, in the case of NHRP which is already
responsible for managing best-effort shortcuts, one may want to
extend this to also include management of QoS VCs. On the other
hand, in order to easily support multiple shortcut mechanisms,
it might be desirable to keep management of QoS shortcuts under
the responsibility of RSVP, or rather of the "ATM gateway"
responsible for establishing VCs on behalf of RSVP. Note that in
this case, it is still necessary to maintain coordination between
the best-effort and QoS shortcut VCs as outlined above.
Guerin, et al. Expires 4 February 1998 [Page 4]
Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997
In the next two sections, we elaborate on the interactions between
RSVP and the shortcut mechanism, in terms of both external and
internal exchanges. In Section 2, we specify more precisely the
implications of RSVP shortcuts in terms of the associated message
flows between entities on each end of the shortcut. In Section 3, we
illustrate, for the case of NHRP, a possible interface between RSVP
and the shortcut mechanism.
2. RSVP Shortcut Interactions
This section covers the interactions between hosts and/or routers
that take place in order to enable the use of shortcuts for RSVP
flows. In particular, it describes how and which VCs are used by
RSVP control messages, e.g., PATH and RESV messages, how and when
shortcut VCs are established to support RSVP flows, and finally how
certain VC setup error scenarios are handled.
2.1. RSVP Control Message Handling
In order to properly coordinate the forwarding of RSVP data packets
on a shortcut VC with the associated RSVP control messages, it
is useful to distinguish between downstream and upstream RSVP
control messages. According to the RSVP specification [BZB+97],
downstream messages, e.g., PATH messages, flow from the sender to
the receiver(s), while upstream messages, e.g., RESV messages,
flow hop-by-hop (from next hop to previous hop) back towards the
sender(s). As mentioned earlier, in this draft we limit ourselves to
unicast flows (single ingress and egress points for the ATM network).
Ensuring consistent RSVP reservation states and forwarding of RSVP
data packets on a shortcut VC, requires proper coordination between
the shortcut end-points and the forwarding of RSVP control messages.
In particular, as mentioned in Section 1.1, it is key that downstream
messages, i.e., PATH messages, have previous and next hops that match
the end-points of the shortcut. For example, in Figure 1, when the
shortcut R1-R6 is used for an RSVP data flow, the associated RSVP
control messages sent by R1 must be sent directly to R6 without using
the intermediate routed path R2-R3-R4-R5. If messages passed in the
downstream direction are sent hop-by-hop and the data is sent via a
shortcut, the receiver may not be able to properly handle the data
and extra resources may be allocated in the intermediate routers R2,
R3, R4, and R5. This restriction does not apply to messages sent
in the upstream direction, i.e., RESV messages, that can be sent
on either the shortcut or the hop-by-hop paths (see [Ber97a] for
details).
Guerin, et al. Expires 4 February 1998 [Page 5]
Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997
Given the importance of ensuring that downstream control messages
are delivered directly to the same endpoint as that of the shortcut,
we now review the different cases that must be considered and the
appropriate actions for each of them. There are three different
scenarios that a sender (ATM ingress point) can face:
1. A shortcut to the (session) destination does not exist for
best-effort traffic, and establishment of such a best-effort
shortcut to this destination is administratively permitted.
2. A shortcut already exits for best-effort traffic to the (session)
destination.
3. A shortcut to the (session) destination does not exits for
best-effort traffic, and establishment of such a best-effort
shortcut to this destination is administratively prohibited.
Note that we assume that administrative control of shortcuts is part
of the shortcut support mechanisms, such as NHRP, and is outside the
scope of this document. Furthermore, it is assumed that RSVP can be
notified when a best-effort shortcut is administratively prohibited.
The first case occurs when no shortcut exists and the sender is
administratively permitted to create a shortcut VC for use by
best-effort data traffic to the same destination address as the RSVP
control message. In this case, there are two possible approaches
that the sender can follow. A first approach is to setup the
"best-effort" VC at the time the first control message (PATH)
arrives, and wait until the best-effort shortcut is established
before forwarding the message downstream. The second approach
is to immediately forward the control message (PATH) via the
hop-by-hop path, and to proceed in parallel with the establishment
of the best-effort shortcut. Once the "best-effort" shortcut is
established, forwarding of control messages can then be switched
over to the shortcut. Downstream RSVP processes will detect the
path change and update their internal state appropriately. This
latter approach has the disadvantage that additional resources may
be allocated along the hop-by-hop path prior to the shortcut being
established. In either case, the newly established shortcut VC must
be maintained for as long as there remains RSVP control traffic to be
forwarded downstream, i.e., the VC should not be timed out or taken
down for lack of activity as long as the RSVP PATH state remains in
effect.
The second case occurs when a shortcut already exists for use by
best-effort data traffic to the same destination address as an RSVP
control message, i.e., the entry in the forwarding information base
of the router, that corresponds to the destination address of the
Guerin, et al. Expires 4 February 1998 [Page 6]
Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997
RSVP message, indicates that it is a shortcut. In this case, the
first step that needs to be performed is to "revalidate" the existing
shortcut. As stated earlier, this revalidation is necessary as in
some instances the shortcut mechanism may select different end-points
for a shortcut depending on the nature of the traffic that is to
use the shortcut. Revalidation of the shortcut also depends on
the type of shortcut mechanism used. In case the shortcut is not
validated, the sender finds itself in a similar situation as that of
the previous case. Assuming the shortcut has been validated, the
sender can then simply forward downstream RSVP control messages on
the existing shortcut VC. However, as before, the sender must also
make sure that the existing best-effort shortcut is not released
while still being needed to forward RSVP control messages.
The third and last case occurs when no shortcut exists, and the
sender is administratively prohibited from creating a best-effort
shortcut VC to the same destination address as the RSVP control
messages. However, QoS shortcut VCs are allowed and could be used
by RSVP flows. For example, this could be the case when crossing
administrative domain boundaries. In order to enable the use of QoS
shortcuts by RSVP flows in such instances, it is necessary to create
a special VC to the shortcut endpoint for use solely by RSVP control
messages that are to be sent downstream. As in the first case, the
sender can forward the first PATH message downstream either before
or after the VC has been successfully established. Similarly, the
control shortcut VC must again be maintained for as long as there are
RSVP control messages to be passed downstream.
2.2. Data VC Operations
Shortcut data VCs are setup and maintained in essentially the same
fashion as described in [Ber97a, Ber97b]. The only but significant
difference is that the ATM called party used in VC setup matches
the shortcut endpoint. As in the case of hop-by-hop operation, the
setup of a QoS data VC is triggered by the receipt of the first RESV
message. The fact that a shortcut will be used can be detected by
realizing that the next hop, as per the IP source address in the RESV
message, is on a different subnet, and by the fact that a "control
shortcut VC" already exists to this next hop. When the RESV message
is received by RSVP, a QoS VC to the shortcut endpoint is then
initiated.
In establishing the QoS shortcut VC, the RSVP process should follow
the same recommendations as stated in [Ber97a], specifically using
independent VCs for each RSVP reservation. The RSVP process should
also follow the same recommendations and requirements as stated
Guerin, et al. Expires 4 February 1998 [Page 7]
Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997
in [Ber97b]. This includes the ability to handle changes in QoS
requests and negotiate appropriate encapsulation.
2.3. Error Handling Scenarios
There are a number of error scenarios that need to be handled by RSVP
when using shortcuts.
The first error scenario is when the shortcut VC used to forward RSVP
control messages is abnormally released and cannot be reestablished.
In this case there is no other choice but to send RSVP control
messages hop-by-hop. When this occurs and no RSVP associated QoS
VCs exists, no other special actions is required. However, when
this occurs AND there are RSVP associated QoS VCs (there could be
more than one), then those VCs MUST be released. The release of
the associated data VCs is required to maintain the synchronization
between forwarding and reservation states for the associated data
flows.
A second error scenario occurs when the setup of the QoS data VC
associated with an RSVP flow fails. In this case, a shortcut with
the required QoS is not available, but a best-effort VC has been
successfully established to forward the RSVP control messages. Since
the desired QoS cannot be satisfied using a shortcut, the sender
SHOULD stop sending the RSVP control messages over the best-effort
shortcut and start sending them on the hop-by-hop path. This will
eventually allow the reservation to be attempted on the hop-by-hop
path. The best-effort shortcut VC used for control messages may
be released or maintained based on its other uses. For example,
it may still be used to forward RSVP control messages associated
with other flows which did successfully setup a QoS shortcut to the
same endpoint. Note that the sender may want to regularly retry
establishing a shortcut based path, especially if the reservation is
also unsuccessful on the hop-by-hop path.
The last error scenario to consider is that of a VC setup failure
when processing a change in an RSVP reservation. This case is
handled exactly the same way as is described in [Ber97b, Section
2.4]. The old QoS VC MUST continue to be used. When the new
reservation is greater than the old reservation, the reservation
request MUST be answered with an error. When the new reservation is
less than the old reservation, the request MUST be treated as if the
modification was successful. Implementations SHOULD retry replacing
the too large VC after some appropriate elapsed time.
In the next section, we provide an example of a possible interface
between RSVP and the shortcut mechanisms, when NHRP is assumed for
Guerin, et al. Expires 4 February 1998 [Page 8]
Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997
the latter. This interface is only intended as a possible guideline
and not meant to imply specific implementations requirements.
3. Sample RSVP-NHRP Interface
An interface between RSVP and NHRP should allow determination of
appropriate shortcut endpoints for different RSVP flows, support
coordination between best-effort and QoS VCs used for the same flow,
and accommodate handling of error scenarios. In the context of the
interface outlined in this section, we assume that RSVP (the RSVP-ATM
gateway) is responsible for the establishment of QoS shortcut VCs.
As a result, interactions between NHRP and RSVP are limited to
dealing with best-effort VCs.
- RSVP_shortcut_resolve(flow_ID, IP_address, TSpec, return_code,
BE_VC_handle, endpoint_ATM_address)
This is a query from RSVP to NHRP to request the most appropriate
shortcut possible towards reaching IP_address. Note that if a
shortcut already exists to the destination, NHRP may need to
revalidate it based on the new TSpec specified in the call.
* flow_ID: identifies the flow for future reference.
* IP_address: unicast IP address of the destination specified
in the PATH message.
* TSpec the traffic specification for the RSVP flow. This
information may be carried in the QoS field of the NHRP
request.
* return_code: because resolution of the query and
establishment of a new VC, if necessary, will take
time, the return_code can take three different values:
success/pending/failed.
* BE_VC_handle: this value is only meaningful when return_code
= success, and identifies to RSVP the best-effort VC
associated with the flow. Implicit here is the fact that
both RSVP and NHRP are now aware that the states of the VC
associated with BE_VC_handle and of the RSVP flow identified
by flow_id need to be coordinated. Note that a best effort
VC could be associated with multiple flows, and NHRP could
return the same or different handles for each flow.
* endpoint_ATM_address: ATM address of the endpoint to which
the best-effort VC was established. RSVP will use this
Guerin, et al. Expires 4 February 1998 [Page 9]
Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997
address to subsequently request the setup of a QoS VC upon
receipt of an associated RESV message.
- NHRP_shortcut_resolve(flow_ID, return_code, BE_VC_handle,
endpoint_ATM_address)
This is an asynchronous response to an earlier query by RSVP,
i.e., one for which return_code = pending.
* flow_ID: used by RSVP to correlate the response with the
original query.
* return_code: is either success or failed.
* BE_VC_handle: in case return_code = success, identifies to
RSVP the best-effort VC associated with the flow. Again,
implicit here is the fact that both RSVP and NHRP are now
aware that the states of the VC associated with BE_VC_handle
and of the RSVP flow identified by flow_id need to be
coordinated. Note that a best effort VC could be associated
with multiple flows, and NHRP could return the same or
different handles for each flow.
* endpoint_ATM_address: ATM address of the endpoint to which
the best-effort VC was established. RSVP will use this
address to subsequently request the setup of a QoS VC upon
receipt of an associated RESV message.
- RSVP_shortcut_refresh (flow_id, BE_VC_handle, return_code)
Used by RSVP to notify NHRP that an existing best-effort shortcut
VC, previously established for a given RSVP flow, should be
maintained independent of the volume of traffic it carries.
Note that this function need not be supported through such an
interface, and could be provided through local status bits that
NHRP could query.
* flow_id: initially assigned by RSVP to identify the flow.
* BE_VC_handle: handle provided by NHRP after establishing the
best-effort VC.
* return_code: can be success or an error code (tbd) in case
RSVP is trying to refresh a non-existing VC.
- RSVP_shortcut_take_down (flow_id, BE_VC_handle)
Guerin, et al. Expires 4 February 1998 [Page 10]
Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997
Used by RSVP to notify NHRP that an existing best-effort shortcut
VC, associated with a given flow, can be taken down. This need
not trigger the actual take down of the VC in cases where the
same best-effort VC is used to carry control messages of multiple
RSVP flows, or if NHRP decides to keep the VC up to continue
carrying best-effort data traffic. However, in the latter case,
NHRP is responsible for removing any association between RSVP
flows and the best-effort VC.
* flow_id: initially assigned by RSVP to identify the flow.
* BE_VC_handle: handle provided by NHRP after establishing the
best-effort VC.
- NHRP_BE_VC_failure(BE_VC_handle, error_code)
Used by NHRP to notify RSVP of the failure of an existing
best-effort VC. RSVP is responsible for taking down all
associated QoS VCs.
* BE_VC_handle: handle originally used by NHRP to identify the
best-effort VC.
* return_code: indicates the type of failure if known.
4. Interaction with MPOA
In the ATM Forum's Multiprotocol Over ATM (MPOA) model, shortcuts are
established between MPOA Clients (MPCs) on edge devices, or between
an MPC and an NHRP Client (NHC). When an internetwork layer packet
(e.g., IP packet) arrives over a shortcut VC to an MPOA edge device,
the MPC looks up the internetwork layer destination address in the
packet in a local cache to obtain DLL information to place on the
packet. The DLL information is prepended to the packet and the frame
is transferred to a LAN Emulation client for further handling. When
using the scheme described in this draft for establishing shortcuts
with QoS, it is possible that multiple shortcuts may be established
to the same MPC with traffic from different RSVP flows to the same
IP destination. Furthermore, it may be desirable to place different
DLL headers for packets arriving over different VCs (e.g., with
different values of priority in the token ring header, or in the IEEE
802.1p header), depending on the QoS required for the flow. The MPOA
specification already allows for this possibility. The egress MPC
simply needs to assign a different "tag" for each RSVP flow that it
is terminating. This tag is carried in the packets arriving over
the shortcuts to the edge device, and may be used to index in to
Guerin, et al. Expires 4 February 1998 [Page 11]
Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997
different entries in the local cache. Thus, the scheme described in
this draft is compatible with MPOA as well.
It is for further study whether full PATH state needs to be stored on
the edge devices or not. The MPOA Server (MPS) may be able to store
the PATH state, thus allowing for building of simpler edge devices.
5. Example of RSVP Shortcut
In this last section, we briefly outline a possible set of events
involved in the establishment of a shortcut for an RSVP flow.
Referring to Figure 1, we assume a sending host H1 connected through
a series of networks and routers to router R1 (ingress router to
the ATM network), and a destination host H2 connected to router R6
(egress router from the ATM network) through again possibly a series
of routers and networks.
- Host H1 starts sending PATH messages.
- First PATH message arrives at R1 which extracts the IP address
of H2 and the TSpec of the flow and queries its local NHRP using
RSVP_shortcut_resolve().
- NHRP generates an NHRP query for the IP address of host H2 and
specifies using the NHRP QoS field, that the query should be
resolved in the most specific and feasible manner, i.e., the ATM
address of router R6 should be returned. NHRP responds to the
RSVP query with a return_code = pending.
- NHRP receives a response to its query. It could either
correspond to an existing VC to R6 or require the establishment
of a new VC. If the latter, NHRP proceeds with setting-up a new
best-effort VC.
- NHRP informs, using NHRP_shortcut_resolve(), that the best effort
VC to R6 has been established (or not established) by returning
the appropriate return_code. In what follows, we assume the
best effort VC has been successfully established, so that
NHRP also returns the ATM address of R6 to RSVP and the handle
corresponding to the VC.
- RSVP starts forwarding PATH messages on the newly establish
shortcut VC to R6. Here we assume that R1 held back forwarding
of PATH messages until after the establishment of the best-effort
shortcut VC. Note that data packets for H2 will also be forwarded
on the shortcut VC.
Guerin, et al. Expires 4 February 1998 [Page 12]
Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997
- PATH message arrives at R6 with its PHOP set to R1. R6 creates
the appropriate path state and proceeds to forward the PATH
message towards H2.
- H2 receives the PATH message. It decides to make a reservation
and starts sending RESV messages.
- First RESV message arrives at R6 which (assuming the local
reservation is successful), which forwards it to R1 since it has
the IP address of R1 in its PHOP field.
- RESV message is received by RSVP at R1, which then requests the
establishment of a QoS VC to R6 using the ATM address returned by
NHRP in NHRP_shortcut_resolve(). The request specifies a service
class and traffic parameters based on the information contained
in the RESV message.
- Once notified of the success of the setup of the VC, RSVP
proceeds to update the classifier at R1 to ensure that RSVP data
packets are forwarded on the new VC. R1 also forwards the RESV
message towards H1.
- As long as the associated RESV state remains alive, RSVP at R1
keeps the QoS VC to R6 up and also makes sure that the associated
best-effort VC remains up.
- When the reservation is eventually taken down, say, by H2 issuing
a RESV_TEAR, RSVP at R1 takes down the QoS VC to R6 and removes
the associated classifier entry. Data packets start then being
forwarded on the best effort shortcut VC to R6.
- As long as the PATH state remains alive, RSVP at R1 keeps
refreshing the associated best-effort shortcut VC to R6 using
RSVP_shortcut_refresh().
- When the PATH state is removed, e.g., by receiving a
PATH_TEAR initiated by H1, RSVP at R1 notifies NHRP using
RSVP_shortcut_take_down() with the flow_id and VC_handle
corresponding to the best effort shortcut VC associated with the
flow. NHRP can then decide to either take the VC down or to keep
it up.
Acknowledgment
The authors gratefully acknowledge inputs from Steve Nadas, Anoop
Ghanwani, Steven Blake, Girish Bhat, and Ed Bowen.
Guerin, et al. Expires 4 February 1998 [Page 13]
Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997
References
[BB97] S. Berson and L. Berger. IP Integrated Services with
RSVP over ATM (draft-ietf-issll-atm-support-03.txt).
INTERNET-DRAFT, Internet Engineering Task Force, ISSLL
Working Group, March 1997.
[Ber97a] L. Berger. RSVP over ATM Implementation Guidelines
(draft-ietf-issll-atm-imp-guide-01.ps,txt).
INTERNET-DRAFT, Internet Engineering Task Force,
ISSLL Working Group, July 1997.
[Ber97b] L. Berger. RSVP over ATM Implementation Requirements
(draft-ietf-issll-atm-imp-req-00.ps,txt). INTERNET-DRAFT,
Internet Engineering Task Force, ISSLL Working Group, July
1997.
[GB97] M. Garrett and M. Borden. Interoperation of
Controlled Load and Guaranteed Service with ATM
(draft-ietf-issll-atm-mapping-02.txt). INTERNET-DRAFT,
Internet Engineering Task Force, ISSLL Working Group, March
1997.
[J96] J. Jeffords (ed.). PNNI Augmented Routing (PAR) v1.0
Specification. ATM Forum BTD-PNNI-PAR-01.00, December
1996.
[LKPC97] J. V. Luciani, D. Katz, D. Piscitello, and
B. Cole. NBMA Next Hop Resolution Protocol NHRP
(draft-ietf-rolc-nhrp-11.txt). INTERNET-DRAFT, Internet
Engineering Task Force, ROLC Working Group, March 1997.
[BZB+97] R. Braden (Ed.), L. Zhang, S. Berson, S. Herzog, and
S. Jamin. Resource reSerVation Protocol (RSVP) version
1, functional specification (draft-ietf-rsvp-spec-16.ps).
INTERNET-DRAFT, Internet Engineering Task Force - RSVP WG,
June 1997.
Guerin, et al. Expires 4 February 1998 [Page 14]
Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997
Authors' Address
Roch Guerin Dilip Kandlur
IBM T.J. Watson Research Center IBM T.J. Watson Research Center
P.O. Box 704 P.O. Box 704
Yorktown Heights, NY 10598 Yorktown Heights, NY 10598
EMAIL: guerin@watson.ibm.com EMAIL: kandlur@watson.ibm.com
VOICE +1 914 784-7038 VOICE +1 914 784-7722
FAX +1 914 784-6205 FAX +1 914 784-6205
Liang Li Vijay Srinivasan
IBM Corporation IBM Corporation
P. O. Box 12195 P. O. Box 12195
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
EMAIL: lli@raleigh.ibm.com EMAIL: vijay@raleigh.ibm.com
VOICE: +1 919 254-5627 VOICE: +1 919 254-2730
FAX: +1 919 254-5483 FAX: +1 919 254-5410
Lou Berger
FORE Systems
6905 Rockledge Drive
Suite 800
Bethesda, MD 20817
EMAIL: lberger@fore.com
VOICE: +1 301 571 2534
Guerin, et al. Expires 4 February 1998 [Page 15]