IP Switching — ATM Under IP April 9, 2009

Point of the paper:

1. This paper presents a case for using ATM in today’s Internet.  It shows a way to leverage the benefits that ATM protocol at layer 2 provides for real-time and large flows. To overcome the high connection overhead for smaller flows, the system falls back to the packet forwarding by routers at layer 3 for such flows.
2. What I liked most about the paper is that the authors soundly argue that the earlier versions of ATM which presented an opaque cloud to the IP layer (by hiding the underlying network topology) did so at a substantial connection management overhead and duplication of work. They pinpoint this as one of the important reasons why ATM hasn’t picked up on the Internet scale. We have seen the proof of IP scaling to Internet, despite teh popular Ethernet at layer 2 not providing such an abstraction.
   Eg: DNS involves sending and receiving a single packet, for which setting up of ATM virtual connection is wasteful.
3. To show to the networking community, the seamless manner in which IP and ATM can co-exist in the network. IP maintains its connectionless character by soft-state routing decisions at software. Once a flow is classified, ATM is used to deliver packets at line speed at hardware level.

Concerns/problems with the paper:

One definite concern is: imagine a router that has a number of large active flows at peak time; the number of connections involving that router would be pretty high. This brings back to table several criticisms against ATM in the first place — how to recover/reconstruct the connection book-keeping on the router failure, how best to avoid duplicaton of work between IP and ATM. The other concern — as the authors admit — is that host-pair flows do result in a lot of connections. Coming up with a classification model to reduce that is a challenge, since it is potentially application-dependent.

Future research:

Today, ATM is far from being a competitor to Ethernet at Layer 2. This paper opens up enormous opportunities for future research, precisely because ATM has not been widely deployed across the Internet yet.  The benefit of this is that new ideas can quickly be tried out and included in the real implementation if they are beneficial.

So far, I think, the reason network designers decide against implementing ATM is that it presents unnecessary overhead due to its connection maintenence. This paper makes headway in retaining the benefits of both worlds — hardware connection-oriented switching and software connectionless forwarding. Further research on wide deployment is welcome.

IP Switching – ATM Under IP April 9, 2009

The most interesting aspect of the work is that the authors have integrated IP which is a Layer 3 connectionless protocol with ATM hardware which operates in Layer 2 in a connection oriented fashion. The paper provides useful insight into classification of network traffic into flows for which packets can then be routed along particular paths in the network. The authors have identified the importance of separating the functionality of ATM labeling (deciding the routes) from the switching functionality which allows them to basically use Layer 3 routing protocols to decide labels and use the existing layer 2 hardware for switching.

At the time the paper was written, hardware for Layer 3 routing was significantly costlier and less scalable as compared to hardware for Layer 2 switching. The paper describes a methodology to use the existing Layer 2 ATM hardware, but augment it with software that uses Layer 3 and establish ATM connections to transport connection less IP packets over the ATM network. ATM and IP both have their own routing protocols.  Running IP over ATM would require the use of one of the routing protocols or coordination between the two which can be an overhead. The authors chose to use the routing functionality of IP.

The authors separated the routing functionality of IP, but they had to use the existing labeling technique of the connection oriented ATM network to implement the routes. For this, they mapped individual flows with different ATM VCI’s on a per hop basis to forward the packet. With their ATM implementation, the hardware switching can be setup only after the next hop identifies and indicates the VCI to be used. So until this switching or ATM ‘connection’ is setup, all the packets are routed by IP which is running in software. So this is a slow path and cannot support traffic as fast as the hardware.

Also, IP packet headers were stripped of the flow identifier fields at the first switch which switched in hardware and the checksum decremented by the TTL value. The IP header would be reconstructed at the last hop when the packet is leaving the ATM network based on the known value of the fields including TTL. The authors state that stripping of the IP header fields was done for security purposes.

