Title: Protocols Part II
1Protocols Part II
INF SERV Media Storage and Distribution Systems
2Overview
- Quality-of-Service
- Resource reservation
- Protocols
- IPv4
- IPv6
- Tenet
- ATM
- IntServ
- RSVP
- DiffServ
- MPLS
3Quality-of-Service
4QualityofService (QoS) I
- Many definitions, e.g.QoS represent the set
of those quantitative and qualitative
characteristics of a distributed multimedia
system that are necessary to achieve the required
functionality of an application Vogel et. al.
Distributed Multimedia and QoS A Survey, IEEE
Multimedia 1995 - QoS elements
- specification (parameter set)
- how to describe QoS
- e.g., frames-per-second, color depth, ,
bandwidth, delay, jitter, error rate, - parameter mapping / translation
- negotiation procedure
- how to set up QoS
- peer-to-peer case all components or resources
must agree - different types
- triangular all components (server and network)
allowed to change QoS - bilateral only server allowed to change QoS
- unilateral take is or leave it from client
- reflection in access mechanisms
- how to ensure QoS
- e.g., scheduling
5QualityofService (QoS) II
- Different semantics or classes of QoS
- determines reliability of offered service
- utilization of resources
max
reserved B
unused
available resources
reserved A
6QualityofService (QoS) III
- Best effort QoS
- system tries its best to give a good performance
- no QoS calculation (could be called no effort
QoS) - simple do nothing
- QoS may be violated ? unreliable service
- Deterministic guaranteed QoS
- hard bounds
- QoS calculation based on upper bounds (worst
case) - QoS is satisfied even in the worst case ? high
reliability - over-reservation of resources ? poor utilization
and unnecessary service rejects - QoS values may be less than calculated hard upper
bound
7QualityofService (QoS) IV
- Statistical guaranteed QoS
- QoS values are statistical expressions (served
with some probability) - QoS calculation based on average (or some other
statistic or stochastic value) - resource capabilities can be statistically
multiplexed ? more granted requests - QoS may be temporarily violated ? service not 100
reliable - Predictive QoS
- weak bounds
- QoS calculation based previous behavior of
imposed workload - resource capabilities can be statistically
multiplexed ? more granted requests - possibly more exact workload description (if past
and actual behavior matches) - QoS may be temporarily violated ? service not 100
reliable - QoS values may be less than calculated hard upper
bound
8Resource Reservation
9Resource Reservation I
- Reservations is fundamental for reliable
enforcement of QoS guarantees - per-resource data structure (information about
all usage) - QoS calculations and resource scheduling may be
done based on the resource usage pattern - reservation protocols
- negotiate desired QoS by transferring information
about resource requirements and resource usage
between the end-systems and the intermediate
systems participating in the data transfer - reservation operation
- calculate necessary amount of resources based on
the QoS specifications - reserve resources according to the calculation
(or reject request) - resource scheduling
- enforce resource usage with respect to resource
administration decisions
10Resource Management Phases
Phase 1
users QoS requirements
specification
time
rejection or renegotiation
admission test and calculation of QoS guarantees
negotiation
resource reservation
QoS guarantees to user
confirmation
renegotiation
Phase 2
data transmission
QoS enforcement by proper scheduling
reflection
monitoring and adaptation notification
renegotiation
Phase 3
stream termination
resource deallocation
termination
11Reservation Directions
sender
- Sender oriented
- sender (initiates reservation)
- must know target addresses (participants)
- in-scalable
- good security
- Receiver oriented
- receiver (initiates reservation)
- needs advertisement before reservation
- must know flow addresses
- sender
- need not to know receivers
- more scalable
- in-secure
- Combination
- start sender oriented reservation
- additional receivers join at routers(receiver
based)
1. reserve
3. reserve
data flow
2. reserve
2. reserve
3. reserve
1. reserve
receiver
12Protocols
13Internet Protocol version 4 (IPv4) I
- IP is THE network layer protocol within the
Internet - IPv4
- defined by RFC 791 (1981) STD 5
- unreliable datagram service (neither flow nor
error control) - no fixed routes
- flexibility for path selection
- reordering problems
- not suitable for time critical continuous media
data - but, source routing is optional
- loose specify some router IP addresses to be
passed in order - strict specify all routers to be passed in
order - maximum 64 KB datagrams including headers
- segmentation for smaller subnets (e.g., 1500 B
for standard Ethernet) - reassembly in end-systems IP-layer
14Internet Protocol version 4 (IPv4) II
indication of the abstract parameters of
thequality of service desired somehow
treat high precedence traffic as more important
tradeoff between low-delay, high-reliability,
and high-throughput NOT used, bits now reused
indicates the format of the internet header,
i.e., version 4
length of the internet header in 32 bit words,
and thus points to the beginning of the data
(minimum value of 5)
datagram length (octets) includingheader and
data - allows the lengthof 65,535 octets
fragments allowed flag allowed and last fragment
flag
0 1 2
3 0 1 2 3 4 5 6 7 8 9 0 1 2
3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-------------------------
------- Version IHL Type of
Service Total Length
-------------------------
------- Identification
Flags Fragment Offset
-------------------------
------- Time to Live Protocol
Header Checksum
-------------------------
------- Source
Address
-------------------------
-------
Destination Address
-------------------------
------- Options
Padding
-------------------------
-------
identifying value to aid assembly of fragments
indicate where this fragment belongs in datagram
disable a packet to circulate forever,decrease
value by at least 1 in each node discarded if 0
checksum on the header only TCP, UDP over
payload. Since some header fields change(TTL),
this is recomputed and verified at each point
indicates used transport layer protocol
32-bit address fields. May be configured
differently from small to large networks
options may extend the header. If the options do
not end on a 32-bit boundary, the remaining
fields are padded in the padding field (0s)
15Internet Protocol version 6 (IPv6) I
- IPv6
- defined by RFC 1883 (1995)
- simplified header
label packets which requests special handling by
the IPv6 routers, such as non-default quality of
service or real-time
disable a packet to circulate forever, decrease
value by at least 1 in each node discarded if 0
enables a source to identify the desired
delivery priority of its packets, relative to
other packets from the same source
-----------------------
--------- Version Prio.
Flow Label
-------------------------
------- Payload Length
Next Header Hop Limit
-------------------------
-------
Source Address
------------------------
--------
Destination Address
----------------------
----------
version of protocol, i.e., version 6
length of payload in bytes. If zero, indicates
that the payload length is carried in a Jumbo
Payload option.
Identifies the type of headerimmediately
following the header e.g., TCP, UDP, but also
EXTENSION headers
128-bit address fields
16Internet Protocol version 6 (IPv6) I
- IPv6
- revised by RFC 2460 (1998) obsoletes RFC 1883
- small header modification
-----------------------
--------- Version Prio.
Flow Label
-------------------------
------- Payload Length
Next Header Hop Limit
-------------------------
-------
Source Address
------------------------
--------
Destination Address
----------------------
----------
-----------------------
--------- Version Traffic Class
Flow Label
-------------------------
------- Payload Length
Next Header Hop Limit
-------------------------
-------
Source Address
------------------------
--------
Destination Address
----------------------
----------
the 4-bit priority field has been replaced by an
8-bit traffic class field. To identify and
distinguish between different classes or
priorities
the flow label field has been reduced from 24-bit
to 20-bit
17Internet Protocol version 6 (IPv6) II
- IPv6
- enlarged address space (2128 3.4 x 1038
addresses) - simplified headers reduce packet processing time
- jumbograms allows packets larger than 64 KB
(using a extension header) - strict routing (source can fix route to
destination using a routing extension header) - inclusion of security concepts and mobile
end-systems - may specify only a geographical range for a
multicast session - some support for QoS concepts each packet
header includes ... - ... a 8-bit traffic class field defined by
DiffServ - ... a 20-bit flow label
18Internet Protocol version 6 (IPv6) IV
- Flow labels
- a flow is a sequence of packets sent from the
source to the destination for which the source
desires special handling by the routers - each flow must have same flow label, priority and
addresses - flow pseudo-connection
- before start or during transmission
- set up flow between source and destination
- route is cached table entries in a router
allows fast packet switching - routers can reserve resources
- during data transmission
- routers can identify flows by a unique flow
label/address combination - routers can treat packets according to the flow
type - still experimental use
- BUT IPv6 itself does not define mechanisms for
QoS treatment must use additional protocols
19IP Multicast
- Limiting IP multicast geographically
- IPv4 interpretation of TTL header field is
used(non-standardized MBONE use) - IPv6 multicast address contains a 4-bit scope
field - possible geographical limits
- machine
- LAN
- organization
- country (v4 only)
- continent (v4 only)
- global no limit
20Tenet I
- Late 80s/early 90s, Tenet group at Berkeley
- Aims for network support for real-time continuous
media applications - Real-time communication model
- Real-time channels end-to-end connection with
performance guarantees and traffic restrictions - associated with a set of nodes and links (a
route) through which real-time packets pass - resource reservation in route nodes
- admission control
21Tenet II
- Traffic specification
- expressing peak and average load on the network
- indication of the burstiness of the load
- parameters
- minimum packet inter-arrival time
- average packet inter-arrival time
- averaging interval
- maximum packet size
- Supported QoS parameters (by which users describe
their requirements) - upper bound on end-to-end message delay
- delay violation probability bound
- buffer overflow probability bound
- delay jitter bound (optional)
- a throughput guarantee is obtained from the
traffic specification
22Tenet III
application
real-time messagetransport protocol
continuous media transport protocol
real-time channeladministration protocol
- Protocol suite
- Real-time Channel Administration Protocol (RCAP)
- performs channel setup
- uses the traffic description and performance
requirementto find a route and maps the global
requirement onto local resources - performs admission control and reservations on
the way - Real-time Message Transport Protocol (RMTP)
- intended for message based real-time transport
- Continuous Media Transport Protocol (CMTP)
- offers a stream based interface and a time-driven
mechanism for audio and video - Real-time Internet Protocol (RTIP)
- replaces IP
- schedules packets according to resource
reservations made by RCAP
real-timeinternet protocol
data link layer
physical layer
23Asynchronous Transfer Mode (ATM) I
- Defined by ATM Forum and International
Telecommunication Union (ITU) - Targeted for all kinds of traffic within the same
network (i.e., both continuous and discrete data
types) - A full suite of protocols
- physical layer deals with voltages, bit
timingand framing on the physical medium - ATM layer defines the ATM cell structure
- adaptation layer analogous to the Internet
transport layer supporting different services - IP-over-ATM
- IP rules TCP/IP is used in every end-system?
ATM used as link-layer technology - however, ATM may forward data quickly
- ATM may be used in the Internet backbone running
under IP - uses AAL5 to transport IP datagrams over the ATM
network
ATM adaptation layer (AAL)
ATM layer
ATM physical layer
24Asynchronous Transfer Mode (ATM) II
- Service classes
- constant bit rate (CBR)(real-time, guaranteed
constant rate) - variable bit rate (VBR) real-time and
non-real-time - available bit rate (ABR)(slightly better than
best effort a minimum guarantee, only class
with congestion control) - unspecified bit rate (UBR)(best effort, no
guarantees) - Virtual channels (VC)
- the ATM network sets up a VC between sender and
receiver - a path consisting of a sequence of links
- each link has a virtual circuit identifier (VCI)
used for routing(included in the cell header) - ATM backbones usually use permanent VCs, i.e.,
saving VC setup and teardown - Virtual paths
25Asynchronous Transfer Mode (ATM) III
- The ATM standard specifies a number of QoS
parameters - traffic generation by sender
- cell rate (sustainable (SCR) / peak (PCR) /
minimum (MCR)) - maximum burst size (MBS)
- cell delay variation tolerance (CDVT)
- service provided by network
- cell transfer delay (CTD) cell transit time
from source to destination - cell delay variation (CDV) variance in
transfer delays - cell loss ratio (CLR) fraction of cells lost
or delivered too late - cell error rate (CER) fraction of cells with
bit errors - severly-errored cell block ratio (SECBR)
fraction of an N-cell block with M or more cells
damaged - cell misinsertion rate (CMR) number of cells
delivered to wrong destination
26Asynchronous Transfer Mode (ATM) VI
- Traffic contracts
- the VC acts like a contract between customer and
network for a service - consist of a connection traffic descriptor and a
set of QoS parameters - which traffic to be offered
- which service class
- compliance requirements
- the QoS parameters are negotiated during the VC
setup (can be specified either explicitly or
implicitly)
27Asynchronous Transfer Mode (ATM) V
- Different service categories require different
parameters
28Asynchronous Transfer Mode (ATM) VI
- Application areas for ATM service categories (by
ATM Forum)
3 good 2 fair 1 not good, not applicable
with advantage n/s not suitable
29Integrated Services (IntServ) I
- Framework by IETF to provide individualized QoS
guarantees to individual application sessions - Goals
- efficient Internet support for applications which
require service guarantees - fulfill demands of multipoint, real-time
applications (like video conferences) - do not introduce new data transfer protocols
- In the Internet, it is based on IP (v4 or v6) and
RSVP (described later) - Two key features
- reserved resources the routers need to know
what resources are available (both free and
reserved) - call setup (admission call) reserve resources
on the whole path from source to destination
30Integrated Services (IntServ) II
receiver
- Admission call
- traffic characterization and specification
- one must specify the traffic one willtransmit on
the network (Tspec) - one must specify the requested QoS(Rspec
reservation specification) - signaling for setup
- send the Tspec and Rspec to all routers
- per-element admission test
- each router checks whether the requestsspecified
in the R/Tspecs can be fulfilled - if YES, accept reject otherwise
sender
1. request specify traffic (Tspec), guarantee
(Rspec)
1
3
2. consider request against available resources
3. accept or reject
2
31Integrated Services (IntServ) III
- IntServ introduce two new services enhancing the
Internets traditional best effort - guaranteed service
- guaranteed bounds on delay and bandwidth
- for applications with real-time requirements
- controlled-load service
- a QoS closely to the QoS the same flow would
receive from an unloaded network element RFC
2212, i.e., similar to best-effort in networks
with limited load - no quantified guarantees, but packets should
arrive with a very high percentage - for applications that can adapt to moderate
losses, e.g., real-time multimedia applications
32Integrated Services (IntServ) IV
- Both service classes uses token bucket to police
a packet flow - packets need a token to be forwarded
- each router has a b-sized bucket with tokensif
bucket is empty, one must wait - new tokens are generated at a rate r and
addedif bucket is full (little traffic), the
token is deleted - the token generation rate r serves to limit the
long term average rate - the bucket size b serves to limit themaximum
burst size
token generation
bucket
token wait queue
33Integrated Services (IntServ) V
application
RTP
UDP
RSVP
IP
data link
34Resource Reservation Protocol (RSVP) - I
- Defined by RFC 2205 (1997)
- A protocol to reserve resources in the Internet
- contains protocol elements for control
- no support for data transfers
- simplex protocol, i.e., makes reservations for
unidirectional flows - receiver-oriented, i.e., the receiver initiates
and maintains resource reservations - maintains a soft state graceful changes to
dynamic memberships and automatic adaptation to
route changes - companion protocol to IP supports both IPv4 and
IPv6 - transported as raw IP datagram with protocol
number 46 - filtering provides support for heterogeneous
receivers and different reservation styles
35Resource Reservation Protocol (RSVP) - II
- RSVP will generally require raw network I/O
- sends raw IP datagrams using protocol 46
- operates on top of IP, i.e., takes the place of
the transport protocol - does not perform traditional transport layer
services must add a transport protocol (UDP)
application
UDP
RSVP
IP
data link
36Resource Reservation Protocol (RSVP) - III
- Sessions
- a data flow with particular destination and
transport protocol - defined by (destination address, protocol ID)
- IP address
- IP protocol ID
- may carry multiple data flows
- Data flows are distinguished by
- source IP address and source port (IPv4)
- source IP address and flow label (IPv6)
- Transmission model
37Resource Reservation Protocol (RSVP) - IV
- Two fundamental messages
- PATH
- sender sends a PATH message downstream following
the data path - sent using same source and destination addresses
- includes
- hop-addresses
- sender template (describes data packet format)
- sender Tspec (traffic characteristics generated
by sender) - sender Adspec (advertisement information)
- ...
- RESV
- receiver sends a RESV message upstream using the
path described in the PATH message - sent to previous hop only
- includes
- flowspec reservation requests, desired QoS
(e.g., RFC 1363) - filterspec reservation style
- reverse data paths for the flow
- ...
38Resource Reservation Protocol (RSVP) - V
- Creating and maintaining a reservation state
- the SOURCE
- multicasts data flows
- sends PATH messages with traffic characteristics
(Tspec) describing flows - the RECEIVER
- joins multicast group
- receives the PATH message
- determines own QoS requirements based the PATH
Tspec - sends a RESV message with request and filters
- the ROUTERS
- reserve according to incoming flowspecs
downstream - merge and forward the RESV messages to next node
using largest flowspec - the reservations are maintained using soft
states - the reservation has an associated timer a
timeout removes the reservation - periodically refreshed by PATH and RESV messages
39Resource Reservation Protocol (RSVP) - VI
10 Mbps
1 Mbps
RESV10 Mbps
RESV1 Mbps
reserved 10 Mbps
merging
merging
merging
reserved 1 Mbps
PATH
PATH
PATH
PATH
PATH
reserved 10 Mbps
reserved 10 Mbps
reserved 1 Mbps
PATH
RESV10 Mbps
RESV10 Mbps
RESV1 Mbps
5 Kbps
PATH
reserved 5 Kbps
reserved 3 Mbps
RESV5 Kbps
RESV3 Mbps
merging
PATH
PATH
PATH
reserved 3 Mbps
reserved 3 Mbps
RESV3 Mbps
RESV3 Mbps
reserved 1 Mbps
3 Mbps
RESV1 Mbps
1 Mbps
40Resource Reservation Protocol (RSVP) - VII
- RSVP in hosts and routers
- RESV with flowspec and filterspec to RSVP daemon
- policy control to check privileges etc.
- admission control using flowspec
- forward RESV message
- control of local modules classifier and
scheduler
application process
RSVPdaemon
policy control
routing process
RSVPdaemon
policy control
admission control
admission control
packet classifier
packet scheduler
packet classifier
packet scheduler
data
41Resource Reservation Protocol (RSVP) - VIII
- Reservation styles
- a reservation request includes a set of options
called the reservation style - shared vs. distinct reservations
- concerns treatment of reservations of different
senders - shared single reservation for all senders
(e.g., video conference audio) - distinct one reservation per sender (e.g.,
video conference video) - explicit vs. wildcard
- concerns selection of senders
- explicit specify senders (e.g., teleteaching)
- wildcard automatically select all senders
(e.g., video conference)
42Resource Reservation Protocol (RSVP) - IX
43Resource Reservation Protocol (RSVP) - X
- The RSVP standard RFC 2205 allows to reserve
link bandwidth it does NOT... - ...define how the network should provide the
reserved bandwidth to the data flows the
routers must implement these mechanisms
themselves - ...specify how to do resource provisioning
which must likely be done using a proper
scheduling mechanism - ...determine the route it is not a routing
protocol, but relies on others - ...determine which data to drop in case of
overflow, i.e., the most important data may be
lost - ...perform an admission test, but it assumes that
the routers perform admission control - THUS RSVP can only be used as a small piece in
the QoS guarantee puzzle Kurose, J. F., Ross,
K. W. Computer Networking A Top-Down Approach
Featuring the Internet, 2nd edition, Addison
Wesley, 2002
44Differentiated Services (DiffServ) I
- IntServ and RSVP provide a framework for per-flow
QoS, but they - give complex routers
- much information to handle
- have scalability problems
- set up and maintain per-flow state information
- periodically PATH and RESV messages overhead
- specify only a predefined set of services
- new applications may require other flexible
services - DiffServ RFC 2475 tries to be both scalable and
flexible
45Differentiated Services (DiffServ) II
- ISP favor DiffServ
- Basic idea
- multicast is not necessary
- make the core network simple due to many users
- implement more complex control operations at the
edge - aggregation of flows reservations for a group
of flows, not per flow - thus, avoid scalability problems on routers with
many flows - do not specify services or service classes
- instead, provide the functional components on
which services can be built - thus, support flexible services
46Differentiated Services (DiffServ) III
- Two set of functional elements
- edge functions packet classification and traffic
conditioning - core function packet forwarding
- At the edge routers, the packets are tagged with
a DS-mark (differentiated service mark) - uses the type of service field (IPv4) or the
traffic class field (IPv6) - different service classes (DS-marks) receive
different service - subsequent routers treat the packet according to
the DS-mark - classification
- incoming packet is classified (and steered to
the appropriate marker function) using the header
fields - the DS-mark is set by marker
- once marked, forward
classifier
marker
forward
47Differentiated Services (DiffServ) IV
- Note, however, that there is no rules for
classification it is up to the network
provider - A metric function may be used to limit the packet
rate - the traffic profile may define rate and maximum
bursts - if packets arrive too fast, the metric function
assigns another marker function telling the
router to delay or drop the packet
shaper / dropper
classifier
marker
forward
48Differentiated Services (DiffServ) V
- In the core routers, a DS-marked packet is
forwarded according to a per-hop behavior (PHB)
associated with the DS-tag - the PHB determines how the router resources are
used and shared among the competing service
classes - the PHB should be based on the DS-tag only
simple forwarding decisions, no need for
QoS-states for each source-destination pair - packets with same DS-tag are treated equally
regardless of source or destination (traffic
aggregating) - a PHB can result in different service classes
receiving different performance - performance differences must be observable and
measurable to be able to monitor the system
performance - no specific mechanism for achieving these
behaviors are specified- any mechanism can by
used as long as the performance specification is
met
49Differentiated Services (DiffServ) VI
- Currently, two PHBs are under active discussion
- expedited forwarding RFC 3246
- specifies a minimum departure rate of a class,
i.e., a guaranteed bandwidth - the guarantee is independent of other classes,
i.e., enough resources must be available
regardless of competing traffic - assured forwarding RFC 2597
- divide traffic into four classes
- each class is guaranteed a minimum amount of
resources - each class are further partitioned into one of
three drop categories(if congestion occur, the
router drops packets based on drop value)
50Differentiated Services (DiffServ) VII
Edge routeruse header fields to lookup right
DS-tag and mark packet
fast and scalable due to simple core routers
Core routeruse PHB according to DS-tag to
forward packet
51Internet Streaming Protocol, Version 2 (ST-II)
I
application
- ST-II is defined by RFC 1190/1819
- It is a connection-oriented supplement to IP
with two components - ST reservations and data management
- SCMP (ST control message protocol) reliable
control messages - Main concepts
- unreliable data transfers, reliable control
- a negotiated packet size (no fragmentation and
reassembly) - routing tree from sender to multiple receivers
- flow specification describing QoS parameters
during connection setup
transport
link
52Internet Streaming Protocol, Version 2 (ST-II)
II
- The resource reservation is sender-oriented
- SCMP sends a message with a flow specification
- if the routers and the destination accepts the
call, the call is returned (possibly modified) to
the source - typical parameters include
- bandwidth
- delay
- delay variance
- size
accept/reject
connect
connect
53Fast Routing
54Routing
55Routing
209.73.164.90
216.239.51.101
192.67.198.54
80.91.34.111
129.42.16.99
129.240.148.31
81.93.162.20
209.189.226.17
193.99.144.71
66.77.74.20
129.240.148.31
56Routing
216.239.51.101
192.67.198.54
209.73.164.90
80.91.34.111
129.42.16.99
209.189.226.17
129.240.148.31
81.93.162.20
66.77.74.20
129.240.148.31
193.99.144.71
57Routing
216.239.51.101
192.67.198.54
209.73.164.90
80.91.34.111
129.42.16.99
209.189.226.17
129.240.148.31
81.93.162.20
66.77.74.20
129.240.148.31
193.99.144.71
58Routing Speed-up
- ATM
- Virtual Channels and Virtual Path
- RSVP
- IP and Port Mapping
- ST-II
- Hop ID
- MPLS
- Label
59Multiprotocol Label Switching (MPLS)
- Multiprotocol Label Switching
- Separate path determination from hop-by-hop
forwarding - Forwarding is based on labels
- Path is determined by choosing labels
- Distribution of labels
- On application-demand
- LDP label distribution protocol
- By traffic engineering decision
- RSVP-TE traffic engineering extensions to RSVP
60Multiprotocol Label Switching (MPLS)
- MPLS works above multiple link layer protocols
- Carrying the label
- Over ATM
- Virtual path identifier or Virtual channel
identifier - Maybe shim
- Frame Relay
- data link connection identifier (DLCI)
- Maybe shim
- Ethernet, TokenRing,
- Shim
- Shim?
61Multiprotocol Label Switching (MPLS)
Link Layer Header
Shim
Shim
62Routing using MPLS
216.239.51.101
Reserved path for this label
192.67.198.54
209.73.164.90
80.91.34.111
129.42.16.99
Remove label
Added label
209.189.226.17
129.240.148.31
81.93.162.20
66.77.74.20
129.240.148.31
193.99.144.71
63MPLS Label Stack
- The ISP 1
- Classifies the packet
- Assigns it to a reservation
- Performs traffic shaping
- Adds a label to the packet for routers in his net
ISP 3
ISP 2
ISP 2
ISP 1
ISP 1
- The ISP 1
- Buys resources from ISP 2
- The ISP 2
- Repeats classifying, assignment, shaping
- Adds a label for the routers in his net
- He pushes a label on the label stack
64MPLS Label Stack
ISP 3
ISP 2
ISP 2
ISP 1
ISP 1
65The EndSummary
66Summary
- Timely access to resources is important for
multimedia application to guarantee QoS
reservation might be necessary - Many protocols have tried to introduce QoS into
the Internet, but no protocol has yet won the
battle... - often NOT only technological problems, e.g.,
- scalability
- flexibility
- ...
- but also economical and legacy reasons, e.g.,
- IP rules everything must use IP to be useful
- several administrative domains (how to make ISPs
agree) - router manufacturers will not take the high costs
(in amount of resources) for per-flow
reservations - pricing
- ...
67Some References
- ATM Forum, http//www.atmforum.com
- ATM Forum ATM Service Categories,
http//www.atmforum.com/aboutatm/6.html - Danthine, A., Bonaventure, O. From Best Effort
to Enhanced QoS, in Spaniol, O., Danthine, A.,
Effelsberg, W. (Eds.) Architecture and
Protocols for High-Speed Networks, Kluwer
Achademic Publishers, 1994, pp. 179-201 - IETFs Internet RFC/STD/FYI/BCP Archive,
http//www.faqs.org/rfcs/ or http//www.ietf.org/r
fc.html - Kurose, J. F., Ross, K. W. Computer Networking
A Top-Down Approach Featuring the Internet, 2nd
edition, Addison Wesley, 2002 - Steinmetz, R., Nahrstedt, C. Multimedia
Computing, Communications Applications,
Prentice Hall, 1995 - Tenet group http//tenet.berkeley.edu/tenet.html