Third 2008 International Conference on Convergence and Hybrid Information Technology

A framework of Multicast Transmission on MPLS network Using PIM-SM Protocol.

Md. Arifur Rahman Department of ECE, East West University, Mohakhali, Dhaka-1212, Bangladesh E-mail: [email protected] K. A. M Lutfullah Department of ECE, East West University, Mohakhali, Dhaka-1212, Bangladesh E-mail: [email protected] A.H.Kabir Department of ECE, East West University, Mohakhali, Dhaka-1212, BangladeshEmail: [email protected] A. S. M Samsuzzaman Department of ECE, East West University, Mohakhali, Dhaka-1212, Bangladesh E-mail: [email protected] M. Z. Hassan ICT Cell, Bangladesh Atomic Energy Commission, Ramna, Dhaka-1000, Bangladesh E-mail: [email protected] M. R. Amin Department of ECE, East West University, Mohakhali, Dhaka-1212, Bangladesh E-mail: [email protected]

Abstract
Multicast communication in the internet has been growing rapidly over the last few years. Internet applications transmit data from one sender to many receivers, In Multicast protocols while packet broadcasts to a group of receivers the total numbers of packets swamped in a network decrease. Multicast communication reduces both the time it takes to send data to a large no of receivers and the amount of network resources. It has some drawbacks on added overhead occupied in maintaining globally unique group identifiers and in order to enable addressing a subset of the group the massive amount of stateestablishment tasks are required. PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest path trees per source. It has some advantages considering the number of packets sent and simplicity of routing decisions. In this paper, we make an analysis of PIM-SM using NS according to different message types, finding that the register
978-0-7695-3407-7/08 $25.00 2008 IEEE DOI 10.1109/ICCIT.2008.372 3

message and join/prune message cause most router processing load, while the join/prune message and bootstrap message consume most network bandwidth. This report presents the prominent features of a tree-based architecture (PIM-SM) by associating with MPLS protocols. Using simulation experiments in ns2, we compare the overhead of multicast signaling of PIM-SM with MPLS.

1. Introduction:
At present almost all the traffic is moving from circuit switch or cell-based networks to packet switch network. Packet switch networks creates new demands such as Multimedia on Demand, Video Conferencing, Distance Learning, distributed network games, distributed virtual collaborations (with real time visualization and remote experiment steering), distance lectures with student participation Home Shopping etc. For transferring real-time voice or video through a TCP/IP-network with good quality, with no missing video frames or syllables, special adjustments to the networks are needed. There always has to be guaranteed bandwidth, low latency and no jitter for these kinds of applications.

Increasing the efficiency of Internet resources utilization is very important. Several evolving applications like WWW, video/audio on-demand services, and teleconferencing consume a large amount of network bandwidth. By reducing the number of packets transmitted across the network, the multicast service essentially increases the QoS given to users due to the additional available bandwidth in the network, which increases network performance. Protocol Independent Multicast-Sparse Mode (PIM-SM) [1] routes multicast packets to efficiently establish distribution trees across wide area networks. Sparse mode means that the protocol is designed for situations where multicast groups are thinly populated across a large region. Sparse-mode protocols can operate in LAN environments, but they are most efficient over WANs. PIM-SM is called protocol independent because it can use the route information that any routing protocol enters into the multicast Routing Information Base (RIB) [2].PIMSM improved the protocol by eliminating the dependence on the core (called the Rendezvous Point in PIM-SM), and also minimized the number of packets sent in a multicast transmission, along with maintaining a unidirectional routing tree. However, all tree based protocols had to ensure the global uniqueness of the broadcast addresses, which imposed a huge coordination overhead on them. Also, they were highly inefficient if a subgroup of the multicast group had to be addressed. To overcome these disadvantages, a mesh-based protocol has been proposed which eliminates the need for globally unique multicast addresses and decouples the mechanisms used for group addressing, group creation and management, and multipoint communication within a group. In this paper, we are concerned mainly in one MPLS multicast routing protocol: PIM-MPLS [3]. We propose the use of one (or more) control points in the network called Rendezvous Points (RP) in a manner similar to PIM-SM shared trees. Senders of the multicast session have to register with the RP and establish unicast LSPs with the RP. Receivers who join the session have to send their join requests to the RP which acts as a root (and the sender) of a one-tomany tree by establishing a Point-to-Multipoint (P2MP) LSP between the RP and the receiver. This architecture utilizes more than one RP to implement RP failure recovery, to provide load balancing within the domain, and to enable the extension of this framework to multiple domains by establishing LSPs between RPs in different domains. This architecture also has the advantage of using existing MPLS techniques and existing routing protocols and

requires only the addition of more management capabilities at the RPs.

2. MPLS and Multicast Communication

MPLS (Multi-Protocol Label Switching) [4] as a traffic engineering tool has emerged as an elegant solution to meet the bandwidth management and service requirements for next generation Internet Protocol (IP) based backbone networks. MPLS shows several advantages over conventional network layer forwarding [4-7]. Focusing on the advantages of the layer two switching protocol, Multicasting over MPLS networks can be benefited from the multicast reduce traffic on one hand, and MPLS flexibility, speed and quality of service on the other hand. Work on the MPLS architecture [8-11] started with unicast forwarding. Incorporating the per-flow state requirement and traffic management of multicast in a per-class architecture, such as a DiffServe [12] or MPLS network, does not solve the state scalability problem, since each router still needs to maintain separate states for individual multicast groups which pass though it. In addition, another problem is that traffic control elements may be unable to predict traffic load on every link because of multicast streams which consume network resources differently from point-to-point flows. There is recent research [13, 14] targeted to MPLS support of Differentiated Services, but only for unicast. There are also some proposals about supporting multicast in MPLS networks [15, 16], but their focus is to construct a multicast traffic engineering tree by building multicast trees immediately on L2 or mapping L3 trees on to L2. Multicast and MPLS are two complementary technologies. A framework for IP multicast deployment in an MPLS environment is proposed in [17, 18]. Since multicast communications are becoming an essential part of data networks architectures, some proposals [19-23] are advocated merging these two technologies, making multicast trees built on top of MPLS networks will enhance the network performance and present an efficient solution for multicast scalability and control overhead problems. Multicast attempts to reduce network bandwidth usage, while MPLS attempts to provide users with needed bandwidth in an appropriate switched-like manner. Core Based Tree was the earliest center-based tree multicast protocol and is the simplest. Its efficiency however depended on the choice of the core router, and it was highly inefficient if the wrong choice was made. To implement multicast efficiently, special routing protocols [24-28] are needed. Many different
4

protocols for multicasting have been proposed. There are four well-known multicast routing protocols: Distance Vector Multicast Routing Protocol (DVMRP) [21, 22], Multicast extensions to OSPF (MOSPF) [11], Core Based Tree (CBT) [6, 7], and Protocol Independent Multicast (PIM). PIM consists of two modes: PIM Dense Mode (PIM-DM) [4], and PIM Spares Mode (PIM-SM) [16]. Different techniques are used to build the multicast tree schemes. Mainly there are two types of trees, source-based tree (DVMRP, MOSPF, and PIMDM) and share-based tree (CBT, PIM-SM). The share-based tree schemes might lead to traffic concentration and additional delay. Meanwhile, it is much more efficient for lower data rate sources. On the other hand, source-based tree schemes are more complex. Meanwhile, it is much more efficient for high data rate sources and it can build a shortest path delivery tree to minimize delay.

2.1 PIM-SM MPLS

Using PIM-SM join messages [29] to distribute MPLS labels for multicast routes are proposed in [4] (called hereinafter PIM-MPLS). A piggy-backing methodology is suggested to assign and distribute labels for multicast traffic for sparse-mode trees. The PIM-SM join message should be expanded to carry an MPLS label allocated by the downstream LSR. Modifications to PIM-SM make this proposal not easily accepted by working groups dealing with multicast in the IETF. In plus, MPLS is not used with all its efficiency as a traffic engineering tool since the multicast tree still constructed using the RPF tree checking without constraints.

3. Operation of PIM-SM on MPLS Networks

The implementation of the PIM-SM protocol over MPLS networks is very simple. In the branching routers, instead of mapping the (incoming Label, incoming Interface) one (outgoing Label, outgoing Interface), the mapping is done to more than outgoing interface according to the distribution of the group members. And when a data packet arrives, instead of only doing one label switching, a replication of the data packet is done, and for each copy a label switching is done and then it is transmitted to the convenient outgoing interface, if a group consists of two members and will join a group whose source is at the root, the first member join the group, it will do the labeling in the same manner as in unicast with only one difference is that the allocated labels are then noted to be used to this (source, group) couple and this is done for future
5

members who wishes to join the same (S,G) couple. Thus the labeling when the first member M1 joins the group whose source is at root R1 is done as shown in the figure 1: In [30], the labeling is done from the downstream member up to the source. When another member wishes to join the same group, the labeling will be done in the same manner from the member toward the source. But when it first reaches a node which is already a tree node, it will stop and this tree node is now a branching node. A branching node must contain one (incoming label, incoming interface) but two or more outgoings. And therefore the labeling when M 2 join the (S, G) group is done as follows: i. The upstream labeling is done from the new member M 2 until reaching the router R3.the router R3 is already a tree node, and therefore no further upstream labeling is done. The R3 will then be a branching router and therefore corresponding to the (S, G) incoming label, two outgoings will occur. ii. The data forwarding is done similarly as in the unicast mode. When the source wishes to transmit data to a group, it will lookup in its information base, find the label corresponding to the group, and labels the data packets and transmit them toward the outgoing interface. All intermediate routers have only to switch the label, and forward the packets, exactly as in unicast. In case of a branching node, it need to do a replication of the packet as many times as there are outgoing labels in its information base, and for each packet copy it will do the label swapping and transmit it the respective outgoing interface. iii. As for the pruning, it is done also from the Pruned member and up toward the source. At each node a label de-allocation is done until reaching either the source or a branching node. If it reaches a branching node, only the corresponding (outgoing interface, outgoing label) is removed and branching node will remain a tree node.

Figure 1: Operation of PIM-SM on MPLS Networks

4. Simulation and Result

Below the topology is created using NS2 so that multicast packets can efficiently follow distribution trees across the networks. The simulation has been developed to emphasize the impact of PIM-SM protocol over MPLS network. In this experiment, one shared tree, rooted at node 0 acts as Rendezvous Point 0 and all members join with it. Two sources: node 3 and node 9 are generating CBR traffic through this shared tree. Couple of seconds later one member joins with one source and another one joins with the other, creating two source-based trees. Destination nodes are considered as Node1, 4,5,10 and Node11. The following parameters have used in the configuration: Access-link bandwidth: 1.5 Mbps Access-link delay: 10 ms Packet size: 1460, 830 and 180 (in bytes) Queue management: DropTail in the access link. Total Simulation time is considered 5 unit times. The starting times of the sources are evenly distributed in the interval 0s 1s.

Figure 3: Packet received level of MPLS Network without PIM-SM protocol.

Figure 4: Packet received level of MPLS Network with

PIM-SM protocol.

Figure 2:Experimental Topology

5. Results and Analysis

It is observed that for traffic congestion, significant amount of packets are dropped during transmission without applying PIM-SM protocol. Figure 3 shows that the level of received packets (in mega bytes) at the destination nodes 1,4,5,10 and node 11 .The received packets are fluctuating for MPLS network where as a consistent level of packets are received when PIM-SM protocol is used. As a result, packets received level improved when PIMSM protocol applied shown in figure 4. Figure 5: Packet drop of MPLS Network without PIMSM protocol.

The graph 1 (below) shows the characteristics of transmission delay of two different situations. One is: when PIM-SM protocol is not applied transmission delay increases and another reduces the delay after applying PIM-SM protocol. PIM-SM needs less congestion window size to transfer data to the destination node; as a result, PIM-SM able to hold the same window size after the dropping of data.

[3]. Farinacci, D., Rekhter, Y., Rosen, E.: Using PIM to distribute MPLS labels for multicast routes. IETF Internet draft (2000).

[4].

Rosen, E., Viswanathan, A., Callon, R.: Multiprotocol label switching architecture. IETF RFC 3031 (2001). [5]. Awduche, D., Malcom, J., Agogbua, J., ODell, M.: Requirements for Traffic Engineering over MPLS. IETF RFC 2702 (1999). [6]. X. Xiao, A. Hannan, B. Bailey, and L. Ni. Traffic engineering with MPLS in the Internet. IEEE Network, 14(2):2833, March/April 2000.

Figure 6: Transmission delay of PIM-SM comparing to

the unicast TE of MPLS.

6. Conclusion
In this paper, we showed the framework of PIMSM protocol in a simple manner using MPLS LSP between the branching node routers of a multicast tree in order to reduce routing states in intermediate routers and to increase scalability. We defined multicast traffic engineering and compared it with unicast traffic engineering. We associated MPLS which reduces the massive amount of stateestablishment tasks to enable addressing a subset of the group identifiers. We studied merging multicast and MPLS as traffic engineering tool. It built unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally created shortest path trees per source. On one hand we used the best paths tree (which coincides with the shortest paths tree in absence of any traffic engineering constraints) to forward packets and on the other hand we used the fast label switching technique of MPLS in the routers. We noticed a reduction in size of the multicast routing tables compared to the other multicast MPLS approaches. We also noticed a faster packet processing time due to the use of the label switching technique of MPLS routers. Finally we conclude that the PIM-SM protocol seems to be promising and can adapt a possible implementation of the multicast traffic engineering in the Internet.

[7]. A. Boudani, C. Jawhar, B. Cousin, and M. Doughan. A simulator for multicast routing over an mpls network. Technical report 1493, IRISA, October 2002. [8]. IETF MPLS Working Group, http://www.ietf.org/html.charters/mpls-charter.html. [9]. MPLS Research Center, http://www.mplsrc.com. [10]. B. Davis and Y. Rekhter, MPLS Technology and Applications. Morgan Kaufmann, 2000. [11]. V.Alwayn, Advanced MPLS Implementation:. Cisco Press, 2002. Design and

[12]. S. Blake, D. Black, and et al. Architecture for Differentiated Services. IETF RFC 2475, 1998. [13]. L. Faucheur and et al. MPLS support of Differentiated Services. Internet draft: draft-ietf-mplsdiff-ext-09.txt, Apr. 2001. [14]. S. Ganti, N. Seddigh, and B. Nandy. MPLS support of Differentiated Services using E-LSP. Internet draft: draft-ietf-mpls- diff-ext-00.txt, Apr. 2001. [15]. D. Ooms and et al. Framework for IP-multicast in MPLS. Internet draft:draft-ietf-mpls-multicast-05.txt, 2001. [16]. D. Ooms, R. Hoebeke, P. Cheval, and L. Wu. MPLS multicast traffic engineering. Internet draft: draft-oomsmpls-multicast-te-00.txt, 2001. [17]. Ooms, D., Sales, B., Livens, W., Acharya, A., Griffoul, F., Ansari, F: Overview of IP Multicast in a Multi-Protocol Label Switching MPLS Environment. IETF RFC 3353 (2002) [18]. Ooms, D., Livens, W.: IP Multicast in MPLS Networks. Technical leaflet, Alcatel Corporate Research Center (1999). [19]. A. Acharya and F. Griffoul, IP Multicast Support in MPLS, Proc. of IEEE ATM Workshop, 1999.

7. References
[1]. D. Estrin et al. Protocol Independent MulticastSparse Mode (PIM-SM): Protocol Specification. IETF RFC 2362, 1998. [2]. Ajoy Frank, Ajay D. Bharadwaj,Performance Analysis of Multicast Protocols(PIM-SM and Mesh).

[20]. D. Ooms and W. Livens, IP Multicast in MPLS Networks, Proc. of High Performance Switching and Routing, 2000. [21]. D. Ooms et al., MPLS for PIM-SM, draft-oomsmpls-pimsm-00.txt, Work in progress. [22]. D. Farinacci, Partitioning Label Space among Multicast Routers on a Common Subnet, draft-farinaccimulticast-label-part-00.txt, Work in progress. [23]. D. Farinacci et al., Using PIM to Distribute MPLS Labels for Multicast Routes, draft-farinacci-mplsmulticast-02.txt, Work in progress. [24]. A. Ballardie, Core based trees (CBT version 2) multicast routing protocol specification, RFC 2189, 1997. [25]. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei, Protocol independent multicast sparse mode (PIM-SM): protocol specification, RFC 2362, 1998.

[26]. V. P. Kompella et al., Multicast routing for multimedia communication, IEEE/ACM Transactions on Networking, Vol. 1, 1993, pp. 286-292. [27]. J. Moy, Multicast extensions to OSPF, RFC 1584, 1994. [28]. D. Waitzman, C. Partridge, and S. E. Deering, Distance vector multicast routing protocol, RFC 1075, 1988. [29]. Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., Wei, L.: Protocol Independent Multicast- Sparse Mode (PIM-SM): Protocol Specification. IETF RFC 2362 (1998) [30]. C. Callegari and F. Vitucci PIMSM-MPLSoNS.pdf, 2002.