IP Multicasting

IP Multicasting configuration concerns the creation of an efficient flooding structure for streaming. Streams flow from a source towards a set of multiple receivers, which are supposed to register to the network for the required service. In IP Multicasting Routing takes the form of creating a “spanning tree”, from source to leaves, for the stream-flooding. A multicast destination address represents a service rather than a real destination. Multicast IP techniques deal with the discovering of the sources, the registration of the receivers to the service (the Group) and with the task of building up a loop free and shortest path tree (SPT) from sources to receivers.

The main techniques and concepts used with Multicast are:

Configuration of REGISTRATION techniques for Receivers and, if required, Sources, including:

• Registering end-receivers to a Group: IGMPv1, v2 and v3 (IGMP is IP protocol nr. 2);
• Registering (or recognition) of Sources: implicit like in Dense Mode; performed by First Hop towards the RP like in classical PIM Sparse Mode; registered and shared by MSDP peers (like in AnycastRP’s or with peers of different neighboring domains) or explicit in SSM and IGMPv3;
• Facilitating the registration of non-enabled devices or global segments (see static interface joining in non-Mcast environments);
• Efficiency mechanism (see Layer2 tools like IGMP snooping and CGMP);

Mcast ROUTING Techniques:

• Building up a loop free path: controlling the Reverse Forwarding Path, which is based on analyzing the source address of a stream against the unicast routing table (that can tell the INCOMING direction is best way and block possible temporary loops). Note that the Unicast RFP rule can be altered by configuring static ‘mroutes’ or dynamic DVMRP announcements, which overrule the unicast table;
• Building an efficient distribution tree throughout all routers running PIM. In classical Sparse Mode a shared tree is created by defining (or electing) a central Rendezvous Point (RP), while it is later optimized to the best possible source tree: the RP joins back the source tree from RP to Source (the source registers to the RP via the first hop router which unicast the stream to the RP, allowing the RP to join the source tree back to the source) and from the RP, the initially established shared tree is progressively converted to source tree;
• Building a shared distribution tree, which allows any-to-any communication [and simplifies the PIM SM], like with Bidirectional PIM SM method (reducing CPU and Memory usage, by always streaming towards the RP at cost at more bandwidth – only shared tree are supported);
• Simplifying PIM on Stub routers with a Multicast Stub technique, which uses a simple IGMP helper statement on the stub router and filtering PIM’s query communication, from the hub router to the stub;
• Relying on implicit Source Trees with SSM (the Source is known by IGMPv3 joins, the source tree is automatically backward generated – only Source Tree possible);

Placing and electing the Rendezvous Point in all PIM environments (except in DM and SSM):

• Statically configuring it on all systems;
• Dynamic electing it (with AutoRP or PIMv2 Bootstrap);
• Providing a fault redundancy solution using the AnycastRP technique, based on MSDP and static RP configuration of a logical RP;

Load Splitting techniques. (due to the RFP rule only one output interface would be used):

• By pure load splitting over parallel equal multicast paths (Load Splitting alters the RFP rule and allows it. Note also that UDP used in IP Multicasting does not perform re-ordering);
• By load splitting using GRE tunneling over multiple unicast paths (which are, as usual in unicast, load balanced);

Mcast traffic boundary:

• By using Multicast Boundary lists, which are access-lists only applied to Mcast traffic, that can provide a border in the network(s) to different flooding domains;
• By limiting the scope of the traffic limiting the TTL threshold of the allowed traffic;

QoS specific mechanism:

• Using Multicast Rate Limitation and storm limitation: limiting the rate of Mcast for a Group to a max rate (on a router) or on a per port basis (on a switch);

Layer2 enhancements:

• Multicast may be not natively supported on Frame Relay (Multipoint Interfaces if no broadcast keyword is admitted). Using PIM in NBMA mode Mcast traffic is unicasted at layer 2 in the multipoint NMBA cloud;
• Using CGMP between routers and Layer 2 switches (or IGMP Snooping on the switches), for limiting flooding to only IGMP registered hosts in the layer 2 access network (*);
• Using IGMP snooping on newer catalyst switches (on by default);

Emulating Multicast on non-Multicast native environments:

• Running Multicast over unicast links using GRE tunnels on edges;
• Facilitating hosts which do not run IGMP to have Mcast, performing Joining of an Interface to a group (Static and Join);
• Converting Multicast to Broadcast by using UDP MCast helper address, ip directed broadcast and Dense Mode;

 

Multicast behavior on Layer 2

Multicast streaming is native on layer 2 bridged networks and floods in a “shared tree” fashion, having the 802.1d/w root bridge as the root of a layer 2 spanning tree: Multicasting on Ethernet implicates switching native flooding (if a switch has a multicast layer 2 destination, it floods the frames on “all” ports apart the source port). Loops are impossible due to the implications of 802.1d/s/w spanning tree algorithms. IP Multicast addresses (the so called Class D addresses) are always mapped to Layer 2 Multicast addresses (no specific mapping configuration is needed, because the lowest 23 bits of the IP Group address are used to build the MAC Mcast address. Note some ambiguity in mapping is possible).

At the layer 2 multicast traffic is normally flooded also on ports where no listeners (IGMP joiners) are present. Anyway some proprietary techniques are available to artificially limit the flooding for interfaces where receivers have been heard on:

– IGMP snooping, for instance, requires the switch to “learn” the MAC address and port location of IGMP joiners by snooping the IGMP (IP) communication. The switch does not perform any active registration task though. When a (layer2) Multicast streaming comes in, the switch will cut all paths where no IGMP join has been snooped on. On Cisco implementation PIM is snooped as well;

– A Cisco proprietary protocol available for the same purpose is CGMP (typical of low end switches, which have not the capability to snoop IP packets): in this case the layer 2 device is told by a GCMP server router which device (MAC address) has performed a join. The switch then turns the related switched port on for Multicasting in that segment;

 

Theory: IP Multicast Addresses

# IP Multicast Addresses

224.0.0.0/24 Reserved for Local Link

224.0.1.0/24 Global Scope

232.0.0.0/8 Source specific (used by IGMPv3, to request traffic from specific sources)

233.0.0.0/8 GLOP (Addresses Mapped using the assigned AS number)

239.0.0.0/8 Limited Scope

 

Note for GLOP calculation:

1) Convert AS in Hexadecimal: AS3261 -> (16*203+13) = (16*(16*12+11)+13)

= 0*POWER(16,3)+12*(POWER(16,2))+11*POWER(16,1)+13 =

= 0x0CAD

2) Derive the 2nd and 3rd octect: 0x0C ={0000 1100}=12; 0xAD ={1011 1101}=189 ===> 233.12.189.0/24

 

Theory: IP to Ethernet Multicast Address Mapping

In order to AVOID using the ARP protocol for IP to MAC address translation on local segment (where the hosts reside) a STATIC MAPPING has been defined. An IP Multicast “host group” address is mapped to an Ethernet multicast address by placing the low-order 23-bits of the IP address into the low-order 23 bits of Ethernet multicast address 01-00-5E-00-00-00 (in hex form). Because there are 28 significant bits in an IP host group address, more than one host group address may map to the same Ethernet multicast address.

Example: 224.123.232.12

<-discard-><———take———->

xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx

11100000.01111011.11101000.00001100

Being the basis: 01-00-5E-00-00-00

xxxx xxxx-xxxx xxxx-xxxx xxxx-xxxx xxxx-xxxx xxxx-xxxx xxxx

0000 0001-0000 0000-0111 1110-0000 0000-0000 0000-0000 0000

Therefore:

——————————-111 1011-1110 1000-0000 1100

0000 0001-0000 0000-0111 1110-0—————————-

0000 0001-0000 0000-0111 1110-0111 1011-1110 1000-0000 1100

0 1 -0 0 -5 E -5 B -E 8 -0 A

01-00-5E-5B-E8-0A

NOTE: because the transmission of bytes in Ethernet is reverse, a Layer-2 Multicast packet is identified by the LEAST SIGNIFICANT bit of the first byte (first byte being thus: 0000 0001).

NOTE: because only 23 bits are used from the multicast IP and not 28, there is a potential ambiguity into the translation. the two multicast IP addresses are translated to the same MAC.

224.123.232.12 11100000.01111011.11101000.00001100

234.251.232.12 11101010.11111011.11101000.00001100

 

Theory: IGMP

