White Paper

Multicast on Verizon Private IP By William Copeland

Most customer equipment supports IP multicast, but, because of unfamiliarity with this protocol on the part of IT managers, few Private IP customers take advantage of this efficient way of distributing a wide variety of data and multimedia applications. The information in this paper illustrates the basics of multicast along with a discussion of multicast across the Private IP network.

Multicast Applications A wide variety of multicast applications exist, and many of these are operating on Private IP today. Some IT tasks are accomplished best with multicast.

Publishing and Distributing Imagine that you own a publishing company whose product is an insert for Sunday newspapers across the country. What’s the most cost-efficient method for distributing this piece to those newspapers before they assemble their Sunday edition? Multicast is the answer. Multicast lets you send one, and only one, electronic copy of your document into the Private IP network where it is instantly and automatically replicated for delivery to each newspaper’s Private IP port. Each paper then can print as many copies as it needs, and you collect the royalties.

Distance Learning Suppose a university wants to offer a course at ten satellite campuses. Private IP Multicast can handle this by accepting the video and audio feeds as a single program and then multiplying it as needed so that all ten virtual classrooms have full accessibility to this course. Private IP multicast will distribute the program to every classroom without requiring a direct individual pipe to each one. So, if the program bandwidth is 1 Mbps at the originator’s video equipment, the university only needs to purchase the cheaper 1 Mbps port vs. the 10 x 1 Mbps ports. If more campuses in other locations need to receive the program, no change is needed at the main campus. The additional copy simply needs to be launched into Private IP, which can make as many copies and distribute them where needed.

Other Multicast Applications Many other applications of multicast exist. With videoconferencing, a CEO can address the enterprise live, speaking to offices around the world. A brokerage house may use multicast to distribute bond prices in real-time to thousands of agents. Multicast also may be used to distribute software updates to many locations. Private IP multicast as the solution to all of these activities saves bandwidth at the host location, diminished download time, and ultimately can reduce costs.

How Multicast Works Multicast represents a different way of thinking about data transmission. Most individual users function in a unicast world—two computers “talk” to each other, and only to each other, at a given time. Rather than one computer host sending data to another host via a unicast transmission (e.g., an e-mail server sending data to your PC), multicast provides a way to send traffic to a group of hosts simultaneously. This is different from a broadcast that sends data to every host on a given network, which can be a burden to computers that are not interested in receiving that transmission. With multicast, only interested hosts actually receive the transmission.

Unicast Transmission Figure 1 shows a simple unicast transmission from the Source, with address 10.1.1.1, to Host A, with destination address 10.1.1.2. In this case, the other workstation, Host B, does not bother to process this packet because it knows from the address that it is not the intended recipient. This kind of packet forwarding, or routing as it is Page  of 9

White Paper

called in the case of IP, is similar to letters being delivered by the post office. The Source Address (SA) is the return address, and the Destination Address (DA) represents the letter recipient. The packet from the Source to Host A would be addressed, from the IP perspective, as follows: (SA, DA) = (10.1.1.1, 10.1.1.2).

10.1.1.1

10.1.1.2

10.1.1.3

Host A

Host B

Source Figure 1: Typical Unicast Traffic Addressing

Multicast Transmission Figure 1 also can show what happens when multicast is used. Now, Hosts A and B both want to receive the transmission from the Source. Without multicast, the Source would have to send two separate packets, addressed individually, to each host as follows: Packet 1: (SA, DA) = (10.1.1.1, 10.1.1.2) Packet 2: (SA, DA) = (10.1.1.1, 10.1.1.3) As discussed, addressing a multicast packet is different from the unicast case. The interested hosts express their desire to receive the transmission by signaling that they want to join the multicast group. This gives the Source the option of using multicast instead of unicast, so that it only needs to send one packet for both hosts. The shorthand convention is Source Address (S) to multicast group (G) and is often written as (S,G). In our example, the multicast packet uses the address: Packet 1 (SA, DA) = (10.1.1.1, 239.4.3.1) Host A is the Source with address 10.1.1.1, and it is sending to multicast group “G,” with multicast address 239.4.3.1. Any host that wishes to join this group may do so and receive the program—providing the network is set up to support multicast. The workstations see the destination address 239.4.3.1 in the packet, and, because they are interested in this particular group, they pull the packet off the wire and deliver it to the user’s application. The Source only had to send one packet.

