[ndnSIM] question about fragmentation implementation
alexander.afanasyev at ucla.edu
Fri Jun 7 09:55:37 PDT 2013
Thanks for the explanation.
So, it should be pretty straightforward to implement the intra-hop fragmentation. The following assumes that you don't care about Interest/Data packets. If you need to distinguish, you would need to use ndn::HeaderHelper::GetNdnPacketType method. (The "future" plan is to have SendInterestImpl and SendDataImpl eventually, but I haven't got to that point yet.)
As a first step, you should create a new Face class, inherited from ndn::NetDeviceFace, overriding RegisterProtocolHandler and SendImpl and implementing new ReceiveFromNetDeviceFragmented method (similar to existing ReceiveFromNetDevice, but with different things in it).
In SendImpl you would need to chop off packet into pieces and add appropriate fragmentation headers (you'll need to implement a fragmentation header class, similar way Interest/Data class are implemented, then use packet->AddHeader method to add header). After that, you can send packet same way it is done in NetDeviceFace::SendImpl (using m_netDevice->Send).
For the opposite part, you will need to implement assembly in ReceiveFromNetDeviceFragmented, which you "register" in overloaded RegisterProtocolHandler method. Don't forget to change EthernetFrame type. So you'll need to do something like:
m_node->RegisterProtocolHandler (MakeCallback (&FragmenationNetDeviceFace::ReceiveFromNetDeviceFragmented, this),
FragmenationNetDeviceFace::ETHERNET_FRAME_TYPE, m_netDevice, true/*promiscuous mode*/);
If should also call parent's class RegisterProtocolHandler:
this way, non fragmented packets will go to NDN stack directly (so, the same NetDevice will properly handle fragmented and non-fragmented packets).
After assembly, you can simply call Receive (p), which will propagate packet to NDN stack.
After you implement your class, you will need to do something like this in your scenarios:
a) create a method
FragmentedNetDeviceFaceCallback (Ptr<Node> node, Ptr<ndn::L3Protocol> ndn, Ptr<NetDevice> device)
NS_LOG_DEBUG ("Creating ndn::FragmentedNetDeviceFace on node " << node->GetId ());
Ptr<ndn::NetDeviceFace> face = CreateObject<ndn::FragmentedNetDeviceFace> (node, device);
b) call UpdateNetDeviceFaceCreateCallback of ndn::StackHelper before you install stack on nodes
helper.UpdateNetDeviceFaceCreateCallback (ndn::FragmentedNetDeviceFace::GetTypeId (), MakeCallback (FragmentedNetDeviceFaceCallback));
This way, a correct NetDeviceFace will be automatically created during Install phase.
Let me know if you have questions.
On Jun 5, 2013, at 6:26 PM, Naveen Nathan <nnathan at uci.edu> wrote:
> Hi Alex,
> Thanks for the prompt reply.
> See below.
>> I guess, the implementation way would depend on fragmentation type. I didn't not fully understood the terminology (intra-hop, cut through), but I guess one means that each router can chop off interest/data and the next router on the path will assemble it back before processing (like NDNLP does). The other way is something like IP fragmentation.
> Sorry, hopefully this will explain intra-hop versus cut-through:
> Intra-hop fragmentation:
> * If a packet exceeds the MTU of an outgoing interface, it must break it into smaller packets (fragments) sized at the MTU.
> * The fragments are forwarded over the link.
> * The adjacent node/router will MUST receive all fragments, reassemble the original packet, before further processing (i.e. forward lookup, PIT lookup/satisfying interest, etc.).
> Cut-through fragmentation:
> * This is essentially the same as IP fragmentation. If a packet exceeds the MTU of an outgoing interface, it breaks it into smaller fragments. Each fragment contains a header to allow forwarding independent of the other fragments.
> * Adjacent nodes will forward fragments individually and are not required to store/retain/buffer fragments. It may do so if it plans to reassemble and cache content. Final destination MUST receive all fragments and also reassemble the original packet.
>> With the first type, you would need to implement a custom ndn::NetDeviceFace class. This face class would talk to the network with fragmented versions of packets, but present everything to NDN stack as normal Interest/Data packets.
> It would be ideal to have the packet format be at the NDN transport (perhaps what NDNLP uses), this way the fragmentation scheme is agnostic to the transport (TCP, UDP, Ethernet, etc.) used.
>> For the second type, I'm not really seeing how it can be implemented... Or I'm misunderstanding something. Isn't it router suppose to know the whole interest before figuring out what to do with the interest? Similar with data...
> Interest packets must be fragmented using intra-hop fragmentation/reassembly. Cut-through will not work, because you need to know the entire name before doing a FIB lookup.
> Content packets however can be fragmented in a cut-through manner. However, in some cases this still may not work (since the name and content fields are arbitrary size).
> For now, I want to try implementing just the interest fragmentation
> (intra-hop fragmentation and reassembly). This should be an easier task.
> From there, I would like to introduce a more elaborate cut-through scheme.
> I have a cut-through implementation in CCNx, but the problem is that due
> to the complexity of ccnd and the code, it is hard to keep maintained and
> there's too many details missing (such as signature verification). It also
> makes doing simulation difficult. That is why I would like to implement
> in ndnsim first, and gather some interesting results.
> Let me know if you need more explanation.
> Thanks Alex.
> - Naveen
More information about the ndnSIM