The Internet Group Management Protocol (IGMP) is used by IP hosts to report their host group memberships to any immediately-neighboring multicast routers. IGMP messages are directly encapsulated in IP datagrams, with an IP protocol number of 2.

IGMPv1

This is the datagram format for IGMP version 1:

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Version| Type | Unused | Checksum |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Group Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In IGMP version 1 two types of IGMP message of concern to hosts are defined:

– Host Membership Query (Type=1, from multicast routers to hosts)

– Host Membership Report (Type=2, from hosts to multicast routers).

Multicast routers send Host Membership Query messages (hereinafter called “Queries”) to discover which host groups have at least one member on their attached local networks(*). Queries are addressed to the all-hosts group (address 224.0.0.1), and carry an IP time-to-live of 1. In IGMPv1 there is no explicit election of / or Querier state. This is instead defined in IGMPv2.

(*) Because IGMP spreads always the LAN segment and because multicast router do not keep a list of the hosts which joined the group, but only if AT LEAST ONE host has joined the group, regardless of who did, the joining process is equivalent to (LAN) segments joining a group. For a Router this can be traduced to WHICH INTERFACE HAS JOINED A GROUP (see the “show ip igmp groups” output command: the joiners are summarised to the interfaces joining a group). Actually this is true for Routers, in RFC compliant mode, but, in the Cisco case, not for Switches. Using IGMP spoofing or CGMP a Catalyst switch knows which of its directly attached hosts (MACs) are joining a group and which not, therefore forwarding received multicast to only the necessary hosts.

Hosts respond to a Query by generating Host Membership Reports (hereinafter called Reports), reporting each host group to which they belong on the network interface from which the Query was received. When a host joins a new group, it should immediately transmit a Report for that group, rather than waiting for a Query, in case it is the first member of that group on the network. A Report sent for JOINING a group is sent to the all-router group (224.0.0.2).

Queries are sent periodically (by default this is every 60 seconds) to refresh router’s knowledge of memberships present on a particular network. A [Group Membership Interval] timer is used by routers to define expiration of received Reports. Repeated Reports refresh the timer. If no Reports are received for a particular group after the Group Membership Interval has expired, the routers assume that that group has no local members and that they need not forward remotely-originated multicasts for that group onto the local network. In order to avoid an “implosion” of concurrent Reports (all answers at once) and to reduce the total number of Reports transmitted, two techniques are used:

– Report Delay Timer (random): When a host receives a Query, rather than sending Reports immediately, it starts a report delay timer for each of its group memberships on the network interface of the incoming Query. Each timer is set to a different, randomly-chosen value between zero and D seconds. When a timer expires, a Report is generated for the corresponding host group. Consequently Reports are spread out over a D second interval instead of all occurring at once. In IGMPv1 the D value is statically defined as 10 seconds. This is done in IGMPv2 with the Max_Resp_Time parameter in the IGMP packet (with default 10 seconds);

– Report sent to the Multicast Group Address. A Report is sent with an IP destination address equal to the host group address being reported, and with an IP time-to-live of 1, so that other members of the same group on the same network can overhear the Report. If a host hears a Report for a group to which it belongs on that network, the host STOPS its own timer for that group and does not generate a Report for that group. Thus, in the normal case, only one Report will be generated for each group present on the network, by the member host whose delay timer expires first.

IGMPv2

IGMPv2 had been introduced by RFC2236 in order to allow group membership termination to be more quickly reported to the routing protocol, which is important for high-bandwidth multicast groups and/or subnets with highly volatile group membership. In IGMPv2 also the Max_Resp_Time (for the random timer used by hosts) is defined as a parameter in the packet and router’s Querier Election is explicitly performed (lower IP).

Datagram format for IGMP version 2:

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Max Resp Time | Checksum |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Group Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note:

Type(2) = Type(1)+Version(1)

Max_Resp_Time(2) = Unused(1)

In IGMP version 2 three types of IGMP message of concern to hosts are defined::

• Leave Group (0x17 = 0x16 = equivalent to type 7, IGMP version 1)
• Membership Query (0x11 = 00010001, equivalent to type 1, IGMP version 1)
• Membership Report (Version 1, 0x12 = equivalent to type 2, IGMP version 1) (Version 2, 0x16 = equivalent to type 6, IGMP version 1).The additional type of Report message assures backwards-compatibility with IGMPv1.

