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   Di - 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