软件定义网络（SDN）技术原理详解

一、SDN相关概念

1、大二层网络

互联网时代，用户的访问称之为南北向流量，而数据中心之间的数据传递成为东西向流量。

很多情况下，需要不同的数据中心之间进行数据访问，数据同步。而去同步这些流量要求对这个安全性，以及稳定性有一定的挑战。而让这些数据中心网络变成一个看起来大的逻辑二层网络的技术，叫做虚拟网络技术，这个逻辑性大的网络，则为二层网络，目前大二层网络存在于数据中心的虚拟化方向相关，云计算等等的主要网络技术。

实现不同数据通信依靠vlan直接进行通信，故二层通信，本质是打隧道，让数据跟进隧道进行转发，有点类似与mpls（隧道转发），不过建立隧道之间，需要这些数据中心的路由是可达的，保证三层能够互通的情况下，建立隧道，提供高速安全的数据访问。

mpls种类是真的多，有MPLS L2VPN 、MPLS L3VPN 、LDP 、mlps 6vpn/6pe 、mpls TE，它们都有一个共同点，依赖LDP协议（标签分发），这个LDP也是一个Mpls的一个主要协议。

mlps 6vpn/6pe：一种过渡技术，允许零散的ipv6网络，穿过ipv4的隧道，去访问另外一端的ipv6网络
mpls l2vpn：可以提供点到点或者点到多点的一个服务，依据私网的mac进行转发用户报文，（二层vpn）
mpls l3vpn：这个是一个比较经典的三层vpn技术了，基于pe的三层vpn技术（pe：lsp两端的路由器，提供标签交换最早的路由器设备）
mpls Te：这个是mpls的流量工程，能够实现高优先级的流量去占用低优先级的lsp带宽。

2、SDN相关术语

下面是SDN技术的相关术语。

软件定义网络(SDN)：软件定义网络(SDN)可以构建出一种开放可编程的网络环境，它通过对底层各种网络资源虚拟化的基础上，实现对网络的集中控制和管理。
软件定义局域网(SD-LAN)：即以软件定义网络为基础的局域网，可以创造出一种灵活、节省成本的无线和有线接入网。
软件定义广域网(SD-WAN)：即以软件定义网络为基础的广域网，常用来连接区域跨度较大的企业与其数据中心。
OpenFlow：OpenFlow是一种配置flows、flowtable和TCAMs的协议。
OpenDaylight：OpenDaylight是以Linux平台主导的一种开放式标准控制器。
OpenStack：OpenStack是一种开放源码的云操作系统，用来创造和管理云资源。
CloudStack：CloudStack是一种开放源码的云计算软件，用来创造、管理和部署云服务基础架构。
Orchestration：Orchestration是一种自动创造、初始化、协调和管理云服务传递所需的物理和虚拟资源的系统。
OSS：OSS是一种短时运维支撑系统，可以帮助服务运营商监控、分析和管理电话或计算机网络。
SDN控制器：SDN控制器是软件定义网络(SDN)中的应用程序，负责流量控制以确保智能网络。它的以OpenFlow等协议为基础，允许服务器告诉交换机向哪里发送数据包。
白盒交换机：也叫openflow交换机，是一种预安装第三方网络操作系统的消费类交换机硬件。
NFV（Network Functions Virtualization 网络功能虚拟化）：一种针对网络架构的概念，利用虚拟化技术，将网络节点阶层的功能，分割成几个功能区块，分别以软件方式实作，不再局限于硬件架构。

3、SDN相关协议

作为一种新型技术，下面是SDN技术的相关协议内容。

数据中心：bgp evpn vxlan、vxlan

sdn技术：pcep、bgp-ls，OpenFlow，ovsdb，SR/SRv6、netconf，bgp flowspec

SDN最常见的协议是OpenFlow，但是除了OpenFlow外，下列协议也可以用于SDN。

OpenFlow协议：OpenFlow是软件定义网络(SDN)的第一代标准协议，它定义了一种开放式协议，使得SDN控制器可以和网络设备的转发平台相互作用。
NETCONF协议：由RFC 6241定义，用以替代命令行界面(CLI，command line interface)、简单网络管理协议(SNMP，Simple Network Management Protocol)以及其它专有配置机制。管理软件可以使用NETCONF协议将配置数据写入设备，也可从设备中检索数据。
OF-Config协议：OF-Config协议是配置OpenFlow交换机的一种协议，它的主要功能包括配置交换机连接的多个控制器信息、端口和队列等资源的配置和分配以及端口等资源的状态修改等。
XMPP协议：XMPP是一种基于标准通用标记语言的子集XML的协议，它继承了在XML环境中灵活的发展性。
OpFlex协议：它是由思科(Cisco)推出的OpenFlow协议的替代品。OpFlex协议旨在保持网络基础设施硬件作为可编程网络的基础控制元件。

sr与srv6的原理不同，一个是标签转发和igp协议拓展，一个是ipv6头部拓展字段的利用&利用该字段中的SRH信息进行转发。

vxlan归类与数据中心的应用，他是用来打隧道的，与SDN有一定的关联性。其他的八种归类为带有SDN属性的协议。SDN也就是让网络拥有编程的能力，通过程序去更加动态的调整网络资源，对网络资源进行分配，这是后续21世纪的主流趋势。

其中openflow和ovsdb这两个主要是在PCC（计算机控制器，负责运算编程的大脑）上工作的，主要作用就是控制器与多个交换机进行通信，让交换机去接收控制器的lsp信息，使得交换机形成多个不同的隧道。然后数据通过这些隧道进行快速的转发。提高网络质量以及容量，而SR、SRv6的目的，同样也是实现这个同一的目标。

二、SDN概述

1、SDN产生背景

当前路由协议的一个弊端是主要路由算法部分占很少，大部分都是用来维护拓扑和邻居关系的，比如RIP、OSPF、IS-IS等，该点被定义被distribution system，为了解决这个问题，于是有了SDN。

软件定义网络(SDN)提供了较高的可编程性，使网络扩展、系统设计和管理更加简单。即SDN实际上是把不同协议间的相同部分，即distrilbuted system给综合在Network OS中，而路由算法就变成了APP了，所以路由协议并没有消失，而是成为了另一种形态。

SDN是一种存在逻辑上集中控制的新型网络结构，其主要特征是数据平面与控制平面分离，数据平面与控制平面之间通过标准的开放接口OpenFlow实现信息交互。

SDN吸取了计算模式从封闭、集成、专用的系统进化为开放系统的经验，通过将传统封闭的网络设备中的数据平面与控制平面分离，实现网络硬件与控制软件分离，制定开放的标准接口，允许网络软件开发者与网络管理员通过编程控制网络，将传统的专用网络设备变为可通过编程定义的标准化通用网络设备。

SDN可以实现一切协议，也可以废弃一切协议，是因为SDN根本跟控制协议就不在一个层面上。

SDN解决的问题是把协议的实现从硬件层剥离出来，把硬件用统一的模型来描述，把除了统一模型以外的部分变成流表和控制器。通过流表和控制器可以实现任意的网络协议，自然也包括传统控制协议。升级控制器就能让SDN网络支持更多的协议。

从理性上来说，SDN再发达也不可能做到整个Internet用一个控制器来控制。路由交换协议是现代Internet的基础，所以不管是SDN实现的网络还是传统实现的网络，路由交换协议在可预见的未来还是绕不开的东西。

2、SDN网络抽象结构

SDN的网络抽象结构由四种抽象模型组成：控制平面抽象模型、转发平面、管理平面、操作平面。

将控制平面与数据平面接口、控制平面与应用平面接口分别称为南向（south bound）接口与北向（north bound）接口，将控制平面内部的SDN控制器之间的接口称为东向接口与西向接口。

传统网络设备实现网络功能的软件通常都会包含多个角色，我们可以将这些角色归类成独立工作的功能平面，这些功能平面通过专有或开放的API（Application Program Interface，应用程序接口）进行交互。从高层视角可以将这些角色分成如下4类。

控制平面：主要功能是确定数据流经设备时的路径、决定是否允许数据穿透设备、数据的排队行为以及数据所需的各种操作等，该角色称为控制平面。
转发平面：这部分软件的作用是根据控制平面的指令在设备上实现数据的转发、排队与处理，该角色称为转发平面或数据平面。因此，控制平面的职责是确定进入设备的数据的处理方式，而数据平面的职责则是根据控制平面的决定来执行具体操作。
管理平面：控制平面和转发平面负责处理数据流量，而管理平面则负责网络设备的配置、故障监控及资源管理。
操作平面：设备的运行状态由操作平面监控，操作平面可以直接查看所有设备实体。管理平面直接与操作平面进行协同工作，并利用操作平面检索设备的运行状况信息，同时还负责推送配置更新以管理设备的运行状态。

对于传统网络设备来说，这些平面完全耦合在一起并通过专有接口及协议进行通信，如下图所示。

SDN控制平面抽象模型支持用户在控制平面上通过编程控制网络，而无须关心数据平面实现的细节。通过统计分析网络状态信息，提供全局、实时的网络状态视图的抽象模型，网络控制平面能根据全局网络状态对路由进行优先安排、提高网络系统的安全性，使网络具有更强的管理、控制能力与安全性。

为了更好地解释这些概念，我们以路由器为例。负责路由器配置工作的管理平面提供了一种机制来定义主机名、要使用的接口IP地址、路由协议配置、用于QoS（Quality of Service，服务质量）的阈值及分类等参数，操作平面则负责监控接口的状态、CPU的消耗以及存储器的利用率等，并将这些资源的状态信息传送给管理平面以进行故障监控。路由器上运行的路由协议（通过管理平面进行定义）构成控制平面，可以预先确定数据流以建立路由查找表（称为RIB[Routing Information Base，路由信息库]），并将该数据映射到路由器的特定出接口。转发平面则使用该路由查找表并确定数据穿越该路由器的路径。

由于控制平面集成在设备软件中，因而网络架构具备分布式控制平面，每个节点都会执行自己的控制平面计算操作，而且这些控制平面之间可以相互交换信息。例如，运行在每台设备上的路由协议相互交换信息以确定整网拓扑或相互学习路由信息。虽然管理平面也随之本地化，但NMS（Network Management System，网络管理系统）通过在管理平面上增加一层管理层，从而实现了管理功能的集中化。

通常采用Syslog、SNMP（Simple Network Management Protocol，简单网络管理协议）和NetFlow等协议来执行监控操作，而配置操作则利用专有的CLI、API、SNMP或脚本来完成。

下图给出了传统网络设备的部署架构示意图：

可编程性是SDN的核心。编程人员只要掌握网络控制器API的编程方法，就可以写出控制各种网络设备（例如路由器、交换机、网关、防火墙、服务器、无线基站）的程序，而无需知道各种网络设备配置命令的具体语法、语义。控制器负责将API程序转化成指令去控制各种网络设备。新的网络应用也可以方便地通过API程序添加到网络中。开放的SDN体系结构将网络变得通用、灵活、安全，并支持创新。

3、SDN简介

SDN不是一种协议，而是一种开放的网络体系结构。

SDN是将传统的数据平面与控制平面紧耦合的结构，改变为数据平面与控制平面解耦分离的结构，将路由器的网络控制平面功能集中到SDN控制器。SDN路由器是可编程交换机。SDN控制器通过发布路由信息和控制命令，实现对路由器数据平面功能的控制。

SDN通过标准协议对网络的逻辑加以集中控制，实现对网络流量的灵活控制和管理，为核心网络及应用创新提供了良好的平台。

在SDN网络中，SDN并不是要取代路由器与交换机的控制平面，而是以整个网络视图的方式加强控制平面，根据动态的流量、延时、服务质量与安全状态，决定各个节点的路由和分组转发策略，然后将控制指令推送到路由器与交换机的控制平面，由控制平面操控数据平面的分组转发过程。

虽然SDN的目标是实现控制平面与转发平面分离，但并不强制要求将集中化的控制平面限定在单个节点上。为了实现可扩展性和高可用性，允许将控制平面进行水平扩展以形成控制平面集群，包含该集群功能的模块可以通过BGP（Border Gateway Protocol，边界网关协议）或PCEP（Path Computational Element Communication Protocol，路径计算单元通信协议）等协议进行通信，实现单一的集中控制平面。

下图给出了SDN的基本概念以及与传统网络架构的差异之处，需要注意的是，由于SDN的重点是控制平面和转发平面，因而图中并没有强调这些平面与硬件平面或操作平面以及管理平面之间的交互问题。

在SDN实现中，可以通过应用程序来管理控制平面，应用程序可以与控制平面及管理平面进行交互，从管理平面提取设备信息及设备配置，从控制平面提取网络拓扑结构和流量路径信息，因而应用程序拥有完整统一的网络视图，并利用这些信息做出可传递给控制平面或管理平面的处理决策，如下图所示。

图中还给出了北向和南向协议以及API的概念，这些术语的含义与使用它们的环境相关，图中给出的是SDN控制平面及管理平面应用场景，此时的南向协议指的是从控制平面或管理平面到底层平面的通信，管理平面和控制平面提供给上层平面（如应用层）的接口则称为北向API或北向协议。

这类应用的一个典型案例就是按需带宽，应用程序可以监控网络中的流量，并在一天中的某些时段或超过预定阈值时提供额外的流量路径，管理平面必须向应用程序提供有关网络接口的状态以及利用率等信息，控制平面则提供实时的转发拓扑，应用程序就通过这些信息来确定是否需要为特定流量提供额外的流量路径。可以使用用户自定义策略来预设应用程序的阈值，从而触发相应的操作，应用程序传达该操作的方式是指示管理平面提供新的流量路径并告知控制平面开始使用该流量路径。

