8/12/2019 Multi Cast Summary Pp t 1469

1/61

Summary of IP Multicast

CPSC 601.43Course Director: Dr. AnirbanMahanti

Student : Liqi Shi

8/12/2019 Multi Cast Summary Pp t 1469

2/61

Outline

1. Introduction to Multicast

2. Multicast Group and Service Model3. Multicast Routing

4. Deployment Issues of Multicast

5. EXPRESS6. References

8/12/2019 Multi Cast Summary Pp t 1469

3/61

1 Introduction to Multicast

1.1 Why Multicast /Multicast Applications

1.2 Broadcast/Unicast/Multicast

8/12/2019 Multi Cast Summary Pp t 1469

4/61

1.1 Why Multicast /Multicast

Applications

Same data sent to multiple receivers

To use the bandwidth efficiently Reduce routing processing

Sender doesnt get receivers address

8/12/2019 Multi Cast Summary Pp t 1469

5/61

1.1 Why Multicast /Multicast

Applications

Video/audio conference

IP TV, Video on Demand Advertisement, Stock, Distance learning

Synchronizing of distributed database,

websites

8/12/2019 Multi Cast Summary Pp t 1469

6/61

1.1 Why Multicast /Multicast

Applications

ConferenceXP: An Example of Multicast

applicationVideo Conference Distance Learning

8/12/2019 Multi Cast Summary Pp t 1469

7/61

1.2 Broadcast/Unicast/Multicast

Broadcast: One sender, all the others as

receivers Unicast: One sender and one receiver

Multicast: One sender (potentially many

senders), many receivers

You can take broadcast and unicast as two

special types of multicast

8/12/2019 Multi Cast Summary Pp t 1469

8/61

1.2 Broadcast/Unicast/Multicast

UNICAST

With 4 receivers,

sender must

replicate the

stream 4times

8/12/2019 Multi Cast Summary Pp t 1469

9/61

1.2 Broadcast/Unicast/Multicast

MULTICAST Source transmits

one stream of data

for n receivers

Replication

happens inside

routers and

switches

WAN links only

need one copy of

the data, not n

copies.

8/12/2019 Multi Cast Summary Pp t 1469

10/61

2 Multicast Group and Service Model

Each multicast group is identified by a class D IPaddress

Members of the group could be anywhere in theInternet

Members can join and leave the group and indicatethis to the routers

Senders and receivers are distinct: i.e., a senderneed not be a member, but receivers should be

Routers listen to all multicast addresses and usemulticast routing protocols to manage groups (IGMP)

8/12/2019 Multi Cast Summary Pp t 1469

11/61

2 Multicast Group and Service Model

Multicast Address IP reserved class D addresses for multicast

224.0.0.0~239.255.255.255

Base address: 224.0.0.0 is reserved 224.0.0.1~224.0.0.255 are devoted to multicast routing

and group maintenance protocols

Multicast addresses can only be used as destination

No ICMP error messages can be generated for multicastdatagram

8/12/2019 Multi Cast Summary Pp t 1469

12/61

2 Multicast Group and Service Model

Mapping IP Multicast to Ethernet Multicast: Place the lower

23 bits of the IP multicast address into the lower 23 bits of

special Ethernet multicast address 01.00.5E.00.00.00. 32

multicast groups may be mapped into the same address.

Probability is small, but receivers should check the datagram

8/12/2019 Multi Cast Summary Pp t 1469

13/61

3 Multicast Routing

3.1 Transmission and Delivery of Multicast Datagram

3.2 Internet Group Management Protocol (IGMP)

3.3 Multicast Forwarding Algorithms Flooding

Spanning Trees

Reverse Path Broadcasting (RPB)

Truncated Reverse Path Broadcasting (TRPB)

Reverse Path Multicasting (RPM)

Core Based Trees (CBT)

3.4 Multicast Protocols Distance Vector Multicast Routing Protocol (DVMRP) Multicast OSPF (MOSPF)

