multimedia networking

Multimedia Networking

#6 IP MulticastSemester Ganjil 2012

PTIIK Universitas Brawijaya

Schedule of Class Meeting

1. Introduction 2. Applications of MN3. Requirements of MN4. Coding and

Compression5. RTP6. IP Multicast7. IP Multicast (cont’d)

8. Overlay Multicast9. CDN: Solutions10. CDN: Case Studies11. QoS on the Internet:

Constraints12. QoS on the Internet:

Solutions13. Discussion14. Summary

Multmedia Networking 2

Today’s Outline

• IP Multicast– Concept and components– Addressing architecture– IP Multicast Protocols


IP Multicast

Multicast

• Many receivers– Receiving the same content

• Applications– Video conferencing– Online gaming– IP television (IPTV)– Financial data feeds


Iterated Unicast

• Unicast message to each recipient• Advantages

– Simple to implement– No modifications to network

• Disadvantages– High overhead on sender– Redundant packets on links– Sender must maintain list of receivers


IP Multicast

• Embed receiver-driven tree in network layer– Sender sends a single packet to the group– Receivers “join” and “leave” the tree

• Advantages– Low overhead on the sender– Effective use of network resources

• Avoids redundant network traffic

• Disadvantages– Control-plane protocols for multicast groups– Overhead of duplicating packets in the routers


Multicast Communication

1 flows of a packet

10 flows of the same packet

Unicast Multicast

sender sender


IP Multicast Communication

• Concept– Multicast data sender sends the data only once, and

only the intended recipients (who want to receive the data) receive the data

• IP multicast provides one-to-many or many-to-many communication effectively

– Each data (i.e. multicast stream) is classified by multicast address (and source address if SSM is used)

– Non-reliable communication (i.e. on top of UDP)• IP multicast is basically applied to real-time applications


Data Flow• Data sender

– Sender sends data once• Data receiver

– Receiver that has requested getting the data receives the data• Multicast routers

– Router copies and forwards the data only toward the data receivers

MulticastRouter

Sender Receiver

Data Data


Communication Flow• Control messages

– Sender announces the session information or receivers discover the session information

– Each receiver requests to start and stop receiving data by “join and leave” operations

– Multicast routers maintains membership state by having reports

MulticastRouter

Sender Receiver

Join/Leave request

Announcement

Discovery

Query

MulticastRouter

Routingprotocol


Multicast Addresses

• Multicast “group” defined by IP address– Multicast addresses look like unicast addresses– 224.0.0.0 to 239.255.255.255

• Using multicast IP addresses– Sender sends to the IP address– Receivers join the group based on IP address– Network sends packets along the tree


Example Multicast Protocol• Receiver sends a “join” messages to the sender

– And grafts to the tree at the nearest pointA

B

G

D

E

c

F


IP Multicast is Best Effort

• Sender sends packet to IP multicast address– Loss may affect multiple receiversA

B

G

D

E

c

F


Terminologies

• Group address (or multicast address)– Used for destination address

• Join and leave– Data reception state requested by receiver hosts

• Join and prune– Data reception state requested by routers

• (*,G) and (S,G)– Notation of source address and group address in

join-and-leave (or join-and-prune) state


Terminologies

• Scope– Expected data distribution area– Classified by multicast address or TTL

• TTL (Time To Live) or Hop limit– Expected maximum hop count of each packet

• IIF and OIF– IIF: Incoming interface from which data is received– OIF: Outgoing interface to which data is sent


Terminologies

• Multicast session– Multicast data stream classified by the “multicast

address” is called “multicast session”• Multicast channel

– Multicast data stream explicitly classified by the pair of “multicast address” and “source address” is called “multicast channel”

• Used for SSM


Multicast Protocols

• Host-to-Router Protocols– IGMPv1, IGMPv2, IGMPv3, MLDv1, MLDv2

• Router-to-Router Protocols– DVMRP, MOSPF, CBT, PIM-DM, PIM-SM, PIM-SSM

MulticastRouter

Sender host

Receiver host

Join/Leave requestQuery

MulticastRouter


Multicast Address Assignment

IP Multicast• Simple to use in applications

– Multicast “group” defined by IP multicast address• IP multicast addresses look similar to IP unicast addrs• 224.0.0.0 to 239.255.255.255 (RPC 3171)

