Professional Documents
Culture Documents
WP Multicast On Verizon Private Ip en XG
WP Multicast On Verizon Private Ip en XG
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.
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 originators 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.
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 Source
Figure 1: Typical Unicast Traffic Addressing
Host B
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 programproviding 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 users 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 223which 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 dont 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 existProtocol 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 doesnt 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 networks 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.
RP R4
Potential Receivers a
a R1 Source R2 R3 b c d
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 users 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 others 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.
RP R4
Receivers a
a R1 Source R2 R3 b 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 RPs 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.
RP R4
Receivers a
a R1 Source
Shared Distribution Tree Unicast Register With RP Multicast Traffic
Figure 4: Transmission Process
R2
R3
b c d d c
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 CEOs speech. As far as the Receiver is concerned, the mission has been accomplished; but the network is still busy optimizing the multicast flow.
Page of 9
White Paper
RP R4
Receivers a
a R1 Source
Shared Distribution Tree SPT Join Message to Source Multicast Traffic on SPT
R2
R3
b c d d c
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.
RP R4
Receivers a
a R1 Source R2 R3 b 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 CEOs 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.
RP R4
Potential Receivers a
a R1 Source R2 R3 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 customers 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.
S (Private IP)
G (Private IP)
S (Cust.)
G (Cust.)
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
Customer Site
Multicast Source(s)
Interested Receivers
Customer RP
CE
CE
Private IP-RP PE PE
Interested Receivers
PE CE
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 Allieds 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 isnt 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 dont need a port upgrade to our router. The CTO realizes that the analysts 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.