Click模块化路由器软件架构详解

5星 · 超过95%的资源需积分: 34 109 浏览量更新于2024-07-24 收藏 764KB PDF 举报

"这篇资料是关于Click Modular Router的，由Eddie Kohler撰写，可能包含有关Click路由器的深入技术细节，适合那些希望深入理解Click的人阅读。该文档可能是Eddie Kohler在麻省理工学院攻读博士学位时的部分研究成果，最初提交于2000年11月，并在2001年进行了部分修正。" Click Modular Router是一个创新的软件架构，设计用于构建灵活且可配置的路由器。这个系统的核心概念是将路由器拆分为一系列称为元素的模块化包处理单元。每个元素负责执行路由器的基本功能，例如： 1. **包分类**：元素能够识别并区分不同类型的网络数据包，这在实施QoS（服务质量）策略或执行访问控制列表时非常关键。 2. **队列管理**：元素可以管理数据包的存储和发送顺序，通过不同的队列策略（如FIFO、优先级队列或WFQ等）来优化网络性能。 3. **调度**：元素负责决定何时以及如何发送数据包，确保网络资源的有效分配。 4. **与网络设备接口**：元素能够与物理网络接口、交换机、集线器等硬件设备交互，实现数据包的接收和发送。 Click路由器的配置是一个有向图，其中每个节点代表一个元素，边则表示数据包在元素间的流动路径。这种图形化配置方式使得路由器的行为可以根据需求进行动态调整和定制。用户可以通过连接不同的元素来创建复杂的功能，例如，可以构建一个包含高级流量整形、多协议支持和自定义过滤规则的路由器。 Click的灵活性和模块化设计使其成为研究和实验新型路由算法的理想平台。它允许研究人员快速原型设计和测试新的网络协议和策略，而无需依赖特定硬件。此外，Click也被广泛用于教育，因为它提供了深入理解路由器工作原理的实践机会。在实际应用中，Click路由器可能被部署在各种场景下，例如企业网络、数据中心内部通信、互联网边缘路由器或者作为网络仿真工具。其可扩展性和可编程性使其能够适应不断变化的网络需求，为网络管理员和开发者提供了强大的工具。总结来说，Click Modular Router是一种高度可定制和灵活的软件路由器架构，通过模块化元素组合实现路由器的各种功能，为网络研究和实践提供了强大的平台。学习和掌握Click，不仅可以深入了解网络路由的工作原理，还能为解决复杂的网络问题提供新的思路和解决方案。

Tee(2)

input port output ports

element class

configuration string

Figure 2.2—A sample element.

– Method interfaces. Each element exports methods that other elements may

access. This set of methods is grouped into method interfaces.

Every element supports at least the base method interface, which contains,

for example, methods for transferring packets. Elements can deﬁne and

implement arbitrary other interfaces on top of this; for example, Click’s

Queue element, which implements a FIFO packet queue, exports an inter-

face that reports its current length.

– Handlers. Handlers are methods that are exported to the user, rather than

to other elements in the router conﬁguration. They support simple, text-

based read/write semantics, as opposed to fully general method call se-

mantics. For example, the Queue element mentioned above has a handler

that reports its current length as a decimal ASCII string, and the Counter

element in Figure 2.1 provides a handler so users can access its current

count.

In the Linux kernel driver, handlers appear as ﬁles in the dynamic /proc

ﬁle system. At user level, handlers may be accessed via a TCP/IP-based

protocol.

Figure 2.2 shows how we diagram these properties for a sample element,

Tee(2). ‘Tee’ is the element class; a Tee copies each packet received on its

single input port, sending one copy to each output port. We draw input ports

as triangles and output ports as rectangles. Conﬁguration strings are enclosed

in parentheses: the ‘2’ in ‘Tee(2)’ is interpreted by Tee as a request for two

outputs. Method interfaces and handlers are not shown explicitly; they are

speciﬁed implicitly by the element class.

The element glossary in Appendix A provides a quick description of Tee

and every other element class mentioned in the text.

2.2 packets

A Click packet consists of a small packet header and the actual packet data;

the packet header points to the data. This structure was borrowed from the

Linux kernel’s packet abstraction, sk_buff. In the Linux kernel driver, Click

packet objects are equivalent to sk_buffs, which avoids translation or indi-

rection overhead when communicating with device drivers or the kernel itself.