Protocol-Independent Multicast (PIM)

BGMP and MASC

8/12/2019 Multi Cast Summary Pp t 1469

14/61

3.1 Transmission and Delivery of Multicast

Datagram

Local subnetwork transmissionThe source station simply addresses the IP packet to the multicast group, the

network interface card maps the Class D address to the correspondingEthernet multicast address, and the frame is sent. Receivers that wish to

capture the frame notify their IP layer that they want to receive datagrams

addressed to the group

Transmission throughout the Internet

Routers are required to implement a multicast routing protocol that permits theconstruction of multicast delivery trees and supports multicast data packet

forwarding. In addition, each router needs to implement a group membership

protocol (IGMP) that allows it to learn about the existence of group members on

its directly attached subnetwork

8/12/2019 Multi Cast Summary Pp t 1469

15/61

3.2 Internet Group Management

Protocol (IGMP)

Introduction

IGMP runs between hosts and the

nearest multicast routers. A localhost can use it to inform the routerwhich multicast group it wants to beadded in, while the multicast routerscan use it to poll the LANperiodically, thus determine ifknown group members are still

active IGMP message format

Type 0x11 0x11 0x16 0x17 0x12

Group

Addre

ss

unuse

d

used used used used

Meani

ng

Gener

al

memb

ership

query

Specifi

c

memb

ership

query

Memb

ership

report

Leave

group

Memb

ership

report

(V1)

0 8 16 32

8/12/2019 Multi Cast Summary Pp t 1469

16/61

3.2 Internet Group Management

Protocol (IGMP)

IGMP versions RFC1112, IGMP version 1

, IGMP version2 defines a procedure for the election of the multicast querier for each

LAN

defines a new type of Query message-the Group-Specific Querymessage

defines a Leave Group message

, IGMP version 3 introduces support for Group-Source Report messages so that a host

can elect to receive traffic from specific sources of a multicast group

support for Leave Group messages first introduced in IGMP Version 2has been enhanced to support Group-Source Leave messages. Thisfeature allows a host to leave an entire group or to specify the specificIP address(es) of the (source, group) pair(s) that it wishes to leave

8/12/2019 Multi Cast Summary Pp t 1469

17/61

3.2 Internet Group Management

Protocol (IGMP)

How it works

One host joins a group

Newly joined host in a group sends IGMP message to group multicastaddress declaring membership.

Local multicast router receives the message and establishesnecessary routing path

Group membership report

Router sends Host Membership Query to 224.0.0.1 (all multicast hostson a subnet)

Host responds with Host Membership reportfor each group to which itbelongs (sent to group address)

other hosts in the same group suppress reports

Router periodically broadcasts query to detect if groups have goneaway

8/12/2019 Multi Cast Summary Pp t 1469

18/61

3.2 Internet Group Management

Protocol (IGMP) Each hostresponds to the

query with a

random delay. If

one report is

received at the

router, the otherreports will be

suppressed

8/12/2019 Multi Cast Summary Pp t 1469

19/61

3.3 Multicast Forwarding Algorithms

Introduction: IGMP is responsible for delivering packets from alocal router to directly attached subnetwork. To forwardingmulticast packets across internet, we should use multicastprotocols. Several algorithms may be used by the protocols.

3.3.1 Flooding

3.3.2 Spanning Trees

3.3.3 Reverse Path Broadcasting (RPB)

3.3.4 Truncated Reverse Path Broadcasting (TRPB)

3.3.5 Reverse Path Multicasting (RPM)

3.3.6 Core Based Trees (CBT)

8/12/2019 Multi Cast Summary Pp t 1469

20/61

3.3.1 Flooding

When a router receives a packet, the router will determinewhether its the first time it receives the packet. If so, the packet

will be delivered to all interfaces except the one on which itarrived, otherwise the packet will be discarded.

No routing tables needed

Inefficient use of bandwidth

