Click：模块化软件路由器设计

4星 · 超过85%的资源 | 下载需积分: 50 | PDF格式 | 764KB | 更新于2024-07-26 | 56 浏览量 | 举报

"Click - 软件路由器论文是MIT博士生Eddie Kohler关于基于模块化设计的软件路由器的研究成果。这篇论文详细介绍了Click模块化路由器的设计理念和实现方法，探讨了如何通过组合不同的模块来构建灵活且可配置的路由器。" 在软件定义网络（SDN）领域，Click是一款具有里程碑意义的开源软件路由器项目。它由麻省理工学院（MIT）的研究者开发，旨在解决传统路由器在灵活性和定制性上的局限。Click的核心特性在于其模块化设计，它将路由器的各种功能分解为独立的组件，称为元素（elements），这些元素可以是包分类、队列管理、调度算法或与网络设备交互的接口等基本功能。 Click路由器的配置是一个有向图，其中每个节点代表一个元素，边则表示数据包在处理过程中的流向。用户可以根据需求自由组合这些元素，形成特定的路由器配置，以满足不同的网络服务需求。例如，可以创建一个包含包分类、优先级队列和流量整形的配置，用于提供QoS（服务质量）保障。论文详细讨论了以下几个关键知识点： 1. **模块化设计**：Click的模块化架构允许开发者轻松添加新的处理模块或修改现有模块，以适应快速变化的网络环境。这种设计降低了复杂性，提高了代码复用性和可维护性。 2. **包处理流程**：每个元素负责执行特定任务，如接收数据包、修改包头或转发包到下一个元素。这种流水线处理方式提高了处理效率。 3. **动态重构**：Click支持在运行时动态改变路由器的配置，无需重启，从而实现了对网络状况的实时响应。 4. **网络功能虚拟化（NFV）**：Click为NFV提供了理想的平台，因为它允许在网络设备上快速部署和调整服务链，使得网络服务可以像云服务一样进行管理和扩展。 5. **性能优化**：尽管Click是软件实现，但通过精心设计的数据结构和算法，其性能接近硬件路由器，能够在普通PC硬件上高效运行。 6. **应用场景**：Click被广泛应用于研究、教育和实验网络，如测试新的路由策略、评估队列管理算法或构建自定义的网络服务。 7. **开源社区**：Click作为开源项目，拥有活跃的社区支持，不断有新贡献者加入，推动其功能的增强和维护。通过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页未读，继续阅读

johnkeepmoving

粉丝: 0

Click：模块化软件路由器设计

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

Click软件路由器的分布式数据层实现与扩展技术

构建Click系统下的MPLS软件路由器：功能实现与应用探索

论文研究-基于Click系统的包过滤防火墙软件路由器 .pdf

初级java笔试题-click:单击路由器文档

NAT-PT翻译网关在Click模块化软件路由器中的实现.pdf

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

Click模块化IPv6路由器性能测试方法研究.pdf

基于Click系统的无线Mesh路由器设计.pdf

点击与OpenFlow驱动的软件路由器创新研究

最新资源