RFC 2205
Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
Pages: 112
Proposed Standard
→ Errata
Updated by: 2750 3936 4495 5946 6437 6780
Proposed Standard
→ Errata
Updated by: 2750 3936 4495 5946 6437 6780
Part 1 of 4 – Pages 1 to 18
Network Working Group R. Braden, Ed. Request for Comments: 2205 ISI Category: Standards Track L. Zhang UCLA S. Berson ISI S. Herzog IBM Research S. Jamin Univ. of Michigan September 1997 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties.
Table of Contents 1. Introduction ................................................... 4 1.1 Data Flows ................................................. 7 1.2 Reservation Model .......................................... 8 1.3 Reservation Styles .........................................11 1.4 Examples of Styles .........................................14 2. RSVP Protocol Mechanisms .......................................19 2.1 RSVP Messages ..............................................19 2.2 Merging Flowspecs ..........................................21 2.3 Soft State .................................................22 2.4 Teardown ...................................................24 2.5 Errors .....................................................25 2.6 Confirmation ...............................................27 2.7 Policy Control .............................................27 2.8 Security ...................................................28 2.9 Non-RSVP Clouds ............................................29 2.10 Host Model ................................................30 3. RSVP Functional Specification ..................................32 3.1 RSVP Message Formats .......................................32 3.2 Port Usage .................................................47 3.3 Sending RSVP Messages ......................................48 3.4 Avoiding RSVP Message Loops ................................50 3.5 Blockade State .............................................54 3.6 Local Repair ...............................................56 3.7 Time Parameters ............................................57 3.8 Traffic Policing and Non-Integrated Service Hops ...........58 3.9 Multihomed Hosts ...........................................59 3.10 Future Compatibility ......................................61 3.11 RSVP Interfaces ...........................................63 4. Acknowledgments ................................................76 APPENDIX A. Object Definitions ....................................77 APPENDIX B. Error Codes and Values ................................92 APPENDIX C. UDP Encapsulation .....................................98 APPENDIX D. Glossary .............................................102 REFERENCES .......................................................111 SECURITY CONSIDERATIONS ..........................................111 AUTHORS' ADDRESSES ...............................................112
What's Changed
This revision contains the following very minor changes from the ID14
version.
o For clarity, each message type is now defined separately in
Section 3.1.
o We added more precise and complete rules for accepting Path
messages for unicast and multicast destinations (Section
3.1.3).
o We added more precise and complete rules for processing and
forwarding PathTear messages (Section 3.1.5).
o A note was added that a SCOPE object will be ignored if it
appears in a ResvTear message (Section 3.1.6).
o A note was added that a SENDER_TSPEC or ADSPEC object will be
ignored if it appears in a PathTear message (Section 3.1.5).
o The obsolete error code Ambiguous Filter Spec (09) was
removed, and a new (and more consistent) name was given to
error code 08 (Appendix B).
o In the generic interface to traffic control, the Adspec was
added as a parameter to the AddFlow and ModFlow calls
(3.11.2). This is needed to accommodate a node that updates
the slack term (S) of Guaranteed service.
o An error subtype was added for an Adspec error (Appendix B).
o Additional explanation was added for handling a CONFIRM
object (Section 3.1.4).
o The rules for forwarding objects with unknown class type were
clarified.
o Additional discussion was added to the Introduction and to
Section 3.11.2 about the relationship of RSVP to the link
layer. (Section 3.10).
o Section 2.7 on Policy and Security was split into two
sections, and some additional discussion of security was
included.
o There were some minor editorial improvements.
1. Introduction This document defines RSVP, a resource reservation setup protocol designed for an integrated services Internet [RSVP93, RFC 1633]. The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or flows. RSVP is also used by routers to deliver quality-of-service (QoS) requests to all nodes along the path(s) of the flows and to establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path. RSVP requests resources for simplex flows, i.e., it requests resources in only one direction. Therefore, RSVP treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack. However, RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols. Like the implementations of routing and management protocols, an implementation of RSVP will typically execute in the background, not in the data forwarding path, as shown in Figure 1. RSVP is not itself a routing protocol; RSVP is designed to operate with current and future unicast and multicast routing protocols. An RSVP process consults the local routing database(s) to obtain routes. In the multicast case, for example, a host sends IGMP messages to join a multicast group and then sends RSVP messages to reserve resources along the delivery path(s) of that group. Routing protocols determine where packets get forwarded; RSVP is only concerned with the QoS of those packets that are forwarded in accordance with routing. In order to efficiently accommodate large groups, dynamic group membership, and heterogeneous receiver requirements, RSVP makes receivers responsible for requesting a specific QoS [RSVP93]. A QoS request from a receiver host application is passed to the local RSVP process. The RSVP protocol then carries the request to all the nodes (routers and hosts) along the reverse data path(s) to the data source(s), but only as far as the router where the receiver's data path joins the multicast distribution tree. As a result, RSVP's reservation overhead is in general logarithmic rather than linear in the number of receivers.
HOST ROUTER
_____________________________ ____________________________
| _______ | | |
| | | _______ | | _______ |
| |Appli- | | | |RSVP | | | |
| | cation| | RSVP <---------------------------> RSVP <---------->
| | <--> | | | _______ | | |
| | | |process| _____ | ||Routing| |process| _____ |
| |_._____| | -->Polcy|| || <--> -->Polcy||
| | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl||
| |data | | |_____|| ||__.____| | | |_____||
|===|===========|==|==========| |===|==========|==|==========|
| | --------| | _____ | | | --------| | _____ |
| | | | ---->Admis|| | | | | ---->Admis||
| _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl||
| | | | | |_____|| | | | | ||_____||
| |Class-| | Packet | | | |Class-| | Packet | |
| | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>
| |______| |________| |data | |______| |________| |data
| | | |
|_____________________________| |____________________________|
Figure 1: RSVP in Hosts and Routers
Quality of service is implemented for a particular data flow by
mechanisms collectively called "traffic control". These mechanisms
include (1) a packet classifier, (2) admission control, and (3) a
"packet scheduler" or some other link-layer-dependent mechanism to
determine when particular packets are forwarded. The "packet
classifier" determines the QoS class (and perhaps the route) for each
packet. For each outgoing interface, the "packet scheduler" or other
link-layer-dependent mechanism achieves the promised QoS. Traffic
control implements QoS service models defined by the Integrated
Services Working Group.
During reservation setup, an RSVP QoS request is passed to two local
decision modules, "admission control" and "policy control".
Admission control determines whether the node has sufficient
available resources to supply the requested QoS. Policy control
determines whether the user has administrative permission to make the reservation. If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the desired QoS. If either check fails, the RSVP program returns an error notification to the application process that originated the request. RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths. RSVP itself transfers and manipulates QoS and policy control parameters as opaque data, passing them to the appropriate traffic control and policy control modules for interpretation. The structure and contents of the QoS parameters are documented in specifications developed by the Integrated Services Working Group; see [RFC 2210]. The structure and contents of the policy parameters are under development. Since the membership of a large multicast group and the resulting multicast tree topology are likely to change with time, the RSVP design assumes that state for RSVP and traffic control state is to be built and destroyed incrementally in routers and hosts. For this purpose, RSVP establishes "soft" state; that is, RSVP sends periodic refresh messages to maintain the state along the reserved path(s). In the absence of refresh messages, the state automatically times out and is deleted. In summary, RSVP has the following attributes: o RSVP makes resource reservations for both unicast and many-to- many multicast applications, adapting dynamically to changing group membership as well as to changing routes. o RSVP is simplex, i.e., it makes reservations for unidirectional data flows. o RSVP is receiver-oriented, i.e., the receiver of a data flow initiates and maintains the resource reservation used for that flow. o RSVP maintains "soft" state in routers and hosts, providing graceful support for dynamic membership changes and automatic adaptation to routing changes. o RSVP is not a routing protocol but depends upon present and future routing protocols. o RSVP transports and maintains traffic control and policy control parameters that are opaque to RSVP.
o RSVP provides several reservation models or "styles" (defined
below) to fit a variety of applications.
o RSVP provides transparent operation through routers that do not
support it.
o RSVP supports both IPv4 and IPv6.
Further discussion on the objectives and general justification for
RSVP design are presented in [RSVP93] and [RFC 1633].
The remainder of this section describes the RSVP reservation
services. Section 2 presents an overview of the RSVP protocol
mechanisms. Section 3 contains the functional specification of RSVP,
while Section 4 presents explicit message processing rules. Appendix
A defines the variable-length typed data objects used in the RSVP
protocol. Appendix B defines error codes and values. Appendix C
defines a UDP encapsulation of RSVP messages, for hosts whose
operating systems provide inadequate raw network I/O support.
1.1 Data Flows
RSVP defines a "session" to be a data flow with a particular
destination and transport-layer protocol. RSVP treats each
session independently, and this document often omits the implied
qualification "for the same session".
An RSVP session is defined by the triple: (DestAddress, ProtocolId
[, DstPort]). Here DestAddress, the IP destination address of the
data packets, may be a unicast or multicast address. ProtocolId
is the IP protocol ID. The optional DstPort parameter is a
"generalized destination port", i.e., some further demultiplexing
point in the transport or application protocol layer. DstPort
could be defined by a UDP/TCP destination port field, by an
equivalent field in another transport protocol, or by some
application-specific information.
Although the RSVP protocol is designed to be easily extensible for
greater generality, the basic protocol documented here supports
only UDP/TCP ports as generalized ports. Note that it is not
strictly necessary to include DstPort in the session definition
when DestAddress is multicast, since different sessions can always
have different multicast addresses. However, DstPort is necessary
to allow more than one unicast session addressed to the same
receiver host.
Figure 2 illustrates the flow of data packets in a single RSVP
session, assuming multicast data distribution. The arrows
indicate data flowing from senders S1 and S2 to receivers R1, R2,
and R3, and the cloud represents the distribution mesh created by
multicast routing. Multicast distribution forwards a copy of each
data packet from a sender Si to every receiver Rj; a unicast
distribution session has a single receiver R. Each sender Si may
be running in a unique Internet host, or a single host may contain
multiple senders distinguished by "generalized source ports".
Senders Receivers
_____________________
( ) ===> R1
S1 ===> ( Multicast )
( ) ===> R2
( distribution )
S2 ===> ( )
( by Internet ) ===> R3
(_____________________)
Figure 2: Multicast Distribution Session
For unicast transmission, there will be a single destination host
but there may be multiple senders; RSVP can set up reservations
for multipoint-to-single-point transmission.
1.2 Reservation Model
An elementary RSVP reservation request consists of a "flowspec"
together with a "filter spec"; this pair is called a "flow
descriptor". The flowspec specifies a desired QoS. The filter
spec, together with a session specification, defines the set of
data packets -- the "flow" -- to receive the QoS defined by the
flowspec. The flowspec is used to set parameters in the node's
packet scheduler or other link layer mechanism, while the filter
spec is used to set parameters in the packet classifier. Data
packets that are addressed to a particular session but do not
match any of the filter specs for that session are handled as
best-effort traffic.
The flowspec in a reservation request will generally include a
service class and two sets of numeric parameters: (1) an "Rspec"
(R for `reserve') that defines the desired QoS, and (2) a "Tspec"
(T for `traffic') that describes the data flow. The formats and
contents of Tspecs and Rspecs are determined by the integrated
service models [RFC 2210] and are generally opaque to RSVP.
The exact format of a filter spec depends upon whether IPv4 or
IPv6 is in use; see Appendix A. In the most general approach
[RSVP93], filter specs may select arbitrary subsets of the packets
in a given session. Such subsets might be defined in terms of
senders (i.e., sender IP address and generalized source port), in
terms of a higher-level protocol, or generally in terms of any
fields in any protocol headers in the packet. For example, filter
specs might be used to select different subflows of a
hierarchically-encoded video stream by selecting on fields in an
application-layer header. In the interest of simplicity (and to
minimize layer violation), the basic filter spec format defined in
the present RSVP specification has a very restricted form: sender
IP address and optionally the UDP/TCP port number SrcPort.
Because the UDP/TCP port numbers are used for packet
classification, each router must be able to examine these fields.
This raises three potential problems.
1. It is necessary to avoid IP fragmentation of a data flow for
which a resource reservation is desired.
Document [RFC 2210] specifies a procedure for applications
using RSVP facilities to compute the minimum MTU over a
multicast tree and return the result to the senders.
2. IPv6 inserts a variable number of variable-length Internet-
layer headers before the transport header, increasing the
difficulty and cost of packet classification for QoS.
Efficient classification of IPv6 data packets could be
obtained using the Flow Label field of the IPv6 header. The
details will be provided in the future.
3. IP-level Security, under either IPv4 or IPv6, may encrypt the
entire transport header, hiding the port numbers of data
packets from intermediate routers.
A small extension to RSVP for IP Security under IPv4 and IPv6
is described separately in [RFC 2207].
RSVP messages carrying reservation requests originate at receivers
and are passed upstream towards the sender(s). Note: in this
document, we define the directional terms "upstream" vs.
"downstream", "previous hop" vs. "next hop", and "incoming
interface" vs "outgoing interface" with respect to the direction
of data flow.
At each intermediate node, a reservation request triggers two
general actions, as follows:
1. Make a reservation on a link
The RSVP process passes the request to admission control and
policy control. If either test fails, the reservation is
rejected and the RSVP process returns an error message to the
appropriate receiver(s). If both succeed, the node sets the
packet classifier to select the data packets defined by the
filter spec, and it interacts with the appropriate link layer
to obtain the desired QoS defined by the flowspec.
The detailed rules for satisfying an RSVP QoS request depend
upon the particular link layer technology in use on each
interface. Specifications are under development in the ISSLL
Working Group for mapping reservation requests into popular
link layer technologies. For a simple leased line, the
desired QoS will be obtained from the packet scheduler in the
link layer driver, for example. If the link-layer technology
implements its own QoS management capability, then RSVP must
negotiate with the link layer to obtain the requested QoS.
Note that the action to control QoS occurs at the place where
the data enters the link-layer medium, i.e., at the upstream
end of the logical or physical link, although an RSVP
reservation request originates from receiver(s) downstream.
2. Forward the request upstream
A reservation request is propagated upstream towards the
appropriate senders. The set of sender hosts to which a
given reservation request is propagated is called the "scope"
of that request.
The reservation request that a node forwards upstream may
differ from the request that it received from downstream, for
two reasons. The traffic control mechanism may modify the
flowspec hop-by-hop. More importantly, reservations from
different downstream branches of the multicast tree(s) from
the same sender (or set of senders) must be " merged" as
reservations travel upstream.
When a receiver originates a reservation request, it can also
request a confirmation message to indicate that its request was
(probably) installed in the network. A successful reservation
request propagates upstream along the multicast tree until it
reaches a point where an existing reservation is equal or greater
than that being requested. At that point, the arriving request is
merged with the reservation in place and need not be forwarded
further; the node may then send a reservation confirmation message
back to the receiver. Note that the receipt of a confirmation is
only a high-probability indication, not a guarantee, that the
requested service is in place all the way to the sender(s), as
explained in Section 2.6.
The basic RSVP reservation model is "one pass": a receiver sends a
reservation request upstream, and each node in the path either
accepts or rejects the request. This scheme provides no easy way
for a receiver to find out the resulting end-to-end service.
Therefore, RSVP supports an enhancement to one-pass service known
as "One Pass With Advertising" (OPWA) [OPWA95]. With OPWA, RSVP
control packets are sent downstream, following the data paths, to
gather information that may be used to predict the end-to-end QoS.
The results ("advertisements") are delivered by RSVP to the
receiver hosts and perhaps to the receiver applications. The
advertisements may then be used by the receiver to construct, or
to dynamically adjust, an appropriate reservation request.
1.3 Reservation Styles
A reservation request includes a set of options that are
collectively called the reservation "style".
One reservation option concerns the treatment of reservations for
different senders within the same session: establish a "distinct"
reservation for each upstream sender, or else make a single
reservation that is "shared" among all packets of selected
senders.
Another reservation option controls the selection of senders; it
may be an "explicit" list of all selected senders, or a "wildcard"
that implicitly selects all the senders to the session. In an
explicit sender-selection reservation, each filter spec must match
exactly one sender, while in a wildcard sender-selection no filter
spec is needed.
Sender || Reservations:
Selection || Distinct | Shared
_________||__________________|____________________
|| | |
Explicit || Fixed-Filter | Shared-Explicit |
|| (FF) style | (SE) Style |
__________||__________________|____________________|
|| | |
Wildcard || (None defined) | Wildcard-Filter |
|| | (WF) Style |
__________||__________________|____________________|
Figure 3: Reservation Attributes and Styles
The following styles are currently defined (see Figure 3):
o Wildcard-Filter (WF) Style
The WF style implies the options: "shared" reservation and
"wildcard" sender selection. Thus, a WF-style reservation
creates a single reservation shared by flows from all
upstream senders. This reservation may be thought of as a
shared "pipe", whose "size" is the largest of the resource
requests from all receivers, independent of the number of
senders using it. A WF-style reservation is propagated
upstream towards all sender hosts, and it automatically
extends to new senders as they appear.
Symbolically, we can represent a WF-style reservation request
by:
WF( * {Q})
where the asterisk represents wildcard sender selection and Q
represents the flowspec.
o Fixed-Filter (FF) Style
The FF style implies the options: "distinct" reservations and
"explicit" sender selection. Thus, an elementary FF-style
reservation request creates a distinct reservation for data
packets from a particular sender, not sharing them with other
senders' packets for the same session.
Symbolically, we can represent an elementary FF reservation
request by:
FF( S{Q})
where S is the selected sender and Q is the corresponding
flowspec; the pair forms a flow descriptor. RSVP allows
multiple elementary FF-style reservations to be requested at
the same time, using a list of flow descriptors:
FF( S1{Q1}, S2{Q2}, ...)
The total reservation on a link for a given session is the
`sum' of Q1, Q2, ... for all requested senders.
o Shared Explicit (SE) Style
The SE style implies the options: "shared" reservation and
"explicit" sender selection. Thus, an SE-style reservation
creates a single reservation shared by selected upstream
senders. Unlike the WF style, the SE style allows a receiver
to explicitly specify the set of senders to be included.
We can represent an SE reservation request containing a
flowspec Q and a list of senders S1, S2, ... by:
SE( (S1,S2,...){Q} )
Shared reservations, created by WF and SE styles, are appropriate
for those multicast applications in which multiple data sources
are unlikely to transmit simultaneously. Packetized audio is an
example of an application suitable for shared reservations; since
a limited number of people talk at once, each receiver might issue
a WF or SE reservation request for twice the bandwidth required
for one sender (to allow some over-speaking). On the other hand,
the FF style, which creates distinct reservations for the flows
from different senders, is appropriate for video signals.
The RSVP rules disallow merging of shared reservations with
distinct reservations, since these modes are fundamentally
incompatible. They also disallow merging explicit sender
selection with wildcard sender selection, since this might produce
an unexpected service for a receiver that specified explicit
selection. As a result of these prohibitions, WF, SE, and FF
styles are all mutually incompatible.
It would seem possible to simulate the effect of a WF reservation
using the SE style. When an application asked for WF, the RSVP
process on the receiver host could use local state to create an
equivalent SE reservation that explicitly listed all senders.
However, an SE reservation forces the packet classifier in each
node to explicitly select each sender in the list, while a WF
allows the packet classifier to simply "wild card" the sender
address and port. When there is a large list of senders, a WF
style reservation can therefore result in considerably less
overhead than an equivalent SE style reservation. For this
reason, both SE and WF are included in the protocol.
Other reservation options and styles may be defined in the future.
1.4 Examples of Styles
This section presents examples of each of the reservation styles
and shows the effects of merging.
Figure 4 illustrates a router with two incoming interfaces,
labeled (a) and (b), through which flows will arrive, and two
outgoing interfaces, labeled (c) and (d), through which data will
be forwarded. This topology will be assumed in the examples that
follow. There are three upstream senders; packets from sender S1
(S2 and S3) arrive through previous hop (a) ((b), respectively).
There are also three downstream receivers; packets bound for R1
(R2 and R3) are routed via outgoing interface (c) ((d),
respectively). We furthermore assume that outgoing interface (d)
is connected to a broadcast LAN, i.e., that replication occurs in
the network; R2 and R3 are reached via different next hop routers
(not shown).
We must also specify the multicast routes within the node of
Figure 4. Assume first that data packets from each Si shown in
Figure 4 are routed to both outgoing interfaces. Under this
assumption, Figures 5, 6, and 7 illustrate Wildcard-Filter,
Fixed-Filter, and Shared-Explicit reservations, respectively.
________________
(a)| | (c)
( S1 ) ---------->| |----------> ( R1 )
| Router | |
(b)| | (d) |---> ( R2 )
( S2,S3 ) ------->| |------|
|________________| |---> ( R3 )
|
Figure 4: Router Configuration
For simplicity, these examples show flowspecs as one-dimensional
multiples of some base resource quantity B. The "Receives" column
shows the RSVP reservation requests received over outgoing
interfaces (c) and (d), and the "Reserves" column shows the
resulting reservation state for each interface. The "Sends"
column shows the reservation requests that are sent upstream to
previous hops (a) and (b). In the "Reserves" column, each box
represents one reserved "pipe" on the outgoing link, with the
corresponding flow descriptor.
Figure 5, showing the WF style, illustrates two distinct
situations in which merging is required. (1) Each of the two next
hops on interface (d) results in a separate RSVP reservation
request, as shown; these two requests must be merged into the
effective flowspec, 3B, that is used to make the reservation on
interface (d). (2) The reservations on the interfaces (c) and (d)
must be merged in order to forward the reservation requests
upstream; as a result, the larger flowspec 4B is forwarded
upstream to each previous hop.
|
Sends | Reserves Receives
|
| _______
WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} )
| |_______|
|
-----------------------|----------------------------------------
| _______
WF( *{4B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} )
| |_______| <- WF( *{2B} )
Figure 5: Wildcard-Filter (WF) Reservation Example
Figure 6 shows Fixed-Filter (FF) style reservations. For each
outgoing interface, there is a separate reservation for each
source that has been requested, but this reservation will be
shared among all the receivers that made the request. The flow
descriptors for senders S2 and S3, received through outgoing
interfaces (c) and (d), are packed (not merged) into the request
forwarded to previous hop (b). On the other hand, the three
different flow descriptors specifying sender S1 are merged into
the single request FF( S1{4B} ) that is sent to previous hop (a).
|
Sends | Reserves Receives
|
| ________
FF( S1{4B} ) <- (a) | (c) | S1{4B} | (c) <- FF( S1{4B}, S2{5B} )
| |________|
| | S2{5B} |
| |________|
---------------------|---------------------------------------------
| ________
<- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} )
FF( S2{5B}, S3{B} ) | |________| <- FF( S1{B} )
| | S3{B} |
| |________|
Figure 6: Fixed-Filter (FF) Reservation Example
Figure 7 shows an example of Shared-Explicit (SE) style
reservations. When SE-style reservations are merged, the
resulting filter spec is the union of the original filter specs,
and the resulting flowspec is the largest flowspec.
|
Sends | Reserves Receives
|
| ________
SE( S1{3B} ) <- (a) | (c) |(S1,S2) | (c) <- SE( (S1,S2){B} )
| | {B} |
| |________|
---------------------|---------------------------------------------
| __________
<- (b) | (d) |(S1,S2,S3)| (d) <- SE( (S1,S3){3B} )
SE( (S2,S3){3B} ) | | {3B} | <- SE( S2{2B} )
| |__________|
Figure 7: Shared-Explicit (SE) Reservation Example
The three examples just shown assume that data packets from S1,
S2, and S3 are routed to both outgoing interfaces. The top part
of Figure 8 shows another routing assumption: data packets from S2
and S3 are not forwarded to interface (c), e.g., because the
network topology provides a shorter path for these senders towards
R1, not traversing this node. The bottom part of Figure 8 shows
WF style reservations under this assumption. Since there is no
route from (b) to (c), the reservation forwarded out interface (b)
considers only the reservation on interface (d).
_______________
(a)| | (c)
( S1 ) ---------->| >-----------> |----------> ( R1 )
| > |
| > |
(b)| > | (d)
( S2,S3 ) ------->| >-------->--> |----------> ( R2, R3 )
|_______________|
Router Configuration
|
Sends | Reserves Receives
|
| _______
WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} )
| |_______|
|
-----------------------|----------------------------------------
| _______
WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} )
| |_______| <- WF( * {2B} )
Figure 8: WF Reservation Example -- Partial Routing
(next page on part 2)