SRC Non-red streams will be

discarded according to

flooding algorithm

8/12/2019 Multi Cast Summary Pp t 1469

21/61

3.3.2 Spanning Tree

Only one active path connects any two of routers

The multicast packets will not loop and reach all routers

May not provide the most efficient path between the sourcesubnetwork and group members

8/12/2019 Multi Cast Summary Pp t 1469

22/61

3.3.3 Reverse Path Broadcasting (RPB)

A local router only acceptspackets from the nearestsource (parent), otherwise the

packets are discarded Accepted packets will be

forwarded to all interfacesexcept the source

it does not take into accountmulticast group membership

when building the distributiontree, so packets may beforwarded to non-membershipsubnetwork

8/12/2019 Multi Cast Summary Pp t 1469

23/61

3.3.4 Truncated Reverse Path

Broadcasting (TRPB)

Its an enhancement of RPB

With the help of IGMP,

multicast routers determine thegroup membership on each leaf

subnetwork, thus avoiding

forwarding packets to non-

members

Eliminates unnecessary traffic

on leaf subnetworks , but doesnot consider group

memberships when building the

branches of the distribution tree

Source,

G1

G1

G2

G3

Truncated

8/12/2019 Multi Cast Summary Pp t 1469

24/61

3.3.5 Reverse Path Multicasting (RPM)

RPM creates a delivery tree that spans only

Subnetworks with group members, and

Routers along the shortest path to subnetworks with groupmembers

First packet will be sent to all interfaces except the source. Ifnone of the subnetworks connected to the leaf router havegroup members, the leaf router may transmit a "prune"message on its parent link informing the upstream router not toforward packets in this group to the leaf

In RPM, first packet still needs to be forwarded throughout thenetwork.

Each router has to maintain state information for all groups. Itwill be impossible as the number of groups and sourcesincreases.

8/12/2019 Multi Cast Summary Pp t 1469

25/61

3.3.5 Reverse Path Multicasting (RPM)

Source,

G

G

G

First packet of G

G Member subnetwork

Non-member

subnetwork

Prune message

8/12/2019 Multi Cast Summary Pp t 1469

26/61

3.3.6 Core Based Trees (CBT)

There is a backbone for CBT. It includes both

core and non-core routers.

8/12/2019 Multi Cast Summary Pp t 1469

27/61

3.3.6 Core Based Trees (CBT)

If a host wants to join one group, it has to send a unicast joinrequest message to the core. The nearest router in thebackbone will respond with ACK and the intermediate routerswill record the routing information, thus a delivery tree for agroup is established

Compared to previous algorithms, CBT can use bandwidth androuter resources more efficiently

CBT may result in traffic concentration and bottlenecks near

core routers since traffic from all sources traverses the sameset of links as it approaches the core

A single shared tree may create trees not as optimal as source-trees

8/12/2019 Multi Cast Summary Pp t 1469

28/61

3.4 Multicast Protocols

3.4.1 Distance Vector Multicast Routing Protocol(DVMRP)

3.4.2 Multicast OSPF (MOSPF)

3.4.3 Protocol-Independent Multicast (PIM)

3.4.4 BGMP and MASC

8/12/2019 Multi Cast Summary Pp t 1469

29/61

3.4.1 Distance Vector Multicast Routing

Protocol (DVMRP)

Source-based trees, data-driven (broadcast-and-prune), implicitjoin, dense mode protocol

RPM algorithm Derived from Routing Information Protocol (RIP)

RIP forwards the unicast packets based on the next-hop towards adestination

DVMRP constructs delivery trees based on shortest previous-hopback to the source

DVMRP forwarding table: built from DVMRPs own routing table,received prune messages

TTL and admin scoping available; physical or tunnel interfacespossible

8/12/2019 Multi Cast Summary Pp t 1469

30/61

3.4.1 Distance Vector Multicast Routing

Protocol (DVMRP)

