Protocolos de transporte QoS
Download
Report
Transcript Protocolos de transporte QoS
1Protocolos de transporte con QoS
Clases de aplicaciones multimedia
Redes basadas en IP y QoS
RTP/RTCP: Transporte de flujos multimedia
RTSP: Control de sesión y localización de medios
Multicasting
Computer
Networking: A Top
Down Approach
6th edition
Jim Kurose, Keith Ross
Addison-Wesley
March 2012
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014 – http://www.grc.upv.es/docencia/tra/
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
2
What is multimedia?
Definition of multimedia
Hard to find a clear-cut definition
In general, multimedia is an integration of text, graphics, still
and moving images, animation, sounds, and any other medium
where every type of information can be represented, stored,
transmitted and processed digitally
Characteristics of multimedia
Digital – key concept
Integration of multiple media type, usually including video
or/and audio
May be interactive or non-interactive
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Various Media Types
Text, Graphics, image, video, animation, sound, etc.
Classifications of various media types
Captured vs. synthesized media
Captured media (natural) : information captured from the real world
– Example: still image, video, audio
Synthesized media (artificial) : information synthesize by the
computer
– Example: text, graphics, animation
Discrete vs. continuous media
Discrete media: space-based, media involve the space dimension
only
– Text, Image, Graphics
Continuous media: time-based, media involves both the space and
the time dimension
– Video, Sound, Animation
3
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Classification of Media Type
Sound
Video
Continuous
Image
Discrete
Captured
From real world
4
Animation
Continuous
Text
Graphics
Discrete
Synthesized
By computer
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
5
Text
Plain text
Unformatted
Characters coded in binary form
ASCII code
All characters have the same style and font
Rich text
Formatted
Contains format information besides codes for characters
No predominant standards
Characters of various size, shape and style, e.g. bold, colorful
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Plain Text vs. Rich Text
An example of Plain text
6
Example of Rich text
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Graphics
Revisable document that retains structural information
Consists of objects such as lines, curves, circles, etc
Usually generated by graphic editor of computer
programs
10
5
Example of
graphics (FIG file)
0
-5
-10
4
2
4
2
0
0
-2
7
-2
-4
-4
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Images
2D matrix consisting of pixels
Pixel—smallest element of resolution of the image
One pixel is represented by a number of bits
Pixel depth– the number of bits available to code the pixel
Have no structural information
Two categories: scanned vs. synthesized still image
Digital still image
Camera
8
Computer
software
Synthesized
image
Capture and
A/D conversion
Scanned
image
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
9
Images (cont.)
Examples of images
Binary image – pixel depth 1
Gray-scale – pixel depth 8
Color image – pixel depth 24
Binary image
Gray-scale
colorimage
image
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Video vs. Animation
Both images and graphics can be displayed as a
succession of view which create an impression of
movement
Video – moving images or moving pictures
Captured or Synthesized
Consists of a series of bitmap images
Each image is called a frame
Frame rate: the speed to playback the video (frame per second)
Animation – moving graphics
Generated by computer program (animation authoring tools)
Consists of a set of objects
The movements of the objects are calculated and the view is
updated at playback
1
0
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Sound
1-D time-based signal
0. 2
0. 15
0. 1
0. 05
0
-0. 05
-0. 1
-0. 15
-0. 2
0
100
200
300
400
500
600
700
800
900
1000
Speech vs. non-speech sound
Speech – supports spoken language and has a semantic content
Non-speech – does not convey semantics in general
Natural vs. structured sound
Natural sound – Recorded/generated sound wave represented as
digital signal
Example: Audio in CD, WAV files
Structured sound – Synthesize sound in a symbolic way
1
1
Example: MIDI file
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Networked Multimedia
Local vs. networked multimedia
Local: storage and presentation of multimedia information in
standalone computers
Sample applications: DVD
Networked: involve transmission and distribution of
multimedia information on the network
Sample applications: videoconferencing, web video
broadcasting, multimedia Email, etc.
A scenario of multimedia networking
Video server
1
2
Internet
Image server
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
1
3
Consideration of Networked Multimedia
Requirements of multimedia applications on the network
Typically delay sensitive
end-to-end delay
delay jitter:
– Jitter is the variability of packet delays within the same packet stream
Quality requirement
Satisfactory quality of media presentation
Synchronization requirement
Continuous requirement (no jerky video/audio)
Can tolerant some degree of information loss
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Technologies of Multimedia Networking
Challenges of multimedia networking
1. Conflict between media size and bandwidth limit of the network
2. Conflict between the user requirement of multimedia application
and the best-effort network
3. How to meet different requirements of different users?
Media compression – reduce the data volume
Address the 1st challenge
Image compression
Video compression
Audio compression
Multimedia transmission technology
1
4
Address the 2nd and 3rd challenges
Protocols for real-time transmission
Rate / congestion control
Error control
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Multimedia Networking Systems
Live media transmission system
Capture, compress, and transmit the media on the fly
(example?)
Send stored media across the network
Media is pre-compressed and stored at the server. This system
delivers the stored media to one or multiple receivers.
(example?)
Differences between the two systems
For live media delivery:
Real-time media capture, need hardware support
Real-time compression– speed is important
Compression procedure can be adjusted based on network
conditions
For stored media delivery
1
5
Offline compression – better compression result is important
Compression can not be adjusted during transmission
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Multimedia networking: 3 application types
streaming, stored audio, video
streaming: can begin playout before downloading entire file
stored (at server): can transmit faster than audio/video will be
rendered (implies storing/buffering at client)
e.g., YouTube, Netflix, Hulu
conversational voice/video over IP
interactive nature of human-to-human conversation limits delay
tolerance
e.g., Skype
streaming live audio, video
e.g., live sporting event (futbol)
1
6
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Streaming stored video:
1. video
recorded
(e.g., 30
frames/sec)
2. video
sent
network delay
(fixed in this
example)
3. video received,
played out at client
(30 frames/sec)
streaming: at this time, client
playing out early part of video,
while server still sending later
part of video
time
constant bit
rate video
transmission
client video
reception
variable
network
delay
constant bit
rate video
playout at client
buffered
video
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Streaming stored video: revisted
client playout
delay
client-side buffering and playout delay: compensate
for network-added delay, delay jitter
time
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Client-side buffering, playout
buffer fill level,
Q(t)
playout rate,
e.g., CBR r
variable fill
rate, x(t)
video server
client application
buffer, size B
client
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Client-side buffering, playout
buffer fill level,
Q(t)
playout rate,
e.g., CBR r
variable fill
rate, x(t)
video server
client application
buffer, size B
client
1. Initial fill of buffer until playout begins at tp
2. playout begins at tp,
3. buffer fill level varies over time as fill rate x(t)
varies and playout rate r is constant
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Client-side buffering, playout
buffer fill level,
Q(t)
playout rate,
e.g., CBR r
variable fill
rate, x(t)
video server
client application
buffer, size B
playout buffering: average fill rate (x), playout rate (r):
x < r: buffer eventually empties (causing freezing of
video playout until buffer again fills)
x > r: buffer will not empty, provided initial playout
delay is large enough to absorb variability in x(t)
initial playout delay tradeoff: buffer starvation less likely with
larger delay, but larger delay until user begins watching
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Streaming multimedia: UDP
server sends at rate appropriate for client
often: send rate = encoding rate =
constant rate
transmission rate can be oblivious to
congestion levels
short playout delay (2-5 seconds) to remove network
jitter
error recovery: application-level, timeipermitting
RTP [RFC 2326]: multimedia payload types
UDP may not go through firewalls
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Streaming multimedia: HTTP
multimedia file retrieved via HTTP GET
send at maximum possible rate under TCP
variable
rate, x(t)
video
file
TCP send
buffer
server
TCP receive
buffer
application
playout buffer
client
fill rate fluctuates due to TCP congestion control,
retransmissions (in-order delivery)
larger playout delay: smooth TCP delivery rate
HTTP/TCP passes more easily through firewalls
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Streaming multimedia: DASH
DASH: D ynamic, A daptive S treaming over H TTP
server:
divides video file into multiple chunks
each chunk stored, encoded at different rates
manifest file: provides URLs for different chunks
client:
periodically measures server-to-client bandwidth
consulting manifest, requests one chunk at a time
chooses maximum coding rate sustainable given
current bandwidth
can choose different coding rates at different
points in time (depending on available
bandwidth at time)
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Streaming multimedia: DASH
DASH: D ynamic, A daptive S treaming over H TTP
“intelligence” at client: client determines
when to request chunk (so that buffer starvation, or overflow
does not occur)
what encoding rate to request (higher quality when more
bandwidth available)
where to request chunk (can request from URL server that is
“close” to client or has high available bandwidth)
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Content distribution networks
challenge: how to stream content (selected from
millions of videos) to hundreds of thousands of
simultaneous users?
option 1: single, large “mega-server”
single point of failure
point of network congestion
long path to distant clients
multiple copies of video sent over outgoing link
….quite simply: this solution doesn’t scale
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Content distribution networks
challenge: how to stream content (selected from
millions of videos) to hundreds of thousands of
simultaneous users?
option 2: store/serve multiple copies of videos at
multiple geographically distributed sites (CDN)
enter deep: push CDN servers deep into many access
networks
close to users
used by Akamai, 1700 locations
bring home: smaller number (10’s) of larger clusters in POPs
near (but not within) access networks
used by Limelight
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
CDN: “simple” content access scenario
Bob (client) requests video http://netcinema.com/6Y7B23V
video stored in CDN at http://KingCDN.com/NetC6y&B23V
1. Bob gets URL for for video
http://netcinema.com/6Y7B23V
from netcinema.com
web page
1
2
6. request video from
KINGCDN server,
streamed via HTTP
netcinema.com
2. resolve http://netcinema.com/6Y7B23V
via Bob’s local DNS
5
3. netcinema’s DNS returns URL
http://KingCDN.com/NetC6y&B23V
4
4&5. Resolve
http://KingCDN.com/NetC6y&B23
via KingCDN’s authoritative DNS,
which returns IP address of KIingCDN
server with video
3
netcinema’s
authorative DNS
KingCDN.com
KingCDN
authoritative DNS
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
CDN cluster selection strategy
challenge: how does CDN DNS select “good” CDN
node to stream to client
pick CDN node geographically closest to client
pick CDN node with shortest delay (or min # hops) to client
(CDN nodes periodically ping access ISPs, reporting results to
CDN DNS)
IP anycast
alternative: let client decide - give client a list of
several CDN servers
client pings servers, picks “best”
Netflix approach
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Case study: Netflix
30% downstream US traffic in 2011
owns very little infrastructure, uses 3rd party services:
own registration, payment servers
Amazon (3rd party) cloud services:
Netflix uploads studio master to Amazon cloud
create multiple version of movie (different
encodings) in cloud
upload versions from cloud to CDNs
Cloud hosts Netflix web pages for user browsing
three 3rd party CDNs host/stream Netflix
content: Akamai, Limelight, Level-3
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Case study: Netflix
Amazon cloud
Netflix registration,
accounting servers
2. Bob browses
Netflix video 2
upload copies of
multiple versions of
video to CDNs
3. Manifest file
returned for
requested video
Akamai CDN
Limelight CDN
3
1
1. Bob manages
Netflix account
4. DASH
streaming
Level-3 CDN
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Voice-over-IP (VoIP)
VoIP end-end-delay requirement: needed to maintain
“conversational” aspect
higher delays noticeable, impair interactivity
< 150 msec: good
> 400 msec bad
includes application-level (packetization,playout), network
delays
session initialization: how does callee advertise IP
address, port number, encoding algorithms?
value-added services: call forwarding, screening,
recording
emergency services: 911
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
VoIP characteristics
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 of data
application-layer header added to each chunk
chunk+header encapsulated into UDP or TCP
segment
application sends segment into socket every 20 msec
during talkspurt
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
VoIP: packet loss, delay
network loss: IP datagram lost due to network
congestion (router buffer overflow)
delay loss: IP datagram arrives too late for playout at
receiver
delays: processing, queueing in network; end-system
(sender, receiver) delays
typical maximum tolerable delay: 400 ms
loss tolerance: depending on voice encoding, loss
concealment, packet loss rates between 1% and 10%
can be tolerated
constant bit
rate
transmission
client
reception
variable
network
delay
(jitter)
constant bit
rate playout
at client
buffered
data
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Delay jitter
client playout
delay
end-to-end delays of two consecutive packets:
difference can be more or less than 20 msec
(transmission time difference)
time
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
VoIP: 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
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
VoIP: 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’
packets
loss
packets
generated
packets
received
playout schedule
p' - r
playout schedule
p-r
time
r
p
p'
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Adaptive playout delay (1)
goal: low playout delay, low late loss rate
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
adaptively estimate packet delay: (EWMA exponentially weighted moving average, recall TCP
RTT estimate):
di = (1-a)di-1 + a (ri – ti)
delay estimate
after ith packet
small constant,
e.g. 0.1
time received - time sent
(timestamp)
measured delay of ith packet
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Adaptive playout delay (2)
also useful to estimate average deviation of delay, v
vi = (1-b)vi-1 + b |ri – ti – di|
estimates di, vi calculated for every received
packet, but used only at start of talk spurt
for first packet in talk spurt, playout time is:
playout-timei = ti + di + Kvi
remaining packets in talkspurt are played out
periodically
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Adaptive playout delay (3)
Q: How does receiver determine whether packet is first in
a talkspurt?
if no loss, receiver looks at successive timestamps
difference of successive stamps > 20 msec -->talk spurt
begins.
with loss possible, receiver must look at both time
stamps and sequence numbers
difference of successive stamps > 20 msec and sequence
numbers without gaps --> talk spurt begins.
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
VoiP: recovery from packet loss (1)
Challenge: recover from packet loss given small tolerable
delay between original transmission and playout
each ACK/NAK takes ~ one RTT
alternative: Forward Error Correction (FEC)
send enough bits to allow recovery without retransmission
(recall two-dimensional parity in Ch. 5)
simple FEC
for every group of n chunks, create redundant chunk by exclusive
OR-ing n original chunks
send n+1 chunks, increasing bandwidth by factor 1/n
can reconstruct original n chunks if at most one lost chunk from
n+1 chunks, with playout delay
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
VoiP: recovery from packet loss (2)
another FEC scheme:
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
non-consecutive loss: receiver can conceal loss
generalization: can also append (n-1)st and (n-2)nd low-bit
rate chunk
“piggyback
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
VoiP: recovery from packet loss (3)
interleaving to conceal loss:
audio chunks divided into
smaller units, e.g. four 5 msec
units per 20 msec audio chunk
packet contains small units from
different chunks
if packet lost, still have most of
every original chunk
no redundancy overhead, but
increases playout delay
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Voice-over-IP: Skype
Skype clients (SC)
proprietary application-layer
protocol (inferred via
reverse engineering)
encrypted msgs
P2P components:
clients: skype peers
connect directly to
each other for VoIP call
super nodes (SN):
skype peers with
special functions
overlay network: among
SNs to locate SCs
login server
Skype
login server
supernode (SN)
supernode
overlay
network
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
P2P voice-over-IP: skype
skype client operation:
1. joins skype network by
contacting SN (IP address
cached) using TCP
2. logs-in (usename,
password) to centralized
skype login server
3. obtains IP address for
callee from SN, SN
overlay
or client buddy list
4. initiate call directly to
callee
Skype
login server
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Skype: peers as relays
problem: both Alice, Bob are
behind “NATs”
NAT prevents outside peer
from initiating connection to
insider peer
inside peer can initiate
connection to outside
relay solution:Alice, Bob maintain
open connection
to their SNs
Alice signals her SN to connect
to Bob
Alice’s SN connects to Bob’s
SN
Bob’s SN connects to Bob over
open connection Bob initially
initiated to his SN
1Protocolos de transporte con QoS.
Clases de aplicaciones multimedia
Redes basadas en IP y QoS
RTP/RTCP: Transporte de flujos
multimedia
RTSP: Control de sesión y localización de
medios
Multicasting
Thanks to :
RADCOM technologies
H. Shulzrinne
Paul. E. Jones (from packetizer.com)
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014 – http://www.grc.upv.es/docencia/tra/
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Requisitos de red.
Se definen 3 parámetros críticos que la red debería
suministrar a las aplicaciones multimedia:
Productividad (Throughput)
Número de bits que la red es capaz de entregar por unidad
de tiempo (tráfico soportado).
CBR (streams de audio y vídeo sin comprimir)
VBR (ídem comprimido)
– Ráfagas (Peak Bit Rate y Mean Bit Rate)
Retardo de tránsito (Transit delay)
Mensaje listo
para envío
Envío del primer
bit del mensaje
Retardo
de acceso
4
8
Primer bit del
mensaje recibido
Ultimo bit del
Mensaje listo
mensaje recibido para recepción
Retardo
Retardo de
de tránsito
transmisión
Retardo extremo-a-extremo
Retardo
de acceso
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Requisitos de red (II).
Varianza del retardo (Jitter)
Define la variabilidad del retardo de una red.
1
2
Emisor
3
t
1
D1
2
D2 = D1
3
D3 > D1
Receptor
t
Jitter físico (redes de conmutación de circuito)
– Suele ser muy pequeño (ns)
LAN jitter (Ethernet, FDDI).
– Jitter físico + tiempo de acceso al medio.
Redes WAN de conmutación de paquete (IP, X.25, FR)
4
9
– Jitter físico + tiempo de acceso + retardo de conmutación de paquete en
conmutadores de la red.
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Internet y las aplicaciones multimedia
¿Qué podemos añadir a IP para soportar los
requerimientos de las aplicaciones multimedia?
Técnicas de ecualización de retardos (buffering)
Protocolos de transporte que se ajusten mejor a las
necesidades de las aplicaciones multimedia:
RTP (Real-Time Transport Protocol) RFC 1889.
RTSP (Real-Time Streaming Protocol) RFC 2326.
Técnicas de control de admisión y reserva de recursos
(QoS)
RSVP (Resource reSerVation Protocol) RFC 2205
Arquitecturas y protocolos específicos:
5
0
Protocolos SIP (RFC 2543), SDP (RFC 2327), SAP (RFC
2974), etc..
ITU H.323
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Internet Protocols
Slide thanks to Henning Schulzrinne
5
1
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Network support for multimedia
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Dimensioning best effort networks
approach: deploy enough link capacity so that congestion
doesn’t occur, multimedia traffic flows without delay or
loss
low complexity of network mechanisms (use current “best effort”
network)
high bandwidth costs
challenges:
network dimensioning: how much bandwidth is “enough?”
estimating network traffic demand: needed to determine how
much bandwidth is “enough” (for that much traffic)
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Providing multiple classes of service
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 versus regular service)
granularity:
differential service
among multiple
classes, not among
individual connections
history: ToS bits
0111
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Multiple classes of service: scenario
H1
H2
H3
R1
R1 output
interface
queue
R2
1.5 Mbps link
H4
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Scenario 1: mixed HTTP and VoIP
example: 1Mbps VoIP, HTTP share 1.5 Mbps link.
HTTP bursts can congest router, cause audio loss
want to give priority to audio over HTTP
R1
R2
Principle 1
packet marking needed for router to distinguish
between different classes; and new router policy to
treat packets accordingly
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Principles for QOS guarantees (more)
what if applications misbehave (VoIP sends higher than
declared rate)
policing: force source adherence to bandwidth allocations
marking, policing at network edge
1 Mbps
phone
R1
R2
1.5 Mbps link
packet marking and policing
Principle 2
provide protection (isolation) for one class from others
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Principles for QOS guarantees (more)
allocating fixed (non-sharable) bandwidth to flow:
inefficient use of bandwidth if flows doesn’t use its
allocation
1 Mbps
phone
1 Mbps logical link
R1
R2
1.5 Mbps link
0.5 Mbps logical link
Principle 3
while providing isolation, it is desirable to use
resources as efficiently as possible
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
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
real-world example?
discard policy: if packet arrives to full queue: who to discard?
tail drop: drop arriving packet
priority: drop/remove on priority basis
random: drop/remove randomly
packet
arrivals
queue
link
(waiting area) (server)
packet
departures
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Scheduling policies: priority
high priority queue
(waiting area)
priority scheduling: send
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.
real world example?
arrivals
departures
classify
low priority queue
(waiting area)
link
(server)
2
5
4
1 3
arrivals
packet
in
service
1
4
2
3
5
departures
1
3
2
4
5
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Scheduling policies: still more
Round Robin (RR) scheduling:
multiple classes
cyclically scan class queues, sending one complete
packet from each class (if available)
real world example?
2
5
4
1 3
arrivals
packet
in
service
1
2
3
4
5
departures
1
3
3
4
5
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Scheduling policies: still more
Weighted Fair Queuing (WFQ):
generalized Round Robin
each class gets weighted amount of service in each
cycle
real-world example?
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
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
ppm peak rate
(max.) burst size: max number of pkts sent consecutively
(with no intervening idle)
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Policing mechanisms: implementation
token bucket: limit input to specified burst size and
average rate
bucket can hold b tokens
tokens generated at rate r token/sec unless bucket full
over interval of length t: number of packets admitted
less than or equal to (r t + b)
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Policing and QoS guarantees
token bucket, WFQ combine to provide guaranteed
upper bound on delay, i.e., QoS guarantee!
arriving
traffic
token rate, r
bucket size, b
per-flow
rate, R
WFQ
arriving
traffic
D = b/R
max
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Differentiated services
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
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Diffserv architecture
marking
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 in-profile
packets over out-of-profile
packets
r
b
scheduling
..
.
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Edge-router packet marking
profile: pre-negotiated rate r, bucket size b
packet marking at edge based on per-flow
profile
rate r
b
user packets
possible use of marking:
class-based marking: packets of different classes marked
differently
intra-class marking: conforming portion of flow marked
differently than non-conforming one
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Diffserv packet marking: details
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)
determine PHB that the packet will receive
2 bits currently unused
DSCP
unused
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Classification, conditioning
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
7-70
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Forwarding Per-hop Behavior (PHB)
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
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Forwarding PHB
PHBs proposed:
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
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Per-connection QOS guarantees
basic fact of life: can not support traffic demands
beyond link capacity
1 Mbps
phone
1 Mbps
phone
R1
R2
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
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
QoS guarantee scenario
resource reservation
call setup, signaling (RSVP)
traffic, QoS declaration
per-element admission control
request/
reply
QoS-sensitive scheduling
(e.g., WFQ)
1Protocolos de transporte multimedia.
Clases de aplicaciones multimedia
Redes basadas en IP y QoS
RTP/RTCP: Transporte de flujos
multimedia
RTSP: Control de sesión y
localización de medios
Multicasting
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014 – http://www.grc.upv.es/docencia/tra/
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
7
6
RTP (Real-time Transport Protocol)
Se basa en el concepto de sesión: la asociación entre un
conjunto de aplicaciones que se comunican usando RTP
Una sesión es identificada por:
Una dirección IP multicast
Dos puertos: Uno para los datos y otro para control
(RTCP)
Un participante (participant) puede ser una máquina o
un usuario que participa en una sesión
Cada media distinto es trasmitido usando una sesión
diferente.
Por ejemplo, si se quisiera transmitir audio y vídeo
harían falta dos sesiones separadas Esto permite
a un participante solamente ver o solamente oír
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
RTP (Real-time Transport Protocol)
Audio-conferencia con multicast y RTP
Sesión de audio: Una dirección multicast y dos puertos
Datos de audio y mensajes de control RTCP.
Existirá (al menos) una fuente de audio que enviará un stream de
segmentos de audio pequeños (20 ms) utilizando UDP.
A cada segmento se le asigna una cabecera RTP
La cabecera RTP indica el tipo de codificación (PCM, ADPCM, LPC, etc.)
Número de secuencia y fechado de los datos.
Control de conferencia (RTCP):
Número e identificación de participantes en un instante dado.
Información acerca de cómo se recibe el audio.
Audio y Vídeo conferencia con multicast y RTP
Si se utilizan los dos medios, se debe crear una sesión RTP
independiente para cada uno de ellos.
Una dirección multicast y 2 puertos por cada sesión.
Existencia de participantes que reciban sólo uno de los medios.
Temporización independiente de audio y vídeo.
7
7
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
7
8
RTP: Mezcladores y traductores
Mezcladores (Mixers).
Permiten que canales con un BW bajo puedan participar en una
conferencia. El mixer re-sincroniza los paquetes y hace todas las
conversiones necesarias para cada tipo de canal.
Traductores (Translators).
Permiten conectar sitios que no tienen acceso multicast (p.ej.
que están en una sub-red protegida por un firewall)
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
RTP: Formato de mensaje (I)
32 bits
V PX
CC M
PT
Sequence number
Timestamp
Synchronization Source (SSRC) ID
Contributing Source (CSRC) ID
V: versión; actualmente es la 2
P: si está a 1 el paquete tiene bytes de relleno (padding)
X: presencia de una extensión de la cabecera
7
9
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
RTP: Formato de mensaje (II)
32 bits
V PX
CC M
PT
Sequence number
Timestamp
Synchronization Source (SSRC) ID
Contributing Source (CSRC) ID
CC: Identifica el número de CSRC que contribuyen a los datos
M: Marca (definida según el perfil)
PT: Tipo de datos (según perfil)
8
0
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
RTP: Formato de mensaje (III)
32 bits
V PX
CC M
PT
Sequence number
Timestamp
Synchronization Source (SSRC) ID
Contributing Source (CSRC) ID
8
1
Sequence number: Establece el orden de los paquetes
Timestamp: Instante de captura del primer octeto del campo de datos
SSRC: Identifica la fuente de sincronización
CSRC: Fuentes que contribuyen
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
8
2
RTP header definition
/*
* RTP data header
*/
typedef struct {
unsigned int version:2;
unsigned int p:1;
unsigned int x:1;
unsigned int cc:4;
unsigned int m:1;
unsigned int pt:7;
u_int16 seq;
u_int32 ts;
u_int32 ssrc;
u_int32 csrc[1];
} rtp_hdr_t;
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
8
3
RTP y las aplicaciones
La especificación de
RTP para una
aplicación particular va
acompañada de:
Un perfil (profile) que
defina un conjunto de
códigos para los tipos
de datos transportados
(payload)
El formato de
transporte de cada uno
de los tipos de datos
previstos
Ej.: RFC 1890 para audio y vídeo
PT
encoding audio/video clock rate channels
name
(A/V)
(Hz)
(audio)
______________________________________________
0
PCMU
A
8000
1
1
1016
A
8000
1
2
G721
A
8000
1
3
GSM
A
8000
1
...
34-71 unassigned
?
72-76 reserved
N/A
N/A
N/A
77-95 unassigned
?
96-127 dynamic
?
PCMU
Corresponde a la recomendación CCITT/ITU-T
G.711. El audio se codifica con 8 bits por
muestra, después de una cuantificación
logarítmica. PCMU es la codificación que se
utiliza en Internet para un media de tipo
audio/basic.
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
8
4
RTCP (RTP Control Protocol)
RTCP se basa en envíos periódicos de paquetes de
control a los participantes de una sesión RTP
Permite realizar una realimentación de la calidad de
recepción de los datos (estadísticas).
Los paquetes de control siempre llevan la
identificación de la fuente RTP: CNAME
Asociar más de una sesión a un mismo fuente
(sincronización).
El envío de estos paquetes debe ser controlado por
cada participante (sistema ampliable).
Control de sesión (opcional)
Información adicional de cada participante.
Entrada y salida de participantes en las sesión.
Negociación de parámetros y formatos.
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
8
5
RTCP (RTP Control Protocol)
RTCP permite controlar el trafico que no se auto-limita
(p.ej cuando el número de fuentes aumenta)
Para ello se define el ancho de banda de la sesión. RTCP
se reserva el 5% (bwRTCP)
A cada fuente se le asigna 1/4 de bwRTCP
El intervalo entre cada paquete RTCP es > 5 sec
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
RTCP (RTP Control Protocol)
Formato de un paquete RTCP:
Existen distintos tipos de paquetes RTCP:
SR (Sender Report): Informes estadísticos de transmisión y
recepción de los elementos activos en la sesión.
RR (Receiver Report): Informes estadísticos de recepción
en los receptores.
SDES (Source Description): Información del participante
(CNAME, e-mail, etc).
BYE: Salida de la sesión.
APP: Mensajes específicos de la aplicación.
Cada paquete RTCP tiene su propio formato.
Su tamaño debe ser múltiplo de 32 bits (padding).
Se pueden concatenar varios paquetes RTCP en uno
(compound RTCP packet).
8
6
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
RTCP: Mensajes SR
32 bits
Sender
info
Report
block 1
8
7
RC
PT=SR=200
Longitud
SSRC del sender
NTP timestamp msw
NTP timestamp lsw
RTP timestamp
Contador de los paquetes del sender
cabecera V P
Contador de los bytes del sender
SSRC_1
Frac perd
Total paquetes perdidos
Num sec más alto recibido
Jitter de inter-llegada
Ultimo SR (LSR)
Retraso del último SR (LSR)
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
8
8
RTCP: Cálculo del Jitter
Es una estimación de la variancia del tiempo de interllegada de los paquetes RTP
D(i, j ) ( R j - Ri ) - (S j - Si ) ( R j - S j ) - ( Ri - Si )
Si RTP timestamp del paquete i
Ri Instante de llegada del paquete i
J i J i -1 Di - 1, i - J i -1 / 16
1Protocolos de transporte multimedia.
Clases de aplicaciones multimedia
Redes basadas en IP y QoS
RTP/RTCP: Transporte de flujos
multimedia
RTSP: Control de sesión y
localización de medios
Multicasting
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014 – http://www.grc.upv.es/docencia/tra/
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
9
0
Real-Time Streaming Protocol
RFC 2326
Tiene la función de un “mando a distancia por la red”
para servidores multimedia
Permite establecer y controlar uno o más flujos de datos
sincronizados
NO existe el concepto de conexión RTSP sino de sesión
RTSP
Además, una sesión RTSP no tiene relación con ninguna
conexión especifica de nivel transporte (p.ej. TCP o
UDP)
Los flujos de datos no tienen por que utilizar RTP
Está basado en HTTP/1.1
Diferencias importantes:
No es stateless
Los clientes y servidores pueden generar peticiones
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Terminología RTSP
Conferencia
Media stream
Una instancia única
de un medio
continuo:
Un stream audio,
Un stream vídeo
Una “whiteboard”
Voz del
conferenciante
Imagen de las
transparencias
Imagen del
conferenciante
Presentación:
Es el conjunto de
uno o más streams,
que son vistos por el
usuario como un
conjunto integrado
9
1
Imagen del
público
Voz del
público
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
RTSP: Ejemplo de una sesión
HTTP GET
Cliente
SETUP
PLAY
RTP audio
RTP vídeo
RTCP
PAUSE
TEARDOWN
9
2
Web
server
descripción de la sesión
Media
server
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
RTSP: Comandos de petición
Request =
Request-Line ;
*( general-header | request-header | entity-header )
CRLF
[ message-body ]
Request-Line = Method SP Request-URI SP RTSP-Version CRLF
Method
=
"DESCRIBE“ | "ANNOUNCE" | "GET_PARAMETER" |
"OPTIONS“
| "PAUSE" | "PLAY" | "RECORD" |
"REDIRECT" | "SETUP" | "SET_PARAMETER" |
"TEARDOWN" | extension-method
extension-method = token
Request-URI = "*" | absolute_URI
RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT
9
3
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
RTSP: Mensajes de respuesta
Response =
*(
|
|
Status-Line ;
general-header
response-header
entity-header )
CRLF
[ message-body ]
Status-Line = RTSP-version SP Status-Code SP Reason-Phrase CRLF
Status-Code =
1xx: Información (Comando recibido, procesando,..) |
2xx: Exito (Comando recibido y ejecutado con éxito) |
3xx: Re-dirección (Comando recibido pero aún no completado) |
4xx: Error del cliente (El comando tiene errores de sintaxis) |
5xx: Error del servidor (Error interno del servidor)
9
4
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
RTSP: Una sesión completa (I)
1
2
media server A
4
web server W
cliente C
3
media server V
C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com
Accept: application/sdp
W->C: HTTP/1.0 200 OK
Content-Type: application/sdp
9
5
v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session
m=audio 0 RTP/AVP 0
a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31
a=control:rtsp://video.example.com/twister/video
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
RTSP: Una sesión completa (II)
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 1
Transport: RTP/AVP/UDP;unicast;client_port=3056-3057
A->C: RTSP/1.0 200 OK
CSeq: 1
Session: 12345678
Transport: RTP/AVP/UDP;unicast;client_port=3056-3057;
server_port=5000-5001
C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 1
Transport: RTP/AVP/UDP;unicast;client_port=3058-3059
V->C: RTSP/1.0 200 OK
CSeq: 1
Session: 23456789
Transport: RTP/AVP/UDP;unicast;client_port=3058-3059;
server_port=5002-5003
9
6
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
9
7
RTSP: Una sesión completa (III)
C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 2
Session: 23456789
Range: smpte=0:10:00V->C: RTSP/1.0 200 OK
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-0:20:00
RTP-Info: url=rtsp://video.example.com/twister/video;
seq=12312232;rtptime=78712811
C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 2
Session: 12345678
Range: smpte=0:10:00A->C: RTSP/1.0 200 OK
CSeq: 2
Session: 12345678
Range: smpte=0:10:00-0:20:00
RTP-Info: url=rtsp://audio.example.com/twister/audio.en;
seq=876655;rtptime=1032181
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
RTSP: Una sesión completa (IV)
C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 3
Session: 12345678
A->C: RTSP/1.0 200 OK
CSeq: 3
C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 3
Session: 23456789
V->C: RTSP/1.0 200 OK
CSeq: 3
9
8
1Protocolos de transporte multimedia.
Clases de aplicaciones multimedia
Redes basadas en IP y QoS
Gestión de los recursos: IntServ vs
DiffServ
RSVP
RTP/RTCP: Transporte de flujos
multimedia
RTSP: Control de sesión y
localización de medios
Multicasting
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014 – http://www.grc.upv.es/docencia/tra/
1
0
0
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Multicast = Efficient Data Distribution
Src
Src
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
1
0
1
Why Multicast ?
Need for efficient one-to-many delivery of same data
Applications:
News/sports/stock/weather updates
Distance learning
Configuration, routing updates, service location
Pointcast-type “push” apps
Teleconferencing (audio, video, shared whiteboard, text editor)
Distributed interactive gaming or simulations
Email distribution lists
Content distribution; Software distribution
Web-cache updates
Database replication
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
1
0
2
Why Not Broadcast or Unicast?
Broadcast:
Send a copy to every machine on the net
Simple, but inefficient
All nodes must process packet even if they don’t care
Wastes more CPU cycles of slower machines (“broadcast
radiation”)
Network loops lead to “broadcast storms”
Replicated Unicast:
Sender sends a copy to each receiver in turn
Receivers need to register or sender must be pre-configured
Sender is focal point of all control traffic
Reliability => per-receiver state, separate sessions/processes at
sender
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Multicast Apps Characteristics
Number of (simultaneous) senders to the group
The size of the groups
Number of members (receivers)
Geographic extent or scope
Diameter of the group measured in router hops
The longevity of the group
Number of aggregate packets/second
The peak/average used by source
Level of human interactivity
Lecture mode vs interactive
Data-only (eg database replication) vs multimedia
1
0
3
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
1
0
4
Reliable Multicast vs. Unreliable Multicast
When a multicast message is sent by a process, the
runtime support of the multicast mechanism is
responsible for delivering the message to each process
currently in the multicast group.
As each participating process may be on a separate
host, due to factors such as failures of network links
and/or network hosts, routing delays, and differences in
software and hardware, the time between when a
message is sent and when it is received may vary
among the recipient processes.
Moreover, a message may not be received by one or
more of the processes at all.
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
1
0
5
Classification of multicasting mechanisms in terms of message
delivery
Unreliable multicast:
The arrival of the correct message at each process is not
guaranteed.
Reliable multicast:
Guarantees that each message is eventually delivered in a noncorrupted form to each process in the group.
The definition of reliable multicast requires that each
participating process receives exactly one copy of each
message sent. It does not put any restriction of the
order the messages delivered.
Reliable multicast can be further classified based on the
order of the delivery of the messages: unordered, FIFO,
causal order, atomic order.
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
1
0
6
Classification of reliable multicast -- unordered
An unordered reliable multicast system guarantees the
safe delivery of each message, but it provides no
guarantee on the delivery order of the messages.
Example: Processes P1, P2, and P3 have formed a
multicast group. Three messages, m1, m2, m3 have
been sent to the group. An unordered reliable multicast
system may deliver the messages to each of the three
processes in any of these:
m1-m2-m3,
m1-m3-m2,
m2-m1-m3,
m2-m3-m1,
m3-m1-m2,
m3-m2-m1
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Classification of reliable multicast - FIFO
If process P sent messages mi and mj, in that order,
then each process in the multicast group will be
delivered the messages mi and mj, in that order.
Note that FIFO multicast places no restriction on the
delivery order among messages sent by different
processes. For example, P1 sends messages m11 then
m12, and P2 sends messages m21 then m22. It is
possible for different processes to receive any of the
following orders: m11-m12-m21-m22,
m11-m21-m12-m22,
m11-m21-m22-m12,
m21-m11-m12-m22
m21-m11-m22-m12
m21-m22-m11-m12.
1
0
7
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
1
0
8
Classification of reliable multicast – Causal order
If message mi causes (results in) the occurrence of
message mj, then mi will be delivered to each process
prior to mj. Messages mi and mj are said to have a
causal or happen-before relationship.
For example, P1 sends a message m1, to which P2
replies with a multicast message m2. Since m2 is
triggered by m1, the two messages share a causal
relationship of m1-> m2. A causal-order multicast
message system ensures that these two messages will
be delivered to each of the processes in the order of
m1- m2.
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
Classification of reliable multicast –
Atomic order
In an atomic-order multicast system, all messages are
guaranteed to be delivered to each participant in the
exact same order. Note that the delivery order does not
have to be FIFO or causal, but must be identical for
each process.
Example:
P1 sends m1, P2 sends m2, and P3 sends m3.
An atomic system will guarantee that the messages will
be delivered to each process in only one of the six
orders:
m1-m2- m3, m1- m3- m2, m2- m1-m3,
m2-m3-m1, m3-m1- m2, m3-m2-m1.
1
0
9
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
IP Multicast Architecture
Service model
Host-to-router protocol
(IGMP)
Routers
Multicast routing protocols
(various)
1
1
0
Hosts
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
IP Multicast model: RFC 1112
Message sent to multicast “group” (of receivers)
Senders need not be group members
A group identified by a single “group address”
Use “group address” instead of destination address in IP packet sent to
group
Groups can have any size;
Group members can be located anywhere on the Internet
Group membership is not explicitly known
Receivers can join/leave at will
Packets are not duplicated or delivered to destinations outside the
group
Distribution tree constructed for delivery of packets
No more than one copy of packet appears on any subnet
Packets delivered only to “interested” receivers => multicast delivery
tree changes dynamically
Network has to actively discover paths between senders and receivers
1
1
1
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
1
1
2
IP Multicast Addresses
Class D IP addresses
224.0.0.0 – 239.255.255.255
1 110
Group ID
Address allocation:
Well-known (reserved) multicast addresses, assigned by IANA:
224.0.0.x and 224.0.1.x Transient multicast addresses, assigned
and reclaimed dynamically, e.g., by “sdr” program
Each multicast address represents a group of arbitrary
size, called a “host group”
There is no structure within class D address space like
subnetting => flat address space
TECNOLOGÍAS DE RED AVANZADAS – Master IC 2013-2014
IP Multicast Service
Sending
Uses normal IP-Send operation, with an IP multicast address
specified as the destination
Must provide sending application a way to:
Specify outgoing network interface, if >1 available
Specify IP time-to-live (TTL) on outgoing packet
Enable/disable loop-back if the sending host is/isn't a member of
the destination group on the outgoing interface
Receiving
Two new operations
Join-IP-Multicast-Group(group-address, interface)
Leave-IP-Multicast-Group(group-address, interface)
Receive multicast packets for joined groups via normal IPReceive operation
1
1
3