Transcript IP_tec - iptel.org

Transporting Multimedia
Data in the Internet
Dr. Dorgham Sisalem
Tekelec
[email protected]
These presentation materials describe Tekelec's present plans to develop and make available to its customers certain
products, features and functionality. Tekelec is only obligated to provide those deliverables specifically included in a
written agreement signed by Tekelec and customer.
IP Based Multimedia Communication
•
Audio/Video samples are digitized, compressed and sent in IP
packets
•
Compression schemes use limitations of human ears/eyes to reduce
bandwidth
•
Reduce audio bandwidth using silence suppression
•
Reduce video bandwidth using motion detection
•
Media data needs to be transported from sender to receiver
•
Media data differ in their characteristics
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Media Exchange
D/A
A/D
encoding
packetization
OS
FCFS
Route
lookup
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
decoding
OS
Example audio encoding techniques
G.711
G.729
•
PCM (non-linear)
•
CS-ACELP
•
4KHz bandwidth
•
4KHz bandwidth
•
64Kb/s
•
8Kb/s
G.722
G.723.1
•
SB-ADPCM
•
MP-MLQ
•
48/56/64Kb/s
•
5.3/6.3Kb/s
•
4-8KHz bandwidth
•
4KHz bandwidth
G.728
GSM
•
LD-CELP
•
RPE/LTP
•
4KHz bandwidth
•
4KHz
•
16Kb/s
•
13Kb/s
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Example video encoding techniques
MPEG1
•
H.261 and H.263
Up to 1.5Mb/s
•
n  64Kb/s, 1 n  30
MPEG2
•
Up to 10Mb/s (HDTV quality)
MPEG4
•
5-64Kb/s (mobile, PSTN)
•
2Mb/s (TV quality)
•
MPEG7, MPEG21
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Streaming Media
sender
 not interactive
 Delay

Less stringent
 loss

Stringent, (can be long for the first
packet but should then not vary a
lot)
 Rate

Need a minimum but can vary (as
long as the play out buffer does
not become empty)
 Data constantly generated and
played out
player
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Video/Audio Communication
sender
 person-to-person
 interactive
 Delay

Stringent (should be small and
constant)
 Loss

Could be tolerated (depending on the
situation and language)
 Rate

Need a minimum and should not vary a
lot
 Data constantly generated and played
out

Except for silence suppression
player
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
What are transport protocols needed for?
•
Addressing: application to application addressing
•
Reliable delivery (if needed) the receiver application should receive the same data stream
the source puts on the net
•
Segment order maintenance: data segments should reach the application in the same
order they left the sender
•
Flow control: the data sending speed should adapt itself to the receivers speed
•
Congestion control: the transmission speed can not be faster than the speed of the slowest
link traversed on the connections path
•
Segmentation: data is sent in segments that provide the highest throughout.
•
Media transport protocols should further inform the receiver about the content of the data
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Application Addressing
•
IP addresses enable us to get from
192.22.22.22
one device to another
195.33.33.33
•
Port numbers allow us to address
one process at a device
77777 88888
80
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Internet Transport Protocols
•
We will focus on the two main Internet transport protocols: UDP and
TCP.
•
Transmission Control Protocol (TCP)
 Connection oriented protocol intended to provide a reliable end-to-end
byte stream over an unreliable network.
•
User Datagram Protocol (UDP)
 Connectionless protocol that provides an unreliable end-to-end datagram
service.
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Transport Control Protocol
These presentation materials describe Tekelec's present plans to develop and make available to its customers certain
products, features and functionality. Tekelec is only obligated to provide those deliverables specifically included in a
written agreement signed by Tekelec and customer.
TCP (RFC 793)
•
TCP is connection oriented and full duplex.
•
Reliability achieved using acknowledgments, round trip delay estimations and data
retransmission.
•
TCP uses a variable window mechanism for flow control.
•
Congestion control and avoidance is realized using slow start and congestion
avoidance schemes.
•
Specified in RFC 793; corrections and finer details in Host Requirement RFCs 1122
and 1123.
•
Used for FTP, HTTP, mail
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
IP encapsulation of TCP segments
IP datagram
TCP segment
IP header
20 bytes
TCP header
20 bytes
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
TCP data
TCP header
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source Port
|
Destination Port
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Acknowledgment Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
|U|A|P|R|S|F|
|
| Offset| Reserved |R|C|S|S|Y|I|
Window
|
|
|
|G|K|H|T|N|N|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Checksum
|
Urgent Pointer
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Options
|
Padding
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
data
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
TCP connection Establishment
•
Connection establishment is done with a three way handshake
client
SYN 141 (0)win 100, <mss 1024>
SYN 181 (0) win 100, <mss 1024>
ACK 142
ACK 182
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
server
TCP Data Exchange
client
server
142
ACK 143
143
144
ACK 143
•
Gaps in the sequence numbers indicate losses to the receiver
•
Missing or repeated acknowledgements indicate loss to the sender
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Normal TCP connection termination
•
4 segments are needed to terminate a TCP connection
•
Each end must be shut down independently.
 Either end can send a FIN when is it done.
 The other end ACK’s the FIN.
