Internet Research Task Force (IRTF) F. Templin, Ed.
Request for Comments: 6179 Boeing Research & Technology
Category: Experimental March 2011
ISSN: 2070-1721
Internet Research Task Force (IRTF) F. Templin, Ed.
Request for Comments: 6179 Boeing Research & Technology
Category: Experimental March 2011
ISSN: 2070-1721
The Internet Routing Overlay Network (IRON)
Internet路由覆盖网络（IRON）
Abstract
摘要
Since the Internet must continue to support escalating growth due to increasing demand, it is clear that current routing architectures and operational practices must be updated. This document proposes an Internet Routing Overlay Network (IRON) that supports sustainable growth while requiring no changes to end systems and no changes to the existing routing system. IRON further addresses other important issues including routing scaling, mobility management, multihoming, traffic engineering and NAT traversal. While business considerations are an important determining factor for widespread adoption, they are out of scope for this document. This document is a product of the IRTF Routing Research Group.
由于需求不断增长，互联网必须继续支持不断升级的增长，因此很明显，必须更新当前的路由架构和操作实践。本文件提出了一种互联网路由覆盖网络（IRON），该网络支持可持续发展，同时不需要改变终端系统和现有路由系统。IRON进一步解决了其他重要问题，包括路由扩展、移动性管理、多宿、流量工程和NAT穿越。虽然业务考虑因素是广泛采用的一个重要决定因素，但它们超出了本文档的范围。本文件是IRTF路由研究组的产品。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the individual opinion(s) of one or more members of the Internet Research Task Force (IRTF) Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。本RFC代表互联网研究工作队（IRTF）研究小组的一名或多名成员的个人意见。IRSG批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6179.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6179.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................4
2. Terminology .....................................................5
3. The Internet Routing Overlay Network ............................7
3.1. IRON Client ................................................9
3.2. IRON Serving Router .......................................10
3.3. IRON Relay Router .........................................10
4. IRON Organizational Principles .................................11
5. IRON Initialization ............................................13
5.1. IRON Relay Router Initialization ..........................13
5.2. IRON Serving Router Initialization ........................14
5.3. IRON Client Initialization ................................15
6. IRON Operation .................................................15
6.1. IRON Client Operation .....................................16
6.2. IRON Serving Router Operation .............................17
6.3. IRON Relay Router Operation ...............................18
6.4. IRON Reference Operating Scenarios ........................18
6.4.1. Both Hosts within IRON EUNs ........................19
6.4.2. Mixed IRON and Non-IRON Hosts ......................21
6.5. Mobility, Multihoming, and Traffic Engineering
Considerations ............................................24
6.5.1. Mobility Management ................................24
6.5.2. Multihoming ........................................25
6.5.3. Inbound Traffic Engineering ........................25
6.5.4. Outbound Traffic Engineering .......................25
6.6. Renumbering Considerations ................................25
6.7. NAT Traversal Considerations ..............................26
6.8. Multicast Considerations ..................................26
6.9. Nested EUN Considerations .................................26
6.9.1. Host A Sends Packets to Host Z .....................28
6.9.2. Host Z Sends Packets to Host A .....................28
7. Implications for the Internet ..................................29
8. Additional Considerations ......................................30
9. Related Initiatives ............................................30
10. Security Considerations .......................................31
11. Acknowledgements ..............................................31
12. References ....................................................32
12.1. Normative References .....................................32
12.2. Informative References ...................................32
Appendix A. IRON VPs over Internetworks with Different
Address Families ......................................35
Appendix B. Scaling Considerations ................................36
1. Introduction ....................................................4
2. Terminology .....................................................5
3. The Internet Routing Overlay Network ............................7
3.1. IRON Client ................................................9
3.2. IRON Serving Router .......................................10
3.3. IRON Relay Router .........................................10
4. IRON Organizational Principles .................................11
5. IRON Initialization ............................................13
5.1. IRON Relay Router Initialization ..........................13
5.2. IRON Serving Router Initialization ........................14
5.3. IRON Client Initialization ................................15
6. IRON Operation .................................................15
6.1. IRON Client Operation .....................................16
6.2. IRON Serving Router Operation .............................17
6.3. IRON Relay Router Operation ...............................18
6.4. IRON Reference Operating Scenarios ........................18
6.4.1. Both Hosts within IRON EUNs ........................19
6.4.2. Mixed IRON and Non-IRON Hosts ......................21
6.5. Mobility, Multihoming, and Traffic Engineering
Considerations ............................................24
6.5.1. Mobility Management ................................24
6.5.2. Multihoming ........................................25
6.5.3. Inbound Traffic Engineering ........................25
6.5.4. Outbound Traffic Engineering .......................25
6.6. Renumbering Considerations ................................25
6.7. NAT Traversal Considerations ..............................26
6.8. Multicast Considerations ..................................26
6.9. Nested EUN Considerations .................................26
6.9.1. Host A Sends Packets to Host Z .....................28
6.9.2. Host Z Sends Packets to Host A .....................28
7. Implications for the Internet ..................................29
8. Additional Considerations ......................................30
9. Related Initiatives ............................................30
10. Security Considerations .......................................31
11. Acknowledgements ..............................................31
12. References ....................................................32
12.1. Normative References .....................................32
12.2. Informative References ...................................32
Appendix A. IRON VPs over Internetworks with Different
Address Families ......................................35
Appendix B. Scaling Considerations ................................36
Growth in the number of entries instantiated in the Internet routing system has led to concerns regarding unsustainable routing scaling [RADIR]. Operational practices such as the increased use of multihoming with Provider-Independent (PI) addressing are resulting in more and more fine-grained prefixes being injected into the routing system from more and more end user networks. Furthermore, depletion of the public IPv4 address space has raised concerns for both increased address space fragmentation (leading to yet further routing table entries) and an impending address space run-out scenario. At the same time, the IPv6 routing system is beginning to see growth [BGPMON] which must be managed in order to avoid the same routing scaling issues the IPv4 Internet now faces. Since the Internet must continue to scale to accommodate increasing demand, it is clear that new routing methodologies and operational practices are needed.
Internet路由系统中实例化的条目数量的增长导致了对不可持续路由扩展[RADIR]的担忧。操作实践，例如越来越多地使用具有提供商独立（PI）寻址的多宿主，导致越来越多的细粒度前缀从越来越多的最终用户网络注入路由系统。此外，公共IPv4地址空间的耗尽引起了对地址空间碎片增加（导致更多路由表条目）和即将出现的地址空间耗尽场景的担忧。与此同时，IPv6路由系统开始出现增长[BGPMON]，必须对其进行管理，以避免IPv4 Internet现在面临的相同路由扩展问题。由于互联网必须继续扩展以适应不断增长的需求，显然需要新的路由方法和操作实践。
Several related works have investigated routing scaling issues. Virtual Aggregation (VA) [GROW-VA] and Aggregation in Increasing Scopes (AIS) [EVOLUTION] are global routing proposals that introduce routing overlays with Virtual Prefixes (VPs) to reduce the number of entries required in each router's Forwarding Information Base (FIB) and Routing Information Base (RIB). Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) [RFC5720] examines recursive arrangements of enterprise networks that can apply to a very broad set of use-case scenarios [RFC6139]. IRON specifically adopts the RANGER Non-Broadcast, Multiple Access (NBMA) tunnel virtual-interface model, and uses Virtual Enterprise Traversal (VET) [INTAREA-VET] and the Subnetwork Adaptation and Encapsulation Layer (SEAL) [INTAREA-SEAL] as its functional building blocks.
一些相关的工作已经研究了路由缩放问题。虚拟聚合（VA）[GROW-VA]和递增范围聚合（AIS）[EVOLUTION]是全局路由方案，引入带有虚拟前缀（VP）的路由覆盖，以减少每个路由器的转发信息库（FIB）和路由信息库（RIB）中所需的条目数。具有全局企业递归（RANGER）的网络中的路由和寻址[RFC5720]检查企业网络的递归安排，这些安排可以应用于非常广泛的用例场景集[RFC6139]。IRON特别采用RANGER非广播多址（NBMA）隧道虚拟接口模型，并使用虚拟企业穿越（VET）[INTAREA-VET]和子网适配和封装层（SEAL）[INTAREA-SEAL]作为其功能构建块。
This document proposes an Internet Routing Overlay Network (IRON) with goals of supporting sustainable growth while requiring no changes to the existing routing system. IRON borrows concepts from VA and AIS, and further borrows concepts from the Internet Vastly Improved Plumbing (Ivip) [IVIP-ARCH] architecture proposal along with its associated Translating Tunnel Router (TTR) mobility extensions [TTRMOB]. Indeed, the TTR model to a great degree inspired the IRON mobility architecture design discussed in this document. The Network Address Translator (NAT) traversal techniques adapted for IRON were inspired by the Simple Address Mapping for Premises Legacy Equipment (SAMPLE) proposal [SAMPLE].
本文件提出了一种互联网路由覆盖网络（IRON），其目标是支持可持续增长，同时不需要改变现有的路由系统。IRON借鉴了VA和AIS的概念，并进一步借鉴了互联网大幅改善管道（Ivip）[Ivip-ARCH]架构提案及其相关的翻译隧道路由器（TTR）移动性扩展[TTRMOB]的概念。事实上，TTR模型在很大程度上启发了本文档中讨论的铁移动架构设计。适用于IRON的网络地址转换器（NAT）遍历技术的灵感来自于房屋遗留设备的简单地址映射（示例）提案[示例]。
IRON supports scalable addressing without changing the current BGP [RFC4271] routing system. IRON observes the Internet Protocol standards [RFC0791][RFC2460]. Other network-layer protocols that can be encapsulated within IP packets (e.g., OSI/CLNP (Connectionless Network Protocol) [RFC1070], etc.) are also within scope.
IRON支持可扩展寻址，无需更改当前BGP[RFC4271]路由系统。IRON遵守互联网协议标准[RFC0791][RFC2460]。可封装在IP包内的其他网络层协议（例如OSI/CLNP（无连接网络协议）[RFC1070]等）也在范围内。
The IRON is a global routing system comprising virtual overlay networks managed by Virtual Prefix Companies (VPCs) that own and manage Virtual Prefixes (VPs) from which End User Network (EUN) prefixes (EPs) are delegated to customer sites. The IRON is motivated by a growing customer demand for multihoming, mobility management, and traffic engineering while using stable addressing to minimize dependence on network renumbering [RFC4192][RFC5887]. The IRON uses the existing IPv4 and IPv6 global Internet routing systems as virtual NBMA links for tunneling inner network protocol packets within outer IPv4 or IPv6 headers (see Section 3). The IRON requires deployment of a small number of new BGP core routers and supporting servers, as well as IRON-aware routers/servers in customer EUNs. No modifications to hosts, and no modifications to most routers, are required.
IRON是一个全球路由系统，由拥有和管理虚拟前缀（VP）的虚拟前缀公司（VP）管理的虚拟覆盖网络组成，最终用户网络（EUN）前缀（EP）从虚拟覆盖网络委托给客户站点。IRON的动机是客户对多归属、移动性管理和流量工程的需求不断增长，同时使用稳定的寻址来最大限度地减少对网络重新编号的依赖[RFC4192][RFC5887]。IRON将现有的IPv4和IPv6全局Internet路由系统用作虚拟NBMA链路，用于在外部IPv4或IPv6报头内对内部网络协议数据包进行隧道传输（请参见第3节）。IRON需要在客户EUN中部署少量新的BGP核心路由器和支持服务器，以及IRON感知路由器/服务器。不需要修改主机，也不需要修改大多数路由器。
Note: This document is offered in compliance with Internet Research Task Force (IRTF) document stream procedures [RFC5743]; it is not an IETF product and is not a standard. The views in this document were considered controversial by the IRTF Routing Research Group (RRG), but the RG reached a consensus that the document should still be published. The document will undergo a period of review within the RRG and through selected expert reviewers prior to publication. The following sections discuss details of the IRON architecture.
注：本文件符合互联网研究工作队（IRTF）文件流程序[RFC5743]；它不是IETF产品，也不是标准。IRTF路由研究小组（RRG）认为本文件中的观点存在争议，但RG达成共识，认为该文件仍应出版。该文件将在RRG内进行一段时间的审查，并在出版前通过选定的专家审查员进行审查。以下各节讨论了IRON架构的细节。
This document makes use of the following terms:
本文件使用了以下术语：
End User Network (EUN): an edge network that connects an organization's devices (e.g., computers, routers, printers, etc.) to the Internet.
终端用户网络（EUN）：将组织的设备（如计算机、路由器、打印机等）连接到Internet的边缘网络。
End User Network Prefix (EP): a more specific inner network-layer prefix derived from a Virtual Prefix (VP) (e.g., an IPv4 /28, an IPv6 /56, etc.) and delegated to an EUN by a Virtual Prefix Company (VPC).
最终用户网络前缀（EP）：从虚拟前缀（VP）（例如IPv4/28、IPv6/56等）派生并由虚拟前缀公司（VPC）委托给EUN的更具体的内网层前缀。
End User Network Prefix Address (EPA): a network-layer address belonging to an EP and assigned to the interface of an end system in an EUN.
终端用户网络前缀地址（EPA）：属于EP并分配给EUN中终端系统接口的网络层地址。
Forwarding Information Base (FIB): a data structure containing network prefixes to next-hop mappings; usually maintained in a router's fast-path processing lookup tables.
转发信息库（FIB）：包含网络前缀到下一跳映射的数据结构；通常维护在路由器的快速路径处理查找表中。
Internet Routing Overlay Network (IRON): a composite virtual overlay network that comprises the union of all VPC overlay networks configured over a common Internetwork. The IRON supports routing through encapsulation of inner packets with EPA addresses within outer headers that use locator addresses.
Internet路由覆盖网络（IRON）：一种复合虚拟覆盖网络，由在公共互联网上配置的所有VPC覆盖网络组成。IRON支持通过将内部数据包封装在使用定位器地址的外部报头中的EPA地址来进行路由。
IRON Client Router/Host ("Client"): a customer's router or host that logically connects the customer's EUNs and their associated EPs to the IRON via an NBMA tunnel virtual interface.
IRON客户端路由器/主机（“客户端”）：客户的路由器或主机，通过NBMA隧道虚拟接口将客户的EUN及其相关EPs逻辑连接到IRON。
IRON Serving Router ("Server"): a VPC's overlay network router that provides forwarding and mapping services for the EPs owned by customer Clients.
铁服务路由器（“服务器”）：VPC的覆盖网络路由器，为客户拥有的EPs提供转发和映射服务。
IRON Relay Router ("Relay"): a VPC's overlay network router that acts as a relay between the IRON and the native Internet.
IRON中继路由器（“中继”）：VPC的覆盖网络路由器，充当IRON和本机互联网之间的中继。
IRON Agent (IA): generically refers to any of an IRON Client/Server/Relay.
IRON代理（IA）：泛指任何IRON客户端/服务器/中继。
Internet Service Provider (ISP): a service provider that connects customer EUNs to the underlying Internetwork. In other words, an ISP is responsible for providing basic Internet connectivity for customer EUNs.
互联网服务提供商（ISP）：将客户EUN连接到基础互联网的服务提供商。换句话说，ISP负责为客户EUN提供基本的互联网连接。
Locator an IP address assigned to the interface of a router or end system within a public or private network. Locators taken from public IP prefixes are routable on a global basis, while locators taken from private IP prefixes are made public via Network Address Translation (NAT).
定位器分配给公用或专用网络内路由器或终端系统接口的IP地址。取自公共IP前缀的定位器可在全局基础上路由，而取自私有IP前缀的定位器通过网络地址转换（NAT）公开。
Routing and Addressing in Networks with Global Enterprise Recursion (RANGER): an architectural examination of virtual overlay networks applied to enterprise network scenarios, with implications for a wider variety of use cases.
具有全局企业递归（RANGER）的网络中的路由和寻址：应用于企业网络场景的虚拟覆盖网络的体系结构检查，适用于更广泛的用例。
Subnetwork Encapsulation and Adaptation Layer (SEAL): an encapsulation sublayer that provides extended packet identification and a Control Message Protocol to ensure deterministic network-layer feedback.
子网封装和适配层（SEAL）：封装子层，提供扩展数据包标识和控制消息协议，以确保确定性网络层反馈。
Virtual Enterprise Traversal (VET): a method for discovering border routers and forming dynamic tunnel-neighbor relationships over enterprise networks (or sites) with varying properties.
虚拟企业遍历（VET）：一种在具有不同属性的企业网络（或站点）上发现边界路由器并形成动态隧道邻居关系的方法。
Virtual Prefix (VP): a prefix block (e.g., an IPv4 /16, an IPv6 /20, an OSI Network Service Access Protocol (NSAP) prefix, etc.) that is owned and managed by a Virtual Prefix Company (VPC).
虚拟前缀（VP）：由虚拟前缀公司（VPC）拥有和管理的前缀块（例如，IPv4/16、IPv6/20、OSI网络服务访问协议（NSAP）前缀等）。
Virtual Prefix Company (VPC): a company that owns and manages a set of VPs from which it delegates EPs to EUNs.
虚拟前缀公司（VPC）：一家拥有和管理一组VP的公司，该公司将EPs委托给EUNs。
VPC Overlay Network a specialized set of routers deployed by a VPC to service customer EUNs through a virtual overlay network configured over an underlying Internetwork (e.g., the global Internet).
专有网络覆盖网络专有网络部署的一组专用路由器，通过在基础互联网（如全球互联网）上配置的虚拟覆盖网络为客户EUN提供服务。
The Internet Routing Overlay Network (IRON) is a system of virtual overlay networks configured over a common Internetwork. While the principles presented in this document are discussed within the context of the public global Internet, they can also be applied to any autonomous Internetwork. The rest of this document therefore refers to the terms "Internet" and "Internetwork" interchangeably except in cases where specific distinctions must be made.
Internet路由覆盖网络（IRON）是一个虚拟覆盖网络系统，配置在公共互联网上。虽然本文中介绍的原则是在公共全球互联网的背景下讨论的，但它们也可以应用于任何自治互联网。因此，本文件其余部分交替使用“互联网”和“互联网”这两个术语，但必须进行具体区分的情况除外。
The IRON consists of IRON Agents (IAs) that automatically tunnel the packets of end-to-end communication sessions within encapsulating headers used for Internet routing. IAs use the Virtual Enterprise Traversal (VET) [INTAREA-VET] virtual NBMA link model in conjunction with the Subnetwork Encapsulation and Adaptation Layer (SEAL) [INTAREA-SEAL] to encapsulate inner network-layer packets within outer headers, as shown in Figure 1.
IRON由IRON代理（IAs）组成，它可以在用于Internet路由的封装头中自动对端到端通信会话的数据包进行隧道传输。IAs使用虚拟企业遍历（VET）[INTAREA-VET]虚拟NBMA链路模型和子网封装和适配层（SEAL）[INTAREA-SEAL]将内网层数据包封装在外部报头中，如图1所示。
+-------------------------+
| Outer headers with |
~ locator addresses ~
| (IPv4 or IPv6) |
+-------------------------+
| SEAL Header |
+-------------------------+ +-------------------------+
| Inner Packet Header | --> | Inner Packet Header |
~ with EP addresses ~ --> ~ with EP addresses ~
| (IPv4, IPv6, OSI, etc.) | --> | (IPv4, IPv6, OSI, etc.) |
+-------------------------+ +-------------------------+
| | --> | |
~ Inner Packet Body ~ --> ~ Inner Packet Body ~
| | --> | |
+-------------------------+ +-------------------------+
+-------------------------+
| Outer headers with |
~ locator addresses ~
| (IPv4 or IPv6) |
+-------------------------+
| SEAL Header |
+-------------------------+ +-------------------------+
| Inner Packet Header | --> | Inner Packet Header |
~ with EP addresses ~ --> ~ with EP addresses ~
| (IPv4, IPv6, OSI, etc.) | --> | (IPv4, IPv6, OSI, etc.) |
+-------------------------+ +-------------------------+
| | --> | |
~ Inner Packet Body ~ --> ~ Inner Packet Body ~
| | --> | |
+-------------------------+ +-------------------------+
Inner packet before Outer packet after encapsulation encapsulation
封装后的外包之前的内包封装
Figure 1: Encapsulation of Inner Packets within Outer IP Headers
图1：外部IP头中内部数据包的封装
VET specifies the automatic tunneling mechanisms used for encapsulation, while SEAL specifies the format and usage of the SEAL header as well as a set of control messages. Most notably, IAs use the SEAL Control Message Protocol (SCMP) to deterministically exchange and authenticate control messages such as route redirections, indications of Path Maximum Transmission Unit (PMTU) limitations, destination unreachables, etc. IAs appear as neighbors on an NBMA virtual link, and form bidirectional and/or unidirectional tunnel-neighbor relationships.
VET指定用于封装的自动隧道机制，而SEAL指定SEAL标头以及一组控制消息的格式和用法。最值得注意的是，IAs使用密封控制消息协议（SCMP）来确定地交换和验证控制消息，如路由重定向、路径最大传输单元（PMTU）限制指示、目标不可到达等。IAs显示为NBMA虚拟链路上的邻居，并形成双向和/或单向隧道邻居关系。
The IRON is the union of all virtual overlay networks that are configured over a common underlying Internet and are owned and managed by Virtual Prefix Companies (VPCs). Each such virtual overlay network comprises a set of IAs distributed throughout the Internet to serve highly aggregated Virtual Prefixes (VPs). VPCs delegate sub-prefixes from their VPs, which they lease to customers as End User Network Prefixes (EPs). In turn, the customers assign the EPs to their customer edge IAs, which connect their End User Networks (EUNs) to the IRON.
IRON是所有虚拟覆盖网络的联合体，这些网络通过一个公共基础Internet进行配置，并由虚拟前缀公司（VPC）拥有和管理。每一个这样的虚拟覆盖网络都包含一组分布在整个互联网上的IAs，以服务于高度聚合的虚拟前缀（VP）。VPC从其VP中委托子前缀，并将其作为最终用户网络前缀（EP）出租给客户。反过来，客户将EPs分配给其客户边缘IAs，后者将其最终用户网络（EUN）连接到熨斗。
VPCs may have no affiliation with the ISP networks from which customers obtain their basic Internet connectivity. Therefore, a customer could procure its summary network services either through a common broker or through separate entities. In that case, the VPC can open for business and begin serving its customers immediately
专有网络可能与ISP网络没有联系，客户可以从ISP网络获得基本的互联网连接。因此，客户可以通过公共代理或单独的实体获取其摘要网络服务。在这种情况下，专有网络就可以开始营业，并立即开始为其客户提供服务
without the need to coordinate its activities with ISPs or other VPCs. Further details on business considerations are out of scope for this document.
无需与ISP或其他专有网络协调其活动。有关业务注意事项的更多详细信息不在本文档范围内。
The IRON requires no changes to end systems or to most routers in the Internet. Instead, the IRON comprises IAs that are deployed either as new platforms or as modifications to existing platforms. IAs may be deployed incrementally without disturbing the existing Internet routing system and act as waypoints (or "cairns") for navigating the IRON. The functional roles for IAs are described in the following sections.
IRON不需要改变终端系统或互联网上的大多数路由器。相反，IRON由IAs组成，这些IAs要么作为新平台部署，要么作为对现有平台的修改部署。IAs可以在不干扰现有互联网路由系统的情况下进行增量部署，并作为导航铁路线的航路点（或“凯恩斯”）。IAs的职能角色在以下章节中描述。
An IRON client (or, simply, "Client") is a customer's router or host
that logically connects the customer's EUNs and their associated EPs
to the IRON via tunnels, as shown in Figure 2. Client routers obtain
EPs from VPCs and use them to number subnets and interfaces within
their EUNs. A Client can be deployed on the same physical platform
that also connects the customer's EUNs to its ISPs, but it may also
be a separate router or even a standalone server system located
within the EUN. (This model applies even if the EUN connects to the
ISP via a Network Address Translator (NAT) -- see Section 6.7).
Finally, a Client may also be a simple end system that connects a
singleton EPA and exhibits the outward appearance of a host.
.-.
,-( _)-.
+--------+ .-(_ (_ )-.
| Client |--(_ ISP )
+---+----+ `-(______)-'
| <= T \ .-.
.-. u \ ,-( _)-.
,-( _)-. n .-(_ (- )-.
.-(_ (_ )-. n (_ Internet )
(_ EUN ) e `-(______)-
`-(______)-' l ___
| s => (:::)-.
+----+---+ .-(::::::::)
| Host | .-(::::::::::::)-.
+--------+ (:::: The IRON ::::)
`-(::::::::::::)-'
`-(::::::)-'
An IRON client (or, simply, "Client") is a customer's router or host
that logically connects the customer's EUNs and their associated EPs
to the IRON via tunnels, as shown in Figure 2. Client routers obtain
EPs from VPCs and use them to number subnets and interfaces within
their EUNs. A Client can be deployed on the same physical platform
that also connects the customer's EUNs to its ISPs, but it may also
be a separate router or even a standalone server system located
within the EUN. (This model applies even if the EUN connects to the
ISP via a Network Address Translator (NAT) -- see Section 6.7).
Finally, a Client may also be a simple end system that connects a
singleton EPA and exhibits the outward appearance of a host.
.-.
,-( _)-.
+--------+ .-(_ (_ )-.
| Client |--(_ ISP )
+---+----+ `-(______)-'
| <= T \ .-.
.-. u \ ,-( _)-.
,-( _)-. n .-(_ (- )-.
.-(_ (_ )-. n (_ Internet )
(_ EUN ) e `-(______)-
`-(______)-' l ___
| s => (:::)-.
+----+---+ .-(::::::::)
| Host | .-(::::::::::::)-.
+--------+ (:::: The IRON ::::)
`-(::::::::::::)-'
`-(::::::)-'
Figure 2: IRON Client Router Connecting EUN to the IRON
图2：将EUN连接到IRON的IRON客户端路由器
An IRON serving router (or, simply, "Server") is a VPC's overlay network router that provides forwarding and mapping services for the EPs owned by customer Client routers. In typical deployments, a VPC will deploy many Servers around the IRON in a globally distributed fashion (e.g., as depicted in Figure 3) so that Clients can discover those that are nearby.
IRON服务路由器（或简称“服务器”）是VPC的覆盖网络路由器，为客户客户端路由器拥有的EPs提供转发和映射服务。在典型部署中，VPC将以全球分布的方式（如图3所示）在IRON周围部署许多服务器，以便客户端可以发现附近的服务器。
+--------+ +--------+
| Boston | | Tokyo |
| Server | | Server |
+--+-----+ ++-------+
+--------+ \ /
| Seattle| \ ___ /
| Server | \ (:::)-. +--------+
+------+-+ .-(::::::::)------+ Paris |
\.-(::::::::::::)-. | Server |
(:::: The IRON ::::) +--------+
`-(::::::::::::)-'
+--------+ / `-(::::::)-' \ +--------+
| Moscow + | \--- + Sydney |
| Server | +----+---+ | Server |
+--------+ | Cairo | +--------+
| Server |
+--------+
+--------+ +--------+
| Boston | | Tokyo |
| Server | | Server |
+--+-----+ ++-------+
+--------+ \ /
| Seattle| \ ___ /
| Server | \ (:::)-. +--------+
+------+-+ .-(::::::::)------+ Paris |
\.-(::::::::::::)-. | Server |
(:::: The IRON ::::) +--------+
`-(::::::::::::)-'
+--------+ / `-(::::::)-' \ +--------+
| Moscow + | \--- + Sydney |
| Server | +----+---+ | Server |
+--------+ | Cairo | +--------+
| Server |
+--------+
Figure 3: IRON Serving Router Global Distribution Example
图3：铁服务路由器全球分布示例
Each Server acts as a tunnel-endpoint router that forms a bidirectional tunnel-neighbor relationship with each of its Client customers. Each Server also associates with a set of Relays that can forward packets from the IRON out to the native Internet and vice versa, as discussed in the next section.
每个服务器充当一个隧道端点路由器，它与每个客户端客户形成双向隧道邻居关系。每个服务器还与一组中继相关联，这些中继可以将数据包从IRON out转发到本机Internet，反之亦然，如下一节所述。
An IRON Relay Router (or, simply, "Relay") is a VPC's overlay network router that acts as a relay between the IRON and the native Internet. Therefore, it also serves as an Autonomous System Border Router (ASBR) that is owned and managed by the VPC.
IRON中继路由器（或简称“中继”）是VPC的覆盖网络路由器，充当IRON和本机互联网之间的中继。因此，它还充当专有网络拥有和管理的自主系统边界路由器（ASBR）。
Each VPC configures one or more Relays that advertise the company's VPs into the IPv4 and IPv6 global Internet BGP routing systems. Each Relay associates with all of the VPC's overlay network Servers, e.g., via tunnels over the IRON, via a direct interconnect such as an Ethernet cable, etc. The Relay role (as well as its relationship with overlay network Servers) is depicted in Figure 4.
每个VPC配置一个或多个中继，将公司的VP播发到IPv4和IPv6全球互联网BGP路由系统中。每个中继都与VPC的所有覆盖网络服务器相关联，例如，通过铁上的隧道，通过以太网电缆等直接互连。中继角色（及其与覆盖网络服务器的关系）如图4所示。
.-.
,-( _)-.
.-(_ (_ )-.
(_ Internet )
`-(______)-' | +--------+
| |--| Server |
+----+---+ | +--------+
| Relay |----| +--------+
+--------+ |--| Server |
_|| | +--------+
(:::)-. (Ethernet)
.-(::::::::)
+--------+ .-(::::::::::::)-. +--------+
| Server |=(:::: The IRON ::::)=| Server |
+--------+ `-(::::::::::::)-' +--------+
`-(::::::)-'
|| (Tunnels)
+--------+
| Server |
+--------+
.-.
,-( _)-.
.-(_ (_ )-.
(_ Internet )
`-(______)-' | +--------+
| |--| Server |
+----+---+ | +--------+
| Relay |----| +--------+
+--------+ |--| Server |
_|| | +--------+
(:::)-. (Ethernet)
.-(::::::::)
+--------+ .-(::::::::::::)-. +--------+
| Server |=(:::: The IRON ::::)=| Server |
+--------+ `-(::::::::::::)-' +--------+
`-(::::::)-'
|| (Tunnels)
+--------+
| Server |
+--------+
Figure 4: IRON Relay Router Connecting IRON to Native Internet
图4:IRON中继路由器将IRON连接到本机互联网
The IRON consists of the union of all VPC overlay networks configured over a common Internetwork (e.g., the public Internet). Each such overlay network represents a distinct "patch" on the Internet "quilt", where the patches are stitched together by tunnels over the links, routers, bridges, etc. that connect the underlying Internetwork. When a new VPC overlay network is deployed, it becomes yet another patch on the quilt. The IRON is therefore a composite overlay network consisting of multiple individual patches, where each patch coordinates its activities independently of all others (with the exception that the Servers of each patch must be aware of all VPs in the IRON). In order to ensure mutual cooperation between all VPC overlay networks, sufficient address space portions of the inner network-layer protocol (e.g., IPv4, IPv6, etc.) should be set aside and designated as VP space.
IRON由在公共互联网（例如，公共互联网）上配置的所有专有网络覆盖网络组成。每一个这样的覆盖网络都代表了互联网“被子”上一个独特的“补丁”，补丁通过连接底层互联网的链路、路由器、网桥等上的隧道缝合在一起。当一个新的VPC覆盖网络部署后，它将成为另一个补丁。因此，IRON是一个由多个单独补丁组成的复合覆盖网络，其中每个补丁独立于所有其他补丁协调其活动（每个补丁的服务器必须知道IRON中的所有VP除外）。为了确保所有VPC覆盖网络之间的相互协作，应留出足够的内网层协议（例如IPv4、IPv6等）地址空间部分，并指定为VP空间。
Each VPC overlay network in the IRON maintains a set of Relays and Servers that provide services to their Client customers. In order to ensure adequate customer service levels, the VPC should conduct a traffic scaling analysis and distribute sufficient Relays and Servers for the overlay network globally throughout the Internet. Figure 5 depicts the logical arrangement of Relays, Servers, and Clients in an IRON virtual overlay network.
IRON中的每个VPC覆盖网络都维护一组为其客户提供服务的中继和服务器。为了确保足够的客户服务水平，专有网络应进行流量缩放分析，并在整个互联网上为覆盖网络在全球范围内分布足够的中继和服务器。图5描述了IRON虚拟覆盖网络中中继、服务器和客户端的逻辑安排。
.-.
,-( _)-.
.-(_ (_ )-.
(__ Internet _)
`-(______)-'
.-.
,-( _)-.
.-(_ (_ )-.
(__ Internet _)
`-(______)-'
<------------ Relays ------------>
________________________
(::::::::::::::::::::::::)-.
.-(:::::::::::::::::::::::::::::)
.-(:::::::::::::::::::::::::::::::::)-.
(::::::::::: The IRON :::::::::::::::)
`-(:::::::::::::::::::::::::::::::::)-'
`-(::::::::::::::::::::::::::::)-'
<------------ Relays ------------>
________________________
(::::::::::::::::::::::::)-.
.-(:::::::::::::::::::::::::::::)
.-(:::::::::::::::::::::::::::::::::)-.
(::::::::::: The IRON :::::::::::::::)
`-(:::::::::::::::::::::::::::::::::)-'
`-(::::::::::::::::::::::::::::)-'
<------------ Servers ------------>
.-. .-. .-.
,-( _)-. ,-( _)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-. .-(_ (_ )-.
(__ ISP A _) (__ ISP B _) ... (__ ISP x _)
`-(______)-' `-(______)-' `-(______)-'
<----------- NATs ------------>
<------------ Servers ------------>
.-. .-. .-.
,-( _)-. ,-( _)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-. .-(_ (_ )-.
(__ ISP A _) (__ ISP B _) ... (__ ISP x _)
`-(______)-' `-(______)-' `-(______)-'
<----------- NATs ------------>
<----------- Clients and EUNs ----------->
<----------- Clients and EUNs ----------->
Figure 5: Virtual Overlay Network Organization
图5：虚拟覆盖网络组织
Each Relay in the VPC overlay network connects the overlay directly to the underlying IPv4 and IPv6 Internets. It also advertises the VPC overlay network's IPv4 VPs into the IPv4 BGP routing system and advertises the overlay network's IPv6 VPs into the IPv6 BGP routing system. Relays will therefore receive packets with EPA destination addresses sent by end systems in the Internet and direct them toward EPA-addressed end systems connected to the VPC overlay network.
VPC覆盖网络中的每个中继将覆盖直接连接到基础IPv4和IPv6互联网。它还将VPC覆盖网络的IPv4 VP播发到IPv4 BGP路由系统，并将覆盖网络的IPv6 VP播发到IPv6 BGP路由系统。因此，中继将接收由互联网终端系统发送的带有EPA目标地址的数据包，并将其定向到连接到VPC覆盖网络的EPA寻址终端系统。
Each VPC overlay network also manages a set of Servers that connect their Clients and associated EUNs to the IRON and to the IPv6 and IPv4 Internets via their associations with Relays. IRON Servers therefore need not be BGP routers themselves; they can be simple commodity hardware platforms. Moreover, the Server and Relay functions can be deployed together on the same physical platform as a unified gateway, or they may be deployed on separate platforms (e.g., for load balancing purposes).
每个VPC覆盖网络还管理一组服务器，这些服务器通过其与中继的关联将其客户端和关联的EUN连接到IRON以及IPv6和IPv4 Internet。因此，IRON服务器本身不必是BGP路由器；它们可以是简单的商品硬件平台。此外，服务器和中继功能可以一起部署在与统一网关相同的物理平台上，也可以部署在单独的平台上（例如，出于负载平衡的目的）。
Each Server maintains a working set of Clients for which it caches EP-to-Client mappings in its Forwarding Information Base (FIB). Each Server also, in turn, propagates the list of EPs in its working set to each of the Relays in the VPC overlay network via a dynamic
每台服务器都维护一组客户端，并在其转发信息库（FIB）中缓存EP到客户端的映射。每台服务器还通过动态网络将其工作集中的EP列表传播到VPC覆盖网络中的每个中继
routing protocol (e.g., an overlay network internal BGP instance that carries only the EP-to-Server mappings and does not interact with the external BGP routing system). Therefore, each Server only needs to track the EPs for its current working set of Clients, while each Relay will maintain a full EP-to-Server mapping table that represents reachability information for all EPs in the VPC overlay network.
路由协议（例如，覆盖网络内部BGP实例，仅携带EP到服务器的映射，不与外部BGP路由系统交互）。因此，每个服务器只需要跟踪其当前工作组客户端的EP，而每个中继将维护完整的EP到服务器映射表，该表表示VPC覆盖网络中所有EP的可达性信息。
Customers establish Clients that obtain their basic Internet connectivity from ISPs and connect to Servers to attach their EUNs to the IRON. Each EUN can connect to the IRON via one or multiple Clients as long as the Clients coordinate with one another, e.g., to mitigate EUN partitions. Unlike Relays and Servers, Clients may use private addresses behind one or several layers of NATs. Each Client initially discovers a list of nearby Servers through an anycast discovery process (described below). It then selects one of these nearby Servers and forms a bidirectional tunnel-neighbor relationship with the server through an initial exchange followed by periodic keepalives.
客户建立客户机，从ISP获得基本的互联网连接，并连接到服务器以将其EUN连接到熨斗。每个EUN可以通过一个或多个客户机连接到IRON，只要客户机彼此协调，例如，减轻EUN分区。与中继和服务器不同，客户端可以在一层或几层NAT后面使用专用地址。每个客户端最初通过选播发现过程（如下所述）发现附近服务器的列表。然后，它选择其中一个附近的服务器，并通过初始交换和周期性保留，与服务器形成双向隧道邻居关系。
After the Client selects a Server, it forwards initial outbound packets from its EUNs by tunneling them to the Server, which, in turn, forwards them to the nearest Relay within the IRON that serves the final destination. The Client will subsequently receive redirect messages informing it of a more direct route through a Server that serves the final destination EUN.
在客户端选择服务器后，它通过隧道将初始出站数据包从其EUN转发到服务器，服务器反过来将其转发到为最终目的地服务的IRON中最近的中继。客户端随后将接收重定向消息，通知它通过服务于最终目的地EUN的服务器的更直接路由。
The IRON can also be used to support VPs of network-layer address families that cannot be routed natively in the underlying Internetwork (e.g., OSI/CLNP over the public Internet, IPv6 over IPv4-only Internetworks, IPv4 over IPv6-only Internetworks, etc.). Further details for the support of IRON VPs of one address family over Internetworks based on other address families are discussed in Appendix A.
IRON还可用于支持网络层地址族的VP，这些地址族不能在基础互联网中本机路由（例如，公共互联网上的OSI/CLNP、仅IPv4互联网上的IPv6、仅IPv6互联网上的IPv4等）。附录A中讨论了在基于其他地址族的互联网上支持一个地址族的IRON VP的更多细节。
IRON initialization entails the startup actions of IAs within the VPC overlay network and customer EUNs. The following sub-sections discuss these startup procedures.
IRON初始化需要在VPC覆盖网络和客户EUN内启动IAs。以下小节讨论这些启动程序。
Before its first operational use, each Relay in a VPC overlay network is provisioned with the list of VPs that it will serve as well as the locators for all Servers that belong to the same overlay network. The Relay is also provisioned with external BGP interconnections -- the same as for any BGP router.
在首次运行使用之前，VPC覆盖网络中的每个中继器都提供了它将用作的VP列表以及属于同一覆盖网络的所有服务器的定位器。中继还配备了外部BGP互连——与任何BGP路由器相同。
Upon startup, the Relay engages in BGP routing exchanges with its peers in the IPv4 and IPv6 Internets the same as for any BGP router. It then connects to all of the Servers in the overlay network (e.g., via a TCP connection over a bidirectional tunnel, via an Internal BGP (IBGP) route reflector, etc.) for the purpose of discovering EP-to-Server mappings. After the Relay has fully populated its EP-to-Server mapping information database, it is said to be "synchronized" with regard to its VPs.
启动后，中继器与IPv4和IPv6 Internet中的对等方进行BGP路由交换，与任何BGP路由器相同。然后，它连接到覆盖网络中的所有服务器（例如，通过双向隧道上的TCP连接，通过内部BGP（IBGP）路由反射器等），以发现EP到服务器的映射。中继已完全填充其EP到服务器映射信息数据库后，称其VPs已“同步”。
After this initial synchronization procedure, the Relay then advertises the overlay network's VPs externally. In particular, the Relay advertises the IPv6 VPs into the IPv6 BGP routing system and advertises the IPv4 VPs into the IPv4 BGP routing system. The Relay additionally advertises an IPv4 /24 companion prefix (e.g., 192.0.2.0/24) into the IPv4 routing system and an IPv6 ::/64 companion prefix (e.g., 2001:DB8::/64) into the IPv6 routing system (note that these may also be sub-prefixes taken from a VP). The Relay then configures the host number '1' in the IPv4 companion prefix (e.g., as 192.0.2.1) and the interface identifier '0' in the IPv6 companion prefix (e.g., as 2001:DB8::0), and it assigns the resulting addresses as subnet-router anycast addresses [RFC3068][RFC2526] for the VPC overlay network. (See Appendix A for more information on the discovery and use of companion prefixes.) The Relay then engages in ordinary packet-forwarding operations.
在该初始同步过程之后，中继随后向外部播发覆盖网络的VP。特别是，中继向IPv6 BGP路由系统播发IPv6 VP，并向IPv4 BGP路由系统播发IPv4 VP。中继还向IPv4路由系统播发IPv4/24伴随前缀（例如192.0.2.0/24），并向IPv6路由系统播发IPv6:：/64伴随前缀（例如2001:DB8:：/64）（注意，这些前缀也可能是取自VP的子前缀）。然后，中继器在IPv4伴随前缀（例如as 192.0.2.1）中配置主机号“1”，在IPv6伴随前缀（例如as 2001:DB8:：0）中配置接口标识符“0”，并将生成的地址分配为VPC覆盖网络的子网路由器选播地址[RFC3068][RFC2526]。（有关发现和使用伴随前缀的更多信息，请参见附录A。）然后，中继器执行普通的数据包转发操作。
Before its first operational use, each Server in a VPC overlay network is provisioned with the locators for all Relays that aggregate the overlay network's VPs. In order to support route optimization, the Server must also be provisioned with the list of all VPs in the IRON (i.e., not just the VPs of its own overlay network) so that it can discern EPA and non-EPA addresses. (Therefore, the Server could be greatly simplified if the list of VPs could be covered within a small number of very short prefixes, e.g., one or a few IPv6 ::/20's). The Server must also discover the VP companion prefix relationships discussed in Section 5.1, e.g., via a global database such as discussed in Appendix A.
在首次运行之前，VPC覆盖网络中的每台服务器都配备了用于聚合覆盖网络VP的所有中继的定位器。为了支持路由优化，还必须为服务器提供IRON中所有VP的列表（即，不仅仅是其自身覆盖网络的VP），以便其能够区分EPA和非EPA地址。（因此，如果VP列表可以包含在少量非常短的前缀内（例如，一个或几个IPv6:：/20），则服务器可以大大简化）。服务器还必须发现第5.1节中讨论的VP伴音前缀关系，例如，通过附录a中讨论的全局数据库。
Upon startup, each Server must connect to all of the Relays within its overlay network (e.g., via a TCP connection, via an IBGP route reflector, etc.) for the purpose of reporting its EP-to-Server mappings. The Server then actively listens for Client customers that register their EP prefixes as part of establishing a bidirectional tunnel-neighbor relationship. When a new Client registers its EP prefixes, the Server announces the new EP additions to all Relays; when an existing Client unregisters its EP prefixes, the Server withdraws its announcements.
启动时，每个服务器必须连接到其覆盖网络内的所有中继（例如，通过TCP连接、通过IBGP路由反射器等），以便报告其EP到服务器的映射。然后，服务器主动侦听注册EP前缀作为建立双向隧道邻居关系的一部分的客户端客户。当一个新的客户机注册其EP前缀时，服务器向所有中继宣布新的EP添加；当现有客户端注销其EP前缀时，服务器将撤回其通知。
Before its first operational use, each Client must obtain one or more EPs from its VPC as well as the companion prefixes associated with the VPC overlay network (see Section 5.1). The Client must also obtain a certificate and a public/private key pair from the VPC that it can later use to prove ownership of its EPs. This implies that each VPC must run its own public key infrastructure to be used only for the purpose of verifying its customers' claimed right to use an EP. Hence, the VPC need not coordinate its public key infrastructure with any other organization.
在首次运营使用之前，每个客户机必须从其专有网络获得一个或多个EP以及与专有网络覆盖网络相关的伴随前缀（见第5.1节）。客户还必须从VPC获得证书和公钥/私钥对，以便日后用于证明其EPs的所有权。这意味着每个专有网络必须运行自己的公钥基础设施，以便仅用于验证其客户声称的EP使用权。因此，专有网络无需与任何其他组织协调其公钥基础设施。
Upon startup, the Client sends an SCMP Router Solicitation (SRS) message to the VPC overlay network subnet-router anycast address to discover the nearest Relay. The Relay will return an SCMP Router Advertisement (SRA) message that lists the locator addresses of one or more nearby Servers. (This list is analogous to the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Potential Router List (PRL) [RFC5214].)
启动时，客户端向VPC覆盖网络子网路由器选播地址发送SCMP路由器请求（SRS）消息，以发现最近的中继。中继将返回一条SCMP路由器公告（SRA）消息，该消息列出一个或多个附近服务器的定位器地址。（该列表类似于站点内自动隧道寻址协议（ISATAP）潜在路由器列表（PRL）[RFC5214]。）
After the Client receives an SRA message from the nearby Relay listing the locator addresses of nearby Servers, it initiates a short transaction with one of the Servers carried by a reliable transport protocol such as TCP in order to establish a bidirectional tunnel-neighbor relationship. The protocol details of the transaction are specific to the VPC, and hence out of scope for this document.
在客户端从附近的中继器接收到列出附近服务器的定位器地址的SRA消息后，它启动与可靠传输协议（如TCP）承载的其中一个服务器的短事务，以便建立双向隧道邻居关系。交易的协议详细信息特定于专有网络，因此不在本文件范围内。
Note that it is essential that the Client select one and only one Server. This is to allow the VPC overlay network mapping system to have one and only one active EP-to-Server mapping at any point in time, which shares fate with the Server itself. If this Server fails, the Client can select a new one that will automatically update the VPC overlay network mapping system with a new EP-to-Server mapping.
请注意，客户端必须选择一个且仅选择一个服务器。这是为了允许VPC覆盖网络映射系统在任何时间点都只有一个活动EP到服务器的映射，该映射与服务器本身共享命运。如果此服务器出现故障，客户端可以选择一个新服务器，该服务器将自动使用新的EP到服务器映射更新VPC覆盖网络映射系统。
Following the IRON initialization detailed in Section 5, IAs engage in the steady-state process of receiving and forwarding packets. All IAs forward encapsulated packets over the IRON using the mechanisms of VET [INTAREA-VET] and SEAL [INTAREA-SEAL], while Relays (and in some cases Servers) additionally forward packets to and from the native IPv6 and IPv4 Internets. IAs also use SCMP to coordinate with other IAs, including the process of sending and receiving redirect messages, error messages, etc. (Note however that an IA must not send an SCMP message in response to an SCMP error message.) Each IA operates as specified in the following sub-sections.
在第5节详述的IRON初始化之后，IAs参与接收和转发数据包的稳态过程。所有IAs都使用VET[Intrea-VET]和SEAL[Intrea-SEAL]机制在IRON上转发封装的数据包，而中继（在某些情况下是服务器）还向本机IPv6和IPv4 Internet转发数据包。IAs还使用SCMP与其他IAs进行协调，包括发送和接收重定向消息、错误消息等的过程（但请注意，IA不得发送SCMP消息以响应SCMP错误消息）。每个IA按照以下小节中的规定进行操作。
After selecting its Server as specified in Section 5.3, the Client should register each of its ISP connections with the Server for multihoming purposes. To do so, it sends periodic beacons (e.g., SRS messages) to its Server via each of its ISPs to establish additional tunnel-neighbor state. This implies that a single tunnel-neighbor identifier (i.e., a "nonce") is used to represent the set of all ISP paths between the Client and the Server. Therefore, the nonce names this "bundle" of ISP paths.
按照第5.3节的规定选择服务器后，客户机应将其每个ISP连接注册到服务器，以实现多主目的。为此，它通过每个ISP定期向其服务器发送信标（例如SRS消息），以建立额外的隧道邻居状态。这意味着使用单个隧道邻居标识符（即“nonce”）来表示客户端和服务器之间的所有ISP路径集。因此，nonce将ISP路径命名为“bundle”。
If the Client ceases to receive acknowledgements from its Server via a specific ISP connection, it marks the Server as unreachable from that address and therefore over that ISP connection. (The Client should also inform its Server of this outage via one of its working ISP connections.) If the Client ceases to receive acknowledgements from its Server via multiple ISP connections, it marks the Server as unusable and quickly attempts to register with a new Server. The act of registering with a new Server will automatically purge the stale mapping state associated with the old Server, since dynamic routing will propagate the new client/server relationship to the VPC overlay network Relay Routers.
如果客户端停止通过特定ISP连接从其服务器接收确认，则会将服务器标记为无法从该地址访问，因此无法通过该ISP连接访问。（客户端还应通过其一个工作的ISP连接将此中断通知其服务器。）如果客户端停止通过多个ISP连接从其服务器接收确认，则会将服务器标记为不可用，并快速尝试向新服务器注册。向新服务器注册的行为将自动清除与旧服务器关联的过时映射状态，因为动态路由将新的客户端/服务器关系传播到VPC覆盖网络中继路由器。
When an end system in an EUN sends a flow of packets to a correspondent, the packets are forwarded through the EUN via normal routing until they reach the Client, which then tunnels the initial packets to its Server as the next hop. In particular, the Client encapsulates each packet in an outer header with its locator as the source address and the locator of its Server as the destination address. Note that after sending the initial packets of a flow, the Client may receive important SCMP messages, such as indications of PMTU limitations, redirects that point to a better next hop, etc.
当EUN中的终端系统向对应方发送数据包流时，数据包通过正常路由通过EUN转发，直到它们到达客户端，然后客户端将初始数据包作为下一跳通过隧道传输到其服务器。具体而言，客户机将每个分组封装在外部报头中，其定位器作为源地址，其服务器的定位器作为目的地址。注意，在发送流的初始分组之后，客户端可以接收重要的SCMP消息，例如PMTU限制的指示、指向更好的下一跳的重定向等。
The Client uses the mechanisms specified in VET and SEAL to encapsulate each forwarded packet. The Client further uses the SCMP protocol to coordinate with Servers, including accepting redirects and other SCMP messages. When the Client receives an SCMP message, it checks the nonce field of the encapsulated packet-in-error to verify that the message corresponds to the tunnel-neighbor state for its Server and accepts the message if the nonce matches. (Note however that the outer source and destination addresses of the packet-in-error may be different than those in the original packet due to possible Server and/or Relay address rewritings.)
客户端使用VET和SEAL中指定的机制来封装每个转发的数据包。客户端还使用SCMP协议与服务器协调，包括接受重定向和其他SCMP消息。当客户端接收到SCMP消息时，它会检查错误封装数据包的nonce字段，以验证该消息是否对应于其服务器的隧道邻居状态，并在nonce匹配时接受该消息。（然而，请注意，由于可能的服务器和/或中继地址重写，错误数据包的外部源地址和目的地址可能与原始数据包中的不同。）
After the Server is initialized, it responds to SRSs from Clients by sending SRAs. When the Server receives a SEAL-encapsulated packet from one of its Client tunnel neighbors, it examines the inner destination address. If the inner destination address is not an EPA, the Server decapsulates the packet and forwards it unencapsulated into the Internet if it is able to do so without loss due to ingress filtering. Otherwise, the Server re-encapsulates the packet (i.e., it removes the outer header and replaces it with a new outer header of the same address family) and sets the outer destination address to the locator address of a Relay within its VPC overlay network. It then forwards the re-encapsulated packet to the Relay, which will, in turn, decapsulate it and forward it into the Internet.
服务器初始化后，通过发送SRA从客户端响应SRS。当服务器从其一个客户端隧道邻居接收到密封封装的数据包时，它会检查内部目标地址。如果内部目标地址不是EPA，则服务器将解除数据包的封装，并将其转发到Internet，前提是它能够这样做而不会由于入口过滤而丢失数据包。否则，服务器将重新封装数据包（即，它删除外部报头并用同一地址系列的新外部报头替换），并将外部目的地地址设置为其VPC覆盖网络内中继的定位地址。然后，它将重新封装的数据包转发给中继器，中继器将依次将其解封并转发到Internet。
If the inner destination address is an EPA, however, the Server rewrites the outer source address to one of its own locator addresses and rewrites the outer destination address to the subnet-router anycast address taken from the companion prefix associated with the inner destination address (where the companion prefix of the same address family as the outer IP protocol is used). The Server then forwards the revised encapsulated packet into the Internet via a default or more specific route, where it will be directed to the closest Relay within the destination VPC overlay network. After sending the packet, the Server may then receive an SCMP error or redirect message from a Relay/Server within the destination VPC overlay network. In that case, the Server verifies that the nonce in the message matches the Client that sent the original inner packet and discards the message if the nonce does not match. Otherwise, the Server re-encapsulates the SCMP message in a new outer header that uses the source address, destination address, and nonce parameters associated with the Client's tunnel-neighbor state; it then forwards the message to the Client. This arrangement is necessary to allow SCMP messages to flow through any NATs on the path.
但是，如果内部目标地址是EPA，则服务器将外部源地址重写为其自己的定位地址之一，并将外部目标地址重写为子网路由器选播地址，该地址取自与内部目标地址关联的伴随前缀（使用与外部IP协议相同的地址系列的伴随前缀）。然后，服务器通过默认或更具体的路由将修改后的封装数据包转发到Internet，并将其定向到目标VPC覆盖网络内最近的中继。发送数据包后，服务器可能会从目标VPC覆盖网络内的中继/服务器接收SCMP错误或重定向消息网络。在这种情况下，服务器验证消息中的nonce是否与发送原始内部数据包的客户端匹配，如果nonce不匹配，则丢弃该消息。否则，服务器会将SCMP消息重新封装在一个新的外部头中，该头使用与源地址、目标地址和nonce参数关联的源地址、目标地址和nonce参数e客户端的隧道邻居状态；然后将消息转发给客户端。这种安排对于允许SCMP消息通过路径上的任何NAT是必要的。
When a Server ('A') receives a SEAL-encapsulated packet from a Relay or from the Internet, if the inner destination address matches an EP in its FIB, 'A' re-encapsulates the packet in a new outer header and forwards it to a Client ('B'), which, in turn, decapsulates the packet and forwards it to the correct end system in the EUN. However, if 'B' has left notice with 'A' that it has moved to a new Server ('C'), 'A' will instead forward the packet to 'C' and also send an SCMP redirect message back to the source of the packet. In this way, 'B' can leave behind forwarding information when changing between Servers 'A' and 'C' (e.g., due to mobility events) without exposing packets to loss.
当服务器（“a”）从中继器或互联网接收到密封封装的数据包时，如果内部目的地地址与其FIB中的EP匹配，“a”将数据包重新封装在新的外部报头中，并将其转发给客户端（“B”），而客户端（“B”）则将数据包解封并转发给EUN中的正确终端系统。但是，如果“B”通知“A”它已移动到新服务器（“C”），则“A”将改为将数据包转发到“C”，并将SCMP重定向消息发送回数据包的源。这样，“B”可以在服务器“A”和“C”之间切换时（例如，由于移动事件）留下转发信息，而不会使数据包丢失。
After each Relay has synchronized its VPs (see Section 5.1) it advertises the full set of the company's VPs and companion prefixes into the IPv4 and IPv6 Internet BGP routing systems. These prefixes will be represented as ordinary routing information in the BGP, and any packets originating from the IPv4 or IPv6 Internet destined to an address covered by one of the prefixes will be forwarded to one of the VPC overlay network's Relays.
在每个中继同步其VP（见第5.1节）后，它会将公司的整套VP和伴随前缀发布到IPv4和IPv6互联网BGP路由系统中。这些前缀将在BGP中表示为普通路由信息，任何来自IPv4或IPv6互联网、目的地为其中一个前缀覆盖的地址的数据包都将转发到VPC覆盖网络的一个中继。
When a Relay receives a packet from the Internet destined to an EPA covered by one of its VPs, it behaves as an ordinary IP router. In particular, the Relay looks in its FIB to discover a locator of the Server that serves the EP covering the destination address. The Relay then simply encapsulates the packet with its own locator as the outer source address and the locator of the Server as the outer destination address and forwards the packet to the Server.
当一个中继从互联网接收到一个数据包，该数据包的目的地是它的一个VP覆盖的EPA，它的行为就像一个普通的IP路由器。特别是，中继器在其FIB中查找为EP提供服务的服务器的定位器，该定位器覆盖目标地址。然后，中继器简单地用它自己的定位器作为外部源地址和服务器的定位器作为外部目的地地址封装数据包，并将数据包转发给服务器。
When a Relay receives a packet from the Internet destined to one of its subnet-router anycast addresses, it discards the packet if it is not SEAL encapsulated. If the packet is an SCMP SRS message, the Relay instead sends an SRA message back to the source listing the locator addresses of nearby Servers then discards the message. The Relay otherwise discards all other SCMP messages.
当中继从Internet接收到一个数据包，该数据包的目的地为其子网路由器选播地址之一时，如果该数据包未密封封装，则会丢弃该数据包。如果数据包是SCMP SRS消息，则中继会将SRA消息发送回源，列出附近服务器的定位器地址，然后丢弃该消息。否则，中继将丢弃所有其他SCMP消息。
If the packet is an ordinary SEAL packet (i.e., one that encapsulates an inner packet), the Relay sends an SCMP redirect message of the same address family back to the source with the locator of the Server that serves the EPA destination in the inner packet as the redirected target. The source and destination addresses of the SCMP redirect message use the outer destination and source addresses of the original packet, respectively. After sending the redirect message, the Relay then rewrites the outer destination address of the SEAL-encapsulated packet to the locator of the Server and forwards the revised packet to the Server. Note that in this arrangement, any errors that occur on the path between the Relay and the Server will be delivered to the original source but with a different destination address due to this Relay address rewriting.
如果数据包是普通密封数据包（即封装内部数据包的数据包），中继器将相同地址族的SCMP重定向消息发送回源，并将服务于内部数据包中EPA目的地的服务器的定位器作为重定向目标。SCMP重定向消息的源地址和目标地址分别使用原始数据包的外部目标地址和源地址。在发送重定向消息之后，中继随后将密封封装的分组的外部目的地地址重写到服务器的定位器，并将修改后的分组转发到服务器。注意，在这种安排中，在中继和服务器之间的路径上发生的任何错误都将被传送到原始源，但由于中继地址重写而具有不同的目标地址。
The IRON supports communications when one or both hosts are located within EP-addressed EUNs, regardless of whether the EPs are provisioned by the same VPC or by different VPCs. When both hosts are within IRON EUNs, route redirections that eliminate unnecessary Servers and Relays from the path are possible. When only one host is within an IRON EUN, however, route optimization cannot be used. The following sections discuss the two scenarios.
当一个或两个主机位于EP寻址的EUN内时，IRON支持通信，无论EPs是由同一VPC还是由不同的VPC提供。当两台主机都在IRON EUN内时，可以通过路由重定向消除路径中不必要的服务器和中继。但是，当一个IRON EUN内只有一个主机时，不能使用路由优化。以下各节将讨论这两种场景。
When both hosts are within IRON EUNs, it is sufficient to consider the scenario in a unidirectional fashion, i.e., by tracing packet flows only in the forward direction from source host to destination host. The reverse direction can be considered separately and incurs the same considerations as for the forward direction.
当两个主机都在铁EuNs中时，就足以以单向方式考虑场景，即，只跟踪从源主机到目的主机的正向流的分组流。反向可以单独考虑，并引起与正向相同的考虑。
In this scenario, the initial packets of a flow produced by a source host within an EUN connected to the IRON by a Client must flow through both the Server of the source host and a Relay of the destination host, but route optimization can eliminate these elements from the path for subsequent packets in the flow. Figure 6 shows the flow of initial packets from host A to host B within two IRON EUNs (the same scenario applies whether the two EUNs are within the same VPC overlay network or different overlay networks).
在该场景中，由客户端连接到IRON的EUN内的源主机产生的流的初始分组必须同时流经源主机的服务器和目的主机的中继，但是路由优化可以从流中后续分组的路径中消除这些元素。图6显示了两个IRON EUN内从主机A到主机B的初始数据包流（无论两个EUN是在同一VPC覆盖网络内还是在不同覆盖网络内，都适用相同的场景）。
________________________________________
.-( .-. )-.
.-( ,-( _)-. )-.
.-( +========+(_ (_ +=====+ )-.
.( || (_|| Internet ||_) || ).
.( || ||-(______)-|| vv ).
.( +--------++--+ || || +------------+ ).
( +==>| Server(A) | vv || | Server(B) |====+ )
( // +---------|\-+ +--++----++--+ +------------+ \\ )
( // .-. | \ | Relay(B) | .-. \\ )
( //,-( _)-. | \ +-v----------+ ,-( _)-\\ )
( .||_ (_ )-. | \____| .-(_ (_ ||. )
( _|| ISP A .) | (__ ISP B ||_))
( ||-(______)-' | (redirect) `-(______)|| )
( || | | | vv )
( +-----+-----+ | +-----+-----+ )
| Client(A) | <--+ | Client(B) |
+-----+-----+ The IRON +-----+-----+
| ( (Overlaid on the Native Internet) ) |
.-. .-( .-) .-.
,-( _)-. .-(________________________)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-.
(_ IRON EUN A ) (_ IRON EUN B )
`-(______)-' `-(______)-'
| |
+---+----+ +---+----+
| Host A | | Host B |
+--------+ +--------+
________________________________________
.-( .-. )-.
.-( ,-( _)-. )-.
.-( +========+(_ (_ +=====+ )-.
.( || (_|| Internet ||_) || ).
.( || ||-(______)-|| vv ).
.( +--------++--+ || || +------------+ ).
( +==>| Server(A) | vv || | Server(B) |====+ )
( // +---------|\-+ +--++----++--+ +------------+ \\ )
( // .-. | \ | Relay(B) | .-. \\ )
( //,-( _)-. | \ +-v----------+ ,-( _)-\\ )
( .||_ (_ )-. | \____| .-(_ (_ ||. )
( _|| ISP A .) | (__ ISP B ||_))
( ||-(______)-' | (redirect) `-(______)|| )
( || | | | vv )
( +-----+-----+ | +-----+-----+ )
| Client(A) | <--+ | Client(B) |
+-----+-----+ The IRON +-----+-----+
| ( (Overlaid on the Native Internet) ) |
.-. .-( .-) .-.
,-( _)-. .-(________________________)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-.
(_ IRON EUN A ) (_ IRON EUN B )
`-(______)-' `-(______)-'
| |
+---+----+ +---+----+
| Host A | | Host B |
+--------+ +--------+
Figure 6: Initial Packet Flow before Redirects
图6：重定向前的初始数据包流
With reference to Figure 6, host A sends packets destined to host B via its network interface connected to EUN A. Routing within EUN A will direct the packets to Client(A) as a default router for the EUN, which then uses VET and SEAL to encapsulate them in outer headers with its locator address as the outer source address and the locator address of Server(A) as the outer destination address. Client(A) then simply forwards the encapsulated packets into its ISP network connection that provided its locator. The ISP will forward the encapsulated packets into the Internet without filtering since the (outer) source address is topologically correct. Once the packets have been forwarded into the Internet, routing will direct them to Server(A).
参考图6，主机A通过其连接到EUN A的网络接口向主机B发送数据包。EUN A内的路由将数据包定向到客户端（A），作为EUN的默认路由器，然后，它使用VET和SEAL将它们封装在外部头中，其定位器地址作为外部源地址，服务器（A）的定位器地址作为外部目标地址。然后，客户机（A）简单地将封装的数据包转发到其ISP网络连接中，该网络连接提供了其定位器。由于（外部）源地址在拓扑上是正确的，ISP将在不进行过滤的情况下将封装的数据包转发到Internet。一旦数据包被转发到Internet，路由将把它们定向到服务器（A）。
Server(A) receives the encapsulated packets from Client(A) then rewrites the outer source address to one of its own locator addresses and rewrites the outer destination address to the subnet-router anycast address of the appropriate address family associated with the inner destination address. Server(A) then forwards the revised encapsulated packets into the Internet, where routing will direct them to Relay(B), which services the VPC overlay network associated with host B.
服务器（A）从客户端（A）接收封装的分组，然后将外部源地址重写为其自己的定位器地址之一，并将外部目标地址重写为与内部目标地址相关联的适当地址族的子网路由器选播地址。然后，服务器（A）将修改后的封装数据包转发到Internet，在Internet上路由将它们定向到中继（B），中继（B）为与主机B关联的VPC覆盖网络提供服务。
Relay(B) will intercept the encapsulated packets from Server(A) then check its FIB to discover an entry that covers inner destination address B with Server(B) as the next hop. Relay(B) then returns SCMP redirect messages to Server(A) (*), rewrites the outer destination address of the encapsulated packets to the locator address of Server(B), and forwards these revised packets to Server(B).
中继（B）将截获来自服务器（A）的封装数据包，然后检查其FIB以发现覆盖内部目标地址B的条目，服务器（B）作为下一个跃点。中继（B）然后将SCMP重定向消息返回给服务器（A）（*），将封装包的外部目标地址重写为服务器（B）的定位器地址，并将这些修改后的包转发给服务器（B）。
Server(B) will receive the encapsulated packets from Relay(B) then check its FIB to discover an entry that covers destination address B with Client(B) as the next hop. Server(B) then re-encapsulates the packets in a new outer header that uses the source address, destination address, and nonce parameters associated with the tunnel-neighbor state for Client(B). Server(B) then forwards these re-encapsulated packets into the Internet, where routing will direct them to Client(B). Client(B) will, in turn, decapsulate the packets and forward the inner packets to host B via EUN B.
服务器（B）将从中继器（B）接收封装的数据包，然后检查其FIB以发现覆盖目标地址B的条目，客户端（B）作为下一个跃点。然后，服务器（B）将数据包重新封装在新的外部报头中，该报头使用与客户端（B）的隧道邻居状态相关联的源地址、目标地址和nonce参数。然后，服务器（B）将这些重新封装的数据包转发到Internet，路由将它们定向到客户端（B）。客户端（B）将依次解除数据包的封装，并通过EUN B将内部数据包转发给主机B。
(*) Note that after the initial flow of packets, Server(A) will have received one or more SCMP redirect messages from Relay(B) listing Server(B) as a better next hop. Server(A) will, in turn, forward the redirects to Client(A), which will establish unidirectional tunnel-neighbor state and thereafter forward its encapsulated packets directly to the locator address of Server(B) without involving either Server(A) or Relay(B), as shown in Figure 7.
（*）注意，在初始数据包流之后，服务器（A）将从中继（B）接收到一个或多个SCMP重定向消息，中继（B）将服务器（B）列为更好的下一跳。服务器（A）反过来将重定向转发给客户端（A），客户端（A）将建立单向隧道邻居状态，然后将其封装的数据包直接转发到服务器（B）的定位器地址，而不涉及服务器（A）或中继（B），如图7所示。
________________________________________
.-( .-. )-.
.-( ,-( _)-. )-.
.-( +=============> .-(_ (_ )-.======+ )-.
.( // (__ Internet _) || ).
.( // `-(______)-' vv ).
.( // +------------+ ).
( // | Server(B) |====+ )
( // +------------+ \\ )
( // .-. .-. \\ )
( //,-( _)-. ,-( _)-\\ )
( .||_ (_ )-. .-(_ (_ ||. )
( _|| ISP A .) (__ ISP B ||_))
( ||-(______)-' `-(______)|| )
( || | | vv )
( +-----+-----+ The IRON +-----+-----+ )
| Client(A) | (Overlaid on the native Internet) | Client(B) |
+-----+-----+ +-----+-----+
| ( ) |
.-. .-( .-) .-.
,-( _)-. .-(________________________)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-.
(_ IRON EUN A ) (_ IRON EUN B )
`-(______)-' `-(______)-'
| |
+---+----+ +---+----+
| Host A | | Host B |
+--------+ +--------+
________________________________________
.-( .-. )-.
.-( ,-( _)-. )-.
.-( +=============> .-(_ (_ )-.======+ )-.
.( // (__ Internet _) || ).
.( // `-(______)-' vv ).
.( // +------------+ ).
( // | Server(B) |====+ )
( // +------------+ \\ )
( // .-. .-. \\ )
( //,-( _)-. ,-( _)-\\ )
( .||_ (_ )-. .-(_ (_ ||. )
( _|| ISP A .) (__ ISP B ||_))
( ||-(______)-' `-(______)|| )
( || | | vv )
( +-----+-----+ The IRON +-----+-----+ )
| Client(A) | (Overlaid on the native Internet) | Client(B) |
+-----+-----+ +-----+-----+
| ( ) |
.-. .-( .-) .-.
,-( _)-. .-(________________________)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-.
(_ IRON EUN A ) (_ IRON EUN B )
`-(______)-' `-(______)-'
| |
+---+----+ +---+----+
| Host A | | Host B |
+--------+ +--------+
Figure 7: Sustained Packet Flow after Redirects
图7：重定向后的持续数据包流
When one host is within an IRON EUN and the other is in a non-IRON EUN (i.e., one that connects to the native Internet instead of the IRON), the IA elements involved depend on the packet-flow directions. The cases are described in the following sub-sections.
当一台主机位于IRON EUN内而另一台主机位于非IRON EUN内（即，连接到本机互联网而不是IRON的主机）时，所涉及的IA元素取决于分组流方向。这些案例在以下小节中进行了描述。
Figure 8 depicts the IRON reference operating scenario for packets flowing from host A in an IRON EUN to host B in a non-IRON EUN.
图8描述了从IRON EUN中的主机A到非IRON EUN中的主机B的数据包的IRON参考操作场景。
_________________________________________
.-( )-. )-.
.-( +-------)----+ )-.
.-( | Relay(A) |--------------+ )-.
.( +------------+ \ ).
.( +=======>| Server(A) | \ ).
.( // +--------)---+ \ ).
( // ) \ )
( // The IRON ) \ )
( // .-. ) \ .-. )
( //,-( _)-. ) \ ,-( _)-. )
( .||_ (_ )-. ) The Native Internet .-|_ (_ )-. )
( _|| ISP A ) ) (_ | ISP B ))
( ||-(______)-' ) |-(______)-' )
( || | )-. v | )
( +-----+ ----+ )-. +-----+-----+ )
| Client(A) |)-. | Router B |
+-----+-----+ +-----+-----+
| ( ) |
.-. .-(____________________________________)-. .-.
,-( _)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-.
(_ IRON EUN A ) (_non-IRON EUN B)
`-(______)-' `-(______)-'
| |
+---+----+ +---+----+
| Host A | | Host B |
+--------+ +--------+
_________________________________________
.-( )-. )-.
.-( +-------)----+ )-.
.-( | Relay(A) |--------------+ )-.
.( +------------+ \ ).
.( +=======>| Server(A) | \ ).
.( // +--------)---+ \ ).
( // ) \ )
( // The IRON ) \ )
( // .-. ) \ .-. )
( //,-( _)-. ) \ ,-( _)-. )
( .||_ (_ )-. ) The Native Internet .-|_ (_ )-. )
( _|| ISP A ) ) (_ | ISP B ))
( ||-(______)-' ) |-(______)-' )
( || | )-. v | )
( +-----+ ----+ )-. +-----+-----+ )
| Client(A) |)-. | Router B |
+-----+-----+ +-----+-----+
| ( ) |
.-. .-(____________________________________)-. .-.
,-( _)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-.
(_ IRON EUN A ) (_non-IRON EUN B)
`-(______)-' `-(______)-'
| |
+---+----+ +---+----+
| Host A | | Host B |
+--------+ +--------+
Figure 8: From IRON Host A to Non-IRON Host B
图8：从铁基质A到非铁基质B
In this scenario, host A sends packets destined to host B via its network interface connected to IRON EUN A. Routing within EUN A will direct the packets to Client(A) as a default router for the EUN, which then uses VET and SEAL to encapsulate them in outer headers with its locator address as the outer source address and the locator address of Server(A) as the outer destination address. The ISP will pass the packets without filtering since the (outer) source address is topologically correct. Once the packets have been released into the native Internet, routing will direct them to Server(A).
在这种情况下，主机A通过其连接到IRON EUN A的网络接口向主机B发送数据包。EUN A内的路由将数据包定向到客户端（A），作为EUN的默认路由器，然后，它使用VET和SEAL将它们封装在外部头中，其定位器地址作为外部源地址，服务器（A）的定位器地址作为外部目标地址。由于（外部）源地址在拓扑上是正确的，ISP将在不进行过滤的情况下传递数据包。一旦数据包被释放到本机Internet，路由将把它们定向到服务器（A）。
Server(A) receives the encapsulated packets from Client(A) then re-encapsulates and forwards them to Relay(A), which simply decapsulates them and forwards the unencapsulated packets into the Internet. Once the packets are released into the Internet, routing will direct them to the final destination B. (Note that Server(A) and Relay(A) are
服务器（A）从客户端（A）接收封装的数据包，然后将其重新封装并转发给中继（A），中继（A）只需解除封装并将未封装的数据包转发到Internet。一旦数据包被释放到Internet，路由将把它们定向到最终目的地B。（注意，服务器（A）和中继（A）是
depicted in Figure 8 as two halves of a unified gateway. In that case, the "forwarding" between Server(A) and Relay(A) is a zero-instruction imaginary operation within the gateway.)
在图8中描述为统一网关的两部分。在这种情况下，服务器（A）和中继器（A）之间的“转发”是网关内的零指令操作。）
This scenario always involves a Server and Relay owned by the VPC that provides service to IRON EUN A. Therefore, it imparts a cost that would need to be borne by either the VPC or its customers.
这种情况通常涉及专有网络拥有的一台服务器和中继，该服务器和中继向IRON EUN a提供服务。因此，它带来的成本需要由专有网络或其客户承担。
Figure 9 depicts the IRON reference operating scenario for packets flowing from host B in an Non-IRON EUN to host A in an IRON EUN.
图9描述了从非IRON EUN中的主机B到IRON EUN中的主机A的数据包的IRON参考操作场景。
_______________________________________
.-( )-. )-.
.-( +-------)----+ )-.
.-( | Relay(A) |<-------------+ )-.
.( +------------+ \ ).
.( +========| Server(A) | \ ).
.( // +--------)---+ \ ).
( // ) \ )
( // The IRON ) \ )
( // .-. ) \ .-. )
( //,-( _)-. ) \ ,-( _)-. )
( .||_ (_ )-. ) The Native Internet .-|_ (_ )-. )
( _|| ISP A ) ) (_ | ISP B ))
( ||-(______)-' ) |-(______)-' )
( vv | )-. | | )
( +-----+ ----+ )-. +-----+-----+ )
| Client(A) |)-. | Router B |
+-----+-----+ +-----+-----+
| ( ) |
.-. .-(____________________________________)-. .-.
,-( _)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-.
(_ IRON EUN A ) (_non-IRON EUN B)
`-(______)-' `-(_______)-'
| |
+---+----+ +---+----+
| Host A | | Host B |
+--------+ +--------+
_______________________________________
.-( )-. )-.
.-( +-------)----+ )-.
.-( | Relay(A) |<-------------+ )-.
.( +------------+ \ ).
.( +========| Server(A) | \ ).
.( // +--------)---+ \ ).
( // ) \ )
( // The IRON ) \ )
( // .-. ) \ .-. )
( //,-( _)-. ) \ ,-( _)-. )
( .||_ (_ )-. ) The Native Internet .-|_ (_ )-. )
( _|| ISP A ) ) (_ | ISP B ))
( ||-(______)-' ) |-(______)-' )
( vv | )-. | | )
( +-----+ ----+ )-. +-----+-----+ )
| Client(A) |)-. | Router B |
+-----+-----+ +-----+-----+
| ( ) |
.-. .-(____________________________________)-. .-.
,-( _)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-.
(_ IRON EUN A ) (_non-IRON EUN B)
`-(______)-' `-(_______)-'
| |
+---+----+ +---+----+
| Host A | | Host B |
+--------+ +--------+
Figure 9: From Non-IRON Host B to IRON Host A
图9：从非铁主体B到铁主体A
In this scenario, host B sends packets destined to host A via its network interface connected to non-IRON EUN B. Routing will direct the packets to Relay(A), which then forwards them to Server(A) using encapsulation if necessary.
在这种情况下，主机B通过其连接到非IRON EUN B的网络接口向主机A发送数据包。路由将数据包定向到中继（A），中继（A）然后在必要时使用封装将数据包转发到服务器（A）。
Server(A) will then check its FIB to discover an entry that covers destination address A with Client(A) as the next hop. Server(A) then (re-)encapsulates the packets in an outer header that uses the source address, destination address, and nonce parameters associated with the tunnel-neighbor state for Client(A). Next, Server(A) forwards these (re-)encapsulated packets into the Internet, where routing will direct them to Client(A). Client(A) will, in turn, decapsulate the packets and forward the inner packets to host A via its network interface connected to IRON EUN A.
然后，服务器（A）将检查其FIB，以发现覆盖目标地址A的条目，客户端（A）作为下一个跃点。然后，服务器（A）将数据包（重新）封装在外部报头中，该报头使用与客户端（A）的隧道邻居状态相关联的源地址、目标地址和nonce参数。接下来，服务器（A）将这些（重新）封装的数据包转发到Internet，路由将把它们定向到客户端（A）。客户机（A）将依次解除数据包的封装，并通过其连接到IRON EUN A的网络接口将内部数据包转发给主机A。
This scenario always involves a Server and Relay owned by the VPC that provides service to IRON EUN A. Therefore, it imparts a cost that would need to be borne by either the VPC or its customers.
这种情况通常涉及专有网络拥有的一台服务器和中继，该服务器和中继向IRON EUN a提供服务。因此，它带来的成本需要由专有网络或其客户承担。
While IRON Servers and Relays can be considered as fixed infrastructure, Clients may need to move between different network points of attachment, connect to multiple ISPs, or explicitly manage their traffic flows. The following sections discuss mobility, multihoming, and traffic engineering considerations for IRON client routers.
虽然IRON服务器和中继可以被视为固定基础设施，但客户端可能需要在不同的网络连接点之间移动，连接到多个ISP，或者显式管理其流量。以下各节讨论IRON客户端路由器的移动性、多主和流量工程考虑因素。
When a Client changes its network point of attachment (e.g., due to a mobility event), it configures one or more new locators. If the Client has not moved far away from its previous network point of attachment, it simply informs its Server of any locator additions or deletions. This operation is performance sensitive and should be conducted immediately to avoid packet loss.
当客户端更改其网络连接点时（例如，由于移动事件），它将配置一个或多个新定位器。如果客户端没有远离其以前的网络连接点，它只会通知其服务器任何定位器的添加或删除。此操作对性能敏感，应立即执行以避免数据包丢失。
If the Client has moved far away from its previous network point of attachment, however, it re-issues the anycast discovery procedure described in Section 6.1 to discover whether its candidate set of Servers has changed. If the Client's current Server is also included in the new list received from the VPC, this provides indication that the Client has not moved far enough to warrant changing to a new Server. Otherwise, the Client may wish to move to a new Server in order to reduce routing stretch. This operation is not performance critical, and therefore can be conducted over a matter of seconds/ minutes instead of milliseconds/microseconds.
但是，如果客户端已远离其以前的网络连接点，则会重新发布第6.1节中描述的选播发现过程，以发现其候选服务器集是否已更改。如果客户端的当前服务器也包含在从VPC收到的新列表中，则这表明客户端尚未移动到足以保证更改为新服务器的程度。否则，客户端可能希望移动到新服务器以减少路由扩展。此操作不是性能关键，因此可以在几秒钟/分钟而不是几毫秒/微秒的时间内执行。
To move to a new Server, the Client first engages in the EP registration process with the new Server, as described in Section 5.3. The Client then informs its former Server that it has moved by
如第5.3节所述，要移动到新服务器，客户端首先参与新服务器的EP注册过程。然后，客户机通知其以前的服务器它已经移动了
providing it with the locator address of the new Server; again, via a VPC-specific reliable transaction. The former Server will then garbage-collect the stale FIB entries when their lifetime expires.
向其提供新服务器的定位地址；同样，通过专有网络特定的可靠交易。前一个服务器将在过时的FIB条目的生存期到期时对其进行垃圾收集。
This will allow the former Server to redirect existing correspondents to the new Server so that no packets are lost.
这将允许前一个服务器将现有的通信者重定向到新服务器，这样就不会丢失任何数据包。
A Client may register multiple locators with its Server. It can assign metrics with its registrations to inform the Server of preferred locators, and it can select outgoing locators according to its local preferences. Therefore, multihoming is naturally supported.
客户端可以向其服务器注册多个定位器。它可以通过注册来分配度量，以通知服务器首选定位器，并且可以根据其本地首选项选择传出定位器。因此，自然支持多归宿。
A Client can dynamically adjust the priorities of its prefix registrations with its Server in order to influence inbound traffic flows. It can also change between Servers when multiple Servers are available, but should strive for stability in its Server selection in order to limit VPC network routing churn.
客户机可以动态调整其服务器前缀注册的优先级，以影响入站流量。当有多台服务器可用时，它也可以在服务器之间切换，但应努力在服务器选择上保持稳定性，以限制VPC网络路由的波动。
A Client can select outgoing locators, e.g., based on current Quality-of-Service (QoS) considerations such as minimizing one-way delay or one-way delay variance.
客户机可以选择出站定位器，例如，基于当前服务质量（QoS）考虑，例如最小化单向延迟或单向延迟方差。
As new link-layer technologies and/or service models emerge, customers will be motivated to select their service providers through healthy competition between ISPs. If a customer's EUN addresses are tied to a specific ISP, however, the customer may be forced to undergo a painstaking EUN renumbering process if it wishes to change to a different ISP [RFC4192][RFC5887].
随着新的链路层技术和/或服务模式的出现，客户将通过ISP之间的健康竞争来选择其服务提供商。但是，如果客户的EUN地址与特定ISP绑定，则如果客户希望更改为其他ISP[RFC4192][RFC5887]，则可能会被迫进行艰苦的EUN重新编号过程。
When a customer obtains EP prefixes from a VPC, it can change between ISPs seamlessly and without need to renumber. If the VPC itself applies unreasonable costing structures for use of the EPs, however, the customer may be compelled to seek a different VPC and would again be required to confront a renumbering scenario. The IRON approach to renumbering avoidance therefore depends on VPCs conducting ethical business practices and offering reasonable rates.
当客户从VPC获得EP前缀时，它可以在ISP之间无缝切换，而无需重新编号。但是，如果专有网络本身对EPs的使用采用了不合理的成本结构，客户可能会被迫寻求不同的专有网络，并再次需要面对重新编号的情况。因此，重新编号避免的铁的方法取决于VPC进行道德商业实践并提供合理的费率。
The Internet today consists of a global public IPv4 routing and addressing system with non-IRON EUNs that use either public or private IPv4 addressing. The latter class of EUNs connect to the public Internet via Network Address Translators (NATs). When a Client is located behind a NAT, it selects Servers using the same procedures as for Clients with public addresses, e.g., it can send SRS messages to Servers in order to get SRA messages in return. The only requirement is that the Client must configure its SEAL encapsulation to use a transport protocol that supports NAT traversal, namely UDP.
今天的互联网由一个全球公共IPv4路由和寻址系统组成，该系统具有使用公共或私有IPv4寻址的非铁EUN。后一类EUN通过网络地址转换器（NAT）连接到公共互联网。当客户机位于NAT后面时，它使用与具有公共地址的客户机相同的过程选择服务器，例如，它可以向服务器发送SRS消息，以获得SRA消息作为回报。唯一的要求是客户端必须配置其密封封装，以使用支持NAT遍历的传输协议，即UDP。
Since the Server maintains state about its Client customers, it can discover locator information for each Client by examining the UDP port number and IP address in the outer headers of the Client's encapsulated packets. When there is a NAT in the path, the UDP port number and IP address in each encapsulated packet will correspond to state in the NAT box and might not correspond to the actual values assigned to the Client. The Server can then encapsulate packets destined to hosts in the Client's EUN within outer headers that use this IP address and UDP port number. The NAT box will receive the packets, translate the values in the outer headers, then forward the packets to the Client. In this sense, the Server's "locator" for the Client consists of the concatenation of the IP address and UDP port number.
由于服务器维护其客户机的状态，因此它可以通过检查客户机封装数据包的外部报头中的UDP端口号和IP地址来发现每个客户机的定位器信息。当路径中存在NAT时，每个封装数据包中的UDP端口号和IP地址将对应于NAT框中的状态，并且可能不对应于分配给客户端的实际值。然后，服务器可以在使用此IP地址和UDP端口号的外部报头中封装发送到客户端EUN中主机的数据包。NAT框将接收数据包，转换外部报头中的值，然后将数据包转发给客户端。从这个意义上讲，服务器的客户端“定位器”由IP地址和UDP端口号的串联组成。
IRON does not introduce any new issues to complications raised for NAT traversal or for applications embedding address referrals in their payload.
IRON不会给NAT遍历或在有效负载中嵌入地址引用的应用程序带来任何新问题。
IRON Servers and Relays are topologically positioned to provide Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD) proxying for their Clients [RFC4605]. Further multicast considerations for IRON (e.g., interactions with multicast routing protocols, traffic scaling, etc.) will be discussed in a separate document.
IRON服务器和中继在拓扑上定位为为其客户端提供Internet组管理协议（IGMP）/多播侦听器发现（MLD）代理[RFC4605]。IRON的进一步多播注意事项（例如，与多播路由协议的交互、流量缩放等）将在单独的文档中讨论。
Each Client configures a locator that may be taken from an ordinary non-EPA address assigned by an ISP or from an EPA address taken from an EP assigned to another Client. In that case, the Client is said to be "nested" within the EUN of another Client, and recursive nestings of multiple layers of encapsulations may be necessary.
每个客户端配置一个定位器，该定位器可以取自ISP分配的普通非EPA地址，也可以取自分配给另一个客户端的EP地址。在这种情况下，客户机被称为“嵌套”在另一个客户机的EUN中，并且可能需要多层封装的递归嵌套。
For example, in the network scenario depicted in Figure 10, Client(A) configures a locator EPA(B) taken from the EP assigned to EUN(B). Client(B) in turn configures a locator EPA(C) taken from the EP assigned to EUN(C). Finally, Client(C) configures a locator ISP(D) taken from a non-EPA address delegated by an ordinary ISP(D). Using this example, the "nested-IRON" case must be examined in which a host A, which configures the address EPA(A) within EUN(A), exchanges packets with host Z located elsewhere in the Internet.
例如，在图10所示的网络场景中，客户端（A）配置一个定位器EPA（B），该定位器取自分配给EUN（B）的EP。客户端（B）依次配置从分配给EUN（C）的EP获取的定位器EPA（C）。最后，客户端（C）配置从普通ISP（D）委托的非EPA地址获取的定位器ISP（D）。使用此示例，必须检查“嵌套铁”情况，其中配置EUN（a）内地址EPA（a）的主机a与位于Internet其他位置的主机Z交换数据包。
.-.
ISP(D) ,-( _)-.
+-----------+ .-(_ (_ )-.
| Client(C) |--(_ ISP(D) )
+-----+-----+ `-(______)-'
| <= T \ .-.
.-. u \ ,-( _)-.
,-( _)-. n .-(_ (- )-.
.-(_ (_ )-. n (_ Internet )
(_ EUN(C) ) e `-(______)-'
`-(______)-' l ___
| EPA(C) s => (:::)-.
+-----+-----+ .-(::::::::)
| Client(B) | .-(::::::::::::)-. +-----------+
+-----+-----+ (:::: The IRON ::::) | Relay(Z) |
| `-(::::::::::::)-' +-----------+
.-. `-(::::::)-' +-----------+
,-( _)-. | Server(Z) |
.-(_ (_ )-. +-----------+ +-----------+
(_ EUN(B) ) | Server(C) | +-----------+
`-(______)-' +-----------+ | Client(Z) |
| EPA(B) +-----------+ +-----------+
+-----+-----+ | Server(B) | +--------+
| Client(A) | +-----------+ | Host Z |
+-----------+ +-----------+ +--------+
| | Server(A) |
.-. +-----------+
,-( _)-. EPA(A)
.-(_ (_ )-. +--------+
(_ EUN(A) )---| Host A |
`-(______)-' +--------+
.-.
ISP(D) ,-( _)-.
+-----------+ .-(_ (_ )-.
| Client(C) |--(_ ISP(D) )
+-----+-----+ `-(______)-'
| <= T \ .-.
.-. u \ ,-( _)-.
,-( _)-. n .-(_ (- )-.
.-(_ (_ )-. n (_ Internet )
(_ EUN(C) ) e `-(______)-'
`-(______)-' l ___
| EPA(C) s => (:::)-.
+-----+-----+ .-(::::::::)
| Client(B) | .-(::::::::::::)-. +-----------+
+-----+-----+ (:::: The IRON ::::) | Relay(Z) |
| `-(::::::::::::)-' +-----------+
.-. `-(::::::)-' +-----------+
,-( _)-. | Server(Z) |
.-(_ (_ )-. +-----------+ +-----------+
(_ EUN(B) ) | Server(C) | +-----------+
`-(______)-' +-----------+ | Client(Z) |
| EPA(B) +-----------+ +-----------+
+-----+-----+ | Server(B) | +--------+
| Client(A) | +-----------+ | Host Z |
+-----------+ +-----------+ +--------+
| | Server(A) |
.-. +-----------+
,-( _)-. EPA(A)
.-(_ (_ )-. +--------+
(_ EUN(A) )---| Host A |
`-(______)-' +--------+
Figure 10: Nested EUN Example
图10：嵌套的EUN示例
The two cases of host A sending packets to host Z, and host Z sending packets to host A, must be considered separately, as described below.
必须分别考虑主机A向主机Z发送数据包和主机Z向主机A发送数据包的两种情况，如下所述。
Host A first forwards a packet with source address EPA(A) and destination address Z into EUN(A). Routing within EUN(A) will direct the packet to Client(A), which encapsulates it in an outer header with EPA(B) as the outer source address and Server(A) as the outer destination address then forwards the once-encapsulated packet into EUN(B). Routing within EUN(B) will direct the packet to Client(B), which encapsulates it in an outer header with EPA(C) as the outer source address and Server(B) as the outer destination address then forwards the twice-encapsulated packet into EUN(C). Routing within EUN(C) will direct the packet to Client(C), which encapsulates it in an outer header with ISP(D) as the outer source address and Server(C) as the outer destination address. Client(C) then sends this triple-encapsulated packet into the ISP(D) network, where it will be routed into the Internet to Server(C).
主机A首先将具有源地址EPA（A）和目的地址Z的数据包转发到EUN（A）中。EUN（A）内的路由将数据包定向到客户端（A），客户端（A）将数据包封装在外部报头中，EPA（B）作为外部源地址，服务器（A）作为外部目标地址，然后将封装后的数据包转发到EUN（B）中。EUN（B）内的路由将数据包定向到客户端（B），客户端（B）将数据包封装在外部报头中，EPA（C）作为外部源地址，服务器（B）作为外部目标地址，然后将两次封装的数据包转发到EUN（C）中。EUN（C）内的路由将数据包定向到客户端（C），客户端（C）将数据包封装在外部报头中，ISP（D）作为外部源地址，服务器（C）作为外部目标地址。然后，客户机（C）将这个三重封装的数据包发送到ISP（D）网络，在那里它将被路由到Internet到服务器（C）。
When Server(C) receives the triple-encapsulated packet, it removes the outer layer of encapsulation and forwards the resulting twice-encapsulated packet into the Internet to Server(B). Next, Server(B) removes the outer layer of encapsulation and forwards the resulting once-encapsulated packet into the Internet to Server(A). Next, Server(A) checks the address type of the inner address 'Z'. If Z is a non-EPA address, Server(A) simply decapsulates the packet and forwards it into the Internet. Otherwise, Server(A) rewrites the outer source and destination addresses of the once-encapsulated packet and forwards it to Relay(Z). Relay(Z), in turn, rewrites the outer destination address of the packet to the locator for Server(Z), then forwards the packet and sends a redirect to Server(A) (which forwards the redirect to Client(A)). Server(Z) then re-encapsulates the packet and forwards it to Client(Z), which decapsulates it and forwards the inner packet to host Z. Subsequent packets from Client(A) will then use Server(Z) as the next hop toward host Z, which eliminates Server(A) and Relay(Z) from the path.
当服务器（C）接收到三重封装的数据包时，它会移除外层封装，并将得到的两次封装的数据包转发到互联网上的服务器（B）。接下来，服务器（B）移除封装的外层，并将得到的封装后的数据包转发到互联网上的服务器（A）。接下来，服务器（A）检查内部地址“Z”的地址类型。如果Z是一个非EPA地址，服务器（a）只需解除数据包的封装并将其转发到Internet。否则，服务器（A）重写封装后的数据包的外部源地址和目的地址，并将其转发给中继（Z）。中继（Z）反过来将数据包的外部目的地地址重写到服务器（Z）的定位器，然后转发数据包并向服务器（a）发送重定向（后者将重定向转发到客户端（a））。然后，服务器（Z）重新封装数据包并将其转发给客户端（Z），客户端（Z）将其解封并将内部数据包转发给主机Z。来自客户端（A）的后续数据包随后将使用服务器（Z）作为到主机Z的下一跳，从而从路径中消除服务器（A）和中继（Z）。
Whether or not host Z configures an EPA address, its packets destined to host A will eventually reach Server(A). Server(A) will have a mapping that lists Client(A) as the next hop toward EPA(A). Server(A) will then encapsulate the packet with EPA(B) as the outer destination address and forward the packet into the Internet. Internet routing will convey this once-encapsulated packet to Server(B), which will have a mapping that lists Client(B) as the next hop toward EPA(B). Server(B) will then encapsulate the packet with EPA(C) as the outer destination address and forward the packet into the Internet. Internet routing will then convey this twice-encapsulated packet to Server(C), which will have a mapping that
无论主机Z是否配置EPA地址，其目的地为主机A的数据包最终将到达服务器（A）。服务器（A）将有一个映射，该映射将客户端（A）列为通向EPA（A）的下一个跃点。然后，服务器（A）将用EPA（B）作为外部目标地址封装数据包，并将数据包转发到Internet。Internet路由将把这个曾经封装的数据包传送到服务器（B），服务器（B）将有一个映射，该映射将客户机（B）列为通向EPA（B）的下一跳。然后，服务器（B）将用EPA（C）作为外部目标地址封装数据包，并将数据包转发到Internet。然后，Internet路由将这个两次封装的数据包传送到服务器（C），服务器（C）将有一个
lists Client(C) as the next hop toward EPA(C). Server(C) will then encapsulate the packet with ISP(D) as the outer destination address and forward the packet into the Internet. Internet routing will then convey this triple-encapsulated packet to Client(C).
将客户机（C）列为通向EPA（C）的下一个跃点。然后，服务器（C）将使用ISP（D）作为外部目标地址封装数据包，并将数据包转发到Internet。然后，Internet路由将这个三重封装的数据包传送到客户端（C）。
When the triple-encapsulated packet arrives at Client(C), it strips the outer layer of encapsulation and forwards the twice-encapsulated packet to EPA(C), which is the locator address of Client(B). When Client(B) receives the twice-encapsulated packet, it strips the outer layer of encapsulation and forwards the once-encapsulated packet to EPA(B), which is the locator address of Client(A). When Client(A) receives the once-encapsulated packet, it strips the outer layer of encapsulation and forwards the unencapsulated packet to EPA(A), which is the host address of host A.
当三次封装的数据包到达客户端（C）时，它剥离封装的外层，并将两次封装的数据包转发给EPA（C），EPA（C）是客户端（B）的定位地址。当客户端（B）接收到两次封装的数据包时，它剥离封装的外层并将一次封装的数据包转发给EPA（B），EPA（B）是客户端（A）的定位地址。当客户端（A）接收到一次封装的数据包时，它剥离封装的外层，并将未封装的数据包转发给EPA（A），EPA是主机A的主机地址。
The IRON architecture envisions a hybrid routing/mapping system that benefits from both the shortest-path routing afforded by pure dynamic routing systems and the routing-scaling suppression afforded by pure mapping systems. Therefore, IRON targets the elusive "sweet spot" that pure routing and pure mapping systems alone cannot satisfy.
IRON架构设想了一个混合路由/映射系统，它既受益于纯动态路由系统提供的最短路径路由，也受益于纯映射系统提供的路由缩放抑制。因此，IRON瞄准了一个难以捉摸的“最佳点”，这是纯路由和纯映射系统无法单独满足的。
The IRON system requires a deployment of new routers/servers throughout the Internet and/or provider networks to maintain well-balanced virtual overlay networks. These routers/servers can be deployed incrementally without disruption to existing Internet infrastructure and appropriately managed to provide acceptable service levels to customers.
IRON系统需要在整个互联网和/或提供商网络中部署新的路由器/服务器，以维持良好平衡的虚拟覆盖网络。这些路由器/服务器可以在不中断现有互联网基础设施的情况下进行增量部署，并进行适当管理，为客户提供可接受的服务级别。
End-to-end traffic that traverses an IRON virtual overlay network may experience delay variance between the initial packets and subsequent packets of a flow. This is due to the IRON system allowing a longer path stretch for initial packets followed by timely route optimizations to utilize better next hop routers/servers for subsequent packets.
穿越IRON虚拟覆盖网络的端到端流量可能在流的初始分组和后续分组之间经历延迟变化。这是由于IRON系统允许对初始数据包进行更长的路径拉伸，然后及时进行路由优化，以便为后续数据包利用更好的下一跳路由器/服务器。
IRON virtual overlay networks also work seamlessly with existing and emerging services within the native Internet. In particular, customers serviced by IRON virtual overlay networks will receive the same service enjoyed by customers serviced by non-IRON service providers. Internet services already deployed within the native Internet also need not make any changes to accommodate IRON virtual overlay network customers.
IRON虚拟覆盖网络还可以与本机Internet中的现有和新兴服务无缝协作。特别是，由IRON虚拟覆盖网络服务的客户将获得与非IRON服务提供商服务的客户相同的服务。已经部署在本机Internet中的Internet服务也不需要进行任何更改以适应IRON虚拟覆盖网络客户。
The IRON system operates between routers within provider networks and end user networks. Within these networks, the underlying paths traversed by the virtual overlay networks may comprise links that
IRON系统在提供商网络和最终用户网络内的路由器之间运行。在这些网络内，虚拟覆盖网络所穿越的底层路径可以包括以下链路：
accommodate varying MTUs. While the IRON system imposes an additional per-packet overhead that may cause the size of packets to become slightly larger than the underlying path can accommodate, IRON routers have a method for naturally detecting and tuning out all instances of path MTU underruns. In some cases, these MTU underruns may need to be reported back to the original hosts; however, the system will also allow for MTUs much larger than those typically available in current Internet paths to be discovered and utilized as more links with larger MTUs are deployed.
适应不同的MTU。虽然IRON系统施加了额外的每个数据包开销，这可能导致数据包的大小略大于基础路径所能容纳的大小，但IRON路由器有一种方法可以自然地检测和调谐路径MTU欠载的所有实例。在某些情况下，可能需要将这些MTU欠载报告回原始主机；然而，随着部署更多具有更大MTU的链路，该系统还允许发现和利用比当前Internet路径中通常可用的MTU大得多的MTU。
Finally, and perhaps most importantly, the IRON system provides an in-built mobility management and multihoming capability that allows end user devices and networks to move about freely while both imparting minimal oscillations in the routing system and maintaining generally shortest-path routes. This mobility management is afforded through the very nature of the IRON customer/provider relationship, and therefore requires no adjunct mechanisms. The mobility management and multihoming capabilities are further supported by forward-path reachability detection that provides "hints of forward progress" in the same spirit as for IPv6 Neighbor Discovery (ND).
最后，也许是最重要的一点，IRON系统提供了内置的移动性管理和多主功能，允许最终用户设备和网络自由移动，同时使路由系统中的振荡最小，并保持通常最短的路径。这种移动性管理是通过铁客户/提供商关系的本质提供的，因此不需要附加机制。前向路径可达性检测进一步支持移动性管理和多主功能，该检测与IPv6邻居发现（ND）的精神相同，提供“前向进度提示”。
Considerations for the scalability of Internet Routing due to multihoming, traffic engineering, and provider-independent addressing are discussed in [RADIR]. Other scaling considerations specific to IRON are discussed in Appendix B.
[RADIR]中讨论了由于多宿、流量工程和独立于提供商的寻址而导致的互联网路由可扩展性的考虑因素。附录B中讨论了铁特有的其他结垢因素。
Route optimization considerations for mobile networks are found in [RFC5522].
移动网络的路由优化注意事项见[RFC5522]。
IRON builds upon the concepts of the RANGER architecture [RFC5720] [RFC6139], and therefore inherits the same set of related initiatives. The Internet Research Task Force (IRTF) Routing Research Group (RRG) mentions IRON in its recommendation for a routing architecture [RFC6115].
IRON以RANGER架构[RFC5720][RFC6139]的概念为基础，因此继承了相同的一组相关计划。互联网研究任务组（IRTF）路由研究小组（RRG）在其关于路由架构的建议[RFC6115]中提到了IRON。
Virtual Aggregation (VA) [GROW-VA] and Aggregation in Increasing Scopes (AIS) [EVOLUTION] provide the basis for the Virtual Prefix concepts.
虚拟聚合（VA）[GROW-VA]和递增范围聚合（AI）[进化]为虚拟前缀概念提供了基础。
Internet Vastly Improved Plumbing (Ivip) [IVIP-ARCH] has contributed valuable insights, including the use of real-time mapping. The use of Servers as mobility anchor points is directly influenced by Ivip's associated TTR mobility extensions [TTRMOB].
互联网极大改善管道（Ivip）[Ivip-ARCH]提供了宝贵的见解，包括实时地图的使用。将服务器用作移动性锚点直接受到Ivip相关TTR移动性扩展[TTRMOB]的影响。
[RO-CR] discusses a route optimization approach using a Correspondent Router (CR) model. The IRON Server construct is similar to the CR concept described in this work; however, the manner in which customer EUNs coordinate with Servers is different and based on the redirection model associated with NBMA links.
[RO-CR]讨论了一种使用相应路由器（CR）模型的路由优化方法。IRON服务器结构类似于本工作中描述的CR概念；然而，客户EUN与服务器协调的方式不同，并且基于与NBMA链路相关联的重定向模型。
Numerous publications have proposed NAT traversal techniques. The NAT traversal techniques adapted for IRON were inspired by the Simple Address Mapping for Premises Legacy Equipment (SAMPLE) proposal [SAMPLE].
许多出版物都提出了NAT穿越技术。适用于IRON的NAT穿越技术的灵感来自于房屋遗留设备的简单地址映射（示例）提案[示例]。
Security considerations that apply to tunneling in general are discussed in [V6OPS-TUN-SEC]. Additional considerations that apply also to IRON are discussed in RANGER [RFC5720] [RFC6139], VET [INTAREA-VET] and SEAL [INTAREA-SEAL].
[V6OPS-TUN-SEC]中讨论了一般适用于隧道的安全注意事项。RANGER[RFC5720][RFC6139]、VET[INTAREA-VET]和SEAL[INTAREA-SEAL]中讨论了同样适用于铁的其他注意事项。
The IRON system further depends on mutual authentication of IRON Clients to Servers and Servers to Relays. This is accomplished through initial authentication exchanges followed by tunnel-neighbor nonces that can be used to detect off-path attacks. As for all Internet communications, the IRON system also depends on Relays acting with integrity and not injecting false advertisements into the BGP (e.g., to mount traffic siphoning attacks).
IRON系统进一步依赖于IRON客户端到服务器和服务器到中继的相互认证。这是通过初始身份验证交换完成的，然后是可用于检测非路径攻击的隧道邻居nonce。对于所有的互联网通信，IRON系统还依赖于继电器的完整性，不向BGP中注入虚假广告（例如，发起流量虹吸攻击）。
Each VPC overlay network requires a means for assuring the integrity of the interior routing system so that all Relays and Servers in the overlay have a consistent view of Client<->Server bindings. Finally, Denial-of-Service (DoS) attacks on IRON Relays and Servers can occur when packets with spoofed source addresses arrive at high data rates. However, this issue is no different than for any border router in the public Internet today.
每个VPC覆盖网络都需要一种确保内部路由系统完整性的方法，以便覆盖中的所有中继和服务器都具有客户端<->服务器绑定的一致视图。最后，当具有伪造源地址的数据包以高数据速率到达时，铁继电器和服务器上可能会发生拒绝服务（DoS）攻击。然而，这个问题与当今公共互联网上的任何边界路由器没有什么不同。
The ideas behind this work have benefited greatly from discussions with colleagues; some of which appear on the RRG and other IRTF/IETF mailing lists. Robin Whittle and Steve Russert co-authored the TTR mobility architecture, which strongly influenced IRON. Eric Fleischman pointed out the opportunity to leverage anycast for discovering topologically close Servers. Thomas Henderson recommended a quantitative analysis of scaling properties.
这项工作背后的想法从与同事的讨论中受益匪浅；其中一些出现在RRG和其他IRTF/IETF邮件列表上。罗宾·惠特尔（Robin Whittle）和史蒂夫·拉塞特（Steve Russert）合著了TTR移动性架构，该架构对IRON产生了重大影响。Eric Fleischman指出了利用anycast发现拓扑上紧密的服务器的机会。Thomas Henderson建议对标度特性进行定量分析。
The following individuals provided essential review input: Jari Arkko, Mohamed Boucadair, Stewart Bryant, John Buford, Ralph Droms, Wesley Eddy, Adrian Farrel, Dae Young Kim, and Robin Whittle.
以下个人提供了重要的审查意见：贾里·阿尔科、穆罕默德·布卡代尔、斯图尔特·布莱恩特、约翰·布福德、拉尔夫·德罗姆斯、韦斯利·艾迪、阿德里安·法雷尔、戴扬·金和罗宾·惠特尔。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[BGPMON] net, B., "BGPmon.net - Monitoring Your Prefixes, http://bgpmon.net/stat.php", June 2010.
[BGPMON]net，B.，“BGPMON.net-监视您的前缀，http://bgpmon.net/stat.php“，2010年6月。
[EVOLUTION] Zhang, B., Zhang, L., and L. Wang, "Evolution Towards Global Routing Scalability", Work in Progress, October 2009.
[EVOLUTION]Zhang，B.，Zhang，L.，and L.Wang，“朝向全球路由可扩展性的进化”，正在进行的工作，2009年10月。
[GROW-VA] Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and L. Zhang, "FIB Suppression with Virtual Aggregation", Work in Progress, February 2011.
[GROW-VA]Francis，P.，Xu，X.，Ballani，H.，Jen，D.，Raszuk，R.，和L.Zhang，“FIB抑制与虚拟聚集”，正在进行的工作，2011年2月。
[INTAREA-SEAL] Templin, F., Ed., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", Work in Progress, February 2011.
[Intrea-SEAL]Templin，F.，Ed.“子网络封装和适配层（SEAL）”，正在进行的工作，2011年2月。
[INTAREA-VET] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", Work in Progress, January 2011.
[Intrea-VET]Templin，F.，编辑，“虚拟企业遍历（VET）”，正在进行的工作，2011年1月。
[IVIP-ARCH] Whittle, R., "Ivip (Internet Vastly Improved Plumbing) Architecture", Work in Progress, March 2010.
[IVIP-ARCH]Whittle，R.，“IVIP（互联网极大改进的管道）架构”，正在进行的工作，2010年3月。
[RADIR] Narten, T., "On the Scalability of Internet Routing", Work in Progress, February 2010.
[RADIR]Narten，T.，“互联网路由的可扩展性”，正在进行的工作，2010年2月。
[RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as a subnetwork for experimentation with the OSI network layer", RFC 1070, February 1989.
[RFC1070]Hagens，R.，Hall，N.，和M.Rose，“将互联网用作OSI网络层实验的子网”，RFC 1070，1989年2月。
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[RFC2526]Johnson，D.和S.Deering，“保留的IPv6子网选播地址”，RFC 25261999年3月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068]Huitema，C.，“6to4中继路由器的选播前缀”，RFC3068，2001年6月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]Baker，F.，Lear，E.，和R.Droms，“在没有国旗日的情况下对IPv6网络重新编号的程序”，RFC 41922005年9月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code Point (ICP) Assignments for NSAP Addresses", RFC 4548, May 2006.
[RFC4548]Gray，E.，Rutemiller，J.和G.Swallow，“NSAP地址的互联网代码点（ICP）分配”，RFC 4548，2006年5月。
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4605]Fenner，B.，He，H.，Haberman，B.，和H.Sandick，“基于Internet组管理协议（IGMP）/多播侦听器发现（MLD）的多播转发（“IGMP/MLD代理”）”，RFC 4605，2006年8月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214]Templin，F.，Gleeson，T.，和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，RFC 52142008年3月。
[RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks", RFC 5522, October 2009.
[RFC5522]Eddy，W.，Ivancic，W.，和T.Davis，“航空和空间探索移动网络中运行使用的网络移动路径优化要求”，RFC 5522，2009年10月。
[RFC5720] Templin, F., "Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)", RFC 5720, February 2010.
[RFC5720]Templin，F.“具有全局企业递归（RANGER）的网络中的路由和寻址”，RFC 5720，2010年2月。
[RFC5743] Falk, A., "Definition of an Internet Research Task Force (IRTF) Document Stream", RFC 5743, December 2009.
[RFC5743]Falk，A.“互联网研究工作队（IRTF）文件流的定义”，RFC 57432009年12月。
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010.
[RFC5887]Carpenter，B.，Atkinson，R.，和H.Flinck，“重新编号仍然需要工作”，RFC 5887，2010年5月。
[RFC6115] Li, T., "Recommendation for a Routing Architecture", RFC 6115, February 2011.
[RFC6115]Li，T.，“路由架构的建议”，RFC61152011年2月。
[RFC6139] Russert, S., Fleischman, E., and F. Templin, "Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios", RFC 6139, February 2011.
[RFC6139]Russert，S.，Fleischman，E.，和F.Templin，“具有全局企业递归（RANGER）场景的网络中的路由和寻址”，RFC 6139，2011年2月。
[RO-CR] Bernardos, C., Calderon, M., and I. Soto, "Correspondent Router based Route Optimisation for NEMO (CRON)", Work in Progress, July 2008.
[RO-CR]Bernardos，C.，Calderon，M.，和I.Soto，“NEMO（CRON）基于代理路由器的路由优化”，正在进行的工作，2008年7月。
[SAMPLE] Carpenter, B. and S. Jiang, "Legacy NAT Traversal for IPv6: Simple Address Mapping for Premises Legacy Equipment (SAMPLE)", Work in Progress, June 2010.
[样本]Carpenter，B.和S.Jiang，“IPv6遗留NAT遍历：房屋遗留设备的简单地址映射（样本）”，正在进行的工作，2010年6月。
[TTRMOB] Whittle, R. and S. Russert, "TTR Mobility Extensions for Core-Edge Separation Solutions to the Internet's Routing Scaling Problem, http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf", August 2008.
[TTRMOB]Whittle，R.和S.Russert，“互联网路由扩展问题核心边缘分离解决方案的TTR移动性扩展，http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf“，2008年8月。
[V6OPS-TUN-SEC] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns With IP Tunneling", Work in Progress, October 2010.
[V6OPS-TUN-SEC]Krishnan，S.，Thaler，D.，和J.Hoagland，“IP隧道的安全问题”，正在进行的工作，2010年10月。
The IRON architecture leverages the routing system by providing generally shortest-path routing for packets with EPA addresses from VPs that match the address family of the underlying Internetwork. When the VPs are of an address family that is not routable within the underlying Internetwork, however, (e.g., when OSI/NSAP [RFC4548] VPs are used within an IPv4 Internetwork) a global mapping database is required to allow Servers to map VPs to companion prefixes taken from address families that are routable within the Internetwork. For example, an IPv6 VP (e.g., 2001:DB8::/32) could be paired with a companion IPv4 prefix (e.g., 192.0.2.0/24) so that encapsulated IPv6 packets can be forwarded over IPv4-only Internetworks.
IRON体系结构利用了路由系统，为来自VP的EPA地址与基础互联网的地址系列相匹配的数据包提供一般最短路径路由。然而，当VP属于不可在基础互联网内路由的地址族时（例如，当在IPv4互联网内使用OSI/NSAP[RFC4548]VP时），需要一个全局映射数据库，以允许服务器将VP映射到从可在互联网内路由的地址族中获取的伴随前缀。例如，IPv6 VP（例如，2001:DB8:：/32）可以与伴随的IPv4前缀（例如，192.0.2.0/24）配对，以便封装的IPv6数据包可以通过仅IPv4的互联网转发。
Every VP in the IRON must therefore be represented in a globally distributed Master VP database (MVPd) that maintains VP-to-companion prefix mappings for all VPs in the IRON. The MVPd is maintained by a globally managed assigned numbers authority in the same manner as the Internet Assigned Numbers Authority (IANA) currently maintains the master list of all top-level IPv4 and IPv6 delegations. The database can be replicated across multiple servers for load balancing, much in the same way that FTP mirror sites are used to manage software distributions.
因此，IRON中的每个VP都必须在全局分布的主VP数据库（MVPd）中表示，该数据库为IRON中的所有VP维护VP到伴随前缀的映射。MVPd由全球管理的分配号码管理机构维护，维护方式与Internet分配号码管理机构（IANA）当前维护所有顶级IPv4和IPv6授权的主列表相同。数据库可以跨多台服务器复制以实现负载平衡，这与FTP镜像站点用于管理软件分发的方式非常相似。
Upon startup, each Server discovers the full set of VPs for the IRON by reading the MVPd. The Server reads the MVPd from a nearby server and periodically checks the server for deltas since the database was last read. After reading the MVPd, the Server has a full list of VP-to-companion prefix mappings.
启动时，每个服务器通过读取MVPd来发现熨斗的全套VP。服务器从附近的服务器读取MVPd，并在上次读取数据库后定期检查服务器的增量。在读取MVPd之后，服务器有一个VP到伴随前缀映射的完整列表。
The Server can then forward packets toward EPAs covered by a VP by encapsulating them in an outer header of the VP's companion prefix address family and using any address taken from the companion prefix as the outer destination address. The companion prefix therefore serves as an anycast prefix.
然后，服务器可以通过将数据包封装在VP的伴随前缀地址系列的外部标头中，并使用从伴随前缀获取的任何地址作为外部目标地址，将数据包转发到VP覆盖的EPA。因此，伴随前缀用作选播前缀。
Possible encapsulations in this model include IPv6-in-IPv4, IPv4-in-IPv6, OSI/CLNP-in-IPv6, OSI/CLNP-in-IPv4, etc.
该模型中可能的封装包括IPv4-in-IPv4、IPv4-in-IPv6、OSI/CLNP-in-IPv6、OSI/CLNP-in-IPv4等。
Scaling aspects of the IRON architecture have strong implications for its applicability in practical deployments. Scaling must be considered along multiple vectors, including Interdomain core routing scaling, scaling to accommodate large numbers of customer EUNs, traffic scaling, state requirements, etc.
IRON体系结构的可伸缩性对其在实际部署中的适用性有很大影响。必须沿多个向量考虑扩展，包括域间核心路由扩展、适应大量客户EUN的扩展、流量扩展、状态要求等。
In terms of routing scaling, each VPC will advertise one or more VPs into the global Internet routing system from which EPs are delegated to customer EUNs. Routing scaling will therefore be minimized when each VP covers many EPs. For example, the IPv6 prefix 2001:DB8::/32 contains 2^24 ::/56 EP prefixes for assignment to EUNs; therefore, the IRON could accommodate 2^32 ::/56 EPs with only 2^8 ::/32 VPs advertised in the interdomain routing core. (When even longer EP prefixes are used, e.g., /64s assigned to individual handsets in a cellular provider network, considerable numbers of EUNs can be represented within only a single VP.) Each VP also has an associated anycast companion prefix; hence, there will be one anycast prefix advertised into the global routing system for each VP.
在路由扩展方面，每个VPC将向全球互联网路由系统发布一个或多个VP，EPs从该系统委托给客户EUN。因此，当每个VP覆盖多个EP时，路由扩展将最小化。例如，IPv6前缀2001:DB8:：/32包含2^24:：/56 EP前缀，用于分配给EUN；因此，IRON可以容纳2^32:：/56个EP，而在域间路由核心中仅播发2^8:：/32个VP。（当使用更长的EP前缀时，例如，分配给蜂窝提供商网络中的单个手机的/64s，相当数量的EUN可以仅在单个VP中表示。）每个VP还具有相关联的选播伴随前缀；因此，对于每个VP，将有一个选播前缀播发到全局路由系统中。
In terms of traffic scaling for Relays, each Relay represents an ASBR of a "shell" enterprise network that simply directs arriving traffic packets with EPA destination addresses towards Servers that service customer EUNs. Moreover, the Relay sheds traffic destined to EPAs through redirection, which removes it from the path for the vast majority of traffic packets. On the other hand, each Relay must handle all traffic packets forwarded between its customer EUNs and the non-IRON Internet. The scaling concerns for this latter class of traffic are no different than for ASBR routers that connect large enterprise networks to the Internet. In terms of traffic scaling for Servers, each Server services a set of the VPC overlay network's customer EUNs. The Server services all traffic packets destined to its EUNs but only services the initial packets of flows initiated from the EUNs and destined to EPAs. Therefore, traffic scaling for EPA-addressed traffic is an asymmetric consideration and is proportional to the number of EUNs each Server serves.
就中继器的流量缩放而言，每个中继器代表“外壳”企业网络的ASBR，该企业网络简单地将到达的带有EPA目的地地址的流量包定向到为客户EUN服务的服务器。此外，中继通过重定向发送到EPA的流量，从而将其从绝大多数流量数据包的路径中移除。另一方面，每个中继必须处理其客户EUN和非铁互联网之间转发的所有流量数据包。后一类流量的扩展问题与将大型企业网络连接到Internet的ASBR路由器没有什么不同。就服务器的流量扩展而言，每台服务器都为一组VPC覆盖网络的客户EUN提供服务。服务器为所有发送到其EUN的流量数据包提供服务，但仅为从EUN启动并发送到EPA的初始流量数据包提供服务。因此，EPA寻址流量的流量缩放是一个不对称的考虑因素，并且与每个服务器服务的EUN数量成正比。
In terms of state requirements for Relays, each Relay maintains a list of all Servers in the VPC overlay network as well as FIB entries for all customer EUNs that each Server serves. This state is therefore dominated by the number of EUNs in the VPC overlay network. Sizing the Relay to accommodate state information for all EUNs is therefore required during VPC overlay network planning. In terms of state requirements for Servers, each Server maintains tunnel-neighbor state for each of the customer EUNs it serves, but it need not keep
就中继的状态要求而言，每个中继维护VPC覆盖网络中所有服务器的列表，以及每个服务器所服务的所有客户EUN的FIB条目。因此，这种状态主要取决于VPC覆盖网络中的EUN数量。因此，在VPC覆盖网络规划期间，需要调整中继的大小以适应所有EUN的状态信息。就服务器的状态要求而言，每个服务器都为其服务的每个客户EUN维护隧道邻居状态，但不需要保留
state for all EUNs in the VPC overlay network. Finally, neither Relays nor Servers need keep state for final destinations of outbound traffic.
VPC覆盖网络中所有EUN的状态。最后，对于出站流量的最终目的地，中继和服务器都不需要保持状态。
Clients source and sink all traffic packets originating from or destined to the customer EUN. Therefore, traffic scaling considerations for Clients are the same as for any site border router. Clients also retain state for the Servers for final destinations of outbound traffic flows. This can be managed as soft state, since stale entries purged from the cache will be refreshed when new traffic packets are sent.
客户机发送和接收来自客户EUN或目的地为客户EUN的所有流量数据包。因此，客户机的流量扩展考虑与任何站点边界路由器相同。客户端还为出站流量的最终目的地保留服务器的状态。这可以作为软状态进行管理，因为当发送新的流量数据包时，将刷新从缓存中清除的过时条目。
Author's Address
作者地址
Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA
Fred L.Templin（编辑）美国华盛顿州西雅图波音研究与技术公司邮政信箱3707 MC 7L-49 98124
EMail: fltemplin@acm.org
EMail: fltemplin@acm.org