Transcript Mobility in the Internet

Quality of Service in the Internet
TML,TKK, Helsinki, FINLAND
Chittaranjan Hota, PhD
Department of Computer Science and Information Systems
Birla Institute of Technology & Science, Pilani
Rajasthan, 333031, INDIA
E-mail: [email protected]
(Few slides are adapted from Leon Garcia, Kuross Ross, and Tanenbaum)
05.11.2007
1
Agenda
• What is QoS and it’s Requirements
• Higher Layer Protocols for QoS Guarantee
• Mechanisms to achieve Quality of Service
• QoS Protocols and Models for the Internet
• Integrated Services (IntServ)
• Differentiated Services (DiffServ)
• Multiprotocol Label Switching (MPLS)
• QoS 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”)
QoS
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
QoS Requirements
Sensitive
Personal
voice
over
IP
Network
monitorin
g
Unicast
radio
Financial
Transactions
Interactive
whiteboar
d
Delay
Public web
traffic
(With QoS)
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 QoS)
05.11.2007
Mission
Criticality
Critical
Audio end-to-end delay : < 150 msec good, < 400 msec OK
4
Internet QoS
TCP/UDP/IP: “best-effort service”
• no guarantees on delay, loss
?
?
?
?
?
?
?
But you said multimedia apps require ?
QoS 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 QoS
(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 QoS through
feedback (RTCP pkts)
05.11.2007
7
QoS at Network Layer
(Router Architecture)
05.11.2007
8
QoS 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 QoS Mechanisms
IP addresses, net mask,
port numbers, protocol id
N
Arrival
Full
Packet Classifier
Y
Processor
Departure
Queue
Discard
Scheduling (FIFO Queuing)
Flow identifier
Full
Arrival
Classifier
The switch turns to other queue
when the current one is empty
N
High Priority Queue
Y
Discard
Full
Processor
Departure
N
Y
Discard
Low Priority Queue
Scheduling (Priority Queuing)
05.11.2007
10
Simple QoS Mechanisms
Full
Arrival
Classifier
The turning switch selects 2 packets
from 1st queue, then 1 packet from 2nd
queue and the cycle repeats
N
Weight: 2
Y
Discard
Full
Processor
Departure
N
Y
Discard
Weight: 1
Scheduling (Weighted Fair Queuing)
Leaky Bucket (Regulate the traffic)
05.11.2007
Token Bucket (Credit an idle host)
11
Simple QoS Mechanisms
Arriving Packet
Arriving Packet
Queue
Queue
Accepted
Dropped
Dropped from front
Full
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
QoS Architectures for Internet
•
Integrated Services (IntServ)
–
Flow Based QoS 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 (DiffServ)
–
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 QoS)
•
Multiprotocol Label Switching (MPLS)
–
Not primarily a QoS 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>
<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)
•
•
•
•
•
(H1, H2, H3, H4, H5) : both senders and receivers
multicast group m1
no filtering: packets from any sender forwarded
audio rate: b
only one multicast routing tree possible
H3
H2
R1
R2
R3
H4
H1
H5
05.11.2007
audio conference
20
Building up Path State
• H1, …, H5 all send path messages on m1:
(address=m1, Tspec=b, filter-spec=no-filter, refresh=100)
• Suppose H1 sends first path message
m1:
m1:
in L1
out
L2 L6
in
L7
out L3 L4
L6
m1: in
out L5
L7
H3
H2
L3
L2
H1
L1
R1
L6
R2
L5
L7
R3
L4
H4
H5
05.11.2007
21
Building up Path State
• next, H5 sends path message, creating
more state in routers
m1:
L6
L1
m1: in
out L1 L2 L6
in
L7
out L3 L4
L5 L6
m1: in
out L5 L6 L7
H3
H2
L3
L2
H1
L1
R1
L6
R2
L5
L7
R3
L4
H4
H5
05.11.2007
22
Building up Path State
• H2, H3, H5 send path msgs, completing
path state tables
m1:
L1 L2 L6
m1: in
out L1 L2 L6
in L3 L4 L7
out L3 L4 L7
L5 L6 L7
m1: in
out L5 L6 L7
H3
H2
L3
L2
H1
L1
R1
L6
R2
L5
L7
R3
L4
H4
H5
05.11.2007
23
Receiver Reservation
H1 wants to receive audio from all other senders
• H1 reservation msg flows uptree to sources
• H1 only reserves enough bandwidth for 1 audio stream
• reservation is of type “no filter” – any sender can use
reserved bandwidth
H3
H2
L3
L2
H1
L1
R1
L6
R2
L5
L7
R3
L4
H4
H5
05.11.2007
24
Receiver Reservation
• H1 reservation msgs flows uptree to sources
• routers, hosts reserve bandwidth b needed on
downstream links towards H1
m1: in L1 L2
out L1(b) L2
L6
L6
m1:
L2
H1
b
b
L1
R1
b
L6
L7
L7(b)
L7
L6
L6(b) L7
m1: in L5
out L5
H2
L4
L4
in L3
out L3
b
R2
L5
b
L7
b
R3
L3
b
L4
H3
H4
H5
05.11.2007
25
Receiver Reservation
• next, H2 makes no-filter reservation for bandwidth b
• H2 forwards to R1, R1 forwards to H1 and R2 (?)
• R2 takes no action, since b already reserved on L6
L6
m1: in L1 L2
out L1(b) L2(b) L6
m1:
b
L2
H1
b
b
b L1
R1
b
L6
L7
L7(b)
L7
L6
L6(b) L7
m1: in L5
out L5
H2
L4
L4
in L3
out L3
b
R2
L5
b
L7
b
R3
L3
b
L4
H3
H4
H5
05.11.2007
26
Link Failure
05.11.2007
27
Integrated Services
• Resource reservation
– call setup, signaling (RSVP)
– traffic, QoS declaration
– per-element admission control
request/
reply
– QoS-sensitive
scheduling
(e.g., WFQ)
05.11.2007
28
Router and Service Model
• Flow Descriptor
– filterspec, flowspec
• filterspec is required for
classifier
• flowspec(Tspec, Rspec)
Traffic behavior
QoS
• 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
IntServ 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
DiffServ: Motivation and Design
• Complex processing is moved from core to edge
• Per flow service (IntServ) 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 QoS
• 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
31
DiffServ 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
DiffServ Architecture
Edge router:
r marking
scheduling
 per-flow traffic management
 marks packets as in-profile
