Integrated services and RSVP - Protocol

con®gure a separate LSP to carry each class of traf®c between each pair of edge
LSRs. A more practical solution is to merge LSPs of the same traf®c class to
obtain multipoint-to-point ¯ows that are rooted at an egress LSR. The LSRs
serving each of these ¯ows would be con®gured to provide the desired levels of
performance to each traf®c class.
MPLS can also be used to create Virtual Private Networks (VPNs). A VPN
provides wide-area-connectivity to a large multilocation organization. MPLS
can provide connectivity between VPN sites through LSPs that are dedicated
to the given VPN. The LSPs can be used to exchange routing information
between the various VPN sites, transparently to other users of the MPLS net-
work, thus giving the appearance of a dedicated wide area network. VPNs
involve many security issues related to ensuring privacy in the public or shared
portion of a network. These issues are discussed in Chapter 11.
10.4 INTEGRATED SERVICES IN THE INTERNET
Traditionally, the Internet has provided best-effort service to every user regard-
less of its requirements. Because every user receives the same level of service,
congestion in the network often results in serious degradation for applications
that require some minimum amount of bandwidth to function propertly. As the
Internet becomes universally available, there is also interest in providing real-
time service delivery to applications such as IP telephony. Thus an interest has
developed in having the Internet provide some degree of QoS.
To provide different QoS commitments, the IETF developed the integrated
services model that requires resources such as bandwidth and buffers to be expli-
citly reserved for a given data ¯ow to ensure that the application receives its
requested QoS. The model requires the use of packet classi®ers to identify ¯ows
that are to receive a certain level of service as shown in Figure 10.18. It also
requires the use of packet schedulers to handle the forwarding of different packet
¯ows in a manner that ensures that QoS commitments are met. Admission control
is also required to determine whether a router has the necessary resources to
accept a new ¯ow. Thus the integrated services model is analogous to the ATM
model where admission control coupled with policing are used to provide QoS to
individual applications.
The Resource Reservation Protocol (RSVP), which is discussed later in the
chapter, is used by the integrated services model to provide the reservation
messages required to set up a ¯ow with a requested QoS across the network.
RSVP is used to inform each router of the requested QoS, and if the ¯ow is found
admissible, each router in turn adjusts its packet classi®er and scheduler to
handle the given packet ¯ow.
A ¯ow descriptor is used to describe the traf®c and QoS requirements of a
¯ow. The ¯ow descriptor consists of two parts: a ®lter speci®cation (®lterspec)
and a ¯ow speci®cation (¯owspec). The ®lterspec provides the information
10.4 Integrated Services in the Internet 693
| | | Textbook Table of Contentse-Text Main Menu
v
v

required by the packet classi®er to identify the packets that belong to the ¯ow.
The ¯owspec consists of a traf®c speci®cation (Tspec) and a service request
speci®cation (Rspec). The Tspec speci®es the traf®c behavior of the ¯ow in
terms of a token bucket as discussed in Chapter 7. The Rspec speci®es the
requested QoS in terms of bandwidth, packet delay, or packet loss.
The integrated services model introduces two new services: guaranteed ser-
vice and controlled-load service.
10.4.1 Guaranteed Service
The guaranteed service in the Internet can be used for applications that require
real-time service delivery. For this type of application, data that is delivered to
the application after a certain time is generally considered worthless. Thus guar-
anteed service has been designed to provide a ®rm bound on the end-to-end
packet delay for a ¯ow. How does guaranteed service provide a ®rm delay
bound?
Recall that from Chapter 7, if a ¯ow is shaped by a …b; r† token bucket and is
guaranteed to receive at least R bits/second, then the delay experienced by the
¯ow will be bounded by b=R with a ¯uid ¯ow model, assuming that R > r. This
delay bound has to be adjusted by error terms accounting for the deviation from
the ¯uid ¯ow model in the actual router or switch.
To support guaranteed service, each router must know the traf®c character-
istics of the ¯ow and the desired service. Based on this information, the router
uses admission control to determine whether a new ¯ow should be accepted.
Once a new ¯ow is accepted, the router should police the ¯ow to ensure com-
pliance with the promised traf®c characteristics.
694 CHAPTER 10 Advanced Network Architectures
Routing
agent
Reservation
agent
Admission
control
Traffic control databaseRouting database
Classifier
Input
driver
Internet
forwarder Output driver
Packet scheduler
Management
agent
FIGURE 10.18 Router model in integrated services IP
v
v

