An architecture for CBR for reactive routing

1
An architecture for CBR for reactive routing
2
Objectives

• Motivation there are many routing protocols and
  yet there is no single routing protocol is
  satisfactory
• CBR objective
• Develop, refine, analyze, routing algorithms (or
  components), not routing protocols
• Routing algorithms include route selection, route
  metric, aggressiveness of RERR propagation (e.g.,
  AODV precursor neighbors), collision avoidance in
  RREQ propagation
• Simplify the analysis and comparison of routing
  algorithms
• A single framework allows fair comparison in all
  cases. Anything can be compared.
• Simplify the development and performance analysis
  of routing algorithms
• Focus on the important stuff (e.g., how
  aggressively should route information be
  disseminated), not on the details like packet
  headers.
• Decomposition of routing protocols into a
  well-defined structure tends to clarify design
  choices.
• E.g., Link-lifetime prediction has a clear role.
  Route-activity prediction has a clear role. But
  AODV confuses these - it uses one timer for both.
• Decomposition of routing protocols into generic
  parts requires careful analysis of the role of
  various parts of the routing protocol.

3
CBR Architecture

• A single framework that supports a very large
  number of different routing algorithms.
• CBR system contains
• A fixed generic infrastructure.
• Self-contained, user-defined building blocks.
• Self-contained mean that the protocol designed
  can focus on the design of a single block and not
  be concerned about functional interactions. (The
  greatly simplifies implementation.)
• An Interface between these two parts.
• Functional orthogonality user-defined building
  blocks can be change and refined without
  impacting the infrastructure or other user-define
  building blocks
• Performance orthogonality (i.e., where the
  performance of a building block is independent of
  the other building blocks) is not an objective.
• Role of the infrastructure
• The infrastructure performs few routing
  functions.
• It defines the flow of information, and then the
  sequence of tasks/decisions.
• It defines the format/interface between building
  block.
• Therefore, the following does not address routing
  algorithms. The focus is on an architecture that
  allows a wide range of routing algorithms.
• There should be boxes where specific algorithms
  can be placed. But we will not be overly
  concerned with what exactly are in the boxes.

4
How to make things generic (1)
TheComponentManager - This object controls which
version of each user-defined building block is
used. E.g,
CTopologyInfo TI TheComponentManger.MakeTopolo
gyInfo()

• makes some type of Topology Info.
• CTopologyInfo is a parent class. The child class
  could contain a wide variety of topology
  information.
• TI could be of type CPathInfoBidirectional,
  CTableInfoBidirectional, etc.
• Note that CTopologyInfo is an abstract class
  (i.e., there is never an object of type
  CTopologyInfo).

Parent class
Child class
5
How to make things generic (2)

• Consider a route request packet.
• This packet MUST contain topology information
  about the path that is experienced by the
  packet as it is flooded.
• The exact form of this topology information is
  not important to the RREQ packet.
• Solution
• The parent class of the RREQ part of a packet has
  an attribute called AppendedTopologyInfo and this
  attribute is of type CTopologyInfo.
• AppendedTopologyInfo could be any of a wide
  variety of types of topology information
  (including types of information we have not yet
  thought about)

6
How to make things generic (3)
The RREQ packet needs its AppendedTopology
attribute to perform some specific tasks. E.g.,
The last hop must be appended onto
AppendedTopology
This is a generic type too. The TopologyInfo does
not depend on link information.
Pkt.RREQInfo-gtAppendedTopologyInfo-gtAppendObserved
Link(LastHop)
The RREQ part of the pkt
The task needed. Every child of CTopologyInfo
MUST be able to perform this task. gt
AppendObservedLink must be part of the interface
of CTopologyInfo.
The AppendedTopology could be of any type
Summary Identified a fundamental object (e.g.,
topology info). Identified other fundamental
objects (e.g., RREQ) that must interact or have
this fundamental object as an attribute. Identifie
d the tasks (interface) that the fundamental
object must provide.
7
Hierarchical architecture

• The highest level of the architecture is a set of
  packages.
• Within these packages are sets of more packages.
• Eventually, the packages contain a sets of
  classes.
• Infrastructure classes
• These class are hard coded. They cannot be
  overloaded by the user/protocol designer.
• TheComponentManager is part of the
  infrastructure.
• Parent classes
• Provide an interface between the fixed
  infrastructure and the protocol designer.
• Child classes
• Specific versions of parent classes that the
  protocol design can change.
• But the child class must support the interface
  defined by the parent.

8
Highest level of packages
Note this is the current design. Future
adjustments are possible.

