TSIN02 - Internetworking

Transcription

1 Lecture 3: Multicast Lecture 3: Multicast Goals: Understand the abstract idea with multicast and its benefits Get some insight into some applications using multicast Literature: Understand the IETF multicast architecture Fouruzan: p 108- Multicast Addresses Fouruzan: ch 10: IGMP RFC3170: IP Multicast Applications Challenges and Solutions Multicast addressing Multicasting on a LAN: the IGMP protocol IGMP evolution RFC1112, RFC2236, RFC3376 (IGMP ver 1,2,3) Layer-2 relation (Multicast routing Fouruzan: p 409- not part of this lecture) Gain some understanding regarding some emerging techniques Address allocation 2004 Image Coding Group, Linköpings Universitet Reliable multicast 2 Lecture 3: Multicast Communication Forms Outline: Applications (one-to-many, many-to-many) Multicast architecture Multicast addressing LAN mechanisms (IGMP v 2) One-to-one: In most applications the peer sends data exclusively to the receiver Examples: Web-traffic, Video-ondemand etc One-to-all: Support in layer 2 (IGMP snooping) What is all? (ans: the local network) IGMP ver 3 Emerging techniques Address allocation (Which addresses can I use?) Reliable multicast Requesting a service from a host with unknown IP#/MAC (Eg, DHCP, (R)ARP, SLP) Sending small pieces of information which are fundamental to most hosts (Eg, NTP, routing info) 3 4

2 Communication Forms cont One-to-many: Streaming TV/lectures/radio etc Push media and announcements Distributed requests (eg, DB-queries) Mass distribution of files Many-to-many Multimedia conferencing Synchronized resources Concurrent processing Communication Forms cont Major reasons why preferable over broadcast: Network may replicate packets and prune vast regions not interested in receiving packets Save network bandwidth Save packet processing cycles sender Pruned areas 5 Packet replication 6 Application Example #1 Application Example #2 TV over IP Videoconferencing Access network (turned off) Per channel: Potentially a very large group Just one sender Operator in control Works today Zaptime important! 7 Every receiver also a sender Many WAN:s/operators involved How to build the tree over domain boundaries? Inter domain multicast routing needed Scenario not yet globally deployable! 8

3 Application Example #3 Application Needs Multiuser Gaming from an application s point of view Receivers form a group Group identification scheme (scope?) We want to form groups dynamically Need API for telling OS we re interested in receiving/sending data for a group Normally not a many-to-many application! Tough upholding synchronism between clients Sensitive to cheating if all clients have access to thewholeworldstate Scales badly, The total amount of user input will at some point surpass the data needed per user to render a scene Though shared audio etc could benefit Server 9 Security: Authentication, data integrity, privacy and anonymity How to find information on existing groups? announcements, web-pages, predefined? Reliability 10 IP Multicast architecture IPv4 Multicast Addressing Two models: 1) ISM Internet Standard Multicast In IPv4 the G in the id is part of the normal host address space The multicast subnet is : Many-to-many Everyone (also non-groupmembers) can send to a group (*,G) A host need to communicate with gateway to start receiving packets for group (*,G) (IGMP ver 1 & 2) 2) SSM Source Specific Multicast Specific support for one-to-many A group can be identified via the pair (S,G) where S is a sender s host IP# Communication with gateway via IGMP ver /4 Ie, Addresses to Some of these addresses are statically allocated by IANA and some ranges have predefined use 12

