Presentation is loading. Please wait.

Presentation is loading. Please wait.

Summary of IP Multicast

Similar presentations


Presentation on theme: "Summary of IP Multicast"— Presentation transcript:

1 Summary of IP Multicast
CPSC 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 Video conference Distance learning

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

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

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

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 ~ Base address: is reserved ~ 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 E 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)
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)

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 (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. Flooding Spanning Trees Reverse Path Broadcasting (RPB) Truncated Reverse Path Broadcasting (TRPB) Reverse Path Multicasting (RPM) Core Based Trees (CBT)

20 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

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 Core Based Trees (CBT) There is a backbone for CBT. It includes both core and non-core routers.

27 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 Multicast Protocols Distance Vector Multicast Routing Protocol (DVMRP) Multicast OSPF (MOSPF) Protocol-Independent Multicast (PIM) 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)
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

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

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

52 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

53 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

54 5.2 EXPRESS count management protocol (ECMP)

55 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

56 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

57 5.3 Multi-source applications

58 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

59 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

60 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

61 6 References Douglas E. Comer, Internetworking with TCP/IP vol1, Principles, Protocols, and Architectures, 4th edition Pages: 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


Download ppt "Summary of IP Multicast"

Similar presentations


Ads by Google