This equivalence is hidden behind a C++ class, Packet. Other drivers reim-

plement this interface; the user-level driver, for example, has a hand-written

Packet implementation. Thus, elements may be compiled for either driver

without change. Operations on an in-kernel Packet have zero overhead over

the corresponding Linux sk_buff operations.

Several packet headers may share the same packet data. When copying

a packet—for example, with a Tee element—Click produces a new packet

header that shares the original data. Shared packet data is copy-on-write.

Elements that modify packet data ﬁrst ensure that it is unshared; if it is shared,

the element will make a unique copy of the data and change the packet header

to point to that copy. Packet headers are never shared, however, so header

modiﬁcations never cause a copy.

Headers contain a number of annotations in addition to a pointer to the

packet data. Annotations may be shared with Linux or speciﬁc to Click. Some

annotations contain information independent of the packet data—for exam-

ple, the time when the packet arrived. Other annotations cache information

about the data. For example, the CheckIPHeader element sets the IP header

annotation on passing IP packets. This annotation marks both where the IP

header begins and where the IP payload begins, freeing later elements from

examining the IP header’s length ﬁeld. Annotations are stored in the packet

header in a ﬁxed static order; there is currently no way to dynamically add a

new kind of annotation.

Packet data is stored in a single memory buffer. This differs from the

BSD-style mbuf structure, where data is stored in a linked chain of buffers.

Compared to mbufs, Linux and Click’s model allows simpler, faster access in

the common case, at the cost of occasional packet copies when prepending or

appending more data than will ﬁt into a particular buffer. Such copies do not

occur in our tests.

2.3 connections

A connection passes from an output port on one element to an input port

on another. Connections are the main mechanism used for linking elements

together; each connection represents a possible path for packet transfer be-

tween elements. In a running router, connections are represented as pointers

to element objects, and passing a packet along a connection is implemented

by a single virtual function call.

Connections are drawn as arrows; each arrow’s direction represents the

direction of packet ﬂow. Each connection links a source port to a destination

port. The source port is always an output port, and the destination port is

always an input port. We also use source element and destination element

with the obvious deﬁnitions.

Router conﬁgurations may be seen as directed graphs with elements as

vertices. However, connections link ports, not elements, and each element

may have many ports. A more complete model treats router conﬁgurations as

directed graphs with ports as vertices. Port graphs such as this have two kinds

of directed edges, ordinary connections and internal edges. Internal edges

show how packets may ﬂow from input ports to output ports within a single

element; an internal edge from an element’s input port i to its output port o

means that a packet that arrived on input port i might be emitted on output

port o. In the simplest model, every element has a complete graph of internal

edges—that is, there are internal edges linking every input to every output.

This is not always appropriate, however. For some elements, packets arriving

on a given input might be emitted on only a subset of outputs, or perhaps on

none at all. More speciﬁc internal edge information helps the system decide

which elements are reachable from a given port; in the long run, it will also

help check properties of conﬁgurations. Click elements can therefore specify

detailed internal edge information if they choose.

If a path exists from an output port o to an input port i in the port graph

representation of a router conﬁguration, then we say that i is downstream of

o, and, conversely, that o is upstream of i. This notion may also be generalized

to elements.

2.4 push and pull

Click supports two kinds of connections, push and pull, that implement com-

plementary kinds of packet transfer. On a push connection, packets start at the

source element and are passed downstream to the destination element. On a

pull connection, in contrast, the destination element initiates packet transfer:

it asks the source element to return a packet, or a null pointer if no packet is

available. Many software routers provide only push connections; Clark called

pull connections upcalls [8].

These forms of packet transfer are implemented by two virtual function

calls, push and pull. Neither kind of call is ever intended to block. For in-

stance, a pull call reaching an element with no packet ready should immedi-

ately return a null pointer rather than waiting for some packet to arrive. Click

is currently single-threaded, so a blocking design would simply hang.

FromDevice

Null Null

ToDevice

push(p)

return

pull()

return p

receive

packet p

enqueue p

ready to

transmit

dequeue p

and return it

send p

Figure 2.3—Push and pull control ﬂow. This diagram shows functions called as a packet

moves through a simple router; time moves downwards. During the push, control ﬂow

starts at the receiving device and moves forward through the element graph; during the pull,

control ﬂow starts at the transmitting device and moves backward. The packet p always

moves forward.

The type of a connection is determined by the ports at its endpoints. Each