4、SDN优势

最初引入SDN的时候，其优点并不足以使厂商或服务提供商坚定不移地朝着这个方向迈进。当时的网络扩展部署方案仍然采用部分自动化的配置及管理机制，控制平面与数据平面的紧耦合方式也没有成为网络扩展的重大瓶颈，因而当时的SDN主要停留在学术界，没有成为实用化、商业化技术。

后来网络逐渐面临指数级的规模增长需求，使得传统网络的扩展机制出现了大量限制因素。NFV就是网络行业开拓创新并采用新技术以摆脱厂商锁定障碍的一个成功案例，SDN则是另一个成功案例。从学术界到现实世界的应用部署，SDN并没有花费太多的时间，由于SDN能够实现灵活、可扩展、开放且可编程的网络，因而得到越来越广泛的应用部署。

下面将详细讨论SDN的一些重要优势，这些优势都与降低网络运营成本息息相关。

1. 可编程性与自动化

通过应用程序来控制网络的能力是SDN一个重要的优势，当前的网络需要具备更强大的网络恢复能力、大规模的可扩展性、更快速的部署机制以及运营费用的优化能力，但是由于人工处理流程无法提供快速处理机制，因而整个网络的运营不得不放慢速度，最大限度地使用自动化工具和应用程序已成为满足网络需要的必备条件，需要自动化和可编程能力来支持网络的随需配置、设备数据的监控与解析，而且还需要根据流量负荷情况、网络中断情况以及网络中发生的已知和未知事件进行实时更改。在传统意义上，厂商提供的解决方案主要面向它们自己的设备或OS（Operating System，操作系统），有时也会对外部设备提供有限的支持能力（如果有的话），根据网络上的逻辑和约束条件做出决策。

SDN解决方案将应用程序与网络相耦合，解决了手动控制与管理流程存在的问题。由于SDN将智能放在集中的控制设备（即SDN控制器）上，因而可以直接在控制器中构建自动响应预期事件和意外事件的程序及脚本。作为可选方式，应用程序也可以运行在控制器之上，利用北向API将逻辑传递给控制器，并最终传递给转发设备。应用程序可以处理故障以及越来越多的管理需求，实现故障的快速解决与恢复。这种方法可以显著减少服务宕机时间、缩短配置时间并提高设备与网络运营人员的比例，从而最大限度地降低运营成本。

2. 支持集中控制

控制平面集中化之后，可以更加容易地获得所有重要信息，控制逻辑的实现也就显得较为简单。SDN可以实现网络视图的统一化，简化网络控制逻辑，降低操作复杂性及维护成本。

3. 多厂商和开放式架构

由于SDN采用了标准化协议，因而打破了对供应商特定控制机制的依赖性。传统供应商提供的设备访问及设备配置方法都是专有方法，不易编程，而且在开发应用程序和脚本以实现某些配置及管理过程自动化时会遇到很多障碍，特别是在混合供应商（甚至是混合OS）环境中，应用程序必须考虑设备接口的变化和差异。此外，如果供应商在实现标准的控制平面协议时存在差异（可能是解析差异），那么就可能会导致互操作性问题。这些挑战长期存在于传统网络中，但是SDN将设备的控制平面释放出来，仅留下数据平面，因而潜在解决了混合供应商部署环境下的控制平面互操作性问题。

4. 简化网络设备

网络设备的控制平面通常会占用大量网络资源（尤其是运行了多种协议的网络设备），并在这些协议之间传递各种信息（如内部路由、外部路由和标签等），然后在本地存储这些信息，同时还运行其他协议逻辑以利用数据进行路径计算，这些操作都会给设备带来不必要的开销，并限制其扩展性和性能。由于SDN将这些开销都从设备中剥离，让网络设备专注于主要职责（转发数据），将设备的处理资源和内存资源释放出来，因而大大降低了设备成本、简化了软件实现，从而获得了更好的可扩展性，实现设备资源的最佳利用。

三、SDN实现原理

如前所述，SDN的核心理念是分离控制平面，将控制平面从转发平面中分离出来。实现该目标的一种直接方式就是在外部设备（称为SDN控制器）上实现控制平面的功能，将转发平面功能留在数据路径中的设备上。

不过，随着大家越来越深入地了解SDN的理念，就会发现可以通过多种方式来实现集中控制以及简化数据平面的基本目标。

1、SDN控制器简介

SDN控制器是一种实现SDN控制平面功能的独立设备，负责将控制平面的决策信息传递给网络设备。与此同时，SDN控制器还能从网络设备检索信息，以做出合理的控制平面决策。SDN控制器通过SDN控制协议与网络设备进行通信。

从地理位置的角度来看，SDN控制器不需要与网络设备部署在同一个地理位置上，只要能够与它们所控制的网络设备进行通信即可。目前业界提供了多种开源及商用SDN控制器，后面将详细讨论这些SDN控制器的相关内容。

2、SDN实现模型

从技术角度来看，供应商将网络设备的控制平面完全分离出来并让网络设备执行单纯的转发功能并非始终可行，因而供应商们采用了不同的方法来实现SDN，与我们目前讨论的SDN实现机制并非完全一致。服务提供商们也面临着很多实际操作困难，很难将自己的网络完全迁移到SDN，因而有可能采用某种替代方案来部署SDN，只要这些替代实现方案能够充分享受SDN带来的好处，能够实现控制平面与转发平面的分离，就是有效的SDN实现方式。

常见的SDN实现方式主要有如下3种。

1. 开放（经典）SDN

该方法是实现控制平面与转发平面相分离的经典实现方式。由于供应商研发的网络设备还暂时无法实现这一目标，因而这种方式利用SDN支持层（SDN Support Layer）来代替本地控制平面，以实现SDN的支持能力。

新的SDN支持层能够与SDN控制器以及设备的转发平面协同工作，使得网络设备具备通过SDN协议与SDN控制器进行通信的能力，而且还能直接控制转发平面，如下图所示。

2. 混合SDN

很多供应商都采用了通过SDN支持层修改设备控制平面的SDN实现方式，并声称其设备已支持SDN。但是这并不意味着设备的本地控制平面已不复存在，本地智能仍然可以与外部控制器实现的控制平面协同工作。

对于这种实现方式来说，由于设备会运行自己的（分布式）本地控制平面，并由外部SDN控制器通过修改这些协议使用的路由参数或者直接修改转发平面来增强设备的智能，因而将该实现方法称为混合SDN，如下图所示。

请注意，与经典SDN实现方式相比，混合SDN实现方式的主要区别在于设备仍然使用本地控制平面。

3. 通过API实现SDN

有些供应商通过提供用于部署、配置和管理设备的API来实现SDN，应用程序可以通过API控制设备的转发平面，等同于控制器与网络设备之间使用的南向API。不过，由于API可以直接插入到应用程序中，因而这种SDN实现方式可能不需要使用标准南向协议的SDN控制器。

与供应商一直使用的私有CLI（Command-Line Interface，命令行接口）相比，该实现方式是向更加协作化和开放化的方向进行转变，但很难做到真正的开放性，因为这些API很可能无法实现多供应商之间的兼容性，因而并没有真正解决私有性问题。使用这种基于API的SDN实现方式的应用程序必须知道它们正在与哪些供应商的设备进行通信，从而能够使用正确的API。

支持这种SDN实现方式的观点认为，该实现方式允许应用程序影响转发决策，而且任何想要构建应用程序和使用API的人都能公开使用API，因而实现了SDN的核心目标。虽然这种方式让网络具备了可编程性，但灵活性不足（因为私有的南向API）。部分供应商通过提供自己的控制器来解决灵活性问题，这些控制器使用私有的南向API（面向网络设备）和标准的北向API。

下图给出了通过API实现SDN的实现方案：

4. 通过叠加方式实现SDN

从网络中分离控制平面的另一种方法是在现有网络之上创建独立的叠加网络，该实现方式中的底层网络仍然拥有采用传统方式进行本地管理的控制平面。不过，对于叠加网络来说，该底层网络实质上仅提供连接并转发数据。

对于网络用户来说，底层网络及其拓扑结构和控制平面都是透明的，叠加网络就是与用户进行交互的网络。该实现方式下的用户可以通过外部控制器来管理叠加网络，不需要构成底层网络的设备支持任何SDN功能。该SDN网络实现方式符合SDN的基本要求，唯一的约束条件就是要求底层设备必须支持实现叠加网络的协议。前面讨论了虚拟网络的概念，虚拟网络实际上就是叠加网络。

采用该SDN实现方式的技术方案主要包括由大量供应商支持的VXLAN（Virtual Extensible LAN，虚拟可扩展LAN）以及由Microsoft支持的NVGRE（Network Virtualization using Generic Routing Encapsulation，采用通用路由封装的网络虚拟化）。

3、SDN协议内容

无论采用何种方式实现SDN，都必须使用某种类型的协议来完成转发设备、应用程序以及控制器之间的通信与信息交换。从SDN控制器的角度来看，可以将这些协议分成北向协议和南向协议。如前所述，南向协议用于控制平面设备（如SDN控制器或者是应用程序）与转发平面之间的通信，而北向协议则用于应用程序与SDN控制器之间的通信。

1. 南向协议

可以将南向协议分为两类，一类是控制平面可以直接与转发平面进行通信，另一类是控制平面通过管理平面改变设备参数从而间接影响转发平面。直接与转发平面进行交互的协议称为SDN控制平面协议，使用管理平面来改变转发平面的协议则简单地称为管理平面协议。

下图给出了SDN协议分类示意图：

2. SDN控制平面协议

SDN控制平面协议在网络设备上以低层协议方式进行操作，可以对设备硬件进行编程以直接控制数据平面。常见的SDN控制平面协议主要有OpenFlow、PCEP（Path Computation Element Communication Protocol，路径计算单元通信协议）以及BGP流规范（BGP Flow-Spec）。

下面将对这些协议做一个简要分析。

1）OpenFlow

设备商提供的传统网络设备的控制平面与转发平面之间的通信过程都发生在同一台设备中，这些设备使用专有通信协议和内部进程调用。对于SDN环境来说，由于控制平面与转发平面分离，因而需要一个支持多供应商的标准协议来完成它们之间的通信过程。OpenFlow就此应运而生，OpenFlow是业界第一个用于SDN控制器与网络设备之间的通信并对转发平面进行编程的开源控制协议。

OpenFlow已从最初的实验室版本逐渐发展成熟，目前已经提供1.3及以上版本的产品级软件。

OpenFlow负责在设备上维护被称为流表（flow table）的信息，流表中包含了如何转发数据的相关信息。SDN控制器可以通过OpenFlow协议对支持OpenFlow的交换机的转发平面进行编程，实现方式是更改设备上的流表。

为了对转发信息进行编程并在网络中设置路径，OpenFlow支持两种操作模式，即被动模式和主动模式。被动模式是利用OpenFlow实现SDN的默认操作模式，假设条件是网络设备无智能或者未运行控制平面的相关功能。

在被动模式下，所有转发节点收到的数据流量中的第一个数据包都会发送给SDN控制器，由SDN控制器利用该信息对穿越整个网络的数据流进行编程，该进程会在路径上的所有后续设备中创建流表，并相应地切换数据流量。在主动模式下，SDN控制器会预先配置一些默认流值，待交换机启动之后，就会对流量流进行预编程。

SDN控制器与交换机通过网络交换信息流时，建议通过安全通道进行OpenFlow通信，如SSL（Secure Socket Layer，安全套接字层）或TLS（Transport Layer Security，传输层安全性）。

下图给出了OpenFlow的体系架构：

OpenFlow主要关注控制平面与数据平面之间的关系，但是如果设备的管理平面和操作平面仍然必须以传统方式进行管理，那么就会削弱OpenFlow给SDN带来的可编程性优势。最初的OpenFlow是为交换机开发的，较少考虑管理功能，为了获得可编程性的全部好处，就要求管理平面也应该具备应用程序可使用的接口。

因此，可以采用两种不同的协议来提升OpenFlow的管理能力和配置能力：OF-CONFIG（OpenFlow Configuration，OpenFlow配置）管理协议和OVSDB（Open vSwitch Database，开放虚拟交换机数据库）管理协议。

2）PCEP

PCEP（Path Computation Element Communication Protocol，路径计算单元通信协议）是一种工作在两台设备之间的协议，其中一台设备利用TE（Traffic Engineering，流量工程）进行转发，另一台设备则负责执行确定流量工程路径所需的所有计算。PCEP由RFC 4655定义，该RFC将运行TE协议的设备定义为PCC（Path Computation Client，路径计算客户端），将执行全部计算功能的设备定义为PCE（Path Computation Element，路径计算单元），PCE与PCC之间的协议则称为PCEP。

PCC可以是任何已经启用了与PCE协同工作能力的传统路由设备，传统意义上的路由器会执行自己的计算操作并相互交换信息，而PCEP模型中的路由器（充当PCC）则执行流量转发以及标签的添加与处理等操作，将所有的计算及路径决策进程都留给了PCE。如果有多台PCE协同工作，那么也可以将PCEP用作这些PCE之间的通信协议。如果要从网络中学习LSDB（Link State DataBase，链路状态数据库）信息，那么就可以由PCE设备与网络中的设备建立被动IGP关系，但是由于这样做会限制PCE对网络区域边界的认知，因而提出了一种被称为BGP LS（BGP Link State，BGP链路状态）的替代解决方案，BGP LS是一种新的BGP扩展协议，可以向PCE提供LSDB信息。

