Quality of Service in the Internet TML TKK

Quality of Service in the Internet TML, TKK, Helsinki, FINLAND Chittaranjan Hota, Ph. D Department of Computer Science and Information Systems Birla Institute of Technology & Science, Pilani Rajasthan, 333031, INDIA E-mail: c_hota@bits-pilani. ac. in (Few slides are adapted from Leon Garcia, Kuross Ross, and Tanenbaum) 05. 11. 2007

Agenda • What is Qo. S and it’s Requirements • Higher Layer Protocols for Qo. S Guarantee • Mechanisms to achieve Quality of Service • Qo. S Protocols and Models for the Internet • Integrated Services (Int. Serv) • Differentiated Services (Diff. Serv) • Multiprotocol Label Switching (MPLS) • Qo. S in Mobile Networks • Next Steps in Signaling (NSIS) 05. 11. 2007 2

What is Quality of Service? Multimedia applications: network audio and video (“continuous media”) Qo. S network provides application with level of performance needed for application to function. 05. 11. 2007 Capability of a network to provide better service (high bandwidth, less delay, low jitter, and low loss probability) to a selected set of network traffic. 3

Qo. S Requirements Sensitive Personal voice over IP Network monitorin g Unicast radio Financial Transactions Interactive whiteboar d Delay Public web traffic (With Qo. S) CEO Video conference with analysis Extranet web traffic Network management traffic Push news Personal e-mail Busines s e-mail Server backups Insensitive Casual (Without Qo. S) 05. 11. 2007 Mission Criticality Critical Audio end-to-end delay : < 150 msec good, < 400 msec OK

Internet Qo. S TCP/UDP/IP: “best-effort service” • no guarantees on delay, loss ? ? ? ? ? But you said multimedia apps require ? Qo. S and level of performance to be effective! ? ? ? Today’s Internet multimedia applications use application-level techniques to mitigate (as best possible) effects of delay, loss 05. 11. 2007 5

Application Layer Protocols With Streaming Without Streaming With Streaming 05. 11. 2007 6

Higher Layer Protocols RTP does not provide any Qo. S (User control using Real-Time Streaming Protocol (RFC 2326)) (Application Layer Protocol RTSP) (Real-Time Protocol (RTP) (RFC 1889)) Real-Time Control Protocol (RTCP) (RFC 3550) Ensures Qo. S through feedback (RTCP pkts) 05. 11. 2007 7

Qo. S at Network Layer (Router Architecture) 05. 11. 2007 8

Qo. S Principles Packet Scheduling Traffic Shaping (Users get their share of bandwidth) (Amount of traffic users can inject into the network) Admission Control (To accept or reject a flow based on flow specifications) 05. 11. 2007 Core 9

Simple Qo. S Mechanisms IP addresses, net mask, port numbers, protocol id Arrival Full Packet Classifier Y N Processor Departure Queue Discard Scheduling (FIFO Queuing) Flow identifier Full Arrival Classifier Y Discard Full The switch turns to other queue when the current one is empty N High Priority Queue Processor N Y Discard Departure Low Priority Queue Scheduling (Priority Queuing) 05. 11. 2007 10

Simple Qo. S Mechanisms Full Arrival Classifier N Y Discard Full The turning switch selects 2 packets from 1 st queue, then 1 packet from 2 nd queue and the cycle repeats Weight: 2 Processor N Y Discard Departure Weight: 1 Scheduling (Weighted Fair Queuing) Leaky Bucket (Regulate the traffic) 05. 11. 2007 Token Bucket (Credit an idle host) 11

Simple Qo. S Mechanisms Arriving Packet Queue Accepted Dropped from front Full (Tail-drop scheme) (Drop-from-front scheme) Drop probability Queue 1 Avg. TCP Traffic Drop MAXth MINth MAXdrop MINth (Random Early Detection with Drop function) 05. 11. 2007 MAXth Avg. queue size 12

Qo. S Architectures for Internet • Integrated Services (Int. Serv) – Flow Based Qo. S Model (Resources are available prior to establishing the session) – Session by session (end-to-end) – Uses RSVP (signaling protocol) to create a flow over a connectionless IP • Differentiated Services (Diff. Serv) – Categorize traffic into different classes or priorities with high priority value assigned to real time traffic – Hop by hop (no assurance of end-to-end Qo. S) • Multiprotocol Label Switching (MPLS) – Not primarily a Qo. S model, rather a Switching architecture – Ingress to the network decides a label according to FEC 05. 11. 2007 13

