9.3 IP Transports and IP Multicast

While IP multicast is not directly related to broadcasting, delivery of content via IP multicasting is rapidly becoming a critical capability [IPM]. As the penetration of cable modems and DSL lines increases , so does the need for, and value of, IP multicasting.

The IP multicast protocol enables simultaneously delivery of a single bit-stream to thousands of recipients. iTV content can be streamed, in push mode, via IP multicast to complement the high cost MPEG-based broadcast. IP Multicast delivers source traffic to multiple receivers without adding any additional burden on the source or the receivers (see Figure 9.5). Applications that take advantage of multicast include video conferencing, corporate communications, distance learning, and distribution of software, stock quotes, and news.

Figure 9.5. IP Multicast transmission model.

Multicast is based on the concept of router groups, each registering an interest in receiving a particular data stream carried in packets having a well-defined IP address range. This group does not have any physical or geographical boundaries as its member hosts can be located anywhere on the Internet. Hosts may receive data only from groups they are members of. Therefore, hosts that are interested in receiving data flowing to a particular group need to join that group; this is done using Internet group management protocol defined in RFC 2236 [IGMP].

Propagation IP multicast packets is as follows : As a router receives an IP multicast packet, it checks the Time-To-Live (TTL) counter carried in that packet. If that value is greater than 0, a router decrements that value by one, and retransmits that packet to those directly connected routers having listed the IP address of this packet on their multicast membership groups. Router only retransmit packets in downstream, away from the source, using reverse- path -forwarding (see multicast forwarding in this Chapter). Consequently, a packet may be replicated at most TTL times, and thus can only travel up to TTL hops from the originating source.

9.3.1 Session Description Protocol (SDP)

IP multicast clients need to be able to discover, using well-known public entry points, the multicast addresses to which they need to tune. The SDP, defined in RFC 2327, provides the capability to discover multimedia sessions and supports session announcement, session invitation , and other forms of multimedia session initiation [SDP]. When using IP multicasting for multimedia application, carriage of SDP over IP multicast is a critical capability that is used extensively for multimedia conferencing. This capability is provided by Mbone, a Class-D addressing and routing scheme (all IP addresses are divided into Classes A ... D) that allows distributed applications to achieve real-time communication, implemented by Steve Deering at Xerox PARC and adopted by the IETF in March 1992. To receive a conference, a user at an Mbone site only has to know the conference's multicast group address and the UDP ports for the conference data streams. With SDP, the following key notions are supported:

• Conference : Two or more communicating users along with the software they are using to communicate.

• Session : Two or more multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session.

• Session Announcement (Advertisement) : A mechanism by which a session description is conveyed to users in a proactive fashion, namely the session description was not explicitly requested by the user.

• Session Description : A well defined format for conveying sufficient information to discover and participate in a multimedia session.

In general, SDP conveys sufficient information to be able to join a session (with the possible exception of encryption keys) and to announce the resources to be used to non- participants that may need to know. For example, SDP may include a URI referring to additional session information. More specifically , SDP includes:

• Session name and purpose

• Time(s) the session is active

• The media comprising the session

• The transport protocol (RTP/UDP/IP, H.320, etc.)

• Information about the bandwidth to be used by the conference

• Contact information for the person responsible for the session

• The type of media (video, audio, etc.)

• The format of the media (H.261 video, MPEG video, etc.)

• The multicast address and transport port

9.3.1.1 Multicast Announcements

A common mode of usage is for a client to announce a conference session by periodically multicasting an announcement packet to a well-known multicast address and port using the SAP. Its packets are UDP packets with a header and text payload; the latter may announce at most one session (per packet) and is limited to 1 KByte.

9.3.1.2 Email and WWW Announcements

Alternative means of conveying session descriptions include electronic mail and the Internet. For both Email and WWW distribution, the use of the MIME content type application/sdp should be used. This enables the automatic launching of applications for participation in the session from the WWW client or mail reader in a standard manner.

9.3.1.3 Session Timing

Sessions may either be bounded or unbounded in time. Whether or not they are bounded, they may be only active at specific times. SDP can convey an arbitrary list of start and stop times bounding the session, as well as, for each bound, repeat times (e.g., every Wednesday at 10 a.m. for one hour ).

9.3.1.4 Private Sessions

SDP supports both public and private sessions. Private sessions are typically conveyed by encrypting the session description. If a session announcement is private it is possible to use that private announcement to convey encryption keys necessary to decode each of the media in a conference, including enough information to know which encryption scheme is used for each media.

9.3.2 Internet Group Multicast Protocol (IGMP)

