RouteOutput RouteInput Forwarding

[Jack Higgins]

Dear all,

I am currently developing a proactive protocol  and I run into a problem after creating all the routes and wanting to use RouteOutput to start my app data flow.

In my topology there are multiple static nodes and 1 mobile node. There is an sensor set in each one of the nodes and this information needs to go in the end to the mobile node. The nodes do not send information to the mobile node directly but instead to a "clusters" that gather all the nodes packets and have direct communication with the mobile node.

N=node
C=cluster
MB=mobile node


N1 N2 N3 N4

N5 N6 N7 N8

C1       C2

MB--->


The clusters nodes are not known a priori but get selected as clusters during the routes creation process(all the routes in the nodes routing tables are created to point to the clusters). The applications are set to send packets to the mobile node after the creation of the routes to the clusters. As described in this post https://groups.google.com/forum/#!searchin/ns-3-users/routeoutput/ns-3-users/CDfqwyZUMv8/EwfrCeU_UP8J , updating or changing the Ipv4Header in RouteOutput is not possible so we can not change the destination to point to the assigned clusters.


Is it possible to add an extra header, tag or something else to add the address of the asigned cluster to each one of the packets inside RouteOutput?

Some suggestions seemed to be pointed in https://groups.google.com/forum/#!topic/ns-3-users/BpZSAEVJwzI , this post describes how you can make a loopback in RouteOutput to redirect to a RouteInput and make a new Ip4header (similar to packet buffering) and send it with a UnicastForwardCallback . This however, would make the final destination the cluster and I would not be able to access a Final RouteInput necessary to forward the packet from the cluster to the mobile node.

Which is the best way to implement a behaviour in which all the packets are sent to node clusters before being sent to a final destination? Are there any code examples of a similar protocol? (Something like ZRP which is not implemented in NS3) or what would be the correct way to implement such cases?

Please, any suggestion advice of how to proceed would be much appreciated. I apologize in advance if this description is too long or too "unclear".

[Tommaso Pecorella]

Hi,

what is clear is that you have to sit down and clarify yourself: you're mixing two completely different approaches and they are not compatible.

Option 1: normal routing.

Option 2: L7 routing.

In L7 routing (sometimes called semantic routing, CDN, etc.) you WANT to have the packets to be sent to the cluster node, eventually changing their IP address. There will be an application (hence the L7 approach) that will get the data and will re-send them to the mobile node. Routing is at L7.

In the "normal" routing, you just want to change the next hop in some (or all) the nodes, so the packets will "flow through" the cluster head, and these nodes will (eventually) hole the packets until they are able to send the packets to the appropriate node. There's no need to change the IP address in the packets in this case, as it's just a matter of playing with the node's routing tables.

In my opinion the "best" way doesn't exists. However, I'd use the normal routing approach, with the cluster nodes having a special RouteOutput function that, upon receiving the packet, doesn't discard them if the mobile node isn't in sight. Packets can be put in a queue and dequeued when the MN is near and/or if a timeout happens.

The "hard" part is to decide when the MN is close to the Cluster node, but... hey, it's your research, isn't it ? It wouldn't be fun if I give you all the solutions.

Cheers,

T.

[Jack Higgins]

Thank you for your reply Tommaso.
Your post made me think about my approach but is hard for me to define if my approach as "normal" or L7 routing. If I have to chose I would  prefer to handle things the "normal way": Look into the tables for the next hop and send the packet there.(Only that the routing tables in the nodes contains only cluster destinations!)

 I could be wrong  but isn't semantic routing more for cases where you do not know the destination and you change  constantly the destination IP "on the go"?
 In my case I know the destination  (the mobile node ip) but I want the packets to flow to one cluster or another depending the place they were the packets were created(Flow to the chosen cluster) The only way I can think of making this possible is to carry  the cluster ip address from the packet creation so each node route the packets according the cluster ip and still have as final destination the mobile node.

So there is no way to add information to the packets during the first RouteOutput call? or any other way :(

The way that the cluster handle the queue of packets  and try to send data to the mobile node is already defined so there is no problem in that point.

I hope this is not too repetitive or am I still stubbornly trying to mix a normal and L7  approach??

Thank you for your time
 

[Jack Higgins]

Forgot to mention. All the nodes must send to the cluster first.  No node have direct communication with the mobile node. Only Clusters.

[Tommaso Pecorella]

Hi Jack,

I'm sorry to say, but you definitely need to refresh your knowledge about how IP routing works.

What you're describing is plain, old, totally normal IP routing. You can call them "cluster", but they're routers, and IP routing works in the way you described.

As a consequence, either you're hiding some details or you didn't describe the problem well enough.

Cheers,

T.

[Jack Higgins]

Thank you for your patience and your answers Tom.

I believe you are right, I have not explain the whole picture.....
 In a few words. The application is set to send packets to the mobile node, but first the packets must be gathered and buffered in a cluster.
 The packets must follow specific routes to these specific clusters. Since the packets have a header marked to go to the mobile node and the nodes only contain routes to the  clusters attempting to send from the node with the header destination will always fail. Therefore, packets must be forwarded first to the clusters and then attempt to send to the header destination from there.

 I manage to make the packets go to the correct assigned clusters by adding a  tag with the correct cluster ip address to each packet and use this Address.

My only question is... how good is to use packet tags to accomplish this?
According to the description of Packet in the ns-3 docs : (https://www.nsnam.org/docs/models/html/packets.html?highlight=packet)
"developers often want to store data in packet objects that is not found in the real packets (such as timestamps or flow-ids). The Packet class deals with this requirement by storing a set of tags (class Tag)."

Does this mean that real life packets do not support adding information to packets via tags? and tags are meant to be use in ns-3 to merely to monitor ,flow control,debugging purposes? 
 If this is true, how come AODV and DSDV use in their core functionality  a deferredRouteTags to distinguish between packets that were loopbacked requiring to  be buffered and packets that need to be sent?   Would the use of tags this way in  AODV and DSDV make the code not implementable in real life?

Maybe its a dumb question, I just want to make sure my approach could be as implementable in real life as possible ,and I base some of my decision with the code of these two  well known examples.

Thank you again!

[Tommaso Pecorella]

Again, what you are trying to is a normal case for Internet, where one of the routers has the possibility to not forward packets right away (it's a router, but acts like a proxy).

The *only* thing you should make care of is that in the path from the source to the mobile node there is a cluster node. When a packet reaches the cluster node, the packet is NOT discarded if the mobile node is not in the cluster node routing table. that's all you need to do, the source doesn't need to know that there is a cluster node somewhere.

When you send an SMS to someone, do you know that there's a gateway somewhere holding the SMS until the detention is reachable ? No. This is the same situation.

What you are missing is that the cluster node should announce its ability to route packets to the mobile node even when the mobile node isn't in the cluster node visibility. In this way the routes will be built in advance and the packets will reach the cluster node even i the mobile node isn't there.

T.