application
CLOSE
FIN
deliver EOF to application
ACK of FIN
FIN
ACK of FIN
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
application
CLOSE
Flow Control in TCP
• TCP uses a sliding window mechanism to adjust the senders
transmission speed to that of the receiver.
• The sliding window specifies the amount of data the sender is
allowed to transmit without receiving additional ACKs.
• ACK segments contain the last correctly received byte and the
number of bytes the receiver is still willing to accept.
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Window Flow Control
RTT
Source
1 2
W
•
W
time
ACKs
data
Destination
1 2
1 2
W
Rate= (W packets x packet size) / RTT
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
1 2
W
time
TCP Congestion Control
•
To avoid congestion in advance, the sender must adapt its transmission
window to the available link bandwidth.
•
On connection establishment TCP uses a window of the size of 1 MSS as
Congestion Window, cwnd.
•
Increase the window size till some loss is noticed
•
Decrease the window after a loss and start increasing again
•
Slow Start: the congestion window is increased by 1 MSS for each
acknowledged segment (exponential increase of cwnd).
•
The receiver also announces how much buffer it still has for the connection
(advertised window)
•
At any time the sender has a transmission window of
min (advertised window, congestion window)
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Slow Start
sender
receiver
cwnd
1
1 RTT
2
data packet
ACK
3
4
5
6
7
8
cwnd  cwnd + 1 (for each ACK)
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Congestion Avoidance
sender
receiver
cwnd
1
2
data packet
ACK
1 RTT
3
4
cwnd  cwnd + 1 (for each cwnd ACKS)
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Congestion Avoidance
•
ssthresh = ½ of window before loss
•
Slow start upto ssthresh
•
Starts when cwnd  ssthresh
 Set at beginning of communication to a large value
 Updated after a loss
•
On each successful ACK:
cwnd  cwnd + 1/cwnd
•
Linear growth of cwnd
each RTT:
cwnd  cwnd + 1
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
TCP Tahoe (Jacobson 1988)
window
SS
time
CA
SS: Slow Start
CA: Congestion Avoidance
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
TCP over Wireless
•
In fixed networks losses are considered as congestion indication
•
In wireless networks losses might occur due to the characteristics of
the physical link
 Reacting to losses in a similar manner as in fixed netwroks is thus
wasteful
 Solutions:

Use a new TCP

Use mechanisms for distinguishing between congestion and wireless losses
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
User Datagram Protocol
These presentation materials describe Tekelec's present plans to develop and make available to its customers certain
products, features and functionality. Tekelec is only obligated to provide those deliverables specifically included in a
written agreement signed by Tekelec and customer.
UDP (RFC 768)
•
UDP is a simple, datagram-oriented protocol.
 Each output operation by a process produces exactly one UDP
datagram, which causes one IP datagram to be sent.
IP datagram
UDP datagram
IP header
20 bytes
UDP header
8 bytes
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
UDP data
UDP header
•
port numbers: used to identify the sending and the receiving
process.
 UDP and TCP modules demultiplex incoming data from IP.
 UDP port numbers are looked at only by UDP.
16-bit source port number
16-bit destination port number
16-bit UDP length
16-bit UDP checksum
data (if any)
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
When should I use UDP?
•
UDP is not reliable!!
•
The amount of data to be transmitted is small.
 The overhead of creating connections and ensuring reliable delivery may
be more work than re-transmitting the entire data set.

•
Signaling protocols
Applications that fit a “query-response” model.
 The response can be used as a positive acknowledgement to the query.

