Outline. T Computer Networks II Quality of Service. Example QoS Requirements. What is Quality of Service? Matti Siekkinen

Transcription

1 Outline T Computer Networks II Quality of Service Matti Siekkinen! What is QoS?! Overview of QoS mechanisms! Application level techniques " Media streaming example case o Client or server based techniques " Overlays " CDN! Network-layer techniques " Queuing, policing, resource reservation, " DiffServ, IntServ, RSVP " Multiprotocol Label Switching (MPLS) (Some material from: J. Kurose, K. Ross: Computer Networking: A Top Down Approach, J. Manner: IP Quality of Service) What is Quality of Service? Example QoS Requirements! 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 Sensitive Delay Insensitive Casual Personal voice over IP Unicast radio Public web traffic Personal Network monitoring Push news Extranet web traffic Interactive whiteboard Business Mission Criticality CEO Video conference with analysis Financial Transactions Network management traffic Server backups Critical

2 QoS in Today s Internet TCP/UDP/IP: best-effort service! no guarantees on delay, loss?????? But some apps (multimedia) require QoS and level of performance to be?? effective!?? Today s Internet applications use application-level techniques to mitigate (as best possible) effects of delay, loss? 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? Outline QoS Mechanisms: classification! What is QoS?! Overview of QoS mechanisms! Application level techniques " Media streaming example case o Client or server based techniques " Overlays " CDN! Network-layer techniques " Queuing, policing, resource reservation, " DiffServ, IntServ, RSVP " Multiprotocol Label Switching (MPLS)! 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

3 QoS Mechanisms QoS Control Mechanisms Traffic Shaping (Amount of traffic users can inject into the network) Admission Control (To accept or reject a flow based on flow specifications) Adapt application behavior Core Packet Scheduling (Users get their share of bandwidth)! Application-level techniques " Application adapts to network conditions " Use overlays Make the best out! Transport-layer techniques of best effort " 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) Outline Example case: Multimedia networking! What is QoS?! Overview of QoS mechanisms! Application level techniques " Media streaming example case o Client or server based techniques " Overlays " CDN! Network-layer techniques " Queuing, policing, resource reservation, " DiffServ, IntServ, RSVP " Multiprotocol Label Switching (MPLS)! Streaming stored multimedia! Interactive real time media

4 Streaming stored media Client buffering and jitter 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 Media Player! jitter removal! decompression! error concealment! graphical user interface w/ controls for interactivity Cumulative data constant bit rate video transmission variable network delay (jitter) client playout delay client video reception buffered video constant bit rate video playout at client time! client-side buffering, playout delay compensate for network-added jitter Client Buffering Streaming: UDP or TCP? variable fill rate, x(t) buffered video constant drain rate, d! client-side buffering, playout delay compensate for network-added jitter 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

5 Streaming Multimedia: client rate(s) 1.5 Mbps encoding 28.8 Kbps encoding 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 Real-time interactive applications! PC-2-PC phone " Skype! PC-2-phone " Dialpad " Net2phone " Skype! videoconference with webcams " Skype " Polycom Going to now look at a PC-2-PC Internet phone example in detail 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 talkspurt 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; endsystem (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.

6 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 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 Adaptive Playout Delay (1) Adaptive playout delay (2)! 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.! also useful to estimate average deviation of delay, v i :! estimates d i, v i 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 dynamic estimate of average delay at receiver: where u is a fixed constant (e.g., u =.01).

7 Adaptive Playout (3) Recovery from packet loss (1) 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. 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 Recovery from packet loss (2) Recovery from packet loss (3) 2nd FEC scheme! piggyback lower quality stream! send lower resolution audio stream as redundant information! e.g., nominal stream PCM at 64 kbps and redundant stream GSM at 13 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 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

8 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) RON: Resilient Overlay Networks Premise: by building application overlay network, can increase performance and reliability of routing application-layer router Princeton Yale Two-hop (application-level) Berkeley-to-Princeton route 29 Berkeley 30 RON Can 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! Then again, RON has its own overheads " 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 31 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 CDN server in S. America origin server in North America CDN distribution node CDN server in Europe CDN server in Asia

