Router modeling using Ptolemy Xuanming Dong and Amit Mahajan May 15, 2002 EE290N

Project Goals Modeling routers in Ptolemy Proposing and verifying design improvements

Approach Modeled a typical router in Ptolemy Identified the bottlenecks in routers Proposed solutions for these problems and verified some desirable properties

Router Architecture (I) Set of input and output interfaces interconnected by a high speed fabric input interfaceoutput interfacebackplane

Router Architecture (II) Admission Control Data In Data Out Control Plane Data Plane Routing Messages RSVP messages RSVP Route Lookup Forwarding TablePer Flow QoS Table Scheduler flow 1 flow 2 flow n Classifier Buffer management Switch Fabric

Recent Router Research Reconfigurable routers –use recent developments in run-time reconfigurable hardware and hardware/software co-design techniques to improve both the performance and functionality of the network routers –so that the new protocols can be deployed rapidly Routers based on the reusable elements –click modular router Parallelism by partitioning functions of routers

Motivation for Router Models Define high level models of router behavior Construct routers by proof Explore the design space to optimize hardware and software performance of routers Support from verification and simulation tools Reuse previous designs Provide function decomposition of routers If possible, synthesize part or all of the hardware and software

Overview of the Simulated Networks and Router Subnetwork 1 Subnetwork 2 Subnetwork 3 interface1 interface3 interface2 Router

Basic Model Model the data-plane of the router Model major components in the DE domain Three input interfaces, three output interfaces Packets generated by a Poisson process QoS implemented using priority-based scheduling for packets

Model and Screen Shot input interfaceoutput interface fabric

Run Window

Problems Identified Main bottlenecks in routers are – LookUp – Switching Fabric We worked on the LookUp design improvement

LookUp Slow LookUp speed creates a bottleneck Solution : Parallelize the LookUp block Properties desired: –Ordering of the packets should be maintained –System should not deadlock –Bounded memory constraints are not violated

Verification of desired Properties The block can be represented well in the DF domains BDF seems to be a good choice –but the present formalism is not powerful enough to handle the model under consideration Our Solution: Model the block in the SDF domain. –This adds a little redundancy but we get good enough solution with the verification of desirable properties

Model in BDF Domain

Model in SDF Domain

Related Problems What input rates can the router support? With the above rates, will the available memory be sufficient to prevent overflow (with probability.99)? The above problems can be solved using a probabilistic framework but could be quite complex

General Problem Formulation SYSTEM: Composed of a multitude of components, each of them capable of being modeled in timed/untimed domains. AIM: Want to check properties like bounded memory. Can we use modeling to make this problem simpler?

Our Solution If possible, model some components in the DF domains Abstract these components with their cumulative properties Using the above properties, consider the timed model (like DE) of the system for checking these properties in a probabilistic framework This interaction among the timed and the untimed models could be used to make the problem simpler

Conclusions Verification is easy in some domains. –Hence one might need to modify the component design to model them in these domains in order to verify the desirable properties In system design, abstracting the interaction between the timed and untimed models can help simplify problems