draft-ietf-rsvp-spec-06.txt   draft-ietf-rsvp-spec-07.txt 
Internet Draft R. Braden, Ed. Internet Draft R. Braden, Ed.
Expiration: December 1995 ISI Expiration: January 1996 ISI
File: draft-ietf-rsvp-spec-06.txt L. Zhang File: draft-ietf-rsvp-spec-07.txt L. Zhang
PARC PARC
D. Estrin D. Estrin
ISI ISI
S. Herzog S. Herzog
ISI ISI
S. Jamin S. Jamin
USC USC
Resource ReSerVation Protocol (RSVP) -- Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification Version 1 Functional Specification
June 21, 1995 July 7, 1995
Status of Memo Status of Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 5 skipping to change at page 2, line 5
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au
(Pacific Rim). (Pacific Rim).
Abstract Abstract
This memo describes version 1 of RSVP, a resource reservation setup This memo describes version 1 of RSVP, a resource reservation setup
protocol designed for an integrated services Internet. RSVP provides protocol designed for an integrated services Internet. RSVP provides
receiver-initiated setup of resource reservations for multicast or receiver-initiated setup of resource reservations for multicast or
unicast data flows, with good scaling and robustness properties. unicast data flows, with good scaling and robustness properties.
What's Changed Since Boston IETF What's Changed Since Danvers IETF
The most important changes in this document from the rsvp-spec-05 draft The most important changes in this document from the rsvp-spec-05 draft
are: are:
o Added fields to common header for linear fragmentation, and
moved all references to semantic fragmentation to Appendix D.
o Added SE (Shared Explicit) style to all parts of the document. o Added SE (Shared Explicit) style to all parts of the document.
o Further clarified reservation options and added table in Figure o Further clarified reservation options and added table in Figure
3. Defined option vector in STYLE object. 3. Defined option vector in STYLE object.
o Renamed CREDENTIAL object class to POLICY_DATA object class, and o Renamed CREDENTIAL object class to POLICY_DATA object class, and
rewrote section 2.5 to more fully express its intended usage. rewrote section 2.5 to more fully express its intended usage.
o Clarified the relationship between the wildcard scope o Clarified the relationship between the wildcard scope
reservation option and wildcards in individual FILTER_SPEC reservation option and wildcards in individual FILTER_SPEC
objects: wildcard is as wildcard does. objects: wildcard is as wildcard does.
o Added SCOPE object definition and define the rules for its use o Added SCOPE object definition and defined the rules for its use
to prevent looping of wildcard-scope messages. to prevent looping of wildcard-scope messages.
o Added TAG object. This is needed to do semantic fragmentation
in certain cases; however, the rules for its use are not yet
written down. Furthermore, there has been some debate about
semantic fragmentation.
o Added some mechanisms for handling backwards compatibility for o Added some mechanisms for handling backwards compatibility for
future protocol extensions: (1) High bit of object class number; future protocol extensions: (1) High bit of object class number;
(2) unmerged FLOWSPEC C-Type; (3) unmerged POLICY_DATA C-Type. (2) unmerged FLOWSPEC C-Type; (3) unmerged POLICY_DATA C-Type.
o Rewrote Section 4.3 on preventing looping. Included rules for o Rewrote Section 4.3 on preventing looping. Included rules for
SCOPE object. SCOPE object.
o Specified rules for local repair upon route change notification o Specified rules for local repair upon route change notification
(Section 4.4). (Section 4.4).
skipping to change at page 3, line 12 skipping to change at page 3, line 10
o Changed common header format, removing Object Count (which was o Changed common header format, removing Object Count (which was
redundant) and rearranging the remaining fields. Moved the two redundant) and rearranging the remaining fields. Moved the two
common header flags into objects: Entry-Police into SESSION common header flags into objects: Entry-Police into SESSION
object and LUB-used into ERROR_SPEC object. object and LUB-used into ERROR_SPEC object.
o Revised the rules for state timeout (Section 4.5) and redefined o Revised the rules for state timeout (Section 4.5) and redefined
the TIME_VALUES object format. the TIME_VALUES object format.
o Changed the error message format: (1) removed required RSVP_HOP o Changed the error message format: (1) removed required RSVP_HOP
object from PERR and RERR messages; (2) removed CREDENTIAL object from PERR and RERR messages; (2) specified more carefully
(i.e., POLICY_DATA) object from RERR messages; (3) specified what may appear in flow descriptor list of RERR messages.
more carefully what may appear in flow descriptor list of RERR
messages.
o Revised the definitions of error codes and error values, and o Revised the definitions of error codes and error values, and
moved them into a separate Appendix B. moved them into a separate Appendix B.
o No longer require CREDENTIAL (i.e., POLICY_DATA) match for o No longer require CREDENTIAL (i.e., POLICY_DATA) match for
teardown. teardown.
o Revised routing of RERR messages to use SCOPE objects to avoid o Revised routing of RERR messages to use SCOPE objects to avoid
wildcard-induced looping. wildcard-induced looping.
o Added LIH (logical interface handle) to RSVP_HOP object, for IP o Added LIH (logical interface handle) to RSVP_HOP object, for IP
multicast tunnels. multicast tunnels.
o Specified that addresses should be sorted in SCOPE object.
o Added two new upcall event types in the API: reservation event o Added two new upcall event types in the API: reservation event
and policy data event. and policy data event.
o Generalized the generic traffic control calls slightly to allow o Generalized the generic traffic control calls slightly to allow
multiple filter specs per flowspec, for SE style. This multiple filter specs per flowspec, for SE style. This
introduced a new set of handles, called FHandle. Also added a introduced a new set of handles, called FHandle. Also added a
preemption upcall. preemption upcall.
o Added route change notification to the generic interface to o Added route change notification to the generic interface to
routing. routing.
skipping to change at page 10, line 4 skipping to change at page 10, line 4
2. Daemon forwards the reservation upstream 2. Daemon forwards the reservation upstream
The reservation request is propagated upstream towards the The reservation request is propagated upstream towards the
appropriate senders. The set of sender hosts to which a appropriate senders. The set of sender hosts to which a
given reservation request is propagated is called the "scope" given reservation request is propagated is called the "scope"
of that request. of that request.
The reservation request that a node forwards upstream may differ The reservation request that a node forwards upstream may differ
from the request that it received, for two reasons. First, it is from the request that it received, for two reasons. First, it is
possible (in theory) for the kernel to modify the flowspec hop- possible (in theory) for the traffic control mechanism to modify
by-hop, although currently no realtime services do this. Second, the flowspec hop-by-hop, although currently no realtime services
reservations from different downstream branches of the multicast do this. Second, reservations from different downstream branches
distribution tree(s) must be "merged" as reservations travel of the multicast distribution tree(s) must be "merged" as
upstream. Merging reservations is a necessary consequence of reservations travel upstream. Merging reservations is a necessary
multicast distribution, which creates a single stream of data consequence of multicast distribution, which creates a single
packets in a particular router from any Si, regardless of the set stream of data packets in a particular router from any Si,
of receivers downstream. The reservation for Si on a particular regardless of the set of receivers downstream. The reservation
outgoing link L should be the "maximum" of the individual for Si on a particular outgoing link L should be the "maximum" of
flowspecs from the receivers Rj that are downstream via link L. the individual flowspecs from the receivers Rj that are downstream
Merging is discussed further in Section 2.2. via link L. Merging is discussed further in Section 2.2.
The basic RSVP reservation model is "one pass": a receiver sends a The basic RSVP reservation model is "one pass": a receiver sends a
reservation request upstream, and each node in the path can only reservation request upstream, and each node in the path can only
accept or reject the request. This scheme provides no way to make accept or reject the request. This scheme provides no way to make
end-to-end service guarantees, since the QoS request must be end-to-end service guarantees, since the QoS request must be
applied independently at each hop. RSVP also supports an optional applied independently at each hop. RSVP also supports an optional
reservation model, known as "One Pass With Advertising" (OPWA) reservation model, known as "One Pass With Advertising" (OPWA)
[Shenker94]. In OPWA, RSVP control packets sent downstream, [Shenker94]. In OPWA, RSVP control packets sent downstream,
following the data paths, are used to gather information on the following the data paths, are used to gather information on the
end-to-end service that would result from a variety of possible end-to-end service that would result from a variety of possible
reservation requests. The results ("advertisements") are reservation requests. The results ("advertisements") are
delivered by RSVP to the receiver host, and perhaps to the delivered by RSVP to the receiver host, and perhaps to the
receiver application. The information may then be used by the receiver application. The information may then be used by the
receiver to construct an appropriate reservation request. receiver to construct an appropriate reservation request.
1.3 Reservation Styles 1.3 Reservation Styles
A reservation request includes a set of control options. One A reservation request includes a set of control options, which are
option concerns the treatment of reservations for different collectively called the reservation "style".
One option concerns the treatment of reservations for different
senders within the same session: establish a "distinct" senders within the same session: establish a "distinct"
reservation for each upstream sender, or else make a single reservation for each upstream sender, or else make a single
reservation that is "shared" all senders' packets. A distinct reservation that is " shared" among all packets of selected
reservation requires that the filter spec match exactly one senders. Another option controls the scope of the request: an
sender, a wildcard reservation must match at least one. Another "explicit" sender specification, or a "wildcard" that implicitly
option controls the scope of the request: an " explicit" sender selects a group of senders. In an explicit-style reservation, the
specification, or a "wildcard" that implicitly selects all sender filter spec must match exactly one sender, while the filter spec
hosts upstream of the given node. in a wildcard reservation must match at least one sender but may
match any number.
These control options are collectively called the reservation
"style", as shown in Figure 3.
|| Reservations: || Reservations:
Scope || Distinct | Shared Scope || Distinct | Shared
_________||__________________|____________________ _________||__________________|____________________
|| | | || | |
Explicit || Fixed-Filter | Shared-Explicit | Explicit || Fixed-Filter | Shared-Explicit |
|| (FF) style | (SE) Style | || (FF) style | (SE) Style |
__________||__________________|____________________| __________||__________________|____________________|
|| | | || | |
Wildcard || (None defined) | Wildcard-Filter | Wildcard || (None defined) | Wildcard-Filter |
|| | (WF) Style | || | (WF) Style |
__________||__________________|____________________| __________||__________________|____________________|
Figure 3: Reservation Attributes and Styles Figure 3: Reservation Attributes and Styles
The styles currently defined are as follows: The styles currently defined are as follows (see Figure 3):
1. Wildcard-Filter (WF) Style 1. Wildcard-Filter (WF) Style
The WF style implies the options: "shared" reservation and " The WF style implies the options: "shared" reservation and "
wildcard" reservation scope. Thus, a WF-style reservation wildcard" reservation scope. Thus, a WF-style reservation
creates a single reservation into which flows from all creates a single reservation into which flows from all
upstream senders are mixed; this reservation may be thought upstream senders are mixed; this reservation may be thought
of as a shared "pipe", whose "size" is the largest of the of as a shared "pipe", whose "size" is the largest of the
resource requests for that link from all receivers, resource requests for that link from all receivers,
independent of the number of senders using it. A WF-style independent of the number of senders using it. A WF-style
skipping to change at page 15, line 9 skipping to change at page 15, line 9
Although multiple next hops may send reservation requests through Although multiple next hops may send reservation requests through
the same physical interface, the final effect should be to install the same physical interface, the final effect should be to install
a reservation on that interface, which is defined by an effective a reservation on that interface, which is defined by an effective
flowspec. This effective flowspec will be the "maximum" of the flowspec. This effective flowspec will be the "maximum" of the
flowspecs requested by the different next hops. In turn, a RESV flowspecs requested by the different next hops. In turn, a RESV
message forwarded to a particular previous hop carries a flowspec message forwarded to a particular previous hop carries a flowspec
that is the "maximum" over the effective reservations on the that is the "maximum" over the effective reservations on the
corresponding outgoing interfaces. Both cases represent merging, corresponding outgoing interfaces. Both cases represent merging,
which is discussed further below. which is discussed further below.
There are a number of ways for a new or modified reservation There are a number of ways for a syntactically valid reservation
request to fail in a given node: request to fail in a given node:
1. The effective flowspec, computed using the new request, may 1. The effective flowspec, computed using the new request, may
fail admission control. fail admission control.
2. Administrative policy or control may prevent the requested 2. Administrative policy or control may prevent the requested
reservation. reservation.
3. There may be no matching path state (i.e., the scope may be 3. There may be no matching path state (i.e., the scope may be
empty), which would prevent the reservation being propagated empty), which would prevent the reservation being propagated
upstream. upstream.
4. A reservation style that requires a unique sender may have a 4. A reservation style that requires a unique sender may have a
filter spece that matches more than one sender in the path filter spec that matches more than one sender in the path
state, due to the use of wildcards. state, due to the use of wildcards.
5. The requested style may be incompatible with the style(s) of 5. The requested style may be incompatible with the style(s) of
existing reservations for the same session on the same existing reservations for the same session on the same
outgoing interface, so an effective flowspec cannot be outgoing interface, so an effective flowspec cannot be
computed. computed.
6. The requested style may be incompatible with the style(s) of 6. The requested style may be incompatible with the style(s) of
reservations that exist on other outgoing interfaces but will reservations that exist on other outgoing interfaces but will
be merged with this reservation to create a refresh message be merged with this reservation to create a refresh message
for the previous hop. for the previous hop.
In any of these cases, an error message is returned to the In any of these cases, an error message is returned to the
receiver(s) responsible for the erroneous message, which may or receiver(s) responsible for the erroneous message. An error
may not be propagated forward along the path. An error message message does not modify state in the nodes through which it
does not modify state in the nodes through which it passes. passes. Therefore, any reservations established downstream of the
Therefore, any reservations established downstream of the node node where the failure was detected will persist until the
where the failure was detected will persist until the receiver(s) receiver(s) responsible cease attempting the reservation.
responsible cease attempting the reservation.
In general, if the error is likely to be repeated at every node The erroneous message may or may not be propagated forward. In
further along the path, it is best to drop the errneous message general, if the error is likely to be repeated at every node
further along the path, it is best to drop the erroneous message
rather than generate a flood of error messages; this is the case rather than generate a flood of error messages; this is the case
for the last four error classes listed above. The first two error for the last four error classes listed above. The first two error
classes, admission control and administrative policy, may or may classes, admission control and administrative policy, may or may
not allow propagation of the message, depending upon the detailed not allow propagation of the message, depending upon the detailed
reason and perhaps on local administrative policy and/or the reason and perhaps on local administrative policy and/or the
particular service request. More complete rules are given in the particular service request. More complete rules are given in the
error definitions in Appendix B. error definitions in Appendix B.
An erroneous FILTER_SPEC object in a RESV message will normally be An erroneous FILTER_SPEC object in a RESV message will normally be
detected at the first RSVP hop from the receiver application, detected at the first RSVP hop from the receiver application,
skipping to change at page 17, line 41 skipping to change at page 17, line 41
Two filter specs can be merged only they are identical or if one Two filter specs can be merged only they are identical or if one
contains the other through wild-carding. The result is the more contains the other through wild-carding. The result is the more
general of the two, i.e., the one with more wildcard fields. general of the two, i.e., the one with more wildcard fields.
2.3 Soft State 2.3 Soft State
To maintain reservation state, RSVP keeps "soft state" in router To maintain reservation state, RSVP keeps "soft state" in router
and host nodes. RSVP soft state is created and periodically and host nodes. RSVP soft state is created and periodically
refreshed by PATH and RESV messages. The state is deleted if no refreshed by PATH and RESV messages. The state is deleted if no
refreshes arrive before the expiration of a "cleanup timeout" matching refresh messages arrive before the expiration of a
interval; it may also be deleted as the result of an explicit "cleanup timeout" interval. It may also be deleted as the result
"teardown" message. of an explicit "teardown" message, described in the next section.
At the expiration of each "refresh timeout" period, RSVP scans its
state to build and forward PATH and RESV refresh messages to
succeeding hops.
When a route changes, the next PATH message will initialize the When a route changes, the next PATH message will initialize the
path state on the new route, and future RESV messages will path state on the new route, and future RESV messages will
establish reservation state; the state on the now-unused segment establish reservation state there; the state on the now-unused
of the route will time out. Thus, whether a message is "new" or a segment of the route will time out. Thus, whether a message is
"refresh" is determined separately at each node, depending upon "new" or a "refresh" is determined separately at each node,
the existence of state at that node. (This document uses the term depending upon the existence of state at that node.
"refresh message" in this effective sense, to indicate an RSVP
message that does not modify the existing state at the node in
question.)
In addition to the cleanup timeout, there is a "refresh timeout"
period. As messages arrive, the RSVP daemon checks them against
the existing state; if it matches, the cleanup timeout timer on
the state is reset and the message is dropped. At the expiration
of each refresh timeout period, RSVP scans its state to build and
forward PATH and RESV messages to succeeding hops.
RSVP sends its messages as IP datagrams without reliability RSVP sends its messages as IP datagrams without reliability
enhancement. Periodic transmission of refresh messages by hosts enhancement. Periodic transmission of refresh messages by hosts
and routers is expected to replace any lost RSVP messages. To and routers is expected to replace any lost RSVP messages. To
tolerate K-1 successive packet losses, the effective cleanup tolerate K-1 successive packet losses, the effective cleanup
timeout must be at least K times the refresh timeout. In timeout must be at least K times the refresh timeout. In
addition, the traffic control mechanism in the network should be addition, the traffic control mechanism in the network should be
statically configured to grant high-reliability service to RSVP statically configured to grant high-reliability service to RSVP
messages, to protect RSVP messages from congestion losses. messages, to protect RSVP messages from congestion losses.
The "soft" state maintained by RSVP is dynamic; to change the set
of senders Si or receivers Rj or to change any QoS request, a host
simply starts sending revised PATH and/or RESV messages. The
result should be an appropriate adjustment in the RSVP state and
immediate propagation to all nodes along the path.
In steady state, refreshing is performed hop-by-hop, which allows In steady state, refreshing is performed hop-by-hop, which allows
merging and packing as described in the previous section. If the merging and packing as described in the previous section. If the
received state differs from the stored state, the stored state is received state differs from the stored state, the stored state is
updated. Furthermore, if the result will be to modify the refresh updated. Furthermore, if the result will be to modify the refresh
messages to be generated, these refresh messages must be generated messages to be generated, these refresh messages must be generated
and forwarded immediately. This will result in state changes and forwarded immediately. This will result in state changes
propagating end-to-end without delay. However, propagation of a propagating end-to-end without delay. However, propagation of a
change stops when and if it reaches a point where merging causes change stops when and if it reaches a point where merging causes
no resulting state change. This minimizes RSVP control traffic no resulting state change. This minimizes RSVP control traffic
due to changes and is essential for scaling to large multicast due to changes and is essential for scaling to large multicast
groups. groups.
The "soft" router state maintained by RSVP is dynamic; to change
the set of senders Si or receivers Rj or to change any QoS
request, a host simply starts sending revised PATH and/or RESV
messages. The result should be an appropriate adjustment in the
RSVP state and immediate propagation to all nodes along the path.
The RSVP state associated with a session in a particular node is The RSVP state associated with a session in a particular node is
divided into atomic elements that are created, refreshed, and divided into atomic elements that are created, refreshed, and
timed out independently. The atomicity is determined by the timed out independently. The atomicity is determined by the
requirement that any sender or receiver may enter or leave the requirement that any sender or receiver may enter or leave the
session at any time, so its state should be created and timed out session at any time, so its state should be created and timed out
independently. independently.
2.4 Teardown 2.4 Teardown
RSVP teardown messages remove path and reservation state without RSVP teardown messages remove path and reservation state without
waiting for the cleanup timeout period, as an optimization to waiting for the cleanup timeout period, as an optimization to
release resources quickly. It is not necessary (although it may release resources quickly. It is not necessary to explicitly tear
be desirable, since the resources being consumed may be down an old reservation, although it may be desirable in many
"valuable"), to explicitly tear down an old reservation. cases.
A teardown request may be initiated either by an application in an A teardown request may be initiated either by an application in an
end system (sender or receiver), or by a router as the result of end system (sender or receiver), or by a router as the result of
state timeout. Once initiated, a teardown request should be state timeout. Once initiated, a teardown request should be
forwarded hop-by-hop without delay. forwarded hop-by-hop without delay.
Teardown messages (like other RSVP messages) are not delivered Teardown messages (like other RSVP messages) are not delivered
reliably. However, loss of a teardown message is not considered a reliably. However, loss of a teardown message is not considered a
problem because the state will time out even if it is not problem because the state will time out even if it is not
explicitly deleted. If one or more teardown message hops are explicitly deleted. If one or more teardown message hops are
skipping to change at page 24, line 17 skipping to change at page 23, line 42
| |
| _______ | _______
WF( *{3B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} ) WF( *{3B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} )
| |_______| | |_______|
| |
-----------------------|---------------------------------------- -----------------------|----------------------------------------
| _______ | _______
WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} ) WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} )
| |_______| | |_______|
Figure 7: Wildcard-Filter Reservation Example 1 Figure 7: Wildcard-Filter (WF) Reservation Example
Figure 8 shows Fixed-Filter (FF) style reservations. The flow Figure 8 shows Fixed-Filter (FF) style reservations. The flow
descriptors for senders S2 and S3, received from outgoing interfaces descriptors for senders S2 and S3, received from outgoing interfaces
(c) and (d), are packed into the message forwarded to previous hop b. (c) and (d), are packed into the message forwarded to previous hop b.
On the other hand, the two different flow descriptors for sender S1 On the other hand, the two different flow descriptors for sender S1
are merged into the single message FF( S1{3B} ), which is sent to are merged into the single message FF( S1{3B} ), which is sent to
previous hop (a). For each outgoing interface, there is a private previous hop (a). For each outgoing interface, there is a private
reservation for each source that has been requested, but this private reservation for each source that has been requested, but this private
reservation is shared among the receivers that made the request. reservation is shared among the receivers that made the request.
Finally, Figure 9 shows a simple example of Shared-Explicit (SE)
style reservations. Here each outgoing interface has a single
reservation that is shared by a list of senders.
| |
Send | Reserve Receive Send | Reserve Receive
| |
| ________ | ________
FF( S1{3B} ) <- (a) | (c) | S1{B} | (c) <- FF( S1{B}, S2{5B} ) FF( S1{3B} ) <- (a) | (c) | S1{B} | (c) <- FF( S1{B}, S2{5B} )
| |________| | |________|
| | S2{5B} | | | S2{5B} |
| |________| | |________|
---------------------|--------------------------------------------- ---------------------|---------------------------------------------
| ________ | ________
<- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} ) <- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} )
FF( S2{5B}, S3{B} ) | |________| FF( S2{5B}, S3{B} ) | |________|
| | S3{B} | | | S3{B} |
| |________| | |________|
Figure 8: Fixed-Filter Reservation Example Figure 8: Fixed-Filter (FF) Reservation Example
Figure 9 shows a simple example of Shared-Explicit (SE) style
reservations. Here each outgoing interface has a single reservation
that is shared by a list of senders.
| |
Send | Reserve Receive Send | Reserve Receive
| |
| ________ | ________
SE( S1{3B} ) <- (a) | (c) |(S1,S2) | (c) <- SE( (S1,S2){B} ) SE( S1{3B} ) <- (a) | (c) |(S1,S2) | (c) <- SE( (S1,S2){B} )
| | {B} | | | {B} |
| |________| | |________|
---------------------|--------------------------------------------- ---------------------|---------------------------------------------
| ________ | ________
<- (b) | (d) |(S1,S3) | (d) <- SE( (S1,S3){3B} ) <- (b) | (d) |(S1,S3) | (d) <- SE( (S1,S3){3B} )
SE( (S2,S3){3B} ) | | {3B} | SE( (S2,S3){3B} ) | | {3B} |
| |________| | |________|
Figure 9: Shared-Explicit Reservation Example Figure 9: Shared-Explicit (SE) Reservation Example
The three examples just shown assume full routing, i.e., data packets The three examples just shown assume full routing, i.e., data packets
from S1, S2, and S3 are routed to both outgoing interfaces. The top from S1, S2, and S3 are routed to both outgoing interfaces. The top
part of Figure 10 shows another routing assumption: data packets part of Figure 10 shows another routing assumption: data packets
from S1 are not forwarded to interface (d), because the mesh topology from S1 are not forwarded to interface (d), because the mesh topology
provides a shorter path for S1 -> R3 that does not traverse this provides a shorter path for S1 -> R3 that does not traverse this
node. The bottom of Figure 10 shows WF style reservations under this node. The bottom of Figure 10 shows WF style reservations under this
assumption. Since there is no route from (a) to (d), the reservation assumption. Since there is no route from (a) to (d), the reservation
forwarded out interface (a) considers only the reservation on forwarded out interface (a) considers only the reservation on
interface (c); no merging takes place in this case. interface (c); no merging takes place in this case.
skipping to change at page 26, line 28 skipping to change at page 25, line 35
| |
| _______ | _______
WF( *{B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} ) WF( *{B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} )
| |_______| | |_______|
| |
-----------------------|---------------------------------------- -----------------------|----------------------------------------
| _______ | _______
WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} ) WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} )
| |_______| | |_______|
Figure 10: Wildcard-Filter Reservation Example -- Partial Routing Figure 10: WF Reservation Example -- Partial Routing
Finally, we note that state that is received through a particular Finally, we note that state that is received through a particular
interface Iout in never forwarded out the same interface. interface I is never forwarded out the same interface. Conversely,
Conversely, state that is forwarded out interface Iout must be state that is forwarded out interface I must be computed using only
computed using only state that arrived on interfaces different from state that arrived on interfaces different from I. A trivial example
Iout. A trivial example of this rule is illustrated in Figure 11, of this rule is illustrated in Figure 11, which shows a transit
which shows a transit router with one sender and one receiver on each router with one sender and one receiver on each interface (and
interface (and assumes one next/previous hop per interface). assumes one next/previous hop per interface). Interfaces (a) and (c)
Interfaces (a) and (c) are both outgoing and incoming interfaces for are both outgoing and incoming interfaces for this session. Both
this session. Both receivers are making wildcard-scope reservations, receivers are making wildcard-scope reservations, in which the RESV
in which the RESV messages are forwarded to all previous hops for messages are forwarded to all previous hops for senders in the group,
senders in the group, with the exception of the next hop from which with the exception of the next hop from which they came. These
they came. These result in independent reservations in the two result in independent reservations in the two directions.
directions.
________________ ________________
a | | c a | | c
( R1, S1 ) <----->| Router |<-----> ( R2, S2 ) ( R1, S1 ) <----->| Router |<-----> ( R2, S2 )
|________________| |________________|
Send | Receive Send | Receive
| |
WF( *{3B}) <-- (a) | (c) <-- WF( *{3B}) WF( *{3B}) <-- (a) | (c) <-- WF( *{3B})
| |
skipping to change at page 28, line 25 skipping to change at page 27, line 25
permissible ordering and choice of object types. These rules are permissible ordering and choice of object types. These rules are
specified using Backus-Naur Form (BNF) augmented with square specified using Backus-Naur Form (BNF) augmented with square
brackets surrounding optional sub-sequences. brackets surrounding optional sub-sequences.
4.1.1 Common Header 4.1.1 Common Header
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Vers | Flags| Type | RSVP Checksum | | Vers | Flags| Type | RSVP Checksum |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Message Length | (Reserved) | | RSVP Length | (Reserved) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Message ID |
+----------+--+-------------+-------------+-------------+
|(Reserved)|MF| Fragment offset |
+----------+--+-------------+-------------+-------------+
The fields in the common header are as follows: The fields in the common header are as follows:
Vers Vers: 4 bits
Protocol version number. This is version 2. Protocol version number. This is version 1.
Flags Flags: 4 bits
(None defined yet) (None defined yet)
Type Type: 8 bits
1 = PATH 1 = PATH
2 = RESV 2 = RESV
3 = PERR 3 = PERR
4 = RERR 4 = RERR
5 = PTEAR 5 = PTEAR
6 = RTEAR 6 = RTEAR
RSVP Checksum
RSVP Checksum: 16 bits
A standard TCP/UDP checksum over the contents of the RSVP A standard TCP/UDP checksum over the contents of the RSVP
message, with the checksum field replaced by zero. message, with the checksum field replaced by zero.
Message Length RSVP Length: 16 bits
The total length of this RSVP message in bytes, including The total length of this RSVP packet in bytes, including
this common header and the variable-length objects that the common header and the variable-length objects that
follow. follow. If the MF flag is on or the Fragment Offset field
is non-zero, this is the length of the current fragment of
a larger message.
Message ID: 32 bits
A label shared by all fragments of one message from a
given next/previous RSVP hop. An RSVP implementation
assignes a unique Message ID to each message it sends.
MF: More Fragments Flag: 1 bit
This flag is the low-order bit of a byte; the seven high-
order bits are reserved. It is on for all but the last
fragment of a message.
Fragment Offset: 24 bits
This field gives the byte offset of the fragment in the
message.
4.1.2 Object Formats 4.1.2 Object Formats
An object consists of one or more 32-bit words with a one-word An object consists of one or more 32-bit words with a one-word
header, in the following format: header, in the following format:
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type | | Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 31, line 32 skipping to change at page 31, line 5
Contains cryptographic data to authenticate the Contains cryptographic data to authenticate the
originating node, and perhaps to verify the contents, originating node, and perhaps to verify the contents,
of this RSVP message. of this RSVP message.
SCOPE SCOPE
An explicit specification of the scope for forwarding An explicit specification of the scope for forwarding
a RESV message. a RESV message.
TAG
Encloses a list of one or more objects and attaches a
logical name or "tag" value to them. The tag value
is unique to the next/previous hop and the session
(specified by HOP and SESSION objects, respectively).
The enclosed object list is the "tagged sublist", and
the objects in it said to be "tagged" with the tag
value. Objects in a particular tagged sublist must
all have the same class-num.
Tagged objects with the same tag value are declared
to be logically related, i.e., to be members of some
larger logical set of objects. Note that the tagged
sublist implies no ordering; it defines only a set of
objects.
The meaning of the logical relationship depends upon
the class-num of the tagged objects.
C-Type C-Type
Object type, unique within Class-Num. Values are defined Object type, unique within Class-Num. Values are defined
in Appendix A. in Appendix A.
The maximum object content length is 65528 bytes. The Class- The maximum object content length is 65528 bytes. The Class-
Num and C-Type fields (together with the 'Optional' flag bit) Num and C-Type fields (together with the 'Optional' flag bit)
may be used together as a 16-bit number to define a unique type may be used together as a 16-bit number to define a unique type
for each object. for each object.
The high-order bit of the Class-Num is used to determine what The high-order bit of the Class-Num is used to determine what
action a node should take if it does not recognize the Class- action a node should take if it does not recognize the Class-
skipping to change at page 32, line 31 skipping to change at page 31, line 34
when defining and deploying new object types. when defining and deploying new object types.
4.1.3 Path Message 4.1.3 Path Message
PATH messages carry information from senders to receivers along PATH messages carry information from senders to receivers along
the paths used by the data packets. The IP destination address the paths used by the data packets. The IP destination address
of a PATH message is the DestAddress for the session; the of a PATH message is the DestAddress for the session; the
source address is an address of the node that sent the message source address is an address of the node that sent the message
(preferably the address of the interface through which it was (preferably the address of the interface through which it was
sent). The PHOP (i.e., the RSVP_HOP) object of each PATH sent). The PHOP (i.e., the RSVP_HOP) object of each PATH
message should contain the IP source address. message must contain the address of the interface through which
the PATH message was sent.
The format of a PATH message is as follows: The format of a PATH message is as follows:
<Path Message> ::= <Common Header> <SESSION> <RSVP_HOP> <Path Message> ::= <Common Header> <SESSION> <RSVP_HOP>
[ <INTEGRITY> ] [ <TIME_VALUES> ] [ <INTEGRITY> ] [ <TIME_VALUES> ]
<sender descriptor list> <sender descriptor list>
<sender descriptor list> ::= <empty > | <sender descriptor list> ::= <empty > |
skipping to change at page 33, line 39 skipping to change at page 32, line 41
A PATH message received at a node is processed to create path A PATH message received at a node is processed to create path
state for all senders defined by SENDER_TEMPLATE objects in the state for all senders defined by SENDER_TEMPLATE objects in the
sender descriptor list. If present, any POLICY_DATA, sender descriptor list. If present, any POLICY_DATA,
SENDER_TSPEC, and ADSPEC objects are also saved in the path SENDER_TSPEC, and ADSPEC objects are also saved in the path
state. If an error is encountered while processing a PATH state. If an error is encountered while processing a PATH
message, a PERR message is sent to all senders implied by the message, a PERR message is sent to all senders implied by the
SENDER_TEMPLATEs. SENDER_TEMPLATEs.
Periodically, the path state is scanned to create new PATH Periodically, the path state is scanned to create new PATH
messages which are forwarded upstream. A node must messages to be forwarded downstream. A node must independently
independently compute the route for each sender descriptor compute the route for each sender descriptor being forwarded.
being forwarded. These routes, obtained from uni-/multicast These routes, obtained from uni-/multicast routing, generally
routing, generally depend upon the (sender host address, depend upon the (sender host address, DestAddress) pairs and
DestAddress) pairs and consist of a list of outgoing consist of a list of outgoing interfaces. The descriptors
interfaces. The descriptors being forwarded through the same being forwarded through the same outgoing interface may be
outgoing interface may be packed into as few PATH messages as packed into as few PATH messages as possible. Note that
possible. Note that multicast routing of path information is multicast routing of path information is based on the sender
based on the sender address(es) from the sender descriptors, address(es) from the sender descriptors, not the IP source
not the IP source address; this is necessary to prevent routing address; this is necessary to prevent routing loops; see
loops; see Section 4.3. Section 4.3.
Multicast routing may also report the expected incoming Multicast routing may also report the expected incoming
interface (i.e., the shortest path back to the sender). If so, interface (i.e., the shortest path back to the sender). If so,
any PATH message that arrives on a different interface should any PATH message that arrives on a different interface should
be discarded immediately. be discarded immediately.
It is possible that routing will report no routes for a It is possible that routing will report no routes for a
(sender, DestAddress) pair; path state for this sender should (sender, DestAddress) pair; path state for this sender should
be stored locally but not forwarded. be stored locally but not forwarded.
skipping to change at page 34, line 29 skipping to change at page 33, line 31
that sent the message. The NHOP (i.e., the RSVP_HOP) object that sent the message. The NHOP (i.e., the RSVP_HOP) object
must contain the IP address of the (incoming) interface through must contain the IP address of the (incoming) interface through
which the RESV message is sent. which the RESV message is sent.
The RESV message format is as follows: The RESV message format is as follows:
<Resv Message> ::= <Common Header> <SESSION> <RSVP_HOP> <Resv Message> ::= <Common Header> <SESSION> <RSVP_HOP>
[ <INTEGRITY> ] [ <TIME_VALUES> ] [ <INTEGRITY> ] [ <TIME_VALUES> ]
[ <SCOPE> ] [ <S_POLICY_DATA> ] [ <SCOPE> ]
<STYLE> <flow descriptor list> <STYLE> <flow descriptor list>
The following style-dependent rules control the composition of <S_POLICY_DATA> ::= <POLICY DATA>
a valid flow descriptor list.
<flow descriptor list> ::= <flow descriptor> |
<flow descriptor list> <flow descriptor>
Here the S_POLICY_DATA object is a POLICY_DATA object that is
associated with the session, i.e., with all the flows that may
be listed. There may also be flow-specific POLICY_DATA
objects, as described below.
The BNF above defines a flow descriptor list as simply a list
of flow descriptors. The following style-dependent rules
specify more exactly the composition of a valid flow descriptor
list.
o WF Style: o WF Style:
<flow descriptor list> ::= <flow descriptor list> ::= <WF flow descriptor>
<FLOWSPEC> [ <POLICY_DATA> ] [ <FILTER_SPEC> ] <WF flow descriptor> ::=
A FILTER_SPEC that is entire wildcard may be omitted. <FLOWSPEC> [ <F_POLICY_DATA> ] <FILTER_SPEC>
<F_POLICY_DATA> ::= <POLICY_DATA>
o FF style: o FF style:
<flow descriptor list> ::= <flow descriptor list> ::= <FF flow descriptor> |
<FLOWSPEC> [ <POLICY_DATA> ] <FILTER_SPEC> <flow descriptor list> <FF flow descriptor>
| <flow descriptor list> [ <FLOWSPEC> ]
[ <POLICY_DATA> ] <FILTER_SPEC> <FF flow descriptor> ::=
[ <FLOWSPEC> ] [ <F_POLICY_DATA> ] <FILTER_SPEC>
Each elementary FF style request is defined by a single Each elementary FF style request is defined by a single
(FLOWSPEC, FILTER_SPEC) pair, and multiple such requests (FLOWSPEC, FILTER_SPEC) pair, and multiple such requests
may be packed into the flow descriptor list of a single may be packed into the flow descriptor list of a single
RESV message. A FLOWSPEC or POLICY_DATA object can be RESV message. A FLOWSPEC or POLICY_DATA object can be
omitted if it is identical to the most recent such object omitted if it is identical to the most recent such object
that appeared in the list. that appeared in the list.
o SE style: o SE style:
<flow descriptor list> ::= <SE descriptor> <flow descriptor list> ::= <SE descriptor>
| <flow descriptor list> <SE descriptor> | <flow descriptor list> <SE flow descriptor>
<SE descriptor> ::= <FLOWSPEC> [ <POLICY_DATA> ] <SE flow descriptor> ::=
<filter spec list> <FLOWSPEC> [ <F_POLICY_DATA> ] <filter spec list>
<filter spec list> ::= <FILTER_SPEC> <filter spec list> ::= <FILTER_SPEC>
| <filter spec list> <FILTER_SPEC> | <filter spec list> <FILTER_SPEC>
Each elementary SE style request is defined by a single SE Each elementary SE style request is defined by a single SE
descriptor, which includes a FLOWSPEC defining the shared descriptor, which includes a FLOWSPEC defining the shared
reservation, possibly a POLICY_DATA object, and a list of reservation, possibly a POLICY_DATA object, and a list of
FILTER_SPEC objects. Multiple elementary requests, each FILTER_SPEC objects. Multiple elementary requests, each
representing an independent shared reservation, may be representing an independent shared reservation, may be
skipping to change at page 36, line 10 skipping to change at page 35, line 26
ignored. ignored.
o For a style with wildcard scope, a SCOPE object, if o For a style with wildcard scope, a SCOPE object, if
present, defines the scope with an explicit list of sender present, defines the scope with an explicit list of sender
IP addresses (see Section 4.3 below). If there is no IP addresses (see Section 4.3 below). If there is no
SCOPE object, the scope is determined by the relevant set SCOPE object, the scope is determined by the relevant set
of senders in the path state. A SCOPE object must be sent of senders in the path state. A SCOPE object must be sent
in any wildcard scope RESV message that is forwarded to in any wildcard scope RESV message that is forwarded to
more than one previous hop. See Section 4.3 below. more than one previous hop. See Section 4.3 below.
If an outgoing message is too large to fit into the MTU of the
interface, it can be sent as multiple messages, as follows:
o For FF style, the flow descriptor list can be split as
required to fit; the rest of the message should be
replicated into each packet.
o For WF style, a SCOPE object containing an explicit list
of sender IP addresses can be split as required to fit;
the rest of the message should be replicated into each
packet.
o For SE style, the flow descriptor list can be split as
required to fit; the rest of the message should be
replicated into each packet.
If a single SE descriptor is too large to fit, its filter
spec list can similarly be split as required. However,
the subsets of a particular filter spec list must each be
enclosed in TAG objects carrying the same tag value, so
the receiver will be able to match each FILTER_SPEC object
to the appropriate shared reservation.
4.1.5 Error Messages 4.1.5 Error Messages
There are two types of RSVP error messages. There are two types of RSVP error messages.
o PERR messages result from PATH messages and travel towards o PERR messages result from PATH messages and travel towards
senders. PERR messages are routed hop-by-hop using the senders. PERR messages are routed hop-by-hop using the
path state; at each hop, the IP destination address is the path state; at each hop, the IP destination address is the
unicast address of a previous hop. unicast address of a previous hop.
o RERR messages result from RESV messages and travel towards o RERR messages result from RESV messages and travel towards
skipping to change at page 37, line 12 skipping to change at page 36, line 4
Errors encountered while processing error messages must not Errors encountered while processing error messages must not
create further error messages. create further error messages.
<PathErr message> ::= <Common Header> <SESSION> <PathErr message> ::= <Common Header> <SESSION>
[ <INTEGRITY> ] <ERROR_SPEC> [ <INTEGRITY> ] <ERROR_SPEC>
<sender descriptor> <sender descriptor>
<sender descriptor> ::= (see earlier definition) <sender descriptor> ::= (see earlier definition)
<ResvErr Message> ::= <Common Header> <SESSION> <ResvErr Message> ::= <Common Header> <SESSION>
[ <INTEGRITY> ] <ERROR_SPEC> [ <INTEGRITY> ] [S_POLICY_DATA]
<ERROR_SPEC>
<STYLE> <error flow descriptor> <STYLE> <error flow descriptor>
The following style-dependent rules control the composition of The following style-dependent rules define the composition of a
a valid error flow descriptor. valid error flow descriptor in terms of sequences defined
earlier:
o WF Style: o WF Style:
<error flow descriptor> ::= <FLOWSPEC> [ <FILTER_SPEC> ] <error flow descriptor> ::= <WF flow descriptor>
o FF style: o FF style:
<error flow descriptor> ::= <FLOWSPEC> <FILTER_SPEC> <error flow descriptor> ::= <FF flow descriptor>
o SE style: o SE style:
<error flow descriptor> ::= <FLOWSPEC> <filter spec list> <error flow descriptor> ::= <SE flow descriptor>
POLICY_DATA objects need be included in error messages only for
information when they are relevant (i.e., when an
administrative failure is being reported).
The ERROR_SPEC object specifies the error and includes the IP The ERROR_SPEC object specifies the error and includes the IP
address of the node that detected the error (Error Node address of the node that detected the error (Error Node
Address). Address).
When a PATH or RESV message has been "packed" with multiple When a PATH or RESV message has been "packed" with multiple
sets of elementary parameters, the RSVP implementation should sets of elementary parameters, the RSVP implementation should
process each set independently and return a separate error process each set independently and return a separate error
message for each that is in error. message for each that is in error.
In general, error messages should be delivered to the In general, error messages should be delivered to the
applications on all the session nodes that (may have) applications on all the session nodes that (may have)
contributed to this error. More specifically: contributed to this error. A PERR message is forwarded to all
previous hops for all senders listed in the Sender Descriptor
o A PERR message is forwarded to all previous hops for all List. A RERR message is generally forwarded towards all
senders listed in the Sender Descriptor List. receivers that may have caused the error being reported. More
specifically:
o A RERR message is generally forwarded to all receivers
that may have caused the error being reported.
The node that creates a RERR message sends the RERR
message to the next hop from which the erroneous
reservation came. The message must contain the
information required to define the error and to route the
error message. Thus, it contains the STYLE, a FLOWSPEC,
and one or more FILTER_SPEC(s) from the erroneous RESV
message.
In succeeding hops, a RERR message is forwarded using the o The node that detects an error in a reservation request
node's reservation state, to the next hops of reservations creates and sends an RERR message to the next hop from
that match the FILTER_SPEC(s) and the FLOWSPEC in the RERR which the erroneous reservation came.
message. Assume that a reservation whose error is being
reported was formed by merging two flowspecs Q1 and Q2
from different next hops.
- If Q1 = Q2, the error message should be forwarded to The message must contain the information required to
both next hops. define the error and to route the error message. Routing
requires at least a STYLE object and one or more
FILTER_SPEC object(s) from the erroneous RESV message.
For an admission control failure, for example, the
erroneous FLOWSPEC must be included.
- If Q1 < Q2, the error message should be forwarded o Succeeding nodes forward the RERR message using their
only to the next hop for Q2. local reservation state, to the next hops of reservations
that match the FILTER_SPEC(s) in the message. For
reservations with wildcard scope, there is an additional
limitation on forwarding RERR messages, to avoid loops;
see Section 4.3.
- If Q1 and Q2 are incomparable, the error message When the error is an admission control failure, a node is
should be forwarded to both next hops, and the LUB- allowed (but not required) to match the FLOWSPEC as well as the
Used flag should be turned on. FILTER_SPEC object(s), to limit the distribution of a RERR
message to those receivers that `caused' the error. Suppose
that a RERR message contains a FLOWSPEC Qerr that is being
matched against the FLOWSPEC Qlocal in the local reservation
state in node N. Qerr, which originated in a node upstream
from N, resulted from merging of flowspecs that included
Qlocal. Generally, a RERR message can be forwarded to the
receiver(s) that specified the `biggest' flowspec. The
comparison of Qerr against a particular Qlocal to determine
whether Qlocal qualifies as (one of) the `biggest', may be
called `de-merging'. As with merging, the details of de-
merging depend upon the service and the FLOWSPEC format, and
are outside RSVP itself.
The RERR message that is forwarded should carry the A RERR message that is forwarded should carry the FILTER_SPEC
FILTER_SPEC from the corresponding reservation state (thus from the corresponding reservation state (thus `un-merging' the
`un-merging' the filter spec). For reservations with filter spec).
wildcard scope, there is an additional limitation on
forwarding RERR messages, to avoid loops; see Section 4.3
below.
When a RERR message reaches a receiver, the STYLE object, When a RERR message reaches a receiver, the STYLE object, flow
flow descriptor list, and ERROR_SPEC object (which descriptor list, and ERROR_SPEC object (which contains the
contains the LUB-Used flag) should be delivered to the LUB-Used flag) should be delivered to the receiver application.
receiver application. In the case of an Admission Control In the case of an Admission Control error, the flow descriptor
error, the flow descriptor list will contain the FLOWSPEC list will contain the FLOWSPEC object that failed. If the
object that failed. If the LUB-Used flag is off, this LUB-Used flag is off, this should be `equal' to (but not
should be `equal' to (but not necessarily identical to) necessarily identical to) the FLOWSPEC originated by this
the FLOWSPEC originated by this application; otherwise, application; otherwise, they may differ.
they may differ.
4.1.6 Teardown Messages 4.1.6 Teardown Messages
There are two types of RSVP Teardown message, PTEAR and RTEAR. There are two types of RSVP Teardown message, PTEAR and RTEAR.
o A PTEAR message deletes path state (which may, in turn, o A PTEAR message deletes path state (which may, in turn,
delete reservation state) and travels towards all delete reservation state) and travels towards all
receivers that are downstream from the point of receivers that are downstream from the point of
initiation. A PTEAR message is routed like a PATH initiation. A PTEAR message is routed like a PATH
message, and its IP destination address is DestAddress for message, and its IP destination address is DestAddress for
skipping to change at page 40, line 28 skipping to change at page 39, line 28
RSVP messages are sent hop-by-hop between RSVP-capable routers as RSVP messages are sent hop-by-hop between RSVP-capable routers as
"raw" IP datagrams with protocol number 46. Raw IP datagrams are "raw" IP datagrams with protocol number 46. Raw IP datagrams are
similarly intended to be used between an end system and the similarly intended to be used between an end system and the
first/last hop router; however, it is also possible to encapsulate first/last hop router; however, it is also possible to encapsulate
RSVP messages as UDP datagrams for end-system communication, as RSVP messages as UDP datagrams for end-system communication, as
described in Appendix C. UDP encapsulation may simplify described in Appendix C. UDP encapsulation may simplify
installation of RSVP on current end systems, particularly when installation of RSVP on current end systems, particularly when
firewalls are in use. firewalls are in use.
Under overload conditions, lost RSVP control messages could cause
a failure of resource reservations. Routers should be configured
to give a preferred class of service to RSVP packets. RSVP should
not use significant bandwidth, but queueing delay and dropping of
RSVP messages needs to be controlled.
An RSVP PATH or RESV message generally consists of a small root
segment followed by a potentially unbounded variable-length list
of objects. The variable part may overflow the capacity of one
datagram. If RSVP used IP fragmentation and reassembly (or an
equivalent byte-by-byte fragmentation mechanism at the RSVP
level), loss of a single packet would unnecessarily lose the
entire state update for a session. It is instead recommended that
an RSVP implementation use "semantic" fragmentation, using the
structure of the RSVP message.
An unbounded list in an RSVP message in fact consists of
individual atomic elements that are packed together for
efficiency. Wben sending a message, an RSVP should therefore pack
only what will fit into one packet, and then continue packing with
the next packet, etc. Each of these messages will be processed
independently at the receiving node, each updating its part of the
session state in the node. No explicit reassembly is needed.
Since RSVP messages are normally expected to be generated and sent
hop-by-hop, their MTU should be determined by the MTU of each
interface.
Upon the arrival of an RSVP message M that changes the state, a Upon the arrival of an RSVP message M that changes the state, a
node must forward the modified state immediatly. If this is node must forward the modified state immediatly. If this is
implemented as an immediate refresh of all the state for the implemented as an immediate refresh of all the state for the
session, then no refresh messages should be sent out the interface session, then no refresh messages should be sent out the interface
through which M arrived. This rule is necessary to prevent packet through which M arrived. This rule is necessary to prevent packet
storms on broadcast LANs. storms on broadcast LANs.
An RSVP message must be fragmented when necessary to fit into the
MTU of the interface through which it will be sent. All fragments
of the message should carry the same unique value of the Message
ID field, as well as appropriate Fragment Offset and MF bits, in
their common headers. When an RSVP message arrives, it must be
reassembled before it can be processed. The refresh period R is
appropriate as a ressembly timeout time.
Since RSVP messages are normally expected to be generated and sent
hop-by-hop, using the RSVP-level fragmentation mechanism should
result in no IP fragmentation. However, IP fragmentation may
occur through a non-RSVP cloud. For IP6, which does not support
router fragmentation, this case will require that the RSVP
implementation use Path MTU Discovery or hand configuration to
obtain an appropriate MTU.
Under overload conditions, lost RSVP control messages could cause
a failure of resource reservations. Routers should be configured
to give a preferred class of service to RSVP packets. RSVP should
not use significant bandwidth, but queueing delay and dropping of
RSVP messages needs to be controlled. Loss of RSVP packets
through a congested non-RSVP cloud may still be a problem. The
simplest solution is to adopt a larger value for the timeout
factor K (see section 4.5 below). If this does not suffice,
neighboring RSVP routers could use a TCP connection to pass RSVP
messages through a non-RSVP cloud. The current protocol contains
no automatic mechanism to setting up such connections; hand
configuration is assumed.
Some multicast routing protocols provide for "multicast tunnels", Some multicast routing protocols provide for "multicast tunnels",
which encapsulate multicast packets for transmission through which encapsulate multicast packets for transmission through
routers that do not have multicast capability. A multicast tunnel routers that do not have multicast capability. A multicast tunnel
looks like a logical outgoing interface that is mapped into some looks like a logical outgoing interface that is mapped into some
physical interface. A multicast routing protocol that supports physical interface. A multicast routing protocol that supports
tunnels will describe a route using a list of logical rather than tunnels will describe a route using a list of logical rather than
physical interfaces. RSVP can support multicast tunnels in the physical interfaces. RSVP can support multicast tunnels in the
following manner: following manner:
1. When a node N forwards a PATH message out a logical outgoing 1. When a node N forwards a PATH message out a logical outgoing
skipping to change at page 43, line 28 skipping to change at page 42, line 30
session. session.
If reservation state from some NHOP does not contain a SCOPE If reservation state from some NHOP does not contain a SCOPE
object, a substitute sender list must be created and included object, a substitute sender list must be created and included
in the union. For a wildcard scope (WF) message that arrived in the union. For a wildcard scope (WF) message that arrived
on outgoing interface OI, the substitute list is the set of on outgoing interface OI, the substitute list is the set of
senders that route to OI. For an explicit scope (SE) senders that route to OI. For an explicit scope (SE)
message, it is the set of senders explicitly listed in the message, it is the set of senders explicitly listed in the
message. message.
2. Any local senders are removed from this set. 2. Any local senders (i.e., any sender applications on this
node) are removed from this set.
3. If the SCOPE object is to be sent to PHOP, remove from the 3. If the SCOPE object is to be sent to PHOP, remove from the
set any senders that did not come from PHOP. set any senders that did not come from PHOP.
Figure 12 shows an example of wildcard-scoped (WF style) RESV Figure 12 shows an example of wildcard-scoped (WF style) RESV
messages. The address lists within SCOPE objects are shown in messages. The address lists within SCOPE objects are shown in
square brackets. Note that there may be additional connections square brackets. Note that there may be additional connections
among the nodes, creating looping topology that is not shown. among the nodes, creating looping topology that is not shown.
________________ ________________
skipping to change at page 45, line 20 skipping to change at page 44, line 20
short refresh periods, the local routing protocol module can short refresh periods, the local routing protocol module can
notify the RSVP daemon of route changes for particular notify the RSVP daemon of route changes for particular
destinations. The RSVP daemon should use this information to destinations. The RSVP daemon should use this information to
trigger an immediate refresh of state for these destinations, trigger an immediate refresh of state for these destinations,
using the new route. using the new route.
More specifically, the rules are as follows: More specifically, the rules are as follows:
o When routing detects a change of the set of outgoing o When routing detects a change of the set of outgoing
interfaces for sending PATH messages for destination G, RSVP interfaces for sending PATH messages for destination G, RSVP
should send immediate PATH refreshes for all sessions G/* sends immediate PATH refreshes for all sessions G/* (i.e.,
(i.e., for any session with destination G, regardless of for any session with destination G, regardless of destination
destination port). port). Such refresh messages are to be sent to at least the
new outgoing interfaces for these sessions.
o When a PATH message arrives with a Previous Hop address that o When a PATH message arrives with a Previous Hop address that
differs from the one stored in the path state, RSVP should differs from the one stored in the path state, RSVP should
send immediate RESV refreshes for that session. send immediate RESV refreshes for that session.
4.5 Time Parameters 4.5 Time Parameters
There are two time parameters relevant to each element of RSVP There are two time parameters relevant to each element of RSVP
path or reservation state in a node: the refresh period R between path or reservation state in a node: the refresh period R between
receiving successive refreshes for the state, and its lifetime L. receiving successive refreshes for the state, and its lifetime L.
skipping to change at page 47, line 7 skipping to change at page 46, line 7
synchronization and burstiness of refreshes. synchronization and burstiness of refreshes.
8. The values of Rdef, K, and Slew.Max used in an implementation 8. The values of Rdef, K, and Slew.Max used in an implementation
should be easily modifiable, as experience may lead to should be easily modifiable, as experience may lead to
different values. The possibility of dynamically changing K different values. The possibility of dynamically changing K
and/or Slew.Max in response to measured loss rates is for and/or Slew.Max in response to measured loss rates is for
future study. future study.
4.6 RSVP Interfaces 4.6 RSVP Interfaces
RSVP on a router has interfaces to routing and to traffic control RSVP on a router has interfaces to routing and to traffic control.
in the kernel. RSVP on a host has an interface to applications RSVP on a host has an interface to applications (i.e, an API) and
(i.e, an API) and also an interface to traffic control (if it also an interface to traffic control (if it exists on the host).
exists on the host).
4.6.1 Application/RSVP Interface 4.6.1 Application/RSVP Interface
This section describes a generic interface between an This section describes a generic interface between an
application and an RSVP control process. The details of a real application and an RSVP control process. The details of a real
interface may be operating-system dependent; the following can interface may be operating-system dependent; the following can
only suggest the basic functions to be performed. Some of only suggest the basic functions to be performed. Some of
these calls cause information to be returned asynchronously. these calls cause information to be returned asynchronously.
o Register o Register
skipping to change at page 50, line 4 skipping to change at page 48, line 49
o Release o Release
Call: RELEASE( session-id ) Call: RELEASE( session-id )
This call will terminate RSVP state for the session This call will terminate RSVP state for the session
specified by session-id. It may send appropriate teardown specified by session-id. It may send appropriate teardown
messages and will cease sending refreshes for this messages and will cease sending refreshes for this
session-id. session-id.
o Error/Event Upcalls o Error/Event Upcalls
Upcall: <Upcall_Proc>( ) -> session-id, Info_type,
Upcall: <Upcall_Proc>( ) -> session-id, Info_type,
[ Error_code , Error_value , LUB-Used, ] [ Error_code , Error_value , LUB-Used, ]
List_count, [ Flowspec_list,] List_count, [ Flowspec_list,]
[ Filter_spec_list, ] [ Advert_list, ] [ Filter_spec_list, ] [ Advert_list, ]
[ Policy_data ] [ Policy_data ]
Here "Upcall_Proc" represents the upcall procedure whose Here "Upcall_Proc" represents the upcall procedure whose
address was supplied in the REGISTER call. address was supplied in the REGISTER call.
skipping to change at page 55, line 4 skipping to change at page 53, line 47
If requested by a route query with the Notify_flag True, If requested by a route query with the Notify_flag True,
the routing daemon may provide an asynchronous callback to the routing daemon may provide an asynchronous callback to
RSVP that a specified route has changed. RSVP that a specified route has changed.
Ucast_Route_Change( ) -> DestAddress, OutInterface Ucast_Route_Change( ) -> DestAddress, OutInterface
Mcast_Route_Change( ) Mcast_Route_Change( )
-> SrcAddress, DestAddress, OutInterface_list -> SrcAddress, DestAddress, OutInterface_list
o Outgoing Link Specification
o Outgoing Link Specification
RSVP must be able to force a (multicast) datagram to be RSVP must be able to force a (multicast) datagram to be
sent on a specific outgoing virtual link, bypassing the sent on a specific outgoing virtual link, bypassing the
normal routing mechanism. A virtual link may be a real normal routing mechanism. A virtual link may be a real
outgoing link or a multicast tunnel. Outgoing link outgoing link or a multicast tunnel. Outgoing link
specification is necessary because RSVP may send different specification is necessary because RSVP may send different
versions of outgoing PATH messages for the same source and versions of outgoing PATH messages for the same source and
destination addresses on different interfaces. It is also destination addresses on different interfaces. It is also
necessary in some cases to avoid routing loops. necessary in some cases to avoid routing loops.
o Discover Interface List o Discover Interface List
skipping to change at page 56, line 37 skipping to change at page 55, line 37
MESSAGE ARRIVES MESSAGE ARRIVES
Verify version number, checksum, and length fields of common header, Verify version number, checksum, and length fields of common header,
and discard message if any mismatch is found. and discard message if any mismatch is found.
Further processing depends upon message type. Further processing depends upon message type.
PATH MESSAGE ARRIVES PATH MESSAGE ARRIVES
Start with the Refresh_Needed flag off.
Each sender descriptor object sequence in the message defines a Each sender descriptor object sequence in the message defines a
sender. Process each sender as follows, starting the sender. Process each sender as follows, starting the
Path_Refresh_Needed and Resv_Refresh_Needed flags off. Path_Refresh_Needed and Resv_Refresh_Needed flags off.
1. If there is a POLICY_DATA object, verify it; if it is 1. If there is a POLICY_DATA object, verify it; if it is
unacceptable, build and send a "Administrative Rejection" unacceptable, build and send a "Administrative Rejection"
PERR message, drop the PATH message, and return. PERR message, drop the PATH message, and return.
2. Call the appropriate Route_Query routine, using DestAddress 2. Call the appropriate Route_Query routine, using DestAddress
from SESSION and (for multicast routing) SrcAddress from from SESSION and (for multicast routing) SrcAddress from
skipping to change at page 58, line 7 skipping to change at page 57, line 5
o If the new ROUTE_MASK differs from that stored in the o If the new ROUTE_MASK differs from that stored in the
PSB, turn on the Path_Refresh_Needed flag, and store PSB, turn on the Path_Refresh_Needed flag, and store
the new ROUTE_MASK into the PSB. the new ROUTE_MASK into the PSB.
o If the new EXPECTED_INTERFACE differs from that stored o If the new EXPECTED_INTERFACE differs from that stored
in the PSB, turn on the Resv_Refres_Needed flag and in the PSB, turn on the Resv_Refres_Needed flag and
store the new EXPECTED_INTERFACE value into the PSB. store the new EXPECTED_INTERFACE value into the PSB.
7. Save the IP TTL with which the message arrived in the PSB . 7. Save the IP TTL with which the message arrived in the PSB .
8. If the Refresh_Needed flag is now set, execute the PATH 8. If the Path_Refresh_Needed flag is now set, execute the
REFRESH event sequence (below); however, send no PATH PATH REFRESH event sequence (below); however, send no PATH
refresh messages out the interface through which the PATH refresh messages out the interface through which the PATH
message arrived. message arrived.
9. If the Resv_Needed flag is now set, execute the RESV 9. If the Resv_Needed flag is now set, execute the RESV
REFRESH event sequence (below). REFRESH event sequence (below).
PATH TEAR MESSAGE ARRIVES PATH TEAR MESSAGE ARRIVES
o If there is no path state for this destination, drop the o If there is no path state for this destination, drop the
message and return. message and return.
skipping to change at page 62, line 22 skipping to change at page 61, line 15
If processing a RESV message finds an error, a RERR message is If processing a RESV message finds an error, a RERR message is
created containing flow descriptor and an ERRORS object. The created containing flow descriptor and an ERRORS object. The
Error Node field of the ERRORS object (see Appendix A) is set to Error Node field of the ERRORS object (see Appendix A) is set to
the IP address of OI, and the message is sent unicast to NHOP. the IP address of OI, and the message is sent unicast to NHOP.
RESV TEAR MESSAGE ARRIVES RESV TEAR MESSAGE ARRIVES
A RTEAR message arrives on outgoing interface OI. A RTEAR message arrives on outgoing interface OI.
o If there are no existing PSB's for SESSION then drop the o Initialize flag Tear_Needed to False.
RTEAR message and return.
o Process the flow descriptor list sequence to tear down
reservations.
For FF style, execute the following steps for each b flow o Execute the following steps for each flow descriptor, i.e.,
descriptor, i.e., each (FLOWSPEC, FILTERSPEC) pair. For WF each (FLOWSPEC, FILTERSPEC) pair, in the flow descriptor
style execute the following once, using some internal list:
placeholder "WILD_FILTER" for FILTERSPEC to indicate
wildcard scope.
1. Find matching RSB(s) for the 4-tuple: (SESSION, NHOP, 1. Find matching RSB for the 4-tuple: (SESSION, NHOP,
style, FILTERSPEC). If no RSB is found, continue with style, FILTER_SPEC). If no RSB is found, continue
next flow descriptor, if any. with next flow descriptor.
2. Delete the RSB(s). 2. Delete the RSB.
3. If there are no more RSBs for the same (SESSION, OI, 3. If there are no more RSBs for the same (SESSION, OI,
FILTERSPEC/) triple, call the kernel interface module: FILTER_SPEC) triple, call the kernel interface to
delete the reservation:
TC_DelFlowspec( K_handle ) TC_DelFlowspec( K_handle )
to delete the reservation. Then build and forward a and set Tear_Needed to True.
new RTEAR message.
- WF style: send a copy to each PHOP among all
matching senders.
- FF style: Send to PHOP of matching PSB.
4. Otherwise (there are other RSB's for the same 4. Otherwise (there are other RSB's for the same
reservation), recompute K_Flowspec and call the kernel reservation), recompute K_Flowspec and call the kernel
interface module: interface module:
TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec) TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec)
to update the reservation, and then execute the RESV to update the reservation. If this kernel call fails,
REFRESH sequence (below). If this kernel call fails,
return; the prior reservation will remain in place. return; the prior reservation will remain in place.
o If Tear_Needed is False (the resulting merged state may
have changed but is still in place), then execute the RESV
REFRESH sequence below, drop RTEAR message, and return.
o Otherwise, need to create new RTEAR message for each PHOP,
and perhaps some RESV refresh messages.
Set Refresh_Needed flag to False. Do the following for
each sender Si (in the path stat) whose ROUTE_MASK includes
the outgoing interface OI and for each PHOP:
1. Pick each flow descriptor Fj in the RTEAR message
whose FILTER_SPEC matches Si, and do the following.
- If there is no RSB whose FILTER_SPEC matches Si,
then add Fj to the new RTEAR message being built.
- Otherwise (there is a matching RSB), note the
incoming interface of Si as an interface needing
a RESV refresh message and set the Refresh_Needed
flag True.
2. If the new RTEAR message contains any flow
descriptors, forward it to PHOP.
If the scope is wildcard, include only a single flow
descriptor in the message.
o If the Refresh_Needed flag is true, then execute the
RESV_REFRESH sequence below, for the incoming interfaces
that have been noted.
RESV ERROR MESSAGE ARRIVES RESV ERROR MESSAGE ARRIVES
o Call the appropriate route discovery routine, using o If there is no state for SESSION, then drop the RERR
DestAddress from SESSION and (for multicast routing) mesasge and return.
SrcAddress from the Error Node Address field in the ERRORS
object. Let the resulting routing bit mask be M.
o Determine the set of RSBs matching the triple: (SESSION, o For each RSB, do the following. Note that an RSB implies
style, FILTERSPEC). If no RSB is found, drop RERR message an outgoing interface OI and a next hop NHOP.
and return.
Recompute the maximum over the FLOWSPEC objects of this set 1. If OI differs from the incoming interface through
of RSB's. If the LUB was used in this computation, turn on which the RERR message arrived, continue with the next
the LUB-Used flag in the received RESV message. RSB.
o Delete from the set of RSVs any whose OI does not appear in 2. Compare the FILTER_SPEC(s) in the error flow
the bit mask M and whose NHOP is not the local API. If descriptor with the FILTER_SPEC(s) in the RSB. If no
none remain, drop RERR message and return. match, continue with the next RSB.
For each PSB in the resulting set, do the following step. Otherwise, form a new error flow descriptor with the
subset of FILTER_SPECs that matched.
o If NHOP in PSB is local API, deliver error to application 3. Compare the FLOWSPEC in the RERR message with the
via an upcall: FLOWSPEC in the RSB. If they don't match along any
coordinate (i.e., if the RSB FLOWSPEC is strictly
`smaller'), continue with the next RSB.
Call: <Upcall_Proc>( session-id, Resv Error, 1, If they agree on some but not all coordinates, turn on
the LUB-used flag.
4. If NHOP in PSB is local API, deliver error to
application via an upcall:
Call: <Upcall_Proc>( session-id, Resv Error, k,
Error_code, Error_value, LUB-Used, Error_code, Error_value, LUB-Used,
FILTER_SPEC, FLOWSPEC, NULL) Filter_Spec_List, Flowspec_List, NULL,
NULL)
Here LUB-Used flag is taken from the received packet, as and continue with the next RSB. Here k,
possibly modified above. Filter_Spec_List, and Flowspec_List are constructed
from the new error flow descriptor.
Otherwise (NHOP is not local API), forward a copy of the 5. If the RESV message has wildcard scope, use its SCOPE
RERR message to the PHOP node. object SC.In to construct a SCOPE object SC.Out to be
forwarded. SC.Out should contain those sender
addresses that appeared in SC.In and that route to OI
[LIH?], as determined by scanning the PSB's. If
SC.Out is empty, continue with the next RSB.
6. Create a new RERR message containing the new error
flow descriptor and send to the NHOP address specified
by the RSB. Include SC.Out if the scope is wildcard.
7. Continue with the next RSB.
o Drop the RERR message and return.
PATH REFRESH PATH REFRESH
This sequence may be entered by either the expiration of the path This sequence may be entered by either the expiration of the path
refresh timer for a particular session, or immediately as the result refresh timer for a particular session, or immediately as the result
of processing a PATH message turning on the Refresh_Needed flag. of processing a PATH message turning on the Path_Refresh_Needed flag.
For each outgoing interface OI, build a PATH message and send it to For each outgoing interface OI, build a PATH message and send it to
OI. To build the message, consider each PSB whose ROUTE_MASK OI. To build the message, consider each PSB whose ROUTE_MASK
includes OI, and do the following: includes OI, and do the following:
o Pass the ADSPEC and SENDER_TSPEC objects present in the PSB to o Pass the ADSPEC and SENDER_TSPEC objects present in the PSB to
the kernel call TC_Advertise, and get back a modified ADSPEC the kernel call TC_Advertise, and get back a modified ADSPEC
object. Pack this modified object into the PATH message being object. Pack this modified object into the PATH message being
built. built.
skipping to change at page 75, line 8 skipping to change at page 74, line 8
The low order bits of the option vector are determined by the The low order bits of the option vector are determined by the
style id, as follows: style id, as follows:
WF 10001b WF 10001b
FF 01010b FF 01010b
SE 10010b SE 10010b
A.8 FLOWSPEC Class A.8 FLOWSPEC Class
FLOWSPEC class = 9. FLOWSPEC class = 9.
The following C-Types for service types are defined. The o Class = 9, C-Type = 1: int-serv flowspec
corresponding object contents are specified in service template
documents created by the int-serv working group.
o Class = 9, C-Type = 1: Controlled-Delay Quality of Service
o Class = 9, C-Type = 2: Predictive Quality of Service
o Class = 9, C-Type = 3: Guaranteed Quality of Service
There is also a container C-Type, used to enclose a set of The contents of this object will be specified in documents
FLOWSPEC objects that could not be merged at a downstream node prepared by the int-serv working group.
because they include unrecognized C-Types.
o Class = 9, C-Type = 254: Controlled-Delay Quality of Service o Class = 9, C-Type = 254: Unmerged Flowspec List
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
// FLOWSPEC object 1 // // FLOWSPEC object 1 //
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
// FLOWSPEC object 2 // // FLOWSPEC object 2 //
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
// // // //
// // // //
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
// FLOWSPEC object k // // FLOWSPEC object k //
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
This is a container C-Type, used to enclose a set of FLOWSPEC
objects that could not be merged at the next hop downstream
because they include unrecognized C-Types. The node that
receives this object may merge those it recognizes and
forward the rest in another Unmerged Flowspec List object.
A.9 FILTER_SPEC Class A.9 FILTER_SPEC Class
FILTER_SPEC class = 10. FILTER_SPEC class = 10.
o IPv4 FILTER_SPEC object: Class = 10, C-Type = 1 o IPv4 FILTER_SPEC object: Class = 10, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 SrcAddress (4 bytes) | | IPv4 SrcAddress (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Protocol Id | ////// | SrcPort | | Protocol Id | ////// | SrcPort |
skipping to change at page 81, line 4 skipping to change at page 80, line 4
// POLICY_DATA object 2 // // POLICY_DATA object 2 //
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
// // // //
// // // //
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
// POLICY_DATA object k // // POLICY_DATA object k //
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
A.14 TAG class
TAG class = 20.
o TAG object: Class = 20, C-Type = 1
+-------------+-------------+-------------+-------------+
| Tag Value |
+-------------+-------------+-------------+-------------+
| |
// Tagged Sublist //
| |
+-------------+-------------+-------------+-------------+
Tag Value
The value of the tag being attached to the objects in
the Tagged Sublist. The tag value is unique for each
session and next/previous hop.
Tagged Sublist
A list of objects with the same class-num (but not
necessarily the same C-Type).
APPENDIX B. Error Codes and Values APPENDIX B. Error Codes and Values
The following Error Codes are defined. The following Error Codes are defined.
o Error Code = 01: Admission failure o Error Code = 01: Admission failure
Reservation rejected by admission control. Reservation rejected by admission control.
For this Error Code, the 16 bits of the Error Value field are: For this Error Code, the 16 bits of the Error Value field are:
suur cccc cccc cccc ussr cccc cccc cccc
where the bits are: where the bits are:
s = 0: RSVP should reject the message without updating local u = 0: RSVP should reject the message without updating local
state. state.
s = 1: RSVP may use message to update local state and propagate u = 1: RSVP may use message to update local state and forward
it. it.
uu = 00: Low order 12 bits contain a globally-defined sub-code ss = 00: Low order 12 bits contain a globally-defined sub-code
(values listed below). (values listed below).
uu = 10: Low order 12 bits contain a sub-code that is specific ss = 10: Low order 12 bits contain a sub-code that is specific
to local organization. RSVP is not expected to be able to to local organization. RSVP is not expected to be able to
interpret this except as a numeric value. interpret this except as a numeric value.
uu = 11: Low order 12 bits contain a sub-code that is specific ss = 11: Low order 12 bits contain a sub-code that is specific
to the service. RSVP is not expected to be able to to the service. RSVP is not expected to be able to
interpret this except as a numeric value. Since the interpret this except as a numeric value. Since the
traffic control mechanism might substitute a different traffic control mechanism might substitute a different
service, this encoding may include some representation of service, this encoding may include some representation of
the service in use. the service in use.
r: Reserved bit, should be zero. r: Reserved bit, should be zero.
cccc cccc cccc: 12 bit code. cccc cccc cccc: 12 bit code.
skipping to change at page 89, line 4 skipping to change at page 87, line 4
an "RSVP relay host". This system would listen on (G1,Pu) and an "RSVP relay host". This system would listen on (G1,Pu) and
be configured with the IP address of R. It could then forward be configured with the IP address of R. It could then forward
any (PATH) messages it received directly to R, and T1 could be any (PATH) messages it received directly to R, and T1 could be
set only large enough to reach local hosts and the relay. set only large enough to reach local hosts and the relay.
Finally, manual configuration of T1 could be replaced by an expanding Finally, manual configuration of T1 could be replaced by an expanding
ring search conducted by host RSVP daemons. This possibility is for ring search conducted by host RSVP daemons. This possibility is for
future study. future study.
APPENDIX D. Experimental and Open Issues APPENDIX D. Experimental and Open Issues
D.1 RSVP MTU D.1 Reservation Compatability
The spec says that the MTU for RSVP messages, which are sent hop
by hop, is determined by the MTU at each interface. There may be
rare instances in which this does not work very well, and in which
manual configuration would not help. The problem case is an
interface connected to a non-RSVP cloud in which some particular
link far away has a smaller MTU. This would affect only those
sessions that happened to use that link. Proper solution to this
case would require MTU discovery separately for each interface and
each session, which is a very large amount of machinery and some
overhead for a rare (?) case. The best approach seems to be to
rely on IP fragmentation and reassembly for this case.
D.2 Reservation Compatability
How strong is the requirement for compatability of reservations in How strong is the requirement for compatability of reservations in
different directions? For example, see Figure 11; should it be different directions? For example, see Figure 11; should it be
possible to have incompatible reservation styles on the two possible to have incompatible reservation styles on the two
interfaces? If R1 requests a WF reservation and R2 requests a FF interfaces? If R1 requests a WF reservation and R2 requests a FF
reservation, it is logically possible to make the corresponding reservation, it is logically possible to make the corresponding
reservations on the two different interfaces. The current reservations on the two different interfaces. The current
implementation does NOT allow this; instead, it prevents mixing of implementation does NOT allow this; instead, it prevents mixing of
incompatible styles in the same session on a node, even if they incompatible styles in the same session on a node, even if they
are on different interfaces. are on different interfaces.
D.3 Session Groups (Experimental) D.2 Session Groups (Experimental)
Section 1.2 explained that a distinct destination address, and Section 1.2 explained that a distinct destination address, and
therefore a distinct session, will be used for each of the therefore a distinct session, will be used for each of the
subflows in a hierarchically encoded flow. However, these subflows in a hierarchically encoded flow. However, these
separate sessions are logically related. For example it may be separate sessions are logically related. For example it may be
necessary to pass reservations for all subflows to Admission necessary to pass reservations for all subflows to Admission
Control at the same time (since it would be nonsense to admit high Control at the same time (since it would be nonsense to admit high
frequency components but reject the baseband component of the frequency components but reject the baseband component of the
session data). Such a logical grouping is indicated in RSVP by session data). Such a logical grouping is indicated in RSVP by
defining a "session group", an ordered set of sessions. defining a "session group", an ordered set of sessions.
skipping to change at page 90, line 36 skipping to change at page 88, line 21
refresh cycle and then perform Admission Control on the subset of refresh cycle and then perform Admission Control on the subset of
the session group that it has received. The rank values will the session group that it has received. The rank values will
identify which are missing. identify which are missing.
Note that routing different sessions of the session group Note that routing different sessions of the session group
differently will generally result in delays in establishing or differently will generally result in delays in establishing or
rejecting the desired QoS. A "bundling" facility could be added rejecting the desired QoS. A "bundling" facility could be added
to multicast routing, to force all sessions in a session group to to multicast routing, to force all sessions in a session group to
be routed along the same path. be routed along the same path.
D.3.1 Resv Messages D.2.1 Resv Messages
Add: Add:
[ <SESSION_GROUP> ] [ <SESSION_GROUP> ]
after the SESSION object. after the SESSION object.
D.3.2 SESSION_GROUP Class D.2.2 SESSION_GROUP Class
SESSION_GROUP class = 2. SESSION_GROUP class = 2.
o IPv4 SESSION_GROUP Object: Class = 2, C-Type = 1: o IPv4 SESSION_GROUP Object: Class = 2, C-Type = 1:
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 Reference DestAddress | | IPv4 Reference DestAddress |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Session_Group ID | Count | Rank | | Session_Group ID | Count | Rank |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 91, line 27 skipping to change at page 89, line 14
+ IP6 Reference DestAddress + + IP6 Reference DestAddress +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Session-Group ID | Count | Rank | | Session-Group ID | Count | Rank |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
The variables are defined in above. The variables are defined in above.
D.4 DF Style (Experimental) D.3 DF Style (Experimental)
In addition to the WF and FF styles defined in this specification, In addition to the WF and FF styles defined in this specification,
a Dynamic Filter (DF) style has also been proposed. The following a Dynamic Filter (DF) style has also been proposed. The following
describes this style and gives examples of its usage. At this describes this style and gives examples of its usage. At this
time, DF style is experimental. time, DF style is experimental.
D.4.1 Reservation Styles D.3.1 Reservation Styles
A Dynamic-Filter (DF) style reservation makes "distinct" A Dynamic-Filter (DF) style reservation makes "distinct"
reservations with "wildcard" scope, but it decouples reservations with "wildcard" scope, but it decouples
reservations from filters. reservations from filters.
o Each DF reservation request specifies a number D of o Each DF reservation request specifies a number D of
distinct reservations using the same specified flowspec. distinct reservations using the same specified flowspec.
These reservations are distributed with wildcard scope, These reservations are distributed with wildcard scope,
i.e., to all senders. i.e., to all senders.
skipping to change at page 92, line 34 skipping to change at page 90, line 20
The DF style allows a receiver to switch channels without The DF style allows a receiver to switch channels without
danger of an admission denial due to limited resources (unless danger of an admission denial due to limited resources (unless
a topology change reroutes traffic along a lower-capacity path a topology change reroutes traffic along a lower-capacity path
or new senders appear), once the initial reservations have been or new senders appear), once the initial reservations have been
made. This in turn implies that the DF style creates made. This in turn implies that the DF style creates
reservations that may not be in use at any given time. reservations that may not be in use at any given time.
The DF style is compatible with the FF style but not the WF or The DF style is compatible with the FF style but not the WF or
SE style. SE style.
D.4.2 Examples D.3.2 Examples
To give an example of the DF style, we use the following To give an example of the DF style, we use the following
notation: notation:
o DF Style o DF Style
DF( n, {r} ; ) or DF( n, {r} ; S1, S2, ...) DF( n, {r} ; ) or DF( n, {r} ; S1, S2, ...)
This message carries the count n of channels to be reserved, This message carries the count n of channels to be reserved,
each using common flowspec r. It also carries a list, perhaps each using common flowspec r. It also carries a list, perhaps
skipping to change at page 94, line 9 skipping to change at page 92, line 5
interface is given by the formula: interface is given by the formula:
N' = min( D1+D2+...Dn, Ns), N' = min( D1+D2+...Dn, Ns),
where Di is the D value (channel reservation count) in a RESV where Di is the D value (channel reservation count) in a RESV
from the ith next-hop node. from the ith next-hop node.
For a DF reservation request with a Dynamic Reservation Count = For a DF reservation request with a Dynamic Reservation Count =
C, RSVP should call TC_AddFlowspec C times. C, RSVP should call TC_AddFlowspec C times.
D.4.3 Resv Messages D.3.3 Resv Messages
Add the following sequence: Add the following sequence:
<flow descriptor list> ::= <flow descriptor list> ::=
<FLOWSPEC> <filter spec list> <FLOWSPEC> <filter spec list>
D.4.4 STYLE Class D.3.4 STYLE Class
o STYLE-DF object: Class = 8, C-Type = 2 o STYLE-DF object: Class = 8, C-Type = 2
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Style ID=4 | Attribute Vector 0...0101001b | | Style ID=4 | Attribute Vector 0...0101001b |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| ////// /////// | Dynamic Resv Count | | ////// /////// | Dynamic Resv Count |
+-------------+-------------+---------------------------+ +-------------+-------------+---------------------------+
Style ID Style ID
skipping to change at page 95, line 5 skipping to change at page 92, line 44
3 bits: Scope control (as before) 3 bits: Scope control (as before)
Dynamic Resv Count Dynamic Resv Count
The number of channels to be reserved for a Dynamic The number of channels to be reserved for a Dynamic
Filter style reservation. This integer value must Filter style reservation. This integer value must
not less than the number of FILTER_SPEC objects in not less than the number of FILTER_SPEC objects in
filter spec list. filter spec list.
D.4 Semantic Fragmentation
Long RSVP messages are fragmented into MTU-sized packets when they
are sent and reassembled upon receipt. This is normally expected
to be done at the RSVP layer, but may also occur at the IP layer
(when fragmentation occurs within a non-RSVP cloud). It is well
known that such "linear fragmentation" amplifies the effect of
packet loss. There is some concern that this could result in lost
RSVP state across congested paths through non-RSVP clouds.
One way to avoid this problem would be to use "semantic"
fragmentation, exploiting the structure of an RSVP message. With
semantic fragmentation, the state information that would have been
packed into one large message is sent in multiple packets, each of
which is constructed to be logically complete. Upon receipt, each
packet can be processed independently of the other packets, with
no explicit reassembly required.
Semantic fragmentation causes some redundancy of information; for
example, each packet of a RESV message must include SESSION,
NHOP/PHOP, TIME_VALUES, and STYLE objects. More importantly, the
rules for semantic fragmentation are complex, since a single RESV
message may contain two unbounded lists, and different styles
require different rules. Finally, the largest atomic message must
still fit into an MTU-sized packet, leading to a complex set of
limits on the sizes of individual objects. At present, most
objects are known to be small, but POLICY_DATA objects are
variable and may perhaps grow large.
The text of this section describes (some of) the rules for
semantic fragmentation. It has been removed from the main body of
the document, but is kept here for futur consideration.
D.4.1 Semantic Fragmentation of RESV Messages
An outgoing RESV message that is too large for the MTU of the
interface can be sent as multiple messages, as follows:
o For FF style, the flow descriptor list can be split as
required to fit; the rest of the message should be
replicated into each packet.
o For WF style, a SCOPE object containing an explicit list
of sender IP addresses can be split as required to fit;
the rest of the message should be replicated into each
packet.
o For SE style, the flow descriptor list can be split as
required to fit; the rest of the message should be
replicated into each packet.
If a single SE descriptor is too large to fit, its filter
spec list can similarly be split as required. However,
the subsets of a particular filter spec list must each be
enclosed in TAG objects carrying the same tag value, so
the receiver will be able to match each FILTER_SPEC object
to the appropriate shared reservation.
D.4.2 TAG class
TAG class = 15.
o TAG object: Class = 15, C-Type = 1
+-------------+-------------+-------------+-------------+
| Tag Value |
+-------------+-------------+-------------+-------------+
| |
// Tagged Sublist //
| |
+-------------+-------------+-------------+-------------+
Tag Value
The value of the tag being attached to the objects in
the Tagged Sublist. The tag value is unique for each
session and next/previous hop.
Tagged Sublist
A list of objects with the same class-num (but not
necessarily the same C-Type).
A TAG object encloses a list of one or more objects and
attaches a logical name or "tag" value to them. The tag
value is unique to the next/previous hop and the session
(specified by HOP and SESSION objects, respectively). The
enclosed object list is the "tagged sublist", and the
objects in it said to be "tagged" with the tag value.
Objects in a particular tagged sublist must all have the
same class-num.
Tagged objects with the same tag value are declared to be
logically related, i.e., to be members of some larger
logical set of objects. Note that the tagged sublist
implies no ordering; it defines only a set of objects.
The meaning of the logical relationship depends upon the
class-num of the tagged objects.
References References
[CSZ92] Clark, D., Shenker, S., and L. Zhang, "Supporting Real-Time [CSZ92] Clark, D., Shenker, S., and L. Zhang, "Supporting Real-Time
Applications in an Integrated Services Packet Network: Architecture Applications in an Integrated Services Packet Network: Architecture
and Mechanisms", Proc. SIGCOMM '92, Baltimore, MD, August 1992. and Mechanisms", Proc. SIGCOMM '92, Baltimore, MD, August 1992.
[ISInt93] Braden, R., Clark, D., and S. Shenker, "Integrated Services [ISInt93] Braden, R., Clark, D., and S. Shenker, "Integrated Services
in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and
PARC, June 1994. PARC, June 1994.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/