Mechanics of IP Multicast


IP Multicast can be broken into three categories to more easily explain how content is successfully delivered from a source server to multiple receivers:

  • Multicast routing

  • Host signaling

  • Sourcing

Protocol-Independent Multicast sparse mode (PIM-SM) is the method used to facilitate the successful delivery of multicast traffic from source to destination through an enterprise network. The primary benefit of PIM-SM is that the protocol assumes that no host wants multicast traffic unless it specifically requests it. PIM is an independent routing protocol. Therefore, PIM uses the information in the unicast routing table to determine what happens to multicast traffic, regardless of the unicast routing protocol used on a router. The fundamental difference between multicast and unicast routing is that PIM determines the destination of multicast traffic by working with the source address rather than the destination address.

In unicast routing, traffic is routed through the network along a single path from the source to the destination host. A unicast router does not consider the source address; it considers only the destination address and how to forward the traffic toward that destination. The router scans its routing table for the destination address and then forwards a single copy of the unicast packet out the correct interface in the direction of the destination.

In multicast forwarding, the source sends traffic to an arbitrary group of hosts that are represented by a multicast group address. The multicast router must determine which direction is upstream (toward the source) and which is downstream . If there are multiple downstream paths, the router replicates the packet and forwards it down the appropriate downstream paths (best unicast route metric), which is not necessarily all paths. Forwarding multicast traffic away from the source, rather than to the receiver, is called Reverse Path Forwarding (RPF). RPF is described in the following section.

RPF

PIM uses the unicast routing information to create a distribution tree along the reverse path from the receivers toward the source. The multicast routers then forward packets along the distribution tree from the source to the receivers. RPF is a key concept in multicast forwarding. It lets routers correctly forward multicast traffic down the distribution tree. 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. This RPF check helps guarantee that the distribution tree is loop-free.

RPF Check

When a multicast packet arrives at a router, the router performs an RPF check on the packet. If the RPF check succeeds, the packet is forwarded. Otherwise, it is dropped.

For traffic flowing down a source tree, the RPF check procedure works as follows:

Step 1.

The router looks up the source address in the unicast routing table to determine if the packet has arrived on the interface that is on the reverse path back to the source.

Step 2.

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

Step 3.

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

Distribution trees are used to define the path that multicast traffic takes through the network. PIM uses shared trees and source distribution trees. Source trees may also be referred to as shortest-path trees (SPTs) because the tree uses the shortest path through the network. An SPT is represented on a router with the (S,G) notation, where S denotes the IP address of the source and G denotes the multicast group address. This is generally shortened to "S comma G" (S,G). Shared trees use a common point in the network called the rendezvous point (RP), which acts as the root of the multicast delivery tree. This tree is represented on a router with the (S,G) notation, where * denotes all sources and G denotes the multicast group address, which is shortened to "star comma G" (*,G).

Source Trees Versus Shared Trees

Both source trees and shared trees are loop-free. Messages are replicated only where the tree branches.

Members of multicast groups can join or leave at any time; therefore, the distribution trees must be dynamically updated. 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.

Source trees have the advantage of creating the optimal path between the source and the receivers. This advantage guarantees the minimum amount of network latency for forwarding multicast traffic. However, this optimization comes at a cost: The routers must maintain path information for each source. In a network that has thousands of sources and thousands of groups, this overhead can quickly become a resource issue on the routers. Memory consumption from the size of the multicast routing table is a factor that network designers must take into consideration.

Shared trees have the advantage of requiring the minimum amount of state in each router. This advantage lowers the overall memory requirements for a network that allows only shared trees. The disadvantage of shared trees is that under certain circumstances the paths between the source and receivers might not be the optimal paths, which might introduce some latency in packet delivery.

Protocol-Independent Multicast