9 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 CDN example client origin server ( distributes HTML! replaces: with origin server CDN s authoritative DNS server HTTP request for DNS query for HTTP request for CDN server near client CDN company (cdn.com)! distributes gif files! uses its authoritative DNS server to route redirect requests 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 Outline! What is QoS?! Overview of QoS mechanisms! Application level techniques " Media streaming example case o Client or server based techniques " Overlays " CDN! Network-layer techniques " Queuing, policing, resource reservation, " DiffServ, IntServ, RSVP " Multiprotocol Label Switching (MPLS)

10 Providing Multiple Classes of Service Multiple classes of service: scenario! thus 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)! granularity: differential service among multiple classes, not among individual connections! history: ToS bits 0111 H2 H1 R1 R1 output interface queue 1.5 Mbps link R2 H4 H3 Scenario 1: mixed FTP and audio! Example: 1Mbps IP phone, FTP share 1.5 Mbps link. " bursts of FTP can congest router, cause audio loss " want to give priority to audio over FTP R1 Principle 1 packet marking needed for router to distinguish between different classes; and new router policy to treat packets accordingly R2 Principles for QOS Guarantees (more)! what if applications misbehave? (audio sends higher than declared rate) " policing: force source adherence to bandwidth allocations! marking and policing at network edge: 1 Mbps phone R1 1.5 Mbps link packet marking and policing Principle 2 provide protection (isolation) for one class from others R2

11 Principles for QOS Guarantees (more)! Allocating fixed (non-sharable) bandwidth to flow: inefficient use of bandwidth if flows don t use their allocation 1 Mbps phone R1 1 Mbps logical link 1.5 Mbps link R2 Scheduling And Policing Mechanisms! scheduling: choose next packet to send on link! FIFO (first in first out) scheduling: send in order of arrival to queue " discard policy: if packet arrives to full queue: who to discard? o Tail drop: drop arriving packet o priority: drop/remove on priority basis o random: drop/remove randomly 0.5 Mbps logical link Principle 3 While providing isolation, it is desirable to use resources as efficiently as possible Scheduling Policies: 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.. Scheduling Policies: still more round robin scheduling:! multiple classes! cyclically scan class queues, serving one from each class (if available)

12 Scheduling Policies: still more Weighted Fair Queuing:! generalized Round Robin! each class gets weighted amount of service in each cycle Policing Mechanisms Goal: limit traffic to not exceed declared parameters Three common-used criteria:! (Long term) Average Rate: how many pkts can be sent per unit time (in the long run) " 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) Policing Mechanisms Token Bucket: limit input to specified Burst Size and Average Rate. Policing Mechanisms (more)! token bucket, WFQ combine to provide guaranteed upper bound on delay, i.e., QoS guarantee! arriving traffic token rate, r! 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). bucket size, b per-flow rate, R WFQ D = b/r max

13 IETF Differentiated Services Diffserv Architecture! want qualitative service classes " behaves like a wire " relative service distinction: Platinum, Gold, Silver! scalability: simple functions in network core, relatively complex functions at edge routers (or hosts) " signaling, maintaining per-flow router state difficult with large number of flows! don t define define service classes, provide functional components to build service classes Edge router:! per-flow traffic management! marks packets as in-profile and out-profile Core router:! per class traffic management! buffering and scheduling based on marking at edge! preference given to inprofile packets b marking r scheduling. Edge-router Packet Marking! profile: pre-negotiated rate A, bucket size B! packet marking at edge based on per-flow profile User packets Rate A Possible usage of marking:! class-based marking: packets of different classes marked differently! intra-class marking: conforming portion of flow marked differently than non-conforming one B Classification and Conditioning! 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