• TheComponentManager
• Already discussed
• Eventually this is where component adaptation
  will be implemented.
• PNode
• All processing that is performed in the node is
  within this package
• PPacket
• All the objects that might be contained in a
  packet
• Note that objects are not just data. E.g.,
  Topology Info must be able to perform specific
  functions on itself. E.g., a packet must be able
  to decode itself
• But data objects typically do not have state
  diagrams.
• PTopologyInfoCenter
• Anything related to topology
• PTheMacInterface
• This outside the scope of CBR, which causes some
  conceptual problems.
• (The MAC defines the type of topology info is
  required/available, not TheComponentManager.)

P package C class The object
9
Highest level of packages
Note this is the current design. Future
adjustments are possible.

• TheComponentManager
• Already discussed
• Eventually this is where component adaptation
  will be implemented.
• PNode
• All processing that is performed in the node is
  within this package
• PPacket
• All the objects that might be contained in a
  packet
• Note that objects are not just data. E.g.,
  Topology Info must be able to perform specific
  functions on itself. E.g., a packet must be able
  to decode itself
• But data objects typically do not have state
  diagrams.
• PTopologyInfoCenter
• Anything related to topology
• PTheMacInterface
• This outside the scope of CBR, which causes some
  conceptual problems.
• (The MAC defines the type of topology info is
  required/available, not TheComponentManager.)

P package C class The object
10
PNode (subpackages)

• Class CNode
• All processes are the attributes
• There is some distinction between processes and
  data.
• PControlPktProcessor
• Process control packets
• PRouteSearchStateMachine
• Performs route search

• PFloodPropagator
• Floods packets (efficiently)
• PPktForwarder
• Forwards data packets. Performs next-hop lookup.
  Packets stay in the queue during route search.

11
PNode (class view)

• Class CNode
• Attributes of all processes
• There is some distinction between processes and
  data.
• PControlPktProcessor
• Process control packets
• PRouteSearchStateMachine
• Performs route search

• PFloodPropagator
• Floods packets (efficiently)
• PPktForwarder
• Forwards data packets. Performs next-hop lookup.
  Packets stay in the queue during route search.

Interfaces to packages
12
PNode (class view)

• Class CNode
• Attributes of all processes
• There is some distinction between processes and
  data.
• PControlPktProcessor
• Process control packets
• PRouteSearchStateMachine
• Performs route search

• PFloodPropagator
• Floods packets
• PPktForwarder
• Forwards data packets. Performs next-hop lookup.
  Packets with in queue during route search.

Interfaces to packages
13
PNodePControlPktProcessor
Package view
14
PNodePControlPktProcessor
Class view
Infrastructure classes
Parent classes
Child classes
15
PNodePControlPktProcessor
Infrastructure classes
Parent classes
Child classes
16
Processing RREQ (1)
Infrastructure classes
Parent classes
Child classes (only a small sample)
17
Processing RREQ (2)
Note the interfaces are shown
18
TheRouteSecurityProcessor

• One of many security processors
• Checks for RREQ DoS floods
• Protocol conformance check
• Nonconforming packets may have lead to adverse
  behavior and should be dropped.
• Check sanity of AppendedTopologyInfo

19
Processing RREQ
20
TheRouteSearchTopologyController

• Routes are constructed out of the path followed
  by the RREQ. To ensure that the route is of
  sufficient quality, RREQs are neglected if the
  LastHop and TheAppendedTopology do not form a
  route of high enough quality.
• Signal Stability-Based Adaptive Routing Protocol
  (SSA) drops RREQ if the LastHop is not stable and
  strong.
• The level of stability and strength required is
  carried in the pkt and is controlled by the route
  search state machine, e.g., first strong/stable
  links are used, and if no route is found, then
  weaker/less stable links are used.

21
Processing RREQ
22
TheRouteSearchRegionEnforcer

• Route search may be limited by
• Hop count (with the maximum hop count included in
  the packet and controlled by the route search
  state machine)
• Geographical region (with the specific region
  defined in the packet and controlled by the route
  search state machine)
• Different ways of defining the geographic region
  are different versions of this class.

23
Processing RREQ
24
TheTopologyAppender

• As a RREQ is flooded in search for a path to the
  destination, the path traversed by the RREQ is
  learned. This learned topology information is
  included in the RREQ.
• TheTopologyAppender puts the information into the
  RREQ.
• In general, other information can also be
  included.
• E.g., information about other paths and routes
  can be piggybacked.
• Exactly the form of the learn topology depends on
  the type of CTopologyInfo used.