A multicast router keeps a list of multicast group memberships for each attached network, and a timer for each membership. “Multicast group memberships” means the presence of at least ONE member in a given multicast group on a given attached network, NOT a list of all of the members. With respect to each of its attached networks, a multicast router may assume one of two roles: QUERIER or Non-Querier. There is normally only one Querier per physical network. All multicast routers start up as a Querier on each attached network. If a multicast router hears a Query message from a router with a LOWER IP address, it MUST become a Non-Querier on that network. If a Non-Querier verifies no Query message has been sent for a max time (Queries are like IGMPv1 sent periodically), it resumes the Querier role. Like in IGMPv1 hosts wait the expiration a Report Delay Timer (random) before sending the Report. In IGMPv2 this timer is explicitly defined in the range of (0, Max Response Time], with Max_Response_Time introduced as a field in the IGMPv2 packet.

When a router receives a Report, it adds the group being reported to the list of given multicast group memberships on the network on which it received the Report and sets the timer for the membership to the [Group Membership Interval]. Repeated Reports refresh the timer. If no Reports are received for a given particular group before this timer has expired, the router assumes that the group has no local members and that it need not forward remotely-originated multicasts for that group onto the attached network.

When a host LEAVES a multicast group it (normally) sends a Leave Group message to the “all-routers” multicast group (224.0.0.2). If the host heard a Report to a previous Query for that group from another host, it MAY send nothing as there must be another member on the subnet. This is an optimization to reduce traffic. When a Querier receives a Leave Group message for a group that has group members on the reception interface, it sends a special Group-Specific Query to the group being left. These Group-Specific Queries have their Max Response time set to [Last Member Query Interval] and instead of the 224.0.0.1 the GROUP multicast address is used. If no Reports are received after the response time of the last query expires, the routers assume that the group has no local members anymore.

IGMPv3

IGMP Version 3 (IGMPv3) adds support for “source filtering,” which enables a multicast receiver host to signal to a router which groups it wants to receive multicast traffic from, and from which source(s) this traffic is expected. This membership information enables Cisco IOS software to forward traffic only from those sources from which receivers requested the traffic.

IGMPv3 supports applications that explicitly signal sources from which they want to receive traffic. With IGMPv3, receivers signal membership to a multicast host group in the following two modes:

• INCLUDE mode — In this mode, the receiver announces membership to a host group and provides a list of IP sources (the INCLUDE list) from which it wants to receive traffic.
• EXCLUDE mode — In this mode, the receiver announces membership to a host group and provides a list of IP addresses (the EXCLUDE list) from which it does not want to receive traffic. This indicates that the host wants to receive traffic only from other sources whose IP addresses are not listed in the EXCLUDE list. To receive traffic from all sources, like in the case of the Internet Standard Multicast (ISM) service model, a host expresses EXCLUDE mode membership with an empty EXCLUDE list.

IGMPv3 is the industry-designated standard protocol for hosts to signal channel subscriptions in Source Specific Multicast (SSM). SSM with support for IGMPv3 was introduced in 12.1(5)T. For SSM to rely on IGMPv3, IGMPv3 must be available in last hop routers and host operating system network stacks, and be used by the applications running on those hosts.

In SSM deployment cases where IGMPv3 cannot be used because it is not supported by the receiver host or the receiver applications, there are three Cisco-developed transition solutions that enable the immediate deployment of SSM services:

• URL Rendezvous Directory (URD)
• IGMP Version 3 lite (IGMP v3lite).
• Source Specific Multicast (SSM) Mapping feature

URL Rendezvous Directory (URD)

URD is a Cisco-developed transitional solution that allows existing IP multicast receiver applications to be used with SSM without the need to modify the application and change or add any software on the receiver host running the application. URD is a content provider solution in which the receiver applications can be started or controlled through a web browser.

URD operates by passing a special URL from the web browser to the last hop router. This URL is called a URD intercept URL. A URD intercept URL is encoded with the (S, G) channel subscription and has a format that allows the last hop router to easily intercept it.

