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

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

(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 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.