[Ns-bugs] [Bug 671] RecvIfIndex tag in sockets

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=671





--- Comment #8 from Tom Henderson <tomh at tomh.org>  2010-01-06 01:12:47 EDT ---

> You can see the example of this tag usage as follows.
> 
> http://www.sfc.wide.ad.jp/~tazaki/hg/ns-3-simu_zebra_ipv6-2nd/diff/fc2c29a13125/src/process-manager/unix-datagram-socket-fd.cc

Yes, I agree and understand how you want to use it.

> 
> 
> I didn't understand what you meant in the following sentence.
> 
> > If you look at the implementation of raw
> >sockets, the packets are not preserved across the sockets API boundary.  
> 
> How can I see the sockets API boundary?

Actually, I think we are OK on this point.  Packets are queued in a
std::list<struct Data> m_data, and the tag will be kept on the packet as it is
delivered across the API using Recv().

So, the issue seems to be what we add and how/where to add it.  The place in
LocalDeliver where I added it will not work for the raw sockets.  I'm not even
sure that the raw socket reception code is correctly placed in the input path
processing, but in any case, the current patch will not support raw sockets so
clearly we should fix this since it is IPv6 RS that wants to use it, among
others.

> 
> 
> FYI, I took a look of other OS implementation.
> 
> In NetBSD, struct pkthdr, which is pointed from struct mbuf,
> includes rcvif information. This value seems to be added at
> NIC driver codes, and delivered as ipi6_ifindex in
> IPV6_PKTINFO.
> 
> In Linux, struct net_device, which is pointed from struct
> sk_buff, includes iif information. This value seems to be
> added at sk_buff allocation, and delivered as ipi6_ifindex
> in IPV6_PKTINFO.
> 
> The recv if information is handled by device driver in above case.
> In ns-3, we can also handle in every NetDevice class, but I took to implement
> in class Node instead.

If we make it added in the Node, my main issue was that it added a socket
dependency where we have avoided it in the past.  To avoid this dependency but
add at a low layer, we could instead call it a RecvIfIndex tag and declare it
in net-device.h.  I also noticed that it was causing asserts in some scripts to
add this tag at a low layer since a Packet received on CSMA interfaces is
received on multiple interfaces before being thrown away by non-recipients.  We
should also double check that adding this tag to packets that we ultimately are
throwing away (since they are not for us) will not cause a deep buffer copy of
the packet.

Another question I have is whether users will come back at a later date asking
for all of these RFC 2292 values:
       1.  the destination IPv6 address,
       2.  the arriving interface index, and
       3.  the arriving hop limit.
and not just the arriving interface index, and that we might want to just make
this tag an IP_PKTINFO tag with multiple fields.  What do you think-- will we
end up needing to fully support the ancillary data fields for ns-3-simu? 
Should they be handled in one or multiple tags?

-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.