Top Banner
Summary of IP Multicast CPSC 601.43 Course Director: Dr. Anirban Mahanti Student : Liqi Shi
61
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: MulticastSummary.ppt

Summary of IP Multicast

CPSC 601.43Course Director: Dr. Anirban Mahanti

Student : Liqi Shi

Page 2: MulticastSummary.ppt

Outline

1. Introduction to Multicast

2. Multicast Group and Service Model

3. Multicast Routing

4. Deployment Issues of Multicast

5. EXPRESS

6. References

Page 3: MulticastSummary.ppt

1 Introduction to Multicast

1.1 Why Multicast /Multicast Applications

1.2 Broadcast/Unicast/Multicast

Page 4: MulticastSummary.ppt

1.1 Why Multicast /Multicast Applications

Same data sent to multiple receivers To use the bandwidth efficiently Reduce routing processing Sender doesn’t get receiver’s address

Page 5: MulticastSummary.ppt

1.1 Why Multicast /Multicast Applications

Video/audio conference IP TV, Video on Demand Advertisement, Stock, Distance learning Synchronizing of distributed database,

websites

Page 6: MulticastSummary.ppt

1.1 Why Multicast /Multicast Applications

ConferenceXP: An Example of Multicast application

Video ConferenceDistance Learning

Page 7: MulticastSummary.ppt

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

Page 8: MulticastSummary.ppt

1.2 Broadcast/Unicast/Multicast

UNICAST

With 4 receivers, sender must replicate the stream 4 times

Page 9: MulticastSummary.ppt

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.

Page 10: MulticastSummary.ppt

2 Multicast Group and Service Model

Each multicast group is identified by a class D IP address

Members of the group could be anywhere in the Internet

Members can join and leave the group and indicate this to the routers

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

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

Page 11: MulticastSummary.ppt

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 multicast

datagram

Page 12: MulticastSummary.ppt

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

Page 13: MulticastSummary.ppt

3 Multicast Routing

3.1 Transmission and Delivery of Multicast Datagram3.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

Page 14: MulticastSummary.ppt

3.1 Transmission and Delivery of Multicast Datagram

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

network interface card maps the Class D address to the corresponding Ethernet 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 the

construction 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

Page 15: MulticastSummary.ppt

3.2 Internet Group Management Protocol (IGMP)

Introduction IGMP runs between hosts and the

nearest multicast routers. A local host can use it to inform the router which multicast group it wants to be added in, while the multicast routers can use it to poll the LAN periodically, thus determine if known group members are still

active IGMP message format

Type 0x11 0x11 0x16 0x17 0x12

Group Address

unused

used used used used

Meaning

General membership query

Specific membership query

Membership report

Leave group

Membership report (V1)

0 8 16 32

Page 16: MulticastSummary.ppt

3.2 Internet Group Management Protocol (IGMP)

IGMP versions– RFC1112, IGMP version 1– <draft-ietf-idmr-igmp-v2-01.txt>, 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 Query message

defines a Leave Group message – <draft-cain-igmp-00. txt>, 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 2 has been enhanced to support Group-Source Leave messages. This feature allows a host to leave an entire group or to specify the specific IP address(es) of the (source, group) pair(s) that it wishes to leave

Page 17: MulticastSummary.ppt

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 multicast address declaring membership.

Local multicast router receives the message and establishes necessary routing path

– Group membership report Router sends Host Membership Query to 224.0.0.1 (all multicast hosts

on a subnet) Host responds with Host Membership report for each group to which it

belongs (sent to group address) other hosts in the same group “suppress” reports Router periodically broadcasts query to detect if groups have gone

away

Page 18: MulticastSummary.ppt

3.2 Internet Group Management Protocol (IGMP) Each host responds

to the query with a random delay. If one report is received at the router, the other reports will be suppressed

Page 19: MulticastSummary.ppt

3.3 Multicast Forwarding Algorithms

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

3.3.1 Flooding3.3.2 Spanning Trees3.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)

Page 20: MulticastSummary.ppt

3.3.1 Flooding

When a router receives a packet, the router will determine whether it’s the first time it receives the packet. If so, the packet will be delivered to all interfaces except the one on which it arrived, 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

Page 21: MulticastSummary.ppt

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 source

subnetwork and group members

Page 22: MulticastSummary.ppt

3.3.3 Reverse Path Broadcasting (RPB)

A local router only accepts packets from the ‘nearest’ source (parent), otherwise the packets are discarded

Accepted packets will be forwarded to all interfaces except the source

it does not take into account multicast group membership when building the distribution tree, so packets may be forwarded to non-membership subnetwork

