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.
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.
How to make things generic (1)
Parent class
Child class
CTopologyInfo
CTableInfoBidirectionalCPathInfoBidirectional
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).
TheComponentManager - This object controls which version of each user-defined building block is used. E.g,
CTopologyInfo *TI = TheComponentManger.MakeTopologyInfo();
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)
CTopologyInfo
CTableInfoBidirectionalCPathInfoBidirectional
CRREQInfo
AppendedTopologyInfo
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
Pkt.RREQInfo->AppendedTopologyInfo->AppendObservedLink(LastHop);
The RREQ part of the pkt
The AppendedTopology could
be of any type
The task needed.Every child of CTopologyInfo MUST
be able to perform this task.=> AppendObservedLink must be
part of the interface of CTopologyInfo.
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.Identified the tasks (interface) that the fundamental object must provide.
This is a generic type too.The TopologyInfo does not depend on link information.
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.
Highest level of packages• 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.)
Note: this is the current design. Future adjustments are possible.
‘P’ = package‘C’ = class‘The’ = object
ReactiveCBR
PTopologyInfoCenter PMacInterface
PPacketPNodeCComponentManager
Highest level of packages• 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.)
Note: this is the current design. Future adjustments are possible.
‘P’ = package‘C’ = class‘The’ = object
ReactiveCBR
PTopologyInfoCenter PMacInterface
PPacketPNodeCComponentManager
PNode (subpackages)
PNode
PFloodPropagatorCNode PControlPktProcessor
PRouteSearchStateMachine PPktForwarding
• 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.
PNode (class view)
CNode
CControlPktP rocessor
TheNode
TheControlPktP rocessor
CFloodP ropagator
TheNode
TheFloodP ropagator
CRouteSearchStateM achine
TheRouteSearchStateM achine
TheNode
CP ktForwarder
TheP ktForwarder
TheNode
• Class CNode– Attributes of all processes– There is some distinction
between processes and data.
• PControlPktProcessor– Process control packets
• PRouteSearchStateMachine– Performs route search
Interfaces to packages
• PFloodPropagator– Floods packets (efficiently)
• PPktForwarder– Forwards data packets. Performs next-hop
lookup. Packets stay in the queue during route search.
PNode (class view)
CNode
CControlPktP rocessor
TheNode
TheControlPktP rocessor
CFloodP ropagator
TheNode
TheFloodP ropagator
CRouteSearchStateM achine
TheRouteSearchStateM achine
TheNode
CP ktForwarder
TheP ktForwarder
TheNode
• 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
PNode::PControlPktProcessor
PControlPktProcessor
CControlPktProcessor
PTopologyAppenderPSearchTopologyControl
PRouteSearchSecurity PRouteSearchRegionEnforcer
PRouteReplyGenerator
Package view
PNode::PControlPktProcessor
CControlPktProces sor
CRouteErrorProces s or
TheControlPktProces s or
TheRouteErrorProcess or
CRouteReplyProcess or
TheControlPktProces s or
TheRouteReplyProces s or
CRouteReques tProces s or
TheControlPktProces s or
TheRouteReques tProces sor
CRouteErrorProces s orBasicCRouteReplyProcess orBas ic
Infrastructure classesParent classes
Child classes
Class view
PNode::PControlPktProcessor
CControlPktProces sor
CRouteErrorProces s or
TheControlPktProces s or
TheRouteErrorProcess or
CRouteReplyProcess or
TheControlPktProces s or
TheRouteReplyProces s or
CRouteReques tProces s or
TheControlPktProces s or
TheRouteReques tProces sor
CRouteErrorProces s orBasicCRouteReplyProcess orBas ic
Infrastructure classesParent classes
Child classes
Processing RREQ (1)
Infrastructure classes
Parent classes
Child classes (only a small sample)
CControlPktProcessor
CRouteRequestProcessor
CRouteSearchSecurity
CRouteSearchSecurityDefault
CRouteSearchTopologyController
CRouteSearchTopologyControllerDefault
CRouteSearchRegionEnforcer
CRouteSearchRegionEnforcerDefault
CRouteReplyGenerator
CRouteReplyGeneratorBasic
CTopologyAppender
CTopologyAppenderBasic
Processing RREQ (2)
The ControlPkt
Proces s or
The RouteRequest
Proces s or
Proces s NewPkt
RREQProcess ingCom plete
The RouteSearch Securi ty
Proces s or
Proces s NewPkt
SecurityProces s ingCom plete
The RouteSearch Topology
Controller
Proces s NewPkt
SearchTopologyControlCom plete
The RouteReply
Generator
Proces s RouteReques t(Pkt)
RouteReplyGeneratorCom plete(Pkt, Succes s)
The RouteSearch Region
Enforcer
Proces s NewPkt(Pkt)
SearchTopologyControlCom plete(Pkt, Succes s)
The TopologyAppender
AppendTopologyToRREQ(Pkt)
AppendTopologyToRREQCom plete(Pkt, Succes s)
Packet arrivesfrom TheNode
If s ecurity is OK
If topology info is ok (e.g., goodlinks , loop-free)
If the RREQ is to be flooded
If the s earch region has not been violated
Pkt goes to FloodProces s or
Note the interfaces are shown
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
Processing RREQ
The ControlPkt
Proces s or
The RouteRequest
Proces s or
Proces s NewPkt
RREQProcess ingCom plete
The RouteSearch Securi ty
Proces s or
Proces s NewPkt
SecurityProces s ingCom plete
The RouteSearch Topology
Controller
Proces s NewPkt
SearchTopologyControlCom plete
The RouteReply
Generator
Proces s RouteReques t(Pkt)
RouteReplyGeneratorCom plete(Pkt, Succes s)
The RouteSearch Region
Enforcer
Proces s NewPkt(Pkt)
SearchTopologyControlCom plete(Pkt, Succes s)
The TopologyAppender
AppendTopologyToRREQ(Pkt)
AppendTopologyToRREQCom plete(Pkt, Succes s)
Packet arrivesfrom TheNode
If s ecurity is OK
If topology info is ok (e.g., goodlinks , loop-free)
If the RREQ is to be flooded
If the s earch region has not been violated
Pkt goes to FloodProces s or
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.
Processing RREQ
The ControlPkt
Proces s or
The RouteRequest
Proces s or
Proces s NewPkt
RREQProcess ingCom plete
The RouteSearch Securi ty
Proces s or
Proces s NewPkt
SecurityProces s ingCom plete
The RouteSearch Topology
Controller
Proces s NewPkt
SearchTopologyControlCom plete
The RouteReply
Generator
Proces s RouteReques t(Pkt)
RouteReplyGeneratorCom plete(Pkt, Succes s)
The RouteSearch Region
Enforcer
Proces s NewPkt(Pkt)
SearchTopologyControlCom plete(Pkt, Succes s)
The TopologyAppender
AppendTopologyToRREQ(Pkt)
AppendTopologyToRREQCom plete(Pkt, Succes s)
Packet arrivesfrom TheNode
If s ecurity is OK
If topology info is ok (e.g., goodlinks , loop-free)
If the RREQ is to be flooded
If the s earch region has not been violated
Pkt goes to FloodProces s or
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.
Processing RREQ
The ControlPkt
Proces s or
The RouteRequest
Proces s or
Proces s NewPkt
RREQProcess ingCom plete
The RouteSearch Securi ty
Proces s or
Proces s NewPkt
SecurityProces s ingCom plete
The RouteSearch Topology
Controller
Proces s NewPkt
SearchTopologyControlCom plete
The RouteReply
Generator
Proces s RouteReques t(Pkt)
RouteReplyGeneratorCom plete(Pkt, Succes s)
The RouteSearch Region
Enforcer
Proces s NewPkt(Pkt)
SearchTopologyControlCom plete(Pkt, Succes s)
The TopologyAppender
AppendTopologyToRREQ(Pkt)
AppendTopologyToRREQCom plete(Pkt, Succes s)
Packet arrivesfrom TheNode
If s ecurity is OK
If topology info is ok (e.g., goodlinks , loop-free)
If the RREQ is to be flooded
If the s earch region has not been violated
Pkt goes to FloodProces s or
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.
Processing RREQ
The ControlPkt
Proces s or
The RouteRequest
Proces s or
Proces s NewPkt
RREQProcess ingCom plete
The RouteSearch Securi ty
Proces s or
Proces s NewPkt
SecurityProces s ingCom plete
The RouteSearch Topology
Controller
Proces s NewPkt
SearchTopologyControlCom plete
The RouteReply
Generator
Proces s RouteReques t(Pkt)
RouteReplyGeneratorCom plete(Pkt, Succes s)
The RouteSearch Region
Enforcer
Proces s NewPkt(Pkt)
SearchTopologyControlCom plete(Pkt, Succes s)
The TopologyAppender
AppendTopologyToRREQ(Pkt)
AppendTopologyToRREQCom plete(Pkt, Succes s)
Packet arrivesfrom TheNode
If s ecurity is OK
If topology info is ok (e.g., goodlinks , loop-free)
If the RREQ is to be flooded
If the s earch region has not been violated
Pkt goes to FloodProces s or
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.
CPacket
CPacket
RREQInfoExists:boolRERRInfoExists:boolRREPInfoExists:boolDataExists:boolDestinationID:CNodeIDTransmitterID:CNodeID
CPayload
Payload
CRERRInfo
TheRERRInfo
CRREPInfo
TheRREPInfo
CRREQInfo
TheRREQInfo
CRawPacket
RawPktIn
RawPktOut
PTopologyInfo
CGeneralizedLinkLastHop
CRREQInfoBasic CRREPInfoBasic CRERRInfoBasic
Fixed parent classes(these contain attributes)
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.
Protocol designer designed child
classes
CPacket
CPacket
RREQInfoExists:boolRERRInfoExists:boolRREPInfoExists:boolDataExists:boolDestinationID:CNodeIDTransmitterID:CNodeID
CPayload
Payload
CRERRInfo
TheRERRInfo
CRREPInfo
TheRREPInfo
CRREQInfo
TheRREQInfo
CRawPacket
RawPktIn
RawPktOut
PTopologyInfo
CGeneralizedLinkLastHop
CRREQInfoBasic CRREPInfoBasic CRERRInfoBasic
TheMacInterface must provide LastHop information and raw bytes
Fixed parent classes(these contain attributes)
Protocol designer designed child
classes
CPacket
CPacket
RREQInfoExists:boolRERRInfoExists:boolRREPInfoExists:boolDataExists:boolDestinationID:CNodeIDTransmitterID:CNodeID
CPayload
Payload
CRERRInfo
TheRERRInfo
CRREPInfo
TheRREPInfo
CRREQInfo
TheRREQInfo
CRawPacket
RawPktIn
RawPktOut
PTopologyInfo
CGeneralizedLinkLastHop
CRREQInfoBasic CRREPInfoBasic CRERRInfoBasic
Fixed parent classes(these contain attributes)
Protocol designer designed child
classes
CRREQInfo
AppendedTopologyInfo:CTopologyInfoOriginatorOfRREQ:CNodeID
operator<<(RawPkt:CRawPacket):voidoperator>>(RawPkt:CRawPacket):voidoperator==(other:CRREQInfo):boolCompareToDesiredDestination(Dest:CNodeID):bool
CRREQInfoBasic
CRREQInfo - RREQ information within packetsP
aren
t cl
ass
Chi
ld c
lass
Already discussed
All RREQ’s must have an originator
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)
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)
PTopologyInfoParent class
Child classes
Infrastructure classes
Parent class
Child classes
‘*’ = list
CTopologyInfo
CTableInfoBidirectional CPathInfoBidirectional
CGeneralizedLink
NextHop:CGeneralizedLink
*PathGeneralizedLinkToGo
CNodeIDReceiverID
TransmitterID
CLinkAttribute
*LinkAttributes
CHopCount CLinkSignalStrength CFreshness CRadio
Note that table or path is orthogonal to path metric (e.g., hop count, signal strength, …)
CLinkAttribute
operator>>(RawPkt:CRawPacket):voidoperator<<(RawPkt:CRawPacket):voidoperator+=(OtherLinkAttribute:CLinkAttribute):void
CHopCount
CLinkSignalStrength
CFreshness
operator<<(RawPkt:CRawP...operator>>(RawPkt:CRawP...operator+=(OtherLinkAttribu...
CLinkAttribute
Abstractfunctions
For putting (getting) the attribute into (out of) the
packet
Update attribute
CLinkSignalStrength: A+=B => A = min(A, B) (the worst link)
CHopCount: A+=B => A = A + B
CFreshness: A+=B => A = min(A, B) (the oldest link)
Independent of the what the link attribute is, the interface is the same
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
Pkt.RREQInfo->AppendedTopologyInfo->AppendObservedLink(LastHop);
The RREQ part of the pkt
The AppendedTopology could
be of any type
The task needed.Every child of CTopologyInfo MUST
be able to perform this task.=> AppendObservedLink must be
part of the interface of CTopologyInfo.
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.Identified the tasks (interface) that the fundamental object must provide.
This is a generic type too.The TopologyInfo does not depend on link information.
CPathInfoBidirectional
• Simply append Generalized link onto the Path attribute
• Bidirectionality impacts route search
AppendObservedLink
CTableInfoBidirectional
• CGeneralizedLink GL = LastHop;
• GL.FlipDirections(); // bidirectional
• GeneralizedLinkToGo.Transmitter = TheNode->ID; //now this node is at the end of the path
• GeneralizedLinkToGo.LinkAttributes+=LastHop.LinkAttributes;
CTopologyInfoCenter
CTopologyInfoAssimilatorCTopologyDatabaseFront
CTopologyRouteSearchEngine
CTopologyRouteSearchEngineLeastHopsForPathBased
CTopologyRouteSearchEngineLeastHopsForTableBased
CTopologyInfo
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!
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