由于PCEP的设计基于SDN的流量工程用例，因而采用了RSVP-TE、基于GMPLS（Generalized MPLS，通用MPLS）的TE以及SR-TE（Segment Routing TE，分段路由TE）等协议，这些场景下的PCEP、PCC以及PCE的角色都相同。

例如，PCC可以请求PCE执行特定约束条件下的路径计算操作，而PCE则可以返回满足约束条件的可能路径。

3）BGP-FS

BGP-FS（BGP Flow Spec，BGP流规范）是BGP协议的一种补充协议，定义了BGP路由器向上游BGP对等路由器通告流过滤规则的方法，流过滤规则包括匹配特定流量的标准以及对这些匹配流量执行的特定操作（包括丢弃这些匹配流量）。

BGP-FS是一种标准协议，定义在RFC 5575中，得到大量厂商的支持。BGP-FS定义了一种新的BGP NLRI（Network Layer Reachability Information，网络层可达性信息），可用来创建流规范。从本质上来说，流规范就是匹配条件，如源地址、目标端口、QoS值以及数据包长度等。对于匹配流量来说，系统可以执行限速、QoS分类、丢弃以及重定向到某个VRF（Virtual Routing and Forwarding，虚拟路由和转发）实例等操作。

对于SDN场景来说，SDN控制器可以与转发设备建立BGP邻居关系，只要所有设备都支持BGP-FS，那么就可以通过BGP-FS，由控制器向这些设备发送流量过滤规则，从而控制转发行为。事实上，BGP-FS的最初目的是重定向或丢弃DDoS（Distributed Denial of Service，分布式拒绝服务）攻击流量，该场景下的控制器（检测到攻击之后）指示面向攻击流量的路由器丢弃匹配流量或者将这些流量转移到流量清理设备中。

3. SDN管理平面协议

管理平面协议负责处理设备配置操作，从而间接影响转发平面。由于管理平面协议假定采用混合SDN实现方式，因此网络设备都运行自己的控制平面协议，这些控制平面协议受到使用管理平面协议的外部应用程序的影响。

下面将对这些协议做一个简要分析。

1）NETCONF

NETCONF（Network Configuration Protocol，网络配置协议）是IETF（Internet Engineering Task Force，因特网工程任务组）标准协议（定义在RFC 6242中），很多网络厂商都已经支持该协议，以支持网络设备的编程接口。

NETCONF采用客户端-服务器模型，应用程序充当客户端，为充当服务器的设备配置参数或者从服务器上检索操作数据。通过NETCONF交换的配置数据或操作数据均采用YANG数据模型所描述的预定义格式。由Tail-f研发的Cisco NSO（Network Service Orchestrator，网络服务编排器）、ODL（Open Daylight）、Cisco OSC（Open SDN Controller，开放SDN控制器）以及Juniper的Contrail等SDN控制器都将NETCONF作为南向协议。

YANG是Yet Another Next Generation的缩写，是一种前面曾经讨论过的数据建模语言。虽然YANG的最初开发目的是与NETCONF协同工作，但实际应用并不仅限于此。

2）RESTCONF

RESTCONF是NETCONF的一种替代协议，也采用数据建模语言YANG来解析设备与应用程序之间交换的配置及操作数据。RESTCONF的操作与NETCONF相似但并非完全相同。RESTCONF源自REST（Representational State Transfer，表述性状态转移）API，CSP（Cloud Service Provider，云服务提供商）通常利用REST API对自己的计算基础设施进行编程。

RESTCONF采用与REST API相似的原理及操作与网络设备进行通信，为使用YANG模型访问配置及操作数据的NETCONF提供了一种替代解决方案。由于RESTCONF与REST API（服务提供商可能已经采用REST API管理其计算资源）具有很多相似性，因而使用RESTCONF可以为服务提供商的计算及网络基础设施提供非常方便的公共接口，如支持OPTIONS、GET、PUT、POST以及DELETE等操作。

REST是Representational State Transfer（表述性状态转移）的缩写，REST架构为客户端—服务器关系中的两个实体之间的无状态通信定义了通信机制，符合REST架构的API称为RESTful API，很多时候也将术语RESTful API简化为REST API。

常见的基于REST通信的传输协议是HTTP，REST使用一组动作（称为REST方法）来定义自己的操作，常见操作主要有POST（创建条目）、GET（检索条目或数据）、DELETE（从服务器中删除条目或数据）以及PUT（替换现有数据或条目）和PATCH（修改服务器上的现有数据）。

对这些动作及其相关信息进行编码时，REST首选JSON（JavaScript Object Notation，JavaScript对象标记），不过也可以选择XML或其他方法，只要服务器能够解码这些信息并理解操作请求即可。

3）OpenConfig

OpenConfig是一种支持网络设备实现厂商中立性的编程接口的技术框架，由Google、AT&T、BT等成立的网络运营商论坛发起，希望推动业界创建一个实用化的用例模型，以可编程方式来配置和监控网络设备。

OpenConfig采用YANG模型作为其传输数据的标准，虽然没有为操作指定任何底层协议，但某些厂商已采用NETCONF来支持OpenConfig框架。此外，OpenConfig还通过支持来自设备的数据流遥测（Streaming Telemetry）数据来支持网络监控能力。

与传统的网络监控方法（如SNMP、Syslog以及CLI）相比，数据流遥测是一种从网络设备收集数据的新方法。传统方法主要基于轮询或事件收集数据，而数据流遥测则基于推送模型使用网络设备的信息流，将必要的操作状态及数据信息发送给中心服务器，也可以采用编程方式，让其定期发送数据或基于特定事件发送数据。

4）XMPP

某些SDN控制器厂商（如Juniper Contrail以及Nuage Network）已经开始使用XMPP（eXtensible Messaging and Presence Protocol，可扩展消息及表示协议）作为集中式控制器与网络设备之间的通信协议，XMPP是一种开源、免费且可扩展的通信协议，可以提供基于XML的实时数据交换能力。

XMPP的开发目的是作为厂商开发的即时通信系统的替代解决方案，XMPP的主要功能特性如下。

开放和自由。
基于IETF标准的协议。
安全，支持TLS（Transport Layer Security，传输层安全）和SASL（Simple Authentication and Security Layer，简单身份验证和安全层）。
去中心化（所有组织机构都能实现自己的XMPP系统，并根据特定需求进行增强）。
灵活且可扩展，可以利用XML创建自定义功能。

5）I2RS

I2RS（Interface to the Routing System，路由系统接口）是IETF支持混合SDN实现方式的一个工作组，其目的是提供一种以编程方式在网络设备上访问、查询和配置路由基础设施的方法。I2RS的立场是不需要将控制平面完全移出网络设备，与最初的SDN建议一样。I2RS建议通过某种方式来影响分布式路由决策，对设备进行监控并将策略推送给设备，从而解决设备缺乏可编程性、自动化能力不足以及供应商绑定等问题。

I2RS定义了代理和客户端。I2RS代理运行在网络设备上，与LDP、BGP（Border Gateway Protocol，边界网关协议）、OSPF（Open Shortest Path First，开放最短路径优先）、IS-IS（Intermediate System to Intermediate System，中间系统到中间系统）、RIB管理器以及设备的操作平面和配置平面等路由组件进行交互。

I2RS代理可以为运行在独立设备上的I2RS客户端提供读写访问能力，允许I2RS客户端通过查询I2RS代理来控制路由参数或检索路由信息。此外，I2RS客户端还可以订阅来自代理的事件通知，因而已订阅的任何路由组件的变化情况都能以推送模型方式从代理传递给客户端。

I2RS架构定义的代理要求支持和处理来自多个外部客户端的请求，I2RS客户端既可以是应用程序中的嵌入式代码，也可以位于路由设备与应用程序之间，如下图所示。

4. 北向协议

北向协议是SDN控制器与上层应用程序之间的接口，如下图所示。

应用程序通常执行服务编排功能或者根据应用程序定义的逻辑或策略来制定并实现决策。SDN控制器与应用程序之间的通信与两个软件实体之间的通信没有任何区别，因而不需要任何特殊的新协议。现在使用的很多协议都能实现北向通信，如RESTful API或Python、Ruby、Go、Java、C ++等编程语言中的库。

5. 再论NETCONF、RESTCONF以及YANG

如前所述，NETCONF和RESTCONF都使用数据建模语言YANG进行信息交换。如果不分析它们使用的编码技术以及传输机制，那么有关这些协议的讨论就不够完整。下面将首先分析一下这些协议之间的关系。

从下图可以看出，数据（包括操作数据、配置数据以及用户数据）加上编程逻辑以及分析模块就构成了应用程序的recipe（注：recipe文件包含了给定软件的相关信息），如果应用程序希望配置网络设备，那么就可以利用YANG之类的数据建模语言来构造配置信息。

构造了配置信息之后，就可以由配置协议（如NETCONF）利用该数据定义所要执行的操作类型。例如，下发配置数据之后，NETCONF可以执行edit-config操作）。接下来还要对协议的操作及数据模式信息进行编码，最后再利用传输协议（如SSH[Secure Shell，安全外壳]、HTTPS以及TLS等来传递信息。

网络设备需要具备使用相同传输方法进行通信的能力。与此相似，网络设备需要对这些协议信息数据进行解码，然后传递给协议代码以确定必须执行的操作类型。要求网络设备能够理解所用的数据建模语言，并在预定义结构中识别配置数据和操作数据。由于应用程序和设备使用的数据模型都相同，因而能够轻松解析与该被交换数据相关的参数及字段。

数据模型、协议以及编码器之间的差别对于初次接触可能具有一定的挑战性。

例如，虽然可以用JSON格式来表示YANG数据建模，但是不应该与协议编码相混淆。为了更好地理解这些概念，可以用人们的日常交流进行类比。

传输介质：空气。
编码：音素和声音。
传输介质：空气。
编码：音素和声音。
协议：使用的语言（如英语）。
数据模型：语法结构（如果没有形成正确的句子，那么语言中的单词将没有意义）。
应用：舌头和耳朵，即人类的语言与听觉器官。
数据逻辑分析：人的大脑。

在此基础上，我们可以进一步分析NETCONF和RESTCONF。它们都是非常流行且应用广泛的配置协议，可以利用跨平台、跨厂商的标准应用程序来配置网络设备。

NETCONF和RESTCONF都使用YANG作为数据建模语言，而且都通过RFC进行标准化。NETCONF倾向于使用XML作为编码技术，而RESTCONF则常常使用基于JSON和基于XML的编码技术。

在传输层面，NETCONF标准建议采用安全的、经认证的、能提供数据完整性和安全性的传输协议，虽然具有一定的灵活性，但SSH仍被列为强制选项之一。RESTCONF的常用传输协议是HTTP，不过很多时候也使用HTTPS等传输协议。

下图列出了这些模块之间的关系以及RESTCONF和NETCONF的常用选项。

6. 关于YANG模型的更多信息

在理想情况下，所有功能特性及操作数据的YANG模型都可以实现完全标准化。事实上，经过IETF的持续努力，已经为不同的功能特性和可配置参数提供了通用的标准YANG模型，虽然这些IETF YANG模型可以实现跨厂商的无缝工作，但缺点是无法支持厂商针对配置参数或操作数据的各种增强型功能。

从下图可以看出，很多厂商都开发（或基于标准模型进行修改）了单独的YANG模型，这些模型通常称为原生YANG模型，更适合厂商自己的实现方案，这些YANG模型会被发布到公共存储库中，供应用程序开发人员导入和使用。虽然这种方法与标准方法背道而驰，但却非常现实，而且保留了灵活性和开放性。

第三类YANG模型则是由服务提供商推动的YANG模型，在OpenConfig工作组的领导下，服务提供商们认为IETF的标准化时间难以满足他们的需求，有时受厂商的影响太大，因而服务提供商们也开始着手开发和发布自己的YANG模型以填补空白。

前面提到的YANG模型都是网元级模型，可以表示功能特性的配置信息或操作数据的结构（如接口的比特率或协议的路由规模），这些YANG模型都工作在网元级别。

值得一提的是，YANG模型还能定义完整的网络服务，这类服务级YANG模型可以描述整个服务（如L3VPN服务或VPLS服务）的结构及参数，编排器可以利用该模型来实现整个服务。虽然IETF草案定义了很多这类YANG模型，但是在很多情况下，厂商或提供商们都在开发自己的模型以满足特定的服务部署需求。

下图给出了这两类YANG模型之间的关系：

四、SDN控制器详解

前面已经介绍了SDN控制器的主要作用以及使用的各种协议，接下来将讨论目前可用的常见SDN控制器，包括开源SDN控制器和网络设备供应商提供的商用SDN控制器。

所有的SDN控制器都应该具备如下功能：

提供与各类网络设备进行通信的能力，可以通过支持多种SDN南向协议来实现。
提供开放和/或良好记录的北向API，以开发能够与SDN控制器交互的应用程序。
保持网络的全局视图。
提供网络事件监控能力，并提供定义响应操作以响应这些事件的功能。
为网络提供执行路径计算及决策的能力。
提供高可用性能力。
提供模块化和灵活性机制，可以对网络进行编程和定制，以满足不断变化的需求或新出现的协议。必须确保SDN控制器的可扩展性，能够随着需求的增长而增长。

接下来将详细讨论目前可用的一些常见SDN控制器。

1、开源SDN控制器

目前供应商和开源社区提供了很多可用的开源SDN控制器，与其他开源软件类似，这些控制器没有任何许可成本，所有人都能拿到代码并按原样使用或根据需要对其进行修改。当然，这些优势都有赖于开源社区的支持能力和开发能力。