If router C can receive datagrams from both A and B, then itwill receive from A if As metric to the source is smaller than

Bs or if they are equal, A has the smaller IP address on its

downstream interface

8/12/2019 Multi Cast Summary Pp t 1469

31/61

3.4.1 Distance Vector Multicast Routing

Protocol (DVMRP)

Separate processes (and updates) for unicast and multicast

routing Limitations:

distance-vector => slow to adapt to topology changes;

Must store source-specific sate even when not on tree => scalingproblems

B A

Source

8/12/2019 Multi Cast Summary Pp t 1469

32/61

3.4.2 Multicast OSPF (MOSPF)

OSPF provides each router with the topology of theInternet or its OSPF area

MOSPF uses OSPFs topology database to calculateforwarding tree.

Broadcasting data for a group is demand-driven, thatmeans it happens only when a host joins or leaves agroup. Compared to data-driven protocols, the costis that routing information should be propagated,because all routers in an area must maintainmembership about every group

8/12/2019 Multi Cast Summary Pp t 1469

33/61

3.4.3 Protocol-Independent Multicast

(PIM)

PIM has two variants: Dense mode (DM) and sparsemode (SM) DM builds source-based trees in a data-driven (broadcast-and-

prune), implicit join manner

SM allows shared tree and uses explicit join.

PIM-DM it employs the Reverse Path Multicasting (RPM) algorithm

PIM-DM relies on the presence of an existing unicast routingprotocol to adapt to topology changes, but it is independent of themechanisms of the specific unicast routing protocol, while DVMRPhas its own routing table

PIM-DM simply forwards multicast traffic on all downstreaminterfaces until explicit prune messages are received

8/12/2019 Multi Cast Summary Pp t 1469

34/61

3.4.3 Protocol-Independent Multicast

(PIM)

PIM-SM

Routers with directly attached or downstream members arerequired to join a sparse-mode distribution tree bytransmitting explicit join messages

PIM-SM is similar to the Core-Based Tree (CBT) approach inthat it employs the concept of a rendezvous point (RP)where receivers "meet" sources

Join a PIM-SM

distributiontree

8/12/2019 Multi Cast Summary Pp t 1469

35/61

3.4.3 Protocol-Independent Multicast

(PIM)

PIM-SM (cont.) When a host first transmits a multicast packet to a group, its

DR encapsulates the multicast packet in a PIM-SM-Register

packet and unicasts it to the primary RP. The RP respondsPIM-Join message. All routers between source and RPmaintain the route so that subsequent unencapsulatedmulticast packets could be forwarded to the RP

8/12/2019 Multi Cast Summary Pp t 1469

36/61

3.4.3 Protocol-Independent Multicast

(PIM)

PIM-SM (cont.)

PIM-SM allows receivers to either continue to receive

multicast traffic over the RP-shared tree or over a source-rooted shortest-path tree that a receiver subsequently creates.

The shortest-path tree allows a group member to reduce the

delay between itself and a particular source

8/12/2019 Multi Cast Summary Pp t 1469

37/61

3.4.4 BGMP and MASC

BGMP (Border Gateway Multicast Protocol )

BGMP builds shared tree of domains for a group

So we can use a rendezvous mechanism at the domain levelShared tree is bidirectional

Root of shared tree of domains is at root domain

Runs in routers that border a multicast routing domain

Runs over TCP

Joins and prunes travel across domains Can build unidirectional source trees

8/12/2019 Multi Cast Summary Pp t 1469

38/61

3.4.4 BGMP and MASC

unidirectional

source

tree

8/12/2019 Multi Cast Summary Pp t 1469

39/61

3.4.4 BGMP and MASC

MASC (Multicast Address Set Claim )

Group prefixes are temporarily leased to domains

Allocated by ISP who in turn received them from itsupstream provider

Claims for group allocation resolve collisions

Group allocations are advertised across domains

Group prefix allocations are not assigned to domainstheyare leased