Protocol-Independent Multicast (PIM) is IP routing protocol-independent and can leverage whichever unicast routing protocols are used to populate the unicast routing table, including Enhanced Interior Gateway Routing Protocol (EIGRP), Open Shortest Path First (OSPF), Border Gateway Protocol (BGP), and static routes. PIM uses this unicast routing information to perform the multicast forwarding function. Although PIM is called a multicast routing protocol, it actually uses the unicast routing table to perform the RPF check function instead of building a completely independent multicast routing table. Unlike other routing protocols, PIM does not send and receive routing updates between routers.

PIM forwarding modes are described in the next three sections.

PIM Dense Mode

PIM dense mode (PIM-DM) uses a push model to flood multicast traffic to every corner of the network. This push model is a brute-force method of delivering data to the receivers. This method would be efficient in certain deployments in which there are active receivers on every subnet in the network.

PIM-DM initially floods multicast traffic throughout the network. Routers that have no downstream neighbors prune the unwanted traffic. This process repeats every 3 minutes.

Routers accumulate state information by receiving data streams through the flood-and-prune mechanism. These data streams contain the source and group information so that downstream routers can build their multicast forwarding table. PIM-DM supports only source treesthat is, (S,G) entries. It cannot be used to build a shared distribution tree.

PIM Sparse Mode

PIM-SM uses a pull model to deliver multicast traffic. Only network segments with active receivers that have explicitly requested the data receive the traffic.

PIM-SM distributes information about active sources by forwarding data packets on the shared tree. Because PIM-SM uses shared trees (at least initially), it requires the use of an RP. The RP must be administratively configured in the network.

Sources register with the RP, and then data is forwarded down the shared tree to the receivers. The edge routers learn about a particular source when they receive data packets on the shared tree from that source through the RP. The edge router then sends PIM (S,G) join messages toward that source. Each router along the reverse path compares the unicast routing metric of the RP address to the metric of the source address. If the metric for the source address is better, the router forwards a PIM (S,G) join message toward the source. If the metric for the RP is the same or better, the PIM (S,G) join message is sent in the same direction as the RP. In this case, the shared tree and the source tree are considered congruent.

If the shared tree is not an optimal path between the source and the receiver, the routers dynamically create a source tree and stop traffic from flowing down the shared tree. This behavior is the default behavior in Cisco IOS. Network administrators can force traffic to stay on the shared tree by using the Cisco IOS ip pim spt-threshold infinity command.

PIM-SM was originally described in RFC 2362, Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. This RFC is being revised and is currently in draft form. The draft specification, Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification (Revised), can be found on the IETF website: http://www.ietf.org.

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.

Bidirectional PIM (Bidir-PIM)

Bidirectional PIM (bidir-PIM) is an enhancement of the PIM protocol that was designed for efficient many-to-many communications within an individual PIM domain. Multicast groups in bidirectional mode can scale to an arbitrary number of sources with only a minimal amount of additional overhead.

The shared trees that are created in PIM sparse mode are unidirectional. This means that a source tree must be created to bring the data stream to the RP (the root of the shared tree). Then it can be forwarded down the branches to the receivers. Source data cannot flow up the shared tree toward the RP, which would be considered a bidirectional shared tree.

In bidirectional mode, traffic is routed only along a bidirectional shared tree that is rooted at the RP for the group. With bidir-PIM, the RP's IP address acts as the key to having all routers establish a loop-free spanning-tree topology rooted in that IP address. This IP address need not be a router address. It can be any unassigned IP address on a network that can be reached throughout the PIM domain.

Bidir-PIM is derived from the mechanisms of PIM sparse mode (PIM-SM) and shares many of the shared tree operations. Bidir-PIM also has unconditional forwarding of source traffic toward the RP upstream on the shared tree, but it has no registering process for sources as in PIM-SM. These modifications are necessary and sufficient to allow forwarding of traffic in all routers solely based on the (*,G) multicast routing entries. This feature eliminates any source-specific state and allows scaling capability to an arbitrary number of sources.