下面将讨论一些常见的开源SDN控制器：

1. ODL（OpenDaylight）

OpenDaylight基金会是一家主要由网络供应商成立的论坛，目的是提供开放的SDN平台并支持多厂商网络环境。该基金会负责开发并维护OpenDaylight SDN控制器，目前该控制器已成为网络界开源SDN平台的事实标准。

ODL采用微服务架构，具有模块化和灵活性特点，仅需安装必要的协议及服务。ODL支持多种常见的南向协议（如OpenFlow、PCEP、BGP、NETCONF、SNMP以及LISP[Location/ID Separation Protocol，位置/ID分离协议]）和北向API（如RESTCONF），对多种南向协议的支持能力使得ODL非常适合半开放式部署环境，因为这些部署方案可能需要使用特定协议。ODL是一种纯软件产品，作为Java虚拟机运行在Java之上。

下图给出了ODL架构图：

由于ODL是开源软件，因而很多供应商（如HP、Cisco、Oracle等）都在为ODL代码贡献自己的软件，主要是为了支持ODL与自己的设备进行交互。还有一些供应商在开源ODL的基础上开发出自己的ODL产品，支持更多的附加功能，并作为商用产品提供技术支持。

ODL的版本名称以元素周期表命名，第一个版本Hydrogen于2014年年初首次亮相，后续的版本分别是Helium、Lithium和Beryllium.。目前为止，ODL已经提供了名为Boron的第五个可用版本。

2. Ryu

Ryu是一款由开源社区支持的开源SDN控制器，完全采用Python编写，基于组件化方式，拥有良好文档化的API，可以轻松地开发任何应用程序与其进行交互。Ryu通过南向库，可以支持OpenFlow、OF-CONFIG、NETCONF以及BGP等主要南向API。

Ryu支持多厂商网络设备，已经在NTT（Nippon Telegraph and Telephone，日本电报电话公司）的数据中心得到应用部署。

下图给出了基于Ryu SDN控制器的部署架构：

3. ONOS

ONOS（Open Network Operating System，开放网络操作系统）是一款分布式SDN操作系统，可以提供丰富的高可用性和运营级的SDN。ONOS于2014年作为开源软件方式出现，旨在为服务提供商提供一种构建软件定义网络的开源平台。目前ONOS已得到大量服务提供商、供应商以及其他合作伙伴的广泛支持，还有大量新成员不断加入ONOS社区。

下图给出了ONOS架构示意图，图中强调了ONOS的分布式核心，这也是ONOS拥有高可用性和弹性能力以满足运营级标准的根本原因。

该分布式核心层位于北向核心API与南向核心API之间，这两个核心API的目的都是从各自方向为分布式核心提供协议无关性API。分布式核心则负责整个集群的协同，处理从北向和南向核心发起的状态管理及数据管理操作，确保全网各种控制器的协同工作，同时还能保持基于全网视图的公共视图，而不仅仅是基于可见性的隔离视图，所有与ONOS交互的应用程序都可以拥有该网络的公共视图，这也是ONOS分布式架构的核心优势。

ONOS在南向核心API上采用可插拔适配器，支持多种流行的SDN南向协议，因而极具灵活性。北向API则允许应用程序与ONOS交互并使用ONOS，而无须了解分布式ONOS的部署情况。

ONOS的版本名称以鸟类进行命名，而且ONOS的徽标也是飞鸟图形。

目前为止，ONOS的最新版本名为Hummingbird。常见的ONOS应用之一就是将ONOS包含在名为CORD（Central Office Re-architected as a Datacenter，端局重构为数据中心）的项目中，CORD的目的是加快推动供应商采用SDN和NFV技术。

4. OpenContrail

OpenContrail是Juniper开发的一款开源SDN平台，旨在通过叠加模型实现SDN。OpenContrail采用网络虚拟化技术，将叠加网络的转发功能（如MPLS或VXLAN）与数据转发功能解耦，控制功能则由SDN控制器负责。

目前OpenContrail遵从Apache 2.0，支持虚拟路由器以及常用北向API等附加功能。

2、商用SDN控制器

很多SDN控制器都拥有商用版本，这些商用SDN控制器不仅来自网络设备供应商，还来自很多业内新进入者，他们希望通过提供更好、更有利可图的SDN控制器来获得网络市场的份额。如前所述，很多供应商都以ODL为基础，通过提供增强型功能、演进路线以及技术支持等措施来实现自己的SDN控制器。当然，也有一部分供应商从头开发自己的SDN控制器。

常见商用SDN控制器如下：

1. VMware NSX

VMware NSX是由供应商开发的第一款SDN控制器，最初由一家名为Nicira的创业公司开发完成，后来被VMware收购。NSX平台利用叠加网络方式实现SDN，可以创建基于VXLAN的叠加网络，也支持路由、防火墙、交换以及其他网络功能。NSX SDN平台可以与任意硬件及Hypervisor配合使用，为最终用户提供所有的网络逻辑功能，如逻辑负载平衡器及逻辑路由器，同时还能提供灵活的可编程网络。

2. Cisco SDN控制器

Cisco开发了多款SDN控制器以满足不同细分市场的需求。最初Cisco开发了一款开放的Cisco XNC（eXtensible Network Controller，可扩展网络控制器），该控制器可以通过Cisco的onePK协议支持南向通信，后来又陆续加入了其他供应商并成为ODL的创始成员之一。Cisco支持名为Cisco OSC（Open SDN Controller，开放SDN控制器）的商用版ODL，OSC建立在ODL之上，支持标准的南向和北向API以及相关协议。

Cisco为数据中心和企业提供的SDN控制器解决方案称为APIC（Application Policy Infrastructure Controller，应用策略基础设施控制器），企业版的APIC是APIC-EM（APIC Enterprise Module，APIC企业模块）。

数据中心版本的APIC则被称为APIC-DC（APIC Data Center，APIC数据中心），是Cisco ACI生态系统的一部分，该生态系统使用Cisco专有解决方案。Cisco APIC-DC是ACI解决方案的核心组件，支持网络的可编程性、管理与部署、策略实施以及网络监控等功能。APIC-DC提供GUI和CLI接口以实现北向交互，在南向通信方面则支持专有协议iVXLAN（通过VXLAN覆盖网络实现SDN）以及标准的OpenFlex协议（由Cisco开发并成为开源协议）。

此外，Cisco还提供开放的标准化的SDN控制器，称为Cisco VTS（Virtual Topology System，虚拟拓扑结构系统），用于叠加网络的管理与配置，VTS通过MP-BGP EVPN（Multi-Protocol BGP Ethernet Virtual Private Network，多协议BGP以太网虚拟专用网）提供SDN叠加功能。Cisco VTS支持基于REST的北向API，从而与其他OSS/BSS实现集成，同时还支持丰富的南向协议，如RESTCONF/YANG、Nexus NX-OS API等。

在基于VxLAN的网络部署方案中，二层地址承载在三层传输系统之上。可以通过两种方式学到终端主机的二层MAC地址：采用数据路径的泛洪和学习机制或采用控制协议交换MAC地址。MP BGP EVPN使用的是控制协议方式，由MP BGP提供在不同VxLAN端点之间交换MAC地址的功能。

3. Juniper Contrail

Juniper提供的开源OpenContrail SDN平台的商用支持版本是Juniper Contrail，如下图所示。

与OpenContrail一样，商用版本通过支持叠加模型来实现SDN，与现有的物理网络协同工作，并在其上部署网络虚拟化层。Contrail支持使用XMPP以及NETCONF、BGP与Juniper的虚拟路由器（vRouter）进行南向通信。

Juniper于2016年退出ODL项目，目前支持Juniper Contrail和OpenContrail作为其SDN控制器。

4. Big Network控制器

Big Switch Networks是早期进入SDN控制器市场的少数几家公司之一，为SDN开源社区贡献了3个重要项目。

Floodlight：开源SDN控制器。
Indigo：在物理和虚拟环境中支持OpenFlow。
OFTest：在交换机上测试OpenFlow一致性的框架。

在商业方面，Big Switch的SDN控制器已经从最初的Floodlight项目发展成为市场化的Big Network控制器，该控制器支持标准的南向协议（如OpenFlow），采用经典的SDN实现方式，能够与物理设备及虚拟设备协同工作。

5. Nokia Nuage VSP

Nokia通过Nuage VSP（Virtual Service Platform，虚拟服务平台）来提供SDN控制器解决方案，该产品最初由Nuage Networks公司开发完成，后来被Alcatel-Lucent收购，目前成为Nokia的一部分。

VSP主要包括3个组件，VSC（Virtual Services Controller，虚拟服务控制器）是主要的SDN控制器，用于对数据转发平面进行编程，支持OpenFlow通信协议。VSC通过XMPP与北向的VSD（Virtual Service Directory，虚拟服务目录）进行通信，VSD是策略引擎。与Open vSwitch类似，Nuage也有VRS（Virtual Routing and Switching，虚拟路由和交换）平台，与提供网络功能的Hypervisor集成在一起。

6. SD-WAN控制器

如前所述，SDN正逐渐渗透到网络的各个层面，其中的一个重要应用领域就是SD-WAN，目前已经有多个供应商明确提供了可用的SD-WAN控制器。控制器的架构都相似，因而这里笼统地描述这些控制器。

目前企业WAN市场刚刚开始采用SDN技术，除了传统供应商之外，还有很多新进入者也试图占领这块市场，市面上由大公司提供的SD-WAN控制器包括Cisco的APIC-EM、Riverbed的SteelConnect以及Viptela的vSmart Controller。

这些产品的主要功能如下：

Cisco APIC-EM，该功能特性丰富的SD-WAN解决方案是Cisco IWAN（Intelligent WAN，智能WAN）解决方案的一部分。
适用于任何WAN链路技术。
利用DMVPN进行站点间通信。
Riverbed SteelConnect。
利用应用程序数据库目录在不同的WAN链路上引导流量，为使用云应用程序产品（如MS Office365、Salesforce以及Box）的客户带来增值服务。
利用Riverbed的SteelHead CX平台提供SaaS服务，可以动态创建更靠近分支机构或最终用户的虚拟机，从而提供低时延、低抖动以及高速接入等优势。
Viptela vSmart Controller。
该SD-WAN解决方案是Viptela SEN（Secure Extensible Network，安全可扩展网络）平台的一部分，SEN平台还包括用于管理网络的vManage应用程序以及vEdge路由器。
简化部署和管理操作，实现接入设备的即插即用。
控制平面与数据平面通过专有协议进行通信。
控制器和配置管理软件免费，客户只需支付边缘硬件系统。
使用L3VPN进行站点间通信。

五、SDN应用案例

SDN最初被认为是专用于解决数据中心可扩展性和流量控制难题的解决方案，后来这项新技术又逐渐进入很多网络领域，并在这些领域取得了一定的应用。

考虑到SDN在不同网络领域使用的协议和技术因具体的解决方案不同而有所不同，因而这里将从5个不同的网络领域来分析SDN在这些领域中的作用，如下图所示。

1、数据中心中的SDN（SDN DC）

虽然数据中心从大型机时代就一直存在，但是在过去的十多年中，数据中心的规模和容量都出现了指数级增长。互联网和云的出现以及服务提供商维护在线业务以满足消费者需求的趋势极大地推动了数据中心的迅猛增长，导致大规模数据中心安装了成千上万台服务器，它们被部署在数十英亩的土地上，消耗了数以兆瓦计的电力资源。

1. 问题与挑战

数据中心的发展是服务器虚拟化的主要推动力，虽然虚拟化提高了机房空间利用率、能耗水平及成本效率，但同时也给互连这些虚拟服务器的网络架构带来新的严峻挑战。

其中的一个挑战就是VLAN（Virtual LAN，虚拟LAN）的可扩展性被限定为4096，虚拟服务器通常都位于同一个二层域中，需要利用VLAN来隔离这些虚拟服务器以支持多租户应用，而且企业对云托管服务的大量应用也催生了跨多个数据中心延伸企业VLAN域的需求，这些都给可用VLAN空间带来了巨大压力。

为了解决这个问题，人们引入了VXLAN（Virtual Extensible LAN，虚拟可扩展LAN）协议。VXLAN可以通过三层网络为虚拟服务器提供二层邻接性，VXLAN利用VXLAN ID建立的叠加式网络，最多可扩展到1600万个网段，从而解决了前面所说的可扩展性问题。不过，VXLAN也带来了新的挑战，即叠加网络的管理、监控及编程。

下图所示为基于VXLAN的叠加网络：

2. SDN解决方案

VXLAN叠加网络的端点（即VTEP[VXLAN Tunnel End Point，VXLAN隧道端点]）通常位于ToR（Top of Rack，架顶）交换机或主机的虚拟交换机上，这两种情况下的VTEP都需要编程并与租户的虚拟机相关联。

大规模数据中心的虚拟机都采用编排工具进行部署，如OpenStack，可以采用自动化方式部署VM，因而可以将虚拟机部署在任意物理服务器上。不过为了通过VXLAN连接网络，还需要提供相应的机制来查看整个网络，此时就要用到SDN，因为SDN拥有完整的网络视图，而且还能与虚拟开发工具相协调，对转发平面（位于ToR或虚拟交换机上）的VTEP和VXLAN信息进行编程。

从下图可以看出，SDN控制与交换机进行通信，并根据交换机所服务的服务器上配置的虚拟机创建VTEP接口。

