draft-ietf-rsvp-spec-11.txt   draft-ietf-rsvp-spec-12.txt 
Internet Draft R. Braden, Ed. Internet Draft R. Braden, Ed.
Expiration: September 1996 ISI Expiration: November 1996 ISI
File: draft-ietf-rsvp-spec-11.txt L. Zhang File: draft-ietf-rsvp-spec-12.txt L. Zhang
PARC PARC
S. Berson S. Berson
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
March 18, 1996 May 6, 1996
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 7 skipping to change at page 2, line 7
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.
Table of Contents Table of Contents
1. Introduction ........................................................4 1. Introduction ........................................................3
1.1 Data Flows ......................................................7 1.1 Data Flows ......................................................6
1.2 Reservation Model ...............................................8 1.2 Reservation Model ...............................................7
1.3 Reservation Styles ..............................................11 1.3 Reservation Styles ..............................................10
1.4 Examples of Styles ..............................................13 1.4 Examples of Styles ..............................................12
2. RSVP Protocol Mechanisms ............................................18 2. RSVP Protocol Mechanisms ............................................17
2.1 RSVP Messages ...................................................18 2.1 RSVP Messages ...................................................17
2.2 Port Usage ......................................................20 2.2 Port Usage ......................................................19
2.3 Merging Flowspecs ...............................................21 2.3 Merging Flowspecs ...............................................20
2.4 Soft State ......................................................22 2.4 Soft State ......................................................21
2.5 Teardown ........................................................24 2.5 Teardown ........................................................23
2.6 Errors ..........................................................25 2.6 Errors ..........................................................24
2.7 Confirmation ....................................................27 2.7 Confirmation ....................................................26
2.8 Policy and Security .............................................27 2.8 Policy and Security .............................................26
2.9 Non-RSVP Clouds .................................................28 2.9 Non-RSVP Clouds .................................................27
2.10 Host Model .....................................................29 2.10 Host Model .....................................................28
3. RSVP Functional Specification .......................................31 3. RSVP Functional Specification .......................................30
3.1 RSVP Message Formats ............................................31 3.1 RSVP Message Formats ............................................30
3.2 Sending RSVP Messages ...........................................44 3.2 Sending RSVP Messages ...........................................43
3.3 Avoiding RSVP Message Loops .....................................45 3.3 Avoiding RSVP Message Loops .....................................45
3.4 Blockade State ..................................................49 3.4 Blockade State ..................................................48
3.5 Local Repair ....................................................51 3.5 Local Repair ....................................................50
3.6 Time Parameters .................................................52 3.6 Time Parameters .................................................51
3.7 Traffic Policing and Non-Integrated Service Hops ................53 3.7 Traffic Policing and Non-Integrated Service Hops ................52
3.8 Multihomed Hosts ................................................54 3.8 Multihomed Hosts ................................................53
3.9 Future Compatibility ............................................56 3.9 Future Compatibility ............................................55
3.10 RSVP Interfaces ................................................58 3.10 RSVP Interfaces ................................................57
4. Message Processing Rules ............................................70 4. Message Processing Rules ............................................69
5. Acknowledgments .....................................................90 5. Acknowledgments .....................................................91
APPENDIX A. Object Definitions .........................................91 APPENDIX A. Object Definitions .........................................92
APPENDIX B. Error Codes and Values .....................................107 APPENDIX B. Error Codes and Values .....................................107
APPENDIX C. UDP Encapsulation ..........................................112 APPENDIX C. UDP Encapsulation ..........................................113
What's Changed
The most important changes in this document from the rsvp-spec-10
draft are:
o RSVP-layer fragmentation machinery was removed.
However, the common header was rearranged to allow message
length to be expanded beyond 16 bits in the future, should
that be necessary.
o A little more discussion of IPv6 in Introduction.
o Service preemption now triggers a ResvTear message.
o Traffic Control can return updated FLOWSPEC. (This forced a
significant change in the UPDATE TRAFFIC CONTROL processing
in section 4).
o The discussion at the end of Section 2.3 was rewritten.
o The Message Processing Rules were updated.
The most important changes in this document from the rsvp-spec-09
draft are:
o Multiple POLICY_DATA objects in any order are now allowed.
o The length field in the common header is now the total
message length [Section 3.1.1].
o The meaning of Message Id is refined and more completely
specified [Section 3.1.1].
o RSVP fragmentation is specifically called for, and IP
fragmentation disallowed [Section 3.1.1].
o The granularity of state timeouts is now specified [Section
3.6].
1. Introduction 1. Introduction
This document defines RSVP, a resource reservation setup protocol This document defines RSVP, a resource reservation setup protocol
designed for an integrated services Internet [RSVP93,ISInt93]. designed for an integrated services Internet [RSVP93,ISInt93].
The RSVP protocol is used by a host, on behalf of an application data The RSVP protocol is used by a host, on behalf of an application data
stream, to request a specific quality of service (QoS) from the stream, to request a specific quality of service (QoS) from the
network. The RSVP protocol is also used by routers to deliver QoS network. The RSVP protocol is also used by routers to deliver QoS
requests to all nodes along the path(s) of the data stream and to requests to all nodes along the path(s) of the data stream and to
skipping to change at page 5, line 7 skipping to change at page 4, line 7
RSVP daemon consults the local routing database(s) to obtain routes. RSVP daemon consults the local routing database(s) to obtain routes.
In the multicast case, for example, a host sends IGMP messages to In the multicast case, for example, a host sends IGMP messages to
join a multicast group and then sends RSVP messages to reserve join a multicast group and then sends RSVP messages to reserve
resources along the delivery path(s) of that group. Routing resources along the delivery path(s) of that group. Routing
protocols determine where packets get forwarded; RSVP is only protocols determine where packets get forwarded; RSVP is only
concerned with the QoS of those packets that are forwarded in concerned with the QoS of those packets that are forwarded in
accordance with routing. accordance with routing.
HOST ROUTER HOST ROUTER
_________________________ RSVP _____________________________ HOST ROUTER
| | .--------------. |
_____________________________ ____________________________
| | .-----------. |
| _______ ______ | / | ________ . ______ | | _______ ______ | / | ________ . ______ |
| | | | | | / || | . | | | RSVP | | | | | | RSVP || | . | | | RSVP
| |Applic-| | RSVP <----/ ||Routing | -> RSVP <----------> | |Applic-| | RSVP <---------/ ||Routing | -> RSVP <---------->
| | App <----->daemon| | ||Protocol| |daemon| _____ | | | ation<--->daemon| _____ | ||Protocol| |daemon| _____ |
| | | | | | || daemon <----> >|Polcy|| | |_._____| | >|Polcy|| || daemon <---> >|Polcy||
| |_______| |___.__| | ||_ ._____| |__.__.||Cntrl|| | | |__.__.||Cntrl|| ||__._____| |__.__.||Cntrl||
| | | | | | | .|_____|| | |data | .|_____|| | | | .|_____||
|===|===============|=====| |===|=============|====.======| |===|============|====.======| |===|============|====.======|
| data .........| | | | ...........| .____ | | | ..........| .____ | | | ..........| .____ |
| | ____V_ ____V____ | | _V__V_ _____V___ |Admis|| | _V__V_ ____V___ |Admis|| | _V__V_ ____V___ |Admis||
| | |Class-| | || data | |Class-| | ||Cntrl|| | |Class-| | ||Cntrl|| | |Class-| | ||Cntrl||
| |=> ifier|=> Packet ============> ifier|==> Packet ||_____|| data | | ifier|==> Packet ||_____|| .===> ifier|==> Packet ||_____||
| |______| |Scheduler|| | |______| |Scheduler|===========> | |______| |Schedulr|===========/ | |______| |Schedulr|===========>
| |_________|| | |_________| | | |________| | data | |________| | data
|_________________________| |_____________________________| |____________________________| |____________________________|
Figure 1: RSVP in Hosts and Routers Figure 1: RSVP in Hosts and Routers
Each node that is capable of resource reservation passes incoming Each node that is capable of resource reservation passes incoming
data packets through a "packet classifier", which determines the data packets through a "packet classifier", which determines the
route and the QoS class for each packet. On outgoing interface, a route and the QoS class for each packet. On outgoing interface, a
"packet scheduler" then makes forwarding decisions for every packet, "packet scheduler" then makes forwarding decisions for every packet,
to achieve the promised QoS on the particular link-layer medium used to achieve the promised QoS on the particular link-layer medium used
by that interface. by that interface.
skipping to change at page 7, line 32 skipping to change at page 6, line 35
while Section 4 presents explicit message processing rules. Appendix while Section 4 presents explicit message processing rules. Appendix
A defines the variable-length typed data objects used in the RSVP A defines the variable-length typed data objects used in the RSVP
protocol. Appendix B defines error codes and values. Appendix C protocol. Appendix B defines error codes and values. Appendix C
defines an extension for UDP encapsulation of RSVP messages. defines an extension for UDP encapsulation of RSVP messages.
1.1 Data Flows 1.1 Data Flows
RSVP defines a "session" to be a data flow with a particular RSVP defines a "session" to be a data flow with a particular
destination and transport-layer protocol. The destination of a destination and transport-layer protocol. The destination of a
session is defined by DestAddress, the IP destination address of session is defined by DestAddress, the IP destination address of
the data packets, and perhaps by DstPort, a "generalized the data packets, by the IP protocol ID, and perhaps by DstPort, a
destination port", i.e., some further demultiplexing point in the "generalized destination port", i.e., some further demultiplexing
transport or application protocol layer. RSVP treats each session point in the transport or application protocol layer. RSVP treats
independently, and this document often omits the implied each session independently, and this document often omits the
qualification "for the same session". implied qualification "for the same session".
DestAddress is a group address for multicast delivery or the DestAddress is a group address for multicast delivery or the
unicast address of a single receiver. DstPort could be defined by unicast address of a single receiver. DstPort could be defined by
a UDP/TCP destination port field, by an equivalent field in a UDP/TCP destination port field, by an equivalent field in
another transport protocol, or by some application-specific another transport protocol, or by some application-specific
information. Although the RSVP protocol is designed to be easily information. Although the RSVP protocol is designed to be easily
extensible for greater generality, the basic protocol documented extensible for greater generality, the basic protocol documented
here supports only UDP/TCP ports as generalized ports. Note that here supports only UDP/TCP ports as generalized ports. Note that
it is not strictly necessary to include DstPort in the session it is not strictly necessary to include DstPort in the session
definition when DestAddress is multicast, since different sessions definition when DestAddress is multicast, since different sessions
skipping to change at page 11, line 42 skipping to change at page 10, line 44
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 following styles currently defined (see Figure 3): The following styles are currently defined (see Figure 3):
o Wildcard-Filter (WF) Style o Wildcard-Filter (WF) Style
The WF style implies the options: "shared" reservation and The WF style implies the options: "shared" reservation and
"wildcard" sender selection. Thus, a WF-style reservation "wildcard" sender selection. Thus, a WF-style reservation
creates a single reservation shared by flows from all creates a single reservation shared by flows from all
upstream senders. This reservation may be thought of as a upstream senders. This reservation may be thought of as a
shared "pipe", whose "size" is the largest of the resource shared "pipe", whose "size" is the largest of the resource
requests from all receivers, independent of the number of requests from all receivers, independent of the number of
senders using it. A WF-style reservation is propagated senders using it. A WF-style reservation is propagated
skipping to change at page 12, line 44 skipping to change at page 11, line 46
multiple elementary FF-style reservations to be requested at multiple elementary FF-style reservations to be requested at
the same time, using a list of flow descriptors: the same time, using a list of flow descriptors:
FF( S1{Q1}, S2{Q2}, ...) FF( S1{Q1}, S2{Q2}, ...)
The total reservation on a link for a given session is the The total reservation on a link for a given session is the
`sum' of Q1, Q2, ... for all requested senders. `sum' of Q1, Q2, ... for all requested senders.
o Shared Explicit (SE) Style o Shared Explicit (SE) Style
The SE style implies the options: "shared" reservation and " The SE style implies the options: "shared" reservation and
explicit" sender selection. Thus, an SE-style reservation "explicit" sender selection. Thus, an SE-style reservation
creates a single reservation shared by selected upstream creates a single reservation shared by selected upstream
senders. Unlike the WF style, the SE style allows a receiver senders. Unlike the WF style, the SE style allows a receiver
to explicitly specify the set of senders to be included. to explicitly specify the set of senders to be included.
We can represent an SE reservation request containing a We can represent an SE reservation request containing a
flowspec Q and a list of senders S1, S2, ... by: flowspec Q and a list of senders S1, S2, ... by:
SE( (S1,S2,...){Q} ) SE( (S1,S2,...){Q} )
Shared reservations, created by WF and SE styles, are appropriate Shared reservations, created by WF and SE styles, are appropriate
skipping to change at page 14, line 11 skipping to change at page 13, line 14
two outgoing interfaces, labeled (c) and (d), through which data two outgoing interfaces, labeled (c) and (d), through which data
will be forwarded. This topology will be assumed in the examples will be forwarded. This topology will be assumed in the examples
that follow. There are three upstream senders; packets from that follow. There are three upstream senders; packets from
sender S1 (S2 and S3) arrive through previous hop (a) ((b), sender S1 (S2 and S3) arrive through previous hop (a) ((b),
respectively). There are also three downstream receivers; packets respectively). There are also three downstream receivers; packets
bound for R1 (R2 and R3) are routed via outgoing interface (c) bound for R1 (R2 and R3) are routed via outgoing interface (c)
((d), respectively). We furthermore assume that outgoing ((d), respectively). We furthermore assume that outgoing
interface (d) is connected to a broadcast LAN, and that R2 and R3 interface (d) is connected to a broadcast LAN, and that R2 and R3
are reached via different next hop routers (not shown). are reached via different next hop routers (not shown).
We must also specify the multicast routes within the nod of Figure We must also specify the multicast routes within the node of
4. Assume first that data packets from each Si shown in Figure 4 Figure 4. Assume first that data packets from each Si shown in
is routed to both outgoing interfaces. Under this assumption, Figure 4 are routed to both outgoing interfaces. Under this
Figures 5, 6, and 7 illustrate Wildcard-Filter, Fixed-Filter, and assumption, Figures 5, 6, and 7 illustrate Wildcard-Filter,
Shared-Explicit reservations, respectively. Fixed-Filter, and Shared-Explicit reservations, respectively.
________________ ________________
(a)| | (c) (a)| | (c)
( S1 ) ---------->| |----------> ( R1 ) ( S1 ) ---------->| |----------> ( R1 )
| Router | | | Router | |
(b)| | (d) |---> ( R2 ) (b)| | (d) |---> ( R2 )
( S2,S3 ) ------->| |------| ( S2,S3 ) ------->| |------|
|________________| |---> ( R3 ) |________________| |---> ( R3 )
| |
Figure 4: Router Configuration Figure 4: Router Configuration
skipping to change at page 17, line 26 skipping to change at page 16, line 26
| |
Send | Reserve Receive Send | Reserve Receive
| |
| _______ | _______
WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} ) WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} )
| |_______| | |_______|
| |
-----------------------|---------------------------------------- -----------------------|----------------------------------------
| _______ | _______
WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} ) WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} )
| |_______| <- WF( * {2B} | |_______| <- WF( * {2B} )
Figure 8: WF Reservation Example -- Partial Routing Figure 8: WF Reservation Example -- Partial Routing
2. RSVP Protocol Mechanisms 2. RSVP Protocol Mechanisms
2.1 RSVP Messages 2.1 RSVP Messages
Previous Incoming Outgoing Next Previous Incoming Outgoing Next
Hops Interfaces Interfaces Hops Hops Interfaces Interfaces Hops
skipping to change at page 22, line 18 skipping to change at page 21, line 18
supplied in Path messages from different previous hops (e.g., supplied in Path messages from different previous hops (e.g.,
some or all of A, B, and B' in Figure 9). some or all of A, B, and B' in Figure 9).
3. RSVP passes these two results, (Re, Resv_Te) and Path_Te, to 3. RSVP passes these two results, (Re, Resv_Te) and Path_Te, to
traffic control. Traffic control will compute the "minimum" traffic control. Traffic control will compute the "minimum"
of Path_Te and Resv_Te in an appropriate, perhaps service- of Path_Te and Resv_Te in an appropriate, perhaps service-
dependent, manner. dependent, manner.
The definition and implementation of the rules for comparing The definition and implementation of the rules for comparing
flowspecs, calculating LUBs and GLBs, and summing Tspecs are flowspecs, calculating LUBs and GLBs, and summing Tspecs are
outside the definition of RSVP. Section 3.10.4 shows generic outside the definition of RSVP. Section 3.10.5 shows generic
calls that an RSVP daemon could use for these functions. calls that an RSVP daemon could use for these functions.
2.4 Soft State 2.4 Soft State
RSVP takes a "soft state" approach to managing the reservation RSVP takes a "soft state" approach to managing the reservation
state in routers and hosts. RSVP soft state is created and state in routers and hosts. RSVP soft state is created and
periodically refreshed by Path and Resv messages. The state is periodically refreshed by Path and Resv messages. The state is
deleted if no matching refresh messages arrive before the deleted if no matching refresh messages arrive before the
expiration of a "cleanup timeout" interval. State may also be expiration of a "cleanup timeout" interval. State may also be
deleted by an explicit "teardown" message, described in the next deleted by an explicit "teardown" message, described in the next
skipping to change at page 22, line 46 skipping to change at page 21, line 46
the state on the now-unused segment of the route will time out. the state on the now-unused segment of the route will time out.
Thus, whether a message is "new" or a "refresh" is determined Thus, whether a message is "new" or a "refresh" is determined
separately at each node, depending upon the existence of state at separately at each node, depending upon the existence of state at
that node. that node.
RSVP sends its messages as IP datagrams with no reliability RSVP sends its messages as IP datagrams with no reliability
enhancement. Periodic transmission of refresh messages by hosts enhancement. Periodic transmission of refresh messages by hosts
and routers is expected to handle the occasional loss of an RSVP and routers is expected to handle the occasional loss of an RSVP
message. If the effective cleanup timeout is set to K times the message. If the effective cleanup timeout is set to K times the
refresh timeout period, then RSVP can tolerate K-1 successive RSVP refresh timeout period, then RSVP can tolerate K-1 successive RSVP
packet losses without falsely deleting state. the network traffic packet losses without falsely deleting state. The network traffic
control mechanism should be statically configured to grant some control mechanism should be statically configured to grant some
minimal bandwidth for RSVP messages to protect them from minimal bandwidth for RSVP messages to protect them from
congestion losses. congestion losses.
The state maintained by RSVP is dynamic; to change the set of The state maintained by RSVP is dynamic; to change the set of
senders Si or to change any QoS request, a host simply starts senders Si or to change any QoS request, a host simply starts
sending revised Path and/or Resv messages. The result will be an sending revised Path and/or Resv messages. The result will be an
appropriate adjustment in the RSVP state in all nodes along the appropriate adjustment in the RSVP state in all nodes along the
path; unused state will time out if it is not explicitly torn path; unused state will time out if it is not explicitly torn
down. down.
skipping to change at page 23, line 36 skipping to change at page 22, line 36
router with one sender and one receiver on each interface (and router with one sender and one receiver on each interface (and
assumes one next/previous hop per interface). Interfaces (a) and assumes one next/previous hop per interface). Interfaces (a) and
(c) serve as both outgoing and incoming interfaces for this (c) serve as both outgoing and incoming interfaces for this
session. Both receivers are making wildcard-style reservations, session. Both receivers are making wildcard-style reservations,
in which the Resv messages are forwarded to all previous hops for in which the Resv messages are forwarded to all previous hops for
senders in the group, with the exception of the next hop from senders in the group, with the exception of the next hop from
which they came. The result is independent reservations in the which they came. The result is independent reservations in the
two directions. two directions.
There is an additional rule governing the forwarding of Resv There is an additional rule governing the forwarding of Resv
messages: state from RESV messages received from outgoing messages: state from Resv messages received from outgoing
interface Io should be forwarded to incoming interface Ii only if interface Io should be forwarded to incoming interface Ii only if
Path messages from Ii are forwarded to Io. Path messages from Ii are forwarded to Io.
________________ ________________
a | | c a | | c
( R1, S1 ) <----->| Router |<-----> ( R2, S2 ) ( R1, S1 ) <----->| Router |<-----> ( R2, S2 )
|________________| |________________|
Send | Receive Send | Receive
| |
skipping to change at page 24, line 49 skipping to change at page 23, line 49
(ResvTear) message may be conceptualized as a reversed-sense Path (ResvTear) message may be conceptualized as a reversed-sense Path
message (Resv message, respectively). message (Resv message, respectively).
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 or service preemption. Once initiated, a teardown state timeout or service preemption. Once initiated, a teardown
request must be forwarded hop-by-hop without delay. A teardown request must be forwarded hop-by-hop without delay. A teardown
message deletes the specified state in the node where it is message deletes the specified state in the node where it is
received. As always, this state change will be propagated received. As always, this state change will be propagated
immediately to the next node, but only if there will be a net immediately to the next node, but only if there will be a net
change after merging. As a result, an ResvTear message will prune change after merging. As a result, a ResvTear message will prune
the reservation state back (only) as far as possible. the reservation state back (only) as far as possible.
Like all other RSVP messages, teardown requests are not delivered Like all other RSVP messages, teardown requests are not delivered
reliably. The loss of a teardown request message will not cause a reliably. The loss of a teardown request message will not cause a
protocol failure because the unused state will eventually time out protocol failure because the unused state will eventually time out
even though it is not explicitly deleted. If a teardown message even though it is not explicitly deleted. If a teardown message
is lost, the router that failed to receive that message will time is lost, the router that failed to receive that message will time
out its state and initiate a new teardown message beyond the loss out its state and initiate a new teardown message beyond the loss
point. Assuming that RSVP message loss probability is small, the point. Assuming that RSVP message loss probability is small, the
longest time to delete state will seldom exceed one refresh longest time to delete state will seldom exceed one refresh
skipping to change at page 25, line 28 skipping to change at page 24, line 28
filter spec. For example, refer to Figure 7. Receiver R1 could filter spec. For example, refer to Figure 7. Receiver R1 could
send a ResvTear message for sender S2 only (or for any subset of send a ResvTear message for sender S2 only (or for any subset of
the filter spec list), leaving S1 in place. the filter spec list), leaving S1 in place.
A ResvTear message specifies the style and filters; any flowspec A ResvTear message specifies the style and filters; any flowspec
is ignored. Whatever flowspec is in place will be removed if all is ignored. Whatever flowspec is in place will be removed if all
its filter specs are torn down. its filter specs are torn down.
2.6 Errors 2.6 Errors
There are two RSVP error messages, ResvErr and PathErr. PERR There are two RSVP error messages, ResvErr and PathErr. PathErr
messages are very simple; they are simply sent upstream to the messages are very simple; they are simply sent upstream to the
sender that created the error, and they do not change path state sender that created the error, and they do not change path state
in the nodes though which they pass. There are only a few in the nodes though which they pass. There are only a few
possible causes of path errors. possible causes of path errors.
However, there are a number of ways for a syntactically valid However, there are a number of ways for a syntactically valid
reservation request to fail at some node along the path. A node reservation request to fail at some node along the path. A node
may also decide to preempt an established reservation. The may also decide to preempt an established reservation. The
handling of ResvErr messages is somewhat complex (Section 3.4). handling of ResvErr messages is somewhat complex (Section 3.4).
Since a request that fails may be the result of merging a number Since a request that fails may be the result of merging a number
skipping to change at page 31, line 10 skipping to change at page 30, line 10
A specific application program interface (API) for RSVP is not A specific application program interface (API) for RSVP is not
defined in this protocol spec, as it may be host system dependent. defined in this protocol spec, as it may be host system dependent.
However, Section 3.10.1 discusses the general requirements and However, Section 3.10.1 discusses the general requirements and
outlines a generic interface. outlines a generic interface.
3. RSVP Functional Specification 3. RSVP Functional Specification
3.1 RSVP Message Formats 3.1 RSVP Message Formats
An RSVP message consists of a common header, followed by a body An RSVP message consists of a common header, followed by a body
consisting of a variable number of variable-length, typed " consisting of a variable number of variable-length, typed
objects". The following subsections define the formats of the "objects". The following subsections define the formats of the
common header, the standard object header, and each of the RSVP common header, the standard object header, and each of the RSVP
message types. message types.
For each RSVP message type, there is a set of rules for the For each RSVP message type, there is a set of rules for the
permissible choice of object types. These rules are specified permissible choice of object types. These rules are specified
using Backus-Naur Form (BNF) augmented with square brackets using Backus-Naur Form (BNF) augmented with square brackets
surrounding optional sub-sequences. The BNF implies an order for surrounding optional sub-sequences. The BNF implies an order for
the objects in a message. However, in many (but not all) cases, the objects in a message. However, in many (but not all) cases,
object order makes no logical difference. An implementation object order makes no logical difference. An implementation
should create messages with the objects in the order shown here, should create messages with the objects in the order shown here,
skipping to change at page 33, line 41 skipping to change at page 32, line 41
Carries the IP address of the RSVP-capable node that Carries the IP address of the RSVP-capable node that
sent this message and a logical outgoing interface sent this message and a logical outgoing interface
handle (LIH; see Section 3.2). This document refers handle (LIH; see Section 3.2). This document refers
to a RSVP_HOP object as a PHOP ("previous hop") to a RSVP_HOP object as a PHOP ("previous hop")
object for downstream messages or as a NHOP (" next object for downstream messages or as a NHOP (" next
hop") object for upstream messages. hop") object for upstream messages.
TIME_VALUES TIME_VALUES
Contains the value for the refresh period R used by Contains the value for the refresh period R used by
the creator of the message; see 3.6. Required in the creator of the message; see Section 3.6.
every Path and Resv message. Required in every Path and Resv message.
STYLE STYLE
Defines the reservation style plus style-specific Defines the reservation style plus style-specific
information that is not in FLOWSPEC or FILTER_SPEC information that is not in FLOWSPEC or FILTER_SPEC
objects. Required in every Resv message. objects. Required in every Resv message.
FLOWSPEC FLOWSPEC
Defines a desired QoS, in a Resv message. Defines a desired QoS, in a Resv message.
FILTER_SPEC FILTER_SPEC
Defines a subset of session data packets that should Defines a subset of session data packets that should
receive the desired QoS (specified by an FLOWSPEC receive the desired QoS (specified by a FLOWSPEC
object), in a Resv message. object), in a Resv message.
SENDER_TEMPLATE SENDER_TEMPLATE
Contains a sender IP address and perhaps some Contains a sender IP address and perhaps some
additional demultiplexing information to identify a additional demultiplexing information to identify a
sender. Required in a Path message. sender. Required in a Path message.
SENDER_TSPEC SENDER_TSPEC
skipping to change at page 34, line 39 skipping to change at page 33, line 39
Specifies an error in a PathErr, ResvErr, or a Specifies an error in a PathErr, ResvErr, or a
confirmation in a ResvConf message. confirmation in a ResvConf message.
POLICY_DATA POLICY_DATA
Carries information that will allow a local policy Carries information that will allow a local policy
module to decide whether an associated reservation is module to decide whether an associated reservation is
administratively permitted. May appear in Path, administratively permitted. May appear in Path,
Resv, PathErr, or ResvErr message. Resv, PathErr, or ResvErr message.
The use of POLICY_DATA objects is not fully specified
at this time; a future document will fill this gap.
INTEGRITY INTEGRITY
Carries cryptographic data to authenticate the Carries cryptographic data to authenticate the
originating node and to verify the contents of this originating node and to verify the contents of this
RSVP message. The use of the INTEGRITY object is RSVP message. The use of the INTEGRITY object is
described in [Baker96]. described in [Baker96].
SCOPE SCOPE
Carries an explicit list of sender hosts towards Carries an explicit list of sender hosts towards
skipping to change at page 35, line 26 skipping to change at page 34, line 29
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 may be used together as a 16-bit number Num and C-Type fields may be used together as a 16-bit number
to define a unique type for each object. to define a unique type for each object.
The high-order two bits of the Class-Num is used to determine The high-order two bits of the Class-Num is used to determine
what action a node should take if it does not recognize the what action a node should take if it does not recognize the
Class-Num of an object; see Section 3.9. Class-Num of an object; see Section 3.9.
3.1.3 Path Messages 3.1.3 Path Messages
Each sender host periodically sends a Path message containing a Each sender host periodically sends a Path message for each
description of each data stream it originates. The Path data stream it originates. The Path message travels from a
message travels from a sender to receiver(s) along the same sender to receiver(s) along the same path(s) used by the data
path(s) used by the data packets. The IP source address of a packets. The IP source address of a Path message is an address
Path message is an address of the sender it describes, while of the sender it describes, while the destination address is
the destination address is the DestAddress for the session. the DestAddress for the session. These addresses assure that
These addresses assure that the message will be correctly the message will be correctly routed through a non-RSVP cloud.
routed through a non-RSVP cloud.
The format of a Path message is as follows: The format of a Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ] <Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
skipping to change at page 36, line 24 skipping to change at page 35, line 25
from this sender, while the SENDER_TSPEC object specifies the from this sender, while the SENDER_TSPEC object specifies the
traffic characteristics of the flow. Optionally, there may be traffic characteristics of the flow. Optionally, there may be
an ADSPEC object carrying advertising (OPWA) data. an ADSPEC object carrying advertising (OPWA) data.
Each RSVP-capable node along the path(s) captures a Path Each RSVP-capable node along the path(s) captures a Path
message and processes it to create path state for the sender message and processes it to create path state for the sender
defined by the SENDER_TEMPLATE and SESSION objects. Any defined by the SENDER_TEMPLATE and SESSION objects. Any
POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are also saved in POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are also saved in
the path state. If an error is encountered while processing a the path state. If an error is encountered while processing a
Path message, a PathErr message is sent to the originating Path message, a PathErr message is sent to the originating
sender of the Path message. PATH messages must satisfy the sender of the Path message. Path messages must satisfy the
rules on SrcPort and DstPort in Section 2.2. rules on SrcPort and DstPort in Section 2.2.
Periodically, the RSVP daemon at a node scans the path state to Periodically, the RSVP daemon at a node scans the path state to
create new Path messages to forward towards the receiver(s). create new Path messages to forward towards the receiver(s).
Each message contains a sender descriptor defining one sender, Each message contains a sender descriptor defining one sender,
and carries the original sender's IP address as its IP source and carries the original sender's IP address as its IP source
address. Path messages eventually reach the applications on address. Path messages eventually reach the applications on
all receivers; however, they are not looped back to a receiver all receivers; however, they are not looped back to a receiver
running in the same application process as the sender. running in the same application process as the sender.
The RSVP daemon forwards Path messages, and replicates them as The RSVP daemon forwards Path messages, and replicates them as
required, using routing information it obtains from the required, using routing information it obtains from the
appropriate uni-/multicast routing daemon. The route depends appropriate uni-/multicast routing daemon. The route depends
upon the session DestAddress, and for some routing protocols upon the session DestAddress, and for some routing protocols
also upon the source (sender's IP) address. The routing also upon the source (sender's IP) address. The routing
information generally includes the list of none or more information generally includes the list of zero or more
outgoing interfaces to which the Path message to be forwarded. outgoing interfaces to which the Path message is to be
Because each outgoing interface has a different IP address, the forwarded. Because each outgoing interface has a different IP
Path messages sent out different interfaces contain different address, the Path messages sent out different interfaces
PHOP addresses. In addition, ADSPEC objects carried in Path contain different PHOP addresses. In addition, ADSPEC objects
messages will also generally differ for different outgoing carried in Path messages will also generally differ for
interfaces. different outgoing interfaces.
Some IP multicast routing protocols (e.g., DVMRP, PIM, and Some IP multicast routing protocols (e.g., DVMRP, PIM, and
MOSPF) also keep track of the expected incoming interface for MOSPF) also keep track of the expected incoming interface for
each source host to a multicast group. Whenever this each source host to a multicast group. Whenever this
information is available, RSVP should check the incoming information is available, RSVP should check the incoming
interface of each Path message and do special handling of those interface of each Path message and do special handling of those
messages Path messages that have arrived on the wrong messages Path messages that have arrived on the wrong
interface; see Section 3.8. interface; see Section 3.8.
3.1.4 Resv Messages 3.1.4 Resv Messages
skipping to change at page 37, line 35 skipping to change at page 36, line 36
[ <RESV_CONFIRM> ] [ <SCOPE> ] [ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list> <STYLE> <flow descriptor list>
<flow descriptor list> ::= <flow descriptor> | <flow descriptor list> ::= <flow descriptor> |
<flow descriptor list> <flow descriptor> <flow descriptor list> <flow descriptor>
The STYLE object followed by the flow descriptor list must If the INTEGRITY object is present, it must immediately follow
occur at the end of the message, and objects within the flow the common header. The STYLE object followed by the flow
descriptor list must follow the BNF given below. There are no descriptor list must occur at the end of the message, and
other requirements on transmission order, although the above objects within the flow descriptor list must follow the BNF
order is recommended. given below. There are no other requirements on transmission
order, although the above order is recommended.
The NHOP (i.e., the RSVP_HOP) object contains the IP address of The NHOP (i.e., the RSVP_HOP) object contains the IP address of
the interface through which the Resv message was sent and the the interface through which the Resv message was sent and the
LIH for the logical interface on which the reservation is LIH for the logical interface on which the reservation is
required. required.
The appearance of a RESV_CONFIRM object signals a request for a The appearance of a RESV_CONFIRM object signals a request for a
reservation confirmation and carries the IP address of the reservation confirmation and carries the IP address of the
receiver to which the ResvConf should be sent. Any number of receiver to which the ResvConf should be sent. Any number of
POLICY_DATA objects may appear. POLICY_DATA objects may appear.
skipping to change at page 38, line 47 skipping to change at page 38, line 4
<flow descriptor list> ::= <SE flow descriptor> <flow descriptor list> ::= <SE flow descriptor>
<SE flow descriptor> ::= <SE flow descriptor> ::=
<FLOWSPEC> <filter spec list> <FLOWSPEC> <filter spec list>
<filter spec list> ::= <FILTER_SPEC> <filter spec list> ::= <FILTER_SPEC>
| <filter spec list> <FILTER_SPEC> | <filter spec list> <FILTER_SPEC>
The reservation scope, i.e., the set of senders towards which a The reservation scope, i.e., the set of senders towards which a
particular reservation is to be forwarded (after merging), is particular reservation is to be forwarded (after merging), is
determined as follows: determined as follows:
o Explicit sender selection o Explicit sender selection
Select a particular sender by matching each FILTER_SPEC The reservation is forwarded to all senders whose
object against the path state created from SENDER_TEMPLATE SENDER_TEMPLATE objects recorded in the path state match a
objects. This match must follow the rules of Section 2.2. FILTER_SPEC object in the reservation. This match must
follow the rules of Section 2.2.
o Wildcard sender selection o Wildcard sender selection
All senders that route to the given outgoing interface A request with wildcard sender selection will match all
match this request. A SCOPE object, if present, contains senders that route to the given outgoing interface.
an explicit list of sender IP addresses. If there is no
SCOPE object, the scope is determined by the relevant set
of senders in the path state.
Whenever a Resv message with wildcard sender selection is Whenever a Resv message with wildcard sender selection is
forwarded to more than one previous hop, a SCOPE object forwarded to more than one previous hop, a SCOPE object
must be included in the message. See Section 3.3 below. must be included in the message (see Section 3.3 below);
in this case, the scope for forwarding the reservation is
constrained to just the sender IP addresses explicitly
listed in the SCOPE object.
3.1.5 Teardown Messages 3.1.5 Teardown Messages
There are two types of RSVP teardown message, PathTear and There are two types of RSVP teardown message, PathTear and
ResvTear. ResvTear.
o A PathTear message deletes path state (which in turn o A PathTear message deletes path state (which in turn
deletes any reservation state for that sender), traveling deletes any reservation state for that sender), traveling
towards all receivers that are downstream from the towards all receivers that are downstream from the
initiating node. A PathTear message must be routed initiating node. A PathTear message must be routed
exactly like the corresponding Path message. Therefore, exactly like the corresponding Path message. Therefore,
its IP destination address must be the session its IP destination address must be the session
DestAddress, and its IP source address must be the address DestAddress, and its IP source address must be the address
of the sender being torn down. of the sender being torn down.
o A ResvTear message deletes reservation state, travelling o A ResvTear message deletes reservation state, travelling
towards all matching senders upstream from the initiating towards all matching senders upstream from the initiating
node. A ResvTear message must be routed link the node. A ResvTear message must be routed like the
corresponding Resv message, and its IP destination address corresponding Resv message, and its IP destination address
will be the unicast address of a previous hop. An will be the unicast address of a previous hop. A ResvTear
ResvTear message will be initiated by a receiver, by a message will be initiated by a receiver, by a node in
node in which reservation state has timed out, or by a which reservation state has timed out, or by a node in
node in which a reservation has been preempted. which a reservation has been preempted.
<PathTear Message> ::= <Common Header> [ <INTEGRITY> ] <PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<sender descriptor> <sender descriptor>
<sender descriptor> ::= (see earlier definition) <sender descriptor> ::= (see earlier definition)
<ResvTear Message> ::= <Common Header> [<INTEGRITY>] <ResvTear Message> ::= <Common Header> [<INTEGRITY>]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
[ <SCOPE> ] <STYLE> [ <SCOPE> ] <STYLE>
skipping to change at page 40, line 20 skipping to change at page 39, line 22
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
[ <SCOPE> ] <STYLE> [ <SCOPE> ] <STYLE>
<flow descriptor list> <flow descriptor list>
<flow descriptor list> ::= (see earlier definition) <flow descriptor list> ::= (see earlier definition)
FLOWSPEC objects in the flow descriptor list of a ResvTear FLOWSPEC objects in the flow descriptor list of a ResvTear
message will be ignored and may be omitted. The order message will be ignored and may be omitted. The order
requirements for sender descriptor, STYLE object, and flow requirements for INTEGRITY object, sender descriptor, STYLE
descriptor list are as given earlier for Path and Resv object, and flow descriptor list are as given earlier for Path
messages. A ResvTear message may specify any subset of the and Resv messages. A ResvTear message may specify any subset
filter specs in FF- or SE-style reservation state. of the filter specs in FF- or SE-style reservation state.
Note that, unless it is accidentally dropped along the way, a Note that, unless it is accidentally dropped along the way, a
PTEAR message will reach all receivers downstream from the PathTear message will reach all receivers downstream from the
originating node. On the other hand, a ResvTear message will originating node. On the other hand, a ResvTear message will
cease to be forwarded at the node where merging would have cease to be forwarded at the node where merging would have
suppressed forwarding of the corresponding Resv message. In suppressed forwarding of the corresponding Resv message.
each node N along the way, if the ResvTear message causes the Depending upon the resulting state change in a node, receipt of
removal of all state for this session, N will create a new a ResvTear message may cause a ResvTear message to be
teardown message to be propagated further upstream; otherwise, forwarded, a modified Resv message to be forwarded, or no
the ResvTear message may result in the immediate forwarding of message to be forwarded.
a modified Resv refresh message.
For example, consider the FF-style reservations in Figure 6. These three cases can be illustrated in the case of the FF-
If receiver R3 send a ResvTear message for its reservation style reservations shown in Figure 6.
S1{B}, there is no change in the effective reservation S1{3B}
on (d), and no message will be forwarded. If receiver R2 sends o If receiver R2 sends a ResvTear message for its
a ResvTear message for its reservation S3{B}, the corresponding reservation S3{B}, the corresponding reservation is
reservation will be removed from (d) and an ResvTear for S3{B} removed from interface (d) and an ResvTear for S3{B} is
will be forwarded out interface (b). Finally, if receiver R1 forwarded out (b).
sends a ResvTear for its reservation S1{4B}, the result will be
to remove the reservation from interface (c), and to forward o If receiver R1 sends a ResvTear for its reservation
immediately a Resv message FF( S1{3B} ) out interface (a). S1{4B}, the corresponding reservation is removed from
interface (c) and a modified Resv message FF( S1{3B} ) is
immediately forwarded out (a).
o If receiver R3 sends a ResvTear message for S1{B}, there
is no change in the effective reservation S1{3B} on (d)
and no message is forwarded.
Deletion of path state as the result of a PathTear message or a Deletion of path state as the result of a PathTear message or a
timeout must cause any adjustments in related reservation state timeout must cause any adjustments in related reservation state
required to maintain consistency in the local node. The required to maintain consistency in the local node. The
adjustment in reservation state depends upon the style. For adjustment in reservation state depends upon the style. For
example, suppose a PathTear deletes the path state for a sender example, suppose a PathTear deletes the path state for a sender
S. If the style specifies explicit sender selection (FF or S. If the style specifies explicit sender selection (FF or
SE), any reservation with a filter spec matching S should be SE), any reservation with a filter spec matching S should be
deleted; if the style has wildcard sender selection (WF), the deleted; if the style has wildcard sender selection (WF), the
reservation should be deleted if S is the last sender to the reservation should be deleted if S is the last sender to the
session. These reservation changes should not trigger an session. These reservation changes should not trigger an
immediate Resv refresh message, since the PathTear message have immediate Resv refresh message, since the PathTear message has
already made the required changes upstream. However, at the already made the required changes upstream. However, at the
node in which a ResvTear message stops, the change of node in which a ResvTear message stops, the change of
reservation state may trigger a Resv refresh starting at that reservation state may trigger a Resv refresh starting at that
node. node.
3.1.6 Error Messages 3.1.6 Error Messages
There are two types of RSVP error messages. There are two types of RSVP error messages.
o PathErr messages result from Path messages and travel o PathErr messages result from Path messages and travel
skipping to change at page 43, line 4 skipping to change at page 42, line 10
Note that a ResvErr message contains only one flow descriptor. Note that a ResvErr message contains only one flow descriptor.
Therefore, a Resv message that contains N > 1 flow descriptors Therefore, a Resv message that contains N > 1 flow descriptors
(FF style) may create up to N separate ResvErr messages. (FF style) may create up to N separate ResvErr messages.
Generally speaking, a ResvErr message should be forwarded Generally speaking, a ResvErr message should be forwarded
towards all receivers that may have caused the error being towards all receivers that may have caused the error being
reported. More specifically: reported. More specifically:
o The node that detects an error in a reservation request o The node that detects an error in a reservation request
sends a RERR message to the next hop from which the sends a ResvErr message to the next hop from which the
erroneous reservation came. erroneous reservation came.
This message must contain the information required to This message must contain the information required to
define the error and to route the error message in later define the error and to route the error message in later
hops. It therefore includes an ERROR_SPEC object, a copy hops. It therefore includes an ERROR_SPEC object, a copy
of the STYLE object, and the appropriate error flow of the STYLE object, and the appropriate error flow
descriptor. If the error is an admission control failure, descriptor. If the error is an admission control failure,
any reservation already in place must be left in place, any reservation already in place must be left in place,
and the InPlace flag bit must be on in the ERROR_SPEC of and the InPlace flag bit must be on in the ERROR_SPEC of
the ResvErr message. the ResvErr message.
skipping to change at page 44, line 38 skipping to change at page 43, line 44
messages as UDP datagrams for end-system communication, as messages as UDP datagrams for end-system communication, as
described in Appendix C. UDP encapsulation is needed for systems described in Appendix C. UDP encapsulation is needed for systems
that cannot do raw network I/O. that cannot do raw network I/O.
Path, PathTear, and ResvConf messages must be sent with the Router Path, PathTear, and ResvConf messages must be sent with the Router
Alert IP option [Katz95] in their IP headers. This option may be Alert IP option [Katz95] in their IP headers. This option may be
used in the fast forwarding path of a high-speed router to detect used in the fast forwarding path of a high-speed router to detect
datagrams that require special processing. datagrams that require special processing.
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 immediately. However, this node must forward the state modification immediately. However,
must not trigger sending a message out the interface through which this must not trigger sending a message out the interface through
M arrived (which could happen if the implementation simply which M arrived (which could happen if the implementation simply
triggered an immediate refresh of all state for the session). triggered an immediate refresh of all state for the session).
This rule is necessary to prevent packet storms on broadcast LANs. This rule is necessary to prevent packet storms on broadcast LANs.
In this version of the spec, each RSVP message must occupy exactly In this version of the spec, each RSVP message must occupy exactly
one IP datagram. If it exceeds the MTU, such a datagram will be one IP datagram. If it exceeds the MTU, such a datagram will be
fragmented by IP and reassembled at the recipient node. This has fragmented by IP and reassembled at the recipient node. This has
several consequences: several consequences:
o A single RSVP message may not exceed the maximum IP datagram o A single RSVP message may not exceed the maximum IP datagram
size, approximately 64K bytes. size, approximately 64K bytes.
skipping to change at page 45, line 22 skipping to change at page 44, line 28
reservation state being transmitted into multiple self-contained reservation state being transmitted into multiple self-contained
messages, each of an acceptable size. messages, each of an acceptable size.
RSVP uses its periodic refresh mechanisms to recover from RSVP uses its periodic refresh mechanisms to recover from
occasional packet losses. Under network overload, however, occasional packet losses. Under network overload, however,
substantial losses of RSVP messages could cause a failure of substantial losses of RSVP messages could cause a failure of
resource reservations. To control the queueing delay and dropping resource reservations. To control the queueing delay and dropping
of RSVP packets, routers should be configured to offer them a of RSVP packets, routers should be configured to offer them a
preferred class of service. If RSVP packets experience noticeable preferred class of service. If RSVP packets experience noticeable
losses when crossing a congested non-RSVP cloud, a larger value losses when crossing a congested non-RSVP cloud, a larger value
can be used for the timeout factor K (see section 3.6 below). can be used for the timeout factor K (see section 3.6).
Some multicast routing protocols provide for "multicast tunnels", Some multicast routing protocols provide for "multicast tunnels",
which do IP encapsulation of multicast packets for transmission which do IP encapsulation of multicast packets for transmission
through routers that do not have multicast capability. A through routers that do not have multicast capability. A
multicast tunnel looks like a logical outgoing interface that is multicast tunnel looks like a logical outgoing interface that is
mapped into some physical interface. A multicast routing protocol mapped into some physical interface. A multicast routing protocol
that supports tunnels will describe a route using a list of that supports tunnels will describe a route using a list of
logical rather than physical interfaces. RSVP can operate across logical rather than physical interfaces. RSVP can operate across
such multicast tunnels in the following manner: such multicast tunnels in the following manner:
skipping to change at page 46, line 24 skipping to change at page 45, line 30
sending Path messages. On the other hand, error and teardown sending Path messages. On the other hand, error and teardown
messages are forwarded immediately and are therefore subject to messages are forwarded immediately and are therefore subject to
direct looping. direct looping.
Consider each message type. Consider each message type.
o Path Messages o Path Messages
Path messages are forwarded in exactly the same way as IP Path messages are forwarded in exactly the same way as IP
data packets. Therefore there should be no loops of Path data packets. Therefore there should be no loops of Path
messages, even in a topology with cycles. messages (except perhaps for transient routing loops, which
we ignore here), even in a topology with cycles.
o PathTear Messages o PathTear Messages
PathTear messages use the same routing as Path messages and PathTear messages use the same routing as Path messages and
therefore cannot loop. therefore cannot loop.
o PathErr Messages o PathErr Messages
Since Path messages do not loop, they create path state Since Path messages do not loop, they create path state
defining a loop-free reverse path to each sender. PathErr defining a loop-free reverse path to each sender. PathErr
skipping to change at page 49, line 12 skipping to change at page 48, line 20
must contain a SCOPE object derived from L by including only must contain a SCOPE object derived from L by including only
those senders that route to OI. If this SCOPE object is those senders that route to OI. If this SCOPE object is
empty, the ResvErr message should not be sent out OI. empty, the ResvErr message should not be sent out OI.
3.4 Blockade State 3.4 Blockade State
The basic rule for creating a Resv refresh message is to merge the The basic rule for creating a Resv refresh message is to merge the
flowspecs of the reservation requests in place in the node, by flowspecs of the reservation requests in place in the node, by
computing their LUB. However, this rule is modified by the computing their LUB. However, this rule is modified by the
existence of "blockade state" resulting from ResvErr messages, to existence of "blockade state" resulting from ResvErr messages, to
solve the KR-II problem (Section 2.6). The blockade state also solve the KR-II problem (see Section 2.6). The blockade state
enters into the routing of ResvErr messages for Admission Control also enters into the routing of ResvErr messages for Admission
failure. Control failure.
When a ResvErr message for an Admission Control failure is When a ResvErr message for an Admission Control failure is
received, its flowspec Qe is used to create or refresh an element received, its flowspec Qe is used to create or refresh an element
of local blockade state. Each element of blockade state consists of local blockade state. Each element of blockade state consists
of a blockade flowspec Qb taken from the flowspec of the ResvErr of a blockade flowspec Qb taken from the flowspec of the ResvErr
message, and an associated blockade timer Tb. When a blockade message, and an associated blockade timer Tb. When a blockade
timer expires, the corresponding blockade state is deleted. timer expires, the corresponding blockade state is deleted.
The granularity of blockade state depends upon the style of the The granularity of blockade state depends upon the style of the
ResvErr message that created it. For an explicit style, there may ResvErr message that created it. For an explicit style, there may
skipping to change at page 50, line 25 skipping to change at page 49, line 33
o If there are any local reservation requests Qi that are not o If there are any local reservation requests Qi that are not
blockaded, these are merged by computing their LUB. The blockaded, these are merged by computing their LUB. The
blockaded reservations are ignored; this allows forwarding of blockaded reservations are ignored; this allows forwarding of
a smaller reservation that has not failed and may perhaps a smaller reservation that has not failed and may perhaps
succeed, after a larger reservation fails. succeed, after a larger reservation fails.
o Otherwise (all local requests Qi are blockaded), they are o Otherwise (all local requests Qi are blockaded), they are
merged by taking the GLB (Greatest Lower Bound) of the Qi's. merged by taking the GLB (Greatest Lower Bound) of the Qi's.
(The use of some definition of "minimum" improves performance
by bracketing the failure level between the largest that
succeeds and the smallest that fails. The choice of GLB in
particular was made because it is simple to define and
implement, and no reason is known for using a different
definition of "minimum" here).
This refresh merging algorithm is applied separately to each flow This refresh merging algorithm is applied separately to each flow
(each sender or PHOP) contributing to a shared reservation (WF or (each sender or PHOP) contributing to a shared reservation (WF or
SE style). SE style).
Figure 12 shows an example of the the application of blockade Figure 12 shows an example of the the application of blockade
state for a shared reservation (WF style). There are two previous state for a shared reservation (WF style). There are two previous
hops labelled (a) and (b), and two next hops labelled (c) and (d). hops labelled (a) and (b), and two next hops labelled (c) and (d).
The larger reservation 4B arrived from (c) first, but it failed The larger reservation 4B arrived from (c) first, but it failed
somewhere upstream via PHOP (a), but not via PHOP (b). The somewhere upstream via PHOP (a), but not via PHOP (b). The
figures show the final "steady state" after the smaller figures show the final "steady state" after the smaller
skipping to change at page 51, line 33 skipping to change at page 50, line 38
route. To provide fast adaptation to routing changes without the route. To provide fast adaptation to routing changes without the
overhead of short refresh periods, the local routing protocol overhead of short refresh periods, the local routing protocol
module can notify the RSVP daemon of route changes for particular module can 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 a quick refresh of state for these destinations, using the trigger a quick refresh of state for these destinations, using the
new route. new route.
The specific rules are as follows: The specific 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 destination G, RSVP should wait for a short interfaces for destination G, RSVP should update the path
period W, and then send Path refreshes for all sessions G/* state, wait for a short period W, and then send Path
(i.e., for any session with destination G, regardless of refreshes for all sessions G/* (i.e., for any session with
destination port). destination G, regardless of destination port).
The short wait period before sending Path refreshes is to The short wait period before sending Path refreshes is to
allow the routing protocol getting settled with the new allow the routing protocol to settle, and the value for W
change(s), and the exact value for W should be chosen should be chosen accordingly. Currently W = 2 sec is
accordingly. Currently W = 2 sec is suggested; however, this suggested; however, this value should be configurable per
value should be configurable per interface. interface.
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 to that PHOP.
3.6 Time Parameters 3.6 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
generation of successive refreshes for the state by the neighbor generation of successive refreshes for the state by the neighbor
node, and the local state's lifetime L. Each RSVP Resv or Path node, and the local state's lifetime L. Each RSVP Resv or Path
message may contain a TIME_VALUES object specifying the R value message may contain a TIME_VALUES object specifying the R value
that was used to generate this (refresh) message. This R value is that was used to generate this (refresh) message. This R value is
then used to determine the value for L when the state is received then used to determine the value for L when the state is received
skipping to change at page 53, line 9 skipping to change at page 52, line 13
node does not implement local repair of reservations node does not implement local repair of reservations
disrupted by route changes, a smaller R speeds up adaptation disrupted by route changes, a smaller R speeds up adaptation
to routing changes, while increasing the RSVP overhead. With to routing changes, while increasing the RSVP overhead. With
local repair, a router can be more relaxed about R since the local repair, a router can be more relaxed about R since the
periodic refresh becomes only a backstop robustness periodic refresh becomes only a backstop robustness
mechanism. A node may therefore adjust the effective R mechanism. A node may therefore adjust the effective R
dynamically to control the amount of overhead due to refresh dynamically to control the amount of overhead due to refresh
messages. messages.
The current suggested default for R is 30 seconds. However, The current suggested default for R is 30 seconds. However,
the default should be configurable per interface. the default value Rdef should be configurable per interface.
5. When R is changed dynamically, there is a limit on how fast 5. When R is changed dynamically, there is a limit on how fast
it may increase. Specifically, the ratio of two successive it may increase. Specifically, the ratio of two successive
values R2/R1 must not exceed 1 + Slew.Max. values R2/R1 must not exceed 1 + Slew.Max.
Currently, Slew.Max is 0.30. With K = 3, one packet may be Currently, Slew.Max is 0.30. With K = 3, one packet may be
lost without state timeout while R is increasing 30 percent lost without state timeout while R is increasing 30 percent
per refresh cycle. per refresh cycle.
6. To improve robustness, a node may temporarily send refreshes 6. To improve robustness, a node may temporarily send refreshes
skipping to change at page 54, line 23 skipping to change at page 53, line 27
o B_Police_Flag -- Branch Policing o B_Police_Flag -- Branch Policing
This flag should be set on when the flowspec being installed This flag should be set on when the flowspec being installed
is smaller than, or incomparable to, a FLOWSPEC in place on is smaller than, or incomparable to, a FLOWSPEC in place on
any other interface, for the same FILTER_SPEC and SESSION. any other interface, for the same FILTER_SPEC and SESSION.
RSVP must also detect and report to receivers the presence of RSVP must also detect and report to receivers the presence of
non-RSVP (which implies non-integrated-service compliant) hops in non-RSVP (which implies non-integrated-service compliant) hops in
the path. For this purpose, an RSVP daemon sets the Non_RSVP flag the path. For this purpose, an RSVP daemon sets the Non_RSVP flag
bit in SESSION object of Path messages. With normal IP bit in the SESSION object of Path messages. With normal IP
forwarding, RSVP can detect a non-RSVP hop by comparing the IP TTL forwarding, RSVP can detect a non-RSVP hop by comparing the IP TTL
with which a Path message is sent to the TTL with which it is with which a Path message is sent to the TTL with which it is
received, and set the Non_RSVP bit on. For this purpose, the received, and set the Non_RSVP bit on. For this purpose, the
transmission TTL is placed in the common header. transmission TTL is placed in the common header.
However, the TTL is not always a reliable indicator of non-RSVP However, the TTL is not always a reliable indicator of non-RSVP
hops, and other means must be used. For example, if the routing hops, and other means must be used. For example, if the routing
protocol uses IP encapsulating tunnels, then the routing protocol protocol uses IP encapsulating tunnels, then the routing protocol
must inform RSVP when non-RSVP hops are included. If no automatic must inform RSVP when non-RSVP hops are included. If no automatic
mechanism will work, manual configuration will be required. mechanism will work, manual configuration will be required.
skipping to change at page 58, line 21 skipping to change at page 57, line 21
3.10.1 Application/RSVP Interface 3.10.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 Session o Register Session
Call: SESSION( DestAddress , ProtocolId, DstPort , Call: SESSION( DestAddress , ProtocolId, DstPort
[ , SESSION_object ] [ , SESSION_object ]
[ , Upcall_Proc_addr ] ) -> Session-id [ , Upcall_Proc_addr ] ) -> Session-id
This call initiates RSVP processing for a session, defined This call initiates RSVP processing for a session, defined
by DestAddress together with ProtocolId and possibly a by DestAddress together with ProtocolId and possibly a
port number DstPort. If successful, the SESSION call port number DstPort. If successful, the SESSION call
returns immediately with a local session identifier returns immediately with a local session identifier
Session-id, which may be used in subsequent calls. Session-id, which may be used in subsequent calls.
skipping to change at page 58, line 43 skipping to change at page 57, line 43
The Upcall_Proc_addr parameter defines the address of an The Upcall_Proc_addr parameter defines the address of an
upcall procedure to receive asynchronous error or event upcall procedure to receive asynchronous error or event
notification; see below. The SESSION_object parameter is notification; see below. The SESSION_object parameter is
included as an escape mechanism to support some more included as an escape mechanism to support some more
general definition of the session ("generalized general definition of the session ("generalized
destination port"), should that be necessary in the destination port"), should that be necessary in the
future. Normally SESSION_object will be omitted. future. Normally SESSION_object will be omitted.
o Define Sender o Define Sender
Call: SENDER( Session-id, Call: SENDER( Session-id
[ , Source_Address ] [ , Source_Port ] [ , Source_Address ] [ , Source_Port ]
[ , Sender_Template ] [ , Sender_Template ]
[ , Sender_Tspec ] [ , Data_TTL ] [ , Sender_Tspec ] [ , Data_TTL ]
[ , Sender_Policy_Data ] ) [ , Policy_data ] )
A sender uses this call to define, or to modify the A sender uses this call to define, or to modify the
definition of, the attributes of the data stream. The definition of, the attributes of the data stream. The
first SENDER call for the session registered as `Session- first SENDER call for the session registered as `Session-
id' will cause RSVP to begin sending Path messages for id' will cause RSVP to begin sending Path messages for
this session; later calls will modify the path this session; later calls will modify the path
information. information.
The SENDER parameters are interpreted as follows: The SENDER parameters are interpreted as follows:
- Source_Address - Source_Address
This is the address of the interface from which the This is the address of the interface from which the
data will be sent. If it is omitted, a default data will be sent. If it is omitted, a default
interface will be used. This parameter is needed on interface will be used. This parameter is needed
a multihomed sender host. only on a multihomed sender host.
- Source_Port - Source_Port
This is the UDP/TCP port from which the data will be This is the UDP/TCP port from which the data will be
sent. If it is omitted or zero, the port is "wild" sent.
and can match any port in a FILTER_SPEC.
- Sender_Template - Sender_Template
This parameter is included as an escape mechanism to This parameter is included as an escape mechanism to
support a more general definition of the sender support a more general definition of the sender
("generalized source port"). Normally this parameter ("generalized source port"). Normally this parameter
may be omitted. may be omitted.
- Sender_Tspec - Sender_Tspec
This optional parameter describes the traffic flow to This parameter describes the traffic flow to be sent.
be sent. It may be included to prevent over- It may be included to prevent over-reservation on the
reservation on the initial hops. initial hops.
- Data_TTL - Data_TTL
This is the (non-default) IP Time-To-Live parameter This is the (non-default) IP Time-To-Live parameter
that is being supplied on the data packets. It is that is being supplied on the data packets. It is
needed to ensure that Path messages do not have a needed to ensure that Path messages do not have a
scope larger than multicast data packets. scope larger than multicast data packets.
- Sender_Policy_Data - Policy_data
This optional parameter passes policy data for the This optional parameter passes policy data for the
sender. This data may be supplied by a system sender. This data may be supplied by a system
service, with the application treating it as opaque. service, with the application treating it as opaque.
o Reserve o Reserve
Call: RESERVE( session-id, [ receiver_address , ] Call: RESERVE( session-id, [ receiver_address , ]
[ CONF_flag, ] style, style-dependent-parms ) [ CONF_flag, ] [ Policy_data, ]
style, style-dependent-parms )
A receiver uses this call to make or to modify a resource A receiver uses this call to make or to modify a resource
reservation for the session registered as `session-id'. reservation for the session registered as `session-id'.
The first RESERVE call will initiate the periodic The first RESERVE call will initiate the periodic
transmission of Resv messages. A later RESERVE call may transmission of Resv messages. A later RESERVE call may
be given to modify the parameters of the earlier call (but be given to modify the parameters of the earlier call (but
note that changing existing reservations may result in note that changing existing reservations may result in
admission control failures). admission control failures).
The optional `receiver_address' parameter may be used by a The optional `receiver_address' parameter may be used by a
receiver on a multihomed host (or router); it is the IP receiver on a multihomed host (or router); it is the IP
address of one of the node's interfaces. The CONF_flag address of one of the node's interfaces. The CONF_flag
should be set on if a reservation confirmation is desired, should be set on if a reservation confirmation is desired,
off otherwise. The `style' parameter indicates the off otherwise. The `Policy_data' parameter specifies
reservation style. The rest of the parameters depend upon policy data for the receiver, while the `style' parameter
the style; generally these will include appropriate indicates the reservation style. The rest of the
flowspecs, filter specs, and possibly receiver policy data parameters depend upon the style; generally these will be
objects. appropriate flowspecs and filter specs.
The RESERVE call returns immediately. Following a RESERVE The RESERVE call returns immediately. Following a RESERVE
call, an asynchronous ERROR/EVENT upcall may occur at any call, an asynchronous ERROR/EVENT upcall may occur at any
time. time.
o Release o Release
Call: RELEASE( session-id ) Call: RELEASE( session-id )
This call removes RSVP state for the session specified by This call removes RSVP state for the session specified by
skipping to change at page 61, line 16 skipping to change at page 60, line 16
Currently there are five upcall types, distinguished by Currently there are five upcall types, distinguished by
the Info_type parameter. The selection of information the Info_type parameter. The selection of information
parameters depends upon the type. parameters depends upon the type.
1. Info_type = PATH_EVENT 1. Info_type = PATH_EVENT
A Path Event upcall results from receipt of the first A Path Event upcall results from receipt of the first
Path message for this session, indicating to a Path message for this session, indicating to a
receiver application that there is at least one receiver application that there is at least one
active sender. active sender, or if the path state changes.
Upcall: <Upcall_Proc>( ) -> session-id, Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=PATH_EVENT, Info_type=PATH_EVENT,
flags, flags,
Sender_Tspec, Sender_Template, Sender_Tspec, Sender_Template
[ , Advert ] [ , Policy_data ] [ , Adspec ] [ , Policy_data ]
This upcall presents the Sender_Tspec and the This upcall presents the Sender_Tspec and the
Sender_Template from a Path message; it also passes Sender_Template from a Path message; it also passes
the advertisement and policy data if they are the advertisement and policy data if they are
present. The possible flags correspond to Non_RSVP present. The possible flags correspond to Non_RSVP
and Maybe_RSVP flags of the SESSION object. and Maybe_RSVP flags of the SESSION object.
2. Info_type = RESV_EVENT 2. Info_type = RESV_EVENT
A Resv Event upcall is triggered by the receipt of A Resv Event upcall is triggered by the receipt of
the first RESV message, or by modification of a the first RESV message, or by modification of a
previous reservation state, for this session. previous reservation state, for this session.
Upcall: <Upcall_Proc>( ) -> session-id, Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=RESV_EVENT, Info_type=RESV_EVENT,
Style, Flowspec, Filter_Spec_list, Style, Flowspec, Filter_Spec_list
[ , Policy_data ] [ , Policy_data ]
Here `Flowspec' will be the effective QoS that has Here `Flowspec' will be the effective QoS that has
been received. Note that an FF-style Resv message been received. Note that an FF-style Resv message
may result in multiple RESV_EVENT upcalls, one for may result in multiple RESV_EVENT upcalls, one for
each flow descriptor. each flow descriptor.
3. Info_type = PATH_ERROR 3. Info_type = PATH_ERROR
An Path Error event indicates an error in sender An Path Error event indicates an error in sender
information that was specified in a SENDER call. information that was specified in a SENDER call.
Upcall: <Upcall_Proc>( ) -> session-id, Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=PATH_ERROR, Info_type=PATH_ERROR,
Error_code , Error_value , Error_code , Error_value ,
Error_Node , Sender_Template, Error_Node , Sender_Template
[ Policy_data_list ] [ , Policy_data_list ]
The Error_code parameter will define the error, and The Error_code parameter will define the error, and
Error_value may supply some additional (perhaps Error_value may supply some additional (perhaps
system-specific) data about the error. The system-specific) data about the error. The
Error_Node parameter will specify the IP address of Error_Node parameter will specify the IP address of
the node that detected the error. The the node that detected the error. The
Policy_data_list parameter, if present, will contain Policy_data_list parameter, if present, will contain
any POLICY_DATA objects from the failed Path message. any POLICY_DATA objects from the failed Path message.
4. Info_type = RESV_ERR 4. Info_type = RESV_ERR
skipping to change at page 62, line 44 skipping to change at page 61, line 44
contributed. contributed.
Upcall: <Upcall_Proc>( ) -> session-id, Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=RESV_ERROR, Info_type=RESV_ERROR,
Error_code , Error_value , Error_code , Error_value ,
Error_Node , Error_flags , Error_Node , Error_flags ,
Flowspec, Filter_spec_list, Flowspec, Filter_spec_list
[ Policy_data_list ] [ , Policy_data_list ]
The Error_code parameter will define the error and The Error_code parameter will define the error and
Error_value may supply some additional (perhaps Error_value may supply some additional (perhaps
system-specific) data. The Error_Node parameter will system-specific) data. The Error_Node parameter will
specify the IP address of the node that detected the specify the IP address of the node that detected the
event being reported. event being reported.
There are two Error_flags: There are two Error_flags:
- InPlace - InPlace
skipping to change at page 63, line 44 skipping to change at page 62, line 44
A Confirmation event indicates that a ResvConf A Confirmation event indicates that a ResvConf
message was received. message was received.
Upcall: <Upcall_Proc>( ) -> session-id, Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=RESV_CONFIRM, Info_type=RESV_CONFIRM,
Style, List_count, Style, List_count,
Flowspec, Filter_spec_list, Flowspec, Filter_spec_list
[ Policy_data ] [ , Policy_data ]
The parameters are interpreted as in the Resv Error The parameters are interpreted as in the Resv Error
upcall. upcall.
Although RSVP messages indicating path or resv events may Although RSVP messages indicating path or resv events may
be received periodically, the API should make the be received periodically, the API should make the
corresponding asynchronous upcall to the application only corresponding asynchronous upcall to the application only
on the first occurrence or when the information to be on the first occurrence or when the information to be
reported changes. All error and confirmation events reported changes. All error and confirmation events
should be reported to the application. should be reported to the application.
skipping to change at page 64, line 36 skipping to change at page 63, line 36
The TC_Flowspec parameter defines the desired effective The TC_Flowspec parameter defines the desired effective
QoS to admission control; its value is computed as the QoS to admission control; its value is computed as the
maximum over the flowspecs of different next hops (see the maximum over the flowspecs of different next hops (see the
Compare_Flowspecs call below). The TC_Tspec parameter Compare_Flowspecs call below). The TC_Tspec parameter
defines the effective sender Tspec Path_Te (see Section defines the effective sender Tspec Path_Te (see Section
2.3). The Police_Flags parameter carries the three flags 2.3). The Police_Flags parameter carries the three flags
E_Police_Flag, M_Police_Flag, and B_Police_Flag; see E_Police_Flag, M_Police_Flag, and B_Police_Flag; see
Section 3.7. Section 3.7.
The TC_AddFlowspec call returns an error code if Flowspec If this call is successful, it establishes a new
is malformed or if the requested resources are reservation channel corresponding to RHandle; otherwise,
unavailable. Otherwise, it establishes a new reservation it returns an error code. The opaque number RHandle is
channel corresponding to Rhandle. It returns the opaque used by the caller for subsequent references to this
number Rhandle for subsequent references to this reservation. If the traffic control service updates the
reservation. If the service updates the flowspec, the flowspec, the call will also return the updated object as
call will also return the updated object as Fwd_Flowspec. Fwd_Flowspec.
o Modify Reservation o Modify Reservation
Call: TC_ModFlowspec( Interface, Rhandle, TC_Flowspec, Call: TC_ModFlowspec( Interface, RHandle, TC_Flowspec,
Sender_Tspec, Police_flags ) Sender_Tspec, Police_flags )
-> [ Fwd_Flowspec ] [ -> Fwd_Flowspec ]
This call is used to modify an existing reservation. This call is used to modify an existing reservation.
TC_Flowspec is passed to Admission Control; if it is TC_Flowspec is passed to Admission Control; if it is
rejected, the current flowspec is left in force. The rejected, the current flowspec is left in force. The
corresponding filter specs, if any, are not affected. The corresponding filter specs, if any, are not affected. The
other parameters are defined as in TC_AddFlowspec. If the other parameters are defined as in TC_AddFlowspec. If the
service updates the flowspec, the call will also return service updates the flowspec, the call will also return
the updated object as Fwd_Flowspec. the updated object as Fwd_Flowspec.
o Delete Flowspec o Delete Flowspec
Call: TC_DelFlowspec( Interface, Rhandle ) Call: TC_DelFlowspec( Interface, RHandle )
This call will delete an existing reservation, including This call will delete an existing reservation, including
the flowspec and all associated filter specs. the flowspec and all associated filter specs.
o Add Filter Spec o Add Filter Spec
Call: TC_AddFilter( Interface, Rhandle, Call: TC_AddFilter( Interface, RHandle,
Session , FilterSpec ) -> FHandle Session , FilterSpec ) -> FHandle
This call is used to associate an additional filter spec This call is used to associate an additional filter spec
with the reservation specified by the given Rhandle, with the reservation specified by the given RHandle,
following a successful TC_AddFlowspec call. This call following a successful TC_AddFlowspec call. This call
returns a filter handle FHandle. returns a filter handle FHandle.
o Delete Filter Spec o Delete Filter Spec
Call: TC_DelFilter( Interface, FHandle ) Call: TC_DelFilter( Interface, FHandle )
This call is used to remove a specific filter, specified This call is used to remove a specific filter, specified
by FHandle. by FHandle.
skipping to change at page 66, line 13 skipping to change at page 65, line 13
o Preemption Upcall o Preemption Upcall
Upcall: TC_Preempt() -> RHandle, Reason_code Upcall: TC_Preempt() -> RHandle, Reason_code
In order to grant a new reservation request, the admission In order to grant a new reservation request, the admission
control and/or policy control modules may preempt one or control and/or policy control modules may preempt one or
more existing reservations. This will trigger a more existing reservations. This will trigger a
TC_Preempt() upcall to RSVP for each preempted TC_Preempt() upcall to RSVP for each preempted
reservation, passing the RHandle of the reservation and a reservation, passing the RHandle of the reservation and a
sub-code indicating the reason. sub-code indicating the reason.
3.10.3 RSVP/Routing Interface 3.10.3 RSVP/Policy Control Interface
This interface will be specified in a future document.
3.10.4 RSVP/Routing Interface
An RSVP implementation needs the following support from the An RSVP implementation needs the following support from the
packet forwarding and routing mechanisms of the node. packet forwarding and routing mechanisms of the node.
o Promiscuous Receive Mode for RSVP Messages o Promiscuous Receive Mode for RSVP Messages
Packets received for IP protocol 46 but not addressed to Packets received for IP protocol 46 but not addressed to
the node must be diverted to the RSVP program for the node must be diverted to the RSVP program for
processing, without being forwarded. On a router, the processing, without being forwarded. On a router, the
identity of the interface, real or virtual, on which it is identity of the interface, real or virtual, on which it is
skipping to change at page 68, line 18 skipping to change at page 67, line 19
RSVP must be able to learn what real and virtual RSVP must be able to learn what real and virtual
interfaces are active, with their IP addresses. interfaces are active, with their IP addresses.
It should be possible to logically disable an interface It should be possible to logically disable an interface
for RSVP. When an interface is disabled for RSVP, a Path for RSVP. When an interface is disabled for RSVP, a Path
message should never be forwarded out that interface, and message should never be forwarded out that interface, and
if an RSVP message is received on that interface, the if an RSVP message is received on that interface, the
message should be silently discarded (perhaps with local message should be silently discarded (perhaps with local
logging). logging).
3.10.4 Service-Dependent Manipulations 3.10.5 Service-Dependent Manipulations
Flowspecs, Tspecs, and Adspecs are opaque objects to RSVP; Flowspecs, Tspecs, and Adspecs are opaque objects to RSVP;
their contents are defined in service specification documents. their contents are defined in service specification documents.
In order to manipulate these objects, RSVP daemon must have In order to manipulate these objects, RSVP daemon must have
available to it the following service-dependent routines. available to it the following service-dependent routines.
o Compare Flowspecs o Compare Flowspecs
Compare_Flowspecs( Flowspec_1, Flowspec_2 ) -> Compare_Flowspecs( Flowspec_1, Flowspec_2 ) ->
skipping to change at page 70, line 14 skipping to change at page 69, line 14
4. Message Processing Rules 4. Message Processing Rules
This section provides a generic description of the rules for RSVP This section provides a generic description of the rules for RSVP
operation. It is intended to outline a set of algorithms that will operation. It is intended to outline a set of algorithms that will
accomplish the needed function, omitting some details. accomplish the needed function, omitting some details.
This section assumes the generic interface calls defined in Section This section assumes the generic interface calls defined in Section
3.10 and the following data structures. An actual implementation may 3.10 and the following data structures. An actual implementation may
use additional or different data structures and interfaces. The data use additional or different data structures and interfaces. The data
structure fields that a shown are required unless they are explicitly structure fields that are shown are required unless they are
labelled as optional. explicitly labelled as optional.
o PSB -- Path State Block o PSB -- Path State Block
Each PSB holds path state for a particular (session, sender) Each PSB holds path state for a particular (session, sender)
pair, defined by SESSION and SENDER_TEMPLATE objects, pair, defined by SESSION and SENDER_TEMPLATE objects,
respectively, received in a Path message. respectively, received in a Path message.
PSB contents include the following values from a Path message: PSB contents include the following values from a Path message:
- Session - Session
skipping to change at page 70, line 51 skipping to change at page 69, line 51
- Local_Only flag (Section 3.8) - Local_Only flag (Section 3.8)
In addition, the PSB contains the following information provided In addition, the PSB contains the following information provided
by routing: OutInterface_list, which is the list of outgoing by routing: OutInterface_list, which is the list of outgoing
interfaces for this (sender, destination), and IncInterface, interfaces for this (sender, destination), and IncInterface,
which is the expected incoming interface. For a unicast which is the expected incoming interface. For a unicast
destination, OutInterface_list contains one entry and destination, OutInterface_list contains one entry and
IncInterface is undefined. IncInterface is undefined.
Note that there may be more than one PSB for the same (session,
sender) pair but different incoming interfaces (see Section
3.8). At most one of these, which will have the Local_Only flag
off, will be the PSB used for forwarding Path messages
downstream; we will refer to it as the "forwarding PSB" in the
following. The other PSB's will have the Local_Only flag on and
an empty OutInterface_list. The Local_Only flag is needed to
correctly match PSB's against RSB's, by the rules of Section
3.8.
o RSB -- Reservation State Block o RSB -- Reservation State Block
Each RSB holds a reservation request that arrived in a Each RSB holds a reservation request that arrived in a
particular Resv message, corresponding to the triple: (session, particular Resv message, corresponding to the triple: (session,
next hop, Filter_spec_list). Here "Filter_spec_list" may be a next hop, Filter_spec_list). Here "Filter_spec_list" may be a
list of FILTER_SPECs (for SE style), a single FILTER_SPEC (FF list of FILTER_SPECs (for SE style), a single FILTER_SPEC (FF
style), or empty (WF style). We define the virtual object type style), or empty (WF style). We define the virtual object type
"FILTER_SPEC*" for such a data structure. "FILTER_SPEC*" for such a data structure.
RSB contents include: RSB contents include:
- Session specification - Session specification
skipping to change at page 71, line 41 skipping to change at page 70, line 51
Each TCSB holds the reservation specification that has been Each TCSB holds the reservation specification that has been
handed to traffic control for a specific outgoing interface. In handed to traffic control for a specific outgoing interface. In
general, TCSB information is derived from RSB's for the same general, TCSB information is derived from RSB's for the same
outgoing interface. Each TCSB defines a single reservation for outgoing interface. Each TCSB defines a single reservation for
a particular triple: (session, OI, Filter_spec_list). TCSB a particular triple: (session, OI, Filter_spec_list). TCSB
contents include: contents include:
- Session - Session
- OI - OI (Outgoing Interface)
- Filter_spec_list - Filter_spec_list
- TC_Flowspec, the effective flowspec, i.e., the LUB over the - TC_Flowspec, the effective flowspec, i.e., the LUB over the
corresponding FLOWSPEC values from matching RSB's. corresponding FLOWSPEC values from matching RSB's.
TC_Flowspec is passed to traffic control to make the actual TC_Flowspec is passed to traffic control to make the actual
reservation. reservation.
- Fwd_Flowspec, the updated object to be forwarded after - Fwd_Flowspec, the updated object to be forwarded after
merging. merging.
skipping to change at page 72, line 50 skipping to change at page 72, line 11
The following Boolean Flag variables are used in this section: The following Boolean Flag variables are used in this section:
Path_Refresh_Needed, Resv_Refresh_Needed, Tear_Needed, Need_Scope, Path_Refresh_Needed, Resv_Refresh_Needed, Tear_Needed, Need_Scope,
B_Merge, and NeworMod. Refresh_PHOP_list is a variable-length list B_Merge, and NeworMod. Refresh_PHOP_list is a variable-length list
of PHOPs to be refreshed. of PHOPs to be refreshed.
MESSAGE ARRIVES MESSAGE ARRIVES
Verify version number and RSVP checksum, and discard message if any Verify version number and RSVP checksum, and discard message if any
mismatch is found. mismatch is found.
If the message type is ResvConf, forward the message to IP If the message type is not Path or PathTear or ResvConf and if the IP
destination address and return. destination address does not match any of the addresses of the local
interfaces, then forward the message to IP destination address and
If the message type is not Path or PathTear and if the IP destination return.
address does not match any of the addresses of the local interfaces,
then forward the message to IP destination address and return.
Parse the sequence of objects in the message. If any required Parse the sequence of objects in the message. If any required
objects are missing or the length field of the common header does not objects are missing or the length field of the common header does not
match, discard the message and return. match an object boundary, discard the message and return.
Verify the INTEGRITY object, if any. If the check fails, discard the Verify the INTEGRITY object, if any. If the check fails, discard the
message and return. message and return.
Verify the consistent use of port fields. If the DstPort in the Verify the consistent use of port fields. If the DstPort in the
SESSION object is zero but the SrcPort in a SENDER_TEMPLATE or SESSION object is zero but the SrcPort in a SENDER_TEMPLATE or
FILTER_SPEC object is non-zero, then the message has a "conflicting FILTER_SPEC object is non-zero, then the message has a "conflicting
source port" error; silently discard the message and return. source port" error; silently discard the message and return.
Processing of POLICY_DATA objects will be specified in the future. Processing of POLICY_DATA objects will be specified in the future.
Further processing depends upon message type. Further processing depends upon message type.
Path MESSAGE ARRIVES Path MESSAGE ARRIVES
Assume the Path message arrives on interface InIf.
Process the sender descriptor object sequence in the message as Process the sender descriptor object sequence in the message as
follows. The Path_Refresh_Needed and Resv_Refresh_Needed flags follows. The Path_Refresh_Needed and Resv_Refresh_Needed flags
are initially off. are initially off.
o Search for a path state block (PSB) whose (session, o Search for a path state block (PSB) whose (session,
sender_template) pair matches the corresponding objects in sender_template) pair matches the corresponding objects in
the message. During this search: the message, and whose IncInterface matches InIf.
During this search:
1. If a PSB is found whose session matches the 1. If a PSB is found whose session matches the
DestAddress and Protocol Id fields of the received DestAddress and Protocol Id fields of the received
SESSION object, but the DstPorts differ and one is SESSION object, but the DstPorts differ and one is
zero, then build and send a "Conflicting Dst Port" zero, then build and send a "Conflicting Dst Port"
PathErr message, drop the Path message, and return. PathErr message, drop the Path message, and return.
2. If a PSB is found with a matching sender host but the 2. If a PSB is found with a matching sender host but the
SrcPorts differ and one of the SrcPorts is zero, then SrcPorts differ and one of the SrcPorts is zero, then
build and send an "Ambiguous Path" PathErr message, build and send an "Ambiguous Path" PathErr message,
drop the Path message, and return. drop the Path message, and return.
3. If a forwarding PSB is found, i.e., a PSB that matches
the (session, sender_template) pair and whose
Local_Only flag is off, save a pointer to it in the
variable fPSB. If none is found, set fPSB to NULL.
o If there was no matching PSB, then: o If there was no matching PSB, then:
1. Create a new PSB. 1. Create a new PSB.
2. Copy contents of the SESSION, SENDER_TEMPLATE, 2. Copy contents of the SESSION, SENDER_TEMPLATE,
SENDER_TSPEC, and PHOP (IP address and LIH) objects SENDER_TSPEC, and PHOP (IP address and LIH) objects
into the PSB. into the PSB.
3. Calculate initial routing information. If the sender 3. If the sender is from the local API, set
is from the local API, OutInterface_List is set to the OutInterface_List to the single interface whose
single interface whose address matches the sender address matches the sender address, and make
address, and IncInterface is undefined. Otherwise, IncInterface undefined. Otherwise, turn on the
call the appropriate Route_Query routine, using Local_Only flag.
DestAddress from SESSION and (for multicast routing)
SrcAddress from SENDER_TEMPLATE. Store the values of 4. Turn on the Path_Refresh_Needed flag.
OutInterface_list and IncInterface from routing into
o Otherwise (there is a matching PSB):
- If the PHOP IP address, the LIH, or Sender_Tspec
differs between the message and the PSB, copy the new
value into the PSB and turn on the Path_Refresh_Needed
flag. If the PHOP IP address or the LIH differ, also
turn on the Resv_Refresh_Needed flag.
o Call the resulting PSB the "current PSB" (cPSB). Update
the cPSB, as follows:
- Start or Restart the cleanup timer for the PSB.
- If the message contains an ADSPEC object, copy it into
the PSB. the PSB.
4. If IncInterface is defined and if a multicast message - Copy E_Police flag from SESSION object into PSB.
arrived on an interface different from IncInterface,
turn on the Local_Only flag in the PSB and store the
actual incoming interface into IncInterface.
5. If this is the first PSB for the session, set a - Store the received TTL into the PSB.
refresh timer for the session.
6. Turn on the Path_Refresh_Needed flag. If the received TTL differs from Send_TTL in the RSVP
common header, set the Non_RSVP flag on in the PSB.
o Otherwise (there is a matching PSB): o If the PSB is new or if there is no route change
notification in place, then perform the following routing
manipulations, but not if the cPSB is from the local API.
1. If there is no route change notification in place, 1. Invoke the appropriate Route_Query routine using
call the appropriate Route_Query routine using
DestAddress from SESSION and (for multicast routing) DestAddress from SESSION and (for multicast routing)
SrcAddress from Sender_Template. SrcAddress from Sender_Template.
- If the OutInterface_list that is returned differs Call the results (Rt_OutL, Rt_InIf).
from that in the PSB, then execute the Path LOCAL
REPAIR event sequence below.
- If a multicast message arrived on an interface 2. If the destination is multicast and Rt_InIf differs
different from IncInterface, then execute the from IncInterface in the cPSB, but fPSB points to the
Resv REFRESH event sequence below for the cPSB, then do the following.
previous hop.
2. If the PHOP IP address, the LIH, or Sender_Tspec - Turn on the Local_Only flag and clear the
differs between the message and the PSB, copy the new OutInterface_list of the fPSB. Set the fPSB
value into the PSB and turn on the Path_Refresh_Needed pointer to NULL.
flag. If the PHOP IP address or the LIH differ, also
turn on the Resv_Refresh_Needed flag.
o Update the PSB - Search for a PSB for the same (session,
sender_template) pair whose IncInterface matches
Rt_InIf. If one is found, set fPSB to point to
it.
1. If the message contains an ADSPEC object, copy it into 3. If the destination is multicast and Rt_InIf is the
the PSB. same as IncInterface in the cPSB, but fPSB does not
point to the cPSB, then do the following.
2. Start or Restart the cleanup timer for the PSB. - Copy into the cPSB the OutInterface_list from the
PSB, if any, pointed to by fPSB. Clear
OutInterface_list and turn on the Local_Only flag
in the PSB pointed to by fPSB, if any.
3. Copy E_Police flag from SESSION object into PSB. - Turn off the Local_Only flag in the cPSB and set
fPSB to point to cPSB.
4. Store the received TTL into the PSB. 4. If Rt_OutL differs from OutInterface_list of the PSB
pointed to by fPSB, then:
If the received TTL differs from Send_TTL in the RSVP - Update the OutInterface_list of the PSB from
common header, set the Non_RSVP flag on in the PSB. Rt_OutL, and then execute the Path LOCAL REPAIR
event sequence below.
o If the Path_Refresh_Needed flag is now off, drop the Path o If the Path_Refresh_Needed flag is now off, drop the Path
message and return. message and return.
Otherwise (the path state is new or modified) then do Otherwise (the path state is new or modified), do
refreshes, upcalls, and state updates. refreshes, upcalls, and state updates as follows.
1. If this Path message came from a network interface and 1. If this Path message came from a network interface and
not from a local application, make a Path Event upcall not from a local application, make a Path Event upcall
for each local application for this session: for each local application for this session:
Call: <Upcall_Proc>( session-id, PATH_EVENT, Call: <Upcall_Proc>( session-id, PATH_EVENT,
flags, sender_tspec, sender_template, flags, sender_tspec, sender_template
[ADSPEC], [POLICY_DATA] ) [ , ADSPEC] [ , POLICY_DATA] )
2. Execute the Path REFRESH event sequence (below) for 2. If OutInterface_list is not empty, execute the Path
the sender defined by the PSB. REFRESH event sequence (below) for the sender defined
by the PSB.
3. Search for an RSB whose Filter_spec_list includes a 3. Search for any matching reservation state, i.e., an
FILTER_SPEC matching the SENDER_TEMPLATE and whose OI RSB whose Filter_spec_list includes a FILTER_SPEC
appears in the OutInterface_list. If none is found, matching the SENDER_TEMPLATE and whose OI appears in
drop the Path message and return. the OutInterface_list, and make this the `active RSB'.
If none is found, drop the Path message and return.
Otherwise, make this the `active RSB' and execute the 4. Execute the Resv REFRESH sequence (below) for the PHOP
event sequence UPDATE TRAFFIC CONTROL to update the in the PSB.
local traffic control state if necessary. If this
modifies the traffic control state, it will make a
RESV_EVENT upcall to any matching local application
and turn on the Resv_Refresh_Needed flag.
4. If the Resv_Refresh_Needed flag is now on, execute the 5. Execute the event sequence UPDATE TRAFFIC CONTROL to
Resv REFRESH sequence for the PHOP in the PSB. update the local traffic control state if necessary.
This sequence will turn on the Resv_Refresh_Needed
flag if the traffic control state has been modified in
a manner that should trigger a reservation refresh.
If so, execute the Resv REFRESH sequence for the PHOP
in the PSB.
o Drop the Path message and return. o Drop the Path message and return.
PathTear MESSAGE ARRIVES PathTear MESSAGE ARRIVES
o Search for a PSB whose (Session, Sender_Template) pair o Search for a PSB whose (Session, Sender_Template) pair
matches the corresponding objects in the message. If no matches the corresponding objects in the message. If no
matching PSB is found, drop the PathTear message and matching PSB is found, drop the PathTear message and
return. return.
o Forward a copy of the PathTear message to each outgoing o Forward a copy of the PathTear message to each outgoing
interface listed in OutInterface_list of the PSB. interface listed in OutInterface_list of the PSB.
o Find each RSB that matches this PSB, i.e., that whose o Find each RSB that matches this PSB, i.e., that whose
Filter_spec_list matches Sender_Template in the PSB and Filter_spec_list matches Sender_Template in the PSB and
whose OI is included in OutInterface_list. whose OI is included in OutInterface_list.
If this RSB matches no other PSB, then tear down the RSB, If this RSB matches no other PSB, then:
as described below under ResvTear MESSAGE ARRIVES.
1. Delete the RSB.
2. Execute the event sequence UPDATE TRAFFIC CONTROL
(below) to update the traffic control state to be
consistent with the current reservation state.
o Delete the PSB. o Delete the PSB.
o Drop the PathTear message and return. o Drop the PathTear message and return.
PathErr MESSAGE ARRIVES PathErr MESSAGE ARRIVES
o Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair o Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair
matches the corresponding objects in the message. If no matches the corresponding objects in the message. If no
matching PSB is found, drop the PathErr message and return. matching PSB is found, drop the PathErr message and return.
o If the previous hop address in the PSB is the local API, o If the previous hop address in the PSB is the local API,
make an error upcall to the application: make an error upcall to the application:
Call: <Upcall_Proc>( session-id, PATH_ERROR, Call: <Upcall_Proc>( session-id, PATH_ERROR,
Error_code, Error_value, Error_code, Error_value,
Node_Addr, Sender_Template, Node_Addr, Sender_Template
[Policy_Data] ) [ , Policy_Data] )
Any SENDER_TSPEC or ADSPEC object in the message is Any SENDER_TSPEC or ADSPEC object in the message is
ignored. ignored.
Otherwise, send a copy of the PathErr message to the PHOP Otherwise, send a copy of the PathErr message to the PHOP
IP address. IP address.
o Drop the PathErr message and return. o Drop the PathErr message and return.
Resv MESSAGE ARRIVES Resv MESSAGE ARRIVES
skipping to change at page 77, line 30 skipping to change at page 77, line 27
o Check for incompatible styles. o Check for incompatible styles.
If any existing RSB for the session has a style that is If any existing RSB for the session has a style that is
incompatible with the style of the message, build and send incompatible with the style of the message, build and send
a ResvErr message specifying "Conflicting Style", drop the a ResvErr message specifying "Conflicting Style", drop the
Resv message, and return. Resv message, and return.
Process the flow descriptor list to make reservations, as Process the flow descriptor list to make reservations, as
follows, depending upon the style. The following uses a filter follows, depending upon the style. The following uses a filter
spec list struct Filtss, of type FILTER_SPEC* (defined earlier). spec list struct Filtss of type FILTER_SPEC* (defined earlier).
For FF style: execute the following steps independently for each For FF style: execute the following steps independently for each
flow descriptor in the message, i.e., for each (FLOWSPEC, flow descriptor in the message, i.e., for each (FLOWSPEC,
Filtss) pair. Here the structure Filtss consists of the Filtss) pair. Here the structure Filtss consists of the
FILTER_SPEC from the flow descriptor. FILTER_SPEC from the flow descriptor.
For SE style, execute the following steps once for (FLOWSPEC, For SE style, execute the following steps once for (FLOWSPEC,
Filtss), with Filtss consisting of the list of FILTER_SPEC Filtss), with Filtss consisting of the list of FILTER_SPEC
objects from the flow descriptor. objects from the flow descriptor.
For WF style, execute the following steps once for (FLOWSPEC, For WF style, execute the following steps once for (FLOWSPEC,
Filtss), with Filtss an empty list. Filtss), with Filtss an empty list.
o Check the path state, as follows. o Check the path state, as follows.
1. Locate the set of PSBs (senders) whose 1. Locate the set of PSBs (senders) that route to OI and
SENDER_TEMPLATEs match Filtss and whose whose SENDER_TEMPLATEs match Filtss.
OutInterface_list includes OI.
If this set is empty, build and send an error message If this set is empty, build and send an error message
specifying "No sender information", and continue with specifying "No sender information", and continue with
the next flow descriptor in the Resv message. the next flow descriptor in the Resv message.
2. If the style has explicit sender selection (e.g., FF 2. If the style has explicit sender selection (e.g., FF
or SE) and if any FILTER_SPEC included in Filtss or SE) and if any FILTER_SPEC included in Filtss
matches more than one PSB, build and send a ResvErr matches more than one PSB, build and send a ResvErr
message specifying "Ambiguous filter spec" and message specifying "Ambiguous filter spec" and
continue with the next flow descriptor in the Resv continue with the next flow descriptor in the Resv
message. message.
3. Add the PHOP from the PSB to Refresh_PHOP_list, if the 3. Add the PHOP from the PSB to Refresh_PHOP_list, if the
PHOP is not already on the list. PHOP is not already on the list.
o Find or create a reservation state block (RSB) for the o Find or create a reservation state block (RSB) for
triple: (session, NHOP, Filtss). Call this the "active (SESSION, PHOP). If the style is distinct, Filtss is also
RSB". used in the selection. Call this the "active RSB".
o If the active RSB is new: o If the active RSB is new:
1. Set the session, NHOP, OI and style of the RSB from 1. Set the session, NHOP, OI and style of the RSB from
the message. the message.
2. Copy Filtss into the Filter_spec_list of the RSB. 2. Copy Filtss into the Filter_spec_list of the RSB.
3. Copy the FLOWSPEC and any SCOPE object from the 3. Copy the FLOWSPEC and any SCOPE object from the
message into the RSB. message into the RSB.
4. Set NeworMod flag on. 4. Set NeworMod flag on.
o Start or restart the cleanup timer on the active RSB. o If the active RSB is not new, check whether Filtss from the
message contains FILTER_SPECs that are not in the RSB; if
so, add the new FILTER_SPECs and turn on the NeworMod flag.
o If the message contained a RESV_CONFIRM object, copy it o Start or restart the cleanup timer on the active RSB, or,
into the RSB and turn on Resv_Refresh_Needed flag. in the case of SE style, on each FILTER_SPEC of the RSB
that also appears in Filtss.
o If the active RSB is not new, check whether STYLE, FLOWSPEC o If the active RSB is not new, check whether STYLE, FLOWSPEC
or SCOPE objects have changed; if so, copy changed object or SCOPE objects have changed; if so, copy changed object
into RSB and turn on the NeworMod flag. into RSB and turn on the NeworMod flag.
o If NeworMod flag is off, continue with the next flow o If the message contained a RESV_CONFIRM object, copy it
into the RSB and turn on NeworMod flag.
o If the NeworMod flag is off, continue with the next flow
descriptor in the Resv message, if any. descriptor in the Resv message, if any.
o Otherwise (the NeworMod flag is on, i.e., the active RSB is o Otherwise (the NeworMod flag is on, i.e., the active RSB is
new or modified), execute the UPDATE TRAFFIC CONTROL event new or modified), execute the UPDATE TRAFFIC CONTROL event
sequence (below). If the result is to modify the traffic sequence (below). If the result is to modify the traffic
control state, the Resv_Refresh_Needed flag will be turned control state, this sequence will turn on the
on and a RESV_EVENT upcall will be made to the application. Resv_Refresh_Needed flag and make a RESV_EVENT upcall to
any local application.
If the UPDATE TRAFFIC CONTROL sequence fails with an error,
then delete a new RSB but restore the original reservation
in an old RSB.
o Continue with the next flow descriptor. o Continue with the next flow descriptor.
o When all flow descriptors have been processed, check the o When all flow descriptors have been processed, check the
Resv_Refresh_Needed flag. If it is now on, execute the Resv_Refresh_Needed flag. If it is now on, execute the
Resv REFRESH sequence (below) for each PHOP in Resv REFRESH sequence (below) for each PHOP in
Refresh_PHOP_list. Refresh_PHOP_list.
o Drop the Resv message and return. o Drop the Resv message and return.
If processing a Resv message finds an error, a ResvErr message If processing a Resv message finds an error, a ResvErr message
is created containing flow descriptor and an ERRORS object. The is created containing flow descriptor and an ERRORS object. The
Error Node field of the ERRORS object is set to the IP address Error Node field of the ERRORS object is set to the IP address
of OI, and the message is sent unicast to NHOP. of OI, and the message is sent unicast to NHOP.
ResvTear MESSAGE ARRIVES ResvTear MESSAGE ARRIVES
Processing of a ResvTear message roughly parallels the
processing of the corresponding Resv message
A ResvTear message arrives with an IP destination address A ResvTear message arrives with an IP destination address
matching outgoing interface OI. Flags Tear_Needed and matching outgoing interface OI. Flag Resv_Refresh_Needed is
Resv_Refresh_Needed are initially off and Refresh_PHOP_list is initially off and Refresh_PHOP_list is empty.
empty.
o Process the STYLE object and the flow descriptor list in o Determine the Outgoing Interface OI
the ResvTear message to tear down local reservation state,
as follows. We assume a filter spec list struct Filtss, of The logical outgoing interface OI is taken from the LIH in
type FILTER_SPEC* (defined earlier). the NHOP object. (If the physical interface is not implied
by the LIH, it can be learned from the interface matching
the IP destination address).
o Process the flow descriptor list in the ResvTear message to
tear down local reservation state, as follows, depending
upon the style. The following uses a filter spec list
struct Filtss of type FILTER_SPEC* (defined earlier).
For FF style: execute the following steps independently for For FF style: execute the following steps independently for
each flow descriptor in the message, i.e., for each each flow descriptor in the message, i.e., for each
(FLOWSPEC, Filtss) pair. Here the structure Filtss (FLOWSPEC, Filtss) pair. Here the structure Filtss
consists of the FILTER_SPEC from the flow descriptor. consists of the FILTER_SPEC from the flow descriptor.
For SE style, execute the following steps once for For SE style, execute the following steps once for
(FLOWSPEC, Filtss), with Filtss consisting of the list of (FLOWSPEC, Filtss), with Filtss consisting of the list of
FILTER_SPEC objects from the flow descriptor. FILTER_SPEC objects from the flow descriptor.
For WF style, execute the following steps once for For WF style, execute the following steps once for
(FLOWSPEC, Filtss), with Filtss an empty list. (FLOWSPEC, Filtss), with Filtss an empty list.
1. Find matching RSB for the triple: (SESSION, NHOP, 1. Find an RSB matching (SESSION, PHOP). If the style is
Filtss); call this the active RSB. If no active RSB distinct, Filtss is also used in the selection. Call
is found, continue with next flow descriptor. this the "active RSB". If no active RSB is found,
continue with next flow descriptor.
2. Delete the active RSB. 2. Check the style
3. Execute the event sequence UPDATE TRAFFIC CONTROL If the active RSB has a style that is incompatible
with the style of the message, drop the ResvTear
message and return.
3. Delete from the active RSB each FILTER_SPEC that
matches a FILTER_SPEC in Filtss.
4. If all FILTER_SPECs have now been deleted from the
active RSB, delete the active RSB.
5. Execute the UPDATE TRAFFIC CONTROL event sequence
(below) to update the traffic control state to be (below) to update the traffic control state to be
consistent with the reservation state. consistent with the reservation state. If the result
is to modify the traffic control state, the
Resv_Refresh_Needed flag will be turned on and a
RESV_EVENT upcall will be made to any local
application.
4. Search for a TCSB remaining for the (session, OI, 6. Continue with the next flow descriptor.
Filtss) triple; if not, set the Tear_Needed flag on.
5. Continue with the next flow descriptor. o All flow descriptors have been processed.
o If Tear_Needed and Resv_Refresh_Needed flags are both off, Build and send any ResvTear messages to be forwarded, in
then drop the ResvTear message and return. the following manner.
o If Tear_Needed is off but Resv_Refresh_Needed is on, then 1. Select each PSB that routes to the outgoing interface
execute the Resv REFRESH sequence for each PHOP in OI.
Refresh_PHOP_list, drop the ResvTear message, and return.
o Otherwise (Tear_Needed is on), need to forward ResvTear 2. Select a flow descriptor Fj in the ResvTear message
and/or Resv refresh messages. whose FILTER_SPEC matches the SENDER_TEMPLATE in the
PSB, and do the following. However, if no match is
found, return to the previous step to select the next
PSB.
Do the following for each PSB whose OutInterface_list - Search for an RSB for outgoing interface OI whose
includes the outgoing interface OI: FILTER_SPEC matches the PSB.
1. Pick each flow descriptor Fj in the ResvTear message - If an RSB is found and if the Resv_Refresh_Needed
whose FILTER_SPEC matches the PSB, and do the flag is on, add the PHOP of the PSB to the
following. Refresh_PHOP_list.
- If there is no RSB whose FILTER_SPEC matches the - If no such RSB is found then add Fj to the new
PSB, then add Fj to the new ResvTear message ResvTear message being built, in a manner
being built. appropriate to the style.
- Otherwise (there is a matching RSB), note the PSB - Continue with the next PSB.
as needing a Resv refresh message and set the
Resv_Refresh_Needed flag True.
2. If the new ResvTear message contains any flow 3. If the next PSB is for a different PHOP or the last
descriptors, send it to PHOP in the PSB. PSB has been processed, forward any ResvTear message
that has been built.
o If the Resv_Refresh_Needed flag is now on, execute the RESV o If any PSB's were found in the preceding step, and if the
Resv_Refresh_Needed flag is now on, execute the Resv
REFRESH sequence (below) for each PHOP in REFRESH sequence (below) for each PHOP in
Refresh_PHOP_list. Refresh_PHOP_list.
o Drop the ResvTear message and return. o Drop the ResvTear message and return.
ResvErr MESSAGE ARRIVES ResvErr MESSAGE ARRIVES
A ResvErr message arrives through the (real) incoming interface A ResvErr message arrives through the (real) incoming interface
In_If. In_If.
skipping to change at page 81, line 26 skipping to change at page 82, line 9
filter_spec), for each filter_spec contained in the filter_spec), for each filter_spec contained in the
filter spec list of the flow descriptor. filter spec list of the flow descriptor.
2. For each BSB in the preceding step, set (or replace) 2. For each BSB in the preceding step, set (or replace)
its FLOWSPEC Qb with FLOWSPEC from the message, and its FLOWSPEC Qb with FLOWSPEC from the message, and
set (or reset) its timer Tb to Kb*R seconds [Section set (or reset) its timer Tb to Kb*R seconds [Section
3.4]. If the BSB is new, set its PHOP value, and set 3.4]. If the BSB is new, set its PHOP value, and set
its Sender_Template equal to the appropriate its Sender_Template equal to the appropriate
filter_spec from the message. filter_spec from the message.
3. Partially execute the Resv REFRESH event sequence 3. Execute the Resv REFRESH event sequence (shown below)
shown below, for the previous hop PHOP. for the previous hop PHOP, but only with the B_Merge
flag off. That is, if processing in the Resv REFRESH
In particular, execute the refresh sequence with the sequence reaches the point of turning the B_Merge flag
B_Merge flag off. If this results in no refresh on (because all matching reservations are blockaded),
messages being generated, because all matching do not turn it on but instead exit the REFRESH
reservations are blockaded, do not turn B_Merge on but sequence and return here.
instead exit the refresh sequence and return here.
o For all ResvErr messages, execute the following for each o Execute the following for each RSB for this session whose
RSB for this session whose OI differs from In_If and whose OI differs from In_If and whose Filter_spec_list has at
Filter_spec_list has at least one filter spec in common least one filter spec in common with the FILTER_SPEC* in
with the FILTER_SPEC* in the ResvErr message. For WF the ResvErr message. For WF style, empty FILTER_SPEC*
style, empty FILTER_SPEC* structures are assumed to match. structures are assumed to match.
1. If Error_Code = 01 and the InPlace flag is 1 and one 1. If Error_Code = 01 and the InPlace flag in the
or more of the BSB's found/created above has a Qb that ERROR_SPEC is 1 and one or more of the BSB's
is strictly greater than Flowspec in the RSB, then found/created above has a Qb that is strictly greater
continue with the next matching RSB, if any. than Flowspec in the RSB, then continue with the next
matching RSB, if any.
2. If NHOP in the RSB is the local API, then: 2. If NHOP in the RSB is the local API, then:
- If the FLOWSPEC in the ResvErr message is - If the FLOWSPEC in the ResvErr message is
strictly greater than the RSB Flowspec, then turn strictly greater than the RSB Flowspec, then turn
on the NotGuilty flag in the ERROR_SPEC. on the NotGuilty flag in the ERROR_SPEC.
- Deliver an error upcall to application: - Deliver an error upcall to application:
Call: <Upcall_Proc>( session-id, RESV_ERROR, Call: <Upcall_Proc>( session-id, RESV_ERROR,
Error_code, Error_value, Error_code, Error_value,
Node_Addr, Error_flags, Node_Addr, Error_flags,
Flowspec, Filter_Spec_List, Flowspec, Filter_Spec_List
[Policy_data] ) [ , Policy_data] )
and continue with the next RSB. and continue with the next RSB.
3. If the style has wildcard sender selection, use the 3. If the style has wildcard sender selection, use the
SCOPE object SC.In from the ResvErr message to SCOPE object SC.In from the ResvErr message to
construct a SCOPE object SC.Out to be forwarded. construct a SCOPE object SC.Out to be forwarded.
SC.Out should contain those sender addresses that SC.Out should contain those sender addresses that
appeared in SC.In and that route to OI [LIH?], as appeared in SC.In and that route to OI, as determined
determined by scanning the PSB's. If SC.Out is empty, by scanning the PSB's. If SC.Out is empty, continue
continue with the next RSB. with the next RSB.
4. Create a new ResvErr message containing the error flow 4. Create a new ResvErr message containing the error flow
descriptor and send to the NHOP address specified by descriptor and send to the NHOP address specified by
the RSB. Include SC.Out if the style has wildcard the RSB. Include SC.Out if the style has wildcard
sender selection. sender selection.
5. Continue with the next RSB. 5. Continue with the next RSB.
o Drop the ResvErr message and return. o Drop the ResvErr message and return.
skipping to change at page 82, line 42 skipping to change at page 83, line 28
o If the (unicast) IP address found in the RESV_CONFIRM o If the (unicast) IP address found in the RESV_CONFIRM
object in the ResvConf message matches an interface of the object in the ResvConf message matches an interface of the
node, a confirmation upcall is made to the matching node, a confirmation upcall is made to the matching
application: application:
Call: <Upcall_Proc>( session-id, RESV_CONFIRM, Call: <Upcall_Proc>( session-id, RESV_CONFIRM,
Error_code, Error_value, Node_Addr, Error_code, Error_value, Node_Addr,
LUB-Used, nlist, Flowspec, LUB-Used, nlist, Flowspec,
Filter_Spec_List, NULL, NULL ) Filter_Spec_List, NULL, NULL )
o Otherwise, the ResvConf message is forwarded immediately to o Otherwise, forward the ResvConf message to the IP address
the address in the IP address in its RESV_CONFIRM object. in its RESV_CONFIRM object.
o Drop the ResvConf message and return. o Drop the ResvConf message and return.
UPDATE TRAFFIC CONTROL UPDATE TRAFFIC CONTROL
The sequence is invoked by the Path MESSAGE ARRIVES or the Resv
MESSAGE ARRIVES sequence, to (re-)calculate and adjust the local The sequence is invoked by many of the message arrival sequences
traffic control state in accordance with the current reservation to set or adjust the local traffic control state in accordance
and path state. An implicit parameter of this sequence is the with the current reservation and path state. An implicit
`active' RSB. parameter of this sequence is the `active' RSB.
If the result is to modify the traffic control state, this If the result is to modify the traffic control state, this
sequence turns on the Resv_Refresh_Needed flag and notifies any sequence notifies any matching local applications with a
matching local applications with a RESV_EVENT upcall. RESV_EVENT upcall. If the state change is such that it should
trigger immediate Resv refresh messages, it also turns on the
Resv_Refresh_Needed flag.
o Compute the traffic control parameters using the following o Compute the traffic control parameters using the following
steps. steps.
1. Consider the set of RSB's matching SESSION, 1. Consider the set of RSB's matching SESSION,
Filter_spec_list, and OI from the active RSB. Filter_spec_list, and OI from the active RSB.
Initially the local flag Is_Biggest is off. Initially the local flag Is_Biggest is off.
- Compute the effective kernel flowspec, - Compute the effective kernel flowspec,
TC_Flowspec, as the LUB of the FLOWSPEC values in TC_Flowspec, as the LUB of the FLOWSPEC values in
skipping to change at page 84, line 16 skipping to change at page 85, line 4
1. Store TC_Flowspec, TC_Filter_Spec*, Path_Te, and the 1. Store TC_Flowspec, TC_Filter_Spec*, Path_Te, and the
police flags into TCSB. police flags into TCSB.
2. Turn the Resv_Refresh_Needed flag on and make the 2. Turn the Resv_Refresh_Needed flag on and make the
traffic control call: traffic control call:
TC_AddFlowspec( OI, TC_Flowspec, TC_AddFlowspec( OI, TC_Flowspec,
Path_Te, police_flags) Path_Te, police_flags)
-> Rhandle, Fwd_Flowspec -> Rhandle, Fwd_Flowspec
3. If this call fails, build and send a ResvErr message 3. If this call fails, build and send a ResvErr message
specifying "Admission control failed" and with the specifying "Admission control failed" and with the
InPlace flag off. Delete any RESV_CONFIRM object from InPlace flag off. Delete the TCSB, delete any
the active RSB and return. RESV_CONFIRM object from the active RSB, and return.
4. Otherwise (call succeeds), record Rhandle and 4. Otherwise (call succeeds), record Rhandle and
Fwd_Flowspec in the TCSB. For each filter_spec F in Fwd_Flowspec in the TCSB. For each filter_spec F in
TC_Filter_Spec*, call: TC_Filter_Spec*, call:
TC_AddFilter( OI, Rhandle, Session, F) TC_AddFilter( OI, Rhandle, Session, F)
-> Fhandle -> Fhandle
and record the returned Fhandle in the TCSB. and record the returned Fhandle in the TCSB.
o Otherwise, if TCSB is not new but no effective kernel
flowspec TC_Flowspec was computed earlier, then:
1. Turn on the Resv_Refresh_Needed flag.
2. Call traffic control to delete the reservation:
TC_DelFlowspec( OI, Rhandle )
3. Delete the TCSB and return.
o Otherwise, if TCSB is not new but the TC_Flowspec, Path_Te, o Otherwise, if TCSB is not new but the TC_Flowspec, Path_Te,
and/or police flags just computed differ from corresponding and/or police flags just computed differ from corresponding
values in the TCSB, then: values in the TCSB, then:
1. Turn the Resv_Refresh_Needed flag on and make the 1. If the TC_Flowspec and/or Path_Te values differ, turn
traffic control call: the Resv_Refresh_Needed flag on.
2. Call traffic control to modify the reservation:
TC_ModFlowspec( OI, Rhandle, TC_Flowspec, TC_ModFlowspec( OI, Rhandle, TC_Flowspec,
Path_Te, police_flags ) Path_Te, police_flags )
-> Fwd_Flowspec -> Fwd_Flowspec
2. If this call fails, build and send a ResvErr message 3. If this call fails, build and send a ResvErr message
specifying "Admission control failed" and with the specifying "Admission control failed" and with the
InPlace bit on. Delete any RESV_CONFIRM object from InPlace bit on. Delete any RESV_CONFIRM object from
the active RSB and return. the active RSB and return.
3. Otherwise (the call succeeds), update the TCSB with 4. Otherwise (the call succeeds), update the TCSB with
the new values and save Fwd_Flowspec in the TCSB. the new values and save Fwd_Flowspec in the TCSB.
o Otherwise, if the TCSB is not new but the TC_Filter_Spec* o If the TCSB is not new but the TC_Filter_Spec* just
just computed differs from the FILTER_SPEC* in the TCSB, computed differs from the FILTER_SPEC* in the TCSB, then:
then:
1. Turn on the Resv_Refresh_Needed flag.
2. Make an appropriate set of TC_DelFilter and 1. Make an appropriate set of TC_DelFilter and
TC_AddFilter calls to transform the Filter_spec_list TC_AddFilter calls to transform the Filter_spec_list
in the TCSB into the new TC_Filter_Spec*. in the TCSB into the new TC_Filter_Spec*.
o If the active RSB contains a RESV_CONFIRM object, then: o If the active RSB contains a RESV_CONFIRM object, then:
1. If the Is_Biggest flag is on, move the RESV_CONFIRM 1. If the Is_Biggest flag is on, move the RESV_CONFIRM
object into the TCSB and turn on the object into the TCSB and turn on the
Resv_Refresh_Needed flag. (This will invoke the Resv Resv_Refresh_Needed flag. (This will later cause the
REFRESH sequence, which will either forward or return Resv REFRESH sequence to be invoked, which will either
the RESV_CONFIRM object, deleting it from the TCSB forward or return the RESV_CONFIRM object, deleting it
again). from the TCSB in either case).
2. Otherwise, create and send a ResvConf message to the 2. Otherwise, create and send a ResvConf message to the
address in the RESV_CONFIRM object. Include the address in the RESV_CONFIRM object. Include the
RESV_CONFIRM object in the ResvConf message. The RACK RESV_CONFIRM object in the ResvConf message. The
message should also include an ERROR_SPEC object whose ResvConf message should also include an ERROR_SPEC
Error_Node parameter is IP address of OI from the TCSB object whose Error_Node parameter is IP address of OI
and that specifies "No Error". from the TCSB and that specifies "No Error".
o If the Resv_Refresh_Needed flag is on, make a RESV_EVENT o If the Resv_Refresh_Needed flag is on and the RSB is not
upcall to the application: from the API, make a RESV_EVENT upcall to any matching
application:
Call: <Upcall_Proc>( session-id, RESV_EVENT, Call: <Upcall_Proc>( session-id, RESV_EVENT,
style, Flowspec, Filter_spec_list, style, Flowspec, Filter_spec_list
[POLICY_DATA] ) [ , POLICY_DATA] )
where Flowspec and Filter_spec_list come from the TCSB and where Flowspec and Filter_spec_list come from the TCSB and
the style comes from the active RSB. the style comes from the active RSB.
o Return to the event sequence that invoked this one. o Return to the event sequence that invoked this one.
Path REFRESH Path REFRESH
This sequence sends a path refresh for a particular sender, This sequence sends a path refresh for a particular sender,
i.e., a PSB. This sequence may be entered by either the i.e., a PSB. This sequence may be entered by either the
expiration of the path refresh timer or directly as the result expiration of a refresh timer or directly as the result of the
of the Path_Refresh_Needed flag being turned on during the Path_Refresh_Needed flag being turned on during the processing
processing of a received Path message. of a received Path message.
o Insert TIME_VALUES object into the Path message being o Insert TIME_VALUES object into the Path message being
built. Compute the IP TTL for the Path message as one less built. Compute the IP TTL for the Path message as one less
than the TTL value received in the message. However, if than the TTL value received in the message. However, if
the result is zero, return without sending the Path the result is zero, return without sending the Path
message. message.
o Create a sender descriptor containing the SENDER_TEMPLATE, o Create a sender descriptor containing the SENDER_TEMPLATE,
SENDER_TSPEC, and POLICY_DATA objects, if present in the SENDER_TSPEC, and POLICY_DATA objects, if present in the
PSB, and pack it into the Path message being built. PSB, and pack it into the Path message being built.
o Send a copy of the Path message to each interface OI in o Send a copy of the Path message to each interface OI in
OutInterfact_list. Before sending each copy: OutInterface_list. Before sending each copy:
1. If the PSB has the E_Police flag on and if interface 1. If the PSB has the E_Police flag on and if interface
OI is not capable of policing, turn the E_Police flag OI is not capable of policing, turn the E_Police flag
on in the Path message being built. on in the Path message being built.
2. Pass any ADSPEC and SENDER_TSPEC objects present in 2. Pass any ADSPEC and SENDER_TSPEC objects present in
the PSB to the traffic control call TC_Advertise. the PSB to the traffic control call TC_Advertise.
Insert the modified ADSPEC object that is returned Insert the modified ADSPEC object that is returned
into the Path message being built. into the Path message being built.
3. Insert into its PHOP object the interface address and 3. Insert into its PHOP object the interface address and
the LIH for the interface. the LIH for the interface.
Resv REFRESH Resv REFRESH
This sequence sends a reservation refresh towards a particular This sequence sends a reservation refresh towards a particular
previous hop with IP address PH. This sequence may be entered previous hop with IP address PH. This sequence may be entered
by the expiration of a reservation refresh timer, or invoked by the expiration of a refresh timer, or invoked from the Path
from the Path MESSAGE ARRIVES, Resv MESSAGE ARRIVES, or ResvErr MESSAGE ARRIVES, Resv MESSAGE ARRIVES, ResvTear MESSAGE ARRIVES,
MESSAGE ARRIVES sequence. or ResvErr MESSAGE ARRIVES sequence.
In general, this sequence considers each of the PSB's with PHOP In general, this sequence considers each of the PSB's with PHOP
address PH. For a given PSB, it scans the TCSBs for matching address PH. For a given PSB, it scans the TCSBs for matching
reservations and merges the styles, FLOWSPECs and reservations and merges the styles, FLOWSPECs and
Filter_spec_list's appropriately. It then builds a Resv message Filter_spec_list's appropriately. It then builds a Resv message
and sends it to PH. The details depend upon the attributes of and sends it to PH. The details depend upon the attributes of
the style(s) included in the reservations. the style(s) included in the reservations.
Initially the Need_Scope flag is off and the new_SCOPE object is Initially the Need_Scope flag is off and the new_SCOPE object is
empty. empty.
skipping to change at page 87, line 22 skipping to change at page 88, line 20
one PHOP and if the multicast routing protocol does not use one PHOP and if the multicast routing protocol does not use
shared trees, set the Need_Scope flag on. shared trees, set the Need_Scope flag on.
o Select each sender PSB whose PHOP has address PH. Set the o Select each sender PSB whose PHOP has address PH. Set the
local flag B_Merge off and execute the following steps. local flag B_Merge off and execute the following steps.
1. Select all TCSB's whose Filter_spec_list's match the 1. Select all TCSB's whose Filter_spec_list's match the
SENDER_TEMPLATE object in the PSB and whose OI appears SENDER_TEMPLATE object in the PSB and whose OI appears
in the OutInterface_list of the PSB. in the OutInterface_list of the PSB.
2. If B_Merge flag is off then ignore a blockaded TCSB, 2. If the PSB is from the API, then:
- If TCSB contains a CONFIRM object, then create
and send a ResvConf message containing the object
and delete the CONFIRM object from the TCSB.
- Continue with next PSB.
3. If B_Merge flag is off then ignore a blockaded TCSB,
as follows. as follows.
- Select BSB's that match this TCSB. If any of - Select BSB's that match this TCSB. If any of
these BSB's has a Qb that is not strictly larger these BSB's has a Qb that is not strictly larger
than TC_Flowspec, then continue processing with than TC_Flowspec, then continue processing with
the next TCSB. the next TCSB.
However, if steps 1 and 2 result in finding that all However, if steps 1 and 2 result in finding that all
TCSB's matching this PSB are blockaded, then: TCSB's matching this PSB are blockaded, then:
- If this Resv REFRESH sequence was invoked from - If this Resv REFRESH sequence was invoked from
RESV ERROR RECEIVED, then return to the latter. Resv ERROR RECEIVED, then return to the latter.
- Otherwise, turn on the B_Merge flag and restart - Otherwise, turn on the B_Merge flag and restart
at step 1, immediately above. at step 1, immediately above.
3. Merge the flowspecs from this set of TCSB's, as 4. Merge the flowspecs from this set of TCSB's, as
follows: follows:
- If B_Merge flag is off, compute the LUB over the - If B_Merge flag is off, compute the LUB over the
flowspec objects. From each TCSB, use the flowspec objects. From each TCSB, use the
Fwd_Flowspec object if present, else use the Fwd_Flowspec object if present, else use the
normal Flowspec object. normal Flowspec object.
While computing the LUB, check for a RESV_CONFIRM While computing the LUB, check for a RESV_CONFIRM
object in each TCSB. If a RESV_CONFIRM object is object in each TCSB. If a RESV_CONFIRM object is
found: found:
skipping to change at page 88, line 23 skipping to change at page 89, line 30
should also include an ERROR_SPEC object should also include an ERROR_SPEC object
whose Error_Node parameter is IP address of whose Error_Node parameter is IP address of
OI from the TCSB and specifying "No Error". OI from the TCSB and specifying "No Error".
- Delete the RESV_CONFIRM object from the - Delete the RESV_CONFIRM object from the
TCSB. TCSB.
- Otherwise (B_Merge flag is on), compute the GLB - Otherwise (B_Merge flag is on), compute the GLB
over the Flowspec objects of this set of TCSB's. over the Flowspec objects of this set of TCSB's.
While computing the GLB, check for a RESV_CONFIRM While computing the GLB, delete any RESV_CONFIRM
object in each TCSB. If one is found, delete it. object object in any of these TCSB's.
4. (All matching TCSB's have been processed). The next 5. (All matching TCSB's have been processed). The next
step depends upon the style attributes. step depends upon the style attributes.
Distinct reservation (FF) style Distinct reservation (FF) style
Use the Sender_Template as the merged Use the Sender_Template as the merged
FILTER_SPEC. Pack the merged (FLOWSPEC, FILTER_SPEC. Pack the merged (FLOWSPEC,
FILTER_SPEC, F_POLICY_DATA) triplet into the FILTER_SPEC, F_POLICY_DATA) triplet into the
message as a flow descriptor. message as a flow descriptor.
Shared wildcard reservation (WF) style Shared wildcard reservation (WF) style
skipping to change at page 88, line 43 skipping to change at page 90, line 4
FILTER_SPEC, F_POLICY_DATA) triplet into the FILTER_SPEC, F_POLICY_DATA) triplet into the
message as a flow descriptor. message as a flow descriptor.
Shared wildcard reservation (WF) style Shared wildcard reservation (WF) style
There is no merged FILTER_SPEC. Merge (compute There is no merged FILTER_SPEC. Merge (compute
the LUB of) the merged FLOWSPECS from the TCSB's, the LUB of) the merged FLOWSPECS from the TCSB's,
across all PSB's for PH. across all PSB's for PH.
Shared distinct reservation (SE) style Shared distinct reservation (SE) style
Using the Sender_Template as the merged Using the Sender_Template as the merged
FILTER_SPEC, form the union of the FILTER_SPECS FILTER_SPEC, form the union of the FILTER_SPECS
obtained from the TCSB's. Merge (compute the LUB obtained from the TCSB's. Merge (compute the LUB
of) the merged FLOWSPECS from the TCSB's, across of) the merged FLOWSPECS from the TCSB's, across
all PSB's for PH. all PSB's for PH.
5. If the Need_Scope flag is on and the sender specified 6. If the Need_Scope flag is on and the sender specified
by the PSB is not the local API: by the PSB is not the local API:
- Find each RSB that matches this PSB, i.e., whose - Find each RSB that matches this PSB, i.e., whose
Filter_spec_list matches Sender_Template in the Filter_spec_list matches Sender_Template in the
PSB and whose OI is included in PSB and whose OI is included in
OutInterface_list. OutInterface_list.
- If the RSB either has no SCOPE list or its SCOPE - If the RSB either has no SCOPE list or its SCOPE
list includes the sender IP address from the PSB, list includes the sender IP address from the PSB,
insert the sender IP address into new_SCOPE. insert the sender IP address into new_SCOPE.
skipping to change at page 89, line 28 skipping to change at page 90, line 33
message. message.
1. If Need_Scope flag is on but new_SCOPE is empty, no 1. If Need_Scope flag is on but new_SCOPE is empty, no
RESV message should be sent; return. Otherwise, if RESV message should be sent; return. Otherwise, if
Need_Scope is on, move new_SCOPE into the message. Need_Scope is on, move new_SCOPE into the message.
2. If a shared reservation style is being built, move the 2. If a shared reservation style is being built, move the
final merged FLOWSPEC object and filter spec list into final merged FLOWSPEC object and filter spec list into
the message. the message.
3. If a RESV_CONFIRM object was saved earlier, copy it 3. If a RESV_CONFIRM object was saved earlier, move it
into the new Resv message. into the new Resv message.
4. Set the RSVP_HOP object in the message to contain the 4. Set the RSVP_HOP object in the message to contain the
IncInterface address through which it will be sent and IncInterface address through which it will be sent and
the LIH from (one of) the PSB's. the LIH from (one of) the PSB's.
o Send the message to the address PH. o Send the message to the address PH.
ROUTE CHANGE NOTIFICATION ROUTE CHANGE NOTIFICATION
skipping to change at page 90, line 31 skipping to change at page 91, line 38
implementation of RSVP and successfully demonstrated it in May 1993. implementation of RSVP and successfully demonstrated it in May 1993.
Shai Herzog, and later Steve Berson, continued development of RSVP Shai Herzog, and later Steve Berson, continued development of RSVP
prototypes. prototypes.
Since 1993, many members of the Internet research community have Since 1993, many members of the Internet research community have
contributed to the design and development of RSVP; these include (in contributed to the design and development of RSVP; these include (in
alphabetical order) Steve Berson, Bob Braden, Lee Breslau, Dave alphabetical order) Steve Berson, Bob Braden, Lee Breslau, Dave
Clark, Deborah Estrin, Shai Herzog, Craig Partridge, Scott Shenker, Clark, Deborah Estrin, Shai Herzog, Craig Partridge, Scott Shenker,
John Wroclawski, and Daniel Zappala. In addition, a number of host John Wroclawski, and Daniel Zappala. In addition, a number of host
and router vendors have made valuable contributions, particularly and router vendors have made valuable contributions, particularly
Fred Baker (Cisco), Mark Baugher (Intel), Don Hoffman (Sun), Steve Fred Baker (Cisco), Mark Baugher (Intel), Lou Berger (Fore Systems),
Jakowski (NetManage), John Krawczyk (Bay Networks), and Bill Nowicki Don Hoffman (Sun), Steve Jakowski (NetManage), John Krawczyk (Bay
(SGI). Ron Frederick, Bobby Minnear, Eve Schooler, and Garrett Networks), and Bill Nowicki (SGI). Ron Frederick, Bobby Minnear, Eve
Wollman did early interfacing of multicast applications to RSVP. Schooler, and Garrett Wollman did early interfacing of multicast
Steve Deering, Bill Fenner, and Ajit Thyagarajan helped with the applications to RSVP. Steve Deering, Bill Fenner, and Ajit
interface between RSVP and multicast routing. Thyagarajan helped with the interface between RSVP and multicast
routing.
APPENDIX A. Object Definitions APPENDIX A. Object Definitions
C-Types are defined for the two Internet address families IPv4 and C-Types are defined for the two Internet address families IPv4 and
IPv6. To accommodate other address families, additional C-Types IPv6. To accommodate other address families, additional C-Types
could easily be defined. These definitions are contained as an could easily be defined. These definitions are contained as an
Appendix, to ease updating. Appendix, to ease updating.
All unused fields should be sent as zero and ignored on receipt. All unused fields should be sent as zero and ignored on receipt.
skipping to change at page 92, line 36 skipping to change at page 93, line 36
along the path. along the path.
0x20 = Maybe_RSVP flag 0x20 = Maybe_RSVP flag
The Maybe_RSVP flag is turned on in the SESSION object The Maybe_RSVP flag is turned on in the SESSION object
of a Path message whenever the RSVP daemon is unable to of a Path message whenever the RSVP daemon is unable to
ascertain whether or not the previous hop included one ascertain whether or not the previous hop included one
or more non-RSVP-capable routers. This flag is or more non-RSVP-capable routers. This flag is
forwarded hop-by-hop and passed to a receiver forwarded hop-by-hop and passed to a receiver
application. If it is on and the Non_RSVP flag is off, application. If it is on and the Non_RSVP flag is off,
the application cannot tell whether or not a successful the application cannot tell whether or not the requested
reservation request may not install the requested QoS at QoS was installed at every node along the path.
every node along the path.
DstPort DstPort
The UDP/TCP destination port for the session. Zero may be The UDP/TCP destination port for the session. Zero may be
used to indicate `none'. used to indicate `none'.
Other SESSION C-Types could be defined in the future to Other SESSION C-Types could be defined in the future to
support other demultiplexing conventions in the transport- support other demultiplexing conventions in the transport-
layer or application layer. layer or application layer.
skipping to change at page 100, line 8 skipping to change at page 101, 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, as follows: style, 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.
o Class = 9, C-Type = 2: int-serv flowspec o Inv-serv Flowspec object: Class = 9, C-Type = 2
The contents of this object will be specified in documents The contents and encoding rules for this object are specified
prepared by the int-serv working group. in documents prepared by the int-serv working group.
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) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 103, line 17 skipping to change at page 104, line 17
SENDER_TEMPLATE class = 11. SENDER_TEMPLATE class = 11.
o IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = 1 o IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = 1
Definition same as IPv4/UDP FILTER_SPEC object. Definition same as IPv4/UDP FILTER_SPEC object.
o IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = 2 o IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = 2
Definition same as IPv6/UDP FILTER_SPEC object. Definition same as IPv6/UDP FILTER_SPEC object.
o IPv6 Flow-label SENDER_TEMPLATE object: Class = 11, C-Type =
3
A.11 SENDER_TSPEC Class A.11 SENDER_TSPEC Class
SENDER_TSPEC class = 12. SENDER_TSPEC class = 12.
o Intserv SENDER_TSPEC object: Class = 12, C-Type = 1 o Intserv SENDER_TSPEC object: Class = 12, C-Type = 2
The contents of this object are specified in service The contents and encoding rules for this object are specified
specification documents prepared by the int-serv working in documents prepared by the int-serv working group.
group.
A.12 ADSPEC Class A.12 ADSPEC Class
ADSPEC class = 13. ADSPEC class = 13.
o Intserv ADSPEC object: Class = 13, C-Type = 2 o Intserv ADSPEC object: Class = 13, C-Type = 2
The contents of this object are specified in service The contents and format for this object are specified in
specification documents prepared by the int-serv working documents prepared by the int-serv working group.
group.
A.13 POLICY_DATA Class A.13 POLICY_DATA Class
POLICY_DATA class = 14. POLICY_DATA class = 14.
o Type 1 POLICY_DATA object: Class = 14, C-Type = 1 o Type 1 POLICY_DATA object: Class = 14, C-Type = 1
The contents of this object are for further study. The contents of this object are for further study.
A.14 Resv_CONFIRM Class A.14 Resv_CONFIRM Class
skipping to change at page 108, line 18 skipping to change at page 108, line 18
The following globally-defined sub-codes may appear in the low- The following globally-defined sub-codes may appear in the low-
order 12 bits when ssur = 0000: order 12 bits when ssur = 0000:
- Sub-code = 1: Delay bound cannot be met - Sub-code = 1: Delay bound cannot be met
- Sub-code = 2: Requested bandwidth unavailable - Sub-code = 2: Requested bandwidth unavailable
o Error Code = 02: Policy Control failure o Error Code = 02: Policy Control failure
Reservation has been rejected for administrative reasons, for Reservation or path message has been rejected for administrative
example, required credentials not submitted, insufficient quota reasons, for example, required credentials not submitted,
or balance, or administrative preemption. This Error Code may insufficient quota or balance, or administrative preemption.
appear in a PathErr or ResvErr message. This Error Code may appear in a PathErr or ResvErr message.
Contents of the Error Value field are to be determined in the Contents of the Error Value field are to be determined in the
future. future.
o Error Code = 03: No path information for this Resv message. o Error Code = 03: No path information for this Resv message.
No path state for this session. Resv message cannot be No path state for this session. Resv message cannot be
forwarded. forwarded.
o Error Code = 04: No sender information for this Resv message. o Error Code = 04: No sender information for this Resv message.
There is path state for this session, but it does not include There is path state for this session, but it does not include
the sender matching some flow descriptor contained in the Resv the sender matching some flow descriptor contained in the Resv
message. RESV message cannot be forwarded. message. Resv message cannot be forwarded.
o Error Code = 05: Conflicting reservation style o Error Code = 05: Conflicting reservation style
Reservation style conflicts with style(s) of existing Reservation style conflicts with style(s) of existing
reservation state. The Error Value field contains the low-order reservation state. The Error Value field contains the low-order
16 bits of the Option Vector of the existing style with which 16 bits of the Option Vector of the existing style with which
the conflict occurred. This Resv message cannot be forwarded. the conflict occurred. This Resv message cannot be forwarded.
o Error Code = 06: Unknown reservation style o Error Code = 06: Unknown reservation style
skipping to change at page 109, line 30 skipping to change at page 109, line 30
o Error Code = 12: Service preempted o Error Code = 12: Service preempted
The service request defined by the STYLE object and the flow The service request defined by the STYLE object and the flow
descriptor has been administratively preempted. descriptor has been administratively preempted.
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:
ssur cccc cccc cccc ssur cccc cccc cccc
Here the high-order bits ssur are as defined under Error Code Here the high-order bits ssur are as defined under Error Code
01. The following globally-defined sub-codes may appear in the 01. The globally-defined sub-codes that may appear in the low-
low-order 12 bits when ssur = 0000 are to be defined in the order 12 bits when ssur = 0000 are to be defined in the future.
future.
o Error Code = 13: Unknown object class o Error Code = 13: Unknown object class
Error Value contains 16-bit value composed of (Class-Num, C- Error Value contains 16-bit value composed of (Class-Num, C-
Type) of unknown object. This error should be sent only if RSVP Type) of unknown object. This error should be sent only if RSVP
is going to reject the message, as determined by the high-order is going to reject the message, as determined by the high-order
bits of the Class-Num. This Error Code may appear in a PathErr bits of the Class-Num. This Error Code may appear in a PathErr
or ResvErr message. or ResvErr message.
o Error Code = 14: Unknown object C-Type o Error Code = 14: Unknown object C-Type
skipping to change at page 110, line 21 skipping to change at page 110, line 20
format or contents of the request. This Resv message cannot be format or contents of the request. This Resv message cannot be
forwarded, and continued attempts would be futile. forwarded, and continued attempts would be futile.
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:
ss00 cccc cccc cccc ss00 cccc cccc cccc
Here the high-order bits ss are as defined under Error Code 01. Here the high-order bits ss are as defined under Error Code 01.
The following globally-defined sub-codes may appear in the low The following globally-defined sub-codes may appear in the low
order 12 bits (cccc cccc cccc) when ssr = 000: order 12 bits (cccc cccc cccc) when ss = 00:
- Sub-code = 01: Service conflict - Sub-code = 01: Service conflict
Trying to merge two incompatible service requests. Trying to merge two incompatible service requests.
- Sub-code = 02: Service unsupported - Sub-code = 02: Service unsupported
Traffic control can provide neither the requested service Traffic control can provide neither the requested service
nor an acceptable replacement. nor an acceptable replacement.
- Sub-code = 03: Bad Flowspec value - Sub-code = 03: Bad Flowspec value
Mal-formed or unreasonable request. Mal-formed or unreasonable request.
- Sub-code = 04: Bad Tspec value - Sub-code = 04: Bad Tspec value
Mal-formed or unreasonable request. Malformed or unreasonable request.
o Error Code = 22: Traffic Control System error o Error Code = 22: Traffic Control System error
A system error was detected and reported by the traffic control A system error was detected and reported by the traffic control
modules. The Error Value will contain a system-specific value modules. The Error Value will contain a system-specific value
giving more information about the error. RSVP is not expected giving more information about the error. RSVP is not expected
to be able to interpret this value. to be able to interpret this value.
o Error Code = 23: RSVP System error o Error Code = 23: RSVP System error
skipping to change at page 111, line 18 skipping to change at page 111, line 17
construction. Similarly, each node is required to verify the correct construction. Similarly, each node is required to verify the correct
construction of each RSVP message it receives. Should a programming construction of each RSVP message it receives. Should a programming
error allow an RSVP to create a malformed message, the error is not error allow an RSVP to create a malformed message, the error is not
generally reported to end systems in an ERROR_SPEC object; instead, generally reported to end systems in an ERROR_SPEC object; instead,
the error is simply logged locally, and perhaps reported through the error is simply logged locally, and perhaps reported through
network management mechanisms. network management mechanisms.
The only message formatting errors that are reported to end systems The only message formatting errors that are reported to end systems
are those that may reflect version mismatches, and which the end are those that may reflect version mismatches, and which the end
system might be able to circumvent, e.g., by falling back to a system might be able to circumvent, e.g., by falling back to a
previous CType for an object; see code 12 and 13 above. previous CType for an object; see code 13 and 14 above.
The choice of message formatting errors that an RSVP may detect and The choice of message formatting errors that an RSVP may detect and
log locally is implementation-specific, but it will typically include log locally is implementation-specific, but it will typically include
the following: the following:
o Wrong-length message: RSVP Length field does not match message o Wrong-length message: RSVP Length field does not match message
length. length.
o Unknown or unsupported RSVP version. o Unknown or unsupported RSVP version.
o Bad RSVP checksum o Bad RSVP checksum
o INTEGRITY failure
o Illegal RSVP message Type o Illegal RSVP message Type
o Illegal object length: not a multiple of 4, or less than 4. o Illegal object length: not a multiple of 4, or less than 4.
o Next hop/Previous hop address in HOP object is illegal. o Next hop/Previous hop address in HOP object is illegal.
o Conflicting source port: Source port is non-zero in a filter o Conflicting source port: Source port is non-zero in a filter
spec or sender template for a session with destination port spec or sender template for a session with destination port
zero. zero.
skipping to change at page 112, line 5 skipping to change at page 112, line 5
o Illegal object class (specify) in this message type. o Illegal object class (specify) in this message type.
o Violation of required object order o Violation of required object order
o Flow descriptor count wrong for style o Flow descriptor count wrong for style
o Logical Interface Handle invalid o Logical Interface Handle invalid
o Unknown object Class-Num. o Unknown object Class-Num.
o Destination address of ResvConf message does not match Receiver
Address in the RESV_CONFIRM object it contains.
APPENDIX C. UDP Encapsulation APPENDIX C. UDP Encapsulation
An RSVP implementation will generally require the ability to perform An RSVP implementation will generally require the ability to perform
"raw" network I/O, i.e., to send and receive IP datagrams using "raw" network I/O, i.e., to send and receive IP datagrams using
protocol 46. However, some important classes of host systems may not protocol 46. However, some important classes of host systems may not
support raw network I/O. To use RSVP, such hosts must encapsulate support raw network I/O. To use RSVP, such hosts must encapsulate
RSVP messages in UDP. RSVP messages in UDP.
The basic UDP encapsulation scheme makes two assumptions: The basic UDP encapsulation scheme makes two assumptions:
skipping to change at page 112, line 51 skipping to change at page 113, line 51
It is useful to define two flavors of UDP encapsulation, one to be It is useful to define two flavors of UDP encapsulation, one to be
sent by Hu and the other to be sent by Hr and R, to avoid double sent by Hu and the other to be sent by Hr and R, to avoid double
processing by the recipient. In practice, these two flavors are processing by the recipient. In practice, these two flavors are
distinguished by differing UDP port numbers Pu and Pu'. distinguished by differing UDP port numbers Pu and Pu'.
The following symbols are used in the tables. The following symbols are used in the tables.
o D is the DestAddress for the particular session. o D is the DestAddress for the particular session.
o G* is a well-known group address of the form 224.0.0.x, i.e., a o G* is a well-known group address of the form 224.0.0.14, i.e., a
group that is limited to the local connected network. [TO BE group that is limited to the local connected network.
DEFINED]
o Pu and Pu' are two well-known UDP ports for UDP encapsulation of o Pu and Pu' are two well-known UDP ports for UDP encapsulation of
RSVP. [TO BE DEFINED] RSVP, with values 1698 and 1699.
o Ra is the IP address of the router interface `a'. o Ra is the IP address of the router interface `a'.
o Tr is the TTL value of the specific Path message. o Tr is the TTL value of the specific Path message.
o Router interface `a' is on the local network connected to Hu and o Router interface `a' is on the local network connected to Hu and
Hr. Hr.
o [RA] indicates that the Router Alert option is sent. o [RA] indicates that the Router Alert option is sent.
skipping to change at page 115, line 13 skipping to change at page 116, line 13
receive TTL. This may be overridden by manual configuration. receive TTL. This may be overridden by manual configuration.
We have assumed that the first-hop RSVP-capable router R is on the We have assumed that the first-hop RSVP-capable router R is on the
directly-connected network. There are several possible approaches if directly-connected network. There are several possible approaches if
this is not the case. this is not the case.
1. Hu can send both unicast and multicast sessions to UDP(Ra,Pu) 1. Hu can send both unicast and multicast sessions to UDP(Ra,Pu)
with TTL=Ta with TTL=Ta
Here Ta must be the TTL to exactly reach R. If Ta is too small, Here Ta must be the TTL to exactly reach R. If Ta is too small,
the Path message will not reach R. If Ta is too large, the Path message will not reach R. If Ta is too large, R and
multicast routing in R will forward the UDP packet into the succeeding routers may forward the UDP packet until its hop
Internet until its hop count expires. This will turn on UDP count expires. This will turn on UDP encapsulation between
encapsulation between routers within the Internet, perhaps routers within the Internet, perhaps causing bogus UDP traffic.
causing bogus UDP traffic. The host Hu must be explicitly The host Hu must be explicitly configured with Ra and Ta.
configured with Ra and Ta.
2. A particular host on the LAN connected to Hu could be designated 2. A particular host on the LAN connected to Hu could be designated
as an "RSVP relay host". A relay host would listen on (G*,Pu) as an "RSVP relay host". A relay host would listen on (G*,Pu)
and forward any Path messages directly to R, although it would and forward any Path messages directly to R, although it would
not be in the data path. The relay host would have to be not be in the data path. The relay host would have to be
configured with Ra and Ta. configured with Ra and Ta.
References References
[Baker96] Baker, Fred, "RSVP Cryptographic Authentication", Work in [Baker96] Baker, F., "RSVP Cryptographic Authentication", Work in
Progress, February 1996. Progress, February 1996.
[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.
[FJ94] Floyd, S. and V. Jacobson, "Synchronization of Periodic Routing [FJ94] Floyd, S. and V. Jacobson, "Synchronization of Periodic Routing
Messages", IEEE/ACM Transactions on Networking, Vol. 2, No. 2, Messages", IEEE/ACM Transactions on Networking, Vol. 2, No. 2,
April, 1994. April, 1994.
skipping to change at page 116, line 6 skipping to change at page 117, line 4
1995. 1995.
[ISdata95] Wroclawski, J., "Standard Data Encoding for Integrated [ISdata95] Wroclawski, J., "Standard Data Encoding for Integrated
Services Objects", Work in Progress, November 1995. Services Objects", Work in Progress, November 1995.
[RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. [RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D.
Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network, Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network,
September 1993. September 1993.
[ServTempl95] Shenker, S., "Network Element Service Specification [ServTempl95] Shenker, S., "Network Element Service Specification
Template", Internet Draft draft-ietf-intserv-svc-template-00.txt, Template", Work in Progress, Integrated Services Working Group,
Integrated Services Working Group, March 1995. November 1995.
[OPWA95] Shenker, S. and L. Breslau, "Two Issues in Reservation [OPWA95] Shenker, S. and L. Breslau, "Two Issues in Reservation
Establishment", Proc. ACM SIGCOMM '95, Cambridge, MA, August 1995. Establishment", Proc. ACM SIGCOMM '95, Cambridge, MA, August 1995.
Security Considerations Security Considerations
See Section 2.8. See Section 2.8.
Authors' Addresses Authors' Addresses
Lixia Zhang
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304
Phone: (415) 812-4415
EMail: Lixia@PARC.XEROX.COM
Bob Braden Bob Braden
USC Information Sciences Institute USC Information Sciences Institute
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292 Marina del Rey, CA 90292
Phone: (310) 822-1511 Phone: (310) 822-1511
EMail: Braden@ISI.EDU EMail: Braden@ISI.EDU
Lixia Zhang
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304
Phone: (415) 812-4415
EMail: Lixia@PARC.XEROX.COM
Steve Berson Steve Berson
USC Information Sciences Institute USC Information Sciences Institute
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292 Marina del Rey, CA 90292
Phone: (310) 822-1511 Phone: (310) 822-1511
EMail: Berson@ISI.EDU EMail: Berson@ISI.EDU
Shai Herzog Shai Herzog
USC Information Sciences Institute USC Information Sciences Institute
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292 Marina del Rey, CA 90292
Palo Alto, CA 94304
Phone: (310) 822 1511 Phone: (310) 822 1511
EMail: Herzog@ISI.EDU EMail: Herzog@ISI.EDU
Sugih Jamin Sugih Jamin
Computer Science Department Computer Science Department
University of Southern California University of Southern California
Los Angeles, CA 90089-0871 Los Angeles, CA 90089-0871
Phone: (213) 740-6578 Phone: (213) 740-6578
 End of changes. 

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