在计算机网络的学习中，由于网络近年来井喷式的发展，阅读一些论文是很有必要的，既有助于学习，也对网络能有更深的理解，后面，将会阅读一些计算机网络相关的论文，并将其翻译上传。
第一篇，选的是关于未来互联网架构的一个设想。
论文标题及作者：
原文及翻译，原文下载链接戳文末链接：
文中出现的一些缩写名词的解释：
NEBULA：就是NEBULA，整篇论文都围绕这玩意展开，简单来说，就是一种新颖的未来互联网架构，可解决云计算的网络挑战。
Zodiac：百度翻译成星座……放在原文里怎么看都很奇怪……正儿八经的翻译是黄道带、黄道十二宫图，在文中实在不知道应该翻译成什么，就直接引用原文了。
CGM：continuous glucose monitor, 连续血糖监测仪，原文中是用来举例子用的，和我们讨论的内容没啥关系。
CCN：Content-Centric Networking，以内容为中心的网络
NCore：the network core 中心网络
NDP：the NEBULA data plane NEBULA数据平面
NVENT：the NEBULA Virtual and Extensible Networking Techniques NEBULA虚拟可扩展网络技术
ICING：path verification mechanism 路径验证机
POC：proof of consent 同意证明？
POPs： proofs of provenance 出处证明？源出证明？感觉翻译得好接地气
HIPAA：HIPAA全称为：Health Insurance Portability and Accountability Act/1996，Public Law 104-19，尚没有确切的正式中文名称，国内文献一般直接称为HIPAA法案，有的称为健康保险携带和责任法案，也有取其意为医疗电子交换法案；台湾有文献翻译为义务型可携带式健康保险法案。（虽然这个翻译这么长但是它依然和我们讨论的内容没有什么卵关系，它只是用来举例的）
PS：翻译中红色的字体是我的吐槽/翻译中不确定的地方/注解
A Brief Overview of the NEBULA Future Internet Architectur
NEBULA的未来互联网体系结构简介
NEBULA is a proposal for a Future Internet Architecture. It is based on the assumptions that: (1) cloud computing will comprise an increasing fraction of the application workload offered to an Internet, and (2) that access to cloud computing resources will demand new architectural features from a network. Features that we have identified include dependability, security, flexibility and extensibility, the entirety of which constitute resilience. NEBULA provides resilient networking services using ultrareliable routers, an extensible control plane and use of multiple paths upon which arbitrary policies may be enforced. We report on a prototype system, Zodiac, that incorporates these latter two features.
NEBULA是一个未来的互联网架构的建议（proposal）。它基于这样的假设：（1）云计算将构成提供给互联网的应用工作负载的一小部分；（2），访问云计算资源将需求一种新的网络结构特征（new architectural features from a network.）。其中，我们已经确定的特征包括可靠性、安全性、灵活性和可扩展，这些构成整体的弹性（the entirety of which constitute resilience）。NEBULA通过使用超可靠的路由器，可扩展的控制平面以及多条路径的使用来提供弹性网络服务，并可以实施任意策略。我们报告的是一个原型系统，Zodiac，包含了后者的两个特征。
1. INTRODUCTION
引言
The Internet architecture [8, 23, 9] is an obvious success, with interesting applications continuing to emerge at a rapid pace. However, certain applications categories remain a concern. Imagine, for example, a healthcare application that might use a future Internet: a diabetic wears both an insulin pump and a continuous glucose monitor (CGM). Data from the CGM are sent over the network to a data center every 5 minutes, while other data such as images of meals, accelerometer readings of activity, etc., are sent as needed. These data are logged, and analyzed against both historical data from the individual and anonymized masses of data from other data sources. Machine learning algorithms are used to estimate appropriate micro-dosages of insulin to be delivered by the pump, as well as to detect anomalies that might can be forwarded to human experts who can ensure that no medical problem has occurred. Dosage values are downloaded using the network into the patient’s insulin pump.
互联网架构[8,23,9]取得了明显的成功，有趣的应用程序正在以飞快的速度不断涌现。但是，某些应用程序的类别仍然是一个问题。想象一下，例如，可能使用未来互联网的医疗保健应用程序：糖尿病患者同时佩戴胰岛素泵和连续血糖监测仪（CGM）。来自CGM的数据每5分钟通过网络发送到数据中心，而其他数据（如膳食图像，加速度计活动读数等）则根据需要发送。这些数据将被记录下来，并根据个人的历史数据和来自其他数据源的大量匿名数据进行分析。机器学习算法用于估计胰岛素的适当微量剂量，以及检测是否有异常情况，若存在异常，将会转发给人类专家，来确定时候发生医疗问题。剂量值会通过网络下载到患者的胰岛素泵中。
Such a healthcare application has clear dependability and security requirements. Such needs are clearly shared by other applications, including teleoperation of vehicles, telemanufacturing tasks such as remote 3-D printing, and remote feedback scenarios such as telesurgery. The challenge in designing an architecture, as opposed to a solution to a specific problem, is that one must anticipate the emergence of unanticipated applications. Any future Internet must preserve the existing Internet’s flexibility and extensibility while accommodating important new classes of applications, such as those sketched above. A key question is whether to attempt to enumerate many possible futures and accommodate all of them, or to pick a likely future and do research towards enabling that choice.
如上所述的医疗应用具有明确的可靠性和安全性要求。而其他应用程序同样这些需求，包括车辆遥控操作，遥控制造任务（如远程3D打印）和远程反馈场景（如远程手术）。与解决特定问题相比，设计架构所面临的挑战是必须预见出现意料之外的应用程序。任何未来的互联网必须保持现有的互联网的灵活性和可扩展性，同时适应重要的新类别的应用程序，例如上面描述的那些。一个关键的问题是是否试图列举许多可能的未来，并容纳所有这些未来，或选择一个可能的未来并进行研究以实现这一选择。
We chose the latter strategy, and focused NEBULA on cloud computing, as we discuss further in Section 3. We report on our architectural choices in Section 4, discuss integration in Section 5, an initial prototype in Section 6, some initial reflections on the project in Section 7 and conclude in Section 8.
我们选择后一种策略，并将NEBULA集中在云计算上，我们将在第3部分进一步讨论。我们在第4部分汇报了我们的架构选择，第5部分讨论了集成，第6部分讨论了初始原型，对项目进行了一些初步反思在第7节和第8节结束。
2. BACKGROUND/RELATEDWORK
背景/相关
Network design has many dimensions, but history has shown that extensibility to meet unanticipated application needs is extremely important. Telephony achieved extensibility by refining services offered using programmable switches , but premises equipment evolved more slowly.
网络设计有许多维度，但是历史表明，满足未预料到的应用需求的可扩展性是非常重要的。 电话通过使用可编程交换机提供服务（refining services？？啥服务？）来实现可扩展性，但是前提设备（premises equipment）的演变速度更慢。
The architecture of the Internet is based on both (1) an elegant interoperability model based on a packet-switching overlay using disparate subnets, and (2) well-chosen “rules of thumb” such as pushing the primary locus of evolution to the endpoints (hosts). This latter point has been key to exploiting the continuing exponential improvements incomputer performance due to Moore’s Law.
互联网的体系结构基于以下两点：（1）基于使用不同子网的包交换覆盖（packet-switching overlay）的精细（elegant）互操作性模型；（2）精心挑选的“经验法则”，例如推动发展的主要轨迹到端点（主机）。后者对于利用由摩尔定律引起的持续的指数式改进计算机性能至关重要。
The rapid evolution of endpoint services possible with computers attached to an Internet is clear, but it is also clear that the Internet model makes advanced in-network services, such as the desirable capability for IP-layer multicast, more difficult to deploy. Consequently, the Internet architecture makes it harder for the network itself to evolve.
连接到互联网的计算机可能实现的端点服务的快速发展是明显的，但同样清楚的是，互联网模型使得先进的网内服务（例如IP层组播（multicast）的理想能力）更难以部署。 因此，互联网架构使网络本身难以发展。
Attempts have been made to synthesize the evolvability advantages of telephony’s switches and the Internet’s end-hosts, perhaps most notably the approach of Active Networks [25] – networks that allowed both users and providers to dynamically deploy new services to support their applications. Interestingly, in fits and starts [13], elements of this approach have made their way into today’s Software-Defined Networks.
人们已经尝试综合电话交换机和互联网终端主机的可演进性优势，尤其是主动网络（Active Networks）的构建（approach） - 允许用户和提供商动态部署新服务以支持其应用的网络。 有趣的是，这种架构的元素已经进入了今天的软件定义网络。
Other approaches are possible. For example, Content-Centric Networking (CCN) [15] posits that the Internet architecture should evolve to focus on content, and routes named units of content rather than packets.In addition to the work originated by Jacobson, some additional proposals for Future Internets based on CCN have emerged. The eXtensible Internet Architecture(XIA)[2]projectis targeted at a content-centric architecture, but also at architectural extensibility. Named Data Networking [26] almost exactly follows Jacobson’s proposal.
其他方法是可能的。 例如，以内容为中心的网络（Content-Centric Networking，CCN）认为互联网体系结构应该发展为专注于内容的结构，并且路线应该以内容单元命名，而不是数据包。 除了雅各布森提供的工作（work）之外，还出现了一些基于CCN的未来互联网提案。可扩展互联网体系结构（XIA）项目针对的是以内容为中心的体系结构，同时也针对架构的可扩展性。 命名数据网络几乎完全遵循Jacobson的提议。
A different approach, more in line with that of NEBULA’s choice of one particular future, is MobilityFirst [24], which posits a future Internet driven by billions of mobile devices such as smartphones.
MobilityFirst是一种不同的方法，它更符合NEBULA选择某个特定未来的方案。该方法假定未来互联网是由智能手机等数十亿移动设备驱动的。
（MobilityFirst，查不出这个单词，是由伊万·塞斯卡尔，基兰·纳加拉贾，萨姆纳尔逊和迪坦卡·雷查杜胡里在ACM亚洲互联网工程会议提出的一种未来互联网架构。这里我就不翻译了，直接引用英文）
3. TARGETING THE CLOUD
瞄准“云”
The ubiquity of the Internet has given rise to a new form of computing, cloud computing [4], where services are made available using networked access to one or more large data centers with shared computing and storage resources – in effect, a distributed form of the 1960s “computing utility” [12] vision. The economic advantages of sharing resources are clear, and additional benefits accrue from the computational and storage resources available. Decision making, for instance, can be improved with access to archives of user, historical, and logistical data. Global coordination and forecasting or planning are often much more effective than distributed coordination. Today, cloud computing services are increasingly the coordination point among always-on mobile devices, such as tablets and smartphones.
互联网的普及已经引发了一种新的计算形式 - 云计算[4]，在这种形式中，通过对具有共享计算和存储资源的一个或多个大型数据中心的联网访问，提供服务 - 事实上是20世纪60年代“计算效用”[12]想法的分布式形式。共享资源的经济优势非常明显，并且可用计算和存储资源能获得额外收益。例如，可以通过访问用户档案，历史数据和后勤数据来改进决策。全球协调和预测或计划往往比分布式协调更有效。如今，云计算服务正日益成为永远在线的移动设备（如平板电脑和智能手机）的协调点。
For all of these reasons, we believe that cloud computing will play a central role in the Internet of the future. The requirements of cloud-centric services have several implications for a future Internet and the connection properties it provides to end hosts, distributed sites, and data centers:
出于所有的这些原因，我们认为云计算将在未来的互联网中发挥核心作用。以云为中心的服务对未来的互联网以及提供给终端、分布式站点和数据中心的连接属性有一些影响：
1.If cloud-based storage, computation, and control/coordination are to replace the local storage and computation facilities we have today, access to the cloud must be highly dependable to avoid a loss of availability or integrity, or to avoid fluctuations in timing.
1.如果基于云计算的存储，计算和控制/协调要取代我们今天的本地存储和计算设施，则访问云必须非常可靠，以避免可用性或完整性的损失，或避免时间波动。
2. Mission-critical data and infrastructure hosted on the cloud means the network must be secure to prevent data and control from being corrupted or falling into the wrong hands.
2.关键任务数据和基础设施托管在云上，意味着网络必须是安全的，防止数据和控制被破坏或落入坏人之手。
3. The cloud is still in its infancy, and new applications continue to be invented. The network must be sufficiently flexible and extensible to provide connections meeting their needs.
3.云仍处于起步阶段，人们不断发明出新的应用程序。 网络必须具有足够的灵活性和可扩展性，以提供满足其需求的连接。
The four properties in italics are thus essential for a future Internet architecture.
因此，斜体的四个属性对于未来的互联网体系结构非常重要。
4. NEBULA overview
NEBULA概述
The NEBULA future Internet architecture project has been investigating a new Internet architecture that supports cloud computing by providing the properties discussed at the end of section 3.
NEBULA未来互联网架构项目通过提供第3节末尾讨论的属性，一直在研究支持云计算的新互联网架构。
Figure 1 shows the high-level architecture of NEBULA. NEBULA consists of three tiers: the network core (NCore) that connects data centers to each other, the NEBULA data plane (NDP)thatconnectsthedatacenterstotheaccess(edge)networks, and the NEBULA Virtual and Extensible Networking Techniques (NVENT) that offers users a dynamic and flexible spectrum of connectivity choices — including, for instance, paths with HIPAA assurances that can be used for protected health information, or high-reliability paths.
图1显示了NEBULA的高级架构。 NEBULA由三层组成：将数据中心互相连接起来的中心网络（NCore），将数据中心连接到边缘网络的NEBULA数据平面（NDP），以及可以为用户提供动态且灵活的连接选择范围的NEBULA虚拟可扩展网络技术（NVENT），-例如，包括可用于受保护的健康信息的HIPAA保证或高可靠性的路径。
注：接下来的几段基本都是在解释NCore、NDP和NVENT这三个名词。
NCore：the network core 中心网络
NDP：the NEBULA data plane NEBULA数据平面
NVENT：the NEBULA Virtual and Extensible Networking Techniques NEBULA虚拟可扩展网络技术
NEBULA Core Architecture (NCore): NCore is based on a model of high-performance core routers, as well as richer interconnection topologies for both data center attachment and NCore router interconnection. It uses ideas from distributed systems fault tolerance to achieve high reliability. Research has resulted in new, ultra-reliable router architectures, as well as interconnection architectures for data centers that can leverage such ultra-reliable routers.
NEBULA核心架构（NCore）：NCore基于高性能核心路由器的模型，以及用于数据中心连接和NCore路由器互连的更丰富的互连拓扑。 它使用分布式系统容错的思想来实现高可靠性。 研究已经产生了新的，超可靠的路由器架构，以及用于数据中心的互连架构，这些架构可以利用这种超可靠的路由器。
NEBULA Data Plane (NDP): NDP incorporates new data-plane technologies for resilient access, allowing communication only when all involved parties, such as endpoints and transit networks, have agreed to participate (this is desirable for reasons of confidentiality, integrity and availability).
NEBULA数据平面（NDP）：NDP采用新的数据平面技术提供弹性访问，只有当所有相关方（例如端点和传输网络）同意参与时才允许进行通信（由于保密性，完整性和可用性，这是可取的）。
NDP contains as its key element a path verification mechanism called ICING [18]. ICING ensures that, before packets are sent over any network path, each domain along the path has (explicitly or through delegation) consented to the use of the path. A domain’s consent is embodied in a cryptographic token called a proof of consent (PoC), which the sender embeds in each packet that she launches along the path. As the packet traverses the path, it is incrementally marked with proofs of provenance(PoPs),which essentially certify that the packet has indeed traveled through each domain on the path, in the correct order.
NDP包含一个称为ICING的路径验证机（path verification mechanism）的关键要素。 ICING确保在数据包通过任何网络路径之前，路径上的每个域都已（明确或通过委托）同意使用该路径。 域名的同意体现在称为同意证明（PoC）的加密令牌中，发件人将其嵌入到她沿路径启动的每个数据包中。 当数据包通过路径时，它会逐步地用出处证明来标记（it is incrementally marked with proofs of provenance(PoPs) ？？？不理解），实质上证明数据包确实按照正确的顺序遍历了路径上的每个域。
The requirement for explicit consent is a major difference from the current Internet architecture, and substantially improves security: for instance, since all traffic must be explicitly authorized and strong cryptographic mechanisms thwart spoofing, denial-ofservice attacks are much harder to carry out. ICING also enables NEBULA to enforce a much richer set of policies—e.g., a domain can refuse to carry traffic that has not yet traversed a fire wall that is located in another domain.
明确的应答（explicit consent）的要求与当前的互联网体系结构有很大的不同，并且大大提高了安全性：例如，由于所有的流量都必须得到明确的授权，并且强大的加密机制会阻止访问，否则拒绝服务攻击就难以实施。 ICING还使NEBULA能够执行更丰富的一组策略-例如，一个域可以拒绝承载尚未遍历位于另一个域中的防火墙的流量。
NEBULA extensible control plane(NVENT):NVENT embodies new control-plane technologies that focus on policy specification, policy-based path setup [6] and service naming [20].
NEBULA可扩展控制平面（INVENT）：INVENT体现了集中于策略特性（policy specification），基于策略的路径设置和服务命名的新控制平面技术。
NVENT uses declarative networking, based on Network Datalog. This declarative approach lets administrators provide high-level specifications of their routing policies, without having to worry about implementation details (and getting them right). The resulting specifications tend to be very concise: complex policies can often be specified with just a handful of rules. This makes it easier for administrators to update and evolve their policies over time. Just as BGP in the current Internet, NVENT providesasetof default paths to ensure global reachability, but it also provides an interface to NDP, which is available to users for requesting custom paths, e.g., for applications that require high reliability. These custom paths are negotiated and set up on demand.
NVENT使用基于网络数据记录的声明性网络。 这种声明性的方法可以让管理员提供他们路由策略的高级特性，而不必担心实现细节（并且正确地获得它们）。 由此产生的说明往往非常简洁：复杂的策略往往可以通过一些规则来指定。这使得管理员可以更轻松地随着时间的推移更新和发展他们的策略。 与当前互联网中的BGP一样，NVENT提供了一组默认路径以确保全局可达性，但它也提供了一个NDP接口，NDP可供用户请求自定义路径，例如用于需要高可靠性的应用程序。这些自定义路径是根据需要进行协商和设置的。
5. PUTTING NEBULA TOGETHER
将NEBULA放在一起
Figure 2 illustrates how the three tiers work together to negotiate a custom end-to-end path (e.g., for sensitive health data) from a cell phone to a data center. The cell phone contacts NVENT（NEBULA虚拟和可扩展网络技术，前文有讲述）and requests a path to NCore. NVENT looks for a suitable path that complies with the policies of each network, and it contacts the NDP policy server in each network to obtain the necessary proofs of consent (PoCs), which it then returns to the phone. The phone can use the PoCs to send packets via NDP to the nearest NCore router, which inspects the proofs of provenance (PoPs) to check that the negotiated path has been followed, and then uses its NCore links to forward the packets to the correct data center.
图2展示了三层如何协同工作来协商从手机到数据中心的定制的端到端路径。（例如，用于敏感健康数据）。 手机联系NDP并请求通往核心网的路径。 NVENT寻找符合每个网络策略的合适路径，并联系每个网络中的NDP策略服务器以获得必要的同意证明（PoC），然后将其返回给手机。 手机可以通过NDP使用PoC将数据包发送到最近的核心网路由器，后者检查源出证明（PoP）以检查协商路径是否已被遵循，然后使用其核心网链路将数据包转发到正确的数据中心。
A policy server will have zero or more policies. The default policy is to drop traffic, sometimes called “deny by default”. Policies are assumed to be dynamic (changeable) but we assume they are changed infrequently, and thus are cacheable. In our initial architecture, we expect that users and prototype applications will want easy to state policies, e.g., a policy indicating HIPAA compliance would be stated as “HIPAA=yes”. A policy server’s policies can be queried by clients or consent servers. A path is constructed from consenting servers.
策略服务器将有零或多个策略。 默认策略是丢弃流量，有时称为“默认拒绝”。 假定策略是动态的（可变的），但我们假设它们很少发生变化，因此可以缓存。 在我们最初的体系结构中，我们预计用户和原型应用程序会希望容易陈述政策，例如，指示HIPAA合规的政策将被声明为“HIPAA = yes”。策略服务器的策略可以由客户端或同意服务器查询。 路径是由同意的服务器构建的。
A user or application specifies policy requirements, e.g., NEBULAPATH=HIPAA. The application specifies a destination or service. When this specification is received, the system checks a cache for a cached compliant path to the destination or service. If such a path is available, NEBULA tries to get consent to use the path, perhaps with cached proofs of consent if obtaining consent is expensive. If nothing is cached, or there is no consent for a cached path, the system iterates requests for consent to consent servers. The end result is that NEBULA will either establish and cache a path, or will fail with an error.
用户或应用程序指定策略要求，例如NEBULAPATH = HIPAA。 该应用程序指定目标或服务。 当收到此指定时，系统会检查缓存以找到目标或服务的缓存兼容路径。如果有这样的路径可用，NEBULA会试图得到使用该路径的同意，如果获得同意是昂贵的，可能使用缓存的同意证明。 如果没有任何内容被缓存，或者没有对缓存路径的同意，系统会重复请求同意服务器。最终的结果是，NEBULA将建立并缓存一条路径，否则将失败并出现错误。
Packets carry secure “markings” of consent. This might be the cryptographic seal implied by Onion Routing in TorIP. These “marks” are updated at “realm” (e.g., ISP) boundaries. There are checks to see whether a packet is “permitted”.
数据包带有安全的“同意标记”。 这可能是TorIP中Onion Routing隐含的加密密封。 这些“标记”在“领域”（例如，ISP）边界被更新。将会有检查查看一个数据包是否“被允许”。
6.1 Overview
概述（怎么又是概述……）
Figure 4 illustrates the internal structure of a network node in our prototype design. Not unlike a router in the current Internet, the node has a “data plane” and a “control plane”: the former consists of the NDP path verification mechanism,which is based on ICING, while the latter consists of NVENT’s routing and policy mechanism and is based on the RapidNet [22] declarative networking engine.
图4说明了我们的原型设计中网络节点的内部结构。 与当前Internet中的路由器不同（Not unlike），该节点具有“数据平面”和“控制平面”：前者由基于ICING的NDP路径验证机制组成，后者由NVENT的路由和策略机制组成，且是基于RapidNet（一个论文中的名词，不知道怎么翻译）的声明性网络引擎。
Each administrative domain can install its own policies to describe what kinds of paths it permits in its network. The policies are written in Network Datalog (NDlog), a declarative language;this enables administrators to state policies very concisely, injusta few lines of code, and it facilitates the process of writing and updating the policies. In addition, our prototype design contains the notion of a path broker; this is a special kind of node that collects information about policies and locally available paths. Figure 5 illustrates how these components are interconnected.
每个管理域可以安装自己的策略来描述它在网络中允许的路径。 这些策略以网络数据记录（NDlog）这种声明性语言编写;这使得管理员可以通过几行代码简洁地陈述策略，并且有助于编写和更新策略。 另外，我们的原型设计包含路径代理的概念; 这是一种特殊的节点，它可以收集有关策略和本地可用路径的信息。 图5说明了这些组件如何互连。
During normal operation, the path brokers generate a set of default best-effort paths that provide basic connectivity, just as in the current Internet. However, networks and end users with the appropriate credentials can submit queries for paths with specific properties. Forinstance,ahospitalthatisabouttoperformtelesurgeryon a remote patient might request three redundant paths between the hospital and the patient’s location that each have sufficient bandwidth and traverse only domains that advertise compliance with HIPAA (and are perhaps certified by an appropriate industry consortium, similar in spirit to ‘privacy seal’ programs like TRUSTe’s or BBBOnLine’s). The path broker may have to contact other path brokers to process this query – e.g., to find paths that do not share any interior nodes. Once a set of suitable paths is found, the path broker contacts the domains along the path and requests the appropriate NDP credentials – cryptographic proofs of consent (PoC) – which are then returned to the user that made the request.
在正常运行期间，路径代理会生成一组默认的最大效果（best-effort）路径，以提供基本连接，就像当前的互联网一样。但是，具有适当证书的网络和终端用户可以提交具有特定属性的路径查询。例如，对于远程病人进行手术治疗的医院，可能要求医院和患者位置之间有三条冗余路径，每条路径都有足够的带宽，并且只通过宣传符合HIPAA（注：HIPAA全称为：Health Insurance Portability and Accountability Act/1996，Public Law 104-19，尚没有确切的正式中文名称，国内文献一般直接称为HIPAA法案，有的称为健康保险携带和责任法案，也有取其意为医疗电子交换法案；台湾有文献翻译为义务型可携带式健康保险法案。）标准的领域（也许可以由适当的行业联盟进行认证，类似于'隐私印章'程序像TRUSTe's或BBBOnLine's）。路径代理可能不得不联系其他路径代理来处理此查询 - 例如，查找不共享任何内部节点的路径。找到一组合适的路径后，路径代理程序会联系路径上的域并请求相应的NDP凭证 - 加密证明同意书（PoC） - 然后将其返回给提出请求的用户。
6.2 Query processing
6.2查询处理
Figure 5 illustrates the PoC creation process in some more detail.
图5更详细地说明了PoC创建过程。
The process begins when the sender (shown on the left) attempts to transmit a packet to a destination for which the user has formulated a special policy. NDP detects that no PoC is available for that destination yet, and therefore contacts NVENT (1), which issues a query to the path broker (2). Once the path broker has identified a candidate path (the three green nodes), it contacts the NVENT instances along the path (3), which check compliance with their local policies and then ask the local ICING policy server to issue a PoC for the local segment of the path (4). These individual PoCs are then returned to the path broker, which assembles them into an end-to-end PoC and returns it to the NDP instance on the sender (5).
当发送方（显示在左侧）尝试将数据包发送到用户为其制定特殊策略的目的地时，该过程开始。 NDP检测到没有PoC可用于该目的地，因此与NVENT（1）联系，NVENT（1）向路径代理（2）发出查询。 一旦路径代理已经确定了一个候选路径（三个绿色节点），它会沿着路径（3）联系NVENT实例，该路径检查是否符合其本地策略，然后要求本地ICING策略服务器为本地发出PoC 路径段（4）。 然后将这些单独的PoC返回给路径代理，路径代理将它们组装成端到端的PoC并将其返回给发送方（5）上的NDP实例。
From that point on, the sender can generate cryptographic tokens for the packets it wants to send along the path. In our prototype, end nodes can “stripe” their traffic across multiple paths for redundancy; an alternative approach would be to detect path failures and to fail over to an alternative path. In either case, the failure of a single path, or even a small number of paths, does not interrupt the user’s connection.
从这一点开始，发送者可以为它想沿路径发送的数据包生成密码令牌。 在我们的原型中，终端节点可以通过多条路径“分散”他们的流量以减少冗余; 另一种方法是检测路径故障并将故障切换到备用路径。在任何一种情况下，单个路径或甚至少量路径的失败都不会中断用户的连接。
6.3 Network state
网络状态
To illustrate how policies are implemented in practice, we show some of the relations that our prototype maintains in Figure 6. The link table stores the topology of the network, as well as the attributes of the available links. (Like all the other tables, this table is not stored anywhere in its entirety; each node stores the entries that pertain to its local links.) In our prototype, an entry in the link table is of the form (A,B, c, d, h), where A and B are NEBULA nodes, c is the capacity of the link, d is the propagation delay, and h indicates HIPAA compliance; other properties would not be difficult to add. datalink is a similar table that describes the connections to each node’s path broker(s). routerIP is an artifact of our prototype, which is implemented as an overlay over an existing IP network; it maps our internal node identifiers to IP addresses. pendingPing is used by a simple link failure detection mechanism.
为了说明在实践中如何实施策略，图6展示了我们的原型中维护的一些关系。链接表存储了网络的拓扑结构以及可用链接的属性。 （和所有其他表一样，这个表并不存储在任何地方;每个节点存储与其本地链接有关的条目）。在我们的原型中，链接表中的一个条目的形式是（A，B，c ，d，h），其中A和B是NEBULA节点，c是链路容量，d是传播延迟，h表示HIPAA符合性; 其他属性不会难以添加。数据链路是一个类似的表，它描述了到每个节点路径代理的连接。routerIP是我们原型的一个产物，它是作为现有IP网络上的覆盖层实现的; 它将我们的内部节点标识符映射到IP地址。pendingPing作为简单的链路故障检测机制使用。
pathRequest, minPathRequest, and hipaaPath-Request store three types of path queries that can be issued in our prototype. Adding more query types would not be difficult, thanks to NDlog’s flexibility; each request type should require only a few more lines of NDlog code.
pathRequest，minPathRequest和hipaaPath-Request存储可以在我们的原型中发布的三种类型的路径查询。由于NDlog的灵活性，添加更多查询类型并不困难; 每种请求类型只需要添加几行NDlog代码。
localPOC is used to store the proofs of consent (PoCs) that the node has generated locally; replyPOC stores PoCs that have been received from the path broker; and replyPOCCount keeps track of the number of PoCs that have been received for a particular query. We note that paths could fail or be withdrawn because a network along the path no longer consents to their use; this could be handled by submitting the path request as a continuous query, which would enable the path broker to automatically replace failed paths once the number of working paths becomes too low.
localPOC用于存储节点本地生成的同意证明（PoC）; replyPOC存储从路径代理收到的PoC; 并且replyPOCCount跟踪已收到特定查询的PoC数量。 我们注意到路径可能会失败或被撤销，因为路径上的网络不再同意它们的使用; 这可以通过将路径请求作为连续查询提交来处理，这将使路径代理在工作路径数量变得过低时自动替换失败的路径。
6.4 Interdomainpaths
域间路径
Figure 7 illustrates how the path broker discovers suitable interdomain paths in a setting with multiple path brokers. The process works by chaining together suitable peering links, taking bandwidth constraints and HIPAA requirements into account. Notably, even this complex process can be described withjust a few lines of declarative code.
图7说明路径代理如何在具有多个路径代理的设置中发现适当的域间路径。 该过程通过将适当的对等链路链接在一起工作，将带宽限制和HIPAA要求考虑在内。 值得注意的是，即使这个复杂的过程可以用几行声明性代码来描述。
6.5 Status
说明
Our implementation is based on a software-only implementation of ICING [14] and the RapidNet declarative networking engine [22]. A clip of a demo is available at the project web site [19], showing a video being streamed over three redundant NEBULA connections; when faults are injected into some of the paths, the video is unaffected and continues to play.
我们的实现基于ICING [14]和RapidNet声明性网络引擎的软件实现。 项目网站提供了一个演示视频，展示了一个视频通过三个冗余NEBULA连接进行流式传输; 当故障被注入某些路径时，视频不受影响并继续播放。
7. DISCUSSION
讨论
As might be expected of a complex project with a large team of researchers, significant management effort was required to bring the architecture to fruition. One surprising problem that created difficulty for us was a lack of clarity on exactly what an “architecture” was. For example, is an architecture defined by the design goals? The components and the interaction of components? An abstract description of a vision and its realization? Or something else entirely? In the end, we tried to loosely follow the model of Clark[9].
正如对一个有大量研究人员的复杂项目所期望的那样，架构的实现需要付出巨大的管理努力。 一个让我们感到困难的令人惊讶的问题是对“架构”究竟是什么缺乏清晰的理解。 例如，一个架构是由设计目标定义的，还是由组件和组件的交互方式定义的？是对愿景及其实现的抽象描述，还是其他什么东西？最后，我们试图松散地（loosely）遵循Clark的模型。
As a management mechanism, and because the members of our team brought significant research and implementation experience to the table, we decided to loosely organize our research around the NVENT, NCORE and NDP designs in the first year of NEBULA, and then gradually integrate. For example, a subgroup interested in router reliability [1, 11] focused their energies on bringing faulttolerance strategies from distributed systems research to the context of core routers that comprise hundreds of line cards and processors. Thus, even if the more radical proposals for policy enforcement did not transition immediately, we were hopeful that our results could influence the router vendor community.
作为一个管理机制，并且由于我们团队的成员为我们带来了重要的研究和实施经验，所以我们决定在NEBULA的第一年松散地（loosely 怎么翻译都感觉怪怪的……）组织有关NVENT，NCORE和NDP设计的研究，然后逐步整合。 例如，一个对路由器可靠性感兴趣的小组专注于将分布式系统研究的容错策略引入包含数百个线卡和处理器的核心路由器的环境中。 因此，即使更激进的政策执行提案没有立即过渡（transition 或者翻译成执行？），我们仍然希望我们的结果能够影响路由器供应商。
As designs for the elements began to emerge, we realized that postponing the integration of the architecture was a significant strategic error. In retrospect the deepest questions were not in the component research, interesting as it was. Rather, they were in the integration of the components into an architecture that achieved the NEBULA agenda of resilience for new applications — those that would not use an Internet without novel features such as NDP’s policy enforcement. One example is the challenge of specifying and enforcing interrealm/interdomain policies. Other examples include policies for path discovery in a federation (today addressed with BGP), and the API used for application specification of policies.
随着元素的设计开始出现，我们意识到推迟整合架构是一个重大的战略错误。 回想起来，最深刻的问题不在组件研究中，因为它是有趣的。相反，他们将这些组件整合到一个架构中，实现了NEBULA新应用程序的弹性议程 - 那些不使用互联网而没有诸如NDP政策执行等新颖功能的互联网。 其中一个例子就是指定和执行interrealm / interdomain策略的挑战。其他示例包括联合中路径发现的策略（现在用BGP解决）以及用于策略应用规范的API。
There are perhaps too many of these questions for realizing a complete integrated NEBULA architecture before the project ends. Nonetheless, we have done some experimental work with our Zodiac prototype that indicates that the components can be composed into a functioning system. This piecewise integration reinforces our belief that a NEBULA realization is feasible, albeit one requiring additional thought and engineering to fully instantiate.
在项目结束之前实现完整的NEBULA体系结构可能有太多这样的问题。尽管如此，我们已经用我们的Zodiac原型做了一些实验性工作，表明这些组件可以组成一个功能正常的系统。 这种分段集成加强了我们的信念，即NEBULA的实现是可行的，尽管需要额外的思考和工程来充分实例化。
8. CONCLUSIONANDNEXTSTEPS
结论和内容
NEBULA is a novel future Internet architecture that addresses networking challenges for cloud computing. Table 1 summarizes the architectural choices made in NEBULA, following Clark’s[9]similar summary.
NEBULA是一种新颖的未来互联网架构，可解决云计算的网络挑战。 表1总结了在NEBULA中做出的架构选择，遵循Clark的类似的总结。
（注：所谓Clack的类似的总结是大卫D.克拉克提出的DARPA互联网协议的设计理念。）
NEBULA is focused on resilience, and incorporates routers hardened with distributed systems technology, an extensible control plane and a flexible approach to policy enforcement. These latter two elements have been combined in the Zodiac prototype discussed in Section 6.
NEBULA专注于应变能力，并融合了利用分布式系统技术强化的路由器，可扩展的控制平面和灵活的策略执行方法。 后面两个元素已经在第6节讨论的Zodiac原型中结合了。
We continue to work towards integrating more of the research generated in the NEBULA project into operational software. For example, a prototyping effort to integrate Serval and ICING has recently been completed.
我们继续致力于将NEBULA项目中产生的更多研究纳入运营软件。 例如，最近完成了将Serval和ICING整合在一起的原型设计工作。
9. ACKNOWLEDGMENTS
致谢
The NEBULA project was supported by the U.S. National Science Foundation. We also appreciate the support of Cisco Systems.
NEBULA项目得到美国国家科学基金会的支持。 我们也非常感谢Cisco系统的支持。