由于虚拟机可能会在物理服务器之间移动或拆除，因而有可能需要重新编程或删除VTEP信息，此时也由SDN控制器负责处理。

2、服务提供商网络中的SDN（SP SDN）

可以从高层视角将SP（Service Provider，服务提供商）网络中的路由设备分为PE（Provider Edge，提供商边缘）和P（Provider，提供商）路由器。PE路由器直接连接客户网络，因而PE路由器拥有大量接口，并执行分类、QoS、访问控制、故障检测以及路由等各种操作，这些路由器通常都会携带大量客户路由信息和ARP缓存，构成服务提供商网络的边界。PE路由器通常都通过大带宽上游链路将流量汇聚到P路由器。

P路由器的功能特性并不复杂，而且数量相对较少，但P路由器之间需要通过地理位置分散的POP点提供的大带宽链路进行互联。对于大多数SP网络来说，通常提供的语音、视频、数据和Internet等服务都要用到公共的核心链路和核心路由器，这些核心链路承载了服务提供商们所服务的大量客户的聚合流量，大带宽链路的任何中断都会给大量用户带来严重影响，因而为了避免故障并提供运营级的可用性，通常都要为这些核心链路以及通过这些链路互联的核心路由器部署物理冗余机制。

1. 问题与挑战

由于SP流量面对着大量的冗余链路、节点及路径，因而节点间的最短可用路径通常可能并不是每比特成本最优的路径，或者可能无法一次性承载所有流量。因此，SP的常见做法是利用流量工程技术，根据重要程度、成本、时延以及网络状态等因素将流量引导到特定路径，从而优化网络成本并实现更优的性能。

下图所示为SP网络的通用视图，并举例说明了通过流量工程隧道将流量从最佳路径引导到用户首选路径的实现方式。

如上所述，最佳路由路径可能并不是优选的流量路径（考虑到成本、时延、带宽可用性等因素），而且还会通过特定的流量工程技术改变路由协议的行为以满足特定需要。MPLS-TE（MPLS Traffic Engineering，MPLS流量工程）是实现此类目标的常用技术，SR-TE（Segment Routing Traffic Engineering，分段路由流量工程）也得到了广泛应用。

对这两种协议来说，并不是所有的节点都拥有网络链路带宽、链路偏好、共享故障组（如共享相同传输设备的链路）、流量工程路径的切换信息等端到端视图，需要利用特殊协议或协议扩展在节点之间进行协调以交换这些信息，并确定完整的流量工程路径。

每个节点都要进行路径计算并做出决策，因而必须在所有节点上保留所需数据。由于这些操作都要消耗大量CPU资源并占用大量内存，而且这种分布式实现机制还要进行端到端的协调操作，因而这些开销会占用大量设备资源。

SP网络的另一个挑战是发生潜在故障时对网络及服务造成的影响范围。虽然可以部署FRR（Fast Re-Route，快速重路由）等机制，但是当加上网络容量规划以及QoS保证需求时，整个网络设计工作就会变得非常复杂且难以优化。

2. SDN解决方案

由于集中式控制器拥有全网链路状态视图，而且还可以跟踪带宽分配情况并允许控制器处理决策过程，因而使用集中式控制器能够有效解决跨网络的流量工程管理与设计挑战。

SDN非常适合该场景。对于基于SDN的解决方案来说，路由器不需要做出决策或者保留决策所需的数据库，从而大大减少了路由器的内存和CPU资源开销。集中化的SDN控制器完全可以超越基于流量和链路利用率的基本决策标准，与高层应用程序进行交互，实现基于策略的流量重路由，如在维护窗口到来之前预先进行流量重路由，根据一天中的特定时间或特定事件更改流量方向，或者针对特定流量流动态更改带宽分配方案以满足临时需求。

集中式控制器对于管理特性丰富的PE路由器来说也非常有用。在PE路由器上配置新客户时，可以根据SLA（Service Level Agreement，服务等级协议）需求为这些客户配置一致的QoS、安全性、扩展性以及连接性体验，如果客户需求出现了变化（如客户对特定数据流拥有更高偏好），那么就可以通过集中式SDN控制器轻松一致地将配置变更数据推送到SP网络的所有边缘路由器，如下图所示。

SDN解决方案的另一大优势就是提高SP网络的安全性和高可用性。如果服务提供商网络正在遭受大流量的DDoS（Distributed Denial-of-Service，分布式拒绝服务）攻击（攻击SP网络或者托管在SP网络上的客户），那么就可以利用集中式SDN控制器将攻击流量偏离标准的路由路径，并重定向到集中式或分布式流量清洗设备上，从而有效保护SP的基础设施。

3、广域网中的SDN（SD WAN）

企业及其商业客户的网络分布在不同的地理位置，众多分支机构都要连接到总部的网络。这些站点都通过专用WAN（Wide-Area Network，广域网）电路（如T1或T3）或VPN（Virtual Private Network，虚拟专用网）服务提供商提供的专线连接不同的办公室，这些链路或服务的价格都非常昂贵，大大增加了企业网的运营费用。为了降低成本开销，很多企业都利用DMVPN（Dynamic Multipoint VPN，动态多点VPN）或MPLS VPN等新技术将这些网络连接转向安全的互联网链路。增加了数据加密保护机制之后，动态建立的叠加网络就可以使用共享的Internet链路为企业的私有流量提供服务。

不过，Internet连接可能无法保证SLA，而且即便采用了加密技术，也可能并不适合传送高度敏感的企业数据，因而这种方法虽然降低了专用链路的带宽要求，但并未完全消除对专用WAN链路的需求。可以根据SLA需求或数据敏感性要求，将流量引导到Internet链路或专用WAN链路。

除了主用的专线链路之外，使用这种共享的Internet提供商链路，客户能够以经济有效的方式连接不同的分支机构和总部，如下图所示。

1. 问题与挑战

对于具有成百上千个站点的大规模WAN部署方案来说，要在使用分离的专线链路和互连链路的同时维护好各分支机构之间的互连性，是一项非常复杂的任务。此外，还需要在每个站点位置上管理可以引导到Internet链路上的流量类型的流量策略，仅此一项就构成了极大的管理开销。

根据实时度量结果优化这些策略或者经常性地动态调整这些策略都不是一件简单的事情。虽然成本与性能之间的关系非常清晰，但是如果没有可以集中管理流量流并配置WAN路由器的管理系统，那么追求这样的效果就显得力有不逮了。

2. SDN解决方案

使用集中式网络拓扑结构的SDN模型，可以将拥有多条链路的WAN抽象为一个集中式管理系统（称为控制器），控制器可以监控Internet链路上的SLA，并指示分支机构或总部使用正确的链路传送数据，而且还可以根据流量的类型及敏感性管理流量流，让不同的流量分别使用专线电路和Internet链路。

另外一个好处就是可以提高远端路由器的链路利用率，对离开源端路由器的流量流做出有效的路径决策。因此，SDN解决方案能够有效节省运营费用，这一点是传统解决方案极难实现的。我们将该解决方案称为WAN的SDN解决方案，简称为SD WAN，常见的商用SD WAN产品主要有Viptela的vSmart、Cisco的IWAN或Riverbed的Steel-Connect。

下图给出了SD WAN解决方案示意图：

可以看出集中式SDN WAN控制器负责管理WAN路由器，监控上行链路的性能并基于链路性能、流量特性以及时间等因素，集中管理流量策略以改变流量路径。

4、企业SDN

企业网通常由跨本地LAN和WAN连接的网络设备组成，根据企业规模的不同，LAN可以通过无线和有线方式连接计算机、打印机、语音/视频终端以及其他网络设备。

如果要连接远程分支机构或数据中心，可以为WAN连接配置专用的WAN链路或Internet链路。企业网通常都会部署多种服务，如用于内部及外部通信的语音网络、连接本地用户的数据网络以及在私有数据中心或公共云中的数据存储等。此外，大型企业网还经常会根据工程、财务、市场、销售以及合作伙伴等部门差异对企业网进行隔离。

下图展示了典型企业网的网络部署：

1. 问题与挑战

对于实际网络环境来说，可能需要从LAN访问企业网，也可能需要从WAN访问企业网，此时就要为企业网部署不同的控制策略，因而安全性和灵活性对于部署和管理这类企业网架构来说至关重要。此外，企业部署了基于私有云的网络架构之后，原有的网络访问控制机制、防火墙策略以及安全措施都要作出有针对性地调整与完善，从而充分享受私有云部署方案的好处。

随着大量新型业务敏捷性模型的不断涌现（如BYOD[Bring Your Own Device，自带设备办公]）和计算设备的大量普及（如笔记本电脑、移动设备以及平板电脑等），以及从任意设备访问企业网的能力不断增强，企业IT部门必须在不损害网络的情况下支持所有需求。

从本质上来说，网络访问的安全策略属于动态策略，极其复杂。例如，用户访问设备（如运行多种操作系统的笔记本电脑）需要部署不同的安全进程，网络传输层需要采用VPN和安全加密机制，而数据中心服务器则需要部署数据隐私保护机制。需要在所有用户接入点都部署用户策略，同时还要在全网部署QoS策略。

由于企业网部署了无线及移动设备的网络传输机制，网络接入灵活多变，因而必须在用户所连接的网络边缘的接入端口上部署所有这些策略。

2. SDN解决方案

利用SDN的集中式网络视图及其从单一源点对整个网络进行编程的能力，可以解决企业网所面临的种种挑战。

BYOD允许员工将自己的个人设备（如笔记本电脑或智能手机）带到办公室，并享有与企业提供的设备相同的权限访问企业网。有时人们也将BYOD称为IT消费化（IT consumerization）。

对于BYOD来说，这些设备接入网络之后，SDN控制器就能检测到，进而根据用户或设备类型下发适当的配置文件，从而在设备上强制执行相应的访问策略，同时还可以通过适当的策略机制对网络边缘及传输层进行编程。

通过这种从集中式源点创建动态策略的方法，企业客户可以让自己的用户/员工或合作伙伴从任意位置访问企业网，而不需要局限于特定的物理办公室/桌面。如果没有SDN模型，那么IT人员就得针对每台设备或每个用户在网络上动态配置QoS/安全策略，这将是一项极其烦琐的工作。如果企业拥有数千名员工且分布在多个地点，那么采用这种传统动态配置方式几乎是一件不可能完成的工作。

此外，SDN在保护企业网免受DDoS或其他安全攻击方面也能起到非常重要的作用，只要从任意源端检测或学习到攻击签名，SDN控制器就能在全网范围内防范攻击，从而为企业数据提供安全保护。

常见案例就是利用BGP-FS来处理DDoS攻击流量，只要SDN控制器识别出了攻击流量，运行在SDN控制器之上的BGP服务器就能发现攻击流量，此后BGP服务器就能利用BGP-FS要求对等的边缘设备丢弃或引导（用于清除）所有与攻击流量特性相匹配的流量。如果没有这种方法，那么就只能通过注入静态路由（只能根据流量目的端进行匹配）的方式来实现RTBH（Remote Triggered Black Hole，远程触发黑洞），以调整每台边缘设备的路由，将攻击流量引导到清洗中心。

目前越来越多的企业网正逐步采用这种新型SDN网络架构，SDN技术给企业带来了自助IT等服务优势，而且也降低了运营成本，安全性和合规性也得到了显著增强。

5、传输SDN

传输网可以为网络POP（Point Of Presence，接入点）提供一层连接性基础设施，CSP通常利用传输网来互连数据中心，网络服务提供商则利用传输网在核心路由器之间构建网络。

传输网可能归属同一个提供商或独立的传输网提供商，通常包括光纤链路、光交换机、光复用器（MUX）和解复用器（DEMUX）以及光再生器（REGEN）等组件，而且拥有大量逻辑电路，这些共享物理介质的逻辑电路通过不同的波长（通常称为Lambda）进行分离，而且可以在逻辑网络的入口或出口处将这些波长/Lambda分离或插入到传输网中。

下图给出了一个简化的传输网示意图：

目前的传输网已经将MUX和DEMUX功能整合为可以通过重新配置以确定上下波长的单台设备，称为ROADM（Reconfigurable Optical Add-Drop Multiplexer，可重构光分插复用器）。

ROADM在传输网中的功能与IP网络中的交换机（二层交换机，甚至是标签交换路由器）功能非常相似。由于光链路每次承载多个波长并利用波长来确定相应的切换操作，因而也将由ROADM、REGEN和光链路等组成的网络称为基于WDM（Wave Division Multiplexing，波分复用）的交换光网络或WSON。

1. 问题与挑战

正如交换机维护MAC表或MPLS路由器维护LFIB（Label Forwarding Information Base，标签转发信息库）表一样，ROADM也要维护相应的表格以确定如何从复合光信号中交换、分插波长。

历史上的波长交换决策进程都是由设备在本地进行手动管理的，导致配置新电路花费的时间较长，为了让该进程自动化并且能够让设备交换控制平面信息，人们又陆续开发了一些独立协议，其中值得一提的是IETF的GMPLS（Generalized MPLS，通用MPLS）和ITU（International Telecommunication Union，国际电信联盟）的ASON（Automatically Switched Optical Network，自动交换光网络），两者的目标相似，但实现方法不同。

GMPLS基于MPLS-TE及其他相关协议，目的是希望将MPLS协议通用化，与光网络协同工作，而ASON则是为光网络开发的一种全新的自动化控制平面架构。由于不同的供应商对这两种方法的支持程度不同，而且不同的供应商之间还存在很多互操作性问题，因而在采用供应商异构部署方案时，进行端到端的信息交换以及跨传输网的波长分配与管理还存在很多挑战。同样，即便是供应商同构部署，也存在一定的信息交换限制，并没有做到集中交换，与SP核心网络面临相似的效率低下问题。

注意：波长选择是光传输网中非常重要的一个处理步骤，必须根据需求选择能够到达目的端的可用波长，可以先从起始节点选择一个波长，然后在中间节点通过光电转换和电光转换操作转换成另一个波长。不过，由于电子器件的转换和处理操作速率受限，因而该实现方式会增加网络的复杂性和成本，而且也给传输速率带来严重影响。因此，网络应尽可能地保持端到端的光操作，从而能够使用功率更高的发射器和质量更好的光纤以避免再生。

除了波长可用性之外，影响波长选择的其他因素还有信号衰减或损伤以及信号差错率等因素，这些参数都要进行逐跳测量，与网络中的其他设备交换这些信息有助于做出合理的交换决策。除非能够掌握传输网的所有这些信息，否则设备（ROADM或交换机）都无法做出电路交换的最佳、快速和自动化决策。

2. SDN解决方案

SDN提供的集中化控制平面解决方案，可以利用提取到的网络信息来解决前面提到的各种挑战。实现传输SDN功能的控制器可以从光设备提取波长及信号信息，从而拥有可用波长的完整视图以及每一跳收到的信号的质量，从而可以在源端与目的端之间计算出最佳的光信号交换路径，并对沿途的ROADM、交换机及中继设备（信号再生器）进行编程。

在传输网中使用SDN，不但能大大缩短配置时间（从几周缩短到几分钟时间），而且还能为快速业务恢复、检测并修复业务劣化以及实现最佳利用率提供实现的可能性。

由于每个供应商都可能通过不同的接口来接收信息或发送指令，因而有必要开发一套通用的YANG模型来实现该目的并提供相应的通用接口。在这方面的努力还有OpenFlow，很多供应商都在自己的实现中支持OpenFlow。在标准制定方面，OIF（Optical Interworking Forum，光互连论坛）已经发布了传输SDN的通用API框架，并提出了后续演进计划。

在这方面开展标准化工作的还有PCEP协议扩展，目前PCEP协议扩展已被提议用于确保PCEP与GMPLS网络之间的互操作性，并作为执行路径选择决策时考虑WSON网络健康性的协议机制。

六、SDN实现虚拟化网络功能NFV

SDN与NFV是两种完全独立的创新技术，只不过SDN的很多目标都与NFV一致，因而两者能够相互促进并协同应用。

对于供应商提供的传统网络设备来说，控制平面、数据平面和硬件平面都紧密集成在一起，如下图所示。

无法独立扩展这些平面，因而该体系架构无法灵活部署新型服务，也难以灵活更改其功能。从图中可以看出，SDN和NFV在两个不同的维度发挥作用。SDN的重点是实现控制平面与转发平面的分离，并通过独立的控制平面来管理、控制和监控转发平面。

NFV的重点则是将网络功能与供应商提供的硬件设备相分离，有助于通过通用硬件来运行实现网络功能的软件。

SDN和NFV都可以提供灵活、可扩展、弹性且敏捷的网络部署机制，虽然可以独立部署这两种技术，但是也可以通过虚拟化网络功能以及将控制平面与转发平面分离等方式将SDN原理应用于NFV。

下图反映了两者之间的协同关系，此时的NFV使用商用硬件并实现了网络功能的转发平面，而控制平面功能则由SDN控制器完成。应用程序可以为SDN与NFV的协同工作提供黏合剂，最大限度地发挥这两种技术的优势，从而实现新型网络环境。

从下图可以看出，SDN、NFV以及应用程序相互协同之后，完全可以满足按需扩展、优化、部署以及速度等方面的云扩展需求。

服务提供商们都在朝这个方向努力，希望提升自己的商业优势并为最终用户快速部署新型服务。随着行业的积极转变，主流供应商和新进入者们纷纷支持这一发展趋势，并希望成为新市场领域的主要供应商。

由于SDN和NFV都提供了大量开源工具，因而需要认真评估这些联合研究项目以更好地使用这些工具，其中的一个典型案例就是ON.Lab（Open Networking Lab，开放网络实验室）与AT&T联合开展的名为CORD（Central Office Re-Architected as Datacenter，端局重构为数据中心）的研究项目，下面将详细介绍该项目以展示和解释NFV、SDN以及应用程序之间的协同关系。

1、CORD：SDN与NFV的协同案例

CORD是AT&T实验室与ON.Lab共同发起的一个研究项目，希望为传统电信端局的转型升级提供一种全新的体系架构，该平台可以为下一代网络服务提供可扩展、敏捷的部署方案。CORD将SDN和NFV作为体系架构的核心组件，采用开放的编排工具和应用程序的可编程性，同时将数据中心部署架构的相关概念结合在一起。

这种SDN与NFV结合方式，为新型网络服务的设计、实现及部署变革提供了一种非常完美的技术融合案例。SDN和NFV都以开源软件为基础，能够打破供应商的边界，这一点在CORD项目上得到了很好的体现，从本质上来说，CORD项目的核心就是由运行在供应商的通用硬件之上的开源软件实现的。

整个CORD架构包含硬件、软件以及服务编排功能，ONOS作为SDN控制器，网络服务由运行在COTS硬件上的VNF实现，OpenStack负责执行NFVI编排功能，最后由开放式云操作系统XOS将这些组件组合在一起，共同实现网络服务的创建、管理、运行以及提供能力。

下图给出了CORD架构示意图：

从图中可以看出，CORD的商用服务器以及底层网络采用了数据中心的spine-leaf架构。

SDN控制器及应用程序执行控制平面功能，而XOS和OpenStack则分别执行服务编排和NFVI编排功能。

开放计算项目最初由Facebook发起，旨在为数据中心基础设施资源（计算、存储、网络、交换矩阵、电力以及制冷等）开发有效的设计规范。经过两年的努力，该项目大大提升了Facebook位于俄勒冈州的数据中心的能效水平，成本效益提高显著。后来Intel、Rackspace以及其他公司也共同参与了该项目，并将该项目称为开放计算项目。

业界已开始利用CORD基础设施架构在特定领域积极探索CORD的应用示范。例如，移动供应商正探索将CORD用于5G移动服务，称为M-CORD。M-CORD通过将MME（Mobility Management Entity，移动性管理实体）、SGW（Serving Gateway，服务网关）以及其他模块虚拟化成相应的虚拟等效组件来应用NFV，同时利用SD-WAN等方法优化网络利用率，根据需要将流量引导到缓存服务器或Internet。其他领域的探索还有E-CORD（Enterprise CORD，企业CORD），E-CORD利用vFW、vLB以及SDN的理念来定制按需网络，以增强企业网的可编程性和适应性。

接下来介绍一下CORD在家庭宽带接入领域的应用情况。向用户提供宽带接入服务的传统端局架构起源于TDM（Time-Division Multiplexing，时分复用）时代。随着接入需求的快速增加，特别是通过G.fast和GPON（Gigabit Passive Optical Network，千兆无源光网络）等技术为用户提供千兆接入服务，需要调整传统端局的设计模式以满足各种新型服务提供需求。CORD的目标就是构建一种可扩展且灵活有效的基础架构，在降低运营成本及设备成本的情况下有效提供各种新服务。

下图给出了传统PON（Passive Optical Network，无源光网络）网络的系统架构图，PON网络连接用户的光纤（无论终结在什么位置）是无源器件，多个用户共享同一条去往接入端口的上行链路。

PON接入技术可以将光纤延伸到用户家中，通常将该接入方式称为FTTH（Fiber To The Home，光纤到户），此时的用户数据可以直接进入光纤链路，并与其他FTTH用户的数据复用在同一条光纤链路上。实际部署中的光纤接入形式还有很多。例如，仅将光纤部署到家庭附近，然后通过双绞线为家庭用户提供接入能力，该方式称为FTTC（Fiber To The Curb，光纤到路边）。

其他的还有类似于FTTC但用于多栋楼宇接入的FTTB（Fiber To The Basement，光纤到楼），以及从用户家庭到就近电信交接箱采用DSL（Digital Subscriber Line，数字用户线）技术的FTTCab（Fiber To The Cabinet，光纤到交接箱）。无论采用何种接入方式，总体的系统架构都与前面的描述基本一致。

PON部署方案中的关键组件如下：

CPE（Customer Premises Equipment，客户端设备）位于用户前端，可以提供网络接入、本地网络管理以及通过ONU（Optical Network Unit，光网络单元）连接网络等功能，ONU的作用是进行光信号与电信号的转换。
虽然ONU的位置可能会因不同的FTTx部署方案而有所不同，但是对于所有场景来说，来自用户（或多个用户）ONU的数据都会在DSLAM（DSL Access Multiplexer，DSL接入复用器）上通过WDM（Wave Division Multiplexing，波分复用）技术进行复用，由DSLAM将复用后的信号传送到CO（Central Office，端局）。
CO是大量DSLAM光纤连接的汇聚端，这些光纤链路都终结在OLT（Optical Line Terminator，光线路终端）设备上。OLT的作用与ONU相同，但顺序相反。接下来由BNG（Broadband Network Gateway，宽带网络网关）设备对用户进行认证，此后用户就可以访问CO所连接的任意网络。

G.fast和GPON这两种技术是目前实现家庭用户千兆接入的前沿技术。G.fast是VDSL（Very high-speed DSL，超高速DSL）的后续产品，可以提供千兆/秒的接入速率，比VDSL的速率快得多。

GPON则是另一种向用户提供千兆接入速度的家庭宽带接入技术，采用FTTH的点对多点部署方案。希望充分利用现有铜线资源为家庭用户提供宽带接入服务的服务提供商们，更愿意采用G.fast技术，将光纤尽可能部署到靠近用户的边缘（如FTTCab将光纤延伸到交接箱），然后再利用G.fast技术将用户连接到光纤所在位置。不过，G.fast只能工作在离光纤终结点几百米的范围内。

对于G.fast和GPON这两种技术来说，去往端局的光纤都要在用户之间共享。

通过CORD架构改造这类网络时，需要将CPE替换成vCPE（virtual CPE，虚拟CPE），将OLT替换为vOLT（virtual OLT，虚拟OLT），此时就要用到如下NFV技术。

CPE的虚拟化相对简单。CPE虚拟化可以利用非智能设备取代CPE，ONT的功能也可以在同一设备中实现。vCPE可以在端局运行新服务以及各种新用户功能。
OLT的虚拟化相对较为复杂，因为OLT在硬件平台中的作用非常重要。虽然也能解耦OLT的硬件和软件，但需要为vOLT的VNF打造专门的硬件，为此提出的解决方案是，与OCP（Open Compute Project，开放计算项目）合作开发具有开放规范的硬件设备。虽然该硬件是专门为OLT的虚拟化打造的，但并不依赖于任何特定供应商，而是全面支持开放式规范，任何人都能制造和复制，因而它的使用并没有违反NFV规则。
不需要通过vBNG VNF虚拟化BNG的功能。此时需要利用SDN技术，由SDN控制器（托管在ONOS上）管理交换矩阵中的流量流并传送给核心网络，该功能在传统网络中由BNG完成，BNG的身份认证及IP地址分配功能由vOLT完成。因此，vBNG的功能由基于SDN的流控制设备以及其他VNF设备共同完成。
OpenStack编排器负责管理NFV基础设施，ONOS通过交换矩阵管理流量流（如前所述），XOS与ONOS及OpenStack协同工作以实现宽带接入服务。

下图给出了宽带网络的CORD实现架构图：

CORD解决方案解决了当前各种应用领域（如有线、移动、商业VPN服务、IoT[Internet of Things，物联网]以及云等）所面临的相似挑战，可以满足各种新的不断增长的服务需求，快速实现各种创新服务。凭借SDN和NFV的技术优势，CORD为网络提供商们提供了一种极具扩展性且兼具技术与业务优势的创新平台。

2、NFV部署安全机制

如何结合SDN及应用程序来解决NFV的安全性问题，对于这种动态应用环境来说，必须将安全措施设计成能够快速响应安全威胁并实现高水平的健壮性。对于SDN、NFV以及应用程序等3个区域来说，不仅要为每个区域部署安全策略，还要为这3个区域部署公共安全策略，这样才能保障网络安全。

下图给出了需要为虚拟化网络中这些区域考虑的一些安全因素示例。

接下来讨论一些必要的基本安全措施：

