Implementation of Protocol Independent Multicast -Sparse Mode on IXP 1200/2400 Network Processor Platform

Transcription

1 Implementation of Protocol Independent Multicast -Sparse Mode on IXP 1200/2400 Network Processor Platform Students: Girish Dadhich, Himanshu Shringarpure, Prakshep Mehta, Supriyo Chakraborty Faculty Guide: Prof Girish P Saraph (girishs@ee.iitb.ac.in) Department of Electrical Engineering, Indian Institute of Technology, Bombay Intel Technologist: Shreekanth Patel (shreekanth.patel@intel.com) I. INTRODUCTION There has been an upsurge in the number of next generation Internet Service Providers, who are building integrated voice, video and data networks. These converged networks carry packets for multimedia applications like video conferencing, audio and video on-demand services, distance learning, Tele-medicine, web-content hosting etc. along with the usual data applications FTP, and WWW traffic. All these applications have different QoS requirements in terms of delay, jitter and packet loss rates. When the same content is to be delivered to multiple destinations, then multicast is used. This turns out to be more efficient than packet replication at the source. If point-to-point unicast is used, to reach all connected users, the overall bandwidth demands of the network will soon exceed the available link capacity, since in case of unicast the amount of network bandwidth linearly increases with the number of connected users. Internet Protocol (IP) multicast is a bandwidth-conserving technology that reduces traffic by simultaneously delivering a single stream of information to multiple destination nodes. Multicast techniques substantially reduce the overall cost at the access points. As the Internet and in many cases, the intranets in enterprises have grown in terms of traffic and the number of connected users, to support this ever-increasing and evolving set of applications in environments with a large number of high-bandwidth links, the network systems must be flexible and should be able to process packets at line rates. Traditionally, high performance routers have been designed using fixed-function ASICs that process packets at high speeds. Generally, these ASICs have long design and development times, are difficult to upgrade and expensive, whereas Network processors, meet simultaneously the demands of flexibility and high performance. Like other Linux PCs (general purpose processors), NPUs (network processor units) are fully programmable. However, they support mechanisms such as multiple processor cores per chip and multiple hardware contexts per processor core that enable them to process packets at high rates, consequently, facilitating rapid development and deployment of new services. Most of the applications supported by IP multicast are real-time and require flexible and high performance routers which support both unicast and multi cast. Hence network processors become an obvious choice of a service provider. This report focuses upon implementation of IP multicast on IXP1200/2400 and is organized as follows: In Section II we present a review of important multicast concepts and review of IP multicast schemes in Section III with emphasis on PIM-SM. Section IV discusses the architecture of IXP1200 network processor in brief. In section V we explain the implementation in detail followed by conclusions and the scope of future work. II. REVIEW OF IP MULTICAST Multicast is based on the concept of a group. An arbitrary group of receivers expresses an interest in receiving a particular data stream. This group does not have any physical or geographical boundaries. Hosts must be a member of the group to receive the data stream. Hosts that are interested in receiving data flowing to a particular group must join the group using Internet Group Management Protocol (IGMP). A given multicast addresses specifies 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) has assigned the Class D address space to be used for IP multicast.

2 All IP multicast group addresses will fall in the range of to In the standard, bit 0 of the first octet is used to indicate a broadcast and/or multicast frame. This bit indicates that the frame is destined for an arbitrary group of hosts or all hosts on the network (in the case of the broadcast address, 0xFFFF.FFFF.FFFF). IP multicast makes use of this capability to transmit IP packets to a group of hosts on a LAN segment or network. $$$ The IANA owns a block of Ethernet MAC addresses that start with 01:00:5E in hexadecimal. Half of this block is allocated for multicast addresses. This creates the range of available Ethernet MAC addresses to be e through e7f.ffff. This allocation allows for 23 bits in the Ethernet address to correspond to the IP multicast group address. The mapping places the lower 23 bits of the IP multicast group address into these available 23 bits in the Ethernet address. IGMP is used to dynamically register individual hosts in a multicast group on a particular LAN. Hosts identify group memberships by sending IGMP messages to their local multicast router. When multicast tree spans multiple administrative domains, there is typically one central node in each domain that handles the join and prune messages. Under IGMP, routers listen to IGMP messages and periodically send out queries to discover which groups are active or inactive on a particular subnet. RFC 2236 defines the specification for IGMP Version 2. In Version 2, there are four types of IGMP messages: Membership query Version 1 membership report Version 2 membership report Leave group IGMP Version 2 allows hosts to 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 IGMP Version1and unnecessary traffic can be stopped much sooner. The network is responsible for replicating the same packet at each bifurcation point (the point at which the branches fork) in the tree. This means that only one copy of the packet travels over any particular link in the network, making multicast trees extremely efficient for distributing the same information to many receivers. Multicast packets are forwarded through the network by using a multicast distribution tree. There are two types of distribution trees: source trees and shared trees. Source Trees: A source tree is the simplest form of distribution tree. The source host of the multicast traffic is located at the root of the tree, and the receivers are located at the ends of the branches. When a packet travels from a source (or root) toward a receiver, it is deemed to be traveling down the tree. If a packet is traveling from the receiver toward the source (such as a control packet), it is deemed to be traveling up the tree. Since the source tree is maintained by the source itself, rather than the central node, the receiving end can only join the source tree if it has knowledge of the IP address of the source that is transmitting the group in which it is interested. Fig. 1: Source and Shared Trees

3 Shared Trees: Shared trees differ from source trees in that the root of the tree is a common point somewhere in the network. This common point is referred to as the rendezvous point (RP). The RP is the point at which receivers join to learn of active sources. Multicast sources must transmit their traffic to the RP. When receivers join a multicast group on a shared tree, the root of the tree is always the RP, and multicast traffic is transmitted from the RP down toward the receivers. Shared trees are not as optimal in their routing as source trees because all traffic from sources must travel to the RP and then follow the same path to receivers. However, the amount of multicast routing state information required is less than that of a source tree. Therefore, there is a trade-off between optimal routing versus the amount of state information that must be kept. III.MULTICAST ROUTING PROTOCOLS The concept of forwarding multicast traffic away from the source, rather than to the receiver, is called reverse path forwarding. It enables routers to 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 to guarantee that the distribution tree will be loop-free. Reverse-path forwarding and its extension require each router to know its shortest path to every source, through the information available from the unicast routing table. If every router in the Internet uniformly supported multicast, then the multicast packet forwarding agent could simply look up the unicast routing table for shortest-path information. Unfortunately, many routers in the Internet do not support multicast. Hence extensions were developed for the hosts and routers to support multicast. These extensions are: DVMRP, MOSPF, CBT. Distance Vector Multicast Routing Protocol (DVMRP) uses the hop-count metric and provides the unicast routes that are used for reverse-path forwarding. DVMRP uses the flood-and-prune approach to determine multi cast trees, with per-source and per-group information at each router interface. It suffers from the problems of (a) periodic flooding and pruning and (b) need to store the persource, per-group records at each router. Multicast OSPF (MOSPF), adds LSP database records of routers that want to listen to groups, When a host wants to listen to a particular multicast group, it informs its local router, which then floods the network with an LSP containing this information, ensuring that when the shortest path tree is recomputed, the router will start receiving packets for that group. Thus, hosts can join and leave groups without flood-and-prune, but at the expense of a much larger LSP database. The shortest path computation must be done separately for every potential source, making MOSPF computationally expensive. The core-based trees (CBT) approach addresses the deficiencies of both DVMRP and MOSPF. It explicitly defines core routers to coordinate multicast. When a router discovers that a host attached to its LAN wants to receive packets from a group, it forwards a special packet- join request towards the core. Each router along the core, marks the interface on which the request has arrived as the interface on which to forward the packets for that group. Protocol-independent multicast is IP routing protocol-independent. It can leverage whichever unicast routing protocols are used to populate the unicast routing table, including EIGRP, OSPF, BGP, or static routes. PIM uses this unicast routing information to perform the multicast forwarding function, so it is IP protocol-independent. Although PIM is called a multicast routing protocol, it actually uses the unicast routing table to perform the reverse path forwarding (RPF) check function instead of building up a completely independent multicast routing table. 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 every 3 minutes. The routers accumulate their state information by flood and prune mechansim. These data streams contain the source and group information so that downstream routers can build up their multicast forwarding tables. PIM-DM can support only source trees. It cannot be used to build a shared tree.

4 PIM Sparse Mode (PIM-SM): Uses a pull model to deliver multicast traffic. Only networks that have active receivers that have explicitly requested the data will be forwarded the traffic. PIM-SM is defined in RFC PIM-SM uses a shared tree to distribute the information about active sources. Depending on the configuration options, the traffic can remain on the shared tree or switch over to an optimized source distribution tree. The traffic starts to flow down the shared tree, and then routers along the path 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) will send a join message toward the source and then reroute the traffic along this path. PIM-SM has the concept of an RP, since it uses shared trees. 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. 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. 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. Sparse-Dense Mode: This configuration option allows individual groups to be run in either sparse or dense mode, depending on whether RP information is available for that group. If the router learns RP information for a particular group, it will be treated as sparse mode; otherwise, that group will be treated as dense mode. IV. IXP 1200/2400 ARCHITECTURE: To meet simultaneously the demands of flexibility and high performance, an alternative to general purpose processors and application-specific integrated circuits (ASICs), referred to as network processors (NPUs), has emerged (e.g., AMCC s np7xxx, Agere s PayloadPlus, IBM s PowerNP, Silicon Access s iflow, Motorola s CPort and Intel s IXP families of NPUs). Network processors, much like general purpose processors, are programmable. However, NPUs support mechanisms such as multiple processor cores per chip and multiple hardware contexts per processor core that enable them to process packets at high rates. We have considered Intel s IXP1200/2400 for our implementation. In this section we briefly describe the architecture of IXP1200. Intel s IXP1200 network processor contains a Strong ARM core processor, six RISC CPUs (known as microengines), a proprietary bus (the 64-bit 66MHz IX bus) controller, a PCI controller, control units for accessing off-chip SRAM and DRAM memory, and a small amount (4KB) of on-chip scratchpad memory. The StrongARM Core is used for control path processing, such as handling slow path exception packets, managing routing tables, and maintaining other network state information. Microengines, on the other hand, are used for data path processing; they process multiple packets in parallel. Fig. 2: IXP1200 block diagram

5 Each microengine is associated with a private 4KB instruction store. Both the StrongARM and the microengines are clocked at 200MHz. A detailed description of the IXP1200/2400 architecture can be obtained from [Kunze]. To enable a network processor to process packets at line speeds, it is essential to hide the latency of memory accesses incurred while processing packets. To achieve this, each microengine supports 4 hardware threads. A microengine can switch context from one hardware thread to another in a single cycle when it issues a memory request. There is a hash co-processor, useful for route table look-up using hashing techniques. This speeds up the route table look-up process and also lessens the computational burden on microengines. V. IMPLEMENTATION Problem formulation: We have considered an application scenario of a P2MP (point-tomultipoint) multicast, where a single sender or source, has to send data to multiple receivers (e.g. distance learning). It is assumed that the receivers are connected to the network with links of different capacities. Figure below shows the topology used for implementation. The topology is single source shared tree and the mode of operation is PIM-SM. Fig. 3: Topology for multicast implementation The source node is S and is followed by IXP which acts as the rendezvous point (RP). R1, R2 and R3 are linux routers and would be replaced by IXPs for scaling the network to support more receivers, that wish to join the group as well as more than one multicast group as shown in the figure below. Fig. 4: Scaled network for performance evaluation

6 Fig.5: Multicast trees for Sources S1 and S2 respectively The forwarding plane functionality has been implemented on the micro-engines. This includes reception of packets, inspection of packet header, replication and forwarding of packets to appropriate output interface(s). The control path processing functionality is being implemented on the Strong ARM core. This includes polling the advertisements and pruning of entries from the route tables. The flowchart in the figure below shows the journey of a packet inside the IXP. Fig. 3: Journey of a packet inside the IXP1200/2400

7 The packet forwarding plane functions namely receive_packet(),packet_hdr() and transmit_packet() have been implemented to run on each microengine except one. Each microengine listens for incoming packets on the ports 0 to 7. When a packet arrives on a port, it is fragmented into mpackets and sent to the RFIFOs by the receive_packet micro block. It is further transferred to the SDRAM and is available for processing after assembling back into a packet. We devise a packet_hdr micro block which extracts the header of the packet and puts in a header_multicast type of structure. The multicast bit can be directly checked from this structure. If the bit is not set, the regular IP unicast lookup algorithm processes the packet. If the bit is set, the multicast algorithm inspects the packet, to check if it is a control plane (IGMP) packet or a multicast data packet. This multicast algorithm runs on the microengine which was idle and is dedicated for processing and forwarding multicast packets. For a data packet, the destination IP address is given to the hashing unit which gives the entry position in the Multicast Routing Table. This table gives the MAC addresses of the output interfaces corresponding to the Group-ID embedded in the destination IP address. Figure below shows the routing table structure. Table 1: Multicast routing table Destination ID (group ID) No. of Interfaces MAC addresses e ,0100.5e , e00.00ef,0100.5e , e00.ff17 These addresses are then mapped to the specific output port numbers, by referring to the mapping table which is shown in table below: Table 2: Outgoing interface to port number mapping MAC of O/p Interfaces e e e00.ff e00.00ef O/p port no The output port is passed on to the transmit_packet micro block. The packet is replicated by the transmit module as many times as there are output interfaces for the given Group-ID. This is achieved by controlling the pointer to the packet being transmitted. This pointer is not allowed to increment till the packet is sent on all the output ports. The TFIFOs are filled in such a way so that the transmit pointer carries on its operation in a smooth way without getting blocked at an unfilled TFIFO. The control plane functionality is being implemented on the Strong ARM core. Current implementation makes use of static routing information stored in the memory. Dynamic updates of routing tables with the join and prune messages is being implemented. VI. CONCLUDING REMARKS AND FUTURE WORK It is important to develop a cost-effective solution for IP multicast over converged networks, to enable many upcoming applications. IXP platform is an ideal solution to address this market space. We have concentrated on distance education and video services applications and chosen PIM-SM with source based trees as the most practical schemes from the applications scenarios under consideration. We are IP multicast on the IXP platform. We have completed the implementation of the forwarding plane functionality. The details of our scheme are presented here The basic functionality has been tested and has been successfully demonstrated. We are working on implementing the control plane functionality. We further intend to carry out detailed performance evaluation on bigger network topologies and multiple multicast groups. REFERENCES [1]. Developing IP Multicast Networks vol. 1- Beau Williamson, CISCO Press [2]. An Engineering Approach to Computer Networking- S. Keshav, Pearson Education [3]. IXP1200 Programing- Eric Johnson &Aaron Kunze, Intel Press

8 [4]. IXP2400/2800 Programing- Eric Johnson &Aaron Kunze, Intel Press [5]. RFC MOSPF [6]. RFC DVMRP [7]. RFC Core-based Trees [8]. RFC PIM-SM