* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Multicasting and Multicast Routing Protocols
Survey
Document related concepts
SIP extensions for the IP Multimedia Subsystem wikipedia , lookup
Point-to-Point Protocol over Ethernet wikipedia , lookup
Computer network wikipedia , lookup
Internet protocol suite wikipedia , lookup
Spanning Tree Protocol wikipedia , lookup
Serial digital interface wikipedia , lookup
Deep packet inspection wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Multiprotocol Label Switching wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
IEEE 802.1aq wikipedia , lookup
Transcript
Chapter 12: Multicasting and Multicast Routing Protocols 1 Objectives 12.1 Introduction 12.2 Multicast Addresses To compare and contrast unicasting, multicasting, and broadcasting communication To define multicast addressing space in IPv4 and show the division of the space into several blocks 12.3 IGMP To discuss IGMP v3 which is responsible for collecting group membership information in a network 2 Objectives 12.4 Multicast Routing To discuss the general idea behind multicast routing protocols 12.5 Routing Protocols To discuss multicast link state routing, distance vector routing and core-based protocol (CBT) in general and their implementation in the Internet Source-Based Tree Group-Based Tree MOSPF / DVMRP / PIM-DM and PIM-SM 12.6 MBONE To discuss multicast backbone (MBONE) that shows how to create a tunnel when the multicast messages need to pass through an area with no multicast routers 3 12.1 Introduction There are three communication mechanisms defined and classified as they related to the Internet Unicasting Multicasting Broadcasting 4 Unicast In unicast routing (Fig. 12.1), the router forwards the received packet through only one of its interfaces In unicast routing, each router in the domain has a table that defines a shortest path tree to possible destinations 5 Unicast Figure 12.1 Unicasting 6 Multicast In multicasting (Fig. 12.2), there is one source and a group of destinations The relationship is one to many The router may forward the received packet through several of its interfaces 7 Multicast Figure 12.2 Multicasting 8 Emulation of Multicasting with Unicasting As shown in Fig. 12.3 : Multicasting is more efficient than multiple unicasting Multicasting requires less bandwidth than multiple unicasting In multiple unicasting, some of the links must handle several copies In multiple unicasting, the packets are created by the source with a delay relative to each other If there are 1000 destinations, the delay between the first and the last packet may be unacceptable In multicasting, there is little delay because of multiple packet creation 9 Emulation of Multicasting with Unicasting Legend S1 Di Gi G1 G1 G1 a. Multicasting G1 Multicast router Unicast router Unicast destination Group member D1 S1 D2 D3 D4 b. Multiple unicasting Figure 12.3 Multicasting versus multiple unicasting 10 Application for Multicasting Access to Distributed Database Information Dissemination Dissemination of News Teleconferencing Distance Learning 11 Broadcasting In broadcasting communication, the relationship between the source and the destination is one to all The Internet does not explicitly support broadcasting because of Traffic Bandwidth 12 12.2 Multicast Addresses A multicast address is a destination address for a group of hosts that have joined a multicast group A packet that uses a multicast address as a destination can reach all members of the group unless there are some filtering restriction by the receiver 13 Multicast Addresses in IPv4 In classful addressing, multicast addresses occupied the only single block in class D In classless addressing, the same block has been used for this purpose In other words, the block assigned for multicasting is 224.0.0.0/4 This large block, or the multicast address space as sometimes it is referred to, is divided into some smaller ranges, as shown in Table 12.1, based on RFC 3171 14 15 Multicast Addresses Ranges Local Network Control Block The address in this block are used for protocol control traffic Not used for general multicast communication TTL = 1 Table 12.2 shows the assignment of some of these addresses 16 Multicast Addresses Ranges Internetwork Control Block Also used for protocol control traffic AD-HOC Block But the IP packets with one of these addresses as destination can be forwarded by router through the whole Internet This block was traditionally assigned to some applications that do not fit in the first or second block discussed above Stream Multicast Group Block Allocated for stream multimedia 17 Multicast Addresses Ranges SAP/SDP Block SSM Block Used for Session Announcement Protocol and Session Directory Protocol Used for Source Specific Multicasting GLOP Block This block defines a range of globally assigned addresses that can be used inside an autonomous system 18 Multicast Addresses Ranges Administratively Scope Block The addresses in this Administratively Scoped Block are used in a particular area of the Internet The packet whose address belongs to this range is not supposed to leave the area In other words, an address in this block is restricted to an organization 19 Selecting Multicast Address The selection of address depends on the type of application For Limited Group: The administrator can use the AS number (x,y) and choose an address between 239.x.y.0 and 239.x.y.255 that is not used by any other group as the multicast address for that particular group 20 Selecting Multicast Address For Larger Group: If the group is spread beyond an AS territory, the previous solution does not work The group needs to choose an address from the SSM block (232.0.0.0/8) There is no need to get permission to use an address in this block, because the packets in source-specific multicasting are routed based on the group and the source address; they are unique 21 Delivery of Multicast Packets at Data Link Layer Because the IP packet has a multicast IP address, the ARP protocol cannot find the corresponding MAC (physical) address to forward the packet at the data link layer What happens next depends on the following two cases: Network with Multicast Support Network with no Multicast Support 22 Network with Multicast Support Most LANs support physical multicast addressing Ethernet is one of them An MAC address is 48 bits long If the first 25 bits starts with 00000001 00000000 01011100 0, it is a physical multicast address for TCP/IP The remaining 23 bits can be used to define a group To convert an IP multicast address into an Ethernet address, the router extracts the least significant 23 bits of a multicast IP address and inserts them into a multicast Ethernet physical address (see Fig. 12.4) 23 Network with Multicast Support Figure 12.4 Mapping class D to Ethernet physical address 24 Network with no Multicast Support Most WANs do not support physical multicast addressing To send multicast packet through these network, a process called tunneling is used In tunneling, the multicast packet is encapsulated in a unicast packet and sent through the network (Fig. 12.5) 25 Network with no Multicast Support Figure 12.5 Tunneling 26 12.3 IGMP In multicast, each multicast router needs to know the list of groups to each interface It means that they need to collect information about members and share it with others The Internet Group Management Protocol (IGMP) is responsible for correcting and interpreting information about group members in a network It is one of the protocols designed at the IP layer for this purpose (Fig. 12.6) 27 12.3 IGMP Figure 12.6 Position of IGMP in the network layer 28 Group Management IGMP is not a multicasting routing protocol IGMP is a protocol that manages group membership The IGMP protocol gives the multicast routers information about the membership status of hosts (routers) connected to the network It helps a multicast router create and update a list of loyal members related to each router interface 29 Group Management IGMP has gone through three versions. V1 and V2 provide any-source multicast (ASM), which means that the group members receive a multicast message no matter where it comes from V3 provides what is called source-specific multicast (SSM), which means that the recipient can choose to receive multicast messages coming from a list of predefined sources Only V3 is discussed in this section 30 IGMP Messages Two types of message of IGMPv3 Member ship query message Membership report message The former can be used in three different formats Figure 12.7 IGMP messages 31 Membership query message format A membership query message is sent by a route to find active group members in the network Figure 12.8 Membership query message format 32 Membership query message format Type Maximum Response Code The value is 0x11 for a membership query message It is used to define the response time of a recipient of the query Checksum Group Address This field is set to 0 in a general query message; it is set to IP multicast being queried when sending a groupspecific or group-and-source-specific query message 33 Membership query message format Resv S Reserved for the future Suppress flag: when this field is set to 1, it means that the receivers of the query message should suppress the normal timer updates QRV Querier’s robustness variable: it is used to monitor the robustness in the network 34 Membership query message format QQIC Querier’s query interval code: it is used to calculate the querier’s query interval (QQI), as we will show shortly Number of sources (N) This field defines the number of unicast source addresses attached to the query The value of this field is zero for the general query and the group-specific query; and non-zero in the group-and-sourcespecific query Source Addresses These fields list the N source address, the origin of multicast messages 35 Membership query message format Three formats of query messages (Fig. 12.9) General query message Group specific message The querier router probes each neighbor to report the whole list of its group membership. Probes each neighbor to report if it is still interested in a specific multicast group. The multicast group address is defined as x.y.z.t in the group address field of the query. Group-and-source-specific query message Probes each neighbor to report if it is still in a specific multicast group, x.y.z.t, coming from any of the N sources whose unicast addresses are defined in this packet 36 Membership query message format Figure 12.9 Three forms of query messages 37 Membership report message format Version 3 Membership Reports are sent by IP systems to report (to neighboring routers) the current multicast reception state, or changes in the multicast reception state, of their interfaces Reports have the following format: (Fig. 12.10) 38 Membership report message format Figure 12.10 Membership report message format 39 Membership report message format Type 0x22 defines this type of the message Checksum Number of Group Records (M) This field defines the number of group records carried by the packet There can be zero or more group records of variable length 40 Membership report message format Each group record includes the following information related to the responder’s membership in a single multicast group Record Type Six record types 41 Membership report message format Aux Data Len This field defines the length of the auxiliary data included in each group record It may contain zero, to indicate the absence of any auxiliary data Number of Sources (N) The Number of Sources (N) field specifies how many source addresses are present in this Group Record 42 Membership report message format Source Addresses These fields list the source addresses Aux Data This field contains any auxiliary data that may be included in the report message The IGMP has not yet defined any auxiliary data, but it may be added to the protocol in the future 43 IGMP Protocol Applied to Host How a host implements IGMP is discussed in this section Hosts need to do the management of groups Each process (running application programs) associated with each socket How to maintain the socket states? Several interfaces are used How to maintain interface states? Can interface states be simplified? 44 Socket state Each process has a record for each multicast group The record shows one of the two modes: Include mode It lists the unicast source addresses from which the socket accepts the group messages Exclude mode It lists the unicast source addresses that the socket will not accept the group messages 45 Example 12.4 Figure 12.11 shows a host with three processes: S1, S2, and S3. The first process has only one record; the second and the third processes each have two records. We have used lowercase alphabet to show the source address. Figure 12.11 Socket state 46 Interface State If a record with the same multicast group has many lists of resources, the following two rules need to be followed to combine the list of resources Each time there is a change in any socket record, the interface state will change 47 Interface State Rule 1: If any of the records to be combined has the exclusive filter mode, then the resulting interface record will have the exclusive filter mode and the list of the source addresses is made as shown below: Apply the set intersection operation on all the address lists with exclusive filters Apply the set difference operation on the result of part a and all the address lists with inclusive filters 48 Interface State Rule 2: If all the records to be combined have the inclusive filter mode, Then the resulting interface record will have the inclusive filter mode And the list of the source addresses is found by applying the set union operations on all the address lists 49 Example 12.5 We use the two rules described above to create the interface state for the host in Example 12.4. First we found the list of source address for each multicast group. a. Multicast group 226.14.5.2 has two exclude lists and one include list. The result is an exclude list as calculated below. b. Multicast group: 228.24.21.4 has two include lists. The result is an include list as calculated below. We use the plus sign for the union operation. Figure 12.12 shows the interface state. 50 Example 12.5 Figure 12.12 Interface state 51 Sending Change-State Reports If there is any change in the interface state, the host needs to immediately send a membership report message for that group, using the appropriate group record(s) As Figure 12.13 shows, four different cases may occur in the change, based on the oldstate filter and the new state filter Only the group records are shown, not the whole report 52 Figure 12.13 Sending change state reports 53 Receiving Query Reports When a host receives a query, it does not respond immediately It delays the response by a random amount of time calculated from the value of the Max Resp Code field The action of the host depends on the type of the query received as shown below: 54 Receiving Query Reports 1. If the received query is a general query, the host reset the interface timer (see Fig. 12.12) to the calculated delay value This means if there is any previous delayed response, it is cancelled 2. If the received query is a group-specific query, then the corresponding group time (see Fig. 12.12) is reset to the shorter value of the remaining time for the timer or the calculated delay If a timer is not running, its remaining time is considered to be infinity 55 Receiving Query Reports 3. If the received query is a group-and-source-specific query, then the action is the same as the previous case In addition, the list of source is recorded for the delayed response 56 Timer Expiration Membership report messages are sent by a host when a timer expires However, the types and number of group records contained in the message depends on the timer 57 Timer Expiration 1. General query received timer expires: Host sends a membership report contains one CurrentState-Record for each group in the interface state If all records to be sent do not fit in one report They can be split into several reports 2. Group-specific query received timer expires: Host sends a membership report contains only one Current-State-Record for that particular group if it is still active 58 Timer Expiration 3. Group-and-source-specific query received timer expires: Same as 2. The type of the single record contained in the report and source list depends on the filter mode of the group Include The record type is Mode_Is_Include (type 1) and the source list is (A . B) A: group source list / B: received source list .(dot sign) means the intersection operation Exclude The record type is Mode_Is_Exclude(type 2) and the source list is (B - A) -(minus sign) means the difference operation 59 Report Suppression In IGMPv2, If a host receives a report sent by another host, it cancelled the corresponding timer in its interface state, which means suppressing the pending report In IGMPv3, This mechanism has been removed from the protocol for some practical reasons described in RFC 3376 60 IGMP Protocol Applied to Router How a router implements IGMP is discussed in this section A querier (multicast router) in IGMPv3 needs to handle 6 types of group records contained in a membership report Multiple interfaces are used How to maintain their states? 61 Querier’s State The multicast router needs to maintain the state information for each multicast group associated with each network interface Figure 12.14 shows an example of a multicast router and its two state tables 62 Querier’s State Figure 12.14 Router States 63 Action Taken on Membership Report Reception A multicast router sends out queries and receives reports When a multicast router receives the reports, it needs to take some actions to change its state Reception of Report in Response to General Query Reception of Reports in Response to Other Queries 64 Reception of Report in Response to General Query When a router sends a general query, it expects to receive a report or reports This types of a report normally contains Current-StateRecord(types 1 and 2) When such a report arrives, the router changes its state, as shown in Figure 12.15 65 Reception of Report in Response to General Query Figure 12.15 Change of state related to general query report 66 Reception of Reports in Response to Other Queries When a router sends a group-specific or groupand-source-specific query, it expects to receive a report or reports This types of a report normally contains FilterState_Mode_Change_Record (types 3 and 4) or Source_List_Change_Record (types 5 and 6) When such a report arrives, the router changes its state, as shown in Figure 12.16 67 Figure 12.16 Change of state related to other report types 68 Role of IGMP in Forwarding In previous versions of IGMP, the forwarding recommendation was based only on the destination multicast address of a packet In IGMPv3, the recommendation is based on both destination address and the source address. RFC 3376 mentions 6 different recommendations that IGMPv3 software can give to the IP multicast router to forward or not to forward a packet with respect to an interface 69 Role of IGMP in Forwarding If the multicast destination address does not exist in the router state, the recommendation is definitely not to forward the packet 70 Variables and Timers Maximum Response Time The maximum response time is the maximum time allowed before sending a report in response to a query It is calculated from the value of the 8-bit Max Resp Code field in the query The calculation of the maximum response time is shown in Fig. 12.17 71 Variables and Timers RFC 3376: The Max Response Time in Query messages has an exponential range, changing the maximum from 25.5 seconds to about 53 minutes, for use on links with huge numbers of systems Figure 12.17 Calculation of maximum response time 72 Variables and Timers Querier’s Robustness Variable (QRV) It dictates how many times a response message to a query should be sent The number of times a host should send a response to a query is QRV -1 Default value is 2 73 Variables and Timers Qurier’s Query Interval This is the interval between the general queries Default value is 125 This value can be changed by an administrator to control the traffic on the network Other Variables and Timers See RFC 3376 74 IGMP Encapsulation The IGMP message is encapsulated in an IP datagram with the value of protocol field set to 2 and the TTL field set to 1 The destination IP address of datagram, however, depends on the type of the message, as shown in Table 12.5 75 IGMP Compatibility with Older Versions To be compatible with V1 and V2, IGMPv3 software is designed to accept messages defined in V1 and V2. Table 12.6 shows the value of type fields and the type of messages in V1 and V2 76 12.4 Multicast Routing Objectives To discuss the idea of optimal routing, common in all multicast protocols Optimal Routing: Shortest Path Trees To discuss the general idea behind multicast routing protocols Source-Based Tree Group-Based Tree 77 Optimal Routing: Shortest Path Trees The process of optimal inter-domain routing eventually results in the finding of the shortest path tree However, the number of trees and the formation of the trees in unicast and multicast routing are different 78 Unicast routing In unicast routing, each router in the domain has a table that defines a shortest path tree to possible destinations Fig. 12.18 shows the situation 79 Figure 12.18 Shortest path tree in multicast routing 80 Multicast routing A multicast packet may have destinations in more than one network Forwarding of a single packet to members of a group requires a shortest path tree N group N trees (complexity is high) Two approaches have been used to solve the problem: Source-based trees Group-shared trees 81 Source-based trees In a source-based tree approach, the combination of source and group determines the tree If there are N groups and M sources in the system, there can be a maximum of N*M different trees In the source-based tree approach, each router needs to have one shortest path tree for each group See Fig. 12.19 82 Source-based trees Figure 12.19 Source-based tree approach 83 Group-shared trees In the group-shared tree approach, the group determines the tree If there are N groups in the system, there is a maximum of N trees In the group-shared tree approach, only the core router, which has a shortest path tree for each group, is involved in multicasting See Fig. 12.20 84 Group-shared trees Figure 12.20 Group-shared tree approach 85 12.5 Routing Protocols During the last few decades, several multicast routing protocols have emerged Some of these protocols are extensions of unicast routing protocols; some are totally new Figure 12.21 shows the taxonomy of these protocols 86 Multicast routing protocols Figure 12.21 Taxonomy of common multicast protocols 87 DVMRP The Distance Vector Multicast Routing Protocol (DVMRP) must achieve the following It must prevent the formation of loops It must prevent duplications It must provide for dynamic membership 88 DVMRP Reverse Path Forwarding (RPF): In reverse path forwarding (RPF), the router forwards only the packets that have traveled the shortest path from the source to the router; all other copies are discarded RPF prevents the formation of loops in the flooding process 89 DVMRP Figure 12.22 RPF 90 DVMRP Reverse Path Broadcasting (RPB) Net3 has two parents: routers R2 and R4 For each source, the router sends the packet only out of those interfaces for which it is the designated parent. This policy is called reverse path broadcasting To eliminate duplication, the most common policy is to select the router with the shortest path to the source as the designed parent router 91 DVMRP RPF versus RPB RPB creates a shortest path broadcast tree from the source to each destination. It guarantees that each destination receives one and only one copy of the packet 92 DVMRP Reverse Path Multicasting (RPM) Pruning: The router sends a prune message to the upstream can stop sending multicast messages for this group through that interface Grafting: The graft message forces the upstream router to resume sending the multicast messages RPM adds pruning and grafting to RPB to create a multicast shortest path tree that supports dynamic membership changes 93 DVMRP RPF, RPB, and RPM 94 MOSPF The Multicast Open Shortest Path First (MOSPF) is an extension of the OSPF protocol that uses multicast link state routing to create source-based trees The tree is a least-cost tree (using a metric) The tree is made all at once 95 CBT Shared-group tree with rendezvous router The Core-Based Tree (CBT) protocol is a group-shared protocol that uses a core as the root of the tree The autonomous system is divided into regions and a core (center router) is chosen for each region 96 CBT Procedure of Transmission in CBT The source, which may or may not be part of the tree, encapsulates the multicast packet inside a unicast packet with the unicast destination address of the core and sends it to the core This part of delivery is done using a unicast address; the only recipient is the core router The core decapsulates the unicast packet and forwards it to all “interested” interfaces Each router that receives the multicast packet, in turn, forwards it to all interested interfaces 97 CBT Sending a multicast packet to the rendezvous router 98 CBT In CBT, the source sends the multicast packet (encapsulated in a unicast packet) to the core router The core router decapsulates the packet and forwards it to all interested interfaces . 99 PIM Protocol Independent Multicast (PIM) is the name given to two independent multicast routing protocols: Protocol Independent Multicast, Dense Mode (PIM-DM) Protocol Independent Multicast, Sparse Mode (PIM-SM) 100 PIM PIM-DM PIM-DM is used in a dense multicast environment, such as a LAN environment. PIM-DM uses RPF and prunning/grafting strategies to handle multicasting. However, it is independent from the underlying unicast protocol. PIM-SM PIM-SM is used in a sparse multicast environment such as a WAN. PIM-SM is a group shared routing should notify protocol that has a rendezvous point (RP) as the source of the tree. PIM-SM is similar to CBT but uses a simpler procedure. 101 12.6 MBONE MBONE The multicast routers may not be connected directly, but they are connected logically Only the routers enclosed in the shaded circles are capable of multicasting With tunneling, these multicast routers are not isolated 102 islands MBONE Procedure of Transmission in MBONE A logical tunnel is established by encapsulating the multicast packet inside a unicast packet. The multicast packet becomes the data of the unicast packet The intermediate (non-multicast) routers route the packet as unicast routers and deliver the packet from one island to another It’s as if the unicast routers do not exist and the two multicast routers are neighbors. DVMRP supports MBNOE 103 MBONE MBONE 104