IPv4 cleanup

This page summarizes an effort to do some cleanup of the IPv4 API, routing, and class design. This is related to the following bugs in the database: 63, 64, 74, 85, and 219

Ipv4 ifIndex not the same as NetDevice ifIndex (bug 85)

We ought to consider an alternative to using ifIndex both in the NetDevice and in the API for Ipv4. These two indices are not the same; namely, the Ipv4 ifIndex (the underlying variable is Ipv4L3Protocol::m_nInterfaces) is often one greater than the NetDevice ifIndex due to the Ipv4 loopback interface not having a corresponding NetDevice.

At least we should consider changing one of these names because otherwise some subtle programming errors are likely.

Craig Dowell did such a change in his ns-3-ipv4 repo prior to the 3.1 release but it wasn't merged because it was thought to be destabilizing at the time.

Current status is to merge something like the above repo but make sure we just change it once the other changes below are made, so we don't have to change it multiple times.

Ipv4 multihoming design

Presently, we are not well set up to do IPv4 multihoming-- assigning more than one IPv4 address to an interface. We have two basic options: add multiple Ipv4Interface objects per NetDevice, or keep one Ipv4Interface object per NetDevice and allow it to hold more addresses. Solution is to adopt a new Ipv4InterfaceAddress class that corresponds to Linux if_addr, and allow the Ipv4Interface to hold a list of such addresses.

Routing issues

The repository http://code.nsnam.org/tomh/ns-3-ip contains descriptions of the new API (README.routing.api) and design (README.routing.txt).

Static routing API as part of Ipv4 API

Presently, this is part of the Ipv4 API, but probably should be split off so it is not a special case API for this routing protocol. What may make more sense is to have a static routing protocol that can be added as a routing protocol like any other.

Note this is bug 64 in the database.

Update: This has become an Ipv4StaticRouting protocol in the current repository.

Hierarchical routing/forwarding

The current design is fairly flat with each routing protocol being consulted in order to see whether it can route a packet. However, an expected use case is to have some kind of routing agent that queries for routes from multiple routing agents and applies policy, based on the metrics provided or other factors, to select from the possibly multiple routes. Note that this could be recursively hierarchical in the extreme, although in general there is only two levels of hierarchy typically.

In the revised architecture, a single routing protocol can be inserted, or we can have lists of protocols as we do now.

Current Ipv4Routing API

The current API for routing/forwarding a packet:

 virtual bool Ipv4::RequestRoute (uint32_t ifIndex,
                            const Ipv4Header &ipHeader,
                            Ptr<Packet> packet,
                            RouteReplyCallback routeReply) = 0;

and for looking up a route in the outbound direction:

 virtual bool RequestIfIndex (Ipv4Address destination,
                             uint32_t& ifIndex) = 0;

These can be improved and better aligned with Linux:

 // similar to Linux ip_route_input()
 virtual bool RouteInput  (Ptr<const Packet> p, const Ipv4Header &header, Ptr<const NetDevice> idev,
                            UnicastForwardCallback ucb, MulticastForwardCallback mcb,
                            LocalDeliverCallback lcb, ErrorCallback ecb) = 0;

 // similar to Linux ip_route_output()
 virtual Ptr<Ipv4Route> RouteOutput (const Ipv4Header &header, uint32_t oif, Socket::SocketErrno &errno) = 0;

This will better deal with multicast and will facilitate future addition of Linux-like routing cache and policy rules.

Class hierarchy

Experience with the existing class hierarchy has proven that it is difficult to extend because of the need to plumb new API through different interface and implementation classes in the system. This is believed to be partly due to the current support of a set of interface classes in src/node/ and a set of common L3 and L4 base classes on the implementations in src/internet-stack.

Some options to consider are:

• give up on supporting multiple implementations with interface classes, which would move src/node/ipv4.h (and tcp.h, udp.h, etc.) to src/internet-stack directory. However, we already have two independent implementations of TCP and are hoping to have independent implementations of the whole TCP/IP stack
• refactor the current src/internet-stack to avoid separate L3 and L4 base classes
• allow for judicious use of multiple inheritance

additionally, some dependencies on Ipv4 in the architecture are perceived to constrain the IPv6 integration effort. Many of the problems discovered are due to the use of class Ipv4Address through the stack, and work is underway to refactor to try to use a common base class Address.

Schedule

The below is an estimated timetable for this work:

• Nov. 1-30: Finish off Ipv4 refactoring
  • implement RouteInput()
  • implement multicast functions
  • implement static routing API
  • get all examples to run with the new plumbing
• Nov. 16-Dec 15: Try to make similar, parallel changes to Ipv6
• Dec. 1-15: Cleanup, tests, documentation, more example code
• Dec. 16-30: Begin reviews for ns-3.4 merge