The Internet Group Multicast Protocol (IGMP) is an Internet protocol that enables a host to report its multicast group membership to adjacent routers. IGMP version 1, RFC 1112, uses two different types of IGMP messages: membership query and membership report [IGMP]. Hosts send out IGMP membership reports corresponding to a particular multicast group to indicate that they are interested in joining that group. Each properly configured router periodically sends out an IGMP membership query to verify that at least one host on the subnet is still interested in receiving traffic directed to that group. When there is no reply to three consecutive IGMP membership queries, the router times out the group and stops forwarding traffic directed toward that group.

IGMP version 2, RFC 2236, uses four types of IGMP messages: membership query, version 1 membership report, version 2 membership report, and leave group. IGMPv2 is similar to IGMPv1, with the addition of a leave group message. With version 2, hosts can actively communicate to the local multicast router their intention to leave the group. The router then sends out a group-specific query and determines whether there are any remaining hosts interested in receiving the traffic. If there are no replies, the router times out the group and stops forwarding the traffic. This can greatly reduce the leave latency compared to IGMPv1. Unwanted and unnecessary traffic can be stopped much sooner.

9.3.3 Multicast Addresses

The IP multicast address is essentially the identifier of a broadcast data stream. In terms of the transport protocol, however, multicast addresses specify an arbitrary group of IP hosts that have joined the group and want to receive traffic sent to this group. The Internet Assigned Numbers Authority (IANA) controls the assignment of IP multicast addresses. It has assigned the old Class D address space, in the range of 224.0.0.0 to 239.255.255.255 , to be used for IP multicast.

9.3.3.1 Local Addresses

Further, the IANA has reserved addresses in the 224.0.0.0 through 224.0.0.255 to be used by network protocols on a local network segment. Packets with these addresses should never be forwarded by a router; they remain local on a particular LAN segment. They are always transmitted with a TTL of 1, namely they are replicated exactly once. Network protocols use these addresses for automatic router discovery and to communicate important routing information. For example, Open Shortest Path First (OSPF) uses 224.0.0.5 and 224.0.0.6 to exchange link state information. Table 9.2 lists some of the well-known addresses.

Table 9.2. Local IP Multicast Address Usage

Address	Usage
224.0.0.1	All systems on this subnet
224.0.0.2	All routers on this subnet
224.0.0.5	OSPF routers
224.0.0.6	OSPF designated routers
224.0.0.12	DHCP server/relay agent

9.3.3.2 Global Addresses

The range of addresses from 224.0.1.0 through 238.255.255.255 are called globally scoped addresses. They can be used to multicast data between organizations and across the Internet. Some of these addresses have been reserved for use by multicast applications through IANA. For example, 224.0.1.1 has been reserved for Network Time Protocol (NTP).

9.3.3.3 Limited Scope Addresses

The range of addresses from 239.0.0.0 through 239.255.255.255 contains limited scope addresses or administratively scoped addresses. These are defined by RFC 2365 to be constrained to a local group or organization [IPADMIN]. Routers are typically configured with filters to prevent multicast traffic in this address range from flowing outside an autonomous system or user-defined domains. Within an autonomous system or a domain, the limited scope address range can be further subdivided enabling the definition of local multicast boundaries. This enables address reuse among smaller domains.

9.3.3.4 Glop Addressing

This is an experimental protocol specified in RFC 2770 [GLOP], suggesting that the 233.0.0.0 through 233.0.0.8 address range be reserved for statically defined addresses by organizations that already have an autonomous system number reserved. The autonomous system number of the domain is embedded into the second and third octets of the address. For example, the 0xF23A a subnet of 233.242.58.0 through 233.242.58.8 that would be globally reserved for 62010 decimal to use.

9.3.3.5 Layer 2 Multicast Addresses

Normally, Network Interface Cards (NIC) on a LAN segment receive only packets destined for their burned-in Media Access Control (MAC) address or the broadcast MAC address, also known as the Ethernet address. The IEEE LAN specifications made provisions for the transmission of broadcast and/or multicast packets so that multiple hosts could receive the same packet and still be capable of differentiating among multicast groups. In the 802.3 standard, bit 0 of the first octet indicates a broadcast or multicast frame.

9.3.4 Multicast Forwarding

In unicast routing, traffic is routed through the network along a single path from the source to the destination host. A unicast router typically ignores the source address, and only uses the destination address. The router scans through its routing table and then forwards a single copy of the unicast packet out the correct interface in the direction of the destination.

In multicast routing, the source is sending traffic to an arbitrary group of hosts represented by a multicast group address. The multicast router determines which direction is upstream (toward the source) and which direction (or directions) is downstream. If there are multiple downstream paths, the router replicates the packet and forwards the traffic down the appropriate downstream paths.