– 265 M multicast groups at most

– Best effort delivery only• Sender issues single datagram to IP multicast address• Routers delivery packets to all subnetworks that have a

receiver “belonging” to the group

• Receiver-driven membership– Receivers join groups by informing upstream routers– Internet Group Management Protocol (v3: RFC 3376)


IP Multicast Address

• IP multicast address– IPv4: 224.0.0.0 – 239.255.255.255– IPv6: FFx0::1– MUST be specified as a destination address– MUST NOT be specified as a source address

• Dynamic address assignment– Regular applications select their multicast addresses

dynamically• Some multicast addresses are assigned by IANA for special

uses


IPv4 Multicast Addresses• IPv4 multicast address

– 224.0.0.0 (0xe0000000) - 239.255.255.255 (0xefffffff)+----+----+---------+------------+| 4 | 28 bits |+----+----+---------+------------+|1110| group address |+----+----+---------+------------+

– Administrative scope [RFC2365]– Local address (224/24)– Administrative scope (239/8)– Organization-Local (239.192/14)

– GLOP address (233/8) [RFC3180]– EGLOP (233.252.0.0 - 233.255.255.255) [RFC3138]– SSM address (232/8) [RFC]


IPv6 Multicast Addresses• IPv6 multicast address: FFxx::

+--------+----+----+---------------------------------------------+| 8 | 4 | 4 | 112 bits |+--------+----+----+---------------------------------------------+|11111111|flgs|scop| group ID |+--------+----+----+---------------------------------------------+

– Flags• 000T (T=1: transient, T=0: well-known)

– Scope• 0x1: Interface Local• 0x2: Link-Local• 0x3: Subnet-Local• 0x4: Admin-Local• 0x5: Site-Local• 0x8: Organization-Local• 0xE: Global

– SSM address (FF3x::/32 (or 96)) [RFC3306]Multmedia Networking 23

Host-to-Router Multicast Protocols

IGMP v1• Two types of IGMP msgs (both have IP TTL of 1)

– Host membership query: Routers query local networks to discover which groups have members

– Host membership report: Hosts report each group (e.g., multicast addr) to which belong, by broadcast on net interface from which query was received

• Routers maintain group membership– Host senders an IGMP “report” to join a group– Multicast routers periodically issue host membership query

to determine liveness of group members– Note: No explicit “leave” message from clients


IGMP: Improvements• IGMP v2 added:

– If multiple routers, one with lowest IP elected querier

– Explicit leave messages for faster pruning

– Group-specific query messages

• IGMP v3 added:– Source filtering: Join specifies multicast “only from”

or “all but from” specific source addresses


IGMP: Parameters and Design• Parameters

– Maximum report delay: 10 sec– Membership query internal default: 125 sec– Time-out interval: 270 sec = 2 * (query interval + max delay)

• Is a router tracking each attached peer?– No, only each network, which are broadcast media

• Should clients respond immediately to queries?– Random delay (from 0..D) to minimize responses to queries– Only one response from single broadcast domain needed

• What if local networks are layer-2 switched?– L2 switches typically broadcast multicast traffic out all ports– Or, IGMP snooping (sneak peek into layer-3 contents), Cisco’s

proprietary protocols, or static forwarding tablesMultmedia Networking 27

Router-to-Router Multicast Protocols

Multicast TreeA

B

G

D

E

c

F


Multicast routing: problem statement

goal: find a tree (or trees) connecting routers having local mcast group members

• tree: not all paths between routers used• shared-tree: same tree used by all group members

shared tree source-based trees

group membernot group member

routerwith agroup member

routerwithoutgroup member

legend

source-based: different tree from each sender to rcvrs


Approaches for building mcast trees

approaches:• source-based tree: one tree per source

– shortest path trees– reverse path forwarding

• group-shared tree: group uses one tree– minimal spanning (Steiner) – center-based trees

…we first look at basic approaches, then specific protocols adopting these approaches


Single vs. Multiple Senders

• Source-based tree– Separate tree for

each sender– Tree is optimized for

that sender– But, requires

multiple trees for multiple senders

• Shared tree– One common tree– Spanning tree that

reaches all participants

– Single tree may be inefficient

– But, avoids having many different trees


Shortest path tree• mcast forwarding tree: tree of shortest

path routes from source to all receivers– Dijkstra’s algorithm

