IPv4 cleanup: Difference between revisions

From Nsnam
Jump to navigation Jump to search
 
(11 intermediate revisions by the same user not shown)
Line 1: Line 1:
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
{{TOC}}


== Ipv4 ifIndex not the same as NetDevice ifIndex (bug 85) ==
This page lists things that need to be done for IPv4 and routing protocols.


We ought to consider an alternative to using ifIndex
== API issues ==
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
# Public API needed to look at or manipulate the ARP cache
subtle programming errors are likely.
#* '''Proposal:''' Defer to ns-3.6 or later
# <s>Ipv4StaticRouting:  split into unicast and multicast separate objects?  Or just remove Impl class?</s>
# <s>No way to remove an IP address from an interface
#* '''Proposal:''' Fix this for ns-3.5.  bugfix patch is in tracker.</s>
# Ipv4RoutingProtocol::RouteOutput() may require Ptr<Packet> for supporting Nix vector routing (and perhaps other use cases)
#* '''Proposal:''' Fix this for ns-3.5.
# Ipv4StaticRouting multicast mrouted API does not support VIFs and TTLs
#* For reference, see http://tldp.org/HOWTO/Multicast-HOWTO-7.html, MRT_ADD_MFC, MRT_DEL_MFC
#* '''Proposal:''' Defer to ns-3.6 or later
# GlobalRouteManager static API could be moved to a helper API
#* '''Proposal:''' ?? how to deal with API breakage
# Tunneling net device (Ipv4 in ipv4) will require a public entry point into Ipv4 so that packets can be looped back through
#* '''Proposal:''' Defer class Ipv4's API extension until we have working example
# Ipv4RoutingHelper API could be created and delegated the task of creating routing protocols, and passed into InternetStackHelper
# Multicast API for hosts (setting group membership, setting TTL, setting loopback behavior) needs to be completed
#* '''Proposal:''' Defer to ns-3.6 or later.


Craig Dowell did such a change in his [http://code.nsnam.org/craigdo/ns-3-ipv4/ 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.
== Bugs and cleanup ==


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.
* IpForward attribute (ipv4.cc) doesn't do anything (bug 63)
* <s>Ipv4L3Protocol needs a unit test or a module test</s> <- this has been started
* <s>some XXXs remain around the multi-address (ip aliasing) code
** Ipv4L3Protocol::LocalDeliver
** IPv4L3Protocol::IpForward
** ArpL3Protocol::Receive
** ArpL3Protocol::SendArpRequest
** ArpL3Protocol::SendArpReply
** Ipv4StaticRoutingImpl::LookupStatic
** Ipv4EndPointDemux::Lookup</s>
* case 4) of Ipv4L3Protocol::Send() is not implemented, but this case is for currently non-existent on-demand ad-hoc routing protocol
** n.b. this may be an invalid case anyway
* should some of the routing protocol interfaces be aggregated to node, or to Ipv4ListRouting?  Not clear.
* TcpL4Protocol::Send () probably needs to be passed a route from TcpSocketImpl() instead of looking up the route again
* Ipv4StaticRoutingImpl is not robust enough to be added as a standalone routing protocol (e.g. for hosts and not routers, to perform local delivery).


== Ipv4 multihoming design ==
== New features needed ==


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 ==
* Multicast
 
** add VIF (virtual interface) and better TTL handling logic, for multicast forwarding
The repository http://code.nsnam.org/tomh/ns-3-ip contains descriptions of the new API (README.routing.api) and design (README.routing.txt). 
** for multicast hosts, the API for group membership, TTL, loopback (multicast sockets)
 
* Ability to dump routing tables for logging/output
=== Static routing API as part of Ipv4 API ===
* helpers to provide iproute2-like interface
 
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;
 
is biased towards an on-demand approach to routing, and is probably not rich enough API.  There are a few problems here:
 
* sometimes, one wants to simply query whether a route is available rather than have the routing protocol search for a route if none is found. 
* it seems cleaner to not pass the packet for forwarding to the routing protocol, but instead to have the routing protocol just return routes (or a list of routes).  This can be finessed with the current callback-based API by passing an appropriate callback, but might be better to directly have the method pass back routes.
 
There probably needs to be two methods:
# a method to request a list of matching routes that are already stored in the agent, if any
# a method to ask the routing agent to try to discover a route if none exists
 
We should also revisit multicast implications, as Gustavo has inquired in the past (e.g. ability to pass back a list of multicast routes).
 
== 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

Latest revision as of 06:50, 22 June 2009

Main Page - Roadmap - Summer Projects - Project Ideas - Developer FAQ - Tools - Related Projects

HOWTOs - Installation - Troubleshooting - User FAQ - Samples - Models - Education - Contributed Code - Papers

This page lists things that need to be done for IPv4 and routing protocols.

API issues

  1. Public API needed to look at or manipulate the ARP cache
    • Proposal: Defer to ns-3.6 or later
  2. Ipv4StaticRouting: split into unicast and multicast separate objects? Or just remove Impl class?
  3. No way to remove an IP address from an interface
    • Proposal: Fix this for ns-3.5. bugfix patch is in tracker.
  4. Ipv4RoutingProtocol::RouteOutput() may require Ptr<Packet> for supporting Nix vector routing (and perhaps other use cases)
    • Proposal: Fix this for ns-3.5.
  5. Ipv4StaticRouting multicast mrouted API does not support VIFs and TTLs
  6. GlobalRouteManager static API could be moved to a helper API
    • Proposal: ?? how to deal with API breakage
  7. Tunneling net device (Ipv4 in ipv4) will require a public entry point into Ipv4 so that packets can be looped back through
    • Proposal: Defer class Ipv4's API extension until we have working example
  8. Ipv4RoutingHelper API could be created and delegated the task of creating routing protocols, and passed into InternetStackHelper
  9. Multicast API for hosts (setting group membership, setting TTL, setting loopback behavior) needs to be completed
    • Proposal: Defer to ns-3.6 or later.

Bugs and cleanup

  • IpForward attribute (ipv4.cc) doesn't do anything (bug 63)
  • Ipv4L3Protocol needs a unit test or a module test <- this has been started
  • some XXXs remain around the multi-address (ip aliasing) code
    • Ipv4L3Protocol::LocalDeliver
    • IPv4L3Protocol::IpForward
    • ArpL3Protocol::Receive
    • ArpL3Protocol::SendArpRequest
    • ArpL3Protocol::SendArpReply
    • Ipv4StaticRoutingImpl::LookupStatic
    • Ipv4EndPointDemux::Lookup
  • case 4) of Ipv4L3Protocol::Send() is not implemented, but this case is for currently non-existent on-demand ad-hoc routing protocol
    • n.b. this may be an invalid case anyway
  • should some of the routing protocol interfaces be aggregated to node, or to Ipv4ListRouting? Not clear.
  • TcpL4Protocol::Send () probably needs to be passed a route from TcpSocketImpl() instead of looking up the route again
  • Ipv4StaticRoutingImpl is not robust enough to be added as a standalone routing protocol (e.g. for hosts and not routers, to perform local delivery).

New features needed

  • Multicast
    • add VIF (virtual interface) and better TTL handling logic, for multicast forwarding
    • for multicast hosts, the API for group membership, TTL, loopback (multicast sockets)
  • Ability to dump routing tables for logging/output
  • helpers to provide iproute2-like interface
Retrieved from "https://www.nsnam.org/mediawiki/index.php?title=IPv4_cleanup&oldid=2886"