A Comprehensive Comparison of IP Switching and Tag Switching

Transcription

1 A Comprehensive Comparison of ing and Tag Switching Xipeng Xiao, Lionel M. Ni and Vibhavasu Vuppala Department of Computer Science Michigan State University East Lansing, MI Abstract: Both IP switching and Tag switching were recently proposed to improve the performance of IP routers. They are all based on a multi-layer labelswapping mechanism, but their implementations are quite different. In this paper, we present an overview of both switching mechanisms, compare their key features, identify their constraints, and analyze the effect of these constraints on performance. Our study shows that both IP switching and Tag switching are better than the conventional IP routing, but neither of them is universally superior to the other. Keywords: IP router, IP switching, Tag switching, Multiprotocol Label Switching, Performance Evaluation 1. Introduction The explosion of Internet traffic has made IP routers the bottleneck of the Information Super Highway. In order to improve the router performance, many new routing mechanisms have been proposed. Among the most popular are Ipsilon s IP switching, Cisco s Tag switching, IBM s ARIS and Toshiba s CSR. Their common characteristic is a multi-layer label-swapping mechanism. It is realized by: (a) providing a semantic to bind labels to specific streams of packets; (b) using a protocol to distribute binding information among routers; and (c) forwarding packets from incoming interface to outgoing interface based solely on the label information, not the destination IP address. The forwarding can be done in hardware by the switch fabric of the router, or it can be done in software by indexing the label of the incoming packet into the Tag Information Base (TIB) to find out the corresponding outgoing interface. The result is a router with the speed of a link-layer (layer-) switch and the flexibility of a network-layer (layer-3) router. Among all the mechanisms mentioned above, IP switching and Tag switching draw the most attention. IP switching is the only one that has been implemented (at the time of this writing) []. Tag switching is publicly demonstrated in June 1997 and widely lauded in the industry. Although both IP switching and Tag switching are based on a label-swapping mechanism, the ideas and the implementations are quite different. Both of them are seeking to be the industry standard. It is imperative for a third party to do a comparison and evaluation of these two routing techniques finding out their strength and weakness, and comparing their fitness for different environments. Such a comparison will provide insights for future implementation and help to set the standard. This is the motivation of this paper. But the readers should note the difference between a product and an architecture proposal. While the proposed architecture can be very powerful and flexible, the real product based on the proposal may only have part of the functionality. The organization of the rest of this paper is as follows. We present an overview of IP switching and Tag switching in Section. Then we give a comprehensive comparison of IP switching and Tag switching in Section 3. The paper is summarized in Section 4.. An Overview of ing and Tag Switching An important concept in both IP switching and Tag switching is flow. A flow is a sequence of packets from a particular source to a particular destination sharing some common characteristics like the same source and destination addresses, port numbers, transport protocol, TTL value and type of service. In conventional IP routing, all packets of a flow must go through the IP layer. This involves hundreds of lines of software processing and introduces considerable overhead. Both IP switching and Tag switching try to improve the performance by reducing the number of packets that must go through the IP layer. In IP switching, long duration flows are identified and assigned a label. These flows are then switched at the link level (layer-). In Tag switching, it is possible to pre-distribute tags so that all the flows can be switched. These two switching mechanisms differ in their ways to bind labels (tags) to packet sequences, to distribute the binding information, and to forward packets through the routers. 1

