IP Multicast
In This Chapter
This chapter provides information on multicast for IPv4 and IPv6, including Internet Group Management Protocol (IGMP), Multicast Listener Discovery (MLD), and Protocol Independent Multicast Source-Specific Multicast (PIM SSM).
Topics in this chapter include:
Overview of IP Multicast
IP multicast is a method of sending a single stream of traffic (or a single copy of data) to multiple recipients. IP multicast provides an effective method of one-to-many and many-to-many communication.
In the case of unicast delivery, IP packets are sent from a single source to a single host receiver. The source inserts the address of the target receiver in the IP header destination field of an IP datagram, and intermediate routers (if present) forward the datagram towards the target in accordance with their respective routing tables.
However, some applications, such as audio or video streaming broadcasts, require the delivery of individual IP packets to multiple destinations. In such applications, IP multicast is used to distribute datagrams from one or more source hosts to a set of receivers that may be distributed over different (sub) networks.
A multicast source sends a single copy of data to a single IP address that represents a group of receivers (multicast group). The source inserts the address of the multicast group in the datagram’s header in the destination IP address field. A source does not have to register to a Rendezvous Point (RP) in order to send data to a group, nor does it need to be a member of the group. Intermediate routers forward the data using the group address. The last router on the route replicates and distributes the data to all group members attached to it.
Routers and Layer 3 switches use the Internet Group Management Protocol (IGMP) to manage group membership for IPv4 multicast and Multicast Listener Discovery (MLD) for IPv6 multicast. When a host receiver wants to receive one or more multicast sessions, it signals its local router by sending a Join message to each multicast group it wants to join. When a host wants to leave a multicast group, it sends a Leave message. The local router forwards its group membership information to the core routers to inform the core routers about which multicast flows are needed.
To extend multicast from the receivers’ local router to the Internet, the 7705 SAR uses Protocol Independent Multicast Source-Specific Multicast (PIM SSM), which employs both unicast and multicast routing tables to keep track of route information. As more routers in the Internet become multicast-capable, using both unicast and multicast routing tables becomes more and more important.
To summarize, host receivers connect to a local router (7705 SAR) via IGMP or MLD access or network interfaces. The 7705 SAR connects to the network—and eventually to the multicast source device at the far end—via PIM SSM network interfaces. At the multicast source end, the 7705 SAR connects to the source via a PIM SSM access or network interface.
Mobile Backhaul IP Multicast Example
A typical mobile backhaul infrastructure designed for Multimedia Broadcast Multicast Service (MBMS) is shown in Figure 1.
Figure 1: IP Multicast for MBMS
The 7705 SAR listens for IGMP and MLD receiver requests from the eNB and relays the requested group information back to the requester in one of two ways:
- via local replication, if the stream for the given group is already available (that is, one or more receivers have already joined the group), or
- via first relaying the request to the upstream router and then replicating the stream to the new receiver once the stream is available
Figure 1 illustrates this as follows.
- The 7705 SAR listens to IGMPv3 on an eNB IPv4 interface, or to MLDv2 on an eNB IPv6 interface.
- The 7705 SAR uses PIM SSM to send multicast traffic upstream and communicate with the 7750 SR at the MTSO. Similarly, the 7750 SR runs PIM SSM towards the 7705 SAR.
- The 7750 SR can then run a wide variety of different multicast protocols (such as point-to-multipoint LSPs, and multicast IP-VPN) towards the network core where the source (video head end) is located.
Source-Specific Multicast (SSM) versus Any-Source Multicast (ASM)
The Source-Specific Multicast (SSM) service model defines a channel identified by an (S,G) pair, where S is a source address and G is a multicast group address. SSM provides network layer support for one-to-many delivery, as opposed to Any-Source Multicast (ASM), which supports many-to-many delivery. The ASM service model identifies a channel by a (*, G) pair, where “*” (star) represents one or more sources.
 | Note:
The 7705 SAR does not support Any-Source Multicast (ASM), the many-to-many service model. |
The SSM service model attempts to alleviate the following deployment problems that ASM has presented:
- address allocation — SSM defines channels on a per-source basis. For example, the channel (S1,G) is distinct from the channel (S2,G), where S1 and S2 are source addresses. This avoids the problem of global allocation of SSM destination addresses and makes each source independently responsible for resolving address collisions for the various channels it creates.
- access control — SSM provides an efficient solution to the access control problem. When a receiver subscribes to an (S,G) channel, it receives data sent only by the source, S. In contrast, any host can transmit to an ASM host group. At the same time, when a sender picks a channel (S,G) to transmit on, it is automatically ensured that no other sender will be transmitting on the same channel (except in the case of malicious acts such as address spoofing). This makes it harder to spam an SSM channel than it is to spam an ASM multicast group.
- handling of well-known sources — SSM requires only source-based forwarding trees. This eliminates the need for a shared tree infrastructure. Thus, the complexity of the multicast routing infrastructure for SSM is low, making it viable for immediate deployment.
- future-proofing — SSM anticipates that point-to-multipoint applications such as Internet TV will be significant in the future. The SSM model is better suited for such applications.
IPv4 Multicast
IPv4 multicast enables multicast applications over native IPv4 networks. The 7705 SAR supports Source-Specific Multicast (SSM) for IPv4 with the following protocols:
SSM does not require source discovery and only supports a single multicast source for a specific multicast stream. As a result, SSM is well suited to operate in a large-scale deployment that uses the one-to-many service model.
Internet Group Management Protocol (IGMP)
Internet Group Management Protocol (IGMP) is used by IPv4 hosts and routers to report their IP multicast group memberships to neighboring multicast routers. A multicast router keeps a list of multicast group memberships for each attached network, and a timer for each membership.
Multicast group memberships include at least one member of a multicast group on a given attached network. With respect to each of its attached networks, a multicast router can assume one of two roles, querier or non-querier. There is normally only one querier per physical network. The querier is the router elected as the router that issues queries for all routers on a LAN segment. Non-queriers listen for reports.
The querier issues two types of queries, a general query and a group-specific query. General queries are issued to solicit membership information with regard to any multicast group. Group-specific queries are issued when a router receives a Leave message from the node it perceives as being the last remaining group member on that network segment.
SSM translation allows an IGMPv1 or IGMPv2 device to join an SSM multicast network through the router that provides such a translation capability. SSM translation can done at the node (IGMP protocol) level, and at the interface level, which offers the ability to have the same (*,G) mapped to two different (S,G)s on two different interfaces to provide flexibility. Since PIM SSM does not support (*,G), SSM translation is required to support IGMPv1 and IGMPv2.
Hosts wanting to receive a multicast session issue a multicast group membership report. These reports must be sent to all multicast-enabled routers.
IGMP Versions and Interoperability Requirements
If routers run different versions of IGMP, they will negotiate to run the lowest common version of IGMP that is supported on their subnet and operate in that version. The 7705 SAR supports three versions of IGMP:
- version 1 — specified in RFC 1112, Host extensions for IP Multicasting, IGMPv1 was the first widely deployed version and the first version to become an Internet standard
- version 2 — specified in RFC 2236, Internet Group Management Protocol, IGMPv2 added support for “low leave latency”; that is, a reduction in the time it takes for a multicast router to learn that there are no longer any members of a particular group present on an attached network
- version 3 — specified in RFC 3376, Internet Group Management Protocol, IGMPv3 added support for source filtering; that is, the ability for a system to report interest in receiving packets only from specific source addresses, as required to support Source-Specific Multicast or from all but specific source addresses, sent to a particular multicast address (see Source-Specific Multicast (SSM) versus Any-Source Multicast (ASM))
IGMPv3 must keep track of each group’s state for each attached network. The group state consists of a filter-mode, a list of sources, and various timers. For each attached network running IGMP, a multicast router records the desired reception state for that network.
IGMP Version Transition
Alcatel-Lucent 7705 SAR routers are capable of interoperating with routers and hosts running IGMPv1, IGMPv2, and/or IGMPv3. RFC 5186, Internet Group Management Protocol version 3 (IGMPv3)/Multicast Listener Discovery version 2 (MLDv2) and Multicast Routing Protocol Interaction explores some of the interoperability issues and how they affect the various routing protocols.
IGMPv3 specifies that if at any time a router receives an older IGMP version query message on an interface, then it must immediately switch to a mode that is compatible with that earlier version. Since the previous versions of IGMP are source-aware, should this occur and the interface switch to version 1 or version 2 compatibility mode, any previously learned group memberships with specific sources (learned via the IGMPv3 specific INCLUDE or EXCLUDE mechanisms) must be converted to non-source-specific group memberships. The routing protocol will then treat this as if there is no EXCLUDE definition present.
PIM SSM for IPv4
IGMPv3 permits a receiver to join a group and specify that it only wants to receive traffic for a multicast group if that traffic comes from a particular source.
The range of multicast addresses from 232.0.0.0 to 232.255.255.255 is currently set aside for source-specific multicast in IPv4. For groups in this range, receivers should only issue source-specific IGMPv3 joins. If a PIM router receives a non-source-specific join message for a group in this range, it should ignore it.
A 7705 SAR PIM router must silently ignore a received (*,G) PIM join message when “G” is a multicast group address from the multicast address group range that has been explicitly configured for SSM. This occurrence should generate an event. If configured, the IGMPv2 request can be translated into IGMPv3. The 7705 SAR allows for the conversion of an IGMPv2 (*,G) request into a IGMPv3 (S,G) request based on manual entries. A maximum of 32 SSM ranges is supported.
IGMPv3 also permits a receiver to join a group and specify that it only wants to receive traffic for a group if that traffic does not come from a specific source or sources. In this case, the designated router (DR) will perform a (*,G) join as normal, but can combine this with a prune for each of the sources the receiver does not wish to receive.
IPv6 Multicast
IPv6 multicast enables multicast applications over native IPv6 networks. The 7705 SAR supports Source-Specific Multicast (SSM) for IPv6 with the following protocols:
SSM does not require source discovery and only supports a single source of data for a specific multicast stream. As a result, SSM is well suited to operate in a large- scale deployment that uses the one-to-many service model.
| Note:
The 7705 SAR does not support Any-Source Multicast (ASM), the many-to-many service model. |
Multicast Listener Discovery (MLDv1 and MLDv2)
MLD is the IPv6 version of IGMP. The purpose of MLD is to allow each IPv6 router to discover the presence of multicast listeners on its directly attached links, and to discover specifically which multicast groups are of interest to those neighboring nodes.
MLD is a sub-protocol of ICMPv6. MLD message types are a subset of the set of ICMPv6 messages, and MLD messages are identified in IPv6 packets by a preceding Next Header value of 58. All MLD messages are sent with a link-local IPv6 source address, a Hop Limit of 1, and an IPv6 Router Alert option in the Hop-by-Hop Options header.
Similar to IGMPv2, MLDv1 reports include only the multicast group addresses that listeners are interested in, and do not include the source addresses. In order to work with the PIM SSM model, an SSM translation function similar to that used for IGMPv2 is required when MLDv1 is used.
SSM translation allows an MLDv1 device to join an SSM multicast network through the router that provides such a translation capability. SSM translation can done at the node (MLD protocol) level, and at the interface level, which offers the ability to have the same (*,G) mapped to two different (S,G)s on two different interfaces to provide flexibility. Since PIM SSM does not support (*,G), SSM translation is required to support MLDv1.
MLDv2 is backwards compatible with MLDv1 and adds the ability for a node to report interest in listening to packets with a particular multicast group only from specific source addresses or from all sources except for specific source addresses.
PIM SSM for IPv6
The IPv6 address family for the SSM model is supported. OSPFv3 and static routing have extensions to support submission of routes into the IPv6 multicast RTM.
PIM
The 7705 SAR supports PIM SSM according to RFC 4607, Source-Specific Multicast for IP.
For information on PIM SSM support for IPv4 and IPv6, refer to PIM SSM for IPv4 and PIM SSM for IPv6.
PIM Routing Tables
The 7705 SAR supports unicast and multicast Reverse Path Forwarding (RPF) tables for both IPv4 and IPv6. You can configure which table is used when searching for an RPF interface for a multicast route. The choices are: unicast table only, multicast table only, or both tables.
PIM Routing Policies
You can filter traffic at the PIM protocol level by defining and importing join policies. Up to five policies can be applied.
PIM Bootstrap Message Processing
Since the 7705 SAR supports Source-Specific Multicast (SSM), but not Any-Source Multicast (ASM), configuring Bootstrap Router (BSR) and Rendezvous Point (RP) parameters do not apply to the 7705 SAR.
However, because the 7705 SAR might be deployed in a mixed ASM-SSM network, it must conform to RFC 2362, Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. This means that the 7705 SAR, as a non-candidate BSR, must still accept and forward BSM messages (which contain group-to-RP-set mappings) in order for the ASM routers to have a full multicast topology view. To support BSR messages, the 7705 SAR is fully configurable via bootstrap export and import policies.
Bootstrap import and export policies are created using the config>router>policy-options>policy-statement command, and are assigned to PIM SSM using the config>router>pim>rp>bootstrap-import and bootstrap-export commands. For more information on configuring bootstrap policies, refer to the “Configuring PIM Join Policies” section of the 7705 SAR OS Router Configuration Guide.
IP Multicast Debugging Tools
This section describes multicast debugging tools for the 7705 SAR. The debugging tools for multicast consist of three elements, which are accessed from the CLI <global> level:
Mtrace
Assessing problems in the distribution of IP multicast traffic can be difficult. The multicast traceroute (mtrace) feature uses a tracing feature implemented in multicast routers that is accessed via an extension to the IGMP protocol. The mtrace feature is used to print the path from the source to a receiver; it does this by passing a trace query hop-by-hop along the reverse path from the receiver to the source. At each hop, information such as the hop address, routing error conditions, and packet statistics are gathered and returned to the requester.
Data added by each hop includes:
- query arrival time
- incoming interface
- outgoing interface
- previous hop router address
- input packet count
- output packet count
- total packets for this source/group
- routing protocol
- TTL threshold
- forwarding/error code
The information enables the network administrator to determine:
- the flow of the multicast stream
- where multicast flows stop
When the trace response packet reaches the first-hop router (the router that is directly connected to the source’s network interface), that router sends the completed response to the response destination (receiver) address specified in the trace query.
If a multicast router along the path does not implement the mtrace feature or if there is an outage, then no response is returned. To solve this problem, the trace query includes a maximum hop count field to limit the number of hops traced before the response is returned. This allows a partial path to be traced.
The reports inserted by each router contain not only the address of the hop, but also the TTL required to forward the packets and flags to indicate routing errors, plus counts of the total number of packets on the incoming and outgoing interfaces and those forwarded for the specified group. Examining the differences in these counts for two separate traces and comparing the output packet counts from one hop with the input packet counts of the next hop allows the calculation of packet rate and packet loss statistics for each hop to isolate congestion problems.
Finding the Last Hop Router
The trace query must be sent to the multicast router that is the last hop on the path from the source to the receiver. If the receiver is on the local subnet (as determined by the subnet mask), then the default method is to send the trace query to all-routers.mcast.net (224.0.0.2) with a TTL of 1. Otherwise, the trace query is sent to the group address since the last-hop router will be a member of that group if the receiver is. Therefore, it is necessary to specify a group that the intended receiver has joined. This multicast query is sent with a default TTL of 64, which may not be sufficient for all cases.
When tracing from a multihomed host or router, the default receiver address may not be the desired interface for the path from the source. In that case, the desired interface should be specified explicitly as the receiver.
Directing the Response
By default, mtrace first attempts to trace the full reverse path, unless the number of hops to trace is explicitly set with the hop option. If there is no response within a 3-s timeout interval, a “*” is displayed and the probing switches to hop-by-hop mode. Trace queries are issued starting with a maximum hop count of one and increasing by one until the full path is traced or no response is received. At each hop, multiple probes are sent. The first attempt is made with the unicast address of the host running mtrace as the destination for the response. Since the unicast route may be blocked, the remainder of attempts request that the response be sent to mtrace.mcast.net (224.0.1.32) with the TTL set to 32 more than what is needed to pass the thresholds seen so far along the path to the receiver. For the last attempts, the TTL is increased by another 32.
Alternatively, the TTL may be set explicitly with the TTL option.
For each attempt, if no response is received within the timeout, a “*” is displayed. After the specified number of attempts have failed, mtrace will try to query the next-hop router with a DVMRP_ASK_NEIGHBORS2 request (as used by the mrinfo feature) to determine the router type.
The output of mtrace is a short listing of the hops in the order they are queried, that is, in the reverse of the order from the source to the receiver. For each hop, a line is displayed showing:
- the hop number (counted negatively to indicate that this is the reverse path)
- the multicast routing protocol
- the threshold required to forward data (to the previous hop in the listing as indicated by the up-arrow character)
- the cumulative delay for the query to reach that hop (valid only if the clocks are synchronized)
The response ends with a line showing the round-trip time which measures the interval from when the query is issued until the response is received, both derived from the local system clock.
Mtrace/mstat packets use special IGMP packets with IGMP type codes of 0x1E and 0x1F.
Mstat
The mstat feature adds the capability to show the multicast path in a limited graphic display and indicates drops, duplicates, TTLs, and delays at each node. This information is useful to the network operator because it identifies nodes with high drop and duplicate counts. Duplicate counts are shown as negative drops.
The output of mstat provides a limited pictorial view of the path in the forward direction with data flow indicated by arrows pointing downward and the query path indicated by arrows pointing upward. For each hop, both the entry and exit addresses of the router are shown if different, along with the initial TTL required on the packet in order to be forwarded at this hop and the propagation delay across the hop assuming that the routers at both ends have synchronized clocks. The output consists of two columns, one for the overall multicast packet rate that does not contain lost/sent packets and the other for the (S,G)-specific case. The (S,G) statistics also do not contain lost/sent packets.
Mrinfo
The mrinfo feature is a simple mechanism to display the configuration information from the target multicast router. The type of information displayed includes the multicast capabilities of the router, code version, metrics, TTL thresholds, protocols, and status. This information can be used by network operators, for example, to verify if bidirectional adjacencies exist. Once the specified multicast router responds, the configuration is displayed.
Configuration Notes
General
This section describes multicast configuration caveats:
- a multicast stream is required by one or more multicast clients
- a multicast stream is offered by one or more multicast servers
- unlike 7750 SR nodes, when the maximum number of groups per node limit is exceeded, the additional groups are not stored at the CSM layer and an alarm is raised immediately
Reference Sources
For information on supported IETF drafts and standards, as well as standard and proprietary MIBs, refer to Standards and Protocol Support.
IP Multicast Configuration Process Overview
Figure 2 shows the process to configure multicast parameters.
Figure 2: IP Multicast Configuration Process