VNF内及VNF间通信：VNF之间的通信流量存在两条路径，其中一条路径位于同一台服务器内部，使用虚链路。另一条路径位于服务器之间，使用物理基础设施。需要针对这两种情况为VNF内部及VNF间通信定义相应的安全措施，以确保流量的安全性。
NFV基础设施：需要及时更新主机OS（Operating System，操作系统）、Hypervisor、固件以及BIOS的安全补丁，以封堵基础设施的安全漏洞。必须对来自外部的基础设施访问行为加强安全防控，防范TCP（Transmission Control Protocol，传输控制协议）同步攻击、大流量DDoS（Distributed Denial of Service，分布式拒绝服务）等攻击行为。
SDN协议安全性：需要保护从SDN控制器到NFV基础设施的流量。必须采取适当的安全措施，部署安全加密及授权策略。例如，虽然OpenFlow并不强制要求将安全性作为必需字段，但是使用TLS（Transport Layer Security，传输层安全性）模式却可以为交换机或终端设备访问控制器提供设备认证措施，而且还能以加密格式保护控制器与交换机之间的控制协议消息，以防范窃听和中间人攻击。
SDN控制器安全性：由于SDN是运行在主机或VM（Virtual Machine，虚拟机）环境中的应用程序，因而可以利用NFV基础设施中描述的安全措施来加强主机或VM的安全性。对于SDN应用程序来说，需要评估这些应用程序的脆弱性并采取适当的安全措施。以ODL（Open Daylight）控制器为例，由于该控制器是一种基于Java的应用程序，因而必须评估和修补Java的所有安全漏洞，这样才能确保ODL控制器免受攻击。
用户和管理员授权策略：必须对由计算基础设施、VNF、编排器、SDN组件、Hypervisor以及应用程序组成的多域体系架构定义用户及管理员授权策略，这些域中的每一个域都可能属于不同的管理或操作组。如果NFV基础设施需要为客户托管基于租户的网络，那么就必须合并处理这些租户的身份认证及授权操作，从而提供必需的安全性以满足客户的访问策略。
公共安全策略：由于多个域存在紧密交互关系，因而单个用户可能需要以不同的权限访问多个域。这样一来，就要求安全策略必须适应这种灵活性，如SSO（Single-Sign-On，单点登录）身份认证与审计。

3、虚拟化网络功能实现

网络中的流量在进入、穿越和离开网络时可能需要经历一系列网络功能，这些网络功能可能会因为与流量相关的众多设计因素的不同而有所不同，可以将网络流量所经历的一系列功能视为链接在一起的功能链，而且这些网络功能所构成的网络服务是通过这些网络功能的组合效果展现出来的，因而将这种安排数据包路径以特定顺序遍历这些网络功能的设计模式称为服务功能链，或者简称为服务链。

为了体现转发路径，通常将下图中的类似折线图称为网络转发图。

此前曾以移动网络为例介绍过服务链的概念，这里介绍服务链架构的定义、实现方式以及NFV场景下的相关标准。

1. 传统网络中的服务链

服务链并不是一个新概念，传统网络就已经通过网络设备的物理和逻辑连接实现了服务功能链，但传统网络非常僵化，如果要对基于流量类别的路径做出任何变更，或者添加（删除）任何新的网络功能块，都必须改变服务链，这在实际应用中极具挑战性。

如果新的网络功能需要添加新硬件，那么就需要花费大量时间和资源来安装物理设备、配置传输链路。还有一种可能的方法就是采用叠加网络，特别是在硬件资源已经存在的情况下，通过配置叠加网络，对服务路径进行重路由，从而增加所需的功能块。虽然叠加网络可以解决服务链的某些物理网络限制，但是同样会增加配置复杂性，而且仍然依赖于底层的网络拓扑结构。

以下图为例，利用二层VLAN为不同的服务链配置了两种类型的流量，无论采用什么方法来增加新的网络功能，都无法在网络运行过程中部署新服务。

这样一来，不但会导致收入损失，而且会对供应商希望以更快、更灵活的方式满足云服务的规模部署带来严重限制。

采用物理或叠加网络技术实现服务链还存在另一个挑战，那就是无法提供应用程序级别的颗粒度、无法支持所有的传输介质或者实现不同叠加网络的互连，现有的叠加网络技术无法沿数据路径（中间节点或端节点可以利用数据路径来影响分组处理决策）携带应用程序级别的信息。

2. 满足云扩展需求的服务功能链

对于能够在更短时间内适应业务变化以满足市场需求的敏捷而灵活的网络架构来说，需要能够支持新服务的SFC（Service Function Chaining，服务功能链）架构，必须能够动态插入这些服务，而且对现有网络的干扰最小或者不会中断。考虑到业界正逐渐向虚拟化的方向演进，因而该架构还必须能够在虚拟网络、物理网络或混合网络上实现该目标。

此外，服务功能链技术还需要携带来自应用程序的信息并能够解析它们。目前已经出现了满足上述需求的一些标准及用例，下面将详细讨论这些标准及用例。

为了能够以一种统一、兼容的方式在全网实现满足上述目标要求的服务链功能，IETF（Internet Engineering Task Force，互联网工程任务组）一直都在尝试定义一种服务链架构，在架构中定义了多种功能模块，在协同工作的情况下实现的服务链能够很好地满足云扩展需求以及前述目标。

下图给出了该体系结构的高层视图以及相关组件：

图中显示的各个功能模块都是逻辑功能模块，某些功能或全部功能可能由单一物理设备、虚拟设备或混合设备完成，下面将详细介绍这些组件的具体功能。

1）SFC域

如果网络支持端到端的服务功能链功能且位于单一管理域下，那么SFC架构就将该网络称为启用了SFC的域（或简称为SFC域）。SFC域拥有入口节点和出口节点，这些节点构成SFC域的边界。数据包进入SFC域之后，SFC会对其进行分类并引导到正确的网络功能上，等到数据包离开出口节点时，会删除与SFC有关的所有信息，然后再将其转发给外部网络。

因此，SFC域只是整个网络的一部分，用于执行与特定服务相关的网络功能，同时具有相应的控制机制，能够根据规则选择需要遍历这些网络功能的流量。

2）分类器

分类器（Classifier）的定义非常简单直观，就是对进入SFC域的数据进行分类。流量分类操作既可以很简单地以源端或目的端为依据，也可以定义很复杂的分类策略。分类器会在数据包中添加SFC报头，以确保流量能够按照分类规则（如服务策略或其他匹配条件）在网络中沿着正确的路径进行传送。

与所有策略一样，这里提到的策略也是一组规则，由匹配条件及匹配操作组成。SFC场景下的策略可以匹配网络层中的信息，然后再根据匹配情况决定应该对数据包执行哪组网络功能。由于匹配规则还能匹配应用层信息，因而SFC的流量路径确定机制非常灵活和精细。

3）服务功能（SF）

SF（Service Function，服务功能）是对数据包执行网络服务或网络功能的逻辑功能模块。SF可以与应用层或以下的各层进行交互，可以包含防火墙、DPI（Deep Packet Inspection，深度包检测）、高速缓存或负载平衡等各种服务。

在理想情况下，执行该服务功能的设备支持SFC，也就是说能够理解并处理SFC报头。不过该SFC架构也允许不支持SFC的SF，即该SF无法处理携带SFC信息的数据包，此时就需要通过服务功能代理（Service Function Proxy）来处理进出该不支持SFC功能的SF的SFC数据包。

4）服务功能路径（SFP）

SFP（Service Function Path，服务功能路径）是SFC域内定义分类流量路径的规范信息。以城市公交线路为例，如果乘客乘坐了前往特定路线的公共汽车，那么就会经过确切的车站和路径，乘客也可以根据需要在中途的某个车站下车，然后再搭乘不同线路的联程巴士。

同样，SFC也不是一个严格定义所有跳的线性链，可以仅定义部分跳，也可以根据需要将流量灵活调整到新的流量路径上。

下图以图形方式解释了SFC路径的概念：

5）服务功能链或服务链（SFC）

SFC就是关于网络服务的完整拓扑结构以及与该流量路径相关联的参数或约束条件的逻辑抽象，因而SFC并不是一个逻辑功能模块，而是有关SFP、SF以及SFC域等逻辑功能模块的统一视图。仍然以前面的公交线路为例，可以将SFC视为城市内所有区域的所有公交车站及公交线路运行图，而SFP则是其中的某一条公交线路。

6）服务功能链封装

分类器识别出需要转发到服务链路径上的流量之后，会在数据帧中添加额外的报头信息，这个额外的报头就是服务功能链封装。目前存在多种可能的封装报头，三层VPN以及SR（Segment Routing，分段路由）等叠加网络技术都能实现服务链封装功能。

这些叠加技术都依赖于IP网的存在，IETF正在推动基于NSH（Network Service Header，网络服务报头）的新SFC封装格式的标准化工作，该标准能够与各种不同的底层网络协同工作。有

7）重新分类与分叉

分类器对SF报头的标记操作基于数据包进入SF域时的可用信息，不过有关数据包的某些最新信息（尤其是基于路径中的SF）可能需要修改路径并将流量转移到其他路径上，此时就要用到中间服务功能，对数据包进行重新分类，进而更新或修改SF路径。

这些信息会导致更新数据包中嵌入的信息，或者更新数据包的SF报头，或者两者兼而有之。我们将这种导致新路径的SFP更新称为分叉（Branching）。例如，如果防火墙SF的规则要求每天特定时段发起的流量不能去往游戏服务器，那么就会将这些流量发送给家长控制功能。

8）服务功能转发器（SFF）

SFF（Service Function Forwarder，服务功能转发器）负责查看SF报头并确定携带该服务报头的数据包的转发方式，以确保该数据包能够遍历指定的网络服务。数据包经过服务功能的处理操作之后，会被发送回SFF，由SFF将数据包转发给下一个网络服务。与其他功能模块一样，SFF也是一个逻辑单元，可以驻留在服务功能之内，也可以位于外部的ToR（Top of Rack，架顶）交换机。

一个SF域可以拥有多个SFF，下图为SFF功能的操作示意图。

图中的SFF将两种不同的分类流量发送给不同的SF，由SF处理完之后再返回给SFF。之前利用VLAN（Virtual LAN，虚拟LAN）叠加技术实现了类似目标，但是对于这种情况（即服务链所要完成的工作）来说，其配置过程非常复杂且难以跟踪，我们只要利用SFC架构并使用分类器、SF报头以及SFF，即可轻松实现上述目标。

9）服务功能代理（SF Proxy）

如果网络服务无法处理服务功能链信息，那么只要将SF代理放在进出该服务功能的流量路径中，就能保证该SF仍然是SF域的一部分。

SF代理会删除服务功能报头，然后根据SFC报头信息将解封装后的流量发送给服务功能，处理完该服务之后再将数据包送回SF代理，由SF代理重新插入服务功能报头及路径信息，并将流量转发给SFF以进行后续操作。

这种方式的缺点是服务功能只能执行本地网络功能，而不能执行任何可能会影响后续SF路径变更的操作。

10）服务功能控制平面

服务功能路径由负责服务叠加路径的服务功能控制平面构建，这种叠加路径可以是为数据包提供静态流的固定路径，也可以是基于网络部署特性的动态路径，还可以是静态路径与动态路径的组合。服务功能控制平面支持分布式模型和集中式模型，集中式模型中的集中式控制器被称为服务功能控制器。

11）服务功能控制器

SDN的概念非常适合于SFC，可以在集中控制器中定义服务路径，以抽象网络信息并通过应用层及集中式控制功能应用策略。实现该功能的逻辑模块称为服务功能控制器。

对于支持SDN的网络来说，SF控制器能够与SDN控制器集成在一起。

3. 网络服务报头（NSH）

NSH（Network Service Header，网络服务报头）为SFC的封装提供了协议标准，该标准由IETF管理并得到大量供应商的支持。NSH主要包括两大组件：第一个组件负责提供流量流在网络中采用的服务路径的信息，第二个组件以元数据的形式携带与净荷相关的附加信息。应用程序及高层协议可以利用NSH的元数据组件沿服务路径发送信息，该信息对于服务路径选择的决策进程以及可能需要对数据包执行的其他特殊处理都非常有用。

NSH协议报头包括3个部分：基本报头、服务路径报头以及上下文报头，如下图所示。

1）基本报头

基本报头是一个4字节报头，包含以下字段。

2比特版本字段，保留字段，目的是与未来版本实现向后兼容。
1比特O-bit字段，该字段表示数据包是否包含O&M（Operational and Maintenance，操作与维护）信息。如果NSH报头中的O-bit置位，那么就应该由SF和SFF检查该数据包的净荷。
1比特C-bit字段，该字段表示报头的后面部分至少有一个包含了关键信息的TLV（Type-Length-Value，类型—长度—值）。该比特的作用是简化数据包解析程序或硬件，只要简单地查看C-bit是否置位（而无须解析TLV数据）就能确定是否存在关键TLV信息。
6比特字段，保留给将来使用。6比特长度字段，表示NSH报头的长度。
8比特字段字段，保留字段。用于定义所用的元数据类型或选项。目前NSH定义了两种类型的元数据：类型1和类型2。NSH类型1元数据的报头格式固定，有助于服务转发操作以维护可预测的转发性能，而且还便于硬件的最佳实现，所有的NSH实现都必须支持该类型元数据。第二种选项就是类型2元数据，类型2元数据采用可变长度，可以携带自定义信息，如应用程序级别的侦听器、TLV等，协议希望NSH实现支持类型2元数据。基本报头信息仅标识元数据类型，有关元数据信息本身的内容则位于其他报头字段。
基本报头的最后8比特用于标识数据包的原始协议。

协议允许的内部数据包协议值如下表所示：

2）服务路径报头

服务路径报头包含了服务路径的相关信息，是一个4字节报头，包括如下字段。

SPI（Service Path Identifier，服务路径标识符）字段，是该报头的主要部分，使用了32比特中的24比特。SPI唯一标识了数据包将在SFC域内使用的服务路径。如果以公交线路为例来解释服务功能路径，那么SPI就是公交车的线路编号。
SI（Service Index，服务索引）字段，使用剩余的8比特来指示该数据包在服务路径中的位置。数据包每经过一个启用了SFC功能的节点，服务路径都会递减1，因而查看SPI和SI值就能准确确定数据包所在的SF。SI的工作方式与IP报头中检测环路的TTL（Time To Live，生存时间）值相似。

3）上下文报头

