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 interface output interfacebackplane
Router Architecture (II)
Admission Control
Data In
Data Out
Con
trol
Pla
ne
Data
Pla
ne
Routing Routing
Messages
RSVP messages
RSVP
Route Lookup
Forwarding Table Per Flow QoS Table
Scheduler
flow 1
flow 2
flow n
Classifier
Buffer management
SwitchFabric
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
.
.. ...
0 1 2
3 4 5 6
7 8 9Subnetwork 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 interface output interfacefabric
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