SPRING用例分析
https://tools.ietf.org/html/rfc7855#page-3
3.1. IGP-Based MPLS Tunneling
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. Previdi, et al. Informational [Page 4]
基于源的路由模型，同样适用MPLS数据平面，提供隧道服务能力用于创建VPN，VPLS，VPWS，主要是指从入PE到出PE间的隧道，这些隧道通过显式路径或者非显式路径并且不需要中间节点的转发或者控制平面的状态。点对多点和多点间的隧道不属于本文范围。
RFC 7855 SPRING Problem Statement May 2016
3.1.1. Example of IGP-Based MPLS Tunnels
This section illustrates an example use case.
P1---P2
/ \
A---CE1---PE1 PE2---CE2---Z
\ /
P3---P4
Figure 1: IGP-Based MPLS Tunneling
IGP-Based MPLS Tunneling 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. 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.
图1基于IGP的MPLS隧道，A，CE1，CE2和Z节点是同一VPN的四个节点，CE2通告PE2到达Z的一条路由，PE2绑定本地标签LZ到这条路由并且将路由和标签通过MPBGP传播给PE1，指定下一跳是PE2的本地地址例如192.0.2.2。PE1安装VPN前缀Z到正确的VRF表并且基于IGP的MPLS隧道解析下一跳到PE2。为了应对当前部署的现实，SPRING架构必须允许根据IGP最短路径进行PE到PE转发，而无需添加任何其他信令协议。 每个PE通过网络转发的数据包将包含从拓扑数据库派生的必要信息，以便将数据包传递到远程PE。
3.2. Fast Reroute (FRR)
Fast Reroute (FRR) technologies have been deployed by network operators in order to cope with link or node failures through precomputation of backup paths. Illustration of the problem statement for FRR and micro-loop avoidance can be found in [SPRING-RESIL]. The SPRING architecture MUST address the following requirements:
快速重路由技术被网络管理者部署用来处理节点或者链路失败，通过预计算备份链路。网络运营商已经部署了快速重路由（FRR）技术，以通过预先计算备份路径来应对链路或节点故障。 FRR和微环避免的问题陈述的插图可以在[SPRING-RESIL]中找到。 SPRING架构必须满足以下要求：
o support of Fast Reroute (FRR) on any topology
支持任意拓扑的FRR
o precomputation and setup of backup path without any additional signaling (other than the regular IGP/BGP protocols)
预计算并设置备份链路不依赖任何额外的信令（不同于常规IGP/BGP协议）
o support of shared risk constraints Previdi, et al. Informational [Page 5]
支持共同的风险约束
o support of node and link protection
支持节点和链路保护
o support of micro-loop avoidance
支持微型环避免
3.3. Traffic Engineering
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.). 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. 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:
流量工程（TE）是用于表示使运营商能够控制在其网络中如何处理特定流量流的技术的术语。已经定义了不同的上下文和模式（例如单域vs多域，有无带宽控制，集中vs分布式路径计算）。某些部署对TE的使用有限，例如解决特定应用或者客户的需求，或者解决网络中特定带宽限制（策略TE）。在这些场景下，需要尽可能减少开销（例如信令协议的数量和节点请求特定配置/特性的数量）。其他一些部署对TE需要很高扩展性使用，例如应用程序级别的流量优化。在这种场景下特别是中间点则需要很高的扩展性。基于源的路由模型允许流量工程不需要信令组件的情况下得以实现。SPRING架构必须支持流量工程以下需求：
o loose or strict options o bandwidth admission control
对于带宽或严格或松散的控制
o distributed vs. centralized model (e.g., Path Computation Element (PCE) [STATEFUL-PCE], Software-Defined Networking (SDN) Controller)
分布式vs集中式模型（例如PCE,SDN）
o disjointness in dual-plane networks
双平面网络中不相交？是不是控制面转发面分离？
o egress peer engineering
出节点对等工程
o load balancing among non-parallel links (i.e., links connected to different adjacent neighbors).
在非平行链路间负载均衡（例如链路连接到不通临街邻居）
o limiting (scalable, preferably zero) per-service state and signaling on midpoint and tail-end routers.
限制每个服务状态（可扩展，最好可以是零）以及在中间点和尾端节点发送信令？
o ECMP-awareness
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).
节点弹性属性（例如流量工程策略不局限于某个核心节点失败而影响到服务）
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). 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.
在大多数情况下，流量工程使用“松散”路由选项，其中大多数显式路径可以通过少量跳跃来表示。然而，存在可以使用“严格”选项的用例，并且在这种情况下，显式路径的每一跳都是明确的。这可能导致长的下一跳列表被实例化到MPLS标签栈（在MPLS数据平面中）或IPv6地址列表（在IPv6数据平面中）。很明显，在长而严格的源路由路径的情况下，如果显式路径的头端支持长显式路径的实例化，则可以进行部署。或者，控制器可以将端到端路径分解成一组子路径，例如这些子路径中的每一个由其相应的头端支持并用单个标识符通告。因此，子路径标识符的串联（或拼接）给出了压缩方案，允许端到端路径以较少数量的跳数表示
3.3.1. Examples of Traffic-Engineering Use Cases
流量工程用例举例
Below are descriptions of two sets of use cases:
以下是两种用例集合描述
o Traffic Engineering without Admission Control
无准入控制的流量工程
o Traffic Engineering with Admission Control
准入控制的流量工程
3.3.1.1. Traffic Engineering without Bandwidth Admission Control
In this section, we describe Traffic Engineering use cases without bandwidth admission control.
在这一部分，描述无带宽准入控制的流量工程用例
3.3.1.1.1. Disjointness in Dual-Plane Networks
Many networks are built according to the dual-plane design, as illustrated in Figure 2: Each aggregation region k is connected to the core by two C routers C1k and C2k, where k refers to the region.
C1k is part of plane 1 and aggregation region k
C2k is part of plane 2 and aggregation region k
许多网络根据说明吗设计而建立，例如图2:每个接入区域k通过两个c（核心）路由器C1k和C2k接入核心，k代表一个区域。
C1k是plane1和接入区域k一部分
C2k是plane2和接入区域k一部分，
C1k has a link to C2j iff k = j. C1k于C2j之间有一条链路。 The core nodes of a given region are directly connected. 一个给定区域的核心节点是直连的，例如C1A和C2A Inter-region links only connect core nodes of the same plane. 区域间链路只连接同一平面的核心节点，例如C1A和C1B {C1k has a link to C1j} iff {C2k has a link to 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. 这些链路分配依赖核心自主性系统的拓扑属性。以上的设计规则指出这些链路在两个核心平面中存在。 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 Figure 2: Dual-Plane Network and Disjointness 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. 流量通过任意ECMP路径在网络上是负载均衡的。 Previdi, et al. Informational [Page 8]
RFC 7855 SPRING Problem Statement May 2016 o The traffic is load-balanced across any ECMP path within Plane1 of the network. 流量通过网络平面1的任意ECMP路径是负载均衡的 o The traffic is load-balanced across any ECMP path within Plane2 of the network. 流量通过网络平面2的任意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 ECMP-awareness. ECMP感知 o Node resiliency property: The traffic-engineering policy is not anchored to a specific core node whose failure could impact the service.
节点弹性，不因某一核心节点失败影响业务。
3.3.1.1.2. Egress Peering Traffic Engineering
+------+
| |
+---D F
+---------+ / | AS2 |\ +------+
| |/ +------+ \| Z |
A C | |
| |\ +------+ /| AS4 |
B AS1 | \ | |/ +------+
| | +---E G
+---------+ | AS3 |
+------+\
Figure 3: Egress Peering Traffic Engineering
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).
AS1中的C节点学习到AS4的Z节点路由包括两条BGP路径，分别为AS2，AS4和AS3，AS4
o C may or may not be configured to enforce the next-hop-self behavior before propagating the paths within AS1.
在AS1传播路径之前，C节点可以配置强化下一跳自行为也可以不配置
o C may propagate all the paths to Z within AS1 (using BGP ADD-PATH
as specified in [ADD-PATH]).
C可以AS1内所有到大Z节点的路径（使用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.
C可以安装仅通过AS2的路由到它的FIB，也可以通过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.
目标Z端点的流量从A通过AS2的流量有60%，通过AS3有40%
o Steer 80% of the Z-destined traffic received at B via AS2 and 20%
via AS3.
目标Z端点的流量从B通过AS2的流量有60%，通过AS3有40%
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架构必须支持允许入节点（即显示路由源节点）选择包的出口点作为一个出口节点，出口接口，对端邻居和对端域的任意组合。
The use cases and requirements for egress peer engineering are
described in [SR-BGP-EPE].
对于出节点工程在SR-BGP-EPE有描述
3.3.1.1.3. Load Balancing among Non-parallel Links
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
Figure 4: Multiple (Non-parallel) Adjacencies
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到PE2的流量在ABCDE和ABFE等价链路之间进行负载均衡，允许运营商以一种可控的方式在这两条链路不均匀的分配流量。
3.3.1.2. Traffic Engineering with Bandwidth Admission Control
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.
3.3.1.2.1. Capacity-Planning Process
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. The bandwidth accounting of a demand along its shortest path is a basic capability of any planning tool or PCE server. 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. C-----D / \ \ A---B +--E--F--Z \ / G------+ Figure 5: Capacity Planning an ECMP-Based Demand 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. 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. Previdi, et al. Informational [Page 11]
RFC 7855 SPRING Problem Statement May 2016 C / \ B-D-L-- / \ / \ A E \ \ M \ G / \ / \ / F K \ / I Figure 6: ECMP Topology Example 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: o the ability to steer a packet across a set of ECMP paths o the ability to diverge from a set of ECMP shortest paths to one or more paths not in the set of shortest paths
3.3.1.2.2. SDN Use Case
The SDN use case lies in the SDN controller, (e.g., Stateful PCE as described in [STATEFUL-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. The algorithms supporting this behavior are a local matter of the SDN controller and are outside the scope of this document. Previdi, et al. Informational [Page 12]
RFC 7855 SPRING Problem Statement May 2016 The means of collecting traffic and topology information are the same as what would be used with other SDN-based traffic-engineering solutions. 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. In the context of centralized optimization and the SDN use case, the SPRING architecture MUST have the following attributes: o Explicit routing capability with or without ECMP-awareness. o No signaling hop-by-hop through the network. o The policy state is only maintained at the policy head-end. No policy state is maintained at midpoints and tail-ends. o Automated guaranteed FRR for any topology. 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 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.
3.4. Interoperability with Non-SPRING Nodes
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.
4. Security Considerations
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 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. Previdi, et al. Informational [Page 13]
RFC 7855 SPRING Problem Statement May 2016 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. 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. 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. 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. 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. 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. 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. Previdi, et al. Informational [Page 14]
RFC 7855 SPRING Problem Statement May 2016 Data-plane security considerations MUST be addressed in each document related to the SPRING data plane (i.e., MPLS and 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. 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. 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.
5. Manageability Considerations
The SPRING WG MUST define Operations, Administration, and Maintenance (OAM) procedures applicable to SPRING-enabled networks. 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. OAM use cases and requirements are detailed in [OAM-USE] and [SR-OAM].
760
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
