https://www.nsnam.org/docs/release/3.10/manual/html/routing.html#fig-routing

---

Routing overview

ns-3 is intended to support traditional routing approaches and protocols, support ports of open source routing implementations, and facilitate research into unorthodox routing techniques. The overall routing architecture is described below in Routing architecture. Users who wish to just read about how to configure global routing for wired topologies can read Global centralized routing. Unicast routing protocols are described in Unicast routing. Multicast routing is documented in Multicast routing.

ns-3打算支持传统路由方法和协议，支持各种开源路由实现，促进对非传统路由技术的研究。整体路由体系描述如下图“Routing architecture”。读者想阅读关于如何为有线拓扑配置全局路由，可以阅读“全局集中式路由”。单播路由协议在“单播路由”里描述，多播路由在“组播路由”描述。

路由概述

Overview of routing shows the overall routing architecture for Ipv4. The key objects are Ipv4L3Protocol, Ipv4RoutingProtocol(s) (a class to which all routing/forwarding has been delegated from Ipv4L3Protocol), and Ipv4Route(s).

路由概述展示了Ipv4的整体路由架构。关键对象是Ipv4L3Protocol，Ipv4RoutingProtocol(s)（一个所有路由／转发方法都被Ipv4L3Protocol托管的类）和Ipv4Route(s)。Ipv4L3Protocol must have at least one Ipv4RoutingProtocol added to it at simulation setup time. This is done explicitly by calling Ipv4::SetRoutingProtocol ().当仿真启动的时候，Ipv4L3Protocol中必须至少有一个Ipv4RoutingProtocol。调用Ipv4::SetRoutingProtocol ()明确表示完成。

The abstract base class Ipv4RoutingProtocol () declares a minimal interface, consisting of two methods: RouteOutput () and RouteInput (). For packets traveling outbound from a host, the transport protocol will query Ipv4 for the Ipv4RoutingProtocol object interface, and will request a route via Ipv4RoutingProtocol::RouteOutput (). A Ptr to Ipv4Route object is returned. This is analagous to a dst_cache entry in Linux. The Ipv4Route is carried down to the Ipv4L3Protocol to avoid a second lookup there. However, some cases (e.g. Ipv4 raw sockets) will require a call to RouteOutput() directly from Ipv4L3Protocol.

抽象基类Ipv4RoutingProtocol ()声明了一个最小接口，包括两个方法：RouteOutput () 和 RouteInput ()。当数据包从主机往外发出，传输层协议会查询Ipv4来获取一个Ipv4RoutingProtocol对象接口，然后通过Ipv4RoutingProtocol::RouteOutput ()获取一个路由。一个Ipv4Route的指针将会返回。这跟Linux里的dst_cache entry类似。这个Ipv4Route会带下到Ipv4L3Protocol防止再次寻找。然后，有些情况下（e.g. Ipv4 raw sockets）会直接从Ipv4L3Protocol调用RouteOutput()。

For packets received inbound for forwarding or delivery, the following steps occur. Ipv4L3Protocol::Receive() calls Ipv4RoutingProtocol::RouteInput(). This passes the packet ownership to the Ipv4RoutingProtocol object. There are four callbacks associated with this call:

LocalDeliver

UnicastForward

MulticastForward

Error

当数据包收到用于转发或投递，以下步骤将会发生。 Ipv4L3Protocol::Receive()调用Ipv4RoutingProtocol::RouteInput()。这传递数据包所有权给Ipv4RoutingProtocol对象。有四个回调方法跟这次调用关联：

本地投递

单播转发

组播转发

错误

The Ipv4RoutingProtocol must eventually call one of these callbacks for each packet that it takes responsibility for. This is basically how the input routing process works in Linux.Ipv4RoutingProtocol对象对每一个数据包，根据它的任务，最终调用其中一个回调。这基本上是输入路由进程如何运行在Linux的方式。

“Ipv4Routing specialization.”This overall architecture is designed to support different routing approaches, including (in the future) a Linux-like policy-based routing implementation, proactive and on-demand routing protocols, and simple routing protocols for when the simulation user does not really care about routing.

整体架构为了支持不同路由方案而设计，包括基于仿Linux机制的路由实现，主动和按需路由协议，还有简单的路由协议当仿真用户不关心路由方法。

Ipv4Routing specialization. illustrates how multiple routing protocols derive from this base class. A class Ipv4ListRouting (implementation class Ipv4ListRoutingImpl) provides the existing list routing approach in ns-3. Its API is the same as base class Ipv4Routing except for the ability to add multiple prioritized routing protocols (Ipv4ListRouting::AddRoutingProtocol(), Ipv4ListRouting::GetRoutingProtocol()).

“Ipv4Routing specialization.”

阐述了多张路由协议如何从基类派生。Ipv4ListRouting类（Ipv4ListRoutingImpl为实现类）提供ns-3中已存在的路由方案。除了不能添加多种优先级的路由协议(Ipv4ListRouting::AddRoutingProtocol(), Ipv4ListRouting::GetRoutingProtocol())，它的api跟基类Ipv4Routing一样。

The details of these routing protocols are described below in Unicast routing. For now, we will first start with a basic unicast routing capability that is intended to globally build routing tables at simulation time t=0 for simulation users who do not care about dynamic routing.

