IP_tec - iptel.org | slideum.com

IP_tec - iptel.org

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

Media Exchange

A/D encoding packetization OS Route lookup FCFS

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

D/A decoding OS

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 / For Discussion Purposes Only / Tekelec Confidential

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

 64Kb/s, 1 

 30

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

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

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

player

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

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

player

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

Application Addressing

• • IP addresses enable us to get from one device to another 192.22.22.22

Port numbers allow us to address one process at a device 80 195.33.33.33

77777 88888

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

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 byte stream

over an unreliable network.

end-to-end • User Datagram Protocol (UDP) 

Connectionless

protocol that provides an

unreliable

end-to-end

datagram

service.

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

Transport Control Protocol

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

IP encapsulation of TCP segments

IP header 20 bytes IP datagram TCP segment TCP header 20 bytes TCP data

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

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

TCP connection Establishment

• Connection establishment is done with a three way handshake client SYN 141 (0)win 100, SYN 181 (0) win 100, ACK 142 ACK 182 server

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

TCP Data Exchange

client

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

server

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 application CLOSE ACK of FIN

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

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

Window Flow Control

Source 1 2 RTT W 1 2 W data ACKs Destination 1 2 W • Rate= (W packets x packet size) / RTT 1 2 time W time

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

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

Slow Start

sender cwnd 1 receiver data packet 1 RTT ACK 2 3 4 5 6 7 8 cwnd  cwnd + 1 (for each ACK)

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

Congestion Avoidance

sender cwnd 1 data packet receiver ACK 2 1 RTT 3 4 cwnd  cwnd + 1 (for each cwnd ACKS)

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

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

TCP Tahoe

(Jacobson 1988)

window SS CA SS: Slow Start CA: Congestion Avoidance

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

time

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

User Datagram Protocol

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 20 bytes IP datagram UDP datagram UDP header 8 bytes UDP data

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

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 UDP length 16-bit destination port number data (if any) 16-bit UDP checksum

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

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

UDP vs. TCP Traffic Characteristics

packet/s p Sender packet/s p loss time window window time SS CA SS: Slow Start CA: Congestion Avoidance time Receiver SS CA SS: Slow Start CA: Congestion Avoidance time time

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

Real Time Transport Protocol

Based on slides by Vincent Roca

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

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 / For Discussion Purposes Only / Tekelec Confidential

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

RTP: Header

RTP version

M CC Payload Sequence number Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

RTP: Header

Padding for encryption

M CC Payload Sequence number Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

RTP: Header

Extension bit

Allows adding experimental headers

M CC Payload Sequence number Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

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

RTP: Header

V P X M Contributers Count Number of sources contributing to this packet Added by mixers and ranges from 0 to 15 CC Payload Sequence number Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

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

RTP: Header

Number of packet incresed by one for each new packet

V P X M CC Payload Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

RTP: Header

V P X

Different fixed value for each compression type (160 for 20 ms at 8000

Payload Sequence number Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

RTP: Header

A random number identifying the source (unique per source)

chosen randomly  Sequence number Contributing Source Identifier (CSRC) Payload

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

RTP: Header

V P X M Payload Sequence number

Identify the contributing sources to this packet

(added by mixers) Contributing Source Identifier (CSRC) Payload

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

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

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

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  BYE  APP source description, including CNAME explicit leave application specific extensions

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

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

SR RTCP packets

• includes       SSRC of sender NTP timestamp RTP timestamp packet count identify source of data when report was sent corresponding RTP time total number sent octet count total number sent followed by zero or more receiver report…

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

RR RTCP packets

• includes        SSRC of source fraction lost LSR DLSR identify the source to which this RR block pertains since previous RR (SR) sent (= int(256*lost/expected)) cumul # of packets lost highest seq # received interarrival jitter long term loss compare losses smoothed interpacket distortion time when last SR heard delay since last SR

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

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

Example of RTCP compound packet

SR RTCP packet 1 sender report receiver report source 2 receiver report source 3 compound packet (single UDP datagram) RTCP packet 2 SDES CNAME PHONE

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

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

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

application

uncomplete data!!!

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

useless!!!

Transport Mechanisms for Group Communication

Based on slides of Ofer Hadar, Jon Crowcroft

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

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

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

A B

Audio Mixing Server

G.711

E G.729

E C GSM E G.711

D G.729

D X=A+B+C G.711

A D X-A=B+C X-B=A+C G.729

D B GSM D X-C=B+A E: Encoder D: Decoder GSM 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:   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

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

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 / For Discussion Purposes Only / Tekelec Confidential

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

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

What is multicast good for?

A B 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

C

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

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

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

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 Sender R1

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

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

Reverse Path Forwarding Example 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.

Sender R1 Drop 3.

Router R2 drops packets that arrive from Router R3 because that is not the shortest path to the sender. Avoids cycles.

R4 R2 R5 1. No receivers so prune 2. Next packets will not be forwarded to R5 3. R2 will periodically test R5 Drop R6

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

R3 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). 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

IGMP Example (1)

1 Network 1 2 Router

• • Host 1 begins sending packets  No IGMP messages sent  Packets remain on Network 1 Router periodically sends IGMP Membership Query

3 Network 2 4

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

IGMP Example (2)

1 Network 1 Network 2 Router 2 4

• • • 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

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

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. Multicast Router 1 Sender 1 Network 1 Encapsulated Data Packet UR1 UR2 UR3 UR4 Unicast Routers

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

Multicast Router 2 Multicast Router 2 decapsulates IP-in-IP packets. It then forwards them using Reverse Path Multicast. Receiver Network 2

Multicast Tunneling Example (2)

Virtual Network Topology MR1 Virtual Interfaces MR2

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

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

Now about the Real Problems?

• Address allocation • Security, privacy and IPR • Busines model and motivation

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

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

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

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

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

Commerical Multicast

Traditional Application level multicast

Tekelec Confidential / For Discussion Purposes Only / Tekelec Confidential

Content source Content source