View
2
Download
0
Category
Preview:
Citation preview
T-110.5116 Computer Networks II Quality of Service
21.11.2011 Matti Siekkinen
(Main source: J. Kurose, K. Ross: “Computer Networking: A Top Down Approach”)
November 21, 11
Q & A for summary lecture
Q & A for summary lecture 5.12. Prepare and send me questions by email Questions are treated anonymously We will go through the questions during the last session
Assignment grading almost done No failed reports Results probably this week
2
November 21, 11
Outline What is QoS?
Overview of QoS mechanisms Application level techniques
Media streaming example case o Client or server based techniques
Overlays o RON, CDN
Network-layer techniques Offering multiple classes of service
o Scheduling and policing packets, DiffServ Providing QoS guarantees
o Resource reservation, RSVP, IntServ Conclusions
November 21, 11
What is Quality of Service?
Many applications are sensitive to delay, jitter, and packet loss Too high values makes utility drop to zero
Some mission-critical applications cannot tolerate disruption VoIP high-availability computing
Charge more for business applications vs. consumer applications
Related concept is service availability How likely is it that I can place a call and not get interrupted? requires meeting the QoS requirements for the given
application
November 21, 11
Example QoS Requirements
Personal voice over IP Network
monitoring
CEO Video conference with analysis
Financial Transactions
Interactive whiteboard
Unicast radio
Network management traffic Extranet
web traffic Public web traffic
Push news
Personal e-mail
Business e-mail
Server backups
Sensitive
Insensitive
Casual Critical
Delay
Mission Criticality
November 21, 11
QoS in Today’s Internet TCP/UDP/IP: “best-effort service” no guarantees on delay, loss
Today’s Internet applications use application-level techniques to mitigate
(as best possible) effects of delay, loss
But some apps (multimedia) require QoS and level of performance to be
effective!
? ? ? ? ?
?
? ? ?
?
?
November 21, 11
How should the Internet evolve to better support QoS?
Integrated services philosophy: fundamental changes in
Internet so that apps can reserve end-to-end bandwidth
requires new, complex software in hosts & routers
Laissez-faire no major changes more bandwidth when
needed content distribution,
application-layer multicast application layer
Differentiated services philosophy:
fewer changes to Internet infrastructure, yet provide 1st and 2nd class service
What’s your opinion?
November 21, 11
QoS Mechanisms: classification
Provisioning Admission control
o Prohibit or allow new flows to enter the nw Resource reservation
Control Operate on short time scales Real-time traffic or flow control
o E.g. scheduling, shaping, policing... Management
Monitor the QoS Longer time scales than control
November 21, 11
QoS Mechanisms
Packet Scheduling
Admission Control
Traffic Shaping
(Users get their share of bandwidth) (Amount of traffic
users can inject into the network)
(To accept or reject a flow based on flow specifications)
Core
Adapt application behavior
November 21, 11
QoS Control Mechanisms
Application-level techniques Application adapts to network conditions Use overlays
Transport-layer techniques Adapt transport protocols to application requirements
and network conditions TCP, DCCP
Network-layer techniques Scheduling (FIFO, WFQ) Queue mgmt (drop-tail, RED) Policing (leaky/token bucket)
Make the best out of best effort
November 21, 11
Outline What is QoS?
Overview of QoS mechanisms Application level techniques
Media streaming example case o Client or server based techniques
Overlays o RON, CDN
Network-layer techniques Offering multiple classes of service
o Scheduling and policing packets, DiffServ Providing QoS guarantees
o Resource reservation, RSVP, IntServ Conclusions
November 21, 11
Example case: Multimedia networking
Streaming stored multimedia Interactive real time media
November 21, 11
Streaming stored media application-level streaming
techniques for making the best out of best effort service: client-side buffering use of UDP versus TCP multiple encodings of
multimedia
jitter removal decompression error concealment
Media Player
November 21, 11
constant bit rate video transmission
Cum
ulat
ive
data
time
variable network
delay (jitter)
client video reception
constant bit rate video playout at client
client playout delay
buff
ered
vi
deo
Client buffering and jitter
client-side buffering, playout delay compensate for network-added jitter
November 21, 11
Client Buffering
Client-side buffering, playout delay compensate for network-added jitter
Usually Fast Start used to fill buffer quickly Not possible with live streaming
buffered video
variable fill rate, x(t)
constant drain rate, d
November 21, 11
Streaming: UDP or TCP?
UDP server sends at rate appropriate for client (oblivious to
network congestion !) often send rate = encoding rate = constant rate then, fill rate = constant rate - packet loss
short playout delay (2-5 seconds) to remove network jitter
error recover: time permitting TCP send at maximum possible rate under TCP fill rate fluctuates due to TCP congestion control larger playout delay: smooth TCP delivery rate HTTP/TCP passes more easily through firewalls
November 21, 11
Streaming Multimedia: client rate(s)
Q: how to handle different client receive rate capabilities? 28.8 Kbps dialup 100 Mbps Ethernet
A: server stores, transmits multiple copies of video, encoded at different rates
1.5 Mbps encoding
28.8 Kbps encoding
Trade stream quality to resource requirements
November 21, 11
Real-time interactive applications PC-2-PC
Skype Google Voice
PC-2-phone Dialpad Net2phone Skype Google Voice
videoconference with webcams Skype Polycom (Google Voice)
Going to now look at a PC-2-PC Internet phone example in detail
November 21, 11
Interactive Multimedia: Internet Phone
speaker’s audio: alternating talk spurts, silent periods. 64 kbps during talk spurt pkts generated only during talk spurts 20 msec chunks at 8 Kbytes/sec: 160 bytes
data application-layer header added to each chunk. chunk+header encapsulated into UDP segment. application sends UDP segment into socket every
20 msec during talk spurt
November 21, 11
Internet Phone: Packet Loss and Delay
network loss: IP datagram lost due to network congestion (router buffer overflow)
delay loss: IP datagram arrives too late for playout at receiver delays: processing, queueing in network; end-
system (sender, receiver) delays typical maximum tolerable delay: 400 ms
loss tolerance: depending on voice encoding, losses concealed, packet loss rates between 1% and 10% can be tolerated.
November 21, 11
Internet Phone: Fixed Playout Delay
receiver attempts to playout each chunk exactly q msecs after chunk was generated. chunk has time stamp t: play out chunk at t+q . chunk arrives after t+q: data arrives too late
for playout, data “lost” tradeoff in choosing q:
large q: less packet loss small q: better interactive experience
November 21, 11
Fixed Playout Delay
sender generates packets every 20 msec during talk spurt. first packet received at time r first playout schedule: begins at p second playout schedule: begins at p’
November 21, 11
Adaptive Playout Delay (1)
dynamic estimate of average delay at receiver:
where u is a fixed constant (e.g., u = .01).
Goal: minimize playout delay, keeping delay loss rate low Approach: adaptive playout delay adjustment:
estimate network delay, adjust playout delay at beginning of each talk spurt.
silent periods compressed and elongated. chunks still played out every 20 msec during talk spurt.
November 21, 11
Adaptive playout delay (2)
also useful to estimate average deviation of delay, vi :
estimates di , vi calculated for every received packet but used only at start of talk spurt
for first packet in talk spurt, playout time is:
where K is positive constant
remaining packets in talk spurt are played out periodically
November 21, 11
Adaptive Playout (3)
Q: How does receiver determine whether packet is first in a talkspurt?
if no loss, receiver looks at successive timestamps. difference of successive stamps > 20 msec -->talk
spurt begins. with loss possible, receiver must look at both time
stamps and sequence numbers. difference of successive stamps > 20 msec and
sequence numbers without gaps --> talk spurt begins.
November 21, 11
Recovery from packet loss (1) Forward Error Correction (FEC): simple scheme for every group of n chunks create redundant chunk by
exclusive OR-ing n original chunks send out n+1 chunks, increasing bandwidth by factor 1/n. can reconstruct original n chunks if at most one lost chunk
from n+1 chunks playout delay: enough time to receive all n+1 packets tradeoff:
increase n, less bandwidth waste increase n, longer playout delay increase n, higher probability that 2 or more chunks will be
lost
November 21, 11
Recovery from packet loss (2) 2nd FEC scheme “piggyback lower quality stream” send lower resolution audio stream as redundant information e.g., nominal stream at 64 kbps and redundant stream at 16 kbps.
whenever there is non-consecutive loss, receiver can conceal the loss. can also append (n-1)st and (n-2)nd low-bit rate chunk
November 21, 11
Recovery from packet loss (3)
Interleaving chunks divided into smaller
units for example, four 5 msec units
per chunk packet contains small units
from different chunks
if packet lost, still have most of every chunk
no redundancy overhead, but increases playout delay
November 21, 11
Outline What is QoS?
Overview of QoS mechanisms Application level techniques
Media streaming example case o Client or server based techniques
Overlays o RON, CDN
Network-layer techniques Offering multiple classes of service
o Scheduling and policing packets, DiffServ Providing QoS guarantees
o Resource reservation, RSVP, IntServ Conclusions
November 21, 11
Overlay solutions
QoS can also be provided by using overlay solutions (application layer)
Consider Overlay node placement wrt. network topology Replication
Examples RON Reliable Overlay Network Content distribution networks (CDN)
30
November 21, 11 31
RON: Resilient Overlay Networks Claim: building an application overlay network can increase
performance and reliability of routing "Because, sometimes, the Internet doesn't quite work..."
Two-hop (application-level) Berkeley-to-Princeton route
application-layer router
Princeton Yale
Berkeley
November 21, 11
RON
Overlay nodes cooperatively monitor path quality to each other Probing
Nodes decide whether to allow packets go through to destination or reroute them via another node
Applications must explicitly support the use of RON
32
November 21, 11 33
Can RON outperform IP Routing?
IP routing does not adapt to congestion But RON can reroute when the direct path is congested
IP routing is sometimes slow to converge But RON can quickly direct traffic through intermediary
IP routing depends on AS routing policies But RON may pick paths that circumvent policies
RON introduces overhead Packets go in and out at intermediate nodes
o Performance degradation, load on hosts, and financial cost Probing overhead to monitor the virtual links
o Limits RON to deployments with a small number of nodes What if all applications start to use RON?
November 21, 11
Content distribution networks (CDNs)
Content replication challenging to stream large
files (e.g., video) from single origin server in real time
solution: replicate content at hundreds of servers throughout Internet content downloaded to CDN
servers ahead of time placing content “close” to
user avoids impairments (loss, delay) of sending content over long paths
CDN server typically in edge/access network
origin server in North America
CDN distribution node
CDN server in S. America CDN server
in Europe
CDN server in Asia
November 21, 11
Content distribution networks (CDNs)
Content replication CDN (e.g., Akamai)
customer is the content provider (e.g., CNN)
CDN replicates customers’ content in CDN servers.
when provider updates content, CDN updates servers
origin server in North America
CDN distribution node
CDN server in S. America CDN server
in Europe
CDN server in Asia
• November 21, 11
CDN example
origin server (www.foo.com) distributes HTML replaces: http://www.foo.com/sports.ruth.gif
with http://www.cdn.com/www.foo.com/sports/ruth.gif
CDN company (cdn.com) ❒ distributes gif files ❒ uses its authoritative
DNS server to route redirect requests
HTTP request for www.foo.com/sports/sports.html
DNS query for www.cdn.com
HTTP request for www.cdn.com/www.foo.com/sports/ruth.gif
1
2
3
origin server
CDN’s authoritative DNS server
CDN server near client
client
November 21, 11
More about CDNs routing requests CDN creates a “map”, indicating distances from
leaf ISPs and CDN nodes when query arrives at authoritative DNS server:
server determines ISP from which query originates uses “map” to determine best CDN server
CDN nodes create application-layer overlay network
November 21, 11
Outline What is QoS? Overview of QoS mechanisms Application level techniques
Media streaming example case o Client or server based techniques
Overlays o RON, CDN
Network-layer techniques Offering multiple classes of service
o Scheduling and policing packets, DiffServ Providing QoS guarantees
o Resource reservation, RSVP, IntServ Conclusions
November 21, 11
Providing Multiple Classes of Service So far: making the best of best effort service
one-size fits all service model alternative: multiple classes of service
partition traffic into classes network treats different classes of traffic differently
(analogy: VIP service vs regular service)
0111
granularity: differential service among multiple classes, not among individual connections
history: ToS bits in IP header
November 21, 11
Multiple classes of service: scenario
R1 R2 H1
H2
H3
H4 1.5 Mbps link R1 output
interface queue
November 21, 11
Principles for QoS differentiation Example: 1Mbps IP video phone, FTP share 1.5 Mbps
link. bursts of FTP can congest router, cause audio/video loss want to give priority to audio/video over FTP
packet marking needed for router to distinguish between different classes; and new router policy to treat packets accordingly
Principle 1
R1 R2
November 21, 11
Principles for QoS differentiation (more)
what if applications misbehave? (audio/video sends higher than declared rate) policing: force source adherence to bandwidth allocations
marking and policing at network edge:
provide protection (isolation) for one class from others Principle 2
R1 R2
1.5 Mbps link
1 Mbps phone
packet marking and policing
November 21, 11
Principles for QoS differentiation (more)
Allocating fixed (non-sharable) bandwidth to flow is inefficient use of bandwidth if flows don’t use their allocation
While providing isolation, use resources as efficiently as possible
Principle 3
R1 R2
1.5 Mbps link
1 Mbps phone
1 Mbps logical link
0.5 Mbps logical link
November 21, 11
Mechanisms for QoS differentiation
Scheduling mechanisms Routers buffer arriving packets in queue(s) Scheduling: router chooses which packet to forward
next from many possible ones Many different scheduling policies possible
Policing mechanisms Router forwards only packets that agree to specified
policy parameters Provide protection/isolation between classes of flows
o Enforce ”good behavior”
44
November 21, 11
Scheduling Mechanisms
scheduling: choose next packet to send on link FIFO (first in first out) scheduling: send in order
of arrival to queue The most widely used in the Internet
November 21, 11
Scheduling: more Priority scheduling: transmit highest priority
queued packet multiple classes, with different priorities
class may depend on marking or other header info, e.g. IP source/dest, port numbers, etc..
November 21, 11
Scheduling: still more round robin scheduling: multiple classes cyclically scan class queues, serving one from
each class (if available)
November 21, 11
Scheduling: still more Weighted Fair Queuing: generalized Round Robin each class gets weighted amount of service in
each cycle
November 21, 11
Drop policy If packet arrives to full queue, which one to discard?
Tail drop: drop arriving packet priority: drop/remove on priority basis random: drop/remove randomly
RED = Random Early Detection, a.k.a. Random Early Drop When queue length exceeds a drop level -> drop each arriving
packet with a fixed probability p Advantages
o Avoids global synchronization where all TCP connections back off at the same time
o Sources don’t have to react to transient congestion Problems
o Not suitable as such for QoS differentiation (WRED proposed) o Vulnerable to LDOS
• Low rate attack stream with carefully scheduled periodic short bursts • Cause “lock out” of legitimate flows via successive TCP timeouts
p Drop level
November 21, 11
Policing Mechanisms Goal: limit traffic to not exceed declared parameters Three commonly used criteria:
(Long term) Average Rate: how many pkts can be sent per unit time (in the long run)
o crucial question: what is the interval length: 100 packets per sec or 6000 packets per min have same average!
Peak Rate: e.g., 6000 pkts per min. (ppm) avg.; 1500 pps peak rate
(Max.) Burst Size: max. number of pkts sent consecutively (with no intervening idle)
Mechanisms Leaky bucket Token bucket
November 21, 11
Policing: Leaky Bucket
Enforces a constant output rate Levels out any incoming bursts
of packets Can be used to limit peak rates
51
Leaky Bucket
Water drips out of the hole at constant rate
Packets out
Packets in
Regulated flow
Unregulated flow
November 21, 11
Policing: Token Bucket Limit input to specified burst size and average rate
bucket can hold b tokens tokens generated at rate r token/sec unless bucket full over interval of length t: number of packets admitted less
than or equal to (r*t + b) b limits max burst size Smax avg rate limited by r*t
Does not bound the peak rate of bursts smaller than Smax Bucket contains enough tokens to cover a complete burst size
Smax = b(1+r/(C-r)), where C is output link capacity
November 21, 11
Policing: Token Bucket
What to do with packets without tokens? Token Bucket can be used to shape, police, or mark
Delay pkts from entering net until token available (shaping) Drop pkts that arrive without tokens (policing) Let all pkts pass through, mark ones without tokens
o Network drops pkts without tokens in time of congestion
November 21, 11
IETF Differentiated Services Want “qualitative” service classes
“behaves like a wire” Relative service distinction: Platinum, Gold, Silver
Scalability: Simple functions in network core Complex functions at edge routers (or hosts) No per-flow router state maintained at core
o Difficult with large number of flows Flexibility:
New service classes arise, old may become obsolete Don’t define define service classes but provide
functional components to build them
November 21, 11
Core router: per class traffic
management buffering and scheduling
based on marking at edge Per Hop Behaviors (PHB) no per-flow states
Diffserv Architecture Edge router: per-flow traffic management marks packets to classes could also be done by the host
scheduling
. . .
r
b
marking
November 21, 11
Edge-router packet marking
Packet is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6
6 bits used for Differentiated Service Code Point (DSCP) and determine PHB that the packet will receive
2 bits are currently unused
November 21, 11
Edge-router packet marking
User packets
Rate A
B
Example: Profile: pre-negotiated rate A, bucket size B Packet marking at edge based on per-flow
profile
Possible usage of marking: Packets of different classes marked differently
E.g. different applications Conforming portion of flow marked differently than non-
conforming one
November 21, 11
Classification and conditioning
Traffic metering could be done before/after classification
Check if traffic conforms to agreed traffic profile (e.g., rate, burst size)
Depending on conformance can shape, police(drop), or mark differently
November 21, 11
Core router Per-Hop Behavior (PHB)
PHB result in a different observable forwarding performance behavior Must be measurable differences
Mechanisms to use to enforce PHB not specified Can do it as you want
Examples: Class A gets x% of outgoing link bandwidth over time
intervals of a specified length Class A packets leave first before packets from class B
November 21, 11
Forwarding (PHB)
PHBs currently defined: Expedited Forwarding: pkt departure rate of a class
equals or exceeds specified rate logical link with a minimum guaranteed rate
Assured Forwarding: 4 classes of traffic each guaranteed minimum amount of bandwidth each with three drop preference partitions
November 21, 11
Expedited Forwarding
Expedited packets experience a traffic-free network (low loss, low latency, low jitter, and assured bandwidth (premium service)
Strict priority queuing
61
November 21, 11
Assured Forwarding AF PHB delivers the packet with high assurance as
long as its class does not exceed the subscribed rate Use e.g. WFQ scheduling
62
November 21, 11
Outline What is QoS? Overview of QoS mechanisms Application level techniques
Media streaming example case o Client or server based techniques
Overlays o RON, CDN
Network-layer techniques Offering multiple classes of service
o Scheduling and policing packets, DiffServ Providing QoS guarantees
o Resource reservation, RSVP, IntServ Conclusions
November 21, 11
End-to-end QoS guarantees
What is needed? QoS differentiation mechanisms
o The mechanisms we just reviewed Resource reservation mechanism
o Admission control o RSVP or other existing protocol
How to put it all together? IETF IntServ architecture
64
November 21, 11
From QoS differentiation to guarantees
Basic fact of life: can not support traffic demands beyond link capacity
Call Admission: flow declares its needs, network may block call (e.g., busy signal) if it cannot meet needs
R1 R2
1.5 Mbps link
1 Mbps phone
1 Mbps phone
Principle 4
November 21, 11
QoS guarantee scenario Resource reservation
traffic and QoS declaration call setup, signaling (RSVP) per-element admission control
QoS-sensitive scheduling (e.g.,
WFQ)
request/ reply
November 21, 11
Architecture for providing QoS guarantees in IP networks for individual application sessions
Resource reservation: routers maintain state info of allocated resources, QoS req’s
Admit/deny new call setup requests:
Question: can newly arriving flow be admitted with performance guarantees while not violated QoS guarantees made to already admitted flows?
IETF Integrated Services
November 21, 11
Call Admission Arriving session must : declare its QoS requirement
R-spec: defines the QoS being requested Three types: best effort, controlled load,
guaranteed service characterize traffic it will send into network
T-spec: defines traffic characteristics Described as Token Bucket parameters: r, b
signaling protocol: needed to carry R-spec and T-spec to routers (where reservation is required) RSVP
November 21, 11
Intserv QoS: Service models Best effort: No reservation required at all Controlled load service: "a quality of service closely approximating the QoS that
same flow would receive from an unloaded network element.“
No R-spec necessary, just T-spec Routers can ensure that they do not oversubscribe
Guaranteed service: R-spec described as rate R
Selected to obtain desired bandwidth and delay guarantees R >= r in T-spec
o Higher rates will reduce queuing delay
November 21, 11
Achieving QoS guarantee Combine token bucket and WFQ Mathematically proven upper bound on delay (Parekh 1992)
Regulated traffic has bounded delay Can be extended to arbitrary topology networks
WFQ
token rate: ri
bucket size: bi
flow i rate: Ri=wiC/Σw
When ri < Ri , max delay for packet of flow i: Di
max = bi /Ri
arriving traffic
output link capacity: C
November 21, 11
Signaling in the Internet
connectionless (stateless)
forwarding by IP routers
best effort service
no network signaling protocols
in initial IP design
+ =
New requirement: reserve resources along end-to-end path (end system, routers) for QoS
RSVP: Resource Reservation Protocol [RFC 2205] “ … allow users to communicate requirements to network in
robust and efficient way.” i.e., signaling ! earlier Internet Signaling protocol: ST-II [RFC 1819]
November 21, 11
RSVP is… simplex
Makes reservations for unidirectional data flows receiver-initiated
Receiver of a data flow initiates and maintains the resource reservation
using soft states adapts dynamically to changing group membership as
well as changing routes. independent of routing, admission control, and
packet scheduling necessary to be present at sender(s), receiver(s),
and routers
November 21, 11
RSVP does not…
specify how resources are to be reserved rather: a mechanism for communicating needs
determine routes packets will take that’s the job of routing protocols signaling decoupled from routing RSVP relies on existing unicast/multicast routing
protocols
November 21, 11
RSVP: operation At each hop consults admission control and sets up
reservation Requester informed in case of failure
Sender-to-network signaling path message: make sender presence known to routers path teardown: delete sender’s path state from routers
Receiver-to-network signaling reservation message: reserve resources from sender(s) to
receiver reservation teardown: remove receiver reservations
Network-to-end-system signaling path error reservation error
November 21, 11
IntServ: Scalability Issues
RSVP signaling Overhead One PATH/RESV per flow for each refresh period (soft
state)
Processing overhead Routers have to classify, police and queue each flow
State information stored in routers Flow identification (using IP address, port etc) Previous hop identification Reservation Status Reserved Resources
75
November 21, 11
Outline What is QoS? Overview of QoS mechanisms Application level techniques
Media streaming example case o Client or server based techniques
Overlays o RON, CDN
Network-layer techniques Offering multiple classes of service
o Scheduling and policing packets, DiffServ Providing QoS guarantees
o Resource reservation, RSVP, IntServ Conclusions
November 21, 11
Conclusions
Some applications require a certain QoS level Different metrics important for different apps Service availability is important also
QoS mechanisms developed on various layers Application, transport, network
Today’s end-to-end Internet is best effort No end-to-end QoS guarantees possible
o Would require usage and deployment of nw-layer techniques
Application and transport level techniques used to make the best out of best effort
77
November 21, 11
Internet-wide QoS never happened
Lots of research done on QoS mechanisms in 90s For nothing..?
Some IP QoS mechanisms are utilized E.g. DiffServ can be used in private networks (within a single
ISP) Some guesses of reasons for “failure”
Technical dimension o Not manageable across competing domains o Not configurable by normal users (or apps writers) o Increase system vulnerability and resilience
Economic dimension o Lack of no viable business models o No initial gain o Not incrementally deployable
78
November 21, 11
References 1. Andrew S. Tanenbaum, Computer Networks, Fourth Edition, Pearson Education, 2006. 2. James F. Kurose, and Keith W. Ross: Computer Networking: A Top-Down Approach Featuring the Internet, Third Edition, Pearson Education,
2006. 3. Alberto Leon-Garcia and Indra Widjaja, Communication Networks: Fundamental Concepts and Key Architectures, Second Edition, Tata McGraw-
Hill, 2005. 4. IP QoS Architectures and Protocols, Packet Broadband Network Handbook, Digital Engineering Library, McGraw Hill, 2004. 5. Congestion Control and Quality of Service, Data Communication and Networking, Digital Engineering Library, McGraw Hill, 2006. 6. Curado, M. and Monteiro, E. , "A Survey of QoS Routing Algorithms", in Proc. of the International Conference on Information Technology
(ICIT2004), December 2004 7. Manner Jukka, Lopez A, Mihailovi A, Velayos H, Hepworth E, and Y Khouaja, Evaluation of Mobility and QoS Interaction, Computer Networks
Volume 38, Issue 2, 5 Feb 2002, pp. 137-163. 8. Anup Kumar Talukdar, B. R. Badrinath, and Arup Acharya, MRSVP: A Resource Reservation Protocol for an Integrated Services Network with
Mobile Hosts, Wireless Networks, 7, 5–19, 2001. 9. Rajeev Koodli, and Charles E. Perkins, Fast Handovers and Context Transfers in Mobile Networks, ACM SIGCOMM Computer Communications
Review, Special Issue on Wireless Extensions to Internet, 2001. 10. J. Hillebrand, C.Prehofer, R. Bless, M. Zitterbart, Quality-of-Service Signaling for Next-Generation IP-based Mobile Networks, IEEE
Communications Magazine, June 2004. 11. Seoung-Bum Lee, G. Ahn, X. Zhang and A. T. Campbell, INSIGNIA: An IP-Based Quality of Service Framework For Mobile Ad Hoc Networks,
Journal of Parallel and Distributed Computing, 2000. 12. Abhay K. Parekh and Robert G. Gallagher. 1994. A generalized processor sharing approach to flow control in integrated services networks: the
multiple node case. IEEE/ACM Trans. Netw. 2, 2 (April 1994), 137-150. 13. RFC 2205: Resource Reservation Protocol, Braden, Zhang et al. 14. RFC 3031: Multiprotocol Label Switching (MPLS), Rosen, Viswanathan and Callon. 15. RFC 2475: An Architecture for Differentiated Services, S. Blake, D. Black et al. 16. RFC 4080: Next Steps in Signaling (NSIS): Framework, R. Hancock, G. Karagiannis et al., 2005. 17. RFC 2326: Real Time Streaming Protocol (RTSP), H. Schulzrinne et al., 1998 18. GMPLS tutorial: http://www.iec.org/online/tutorials/gmpls/
79
Recommended