2 .1 ing An IP-switched router consists of two parts: (1) an switch which switches packets from input ports to output ports; and () an, which uses the General Switch Management Protocol (GSMP) [1] to control the switch to establish the desired mapping from a specific flow to an output port. The also performs flow identification and uses the Ipsilon Flow Management Protocol (IFMP) [7] to communicate with adjacent routers, so that a flow can be correctly labeled and switched through the switch fabric. The generic architecture of an IP-switched router * is shown in Fig. 1. port directly by the switch fabric, bypassing the routing software and its associated processing overhead (step in Fig. d). The cut-through mechanism allows IP-switched routers to forward packets at hardware (layer-) speed. (1) () Switch (a) (3) Switch (b) (layer-3) IFMP GSMP Switch (layer-) IFMP Figure 1. The generic architecture of an IPswitched router During the network setup, each IP-switched router sets up a virtual channel for each of its physical links to be used as the default routing channel. Packets will first be sent and received through this default channel and routed normally as in conventional IP routing (step 1 in Fig. a). Meanwhile, the performs flow identification. Long-duration flows will be identified and switched directly through the switch fabric; short-duration flows are not identified and are routed normally. Once a long-duration flow is identified, the switch controller allocates a VCI for this flow and sends an IFMP message to instruct the upstream node to label that flow with this VCI (step in Fig. a). This is called flow redirection. If the upstream node complies, it will send packets of that flow via the new virtual channel (step 3 in Fig. b). Independently, the downstream node can also identify the flow and ask the current to use a specified VCI for it (step 4 in Fig. c). The IP Switch instructs the switch to make the appropriate port mapping for that flow. Packets of that flow will be switched from the input port to the output * Ipsilon Networks Inc. called a router implementing IP switching mechanism an. But switches are considered as link level (layer-) devices. To avoid confusion, we use the name IP-switched router in this paper. A Tag Switch is called a Tag-switched router for the same reason. Switch (4) (c) Figure. IP switching mechanism If a host understands the IP switching mechanism, it can directly connect to an IP-switched router. Otherwise, the host must first connect to an Gateway, which in turn connects to an IP-switched router through an interface. An Gateway converts a packet from normal format to one that is suitable for IP switching or vice versa.. Tag Switching Switch () Tag switching consists of a control component and a forwarding component. The control component is responsible for creating and maintaining a Tag Information Base (TIB) among a group of interconnected Tag-switched routers. Each entry in the TIB consists of an incoming tag and one or more (for multicast) subentries in the form of [outgoing tag, outgoing interface, outgoing link level information]. The forwarding component then uses the TIB and the tag carried by the packet to perform forwarding [3]. Tag switching supports a wide range of tag binding granularities. At one extreme, a tag can be bound to a destination prefix (network ID). Thus, packets from different hosts within a network to different hosts within another network can share the same tag. At the other extreme, a tag could be bound to an individual application flow. Thus, packets with the same source and destination IP addresses but different port numbers can have different tags. A tag can also be bound to a multicast tree. Tag-switched routers behave like normal routers in the dynamic routing protocols, such as the (d)

3 Open Shortest Path First (OSPF) and the Border Gateway Protocol (BGP), to construct the routing tables. The TIB is then constructed based on the routing information. There are three schemes for allocating a tag to a route. They are the downstream allocation scheme, the downstream-on-demand allocation scheme and the upstream allocation scheme. In the downstream allocation scheme, for each route in its routing table, the Tag-switched router creates an entry in its TIB. The Tagswitched router allocates a tag for this route and stores it as the incoming tag in its TIB entry. The Tag-switched router then advertises this binding information to the adjacent Tag-switched routers. When a Tag-switched router receives the advertisement from its downstream peer, it stores that tag as the outgoing tag in its TIB. It also fills in information about the outgoing interface and outgoing link address. The entry for that route thus becomes complete and can be used in the forwarding phase [3]. This tag allocation scheme is called downstream allocation because the outgoing tags are allocated by the downstream nodes. The downstream-ondemand allocation scheme is similar except that an upstream Tag-switched router explicitly requests the downstream peer to allocate a tag for a specific route. In the upstream allocation scheme, tags are allocated by the upstream nodes and the downstream nodes are notified. Tag binding information is distributed among Tagswitched routers using the Tag Distribution Protocol (TDP). The binding information can also be piggybacked in BGP, RSVP or PIM messages if these protocols are used. After tags are distributed, packets flowing through a specific route will carry the tag for that route. When a tagged packet is received, the forwarding component uses the tag as an index to search the TIB. If it finds an entry with the incoming tag same as the tag carried in the packet, then for each sub-entry in the TIB, the switch replaces the tag of the packet with the outgoing tag, replaces the link level information (e.g., MAC address) of the packet with the outgoing link level information, and forwards the packet over the outgoing interface. In Tag switching, hosts can only connect through a Tag Switch to a Tag-switched router. A Tag Switch converts a packet from normal format to one that is suitable for Tag switching or vice versa. Note that it is not necessary for a Tag-switched router to use as the underlying switch fabric. But if it does, it uses VPI/VCI as tags. 3. Comparison between ing and Tag Switching In this section, we present the key features and constraints of IP switching and Tag switching. 3.1 Key Features of ing and Tag Switching The key features of IP-switched router and Tag-switched router are summarized below Switch fabric and signaling Theoretically an IP-switched router can use any switch fabric. But a switch is the natural choice because labels can be carried in the VPI/VCI fields and label swapping can be done by the switch. Tag-switched router can use or other switch fabrics. Conventional routers can be software upgraded to support Tag switching. However, tag switching over may introduce the cell-interleave problem (explained later) if route aggregation is to be done. With traditional switches, some network layer forwarding is still needed with tag switching. Both IPswitched routers and Tag-switched routers control the switch by themselves, and negotiate what VPIs/VCIs to use among them using IFMP or TDP. There is no need for signaling like connection setup or deletion Label (tag) binding granularity IP switching supports two binding granularities. A label can be bound to a flow of type 1 or of type. Type 1 flows are a subset of type flows. Tag switching supports a wide range of binding granularities. A tag can be bound to an address prefix, so that traffic to a group of destinations can share the same tag. Or a tag can be bound to a specific application flow. A tag can also be bound to a multicast tree Triggers to create the binding In IP switching, the binding of a label to a specific flow is triggered by the packets of that flow. This implies that if the packet sequence is short, it may not be worthy to establish a flow for it. Those packets are routed normally. In Tag switching, tag binding is driven by control messages such as route updates, PIM join/prune, or RSVP messages. A mesh of paths is pre-established through the exchange of control packets and has nothing to do with the actual traffic of the network. Even short sequences of packets can take advantage of link-level switching Label allocation policy In IP switching, labels are allocated by the downstream IP-switched routers. The upstream node is informed by an IFMP message to use that label for the flow specified. In Tag switching, there are three allocation schemes: downstream, downstream-on-demand and upstream. These allocation schemes have been explained in Section. If Tag switching is used over, the downstreamon-demand allocation scheme is used. 3

4 3.1. Protocols for transferring binding information In IP switching, binding information is carried by IFMP. In Tag switching, if the routing protocols are BGP, RSVP or PIM, then the binding information can be piggybacked on these protocols. Otherwise, the binding information is carried by TDP over a TCP connection. The TCP connection exists as long as the binding remains valid Binding information validity In IP switching, the binding between a label and a flow is valid only for a period of time, say, 60 seconds. In order to keep that binding alive, refresh messages must be sent periodically. This implies that IP switching can change the priority of a flow dynamically while refreshing the binding information. In Tag switching, for unicast traffic, the binding is always valid after being established, unless the topology of the network changes or the TCP connection for sending TDP messages is broken. There is no need for refreshing. For multicast traffic, the bindings must be refreshed. Otherwise they will be deleted after the time-out period. The binding information validity is done consistently with the distribution of the underlying routing information Percentage of link-layer switching With IP switching, it was reported that about 90% of the packets in campus traffic could be switched with about 000 VCIs [14]. With Tag switching, if the route of the network is stable, after the tags are distributed, all the packets can be switched. However, host computers cannot connect directly to Tag-switched routers. All the traffic from/to a Tag-switched router must go through Tag Switch s, which convert a packet from normal format to one that is suitable for tag switching or vice versa. All the packets must go through the IP layer at the s. The counterpart of in IP switching is Gateway. If hosts do not support IP switching themselves, IP switching Gateways must be used to connect them to the IP-switched routers. All packets have to go through the IP layer at the IP Switch Gateways Packet TTL decrement Even when packets cut through the network layer, both IP switching and Tag switching will have their TTLs correctly decremented. But their approaches to achieve this are different. With IP switching, before flow redirection, packets are routed conventionally and the TTL values of the packets are decremented conventionally. After the redirection, the TTL field of a packet is actually not transferred. Instead, it is restored at the egress Gateway to a value that is the same should conventional IP routing be used. In Tag switching, the TTL information is provided either by the TDP hop count or in the TTL field of tag stack that is prepended to each IP packet [11]. This will affect how they handle loops. More will be discussed later in Section Binding information s consistency with routing states In IP switching, when a route of the network changes, adjacent IP-switched routers have to exchange control messages for every redirected flow that originally was associated with that route. To avoid sending lots of useless redirect messages during the transient period, no new flows that match the route are redirected for a period of N seconds, where N is long enough to ensure that the transients die out. In Tag switching, when a route changes, binding information associated with that route is deleted. Tag-switched routers also send control messages among peers to reflect the change of this particular route Multicast support Both IP switching and Tag switching can support multicast. With IP switching, receivers use the Internet Group Management Protocol (IGMP) to join a multicast group. At an IP-switched router, a multicast flow is replicated by the switch into a number of branches. Flows for branches of a multicast tree are identified and redirected by the downstream nodes in exactly the same manner as for unicast traffic. The IP-switched router can also send a copy of the mutlicast flow to the switch controller, so that branches that have not yet established flows can receive their copies through the default channel [6]. With Tag switching, when some hosts want to join a multicast group, the Tag-switched router connecting to these hosts will create a multicast state in its routing table. It will also create a multicast entry in its TIB. The Tag-switched router then allocates a tag and stores it as the incoming tag of that TIB entry. Next, the Tagswitched router sends a PIM join message to the upstream Tag-switched router. When the upstream Tagswitched router receives the join message, it stores the multicast state in its routing table. It also creates a multicast entry in its TIB and save the received tag as the outgoing tag. This tag will be used to forward multicast data packets [16]. This binding scheme is called downstream binding. Tag switching can also use the upstream binding scheme QoS support In IP switching, the switch controller can assign a priority to a specific flow. Higher priority packets will be switched to the output ports before lower priority packets if there is a contention. The priority can change dynamically when the binding information is refreshed. It is not as easy for Tag switching to support QoS unless tags are bound to application flows. In both cases, the QoS commitment must be enforced by the underlying switch fabric. Currently neither IP switching nor Tag switching can guarantee the service quality. Both IP 4

5 switching and Tag switching claim that they can support RSVP. But it is not clear how the commitments are enforced Hierarchical switching Tag switching can use a stack of tags, each of them is used in a different environment. In this case, Tagswitched routers within a domain only need to know the route information within that domain, which is much less than the route information about the whole Internet. This is a good feature in terms of scalability. But the Tagswitched routers at the border of the domain need to know all the route information and must add (or remove) tags to packets entering (or leaving) its domain. There is no such support for IP switching Loop handling Suppose router A sends packets to router B, router B sends packets to router C, and router C sends packets back to router B. There is a loop between B and C. In conventional IP routing, loops are handled by discarding packets with 0 TTL values. In IP switching, before the flow is redirected and switched, the TTL field is treated conventionally. The TTL value of every packet received will be decremented. The packet will be discarded if its TTL value reaches 0. After the flow is redirected, the TTL field of a packet is actually not transferred. Instead, it is restored at the egress Gateway to a value that is the same as if conventional IP routing were used. When router B redirects a flow from router A and sends the packets to router C, C (as the egress router at this time) will decrement their TTL value and send the packets back to B. Because these packets arrive at a different port and have different TTL value from those packets from A, they will not be treated as packets of the redirected flow. Instead, they will be treated as an unredirected flow, and the TTL value will be decremented. Eventually the TTL value will reach 0 and those packets will be dropped. In Tag switching, loops are prevented by using TDP level hop count which is carried in TDP messages or using the TTL field of the tag stack which is attached to each IP packet [4]. We should point out that loop prevention is needed only during a short period. The loop itself will soon be removed by the routing protocols like OSPF or BGP. 3. Constraints of ing and Tag Switching After comparing the key features of IP switching and Tag switching, we will further examine some of their constraints and the effect of these constraints on performance. For IP switching, an important parameter is k, the number of packets of a flow that must be routed through the IP layer before switching occurs. With a small value of k, more packets can be switched, so it is faster. But it consumes more VCIs because short flows are also identified and assigned some VCIs. With a large value of k, fewer flows will be switched, but fewer VCIs are consumed. Thus some heuristics must be developed to decide the optimal value of k. It was reported that for campus traffic, 000 VCIs are enough to reach the maximum throughput of about 90% of the packets being switched, the value of k can be set as small as. With such a small value of k, the performance difference between IP switching and Tag switching is very small. In the Internet backbone, the value of k is usually set to be large, leaving the short duration packet sequences routed conventionally. It was reported that with 16K of VCIs, by binding VCIs to flows that have or more packets flowing through the IP-switched router in 40 seconds, it is possible to have 84% of the packets switched. With 3K VCIs, the percentage can be further raised to 9% [14] *. However, the volume and diversity of the Internet is growing rapidly, it may not be long before even 64K VCIs are not enough to achieve adequate performance. IP switching requires that the network protocol be IP, and the current products are based. This limits IP switching from being widely deployed. By 1998, over 60% of the LANs will be TCP/IP connected [1]. This means that about 40% of the LANs cannot benefit from IP switching, never mention that among those 60% which speaks TCP/IP, most of them are not -based. In order to support those kind of networks, IP-switched router Gateways are introduced to convert the traffic from their original format to the one that is suitable for switching. Hosts connect to an Gateway through Ethernet or FDDI ports. The Gateway understands IFMP and can communicate with an IPswitched router through their interfaces. Besides Gateways, a dual-router network topology should be used during the migration period from IP routing to IP switching. Those hosts that are not supported by IP switching will communicate with each other through the conventional router as shown in Fig. 3. hosts Gateway IP-switched router Gateway Conventional router Figure 3. Dual router topology hosts * The bit rate of the Internet backbone traces used in this simulation was about 36 Mbps, not the typical 1 Mbps. With traces of bit rate of 1 Mbps, the number of VCIs needed will be much larger.

6 IP switching can potentially misorder IP datagrams. This is because before a flow is switched through, all packets travelling via the default channel must be switched once to enter the switch controller, routed, and switched to the output port. It is possible that while some datagrams associated with the flow are being processed by the switch controller, arriving datagrams on a new VC are switched and depart before the earlier datagrams. It was reported that in a campus environment, a single IPswitched router might cause about the same amount of datagram misordering as a whole network without IPswitched routers [14]. But this does not imply that if N IP-switched routers are used, the number of misordered packets will be N times as many. The interaction of those N IP-switched routers is unclear at this moment. IP datagram misordering will affect the performance of the transport layer. IP switching can be implemented on host computers. If all the nodes along the path to the destination support IP switching, packets can completely cut through the IP layer after the flow is established. The speed can be made very fast. Tag switching is quite different. It is a very comprehensive mechanism and does not have constraints on network protocols or underlying switch fabric. It can have different software modules to support different network protocols and hardware. Conventional routers can be software-upgraded to Tag-switched routers. However, different Tag-switched routers with different software modules can work quite differently. They may have different tag allocation and binding schemes. For example, an organization may want to bind tags to application flows while others want to bind them to address prefixes. How to make these Tag-switched routers work together can be a very difficult problem. Tag switching may not be as flexible as it seems. Even without this problem, the complexity of Tag switching may cause slow processing speed. A common tag-binding scheme of Tag switching is to bind a tag to an address-prefix (network ID). All computers within a network appear as a single entity outside the network. If different hosts in a network share the same route to another network, they can share the same tag. This is called tag aggregation. In this case, Tag switching requires many fewer tags than IP switching. In this sense, it has better scalability in the Internet than IP switching. However, since all packets from one network to computers in another network carry the same tag, it is impossible for them to be tag switched to the destination hosts. All packets must go through IP at the border gateway of the network. In this sense, Tag switching cannot work across a domain. If subnetting is done within a network, Tag switching cannot work across a subnet either. Despite all these problems, address prefix-based binding scheme greatly reduces the number of tags required and makes it possible to pre-distribute tags among Tag-switched routers. Thus short duration flow can take advantage of the link-level switching. It has some strong advantages over other binding schemes. In Tag switching, host computers cannot directly communicate with a Tag-switched router. There must be an in between, even if the hosts and the Tagswitched routers are within the same network. It is impossible for a packet sequence to cut through the IP layer completely. Packets must go through IP at the Edge Routers. But this may change in the future *. When Tag switching is implemented on switch, destination-prefix binding should not be used unless the switch is enhanced to prevent cell interleave. Even if packets share the same next hop, they must carry different tags (Fig. 4a). A large number of VCIs will be needed. The cell interleave problem is illustrated in Fig. 4b when packets sharing the same route also share the same tag. The switch interleaves cells of different packets. The egress Tag Switch does not know how to reassemble the packets. A solution to this problem is to enhance the switch to prevent cell interleave. Tag-Switched Router (a) Cell interleave Tag-Switched Router 6 6 (b) Solution #1: multiple tags Tag-Switched Router (c) Solution #: Non-interleaving switch Figure 4. Cell interleave * The authors were told by the creators of Tag-switched router that it is possible for hosts to directly communicate with Tag- switched routers. But those documents are not accessible to the public currently

7 4. Summary In this paper we have presented a comprehensive comparison of IP switching and Tag switching. The key features of both switching mechanisms were outlined. The constraints and their effect on performance were analyzed. Our intention for this work was to facilitate other researchers in further evaluating and analyzing these new routing techniques. From our study, we feel that neither IP switching nor Tag switching is universally better than the other. IP switching is simple, and it is possible to cut through the IP layer completely after the flow is identified. This can significantly improve the performance of applications like online video and audio. However, It may suffer a VCI space explosion for the future Internet traffic. Tag switching is more comprehensive and flexible. By binding a tag to a destination prefix, Tag switching requires many fewer tags. This also makes it possible to pre-distribute tags among Tag-switched routers, so that even short packet sequences can take advantage of forwarding. Tag switching can also support network protocols other than IP, and it has no restriction on the underlying switch fabric. Conventional routers can be software upgraded to Tag-switched routers. But too much functionality may make it very complex to implement and cause slow processing speed. In LANs, both IP switching and Tag switching are significantly better than conventional IP routing. On the Internet, Tag switching has better scalability than IP switching. It may be a good idea to implement IP switching in LANs to take advantage of complete cutting through IP, and implement Tag switching on the Internet. In this case, the routers that connect LANs to the Internet must understand both IP switching and Tag switching. Further quantitative evaluation is needed to analyze the performance more thoroughly. [4] B. Davie, P. Doolan, et al., Use of Tag switching With, Internet Draft, ftp://frpeng.cisco. com/tagswitch [] R. Callon, P. Doolan, et al., A Framework for Multiprotocol Label Switching, Draft MPLS Framework Document v, 4/3/97 [6] P. Newman, G. Minshall, Tom Lyon, IP switching: Under IP, Submitted to IEEE/ACM Transactions on Networking [7] P. Newman, W. Edwards, et al., Ipsilon Flow Management Protocol Specification for Ipv4, Version 1.0, RFC 193, 1996 [8] P. Newman, W. Edwards, et al., Transmission of Flow Labeled IPv4 on Data Links, Ipsilon Version 1.0, RFC 194, 1996 [9] F. Baker, Y.Rekhter, Use of Flow Label for Tag switching, Internet Draft, Apr [10] M. Ohta, H. Esaki, et al., Conventional IP over, Internet Draft, Mar. 199 [11] F. Baker, Y. Rekhter, Tag switching with RSVP, Internet Draft, Dec [1] FORE SYSTEMS, FORE and IP switching, Oct. 1996, whitep/ipswitch.html [13] P. Newman, T. Lyon, and G.Minshall, Flow Labelled IP: A Connectionless Approach to, Proc. IEEE Infocom, San Francisco, Mar [14] S. Lin, N. McKeown, A Simulation Study of IP switching, to be published at ACM Sigcomm 97. [1] Y.Ohba, H.Esaki, Y.Katsube, Comparison of Tag Switching and CSR, Internet Draft, Multi-Protocol Label Switching Workgroup, Apr [16] D.Rarinacci, R.Rekhter, Multicast Tag Binding and Distribution using PIM, Internet Draft, Dec Acknowledgment The authors want to thank Dr. Rekhter of Cisco Systems Inc., Dr. Newman of Ipsilon Networks Inc. and S. Lin of Stanford University for their help in the preparation of this paper. References [1] P. Newman, W. Edwards, et al., Ipsilon s General Switch Management Protocol Specification, Version 1.1, RFC 1987, 1996 [] P. Newman, G. Minshall, T. Lyon, and L. Huston, IP switching and Gigabit Routers, IEEE Communications Magazine, Jan. 1997, pp [3] Y. Rekhter, B. Davie, et al., Cisco Systems Tag switching Architecture Overview, RFC 10,