IP Switching for Scalable IP Services Hassan M. Ahmed Ross Callon Andrew G. Malis Hohn Moy Presented by Gao, Yun Shih, Pei-Shin Wei, ShuGuang

OUTLINE Background Review & Motivation The Overlay Model: Classical IP over ATM IP Switching IP Navigator Conclusion

Background Review & Motivation Hop-by hop routing Simplicity Hierarchical Routing, easy to scaling Difficult to implement Traffic Engineering (Bandwidth Management) & QoS

Background Review & Motivation (Continued) Switched Core Achieve a form of Traffic Engineering VC’s allows Explicit Routing to be used efficiently Isolate the internal routing from changes of the Internet’s routing algorithms Integration of Datagram and Circuit Technologies

The Overlay Model: Classical IP over ATM IP vs. ATM Connectionless (IP) vs. connection oriented (ATM) Packets (IP) vs. cells (ATM) Broadcast LAN’s (IP) vs. point-to-point connections (ATM)

The Overlay Model: Classical IP over ATM (Continued) ATM Address Resolution Protocol (ATMARP) Logical IP subnet (LIS) Independent Routing Protocols

Host A Host B Router 1 Router 2 LIS 1 LIS 2LIS 3 Host C Host A Host B Router 1 Router 2 LIS 1 LIS 2LIS 3 Host C Multiple IP LIS’s on one ATM network Connection between Hosts A and B ATM SVC

The Overlay Model: Classical IP over ATM (Continued) Logical IP subnet (LIS) IP stations (hosts & routers) in the same LIS communicate directly via ATM SVC’s or PVC’s IP stations in different LIS’s must intercommunicate via a router Next Hop Resolution Protocol (NHRP) Query / Response Model

Host A Host B Router 1 Router 2 LIS 1 LIS 2LIS 3 Host C Host A Host B Router 1 Router 2 LIS 1 LIS 2LIS 3 Host C ATM SVC Direct Connection between Hosts A and C (NHRP)Connection between Hosts A and C ATM SVC ATM SVC ATM SVC

The Overlay Model: Classical IP over ATM (Continued) Scaling Problem Total number of logical links that are advertised between the n ATM-attached routers equals

IP Switching Eliminating scaling problems by running the IP routing protocol on switches as well as routers

IP Navigator 1. A particular IP switching implementation 2. Developed by Cascade Communication Corporation

IP Navigator (Continued) Makes a “cloud” of Cascade switches, frame relay, or ATM Appears externally to be a collection of IP routers

A F E D C B I G H

IP Navigator (Continued) Two routing instances are running inside the “cloud” Uses standard IP routing (OSPF) within the core to exchange routing information A VC routing protocol is running between switches, allowing them to build up point-to-point and point-to- multipoint VC’s

IP Navigator (Continued) Each router pre-establishes a VC to each potential egress ( i.e. to every other router in the area ) Build point-to-multipoint (PMT) tree rooted at each egress Traffic travels in reversed direction VC’s used by IP Navigator are set up in response to routing packets and are automatically re-established as necessary

IP Navigator (Continued) Multicast Similar to unicast Standard IP multicast protocol are spoken at the edge of the cloud Multicast information is redistributed throughout the cloud using OSPF

A F E D C B I G H Example of multipoint-to-point tree (MPT)

QoS and Traffic Engineering VC routing is based on dynamic routing algorithm Explicit routing allows 1. Crankback and retry 2. Optimization of the combined path for multiple VC’s

QoS and Traffic Engineering (Continued) IP Navigator allows QoS support to be based on a range of coarse through fine granularity Traditional “best efforts” IP service Separates IP traffic into a small number of classes and open separate MPT’s for each class First Class Economy Class

Conclusions IP Navigator integrates the transport of connectionless IP traffic over connection-oriented switched data networks Better scaling properties and inherent simplicity from IP Higher performance of forwarding packets (VC’s)