Page 23: MulticastSummary.ppt

3.3.4 Truncated Reverse Path Broadcasting (TRPB)

It’s an enhancement of RPB With the help of IGMP,

multicast routers determine the group membership on each leaf subnetwork, thus avoiding forwarding packets to non-members

Eliminates unnecessary traffic on leaf subnetworks , but does not consider group memberships when building the

branches of the distribution tree

Source,G1

G1

G2

G3

Truncated

Page 24: MulticastSummary.ppt

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 group

members First packet will be sent to all interfaces except the source. If

none of the subnetworks connected to the leaf router have group members, the leaf router may transmit a "prune" message on its parent link informing the upstream router not to forward packets in this group to the leaf

In RPM, ‘first packet’ still needs to be forwarded throughout the network.

Each router has to maintain state information for all groups. It will be impossible as the number of groups and sources increases.

Page 25: MulticastSummary.ppt

3.3.5 Reverse Path Multicasting (RPM)

Source, G

G

G

First packet of G

G Member subnetwork

Non-member subnetwork

Prune message

Page 26: MulticastSummary.ppt

3.3.6 Core Based Trees (CBT)

There is a backbone for CBT. It includes both core and non-core routers.

Page 27: MulticastSummary.ppt

3.3.6 Core Based Trees (CBT)

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

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

CBT may result in traffic concentration and bottlenecks near core routers since traffic from all sources traverses the same set of links as it approaches the core

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

Page 28: MulticastSummary.ppt

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

Page 29: MulticastSummary.ppt

3.4.1 Distance Vector Multicast Routing Protocol (DVMRP)

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

RPM algorithm Derived from Routing Information Protocol (RIP)

– RIP forwards the unicast packets based on the next-hop towards a destination

– DVMRP constructs delivery trees based on shortest previous-hop back to the source

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

TTL and admin scoping available; physical or tunnel interfaces possible

Page 30: MulticastSummary.ppt

3.4.1 Distance Vector Multicast Routing Protocol (DVMRP)

If router C can receive datagrams from both A and B, then it will receive from A if A’s metric to the source is smaller than B’s or if they are equal, A has the smaller IP address on its downstream interface

Page 31: MulticastSummary.ppt

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 => scaling

problems

B A

Source

Page 32: MulticastSummary.ppt

3.4.2 Multicast OSPF (MOSPF)

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

MOSPF uses OSPF’s topology database to calculate forwarding tree.

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

Page 33: MulticastSummary.ppt

3.4.3 Protocol-Independent Multicast (PIM)

PIM has two variants: Dense mode (DM) and sparse mode (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 routing

protocol to adapt to topology changes, but it is independent of the mechanisms of the specific unicast routing protocol, while DVMRP has its own routing table

– PIM-DM simply forwards multicast traffic on all downstream interfaces until explicit prune messages are received

Page 34: MulticastSummary.ppt

3.4.3 Protocol-Independent Multicast (PIM)

PIM-SM– Routers with directly attached or downstream members are

required to join a sparse-mode distribution tree by transmitting explicit join messages

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

Join a PIM-SM distribution tree

Page 35: MulticastSummary.ppt

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 responds PIM-Join message. All routers between source and RP maintain the route so that subsequent unencapsulated multicast packets could be forwarded to the RP

Page 36: MulticastSummary.ppt

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

Page 37: MulticastSummary.ppt

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 level Shared 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

Page 38: MulticastSummary.ppt

3.4.4 BGMP and MASC

unidirectional source tree

Page 39: MulticastSummary.ppt

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 its

upstream provider– Claims for group allocation resolve collisions– Group allocations are advertised across domains– Group prefix allocations are not assigned to domains—they

are leased Applications must know that group addresses may go away

– RFC 2909

Page 40: MulticastSummary.ppt

3.4.4 BGMP and MASC

Page 41: MulticastSummary.ppt

4 Deployment Issues of Multicast

Current architecture deters the commercial deployment of multicast.– Router mitigation: Older hardware doesn’t support multicast. If

software upgrade is not applicable, the routers are forced into early retirement

– Domain independent: For sparse mode multicast, it’s better to use CBT or PIM-SM. However, many problems are present when RPs/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 an

RP 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

Page 42: MulticastSummary.ppt

4 Deployment Issues of Multicast

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

not consider group management, including receiver/transmitter authorization, group creation, billing, etc. Dangers:

Flooding attack Collision of sessions Unauthorized reception Changing the content of a session

Page 43: MulticastSummary.ppt

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:

– <none>

Page 44: MulticastSummary.ppt

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 address allocation.

MAAA: It is very complicated, consisting of three protocols which connect hosts, domains, address allocation servers. The allocation of addresses between domains is handled by Multicast Address Set Claim (MASC). Multicast Address Dynamic Client Allocation Protocol (MADCAP) is used by host to request address from server. The servers inform each other of claimed address blocks by Address Allocation Protocol (AAP). However, MAAA never considers whether address resource is enough

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

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

IPv6 addressing: IPv6 provides sufficient addresses

Page 45: MulticastSummary.ppt

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 it’s 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

Page 46: MulticastSummary.ppt

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

Page 47: MulticastSummary.ppt

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 should

explicitly 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) won’t receive data from (S’,E)

