Summary of IP Multicast CPSC 601.43 Course Director: Dr. Anirban Mahanti Student : Liqi Shi

Outline Introduction to Multicast Multicast Group and Service Model Multicast Routing Deployment Issues of Multicast EXPRESS References

1 Introduction to Multicast 1.1 Why Multicast /Multicast Applications 1.2 Broadcast/Unicast/Multicast

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

1.1 Why Multicast /Multicast Applications Video/audio conference IP TV, Video on Demand Advertisement, Stock, Distance learning Synchronizing of distributed database, websites

1.1 Why Multicast /Multicast Applications ConferenceXP: An Example of Multicast application Distance Learning Video Conference Video conference Distance learning

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 Broadcast and unicast can be seen as two special types of Multicast

1.2 Broadcast/Unicast/Multicast With 4 receivers, sender must replicate the stream 4 times

1.2 Broadcast/Unicast/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.

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)

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

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

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

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

3.2 Internet Group Management Protocol (IGMP) 0 8 16 32 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 0x16 0x17 0x12 Group Address unused used Meaning General membership query Specific membership query Membership report Leave group Membership report (V1)

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

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

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

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

3.3.1 Flooding Non-red streams will be discarded according to flooding algorithm SRC 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

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

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

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 G3 G2 Truncated

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.

3.3.5 Reverse Path Multicasting (RPM) Source, G First packet of G G G Member subnetwork Non-member subnetwork Prune message G

3.3.6 Core Based Trees (CBT) There is a backbone for CBT. It includes both core and non-core routers.

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

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

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

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

3.4.1 Distance Vector Multicast Routing Protocol (DVMRP) Source B A 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

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

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

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

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

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

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

3.4.4 BGMP and MASC unidirectional source tree

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

3.4.4 BGMP and MASC

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

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

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>

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

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

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

5.1 EXPRESS channel model and advantages 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

5.1 EXPRESS channel model and advantages Group Model

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

5.1 EXPRESS channel model and 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

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)

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

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

5.2 EXPRESS count management protocol (ECMP)

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

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

5.3 Multi-source applications

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

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

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

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