Multicast Addressing The unicast IP address of the PC on your desk, in all likelihood, has an IP address that either is statically configured or is assigned dynamically when you connect to your network provider. That address has the form “W.X.Y.Z,” and W is in the range of 1 to 223—which is typical of IPv4 unicast addresses. Addresses like this are said to be routable in the sense that only one PC in the entire corporate network (or the public Internet) has that address. This means that the network knows how to forward traffic destined to you by virtue of the information the routers obtain from the various routing protocols available (e.g., OSPF, RIP, BGP, etc.). Multicast addresses have the same form, W.X.Y.Z, but W, in this case, is in the special multicast address range of 224 to 239. Addresses like this don’t match any particular PC or host on a network diagram. Instead, traffic sent to these addresses must be handled according to multicast rules. Only networks set up to function with multicast can forward packets using multicast addresses. For this, you must have a multicast protocol.

Multicast Protocols Various multicast protocols exist—Protocol Independent Multicast-Sparse Mode (PIM-SM), PIM-Dense Mode (PIM-DM), and Distance Vector Multicast Routing Protocol (DVMRP). Verizon Private IP only supports PIM-SM and Source Specific Mode (SSM), by special request. This paper focuses exclusively on PIM-SM, because it is the most frequently used multicast protocol.

Page  of 9

White Paper

PIM-SM is called protocol-independent, because it works with any underlying unicast routing protocol. So, it doesn’t matter what a customer may be using to route unicast traffic, because PIM-SM can use any unicast routing table to perform its routing loop detection, forwarding, and multicast signaling duties correctly.

Multicast Signaling Figure 1 demonstrated a very simple multicast network, and, while multicast signaling really is rather complex in its execution, the essentials of it are easy to grasp. The following is an “intuitive” approach that has been simplified for better understanding. Not all details are included, so be forewarned before you set out to design a network! Figure 2 is a simple PIM-SM network with a multicast Source on the left and potential receivers “a” through “d” on the right. The devices marked as “R1” through “R4” are routers, but R4 has a special additional job as the network’s Rendezvous Point (RP). RP helps the Source and the Receivers find each other. The interfaces on R3 are designated “a” through “d” corresponding to each attached host. In this case, the network operator has multicast-enabled all the interfaces in the network and has arranged to inform all the routers where the RP is, either via static configuration or by RP discovery protocols beyond the scope of this document. While these network set-up steps are simple, most equipment does not come out of its box with these features turned on.

Potential Receivers

RP

a

R4

a R1 Source

R2

R3

b

b c

c

d d

Figure 2: Simple PIM-SM Network

Getting Ready Assume a video program is about to be transmitted, during which the Source sends the multicast program (a single copy) to the network. The receivers, if interested in viewing the show, will signal the network to receive the multicast program. At this point, the Source is not sending, and the Receivers have not joined the multicast group. User “a” decides to join the program early. If the equipment at site “a” is a PC or any computer, the host will send an Internet Group Membership Protocol (IGMP) report, when periodically polled by R3, to indicate “I want to join Group 239.4.3.1.” If there is a router at site “a” located between R3 and the user’s PC, which is usually the case, the site router will communicate with the backbone router R3 using PIM signaling. The message, which is called a “(*,G) Join message,” is sent toward the RP using information in the unicast routing table. The wildcard symbol “*” indicates that neither the receiver nor R3 knows the identity of the Source. However, the receiver does know the multicast group address, 239.4.3.1, so it is included in the Join message. The application on the PC knows the multicast address via a web application or by manual configuration. For example, maybe the user clicked on www.ceo.talk in an e-mail from HR in order to hear the program. The RP is the mediator between the Source and the Receivers who do not know about each other’s existence before signaling begins. Because the Source and Receivers need each other, they agree to “rendezvous” at the RP when it is time to activate a multicast session. The RP causes the handshake between the Source and the buyer. Once the Source and Receiver greet each other, and the routers serving the Receiver learn where the Source is, the RP really is no longer involved in the multicast data transmission.