port in a running router is either push or pull. Connections between two push

ports are push, and connections between two pull ports are pull; connections

between a push port and a pull port are illegal. Elements set their ports’ types

as the router is initialized. They may also create agnostic ports, which behave

as push when connected to push ports and pull when connected to pull ports.

In our conﬁguration diagrams, black ports are push and white ports are pull;

agnostic ports are shown as push or pull ports with a double outline.

Figure 2.3 shows how push and pull work in a simple router. This router

forwards packets unchanged from one network interface to another. The

central element in the ﬁgure is a Queue. This element enqueues packets on a

FIFO queue as they are pushed to its input, and yields packets from the front

of that queue as it receives pull requests on its output. The two Null elements,

which pass packets through unchanged, demonstrate agnostic ports.

Push connections are appropriate when unsolicited packets arrive at a

Click router—for example, when packets arrive from a device. The router

must handle such packets as they appear, if only to queue them for later con-

sideration. Pull connections are appropriate when the Click router needs to

control the timing of packet processing. For example, a router may transmit

a packet only when the transmitting device is ready. In Click, transmitting de-

vices are elements with one pull input. They use pull requests to initiate packet

transfer only when ready to transmit. Agnostic ports model the common case

that neither kind of processing is inherently required.

Pull connections also model the scheduling decision inherent in choosing

the next packet to send. A Click packet scheduler is simply an element with

multiple pull inputs and one pull output. It responds to a pull request by

FromDevice

ToDevice

Counter

ToDevice

Figure 2.4—Push and pull violations. The top conﬁguration has four errors: (1) FromDe-

vice’s push output connects to ToDevice’s pull input; (2) more than one connection from

FromDevice’s push output; (3) more than one connection to ToDevice’s pull input; and (4) an

agnostic element, Counter, in a mixed push/pull context. The bottom conﬁguration, which

includes a Queue, is legal. In a properly conﬁgured router, the port colors on either end of

each connection will match.

choosing one of its inputs, making a pull request to that input, and returning

the packet it receives. (If it receives a null pointer, it will generally try another

input.) These elements make only local decisions: different scheduling behav-

iors correspond to different algorithms for choosing an input. Thus, they are

easily composable. Section 4.3 discusses this further.

The following properties hold for all correctly conﬁgured routers: Push

outputs must be connected to push inputs, and pull outputs must be connected

to pull inputs. Each agnostic port must be used as push or pull exclusively.

Furthermore, if there is an internal edge linking an agnostic input port to an

agnostic output port on the same element, then the ports must be either both

push or both pull. Finally, push outputs and pull inputs must be connected

exactly once; this ensures that each packet transfer request—either pushing to

an output port or pulling from an input port—uses a unique connection. These

properties are automatically checked by the system during router initialization.

Figure 2.4 demonstrates some violations.

Conﬁgurations that violate these properties tend to be intuitively invalid.

For example, the connection from FromDevice to ToDevice in Figure 2.4 is

illegal because FromDevice’s output is push while ToDevice’s input is pull.

But this connection is intuitively illegal, since it would mean that ToDevice

might receive packets that it was not ready to send. The Queue element, which

converts from push to pull, also provides the temporary packet storage this

conﬁguration requires.

Some further notes on agnostic ports: Agnostic ports may be connected

to other agnostic ports. At initialization time, the system will propagate con-

straints until every agnostic port has been assigned to either push or pull. To

support agnostic ports, an element designer might write both a push function

and a pull function; only the relevant function will be called. Alternatively, the

剩余126页未读，继续阅读

sky108206306

粉丝: 0
资源: 1

Click模块化路由器软件架构详解

Click模块化路由（The Click Modular Router）

click 软件路由器

Click路由器：模块化设计与编程指南

如何通过Click路由器的模块化设计实现复杂网络功能的配置？请结合具体元素给出配置示例。

Click路由器的模块化设计如何支持IP路由、以太网交换和IP隧道等网络功能？请举例说明。

Click路由器的模块化设计是如何实现复杂网络功能配置的？请结合具体元素给出配置示例。

Click路由器的模块化元素如何具体实现数据包的分类和调度？请结合元素连接示例，深入剖析其在网络路由配置中的功能与作用。

click：Click模块化路由器：快速模块化数据包处理和分析

单机分布式实现：Click软件路由器方案详解

Click软件路由器的数据分发平台设计与实现

最新资源