Upload
tamsin-stevenson
View
218
Download
1
Tags:
Embed Size (px)
Citation preview
IP Switching for Scalable IP ServicesHassan M. Ahmed
Ross CallonAndrew G. Malis
Hohn Moy
Presented by Gao, YunShih, Pei-ShinWei, 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 2 LIS 3
Host C
Host A
Host B
Router 1
Router 2
LIS 1
LIS 2 LIS 3
Host C
Multiple IP LIS’s on one ATM network Connection between Hosts A and B
ATMSVC
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 2 LIS 3
Host C
Host A
Host B
Router 1
Router 2
LIS 1
LIS 2 LIS 3
Host CATMSVC
Direct Connection between Hosts A and C (NHRP)Connection between Hosts A and C
ATMSVC
ATMSVC
ATMSVC
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
2
)1(* nn
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
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
QoS and Traffic Engineering VC routing is based on dynamic
routing algorithm Explicit routing allows
1. Crankback and retry2. 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)