Their work seems to have inspired several efforts toward flow classification for ’same path’ forwarding in the connectionless IP framework . Separating the functionality of routing decisions to the slow path or software and enforcing the routes through the fast path in hardware is another feature that is widely used. Among recent research efforts, the OpenFlow project from Stanford shows remarkable similarity to the work in this paper.

One argument against the paper is that the authors do not provide any analysis regarding the scalability of VCI’s on each switch. Since their IP headers are removed and TTL is not actually decremented at each hop, no aggregation of IP flows is possible since TTL has to be rewritten for each individual flow at the last hop. In the evaluation, the authors do not indicate how much the slow path (using IP based software forwarding) affects performance. Slow path might limit performance when several ports share the processor that runs the software for the slow path. So there is also the issue of slow path affect the number of ports that can be supported on a single switch. It is interesting to note that with their approach, the flows with very few packets were actually handled entirely in software since it was not possible to setup default forwarding for them along the fast path (since TTL would be different for each of the flows). So with their approach, the first packet from every flow would have to go through the software/slow path. Thus while improving the bandwidth of ‘large’ flows, they actually increased the latency of the ’small’ flows. It would have been interesting to see the interplay of their implementation with IP running on other layer 2 hardware/protocols – How is performance affected by transferring IP packets to other types of layer 2 networks etc.

One possible research question would be to devise a methodology to aggregate the flows on a coarser granularity than described in the paper. Sending the IP headers along with the packet would help solving this issue although the security concerns described in the paper with this approach would have to be addressed.

IP Switching – ATM Under IP April 9, 2009

This paper proposes the integration of connection IP routing with fast connection oriented Asynchronous transfer mode (ATM) hardware. It uses a soft-state in the ATM hardware to cache the IP forwarding decision. The paper claims that other proposals to support IP routing over ATM network hide the real network topology from the IP layer by treating the data-link layer as a large opaque network cloud and the approach adopted in this paper will alleviate these concerns. It aims to harness the benefits of high capacity, bandwidth scalability and ability to support multiservice traffic provided by ATM. The authors adopt a flow classification approach to gain benefit of the switching hardware for associating an IP flow with a specific ATM virtual circuit.

The flow classification is provided using port-pair flow and host-pair flow. The flow classifier inspects the contents of the fields that characterize the flow and makes its decision based upon a local policy. A flow management protocol is provided in which the IP switch controller assigns a free Virtual circuit identifier (VCI) label to the input port on which the flow is received and a free label on its control port. A redirection message is then sent other to the upstream node direct the further traffic through this interface which can be directly switched in ATM hardware. The real benefit comes when the downstream node also redirects the flow to a specific VCI as the further traffic belonging to this flow can be directly switched within the ATM hardware without the involvement of IP switch controller. Further provisions have been made in the paper to provide the same Time to Live (TTL) in the flow identifier as it would have been if it were forwarded hop-by-hop. The checksum is taken care of by subtracting the TTL value at the origin of the switched flow to emulate the behavior of hop-by-hop when destination is reached. The authors strive for providing robustness to the protocol by introducing an adjacency protocol which enables a node to be sure that its neighbor has not changed. The lifetime of the inconsistent state in the network is limited by associating lifetimes with redirection messages. Further concepts of receiver initiation, point-to-point, multicast and Quality of service (QoS) have been discussed in relation to the discussed protocol. Further host-pair simulation experiments have been performed and it is shown that ATM switch discussed can handle approximately 3.7 times more traffic. However, the host-pair flow results in a large number of connections which is a big drawback.

IP Switching – ATM Under IP April 9, 2009

Three major contributions:

1. Provided a method to support IP switching using ATM hardware, integrating IP with layer 2 hardware.
2. Policy driven flow classification and routing.
3. Policy driven QoS.

The most glaring problem with the paper:

Would IP switching using ATM hardware scale to the size of the Internet? In their simulation they used trace data from the current Internet, but if you imagine a network that only uses IP switching over ATM hardware implementing a large number of complex policies, then traffic patterns could look different. How complex does the ATM hardware become at this scale?