– Class D address (232.*.*.*) are assigned for experimental use by EXPRESS

Page 48: MulticastSummary.ppt

5.1 EXPRESS channel model and advantages

Channel Model Group Model

Page 49: MulticastSummary.ppt

5.1 EXPRESS channel model and advantages

2. EXPRESS Service Interface Extensions– Source Host

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

channelKey (channel, K(S,E)) is used to inform the network that 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

Page 50: MulticastSummary.ppt

5.1 EXPRESS channel model and advantages

3 Advantages– EXPRESS provides 2 channels per source.

Channels needn’t 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

Page 51: MulticastSummary.ppt

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 explicit source 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)

Page 52: MulticastSummary.ppt

5.2 EXPRESS count management protocol (ECMP)

Generic Counting Operation– CountQuery can start at source or any router on the channel

distribution tree. A sub-range of CountIds are defined for local use.– The query is sent from source to the first hop router, specifying a

channel, countId and timeout– Receiving router minus timeout value by the measured round-trip

time to its upstream router, and send the query to each downstream router

– An end-station host responds to CountQuery with Count message– The value in the Count response is recorded locally. Once Counts

are received from all neighbors or timeout, the counts are summed and the total is sent upstream in a Count reply

Page 53: MulticastSummary.ppt

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 Count

message to be propagated to the channel source, just as a host joins to the core in CBT

– A host unsubscribes by sending zero Count message– For authenticated subscription, the upstream router uses

CoutResponse to deny or validate the user. A valid key is cached in the local router

– Core routers are connected by TCP, using Count message to maintain the connection

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

Page 54: MulticastSummary.ppt

5.2 EXPRESS count management protocol (ECMP)

Page 55: MulticastSummary.ppt

5.2 EXPRESS count management protocol (ECMP)

Neighbor discovery uses ‘neighbors’ countId, and for a local LAN, ‘all channels’ countId is used by CountQuery, as IGMP general query

Packet forwarding is like conventional multicast. A router looks up (S,E) after receiving an EXPRESS packet

Authentication is used based on trust of routers. To get more security, end-to-end encryption can be used

Due to single source, ECMP is easy to manage and implement

Page 56: MulticastSummary.ppt

5.3 Multi-source applications

Multi-source applications can be built on EXPRESS channels either by using multiple channels, one per source, or by allowing multiple sources to share a channel using higher-level relaying. The later one is specially used for ‘almost single source’

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

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

Page 57: MulticastSummary.ppt

5.3 Multi-source applications

Page 58: MulticastSummary.ppt

5.3 Multi-source applications

Advantages of session relay– The application can select the SR placement, thus reduce

communication– Backup SRs can be used for fault-tolerance– The SR can provide extra application-specific functionality beyond

simply relaying data, as it can add sequence numbers to relayed packets

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

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

Relaying time is not significant in wide area applications

Page 59: MulticastSummary.ppt

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

Page 60: MulticastSummary.ppt

5.4 Cost of EXPRESS

Counting: to get an average number of customers in a long period by polling doesn’t affect system’s performance

Proactive Counting: Receivers and routers proactively send Count upstream without requiring a CountQuery 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 tree grows logarithmically with the group size

Page 61: MulticastSummary.ppt

6 References

Douglas E. Comer, Internetworking with TCP/IP vol1, Principles, Protocols, and Architectures, 4th edition Pages:319-350

Chuck Semeria and Tom Maufer, Introduction to IP Multicast Routing L. Sahasrabuddhe and B. Mukherjee, Multicast Routing Algorithms

and Protocols: A Tutorial, IEEE Network, Vol. 14, No. 1, January/February 2000

H. Holbrook and D. Cheriton, IP Multicast Channels: Express Support for Large-scale Single-source Applications, Proc. of ACM SIGCOMM Conference 1999

C. Diot, D. Levine, B. Lyles, H. Kassem, and D. Balensiefen, Deployment Issues for the IP Multicast Service and Architecture, IEEE Network, Vol. 14, No. 1, January/February 2000

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