Lecture – 27 Integrated Service Internet(IntServ) and RSVP

Lecture – 27 Integrated Service Internet(IntServ) and RSVP


The traditional internet model is a best effort
internet model in which the network makes every attempt to transmit the packet but does
not offer any explicit quality of service guarantees in terms of delay bandwidth or
delay jitter. Now, this model was considered quite adequate for most non real time applications
which are prevalent on the internet; like for example telnet or file transfer or web
browsing email, these kinds of applications. Now, these kinds of applications truly speaking
do not require any hard guarantees in terms of delay or delay jitter. They can tolerate
some amount of delays. But when broadband multimedia real time applications started
their way into the internet in terms of either video conferencing or internet telephony and
voice over IP applications, it was felt that these kinds of applications require explicit
quality of service guarantees in terms of either minimum bandwidth or delay and delay
jitter. So therefore, the internet engineering task
force IETF started working on a new group to develop a framework for defining the services
and service model and at the same time, an architecture for an internet which can give
quality of service guarantee. Now, that model was called integrated services internet model.
We will see today in this lecture, the salient architectural features and motivations for
this new integrated services internet model. Unfortunately, the paradigm of the integrated
services internet model was to give quality of service guarantees at the individual applications
flow level and later on after the architecture and the service model was formulated, it was
discovered in the real life or in practice that it is not possible to give explicit end
to end quality of service guarantees to individual applications and flows, primarily because
large number of states corresponding to each application flow will have to be maintained
in the intermediate nodes and routers and clearly it is not possible to maintain such
large number of states for such large number of applications. So, to address that problem therefore, new
architectural framework to provide quality of service guarantees at a courser granularity
was proposed and that was called differentiated services framework. We will also study later
on these differentiated services framework. So, on the one spectrum of quality of service
guarantees, we have best effort internet model which does not offer any quality of service
guarantees and on the other spectrum of the QOS, we have integrated services internet
model which gives quality of service guarantees at a very fine granularity. In between, the
internet has come out with a new paradigm or a new framework which as I just told that
is called as differentiated services framework. It is the differentiated services framework
which is likely to be more popular in providing quality of service guarantees and bandwidth
provisioning in the present day internet. We will see the features of differentiated
services later. But first let us look at the model which was proposed to provide explicit
quality of service guarantees in the internet and the individual application flow level
which is called as the integrated services internet model. So, this is an integrated services internet
model. Now, this internet service model has been specified in the IETFs RFC which is 1633.
Now, the key assumptions in this int serve, popularly called int serve; the key assumptions
are that resources have to be explicitly managed, the resources must be explicitly managed and
these resources must be explicitly managed through a combination of resource reservation
and admission control. So, what must happen is that each individual
application flow must specify its resource requirements and then the network must determine
through an admission control whether the call can be accepted or not, the whether the required
or requested quality of service guarantees can be met or not. If it can be met, then
the flow will be admitted and then later on a flow specific state is required to be maintained
in the router. So, these are the key assumptions of this service model. Now, as we just said that since the integrated
services internet model requires resource reservation and admission control; obviously,
each flow must specify its service requirements and after the source have specified its service
requirements and its traffic characteristics, the network will make certain service commitments.
So, the network will then have to make service commitment. Now, these requirements and commitments can
be met either at the individual flow levels, at the application level and therefore the
service requirements needs to be specified in terms of application level performance
or they can also be made at the granularities of classes of flows or entities and which
is actually the performance has to be judged in terms of the resourced sharing.
So, the int serv model will allow both – at the individual application flow level or at
the entities level. Note, as I was just mentioning that the courser
granularity is available more at the differentiated services framework but as we will see later
on that the entire paradigm of providing quality of service guarantees is completely different
in the differentiated services framework. So, when we say that the resource management
at the entities level will take place in the int serv, the int serv has 2 basic features. One, it operates on an end to end level. So
therefore, all the intermediate nodes in the network must provide quality of service guarantee
because it operates on an end to end level and secondly, the int serv model gives end
to end quality of service, so it defines actually an end to end service. As opposed to that
we will see in the differentiated services framework, it does not offer any end to end
quality of service guarantees. It may give only in certain domains in between. So, that
is that is one thing. Second thing is that we will see later on that the differentiated
services network does not define any service model. It only defines forwarding treatment. So, they are the 2 fundamental differences
between the int serv model and the differentiated services model. Although, popularly it is
told that in the integrated services internet model, you have to give quality of service
guarantees at the individual flow level and at the differentiated services framework,
you have to give quality of service guarantees on the aggregates of flows. So, while that
is true. But at the same time you must keep in mind that in the int serv model, you can
also aggregate some application flows into one bigger flow between two customers and
can give end to end quality of service guarantees by maintaining this aggregate flow specific
states in each individual router along the path. Now, even though you are not giving quality
of service guarantees at the application flow level, you are giving at aggregate flow level;
it would still be defined within the framework of the int serv. Now, let us look at what are the service requirements
that occur for the individual flows. Now obviously, the service requirements for the individual
flows will be in terms of per packet delay. The packet delay is one of the most important
criteria for real time multimedia application flow which is the primary motivating factor
for defining the int serv architecture. Now, this per packet delay usually, you would
require a bound on the maximum and the minimum delay. Typically, you will not require guarantees
in terms of average packet delay. You will require guarantees in terms of worst case
delays because essentially these are real time applications. Then you may require guarantees
in terms of what is the minimum bandwidth that can be given and what is the sustained
bandwidth that is available. The third service requirements for an individual
flow can be in terms of the packet loss probability. Though, the real time application flows are
somewhat insensitive to packet loss in sense that they can tolerate some 10 to 20% of the
packet loss depending upon the particular applications; but even then, different application
flows depending upon their applications requirements may have different requirements in terms of
the packet losses. Now, all the flows in the int serv model can
be defined in therefore 2 types: one is the real time applications and another one is
the elastic applications. Now, int serv model was really architected to take care of these
real time applications, the elastic applications were actually the applications running within
the best effort service model. They are not so much sensitive to packet delays and the
bandwidths. Although, they may be sensitive to the packet
loss probabilities, so therefore they have an in built mechanism for the retransmission
of the packets if some packets are lost. So, even if the packet arrives late, the applications
can still make use of it. So though, even though they maybe sensitive to somewhat packet
loss but that is addressed by having an inbuilt retransmission mechanism. So, now let us look first at the real time
applications, what kind of real time applications we are talking. Now, in the int serv model, we consider only
a playback kind of real time applications. To understand ah what is the playback real
time applications, let me just explain what is meant by a playback real time applications. Now typically, what happens? Let us say that
this is a voice over internet kind of applications. So, in the voice over internet, let us say
that you digitize the voice. So, you have an analog to digital conversion and then you
packetize the voice, packetize it and send it over the internet. Now, this is your receiver
where you will play the packets. Now, what happens at the source? The packets,
there may be certain periodicity with which the packets might have been generated. So,
let us say that these are the samples which have been generated at the transmitter. So,
this is at the transmitter, so at this end. Now, in the internet, each packet may suffer
certain delays. But what is more important is that different packets may suffer different
delay. So therefore, this packet may arrive here and this packet may arrive here and this
packet may arrive only here and then this packet may arrive here and the fourth packet
may arrive here. Now, as you can see here that the periodicity
with which the packets were generated at the transmitter, that periodicity has been completely
lost at the receiver. So, if these packets are given to the receiver for play out, obviously
there will be a distortion in the speech. What is. Why this is happening? This is happening
because different packets are experiencing different delays. While it is true that depending
upon the applications of voice, these voice applications can tolerate some amount of delays
but what is more significant here is that different packets are encountering a different
delay. That is what is called as delay jitter. Now typically, depending upon the applications,
the amount of delays that can be tolerated can vary from 300 milliseconds to 150 milliseconds.
Actually, the human ear cannot perceive delays less than 150 milliseconds. Any amount of
delays from 150 milliseconds to 300 milliseconds may be tolerable depending upon applications.
Let us say for example, you are having a streaming audio over the internet from an internet,
from an audio server; then some amount of delays can be tolerated maybe upto millisecond.
But if you are having a two way interactive telephone conversation over the internet;
then obviously, the amount of delay that can be tolerated will have to be less. So, it depends really upon the application,
what is the maximum amount of delay that can be tolerated. But even if you assume that
the maximum delay that can be tolerated is less than the permissible limit, what is really
happening here as we have seen that because different packets are encountering different
delays, there may still be a perceptible degradation in the speech quality. So, what is the solution? The solution is that at the receiver, we use
a playback buffer. So, at the receiver, we use a
playback buffer. So, we buffer the packets and then we play out the packets at an appropriate
time interval such that the periodicity with which the packets like here, the periodicity
with which the packets were generated at the transmitter, that periodicity is maintained.
To again explain this fact, something like this that let us say, the packets were generated
at this. So, this is like a time and this is like a sequence number of packet. So, this
is one packet has been generated, second packet has been generated, third packet has been
generated and so on. However, these packets arrive differently.
So, this packet arrives here, this packet arrives here, this packet arrives here and
this packet arrives here. So, as a result, the arrival times are … now. What you do
is that you start playing the packets from at this point. So, the first packet is played
here, second packet is played here, third packet is played here and the forth packet
is played here. So, as you can see that this packet which
arrived here had to wait in the buffer for this much amount of time and then it was played
out here. This packet which arrived here; since it suffered the maximum delay, did not
have to wait in this playback buffer. It is played out immediately. This packet which
suffered somewhat less delay, it waits in the buffer for some amount of time and then
it is played out here. Similarly, this packet which suffers this amount of delay, it waits
for certain amount of time. Now, what you can do is that if you can adjust
the playback time in such a manner that even those packets which suffers the maximum delay,
they can also be accounted for; then, we are done. We can then appropriately delay the
packets in the playback buffers and then play them out. As a result, there will not be any
packet loss. But there will be some latencies in playing out the first packet. Now, this
latency will depend upon what is the maximum delay that is there in the network. Now, if
the network can bound this maximum delay, then we can reduce that latency. Just to give you a complete flavor, let us
say that t i is the time of generation of the packet, i’th packet, so the time of generation
of i’th packet and r i is the time of arrival at the receiver.
The time at which the packet will be played out that is p i, the time at which this i’th
packet will be played out p i will clearly be equal to t i that is the time at which
it was generated plus d max, where d max happens to be the maximum delay. Note that this packet delay, actual delay
has been d i has been equal to r i. r i is the term at which it was received and t i
is the time at which it was transmitted. So, r i minus t i is actually the delay. So, the
packet has to wait in the playback buffer for an amount of time. So, this is d buffer,
the delay in the buffer is actually equal to d max minus d i. So, for this much amount
of time the packet has to actually wait in the buffer. So, this would be so if the minimum packet
delay is some d min, then the amount of time for which the packet has to wait in the buffer
is equal to d max minus d min that is the maximum amount of time. So therefore each
packet has to wait in the buffer equal to the delay jitter that is the difference between
the maximum and the minimum delay. If we can reduce this delay jitter that means if we
can bound the d max, then we can also reduce the latency. Such applications are called
the playback applications. In the int serv paradigm, only the playback real time applications
have been considered for defining the framework or the architectural constraints. Now, we now go back to the real time applications,
our discussion here, we consider only as we have just discussing playback real time applications.
Now, as we just saw performance of playback applications is determined by 2 factors; one
is the latency, so as we have just talked that applications like two way interactive
phone call, they are actually more sensitive to the latency. Now, if we play out some packets, if we reduce
the play out, if we reduce the time for which a packet has to wait in the buffer, then it
may and if you do not really worry about that d max that is we do not compute the playback
time for each packet to be t i plus d max but some other time that is pi is equal to
ti but let us say some d average delay; then it may so happen that some packets whose delay
may be greater than the t, the average, they may arrive after their playback time has passed.
And as a result, those packets cannot be played out and will be considered as lost. Because
of these packet losses which will happen at the receiver, there will be certain loss in
the speech quality or fidelity. Now, real time applications, they really exhibit
wide range of sensitivity to the fidelity. Some applications can tolerate more packet
losses; some applications can tolerate less packet losses. So, depending upon that we
can define the real time applications into 2 types; either they can be a tolerant real
time application that means they can tolerate some loss of fidelity or they can be intolerant
real time applications real time applications which cannot tolerate any packet loss or loss
of fidelity. However, remember that both these applications
that is tolerant and intolerant applications are the playback applications. That means
their packets can be buffered in the playback buffer and then can be played out. If any
packet arrives after its playback time has expired, then that packet will be considered
as lost in both – tolerant and intolerant applications. But tolerant applications can
tolerate somewhat more packet loss and intolerant applications can tolerate very less packet
loss. So, as you can see therefore that we need to construct different service models
to take care of tolerant and intolerant playback real time applications. Now, as you can see, in the intolerant applications
that means if you cannot tolerate any packet loss in your playback delay. So, if your situation is as I was just discussing
here, if you cannot tolerate any packet loss here, then it is necessary that you need to
put your playback time in such a manner that it takes care of the maximum delay. That is
you have to every packet you have to make it t i plus d max. So, we can achieve here
as by saying like this that in intolerant application, fixed offset delay can be larger
than the absolute maximum delay. Now, if you do this and if you have to reduce the latency,
then in order to reduce the latency you need a perfectly reliable upper bound on the delay. So, in order to reduce the latent sorry in
order to have no packet loss and in order to fix an offset larger than the absolute
maximum delay, we need to know perfectly what is this absolute maximum delay and therefore
we need a perfectly reliable upper bound on the delay and also of course, to reduce the
latency this bound has to be less. Now, a framework, a service framework which
provides a upper bound on the delay is called guaranteed service within the int serv framework
model. Now, tolerant application, in case of tolerant application; now note that tolerant
applications are those applications which can tolerate some packet losses. Now, in this
case, the fixed offset delay need not be larger than the absolute maximum delay. What does
it mean? You do not have to, you do not have to fix,
you do not have to fix the playback delay as t i plus d max every time. You can adjust
the playback delay for every applications t i by some d hat, where this d hat will be
computed separately. It may so happen when some packet r i, some i’th packet may arrive
at time r i which turns out to be greater than p i so computed. So, if the packet arrives
later than its playback time, then that packet will be considered as lost and therefore there
will be some fidelity loss. However, since these are tolerant applications
and they can tolerate some packet loses; what is now more important therefore is to adjust
this d hat, this d hat here in such a manner that large a proportion of the packets are
able to arrive before their playback time has expired and therefore they can be played
out to absorb the delay jitter. So, the fact is therefore that we do not require
a perfect reliable upper bound on the maximum delay that is possible in the network. We
require only somewhat loose guarantees. That model we call it to be a controlled load service
model which can be applied for tolerant applications. So, actually speaking, in integrated services,
when this integrated services internet framework was architected, several service models were
debated and considered and finally the int serv came to conclusion of defining paradigm
or frameworks for two service models. One is the guaranteed service model and another
one is the controlled load service model. So, guaranteed service model is meant for
intolerant applications which requires a perfectly reliable upper bound on the maximum delay
and controlled load service model is meant for tolerant applications which exhibits less
sensitivity to the packet loses. They can tolerate some packet loss and therefore they
do not require a hard, perfectly hard guarantee or perfectly reliable upper bound on the worst
case. So, let us see what is the guaranteed service model meant for intolerant applications. Since you require a perfectly reliable upper
bound on the delay; obviously, it is based on worst case assumption of the flows. So,
here you need to assume, since you do not you do not want any packet loss and since
you want that a guarantee on the delay; you have to assume the worst case scenarios for
the flows. On the other hand, in the controlled load
model which is actually meant for tolerant applications; the bound is not based on the
worst case assumption of the flows. Controlled load model actually emulate some kind of a
lightly loaded network. Typically, this model can be implemented by using some kind of a
weighted fair queuing scheduling algorithm that we have discussed in combination with
an admission control mechanism. So, what we can do is that the services or
the applications the flows or the applications which have subscribed for the control load
model, they can be given a little bit higher weight in the weighted fair queuing model
and therefore they will get certain priorities over the other users and to limit the amount
of such flows, you can employ admission control so that you do not admit large number of such
flows. Otherwise, even though they have been given higher weights in the weighted fair
queuing, individual application flows will end up seeing a congested network. So, what you do really is that you give them
higher weights but you control the amount of traffic that they are injecting through
some kind of traffic regulation or admission control, so by through admission control.
So, if you do that then these applications, for these applications it will appear as if
the network is lightly loaded. Now, tolerant applications therefore, the
thesis, the premises is that the premises or thesis says that most of these applications
will behave properly and very well if the network is lightly loaded. So therefore, what
we are trying to do is that we are trying to emulate a lightly loaded network. So, the
calculations are therefore not based on the worst case scenarios of the flows. As a matter of fact, the model is motivated
by the conjecture that the performance penalty for applications will be small compared to
the gain that you will obtain in network utilizations through statistical multiplexing. Because
what will happen clearly is that in guaranteed service model, we want hard guarantees in
terms of the worst case delays and therefore your admission control is based upon the worst
case assumption of the flows. Your statistical multiplexing gain is clearly very low in the
guaranteed service model. Maybe, you have to admit flows based on peak rates. But in
the control load model in the control load model; since you are not admitting based on
worst case, your statistical multiplexing gain maybe little bit higher. You can of course augment this service model.
It has been actually found that many audio and video applications can actually adjust
the data rate. So, they can be rate adaptive applications also. For example, they can use
some kind of rate control schemes in MPEG codings. So, depending upon the congestion
conditions in the networks, the network can actually notify to change their traffic characteristics
and the rate adaptive applications can change not only their playback point but also the
traffic pattern. So, this is like a, so what we are saying is that you have two types of
applications: tolerant and intolerant. Now, the tolerant applications are actually
delay adaptive. A delay adaptive is that you can adjust the playback point depending upon
the network delays that you are observing. So, you can periodically adjust the playback
point. Of course, by periodically adjusting the playback point, there is a possibility
that some packet losses will occur because some packets will arrive after their playback
point has expired. But your applications are not so sensitive to a small packet loss.
So, these are delay adaptive applications. You can also have, apart from delay adaptive;
you can also have a rate adaptive application where say by changing the quantization level
in your MPEG encoders, you can actually change your data rate. So, if you observe the congestion
conditions in the networks, you can reduce your data rate by making the quantization
a little coarser. So, these are so therefore, there can be another service model which also
takes care of the delay adaptive applications. The second application that we were talking
is the best effort applications, also called as elastic applications. Here the thesis is
that it uses the arriving data immediately rather than buffering it in the playback buffer
and it will always wait to, it will always choose to wait for the incoming data. So,
if some packets have been lost, then it can wait for the retransmitted packet to arrive.
There is no hurry to play that packet out and more importantly while in the case of
real time application, the performance depends on the worst case bound or delay. Here, the
performance depends more on the average delay than on the tail of delay distributions. So really speaking, the kind of guarantees
which elastic applications will require is that an average delay should be lower than
the permissible limits. So, as long as the queues in the network or queues in the routers
are less than certain or always maintained less than certain permissible limits, your
average delay will be lower and therefore the elastic applications will perceive a good
performance. So, the whole idea is really to reduce the
average delays of the packets for the elastic applications and that you can do by reducing
the average queuing delays and that can be done by actually reducing the congestion conditions
in the network. Now, even elastic applications actually differ
in their requirements for the average delay queue. If you really see, there are 3 kinds
of elastic applications that we can talk. One is the interactive bursts which are like,
applications like telnet or NFS kind of thing, then interactive bulk which are like Ftp applications
and then asynchronous bulk which are email fax over IP, those kinds of applications. So if you really see, among these three kinds
of elastic applications, it is the interactive burst really speaking which requires the least
average delays and then interactive bulk may tolerate more average delay than the interactive
burst and a asynchronous bulk can actually tolerate much higher amount of average delay. So really, in terms of their average delay
requirements also, these elastic applications differ and one can give bandwidth guarantees
or delay guarantees for these applications by using some kind of packet scheduling algorithms
and put applications like telnet and NFS kind of applications into different queues with
higher weights and put applications like asynchronous bulk with their lower weights. So, by using appropriate packet scheduling
algorithms at the routers, it is possible to guarantee these kinds of average packet
delay. Though, for elastic applications, no hard guarantees are required, only qualitative
guarantees are really required in the int serv model. In the int serv model really speaking,
the hard measurable quality of service guarantees is given only to the guaranteed service traffic. So, this service model for elastic applications
is really what is called as ASAP – as soon as possible service model. And as we have
just discussing, there are three delay classes: interactive burst requires lower delay than
the interactive bulk and the interactive bulk requires lower delay than asynchronous bulk,
asynchronous bulk can tolerate much higher amount of average delays and these are the
applications like email and so on. Now, this is we were talking at the individual
applications flow level. It is also possible, so as far as the individual applications flows
are concerned, their quality of service attributes are specified in terms of per packet delay
or bound on the maximum and the minimum delays. The delay is one of the most important quantities
there and most of these applications are playback applications. Now, we can talk of when we
talk of giving end to end quality of service guarantees under the int serv paradigm for
the classes of flows or the aggregates or at the entity level, the service commitments
and service requirements are of different types. So, the service requirements for entities
will be more in terms of aggregate bandwidth on the individual links that is what they
will be talking and these links, so different entities could be there; for example, these
links, the bandwidth maybe shared among multiple entities or multiple organizations or you
may allocate bandwidth depending upon various protocols like for example the IP V 4 traffic
or IP V 6 traffic and so on or you may allocate it depending upon different services. So,
you can have a multi service sharing as well. So, this brings so, what we have specified
right now is the requirements of the services both from individual application flow point
of view and from entities point of view. Now, as you are saying that the paradigm or the
framework of the integrated services internet model is that the resources have to be explicitly
managed; whether they are individual application flows or whether they are the entities. So, it requires therefore a resource reservation
model and the resource reservation model which has been specified in RFC 1633 is that each
individual flow will specify its traffic characteristics and the desired quality of service attributes.
The traffic characteristics will be specified in the form of a token bucket filter. They
have already studied the token bucket filter. The token bucket filter is specified by two
parameters: one is the token generation rate r and second the bucket depth b. So, each
flow has to specify its characteristics through r and b which is what is called as t specs
or the traffic specifications and it has to specify its quality of service characteristics
or reservation characteristics through reservation specs which is called as r specs. Now, like in the telecom networks, before
you can actually start transmitting the data, you have to establish a call; in the int serv
model also, before you can start transmitting the data, you have to undergo a signaling
procedure. Note that in the best effort internet model, there was no need for signaling, there
was no signaling. The model, the delivery model was actually a connectionless datagram
delivery model. Now, here however you have to undergo a signaling
procedure just like in the broadband ATM network, here also you will have to undergo a signaling
procedure and that signaling in the int serv model is called resource reservation protocol
or RSVP. We will see shortly what are the attributes or features of the signaling protocol
and how this signaling protocol is distinct or different from the QOS signaling that is
done in networks like ATM or packets or circuit switch networks. And then, once the t specs that is the traffic
specifications and the reservation specifications are specified through RSVP, the network undergoes
an admission control algorithm which could be measurement based and determines whether
the flow can be admitted or not and once the flow is admitted a virtual circuit is setup
between the source and the destinations on an end to end basis and then the flow can
start transmitting the packets. Since the int serv defines an end to end service
model, a virtual circuit needs to be established for each individual application flow on an
end to end basis and that is the primary reason why a flow specific state is required to be
maintained in each individual routers leading to a leading to maintenance of large number
of states in the routers. So, the traffic control mechanisms that are
used, so up so one is as we have discussed, we require a signaling protocol an admission
control mechanism. Then we also require individual traffic control mechanisms in the int serv
routers. One of the important mechanisms is packet scheduling algorithms. We have already
discussed these packet scheduling algorithms. Some of the popular packet scheduling algorithms
which are used to provide quality of service guarantees is weighted fair queuing algorithm.
We know that a bound on the worst case delays in the case of weighted fair queuing algorithms
can be given if the traffic is token bucket regulated or rho sigma regulated. We can give
guarantees by using weighted fair queuing in terms of worst case delay bound. Now therefore, it is these weighted fair queuing
kind of algorithms have been the primary implementation mechanisms for the QOS routers. We have to
also take into account, how we will drop the packets. We have to determine, for example
that by dropping the packets the service objectives are not violated. So therefore, the applications
like real time applications which exhibit lot of sensitivity to packet loss or fidelity
loss, we have to sort of take care that their packets are not lost. Unfortunately, the length of the queue is
not an indication of how long the packets are there in the queue. It is not an indication
of the congestion conditions in the networks; you have to take decision on dropping the
packets based on some long term average of the queues. So therefore, algorithms like
weighted RED or RED random early detections, they have to be sort of used. We had already
discussed both, the packet dropping algorithms and packet scheduling algorithms in our previous
discussions. And, our third important component of a QOS
router is packet classification. Packet classification will look at the attributes of the packets
and then will classify the packets appropriately into individual flows which can then be queued.
So, if you really see the model of a QOS router, it will look something like this. So, there is a control plane
and there is a data plane. So, in control plane, you have routing agent
and you have admission control and admission control and signaling like RSVP. These are
all elements of the control planes. Now, when the packet comes at the, if the packet goes
through a classifier and classifier then puts the packets into individual application
flows and then you go for packet scheduler. So, the admission control will configure the
packet scheduler and also rule base will configure the packet scheduler, the classification rule
engine where you need to define what is the definition of your flow. Your flow could be
based upon a pure applications or the flow could be an entity. If the flow is an entity,
then the packet classifier will look at the source IP address only and all the packets
which bears the source IP address of this particular entity, they will be put into one
flow. If you are looking at an individual TCP application; then you will look at the
source IP address, destination IP address, source port number, destination port number.
This will identify a particular TCP flow and you will classify the packet into a particular
TCP flow. So, you will put them into different queues. So actually, you will look at packet attributes
and depending upon how your packet classifier has been configured through a rule engine,
you will classify the packets into individual flows. Before actually, you do this in the
data plane as we have already discussed that before any source can start transmitting its
packet, it has to send the signaling RSPV signaling messages which contain the traffic
specifications and the reservation specifications. The admission control through an admission
control algorithm will determine whether the flow can be accepted or not and if the flow
can be accepted, then the admission control algorithm will configure the scheduler accordingly.
Set up the virtual circuit path and then allow the flow to start transmitting the packets.
When the packets come, now the packets pass through the data plane, these are the data
packets; therefore, they will undergo the packet classification, scheduling and switching.
So, these are the 3 primary engines in the data plane of any particular router. Now, what we will do now in the next is to
understand how the signaling for the call set up takes place in the int serv paradigm
which is what is called as the resource reservation protocol or RSVP. As far as this individual
implementation mechanism like packet scheduling or classifications or various admission control
algorithms or token bucket regulations, we have already discussed these individual components
earlier in our previous lectures. We will now discuss the resource reservation
protocol and that will complete our framework, our description of the framework for the int
serv model; we will then see what are the difficulties or challenges that were there
in with this int serv model for their practical implementations and therefore another model
to provide quality of service guarantees at a coarse granularity level that is the differentiated
services framework must propose. So, with this we will conclude today’s lecture.

Danny Hutson

7 thoughts on “Lecture – 27 Integrated Service Internet(IntServ) and RSVP

  1. I was searching for a brief idea of RSVP but ended up watching the whole lecture just because the concepts were so amazingly unravelled

Leave a Reply

Your email address will not be published. Required fields are marked *