Page  of 9

White Paper

At this point, R3 and R4 know that an interested Receiver is attached to R3, and the multicast instructions, known as routes or states, have been set up in each router. To illustrate, R3 has installed a multicast route in response to the (*,G) Join message that looks like: at R3: (*, 239.4.3.1) with outgoing interface pointing toward Receiver “a” and at R4: (*, 239.4.3.1) with outgoing interface pointing toward R3 Using R3 as the example, these multicast routes mean that any multicast traffic destined for the 239.4.3.1 multicast group that arrives on an acceptable interface will be sent to Receiver “a,” which is the only known interested Receiver at this point. To complete our example, R4 will send any multicast traffic headed for our multicast group to R3, since R4 knows that R3 has an interested Receiver indicated by the Join message that R3 received and passed on to R4. Therefore, R3 shows up in the outgoing interface list.

The RPF Check Multicast monitors the interface on which any multicast arrives to make certain the network is not experiencing an uncontrolled routing loop. The router does this by adding the expected incoming interface to its routing table or the interface on which the router expects to receive multicast traffic for a particular group. If traffic does not arrive on the expected interface, a routing loop is suspected and the traffic should be dropped (discarded). The interface that multicast should arrive on is called the Reverse Path Forwarding (RFP) interface, because the router asks itself, “When a packet arrives with Source address SA, is the interface it came in on the one leading back (reverse path) toward that Source according to my routing table? If so, allow the packet to pass. If not, something is going wrong, such as a routing loop, and the packet must be dropped to prevent further mischief.” This process is called the RPF check, which determines the acceptable interface on which multicast packets should be received. The complete multicast routing table then looks something like this: at R3: ( *, 239.4.3.1) incoming interface facing R4 (the RP) with outgoing interface facing Receiver “a” and at R4: (*, 239.4.3.1) incoming interface facing itself (R4 is the RP) with outgoing interface facing R3 Since, at this point, there is no known Source for multicast group 239.4.3.1, the RP only knows one-half of the shared multicast distribution tree that has been built—an interested receiver but no sender—so it finds itself as the expected incoming interface. However, the RP is ready to set up a connection between a Source, when it presents itself, and a Receiver. Figure 3 depicts the shared distribution tree for Group 239.4.3.1. The arrows indicate the expected path for the multicast data flow for any data that is sent to this Group.

Receivers

RP

a

R4

a R1

R2

Source

R3

b

b c

c

d d Shared Distribution Tree Figure 3: Group 239.4.3.1 Shared Distribution Tree

Page  of 9

White Paper The Source Begins to Transmit After the Receiver gets ready and the RFP check has been done, the Source begins to send traffic to the multicast Group. The router serving the Source, in this case R1, has the responsibility of registering the Source with the RP. This process is shown in Figure 4. Because the identity of the RP is known throughout the network, R1 is able to encapsulate the multicast packets and unicast them to the RP (RP role played by R4), using the RP’s unicast address as the destination address. Ordinary unicast routing must be used at this point, because the full multicast distribution network is not built yet.

Receivers

RP

a

R4

a R1 Source

R2

R3

b

b c

c

d Shared Distribution Tree Unicast Register With RP

d

Multicast Traffic Figure 4: Transmission Process Now, things get interesting. The RP knows the Receiver, and the (*,G) multicast routes are built from the RP to the Receiver, so the RP de-encapsulates the multicast from the unicast wrapping and forwards it to its outgoing interface list. R3 receives the traffic and forwards it to Receiver “a” who now sees the CEO’s speech. As far as the Receiver is concerned, the mission has been accomplished; but the network is still busy optimizing the multicast flow.

The Shortest Path Tree Now that multicast is flowing, two events occur. The first event, based on most default equipment behavior, is that R3, who now knows the identity of the Source by virtue of having seen the Source’s address in the multicast packet, sends what is known as an (S,G) Join directly to R1 so that the direct path through the network can be used for the multicast traffic. Another good reason for this action, which is called establishing the Shortest Path Tree, or SPT, is that the RP can perhaps get out of the forwarding path now that its job is done. The SPT Join and new path are shown in the Figure 5.