and out-profile
b
..
.
Core router:
 per class traffic management
 buffering and scheduling based
on marking at edge
 preference given to in-profile
packets
05.11.2007
33
Multi-Domain Example
Source
Destination
Core Routers
Ingress Router
(police, mark flows)
Domain's Egress Router
(might shape aggregates)
Core Router
(implement PHB for traffic
aggregate)
05.11.2007
Domain's Ingress Router
(classify and police
aggregates)
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
35
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
U1
BB
S1
U2
BB
C1
S2
ISP 2
D
Server 3
C3
C6
Core Network
C7
Server 2
Server 1
U1
U2
05.11.2007
C2
BB
C5
C4
ISP 1
BB
BB
U3
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 QoS
• Supports Multiple protocols like IPv4, IPv6, IPX, AppleTalk 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
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:
Forwarding:
Forwarding:
Longest-match
Lookup
Label Swapping
Label Swapping
41
MPLS Forwarding
05.11.2007
42
MPLS Operation
1a. Routing protocols (e.g. OSPF-TE)
exchange reachability to destination networks
4. LER at egress
removes label and
delivers packet
1b. Label Distribution Protocol (LDP)
establishes label mappings to destination
network
IP
Ingress
IP
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
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.
05.11.2007
45
Label Merging
• Label Switched Path (LSP): A unidirectional connection through multiple
LSRs.
3
7
6
A
B
5
E
6
F
C
2
8
5
6
D
A
5
E
3
B
8
C
D
5
6
F
Multi-point to
Single point tree
routed at Egress
router
05.11.2007
46
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
1a for VoIP data, 1b for billing, and 1c for
alarm & provisioning)
Push
Swap & Push
R1
R2
R2A
Swap
R2B
Pop & Swap
Pop
R2C
R3
R4
IP
05.11.2007
3
2 7
2 6
2 8
4
IP
47
MPLS Traffic Engineering
nt1
d1
Ingress LER
3
2
4
R1
2
R4
R2
1
R3
3
d2
nt2
Egress LER
2
3
1
d3
Ingress LER
nt3
05.11.2007
48
MPLS Traffic Engineering
d1
3
Ingress LER
2
LSP
4
R1
2
R4
1
2
R2
1
05.11.2007
3
d2
Egress LER
LSP
3
d3
R3
Ingress LER
Cost
=2+3+3+3
= 11
49
MPLS Traffic Engineering
d1
Ingress LER
3
4
R1
2
LSR
R4
2
R2
2
1
3
d2
Egress LER
3
Cost = 4 + 1 + 3+2
= 10
1
05.11.2007
R3
d3
Ingress LER
50
MPLS Traffic Engineering
d1
Ingress LER
3
4
R1
2
R2
2
R4
1
2
3
1
d3
05.11.2007
LSR
R3
3
d2
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)
(Explicit Routing)
05.11.2007
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
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
3
05.11.2007
7
3
4
6
7
Failure on working path is detected
2
4
8
6
6
8
5
7
1
5
5
1
Failure occurs and is detected
2
8
2
4
8
6
4
Traffic carried on working path
1
5
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
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.
05.11.2007
59
QoS for Mobile Networks
• Problems:
– Current IP QoS Signaling is not mobility aware (RSVP, DiffServ
etc).
– QoS breaks in new packet path.
– Resources may not be available for the new path.
– Handoff latency.
– Different QoS mechanisms.
• Objectives:
–
–
–
–
05.11.2007
Minimize handoff latency.
Release any old QoS state after handoff as early as possible.
Trigger QoS Signaling as soon as handoff starts.
Deal with multiple QoS mechanisms deployed.
60
A Mobile Environment
[Ref: 9]
• Domain Resource Manager (DRM) controls QoS for one domain
– Maintains up-to-date model of resource usage
– Admission control for reservations
• Supports heterogeneous QoS provisioning
– per-flow reservations, aggregate reservations (DiffServ) 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
[Ref: 7]
HA
Sender
(Correspondent)
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
Router
Proxy
05.11.2007
Router
Proxy
MSpec Proxy
MN
MSpec
Proxy
64
MRSVP Path and Reservation
PATH
Active RESV
Passive RESV
Sender
Router
Router
Proxy
05.11.2007
Router
Proxy
Proxy
MN
Proxy
65
MRSVP - Handoff
Sender
Active Reservation
Router
Passive Reservation
Router
Proxy
Router
Proxy
Proxy
Proxy
Handoff
05.11.2007
MN
MN
66
MRSVP – After Handoff
Sender
Active Reservation
Router
Passive Reservation
Router
Proxy
05.11.2007
Router
Proxy
MN
Proxy
Proxy
67
QoS through Context Transfers
[Ref: 8]
2.
3.
4.
(Fast Handover Signaling)
(Context Transfer)
05.11.2007
68
QoS 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 QoS is difficult
• INSIGNIA uses Adaptive approach
(Fast reservation, Fast restoration,
QoS reporting, and Adaptation
according to network conditions)
05.11.2007
69
INSIGNIA Framework
[Ref: 10]
05.11.2007
70
Reservation Set-up
SERVICE
MODE
RES/BE
1 bit
PAYLOAD BANDWIDTH
INDICATOR INDICATOR
BQ/EQ
BW_IND
1 bit
BANDWIDTH
REQUEST
MAX
Legend
RES/BQ packet
RES/EQ packet
MIN
BE
packet
MAX reserved link
MIN reserved link
16 bits
1 bit
M2
MS
MD
M1
M3
M4
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
M2
MS
M2
MD
M1
M3
Rerouting
Rerouting
M4
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
M3
MS
M1
MD
M3
M4
M5
Rerouting
Rerouting
bottleneck
node
M5
Legend
Packets Received at Destination Mobile Node
05.11.2007
RES
BQ
MIN
Max_BW
Min_BW
BE
EQ
-
Max_BW
Min_BW
[Source: Seoung-Bum Lee’s presentation about INSIGNIA]
RES/BQ packet
RES/EQ packet
BE
packet
MAX reserved link
MIN reserved link
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
Persistent
EQdegradation
degradation
EQ
Scale down to MIN service
MS
MD
M1
M5
bottleneck
node
M4
QOS report : Scale Down
Pkts Received at Destination after “Scaling Down to MINIMUM service
RES
BQ
MIN
Max_BW
Min_BW
BE
EQ
-
-
-
05.11.2007
[Source: Seoung-Bum Lee’s presentation about INSIGNIA]
Legend
RES/BQ packet
RES/EQ packet
BE
packet
MAX reserved link
MIN reserved link
74
Adaptation : Scale Up
constant resource availability
detected
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
M1
M5
bottleneck
bottleneck
node
node
M4
Legend
RES/BQ packet
RES/EQ packet
BE
packet
MAX reserved link
MIN reserved link
05.11.2007
QOS report : Scale Up
Pkts Received at Destination in MIN service
RES
BQ
MAX
[Source: Seoung-Bum Lee’s presentation about INSIGNIA]
Max_BW
Min_BW
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 QoS 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
R1
R2
NE
NE
R3
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 Middleboxes
NSIS Signaling Layer
Protocol for QoS
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 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.
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.
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