Messaging
•
The application provides its own reliable data delivery mechanism.
•
When minimizing overhead is more important than reliability.
 e.g. video or speech transmission
 You can even turn off UDP checksum
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
UDP vs. TCP Traffic Characteristics
packet/s
packet/s
Sender
p
Receiver
p
loss
time
time
window
SS
CA
time
window
SS
time
CA
SS: Slow Start
CA: Congestion Avoidance
SS: Slow Start
CA: Congestion Avoidance
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
time
Real Time Transport
Protocol
Based on slides by Vincent Roca
These presentation materials describe Tekelec's present plans to develop and make available to its customers certain
products, features and functionality. Tekelec is only obligated to provide those deliverables specifically included in a
written agreement signed by Tekelec and customer.
Real Time Transport Protocol (RTP)
•
Why another transport protocol?
 media content type
 talk spurts
 sender identification
 timing

intra-media synchronization: remove jitter with playout buffers

inter-media synchronization: lip-synch between audio-video
 loss detection
 segmentation and reassembly
 security (encryption)
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
RTP: Functions
•
Standardized by the IETF and used by ITU-T as well
•
Designed to be scalable, flexible and separate data and control
mechanisms
IP
UDP
RTP
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Media content
RTP: Header
V P X M Ct Payload
Sequence number
Timestamp
Synchronization Source Identifier (SSRC)
Contributing Source Identifier (CSRC)
Payload
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
RTP: Header
RTP version
VV P X M CC Payload
Sequence number
Timestamp
Synchronization Source Identifier (SSRC)
Contributing Source Identifier (CSRC)
Payload
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
RTP: Header
Padding for encryption
P X M CC Payload
V P
Sequence number
Timestamp
Synchronization Source Identifier (SSRC)
Contributing Source Identifier (CSRC)
Payload
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
RTP: Header
Extension bit
Allows adding experimental headers
X M CC Payload
V P X
Sequence number
Timestamp
Synchronization Source Identifier (SSRC)
Contributing Source Identifier (CSRC)
Payload
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
RTP: Header
Marker bit
Usage depends on codec and media
(end of frame for example)
V P X M CC Payload
Sequence number
Timestamp
Synchronization Source Identifier (SSRC)
Contributing Source Identifier (CSRC)
Payload
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
RTP: Header
Contributers Count
Number of sources contributing to this packet
Added by mixers and ranges from 0 to 15
V P X M CC Payload
Sequence number
Timestamp
Synchronization Source Identifier (SSRC)
Contributing Source Identifier (CSRC)
Payload
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
RTP: Header
Audio/Video encoding method
V P X M CC Payload
Sequence number
Timestamp
Synchronization Source Identifier (SSRC)
Contributing Source Identifier (CSRC)
Payload
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
RTP: Header
Number of packet incresed by
one for each new packet
V P X M CC Payload
Sequence
number
Sequence number
Timestamp
Synchronization Source Identifier (SSRC)
Contributing Source Identifier (CSRC)
Payload
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
RTP: Header
Different fixed value for each
compression
type (160 for 20 ms at 8000
Hz)
V P X M
CC Payload
Sequence number
Timestamp
Timestamp
Synchronization Source Identifier (SSRC)
Contributing Source Identifier (CSRC)
Payload
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
RTP: Header
A random number identifying the source
V(unique
P X M
Sequence number
per Payload
source)
chosen randomly
 detect and solve collisions
Timestamp
Synchronization Source
Synchronization
sourceIdentifier
identifier(SSRC)
(SSRC)
Contributing Source Identifier (CSRC)
Payload
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
RTP: Header
V P X M Payload
Sequence number
Timestamp sources to this packet
Identify the contributing
Synchronization
Source Identifier (SSRC)
(added by mixers)
Contributing Source Identifier (CSRC)
Payload
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Time management
Two times…
•
RTP time
 Random initial offset (for each stream)
 RTP timestamp present in each data packet
 Describes the sampling instant of the payoad

•
Increases by 160 for packets carrying 20ms worth of samples (160)
NTP time (or wallclock time)
 Absolute time (use Network Time Protocol format)
 NTP timestamp present in each RTCP Sender Report
 Relates RTP time to actual time

Enables inter-stream synchronization
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Real time Transport Control Protocol (RTCP)
•
Separate packets sent on a different port number
•
Packets sent in intervals determined based on number of end
systems and available bandwidth
•
several functions
 feedback on the quality of data distribution
 let everybody evaluate the number of participants
 persistant transport-level canonical name for a source, CNAME

