📄 rfc2205.txt
字号:
exactly one sender, while in a wildcard sender-selection no filter
spec is needed.
Braden, Ed., et. al. Standards Track [Page 11]
RFC 2205 RSVP September 1997
Sender || Reservations:
Selection || Distinct | Shared
_________||__________________|____________________
|| | |
Explicit || Fixed-Filter | Shared-Explicit |
|| (FF) style | (SE) Style |
__________||__________________|____________________|
|| | |
Wildcard || (None defined) | Wildcard-Filter |
|| | (WF) Style |
__________||__________________|____________________|
Figure 3: Reservation Attributes and Styles
The following styles are currently defined (see Figure 3):
o Wildcard-Filter (WF) Style
The WF style implies the options: "shared" reservation and
"wildcard" sender selection. Thus, a WF-style reservation
creates a single reservation shared by flows from all
upstream senders. This reservation may be thought of as a
shared "pipe", whose "size" is the largest of the resource
requests from all receivers, independent of the number of
senders using it. A WF-style reservation is propagated
upstream towards all sender hosts, and it automatically
extends to new senders as they appear.
Symbolically, we can represent a WF-style reservation request
by:
WF( * {Q})
where the asterisk represents wildcard sender selection and Q
represents the flowspec.
o Fixed-Filter (FF) Style
The FF style implies the options: "distinct" reservations and
"explicit" sender selection. Thus, an elementary FF-style
reservation request creates a distinct reservation for data
packets from a particular sender, not sharing them with other
senders' packets for the same session.
Braden, Ed., et. al. Standards Track [Page 12]
RFC 2205 RSVP September 1997
Symbolically, we can represent an elementary FF reservation
request by:
FF( S{Q})
where S is the selected sender and Q is the corresponding
flowspec; the pair forms a flow descriptor. RSVP allows
multiple elementary FF-style reservations to be requested at
the same time, using a list of flow descriptors:
FF( S1{Q1}, S2{Q2}, ...)
The total reservation on a link for a given session is the
`sum' of Q1, Q2, ... for all requested senders.
o Shared Explicit (SE) Style
The SE style implies the options: "shared" reservation and
"explicit" sender selection. Thus, an SE-style reservation
creates a single reservation shared by selected upstream
senders. Unlike the WF style, the SE style allows a receiver
to explicitly specify the set of senders to be included.
We can represent an SE reservation request containing a
flowspec Q and a list of senders S1, S2, ... by:
SE( (S1,S2,...){Q} )
Shared reservations, created by WF and SE styles, are appropriate
for those multicast applications in which multiple data sources
are unlikely to transmit simultaneously. Packetized audio is an
example of an application suitable for shared reservations; since
a limited number of people talk at once, each receiver might issue
a WF or SE reservation request for twice the bandwidth required
for one sender (to allow some over-speaking). On the other hand,
the FF style, which creates distinct reservations for the flows
from different senders, is appropriate for video signals.
The RSVP rules disallow merging of shared reservations with
distinct reservations, since these modes are fundamentally
incompatible. They also disallow merging explicit sender
selection with wildcard sender selection, since this might produce
an unexpected service for a receiver that specified explicit
selection. As a result of these prohibitions, WF, SE, and FF
styles are all mutually incompatible.
Braden, Ed., et. al. Standards Track [Page 13]
RFC 2205 RSVP September 1997
It would seem possible to simulate the effect of a WF reservation
using the SE style. When an application asked for WF, the RSVP
process on the receiver host could use local state to create an
equivalent SE reservation that explicitly listed all senders.
However, an SE reservation forces the packet classifier in each
node to explicitly select each sender in the list, while a WF
allows the packet classifier to simply "wild card" the sender
address and port. When there is a large list of senders, a WF
style reservation can therefore result in considerably less
overhead than an equivalent SE style reservation. For this
reason, both SE and WF are included in the protocol.
Other reservation options and styles may be defined in the future.
1.4 Examples of Styles
This section presents examples of each of the reservation styles
and shows the effects of merging.
Figure 4 illustrates a router with two incoming interfaces,
labeled (a) and (b), through which flows will arrive, and two
outgoing interfaces, labeled (c) and (d), through which data will
be forwarded. This topology will be assumed in the examples that
follow. There are three upstream senders; packets from sender S1
(S2 and S3) arrive through previous hop (a) ((b), respectively).
There are also three downstream receivers; packets bound for R1
(R2 and R3) are routed via outgoing interface (c) ((d),
respectively). We furthermore assume that outgoing interface (d)
is connected to a broadcast LAN, i.e., that replication occurs in
the network; R2 and R3 are reached via different next hop routers
(not shown).
We must also specify the multicast routes within the node of
Figure 4. Assume first that data packets from each Si shown in
Figure 4 are routed to both outgoing interfaces. Under this
assumption, Figures 5, 6, and 7 illustrate Wildcard-Filter,
Fixed-Filter, and Shared-Explicit reservations, respectively.
Braden, Ed., et. al. Standards Track [Page 14]
RFC 2205 RSVP September 1997
________________
(a)| | (c)
( S1 ) ---------->| |----------> ( R1 )
| Router | |
(b)| | (d) |---> ( R2 )
( S2,S3 ) ------->| |------|
|________________| |---> ( R3 )
|
Figure 4: Router Configuration
For simplicity, these examples show flowspecs as one-dimensional
multiples of some base resource quantity B. The "Receives" column
shows the RSVP reservation requests received over outgoing
interfaces (c) and (d), and the "Reserves" column shows the
resulting reservation state for each interface. The "Sends"
column shows the reservation requests that are sent upstream to
previous hops (a) and (b). In the "Reserves" column, each box
represents one reserved "pipe" on the outgoing link, with the
corresponding flow descriptor.
Figure 5, showing the WF style, illustrates two distinct
situations in which merging is required. (1) Each of the two next
hops on interface (d) results in a separate RSVP reservation
request, as shown; these two requests must be merged into the
effective flowspec, 3B, that is used to make the reservation on
interface (d). (2) The reservations on the interfaces (c) and (d)
must be merged in order to forward the reservation requests
upstream; as a result, the larger flowspec 4B is forwarded
upstream to each previous hop.
Braden, Ed., et. al. Standards Track [Page 15]
RFC 2205 RSVP September 1997
|
Sends | Reserves Receives
|
| _______
WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} )
| |_______|
|
-----------------------|----------------------------------------
| _______
WF( *{4B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} )
| |_______| <- WF( *{2B} )
Figure 5: Wildcard-Filter (WF) Reservation Example
Figure 6 shows Fixed-Filter (FF) style reservations. For each
outgoing interface, there is a separate reservation for each
source that has been requested, but this reservation will be
shared among all the receivers that made the request. The flow
descriptors for senders S2 and S3, received through outgoing
interfaces (c) and (d), are packed (not merged) into the request
forwarded to previous hop (b). On the other hand, the three
different flow descriptors specifying sender S1 are merged into
the single request FF( S1{4B} ) that is sent to previous hop (a).
|
Sends | Reserves Receives
|
| ________
FF( S1{4B} ) <- (a) | (c) | S1{4B} | (c) <- FF( S1{4B}, S2{5B} )
| |________|
| | S2{5B} |
| |________|
---------------------|---------------------------------------------
| ________
<- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} )
FF( S2{5B}, S3{B} ) | |________| <- FF( S1{B} )
| | S3{B} |
| |________|
Figure 6: Fixed-Filter (FF) Reservation Example
Braden, Ed., et. al. Standards Track [Page 16]
RFC 2205 RSVP September 1997
Figure 7 shows an example of Shared-Explicit (SE) style
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -