plete path. These flags are commonly called
“break bits” as they indicate if gaps in the
RSVP/IntServ scheme were faced by the PATH
message. The AdSpec field is put together by
fragments; starting by default general parame-
ters, followed by fragments for each function
that is selected by the sender application.
Absence of a fragment indicates that the sender
application does not know or care about that
functionality. Then neither the intermediate
nodes nor the receiver node should select such
functionality. Information in the AdSpec field
can be modified by intermediate nodes. Typical
fragments in the AdSpec field, in addition to the
flags are: number of hops, estimate of bandwidth
available, minimum path latency and maximum
transfer unit. These are described in [RFC2215].
The combination of Receiver_TSpec and RSpec
fields in the RESV message is frequently called
the FlowSpec field. This carries the information
from the receiver through the network, indicat-
ing which functionality and values of parameters
that are requested. For the Controlled Load ser-
vice, the FlowSpec field contains the same set of
parameters as for the Sender_TSpec (i.e. mainly
the leaky bucket parameters). For the Guaran-
teed service two more parameters in addition to
those in the Sender_TSpec field are given. These
are referred to as the RSpec; the rate [R], and the
slack term [S]. The RSpec parameters are also
described in [RFC2212].
RSVP defines a session to be a traffic flow with
a particular destination and transport layer proto-
col. The RSVP can then be used by end applica-
tions to select and invoke the appropriate class
and QoS level. It has been claimed, see
[RFC2208], that RSVP does not scale to the size
of the Internet. To overcome this problem sev-
eral solutions have been proposed as described
in the following subsections.
7.1.2 Class-based Aggregation
One intention of introducing aggregation is that
individual flows do not have to be reflected by a
state in each intermediate router. The states refer
to a class and then the traffic flows are put into
the set of classes.
On entering the aggregating region, each flow
for which a reservation was made, is assigned
to one of the service classes. Flows with similar
service requirements are grouped together into a
service class. (Service class definition and flow
assignment are subjects of ongoing research.)
Each packet is marked with a tag that identifies
which service the flow should receive. For IP,
this tag could consist of the Type of Service
(ToS) bits in the packet header (e.g. similar to
DiffServ) or the packet could be encapsulated
(e.g. similar to MPLS). Inside the aggregating
regions, packets are scheduled according to their
assigned service class. Because the number of
classes is given, packet scheduling is less
demanding. However, there is a risk of conges-
tion within any service class. Instead of simply
combining all flows blindly into one service
class, the overall bandwidth available for each
service class can be specified. RSVP-based
admission control could be used to admit new
flows if there is sufficient bandwidth within the
service class. In this manner, the advantages of
admission control still apply, but the packets
within each service class can be processed and
routed more efficiently.7.1.3 Hierarchical RSVP
Activities within the IETF are also examining
hierarchical RSVP. While set-up and release pat-
terns of single RSVP flows are unpredictable,
the aggregation of a greater number of flows
seems less varying. The idea of hierarchical
RSVP is that routers at the edge of aggregating
regions use RSVP to reserve large “pipes” with
particular characteristics through the region. At
the ingress router, packets are assigned to a pipe
and encapsulated so they can be classified and
scheduled as part of the pipe. Source and desti-
nation of the encapsulated packet would be
ingress and egress routers. A limited number
of different service classes is available. Since
RSVP is receiver-oriented, pipe reservations
have to be made by egress routers. Egress routers
could reserve a number of pipes by default and
then adjust the reservations as the actual demand
becomes known. When the demand changes,
pipe reservations can be further adjusted. A pipe
reservation is only maintained if there is a suffi-
cient capacity associated with the reserved flows
to use the pipe. Therefore, a router does not nec-
essarily have to have a pipe to every other
router, leading to better scaling of the mecha-
nism. Reserved flows for which no pipe exists
are served as usual, without aggregation.The advantage of hierarchical RSVP is the re-
duction of reservation state information in the
routers. Routers in the interior of aggregating
regions only keep reservation state for the outer
pipe reservations. Packet scheduling is simpli-
fied by offering only a few choices of classes.
The main disadvantage is that packet classifying
is still done by looking into the packet headers
and comparing source and destination against
the (now shorter) list of reservations.7.1.4 Enhancing RSVP for MPLS
Once an LSP is established the traffic on the
path is identified by the label assigned by the
ingress node of the LSP. The packets that are
given the same label values by a specific node
belong to the same forwarding equivalence class
(FEC). When labels are assigned to traffic flows,