usually: user@host

will not change, even if SSRC does!

provides binding across multiple media tools for a single user
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
RTCP generalities
•
Five RTCP packets
 SR
sender reports
tx and rx statistics from active senders
 RR
receiver reports
rx statistics from other participants, or from
active senders if more than 31 sources
 SDES
source description, including CNAME
 BYE
explicit leave
 APP
application specific extensions
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
RTCP generalities… (cont’)
• distribution
 use same distribution mechanisms as data packets (nm multicast)
 multiple RTCP packets can be concatenated by translators/mixers
 compound RTCP packet
• scalability with session size
 RTCP traffic should not exceed 5% of total session bandwidth
requires an evaluation of number of participants
RTCP tx interval = f(number of participants)
 at least 25% of RTCP bandwidth is for source reports
let new receivers quickly know CNAME of sources!
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
SR RTCP packets
•
includes
 SSRC of sender
 NTP timestamp




identify source of data
when report was sent
RTP timestamp
corresponding RTP time
packet count
total number sent
octet count
total number sent
followed by zero or more receiver report…
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
RR RTCP packets
•
includes
 SSRC of source






identify the source to which
this RR block pertains
fraction lost
since previous RR (SR) sent
(= int(256*lost/expected))
cumul # of packets lost
long term loss
highest seq # received
compare losses
interarrival jitter
smoothed interpacket
distortion
LSR
time when last SR heard
DLSR
delay since last SR
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
SDES RTCP packet
•
Must contain:
 a CNAME item (canonical identifier/name)
•
May contain




a NAME item (real user name)
an EMAIL item
a PHONE item
a LOC item (geographic location)
 a TOOL item (application name)
 a NOTE item (transient msg, e.g. for status)
 a PRIV item (private extension)
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Example of RTCP compound packet
receiver
report
source 3
SDES
compound packet
(single UDP datagram)
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
SSRC
receiver
report
source 2
RTCP packet 2
SSRC
sender
report
SSRC
SR
SSRC
RTCP packet 1
CNAME PHONE
RTP payload
•
RTP is generic… define a payload for each target media!
 Example: MPEG1/2 video packetization
 must follow general guidelines

RFC 2736, December 1999
 Goal:

« every packet received must be usefull !!! »
 Potential problems

over standard Internet packets may be
 lost
 reordered
 fragmented by IP if size > MTU (max tx unit)
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
RTP payload… (cont’)
•
Example of what must not happen!!!
 loss multiplication effect due to bad framing
application
application data unit
Src
RTP
network tx
fragment 1
fragment 2
fragment 3
LOST
RTP
fragment 1
fragment 2
Rx
application
uncomplete data!!!
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
useless!!!
Transport Mechanisms for
Group Communication
Based on slides of Ofer Hadar, Jon Crowcroft
These presentation materials describe Tekelec's present plans to develop and make available to its customers certain
products, features and functionality. Tekelec is only obligated to provide those deliverables specifically included in a
written agreement signed by Tekelec and customer.
Which Applications?
•
Conferencing:
 Audio/video communication and application sharing
 First multicast session IETF 1992
 Many-to-many scenarios
•
Media Broadcast
 Internet TV and radio
 One to many scenario
•
Gaming
 Many to many
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
What is needed?
•
Efficient transport:
 avoid sending the same content more than once
•
Conference setup
 who is allowed to start a conference?
 Who fast can a conference be initiated?
•
Security and privacy:
 How to prevent not-wanted people from joining?
 How to secure the exchanged content?
•
Floor control:
 How to maintain some talking order?
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
How to Realize? Centralized
•
All register at a central point
•
All send to central point
•
Central point forwards to others
•
Simple to implement
•
Single point of failure
•
High bandwidth consumption at center point

•
Must receive N flows
High processing overhead at center point


Must decode N flows mix the flows and encode N flows
With no mixing the central point would send Nx(N-1) flows
•
Appropriate for small to medium sized conferences
•
Simple to manage and administer:



Allows access control and secure communication
Allows usage monitoring
Support floor control
•
Most widely used scenario
•
No need to change end systems
•
Tightly coupled: Some instances know all information about all participants at all times
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Audio Mixing Server
G.711
A
E
G.729
B
E
GSM
C
E
G.711
G.711
D
G.729
D
X-A=B+C
X=A+B+C
G.729
X-B=A+C
D
Periodic timer
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
D
B
GSM
GSM
D
A
X-C=B+A
E: Encoder
D: Decoder
D
C
How to Realize? Full Mesh
•
All establish a connection to each other
•
All can send directly to the others
•
Each host will need to maintain N connections
•
Outgoing bandwidth:


•
Incoming bandwidth:

•
Send N copies of each packet
simple voice session with 64kb/s would translate to 64xN kb/s
If silence suppression is used then only active speakers send data
In case of video lots of bandwidth might be consumed

Unless only active speakers send video
•
Floor control only possible with cooperating users
•
Security: simple! do not send data to members you do not
trust
•
End systems need to mix the traffic –more complex end
systems
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
How to Realize? Peer-to-Peer
•
Mixing is done at the end systems
•
Increases processing over-head at the end
systems
•
Increases overall delay

Possibly mixed a multiple times
•
If central points leave a conference the
conference is dissolved
•
Security: Must trust all members

•
Access control: Must trust all members

•
Any member could send all data to non-trusted
users
Any member can invite new members
Floor control: requires cooperating users
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
IP Multicast
•
Previous scenarios build group communication on top of unicast
sessions
•
Enhance the network with support for group communication
 Optimal distribution is delegated to the network routers instead of end
systems
•
Receivers inform the network of their wish to receive the data of a
communication session
•
Senders send a single copy which is distributed to all receivers
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Group Communication: Multicast or Broadcast?
•
Broadcast:
 Sent to a broadcast address (all 1)
 Receivable by all reached hosts
 Wakeup all hosts even if they are not involved
•
Multicast
 Sent to an address between 224.0.0.0 and 239.255.255.255

Do not describe a host or interface but a group of receivers
 Receivable by all interested hosts
 All others filter it away
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
What is multicast good for?
A
B
C
D
E
• File transfer from C to A,B,D and E
• Unicast:
multiple copies
• Multicast:
single copy
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
IP Multicast
•
True N-way communication
 Any participant can send at any time and everyone receives the message
•
Unreliable delivery
 Based on UDP: Why?

•
Avoids hard problem (e.g., ACK explosion)
Efficient delivery
 Packets only traverse network links once (i.e., tree delivery)
•
Location independent addressing
 One IP address per multicast group
•
Receiver-oriented service model
 Receivers can join/leave at any time
 Senders do not know who is listening
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
IP Multicast
•
Service
 All senders send at the same time to the same group
 Receivers subscribe to any group
 Routers find receivers
•
Reserved IP addresses
 special IP addresses (class D): 224.0.0.0 through 239.255.255.255

class D: 1110+28 bits268 million groups (plus scope for add. reuse)
 224.0.0.x: local network only
 224.0.0.1: all hosts
 Static addresses for popular services (e.g., SAP –Session
Announcement protocol)
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Multicast Routing
•
What is the problem?
 Need to find all receivers in a multicast group
 Need to create spanning tree of receivers
•
Design goals
 Minimize unwanted traffic
 Minimize router state
 Scalability
 Reliability
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Data Flooding (Source based Trees)
•
Sends data to all nodes in network
•
Problem
 Needs to prevent cycles
 Needs to send only once to all nodes in network
 Routers could keep track of every packet and check if it had
previously seen this packet, but that means too much states
R2
R1
Sender
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
R3
Reverse Path Forwarding (RPF)
•
Simple technique for building trees
•
Send out on all interfaces except the one with the shortest path to the sender
•
In unicast routing, routers send to the destination via the shortest path
•
In multicast routing, routers send away from the shortest path to the sender
 Need to have a reverse routing table
•
Pruning:
 When no receivers want a session then inform the upper router not to send data

