Difference between revisions of "IPv4 cleanup"

From Nsnam
Jump to: navigation, search
(remove old outdated material on ipv4 cleanup)
(→‎API issues)
 
(9 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;
+
−
 
+
−
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.
+

Latest revision as of 06:50, 22 June 2009

Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects

Installation - Troubleshooting - User FAQ - HOWTOs - 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"