1 / 61

Summary of IP Multicast

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.

jela
Download Presentation

Summary of IP Multicast

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

  4. 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

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

  6. 1.1 Why Multicast /Multicast Applications • ConferenceXP: An Example of Multicast application Distance Learning Video Conference

  7. 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. 1.2 Broadcast/Unicast/Multicast UNICAST With 4 receivers, sender must replicate the stream 4 times

  9. 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.

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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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

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

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

  21. 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

  22. 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

  23. 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

  24. 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.

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

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

  27. 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

  28. 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

  29. 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

  30. 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

  31. 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 Source B A

  32. 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

  33. 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

  34. 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

  35. 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

  36. 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

  37. 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

  38. 3.4.4 BGMP and MASC unidirectional source tree

  39. 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

  40. 3.4.4 BGMP and MASC

  41. 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

  42. 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

  43. 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>

  44. 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

  45. 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

  46. 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

  47. 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

  48. 5.1 EXPRESS channel model and advantages Channel Model Group Model

  49. 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

  50. 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

More Related