10.4.2 Controlled-Load Service
The controlled-load service is intended for adaptive applications that can tolerate
some delay but that are sensitive to traf®c overload conditions. These applica-
tions typically perform satisfactorily when the network is lightly loaded but
degrade signi®cantly when the network is heavily loaded. Thus the controlled-
load service was designed to provide approximately the same service as the best-
effort service in a lightly loaded network regardless of the actual network con-
dition. The above interpretation is deliberately imprecise for a reason. Unlike the
guaranteed service that speci®es a quantitative guarantee, the controlled-load
service is qualitative in the sense that no target values on delay or loss are
speci®ed. However, an application requesting a controlled-load service can
expect low queueing delay and low packet loss, which is a typical behavior of
a statistical multiplexer that is not congested. Because of these loose de®nitions
of delay and loss, the controlled-load service requires less implementation com-
plexity than the guaranteed service requires. For example, the controlled-load
service does not require the router to implement the weighted fair queueing
algorithm.
As in the guaranteed service, an application requesting a controlled-load
service has to provide the network with the token bucket speci®cation of its
¯ow. The network uses admission control and policing to ensure that enough
resources are available for the ¯ow. Flows that conform to the token bucket
speci®cation should be served with low delay and low loss. Flows that are non-
conforming should be treated as best-effort service.
10.5 RSVP
The resource ReSerVation Protocol (RSVP) was designed as an IP signaling
protocol for the integrated services model. RSVP can be used by a host to
request a speci®c QoS resource for a particular ¯ow and by a router to provide
the requested QoS along the path(s) by setting up appropriate states.6
Because IP traditionally did not have any signaling protocol, the RSVP
designers had the liberty of constructing the protocol from scratch. RSVP has
the following features:
Performs resource reservations for unicast and multicast (multipoint-to-multi-
point) applications, adapting dynamically to changing group membership and
changing routes.
10.5 RSVP 695
6
RSVP can be extended for use in other situations. For example RSVP has been proposed to reserve
resources and install state related to forwarding in MPLS [RFC 2430].
v
v

Requests resource in one direction from a sender to a receiver (i.e., a simplex
resource reservation). Bidirectional resource reservation requires both end
systems to initiate separate reservations.
Requires the receiver to initiate and maintain the resource reservation.
Maintains soft state at each intermediate router: A resource reservation at a
router is maintained for a limited time only, and so the sender must periodi-
cally refresh its reservation.
Does not require each router to be RSVP capable. Non-RSVP-capable routers
use a best-effort delivery technique.
Provides different reservation styles so that requests may be merged in several
ways according to the applications.
Supports both IPv4 and IPv6.
To enable resource reservations an RSVP process (or daemon) in each node
has to interact with other modules, as shown in Figure 10.19. If the node is a
host, then the application requiring a QoS delivery service ®rst has to make a
request to an RSVP process that in turn passes RSVP messages from one node to
another. Each RSVP process passes control to its two local control modules:
policy control and admission control. The policy control determines whether the
application is allowed to make the reservation. Relevant issues to be determined
include authentication, accounting, and access control. The admission control
determines whether the node has suf®cient resources to satisfy the requested
QoS. If both tests succeed, parameters are set in the classi®er and packet sche-
duler to exercise the reservation. If one of the tests fails at any node, an error
noti®cation is returned to the originated application.
In RSVP parlance a session is de®ned to be a data ¯ow identi®ed by its
destination. Speci®cally, an RSVP session is de®ned by its destination IP address,
IP protocol number, and optionally destination port. The destination IP address
can be unicast or multicast. The optional destination port may be speci®ed by a
Host Router
RSVP
process
Packet
scheduler
ClassifierClassifier
Application
Admission
control
DataData
Data
RSVP
Policy
control
RSVP
process
Packet
scheduler
Admission
control
Policy
control
Routing
process
FIGURE 10.19 RSVP architecture
v
v