RSVP Architecture 05. 11. 2007 14

RSVP Design Goals • accommodate heterogeneous receivers (different bandwidth along paths) • accommodate different applications with different resource requirements • make multicast a first class service, with adaptation to multicast group membership • leverage existing multicast/unicast routing, with adaptation to changes in underlying unicast, multicast routes • control protocol overhead to grow (at worst) linear with # receivers 05. 11. 2007 15

RSVP Messages <Path Message> : : = <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [ <POLICY_DATA>. . . ] [ <sender descriptor> ] <sender descriptor> : : = <SENDER_TEMPLATE> <SENDER_TSPEC> [ <ADSPEC> ] <Resv Message> : : = <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [ <RESV_CONFIRM> ] [ <SCOPE> ] [ <POLICY_DATA>. . . ] <STYLE> <flow descriptor list> : : = <empty> | <flow descriptor list> <flow descriptor> Reservation info needs to be refreshed: Soft State Merging 05. 11. 2007 16

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 senders to receiver – reservation teardown: remove receiver reservations • network-to-end-system signaling – path error, -reservation error 05. 11. 2007 17

RSVP Example (1) (A network) 05. 11. 2007 (The multicast spanning tree for host 1) (The multicast spanning tree for host 2) 18

RSVP Example (1) (Host 3 requests a channel to host 1) 05. 11. 2007 (Additionally, it requests a second channel, to host 2) (Host 5 requests a channel to host 1) 19

RSVP Example (2) • • • (H 1, H 2, H 3, H 4, H 5) : both senders and receivers multicast group m 1 no filtering: packets from any sender forwarded audio rate: b only one multicast routing tree possible H 3 H 2 R 1 R 2 R 3 H 4 H 1 H 5 05. 11. 2007 audio conference 20

Building up Path State • H 1, …, H 5 all send path messages on m 1: (address=m 1, Tspec=b, filter-spec=no-filter, refresh=100) • Suppose H 1 sends first path message m 1: in L 1 out L 2 L 6 m 1: in L 7 out L 3 L 4 L 6 m 1: in out L 5 L 7 H 3 H 2 L 3 L 2 H 1 L 1 R 1 L 6 R 2 L 5 L 7 R 3 L 4 H 5 05. 11. 2007 21

Building up Path State • next, H 5 sends path message, creating more state in routers L 6 L 1 m 1: in out L 1 L 2 L 6 m 1: in L 7 out L 3 L 4 L 5 L 6 m 1: in out L 5 L 6 L 7 H 3 H 2 L 3 L 2 H 1 L 1 R 1 L 6 R 2 L 5 L 7 R 3 L 4 H 5 05. 11. 2007 22

Building up Path State • H 2, H 3, H 5 send path msgs, completing path state tables L 1 L 2 L 6 m 1: in out L 1 L 2 L 6 m 1: in L 3 L 4 L 7 out L 3 L 4 L 7 L 5 L 6 L 7 m 1: in out L 5 L 6 L 7 H 3 H 2 L 3 L 2 H 1 L 1 R 1 L 6 R 2 L 5 L 7 R 3 L 4 H 5 05. 11. 2007 23

Receiver Reservation H 1 wants to receive audio from all other senders • H 1 reservation msg flows uptree to sources • H 1 only reserves enough bandwidth for 1 audio stream • reservation is of type “no filter” – any sender can use reserved bandwidth H 3 H 2 L 3 L 2 H 1 L 1 R 1 L 6 R 2 L 5 L 7 R 3 L 4 H 5 05. 11. 2007 24

Receiver Reservation • H 1 reservation msgs flows uptree to sources • routers, hosts reserve bandwidth b needed on downstream links towards H 1 m 1: in L 1 L 2 out L 1(b) L 2 L 6 m 1: L 2 H 1 b b L 1 R 1 b L 6 L 7(b) L 7 L 6(b) L 7 m 1: in L 5 out L 5 H 2 L 4 in L 3 out L 3 b R 2 L 5 b L 7 b R 3 L 3 b L 4 H 3 H 4 H 5 05. 11. 2007 25