i

router with attachedgroup member

router with no attachedgroup member

link used for forwarding,i indicates order linkadded by algorithm

LEGEND

R1

R2

R3

R4

R5

R6 R7

21

6

3 45

s: source


Reverse path forwarding

if (mcast datagram received on incoming link on shortest path back to center)

then flood datagram onto all outgoing links else ignore datagram

rely on router’s knowledge of unicast shortest path from it to sender

each router has simple forwarding behavior:


Reverse path forwarding: example

result is a source-specific reverse SPT may be a bad choice with asymmetric

links



datagram will be forwarded

LEGENDR1

R2

R3

R4

R5

R6 R7

s: source

datagram will not be forwarded


Reverse path forwarding: pruning

• forwarding tree contains subtrees with no mcast group members– no need to forward datagrams down subtree– “prune” msgs sent upstream by router with

no downstream group members



prune message

LEGEND

links with multicastforwarding

P

R1

R2

R3

R4

R5

R6R7

s: source

P

P


Internet Multicasting Routing: DVMRP

• DVMRP: distance vector multicast routing protocol, RFC1075

• flood and prune: reverse path forwarding, source-based tree– RPF tree based on DVMRP’s own routing tables

constructed by communicating DVMRP routers – no assumptions about underlying unicast– initial datagram to mcast group flooded

everywhere via RPF– routers not wanting group: send upstream

prune msgs


DVMRP: continued…• soft state: DVMRP router periodically (1

min.) “forgets” branches are pruned: – mcast data again flows down unpruned

branch– downstream router: reprune or else continue

to receive data• routers can quickly regraft to tree

– following IGMP join at leaf• odds and ends

– commonly implemented in commercial router


TunnelingQ: how to connect “islands” of multicast

routers in a “sea” of unicast routers?

mcast datagram encapsulated inside “normal” (non-multicast-addressed) datagram

normal IP datagram sent thru “tunnel” via regular IP unicast to receiving mcast router (recall IPv6 inside IPv4 tunneling)

receiving mcast router unencapsulates to get mcast datagram

physical topology logical topology


PIM: Protocol Independent Multicast

• not dependent on any specific underlying unicast routing algorithm (works with all)

• two different multicast distribution scenarios :

dense: group members

densely packed, in “close” proximity.

bandwidth more plentiful

sparse: # networks with group

members small wrt # interconnected networks

group members “widely dispersed”

bandwidth not plentifulMultmedia Networking 40

Consequences of sparse-dense dichotomy:

dense• group membership by

routers assumed until routers explicitly prune

• data-driven construction on mcast tree (e.g., RPF)

• bandwidth and non-group-router processing profligate

sparse:• no membership until

routers explicitly join• receiver- driven

construction of mcast tree (e.g., center-based)

• bandwidth and non-group-router processing conservative


PIM- dense modeflood-and-prune RPF: similar to

DVMRP but… underlying unicast protocol provides

RPF info for incoming datagram less complicated (less efficient)

downstream flood than DVMRP reduces reliance on underlying routing algorithm

has protocol mechanism for router to detect it is a leaf-node router


PIM - sparse mode

• explicit join and prune: center-based approach, SPT to the source

• router sends join msg to rendezvous point (RP)– intermediate routers

update state and forward join

• after joining via RP, router can switch to source-specific tree– increased

performance: less concentration, shorter paths

all data multicastfrom rendezvouspoint

rendezvouspoint

join

join

join

R1

R2

R3

R4

R5

R6R7


sender(s):• unicast data to RP,

which distributes down RP-rooted tree

• RP can extend mcast tree upstream to source

• RP can send stop msg if no attached receivers– “no one is listening!”

all data multicastfrom rendezvouspoint

rendezvouspoint

join

join

join

R1

R2

R3

R4

R5

R6R7

PIM - sparse mode


Conclusion of Today’s Lecture

• IP Multicast runs on top of UDP under best-effort IP network– suitable for real-time applications

• IP Multicast is efficient-use of network resources– suitable for one-many or many-many communication

• IP Multicast requires– specific address assignment– host-to-router protocols– router-to-router protocols


multimedia networking

Documents

routersmultmedia networking

treemultmedia networking

multimedia networking

multicast stream

udpip multicast

dataip multicast

ip multicast addressloss

multicast ip addressessender