TCP or UDP port number. When the destination address is multicast, it is not
necessary to include the destination port, since different applications typically
use different multicast addresses. For multicast transmission, there may be multi-
ple senders and multiple destinations in a group. For unicast transmission, there
may be multiple senders but one destination.
An RSVP reservation request consists of a ¯owspec and a ®lterspec. The
¯owspec is used to set parameters in the node's packet scheduler. Generally,
the parameters include a service class, an Rspec (R for reserve) that de®nes
the requested QoS, and a Tspec (T for traf®c) that describes the sender's traf®c
characteristics. The ®lterspec speci®es the set of packets that can use the reserva-
tion in a given session and is used to set parameters in the packet classi®er. The
set of packets is typically de®ned in terms of sender IP address and sender port.
10.5.1 Receiver-Initiated Reservation
RSVP adopts the receiver-initiated reservation principle, meaning that the recei-
ver rather than the sender initiates the resource reservation. This principle is
similar in spirit to many multicast routing algorithms where each receiver joins
and leaves the multicast group independently without affecting other receivers in
the group. The main motivation for adopting this principle is that RSVP is
primarily designed to support multiparty conferencing with heterogeneous recei-
vers. In this environment the receiver actually knows how much bandwidth it
needs. If the sender were to make the reservation request, then the sender must
obtain the bandwidth requirement from each receiver. This process may cause an
implosion problem for large multicast groups.
One problem with the receiver-initiated reservation is that the receiver does
not directly know the path taken by data packets. RSVP solves this by introdu-
cing Path messages that originate from the sender and travel along the unicast/
multicast routes toward the receiver(s). The main purposes of the Path message
are to store the ``path state'' in each node along the path and to carry informa-
tion regarding the sender's traf®c characteristics and the end-to-end path proper-
ties. The path state includes the unicast IP address of the previous RSVP-capable
node. The Path message contains the following information:
Phop: The address of the previous-hop RSVP-capable node that forwards the
Path message.
Sender template: The sender IP address and optionally the sender port.
Sender Tspec: The sender's traf®c characteristics.
Adspec: Information used to advertise the end-to-end path to receivers. The
contents of the Adspec may be updated by each router along the path.
Upon receiving the Path message, the receiver sends Resv messages in a
unicast fashion toward the sender along the reverse path that the data packets
use. A Resv message carries reservation requests to the routers along the path.
Figure 10.20 illustrates the traces of Path and Resv messages. When sender S
has data to send to receiver Rx, S sends Path messages periodically toward Rx
10.5 RSVP 697
v
v

