Internet Engineering Task Force (IETF) P. Quinn, Ed.
Request for Comments: 7498 Cisco Systems, Inc.
Category: Informational T. Nadeau, Ed.
ISSN: 2070-1721 Brocade
April 2015
Internet Engineering Task Force (IETF) P. Quinn, Ed.
Request for Comments: 7498 Cisco Systems, Inc.
Category: Informational T. Nadeau, Ed.
ISSN: 2070-1721 Brocade
April 2015
Problem Statement for Service Function Chaining
服务功能链接的问题陈述
Abstract
摘要
This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers, etc.) in large-scale environments. The term "service function chaining" is used to describe the definition and instantiation of an ordered list of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions.
本文档概述了与在大规模环境中部署服务功能（如防火墙、负载平衡器等）相关的问题。术语“服务功能链接”用于描述此类服务功能实例的有序列表的定义和实例化，以及通过这些服务功能的流量的后续“引导”。
The set of enabled service function chains reflects operator service offerings and is designed in conjunction with application delivery and service and network policy.
已启用的服务功能链集反映了运营商提供的服务，并与应用程序交付、服务和网络策略一起设计。
This document also identifies several key areas that the Service Function Chaining (SFC) working group will investigate to guide its architectural and protocol work and associated documents.
本文件还确定了服务功能链（SFC）工作组将调查的几个关键领域，以指导其架构和协议工作以及相关文件。
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/rfc7498.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7498.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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. Definition of Terms . . . . . . . . . . . . . . . . . . . 3
2. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Topological Dependencies . . . . . . . . . . . . . . . . 5
2.2. Configuration Complexity . . . . . . . . . . . . . . . . 6
2.3. Constrained High Availability . . . . . . . . . . . . . . 6
2.4. Consistent Ordering of Service Functions . . . . . . . . 6
2.5. Application of Service Policy . . . . . . . . . . . . . . 6
2.6. Transport Dependence . . . . . . . . . . . . . . . . . . 7
2.7. Elastic Service Delivery . . . . . . . . . . . . . . . . 7
2.8. Traffic Selection Criteria . . . . . . . . . . . . . . . 7
2.9. Limited End-to-End Service Visibility . . . . . . . . . . 7
2.10. Classification/Reclassification per Service Function . . 7
2.11. Symmetric Traffic Flows . . . . . . . . . . . . . . . . . 8
2.12. Multi-vendor Service Functions . . . . . . . . . . . . . 8
3. Service Function Chaining . . . . . . . . . . . . . . . . . . 8
3.1. Service Overlay . . . . . . . . . . . . . . . . . . . . . 8
3.2. Service Classification . . . . . . . . . . . . . . . . . 9
3.3. SFC Encapsulation . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. Informative References . . . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 3
2. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Topological Dependencies . . . . . . . . . . . . . . . . 5
2.2. Configuration Complexity . . . . . . . . . . . . . . . . 6
2.3. Constrained High Availability . . . . . . . . . . . . . . 6
2.4. Consistent Ordering of Service Functions . . . . . . . . 6
2.5. Application of Service Policy . . . . . . . . . . . . . . 6
2.6. Transport Dependence . . . . . . . . . . . . . . . . . . 7
2.7. Elastic Service Delivery . . . . . . . . . . . . . . . . 7
2.8. Traffic Selection Criteria . . . . . . . . . . . . . . . 7
2.9. Limited End-to-End Service Visibility . . . . . . . . . . 7
2.10. Classification/Reclassification per Service Function . . 7
2.11. Symmetric Traffic Flows . . . . . . . . . . . . . . . . . 8
2.12. Multi-vendor Service Functions . . . . . . . . . . . . . 8
3. Service Function Chaining . . . . . . . . . . . . . . . . . . 8
3.1. Service Overlay . . . . . . . . . . . . . . . . . . . . . 8
3.2. Service Classification . . . . . . . . . . . . . . . . . 9
3.3. SFC Encapsulation . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. Informative References . . . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
The delivery of end-to-end services often requires various service functions including traditional network service functions (for example, firewalls and server load balancers), as well as application-specific features such as HTTP header manipulation. Service functions may be delivered within the context of an isolated user (e.g., a tenant) or shared amongst many users or user groups.
端到端服务的交付通常需要各种服务功能，包括传统的网络服务功能（例如，防火墙和服务器负载平衡器），以及特定于应用程序的功能，例如HTTP头操纵。服务功能可以在独立用户（例如租户）的上下文中交付，也可以在多个用户或用户组之间共享。
Current deployment models for service functions are often tightly coupled to network topology and physical resources, thus resulting in relatively rigid and static deployments. The static nature of such deployments greatly reduces and, in many cases, limits the ability of an operator to introduce new or modify existing services and/or service functions. Furthermore there is a cascading effect: changing one or more elements of a service function chain often affects other elements in the chain and/or the network elements used to construct the chain.
当前服务功能的部署模型通常与网络拓扑和物理资源紧密耦合，从而导致相对刚性和静态的部署。此类部署的静态特性大大降低了运营商引入新服务或修改现有服务和/或服务功能的能力，在许多情况下，这限制了运营商的能力。此外，还有一种级联效应：更改服务功能链的一个或多个元素通常会影响链中的其他元素和/或用于构建链的网络元素。
This issue is particular acute in elastic service environments that require relatively rapid creation, destruction, or movement of physical or virtual service functions or network elements. Additionally, the transition to virtual platforms requires an agile service insertion model that supports elastic and very granular service delivery, post facto modification, and the movement of service functions and application workloads in the existing network. The service insertion model must also retain the network and service policies and the ability to easily bind service policy to granular information such as per-subscriber state.
在需要相对快速地创建、销毁或移动物理或虚拟服务功能或网络元素的弹性服务环境中，此问题尤其严重。此外，向虚拟平台的过渡需要一个灵活的服务插入模型，该模型支持弹性和非常细粒度的服务交付、事后修改以及现有网络中服务功能和应用程序工作负载的移动。服务插入模型还必须保留网络和服务策略，并能够轻松地将服务策略绑定到细粒度信息，如每个订户状态。
This document outlines the problems encountered with existing service deployment models for Service Function Chaining (SFC), which is often referred to simply as "service chaining" (in this document, the terms will be used interchangeably). Section 3 of this document highlights three key areas of WG focus for investigating solutions that address the current problems. The document highlights three key areas of WG focus for addressing the issues highlighted in this document that will form the basis for the possible WG solutions that address the current problems.
本文档概述了服务功能链接（SFC）的现有服务部署模型遇到的问题，SFC通常简称为“服务链接”（在本文档中，术语将互换使用）。本文件第3节强调了工作组关注的三个关键领域，以调查解决当前问题的解决方案。本文件强调了工作组关注的三个关键领域，以解决本文件中强调的问题，这些问题将构成工作组解决当前问题的可能方案的基础。
Classification: Locally instantiated matching of traffic flows against policy for subsequent application of the required set of network service functions. The policy may be customer, network, or service specific.
分类：本地实例化的流量与策略的匹配，用于后续应用所需的一组网络服务功能。该策略可能是特定于客户、网络或服务的。
Network Overlay: A logical network built, via virtual links or packet encapsulation, over an existing network (the underlay).
网络覆盖：通过虚拟链路或数据包封装，在现有网络（参考底图）上构建的逻辑网络。
Network Service: An offering provided by an operator that is delivered using one or more service functions. This may also be referred to as a composite service. The term "service" is used to denote a "network service" in the context of this document.
网络服务：由运营商提供的，使用一个或多个服务功能提供的服务。这也可以称为复合服务。术语“服务”在本文件上下文中用于表示“网络服务”。
Note: Beyond this document, the term "service" is overloaded with varying definitions. For example, to some a service is an offering composed of several elements within the operator's network, whereas for others a service, or more specifically a network service, is a discrete element such as a firewall. Traditionally, such services (in the latter sense) host a set of service functions and have a network locator where the service is hosted.
注意：除了本文档之外，“服务”一词还有各种不同的定义。例如，对于某些人来说，服务是由运营商网络中的几个元素组成的产品，而对于其他人来说，服务，或者更具体地说，网络服务，是一个离散元素，例如防火墙。传统上，此类服务（在后一种意义上）承载一组服务功能，并具有承载服务的网络定位器。
Service Function: A function that is responsible for specific treatment of received packets. A service function can act at various layers of a protocol stack (e.g., at the network layer or other OSI layers). As a logical component, a service function can be realized as a virtual element or be embedded in a physical network element. One or more service functions can be embedded in the same network element. Multiple occurrences of the service function can exist in the same administrative domain.
服务功能：负责对接收到的数据包进行特定处理的功能。服务功能可以在协议栈的各个层（例如，在网络层或其他OSI层）上起作用。作为逻辑组件，服务功能可以作为虚拟元素实现，也可以嵌入到物理网元中。一个或多个服务功能可以嵌入到同一网元中。同一管理域中可能存在多次服务功能。
A non-exhaustive list of service functions includes: firewalls, WAN and application acceleration, Deep Packet Inspection (DPI), server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header enrichment functions, and TCP optimizers.
服务功能的非详尽列表包括：防火墙、WAN和应用程序加速、深度数据包检查（DPI）、服务器负载平衡器、NAT44[RFC3022]、NAT64[RFC6146]、HTTP标头扩展功能和TCP优化器。
The generic term "L4-L7 services" is often used to describe many service functions.
通用术语“L4-L7服务”通常用于描述许多服务功能。
Service Function Chain (SFC): A service function chain defines an ordered or partially ordered set of abstract service functions (SFs) and ordering constraints that must be applied to packets, frames, and/or flows selected as a result of classification. An example of an abstract service function is a firewall. The implied order may not be a linear progression as the architecture allows for SFCs that copy to more than one branch, and also allows for cases where there is flexibility in the order in which service functions need to be applied. The term "service chain" is often used as shorthand for "service function chain".
服务功能链（SFC）：服务功能链定义了一组有序或部分有序的抽象服务功能（SF）和排序约束，这些约束必须应用于作为分类结果选择的数据包、帧和/或流。抽象服务功能的一个例子是防火墙。隐含顺序可能不是线性级数，因为体系结构允许SFC复制到多个分支，并且还允许在需要应用服务功能的顺序中具有灵活性的情况。术语“服务链”通常用作“服务功能链”的缩写。
Service Overlay: An overlay network created for the purpose of forwarding data to required service functions.
服务覆盖：为将数据转发至所需服务功能而创建的覆盖网络。
Service Topology: The service overlay connectivity forms a service topology.
服务拓扑：服务覆盖连接形成服务拓扑。
The following points describe aspects of existing service deployments that are problematic and that the SFC working group aims to address.
以下几点描述了现有服务部署中存在问题的方面，以及SFC工作组旨在解决的问题。
Network service deployments are often coupled to network topology, whether it be physical, virtualized, or a hybrid of the two. For example, use of a firewall requires that traffic flow through the firewall, which means placing the firewall on the network path (often via creation of VLANs) or architecting the network topology to steer traffic through the firewall. Such dependency imposes constraints on service delivery, potentially inhibiting the network operator from optimally utilizing service resources, and reduces flexibility. This limits scale, capacity, and redundancy across network resources.
网络服务部署通常与网络拓扑相耦合，无论是物理、虚拟还是两者的混合。例如，使用防火墙需要流量通过防火墙，这意味着将防火墙置于网络路径上（通常通过创建VLAN）或构建网络拓扑以引导流量通过防火墙。这种依赖性对服务交付施加了限制，可能会抑制网络运营商优化利用服务资源，并降低灵活性。这限制了网络资源的规模、容量和冗余。
These topologies serve only to "insert" the service function (i.e., ensure that traffic traverses a service function); they are not required from a native packet delivery perspective. For example, firewalls often require an "in" and "out" Layer 2 segment and adding a new firewall requires changing the topology (i.e., adding new Layer 2 segments and/or IP subnets).
这些拓扑结构仅用于“插入”服务功能（即，确保流量通过服务功能）；从本机数据包交付的角度来看，它们不是必需的。例如，防火墙通常需要“入”和“出”第2层网段，添加新防火墙需要更改拓扑（即，添加新的第2层网段和/或IP子网）。
As more service functions are required -- often with strict ordering -- topology changes are needed in "front" and "behind" each service function, resulting in complex network changes and device configuration. In such topologies, all traffic, whether a service function needs to be applied or not, often passes through the same strict order.
由于需要更多的服务功能（通常具有严格的顺序），每个服务功能的“前端”和“后端”都需要进行拓扑更改，从而导致复杂的网络更改和设备配置。在这种拓扑中，所有通信量，无论是否需要应用服务功能，通常都通过相同的严格顺序。
The topological coupling limits placement and selection of service functions: service functions are "fixed" in place by topology. Therefore, placement and service function selection that take into account network topology information such as load, new links, or traffic engineering are often not possible.
拓扑耦合限制了服务功能的放置和选择：服务功能通过拓扑“固定”在适当的位置。因此，考虑网络拓扑信息（如负载、新链路或流量工程）的布局和服务功能选择通常是不可能的。
A common example is web servers using a server load balancer as the default gateway. When the web service responds to non-load-balanced traffic (e.g., administrative or backup operations), all traffic from the server must traverse the load balancer, forcing network administrators to create complex routing schemes or additional interfaces to provide an alternate topology.
一个常见的例子是使用服务器负载平衡器作为默认网关的web服务器。当web服务响应非负载平衡流量（例如，管理或备份操作）时，来自服务器的所有流量都必须通过负载平衡器，迫使网络管理员创建复杂的路由方案或附加接口以提供备用拓扑。
A direct consequence of topological dependencies is the complexity of the entire configuration, specifically in deploying service function chains. Simple actions such as changing the order of the service functions in a service function chain require changes to the logical and/or physical topology. However, network operators are hesitant to make changes to the network once services are installed, configured, and deployed in production environments for fear of misconfiguration and consequent downtime. All of this leads to very static service delivery deployments. Furthermore, the speed at which these topological changes can be made is not rapid or dynamic enough, as it often requires manual intervention or use of slow provisioning systems.
拓扑依赖性的直接后果是整个配置的复杂性，特别是在部署服务功能链时。更改服务功能链中服务功能的顺序等简单操作需要更改逻辑和/或物理拓扑。但是，一旦服务在生产环境中安装、配置和部署，网络运营商就会犹豫是否要对网络进行更改，因为他们担心配置错误和导致停机。所有这些都会导致非常静态的服务交付部署。此外，这些拓扑更改的速度不够快或不够动态，因为它通常需要手动干预或使用缓慢的资源调配系统。
Since traffic reaches many service functions based on network topology, alternate or redundant service functions must be placed in the same topology as the primary service.
由于流量根据网络拓扑到达许多服务功能，因此备用或冗余服务功能必须与主服务放在同一拓扑中。
An effect of topological dependency is that the availability of service functions is constrained.
拓扑依赖的一个影响是服务功能的可用性受到约束。
Service functions are typically independent; service function_1 (SF1)...service function_n (SFn) are unrelated, and there is no notion at the service layer that SF1 occurs before SF2. However, to an administrator, many service functions have a strict ordering that must be in place, yet the administrator has no consistent way to impose and verify the ordering of the service functions that are used to deliver a given service. Furthermore, altering the order of a deployed chain is complex and cumbersome.
服务功能通常是独立的；服务功能_1（SF1）…服务功能_n（SFn）是不相关的，在服务层没有SF1出现在SF2之前的概念。但是，对于管理员来说，许多服务功能都必须有严格的顺序，但是管理员没有一致的方法来实施和验证用于提供给定服务的服务功能的顺序。此外，更改已部署链的顺序既复杂又麻烦。
Service functions rely on topology information such as VLANs or packet classification/reclassification to determine service policy selection, i.e., the service function specific action taken. Topology information is increasingly less viable due to scaling, tenancy, and complexity reasons. Topology-centric information often does not convey adequate information to the service functions, forcing functions to individually perform more granular classification. In other words, the topology information is not granular enough, and its semantics is often overloaded.
服务功能依赖于拓扑信息，如VLAN或数据包分类/重新分类，以确定服务策略选择，即所采取的服务功能特定操作。由于扩展、租赁和复杂性的原因，拓扑信息的可行性越来越低。以拓扑为中心的信息通常不能向服务功能传递足够的信息，迫使功能单独执行更细粒度的分类。换句话说，拓扑信息不够细粒度，其语义常常过载。
Service functions can and will be deployed in networks with a range of network transports, including network under and overlays, such as Ethernet, Generic Routing Encapsulation (GRE), Virtual eXtensible Local Area Network (VXLAN), MPLS, etc. The coupling of service functions to topology may require service functions to support many transport encapsulations or for a transport gateway function to be present.
服务功能可以并将部署在具有一系列网络传输的网络中，包括网络下和覆盖，如以太网、通用路由封装（GRE）、虚拟可扩展局域网（VXLAN）、MPLS、，等。服务功能与拓扑的耦合可能需要服务功能支持许多传输封装，或者需要存在传输网关功能。
Given that the current state of the art for adding/removing service functions largely centers around VLANs and routing changes, rapid changes to the deployed service capacity (increasing or decreasing) can be hard to realize due to the risk and complexity of VLANs and/or routing modifications.
鉴于当前添加/删除服务功能的技术水平主要围绕VLAN和路由更改，由于VLAN和/或路由修改的风险和复杂性，很难实现对已部署服务容量的快速更改（增加或减少）。
Traffic selection is coarse; that is, all traffic on a particular segment traverses all service functions whether or not the traffic requires service enforcement. This lack of traffic selection is largely due to the topological nature of service deployment since the forwarding topology dictates how (and what) data traverses which service function(s). In some deployments, more granular traffic selection is achieved using policy routing or access control filtering. This results in operationally complex configurations and is still relatively coarse and inflexible.
交通选择粗糙；也就是说，特定网段上的所有流量都会遍历所有服务功能，而不管该流量是否需要服务强制。缺少流量选择主要是由于服务部署的拓扑性质，因为转发拓扑决定了数据如何（以及什么）遍历哪些服务功能。在某些部署中，可以使用策略路由或访问控制筛选来实现更细粒度的流量选择。这导致操作上的复杂配置，并且仍然相对粗糙和不灵活。
Troubleshooting service-related issues is a complex process that involves both network-specific and service-specific expertise. This is especially the case when service function chains span multiple data centers or cross administrative boundaries. Furthermore, the physical and virtual environments (network and service) can be highly divergent in terms of topology, and that topological variance adds to these challenges.
解决与服务相关的问题是一个复杂的过程，涉及特定于网络和特定于服务的专业知识。当服务功能链跨越多个数据中心或跨管理边界时尤其如此。此外，物理和虚拟环境（网络和服务）在拓扑方面可能存在高度差异，拓扑差异增加了这些挑战。
Classification occurs at each service function, independent from previously applied service functions since there are limited mechanisms to share the detailed classification information between services. The classification functionality often differs between service functions, and service functions may not leverage the classification results from other service functions.
分类发生在每个服务功能处，独立于以前应用的服务功能，因为在服务之间共享详细分类信息的机制有限。分类功能通常在服务功能之间有所不同，并且服务功能可能不会利用来自其他服务功能的分类结果。
Service function chains may be unidirectional or bidirectional depending on the state requirements of the service functions. In a unidirectional chain, traffic is passed through a set of service functions in one forwarding direction only. Bidirectional chains require traffic to be passed through a set of service functions in both forwarding directions. Many common service functions such as DPI and firewalls often require bidirectional chaining in order to ensure flow state is consistent.
根据服务功能的状态要求，服务功能链可以是单向的或双向的。在单向链中，流量仅在一个转发方向上通过一组服务功能。双向链要求流量在两个转发方向上通过一组服务功能。许多公共服务功能（如DPI和防火墙）通常需要双向链接，以确保流状态一致。
Existing service deployment models provide a static approach to realizing forward and reverse associations of service function chains, most often requiring complex configuration of each network device throughout the SFC. In other words, the same complex network configuration must be in place for both "directions" of the traffic, effectively doubling the configuration and associated testing. Further, if partial symmetry is required (i.e., only some of the services in the chain required symmetry), the network configuration complexity increases since the operator must ensure that the exceptions -- the services that do not need the symmetry flow -- are handled correctly via unique configuration to account for their requirements.
现有的服务部署模型提供了实现服务功能链正向和反向关联的静态方法，通常需要在整个SFC中对每个网络设备进行复杂配置。换句话说，相同的复杂网络配置必须适用于两个“方向”的流量，有效地将配置和相关测试翻一番。此外，如果需要部分对称性（即，链中只有一些服务需要对称性），则网络配置复杂性会增加，因为运营商必须确保通过唯一配置正确处理异常（不需要对称流的服务），以满足其需求。
Deploying service functions from multiple vendors often requires per-vendor expertise (insertion models differ, common attributes are few, and inter-vendor service functions do not share information), hence standards are needed to ensure interoperability.
从多个供应商部署服务功能通常需要每个供应商的专业知识（插入模型不同，公共属性很少，供应商间服务功能不共享信息），因此需要标准来确保互操作性。
Service function chaining aims to address the aforementioned problems associated with service deployment. Concretely, the SFC working group will investigate solutions that address the following elements.
服务功能链接旨在解决与服务部署相关的上述问题。具体而言，证监会工作组将调查解决以下问题的方案。
Service function chaining utilizes a service-specific overlay that creates the service topology. The service overlay provides service function connectivity, built "on top" of the existing network topology. It allows operators to use whatever overlay or underlay they prefer to create a path between service functions and to locate service functions in the network as needed.
服务功能链接利用创建服务拓扑的特定于服务的覆盖。服务覆盖提供服务功能连接，构建在现有网络拓扑的“顶部”。它允许运营商使用他们喜欢的任何覆盖或底图在服务功能之间创建路径，并根据需要在网络中定位服务功能。
Within the service topology, service functions can be viewed as resources for consumption and an arbitrary topology constructed to connect those resources in a required order. Adding new service functions to the topology is easily accomplished, and no underlying network changes are required.
在服务拓扑中，可以将服务功能视为可供使用的资源，以及按所需顺序连接这些资源的任意拓扑。向拓扑中添加新的服务功能很容易完成，并且不需要对底层网络进行任何更改。
Lastly, the service overlay can provide service-specific information needed for troubleshooting service-related issues.
最后，服务覆盖可以提供解决服务相关问题所需的特定于服务的信息。
Classification is used to select which traffic enters a service overlay. The granularity of the classification varies based on device capabilities, customer requirements, and services offered. Initial classification determines the service function chain required to process the traffic. Subsequent classification can be used within a given service function chain to alter the sequence of service functions applied. Symmetric classification ensures that forward and reverse chains are in place. Similarly, asymmetric -- relative to required service function -- chains can be achieved via service classification.
分类用于选择进入服务覆盖的流量。分类的粒度因设备功能、客户需求和提供的服务而异。初始分类确定处理流量所需的服务功能链。在给定的服务功能链中，可以使用后续分类来改变应用的服务功能顺序。对称分类确保正向和反向链就位。类似地，非对称（相对于所需的服务功能）链可以通过服务分类来实现。
The SFC encapsulation enables the creation of a service chain in the data plane and can convey information about the chain such as chain identification and OAM status.
SFC封装支持在数据平面中创建服务链，并可以传递有关该链的信息，例如链标识和OAM状态。
The SFC encapsulation also carries data-plane metadata that provides the ability to exchange information between logical classification points and service functions (and vice versa) and between service functions. Metadata is not used as forwarding information to deliver packets along the service overlay.
SFC封装还携带数据平面元数据，该元数据提供了在逻辑分类点和服务功能（反之亦然）之间以及服务功能之间交换信息的能力。元数据不用作沿服务覆盖传送数据包的转发信息。
Metadata can include the result of antecedent classification and/or information from external sources. Service functions utilize metadata, as required, for localized policy decisions.
元数据可以包括先行分类的结果和/或来自外部源的信息。服务功能根据需要利用元数据进行本地化策略决策。
In addition to sharing of information, the use of metadata addresses several of the issues raised in Section 2, most notably by decoupling policy from the network topology, and by removing the need for classification (and reclassification) per service function as described in Section 2.10.
除了信息共享外，元数据的使用还解决了第2节中提出的几个问题，最显著的是通过将策略与网络拓扑分离，以及通过消除第2.10节中所述的每个服务功能的分类（和重新分类）需要。
A common approach to service metadata creates a foundation for interoperability between service functions, regardless of vendor.
服务元数据的通用方法为服务功能之间的互操作性提供了基础，而不管供应商。
Although this problem statement does not introduce any protocols, when considering service function chaining, the three main areas begin investigated (see Section 3) by the WG have security aspects that warrant consideration.
尽管这个问题陈述没有引入任何协议，但在考虑服务功能链接时，工作组开始调查的三个主要领域（见第3节）具有值得考虑的安全方面。
Service Overlay: The service overlay will be constructed using existing transport protocols (e.g., MPLS, VXLAN) and as such is subject to the security specifics of the transport selected. If an operator requires authenticity and/or confidentiality in the service overlay, a transport (e.g., IPsec) that provides such functionally can be used.
服务覆盖：服务覆盖将使用现有传输协议（如MPLS、VXLAN）构建，因此受所选传输的安全细节的约束。如果运营商要求服务覆盖中的真实性和/或机密性，则可以使用提供此类功能的传输（如IPsec）。
Classification: Since classification is used to select the appropriate service overlay and the required service encapsulation details, classification policy must be both accurate and trusted. Conveying the policy to an SFC edge node (a node that forms the logical boundary of an SFC domain) may be done via a multitude of methods depending on an operator's existing provisioning practices and security posture.
分类：由于分类用于选择适当的服务覆盖和所需的服务封装详细信息，因此分类策略必须准确可靠。可以通过多种方法将策略传送到SFC边缘节点（形成SFC域的逻辑边界的节点），这取决于运营商的现有供应实践和安全态势。
Additionally, traffic entering the SFC domain and being classified may be encrypted, thus limiting the granularity of classification. The use of pervasive encryption varies based on type of traffic, environment, and level of operator control. For instance, a large enterprise can mandate how encryption is used by its users, whereas a broadband provider likely does not have the ability to do so.
此外，进入SFC域并被分类的流量可以被加密，从而限制分类的粒度。普及加密的使用因流量类型、环境和操作员控制级别而异。例如，一家大型企业可以强制要求其用户如何使用加密，而宽带提供商可能没有能力这样做。
The use of encrypted traffic, however, does not obviate the need for SFC (nor the problems associated with current deployment models described herein); rather, when encrypted traffic must be classified, the granularity of such classification must adapt. In such cases, service overlay selection might occur using outer (i.e., unencrypted) header information (in the presence of encryption) or external information about the packets.
然而，使用加密通信量并不能消除对SFC的需要（也不能排除与本文描述的当前部署模型相关的问题）；相反，当必须对加密的流量进行分类时，这种分类的粒度必须适应。在这种情况下，服务覆盖选择可能使用外部（即，未加密的）报头信息（在存在加密的情况下）或关于分组的外部信息来进行。
SFC Encapsulation: As described in Section 3, the SFC encapsulation carries information about the SFC and data-plane metadata. Depending on the environment and security posture, the SFC encapsulation might need to be authenticated and/or encrypted. The use of an appropriate overlay transport (as described above) can provide data-plane confidentiality and authenticity.
SFC封装：如第3节所述，SFC封装包含有关SFC和数据平面元数据的信息。根据环境和安全状况，可能需要对SFC封装进行身份验证和/或加密。使用适当的覆盖传输（如上所述）可以提供数据平面机密性和真实性。
The exchange of SFC encapsulation data such as metadata must originate from trusted source(s). Also, if needed, authentication and confidentiality protection should be provided during the exchange to the various SFC nodes.
SFC封装数据（如元数据）的交换必须来自受信任的源。此外，如果需要，应在交换期间向各个SFC节点提供身份验证和保密保护。
SFC and Multi-tenancy: If tenant isolation is required in an SFC deployment, an appropriate network transport overlay that provides adequate isolation and identification can be used. Additionally, tenancy might be used in the selection of the appropriate service chain; however, as stated, the network overlay is still required to provide transport isolation. SF deployment and how specific SFs might or might not be allocated per tenant are outside the scope of this document.
SFC和多租户：如果在SFC部署中需要租户隔离，则可以使用提供充分隔离和标识的适当网络传输覆盖。此外，租赁可用于选择适当的服务链；然而，如上所述，仍然需要网络覆盖来提供传输隔离。SF部署以及如何为每个租户分配特定SF不在本文档范围内。
The SFC Architecture document [SFC-ARCH] presents a more complete review of the security implications of a complete SFC architecture.
证监会架构文件[SFC-ARCH]对完整的证监会架构的安全影响进行了更全面的审查。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001, <http://www.rfc-editor.org/info/rfc3022>.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 30222001年1月<http://www.rfc-editor.org/info/rfc3022>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年4月<http://www.rfc-editor.org/info/rfc6146>.
[SFC-ARCH] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", Work in Progress, draft-ietf-sfc-architecture-07, March 2015.
[SFC-ARCH]Halpern，J.和C.Pignataro，“服务功能链（SFC）架构”，正在进行的工作，草稿-ietf-SFC-Architecture-072015年3月。
Acknowledgments
致谢
The authors would like to thank David Ward, Rex Fernando, David McDysan, Jamal Hadi Salim, Charles Perkins, Andre Beliveau, Joel Halpern, and Jim French for their reviews and comments.
作者要感谢David Ward、Rex Fernando、David McDysan、Jamal Hadi Salim、Charles Perkins、Andre Beliveau、Joel Halpern和Jim French的评论和评论。
Additionally, the authors would like to thank the IESG and Benjamin Kaduk for their detailed reviews and suggestions.
此外，作者还要感谢IESG和Benjamin Kaduk的详细评论和建议。
Contributors
贡献者
The following people are active contributors to this document and have provided review, content and concepts (listed alphabetically by surname):
以下人员是本文档的积极贡献者，他们提供了评论、内容和概念（按姓氏字母顺序列出）：
Puneet Agarwal Broadcom EMail: pagarwal@broadcom.com
Puneet Agarwal Broadcom电子邮件：pagarwal@broadcom.com
Mohamed Boucadair France Telecom EMail: mohamed.boucadair@orange.com
Mohamed Boucadair法国电信电子邮件：Mohamed。boucadair@orange.com
Abhishek Chauhan Citrix EMail: Abhishek.Chauhan@citrix.com
阿披实Chauhan Citrix电子邮件：阿披实。Chauhan@citrix.com
Uri Elzur Intel EMail: uri.elzur@intel.com
urielzur英特尔电子邮件：Uri。elzur@intel.com
Kevin Glavin Riverbed EMail: Kevin.Glavin@riverbed.com
凯文·格拉文：电子邮件：凯文。Glavin@riverbed.com
Ken Gray Cisco Systems EMail: kegray@cisco.com
Ken Gray Cisco Systems电子邮件：kegray@cisco.com
Jim Guichard Cisco Systems EMail:jguichar@cisco.com
Jim Guichard Cisco Systems电子邮件：jguichar@cisco.com
Christian Jacquenet France Telecom EMail: christian.jacquenet@orange.com
Christian Jacquenet法国电信电子邮件：Christian。jacquenet@orange.com
Surendra Kumar Cisco Systems EMail: smkumar@cisco.com
Surendra Kumar Cisco Systems电子邮件：smkumar@cisco.com
Nic Leymann Deutsche Telekom EMail: n.leymann@telekom.de
Nic Leymann德国电信电子邮件：n。leymann@telekom.de
Darrel Lewis Cisco Systems EMail: darlewis@cisco.com
Darrel Lewis Cisco Systems电子邮件：darlewis@cisco.com
Rajeev Manur Broadcom EMail:rmanur@broadcom.com
Rajeev Manur Broadcom电子邮件：rmanur@broadcom.com
Brad McConnell Rackspace EMail: bmcconne@rackspace.com
Brad McConnell Rackspace电子邮件：bmcconne@rackspace.com
Carlos Pignataro Cisco Systems EMail: cpignata@cisco.com
Carlos Pignataro Cisco Systems电子邮件：cpignata@cisco.com
Michael Smith Cisco Systems EMail: michsmit@cisco.com
Michael Smith Cisco Systems电子邮件：michsmit@cisco.com
Navindra Yadav Cisco Systems EMail: nyadav@cisco.com
Navindra Yadav思科系统电子邮件：nyadav@cisco.com
Authors' Addresses
作者地址
Paul Quinn (editor) Cisco Systems, Inc.
保罗·奎因（编辑）思科系统公司。
EMail: paulq@cisco.com
EMail: paulq@cisco.com
Thomas Nadeau (editor) Brocade
托马斯·纳多（编辑）博科
EMail: tnadeau@lucidvision.com
EMail: tnadeau@lucidvision.com