Ipsilon Tagged Flows

 Ipsilons ``Flow Labelled IP'' approach to putting IP traffic on the ATM substrate [31] uses the concept of traffic flows to aggregate connectionless IP traffic onto a connection oriented ATM network.

What an Ipsilons flow-switch basically does is the following: It transparently monitors incoming IP packets and tries to detect flows of traffic matching the same criteria. Since it is already known that some kinds of traffic are only short-lived (for example DNS nameserver queries usually won't consist of more than some packets) the traffic can be categorized by TCP ports (i.e. by applications). For applications that generally will have longer duration traffic, flows are defined. For this, the fields in IP/TCP/UDP headers determining the routing decision, such as type of service, protocol, source address, destination address, source port, destination port etc. are used. Table 2.2 shows the classifcation that Ipsilon proposes for distinguishing the flows.

  

Table 2.2: Flow-oriented vs. short-lived types of internet traffic

Whenever a packet is received by the Ipsilon switch, it is reassembled and submitted to the control processor for forwarding. The processor forwards the packet in the normal manner, but it also performs a flow classifcation on the packet to determine whether future packets belonging to the same flow should be switched directly in the ATM hardware or continue to be forwarded hop-by-hop by the router software.

Flow classification depends on policies local to the switch. The flow classifier inspects the contents of the fields that characterize the flow and makes its classification decision based upon policies expressed in a table. Usually, the TCP port number will be used to identify the application that is responsible for the traffic. Thereby it is for example possible to configure the switch in a way so that flows belonging to FTP data connections will be switched but DNS queries will still be forwarded as datagrams.

The protocol that Ipsilon uses to exchange flow information between Flow Switches is called ``Ipsilon Flow Management Protocol'' (IFMP) and is specified in RFC 1953 [29]. The transmission of IPv4 datagrams over an ATM link is described in RFC1954 [28], both in a default manner or in the presence of flow labelling with IFMP.

In their paper [31], Newman et. al describe the performance of flow classification and they examine the suitability of standard internet applications for flow switching in detail. For this, they use the same data samples as Claffy, Braun and Polyzos did in [15], therefore the results should be comparable.

In the samples they examined about 84% of the packets and 91% of the bytes transferred were recognized as suitable for flow switching with the Ipsilon switch. They found that after an initial startup phase of 60 seconds about 92 flows per second were established. The average number of flows in the flow table was about 15,500. They also compared those results to a setup where all packets were classified for switching. Then a mean number of 422 flows per second would have to be established with an average of 42,000 entries in the flow table. Whether this could be done on an economic basis will surely depend on the architecture of the switch as well as on the price it costs to establish a new flow - however it leads to the conclusion that the effort to distinguish between different types of applications before the establishment of flows makes sense.

What is also worth mentioning is that Ipsilon switches already include a Web server and software that allows to configure and monitor the switch operation via a WWW browser. Because of this they are already very well suited for the web-based enterprise management model that was presented in the introduction.