4 IPv4 Multicast Addressing cont Excerpt from draft-ietf-mboned-rfc3171bis-01txt: (expires July 2004) Local Network Control Block Base Address (Reserved) [RFC1112,JBP] All Systems on this Subnet [RFC1112,JBP] All Routers on this Subnet [JBP] Unassigned [JBP] DVMRP Routers [RFC1075,JBP] OSPFIGP OSPFIGP All Routers [RFC2328,JXM1] OSPFIGP OSPFIGP Designated Routers [RFC2328,JXM1] ST Routers [RFC1190,KS14] ST Hosts [RFC1190,KS14] RIP2 Routers [RFC1723,GSM11] IGRP Routers [Farinacci] Mobile-Agents [Bill Simpson] DHCP Server / Relay Agent [RFC1884] All PIM Routers [Farinacci] RSVP-ENCAPSULATION [Braden] all-cbt-routers [Ballardie] designated-sbm [Baker] all-sbms [Baker] VRRP [Hinden] IPAllL1ISs [Przygienda] IPAllL2ISs [Przygienda] IPAllIntermediate Systems [Przygienda] IGMP [Deering] GLOBECAST-ID [Scannell] Internetwork Control Block VMTP Managers Group [RFC1045,DRC3] NTP Network Time Protocol [RFC1119,DLM1] SGI-Dogfight [AXC] Rwhod [SXD] VNP [DRC3] Artificial Horizons Aviator [BXF] NSS - Name Service Server [BXS2] AUDIONEWS - Audio News Multicast [MXF2] SUN NIS+ Information Service [CXM3] MTP Multicast Transport Protocol [SXA] IETF-1-LOW-AUDIO [SC3] IETF-1-AUDIO [SC3] IETF-1-VIDEO [SC3] IETF-2-LOW-AUDIO [SC3] IETF-2-AUDIO [SC3] IETF-2-VIDEO [SC3] MUSIC-SERVICE [Guido van Rossum] SEANET-TELEMETRY [Andrew Maffei] SEANET-IMAGE [Andrew Maffei] MLOADD [Braden] any private experiment [JBP] DVMRP on MOSPF [John Moy] Sending an multicast datagram For sending a datagram to a multicast group we use normal UDP where the destination address is set to the multicast address multicast address goes here! 8bits 8bits 8bits 8bits ver hlen DS Total Length Identifaction (16bits) flags Frag offset TTL Protocol (17) Header checksum Source IP address Destination IP address Source port address Destination port address UDP total length UDP Checksum Data 15 UDP encapsulation in IP datagram 16

5 IGMP Internet Group Management Protocol IGMP Message format (IGMP v 2) Just for group membership communication between a host and a router Has nothing to do with multicast routing Keeps an updated list of active group listeners for each connected LAN Simplistic network layer service No address management, no session management, no reliable data delivery, no security support, no synchronism IGMP ICMP IP ARP RARP 17 8 bits 8 bits 16 bits Type Message types: Maximum response time Group Address checksum Membership query (0x11) sent by router on If Group Address field is 0000 we have a general query Otherwise we have a special query Membership Report (0x16) sent by host when first time joining or when router queries Leave Report (0x17) sent by host when leaving a group (Not in IGMP ver 1) 18 IGMP Communication Example IGMP Pitfalls taken care of Host/Routercommunication What if a join group message gets lost? Join multicast group (*,G) Wait a random amount of time Host Membership report sent on groupaddr G And again Router Router allocates table space and sets a timer to y secs (default) Join Group messages should be sent at least twice In certain applications a quick tear-down of a group feed is highly prioritized Wait a random amount of time General membership query sent to Membership report sent on groupaddr G A general membership query is routinely sent every 125s (default) IGMP ver 2 introduced leave group When router sees this it sends a group specific membership query a couple of times to give other group members the chance to reestablish the groups existance Leave group (*,G) Leave group message sent on Several group-specific membership queries sent on Router must check if there are more hosts in group Sends 2 (default) G-S membership queries with 1s (default) apart 19 What if there are thousands of members in a group and a router sends a query message? Hosts must delay a random amount of time to see if another host answers 20

6 IGMP Host state diagram Link-level Multicast Each host has one of three states with respect to any multicast address Leave Group stop timer send leave if flag set Non-Member The flag indicates if host is the the last one sending the membership report Leave Group sendleaveifflagset Layer-2 networks can be very large with many nodes How does multicast work on eg, Ethernet? Ethernet uses MAC-addressing (6 bytes): xxxxxxx1 xxxxxxxx xxxxxxxx xyyyyyyy yyyyyyyy yyyyyyy Query Received restart timer if maximum response time < current timer Delaying Member Timer Expired send report set flag Join Group send report set flag start timer Query Received start timer Report Received stop timer clear flag Idle Member 21 All addresses with the low-order bit in the highorder byte set is an Ethernet multicast address IP-multicast addresses is mapped onto MAC addresses where x = (1) and y = 23 low-order bits of the IPv4 multicast address Hence frames may arrive at an interface which the host is not really interested in 22 Link-layer Multicast cont IGMP ver 3 (RFC3376) How does a typical Ethernet-network handle those frames? Dumb switches broadcast all multicast frames! More advanced switches may use a technique called IGMP snooping to filter out group join and leave messages Adds a new message type Version 3 Membership Report (0x22) sent by host when joining one or more source specific multicast groups 8bits 8bits 16 bits Type = 0x22 Reserved checksum Hosts and switches which are VLAN enabled may use the GRMP (GARP Multicast Registration Protocol) defined in IEEE 8021Q Reserved Number of Group Records [M] Group Record [1] Group Record [2] NOTE: We have free access to all IEEE standards within the University domain! Download from ieeexploreieeeorg 23 Group Record [M] 24