Receiver Reservation • next, H 2 makes no-filter reservation for bandwidth b • H 2 forwards to R 1, R 1 forwards to H 1 and R 2 (? ) • R 2 takes no action, since b already reserved on L 6 m 1: in L 1 L 2 out L 1(b) L 2(b) L 6 m 1: b L 2 H 1 b b b L 1 R 1 b L 6 L 7(b) L 7 L 6(b) L 7 m 1: in L 5 out L 5 H 2 L 4 in L 3 out L 3 b R 2 L 5 b L 7 b R 3 L 3 b L 4 H 3 H 4 H 5 05. 11. 2007 26

Link Failure 05. 11. 2007 27

Integrated Services • Resource reservation – call setup, signaling (RSVP) – traffic, Qo. S declaration – per-element admission control request/ reply – Qo. S-sensitive scheduling (e. g. , WFQ) 05. 11. 2007

Router and Service Model • Flow Descriptor – filterspec, flowspec • filterspec is required for classifier • flowspec(Tspec, Rspec) Traffic behavior Qo. S • Guaranteed Service – Firm bound on end-to-end delay in a flow (real-time applications) • Controlled-Load Service – Low delay, and low loss (adaptive applications) Router Model in Integrated Services IP 05. 11. 2007 29

Int. Serv Scalability • RSVP Signaling Overhead – One PATH/RESV per flow for each refresh period • Routers have to classify, police and queue each flow • Admission control is also required • State information stored in Routers – Flow identification (using IP address, port etc) – Previous hop identification – Reservation Status – Reserved Resources 05. 11. 2007 30

Diff. Serv: Motivation and Design • Complex processing is moved from core to edge • Per flow service (Int. Serv) is replaced by per aggregate or per class service with an SLA with the provider. (to improve scalability) • Label packets with a type field – e. g. a priority stamp • Core uses the type field to manage Qo. S • Defines an architecture and a set of forwarding behaviors – Up to the ISP to define an end-to-end service over this 05. 11. 2007

Diff. Serv Schema • Source sends request message to first hop router • First hop router sends request to Bandwidth Broker (BB) that replies with either accept or reject • If the request is accepted, either the source or the first hop router will mark DSCP and will start sending packets • Edge router checks compliance with the SLA and will do policing. It may drop or mark the packet with low priority to match the SLA • Core routers will look into DSCP and decide the PHB 05. 11. 2007 32

Diff. Serv Architecture Edge router: r q per-flow traffic management q marks packets as in-profile and out-profile b marking scheduling . . . Core router: q per class traffic management q buffering and scheduling based on marking at edge q preference given to in-profile packets 05. 11. 2007 33

Multi-Domain Example 05. 11. 2007 34

