1 / 38

G54ACC Advanced Computer Communications

G54ACC Advanced Computer Communications. Introduction to IP Multicast. Contents. Overview Multicast Applications Multicast Addressing Group Membership Protocol Multicast Forwarding (Delivery) Algorithms Implementation and Research Issues. One to Many Communication.

halden
Download Presentation

G54ACC Advanced Computer Communications

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. G54ACCAdvanced Computer Communications Introduction to IP Multicast

  2. Contents • Overview • Multicast Applications • Multicast Addressing • Group Membership Protocol • Multicast Forwarding (Delivery) Algorithms • Implementation and Research Issues

  3. One to Many Communication • Application level one to many communication • multiple unicasts • IP multicast R R S S R R R R

  4. Why Multicast • When sending same data to multiple receivers • better bandwidth utilization • less host/router processing • latency between the first and last receiver getting a copy can be drastically reduced

  5. Multicast Applications • One-to-many • A/V distribution, push media, file distribution, caching, announcements, monitoring (e.g. stock quotes), software distribution, E-mail distribution lists • Many-to-many • A/V conferencing, synchronized resources (e.g. distributed databases), collaboration, chat groups, multiplayer games

  6. Multicast Operation • Defines “multicast groups” • like a host (destination) address • but identifies a logical destination or group • Any number of hosts can • send packets to a multicast group • join a multicast group • => receive packets sent to that group • Plus • each packet crosses any network at most once • packets are filtered in the NICs and hosts for interest (joined)

  7. IP Multicast Service Model • RFC1112 : Host Extensions for IP Multicasting • Transmission of an IP datagram to a"host group" • Host group identified by a class D IP address • Groups can have any size • Group members can be located anywhere in the Internet • Member can join and leave the group at will • Senders and receivers are distinct: i.e., a sender need not be a member • Group membership is not explicitly known

  8. IP Multicast Group Addresses • Class D address space • high-order three 3 bits are set • 224.0.0.0 ~ 239.255.255.255 • Well-known address designated by IANA • permanent as listed in RFC1700 • 224.0.0.0 ~ 224.0.0.255 • 224.0.0.0 is reserved • 224.0.0.1~224.0.0.255 for use of routing protocols and other low level topology discovery or maintenance protocols • 224.0.0.1 (ALL-SYSTEMS.MCAST.NET) • all multicast systems on the subnet • 224.0.0.2 (ALL-ROUTERS.MCAST.NET) • all multicast routers on the subnet • http://www.iana.org/assignments/multicast-addresses

  9. Temporary Addresses • MBONE • 224.2.0.0~224.2.255.255 • Transient multicast group • assigned and reclaimed dynamically, e.g. • 239.192.0.0 – 239.251.255.255 can be used within organisation • 239.252.0.0 – 239.255.255.255 reserved for local site applications

  10. Converting IP Multicast Addresses to Ethernet (Hardware) Multicast Addresses 0xE = 1110 28-bit group address 5 bits are ignored e IP Class D address Low order 23 bits 01 00 5e Ethernet Multicast Address universally administered group address All Ethernet Multicast Addresses start with 3 fixed byte values: 0x01005e

  11. Address Binding • The mapping of multicast IP addresses to Ethernet addresses is not one-to-one • we are ignoring 5 bits in IP multicast address • multiple multicast IP addresses (<= 32 ) can map to the same Ethernet multicast address • imperfect hardware filtering by the device driver will accept the frame • perfect filtering by the IP layer will solve the problems associated with this • ARP not required, simpler than unicast

  12. Requirements for Multicasting • Multicasting on a LAN • hosts (IPv4) should support multicasting • Multicasting on WAN • hosts (IPv4) should support multicasting • one of the followings should be supported: • either connected routers should support multicasting and be able to tunnel multicast packets • or some hosts should be able to tunnel multicast packets. • or all routers should support multicasting.

  13. Multicasting on LAN Receiver app sending app sendto() destIP = 224.0.1.1 destPort = 123 Port: 123 Join 224.0.1.1 UDP UDP UDP Perfect SW filtering IP IP IP 139.139.10.20 receive 01:00:5e: 00:01:01 Imperfect HW filtering Data Link Data Link Data Link 08:00:10:1e:44:00:02 02:00:00:2c:7d:1e:00 08:00:60:8c:2f:4e:00 LAN Eth IPv4 UDP Data destPort = 123 destMAC = 01:00:5e:00:01:01 destIP = 224.0.1.1 protocol = UDP

  14. Multicasting on WAN join group S H1 MR1 MR5 Routers are multicast capable MRP MRP MRP MRP MR2 MR3 MR4 H2 H3 H4 H5 join group join group join group join group

  15. Tunneling • We can multicast data between “islands” of multicast routers in a “sea” of unicast routers • We use a technique called IP-in-IP tunneling • multicast datagram encapsulated inside “normal” unicast datagram addressed to receiving multicast router • receiving multicast router decapsulates to get multicast datagrams • MBONE uses this technique • MBONE:multicast backbone

  16. IP-in-IP Tunneling of Multicast Packets MR2 mhost mhost mhost Host running mrouted daemon tunneling IP UDP Data UR1 Unicast router Multicast address Multicast address IP IP UDP Data Multicast address Unicast address Unicast router UR2 IP UDP Data mhost mhost mhost Host running mrouted daemon MR5

  17. Internet Group Management Protocol (IGMP) join group MRP IGMP H MR1 MR2 MRP join group IGMP MR3 H ICMP IGMP IP When a host joins a multicast group, it uses IGMP protocol to convey this information to the router. Ethernet

  18. IGMP • “Signalling” protocol to establish, maintain, remove groups on a subnet • Encapsulated in an IP datagram with protocol type = 2 and TTL = 1 • Objective: keep router up-to-date with group membership of entire subnet • routers need not know who all the members are, only that members exist • Each host keeps track of which multicast groups it has subscribed to • socket API informs IGMP of all joins

  19. IGMP Message Types and Message Format

  20. IGMP Operation • If two or more multicast routers are connected to the subnet, one router will be elected as the “querier” (one with lowest IP address) • Querier periodically sends a Membership Query message to the all-systems group (224.0.0.1) • On receipt, hosts start random timers between zero and the maximum response time value • When a host’s timer expires, it sends a Membership Report • Other members belonging to the same group hear the report and suppress its own pending Membership Report message • Querier hears all reports and time out non-responding groups

  21. IGMP – Joining a group Example : H joins to Group 224.2.0.1 • H sends IGMP Membership-Reportto join 224.2.0.1 • DR receives it. DR will start forwarding packets for 224.2.0.1 to Network A • DR periodically sends IGMP Membership-Queryto 224.0.0.1 (ALL-SYSTEMS.MCAST.NET) • H answers IGMP Membership-Report about membership to 224.2.0.1 IGMP Membership-Report H Network A DR Data to 224.2.0.1 Network B H: ReceiverDR: Designated Router

  22. IGMP – Leaving a group Example : H leaves from a Group 224.2.0.1 • Leave Group message is used to reduce latency for leaving a multicast group • H sends IGMP Leave-Group to 224.0.0.2 (ALL-ROUTERS.MCAST.NET) • DR receives it and sends IGMP Group-Specific Query of224.2.0.1 to the subnet • DR stops forwarding packets for 224.2.0.1 to Network A if no more 224.2.0.1 group members on Network A. IGMP Leave-Group H Network A DR Network B Data to 224.2.0.1 H: ReceiverDR: Designated Router

  23. Multicast Delivery Algorithms • Basic objective is to build distribution trees for multicast packets • The “leaves” of the distribution tree are the subnets containing at least one group member (detected by IGMP) • Main approaches are: • Source Based • Group Shared

  24. Flooding • A node receiving a packet checks if it is the first reception of this packet • if yes, forwards the packet to all other interfaces except the incoming interface • otherwise the packet is dropped • Difficulty lies in the “first reception” test • a node remembers all the packets received so far • or, each packet contains the list of all the nodes crossed • Simple but very memory and network resource consuming  not scalable

  25. Reverse Path Broadcasting (RPB) • Rely on router’s knowledge of unicast shortest path from it to sender • For each (source, group) pair, if a packet arrives on a link that the local router considers to be the shortest path back to the source • forwards the packet to all other interfaces except the incoming interface • otherwise the packet is discarded • The interface over which the router expects to receive multicast packets from a particular source is referred to as the “parent” link. The outbound interfaces over which the router forwards the multicast packet are called the “child” links

  26. LEGEND R1 R4 router with attached group member R2 router with no attached group member R5 R3 R7 R6 datagram will not be forwarded Reverse Path Broadcasting: Example S: source datagram will be forwarded Assuming shortest path based on hop counts

  27. Reverse Path Multicasting (RPM) • Based on RPB and TRPB • guarantees that each leaf router receives the first multicast packet • If the connected subnets of the leaf router do not have members of the (source, group) pair, it transmits a “prune” message on its “parent” link informing the upstream router to stop forwarding on the “child” interface receiving the “prune” message • “prune” message can be generated one hop back towards the source if there is no local recipient and “prune” messages are received from all its child interfaces • The pruned state of the multicast forwarding tree is refreshed at regular intervals • Routers also have the option of sending “graft” messages on the parent links when directly connected hosts join a pruned group • Graft messages quickly “unprune” a link of a multicast tree

  28. Cored Based Tree (CBT) • Single delivery tree shared by all • A centre node (rendezvous point or core) is identified to be the centre of the multicast tree • Leaf routers with group membership unicast a “join” message addressed to the centre router • All intermediate routers forward the “join” message toward the core and interfaces used are marked until it either hit existing tree branch or arrives at the centre • Path taken by the “join” message becomes the new branch, i.e. the new path has been grafted onto the existing multicast tree

  29. Core Based Trees: Example Suppose R6 chosen as center: LEGEND R1 router with attached group member R4 3 router with no attached group member R2 2 1 R5 path order in which join messages generated R3 1 R7 R6

  30. Source Based TreesAdvantages and Disadvantages • Advantages: • simple implementation • packets follow shortest paths to all destinations • multicast distribution trees of different sources are different, enables traffic to be more distributed • Disadvantages: • multicast routing tables can grow very large, since they carry separate entries for each source • packets still arrive where they aren’t wanted • multicast router, whether it is or not on a path to a receiver, is required to maintain states for the distribution tree

  31. Shared Spanning TreeAdvantages and Disadvantages • Advantages: • can centralize traffic on a smaller number of links, so less memory is required • transmission strictly limited to the routers that are on the path to a receiver, no more duplicate packets at routers • Disadvantages: • shared tree needs to be explicitly constructed • shared trees do not necessarily create the most efficient paths from the source to all group members • spanning tree paths may become bottlenecks

  32. Implementation • For UDP only (unreliable datagrams) • Uses socket interface: java.net.MulticastSocket • Send multicast packets from a normal (unicast) UDP socket • Receive multicast packets only on a MulticastSocket • creating socket performs a JOIN operation • closing a socket performs a LEAVE operation

  33. Choosing Multicast Addresses • Statically allocated for standard services • RFC1700 / IANA (www.iana.org) • apply to IANA for an allocation • Dynamically allocated using Multicast Address Allocation Service • e.g. SDR tool for MM conferences • see IETF MALLOC working group (in progress) • Temporary workarounds • make one up and hope (check with RFCs/scopes)

  34. Scoping Multicast Traffic • With multicasting, very easy to send traffic all over • Would like to limit using scope control: • TTL based • based on Time to Live (TTL) field in IP header • only packets with a TTL > threshold cross boundary • Administrative scoping • set of addresses is not forwarded past domain e.g. 224.0.0.* never leaves subnet • more flexible than TTL based

  35. TTL Scope • Assign TTL threshold to each network interface: • if (packet TTL < threshold) drop packet • TTL threshold conventions: • 0 : same host, iff “loopback” is on for sending packet • 1 : same subnet • 31 : site/organisation • 63 : same region • 127 : continent • 255 : unlimited scope

  36. Administrative Scope (RFC 2365) • Configured in network • Link local scope • 224.0.0.0/24 • Site local scope • 239.252.0.0 – 239.255.255.255 • Organisation-local scope • 239.192.0.0 – 239.251.255.255 • Global scope • 224.0.1.0 – 238.255.255.255 e.g. 224.2.0.0 – 224.2.127.253 for Multimedia Conference Calls • See RFC1700 and/or IANA (www.iana.org)

  37. Multicast Research Issues • Reliable delivery • N.B. only a subset of receivers may have missed a packet • IRTF Reliable Multicast working group; IETF Reliable Multicast Transport working group • Flow and congestion control • N.B. only a subset (one?) of receivers may be experiencing congestion or buffer overflow => lowest common denominator?? • Deployment e.g. dynamic address allocation

  38. Multicast Routing Protocols

More Related