|
|
| 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
| + | == Bugs and cleanup == |
| − | 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
| + | * IpForward attribute (ipv4.cc) doesn't do anything |
| − | subtle programming errors are likely.
| + | * Ipv4L3Protocol::GetStaticRouting() needs to be deleted |
| | | | |
| − | 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.
| + | == New features needed == |
| | | | |
| − | 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.
| + | * Multicast group membership |
| − | | + | * Netlink-like routing API |
| − | == Ipv4 multihoming design ==
| + | * Public API to look at the ARP cache |
| − | | + | * Ability to dump routing tables for logging/output |
| − | 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.
| + | * helpers to provide iproute2-like interface |
| − | | + | |
| − | == 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.
| + | |