along the path determined by the routing protocol. The nodes that receive the
Path message record the state of the path. When Rx receives a Path message, Rx
can begin installing the reservation by sending a Resv message along the reverse
path. The IP destination address of a Resv message is the unicast address of a
previous-hop node, obtained from the path state. RSVP messages are sent as
``raw'' IP datagrams with protocol 46. However, it is also possible to encapsulate
RSVP messages as UDP messages for hosts that don't support the raw I/O
capability.
10.5.2 Reservation Merging
When there are multiple receivers, the resource is not reserved for each receiver
but is shared up to the point where the paths to different receivers diverge. From
the receiver's point of view, RSVP merges the reservation requests from different
receivers at the point where multiple requests converge. When a reservation
request propagates upstream toward the sender, it stops at the point where
there is already an existing reservation that is equal to or greater than that
being requested. The new reservation request is merged with the existing reserva-
tion and is not forwarded further. This practice may reduce the amount of RSVP
traf®c appreciably when there are many receivers in the multicast tree. Figure
10.21 illustrates the reservation merging example. Here the reservation requests
from Rx1 and Rx2 are merged at R3, which are in turn merged at R2 with the
request coming from Rx3.
Path
Resv
Path
Resv
Path Path
Resv Resv
S RxR1
R2
R3
FIGURE 10.20 RSVP Path
and Resv messages
Path
Resv
Path
Path
Path
Resv
Resv
Resv
Path
Path
Path
Resv
Resv
Resv
S
Rx1
Rx2
Rx3
R1
R2
R4
R3
FIGURE 10.21 Merging reservations
v
v

10.5.3 Reservation Styles
Three reservation styles are de®ned in RSVP: wildcard ®lter, ®xed ®lter, and
shared explicit. Figure 10.22 shows a router con®guration somewhere in a dis-
tribution tree for the purpose of distinguishing reservation styles. Three senders
and three receivers are attached to the router. It is assumed that packets from S1,
S2, and S3 are forwarded to both output interfaces.
The wildcard-®lter (WF) style creates a single reservation shared by all
senders. This style can be thought of as a shared pipe whose resource is the
largest of the resource requests from all receivers, independent of the number
of senders. The WF-style reservation request is symbolically represented by
WF(*{Q}), where the asterisk denotes wildcard sender selection and Q denotes
the ¯owspec. WF style is suitable for applications that are unlikely to have
multiple senders transmitting simultaneously. Such applications include audio
conferencing.
Figure 10.23 shows the WF-style reservation. For simplicity, the ¯owspec is
assumed to be of one-dimensional quantity in multiples of some base resource
quantity B. Interface (c) receives a request with a ¯owspec of 4B from a down-
stream node, and interface (d) receives two requests with ¯owspects of 3B and
2B. The requests coming from interface (d) are merged into one ¯owspec of 3B so
that this interface can support the maximum requirement. When forwarded by
the input interfaces, the requests from interfaces (c) and (d) are further merged
into a ¯owspec of 4B.
The ®xed-®lter (FF) style creates a distinct reservation for each sender.
Symbolically, this reservation request can be represented by FF(S1{Q1},
S2{Q2}, . . .), where Si is the selected sender and Qi is the resource request for
sender i. The total reservation on a link for a given session is the sum of all Qi's.
Figure 10.24 shows the FF-style reservation. Interface (c) receives a request
with a ¯owspec of 4B for sender S1 and 5B for sender S2 and forwards
FF(S1{4B}) to (a) and FF(S2{5B}) to (b). Note that the FF-style reservation
is shared by all destinations. Interface (d) receives two requests: FF(S1{3B},
S3{B}) and FF(S1{B}). Interface (d) then reserves 3B for S1 and B for S3 and
forwards FF(S1{3B}) to (a) and FF(S3{B}) to (b). Interface (a) then merges the
two requests received from (c) and (d) and forwards FF(S1{4B}) upstream.
Interface (b) packs the two requests from (c) and (d) and forwards FF(S2{5B},
S3{B}) upstream.
The shared-explicit (SE) style creates a single reservation shared by a set of
explicit senders. Symbolically, this reservation request can be represented by
SE(S1, S2 . . . {Q}), where Si is the selected sender and Q is the ¯owspec.
10.5 RSVP 699
R1
c
d
a
b
S1
S2, S3
Router
R2
R3
FIGURE 10.22 Example for different reservation
styles
v
v

