NFD

commit:c2ee303880e6bfd79c107a4cda2cc28194356409 implements NetworkAddress similar to ns3::Address, but it has caused disputes, such as:

I'm confused about the NetworkAddress class, and since I can't see how it'll be used I don't know what's the best way to implement it. I'm also slightly worried about adding an overhead of 256 bytes for the two addresses to every packet.

Since all we need is equality comparison, we could do:

1. NetworkAddress is declared as a tuple that contains: a Transport pointer, a numeric index that indicates a peer within the Transport.

2. A Transport that is capable of multi-access links should maintain an internal map from a peer address to a numeric index.
   
   For example, in UdpTransport:

   1. UdpTransport has an internal map from IP+port to int is maintained.
   2. For each incoming packet, lookup its sourceIP+port in this map.
   3. If not found, insert sourceIP+port into this map, with a new numeric index (generated from an auto-increment counter).
   4. The remote NetworkAddress is a self pointer, and the numeric index in this map.
   5. Recently unused IP+port can be erased from the map.

This solution has less memory overhead than ns3::Address design, at the cost of a hashtable.

Who will be working on this issue?

20150908 conference call decides to take an approach similar to note-6.

NetworkAddress is renamed to Transport::EndpointId, and is a typedef of uint64_t.

A Transport should either fit the address into the 64 bits (enough for IPv4+port or Ethernet MAC address), or use an internal map as described in note-6.