Internet Engineering Task Force (IETF) S. Previdi, Ed.
Request for Comments: 7855 C. Filsfils, Ed.
Category: Informational Cisco Systems, Inc.
ISSN: 2070-1721 B. Decraene
S. Litkowski
Orange
M. Horneffer
Deutsche Telekom
R. Shakir
Jive Communications, Inc.
May 2016
Internet Engineering Task Force (IETF) S. Previdi, Ed.
Request for Comments: 7855 C. Filsfils, Ed.
Category: Informational Cisco Systems, Inc.
ISSN: 2070-1721 B. Decraene
S. Litkowski
Orange
M. Horneffer
Deutsche Telekom
R. Shakir
Jive Communications, Inc.
May 2016
Source Packet Routing in Networking (SPRING) Problem Statement and Requirements
网络中的源数据包路由（SPRING）问题陈述和要求
Abstract
摘要
The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions. Source-based routing mechanisms have previously been specified for network protocols but have not seen widespread adoption. In this context, the term "source" means "the point at which the explicit route is imposed"; therefore, it is not limited to the originator of the packet (i.e., the node imposing the explicit route may be the ingress node of an operator's network).
节点能够指定特定数据包将要穿越的转发路径，而不是正常的最短路径，这有利于许多网络功能。基于源的路由机制以前曾被指定用于网络协议，但尚未被广泛采用。在这种情况下，“源”一词是指“施加明确路线的点”；因此，它不限于分组的发起方（即，施加显式路由的节点可以是运营商网络的入口节点）。
This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic. Multicast use cases and requirements are out of scope for this document.
本文档概述了各种用例及其需求，这些用例需要由网络中的源数据包路由（SPRING）体系结构考虑，用于单播通信。多播用例和需求超出了本文档的范围。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见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/rfc7855.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7855.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Data Planes . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SPRING Use Cases . . . . . . . . . . . . . . . . . . . . . . 4
3.1. IGP-Based MPLS Tunneling . . . . . . . . . . . . . . . . 4
3.1.1. Example of IGP-Based MPLS Tunnels . . . . . . . . . . 5
3.2. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 5
3.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 6
3.3.1. Examples of Traffic-Engineering Use Cases . . . . . . 7
3.4. Interoperability with Non-SPRING Nodes . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. Manageability Considerations . . . . . . . . . . . . . . . . 15
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Normative References . . . . . . . . . . . . . . . . . . 16
6.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Data Planes . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SPRING Use Cases . . . . . . . . . . . . . . . . . . . . . . 4
3.1. IGP-Based MPLS Tunneling . . . . . . . . . . . . . . . . 4
3.1.1. Example of IGP-Based MPLS Tunnels . . . . . . . . . . 5
3.2. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 5
3.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 6
3.3.1. Examples of Traffic-Engineering Use Cases . . . . . . 7
3.4. Interoperability with Non-SPRING Nodes . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. Manageability Considerations . . . . . . . . . . . . . . . . 15
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Normative References . . . . . . . . . . . . . . . . . . 16
6.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
The ability for a node to specify a unicast forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions, for example:
节点能够指定特定数据包将要穿越的单播转发路径，而不是正常的最短路径，这有利于许多网络功能，例如：
o Some types of network virtualization, including multi-topology networks and the partitioning of network resources for VPNs
o 一些类型的网络虚拟化，包括多拓扑网络和VPN网络资源的分区
o Network, link, path, and node protection such as fast reroute
o 网络、链路、路径和节点保护，如快速重新路由
o Network programmability
o 网络可编程性
o OAM techniques
o OAM技术
o Simplification and reduction of network signaling components
o 简化和减少网络信令组件
o Load balancing and traffic engineering
o 负载平衡与流量工程
Source-based routing mechanisms have previously been specified for network protocols, but have not seen widespread adoption other than in MPLS traffic engineering.
基于源的路由机制以前已经被指定用于网络协议，但除了在MPLS流量工程中，还没有被广泛采用。
These network functions may require greater flexibility and more source-imposed routing than can be achieved through the use of the previously defined methods. In the context of this document, the term "source" means "the point at which the explicit route is imposed"; therefore, it is not limited to the originator of the packet (i.e., the node imposing the explicit route may be the ingress node of an operator's network). Throughout this document, we refer to this definition of "source".
与使用先前定义的方法相比，这些网络功能可能需要更大的灵活性和更多源强制路由。在本文件中，“来源”一词是指“施加明确路线的点”；因此，它不限于分组的发起方（即，施加显式路由的节点可以是运营商网络的入口节点）。在本文件中，我们引用了“来源”的定义。
In this context, Source Packet Routing in Networking (SPRING) architecture is being defined in order to address the use cases and requirements described in this document.
在这种情况下，正在定义网络（SPRING）体系结构中的源数据包路由，以解决本文档中描述的用例和需求。
The SPRING architecture MUST allow incremental and selective deployment without any requirement of a flag day or massive upgrade of all network elements.
SPRING体系结构必须允许增量和选择性部署，而不需要旗帜日或大规模升级所有网络元素。
The SPRING architecture MUST allow putting the policy state in the packet header and not in the intermediate nodes along the path. Hence, the policy is instantiated in the packet header and does not requires any policy state in midpoints and tail-ends.
SPRING体系结构必须允许将策略状态放在数据包头中，而不是路径上的中间节点中。因此，该策略在数据包头中实例化，并且不需要在中点和尾端的任何策略状态。
The SPRING architecture objective is not to replace existing source-routing and traffic-engineering mechanisms, but rather to complement them and address use cases where removal of signaling and path state in the core is a requirement.
SPRING架构的目标不是替换现有的源路由和流量工程机制，而是补充它们，并解决需要删除核心中的信令和路径状态的用例。
Multicast use cases and requirements are out of scope for this document.
多播用例和需求超出了本文档的范围。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The SPRING architecture SHOULD be general in order to ease its applicability to different data planes.
SPRING体系结构应该是通用的，以简化其对不同数据平面的适用性。
The SPRING architecture SHOULD leverage the existing MPLS data plane without any modification and leverage the IPv6 data plane with a new IPv6 Routing Header Type (IPv6 Routing Header is defined in [RFC2460]) and a proposal for a new type of routing header is made by [SRH].
SPRING体系结构应在不做任何修改的情况下利用现有的MPLS数据平面，并利用IPv6数据平面和新的IPv6路由头类型（IPv6路由头在[RFC2460]中定义），并且[SRH]提出了新类型路由头的建议。
The SPRING architecture MUST allow interoperability between SPRING-capable and non-SPRING-capable nodes in both the MPLS and IPv6 data planes.
SPRING体系结构必须允许MPLS和IPv6数据平面中支持SPRING和不支持SPRING的节点之间的互操作性。
The source-based routing model, applied to the MPLS data plane, offers the ability to tunnel services like VPN ([RFC4364]), Virtual Private LAN Service (VPLS) ([RFC4761], [RFC4762]) and Virtual Private Wire Service (VPWS) ([RFC6624]), from an ingress Provider Edge (PE) to an egress PE, with or without the expression of an explicit path and without requiring forwarding-plane or control-plane state in intermediate nodes. Point-to-multipoint and multipoint-to-multipoint tunnels are outside the scope of this document.
应用于MPLS数据平面的基于源的路由模型提供了将VPN（[RFC4364]）、虚拟专用LAN服务（VPLS）（[RFC4761]、[RFC4762]）和虚拟专用有线服务（VPWS）（[RFC6624]）等服务从入口提供商边缘（PE）隧道到出口PE的能力，具有或不具有显式路径的表达式，并且不需要中间节点中的转发平面或控制平面状态。点对多点和多点对多点隧道不在本文件范围内。
This section illustrates an example use case.
本节说明了一个示例用例。
P1---P2
/ \
A---CE1---PE1 PE2---CE2---Z
\ /
P3---P4
P1---P2
/ \
A---CE1---PE1 PE2---CE2---Z
\ /
P3---P4
Figure 1: IGP-Based MPLS Tunneling
图1：基于IGP的MPLS隧道
In Figure 1 above, the four nodes A, CE1, CE2, and Z are part of the same VPN. CE2 advertises to PE2 a route to Z. PE2 binds a local label LZ to that route and propagates the route and its label via the Multiprotocol Border Gateway Protocol (MPBGP) to PE1 with next-hop address 192.0.2.2 (i.e., the local address of PE2). PE1 installs the VPN prefix Z in the appropriate VPN Routing and Forwarding table (VRF) and resolves the next hop onto the IGP-based MPLS tunnel to PE2.
在上面的图1中，四个节点A、CE1、CE2和Z是同一VPN的一部分。CE2向PE2播发到Z的路由。PE2将本地标签LZ绑定到该路由，并通过多协议边界网关协议（MPBGP）将该路由及其标签传播到下一跳地址为192.0.2.2（即PE2的本地地址）的PE1。PE1在适当的VPN路由和转发表（VRF）中安装VPN前缀Z，并将下一跳解析到基于IGP的MPLS隧道到PE2。
To cope with the reality of current deployments, the SPRING architecture MUST allow PE-to-PE forwarding according to the IGP shortest path without the addition of any other signaling protocol. The packet each PE forwards across the network will contain the necessary information derived from the topology database in order to deliver the packet to the remote PE.
为了应对当前部署的现实，SPRING体系结构必须允许PE-To-PE根据IGP最短路径进行转发，而无需添加任何其他信令协议。每个PE通过网络转发的数据包将包含从拓扑数据库派生的必要信息，以便将数据包传送到远程PE。
Fast Reroute (FRR) technologies have been deployed by network operators in order to cope with link or node failures through precomputation of backup paths.
网络运营商已经部署了快速重路由（FRR）技术，以便通过预计算备份路径来应对链路或节点故障。
Illustration of the problem statement for FRR and micro-loop avoidance can be found in [SPRING-RESIL].
FRR和微回路避免问题说明的说明见[SPRING-RESIL]。
The SPRING architecture MUST address the following requirements:
SPRING体系结构必须满足以下要求：
o support of Fast Reroute (FRR) on any topology
o 在任何拓扑上支持快速重路由（FRR）
o precomputation and setup of backup path without any additional signaling (other than the regular IGP/BGP protocols)
o 在没有任何附加信令的情况下预计算和设置备份路径（常规IGP/BGP协议除外）
o support of shared risk constraints
o 支持共享风险约束
o support of node and link protection
o 支持节点和链路保护
o support of micro-loop avoidance
o 支持微环避免
Traffic Engineering (TE) is the term used to refer to techniques that enable operators to control how specific traffic flows are treated within their networks. Different contexts and modes have been defined (single vs. multiple domains, with or without bandwidth admission control, centralized vs. distributed path computation, etc.).
流量工程（TE）是指使运营商能够控制如何在其网络内处理特定流量的技术。定义了不同的上下文和模式（单个域与多个域、有无带宽准入控制、集中式与分布式路径计算等）。
Some deployments have a limited use of TE, such as addressing specific application or customer requirements, or addressing specific bandwidth limitations in the network (tactical TE). In these situations, there is a need to reduce, as much as possible, the cost (such as the number of signaling protocols and the number of nodes requiring specific configurations/features). Some other deployments have a very high-scale use of TE, such as fine tuning flows at the application level. In this situation, there is a need for very high scalability, in particular on midpoints.
某些部署对TE的使用有限，例如解决特定应用程序或客户需求，或解决网络中的特定带宽限制（战术TE）。在这些情况下，需要尽可能降低成本（例如信令协议的数量和需要特定配置/功能的节点的数量）。其他一些部署非常大规模地使用TE，例如在应用程序级别微调流。在这种情况下，需要非常高的可伸缩性，特别是在中点上。
The source-based routing model allows traffic engineering to be implemented without the need for a signaling component.
基于源的路由模型允许在不需要信令组件的情况下实施流量工程。
The SPRING architecture MUST support the following traffic-engineering requirements:
SPRING架构必须支持以下流量工程需求：
o loose or strict options
o 宽松还是严格的选择
o bandwidth admission control
o 带宽接纳控制
o distributed vs. centralized model (e.g., Path Computation Element (PCE) [STATEFUL-PCE], Software-Defined Networking (SDN) Controller)
o 分布式与集中式模型（例如，路径计算元素（PCE）[有状态PCE]，软件定义网络（SDN）控制器）
o disjointness in dual-plane networks
o 双平面网络的不相交性
o egress peer engineering
o 出口对等工程
o load balancing among non-parallel links (i.e., links connected to different adjacent neighbors).
o 非并行链路（即连接到不同相邻链路的链路）之间的负载平衡。
o limiting (scalable, preferably zero) per-service state and signaling on midpoint and tail-end routers.
o 在中点和终端路由器上限制（可扩展，最好为零）每个服务状态和信令。
o ECMP-awareness
o ECMP意识
o node resiliency property (i.e., the traffic-engineering policy is not anchored to a specific core node whose failure could impact the service).
o 节点弹性属性（即，流量工程策略未锚定到其故障可能影响服务的特定核心节点）。
In most cases, traffic engineering makes use of the "loose" route option where most of the explicit paths can be expressed through a small number of hops. However, there are use cases where the "strict" option may be used and, in such cases, each individual hop in the explicit path is specified. This may result in a long list of hops that is instantiated into a MPLS label stack (in the MPLS data plane) or list of IPv6 addresses (in the IPv6 data plane).
在大多数情况下，流量工程使用“松散”路由选项，其中大多数显式路径可以通过少量跳来表示。但是，在某些用例中，可以使用“strict”选项，在这种情况下，会指定显式路径中的每个单独跃点。这可能导致一长串跃点被实例化为MPLS标签堆栈（在MPLS数据平面中）或IPv6地址列表（在IPv6数据平面中）。
It is obvious that, in the case of long, strict source-routed paths, the deployment is possible if the head-end of the explicit path supports the instantiation of long explicit paths.
显然，在长的、严格的源路由路径的情况下，如果显式路径的前端支持长显式路径的实例化，则部署是可能的。
Alternatively, a controller could decompose the end-to-end path into a set of sub-paths such as each of these sub-paths is supported by its respective head-end and advertised with a single identifier. Hence, the concatenation (or stitching) of the sub-paths identifiers gives a compression scheme allowing an end-to-end path to be expressed in a smaller number of hops.
或者，控制器可以将端到端路径分解为一组子路径，例如，这些子路径中的每一个子路径都由其各自的头端支持，并且用单个标识符进行广告。因此，子路径标识符的串联（或缝合）提供了一种压缩方案，允许端到端路径以较小的跳数表示。
Below are descriptions of two sets of use cases:
下面是两组用例的描述：
o Traffic Engineering without Admission Control
o 无准入控制的交通工程
o Traffic Engineering with Admission Control
o 具有准入控制的交通工程
In this section, we describe Traffic Engineering use cases without bandwidth admission control.
在本节中，我们将描述没有带宽许可控制的流量工程用例。
Many networks are built according to the dual-plane design, as illustrated in Figure 2:
许多网络是根据双平面设计构建的，如图2所示：
Each aggregation region k is connected to the core by two C routers C1k and C2k, where k refers to the region.
每个聚合区域k通过两个C路由器C1k和C2k连接到核心，其中k表示该区域。
C1k is part of plane 1 and aggregation region k
C1k是平面1和聚集区k的一部分
C2k is part of plane 2 and aggregation region k
C2k是平面2和聚集区k的一部分
C1k has a link to C2j iff k = j.
当k=j时，C1k有一个到C2j的链接。
The core nodes of a given region are directly connected. Inter-region links only connect core nodes of the same plane.
给定区域的核心节点直接连接。区域间链接仅连接同一平面的核心节点。
{C1k has a link to C1j} iff {C2k has a link to C2j}.
{C1k链接到C1j}iff{C2k链接到C2j}。
The distribution of these links depends on the topological properties of the core of the Autonomous System (AS). The design rule presented above specifies that these links appear in both core planes.
这些链路的分布取决于自治系统（AS）核心的拓扑特性。上面介绍的设计规则指定这些链接出现在两个核心平面中。
We assume a common design rule found in such deployments: The inter-plane link costs (Cik - Cjk, where i != j) are set such that the route to an edge destination from a given plane stays within the plane unless the plane is partitioned.
我们假设在此类部署中存在一个常见的设计规则：平面间链路成本（Cik-Cjk，其中i！=j）的设置使得从给定平面到边缘目的地的路由保持在该平面内，除非该平面被分区。
Edge Router A
/ \
/ \
/ \ Agg Region A
/ \
/ \
C1A----------C2A
| \ | \
| \ | \
| C1B----------C2B
Plane1 | | | | Plane2
| | | |
C1C--|-----C2C |
\ | \ |
\ | \ |
C1Z----------C2Z
\ /
\ / Agg Region Z
\ /
\ /
Edge Router Z
Edge Router A
/ \
/ \
/ \ Agg Region A
/ \
/ \
C1A----------C2A
| \ | \
| \ | \
| C1B----------C2B
Plane1 | | | | Plane2
| | | |
C1C--|-----C2C |
\ | \ |
\ | \ |
C1Z----------C2Z
\ /
\ / Agg Region Z
\ /
\ /
Edge Router Z
Figure 2: Dual-Plane Network and Disjointness
图2：双平面网络和不相交
In this scenario, the operator requires the ability to deploy different strategies. For example, Edge Router A should be able to use the three following options:
在这种情况下，操作员需要能够部署不同的策略。例如，边缘路由器A应能够使用以下三个选项：
o The traffic is load-balanced across any ECMP path through the network.
o 流量通过网络中的任何ECMP路径进行负载平衡。
o The traffic is load-balanced across any ECMP path within Plane1 of the network.
o 流量通过网络Plane1内的任何ECMP路径进行负载平衡。
o The traffic is load-balanced across any ECMP path within Plane2 of the network.
o 流量通过网络Plane2内的任何ECMP路径进行负载平衡。
Most of the data traffic from A to Z would use the first option, so as to exploit the capacity efficiently. The operator would use the two other choices for specific premium traffic that has requested disjoint transport.
从A到Z的大多数数据流量都将使用第一个选项，以便有效地利用容量。运营商将使用另外两种选择，用于要求不相交运输的特定优质交通。
The SPRING architecture MUST support this use case with the following requirements:
SPRING体系结构必须支持此用例，并满足以下要求：
o Zero per-service state and signaling on midpoint and tail-end routers.
o 在中点和终端路由器上，每个服务状态和信令为零。
o ECMP-awareness.
o ECMP意识。
o Node resiliency property: The traffic-engineering policy is not anchored to a specific core node whose failure could impact the service.
o 节点弹性属性：流量工程策略未锚定到其故障可能影响服务的特定核心节点。
+------+
| |
+---D F
+---------+ / | AS2 |\ +------+
| |/ +------+ \| Z |
A C | |
| |\ +------+ /| AS4 |
B AS1 | \ | |/ +------+
| | +---E G
+---------+ | AS3 |
+------+\
+------+
| |
+---D F
+---------+ / | AS2 |\ +------+
| |/ +------+ \| Z |
A C | |
| |\ +------+ /| AS4 |
B AS1 | \ | |/ +------+
| | +---E G
+---------+ | AS3 |
+------+\
Figure 3: Egress Peering Traffic Engineering
图3：出口对等流量工程
Let us assume, in the network depicted in Figure 3, that:
让我们假设，在图3所示的网络中：
o C in AS1 learns about destination Z of AS4 via two BGP paths (AS2, AS4) and (AS3, AS4).
o AS1中的C通过两个BGP路径（AS2，AS4）和（AS3，AS4）了解AS4的目的地Z。
o C may or may not be configured to enforce the next-hop-self behavior before propagating the paths within AS1.
o 在AS1内传播路径之前，C可以配置为强制下一跳的自我行为，也可以不配置为强制下一跳的自我行为。
o C may propagate all the paths to Z within AS1 (using BGP ADD-PATH as specified in [ADD-PATH]).
o C可以将所有路径传播到AS1中的Z（使用[ADD-PATH]中指定的BGP ADD-PATH]）。
o C may install in its Forwarding Information Base (FIB) only the route via AS2, or only the route via AS3, or both.
o C可以在其转发信息库（FIB）中仅安装通过AS2的路由，或仅安装通过AS3的路由，或两者都安装。
In that context, the SPRING architecture MUST allow the operator of AS1 to apply a traffic-engineering policy such as the following one, regardless of the configured behavior of the next-hop-self:
在这种情况下，SPRING体系结构必须允许AS1的运营商应用流量工程策略，如以下策略，而不管下一跳自身的配置行为：
o Steer 60% of the Z-destined traffic received at A via AS2 and 40% via AS3.
o 通过AS2和AS3分别控制60%和40%的Z目的地流量。
o Steer 80% of the Z-destined traffic received at B via AS2 and 20% via AS3.
o 通过AS2控制在B接收到的80%的Z目的地流量，通过AS3控制20%的Z目的地流量。
The SPRING architecture MUST allow an ingress node (i.e., an explicit route source node) to select the exit point of a packet as any combination of an egress node, an egress interface, a peering neighbor, and a peering AS.
SPRING体系结构必须允许入口节点（即，显式路由源节点）选择分组的出口点作为出口节点、出口接口、对等邻居和对等as的任意组合。
The use cases and requirements for egress peer engineering are described in [SR-BGP-EPE].
[SR-BGP-EPE]中描述了出口对等工程的用例和要求。
The SPRING architecture MUST allow a given node to load-share traffic across multiple non-parallel links (i.e., links connected to different adjacent routers), even if these lead to different neighbors. This may be useful for supporting traffic-engineering policies.
SPRING架构必须允许给定节点跨多个非并行链路（即连接到不同相邻路由器的链路）加载共享流量，即使这些链路导致不同的邻居。这可能有助于支持流量工程策略。
+---C---D---+
| |
PE1---A---B-----F-----E---PE2
+---C---D---+
| |
PE1---A---B-----F-----E---PE2
Figure 4: Multiple (Non-parallel) Adjacencies
图4：多个（非平行）邻接
In the above example, the operator requires PE1 to load-balance its PE2-destined traffic between the ABCDE and ABFE equal-cost paths in a controlled way where the operator MUST be allowed to distribute traffic unevenly between paths (Weighted Equal-Cost Multipath (WECMP)).
在上述示例中，运营商要求PE1以受控方式在ABCDE和ABFE等成本路径之间负载平衡其PE2目的地业务，其中必须允许运营商在路径之间不均匀地分配业务（加权等成本多路径（WECMP））。
The implementation of bandwidth admission control within a network (and its possible routing consequence, which consists in routing along explicit paths where the bandwidth is available) requires a capacity-planning process.
在网络中实现带宽许可控制（及其可能的路由结果，包括沿带宽可用的显式路径进行路由）需要容量规划过程。
The spreading of load among ECMP paths is a key attribute of the capacity-planning processes applied to packet-based networks.
负载在ECMP路径之间的扩散是应用于基于分组的网络的容量规划过程的一个关键属性。
Capacity planning anticipates the routing of the traffic matrix onto the network topology for a set of expected traffic and topology variations. The heart of the process consists in simulating the placement of the traffic along ECMP-aware shortest paths and accounting for the resulting bandwidth usage.
容量规划预测流量矩阵在网络拓扑上的路由，以获得一组预期的流量和拓扑变化。该过程的核心在于模拟流量沿ECMP感知的最短路径的位置，并说明由此产生的带宽使用情况。
The bandwidth accounting of a demand along its shortest path is a basic capability of any planning tool or PCE server.
任何规划工具或PCE服务器的基本功能都是在最短路径上计算需求的带宽。
For example, in the network topology described below, and assuming a default IGP metric of 1 and IGP metric of 2 for link GF, a 1600 Mbps A-to-Z flow is accounted as consuming 1600 Mbps on links AB and FZ; 800 Mbps on links BC, BG, and GF; and 400 Mbps on links CD, DF, CE, and EF.
例如，在下面描述的网络拓扑中，假设链路GF的默认IGP度量为1，IGP度量为2，1600 Mbps a-to-Z流被认为在链路AB和FZ上消耗1600 Mbps；链路BC、BG和GF上的800 Mbps；在CD、DF、CE和EF链路上的传输速率为400 Mbps。
C-----D
/ \ \
A---B +--E--F--Z
\ /
G------+
C-----D
/ \ \
A---B +--E--F--Z
\ /
G------+
Figure 5: Capacity Planning an ECMP-Based Demand
图5：基于ECMP需求的容量规划
ECMP is extremely frequent in Service Provider (SP), enterprise, and data-center architectures and it is not rare to see as much as 128 different ECMP paths between a source and a destination within a single network domain. It is a key efficiency objective to spread the traffic among as many ECMP paths as possible.
ECMP在服务提供商（SP）、企业和数据中心体系结构中非常常见，在单个网络域中，源和目标之间出现多达128条不同的ECMP路径并不罕见。在尽可能多的ECMP路径之间分配流量是一个关键的效率目标。
This is illustrated in the network diagram below, which consists of a subset of a network where already 5 ECMP paths are observed from A to M.
下面的网络图说明了这一点，它由网络的一个子集组成，其中从a到M已观察到5条ECMP路径。
C
/ \
B-D-L--
/ \ / \
A E \
\ M
\ G /
\ / \ /
F K
\ /
I
C
/ \
B-D-L--
/ \ / \
A E \
\ M
\ G /
\ / \ /
F K
\ /
I
Figure 6: ECMP Topology Example
图6:ECMP拓扑示例
When the capacity-planning process detects that a traffic growth scenario and topology variation would lead to congestion, a capacity increase is triggered, and if it cannot be deployed in due time, a traffic-engineering solution is activated within the network.
当容量规划过程检测到流量增长场景和拓扑变化将导致拥塞时，会触发容量增加，如果无法在适当的时间部署，则会在网络内激活流量工程解决方案。
A basic traffic-engineering objective consists of finding the smallest set of demands that need to be routed off their shortest path to eliminate the congestion, and then to compute an explicit path for each of them and instantiate these traffic-engineered policies in the network.
一个基本的流量工程目标包括找到最小的需求集，这些需求需要通过最短路径进行路由以消除拥塞，然后计算每个需求的显式路径，并在网络中实例化这些流量工程策略。
The SPRING architecture MUST offer a simple support for ECMP-based shortest-path placement as well as for explicit path policy without incurring additional signaling in the domain. This includes:
SPRING体系结构必须提供对基于ECMP的最短路径放置以及显式路径策略的简单支持，而不会在域中产生额外的信令。这包括：
o the ability to steer a packet across a set of ECMP paths
o 在一组ECMP路径上引导数据包的能力
o the ability to diverge from a set of ECMP shortest paths to one or more paths not in the set of shortest paths
o 从一组ECMP最短路径发散到不在该组最短路径中的一条或多条路径的能力
The SDN use case lies in the SDN controller, (e.g., Stateful PCE as described in [STATEFUL-PCE]).
SDN用例位于SDN控制器中（例如，如[Stateful-PCE]中所述的有状态PCE）。
The SDN controller is responsible for controlling the evolution of the traffic matrix and topology. It accepts or denies the addition of new traffic into the network. It decides how to route the accepted traffic. It monitors the topology and, upon topological change, determines the minimum traffic that should be rerouted on an alternate path to alleviate a bandwidth congestion issue.
SDN控制器负责控制流量矩阵和拓扑的演变。它接受或拒绝向网络中添加新流量。它决定如何路由接受的流量。它监视拓扑，并在拓扑发生变化时，确定应在备用路径上重新路由以缓解带宽拥塞问题的最小流量。
The algorithms supporting this behavior are a local matter of the SDN controller and are outside the scope of this document.
支持此行为的算法是SDN控制器的局部问题，不在本文档范围内。
The means of collecting traffic and topology information are the same as what would be used with other SDN-based traffic-engineering solutions.
收集流量和拓扑信息的方法与其他基于SDN的流量工程解决方案相同。
The means of instantiating policy information at a traffic-engineering head-end are the same as what would be used with other SDN-based traffic-engineering solutions.
在流量工程前端实例化策略信息的方法与其他基于SDN的流量工程解决方案相同。
In the context of centralized optimization and the SDN use case, the SPRING architecture MUST have the following attributes:
在集中式优化和SDN用例的上下文中，SPRING体系结构必须具有以下属性：
o Explicit routing capability with or without ECMP-awareness.
o 有或没有ECMP感知的显式路由功能。
o No signaling hop-by-hop through the network.
o 没有通过网络逐跳发送信号。
o The policy state is only maintained at the policy head-end. No policy state is maintained at midpoints and tail-ends.
o 策略状态仅在策略头端维护。在中点和尾端不维护策略状态。
o Automated guaranteed FRR for any topology.
o 任何拓扑的自动保证FRR。
o The policy state is in the packet header and not in the intermediate nodes along the path. The policy is absent from midpoints and tail-ends.
o 策略状态位于数据包头中，而不是路径上的中间节点中。该政策在中点和尾端都不存在。
o Highly responsive to change: The SDN Controller only needs to apply a policy change at the head-end. No delay is introduced due to programming the midpoints and tail-end along the path.
o 高度响应更改：SDN控制器只需在前端应用策略更改。由于沿路径编程中点和尾端，因此不会引入延迟。
SPRING nodes MUST interoperate with non-SPRING nodes and in both MPLS and IPv6 data planes in order to allow a gradual deployment of SPRING on existing MPLS and IPv6 networks.
SPRING节点必须在MPLS和IPv6数据平面上与非SPRING节点进行互操作，以便在现有MPLS和IPv6网络上逐步部署SPRING。
SPRING reuses the concept of source routing by encoding the path in the packet. As with other similar source-routing architecture, an attacker may manipulate the traffic path by modifying the packet header. By manipulating the traffic path, an attacker may be able to cause outages on any part of the network.
SPRING通过对数据包中的路径进行编码，重用了源路由的概念。与其他类似的源路由体系结构一样，攻击者可以通过修改数据包头来操纵流量路径。通过操纵流量路径，攻击者可以在网络的任何部分造成中断。
SPRING adds some metadata on the packet, with the list of forwarding path elements that the packet must traverse. Depending on the data plane, this list may shrink as the packet traverses the network, by keeping only the next elements and forgetting the past ones.
SPRING在数据包上添加了一些元数据，以及数据包必须遍历的转发路径元素列表。根据数据平面的不同，该列表可能会随着数据包通过网络而缩小，只保留下一个元素而忘记过去的元素。
SPRING architecture MUST provide clear trust domain boundaries so that source-routing information is only usable within the trusted domain and never exposed to the outside world.
SPRING体系结构必须提供清晰的信任域边界，以便源路由信息只能在受信任域内使用，并且永远不会暴露于外部世界。
From a network protection standpoint, there is an assumed trust model such that any node imposing an explicit route on a packet is assumed to be allowed to do so. This is a significant change compared to plain IP offering the shortest-path routing, but not fundamentally different compared to existing techniques providing explicit routing capability. It is expected that, by default, the explicit routing information is not leaked through the boundaries of the administered domain.
从网络保护的角度来看，存在一个假定的信任模型，即假定允许对数据包施加显式路由的任何节点这样做。与提供最短路径路由的普通IP相比，这是一个重大的变化，但与提供显式路由功能的现有技术相比，这并没有根本的不同。默认情况下，显式路由信息不会通过受管域的边界泄漏。
Therefore, the data plane MUST NOT expose any source-routing information when a packet leaves the trusted domain. Special care will be required for the existing data planes like MPLS, especially for the inter-provider scenario where a third-party provider may push MPLS labels corresponding to a SPRING header anywhere in the stack. The architecture document MUST analyze the exact security considerations of such a scenario.
因此，当数据包离开可信域时，数据平面不得公开任何源路由信息。需要特别注意现有的数据平面（如MPLS），特别是在提供商间场景中，第三方提供商可能会将对应于SPRING头的MPLS标签推送到堆栈中的任何位置。体系结构文档必须分析这种场景的确切安全考虑因素。
Filtering routing information is typically performed in the control plane, but an additional filtering in the forwarding plane is also required. In SPRING, as there is no control plane (related to source-routed paths) between the source and the midpoints, filtering in the control plane is not possible (or not required, depending on the point of view). Filtering MUST be performed on the forwarding plane on the boundaries and MAY require looking at multiple labels or instructions.
过滤路由信息通常在控制平面中执行，但也需要在转发平面中进行额外过滤。在SPRING中，由于震源和中点之间没有控制平面（与震源路由路径相关），因此无法在控制平面中进行过滤（或不需要过滤，具体取决于视点）。过滤必须在边界上的转发平面上执行，可能需要查看多个标签或说明。
For the MPLS data plane, this is not a new requirement as the existing MPLS architecture already allows such source routing by stacking multiple labels. For security protection, Section 2.4 of [RFC4381] and Section 8.2 of [RFC5920] already call for the filtering of MPLS packets on trust boundaries.
对于MPLS数据平面，这不是新的要求，因为现有的MPLS体系结构已经允许通过堆叠多个标签来进行此类源路由。为了安全保护，[RFC4381]的第2.4节和[RFC5920]的第8.2节已经要求过滤信任边界上的MPLS数据包。
If all MPLS labels are filtered at domain boundaries, then SPRING does not introduce any change. If only a subset of labels are filtered, then SPRING introduces a change since the border router is expected to determine which information (e.g., labels) is filtered, while the border router is not the originator of these label advertisements.
如果所有MPLS标签都在域边界处过滤，那么SPRING不会引入任何更改。如果只过滤了标签的一个子集，那么SPRING将引入一个更改，因为边界路由器将确定过滤了哪些信息（例如标签），而边界路由器不是这些标签广告的发起人。
As the SPRING architecture must be based on a clear trust domain, mechanisms allowing the authentication and validation of the source-routing information must be evaluated by the SPRING architecture in order to prevent any form of attack or unwanted source-routing information manipulation.
由于SPRING体系结构必须基于明确的信任域，因此SPRING体系结构必须评估允许对源路由信息进行身份验证和验证的机制，以防止任何形式的攻击或不必要的源路由信息操纵。
Data-plane security considerations MUST be addressed in each document related to the SPRING data plane (i.e., MPLS and IPv6).
与SPRING数据平面（即MPLS和IPv6）相关的每个文档中都必须考虑到数据平面安全问题。
The IPv6 data plane proposes the use of a cryptographic signature of the source-routed path, which would ease this configuration. This is indeed needed more for the IPv6 data plane, which is end to end in nature, compared to the MPLS data plane, which is typically restricted to a controlled and trusted zone.
IPv6数据平面建议使用源路由路径的加密签名，这将简化此配置。与MPLS数据平面相比，IPv6数据平面本质上是端到端的，而MPLS数据平面通常被限制在受控和受信任的区域，这确实需要更多。
In the forwarding plane, data-plane extension documents MUST address the security implications of the required change.
在转发平面中，数据平面扩展文档必须解决所需更改的安全影响。
In terms of privacy, SPRING does not propose change in terms of encryption. Each data plane may or may not provide existing or future encryption capability.
在隐私方面，SPRING不建议在加密方面进行更改。每个数据平面可能提供也可能不提供现有或未来的加密功能。
To build the source-routing information in the packet, a node in the SPRING architecture will require learning information from a control layer. As this control layer will be in charge of programming forwarding instructions, an attacker taking over this component may also manipulate the traffic path. Any control protocol used in the SPRING architecture SHOULD provide security mechanisms or design to protect against such a control-layer attacker. Control-plane security considerations MUST be addressed in each document related to the SPRING control plane.
为了在数据包中构建源路由信息，SPRING体系结构中的节点需要从控制层学习信息。由于此控制层将负责编程转发指令，因此接管此组件的攻击者也可能操纵通信路径。SPRING体系结构中使用的任何控制协议都应提供安全机制或设计，以防止此类控制层攻击者。必须在与弹簧控制平面相关的每个文件中说明控制平面安全注意事项。
The SPRING WG MUST define Operations, Administration, and Maintenance (OAM) procedures applicable to SPRING-enabled networks.
SPRING工作组必须定义适用于支持SPRING的网络的操作、管理和维护（OAM）程序。
In SPRING networks, the path the packet takes is encoded in the header. SPRING architecture MUST include the necessary OAM mechanisms in order for the network operator to validate the effectiveness of a path as well as to check and monitor its liveness and performance. Moreover, in SPRING architecture, a path may be defined in the forwarding layer (in both MPLS and IPv6 data planes) or as a service path (formed by a set of service instances). The network operator MUST be capable to monitor, control, and manage paths (both network and service based) using OAM procedures.
在SPRING网络中，数据包的路径在报头中进行编码。SPRING体系结构必须包括必要的OAM机制，以便网络运营商验证路径的有效性，并检查和监控其活动性和性能。此外，在SPRING体系结构中，路径可以在转发层（在MPLS和IPv6数据平面中）中定义，也可以定义为服务路径（由一组服务实例形成）。网络运营商必须能够使用OAM过程监控、控制和管理路径（基于网络和基于服务）。
OAM use cases and requirements are detailed in [OAM-USE] and [SR-OAM].
[OAM-use]和[SR-OAM]中详细介绍了OAM用例和需求。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，DOI 10.17487/RFC2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，DOI 10.17487/RFC4364，2006年2月<http://www.rfc-editor.org/info/rfc4364>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <http://www.rfc-editor.org/info/rfc4761>.
[RFC4761]Kompella，K.，Ed.和Y.Rekhter，Ed.，“使用BGP进行自动发现和信令的虚拟专用LAN服务（VPLS）”，RFC 4761，DOI 10.17487/RFC4761，2007年1月<http://www.rfc-editor.org/info/rfc4761>.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <http://www.rfc-editor.org/info/rfc4762>.
[RFC4762]Lasserre，M.，Ed.和V.Kompella，Ed.，“使用标签分发协议（LDP）信令的虚拟专用LAN服务（VPLS）”，RFC 4762，DOI 10.17487/RFC4762，2007年1月<http://www.rfc-editor.org/info/rfc4762>.
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, <http://www.rfc-editor.org/info/rfc6624>.
[RFC6624]Kompella，K.，Kothari，B.，和R.Cherukuri，“使用BGP进行自动发现和信令的第2层虚拟专用网络”，RFC 6624DOI 10.17487/RFC66242012年5月<http://www.rfc-editor.org/info/rfc6624>.
[ADD-PATH] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", Work in Progress, draft-ietf-idr-add-paths-14, April 2016.
[ADD-PATH]Walton，D.，Retana，A.，Chen，E.，和J.Scudder，“BGP中多路径的广告”，正在进行的工作，草稿-ietf-idr-ADD-PATH-142016年4月。
[OAM-USE] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. Kumar, "A Scalable and Topology-Aware MPLS Dataplane Monitoring System", Work in Progress, draft-ietf-spring-oam-usecase-03, April 2016.
[OAM-USE]Geib，R.，Ed.，Filsfils，C.，Pignataro，C.，Ed.，和N.Kumar，“可扩展和拓扑感知的MPLS数据平面监控系统”，正在进行的工作，草稿-ietf-spring-OAM-usecase-032016年4月。
[RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4381, DOI 10.17487/RFC4381, February 2006, <http://www.rfc-editor.org/info/rfc4381>.
[RFC4381]Behringer，M.，“BGP/MPLS IP虚拟专用网络（VPN）的安全性分析”，RFC 4381，DOI 10.17487/RFC4381，2006年2月<http://www.rfc-editor.org/info/rfc4381>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，DOI 10.17487/RFC5920，2010年7月<http://www.rfc-editor.org/info/rfc5920>.
[SPRING-RESIL] Francois, P., Filsfils, C., Decraene, B., and R. Shakir, "Use-cases for Resiliency in SPRING", Work in Progress, draft-ietf-spring-resiliency-use-cases-03, April 2016.
[SPRING-Resility]Francois，P.，Filsfils，C.，Decarene，B.，和R.Shakir，“春季弹性的用例”，正在进行的工作，草稿-ietf-SPRING-Resilience-Use-cases-032016年4月。
[SR-BGP-EPE] Filsfils, C., Ed., Previdi, S., Ed., Ginsburg, D., and D. Afanasiev, "Segment Routing Centralized BGP Peer Engineering", Work in Progress, draft-ietf-spring-segment-routing-central-epe-01, March 2016.
[SR-BGP-EPE]Filsfils，C.，Ed.，Previdi，S.，Ed.，Ginsburg，D.和D.Afanasiev，“分段路由集中式BGP对等工程”，在建工程，草案-ietf-spring-Segment-Routing-central-EPE-01，2016年3月。
[SR-OAM] Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., and S. Litkowski, "OAM Requirements for Segment Routing Network", Work in Progress, draft-ietf-spring-sr-oam-requirement-01, December 2015.
[SR-OAM]Kumar，N.，Pignataro，C.，Akiya，N.，Geib，R.，Mirsky，G.，和S.Litkowski，“分段路由网络的OAM要求”，正在进行的工作，草案-ietf-spring-SR-OAM-requirement-012015年12月。
[SRH] Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment Routing Header (SRH)", Work in Progress, draft-ietf-6man-segment-routing-header-01, March 2016.
[SRH]Previdi，S.，Filsfils，C.，Field，B.，Leung，I.，Linkova，J.，Kosugi，T.，Vyncke，E.，和D.Lebrun，“IPv6段路由头（SRH）”，正在进行的工作，草案-ietf-6man-Segment-Routing-Header-01，2016年3月。
[STATEFUL-PCE] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Extensions for Stateful PCE", Work in Progress, draft-ietf-pce-stateful-pce-14, March 2016.
[STATEFUL-PCE]Crabbe，E.，Minei，I.，Medved，J.，和R.Varga，“有状态PCE的PCEP扩展”，正在进行的工作，草稿-ietf-PCE-STATEFUL-PCE-142016年3月。
Acknowledgements
致谢
The authors would like to thank Yakov Rekhter for his contribution to this document.
作者感谢Yakov Rekhter对本文件的贡献。
Contributors
贡献者
The following individuals substantially contributed to the content of this document:
以下个人对本文件的内容做出了重大贡献：
Ruediger Geib Deutsche Telekom Heinrich Hertz Str. 3-7 Darmstadt 64295 Germany
Ruediger Geib Deutsche Telekom Heinrich Hertz Str.3-7 Darmstadt 64295德国
Email: Ruediger.Geib@telekom.de
Email: Ruediger.Geib@telekom.de
Robert Raszuk Mirantis Inc. 615 National Ave. 94043 Mountain View, CA United States
罗伯特·拉祖克·米兰蒂斯公司，美国加利福尼亚州山景城94043国家大道615号
Email: robert@raszuk.net
Email: robert@raszuk.net
Authors' Addresses
作者地址
Stefano Previdi (editor) Cisco Systems, Inc. Via Del Serafico, 200 Rome 00142 Italy
斯蒂凡诺·普雷维迪（编辑）思科系统有限公司，意大利罗马，邮编：200，邮编：00142
Email: sprevidi@cisco.com
Email: sprevidi@cisco.com
Clarence Filsfils (editor) Cisco Systems, Inc. Brussels Belgium
Clarence Filsfils（编辑）思科系统公司比利时布鲁塞尔
Email: cfilsfil@cisco.com
Email: cfilsfil@cisco.com
Bruno Decraene Orange France
布鲁诺·德雷恩橙法国
Email: bruno.decraene@orange.com
Email: bruno.decraene@orange.com
Stephane Litkowski Orange France
斯特凡利特科夫斯基橙法国
Email: stephane.litkowski@orange.com
Email: stephane.litkowski@orange.com
Martin Horneffer Deutsche Telekom Muenster 48153 Germany
马丁·霍内弗德国慕尼黑电信公司48153德国
Email: Martin.Horneffer@telekom.de
Email: Martin.Horneffer@telekom.de
Rob Shakir Jive Communications, Inc. 1275 West 1600 North, Suite 100 Orem, UT 84057 United States
Rob Shakir Jive Communications，Inc.美国犹他州奥勒姆100号套房西1600北1275号，邮编84057
Email: rjs@rob.sh
Email: rjs@rob.sh