Transporting Multimedia Data in the Internet
description
Transcript of Transporting Multimedia Data in the Internet
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.
Transporting Multimedia Data in the Internet
Dr. Dorgham Sisalem
Tekelec
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
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
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Media Exchange
encoding
packetization
OS
decoding
OSRoutelookup
FCFS
A/D D/A
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Example audio encoding techniques
G.711
• PCM (non-linear)
• 4KHz bandwidth
• 64Kb/s
G.722
• SB-ADPCM
• 48/56/64Kb/s
• 4-8KHz bandwidth
G.728
• LD-CELP
• 4KHz bandwidth
• 16Kb/s
G.729
• CS-ACELP
• 4KHz bandwidth
• 8Kb/s
G.723.1
• MP-MLQ
• 5.3/6.3Kb/s
• 4KHz bandwidth
GSM
• RPE/LTP
• 4KHz
• 13Kb/s
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Example video encoding techniques
MPEG1
• Up to 1.5Mb/s
MPEG2
• Up to 10Mb/s (HDTV quality)
MPEG4
• 5-64Kb/s (mobile, PSTN)
• 2Mb/s (TV quality)
• MPEG7, MPEG21
H.261 and H.263
• n 64Kb/s, 1 n 30
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Streaming Media
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
sender
player
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Video/Audio Communication
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
sender
player
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
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
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Application Addressing
• IP addresses enable us to get from one device to another
• Port numbers allow us to address one process at a device 80
7777788888
192.22.22.22 195.33.33.33
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
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.
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.
Transport Control Protocol
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
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
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
IP encapsulation of TCP segments
IP header TCP header TCP data
20 bytes 20 bytes
TCP segment
IP datagram
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
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
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
• Connection establishment is done with a three way handshake
TCP connection Establishment
clientserver
SYN 141 (0)win 100, <mss 1024>
SYN 181 (0) win 100, <mss 1024>ACK 142
ACK 182
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
TCP Data Exchange
client server142
ACK 143
• Gaps in the sequence numbers indicate losses to the receiver
• Missing or repeated acknowledgements indicate loss to the sender
144
ACK 143
143
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Normal TCP connection termination
FIN
ACK of FIN
FIN
ACK of FIN
deliver EOF to application
application CLOSE
application CLOSE
• 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.
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
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
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Window Flow Control
• Rate= (W packets x packet size) / RTT
RTT
time
time
Source
Destination
1 2 W
1 2 W
1 2 W
data ACKs
1 2 W
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
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
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Slow Start
data packetACK
receiversender
1 RTT
cwnd1
2
34
5678
cwnd cwnd + 1 (for each ACK)
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Congestion Avoidance
cwnd1
2
3
1 RTT
4
data packetACK
cwnd cwnd + 1 (for each cwnd ACKS)
receiversender
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
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
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
TCP Tahoe (Jacobson 1988)
window
SStime
CA
SS: Slow StartCA: Congestion Avoidance
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
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
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.
User Datagram Protocol
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
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 header UDP header UDP data
20 bytes 8 bytes
UDP datagram
IP datagram
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
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
Tekelec Confidential / For Discussion Purposes Only /
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
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
UDP vs. TCP Traffic Characteristics
packet/s
time
Sender
p
time
loss
window
SStime
CA
SS: Slow StartCA: Congestion Avoidance
packet/s
time
Receiver
p
window
SStime
CA
SS: Slow StartCA: Congestion Avoidance
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
Based on slides by Vincent Roca
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
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
Tekelec Confidential / For Discussion Purposes Only /
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 Media content
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
RTP: Header
V P X Sequence number
PayloadM
Timestamp
Synchronization Source Identifier (SSRC)
Payload
Ct
Contributing Source Identifier (CSRC)
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Contributing Source Identifier (CSRC)
CC
RTP: Header
V P X Sequence number
PayloadM
Timestamp
Synchronization Source Identifier (SSRC)
Payload
V
RTP version
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Contributing Source Identifier (CSRC)
CC
RTP: Header
V P X Sequence number
PayloadM
Timestamp
Synchronization Source Identifier (SSRC)
Payload
P
Padding for encryption
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
CC
Contributing Source Identifier (CSRC)
RTP: Header
V P X Sequence number
PayloadM
Timestamp
Synchronization Source Identifier (SSRC)
Payload
X
Extension bitAllows adding experimental headers
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
CC
Contributing Source Identifier (CSRC)
RTP: Header
V P X Sequence number
Payload
Timestamp
Synchronization Source Identifier (SSRC)
Payload
Marker bitUsage depends on codec and media (end of frame for example)
M
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
M
Contributing Source Identifier (CSRC)
RTP: Header
V P X Sequence number
Payload
Timestamp
Synchronization Source Identifier (SSRC)
Payload
Contributers CountNumber of sources contributing to this packetAdded by mixers and ranges from 0 to 15
CC
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Contributing Source Identifier (CSRC)
CC
RTP: Header
V P X Sequence number
M
Timestamp
Synchronization Source Identifier (SSRC)
Payload
Audio/Video encoding method
Payload
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
CC
Contributing Source Identifier (CSRC)
RTP: Header
V P X Sequence number
PayloadM
Timestamp
Synchronization Source Identifier (SSRC)
Payload
Sequence number
Number of packet incresed by one for each new packet
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
MCC
Contributing Source Identifier (CSRC)
RTP: Header
V P X Sequence number
Payload
Timestamp
Synchronization Source Identifier (SSRC)
Payload
Timestamp
Different fixed value for each compressiontype (160 for 20 ms at 8000 Hz)
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Contributing Source Identifier (CSRC)
RTP: Header
V P X Sequence number
PayloadM
Timestamp
Synchronization Source Identifier (SSRC)
Payload
Synchronization source identifier (SSRC)
A random number identifying the source(unique per source)chosen randomly detect and solve collisions
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
RTP: Header
V P X Sequence number
PayloadM
Timestamp
Synchronization Source Identifier (SSRC)
Payload
Identify the contributing sources to this packet(added by mixers)
Contributing Source Identifier (CSRC)
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
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
Tekelec Confidential / For Discussion Purposes Only /
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
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
RTCP generalities
• Five RTCP packets SR sender reports
tx and rx statistics from active senders
RR receiver reportsrx statistics from other participants, or fromactive senders if more than 31 sources
SDES source description, including CNAME
BYE explicit leave
APP application specific extensions
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
RTCP generalities… (cont’)
• distribution use same distribution mechanisms as data packets (nm 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 reportslet new receivers quickly know CNAME of sources!
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
SR RTCP packets
• includes SSRC of sender identify source of data NTP timestamp 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
Tekelec Confidential / For Discussion Purposes Only /
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
Tekelec Confidential / For Discussion Purposes Only /
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
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Example of RTCP compound packet
SRsenderreport
receiverreport
receiverreportS
SR
C
SS
RC
SS
RC
source 2 source 3
RTCP packet 1
SDES CNAME PHONE
SS
RC
RTCP packet 2
compound packet(single UDP datagram)
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
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
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
RTP payload… (cont’)
• Example of what must not happen!!! loss multiplication effect due to bad framing
application data unit
fragment 1 fragment 2 fragment 3
application
RTPnetwork tx
fragment 2fragment 1
LOST
RTP
uncomplete data!!!application useless!!!
Src
Rx
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.
Transport Mechanisms for Group Communication
Based on slides of Ofer Hadar, Jon Crowcroft
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
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
Tekelec Confidential / For Discussion Purposes Only /
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
Tekelec Confidential / For Discussion Purposes Only /
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
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Audio Mixing Server
G.711
E
G.729
E
GSM
E
Periodic timer
B
A
C
X=A+B+C
D
G.729
D
GSM
D
B
A
C
X-A=B+C
X-B=A+C
X-C=B+A
E: EncoderD: Decoder
G.711
D
G.729
D
GSM
D
G.711
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
• All establish a connection to each other
• All can send directly to the others
• Each host will need to maintain N connections
• Outgoing bandwidth: Send N copies of each packet simple voice session with 64kb/s would translate to 64xN kb/s
• Incoming bandwidth: 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
How to Realize? Full Mesh
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
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 Any member could send all data to non-trusted
users
• Access control: Must trust all members Any member can invite new members
• Floor control: requires cooperating users
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
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
Tekelec Confidential / For Discussion Purposes Only /
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
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
What is multicast good for?
A
E
B
D
C
• File transfer from C to A,B,D and E• Unicast: multiple copies • Multicast: single copy
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
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
Tekelec Confidential / For Discussion Purposes Only /
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
Tekelec Confidential / For Discussion Purposes Only /
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
Tekelec Confidential / For Discussion Purposes Only /
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
Sender
R3R1
R2
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
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
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Reverse Path Forwarding Example
R5 R6
R3R2
R1
R4 R7
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.
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).
Drop
Drop3. Router R2 drops packets that arrive from Router R3 because that is not the shortest path to the sender. Avoids cycles.
1. No receivers so prune2. Next packets will not be forwarded to R53. R2 will periodically test R5
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
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
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
IGMP Example (1)
Network 1
• Host 1 begins sending packets No IGMP messages sent Packets remain on Network 1
• Router periodically sends IGMP Membership Query
Network 2Router
1
2 4
3
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
IGMP Example (2)
Network 1
• 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
Network 2Router
1
2 4
33
Membership Report
33
Leave Group
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
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
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Multicast Tunneling Example (1)
UR1 UR4
MulticastRouter 1
MulticastRouter 2
Sender 1
EncapsulatedData Packet
Unicast Routers
Multicast Router 1 encapsulates multicast
packets for groups that have receivers
outside of network 1. It encapsulates them
as unicast IP-in-IP packets .
Network 1
Receiver
Network 2
Multicast Router 2 decapsulates IP-in-IP
packets. It then forwards them using
Reverse Path Multicast .
UR2 UR3
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Multicast Tunneling Example (2)
MR1 MR2
VirtualInterfaces
Virtual Network Topology
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
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
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Now about the Real Problems?
• Address allocation
• Security, privacy and IPR
• Busines model and motivation
Tekelec Confidential
Tekelec Confidential / For Discussion Purposes Only /
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
Tekelec Confidential / For Discussion Purposes Only /
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
Tekelec Confidential / For Discussion Purposes Only /
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
Tekelec Confidential / For Discussion Purposes Only /
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
Tekelec Confidential / For Discussion Purposes Only /
Non-Binding
Commerical Multicast
Content source
Traditional
Content source
Application levelmulticast