Future research implications:

The idea of flow classification, policy driven QoS, and policy driven network managing have taken ideas from this concept. In order to run real time applications over the Internet, such as VoIP or streaming video, certain QoS levels must be met. Different applications can require vastly different communication requirements. If the Internet wants to provide a more reliable, better suited service for real time applications, then it needs to cater to an application’s specific need on top of the current general requirements.

IP Switching – ATM Under IP April 9, 2009

The paper “IP Switching – ATM Under IP” proposes a performance improvement to IP routing in large-scale networks by using existing ATM technology. Because IP Routers were hitting a performance limit due to their design, the authors propose to use the (then) lower-cost, off-the-shelf  hardware of ATM switches to improve IP performance. They give a localized protocol for a hybrid router which can perform ATM switching and IP routing, which establishes ATM connections for longterm IP conversations. Furthermore, two different classification approaches are investigated, classification based on conversation length and on application type. This paper also includes a quantitative study of how existing links can gain performance by those hybrid approaches, the authors report a performance gain ratio around 3 – 3.5.

In more general terms, this paper gives a mapping of the connection-less, independent approach of IP routing to the connection-oriented, managed approach of ATM switching and highlights the benefits of employing ATM switching for longer IP conversations due to the more manageable ATM switching approach.

The most obvious problem seems to be the missing quantitative comparison to other approaches, they present a few numbers on different technologies in chapter 7, but don’t give a specific outlook on the scalability of other solutions, they don’t present how far each of the approaches goes when scaling over more than one order of magnitude.

Future work would include looking at hybrid networks, where IP routing and ATM switching can be selected by the end-nodes based on application type and also a comparative study on different approaches of performance speed-up on routers including an investigation on how far each of the approaches may take router speeds.

IP Switching – ATM Under IP April 9, 2009

Important:

Integration of ATM at layers 2 and IP at layer 3 provides a performance enhancement. Performance of IP traffic over ATM networks is dramatically improved. Routing processes are freed of making routing decisions and transport capacity is saved by the reduction in header bytes, once a flow is classified and switched. Wide area connections can be switched rather than routed. Simulations on packets traces show a 3.7 times improvement.

Management burdens are greatly reduced. The ATM network is completely maintained by the IP routing and GSMP integration. The ATM network does not require separate addressing or routing in order to support IP traffic. LAN emulation service is not required.

Problem:

Integration with ATM protocols locally has not been addressed. ATM supports additional services, e. g., voice, video, circuit emulation. ATM routing may be required to support native ATM applications. How does IP switching and GSMP integrate with local ATM routing?

Future:

Addressing the integration with local ATM layer routing is required.

UDP is treated as messaging whereas today it is used for real-time traffic. The analysis needs to be repeated to include the voice and video traffic carried by UDP in modern networks.

IP Switching: ATM Under IP April 9, 2009

In this paper the authors talk about a switch-based technique for obtaining higher bandwidth compared to processor based routers of the day. They do so by discarding ATMs connection-based state and maintaining IP’s connectionless state, thus preserving IPs flexibility and simplicity. They utilize existing switch-based ATM hardware, thus achieving higher bandwidth than IP routers of the day. Several important points of the paper are:

1. The concept of flows helps preserve the connection-less notion of IP in the connection oriented ATM hardware. Upon detecting a flow, there will be a connection established on the ATM switch, thus giving the flow a higher bandwidth by using the efficient hardware. Short bursts of traffic would use IP forwarding, thus avoiding the cost of establishing the ATM connections.  In the case of a link failure, the switch can go back to using IP forwarding, without requiring to go through the cost of re-establishing all lost connections.
2. The concept of flows makes it easier to offer QoS. The authors discuss two types of QoS, contract based and policy based. In contract based service, the switch trusts the application and allows it to choose its own QoS requirements. In policy based service, an administrator configures the switch for QoS. In both cases, the existence of flows makes it easier to apply a policy to specific flows. Furthermore, flows are given lifetimes after which if there is no activity on the flow
3. The paper tends to favor the end-to-end argument by allowing each switch to make local decisions regarding the creation of connections. By placing this responsibility on the end points (the switches), the IP switches can choose what’s best for them, without the need to accept the creation of a flow as dictated by the network.