7 IGMP ver 3 cont More on Multicast Addresses Group Record Internal Format: 8bits 8bits 16 bits Multicast addresses are not that many Some of them we want to use locally Record Type Aux Data Len Number of Sources (N) Multicast Address The early experimental Mbone (Multimedia backbone) used TTL-scoping: (the time-to-live field in IP header) Source Address [1] Source Address [2] Source Address [N] AuxillaryData(maynotcurrentlybeused) Where Record Type tells if the (S,G) pairs are included or excluded from the interface s multicast filter Also the membership query message format has been updated to include a specific source list 25 1 local (traverses no router) 2 31 site (never leaves institution or university) 63 region 127 world Ie, routers was instructed to drop multicast packets depending on the TTL value 26 Administrative Scoping Scope restrictions TTL-scoping is not the preferred way while it complicates dynamic address allocation and is not suited for intersected scopes etc The range /8 is reserved for so called Administrative scopes Routers decide based on the group address whether to forward packets Organizations etc might use the reserved subrange Organization local scope: /14 and decide for themselves how these addresses are to be used A large organization might further want to divide this address space into ranges used by various sub-scopes Administrative scopes has some natural restrictions Must be connected Ie, there must exist a route between any two hosts part of a scope Must be convex Ie, the route between any two hosts must not cross the scope boundary Two intersecting scopes should have disjunct address ranges in case a route within one scope goes through the other Any scope boundary is also a boundary for a local scope using the range /

8 Adminstrative Scope Example Scoping and Relative Addresses Z 2 L 1 L 2 L3 L 4 L 5 Z 3 Z 4 In this example scopes Z 2 and Z 4 might use the same address range, but Z 1 and Z 3 need to use different ranges (and not the same as Z 2 /Z 4 ) L 6 Z 1 Z 1 : top level scope L i : local scopes Z 2 Z 4: sub-scopes 29 Given an administrative scope s address range the last 256 addresses are assigned by IANA Eg, for the IPv4 local scope we will have: Local Session Announcements will hence always use MADCAP etc 30 Multicast addresses on-demand Scope Discovery I have developed this new fancy multi-party multimedia application How to get suitable multicast addresses dynamically? How can we find out which scopes are available? Answer: RFC2776 Multicast-Scope Zone Announcement Protocol (MZAP): Answer: RFC2730 Multicast Address Dynamic Client Allocation Protocol Given a scope we can contact a MADCAP server and lease an address for a given time Leases may be renewed and can be actively released If we don t know server s host address we can issue a DISCOVER message over the scope s relative multicast address no 1 31 Routers on the border of a scope (=zone) runs the protocol Such a router is called ZBR (Zone Boundary Router) For every scope the ZBR is a border for it regularly transmits Zone Announcement Messages (ZAMs) to the local scope MZAP multicast address ( ) These messages are then flooded to all local scopes within the announced scope Announcements contain a Zone ID and address range, but also a string description of the zone Example: Department of Electrical Engineering liuse MZAP can detect misconfigurations 32