上下文报头包含了由高层信息嵌入或者基于高层信息的元数据及其他信息。该报头的长度取决于所用的元数据是类型1还是类型2，如果使用的是类型1元数据，那么就会在NSH报头中增加4个4字节上下文报头块；如果使用的是类型2元数据，那么该报头就可以是可变长度或者根本不存在。

4）NSH MD类型

如基本报头所述，NSH报头支持两种不同的MD（MetaData，元数据）选项，而且上下文报头也会随着MD的类型变化而变化。对于类型1来说，上下文报头中的数据是不透明的，而且没有特定格式，包含在4个字段中的数据可以是该实现选择的任意元数据。NSH标准建议但并不要求使用如下4个上下文报头字段。

网络平台上下文：有关网络设备的信息，如端口速率和类型、QoS（Quality of Service，服务质量）标记等。
网络共享上下文：网络节点可用的数据，传递给网络中的其他节点之后将非常有用。例如，与接口相关联的客户的信息以及节点的位置信息等。
服务平台上下文：可以由网络节点使用的网络服务信息，这些信息可以与其他节点共享。例如，对流量实施负载均衡的哈希算法的类型。
共享服务上下文：包含了对网络中实现网络服务有用的元数据。如果要对穿越网络的流量实施特殊处理（可能基于用户所购买的服务等级），那么就可以将该信息作为元数据嵌入报头，从而传播给所有启用了NSH功能的设备。

如果使用的是类型2 MD，那么就可以存在任意数量的上下文报头（此时基本报头的长度字段将非常有用，因为此时的NSH报头的长度可变）。

与强制性的类型1的上下文报头不同，NSH标准为可选的类型2报头定义了特定格式，如下图所示。

TLV是Type-Length-Value（类型—长度—值）的首字母缩写，广泛应用在各种网络协议中。按照定义，TLV利用充当键的类型字段、可变长度的值字段以及表示值字段大小的长度字段来封装数据。这是通过协议传递可变长度键—值（key-value）对信息的一种通用方法。

采用TLV格式，其中，类型字段8比特，长度字段5比特，值字段32比特，保留字段3比特（供将来使用），另外还在报头的起始位置指定了一个2字节的TLV类别（Class）字段，TLV类别字段的作用是指定TLV字段的类别，如TLV所属的供应商或正在使用的TLV实现的标准信息。

类型字段的数值保持开放性，可以由具体的NSH协议实现来定义，不过其高阶比特具有一定的特殊意义，该比特表示数据包经过的节点都要处理和理解TLV。因此，强制要求SFC必须理解类型字段数值为128～255的TLV，类型字段数值为0～127的则可以忽略。

NSH报头位于原始的二层或三层报头与数据净荷之间，如下图所示。

为了提供服务可见性、服务保障以及故障排查等功能，NSH在报头中提供了O-bit以支持O&M功能。

NSH服务路径的设置可以采用分布式方式，每个网络节点都能定义服务路径，也可以利用集中式控制器实现集中式设置方式，由具有网络查看能力的集中式控制器定义服务路径，并通过分类器将NSH服务路径插入来自服务域的数据包。

5）元数据

SFC的一个主要优点是能够以元数据的形式传送和使用应用程序级别的信息。从元数据的通用定义来看，术语元数据指的是与数据相关的信息集。对于SFC场景来说，元数据提供的是与穿越SFC域的数据有关的上下文信息。SFC分类器的作用是在服务报头（如NSH上下文报头）中插入元数据，SFC可以从高层协议中提取该信息（如HTTP报头或URL中的信息）。

例如，分类器可以利用元数据根据不同的目的地来标记视频流量，将去往优选流媒体内容的流量放到高质量服务路径上。将元数据插入SFC协议报头之后，路径中的节点（SFF、SF等）就会读取、处理和响应数据并执行适当的预定义操作。

可以采用不同的方法在服务功能链的组件之间交换元数据信息，常见方法如下。

带内信令，如NSH、MPLS标签以及分段路由标签等。
应用层报头，如HTTP。
一致性带外信令，如RSVP（Resource Reservation Protocol，资源预留协议）。
非一致性带外信令，如OpenFlow和PCEP（Path Computation Element Protocol，路径计算单元协议）。
混合带内和带外信令，如VXLAN（Virtual Extensible LAN，虚拟可扩展LAN）。
带内信令

如果元数据作为数据包的一部分携带在数据包中，那么就称为带内信令。此时的元数据可以是报头的一部分或净荷的一部分。

下图所示为元数据信令流的示意图，网络服务报头就是一个带内信令的很好的案例。

应用层报头中的元数据：应用层报头中的元数据可以在应用层报头中传输，只要能够使用该七层信息的服务功能就能使用该信息。使用应用层元数据的常见案例主要有HTTP <meta>标记以及SMTP的X元数据。

一致性带外信令：如果在独立信道中携带元数据信息并在不同的流中传输该数据（即使两个分组流都在同一路径上），那么就是一致的带外信令，如下图所示。

FTP（File Transfer Protocol，文件传输协议）是使用该类信令的典型示例，端口21用于控制信令，端口22用于数据传输。

非一致性带外元信令，虽然前面的信令模式中的元数据是由与数据流不同的其他流承载的，但两个分组流的路径仍然相同。对于非一致的带外信令来说，元数据信令采用的是与数据流量流不同的路径。

下图信令模型示例中的信令控制平面与节点进行交互并负责管理元数据。使用该类信令的常见案例主要有BGP（Border Gateway Protocol，边界网关协议）、路由反射器、PCEP以及OpenFlow。

混合带内和带外信令，网络的元数据信令可以是包含带内信令及带外信令的混合元数据信令。

从下图可以看出，混合信令模型是带内模型与带外模型的组合，使用该类信令的常见案例有VXLAN和L2TP（Layer 2 Tunneling Protocol，二层隧道协议）

4. 其他SFC协议

虽然由IETF支持的NSH是SFC的新兴标准，但是可以采用多种方式实现元数据通信，因而可以通过多种协议来实现SFC，包括一些存在很长时间的协议，如MPLS-TE、VXLAN或SR-TE（Segment Routing Traffic Engineering，分段路由流量工程）。

下图给出了利用SR-TE实现SFC的示例，集中式SDN控制器在此充当SFC，并通过PCEP与网络中的设备进行通信。

SFC分类器根据基于流量类型的预定义策略，将SR（Segment Routing，分段路由）标签栈附加到数据包中，携带SR标签的流量将被引导到执行指定功能（充当SF）的设备（根据最外层标签）。SF处理完数据包之后，将根据下一个SR标签将其引导到下一跳。

如果SFC控制器确定SF的处理操作需要重新计算路径，那么就可以指示SF在现有标签栈上插入一组新标签。

5. 服务链用例

服务链的好处是可以通过流量分类（基于高层协议信息）控制流量路径，网络设计人员、服务提供商以及最终用户都能从中获益。

对于网络设计人员来说，服务链提供了强大的流量控制机制，能够实现复杂且精细化控制的应用感知策略，提高网络使用效率，从而很好地适应每天不同时段、需求波动以及网络故障等需求场景。

企业可以使用元数据信息为用户提供非常精细化的服务等级，提供新型创新服务，可能的应用如下。

可以对家庭监控系统的视频流量进行分类，将这些流量发送到云存储或远程流式传输之前执行加密功能。
可以提供网络安全服务，将浏览器流量转向可识别和警告恶意软件的DPI（Deep Packet Inspection，深度包检测）设备，而使语音、视频以及其他数据流量绕过DPI。
服务提供商可以为SD-WAN（Software-Defined Wide-Area Network，软件定义广域网）提供一种可选解决方案。对于SD-WAN解决方案来说，企业需要实现自己的SD-WAN解决方案并将其用于不同办公场所之间的通信，从而优化WAN链路。如果企业不希望维护自己的SD-WAN解决方案，但又希望达到相同效果，那么就可以让服务提供商通过SFC对流量进行分类，并根据目的端、源端、应用程序类型以及其他元数据信息对流量进行标记，通过该标记可以为流量建立不同的服务路径。
最终用户可以从上述应用示例中展现出来的新型灵活服务中受益。SFC与NFV相结合，还允许用户按需修改他们的服务协议，利用服务提供商提供的服务门户，用户可以通过这些服务门户添加、删除或修改他们希望包含在服务包中的网络功能。

下面以家长控制上网服务为例来分析利用SFC概念创建、设计和部署新服务的方式。

需求：该服务应该能够让父母限制其子女使用上网设备访问网络。
设计：每种设备的浏览器都会发送标识OS版本以及硬件等信息的元数据，可以通过插件让浏览器发送额外的元数据，将上网设备的标识简化为儿童设备。服务提供商设计分类器，利用特定的元数据匹配策略来标记流量的SFC报头，将识别为源自儿童设备的流量路由给防火墙，而来自其他设备的流量则不需要经过过滤设备。
实施：服务提供商提供服务门户，父母通过服务门户来指定可感知时间及目的地的过滤器，并定义可映射为不同服务策略的设备配置文件。

4、虚拟化网络的可编程性

为了充分利用NFV和SDN的技术优势，必须最大限度地利用网络可编程性来配置、管理和维护网络，这些技术以及开放软件架构的日益普及为可编程网络的实现奠定了坚实的基础。

为了完整起见，下面将按步骤介绍如何在NFV网络的部署及操作阶段开发和利用虚拟化网络的可编程性。

首先假设NFV基础设施组件（计算、存储及网络）以及提供连接性的底层网络已经部署到位，下图给出了NFV、SDN以及应用程序融合应用场景下的事件流程，图中列出的步骤旨在解释应用程序的参与方式以及完整的实现步骤。

详细步骤如下：

第1步：从应用层启动网络设计和实现流程。应用层位于分层架构的顶层，与NFV-MANO及SDN控制器进行通信。

应用层可能只有单个应用程序，也可能包含一组可协同工作的独立的应用程序，这些应用程序承担服务编排器、网络监控和管理系统的角色。应用程序可以采用任何语言进行编写，只要能够使用MANO及SDN模块的北向协议进行通信即可，一般采用Python、C ++、Java和Go语言，北向协议通常是由SDN及MANO工具开发者发布的RESTAPI或Open API。

第2步：应用程序根据服务描述，与MANO进行通信以实例化网络服务所需的虚拟机及VNF。MANO的各个功能模块，如VIM与基础设施协同可以创建虚拟机，VNFM则负责创建VNF资源等，这些模块通过ETSI定义的参考点进行通信。

第3步：创建了VNF之后，利用VLD（Virtual Link Descriptor，虚拟链路描述符）信息互连这些VNF，VNF的互连涉及虚拟交换机的编程问题。

第4步：部署并连接了VNF之后，就可以为构成网络数据平面的虚拟网络服务创建拓扑结构。数据平面可以是纯二层网络、基于VXLAN的网络、基于三层/IP的网络或基于MPLS的网络。至此网络就已经准备好执行各种功能，如防火墙、负载平衡、NAT等。虽然该网络使用实际的物理网络（构成NFVI）作为其底层网络，但该网络本身也可以用作服务层（利用服务功能链提供叠加式服务）的底层网络。

第5步：此时的应用程序与SDN/SF控制器进行交互，并利用控制器根据已定义策略为流量部署相应的服务路径。

从控制器到VNF的通信使用的SDN南向协议，常用的就是NETCONF、RESTCONF以及gRPC，也可以使用其他协议，如Juniper Contrail使用的XMPP、PCEP、OpenFlow或Open API。

这样就完成了网络的初始部署阶段，此时的网络层已经完全可以提供服务，应用程序也可以承担网络监控角色，可以在不同的层面监控网络，如监控VNF的状态以及与功能相关的参数、监控VNF和虚拟机的状态以及监控基础设施等。可以对应用程序进行编程，以根据监控数据中的信息做出自主决策。接下来就以下例来说明这样做的好处。

可能需要更改流量路径来处理特定的流量流、带宽需求的激增或网络故障，这种改变流量路径的决策可以由应用程序中的逻辑完成，然后再通过SDN控制器传递给设备。

NFV MANO可以检测到导致VNF资源过载的需求增加（预期需求或意外需求），然后基于该信息触发VNF的弹性机制。虽然可以通过MANO的功能模块来完成这些工作，但是也可以由应用程序根据全局策略做出的决策来处理这些情况。

VNF（或主机）代码错误可能会对网络造成潜在影响。如果应用程序能够以编程方式智能化地识别并修复错误，那么就可以自动修复差错状态并恢复或保护网络。

此外，应用程序还允许用户、OSS/BSS（Operational and Business Support System，运营和业务支持系统）以及其他应用程序与其交互，并要求其更改网络服务、规模或拓扑结构。应用程序会将这些要求转换成明确的变更需求，然后再将指令发送给MANO或SDN以实现这些变更。

上述步骤不但解释了应用程序的作用以及可编程性在网络部署及网络操作过程中的使用方式，而且说明了在多个逻辑层中构建网络的方式。

下图详细说明了这种逻辑分层概念，而且还显示了这些拓扑结构层次与5个阶段之间的关系。

从图中可以看出，物理基础设施提供了拓扑结构视图并充当NFV的原始底层网络，NFV网络创建于基础架构之上，呈现的是虚拟网络拓扑结构视图，这是一个全功能网络，所有的VNF都以期望的拓扑结构进行互连，从而提供相应的服务。最终用户并不关心VNF的互连方式，仅关心服务所提供的内容，显示的是虚拟网络服务视图。

最后，如果部署了SFC，那么就会将服务拓扑结构视为为流量提供一组不同服务（基于流量类型、元数据或其他高层信息）的逻辑网络，被实现成流量转发和处理策略，称为虚拟服务策略视图。