Graduate Networks, UCSD

CSE222 – Spring 2009

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

Filed under: R03. IP Switching: ATM Under IP — koderaks @ 2:50 pm
Tags: , ,

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

“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

Filed under: R03. IP Switching: ATM Under IP — liyunjiu @ 2:49 pm
Tags: ,

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.