Applications must know that group addresses may go away

RFC 2909

8/12/2019 Multi Cast Summary Pp t 1469

40/61

3.4.4 BGMP and MASC

8/12/2019 Multi Cast Summary Pp t 1469

41/61

4 Deployment Issues of Multicast

Current architecture deters the commercial deployment ofmulticast.

Router mitigation: Older hardware doesnt support multicast. If

software upgrade is not applicable, the routers are forced intoearly retirement

Domain independent: For sparse mode multicast, its better to useCBT or PIM-SM. However, many problems are present whenRPs/core and sources are in different domains Traffic sources in other domains may require traffic controls, such as

rate or congestion control

ISP has little control over receivers who receive messages from anRP in another domain

ISP refuses to be a core if it has no receives or sources

Advertisement of the addresses of the RP/core is not very easy

8/12/2019 Multi Cast Summary Pp t 1469

42/61

4 Deployment Issues of Multicast

Current architecture deters the commercialdeployment of multicast (cont.) Group management: Current service model does

not consider group management, includingreceiver/transmitter authorization, group creation,billing, etc. Dangers: Flooding attack

Collision of sessions

Unauthorized reception

Changing the content of a session

8/12/2019 Multi Cast Summary Pp t 1469

43/61

4 Deployment Issues of Multicast Current architecture deters the commercial deployment of multicast (cont.)

Multicast security:

Authentication, authorization, encryption and data integrity

Current IP multicast service and architecture do not mandate any authentication

Encryption is appropriate mechanism to preserve data privacy at application level Secure Multicast services are network level solutions to ensure that multicast tree

construction and delivery services are restricted to authenticated and authorized hosts(i.e. KHIP)

MSEC - Multicast Security (MSEC@IETF)

Drafts:

The Group Domain of Interpretation (draft-ietf-msec-gdoi-06.txt)

Group Key Management Architecture (draft-ietf-msec-gkmarch-03.txt)

GSAKMP Light (draft-ietf-msec-gsakmp-light-sec-01.txt) MIKEY: Multimedia Internet KEYing (draft-ietf-msec-mikey-04.txt)

HMAC-authenticated Diffie-Hellman for MIKEY (draft-ietf-msec-mikey-dhhmac-00.txt)

RFCs:

http://www.ietf.org/html.charters/msec-charter.htmlhttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gdoi-06.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gkmarch-03.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-04.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-04.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-04.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-04.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-04.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-04.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-04.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-04.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-04.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-04.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gkmarch-03.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gkmarch-03.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gkmarch-03.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gkmarch-03.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gkmarch-03.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gkmarch-03.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gkmarch-03.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gkmarch-03.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gkmarch-03.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gdoi-06.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gdoi-06.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gdoi-06.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gdoi-06.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gdoi-06.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gdoi-06.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gdoi-06.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gdoi-06.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gdoi-06.txthttp://www.ietf.org/html.charters/msec-charter.html

8/12/2019 Multi Cast Summary Pp t 1469

44/61

4 Deployment Issues of Multicast

Current architecture deters the commercial deployment of multicast(cont.) Address allocation: When multicast service is popular, address allocation

will be a big problem. Currently there are four alternatives for addressallocation. MAAA: It is very complicated, consisting of three protocols which connect hosts,

domains, address allocation servers. The allocation of addresses betweendomains is handled by Multicast Address Set Claim (MASC). Multicast AddressDynamic Client Allocation Protocol (MADCAP) is used by host to requestaddress from server. The servers inform each other of claimed address blocks byAddress Allocation Protocol (AAP). However, MAAA never considers whetheraddress resource is enough

Static allocation and assignment (GLOP): Restrict addresses available todomains by AS numbers

EXPRESS model: Uses per source and channel (S,E) structure, so each sourcecan have 16 million channels

IPv6 addressing: IPv6 provides sufficient addresses

8/12/2019 Multi Cast Summary Pp t 1469