Page  of 9

White Paper

Receivers

RP

a

R4

a R1

R2

R3

b

b c

Source

c

d Shared Distribution Tree

d

SPT Join Message to Source Multicast Traffic on SPT

Figure 5: SPT Join and New Path The second event that happens, in parallel with the (S,G) Join being sent, is that the RP sends a registerstop message to R1 and follows up with an (S,G) Join of its own so that R1 can stop encapsulating the multicast and send it natively to the RP. Given the signaling that has just taken place, we observe that R1 is now sending multicast traffic to R4 and to R2 on the SPT. This represents duplicate traffic being received at R3, which multicast signaling will fix momentarily. In response, R3 sends a Prune message to the RP indicating that it no longer wishes to receive the multicast on the shared tree. R4 (the RP) then sends a Prune to R1 so that it can stop sending multicast traffic to R4 and only continue sending to R2. This ceases the duplicate flow and leaves only the SPT as shown in Figure 6.

Receivers

RP

a

R4

a R1 Source

R2

R3

b

b c

c

d d Multicast Traffic on SPT Figure 6: SPT Flow The appropriate (S,G) multicast routes with the correct incoming and outgoing interfaces lists are now built in R1, R2, and R3. For R1, the routing table looks like this: at R1: (S, 239.4.3.1), incoming interface facing Source with outgoing interface facing R2 To wrap up the multicast signaling example, Receivers “b” and “d” suddenly realize that they are late for the CEO’s speech so they quickly join the broadcast. Meanwhile, Receiver “c” has some kind of emergency and Page  of 9

White Paper

does not join (as indicated by the “X” in Figure 7). R3 simply adds the two new Receivers “b” and “d” to its outgoing interface list, and no other routers need to get involved, because the SPT is already set up between the Source and R3.

Potential Receivers

RP

a

R4

a R1

R2

R3

b c

Source

b

c

d d Multicast Traffic on SPT Figure 7: Receiver “c” Disconnects This example for generic PIM-SM is the process employed by customer networks. The customer’s Sources, Receivers, and RP work in concert to deliver multicast where it is wanted and to deny multicast to sites that are not interested. This helps prevent congestion where access circuits are comparatively small and the multicast bandwidth is substantial. Also, all the multicast routes and signaling are set up automatically on behalf of the Sources and Receivers in response to the router-generated Joins, Prunes, and the multicast traffic itself. The right planning and network setup will successfully deliver multicast traffic.

Private IP’s Approach to Delivering Multicast Private IP supports a customer’s multicast network transparently by leaving the Sources, Receivers, RP, and multicast Group addresses intact. Private IP multicast does this by using Generic Routing Encapsulation (GRE) of customer multicast packets within its own network provider. The simplified process at the packet level is shown in Figure 8, where Private IP multicast SA and DA (Source and Group on the left) encapsulates, or wraps around, the customer Source and Group on the right.

S (Private IP)

G (Private IP)

Private IP Verizon-Assigned Multicast Address

S (Cust.)

G (Cust.)

Native Customer Multicast Traffic

Figure 8: Customer Multicast Encapsulated in Private IP Multicast Customer multicast packets arrive at the Private IP provider edge (PE) router, receive the necessary encapsulation, and traverse Private IP. At the Private IP edge PE, the encapsulation is stripped off and the packet is delivered intact to the customer. In Figure 9, the customer multicast traffic, following the SPT, enters Private IP on the left, becomes encapsulated in Private IP multicast, gets transported across Private IP, and finally is de-encapsulated and delivered to the customer edge (CE) router. Page  of 9

White Paper

Interested Receivers

Multicast Source(s)

Customer Site

Customer RP

Customer PIM Network

CE

CE

Private IP-RP PE

Private IP PIM-SM Network

PE

Interested Receivers

PE CE

