Network Working Group J. Wu
Request for Comments: 5565 Y. Cui
Category: Standards Track Tsinghua University
C. Metz
E. Rosen
Cisco Systems, Inc.
June 2009
Network Working Group J. Wu
Request for Comments: 5565 Y. Cui
Category: Standards Track Tsinghua University
C. Metz
E. Rosen
Cisco Systems, Inc.
June 2009
Softwire Mesh Framework
软线网骨架
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). 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). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
The Internet needs to be able to handle both IPv4 and IPv6 packets. However, it is expected that some constituent networks of the Internet will be "single-protocol" networks. One kind of single-protocol network can parse only IPv4 packets and can process only IPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information. It is nevertheless required that either kind of single-protocol network be able to provide transit service for the "other" protocol. This is done by passing the "other kind" of routing information from one edge of the single-protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other. The tunnels are known as "softwires". This framework document explains how the routing information and the data packets of one protocol are passed through a single-protocol network of the other protocol. The document is careful to specify when this can be done with existing technology and when it requires the development of new or modified technology.
互联网需要能够处理IPv4和IPv6数据包。然而，预计因特网的一些组成网络将是“单一协议”网络。一种单协议网络只能解析IPv4数据包，只能处理IPv4路由信息；另一种只能解析IPv6数据包，只能处理IPv6路由信息。然而，要求任何一种单协议网络都能够为“其他”协议提供传输服务。这是通过将“其他种类”的路由信息从单协议网络的一个边缘传递到另一个边缘，并通过隧道将“其他种类”的数据分组从一个边缘传递到另一个边缘来实现的。这些隧道被称为“软电线”。本框架文档解释了一个协议的路由信息和数据包如何通过另一个协议的单个协议网络传递。本文件仔细说明了何时可以利用现有技术实现这一点，何时需要开发新的或改进的技术。
Table of Contents
目录
1. Introduction ....................................................3
2. Specification of Requirements ...................................6
3. Scenarios of Interest ...........................................7
3.1. IPv6-over-IPv4 Scenario ....................................7
3.2. IPv4-over-IPv6 Scenario ....................................9
4. General Principles of the Solution .............................10
4.1. E-IP and I-IP .............................................10
4.2. Routing ...................................................10
4.3. Tunneled Forwarding .......................................11
5. Distribution of Inter-AFBR Routing Information .................11
6. Softwire Signaling .............................................13
7. Choosing to Forward through a Softwire .........................15
8. Selecting a Tunneling Technology ...............................15
9. Selecting the Softwire for a Given Packet ......................16
10. Softwire OAM and MIBs .........................................17
10.1. Operations and Maintenance (OAM) .........................17
10.2. MIBs .....................................................18
11. Softwire Multicast ............................................18
11.1. One-to-One Mappings ......................................18
11.1.1. Using PIM in the Core .............................19
11.1.2. Using mLDP and Multicast MPLS in the Core .........20
11.2. MVPN-Like Schemes ........................................21
12. Inter-AS Considerations .......................................22
13. Security Considerations .......................................23
13.1. Problem Analysis .........................................23
13.2. Non-Cryptographic Techniques .............................24
1. Introduction ....................................................3
2. Specification of Requirements ...................................6
3. Scenarios of Interest ...........................................7
3.1. IPv6-over-IPv4 Scenario ....................................7
3.2. IPv4-over-IPv6 Scenario ....................................9
4. General Principles of the Solution .............................10
4.1. E-IP and I-IP .............................................10
4.2. Routing ...................................................10
4.3. Tunneled Forwarding .......................................11
5. Distribution of Inter-AFBR Routing Information .................11
6. Softwire Signaling .............................................13
7. Choosing to Forward through a Softwire .........................15
8. Selecting a Tunneling Technology ...............................15
9. Selecting the Softwire for a Given Packet ......................16
10. Softwire OAM and MIBs .........................................17
10.1. Operations and Maintenance (OAM) .........................17
10.2. MIBs .....................................................18
11. Softwire Multicast ............................................18
11.1. One-to-One Mappings ......................................18
11.1.1. Using PIM in the Core .............................19
11.1.2. Using mLDP and Multicast MPLS in the Core .........20
11.2. MVPN-Like Schemes ........................................21
12. Inter-AS Considerations .......................................22
13. Security Considerations .......................................23
13.1. Problem Analysis .........................................23
13.2. Non-Cryptographic Techniques .............................24
13.3. Cryptographic Techniques .................................26
14. References ....................................................27
14.1. Normative References .....................................27
14.2. Informative References ...................................28
15. Contributors ..................................................30
16. Acknowledgments ...............................................30
13.3. Cryptographic Techniques .................................26
14. References ....................................................27
14.1. Normative References .....................................27
14.2. Informative References ...................................28
15. Contributors ..................................................30
16. Acknowledgments ...............................................30
The routing information in any IP backbone network can be thought of as being in one of two categories: "internal routing information" or "external routing information". The internal routing information consists of routes to the nodes that belong to the backbone, and to the interfaces of those nodes. External routing information consists of routes to destinations beyond the backbone, especially destinations to which the backbone is not directly attached. In general, BGP [RFC4271] is used to distribute external routing information, and an Interior Gateway Protocol (IGP) such as OSPF [RFC2328] or IS-IS [RFC1195] is used to distribute internal routing information.
任何IP骨干网中的路由信息都可以被认为是两类中的一类：“内部路由信息”或“外部路由信息”。内部路由信息包括到属于主干网的节点以及这些节点的接口的路由。外部路由信息包括到主干以外的目的地的路由，尤其是主干未直接连接到的目的地。通常，BGP[RFC4271]用于分发外部路由信息，而诸如OSPF[RFC2328]或is-is[RFC1195]之类的内部网关协议（IGP）用于分发内部路由信息。
Often an IP backbone will provide transit routing services for packets that originate outside the backbone and whose destinations are outside the backbone. These packets enter the backbone at one of its "edge routers". They are routed through the backbone to another edge router, after which they leave the backbone and continue on their way. The edge nodes of the backbone are often known as "Provider Edge" (PE) routers. The term "ingress" (or "ingress PE") refers to the router at which a packet enters the backbone, and the term "egress" (or "egress PE") refers to the router at which it leaves the backbone. Interior nodes are often known as "P routers". Routers that are outside the backbone but directly attached to it are known as "Customer Edge" (CE) routers. (This terminology is taken from [RFC4364].)
通常，IP主干网将为源自主干网之外且目的地位于主干网之外的数据包提供传输路由服务。这些数据包通过其一个“边缘路由器”进入主干网。它们通过主干路由到另一个边缘路由器，然后离开主干继续前进。主干网的边缘节点通常被称为“提供者边缘”（PE）路由器。术语“入口”（或“入口PE”）指数据包进入主干的路由器，术语“出口”（或“出口PE”）指数据包离开主干的路由器。内部节点通常被称为“P路由器”。位于主干网之外但直接连接到主干网的路由器称为“客户边缘”（CE）路由器。（该术语取自[RFC4364]。）
When a packet's destination is outside the backbone, the routing information that is needed within the backbone in order to route the packet to the proper egress is, by definition, external routing information.
当数据包的目的地在主干网之外时，主干网内将数据包路由到适当出口所需的路由信息根据定义是外部路由信息。
Traditionally, the external routing information has been distributed by BGP to all the routers in the backbone, not just to the edge routers (i.e., not just to the ingress and egress points). Each of the interior nodes has been expected to look up the packet's destination address and route it towards the egress point. This is known as "native forwarding": the interior nodes look into each packet's header in order to match the information in the header with the external routing information.
传统上，BGP将外部路由信息分发到主干中的所有路由器，而不仅仅是边缘路由器（即，不仅仅是入口和出口点）。期望每个内部节点查找数据包的目的地地址并将其路由到出口点。这称为“本机转发”：内部节点查看每个数据包的报头，以便将报头中的信息与外部路由信息相匹配。
It is, however, possible to provide transit services without requiring that all the backbone routers have the external routing information. The routing information that BGP distributes to each ingress router specifies the egress router for each route. The ingress router can therefore "tunnel" the packet directly to the egress router. "Tunneling the packet" means putting on some sort of encapsulation header that will force the interior routers to forward the packet to the egress router. The original packet is known as the "encapsulation payload". The P routers do not look at the packet header of the payload but only at the encapsulation header. Since the path to the egress router is part of the internal routing information of the backbone, the interior routers then do not need to know the external routing information. This is known as "tunneled forwarding". Of course, before the packet can leave the egress, it has to be decapsulated.
但是，可以在不要求所有骨干路由器具有外部路由信息的情况下提供传输服务。BGP分发给每个入口路由器的路由信息指定每个路由的出口路由器。因此，入口路由器可以将分组直接“隧道”到出口路由器。“隧道传输数据包”意味着加入某种封装头，这将迫使内部路由器将数据包转发到出口路由器。原始数据包称为“封装负载”。P路由器不查看有效负载的数据包报头，而只查看封装报头。由于到出口路由器的路径是骨干网内部路由信息的一部分，因此内部路由器不需要知道外部路由信息。这被称为“隧道转发”。当然，在数据包离开出口之前，它必须被拆封。
The scenario where the P routers do not have external routes is sometimes known as a "BGP-free core". That is something of a misnomer, though, since the crucial aspect of this scenario is not that the interior nodes don't run BGP, but that they don't maintain the external routing information.
P路由器没有外部路由的场景有时被称为“BGP自由核心”。不过，这有点用词不当，因为该场景的关键方面不是内部节点不运行BGP，而是它们不维护外部路由信息。
In recent years, we have seen this scenario deployed to support VPN services, as specified in [RFC4364]. An edge router maintains multiple independent routing/addressing spaces, one for each VPN to which it interfaces. However, the routing information for the VPNs is not maintained by the interior routers. In most of these scenarios, MPLS is used as the encapsulation mechanism for getting the packets from ingress to egress. There are some deployments in which an IP-based encapsulation, such as L2TPv3 (Layer 2 Transport Protocol) [RFC3931] or GRE (Generic Routing Encapsulation) [RFC2784] is used.
近年来，我们已经看到了部署此场景以支持VPN服务的情况，如[RFC4364]中所述。边缘路由器维护多个独立的路由/寻址空间，每个VPN对应一个。但是，VPN的路由信息不由内部路由器维护。在大多数情况下，MPLS被用作从入口到出口获取数据包的封装机制。有些部署使用基于IP的封装，例如L2TPv3（第2层传输协议）[RFC3931]或GRE（通用路由封装）[RFC2784]。
This same technique can also be useful when the external routing information consists not of VPN routes, but of "ordinary" Internet routes. It can be used any time it is desired to keep external routing information out of a backbone's interior nodes, or in fact any time it is desired for any reason to avoid the native forwarding of certain kinds of packets.
当外部路由信息不是由VPN路由组成，而是由“普通”互联网路由组成时，同样的技术也很有用。它可以在希望将外部路由信息保留在主干网内部节点之外的任何时候使用，或者实际上，在出于任何原因希望避免某些类型的数据包的本机转发的任何时候使用。
This framework focuses on two such scenarios.
这个框架主要关注两个这样的场景。
1. In this scenario, the backbone's interior nodes support only IPv6. They do not maintain IPv4 routes at all, and are not expected to parse IPv4 packet headers. Yet, it is desired to use such a backbone to provide transit services for IPv4 packets. Therefore, tunneled forwarding of IPv4 packets is
1. 在这种情况下，主干网的内部节点仅支持IPv6。它们根本不维护IPv4路由，也不需要解析IPv4数据包头。然而，希望使用这样的主干网为IPv4数据包提供传输服务。因此，IPv4数据包的隧道转发非常重要
required. Of course, the edge nodes must have the IPv4 routes, but the ingress must perform an encapsulation in order to get an IPv4 packet forwarded to the egress.
必修的。当然，边缘节点必须具有IPv4路由，但入口必须执行封装，以便将IPv4数据包转发到出口。
2. This scenario is the reverse of scenario 1, i.e., the backbone's interior nodes support only IPv4, but it is desired to use the backbone for IPv6 transit.
2. 此场景与场景1相反，即主干网的内部节点仅支持IPv4，但希望使用主干网进行IPv6传输。
In these scenarios, a backbone whose interior nodes support only one of the two address families is required to provide transit services for the other. The backbone's edge routers must, of course, support both address families. We use the term "Address Family Border Router" (AFBR) to refer to these PE routers. The tunnels that are used for forwarding are referred to as "softwires".
在这些场景中，内部节点仅支持两个地址族中的一个的主干网需要为另一个提供中转服务。当然，主干网的边缘路由器必须同时支持两个地址族。我们使用术语“地址族边界路由器”（AFBR）来指代这些PE路由器。用于转发的隧道称为“软线”。
These two scenarios are known as the "Softwire Mesh Problem" [SW-PROB], and the framework specified in this document is therefore known as the "Softwire Mesh Framework". In this framework, only the AFBRs need to support both address families. The CE routers support only a single address family, and the P routers support only the other address family.
这两种情况被称为“软线网格问题”[SW-PROB]，因此本文档中指定的框架被称为“软线网格框架”。在此框架中，只有AFBR需要支持这两个地址族。CE路由器只支持一个地址族，而P路由器只支持另一个地址族。
It is possible to address these scenarios via a large variety of tunneling technologies. This framework does not mandate the use of any particular tunneling technology. In any given deployment, the choice of tunneling technology is a matter of policy. The framework accommodates at least the use of MPLS ([RFC3031], [RFC3032]) -- both LDP-based (Label Distribution Protocol, [RFC5036]) and RSVP-TE-based (Resource Reservation Protocol - Traffic Engineering, [RFC3209]) -- L2TPv3 [RFC3931], GRE [RFC2784], and IP-in-IP [RFC2003]. The framework will also accommodate the use of IPsec tunneling, when that is necessary in order to meet security requirements.
可以通过各种各样的隧道技术来解决这些场景。该框架不强制使用任何特定的隧道技术。在任何给定的部署中，隧道技术的选择都是一个政策问题。该框架至少支持MPLS（[RFC3031]、[RFC3032]）——基于LDP（标签分发协议[RFC5036]）和基于RSVP TE（基于资源预留协议-流量工程[RFC3209]）——L2TPv3[RFC3931]、GRE[RFC2784]和IP-in-IP[RFC2003]的使用。当为了满足安全要求而有必要时，该框架还将适应IPsec隧道的使用。
It is expected that, in many deployments, the choice of tunneling technology will be made by a simple expression of policy, such as "always use IP-IP tunnels", or "always use LDP-based MPLS", or "always use L2TPv3".
预计在许多部署中，隧道技术的选择将通过简单的策略表达进行，例如“始终使用IP-IP隧道”、“始终使用基于LDP的MPLS”或“始终使用L2TPv3”。
However, other deployments may have a mixture of routers, some of which support, say, both GRE and L2TPv3, but others of which support only one of those techniques. It is desirable therefore to allow the network administration to create a small set of classes, and to configure each AFBR to be a member of one or more of these classes. Then the routers can advertise their class memberships to each other, and the encapsulation policies can be expressed as, e.g., "use L2TPv3 to tunnel to routers in class X; use GRE to tunnel to routers in
但是，其他部署可能混合使用路由器，其中一些路由器支持GRE和L2TPv3，但另一些路由器仅支持其中一种技术。因此，希望允许网络管理创建一小组类，并将每个AFBR配置为这些类中的一个或多个的成员。然后路由器可以相互公布它们的类成员身份，封装策略可以表示为，例如，“使用L2TPv3隧道到X类中的路由器；使用GRE隧道到X类中的路由器。”
class Y". To support such policies, it is necessary for the AFBRs to be able to advertise their class memberships; a standard way of doing this must be developed.
为支持此类政策，AFBR必须能够宣传其班级成员资格；必须制定一种标准方式。
Policy may also require a certain class of traffic to receive a certain quality of service, and this may impact the choice of tunnel and/or tunneling technology used for packets in that class. This needs to be accommodated by the Softwire Mesh Framework.
策略还可能要求特定类别的通信量接收特定质量的服务，这可能会影响该类别数据包使用的隧道和/或隧道技术的选择。这需要软线网框架来适应。
The use of tunneled forwarding often requires that some sort of signaling protocol be used to set up and/or maintain the tunnels. Many of the tunneling technologies accommodated by this framework already have their own signaling protocols. However, some do not, and in some cases the standard signaling protocol for a particular tunneling technology may not be appropriate (for one or another reason) in the scenarios of interest. In such cases (and in such cases only), new signaling methodologies need to be defined and standardized.
隧道转发的使用通常需要使用某种信令协议来建立和/或维护隧道。该框架所适应的许多隧道技术已经有了自己的信令协议。然而，有些情况并非如此，并且在某些情况下，特定隧道技术的标准信令协议在感兴趣的场景中可能不合适（出于一个或另一个原因）。在这种情况下（仅在这种情况下），需要定义和标准化新的信令方法。
In this framework, the softwires do not form an overlay topology that is visible to routing; routing adjacencies are not maintained over the softwires, and routing control packets are not sent through the softwires. Routing adjacencies among backbone nodes (including the edge nodes) are maintained via the native technology of the backbone.
在该框架中，软线不形成对路由可见的覆盖拓扑；路由邻接不在软线上保持，路由控制包不通过软线发送。主干节点（包括边缘节点）之间的路由邻接通过主干的本机技术进行维护。
There is already a standard routing method for distributing external routing information among AFBRs, namely BGP. However, in the scenarios of interest, we may be using IPv6-based BGP sessions to pass IPv4 routing information, and we may be using IPv4-based BGP sessions to pass IPv6 routing information. Furthermore, when IPv4 traffic is to be tunneled over an IPv6 backbone, it is necessary to encode the "BGP next hop" for an IPv4 route as an IPv6 address, and vice versa. The method for encoding an IPv4 address as the next hop for an IPv6 route is specified in [V6NLRI-V4NH]; the method for encoding an IPv6 address as the next hop for an IPv4 route is specified in [V4NLRI-V6NH].
已经有一种标准的路由方法用于在AFBR之间分发外部路由信息，即BGP。但是，在感兴趣的场景中，我们可能使用基于IPv6的BGP会话来传递IPv4路由信息，也可能使用基于IPv4的BGP会话来传递IPv6路由信息。此外，当IPv4流量通过IPv6主干进行隧道传输时，有必要将IPv4路由的“BGP下一跳”编码为IPv6地址，反之亦然。[V6NLRI-V4NH]中指定了将IPv4地址编码为IPv6路由的下一个跃点的方法；[V4NLRI-V6NH]中指定了将IPv6地址编码为IPv4路由的下一个跃点的方法。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In this scenario, the client networks run IPv6 but the backbone network runs IPv4. This is illustrated in Figure 1.
在这种情况下，客户端网络运行IPv6，而主干网络运行IPv4。这如图1所示。
+--------+ +--------+
| IPv6 | | IPv6 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| AFBR | | AFBR |
+--| IPv4/6 |---| IPv4/6 |--+
| +--------+ +--------+ |
+--------+ | | +--------+
| IPv4 | | | | IPv4 |
| Client | | | | Client |
| Network|------| IPv4 |-------| Network|
+--------+ | only | +--------+
| |
| +--------+ +--------+ |
+--| AFBR |---| AFBR |--+
| IPv4/6 | | IPv4/6 |
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| IPv6 | | IPv6 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
+--------+ +--------+
| IPv6 | | IPv6 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| AFBR | | AFBR |
+--| IPv4/6 |---| IPv4/6 |--+
| +--------+ +--------+ |
+--------+ | | +--------+
| IPv4 | | | | IPv4 |
| Client | | | | Client |
| Network|------| IPv4 |-------| Network|
+--------+ | only | +--------+
| |
| +--------+ +--------+ |
+--| AFBR |---| AFBR |--+
| IPv4/6 | | IPv4/6 |
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| IPv6 | | IPv6 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
Figure 1: IPv6-over-IPv4 Scenario
图1:IPv6-over-IPv4场景
The IPv4 transit core may or may not run MPLS. If it does, MPLS may be used as part of the solution.
IPv4传输核心可能运行也可能不运行MPLS。如果有，MPLS可以作为解决方案的一部分使用。
While Figure 1 does not show any "backdoor" connections among the client networks, this framework assumes that there will be such connections. That is, there is no assumption that the only path between two client networks is via the pictured transit-core network. Hence, the routing solution must be robust in any kind of topology.
虽然图1没有显示客户机网络之间的任何“后门”连接，但此框架假设将存在此类连接。也就是说，没有假设两个客户端网络之间的唯一路径是通过核心网络。因此，路由解决方案在任何拓扑中都必须是健壮的。
Many mechanisms for providing IPv6 connectivity across IPv4 networks have been devised over the past ten years. A number of different tunneling mechanisms have been used, some provisioned manually, and others based on special addressing. More recently, L3VPN (Layer 3 Virtual Private Network) techniques from [RFC4364] have been extended to provide IPv6 connectivity, using MPLS in the AFBRs and, optionally, in the backbone [V6NLRI-V4NH]. The solution described in this framework can be thought of as a superset of [V6NLRI-V4NH], with a more generalized scheme for choosing the tunneling (softwire) technology. In this framework, MPLS is allowed -- but not required -- even at the AFBRs. As in [V6NLRI-V4NH], there is no manual provisioning of tunnels, and no special addressing is required.
在过去十年中，已经设计了许多跨IPv4网络提供IPv6连接的机制。已经使用了许多不同的隧道机制，一些是手动设置的，另一些是基于特殊寻址的。最近，[RFC4364]的L3VPN（第3层虚拟专用网络）技术已经扩展到提供IPv6连接，在AFBR中使用MPLS，或者在主干[V6NLRI-V4NH]中使用MPLS。该框架中描述的解决方案可以被认为是[V6NLRI-V4NH]的超集，具有选择隧道（软线）技术的更通用方案。在这个框架中，MPLS是允许的——但不是必需的——即使在AFBR上也是如此。与[V6NLRI-V4NH]一样，不需要手动设置隧道，也不需要特殊寻址。
In this scenario, the client networks run IPv4 but the backbone network runs IPv6. This is illustrated in Figure 2.
在这种情况下，客户端网络运行IPv4，而主干网络运行IPv6。如图2所示。
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| AFBR | | AFBR |
+--| IPv4/6 |---| IPv4/6 |--+
| +--------+ +--------+ |
+--------+ | | +--------+
| IPv6 | | | | IPv6 |
| Client | | | | Client |
| Network|------| IPv6 |-------| Network|
+--------+ | only | +--------+
| |
| +--------+ +--------+ |
+--| AFBR |---| AFBR |--+
| IPv4/6 | | IPv4/6 |
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| AFBR | | AFBR |
+--| IPv4/6 |---| IPv4/6 |--+
| +--------+ +--------+ |
+--------+ | | +--------+
| IPv6 | | | | IPv6 |
| Client | | | | Client |
| Network|------| IPv6 |-------| Network|
+--------+ | only | +--------+
| |
| +--------+ +--------+ |
+--| AFBR |---| AFBR |--+
| IPv4/6 | | IPv4/6 |
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
Figure 2: IPv4-over-IPv6 Scenario
图2:IPv4-over-IPv6场景
The IPv6 transit core may or may not run MPLS. If it does, MPLS may be used as part of the solution.
IPv6传输核心可能运行也可能不运行MPLS。如果有，MPLS可以作为解决方案的一部分使用。
While Figure 2 does not show any "backdoor" connections among the client networks, this framework assumes that there will be such connections. That is, there is no assumption that the only path between two client networks is via the pictured transit-core network. Hence, the routing solution must be robust in any kind of topology.
虽然图2没有显示客户机网络之间的任何“后门”连接，但此框架假设将存在此类连接。也就是说，没有假设两个客户端网络之间的唯一路径是通过核心网络。因此，路由解决方案在任何拓扑中都必须是健壮的。
While the issue of IPv6-over-IPv4 has received considerable attention in the past, the scenario of IPv4-over-IPv6 has not. Yet, it is a significant emerging requirement, as a number of service providers are building IPv6 backbone networks and do not wish to provide native IPv4 support in their core routers. These service providers have a large legacy of IPv4 networks and applications that need to operate across their IPv6 backbone. Solutions for this do not exist yet because it had always been assumed that the backbone networks of the foreseeable future would be dual stack.
虽然IPv6-over-IPv4的问题在过去受到了相当多的关注，但IPv4-over-IPv6的情况却没有得到关注。然而，这是一个重要的新兴需求，因为许多服务提供商正在构建IPv6骨干网络，不希望在其核心路由器中提供本机IPv4支持。这些服务提供商拥有大量传统的IPv4网络和应用程序，需要跨其IPv6主干网运行。这方面的解决方案还不存在，因为人们一直认为，在可预见的未来，主干网将是双栈的。
This section gives a very brief overview of the procedures. The subsequent sections provide more detail.
本节简要概述了这些步骤。后续章节将提供更多详细信息。
In the following sections, we use the term "I-IP" (Internal IP) to refer to the form of IP (i.e., either IPv4 or IPv6) that is supported by the transit network. We use the term "E-IP" (External IP) to refer to the form of IP that is supported by the client networks. In the scenarios of interest, E-IP is IPv4 if and only if I-IP is IPv6, and E-IP is IPv6 if and only if I-IP is IPv4.
在以下各节中，我们使用术语“I-IP”（内部IP）来表示传输网络支持的IP形式（即IPv4或IPv6）。我们使用术语“E-IP”（外部IP）来指代客户端网络支持的IP形式。在感兴趣的场景中，E-IP是IPv4当且仅当I-IP是IPv6时，E-IP是IPv6当且仅当I-IP是IPv4时。
We assume that the P routers support only I-IP. That is, they are expected to have only I-IP routing information, and they are not expected to be able to parse E-IP headers. We similarly assume that the CE routers support only E-IP.
我们假设P路由器只支持I-IP。也就是说，它们应该只有I-IP路由信息，而不能解析E-IP头。我们同样假设CE路由器只支持E-IP。
The AFBRs handle both I-IP and E-IP. However, only I-IP is used on AFBR's "core-facing interfaces", and E-IP is only used on its client-facing interfaces.
AFBR同时处理I-IP和E-IP。然而，只有I-IP用于AFBR的“面向核心的接口”，而E-IP仅用于其面向客户端的接口。
The P routers and the AFBRs of the transit network participate in an IGP for the purposes of distributing I-IP routing information.
为了分发I-IP路由信息，公交网络的IP路由器和afbr参与IGP。
The AFBRs use Internal BGP (IBGP) to exchange E-IP routing information with each other. Either there is a full mesh of IBGP connections among the AFBRs, or else some or all of the AFBRs are clients of a BGP Route Reflector. Although these IBGP connections
AFBR使用内部BGP（IBGP）相互交换E-IP路由信息。AFBR之间存在完整的IBGP连接网，或者部分或全部AFBR是BGP路由反射器的客户端。尽管这些IBGP连接
are used to pass E-IP routing information (i.e., the Network Layer Reachability Information (NLRI) of the BGP updates is in the E-IP address family), the IBGP connections run over I-IP, and the BGP next hop for each E-IP NLRI is in the I-IP address family.
用于传递E-IP路由信息（即BGP更新的网络层可达性信息（NLRI）在E-IP地址族中），IBGP连接在i-IP上运行，每个E-IP NLRI的BGP下一跳在i-IP地址族中。
When an ingress AFBR receives an E-IP packet from a client-facing interface, it looks up the packet's destination IP address. In the scenarios of interest, the best match for that address will be a BGP-distributed route whose next hop is the I-IP address of another AFBR, the egress AFBR.
当入口AFBR从面向客户端的接口接收到E-IP数据包时，它会查找数据包的目标IP地址。在感兴趣的场景中，该地址的最佳匹配将是BGP分布式路由，其下一跳是另一个AFBR（出口AFBR）的I-IP地址。
The ingress AFBR must forward the packet through a tunnel (i.e, through a softwire) to the egress AFBR. This is done by encapsulating the packet, using an encapsulation header that the P routers can process and that will cause the P routers to send the packet to the egress AFBR. The egress AFBR then extracts the payload, i.e., the original E-IP packet, and forwards it further by looking up its IP destination address.
入口AFBR必须通过隧道（即，通过软线）将数据包转发到出口AFBR。这是通过使用P路由器可以处理的封装报头来封装分组来完成的，该封装报头将导致P路由器将分组发送到出口AFBR。出口AFBR然后提取有效载荷，即原始e-IP分组，并通过查找其IP目的地地址进一步转发它。
Several kinds of tunneling technologies are supported. Some of those technologies require explicit AFBR-to-AFBR signaling before the tunnel can be used, others do not.
支持多种隧道技术。其中一些技术需要在隧道可以使用之前显式地发送AFBR到AFBR的信令，而其他技术则不需要。
Transmitting a packet through a softwire always requires that an encapsulation header be added to the original packet. The resulting packet is therefore always longer than the encapsulation payload. As an operational matter, the Maximum Transmission Unit (MTU) of the softwire's path SHOULD be large enough so that (a) no packet will need to be fragmented before being encapsulated, and (b) no encapsulated packet will need to be fragmented while it is being forwarded along a softwire. A general discussion of MTU issues in the context of tunneled forwarding may be found in [RFC4459].
通过软线传输数据包始终需要在原始数据包中添加封装头。因此，生成的数据包总是比封装负载长。作为操作事项，软线路径的最大传输单元（MTU）应当足够大，以便（a）在封装之前不需要对分组进行分段，并且（b）在沿着软线转发时不需要对封装分组进行分段。关于隧道转发上下文中MTU问题的一般性讨论，请参见[RFC4459]。
AFBRs peer with routers in the client networks to exchange routing information for the E-IP family.
AFBR与客户端网络中的路由器对等，以交换E-IP系列的路由信息。
AFBRs use BGP to distribute the E-IP routing information to each other. This can be done by an AFBR-AFBR mesh of IBGP sessions, but more likely is done through a BGP Route Reflector, i.e., where each AFBR has an IBGP session to one or two Route Reflectors rather than to other AFBRs.
AFBR使用BGP相互分发E-IP路由信息。这可以通过IBGP会话的AFBR-AFBR网格完成，但更可能通过BGP路由反射器完成，即，每个AFBR都有一个IBGP会话到一个或两个路由反射器，而不是到其他AFBR。
The BGP sessions between the AFBRs, or between the AFBRs and the Route Reflector, will run on top of the I-IP address family. That is, if the transit core supports only IPv6, the IBGP sessions used to distribute IPv4 routing information from the client networks will run over IPv6; if the transit core supports only IPv4, the IBGP sessions used to distribute IPv6 routing information from the client networks will run over IPv4. The BGP sessions thus use the native networking layer of the core; BGP messages are NOT tunneled through softwires or through any other mechanism.
AFBR之间或AFBR与路由反射器之间的BGP会话将在I-IP地址系列的顶部运行。也就是说，如果传输核心仅支持IPv6，则用于从客户端网络分发IPv4路由信息的IBGP会话将在IPv6上运行；如果传输核心仅支持IPv4，则用于从客户端网络分发IPv6路由信息的IBGP会话将在IPv4上运行。因此，BGP会话使用核心的本机网络层；BGP消息不通过软线或任何其他机制进行隧道传输。
In BGP, a routing update associates an address prefix (or more generally, NLRI) with the address of a BGP next hop (NH). The NLRI is associated with a particular address family. The NH address is also associated with a particular address family, which may be the same as or different than the address family associated with the NLRI. Generally, the NH address belongs to the address family that is used to communicate with the BGP speaker to whom the NH address belongs.
在BGP中，路由更新将地址前缀（或更一般地说，NLRI）与BGP下一跳（NH）的地址相关联。NLRI与特定地址族相关联。NH地址还与特定地址族相关联，该地址族可能与NLRI关联的地址族相同或不同。通常，NH地址属于用于与NH地址所属的BGP说话人通信的地址族。
Since routing updates that contain information about E-IP address prefixes are carried over BGP sessions that use I-IP transport, and since the BGP messages are not tunneled, a BGP update providing information about an E-IP address prefix will need to specify a next hop address in the I-IP family.
由于包含有关E-IP地址前缀信息的路由更新通过使用I-IP传输的BGP会话进行，并且由于BGP消息没有隧道传输，因此提供有关E-IP地址前缀信息的BGP更新需要指定I-IP系列中的下一跳地址。
Due to a variety of historical circumstances, when the NLRI and the NH in a given BGP update are of different address families, it is not always obvious how the NH should be encoded. There is a different encoding procedure for each pair of address families.
由于各种历史情况，当给定BGP更新中的NLRI和NH属于不同的地址族时，NH的编码方式并不总是显而易见的。每对地址族都有不同的编码过程。
In the case where the NLRI is in the IPv6 address family, and the NH is in the IPv4 address family, [V6NLRI-V4NH] explains how to encode the NH.
如果NLRI在IPv6地址族中，NH在IPv4地址族中，[V6NLRI-V4NH]解释了如何对NH进行编码。
In the case where the NLRI is in the IPv4 address family, and the NH is in the IPv6 address family, [V4NLRI-V6NH] explains how to encode the NH.
如果NLRI在IPv4地址族中，NH在IPv6地址族中，[V4NLRI-V6NH]解释了如何对NH进行编码。
If a BGP speaker sends an update for an NLRI in the E-IP family, and the update is being sent over a BGP session that is running on top of the I-IP network layer, and the BGP speaker is advertising itself as the NH for that NLRI, then the BGP speaker MUST, unless explicitly overridden by policy, specify the NH address in the I-IP family. The address family of the NH MUST NOT be changed by a Route Reflector.
如果BGP演讲者为E-IP系列中的NLRI发送更新，并且更新是通过在I-IP网络层上运行的BGP会话发送的，并且BGP演讲者将自己宣传为该NLRI的NH，则除非策略明确覆盖，否则BGP演讲者必须指定I-IP系列中的NH地址。NH的地址族不能被路由反射器更改。
In some cases (e.g., when [V4NLRI-V6NH] is used), one cannot follow this rule unless one's BGP peers have advertised a particular BGP capability. This leads to the following softwire deployment
在某些情况下（例如，当使用[V4NLRI-V6NH]时），除非BGP对等方已公布特定BGP功能，否则无法遵循此规则。这将导致以下软线部署
restriction: if a BGP capability is defined for the case in which an E-IP NLRI has an I-IP NH, all the AFBRs in a given transit core MUST advertise that capability.
限制：如果为E-IP NLRI具有I-IP NH的情况定义了BGP能力，则给定传输核心中的所有AFBR必须公布该能力。
If an AFBR has multiple IP addresses, the network administrators usually have considerable flexibility in choosing which one the AFBR uses to identify itself as the next hop in a BGP update. However, if the AFBR expects to receive packets through a softwire of a particular tunneling technology, and if the AFBR is known to that tunneling technology via a specific IP address, then that same IP address must be used to identify the AFBR in the next hop field of the BGP updates. For example, if L2TPv3 tunneling is used, then the IP address that the AFBR uses when engaging in L2TPv3 signaling must be the same as the IP address it uses to identify itself in the next hop field of a BGP update.
如果一个AFBR有多个IP地址，网络管理员通常在选择AFBR使用哪个IP地址来标识自己为BGP更新中的下一个跃点时具有相当大的灵活性。然而，如果AFBR期望通过特定隧道技术的软线接收分组，并且如果该隧道技术通过特定IP地址知道AFBR，则必须使用该相同IP地址在BGP更新的下一跳字段中标识AFBR。例如，如果使用L2TPv3隧道，则AFBR在参与L2TPv3信令时使用的IP地址必须与它在BGP更新的下一跳字段中用于标识自身的IP地址相同。
In [V6NLRI-V4NH], IPv6 routing information is distributed using the labeled IPv6 address family. This allows the egress AFBR to associate an MPLS label with each IPv6 address prefix. If an ingress AFBR forwards packets through a softwire that can carry MPLS packets, each data packet can carry the MPLS label corresponding to the IPv6 route that it matched. This may be useful at the egress AFBR, for demultiplexing and/or enhanced performance. It is also possible to do the same for the IPv4 address family, i.e., to use the labeled IPv4 address family instead of the IPv4 address family. The use of the labeled IP address families in this manner is OPTIONAL.
在[V6NLRI-V4NH]中，IPv6路由信息使用标记的IPv6地址族进行分发。这允许出口AFBR将MPLS标签与每个IPv6地址前缀相关联。如果入口AFBR通过可携带MPLS数据包的软线转发数据包，则每个数据包可携带与其匹配的IPv6路由相对应的MPLS标签。这在出口AFBR处可用于解复用和/或增强性能。也可以对IPv4地址系列执行相同的操作，即使用标记的IPv4地址系列而不是IPv4地址系列。以这种方式使用标记的IP地址族是可选的。
A mesh of inter-AFBR softwires spanning the transit core must be in place before packets can flow between client networks. Given N dual-stack AFBRs, this requires N^2 "point-to-point IP" or "label switched path" (LSP) tunnels. While in theory these could be configured manually, that would result in a very undesirable O(N^2) provisioning problem. Therefore, manual configuration of point-to-point tunnels is not considered part of this framework.
在数据包可以在客户端网络之间流动之前，必须在传输核心上安装一个AFBR间软线网。给定N个双堆栈AFBR，这需要N^2个“点对点IP”或“标签交换路径”（LSP）隧道。虽然理论上可以手动配置这些资源，但这将导致非常不希望出现的O（N^2）资源调配问题。因此，手动配置点到点隧道不被视为本框架的一部分。
Because the transit core is providing layer 3 transit services, point-to-point tunnels are not required by this framework; multipoint-to-point tunnels are all that is needed. In a multipoint-to-point tunnel, when a packet emerges from the tunnel there is no way to tell which router put the packet into the tunnel. This models the native IP forwarding paradigm, wherein the egress router cannot determine a given packet's ingress router. Of course, point-to-point tunnels might be required for some reason beyond the basic requirements described in this document. For example, Quality of
由于公交核心提供第3层公交服务，因此该框架不需要点对点隧道；多点对点隧道就是所需要的一切。在多点对点隧道中，当数据包从隧道中出现时，无法判断是哪个路由器将数据包放入隧道。这模拟了本机IP转发范例，其中出口路由器无法确定给定数据包的入口路由器。当然，除了本文件中描述的基本要求外，可能出于某些原因需要点对点隧道。例如，产品质量
Service (QoS) or security considerations might require the use of point-to-point tunnels. So point-to-point tunnels are allowed, but not required, by this framework.
服务（QoS）或安全考虑可能需要使用点对点隧道。因此，该框架允许但不要求点对点隧道。
If it is desired to use a particular tunneling technology for the softwires, and if that technology has its own "native" signaling methodology, the presumption is that the native signaling will be used. This would certainly apply to MPLS-based softwires, where LDP or RSVP-TE would be used. An IPsec-based softwire would use standard IKEv2 (Internet Key Exchange) [RFC4306] and IPsec [RFC4301] signaling, as that is necessary in order to guarantee the softwire's security properties.
如果希望对软线使用特定的隧道技术，并且如果该技术具有其自己的“本机”信令方法，则假定将使用本机信令。这当然适用于基于MPLS的软电线，其中将使用LDP或RSVP-TE。基于IPsec的软线将使用标准IKEv2（互联网密钥交换）[RFC4306]和IPsec[RFC4301]信令，因为这是保证软线安全属性所必需的。
A GRE-based softwire might or might not require signaling, depending on whether various optional GRE header fields are to be used. GRE does not have any "native" signaling, so for those cases, a signaling procedure needs to be developed to support softwires.
基于GRE的软线可能需要也可能不需要信令，这取决于是否要使用各种可选的GRE报头字段。GRE没有任何“本地”信令，因此对于这些情况，需要开发一个信令程序来支持软线。
Another possible softwire technology is L2TPv3. While L2TPv3 does have its own native signaling, that signaling sets up point-to-point tunnels. For the purpose of softwires, it is better to use L2TPv3 in a multipoint-to-point mode, and this requires a different kind of signaling.
另一种可能的软线技术是L2TPv3。虽然L2TPv3有自己的本机信令，但该信令建立了点对点隧道。对于软线，最好在多点对点模式下使用L2TPv3，这需要不同类型的信令。
The signaling to be used for GRE and L2TPv3 to cover these scenarios is BGP-based, and is described in [RFC5512].
用于GRE和L2TPv3覆盖这些场景的信令是基于BGP的，并在[RFC5512]中描述。
If IP-IP tunneling is used, or if GRE tunneling is used without options, no signaling is required, as the only information needed by the ingress AFBR to create the encapsulation header is the IP address of the egress AFBR, and that is distributed by BGP.
如果使用IP-IP隧道，或者如果使用GRE隧道而没有选项，则不需要信令，因为入口AFBR创建封装头所需的唯一信息是出口AFBR的IP地址，该地址由BGP分发。
When the encapsulation IP header is constructed, there may be fields in the IP whose value is determined neither by whatever signaling has been done nor by the distributed routing information. The values of these fields are determined by policy in the ingress AFBR. Examples of such fields may be the TTL (Time to Live) field, the DSCP (Diffserv Service Classes) bits, etc.
当构造封装IP报头时，IP中可能存在字段，其值既不由所做的任何信令决定，也不由分布式路由信息决定。这些字段的值由入口AFBR中的策略确定。此类字段的示例可以是TTL（生存时间）字段、DSCP（区分服务类）位等。
It is desirable for all necessary softwires to be fully set up before the arrival of any packets that need to go through the softwires. That is, the softwires should be "always on". From the perspective of any particular AFBR, the softwire endpoints are always BGP next hops of routes that the AFBR has installed. This suggests that any necessary softwire signaling should either be done as part of normal system startup (as would happen, e.g., with LDP-based MPLS) or else
希望在需要通过软导线的任何分组到达之前完全设置所有必要的软导线。也就是说，软线应“始终打开”。从任何特定AFBR的角度来看，软线端点始终是AFBR已安装的路由的BGP下一跳。这表明，任何必要的软线信令都应作为正常系统启动的一部分进行（如使用基于LDP的MPLS时会发生的情况），否则
be triggered by the reception of BGP routing information (such as is described in [RFC5512]); it is also helpful if distribution of the routing information that serves as the trigger is prioritized.
通过接收BGP路由信息触发（如[RFC5512]中所述）；如果将用作触发器的路由信息的分布划分为优先级，这也很有帮助。
The decision to forward through a softwire, instead of to forward natively, is made by the ingress AFBR. This decision is a matter of policy.
入口AFBR决定通过软线转发，而不是本机转发。这个决定是一个政策问题。
In many cases, the policy will be very simple. Some useful policies are:
在许多情况下，政策将非常简单。一些有用的政策包括：
- If routing says that an E-IP packet has to be sent out a core-facing interface to an I-IP core, then send the packet through a softwire.
- 如果路由规定必须将E-IP数据包从面向核心的接口发送到I-IP核心，则通过软线发送数据包。
- If routing says that an E-IP packet has to be sent out an interface that only supports I-IP packets, then send the E-IP packet through a softwire.
- 如果路由规定必须将E-IP数据包发送到仅支持I-IP数据包的接口，则通过软线发送E-IP数据包。
- If routing says that the BGP next hop address for an E-IP packet is an I-IP address, then send the E-IP packet through a softwire.
- 如果路由表示E-IP数据包的BGP下一跳地址是I-IP地址，则通过软线发送E-IP数据包。
- If the route that is the best match for a particular packet's destination address is a BGP-distributed route, then send the packet through a softwire (i.e., tunnel all BGP-routed packets).
- 如果与特定分组的目的地地址最匹配的路由是BGP分布式路由，则通过软线（即，隧道所有BGP路由分组）发送分组。
More complicated policies are also possible, but a consideration of those policies is outside the scope of this document.
也可以制定更复杂的政策，但对这些政策的考虑不在本文件的范围之内。
The choice of tunneling technology is a matter of policy configured at the ingress AFBR.
隧道技术的选择取决于入口AFBR配置的策略。
It is envisioned that, in most cases, the policy will be a very simple one, and will be the same at all the AFBRs of a given transit core -- e.g., "always use LDP-based MPLS" or "always use L2TPv3".
可以预见，在大多数情况下，该策略将非常简单，并且在给定传输核心的所有AFBR上都是相同的，例如，“始终使用基于LDP的MPLS”或“始终使用L2TPv3”。
However, other deployments may have a mixture of routers, some of which support, say, both GRE and L2TPv3, but others of which support only one of those techniques. It is desirable therefore to allow the network administration to create a small set of classes and to configure each AFBR to be a member of one or more of these classes. Then the routers can advertise their class memberships to each other, and the encapsulation policies can be expressed as, e.g., "use L2TPv3 to talk to routers in class X; use GRE to talk to routers in class
但是，其他部署可能混合使用路由器，其中一些路由器支持GRE和L2TPv3，但另一些路由器仅支持其中一种技术。因此，希望允许网络管理创建一小组类，并将每个AFBR配置为这些类中的一个或多个的成员。然后路由器可以相互公布它们的类成员身份，封装策略可以表示为，例如，“使用L2TPv3与类X中的路由器对话；使用GRE与类X中的路由器对话。”
Y". To support such policies, it is necessary for the AFBRs to be able to advertise their class memberships. [RFC5512] specifies a way in which an AFBR may advertise, to other AFBRS, various characteristics that may be relevant to the policy (e.g., "I belong to class Y"). In many cases, these characteristics can be represented by arbitrarily selected communities or extended communities, and the policies at the ingress can be expressed in terms of these classes (i.e., communities).
为支持此类政策，AFBR必须能够公布其类别成员身份。[RFC5512]规定了AFBR向其他AFBR公布可能与政策相关的各种特征的方式（例如，“我属于Y类”）。在许多情况下，这些特征可以由任意选择的社区或扩展社区表示，入口的策略可以用这些类别（即社区）表示。
Policy may also require a certain class of traffic to receive a certain quality of service, and this may impact the choice of tunnel and/or tunneling technology used for packets in that class. This framework allows a variety of tunneling technologies to be used for instantiating softwires. The choice of tunneling technology is a matter of policy, as discussed in Section 1.
策略还可能要求特定类别的通信量接收特定质量的服务，这可能会影响该类别数据包使用的隧道和/或隧道技术的选择。该框架允许使用各种隧道技术来实例化软电线。隧道技术的选择是一个政策问题，如第1节所述。
While in many cases the policy will be unconditional, e.g., "always use L2TPv3 for softwires", in other cases the policy may specify that the choice is conditional upon information about the softwire remote endpoint, e.g., "use L2TPv3 to talk to routers in class X; use GRE to talk to routers in class Y". It is desirable therefore to allow the network administration to create a small set of classes, and to configure each AFBR to be a member of one or more of these classes. If each such class is represented as a community or extended community, then [RFC5512] specifies a method that AFBRs can use to advertise their class memberships to each other.
虽然在许多情况下，该策略将是无条件的，例如，“始终使用L2TPv3进行软线”，但在其他情况下，该策略可能会指定该选择取决于关于软线远程端点的信息，例如，“使用L2TPv3与类X中的路由器通话；使用GRE与类Y中的路由器通话”。因此，希望允许网络管理创建一小组类，并将每个AFBR配置为这些类中的一个或多个的成员。如果每个这样的类都表示为一个社区或扩展社区，那么[RFC5512]指定了一个方法，AFBR可以使用该方法相互公布它们的类成员身份。
This framework also allows for policies of arbitrary complexity, which may depend on characteristics or attributes of individual address prefixes as well as on QoS or security considerations. However, the specification of such policies is not within the scope of this document.
该框架还允许具有任意复杂性的策略，这可能取决于单个地址前缀的特征或属性以及QoS或安全考虑。但是，此类政策的规范不在本文件的范围内。
Suppose it has been decided to send a given packet through a softwire. Routing provides the address, in the address family of the transport network, of the BGP next hop. The packet MUST be sent through a softwire whose remote endpoint address is the same as the BGP next hop address.
假设已决定通过软线发送给定的数据包。路由在传输网络的地址族中提供BGP下一跳的地址。数据包必须通过软线发送，其远程端点地址与BGP下一跳地址相同。
Sending a packet through a softwire is a matter of first encapsulating the packet with an encapsulation header that can be processed by the transit network and then transmitting towards the softwire's remote endpoint address.
通过软线发送分组是首先用可由传输网络处理的封装报头封装分组，然后向软线的远程端点地址发送的问题。
In many cases, once one knows the remote endpoint address, one has all the information one needs in order to form the encapsulation header. This will be the case if the tunnel technology instantiating the softwire is, e.g., LDP-based MPLS, IP-in-IP, or GRE without optional header fields.
在许多情况下，一旦知道远程端点地址，就拥有形成封装头所需的所有信息。如果实例化软线的隧道技术例如是基于LDP的MPLS、IP-in-IP或没有可选报头字段的GRE，则情况将是这样。
If the tunnel technology being used is L2TPv3 or GRE with optional header fields, additional information from the remote endpoint is needed in order to form the encapsulation header. The procedures for sending and receiving this information are described in [RFC5512].
如果使用的隧道技术是L2TPv3或GRE，带有可选的头字段，则需要来自远程端点的附加信息以形成封装头。[RFC5512]中描述了发送和接收此信息的过程。
If the tunnel technology being used is RSVP-TE-based MPLS or IPsec, the native signaling procedures of those technologies will need to be used.
如果使用的隧道技术是基于RSVP-TE的MPLS或IPsec，则需要使用这些技术的本机信令过程。
If the packet being sent through the softwire matches a route in the labeled IPv4 or labeled IPv6 address families, it should be sent through the softwire as an MPLS packet with the corresponding label. Note that most of the tunneling technologies mentioned in this document are capable of carrying MPLS packets, so this does not presuppose support for MPLS in the core routers.
如果通过软线发送的数据包与标记的IPv4或标记的IPv6地址系列中的路由匹配，则应将其作为带有相应标签的MPLS数据包通过软线发送。请注意，本文档中提到的大多数隧道技术都能够承载MPLS数据包，因此这并不意味着在核心路由器中支持MPLS。
Softwires are essentially tunnels connecting routers. If they disappear or degrade in performance, then connectivity through those tunnels will be impacted. There are several techniques available to monitor the status of the tunnel endpoints (AFBRs) as well as the tunnels themselves. These techniques allow operations such as softwire path tracing, remote softwire endpoint pinging, and remote softwire endpoint liveness failure detection.
软线本质上是连接路由器的隧道。如果它们消失或性能下降，那么通过这些通道的连接将受到影响。有几种技术可用于监控隧道端点（AFBR）以及隧道本身的状态。这些技术允许软线路径跟踪、远程软线端点ping和远程软线端点活动性故障检测等操作。
Examples of techniques applicable to softwire OAM include:
适用于软线OAM的技术示例包括：
o BGP/TCP timeouts between AFBRs
o AFBR之间的BGP/TCP超时
o ICMP or LSP echo request and reply addressed to a particular AFBR
o ICMP或LSP回送请求和回复地址为特定AFBR
o BFD (Bidirectional Forwarding Detection) [BFD] packet exchange between AFBR routers
o BFD（双向转发检测）[BFD]AFBR路由器之间的数据包交换
Another possibility for softwire OAM is to build something similar to [RFC4378] or, in other words, to create and generate softwire echo request/reply packets. The echo request sent to a well-known UDP port would contain the egress AFBR IP address and the softwire identifier as the payload (similar to the MPLS Forwarding Equivalence
软线OAM的另一种可能性是构建类似于[RFC4378]的东西，或者换句话说，创建和生成软线回送请求/应答包。发送到众所周知的UDP端口的回显请求将包含出口AFBR IP地址和软线标识符作为有效负载（类似于MPLS转发等价物）
Class contained in the LSP echo request). The softwire echo packet would be encapsulated with the encapsulation header and forwarded across the same path (inband) as that of the softwire itself.
类（包含在LSP回显请求中）。软线回波包将用封装报头封装，并通过与软线本身相同的路径（带内）转发。
This mechanism can also be automated to periodically verify remote softwire endpoint reachability, with the loss of reachability being signaled to the softwire application on the local AFBR, thus enabling suitable actions to be taken. Consideration must be given to the trade-offs between the scalability of such mechanisms versus the time required for detection of loss of endpoint reachability for such automated mechanisms.
该机制还可以被自动化，以周期性地验证远程软线端点的可达性，将可达性的损失通知给本地AFBR上的软线应用程序，从而能够采取适当的措施。必须考虑这种机制的可伸缩性与检测这种自动化机制的端点可达性损失所需的时间之间的权衡。
In general, a framework for softwire OAM can, for a large part, be based on the [RFC4176] framework.
通常，软线OAM框架在很大程度上可以基于[RFC4176]框架。
Specific MIBs do exist to manage elements of the Softwire Mesh Framework. However, there will be a need to either extend these MIBs or create new ones that reflect the functional elements that can be SNMP-managed within the softwire network.
确实存在特定的MIB来管理Softwire Mesh框架的元素。但是，需要扩展这些MIB或创建新的MIB，以反映可在softwire网络中进行SNMP管理的功能元素。
A set of client networks, running E-IP, that are connected to a provider's I-IP transit core may wish to run IP multicast applications. Extending IP multicast connectivity across the transit core can be done in a number of ways, each with a different set of characteristics. Most (though not all) of the possibilities are either slight variations of the procedures defined for L3VPNs in [L3VPN-MCAST].
连接到提供商的I-IP传输核心的一组运行E-IP的客户端网络可能希望运行IP多播应用程序。跨传输核心扩展IP多播连接可以通过多种方式完成，每种方式都具有不同的特征集。大多数（尽管不是全部）可能是[L3VPN-MCAST]中为L3VPN定义的过程的微小变化。
We will focus on supporting those multicast features and protocols that are typically used across inter-provider boundaries. Support is provided for PIM-SM (Protocol Independent Multicast - Sparse Mode) and PIM-SSM (PIM Source-Specific Mode). Support for BIDIR-PIM (Bidirectional PIM), BSR (Bootstrap Router Mechanism for PIM), and AutoRP (Automatic Rendezvous Point Determination) is not provided as these features are not typically used across inter-provider boundaries.
我们将重点支持通常跨提供商边界使用的多播功能和协议。支持PIM-SM（协议独立多播-稀疏模式）和PIM-SSM（PIM源特定模式）。未提供对BIDIR-PIM（双向PIM）、BSR（PIM引导路由器机制）和AutoRP（自动会合点确定）的支持，因为这些功能通常不跨提供商间边界使用。
In the "one-to-one mapping" scheme, each client multicast tree is extended through the transit core so that for each client tree there is exactly one tree through the core.
在“一对一映射”方案中，每个客户端多播树都通过传输核心进行扩展，因此对于每个客户端树，只有一棵树通过核心。
The one-to-one scheme is not used in [L3VPN-MCAST] because it requires an amount of state in the core routers that is proportional to the number of client multicast trees passing through the core. In the VPN context, this is considered undesirable because the amount of state is unbounded and out of the control of the service provider. However, the one-to-one scheme models the typical "Internet multicast" scenario where the client network and the transit core are both IPv4 or both IPv6. If it scales satisfactorily for that case, it should also scale satisfactorily for the case where the client network and the transit core support different versions of IP.
[L3VPN-MCAST]中未使用一对一方案，因为它要求核心路由器中的状态量与通过核心的客户端多播树的数量成比例。在VPN上下文中，这被认为是不可取的，因为状态量是无限制的，并且不受服务提供商的控制。然而，一对一方案模拟了典型的“Internet多播”场景，其中客户端网络和传输核心都是IPv4或IPv6。如果在这种情况下，它的扩展令人满意，那么在客户端网络和传输核心支持不同版本的IP的情况下，它的扩展也应该令人满意。
When an AFBR receives an E-IP PIM control message from one of its CEs, it translates it from E-IP to I-IP, and forwards it towards the source of the tree. Since the routers in the transit core will not generally have a route to the source of the tree, the AFBR must include an "RPF (Reverse Path Forwarding) Vector" [RFC5496] in the PIM message.
当AFBR从其一个CE接收到E-IP PIM控制消息时，它将其从E-IP转换为I-IP，并将其转发到树的源。由于传输核心中的路由器通常不会有到树源的路由，因此AFBR必须在PIM消息中包含“RPF（反向路径转发）向量”[RFC5496]。
Suppose an AFBR A receives an E-IP PIM Join/Prune message from a CE for either an (S,G) tree or a (*,G) tree. The AFBR would have to "translate" the PIM message into an I-IP PIM message. It would then send it to the neighbor that is the next hop along the route to the root of the (S,G) or (*,G) tree. In the case of an (S,G) tree, the root of the tree is S; in the case of a (*,G) tree, the root of the tree is the Rendezvous Point (RP) for the group G.
假设AFBR A从CE接收（S，G）树或（*，G）树的E-IP PIM加入/删减消息。AFBR必须将PIM消息“翻译”为I-IP PIM消息。然后它会将它发送给邻居，邻居是（S，G）或（*，G）树根路径上的下一个跃点。对于（S，G）树，树的根是S；对于（*，G）树，树的根是G组的集合点（RP）。
Note that the address of the root of the tree will be an E-IP address. Since the routers within the transit core (other than the AFBRs) do not have routes to E-IP addresses, A must put an RPF Vector [RFC5496] in the PIM Join/Prune message that it sends to its upstream neighbor. The RPF Vector will identify, as an I-IP address, the AFBR B that is the egress point in the transit network along the route to the root of the multicast tree. AFBR B is AFBR A's BGP next hop for the route to the root of the tree. The RPF Vector allows the core routers to forward PIM Join/Prune messages upstream towards the root of the tree, even though they do not maintain E-IP routes.
请注意，树的根地址将是一个E-IP地址。由于传输核心内的路由器（AFBR除外）没有到E-IP地址的路由，A必须在发送给其上游邻居的PIM加入/删减消息中放入RPF向量[RFC5496]。RPF向量将识别作为I-IP地址的AFBR B，该AFBR B是沿着多播树根的路由的传输网络中的出口点。AFBR B是AFBR A到树根的路由的BGP下一跳。RPF向量允许核心路由器将PIM加入/删减消息向上游转发到树的根，即使它们不维护E-IP路由。
In order to translate an E-IP PIM message into an I-IP PIM message, the AFBR A must translate the address of S (in the case of an (S,G) group) or the address of G's RP from the E-IP address family to the I-IP address family, and the AFBR B must translate them back.
为了将E-IP PIM消息转换为I-IP PIM消息，AFBR A必须将S的地址（在（S，G）组的情况下）或G的RP的地址从E-IP地址族转换为I-IP地址族，并且AFBR B必须将其转换回。
In the case where E-IP is IPv4 and I-IP is IPv6, it may be possible to do this translation algorithmically. A can translate the IPv4 S into the corresponding IPv4-mapped IPv6 address [RFC4291], and then B can translate it back. At the time of this writing, there is no such
在E-IP是IPv4而I-IP是IPv6的情况下，可以通过算法进行转换。A可以将IPv4转换为相应的IPv4映射IPv6地址[RFC4291]，然后B可以将其转换回。在撰写本文时，还没有这样的情况
thing as an IPv4-mapped IPv6 multicast address, but if such a thing were to be standardized, then A could also translate the IPv4 G into IPv6, and B could translate it back. The precise circumstances under which these translations are to be done would be a matter of policy.
作为一个IPv4映射的IPv6多播地址，但如果这样一个东西被标准化，那么a也可以将IPv4 G转换为IPv6，B可以将其转换回IPv6。在何种具体情况下进行这些翻译将是一个政策问题。
Obviously, this translation procedure does not generalize to the case where the client multicast is IPv6 but the core is IPv4. To handle that case, one needs additional signaling between the two AFBRs. Each downstream AFBR needs to signal the upstream AFBR that it needs a multicast tunnel for (S,G). The upstream AFBR must then assign a multicast address G' to the tunnel and inform the downstream of the P-G value to use. The downstream AFBR then uses PIM/IPv4 to join the (S',G') tree, where S' is the IPv4 address of the upstream ASBR (Autonomous System Border Router).
显然，此转换过程并不适用于客户端多播是IPv6，而核心是IPv4的情况。要处理这种情况，需要两个AFBR之间的附加信令。每个下游AFBR需要向上游AFBR发出信号，表示它需要（S，G）的多播隧道。然后，上游AFBR必须将多播地址G'分配给隧道，并通知下游要使用的P-G值。然后，下游AFBR使用PIM/IPv4加入（S'，G'）树，其中S'是上游ASBR（自治系统边界路由器）的IPv4地址。
The (S',G') trees should be SSM trees.
（S'，G'）树应为SSM树。
This procedure can be used to support client multicasts of either IPv4 or IPv6 over a transit core of the opposite protocol. However, it only works when the client multicasts are SSM, since it provides no method for mapping a client "prune a source off the (*,G) tree" operation into an operation on the (S',G') tree. This method also requires additional signaling. The BGP-based signaling of [L3VPN-MCAST-BGP] is one signaling method that could be used. Other signaling methods could be defined as well.
此过程可用于通过相反协议的传输核心支持IPv4或IPv6的客户端多播。但是，它仅在客户端多播为SSM时工作，因为它没有提供将客户端“从（*，G）树上修剪源”操作映射到（S'，G'）树上操作的方法。此方法还需要额外的信令。[L3VPN-MCAST-BGP]基于BGP的信令是一种可以使用的信令方法。也可以定义其他信令方法。
LDP extensions for point-to-multipoint and multipoint-to-multipoint LSPs are specified in [MLDP]; we will use the term "mLDP" to refer to those LDP extensions. If the transit core implements mLDP and supports multicast MPLS, then client Source-Specific Multicast (SSM) trees can be mapped one-to-one onto P2MP (Point-to-Multipoint) LSPs.
[MLDP]中规定了点对多点和多点对多点LSP的LDP扩展；我们将使用术语“mLDP”来指那些LDP扩展。如果transit core实现mLDP并支持多播MPL，则客户端源特定多播（SSM）树可以一对一映射到P2MP（点对多点）LSP。
When an AFBR A receives an E-IP PIM Join/Prune message for (S,G) from one of its CEs, where G is an SSM group, it would use mLDP to join a P2MP LSP. The root of the P2MP LSP would be the AFBR B that is A's BGP next hop on the route to S. In mLDP, a P2MP LSP is uniquely identified by a combination of its root and an "FEC (Forwarding Equivalence Class) identifier". The original (S,G) can be algorithmically encoded into the FEC identifier so that all AFBRs that need to join the P2MP LSP for (S,G) will generate the same FEC identifier. When the root of the P2MP LSP (AFBR B) receives such an mLDP message, it extracts the original (S,G) from the FEC identifier, creates an "ordinary" E-IP PIM Join/Prune message, and sends it to the CE that is its next hop on the route to S.
当AFBR A从其一个CE（其中G是SSM组）接收到（S，G）的E-IP PIM加入/删减消息时，它将使用mLDP加入P2MP LSP。P2MP LSP的根将是AFBR B，它是A在到s的路由上的下一跳BGP。在mLDP中，P2MP LSP由其根和“FEC（转发等价类）标识符”的组合唯一标识。原始（S，G）可以通过算法编码到FEC标识符中，以便需要加入（S，G）的P2MP LSP的所有afbr将生成相同的FEC标识符。当P2MP LSP（AFBR B）的根接收到这样的mLDP消息时，它从FEC标识符中提取原始（S，G），创建一个“普通”E-IP PIM Join/Prune消息，并将其发送到作为其到S的路由上的下一跳的CE。
The method of encoding the (S,G) into the FEC identifier needs to be standardized. The encoding must be self-identifying so that a node that is the root of a P2MP LSP can determine whether a FEC identifier is the result of having encoded a PIM (S,G).
将（S，G）编码为FEC标识符的方法需要标准化。编码必须是自识别的，以便作为P2MP LSP的根的节点可以确定FEC标识符是否是编码了PIM（S，G）的结果。
The appropriate state machinery must be standardized so that PIM events at the AFBRs result in the proper mLDP events. For example, if at some point an AFBR determines (via PIM procedures) that it no longer has any downstream receivers for (S,G), the AFBR should invoke the proper mLDP procedures to prune itself off the corresponding P2MP LSP.
必须对适当的状态机制进行标准化，以便AFBR的PIM事件导致适当的mLDP事件。例如，如果AFBR在某一点（通过PIM程序）确定其不再具有（S，G）的任何下游接收器，则AFBR应调用适当的mLDP程序将其自身从相应的P2MP LSP中剪除。
Note that this method cannot be used when the G is a Sparse Mode group. The reason this method cannot be used is that mLDP does not have any function corresponding to the PIM "prune this source off the shared tree" function. So if a P2MP LSP were mapped one-to-one with a P2MP LSP, duplicate traffic could end up traversing the transit core (i.e., traffic from S might travel down both the shared tree and S's source tree). Alternatively, one could devise an AFBR-to-AFBR protocol to prune sources off the P2MP LSP at the root of the LSP. It is recommended, though, that client SM multicast groups be supported by other methods, such as those discussed below.
注意，当G是稀疏模式组时，不能使用此方法。无法使用此方法的原因是mLDP没有任何与PIM“从共享树中删除此源”功能对应的函数。因此，如果P2MP LSP与P2MP LSP一一对应，则重复的通信量最终可能会穿过传输核心（即，来自S的通信量可能会沿着共享树和S的源树向下移动）。或者，可以设计一个AFBR到AFBR协议，在LSP的根处剪除P2MP LSP的源。但是，建议客户端SM多播组由其他方法支持，如下面讨论的方法。
Client-side bidirectional multicast groups set up by PIM-bidir could be mapped using the above technique to MP2MP (Multipoint-to-Multipoint) LSPs set up by mLDP [MLDP]. We do not consider this further, as inter-provider bidirectional groups are not in use anywhere.
PIM bidir建立的客户端双向多播组可以使用上述技术映射到mLDP[mLDP]建立的MP2MP（多点对多点）LSP。我们不进一步考虑这一点，因为提供者间的双向组不在任何地方使用。
The "MVPN (Multicast VPN)-like schemes" are those described in [L3VPN-MCAST] and its companion documents (such as [L3VPN-MCAST-BGP]). To apply those schemes to the softwire environment, it is necessary only to treat all the AFBRs of a given transit core as if they were all, for multicast purposes, PE routers attached to the same VPN.
“类似MVPN（多播VPN）的方案”是在[L3VPN-MCAST]及其配套文档（如[L3VPN-MCAST-BGP]）中描述的方案。为了将这些方案应用于软线环境，只需将给定传输核心的所有AFBR视为连接到同一VPN的所有PE路由器（出于多播目的）。
The MVPN-like schemes do not require a one-to-one mapping between client multicast trees and transit-core multicast trees. In the MVPN environment, it is a requirement that the number of trees in the core scales less than linearly with the number of client trees. This requirement may not hold in the softwire scenarios.
类似MVPN的方案不需要客户端多播树和传输核心多播树之间的一对一映射。在MVPN环境中，要求核心中的树的数量与客户端树的数量成线性关系。这一要求在软线方案中可能不适用。
The MVPN-like schemes can support SM, SSM, and Bidir groups. They provide a number of options for the control plane:
类似MVPN的方案可以支持SM、SSM和Bidir组。它们为控制平面提供了许多选项：
- LAN-like
- 类局域网
Use a set of multicast trees in the core to emulate a LAN (Local Area Network) and run the client-side PIM protocol over that "LAN". The "LAN" can consist of a single Bidir tree containing all the AFBRs or a set of SSM trees, one rooted at each AFBR and containing all the other AFBRs as receivers.
在核心中使用一组多播树来模拟LAN（局域网），并在该“LAN”上运行客户端PIM协议。“LAN”可以由一个包含所有AFBR的Bidir树或一组SSM树组成，每个AFBR都有一个根，并包含所有其他AFBR作为接收器。
- NBMA (Non-Broadcast Multiple Access), using BGP
- NBMA（非广播多址），使用BGP
The client-side PIM signaling can be translated into BGP-based signaling, with a BGP Route Reflector mediating the signaling.
客户端PIM信令可以转换为基于BGP的信令，BGP路由反射器调解信令。
These two basic options admit of many variations; a comprehensive discussion is in [L3VPN-MCAST].
这两个基本选择允许许多变化；[L3VPN-MCAST]中有全面的讨论。
For the data plane, there are also a number of options:
对于数据平面，还有许多选项：
- All multicast data sent over the emulated LAN. This particular option is not very attractive, though, for the softwire scenarios, as every AFBR would have to receive every client multicast packet.
- 通过模拟LAN发送的所有多播数据。但是，对于软线场景，此特定选项不是很有吸引力，因为每个AFBR都必须接收每个客户端多播数据包。
- Every multicast group mapped to a tree that is considered appropriate for that group, in the sense of causing the traffic of that group to go to "too many" AFBRs that don't need to receive it.
- 映射到一棵树的每个多播组都被认为适合该组，这意味着该组的流量流向“太多”不需要接收它的AFBR。
Again, a comprehensive discussion of the issues can be found in [L3VPN-MCAST].
关于这些问题的全面讨论，请参见[L3VPN-MCAST]。
We have so far only considered the case where a "transit core" consists of a single Autonomous System (AS). If the transit core consists of multiple ASes, then it may be necessary to use softwires whose endpoints are AFBRs attached to different Autonomous Systems. In this case, the AFBR at the remote endpoint of a softwire is not the BGP next hop for packets that need to be sent on the softwire. Since the procedures described above require the address of a remote softwire endpoint to be the same as the address of the BGP next hop, those procedures do not work as specified when the transit core consists of multiple ASes.
到目前为止，我们只考虑了“运输核心”由单个自治系统（AS）组成的情况。如果传输核心由多个ASE组成，则可能需要使用其端点为连接到不同自治系统的AFBR的软线。在这种情况下，软导线远程端点处的AFBR不是需要在软导线上发送的分组的BGP下一跳。由于上述过程要求远程软线端点的地址与BGP下一跳的地址相同，因此当传输核心由多个ASE组成时，这些过程不按规定工作。
There are several ways to deal with this situation.
有几种方法可以处理这种情况。
1. Don't do it; require that there be AFBRs at the edge of each AS so that a transit core does not extend more than one AS.
1. 不要这样做；要求每个AS的边缘有AFBR，以便运输核心不会延伸超过一个AS。
2. Use multi-hop EBGP to allow AFBRs to send BGP routes to each other, even if the ABFRs are not in the same or in neighboring ASes.
2. 使用多跳EBGP允许AFBR相互发送BGP路由，即使ABFR不在同一个ASE或相邻ASE中。
3. Ensure that an ASBR that is not an AFBR does not change the next hop field of the routes for which encapsulation is needed.
3. 确保非AFBR的ASBR不会更改需要封装的路由的下一跳字段。
In the latter two cases, BGP recursive next hop resolution needs to be done, and encapsulations may need to be "stacked" (i.e., multiple layers of encapsulation may need to be used).
在后两种情况下，需要进行BGP递归下一跳解析，封装可能需要“堆叠”（即，可能需要使用多层封装）。
For instance, consider packet P with destination IP address D. Suppose it arrives at ingress AFBR A1 and that the route that is the best match for D has BGP next hop B1. So A1 will encapsulate the packet for delivery to B1. If B1 is not within A1's AS, A1 will need to look up the route to B1 and then find the BGP next hop, call it B2, of that route. If the interior routers of A1's AS do not have routes to B1, then A1 needs to encapsulate the packet a second time, this time for delivery to B2.
例如，考虑分组IP与目的IP地址D。假设它到达入口AFBR A1，并且与D最佳匹配的路由具有BGP下一跳B1。因此，A1将封装数据包以交付给B1。如果B1不在A1的AS内，A1将需要查找到B1的路由，然后找到该路由的BGP下一跳，称之为B2。如果A1 AS的内部路由器没有到B1的路由，则A1需要第二次封装数据包，这一次用于传送到B2。
In the Softwire Mesh Framework, the data packets that are encapsulated are E-IP data packets that are traveling through the Internet. These data packets (the softwire "payload") may or may not need such security features as authentication, integrity, confidentiality, or replay protection. However, the security needs of the payload packets are independent of whether or not those packets are traversing softwires. The fact that a particular payload packet is traveling through a softwire does not in any way affect its security needs.
在Softwire Mesh框架中，封装的数据分组是在因特网上传输的E-IP数据分组。这些数据包（软线“有效载荷”）可能需要也可能不需要诸如认证、完整性、机密性或重播保护之类的安全特性。然而，有效载荷分组的安全需求与这些分组是否正在穿越软线无关。一个特定的有效载荷数据包通过软线传输的事实不会以任何方式影响其安全需求。
Thus, the only security issues we need to consider are those that affect the I-IP encapsulation headers, rather than those that affect the E-IP payload.
因此，我们需要考虑的唯一安全问题是影响i-IP封装头的那些问题，而不是影响E-IP有效载荷的问题。
Since the encapsulation headers determine the routing of packets traveling through softwires, they must appear "in the clear".
由于封装头决定了通过软线传输的数据包的路由，因此它们必须显示为“透明”。
In the Softwire Mesh Framework, for each receiving endpoint of a tunnel, there are one or more "valid" transmitting endpoints, where the valid transmitting endpoints are those that are authorized to tunnel packets to the receiving endpoint. If the encapsulation header has no guarantee of authentication or integrity, then it is possible to have spoofing attacks, in which unauthorized nodes send
在软线网格框架中，对于隧道的每个接收端点，存在一个或多个“有效”发射端点，其中有效发射端点是被授权将分组隧道到接收端点的端点。如果封装头无法保证身份验证或完整性，则可能会发生欺骗攻击，其中未经授权的节点发送
encapsulated packets to the receiving endpoint, giving the receiving endpoint the invalid impression the encapsulated packets have really traveled through the softwire. Replay attacks are also possible.
将封装的数据包发送到接收端点，给接收端点一种无效的印象，即封装的数据包实际上已经通过了软线。重播攻击也是可能的。
The effect of such attacks is somewhat limited, though. The receiving endpoint of a softwire decapsulates the payload and does further routing based on the IP destination address of the payload. Since the payload packets are traveling through the Internet, they have addresses from the globally unique address space (rather than, e.g., from a private address space of some sort). Therefore, these attacks cannot cause payload packets to be delivered to an address other than the one appearing in the destination IP address field of the payload packet.
不过，这种攻击的效果有些有限。软线的接收端点解除有效载荷的封装，并基于有效载荷的IP目的地地址进行进一步路由。由于有效载荷分组在因特网上传输，因此它们具有来自全局唯一地址空间的地址（而不是，例如，来自某种私有地址空间）。因此，这些攻击不能导致有效负载数据包被传送到有效负载数据包的目标IP地址字段中出现的地址之外的地址。
However, attacks of this sort can result in policy violations. The authorized transmitting endpoint(s) of a softwire may be following a policy according to which only certain payload packets get sent through the softwire. If unauthorized nodes are able to encapsulate the payload packets so that they arrive at the receiving endpoint looking as if they arrived from authorized nodes, then the properly authorized policies have been side-stepped.
但是，此类攻击可能导致违反策略。软线的授权发送端点可以遵循仅通过软线发送特定有效载荷分组的策略。如果未经授权的节点能够封装有效负载数据包，以便它们到达接收端点时看起来就像它们是从授权节点到达的，那么正确授权的策略就被忽略了。
Attacks of the sort we are considering can also be used in denial-of-service attacks on the receiving tunnel endpoints. However, such attacks cannot be prevented by use of cryptographic authentication/integrity techniques, as the need to do cryptography on spoofed packets only makes the denial-of-service problem worse. (The assumption is that the cryptography mechanisms are likely to be more costly than the decapsulation/forwarding mechanisms. So if one tries to eliminate a flooding attack on the decapsulation/forwarding mechanisms by discarding packets that do not pass a cryptographic integrity test, one ends up just trading one kind of attack for another.)
我们正在考虑的这类攻击也可用于对接收隧道端点的拒绝服务攻击。然而，使用加密身份验证/完整性技术无法防止此类攻击，因为需要对伪造的数据包进行加密只会使拒绝服务问题更加严重。（假设加密机制的成本可能高于去封装/转发机制。因此，如果一个人试图通过丢弃未通过加密完整性测试的数据包来消除对去封装/转发机制的泛洪攻击，他最终只会以一种攻击换取另一种攻击。）
This section is largely based on the security considerations section of RFC 4023, which also deals with encapsulations and tunnels.
本节主要基于RFC4023的安全注意事项部分，该部分还涉及封装和隧道。
If a tunnel lies entirely within a single administrative domain, then, to a certain extent, there are certain non-cryptographic techniques one can use to prevent spoofed packets from reaching a tunnel's receiving endpoint. For example, when the tunnel encapsulation is IP-based:
如果隧道完全位于单个管理域内，那么在一定程度上，可以使用某些非加密技术来防止伪造数据包到达隧道的接收端点。例如，当隧道封装基于IP时：
- The receiving endpoints of the tunnels can be given a distinct set of addresses, and those addresses can be made known to the border routers. The border routers can then filter out packets, destined to those addresses, that arrive from outside the domain.
- 隧道的接收端点可以被赋予一组不同的地址，这些地址可以让边界路由器知道。然后，边界路由器可以过滤掉从域外到达这些地址的数据包。
- The transmitting endpoints of the tunnels can be given a distinct set of addresses, and those addresses can be made known to the border routers and to the receiving endpoints of the tunnels. The border routers can filter out all packets arriving from outside the domain with source addresses that are in this set, and the receiving endpoints can discard all packets that appear to be part of a softwire, but whose source addresses are not in this set.
- 隧道的发送端点可以被赋予一组不同的地址，并且这些地址可以被边界路由器和隧道的接收端点知道。边界路由器可以过滤掉所有从域外到达且源地址在此集合中的包，并且接收端点可以丢弃看起来是软线的一部分但其源地址不在此集合中的所有包。
If an MPLS-based encapsulation is used, the border routers can refuse to accept MPLS packets from outside the domain, or they can refuse to accept such MPLS packets whenever the top label corresponds to the address of a tunnel receiving endpoint.
如果使用基于MPLS的封装，则边界路由器可以拒绝接受来自域外的MPLS分组，或者只要顶部标签对应于隧道接收端点的地址，边界路由器就可以拒绝接受此类MPLS分组。
These techniques assume that, within a domain, the network is secure enough to prevent the introduction of spoofed packets from within the domain itself. That may not always be the case. Also, these techniques can be difficult or impossible to use effectively for tunnels that are not in the same administrative domain.
这些技术假设，在一个域内，网络足够安全，可以防止从域本身引入伪造的数据包。情况可能并非总是如此。此外，这些技术可能难以或不可能有效地用于不在同一管理领域的隧道。
A different technique is to have the encapsulation header contain a cleartext password. The 64-bit "cookie" of L2TPv3 [RFC3931] is sometimes used in this way. This can be useful within an administrative domain if it is regarded as infeasible for an attacker to spy on packets that originate in the domain and that do not leave the domain. An attacker would then not be able to discover the password. An attacker could, of course, try to guess the password, but if the password is an arbitrary 64-bit binary sequence, brute force attacks that run through all the possible passwords would be infeasible. This technique may be easier to manage than ingress filtering is, and may be just as effective if the assumptions hold. Like ingress filtering, though, it may not be applicable for tunnels that cross domain boundaries.
另一种技术是让封装头包含明文密码。L2TPv3[RFC3931]的64位“cookie”有时以这种方式使用。如果攻击者无法监视源自域且未离开域的数据包，则这在管理域中非常有用。攻击者将无法发现密码。当然，攻击者可以尝试猜测密码，但如果密码是任意64位二进制序列，则无法对所有可能的密码进行暴力攻击。这种技术可能比入口过滤更容易管理，如果假设成立，也可能同样有效。不过，与入口过滤一样，它可能不适用于跨域边界的隧道。
Therefore, it is necessary to also consider the use of cryptographic techniques for setting up the tunnels and for passing data through them.
因此，还需要考虑使用密码技术来建立隧道并通过它们传递数据。
If the path between the two endpoints of a tunnel is not adequately secure, then:
如果隧道两个端点之间的路径不够安全，则：
- If a control protocol is used to set up the tunnels (e.g., to inform one tunnel endpoint of the IP address of the other), the control protocol MUST have an authentication mechanism, and this MUST be used when the tunnel is set up. If the tunnel is set up automatically as the result of, for example, information distributed by BGP, then the use of BGP's MD5-based authentication mechanism [RFC2385] is satisfactory.
- 如果使用控制协议设置隧道（例如，通知一个隧道端点另一个的IP地址），则控制协议必须具有身份验证机制，并且在设置隧道时必须使用该机制。例如，如果隧道是根据BGP分发的信息自动设置的，那么使用BGP基于MD5的身份验证机制[RFC2385]是令人满意的。
- Data transmission through the tunnel should be secured with IPsec. In the remainder of this section, we specify the way IPsec may be used, and the implementation requirements we mention are meant to be applicable whenever IPsec is being used.
- 通过隧道的数据传输应使用IPsec进行保护。在本节的其余部分中，我们将指定使用IPsec的方式，以及我们提到的实现要求，以便在使用IPsec时适用。
We consider only the case where IPsec is used together with an IP-based tunneling mechanism. Use of IPsec with an MPLS-based tunneling mechanism is for further study.
我们仅考虑IPSec与基于IP的隧道机制一起使用的情况。将IPsec与基于MPLS的隧道机制结合使用有待进一步研究。
If it is deemed necessary to use tunnels that are protected by IPsec, the tunnel type SHOULD be negotiated by the tunnel endpoints using the procedures specified in [RFC5566]. That document allows the use of IPsec tunnel mode but also allows one to treat the tunnel head and the tunnel tail as the endpoints of a Security Association, and to use IPsec transport mode.
如果认为有必要使用受IPsec保护的隧道，则隧道端点应使用[RFC5566]中指定的过程协商隧道类型。该文档允许使用IPsec隧道模式，但也允许将隧道头和隧道尾视为安全关联的端点，并使用IPsec传输模式。
In order to use IPsec transport mode, encapsulated packets should be viewed as originating at the tunnel head and as being destined for the tunnel tail. A single IP address of the tunnel head will be used as the source IP address, and a single IP address of the tunnel tail will be used as the destination IP address. This technique can be used to carry MPLS packets through an IPsec Security Association, by first encapsulating the MPLS packets in MPLS-in-IP or MPLS-in-GRE [RFC4023] and then applying IPsec transport mode.
为了使用IPsec传输模式，应将封装的数据包视为源于隧道头，目的地为隧道尾。隧道头的单个IP地址将用作源IP地址，隧道尾的单个IP地址将用作目标IP地址。此技术可用于通过IPsec安全关联携带MPLS数据包，方法是首先将MPLS数据包封装在IP中的MPLS或GRE[RFC4023]中的MPLS中，然后应用IPsec传输模式。
When IPsec is used to secure softwires, IPsec MUST provide authentication and integrity. Thus, the implementation MUST support either ESP (IP Encapsulating Security Payload) with null encryption [RFC4303] or else AH (IP Authentication Header) [RFC4302]. ESP with encryption MAY be supported. If ESP is used, the tunnel tail MUST check that the source IP address of any packet received on a given SA (IPsec Security Association) is the one expected, as specified in Section 5.2, step 4, of [RFC4301].
当IPsec用于保护软电线时，IPsec必须提供身份验证和完整性。因此，实现必须支持带有空加密[RFC4303]的ESP（IP封装安全有效负载）或AH（IP认证头）[RFC4302]。可能支持带加密的ESP。如果使用ESP，则隧道尾部必须检查在给定SA（IPsec安全关联）上接收的任何数据包的源IP地址是否为预期的IP地址，如[RFC4301]第5.2节步骤4所述。
Since the softwires are set up dynamically as a byproduct of passing routing information, key distribution MUST be done automatically by means of IKEv2 [RFC4306]. If a PKI (Public Key Infrastructure) is not available, the IPsec Tunnel Authenticator sub-TLV described in [RFC5566] MUST be used and validated before setting up an SA.
由于软线是作为传递路由信息的副产品动态设置的，因此密钥分配必须通过IKEv2[RFC4306]自动完成。如果PKI（公钥基础设施）不可用，则在设置SA之前，必须使用[RFC5566]中描述的IPsec隧道身份验证子TLV并进行验证。
The selectors associated with the SA are the source and destination addresses of the encapsulation header, along with the IP protocol number representing the encapsulation protocol being used.
与SA关联的选择器是封装头的源地址和目标地址，以及表示所用封装协议的IP协议号。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931]Lau，J.，Ed.，Townsley，M.，Ed.，和I.Goyret，Ed.，“第二层隧道协议-版本3（L2TPv3）”，RFC 39312005年3月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4023]Worster，T.，Rekhter，Y.，和E.Rosen，编辑，“在IP或通用路由封装（GRE）中封装MPLS”，RFC4023，2005年3月。
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, April 2009.
[RFC5512]Mohapatra，P.和E.Rosen，“BGP封装后续地址族标识符（SAFI）和BGP隧道封装属性”，RFC 5512，2009年4月。
[RFC5566] Berger, L., White, R. and E. Rosen, "BGP IPsec Tunnel Encapsulation Attribute", RFC 5566, June 2009.
[RFC5566]Berger，L.，White，R.和E.Rosen，“BGP IPsec隧道封装属性”，RFC 5566，2009年6月。
[V4NLRI-V6NH] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop", RFC 5549, May 2009.
[V4NLRI-V6NH]Le Faucheur，F.和E.Rosen，“通过IPv6下一跳发布IPv4网络层可达性信息”，RFC 5549，2009年5月。
[V6NLRI-V4NH] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
[V6NLRI-V4NH]De Clercq，J.，Ooms，D.，Prevost，S.，和F.Le Faucheur，“使用IPv6提供商边缘路由器（6PE）通过IPv4 MPLS连接IPv6孤岛”，RFC 4798，2007年2月。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, February 2009.
[BFD]Katz，D.和D.Ward，“双向转发检测”，正在进行的工作，2009年2月。
[L3VPN-MCAST] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", Work in Progress, March 2009.
[L3VPN-MCAST]Rosen，E.，Ed.，和R.Aggarwal，Ed.，“MPLS/BGP IP VPN中的多播”，正在进行的工作，2009年3月。
[L3VPN-MCAST-BGP] Aggarwal, R., Rosen, E., Morin, T. and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", Work in Progress, April 2009.
[L3VPN-MCAST-BGP]Aggarwal，R.，Rosen，E.，Morin，T.和Y.Rekhter，“MPLS/BGP IP VPN中多播的BGP编码和过程”，正在进行的工作，2009年4月。
[MLDP] Minei, I., Ed., Kompella, K., Wijnands, IJ., Ed., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Work in Progress, April 2009.
[MLDP]Minei，I.，Ed.，Kompella，K.，Wijnands，IJ.，Ed.，和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，正在进行的工作，2009年4月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 11951990年12月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., and A. Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management", RFC 4176, October 2005.
[RFC4176]El Mghazli，Y.，Ed.，Nadeau，T.，Boucadair，M.，Chan，K.，和A.Gonguet，“第三层虚拟专用网络（L3VPN）运营和管理框架”，RFC 41762005年10月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC4378] Allan, D., Ed., and T. Nadeau, Ed., "A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, February 2006.
[RFC4378]Allan，D.，Ed.，和T.Nadeau，Ed.，“多协议标签交换（MPLS）操作和管理（OAM）框架”，RFC 4378，2006年2月。
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, April 2006.
[RFC4459]Savola，P.，“网络隧道中的MTU和碎片问题”，RFC 4459，2006年4月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年10月。
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
[RFC5496]Wijnands，IJ.，Boers，A.，和E.Rosen，“反向路径转发（RPF）向量TLV”，RFC 54962009年3月。
[SW-PROB] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. Durand, Ed., "Softwire Problem Statement", RFC 4925, July 2007.
[SW-PROB]Li，X.，Ed.，Dawkins，S.，Ed.，Ward，D.，Ed.，和A.Durand，Ed.，“软线问题声明”，RFC 49252007年7月。
Xing Li Tsinghua University Department of Electronic Engineering, Tsinghua University Beijing 100084 P.R.China
邢莉清华大学电子工程系，清华大学北京100084
Phone: +86-10-6278-5983
EMail: xing@cernet.edu.cn
Phone: +86-10-6278-5983
EMail: xing@cernet.edu.cn
Simon Barber Cisco Systems, Inc. 250 Longwater Avenue Reading, ENGLAND, RG2 6GB United Kingdom
Simon Barber Cisco Systems，Inc.英国朗沃特大道250号雷丁，RG2 6GB
EMail: sbarber@cisco.com
EMail: sbarber@cisco.com
Pradosh Mohapatra Cisco Systems, Inc. 3700 Cisco Way San Jose, CA 95134 USA
Pradosh Mohapatra Cisco Systems，Inc.美国加利福尼亚州圣何塞市思科大道3700号，邮编95134
EMail: pmohapat@cisco.com
EMail: pmohapat@cisco.com
John Scudder Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA
美国加利福尼亚州桑尼维尔北马蒂尔达大道1194号约翰·斯卡德尔·朱尼珀网络公司，邮编94089
EMail: jgs@juniper.net
EMail: jgs@juniper.net
David Ward, Chris Cassar, Gargi Nalawade, Ruchi Kapoor, Pranav Mehta, Mingwei Xu, and Ke Xu provided useful input into this document.
David Ward、Chris Cassar、Gargi Nalawade、Ruchi Kapoor、Pranav Mehta、Mingwei Xu和Ke Xu为本文件提供了有用的输入。
Authors' Addresses
作者地址
Jianping Wu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China
吴建平清华大学计算机科学系，清华大学北京100084
Phone: +86-10-6278-5983
EMail: jianping@cernet.edu.cn
Phone: +86-10-6278-5983
EMail: jianping@cernet.edu.cn
Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China
清华大学计算机科学系，清华大学北京100084
Phone: +86-10-6278-5822
EMail: yong@csnet1.cs.tsinghua.edu.cn
Phone: +86-10-6278-5822
EMail: yong@csnet1.cs.tsinghua.edu.cn
Chris Metz Cisco Systems, Inc. 3700 Cisco Way San Jose, CA 95134 USA
Chris Metz Cisco Systems，Inc.美国加利福尼亚州圣何塞市思科大道3700号，邮编95134
EMail: chmetz@cisco.com
EMail: chmetz@cisco.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA
Eric C.Rosen Cisco Systems，Inc.美国马萨诸塞州博克斯堡马萨诸塞大道1414号，邮编01719
EMail: erosen@cisco.com
EMail: erosen@cisco.com