• Summary TheTopologyAppender does not control
  what type of topology information is appended, it
  only controls when topology information is
  appended.

25
Processing RREQ
26
TheRouteReplyGenerator

• If TheTopologyDatabase has a route to the
  destination, or if this node is the destination,
  then a route reply may be generated.
• Different versions of TheRouteReplyGenerator
• The generation of the RREP depends on
• whether other RREPs for the same RREQ have been
  recently heard,
• and the quality of the found route.
• Even if a RREP is generated, the RREQ is still
  propagated if
• the quality of the found route is low.
• or multiple routes are desired.
• After a route is found, the generation of the
  RREP is delayed to better assess the relative
  quality of the found route.
• After a route is found, the generation of the
  RREP is delayed to avoid colliding with other
  RREPs.

27
CPacket
28
CPacket
The packet is not just an array of bytes, but is
an object which is processed and passed from one
processor to another within the node.
Fixed parent classes (these contain attributes)
Protocol designer designed child classes
29
CPacket
TheMacInterface must provide LastHop information
and raw bytes
Fixed parent classes (these contain attributes)
Protocol designer designed child classes
30
CPacket
Fixed parent classes (these contain attributes)
Protocol designer designed child classes
31
CRREQInfo - RREQ information within packets
Already discussed
All RREQs must have an originator
Parent class
Abstract (pure virtual) functions. The protocol
designer must implement these.
This type of RREQ can only find a route to one
destination at a time
These are needed to get data from a stream of
bytes. Note that different components do not need
to know the number of bytes other components have
placed in the packet (compare to TCP and IP
headers)
Child class
Required to determine if the RREQ has been seen
before. Maybe it used seq number or seq number
and IP it is the choice of the designer.
Required to determine this node, or some node
reachable from this node is the one that the RREQ
seeks. This works even if a list of destination
are sought.
(Note RREQ is orthogonal to CTopologyInfo)
32
Topology
33
PTopologyInfo
Parent class
Child classes
Infrastructure classes
Parent class
list
Child classes
Note that table or path is orthogonal to path
metric (e.g., hop count, signal strength, )
34
CLinkAttribute
Independent of the what the link attribute is,
the interface is the same
For putting (getting) the attribute into (out of)
the packet
Update attribute
CFreshness AB gt A min(A, B) (the oldest
link)
CLinkSignalStrength AB gt A min(A, B) (the
worst link)
CHopCount AB gt A A B
35
Recall How to make things generic (3)
The RREQ packet needs its AppendedTopology
attribute to perform some specific tasks. E.g.,
The last hop must be appended onto
AppendedTopology
This is a generic type too. The TopologyInfo does
not depend on link information.
Pkt.RREQInfo-gtAppendedTopologyInfo-gtAppendObserved
Link(LastHop)
The RREQ part of the pkt
The task needed. Every child of CTopologyInfo
MUST be able to perform this task. gt
AppendObservedLink must be part of the interface
of CTopologyInfo.
The AppendedTopology could be of any type
Summary Identified a fundamental object (e.g.,
topology info). Identified other fundamental
objects (e.g., RREQ) that must interact or have
this fundamental object as an attribute. Identifie
d the tasks (interface) that the fundamental
object must provide.
36
AppendObservedLink

• CTableInfoBidirectional
• CGeneralizedLink GL LastHop
• GL.FlipDirections() // bidirectional
• GeneralizedLinkToGo.Transmitter TheNode-gtID
  //now this node is at the end of the
  path
• GeneralizedLinkToGo.LinkAttributesLastHop.LinkAt
  tributes

• CPathInfoBidirectional
• Simply append Generalized link onto the Path
  attribute
• Bidirectionality impacts route search

37
Topology Info Center
All access of the topology database if through
here. This part of the infrastructure has a large
number of operations
When a new packet arrives, this object puts the
topology data the packet holds (or represents)
into the topology database.
Parent class different types of route selection
can be performed via child classes. The search
engine seems to depend on the type of topology
information collected. Non-orthogonality!
38
Future work

• This is only the basic parts of reactive routing.
• E.g., Route error is missing
• Only basic or default (i.e., do nothing) child
  classes are implemented now.
• Geographical routing (will stress the
  architecture)
• Cooperative routing (will stress the
  architecture)
• Others
• Interface with QualNet
• Rhapsody includes many threads and timers.
• It is not clear how these will work in a
  simulator.
• Brute force performance comparison
• It is easy to implement different algorithms
• Use a cluster to compare a large number of
  algorithms.
• Merge reactive and proactive
• More security components