Customer SPT Private IP SPT Figure 9: Customer Multicast Traffic In the case of the encapsulating Private IP multicast, the Source is the originating PE. The network architecture requires that the internal Group address be statically assigned exclusively for a particular customer. On the other hand, the customer Source and Group are the addresses normally used by the customer that do not change because they are being supported on Private IP. A nice result of this system is that the customer can retain existing address assignments without worrying about overlapping with other customers or with Private IP internal addresses. As depicted in Figure 9, the customer PIM-SM network surrounds the Private IP PIM-SM network indicated by the nested ovals. Private IP uses its own Verizon RPs to set up the shared tree and shortest-path tree (SPT) on behalf of the customer in response to multicast Private IP provisioning and actual customer traffic. Meanwhile, the customer equipment is unaware of the Private IP multicast encapsulation and builds its own customer-shared tree and SPT transparently across Private IP.

How Does Private IP Look to the Customer Network? It is important to note that the customer is unaware of and is unable to use the Private IP RP, which is used to set up the multicast routes inside Private IP. The customer must have his own RP or RPs that reside in, and are known by the devices in, the customer network. All of the customer’s Joins and Prunes pass transparently through Private IP, as does the customer’s multicast traffic. The customer’s multicast routing tables look exactly the same across Private IP as they would in an ordinary enterprise network.

An Example Allied Carbohydrates needs to send its price schedule hourly to 500 points-of-sale in the U. S., Asia, and Europe. The rapid price updates are needed because of the volatility of the commodities that comprise Allied’s products. By updating hourly, the company has realized a healthy increase in profits. But now, the headquarters’ access circuit is becoming very congested as the computer system spools out a separate price file to each of 500 unicast hosts. The price file isn’t that large; however, when 500 copies of it have to be sent serially over a single 256 Kbps link, every hour, the office staff complains that other applications are freezing up, timing out, or that performance is labored. The basic mathematics of the situation follow. The price file is 180 KB, so it takes nearly six seconds, minimally, to send one copy of the file to one store. To send 500 copies one-by-one to each store using unicast takes about 47 minutes. This leaves very little slack time for the headquarters’ Private IP access circuit to support anything else, such as Internet browsing or e-mail, because Allied has to repeat the update hourly. Page  of 9

White Paper

The Allied CTO feels this is unacceptable. Allied is making more money with these hourly updates but, at the same time, the network is almost unusable. How much would installing an access circuit cost that is four times as fast as the current one? The CTO figures if the 47 minutes can be cut to 12 minutes, the company will be successful with that performance. But an analyst at Allied knows about Private IP multicast and figures that the cost of the larger access circuit would be higher than the multicast charge, especially if the customer router has to be upgraded to support a higher port speed. She speaks up, “Private IP multicast will enable us to send only one copy of the price schedule into the Private IP network. Private IP will replicate the data stream for us and deliver the 500 copies faster than our old system ever could. And, we don’t need a port upgrade to our router.” The CTO realizes that the analyst’s assessment is correct. It is much quicker to send 180,000 bytes into the network, once, than to send 90 million bytes, or 500 times the file size. Multicast was invented for this kind of distribution problem. Now, the headquarters’ personnel are singing the praises of the network performance with multicast.

The Multicast Benefit Multicast is different from any other kind of IP routing because of the signaling necessary to set up the multicast routes, the inherent distribution trees, and the RPF checks. Since it is unique, few IT managers fully appreciate what multicast can do. However, ordering Private IP multicast can be quite easy, and the payoff for the enterprise network can be substantial because of the amazing bandwidth efficiency. Multicast provides automatic replication of a wide variety of video, data, and voice applications. Moreover, if an enterprise is converting to Private IP from a highly meshed frame relay network, the burden of doing the multicast replication on the customer router can be greatly lessened. Let Verizon show you how multicast can benefit your company.

We never stop working for you. © 2006 Verizon. All Rights Reserved. WP10722 01/06 The Verizon and Verizon Business names and logos and all other names, logos, and slogans identifying Verizon’s products and services are trademarks and service marks or registered trademarks and service marks of Verizon Trademark Services LLC or its affiliates in the United States and/or other countries. All other trademarks and service marks are the property of their respective owners. Page  of 9