14 Classification and Conditioning Forwarding (PHB) may be desirable to limit traffic injection rate of some class:! user declares traffic profile (e.g., rate, burst size)! traffic metered, shaped if non-conforming! PHB result in a different observable (measurable) forwarding performance behavior! PHB does not specify what mechanisms to use to ensure required PHB performance behavior! 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 Forwarding (PHB) Expedited Forwarding PHBs being developed:! 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! Expedited packets experience a traffic-free network (low loss, low latency, low jitter, and assured bandwidth (premium service)! Strict priority queuing 56

15 Assured Forwarding! A possible implementation of the data flow for assured forwarding is shown below.! AF PHB delivers the packet with high assurance as long as its class does not exceed the a subscribed rate! Use e.g. WFQ scheduling with RED Principles for QOS Guarantees (more)! Basic fact of life: can not support traffic demands beyond link capacity 1 Mbps phone R1 R2 1 Mbps phone 1.5 Mbps link Principle 4 Call Admission: flow declares its needs, network may block call (e.g., busy signal) if it cannot meet needs 57 QoS guarantee scenario IETF Integrated Services! Resource reservation " call setup, signaling (RSVP) " traffic, QoS declaration " per-element admission control! architecture for providing QOS guarantees in IP networks for individual application sessions! resource reservation: routers maintain state info (a la VC) of allocated resources, QoS req s! admit/deny new call setup requests: QoS-sensitive scheduling (e.g., WFQ) request/ reply Question: can newly arriving flow be admitted with performance guarantees while not violated QoS guarantees made to already admitted flows?

16 Arriving session must : Call Admission! declare its QOS requirement " R-spec: defines the QOS being requested! characterize traffic it will send into network " T-spec: defines traffic characteristics! signaling protocol: needed to carry R-spec and T-spec to routers (where reservation is required) " RSVP Intserv QoS: Service models [rfc2211, rfc 2212] Guaranteed service:! worst case traffic arrival: leaky-bucket-policed source! simple (mathematically provable) bound on delay [Parekh 1992, Cruz 1988] arriving traffic token rate, r bucket size, b per-flow rate, R WFQ D = b/r max Controlled load service:! "a quality of service closely approximating the QoS that same flow would receive from an unloaded network element." 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] RSVP Design Goals 1. accommodate heterogeneous receivers (different bandwidth along paths) 2. accommodate different applications with different resource requirements 3. make multicast a first class service, with adaptation to multicast group membership 4. leverage existing multicast/unicast routing, with adaptation to changes in underlying unicast, multicast routes 5. control protocol overhead to grow (at worst) linear in # receivers 6. modular design for heterogeneous underlying technologies

17 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! interact with forwarding of packets " separation of control (signaling) and data (forwarding) planes RSVP: overview of operation! senders, receiver join a multicast group " done outside of RSVP " senders need not join group! 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 IntServ: Scalability Issues Multiprotocol Label Switching (MPLS)! 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! Mainly used for traffic engineering " Allocate specific path and network resources to specific types of traffic ensuring QoS! Sort of on layer 2.5 " Above: IPv4, IPv6, IPX, AppleTalk " Below: Ethernet, Token Ring, FDDI, ATM, Frame Relay, PPP! Data transmission occurs on Label Switched Paths (LSP) " Labels are distributed before data transmission using Label Distribution Protocol (LDP), or RSVP, or piggybacked on BGP and OSPF! FEC (Forward Equivalence Class) " Representation of group of packets that share the same requirements for their transport " Assignment of FEC to a packet is done once only as it enters into the network 67 68

18 Model for MPLS Network! Convergence of connection oriented forwarding techniques and Internet s routing protocols LER! Route at edge, switch at core LSR LSR = Label Switched Router LER = Label Edge Router LSP = Label Switched Path Separate forwarding and control Exact match instead of longest prefix match (like IP) # faster forwarding LSP IP Router MPLS ATM Switch Control: IP Router Software Control: IP Router Software Control: ATM Forum Software Forwarding: Forwarding: Forwarding: LSP Longest-match Lookup Label Swapping Label Swapping 70 MPLS Forwarding MPLS Operation 1a. Routing protocols (e.g. OSPF-TE) exchange reachability to destination networks 1b. Label Distribution Protocol (LDP) establishes label mappings to destination network 4. LER at egress removes label and delivers packet IP Ingress IP 10 IP 20 IP Egress MPLS Domain Ingress LER receives packet and label s packets 3. LSR forwards packets using label swapping 72

19 MPLS Labels Label and FEC Relationship! Label assignment decisions are based on forwarding criteria like " Destination unicast routing " Traffic engineering " Multicast " Virtual Private Network " Quality of Service A Label could be embedded in the header of the DL layer like ATM (VPI/VCI) and FR (DLCI) or could be between DL and IP as shown below: Assignment of FEC to a packet is done by ingress router R4 could send a packet with Label=L1, but it would mean a different FEC! FEC (Forwarding Equivalence Class): Assigned on the basis of IP addresses, port numbers or TOS bits.! FEC could be associated with all the flows destined to an egress LSR. Bottom of Stack (first label in stack) Label Merging LSP Hierarchy! Label Switched Path (LSP): A unidirectional connection through multiple LSRs.! Label Merging: The replacement of multiple incoming labels for a particular FEC with a single outgoing label.! Labels are "downstream-assigned", and label bindings are distributed in the "downstream to upstream direction.! A Packet can have several labels one after the other before the IP header. (Why? Tunneling) Multi-point to Single point tree routed at Egress router Push Swap & Push Swap Pop & Swap (Multiple Levels of Nesting) (Tunnel 1 may be for the Enterprise with 1a for VoIP data, 1b for billing, and 1c for alarm & provisioning) Pop R1 R2 R2A R2B R2C R3 R4 IP October 6 18, IP 76

20 Label Distribution Label Distribution! Establishes and Maintains a LSP that includes establishment of Label/ FEC bindings between LSRs in the LSP.! A downstream LSR can directly distribute Label/FEC (unsolicited downstream).! An upstream LSR requests a downstream for Label/FEC (downstream on demand).! Protocols like LDP, RSVP-TE are used to distribute Labels in the LSP! Label Distribution Protocol (LDP) [RFC 3036] " An LSR sends HELLO messages over UDP periodically to its neighbors to discover LDP peers (routing protocol tells about peers) " Upon discovery, it establishes a TCP connection to its peer " Two peers then may negotiate Session parameters (label distribution option, valid label ranges, and valid timers) " They may then exchange LDP messages over the session (label request, label mapping, label withdraw etc)! RSVP-TE (Resource Reservation Protocol-Traffic Extension) [RFC 3209] " Path message includes a label request object, and Resv message contains a label object " Follows a downstream-on-demand model to distribute labels " Path message could contain an Explicit Route Object (ERO) to specify list of nodes " Priorities can be assigned to LSPs, where a higher one can preempt a lower one MPLS Protection! Dynamic routing restores the traffic (upon a failure) based on the convergence time of the protocol IntServ, DiffServ and MPLS! An RSVP request (say guaranteed service) from one domain could be mapped to an appropriate DiffServ PHB at another domain that again could be mapped to a possible MPLS FEC at the edge of another MPLS domain. " Convergence can be slow! Set up secondary backup paths in addition to primary working paths " End-to-end protection! May need really fast recovery for mission critical or high priority data " Fast reroute: Setup detour paths around failed links/nodes " Temporary recovery until backup path takes over 79 80

21 Generalized MPLS (GMPLS) Is Internet QoS a failure and why?! MPLS the base technology (for packet switched nws)! GMPLS extension of MPLS to provide the control plane (signaling and routing) for devices that switching in any of these domains: packet, time, wavelength and fiber.! Some IP QoS mechanisms are utilized " E.g. DiffServ, MPLS can be used in private networks (ISPs)! Globally Internet has no end-to-end QoS! Some guesses of reasons for failure " not manageable across competing domains " not configurable by normal users (or apps writers) " no sufficient business model for ISPs " no initial gain " not incrementally deployable " increase system vulnerability and resilience Wrapping up References! 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 Internet is best effort in practice " 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! Some hop by hop (nw-layer) mechanisms used in private networks 1. Andrew S. Tanenbaum, Computer Networks, Fourth Edition, Pearson Education, James F. Kurose, and Keith W. Ross: Computer Networking: A Top-Down Approach Featuring the Internet, Third Edition, Pearson Education, Alberto Leon-Garcia and Indra Widjaja, Communication Networks: Fundamental Concepts and Key Architectures, Second Edition, Tata McGraw- Hill, IP QoS Architectures and Protocols, Packet Broadband Network Handbook, Digital Engineering Library, McGraw Hill, Congestion Control and Quality of Service, Data Communication and Networking, Digital Engineering Library, McGraw Hill, Curado, M. and Monteiro, E., "A Survey of QoS Routing Algorithms", in Proc. of the International Conference on Information Technology (ICIT2004), December 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 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, 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, J. Hillebrand, C.Prehofer, R. Bless, M. Zitterbart, Quality-of-Service Signaling for Next-Generation IP-based Mobile Networks, IEEE Communications Magazine, June 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, Chittaranjan Hota, Sanjay Jha, G Raghurama, Distributed Dynamic Resource Management in IP VPNs to Guarantee Quality of Service, IEEE ICON 2004, Singapore. 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., RFC 2326: Real Time Streaming Protocol (RTSP), H. Schulzrinne et al., GMPLS tutorial: