- Email: [email protected]
IPv6 over ATM flow-handling
Computer Communications 21 (1998) 1124–1130
IPv6 over ATM flow-handling M.V. Loukola*, J.O. Skytta¨ Department of Electrical and Communications Engineering, Helsinki University of Technology, PO Box 3000, 02015 HUT, Finland Received 10 March 1998; revised 20 April 1998; accepted 20 April 1998
Abstract This paper explores the ways to obtain high capacity allocation in the backbone network. IPv6 offers new possibilities for IP over ATM signalling. q 1998 Elsevier Science B.V. Keywords: IPv6; High capacity allocation; ATM flow-handling
1. Introduction IPv6 introduces a new feature called extension header. An extension header is located between the IPv6 header and the TCP header. In IPv6 it is possible to insert an arbitrary number of extension headers between the Internet header and the payload. The headers will form a daisy chain as illustrated in Fig. 1 [1]. The different extension header types are: Hop-by-Hop Options header, Destination Options header, Routing header, Fragment header, Authentication header, and Encapsulating Security Payload header [1]. With one exception, extension headers are not examined or processed by any node along a packet’s delivery path. The exception is the Hop-by-Hop Options header. They must be examined by every node along a packet’s delivery path. There are three predefined Hop-by-Hop Options: Pad1 option, PadN option, and Jumbo Payload option. Users can define their own options that they want to use. In Hop-byHop Extension headers, Option Type field’s highest-order two bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type. Hop-by-Hop Options extension headers can be set out to transport IP over ATM signalling [1–3].
2. IP over ATM Topology-based data link level forwarding is the fastest way to handle IP traffic on ATM links. This is particularly true if the connections, i.e. the flows, last for a short period * Corresponding author. E-mail: [email protected]
0140-3664/98/$19.00 q 1998 Elsevier Science B.V. All rights reserved PII S 01 40 - 36 6 4( 9 8) 0 01 7 6- 5
of time, see Fig. 2. These protocols, however, require large information bases to store the VCI/VPI mapping information. If the network domain consists of thousands of ATM routers, problems start to occur owing to scalability. If the number of hosts in a network domain exceeds a certain critical value, the percentage of payload-traffic decreases. Traffic-based protocols do not have similar problems, because the VCI/VPI values are link specific and they are only transferred between two routers. Traffic-based protocols suffer from another kind of problem: start-up delays. They originate from layer 3 processing of the trigger IP packet and transmission of allocated labels. Applications like Video on Demand (VoD) are not affected by the start-up delays, because the connection is up for several hours and the start-up delay lasts just a few initial milliseconds of the connection. See Fig. 3. Traffic-based protocols can be divided into two categories by the way they allocate layer 2 labels. Downstream label allocation method is not suitable for very short duration flows, because the layer 2 forwarding initialization takes too much time in proportion to the whole connection time. That is why flow classification or some similar method picks up just those connections that are supposed to last longer than the start-up time. Upstream label allocation has shorter start-up time, because the delay consists of just layer 3 processing of the trigger IP packet. In this way the layer 2 forwarding establishment is reasonable for even shorter connections. Upstream label allocation has clearly better performance than the downstream label allocation if the flows last for just a few packets. On the other hand, if the flows last a relatively long time the performances of upstream and downstream label allocation are almost identical.
M.V. Loukola, J.O. Skytta¨/Computer Communications 21 (1998) 1124–1130
Fig. 1. Daisy chain of IPv6 extension headers.
Despite flow length, it is impossible for a traffic-based protocol to reach the speed of topology-based protocols. However, scalability is a basic requirement for every protocol that wants to conquer the Internet. The initial start-up delay can be made shorter by improving the processor clock rate at routers or by making the layer 3 processing on hardware. If layer 3 processing time could be decreased to 50% of what it is now, the leading position that the topology-based protocols now have would be at stake. On the other hand, one can say that traffic-based protocols are not scalable because they require unique labels for each link. If the flows are shorter than the initial start-up delay, traffic-based protocols are not scalable. The allocation of backbone capacity can be made in two different ways. Figs. 2 and 3 illustrate these cases. If the capacity allocation is done according to the Fig. 2, the flows may not last more than the initial start-up delay of the traffic-based protocols. In this case topology-based protocols are the best solution. If the capacity is allocated like illustrated in Fig. 3, the flows last a long time. In this case the traffic-based protocols have almost the same performance as the topology-based protocols. In this case traffic-based protocols are the most reasonable choice. The average flow length in the Internet today is much longer than the initial start-up time of traffic-based protocols, but this might not be the case in the future. The next killer application of the Internet may be voice. Bringing voice to the Internet would cause the average flow length to increase. VoD and other multimedia services would have similar effect on the flow length. As flow length increases, the arguments for traffic-based protocols become stronger. The increasing problem will be the amount of VCs. Modern ATM chips cannot handle more than 10 000 ongoing VCs. This becomes a problem for both traffic-based and topology-based protocols if layer 2 forwarding is established for every flow.
Fig. 2. TDM-like capacity allocation.
1125
Fig. 3. FDM-like capacity allocation.
3. Layer 2 forwarding Layer 2 forwarding provides simple and fast packet forwarding capability. One primary reason for the simplicity of layer 2 forwarding comes from its short, fixed length labels. A node forwarding at layer 3 must parse a relatively large header, and perform a longest-prefix match to determine a forwarding path. When a node performs layer 2 forwarding it can do direct index lookup into its forwarding table with the short header. It is arguably simpler to build layer 2 forwarding hardware than it is to build layer 3 forwarding hardware because the layer 2 forwarding function is less complex [4]. By bypassing the conventional IP forwarding (the packet assembly/reassembly) process using cell-relaying, we could dramatically reduce both the IP packet processing delay and the queuing delay at the router [5]. Pushing traffic to layer 3 may cause congestion. If data is discarded (Hop Limit ¼ 0) or lost (buffer full) TCP will backoff [6]. 4. Previously pronounced IP over ATM protocols 4.1. IP Switching—Nokia IP routing An IP Switch implements the IP protocol stack on ATM hardware, which operates as a high performance link-layer accelerator. An IP Switch dynamically shifts between storeand-forward and cut-through switching based on the needs of the traffic. The majority of the data is switched directly by the ATM hardware, without additional IP router processing [7].
Fig. 4. IP switching—Nokia IP routing #1.
1126
M.V. Loukola, J.O. Skytta¨/Computer Communications 21 (1998) 1124–1130
Fig. 7. Tag switching. Fig. 5. IP switching—Nokia IP routing #2.
The intelligence within the IP Switch system derives from two simple protocols: the General Switch Management Protocol (GSMP) and the Ipsilon Flow Management Protocol (IFMP). GSMP controls the ATM switch engine. It is responsible for setting up, tearing down, and monitoring the status of the VCs within the ATM switch fabric. IFMP enables communications between multiple IP Switches or between hosts and IP Switches [8,9]. It associates IP flows with ATM VCs and defines the format for flow-redirect messages and acknowledgements. Figs. 4–6 illustrate the steps of ATM cut-through establishment. In Fig. 4 the second IP Switch receives the trigger IP packet (1) and performs flow classification and normal IP forwarding. As a result of the flow classification process the second IP Switch sends an IFMP redirect message to the first IP Switch (2). That message contains the VC to be used for that particular flow [7]. In Fig. 5 the first IP Switch starts to send packets belonging to that particular traffic flow on the dedicated VC (3). The third IP Switch has received the trigger IP packet (4) and performs the flow classification and as a result sends an IFMP redirect message to the second IP Switch (5). Now the ATM cut-through establishment is completed (6); see Fig. 6. The second IP Switch forwards the IP packets belonging to the particular flow on data link level. 4.2. Tag Switching Tag Switching technology is Cisco’s version of combining the performance and traffic management capabilities of data link layer switching with the proven scalability of network layer routing. A Tag Switching internetwork consists of Tag Edge Routers, Tag Switches, and Tag Distribution
Fig. 6. IP switching—Nokia IP routing #3.
Protocol (TDP) that is used to distribute tag information between devices in a tag switched Internet. Tag Edge Router and Tag Switches use standard routing protocols, e.g. Enhanced Interior Gateway Routing Protocol (EIGRP), Border Gateway Protocol (BGP), or OSPF, to identify routers through the network [10,11]. Tag Edge Routers apply tags to packets and strip them off once delivered to the destination Tag Edge Router; see Fig. 7. Tag Switches switch tagged packets or cells based on the tags. TDP is used to distribute tag information between devices in a tag switched Internet. Tag Switching is a topology-based IP over ATM protocol. The tags are assigned prior to normal traffic. Tag information is stored in a Tag Information Database (TIB) [12–14]. 4.3. Aggregate Route-based IP Switching (ARIS) ARIS uses OSPF and BGP IETF standard protocols as the basis for switching IP datagrams. ARIS establishes switched paths through a network. Integrated Switch Routers (ISRs), which are normal switches that are augmented with standard IP routing support, have IP forwarding tables that are extended to include a reference to a switch path, VCC. In this way datagrams are switched at hardware speeds through an entire ISR network [15,16]. ARIS establishes switched paths towards each unique egress ISR, which has its own egress identifier. Since thousands of IP destinations can map to the same egress identifier, ARIS minimizes the number of switch paths required in an ISR network. As Fig. 8 shows, there are three kinds of information base in each ISR. They are the routing information base (RIB), the forwarding information base (FIB), and the VC information base (VCIB). The RIB is a standard routing table augmented with egress identifiers. FIB maps the outgoing interface and downstream label with egress ID. VCIB
Fig. 8. ARIS.
M.V. Loukola, J.O. Skytta¨/Computer Communications 21 (1998) 1124–1130
1127
Fig. 9. SITA.
maintains upstream to downstream label mappings for each egress ID [15,16]. 4.4. Switching IP Through ATM (SITA) The SITA domain consists of IP routers and ATM switches. The IP routers exchange routing information using OSPF. ATM switches either participate in OSPF or they participate in PNNI Augmented Routing (PAR) with IP routers. OSPF or PAR configure the VPI tables of the ATM switches. In this way a router with a router index B can be reached via VPI ¼ B in all ATM switches; see Fig. 9 [10,17–19].
5. The advantage of IPv6 in IP over ATM protocols When using the Hop-by-Hop Options extension headers for IP over ATM signalling no extra request packets are sent. The request for label is carried within every IPv6 packet that belongs to the specified flow. The request for label resides in the packet’s Hop-by-Hop Option header. Only the label itself needs to be transferred in its own IPv6 packet from the downstream node to the upstream node. The label resides in the Destination Options header of the IPv6 packet with zero length payload. Label allocation can be made both by the downstream node and the upstream node. Downstream allocation is similar to the other designs in the way that the upstream node asks the downstream node to allocate a label for a specific flow. The upstream label allocation can be made very simple. The upstream node can pick up a label and start to send
Fig. 10. Downstream allocation #1.
Fig. 11. Downstream label allocation #2.
packets belonging to the specific flow using the label. The downstream neighbor needs to reassemble the IPv6 packet in order to make the label bindings to its Label Base (LB). In an ATM switch, the VPI/VCI bindings are link specific, so both the upstream and the downstream nodes know what labels are used and what are unused. The VPI/PCI values are only unique in the physical interface. The upstream label allocation requires some specific features from the ATM switch. It is contingent on ATM switches to keep the cells of a PDU contiguous and in sequence. That is why there is a need for a specific solution in the case of upstream label allocation [4]. 5.1. Downstream label allocation method The trigger IP packet starts the cut-through operation (1), Fig. 10. The trigger packet has a Hop-by-Hop Options header in its header chain with the Option Type 00110110 (bin). This Option Type is used for all Augmented IP Router Protocol (AIRP) messages. This is just some unique Option Type to be used. This protocol is part of the design and is needed to carry messages between the upstream and downstream node. The trigger packet carries a request for layer 2 forwarding label or layer 3 IPv6 Flow Label for accelerated layer 3 forwarding. Once the second router receives such a request it sends the label to its upstream neighbor in an IPv6 packet (2), Fig. 10. This packet also has an Options header with the Option Type 00110110 (bin). This Option header resides in the Destination Options header and contains the label to be used for the specific flow. Once the upstream router has received this packet it can start to send packets belonging to that flow labeled with the specific label (2), Fig. 11.
Fig. 12. Downstream label allocation #3.
1128
M.V. Loukola, J.O. Skytta¨/Computer Communications 21 (1998) 1124–1130
6. Label distribution in IPv6
Fig. 13. Upstream label allocation #1.
When the third router receives the trigger IP packet (4), it sends the label to its upstream neighbor router (5), Fig. 11. The second router can now start to send packets belonging to that flow on the dedicated-VC (6). The downstream label allocation process is illustrated in Figs. 10–12. 5.2. Upstream label allocation method Another way to achieve cut-through operation is to use upstream label allocation. This means that the upstream node chooses the label ( ¼ VPI/VCI) to be used. In this case the node choosing the label and the node which needs to interpret packets using that label are not the same node. When the first router receives a trigger IP packet belonging to a new flow, it allocates a label, i.e. VCI, to it. After that the upstream node is free to send the packets belonging to that flow on the dedicated VC (1). When the downstream node receives cells on the new VCI that it has no entry in its LB, it has to reassemble the IPv6 packet in order to determine where the packet is going (2). After the packet is reassembled, a next-link label is allocated and an entry is entered to the LB. After that the second router begins to send cells to the next router on this new dedicated VC (3). After the cells belonging to the flow arrive at the border node of the ATM domain (third router), the packet is once again reassembled and sent on the non-ATM link (4). The cut-through establishment is illustrated in Fig. 13. The following IP packets receive the cut-through treatment at the second router (5) as shown in Fig. 14.
Label distribution occurs between ATM switches which have been augmented with standard IP routing support. The IP routers must be able to recognize the IPv6 Option Type (00110110 bin) used in this design. Such IP routers are referred as Augmented IP Routers (AIRs). The word augmented here refers to the AIRs ability to recognize the needed IPv6 Option Type. In the downstream label allocation mode, the request for a label is passed in the IPv6 Hop-by-Hop Options header and the label is passed to the upstream node in the IPv6 Destination Options header. Both the Destination Options and the Hop-by-Hop Options headers can contain Options in the same format [1]. Labels expire when there has not been any packet carrying that specific label for 180 s. 6.1. Traffic based soft-state LB bindings The AIRP protocol exchanges layer 2 labels based on traffic like IP switching [20]. This reduces the overhead of exchanging labels between all peers in a routing domain and reduces the size of the label binding information bases in routers. Topology-based methods have the ability of forwarding all the packets on layer 2, including the first packets of each flow, whereas in traffic-based methods the first packet has to be reassembled in all the routers along the packet’s delivery path. But this was not a sufficient argument to make AIRP a topology-based protocol. Simplicity is beautiful. The nature of the bindings in the LB is soft-state because the connection is established owing to the request in the first IPv6 packet. On the other hand, there are no refreshment procedures or keep-alive messages between the neighboring AIRs.
7. AIRP AIRP is an example of how IP over ATM protocol signalling can be merged to IPv6 [21]. The AIRs need to exchange information with each other. That is why a simple AIRP is needed. The messages are transferred within the IPv6 packet’s Hop-by-Hop Options header or the Destination Options header. 7.1. Message types Three kinds of message type are defined: (1) request for label message, (2) label transfer message, and (3) label removal message.
Fig. 14. Upstream label allocation #2.
7.1.1. Request for label message This message must be within all the IPv6 packets belonging to the same flow that want special AIRP treatment. The
1129
M.V. Loukola, J.O. Skytta¨/Computer Communications 21 (1998) 1124–1130 Table 1 Format of the request for label message
Table 3 Format of the label removal message
1 st Next Header 3 rd Option Type ¼ 0011 0110 5 th Action ¼ 0000 0001 7 th Reserved ¼ 0000 0000
1 st Next Header 3 rd Option Type ¼ 0011 0110 5 th Action ¼ 0000 0011 7 th Label [15…8]
2 nd HdrExtLen ¼ 0000 0000 4 th OptDataLen ¼ 0000 0100 6 th Reserved ¼ 0000 0000 8 th Reserved ¼ 0000 0000
first packet triggers the downstream label allocation procedure. Table 1 shows the format of the Hop-by-Hop Options header. After a downstream AIR receives this message it allocates a 24-bit label to be used for the flow, and enters that label to its LB. After the label is entered to the LB, the downstream AIR sends a label transfer message to the upstream AIR. 7.1.2. Label transfer message This message is a response to the label request message. Table 2 shows the format of the Destination Options header. As the upstream AIR receives this message, it is ready to use the VCI for the specified flow. 7.1.3. Label removal message If the upstream node wants the downstream node to delete an LB binding it can send a label removal message instead of waiting the 180 s. This is desired if the number of ongoing flows is near to the maximum, but otherwise it is a waste of bandwidth. The format of the Destination Options header for the label removal message is shown in Table 3. This message is sent on default VCI. After this the downstream node deletes the binding from its LB and can make use of the same label immediately after the deletion.
8. Simulation results The IP over ATM protocols were simulated in a fixed platform illustrated in Fig. 15. The simulator is based on the performance of real ATM switches available from Cisco Systems. The throughput of layer 2 forwarding (1.357 Gbps) is taken from the LightStream 2020 Multiservice ATM Switch specifications [22]. The throughput of
2 nd HdrExtLen ¼ 0000 0000 4 th OptDataLen ¼ 0000 0100 6 th Label [23…16] 8 th Label [7…0]
layer 3 forwarding is taken from the TCP/IP Router Tests, v2.5 [23]. The throughput depends on the packet size. The average layer 3 forwarding speed is 7.25 Mbps when packet sizes of 64, 128, 256, 512, 1024, 1518 bytes are used randomly [21]. In the simulation each host has ten ongoing flows to other hosts. The destination of each flow is chosen randomly. The average flow lengths can be configured. When one flow is ended another is established. At all times each host has ten ongoing flows. Each individual packet of each flow is randomly picked from the six possible packet sizes listed above. This simulation platform gives the possibility to find the maximum forwarding speed of Router6 that is the bottleneck of the network. When the number of IP packets in the layer 3 queue of a router exceeds the buffer size the load has been too heavy. The maximum forwarding speed of the Router6 can be found by adjusting to transmitting speeds of the hosts. When the peak layer 3 queue size of the Router6 is between 90 and 100%, the forwarding speed can be considered the maximum one. The optimistic estimation of the effect of cached flowhandling (CFH) in layer 3 performance is used. An existing CFH entry in a router is estimated to decrease the layer 3 processing delay to 5% of the normal processing time. Topology-based protocols like Tag Switching, ARIS and SITA have the maximum forwarding speed in spite of flow length because the ATM switch is configured prior to the IP packet transmissions. AIRP with its upstream label allocation proves its power. See Fig. 16. AIRP is merged to the core of IPv6. This reduces processing overhead in the routers [13–16,18,24].
Table 2 Format of the label transfer message 1 st Next Header 3 rd Option Type ¼ 0011 0110 5 th Action ¼ 0000 0010 7 th Label [15…8]
2 nd HdrExtLen ¼ 0000 0101 4 th OptDataLen ¼ 0010 1100 6 th Label [23…16] 8 th Label [7…0]
9 th –24 th Source Address of the IP packet that triggered downstream node label allocation 25 th –40 th Destination Address of the IP packet that triggered downstream node label allocation 41 th –43 th Flow Label of the IP packet that triggered downstream node label allocation 45 th –48 th Reserved Fig. 15. The simulation platform.
1130
M.V. Loukola, J.O. Skytta¨/Computer Communications 21 (1998) 1124–1130
Fig. 16. Simulation results.
9. Conclusions In this paper the wide spectrum of IP over ATM protocols is studied. In addition a new protocol was introduced. The designed AIRP was merged to the core of IPv6. It utilizes the new features of IPv6, particularly the Hop-by-Hop Options extension headers. These headers contain the layer 2 forwarding request for the IP flows. Simulation results showed that the merging of AIRP to the core of IPv6 was a successful choice. It had the best performance of the traffic-based protocols. The upstream allocation method of the AIRP protocol has its own limitations that do not appear in the simulations. These are the restrictions that come from the limited VC address space of today’s ATM switches. The best layer 2 forwarding scheme would be a combination of the AIRP upstream method and the AIRP downstream method. The majority of layer 2 forwarding establishments would be done with the downstream allocation method. Several flows of bursty traffic profile would be allocated with the AIRP upstream method. These VCs would be preallocated within the augmented IP routers. The control commands or protocols that influence the chosen method are not part of the AIRP protocol.
[7] [8]
[9]
[10] [11] [12]
[13]
[14]
[15]
[16] [17] [18]
References [1] S. Deering, R. Hinden, Internet Protocol, Version 6, Specification, RFC 1883, Xerox PARC, Ipsilon Networks Inc., December, 1995. [2] C. Huitema, IPv6 The New Internet Protocol, Prentice Hall PTR, 1996. [3] R. Hinden, S. Deering (Eds.), IP Version 6 Addressing Architecture, RFC 1884, Ipsilon Networks Inc., Xerox PARC, December, 1995. [4] R. Callon, et al., A Framework for Multiprotocol Label Switching, Network Working Group, Internet Draft , draft-ietf-mpls-framework-00.txt . , May, 1997. [5] H. Esaki, et al., White Paper on CSR (Cell Switch Router) Provided by Toshiba Corporation, Toshiba Corporation, April, 1997. [6] A. Conta, S. Deering, Internet Control Message Protocol (ICMPv6)
[19] [20] [21] [22]
[23]
[24]
for the Internet Protocol Version 6 (IPv6) Specification, RFC 1885, Digital Equipment Corp., Xerox PARC, December, 1995. P. Newman, et al., Ipsilon Technical White Paper on IP Switching, Ipsilon Networks Inc., July 1996. P. Newman, et al., Ipsilons General Switch Management Protocol Specification Version 1.1, Ipsilon Networks Inc., RFC 1987, August, 1996. P. Newman, et al., Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0, Ipsilon Networks Inc., RFC 1954, May, 1996. J. Moy, OSPF Version 2, RFC 1247, Proteon, Inc., July. 1991,. Rekhter & Li, A Border Gateway Protocol 4, IBM Corporation, Cisco Systems, RFC 1771, March, 1995. P. Doolan, et al., Tag Distribution Protocol, work in progress, Internet Draft , draft-doolan-tdp-spec-00.txt . , Cisco Systems, Inc., September, 1996. Scaling the Internet With Tag Switching, White Paper, url: http:// www.cisco.com/warp/public/732/tag/pjtag_wp.htm, url valid: February 19, 1998, Cisco Systems Inc., April, 1997. B. Davie, et al., Use of Tag Switching With ATM, Internet Draft , draft-davie-tag-switching-atm-01.txt . , Cisco Systems, Inc., January, 1997. A. Viswanathan, et al., ARIS: Aggregate Route-based IP Switching, work in progress, Internet Draft , draft-viswanathan-aris-overview00.txt . , IBM Corp., March, 1997. N. Feldman, A. Viswanathan, ARIS Specification, Internet Draft , draft-feldman-aris-spec-00.txt . , IBM Corporation, March, 1997. R. Callon, et al., An Overview of PNNI Augmented Routing, ATM Forum, April, 1996. J. Heina¨nen, Updated SITA Proposal, url: http://netlab.ucs.indiana.edu/hypermail/ion/9611/0001.html, url valid: February 19, 1998, Telecom Finland, November, 1996. J. Heina¨nen, Multiprotocol Encapsulation over ATM Adaptation Layer 5, RFC 1483, July, 1993. P. Newman, et al., Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0, Ipsilon Networks Inc., RFC 1953, May, 1996. M. Loukola, Data Link Level Forwarding for IPv6 Packets On ATM Links, Licentiates Thesis, HUT, November, 1997. LightStream 2020 Multiservice ATM Switch, Cisco Brochure, Cisco Systems, Inc., url: http://cio.cisco.com/warp/public/641/16.html, url valid: July 4, 1997, September, 1995. TCP/IP Router Tests, v2.5, Digital Eq. Corp., url: http://ftp.digital.com/pub/net/ip/routing/rtests/posting-tcp-ip, url valid: February 19, 1998, Digital Equipment Corporation, 1997. K. Nagami, et al., Toshiba’s Flow Attribute Notification Protocol (FANP) Specification, RFC 2129, Toshiba Corporation, April, 1997.
IPv6 over ATM flow-handling M.V. Loukola*, J.O. Skytta¨ Department of Electrical and Communications Engineering, Helsinki University of Technology, PO Box 3000, 02015 HUT, Finland Received 10 March 1998; revised 20 April 1998; accepted 20 April 1998
Abstract This paper explores the ways to obtain high capacity allocation in the backbone network. IPv6 offers new possibilities for IP over ATM signalling. q 1998 Elsevier Science B.V. Keywords: IPv6; High capacity allocation; ATM flow-handling
1. Introduction IPv6 introduces a new feature called extension header. An extension header is located between the IPv6 header and the TCP header. In IPv6 it is possible to insert an arbitrary number of extension headers between the Internet header and the payload. The headers will form a daisy chain as illustrated in Fig. 1 [1]. The different extension header types are: Hop-by-Hop Options header, Destination Options header, Routing header, Fragment header, Authentication header, and Encapsulating Security Payload header [1]. With one exception, extension headers are not examined or processed by any node along a packet’s delivery path. The exception is the Hop-by-Hop Options header. They must be examined by every node along a packet’s delivery path. There are three predefined Hop-by-Hop Options: Pad1 option, PadN option, and Jumbo Payload option. Users can define their own options that they want to use. In Hop-byHop Extension headers, Option Type field’s highest-order two bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type. Hop-by-Hop Options extension headers can be set out to transport IP over ATM signalling [1–3].
2. IP over ATM Topology-based data link level forwarding is the fastest way to handle IP traffic on ATM links. This is particularly true if the connections, i.e. the flows, last for a short period * Corresponding author. E-mail: [email protected]
0140-3664/98/$19.00 q 1998 Elsevier Science B.V. All rights reserved PII S 01 40 - 36 6 4( 9 8) 0 01 7 6- 5
of time, see Fig. 2. These protocols, however, require large information bases to store the VCI/VPI mapping information. If the network domain consists of thousands of ATM routers, problems start to occur owing to scalability. If the number of hosts in a network domain exceeds a certain critical value, the percentage of payload-traffic decreases. Traffic-based protocols do not have similar problems, because the VCI/VPI values are link specific and they are only transferred between two routers. Traffic-based protocols suffer from another kind of problem: start-up delays. They originate from layer 3 processing of the trigger IP packet and transmission of allocated labels. Applications like Video on Demand (VoD) are not affected by the start-up delays, because the connection is up for several hours and the start-up delay lasts just a few initial milliseconds of the connection. See Fig. 3. Traffic-based protocols can be divided into two categories by the way they allocate layer 2 labels. Downstream label allocation method is not suitable for very short duration flows, because the layer 2 forwarding initialization takes too much time in proportion to the whole connection time. That is why flow classification or some similar method picks up just those connections that are supposed to last longer than the start-up time. Upstream label allocation has shorter start-up time, because the delay consists of just layer 3 processing of the trigger IP packet. In this way the layer 2 forwarding establishment is reasonable for even shorter connections. Upstream label allocation has clearly better performance than the downstream label allocation if the flows last for just a few packets. On the other hand, if the flows last a relatively long time the performances of upstream and downstream label allocation are almost identical.
M.V. Loukola, J.O. Skytta¨/Computer Communications 21 (1998) 1124–1130
Fig. 1. Daisy chain of IPv6 extension headers.
Despite flow length, it is impossible for a traffic-based protocol to reach the speed of topology-based protocols. However, scalability is a basic requirement for every protocol that wants to conquer the Internet. The initial start-up delay can be made shorter by improving the processor clock rate at routers or by making the layer 3 processing on hardware. If layer 3 processing time could be decreased to 50% of what it is now, the leading position that the topology-based protocols now have would be at stake. On the other hand, one can say that traffic-based protocols are not scalable because they require unique labels for each link. If the flows are shorter than the initial start-up delay, traffic-based protocols are not scalable. The allocation of backbone capacity can be made in two different ways. Figs. 2 and 3 illustrate these cases. If the capacity allocation is done according to the Fig. 2, the flows may not last more than the initial start-up delay of the traffic-based protocols. In this case topology-based protocols are the best solution. If the capacity is allocated like illustrated in Fig. 3, the flows last a long time. In this case the traffic-based protocols have almost the same performance as the topology-based protocols. In this case traffic-based protocols are the most reasonable choice. The average flow length in the Internet today is much longer than the initial start-up time of traffic-based protocols, but this might not be the case in the future. The next killer application of the Internet may be voice. Bringing voice to the Internet would cause the average flow length to increase. VoD and other multimedia services would have similar effect on the flow length. As flow length increases, the arguments for traffic-based protocols become stronger. The increasing problem will be the amount of VCs. Modern ATM chips cannot handle more than 10 000 ongoing VCs. This becomes a problem for both traffic-based and topology-based protocols if layer 2 forwarding is established for every flow.
Fig. 2. TDM-like capacity allocation.
1125
Fig. 3. FDM-like capacity allocation.
3. Layer 2 forwarding Layer 2 forwarding provides simple and fast packet forwarding capability. One primary reason for the simplicity of layer 2 forwarding comes from its short, fixed length labels. A node forwarding at layer 3 must parse a relatively large header, and perform a longest-prefix match to determine a forwarding path. When a node performs layer 2 forwarding it can do direct index lookup into its forwarding table with the short header. It is arguably simpler to build layer 2 forwarding hardware than it is to build layer 3 forwarding hardware because the layer 2 forwarding function is less complex [4]. By bypassing the conventional IP forwarding (the packet assembly/reassembly) process using cell-relaying, we could dramatically reduce both the IP packet processing delay and the queuing delay at the router [5]. Pushing traffic to layer 3 may cause congestion. If data is discarded (Hop Limit ¼ 0) or lost (buffer full) TCP will backoff [6]. 4. Previously pronounced IP over ATM protocols 4.1. IP Switching—Nokia IP routing An IP Switch implements the IP protocol stack on ATM hardware, which operates as a high performance link-layer accelerator. An IP Switch dynamically shifts between storeand-forward and cut-through switching based on the needs of the traffic. The majority of the data is switched directly by the ATM hardware, without additional IP router processing [7].
Fig. 4. IP switching—Nokia IP routing #1.
1126
M.V. Loukola, J.O. Skytta¨/Computer Communications 21 (1998) 1124–1130
Fig. 7. Tag switching. Fig. 5. IP switching—Nokia IP routing #2.
The intelligence within the IP Switch system derives from two simple protocols: the General Switch Management Protocol (GSMP) and the Ipsilon Flow Management Protocol (IFMP). GSMP controls the ATM switch engine. It is responsible for setting up, tearing down, and monitoring the status of the VCs within the ATM switch fabric. IFMP enables communications between multiple IP Switches or between hosts and IP Switches [8,9]. It associates IP flows with ATM VCs and defines the format for flow-redirect messages and acknowledgements. Figs. 4–6 illustrate the steps of ATM cut-through establishment. In Fig. 4 the second IP Switch receives the trigger IP packet (1) and performs flow classification and normal IP forwarding. As a result of the flow classification process the second IP Switch sends an IFMP redirect message to the first IP Switch (2). That message contains the VC to be used for that particular flow [7]. In Fig. 5 the first IP Switch starts to send packets belonging to that particular traffic flow on the dedicated VC (3). The third IP Switch has received the trigger IP packet (4) and performs the flow classification and as a result sends an IFMP redirect message to the second IP Switch (5). Now the ATM cut-through establishment is completed (6); see Fig. 6. The second IP Switch forwards the IP packets belonging to the particular flow on data link level. 4.2. Tag Switching Tag Switching technology is Cisco’s version of combining the performance and traffic management capabilities of data link layer switching with the proven scalability of network layer routing. A Tag Switching internetwork consists of Tag Edge Routers, Tag Switches, and Tag Distribution
Fig. 6. IP switching—Nokia IP routing #3.
Protocol (TDP) that is used to distribute tag information between devices in a tag switched Internet. Tag Edge Router and Tag Switches use standard routing protocols, e.g. Enhanced Interior Gateway Routing Protocol (EIGRP), Border Gateway Protocol (BGP), or OSPF, to identify routers through the network [10,11]. Tag Edge Routers apply tags to packets and strip them off once delivered to the destination Tag Edge Router; see Fig. 7. Tag Switches switch tagged packets or cells based on the tags. TDP is used to distribute tag information between devices in a tag switched Internet. Tag Switching is a topology-based IP over ATM protocol. The tags are assigned prior to normal traffic. Tag information is stored in a Tag Information Database (TIB) [12–14]. 4.3. Aggregate Route-based IP Switching (ARIS) ARIS uses OSPF and BGP IETF standard protocols as the basis for switching IP datagrams. ARIS establishes switched paths through a network. Integrated Switch Routers (ISRs), which are normal switches that are augmented with standard IP routing support, have IP forwarding tables that are extended to include a reference to a switch path, VCC. In this way datagrams are switched at hardware speeds through an entire ISR network [15,16]. ARIS establishes switched paths towards each unique egress ISR, which has its own egress identifier. Since thousands of IP destinations can map to the same egress identifier, ARIS minimizes the number of switch paths required in an ISR network. As Fig. 8 shows, there are three kinds of information base in each ISR. They are the routing information base (RIB), the forwarding information base (FIB), and the VC information base (VCIB). The RIB is a standard routing table augmented with egress identifiers. FIB maps the outgoing interface and downstream label with egress ID. VCIB
Fig. 8. ARIS.
M.V. Loukola, J.O. Skytta¨/Computer Communications 21 (1998) 1124–1130
1127
Fig. 9. SITA.
maintains upstream to downstream label mappings for each egress ID [15,16]. 4.4. Switching IP Through ATM (SITA) The SITA domain consists of IP routers and ATM switches. The IP routers exchange routing information using OSPF. ATM switches either participate in OSPF or they participate in PNNI Augmented Routing (PAR) with IP routers. OSPF or PAR configure the VPI tables of the ATM switches. In this way a router with a router index B can be reached via VPI ¼ B in all ATM switches; see Fig. 9 [10,17–19].
5. The advantage of IPv6 in IP over ATM protocols When using the Hop-by-Hop Options extension headers for IP over ATM signalling no extra request packets are sent. The request for label is carried within every IPv6 packet that belongs to the specified flow. The request for label resides in the packet’s Hop-by-Hop Option header. Only the label itself needs to be transferred in its own IPv6 packet from the downstream node to the upstream node. The label resides in the Destination Options header of the IPv6 packet with zero length payload. Label allocation can be made both by the downstream node and the upstream node. Downstream allocation is similar to the other designs in the way that the upstream node asks the downstream node to allocate a label for a specific flow. The upstream label allocation can be made very simple. The upstream node can pick up a label and start to send
Fig. 10. Downstream allocation #1.
Fig. 11. Downstream label allocation #2.
packets belonging to the specific flow using the label. The downstream neighbor needs to reassemble the IPv6 packet in order to make the label bindings to its Label Base (LB). In an ATM switch, the VPI/VCI bindings are link specific, so both the upstream and the downstream nodes know what labels are used and what are unused. The VPI/PCI values are only unique in the physical interface. The upstream label allocation requires some specific features from the ATM switch. It is contingent on ATM switches to keep the cells of a PDU contiguous and in sequence. That is why there is a need for a specific solution in the case of upstream label allocation [4]. 5.1. Downstream label allocation method The trigger IP packet starts the cut-through operation (1), Fig. 10. The trigger packet has a Hop-by-Hop Options header in its header chain with the Option Type 00110110 (bin). This Option Type is used for all Augmented IP Router Protocol (AIRP) messages. This is just some unique Option Type to be used. This protocol is part of the design and is needed to carry messages between the upstream and downstream node. The trigger packet carries a request for layer 2 forwarding label or layer 3 IPv6 Flow Label for accelerated layer 3 forwarding. Once the second router receives such a request it sends the label to its upstream neighbor in an IPv6 packet (2), Fig. 10. This packet also has an Options header with the Option Type 00110110 (bin). This Option header resides in the Destination Options header and contains the label to be used for the specific flow. Once the upstream router has received this packet it can start to send packets belonging to that flow labeled with the specific label (2), Fig. 11.
Fig. 12. Downstream label allocation #3.
1128
M.V. Loukola, J.O. Skytta¨/Computer Communications 21 (1998) 1124–1130
6. Label distribution in IPv6
Fig. 13. Upstream label allocation #1.
When the third router receives the trigger IP packet (4), it sends the label to its upstream neighbor router (5), Fig. 11. The second router can now start to send packets belonging to that flow on the dedicated-VC (6). The downstream label allocation process is illustrated in Figs. 10–12. 5.2. Upstream label allocation method Another way to achieve cut-through operation is to use upstream label allocation. This means that the upstream node chooses the label ( ¼ VPI/VCI) to be used. In this case the node choosing the label and the node which needs to interpret packets using that label are not the same node. When the first router receives a trigger IP packet belonging to a new flow, it allocates a label, i.e. VCI, to it. After that the upstream node is free to send the packets belonging to that flow on the dedicated VC (1). When the downstream node receives cells on the new VCI that it has no entry in its LB, it has to reassemble the IPv6 packet in order to determine where the packet is going (2). After the packet is reassembled, a next-link label is allocated and an entry is entered to the LB. After that the second router begins to send cells to the next router on this new dedicated VC (3). After the cells belonging to the flow arrive at the border node of the ATM domain (third router), the packet is once again reassembled and sent on the non-ATM link (4). The cut-through establishment is illustrated in Fig. 13. The following IP packets receive the cut-through treatment at the second router (5) as shown in Fig. 14.
Label distribution occurs between ATM switches which have been augmented with standard IP routing support. The IP routers must be able to recognize the IPv6 Option Type (00110110 bin) used in this design. Such IP routers are referred as Augmented IP Routers (AIRs). The word augmented here refers to the AIRs ability to recognize the needed IPv6 Option Type. In the downstream label allocation mode, the request for a label is passed in the IPv6 Hop-by-Hop Options header and the label is passed to the upstream node in the IPv6 Destination Options header. Both the Destination Options and the Hop-by-Hop Options headers can contain Options in the same format [1]. Labels expire when there has not been any packet carrying that specific label for 180 s. 6.1. Traffic based soft-state LB bindings The AIRP protocol exchanges layer 2 labels based on traffic like IP switching [20]. This reduces the overhead of exchanging labels between all peers in a routing domain and reduces the size of the label binding information bases in routers. Topology-based methods have the ability of forwarding all the packets on layer 2, including the first packets of each flow, whereas in traffic-based methods the first packet has to be reassembled in all the routers along the packet’s delivery path. But this was not a sufficient argument to make AIRP a topology-based protocol. Simplicity is beautiful. The nature of the bindings in the LB is soft-state because the connection is established owing to the request in the first IPv6 packet. On the other hand, there are no refreshment procedures or keep-alive messages between the neighboring AIRs.
7. AIRP AIRP is an example of how IP over ATM protocol signalling can be merged to IPv6 [21]. The AIRs need to exchange information with each other. That is why a simple AIRP is needed. The messages are transferred within the IPv6 packet’s Hop-by-Hop Options header or the Destination Options header. 7.1. Message types Three kinds of message type are defined: (1) request for label message, (2) label transfer message, and (3) label removal message.
Fig. 14. Upstream label allocation #2.
7.1.1. Request for label message This message must be within all the IPv6 packets belonging to the same flow that want special AIRP treatment. The
1129
M.V. Loukola, J.O. Skytta¨/Computer Communications 21 (1998) 1124–1130 Table 1 Format of the request for label message
Table 3 Format of the label removal message
1 st Next Header 3 rd Option Type ¼ 0011 0110 5 th Action ¼ 0000 0001 7 th Reserved ¼ 0000 0000
1 st Next Header 3 rd Option Type ¼ 0011 0110 5 th Action ¼ 0000 0011 7 th Label [15…8]
2 nd HdrExtLen ¼ 0000 0000 4 th OptDataLen ¼ 0000 0100 6 th Reserved ¼ 0000 0000 8 th Reserved ¼ 0000 0000
first packet triggers the downstream label allocation procedure. Table 1 shows the format of the Hop-by-Hop Options header. After a downstream AIR receives this message it allocates a 24-bit label to be used for the flow, and enters that label to its LB. After the label is entered to the LB, the downstream AIR sends a label transfer message to the upstream AIR. 7.1.2. Label transfer message This message is a response to the label request message. Table 2 shows the format of the Destination Options header. As the upstream AIR receives this message, it is ready to use the VCI for the specified flow. 7.1.3. Label removal message If the upstream node wants the downstream node to delete an LB binding it can send a label removal message instead of waiting the 180 s. This is desired if the number of ongoing flows is near to the maximum, but otherwise it is a waste of bandwidth. The format of the Destination Options header for the label removal message is shown in Table 3. This message is sent on default VCI. After this the downstream node deletes the binding from its LB and can make use of the same label immediately after the deletion.
8. Simulation results The IP over ATM protocols were simulated in a fixed platform illustrated in Fig. 15. The simulator is based on the performance of real ATM switches available from Cisco Systems. The throughput of layer 2 forwarding (1.357 Gbps) is taken from the LightStream 2020 Multiservice ATM Switch specifications [22]. The throughput of
2 nd HdrExtLen ¼ 0000 0000 4 th OptDataLen ¼ 0000 0100 6 th Label [23…16] 8 th Label [7…0]
layer 3 forwarding is taken from the TCP/IP Router Tests, v2.5 [23]. The throughput depends on the packet size. The average layer 3 forwarding speed is 7.25 Mbps when packet sizes of 64, 128, 256, 512, 1024, 1518 bytes are used randomly [21]. In the simulation each host has ten ongoing flows to other hosts. The destination of each flow is chosen randomly. The average flow lengths can be configured. When one flow is ended another is established. At all times each host has ten ongoing flows. Each individual packet of each flow is randomly picked from the six possible packet sizes listed above. This simulation platform gives the possibility to find the maximum forwarding speed of Router6 that is the bottleneck of the network. When the number of IP packets in the layer 3 queue of a router exceeds the buffer size the load has been too heavy. The maximum forwarding speed of the Router6 can be found by adjusting to transmitting speeds of the hosts. When the peak layer 3 queue size of the Router6 is between 90 and 100%, the forwarding speed can be considered the maximum one. The optimistic estimation of the effect of cached flowhandling (CFH) in layer 3 performance is used. An existing CFH entry in a router is estimated to decrease the layer 3 processing delay to 5% of the normal processing time. Topology-based protocols like Tag Switching, ARIS and SITA have the maximum forwarding speed in spite of flow length because the ATM switch is configured prior to the IP packet transmissions. AIRP with its upstream label allocation proves its power. See Fig. 16. AIRP is merged to the core of IPv6. This reduces processing overhead in the routers [13–16,18,24].
Table 2 Format of the label transfer message 1 st Next Header 3 rd Option Type ¼ 0011 0110 5 th Action ¼ 0000 0010 7 th Label [15…8]
2 nd HdrExtLen ¼ 0000 0101 4 th OptDataLen ¼ 0010 1100 6 th Label [23…16] 8 th Label [7…0]
9 th –24 th Source Address of the IP packet that triggered downstream node label allocation 25 th –40 th Destination Address of the IP packet that triggered downstream node label allocation 41 th –43 th Flow Label of the IP packet that triggered downstream node label allocation 45 th –48 th Reserved Fig. 15. The simulation platform.
1130
M.V. Loukola, J.O. Skytta¨/Computer Communications 21 (1998) 1124–1130
Fig. 16. Simulation results.
9. Conclusions In this paper the wide spectrum of IP over ATM protocols is studied. In addition a new protocol was introduced. The designed AIRP was merged to the core of IPv6. It utilizes the new features of IPv6, particularly the Hop-by-Hop Options extension headers. These headers contain the layer 2 forwarding request for the IP flows. Simulation results showed that the merging of AIRP to the core of IPv6 was a successful choice. It had the best performance of the traffic-based protocols. The upstream allocation method of the AIRP protocol has its own limitations that do not appear in the simulations. These are the restrictions that come from the limited VC address space of today’s ATM switches. The best layer 2 forwarding scheme would be a combination of the AIRP upstream method and the AIRP downstream method. The majority of layer 2 forwarding establishments would be done with the downstream allocation method. Several flows of bursty traffic profile would be allocated with the AIRP upstream method. These VCs would be preallocated within the augmented IP routers. The control commands or protocols that influence the chosen method are not part of the AIRP protocol.
[7] [8]
[9]
[10] [11] [12]
[13]
[14]
[15]
[16] [17] [18]
References [1] S. Deering, R. Hinden, Internet Protocol, Version 6, Specification, RFC 1883, Xerox PARC, Ipsilon Networks Inc., December, 1995. [2] C. Huitema, IPv6 The New Internet Protocol, Prentice Hall PTR, 1996. [3] R. Hinden, S. Deering (Eds.), IP Version 6 Addressing Architecture, RFC 1884, Ipsilon Networks Inc., Xerox PARC, December, 1995. [4] R. Callon, et al., A Framework for Multiprotocol Label Switching, Network Working Group, Internet Draft , draft-ietf-mpls-framework-00.txt . , May, 1997. [5] H. Esaki, et al., White Paper on CSR (Cell Switch Router) Provided by Toshiba Corporation, Toshiba Corporation, April, 1997. [6] A. Conta, S. Deering, Internet Control Message Protocol (ICMPv6)
[19] [20] [21] [22]
[23]
[24]
for the Internet Protocol Version 6 (IPv6) Specification, RFC 1885, Digital Equipment Corp., Xerox PARC, December, 1995. P. Newman, et al., Ipsilon Technical White Paper on IP Switching, Ipsilon Networks Inc., July 1996. P. Newman, et al., Ipsilons General Switch Management Protocol Specification Version 1.1, Ipsilon Networks Inc., RFC 1987, August, 1996. P. Newman, et al., Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0, Ipsilon Networks Inc., RFC 1954, May, 1996. J. Moy, OSPF Version 2, RFC 1247, Proteon, Inc., July. 1991,. Rekhter & Li, A Border Gateway Protocol 4, IBM Corporation, Cisco Systems, RFC 1771, March, 1995. P. Doolan, et al., Tag Distribution Protocol, work in progress, Internet Draft , draft-doolan-tdp-spec-00.txt . , Cisco Systems, Inc., September, 1996. Scaling the Internet With Tag Switching, White Paper, url: http:// www.cisco.com/warp/public/732/tag/pjtag_wp.htm, url valid: February 19, 1998, Cisco Systems Inc., April, 1997. B. Davie, et al., Use of Tag Switching With ATM, Internet Draft , draft-davie-tag-switching-atm-01.txt . , Cisco Systems, Inc., January, 1997. A. Viswanathan, et al., ARIS: Aggregate Route-based IP Switching, work in progress, Internet Draft , draft-viswanathan-aris-overview00.txt . , IBM Corp., March, 1997. N. Feldman, A. Viswanathan, ARIS Specification, Internet Draft , draft-feldman-aris-spec-00.txt . , IBM Corporation, March, 1997. R. Callon, et al., An Overview of PNNI Augmented Routing, ATM Forum, April, 1996. J. Heina¨nen, Updated SITA Proposal, url: http://netlab.ucs.indiana.edu/hypermail/ion/9611/0001.html, url valid: February 19, 1998, Telecom Finland, November, 1996. J. Heina¨nen, Multiprotocol Encapsulation over ATM Adaptation Layer 5, RFC 1483, July, 1993. P. Newman, et al., Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0, Ipsilon Networks Inc., RFC 1953, May, 1996. M. Loukola, Data Link Level Forwarding for IPv6 Packets On ATM Links, Licentiates Thesis, HUT, November, 1997. LightStream 2020 Multiservice ATM Switch, Cisco Brochure, Cisco Systems, Inc., url: http://cio.cisco.com/warp/public/641/16.html, url valid: July 4, 1997, September, 1995. TCP/IP Router Tests, v2.5, Digital Eq. Corp., url: http://ftp.digital.com/pub/net/ip/routing/rtests/posting-tcp-ip, url valid: February 19, 1998, Digital Equipment Corporation, 1997. K. Nagami, et al., Toshiba’s Flow Attribute Notification Protocol (FANP) Specification, RFC 2129, Toshiba Corporation, April, 1997.