Need to periodically check whether this is still the case
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Reverse Path Forwarding Example
1. Router R1 checks: Did the data
packet arrive on the interface
with the shortest path to the
Sender? Yes, so it accepts the
packet, duplicates it, and
forwards the packet out all other
interfaces except the interface
that is the shortest path to the
sender (i.e the interface the
packet arrived on).
Sender
2. Router R2 accepts packets
sent from Router R1 because
that is the shortest path to the
Sender. The packet gets sent
out all interfaces.
R1
Drop
R2
3. Router R2 drops
packets that arrive from
Router R3 because that is
not the shortest path to
the sender. Avoids cycles.
R3
Drop
R4
R5
R6
1. No receivers so prune
2. Next packets will not be
forwarded to R5
3. R2 will periodically test R5
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
R7
Internet Group Management Protocol (IGMP)
•
IGMP allows an end system to express interest in joining a certain multicast
group
•
Protocol for managing group membership
 IP hosts report multicast group memberships to neighboring routers
 Messages in IGMPv2 (RFC 2236)



•
Membership Query (from routers)
Membership Report (from hosts)
Leave Group (from hosts)
Announce-listen protocol with suppression
 Hosts respond only if no other host has responded
•
Soft-state protocol
•
IGMP3 allows for joining the multicast data from certain senders
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
IGMP Example (1)
1
3
Network 1
Network 2
Router
4
2
•
Host 1 begins sending packets
 No IGMP messages sent
 Packets remain on Network 1
•
Router periodically sends IGMP Membership Query
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
IGMP Example (2)
Membership
Leave Report
Group
1
3
Network 1
Network 2
Router
4
2
•
Host 3 joins conference
 Sends IGMP Membership Report message
•
Router begins forwarding packets onto Network 2
•
Host 3 leaves conference
 Sends IGMP Leave Group message
 Only sent if it was the last host to send an IGMP Membership Report message
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Multicast Tunneling
•
Problem
 Not all routers are multicast capable
 Want to connect domains with non-multicast routers between them
•
Solution
 Encapsulate multicast packets in unicast packets
 Tunnel multicast traffic across non-multicast routers
•
MBONE
 Multicast capable virtual network, subset of Internet
 Native multicast regions connection with tunnels
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Multicast Tunneling Example (1)
Multicast Router 1
encapsulates multicast
packets for groups
that have receivers
outside of network 1.
It encapsulates them
as unicast IP-in-IP
packets.
Encapsulated
Data Packet
Multicast
Router 2
UR1
Multicast
Router 1
UR2
UR4
UR3
Unicast Routers
Sender 1
Receiver
Network 2
Network 1
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Multicast Router 2
decapsulates IP-in-IP
packets. It then
forwards them using
Reverse Path
Multicast.
Multicast Tunneling Example (2)
Virtual Network Topology
MR1
MR2
Virtual
Interfaces
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Operational Multicast Problems
•
Require updates of routers
•
Lack of experience
•
Debugging is difficult
 Not much of commercial analysis and debug tools
•
Immature protocols and applications
 Complicated routing protocols
•
Interoperability
 Flood and prune/explicit join
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Now about the Real Problems?
•
Address allocation
•
Security, privacy and IPR
•
Busines model and motivation
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Multicast Address Allocation
•
Problem
 Multicast addresses are a limited resource
 Current multicast address allocation scheme does not scale and makes
multicast routing more difficult

Current practice is to randomly allocate an address
 Addresses might collide
•
Solution
 Static distribution

Allocate special portions for Ass
 Use dynamically allocated addresses
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Security, Privacy and Control
•
Anybody can send data
 DoS and flooding attacks
•
Anybody can receive data
 No privacy
 Could add authentication and authorization during a join request

Sender does not know receivers
 Who does the authentication?
 Encryption for multicast

Shared secret between lots of people
 Not really a secret

Need to update the keys
 Intellectual Property Rights (IPR): How to do IPR protection for lots of receivers?
•
Floor control is only realizable with cooperating users
•
Loosly coupled: no entity knows all information about all other participants all
the time
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Business Model and Motivation
•
IP multicast reduces the needed bandwidth
 ISPs want to sell bandwidth
•
Senders do not know receivers
 How to collect money from distributing content
•
No security
 How to ensure protection against DoS, flooding
•
Complex and requires new hardware and knowledge
 When is the sweet point received?
•
Conferencing (few-to-few)
 Can just as well be done with unicast
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Commerical Multicast
•
Use application level multicast
 Multicast routing done using end hosts

Hosts build a multicast routing tables and act as multicast router (but on
application level)
 User request content using unicast
 Content distributed over unicast to the final users
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding
Commerical Multicast
Content source
Traditional
Content source
Application level
multicast
Tekelec Confidential /
For Discussion Purposes Only /
Tekelec Confidential
Non-Binding