This routing method described above, of forwarding multicast traffic away from the source rather than to the receiver, is called Reverse Path Forwarding (RPF). RPF makes use of the existing unicast routing table to determine the upstream and downstream neighbors. A router forwards a multicast packet only if it is received on the upstream interface. When a multicast packet arrives, the router performs an RPF check on the packet. If the RPF check is successful, the packet is forwarded. Otherwise, it is dropped. The RPF check is performed as follows:

Step 1. The router looks up the source address in the unicast routing table to determine whether it has arrived on the interface that is on the reverse path back to the source.

Step 2. If packet has arrived on the interface leading back to the source, the RPF check is successful and the packet is forwarded.

Step 3. If the RPF check in Step 2 fails, the packet is dropped.

9.3.5 Multicast Distribution Trees

Multicast-capable routers create distribution trees that control the path that IP multicast traffic takes through the network to deliver traffic to all receivers. Members of multicast groups can join or leave at any time, implying the need to dynamically update the distribution trees. When all the active receivers on a particular branch stop requesting the traffic for a particular multicast group, the routers prune that branch from the distribution tree and stop forwarding traffic down that branch. If one receiver on that branch becomes active and requests the multicast traffic, the router dynamically modifies the distribution tree and starts forwarding traffic again.

9.3.6 Protocol-Independent Multicast

Protocol-Independent Multicast (PIM) is independent of the IP routing protocol or method used to populate the unicast routing table, including Enhanced Interior Gateway Routing Protocol (EIGRP), OSPF, Border Gateway Protocol (BGP), or static routes. PIM uses the underlying unicast routing information to perform the multicast forwarding function. PIM actually uses the unicast routing table to perform the RPF check function instead of building up a completely independent multicast routing table. PIM does not send and receive multicast routing updates between routers. The following two modes are supported:

• PIM Dense Mode : PIM Dense Mode (PIM-DM) uses a push model to flood multicast traffic to every corner of the network. This is a brute-force method for delivering data to the receivers, but in certain applications, this might be an efficient mechanism if there are active receivers on every subnet in the network. PIM-DM initially floods multicast traffic throughout the network. Routers that do not have any downstream neighbors prune back the unwanted traffic. This process repeats periodically. This flood and prune mechanism enables routers to accumulate their state information. The data stream floods contain the source and group information so that downstream routers can build up their multicast forwarding tables. PIM-DM can support only source trees, and it cannot be used to build a shared distribution tree.

• PIM Sparse Mode : PIM Sparse Mode (PIM-SM) uses a pull model to deliver multicast traffic. Only networks with active receivers that have explicitly requested the data is forwarded the traffic. PIM-SM is defined in RFC 2362. PIM-SM uses a shared tree. The traffic starts to flow down the shared tree, and then routers along the path to determine whether there is a better path to the source. If a better, more direct path exists, the designated router (the router closest to the receiver) sends a join message toward the source and then reroutes the traffic along this path. PIM-SM scales well to a network of any size, including those with WAN links. The explicit join mechanism prevents unwanted traffic from flooding the WAN links.

9.3.6.1 Multicast Source Discovery Protocol (MSDP)

In the PIM-SM multicast sources and receivers register with their local Rendezvous Point (RP). Actually, the closest router to the sources or receivers registers with the RP but the point is that the RP knows about all the sources and receivers for any particular group. RPs in other domains have no way of knowing about sources located in other domains. MSDP is an elegant way to solve this problem. MSDP is a mechanism that connects domains and allows RPs to share information about active sources. When RPs in remote domains know about active sources they can pass on that information to their local receivers and multicast data can be forwarded between the domains. A nice feature of MSDP is that it allows each domain to maintain an independent RP that does not rely on other domains, but it does enable RPs to forward traffic between domains.

9.3.6.2 Multiprotocol Border Gateway Protocol (MBGP)

MBGP gives a method for providers to distinguish which route prefixes they use for performing multicast RPF checks. The RPF check is the fundamental mechanism that routers use to determine the paths that multicast forwarding trees follow and successfully deliver multicast content from sources to receivers.

MBGP is described in RFC 2283, multiprotocol extensions for BGP-4. One of the key advantages of MBGP is that it can support non-congruent unicast and multicast topologies. When the unicast and multicast topologies are congruent, MBGP can support different policies for each, as it provides a scalable policy based inter-domain routing protocol. Being an extension of BGP, MBGP brings along all its administrative machinery. For example, through MBGP, any network utilizing internal or external BGP can apply the multiple BGP policy control knobs to specify routing and forwarding) policy for multicast.