📄 rfc2205.txt
字号:
policy parameters are under development.
Since the membership of a large multicast group and the resulting
multicast tree topology are likely to change with time, the RSVP
design assumes that state for RSVP and traffic control state is to be
built and destroyed incrementally in routers and hosts. For this
purpose, RSVP establishes "soft" state; that is, RSVP sends periodic
refresh messages to maintain the state along the reserved path(s).
In the absence of refresh messages, the state automatically times out
and is deleted.
In summary, RSVP has the following attributes:
o RSVP makes resource reservations for both unicast and many-to-
many multicast applications, adapting dynamically to changing
group membership as well as to changing routes.
o RSVP is simplex, i.e., it makes reservations for unidirectional
data flows.
o RSVP is receiver-oriented, i.e., the receiver of a data flow
initiates and maintains the resource reservation used for that
flow.
o RSVP maintains "soft" state in routers and hosts, providing
graceful support for dynamic membership changes and automatic
adaptation to routing changes.
o RSVP is not a routing protocol but depends upon present and
future routing protocols.
o RSVP transports and maintains traffic control and policy control
parameters that are opaque to RSVP.
Braden, Ed., et. al. Standards Track [Page 6]
RFC 2205 RSVP September 1997
o RSVP provides several reservation models or "styles" (defined
below) to fit a variety of applications.
o RSVP provides transparent operation through routers that do not
support it.
o RSVP supports both IPv4 and IPv6.
Further discussion on the objectives and general justification for
RSVP design are presented in [RSVP93] and [RFC 1633].
The remainder of this section describes the RSVP reservation
services. Section 2 presents an overview of the RSVP protocol
mechanisms. Section 3 contains the functional specification of RSVP,
while Section 4 presents explicit message processing rules. Appendix
A defines the variable-length typed data objects used in the RSVP
protocol. Appendix B defines error codes and values. Appendix C
defines a UDP encapsulation of RSVP messages, for hosts whose
operating systems provide inadequate raw network I/O support.
1.1 Data Flows
RSVP defines a "session" to be a data flow with a particular
destination and transport-layer protocol. RSVP treats each
session independently, and this document often omits the implied
qualification "for the same session".
An RSVP session is defined by the triple: (DestAddress, ProtocolId
[, DstPort]). Here DestAddress, the IP destination address of the
data packets, may be a unicast or multicast address. ProtocolId
is the IP protocol ID. The optional DstPort parameter is a
"generalized destination port", i.e., some further demultiplexing
point in the transport or application protocol layer. DstPort
could be defined by a UDP/TCP destination port field, by an
equivalent field in another transport protocol, or by some
application-specific information.
Although the RSVP protocol is designed to be easily extensible for
greater generality, the basic protocol documented here supports
only UDP/TCP ports as generalized ports. Note that it is not
strictly necessary to include DstPort in the session definition
when DestAddress is multicast, since different sessions can always
have different multicast addresses. However, DstPort is necessary
to allow more than one unicast session addressed to the same
receiver host.
Braden, Ed., et. al. Standards Track [Page 7]
RFC 2205 RSVP September 1997
Figure 2 illustrates the flow of data packets in a single RSVP
session, assuming multicast data distribution. The arrows
indicate data flowing from senders S1 and S2 to receivers R1, R2,
and R3, and the cloud represents the distribution mesh created by
multicast routing. Multicast distribution forwards a copy of each
data packet from a sender Si to every receiver Rj; a unicast
distribution session has a single receiver R. Each sender Si may
be running in a unique Internet host, or a single host may contain
multiple senders distinguished by "generalized source ports".
Senders Receivers
_____________________
( ) ===> R1
S1 ===> ( Multicast )
( ) ===> R2
( distribution )
S2 ===> ( )
( by Internet ) ===> R3
(_____________________)
Figure 2: Multicast Distribution Session
For unicast transmission, there will be a single destination host
but there may be multiple senders; RSVP can set up reservations
for multipoint-to-single-point transmission.
1.2 Reservation Model
An elementary RSVP reservation request consists of a "flowspec"
together with a "filter spec"; this pair is called a "flow
descriptor". The flowspec specifies a desired QoS. The filter
spec, together with a session specification, defines the set of
data packets -- the "flow" -- to receive the QoS defined by the
flowspec. The flowspec is used to set parameters in the node's
packet scheduler or other link layer mechanism, while the filter
spec is used to set parameters in the packet classifier. Data
packets that are addressed to a particular session but do not
match any of the filter specs for that session are handled as
best-effort traffic.
The flowspec in a reservation request will generally include a
service class and two sets of numeric parameters: (1) an "Rspec"
(R for `reserve') that defines the desired QoS, and (2) a "Tspec"
(T for `traffic') that describes the data flow. The formats and
contents of Tspecs and Rspecs are determined by the integrated
service models [RFC 2210] and are generally opaque to RSVP.
Braden, Ed., et. al. Standards Track [Page 8]
RFC 2205 RSVP September 1997
The exact format of a filter spec depends upon whether IPv4 or
IPv6 is in use; see Appendix A. In the most general approach
[RSVP93], filter specs may select arbitrary subsets of the packets
in a given session. Such subsets might be defined in terms of
senders (i.e., sender IP address and generalized source port), in
terms of a higher-level protocol, or generally in terms of any
fields in any protocol headers in the packet. For example, filter
specs might be used to select different subflows of a
hierarchically-encoded video stream by selecting on fields in an
application-layer header. In the interest of simplicity (and to
minimize layer violation), the basic filter spec format defined in
the present RSVP specification has a very restricted form: sender
IP address and optionally the UDP/TCP port number SrcPort.
Because the UDP/TCP port numbers are used for packet
classification, each router must be able to examine these fields.
This raises three potential problems.
1. It is necessary to avoid IP fragmentation of a data flow for
which a resource reservation is desired.
Document [RFC 2210] specifies a procedure for applications
using RSVP facilities to compute the minimum MTU over a
multicast tree and return the result to the senders.
2. IPv6 inserts a variable number of variable-length Internet-
layer headers before the transport header, increasing the
difficulty and cost of packet classification for QoS.
Efficient classification of IPv6 data packets could be
obtained using the Flow Label field of the IPv6 header. The
details will be provided in the future.
3. IP-level Security, under either IPv4 or IPv6, may encrypt the
entire transport header, hiding the port numbers of data
packets from intermediate routers.
A small extension to RSVP for IP Security under IPv4 and IPv6
is described separately in [RFC 2207].
RSVP messages carrying reservation requests originate at receivers
and are passed upstream towards the sender(s). Note: in this
document, we define the directional terms "upstream" vs.
"downstream", "previous hop" vs. "next hop", and "incoming
interface" vs "outgoing interface" with respect to the direction
of data flow.
Braden, Ed., et. al. Standards Track [Page 9]
RFC 2205 RSVP September 1997
At each intermediate node, a reservation request triggers two
general actions, as follows:
1. Make a reservation on a link
The RSVP process passes the request to admission control and
policy control. If either test fails, the reservation is
rejected and the RSVP process returns an error message to the
appropriate receiver(s). If both succeed, the node sets the
packet classifier to select the data packets defined by the
filter spec, and it interacts with the appropriate link layer
to obtain the desired QoS defined by the flowspec.
The detailed rules for satisfying an RSVP QoS request depend
upon the particular link layer technology in use on each
interface. Specifications are under development in the ISSLL
Working Group for mapping reservation requests into popular
link layer technologies. For a simple leased line, the
desired QoS will be obtained from the packet scheduler in the
link layer driver, for example. If the link-layer technology
implements its own QoS management capability, then RSVP must
negotiate with the link layer to obtain the requested QoS.
Note that the action to control QoS occurs at the place where
the data enters the link-layer medium, i.e., at the upstream
end of the logical or physical link, although an RSVP
reservation request originates from receiver(s) downstream.
2. Forward the request upstream
A reservation request is propagated upstream towards the
appropriate senders. The set of sender hosts to which a
given reservation request is propagated is called the "scope"
of that request.
The reservation request that a node forwards upstream may
differ from the request that it received from downstream, for
two reasons. The traffic control mechanism may modify the
flowspec hop-by-hop. More importantly, reservations from
different downstream branches of the multicast tree(s) from
the same sender (or set of senders) must be " merged" as
reservations travel upstream.
When a receiver originates a reservation request, it can also
request a confirmation message to indicate that its request was
(probably) installed in the network. A successful reservation
request propagates upstream along the multicast tree until it
reaches a point where an existing reservation is equal or greater
Braden, Ed., et. al. Standards Track [Page 10]
RFC 2205 RSVP September 1997
than that being requested. At that point, the arriving request is
merged with the reservation in place and need not be forwarded
further; the node may then send a reservation confirmation message
back to the receiver. Note that the receipt of a confirmation is
only a high-probability indication, not a guarantee, that the
requested service is in place all the way to the sender(s), as
explained in Section 2.6.
The basic RSVP reservation model is "one pass": a receiver sends a
reservation request upstream, and each node in the path either
accepts or rejects the request. This scheme provides no easy way
for a receiver to find out the resulting end-to-end service.
Therefore, RSVP supports an enhancement to one-pass service known
as "One Pass With Advertising" (OPWA) [OPWA95]. With OPWA, RSVP
control packets are sent downstream, following the data paths, to
gather information that may be used to predict the end-to-end QoS.
The results ("advertisements") are delivered by RSVP to the
receiver hosts and perhaps to the receiver applications. The
advertisements may then be used by the receiver to construct, or
to dynamically adjust, an appropriate reservation request.
1.3 Reservation Styles
A reservation request includes a set of options that are
collectively called the reservation "style".
One reservation option concerns the treatment of reservations for
different senders within the same session: establish a "distinct"
reservation for each upstream sender, or else make a single
reservation that is "shared" among all packets of selected
senders.
Another reservation option controls the selection of senders; it
may be an "explicit" list of all selected senders, or a "wildcard"
that implicitly selects all the senders to the session. In an
explicit sender-selection reservation, each filter spec must match
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -