Router modeling using Ptolemy
EE290N
Xuanming Dong and Amit Mahajan
May 15, 2002
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 backplane
output interface
Control Plane
Router Architecture (II)
Routing
Routing
Messages
Admission
Control
Forwarding Table
Per Flow QoS Table
flow 1
Data In
Route
Lookup
Data Plane
RSVP
messages
RSVP
Switch
Fabric
Classifier
flow 2
flow n
Buffer
management
Scheduler
Data Out
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
0
1
2
Router
interface3
interface1
..
.
3
Subnetwork 3
9
8
7
..
.
interface2
4
5
Subnetwork 2
6
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
input interface
Model
and
Screen
Shot
fabric
output interface
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