45/61

4 Deployment Issues of Multicast

Some alternate service models

EXPRESS

Application level multicast: Application level

multicast has the potential to address most

problems associated with IP multicast, since its

based on unicast. However, Application level

multicast can not perform as well as IP multicast.The reason is that some redundant traffic on

physical links is unavoidable

8/12/2019 Multi Cast Summary Pp t 1469

46/61

5 EXPRESS (Explicitly Requested

Single Source Multicast)

5.1 EXPRESS channel model and

advantages

5.2 EXPRESS count management protocol

(ECMP)

5.3 Multi-source applications

5.4 Cost of EXPRESS and conclusion

8/12/2019 Multi Cast Summary Pp t 1469

47/61

5.1 EXPRESS channel model and

advantages

1. Channel Model The channel model is identified by (S,E), where S is the

single source and E is a channel destination address

Only source S can send datagrams to (S,E)

If a subscriber host wants to receive data from S, it shouldexplicitly specify both S and E in its request

Compared to group model, (S,E) and (S,E) are unrelated.That means a subscriber to (S,E) wont receive data from(S,E)

Class D address (232.*.*.*) are assigned for experimentaluse by EXPRESS

8/12/2019 Multi Cast Summary Pp t 1469

48/61

5.1 EXPRESS channel model and

advantages

Channel Model Group Model

8/12/2019 Multi Cast Summary Pp t 1469

49/61

5.1 EXPRESS channel model and

advantages

2. EXPRESS Service Interface Extensions Source Host

count = CountQuery (channel, countId, timeout)is used tocollect count information for the channel

channelKey (channel, K(S,E)) is used to inform the networkthat the channel is authenticated

Subscriber Host

result = newSubscription (channel, [K(S,E)])is used to

participate in a channel result = deleteSubscription (channel)is used to unsubscribe

form a channel

count (channel, countId, count)is used to reply to CountQuery

8/12/2019 Multi Cast Summary Pp t 1469

50/61

5.1 EXPRESS channel model and

advantages

3 Advantages

EXPRESS provides 2 channels per source.

Channels neednt be treated as scarce resource

The source has exclusive access to a channel

A subscriber can only get data from the

designated source

Single source and knowledge of subscriber

numbers enables ISP easy in charging

24

8/12/2019 Multi Cast Summary Pp t 1469

51/61

5.2 EXPRESS count management

protocol (ECMP)

ECMP maintains the distribution tree and supports

source-directed counting and voting

Routing aspect of ECMP is simple because explicitsource specification allows reverse path forwarding

(RPF)

ECMP consists of three messages:

CountQuery(channel, countId, timeout)

Count(channel, CountId, K(S,E))

CountResponse(channel, CountId, status)

8/12/2019 Multi Cast Summary Pp t 1469

52/61

5.2 EXPRESS count management

protocol (ECMP)

Generic Counting Operation

CountQuery can start at source or any router on the channeldistribution tree. A sub-range of CountIds are defined for local use.

The query is sent from source to the first hop router, specifying achannel, countId and timeout

Receiving router minus timeout value by the measured round-triptime to its upstream router, and send the query to eachdownstream router

An end-station host responds to CountQuery with Count message

The value in the Count response is recorded locally. Once Countsare received from all neighbors or timeout, the counts are summedand the total is sent upstream in a Count reply

8/12/2019 Multi Cast Summary Pp t 1469

53/61

5.2 EXPRESS count management

protocol (ECMP)

Distribution Tree Maintenance subscriberId is a reserved countId used to report number of

subscribers in a subtree

A newSubscription causes an unsolicited subscriberId Countmessage to be propagated to the channel source, just as a hostjoins to the core in CBT

A host unsubscribes by sending zero Count message

For authenticated subscription, the upstream router usesCoutResponse to deny or validate the user. A valid key is cachedin the local router

Core routers are connected by TCP, using Count message tomaintain the connection