One glaring problem is that there is not enough data for the simulations described in the paper. Most of the experiments are based on short samples of data, representing the network for only a few short minutes. Also when dealing with multicast, the implementation requires establishment of point-to-multipoint connections for each sender. This might cause the creation of too many connections when dealing with multicast messages. There is not enough analysis provided whether the creation of so many connections hinders multicast performance or not.

The authors choose to use the existing ATM hardware switches because it is an already existing solution that is relatively cheap. Further research could be investigating a new hardware for the IP switch without reusing existing ATM hardware. If the IP switch is designed on its own dedicated hardware, it could be more efficient. More research needs to be done to determine the best flow detection algorithms. Another possibility would be addition of a protocol where the application can explicitly tell the switch if it requires the creation of a flow.

IP Switching: ATM Under IP April 9, 2009

The paper proposes the idea of using ATM switching under IP to improve the performance of the internet. Conventionally packet switching has been done in the IP layer 3 in software on a next hop basis. Due to the growing size and complexity of the internet, this method is becoming more inefficient due to the high overhead in the layer 3 processing. The hardware switch on the other hand can forward packets at a much faster speed than the IP at a much lower cost. This cost to performance ratio has lead to the idea of packet switching under the ATM to achieve the efficiency of hardware data forwarding. To be compatible with the notion of connectionless state of IP, the packet switching under ATM provides a soft state to be associated. Thus this state can be used at the discretion of the IP switch controller which can chose to use the state information. The state is basically a set up of a virtual circuit based on a flow. Thus before the flow is started, the circuit is marked with a virtual circuit identifier (VCI) and appropriate mappings between the input and output port are stored in the routers based on this  VCI. When the flow starts, the packets can then be more efficiently forwarded by the ATM switch using the flow identifier (VCI) without consulting the IP layer. For VCIs to be reusable, such virtual circuits are teared down after long enough time after which they need to be set up afresh. Packet switching under ATM can also provide the quality of service by maintaining the QoS information with each flow.

The problem addressed in the paper is the inefficiency of switching every packet under the control of IP. The ATM hardware based packet switching can forward data at much faster rate and at lower cost. But the robustness and flexibility of the IP comes from the basic assumption of no connection state underneath. Introducing the notion of a flow state may contradict that. Further more, in case of a node or link failure, IP can very flexibly find a path and route around the failure. Flows established based on VCI on the other hand needs such paths to be teared down and re-established leading to much over head. Also the flow based approach is mostly effective in case of bulk data transfer where the successive packets closely follow one another. For interactive applications where data transfer is small but intermittent, maintaining a flow may be wasteful and costly.

The paper really attempts to combine the best of both worlds, viz., the flexibility of IP switching with the efficiency of ATM switching. The ideas of the paper can be extended to provide the functionality of the IPs in the ATM layer, thus even making it more flexible and fault tolerant. With hardware becoming cheaper, the idea of switching in hardware efficiently is definitely a plausible alternative. IP layers implemented totally in hardware can also provide similar efficiency and is another alternative.

IP Switching – ATM Under IP April 9, 2009

(i) Three most important things

1. Hiding the real network topology from the IP layer by treating the data-line layer as an opaque cloud leads to significant problems. In the case of ATM over IP both IP and ATM require their own routing protocols so there’s a duplication of functionality and because the routers in the opaque cloud can be very large the next-hop routing tables can become unmanageable. The paper proposes ATM under IP instead where we can maintain the speed and capacity of ATM switches as well as the robustness and scalability of connectionless IP.

2. There needs to be robustness in the face of network or node failure. In using ATM under IP the paper claims that it strives to avoid introducing inconsistent state into the network and seek to limit the amount of time that inconsistent state exists. The paper introduces a simply adjacency protocol (IFMP) that enables a node to be sure that its neighbor has not changed. The paper also proposes that lifetimes be associated with redirection messages to limit the lifetime of an inconsistent state.

3. There should be a point-to-point network model for ATM. The paper claims that the separation of labeling and switching and the local nature of the switching decision ensures scalability to large networks.

(ii) Most glaring problem

The most glaring problem would be that this protocol results in a relatively large number of connections. There needs to be a flow type defined that reduces these number of connections required.

(iii) Future Research Directions

Future research directions for this work would be in the areas of gigabit routers, data-driven label switching, and topology-driven label switching.

IP Switching: ATM Under IP April 9, 2009

This paper presents a method of running IP over ATM hardware that leverages the advantages of ATM hardware while removing the unnecessary parts of ATM that would adversely affect the performance of an IP over ATM implementation. They show one way to take load off a CPU by inserting rules to handle certain flows in hardware. They show that the combination of hop-to-hop forwarding for short flows with virtual circuits for longer flows can leverage the advantages of each to optimize performance according to traffic characteristics, with an adequate policy.

The paper focuses on how IP over ATM hardware can yield higher bandwidth than processor-based routers, pointing out that those processors are becoming stressed, and also that ATM switches are cheaper. Supposing that IP routers might also be hardware-accelerated, or that prices may change, this argument could weaken. However, ATM does offer more advantages such as better support for real-time communication. This was not emphasized or measured, probably because this is more of a concern now than it was then.

Certainly the idea of flow-based routing is an active area of research today (e.g. Openflow), as well as the idea of providing different types or quality of service to different applications. This will continue to be important as the demand for real-time and high-bandwidth communication increases.

IP Switching: ATM Under IP April 9, 2009

The paper proposes the integration of ATM’s connection-oriented switching hardware with the connectionless IP protocol. The proposal is made to exploit the bandwidth and capacity scalability offered by ATM and the connectionless, flexible operation of IP. The idea is eliminate the traditional end-to-end connections in ATM by preserving a cached soft-state of the IP forwarding over time and making local decisions on the type of flow forwarding to be used for the future downstream packets. The paper introduces these basic ideas and delves into the specific details of IP switching, the system structure, flow control semantics and its advantages.

The paper recognizes other IP over ATM integration technologies which tend to obscure the physical layer from IP resulting in the problem of duplication of underlying routing protocol, maintenance and management functions. It points out the explosion in the number of link layer connections between routers that are required when using such technologies in a cloud environment. The paper then introduces the concept of flows which are the logical equivalents of connections in a connection-oriented with the exception that the flow forwarding decisions are purely based on local temporal data of traffic that is cached on the router. Traffic with predominantly short packets will use a connectionless IP forward and longer packets flows will use ATM switching. The two main flow classifications that are performed by the IP switch controller are the port-pair and host-pair flows which influence the forwarding decisions.

The task of integrating ATM under IP is done by replacing the complex ATM software by a more general low-level protocol (GSMP) and building the interface (IFMP) to enable IP to make use of the ATM switching hardware. Flow switches are made from connectionless to virtual circuit flow by binding a free label to the recipient port and routing all further forwarding through the IP switch controller. A downstream node wishing to redirect its flow sends an IFMP message back to the IP switch which then instructs the ATM hardware to make the appropriate direction switch by binding the new label to the output port. In essence IFMP signaling information travels upstream opposite to the direction of data flow. The IFMP redirection message additionally contains the flow identifier which has the header field and lifetime information, the lifetime information is used to compute the refresh rate of the cached flow state. The paper then describes how the lifetime (TTL-time to live) information is subject to preserved propagation by taking a checksum over the header and the lifetime. IFMP ensures the robustness (no drops or corruption) of packet delivery by enforcing adjacency among neighboring nodes and by diminishing the lifetime of inconsistent data. The state information stored at IP is soft because it serves only an advisory purpose and redirection messages can be ignored thus preserving local autonomy. Multicast support and QoS guarantees are then demonstrated followed by a set of host-pair flow experiments. The paper adopts a PPP network model as opposed to a cloud model but does not explain the repercussions of this assumption and the scalability issues that might arise.

The future trends arising from this paper could be development and detailed specification of other integration protocols similar to those quoted in the ‘related work’ section of the paper, which tap the potential throughput achieved from a connection-oriented protocol at the same time allowing the flexibility of a datagram service like IP.

IP Switching-ATM Under IP April 9, 2009

“IP Switching-ATM Under IP” by Peter Newman, Greg Minshall and Thomas L. Lyon is a paper about running IP over ATM. The internet and private enterprise networks traffic have been growing exponentially. To deal with this the authors suggest running IP over ATM because the ATM switching technology offers higher aggregate bandwidth. This gives the simplicity, scalability, and robustness of IP with the speed, capacity and multiservice traffic capabilities of ATM.

The authors start off the paper describing the need for IP over ATM. They bring up the cost difference for a router with limited throughput compare to a switch with more throughput. After mentioning why it is necessary to use IP over ATM, the authors show why other methods that try IP over ATM are incorrect. This is mainly due to the fact that the approaches hide the underlying network topology from IP so it is just an obscured cloud to IP.

The authors approach starts off by replacing the ATM software with a protocol they created called general switch management protocol. This protocol allowed the IP switch to control the hardware switch in ATM. They used soft states to cache flow information and allowed each switch to locally decide which flow to use as there basis in their design. They determined flows using the IP/TCP/UDP headers classifying the flows into two types, port-pair and host-pair. One important part of the paper is the point-to-point network model rather than a logical shared medium. This works because point-to-point is more natural for ATM and have been proven to scale to very large networks by the Internet. Another important part of the paper is the multicasting using IP over ATM. When an incoming multicast flow comes in, it will branch out to multiple destinations. Each of these branches can be redirected by a downstream neighbor. If the flow happens to be labeled, we can use the hardware multicast capabilities of the ATM switch. The last important part of the paper is the QOS. The authors were able to support both policy-based and contract-based quality of service. They supported contract-based QOS with RSVP to simulate something similar to ATM traffic management.

The paper’s impact on the future of networking can be seen from that fact that they are planning for the future. The future trends show traffic growing at a rate that the technology cannot efficiently handle. What makes this paper interesting in this sense is the fact that they used previous technology to address the problem instead of creating something new. A problem with this paper is their solution cannot detect loops from previous switched flows that differ only in TTL.

IP Switching: ATM Under IP April 9, 2009

This paper investigates implementing IP on top of fast ATM switching hardware while preserving the connectionless model of IP.

Contributions:

1. The approach in the paper uses existing ATM hardware while removing the resident software and replacing it with GSMP to give IP router software access to the ATM hardware. Switches maintain “soft” state based on IP headers and IP flows to determine whether to use a hardware switch or pass it up to the IP switch controller to route the packet.

2. Classifying flows by violating strict layering and looking at the IP/TCP/UDP header to determine type of service, protocol, source/destination address and port. host-pair and port-pair flows are defined. When packets are received from the default channel, it is reassembled sent to the IP switch controller if there is no flow classification match. If there is a match, the flow is switched directly in ATM hardware.

3. A point to point model rather than a cloud model was adoped and a flow management protocol introduced to label flows between two ATM switches. TTL is included in the flow identifier so that the TTL is correct at the exit of a switch flow as if it were forwarded hop by hop.

Problems:

Host-pair flows requires large tables. Advances in VLSI and algorithms resulted in this technology being superseded by routers that can forward packets entirely in hardware with better performance and lower overhead.

Future research:

More flexible definition of flow types instead of just host-pair or port-pair flows and dynamic flow control are topics of future research in the IP switching area.

IP Switching: ATM Under IP April 9, 2009

(i) the three most important things the paper says:

1. Around the time the paper was written, the internet and IP was experiencing significant growth. However, the packet-switched routers used by IP was beginning to experience problems — the routers were too expensive and throughput was comparatively low. A new direction that the authors (and others) wanted to explore was replacing routing technology with switching, which is much cheaper and provides scalable link bandwidth and switch capacity. The proposal is to use IP over ansynchronous transfer mode.
2. To implement IP over ATM, other papers hid the physical network topology from the IP layer, which views it as an opaque “cloud”. This results in a number of problems, such as duplication of functionality and increased management/configuration load. The paper suggests running connectionless IP on ATM hardware with “soft state” used as a performance optimization. The state guides the switching decisions of flows that have been previously seen, and is maintained locally instead of end-to-end to provide robustness.
3. The paper uses Internet and corporate backbone traffic traces to determine that a large majority of traffic can be switched, and that the use of ATM switches would increase traffic capacity in the routing software by 3.5 times.

(ii) the most glaring problem with the paper:

There appear to be a few scalability issues with the overhead involved in IP switching, such as maintaining soft state and maintaining connections for a large number of host-pair flows.

(iii) the future research directions of the work:

As the paper mentioned, it may be worthwhile to consider flows at a coarser granularity than host-pair flow types. Later research also generalized the proposal beyond only ATM.

The paper mentioned that IP switching increased the traffic capacity but didn’t mention if the proposal could take advantage of the potential bandwidth gains offered by switching. I would also be interested in finding out the performance differences between IP switching and the other proposals for IP over ATM using clouds.

IP Switching: ATM Under IP April 9, 2009

The main contribution is that ATM switches can be modified to provide level-3 IP routing using hardware. This results in utilizing less expensive hardware to provide higher performance IP routing. The authors identify that while IP is connectionless, many protocols and applications that run on IP do behave as though a virtual connection exists for some period of time. Thus, the existence of a switched connection under IP will benefit many applications. It seems that previous attempts to run IP over ATM did not exploit the connection-based nature of ATM.

Some key details of this approach include flow classification, the use of soft state, and a timeout mechanism. Flow classification allows the IP switch to identify which packets represent a flow between two hosts. An identified flow suggests that packets will be exchanged between the same two hosts because they are engaged in some type of application based conversion/exchange. The authors admit that many flow classification schemes are possible. They chose to identify flows in two ways: between hosts with the same TTL and between hosts with the same port (service-type) and TTL. In the former case, flows were established only after a number of packets were exchanged. In the latter case, flows were setup immediately (as the service types are known). Once a flow is established, the routing no longer involved store-and-forward processing via IP software. The routing was accomplished by switching packets based on setup virtual ATM circuits.

Soft state is employed to provide a cache-like mechanism for each IP switch. When flows are being established, some cached packet history is needed. Similarly, when the flows are established, they need to be tracked so that they can maintain the virtual ATM circuits. However, because each IP switch is autonomous and may fail at any time, this soft state is not absolutely required. It can be rebuilt if lost. Moreover, it is designed to be updated dynamically as the topology and traffic changes.

This leads to the last key detail, the use of timeouts. Each flow is established for a limited amount of time. This prevents virtual ATM circuits from being permanently allocated. If however a flow is continually used, the IP switches will periodically refresh the flow lifetime to keep it alive. This approach allows flows to not consume too many ATM resources and still provide switching for those flows that need it.

Although performance simulations are provided (based on Internet and corporate traces), there is no performance comparison between other IP routing approaches. Several different approaches are described. Based on the descriptions it seems rather glaring that no performance evaluation was done to identify how viable an alternative this IP over ATM approach really is.

Although it appears that crossbar switch based IP routing as won out, I’d expect further research in this area to involve exploring the multicasting benefits that ATM switches may be able to confer. It seems that given the inherent point to many architecture of these devices that they may be able to out perform traditional crossbar switching.