9 Reliable Multicast (RM) RM NACK Based Approach How to use the best-effort network-layer multicast to distribute data reliably? (Ie, everything arrives sooner or later in the correct order at all receivers) Still an active research topic! Three main solutions: 1) NACK-based: Receivers requests retransmission when a packet seems missing 2) ACK-based: Every packet is acknowledged by every receiver Sender resends on time-out 3) FEC-based: Redundancy is added in the form of a of a forward-error (or rather erasure)-correcting code See RFC2887 for a nice introduction! 33 Receivers sends back a NACK when a packet doesn t arrive in time Problem: NACK-implosion at sender Solution 1: Don t send a NACK immediately, but wait a random amount to see (in the data stream) if any other receiver has initiated a retransmission Solution 2: Build in NACK aggregation in routers Data sender NACK(3-4) Packet 4 lost here NACK(3) NACK(4) NACK(3) Packet 3 lost here NACK(3) NACK(3) 34 RM ACK Based Approach RM FEC Based Approach Every receiver acknowledges received content as in TCP For this to scale the receivers need to form an ACK-tree in which the ACK:s are aggregated (just as in the NACK-case described earlier) The ACK-tree could be the same as the multicast tree This however needs new functionality in routers Receivers dynamically form a tree separate from the multicast tree and send ACK:s to their parents only Parents might even react to late ACK:s and resend data to children themselves 35 In general we can add redundancy to k bits of data obtaining n bits of data Any received k bits will enable us to recover the k bits of original data Example using a Hamming (7,4) Incoming Data Block: Construct three parity blocks according to: ( =xor) p 1 =x 1 x 2 x 3 p 2 =x 2 x 3 x 4 p 3 =x 1 x 3 x 4 Outgoing: We can now afford to loose any three of the above blocks! Solve the parity relation to the right after putting in the known received bits (y i ) For very large codes (large n) we need some algebraic structure enabling fast reconstruction Hamming (7,4) is usually used as an example of an block-code capable of correcting one error (position unknown) y 1 y 2 y 3 y 5 =0 y 2 y 3 y 4 y 6 =0 y 1 y 3 y 4 y 7 =0 36

10 RM Layered Coding RM The rmt Working Group Multicasting in general has a problem with congestion control What should sender do (or even know) when a branch suffers from overload? Apart from various upstream solutions we could use several multicast streams, layers, and let receivers join depending on traffic situation Layer 3: A 1 B 1 C 1 D 1 A 2 B 2 C 2 D 2 A 1 B 1 C 1 D 1 A 2 B 2 C 2 D 2 A 1 B 1 C 1 D 1 A 2 B 2 C 2 D 2 Layer 2: C 3 B 3 D 3 A 3 C 4 B 4 D 4 A 4 C 3 B 3 D 3 A 3 Layer 1: D 5 A 5 C 5 B 5 D 6 A 6 C 6 B 6 D 7 A 7 C 7 B 7 (1) (2) Layering can be combined with FEC In the example above any two A i :s with different index need to be received to reconstruct A We see that a receiver listening to all layers might have all data (A,B,C,D) at time instant (1) while a layer 1 and 2 receiver will have to wait till (2) time 37 There is a working group Reliable Multicast Transport (rmt) which are developing protocols: Asynchronous Layered Coding (ALC) Several multicast streams in different rates to avoid congestion (Receiver joins the suitable ones) Uses FEC-techniques RFC is experimental NACK-oriented reliable multicast (NORM) Uses random back-off for NACK (truncated exponential distribution Uses FEC Is just a draft (expires May 2004) 38 RM The Ultimate Solution? IETF Working Groups From RFC3269: Reliable Multicast Transport (RMT) protocols can be constructed in a variety of ways, some of which will work better for certain situations than others It is believed that the requirements space for reliable multicast transport is sufficiently diverse that no one protocol can meet all the requirements [RFC2887, (Sally Floyd et al)] The working group RMT did some work on Generic Router Assist (GRA) where small packet handling programs with access to buffers etc could be inserted into routers by applications In this way a generic solution could be had for all future multicast scenarios GRA only made an appearance as some Internet-Drafts which seems all expired by now 39 idmr - Inter-Domain Multicast Routing IGMP ver 2, 3 Various multicast routing protocols mboned MBONE Deployment Zone Announcement Protocol (ZAP) malloc Multicast-Address Allocation Multicast Address Dynamic Client Allocation Protocol (MADCAP) rmt - Reliable Multicast Transport Draft for NACK-based protocol: NORM Experimental layered protocol: ALC 40

11 Summary Multicast can help in scaling up one-to-many and many-tomany applications Multicast addresses is part of the normal host address space A group is either identified with a multicast address or a multicast address plus source address (source-specific multicasting) Hosts use IGMP to communicate with router to join and leave groups Multicast addresses may live in a scope Scopes may intersect and nest Protocols for leasing multicast addresses exist Using multicast for reliable file transfer can be done, but there is no full IETF standard yet 41