Expedited Forwarding • Expedited packets experience a traffic-free network (low loss, low latency, low jitter, and assured bandwidth (premium service) • EF PHB (101110) 05. 11. 2007

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 traffic profile of the node. 05. 11. 2007 36

Bandwidth Brokers U 1 BB S 1 U 2 BB C 1 S 2 ISP 2 D Server 3 C 6 Core Network C 7 Server 2 Server 1 U 2 05. 11. 2007 C 2 BB C 5 C 4 ISP 1 BB BB U 3 37

Integrated Solution 05. 11. 2007 38

Multiprotocol Label Switching • MPLS is a traffic engineering tool whereby we allocate specific path and network resources to specific types of traffic ensuring Qo. S • Supports Multiple protocols like IPv 4, IPv 6, IPX, Apple. Talk at the network layer, and Ethernet, Token Ring, FDDI, ATM, Frame Relay, PPP at the link layer • Independent of layer 2 and layer 3 • Data transmission occurs on Label Switched Paths (LSP) • Labels are distributed using Label Distribution Protocol (LDP), or RSVP, or piggybacked on BGP and OSPF • FEC (Forward Equivalence Class) is a 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 05. 11. 2007 39

Model for MPLS Network • Convergence of connection oriented forwarding techniques and Internet’s routing protocols LER LSR = Label Switched Router LER = Label Edge Router LSP = Label Switched Path LSR LSP Route at edge and Switch at core 05. 11. 2007 40

Separate forwarding and control • Not a longest prefix match like IP, MPLS does exact match of a label, hence faster routing decisions IP Router Control: IP Router Software 05. 11. 2007 MPLS Control: IP Router Software ATM Switch Control: ATM Forum Software Forwarding: Longest-match Lookup Label Swapping 41

MPLS Forwarding 05. 11. 2007 42

MPLS Operation 1 a. Routing protocols (e. g. OSPF-TE) exchange reachability to destination networks 4. LER at egress removes label and delivers packet 1 b. Label Distribution Protocol (LDP) establishes label mappings to destination network IP Ingress IP 10 IP 20 IP IP 40 Egress MPLS Domain 2. Ingress LER receives packet and “label”s packets 05. 11. 2007 3. LSR forwards packets using label swapping 43

MPLS Labels • Label assignment decisions are based on forwarding criteria like • Destination unicast routing • Traffic engineering • Multicast • Virtual Private Network • Quality of Service 05. 11. 2007 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: Bottom of Stack (first label in stack) 44

Label and FEC Relationship Assignment of FEC to a packet is done by ingress router R 4 could send a packet with Label=L 1, 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. 05. 11. 2007 45

Label Merging • Label Switched Path (LSP): A unidirectional connection through multiple LSRs. 3 7 6 A B 5 E Multi-point to Single point tree routed at Egress router 05. 11. 2007 6 F C 2 8 5 D A 5 E 6 3 B 6 F C 8 D 5

LSP Hierarchy • A Packet can have several labels one after the other before the IP header. (Why? Tunneling) (Multiple Levels of Nesting) (Tunnel 1 may be for the Enterprise with 1 a for Vo. IP data, 1 b for billing, and 1 c for alarm & provisioning) Push Swap & Push R 1 R 2 A Swap R 2 B Pop & Swap Pop R 2 C R 3 R 4 IP 05. 11. 2007 3 2 7 2 6 2 8 4 IP 47

MPLS Traffic Engineering nt 1 d 1 Ingress LER 3 2 4 R 1 2 R 4 R 2 1 1 R 3 3 d 2 nt 2 Egress LER 2 3 d 3 Ingress LER nt 3 05. 11. 2007 48

MPLS Traffic Engineering d 1 3 Ingress LER 2 4 R 1 2 R 4 LSP 1 2 R 2 3 1 05. 11. 2007 d 3 Ingress LER R 3 3 d 2 Egress LER LSP Cost =2+3+3+3 = 11 49

MPLS Traffic Engineering d 1 Ingress LER 3 4 R 1 2 LSR R 4 2 R 2 2 1 05. 11. 2007 3 d 2 Egress LER 3 Cost = 4 + 1 + 3+2 = 10 1 d 3 R 3 Ingress LER 50

MPLS Traffic Engineering d 1 Ingress LER 3 4 R 1 2 2 R 4 1 R 2 2 3 1 d 3 05. 11. 2007 LSR R 3 3 d 2 Egress LER Cost =2+3+3 =8 Ingress LER 51

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 05. 11. 2007 52

Label Distribution • 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 05. 11. 2007 53

RSVP-TE Explicit Routing (Hop-by-Hop Routing) 05. 11. 2007 (Explicit Routing) 54

MPLS Survivability • Survivability is the capability of a network to maintain existing services in the face of failures • Dynamic routing restores the traffic (upon a failure) based on the convergence time of the protocol • For a packet network carrying mission critical or high priority data (like MPLS network), we may need specific fast restoration or protection mechanisms 05. 11. 2007 55

Working Path & Protection Path Working Path 3 2 1 Working Path Protection Path 5 4 Link Failure 6 Link Failure 05. 11. 2007 56

Approaches to Survivability 2 3 Working path 4 8 1 5 6 7 3 Protection path 8 5 6 3 05. 11. 2007 6 7 3 4 8 6 7 Failure on working path is detected 2 4 8 5 6 Traffic carried on working path 5 7 1 5 1 Failure occurs and is detected 2 4 8 2 4 1 3 1 Normal Operation 2 2 7 Alternate path is established and traffic is re-routed 3 4 8 1 5 6 7 Traffic is switched to protection path 57

Local and Global Restoration 2 2 3 3 Egress 1 4 1 Ingress 2 6 3 5 6 (a) Active Path 1 -2 -3 -4 1 4 6 05. 11. 2007 4 5 (b) Backup Path 1 -6 -5 -4 5 (c) Backup Path 1 -2 -6 -5 -3 -4 Restores faster 58

Int. Serv, Diff. Serv and MPLS • An RSVP request (say guaranteed service) from one domain could be mapped to an appropriate Diff. Serv PHB at another domain that again could be mapped to a possible MPLS FEC at the edge of another MPLS domain. 05. 11. 2007 59

Qo. S for Mobile Networks • Problems: – Current IP Qo. S Signaling is not mobility aware (RSVP, Diff. Serv etc). – Qo. S breaks in new packet path. – Resources may not be available for the new path. – Handoff latency. – Different Qo. S mechanisms. • Objectives: – – 05. 11. 2007 Minimize handoff latency. Release any old Qo. S state after handoff as early as possible. Trigger Qo. S Signaling as soon as handoff starts. Deal with multiple Qo. S mechanisms deployed. 60

A Mobile Environment [Ref: 9] • Domain Resource Manager (DRM) controls Qo. S for one domain – Maintains up-to-date model of resource usage – Admission control for reservations • Supports heterogeneous Qo. S provisioning – per-flow reservations, aggregate reservations (Diff. Serv) and overprovisioning 05. 11. 2007 61

Anticipated Inter-Domain Handover [Ref: 9] • Signaling for new resources before hand-over – Request can be sent over old access router to new DRM – Resources can be reserved in advance • Not possible with on-path signaling approaches! – Current IETF approaches (RSVP, NSIS) not sufficient 05. 11. 2007 62

Mobile RSVP HA Sender (Correspondent) [Ref: 7] FA Mobile Host Path Tunnel Path IP-in-IP (Path) Tunnel Resv Path Resv Tunnel Resv Ack IP-in-IP (Resv) 05. 11. 2007 Resv 63

MRSVP Multicast Sender MSpec IGMP Router Proxy 05. 11. 2007 Router Proxy MSpec Proxy MN MSpec Proxy 64

MRSVP Path and Reservation PATH Active RESV Passive RESV Sender Router Proxy 05. 11. 2007 Router Proxy MN Proxy 65

MRSVP - Handoff Sender Active Reservation Router Passive Reservation Router Proxy Handoff 05. 11. 2007 MN MN Proxy 66

MRSVP – After Handoff Sender Active Reservation Router Passive Reservation Router Proxy 05. 11. 2007 Router Proxy MN Proxy 67

Qo. S through Context Transfers [Ref: 8] 2. 3. 4. (Fast Handover Signaling) (Context Transfer) 05. 11. 2007 68

Qo. S in Mobile Ad Hoc Networks • All mobile nodes with limited battery life, and wireless connections • Frequent topology changes leads to rerouting • High traffic load and mobility degrades service quality • Hard Qo. S is difficult • INSIGNIA uses Adaptive approach (Fast reservation, Fast restoration, Qo. S reporting, and Adaptation according to network conditions) 05. 11. 2007 69

INSIGNIA Framework [Ref: 10] 05. 11. 2007 70

Reservation Set-up SERVICE MODE PAYLOAD BANDWIDTH INDICATOR RES/BE BQ/EQ BW_IND 1 bit BANDWIDTH REQUEST MAX Legend RES/BQ packet MIN RES/EQ packet BE packet MAX reserved link 16 bits MIN reserved link M 2 MS M 1 MD M 3 M 4 QOS report : MAX reservation established Packets Received at Destination Mobile Node RES BQ MAX Max_BW Min_BW RES EQ MAX Max_BW Min_BW 05. 11. 2007 [Source: Seoung-Bum Lee’s presentation about INSIGNIA] 71

Re-routing / Restoration M 2 MS M 2 M 1 Rerouting MD M 3 M 4 immediate restoration Legend RES/BQ packet RES/EQ packet BE packet MAX reserved link MIN reserved link 05. 11. 2007 [Source: Seoung-Bum Lee’s presentation about INSIGNIA] 72

Re-routing / Degradation EQ degradation : degraded to minimum service M 3 MS M 1 MD M 3 M 4 M 5 Rerouting bottleneck node M 5 Legend Packets Received at Destination Mobile Node RES BQ MIN Max_BW Min_BW BE EQ - Max_BW Min_BW RES/BQ packet RES/EQ packet BE packet MAX reserved link MIN reserved link 05. 11. 2007 [Source: Seoung-Bum Lee’s presentation about INSIGNIA] 73

Adaptation : Scale Down Packets sent at Source Mobile Node after “Scaling Down” to MINIMUM service RES BQ MAX Max_BW Min_BW BE EQ - - - Persistent EQdegradation EQ Scale down to MIN service MS MD M 1 M 5 bottleneck node M 4 QOS report : Scale Down Pkts Received at Destination after “Scaling Down to MINIMUM service Legend RES/BQ packet RES BQ MIN Max_BW Min_BW RES/EQ packet BE packet MAX reserved link BE EQ - - - MIN reserved link 05. 11. 2007 [Source: Seoung-Bum Lee’s presentation about INSIGNIA] 74

Adaptation : Scale Up Packets sent by Source Mobile Node in MIN service RES BQ MAX Max_BW Min_BW resource now available MAX service re-initiated MS MD M 1 M 5 bottleneck node M 4 Legend RES/BQ packet RES/EQ packet BE packet MAX reserved link constant resource availability detected QOS report : Scale Up Pkts Received at Destination in MIN service RES BQ MAX Max_BW Min_BW MIN reserved link 05. 11. 2007 [Source: Seoung-Bum Lee’s presentation about INSIGNIA] 75

Next Steps in Signaling (NSIS) • RSVP not widely used for resource reservation – but is used for MPLS path setup – design heavily biased by multicast needs – marginal and after-the-fact security – limited support for IP mobility • Thus, IETF NSIS working group is developing new frameworks for general state management protocol – Protocols for signaling information about a data flow along it’s path in the network – Envisioned to support various signaling applications – Resource Reservation – NAT and Firewall control (by examining the flow identifier) – Traffic and Qo. S Measurement – Security and AAA issues – Interaction with other protocols (IP Routing, Mobility, Load Sharing) 05. 11. 2007 76

Next Steps in Signaling (NSIS) Application NE NE R 1 R 2 NE NE R 3 Application NE = Signaling Messages = NSIS Entity = Data flow messages (unidirectional) (Signaling and Data Flow in NSIS) NSIS Signaling Layer NSIS Transport Layer NSIS Signaling Layer Protocol for Qo. S NSIS Signaling Layer Protocol for Middleboxes NSIS Signaling Layer Protocol for … NSIS Transport Layer Protocol IP and Lower Layers 05. 11. 2007 (NSIS Protocol Components) 77

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 Mc. Graw-Hill, 2005. 4. IP Qo. S Architectures and Protocols, Packet Broadband Network Handbook, Digital Engineering Library, Mc. Graw Hill, 2004. 5. Congestion Control and Quality of Service, Data Communication and Networking, Digital Engineering Library, Mc. Graw Hill, 2006. Manner Jukka, Lopez A, Mihailovi A, Velayos H, Hepworth E, and Y Khouaja, Evaluation of Mobility and Qo. S Interaction, Computer Networks Volume 38, Issue 2, 5 Feb 2002, pp. 137 -163. 7. 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. 8. 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. 9. J. Hillebrand, C. Prehofer, R. Bless, M. Zitterbart, Quality-of-Service Signaling for Next-Generation IP-based Mobile Networks, IEEE Communications Magazine, June 2004. 10. 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. 11. Chittaranjan Hota, Sanjay Jha, G Raghurama, Distributed Dynamic Resource Management in IP VPNs to Guarantee Quality of Service, IEEE ICON 2004, Singapore. 12. RFC 2205: Resource Reservation Protocol, Braden, Zhang et al. 13. RFC 3031: Multiprotocol Label Switching (MPLS), Rosen, Viswanathan and Callon. 14. RFC 2475: An Architecture for Differentiated Services, S. Blake, D. Black et al. 15. RFC 4080: Next Steps in Signaling (NSIS): Framework, R. Hancock, G. Karagiannis et al. , 2005. 16. RFC 2326: Real Time Streaming Protocol (RTSP), H. Schulzrinne et al. , 1998 05. 11. 2007 78

Thank you! Questions 05. 11. 2007 79