As soon as the last hop router intercepts both an (S, G) channel subscription encoded in a URD intercept URL and sees an IGMP group membership report for the same multicast group from the receiver application, the last hop router will use PIM-SSM to join toward the (S, G) channel as long as the application maintains the membership for the multicast group G. The URD intercept URL is thus only needed initially to provide the last hop router with the address of the source(s) to join to.

IGMP v3lite

IGMP v3lite is a Cisco-developed transitional solution for application developers to immediately start programming SSM applications. It allows you to write and run SSM applications on hosts that do not yet support IGMPv3 in their operating system kernel.

Applications must be compiled with the Host Side IGMP Library (HSIL) for IGMP v3lite. This software provides applications with a subset of the IGMPv3 applications programming interface (API) that is required to write SSM applications. HSIL was developed for Cisco by Talarian and is available at: http://www.talarianmulticast.com/cgi-bin/igmpdownld

One part of the HSIL is a client library linked to the SSM application. It provides the SSM subset of the IGMPv3 API to the SSM application. If possible, the library checks whether the operating system kernel supports IGMPv3. If it does, then the API calls simply are passed through to the kernel. If the kernel does not support IGMPv3, then the library uses the IGMP v3lite mechanism.

IGMP v3lite is supported by Cisco only through the API provided by the HSIL, not as a function of the router independent of the HSIL. By default, IGMP v3lite is disabled. When IGMP v3lite is configured through the “ip igmp v3lite” command on an interface, it will be active only for IP multicast addresses in the SSM range.

Source Specific Multicast (SSM) Mapping feature

SSM mapping supports SSM transition in cases where neither URD nor IGMP v3lite is available, or when supporting SSM on the end system is impossible or unwanted due to administrative or technical reasons. SSM mapping enables you to leverage SSM for video delivery to legacy set-top boxes (STBs) that do not support IGMPv3 or for applications that do not take advantage of the IGMPv3 host stack.

In a typical STB deployment, each TV channel uses one separate IP multicast group and has one active server host sending the TV channel. A single server may of course send multiple TV channels, but each to a different group. In this network environment, if a router receives an IGMPv1 or IGMPv2 membership report for a particular group G, the report implicitly addresses the well-known TV server for the TV channel associated with the multicast group.

When the router receives an IGMPv1 or IGMPv2 membership report for a group G, the router uses SSM mapping to determine one or more source IP addresses for the group G. SSM mapping then translates the membership report as an IGMPv3 report INCLUDE (G, [S1, G], [S2, G]…[Sn, G] and continues as if it had received an IGMPv3 report.

The router then sends out PIM joins toward (S1, G) to (Sn, G) and continues to be joined to these groups as long as it continues to receive the IGMPv1 or IGMPv2 membership reports and as long as the SSM mapping for the group remains the same. SSM mapping, thus, enables you to leverage SSM for video delivery to legacy STBs that do not support IGMPv3 or for applications that do not take advantage of the IGMPv3 host stack.

As is the case for the other SSM transition solutions (URD and IGMP v3lite), SSM mapping only needs to be configured on the last hop router connected to receivers. No support is needed on any other routers in the network. SSM mapping, in addition, is fully compatible with IGMPv3, IGMP v3lite, and URD.

SSM mapping enables the last hop router to determine the source addresses either by a statically configured table on the router or by consulting a DNS server. When the statically configured table is changed, or when the DNS mapping changes, the router will leave the current sources associated with the joined groups.

Static SSM Mapping

SSM static mapping enables you to configure the last hop router to use a static map to determine the sources sending to groups. Static SSM mapping requires that you configure access lists (ACLs) to define group ranges. The groups permitted by those ACLs then can be mapped to sources using the ip igmp static ssm-map command.

You can configure static SSM mapping in smaller networks when a DNS is not needed or to locally override DNS mappings that may be temporarily incorrect. When configured, static SSM mappings take precedence over DNS mappings.

DNS-Based SSM Mapping

DNS-based SSM mapping enables you to configure the last hop router to perform a reverse DNS lookup to determine sources sending to groups (see Figure 1). When DNS-based SSM mapping is configured, the router constructs a domain name that includes the group address G and performs a reverse lookup into the DNS. The router looks up IP address resource records (IP A RRs) to be returned for this constructed domain name and uses the returned IP addresses as the source addresses associated with this group. SSM mapping supports up to 20 sources for each group. The router joins all sources configured for a group.