An architecture for CBR for reactive routing. Objectives Motivation: there are many routing protocols and yet there is no single routing protocol is satisfactory

An architecture for CBR for reactive routing

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




Interfaces to packages

• PFloodPropagator– Floods packets (efficiently)


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




• PFloodPropagator– Floods packets


lookup. Packets with in queue during route search.

Interfaces to packages

PNode::PControlPktProcessor

PControlPktProcessor

CControlPktProcessor

PTopologyAppenderPSearchTopologyControl

PRouteSearchSecurity PRouteSearchRegionEnforcer

PRouteReplyGenerator

Package view


CControlPktProces sor

CRouteErrorProces s or

TheControlPktProces s or

TheRouteErrorProcess or

CRouteReplyProcess or


TheRouteReplyProces s or

CRouteReques tProces s or


TheRouteReques tProces sor

CRouteErrorProces s orBasicCRouteReplyProcess orBas ic

Infrastructure classesParent classes

Child classes

Class view


CControlPktProces sor

CRouteErrorProces s or


TheRouteErrorProcess or

CRouteReplyProcess or


TheRouteReplyProces s or

CRouteReques tProces 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



Proces s or

Proces s NewPkt



Controller

Proces s NewPkt


The RouteReply

Generator




Enforcer







If s ecurity is OK





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



Proces s or

Proces s NewPkt



Controller

Proces s NewPkt


The RouteReply

Generator




Enforcer







If s ecurity is OK





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



Proces s or

Proces s NewPkt



Controller

Proces s NewPkt


The RouteReply

Generator




Enforcer







If s ecurity is OK





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



Proces s or

Proces s NewPkt



Controller

Proces s NewPkt


The RouteReply

Generator




Enforcer







If s ecurity is OK





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

CComponentManager PNode PPacket

PTheMACInterfacePTopologyInfoCenter

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


CPayload

Payload

CRERRInfo

TheRERRInfo

CRREPInfo

TheRREPInfo

CRREQInfo

TheRREQInfo

CRawPacket

RawPktIn

RawPktOut

PTopologyInfo



TheMacInterface must provide LastHop information and raw bytes



classes

CPacket

CPacket


CPayload

Payload

CRERRInfo

TheRERRInfo

CRREPInfo

TheRREPInfo

CRREQInfo

TheRREQInfo

CRawPacket

RawPktIn

RawPktOut

PTopologyInfo





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)

Topology

CComponentManager PNode PPacket

PTheMACInterfacePTopologyInfoCenter

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

Documents

An architecture for CBR for reactive routing. Objectives Motivation: there are many routing protocols and yet there is no single routing protocol is satisfactory