Figure 10.25 shows the SE-style reservation. When reservation requests are
merged, the resulting ®lterspec is the union of the original ®lterspecs and the
resulting ¯owspec is the largest ¯owspec.
10.5.4 Soft State
The reservation states that are maintained by RSVP at each node are refreshed
periodically by using Path and Resv messages. When a state is not refreshed
within a certain time-out, the state is deleted. The type of state that is maintained
by a timer is called soft state as opposed to hard state where the establishment
and teardown of a state are explicitly controlled by signaling messages.
Because RSVP messages are delivered as IP datagrams with no reliability
requirement, occasional losses can be tolerated as long as at least one of the K
consecutive messages gets through. Currently, the default value of K is 3. Refresh
messages are transmitted once every R seconds, where the default value is 30
seconds. To avoid periodic message synchronization, the actual refresh period
for each message should be randomized, say, using a uniform distribution in the
range of ‰0:5R; 1:5RŠ. Each Path and Resv message carries a TIME_VALUES
object containing the refresh period R. From this value, a local node can deter-
mine its state lifetime L, which is L ! 1:5 Ã
K Ã
R.7
Receive
WF(*{4B})WF(*{4B})
*{4B}
*{3B}
(a)
(b)
(c)
(d)
WF(*{3B})
WF(*{2B})WF(*{4B})
ReserveSend
FIGURE 10.23 Wildcard-®lter reservation example
Receive
FF(S1{4B})
(a)
(b)
(c)
(d)
FF(S2{5B}, S3{B})
FF(S1{4B}, S2{5B})
S1{4B}
S2{5B}
S1{3B}
S3{B}
FF(S1{3B}, S3{B})
FF(S1{B})
ReserveSend
FIGURE 10.24 Fixed-®lter reservation example
7
The RSVP speci®cation instead gives this formula: L ! …K ‡ 0.5† Ã
1.5 Ã
R, which the author thinks is not
correct.
v
v

There is a trade-off between the refresh traf®c overhead period and recovery
time. The amount of refresh traf®c overhead is (Path_size + Resv_size)/R bits/
second. A short refresh period increases the refresh traf®c overhead, while a long
refresh period lengthens the recovery time.
Although a time-out will eventually occur in a path or reservation state if the
corresponding refresh message is absent, RSVP can speed up state removals by
utilizing teardown messages. There are two types of teardown messages:
PathTear and ResvTear. A PathTear message travels from the point of origin,
following the same paths as the Path messages toward the receivers, deleting the
path state and dependent reservation state along the paths. A ResvTear message
travels from the point of origin toward the upstream senders, deleting the reser-
vation state along the way.
10.5.5 RSVP Message Format
Each RSVP message consists of a common header and a body consisting of a
variable number of objects that depend on the message type. The objects in the
message provide the information necessary to make resource reservations. The
format of the common header is shown in Figure 10.26.
The current protocol version is 1, and no ¯ag bits are currently de®ned. The
seven message types are Path, Resv, PathErr, ResvErr, PathTear, ResvTear, and
ResvConf.
The RSVP checksum uses the 1s complement algorithm common in TCP/IP
checksum computation. The Send_TTL represents the IP TTL value with which
the message was sent. It can be used to detect a non-RSVP hop by comparing the
Send_TTL value in the RSVP common header and the TTL value in the IP
10.5 RSVP 701
Receive
(a)
(b)
(c)
(d)
SE((S1, S2){B})
SE((S1, S3){3B})
SE(S2{2B})
SE(S1{3B})
(S1, S2){B}
(S1, S2, S3)
{3B}
SE((S2, S3){3B})
ReserveSend
FIGURE 10.25 Shared-explicit reservation example
0 4 8 16
RSVP checksum
RSVP length
Message type
Reserved
FlagsVersion
Send_TTL
31
FIGURE 10.26 Format of common header
v
v