Edge routers are connected by UDP. Upstream routers have tosend CountQuery periodically to maintain the tree, like IGMP

8/12/2019 Multi Cast Summary Pp t 1469

54/61

5.2 EXPRESS count management

protocol (ECMP)

8/12/2019 Multi Cast Summary Pp t 1469

55/61

5.2 EXPRESS count management

protocol (ECMP)

Neighbor discovery uses neighbors countId, and fora local LAN, all channels countId is used byCountQuery, as IGMP general query

Packet forwarding is like conventional multicast. Arouter looks up (S,E) after receiving an EXPRESSpacket

Authentication is used based on trust of routers. Toget more security, end-to-end encryption can beused

Due to single source, ECMP is easy to manage andimplement

8/12/2019 Multi Cast Summary Pp t 1469

56/61

5.3 Multi-source applications

Multi-source applications can be built on EXPRESSchannels either by using multiple channels, one persource, or by allowing multiple sources to share achannel using higher-level relaying. The later one isspecially used for almost single source

Almost single source can have several sources, butone of them is the main source

Session relay approach uses an SR host to relaypackets. The main resource can reside on it.Packets are transferred from source station to SRhost by unicast

8/12/2019 Multi Cast Summary Pp t 1469

57/61

5.3 Multi-source applications

8/12/2019 Multi Cast Summary Pp t 1469

58/61

5.3 Multi-source applications

Advantages of session relay

The application can select the SR placement, thus reducecommunication

Backup SRs can be used for fault-tolerance

The SR can provide extra application-specific functionality beyondsimply relaying data, as it can add sequence numbers to relayedpackets

Can be used by ISP to provide session relay service. Standardrelaying and accessing protocol is needed

Session relay is like CBT but the later one has no applicationlevel control

Relaying time is not significant in wide area applications

8/12/2019 Multi Cast Summary Pp t 1469

59/61

5.4 Cost of EXPRESS

The key cost of EXPRESS Cost of router FIB memory for channels (12 bytes

for each entry) Cost of management-level router state (16 bytes

for each count activity)

Cost of maintaining this state (the cost growing

linearly with the number of channels) The incremental costs of EXPRESS can be

neglected compared to economic effects

8/12/2019 Multi Cast Summary Pp t 1469

60/61

5.4 Cost of EXPRESS

Counting: to get an average number of customers ina long period by polling doesnt affect systems

performance Proactive Counting: Receivers and routers

proactively send Count upstream without requiring aCountQuery solicitation. Get more accurate estimation of user number, consume

more bandwidth The convergence time of the algorithm grows approximately

linearly with the depth of the tree, while the depth of a treegrows logarithmically with the group size

8/12/2019 Multi Cast Summary Pp t 1469

61/61

6 References Douglas E. Comer, Internetworking with TCP/IP vol1, Principles,

Protocols, and Architectures, 4thedition Pages:319-350

Chuck Semeria and Tom Maufer, Introduction to IP Multicast Routing

L. Sahasrabuddhe and B. Mukherjee, Multicast Routing Algorithmsand Protocols: A Tutorial, IEEE Network, Vol. 14, No. 1,January/February 2000

H. Holbrook and D. Cheriton, IP Multicast Channels: Express Supportfor Large-scale Single-source Applications, Proc. of ACM SIGCOMMConference 1999

C. Diot, D. Levine, B. Lyles, H. Kassem, and D. Balensiefen,

Deployment Issues for the IP Multicast Service and Architecture, IEEENetwork, Vol. 14, No. 1, January/February 2000

http://www.nleymann.de/ip-multicast/mcLinksMain.htm

http://www.nleymann.de/ip-multicast/mcLinksMain.htmhttp://www.nleymann.de/ip-multicast/mcLinksMain.htmhttp://www.nleymann.de/ip-multicast/mcLinksMain.htmhttp://www.nleymann.de/ip-multicast/mcLinksMain.htm