这些路由协议的细节在“单播路由”里描述。现在，我们从一个在仿真用户不关心动态路由前提下，仿真时间t＝0全局建立路由表的基本路由协议开始。

Global centralized routing

Global centralized routing is sometimes called “God” routing; it is a special implementation that walks the simulation topology and runs a shortest path algorithm, and populates each node’s routing tables. No actual protocol overhead (on the simulated links) is incurred with this approach. It does have a few constraints:Wired only: It is not intended for use in wireless networks.Unicast only: It does not do multicast.Scalability: Some users of this on large topologies (e.g. 1000 nodes) have noticed that the current implementation is not very scalable. The global centralized routing will be modified in the future to reduce computations and runtime performance.

全局集中式路由选择有时被称为“上帝”路由选择；它是一个跑仿真拓扑，运行最短路径算法，填充每一个节点的路由表。使用这种方案，没有真正的路由开销（在仿真链路）需要承担。它有几种限制：只能有线: 它不是为了无线网络使用.只能单播: 不做组播.可拓展性: 有些组成了大型拓扑的用户发现了现存实现不是很具备可拓展性。全局集中式路由选择未来会修改来降低计算量和运行表现。

Presently, global centralized IPv4 unicast routing over both point-to-point and shared (CSMA) links is supported.

目前，全局集中式IPv4单播路由选择在点对点和共享（CSMA）链路都已支持。

By default, when using the ns-3 helper API and the default InternetStackHelper, global routing capability will be added to the node, and global routing will be inserted as a routing protocol with lower priority than the static routes (i.e., users can insert routes via Ipv4StaticRouting API and they will take precedence over routes found by global routing).

默认，当使用ns-3 helper API和默认的InternetStackHelper，全局路由能力会被添加到这个节点，全局路由选择以低于静态路由优先级的路由协议插入。（例如：用户可以通过Ipv4StaticRouting API插入路由，然后它们会被全局路由选择优先发现）

Global Unicast Routing API

The public API is very minimal. User scripts include the following::

#include "ns3/helper-module.h"

If the default InternetStackHelper is used, then an instance of global routing will be aggregated to each node. After IP addresses are configured, the following function call will cause all of the nodes that have an Ipv4 interface to receive forwarding tables entered automatically by the GlobalRouteManager::

Ipv4GlobalRoutingHelper::PopulateRoutingTables ();

Note: A reminder that the wifi NetDevice will work but does not take any wireless effects into account. For wireless, we recommend OLSR dynamic routing described below.

It is possible to call this function again in the midst of a simulation using the following additional public function::

Ipv4GlobalRoutingHelper::RecomputeRoutingTables ();

which flushes the old tables, queries the nodes for new interface information, and rebuilds the routes.

For instance, this scheduling call will cause the tables to be rebuilt at time 5 seconds::

Simulator::Schedule (Seconds (5),  &Ipv4GlobalRoutingHelper::RecomputeRoutingTables);

There are two attributes that govern the behavior. The first is Ipv4GlobalRouting::RandomEcmpRouting. If set to true, packets are randomly routed across equal-cost multipath routes. If set to false (default), only one route is consistently used. The second is Ipv4GlobalRouting::RespondToInterfaceEvents. If set to true, dynamically recompute the global routes upon Interface notification events (up/down, or add/remove address). If set to false (default), routing may break unless the user manually calls RecomputeRoutingTables() after such events. The default is set to false to preserve legacy ns-3 program behavior.

Global Routing Implementation

This section is for those readers who care about how this is implemented. A singleton object (GlobalRouteManager) is responsible for populating the static routes on each node, using the public Ipv4 API of that node. It queries each node in the topology for a “globalRouter” interface. If found, it uses the API of that interface to obtain a “link state advertisement (LSA)” for the router. Link State Advertisements are used in OSPF routing, and we follow their formatting.

The GlobalRouteManager populates a link state database with LSAs gathered from the entire topology. Then, for each router in the topology, the GlobalRouteManager executes the OSPF shortest path first (SPF) computation on the database, and populates the routing tables on each node.

The quagga (http://www.quagga.net) OSPF implementation was used as the basis for the routing computation logic. One benefit of following an existing OSPF SPF implementation is that OSPF already has defined link state advertisements for all common types of network links:

point-to-point (serial links)

point-to-multipoint (Frame Relay, ad hoc wireless)

non-broadcast multiple access (ATM)

broadcast (Ethernet)

Therefore, we think that enabling these other link types will be more straightforward now that the underlying OSPF SPF framework is in place.

Presently, we can handle IPv4 point-to-point, numbered links, as well as shared broadcast (CSMA) links, and we do not do equal-cost multipath.

The GlobalRouteManager first walks the list of nodes and aggregates a GlobalRouter interface to each one as follows::

typedef std::vector < Ptr>::iterator Iterator;

for (Iterator i = NodeList::Begin (); i != NodeList::End (); i++)  {    

       Ptrnode = *i;    

       PtrglobalRouter = CreateObject(node);

       node->AggregateObject (globalRouter);

}

This interface is later queried and used to generate a Link State Advertisement for each router, and this link state database is fed into the OSPF shortest path computation logic. The Ipv4 API is finally used to populate the routes themselves.