header. The RSVP length ®eld indicates the total length of the RSVP message in
octets, including the common header.
The format of the objects that follow the common header is shown in Figure
10.27. The length ®eld indicates the total object length in octets. The length must
be a multiple of four.
The Class-Num ®eld identi®es the object class. The C-Type value identi®es
the subclass of the object. The following object classes are de®ned:
NULL: A NULL object is ignored by the receiver.
SESSION: A SESSION object speci®es the session for the other objects that
follow. It is indicated by the IP destination address, IP protocol number,
and destination port number. The session object is required in every mes-
sage.
RSVP_HOP: This object carries the IP address of the RSVP-capable router
that sent this message. For downstream messages (e.g., Path from source
to receiver), this object represents the previous hop; for upstream messages
(e.g., Resv from receiver to source), this object represents the next hop.
TIME_VALUES: This object contains the value of the refresh period R.
STYLE: This object de®nes the reservation style information that is not in
the ¯owspec or ®lterspec objects. This object is required in the Resv mes-
sage.
FLOWSPEC: This object de®nes the desired QoS in a Resv message.
FILTER-SPEC: This object de®nes the set of packets that receive the desired
QoS in a Resv message.
SENDER_TEMPLATE: This object provides the IP address of the sender in
a Path message.
SENDER_TSPEC: This object de®nes the sender's traf®c characteristics in a
Path message.
ADSPEC: This object carries end-to-end path information (OPWA8
) in a
Path message.
ERROR_SPEC: This object speci®es errors in PathErr and ResvErr, or
errors in a con®rmation in ResvConf.
POLICY_DATA: This object carries policy information that enables the
policy module in a node to determine whether a request is allowed or not.
0
Length
16 24 31
Class-Num
(Object contents)
C-type
FIGURE 10.27 Format of each object
8
OPWA stands for one pass with advertising. It refers to a reservation model in which downstream
messages gather advertisement information that the receiver(s) can use to learn about the end-to-end
service.
v
v

INTEGRITY: This object carries cryptographic and authentication informa-
tion that is used to verify the contents of an RSVP message.
SCOPE: This object provides an explicit list of senders that are to receive
this message. The object may be used in Resv, ResvErr, or ResvTear
messages.
RESV_CONFIRM: This object carries the receiver IP address that is to
receive the conformation.
RSVP messages are built from a common header followed by a number of
objects. For example, the format of a Path message is given as follows:
Path message::=Common Header[INTEGRITY]
SESSIONRSVP_HOP
TIME_VALUES
[POLICY_DATA...]
[sender descriptor]
sender descriptor::=SENDER_TEMPLATESENDER_TSPEC[ADSPEC]
Another important example is the Resv message, which is given as follows:
Resv message::=Common Header[INTEGRITY]
SESSIONRSVP_HOP
TIME_VALUES
[RESV_CONFIRM][SCOPE]
[POLICY_DATA...]
STYLEflow descriptor list
The ¯ow descriptor list depends on the reservation styles. For Wildcard
Filter (WF) style, the list is
flow descriptor list::=WF flow descriptor
WF flow descriptor::=FLOWSPEC
For Fixed FILTER (FF) style, the list is given by
flow descriptor list::=FLOWSPECFILTER_SPEC|
flow descriptor listFF flow descriptor
FF flow descriptor::=[FLOWSPEC]FILTER_SPEC
For Shared Explicit (SE) style, the ¯ow descriptor list is given by
flow descriptor::=SE flow descriptor
SE flow descriptor::=FLOWSPECfilter spec list
filter spec list::=FILTER_SPEC|
filter spec listFILTER_SPEC
10.6 DIFFERENTIATED SERVICES
The integrated services model was a ®rst step toward providing QoS in the
Internet. However, the integrated services model requires a router to keep a
10.6 Differentiated Services 703
v
v

Integrated services and RSVP - Protocol

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Integrated services and RSVP - Protocol

Similar to Integrated services and RSVP - Protocol (20)

More from Pradnya Saval

More from Pradnya Saval (20)

Recently uploaded

Recently uploaded (20)

Integrated services and RSVP - Protocol