The current specification of bidir-PIM can be found in the IETF draft titled Bi-Directional Protocol Independent Multicast (BIDIR-PIM) on the IETF website (http://www.ietf.org).

Interdomain Multicast Protocols

The following three sections discuss interdomain multicast protocolsprotocols that are used between multicast domains. Internet service providers (ISPs) also use these protocols to forward multicast traffic on the Internet.

Multiprotocol Border Gateway Protocol

Multiprotocol Border Gateway Protocol (MBGP) lets providers specify which route prefixes they will use to perform multicast RPF checks. The RPF check is the fundamental mechanism that routers use to determine the paths that multicast forwarding trees follow and to successfully deliver multicast content from sources to receivers. For more information, see the earlier section "RPF."

MBGP is described in RFC 2283, Multiprotocol Extensions for BGP-4. Because MBGP is an extension of BGP, it contains the administrative machinery that providers and customers require in their interdomain routing environment, including all the inter-AS tools to filter and control routing, such as route maps. Therefore, any network that uses internal BGP (iBGP) or external BGP (eBGP) can use MBGP to apply the multiple policy control knobs familiar in BGP to specify the routing policy (and thereby the forwarding policy) for multicast.

Two path attributes, MP_REACH_NLRI and MP_UNREACH_NLRI, were introduced in BGP-4. These new attributes create a simple way to carry two sets of routing information: one for unicast routing and the other for multicast routing. The routes associated with multicast routing are used for RPF checking at the interdomain borders.

The main advantage of MBGP is that an internetwork can support noncongruent unicast and multicast topologies. When the unicast and multicast topologies are congruent, MBGP can support different policies for each. Separate BGP routing tables are maintained for the Unicast Routing Information Base (U-RIB) and the Multicast Routing Information Base (M-RIB). The M-RIB is derived from the unicast routing table with the multicast policies applied. RPF checks and PIM forwarding events are performed based on the information in the M-RIB. MBGP provides a scalable policy-based interdomain routing protocol.

Multicast Source Discovery Protocol

In the PIM-SM model, the router closest to the sources or receivers registers with the RP. The RP knows about all the sources and receivers for any particular group. Network administrators may want to configure several RPs and create several PIM-SM domains. In each domain, RPs have no way of knowing about sources located in other domains. Multicast Source Discovery Protocol (MSDP) is an elegant way to solve this problem.

MSDP was developed for peering between ISPs. ISPs did not want to rely on an RP maintained by a competing ISP to provide service to their customers. MSDP allows each ISP to have its own local RP and still forward and receive multicast traffic to and from the Internet.

MSDP lets RPs share information about active sources. RPs know about the receivers in their local domain. When RPs in remote domains hear about the active sources, they can pass on that information to their local receivers, and multicast data can then be forwarded between the domains. A useful feature of MSDP is that it allows each domain to maintain an independent RP that does not rely on other domains. MSDP gives network administrators the option of selectively forwarding multicast traffic between domains or blocking particular groups or sources. PIM-SM is used to forward the traffic between the multicast domains.

The RP in each domain establishes an MSDP peering session using a TCP connection with the RPs in other domains or with border routers leading to the other domains. When the RP learns about a new multicast source within its own domain (through the normal PIM register mechanism), the RP encapsulates the first data packet in a Source-Active (SA) message and sends the SA to all MSDP peers. MSDP uses a modified RPF check to determine which peers should be forwarded the SA messages. This modified RPF check is done at an AS level instead of a hop-by-hop metric. The SA is forwarded by each receiving peer, also using the same modified RPF check, until the SA reaches every MSDP router in the internetworktheoretically, the entire multicast Internet. If the receiving MSDP peer is an RP, and the RP has a (*,G) entry for the group in the SA (that is, there is an interested receiver), the RP creates (S,G) state for the source and joins to the shortest-path tree for the source. The encapsulated data is decapsulated and forwarded down the shared tree of that RP. When the receiver's last-hop router receives the packet, the last-hop router also may join the shortest-path tree to the source. The MSDP speaker periodically sends SAs that include all sources within the own domain of the RP.

Source-Specific Multicast

Source-Specific Multicast (SSM) is an extension of the PIM protocol that allows for an efficient data delivery mechanism in one-to-many communications. SSM allows a receiving client, after it has learned about a particular multicast source through a directory service, to then receive content directly from the source, rather than receiving it using a shared RP.

SSM removes the requirement of MSDP to discover the active sources in other PIM domains. An out-of-band service at the application level, such as a web server, can perform source discovery. It also removes the requirement for an RP.

In traditional multicast implementations, applications must "join" to an IP multicast group address, because traffic is distributed to an entire IP multicast group. If two applications with different sources and receivers use the same IP multicast group address, receivers of both applications receive traffic from the senders of both the applications. Even though the receivers, if programmed appropriately, can filter out the unwanted traffic, this situation still would likely generate noticeable levels of unwanted network traffic.

In an SSM-enhanced multicast network, the router closest to the receiver "sees" a request from the receiving application to join to a particular multicast source. The receiver application then can signal its intention to join a particular source by using Include mode in IGMPv3.

The multicast router can now send the request directly to the source rather than sending the request to a common RP as in PIM sparse mode. At this point, the source can send data directly to the receiver using the shortest path. In SSM, routing of multicast traffic is accomplished entirely with source trees. There are no shared trees, so an RP is not required.

The ability for SSM to explicitly include and exclude particular sources allows for a limited amount of security. Traffic from a source to a group that is not explicitly listed on the INCLUDE list is not forwarded to uninterested receivers.

SSM also solves IP multicast address collision issues associated with one-to-many-type applications. Routers running in SSM mode route data streams based on the full (S,G) address. Assuming that a source has a unique IP address to send on the Internet, any (S,G) from this source also would be unique.

Multicast Addressing

With the growing popularity of IP multicast applications, many users are considering deploying, or have already deployed, IP multicast in their networks. The design and documentation of an appropriate multicast addressing scheme are important components of a successful IP multicast deployment.

Here are some of the common issues you may encounter during IP multicast deployment:

  • Simplify administration and troubleshooting of IP multicast.

  • Control the distribution and use of IP multicast group addresses within an organization (such as between business units).

  • Control the distribution and scope of multicast application data within an organization.

  • Locate the rendezvous point with PIM sparse mode and determine which IP multicast groups each will serve.

  • Control IP multicast traffic on WAN links so that high-rate groups cannot saturate low-speed links.

  • Control who can send IP multicast and who can receive (security).

  • Be ready to deploy next-generation IP multicast protocols (such as bidir-PIM and SSM).

  • Link to the Internet for multicast.

  • Allow for future requirements and expansion so that re-addressing does not have to occur at a later date.

A solid addressing policy is the key to solving or simplifying many of these issues. Without a correctly planned and scoped IP multicast addressing scheme, customers will encounter more complex configurations, which significantly decreases the control of IP multicast over the network and increases administration and support overhead.

The IPv4 multicast address space is handled differently than its unicast counterpart. Unlike unicast addresses, which are uniquely assigned to organizations by the Internet Assigned Numbers Authority (IANA), the multicast address space is openly available for use.

This openness could potentially create problems with address collisions, so steps have been taken to minimize this possibility. Mainly, the multicast address space has been divided into some well-known ranges to give guidance to network operators and to facilitate deployment of certain applications. The well-known group address ranges include the following:

  • Multicast address range 224.0.0.0/4 (RFC 1112)

  • Local scoped range 224.0.0.0/24 (http://www.iana.org/assignments/multicast-addresses)

  • IANA assigned range 224.0.1.0/24 (http://www.iana.org/assignments/multicast-addresses)

  • SSM range 232.0.0.0/8 (IETF: draft-ietf-ssm-arch-01.txt)

  • GLOP range 233.0.0.0/8 (RFC 2770)

  • Administratively scoped range 239.0.0.0/8 (RFC 2365)

Administratively Scoped Addresses

RFC 2365 provides guidelines on how the multicast address space can be divided and used privately by enterprises. The phrase "administratively scoped IPv4 multicast space" relates to the group address range 239.0.0.0 to 239.255.255.255. The key properties of administratively scoped IP multicast are that packets addressed to administratively scoped multicast addresses do not cross configured administrative boundaries. Administratively scoped multicast addresses are locally assigned, so they do not need to be unique across administrative boundaries. This range of multicast addresses was defined to give autonomous networks a set of private multicast addresses that could be used inside their networks without the fear of address collision from outside entities. It is the equivalent of unicast private addresses, as described in RFC 1918. To maintain the integrity of this address space and prevent leaks of control or data traffic into or out of this boundary, it needs to be scoped at the network edge.

A detailed document on IP multicast addressing and scoping can be found at http://ftp-eng.cisco.com.

Deploying the IP Multicast Service

The RP is a fundamental component in PIM sparse mode multicast networks. The RP is a common router in the network that senders and receivers use to learn about each other. Multicast sources are "registered" with the RP by their first-hop router, and receivers are "joined" to the shared tree (rooted at the RP) by their local designated router (DR).

The RP uses multicast to distribute the group RP mappings to all routers in the network, which is known as Auto-RP. All multicast-enabled routers in the network must be enabled for PIM sparse-dense mode to allow Auto-RP to propagate through the network in dense mode. These are the only groups that should operate in dense mode. PIM sparse-dense mode provides multicast-enabled routers with the information required to send joins for specific groups to build shared trees. With Auto-RP, you can configure the RPs themselves to announce their availability as an RP and as a mapping agent. The RPs send their announcements using the 224.0.1.39 IP address. The RP mapping agent listens to the announcement packets from the RPs and then sends RP-to-group mappings in a discovery message, which is sent to the 224.0.1.40 IP address. These discovery messages are automatically received by all routers configured for sparse-dense mode and are used to define their RP-to-group mapping information.

The RPs are configured with an anycast address, which is a method of configuring multiple devices on a network using the same IP address. The benefit of this approach is that if an RP fails, the unicast routing table still contains another reachable entry. Thus, shared trees are successfully built toward the next-closest RP. In Acme, the IP anycast address used is 192.168.1.1. It has been defined as the loopback1 address on all RP routers within Acme. For example, if the RP in New York fails, the RP in San Jose takes over, because it is the next reachable 192.168.1.1 IP address in the Interior Gateway Protocol (IGP) employed, which in this case is EIGRP.

MSDP is a method for RPs in different PIM-SM domains to peer and share information on active sources. It allows for interdomain streams sourced in San Jose to be viewed by users located in different PIM-SM domains, such as the Acme WAN, which has operations in Europe and Asia. Figure 6-2 is an overview of these concepts.

Figure 6-2. Interdomain MulticastServer to Receiver


When a multicast packet arrives at a router it performs the RPF check. It examines the source address to determine if the packet arrived at an interface that is on the reverse path back to the source. PIM performs the RPF check by looking up the unicast routing table to determine which interface would be used to reach the source IP address of the multicast packet. If the packet is sourced from the correct interface, it is forwarded. If it is not sourced from the correct interface, it is dropped.

Cisco IOS Software Releases 12.2.12, 12.2.12S, and 12.1.13E have a new command option on the ip multicast boundary interface command that can automatically filter RP-announce and RP-discovery messages based on the multicast groups the boundary command will allow to pass:

ip multicast boundary acl [filter-autorp]


This command is not enabled by default. When the new option is enabled, filtering for Auto-RP messages occurs in three cases:

  • An RP-announce or RP-discovery packet is received from the interface.

  • An RP-announce or RP-discovery packet received from another interface is forwarded to this interface.

  • An internally generated RP-announce or RP-discovery packet is sent to the interface.

Default PIM Interface Configuration Mode

The recommended default PIM interface configuration mode is sparse mode. Additionally, a new command lets Auto-RP function with 224.0.1.40 and 224.0.1.39. It is fixed to operate in dense mode for the announcement and discovery of dynamic group RP mappings between all routers. This new command is

ip multicast auto-rp [listener]


This global configuration command lets the router have all its interfaces configured in sparse mode, thereby eliminating the potential for dense mode to flood across a topology. It still allows the two groups necessary for Auto-RP to function in dense mode for the dissemination of group RP mapping information and announcements.

Host Signaling

Before content can be delivered, the network infrastructure needs to be aware that users require content. Internet Group Management Protocol (IGMP) lets the end users in a network request delivery of multicast content. When a user requests delivery of multicast content, the workstation sends an IGMP join message to the LAN subnet. When two PIM-enabled multicast routers exist on the same LAN configured in a Hot Standby Router Protocol (HSRP) group, both track the IGMP messages by storing the multicast group address and the first host's source IP address. The router with the lowest IP address is selected as the IGMP querier router and is responsible for maintaining the IGMP table. A DR is also selected between the two PIM-enabled routers by the highest IP address. This router is responsible for sending (*,G) joins toward the RP (based on the IGMP table) and also for forwarding multicast traffic to the LAN. Figure 6-3 shows the IGMP operations in practice.

Figure 6-3. IGMP Operation


A control mechanism is required for Catalyst Layer 2 switches to make intelligent decisions about the delivery of multicast traffic. Otherwise, a Catalyst sends multicast traffic out all ports that are members of a specific virtual LAN (VLAN). IGMP Snooping or Cisco Group Management Protocol (CGMP) must be used to track the ports in the content-addressable memory (CAM) table that have hosts connected wanting to receive multicast traffic with a specific multicast MAC address.

IGMP controls messages transmitted onto the LAN by workstations and routers. Multicast packets are indistinguishable from multicast data at Layer 2. So the 65xx platform uses IGMP snooping to examine every data packet to determine if it contains any pertinent IGMP control information. The 65xx platform has special application-specific integrated circuits (ASICs) that can perform the IGMP checks in hardware. This results in a much more efficient method of delivering multicast traffic onto the user LAN segment. IGMP snooping implemented on a low-end switch with a slow CPU could have severe performance implications when data is sent at high rates. The solution is to use CGMP between the receiver's first-hop router and switch. CGMP is a client/server protocol that runs between the CGMP-capable switches and the multicast router. When the router receives an IGMP join or leave, it in turn sends a CGMP join or leave to the CGMP switches so that they can add ports to or remove ports from the multicast forwarding table. The router delivers CGMP traffic using multicast, which ensures that multiple catalysts receive the CGMP update. CGMP should be used only with legacy switches. For more information on the legacy switches, visit the following web pages:

  • http://www.cisco.com/univercd/cc/td/doc/product/lan/cat2950/12122ea2/2950scg/swigmp.htm

  • http://www.cisco.com/univercd/cc/td/doc/product/lan/cat2970/12225sea/2970scg/swigmp.htm

  • http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3550/12225seb/scg/swigmp.htm

  • http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3560/1225sea/3560scg/swigmp.htm

  • http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3750/12225sea/3750scg/swigmp.htm

  • http://www.cisco.com/univercd/cc/td/doc/product/lan/cat4000/12_2_25a/conf/multi.htm

Sourcing

The IPTV servers stream live multimedia content to the local LAN segment as multicast traffic being delivered to a specific group address. The DR on the same LAN segment as the IPTV server takes this multicast traffic and determines the destination group address. It also checks the multicast routing table for (S,G) and (*,G) entries. The router adds an (S,G) entry in the mroute table, which causes an identical (*,G) route to be created automatically. The router now checks the source IP address and identifies whether the IP address is on a locally connected network. The router encapsulates the packets from the source server in register messages and then sends them to the RP router. An example is shown in Figure 6-4.

Figure 6-4. RP Registration





Selecting MPLS VPN Services
Selecting MPLS VPN Services
ISBN: 1587051915
EAN: 2147483647
Year: 2004
Pages: 136

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net