软件定义网络：SDN与OpenFlow解析 (图灵程序设计丛书)
Author: Thomas D. Nadeau; Ken Gray
Date: 2014-05-02T00:00:00+00:00
Publisher: 人民邮电出版社

版权信息

书名：软件定义网络：SDN与OpenFlow解析（迄今为止SDN领域最权威最重要的著作）

作者：Thomas Nadeau D， Ken Gray 译者：毕军， 单业， 张绍宇， 姚广

ISBN：978-7-115-35147-0

本书由北京图灵文化发展有限公司发行数字版。版权所有，侵权必究。

您购买的图灵电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。

如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。

目录

版权声明

O’Reilly Media, Inc.介绍

蒋林涛推荐序

专家推荐语

译者序

2014：超越炒作，进入部署SDN的时代（David Ward中文版序）

作者中文版序

David Meyer序

David Ward序

前言

Thomas Nadeau的致谢

Ken Gray的致谢

第1章　引言

第2章　集中式与分布式的控制平面和数据平面

2.1　引言

2.2　控制平面和数据平面做什么

2.2.1　控制平面

2.2.2　数据平面

2.2.3　在控制平面和数据平面之间传递信息

2.2.4　为什么控制平面与数据平面分离变得重要

2.3　分布式控制平面

2.3.1　IP和MPLS

2.3.2　建立IP承载网

2.3.3　收敛时间

2.3.4　负载均衡

2.3.5　高可用性

2.3.6　建立MPLS叠加

2.3.7　组播复制

2.4　集中式控制平面

2.4.1　逻辑上的集中式与字面含义上的集中式

2.4.2　ATM/LANE

2.4.3　路由服务器

2.5　小结

第3章　OpenFlow

3.1　引言

3.2　OpenFlow线路协议

3.2.1　复制

3.2.2　 FAWG（转发抽象工作组，Forwarding Abstraction Workgroup）

3.2.3　配置和扩充性（Extensibility）

3.2.4　体系结构

3.3　混合方案

3.3.1　午夜行船模型

3.3.2　双功能交换机

3.4　小结

第4章　SDN控制器

4.1　引言

4.2　基本概念

4.2.1　VMware的控制器

4.2.2　Nicira的控制器

4.2.3　VMware/Nicira的控制器

4.2.4　OpenFlow相关的控制器

4.2.5　Mininet仿真器

4.2.6　NOX/POX控制器

4.2.7　Trema控制器

4.2.8　Ryu控制器

4.2.9　Big Switch公司/Floodlight控制器

4.3　以网络三层为中心的架构

4.3.1　三层VPN的控制器

4.3.2　路径计算单元（PCE）服务器

4.4　Plexxi公司的控制器

4.5　Cisco公司的OnePK控制器

4.6　小结

第5章　网络可编程性

5.1　引言

5.2　管理接口

5.3　应用程序与网络之间的鸿沟

5.3.1　命令行界面（CLI）

5.3.2　NETCONF和NETMOD

5.3.3　SNMP

5.4　现代的编程接口

5.4.1　发布和订阅接口

5.4.2　XMPP

5.4.3　谷歌公司的Protocol Buffers

5.4.4　Thrift

5.4.5　JSON

5.4.6　I2RS

5.5　现代的服务编排

5.5.1　OpenStack

5.5.2　CloudStack

5.5.3　Puppet

5.6　小结

第6章　数据中心的概念与结构

6.1　引言

6.2　多租户数据中心

6.3　虚拟化多租户数据中心

6.3.1　服务编排

6.3.2　连接租户到互联网/VPN

6.3.3　虚拟机迁移与弹性

6.3.4　数据中心互连（DCI）

6.3.5　关于数据中心分布式计算的谬误

6.3.6　数据中心分布式计算的陷阱

6.4　数据中心网络的SDN解决方案

6.4.1　网络承载层

6.4.2　叠加网络

6.5　小结

第7章　网络功能虚拟化

7.1　引言

7.2　虚拟化与数据平面I/O

7.2.1　数据平面I/O

7.2.2　I/O小结

7.3　服务工程路径（Service Engineered Path）

7.4　服务位置与服务链

7.4.1　元数据

7.4.2　一种应用层方法

7.4.3　规模

7.5　ETSI NFV

7.6　非ETSI NFV

7.6.1　Middlebox研究

7.6.2　Embrane/LineRate

7.6.3　平台虚拟化

7.7　小结

第8章　网络拓扑结构与拓扑信息抽象

8.1　引言

8.2　网络拓扑结构

8.3　传统方法

8.4　LLDP

8.5　BGP-TE/LS

用BGP-LS来支持PCE

8.6　ALTO

BGP-LS和PCE与ALTO互动

8.7　I2RS拓扑

8.8　小结

第9章　构建SDN框架

9.1　引言

9.2　先写代码，再问问题

9.3　瞻博公司的SDN框架

9.4　IETF的SDN框架

9.4.1　SDN（P）

9.4.2　ABNO

9.5　OpenDaylight的控制器/框架

9.5.1　API

9.5.2　高可用性和状态存储

9.5.3　分析

9.5.4　策略

9.6　小结

第10章　带宽调度、操控和时间规划的用例

10.1　简介

10.2　带宽时间规划

10.2.1　基础拓扑结构以及基本概念

10.2.2　OpenFlow和PCE拓扑结构

10.2.3　配置示例

10.2.4　OpenFlow业务开通示例

10.2.5　控制器增强

10.2.6　采用PCE配置的叠加网络示例

10.2.7　深入调研：大举向新领域进军

10.3　在即时CSPF中使用大数据和应用程序超虚拟化技术

10.4　扩展拓扑结构

10.5　小结

第11章　数据中心叠加网、大数据和网络功能虚拟化的用例

11.1　引言

11.2　数据中心服务编排

11.2.1　创建租户和虚拟机状态

11.2.2　转发状态

11.2.3　数据驱动的学习

11.2.4　控制平面发信令

11.2.5　对扩展性和性能的考虑

11.3　Puppet（DevOps解决方案）

11.4　网络功能虚拟化（NFV）

NFV的可移动性

11.5　优化的大数据

11.6　小结

第12章　输入流量监测、分类及触发操作的用例

12.1　引言

12.2　防火墙

12.3　防火墙即服务

12.4　网络访问控制的替代方案

12.5　采用虚拟防火墙来扩充用例

12.6　反馈与优化

12.7　入侵检测/威胁缓解

12.8　小结

第13章　最后的思考与结论

13.1　什么是真正的SDN

13.1.1　经济学

13.1.2　SDN实际上与运行和管理相关

13.2　SDN的多种定义

13.3　人们正在取得进步吗

术语表

关于封面

版权声明

©2013 Thomas D. Nadeau, Ken Gray.

Simplified Chinese Edition, jointly published by O’Reilly Media, Inc.and Posts & TelecomPress, 2014. Authorized translation of the English edition, 2014 O’Reilly Media, Inc., theowner of all rights to publish and sell the same.

All rights reserved including the rights of reproduction in whole or in part in any form.

英文原版由O’Reilly Media, Inc. 出版2013。

简体中文版由人民邮电出版社出版， 2014。英文原版的翻译得到O’Reilly Media, Inc. 的授权。此简体中文版的出版和销售得到出版权和销售权的所有者——O’Reilly Media,Inc.的许可。

版权所有，未得书面许可，本书的任何部分和全部不得以任何形式重制。

O’Reilly Media, Inc.介绍

O’Reilly Media 通过图书、杂志、在线服务、调查研究和会议等方式传播创新知识。自1978 年开始，O’Reilly 一直都是前沿发展的见证者和推动者。超级极客们正在开创着未来，而我们关注真正重要的技术趋势——通过放大那些“细微的信号”来刺激社会对新科技的应用。作为技术社区中活跃的参与者，O’Reilly 的发展充满了对创新的倡导、创造和发扬光大。

O’Reilly 为软件开发人员带来革命性的“动物书”；创建第一个商业网站（GNN）；组织了影响深远的开放源代码峰会，以至于开源软件运动以此命名；创立了Make 杂志，从而成为DIY 革命的主要先锋；公司一如既往地通过多种形式缔结信息与人的纽带。O’Reilly 的会议和峰会集聚了众多超级极客和高瞻远瞩的商业领袖，共同描绘出开创新产业的革命性思想。作为技术人士获取信息的选择，O’Reilly 现在还将先锋专家的知识传递给普通的计算机用户。无论是通过书籍出版、在线服务或者面授课程，每一项O’Reilly 的产品都反映了公司不可动摇的理念——信息是激发创新的力量。

业界评论

“O’Reilly Radar 博客有口皆碑。”

——Wired

“O’Reilly 凭借一系列（真希望当初我也想到了）非凡想法建立了数百万美元的业务。”

——Business 2.0

“O’Reilly Conference 是聚集关键思想领袖的绝对典范。”

——CRN

“一本O’Reilly 的书就代表一个有用、有前途、需要学习的主题。”

——Irish Times “Tim 是位特立独行的商人，他不光放眼于最长远、最广阔的视野并且切实地按照Yogi Berra 的建议去做了：‘如果你在路上遇到岔路口，走小路（岔路）。’回顾过去Tim 似乎每一次都选择了小路，而且有几次都是一闪即逝的机会，尽管大路也不错。”

——Linux Journal

蒋林涛推荐序

软件定义网络（SDN，Software Defined Networks）是美国斯坦福大学提出的，它是以OpenFlow 为基础，为了建设网络的创新平台设计的。目前SDN 的概念已经被泛化，泛化后的SDN 目标大体有：简化网络操作，提升网络性能，提供网络创新平台，研究下一代网络技术。SDN 不仅是Software Defined Networks 的缩写形式，同时也是Software Defined Networking 和Software Driven Network 的缩写形式。

上述“三种”SDN，从应用场景角度可以分为两类。一类是用于创新网络的场景，基于OpenFlow 的Software Defined Networks；另一类是为了简化网络操作、优化网络结构和性能的Software Defined Networking 和Software Driven Network。

第一类SDN 主要用于创新网络场景，可以生成新的网络。具体步骤是：1. 提出对新型网络的技术需求；2. 提出新型网络的完整的体系架构和总体技术要求（即完成网络的顶层设计）;3. 设计流表，开发软件，生成新型网络；4. 能力开放（API），北向接口开放；5. 控制器中增加软件定义能力。第一类SDN 基于OpenFlow，与OpenFlow 紧密关联。应用场景大体上有两个方面：网络技术的创新平台，以及研究和生成新型网络。

第二类SDN 与OpenFlow 没有必然的关联。尽管在很多场合还是使用了OpenFlow，但不用OpenFlow 也完全不影响它的工作。这类SDN 中又可以分为软件驱动网络（Software Driven Network）和软件定义组网（Software Define Networking）两类。

软件驱动网络（Software Driven Network） 的设想是很合理的， 那就是业务层（Service Stratum）和传送层（Transport Stratum）间需要接口以便互控，这个接口就是SDN 中说的网络北向接口。从表面上来看，北向接口问题解决起来好像很简单。实际上，当网络规模不大的时候的确不难。但随着网络规模的扩大，问题就来了。目前所想到的办法都存在严重的扩展性问题，是无法真正实用的。由于机理中的基因缺陷，北向接口做起来很难。

软件定义组网（Software Define Networking）就泛化了，大体上等于：1. 智能网管＋ QoS 路由＋软路由器；2. 网管能力开放（API）；3. 网管中增加软件定义能力；4. 网管智能化，网络能力虚拟化和智能化等。目前提出的绝大多数的SDN 应用场景都属于这一类，一般来说对局部、小范围都是有效的，但规模大了都很难实现。控制与转发分离只是SDN 的特征之一，不是其主要特征。控制与转发分离有好处也有坏处，不是一概都好。一般来说，集中控制做不大，扩展性差是通病。它的适用场景是：改造现有网络，简化网络操作，提升网络性能。

本书前言中提到一种很神奇的动物：鸭子。作者明确说道：“鸭子游动时大多数的动作都在水下完成，而这些动作是无法轻易观察到的。强健的脚掌在水面下滑动着，推动鸭子前进，这与软件定义网络在很多方面有着相似之处。” 以此来表述作者对SDN的看法。当然，中国的一般说法是：“鸭子什么都会做，但什么都做不好。”本书前言中提到的鸭子，给读者对SDN 留下了一个很宽泛的想象空间。

国内对SDN 的看法分歧很大。有高度看好SDN 的，认为它是网络界的救星，能够为网络带来翻天覆地的变化；有一般看好SDN 的，认为这是一种局部技术，在局部对网络优化是有贡献的；也有完全不看好SDN 的，认为它是网络界在包装上的一场炒作。当然，这些看法都有道理，都是从各自的期望出发的。我是看好SDN 的。近期，SDN 可以用于在局部范围内改造网络，优化网络结构，提升网络性能；远期，SDN可以成为网络创新的潜在实现技术。

目前的SDN 技术还非常初步，在体系结构上、协议上、硬件上都有很大的开拓空间。但从SDN 的发展来说，真正困难的是对网络的理解，网络的顶层设计。SDN 的机遇与挑战共存，机遇大于挑战。因此，必须明确方向，摆脱盲从思维，坚定地走自己的路。

工业和信息化部电信研究院科技委主任
2014年3月于北京

专家推荐语

互联网不断超出预期的快速发展，使其在扩展性、安全性等方面的挑战日益严重。随着OTT 等业务的迅猛增长，整个互联网的生态环境也将面临新的挑战，而网络技术的发展远远跟不上业务发展的需求。SDN 技术的提出代表业界对网络变革的期盼，SDN 的很多设计理念无疑是先进的，但目前还没有能解决网络中的很多问题。但它就像举起的一面旗帜，吹响了号角，号召大家共同关心、研究网络中的问题，并研究如何满足未来网络发展的需要。所以认真学习、了解国外在SDN 方面的研究成果及国外同行思考问题的方式无疑对我们将有很大的帮助。

——刘韵洁
中国工程院院士
中国联通科技委主任

列宁说过“没有革命的理论，就没有革命的行动”，目前网络的发展日新月异，具有极大的机会和挑战性，迫切需要相关的理论和模型指导，而软件定义网络（SDN）应运而生。我推荐阅读这本书，更希望读者能够把解决实际问题贯穿到阅读的从始至终。如果在这个过程中发现SDN 可以解决你所面临的在网络建设、运行、对应用的支持和商业模型上的核心问题，那就达到了我推荐这本书的目的。

——李星
清华大学电子工程系教授、清华大学网络科学与网络空间研究院副主任
中国教育和科研计算机网（CERNET）网络中心副主任
中国计算机学会互联网专业委员会主任
国际互联网体系结构委员会（IAB）委员

SDN即软件定义网络，催生了新型网络体系结构的思维模式，其核心思想是通过硬件设备的标准化、网络层面的控制转发分离、对设备的抽象封装来增强网络可编程能力。通过网络操作系统对底层网络设备的抽象，为上层应用提供统一的管理视图和编程接口。进而，基于网络操作系统，用户可以开发各种网络应用程序，通过软件来定义网络的业务处理逻辑，实现高效灵活的管控。尽管近年来SDN 得到了业界的广泛关注，但对其的争论与困惑也一直不绝于耳。本书的作者和译者在网络体系架构的研究领域有着很深的造诣，通过浅显易懂的语言对SDN 技术进行了深入的剖析，对网络工程及科研人员来说都是一本难得的学习与参考用书。

——吴春明
浙江大学教授、博士生导师

SDN作为一种新的网络范型，采用控制平面与数据平面分离的架构，不仅使得控制平面与数据平面可以独立演化，有助于解决网络僵化问题，而且带来了传统网络架构不具备的很多优势，例如，可编程能力有利于网络创新，集中化控制方便和简化网管，全局网络视图使网络细粒度控制成为可能，虚拟化支持网络资源优化调度和高效利用，等等。这一切使得SDN受到学术界和业界的广泛关注，得到迅速发展。这本译著的出版对于SDN 的研究者、开发者、实践者、学习者都是一个福音，有助于推动SDN在中国的理论研究和工程实践。

——王兴伟
东北大学教授、博士生导师
国家杰出青年科学基金获得者
中国通信学会会士

软件定义网络代表着网络工业的发展未来，是目前学术界最热门的研究话题之一。本书对软件定义网络的体系结构和相关技术有很全面的覆盖，不仅描述了软件定义网络的最新技术进展，还融入了两位原作者作为该领域的资深人士对软件定义网络未来方向的思考。本书对高校广大教师和学生了解与研究软件定义网络是很好的技术参考书。本书译者毕军教授在软件定义网络领域造诣深厚，对原书的技术内容有非常准确的把握，充分保证了译著的质量。

——刘向阳（Alex X. Liu）
南京大学计算机系教授、博士生导师
教育部长江学者特聘教授

作为一种新型的网络架构，SDN引起了广泛的关注。从整个通信网架构30多年的发展看，都在向结构扁平化和集中控制的方向发展，例如电信网从电路交换网发展到智能网再到基于软交换的NGN 和IMS，就体现了这个趋势。我们在多年从事网络建设的实践中发现，计算机网络的架构这几年也在向这个方向发展，这体现在主流厂家的产品和解决方案上。而明确把这种体系以SDN的方式系统地提出则是把这种演变趋势作为网络体系发展的里程碑，这对激发业界的创新动力、推动计算机网络的发展是十分有意义的。不仅如此，开放和个性化是IT发展的主流，用软件定义增强系统的弹性在很多IT系统中都得到了应用，全球最具权威的IT研究与顾问咨询公司Gartner（高德纳）把软件定义一切（Software Defined X) 作为2014年十大战略技术之一，就反应了这种趋势。

本书是国内外较早系统讲述SDN 的教材，作者有丰富的工程技术背景，翻译者毕军教授多年来一直从事网络体系的研究，在清华大学组建了SDN 的实验网，是第一届全国高校SDN 网络应用创新开发大赛专家组组长，对SDN 技术的发展、原理、技术和应用都有深刻的理解。因此，本书的出版对从事计算机网络研究的工程技术人员无疑是一种福音。

——陆以勤
中国教科网华南地区网络中心主任
华南理工大学信息网络工程研究中心（信息化办公室）主任
博士、教授（二级）、博士生导师
第一届全国高校SDN 网络应用创新开发大赛执委会秘书长

逐渐兴起的软件定义网络（SDN）技术正在成为近年学术界和工业界讨论的热点。SDN的核心理念是网络软件化，网络能力得充分开放，使得网络能够像软件组件一样便捷、灵活，从而提高网络的创新能力。但是目前业界对于什么是SDN、SDN 技术对于网络技术的演进和发展有什么样的作用，以及它的前景如何等问题仍有诸多困惑。本书对SDN 的现状、进展、关键技术和典型应用进行了全面客观的介绍和剖析，本书作者和译者均是具有很强网络理论和工程技术背景的网络技术专家，他们以扎实的技术功底和对SDN 技术的精确把握，把晦涩抽象的专业知识用通俗易懂的语言和示例深入浅出地介绍给了我们，这是一本让读者认识和了解SDN 技术的必备书籍。

——王文东
北京邮电大学网络技术研究院副院长、教授、博士生导师

SDN受到学术界与工业界的广泛关注。本书系统地介绍了SDN 的背景、基础知识与实践，主要内容涵盖了基本概念、协议定义、系统实现、应用实例，对相关领域专业人员与学生有很强的参考价值。

——谢高岗
研究员、博士生导师
中国科学院计算技术研究所网络技术研究中心主任

“转型和创新”是当今通信产业发展的两个关键词。降低流量成本、提升管道价值、加速网络创新是网络发展的目标之一。在此背景下，SDN 技术应运而生，一方面它使网络更加智能、开放，另一方面也为整个网络安全性和可靠性带来了挑战。本书作者全面客观地介绍了SDN 架构，深入浅出地介绍了Openflow 等核心技术，还对相关的技术，如PCE、I2RS 等进行了介绍，相信将使读者能够更好地了解和应用SDN。

——段晓东
中国移动通信研究院网络技术研究所所长

SDN是目前一种非常热门的技术，无论是产业界还是学术界都给予了充分关注，尽管SDN 脱胎于Stanford 大学等提出的OpenFlow， 但实际上SDN 目前的发展已经远远超越了OpenFlow 当初的概念，以Google 为代表的互联网行业最先试水，Verizon 等电信运营商不甘落后，企业网领域也跃跃欲试。本书的两位作者ThomasD. Nadeau 和Ken Gray 是Juniper 公司资深工程师，书中从IP 数据平面及控制平面的发展讲到了OpenFlow 的起源，总结了开放网络的相关协议和若干关键技术，以及带宽调度、大数据、网络功能虚拟化以及流量监控等应用案例，是一本全面和实 用的参考读物。本书的第一位译者毕军教授是我国较早从事SDN 研究的学者之一，相信翻译版将能够在提升我国SDN 的教学、研究和应用中发挥重要作用。

——金耀辉
上海交通大学网络信息中心教授、副主任

计算机网络的工程性更强于它的理论的逻辑性，SDN 也是这样，本书的作者有着很强的网络工程实现背景，除了介绍SDN 的概念、框架、接口、工作原理，还从工程的视角解释了为什么这样实现或者说这样实现的背景是什么，从而让读者能够较深入地了解未来的计算机网络体系结构。

——沈富可
上海华东师范大学信息办主任、教授、博士生导师
上海教育宽带网设计专项组组长

SDN技术带来的变革刚刚开始，云计算和数据中心将迎来新的春天，互联网传奇在基础网络中延续。本书系统性地对SDN 技术，尤其是SDN应用案例做了深入的解读，对业内人士来说，是不可多得的一次学习机会。

——刘东
下一代互联网关键技术和评测工程研究中心主
全球SDN 测试认证中心（ONF 授权OpenFlow 认证实验室）主席
天地互连董事长

终于见到了业界最权威SDN 专著的中文版，这对我国的许多读者不蒂是个福音。本书从SDN 相关概念着手，系统地阐述了OpenFlow 技术实现网络设备控制面与数据面分离的原理，提出了控制层面的抽象和网络可编程等的思维方法，进而完成了一种颠覆传统的新型网络架构。本书的译者和审校者均是网络技术研究、规划和设计的资深人士，在他们的努力下将深奥晦涩的专业术语、原理和案例变成了浅显易懂的小说，使各类读者能在愉悦的阅读中从本书汲取所需的养分。

——章民融
教授级高级工程师
上海市计算技术研究所所长助理、副总工程师

SDN是数通行业多年来难得一见的“大潮”，吸引了学术界人士、运营商、客户、新老厂家等纷纷加入“淘金浪潮”。全球领先的IT 技术书籍出版商O’Reily 携手本书作者，硅谷一线的SDN 专家，为读者拨开迷雾，全面阐述了SDN 的前世今生、发展前景。本书实为迄今为止该领域最为权威而且全面的SDN 专著。

——江朝晖
思科全球副总裁，大中华区CTO

如果说SDN 是一个巨大的变革，也许有些夸大，但它应该是近年来网络发展的一个重要驱动：从“高速公路说”到“以应用为中心”，也确实为以前只有少数网络人独享的“网络快乐”打开了一扇更透亮的窗，让网络专家及更多非网络专业人士一起来思考“那水面下到底是什么暗流在涌动”。不同厂家的反应，业界的不同观点——是一场新的洗牌，还是传统的弱肉强食的再现？至少从开启这本书开始，让我们一起思考……

——苏哲
思科大中华区副总裁、企业部技术总监、CTO

刚在美国硅谷落幕的ONF2014峰会上，AT&T全球高级执行副总裁John Donovan为与会者讲解了AT&T全面启动SDN的计划。有人问AT&T为什么要大动干戈采用SDN理念来驱动公司的转型和创新？ Donavan是这样回答的：“势不可挡”！AT&T都已全面启动，从事技术工作的同仁准备好了吗？本书作者Nadeau和Gray都有资深的AT&T 网络经验，由此，SDN的诠释也就更精彩！

——周明
思科大中华区副总裁、转型事业部技术总监、CTO

SDN是什么，为什么需要SDN，SDN又带来了什么，相信业界被这些问题困扰的人不在少数。Nadeau 和Gray凭借多年厂商和运营商的丰富工作经验，对SDN 做了全面而又精彩的分析，有广度又不乏深度，结合实际用例，观点独到。如果你希望深入了解现代网络及其演化，那么本书不容错过。

——鲁子奕
思科大中华区副总裁、全球研发总监

近两年来，SDN这个名词在整个网络行业成为最热门的话题，几乎所有相关厂商和用户，言必谈SDN。但是如果仔细了解，会发现大家虽然都使用SDN 这个名词，但是实际描述的内容却千差万别，甚至针锋相对。众多的新老标准被包装在一起，构成了一个又一个不同的SDN 定义和理念。不同的方案，各自有其独到的优点和适用的场景，但是目前依然处在诸侯割据、没有一个强有力的方案能一统天下的格局。本书结合了作者大量的实际工作和行业经验，给大家非常全面地介绍了主要的SDN理念和实践。相信读者可以结合自己的需求和经验，从中得到启发，形成自己的SDN观点。

——王卫
瞻博大中国区技术总监、CTO

随着云计算的烈火从互联网烧到传统的企业数据中心，仅仅依靠服务器虚拟化已经不能应对传统数据中心的挑战。为此，软件定义数据中心应运而生。随着软件定义数据中心的蓬勃发展，软件定义网络和软件定义存储也火热起来。虽然软件定义网络还是处于早期阶段，仍然存在颇多争议，但通过纯软件方式来改造传统网络已经成为不二之选。如何基于现有的IP 网络，无需改造现有的网络硬件，通过虚拟化软件来打造更具弹性、可靠性、安全性的网络成为软件定义数据中心的核心诉求。本书阐述的SDN 虽然要经过硬件的改造，但是仍然不失为了解行业趋势的一本不错的参考书，毕竟网络云化不是一夜间实现的，我们需要有耐心等待整个生态链的完善和成熟。

——张振伦
VMware 大中华区技术总监

网络流量爆炸性的增长，大数据应用的兴起，我们每天都感到的当前网络的不给力。SDN分离了网络的控制面与数据面，根据应用流量需要灵活调整业务处理能力，是企业网和运营商网络架构的发展趋势。本书介绍了SDN 的最新进展如编程性、虚拟化，并给出了应用实例，帮助读者攻略最新网络技术。

——杨学贤
博通（中国）现场应用工程技术总监

从网络架构上看，互联网的无连接特性最大程度地解决了网络的扩展性问题。对于网络中存在的QoS 和安全等问题，网络的设计者一直以来通过采用各种修修补补的方式来满足用户。然而，伴随着数据中心虚拟化所产生的动态网络需求，传统的方法遭遇了瓶颈。工程师开始尝试用新的技术来改造网络，SDN 就是其中最引人注目的技术之一。正如本书作者所说，SDN 不仅是新的技术，而且是思考和解决今天各种网络所面临的问题的方式，它的目标是打破现有的网络架构限制，发展出真正意义上可控制、可编程的开放网络系统。本书既有对网络技术演进的系统宏观思考，也在微观上对SDN 技术的复杂性与多样性进行了详细描述。对于广大的网络工作者来说，有很好的参考价值。

——陈端
上海贝尔有限公司战略部高级经理

网络界每隔十年八载就会有具有格局性影响的新技术出现，二十多年前是IP 与OSI之争，十多年前是ATM，最近几年的热门技术毫无争议就是SDN。但若论对行业格局影响之深与范围之广，还是以目前的SDN为最。

现在围绕网络架构的讨论必然涉及SDN，谈ICT 总体架构就一定涉及软件定义（Software Defined），可见其影响范围之广。但正由于涉及范围广，相关技术发展快，各家的关注点差异大，以至解决问题的思路非常不一样，甚至截然相反。除非是对SDN 发展一直有密切跟踪的行业相关人士，一般初涉者想搞清楚SDN 相关技术的来龙去脉及其之间的关系，并不容易。

最近看了英文原版，发现书里除了比较系统地介绍SDN 相关技术，让读者对SDN的整体概念上有概括性的认识，更为难得的是介绍各种技术时不是简单地从相关技术标准文档里搬字过来，而是按作者自己的经验与思路做了比较深入的探讨与分析，这样读者参照相关文档读来应该更容易明白。最特别的是对SDN 的几种应用场景的介绍，可以让读者比较清楚地了解SDN 的各种用途及其可能的发展方向。当然，作者对SDN 发展方向的观点我们未必完全同意，但这只不过是各人对技术发展不一样的判读而已，这种争论搞技术的从来就有，不足为怪，关键是书里对相关技术的介绍还是非常清晰易懂的。

总之，这是本难得的好书。

——梁永健

从封闭电路交换到统一的IP 化再到开放的IT 化，社会化大分工的潮流不可阻挡，SDN就是技术和社会发展体现在网络界的必然产物。然而SDN 这个新概念也让人难以捉摸，本书作者以扎实的技术功底，深入浅出地给读者讲了一个SDN 的美妙故事。故事读完之后，读者就能够茅塞顿开，从云里雾里走入到现实美景中，很清楚地了解为什么需要SDN、SDN 能解决哪些问题、SDN 是怎么解决这些问题的。无论对于准备致力于SDN 深入研究的专家，还是只想宏观了解SDN 状况的一般读者，这本书都将提供一个容易理解但又很有高度的起点。

——范成法
中兴通讯承载网总工

SDN是网络界的一次重大变革，它不仅能引发网络界的重大变革，而且会引发SDx的变异。相信随着时间的推移，SDN 必将应用于各行各业，不仅仅是运营商、教育行业。作为SDN 领域的第一本专著，相信本书会给中国的从业者带来很好的启发。

——韩军
1号店CTO

SDN技术的发展将带来网络产业的新格局，传统网络设备厂商面临洗牌。然而SDN应用如何落地仍为厂商和客户将面对的巨大挑战。作者利用自身丰富的行业经验，从网络理论和基础知识入手，系统全面地介绍了网络通信的基本原理，以及SDN 发展的缘由和趋势。相信读者能从本书中了解到SDN 的基础应用场景，并引发思考；相信只有越来越多的应用开发人员、网络架构人员的不断关注和争论才能促进SDN技术的成熟和大发展！

——叶婧
上海证券交易所执行经理

当我们的数据中心被数十万计的奔跑着的机器所占据的时候，人们开始不甘心被固定的编程、单一的程式和繁杂的运营所束缚，于是希望尝试赋予这些内心冷冰冰的机器以生命，让人类的智慧与学习型思维更便捷地调度和管理基础设施，随即这成为了一门学科。

SDN为我们在数据中心基础设施领域实现这个想法打开了一扇门，让我们有机会将脑海中描绘的种种蓝图付诸实施，而实践证明，东西方在这个领域上的开始点和前进路径又是惊人地相似。本书从基础技术出发，着重讲解了在数据中心网络及系统层面，落地SDN 技术所需要了解的种种基础知识，可实践性较强，是读者为实现梦想蓝图而扬帆起航的必备读物。

——张诚
百度公司系统部技术总监

SDN的出现对网络行业产生了深远影响。各个领域的人，包括腾讯的人都参与进来。O’Reilly 出版社及时出版了其SDN 专著，从SDN 领域的方方面面介绍了相关信息。无论对于SDN 的参与者，还是旁观者，都是一本很好的参考书。

——丘子隽
腾讯公司网络架构设计师

译者序

作为一名高校教师，科研和教学任务这么繁重，为什么要花很多时间来亲自翻译这本书呢？简言之，有四方面的原因。第一是SDN技术很重要；第二是我非常愿意为SDN 领域做此贡献；第三是我认为这是一本非常好的SDN著作；第四是SDN技术众说纷纭，如果翻译不专业，容易误导读者，我作为一名SDN 研究者，愿尽绵薄之力。

本书两位原作者Thomas D. Nadeau 和Ken Gray 都是SDN 界的专家。2011 年11 月在台北举行的国际互联网标准组织IETF 第82 次大会的SDNP 工作组BoF 会议上，Thomas D. Nadeau 作为SDNP Framework 草案和Problem Statement 草案的作者发言，让我印象深刻。此后两位专家在SDN 领域做了诸多贡献，并在约半年前写成此书。书中除了对SDN 技术有较全面的综述外，还提出了很多关于SDN 的独特视点，相信能对读者有所启发。

两位SDN 业界资深人士David Meyer 和David Ward 为原著所写的推荐序值得一读。正如David Ward 先生所说：“这样的变革往往每八至十年就会出现一次，对人们如何构建、使用和推广技术都能产生持久的影响。技术变革还迫使人们以新的方式来重新寻求商业机会。”难得的是，David Ward 又为本书中文版送来了一篇概述了SDN 最新发展动向，并对SDN 的未来给予展望的推荐序。

本书中文版邀请了工信部电信研究院科技委主任、原总工程师、中国通信标准化协会IP与多媒体标准技术工作委员会主席蒋林涛作序；邀请了国内的知名专家学者为本书撰写了推荐语，包括中国联通科技委主任刘韵洁院士、中国教育和科研计算机网网络中心副主任李星教授等。这些序言和推荐语的观点会使读者深受启发。在此对各位专家表示诚挚的感谢！

本书前言可以结合第1章一起阅读，这里给出了SDN的发展背景和意义，相信读者读完一定会感到耐人寻味。我最初试译这里的时候感觉作者的话语十分晦涩，译完全书后，却对作者有了很深的共鸣。目前业界有一些人对SDN 存在两类片面态度。一类是片面注重SDN的炒作，造成人们对SDN产生了“传说中的独角兽”这种看上去辉煌、实际上虚无缥缈的感觉。另一类是片面认为SDN就是一种炒作，而忽视了SDN 实际上有很深刻的技术内涵和技术基础（本书就是介绍这些技术的）。因此，SDN就如本书封面上的鸭子一样，其实质动作因为发生在水下而没有被人们所看到，实际上却有强劲的脚蹼在水面下推动它不断前进。事实确实如此，难道SDN 不是正在稳步前行吗？

对于关注SDN技术研究的读者，本书涉及SDN 体系结构的是第2章、第5章、第9章和第13 章。阅读本书第2章有助于读者思考为什么要采用集中式的控制平面，了解目前控制平面的各项技术，值得关注的是“逻辑上集中式”这种结构。第5章在本书处于重要地位，有助于读者了解各种传统的和现代的网络可编程技术。值得注意的是作者提出的应用程序与网络的鸿沟问题，以及需要什么样的编程接口。虽然在这方面可能还没有理想的答案，但作者讲述的角度相信能让读者耳目一新。第9 章在本书中处于核心地位，结合作者的工作介绍了SDN 的理想框架，特别是OpenDaylight项目的工作。SDN框架不仅是SDN 控制器的基础，也与SDN 的整个生态环境相关。作者在这里从用户角度特别强调了标准化的北向API 的重要性。第13 章涉及了作者对一些前沿问题甚至经济学方面的思考，值得关注的是几种SDN 的定义。相信上述章节可以加深读者对SDN 的理解。

对于关注SDN技术开发的读者，本书涉及SDN关键组件的是第3章、第4章和第8章。第3章介绍了SDN中一种最具革命性的数据平面抽象技术OpenFlow及其进展，特别是探讨了OpenFlow与传统网络混合运行的方法。第4章有助于读者了解目前主流的控制器，及其与所谓的“理想化的SDN控制器框架”（实际上就是OpenDaylight项目的框架）的对比。值得注意的是OpenFlow 并非SDN 唯一的南向协议。第8章主要介绍获取SDN 网络拓扑（这是网络视图中最重要的部分）的各类技术，值得关注的是获取多个层次的拓扑视图这一观点。相信上述章节能成为SDN设计和开发中手册式的工具。

对于关注SDN 技术应用的读者，本书涉及SDN应用的是第6章、第7章、第10章、第11 章和第12 章。第6章所介绍的数据中心，是SDN 技术应用比较典型的环境。第7 章讨论的网络功能虚拟化NFV和服务链则是电信运营商非常关注的SDN应用场景。第10~12章给出了SDN在带宽、数据中心和安全等三方面的具体应用案例，其中一些是作者的实践。相信上述章节有助于启发您结合自己的需求开拓新的应用。

由于本书涉及的技术内容较为全面，限于篇幅不可能对每种技术都详细介绍，但每章均有几项甚至几十个脚注，其中提供了不少延伸阅读的参考文献或软件系统的网站。对于高阶的读者，如果感到还不解渴，建议进一步阅读脚注中提到的那些参考资料。

本书翻译工作的情况如下：毕军负责翻译了原作者和原推荐序作者为中文版写的两篇推荐序、两篇原著推荐序、第2章、第3章、第4章、第5章、第8章、第9章、第13章（约12万余字），参与了前言的一部分翻译。单业负责翻译了第6章和第7章（约4万余字）。张绍宇负责翻译了前言和第1章、第10~12章和封底（约4万余字）。姚广翻译了第4 章的文字初稿，由毕军最后完成该章文字并翻译了该章所有插图。另外，王参与了第2章少部分初稿的翻译。

本书审校工作的情况如下：刘军参与了全书各章的审校。周超参与审校了各篇推荐序、前言、第1~4章，并对各章进行了通读。毕军参与审校了单业和张绍宇所翻译的各章。

人民邮电出版社图灵公司对本书的出版予以高度重视，李松峰主任带领李瑛、李静、毛倩倩等编辑日夜工作，提高了本译著的质量。特别是李松峰主任亲自参与翻译过程中多项讨论，提出了很多宝贵建议。本书出版付印过程中参与服务的还有多位台前幕后的工作人员。对此予以特别感谢！

本书翻译过程中面临的一个困难是SDN 是很新的领域，加之读者的技术程度不同，有很多专业名词是否翻译，如何进行中文翻译等很值得研究。由毕军、刘军、周超和李松峰进行了十余次讨论确定，在编辑协助下整理了本书术语中英文对照表，为读者阅读时快速查找提供便利。

关于书中一些较为专业的插图（例如某些软件的体系结构）是否翻译，我们也进行了深入讨论。对于高阶的读者，可能更愿意看到原图，这样可以最大限度保持原意。但考虑到目前市场上很多译著对插图不翻译的效果并不好，而读者的技术程度又有很大差异，最后决定统一进行插图翻译。由于一些软件模块和术语并没有翻译标准，其中文词汇不一定能与原英文单词一一对应，因此高阶的读者如觉得需要进一步确认其英文原意，可参考该软件的网站等参考资料。

本书英文版出版不久，考虑到SDN领域这么受业界关注，中文版需早日与读者见面，因此留给译者的时间有限，相信不少译者2014年春节和寒假时间，都献给了此书的翻译事业。虽然译者已经竭尽全力尽量地以“信、达、雅”为标准来还原作者的本意，也合作进行了多轮的审校和通读，但仍难免有疏漏之处，如读者发现任何不理想之处，望能不吝赐教，我们将在再版时予以纠正。

有人问，SDN是否会成为另一个ATM，“其兴也勃焉、其亡也乎焉”？我个人的学术观点认为，SDN 分为广义SDN和狭义SDN。广义SDN 代表一种哲学和方向，就是对整体网络的可编程性（不仅是对单个设备编程），狭义SDN 是目前各种实例化的SDN体系结构或其组件技术。在SDN 界没有“上帝”，不应抱残守缺。只要我们吸取经验教训，保持开放的心态来深入研究、改进和实践，就可以实现SDN 所描绘的美好蓝图。我想再一次引用David Ward 先生在推荐序中所说的话：“IT 行业正在经历一场巨大的转变，将使用户对其应用进行构建、测试、部署和以货币化的方式进行彻底革命。这是网络业乃至整体IT 业的新时代，这是改变游戏规则的时代。”因此，不论您是网络领域的研究者、工程师、学生，还是从事信息技术相关领域工作的人士，相信阅读本书都会带给您极大的收获，并能引发您对SDN 的深入思考。

毕军
2014年3月于清华园

2014：超越炒作，进入部署SDN的时代（David Ward中文版序）

本书英文版第一版在2013 年出版之际，我们看到了很多新的SDN 产品、体系结构、营销活动和各种会议，一些新的标准和开源组织也进入了这个领域。当时的SDN 刚刚从炒作周期的高点回归下来。转眼到了2014 年，这一年我们会看到实实在在的产品被采用，包括多个行业的开发和部署。真正重要的是，我们看到了开发者、网络工程师、学术机构、标准组织、合作伙伴的协作达到了高潮，而众多厂商行动的速度也是进入21 世纪以来在网络和基础设施行业前所未见的。人们可以感慨地说，这就是软件（SDN 中的S）的速度啊！ 2014 年过后再进入2015 年，这一切又将有很大改观，因为随着进入炒作周期的“后SDN ”阶段，人们的关注点将从产品和体系结构迁移到完整的解决方案和部署上。我们已经在多个会议、编程马拉松，以及随后的学术论文和白皮书中，看到了很多有关部署成功或失败的案例。

SDN 是网络体系结构的一个重要支柱，NFV（Network Function Virtualization，网络功能虚拟化）也一样。随着更加开放、更便于互操作的基础设施和解决方案快速得到采用，我们还将看到多个平台和社区基于这些体系结构涌现。在互联网的这一次转型中，SDN 很明显不是一个独立的技术。SDN、NFV 和云服务编排，现在都是捆绑在一起作为服务和解决方案交付的。部署路由和信令协议、作为一种可行的技术来实现自动化，以及运行长期部署的控制平面软件等SDN 应用已经有了很大的需求。虽然用SDN 的说法，这是“混合”的网络，但在现实中这就是常态。当前人们正在讨论的SDN 和编程接口，在传统网络的所有层正逐步得到规范化，大量工作集中在传输、线路、服务开通领域以及路由和MPLS 领域。流感知技术与民用和商用服务相结合，催生了许多令人激动的成果！社区和标准组织已经加速转变，正致力于资源管理和建模、故障和性能分析乃至综合分析，以及针对广域网和接入网的经验担保及和谐安排。在这些基础之上，产业界下一步的重点显然是要从试验向实际部署产品迈进。

有所改变的是，数据中心并非唯一的谈论焦点。不是一切都将走向大型数据中心。世界将是“多云”的，这些云会因网络拓扑形状和距离、传输比特的开销、法律法规和新的数据分发规则，以及国家和行业的不同而不同，因为隐私和安全是这个世界的中心。此外，企业IT 部门对使用编程接口和控制器都已经习以为常了。利用编程接口的效率高、实用、省时间，以及多环境下的一键式服务部署和SLA 保证应用，都是企业所看重的。大学校园、分支机构、中小型企业和咨询机构都在利用SDN 的优势。这一年的变化太大了！

有一个主题没有变，那就是开放的（标准、源代码和生态系统）、可互操作的组件和体系结构，将为服务和内容提供商及企业催生出新的市场。随后，我们看到以前需要几周来构建和部署的虚拟服务，由于新产品进入网络中的不同位置，现在只要几分钟就可以完成，这又会创建出新的市场。我真正期待的是技术和业务的组合，以前他们是被分割的，现在走到一起创建新的市场。例如移动网络里的视频服务，购物推车式的按需点击部署的安全功能，以及实时协作技术，无论什么内容，什么设备，如何访问和在什么地方。新的接口和门户将这些服务与最终用户连接起来，网络产业界正在部署的SDN 和NFV 会让这一切成为现实，而且更简单更自动化。

但是，我们还要面对新的挑战：应用程序和内容开发人员，以及最终用户，都不希望把网络当成自己必须了解的东西。对于一名网络工程师，这意味着最终有一个应用程序或工作负载给网络发出信令，告诉网络用户期望通过自己的应用和服务获得什么“体验”，然后网络自己通过编程就能满足用户的需求。于是，不再是网络试图猜测和反应，不再是需要长期的服务开通配置周期。你觉得这很疯狂吗？这是SDN 运动2015 年要达到的新目标，目前标准组织和整个开源社区正在为此展开广泛的讨论。

许多这些新服务都要依赖OpenStack和OpenDaylight项目，它们是这个生态系统中的两个大型社区。2013年和2014年，它们以SDN 沙盘试验场的形象登场，与传统标准制定组织分庭抗礼。开源社区加大发展步伐，使得从概念验证到开发和产品的速度比以前更快。“让可运行的代码来证明”成为新的口头禅（这也是20世纪70年代、80年代和90年代IP开发者的口头禅）。开源显然已经成为一种制定标准的新方式。更多的个人、企业、服务提供商、合作伙伴、供应商和用户参与进来不仅可以集思广益，而且通过利用这些开源解决方案，还可以让这个生态系统和解决方案更加开放。参与者越多，这个生态系统及其产生的解决方案就越开放。结果就是更快、更稳定的解决方案会由多个社区开发出来，这一切都建立在SDN、NFV 和云服务编排的基础上。当然，今年乃至未来，这个沙箱的运转会加速，新的论坛、行业联盟将会出现。

速度之快，可能会像我们有目共睹的2012 年和2013 年SDN 新协议的发展一样。2014 年，SDN 和NFV 将超越炒作阶段，进入实际部署阶段，并扩散到新的网络位置和服务。新的生态系统正在推动更多的服务聚合（mash-up），催生创业公司和新的个性化的软件平台和云环境。新SDN 和NFV 云平台必须是可编程的、健壮的、开放的、可互操作的、虚拟和物理共存的，能够可靠地将接入网与云组合起来。这是我们所有人都需要的网络产业的发展方向。

David Ward
2014年3月26日

英文原文

Intro to Chinese Edition:

2014: Move Beyond the Hype: It’s Time to Deploy SDN

We saw many new Software-Defined Networking products, architectures, marketing campaigns and events as well as new standards and Open Source organizations enter the industry in 2013 when the first edition of this book was published. SDN was just breaking through the hype cycle and thankfully now in 2014 we are seeing real products with adoption inclusive of development and deployment across multiple industries. It was truly great to see the culmination of all the work of developers, network engineers, academic institutions, standards bodies, partners, and multiple vendors move at a speed not seen in the networking and infrastructure industry since the early 2000s – one could say that it was the speed of Software. Moving through 2014 and into 2015 will be much different as we’ll be “post-SDN” hype cycle and moving from products and architectures to full solution deployments. We’ve already seen many deployment success/failure presentations at several conferences, hackathons and subsequent academic and whitepapers.

Software-Defined Networking is a critical pillar of the networking architecture as is Network Function Virtualization (NfV) and as we move rapidly forward with more open, interoperable infrastructure and solutions we’ll see multiple platforms and communities emerge based on these architectures. As the Internet transitions, it’s clear that SDN is not a standalone technology. SDN, NfV and cloud orchestration are now linked together in service and solution delivery. The application of SDN to deployed routing and signaling protocols and as a viable technology to automate and operate long deployed control plane software is now really gaining traction. In SDN parlance it would be a “hybrid” network but in reality it appears the norm. SDN and programmatic interfaces are now being discussed and specified at all traditional layers of network and lots and lots of work is going on in transport, circuit, service provisioning as well as routing and MPLS. The combination of flow awareness and deployed residential and business services is creating a lot of excitement! The change in communities and standards bodies has shifted and we’ll be working on resource management and modeling, fault and performance analytics and analytics overall, experience guarantees and orchestrated ties to the WAN and access. It’s clearly the next step to get the industry from pilots to deployed products.

What has changed is that the data center isn’t the sole focus or conversation; not everything will be moving towards the mega-Data Center. It will be a world of many clouds based upon network topologic shape, proximity, cost of transporting bits, regulation and compliance as well as new data distribution laws on a per-country or industry basis as privacy and security will take center stage. Also the use of programmatic interfaces and controllers in the enterprise IT organization is now commonplace. The Enterprise is taking advantage of the operational efficiencies of programmatic interfaces and useful, time saving, SLA guaranteeing apps and one-touch service deployments that work across multiple environments. Campus, branch, small and medium size businesses (SMB) and smart advisors all utilizing the advantages of SDN. What a change in one year!

One consistent theme is that it will be open (open standard, open source and open ecosystem) and interoperable components and architectures that will drive these new markets for service and content providers and enterprise organizations. We subsequently see new virtualized services that formerly took weeks to build and deploy moving to speeds of minutes with new offerings entering into different positions in the network and creating new markets. I am truly looking forward to the combination of technologies and businesses that were formerly segmented coming together to create these new markets. For example Video over Mobile networks, on-demand shopping-cart-based click-todeploy security offers, the rise of real-time collaboration technologies and any content, any device, any access – anywhere and everywhere. New interfaces and portals connect these services to the end-users; SDN and NFV enable this to happen with simpler and automated capabilities the networking industry is now deploying.

But let’s face it: the app and content developers and end users don’t want to see the network as something they have to understand. As a network engineer it means we finally have an app or workload signal to the network what “experience” the user is supposed to get via their application or service and the network can program itself to deliver it. No longer is the network trying to guess and react or requiring long provisioning cycles.You think this is crazy? This is the new boundary of the SDN movement for 2015 and currently being discussed broadly in both standards organizations and across Open Source communities.

Many of these new services take advantage OpenStack and OpenDaylight, which are two of the big Open Source communities in this ecosystem. In 2013 and 2014 they emerged as the sandboxes to work in versus traditional Standards Development Organizations. Open Source has increased the pace of development enabling Proof-of-Concepts to move into dev and production faster than before. The new mantra (which was the original mantra of internet protocol developers in the 1970s, 80s and 90s) being“ Prove it with running code.” Open Source has clearly emerged as a new way to standardize. The more individuals,enterprises, service providers, partners, vendors and users not only contributing to but utilizing these Open Source solutions the more open the ecosystems and solutions become.The result is faster and more robust solutions taking shape with multiple communities of developers building towards this - all on the foundation of SDN, NfV and Cloud orchestration. Of course through this year and into the future the sandboxes will shift and new forums, consortiums will emerge; probably as fast we all saw new SDN protocols emerge in 2012 and 2013.

2014 will be the year that SDN and NfV move beyond the hype and into deployments and into new network positions and services. The new ecosystems are driving even more service mash-ups and catalyzing start-ups and new and/or personalized software platforms and cloud environments. The new SDN and NfV Cloud platforms must be programmable,robust, open, interoperable, virtual and physical, linking access networks to clouds with guarantees – and this is what we all need to have happen to move the networking industry forward.

David Ward
March 26, 2014

作者中文版序

当本书译者和审校者邀请我们为中文版写个简短的序时，我们首先想到的是要仔细回顾一下本书英文版出版以来的短短六个月中，SDN 业界及相关技术领域发生的各种变化，以及取得的所有新进展。抱着这种想法，我们又看了一遍邀请邮件，发现他们只要求写“不到一页”！好吧，那就没事了，我们的序一定简明扼要。

本书英文版出版以来的短短六个月内，书中探讨的一些主题在现实中有了新的进展。

比如理想化的SDN 框架这类概念，已经由OpenDaylight® 项目给实例化了。越来越多的人开始抛弃专有控制器，因为他们已经意识到，专有控制器不过是另一种垄断形式而已。如今，人们已经转向公共、普适的SDN 框架或基础设施，这样有助于各自的创新。

开源的日益重要和兴起不仅体现在OpenDaylight 项目上，也体现在业内其他组织和人的努力上。OpenStack 和OVS 的快速发展及被人们所接受（部署）就是例证。

传统标准组织往往要花许多年才能让厂商的实现达成一致。开源项目则不同，它们由志愿者构成的用户社区共同维护，并基于可运行的代码创造出事实标准。这是两条完全不同的路线。认清这一点很重要，因为某些“伪标准”组织和论坛一开始也会打着“开源”的幌子，但运作方式仍然是封闭的。希望读者能够留心注意背后的区别。

我们俩现在都换了工作，我们希望自己服务的厂商能像OpenDaylight 项目一样，积极遵循真正开源合作的理念（开放管理、精英主导、各尽所能、求同存异）。Thomas D. Nadeau 现在博科公司领导一个大型团队，专注于构建基于OpenDaylight控制器的商业SDN/NFV 应用程序，同时也非常注重对开源项目的贡献。Ken Gray现在思科公司的工作也差不多。

本书第1 版涉及的其他主题同样有所进展，比如英特尔优化库（DPDK）已成为进一步扩大虚拟化网络服务与功能（及效果）的一种手段。这方面的进步不在控制平面，而在虚拟数据平面前所未有的性能提升上。某些虚拟数据平面在商用标准硬件上的性能，并不亚于在定制硬件上的性能。

同样，我们当初写作本书时刚刚进入共同探索第一年的NFV（网络功能虚拟化）也取得了进步。随着ETSI NFV 研究组两年任期行将届满（并即将颁布体系结构指南），我们看到一些传统的服务提供商宣布愿意采用NFV，也看到了众多厂商宣布即将推出相关产品。

我们没有料到本书英文版获得了如此巨大的成功，我们要感谢那些购买它的读者。同时，我们也为本书能被翻译成中文版，与中文读者见面而感到兴奋。在此感谢本书中文版的译者和审校者，翻译可不是一件简单的事。

想了解我们最新的想法，请访问我们的博客：http://www.sdnprogrammability.net，或关注我们的推特@tdnjunisco 和@graymatterken。

Thomas D. Nadeau
Ken Gray
2014年3月20日

英文原文

When Chao Zhou (who did the Chinese translation of our book) asked us to write a short Preface for this edition, the first thing I thought of was to delve into the details of all of the things in the SDN industry and technology space that have changed or rapidly evolved since we published this book just a short 6 months ago. Then I checked that thought when I read his email again that stated we could only have “less than a page” of space to do this in!Problem solved: we will keep this short and sweet!

In the short 6 months since this book came out, the industry has already moved forward with some of the topics we initiated in the original book.

Concepts like the Idealized SDN Framework were instantiated in the Hydrogen release of OpenDaylight®. There is now a growing shift away from proprietary controllers in the industry as providers realized they were just another means for vendor lock-in. We have movedtowards a common, ubiquitous framework or substrate on which we can focus our innovative efforts.

The growing importance and uptake of open source not just indicated by OpenDaylightrelated efforts, but also by others working in this space. Examples of this also include the rapid evolution and acceptance (deployment) of Open Stack and OVS.

It seems that open source development is on a trajectory to leapfrog traditional standards organizations that have by definition taken many years to produce implementation agreements among vendors. Open source creates an avenue by which a community of interested users can create what are in effect de facto standards with accompanying running code. This observation is important in that the term“ open source” is now being coopted in the creation of other “pseudo standards” organizations and forums that work in decidedly closed ways. We hope our readers will take care to notice the differences behind the labels.

We have both also moved on to work for vendors we feel actively support the ideals of a truly open source collaboration in SDN that the OpenDaylight Project represents (open governance, meritocracy through contribution and a diverse community). Tom is now leading a large team at Brocade that is focused on building commercial SDN/NFV applications based on the ODL controller, as well as a strong focus on contributing to the open source project. For Ken’s part, he is now working on similar SDN efforts at Cisco.

Other topics covered in the first edition that are making advances include the advancement of Intel’s optimization library (DPDK) that others have latched onto as a means of further expanding the role (and efficacy) of virtualized network services and functions. The advances here are not in the control plane, but in the seemingly ever-increasing performance gains of virtualized data planes. At this point, there are real functional examples of virtualized data planes running on COTS hardware that rival some custom hardware.

In the same vein, Network Function Virtualization (which was just entering it’s first year of concerted exploration when we wrote the book) is now moving forward. As the ETSI NFV Study Group nears the end of it’s two-year charter (and publishes it’s architecture guidelines), we see announcements from traditional Service Providers favoring adopting NFV and announcements of forthcoming products from numerous vendors.

Neither of us envisioned the wild success this book would have and we are both grateful to those who have purchased it already, and are also very excited to tap into an entirely different readership. We want to thank Chao (and other people’s name) for embarking on what was likely not an easy process of translating our original writing.

To keep track of our latest thoughts and musings, please visit at our blog at http://www.sdnprogrammability.net or follow us on Ttwitter @tdnjunisco or @graymatterken.

Tom and Ken
March 20, 2014

David Meyer序

虽然软件定义网络（SDN）的基本理念最近才进入公众的意识之中，但活跃于研究领域、运营商和厂商的人们立刻就看到了“类SDN”（SDN-like）技术在数据中心和运营商环境（以及更多的其他环境）中的适用性。SDN 除了在研究领域里激发了创新思维的爆发，同时也以一种可编程的方式来优化、货币化和扩展各种网络。

2011 年，开放网络基金会（Open Networking Foundation，ONF）成为第一个致力于SDN 的成长和成功的组织。其既定的任务是把源于学术界的OpenFlow 协议变为在商业上可行的建设网络和网络产品的基础。在两年内，ONF 的成员已发展到约100 家单位，大家对SDN 抱有不同的兴趣和期望。在此背景下，很多人都在探寻SDN 基础理念的更广泛含义，并在此过程中，把SDN 推广为不仅包括OpenFlow，而且也包括其他形式的网络可编程性。

在这个进程的早期，Tom Nadeau 和Ken Gray 很早就意识到，SDN 实际探讨的是广义的网络可编程性及其相关的接口、协议、数据模型和应用编程接口（API）。正是基于这种洞察力，他们在台北举行的IETF 第82 次会议上帮助组织一个SDN BoF1，以研讨更普遍化的SDN 模型。在那次会议上，Tom Nadeau 提出了一种软件定义网络的框架，设想把SDN 作为网络可编程性的广义机制。这项工作鼓励业界对SDN 采取更广义的看法，并最终导致了在IETF 成立了“路由系统接口”工作组（Interface to the Routing System Working Group）。

1.国际标准组织IETF 成立新工作组时召开的会议叫Birds of a Feather，即BoF。

从那时起，加上他们对互联网技术的许多其他贡献，Tom Nadeau 和Ken Gray 已经成为SDN 业界备受尊重的资深成员。他们积极参与核心的SDN 业界活动，并为SDN市场开发产品。Tom Nadeau 和Ken Gray 推动了许多关键的业界活动，包括ONF、IETF、ETSI，还有其他行业会议，如SDN 在2012 年和2013 年的峰会，以及开源组织如Open Daylight 项目。本书基于他们深厚的学识，不仅能帮助读者了解SDN 技术，而且能帮助读者了解SDN 技术是如何开发、标准化和成功部署的。

Tom Nadeau 和Ken Gray 绝对有资格帮助读者透彻理解网络可编程性技术，及其使用和部署的一般常识。而且，本书对SDN 基础的介绍十分出色而实用，它用了无数的掌故来解释SDN 发展背后的理念和背景。所以，如果读者对编写SDN 的应用、构建具备SDN 能力的网络感兴趣，或者只是想了解什么是SDN，那么本书就是为你而撰写的！

——David Meyer
博科公司（Brocade Communications）首席技术官和首席科学家

David Ward序

技术变革会影响开发人员和工程师建立和设计其业务架构，且影响十分巨大。这些变革并不适用于摩尔定律，而且它往往不仅影响IT 领域，而且也影响商业环境。这样的变革往往每八至十年就会出现一次，对人们如何构建、使用和推广技术都能产生持久的影响。技术变革还迫使人们以新的方式来重新寻求商业机会。

在1996 年，Gartner 公司提出了“面向服务的体系结构”（service-oriented architecture，SOA）。到2000年，该构架已占据了中心舞台，其核心目的是使网络连接的大量计算机易于合作，以服务而不是人工交互的方式来交流信息。这不需要程序或应用本身进行底层的更改。从本质上讲，它起到了与一台机器上单个操作系统相同的作用，却应用到了服务器组成的整个基础设施上，使更可用、更灵活又更可扩展的应用和服务得以构建、测试、部署和管理。它引入Web 服务作为事实上的方法，使功能构建模块可通过标准的、独立于平台和语言的IP 协议来访问，得以对IT 基础设施进行更快和更容易的开发、测试、部署和管理。

当看到软件定义网络时，人们也会有同感，网络是IT的基石，网络建立起新的体系结构，也就创造了新的商业机会。从本质上讲，网络让IT变得比以往任何时候都更加重要，并且成为新业务的助推器。网络如果以正确的方式来架构和运用，就能成为目前最大的业务推动者，即可以把网络、服务器和存储紧密联系在一起，使SOA的原则在网络层得到执行。SDN和网络API，可以更方便地实现对网络和服务的编程意图和状态接收，一改网络必须由魔法师们来建造和运行的传统观念。总之，当SOA原则应用于网络层，网络就变得更容易、更可编程、更灵活，企业也就能够根据业务变化的速度转换IT 技术，这些都以新的方式增加了商业的价值。

但究竟什么是软件定义网络？许多阵营都有不同的定义。简单来说，SDN是简化网络的一种方式或体系结构，而且还能使网络对其工作负载和服务的要求更具有反应性。IT基础设施必须紧随机应需而变，必须用全新的方式支持快速灵活的商业运作。从实用角度出发，SDN的定义可以是这样的：SDN在功能上使网络能被运营商以编程方式来访问，从而实现自动化管理和服务编排，跨多个路由器、交换机和服务器应用配置策略，以及对执行这些操作的应用程序与网络设备的操作系统进行解耦合。

SDN越来越成为各个行业的流行语，有必要回顾一下为什么SDN会出现。从历史上看，网络配置状态大致总是静态的、不变的，并且通常是不让碰的。通常是要在一台设备上手动和基于命令行（CLI）进行配置，网络管理基本靠 “屏幕抓取”或使用Expect脚本的方式来解决可管理性问题和核心的可扩展性问题（剪切和粘贴方式）。编程接口最高端基本就是XML 接口和执行Perl、TK/TCL 和Expect。然而，当要对付一个大系统的许多台路由器、交换机和服务器时（以及面向的服务要在多个域的不同用户、权限和策略中来路由通信流量时），控制和管理状态需要以一个操作来应用到全网。一个接一个地对网元的管理根本就不够灵活和敏捷，也无法支持动态或瞬时数据（配置和状态无法持久地保持在配置文件中）的概念。但当SOA原则开始向下改变南向接口，在网络层得到应用并获得了认可时，新的体系结构伴随着网络技术的进步，使软件定义网络得以出现，用户得以用新的方式来实现网络的力量。

是的，路由器、交换机、服务器、网关等的协议接口确实已有多年历史了。几十年来，互联网中对订阅用户、会话和应用程序等相关的动态数据进行编程确实存在并得到了广泛部署。这些协议的服务器（例如，Radius、Diameter、PCMM、COPS、3GPP）都可以被视为早期形式的SDN，难道它们不是吗？现在有点不同的是，SDN体系结构的一个主要功能是：能够在一个平台上编写应用程序，该平台把从不同来源或数据库获得的数据定制化为一个网络范围的操作。

SDN 也是这样一个体系结构，即集中式的管理下的分布式控制平面、管理平面和数据平面，其中由策略来决定的转发规则是集中式的，而实际的转发规则处理是分布在多个设备上的。在这个模型中，应用程序策略的计算（例如服务质量、访问控制列表和隧道建立）实时地发生在本地，策略的质量、安全和监控被集中地管理，然后推送到了交换/ 路由节点。这允许更大的灵活性、可控制和网络本身的可扩展性，并允许使用模板、变量、用户的多数据库和政策等等，来生成或编译出所需的配置和状态，并将其下载到路由器和交换机中。理解SDN的关键点是，SDN不会取代路由器或交换机上的控制平面，而是对其进行补充。怎么补充？ SDN同时提供整个网络的视图，而原来只能看到拓扑中一个位置（如路由器或交换机）的视图。动态路由和信令与集中式视图的结合将异常地强大。这可以对故障事件提供最快的保护，具有最大的弹性，可以用一个命令就把服务集成到网络中。两种技术双管齐下，的确是迈进了一大步，这是以前的工具箱中所没有的。

SDN有几个种，另外人们也经常提到一些组件。OpenFlow 是其中之一，它从体系结构上把网络设备上的数据平面与控制管理平面分离。这就可以用集中式的控制器来管理转发节点上的数据流。但是，OpenFlow 只是SDN 中的一个协议和一个元素，现在还有许多其他的协议，例如I2RS、PCE-P、BGP-LS、FORCES、OMI 和NetConf/Yang 等，所有的这些也都是开放标准。请记住最重要的是， SDN不是一种协议，它是一种适用于运行和编程的体系结构。

SDN能给我们带来什么呢？ SDN体系结构使网络和网络数据更靠近应用层，也让应用层更靠近网络层。正如SOA实践一样，不再需要人工或脚本语言来双向地分发数据和信息了，因为现在已经演化出API和工具，可以通过开放接口和互操作的方式来安全并可扩展地传递数据和信息。网络中的数据（统计数据、状态、订阅用户信息、服务状态、安全、对等体等）可被应用程序分析和使用，从而实现调控意图并把网络编程为新的配置。网络编程结果既可以持久不变，也可以瞬间改变。

可编程性（即通过API 和开放接口访问网络）是SDN的核心。同样重要的概念是把控制和管理平面挪到交换机/ 路由器之外的应用中，并通过SDN 协议来连接应用与网络设备。这些设备外的应用实际上就是软件开发者所说的“平台”，因为它有自己的一套API、逻辑，以及向网络提出要求、接收事件、处理SDN协议的能力。这里关键的是，程序员不需要知道SDN 协议，他们只要会根据控制器的API写程序就行。程序员不需要知道各种网络设备的不同配置语法或语义，因为他们使用控制 器的API编程，而控制器负责与各种设备沟通。不同厂商、时代和种类的设备（例如传输设备、交换机、无线基站、用户终端网关、对等路由器、核心路由器和服务器），都可以用集成到控制器底部的SDN协议来编程。程序员只使用控制器顶部的API来自动化、编排和操作网络。这并不是说控制器就一统天下了，也不是说控制器能满足网络所有的层次和功能，而是说现在的网络已经可以脱离设备被抽象和编程了。因此，当SDN 与OSS（运营支撑系统）或IT系统等IaaS（基础设施即服 务）层集成后，网络的自动化和编排速度，就能达到像用户登录和在服务器间分配任务一样快。

对新工具的使用习惯也与整个SDN运动相关，这通常由系统管理员来使用，现在也提供给网络运维人员了。Puppet、Chef、CFEngine 等工具以新的方式来自动化或编排网络，即现在可以通过创建插件利用网络的开放接口来使用网络数据。还可以使用控制器的API 方便快捷地在多语言网络中构建和应用策略，并集成到现有的工具如集成开发环境IDE（NetBeans、Eclipse 等）中。相比传统方式下使用的命令行界面CLI模型，这给网络工程师带来了更好的用户体验。

在深入探讨示例之前，我们首先要理解SDN 实际上解决了什么，以及为什么要向这个特定的体系结构转变。随着网络的发展和新服务的部署，以新的方式让用户可以更方便地提供新的服务并实时地编排网络资源，变得非常重要。实现了这一点，就可通过快速可靠的资源调度自动化，并让网络直接对应用程序的请求作出响应（而不是由人来干预），从而降低成本。这使得运营商能够使用编程的（且可扩展的）控制来创建和应用服务，这比手工的命令行界面更简单。此外，SDN 使基础设施、服务和应用得以优化：它扩展了新的网络数据和能力并应用于上述体系结构，创建出新的方式，不仅优化了现有的应用，而且可插入新的服务或产品，提供更好的用户体验或创建了可货币化的新产品或先进功能。

随着SDN 的发展，我们有必要看看一些实现的案例，才能理解为什么对各个行业（例如视频分发、用户服务和移动、有线和宽带、安全和运营商边缘）而言，接受SDN势在必行。在SDN充分释放其潜力的地方，人们要的不仅是对网络功能进行编程并扩展到整个基础设施，而且是为新的使用案例而把服务器、存储和网络紧密联为一体。在这种情况下，无论是物理的、虚拟的还是混合的系统，实际上都可以彼此相互作用，从而获得更大的基础设施灵活性。

基于网络状况与规则变化的流量策略和重新路由也是常见的应用，比如新的服务或数据插入到应用程序，能够清晰地对带宽划分优先级，为那些支付了溢价金额的用户提供更快的连接速度。当人们应用SDN 和独立于数据平面的集中式管理平面，就可迅速做出决定把数据流量重新路由到哪里，因为这是通过对软件接口（API）进行编程而实现的，而不是使用设备上的CLI 的方法。

一个先进的案例是混合云。在这种情况下，一个应用程序可以运行在私有云或数据中心，当需要降低计算容量峰值或成本时，又可以利用公有云1。历史上看，云爆发（cloud bursting）一般仅用于非关键任务的应用或服务的环境中，但随着网络与软件所采用的原则紧密结合，应用场景也发生了变化。现在，应用仍可以继续遵循IT组织的策略和规则。如果它依赖基于云用户端部署的，而不是在公共云环境中部署的各种数据或信息，应用还可以保留其依赖模型。它允许应用在不同的平台上运行，无论它建立在哪里。

1.这里指的技术就是云爆发。

当人们审视SDN时，还必须考虑网络功能虚拟化（Network Functions Virtualization， NFV），以及它所关联的更广泛的基础架构和虚拟化场景。从物理到虚拟的过渡正在业界引导许多变化。通过把硬件（物理的）关联到软件（虚拟的），包括网络、服务器和存储，就可以虚拟化网络服务，它们可以编排调度得与其他工作负载一样快。

再结合广域网的编程接口，可以绝对保证实现服务交付。SDN 与NFV 结合，是计算和网络的关键体系结构转变。这一转变的标志是基础设施的动态变化与客户需求密切契合，通过分析来协助预测性能要求，以及一整套管理和服务编排工具，使网络功能和应用以更快的速度和更低人工干预来放大、缩小和扩展。这个变化会深刻影响人们如何为应用构建云平台，并在最基本层面上必须提供工具和技术，让网络能与平台一样快速地响应不断变化的工作负荷需求。工作负荷需求中还可以包括满足其所需的网络需求。

重要的是，要注意并非所有的网络都是一样的，这就是为什么当从网络（无论是从物理设备还是虚拟设备）中抽象出控制时，了解底层基础设施是至关重要的。网络功能虚拟化仅仅是增加了虚拟的或云端的设备，以加强传统的基础设施。然而，必须考虑把云端和云用户端的产品结合起来，才能确保不仅是运行应用系统或服务的企业，而且是使用服务的用户（无论他们是企业内部用户还是外部的客户），都能有无缝的体验。

那么人们为什么关注SDN ？从技术方面来看， SDN 让人们有了更大的灵活性和敏捷性，为基础设施提供了各种选择。通过允许对数据进行集中式控制，并与网络及存储和服务器进行整合，人们在性能、速度、流量的优化和服务保障方面有了一致性的视图。使用可在多种语言和工具中使用的编程接口（API），运维人员和管理员可以迅速地响应内部和外部客户在业务方面的需求。现在，他们可以将策略应用到内部开发组织，让他们的网络数据更有效地在服务器群中运转起来，甚至有可能构建出具备网络智能的更快、更高性能的应用。让数据以一种安全的和可扩展的方式来提供，整个IT组织都能受益，而且因为开发和部署周期更快以及更容易提交新服务，业务也同样受益。SOA 给开发者的许诺，即只写一次然后到处都可以运行，现在可以通过底层网络在整个企业、接入网、广域网和数据中心（物理的和虚拟的）内分发信息的能力来完全实现。这使得应用打破了OSS与管理平台之间的界限，这个界限以前限制了应用在不同的环境中运行的能力。

IT 行业正在经历一场巨大的转变，将使用户对其应用进行构建、测试、部署和货币化的方式进行彻底革命。有了SDN，网络现在已更像一个应用程序（反之亦然，应用程序也更像网络了），这将孕育出更智能、更快速、性能更好的应用程序。它使网络以新的方式来实现自动化，为用户提供更大的灵活性和可扩展性，并为业务释放出成本节约和创收的潜力。这是网络业乃至整体IT 业的新时代，这是改变游戏规则的时代。请看本书吧，开卷有益，你不可不读。

——David Ward
思科系统公司首席技术官

前言

大多数O’Reilly 图书的读者会问的第一个问题，便是作者为什么选择那个封面动物？针对这本书，读者可能会问：“为什么选鸭子？”好吧，其实作者最先选的是装饰了彩虹丝带的闪闪发光的独角兽。

这么回答肯定会引得大家发笑（相信你也笑了几声）。独角兽的形象也反应了许多经验丰富的网络专业人士对SDN（Software Defined Networks，软件定义网络）的共同感觉。虽然作者认为这种感觉在某些方面是合理的，但这只独角兽的确有血有肉，而不仅仅是个传说。

那么言归正传，对于开头的问题，作者有个更好的答案：人们在水面上见不到鸭子的全部动作。1鸭子游动时大多数的动作都在水下完成，而这些动作是无法轻易观察到的。强健的脚掌在水面下滑动着，推动鸭子前进。这与软件定义网络在很多方面有着相似之处。

1.真正的答案是本书的其中一位作者十分喜欢鸭子，他在家庭农场里也饲养了一些番鸭。

SDN的表象可能导致观察者轻率地产生如下看法。首先，定义SDN 是什么或可能是什么，是很多机构为了抢救他们的商业计划或复兴他们的标准化组织而作出的疯狂尝试。其次，SDN 仅仅是一种品牌的重塑，为已有的产品附上它们所没有的“魔力”。很多厂商声称他们四五年前开发的产品是SDN 的源头，所以从那以后他们所做的也都是SDN。

顺着这种思路，重新给所有东西贴上SDN 标签的行为，以及近三四年来大量SDN 创业公司的宣传鼓噪，都进一步强化了人们的这种负面看法。如果观察者们因为抱有网络信仰与政治的成见而对SDN 不屑一顾，那么SDN 看上去就只是一个飘忽不定的想法。

看懂高德纳公司的技术成熟度曲线2，就可以理解新技术发展的远景，并且可以看到该曲线所预测的新技术发展所处的阶段。

2.http://www.gartner.com/technology/research/methodologies/hype-cycle.jsp

正是当前这场SDN 运动与上述成熟度曲线表现出的相同特征，促使我们为这头光环笼罩的独角兽极力游说，只为说明一点：我们看到了SDN 的与众不同之处。

两年多以来，作者参与了许多相关的客户会议、论坛和行业协会以及标准化组织的会议，讨论了各种SDN 相关的话题，还跟很多SDN 创业公司、支持者及早期应用者一起工作。这些经历使作者相信看似平静的水面下发生着一些值得关注的事情。那就是推动SDN 向设定目标前进的大量努力，而这个目标就是为网络和使用网络的应用提供最佳的运营效率和灵活性。

有确凿的证据表明，SDN 最终还是引起了一场讨论，这场讨论涉及网络的可编程性、控制模型、面向网络的应用接口现代化和上述事物事实上的开放性。

有鉴于此，虽然数据中心中虚拟化所引起的可管理网络终端浪潮是现在SDN 的主要推动力，但SDN 并没有被限制在诸如数据中心这种单一的网络领域。SDN 并没有被局限于单一的客户类型（如研究/ 教育），或者单一的应用（如数据中心服务编排），甚或单一的协议/ 架构（如OpenFlow）。SDN 也没有被单一的架构模型所限制（如集中式的控制器以及一组被操控的交换机的模型）。希望读者可以从本书中看出这一点。

在撰写这本书的第一版时，Thomas Nadeau 和Ken Gray（ 两位作者） 都在瞻博（Juniper）的平台系统部首席技术专家办公室工作，他们也曾经在其他厂商（如思科）和运营商（如BT、Bell Atlantic——现在的Verizon）任过职，因此有着跨行业的丰富经历。本书尽可能将SDN 领域相关的所有内容都包括在内，虽然不会是百科全书式的，但仍然会提供足够广泛的材料。在某些情况下，本书将会依赖作者写作时从为雇主（瞻博）工作的经历中得来的参考资料和示例，这仅仅是因为要么这些内容是一个大规模综述的一部分，要么相同主题下可以替换的例子尚无法获取并披露。希望读者能够理解书中任何的偏向都是无意的，而且这些偏向也不至于让读者感到迷惑。如果 可以，本书会在后续的修订版中对这些偏向之处予以改正和完善。考虑到SDN 还处于早期阶段，而且正经历着飞速发展，作者一致认为本书以后很可能会有多次更新。

最后，作者希望读者能够觉得本书内容的深度和广度恰到好处，有趣、丰富，且能产生共鸣。本书会给出作者自己的观点，不过本书首先会以尽可能公正的方式呈现事实并陈述其利弊。

作者衷心祝愿读者可以在本书中找到独角兽和仙尘，更希望大家能看到水面下滑动着的鸭掌。

阅读本书的条件

对于当今的网络世界来说，SDN 是一种新的方案，但它仍然是网络技术。既然准备继续阅读本书，那本书就假设读者对网络知识有一定程度的了解。读者不需要是一名工程师，但是知道网络的基本工作（以及为什么不工作的）原理，会帮助读者更好地理解本书的内容。

读者应该熟悉以下术语/ 概念。

- OSI 模型
OSI（Open System Interconnection，开放式系统互联）通信参考模型定义了7 个不同的网络层次：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。这个模型使得网络工程师和网络供应商能够方便地讨论，并将技术应用于特定的OSI 层。这种层次划分使得工程师可以将应用程序之间的通信这一整体问题分解成单独并且更加便于管理的部分。每一层都有特定的属性，每一层与它相邻的层都以一种非常明确的方式交互。这7 层之上的知识并不是必需的，但是如果读者知道互通性并不一定总是与电子和光子有关，将会有所帮助。

- 交换机
这种设备在OSI 模型的第2 层工作，并且采用逻辑上的本地寻址来传输网络帧。这类设备包括了以太网和它所有的变种，VLAN、汇聚和冗余设备。

- 路由器
这些设备工作在OSI 模型的第3 层，彼此将多个IP 子网连接起来。路由器以逐跳的方式来传输网络包。

- 以太网
这些广播域将多个主机连接到一个共用基础设施上。主机之间的通信采用第2 层的MAC（Media Access Control，媒体访问控制）地址。

- IP 地址和子网
主机之间使用32 位的地址通过IP 协议进行通信。人们经常采用点分隔的十进制数值格式来表示这些地址。这种地址标记包括了网络地址和主机地址两个部分，一般看上去是这样的：192.168.1.1/24 。

- TCP 和UDP
这些第4 层的协议定义了主机之间通信的方法。TCP（Transmission ControlProtocol， 传输控制协议） 提供了面向连接的通信， 而UDP（User DatagramProtocol，用户数据报协议）则使用无连接的模式通信。使用TCP 还有流量控制、窗口/ 缓存和显式确认等好处。

- ICMP
作为（某些平台上）ping 和traceroute 程序所使用的核心协议，网络工程师使用它对网络进行诊断和操作。另外ICMP（Internet Control Messages Protocol，网际控制报文协议）还被用于发于IP 网的主机间的出错信号和其他消息。

- 数据中心
用于放置大量计算机系统和相关组件（例如电信和存储系统）的场所。数据中心通常要有冗余或备用电源、冗余的数据通信连接、环境控制（如空调和消防）设施和安全设备。大型数据中心作为一种工业级基础设施，消耗的电力可以相当于一个小城镇。

- MPLS
MPLS（Multiprotocol Label Switching，多协议标签交换）是一种在高性能网络中使用的机制，它可以根据短路径标签而非长网络地址将数据报文从一个网络节点传输到另一个节点，以避免在路由表中进行复杂的查找。这些标签标识了远端节点之间而非端点之间的虚拟链路（路径）。MPLS 可以封装多种网络协议的数据包，并且支持多种接入技术。

- 北向接口（Northbound Interface）
将组件所使用的或组件中的底层细节（如数据或函数）抽象化的接口。通过它可以和采用上层组南向接口的上层组件交互。从总体架构来看，北向接口一般画在定义它的组件的顶部，因此称为北向接口。北向接口的例子有JSON 和Thrift。

- 南向接口（Southbound Interface)
与北向接口相反的接口。南向接口一般画在架构图的底部。南向接口的例子包括I2RS、NETCONF 和命令行接口。

- 网络拓扑
计算机网络中各个网元设备（链路、节点、接口、主机等）的布置。本质上，它是网络的拓扑结构，并且可以有物理或逻辑上的表现形式。物理拓扑结构指网络中各组件的摆放，包括设备的位置和线缆的安装，而逻辑拓扑显示了数据在网络中如何流动，与物理设计无关。就算两个网络的节点间距离、物理互联、传输速率或信号类型不同，它们的逻辑拓扑结构也可能是相同的。

- API
软件组件之间交互的规范说明。在实践中，API（Application Programming Interface，应用编程接口）通常是一个库，其中包括变量、程序、对象类和数据结构的规范。API 规范可以有多种表现形式，包括国际标准（如POSIX）、供应商文档（如JunOS SDK）或某种编程语言的库。

本书内容

- 第1章　引言
这一章介绍并且描绘本书所讨论内容的框架，包括SDN 的概念、起源，以及为什么这些话题值得本书去讨论。

- 第2章　集中式和分布式的控制与数据平面
SDN 经常被认为是对未来网络架构的一种抉择：究竟是分布式/ 基于共识的（consensus），还是集中式网络控制平面模型？本章介绍分布式和集中式控制的基础内容，数据平面在这两种模型中是怎样生成的，两种模型的历史3，当前分布式/ 基于共识的模型所拥有的一些可以用替代品来实现的预期功能，以及这两种模型的优点。

3.是的，以前也有过集中式控制模型。

- 第3章　OpenFlow
OpenFlow 已经被市场认定为SDN 的代名词（ 即OpenFlow 就是SDN） 或者SDN 的一个关键组件，到底是哪一个取决于开放网络基金会（Open Networking Foundation）的营销“念头”。当然，OpenFlow 确实引起了人们对于集中式控制模型的讨论。这一章会介绍OpenFlow 模型的现状。

- 第4章　SDN 控制器
一些人认为，对SDN 技术的讨论实际上是对网络状态管理的讨论，而网络状态管理正是SDN 控制器的角色。这一章将概述现有的（开源或商业）控制器，它们的结构和功能，并将它们和一个（将在第9 章中讨论的）理想化模型进行对比。

- 第5章　网络的可编程性
这一章将介绍SDN 的关键信条之一：网络的可编程性。首先介绍网络鸿沟问题。这个问题本质上可以归结为传统的管理接口和范式使网络应用与网络之间保持了很大距离。我们会说明为什么这是一件坏事，以及如何用现代化的编程接口来修正它。这一章的内容奠定了现实世界中网络应用和网络设备遵循SDN 范式变革的基调。

- 第6章　数据中心的概念与结构
这一章将通过对数据中心历史演进的初步探讨向读者介绍现代数据中心的概念。这个演进过程始于20 世纪90 年代末，当时的世界以桌面为中心，而今，人们生活在分布式的世界中，应用及构成应用的组件分布于多个数据中心。这一章将介绍多租户的概念，它是数据中心中虚拟化以及其他虚拟化周边技术的关键驱动力。最后，我们将解释为什么上述技术是SDN 方案的关键，以及为什么它们是推进SDN 这场运动的主要力量。

- 第7章　网络功能虚拟化
这一章的内容建立在前几章所介绍的一些SDN 概念的基础上，如可编程性、控制器、虚拟化、数据中心等。在这里，我们将探索SDN 的一个前沿领域，该领域将SDN 的关键概念和组件结合在一起，不仅给人们带来了服务虚拟化，还允许人们将这些服务以一种新颖而有趣的方式连接在一起。

- 第8章　网络拓扑与拓扑信息的抽象
这一章向读者介绍网络拓扑的概念，不仅介绍它现在的概念，还会说明这个概念是如何随时间演化的。具体将讨论为什么网络拓扑（包括它的发现、日常维护以及与应用的交互）是NFV 等许多SDN 概念的关键。还将探讨多种已经可以部分解决网络拓扑这个难题的方法，以及最近IEFT 在I2RS 上所做的努力为何可能完全解决这个难题。

- 第9章　构建SDN 框架
这一章描述理想化的SDN 框架，该框架可以应用于SDN 的控制器、网络应用和生态系统。此概相当重要，因为它不仅构成当今所有SDN 控制器的体系结构基础，并且从中可以看到控制器正在或将要进行的演进。本章将展示这种框架的多种变体及其随时间的演化，并最终介绍目前Open Daylight 联盟的方案中采用的框架。作者认为该方案是目前建立理想化框架的最好方案，它不仅技术上合理、实用，而且很接近人们在多次尝试和失败后找到的出路。

- 第10章　带宽调度、控制和时间规划的案例
这一章向读者展示带宽调度、控制和带宽时间规划领域的一些用例。本书将演示作者和其他人在各自的实验室构建的用来验证概念的用例。这些用于概念验证的方法有些已经应用于生产环境。虽然它们现在还只是示例，但确实有实际的应用价值。

- 第11章　数据中心叠加网、大数据和网络功能虚拟化案例
这一章将介绍SDN 在数据中心领域的用例。我们将特别展示关于数据中心叠加网络、网络功能虚拟化的一些有趣用例，说明大数据如何推动SDN 中的某些概念。

- 第12章　输入流量监测、分类及触发操作案例
这一章向读者展示输入流量/ 触发动作类的用例，这些用例有共同的行为模式，它们在网络边缘接收某些流量后做出相应的动作。这一动作可以通过编程实现。实现的方式可以是采用集中式控制器，或者是让一个设备在遇到某种特定的流量时向控制器询问应该采取什么动作。这里将展示两个用例以阐释这些概念。首先会说明作者如何构建概念验证，有效地用OpenFlow 控制器和一些真实的路由器取代网络访问控制（NAC）协议和它的活动部件。这样就解决了大型企业中存在的现实问题，而这个问题很难用其他方法解决。其次还将展示如何用虚拟防火墙，通过和控制器的交互，来监测和触发特定的行为。

- 第13章　最后的思考与结论
这一章将带人们回到现在时，再次强调本书对于SDN 当前（撰写本书时）状况的基本观点，并且对SDN 这个主题提出一点总结性的见解。

排版约定

本书使用以下排版约定。

- 粗体
表示新的术语。

- 等宽字体
表示程序片段，也用于在正文中表示程序中使用的变量、函数名、命令行代码、环境变量、语句和关键词等代码文本。

- 等宽加粗
表示应该由用户逐字输入的命令或者其他文本。

- 等宽斜体
表示应该由用户输入的值或根据上下文决定的值替换的文本。

这个图标代表小窍门、建议或说明。
这个图标代表警告信息。

使用代码

补充材料（ 代码范例、练习等） 可以在此下载：http://shop.oreilly.com/product/0636920027577.do。打开链接后，在页面右下方找到Download Example Code 链接，可以下载到一个.txt 文件，里面是第10 章案例的完整配置。你可以在自己的试验性项目中使用该配置。

本书就是要帮读者解决实际问题的。也许你需要在自己的程序或文档中用到本书中的代码。除非大段大段地使用，否则不必与我们联系取得授权。因此，用本书中的几段代码写成一个程序不用向我们申请许可。但是销售或者分发O’Reilly 图书随附的代码光盘则必须事先获得授权。引用书中的代码来回答问题也无需我们授权。将大段的示例代码整合到你自己的产品文档中则必须经过许可。

使用我们的代码时，希望你能标明它的出处。出处一般要包含书名、作者、出版商和书号，例如：“SDN: Software-Defined Networks by Thomas D. Nadeau and Ken Gray.Copyright 2013 Thomas D. Nadeau and Ken Gray, 978-1-449-34230-2.”

如果还有其他使用代码的情形需要与我们沟通，可以随时与我们联系：permissions@oreilly.com。

Safari® Books Online

| Safari Books Online（http://www.safaribooksonline.com）是应需而变的数字图书馆。它同时以图书和视频的形式出版世界顶级技术和商务作家的专业作品。

Safari Books Online 是技术专家、软件开发人员、Web 设计师、商务人士和创意人士开展调研、解决问题、学习和认证培训的第一手资料。

对于组织团体、政府机构和个人，Safari Books Online 提供各种产品组合和灵活的定价策略。用户可通过一个功能完备的数据库检索系统访问O’Reilly Media、Prentice Hall Professional、Addison-Wesley Professional、Microsoft Press、Sams、Que Peachpit Press、Focal Press、Cisco Press、John Wiley & Sons、Syngress、Morgan Kaufmann、IBM Redbooks、Packt、Adobe Press、FT Press、Apress、Manning、New Riders、McGraw-Hill、Jones & Bartlett、Course Technology 以及其他几十家出版社的上千种图书、培训视频和正式出版之前的书稿。要了解Safari Books Online 的更多信息，我们网上见。

联系我们

请把对本书的评价和发现的问题发给出版社。

美国：
O’Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472

中国：
北京市西城区西直门南大街2 号成铭大厦C 座807 室（100035）
奥莱利技术咨询（北京）有限公司

O’Reilly 的每一本书都有专属网页，你可以在那儿找到本书的相关信息，包括勘误表、示例代码以及其他信息。本书的网站地址是： http://shop.oreilly.com/product/0636920027577.do

对于本书的评论和技术性问题，请发送电子邮件到：
bookquestions@oreilly.com

要了解更多O’Reilly 图书、培训课程、会议和新闻的信息，请访问以下网站：
http://www.oreilly.com

我们在Facebook 的地址如下：
http://facebook.com/oreilly

请关注我们的Twitter动态：
http://twitter.com/oreillymedia

我们的YouTube 视频地址如下： http://www.youtube.com/oreillymedia

Thomas Nadeau的致谢

我想首先感谢我出色的妻子Katie， 以及我的两个儿子，Thomas Peter 和Henry Clifford。我无法想象，如果离开了你们，我还能不能如此快乐。人生是一场旅途，我很荣幸能够一路有你们相伴。我还要感谢我的父母，Clement 和Janina。没有你们的支持和鼓励，我永远也不可能成为一名工程师，或者至少，如果没有父亲在我年轻时候的指点，我现在就不会这么擅长锡焊。我还要对很多现在或者过去的同事说声谢谢，是你们带我进入了SDN 的世界，并且让我的想象力在其中得到发挥。这些人包括但不限于David Ward、Dave Meyer、Jan Medved、Jim Guichard、Ping Pan、Alia Atlas、Michael Beesley、Benson Scliesser、Chris Liljenstolpe、Dan Backman、Nils Swart和Michael Bushong。另外，我永远也不会忘记George Swallow 是如何接收我为他年轻的学徒，并且对我进行绝地训练的，否则我不可能达到今天的水平。如果没有这些，我不可能在网络行业取得现在的成就。我还要感谢很多我在思科公司、CA，以及我现在的东家瞻博公司工作时的同事，限于篇幅，就不逐一列举了。我要感谢更大的SDN社区，包括在SDN 的早期就有所建树的斯坦福大学、IETF、ONF 和Open Daylight 项目。感谢Meghan Blanchette 和O’Reilly 的其他工作人员。当然，还要感谢我们的编辑Patrick Ames，他在我们误入歧途时带我们回到正轨，并且帮助我们表达出我们所能传达的最好最明了的信息。

最后，同样重要的，我想对本书的合著者Ken Gray，表达我衷心的感谢。如果不是你掌握着这条船的另一把桨，我不知道我还能否一个人划到终点。你的贡献真正提升了这本书的价值，让它超出了我的期望。

Ken Gray的致谢

我要感谢我了不起的妻子Leslie。她在我参与本书编写，以及随之而来的一切工作期间耐心地支持我，并且给我带来了足够的平衡以及理智。

对于我的孩子，Lilly 和Zane，我希望自己鼓起勇气编写的这第一本书，可以激励你们去开创自己的伟大事业（无论是什么事业）。

限于篇幅，我不能列出客户、同事和朋友的名字，过去两年中和你们的交谈塑造了我对SDN 这个话题的观点。

如果我列出帮助过我的同事、标准化组织以及（当然）那些帮助我们出版本书的人们，那会和我的合著者列出的名单非常相像，大家应该明白这不是巧合。我要特别地再次感谢我过去在瞻博公司的同事（他们现在可能在SDN 领域的创业公司）。两年多以前，他们和我俩一起开始了SDN 相关的工作，那时，“富有远见”这个词还没用来形容SDN 理论家和战略家，他们帮助我塑造了我的观点。出于同样的原因，如果可以重复地感谢一个人，我希望特别地感谢一位我现在在瞻博公司的同事：BensonScliesser。

最后，我要给予我的合著者Thomas Nadeau 以极大的感谢。我们从两个不同但是互补的角度出发，在这个话题上形成了共同的观点。过去几年，我们在无数次的公开讨论中把这两个视角放在一起，并最终把它们印刷出版，这对于我来说是一段极好的经历。这段经历帮助我完善了谈论SDN 的方式，希望它也造就了一部好书。

第1章　引言

直到几年前，存储、计算和网络资源在物理上和运营上还是刻意分开的。甚至用来管理这些资源的系统也是分开的——通常是在物理上分开。运维监控系统等和资源进行交互的应用，都被非常复杂的访问策略、系统和访问规则等以安全的名义控制着。IT 部门就喜欢这种方式。只有等到数据中心环境需要并引入廉价的计算能力、存储空间和网络连接之后，这些机构才不得不将这些网元设备放在一起考虑。这种范式上的变迁，让管理和操作这些资源的应用比以前更加紧密地联系在一起。

数据中心最初被设计用来在物理上分隔传统计算单元（如PC 服务器）、它们所用的存储，以及连接它们和用户的网络。这种数据中心的计算能力往往被用于特定的服务器功能，例如运行邮件服务器、数据库服务器或其他被广泛使用的功能，来为桌面客户端提供服务。以前，这些功能通常运行在企业机构中数千台（或更多）桌面电脑上，由专职部门内部使用的部门级服务器群提供服务。随着时间的推移，出于多种原因，部门级服务器群迁移到了数据中心，这样做主要是为了管理上的便利，其次是企业用户之间的资源共享。

大约10 年之前，发生了一个有趣的变化。一家叫做VMware 的公司发明了一项有趣的技术，它允许一个或多个客户操作系统（如Windows）在流行的Linux 发行版等主机操作系统上运行。VMware 公司所做的是创建了一种小程序，用来建立集成了真实计算环境（如虚拟NIC、BIOS、声卡和视频装置）的虚拟环境，然后在多个虚拟机之间分配资源，并且将虚拟机隔离开。这种监控程序被称为虚拟机管理程序（hypervisor）。

最初的时候，VMware 软件是为那些想要在Linux 下完成大多数计算任务，而只在某些需要Windows 操作系统环境时才用Windows（那时候，这种情况在企业里是常态）的工程师们设计的。他们在Windows 下完成操作后可以像关闭一个普通程序那样关掉Windows，然后继续使用Linux。有意思的是，这样用户就可以把客户操作系统当作其磁盘上的一个程序文件（尽管很大）。人们能够像操作其他文件那样操作这个文件（比如可以把它移动或复制到其他机器，而且还能像安装在原来的机器上一样运行）。更有意思的是，这个操作系统可以在它察觉不到的情况下被中止，实质上是让它进入历程中断状态（suspended animation）。

随着操作系统虚拟化的出现，原本运行Microsoft Windows Server 这种单一的、专用的操作系统以及运行为这些操作系统量身定做的应用的服务器，现在可以被看作普通的计算和存储平台。随着内存、计算能力、存储的进一步发展和增加，数据中心服务器增强了在虚拟化环境中同时运行多个操作系统的能力。VMware 扩展了它的单机版，让它更加适用于数据中心环境，以便在一个终端上运行和控制成百上千的虚拟机。Windows Server 这种以往占据整台物理机器的操作系统如今可以在一个个虚拟机中，各自运行着用户所需的应用。唯一不同的是，每个系统运行在自有的环境中，可以中止、迁移、克隆或者复制（比如备份）。弹性计算（elastic computing）的时代就这样开始了。

在弹性计算环境中，运维部门只需简单地暂停虚拟机再复制文件，就可以将服务器迁移到数据中心的任意物理位置。它们甚至只需要克隆相同虚拟机的文件，然后让虚拟机管理程序将它作为新的实例来运行，就可以创建一个新的虚拟机。凭借这样的灵活性，网络管理员可以利用能源和冷却等指标，来优化数据中心里资源的位置。通过将所有运行中的虚拟机整合在一起，管理员可以让数据中心其他部分的服务器休眠或空转，调低这部分的冷却性能，从而优化了数据中心的冷却负荷。类似地，管理员也可以根据区域的需求，移动或动态地扩展计算、存储或网络资源。

和所有技术上的进步一样，这种在操作部署计算、存储和网络资源上引入的新的灵活性也带来了一个新问题：在考虑对存储和计算能力实现最大化的同时，又要兼顾能源和冷却时的运营效率。正如前面提到的那样，网络管理员开始意识到，一般来说，对于计算能力的需求会随着时间而增长。为了跟上这种需求，IT 部门（通常按年度分配预算）会预测并订购下一年所需的所有设备。然而，只要设备到位并且放置在了机架上，就算它尚未使用，那也还是会消耗电力、冷却和空间资源。亚马逊首先发现了这个左右为难的问题。当时亚马逊的业务正呈现出“曲棍球杆曲线”（hockey stick graph），每6~9 个月翻一倍。因此，为零售、库存和仓库管理系统以及内部IT 系统提供计算服务的系统，其增长必须快于需求。所以亚马逊的IT 部门不得不预先订购大量的存储、网络和计算资源，但他们又陷入了另一个窘境，在需求赶上之前，这些设备会一直处于闲置状态。为了商品化这些未利用的资源池，充分利用这些资源，亚马逊发布了Amazon Web Services（AWS）。当亚马逊的内部需 要更多资源时，AWS 就会简单地压缩零售用户的资源，否则零售用户可以用尽未使用的资源。有人称之为弹性计算服务，本书称之为超虚拟化（hyper virtualization）。

从那时起，亚马逊、Rackspace 等公司等为了价格优惠而大量购买存储和计算设备，结果发现他们并没有充分地利用自己的存储和计算资源，实际上他们可以将多余的计算能力和存储转售给外部用户，从而弥补一些资金投入。多租户的数据中心就这样兴起了。当然，这就引入了一个新的问题，如何将上千个潜在的租户互相隔离开，而这些租户所租用的资源却是任意地分散在不同数据中心的虚拟机上。还有一种理解这个困境的方式是，注意到在迁移到超虚拟化环境之前，（计算任务的）执行环境一般都是由单个企业或者组织来操作的。这就是说，他们通常拥有所有的计算和存储资源（尽管一些是租用的主机托管空间），并把这些资源看做一个连接了大量虚拟机或物理机以及存储设备的扁平局域网（LAN）来操作。（唯一的例外是在金融机构中，需要按照规范要求来实施隔离。）但是，在这些示例中，部门的数量都相对较小，不到100，所以这个问题可以简单地用现有的工具（如2 层或3 层MPLS VPN）来解决。就算使用这两种解决方案，连接所有计算和存储资源的网络组件也还相当简单，它基本上是一个连接所有物理机或虚拟机的扁平以太网LAN。因为这些机器都归一家企业所有，只供他访问，在绝大多数这样的环境中，所有（虚拟或物理的）设备都分配了同一个网络（可能是同一个IP 子网）内的IP地址。这也意味着将虚拟机在同一家企业的不同数据中心之间迁移不会产生问题，因为它们也都在同一个路由域下，并且不管物理位置如何，都可以互相联通。

多租户数据中心的计算、存储和网络资源可以分成相互独立或隔离的分片来提供服务。事实上，将它们隔离开十分关键。这带来了一些有趣的挑战，这些挑战在以往单租户数据中心环境下是不存在的。请记住，多租户的环境允许任意数量的操作系统和运行在这些操作系统上的应用，但如果它是要被其拥有者或者其他外部用户（如客户）访问的话，那么每个操作系统都需要一个唯一的网络地址。在过去，可以从单个、可能是私有网段的内部地址块分配，并且可以轻松在企业内部进行路 由。然而现在需要分配唯一并且可以从外部路由和访问的地址。此外，考虑到相关虚拟机也都还有一个唯一的2 层网络地址。路由器最终需要利用以太网来传送数据报文（而不仅仅通过IP）。这通常不成问题，除非需要考虑虚拟机的移动性（VM molibity）。在这些数据中心里，虚拟机会由于电力、冷却或计算密度等原因而迁移。难点就在这里，因为物理位置的迁移意味着物理地址的迁移。这也意味着可能需要对3 层路由进行更改，以确保发往该机器原先所在位置的数据报文现在可以发送到新位置。

在数据中心不断发展的同时，网络设备却似乎在满足吞吐量和速度以外的方面缺乏创新。也就是说，在IP、MPLS 和移动技术出现之后，网络技术在交换结构能力和接口速度、数据通信以外的方面有些停滞不前。IP 和MPLS 允许网络管理员在这些基础网络上创建网络和虚拟叠加网络，就像数据中心管理员可以利用计算虚拟化技术在物理机上创建并运行虚拟机那样。网络虚拟化通常被称为虚拟专用网络（VPN），并且以多种形式存在，包括点对点（如个人VPN，在笔记本上用它来连接到公司的网络）；3 层（虚拟化IP 或路由网络，比如网络管理员可以用它们将本企业的流量和其他流量隔离开，以此保证企业网络的安全）和2 层VPN（交换网络虚拟化以提供和3 层VPN 类似的隔离，只不过这里用的是以太网地址）。

商用路由器和交换机通常配备了管理接口，支持网络管理员配置和通过其他手段管理这些设备。这些管理接口包括命令行接口、XML/Netconf、图形用户界面（GUI）和简单网络管理协议（SNMP）等。通过这些接口，管理员可以用恰当的方式来管理设备，但是它们通常仍然对管理员隐藏了最底层的细节。例如，网络管理员可以编写静态路由表或其他静态的转发项，但是这些最终都要转化为传递给设备操作系统的请求。如果有人想利用设备上已有功能的语法或功能来配置，这通常不成问题。但如果有人希望试验新的路由协议，就只能使用固件中支持这种新协议的设备。在 这种情况下，客户经常会向设备厂商提出功能增强的要求，并且需要等待很长的时间（等待数年也不罕见），客户请求的功能才会加入。

与此同时，（至少在逻辑上）分布式控制平面的概念再一次出现在人们视野中。一个网络设备由数据平面和一个控制平面组成。数据平面通常是一个交换结构，连接了设备上的多个网络端口。控制平面则是设备的大脑。例如，用来在一个网络中构建无环路的路由协议，通常以分布式的方式实现。也就是说，网络中的每个设备都有一个实现了该协议的控制平面。这些控制平面相互沟通、协调，以构建网络路径。然而，在集中式控制平面范式中，会存在一个（至少在逻辑上）单独的控制平面。这个超级大脑会将命令推送到每个设备，从而指挥这些设备来操控各自的物理交换和路由硬件。应该特别注意的是，虽然构成设备数据平面的硬件仍然相当专业化，因而价格昂贵，但是控制平面却日益倾向于使用越来越便宜的通用计算设备，如Intel 公司生产的中央处理单元。

上面提到的都是重要的概念，因为它们为今天软件定义网络（SDN）的技术提供了核心动因。SDN 的早期倡导者发现网络设备厂商不能满足他们的需求，尤其在功能开发和提供的创新空间上。高端的路由和交换设备也被认为定价过高，至少对于这些设备上的控制元件来说是这样。与此同时，他们看到了原材料价格，即弹性计算力的成本快速下降。这让一个人处理上千个处理器成为了现实。从那时起，他们意识到可以利用这些计算力来运行一个逻辑的集中式控制平面，这样就可以使用哪怕是廉价、商品级价位的交换硬件。斯坦福大学的几位工程师创造出了一种称为OpenFlow 的协议，这个协议正好可以采用上述硬件配置来实现。OpenFlow 的架构为一些只有数据平面的设备而设计，这些设备被一个（逻辑上的）集中式控制器所控制，这个控制器是该网络中唯一一个控制平面。这个控制器负责维护所有的网络路径，以及对其所控制的网络设备进行编程。OpenFlow 的协议描述了这些指令和响应规范。值得一提的是，开放网络基金会（ONF）对SDN 提供商业上的支持，并且今天仍然是其标准化和市场推广的权威机构。基于刚才所描述的这个基本架构，人们现在可以想象，在数据中心的廉价硬件上实现新的协议是多么地快捷和方便。更妙的是，人们可以在弹性计算环境中的虚拟机上实现它。

对于SDN 还有一个稍有不同的视角，业内一些人士称之为软件驱动网络（softwaredriven network），而不是软件定义网络。这种文字游戏并不是故意要把读者搞晕，而是为了突出在方法理念上的差别。在软件驱动的方式中，人们将OpenFlow 及其架构视作所有可实现功能的一个特殊子集。不是在逻辑上把网络看做集中式控制平面和一堆非智能的网络设备，而是将这个世界看成新旧技术的混合体。更确切地说，把现有的网络都拆掉甩卖，让ONF 和软件定义网络来构建新世界是不现实的。丢弃现有支撑着互联网的先进网络技术同样也是不现实的。然而，更现实的是一种混合的方式，网络的一部分被一个逻辑上的集中式控制器操控，而其他部分则由更传统的分布式控制平面来操控。这也意味着，这两个世界要彼此互通协作。

有意思的是，人们发现在SDN 和OpenFlow 倡导者的众多努力中，有一个共同的主要内容，即实现更广泛、更灵活的网络设备可编程性。可编程性不一定与网络控制和数据平面的位置有关，但它关系到如何编写这些设备。不要忘记，创建SDN 和OpenFlow 的一个动机就是如何（how）对网络设备进行编程以获得灵活性，而不只是在哪里（where）进行编程。如果有人关注了SDN 的体系结构设计方面正在进行的工作，就会发现可编程性和编程位置这两个问题都解决了。剩下的问题是，从可编程性的角度来解决问题是否是最优选择。

最近，为了解决这个问题，来自思科公司（Cisco）、瞻博公司（Juniper）、Level3 公司及其他厂商和运营商的技术人员率先为网络可编程性做出了努力，他们的工作成果称为路由系统接口（I2RS）。这些公司的一些同仁为多个相关的IETF 草案做出过贡献，包括基本的需求和框架草案，Alia Atlas、David Ward 和Tom 是主要的贡献者。在不久的将来，至少会有十多份与此相关的草案公布在网络上。很明显，大家对这方面的工作都有着极大的兴趣。I2RS 的基本思想是创建一个协议和多个组件，作为利用快速路径协议来编写网络设备路由信息库（RIB）的一种手段，这种协议支持快速直通式的业务开通配置操作，以允许RIB 和控制它的RIB 管理器之间进行实时交互。此前，通过设备的配置系统（对于Juniper 的设备来说，是Netconf 或SNMP）来操控RIB，是管理RIB 的唯一方法。

理解I2RS 的关键在于，明白I2RS 带来的绝不仅仅是一个业务开通配置协议。这是因为还有许多其他的关键概念组成了整套解决方案，来解决加速网元设备之间的反馈回路、网络编程、网络状态和统计信息获取和后期处理等综合问题。如今，这个反馈回路慢得令人感到痛苦。参与I2RS 的人们认为可编程网络的未来就在于优化这条回路。

为此，I2RS 提供了网络编程的几种不同抽象级别，如网络路径、策略、端口配置，而这些都带来了同样的质量监督上的优势，把编程视作在提交命令前做检查的手段。举个例子，现有的某些用于编写硬件抽象层（HAL）的协议要么粒度过于精细，要么展示了过多的细节，这都影响网络的效率，实际上是给协议的运维系统带来了不必要的负担。另一个例子是为运营支撑系统（OSS）的应用程序提供快速和最佳的RIB 访问，让程序变更更快速地生效，然后观察效果。为了优化网络操作，必须支持快速重新编程。这些例子的一个要点在于，应用程序和RIB 之间的会话是通过RIB 管理器进行的。这点很重要，这是因为许多管理员都希望保留他们在路由协议方面所做的工作，这些工作都位于Junos 或IOS-XR 等设备操作系统上，与此同时充分利用这个新颖实用的编程范式来进一步优化他们的网络。

I2RS 也非常适用于满足人们不断增加的对于逻辑上集中式路由、路径选择和可编程性的渴望。这个协议对于在网络设备上和网络设备之外运行都有要求。这样，可以在需要时使用分布式控制器的功能，也可以在需要时支持更加经典的分布式控制场景。

最后，I2RS 还有一个关键的子组件，就是归一化和抽象化的拓扑结构。定义一个公共可扩展的对象模型就可以表示这种拓扑结构。这种服务还允许公开拓扑表示的多种抽象。这个模型的一个关键在于非路由设备（或其他不支持路由协议的设备）可以更容易地操作和改变RIB 状态持续转发。如今，非路由设备还不能很好地获取这个信息。持续转发、网络管理组件/OSS、分析和其他人们无法预见的应用，将会更快速和有效地与路由状态和网络拓扑进行交互。

所以，人们应该对SDN 下个定义，说明它是什么，以及会变成什么样。以下总结这些思考。

软件定义网络（SDN）：是一种优化和简化网络操作的体系结构方式，它将应用与网络服务、设备之间的交互（如服务开通配置、消息传递、警报）更紧密地结合在一起，不论它们是物理的还是虚拟化的。它通常利用一个逻辑上集中式的网络控制，通常被认为是由SDN 控制器来实现，它编排、协调并促进希望与网元设备进行交互的应用程序，以及希望传送信息给应用的网元设备之间的通信。然后，控制器通过现代化的、应用友好的、双向的编程接口来展示、抽象网络功能和操作。

所以，可以看到，软件定义、软件驱动、可编程网络具有一套丰富和复杂的历史传承、挑战，以及针对这些挑战的多种解决方案。正是软件定义、软件驱动和可编程网络出现之前的技术的成功，使得基于它们的先进技术成为可能。现实情况是，世界上的大多数网络（包括互联网）都运行在IP、BGP、MPLS 和以太网的基础上。如今的虚拟化技术基于VMware 公司多年前开创的技术，现在仍然是VMware 公司和其他产品的基础。网络附加存储有着同样丰富的历史。

只要能够解决网络、计算、存储虚拟化，以及超虚拟化环境下应用的编程性、易访问性、位置和迁移这些问题，I2RS 也将会有同样的光明前景。

虽然SDN 控制器仍然在媒体中称王称霸， 但写作本书时， 许多其他技术进步也出现了。其中一个非常有吸引力且非常透明的项目就是OpenDaylight 项目。OpenDaylight 的任务是促进以社区为主导的、业界支持的开源框架，包括代码和架构，来加速和推动通用的、稳健的软件定义的网络平台。为此，OpenDaylight 项目作为Linux 基金会托管的项目，将会有利于真正改变游戏规则，并有可能为SDN 控制器的发展铺平道路。这方面的努力也将刺激在我们看来这个领域最重要的东西：应用的创新。在过去几年中，可以看到控制器的种种进步，控制器被认为真正代表了支持SDN 的应用程序的基础架构。在这种思想的影响下，过去几年中，业界一直在努力设计和开发控制器，却大多忽视了应用。作者认为，SDN 真正的意义在于运营上的优化和效率，利用这些优点的最好方式，是快速完善基础设施，然后让业界专注于应用和设备层的SDN 架构创新。

本书侧重于软件定义网络、软件驱动网络和可编程网络的网络部分，但也会包含足够多的虚拟化、位置和存储、网络和计算的编程等方面内容。本书的目标就是探索这些网络技术进步背后的细节和动机，这些细节和动机带来并且支撑了网络、存储和计算资源的超虚拟化，并且现在也被视为SDN 的一部分。

第2章　集中式与分布式的控制平面和数据平面

将网络设备的控制和数据平面分离能够带来潜在的优势，这是此前在介绍SDN时提到的一个原则。这种分离，在集中式和半集中式的编程控制方面为网络管理员带来了一些便利。它还带来了一个成本上的潜在优势，因为这种方法可以把通常相对复杂的功能整合到软件里，来配置和控制廉价的所谓通用商品级硬件。

2.1　引言

控制和数据平面的分离，的确是SDN最基本的原则之一，但也是较富争议性的一个原则。尽管这不是一个新的概念，但用当前的思考方式可以对这个传统的想法有一些新的考量：控制平面究竟可以与数据平面相距多远？需要多少实例才能满足对故障的恢复能力和高可用性的要求？是否控制平面可以实际上百分之百地放置在数据平面之外更远的位置，而不是仅相距几英寸的距离处？这些问题大家都激烈地争论过。面对这些想法时，作者更乐意将它们看作是各种不同可能性的连续区，即从最简单的、传统的完全分布式的控制平面，到半集中式的或逻辑上集中式的控制平面，最终到严格的集中式控制平面。图2-1 说明了可供网络管理员选择的全谱系选项，以及它们的优缺点。

图2-1：控制平面与数据平面分布式选项的谱系图

演进还是革命

在回答控制平面放置位置问题时，该谱系图的最左端是对革命方式的支持，它提出了将网络的控制平面完全采用集中式这样一种推倒重来的全新方案。在大多数情况下，由于规模或高可用性的要求，使得严格集中式的方案很难实现，对这种极端方案的尝试实际上最终演化为逻辑上集中式的方案。在这一模型中，设备上并不具备控制平面的功能，这种模型中的设备都是“傻”的（尽管速度很快）交换设备，被位于远端的集中式控制平面完全地控制。稍后，本章会探讨这些细节，并且说明为什么这种模型通常最适用于新部署的网络，而不是现有的网络。

在该谱系图的中间是对演进方式的支持，它着眼于一般定义下的网络域。在这里，集中式控制的形式固然带来了一些新功能，但并不能取代原有的所有功能，也不能完全地将控制平面从设备上移除。这种模式通常能以某种形式和分布式的控制平面一起工作，这意味着设备还保留了一些传统的控制平面功能（如ARP处理或MAC地址学习），同时允许一个集中式的控制器来操控其他功能，即采用集中式操作范式更方便的那些功能。这种观点往往被当作混合操作或“承载/ 叠加”（underlay/overlay）的概念，即分布式控制平面作为承载，而集中式控制平面在利用承载网进行网络传输的基础上，在逻辑上叠加新的功能。

最后，在谱系图的最右端就是传统的控制平面的用法：完全彻底的分布式。在这个模型中，每个设备除了拥有至少一个数据平面以外，还要拥有一个完整的控制平面。而且，在该模型中每一个独立的控制平面必须与其他控制平面合作，以支持一个整体的、可运行的网络。显然这个方案并没有新意，既不是革命性的，也不是演进性的。

本章不会向读者呈现关于控制/ 数据平面设计或部署方面的全面讨论，因为这种全面讨论始终会贯穿全书。因此，本章会讨论所涉及的SDN 问题的一般性概念，并尽量为读者提供一些参考文献，以供读者进行更加深入的了解1。本章将探讨前面介绍的控制平面分布与操作谱系图上每种方式在过去与当今的各种示例，包括关于控制的集中式、混合式和完全分布式操作。

1.作为SDN 演进的一部分，开放网络基金会有时将SDN 的定义和OpenFlow 紧密联系起来（如OpenFlow=SDN)，有时又比较宽松（如OpenFlow 是SDN 的一个关键组件）。不管怎样，不可否认的是OpenFlow 的存在以及ONF 积极的推广，引发了市场和公众对SDN 的讨论和兴趣。

2.2　控制平面和数据平面做什么

我们首先探讨控制平面和数据平面的基础组件和行为，它们为什么不同，以及它们应该如何实现。

2.2.1　控制平面

从高度抽象的角度来看，控制平面在本地建立了用于创建转发表项的数据集，数据平面利用转发表项在设备的出入端口之间转发流量2。其中保存了网络拓扑的数据集被称为路由信息库（RIB）。在与网络中其他控制平面通信的过程中，RIB 总是保持其一致性（如不会产生环路）。转发表项通常被称为转发信息库（FIB），并且一般在设备的控制和数据平面上保持镜像关系。一旦RIB 被视为一致且稳定，FIB 马上就会被创建出来。要执行此任务，控制实体/ 程序必须建立一个网络拓扑的视图（view），此视图必须满足一定的约束条件。网络的这种视图可以通过人工编程来得到，通过观察来学习，也可以从与其他控制平面实例的通信中所收集的零散信息中构建出来。这种控制平面之间的通信可以通过一种或多种路由协议、人工编程或这两者的结合来实现。

2.管理平面负责对网元设备进行配置，可能影响本地转发选路（转发特性），例如访问控制列表（ACL）或基于策略的路由（PBR）。

图2-2 通过一个交换机互连的网络来展示控制平面和数据平面的机制。该图的顶部是一个交换机互连的网络，图下部还展示了其中两台交换机（图中标记为A 和B）的控制和数据平面的细节。数据分组被图下部最左边的交换机A 所接收，最终转发给图下部右边的交换机B。请注意，在交换机内部结构展示图中，控制平面和数据平面是分开的，控制平面和数据平面各自运行在自己的处理器/ 线卡上。控制平面和数据平面都包含在一个机箱内。在本章的后续部分，会探讨此种或其他种类的控制平面和数据平面的物理放置位置方式。在图中，数据分组在数据平面所在的线卡的输入口被接收。举例来说，如果收到一个含有未知源MAC 地址的数据分组，数据分组会被转发或重定向（图中标为4）到设备的控制平面上。控制平面学习、处理，然后继续转发此数据分组。控制分流量如路由协议消息（例如OSPF 链路状态通告）也会这样处理。一旦路由协议的数据分组被传送给控制平面，其中所包含的信息就会被处理，并且可能会导致RIB 的变更、或者向其他对端设备发送额外的消息以通知这项更新（即学习到了新路由）。一旦RIB 变得稳定，控制平面和数据平面上的FIB 就会被更新，转发也就随之被更新以体现此路由的变更。如果收到的数据分组的源MAC 地址是未知的，控制平面处理后还会将数据分组（图中标为C）返还给数据平面（图中标为2），以便转发数据分组（图中标为3）。如需对FIB进行额外的编程，如FIB 学习到该MAC 源地址，同样也在这一步骤（图中标为C）里完成。右边的下一台交换机中也采用了同样的处理数据分组的算法。

图2-2：一个典型网络的控制平面和数据平面

互联网发展历史可以大致反映为面对各种挑战而引发的控制模式的变革，这些控制模式包括对网络信息可达性管理、可达性信息分发协议和生成优化路径的算法。这些挑战包括不断增长的信息库（即路由表的增长），以及如何管理这个信息库。不这样做很可能会导致物理网络非常不稳定；而这么做又可能导致网络的变化速度过快，甚至让网络无法运转。随着路由信息库规模的增长，另外一个需要克服的挑战是对部分目的/ 目标数据的可达性进行宣告的责任分散问题（Diffusion of responsibility），这种通告不仅是在本地数据平面实例之间，而且是可以跨越管理界限的。

在现实中，刚才讨论的互联网的控制平面是二层和三层控制平面的某种组合。因此，二层/ 三层网络和组成其控制平面的协议都出现发展和演进也不奇怪。实际上，互联网的发展就是由于两个方面的演进，即这些协议在功能上的演进，以及硬件厂商掌握了高扩展性和高可用性的技术以实现协议的演进。

二层控制平面专注于硬件或者物理层地址如IEEE MAC地址。构建一个三层控制平面是为了使用网络层地址，如IP地址。在二层网络中，围绕MAC 地址的学习、保证无环路拓扑的机制（如大多数读者所熟悉的生成树协议）和大量的BUM（广播、单播和组播）洪泛流量，都会造成其可扩展性方面的挑战，并揭示出可扩展性上的局限。为了解决这些问题及其他问题，人们已对标准的二层控制协议进行了多次更新换代。最值得注意的是，这些协议里包括了IEEE 的SPB/802.1aq 以及IETF 的TRILL。

不过，一般来说，由于大量终端主机的存在，二层网络终究是不能很好扩展的，这导致二层和三层把它们的控制平面设计最终合并或混合在一起。这些问题的核心在于如何处理终端主机在网络之间迁移的问题，这会导致转发表的大量振荡，并且必须快速地更新转发表，以防止数据流量的转发被中断。二层网络中的转发专注于MAC地址的网络可达性。因此，二层网络为了进行转发，主要处理MAC地址的存储。因为在大型企业网络中，MAC地址的数目庞大，管理这些地址十分困难。更糟的是，想象一下，管理多个甚至整个互联网的MAC 地址会是多么困难的事。

在三层网络中，分组转发着眼于网络地址的可达性。三层网络的可达性信息主要和目的地址的IP 地址前缀的可达性有关。这包括了各种不同地址类型的网络前缀，包括单播和组播。如今三层网络被用于二层域之间的分隔与合并，以克服二层网络所存在的扩展性问题。具体而言，部分IP 子网的二层网桥一般都和三层路由器相连。三层路由器也被连在一起，组成一个更大的网络，或者几个拥有不同地址范围的子网。更大的网络通过专门为大型网络间互连而设计的网关路由器与其他网络相连。然而，在上述这些情况下，路由器在为三层网络之间的数据流提供路由时，只有在已知数据分组已经到达最终目的地所在的三层网络，并且需要将它传送到特定的主机上时，才会在二层进行转发。

随着多协议标签交换（MPLS）协议、以太虚拟专用网（EVPN）协议、位置/ 身份标识分离协议（Locator/ID Separation Protocol，LISP）的出现，二层和三层网络之间的界限才开始变得模糊。MPLS协议实际上是一系列的协议，集二层转发（或交换）和三层路由之所长，同时拥有了ATM那种极其快速的数据分组转发，以及从IP借鉴而来的高度灵活和复杂的路径信令技术。EVPN 协议试图通过将两个相距较远的二层网桥用MPLS（或GRE）隧道连接来解决本章刚刚讨论过的二层网络的扩展性问题。这样二层寻址和网络可达性信息可以通过这些隧道来传递，从而避免对其之上的三层网络造成干扰（或影响）。相距较远的网桥之间的网络可达性信息在一个新的BGP 地址段里作为数据来传输，同样不会干扰其之上的网络。其他一些优化限制了网桥间交换的二层地址的数量，并对网桥之间的交互做了进一步的优化。这种设计将广播和组播的需要最小化了。另外一种值得一提的二层和三层网络的混合是LISP（参见RFC 4984）。在其核心，LISP 试图解决普通分布式控制平面模型在多宿主、增加新的寻址域，以及通过在新的映射/ 封装控制和转发协议将站点的地址空间与厂商的地址空间分开等方面的不足。

在稍微低一些的层次上，某些类型的网络有一些辅助控制进程，被用来提供构建更强大的控制平面所需的信息。这些进程提供的服务包括链路可用性或质量信息的验证/ 通知、邻居发现和地址解析。

因为这些服务中有些有着非常严格的性能回路要求（为了缩短事件检测的时间），所以不管控制平面采用的是什么策略，它们几乎不约而同地在本地的数据平面设备里实现（如运行、管理与维护OAM）。图2-3 通过展示由多种路由协议及RIB 到FIB控制所组成的控制平面核心来描绘这一点。请注意，这里并不是非要规定控制和数据平面所处的位置，只是说数据平面放置在线卡上（图2-3 的LC 框里），控制平面位于路由处理器上（图中由RP 框表示）。

图2-3：典型网络设备的控制平面和数据平面

2.2.2　数据平面

数据平面通过一系列链路层操作来处理（通过线缆、光纤或无线媒介）到来的数据分组。这些操作通常包括数据分组的收集和基本的完整性检查。数据平面通过查询由控制平面所编程的FIB表（在某些实现中，可能是多个FIB表）来处理一个格式正常的数据分组3。这有时被称为数据处理的快速路径（fast path），因为它除了利用编程好的FIB识别数据分组的目的地址之外不需要额外的操作。这个流程的一个例外是，当数据分组不能匹配这些规则时，例如检测到一个未知的目的地址时，这些数据分组就会被发送到路由处理器上，这样控制平面就可以进一步利用RIB 来处理它们。重要的是需要知道，FIB表可能存在于一系列的转发引擎中，包括基于软件的转发、基于硬件加速的软件转发（GPU/CPU，例如Intel公司或ARM公司的产品）、基于通用商品级芯片的转发（NPU，例如博通公司(Broadcom）、Intel 公司或Marvell 公司在以太网交换机市场推出的产品）、基于FPGA 的转发以及基于专用集成电路的转发（ASIC，例如瞻博公司Juniper Trio），或者它们的任何组合4，具体取决于网元设备的设计。

3.一些实现在检查大小、对齐、封装是否符合规则要求，以及校验和的验证之外，还会做其它的检验。特别是，如果数据分组的“类型”被识别，则可能进行另外的“虚假性”检查，看分组对该类型是否有违规之处。
4.硬件平台有一个“溢出”表的设计并不罕见，这个表用于在“快速路径”/ 硬件中查询失败或者需要更多的信息来查询时（通常由于表项的数目或表项的宽度受到硬件资源的限制），这个查询随后在一个软件维护的表上进行重试——此即“慢”路径（slow path）查找。将通用商品级芯片和ASIC 组合在一起，在执行三层功能之前执行二层功能，也并不罕见，这并不需要将两种功能整合在同一个芯片上。

这里所阐述的软件路径（software path）以现代专用的网元设备（例如路由器或交换机）的基于CPU 的转发为例，它以处理器密集查询（在内核系统空间还是用户空间是由特定厂商的设计所决定的，受限于主机操作系统的架构和特征）换取处理器内存的看似无限的转发表项存储。现代计算环境中所对应基于虚拟机管理程序（hypervior-based）的软件交换机或网桥有许多硬件转发模型上的优化（以及一些局限）。

从历史上看，硬件表查询技术已经被证实可以达到相当高的数据分组转发性能，因此其在网元设备设计中占有首要地位，尤其是在高带宽的网元设备中。然而，受到云计算增长和创新的推动，最近在通用处理器输入输出处理方面的进展，使基于专用集成电路转发芯片设计的中低端性能的设备的竞争变得相当激烈。

硬件转发设计方面的差异涉及多种因素，包括（板卡和机架）空间、预算、能效以及吞吐量5的目标需求。这些会导致维持针对特定的目标数据分组长度（或者混合的数据分组长度）的线速转发（一个接口上接近信号上或理论上最大的吞吐率）所需的存储器类型（速度、带宽、大小和位置）的差异，以及运行预算（对数据分组操作的数量、序列或类型）的差异。最终，这导致转发特性支持和转发规模（例如转发表项的数量、路由表的数量）等设计上的差异。

5.在ASIC 设计中有许多特别的连锁因素，除了功耗、散热和尺寸的考虑以外，最终要在从工艺和模具尺寸，到逻辑布局/ 布线、时序和时钟频率（这可能带来最终耗损）和表共享等方面的收益率/ 成本，中达成平衡。

数据平面转发查找结果带来的典型操作就是转发（在特殊情况如组播下，此典型操作是复制）、丢弃、重标记、计数和排队。某些动作可以组合或者串连起来。在某些情况下，转发选路操作会返回一个设备内的本地端口，这表明流量被定向到一个在该设备内部运行的进程，比如OSPF 或者BGP6。这些数据分组会采用被称为上传路径(punt path) 的路径，即借以离开硬件转发路径，使用内部通信通道转发到本设备的路由处理器。这个路径通常是一条相对较低吞吐率的路径，这是因为它不是设计用来做正常流量的高吞吐率包转发用的；然而，为了高吞吐率，有的设计可以简单地在内部交换矩阵里增加一个额外通道，这样就能达到在设备内部接近线速转发的目的。

6.这里有许多例子，包括前述的OAM、BFD、RSTP 和LACP。

除了转发选路操作之外，数据平面可能实现一些轻载的服务/ 特性，通常称为转发特性（例如访问控制列表和服务质量/ 策略）。在有的系统中，这些特性使用它们自己独立的表项；而有的系统则作为转发表的扩展（通过增加表项的宽度）来执行。此外，不同的设计可以实现不同的特性和转发操作顺序（如图2-4 所示）。一些排序可能使某些特征操作排斥于其他操作。

图2-4：传统路由器/ 交换机上的入口特性应用的典型示例

使用这些特性，用户可以在一定程度上本地调整或者占有转发表查询的结果。举例如下。

- 一个访问控制列表可以对某个特定的匹• 配流指定一个丢弃操作（注意，在ACL 中，一个较宽泛的参数集合可以被用到转发选路中）。由于ACL 也可以有合法的转发表项，所以数据分组不被丢弃。

- 一个服务质量（QoS）策略最终把一个流映射到出口的一个队列，或者重标记它的TOS/COS 字段来对网络策略的服务进行规格化。就像ACL，不管是否已经存在到这个目的/ 流的转发表项，它都可以将分组标记为丢弃（整形）。

这些转发特性会与第7章中对服务的定义相重叠。可以说，这些特性是作为服务的数据平面和控制平面的组件而存在的。当本书讨论会话管理、代理以及数据分组包头的大规模转换等服务时，这些定义就有明显差异了。作为转发操作的组成部分，数据平面需要做某种程度的数据分组包头重写。

2.2.3　在控制平面和数据平面之间传递信息

当前大型多槽/多线卡的（即机架式的）分布式转发系统的内部功能，与SDN 的逻辑上集中但物理上分布式的控制机制相仿。特别是路由表的分发和它们在硬件的实例化这些方面会令人感兴趣。研究典型的分布式交换的内部工作情况就可以揭示与外部化的控制平面相仿的一些功能和行为。例如在系统中，控制平面位于独立的处理器/线卡上，而数据平面在其他独立的线卡上，为了系统的故障恢复和容错，围绕这些组件之间通信需要有某些操作。如果控制平面从机箱中移走或者放置于更远的位置（例如逻辑上或者严格的集中式控制平面），那么所有的这些通信机制是否还都需要，就会是很值得探讨的问题了。

首先从基本的数据分组转发的概念开始讨论。当控制平面要求数据平面转发数据分组时，数据平面听得到指令吗？当数据平面正在忙于处理每一个它所接收到的数据分组时，数据平面能听得到指令吗？更具体地说，是否存在流量被引到黑洞7（即，在不同厂商实现的硬件转发系统中，分组被丢弃而无从知晓）？这个问题和控制实体/ 程序是集中式的还是半集中式，或者是分布式的（即与其他网元设备的控制平面之间是同步式的），都是无关的。在这些系统中，对转发表的分发错误的检测功能可以嵌入到数据中（例如转发表的版本控制），或者嵌入到转移机制中（例如使用某种形式的哈希或者从表的内容产生的cookie 来给转发表签名）。这样的机制可以确保分布式转发表的软件版本及时同步，而且万一出错可以被纠正。同样，在路由表的软件版本和硬件版本之间的校验例行程序，可在存储器的驱动软件中实现（针对特定的转发硬件）。

7.黑洞发生在控制-处理- 生成中产生的转发表版本之间存在矛盾的时候。大部分设备中转发表通常保存在DRAM 中（通常称为基于软件的转发表），或者与同一设备内的对等（或者从属）处理器上的软件转发表不一致，或者与从软件转发表所创建的新的硬件转发表不一致。后者在写到特定的硬件关联的存储器时，通常需要一些转换或者“包装”。可能在转换或写入中出现驱动级的错误，或存储器的软错误，这些可导致表项的不完整或不正确（最终导致转发时由于表项不正确而丢弃报文）。某些“黑洞”问题也产生于通过组合多个分离的表来建立转发表项的系统中低效的/ 不同步的表更新算法（例如，如果到某个目的地的下一跳的硬件地址在邻接表中不存在，还继续使用存在于路由表中该下一跳的一条路由，就将导致转发表项的“不可解析”）。

一些厂商实现了采用例行程序来对硬件表项进行事后校验，即在控制平面对数据平面编程之后，才检查转发芯片及其附属存储器的软故障。在这种情况下，将会有相关的例行程序去标记坏的存储块、移动表项、建立引用表项。通常，这些硬件校验例行程序的运行开销很高，所以它们经常被作为后台进程（又称“清道夫”）执行。为此，搬迁和内存读写例行程序也通常通过批处理或块处理技术来优化以降低运行开销。

一些多槽/ 多线卡的系统设计为两级查询，在入口第一级仅简单标记出口的槽位/线卡，然后在出口那里执行第二级的查找。根据如何被实现，两级查找可以做到如下这样的一种优化，即允许一种被称为本地化的技术来减少出口FIB表的大小。在此情况下需要注意的是，两级查找的“异步损失”的场景有可能会发生，并且除非它们失效了，否则很难检测到，这些与SDN转发控制是相关的。

在图2-5 的左半侧显示了一台在做两级查找的多槽路由器/交换机。当链路A-B出现时，在线卡1 内的FIB入口查找的结果就从线卡3变到了线卡2。如果对线卡2的更新发生在线卡1和3之后，则在出口上的第二级查找就会失败。类似地，在SDN环境中（显示在右半侧的云中），如果在这些系统上，连接A和B的隧道（分别地）从接口3变到接口2（由于管理或者网络事件），那么随后在这些网元设备上，流量从1-3转到1-2的映射就需要通过SDN 控制器（即图中的CP）上的应用来同步。

图2-5：两级查找法的异步损失

当本书后续讨论集中化控制平面的一致性问题时，将会进一步探讨所提到的这些迁移技术/优化。

2.2.4　为什么控制平面与数据平面分离变得重要

控制平面和数据平面分离不是一个新的概念。实际上，在过去十年中研发的任何多槽路由器/ 交换机都具有运行于专门处理器/ 板卡上（为了实现冗余，通常是两张卡）的控制平面（即其大脑），并具有独立地运行于一张或多张线卡上的数据平面的交换功能，每一张线卡都有专用的处理器和/ 或分组处理器。图2-6 通过路由处理器引擎说明了这一点（在图2-6 中表示为路由处理器方框）。

图2-6：控制和数据平面的实现样例

在图2-6中，数据平面的实现在下面的方框中，都是分离的线卡，带有端口处理专用的集成电路ASIC芯片来连接此线卡的入端口和出端口（即以太网接口）。在正常的操作下，图2-6中的端口带有转发表，它指示了如何处理带内到带外的接口交换。这些表项被路由处理器的CPU/控制平面程序所设置和管理。当控制平面消息或者未知的数据分组到达这些接口时，它们通常会被推送到路由处理器做进一步处理。可以认为路由处理器和线卡通过一个很小的但是高速的内部网络连接起来，实际上现代交换机就是这么设计的。

除此之外，协议按照此结构来设计就可以优化和提高其性能。例如，多协议标签交换（MPLS）协议使用IP协议簇来承载控制流量，这样可以理想化地在通用CPU上运行专用路由处理引擎；而MPLS的固定的基于标签的交换功能最适于采用各个线卡上的简捷的但是相当高效的分组处理器来实现。

在SDN被人们讨论之前，控制和数据平面分离的距离范围是在大约一米的距离（在同一个机箱之内，或者直接相连的多机箱系统内）。在前面各节中描述的控制平面和数据平面，虽然是分布式的，却是作为紧密集成的（并且相对紧密地放置在一起的）硬件和软件的组合进行搭建和管理的。除了这些组件和非常多的对系统外部观察者所隐藏的内部结构外，对这些组件的包装结果导致了利益驱动的网元设备利润。这些网元设备经常在相同的硬件产品线之上进行开发，以基于服务、管理、控制和数据平面之间的平衡为设计的着眼点，并在吞吐率（以及复杂性）上有所变化。这种 多平面间的紧耦合导致的互相依赖产生了一些围绕革新、稳定性以及规模问题，而规模问题最终可导致上述所有领域的性能问题。然而，解决这些问题由于非常复杂因而开销高昂，这是SDN 出现的一个方面的原因。本书会从读者的着眼点讨论每个组件，这种讨论可以看清其所带来的每个问题，亦或是其所带来的各种益处。

1. 规模是重要的

路由和交换系统的可扩展性问题可能会以各种各样的形式存在，并会涉及各方面的问题，举例来说，可能从原始数据分组转发性能到电能消耗。最终，这些扩展性问题将在开销和性能之间做出平衡，具体说明如下。服务板卡受限于板卡的更新换代来支持特定数量的预订者/流/服务。这是由于服务板卡（特别是那些使用特殊的嵌入式CPU）不得不使用特定厂商的系统互连和交换矩阵8。在新型号系列处理器（或者是板卡当前使用的型号系列里的新处理器）的推出，与服务板卡能真正获益于该处理器的升级之间，就存在着很大的时间差距。最重要的是要花费相当多的时间来做额外的定制化设计。令人遗憾的是这将导致系统成本的增加。

8.这里的术语“交换矩阵”（fabric）是泛指的，因为有很多技术都可以用于互连一个多板卡的网元设备的刀片/主板/板卡。

对于特定一代的转发芯片，其转发板卡支持特定规模的转发表项，但是其中某些板卡相对于主控板上的控制处理器，具有自己独立的本地从属处理器或者协处理器。但这些处理器也有本地处理的一些限制，例如，在某些设计中，在转发板卡CPU上运行数据流采样，可能导致本地CPU 使用率上升，因而消耗系统的CPU处理资源。控制板卡9内存能处理一定规模的路由表或者其他状态，并受限于板卡上CPU处理能力的更新换代。但是内存也用来存储控制协议状态和管理信息，例如BFD或者SNMP。所以对于此类设计存在一个基本限制，也就是说，可以买到最快的内存， 但这也是最昂贵的。

9.根据设备的类型（路由器或者交换机），这可能更通常地被称为路由处理器或者主控卡（不同的厂商有不同的名字）。在那些不是基于多槽机箱设计的设备上，这可能只是子卡上的一个控制处理器，或者甚至是集成在设备的一张主板上。

2. 演进

因此，过去网络运维人员不得不依靠硬件升级的方法，来解决控制平面扩展或者处理性能相关的问题。而与此同时，运维人员需要关注转发板卡扩展性以及性价比，并在合适的时间进行升级。虽然在高度专用的平台解决方案中，它与控制平面分离的讨论更相关，但它必须在服务板卡和转发板卡之间的比率中做出平衡，这可能严重缩减设备的整体转发性能（将转发插槽用于服务插槽）。设备厂商试图改善这种情况的一个方法是通过分离控制和数据平面，以便它们能独立演进和扩展，或者至少比它们组合起来要好。

SDN推动的对于传统设备演进上的改变在于，虽然在控制以及服务平面仍然存在一个“增长/扩展-升级”的周期以适应扩展性，但在商用现货（COTS）计算环境下却很容易实现。在云计算推动的环境下的创新尤其是这样。把控制平面从管理过程中分离出来，进一步造成了一定程度的扩展性影响，这个问题可以通过在路由器/交换机内的COTS 硬件或者远程运行这些用户级的进程来解决10。

10.网元设备的操作系统设计已经得出一个共识，即管理进程可以与控制进程（路由/转发）分离，但仍然可以基于发布订阅模式为控制进程提供服务。这类隔离后的管理任务包括目录管理、环境管理、低级日志、告警处理，以及其他来自控制进程的机箱管理任务，同时使它们仍能保持对转发相关事件（比如某个转发板卡的重启动）的感知。

硬件转发组件将会仍然沿着其自身的升级周期规律来应对转发规模的扩大，而不用考虑控制平面（即路由处理器）的配置。来自转发平台带宽/ 吞吐量需求的升级，是正常的汇聚模型的一部分，即大部分较低速转发组件放置在靠近网络边缘的位置（当它们的功能变得更加通用时，这会是潜在的更为可能发生的场景）。图2-7对此进行了说明。

图2-7：将集成在一起的管理平面、控制平面、服务平面和转发平面分离，使它们都能独立扩展

3. 成本开销

虽然这是个吸引眼球的字眼，但和其他推动控制平面与数据平面分离的因素相比，关于成本开销可说的内容相对较少。成本开销由资产部分（投资成本CAPEX）和运营部分（运营成本OPEX）组成。成本开销由这些因素推动：规模（投资成本的推动力）、复杂性和稳定性（运营成本的推动力）。首先从关于投资成本的显而易见的陈述出发，对于众多客户（特别是运营商或者运营数据中心的大型企业），和他们的网元设备处理开销相比，通用计算（采用了COTS）的处理开销是非常小的。而采用SDN 的集成服务，与控制板卡相关联的集成开销会导致某些成本差额。坦白地说，成本差额在某些情况下也由厂商的利润期望所推动，这些厂商采用的是非单独授权的操作系统（控制、管理和服务处理）。这是一种追回他们知识产权的投资，并为正在进行的维护和开发提供资金的方式。

这正是后续话题的微妙之处。虽然SDN无疑能缩减成本中的硬件集成部分，但厂商的知识产权（控制或者服务）正是可以被重新定价，成为厂商视为真正有价值的部分（这还有待被市场检验）。而且，集成成本将被算入软件组件中11。

11.虽然期望的是对组件的松耦合，以及在互操作性/可替代性上达到高度信心的开放标准，但也可能带来集成中保证的新特性的兼容性管理上的组合。

4. 创新

带来创新性的收益是控制和转发平面分离优点的一个论据（当考虑到服务平面也会分离时，这一优点的说服力就更强）。理论上来说，分离能够给用户带来收益，通过改变软件分发模式，使得任一平面都能互相独立地进行升级更新（相对于当前模式，即每个平面的升级更新，都受限于多平面集成的整体更新升级周期）。

与控制/数据分离更有关的能力是支持在转发平面中引入新的硬件而不必去更新控制平面（例如，通过在控制平面安装新的驱动程序，来适应数据平面设备的物理处理的更新）。

5. 稳定性

当本书在讨论SDN环境下这些平面的分离时，可能会存在一些问题，即一些控制平面的子部件不能被集中化，而是采用本地代理（可能多于一个）来接受对转发的修改，并向中心控制点反馈聚合后的管理信息。如果不考虑这些现实问题，通过分离控制和数据平面，由于得益于更小更稳定的代码库，转发网元设备可以变得更加稳定。这一假设前提：较小的代码库更稳定，在目前是被普遍接受的。例如一个相关并且流行的关于SDN优点的说法，来自于推倒重来的全新的主张。该主张假设在一些领域，比如多协议标签交换（MPLS），循序渐进的软件功能开发工作，通常会沿着一条通过增加已有代码来升级功能的道路缓慢进行。这种开发方式会导致复杂性的增加以及底层上的脆弱。研究结果表明，实现使用集中式的标签分发，来仿效分布式的LDP或者RSV 协议，以及集中式的网络拓扑信息获知，其代码量可以比当前可用的商业代码库至少减少一个数量级12。通常认为在一个高度规范和集中式的控制系统中，网络行为是完全可以类似于静态转发，按理说这会是很稳定的。

12.这里所引用的斯坦福大学的文献可以在网上获取。虽然这项研究推崇的SDN 的那些方面在本章的讨论之外，但该研究的根本前提之一就是：代码越小，系统就越稳定。

6. 复杂性及其导致的脆弱性

使用多少控制平面，以及这些控制平面放置于何处，这个问题直接反映了网络的规模、性能和可恢复性。对于缺乏可恢复性，本书中称之为脆弱性。特别是网络运维人员会在一个网络内，规划和部署足够的设备，来处理一定比例的峰值需求。当使用率达到峰值时，必须部署新的设备来满足需求。在传统的路由和交换系统中，有一点非常重要，就是要知道，在网络内不增加被管理的设备，及其相应的控制协议实体的数量的情况下，网络究竟能满足多少本地的转发吞吐量。从上述论述中可以看到，在交换机和路由器设计的通用模型中，将使用完全分布式控制平面模型，这就意味着对于每一个部署的设备，都需要在机箱内启动一个控制平面的实例，来控制机箱内的数据平面。接下来的问题是：对于网络收敛问题（即整个运行的控制平面，达到无环路的一致的网络状态所需花费的时间），这个额外的控制平面是如何影响整个网络的控制平面的规模的？回答是：它确实影响了整个系统的可恢复性和性能，并且控制平面的数量越多，系统就越会存在脆弱的隐患。如果调整系统，它也能增加抗脆弱性，但这样就最终会变成不能与外界条件变化保持一致的系统。简单地说，在分布式或者最终一致性控制模型中，交互协议的数量过多，会引起管理和运营的复杂性。

起初，通过建立单机设备的小型系统集群，来减缓控制平面的增长。集群的每个单元，通过通用的机箱之间的数据和控制的交换矩阵黏合起来。通常交换矩阵的实现是小型的、专用的交换式以太网。多机箱系统又前进了一步，通过在机架间提供互连交换矩阵，因而使多机箱系统作为单一的逻辑系统来运作，被单一的控制平面所控制。机箱之间的连接，也可以通过外部（网络）端口互联来实现，集中式控制平面是使用多个虚拟控制平面实例，即每个机箱内一个虚拟控制平面来实现的。由于它对网络运维人员只显示了单一的IP 地址，所以它可以作为一个逻辑实体被管理。图2-8对两种方法进行了展示。

图2-8：集群和多机箱系统设计

在图2-8的集群和多机箱系统设计中，由一个互连的控制用的以太网（通过冗余以太网交换机实现）连接的外部控制平面，允许外部控制协议分组流在线卡（端口）机架的处理器和控制处理器（例如路由引擎）之间进行转发表更新和设备管理。

目前业内开发了两种策略来实现这些系统的控制。第一个策略是在机箱中（处理部署位置）多个控制点之间，将处理功能进行分布式设计，从而更加充分地利用处理能力（以及扩展规模），或者在一个外部控制系统（被连线到系统的控制交换矩阵里）集中化处理。第二个策略是潜在地把扩展点转移到一个更加模块化和技术上更快移动的设备上（这些通常是一个集成的交换和计算设备，不需要特定的形式、母卡架构、或私有交换矩阵接口）。

应该注意到多机箱或者集群系统中，尽管还没有解决控制平面的可编程性/灵活性问题，但后者仍旧具有某些SDN 的特点（控制平面集中化和更独立的扩展）。

对于在减少设备中建立转发状态的协议和协议交互的数量方面，还是有潜力可以挖掘的。图2-9显示出在一个IGP/BGP/MPLS网络中的进程交互，通过学习/宣告地址前缀和标签绑定，来在数据平面上安装转发表项。

图2-9：在一个IGP/BGP/MPLS 网络中的进程交互

2.3　分布式控制平面

随着互联网的发展，最终是随着网络规模的发展，控制模型演进为分布式的、最终达成共识的模型。在这个模型中，每个独立的网元设备或其代理都参与分发网络可达性信息，用以创建一个一致的、无环路的本地网络视图。本书中称这个模型为“最终达成共识模型”（或称为最终一致性模型）。对于任何超过小型家庭规模的网络都形成了一个相当复杂的网络拓扑，造成分布式控制模型中固有的网络可达性信息更新的传播延迟。这个模型固有的“间歇性非同步”（intermittent no synchronization），尽管会导致次优的转发路径，但也可以在整个路径中避免或限制短暂的环路，这称为微环路（micro-loops）。图2-10说明了这个概念。

图2-10：路由状态的最终一致性

观察左边的用云表示的网络，以及三个节点（A、B 和C）。在时间=0时，这个网络状态是不一致的、带有环路的网络。在这种情况下，数据分组如果传输的话，可能会绕圈子，因为在节点A和B 的转发允许流量在它们两者之间转发。然而，在时间=1 时，图右边的云所表示的节点A 和B 知道它们之间的链接已断了。在网络的节点之间的路由消息的更新完毕前，网络会维持几分之一秒钟的不稳定，这就是最终一致性的理念。

2.3.1　IP和MPLS

IP和MPLS转发是分布式控制模型的例子。在这些转发模型中，为了对数据平面编程来实现这些路径，路由和网络可达性信息被交换。关于IGP（域内路由协议）操作的书已经有很多，也有大量免费提供的IETF草案和标准，所以本书将不会深入这些模型的细节。然而快速的概括性介绍，将会带来一些关于这些特定模型的相对优点和局限性的讨论，以便更好地理解有关控制和数据平面采用分布式的某些SDN概念。

2.3.2　建立IP承载网

目前IP 控制平面模型的基础是使用IGP协议。这通常采用链路状态协议的形式，比如OSPF或者ISIS。IGP 通常被用来在实现IP 转发的网元设备之间，形成无环路的拓扑互联，建立网络可达性。

一旦配置好后，IGP协议和外部配置的邻居就建立了关系，并且管理控制协议会话、交换可达性信息（例如NLRI 或者路由状态）。随着基础架构安全意识的发展，对邻居关系建立和协议有关数据的接受都要有内在保护机制。

参与交换的网元设备，在状态数据库中的保存和累积，来自于其他节点的宣告（例如OSPF数据库），并且针对数据运行最短路径算法，来建立以自我为中心的最优路径的可达图。这些最优路径被送给了RIB，此外还有运行在相同的网元设备上的其他协议对RIB的贡献。

网络事件就是这些关系（邻居）的丢失/建立，或者一组链路的可达性的丢失/建立，这里链路虽然与网元设备没有邻居关系，但却嵌入在宣告的网络可达性信息里。

这些事件使用协议内所定义的分布式泛洪算法来传播，这样一个域内互相（直接地或者间接地）保持连通的，所有运行了某种特定控制协议的网元设备，就最终可以看见并处理这些事件了。

在上述网络里，控制平面状态的规模问题，可以通过物理和逻辑设计来解决，使用的工具包括递归、汇总、路由过滤和（物理的/ 逻辑的）划分。为了处理支持IGP邻居数量的通用规模问题（指可以被处理的事件数量、链路状态数据库的大小，或者其他状态结构，以及/ 或者其他相关实体的规模），网元设备可被物理上或逻辑上划分成区域，或其他IGP分层。在区域边界，运营商（如果可能）可对来自其他区域的网络可达性信息的汇总信息加以控制，或者对跨越区域边界的网络信息进行披露。

为了宣告跨越管理边界网络的可达性，或者携带网络可达性数据集13。尤其是那些代表了更多抽象的不同地址族，比如不是在IGP中传送的那些横跨网络的虚拟专用网络，其IP控制模型典型地使用边界网关协议（BGP）。与控制平面的IGP部分类似，邻居之间建立了对等关系，像IGP一样交换邻居的BGP 数据库的所有信息，或者任何子集的信息。由于网络可达性信息被划分到各种地址族，因而上述情况就可以实现。

13.BGP已经发展为一个高度可扩展的数据库和数据库交换协议。

这个信息通过递归，使得在控制和数据平面里更易访问和扩展。递归允许网络控制平面使用不同协议的不同属性来分发信息，通过一系列共享字段将这些协议的信息链接起来，如图2-11所示。这项优化的例子是，大量的BGP NLRI信息（网络层可达性信息），可以用IGP数据集合里的单个IP 目的地址来表示（或者如果运营商使用控制平面协议特性，允许多条最优路径到达目的地，或者有多条等价路径到达宣告的实体，则用一个地址集来表示）。当控制平面为数据平面建立表项（FIB）时，BGP信息就被关联到了无环路的IGP图的信息之上。

图2-11：路由递归

在数据平面，递归最终通过IGP“下一跳”，将BGP前缀解析为对二层转发表项中的邻接关系的一个指针。这个转发表项最终用于目的MAC 表项里表示路径下一跳的路由器/交换机接口。

在外部边界，通过多种策略工具的使用，运营商具有额外的对控制状态的汇总和宣告的控制。在IP 模型中，允许在为数据平面转发所选的控制平面数据集之上有一些额外的、本域的控制。标准化的或运营商私有的14操作，是允许本地策略来控制学习到的网络可达性信息的优先级。

14.RFC1104 给出了策略路由模型。

例如，这些工具能通过一条静态路由表项，本地重分发到一个动态路由协议里，或者在重宣告之前修改一条前缀的属性，来间接为了某条特定路由状态来影响邻居的优先级15。如果在RIB中不存在该路由，或静态路由具有较高的管理优先级，那么非重分发的静态路由，能影响本地路由选路。每个协议表中地址前缀的优先级，由该协议的规则所控制，RIB被不同协议表之间的管理优先级所控制，但最终FIB中的转发选路，会对目的地址进行地址前缀最长匹配。坦白地说，IGP/BGP递归和策略工具的组合变得很复杂，但这却正反映出现实世界中控制平面是如何被管理的。

15.可以说，这个处理对BGP特别有用。

就像在现代路由器/ 交换机中的配置单元一样，对于可能影响控制和数据平面结果的配置，可以被集中式地管理，然后推向分布式的网元设备。这种机制会被一些问题所困扰。这些问题就是推动SDN变得流行的动力，即SDN控制器的可编程特性是，服务开通的代理、解决配置提交过程缓慢的问题的控制点，以及解决厂商之间CLI语义和数据模式不一致性问题的控制点。SDN最终能带来的改进之一就是解决对网元设备的编程控制所固有的操作缓慢问题。

对于许多网络运维人员，控制将会影响转发选路结果的灵活性和简单性（以及可编程化）。例如，人们除了通过算法获得“最佳”之外，还可以通过更多的知识或需求，来使网络变得更加灵活和高效。在大多数实现中，静态路由和路由策略都有一定的可扩展性问题。

2.3.3　收敛时间

IP模式中的FIB（或者数据平面转发状态表项）已经经历了多年的软件设计与遍历（查找）算法的优化。在这个模式中，收敛和负载均衡对于网络运维人员/设计者就像前述的黑洞一样，是重要的焦点。收敛是指，从某个网元设备上由于网络事件而引起目的地可达性变化开始，到这个变化被所有其他网元设备都知道，并实际起作用为止，所花费的时间。可能对读者来说，最熟悉的收敛时间的某个组成部分，就是对某个更新的传播延迟。这通常是从最初发生变化的节点，到重泛洪/重传播的中间节点的跳数数量，来度量平均距离的关联函数。收敛的其他组成部分，将关注于本地更新过程，例如更新RIB的操作，以及在数据平面进行更新FIB等实际起作用的操作。

为了优化协议层面的收敛过程，以及传播/泛洪机制，每种协议都有不同的内部时钟，用来为协议产生各种类型的事件。例如产生与邻居之间“hello”消息的时钟。IP网络的奥秘之一就是，在特定网络设计中，如何优化协议时钟的最佳实践的知识。今天，许多这些设置都在各种协议最流行的实现中，被内部设置为默认值。看看那个发送大量数据给很多对等体的BGP协议是如何做的，就很有趣。不同的厂商都通过采用不同的消息更新打包格式、更新优先顺序、对等体更新分组以及其他内部优化，来减少冗余更新消息的产生、提高路由或者控制平面的收敛速度，和提高网络更新信息的传输效率。

为了优化对FIB的更新，不同厂商为FIB 递归性质的关键组件（例如BGP下一跳）开发了路由表组织策略和事件驱动的反应策略。这些优化将因响应网络事件而发生的对FIB改变的数量和类型，进行最小化处理，从而将收敛时间降到最小16。这些最优化处理，使得在某些类型的硬件上执行每秒成千上万的更新成为可能17。

16.例子包括下一跳跟踪和协议独立的收敛。
17.结论来自对Tier 1 运营商网络上RIB/FIB更新优化的研究。结果随厂商而变化，要根据地址前缀分布和故障场景而定。2010 年的一项研究显示，对于大约14 000个地址前缀，收敛时间的范围在0.7~7秒之间（依赖于IGP 地址前缀的百分比，尤其是/32地址前缀掩码长度——以及假设长原始RIB/FIB 地址前缀更新时间对于每个/32地址前缀小于300 微秒）。

2.3.4　负载均衡

分布式IP转发的负载均衡已从对逐包的处理，发展到对IP 分组头更多部分进行哈希处理。这是因为越来越多的用于语音或者其他媒体18的不同数据流，开始被网关设备所处理。不过可能是为了某种目的的非等价路径，负载均衡通常被用于等价路径，或者捆绑的点到点电路。负载均衡算法的实际效率受限于计算的算法本身，以及可能会遇到的潜在的数据流大小的失衡。这会导致装箱效率问题（bin-packing efficiency problem）。在极端情况下，最终将导致等价路径的数量或者实现支持的绑定成员的数量方面的限制。

18.当前某些厂商实现了具有七元组负载均衡哈希的能力。

2.3.5　高可用性

分布式IP环境中的高可用性通过如下多种机制来提供。

- 网络级的冗余（也就是“每样东西都有两个”的方法，网络设计中冗余路由器/交换机和冗余路径允许存在链路或者网元设备的故障）。

- 网元设备级的冗余，使用冗余的路由处理器/ 交换控制模块。冗余处理器可以工作于无状态的主用/ 备用模式（通常意味着如果没有其他路径时，转发会中断），或者带运行状态的控制处理数据的镜像模式（例如不间断路由技术）。

2.3.6　建立MPLS叠加

按照SDN的讨论，MPLS是在数据分组包头增加一个封装，使IP网络运营商可以在IP网络（承载网）之上建立叠加网或者逻辑隧道，如图2-12所示。标签本身是24位的，这意味着有1 048 575 个标签（标签0到15被保留），如图2-13所示。

图2-12：在OSPF 多域承载网之上的MPLS VPN（通过路由反射器分发VRF标签）

图2-13：MPLS 标签

标签可以采用LIFO（先进先出）的顺序来堆栈。标签堆栈允许建立跨越网络的多服务或隧道，它们是今天网络叠加的先驱。

- 相对于IP转发，单一标签能够在标签表中快速查找。

- 两个标签可建立隔离的抽象层，就像VPN，外部标签快速查找到具有多虚拟实例的网元设备（VRF），它的判决器就是内部标签19，如图2-14 所示。

图2-14：建在MPLS TE核心网（OSPF路由提供的承载网）之上的MPLS VPN (通过路由反射进行VRF标签分发)

19.MPLS VPN 能在GRE 封装内使用MPLS 标签建立（如果所穿越的网络不支持MPLS 标记交换，那么本质上就替代了外层的或者IGP 的标签）。最近有提议支持用VxLAN 来封装MPLS 的类似功能。

- 三个到四个标签可建立通过（带保护的或无保护的）中间隧道的相同转发的抽象层，就像用VPN 构建流量工程隧道一样（带有或者不带有快速重路由保护）

就像IGP一样，关于MPLS操作的书已经有很多了，故本书不再赘述，但为有助于后续对SDN的讨论，在此对其进行概要描述。

MPLS操作的主要方面包括标签分配、地址绑定和标签分发，所有这些都由配置系统所控制。

- 标签分发协议是LDP和RSVP（以及BGP做为标记的单播地址族）。这些控制协议由邻居/会话所构成的操作进行信息交流。

- 标签分配操作通常是动态的，但标签的规模可以控制在某个数量级。有些厂商的VPN通过在每个VRF中分配或每地址前缀/每平台分配来实现。这些标签的分配是可以被排序的（但这不是必需的）。

- 标签分发操作可以是下游请求的（如RSVP流量工程20）或下游不请求的，即LDP协议的默认行为。

20.下游请求也是一种“无缝MPLS”实现的功能。

就像IGP一样，MPLS的控制平面操作的某些方面可以通过全局和本地来配置，也同样有前述相同的限制。这包括过滤标签的宣告、控制标签的保留策略、控制标签的范围、保留标签的使用和分发的能力。网元设备可以对标签进行的操作，除了转发之外，还包括推入（push）、拉出（pop）、交换标签（swap）、多次推入（multiple push）、交换并推入（swap-and-push）。从历史上看，并非所有的网元设备都能够执行所有的这些操作，而且也不是都能充分支持更深的标签堆栈。 MPLS部署时，数据平面的转发操作，从IP网的基于目的地址的最长地址前缀匹配，变为匹配标签堆栈里最顶端的标签。不过，转发路径依旧遵循计算出的目的地址前缀的无环路图。在更迅速查找的同时，由于加载了IP转发表和标签表之间的附加表和索引，也增加了复杂性。MPLS还增加了分布式IP 控制模型的整体复杂性。

MPLS流量工程隧道的某些应用允许运营商控制隧道的路径，因此可以使用普通的基于目的地址前缀转发所不能使用的区域。具有相同的下一跳地址的一类地址前缀称为转发等价类（FEC），MPLS 隧道为FEC而加载。FEC也可以是确定特定流的一组具体策略，或是基于策略路由的流的服务质量特征。

就像IP里的IGP一样，MPLS随着时间的推移而不断被增强，特别是通过创建标签交换子路径（sub-LSP）和均衡标签来支持多路径负载均衡。

2.3.7　组播复制

IP和MPLS的分布式控制同样适用于单播和组播，但它们都需要进行组播复制的独特的协议和数据结构。组播复制在一个相当长的时期里仅支持IP 网络，即从DVMRP开始，然后是MOSPF，再发展到PIM。MPL 网络，最近在VPN环境已经有组播技术的新进展（MVPN）。就像它们的单播亲戚一样，组播控制协议围绕规模、收敛性和稳定性进行优化，并努力避免黑洞和环路。在MVPN环境下，对在网络边缘的网元设备中，对复制分组的负荷进行平衡的问题得到了关注。同样，像单播协议一样，这些协议允许一定量的配置驱动的控制，也遇到了和单播IP协议和MPLS的基于配置的控制一样的限制。

2.4　集中式控制平面

集中式控制平面的概念不是“SDN 运动”专属的。实际上，控制的分布式模型存在的部分原因在于，近年开发的数据库的可用特征，在当时还不存在。因此，其所需的高可用性，以及为两个或更多个控制点之间的一致性保证所需的可靠同步，是难以实现的。

集中式控制平面的主要优点是，它可以向应用程序提供网络视图和简化编程控制。为了实现一个大网中的端到端的改变，应用程序不再需要知道，或直接接触各个网元设备，而是与几个处理这些细节的控制点交互。当前或历史上都有一些部分的或完全的集中式模型，尽管它们都不是SDN的解决方案，如在IP域里的路由服务器和ATM 里的交换机控制器21。

21.其他例子还包括语音网络里的七号信令协议SS7 和VoIP 中的媒体网络控制。

还有一个著名的产品化尝试，即Ipsilon公司，许多人认为是现代SDN的祖先22。他们的解决方案里有一个ATM 组件，尽管其价值实际上是IP 和ATM 组合的确定性路由23，ATM由于后来标签交换（tag switching）技术的引入，最终是MPLS技术的引入，而被边缘化了。

22.Ipsilon 公司的解决方案虽然不提供开放式编程接口，但提供一定程度的对网络操作的灵活性。
23.Ipsilon 公司在此主题上有至少两个有意思的IETF RFC，即RFC 1953 和RFC 1954。

还应注意的是，IETF也曾尝试完成一些目前被认为是与SDN有关的技术。这些包括控制/数据平面分离，如通过ForCES（RFC3746）和通用交换管理协议（GSMPRFC3292）。后者的颁布日期是2002年2月！

2.4.1　逻辑上的集中式与字面含义上的集中式

为了讨论集中式的控制平面，有必要把逻辑上的（logical）集中式与字面含义上的（literal）集中式区分开来。

下面这些因素让字面含义上的集中式控制非常困难，亦或根本不可取。

- 规模

中央控制器将支持与每个被管设备的控制会话。由于规模和网络增长的波动性，对单个网元设备的更新都需要增加针对每个会话的I/O和处理。附加功能，如通过通道收集分析或执行其他管理任务，也提供了一个额外的负荷。在某些时候，将负荷分割成更易管理的切片是有道理的。

- 高可用性

虽然控制会话的规模上的负荷可以通过一个单一的控制器来处理，但这样，该控制器就会成为导致整个网络失效的一个单点故障。尽管整个网络可以在一段时间被配置为操作上“无控制”的，但某个时刻发生的其他网络故障或变化也需要与控制器相互作用。如果控制器届时仍未恢复，这将会是一个问题。最简单的高可用性策略将允许控制器主用和备用结合。

- 地域

在一个数据中心内，几乎所有的管理都是比较靠近的，即使数据中心跨了多个城市街区或有多层楼那么高。如果控制器与所控制的网元设备在都市、州或国家级的网络上分离，那么传输延迟就会开始影响运行效率了24。更大的地域也增加了分区的风险（网元设备与控制器分离的分区）25。鉴于这些因素，一个逻辑上集中但物理上分布式的控制平面似乎更有意义。这个概念也就是围绕在物理分布的控制器之间进行同步状态的某种形式的“联盟”（federation）协议。

24.特别是当状态更新需要确认时，就变得更为重要了。这种更新当然是必需的！
25.一旦控制器与其所控制的设备不放在一处，“双刃剑”就随着对SRLG（shared risk link groups，共享风险链路组）和其他物理上的危害等问题的关注而出现了。

2.4.2　ATM/LANE

异步传输模式（ATM）是一种面向连接的信元交换和复用技术（已通过国际电信联盟ITU-T 标准化）。像前面描述IP和MPLS时一样，这里仅给出对ATM 协议的常规（非穷尽式的）描述（侧重于与SDN 的讨论有关的部分）。

大多数ATM 的功能是通过静态服务开通配置的，支持两种类型的服务：静态电路（永久虚电路）和后来发展的动态电路（交换型虚电路）。交换型虚电路SVC 是这样的：使用信令协议，在端点与交换机之间，通过一个众所周知的通道（一对虚路径标识VPI 和虚信道标识VCI），来动态建立（和断开）。

通过为端点使用支持子网的基于网络服务访问点（NSAP）的地址模式（独立于高层协议），ATM 呼叫控制（电路设置采用电话呼叫建立的模式）或路由是基于源/目的NSAP 地址、流量和所需的QoS 的。虚电路可以采用可变的比特率（Variable Bit Rate），或根据服务质量属性26操作的承约比特率（Committed Bit Rate）。

26.这些QoS 的属性包括：峰值信息速率（Peak Information Rate），承约信息率（Committed Information Rate）、承约信息大小（Committed Burst Size）和过量突发大小（Excess Burst Size）。

许多网络后来都转向使用类似IP环境的动态分布式路由协议（ATM论坛的标准的专用网间接口协议PNNI），来进行NSAP与VPI/VCI映射的发布。

局域网仿真（LAN Emulation，LANE）是ATM论坛定义的一个规范，它使ATM网络给高层展现出如同以太网（或令牌环）所提供的相同的MAC层服务接口。LANE在ATM主机那里提供的接口，与真正的二层设备（例如带ATM网卡的以太网交换机）与ATM交换机之间的接口是不同的。关于LANE协议本身最重要的一点是，它创建了ATM承载网之上的对ATM交换机而言不可见的叠加网。要创建此叠加网，需要一些与ATM相连的、角色特定的服务器来作为控制器，如图2-15 所示。这些作为控制器的服务器就是图中的LES、LECS27和BUS。

图2-15：以太网仿真LANE 中的客户机和服务器

27.原文这里写的是LEC，考虑到这里是说服务器，所以应该是指LECS，原文应该是笔误。——译者注

- LES（LAN Emulation Server，LAN • 仿真服务器）提供MAC 地址注册功能，并作为LEC（LAN Emulation Client，局域网仿真客户机）的控制服务器（每一个所仿真LAN有一台），本质上就是LANE的ARP服务器角色（LE-ARP）。LEC是主机（或网元设备）上的MAC层和高层协议之间的协议接口。

- BUS服务器与LES服务器是配对使用的。BUS（Broadcast and Unknown Server，广播和未知服务器）是为被仿真的局域网处理BUM（广播、单播、组播）流量的一个组播服务器。

- LECS（LAN Emulation Client Server，LAN 仿真客户端服务器）维护一个域范围内的LEC 与所仿真的局域网之间的映射关系的数据库，也维护局域网地址解析的查询点（即提供服务于被仿真的局域网的LES服务器的ATM地址）。

- LECS 服务器的地址是在ATM交换机上手动配置的，终端站点发现LECS服务器方式有两种，或者通过一个众所周知的ATM 中用于LECS服务器的NSAP地址ILMI，或者通过与众所周知的信道（由“VPI/VCI 对”所标识）连接。客户端通过双向的直接控制的VCC（虚信道连接）与LES服务器连接，通过双向的直接配置的VCC与LECS服务器连接。客户端作为一个点对多点的VCC的叶节点而连接到BUS服务器上。

在第6 章中，数据中心服务编排中的叠加技术的基本概念以及其他更现代的承载技术，与上述介绍的内容有惊人的相似之处。

虽然ATM在其数据网络中的作用已经褪去，但在控制器/客户机环境中出现的高可用性和状态维护的最早商业应用之一，就是在LANE 里。事实上，LANE 的1.0版本里还没有冗余备份。

后来推出的SSRP机制为LECS服务器建立了一个逻辑/ 物理的层次化结构（优先建立LECS服务器之间的VCC树），允许交换机在最初的LEC发现机制中提供多个LECS服务器地址。LECS服务器层次结构使得只有一个主LECS服务器响应LEC查询请求，其他LECS服务器都用作备份（对主服务器的VCC 失效的备份）。

SSRP机制还允许使用一个优先级机制（提供到LECS的VCC连接，以进行LES/BUS的存活性测试）来达到一对LES/BUS 的冗余备份。

这种冗余方案给网络增加了显著的额外开销（大量的VCC仅用于控制），而且保持所有的LECS数据库同步的网络管理员的职责，还竟然是用手工进行配置的28！

28.LES/BUS 服务器适用于动态状态，当LEC从主LES/BUS服务器转移到二级LES/BUS服务器时有一个“再学习”的过程（思科公司的FSSRP协议试图解决这种LEC 在再学习期间受到干扰的问题，以换取更大的VCC规模和复杂性）。在一些实现中，用户被要求在所有ATM交换机上维护LECS表的顺序。

从SDN的角度来看，ATM交换使用静态和动态两种方式的控制（前者通过一个专有的管理界面来集中地管理）来创建底层承载网。控制不是采用编程方式的（厂商提供的私有的服务开通配置系统作为整个管理系统的一部分，并且没有真正的外部API）。LANE提供特定类型的逻辑叠加网，由多台服务器（或类似控制器这样的功能）来支撑。这些服务器的功能中虽然没有提供编程接口，但提供了最基本的高可用性特性。

2.4.3　路由服务器

路由服务器（Route Server）演变为互联网服务运营商用来处理BGP对等体（peer）的规模，以及处理外部BGP对等点策略的一种手段。另一种略微不同的机制是路由反射器（route reflector），由于被用于处理内部对等体而标准化了。

如图2-16所示，Route Server是一个基于外部边界网关协议（eBGP）的控制点，通常位于所有作为独立的自治系统（autonomous system）的各方所共享的网段，用来从每一个参与方接收控制状态更新（即网络层可达性信息NLRI），把各种过滤和各种策略应用到这些更新上，然后根据这些最后结果的数据，计算出最佳路径（这可能与在中间策略步骤计算出的BGP最佳路径不同），并为每个参与方创建一个RIB（即把计算结果返回给参与者29。Route Server对于像AS Path这样的BGP属性是透明的，每个参与方只需要一个BGP会话进行信息交换。

图2-16：Route Server 体系结构

29.著名的例子包括Quagga（GNU Zebra 的一个分支）和BIRD。

Route Server 可以连接到路由注册处（registry）30。注册处是路由对象（自治系统号ASN、策略、前缀、认证信息）的分布式存储，它提供一个工具集，可以使独立的对等体（边缘路由器）和Router Server做到自动服务开通配置，如图2-17所示。

图2-17：IRR31和Route Server的互通

30.RIPE IRR 就是这种注册处的例子。
31.原文是“IIR”，属于原文的笔误，图中明显是与互联网路由注册处即IRR 的互通。——译者注

路由反射器为内部的BGP 对等体提供了类似的服务，它是一个更透明的服务（如术语“反射器”所暗示的），提供有限的中间策略插入，以及一组更严格定义的行为32。

32.由于路由反射器在运营商网络中的重要性不断增长，改变反射器定义 标准化操作的能力已经出现（例如，向iBGP的client 路由器宣告不止一个最好的路径的能力、宣告next-hop-self属性的能力。nexthop-self是指eBGP路由器向iBGP路由器宣告时可以给出下一跳为自己的路由器接口地址）。

使用路由反射器的一个很好的例子就是，VPN服务专用的路由反射器，可以为所有VPN边界路由器消除负担，即不必再创建和维护全网状链接的BGP会话来交互VPN地址族的NLRI信息，如图2-18所示。路由反射器也支持高可用性（集群）和层次式分布。

图2-18：对地址前缀11.11.11.11/24 的路由反射：该地址前缀从一个客户路由器，穿过反射器的层次结构，最后被发送到所有其他客户路由器

这两种设备都提供了一个集中化的控制点，厂商可以潜在地在这里注入路由状态。许多运营商都在这样的控制点上用自己的脚本化/ 自动化的接口来提供VPN服务、减轻DDOS攻击（针对注入黑洞路由或吸收路由的攻击），并执行其他任务。

由于这些设备是通过标准的、提供了域间和域内的信息交换的控制协议（BGP）来通信的，因此它们很容易被结成联盟，并被同步，以完成在地理上分布。

从SDN的角度来看，今天的基于BGP的控制点的主要问题是缺乏标准化的可编程性。有人会说，RPSL（路由策略规范语言）是一种在Route Server里表示 编程BGP策略的标准。然而，RPSL 对广义的BGP控制点，例如路由反射器而言，就不是一个完整的/适当的解决方案了（因为缺少标准的、面向事务处理的API）。有些ISP使用内部开发的工具，来直接处理RPSL 数据库文件，并帮助实现文件中BGP协议控制的自动化。

2.5　小结

分布式控制平面及其“最终达成共识”的模型随着时间而演进，尝试解决的不仅是互联网总体上不断增长的规模问题，而且还有网络运维人员对一致性的担忧（黑洞和环路避免）和快速收敛的问题。

在这个模型中，承载和叠加这些抽象的基本概念得到了广泛的认可（以IP转发和MPLS的叠加抽象为例）。

分布式控制模型的主要缺点在于：网络灵活性和用户控制（在共识的路径选择上缺少足够细颗粒度的控制以提供足够的灵活性）、可编程性（没有标准的API来注入状态或提取信息，目前大多数自动化或者是依赖于厂商的，或者深入嵌入了厂商配置/ 操作命令的语义知识），以及控制平面、数据平面、服务平面和管理平面整合的深度集成（带来了规模升级的周期和其他依赖性）。这个模型中的元素只是在最近才开始尝试与外部化的控制平面进行试验，以使路由处理器可以运行在更具可扩展性（和更易于升级）的计算平台上，也就是不再被在机箱内的处理器上创建特定的载体和交换矩阵接口这类的困难拖后腿。

可以说，通过IGP/BGP/MPLS互动的递归模型引入了许多复杂性和额外开销。然而，模型也演进出一些可提高收敛、高可用和黑洞回避等运营商很想要的机制。

采用逻辑上集中但物理上分布的模型对控制平面进行集中化，从规模、高可用性和地理位置的角度看是有道理的。

SDN的倡导者们可以学习一下历史上对集中化的各种尝试。本书中所提供的两个例子是：ATM LANE（这是是真实的，历史上曾经使用过的）和Route Server（在IP转发领域目前仍然在使用）。

LANE 系统的服务器展现了人们对集中式模型中高可用性的复杂性的第一次尝试。其高可用性模型还缺乏同步机制，往往需要用户手动地维护LECS数据库以使其保持特定的顺序。这些模型显著地增加了控制平面基础设施的规模（代价是服务器和网元设备存在着非常大量的VCC 虚拟信道连接）。

更现代的路由服务器和路由反射器为分布式IP 控制平面提供了一个集中式的控制点，这些控制点被认为是SDN 发展的“机会点”（将在第4 章中讨论）。这两个中央控制点都减少了分布式控制基础设施的规模。Route Server 提供了可编程性，但还不是用一种标准化的方式，而且没有引入任何更灵活或颗粒度更细的控制。同样可以这么评价路由反射器，许多运营商都在路由反射器上采用自动化以影响他们网络中的转发，尽管在Route Server 数据库之上有某些应用程序（例如WHOIS），但它并不直接向程序员提供额外的应用服务（例如并不提供网络拓扑）。

OpenFlow（以及其配套的标准组织ONF）的功劳在于开启了SDN 讨论，并迈出了现代化的SDN 控制的第一步：向控制器之上的应用程序提供集中式的控制点，提供网络拓扑的北向API、路径计算和开通配置服务，以及一个用于在一个多厂商的基础设施中完成转发状态的实例的标准化的南向协议。

不幸的是，OpenFlow 体系结构并没有（或还没有）提供一个标准化的北向API，也没有提供一个标准化的东西向的状态发布协议，以支持应用程序的可移植性和控制器的互操作性。这些工作的标准化，会在ONF 新成立的架构工作组中开展。

OpenFlow 为那些可以利用全套OpenFlow原语的平台提供了大量的流/流量控制。ONF 已经成立了一个工作组来解决对厂商硬件实现能力的描述/发现，以便厂商可以使用原语集来实现众所周知的网络应用模型。

尽管对OpenFlow实现的抽象程度以及是否最终其API将代表完整的SDN API等方面还有很多疑虑，但OpenFlow的应用，以及正在进行的围绕混合操作的努力（可能会使OpenFlow更容易地在传统的/分布式的网络里或在OpenFlow域与传统域间的边界上整合其匹配/ 限制流量的能力），是很引人注目的。

第3章　OpenFlow

原作者本章中给出了很多ONF 组织信息和OpenFlow 信息，这些均仅代表2013 年原书写作时的信息。因为ONF 组织和OpenFlow/OF-Config 协议标准近年发展十分迅速，这些信息需要更新的地方非常多，译者就不一一地指出其最新的进展或动态了。——译者注

3.1　引言

第2章对网络控制平面和数据平面进行了回顾。本章将关注仍在不断发展中的OpenFlow 提案和协议。OpenFlow 被许多人视为“推倒重来的全新设计”理论的先驱和SDN 讨论的发起者。本章还将讨论，就一般情况而言，SDN控制器如何实现网络的控制平面，并且接着有可能重塑一个运营商网络的面貌。

OpenFlow 最初是作为斯坦福大学网络研究的一部分而设想和实现的。它最初的重点是在校园网上创建用于进行研究和实验的实验协议。在此之前，大学不得不从头开始创建自己的实验平台。从这个想法的初始核心演变出的一种观点认为，OpenFlow可以完整取代商用交换机和路由器里的第二层和第三层协议的功能。这种方法通常被称为推倒重来的全新设计命题（clean slate proposition）。

在2011 年，一些服务提供商2成立了开放网络基金会（Open Networking Foundation，ONF） 这样一个非营利性组织， 来商业化、标准化和促进在生产网络中使用OpenFlow。ONF 是一种新型的标准开发组织，它成立了推动OpenFlow协议发展和其他SDN相关工作的非常活跃的市场部门。作为其工作的一部分，该组织每年都会举办被称为开放网络峰会的会议。

2.目前ONF有90多个成员，包括学术和政府机构、企业、服务提供商、软件公司和设备厂商。

从宏观角度看， 将人们的注意力集中在软件定义网络的现象要归功于ONF。OpenFlow模型的关键组件（如图3-1所示）已至少成为SDN 常见的定义的一部分，主要表现在以下方面。

图3-1：OpenFlow 的体系结构（有些控制平面的应用程序会在控制器之上，来模拟传统的控制平面应用的行为）

- 控制平面和数据平面的分离（对于ONF来说，控制平面是对逻辑上集中的控制器系统的管理）。

- 在控制器和网元设备上的代理之间使用一个标准协议，用于状态（在OpenFlow里，指转发状态）的实例化。

- 通过现代的、可扩展的API，以集中的视图来提供网络可编程性。

OpenFlow是一组协议和API，本身并不是一个产品，甚至不是一个产品的功能。换句话说，如果没有应用程序（可能不止一个）给出指令说明哪些数据流流向哪个网元设备（出于该应用程序自己的目的）的话，控制器就什么都不能做。

OpenFlow 的协议目前被分为两个部分。

- 一个是线路协议（wire protocol，目前的版本是1.3.x），用于建立控制会话，它定义了用于对流的修改（flow mods）进行交互和对统计数据进行收集的消息结构，并定义了一个交换机（端口和流表）的基本结构。其1.1 版新增了支持多表（multiple table）、对动作执行进行暂存以及元数据传递功能，这些功能最终在交换机内创建了逻辑的流水线（pipeline）处理，用于处理流程。

- 另一个是配置与管理协议of-config（当前的版本是1.1），它基于NETCONF（使用 Yang数据模型）来给特定的控制器分配物理的交换机端口，并定义高可用性（主/备机制）和控制器连接失败时的行为。虽然OpenFlow 可以配置对OpenFlow 的命令/控制的基本操作，但它还不能启动或维护网元设备（即还不能达到FCAPS级的管理，FCAPS 即即故障、配置、计费、性能和安全）。

由于OpenFlow线路协议1.0版之后的原语集的复杂性，在2012年，ONF把“plugfest活动”这种互操作性和一致性测试，变成更正式的测试（外包给印第安纳大学）。

虽然ONF已经讨论了建立OpenFlow协议的参考实现，但截至本书写作时，这并没有发生（有很多开源的控制器实现）。

OpenFlow协议不直接提供网络切片（slicing）的能力（这是一个有吸引力的功能，把网元设备分割成单独控制的端口组，或将网络分割成单独的管理域）。然而，FlowVisor3（充当多个控制器和网元设备之间的透明代理）等工具和特定的厂商实现（也就是能为不同控制器会话创建多个虚拟交换机的代理），可以提供这样的功能。

3.FlowVisor 将引入一些中间延迟，因为它必须处理交换机和控制器之间的数据分组。

3.2　OpenFlow线路协议

那么，OpenFlow 有哪些新内容？

首先，它为各厂商协议配置的死板的和非标准化的语义引入了“置换瞬时状态”（substituting ephemeral state）的概念4（流表条目并不存储在网元设备上的永久存储器里）。瞬时状态也可以避开过去网络自动化中配置提交模型速度较慢的问题。

4.在编程控制中创建瞬间状态的能力可能只是OpenFlow的暂时优势，因为已经有一些在现有编程方法（如NETCONF）中添加这个功能的提案。

对于大多数网络工程师而言，这种配置的最终结果是建立转发状态（尽管是分布式的状态，并且是在分布式控制环境中学到的）。事实上，对于许多人来说，对配置正确性的测试就是验证转发状态（看一看路由表、转发表或桥接表）。当然，与传统的位于网元设备上的分布式管理相比，这种方式把一些至少是维护状态的管理负担转移到了控制器上，如果总是想事先在转发表里放入某些转发规则的话5。

5.这种配置方式不是独特的，过去移动网络中的PCRF/PCEF/PCC系统已经（通过与Diameter交互）为每个用户这么做了。标准组织一直在进行系统各组件之间的交换信息和厂商互操作的明确定义和标准化处理工作。毫无疑问，移动策略系统可能演变成SDN 系统并具有SDN的特点。这种SDN系统与OpenFlow之间的主要区别可能是灵活性（尽管客观来说，称为简洁性更合适）。

其次，在OpenFlow流表项里，整个数据分组头（至少第二层和第三层的字段）可用于匹配和修改操作，如图3-2所示。很多字段的匹配可以进行掩码6。已经发展出了不同的OpenFlow版本7。图3-2说明了实现二层+三层+访问控制表（ACL）的转发功能（下一跳抽象的快速收敛）可以是比较复杂的。各表中所支持原语的组合使转发功能可以支持非常广泛的突发事件组合。

图3-2：OpenFlow（线路协议）1.0 版本的原语

6.所支持的匹配类型（连续型或偏移型）是另一种依赖于平台的能力。
7.可惜的是，由于在ofp_match 中加入一个TLV结构（并且匹配字段被进行重组），因而后向兼容性无法在1.2版和以前的版本之间被实现。事实上，由于修改的数量和种类，1.2版被认为是不可实现的（尽管2012年终于做出了开源代理程序）。通过对HELLO握手机制做某些修改来实现版本的发现功能，而且对交换机版本不兼容，故不能形成与控制器的会话。

OpenFlow与分布式IP/MPLS模型相比，在运行者所能控制的广度上有着很明显的差异（OpenFlow有11元组的匹配空间）。下面简短地列出了控制广度的可能性。

- 因为在OpenFlow匹配指令中的掩码能力，网络可以模拟基于IP目的地址的转发行为。

- 在二层和三层上，网络都可以表现出基于源/ 目的的路由行为。

- OpenFlow 的数据分组匹配能力目前还没有其他标准能做到，这使其在替代策略路由或分布式控制环境中的其他匹配/ 转发机制方面非常强大。

最后就是OpenFlow 对修改动作（modify action）的承诺。最初的概念是交换机（通过在交换机之外运行的应用程序），但也可以作成像服务装置一样，执行网络地址翻译（NAT）或防火墙等服务。基于硬件的转发系统能否做到这一点，高度依赖于厂商的实现（所支持的指令、指令的顺序和为保持线速性能所能做的操作的数量）8。随着标签操控被加入到线路协议1.3版本里，OpenFlow控制的网元设备就能很容易地模拟MPLS LSR 等集成平台的行为（或其他传统的分布式平台功能）。

8.后面的应用案例探讨在控制器上建立这样的应用程序，或在虚拟服务路径对此功能进行虚拟化。

OpenFlow协议通过EXPERIMENTER 扩展（扩展可以是公共的，也可以是私有的）来实现对控制消息、流匹配字段、计量表操作、统计数据的扩展，以及厂商特定的扩展（这些扩展可以是公共的，也可以是私有的）。

表项可以有优先级（如果表项有重叠），并有时间到期机制（在某些情况下避免了清理操作，并对控制器丢失等情况下的流表项有终止效果）。

OpenFlow 支持PHYSICAL、LOGICAL 和RESERVED 的端口类型（分别对应物理的、逻辑的和预留的端口类型）。这些端口被用作入口、出口或双向结构。

预留的端口IN_PORT 和ANY 是不言自明的9。

9.IN_PORT 代表数据报文进入的端口，ANY 用在无需特别指定端口的情况下。——译者注

表被要求创建一个多表流水线（OpenFlow 最多支持255个无类型的表，通过任意的GoTo在流水线中排序）。

其余的预留端口用来实现重要的（有意思的）行为10。

10.CONTROLLER 是下面几个预留端口中唯一必需的（其他为可选的）。其他必需预留端口是ANY、IN_PORT、ALL 和TABLE。这里列出的组合因它们在混合作模式中的相互作用而趣味盎然。

- LOCAL
仅用于出端口，该逻辑端口允许OpenFlow 的应用程序访问网元设备的主机操作系统的端口（进而访问进程）。

- NORMAL
仅用于出端口，该逻辑端口允许交换机像一个传统的以太网交换机（以及相关的洪泛/学习行为）那样运作。根据该协议功能规范，该端口仅在混合交换机中受支持11。
11.这里“混合”的原始定义是，一台交换机，既可作为OpenFlow交换机，也可（在OpenFlow 域里面的端口上）作为二层交换机。

- FLOOD
仅用于出端口，该逻辑端口使用网元设备的复制引擎来把数据分组发送到所有标准（非预留）端口。FLOOD 与ALL（另外一个预留端口）不同，ALL端口包含入端口。FLOOD利用了网元设备的数据分组复制引擎。

- CONTROLLER
允许转发数据分组的流规则（通过控制通道）从数据路径转发数据分组到控制器（或方向相反的转发）。这就启动了PACKET_IN 和PACKET_OUT 行为。

OpenFlow 的转发模型提供两种模式：主动模式（预先提供）和被动响应模式（数据平面驱动）。在主动模式下，控制程序将先于需求而放置转发表项。如果收到的流不能与现有的流表项匹配，则运行者有两种（全局的）选择：丢弃这个流，或使用PACKET_IN 选项来作出决定，以创建适应这些数据分组的流表项（无论是正面的、转发或负面的，还是处置），此即被动响应模式。

控制通道最初被规定为一个对称的TCP 会话（可能用TLS来保证安全）。该通道用于配置和管理（放置流表、收集事件以及统计），并提供交换机与控制器/应用程序之间发送和接口分组的路径。

统计数据支持流、聚合、表、端口、队列和厂商特定的计数器。

在OpenFlow 协议的1.3 版中，允许采用多辅助连接（TCP、UDP、TLS 或DTLS）来处理任何OpenFlow 的消息类型或子类型。但UDP 和DTLS 通道不能保证数据分组的顺序，因此规范里有行为准则来确保对数据分组的特定操作是对称的（以避免在控制器上的顺序问题）12。

12.David Ward在JIRA系统（ONF讨论或制定标准中用于提交提案的系统）中提出了关于这些协议变化的相当完整的解释，特别是针对从基于会话的通道变为基于UDP的问题。

OpenFlow 支持BARRIER 消息来创建一个调步机制（创建单元的或流的控制），用于与后续消息有依赖关系的场景（给出的示例是，PACKET_OUT 操作首先需要一个流表项，以匹配数据分组和进行转发）。

3.2.1　复制

OpenFlow 提供了几种数据分组复制的机制。

ANY和FLOOD预留的虚拟端口主要用于模拟/支持现有协议的行为（ 例如，LLDP用来为控制器收集拓扑，常采用FLOOD 作为其输出端口）。

组表（group table）允许把端口组合成一个输出端口集合，以支持组播、多路径、间接转发和快速故障切换。每个组表实质上是一个动作桶的列表（表面上动作之一是输出到一个出端口）。共有四个组表的类型，但只有下面两个是必需的。

- All
用于组播，列表中的所有动作桶都必须被执行13。
13.规范中声称ALL组类型可用于多路径，但这不是IP转发中的多路径，即数据报文将被复制到两条路径。这种行为更加符合提供实况视频，或其他需要在端节点做整流的多路径。

- Indirect
用于模拟IP转发中下一跳的聚合行为，用于更高效的路由聚合。

Apply（ 执行） 动作允许通过创建一个输出/端口动作的列表进行连续的复制（Apply动作在OpenFlow的1.0版中是单例操作）。

3.2.2　 FAWG（转发抽象工作组，Forwarding Abstraction Workgroup）

OpenFlow 交换机的模型（如图3-3所示）在基于软件的交换机（在规模和数据分组操控特性上有突出的灵活性），或在符合一些简化假设的硬件转发实体（例如，像TCAM那样有容量、宽度、深度的多入口存储器）上得到很好的支持。但由于不是所有的设备都符合上述条件，所以在OpenFlow的原语、多表以及其他OpenFlow强大功能所支持的数据分组操控方面，设备的支持有非常多的变种。

图3-3：OpenFlow 1.0 的转发模式（非常简单的共享表模型）

通常来说，OpenFlow 1.1及后续版本的潜在组合复杂性（参见图3-4）在基于ASIC的转发硬件上不能很好工作。因此，OpenFlow应选择何种抽象级别已经成为一个问题，因为这关乎对应用程序的适用性。

图3-4：OpenFlow 1.1版及后续版本中的“后OpenFlow流水线模型”（非常复杂，其组合复杂度为O(n!×a(2l))的路径，其中n=表的数量，a=动作的数量，l=匹配字段的宽度）14

14.这里OpenFlow复杂度的表达式由David Meyer提供。

虽然这是一个普遍持有的观点，但对Martin Casado（OpenFlow之父）进行的访谈经常在关于OpenFlow 抽象级别的更普遍的争论中所引用15。

15.http://searchnetworking.techtarget.com/news/2240174517/Why-Nicira-abandoned-OpenFlowhardwarecontrol（要想阅读完整的文章，需要预订）。

在访谈的全文中，Martin列举了OpenFlow在流量工程中的应用，评论了使用现有的ASIC 来实现OpenFlow的局限性（一般化的观点），然后就OpenFlow对网络虚拟化的适用性做了一个特别的评论：“我认为OpenFlow对网络虚拟化而言是过于低层次了。”

该协议早期版本中仅具有有限的能力检测功能，在1.3版中重构为支持一些原始的表能力描述功能（为每个匹配字段添加了匹配类型，例如，精确匹配、通配符匹配和最长前缀匹配。

以下是从文献16中引述的现有抽象的不足之处：

16.转发平面模型（FPMOD）和表归类（Table Type），应向何处去？（ David Meyer/Curt Beckmann）ONF TAG-CoC 07/17/12。

- 信息丢失；
- 信息泄漏；
- 控制平面到数据平面抽象能力薄弱；
- 组合状态爆增；
- 数据平面驱动的控制事件；
- 间接基础设施匮乏；
- 时间敏感的周期性消息；
- 多个控制引擎；
- 可扩展能力弱；
- 缺少原语。

独立的工作组FAWG，正在通过表归类模式（table type pattern，TTP）尝试第一代协商式交换机模型17FAWG开发一个建立、标识（唯一地标识）和共享TTP的过程。还开发了协商算法（基于Yang 模型构建）和消息，用来建立控制器与交换机之间商定的TTP（可能增加到of-config 版本1.4中）。

17.一个更复杂的解决方案被OpenFlow未来讨论组提出（名字叫转发平面模型：Forwarding Plane Models，FPMOD），但因FAWG正在开发的更简单的表类型描述模型（由技术顾问组TAG建议）而搁置了。这个解决方案模型方面较少，主要是原语集合，是在交换机硬件抽象层编码时做映射的原语，而不是控制器使用的原语（当然，是基于行为的协商模型，但不一定是静态、预定义、限于流水线描述的模型）。

一个TTP 模型是一个预定义的交换机行为模型（例如，HVPLS_over_TE 转发和L2+L3+ACL）由特定表描述（匹配/ 掩码和操作）和表互连（即体现了个性的逻辑管道）来表示。这些描述可能随元素在服务流中的角色不同而不同（例如，对于HVPLS 转发，该元素是头端、中点还是或出口）。

早期的模型贡献建议在OpenFlow 的1.3.x版中通过进一步扩展来实现TTP。

如果FAWG成功了，那么控制器上的应用程序就至少可以从行为描述角度，知道网元设备的能力。

下面是需要TTP（或FPMOD）的一个简单的示例18。

18.这个示例也来自本章前面提到的Meyer/Beckman 的那篇参考文献。

如果硬件表之间包含相似的数据以及表索引（可以）的不同性较低时，就可以共享表项（例如，包含MAC地址转发和MAC地址学习这两个视图的逻辑表）。这个表可以用很多不同的方式来实现，如作为一个单一的硬件表。实现MAC学习/桥接的OpenFlow控制器必须准备两个不同的表：一个用于MAC地址学习，另一个用于MAC桥接（这是OpenFlow表达的限制）。当前还没有办法把这两个潜在不同的视图绑在一起。在图3-5这个简单的示例中，可能会出现计时的场景，把两个独立的OpenFlow表实体的流表修改给同步起来（也就是说，不能在MAC地址学习之前进行转发）。

图3-5：TTP模型的复杂度示例：L2+L3+ACL/PBR（ 策略路由）的TTP（ 资料来源：Brocade 公司的D. Meyer 和C. Beckmann）

在图3-5的情况下，IPv4和IPv6表指向组表来模拟在传统FIB中对下一跳的抽象（为了更快地收敛）。

3.2.3　配置和扩充性（Extensibility）
of-config协议最初设计来设置网元设备上OpenFlow的相关信息（of-config的1.0版本）。该协议是围绕XML 模式、Yang数据模型和NETCONF协议来构架的。

对扩展of-config 的建议来自于Config-Mgmt 工作组（配置和管理工作组）或其他工作组（例如，转发抽象工作组或传输工作组19）。

19.光交换机的大多数配置是静态的和永久性的，所以需要做的扩展可能是更适用于of-config。

自of-config 的1.1版开始，该标准将它本身与运行者会运行FlowVisor（或类似的外部切片代理）的假设解耦分离，以实现在一个物理交换机中的多个虚拟交换机的抽象。这使得工作模型变为物理交换机可以有多个内部的逻辑交换机，如图3-6所示。

图3-6：配置协议与线路协议之间的关系（资料来源：OF-Config 版本1.1）

使用of-config 版本1.1，除了控制器、证书、端口、队列和交换机能力，运行者可以配置一些逻辑隧道类型（IP-in-GRE、NVGRE、VX-LAN）。这个扩展需要交换机支持创建逻辑端口。

有建议进一步扩展of-config，包括自举功能，以及在of-config 协议的1.2 版（参见图3-7）中扩展支持更多的本地（native）20传统交换机功能（例如，配置本地OAM协议守护进程的能力已经被提议作为一种扩展）。

图3-7：OF-Config 能力的发展

20.本章中的“本地”（native）交换机，指在交换机本地有比较完整的控制功能，即传统的以太网交换机。后续还会出现本地网，指传统的以太网或IP 网，本地主机指传统以太网和IP 网设备。——译者注

通过扩展of-config支持的本地组件，ONF可能无意中开始讨论混合操作这一主题，也可能造成了一些与标准相关的疑惑21。

21.of-config使用NETCONF/Yang，所以工作组正在为这些实体（隧道、OAM）建立自己的Yang 数据模型。从一个标准组织的角度来看，这可能不是一个很好的推进模式。

体系结构工作组的一项内定工作是研究线路协议与配置协议的潜在合并。体系结构工作组的章程里没有输出任何协议或规范的要求，因此这个合并将来可能由其他工作组来完成。

对NETCONF 的使用也可扩展到“请求后台支持”（call home）场景（即交换机发起的连接），但指定采用BEEP（这是of-config 里对NETCONF 连接类型的要求）这个历史协议22，可能需要协议规范的修改或与IETF 进行协调。

22.规范NETCONF的传输协议采用BEEP的RFC4744在IETF已经是一个废弃的标准了，即Historical RFC。——译者注

扩充性（Extensibility）工作组审查对线路协议提出的功能扩充，并把新功能加入OpenFlow 中（了解协议的总进展，可参见图3-8）。

图3-8：从OpenFlow 1.1版到1.3版对流水线的增强进展

2012 年4 月，当OpenFlow 的线路协议1.3版发布时，ONF决定放慢扩充版本的发布，直到该版本有更高的采用率，并允许临时的错误修正版本（如1.3.1 版修正了1.3版中的一些小错误）23。

23.后来，ONF 要求新的扩充或配置管理建议都需实现原型系统，以对协议的扩展部分进行概念验证（有点像其他标准组织所要求的那样：标准需要有可工作的代码支持）。

OpenFlow线路协议1.4版的主要扩展，来自于新成立的传输讨论组24，其重点是OpenFlow与光传输网管理系统之间的接口，以便创建一个标准的多厂商传输网络控制（例如服务开通配置）的环境25。

24.有扩展线路线协议来支持光路交换技术的建议（建议编号为EXT-154）。这个扩展处理简单的波长调谐和对端口的进一步定义。
25.有个颇有道理的说法是，GMPLS 就应该提供这种标准化。但GMPL 中的定义、解释以及实现都非常不一致，导致无法保证多厂商之间的互操作性。

OpenFlow 的1.4 版增强功能的全集在本书的未来版本中可以找到。

传输和OpenFlow 整合的第一次努力展示了将光网络抽象成OpenFlow 可理解的交换机模型的能力，通过抽象的视图来创建一个虚拟的叠加。

目前传输讨论组拟议的传输方案的体系结构，是把设备级的信息模型（例如OTN光传输网的网元设备、以太网的网元设备和MPLS-TP 的网元设备）与网络级的信息模型（MTOSI、MTNM）组合起来，在加上OpenFlow 驱动的控制平面，进行直接控制26。

26.解决方案要么允许直接控制网元设备，要么利用一个类FlowVisor 的切片功能代理，并为每个光传输网的虚拟切片引入客户端控制器的概念（适合于传输环境中普通的或预计的业务应用程序）。

即使在直接控制的情况下，各种混合控制平面场景的问题依然存在。即对同一个传输网控制时，传统的EMS/NMS协议是否可以对OpenFlow驱动的控制进行组合。图3-9展示了这种情况。

图3-9：包含了OpenFlow 控制的传输网络的混合控制环境

3.2.4　体系结构

虽然OpenFlow提供了一个标准化的南向（控制器与网元设备代理之间）协议对数据流进行实例化，但无论是北向（应用程序面临的接口）API或东/西向的API都还没有标准。

大多数可用控制器的东/西状态分布是基于数据库的分布式模型，它允许单一厂商的多控制器组成联盟，但不允许不同厂商控制器之间进行可互操作的状态交换。

体系结构工作组正在试图解决这个问题，至少是间接的解决，即为SDN定义一个通用的SDN体系结构。ONF有段时间把SDN的定义和OpenFlow的定义结合在一起。如果没有这些标准化的接口，就会出现这样的问题：SDN 的ONF定义是否意味着开放性。

大多数的OpenFlow控制器（如图3-10所示）提供了一套基本的应用服务：路径计算、拓扑结构（通过LLDP确定，这限制了二层拓扑）和服务开通配置。为了支持of-config，它们需要支持NETCONF驱动程序。

图3-10：OpenFlow 控制器组件（FlowVisor 和应用程序是独立的实体）

关于SDN体系结构和OpenFlow一直存在的问题是，OpenFlow控制器（和OpenFlow 工作的网络层）提供的应用服务的类型，对所有可能的SDN应用程序来说是否够用27。

27.OpenFlow是否就是SDN，是一个备受争议的问题。

围绕OpenFlow的模型宏观主题（例如，故障排除、包含OpenFlow语义的更高层次的政策表达，以及控制器和网元设备之间验证层的需要）展开的研究正在许多学者和研究单位中进行，特别是开放式网络研究中心（Open Network Research Center，ONRC）。

3.3　混合方案

ONF成立了一个混合工作组（Hybrid Working Group）。该工作组建议的体系结构， 一个是“午夜行船”（Ships in the Night，SIN）模型28，另一个是集成的混合模型。委员会只接受了对SIN 模型的推荐。

28.夜晚行船时，船之间要拉开足够的间隔以免互相冲撞，这里的“午夜行船”模型形象地说明在混合网络中，OpenFlow控制模式与传统的“本地网”（native network）模式即分布式运行模式要彼此隔绝。——译者注

集成的混合模式有一系列围绕混合网络安全和疏忽所造成的问题。

假设一个控制的分界点是在网元设备上（在OpenFlow控制平面和本地控制平面之间），安全问题围绕着如何利用预留的端口（尤其是对CONTROLLER、NORMAL、FLOOD 和 LOCAL端口），以允许访问混合网或本地网（即传统网络）的本地守护进程（应用程序在控制器上或OpenFlow端口上可能假冒IGP对端或其他协议会话，来插入或导出状态，从而造成本地网的安全隐患）。

在一个意外的连接创建了混合网络的情况下，安全边界就扩展了。这发生在这样的情况下：外部/ 非环回网络链路的一端被连接到一个OpenFlow的域，而另一端连接到一个本地域中。

新近成立的安全工作组可以解决混合安全的担忧，在写本书时还没有获得足够的材料进行单独讨论。在本书的未来版本中可以找到更多讨论。

3.3.1　午夜行船模型

午夜行船模型SIN的命题，是假设一个端口（物理的或逻辑的）只能用于OpenFlow或者只能用于本地，但不能同时用于两者（参见图3-11）。SIN的重点是。

图3-11：SIN 的体系结构（资料来源：ONF 的混合SIN 工作组）

- 限制OpenFlow进程所分配的资源，使其无法影响本地网这边的操作（反之亦然，限制本地网所分配的资源，使其服务影响OpenFlow网这边的操作）。提出的建议包括在本地主机（即混合模式的交换机）的操作系统中（或通过虚拟化）采用现代进程级别的隔离。

- 避免OpenFlow与本地网的控制平面之间同步状态的需求，或者不同步事件通知。

- 对使用LOCAL、NORMAL 和FLOOD等保留端口的流处理采取严格的规则（有明确注意事项）。

SIN扩展了ONF之前对混合方式的定义（反映在对NORMAL 这种预留端口的定义中）。

SIN模型允许端口通过逻辑端口或VLAN 来隔离，并推荐在这个环境里使用MSTP作为生成树实现（这一步骤对某些特定类型的集成式混合是必要的）。

最后，SIN指出了预留端口之间的交互还是含糊不清的，松散的端口委托模型是SIN混合方式的潜在改进领域。

3.3.2　双功能交换机

混合工作组的集成式体系结构白皮书被ONF拒绝了，ONF董事会后来建议成立了迁移工作组（Migration Working Group）， 以协助OpenFlow的使用者进行OpenFlow网络体系结构的部署，而无需经过一个混合使用的过渡期。然而，对于集成式混合的需求仍然存在，而新成立的迁移工作组可能可以解决混合设备和混合网络的问题29。

29.对于那些希望有一个混合网络的人，混合网络设计方案（Panopticon 混合），其结构类似于一个数据中心叠加模型（使用伪线的叠加），在ONS的2013 年会议上被提出。

一个集成的现有的/ 已部署的（existing/deployed）模型是对OpenFlow 的域与本地域在控制级别（例如RouteFlow）上进行集成。与集成式混合不同的是，这种方式特意建立了一个混合网络（参见图3-12）。

图3-12：RouteFlow 的体系结构（资料来源：http://cpqd.github.io/RouteFlow/）

这种做法背后的一般概念，是在虚拟主机上运行路由协议栈，并把该主机上虚拟机管理程序的虚拟交换机虚拟端口与OpenFlow交换机相关的物理端口绑定。通过这些端口，虚拟路由器与本地网的IGP和BGP在适当的物理边界交换机上，通过开启流表中相应的流而形成邻接关系。虚拟路由器然后通过适当的边界点，发布分配给OpenFlow域的前缀（从本地网中看，它们就像是通过相邻对等体而学到的）。此外，（通过使用内部逻辑和政策）虚拟路由器在OpenFlow的域内创建流规则，将流量引到从邻居那儿学到的目的地前缀，通过流规则最终指向边界交换机的合适端口。

这种混合设计的一个潜在缺点是流量管理和数据分组I/O连续在一个共同的TCP会话上发生，这使该设计回到传统的分布式控制平面要解决的问题，即阻塞、控制数据分组I/O、延迟、队列管理以及硬件编程速度。其中一些问题可以通过使用其他可选（alternative）控制通道（OpenFlow 的1.3 版本所提出的）得到改善，这种想法将在OpenFlow的线路协议中发展并成熟。

目前手头可以用于形成集成式混合连接（在同一设备上的OpenFlow的协议和本地协议）的工具是：表和接口。

基于表的方案可以使用OpenFlow的GoToTable语义来设计，在本地表里做地二次查找。目前，OpenFlow并不了解除了它自己的表之外的其他表，并且也没办法了解。解决方案可以是，允许在会话初始化时发现本地表。该方案存在的下列问题。

- 对于本地域中VRF（虚拟路由转发）表的名字空间而言，OpenFlow的表空间太窄。

- 本地端可以创建大量的动态表，特别是在运营商边缘或数据中心网关设备上，该表需要更新到控制器（重新启动会话可能是繁重的，而动态发现又需要更多的标准化工作） 。

- 本地域在某些设备上可以有64个以上的表。

- 尽管GoToTable方案简洁（包含了所有我们对透明性的所有假设），但它似乎是一种复杂而有影响重大的路由。

目前有一些非官方的基于接口的解决方案，以实现域间的双向流。最常见的是在OpenFlow交换机域中插入一个新的三层的人工组件（artifact）。该人工组件可被NOMRAL 端口行为、DHCP和ARP的组合所影响，这样终端站点就可以在OpenFlow域内发现一个转发网关设备。这个方案虽然可以工作，但还远远谈不上健壮。在OpenFlow这方，NORMAL逻辑端口仅用于出口，所以用流修改在相反方向上控制流是不可能的。此外，一些系统管理员/操作人员出于安全原因，不喜欢使用NORMAL端口。

创建规则来直接交叉连接（cross-connect）三层人工组件与OpenFlow控制的端口，从而支持入口和出口的规则，这是可以做到的。如果进一步对接口的定义进行扩展，那么就能够对三层转发器或本地端口打上Tag标签（这里不关注标签的语义）。例如，在Junos操作系统（瞻博公司），有一种称为逻辑隧道的结构（参见图3-13）。这种结构可以一端在OpenFlow域，另一端在本地的任何路由域。对于运行者，这提供了一个可扩展的、透明的混合解决方案，但运行者员可以对端口挂起（从而发现它的双重性）的唯一标签就是它的名字（遗憾的是，这是瞻博公司独有的技术）。

图3-13：瞻博公司的集成式混合提案（资料来源：瞻博公司）

基于接口的解决方案需要执行以下操作。

- 至少一个端口的扩展描述，将用本地的人工组件来标记（域之间的访问点）。其他额外的属性可能指出域的本质（例如IP/MPLS），以及它们上的路由实例。这些属性可以与厂商代理在port-status消息或Features_reply消息中做为端口信息的一部分来交换。（这些是对OpenFlow的标准所建议的扩展。）

- 厂商代理应该实现双向流所需的所有MAC相关功能（如自动将人工组件的MAC地址与分配给这个点的前缀相关联，或在本地表中指出该人工组件）。

- 厂商代理应该支持OpenFlow-ARP的相关功能，以便OpenFlow域内的设备可以发现人工组件的MAC地址 。

- 本地端口可以实现为一个内部的环回（loopback）端口（首选方案），或实现为一个外部环回（即对称解决方案要优于非对称解决方案）。

- 如果某些应用程序如通过LLDP的拓扑发现，排除了本地人工组件/端口，这是可取的。（这是一个规定的操作行为。）

集成式的混合支持虚拟接口（例如共享一个链接到VLAN Tag的水平）。任何共享链路（如支持VLAN中继的一个端口）的外部/本地功能，都应在跨两个域的整个流量中生效（如域的并行操作，但不要交叉连接）30。此外，本地接口功能可以在人工组件（连接了各域）里应用，但没有假设它们必须被支持。此行为与厂商有关，并且其支持、后果（意外行为）和这些功能的顺序都需要厂商向 他们的客户明确给出定义。

30.客户已经请求了通过一种方法在物理端口上使用QoS的能力，来防止某个域（本地域或OpenFlow 域）的VLAN在共享链路上消耗过多的带宽。

3.4　小结

人们认为是OpenFlow（和与之配套的标准组织ONF）开启了SDN的讨论，并提供了现代SDN控制的第一印象：一个控制的集中点，一个展示拓扑的北向API，路径计算，向控制器之上的应用提供服务，以及一个标准化的、用于在一个多厂商基础设施中对转发状态进行实例化的南向协议。

可惜，OpenFlow的体系结构并没有提供一个标准化的北向API，也没有提供一个标准化的东西向分布状态协议，以实现两个应用程序的可移植性和控制器厂商之间的互操作性。标准化工作可以通过ONF新成立的体系结构工作组，甚至是新的开源组织OpenDaylight项目向前推进。

OpenFlow为那些利用了全套OpenFlow 原语集的平台提供了大量的流/流量控制。ONF已成立了一个工作组，来解决当厂商使用OpenFlow 原语集来实现知名的网络应用模式时，厂商硬件实现能力的描述与发现问题。

尽管对OpenFlow 所实现的抽象水平，以及是否其最终的API 代表一个完整的SDN API 等问题还有疑问，但其应用还是很有意思的，而且在混合操作方面的不懈努力，可能会更容易地整合其在传统的/分布式网络或在OpenFlow域与本地域之间的边界上，匹配和衡量流量的能力。

第4章　SDN控制器

4.1　引言

SDN最能引起人们共鸣的三个概念是：可编程、控制平面与数据平面分离，以及用于网络瞬时状态（ephemeral state）管理的集中式控制模型（无论集中程度如何）。最终，这些概念体现在一个理想化的SDN 框架中，将在第9 章详细介绍这个框架。SDN控制器就是这个理想化SDN框架的具体体现，并且在大多数情况下反映了这个框架的核心内容。

从理论上讲，SDN控制器提供的服务能够实现分布式的控制平面所能做到的那些功能，同时它还能实现网络瞬时状态的管理和集中化等概念。在现实中，任何一个控制器的实例，实际上都是提供了这些功能的一个切片或者是一个子集，反映了该控制器对这些概念的取舍。在本章中，作者将详细介绍由商业公司和开源社区提供的最流行的SDN控制器。本章中将以理想化的控制器/框架图景来贯彻始终，用来作为与各种控制器实现进行对比。本章将具体介绍对不同控制器类型与控制器理想版本进行对比的文字。

作者想说明的是，尽管希望能全面地对这些控制器进行介绍，但依然可能有一些缺失。此外，这里详细介绍了一些商业控制器，但也有可能遗漏了一些。若有任何遗漏，都不是作者故意造成的，而且也不代表作者对控制器存在个人偏好。

4.2　基本概念

图4-1展示了一个理想化的控制器。这张图实际上适合放在第9章，放在这里主要是为了方便引用。为了对不同的控制器进行比较，本章将反复提到这张图。

图4-1：理想化的控制器（框架）

一般地说，SDN 控制器是一个提供如下功能的软件系统或者系统的集合。

- 网络状态管理。某些情况下，对于网络状态的管理与分布，有可能需要一个数据库。这些数据库作为知识库，保存来自于被控制的网元设备和相关软件的信息（以及被SDN应用程序所控制的信息，包括网络状态、一些临时配置信息、学习到的拓扑和控制会话信息）。另一些情况下，控制器可能有多个由目的驱动的数据管理进程（例如，关系和非关系数据库）。再有一些情况下，也有可能使用内存型数据库。

- 高级数据模型。这个数据模型描述被管理的资源、策略和控制器提供的其他服务之间的关系。在很多情况下，这个数据模型可使用YANG建模语言来构建。

- 一般使用现代的RESTful（REpresentational State Transfer，表征状态转移）API来将控制服务提供给应用程序使用，为主要的控制器和应用程序之间的交互提供便利。理想情况下，API 是通过描述控制器服务和特性的数据模型来提供的。在一些情况下，控制器和对应的API是开发环境的一部分，这个开发环境可以从数据模型中产生相应的API代码。一些系统提供一个允许扩展核心功能并为新的模块发布API的开发环境，有些系统甚至支持控制器功能的动态扩展。

- 安全的控制会话，即控制器和网元设备中相应的代理之间的TCP 会话。

- 一个基于标准的、用于在网元设备上配置应用程序驱动的状态的协议。

- 一个设备、拓扑和服务发现机制，一个路径计算系统，以及可能的其他网络为中心或者资源为中心的信息服务。

当前控制器市场的全景是由来自VMware（vCloud/vSphere）、Nicira（NVP）、NEC （Trema）、Big Switch Networks（Floodlight/BNC）、瞻博（Juniper/Contrail）等公司的商业化产品，以及一些开源的控制器组成的1。

1.一些厂商同时提供开源和商业产品。/sub>

除了使用OpenFlow和私有协议，有一些SDN控制器使用IP/MPLS功能来创建MPLS VPN，作为数据中心或在广域网上叠加的MPLS LSP的一种三层上封装三层（L3-over-L3）的租户分离模型。

有些论断是不能忽略的，如基于NETCONF的控制器2和网络管理解决方案这二者几乎无法区分，或者基于Radius/Diameter的控制器如PCRF或者TDF，在移动环境中也可以看作是SDN控制器。特别是当这些方案的南向协议变得更加独立，而且有能力获取网络或者配置的瞬时状态之后，这些论断是正确的。

2.http://www.uppersideconferences.com/sdnsummit2013/program-sdn-summit2013.pdf

正如本书前文所讨论的，原有的数据中心服务编排的SDN 应用，催生了SDN控制器作为集成解决方案的一部分。正是这种应用案例侧重于数据中心的资源，如计算、存储和虚拟机映像，以及网络状态的管理。最近，出现了一些SDN控制器专门从事网络抽象的管理，并通过开源AP（OpenStack、CloudStack）的支持与数据中心资源管理实现紧耦合。当前第二波控制器热潮的驱动力来源于数据中心之外的SDN 应用，特别是那些对虚拟资源的管理（如处理能力和存储）没有必要紧耦合在同一个解决方案中的网络。

数据中心行业中网络部分的增长，也引入了大量围绕虚拟机管理程序内集成的交换机/路由器/网桥来构建的新型网元设备。这里也包含在后面几章将要探讨的网络服务虚拟化。网络服务虚拟化，有时也称为网络功能虚拟化（Network Functions Virtualization，NFV）将向下一代网络体系架构中增加更多的网元设备，这一点进一步加强了对操作和管理这些网元设备的控制器的需求。本书也将讨论NFV 的互联或者链接。

虚拟交换机或者虚拟路由器代表了网络环境中的最低共性。和专用的硬件设备相比，它们一般具有较少的转发表项。尽管在服务虚拟机中，它们可能在技术上能够支持很大的查找表，但是它们真正的限制在于与服务虚拟机无关的那些行为，特别是虚拟机管理程序中对集成表的规模和管理的能力，而该能力常是在为特定路由器或交换机设计的专用硬件平台上实现的。简单的基于虚拟机管理程序的转发架构不能够和传统专用网元设备一样为RIB/FIB组合提供空间。在分布式控制范式情况下，需要协助才能够将分布的网络信息归结为极少数的表项，这个协助要么来自于主机上作为VM 运行的用户空间的代理程序，要么来自于SDN控制器。在后一种情况下，SDN控制器在分布式环境下作为代理运行，或者在管理集中的环境下作为流配置的代理运行。在这种情况下，控制器可能是面向常规情况下由网络OSS提供的网络管理层面的。

对于数据中心中运行在主机上的软件交换机和路由器，SDN控制器是一个关键的管理接口。SDN控制器提供一些除了服务开通配置和发现之外的管理服务，因为它们能够处理和瞬时网络实体相关联的状态（通过代理），如分析和事件通知。在这个方面，SDN有潜力可以彻底改变网元设备管理系统（EMS）的视图。

4.2.1　VMware的控制器

VMware公司提供了一个数据中心的服务编排解决方案及已成为事实标准的私有的SDN 控制器和代理实现。VMware公司成立于1983年，是创建云计算产业的主要公司之一3。VMware公司提供了一整套围绕ESX（ESXi 版本5.0及以后）建立的、以数据中心为中心的虚拟机管理程序以及虚拟机管理程序内集成的交换机（hypervisor switch）：vSphere分布式交换机（vSphere Distributed Switch，VDS）。图4-2 展现了VMware 公司产品之间关系的概要性框架。

图4-2：VMware公司产品关系（以vCenter Chargeback控制器作为运行管理套件进行连接 的示例）

3.http://www.vmware.com
vSphere推出了ESXi虚拟机管理程序（5.x版本），以取代旧的ESX虚拟机管理程序。ESXi更轻量级/更精简（根据销售公告，ESXi只有ESX规模的5%），而且是与操作系统无关的。ESXi还增加了Web界面（ESX只有CLI）、客户端API和vCenter的可视化能力。此外，ESXi避免使用一个客户VM（即每个主机的guest VM）来支持服务控制台进行本地管理。

VDS从管理的角度将一些独立的虚拟交换机（VSphere标准交换机）的集合，抽象成为一个单独的逻辑交换机。这使得VCenter服务器成为了所有VDS实例的一个管理/控制点，并将每一个VSS的管理和数据层面分开。

在VDS中，VMware公司提供了物理网卡的抽象（vmnic）、链路特性的抽象（例如，队列、失效和负载均衡：dvuplink）和网络特性的抽象（例如，VLAN 指派、流量整形和安全：dvportgroup）。这些抽象可以被管理者作为可重用的配置模版。

一旦配置完成后，即便是vCenter服务器失效或者脱离网络4，网络运行必要的组件（ESXi交换机）也将持续运行。大部分的高可用性方案是在结构化的集群中进行管理的，其中一个代理被选举为一个故障域的主节点，其他的作为从节点。这将通过采用建立在共享数据存储机制之上的心跳机制，实现可容忍管理通信分区，来创建一个可扩展性非常好的虚拟机健康监测系统。

4.vCenter 服务器可以在硬件计算机上运行或者在VM中运行。当在VM中运行时，vCenter 可以利用vSphere 的高可用特性。

上述的VMware 软件的应用程序可在不同的程序集中， 例如专为IaaS设计的vSphere/vCloud/vCenter 套件，包含下列几种：

- vSphere
管理VMware的虚拟化基础设施。这包含管理和虚拟机管理程序集成的虚拟交换机（从网络的角度），以及其他基础的IaaS 组件：计算、存储、镜像和服务。这个套件使用SQL数据库（Microsoft 公司或Oracle 公司）作为资源数据存储。

- vCloud Director和vCloud Connector（目录服务和连接服务）
计算、存储、镜像资源文件管理和公有云扩展的主要应用。

- vCloud Networking和Security（联网和安全）
作用如其名字所示。

- vCloud Automation Center（自动化中心）
IT管理的配置助手。

- vCenter Site Recovery Manager（站点恢复管理器）
用于自动灾难恢复的复制管理器。

- vCenter Operations Management Suite（操作管理套件）
应用监控、VM主机和vSphere配置和修改管理、发现、计费、分析和报警。

- vFabric Application Director for Provisioning（服务开通配置的应用目录服务）
应用管理（主要是在租赁度的定义中描述的多级应用，以及管理依赖）。

2011 年VMware公司启动了一个开源的PaaS系统，称为Cloud Foundry5。Cloud Foundry 提供运行在VMware 软件上的托管服务。

5.http://cloudfoundry.com/

虚拟机管理程序内集成的虚拟交换机程序可以创建VxLAN隧道叠加层（在三层中封装二层），创建隔离的租户网络。VMware公司通过自己的vSphere API和其自身的虚拟交换机设施进行交互，并发布一个由厂商使用的API，允许第三方设备（路由器、交换机和其他设备）根据vCenter参数化的事件触发器进行反应（例如，将触发器和对应的参数映射到为厂商定制的配置修改中）。

VMware vSphere 的一个强项是其开发环境通过集成vSphere API，允许第三方开发虚拟机管理程序和用户空间VM 应用服务（例如，防火墙、反病毒机制）。

VMware 公司的解决方案的核心是以Java 为中心的，具有如下的特征。

- 基于HTTP和REST的、面向资源管理的API 集；

- 基于Spring的组件框架6；
6.该环境通过一个Spring的子集SpringSource来提供。

- OSGI（Open Services Gateway Initiative）模块框架7；
7.http://www.osgi.org

- 基于JMS的消息发布/订阅总线；

- Hibernate8DBMS接口（Hibernate是一个对象/关系映射库，允许Java开发者创建/检索对象的关系存储）。
8.http://www.hibernate.org

Spring开发环境可以灵活地创建和链接对象(beans)、声明式事务及缓存管理，以及介入数据库服务。Spring也提供RESTful端点的创建和自动API创建支持。图4-3说明了VMware软件和SpringSource的关系。

图4-3：VMware 公司的vCloud/SpringSource 软件开发体系架构结构图

对于刚才描述的体系架构，最明显的一件事件就是，其重点是在于管理整合的数据中心资源（例如，镜像、存储和计算）。从控制器的角度看，可以注意到“控制器”管理远不止是网络的状态。

这是一个重要的特性，因为这样做能够得到一个统一的、易于操作的解决方案。不过，这样也可能会导致和其他解决方案（例如数据中心交换机、路由器和其他设备）集成时出现问题。

VMware公司的解决方案经常被提及的一个主要缺陷就是其成本9。尽管用户对于成本的考虑各不相同，但是相比之下，开源的解决方案显然是免费的。即便是开源软件的企业版一般情况下也远比同等功能的VMware公司的产品要便宜。另外一个可能不太重要的考虑因素，就是其固有的可扩展性，例如一些大规模的用户往往抱怨价格。VxLAN 叠加网络中的映射和数据封装，并没有标准化的控制平面用于状态分发，这导致其操作类似于手动或者基于脚本的配置或者操作。最后需要在底层网络使用组播来支持洪泛可能成为一个问题，这取决于所部署的底层网络的类型。

9.产品授权中已经包含了每个槽位和VRAM 的费用，对于一些应用，例如站点恢复管理器（Site Recovery Manager）还有额外费用。作者已经就此向大量的用户进行了交流，这已经不是一个“传闻”了。

VxLAN叠加网络中的映射和数据封装，并没有标准化的控制平面用于状态分发，这导致其操作类似于手动或者基于脚本的配置或者操作。最后需要在底层网络使用组播来支持泛洪可能成为一个问题，这取决于部署中底层网络的类型。

这些问题并不是说VMware公司的软件具有可扩展性问题，而是说明了部署商业化解决方案中的一个现实情况：客户有极大的可能拥有一个以上的服务器/控制器。为此，相应的体系架构或者需要具有独立性（即作为独立单元运行的整体），或者需要在运行中支持联盟模式（即多个服务器集群能共同工作来分享状态）。

表4-1：VDS的可扩展性VDS1,2,3

特性 | 5.0版本的上限 | 5.1版本的上限
每个vCenter服务器的VDS数量 | 32 | 128
每个vCenter服务器的静态端口组数量 | 5000 | 10000
每个vCenter服务器的分布式端口数量 | 30000 | 60000
每个VDS的主机数量 | 350 | 500

1.http://www.vmware.com/pdf/vsphere5/r50/vsphere-50-configuration-maximums.pdf
2.http://www.vmware.com/products/datacenter-virtualization/vsphere/distributed-switch.html
3.https://www.vmware.com/pdf/vsphere5/r51/vsphere-51-configuration-maximums.pdf

4.2.2　Nicira的控制器

Nicira公司成立于2007年，为此被认为是SDN市场中，继VMware公司之后的一个后来者。Nicira公司的网络虚拟化平台（NVP）发布于2011 年。NVP并不是类似于VMware的资源管理应用套件，反而，它更多的是一个经典的网络控制器，所管理的资源仅有网络。NVP目前和其他的云虚拟化服务一同工作，包括计算、存储和镜像管理等。

NVP和OVS（Open vSwitch，开放虚拟化软件交换机）10协同工作。OVS是虚拟机管理程序上被NVP控制器集群控制的软件交换机。这是NVP的一个优势，因为OVS几乎被所有的虚拟机管理程序11所支持，而且实际上是一些商业网络硬件设备中交换机制的基础。此外，OVS已经成为Linux 3.3版本的一部分，这将成为NVP的进一步优势。直到NXP被推出之前（NXP被认为是整合VMware 公司软件和Nicira公司软件功能的第一步），Nicira需要一个称为Nicira OVS vApp 的VM在VMware ESXi环境中正常运行。这个vApp需要集成在每一个ESXi 虚拟机管理程序的实例上。尽管Nicira公司是ONF 成立时的会员之一，而且其主要员工都具有开发OpenFlow 的背景，但Nicira 仅仅在很少程度上使用了OpenFlow。这一点和其他的SDN 控制器有很大区别。对于OVS 的大多数编程工作是通过一个类似于数据库的协议OVSDB（Open vSwitch Data Base Management Protocol，OVS数据库管理协议）来达成的12。OVSDB 提供一个强化的虚拟机管理程序内集成的交换机或者其他网元设备的管理接口，可以利用OVSDB 来对隧道、QoS和其他深入的管理任务提供可编程支持，而OpenFlow是不具备这样的能力的。

10.http://openvswitch.org
11.ESX、ESXi、Xen、Xen Server、KVM 和 HyperV。
12.https://datatracker.ietf.org/doc/draft-pfaff-ovsdb-proto/

OVSDB 具备如下的典型特征。

- 利用JSON 作为模式的格式（OVSDB是模式驱动的）和OVSDB协议；

- 事务性；
- 非SQL；
- 持久性；
- 性能监控（类似于分发-订阅的报警机制）；
- 对服务开通配置及运行状态都进行存储。

Nicira公司的NVP控制器（图4-4）是一个通常具有三台服务器的集群，集群中通过数据库同步机制来共享状态。Nicira公司采用了服务节点的概念，服务节点被用来分担虚拟机管理程序节点的各种处理。广播、组播和未知的单播流量由服务节点处理（IPSec隧道端点也放在服务节点上）。这样的架构也可以用于跨虚拟机管理程序的流量处理，或者作为跨域互联的端点。

图4-4：NVP OVSDB 与虚拟交换机及第三方硬件的交互

Nicira公司有一个二层或者三层的网关产品，用于将Nicira STT隧道叠加层转换为VLAN（二层）及VLAN之间的连接，或者提供类似于NAT的功能，将租户网络地址空间（私有网络地址空间）转换到公共网络地址空间。图4-5 描述了基本的NVP组件关系。

图4-5：Nicira 公司的SDN 控制器组件

OVS、网关和服务节点支持冗余的控制器连接，这样可以获得更好的可用性。NVP Manager（NVP 管理器）是一套具有基本Web界面的管理服务系统，主要用来进行故障诊断和连接验证。当用户使用NVP Manager的Web界面时，NVP Manager在后台实际上主要调用的是REST API。对于应用程序开发者，NVP提供了一套RESTful API接口，不过这套接口是其私有的。

Vmware/Nicira控制器与理想化的SDN框架之间的关系

图4-6描述了VMware公司/Nicira公司的控制器的组件和理想化的SDN框架之间的关系。更特别的是，Nicira公司的控制器提供了一系列RESTful北向编程接口及网络流程编排功能。这些功能允许用户创建一个网络叠加层，并将其连接到来自vCenter/vCloudDirector中的管理网元设备的功能。此外，Nicira公司的控制器提供VxLAN、STT、OpenFlow 南向封装能力，以及支持配置南向OVS的OVSDB可编程能力。

图4-6：VMware 公司/Nicira 公司软件的组合的能力（相比于理想化的控制器框架）

4.2.3　VMware/Nicira的控制器

由于VMware公司对Nicira公司的并购13，两者的产品无论在讨论中还是在市场上都联系在一起了。尽管两者的产品是独立开发的，但是很快被整合成了一套无缝的解决方案14。Nicira公司和VMware公司的产品都提供私有的北向应用编程接口API，并利用私有的南向接口/协议和真实的或者虚拟的网元设备进行直接连接。

13.http://blogs.vmware.com/console/2012/07/vmware-and-nicira-advancing-the-software-defineddatacenter.Html
14.VMware 公司产品融合了Nicira 公司的SDN 技术，并透露了其公有云计划。

Nicira 公司产品支持OpenStack 插件，用于扩展其在数据中心业务或者资源管理中的能力。

4.2.4　OpenFlow相关的控制器

大多数开源的SDN的控制器都是完全基于OpenFlow协议的，这是因为其设计多数源自于Onix（图4-7）15。相比之下，只有很少数商业产品完全基于OpenFlow。实际上，不少商业产品都是将OpenFlow和其他协议联合使用的。

图4-7：Onix 控制器模型

15.http://static.usenix.org/events/osdi10/tech/full_papers/Koponen.pdf

与VMware/Nicira公司的解决方案， 或者其后的L3 VPN/PCE解决方案不同，OpenFlow解决方案不需要任何额外的分组封装或者网关。不过为了和OpenFlow及非OpenFlow网络中的网元设备交互，有时候也需要混合操作。实际上，此场景是存在着广泛需求的一个部署模型。

除非特别说明，开源的OpenFlow控制器解决方案都采用内存驻留或者内存数据库以用于状态存储。

Onix与理想化的SDN框架之间的关系

图4-7说明了一般的开源控制器组件和理想化SDN框架之间的关系。由于大多数控制器是基于Onix 的代码和架构的，它们和理想化SDN框架之间的关系是类似的。这一点会随着各个项目的进展发生改变。此外，Floodlight控制器（本书将在后面讨论）是一个例外。不过，当前的开源控制器和理想化SDN 框架之间关系的相似性还是基本成立的。

Onix控制器模型和理想化SDN框架最相关的一点， 就是它提供一系列北向的RESTful接口。这些接口可以用来编程、查询和配置控制器的各项功能，例如基本的控制器功能、流和转发表项编程，以及拓扑相关功能。所有的控制器都支持OpenFlow的某个版本，包括最新的1.3标准。此外，控制器还支持对于OpenFlow协议的一些扩展，用来增加OpenFlow协议的能力。尽管没有直接说明，但所有的基于Onix的控制器都采用内存数据库的概念来用于状态管理。图4-8说明了一般的 开源OpenFlow控制器的组件和理想化SDN框架之间的关系。

图4-8：开源OpenFlow 控制器/Onix 的能力（和理想化的控制器框架对比）

4.2.5　Mininet仿真器

在介绍流行的基于Onix的SDN控制器之前，本书先用一些篇幅来介绍Mininet。Mininet是一个网络模拟器，可以在一个Linux内核上模拟出多个主机、交换机、路由器和链路。所有这些网元设备都被称为“host”。Mininet使用轻量级的虚拟化技术使得单个系统看起来如同一个运行相同内核、系统和用户代码的网络。Mininet对于开源的SDN社区是非常重要的，经常用于仿真、验证、测试和资源提供。Mininet是GitHub上的一个开源项目。如果读者有兴趣想要获取可自由查看的源代码、脚本和文档，请访问GitHub。

一个Mininet主机的操作就像一台真实的机器，这些主机一般运行相同的代码，或者至少有能力运行相同的代码。通过这种方式，一台Mininet主机看起来就像一台机器的shell，可以安装和运行任意的程序。这些自定义的程序可以通过一个看上去实际存在的以太网来发送、接受和处理分组，而这个“以太网”实际上就是虚拟交换机或者接口。分组被虚拟交换机处理，虚拟交换机对于Mininet主机来说，看起来如同真实的以太网交换机或者路由器。实际上，商业版本的Mininet 交换机（例如来自于思科公司或其他公司）可以说相当准确地模拟了对应的商品交换机的关键特性，例如队列深度、处理规则和策略处理等。Minine的一个非常酷的特性，就是其基于Mininet 的网络的性能，常常非常接近非模拟的网络的性能。

图4-9描述了一个简单的Mininet网络。这个网络包含三台主机、一台虚拟OpenFlow交换机和一个OpenFlow控制器。所有的组件都通过虚拟以太网进行连接，并配置了net-10私有IP地址。如同前面提到的，Mininet支持非常复杂的拓扑结构，可以近乎任意的大小和顺序。为此，在配置文件中进行简单的粘贴、复制和重命名，就能够得到一个具有两台交换机和六台主机的网络，以此类推。

图4-9：Mininet 网络的简单示例

Mininet被广泛用于实验的一个重要原因，就是它允许创建自定义的拓扑。拓扑可以是复杂的、实际的，例如大规模的类似于互联网的拓扑可以用于BGP的研究。Mininet另外一个很酷的特性，就是它允许对分组转发的完全定制化，使得主机程序可以模拟商品交换机上的程序。此外，在可以基于OpenFlow协议编程的主机上已经进行了一些新颖的和创新性的实验。这些实验使用了本书将要讨论的这些基于Onix的控制器。

4.2.6　NOX/POX控制器

根据NOX/POX 网页上的说明16，NOX17是由Nicira公司开发的，并被捐赠给了研究社区，因此它从2008年开始就是开源的。事实上，这使得NOX 是第一个开源的OpenFlow控制器。NOX后继被开放式网络实验室ON.LAB18支持并扩展，其主要的贡献者来自于伯克利大学和ICSI。NOX提供OpenFlow(OF v1.0) 的C++ API。NOX采用异步的、基于事件的编程模型。

16.http://yuba.stanford.edu/~nickm/papers/p105-v38n3u-mckeownA4.pdf
17.NOX 和POX 的信息都可以在http://www.noxrepo.org/forum/ 获取。
18.http://onlab.us/tools.html

NOX是最初的控制器，采用了基于组件的框架来开发SDN应用程序。NOX提供针对OpenFlow 设计的支持模块，并进行了扩展。NOX核心提供helper（助手）方法和API用于和OpenFlow交换机的交互，这包含连接处理器和事件引擎。另外还有一些利用其API 的组件，包括主机追踪、路由、拓扑构建（LLDP），以及一个作为组件API封装的Python 接口。NOX 的架构如图4-10所示。

图4-10：NOX 体系架构

NOX通常被用在学术界的网络研究中，用于开发对网络协议进行研究的SDN应用程序。NOX在学术界流行的一个很好的结果就是有很多的示范代码，例如模拟MAC学习交换机或者全网交换机。这些代码可以作为各种项目和实验的基础。

SANE和Ethane是NOX上的两个著名应用程序。SANE是一种将网络表达成为一个文件系统的方法。Ethane是斯坦福大学的一项研究，用于传统的ACL级别的集中式的全网范围的安全。这两个应用程序都展示了相比于传统方法，SDN可以非常有效地降低实现相似功能的代码量19的特点。基于这项成功，研究者在NOX核心之上展示了类MPLS的应用程序。

19.http://yuba.stanford.edu/~casado/nox-ccr-final.pdf

POX是更新的、基于Python的NOX的版本（或者说是基于Python的NOX）。POX的开发是为要还原NOX的C++核心，并开发一个独立的基于Python的平台（Python 2.7）20。POX 有一套高级的SDN API，包含一个可查询的拓扑图以及对虚拟化的支持。

20.实现了一个完全基于C++ 的NOX。

POX 相对于NOX 具有如下的优势。

- POX具有Python化的OpenFlow接口。

- POX具有可重用的示例组件，例如路径选择、拓扑发现等。

- POX是跨平台的，并且可以在运行时与无需安装的PyPy相绑定来简化部署。

- POX针对Linux、Mac OS和Windows进行了优化。

- POX支持和NOX相同的GUI及可视化工具。

- 相比于NOX上基于Python的应用程序，POX的性能更好。

NOX和POX目前采用OpenFlow v1.0，并且针对Open vSwitch进行了特别的支持。

4.2.7　Trema控制器

Trema21是一个为开发OpenFlow控制器设计的OpenFlow的编程框架。Trema最开始是由NEC 开发和支持的，后来得到了开源社区的支持（基于GPLv2）。

21.http://trema.github.com/trema/

与之前常见的以OpenFlow为中心的控制器不同，Trema模型提供了基础设施服务作为其核心模块的一部分，用于支持用户模块的开发（Trema apps22）。开发者可以用Ruby或者C 语言创建其自己的用户模块（当执行速度要求比较高时，推荐C语言）Trema 核心模块提供给应用程序的主要API是一个简单的、非抽象的OpenFlow 驱动（处理所有OpenFlow 消息的接口）。Trema目前通过一个资源库（TremaEdge23）来支持OpenFlow 1.3.X。

22.https://github.com/trema/apps
23.https://github.com/trema/trema-edge

Treme不提供用来支持of-config配置协议的NETCONF的驱动。

本质上，一个Trema OpenFlow控制器是一个可扩展的Ruby脚本集。开发者可以通过定义其自己的控制器子类，并增加消息处理程序，来个性化或者增强基本的控制器能力。

基本的Trema控制器设计是事件驱动的（通过回溯/ 命名约定的分发机制）。为此，Trema控制器经常（被Trema支持者们满意地）与其他开源产品的显式处理分发范式进行对比。

此外，如图4-11所示，Trema核心模块提供消息总线（基于Messenger的IPC机制），允许应用程序/用户模块相互之间以及与核心模块之间通信。通信机制开始是点到点的模式，后来改变为分发/预订模式。

图4-11：Trema 的核心/ 用户模块之间的关系

其他的核心模块包含计时器、日志库、分组解析库，以及哈希表和链表结构的库。

Trema核心并不提供所有状态管理机制以及数据库存储结构。这些机制被包含在Trema应用程序中，并且可以成为使用数据结构库时的默认内存存储24。

24.对于Trema 的SQLite 接口存在一些讨论。

Trema的基础设施提供一个CLI和配置文件系统，用于配置和控制应用程序（在加载时解决依赖）、管理消息和过滤器、通过NDSL（Network Domain Specific Language，网络域描述语言，是Trema 特有的配置语言）配置虚拟网络。

Trema的吸引力在于它是一个全功能的、简单的、模块化的快速原型和开发环境，但只有很小的代码量。开发环境包含网络/主机模拟器和调试工具（集成了单元测试、分组生成/Tremashark 抓包器/Wireshark 抓包器）25。Trema 应用程序/用户模块包含一个拓扑发现和管理单元（libtopology）、一个流/路径管理模块（libpath）、一个负载均衡交换机模块和一个可切片的交换机抽象（能够支持多个OpenFlow 交换机管理）。另外还提供一个OpenStack Quantum 插件，用于可切片的交换机抽象26。

25.整个环境，包括模拟网络和主机，可以运行在笔记本上。
26.https://github.com/nec-openstack/quantum-openflow-plugin

尽管Trema的一个应用就是软件OpenFlow交换机（从各方面描述来看要比OVS简单），但一个基于Trema的OpenFlow控制器可以与任何支持OpenFlow的网元设备交互（OpenFlow版本兼容性方面），并且不需要设备支持特别的代理。图4-12描述了Trema的体系架构。

图4-12：Trema体系架构和API接口

每个用户模块（Trema应用程序）都可以发布RESTful接口。模块化以及为每个模块提供API（或为每个应用程序提供服务）的组合使得Trema不仅仅是一个典型的控制器（典型控制器为所有服务提供统一的接口）。Trema的相关资料认为Trema是一个框架，而不仅仅是一个控制器。这一点将在后面的章节展开。

4.2.8　Ryu控制器

Ryu27是一个基于组件的完全用Python实现的开源框架（如图4-13所示），由NTT公司实验室（NTT Labs）进行支持。不过Ryu消息服务也支持用其他语言开发的组件。

图4-13：Ryu的体系架构、应用程序（不完全的）和API

27.http://www.osrg.net/ryu/

Ryu的组件包括OpenFlow协议支持（支持到OF1.3版，并包含Nicira的扩展）、事件管理、消息机制、内存状态管理、应用程序管理、基础设施服务和一系列可重用的库（例如NETCONF库、sFlow/Netflow库）。 此外，Ryu提供一些应用程序和服务，例如Snort（侦测）、二层交换机、GRE隧道抽象、VRRP、拓扑和统计服务等。

在API层，Ryu有一个Openstack Quantum插件， 支持基于GRE的叠加网络和VLAN配置。

Ryu针对其OpenFlow操作也提供了REST接口。

Ryu有一个利用HBase来进行统计存储的原型组件，另外还提供相应的可视化和分析功能。

通过一个Zookeeper组件，Ryu具有很好的可用性，但是Ryu目前并不支持多个控制器进行协作和以集群的方式对网络进行管理。

4.2.9　Big Switch公司/Floodlight控制器

Floodlight28是一个非常流行的SDN控制器。Big Switch公司创建了Floodlight并贡献给了开源社区。实际上，Floodlight是基于斯坦福大学的Beacon 控制器开发的。Floodlight采用了Apache授权，是一个基于Java实现的OpenFlow控制器（但不是OSGI架构的）。Floodlight的架构和API接口是与Big Switch公司提供的商业版本Big Network Controller (BNC) 控制器共享的29。

28.http://www.projectfloodlight.org/floodlight/
29.尽管本书的重点放在人们非常熟悉的开源Floodlight上，但为了比较，其商业版本BNC也被纳入讨论。通过BNC，BigSwitch提供了虚拟化应用和BigTap应用。

Floodlight的核心架构是模块化的，包括拓扑管理、设备管理（MAC和IP追踪）、路径计算、Web访问和管理、计数器存储（OpenFlow计数器）以及一个面向状态存储的广义存储抽象（最开始默认初始存储在内存中，不过后来支持SQL和非SQL的后台存储抽象，这样可以基于第三方的开源存储解决方案）。

这些组件可以看成是可加载的、具有状态输出接口的服务。控制器自身具有一套可扩展的REST API以及事件通知系统。这套API允许应用获取和设置控制器的状态，并预订由控制器发出的事件（利用Java Event Listeners），如图4-1430所示。这些都是向程序开发人员提供的典型方法31。

图4-14：Floodlight/BNC组合的体系结构，包括开源的组件（无色的组件是属于商业版BNC产品的）。BNC版本的控制器增强了很多核心的功能

30.这里并没有穷举BNC 商业版本的所有应用，而只是列举了与理想化的控制器相比，较为关键的应用。
31.在其商业版本中，Big Switch Networks公司产品结合了对NoSQL分布式数据库的支持、状态变迁通知的分发/预订机制，以及其他的提供水平扩展和高可用性的工具。这就造成了商业版本和开源版本的本质区别。

Floodlight的核心模块称为Floodlight Provider，其处理来自交换机的I/O请求并OpenFlow 消息翻译为Floodlight事件。为此，Floodlight采用了一种事件驱动的异步应用框架。Floodlight采用了一种允许模块共享线程的线程模型。事件处理发生在事件发布模块的线程上下文中。同步锁用于保护共享数据。组件间的依赖关系是在加载时通过配置来确定的。

拓扑管理器通过LLDP协议（ 大多数OpenFlow 交换机都支持此机制）来发现OpenFlow和非OpenFlow的网络端点。

Floodlight提供一些示范的应用程序，包括MAC学习交换机（这种OpenFlow交换机的抽象是大多数开发者定制或开发的初始状态）、集线器和静态流推动器（StaticFlow Pusher）等应用程序。

此外，Floodlight还提供了OpenStack Quantum插件。

Floodlight OpenFlow控制器可以和任何支持OpenFlow的网元设备互操作（ 在OpenFlow版本兼容性方面，在本书撰写之时，在本书撰写之时，对of-config和OF 1.3 的支持还在规中）。Big Switch公司提供了一个开源的OpenFlow代理（Indigo32），并被集成到商业版本中。此外，Big Switch公司还提供一个开源的OpenFlow库生成器Loxi，可以支持多语言33，用于解决对多版本的OpenFlow支持问题。

32.http://indigo.openflowhub.org
33.http://www.projectfloodlight.org/blog/2012/10/02/preview-of-indigo-v2-0-and-loxi/

Floodlight也可以看成是一个以Java/Jython为中心的开发环境，提供了丰富的开发和调试工具集，包括Packet Streamer以及前面提到的Static Flow Pusher。此外，Mininet34可以被用作Floodlight的网络模拟器。

34.https://github.com/mininet

由于Floodlight体系架构采用了restlets35，所以在其所提供的环境下开发的任何模块都可以通过IRestAPI服务来提供更多的REST API接口。Big Switch公司已经开始积极开发一个从YANG模型到REST接口的数据模型编译工具，用于增加其API发布和数据共享能力。这些功能可以被用来开发现在的控制器并不存在的新功能，例如状态和配置管理。

35.http://www.restlets.org

Floodlight与理想化的SDN框架之间的关系

如同在前面提到的那样，Floodlight和Onix控制器代码在很多方面是高度相关的，为此具有很多体系架构层面的相似性。大多数基于Onix的控制器利用内存数据库（至少从概念上）进行状态管理，但是Floodlight是一个例外。Floodlight尽管基于Onix，但是提供了一个称为BigDB的数据库组件。BigDB是一个NoSQL的、基于Cassandra的数据库，可以用于存储各种信息，例如配置和网元设备的状态。

对于Floodlight的超集即其商业版本的BNC 及其应用程序，在与理想化的控制器相比时，足以和VMware/Nicira 的组合相媲美（参见图4-5）。相比之下，BNC支持单一的、非私有的南向接口（OpenFlow）。

4.3　以网络三层为中心的架构

支持L3VPN叠加网络（例如瞻博公司的Contrail控制器）和L2VPN叠加网络（例如Alcatel Lucent公司的Nuage控制器36）的控制器已经出现在市场上，并且促生了虚拟运营商边缘（virtual Provider Edge，vPE）的概念。PE功能的虚拟化是由一个提供服务和平台虚拟化的SDN 应用程序完成的。控制器除了用来构建以辅助服务开通配置的自动化，还有其他一些功能，如集中的标签分配以及vPE上的控制协议负担的缓解机制等。

36.http://www.nuagenetworks.net/press-releases/nuagenetworks-introduces-2nd-generation-sdn-solutionfordatacenter-networks-accelerating-the-move-to-business-cloud-services/

另外，路径计算引擎（PCE，path computation engine）服务器也被认为是一种潜在的控制器或者是对当前控制器的增强，它可以在支持MPLS的网络中创建MPLSLSP叠加网络。这项功能可以用于叠加网络抽象，以及在基于源/目的路由的IP网络中使用MPLS标签，而无需启用传统的标签分发机制或者隧道/路径信令协议如LDP和RSVP-TE。

4.3.1　三层VPN的控制器

在这种设计背后的想法是，一个VRF（Virtual Routing and Forwarding，虚拟路由和转发，这在L3VPN中是常见的）可以代表一个租户网络，这时用于L3VPN的传统工具可以被用来创建基于MPLS标签的叠加网络，进而在主机、服务网元设备和数据中心网关上进行客户的分离。

这种解决方案的潜在优势是，理论上更容易缝合到现有位于数据中心网关的客户VPN中，方便地创建可用于云突发场景的应用程序。这就强化了这个方案的优势，即可用基于标准的BGP地址族来承载用于实现VRF/租户的网络原语状态。

瞻博公司从其所收购的Contrail Systems公司获得了SDN控制器。现在瞻博公司提供一个看起来像虚拟路由反射器的控制器，该控制器提供和其内部服务API对应的OpenStack API。瞻博公司的控制器采用一种高级的数据模型（最开始的设想是基于IFMAP37的），它会自动产生一套REST API呈现给SDN应用程序，如图4-15所示。图4-15说明的是一个数据中心服务编排的应用程序，该应用程序可以提供基于主机的虚拟路由器用于连接所有的叠加网络。该控制器提供的API 和OpenStack Quantum API有所交叉，被用于对整个系统进行服务编排。

图4-15：瞻博公司的虚拟网络SDN 控制器的高级操作

37.http://www.trustedcomputinggroup.org/resources/tnc_ifmap_binding_for_soap_specification

瞻博公司的控制器采用由多个子系统组成的多节点设计。这种设计的出发点是为了提供更好的可伸缩性、可扩展性和高可用性。该系统支持可以作为独立虚拟机运行的独立模块，这样可以向外扩展分析、配置和控制能力，具体如下所述。

- 分析
提供统计信息/计数器的查询接口和存储接口。

- 配置
提供一个编译器，使用高级数据模型来将网络动作的API请求转换为低级数据模型用于控制代码的实现。

- 控制
利用BGP在控制器之间（ 或者管理域之间） 进行水平方向上的状态分发（L3VPN网络原语通过XMPP命令进行分发，如VRF、路由、策略/过滤规则），实现底层数据模型。控制服务器也通过XMPP信道收集统计和其他管理信息。

控制节点利用BGP协议来分发网络状态，这种标准协议具有良好的水平可扩展性和多个厂商之间的互操作性。不过目前这种模式最有用的还是和当前的BGP网络进行互操作。这种体系结构吸取了近期的、公开的体系结构项目的经验，包括处理大量的、易变的数据存储，以及模块化的组件通信。

瞻博公司的Contrail控制器内嵌了开源的解决方案。例如，Cassandra38被用于存储分析数据、大多数操作的数据以及IF-MAP（Interface for Metadata Access Points，元数据访问点接口）数据。Redis39被用于构建一个组件和应用间的支持分发/预订的消息系统。需要说明的是Redis最开始是由VMware公司赞助的。Zookeeper40被用来发现和管理网元设备。

38.瞻博公司并不以Cassandra作为唯一的NoSQL数据库，并且发布了一个API用于替换解决方案。
39.http://redis.io/
40.zookeeper.apache.org

和所有SDN控制器一样，瞻博公司的解决方案需要网元设备中有对应的代理程序，无论它们是真实的设备还是在VM 中的虚拟设备。在第二种场景中，一般是一个驻于虚拟机管理程序中的vRouter 和用户空间的VM（vRouter Agent）的组合41。在第一种场景中，一般通过Netconf、XMPP 和标准的BGP协议来进行配置的通信。

41.和最新的NSX 之前的Nicira/Vmware ESX 情况类似。

控制节点和vRouter Agent之间的通信/消息传递机制，被设计为基于XMPP的开放标准。但XMPP 协议仅仅定义了传输的容器，容器中的内容需要被明确定义来保证互操作性。

针对这些运行范式，目前已经提交了一些RFC 草案，其中包含整个系统如何进行单播、组播和支持策略/ACL：

- http://tools.ietf.org/html/draft-marques-l3vpn-end-system-05

- http://tools.ietf.org/html/draft-marques-sdnp-flow-spec-01

- http://tools.ietf.org/html/draft-marques-l3vpn-mcast-edge-01

此外，还有一项草案提出了非运行状态迁移（transfer of non-operational state）的IF-MAP 方案：

- http://tools.ietf.org/html/draft-marques-sndp-l3vpn-schema-00

vRouter Agent将XMPP控制消息转换为租户网络对应的VRF实例，并且为vRouter的转发平面的网元设备产生合适的FIB表项，如图4-16和图4-17所示。

图4-16：控制器和瞻博公司的vRouter 之间的交互

图4-17：瞻博公司的vRouter 中的多租户

瞻博公司的解决方案实现利用了端口复用技术（unnumbered）来节约IP地址。此外，还提供了基于MPLS标签的多租户隔离方案，支持MPLS-in-GRE 和MPLSin-VxLAN封装。这套解决方案并不需要传输网络支持MPLS交换。与VMware/Nicira公司的解决方案相类似，这个解决方案提供了基于软件的网关，用于与不支持vRouter代理的设备进行交互。

Contrail与理想化的SDN框架之间的关系

图4-18将瞻博公司的Contrail控制器的组件和理想化的SDN框架进行了映射，其中深色的部分是该控制器实现的部分。Contrail平台实现了一个RESTful的北向API，用于应用程序和业务流程编程，另外还包含了OpenStack API集成。此外还整合了HA/集群、内存数据库和NoSQL数据库用于状态存储。对于南向协议，可以注意到XMPP被用作控制器和虚拟路由器之间的信道，此外还有一些其他的南向协议，例如BGP。

图4-18：Contrail VNS 的功能（与理想化的控制器框架相比）

4.3.2　路径计算单元（PCE）服务器

1. RSVP-TE问题描述
在RSVP-TE网络中，建立TE LSP有两个判断准则：需要的带宽（以及一些其他的约束），和当信令创建LSP标签时的可用带宽。

这里的问题在于，当多个LSP（可能来自于不同的LSR）同时产生LSP信令时，将会竞争相同的资源（即一个特定的节点、链路或者其中的带宽）。当这种情况发生时，LSP建立和保持优先级机制必须被调用，以产生LSP的优先关系。否则，LSP的建立将是基于先到先服务的原则，这将使信令有很大的不确定性。

相反，当LSP信令发出但是其他的LSP已经存在时，LSP抢占机制将被用来抢占低优先级的LSP的资源。

即便利用该机制，在普通和重载的情况下，不同的入口路由器发出LSP信令的顺序也决定了实际被选择的路径。

假设有两个集合的LSP，其中一个集合包含两个优先权为1的LSP（记为A和B），另外一个集合包含两个优先权为2的LSP（记为C和D）。假设当前某个节点上的带宽资源仅仅能够满足一个LSP。这样如果A和B的信令发出，将仅仅只有A和B中的一个LSP被建立，这取决于哪个信令先被发出。如果这时发出C和D的信令，先发出的信令将会抢占A或者B的资源，但是仅仅只有最后发出信令的LSP会最后存在。如果改变发出信令的顺序，就会得到一个不同的结果。

事情就是这样：LSP的优先级与抢占机制的组合，耦合了每个入口路由器的路径选择。

在实践中，这一结果或多或少是期望的结果；然而，由于这种不确定性，导致很难先验地对网络真实行为进行建模。

2. Bin-packing（装箱）
当一条RSVP LSP的整个路径上的带宽都能满足需求时，才能成功地完成LSP建立。很多时候，即便是在网络整体并不繁忙的情况下，也是无法找到这样的路径的。

在图4-19 中，Gb前的数字代表了链路上的可用带宽。如果想建立从R1到R5的4Gb LSP，由于R3 和R5之间的链路仅仅只有3Gb的带宽，建立过程将失败。然而，R3-R5和R3-R4-R5带宽的总和是5Gb（3+2）。为此，网络中实际会有足够的带宽，但是由于RSVP信令的特性，会导致无法充分利用可用的带宽。

图4-19：简单的TE 网络

于是，这里就产生了一个装箱问题：如何最大化地利用网络中的可用带宽？

3. 死锁
此外，当LSP优先级没有被使用或者同样优先级的LSP发生了冲突时，可能出现死锁或者低效的资源利用。如图4-19，当R1想建立一条3GB的LSP到达R5（通过R1-R2-R3-R5）时，R2同时R2想建立一条2GB的LSP到达R5（通过R2-R3-R5），这时仅有一个会成功。如果R2成功了，R1将找不到到达R5的可用路径。

4. PCE解决方案
在PCE开发之前，网络运营商为了解决这些问题，使用了复杂的规划工具以找出正确的一组LSP优先级用来获得所需的网络行为，并管理和协调这些LSP的配置，这是一项非常繁重的任务。另外一个方法是超额地提供(Over-provision) 网络带宽，这样就可以避免这些复杂性。

PCE（path computation element，路径计算单元）允许网络运营商将MPLS LSP计算工作委派给一个外部控制器完成。

当和BGP-LS的活动拓扑组合时（在第8章讨论），网络运营商就可以利用前面提到的复杂工具通过极其简化的配置步骤（通过PCE）来（几乎是实时地）解决这些问题。

PCE环境中有多个组件：一个PCE服务器、一个PCE 客户端（PCC）以及PCE协议（用于在PCE 服务器和PCC 之间交换数据）。

PCE 经历了如下几个阶段的发展。

- PCE 服务器通过无状态的方式管理预先配置LSP；

- PCE 服务器通过有状态的方式管理预先配置LSP；

- PCE 服务器通过有状态的方式管理预先配置和动态创建LSP。

PCE服务器提供三种基础的服务：路径计算、状态维持、基础设施和协议支持。PCE服务器利用PCE协议向网元设备或者PCC传递信息。理想情况下，PCE服务器实际上是一个活动拓扑信息的使用者。虽然还有其他的来源，例如路由协议更新、新的I2RS通用拓扑以及ALTO服务器，但至少部分活动拓扑是从BGP-TE/LS协议中获取的。

随着PCE服务器的发展，路径计算的算法将和其配置代理程序松耦合，例如通过一个核心API将原算法更换为自身设计的算法。这会是一个重要的改进，因为不同客户的商业实践和需求将会促生不同的算法，同时第三方工具也可能促生一些新的算法。

5. 与理想化的SDN框架之间的关系
如图4-20所示，PCE服务器或者控制器只关注了理想化的SDN框架的很小部分。在这种情况下，尽管它提供了一套RESTful的北向API来提供众多的可编程选项，但是仅仅只使用了单一的南向接口协议PCE-P。这是因为PCE控制器一般只看做是现存控制器的补充。

图4-20：PCE 服务器的能力（与理想化的控制器框架相比）

PCE控制器解决方案中的其他组件可能是SDN 控制器的典型组件，例如状态管理、可视化、组件管理、面向应用程序的RESTful API等，如图4-21所示。对于API，为了和服务编排引擎无缝成，需要包含API转换功能，例如OpenStack Quantum插件。

图4-21：PCE服务器组件（非完全的/概念性的）

PCE服务器的原生应用就是创建跨域的、具有明确路径的MPLS-TE隧道。其动机就是为了避免跨运营商的运行障碍，到目前为止，这一点依然是困难重重。PCE服务器可以作为多个运营商的中间点，由于其具有对每一个运营商网络足够的可视性，所以能够建立比仅仅基于本地视图的路由协议更为优化的路径。在骨干网带宽管理上，PCE服务器也有引人注目的案例，例如在现存MPLS LSP 机制上的更加优化的装箱算法。此外，对于接入网，PCE 服务器也可以用于服务管理等功能。

MPLS TED（Traffic Engineering Database，流量工程数据库）在传统的IP/MPLS网络中最开始是作为IGP数据库的扩展被分发的。一般情况下，对MPLS TED的分发终结于区域的边缘，这意味着跨域隧道的明确路径，仅仅只到隧道起点区域的边缘。到边缘之后，因为不知道确定的路径，只能是在ERO中规定一个宽松的跳数。一般情况下，这会导致次优路径。作为这个问题的一个解决方案，BGP-TE/LS通过一个特别的BGP 地址族将TED导出到一个中心式的拓扑存储。中心拓扑存储对各个区域的TED进行整合，允许一个离线应用，基于网络拓扑更加全局的视图，来计算明确的端到端路径。

由于MPLS LSP提供了基于MPLS封装的叠加网络并用于基于MPLS的标签进行流量转发，所以PCE 服务器可以自己或者和其他SDN技术结合起来成为一个SDN 控制器（如图4-22）。MPLS LSP信令从路径头部节点通过RSVP-TE发出。通过这种方式，基于PCE的解决方案可以发信令、建立并管理跨多个管理域或者仅是路由区域的LSP隧道。这些隧道可以是更加优化的，或只是根据不同运营商的需要而有所不同的，这是原来因设备没有实现而无法做到的。

图4-22：PCE服务器操控LSP的ERO将源自A的路径的终点从Z改成Y；BGP-TE/LS实现向PCE提供了冗余的拓扑来源

PCE服务器的另外一个新的应用与网段路由（segment routing）42有关。在网段路由场景中，PCE服务器可以通过一个通用的ERO对象（实际上是一个标签栈）创建一个LSP。这一点是通过PCE 服务器的编程控制完成的。PCC可以创建一个基于标签栈的转发条目用于模拟MPLS 叠加网络（即栈里只有一个标签）或者模拟TE隧道（即栈里有多个标签），而不用在网络中发起任何信令。更特别的是，做到这一点甚至都不需要使用RSVP-TE或者LDP协议43。

42.http://datatracker.ietf.org/doc/draft-previdi-filsfils-isis-segment-routing/
43.可以说，对于分布式控制平面复杂性的降低（至少面向会话的标签分发）是SDN的典型应用场景。

上述基于PCE的SDN应用实际上进行了网络的简化，允许网络管理者在一个减少了存储在骨干网络中的状态的更加抽象的层面上操控网络。此外，在服务链（service chaining）方面，基于PCE 的SDN也有一些潜在应用。

本地标签空间和节点地址、邻接点的联合（例如任意播环回地址）促生了基于网段路由的服务链的概念。标签绑定作为ISIS 协议的扩展被发布。

- 节点分段（Node segment）表示到达目标节点的ECMP-aware（可感知等价多路径的）最短路径。

- 邻接分段（Adjacency segment）允许运行者来表示任何明确的路径。

PCE 服务器可以将标签和操作（例如swap 或pop）绑定。默认的操作是将相同的标签进行“swap”。

如图4-23，一条从A到D的简单LSP被建立起来了，并从预留标签空间中分配了标签100。标签栈将标签100和D的回环地址关联起来（即，这个分段就是100）。一条基于RSVP-TE的路径可以用一个邻接标签（例如，500用于表示B-F的邻接分段）和节点标签（例如，300表示节点B和D）的组合来表示，其对应的标签栈就是“300 500 100”。

图4-23：利用PCE 服务器作为SDN 控制器的多段路由

尽管是非常有前途和有意思，而且这种方法还非常前卫，但还是有很多方面需要进一步的研究44。

44.http://datatracker.ietf.org/doc/draft-gredler-rtgwg-igp-label-advertisement/；http://datatracker.ietf.org/doc/draft-gredler-isis-label-advertisement/

值得注意的是，思科公司早已推出了基于其收购的Cariden Technologies公司的PCE服务器。Cariden Technologies公司早在2012年就已经发布了PCE服务器45。对于如何获取拓扑、如何进行路径计算以及其他的技术方面，其他的网络厂商还正在提出不同的方案。除了商业产品，一些服务运营商，包括Google公司，都表示将会开发自己的PCE服务器，用于实现其自身的策略和路径的计算算法。

45.<a href="http://www.sdncentral.com/sdn-blog/cardien-technologies-releases-service-provider-infrastructure-sdnwhitepaper/ 2012/08/">http://www.sdncentral.com/sdn-blog/cardien-technologies-releases-service-provider-infrastructure-sdnwhitepaper/ 2012/08/

4.4　Plexxi公司的控制器

Plexxi公司的主要产品以亲和性网络（affinity networking）的概念为核心。Plexxi提供一个稍有不同的控制器：一个分布式系统和与其紧耦合的私有转发优化算法。

Plexxi公司的控制器的主要功能是采集亲和性（affinities）的信息，可以是从外部系统动态采集的，也可以是以手动创建的策略静态获取的。然后，Plexxi公司的控制器将亲和性信息转换为Plexxi公司的网络中的转发拓扑。图4-24 简单描述了Plexxi公司的系统的体系架构。

图4-24：Plexxi 公司的系统体系结构（资料来源：Plexxi 公司）

Plexxi公司的物理拓扑是基于环的，其亲和性是与环的标识符相匹配的，为此形成了叠加网络和底层网络概念间的一个紧密绑定。有些人认为这个绑定更多是混合的，或者是将网络混合成一个单层架构。

这些拓扑架构表现为控制器域中跨多台交换机的转发规则的集合。Plexxi系统还有一些额外机制用于当控制器从网络断开时，在交换机中保存活动拓扑。

控制器的任务在一个集中式控制器和对应的协控制器（Co-Controller）之间进行分配。集中式控制器维护中心策略，执行管理和算法拟合任务。协控制器执行本地转发表维护和快速路由修复任务。

除了学习和创建亲和性，控制器还为运行和维护任务提供接口。这些接口包括一个REST API、一个Jython shell和一个图形界面。Jython shell具有一些提前定义的命令用于和控制机、交换机交互，另外可以通过Python编写自定义的CLI命令。图形界面采用JIT/GWT来自动创建物理网络和亲和性的图。

Plexxi公司的拓扑和转发编程是一个私有控制协议（PSCP）的一部分。转发编程采用ActiveMQ，控制器是基于PostgreSQL46的。

46.数据库复制（Plexxi公司的2013规划）可以复制配置和状态，用于多控制器或者冗余环境中。

Plexxi公司的控制器目前仅仅能和Plexxi公司的LightRail光交换机协同工作。

对于接在一个控制器下的一个环，Plexxi公司能支持多达250台交换机。Plexxi公司支持冗余和多环拓扑，用于扩展或者分离维护域47。

47.Plexxi公司提供详尽的网络设计指南，并且计划支持大规模和更加复杂的拓扑。

Plexxi公司和理想化的控制器框架之间的关系和其他具有私有南向API的控制器类似（类似于图4-18中的Contrail VNS）。一个区别是其独有的亲和性算法在拓扑和转发上造成了差异性。

Plexxi 的亲和性

亲和性包含一到两个亲和组，以及其中的亲和链接。一个亲和组是一个网络端点的集合，其中的网络端点用MAC 或者IP 地址来表示。一个亲和链接是一个策略的架构，用来描述亲和组之间，以及亲和组内部的端点之间的转发行为。

例如，亲和组A可以是一个存储集群的MAC 地址的集合，亲和组B可以是一对冗余的存储控制器。A 和B之间的亲和链接告知控制器将两者之间的流量从网络中进行隔离。通过Plexxi（connector）连接器，亲和性信息可以从任何网络系统设施中获取，例如IP PBX、存储系统、WAN优化系统、私有云系统（OpenStack，VMware）等。此外，亲和性可以从存储sFlow、netflow、IPFIX数据的流量监控系统中获取。

4.5　Cisco公司的OnePK控制器

思科公司的OnePK控制器是一个商业化的控制器。通过集成包括一个不常见的南向协议插件Cisco OnePK API在内的多个南向协议插件，OnePK 控制器体现出一种整体框架的设计理念。

其体系架构采用基于Java的OSGI框架，使用内存状态存储模型，并提供一个双向的、带认证的REST接口。通过Infinispan和JBoss封装及事物化工具，可以支持控制器集群模式。图4-25说明了思科公司的OnePK控制器的基本概念。

图4-25：思科公司的OnePK 控制器概念

思科公司表示，控制器逻辑可以解决多个应用程序之间转发规则的重叠和冲突，并且提供一个支持故障诊断、资源发现和映射的服务抽象。

主流的网络设备厂商向其客户提供设备的SDK（厂商特定的SDK实际上这是SDN之前网元设备编程的主要手段之一），这一现象并不罕见。但Cisco控制器的特点在于将SDK作为一般性的控制器框架中的一个插件进行提供。这使得即便是在SDN环境中，其SDK依然可以被使用，例如，可以混合OnePK API和OpenFlow。某些场景下，其SDK（或者控制器之上的SDK 应用程序）可提供比OpenFlow更多的价值。

与理想化的SDN框架之间的关系

与理想化的SDN框架相比，思科公司的OnePK控制器看上去是目前最好的控制器，它包含理想化的控制器的所有方面：可扩展的RESTful API、集成开发环境、多个计算引擎，以及可能是最广泛的与物理或虚拟的网络设备进行接口的南向协议。OnePK控制器支持内存驻留和离线的分布式状态管理及配置存储，它还支持水平方向上的控制器-控制器通信和协作。最后，控制器实现了一个抽象层用于支持多个南向协议和多个北向协议之间的 多对多通信，并能够很容易地进行扩展。这个抽象层正是将OnePK和其他控制器进行区分的关键技术。

基于这么多优点，OnePK成为开源SDN控制器的新金牌标准就毫不奇怪了。其证据就是，由Linux 基金会支持的OpenDaylight项目以OnePK控制器作为基础进行开发。

4.6　小结

SDN控制器这个词具有很多不同的含义，所以今天的控制器具有多种不同的形式。一个SDN控制器的具体含义源自其所运行的网络领域，而网络领域的含义来自于其中所使用的策略和协议选择。

用户常提到的多厂商之间的互操作性，是SDN能提供的最引人注目的特性，为此市场期望SDN控制器的行为是标准化的。然而，就现在SDN控制器的市场状态而言，这种情况并不常见。无论是好是坏，这就是事实：厂商们采用基于其产品或者应用程序的引人注目的私有技术和协议来为其产品开拓市场。在应用程序上采用私有技术是现实存在，因为实际上现在的应用程序都是基于非标准化API的，并与其相应的SDN控制器市场紧紧绑定在一起。

由于控制器与设备中代理之间的对应关系，以及当前并非所有的网元设备都支持代理守护进程/ 程序（代理程序实例化了用于网络抽象的网络状态传递协议），因此很多控制器产品采用了基于主机的网关作为解决方案。在这些网关中，代理程序将租户的叠加网络转换为可被非SDN控制的网元设备处理的格式，一般将租户的叠加网络转换为VLAN。这种策略使得新旧网络间的互操作成为可能，但是问题在于基于软件的网关可能降低分组处理的能力。

在本书中所讨论的控制器48具有如下的共有属性。

48.这并不是一个详尽的清单，也并非包括了所有当前可用以及历史上出现过的所有SDN控制器。

- 提供不同级别开发支持：语言、工具及其他。

- 商业产品往往具有私有的接口，但是（如预期地）提供了更加健壮的存储和更好的可扩展能力。

- 相比于集成的数据中心控制器解决方案，专用于网络状态管理的控制器的发展导致了一些新的策略，采用最近开发的产品来进行状态存储（例如，Big Switch 公司基于NoSQL 数据库的方案）、消息传递（例如，瞻博公司基于Redis的方案）和实体管理（例如，利用Zookeeper）。最终，商业产品必将选择在跨不同控制器的状态共享机制上的立场，或者是作为原子（Atomic）操作，或者是以联邦（Federation）的形式。

- 当前所有的控制器解决方案都只有对于拓扑的很有限的视图。一般情况下，只有网络中的一层，甚至只有邻居设备（例如在二层上用LLDP 发现设备）。对于PCE，一般只有BGP流量工程数据库。

- 只有极少数的控制器支持多于一种的南向协议。例如，一些OpenFLow的开源控制器不支持NETCONF，为此不能使用of 配置。

- 所有的控制器给应用程序的接口API都是私有的。也就是说，没有标准的北向接口。尽管有些项目试图解决这个问题，例如OpenDaylight项目。不幸的是，ONF直到最近才决定抵制定义北向API标准。不过其他的标准化组织，例如IETF和ETSI早已进入这个领域了。此外，OpenDaylight项目将会产出开源代码，这代表着对此类接口的普遍实现，这将在一定程度上推动北向接口的标准化。

- 当前的SDN控制器解决方案采用了多控制器、数据库同步或者集群的方式来解决可扩展性问题。除了瞻博公司的解决方案，这些策略都会影响跨设备厂商的互操作性。瞻博公司的解决方案提出用BGP 来交换网络状态，具有更好的互操作性，不过也依然需要其他厂商给予支持。

在OpenFlow环境中，开源SDN 控制器的水平和垂直的可扩展性依然是存在问题的，这是因为采用数据管理系统的做法还比较新。很多开源控制器最开始的设计是完全把数据放在内存中。除非特别设计，否则它们都没有被设计用来在一群控制器之间共享贮存内存的状态。Big Switch公司的解决方案可能是一个例外，但只有其商业版本才有很多改进。

对于OpenFlow 1.3的支持还不普遍。大多数控制器和设备都支持OpenFlow 1.0，这可能成为一个问题，因为1.3版本做出了一些非常重要的改变。另外一个问题是，在支持OpenFlow 上，很多设备厂商实现了一些私有的协议扩展，而并非所有的控制器都支持这些扩展，这将进一步加剧互操作问题。

大多数和网络相关的讨论最后得到的结论都是：网络是与应用程序相关的。对于SDN控制器而言，应用程序的可移植性，以及控制器周边的生态系统，将最终决定谁是商业上的赢家（们）。如果这两点都不够充分的话，对于SDN的思考以及控制器模型将有可能发生改变。这一点可能是思科公司OnePK 以及OpenDaylight项目诞生背后的原因。除了这两者之外，其他的控制器架构在支持南向协议和北向的应用程序可编程上都不具备灵活性。

关于应用程序开发，涉及的控制器中有如下值得关注的技术或思维过程。

- Trema引入了控制器框架的构想。即，最开始仅仅提供核心模块，每个服务模块可以提供自身的API，这个API可以在多个组件甚至用户应用程序中进行实现。

- Big Switch公司的商业版本（Floodlight在未来也有可能），以及VMware公司的基于Spring 的环境，可以加速API 的开发甚至自动从模块中产生API，或者从模块操作的数据模型中产生API。

- 瞻博公司提炼了“SDN是网络编译器”的概念。按照这个观点创造了高级的、用户/应用程序友好的数据模型，这个数据模型可以被翻译成底层的网络策略/协议原语（例如，L3VPN VRF、路由器和策略）。

- 一些解决方案采用将服务器和基本功能进行分离的策略，以及为应用程序定制的数据库策略。特别是对于最新的设计，很多控制器被描述成为系统或者集群，为此必须解决一致性的问题。

从本书所做的跨越时间的调查中，可以看到，与上述类似的那些最好的想法被挑选了出来或演进而来，并且被结合到了新的设计中。

第5章　网络可编程性

5.1　引言

网络可编程性（network programmability）这一概念作为软件定义网络的关键宗旨之一处于核心地位。网络可编程性的概念存在于网络设备和软件组件之中，或表现为网络设备和软件组件的特征。网络可编程性确实不是一个新的概念了，因为网络管理技术从设备组网时代一开始就存在。现在，不同之处在于设备（不论是物理的还是虚拟的设备）不仅要被管理，还要被与之互动。不管是何种可编程对象（如设备），网络可编程性的目标是使该对象易于编程，并建立该对象和与之通信的软件之间的双向通信通道。这就形成了人们所说的网元设备之间紧耦合的反馈回路（feedback loop）。此概念与传统的网络管理范式相比，实际上有很大不同。在传统的网络管理范式中，管理器（manager）和被管代理（agent）以一种相对松散的方式来通信，操作之间有相当大的延迟，而且可能本质上并不存在反馈机制。

为了实现这种新型的通信与交互范式，紧耦和、双向的编程接口是必需的。此编程接口应可以在软件中方便和迅速地实现，以促进其使用和广泛部署。人们通常称这些编程接口为应用程序友好型（application friendly）接口。这些编程接口也应由开发人员群体来开发，以便使编程接口健壮、安全和被广泛应用。这将导致对这些编程进行事实上的标准化，并最终达到严格意义上的标准化。编程接口应提供自描述（selfdescribe）能力，使应用程序拥有轻松和动态地学习和理解网元设备的能力，而不需要重新编译。最终的效果就是人们可用来可靠地编写代码的接口，并且是可跨控制器平台移植的接口。

本章，我们将详细介绍编程接口，并解释接口如何为这种紧耦合的双向通信通道提供便利，以形成控制器与其所控制网络设备之间的、最终是与（需要与控制器和网络设备都进行交互的）应用程序之间的反馈回路。

注意，因为本章是为读者综述现有技术，所以作者不打算详细解释每一种管理接口，而是致力于从较高层次探讨这里给出的协议或方法的重要优缺点，尽力向读者展示相应技术是否适应SDN模型。不过，本书会为读者提供进一步了解这些技术细节的参考文献。

5.2　管理接口

管理接口可以让网络操作人员在其网络中管理网络设备。这些接口一般为操作者提供一个网络设备的一致的操作视图，包括该网络设备的配置和运行状态。一个管理接口通常由两个关键要素组成：协议和消息格式规范。协议用来描述与发送或接收特定消息（消息由管理器或网元设备生成）相关的语法和语义。这些消息通常包含命令、查询，以及对之前所做查询的响应。在某些情况下，这些消息可以不经查询而直接发出，即为响应网元设备中的一些事件而异步发出事件（通知）。管理接口的另一关键因素是消息的格式和消息的含义。有些管理接口定义可为网络操作人员提供信息目录的数据模型。某些情况下，管理接口也可用于描述管理器如何创建（或安排）它与设备之间的查询或命令。该数据模型通常还描述了系统内可管对象之间的关系。例如，系统的名字可能保存在称为sysName的一个对象中，并关联到一个称为sysUpTime的，给出系统已运行时长的对象。这两个对象都包含在称为system的代表整个系统的父对象中，从而形成关联。

5.3　应用程序与网络之间的鸿沟

直到最近，大多数现代网元设备（例如路由器、交换机、防火墙）仅支持与这些网元设备通信的一小部分传统接口。这些接口通常包括专有的命令行界面（CLI）、简单网络管理协议（SNMP）、公共对象请求代理体系结构（CORBA），以及最近提出的网络配置协议（NETCONF）这类形式的接口。这些接口语言有几个关键的共同点。首先，它们一般在本质上是静态的，需要一个先验数据模型的设计和声明。在实践中，这意味着代码要通常根据已内置到网元设备里执行的固件映像文件 （firmware image）里的管理接口来生成，以及根据内置到管理软件（或应用程序）中的管理接口来生成。这就意味着，用来与网元设备进行对话的此类接口必须预先编程，而不能根据感知的网络状况动态习得。其次，在某种程度上要为这些管理接口构建专门的语言语法，来定义消息的结构和网元设备处理消息的规则（只读和读写）。再次，这些协议通常使用二进制编码，这意味着实际使用中很难再编程、调试和表示。最后，编写管理接口所述结构的语法模块的普遍做法往往是非层次化的，这意味着既难以指导应用程序，也难以指导用此模式编程的人。

大多数情况下，应用程序通过某种协议，或更常见的是，通过网元管理系统（EMS）与网元设备或其服务进行通信。EMS充当网元设备和应用程序之间的代理。遗憾的是，EMS（或NMS，即网络管理系统）一般都不以友好的方式向应用程序开放网元设备或服务。这意味着对这些接口和范式的编码很麻烦，最终导致应用程序希望做的控制需要很长的时间周期才能实际做到。这就是我们所说的应用程序和网络之间的鸿沟，如图5-1所示。

图5-1：应用程序与网络之间的鸿沟

为此， 一个答案是使用应用程序友好型RESTful（representational state transfer，表征状态转移） 接口。这些接口通常使用现代方法如JSON（JavaScript Object Notation，JavaScript对象表示法）来定义。JSON解决了上面提到的那些传统接口的很多缺点，因为它的模式是使用人类可读的XML定义的、自我指涉的（selfreferential）、层次化的，并且很容易内置到Java语言，这种过去十年中最常用的语言编写的应用程序中。下面的这段代码展示一个JSON 示例（其他现代的、应用程序友好型接口是Thrift和谷歌公司的Protocol Buffers，我们将在本章后续内容中描述它们以及一些其他技术）：

<!DOCTYPE html>
<html>
<body>
<h2>
JSON Object Creation in JavaScript
</h2>
<p>

Name: <span id="jname"></span><br />

Age: <span id="jage"></span><br />

Address: <span id="jstreet"></span><br />

Phone: <span id="jphone"></span><br />
</p>
<script>

var JSONObject= {

"name":"John Johnson",

"street":"Oslo West 555",

"age":33,

"phone":"5551234567"};

document.getElementById("jname").innerHTML=JSONObject.name
document.getElementById("jage").innerHTML=JSONObject.age
document.getElementById("jstreet").innerHTML=JSONObject.street
document.getElementById("jphone").innerHTML=JSONObject.phone

</script>

</body>

</html>

SDN技术的另一个关键原则是促进应用程序与支持该应用程序的网元设备之间更紧耦合的交互。具体来说，服务开通配置（provisioning）、分析和优化所代表的这三种常见动作组成的周期，在过去往往被认为是彼此独立完成的。作者建议，在SDN的方法中，这三者应一起加以考虑，如图5-2所示。服务开通配置阶段是一个应用程序指出它想做什么、改变什么，或在总体上影响网络行为。分析阶段是监视或收集来自网元设备的反馈，包括其运行状态、故障状态、容量状态或健康状态。例如，这包括统计数据的收集和状态通知的接收。最后，优化阶段是使用从分析阶段收集到的信息来实现的，并可能导致另一次服务开通配置的发生（可能通过一些嵌入式或外部的策略引擎的互动来实现），以便系统能自我调节来更好地运行。此反馈回路实现得越紧密，则整个系统就越可能更快地自我调节以适应变化、越可能更优化地运行。

图5-2：应用程序与网络之间的反馈回路

此前，本书介绍了传统接口下的应用程序设计模式，往往导致应用程序需要与网元设备之间通过某种代理或翻译器来通信。此方式有一个经常被忽视的副作用，即在应用程序和网元设备之间的反馈回路的时间周期通常要几分钟、几小时，甚至几天。此效率在我们想做接近实时控制时显然是不够的，例如针对本书后续描述的一些应用案例（例如，第12 章中的带宽按时间调度，或第10 章中的需要瞬时起作用的CSFP）。1

1.CSPF 是带约束条件的最短路径优先路由方法，需要及时地反映网络可用资源的变化，以便为应用程序实时地计算出能满足所需要性能的路径。——译者注

5.3.1　命令行界面（CLI）

每个厂商从一开始就必须提供某种形式的命令行界面，使操作者可以与设备通信。CLI通常是基于ASCII字符的系统，其目的是为特定设备提供默认的、被广泛接受的管理接口。CLI 在许多方面类似于UNIX命令行界面提示符，CLI实际上是一个有效的语法分析器，当回车键被按下后，就基于字符串的标记来采取动作。

大多数设备都支持采用通用协议，如Telnet或SSH（Secure Shell）的形式远程访问CLI。由于这些协议在网络上运行，它们很容易受到网络中断或其他故障的影响，造成管理员与设备无法正常通信。正是由于这个原因，不管是大型还是小型设备都仍然提供某种形式的硬件连线联接，以支持可本地交互的操作命令（例如，通过USB线或串口线）。

一般情况下，设备厂商指定的命令行语法分为两部分：配置与查询/监控。就配置来说，往往会有操作的安全模式，管理员进入安全模式以改变设备运行中的配置。某些设备允许管理员存储配置的多个副本，以便为不同的场景进行配置，或一旦某个特定配置不能正常工作时，能马上回退到另一配置。参见下面这段简单的配置：

RP/0/0/CPU0:ios#config t
RP/0/0/CPU0:ios(config)#interface
MgmtEth 0/0/CPU0/0
RP/0/0/CPU0:ios(config-if)#
RP/0/0/CPU0:ios#
RP/0/0/CPU0:ios#admin
RP/0/0/CPU0:ios(admin)#

命令行语法通常还提供查询模式，允许管理员查询设备的状态或某特定功能的状况。例如，在前面的例子中，我们将系统的名字用作管理员可以查询的元素，以确保管理员将对正确的设备进行配置。下面给出另一个例子，查询设备的BGP协议运行状况：

RP/0/0/CPU0:R2#show bgp summary
BGP router identifier 3.3.3.3, local AS number 1 BGP generic
scan interval 60 secs

BGP table state: Active

Table ID: 0xe0000000
BGP main routing table version 561
BGP scan interval 60 secs
BGP is operating in STANDALONE mode.
Process Speaker Neighbor 20.0.101.1
RecvTblVerbRIB/RIB LabelVer ImportVer SendTblVer
StandbyVer 561 561 561 561 561 561
Spk AS MsgRcvdMsgSentTblVerInQOutQ Up/Down
St/PfxRcd 0 1 1068 1036 561 0 0 14:35:30 100

遗憾的是，尽管实际上用于管理相同的东西，但两个厂商所制定的CLI语法通常是不同和不兼容的。例如，一种命令行语法可能允许系统名字采用混合大小写的形式表示，而另一种命令行语法可能要求必须用大写字母（或禁止使用某些特定字符）。致力于达成事实上的标准，许多网络设备厂商现在已经尽量合法地仿制思科公司的CLI。虽然这有一定帮助，但这些解决方案的兼容仍然受阻于缺乏操作语义上的兼容，比如我们刚才所说的那个系统名字的问题。除了仿制思科公司 CLI，目前还没有CLI 的标准存在。有些人试图对CLI 进行标准化，但这些尝试都失败了。

CLI范畴内实现网络可编程性的一种早期途径目前应用仍相当普遍，它用UNIX脚本来与设备的CLI 进行交互。现在有多种工具可以做到这点，包括Perl、Expect脚本、UNIX shell命令，以及Python。采用这种方式时，我们先编制脚本，然后通过网络传输和会话协议（如Telnet over UDP/IP或SSH）来连接设备。一旦连接成功，采用某些协议时还需要通过认证，脚本程序就机械地在CLI中输入命令，就如同用户在键入这些命令一样。这通常称为 “屏幕抓取”，因为并不是真正地与系统进行交互，而是像用一个橡胶窗刮在刷屏。遗憾的是，这是目前最广泛使用的实现网络可编程性的方法。管理上使用这些“管理机器人”的不利之处在于，对一个设备编写脚本，然后收集统计数据来调整配置或进行操作，这之间的周转时间相对来说通常很长。这种方法还有另一个缺陷，它在很大程度上不是应用程序友好型方法。虽然一些现代的应用程序也都是用Perl或Python来编写的，但编程人员一般无法理解每个特定厂商CLI的语法和语义。更糟糕的是，在有多个厂商的设备存在于同一网络的情况下，应用程序必须了解与设备进行交互的多种方式，这依赖于设备的类型、厂家、型号和固件映像文件。熟悉这种操作方法的大多数人都认为，这种要求是对编写应用程序的程序员的不恰当和过分的负担，因为这些程序员通常都不了解对某个网络设备编程的细节，他们也不必要了解这些细节！2

2.作者的意思是编写应用程序的程序员关注所开发的应用程序即可，不必去了解底层设备的细节。——译者注

5.3.2　NETCONF和NETMOD

网络配置协议（NETCONF）是由IETF标准化的网络管理协议，于2006年12月开发和发布3。IETF在20世纪80年代后期开发了SNMP，事实证明即使在今天SNMP仍然是一个非常主流的网络管理协议，至少在统计和监测领域是这样。经过约10年的SNMP部署实践，遗憾的是，非常明显，不管SNMP本来的设计目标是什么，它目前主要用于网络监测，而不是用来配置网络设备。2001年左右，IETF网络管理社区的成员与网络运营商们共聚一堂研讨了这种情况。这次会议的结果记录在RFC 35354里，但总体来说，结果是运营商主要采用厂商专有的命令行界面（CLI）来配置设备，而不用SNMP进行配置。这次会议的另一个重要成果是发现了这种行为背后的原因。其关键点是，CLI具有许多运营商喜欢的功能，包括CLI是基于文本的，与之相反，SNMP是基于BER编码的（即二进制的）。此外，许多设备厂商没有提供通过SNMP完全配置设备的选项。大多数厂商根据此前从运营商得到的消息，仅允许“只读”操作。甚至那些实现了完全“读写”能力的设备也仍然是孤立的，因为虽然IETF提供了标准的管理信息库（MIB）模块，每一个厂商仍然实现了自己专有的MIB模块。而往往其他厂商并没有实现这些专有MIB的扩展。最后，即使是都基于标准的MIB，有的厂商设计实现的语义，最终与另一个厂商设计实现的语义不匹配，这使SNMP更加难以（或不可能）作为配置的手段。

3.RFC 4741和RFC 6241。
4.即RFC 3535。

如前所述，网络运行人员通常喜欢写脚本来管理网元设备。但他们都发现CLI的功能匮乏，最明显的是配置后的输出的不可预测性。输出的内容和格式很容易发生不可预知的变化，包括设备的不同固件版本在输出格式上不同。虽然有些固件版本造成的变化有书面通知，而且写入了文档，但有些则未能提供这些信息，这更加重了输出的难以预测性。

几乎同一时间，瞻博公司一直在使用基于XML的网络管理方式，与远端的网络设备进行通信（即瞻博公司的管理接口协议），并用作指定CLI配置模式的原生语言。这种新方法作为更统一的、更对应用程序友好的管理接口的提议带入到IETF和更广泛的社区里。该提议以及在RFC3535里讲的那次会议，最终导致IETF创建了一种称为NETCONF的新型网络管理协议。

简言之，NETCONF提供了安装、操作和删除网络设备配置的机制。NETCONF的操作在简单的远程过程调用（RPC之上进行。NETCONF协议基于可扩展标记语言（XML）对数据和协议的消息进行编码。这相应地实现在传输协议之上，例如实现在TCP、HTTP 或HTTPS之上。一般来说，NETCONF 协议可以从概念上划分为四层，如图5-3所示。接下来，我们具体描述其中的每一层。

图5-3：NETCONF 的四层：内容层、操作层、RPC 层、传输协议层

1. 基本NETCONF操作
NETCONF 基础协议包括下列协议操作：get、get-config、edit-config、copy-config、delete-config、lock、unlock、close-session 和kill-session。

2. 功能
NETCONF 基本功能可通过对NETCONF 能力的定义来进行扩展。某个实现支持的所有附加的协议功能，都必须在服务器和客户端会话建立时的能力交换阶段进行沟通。强制性协议功能则不需包括在能力交换之中，因为这些强制功能被假定在所有的兼容实现中都已经支持。RFC 4741中定义了一些可选的功能（包括:xpath和:validate）。

NETCONF 还提供了支持订阅和接收异步事件通知的能力5。即运行人员使用<create-subscription> 操作来对订阅通知进行实时创建和重放。发送时， 使用<notification> 结构来异步地发出通知。

5.RFC 5277，http://datatracker.ietf.org/doc/rfc5277/

NETCONF有一个非常重要的功能，即支持对设备的运行中的配置进行部分锁定6。这一点至关重要，因为它允许多个会话同时编辑同一台设备运行时配置中的不重叠子树。如果没有这个能力，我们仅能针对整个配置进行锁定，这种情况下需要对各项配置进行序列化操作而不是同时操作，而这可能会减慢整个配置过程。7

6.RFC 5717, http://datatracker.ietf.org/doc/rfc5717/
7.CLI（或脚本）在SDN环境中应用的主要障碍就是：配置锁定/解锁周期长，及难以调用守护进程对CLI（脚本）所做配置子块的语法来验证。

最后，我们可以将NETCONF协议本身视作一个独立实体对其进行监测8和管理。数据存储、会话、加锁和统计数据等用来对NETCONF服务器进行管理，并用于对NETCONF服务器进行故障排除等重要活动。最重要的是，NETCONF服务器定义了NETCONF客户端用来发现NETCONF服务器所支持数据模型的方法，并定义<get-schema> 操作使NETCONF客户端获取数据模型。正是这种能力，允许一个应用程序（或SDN 控制器）动态地发现支持NETCONF 的设备所具有的能力。正是这种简单而强大的功能，将有利于动态的、数据驱动的应用程序代码创建，包括第4章所讨论的SDN控制器之内的代码创建。

8.RFC 6022，http://datatracker.ietf.org/doc/rfc6022/

5.3.3　SNMP

简单网络管理协议（SNMP）由IETF多年前设计，是一个易于实现的、基本的网络管理工具，可以用来远程地管理网元设备。SNMP的若干标准定义了标准协议、访问方法，以及用于表示网络设备内保存的托管数据的标准格式。由于SNMP是业内的长青树，多年来它已经历了多次完善和提高。目前SNMP 有三个版本：V1（版本1）、V2c（版本2C）和V3（版本3）。SNMP 协议仍然存在并且被广泛应用，如前面已经提到的，它目前主要用于监测网元设备的状态和性能特性。今天，大多数生产网络确实在使用SNMP，至少是将其作为其网元设备管理手段的一部分，但大多数生产网络并不将其用于配置目的。

SNMP的一整套标准提供了定义管理信息的框架及交互管理信息的协议。SNMP模型假定有管理者和被管系统的代理，如图5-4所示。

图5-4：SNMP 体系结构概览：SNMP 管理系统和SNMP 被管系统

一般来说，在SNMP用语里，希望查询或配置网元设备的任何应用程序都可称为SNMP管理器。SNMP 管理器包含管理器组件，正是此组件与位于网元设备内的被管代理组件通信。IETF的SNMP框架9定义了更广义的SNMP实体模型。SNMP实体的体系结构比简单的“被管代理-管理器”的关系更加复杂，但“被管代理-管理器”的关系仍普遍适用。由于本章旨在为读者提供现有技术的综述，所以不会进行如此深入的介绍，而是针对此协议的重要利弊进行较深入的探讨。

9.RFC 2571，http://datatracker.ietf.org/doc/rfc2571/

1. SNMP被管代理

SNMP代理是网元设备内的一个软件模块，它负责维护本地管理信息，并通过SNMP协议向SNMP管理器提供这些信息。网元设备的典型实现中都包含被管代理模块。被管代理管理着管理信息库（MIB），即设备内的概念性数据存储。我们可以认为这是一个设备内管理对象的集合，如系统的名字、位置，或最近一次重新启动的日期。被管代理还充当消息的调度者，用来截取、认证和处理从管理器接收的消息。管理信息交换可由管理器来发起（通过get、get-next或get-bulk 命令），或由被管代理来发起（通过SNMP的trap 或notification 消息）。被管代理侦听请求并进行回应。查询时，被管代理根据来自管理器的请求收集被管资源的信息。在这样做时，被管代理就成为管理器和设备内部实现之间的一个归一化层次。例如，内部系统的名字可能表示为两个连接的字符串（代表系统的姓和名），这些字符串就必须先组合在一起，以响应管理器对系统名字检索的请求。这是因为IETF标准定义了系统名字为一个任意长度的字符串，但只能作为一个字符串（不能是两个字符串）。此即SNMP MIB定义所提供的归一化功能，就像任何管理协议的标准数据模型一样。

2. SNMP管理器

与SNMP被管代理相对应的是SNMP管理器。顾名思义，管理器是从事管理设备工作的一个应用程序。术语“管理”这个词可以指针对各种事物的管理，而随着时间的演变，它涵盖负责配置、监测，或者简单地查询网络设备以获取信息的任何应用。网络管理器的传统形象是一个成熟的网元设备或网络管理系统，如CA技术公司的IM 2.0或阿尔卡特公司的SAM产品；但是，它其实并不必须是成熟的产品。正如前面CLI 部分的讨论，网络管理器可以是一个简单的Python应用程序，用来监测系统接口的状况。在这种情况下，不是应用程序通过SSH 连接到网络设备来操作CLI，而是引入一个SNMP库，并将SNMP协议用作该应用程序与被管代理/ 网元设备之间的通信通道。

3. 管理器与被管代理间的关系

正如前面提到的，SNMP 促进被管设备（有SNMP 被管代理的设备，比方说一台路由器）和SNMP 管理器或管理应用程序之间的通信。这个基本的关系如图5-5所示。这两个实体之间的通信是通过SNMP协议完成的。这些消息通常封装在UDP分组里，并允许管理器和被管代理（被管理设备）之间的四种操作，如下面所述。

图5-5：基本SNMP管理器和被管代理的配置；管理器由管理控制台/PC机表示，被管代理可以在任何联网的实体中存在，包括路由器、交换机，以及不太引人注意的服务器或打印机

- Get4
管理器可以执行get（或 read），从被管代理获取有关被管理对象的属性信息。

- Get-Next
管理器可以执行get-next，针对被管设备上对象树中的下一个对象获取同样的信息。

- Get-Bulk
管理器可以执行get-bulk，从被管代理批量地获取有关一组数据的信息。这在SNMP V1里是做不到的。

- Set
管理器可以执行set（或write），设置被管对象的属性值。

除了这些消息，被管代理可以发出trap或notification表示异步通知。这些通知将被定向到一个或多个管理器，旨在表明被管设备上发生了某种事件。

在更现代的、高度可扩展的系统里，SNMP被管代理工作所造成的CPU负荷（尤其是当被管代理同时为多个管理器提供接口时），通常通过创建本地的层次结构（包括分布式代理）来解决。为了优化性能，调整被管代理的自身操作（如调整对表格数据每次访问所能提取的记录的数量）和采用数据管理优化技术（如采用本地缓存）也并不少见。

4. MIB（管理信息库）

SNMP规定了一种方案，对所有对象和系统中这些对象的实例进行唯一的标识和规定。这些条目称为对象标识符，简称OID。OID被规定为从左到右书写的，由句点（即“点”）来分隔的非负整数的有序序列。有时，这称为点标记法。例如， OID“2.1.0”表示某被管代理的MIB中的一个唯一OID。OID的一般结构是“<对象标识符>.<实例ID>”的形式，以允许管理器指定对象的一个特定实例。我们可以把目标想象为一个变量名，把实例想象为该变量的一个或潜在的多个版本。OID也可表示表格对象，包括索引，或者表示标量对象。OID组织为一个层次化的树型结构，树的最高层由ITU（国际电信联盟）和ISO（国际标准组织）标准组织来控制，以便对标准的树定义顺序和结构。这个结构中的子树都被分给其他组织（如IETF）来管理，而此结构中的子树被进一步分配给各种组织和企业用于实验或私人使用（即专有MIB）。图5-6展示了这种安排。

图5-6：OID为一个层次化的树型结构，树的最高层由ITU和ISO来控制

SNMP管理器或管理应用程序使用此明确定义的OID命名语法来表示对象，并对这些对象执行上述操作。为此，每一个SNMP协议消息都包括一个OID和一个对该OID的操作，以及可能的对所述OID设置的值。管理信息库（MIB）是设备所支持的所有MIB 模块在设备内的概念性存储。标准化文档规定了语法，以及某些情况下对模块实现所期望的语义操作行为。创建MIB模块是用来管理特定的功能的，例如设备所支持的协议或特性。MIB模块还可设计用来管理逻辑或物理实体，如接口和电源。例如，如果某公司想开发一款新的设备，并希望该设备的BGP协议栈可以被远程管理，该公司就会设计和实现一系列兼具标准的和专有的MIB，来提供该BGP协议相关的信息。

5.4　现代的编程接口

上文已经描述了最常见的管理接口，下文将转而讨论现代的管理接口和概念。这些新的接口和概念能在最佳意义上启用和鼓励网络可编程性。为此，这些接口展示了我们在前面介绍中所阐述关键属性中的大多数（如果不是所有属性的话）：双向的、应用程序友好型，以及自描述的。这些接口还包含了扎实的数据模型（可转化为数据驱动的行为和快速的实现），当然，开发者群体也很容易开发。

5.4.1　发布和订阅接口

发布-订阅（Publish-Subscriber，一般简称为pub-sub）接口，是一种消息通信模式，即信息的发送者（称为发布者）发送消息给接收者（称为订阅者）。此模式下，发送者并不把消息直接发送到特定的接收者，而是根据所发布消息的特征，把消息划为不同的种类。发布者发布时都不需要知道在什么时间点哪些订阅者存在。在该模式下，订阅者表示对一个或多个类别消息的兴趣，从而只接收那些他们感兴趣的类别的消息。订阅时他们也不需要知道有哪些发布者存在。这么做就实现了所谓的消息总线，消息被发布者放置在总线上，订阅者就很容易地接收到这些消息。由于更低的状态管理需求等特性，相对于点对点系统，这种模式提供了更大的网络可扩展性和更动态的网络拓扑结构。消息总线可以是可靠的或不可靠的，并且就像一个虚拟网络那样提供缓冲队列控制。事实上，这种发布-订阅范式模式是消息队列范式的“兄弟”，所以有很多网络原则是类似的。为了更扎实地处理不同的应用案例，大多数现代消息通信系统都在其API 中支持消息队列和发布-订阅两种模型。其中一个例子就是Java 消息服务（JMS），它在Java 应用程序员中很有声望的。

在发布-订阅模式中，订阅者通常会收到发布的全部消息的一个子集。这是一个非常重要的特性，因为它同时降低了消息处理应用程序的负荷，并减少了信息投递、维护和统计等整个系统负荷。选择消息的接收和处理的过程称为消息过滤。过滤的两种常见形式是基于主题和基于内容的过滤。

基于主题的系统把消息发布给各个主题，主题代表了逻辑集合，或类似于广播系统中的逻辑通道。在基于主题的系统中，订阅者将只会收到发布到他们所订阅主题的所有消息，而不收到其他消息。一个主题的所有订阅者将收到相同的消息，而且一般收到消息的顺序与消息的发表次序相同。尽管某些消息通信系统记录消息发布的顺序，并在队列中缓冲，但有的系统并不这么做，所以不能假设每个系统都这么做。为了使订阅者可以理解消息，发布者应当首先定义好可以被订阅的消息的种类。如果不这样做，那么未订阅的消息都会被所有订阅者简单地丢弃（即置之不理）。

相比之下，基于内容的系统里，仅当信息的属性或内容与订阅者所定义的约束匹配时，才向该订阅者投递该消息。这类似于设置匹配电子邮件某些字段的搜索过滤器，当消息被匹配，它们被放置在一个特殊的文件夹中。基于内容的系统与邮件过滤器是相同的，不过在前者中该匹配的消息将被投递，而不是被忽视。类似于基于主题的方法，订阅者负责对消息进行识别，如不匹配就简单地忽视。

应当指出，许多消息通信系统支持上述两种方法的混合形式，发布者可以发布消息到一个主题，订阅者可同时注册基于主题的订阅和基于内容的订阅。在许多发布-订阅系统里，订阅者通过中介（broker）来注册订阅，让中介来进行过滤。在这种模型中，发布者把消息发送到中间的消息中介或事件总线。中介通常通过存储转发功能来缓冲消息，使它们在拥塞的情况下不会丢失。一旦消息流到了其队列的顶部，它就被路由选择到订阅者。此外，中介可以在进行路由选择之前对队列中的消息做优先级处理。由于中介维护系统中传送的所有消息，所以它很容易复制所有消息，使它们能在以后重放。这是这种系统的一个重要特征，因为它可以同时提供故障排除或诊断功能，以及高可用性功能（可以想象为，中介把消息复制到一个备份的中介，这样就可以在该中介不知何故停止运作时，由这个备份中介来接手）。

这种设计模式有一个有趣的部分，订阅者可以在系统构建时、初始化时或运行时来注册具体的消息。正是这种灵活性使得这种模型非常有用，并且被广泛采用。有些框架和软件产品使用XML 配置文件来注册订阅者，提供了一种称为数据驱动的方法，可以根据系统的属性、配置或者当地的情况来动态地调整。

由于发布者与订阅者之间是松耦合的，所以它们甚至不需要知道对方是否存在。这也是该方法的一个重要属性，因为这意味着无论是发布者还是订阅者，都不需要持续跟踪状态、统计，或其他与发布者或订阅者相关的属性。这些是中介的工作，中介在产生单点故障的同时，确实也带来可集中地处理这类琐事的好处。这也意味着，发布者和订阅者不需要知道系统的拓扑结构，即一旦发布者或订阅者注册了中介，就从根本上不用配置了。这也意味着，随着越来越多的对主题、内容或系统的订阅或取消订阅的发生，对发布者和订阅者来说，都不需做任何改变。这还意味着，不管所有其他发布者或订阅者的状态是什么，任意特定网元设备都可以继续正常工作。

当然，如果一个发布者消失了（宕机了、虚拟机停止了、CPU 太忙了，等等），来自此发布者的消息将不再出现在系统内，或不再被订阅者收到。但重要的是，在发布-订阅模式下，任何特定网元设备的状态都与其他网元设备是松耦合的（无关的）。而相对于传统的、紧耦合的客户端-服务器范式，如果服务器不运行了，客户端可能无法将消息投递到服务器，或者除非客户端还在运行，否则服务器也收不到客户端发来的消息。一个有意思的实施方法是，大部分发布-订阅系统都能够暂时将订阅者与发布者解耦。例如，发布者可能被禁用，以便于订阅者处理邮件的积压，从而节约订阅者的消息带宽和处理器使用率。

相比于传统的紧耦合的客户端-服务器方式，发布-订阅模式提供了具有更好可扩展性的机会，比如并行操作、消息缓存、基于树或基于网络的路由选择在系统中变得可行了。不仅是有更好的可扩展性，系统也有潜力比传统系统有更高的可用性。

例如，一种方法是并行运行两个发布者，如上所述，以便使系统具有可恢复性。在这种情况下，一个发布者可能宕机或撤下进行维护，而其他的发布者仍然继续运行，系统总体上没有任何损失。发布-订阅范式已经证明了它的可扩展性远远超出了单个数据中心的范围，通过Web 聚合协议，例如RSS、Atom 和XMPP，提供了互联网级的分布式消息通信。这些聚合协议能容忍更高的延迟，并降低或干脆是完全损失了消息投递的可靠性，以换取能对庞大数量的订阅者进行服务的能力。

发布-订阅方式最严重的问题之一就是订阅者与发布者的解耦。发布-订阅系统里的中介，可被设计来在指定的时间内投递消息，随后停止尝试投递消息，不论是否已从所有订阅者成功收到消息的确认。发布-订阅系统的这种设计，不能保证消息一定能投递到可能需要确保投递的应用程序。如果发布者或订阅者不知道这种限制，那么同步问题及其他一致性问题就可能会出现。为解决这种限制，有一种具有一定讽刺意味的方法，即对发布者和订阅者之间进行紧耦合的设计，以便克服这些限制。这种紧耦合设计必须在发布-订阅体系结构之外来强制执行，以达到确保投递的效果，这使得这种方法并不可取，因为它给应用程序编程人员带来了额外的负担。

就SDN系统而言，可以从发布-订阅模型中获益，应用程序和控制器都可以使用发布-订阅方式来构建，以获得先前所描述的发布-订阅模式的那些好处。特别是，控制器可以使用发布-订阅方式来与它所控制的网元设备进行通信。这已在第4章介绍的瞻博公司的Contrail控制器/代理解决方案（基于XMPP的，XMPP的介绍见5.4.2节）中体现出来了。

订阅-发布方式也是控制器内通用的模块间通信方案，如在思科公司的One控制器（第4章介绍）和OpenDaylight项目（ODP）框架（第9章介绍）中所例举的。

另一个例子是在控制器间的通信采用发布-订阅模型。控制器可以使用松耦合的方式来中继或传递状态给另一个控制器，这意味着它们可以继续做它们需要做的工作，而不会阻塞处理、发送或接收来自其他控制器的消息。最后，这也可以在多个应用程序希望与一个控制器进行交互的情况下使用。为了提高控制器和应用程序之间通信的可扩展性，我们可以通过安装一个从控制器中分离出来的中介来实现发布-订阅模型；中介用于调和、处理和维护控制器与应用程序之间的通信。

5.4.2　XMPP

正如刚才提到的，“可扩展消息与存在协议”（Extensible Messaging and Presence Protocol，XMPP）是发布-订阅式协议的一个例子，它已经被用来实现一些发布-订阅系统。XMPP 是一种基于XML（可扩展标记语言）的通信协议。该协议可用于提供接近实时的即时消息、存在信息，或确需扩展到一个订阅组的任何信息。顾名思义，它是可扩展的，而且实际上已经在过去几年中被多次扩展。

XMPP是一种IET 的开放式协议标准10。除了IETF标准化的这些核心协议，XMPP 标准基金会（其前身是Jabber 软件基金会）积极地开发开放的XMPP 扩展功能。许多实现已经开发并分发和使用了，比如Jabber、Google Talk 和Facebook Messenger。

10.RFC 6120，http://datatracker.ietf.org/doc/rfc6120/；RFC 6121，http://datatracker.ietf.org/doc/rfc6121/； RFC 6122，http://datatracker.ietf.org/doc/rfc6122/

XMPP的体系结构是非常离散的，类似于电子邮件，任何人都可以运行自己的XMPP服务器，并没有每个人都必须连接到或去验证的中央主服务器。当然，我们可以实现发布者和订阅者的专有组。如同在上面订阅-发布这节内容中，刚刚给出的控制器和应用程序这个例子，服务器如同上面所描述的消息中介那样工作。服务器处理所有注册和要求传递的消息。发布者和订阅者使用基于主题的方法在服务器上注册，基于它们参与了哪个组的会话而进行过滤。服务器可以支持多个会话。例如，许多即时通信服务器对一组用户同时支持多个专有的、多方的会话。

XMPP网络使用发布-订阅式的客户端-服务器体系结构，客户端之间不直接彼此对话，而是在中央服务器注册，该服务器有效地发挥了发布-订阅模式的中介的功能。这意味着，客户端和服务器是松耦合的，并能获得这种关系的上述所有好处。该体系结构被分散地设计为没有全球授权的服务器，因为有各种不同的即时通信服务（如Facebook Messenger 或Google Talk等）。这有时会导致混淆，因为有名称为jabber.org 的公共XMPP 服务器在运行，大量用户在那里订阅。然而，这仅仅是为了社区用户而已。其他人可以在自己的域名上运行自己的XMPP服务器。而且，现 在XMPP作为一个应用程序的框架，已经与这些公共服务器实现无关了。

在XMPP体系结构里，系统中的每个用户都有唯一的Jabber ID。作者在这里并不严谨地使用 “用户”这个术语，因为它实际上是一个应用程序，这个应用程序在发布-订阅范式中或者是发布者，或者是订阅者，或者两者都是。为了避免需要一个中央服务器来维护ID 列表，Jabber ID通常被构造为类似于用一个用户名和一个域名或IP地址组成的电子邮件地址。进一步说，用户所在的服务器可以通过用户名后跟随@ 符号来包括，如username@example.com。这种命名模式是常见的，但不是必需的，实际上可能不适合实现XMPP的一些框架。在这些情况下，其他局部化的命名方案可以很好地使用。

XMPP系统具有表示消息优先级的标记。正如上文所述，有些发布-订阅系统在消息投递中采用缓冲队列。在这种情况下可采用有序/ 优先级队列的方法。为此，当资源在一个服务器上注册时，每个资源都可指定一个称为优先级的数值。发送给该用户的消息将用相应的优先级来对待。最大的数值表示最高的优先级。应当指出的是，发出不含用户名的消息在XMPP系统里也是有效的。这些没有用户名的消息，用于系统消息和服务器上的特殊功能的控制。

对通用的XMPP部署模型的一个重要而有趣的变种，是通过HTTP和WebSocket 传输来使用XMPP。XMPP原本所用的传输协议是IP之上的传输控制协议（TCP）。这种编码在长连接的TCP之上使用XML流，而XML流的格式留给用户来定义和指定。

作为TCP传输的替代品，XMPP社区还为受防火墙限制的用户开发了Web客户端的HTTP传输方式。在原规范里，XMPP可以通过两种方法使用HTTP：轮询模式或绑定模式。人们不会考虑轮询模式了，因为它已经过时了。绑定模式是使用同步HTTP之上的双向流来实现的。该模式允许服务器一旦可以发送消息时，就尽快用异步的方式把消息推送给客户端。这种模式的效率远远高于已经废弃的轮询模式，因此非常受欢迎。使用HTTP传输还有一个优势：大多数防火墙允许客户端通过HTTP来获取和发送消息，不存在端口过滤或阻断等任何问题。使用这种方法，一台服务器可以简单地监听正常的HTTP或HTTPS端口，接收到XMPP封装的流量后进行处理。

5.4.3　谷歌公司的Protocol Buffers

Potocol Buffers是谷歌公司提出的一种语言中立的、平台中立的、可扩展的机制，用于对结构化的数据进行序列化。谷歌公司发明的Potocol Buffers，改进了在XML和JSON 中发现的编码器不足11。

11.本节并不意味着要对谷歌公司的Protocol Buffers 全面展开说明，但确实希望对材料进行充分介绍。更多详细信息，请参见https://developers.google.com/protocol-buffers/

协议缓冲区的主要优化是通过使用二进制编码使XML 变得更小、更密集。使用XML有一个缺点，虽然它是人类可读的格式，但是它的表达非常冗长，传达相同的信息所用的字符会比用二进制格式时多很多。这实际上是NETCONF提出初期，对NETCONF有争议（与SNMP对照 ）的一个重要方面。回想一下上文讨论过的SNMP的相对优点，其中之一就是SNMP 由于采用紧凑的二进制格式，可以随意地快速处理请求。虽然SNMP 采用紧凑的格式，但它搜索信息时仍可能需要相当长的时间。而Potocol Buffers这种新方法就没有以前技术上的这些局限了。然而，在比较这些方法时人们常问这样一个问题：这种紧凑性的重要性是否胜过用户能快速检索和理解文本的重要性。帮助做决策的一种方法是，其格式是用于内部的API 还是外部的API。人们达成的共识似乎是二进制编码的API仅用于内部使用的API，而人类用户可读的方式（即 XML、JSON 等）用于面向公众的接口；这样做，在一般情况下比较好。

Protocol Buffers中采用唯一的方式来定义结构化的数据格式，然后用于交换和序列化。这就是在.proto文件中定义一个缓冲区消息类型（buffer message type）。每个协议缓冲区消息代表一个采用此格式的信息的逻辑记录。每个消息都包含了采用这种语法的一系列“名-值”对。下面给出一个.proto 文件示例，它定义了包含通讯录条目信息的一个消息：
message PersonalRecord {
required string nameFirst = 1;
required string nameLast = 2;
required string streetAddress = 3;
optional string emailAddress = 3;

enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
HOME_OFFICE = 3;
}
message PhoneNumber {
required string internationalNumber = 1;
optional PhoneType type = 2 [default = MOBILE];
}
repeated PhoneNumber phone = 4;
}

正如你所看到的，消息格式相当简单明了。每种消息类型都至少有一个唯一编号的字段，每个字段有一个名字类型和一个值类型。需要注意的是，值可以是数字（整数或浮点数）、布尔值、字符串、原始字节（raw byte），或其他协议缓冲区消息类型（如上面这个通讯录的例子）。这些其他的消息类型允许人们对数据进行层次式的结构化，以满足不同应用所需的定制化和灵活性。可选字段、必填字段和重复字段都可以被很好地表述，如上面通讯录的例子里所展示的，电话号码这部分就可以重复地给出四个电话号码的条目。

一旦定义了数据结构类型和格式，我们就可以用一些Protocol Buffers编译器工具来对这些类型进行读写，生成源代码。这些工具可用于多种数据流类型，以及各种语言，包括Java、Python、Perl 和C++。消息定义好后，就运行针对一个特定目标语言的Protocol Buffers编译器。这个编译器读取一个或多个.proto文件作为输入，然后生成数据访问类（class）。这一过程为每个字段（即set_query() 或set_query()）生成访问函数（function），以及生成把已定义的数据结构序列化为原始字节、或从原始字节解析为数据结构的方法（method）。举例来说，如果选择的语言是C++，对前面通讯录的例子运行编译器后，就会生成一个叫做PersonalRecord的类。然后，你就可以使用这个类在应用程序中方便地填充、序列化，以及发送和检索Person这个协议缓冲区信息。

Protocol Buffers中有一个非常酷的功能，即所生成的用于接收消息的代码，将忽略在被编译代码的版本中没有定义的附加字段。这意味着，在通信两方之间的绝对兼容性不需要是精确的。这样做是可以的，因为设计师们担心服务器需要根据API的迅速发展而升级，希望升级时避免一下子就升级所有的服务器。在小规模下升级所有服务器似乎不是什么大不了的事情，但对于像谷歌这样大规模的公司，在很短的时间内升级数以万计的服务器绝对会是个问题。

回到刚才的通信录示例，看一下新生成的C++代码，如下例所示，填充这些类，并使用它们来发送消息：

PersonalRecord personalRec;
personalRec.set_name("David Blowfish");
personalRec.set_id(420420420420);
personalRec.set_email("blowfish@lovestogrowgrapes.com");
fstream output("someFile", ios::out | ios::binary);
personalRec.SerializeToOstream(&output);

如果要读取该消息，可以执行如下代码：
fstream input("someFile", ios::in | ios::binary);
PersonalRecord personalRec;
personalRec.ParseFromIstream(&input);
cout << "Name: " << personalRec.name() << endl;
cout << "E-mail: " << personalRec.email() << endl;

Protocol Buffers中一个有吸引力的方面是其格式是自描述的，这对于SDN环境中使用API而言，将是一个非常可取的特性。这是因为，这些API不仅可用于生成代码，也能动态地解释语义或语法。这可用于判断所生成代码的API 是否被修改了，这意味着，应用程序可以自动检测到不兼容的地方，并通过询问有关API 的更新而相应修改，这样做就可以使应用程序的接口马上成为最新的了。除了被用于短暂的远程过程调用（RPC）请求，Protocol Buffers也可以用来作为定义自描述数据的持久性存储的手段。

Protocol Buffers现在已成为诸如谷歌公司和其他一些大型数据中心提供商进行数据格式化的首选，用于RPC系统以及数据的永久性存储。

5.4.4　Thrift

Thrift12是一种接口定义语言，用来为众多语言定义和创建服务。

12.本节并不意味着要对Thrift全面展开叙述，但确实希望给出对材料的充分介绍。更多详细信息，请参见http://thrift.apache.org/

类似于Protocol Buffers，Thrift也被用作远程过程调用（RPC）的框架。类似于Protocol Buffers，Thrift的开发是为了解决一个新兴的应用内容服务提供商——Facebook公司——不断增长的需求。在其创建之时，Facebook所运营的大规模数据中心，遇到了与谷歌公司数年前遇到的类似的问题。虽然Thrift是用C++写的，但它的编译器可以为多种语言创建代码。类似于Protocol Buffers，Thrift把代码生成引擎与多种程序语言支持结合起来，可以为各种语言创建服务。Facebook公司本着更加灵活的开发环境的理念，Thrift可用来生成非常广泛的语言，包括C++、Erlang、Go、Haskell、Perl、Cappuccino、Python、C#、Ruby、Smalltalk、Node.js和PHP。

2007年4月，Facebook公司把该项目捐赠给Apache软件基金会，在那里继续工作和发展Thrift。

如前所述，Thrift包含一个完整的软件库，该库可用于创建客户端和服务器，以及创建便于两者之间通信的RPC机制。

图5-7展示了一个Thrift的客户端和服务器的功能结构。图中Service client（服务客户端和读写操作read()/write()的代码是从Thrift的服务定义文件生成的。该服务定义文件被提供给Thrift编译器，然后该编译器生成客户端和处理器代码，之后二者被并入客户端和服务器代码。在图中所示的协议层（TProtcol）和传输层（TTransport）是实时运行库的一部分，作为一个预编译的库包含到客户端和服务器代码里。

图5-7：Apache Thrift API 的客户端/ 服务器体系结构

该标准的Thrift库包含用于处理底层的输入/输出调用的服务器基础设施。

类似于谷歌公司的Protocol Buffers，Trift可以定义一个新服务，并更改协议和传输，而无需重新编译代码。这是因为代码是从定义文件生成的，而未知字段可被忽略。

Thrift实际上支持许多可用于以满足各种应用需求的协议。例如，Thrift支持一个称为TBinaryProtocol协议，该协议采用基本的二进制格式，用于因性能原因不希望采用原始文本格式的场景。另一个是用于包括数据的JSON编码的TJSON协议。所支持的协议还有很多（相关细节请参见参考文献）。

这是一个Thrift 服务描述文件的示例：
enum PhoneType {
HOME,
WORK,
MOBILE
}
struct Phone {
1: i32 id,
2: string phoneNum,
3: PhoneType type
}

正如你所看到的，这段代码与C++中所定义的结构非常相似，对于熟悉C++语言的人来说应该很简单。

Thrift根据这种描述性信息来生成各种语言的代码。例如在Java中，PhoneType将是C++语言的类“Phone”中的一个简单枚举类型（enum）。

5.4.5　JSON

JavaScript对象表示法就是通常所说的JSON，是一种轻量级的数据交换格式。JSON的一个主要诉求是基于XML，易于人们阅读和书写，同时机器也相对容易进行语法解析和生成。JSON是一种完全独立于语言的文本格式，但符合使用C语言族的程序员所熟悉的习惯，包括C、C++、C#、Java、JavaScript、Perl 和Python。正是这些特性使JSON成为一个非常有吸引力的数据交换语言，它也被证明是用来构建SDN 控制器和应用程序的API的优选。

JSON基于相互作用的两种结构：名-值对的集合，以及值的有序列表。在不同的语言中，它被实现为对象、记录、结构（struct）等。在大多数语言中，值的有序列表被视为一个数组或列表。大多数现代编程语言都支持这些结构，尽管不同的语言在实现形式上各不相同。

基于这些结构来表示编程语言之间可交换的数据格式是很有意义的。JSON中的数据格式呈现如下这些形式。

对象（object）是一个无序的名-值对的集合。一个对象以{（左括号）开始，以}（右括号）结束。每个“名”后跟一个冒号（:）；名-值对之间使用逗号（,）分隔。下面是一个JSON 定义的例子：

{"menu": {
"header": "SVG Viewer",
"items": [
{"id": "Open"},
{"id": "OpenNew", "label": "Open New"},
null,
{"id": "ZoomIn", "label": "Zoom In"},
{"id": "ZoomOut", "label": "Zoom Out"},
{"id": "OriginalView", "label": "Original View"},
null,
{"id": "Quality"},
{"id": "Pause"},
{"id": "Mute"},
null,
{"id": "Find", "label": "Find..."},
{"id": "FindAgain", "label": "Find Again"},
{"id": "Copy"},
{"id": "CopyAgain", "label": "Copy Again"},
{"id": "CopySVG", "label": "Copy SVG"},
{"id": "ViewSVG", "label": "View SVG"},
{"id": "ViewSource", "label": "View Source"},
{"id": "SaveAs", "label": "Save As"},
null,
{"id": "Help"},
{"id": "About", "label": "About Adobe CVG Viewer..."}
]
}}

5.4.6　I2RS

大约两年前，Tom Nadeau、Ping Pan、Alia Atlas和David Ward等人组成了一个小组，开始思考如何标准化可编程性的概念，如控制器的北向接口、设备的（快速）编程，以及网络拓扑结构。这些都是SDN所讨论的核心问题，但这些概念存在许多不同的定义、描述和实现。在某些情况下，标准的一部分已经存在或正在进行制订，而其他部分的命运却在一个不那么开放的论坛手中。

正是这些动机酝酿了一个计划，即在IETF这样一个众所周知的创造高品质和开放标准的组织中从事这项标准化工作。经过大量艰苦的组织和写作工作，能够从事这项工作的组织终于起步了。这就是现在IETF的“路由系统接口” (Interface to the Routing System），IETF 术语缩写为I2RS。

I2RS有三个关键方面。

- 首先，接口采用本章一直所讨论的那种现代编程接口（这意味着它是异步的，并提供快速的、交互式访问）。它应该是自描述的，并很容易被现代应用程序和编程方法消化或操作。

- 其次，I2RS为应用程序提供可以访问网络设备的信息和状态的能力，这些信息和状态是现有的实现或配置协议通常不能建模或操作的。例如，这可能是访问一个网络设备正在使用中的转发表。

- 再次，I2RS为应用程序提供从网络设备习得额外的、结构化信息的能力，例如习得网络拓扑和事件的能力。这些信息将以可筛选的方式提供，用来支持灵活性、可扩展性，使应用程序易于消化。

当I2RS工作开始时，首先审视和检查现有机制，针对一些应用案例来确定这些机制的可行性和适用性。最后的竞争者是SNMP和NETCONF，因为两者都允许对网络设备进行状态的写入和读取，但最终它们还是没有满足所有在参考文献13中给出的I2RS的关键属性。

13.http://tools.ietf.org/html/draft-atlas-i2rs-problem-statement-00

例如，基于SNMP来编程的开销是相当高的，这对于现代应用程序来说代价过于昂贵。此外，许多MIB（在定义上或实践中）仅以只读的方式实现，因此不适合用于网络设备的状态配置。

而NETCONF在增加新的应用程序特定的状态，并通过路由系统分发上的能力非常受限。NETCONF具有许多有用的特性，如配置重放、配置回退和配置验证，但这些都是费时的特性，因而不适合做网络设备的快速配置，所以这些功能或许应该由外部的SDN控制器来处理。

考虑到RIB（路由信息库）数据的性质和SDN编程接口潜在的高处理速度，该接口可能需要在目标设备中创建短暂的状态。许多现有的接口包括NETCONF在这点上都有缺陷。为此，I2RS提出建议要求扩大其创建和管理临时状态的能力。

I2RS的一些有意思的应用案例如下。

- 间接方式的路由控制
它使应用程序也能够在RIB中安装路由表项，可以做到例如BGP用RIB来解析其IGP的下一跳时，这个下一跳就可能是应用程序安装的路由表项。一般情况下，路由从一个协议到另一个协议重发布（redistribute）是通过RIB完成的。该重发布的路由可以是通过I2RS接口来安装的。这非常类似于第4章中PCE-P服务器的例子。

- 对未知流量采用基于策略路由
RIB中安装的静态路由，可以通过某种合适的隧道方式，将无法识别的流量转到应用程序做进一步处理。这样，静态路由就可以通过间接方式进行编程，以使其转发路径是一个特定的路由（例如，转给一个特定的服务器）。这非常类似于第12章中所描述的应用案例，即输入流量的检测和相关联的操作。

- 固定时间的服务
如果一个应用程序只能在固定的时间段提供服务，应用程序可以在本地路由器的RIB中安装特定的路由，并通过IGP来发布接入本地路由器的相关地址前缀。如果应用程序知道运行的固定时间，那么安装的状态可以是临时的，并根据大致正确的时间来自动移除。这非常类似于在第10 章中所描述的带宽按时间调度的例子。

正如在本章前面所讨论的，现存的一些管理接口也允许对路由系统的间接编程，其中包括专有的CLI、NETCONF和SNMP。然而，没有一种机制可以对网络设备内的路由系统进行直接的、快速的、应用程序友好型编程。所以，我们需要一种异步接口来支持动态的、基于时间的应用。

这种接口应该满足应用程序如何与其他应用程序和网络服务进行交互的需求，而不是强制应用程序使用在理解、实施和操作层面上更复杂的传统机制。这种接口应允许应用程序对网络掌握有限的、过滤过的或抽象的知识。

授权和认证也很关键，使I2RS可用于不被网络运行者完全控制的应用程序，但网络运行人员对该应用程序提供了访问I2RS的权限。

I2RS工作组正在制定标准的数据模型及其相关的语义。

许多路由协议虽然是标准化的，但其相关的数据模型却尚未公布。因此，每个路由器都使用不同的信息、机制和CLI，这就使得应用程序所使用的标准接口开发和维护起来极其烦琐。

众所周知的数据建模语言（如YANG14），在数据模型上已有一些进展，并可能用于定义I2RS 所需的数据模型。但对更多替代方法的研究仍然必要。某些部分（希望是一小部分）将继保留为专有扩展，数据模型必须支持未来的扩展和专有的扩展。由于I2RS需要支持主机或服务器上运行的应用程序与网络中路由器间的远程访问，至少需要定义一个标准机制，以提供协议所定义的用于应用程序和路由系统通信的传输语法。 I2RS需要支持常见的功能，包括：确认、通知，以及请求-准备-提交。

14.RFC 6020，http://datatracker.ietf.org/doc/rfc6020/

I2RS工作组的工作围绕着定义合适的候选协议而展开。所选的协议最好不要求应用程序理解和实现现有的路由协议来与I2RS 互动。这些接口应改为基于轻量级的、快速部署的方法。各种技术实现必须进行评估，例如可能包括RESTful Web服务、JSON、XMPP 和XML。这些接口应具备自描述的属性（例如Web 服务接口），这样应用程序可以快速查询和了解网络设备在当前具有的能力。或许还需要定义在本地运行的应用程序对路由器操作的本地语法（例如编程语言的API）。

因为可以预计I2RS随着时间而不断演进，所以版本控制和向后兼容，作为基本的功能要求，是非常重要的。类似地，也需要通用的、一致的错误处理和确认机制，以便不会对接口的可扩展性和响应性造成严重限制。

由于I2RS是相对较新的工作，我们仅能推断它在凝聚一个群体，开始定义满足其崇高目标所需的接口和其他元素等方面已取得一些成功。目标最终能否实现，还需要经过时间的检验。

5.5　现代的服务编排

近年来，网络以及数据中心的许多关键元素的服务编排需求已经兴起。特别是，在部署场景中促进和监测计算和存储是一个关键需求，以达到最快、最便宜、最优化的部署。过去，这些工作是通过手工或用传统的管理系统来缓慢和笨拙地完成。为实现这些功能，目前有多个同期进行的工作正在开展，其任务不仅是定义标准，更重要的是定义雅虎公司、Bloomberg公司、Rackspace公司等生产数据中心环境中所使用的，基于实际部署的、开源代码的事实标准。

从SDN的角度来看，这些工作中使网络得以激活的API仅代表了SDN控制器的API能力子集（主要是因为这些工作专注于服务编排这样的特定应用程序）。

5.5.1　OpenStack

OpenStack15是一个全球合作项目，其目的是为公共云和专有云形成开放标准的云操作系统。OpenStack是可以自由使用的、采用Apache许可的软件系统，可以用来构建大型可扩展的云环境。

15.http://www.openstack.org/

OpenStack目前包括许多软件项目（把这些项目结合起来的共同项目Common除外），参见图5-8：OpenStack的计算（项目名为Nova）、OpenStack的对象存储（项目名为Swift 和Cinder）、OpenStack的网络（项目名为Quantum）、OpenStack的映像服务（项目名为Glance）、OpenStack的身份（项目名为Keystone）和OpenStack的仪表板（项目名为Horizon）。

图5-8：OpenStack 体系结构的组成

这些项目提供了一个可插拔和可扩展的框架，为公共云和专有云形成一个开源的操作系统。

由于与工业界主流的虚拟机管理程序紧密集成，在过去的一年里OpenStack系统已经越来越流行。例如，OpenFlow支持包括ESX、Hyper-V、KVM、LXC、QEMU、UML、Xen 和XenServer。

Nova项目是被设计用来提供和管理虚拟机的大型网络的开源软件，并创建一个冗余备份的和可扩展的云计算平台。该项目代表了大多数人想象中的OpenStack功能。该软件提供了对云服务进行服务编排所需的控制面板和API，包括运行虚拟机实例、管理网络，以及用户和组（即项目）的访问控制。理论上，OpenStack的计算是与硬件和虚拟机管理程序无关的，但实际的构建和支持主要受限于最流行的服务器平台。

Swift项目和Cinder项目是创建冗余备份的和可扩展的数据存储的开源软件。它使用标准服务器的集群来存储访问数据的多个数据块。它不是一个文件系统或者实时数据系统，而是一个长期存储系统，用于存储大量的可以检索或更新的静态数据。对象存储使用分布式体系结构，以防出现有故障的中心点。这也为用户提供了部署选项上的更大灵活性，以及显著的可扩展性、冗余备份和性能。

Glance项目提供了虚拟磁盘映像的发现、注册和交付服务。映像服务的API服务器提供了一个精心定义的RESTful Web服务接口，来查询有关虚拟磁盘映像的信息。这些磁盘映像可以存储在各种后端存储里，包括储存在OpenStack的对象存储里。客户可以使用映像服务来注册新的虚拟磁盘映像，查询已公开的可用磁盘映像的信息，并使用映像服务的客户端库来形成虚拟磁盘映像业务流。这些映像可以供以后引用，其方式和把菜单提供给在餐厅吃饭的客人颇为类似。

图5-9和图5-10展示了OpenStack的三个组成部分，首先是映像启动（即通过虚拟机管理程序调用）之前，连接到虚拟存储器，然后映像被虚拟机管理程序调用。

图5-9：OpenStack 有代表性的三个主要组成部分：存储、计算和映像服务

图5-10：使用一个目录映像实现实例创建后的OpenStack 三个组成部分

Nova项目不配置物理网络接口，但会自动创建所有的虚拟网络桥接（例如br100）和虚拟机的虚拟接口（通过功能子集nova-network）。

Nova项目为其部署的每个虚拟机实例分配一个专有IP地址。该地址通过navanetwork的API连接到Linux网桥上，然后（潜在地）连接到NAT上，以允许虚拟接口通过物理接口连接到外部网络。nava-network的网络控制器提供一个虚拟网络，使计算服务器彼此之间以及与公众网络交互。

目前，Nova项目（nova-network）支持三种网络，实现三种网络管理器类型：扁平网络管理器、扁平DHCP网络管理器，以及VLAN网络管理器。三种类型的网络可以在云系统中共存。

Nova项目将自动创建所有网桥（即br100）和VM虚拟接口。所有的物理机必须有一个公用的内部网络接口。

Quantum项目提供OpenStack 物理节点之间创建所需网络连通性的API（ 即OpenStack Nova 项目所管理的vNIC之间，把网络作为一种服务功能提供给它们）。

这使Quantum项目API与SDN和网络可编程性的讨论紧密相关，但应该指出的是（因为其关注点在于为单一的应用即“服务编排”来提供所需的原语），Quantum项目的API仅是大多数SDN控制器/框架/系统的北向接口所揭示的功能的一个子集。

Quantum项目以创建先进的虚拟拓扑结构和服务为目标，正如较大规模部署中，为了规避基于VLAN部署的局限性，而常用到的二层嵌入三层叠加技术（layer 2-in-layer 3 overlay）。也就是说，Quantum项目旨在从服务实现（即“如何做”）中解耦出服务规范的API（即“做什么”），开拓功能丰富的、由虚拟和物理系统所组成的底层拓扑结构。OpenStack功能通过公开或专有发布的Quantum 项目插件来实施的。该插件体系结构允许厂商们在支持网络服务配置的标准API的同时，隐藏自己的后台实现细节。

Quantum项目当前发布版本（版本2.0）的API通过7~10个插件，来提供简单的二层连通性。插件遵循“单一服务/单一设备”模型，以支持多厂商的虚拟交换机（vSwitch）环境。例如，对思科公司Nexus、OVS和Linux网桥分别有单独的插件。同样，对Ryu和NEC的OpenFlow控制器（以及第4章所介绍的其他控制器）也分别有单独的插件。此外，物理装置通常是带外手工管理的（尽管有越来越多的网元设备厂商提供他们自己的插件）。在Quantum项目2.0版本中，“网络”这个术语包括两个隐含的语义：将端口和服务分组（二层连通性），为端口赋予服务（基于如下假设：端口分组的唯一理由是为端口提供网络的二层连通性）。

Quantum项目2.0版本的要素是：网络（连通性服务）、子网（策略）和端口（租户端点）。Quantum项目3.0版（称为Grizzly）的API处于提案阶段。所提的建议包括增加了三层网络的API（如VPN），增加了网络服务的API（例如，安全性、负载均衡），并有可能走向“多服务/多厂商”的插件模型。图5-11简单展示了Quantum项目2.0版本和3.0版本中元素/关系的不同。

图5-11：Quantum 2.0版本（左）中的元素和关系，以及Quantum 3.0版本（右）中所建 议的元素和关系

Quantum项目3.0版本还有另外一个提案，它是在语义中对“把服务分组”和“把服务连通”服务进行解耦。3.0版本的元素将包括连通性服务[二层区域（layer 2domain）、三层区域（layer 3 domian）]、组（group）、策略[子网（subnet）、安全策略（srcurityPolicy）、浮动IP 地址策略（fIPPolicy）、负载均衡策略（lbPolicy）和服务质量策略（qosPolicy）]、定义策略的规则（rule）、新的端点（endpoint）抽象（无论是消费者还是供应商端点，还是端口）、虚拟机和虚拟应用程序栈（vApp）。

5.5.2　CloudStack

CloudStack16是一个云服务编排的平台，它池化了计算资源来构建公共的、专有的 和混合式的“基础设施即服务”（IaaS）云。 CloudStack与OpenStack在管理网络、存储和计算节点，构成云基础设施等方面非常相似。一个CloudStack云具有层次结构，这使其能够扩展以用单一管理接口来管理大量物理服务器。

16.http://cloudstack.apache.org/

CloudStack体系结构由一些基本要素组成：机架（pod）、集群（cluster），以及二级存储器与主存储器（secondary and primary storage）。Pod是被配置来形成集群的硬件。Pod通常是一个数据中心的机架，包含一个或多个集群，以及各集群共享的与二层交换机的连接。在CloudStack体系结构中，最重要的是Pod对最终用户是不可知也不可见的。这样就保持了多租户的感觉，并为托管服务运营商以及数据中心内的任何其他租户提供了安全单元。集群是一组运行共同虚拟机管理程序的相同主机。例如，一个集群可以是一个预先配置在vCenter中的VMware集群。每个集群都有一个专用的主存储设备。这个主存储设备是虚拟机实例被托管和启动的地方。一个集群中有多台主机，高可用性和负载均衡是一个CloudStack实施的标准功能。

一个资源域（zone）是在CloudStack环境中的最大组织单位，如图5-12所示。数据中心通常包含单个资源域，但也可能包含不止一个资源域。通过构建CloudStack地域上的资源域，虚拟实例和数据存储可以放置在特定位置，以符合对某组织在性能上或地域优化上的数据存储策略。这也可以用来设定存储/计算必须保持在一定地域界限内的规则。一个可用资源域由至少一个Pod和二级存储器组成，该二级存储器可以由资源域内的所有Pod共享。资源域对最终用户而言是可见的。这一点很重要，因为这样就允许用户选择他们希望在哪个资源域里创建自己的虚拟实例。公共资源域对所有用户都是可见的，但我们也可以创建专有资源域，仅提供给特定区域及其相关子区域的成员。其实这就是如何用CloudStack实现多租户业务。

图5-12：一个具有可用性的CloudStack资源域

二级存储系统用于存储虚拟机模板、ISO映像和快照。它们稍后被用来启动虚拟机的实例。该存储可提供给一个资源域中的所有Pod使用。存储也可以在可用的资源域之间复制，从而提供整个云中的通用存储平台。这也可以是自动的。

主存储系统对于每个集群都是唯一的，用于承载虚拟机实例。由于主存储系统是一个重要组成部分，它往往是构建在高性能的硬件上，采用多个高速磁盘来使系统成为兼具冗余性和更高性能的单元。

二级存储使用网络文件系统（NFS）。NFS是一种广泛部署的文件系统，内置联网功能，因而在该资源域中的任何主机都可以访问CloudStack 的存储。

CloudStack被设计与任何符合标准的iSCSI，以及所支持的任何虚拟机管理程序的NSF服务器协同工作。

5.5.3　Puppet

Puppet17是一组IT自动化软件工具[ 通常称为DevOps（开发运营组合）工具18]，帮助系统管理员管理基础设施中， 从业务开通配置到补丁管理和软件合规性 （compliance）的整个生命周期。

17.https://puppetlabs.com/
18.这里选择Puppet作为DevOps配置工具的例子来讨论网络可编程。还有很多其他可选的软件都有类似的功能，包括Chef、Ganglia 和UrbanCode。此外，还有一些软件的扩展工具链（来自附加代码库的附加软件模块），包括具有监测、日志记录等功能的应用程序。

图5-13所示为DevOps 管理周期示意图。Puppet允许IT管理员实现重复性任务的自动化执行，快速部署关键应用，并积极管理变化的服务器。

图5-13：Puppet的DevOps高级别管理周期

Puppet既有开源的版本，也有多种商业化的企业版本。

Puppet使用声明式的(declarative)、基于模型的方法来实现IT自动化。这种语言允许IT管理员使用Puppet的声明式配置语言，来轻松定义所需的基础设施配置。它使管理员能够在具体实施前模拟各种配置的更改。它会自动启用对基础设施所需状态的强制执行。管理员也可以使用它来纠正任意配置更改。最后，Puppet为管理员提供报告，用来检测实际运行状态和所需状态之间的区别，并进行更改以强制执行到基础设施的所需状态。

要定义一个基础设施所需的状态，我们可以首先从预先构建的、可免费下载的配置模板中进行选择，或通过使用Puppet的配置语言来创建自定义的模板 。一旦定义，这些配置可以跨物理、虚拟和云环境来使用，而且可以跨操作系统来管理和编排基础设施的组件。它也可以合并或混搭配置模块，以创建完整的应用程序配置栈。这些栈集成到基础设施的管理应用程序里，或在某些情况下集成到SDN的控制器里就会产生作用。

配置完成后，每个基础设施节点上的Puppet代理与Puppet主服务器定期通信，自动地通知其状态。Puppet主服务器可以指示这些节点来强制执行达到所需的状态，或者只是简单地监测并报告它们与预期配置的偏差。节点上的Puppet代理将Puppet体系结构所称的“fact”（即关于节点状态的数据）发送回Puppet主服务器。发送基于固定的时间间隔，或者基于所发生的事件。利用这些收到的“fact”，Puppet主服务器编译出称为 “catalog”的，关于在节点应该如何配置的详细数据集。此信息会定期发送回Puppet 代理。参见图5-14，其中所示为Puppet配置/服务开通周期的示意图。

图5-14：Puppet 配置/ 业务开通周期（详情）

在进行更改回到所需状态后，Puppet代理发送一个完整的报告到Puppet主服务器。通过开放API与其他IT系统集成，该报告完全可以被其他IT 系统访问。应当指出的是，这些报告可以在称为 “无操作”（no-op）的模式下执行，该模式允许管理员模拟各种变更，而无需对网元设备进行实际更改。这使Puppet成为重要的“假设”（what if?）场景测试工具，以及规划工具。

5.6　小结

本章介绍了SDN最重要的一个特性（方面）——网络可编程性——的概念，可编程性真正使SDN 与很多人可能会认为的“SDN不过是网络管理的另一种形式”的看法区分开来。

本章介绍了可编程性的概念，并讨论了可编程性如何在网络设备、控制器和软件组件中作为这些网元设备之间交互的关键而存在。为了使网络设备易于编程，首先要建立某种形式的设备和与之通信的其他软件之间的双向通信通道，这些软件包括控制器或与控制器通信的应用程序。

然后，本章还介绍了这些网元设备之间“紧耦合反馈回路”的概念。我们讨论了为什么这一概念不同于传统的，关注简单的“被管代理和管理器模型”的网络管理范式。

SDN的成功在于，多个管理器、多个代理和多个控制器在紧耦合通信的“交响乐”中互动，以实现传统的网管模型所不能实现的网络优化和能力。

为了实现通信和交互的新范式，我们需要紧耦合的、双向的流接口。本章解释了为什么这些编程接口需要在软件中被方便和迅速地实现，以推进其使用和实现无处不在的部署。这些接口通常称为应用友好型接口，体现了今天现代应用程序的编写方式。这些内容有的已在第4章介绍过，但在本章中进一步展开论述，全面细致介绍如何达到此预期目标。第9章将再次讨论这个问题。

然后，本章还详细描述了一些具体的编程接口和流接口，包括JSON、谷歌公司的Protocol Buffers、Thrift，以及更近期的IETF的I2RS工作组的工作。

本章最后讨论了服务编排的接口，例如OpenStack、OpenCloud 和Puppet。它们在本质上其实也是可编程性的一种形式。

第6章　数据中心的概念与结构

6.1　引言

在数据中心出现以前，计算资源、存储资源和连接它们的网络资源都位于企业用户的桌面PC上。随着存储技术的发展和合作需求的出现，企业安装了部门服务器来提供这些资源。然而这些服务器只能提供本地服务或者有限服务。随着时间的发展，部门服务器无法处理负荷的增长以及用户更大范围合作的需求，因而迁移到了更加集中化的数据中心。数据中心简化了软硬件的管理与维护，也更便于所有企业用户之间资源共享。

现代数据中心的最初设计是为了把传统的计算资源（比如PC 服务器）、与之相连的存储资源（也就是存储局域网络，SAN）以及把它们与用户相连的网络资源从物理上分隔开来。这类数据中心内部的计算资源逐渐变得只用于提供特定的服务器功能，比如运行邮件服务器、数据库服务器或者其他企业IT应用程序。

大约10年前这一情况出现了有趣的变化。一家叫做VMware的公司发明了一种有趣的技术，能够在宿主操作系统，比如某个流行的Linux 发行版本上，像运行其他软件一样运行一个或多个客户操作系统（比如Windows）。WMware 开发了一个管理程序来生成一个模拟真实计算环境（比如虚拟网卡、BIOS、声卡和显卡）的虚拟环境。然后在这些虚拟机上分发真实资源。这个管理程序叫做虚拟机管理程序。这项技术彻底改变了IT 界，因为这意味着服务软件不再需要固定占用某些硬件资源，而是能够以一种非常灵活的方式部署，也能够更充分地利用硬件平台。具体细节请参考图6-1。

图6-1：作为虚拟机的虚拟化应用程序运行在一台物理服务器上

数据中心服务器可以在虚拟环境中同时运行多个操作系统，通过内存、计算资源和存储的升级和扩充，还可以增加操作系统的数量。像Windows这样的操作系统之前要占用整个物理服务器，现在则可以在虚拟机环境里共存，并各自运行用户所需的应用程序。另外，现在网络管理员也不一定非要再根据物理机的情况来确定计算能力。取而代之的是计算能力可以随着资源的变化动态增减。从此进入了弹性计算的时代。

在弹性计算的环境下，业务部门可以在物理数据中心之间迁移服务器，只需要暂停虚拟机后通过网络将其复制到新的物理计算位置（也就是一台服务器）上。甚至可以快速启动一个新的虚拟机来扩充资源，只需要复制文件并通知本地或远程机器上的虚拟机管理程序运行同一服务的这个新实例即可。当某个资源不再需要的时候，只需要关闭甚至直接删除这个服务器实例。这样的灵活性使得网络管理员可以从基于电力和冷却系统的角度，来优化数据中心资源的地理位置配置以提高效用。通过bin packing技术可以把虚拟机锁定在物理机上，进而可以针对不同的特性优化，比如服务器的网络局部性，甚至可以关闭未使用的物理机以减少耗电或节省冷却系统。实际上，很多现代数据中心都会优化虚拟机的位置，因为耗电和冷却系统对成本有决定性的影响。在这种情况下，管理员可以调低或关闭数据中心整个分部的冷却系统。类似地，管理员可以根据地理位置的需求来迁移或者动态扩展计算、存储和网络资源。图6-2展示了一个现代数据中心。

图6-2：由计算资源、存储资源和网络资源构成的现代数据中心

和所有技术上的发展一样，这种新技术在带来对计算资源、存储资源和网络资源灵活部署的同时，也带来了两方面的运维效率的新问题，一是如何将存储设备和计算能力的使用率最大化，还有一个是耗电和冷却系统的效率问题。前面曾经提到，网络运营商已经开始认识到，通常来说随着时间发展，计算能力的需求总是越来越高的。为了满足这样的需求，IT部门（通常是按年度预算）需要订购下一年里所有预计将会用到的设备。然而一旦购买并安装了这些设备，它们就会消耗电力、冷却系统和空间资源，即便是数月之后它们才会被真正使用。

普遍认为是亚马逊公司最先发现了这个问题。当时亚马逊的业务增长率几乎达到了极致，每6个月翻一番。曾有段时间亚马逊的计算资源、存储资源和网络资源无法跟上需求的增长，这些需求来自于他们的在线订购、官翻网和内部IT系统。亚马逊曾经试图通过当时已有的方法预先订购大量设备来提前满足这些需求，但是他们也遇到了这一普遍问题，即不得不提前很长时间来购买设备，以至于这些设备在计算服务需求出现之前要闲置相当长的一段时间。这时候亚马逊意识到，设备增长确 实需要提前于计算服务的需求，但它需要恰到好处地满足需求。由此产生了亚马逊Web服务（AWS）的想法。这个想法基本上就是，仍然提前购买存储、计算和网络设备，但不是放任它们闲置，而是利用弹性计算的原则来出售未使用的资源池，从而使资源达到几乎百分之百的利用率。当内部需要更多的资源时，可以简单地通过减少零售用户来获得；即内部不需要资源时，可以将其出售给零售用户。有时候这被称为弹性计算服务，因为多数大型数据中心都是在超大规模上实现弹性计算的，所以本书中称之为超虚拟化（hyper virtualization）。也正是因为虚拟化这个词的流行，这个概念在存储、计算、存储资源中都广泛使用。

6.2　多租户数据中心

亚马逊AWS模型中值得注意的一个关键点，不仅体现在亚马逊虚拟化服务上，同时体现在访问控制和资源管理方面。现在它还需要一种新的模型，通过让外部用户进入其内部网络，它已经创建了一个多租户数据中心环境。这当然会带来新的问题：可能有成千上万的用户，他们的资源可能需要任意分布在不同的物理数据中心上的虚拟机中，同时又要满足他们对自己AWS云的随时私有访问，如何隔离这些用户呢？图6-3展示了这个概念。

图6-3：多租户数据中心概念；在多租户数据中心内部，用户必须能够访问自己私有的计算、存储和网络资源的虚拟切片，而这些资源对其他租户是保密的

还可以从另外一个角度来考察这个两难问题，请注意，在向超虚拟化环境迁移的过程中，执行环境是由单个企业或组织运行的。也就是说，所有这些计算资源和存储资源（尽管有些是租用的托管空机房）都是由这些企业或组织来拥有并维护的，就像是一个连接大量虚拟机或物理机以及网络附加存储的单一扁平局域网（LAN）一样。金融机构是一个例外，因为监管机构强制要求隔离。然而，在这种情况下的部门（或租户）的数量相对来说是很小的，不会超过100个。同时这些部门共享同一个私有网络IP地址空间。通过当前已有的工具，比如MPLS2层或3层VPN，这很容易实现。尽管在两种情况下，连接所有计算、存储资源的网络组件到目前为止都是十分简单的：它只是一个连接所有物理和虚拟服务器的扁平以太局域网。多数情况下，这种环境为所有设备（物理的或虚拟的）分配的IP地址在同一网络（可能有IP子网），就像是一个单独的企业拥有这些机器并需要访问它们一样。这也意味着，通常来说在一个企业内部的不同数据中心之间迁移虚拟机不是个问题，因为它们都在同一个路由域内，所以不管物理位置在哪，它们都可以彼此访问。

在不同的环境里，租户这个概念有不同的含义。对于提供公有云服务的服务运营商数据中心来说，它是指某客户。对于实现了私有云解决方案的企业数据中心来说，它可能意味着某部门（可以看成是一个内部客户）。虽然不是完全互斥，但是多租户和多用户或者多企业的概念是不同的。租户是在用户和企业边界之上的一个概念。在公有云和私有云中多租户都是常见的，而不仅仅局限在基础设施即服务（IaaS）数据中心里。

2008年当云计算成为了一个热点时，Phil Waine-wright1在一篇博客中试图把“多租户”这个概念内部的细微差别定义为建立在应用层的架构里，租户是共享的应用程序环境或其子环境中的一个用户（博客中的观点）。在博客最初的版本中，用多租户共享度（degree of multitenancy）这个概念来定义多租户的区别。这个概念表达的是应用程序的共享程度，下降到数据库这一层，就是定义了数据库结构的模式（schema）的共享程度。文中给出了一个Salesforce.com（http://salesforce.com）的示例，它部署在单个模式之上（所有客户共用），通过数据库复制技术扩展到分布式系统上（博客发表的时候，Salesforce 达到了令人难以置信的数据库实例与客户比率1∶50002）。

1.参见http://www.zdnet.com/blog/saas/many-degrees-of-multi-tenancy/533
2.在模式程度共享对比中还给出了一个共享程度低一级的示例（Intaact，模式/客户比率1∶250）还有一个共享程度更低的示例，就是Oracle的“pod”架构（作者认为这是“对共享模式原则的背弃”）。

到了2012年，这个思路又被重新拾起，如下几个重要的云架构都把多租户共享度这个概念映射到了常用的数据中心应用/ 服务原型中（参见图6-4）。

图6-4：多租户共享度

- 基础设施即服务（IaaS）
共享基础设施（计算资源、存储资源和网络资源）。比如亚马逊。

- 平台即服务（PaaS）
共享应用程序开发环境。比如Google App。

- 软件即服务（SaaS）
共享应用程序。比如Salesforce.com。

这些架构还引入了（有别于客户对模式的共享程度）第二个多租用维度。在这个模型里有如下特点。

- 在数据中心服务层级图中，最高的多租户共享度发生在IaaS和PaaS中。

- 包括IaaS在内的三类服务都是完全多租用时，整体的多租户共享度最高。

- 在IaaS和PaaS是多租用，而SaaS是在物理机集群中多租用或者SaaS对于其各种子模块多租用时，可能出现中等的多租户共享度。

- 最低的多租户共享度发生在SaaS是单租户的时候。

这些度量方式描述了应用程序组件和支撑它们所需的网络及安全架构之间的耦合程度，这关系到单个虚拟机或者一组分布式但又非独立（distributed-but-dependent）的应用程序/服务组件集合的迁移的重要因素，也就是说，对于SDN应用的招牌特性，VM移动性是至关重要的。

本章将会探讨多租户数据中心背后的基本概念、相关架构，以及可能会成为数据中心SDN标准的控制平面解决方案。

6.3　虚拟化多租户数据中心

虚拟化多租户数据中心使得多个租户可以共享同一个数据中心，同时为他们提供对资源虚拟化切片的私有访问。数据中心网络可能是多层网络。如图6-5所示，尽管最初是从骨干-枝叶这样的两层网络设计开始的，但后续的发展导致了第三层汇聚层的出现。如图6-6所示，数据中心也可能单层的（比如瞻博公司的Q-Fabric）。

图6-5：多租户虚拟化数据中心（多层数据中心网络）

图6-6：单层数据中心网络的多租户虚拟化数据中心（瞻博公司的Q-Fabric）

一般来讲，每个租户对应着一组虚拟机，这组虚拟机运行在运行着虚拟机管理程序的服务器上。虚拟机管理程序包含有虚拟交换机（vSwitch），以便把虚拟机和物理网络以及虚拟机彼此之间连接起来。应用程序也可能运行在物理服务器上。也就是说它们不是运行在虚拟机上，而是运行在一个专为这个应用提供的完整机器上，如图6-6中右下角的服务器B所示。

服务器之间通过物理网络互连，通常是高速以太网，也有的使用光环网的变种。在图6-5中，网络是两层网络（接入层、核心层）。实际中也可能是三层网络（接入层、汇聚层和核心层），或者是单二层网络（比如Q-Fabric）。对于叠加网络解决方案来说，数据中心网络也可能是一个三层网络（IP、GRE 或者MPLS）。

如图6-7所示，每个租户都被分配了一个私有网络。租户网络允许这个租户的服务实例之间在访问策略的限制下彼此通信。在现实情况下，这意味着每个运行服务的物理机或虚拟机必须能够通过二层或者三层网络访问同一个逻辑租户组的其他服务器。多个租户网络彼此之间是隔离的，即除非特殊指定的策略允许，一个租户的虚拟机，是不能和其他租户的虚拟机通信的。

图6-7：呈现给租户的逻辑网络抽象

租户的私有网络通常是二层网络，某个租户网络上的所有虚拟机都配置在同一个三层IP子网中。虚拟机的IP地址可以由租户自己指定，或者由云业务运营商来分配。不管采用何种方式，IP地址在租户之间不一定是唯一的（即两个租户的虚拟机可能使用同一个IP地址）。在这种情况下，如果想让这些租户能够彼此通信或者访问外部网络（如公共互联网访问服务），一定要采用某种网络地址方案（NAT）。

单个租户可能拥有多个网络，例如，在为了实现安全区，在使用IaaS服务的情况下，为了合并多个部门，或者使用多个云业务运营商托管业务时。图6-8展示了如何在企业本地数据中心上附连多个云业务运营商来拓展数据中心，以此提供弹性云服务。这种配置的优点是：冗余性；能够使用价格最低廉的云服务资源（就像多个商家提供的消费电器一样）；或仅仅是为了给部署在广阔地理范围上的服务提供地理覆盖。

图6-8：一个租户企业的多个网络。租户云网络A1、A2、A3和A4分布在多个地理位置，来自于多个逻辑运营商，整合起来为用户A提供了一致的虚拟服务

6.3.1　服务编排

服务编排是虚拟化多租户数据中心解决方案的一个重要方面。为了部署和管理多租户数据中心，运营商需要实现某种形式的逻辑上集中化的服务编排。数据中心服务编排提供了逻辑上集中化的控制以及与网络管理员的交互点，是控制其他网络控制器的中心点。从整体来说，服务编排层提供了以下功能：

- 添加删除租户；
- 服务开通后的账单系统接口；
- 工作流自动化；
- 为租户添加删除虚拟机；

- 指定租户网络的带宽、服务质量（QoS）和安全属性。

服务编排必须涵盖，包括与计算、存储、网络和存储系统或控制器的接口在内的数据中心的各个方面。其实现一定要支持快速变化，以适应真正的弹性计算服务，如图6-9所示。

图6-9：数据中心服务编排引擎实例。数据中心服务编排为网络管理员提供了逻辑上集中化的控制以及与网络管理员的交互点，是控制其他网络控制器的中心点

6.3.2　连接租户到互联网/VPN

如图6-10所示，通常数据中心租户通过某个VPN 连接到互联网或者租户的企业网络。VPN可能是L3 MPLS VPN、L2 MPLS VPN、SSL VPN、IPsec VPN或者其他类型的VPN。不同类型的VPN 各有其优缺点，这也和数据中心采用何种承载网络（比如以太网、VLAN、Stacked VLAN、VxLAN 或者MPLS）相关。本章后面会详细讨论各种类型的承载网络和叠加网络。

如图6-10所示，数据中心网关负责连接租户网络到互联网或其他VPN站点。注意根据采用网络架构的不同，可能部署有多个网关。实践中普遍的情况仍然是，部署物理设备作为网关，用软件实现网关功能作为虚拟服务也完全没有问题。在第7章将对此进行深入讨论。

图6-10：连接租户到互联网/VPN

6.3.3　虚拟机迁移与弹性

虚拟机（VM）迁移是指把虚拟机从一台计算服务器移动至另一台服务器上。这包括运行中的虚拟机，也包括休眠、暂停和关闭状态下的虚拟机。多数情况下这个操作最终会是新计算资源附近（但近距离不是必要条件）的服务器或者存储阵列之间的文件复制。

虚拟机迁移的原因可能包括下面这些：

- 数据中心维护；

- 工作负载均衡/重新平衡/扩容（包括电源管理）；

- 数据中心迁移、合并或扩容；

- 避灾/容灾；

- 地理局部性（也就是说，把服务访问移动到距离用户比较近的位置以提高用户体验）。

根据此前给出的租户定义和租用度的概念，只讨论单个服务器实例的迁移是最容易说明的实例。在某些情况下，应用可能是多层的，表现为紧耦合的一系列虚拟机和网络组件。迁移这种环境里的单个虚拟机可能会引发性能或带宽问题，这时管理员或编排系统需要清楚这一系列设备的依赖关系。然而，在其他某些情况下，应用的各个层次（比如计算服务、前端负载均衡器、Web服务器和后端分布式数据库）之间的耦合度很低，更像是利用Hadoop或者其他多进程分布式架构的应用程序。虚拟机迁移，或者更一般来说，撤销和创建，通常对服务只有正面影响。这种情况下，通常不会使用实时虚拟机迁移。图6-11中给出了一个三层架构。在这个三层架构中，需要单个虚拟机实现所有这三层，但是可以随时创建更多的（组件）虚拟机在本地或远程运行，来扩展或缩减计算资源。无缝工作进程分发由像Hadoop 这样的技术来处理，通过Hadoop可实现这种颗粒度化的弹性计算模型。无缝并且易于扩展的、高度弹性化的后端数据库功能由像Cassandra这样的技术来实现。

图6-11：现代应用采用的三层应用架构

关于DCI用例的数据中心之间的在线迁移应该在何种频度上执行，这一问题一直存在着一些争论。这是因为要实现迁移，一定要把当前激活运行的虚拟机文件复制到新的服务器上，因为文件可能会在文件复制操作的过程中发生改变，所以虚拟机不能在文件复制的时候运行。因而在现实中，这种操作执行的越来越少，取而代之的是更简单（也更安全）的三层应用架构，其中要进行的工作就是创建和撤销虚拟机。

图6-12展示了两个服务器之间的虚拟机迁移过程。如果两个服务器在同一个数据中心上，那么就是数据中心内的虚拟机迁移，只需要在暂停这个虚拟机之后，进行一个简单的点对点文件的复制操作就行了。如果两个服务器在不同的数据中心上，则称为数据中心间的虚拟机迁移，此时还是需要在两个IP端点之间进行文件复制，但可能涉及在更复杂的网络路径上传输文件。基于此，再加上别忘了之前关于在线虚拟机迁移的讨论，要保持虚拟机在文件传输的同时是激活运行的话，网络必须在迁移的同时继续工作，所有的会话（比如TCP连接）必须要保持。这部分由管理虚拟机和虚拟机迁移的虚拟机管理程序系统来负责。

图6-12：虚拟机迁移

很多时候，为了实现无缝迁移，需要虚拟机保持原来的MAC地址和IP地址，还有虚拟机相关的配置状态，这使得情况变得更为复杂。此外还包括其他与网络相关的项目，比如QoS配置、ACL、防火墙规则以及安全策略。所有这些也必须一同迁移到新服务器或接入交换机上。同时还包括虚拟机自身和虚拟交换机内部的运行状态。另外，还必须通知物理网络中的交换机更新以反映这台虚拟机的新位置，包括MAC地址表、ARP表和组播组成员表。正是由于这些复杂性，采用三层应用设计模式简单地创建和撤销( 组件) 虚拟机会更容易一些。

实现虚拟机迁移的方式有以下三种。

- 网络数据平面驱动方式
可以通过支撑网络设备监测虚拟机的出入网络流量（比如说，监测无故ARP 消息）来检测到虚拟机迁移。

- 虚拟机管理程序驱动方式
可以通过虚拟机管理程序中组件（vSwitch或者vGW）的内部监测来发现虚拟机迁移。实现方法之一是老的虚拟机管理程序监测到虚拟机消失，新的虚拟机管理程序监测到虚拟机出现。

- 编排系统驱动方式
虚拟机迁移不是先验地在运行时检测到，而是在执行虚拟机迁移之前由编排系统显式地触发运行时状态迁移。

可以通过以下两种方法之一来更新运行时状态。

- 数据平面驱动方法
虚拟机发送消息强制运行时状态更新。比如虚拟机可以广播一个不需要的ARP消息，使得租户网络内部所有的MAC 地址表更新指向虚拟机MAC地址的新位置。

- 编排系统或控制平面驱动方法
编排系统使用控制平面信令协议来显式更新所有需要更新的位置上的运行时状态。

关于检测虚拟机迁移和更新运行时状态的方法可以参见本书6.4节的介绍。

虚拟机迁移通过把完整状态（磁盘、内存、寄存器等）从一个服务器复制到另一个服务器来实现。通常是通过复制集成了所有这些状态的虚拟机文件来完成。复制的初始阶段可能需要几分钟，在这个阶段里复制过程是在后台完成的，虚拟机仍在原来的服务器上运行。在复制将要结束的最后几秒钟内，暂停原来的虚拟机，复制剩余的最后一部分状态，然后虚拟机在新的服务器上开始运行。这个过程需要两个服务器之间具备高带宽和低延迟，因为虚拟机服务不可用的时间是由实现方法中最后一步消耗的时间决定的。

另外一种方法是为虚拟机建立快照并暂停虚拟机，然后把快照搬迁到另外一台服务器上，之后虚拟机管理程序会恢复虚拟机运行。这是迁移但不是在线迁移3。在线迁移会涉及存储系统，特别是如果虚拟机使用共享存储模型，其中两个虚拟机共享同一个物理磁盘（阵列）的同一逻辑卷，并传递了一个允许迁移过程中I/O 继续进行的锁定。根据磁盘访问协议（iSCSI、NFS、光线通道）的不同，这个过程可接受的距离和延迟也有所不同。也可以把应用分解为多个层次，使用公用后端数据库存储状态和其他信息。只要在虚拟机迁移之前的暂停之前锁定这个状态。在其它位置重启虚拟机后，只需要重新连接到这个存储，就能继续运行。

3.替代方案是卷之间使用活跃/活跃同步数据发布，据称支持的距离可以达到100公里。

根据服务类型（IaaS、PaaS 或者SaaS）和租用率的不同，虚拟机迁移的规模和性能有所不同。基于这一代Intel/ARM处理器，c.2012的典型运营商提供的简单IaaS服务规模大概如下。

- 数据中心数量
数十个（完全由地理情况决定，给出的数字是对于像日本这样大小的国家而言）。

- 每个数据中心提供的服务数量
数万个。

- 每个集群/机架提供的服务数量
1000 个。

- 每个服务器的租户个数
大约20个（当前处理器，下一代预计数量会翻倍）。

- 每个租户的虚拟机数量
大约5个。

- 虚拟机变化率
高度可变。

- 虚拟机变化延迟
根据厂商和应用的不同有所不同。

6.3.4　数据中心互连（DCI）

本章已经介绍了一些基本概念来说明数据中心是什么，以及数据中心如何构建，现在来讨论一下如何连接一个或多个数据中心。出于地理多样性、灾后恢复、服务或者云猝发这样的可能原因，需要配置多个数据中心，数据中心在某种形式的广域网（WAN）之上需要彼此连接。即使对于从地理位置来看只不过一个街区之隔的数据中心也是这样，虽然这时通常是通过某种城域网来互连。有各种各样的技术可以用于实现这样的互联，包括EVPN、VPLS、MPLS L3 或者L2 VPN、虚链路，甚至简单的平坦IP网络。

只要有超过两个数据中心，就需要考虑如何连接它们。举例来说，一个租户可能在每个数据中心上有若干个虚拟机，需要至少在逻辑上互相连通。数据中心互连（DCI，参见图6-13）把用户所有数据中心上的虚拟机放在同一个L2或L3支撑（也就是承载网络）租户网络上4。通过之前讨论过的多租户数据中心引出的概念，可以发现连接数据中心这件事，就像是把数据中心当作乐高积木连在一起一样方便。

图6-13：数据中心互连（DCI）

4.另外一个数据中心网络中使用二层网络的驱动力，来自于VM移动时持续连通性的需求。简单地说，就是VM移动的过程中，源服务器和目标服务器不需要在同一个IP子网内，但为了保持IP 互联性，扩展二层连接性可能是一个吸引人的方案。

连接数据中心也不一定就是这么简单，因为需要考虑到各种各样的因素。在讨论DCI实现的各种方法之前，先来查看一下正确的DCI解决方案的一些需求，以及讨论更重要的一些关于此的谬误。

6.3.5　关于数据中心分布式计算的谬误

设计数据中心互连的架构或策略的时候，不可避免地需要列出互连的需求，这通常从一系列假定前提开始。作者发现，在实践中，很多假定都是在理论上似乎有道理，但在实践中却无法保证的。这些假定包括下面这些。

- 可靠网络；
- 零延迟；
- 无限带宽；
- 网络是安全的；
- 拓扑结构不会改变；
- 有一个管理员；
- 传输成本为零；
- 网络是同构的。

一开始这些概念看起来似乎很有道理，但是在实际中却是很难（或不可能）实现的。比如，前面四点对采用的技术和实现这些技术的设备做出了假定。但是没有哪家的设备是完美的或者说是不出错的，所以实际上作者做出相反的假定更为安全。第四点到第六点涉及管理或者人为因素。所有一切都是相同的，一旦网络配置好了，就应该一直这样运行下去直到做出修改。但这其中也暗藏着问题：从网络的正常运行来说，配置操作错误（比如输入错误）可能是灾难性的，还可能无意中引入了安全漏洞。（统计表明，在节假日期间，网络管理员没有进行操作时，网络出错率有所下降。）

6.3.6　数据中心分布式计算的陷阱

DCI必须要考虑到租户的地址空间是可能重叠的，比如使用L2 MPLS VPN、L3MPLS VPN、GRE 隧道、SSL VPN或者其他隧道机制分隔地址空间。根据所选地址管理策略的不同，这可能会导致出现前面6.3.5节中所讨论过的问题。特别是，如果地址重叠而又需要隔离保护的时候，如果配置操作失误使得某个租户不小心能够看到其他租户的虚拟机，就会出问题。所以请记住，地址管理方案的选择不是那么简单的，需要考虑操作因素、管理验证和检查机制。

数据中心互联也是有性能标准的。许多限制来自于数据中心（之前讨论过，包括磁盘I/O）之间的在线迁移，考虑到在线迁移的高效实现有很多障碍需要克服，关于在数据中心互联的设计中是否需要考虑这个用例还有大量争议。举例来说，Broadband 论坛上关于DCI 的讨论，指出VMware VMotion 解决方案需要数据中心之间至少有622Mbit/s的带宽，建议的源服务器和目标服务器之间的往返延迟（RTT）小于5毫秒（参见图6-14）。这极大地限制了服务器之间的物理距离。现实 中，到底需要多大带宽实际上是从已知数据中推导出来的。

图6-14：推荐VMotion 延迟（互连带宽622Mbit/s）下的距离限制

这个数据可以概括地说，但它很大程度上取决于租户服务特点和目标限制。DCI带宽是一个重要的考虑因素，因为它直接关系到变更窗口时长和要复制的数据量。RTT 以及由此得出的数据中心分布距离也是一个限制5。这些限制都可以通过计算来优化，前面举的示例是，某个数通产品变更窗口的时长3小时的确定的连接带宽。当然，这些计算可以针对单个基本操作进行，也可以针对多个操作的集合，其得出的数值会有所不同。

5.RTT/距离的关系最主要受限于光纤中的光速，400 km的距离限制来自于使0.005ms/km（因为这是来回的值，所以实际是单方向上2.5ms）作为传播速度的粗略计算。

总结下来，DCI设计通常要考虑以下涉及规模的因素。

- 对于使用L2扩展的解决方案来说，数据中心WAN边缘的MAC地址可扩展性是一个问题（比如，单个运营商数据中心的250k客户MAC地址在互连的运营商数据中心和企业数据中心复制）；

- 虚链路规模（也就是直接LDP会话的个数、MAC地址学习的数量）；

- 控制平面规模（也就是L2控制平面域是否扩展到跨数据中心）；

- 广播，未知单播和组播流量处理（BUM）。

最后，可能需要混合L2扩展和IP互连。后者可能是直接IP转发或L3 VPN。更进一步的问题是关于是否要隔离不同数据中心的控制平面。

1. DCI的方法

上文已经讨论过一系列的常用DCI方法，从最简单的到最复杂的，如下分类可以凸现它们各自的优缺点。

- 在数据中心链路上使用802.1q trunk 的VLAN扩展。这种方法需要考虑的问题与在数据中心中使用VLAN一样，包括MAC地址扩展性、可能出现的生成树环、BUM 流量无法预测以及几乎无法控制多条链路上有效负载均衡（流量工程）的问题。

- 对于VLAN扩展的问题有一些专有的解决方案。例如思科公司的vPC（虚拟端口通道），提出的合并内部数据中心链路，并过滤生成树BPDU分组来避免生成树环路的方案。

- VPLS在数据中心之间的物理连接上使用MPLS建立虚链路叠加层。MPLS的需求伴随着LDP和/或叠加层控制平面的多协议BGP需求，尽管这可以通过像自动发现（Auto Discovery）这样的技术来解决，但可能对于某些操作者意味着更复杂的操作。6

6.RFC 4761（基于BGP 的VPLS）、RFC 4762（基于LDP 的VPLS）、基于LDP 的VPLS 上BGP自动发现、RFCxxxx、基于LDP的VPLS上的分层VPLS方案。

- MPLS带来了另外的潜在功能需求：流量工程、快速路由更新、组播/广播复制、某种程度的数据中心隔离以实现重叠VLAN分配和拓扑结构隐藏，以及更好的支持和交互性。

2. 用VLAN来实现DCI

最简单的DCI解决方案就是VLAN。如果每个数据中心的租户个数不超过4000，使用VLAN作为隔离机制是完全可以接受的，也是可扩展的。从高端的路由交换设备直到消费级交换机，多数硬件都支持这种机制。使用这种机制的优点是架构上几乎不需要改动什么，操作成本也很低。而缺点是修改可能非常复杂。也就是说，如果将来的需要发生变动的话，可能需要在很多位置修改VLAN/ 标签映射。

这种解决方案的实现，只需要把数据中心VLAN解决方案，简单地映射到数据中心内的IP或者以太网路径上，它们在这些路径上将打了标签的在数据中心网关之间的数据流量，转发到本地数据中心。

3. 用VPLS来实现DCI

如果需要支持的租户数量超过4000，就需要采用其他方法。一个可选方案是使用虚拟专用局域网服务（VPLS）。VPLS的基本运作方式类似于VLAN 服务，除了使用MPLS（L2TPv3）和虚链路来连接数据中心之外。并且VLAN（或stacked VLAN)映射到网关上的虚链路上，这样数据中心VLAN 到虚拟机的映射就连接到了一起。图6-15中展示了这种情况，其中CE 表示网关交换机/路由器或柜顶式交换机（ToR），具体要看架构需要VPLS深入到网络何种程度。如果是前者，VLAN到 VPLS隧道的映射发生在网关位置，否则映射发生在柜顶式交换机ToR 上。对于扩展性、操作、管理和变化响应来说，两种方法各有其优缺点，但总的来说VPLS 解决方案具有以下特性：

图6-15：VPLS实现DCI（水平分割去除了通过N-PE 2、N-PE 4或者N-PE 3上的LSP到达目标CE 的路径）

- 泛洪（广播、组播和未知单播）；

- 动态MAC地址学习；

- 核心层水平分割和全网PW避免环路（核心层没有运行生成树协议STP，所以数据中心生成树SPT域是分隔的）；

- 次优组播（尽管可能通过标签交换组播技术改善）；

- VLAN到虚链路的映射可能会限制单个物理接口所支持的租户数量（4K）；

- 基于VLAN的双归属设计可能要求PE/DCI网关之间使用虚拟交换机集群技术和虚链路冗余（活跃/ 活跃冗余）；

- 等价路径上的负载均衡可以单纯基于VLAN实现（但不是基于流的，除非进一步引入像熵标签（Entropy Label）或流感知传输（Flow Aware Transport，FAT）虚链路这样的增强技术）7。

7.熵标签RFC 6790和FAT虚电路RFC 6391。

虽然VPLS是简单VLAN或stacked VLAN方法之上的一个重要改进，但它也还存在一些问题。比如，与VLAN和stacked VLAN方法类似，这种方法数据平面学习还是会引起MAC扩展的问题8。这些问题还可能导致网关点上出现问题，如图6-15所示。因为需要网络配置中在PE之间实现部署虚链路隧道（或者在网关或者在柜顶式交换机ToR，具体要看是什么架构），这也可能会引起虚链路扩展维护问题。

8.一个解决MAC 地址问题的提议是同时使用PBB/801ah和VPLS。

4. 用EVPN来实现DCI

以太网VPN（EVPN）是一种基于MPLS的解决方案9，它的目标是解决VPLS解决方案的缺陷。EVPN为数据平面MAC地址学习扩展了一个控制平面解决方案，来实现数据中心之间的MAC地址学习过程的自动化。通过把MAC地址转化为可路由的地址，EVPN 为BGP创建了一个新的地址族，然后用它在网络中的PE之间发布MAC地址学习信息。目前已经出现了对EVPN新的优化方案来进一步优化MAC地址学习过程，以增强扩展性。

9.EVPN也可以与PBB共同使用，后者与EVPN一起传播B-MAC地址。PE执行PBB功能，例如，对来自于AC的流量进行PBB-VPLS C-MAC学习，以及对来自于核心网的流量进行C-MAC/B-MAC地 址关联。思科公司的OTV提供了EVPN的某些特性，这是思科公司的专有解决方案。

EVPN可以使用多种不同类型的传输LSP（P2P/P2MP/MP2MP）10，它与VPLS相比具有如下分发优势：

10.某些情况下MPLS核心网络可能是有问题的，这时也可以使用IP/GREB隧道连接MES。快速收敛的实现依赖于MES-CE链路失效的局部恢复。然而这种情况下，很明显对于非MPLS核心网络就失去了MPLS快速重新路由对隧道的保护。根据拓扑结构的不同，可能用IP-FRR替换就足够了，这时需要在MES之间的TE隧道上运行LSP。

- 基于流的负载均衡和多路径处理（二、三、四层）以支持多归属设备；

- 多归属网络基于流或VLAN的负载均衡（可以基于自动检测）；

- 使用MP2MP组播分发树进行组播优化；

- PE/网关节点的地理冗余性。

EVPN 引入了一些新的设备概念，图6-16给出了进一步的说明如下。

图6-16：EVPN MAC地址学习模型

- MES-MPLS 边缘交换机；

- MFI-EVPN 转发实例；

- ESI-以太网段标识符（在链路聚合场景中起到重要作用）。

图6-16说明，在EVPN模型中，数据中心内部的本地MAC地址还是通过正常的数据平面学习。MES 也可以通过其他机制（管理平面协议或者像LLDP这样的发现协议来扩展）来学习本地MAC地址，但仍然使用水平分割和其他MAC桥接优化方法，将这些地址发布到其他PE上。EVPN的基本运作还会在MES中生成新地址族表，然后通过BGP更新传播到邻近MES，以发布MAC路由。另外，MES还把BGP学到的MAC地址与相关的邻接信息，插入到二层转发表中。与之前介绍的常见VLAN方法的区别在于，这种实现的扩展性更强。举例来说，WAN边界路由器可以只基于标签转发，其他MES结点可以只为活跃MAC地址创建转发平面。这和不得不让每个终端设备学习来自于所有VLAN的所有MAC地址是不同的。在每个MES后汇集MAC地址，和BGP在网络后面汇集网络地址，并且只发布到这些网络的可达性而不是实际的终端地址相比，是非常类似的，这样的实现是高效的。

除了前面提到的优点，EVPN还尽量减少了可能导致扩展性问题的ARP泛洪。ARP风暴可能很快就会消耗掉大量的交换机转发带宽。为了实现这一点，MES作为代理ARP，代替其所代理的IP地址响应ARP请求，而不再转发ARP消息，除非BGP MAC =路由中包含所请求IP 地址的绑定。

EVPN还通过实现BGP策略改进了MAC地址学习和选择性VLAN分配，类似于通过BGP策略，增强正常IP可达性。EVPN的成员通过路由目标（RT）定义，包括MES和连接CE（比如主机、交换机和路由器）的以太网接口/VLAN。特别是如果EVPN和VLAN之间是一对一映射的，路由目标可以从VLAN ID中自动推导得出。每个MES学习其所在的VPN中所有其他MES的ESI成员。这个过程使得BUM流 量（多归属CE）的转发器选举和水平分割成为可能。

图6-16中的示例说明了EVPN MES可以向同VPN的其他MES成员发布不同的MFI。多数情况这是通过使用路由反射进一步增强解决方案的扩展性来实现的，它同时也利用了BGP的特性比如约束分布、路由反射器、inter-AS。另外在图6-16 中，MES1和MES4都为发布以太网标签（Ethernet Tag）自动发现路由，其中带有MPLS 标签和VPNA RT。举例来说，MES1 在BGP中发布MA 路由：

<RD-1, MAC1, A1-VLAN, A1-ESI ID, MAC lbl L1, VPN A RT>

在这个示例中，MES2通过BGP学习到MAC1是MES1和MES4双归属。即使事实上可能MES4还没有发布MAC1也是这样，因为MES2通过以太网标签自动发现路由得知MES4连接到ESI1和VLAN1。如果MES2要发送分组到MES1，它会使用内层标签和外层封装<LSP到MES1的MPLS标签> 或者<到MES1的IP/GRE隧道的IP/GRE头>。

现在MES2可以安全地在MES1和MES4之间负载均衡到MAC1的流量。

5. DCI的VPLS和EVPN实现方法对比总结

作为总结，作者认为对比最后这两种相似的DCI解决方案是有指导意义的。表6-1中清楚表明EVPN 似乎是DCI的最优解决方案。

表6-1：VPLS和EVPN实现DCI对比总结

扩展属性需求 | VPLS | E-VPN
虚拟机移动不需要新的L2和L3地址 | √ | √
实现跨不同位置机架的VLAN | √ | √
支持单数据中心或多数据中心扩展到上百K主机 | √ | √
与L3 VPN类似的基于策略的灵活L2拓扑 | | √
支持VLAN负载均衡的多点附加 | √ | √
活跃-活跃附加点，支持VLAN内基于流的负载均衡 | | √
多租户支持（安全隔离，MAC地址、IP地址重叠） | √ | √
基于控制平面的学习 | | √
最小化或者消除未知单播泛洪 | | √
基于局部修复的边界失效快速恢复 | | √

6.4　数据中心网络的SDN解决方案

本节将讨论现代数据中心的SDN解决方案。并将特别讨论上文介绍过的现代数据中心如何应用SDN 概念提高服务提供的效率、规模和灵活性。应该注意到SDN解决方案并不一定是标准解决方案，这里介绍的有些解决方案在某种形式上是厂商专有的。

如前所述，传统的数据中心包括存储、计算（也就是服务器）和把两者连接起来的网络技术。服务器和应用程序，还有网络也基本上是按这种方式被虚拟化的。在传统网络部署中，网络虚拟化的途径几乎就只有VLAN。在此意义上，VLAN是虚拟机之间的虚拟化网络路径。这是网络虚拟机的第一步。前面在DCI章节已经介绍过，有多种协议可以用于构建数据中心网络，它们也能用于虚拟化网络。本章将会特别介绍网络叠加的概念，通过它可以对底层网络（或称为承载网络）实现虚拟化。

6.4.1　网络承载层

承载网可能由多种技术实现。一般来说可以分为一层、二层和三层解决方案，但在所有情况下，这些解决方案基本都是设计来实现同一件事情：在数据中心服务器之间传输数据。图6-17中展示了叠加网络如何在物理承载网上创建逻辑网络。叠加网通常使用虚拟网络组件创建，比如虚拟路由器、交换机或者逻辑隧道。承载网络就是通常的网络，比如以太网、MPLS或者IP网络。

图6-17：数据中心叠加网和承载网关系

坦白地说，所有可用的解决方案实现承载叠加网都是可行的。问题在于每种解决方案实现的优化程度，以及承载某种特定叠加技术的能力不同。举例来说，某个解决方案可能对于二层MAC地址学习的扩展性较好，考虑到处理虚拟机迁移或者外部云猝发的时候采用这种方法不错。再例如，某个解决方案可能在响应网络变化的效率方面扩展性较好，另外一种则可能需要更多的时间进行半自动化（甚至手工）操作。下面将深入探讨所有这些方面。

1. VLAN

虽然这一章主要关注SDN新技术，但也不会忘记对于网络操作来说简单就是王道。因此，如果只是内部租户，而且租户数量也不超过1000，VLAN仍然是最简单有效的解决方案。这是一种很常见的方法，容易操作，拥有最广泛的硬件支持，所以形式最简单的叠加网当然就是平坦的IP网络运行在VLAN底层或者承载层。实际上这就是数据中心最初构建的形式。那时还没有对于多租户支持的现实需求，当需要按照部门访问来隔离资源时，出现了VLAN 技术，但叠加层仍是地址空间相对平坦的IP网络。这种方法甚至短时间用于外部用户访问数据中心（想想亚马逊AWS的案例），直到租户数量变得太大因而地址空间必须要叠加，虚拟化网络元素的快速变动需要对这些资源进行快速编程。在这种场景下，基本的IP over Ethernet就足以满足单个租户，并且通过VLAN还可以很容易扩展到支持大约4000个租户。

图6-18说明了如何使用基本VLAN方法实现一个包含IP叠加层的本地数据中心叠加网络，并实现相对简单的数据中心互连。在这个示例中，为应用（应用程序、数据库和管理）创建了三个801.1q VLAN，通过这些VLAN隔离网络数据流量，其中数据中心内部用了一个平坦IP地址空间为这些服务所在的虚拟机提供三层访问。虚拟机到虚拟机管理程序的接口是一个接入接口。虚拟机管理程序把这个接口分配给租户VLAN。服务器到接入交换机接口和交换机之间的接口一样，都是trunk接口。

图6-18：数据中心端对端租户VLAN

尽管VLAN解决方案很容易实现，但众所周知，如果只是简单地依赖桥接或者生成树协议（或其变种），都无法很好地扩展到单个VLAN支持超过300个主机，除非在VLAN之间插入路由。这个协议的问题是，当主机MAC地址数量变大时，网络变动、迁移或者出错都会导致网络组件大量处理操作。在这种负荷很高的时期，网络组件可能会漏掉其他错误，或者在无法做出快速调整处理的时候就干脆进入过载状态。这可能会导致网络环路或者黑洞。早期版本的生成树还被等价（也就是平行路径）链接所困扰，协议只是简单地阻塞了所有到同一个网桥的平行链路，但只保留一条链路，以此来消除环路。即使这些协议的最新版本也只能提供有限的多路径功能。最后，多数情况下网桥在与其他网桥建立连接的时候可能会有几秒钟无法转发数据。

2. EVPN

上文曾把EVPN作为DCI解决方案介绍过，并注意到PE功能终止于数据中心网关或柜顶式交换机ToR 处。上文的示例展示了如何通过VLAN（stacked、tagged或flat）构建承载层。上文还指出，EVPN和VPLS一样可以用于扩展网络租户个数，突破VLAN标签4000个的限制。

图6-19说明在数据中心内如何使用EVPN把数据从一个租户发送到其他租户。通常操作很简单，数据作为MPLS封装的帧来发送，其中包含一个以太网帧。MPLS隧道终止于物理或虚拟交换机，然后数据被解封装作为二层帧发送到虚拟或者物理主机，具体根据实现而定。类似地，从终端设备发送的二层帧也在封装后通过MPLS隧道发送到其他终端主机。这和上文解释过的原理是一样的。

图6-19：EVPN（数据平面）

图6-20展示了控制平面如何在接入交换机和核心交换机之间使用LDP或RSVP建立传输MPLS LSP的全连接。与之前关于DCI的一节中介绍过的一样，接入交换机通过运行MP-IBGP来发送MAC地址学习网络可达性信息。

图6-20：EVPN（控制平面）

对比这种方案与本书介绍过的其他方案的扩展性是很重要的。既然物理网络是三层网络（MPLS），其扩展方式和操作方式和MPLS网络常用方式是一致的。类似地，所有的二层流量都在MPLS之上的网络隧道中传输，这有利于扩展性，因为不需要大量的二层域，并且避免了由此引起的扩展性问题。再来与VxLAN或者NVGRE方法对比，这时需要考虑实际需要创建和维护的隧道数量。因为这种方案可以使用堆叠标签，所以使用的隧道数量一定比VxLAN和NVGRE要少。在这种模式中使用BGP路由反射器，是一种进一步扩展交换机负荷处理规模的方法，这样可以大幅度改进该解决方案。最后，在本地交换机（或虚拟交换机）和MP-IBGP点之间使用XMPP有可能减轻这种架构下终端主机协议配置负荷。

3. 位置标识分离（LISP）

目前互联网的路由和编址架构依赖于同一个命名空间来表达网络组件的两个功能：网络标识以及它是如何连接到这个网络的。问题本质上在于，不管设备如何连接、连接到哪些网络，人们都想要保持设备标识的永久性。在当前编址方案发明的时候，网络组件相对来说是静态的，还假定网络到组件ID的绑定也是相对静态的。而现在则必须要考虑在当前用户的习惯下，移动设备在基站或无线接入网之间快速移动的情况。这使得网络连接、资源和其他应当通过网络组件标识符锁定的属性难以管理，因为网络组件的地址会随其所在网络的改变而改变。进一步来说，如果网络组件是多归属的，就需要采用流量工程（TE）或者通过地址分配策略防止聚合。

两种因素会导致问题加剧。一是IPv4地址空间耗尽，这导致IPv4地址空间的分配越来越精细以减小聚合的可能性。第二个因素是支持IPv4和IPv6协议的双栈路由器越来越多。IPv6在IP地址使用方面没有什么变化，所以还是有和IPv4一样的问题。IETF意识到了这些问题，并想要通过创建一种新的地址与网络元素地址分离的机制来解决这个问题，目前称为位置标识分离（Locator ID Split，LISP）。他们创建了新的网络架构，设计了一套协议以实现IP寻址的新语义。本质上说，LISP创建了两个命名空间，每个网络设备使用两个IP地址。第一个是分配给终端主机的终端标识符（EID），无论这个主机在哪个网络中都始终保持这个IP 地址不变。第二个是为构成整个路由系统的每个网络设备（也就是路由器）分配的路由地址（RLOC）。这些路由器和唯一设备标识，以及在互联网管理它们的协议一起，构成了LISP系统，使其能够运作。

设备标识和网络标识的分离带来了以下几点好处：

- 拓扑聚合RLOC的使用增强了路由系统的扩展性；

- 多归属终端设备的使用改进了流量工程；

- 从通用EID空间为设备分配EID，使得设备独立于厂商，这提供了IP可移植性，这一重要的特性；

- LISP是一种简便的渐进的网络实现，主要在网络边缘设备部署，因此不需要改变主机协议栈、域名服务和其他支持这些主机的本地网络基础设施；

- IP移动性（EID可移动而不需改变——只改变RLOC）。

IETF、各大高校和研究学者已经对位置标识分离的概念研究了超过15年。把设备标识、终端标识和路由位置分离到两个不同的命名空间，通过更大的RLOC聚合能够提高路由系统的扩展性。

LISP提供了高度可扩展的全局流量分段，同时实现对基础设施的冲击最小化，这适用于数据中心。这种方法实际上也能够支持虚拟化/多租户，类似于本节之前讨论的数据中心内VLAN或VPN。通过把VRF映射到LISP实例ID，实现控制平面和数据平面的流量分段，就可以实现。因此这个叠加解决方案具有高度的灵活性和扩展性。这还可能降低运维成本，因为映射过程由数据中心网络交换机自动完成。

这种方案的另一个优点是数据中心虚拟机可移动性为IP终端设备提供了位置灵活性，由于使用了IP协议还可以跨互联网，所以可以不只在数据中心网络内部实现。实际上，采用这种方案，因为和其它LISP实现一样，服务器标识符也就是EID和其位置（RLOC）是分离的，所以虚拟主机可以在数据中心之间自由迁移。因此这种解决方案不管其IP 地址如何，可以把IP终端设备绑定到虚拟机上，并部署到任何地方。另外，跨机架、跨row，跨pds，甚至跨越不同地理位置数据中心的虚拟机迁移也可以实现。采用这种方案还可以实现跨组织架构，支持数据中心的云猝发特性。

4. VxLan

虚拟可扩展局域网（VxLAN）是一种网络虚拟化技术，目标在于改善现有VLAN技术在部署大型云计算时遇到的扩展性问题。作为解决这种环境下问题的方法，VxLAN是由思科公司和VMware公司最早提出的。目前支持这种技术的厂家还有瞻博公司、Arista公司、博通公司（Broadcom）、Citix公司和Red Hat公司。

VxLAN采用了类似于VLAN的封装技术，把基于MAC的二层以太网帧封装到三层UDP分组中。通过这种MAC-in-UDP封装技术，VxLAN为虚拟机（VM）提供了与位置无关的二层抽象，这类似于LISP发明的原因。图6-21说明了VxLAN的分组格式。注意其中内层和外层MAC/IP部分，为这种方案提供了虚拟隧道功能。

图6-21：VxLAN 分组格式

前面已经提到，802.1Q VLAN标识符受限于12位宽度， 也就是大约4000个。VxLAN采用24位标识符，VxLAN ID空间增加了4000多倍， 也就是达到超过1600万个标识符。这应该足以支持未来数年的发展。图6-21中也表明，VxLAN采用IP协议作为VxLAN主机之间的传输协议，对于单播和组播操作都是这样。使用IP作为传输层是很重要的，因为这使得VxLAN网段的可达性远远超过了使用802.1Q的VLAN。

基本说来， 通过允许VM使用物理叠加网络之上的一个透明叠加层彼此通信，VxLAN把VM在物理网络这一层的连接断开了。这些叠加网络也可以跨三层边界以支持intra-DC的情况。VxLAN的一个重要优势是，因为终端看到的只是虚拟的二层邻接关系，所以终端VM完全意识不到物理网络限制。更重要的是，这种技术支持跨传统网络边界的虚拟化，由此支持VM主机可移动性。和VLAN 类似，VxLAN也允许逻辑网络之间彼此隔离来简化真实多租户的实现，同时提供了远超过VLAN 4000限制的更大虚拟化空间。

通常VxLAN的运作依赖于虚拟隧道终端（VTEP），VTEP分组含为终端系统提供二层以太网服务所需的所有功能。VTEP位于网络边缘。通常VTEP把接入交换机连接到IP传输网络。注意这些交换机可以是虚拟或物理交换机。图6-22中给出了VxLAN VTEP的大体配置。

图6-22：VTEP作为虚拟（或物理）交换机的一部分跨过数据中心基础设施连接VM

连接同一个接入交换机的每个终端系统都通过这个接入交换机相互通信以获得其他主机的数据分组。接入交换机的工作方式和传统学习网桥一样。特别是，在不知道接收分组目标MAC 地址的时候，会在除了接收分组的端口之外的所有端口发送泛洪分组，如果已经学习到了转发目标地址就只发送到特定端口。和通常一样，广播流量从所有端口发出，组播也采用类似的操作方式。接入交换机支持多个桥接域，这些桥接域通常在trunk端口用802.1Q头中的VLAN ID标识为一个VLAN。而对于支持VxLAN的交换机，这些桥接域则关联到一个VxLAN ID。

正常操作中，VTEP检查帧中的目标MAC地址，查找目标VTEP的IP地址。MAC到外层IP的映射表通过正常L2网桥学习来填写。一个VM要和其他VM通信时，通常会先发送一个广播ARP分组，VTEP会将其发送到其VNI的多播组。其他所有VTEP从这个分组中学习，发送端VM的内层MAC地址和其VTEP 的外层IP地址。目标VM会给发送方发回一个单播消息来响应ARP，原来的VTEP也可以由此学到目标地址映射。

当一个MAC地址移动到另外一个物理或者虚拟交换机端口时（也就是VM迁移的时候），其他VTEP 通过同样的学习过程发现它的新位置，从新的VTEP发送的第一个分组会触发这个学习动作。

从可编程性的角度看，VxLAN在提供单一接口进行二层逻辑网络叠加编程方面胜出。在虚拟化环境中，VMware 的vSphere DVS、vSwitch和网络I/O控制已经集成了VxLAN来编程控制VM和与之相关的带宽及安全属性。

5. NVGRE

前面介绍选择VLAN作为承载层时，曾提到过的一些问题，可能会影响大型数据中心环境下的扩展性，使用通用路由封装的网络虚拟化（NVGRE）协议就是为解决这个问题而发明的。与VxLAN类似，它采用了隧道发包机制，把二层信息封装在三层分组内。NVGRE使用通用路由封装（GRE）在三层网络中建立二层隧道。在核心层，NVGRE只是在IP分组中封装二层以太网帧。这样就可以创建跨物理三层IP网络的虚拟化二层子网。这个协议的最初规范在IETF 的draft-sridharan-virtualizationnvgre-00。它的主要支持者是微软。

通过NVGRE实现了两个或多个L3网络的连接，使得对于终端主机来说，它们就像在同一个二层子网内一样（如图6-23所示)。与VxLAN类似，这使得跨三层网络的VM间通信对于终端设备来说就像是连接到同一个二层子网一样。NVGRE是三层网络上的一种二层网络叠加机制。

图6-23：NVGRE叠加网络：为云基础设施提供网络扩展性

NVGRE在二层以太网帧中增加一个24位的唯一ID，称为租户网络标识符（TNI）。TNI从GRE Key 字段的低24位映射而来。这个新的TNI可以在同一个管理域内支持超过1600万个L2（逻辑）网络，比上文讨论过的VLAN网段划分4096的限制提高了很多个数量级。然后使用外层IP头再加上外层MAC地址封装GRE封装过的L2帧。图6-24中给出了一个简化的NVGRE帧格式和封装过程说明。

图6-24：NVGRD 分组格式

NVGRE是一种依赖于GRE路由协议的隧道机制，GRE路由协议由RFC 2784定义，RFC2890扩展。每个TNI与单个GRE隧道关联，具有唯一标识，就像其名字所暗示的一样，是一个云租户的唯一虚拟子网。虚拟机管理程序之间使用了已有的GRE协议，因此NVGRE并不是一个新标准，而是对现有协议的修改。因此和运维管理和理解协议的其他特性等方面相比，这种方案是有优势的。

服务器、交换机和物理网卡使用NVGRE协议封装VM流量的过程是很直观的。对于来自于VM的流量，在帧内添加24位的TNI，然后通过合适的GRE隧道发送出去。在终点处，终端设备解封数据分组，然后将原来的二层以太网分组转发到目标VM。

内层IP地址称为客户地址（CA），外层IP地址称为厂商地址（PA）。如果一个NVGRE终端要发送数据分组到目标VM，它就需要知道目标NVGRE终端的PA。

6. OpenFlow

上文已经介绍过几种承载网技术，它们可以松散地映射到现有二层网络协议的多个变种协议。一个例外是使用OpenFlow协议创建和管理承载网络，其上可以叠加，比如IP网络。在第3章和第10章中已经介绍了这个协议的一般运作，这里就不再重复。但解释如何构建这样的承载网还是有必要的，幸运的是，这并不复杂。

图6-25展示了建立OpenFlow控制器来控制一组网络交换机的经典架构。请注意，虽然图片中使用的是BigSwitch Floodlight控制器，但可以把它替换为任何OpenFlow控制器，它们的基本操作都是一样的。图中的交换机通常由控制器完全控制，第3章曾提到过，混合操作模式（实践中）也是可行的。每个交换机拥有一个与控制器相连的运行OpenFlow协议的控制通道。请注意，这些受控交换机在图中表示为虚拟的（vSwitch）或物理的（switch）。坦白地说，这种情况下交换机是物理的还是虚拟的，都无所谓。

图6-25：使用OpenFlow 控制交换机创建二层承载网络

通常由控制器来创建和配置交换机，以在交换机之间建立二层交换路径，在网络的进入点和转出点还包含三层功能来处理ARP等三层操作。应该注意到，使用这种技术还可以构建真正的二层和三层承载层，但普遍认为这样实现的话，对于扩展性、失效恢复和常用操作复杂性等方面过于困难。这些问题已经在第4 章中讨论过了。

6.4.2　叠加网络

前面已经提到，虽然逻辑网络叠加层的概念并非由SDN发明，但很明显，特别是在数据中心网络领域，它已经是当今SDN发展的重要动力之一。本章前面部分已经介绍了网络承载层的概念。总的来说，承载层是目前数据中心网络和其他网络运作所采用的基础设施技术。除了几点例外，比如VxLAN和NGVRE，这些基础技术都被修改或剪裁以支持额外的虚拟化、用户上下文或网络本身的整个虚拟化切片等功能。就和有多种网络承载层一样，也存在很多种网络叠加层。本节将从连接虚拟机的隧道终止位置这个通用概念开始讨论每一种叠加层类型。

1. 终止于vSwitch的隧道

本书第4章介绍了虚拟交换机vSwitch。目前开源社区和商业领域里都有几种虚拟交换机。普遍认为其中最流行的是开放虚拟交换机（Open Virtual Switch，OVS）。本章后文的讨论指的都是OVS。

这类解决方案都是在vSwitch之间建立隧道，以承载其他vSwitch之间的租户流量。通常来说vSwitch运行在虚拟机管理程序空间，所以将其作为VM的本地终止点和转换点。还有一个优势，就是它不需要任何修改就可以加入叠加层（或承载层）。就像在非叠加环境中一样，VM用一个IP 地址和一个MAC地址表示。这类解决方案有两类vSwitch隧道终止方案：单层和多层方案。很多基于标准的解决方案使用前者，后文会详细介绍，这里仅简单描述一下，就是由多个逻辑和物理层构成的网络，这些层次相互连接构成了承载层基础设施，其上是叠加层。图6-26展示了这类方案。图中VM用方框A和B标识。字母表示特定叠加层或VPN的组归属；外层稍大的矩形表示物理主机（服务器）；内部的矩形表示vSwitch。请注意逻辑网络隧道在这一点上是如何起始和终止的。图中的示例与承载网无关。

图6-26：网络叠加，多层网络中隧道终止于vSwitch

另外一种叠加方案是单层方法。通常被称为数据中心交换矩阵（data center fabric），绝大多数是特定于厂商的专有纵向集成解决方案。如图6-27所示，这种方法中，和多层解决方案一样叠加隧道的起始点都在vSwitch中。与多层解决方案的区别在于，这类解决方案通常会在构建逻辑交换网络的vSwitch上建立全网隧道。这可能会简化网络信令发送和操作，因为网络管理员（或其OSS）不需要关心任何具体的隧道信令的发送、移动和维护，这些转而由交换矩阵的管理系统处理，只需要提供到VM的隧道，就像是连接到真实网络上的一样。

图6-27：网络叠加，单层网络（即交换矩阵）中终止于vSwitch的隧道

2. 叠加网络类型

如前所述，网络叠加层模拟不同的网络逻辑层，包括二层和三层，最近还出现了一种紧密结合一层和二层的方法。

二层叠加

可以证明，目前多数承载隧道协议，都是在某种三层网络上封装二层租户网络流量11，尽管这里OpenFlow是一个明显的例外。上文已经介绍过，OpenFlow的常用方法是从整个二层网段中构建一个网络。这里的三层网络通常是IP网络，尽管上文已经看到也可能是OpenFlow、GRE甚至是MPLS，严格地说是2.5层，这里也算是一个。隧道包头的具体格式根据隧道封装机制的不同而有所不同，但基本思想对于所有的封装机制几乎都是一样的12，如图6-28所示。

图6-28：叠加隧道的二层封装

11.在三层租户网络流量之上建立二层隧道的方案被认为是一个独立的变种。
12.如果使用MPLS，就要用MPLS 头替换外层IP 头，隧道头替换为stacked MPLS 头。

对于二层网络的关注最早来自于服务器集群技术13和存储同步系统的需求，还有OSS 网络操作对更自由地绑定IP到VM的需求。这些应用已经不再只局限于二层了，可以看到越来越多的技术正在向三层迁移。

13.比如，Microsoft MSCS、Veritas Cluster Server、Solaris Sun Cluster Enterprise、VMware Cluster、Oracle RAC(Real Appl.Cluster)、HP MC/ServiceGuard、HP NonStop、HP Open VMS/TruCluster、IBM HACMP 和EMS/Legato Automated Availability Manager。

如图6-29所示，所有这些解决方案使用的隧道封装机制，都是在隧道包头中，使用某种形式的租户标识符字段，把从隧道收到的分组，解析到正确的vSwitch网桥上下文中，具体说明如下。

图6-29：在隧道头中使用租户ID 来分发包到正确的租户

- GRE使用32位的GRE key[GRE-KEY-RFC]（32 位）；

- VxLAN使用24位的VxLAN网段ID，也称为VxLAN网络标识符（VNI）；

- NVGRE使用24位虚拟子网ID（VSID），是GRE key的一部分；

- VmWare/Nicera的STT使用64位的Context ID；

- MPLS使用20位的内层标签。

VxLAN 的VNI、NVGRE的VSID以及STT的context ID是跨数据中心的全局作用域；MPLS的内层标签也是在vSwitch的局部作用域。

三层叠加

另外一类网络叠加是三层（IP层）叠加。这类叠加提供基于IP 的叠加而不是二层叠加，与二层叠加的区别在于其对VM之间提供的是三层网络，而不是二层逻辑拓扑。这种方法的优势类似于现在的三层VPN。特别是，可以很容易混合使用私有的或公有的寻址方法，所以云猝发和附加外部云都很容易实现，迁移也更加容易。与二层隧道终止于vSwitch不同，这类解决方案中三层隧道终止于vRouter。vRouter的职责与vSwitch类似，此外它还作为三层VPN中的厂商边缘设备（PE）组件。当前这类方法中最常用的，实际上它是三层MPLS方案的一个变种，它在虚拟机管理程序空间内集成了vRouter。

叠加网-承载网混合方法

还有一种方法来自于一家初创公司Plexxi，不同于上文介绍的严格二层或三层方案。这是一种承载层解决方案，但同时也提供了一个紧密集成的叠加层（如图6-30）。作者把这种方法称为混合叠加-承载层（hybrid overlay-underlay）。对于叠加层来说，网络管理者还是必须要清楚意识到网络的负担能力，因为这是一种有限资源。而叠加层对网络是完全无知的，正如整个叠加层管理员所认为的，具有无限带宽支持。在传统网络设计中，包括骨干/叶结点（spine/leaf）设计，网络容量是静态的。研究表明这种网络中多数的容量都是被浪费掉的。Plexxi的方法是把数据中心网络缩减一层，通过光环网连接这一层中的交换机。因此这种解决方案减少了设备数量， 减少了连线数量和收发器数量。再加上动态维护的关联度（affinity），这意味着应用程序可以在需要时获得资源，而不需要提前购买未使用的资源。

图6-30：Plexxi 的承载层叠加层混合方案

这种解决方案中叠加层被表示为亲和度（affinity），即使终端设备掩藏在叠加层后，网络容量也是动态管理的。因为所需数据通过一个连接器从叠加层管理系统中获得，然后这个连接器把数据通过Plexxi API传入Plexxi控制器，所以这是可以实现的，第4章中已经介绍过Plexxi控制器，这里就不再赘述。

6.5　小结

本章展示了用于创建、运行、维护和管理现代多租户数据中心的概念和结构。其中有些只是既有概念的一个变种，另一些则是在SDN发展过程中出现的全新概念。这些解决方案都为虚拟机通信提供了虚拟化网络访问，这些网络访问对于同一个运营商的数据中心上的其他租户虚拟机都是保密的。在某些案例中，这些技术还可以用来帮助实现跨多个运营商数据中心的虚拟机通信。在另外一些案例中，前述技术实现的逻辑网络，可以跨同一个企业甚至多个企业运维的多个数据中心。本书后面章节会继续讨论在实现数据中心的设计中重叠使用多种技术带来的影响。

第7章　网络功能虚拟化

7.1　引言

网络功能虚拟化（Network Function Virtualization，NFV）建立在前面介绍过的几个SDN关键议题之上，这些议题包括控制/ 数据平面分离、虚拟化、SDN控制器和数据中心概念（特别是编排应用）。图7-1说明了这些主题的关联。

图7-1：使得网络功能虚拟化成为可能的交集

网络功能虚拟化源于前面介绍过的几个网络运维问题，特别是网络设备厂商在其平台操作系统上捆绑服务带来的影响。NFV也适用于设备厂商，其运作方式不需要利用许多客户在数据中心看到的那些处理规模和创新技术。

许多大型运营商都有自己的云，因此可以假定其运作也需要自己的虚拟机编排。他们也在紧跟Intel在这个领域的I/O创新（VT-d，DDIO、DPDK 和SR-IOV 支持）。根据在2012年秋季123层SDN大会（Layer123 SDN Conference，德国达姆施塔特）上的报告1，这些厂商正式表明他们对服务虚拟化的渴望，并倡议围绕服务虚拟化制定标准。这项工作最终在ETSI2的赞助下完成了。除了这份报告之外，运营商也不断在用钱包反复投票，朝着支持商品化、ODM制造、附带现成软件的顶级交换机迈进。厂商也已经在幕后追踪COTS平台I/O性能的发展，并评估包括宽带网络网关（Broadband Network Gateway，BNG)、它在线缆一层的对应物（CMTS）、移动领域的node-B，以及其他面向服务的接入平台和汇聚平台在内的下一代服务设备策略，以及由大量服务组件构成的专有网络平台的未来。

1.http://www.tid.es/es/Documents/NFV_White_PaperV2.pdf;http://www.lightreading.com/document.asp?doc_id=226204&
2.ETSI是一个标准制定组织（Standards Development Organization，SDO）。要深入了解NFV工作内容需要ETSI成员资格。

关于网络服务和功能的讨论逐步发展成三大类：简单虚拟服务、服务链和服务或平台虚拟化。所有这些讨论中，都涉及SDN控制器，至少简单虚拟服务中有少量涉及，另外两类按理说也需要它。

7.2　虚拟化与数据平面I/O

网络服务虚拟化不一定就是包含每个服务实例的独立虚拟机管理程序分区虚拟机，它还可能是：

- 在一台带有多个操作系统或分区操作系统的机器上实现的服务；

- 在虚拟机管理程序中实现的服务；
- 实现为分布式或集群组合的服务；
- 在物理机上运行的服务；

- 在Linux虚拟容器（virtual container）上实现的服务。

上述方案可以通过某种形式的网络附加存储（NAS）或其他存储/内存共享架构来共享状态。图7-2中展示这些方案的简图。

图7-2：虚拟化方法纵览：（A）虚拟机管理程序分区，（B）操作系统划分，（C）物理机，（D）虚拟机管理程序嵌入，（E）分布式/集群组件功能，其中A和B两种方法通过共享存储实现状态共享

从管理的角度说虚拟机具有巨大的优势3，因此成为NFV的首选工具。Linux容器在密度（每个主机容纳更多的实例）和性能上有优势，但缺乏管理生态系统和虚拟机的操作系统灵活性。当然从性能的角度来说，裸物理机优于前两种方案，但是从灵活性和可管理性的角度来说，则是十分落后的。

3.这里是管理优势的简要列表（如果读者跳过了第6章的话，可以参考该表）：VM生存期管理、存储管理、VM放置优化、VM快照、VM迁移、灾难恢复、性能监测、规范化管理和容量管理。

在使用内建或附加服务的交换机/ 路由器环境下， 通过虚拟以太网端口扩展（Virtual Ethernet Port Extension，VEPA）等端口扩展技术，还可能实现特定于虚拟机的（per-VM）服务。

网络服务虚拟化也带来了可靠性的问题，这些都是NFV实践和推荐需要考虑的。

- 虚拟机管理程序的引入，以及在同一物理硬件上运行多个虚拟服务，都可能导致物理资源竞争，可能导致单个服务/功能或通过这个组件的整条服务链性能下降。NFV编排系统不仅要监测这种性能下降，它还需要观察虚拟机管理程序和主机资源状况来分析问题所在，以隔离或缓解竞争状态。

- 虚拟机管理程序自身引入了潜在的单点失效（SPOF）问题，会影响主机上的多个并发虚拟机，进而可能影响许多服务链。

- 服务于多个虚拟机的多个虚拟网卡时，虚拟机管理程序的虚拟交换机可能出现拥塞，需要识别并优先考虑控制流量，以避免应用和管理出错。

- 另外，虚拟机管理程序可能会使应用程序感知不到网口出错等物理机状态的变化。这种管理上的状态感知需要通过SDN 控制器和编排层合作实现。

- 最后，虚拟机作为高可用性（HA）策略的一部分，在实现时也可能发生迁移。这种行为可能会对服务链造成多方面的影响，所有只有在用于提供HA能力时，才会被有意无意地作为策略实现的一部分。

7.2.1　数据平面I/O

一般说来，数据平面I/O的发展是能够在COTS硬件上运行服务的关键要素。因为NFV/服务虚拟化方案使用的虚拟机管理程序的虚拟交换机为I/O增加了性能开销，虚拟化/抽象不是没有代价的，已经出现了损失补偿的软硬件策略。I/O加速是基于软件（操作系统或者虚拟机管理程序）的技术，包括Virtio和SR-IOV。

- Virtio是Linux、FreeBSD等操作系统中主要的磁盘和网络I/O虚拟化平台。Virtio 在准虚拟化（para-virtualization）4虚拟机管理程序/VMM设备之上提供了一个抽象层，在I/O方面优于完全虚拟化。

4.准虚拟化通过为关键任务提供钩子进行客户系统和主机操作之间的交互，从而支持把这些任务的执行从虚拟域重新分配到主机域。Xen、VMware（外部）和KVM（虚拟机管理程序）都使用Virtio实现准虚拟化。

- SR-IOV（PCI-SIG 单根I/O 虚拟化，PCI-SIG Single Root I/O Virtualization）与 围绕PCIe技术的一类硬件厂家合作。PCIe标准把设备分解为多个PCI ExpressRequester ID（把物理功能分割为更轻量级的虚拟功能），使I/O MMU能够区分单个数据流，应用内存/中断转换，直接发送到虚拟机（每个PCIe虚拟功能，映射为一个ID，可以分配到一台虚拟机）。这样就绕过了软件交换机这一层，从而减少了对I/O的软件模拟带来的性能冲击。物理设备到虚拟设备的映射率是1∶256。

PCIE虚拟功能对于虚拟机来说是硬件设备。所有的数据分组直接在特定客户操作系统和虚拟功能之间通过独立的内存空间、中断和DMA流发送。因此I/O吞吐率、CPU使用率和延迟都有所改进。SR-IOV需要硬件（网卡）和软件的共同支持，在BIOS和操作系统实例中或虚拟机管理程序中实现。

依赖特定厂商的硬件I/O增强技术（网卡和CPU）还可以实现进一步的I/O加速。

Intel为开发者提供了一系列I/O性能加速支持，与其（基于Intel架构的）CPU和网卡的性能共同发展，包括以下方面：

- 纯粹硬件设计改进，流水线深度、直接缓存访问、内存控制器集成，以及高带宽第三代PCIe集成5。

5.这里简要地介绍一下其AVX扩展：基于以前的128位SIMD（增强版SSEx）和64 位SIMD（MMX）ISA扩展的256位指令集架构（ISA）；GCC 4.6、Linux内核2.6.30和Intel C++编译器12.1支持这项扩展。

- Intel虚拟化技术（Intel VT）——VTx，VTc 和VTd。

- VT-x为虚拟机迁移和32位客户系统提供CPU级硬件辅助（VMware、微软、Xen、KVM、Citrix、Red Hat、Novell 和Parallels的产品都支持）。

- VT-d通过实现直接向VM 分配I/O设备来加速I/O虚拟化（在OEM平台上需要BIOS支持，还需要大量虚拟机管理程序/VMM支持）。

- VT-c硬件辅助Intel以太网为网络和存储设备连接提供辅助支持，包括VMDq和SR-IOV。虚拟机设备队列（Virtual Machine Device Queue，VMDq）是指通过多个队列对网络分组使用LAN silicon而不是VMM进行排序/分组。

- Intel QuickAssist技术使中间件能加速包处理工作（比如DPI、加密等）。应用程序可以进行不同程度的集成：可以使用Intel QuickAssist 技术API 编程，也可以以开源框架（比如，OpenSSL libcrypto，Linux 内核的crypto API：scatterlist和zlib）补丁的形式。

- 商业集成合作伙伴（比如6Wind6和Wind River7）提供的调度和其他增强，通过特定的封装技术为数据分组I/O分配处理器核（比如Wind River的Linux版本和Wind River Hypervisor）。

6.6Wind 为支持其数据平面I/O 增强的Intel 主机提供了一系列vEPC 产品。
7.Intel 已经收购了Wind River。

- Intel Data Direct I/O技术（Intel DDIO8）：利用CPU集成的PCIe通道降低内存访问率，加速CPU数据传输，有时被称为NIC core pinning（网卡核锁定）。

8.与Sandy Bridge CPU和Intel以太网PCIe I/O设备一同引入。

- Intel DPDK9：Intel在I/O虚拟化改进方面的最近创新， 数据平面开发套件（Dataplane Development Kit，图7-3），提供数据平面库和优化的（轮询模式）Linux用户空间网卡驱动（支持Intel 网卡），通过简洁的API提供先进的队列管理、缓存管理和流量分组（通过标准工具链——gcc/icc、gdb和分析工具提供支持）。

图7-3：Intel DPDK

9.Intel已经为公共域ovswitch开发了一个DPDK增强版本，支持主要的虚拟化产品（KVM、Xen、UML 和xVM）。

（除Intel 之外的）网卡厂商也有自己的I/O加速技术。

- RoCE（RDMA over Converged Ethernet，基于融合以太网的RDMA）可能是虚拟化网络功能（一种I/O虚拟化技术）间集群计算API的有效应用10。Mellanox是RoCE技术及其应用于NFV的主要支持者。它们的网卡加速了RoCE支持的发展，提供用户空间动态链接库，通过允许应用程序直接访问网卡，降低CPU网络分组处理的负担11。

10.RDMA可能出现在Infiniband网络中，在数据中心环境之外较少出现。
11.RoCE的可行性需要DCB（Data Center Bridging，数据中心桥接）环境下某些属性的支持，这种环境下各个数据流的不同优先级可以被当作分离的流水线，从而降低或控制延迟。这种环境下，RDMA提供以太网广播域范围内的远程内存访问API（Berkeley Socket API的替代）功能（RoCE是链路层协议，需要实现其GID到MAC地址的某种映射）。

- 类似地，其他特定的虚拟化应用程序加速技术（比如PCoIP：Teradic提供针对PCoIP优化的网卡）也能在NFV虚拟服务领域找到自己的用武之地12。

12.PCoIP还没有作为NFV虚拟化策略提出（到目前为止），只是用于说明NFV领域数据平面优化的一种可能性。

（直接的）数据平面I/O和数据平面处理（比如在虚拟路由器或者网桥上应用访问控制或执行数据分组转换）之间的区别可能会影响虚拟化功能/解决方案的效率。路由/交换技术的发展历史上曾出现过大量这种操作降低吞吐量的事例（随着时间的发展，也出现了成功优化的事里）。

7.2.2　I/O小结

这里已经给出了不少细节，但其实还有同样多的审视和努力都用于降低中断频率、上下文切换和缓存复制（零拷贝策略）次数。这些需求主要来自于虚拟化服务开发的激增，由于其固有的I/O组件组成部分，以及提高整体性能和规模的需求，所以这些努力也是非常必要的。就像前面描述的那样，除非演进出某个明显的实际硬件标准，否则未来NFV最重要的目标就是寻找开放程度能为社区所接受的优化方法（也就是不依靠某个厂商的硬件技术）。

7.3　服务工程路径（Service Engineered Path）

2010年，当时在瞻博公司CTO办公室任首席架构师一职的Jim Guichard提出了一项分离服务平面与网络基础设施平面的提案。首次引入了服务工程路径（SEP）概念（如图7-4所示），作为运营商社区进行服务交付的新方法：这是瞻博公司的专有解决方案，同其他与这个概念相关的标准相比，这个方案最早解决了这个问题。

图7-4：基本SEP概念

SEP关注的问题是运营商不提供新服务时，需要部署服务设备（或者专用刀片服务器），这一点造成了很大的限制。提供的服务包括防火墙、入侵检测系统（IDS）、入侵防御系统、负载均衡器和SSL卸载机，运行在为其目标市场服务的边缘路由器中。

这些限制使得服务引入的网络操作繁琐而又混乱，并增加了预测服务市场的重要性，因为订阅用户太少会造成资源浪费，而订阅者太多又可能需要安装更多的设备/ 刀片服务器。

以下几个因素推动了这个想法。

- SET（Service Enabling Technologies，提供服务支撑技术）的网络设备对于通用网络基础设施来说将会是透明的。

- 修改/添加/升级一个或多个服务实例不会影响网络路由，由此提供更稳定的服务引入环境。

- 提供灵活的服务SET和实例放置方案，以及合理的服务容量计划。

- 从设计、升级、测试到部署的角度缩短服务上市周期。

- 不再需要每次添加新服务或升级新功能都升级边缘路由器。

- 提供连接不同类型服务的能力，由此可以提供创新的服务组合。

基本上，如果SET池能够放在本地或远程，从成本和运营的角度来说对厂商都是有利的（和数据中心中主机虚拟化的好处是一样的）。

在边缘标识流分片，然后通过SEP（服务工程路径）控制这些流分片，通过这些SET就可以创建新服务，SEP可以通过目前可用的叠加技术构建：VLAN、MPLS或者IP隧道。

服务是由以下组件构成的层级结构。

- 服务
一个服务功能、应用或内容，单独或与其他SET组合，就构成了服务。

- SET序列
预先定义好的形成服务的SET序列。

- Set序列路径
一个SET的实例可以出现在网络中的多个位置，所以构成SET序列的服务结点组合可能有几种。SET 序列路径是形如[ 服务节点，SET]组合的可用组合列表，可用于实现服务。

预先提供了服务编排和注册服务，用于服务开通和和日常管理。

最初使用动态服务流过滤器（Dynamic Service Flow Filter）标识和控制流量进入路径，路径本身通过MPLS封装进行控制。

随着时间的发展，出现了SDN技术，尤其是PCE和OpenFlow（如图7-5所示）。虽然通过LDP标签分发来创建叠加层抽象/封装这个概念还有一些草率，但是这个思路还是被进一步优化了。

图7-5：发展后包含OpenFlow、ALTO（拓扑）和PCE的SEP概念

SEP概念出现时，虚拟化技术和虚拟I/O增强在SEP概念中才刚刚起步，所以和现在的ETSI NVF 不同，COTS上的服务平面大规模虚拟化并不是提案的完整组成部分。然而，分离服务平面、网络功能虚拟化和服务链这些想法的起源可以追溯到这个概念（一些产品也是如此）。

最终（也很可惜）网络功能虚拟化这个术语覆盖了这些早期概念，包括随SEP（以及ETSI工作组这个名字）引入的那些概念。

7.4　服务位置与服务链

即使是运营商对其边缘/接入部署的长期目标，服务链概念也不应该假定服务网元设备位于数据中心中（或所有服务网元设备都是虚拟化的）13。

13.很多运营商已经有了自己的分布式数据中心来支持移动设备（基础设施）或视频缓存（在主要的中心城市或中心区域）。

服务可能天生就与网络边界有关，比如，通过在网络边界上附加一个安全策略或者在网络边界插入一个负载均衡器来实现。如图7-6所示，网络边界可能是指：

图7-6：位于网络边界的服务

- 租户网络和外部网络（互联网或者企业网络VPN）的边界；

- 不同租户网络之间的边界；

- 同一租户多个网络之间的边界。

最后，服务可以通过颗粒度更细的方式部署，附加在单个流或一组流（也就是聚合流）上，如图7-7所示。这是云服务运营商和在边缘/接入网络域提供特定预订者服务的运营商所感兴趣的主要模式。

图7-7：流服务

在数据流上应用服务涉及到以下几个步骤。

1. 确定实现服务需要的网元设备及其顺序和配置。这包括服务网元设备的位置限制。

2. 识别和控制数据流来访问服务结点或服务节点序列。

3. 厂商已经开始为他们实现服务链接的方法打上自己的标签。以思科公司为例，称为vPath（虚拟路径），对于瞻博公司来说，称为服务工程路径（SEP）。

4. 控制平面发送信号给服务结点，通知它们需要把哪些服务应用到哪些流上，包括服务参数。 5.后面将会看到，对服务节点的最初位置或额外服务实例的放置还可以进行优化，以缓和性能瓶颈。

所有这些任务都适合于SDN控制器来执行。SDN控制器具备域/网络宽度的拓扑视角，与编排系统的连接（API），以及管理网络叠加层的能力（也就是可用于匹配和管理流量的抽象能力）。

对于数据中心内服务链接来说，使用SDN控制器似乎是显而易见的结论，但是在边缘/接入层（其中在同一位置添加控制器增加的开销可能是不可接受的，但同时代理/控制器之间的交互延迟也可能会造成问题）则没有那么显然了。这又带回到嵌入式控制器的思路，如图7-8所示（最初是一些研究中将其作为对控制反馈环的一种优化手段提出来的，这些研究是关于OpenFlow控制网络中“老鼠与大象”数据流识别和转发表大小管理的）。其中数据平面网元设备终止于位于边缘的环形，作为主控制器的从子控制器进行内部处理，然后主控制器再与编排应用连接，只提供状态/规则和配置更新。

图7-8：对于网络中的非数据中心区域，在网元设备中嵌入SDN控制处理可能是恰当的

在混合环境中（也就是说虚拟化的服务网元设备和遗留下来的服务组件并存），或者完全在遗留下来的环境中，网元设备可能不支持某些SDN叠加层中使用的隧道封装，或者某个与SDN控制器能很好配合的本地代理。因此创建服务链可需要混合使用VLAN和隧道封装技术，以及一个或多个控制器和网元设备之间的配置/控制协议。

7.4.1　元数据

关于叠加层封装和用于创建服务链/路径的流量匹配协议的标准化，还有一些有待解决的问题。考虑到是否需要在数据流中植入某种形式的元数据，就会得问题变得更加复杂。

对后面这个问题的考虑来自于两个因素：一是目前集成系统内部使用元数据在模块之间传递信息，其中的服务应用如何设计；二是服务功能的部分分解和虚拟化（如图7-13所示）的可能性（正如ETSI NFV工作组的设想）。

是否需要元数据？这个问题的答案依赖于控制器及其服务链接应用的角色范围，特别是它们是否负责创建不具备任何跨组件知识的服务链。还可能依赖于虚拟化设想是否限制了对同一个虚拟设备或设备组合的功能分解，从而隔断了使用某种支持从外部链/叠加层嵌入内部元数据的IPC机制的内部链。

由于无法从数据流包头中提取到上下文信息，因此需要元数据。最常见的示例是在视频流（其中嵌入了反映地理位置、兴趣点和其他触发广告插入的进一步线索）中特定于订阅者的广告插入。

如果需要在NFV功能模块之间传递元数据，并且元数据是数据流关联对数据分组关联，在整个架构中可以有一个元数据接入点（Metaata Access Point，MAP）的角色。像IF-MAP14这样的现有标准提供了服务器/协议解决方案来创建和分发元数据，但还需要集成到服务链构建过程中的流建立或SDN控制阶段。

14.http://www.trustedcomputinggroup.org/resources/tnc_ifmap_binding_for_soap_specification

元数据既可以是隐式的（比如与MPLS标签关联）也可以是显式的。元数据嵌入的一种显式替代可能是扩展数据分组来实现元数据从一个链成员到另一个的传递，这几乎必然需要标准化才能促成一个开放环境，同时还得考虑对于现存网络基础设施增加，这样的扩展流如何实现透明性。

7.4.2　一种应用层方法

如果人们一直试图在错误的层次上解决NFV服务链接的问题，那会怎样呢？人们是否应该寻求基于应用的协议而不是基于网络构建的解决方案？网络构建视角需要使用隧道机制，因为需要覆盖数据流本身的路由（也就是说并不是基于目标地址转发）。这个视角假定在控制器的协助下，可以操纵网络协议来转发数据流并管理元数据。

而从应用程序构建的角度（如图7-9所示）来看，数据流是作为应用程序的输入输出。应用程序（使用分立的套接字）运行在具有可解析域名的服务器（DNS）上。服务实例名到IP地址的绑定标识了服务于一组服务组件的负载均衡器（或者一组ADC/负载均衡功能的泛播地址——负载均衡器的假定是很常见的），这些组件可能有多个输入输出端口，代表了不同的应用程序特性（也就是不同的配置和行为方式）。双向数据流使用两个特性。

图7-9：应用程序层的服务链接方案，利用了优化栈与虚拟设备通信，可以为某些使用共享内存来通信（一种优化方案）的虚拟网络服务提供运行时环境

服务路径指定了每个服务内部服务端口到外部传输端口的映射，以及传输端口之间的连接性15。服务路径从数据模型生成，数据模型表达了服务组件、服务和服务路径之间的关系，并且从管理系统向服务实例传播/应用（通过还未确定的API）。更明确地说，这个模型表达了服务功能之间的关系，内部端口/套接字和外部端口之间的映射，扩展行/约束和负载均衡等比较通用的属性，以及如何连接这些功能来创建服务。

15.这并不是从内部映射到外部映射的详细描述。

在设想和探索阶段，如果链（也就是隧道）的数量是压倒性的指标，这种通过一系列以常见应用程序为主的技术（比如DNS 和ADC/LB）加上一些新的应用管理技术（比如控制器及其API）构成的服务链接方法可能令人吸引的。一个改进思路是，如果服务链上的应用交互混合使用了外部协议和内部IPC的话，同一个设备上的功能性组件可以使用共享内存这种IPC机制来提高性能。

7.4.3　规模

即使SDN现状已经使得网络搭建越来越轻松，即使它已经是能够试验和构建的实体，由于规模和复杂度关系到了应用级方案的开发，所以无法忽视关于规模和复杂度的考量。

复杂性讨论主要围绕着服务结点的放置和可能限制服务路径的约束（如图7-10所示）。

图7-10：服务链接复杂度能达到什么程度？负载均衡和高可用性需要在服务结点之间建立很多隧道。弹性和动态路径可能需要大量的隧道创建和删除操作

- 有多少个链，以及服务链路径选择有哪些限制（比如，发送服务的整体延迟、管理边界、收费）？

- 这些限制如何影响服务的高可用性（HA）策略（比如，如果单个SET的放置导致网络中出现trombone流，是否还要将其增加到链中，还是要把这个流失效转移到新的链中）？

- 服务链拓扑结构改变的频率是怎样的？链中网元设备的加载需要多大的动态性/弹性？

- 最小化网络瓶颈出现概率但增加服务流整体延迟的服务放置算法是否值得？

- 策略在服务链中作为决策/分支点嵌入在链中，或者表达为多个不同的链拓扑时，起到什么作用？什么时候应该把数据分组发送到远程in-line 服务（或者说不是一个代理）？

复杂性讨论中原生规模也是一个因素。

- 预订者/会话数量。

- 会话/流的长度/持续时间，以及包长的分布状况。

- 数据分组吞吐量预期值，链整体和每个网元设备（比如负载均衡器）的容量。

给定可能的规模需求和总体服务约束，虚拟服务功能的放置和得到的服务链很可能具有高度的局部性。链中路径分散度最高的位置可能出现在边缘/接入域设备和一个集中式COTS资源库（数据中心）——具有一个同样的资源库作为失效备份——的连接上。

7.5　ETSI NFV

欧洲电信标准化协会（ETSI）中的NFV活动致力于解决关于服务虚拟化的各种问题。NFV部分在ETSI中以一个工业规范工作组（ISG）的形式存在。NFV工作组（如图7-11 所示）并不制定标准。他们的目标是定义需求，确定最佳实现，确定当前标准之间的空白，对于如何填补这些空白提出自己的建议。NFV 由组织主体、技术指导委员会（TSC）和几个关注特定领域的子组织构成。设备厂商也受邀参与讨论，但从组织设计上来说，NFV 官方成员主要是运营商16。尽管早期文档已经定义了所有工作组的接口和角色，而在撰写本书时，不是每个工作组都提交了意见书。

图7-11：ETSI NFV工作组组织/结构图。MANO和INF都与NFV SWA有接口，彼此之间也有接口。跨功能的工作组（PER、REL 和SEC）还没有确定与MANO、INF和SWA之间的接口，但与这些模块一起工作。NFV SWA还参与了与旧有OSS/BSS系统的接口（图中没有显示）

16.根据目前的在线列表，在所有子工组作中，只有华为技术（UK）、惠普和NEC（欧洲）具有“正式”资格。

管理与编排工作组（MANO）定义了用于服务开通、配置和运作虚拟网络功能（VNF）的框架——本质上是定义了一个编排器来控制所有VNF。MANO 编排器既有应用程序（北向）接口也有网元设备（南向）接口。南向接口是由另一个工作组（基础设施组）定义的，北向接口为VNF 提供整个生命周期的服务（生成、操作和监测）、指定策略（通过控制）、基础设施监测（是某种pass-through 功能）以及注册/拓扑功能。

可能需要为传统的OAM&P模型添加新的管理工具来处理虚拟化网络服务（前面已经指出这一点，SDN控制器可能作为新的管理实体单独部署），MANO强化了这一概念。在MANO中，这是作为NFV 编排器（NFVO）提出来的，它与旧有的OSS/BSS接口。

还需要考察，这是否意味着过去通过SDN控制器/代理机制收集的多数管理信息，现在或者通过应用程序接口表示，或者通过SDN控制器级的与旧有OSS/BSS交互的固有接口表示。在DC编排器的例子中，MANO编排平台可以与云管理系统合作，后者在某些NFV 文档中逻辑上显示在MANO编排层的下方。

MANO的部分工作是为各种任务/接口定义数据模型（Yang，TMN）并提供开放API。这项工作包括云和网络模型（与NFV INF合作），通过网络模型可以为虚拟基础设施创建宏管理应用。（管理应用是管理程序的管理程序？）

编排功能中的某处应该能够把功能点映射到需求，潜在地提供包括API和虚拟化组件在内的服务拓扑结构。SDN控制器需要管理拓扑和终端的映射关系。

基础设施工作组（NFV INF）为NFV定义通用的基础设施。它的目标既包括软件也包括硬件，如图7-12所示。这个工作组在编写文档方面非常活跃，已经建立了NFV架构中大约14类跨域接口。他们负责推荐高效I/O和最小化上下文切换的虚拟机管理程序级架构，以及MANO部分介绍过的数据模型。

图7-12：ETSI MANO、INF和SWA工作组之间的交互（SWA视角，包括内部的功能组）

关于这个领域的常用I/O 优化策略哪种最适合NFV（比如，DPDK 对比SR-IOV）的性能提高，已经有了深入的讨论。这个问题依赖于提出的可靠性与可用性架构，因为后者可能包括VM-motion 这个可能妨碍SR-IOV 优化策略的概念。讨论已经确定SR-IOV 对于VM-motion 的友好性更差一些17。

17.目前一切还不能下定论，这里讨论这个示例的目的，更多的是为了指出NFV子组织之间的依赖性。根据NFV PER测试的结果，可能还有更多依赖关系。

软件架构工作组（NFV SWA）定义了用例、解决方案的组织形式以及如何分解为功能单元。

关于一般意义上的NFV的一个有意思的问题是，哪些服务可以被虚拟化，如何虚拟化。可能的解决方案有一个谱系，从作为单个虚拟机运行的完全虚拟服务，到具有多个组成部分（多个功能子单元构成的服务）的完全虚拟服务，再到需要直接运行在物理机上的服务。注意，从运作的角度来说，后者也仍然可能得利于编排系统。

NFV SWA确信虚拟功能应该能够与INF 直接交互或者通过MANO间接交互来表达运作需求（比如，计算、存储、安全、QoS、内存资源）和支持需求（比如监控、测量和记账）。

- 他们的控制信号处理功能组，致力于认证/授权、策略、状态管理、移动性、移动性相关的支持功能，包括呼叫记录收集和合法拦截。

- 用户数据处理功能组致力于包转发、复制、计数、处理、负载均衡和应用层转向控制（也就是代理）。

- 数据与存储功能组致力于数据存储和管理。

在SWA中，NFV建立在SET（在NFV 中现在称为VNF）的SEP概念之上，因为SET或服务功能可以被分解为组件部分或功能单元（假定SET由多个功能单元构成，比如信号处理、传输管理和内容处理）。

如果分解成了多个功能单元，这些单元就可以以多种形式运行。因此还需要对这些单元的关系和通信、运作特性和约束（比如拓扑结构）进行描述。

这些功能描述符类似于附加在SDN应用程序上的策略，向SDN控制器表达这些策略或称施加策略于SDN控制器。这样的策略为每个应用程序指定了路由、安全、性能、QoS、地域防护、访问控制、一致性、可用性/容灾恢复和其他运作预期/参数。

SWA非常重要的一个任务是以允许flow-through配置的方式定义描述符。也就是说，编排系统和SDN控制器可以在网络功能放置、路径确定和实例化上合作，它们各自的和组合的配置可能非常复杂，目前通常是厂商自定义的。

开放虚拟格式(OVF，目前是虚拟机打包的实际标准）能够表达当前的某些配置元数据，但是还不足以满足未来可能出现的服务的配置复杂性，因此还需要扩展。

目标是让管理员分离已经实例化的配置实体时不需要退出，避免再次接触构成单个或复合服务的机器集合。

一个例子是演进分组核心网（EPC）应用（通用地），它可以分解为以下功能：策略/规则集合处理、用户/会话状态管理、3层包处理，7层流量控制功能等。图7-13中演示了这个功能分解状态。

图7-13：功能分解。如果一个服务（比如EPC）是虚拟化的，那么它的所有子组件是运行在同一虚拟机上、同一主机上的分立虚拟机上，还是作为同一逻辑域内（比如数据中心）不同主机上的独立虚拟机运行，或作为多个逻辑域（比如数据中心和聚合）内不同主机上的分立虚拟机运行呢

- 安全（NVF SEC）工作组
定义如何保护基础设施和虚拟化服务功能（包括API）。还包括身份认证、身份管理，监测、检测和缓和威胁。

- 性能与规模（NFC PER）工作组
这是不言而喻的。这个工作组试图定义提供优化性能的实现，描述性能/规模/可移植性权衡，提供性能测试数据（几个运营商已经提出了多个测试，包括测试多个厂商的网卡和多种I/O机制的使用对性能的冲击）。

- 可靠性与可用性（NFV REL）工作组
定义确保可靠性和可用性的部署和管理实践。目前他们已经定义了一些有用的术语来表达对应用程序的需求和约束：延迟/流量/分裂/容错性、性能（比如QoS 需求）、安全（不可否认性、保密性、授权等），以及依赖性/可靠性。

这个工作组还涉及在非虚拟化解决方案中也存在的几个有趣的问题，包括链内失效（链中一个网元设备或功能失效）及其可能涉及的应用，避免单点失效（比如虚拟机管理程序），子组件之间的心跳机制需求，（软硬件）看门狗（watchdog）模拟。

NFV REL还处理虚拟化环境中可能出现的几个问题，这些是需要为运营级部署解决的问题（参见7.2 节）。

除了SWA之外，还有几个工作组也会制定用例文档。网络运维委员会（Network Operations Council，NOC）定义用例，INF 组也提供了说明性的用例。这包括具体技术（比如WAN 优化、防火墙、路由器、IPTV head-end、DPI、家用网关/CPE、移动基站和移动封包核心网）和更通用的服务描述（比如功能的部分分解、专用硬件的使用，VNF之间nd共享计算），只要能想到的都可以制定用例。

7.6　非ETSI NFV

ETSI工作组的存在并不意味着这是服务虚拟化研究和标准制定的唯一所在，也不意 味着服务虚拟化产品还没有上市。事实远不是这样，举例来说：

- 作为生机勃勃的SDN 研究的一部分，学术界已经开始研究围绕着NFV的一些议题；

- 很多现存的控制器/ 框架厂商已经准备把服务链接作为他们的应用程序之一，还有几个初创公司（比如LineRate、Embrane）正在分析2层到7层控制器的市场定位，以及这些控制器与他们自身的虚拟化服务协作。

- 现有的高度集成网元设备厂商正在考虑把它们的平台/ 解决方案中间件化或者完 全虚拟化。

- 尽管在这个版本中下定论还为时尚早，但IETF已经开始征求服务链领域的意见。一个工作组（网络服务链工作组，NSC）正在其BoF（birds of a feather）18阶段收集草案。包括确定表达服务上下文和元数据，以及满足标准化通用服务控制平面需求的草案。

18.目前此BOF（IETF87 上提出）提案和相关论文可以在线获得（但在BOF之后这些文档可能转为存档状态）。

7.6.1　Middlebox研究

学术界最近的研究集中在MiddleBox（中间盒）设备的优化上19，其本质上是NFV研究关注的虚拟服务设备（或者子集）。由于这些可能不止一个设备而是一个服务链，研究主要关注集成、管理和扩展一个完整的MiddleBox部署的能力。

19.这里是指可以了解到的公开研究，并不一定包括关于这个主题的所有研究。

威斯康辛大学的一系列研究（Stratos20，似乎后来发展为CloudMB21）提出了对这样的服务链的性能优化方案，基于应用程序报告的性能矩阵进行服务流监测，在维持预先定义的应用程序性能指标的基础上（使用启发式贪婪算法），通过增减特定的MiddleBox 实例来缓和瓶颈（由某个时间阈值上出现的显著性能变化触发）。

20.http://minds.wisconsin.edu/bitstream/handle/1793/61606/stratos_tech_report.pdf?sequence=3
21.http://www.opennetsummit.org/pdf/2013/research_track/poster_papers/final/ons2013-final28.pdf

这项研究还关注MiddleBox初始放置的优化，启发式的（规模增减）和流内的MiddleBox分配来避免可能导致瓶颈的机架间流量（网络可知的放置和流分布）。

还有一个要点是，在规模增减阶段不要移动已有的流（没有服务中断或先接后断（make before break）行为，其中包含规模缩减这一点是很有趣的，因为在网络空闲阶段这也许能够节省成本）。

在围绕启发式算法的研究中有一些有意思的概念和简化操作的假定/断言（涉及服务链）。

- 管理员希望完全不需要手动干涉（完全自动• 化的解决方案），而MiddleBox的本质或者说功能就是与处理过程无关的（或者可以通过处理过程实现成这样）。

- 期望的服务链拥塞处理解决方案可以（相对地）就地解决，不需要把流量转移到其他位置的实例或者链片段（也就是说要最小化分支）。

- 由于某些设备的运作本质，不能通过基础设施的传统流量计数器实现监测。也不能认定通过虚拟机资源消耗的简单监测就能够反映端到端应用程序的性能。因此监测过程需要应用程序介入。22

22.这并非对特定叠加网络（比如弹性叠加网络）的独特视角。

- 选择迭代启发式算法是基于其他的策略考虑：改变路径上所有的MiddleBox规模、对特定于功能监测的依赖、对包处理时间预期的依赖，和服务网元设备上CPU负载的监测。

这个解决方案使用了高级拓扑抽象来定义服务链以及中央控制器，从而进行转发编程（比如使用OpenFlow控制器）。控制器增加了一个拓扑文件，用MiddleBox和应用程序实例填充，由此它可以为交换基础设施生成服务链转发规则（根据抽象的拓扑链）。更通用的描述是，这个扩展将传统的（简单的）控制器拓扑和路径计算变成了可感知服务的。

这个系统/流程与虚拟机编排系统合作进行服务虚拟机的初始放置，并在启发式算法增减规模时增减实例。

Slick23则采用了不同的策略。SDN协议语义保证了可以把（虚拟）交换机变形为网 络服务设备，但协议和现有实现的限制阻止了这种可能性的实现。Slick探索了两种广阔的领域：绕过SDN中流匹配的现有静态语义这个局限，以及（可能不是有意实现的）动态服务链。

23.http://www.opennetsummit.org/pdf/2013/research_track/poster_papers/final/ons2013-final51.pdf

在这个项目中，可编程设备（比如一台可能具有可编程网元设备——FPGA、NPU、GPU的服务器）上的专门控制器与一个代理（Slick控制器和代理）对话，让这个代理动态加载应用程序功能，通过这些功能向控制器提供返回触发器。

应用程序与控制器交互，在网络中安装功能和一个流匹配集。控制器负责放置功能（与CloudMB 通用）并且为到这个功能的流建立路径，如图7-14所示。

图7-14：迭代式MiddleBox优化技术；Web客户端报告超过了规范指定的响应时间后，编排器（与SDN控制器合作）迭代式增加服务路径上不同MiddleBox的（局部）容量来消除瓶颈

这个概念看起来似乎通过去除先验的功能分配，打破了MiddleBox的垂直集成（比如设备自身不再是一个防火墙，但是可以执行防火墙的某些功能）。所以，Slick不只是提出了服务链这个一般性概念，还给出了虚拟服务的定义。

7.6.2　Embrane/LineRate

虽然本书介绍控制器那一章没有介绍Embrane，但可以把它看作是非常专门化的SDN控制器，在NFV讨论中提出来是合适的。Embrane的产品Heleos是一个提供虚拟网络服务配置（provisioning）的平台。它不依赖于任何标准化SDN协议，在自身应用中直接集成了服务管理应用程序，因此这里控制器、编排和管理系统的概念有一点模糊。（SDN领域中，这已经成为重复的主题！）和其他一些SDN控制器/代理架构一样，Embrane的控制进程（ESM——弹性服务管理器）只支持它们自己的设备仪器（DVA——分布式虚拟设备）。DVA本质上是用于COTS计算的虚拟服务网元设备。Embrane目前提供负载均衡和防火墙服务。

对于像Embrane这样的解决方案有一个大问题，公平地说也是所有将要上市的类SDN解决方案的问题，就是它是否要发展开放的生态系统来支持第三方应用的开发和管理，还是继续走私有路线。如果选择后者，对于这些解决方案来说，是否能够得到足够多的客户支持以形成一个事实标准，将是值得考虑的问题。

LineRate 系统已经被F5网络收购24。LineRate源自于科罗拉多大学的研究工作，当时已经有一个（公开）产品，是虚拟负载均衡器（LineRate Proxy）。这个虚拟服务 是一个完整的应用程序层代理，具备流量定向能力，由外部策略驱动。这是与虚拟化服务/NFV相关的一个产品。与Embrane的区别在于，LineRate没有单独的控制器/代理架构，也没有提供控制器，而是提供一个外部策略服务器。LineRate对于SDN定义和网络功能分解的看法确实很吸引人。

24.http://www.f5.com/about/news/press/2013/20130211/

- LineRate实现SDN的方法看起来类似于DPI，但是LineRate声称与其不同，是因为它并不是基于包匹配/转发进行流量定向。而是缓存并重放应用程序层级的请求，加上对响应应用的策略来实现流量定向。因此这种解决方案能够向其他源或中间服务（比如视频优化服务）重新发送请求。

- LineRate 在其市场推广文档中指出，可以像集成服务( 比如EPC) 分解一样，LineRate 解决方案的定位作为控制点更有效。

ETSI中的NFV工作也已经表明流内的不同位置可能需要low-touch控制（比如OpenFlow中的流匹配）和high-touch控制（比如完全代理的某种混合）。low-touch控制可能更适合在流建立和位置转向过程发挥作用，而high-touch控制可以用于流量分割和汇集。

Embrane和LineRate都宣传过它们灵活的许可模式，包括无密钥、基于使用、预定模式等各种选项（对于这些模式各个公司使用不同的术语，但思路是一样的）。既然价格/许可都不是固定的，可能很快就会成为历史。但在NFV或服务虚拟化的讨论中许可模式也还是一个很重要的考虑因素。举例来说，基于使用的定价模式可能更需要优化和自动化，就像Stratos/CloudMB提供的一样（或像在后面用例章节中将要介绍的反馈环，它会优化发给服务结点的流量）。

7.6.3　平台虚拟化

当前运营商网络已经发展为一组专门设计的集成网元设备或平台。举例来说，核心路由平台的基本设计是为了实现极其高速、低延迟的包转发，并且以尽量减小物理引脚数、功耗具有良好散热的形式封装。这个平台放置在网络/厂商边缘，在那里可能要在转发速度、会话状态管理、协议会话规模和其他服务之间做出权衡，如果不使用完全不同的一组转发刀片服务器和服务刀片服务器，就可能很难做到。

随着时间的发展，有些厂商开始专门打包某种类型的平台。最常见的例子是宽带网络网关和演化封包核心网组件25。

25.参见http://www.virtualization.net/5653-carrier-sdn-solutions-virtualized-epc/或http://www.huawei.com/en/about-huawei/newsroom/press-release/hw-196147-sdn.htm（华为也提交了vBNG 作为一个NFV用例）。

随着网络运营商开始探索SDN，这类平台最大的几家厂商的竞争者也开始研究新的打包模式，这些打包模式降低了成本并且采用了某些服务虚拟化基本原则。

他们提出的总体设计是使用SDN控制器（比如OpenFlow控制器）把转发状态编写到一个（简单很多而且成本更低）交换网元设备中，在一个基于服务器的相关应用程序中创建特定于应用的状态（协议或者用户会话状态）。还有一些（前面提过的）项目用RouteFlow（OpenFlow 上的BGP 和IGP）、Flexinet（OpenFlow 上的BGP）以及IP Infusion26最新的产品（ZebOS BGPD）等低价组件替换或集中实现当代路由器的功能。

26.http://www.ipinfusion.com

传统厂商对此的响应是，对传统网络运维中最容易虚拟化的部分进行虚拟化，比如BGP路由反射器（vRR），如图7-15所示。这些设备的设计意图不在数据平面中，因此很容易转化为在虚拟机上运行。

图7-15：作为运营商网络可编程控制点的概念上的虚拟路由反射器（vRR）（比如向汇聚网络注入路由）

如果vRR有一个标准化编程接口和标准化控制器/代理控制会话，那么它就变成了潜在的SDN控制集中点。然后现有的厂商边缘（Provider Edge）设备部署就开始变得像SDN部署了（即使它们主要还是继续使用既有的分布式控制平面），为当前运作方式和更加虚拟化的未来操作提供了过渡桥梁。

瞻博公司的Contrail产品和ALU 的Nuage产品的SDN控制器探索了这个模型，这个模型也出现在其他传统网元设备厂商的产品中。这个模型在数据中心环境中特别容易实现，其中虚拟供应商边缘（vPE）设备作为vRR，伴有基于主机的代理（为数据/转发平面编写基于虚拟机管理程序的路由实体）作为控制平面，租户虚拟机作为虚拟化虚拟客户边缘设备出现。而vCE云也可以作为托管服务的一部分，为企业VPN市场集中化/优化WaaS、IPSec和其他服务（表面上使用流隧道）的流程。图7-16给出了一个vCE 提案的概念图。

图7-16：2013年MPLS及以太网世界大会上的Fang/Bitar vCE提案

传统网元设备厂商也采取了渐进的策略，把服务部分从硬件分离出来。比如有些厂商在服务最终完全虚拟化之前提供程序，先在连接服务器（tethered server）上运行服务（使用其SDK/API，用于在集成平台中链接服务的已有扩展）。这样就可以在共同的计算平台上实现链接编排和协议逐渐实现的同时，过渡使用服务（图7-17）。

图7-17：过渡/集成服务虚拟化策略

服务可以运行在内部NPU或CPU刀片服务器和连接的COTS上，其中COTS使用的API扩展，支持在连接计算设备上使用内部管理和转发/链接技术，最终发展为外部控制的独立实体。这个层级的虚拟化和链接是专有技术，但也支持某种程度的COTS计算扩展，也可以与应用程序层的负载均衡和局部静态路由功能共同合作，产生新的服务（比如移动领域的服务传递网关，Service Delivery Gateway）。然而在这个模型中，虚拟化服务的管理者可能是路由器/交换机（特别是在tetheredappliance模式下）。由于缺乏可用的服务链协议和包封装标准，早期市场上的服务 链可能是通过GRE 封装和路由泄露（route-leaking）技术创建的（图7-18）。

图7-18：使用路由实例的链式服务

还有许多运营商（宽带聚合器）在考虑转向虚拟化CPE 设备（vCPE）。这些研究已经回归到了这样的思路，用于宽带聚合（BNG/BRAS）的传统PE（供应商边缘）设备作为虚拟化实体（vPE）可能也同样有效。对于运营商来说， 实现vCPE的动机来自于通过把（已经精疲力尽的）3层CPE 转为2层CPE和COTS硬件的组合，这些COTS硬件运行3层CPE基本服务（比如NAT、DHCP、DNS），未来还可能运行更高级服务（比如安全、HTTP代理等），从而支持新服务创建，降低成本并降低客户售后服务电话率，如图7-19所示。

图7-19：应用于运营商网络3层CPE的网络功能虚拟化（概念验证）

这项工作最终导致了能否把BNG功能与vCPE功能集成的研究（图7-20）。

图7-20：集成并虚拟化BNG 和CPE 功能构建的宽带汇聚平台

这个领域（超出概念验证）的工作包括虚拟化功能放置的性能影响（比如放在BNG北向或者南向，与AN共同放置等）研究，以及如何分解集成功能来创建水平可扩展的解决方案。还包括在ETSI NFV论坛上也在研究和讨论的容器策略和I/O优化策略。

目前的集成解决方案（实现vCPE/vBNG的例子）每用户价格是非常低的，新的虚拟化服务也需要达到这点。可能只有到未来某个时间每用户成本达到商业上的要求（当COTS价格/性能曲线达到某个阈值），这些新的虚拟化平台设计才在技术上是可行的。

7.7　小结

网络功能虚拟化是一个比较早的想法，当它首次被提出的时候还无法真正实现。但随着SDN的出现、服务编排技术和虚拟化技术的发展，现在已经可以实现。与SDN对控制平面所做的一样，SDN 概念和结构使运营商和用户使用新的虚拟化的和可链接起来的服务平台结构，重新考虑内置到当前服务平面提供或服务发送方案中去的设想。虚拟化本身并不能解决所有的服务部署问题，实际上它还引入了新的可靠性问题，需要通过服务编排系统或架构设计来缓解。

本章的重点，以及NFV发展的重点是虚拟化，但实际上其中涉及的编排和链接需要支持当前和未来的完全集成服务平台（至少到完全虚拟化解决方案的I/O特性使它们的作用黯然失色和它们必须面对的一些“艰难”时期到来之前）。

还不清楚目前虚拟化环境中的数据平面处理开销，是否会影响高租用率虚拟服务主机的实用性。NFV的一个现实成果是编排系统和SDN的集成实现流量定向和按需规模增减。

关于将现有服务分解为功能网元设备，已经出现了大量的研究，关于分解颗粒度的意见还不统一。对于服务整体和其单独网元设备，服务分解最终都会影响服务链的复原能力和可用性需求。它还会进一步冲击到运作的规模和复杂度。需要确定功能单元、服务链的总数，以及构建和运作服务链的约束条件，而这些可能只有通过实验性的部署和其他实验才能确定。这些服务链需要包含虚拟化和非虚拟化的服务网元设备。

尽管服务链和NF 已经混为一谈，但现在还不能确定运营商的服务链部署会是网元设备物理位置上高度分散的，还是继续构建类似于目前没有链接情况下的非常线性化/流水线化的结构。利用的NFV改进主要是（就地）增减服务规模。

尽管SDN在服务虚拟化控制领域的角色已经被广泛接受，但关于控制点的类型还有争议。特别是在涉及无状态控制点与代理控制点之间的对比时。

类似于威斯康辛大学的研究27进一步强调了拓扑结构的角色，在SDN（也就是超越了简单的单层表达）中，以及在向应用或通过应用提供的抽象类型中（这种情况下是定义服务链的语言）。这项研究也提出了（常常被忽略的）在新的运作模式下排除故障的主题28。

27.总的来说学术界研究为SDN 及其应用程序提供了重要支持，这里只是一个具体的示例。
28.目前已经有草案提出在VxLAN 叠加网络中创建类OAM 的功能，但OAM、ipsla、ping和traceroute这样的通用故障诊断工具还需要添加到各种主流叠加网络环境中。

与故障排除一样，安全议题也是服务虚拟化的当前讨论中所缺乏的（在整个SDN讨论中也是这样）29。有些领域中用户社区的洞察力最强，做出的贡献最大，投入的热情最多（特别是那些政府部门深院之中的工作人员或黑帽安全专家），安全领域可能就是其中的一个。同时，虚拟化服务的市场已经出现。Embrane等专门SDN解决方案厂商提供了成套的解决方案（重新发明了负载均衡和防火墙服务概念），更通用的控制器/框架厂商也已经开始公开讨论面向其平台目标应用程序（某些数据中心编排系统已经在相关领域环境下集成了设备识别和放置功能）的服务链技术。

29.尽管ETSI NFV论坛和ONF都已经启动了安全子工作组，前者的目标是在2013年发布最佳实践推荐。

在这些NFV架构或模型中，编排层分配服务容器，而SDN提供连通性，还可能进行某些抽象来掩藏灵活性引起的某些复杂性。二者需要相互合作才能提供高可用性并形成统一管理/运作视角。同时，幕后的传统OSS/BSS并不是真正设计来管理高度分离的NFV服务的，NFV编排和SDN这一对将不得不提供一个转换。这些系统还需要进化以适应NFV许诺的虚拟化网络服务未来新发展。

最后，很明显传统厂商正在他们的集成服务平台中寻找比较容易的部分进行虚拟化转换，同时也在关注实现的性价比，等待厂商网络边缘（vCPE/vBNG/vPE）更复杂的整合方案变得可行的时机。这些早期转换肯定包括虚拟防火墙、DPI 和负载均衡功能（既然这些是每个产品链都包含的最基本功能）产品。最终，入侵检测系统（IDS）、入侵防御系统（IPS），SSL卸载机（off-loader）、缓存和WAN优化器也将成为目标（特别是在企业网络/租户领域）。现在的问题就是，这样的转换是快到能让传统硬件厂商跟上趋势，还是能让后来者抢到一席之地。

第8章　网络拓扑结构与拓扑信息抽象

8.1　引言

某些网络应用很久以来就已经在使用拓扑信息，这些拓扑信息可以说是网络世界提供给应用程序的难得的金矿。这些网络应用必须满足几个重要的标准。首先，它们必须是与某个路由协议相关联的。其次，它们必须在真正意义上被允许加入到路由中去：即必须直接连接到一个路由的网络里，而不仅仅是把一台服务器放上机架连上网。

这往往要求该应用程序必须通过其他网络设备经历过的那些安全性和其他质量保证检验。这往往需要多年真正意义上的测试才能达到。并且当这一时刻到来时，当应用程序被允许加入网络，应用程序仅限于获得活跃的（active）拓扑信息，用于该时刻的实际路由或指导流量。

路由计算中一般不需要非活跃的（inactive）或处于休眠状态的（dormant）拓扑信息1，所以任何路由协议交换中都不携带这类信息。但有些应用程序需要这些信息，如本章稍后解释的应用程序。因此应用程序仍然要通过带外的方式来手动获得这些信息，例如可以通过命令行界面或其他管理协议。

1.这里所谓非活跃的或处于休眠状态的拓扑信息，是指实际上存在，但尚未实际使用的拓扑。例如某端口实际存在，但处于端口down的状态，那它就是一个处于休眠状态的端口。某些应用程序也可能需要这些信息。——译者注

传统的获取拓扑结构的方法的最后一个缺点是拓扑信息的格式。正如人们所期望的那样，拓扑信息被格式化，这样路由器能就可以快速收集和处理拓扑信息，以便用于最快的路由计算。如果使用带外方法来获取，则拓扑信息就采用适用于命令行界面的另一种格式，但这不适用于做其它计算。可惜，这些拓扑信息的格式在应用程序做其他用途使用时不够理想，因此需要进一步处理才能使用，这需要进一步的努力、开销和装配。幸好，拓扑信息及其发现、检索和处理领域的新方法已经着手探索。事实上，本章将详细阐述获得拓扑结构的新努力和新方法，拓扑信息是如何通过SDN控制器和框架提供给应用程序的。至于获得拓扑信息后可以做什么，那将是本书讨论的内容。

8.2　网络拓扑结构

在深入探讨采集、构建和维护一个现代化的网络拓扑结构意味着什么，特别是对SDN方法的用途意味着什么之前，那么退后一步，先简要介绍一下网络拓扑结构。

网络拓扑结构是各种网元设备之间的互联和关系。网络拓扑结构可以归结为两个基本要素：节点和链路。节点代表任意数量的网络设备，如路由器、交换机、服务器、手机、照相机或笔记本电脑。请注意节点既可以是终端节点，也可以是互连节点（connecting node）。终端节点位于拓扑结构图的端点，不与其他节点互连，从而转发其他节点之间的流量，终端节点的示例包括笔记本电脑和iPhone手机等。互连节点的功能顾名思义：它们把其他节点连接在一起，互连节点的示例包括路由器或交换机等。

由节点和链路构成的网络拓扑结构有两种连接方式：物理连接或逻辑连接。物理连接就是指实际的网络接口，例如在节点之间互连的物理电缆（如以太网线）或光纤。而逻辑连接是一组结构，其中包含建立在物理基础设施之上的虚拟接口或网络路径等。例如，三层的IP 接口就是在以太网五类双绞线等物理接口之上的一个逻辑结构和封装。当然，无论是物理连接还是逻辑连接，两个节点间的距离、物理上的互连或接口的传输速率都可以是不同的。

一个包含了逻辑和物理链路节点的拓扑示例就是，六个节点加物理或逻辑链路的简单以太网局域网。在这种情况下，每个节点都至少有一个位于各节点之间的物理接口，可能还有通过协议栈方式建立在这个物理接口之上的三层的IP逻辑接口。

如果人们希望可视地显示拓扑结构，则拓扑结构看起来像一些常见的几何形状，如图8-1所示。然后人们可以将这个拓扑结构中物理或逻辑实体之间的数据流，映射为（相同）物理承载拓扑之上的二层拓扑可视化。

图8-1：经典的网络拓扑

通过这种二层拓扑可视化方式，可以看到拓扑结构不仅有助于跟踪节点或链路等实际实体，还可用来表示节点或链路的状态。例如，可以想象在图8-1的不同元素中用各种着色手段，例如用红色或绿色指示灯来表示这些接口的操作状态。

为了保持完整性，在图8-1考虑和显示了七种基本的拓扑结构：

- 环型（Ring）或称为圆型（Circular）拓扑结构；

- 网状拓扑结构（Mesh）；
- 星型拓扑结构（Star）；
- 全连通网状拓扑结构（Fully connected）；

- 线型拓扑结构（Line）或称为链状拓扑结构（Daisy chain）；

- 树型拓扑结构（Tree）：无环的（acyclic）或多向的（multidirectional）；

- 总线型拓扑结构（Bus）。

当然，这七种拓扑也可以混合使用，实际上，混合使用在真实网络世界中非常普遍。

只要拓扑信息已经采集到，且被认为是稳定的，那就可以对拓扑信息的表示形式进行不同的模型化工作，以便能把管理系统内部使用或外部使用的拓扑信息最好地表示出来。

在大多数情况下，利用拓扑分层来关联不同的拓扑物理层和概念层，并把它们组合在一起。这个概念并不是一个新的发明，而是自网络时代一开始就存在的，但它随着时间的演变包含了越来越多的信息。注意，当考虑多层拓扑时，第0层到第7层都要考虑。

因此，这既包括物理的、光学的拓扑结构，也包括在物理基础设施之上的虚拟网络层，如三层的MPLS VPN。

典型的拓扑图不仅包括物理和虚拟的网络组件，现在也包括使用这些链路和节点的应用。在拓扑图中表示这些应用也很重要，在图8-2中，这里不仅表示了逻辑的三层网络，还有两个附加层2。

图8-2：展示了管理站点多层拓扑的概念图

2.作者这里指的是在图8-2中，最右端是三层拓扑，中间是相关服务器的连接层及其在右面的三层拓扑里的位置，左边是应用程序的层次及其在中间服务器中对应的位置。——译者注

对这些高层级概念的表示有助于网络规划者和设计者更好地监控和调整网络，应对观察到的或预测到的网络变化。根据第7章中对NFV的讨论，这是特别重要的。

8.3　传统方法

现在快速回顾一下在SDN出现之前，维护、收集和发现拓扑结构对真实网络意味着什么。

传统的拓扑方法包括一些基本操作：网络拓扑的初始发现，跟踪不断变化的拓扑结构（即重新发现），只要拓扑收集到且视为稳定后，就用于管理和或对外提供拓扑信息。

收集到并与网络拓扑信息交互时，有两类很不同的方法：屏幕上的命令行界面、SNMP的MIB库或NETCONF的混合使用，或参与路由。

在第一种情况下，应用程序一般会依赖一个网络管理站点来采集各种拓扑信息，然后进行整合、过滤和抽象，把信息转化为专有格式，以便提供给应用程序或其他管理服务使用。应用程序只要获得这些信息，就可以在这大量的信息里搜索到所需部分。有些情况下，管理站点也需要通知相关的应用程序现有的拓扑结构发生了变化。例如，如果发现了一个新节点，则把这一变化及时通知给应用程序就是很重要的。

与设备进行通信时可以使用多种方法，包括命令行界面、SNMP、NETCONF甚至ARP探针或ICMP的ping报文。这些方法的搭配使用将返回各种信息，包括二层或三层的可达性、连接的邻居、逻辑隧道/路径，以及它们的基本状态。只要收集到这些信息，就处理成可以剖析和抽象的形式，最终可以被其他应用程序操作和使用。

有许多成功的公司提供完成上述操作的应用。例如以前的Cabletron Spectrum系统（即现在CA 公司的Infrastructure Manager，即基础设施管理系统IM）把拓扑发现技术带入了一个新的水平。这些应用程序不但能发现活跃的三层拓扑，还能找到非路由式（即二层）拓扑里集线器和二层交换机等设备。最后，它们还可以找到处于休眠状态的、处于故障状态的、或还没有被路由协议所宣布的设备、链路或路径。CA公司的Spectrum/IM系统的屏幕截图如图8-3所示。该图显示了物理的和逻辑的拓扑如何叠加在一起，为网络管理者构建一个全网的完整视图。

图8-3：CA公司的Spectrum/IM系统的拓扑界面

其他公司把参与路由作为收集大部分拓扑信息的手段，但作为早期的方法，需要加强从其他管理接口（如从命令行界面）中获得的信息。

这方面产品的一个示例是Packet Design公司的Route Explorer产品。其本质是，Route Explorer作为BGP、OSPF或ISIS的协议实体参与路由，但只是简单地接收路由信息。这样它就可以得知路由器正在通告的网络范围内的拓扑。图8-4展示了它的工作原理。执行Route Explorer的服务器必须至少有一个接口（例如以太网端口），从这里与IGP和BGP建立邻接关系，学到信息。

图8-4：Packet Design公司的Route Explorer产品参与活跃的路由，通过把自己伪装为一个路由器来收听路由协议更新信息，以便获取网络拓扑信息

不管拓扑信息是如何获取的，一旦收集到，拓扑管理系统就对拓扑信息进行归一化处理，转换成可由系统的其余部分使用的格式。

在过去，系统的其余部分包括管理应用或运营支撑系统（OSS）的其他部分。由于厂商与他们的网元设备是紧耦合的，所以拓扑的格式可能是专有的，或至少是由厂商定义的，只有当外部应用程序必须与之交互时才公开。

然而，今天的SDN控制器体系结构的一个关键之处就是有一个标准化的北向API。每个控制器都拥有独自的API是很重要的，因为它允许应用程序进行编码从而与控制器进行交互，但是这仅仅是开端。正如第5章提到的那样，把这个API定义为行业标准，将允许并鼓励应用程序的可移植性（application portability）。

在日益增长的SDN控制器世界里，采用通用的API来对SDN应用程序进行编程，不仅在理论上很重要，而且在成本上和操作上也很重要。这意味着网络运营商可以购买或建造单个应用程序来完成一项特定的任务，然后应用程序就可以与部署在该运营商网络里的所有控制器进行交互。

可对网络拓扑做的一件非常有趣的事就是“网络变化模型”，或更通俗地说，是基于“假设”（what if）的情景规划。只要采集到网络拓扑并视为一个稳定的拓扑，这个特征就可以使用。

如果已经有了网络拓扑结构，并且知道该拓扑是如何构建的（即路由拓扑算法、约束、网络策略、链路带宽利用率、接口状态等），就可以把拓扑结构看作是一种非常精确的模型运行网络的模型。不仅如此，还可以知道当前状态是如何达到的。

由此可以想象，可以通过变化来看看网络拓扑受到了怎样的影响。例如，网络运营商很有兴趣去观察，在改变链路度量、带宽利用率、链路添加或删除、备份路径添加或任意数量故障（如链路、节点或整个网络出现故障）的情况下，会对网络的流量模式和行为产生怎样的影响。

此外，只要实现了分层拓扑结构，就是前面（图8-2）所展示的那种，（除了观察到网络设备的三层拓扑），还可以观察到正在运行的应用程序，或承载这些应用程序和服务的服务器的拓扑，则对未来的服务能力进行规划等操作也就可能实现。

适用于这一点的一个关键的SDN应用就是网络功能虚拟化（NFV），以及这些虚拟化功能与其他实际或虚拟功能之间的服务链。这些方法成功的一个关键点实际上就是服务以及这些服务如何连接起来的服务级拓扑视图（已经在第7章详细讨论过）。

8.4　LLDP

第4章讲述的早期SDN控制器和OpenFlow交换机的方式，在体系结构上还缺少一个关键组成部分没介绍：需要发现被控制器所控制的OpenFlow交换机的网络拓扑。

控制器需要该信息来规划、配置和监控交换机之间的网络路径。但没有为交换机设置路径前，这个信息是拿不到的，直到为它设置路径才能拿到，也就是说，交换机还在等待控制器在它们的初始化状态中进行编程。

这就陷入了先有鸡还是先有蛋的窘境。为了解决这个问题，LLDP协议在交换机端口上默认是被启用的。但并不是直接用发现帧（discovery frame）与远程交换机通信，收到的发现帧信息被中继传送到SDN控制器，SDN控制器收集这些信息形成网络拓扑结构的集中式视图，然后再把这个视图转发回邻居交换机。这在OpenFlow的部署体系结构中是行之有效的。

链路层发现协议（Link Layer Discovery Protocol，LLDP）是一个行业标准的协议，它允许网络设备在二层局域网内发现并宣告能力与身份的信息。

该二层协议由IEEE来标准化3，取代了由个别厂商为他们的设备实现的特有协议，包括思科公司的发现协议（Cisco Discovery Protocol，CDP）。

3.IEEE 802.1AB-2005

LLDP允许在协议栈更低层运作的网络设备（例如，二层的网桥和交换机），来学习局域网中网络设备上用于高层协议的一些功能和特性（如IP地址）。

通过LLDP操作收集的信息被存储在网络设备中，并且可以使用SNMP协议、命令行界面或NETCONF 进行查询。一个设备的邻居拓扑和相关联的信息也可以从该数据库中获取。

可以通过LLDP收集的信息包括以下内容：

- 系统名称和说明；
- 端口名称和描述；
- VLAN名称和标识符；
- IP网络管理地址；
- 设备的能力（如交换机、路由器或服务器）；
- MAC地址和物理层信息；
- 电源信息。

为LLDP操作配置的设备在每个LLDP开启的接口上都发出PDU（协议数据单元）。PDU是按固定时间间隔发送的以太网帧。每个链路层发现PDU 包含一个“类型-长度-值”（type-length-value，TLV）结构的序列，其编码表述前述这些属性4。这些帧被发送给一个不用于转发的特殊组播地址。以防止转发环路导致的广播风暴。

4.LLDP支持厂商通过TLV的类型127来扩展和定制。

图8-5展示了由两台交换机、三部IP电话、一台电话用户交换机（PBX）和一台PC机所组成的一个基本网络。这里显示了每个交换机都接收到LLDP邻居发现信息时的情况。请注意，每个交换机的邻居发现表中都显示了每个邻居的类型和地址。

图8-5：一个由两台交换机、三部电话、一台电话用户交换机和一台PC所组成的简单网络中LLDP的操作示例；此时每个交换机都接收到LLDP邻居发现信息

在SDN中，可以利用LLDP作为交换机发现协议。LLDP所收集的信息可用来构建网络的拓扑结构。

在图8-6所示的示例中，由两台交换机组成的非常基本的网络，在图顶部的SDN控制器的控制之下。

图8-6：使用LLDP作为SDN控制器的交换机端口发现协议

OpenFlow的网络发现使用packet_in和packet_out消息来实现。如前所述，当网络的各端口收到邻居发现信息时，这些信息被交换机通过处理“packet in”规则转给SDN控制器。接着这些信息也被SDN控制器转发给邻居交换机，这样这些邻居就可以学到其MAC地址。重要的是，网络拓扑结构数据库构成了。

前面所述的交换LLDP邻居信息的方法，虽然确实可以解决邻居交换机的拓扑发现问题，但这种方法仍然存在问题。

首先，这种方法仅限于实现LLDP的交换机。这通常倒不是一个大问题，但必须实现一个特定的路由（或交换）协议，这对应用程序来说很没有吸引力。

其次，LLDP拓扑信息局限于交换机的直连二层邻居。如果某些端口配置错误（即它们的初始配置不正确），则这些端口上无法执行发现功能。

最后，在跨越完全由OpenFlow控制的交换机区域、非OpenFlow的区域或混合区的拓扑结构中，邻居发现信息很难缝合在一起。理由是（正如前面所述，控制器的北向API）标准并未统一起来，因此信息的交换仍仅限于理解专有定义的应用程序或其他控制器。进一步看，拓扑格式本身和其所包含的内容也都是专有的。

由于这些限制，需要更多的工作来建立存储库，允许个别的方法和数据集可以被合并进去，以创建多层的视图（如图8-2所显示的那种多层拓扑结构）。

8.5　BGP-TE/LS

正如已经提到的，有两种获取网络拓扑信息的基本方式：管理协议或路由协议。后者的一个方法是BGP Link State（BGP 链路状态扩展），更常见的叫法是BGP-LS。前面提到基于路由协议获取拓扑的方式时，并没有细讲，这是因为路由协议里的信息主要是适用于路由计算的信息，而对其他计算所需的拓扑信息不一定是最佳选择。但BGP-LS试图纠正这方面的不足。

BGP-LS是对BGP的扩展，允许BGP协议携带链路状态信息。链路状态信息通常从IGP的状态信息中获取，但这里是从区域的流量工程数据库（traffic engineering database，TED）来获取。这些信息可以从多个域和多个自治系统来聚合，以执行对网络状态的分析。

无论是IGP的流量工程数据库还是通过BGP-LS来收集拓扑数据，都应可以提供相同的信息集合。然而，BGP-LS的发明是专门利用BGP的一些属性，以获得更好的可扩展性。这些措施包括基于TCP 的流控和路由反射器的策略性使用。因此，BGP-LS也是一个更具扩展性的选择，当人们需要获得多个域的拓扑信息时，这通常需要人们使用更多的手动方式从每个自治系统的数据库中收集。

流量工程（traffic engineering，TE）控制器（例如PCE服务器的应用程序）实现BGP-LS 作为获取路由拓扑的一种手段。在SDN中，这当然只是另一种SDN应用程序和控制器的组合。实际上，第4章描述了这个控制器，第12章描述了这个用例。BGP-LS也支持策略机制，使人们可以限定某些节点、链路或由用户分区的拓扑部分的展示。一个TE 控制器将提供必要的控制旋钮来支持此功能。

当链路/节点失效等网络拓扑变化事件发生时，用IGP的泛洪机制来传播拓扑信息给TE控制器，要比BGP-LS快得多。这是因为BGP-LS必须等待网络中的路由器上本地IGP来更新流量工程数据库，然后BGP-LS才能把这种网络变化事件发送给对等体。这种延迟不应对使用BGP-LS收集拓扑信息的实时特性产生不利影响。

那么，为什么还要发明BGP-LS呢？它用来解决哪些尚未解决的问题？正如刚才提到的那样，已经有用来获得网络拓扑结构的手动方法，也有通过参与路由过程来获得路由链路状态信息的方法。路由协议中的信息对获取拓扑而言存在几个问题。现在来研究这些问题。

用BGP-LS来支持PCE

第4章中描述了路径计算单元（PCE）如何用于计算MPLS-TE的路径。计算这些路径时，它们在一个域内，例如一个自治系统（即一个IGP区）内计算，或者跨越多个自治系统或区域计算。

在这种情况下，描述了PCE如何通过使用比路由器成本更低的、性能更高的COGS硬件来提供增强的计算能力，以在路由器之外运行CSPF算法。此外，也可以用其他CSPF算法来做用户自定义的路径计算，这可能无法在某些特定的商用路由器上实现。

但问题是，在这些情况下，缺乏全局（多域的）拓扑结构信息可能妨碍这些计算的精确度。例如，可能为一个特定路径选择了一个错误的出口路由器，或选择了错误的中转节点。在其他情况，可能只是选择了非最优的路径。

为了解决这个问题，PCE需要访问整体或全局流量工程数据库。某些前期的方案，让PCE变成IGP 路由信息的被动收听者，从而参与到路由过程收集拓扑。但本书已经讨论过，路由过程并不总能提供拓扑信息的最佳格式。图8-7显示了一个PCE如何通过参与路由过程以及利用BGP（BGP-LS）来得到流量工程数据库信息。

图8-7：使用流量工程数据库（TED）同步机制的外部PCE节点

展望未来，PCE服务器将能够通过BGP-LS跨多个域的互联来获取全局拓扑信息。

8.6　ALTO

对拓扑信息进行标准化的第一个努力就是应用层流量优化（Application-Layer Traffic Optimization，ALTO），它不仅对拓扑信息进行格式化，而且使这个格式以标准化的方式提供给应用程序，以便应用程序不再需要与路由协议直接交互。这是一个重要的转变，因为开发现代应用程序通常并不是为了与路由协议交互。ALTO提供网络信息的应用，如网络位置、结构，以及对各种网络服务的网络路径偏好。

目前ALTO的目的是为内容分发网络（Content Delivery Network，CDN）提供路径，这也是它的实际应用。提供此路径信息的目的是为了通知应用程序，例如那些在寻求最近的CDN服务器的应用程序。应用程序获得这些信息就可以提高性能。一个有趣的副作用是，这项服务有可能进一步优化为网络资源的使用模式，这正合网络运营商的心意。

ALTO服务提供的基本信息是网络的抽象或逻辑拓扑图。该拓扑图映射可以由一个ALTO服务器获取的物理或逻辑拓扑来构造。

前面讨论过，网络的拓扑结构既可以是物理的也可以是逻辑的，在这种情况下不仅是逻辑的，还可以是网络服务层的。

前文图8-2所示的分层拓扑结构，就代表了分层中最顶端的层级。抽象拓扑图提供CDN节点和网络中节点之间路径权重的一个抽象视图。这可以把拓扑范围简化，降低到一组CDN相关的应用程序的程度。如果对其他详细信息感兴趣，可以再参考其他拓扑资源，如管理界面或基于路由的资源，即前面各节讨论的那些拓扑信息获取方式。

ALTO服务器是一种在Web服务API上向需要感知网络的应用程序公开的网络服务。ALTO协议使用RESTful来设计，其请求和响应的编码使用JSON5。正如第5章所指出的那样，现代应用程序的程序员因为其灵活性和可扩展能力而愿意选择这类方案。

5.IETF 的RFC4627。

作者认为ALTO是向现代SDN运动和范式转变的一个先驱。如果从这个角度来看，ALTO服务器和协议就可看做是SDN控制器实现中的一个早期参与者。

图8-8展示了ALTO服务器及其提供的网络服务的一个示例。

图8-8：ALTO服务的体系结构

BGP-LS和PCE与ALTO互动

如上一节所述，BGP-LS和PCE可以组合起来，做到对链路状态拓扑信息的速度更快的、更一致的和可扩展的采集，以形成用于跨AS 路径计算的更优化方案。

现在也把ALTO服务器描述为这样一种网络实体，它产生抽象网络拓扑结构，并通过Web服务API将该拓扑提供给需要感知网络的应用程序。示例应用程序包括P2P网络的客户端或服务器（tracker），或内容分发网络。抽象的网络拓扑带来了两种形式的图例：一种对PID的前缀进行分配的网络图，另一种是网络图内PID 之间的链路代价（cost）图。ALTO的抽象网络拓扑可以从底层网络的物理拓扑结构自动生成。这种自动生成通常基于运维人员所设置的策略和规则。

地址前缀和流量工程数据都是必需的：地址前缀数据用来产生ALTO网络图；流量工程 （拓扑）数据用来生成ALTO的代价图。地址前缀数据由BGP携带和产生，流量工程数据由IGP协议携带和产生。

虽然ALTO提供了了单一接口，通过它，ALTO服务器可以从底层网络获取所有必要的前缀和网络拓扑数据，ALTO服务器也可以使用其他机制来获得网络数据（例如，与多个IGP和BGP实体建立对等体关系）。图8-9 显示了ALTO服务器如何使用这种机制从底层网络中获取网络拓扑信息。

图8-9：ALTO服务器利用网络拓扑信息

虽然ALTO在继续进行部署和实施，但它的适用性和使用性仍然仅限于内容分发网络。此领域外也有一些大胆的尝试，但这么做的动力并不大。作者推测，尽管ALTO的协议和体系架构确实具有足够的灵活性可用于其他地方，但似乎有一种观点认为，ALTO最合适使用的地方就是CDN。

8.7　I2RS拓扑

第4章提到了一项称为SDNP的早期努力，SDNP由想对（当时的）SDN标准体系结构和关键部件进行标准化的一些人所提出。该体系结构由逻辑上集中式控制器和与其交互或被其控制的一组网络设备集合组成。该控制器表示那些它使用RESTful Web服务API实现的服务。

正如前面所述，这项努力由于过于超前而停滞不前了。然而从灰烬中走出了IETF的一个新的努力，最初被命名为IRS（Interface to the Routing System，路由系统的接口）。有太多的人反对这个缩写名称，因为这使他们过于心痛地想起了山姆大叔6，所以名字稍后微调为I2RS。

6.IRS是美国国税局的缩写，因此叫这样的名字就会让人想起该去交税了。——译者注

虽然仍处于起步阶段，但这方面的努力现已在行业内得到了有力支持，作者写作本章时，它继续在成功的轨道上前进。作者希望这一努力能够开花结果，因为它很有潜力，至少能解决一些围绕SDN 的棘手问题：北向API的标准化（I2RS 既可以读取也可以写入网络状态），以及最适合本章的问题，即广义的网络拓扑结构服务的标准化。

正如刚才所描述的，ALTO是在IETF早期的一项努力，通过对应用程序友好的API，构建一个标准化的、为应用程序服务的拓扑信息收集和表示服务。可惜，这方面的努力似乎严重依赖CDN。为此，I2RS工作组的章程里添加了通用拓扑，作为其重点工作项目之一。描述一下这意味着什么，以及I2RS的当前状态，以便大家更好地理解为什么这种努力是非常重要的。

I2RS拓扑管理的一个关键方面是拓扑收集（以及与拓扑相关的/符合的）数据格式，数据来自多个来源，包括网元设备、路由协议、数据库收集和统计数据收集等。

从上述对获得拓扑的努力和方法的描述中可以清楚地看出，从多种来源收集（包括从路由协议收集）拓扑信息，是形成完整的、有用的网络拓扑视图的关键所在。

为此，拓扑数据源可位于多个IGP区域、跨多个AS或多个网络层（包括单个组织内的管理域或系统，如传输和路由）。除了由这些来源提供的一般的链路和节点（虚拟的和物理的），其他一些数据源也可以用来增加拓扑图，如一些明确的节点功能（网络服务装置上的）、统计数据或者可被注入的物理设备清单。

这些信息可能被用于拓扑管理器（例如提供运行视图的界面），但很可能被用于更有意思的应用，如网络分析、服务定位和服务开通配置。

最终，拓扑管理的目标是建立全局性的拓扑视图。在实践中，这将会实现为基于一个共同的数据模型的应用程序，用于归一化所收集的数据并将其转换成标准格式，这种标准格式更容易使用和跨应用程序移植。拓扑视图可以最终跨越多个网络层以及多个自治系统或整个网络，这取决于不同的管理域是否能很好地合作与共享信息。

重要的是，该全局视图包括所有的网元设备和基础设施中存在的资源，无论它们是否正被活跃地使用。一个示例是重构网络全局视图时，包括可以使用但尚未使用的路由器或交换机端口。另一个是构建网络的全局视图时，包括路由器/交换机端口和已使用以及未使用的底层传输网元设备。这些在计算“假设”（what if）场景中都很重要。

这种操作在使用基于路由协议的方法中是很难做到的，因为这些未使用的端口信息根本就没有出现在任何活跃的路由更新中（尽管修改路由来支持这些功能的需求已经提出，像最近提出的MPLS-TE 中的SRLG 概念）。这只能通过附加的装置，例如一个专有的CLI完成。

收集了拓扑信息后，重要的是，它将以现代应用程序可接受的格式来呈现。为此，拓扑管理器将处理这些信息，并使用一个标准化的对象模型把拓扑信息归一化。此对象模型也将用于生成REST的API，以便应用程序用来收集这些拓扑信息。

从顶层看，直到人们意识到保存在拓扑服务器中的信息数量之巨之前，这一切都听起来很棒。因此，拓扑管理器能从其全局共同拓扑数据库创建多个（也许是针对特定应用程序的）视图，就变得非常重要了。这（在某种程度上）允许应用程序来设定查看信息的过滤条件。例如，刚刚描述的ALTO服务器这种应用，就很可能仅从数据库中查询CDN标记的节点和路径，这些信息由CDN拓扑层来提供。

来自网元设备的拓扑信息通过其南向API被中继到拓扑管理器上，如图8-10所示。拓扑信息的来源可能是网络不同层的网元设备，如家电、路由器、二层交换机、光转发器、光交换机，或监控、配置和网络分析工具（如统计数据收集子系统或设备清单子系统）。

图8-10：I2RS拓扑管理器的运行模式

在实施方面，拓扑管理器功能可以在一个独立的服务器上实例化，作为完整的服务编排系统、数据采集、展示框架的一部分，甚至是嵌入在一个路由设备之中。客户可以是上层框架中的一个应用程序或功能，例如策略功能等。根据其收集到的数据，拓扑管理器或许还不能了解到整个网络。为了创建一个全局的拓扑结构，拓扑管理器可能会通过对等体拓扑管理器的API，从其他拓扑管理器那里获得一个互补部分的拓扑视图。

8.8　小结

拓扑结构是应用程序所需的多种信息中的关键部分之一。本章探讨了拓扑结构，并试图强调其在SDN中的重要性。

虽然本书无法涵盖SDN服务所有可能的示例（如策略等），但这里把拓扑展现作为SDN的一个广泛使用的示例。本章的目的是，与第5章和第9章一起，把SDN作为一种编程/开发环境来展现，并说明拓扑结构如何展现，被认为是编程环境中重要的一个组成部分。

如果单一的SDN控制器方案/体系结构代表自己作为SDN的主宰者，但又仅拥有拓扑结构的有限视图，这就限制了SDN的视图仅是网络世界的子集。这个难题的最新示例就是OpenFlow的控制器范式，目前仅通过LLDP学习二层拓扑，至少也算是理解底层传输网络的一种抽象视图。这个示例也清楚地说明为什么通用的和抽象的拓扑结构是必要的，以便形成最灵活和最普遍适用的解决方案。

本章通过回顾历史上OSS/拓扑交互的局限性，以及通过LLDP、BGP–LS、ALTO以及IETF 的I2RS 工作组的最新工作，是否可以这样说，拓扑结构作为服务这种需求已经经过了实验、试运行和现实部署的磨练。这种演变同样是SDN的演变，从专有系统演变到面向服务的系统，（并希望）能演变为开放的和现代化的北向和南向接口。

与网络拓扑领域相关的，是在存储体系结构（工具和模式）之上的多层拓扑及其工具方面的工作。例如，可以再用一章来介绍Neo4j、Titan、Jung、TinkerPop等工具集，以及总结或参加各层视图的API。

在本章中，希望所讨论的拓扑结构概念不仅是节点和链路，而是一组与节点和链路以及处于不活跃或休眠状态的网络组件相关的丰富信息的集合。也希望读者能对此留下印象，即需要用现代化的、对应用友好的接口来访问拓扑信息，例如第5 章描述的这些接口。例如，过去的一个明显的错误是一直要求应用程序去实现路由协议，以便能参与到路由协议中学习网络拓扑，或通过某个实现了路由协议的代理来访问路由协议信息。说明了为什么这对现代应用程序的程序员而言是不想要的和不理想的。

在这个领域里，人们有许多热情，但也仍有大量的工作要做。网络拓扑领域有一个很重要的任务需要推进。这就是，为SDN框架内的多种拓扑结构来源而定义数据模型。这需要对拓扑结构进行标准化和归一化，无论是提供给网络的，或者是提供给应用程序的，都要使这些操作具有普适性，否则就会费时费力。在I2RS这节中描述了这一点，并强调在SDN的广泛努力中，这是相对重要的。如果SDN的各方面技术不能依赖于标准化的拓扑结构，则SDN上更大的努力就不会获得本来可能获得的成效或影响力。

第9章　构建SDN框架

9.1　引言

软件定义网络（SDN）的概念或许可以追溯到2007年至2008年，那时首先出现了Nicira公司/VMware公司、NOX 控制器，其他相关大学也在付出努力。自那时起，SDN作为一项新技术开始不断发展和进步，但各种专有的控制器之间仍然有冲突，且对于其间的互操作性没有确定的计划。更糟糕的是，这种控制器间互操作性的缺乏（或者说控制器之间如何通信尚难确定），阻碍了网络运营商、控制器厂商或第三方软件公司所构建的应用程序无缝地跨不同控制器平台的执行。到了2013年，已经有了许多控制器和控制策略，但均不能（至少不能轻松地）协同工作。这当然是一个需要解决的问题，作者认为可以通过在开源代码基础上定义一个SDN框架来解决，这不仅能确保其语法的正确性，而且能确保其语义的正确性。然后，该框架及其配套组件，如协议或协议扩展，就可以被标准组织（如IETF）进行标准化。

本章将介绍并描述一个能把控制器整合在一起的理想的SDN框架。该框架首先来自于作者在瞻博公司（Juniper）所做的概念验证工作，现在也以一种略微不同的形式，成为OpenDaylight Project（OpenDaylight 项目，ODP）控制器框架的一部分。作为ODP框架的一部分，它也反应在ODP用来构建一个行业标准的SDN控制器的开源代码库上。通过这种方式，作者认为工业界有了明显的进步，在解决完成SDN关键承诺所面对的最大挑战之一：应用程序和网络之间更紧密的集成。

9.2　先写代码，再问问题

公平地说，厂商们首先关心的是做系统，然后才会关心互操作性的问题。有的厂商公开地疏远标准化，声称标准化会阻碍创新的速度，或甚至更糟的是，标准化将产出那种对新型SDN实际上不感兴趣的老厂商们所做的那种控制器。结果就是，没有厂商为应用程序来开发开放的、基于多厂商标准的北向API，或提供开放的、基于多厂商标准的控制器间状态分布接口。一旦控制器产品开始离开测试和认证实验室环境，并开始考虑在实际中部署，问题就出现了。控制器还缺乏对多厂商（例如来自不同厂商的OpenFlow控制器）或跨管理域（假设厂商相同，但却是两个独立的数据库）的同类状态目标进行操控的能力，这都是实际存在的问题。此外，南向的控制器与设备上的代理间的协议还缺乏基于最终标准的方案，这意味着每个人都会面临抉择，控制器需要与每一台部署的交换机做互操作性认证测试，而如果以后考虑换交换机了，又要再次进行测试。当这些控制器被考虑用于集成到运营商或企业网的运维支撑系统，来配置和控制他们的整体网络时，这些问题就会令人头疼了。最后一个障碍是缺乏应用程序可移植性，这是未能建立标准化北向SDN API的一个直接后果。也就是说，那些依赖于控制器与网络或网络服务进行交互的应用程序，都需要针对所选的控制器而分别编写。SDN所宣称的操作软件、软件应用、网元设备之间更紧密的互动，所导致更低运营成本的好处，就突然被置疑了。

为何说一个标准化框架以及事实上实现该框架的代码库很重要？我们来看一些示例，如OpenFlow 交换机如何进行端口管理。在一些情况下，可能出现有关端口所有权的难题，例如控制授权。尽管在仅采用单一南向协议时，即前面一章中讨论SDN控制器中的主流方式，这个问题也存在，但是当需要多个控制器时这一问题会更严重。

例如，在OpenFlow控制器模型中，如果用户选择厂商A，因为它提供一个较好的服务编排应用程序来控制数据中心交换机的端口，然后又选择了一个能提供所需的虚拟网络tap（流量分流）应用的厂商B。两者都试图对同一台交换机进行编程，那么这两个厂商的控制器间对转发表的控制该如何进行协调？更糟的是，由于两个SDN 控制器厂商都没有基于标准化的北向API，甚至北向API 也没有事先的约定，因此厂商A 提供的服务编排应用程序很可能会无法与供应商B 的控制器沟通，至少无法完全沟通。反之，对于虚拟网络tap应用而言也是这样。从本质上说，这可以归结为缺少传递状态的互操作API，或缺少仲裁控制1。

1.事实上，当前的OpenFlow模型还不支持这些技术。目前的模型下，刚才谈到的这两个应用程序中必须有一个用另一控制器厂商的API来重写，这样才能达到协调。

其他后果是控制器采用单一（南向）协议，导致控制器上可用的服务很少，特别是在网络拓扑方面。这是因为大多数SDN控制器/代理协议，仅获得单一产品所提供的抽象层的网络拓扑：二层/MAC/FIB、三层/RIB/LDB，或四层及其以上的层/服务。其结果是无法获得网络范围的整体视图。这个整体网络视图对某些网络控制应用来说太关键了，例如对第4 章中所讨论的基于服务器的PCE 或网段路由（segment routing）这样的应用所需的视图，目前就提供不了，导致这些解决方案根本没用。

最后，缺乏互操作性这个问题意味着，SDN控制器集成到混合运行环境中的能力很有限，因为缺少一个“万能胶”（glue）式的应用程序来进行不同端口之间的仲裁。例如，在数据中心网关上，用VMware/Nicira公司SDN系统控制的VxLAN叠加网来给VPN/VRF订阅者提供服务，就需要一些自动化，这可以通过基于NETCONF的应用程序或服务开通配置脚本来提供2。图9-1展示了一个类似的场景，Big Switch公司的Floodlight控制器和Trema控制器都提供了应用程序必须与之互动的不同的北向API。这两个控制器都没有向应用程序开发者提供写代码用的一致性接 口，也没提供对底层交换机的相同网络抽象，也没提供如拓扑结构等其他服务。

图9-1：Big Switch公司的Floodlight控制器和Trema控制器，都提供了应用程序用来编程的不同的北向API

2.对于一个已经在业界有一定地位的厂商，解决方案是显而易见的：“请在你的平台上支持我的代理或我的API。”那么问题就变成可以合理地支持多少个代理，以及网元设备厂商是否愿意和有能力支持这种解决方案。

一些控制器环境，不仅支持现代开发语言（如Python）和编码方法（例如Eclipse开发环境），还提供强大的尽管是专有的框架来支持和鼓励应用开发。这些环境包括文档充分的用于编程的API 和调试/测试工具的API。确实，大多数控制器支持这些属性的某种组合。但问题是：这些控制器如何适应新的或额外的服务，包括对控制器的现有应用服务能力的增强，或控制器的交叉编程能力？归根结底，如果SDN真的是只为应用服务的，那么回答这些问题就至关重要。再进一步，人们还会追问，这些控制器厂商是否真的关心应用，难道不是所有控制器都说选择了开放性、互操作性和模块化作为技术方向吗？这在网络行业并非没有先例，甚至在SDN的解决方案领域也有先例（例如OpenStack）。

这种观点（认为SDN控制器不应该是一个单协议的产品，而应该是开放的、模块化的，并专注于为应用程序开发人员提供服务）推动了SDN控制器的定义：网络应用开发框架。这就是为什么说该框架与网元设备的结合将促进并带来一个终极目标，即快速开发可以无缝地、迅速地、有效地与网络和服务互动的应用程序。

由于框架概念演变中所设想的SDN 控制器的服务是如此需要支持，控制器也从单一的设备或简单的多设备联合，变成设备和托管这些服务不同组件的虚拟机所组成的系统。这些组件可以联合起来，并通过一个网络编排系统协调为单个系统。下面将探讨这意味着一个怎样的，以及将如何演进的SDN框架。同时要注意，框架的概念也在不断演变，正如框架里的这些SDN技术也在不断演变一样。

9.3　瞻博公司的SDN框架

2011年年初，即在2012年收购Contrail系统公司之前，瞻博公司提出了SDN不应该只是一个控制器，而更应该是一个组成控制器的框架，该框架支持各种服务要素，并把这些要素组成系统。更重要的是，该项目的目标是展示系统该如何正确组合在一起，最终支持网络应用程序和网络之间的紧密反馈回路，从而支持人们所盼望的SDN的“圣杯”：网络可编程性。

瞻博公司展示了一款基于Java的框架，采用一个RESTful API，作为快速建模环境，为开发新的、有用的网络应用程序提供帮助。一个简单但绝妙的脚本界面被用来增强API，将其与SDK的概念融合。其基本理念是，传统控制器的基本网络应用服务组件（例如，拓扑结构、路径计算和路径配置）可以有多个服务源。各个服务源通过一个插件式体系结构来提供服务，通用插件模型的定义可以在未来继续扩展，以适应未来应用程序的需要。其所创建的广义的应用服务，还可以提供自己的北向API来对南向插件能力进行抽象。从这个意义上讲，应用程序可以递归地定义其他服务可使用的或与之交互的新服务。

控制器系统没有存储接口，其作用与服务总线类似。Junos CSPF算法（转换成一个Java applet 后）提供的路径计算服务被用于支持Junos 的设备。该算法通过插件基础设施来访问。路径配置服务通过多种南向协议来提供，并通过这些南向协议关联的插件来访问，如图9-2所示。这些插件包括NETCONF（通过NETCONF驱动程序） 、路径计算单元（PCE，通过一个基于Java的PCE服务器）和OpenFlow（通过为Big Switch公司的Floodlight控制器所编写的插件）。拓扑服务也通过多个插件提供，包括：使用基于Java的BGP-TE客户端的BGP-TE/LS、ALTO（客户端和服务器模块都有）和实现系统快速和方便配置的静态文件导入功能。OpenFlow的控制器还有一个拓扑采集插件，提供了当前OpenFlow控制所必需的基于LLDP的拓扑。

图9-2：瞻博公司的SDN框架的概念验证

瞻博公司所展示的概念验证的应用程序称为带宽时间规划应用（BCA），这将在第10章中具体探讨。顾名思义，带宽时间规划应用通过一个示例或相对静态的网络实现一个基于应用程序的带宽预留。带宽预留可以是基于未来的需要，或者当前的需要，可以给出终止时间（即持续时间），也可以没有终止时间。这是研究网络和一些大型的Web 2.0网络运营商中很普遍的应用。

该应用展示了框架的模块性。

- API使应用程序并不在意，在其所选路径上的网元设备，是否支持OpenFlow，或是否支持MPLS LSP操控的PCE。这可以通过运营商，或通过在应用程序中用API来指定其偏好来实现。

- 虽然这不是归一化的拓扑结构，但通过对活动网络拓扑的支持，带宽时间规划应用采用BGP-TE 和OpenFlow来主动获取网络拓扑信息。在纯MPLS网里， PCE配置适应已经使用的流，在分布式流量工程数据库（TED）里对预留进行维护。每当一个LSP被更新或创建时，TED都通过BGP-TE/LS客户端来更新。在混合网络中，应用程序必须管理OpenFlow段上的预留带宽。

- 网络拓扑可以通过使用OpenFlow的配置支持和MPLS NETCONF/Yang模型来进行扩展，这是瞻博公司的专有功能，即通过NETCONF插件来关闭/开启其他网元设备上对MPLS或OpenFlow的支持。

带宽时间规划应用的真正要点是，API提供网络可编程性。这里展示API的两个示例。第一个示例是基于Guava的可视化应用程序，它表现得像一个传统的类似于OSS的主控台，呈现了OpenFlow 和PCE的拓扑组合，以及系统内预留的带宽。该系统将允许应用程序使用编程接口对带宽预留进行编程，以及询问预留带宽的状态和网络路径。第二个示例是嵌入到API里的Java小程序（applet），模拟了视频点播应用。其他的应用程序可以与这个API进行交互。

在概念验证的后续阶段，这个小程序被从其运行的与测试拓扑的多个域相连接的服务器上，移植成为一个Android平板电脑上演示的Android应用。这有效地证明了消费者也可以使用这种API，也显示了网络运营商也可以使用iPad和Android应用程序来管理网络并与之互动。

对于这种应用，由于客户端不能处理大型网络拓扑，ALTO客户端/服务器交互被用来限制网络拓扑，为平板电脑上的应用程序形成所需的摘要。实际上，ALTO服务器将把这个对路径的搜索安排到最适合的服务器上，这会在第一个步骤——ALTO查询——中解析。这一点与大多数应用程序的需求一致，即最经常想查看的不是整个网络的拓扑，而是一个抽象或过滤后的版本。更多的细节内容详见第8章。

本试验的一些经验教训如下。

- 拓扑结构是从网络提供给应用程序中的基础数据资源，多个来源的拓扑结构的归一化是很难的，特别是当这些拓扑分别代表多个网络层时。如果这些层是虚拟化的或者采用了某种抽象，则尤其如此，例如查看第一层（即光网络）的拓扑结构时。此结果推动了一些IETF在拓扑上的工作。

- 策略似乎是一个基本的应用服务，因为它嵌入在生成的每个应用程序中。

- 在结构上，该框架可以设计得更好。例如，API应该可以是自我生成的，这被其他一些较新的方法实现了。这个称为数据驱动的方法已经在第5 章详细讨论过了。

遗憾的是，由于种种原因，虽然曾经讨论过将带宽时间规划应用在OpenDaylight项目中产品化，或讨论过作为Contrail控制器的应用程序，但瞻博公司却最终从未对带宽时间规划或其框架进行真正的产品化。

瞻博公司的POC（概念验证）框架，以及随之而来的IETF 框架，可以描述为一种中介。与之不同的是，许多控制器策略都把这个概念定位为网络操作系统（Network Operating System，NOS），以替代分布式路由协议，以代表定义网络服务的应用程序来监督被管网络设备的数据平面。而在中介模型（broker model）中，应用程序与网络通过中介来交互，使应用或网络可以更有效，达成SLA目标，或提供更好的终端用户体验。这两种模型之间的明显区别在于，应用程序的类型，也就是体系结构对于业务的意义（即解决方案的宽广度不同）。

9.4　IETF的SDN框架

在2012年向IETF提议成立SDN工作组，人们就提出了基本框架（Framework）的概念，特别是在“基于应用的网络运行”工作组（Application-Based Network Operations，ABNO） 和“ 软件驱动的网络（ 协议）” 工作组[Software-Driven Network(Protocol)] 或称为SDN（P）工作组的提案中。迄今为止，这些工作组提案都还没有在IETF获得进展，但其概念已经被引入了一些IETF 工作中（例如，“路由系统接口”工作组，或称为I2RS工作组）。此外，这些早期的努力都体现了瞻博公司在制定POC 框架的道路上的显著进步。

9.4.1　SDN（P）

软件驱动的网络（协议）3是一个在IETF提出的工作组提案，旨在探讨和界定SDN问题空间里的协议、体系结构和用户案例4。体系结构标准草案突出了刚才所描述的 框架概念5，并提出了对瞻博公司的框架里所缺失的额外服务组件（例如策略）的需 求。事实上，该工作的框架中，至少有一部分灵感来自于瞻博公司的SDN框架。

3.http://tools.ietf.org/html/draft-nadeau-sdn-framework-01
4.http://tools.ietf.org/html/draft-nadeau-sdn-problem-statement-01
5.http://tools.ietf.org/html/draft-nadeau-sdn-framework-01

SDNP体系结构（如图9-3所示）提出了一个服务编排器（orchestrator）的概念，作为系统的控制和协调点。这里的编排与数据中心里作为控制平面控制器的服务编排（即OpenStack的服务编排系统）的应用有些不同。这个角色也与当时还很简单的OpenFlow控制器有些不同。这个控制点是充当混合的外部控制平面的软件，带有其他协议如南向OpenFlow的能力。事实上，这在很大程度上是ONF提出混合OpenFlow模式的根本原因，但后来这个模式被ONF拒绝了。该实体被定义来操控不同的插件式南向协议的目标模型，每一个南向协议都要产生一个自我描述的、还可用来生成北向API的对象模型。这些概念后来多见于较新的商用控制器产品，包括使用自生成API 的数据/ 对象模型，最近已针对OpenDaylight项目的控制器提出。

图9-3：IETF的SDNP框架设想

此外，该提案提出了一个计划，以原理化或归一化这种控制实体与插件间的通信，这些都是形成插件贡献模型的本质。最后，提案考虑了这些编排软件之间的联盟或横向通信，这实际上是一个消息总线的概念，而这仍然是今天大多数控制器里所没有的。

可惜的是，这种努力由于种种原因领先了它的时代。首先，IETF不明白如何理解SDN概念，所以无法弄清楚该把这个工作放在这么多领域（Area，即IETF的工作组集合）中的哪一个里。其次，存在来自ONF的大量阻力；当时刚成立的ONF在尽量抢占它能抢占的所有地盘，因此宣称可以处理这些概念。很遗憾，事实证明，ONF的宣称有点过于乐观了。IETF最终找到了办法形成了一个工作组，进行网络拓扑编程和基于策略的路由系统编程工作，这些编程要素第一次在这里得到讨论。这个工作组现在称为路由系统接口工作组（I2RS）。许多其他领域的工作正在被OpenDaylight 项目接管。

9.4.2　ABNO

基于应用的网络运行（ABNO）6框架（如图9-4所示）作为一项提案最早出现在IETF 的路由领域（Routing Area）工作组，建议以现有工作扩展到PCE工作组，甚至是形成一个独立的工作组。在该提案中，对组件之间所建议的接口的关注比SNDP提案要少。相反，该工作组采取策略，把重点放在一些组件的作用上。这样就避免了IETF中很多人都不理解的术语“SDN”，因此也就不会像瘟疫一样被人们所躲避。

图9-4：通用的ABNO体系结构

6.http://datatracker.ietf.org/doc/draft-farrkingel-pce-abno-architecture/

该框架重申了策略在框架中的必要作用。该建议超越了一个简单PCE服务器，可以适应多种南向配置接口，包括：PCE、OpenFlow、SNMP（如与旧的OSS/BSS系统的接口）、NETCONF和ForCES。它也支持I2RS工作组建议的类似接口。

- 一些ABNO框架的独特创意来自对PCE的关注。

- 它包括了通过OAM管理器来进行故障排除、调试、审计或验证工具的需求建议。

- 此外，它还引入了一个新的组件——虚拟网络拓扑管理器（VNTM，参见RFC5623）。PCE可用于创建基于二层或三层的LSP，以及使用GMPLS机制的底层光传输系统的LSP。VNTM 用于归一化网络中各层之间的虚拟拓扑结构，此概念已经在第8章中介绍过。

拓扑结果通过清单（inventory）信息来增强是从I2RS借用的想法。ABNO控制器组件处理从传统的网管系统/运营支撑系统（OSS）而来的管理请求，并对分层的PCE或域间的PCE进行PCE仲裁。通过这种方式，它允许PCE控制器的联盟和协调。它也形成了一种方法，使它有可能被插入到一个更大的服务编排系统中，如一个OSS，甚至是一个OpenStack的服务编排平台。

9.5　OpenDaylight的控制器/框架

缺乏标准的用于控制器的SDN北向API、缺乏对混合操作模式的支持，以及需要定义上的扩展（例如SDN 南向协议是否能超越OpenFlow），这些问题于2013年年初进入了工业界许多著名的设备和控制器厂商的脑海。这些问题曾被提交到标准组织如IETF 来定义，但其尝试都失败了；同时，ONF实际上并不愿采取认真的态度来应对这些问题，以推动工业界把注意力转到此新方向。正是在这个时候，许多公司（包括思科公司和国际商业机器公司(IBM)）开始讨论如何形成一个开放源码的SDN控制器项目，以创建一个共同的控制器的基础设施，作为载体来克服刚才提到的这些问题。2013年2月，OpenDaylight项目（ODP）联盟7作为一个Linux基金会项目形成了8。

7.http://www.opendaylight.org/announcements/2013/04/industry-leaders-collaborate-opendaylight-projectdonate-key-technologies
8.这个消息一经发布，ONF紧接着就宣布他们也将致力于标准化的北向（应用程序）API。

因为最终目标是应用程序的可移植性，所以该组织计划创造一个共同的SDN控制器的基础设施，以拥有一个良好定义的（并且最终是基于标准的）北向API，并支持各种南向协议。OpenDaylight 项目的结果将是为SDN应用程序创建一个开源的控制器/框架，同时也事实上创建用于对不同的南向协议（包括OpenFlow、I2RS 和NETCONF）进行编程的北向接口。

该项目的根源是知识产权、经费和以多个公司提供开发人员的形式所表现的工程资源。它试图在最先进的控制器/框架中，吸取过去在控制器和框架的探索中得到的教训，并最终用以增强网络的可编程性。

虽然估计一些厂商可能会继续提供专有控制器，但极有可能来标准化这些采用ODP的代码的控制器的基础设施，就像Linux已经实现的那样。由于任何厂商都可以自由地在其核心基础设施上封装自己的专有/增值产品（或者作为一个插件模块，来支持OpenDaylight的应用程序API以直接支持互操作性，或者仅仅提供产品化的技术支持），预计未来将有一些ODP控制器的企业版本。长期来看，这些贡献可能出现在对东西向接口的标准化上，用于OpenDaylight和其他控制器解决方案之间的网络运行状态交换，以及在运营域内或跨管理域增强控制器联盟之间的互操作性。

因为很多技术都直接借鉴其前辈技术，所以OpenDaylight框架（如图9-5所示）是非常模块化的、基于Java的（即一个纯粹的Java 虚拟机），并支持双向REST和OSGi框架编程。这将支持在相同地址空间中运行的应用程序作为控制器的应用9。

图9-5：OpenDaylight的理想化框架/控制器

9.http://www.osgi.org/Technology/WhatIsOSGi

目前，ODP非常注重服务。一个服务抽象层（Service Abstraction Layer，SAL）把内部和外部服务请求映射到适当的南向插件，并提供建立更高级别抽象的基本服务抽象，而这依赖于插件的能力。

这种服务的一个例子就是数据分组处理服务，可以让像ARP这样的应用程序处理对发送/接收特定分组类型的兴趣进行注册，而不必知道可能会提供或发送这些分组的各个插件的方法或功能。其他有意思的且重要的内置服务包括拓扑抽象和发现、PCE-P（和CSPF）、OpenFlow、I2RS（随着它的发展而加入）以及NETCONF。

虽然在早期阶段，一些提案作出的贡献已包括先进的功能，如虚拟化管理套件（可用于构建和跟踪叠加网络）。另一个重要提案的贡献是网络功能虚拟化（即服务链）的控制。所以可以看到，我们完全有可能开发一个非常复杂和功能性的控制器，以在其上快速构建非常复杂的应用程序。

9.5.1　API

OpenDaylight项目的一个体系架构任务是通过多种协议插件，使北向API匹配南向API的一些合理的子集（参见图9-5）。OpenDaylight的一个提案就是基于Yang的高级数据模型编译模式，以用于自动生成或更新代码的API，而且具有在运行中动态地移植目标模型中新的部分的能力。这是非常酷的功能，因为这样一来便不再需要重新启动控制器。这种模式还允许动态服务模式发现机制。这种动态发现机制，无论应用程序与控制器已经连上还是正在连接时都有效，因此潜在地允许应用程序通过读取改变了的或更新了的模型，而进行动态调整。有些人设想的应用程序，甚至能够根据数据模型的变化自动生成（或重新生成）大量内部代码，而这仅需在检测到变化时重新访问模型。虽然这个数据模型的用途还达不到前面第4章中提到的那个目标，即一个SDN控制器或框架可以被看作网络的编译器，但将来很可能做到通过一个编译器从数据模型来生成对网元设备的配置。在这个模型中，高级数据模型允许应用程序或操作者简单地表达其意图（intent），然后控制器通过把这个意图编译到原语（即代码）里来执行。

这么做的一个诱人之处在于用反向编译帮助进行故障排除。也就是说，如果编译后的数据模型就是把意图转换为网络状态，就应该能够通过逆向处理发现不能被映射回当初意图的网络状态，或者说可以通过编译检测出其他潜在的问题，如无效配置等。理论上，这也可能成为一个很好的策略执行和/或操作故障排除的工具，让运营商能在实际配置到网络之前就能看到问题。

然而，对高级数据模型和低级数据模型之间的每个交互都进行编译来实现网络原语，可能导致对性能的影响。特别是，如果变化过于频繁，发生变化后对网元设备进行编程花费太长的时间，这就可能会带来问题。例如，如果系统依赖于实现前面描述的应用程序、控制器和网元设备之间的反馈环路，那么这个过程花费的时间越长，整个系统对失效或其他需调整的情况的反应就越慢。

OpenDaylight项目对数据模型的使用较为简单。当使用OSGI模式时，每个模块自己发布其API。新模块的API可以被任何其他感兴趣的（已经在运行的）模块使用。这意味着， API版本控制方案将是整体框架的一部分，因为API的版本可能在加载/卸载周期之间发生变化。希望刚才所描述的动态加载对象模型可能有助于这一点。ODP的控制器框架体现了用松耦合的服务总线的概念，把内部模块连在一起。简言之，就是并非一切事务都要访问存储，以便提高性能。这种方式适用于基于Java的控制器的一个例子，可能是使用发布/订阅和支持JMS （Java 消息服务）API的Java消息服务来提供服务。在这种情况下，JMS提供者可以同时支持发布和订阅和异步消息域。不过说到底，网络状态总还是要存储在某些地方，可以存储在内存或永久存储器里。

9.5.2　高可用性和状态存储

ODP实现了一个基于集群的高可用性模型，用于状态和事件同步。在其原来的模型中，控制器在内存中保存一切内容，并使用JBOSS的Infinispan进行复制。框架项目之一就是建立一个框架的后端，以提供分区容错的存储。问题根源在于大多数（不基于内存缓存的）SDN控制器的数据库同步策略。最新的控制器设计在尝试使用非关系型数据库（即NoSQL）来存储网络状态，而不是内存缓存方式（在传统的开源控制器中的内存缓存），或高度集成的服务编排中所使用的关系型存储。最近控制器的发展趋势是，利用Cassandra作为网络状态的分布式“键-值”存储来支持高处理量，利用Zookeeper来做分布式单元发现/跟踪/配置管理。

非关系型数据库在水平方向扩展上特别好（数据库单元或碎片，可以分布到不同的处理器和物理磁盘存储上，同时对外表现一致）。以这种方式，NoSQL的方法也可以用在网格文件系统中。当应用程序不关心业务行为，而只关心一致性和可用性模式时，这种方式特别有用。但是，业务处理可以通过Zookeeper来支持，也可用于加锁服务，作为加锁管理器来支持Cassandra中的读/写协调。其他开源产品也有相同的作为“键-值”存储的相对性能，以及关系型数据库的灵活性。

通过正确的参数，分区恢复可以实现在像Cassandra和像CAP法则10这样“最终达成共识”模型的数据库中。有的应用程序可能无法在“最终达成共识”模型的数据存储（如Cassandra）中得到容错，可能需要另外的存储接口或功能。

10.有许多关于开源数据库（特别是NoSQL数据库）中启动应用程序开发的经验的好文章可供参考。其中一些文章探讨如何在一致性、可用性和分区的回避/恢复之间进行权衡，这些是在CAP理论中表述的。示例：http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/。

9.5.3　分析

如果SDN的目的是把网络信息展示给应用程序，那么展示给应用程序开发人员的最重要的两个网络信息库，就是有关网元设备和服务的一些可被利用的特性信息。例如，典型的链路和资源信息可以被用来衡量整个网络的预期或实际应用性能。当这些信息与拓扑结构结合，就可以得到有趣且非常强大的效果。例如，在拓扑的多层之间可以交叉引用的组合数据库，用一个服务层在拓扑内进行资源定义，当交叉引用一些性能数据时，就可以判断是否需要重新优化网络。

无论是OpenDaylight控制器/框架，还是许多其他最新的控制器，都确认它们在管理虚拟化基础设施中的角色，即把统计数据收集和事件通知融入到其管理会话的数据中。它们都试图做主动的拓扑发现，尽管拓扑可见的层次是有限的。由于拓扑是用来分析的数据源，控制器/框架需要提供API来支持对这些数据的访问。独立的网络分析系统已日益普及、广泛部署，因为它们可以帮助解决网络运营商的一些运行问题。由于网络分析的目标与SDN的目标和功能很一致，因此许多最新的SDN控制器策略，也都自然地开发出了分析服务或分析应用程序。这些应用程序通常包含一个信息收集器、规则引擎/处理器、存储后端、可视化模块，以及一些查询接口。对信息收集的管理，尤其是对所有流数据的收集，对SDN 控制器造成了多方面的可扩展性问题，包括输入/输出、存储和处理等方面。其中大多数问题引起了对总控制会话数的限制。对流数据进行压缩通常是这些系统的功能之一，一个显著的问题是，网格计算形式的分布式处理（参见图9-6）是否适用于解决这个问题。这种网格计算如何集成到控制器里11以及集成在控制器的何处，则是另一个话题了。

图9-6：Guavus公司对于分析数据压缩问题的网格计算方案

11.今天已经有独立的、基于网格的分析系统可用，例如Guavus公司等所提供的基于网络的分析系统。

传统的关系型数据库对于系统产生的海量数据而言实在是太慢了。较新的NO-SQL数据库虽然并没有在独立的网络分析应用程序中普遍应用，但因其在其他大型数据存储应用中表现出的可扩展性和性能，可能会在数据分析中的得到应用。值得关注的是，这种数据库技术的变迁，已经在新一代SDN控制器的网络状态存储中展现出来。

正如上文所提到的，SDN中对网络分析的需求超越了基本的分组计数或传统的统计数据，这些信息只有被进一步合成流信息时才有用处。具体来讲，这些信息需要合成和关联起来，以便能用来描述SDN控制器所管理的虚拟化的或叠加的层次。传统的网元设备（例如路由器、防火墙、交换机、网卡等）的端口分组计数器可以展示链路的整体利用率，但必须把这个统计信息关联到一个特定的虚拟端口或一个虚拟机。在虚拟化环境中，如果把虚拟机关联到一个特定的虚拟端口和一个特定的流或流的集合，这一点是可以做到的。

把流数据返回给用户客户端，对故障排除来说很重要，因此可能需要为服务编排系统提供一些回调函数或API。因此，我们要把提供API的例行程序纳入到底层的网元设备中，作为网元设备厂商与服务编排系统/SDN 系统厂商之间独有的API 访问安排。实现这样的功能，对于通过传统方式（Netflow、JFlow、IP-FIX）来提供流信息的传统网元设备来说比较困难。但这些传统方式采集的流信息的颗粒度还不够细，无法关联到虚拟机，至少是不容易关联到虚拟机。

链路利用率与拓扑的组合可能会导致强大的新应用，其中大部分利用“服务开通配置/分析/化”这个典型的SDN反馈回路。第10章讨论了一个把此反馈回路与大数据组合起来的示例，即广域网中的一个潜在应用：即时CSPF。一度有研究表明，收紧这个反馈回路或许能帮助解决由于在现存硬件（即能力较差的硬件）上引入新的流表所带来的可扩展性问题。例如，当不基于TCAM的硬件转发体系结构上支持OpenFlow时，人们发现控制器不得不担负大量的故障检测和响应的压力12。

12.参见http://conferences.sigcomm.org/sigcomm/2012/paper/hotsdn/p19.pdf（以及其他许多参考文献，如http://www.sigcomm.org/ccr/papers/2012/January/2096149.2096152，该网站可能需要订阅ACM 的论文 数据库才能查看全文）

网络分析和大数据在数据的采集和后续处理与分析这个范畴内正在被关联起来。例如，Splunk产品13接收和分析统计数据，并将其存储在称为索引的无结构文件中。Splunk促成了许多开源软件使用其API；例如Shep，它把Splunk的数据引入到Hadoop环境中，以进一步处理该数据。一些网络分析产品提供了触发/响应机制，这对在数据中心缓解Incast/微流突发（Microburst）问题的应用程序很有用。

13.参见http://www.splunk.com/ 和http://blogs.splunk.com/2011/12/05/introducing-shep/。

Incast出现在如下场景：当对数据或命令集合的一个请求发给很多个目的地时，就会在很短的时间内，从这些目的地发出突发的大数据/流量返给该请求者（如图9-7所示）。重叠后的突发流量变大为原来的N倍，这会导致延迟瞬变、交换机丢弃队列尾的分组，或者干脆在此路径上丢包。

图9-7：Incast/微流突发问题

9.5.4　策略

网络分析也可以驱动或有助于网络的策略控制。在框架的演变中经常要回归到策略，即把策略作为用来驱动或管理运行操作的组件。虽然OpenDaylight项目已经是最接近于完整的商用或开源框架的一个产品，但其初期的体系结构看上去还缺少一个策略组件。值得庆幸的是，随着体系结构的模块化，把策略模块添加到服务框架中是相对容易的，而且在不久的将来估计就会被提出来。

9.6　小结

本章旨在通过介绍几个框架说明在SDN控制思维上的演进，并总结目前对于理想控制器的思考。本章并没有试图像第4章详细介绍控制器范式那样深度地定义控制器。本章意图说明一个精心设计的控制器背后存在一个深思熟虑的框架。控制器不仅以这个框架为基础，而且将来也要在这个框架上继续开发。

SDN框架应该像一个控制器设计的体系结构蓝图。为此，本章提出并定义这样一个理想化的SDN框架，希望将来被控制器厂商和开发者们使用。本章描述了这个框架的关键要素，包括北向和南向的API、动态编程环境，以及状态存储方案的重要性。

本章表述了策略和网络分析的元素，以及它们如何在框架和良好的控制器实现中发挥自己的作用。

本章还讨论了为什么控制器/框架的演进就是对控制器实体的意识形态目的的演进：控制器是做网络操作系统，还是做中介/编译器。

关于本章所涉及的SDN本质还存在一些争议。特别地，SDN的本质是否实际上就是关于应用程序和网络之间的双向通信，还是SDN的本质可以是一个通过动态地使用策略来表达的反应模型（reactive model）？

作者认为SDN应该是双向的（参见图9-8）。作者认为，SDN的主要原则之一是：应用程序、SDN控制器以及它所控制的网元设备之间的反馈回路。这涉及网络可编程性，或者说，如何对控制器进行编程，让它充当它所控制的网元设备和应用程序之间的代理。

图9-8：SDN为应用程序和网络之间的双向管道

第10章　带宽调度、操控和时间规划的用例

10.1　简介

带宽时间规划（Bandwidth Calendaring）是一个用例的类别，这些用例1的核心都体现了基于时间的带宽操控的概念。在这些场景下，带宽操控指的是增加、减少或者修改网络的带宽。需要控制网络带宽的原因或者触发因素非常多样。包括为了让带宽更好地匹配流量的模式、服务的需求和中断，或者预先为未来的改变作出规划，比如容量上的改变。这里有一个共同的主题，就是它们都涉及某种时间周期。事实上，不仅是带宽随着时间而变化，之所以这样控制带宽，也是出于对使用某种规划，而非手动控制带宽的一种需求。下文将对此一探究竟。

1.参见http://conferences.sigcomm.org/sigcomm/2012/paper/hotsdn/p19.pdf（以及其他许多网站，其中一些参考http://www.sigcomm.org/ccr/papers/2012/January/2096149.2096152，这个网站可能需要订阅ACM的论文数据库才能查看全文）。

本节从简单的开始。图10-1的场景中，一个运营商拥有两个数据中心，它们之间通过一些网络链路相互连接。其中一个位于加利福尼亚州的桑尼维尔，另一个位于新罕布什尔州的朴茨茅斯。

图10-1：数据中心互连示例

为了降低用户所体验到的延时和进行灾难恢复，两个数据中心被刻意在地理上分开。为此，每个数据中心都包含了承载和运营该公司网络音乐流媒体服务的虚拟机。当数据中心处于稳定状态时，每个数据中心都拥有一份客户记录、音乐数据库和其他重要信息的副本。各数据中心都与互联网相连，根据每个用户和这两个数据中心之间延迟的大小，提供基于邻近性、低延迟的访问服务。

为了使所有的这些结构对用户透明，并且让这项服务的使用变得尽可能直观，需要对每个VM进行设置，让它们看上去是在进行同样的服务，虽然它们在逻辑上只为用户的超集的一个部分提供服务。当用户访问www.TomsMusicStreaming.com时，他们就会连接到离他们当前地理位置最接近的Web 服务器（当然，实际上这意味着他们只能连接到上述两个数据中心中的一个）。为人所熟知的网络流量负载均衡机制（这里不再赘述）有效地将用户请求分配到不同的数据中心上。因此在概念上，虽然音乐流服务看上去位于用户所选取的任一服务接入点之后，但在任意时间点，这个数据库实际上是由同一数据库的两个子集组成的。服务的这两部分实现（以及虚拟机）也可能为同一个用户提供服务，提供同一首歌曲。

然而，在上述示例里，用户只能获取他们所访问的那个特定的数据中心歌曲数据库中的音乐流。因为Web服务背后，整个数据库的信息（例如用户账单信息）事实上由同一个逻辑数据库的两个部分实现，数据库的这两个部分需要周期性地同步，来保证数据的一致性。这称为数据库复制或同步。数据库复制或同步有多种实现形式，这超出了本用例介绍的范围。但是，任何形式的数据库同步都需要消耗一定的网络带宽，因为数据库的各个部分，不管是文件块、整个文件，还是作为单个文件进行简单拷贝的整个数据库，都必须通过网络来传输。通常，在低负荷或者服务下线时间里运行的就是这种数据库复制或同步任务。在很多场景下，这些下线时间可以和昼夜时间有关联，或者称为昼夜使用模式。

再回到上述示例TomsMusicStreaming.com，假设数据库基本上是在白天被访问。本示例以美国标准时间来考虑，因为它的客户大多数位于美国。同样假设，大部分用户在晚上并不会使用这个音乐流服务。因为不论用户处于什么地点，音乐服务都必须对他们可用，所以必须要对用户记录以及音乐文件进行周期性的同步。人们可以放心地假设服务器和网络在晚上利用率都比较低，并且网络管理员可以选择在这个时间段进行数据库同步。可以很容易地想象一个管理员按下控制台上的一个按钮，或者通过某种作业自动化功能，在某个固定的时刻，启动每晚的备份或同步活动。

在过去，实现上述方案的一个普遍做法，就是简单地设置两个数据中心之间的带宽，使其能够承受住计算出的最坏情况下，两个数据中心之间的带宽需求，然后就大功告成。

但是经过仔细研究可以发现，如果权衡带宽与每比特的开销，并且将之与实际需要的量相比较，那么在一天中的任何时候，从上面讨论的昼夜使用模型的示例来看，这种模型都是很浪费的。举个例子，假设大部分的带宽都是在白天消耗掉的，其峰值的需求占用了85% 的网络资源，但是在夜间，数据复制任务只需要40%的资源，所以在夜间为与白天相近的带宽缴纳费用是相当浪费的。假设TomsMusicStreaming.com可以获取灵活定价的带宽，基于时间需求模型来调整带宽才有意义。就算只能使用固定价格的带宽，关闭或者闲置虚拟机和网络设备资源，也可以显著地优化电力使用，降低采暖或者冷却费用。为了达到这些目的，时间规划（即对路径和带宽进行预留）是优化本用例的方案之一。

在一个更加全球化的背景下，大规模的数据传输和随之而来的预留（reservations）可能会跨越多个时区（国际数据传输），所经过网络的重叠的昼夜使用模式，可能会让人们难以为一个优化的直接传输解决方案而制定简单的带宽预留时间规划。人们可能会找到一个更加经济的存储转发路径（由一系列较短距离的存储转发所组成），但这要取决于应用和商业运作是否能够接受这样的方案。2

2.参见Nikolaos Laoutaris、Michael Sirivianos、Xiaoyuan Yang和Pablo Rodriguez的论文“采用NetStitcher的数据中心间批量数据传输”，Telefonica研究院。

因为路径的可用性、利用率信息和其他较为缓和的因素（带宽成本、策略和资源竞争）之间的复杂关系，为了给带宽时间规划应用中所要保证的效率提供一定级别的精确性和响应性，读者可能更加难以想象，这位虚构的管理员应该采取什么样的行动（手动管理），甚至采用何种作业自动化功能触发的方式。

这样的应用程序可以和前面章节所描述的控制器或框架在一起工作，从网络中提取信息（活动状态），为业务计算已知的路径，管理预留资源，并且在适当的时候提供路径，为连接应用程序的源和目的之间的数据流提供路径。

虽然可能还是同一个管理员通过应用程序GUI控制着那个控制台按钮，但触发这些服务的API调用可以嵌入应用程序本身（或者至少通过某种代理机制），这才是真正的力量所在。正是这种通过编程与网络进行交互的场景，彰显了SDN的力量。

当然，这种交互可以提升效率，这使许多运营商从中看到了一个新的机会，即采用资源调度，在低使用率时间段出售新的业务，来充分利用资源。

10.2　带宽时间规划

现在再来看看带宽时间规划的一个更详细的示例，如图10-2所示。图中是上文所描述的概念上的 TomsMusicStreaming.com的一个真实实现。别了，汤姆！

图10-2：带宽时间规划示例

10.2.1　基础拓扑结构以及基本概念

图10-2所示的拓扑结构中，有五个路由器在日本境内。每个路由器都被放置在特定位置，为运营商的多个租户提供多站点支持。所有的五个路由器都同时支持OpenFlow协议和MPLS/IP（用于演示这个方案如何与多个不同类型的控制器一同工作）。

带宽时间规划应用运行在一个概念上的SDN 控制器或者一个拥有多个可互换的控制器以及其他服务的框架之上。

预留的路径可以采用很多方法构建（或者通告signal）：OpenFlow协议、MPLS标签分发协议（LDP）、路由器计算出的MPLS流量工程（RSVP-TE）路径，或者控制器上运行的PCE-P应用所计算出的PCE-P路径。本节将集中讨论OpenFlow和PCE相关的示例。

在使用OpenFlow的情况下，应用可以被放置在一个OpenFLow控制器（该控制器提供面向第二层的拓扑结构、路径计算和配置服务）上，而PCE的示例则更应该使用一个服务框架（因为PCE服务器上并没有集成拓扑结构服务组件）。

10.2.2　OpenFlow和PCE拓扑结构

为了让控制器和网络中每个设备可以直接通过以太网相连，本书实现了一个单独的用于管理的局域网。虽然OpenFlow确实支持控制器和网元设备之间的带内（inband）连接，但带外（out-of-band）连接则更加常见，并且减少了将控制和数据流量一起混在链路上传输所带来的额外担忧。其他类型的控制器可能不会默认/必须使用带外连接。

一般来说，在本拓扑结构的边缘，也有采用虚拟局域网（VLAN）或原始的以太网接口的数据中心（虚拟机、数据库、租户所需要的服务）和/或一个客户 服务预订者站点的网络。

假设本例的交换机支持IP/MPLS和OpenFlow这两种协议（并且可以设置为混合交换机，同时提供对两种协议的支持），由于传统的MPLS/IP控制平面和OpenFlow控制器对于单个端口的控制是排他的，所以每个边缘路由器/交换机都利用两个或三个链路（在某些场景下，也可能利用虚拟链路）来创建本例的核心拓扑结构。

在这个特定的示例中，构建一个仅使用以太网/VPLS封装的（逐跳OpenFlow流表项机制控制下的）的二层的拓扑结构所需的基础设施，由端口/链路的一个子集提供。

这些端口/链路的另一个子集提供了IP/MPLS拓扑结构（为了说明这个示例，这些拓扑结构可能并不是完全重叠的，这样就允许网络中存在仅使用二层网络的部分）。为了利用MPLS/IP路径，在那些启用了MPLS/IP的链路上还需要一个基于IGP的承载网络。

位于新泻和大阪的节点没有配置/启用OpenFlow传输路径。所有的节点都能够进行MPLS/IP传输。

由于交换机实现混合模式时的一些细节，OpenFlow控制的端口和VPLS实例或MPLS LSP是通过虚拟隧道（一个虚拟隧道的一个逻辑端可以位于二层转发实例上，另一个位于二层或三层实例上）连接起来的。

采用这样基本的配置，跨越核心网络、连接各站点的路径可以采用多种方法建立，所有的这些方法都可以在技术上视为SDN（因为这个示例中的控制平面和数据平面是分开的）。

基础的连接一旦建立，时间规划应用程序，就可以利用可视化界面，或者内置的API调用，来接收为特定客户端数据流提供的带宽预留了。

最基础的API调用可以用一个路径偏好（可选的）、一个路径配置方法偏好（可选的）、和数据流信息（可解析的源和目的地址，流套接字或其他用于匹配的细节）、带宽请求、数据流持续时间和起始时间（可选的）作为参数。请注意，这个API调用默认是立即执行的，这就允许在命令被处理之后立即应用规则。

这个特殊的示例还会演示札幌和鹿儿岛之间的带宽预留/数据流。具体地说，位于札幌的（客户）子网3.3.3.0/24中将会用到视频客户端，客户端连接到鹿儿岛的一个视频服务器（2.2.2.2）。这个带宽预留是不对称的（6.4Mbit/s用于高清视频，提供给源到接收者这一方向；10Kbit/s接收者到源的反向通道，用于维护视频会话）。

补充文件中包含了本章中用例的完整配置，以及关于如何构建一个功能完备的演示的说明，供读者研究。

10.2.3　配置示例

本书绝不是在试图说明构造一个带宽时间规划环境只能够采用瞻博公司的MX系列设备，但这确实是作者搭建的一个可以工作的功能原型。为了体现这个示例的指导意义，在本书的网站上提供了实际的配置文件，网站由出版社提供。这些配置相对来说较为简略，并且可以在运行Junos 12.3I0的瞻博公司的MX80上正常运行。请注意，使用这些配置文件需要用到瞻博公司的SDK。注册并下载SDK，即可获得带宽时间规划应用程序SDK源代码。它提供了一个可正常运行的演示，来让读者进行深入研究。

10.2.4　OpenFlow业务开通示例

记住OpenFlow中的配置和流业务开通模型的工作机制是很有用的。这个机制如下，在控制器和每个支持OpenFlow的路由器之间建立了（TLS 保护下的）TCP会话，随后，OpenFlow消息就可以在这个控制通道上交换传递。配置消息确定了控制器（可能有多个）和网元设备之间的关系，包括数据流保留（retention）行为，多个控制器的主/从分工、端口到控制器实例的映射，以及其他基本的可配置项目。这些配置过程利用了OpenFlow特定的Yang数据模型以及NETCONF协议。3

3.在本书撰写时，ONF配置工作组正在致力于研究一种引导程序，用于自动配置。目前，还需要进行一些静态配置。

在这个示例中，控制器通过LLDP来识别拓扑结构，但也可以利用其它的机制，包括Cisco发现协议（CDP）、ICMP 探测，甚至静态的编程设置。

线路协议（wire protocol）消息用来（在主动模型下，为应用程序）填充转发表，这些消息指定了一个特定的表，作为填充目标，一个包含了输入端口（用于匹配）的数据报文包头信息匹配/修改规则以及需要采取的操作的组合，这些操作在OpenFlow线路协议中有说明，可以是next_table或者输出到端口。本示例做了一些简化，让这些规则指明哪些流可以在一个或多个输入输出端口间进行交换。再来看一下基本的配置，鹿儿岛的交换机需要四个端口接入OpenFlow：ge-1/0/5.0、lt-0/0/10.0、lt-0/0/10/150（提供对第三层实例上的MPLS LSP的接入）和lt-1/0/10.0（接入连接了OpenFlow中转路由器的VPLS实例）。

OpenFlow交换机/路由器所看到的端口如下：
admin@ 鹿儿岛> show openflow switch info 0
1(ge-1/0/5.0): addr:64:87:88:5a:d2:5d, config: 0, state:0
2(lt-0/0/10.0): addr:64:87:88:5a:d1:f8, config: 0, state:0
3(lt-0/0/10.150): addr:64:87:88:5a:d1:f8, config: 0, state:0
4(lt-1/0/10.0): addr:64:87:88:5a:d2:58, config: 0, state:0
LOCAL(lo0.0): addr:64:87:88:5a:d2:f7, config: 0, state:0

当札幌的客户端应用程序启动，并向鹿儿岛请求视频流时，有一个选项可以选择一个特定的纯OpenFlow路径，在小应用（applet）或者 API中。选择这个选项将强制数据流通过东京。

这里将创建两个单向的流。

路径上路由器/ 交换机中的流状态（部分输出被省略）：
admin@ 札幌> show openflow switch statistics flows all
cookie=0xffffffffda6979c2, duration_sec=15s, duration_nsec=116000000ns,
table_id=0, priority=32767,
ip,in_port=1,nw_src=2.2.2.2,nw_dst=3.3.3.3,actions=output:4
cookie=0xa00000138ac0f2, duration_sec=15s, duration_nsec=116000000ns,
table_id=0, priority=32767,
ip,in_port=4,nw_src=3.3.3.3,nw_dst=2.2.2.2,actions=output:1

admin@ 东京> show openflow switch statistics flows all
cookie=0xa000002d2dd7a5, duration_sec=56s, duration_nsec=116000000ns,
table_id=0, priority=32767,
ip,in_port=1,nw_src=3.3.3.3,nw_dst=2.2.2.2,actions=output:2
cookie=0xffffffffa31ecf59, duration_sec=56s, duration_nsec=116000000ns,
table_id=0, priority=32767,
ip,in_port=2,nw_src=2.2.2.2,nw_dst=3.3.3.3,actions=output:1

admin@ 鹿儿岛> show openflow switch statistics flows all
cookie=0xa0000061b156c3, duration_sec=101s, duration_nsec=116000000ns,
table_id=0, priority=32767,ip,in_port=4,nw_src=2.2.2.2,nw_dst=3.3.3.3,
actions=output:1
cookie=0xa000006e97ed68, duration_sec=101s, duration_nsec=116000000ns,
table_id=0, priority=32767,ip,in_port=1,nw_src=3.3.3.3,nw_dst=2.2.2.2,
actions=output:4

注意鹿儿岛的输出，将这些输出反向映射到端口输出是比较简单的。

请注意，虽然所请求的流的持续时间可以映射到控制器所下发的流表项的持续时间，但在流表项中无法表达带宽预留的信息。这需要另外地跟踪记录，并且可以通过带宽预留应用程序的可视化界面或分析界面访问。

10.2.5　控制器增强

为了进一步说明这个控制器的效用，下面将仔细看看哪些组件可以构成该控制器。图10-3展示了一个基本控制器可能的内部结构的细节，这个控制器可以用于实现之前的那个示例。

首先，图10-3展示了控制器的一个RESTful API，它可以用于和控制器的通信（如创建新的或删除LSP，或更改现有LSP的基于时间的调度）。这里采用Firefox的图标与GUI之间的通信表示。为控制器加上REST风格的接口十分重要，因为它可以提供与控制器之间的快速、灵活的交互，而且，这也是现代应用程序开发人员所使用的一种首选的应用程序编程接口（API），这些开发人员使用诸如Java、Python或Perl这样的语言。

图10-3：OpenFlow控制器分解

接下来，RESTful的管理器会与调度器进行通信。正如人们所期望的，这个组件负责管理LSP创建、暂停、卸载这些编程事件的调度。实际上，这可以简单到用一个配置文件实现，或者复杂到用一个多分片（multisharded）SQL数据库实现。调度器再与拓扑结构管理器组件交互。该管理器负责管理和维护拓扑结构。在本例子中，假定这是LLDP所收集信息的一个资源库，正如之前讨论过的那样。然而，可以注意到的，这个数据库可以由多种机制构建，包括Cisco发现协议（CDP）、ICMP 探测，甚至是静态的编程配置。最后，调度器与OpenFlow控制器进行交互。本例中的这个组件十分简单，并且基于开源的Floodlight控制器，但人们可以随意地使用任意开源控制器，甚至用自己实现的控制器来替换它。

10.2.6　采用PCE配置的叠加网络示例

一个更加令人回味的例子是有状态的PCE，也被称为PCE-P的使用。如果读者考虑使用运行在控制器上的外部C-SPF算法，那么PCE-P是一个非常有吸引力的选择。PCE允许应用通过PCE服务器，控制拓扑结构中之前所配置并且指派的MPLS LSP的ERO，或者动态创建新的LSP（取决于网元设备软件对PCE支持的级别4）。这在图10-4中有说明。

图10-4：PCE-P操作概念图

4.draft-crabbe-pce-pce-initiated-lsp-00 描述了进行PCE 发起的LSP 设定的能力，建立在之前“有状态”PCE的相关工作之上。[draft-crabbe-pce-pce-initiated-lsp-00]

实验平台的初始设置可以用和OpenFlow示例（NEYCONF/Yang）中相似的方式自动化进行。PCE的拓扑结构可以通过一个静态文件（有很多工具可以利用配置或者IG数据库转储来构建拓扑结构）提供给应用程序，但实用起见，最好选择活动拓扑结构。5

5.可选的活动拓扑结构在第8章中有讨论。

在叠加网络中使用MPLS LSP带来了如下几个好处。

- 配置只在边缘设备上进行；

- 提供了潜在的保护（同时预留和配置了主备路径）6； 6.draft-crabbe-pce-stateful-pce-protection-00提出了创建或操控路径或为已创建或指派的LSP提供本地保护的能力。

- 提供了潜在的动态LSP配置能力（本示例允许PCE操作现有的、预先配置好的LSP基础设施的ERO）；7 7.draft-crabbe-pce-pce-initiated-lsp-00 提出了PCE 在 PCC 上发起LSP 的能力。

- 和BGP-TE/LS 提供相似的现有路径计算算法（CSPF）和拓扑模型的自然亲和性；

- RSVP → BGP-TE/LS 反馈周期中的主动预留管理。

最后一点对于应用开发者来说可能是福也可能是祸，并且这也是同OpenFlow模型的一个区别。在PCE模型中，预留请求（RSVP路径请求中的带宽预留）由流量工程数据库（TED）管理，并且可以不断地在拓扑结构中更新（如果选择BGP-TE/LS来进行拓扑结构学习的话）。所以，在PCE模型中，系统的总体预留是未决或未来（还未提交）的预留和现有的活动预留的组合。在OpenFlow中，预留管理仅作为应用程序的一部分。

这两种模型都需要一些策略来记录没有被预留的路径。在使用OpenFlow或PCE模型的情况下，这可能包含在解析更新中。PCE有一个选项，可以将默认的（没有被匹配的）流量映射到自调控带宽的隧道上，并且周期性地采集这些隧道的带宽利用数据。

和基于OpenFlow的例子不同，基于PCE的示例可能需要一个入站旁路来将某些流量映射到MPLS LSP上。默认情况下，LSP FEC是基于目标IP前缀的，所以流量会映射到网络上距离通告目标IP 前缀的节点（下一跳）最近的隧道上。因为这种操作可能无法提供足够精细的控制，所以大多数MPLS-TE的实现支持基于策略的路由，来为隧道分配流量。然而，这个选项带来了控制策略（厂商特定的语法和上锁/验证/提交行为）的负荷、有限的策略表达，以及有限的扩展性（在某些实现中）。

OpenFlow提供了一个有意思的、动态且开放的入站旁路功能（流量匹配和/或重定向）的替代选项。利用OpenFlow的匹配功能，人们可以将需要的数据流映射到MPLS-TE隧道（LSP）所代表的逻辑端口上。

入站旁路功能的其他替代选项可能在未来出现（如利用BGP Flowspec8的扩展）。

8.draft-marques-sdnp-flow-spec-01提出了一种扩展数据流分类的方法，可以利用RFC5575中IP目的地址以外的字段来分类，draft-simpson-idr-flowspec-redirect-02.txt 也对同一个RFC中的重定向规则提出了更改（使它成为一个更加实用的策略-路由入站匝道功能）。

发出和上文示例相同的请求，但并不指定一个纯OpenFlow路径会导致预留一条PCE控制下的MPLS LSP。

同样，新创建两条单向数据流，并且在这种情况下，为带宽预留提供了两条单向MPLS LSP。图10-5说明了如何用一个控制器在同一个网络中同时支持OpenFlow和PCE模型。

图10-5：PCE-P 和OpenFlow

现在来看一下鹿儿岛的输出。

这里，可以看到为一个名为LSP Kagoshima_to_Sapporo（鹿儿岛到札幌）的LSP创建了带宽预留（所有的基础LSP在创建时都是零带宽预留的），并且创建了两条数据流：
admin@ 鹿儿岛> show mpls lsp extensive name Kag_to_Sap
Ingress LSP: 2 sessions
10.10.10.100
From: 10.10.10.118, State: Up, ActiveRoute: 0, LSPname: Kag_to_Sap
ActivePath: (primary)
LSPtype: Externally controlled, Penultimate hop popping
LSP Control Status: Externally controlled ← controlled by a PCE
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 0 0
Bandwidth: 6.30146Mbps ← up from original reservation of 10Kbps
SmartOptimizeTimer: 180
No computed ERO.
admin@ 鹿儿岛> show openflow switch statistics flows all
cookie=0xa0000046ada2b3, duration_sec=42s, duration_nsec=883000000ns,
table_id=0, priority=32767,
ip,in_port=1,nw_src=2.2.2.2,nw_dst=3.3.3.3,actions=output:2
cookie=0xffffffffd2efad8b, duration_sec=42s, duration_nsec=994000000ns,
table_id=0, priority=32767,
ip,in_port=2,nw_src=3.3.3.3,nw_dst=2.2.2.2,actions=output:1

类似地，可以在札幌那里发现一条拥有带宽预留的 MPLS LSP，并且OpenFlow流表里也会有两条数据流。

在任意的中间路由器上，别指望能看到任何关于这条数据流的OpenFlow状态，哪怕这条LSP路径经过了一个支持OpenFlow的网元设备。

10.2.7　深入调研：大举向新领域进军

本节继续讨论API赋予SDN应用程序的力量（事实上，SDN就是关于可编程接口的），并且将示例扩展到用户（consumer）应用程序（这就是大举向新领域进军）。到目前为止，本章都在集中讨论相对封闭环境下的高带宽使用的数据流，一般来说，这代表了较为封闭的网络上的内部应用。相反地，用户环境的特点在于一个更加开放环境下的大量低带宽使用的数据流，以及一些必须加入SDN 控制器/框架的必需的功能。

虽然对于安全、策略、潜在的为运营和业务支撑系统OSS/BSS系统（如计费系统）提供的接口的需求是显而易见的，如果将这个示例扩展到一个嵌入客户浏览器（或客户代理）中的API，这个API在客户试图观看某一类视频时会被调用，这样就可以集中从拓扑结构的角度来讨论SDN API的性质。

出于计算和安全上的原因，人们不会想把整个拓扑结构都展示给这样的客户端（可能是智能手机或者平板电脑），但是需要提供API，来让拓扑结构变得可扩展，并可以用策略来进行定制。ALTO9协议提供了这些AP服务的示例。

9.http://datatracker.ietf.org/wg/alto/提供了丰富的关于IETF ALTO协议的阅读材料。

假设SDN控制器/框架内嵌入了一个ALTO服务器，当用户尝试下载一个视频的高清版本时，用户将收到一个嵌入的小程序的提示（这个小程序会利用ALTO客户端来调用API），询问用户请求一条付费的（只有需要许可时才需要这个提示，否则不是必需的），或有优先级的，或有保证的数据流路径。通过在客户端和服务器端（控制器/框架）使用ALTO，用户可以限制对客户端/调用者展示的拓扑结构，只展示简单的内容，如源和目的地之间的最优路径或（对于网络中一个为客户端进行调用的代理展示）一个受限的网络视图，这个网络视图包含了高清视频源和可用的视频链路。

10.3　在即时CSPF中使用大数据和应用程序超虚拟化技术

到目前为止，关于带宽时间规划的用例，都只需要SDN控制器/框架所提供服务的一个简单的子集。这些服务主要集中在拓扑结构、路径计算和路径调配上。

拓扑结构是一个二层的（OpenFlow）或三层的/MPLS拓扑结构（PCE），并且所需的路径计算是相对简单的、带有较少限制（当前网络状态、对于当前数据流统计和预留的基本分析，以及相对简单，嵌入式的策略）的最短路径（SPF）（OpenFlow）或带约束的最短路径（CSPF）（PCE）。

上一节的示例是可行的并且可以用来演示的。10然而，那个示例可以被扩展到更为复杂的应用中，带宽时间规划应用程序中的预留系统是这个应用的一个组件。如图10-6所示。

10.2012 年，Ofelia 研究项目、OESSS（OES3）软件和瞻博公司的BCA 演示应用程序都演示了如何进行带宽时间规划。

现在，许多网络管理员使用离线分析和计算引擎为他们的网络（或其中一部分）进行周期性优化。这些工作很大程度上都是手动进行的（可能会用到某种自动化手段）并且同时被工具自身的能力，以及带宽时间规划应用所围绕的静态调配模型所限制。因为这些操作都是在OpenFlow和SDN驱动的叠加解决方案之前出现，它们通常使用MPLS-TE LSP来引导流量（和之前提到的PCE示例有着一样的装载/入站旁路的限制）。11

图10-6：一个预测式、多层拓扑结构网络优化工作流

11.一些诸如允许子LSP的草案为这个领域的几个问题带来了一些进步，尽管这些进步是增量性的。

一种可以工作的模式，是输入一个静态的拓扑结构（可能从网元设备的配置或者路由协议数据库转储中获取，具体取决于工具厂商）、流数据，以及用户定义的策略或限制（如最大路径延迟或避免共享风险链路组），然后对这个拓扑结构进行优化，使其达到最高效的网络利用率（通常在活动和受限的假设错误场景下）。一次分析运行的结果一般以建议的形式呈现，可以导出到电子表格，然后转换为厂商特定的隧道创建语法/语义，并且在维护窗口内进行调配。在运营期间，潜在的重路由流量会带来很多问题，这些问题在于静态调配模型所需要的时间，以及在调配模型中，人们不可能接近同时地安排多个变更（可能会带来人们不想看到的暂时的效率低下）。

当前离线工具的能力在于它们可以接收的参数以及策略是多种多样的，以及它们所用数学算法的复杂性。但是，它们的运行可能需要消耗很长时间，这要取决于网络自身或流数据的复杂性和规模。

在这个工作流程中，路径计算组件可以根据以下信息进行优化。

- 当前使用率
通常从流数据信息库中获取。

- 历史使用率
一般是一个基于历史流数据的使用率图，不用太具体，这个图可以说明网络使用的昼夜模式（这个昼夜模式可以采用历史数据的滑动窗口来进行更新，如果这个模式的趋势出现了明显的变化）。

- 未来的预留
由带宽时间规划预留系统管理。

这些输入可能不会单独使用，而且预测的真正力量就源自它们的组合。

虽然还只是一个潜在的应用，但SDN和大数据技术可以为网络优化应用提供可行的解决方案，并且一系列潜在的服务需求，从带宽时间规划到这种自动化网络优化，飞行线控（fly-by-wire）应用，都强调了对于组件模块化的需要以及（再次强调）提供的服务API的灵活性。

BCA应用及其底层的控制器/框架提供了一个模板，如果要用这一模板解决这个问题，还需要对路径计算组件进行一次重大升级。同时，需要一个更加健壮的分析模型，来捕捉、格式化，并且（可能需要）汇总相关的流数据。

一些商业工具厂商正在利用大数据技术，解决分析管理和路径计算问题的计算复杂度。例如，使用网格计算对分析数据进行自定义的分布式汇总，使用Hadoop管理计算活动，并且将它们的结果提供给PCE服务器进行配置。

近期的一个IFTF草案 draft-farrkingel-pce-abno-architecture-02提出了一个基于PCE的架构，这个架构可能对这种应用起到推动作用。

10.4　扩展拓扑结构

这一节的用例集中讨论了动态网络路径创建和网络优化。现在，回过头来把拓扑结构看作SDN 控制器/框架所提供的一种服务。很显然，网络拓扑结构是SDN框架的一个重要的方面和服务，因为它同时涉及了较为实际的带宽时间规划应用，以及更加未来的网络优化应用。

在这两个示例中，对二层的或三层的/MPLS拓扑结构进行的配置以及它们所能见到的，展示了限制的拓扑结构。

一些运营商的商业模式要求他们按照网络出口点来进行优化，并且在某些情况下，可能还要和链路利用率策略相结合。这通常会带来一个挑战，因为大多数活动的拓扑结构源包含了对外部地址前缀可达性的解析，这种解析采用了配置、分布式、路由策略以及BGP最优路径算法。这只表示了真正通告此地址前缀的对等点的一个子集。虽然加强的BGP允许多个潜在的最优路径，12这可能带来一个附加的活动状态，从而给网络带来负担，特别是当需要让流量通过隧道到达出口点时，这就意味着所有中间节点都不需要知道这个附加的状态。解决这个问题的方法，是把类路由服务器状态和SDN 控制器/框架拓扑结构库里的活动拓扑结构，合并起来。用来收集此类信息的非侵入式工具还正在开发中。

12.draftietf-idr-add-paths-08 描述了BGP add-path 操作，来展示多条路径（对best-path 的加强）而draftietf-idr-add-paths-guidelines-04 提供了关于这项增强的使用指南。

还有一些人肯会使用隐藏资源来加强拓扑结构，这些隐藏资源可以被用作路径计算的解决方案的一部分（这里，增加额外的容量来处理突发是比重路由流量更好的一种策略，或者可以和重路由一起使用）。重要的是，要注意隐藏资源会导致网元设备上连接的但（在二层或三层）未调配的端口。特别令人感兴趣的是第0层（光路）上附加的链路容量可以按需供应。可以想象，光网络厂商或者二/三层网络的运营商（如果这个运营商同时也是传输运营商）提供其光网络的一个可配置的划分，这一划分可以向上一层运营商提供潜在的路径。

目前，在前一节中所提到的工具厂商，允许将第0 层拓扑结构和上层拓扑结构合并，但是这还没有实现自动化，数据格式也没有标准化。尽管如此，路径计算引擎可以使用这样的拓扑结构，现有的PCE-GMPLS和提议中的OpenFlow扩展（传输工作组）的组合使得这些路径可以动态地设置。

10.5　小结

本章展示了一些关于SDN的简单而重要的用例。具体来说，展示了如何利用一个SDN控制器，以集中式的方式来控制网络路径，在工作日的特定时间或者特定条件下，对这些路径作出调度。还展示了一个集中式控制器在没有附加的智能时，如何提供有一点价值的功能，例如有状态的PCE和离线分析工具。举例来说，OpenFlow协议一节演示了如何使用这种工具来放置一个简单路径，虽然作为例子是很有意思并有指导意义的，但如果没有附加的工具来增强控制平面的功能，这个示例在真实的网络中就不会发挥太大的作用。这是SDN领域的一个富有成果和令人感兴趣的方向。本书的合作网站上还有很多SDN领域中与这些用例相关的有意思的进展，可以作为读者附加的阅读材料，笔者建议大家去进一步研究。此外，对于这些设备的配置也放在了合作网站上，读者可以在实验室或其他地方用到。

第11章　数据中心叠加网、大数据和网络功能虚拟化的用例

11.1　引言

数据中心中的用例1可能会像数据中心里运行的应用程序那么多种多样。为了将前 面几章中的一些概念整合起来，本章将展示一些示例，用来反映下述内容。

1.这些示例不是作为“攻略”出现的（每个示例都可以出一本攻略，为该功能提供合适的/ 可用的细节），而是对SDN在数据中心应用程序上使用的一个更加广泛的说明。

- 服务编排叠加网络中多租户共享度低的分层应用程序；

- 叠加网络服务编排的DevOps（开发运营组合）替代；

- 在大数据应用中使用SDN（应用驱动的网络控制）；

- 数据中心内外的NFV/服务链。

11.2　数据中心服务编排

数据中心所扮演的角色可以是纯粹的IaaS、PaaS、SaaS，或这些服务的任意组合。

一个典型的主要提供SaaS服务的垂直行业的服务中心（进行专门的信息管理的数据中心，例如，医疗记录管理，人力资源外包等2）可能有多种潜在的客户类型，这些客户类型有着不同程度上的共性（共性程度的不同取决于它们如何与外界相连）。

2.这个具体的示例来源于某医疗保健领域的垂直行业服务中心，并且客户可以是医生办公室，或其他与保健业务相关的运营商（如成像、药房、收费等）。

这些客户之间的共性是，他们都假定自己通过某种等级的公网/互联网访问SaaS服务，应用交付控制器（ADC），ADC提供一些基本的安全性以及负载均衡。

运营商主要关心规模、运营的简便以及安全。就安全而言，需要保护所有的系统免受蠕虫、病毒、恶意软件以及其他类型攻击的入侵。

如图11-1所示，第一种客户类型在数据中心里拥有多个虚拟网络。第一个虚拟网络提供了主要的服务中心应用程序/数据管理功能，剩下的是用于其他用途的外包网络，所以，客户预订的是数据中心里IaaS、PaaS和SaaS的一个组合。客户还会管理自己的网络中的虚拟机，这个网络可以连接到数据中心。

图11-1：一个概念上的专业服务中心（数据中心）。租户类型1是完全虚拟化的两个虚拟机池，分别用于服务应用程序（图中方块内标竖线的区域）以及租户自己的应用程序（图中白色区域）。租户类型2拥有场外（off-premise）实例以及私有网络的连接，他们也拥有自己的非虚拟化应用程序以及托管在数据中心的数据库管理系统（DBMS，图中灰色区域）。租户类型3拥有虚拟化的服务应用程序以及它自己的非虚拟化应用程序和DBMS（图中方块内标横线的区域），这些应用只能通过互联网访问。租户类型4只将数据中心用作基础设施（IaaS，图中方块内标斜线的区域）

来自客户网络的寻址延伸到了服务中心，这符合VPN客户端模型。

有下列四种离散的数据流类型。

- 段内，服务器到服务器；

- 段间（通过网关），服务器到服务器；

- 通过vADC 和vFirewall（防火墙可以在网关以内或以外）从外部传入的用户流量；

- 服务器到服务器，从服务中心里的客户网络VM 到租户网络VM，经过了一个或多个（本地和/ 或远端）防火墙。

图11-1 所示的第二种客户类型将服务中心应用程序（SaaS）扩展到了它自己的站点上，并且可能也拥有数据中心里虚拟和物理资源（assets）的一个组合（虚拟资源采用SDN/服务编排系统进行管理）。在这种情况下，对虚拟机管理扩展到了租户自己的设备上了。

这种运营模式可以适应云猝发模型。

第一种场景包括了数据流类型#1和#3（除非遇到真正的云猝发，此时#3中的数据流可以首先使用客户站点的VM，再溢出到数据中心的VM中）。数据流#2被稍微修改了一下，因为它处在一个VM 和一个物理设备之间（该设备可能没有被VM服务编排系统所管理）。数据流#4略有不同，尽管它可能存在于本地和远端VM之间，但数据中心运营商会管理所有这些流。

第二种场景引入了下面两种新的数据流。

- 从服务中心里的租户VM 到租户私有网络中的机器/VM（经过一个额外的网关）；

- 从远端但是受控的VM 到私有网络中的远端机器。

图11-1中的第三种场景, 无论是对IaaS、PaaS还是服务中心的专门应用程序（SaaS）来说, 都仅提供互联网访问。

最后，图11-1中的第四个场景和第二个类似，只不过私有网络并不在客户的设备内，而是在服务中心里（一个额外网络的连接）。这个网络可以从运营商那里分开管理，或者由运营商来直接管理。

数据中心里的真实情况看上去并非那么理想化。数据中心里可能有很多独立的存储、主机、管理（带外监控和镜像加载/启动），以及vMotion网络。为了体现使用资源池的优势，随着网络上的客户变得更加随机，它将变成一个重度叠加的物理基础设施（这在图11-2这样小的图里很难描述）。

图11-2：服务中心实际上的视图，通过叠加虚拟化实现的物理的、虚拟的以及存储的离散放置（很难在图中描绘出来，但是每种颜色就是一个错综复杂的叠加隧道网络）

11.2.1　创建租户和虚拟机状态

在任何一种叠加方法中，当某个给定租户的第一个虚拟机在服务器上被实例化时，都需要采取以下几个步骤（如图11-3）。

图11-3：在一台服务器上为租户添加一台虚拟机；为租户添加第一台虚拟机（1）；添加虚拟机（2）

1. 实例化一台新的虚拟机。

2. 为租户在vSwitch上创建一个新的逻辑网桥。

3. 用虚拟以太网接口将新创建的虚拟机连接到逻辑网桥上。

4. 在这台服务器和数据中心里，每台至少运行了同一个租户的一台虚拟机的服务器和其他服务器之间创建隧道，如果这些隧道之前不存在的话。

5. 在每条隧道之上创建一个虚拟以太网接口，来代表租户的ID，并且连接到逻辑网桥上（对于不同封装传送/表达租户ID的方式请见第6章）。

6. 为VM的每个虚拟网络接口上应用服务，如QoS、防火墙策略、访问列表等。

当在同一台服务器上继续实例化同一个租户的虚拟机时，只需要执行步骤1、3、5 和6。

SDN控制器的职责是，创建逻辑网桥、隧道、虚拟以太网接口，将虚拟以太网接口连接到逻辑网桥上。在SDN控制器和服务器之间需要有某种信令协议，来引导这些操作，如图11-4。在第4章中已经详细地介绍了这一点。一般来说，SDN控制器只对数据中心的网络负责，它会根据编排器的高级指令来进行底级的网络操作。编排器负责数据中心的整体操作，不仅仅是网络，还包括, 计算、存储和服务。

图11-4：编排器、SDN控制器、网络管理系统（NMS）所扮演的角色

这里还有一个重要的发现是，编排器和SDN 控制器都不对物理网络进行操作，它们只操作服务器。在叠加模型中，增加一个租户或者为一个租户添加虚拟机，不需要物理网络的任何变动。管理物理网络是网络管理系统（NMS）的职责。当增加交换机或者服务器时，NMS需要和物理网络进行交互，但是在增加租户或虚拟机时，则不需要。这显然是叠加模型的一个优势。物理网络非常稳定，也因此更加可靠；所有和租户相关的动态改变都只会影响虚拟网络。

11.2.2　转发状态

除了与租户和虚拟机相关的状态（即隧道、网桥和接口），每个租户的服务器上也需要存放转发状态，这包括下列内容。

- vSwitch上每个租户网桥的MAC地址表；

- 每个VM的ARP表。

图11-5对此进行了说明。

图11-5：vSwitch网桥中的MAC表

有两种方式可以填充MAC表：数据驱动的学习和控制平面发信令。

11.2.3　数据驱动的学习

数据驱动的学习，这种方式使用了和普通交换网络（如非叠加网络）相同的机制。拥有未知目的MAC地址的网络帧在整个租户网络上被泛洪。交换机通过观察源MAC地址和输入接口来构建MAC地址表。同时它还构建一个ARP表。用于将IP地址映射到MAC地址的ARP表，通过在整个租户网络上广播ARP请求来构建。数据驱动的学习方式在扩展性和稳定性上存在些问题。通过对隧道接口的水平分割（不将从隧道上收到的数据帧转发到其他隧道上），可以消除或降低对生成树协议的需求。数据驱动的学习方式，还在处理VM移动性上存在挑战，必须恰当地实现它，这样在VM移动时，就能够足够快速地对所有刚刚提到的那些（转发）信息，重新编程。

11.2.4　控制平面发信令

在控制平面发信令这种方式下，SDN控制器采用某种发信令协议（如OpenFlow或XMPP）来填充MAC地址表。控制器拥有所有必需的信息，它知道每个虚拟机的位置、MAC地址、IP地址。SDN控制器知道VM的移动，并且可以相应地对MAC地址表进行重新编程。SDN控制器不能使用发信令协议来填充VM的ARP表，因为VM运行的是应用程序软件，而且不能假设VM 运行了可以向SDN控制器通信的发信令代理程序。一种解决方案是使用普通的ARP解析流程，并且接收扩散的ARP请求。另一种解决方案是在vSwitch中实现一个ARP代理，这个代理可以拦截ARP请求，然后将它们通过隧道传送给SDN控制器。

11.2.5　对扩展性和性能的考虑

回顾一下叠加方式的几个基本优势（第6章）。

- 物理交换机中不存在租户相关的状态。具体来说，物理交换机中不包含任何租户虚拟机的MAC地址。当不使用叠加时，核心交换机需要存储所有租户所有VM的MAC地址。

- 如果在三层隧道上使用二层网络的叠加解决方案，可以选择让物理网络成为一个三层路由网络而不是二层交换网络。这样就会提升带宽的使用率和性能（自然地可以提供多路径支持）。而一个二层网络使用生成树协议并且需要TRILL这样的协议来支持多路径。3

3.按理说，三层路由协议在本质上相比二层生成树之类的交换控制协议更加具有可扩展性及稳定性。

如果将隧道的一端放在虚拟机管理程序中（而不是像在ToR上使用VEPA那样），隧道的状态会分布在主机和它们的虚拟机管理程序上。某数据中心运营商提供了以下一些数据，供研究叠加对隧道状态的影响。

- 如今，大多数被广泛使用的ToR交换机支持48个主机；

- 每个主机现在平均支持20台虚拟机；

- 典型的租户拥有四到五台虚拟机。

在本示例中，租户可能还需要和一个装置（如防火墙）和/或一个网关打交道。

假设拥有某种程度的装置/网关冗余，和最坏情况下的租户VM分布，即每个VM都放置在一个不同的主机上，那么可以快速地算出需要添加上百条隧道（每个VM大约160——有八个隧道，其中四个隧道用于连接组内其他主机，两个隧道连接冗余的防火墙，两个隧道连接网关，20个VM）。映射到这些隧道的数据流的数量可能是一个额外的，但目前仍然需要控制的规模乘数（并不总是1∶1对应关系）。

如果为每个租户添加VM，构建一个高度网状连接的结构，并且利用LAG那样的技术使这个结构变得更加复杂，那么每个主机的隧道/链路数目就会很快地增大。当然，这种最坏的情况基于每个主机都可以（并且希望）使用全网状连接方式的假设。

在这个特定情况下，由于预测段内的数据流很少，所以许多数据流必须首先经过一个防火墙或者网关。在本章的第三个租户类型的示例（见图11-1）中就更是如此，这个示例中，只为服务中心应用程序提供了互联网访问。在这些情况下，主机虚拟机管理程序上的隧道总量是主机上虚拟机数量的一个较小的倍数（在冗余存在的情况下）。相应地，数据流到这些隧道的映射也会如之前所述那样扩展。

无论是用哪种方式，最坏情况下，运营商的平均租户和数据流规模都可以被这一代的COTS主机所支持。另一方面，如果从ToR交换机开始叠加，隧道状态数可能最少比现有的大一个数量级（可能有48X）。某些网络芯片可以支持这种规模的隧道，但是成本较高。4

4.回想一下，上文讨论叠加网络的使用来避免逐跳的数据流（如OpenFLow）配置。在这种情况下，每个端口上的数据流规模是以百计算的，并且内部（主干/聚合）交换机可能存在相似倍数（48倍或更大）的数据流状态。这种“第二效应”数据流规模在今天的商用芯片上是有问题的，并且为了管理这些流，需要使用聚合。

下一代的服务器/CPU，以及随之而来的支持VM的数目的增加，是否能够放入虚拟机管理程序的转发空间，还有待观察，但期望这种规模是可控的。每天都在增长的处理能力可能不会成为限制，但虚拟机管理程序的进程空间却可能成为限制。

11.3　Puppet（DevOps解决方案）

如果客户类型的数量以及规模不是太大（客观的“大”），管理员可能不需要一个编排驱动的SDN解决方案。选择DevOps，使用Puppet、Chef、Cobbler或者Ganglia这样基于模板的构建工具可能是较为恰当的。

这些围绕镜像/角色和服务管理开发的工具，功能包括（为物理级和虚拟主机）地址分配和网络设置。例如，当使用Puppet时，Puppet Master的作用是将节点（设备）分配到类（如，Web服务器、数据库服务器等）。每一类的定义描述了设备上所需资源的种类（如Apache、MySQL等）。这些资源说明了要做什么，而不是怎么做。

将这些概念应用于网络，这些资源就会是网络接口、VLAN等。如果传统网元设备的操作系统支持Puppet客户端/代理，那么就可以找到有意思的解决方案。例如，如果数据中心的运营规模足够小，可以放入一个VLAN 分区（separation）的范围（不需要叠加的情况下），那么就可以使用Puppet 的扩展在端口和中继上设置VLAN，以适应这样的架构。

瞻博公司和Arista公司都对Puppet进行了扩充，以使之支持各自操作系统中的代理。5在图11-6展示的例子中，瞻博公司的解决方案包括了下面两个文件。

图11-6：Puppet netdev的网元设备支持

5.Arista 同时支持Puppet 和Chef。

- 第一个，/netdevops/netdev_stdlib，包括了为netdev资源的Puppet类型定义。Netdev 是一个厂商中立的网络抽象框架，由瞻博公司开发，并且免费公布在GitHub上。6

6.这个文件最终会被转到PuppetForge上。

- 第二个文件，juniper/netdev_stdlib_junos，使用了Junos的操作系统相关的代码，来实现 netdevops/netdev_stdlib中定义的各类型。

后面这个文件必然是厂商相关的，绕开了现在缺少针对这些服务的公共数据模型这个问题。7

7.对于开发标准数据模型的需求是本书的主题之一。VLAN模型是非常简单的，但是叠加封装的建模和其他为网元设备和虚拟机管理程序，虚拟交换机的网络抽象并没有什么影响。

这一组合支持如下几种类型。

- netdev_device
为网络设备的性质建模。

- netdev_interface
为物理接口的属性建模。物理接口属性和接口上的服务是分开管理的。

- netdev_l2_interface
为接口上的二层交换服务的属性建模。接口上的二层服务和物理接口在管理上是分开的。

- netdev_lag
为链路聚合组（LAG）的属性建模。LAG的属性和物理成员链路以及接口上的服务在管理上是分开的。

- netdev_vlan
为VLAN 资源的属性建模。

对于Puppet的用户来说， 把VLAN分配给主机， 意味着修改主机设置清单的netdev一节。Puppet master将会编译清单，并且变更后的代码可以被主机/网元设备（通过SSL）（定期）下载。

例如，将应用foo部署在bar.com 的交换机fooswitch1上（将foo分配给一个端口或一个中继，并且用VLAN 100和其他类似foo的服务器通信）可以如下进行：
node "fooswitch1.bar.com" {
netdev_device { $hostname: }
netdev_vlan { "Foo-net":
vlan_id=> 100,
}
netdev_vlan { "Native":
vlan_id=> 103,
}
netdev_l2_interface { 'ge-0/0/19':
untagged_vlan => Native,
description=>"local foo host port"
}
netdev_l2_interface { 'ge-0/0/20':
description => "trunk Link from local ToR",
untagged_vlan => Native,
tagged_vlans => [ Foo ],
}
}

虽然这个例子是相对静态的，但大多数DevOps模板/脚本语言都是高度参数化的，并且可以使用类定义。Puppet框架通过简单地更改Puppet master上的类定义就可以完成对设备的大规模变更。

使用变量定义的例子如下：

$vlans = {
'Foo' => { vlan_id=> 100, description => "This is a foo vlan, just updated"
},
'Native' => { vlan_id=> 103, description => "This is a native vlan" },
}

以下可能是与其对应的类定义：
class foo_switch {
netdev_device { $hostname: }
create_resources( netdev_vlan, $vlans )
$db_port_desc = "This is for foo-ap"
$db_ports = {
"ge-0/0/0" => { description => "${db_port_desc} ge0" },
"ge-0/0/1" => { description => "${db_port_desc} ge1" },
}
$db_port_settings = {
untagged_vlan => Native,
tagged_vlans => [Foo]
}
create_resources(netdev_l2_interface,$db_ports,$db_port_settings )
}

相应的调用方法看上去可能会是这样：
node "fooswitch1.bar.com" {
include foo_switch
}

虽然这个示例被厂商提供的Puppet二层操作扩展库所限制，但是在未来可能展示的新功能上是不会存在真正的限制的。

需要注意的是，类似的功能限制存在于一些可替换产品上，如OpenStack Quantum上，虽然这会在后续版本的API中解决。也就是说，这个问题只在于厂商是否会在不断支持和扩展API来支持三层服务、叠加或其他服务上，下工夫。

11.4　网络功能虚拟化（NFV）

在数据中心编排中，运营商提供的服务包括了虚拟设施的使用（如防火墙）。一般说来，可以编排这些设施的使用，允许存在一个操作流的简单遍历，这里的逻辑接口同时代表了租户网络的一个入口和出口，建立起一个简单的数据流模式。这实际上是网络功能虚拟化（NFV）的核心，本书使用一种称为服务链的概念将这些功能链接起来（图11-7）。

图11-7：数据中心服务链；由高可用性策略导出的叠加可能有着额外的复杂性。图中画出了活动和待机的VM，但是这里的活动/待机的设备更多是从吞吐量的角度来看的

NFV的变化概念，在示例中为所有租户提供服务的定义是，一条基本的服务链：为所有从互联网入口流量提供ADC防火墙。8如果采用了VPN/私有网络访问，那么实际上是两个服务链。设备所采取的动作要么是转发、更改并转发，要么是丢弃，不需要额外的逻辑。也不需要在服务网元设备之间传送元数据。服务链中也没有明显的分支逻辑。

8.返回的数据流在大多数情况下经过一个单一的设备（如防火墙，甚至这个也不是必须的）。

服务链一般是由某些控制或编排实体（如SDN控制器）构建的。这个实体负责服务的配置（如放置），以及它们之间的链接。虽然实际上每个租户的服务（如防火墙和网关）的配置都不同，但还是需要由NFV控制器或编排器维护。现在，这种配置工作的透明度，取决于选择的编排器厂商以及部署的防火墙产品。如果它们来自于同一个厂商，那么就有可能进行透明的配置。如果不是，也可以用一个更高级的代理，运营和业务支撑系统（OSS）来维持某种程度的透明，这个代理可以和SDN控制器以及防火墙厂商的EMS/配置实体进行交互。如今任何设施/服务链的关系都与之相同。

本例中服务链的复杂性来自于将在本书后面提到的高可用性和/或负载均衡场景（创建第7章图7-10中描述的领结状结构）。也要注意到，这并不意味着所有的数据中心服务链本质上都是简单的，因为一些配置的高度复杂性不仅体现在实施配置上，还体现在长时间的维护上。

NFV的可移动性

服务链可能会变得越来越复杂，特别是在数据中心之外的集成网络平台分解过程中，以及那些需要解决宽带认证和可移动性（如EPC）问题的情况下。当然，可以预见到，很多的这些服务将会进入数据中心中。

这背后的原因是对服务的订制，本质上是以每个用户为单位的，具体说明如下。

- 对于一个典型的移动用户来说，可能存在着多个服务链：HTTP 流量（L4过滤、ADC、媒体优化、缓存、CGN、有状态和无状态的FW），点对点（DPI、CGN、有状态的FW），VoIP 和其他，它们中有些可能需要会话代理。目前，对于移动运营商用例的Ad hoc 分析表明，这些用例平均包含了七到十个可能的服务链。

- 服务链的特性取决于商业方面（如对于流向某个特定应用服务器的流量收取赞助费）而非网络方面的特性。

- 服务链是动态且个性化的。

- 由于需要针对每个用户提供个性化的流量处理手段，所以需要将一些元数据和上下文信息及服务链关联起来，或采用下文所提出的技术。

通常称为Gi LAN（按照3GPP接口命名法）或者服务LAN的是一系列包含了流量转发的增值服务。它们一开始由APN匹配来设置，并随后通过DPI动作重置，在策略交互的建议下（图11-8）。

图11-8：典型的移动服务LAN以及一系列增值服务（VAS）。不同的APN映射到VLAN上。DPI 可能导致进一步的重新映射（如，VLAN 200、300分支）

这个服务的重配置选项之一是将流量发送给下一代代理。然而，无线网络共享在移动领域中的使用在不断增加，所以很多笔记本电脑的流量会通过代理，这是低效且昂贵的，并且增加了延迟。

流量转发（从SDN的角度，鉴于目前可用的工具）是在三层进行的，所以根据URL进行转发的选项是不可行的。然而，需要达到这种颗粒度才能判断不同用户需要经过的VAS。

合理的、可扩展的解决方案是将一个PCC控制的用户绑定到一条服务链上。在采用OpenFlow控制的情况下，用于本地/传统的VAS的每服务的VLAN ID，和带有附加MAC重写、以定向到（在WAN 以及数据中心中的）下一跳的数据中心VAS的组合，所有的这些操作都通过，编排中URL/IP到服务链的映射指导下的数据流修改来完成（如图11-9所示）。这可以被延伸/扩展到VxLAN或者GRE封装，通过将OpenFlow中较为复杂的（并且可能存在局限性的）VLAN/NH-MAP数据流修改替换为一个可路由的隧道封装（数据流到VNID再到服务链的映射）。一些传统的VAS可能仍然需要从隧道叠加的VLAN映射，通过一种厂商相关的网关或者在网元设备内部（在叠加编排的指导下行使网关的职责）。TDF功能允许厂商使用现有的基于应用的收费系统以及动态策略或业务相关的服务调整。

图11-9：SDN控制执行每个用户的流量导向。流量通过TDF（DPI）来识别。无法感知隧道的本地的/传统的VAS（Value Added Service，增值服务）通过VLAN链接起来，否则VAS导向将通过隧道叠加进行

这同样也表现了一种理念上的转变，从应用程序和网络之间的双向会话上转移开。在这个模型中，网络控制对于策略引擎以及DPI嗅探器所呈现的信息作出反应。

11.5　优化的大数据

“大数据”的标签代表了高性能计算从为特定目的建造的计算系统（如SUN、CRAY等）到一种利用COTS硬件的价格优势，使用可以组成集群的小型、廉价设备的过渡。通过使用分治的方式来将计算问题分成数据上以及实际计算量上的小块，将它们分配到这些计算能力较弱但是非常便宜的小型硬件上。应该注意的是，许多大数据技术的使用者发现了拓扑结构视图和SDN 的集中控制，以及一些大数据应用之间的天然亲和性。

一般情况下，大数据不使用虚拟化环境，因为虚拟机管理程序所带来的开销是不必要的。Hadoop 是最流行的一类用于大数据的集群计算架构之一，它使用一个应用控制器来管理作业请求。9Hadoop用于一类被称为Map/Reduce（映射/化简）的应用，这种应用通过将问题（即数据集）划分成若干段/块，分配在多台计算机上进行并行处理，来完成对大量数据的处理。这个系统还利用了Hadoop的分布式文件系统，HDFS所带来的好处。

9.Hbase，Dryad，Spark

这类应用的主要开销来自于分发分段后的文件，存储然后收集结果。冗余策略的使用使这个开销被放大，冗余策略会导致分发同一个文件块的多个拷贝，以防止某个计算节点的故障，冗余复制是一个分层的操作。

Hadoop架构有三个功能组件：客户端、主节点、从节点（图11-10）。客户端是集群的终极用户，它们可以提交一个作业请求和一个文件，用于指示如何操作/处理这个作业以及收集结果。Hadoop的主节点承担文件分发以及控制处理节点的全部责任。主节点依赖并且与两个其他的节点交互：命名节点和作业追踪器。命名节点负责分发/存储，而作业追踪器协调计算的进行。10

图11-10：Hadoop架构

10.命名节点和作业追踪器功能可以在同一台设备上运行，这取决于集群的规模。

从节点被称为映射器，它们接收并处理文件块；化简器收集并聚合结果；作业追踪器控制任务追踪进程并且处理和协调客户端提交的作业；作业控制器与命名节点通信来确定数据处理的位置。作业追踪器需要对已经提交到被选中处理这部分工作的任务追踪器节点的工作负责。作为实现系统冗余以及高可用性的手段，任务追踪器必须周期性地ping作业追踪器。如果一段时间内没有收到这种心跳信号，作业追踪器就会决定重新向其他节点提交这份作业，可能将那个任务追踪器放入黑名单，或者只是在未来记住这个节点的性能特点，因为这（无心跳信号）可能只是暂时的情况。它也可能标志着主机/服务器故障的开始。

命名节点维护了文件位置以及各文件块在机器上的分布图。它自己有着某种程度上的拓扑结构感知能力，因为它可以通过管理员手动为主机所设置的机架号来理解主机间的相对位置。然后，命名服务器尝试使用最优化数据分发策略的算法来减少机架间的传输，但是仍然保持冗余数据之间的分离，以保证冗余/复制机制可以正常工作。11

11.Hadoop也是一个三层感知的文件系统，所以它运行在可路由网络中，这就允许架构师限制二层网络域的大小，并且可以在更大的范围内使用Hadoop。虽然可以在WAN上使用，但还是存在一些实际限制。更确切地说，可以使用数据中心的全部可用带宽（达到主干/聚合交换机的带宽极限）。

这样做的问题在于，这种配置方式的手动性质（特别是在大型并且不断增长/改编的数据中心）以及算法的动态性不足（关于机架内相对性能的假设可能不总是对的，特别是其他流量存在的情况下）。

使用SDN（OpenFlow）控制器以及修改过的Hadoop（修改过的作业追踪器以及任务），可以在传统的交换/ 共享的基于以太网的拓扑结构上（图11-11）实现一个更加动态的Hadoop版本。例如，近期的一项研究优化了整理阶段（shuffle phase），在这个阶段内，映射器采用OpenFlow 驱动的QoS将结果发送给化简器，以使整理流量可以消耗更多的链路带宽，这项研究得出了可喜的成果。12

图11-11：修改后的Hadoop以及SDN控制能给予Hadoop流量有力的QoS处理（在一个通用的基于以太网交换的数据中心架构中）

12.SCC Proceedings of the 2012 SC Companion: High Performance Computing, Networking Storage and Analysis

如果交换基础设施是可编程的光学器件，这个解决方案可以变得更加吸引人。在这种情况下，可以用OpenFlow协议在电-光网络上实现一个优化的拓扑结构配置（图11-12）。13

13.这一描述依赖于OCS的性质。如果它基于光-电器件并且主机之间通过以太网相连，那可以采用数据流匹配，来将流量复用在一个专用的波长上。在一个纯光学的交换机上，单个波长可以在交换机网络上使用，并且在终端节点上复用，或者在每跳之间复用。总之有很多的选择。

图11-12：Hadoop使用一个SDN控制器（通过Mesos集群资源管理软件，如果需要的话）在一个可配置的光交换网络上为映射器到化简器的流量创建一个树形拓扑结构

这个领域另外一个近期的研究14展示了组合带来的灵活性。可以从多个树形拓扑结构中推导出距离，在这些拓扑结构中，化简器要比它们对应的映射器更接近根节点。这个信息被用来在可扩展性很好的Torus或者Hypercube中减少多跳传输，这些网络结构可最终通过更改数据整理策略来启用。

14.http://www.cs.rice.edu/~eugeneng/papers/HotSDN12.pdf

这两个想法的进一步扩展，建议将控制器绑定到集群的动态资源管理器上（如Mesos15，图11-2中融入了这一想法）。通过使用管理器，管理员可以在一个集群上运行多个框架来控制使用率（特别是存储使用率），并且它们之间可以共享数据（和静态分区相反）。

15.2012 年国际会议SC Companion: High Performance Computing, Networking Storage and Analysis论文集中的论文“High Performance Computing, Networking Storage and Analysis”。

本章所创建的本质上是一个可以感知网络的应用，它会尝试去优化它的功能放置，或者利用网络的信息来影响它们的互连/管道系统（plumbing）。这和利用网络层的分析而进行的优化——应用感知的网络（如Plexxi，Helios，16OSA17）或之前提到的启用TDF的移动NFV的例子有着理念上的不同。

16.：http://cseweb.ucsd.edu/~vahdat/papers/helios-sigcomm10.pdf
17.https://www.usenix.org/sites/default/files/conference/protected-files/osa-nsdi12_.pdf

像Plexxi这样的解决方案能够支持这两种工作方式，可以修改Hadoop作业追踪器/命名节点，使它们导出一个节点列表，这个节点列表可以作为静态的亲和性映射导入Plexxi控制器。

11.6　小结

与健康服务相关的数据中心拥有多个目标客户方案，并且因此导致了多种潜在的数据流（和问题），数据中心内有一些定制化的但仍可识别的服务网元设备（负载均衡、防火墙以及网关）。

但是数据中心编排并不总是意味着复杂，也不是必须使用SDN。为此，本章加入了一个DevOps的例子，适用于一个基于VLAN的较简单的数据中心的部署。

笔者通过集中讨论一个特殊的应用类别-大数据来结束本章。除了介绍SDN是如何影响大数据的，还开启了关于SDN 所扮演角色的讨论（并且有意给读者留了一些讨论的空间）：它可以让应用感知网络还是反过来网络感知应用，或是两者皆有可能。

本章试图说明一些常见但是有用的，与数据中心和NFV相关的用例。这些话题混合在示例中，因为今天还很难将它们分开来。虽然看上去是纸上谈兵，但这些用例都是基于真实的部署，不过本章对这些部署以及公开研究刻意进行了匿名化处理。数据中心编排是SDN的标志性的子应用，并且长期笼罩在其炫目的光环之下，令人难以举出一个新的用例，所以本章展示和讨论了一些更加典型的部署。SDN的未来是光明的，数据中心将是它蓬勃发展前进的领域之一。笔者建议读者持续关注其快速且连续的演进和发展。

第12章　输入流量监测、分类及触发操作的用例

12.1　引言

有一类常见的用例1是输入流量监控或分类的变种，并且采取某一种或多种触发的操作。一般假设在网络的某个位置拦截或者检测到某种流量模式，通常是在网络边缘或是接入点，然后导致一个或多个触发操作。这一个或多个操作可能是多样的，并且非常强大：简单的可能是丢弃传入的数据包，复杂的可能是触发对radius（远程用户拨号认证系统）服务器的查询或HTTP重定向。一旦这些动作被触发，系统可以要么返回它原先的状态，只是处理流量，好像什么都没有发生过；要么改变它原先的动作，并且采取一些隐式的操作或者接收查询（如radius请求）响应后所引起的操作。以下将讨论若干典型的示例，来说明这一切是如何工作的。现在从现有的最基本的输入流量拦截机制开始：防火墙。

1.这些示例不是作为“攻略”出现的（每个示例都可以出一本攻略，为该功能提供合适/可用的细节），而是对SDN在基本流量监控应用程序上使用的一个更加广泛的说明。

12.2　防火墙

防火墙的核心，是一个由输入流量模式匹配引擎组成的系统，该引擎包含了一组用于匹配输入流量的分类规则。该分类规则的能力范围从十分简单且原始的（表达式）直到复杂的正则表达式。在所有的情况下，每一条规则都有一个对应的操作，如果这条规则被匹配，那么引擎就会采取相对应的操作。因此，防火墙的基本功能就是匹配输入流量的模式，并且采取相应的操作。这一操作，事实上可以作为另一条规则的输入，这就会导致递归或迭代的规则触发及处理。实际上，防火墙的规则几乎变成了它们自己的编程语言。事实上，这就是当今最先进的防火墙运作的方式，这种方式使得防火墙能够处理用于保护现代企业或运营商网络的海量数据的规则。

顺便提一下，另外一个相似且经常被同等看待的概念被称为访问控制列表（ACL）。这是防火墙规则的先驱，并且通常仍旧局限于很初级的匹配规则。它的优势在于，大多数高性能路由平台都在硬件中实现了匹配逻辑，并且有着很高的处理速率，这是许多防火墙设备仍然无法做到的。你可以在绝大多数的网络路由和交换设备上发现ACL的功能，更不用说在家使用的最廉价的无线路由器了。

接下来考察一下如何制定防火墙分类规则以及相对应的操作。正如之前所述，防火墙规则的核心是一个二元组，包括了 {<输入模式>，<动作>}。防火墙通常以一个阵列的形式来存储规则，为每个规则顺序编号。图12-1说明了这一基本概念。

图12-1：防火墙服务的重要组件

简单的匹配-操作规则如“allow all”或“deny from any interface ”，这两条规则分别允许转发所有的匹配流量和丢弃接口n 上的所有传入流量。复杂的规则如匹配传入数据报文上的多个模式字段，如在TCP端口范围上进行过滤，“drop fromany ipv4 TCP PORT 61000:65095”。匹配-操作规则也可以被链接起来，组成更加复杂的操作。例如，当输入流量匹配了一个特定的模式时，如“ACCEPT from192.168.1.0/24 to Interface eth0 –j GOOD-DMZ”，可以跳转到一个匹配规则组。在这个示例中，可以跳转到另一个定义在“GOOD-DMZ”规则组中的一系列规则。为了一起说明这些概念，以下来看看Mac OS X pfctl防火墙的示例输出：

Firewall
#
# anchor ruleset for the Adaptive Firewall
# anchor name: 400.AdaptiveFirewall
# see afctl(8), pfctl(8), pf.conf(5)
#
block in quick from 122.110.1.78 to any

在这个示例中，来自特定主机（122.110.1.78）的流量被显式地阻断了。这是通过在最后一行制定一个显式的分类匹配模式来实现的。如果防火墙匹配了来自哪个IPv4地址的流量，采取的操作就是阻断或者舍弃该流量。

如同前面提到的，可以将规则链接起来，组成更加复杂的规则集，让网络管理员可以依据输入条件缩小流量模式的范围，或者允许后续的匹配规则只在特定的、可能是动态的输入条件存在时触发。例如，较为知名的输入流量速率限制或者输入流量整形，实际上是接收流量高于特定阈值时触发的操作。由此产生的操作是丢弃或者有时是选择性地丢弃（如，整形）那些符合条件的输入流量。

需要注意的是，防火墙模式匹配可能是相当复杂的。到目前为止的讨论还集中于简单的规则，如“allow”（允许）或“drop”（丢弃），但是还有其他可能的规则，如“rewrite”（改写），这会指示防火墙在匹配时修改数据包的一部分。例如，可以用防火墙实现网络端口映射。也就是说，当一个模式被匹配时，如，在任何面向外部的端口上接收到一个来自任何主机的数据报文时，防火墙会将某些端口转换为内部所使用的端口号。这个功能被用于将一系列外部可访问的服务映射到网络地址转换（NAT）网关后的内部主机上。例如，可以定义如下规则：

第一条规则将匹配到达设备 “wan” 或者面向外部端口的来自任意主机的IPv4 TCP 22端口的流量，并且将IPv4的目的地址重写为192.168.1.45，端口重写为22000。这可以用来将进入此网络的一般的安全shell（SSH）流量导向一个特别的网关主机，这个主机配置有特殊的身份验证功能。类似地，第二条规则将到达此设备的23端口流量重写为端口23000，并且将其发送给主机192.168.1.46。这就有效地将数据流的端口重写为了一个特定的传入端口，并且将其发送给另一个特定的主机。图12-2说明了这些输入规则是如何应用于防火墙设备的。

图12-2：一个基础的防火墙

12.3　防火墙即服务

到目前为止所讨论的都是，关于当今网络中所能遇到的任何防火墙都有的功能。传统上，这些功能实现在系统软件中，这些系统软件运行于专门用于防火墙功能的物理设备上。事实上，许多这样的设备都有为这些功能优化的硬件，包括优化的输入模式匹配硬件接口，以及连接防火墙输入端口以及输出端口的交换矩阵。

所以，问题在于：为什么要虚拟化这些功能？答案很简单：灵活性以及成本。首先，将软件从定制设计的设备上提取出来，并且运行在商用硬件（我们称之为Intel x86）上所带来的灵活性非常具有吸引力。它允许网络管理员选择采用多种方式来组建他们的网络，或者，更重要的是，在以后更换所选的方式。他们可以选择的另一个选项是关闭防火墙软件，在那台机器上运行其他的程序！如果想象在物理上移动一个防火墙时所要做的工作，包括物理上以及运营和业务支撑系统（OSS）所需的工作，那么显然移动防火墙软件要比硬件更加便宜快捷。放置的灵活性也使得它适用于构建服务链，正如之前在第7 章中所讨论的，一个潜在用途是连接物理的和虚拟的服务。此时，虚拟的或其他方式实现的防火墙，被当作一项网络服务。

应该注意的是，让防火墙运行在商用硬件上不是一个新的想法，并且事实上，许多将遇到的防火墙设备都是，正在或已经在基于x86的设备上运行了很长时间的。也就是说，控制平面软件（负责维护规则集合以及总体控制配置、用户界面的软件）很久之前就可以在x86 CPU上运行了。实际上，这个CPU并不处理用户数据报文，而是采用特殊的交换矩阵以及特制的处理器，这些矩阵和处理器被用来连接输入和输出端口，并且带有特殊的模式匹配硬件，这种特殊硬件本质上是被静态编程的，用来查找特殊的模式，并最终转发、丢弃或修改数据报文。运行在CPU上的系统软件或控制平面将指令（如规则）编程入硬件中。总之，这个分离的系统将大脑运行在x86 CPU上，将处理数据报文的体力活交给专用的硬件。

以前远远达不到要求的现成的网络接口，现在接近了定制设计硬件的数据报文处理性能，这是现代硬件场景下的新现象。此外，现代CPU可以处理大量的模式匹配能力，特别是为数据报文处理优化之后，如Intel的数据平面开发套件（Data Plan Development Kit，DPDK）系统。

鉴于廉价、现成的硬件在数据报文处理上取得的巨大进步，运行虚拟化防火墙实例并非仅仅停留在想像中。虽然不能达到专用硬件性能的100%，但当将虚拟防火墙实例接到一个CPU以及网络接口上之后，就可以用分治的方式来解决这个问题，尽管需要管理更多的活动部件，但可以并且取得名义上相同的方式。这就是说，如果将虚拟防火墙的实例分担在许多x86 CPU上，拥有自己的网络接口，并且恰当地将输入流量导向到这些接口，让它们各自处理总体输入流量的一个子集，就可有效地将输入流量工作负载分担在了许多设备上，而不是依赖于一台大型并且昂贵的定制硬件。

这带来了第二个优点：价格。将工作负载分担在商用硬件上有一个盈亏平衡点，这个点因问题中实际产品的不同而异，所以这里不尝试去猜测是哪一个具体的点了。然而，因为许多网络管理员，正在将很多其他计算任务，迁移至通用的基于x86的数据中心里，可以想象，还有一些闲置的计算容量可用于防火墙处理。能够将同样的硬件用于多种目的是对总体设备成本的一个明显的优化。

图12-3演示了如何构建这样的场景。注意网络中真实和虚拟防火墙服务的混合部署。其中值得注意的是，管理员必须理解虚拟机是连接到真实网络中的，它在网络中的放置是至关重要的，因为这会影响到它的数据包处理速率，以及它所处理的数据包的延迟。例如，虚拟机在地理上的糟糕放置，会导致转发跳数的增加，从而增加数据包在网络中传输的延迟。此外，将虚拟防火墙放置在已经有较高负荷（从CPU处理或者输入接口的角度看）的物理系统上，也可能会导致延迟甚至丢包。

图12-3：部署物理和虚拟防火墙网络服务

对虚拟化防火墙服务所做的最后一个调整是，添加防火墙服务自身的集中式控制。这可以用该服务（和服务所在的虚拟机），以及驱动模式匹配功能的实际防火墙规则的集中式控制组合来实现。如果看过了前一个示例中，虚拟以及真实的防火墙实例，就可以想像一个集中式控制器，是如何从一个中心点，或者以分布式的方式控制以及编排防火墙网络的。前一种情况的优势在于，网络管理员只有一个点需要控制（逻辑上的集中式），以更改网络中任意防火墙的配置状态。第二种去集中式 的示例下，在调整配置之前，管理员需要先了解哪些控制点控制了防火墙的哪个子集。

12.4　网络访问控制的替代方案

网络访问控制（NAC）可以被视为一个防火墙即服务的衍生品或简化物。NAC通常是通过使用交换机/路由器的访问控制表和/或基于策略的，依赖于策略服务器和交换机/路由器之间的半径/直径交互（这在共享接入的基础设施上，每用户会话的情况下是典型的）来实现的。

这些解决方案有它们自身的局限性。关键的是，大多数实现允许支持预编译的（如静态编程的）ACL，而这不太适用于动态（快速变化）的环境。这就是说，规则通过一个配置系统下发到网络中的每个交换机，基本上是对每个路由器进行了重新设置。对于大多数设备而言，这是一个相当耗时的过程，因为配置操作需要几分钟到几十分钟的时间。一些SDN技术的早期使用者，希望利用SDN更加动态的特性来作为NAC的替代策略。

本节使用一个基于OpenFlow的示例，来介绍使用了集中式SDN控制器的网络访问控制。应当注意的是，可以使用其他的机制来实现这一用例，但是OpenFlow的特性使得它在解决这一问题上非常具有吸引力，这些特性与替代方案相比更加完善（在本书编写时）。特别的是，OpenFlow允许在数据报文包头的很大区域上进行匹配，而BGP flowspec（IETF RFC5575）这样的替代品，虽然比静态的ACL更具动态性，但缺少这样大的匹配范围，并且目前还仅局限于对通用地址家族的支持以及IP地址前缀相关的过滤器。2此外，如果厂商在实现OpenFlow协议时，没有重用ACL或者防火墙过滤结构，而是用真正的转发表项，而非转发的一个功能阶段来实现OpenFlow，那么就可以避免典型ACL 的编译困境。这就是说，可以实现无痛且动态的NAC 规则调整。

2.查阅前一章，可以了解扩展flowspec为此目的以及其他目的提高可用性的说明。

当然，作为权衡，这一般会降低首先检查OpenFlow表的特权。3在没有重用ACL表或者防火墙结构的情况下，实现会遇到各种性能以及可扩展性的下降。特别是，一个简单的实现，会真正去尝试原封不动地编程OpenFlow规则，从而失去规则编译所带来的好处。规则编译有效地将规则压缩并优化，保留了它们最重要的部分，这有效地降低了实际编程到硬件中规则的数目和复杂性。这不仅意味着，在硬件上存储这些规则所需要的空间变小，而且避免了不必要的查找或回收规则，带来了潜在的处理上的性能优化。

3.笔者已经看到了客户的招标书中要求将OpenFlow协议视为动态ACL，并且维持默认IP转发表中的“第一转发查找”。但是，据笔者所知，这还没有实现。

通过使用集中式控制器，可以试图解决一个乍看相对简单的问题。就是在一个快速发展的“自带设备”（bring-your-own-device，BYOD）环境中限制被批准的桌面计算机或无线IP电话对企业IMS/SIP子系统的使用，以及限制已注册设备对企业网络的访问。

在展开讨论之前，先提供一些背景信息。虽然IT部门一开始考虑使用带802.1X标识的产品，而事实上并不是所有的设备都支持802.1X，而且为他们办公室选择的IP电话就属于这类设备。此外，在考察一个多厂商解决方案之后，IT部门发现了一些设备之间存在不兼容的问题。所以为了使他们企业的以太网交换机不至于全使用一个厂商的设备，就出现了这个示例。

图12-4展示了这个解决方案的基础。这个解决方案比较直接了当，在OpenFlow控制器上使用简单的融入逻辑的应用程序，来验证进入网络的每个设备的注册信息。支持OpenFlow（v1.0）的设备（如接入交换机）的能力只需要能够在源MAC地址上做匹配，以及进行PACKET_IN和PACKET_OUT操作即可。交换机还必须能够将匹配某个规则的数据包“踢”给控制器，或者将流量调至VLAN。还需要注意的是，底层的网络使用IP/MPLS转发，为边缘到边缘的数据报文传送提供二层/IP基础设施。

图12-4：在混合网络中采用OpenFlow进行简单的网络访问控制

这个组合充当了一个OpenFlow混合网络。4这个混合网络的两个功能之间的连接可以用一个OpenFlow域中的集成路由-网桥实例和OpenFlow的正常功能实现，或者使用一个逻辑端口结构（如逻辑隧道）实现，其一端位于OpenFlow域，一端位于三层路由实例中（一个RIB关联），作为OpenFlow协议的传入/传出端口。

4.将网络边缘像OpenFlow混合网络那样操作是可选的。可能有人会说NAC处于纯OpenFLow网络中是隐含条件。

当客户端设备发送它的第一个数据报文时，交换机会进行一次查找，看匹配那个特定源MAC地址的规则，是否已经在交换机上了。如果没有找到，数据报文将会通过PACKET_IN操作发送给活动的控制器。这个控制器负责在接入交换机中的虚拟交换机上创建规则。控制器也会在这个交换机上指定传入端口。

为了不让控制器上的身份验证胶合逻辑浪费计算周期，可以用一个高速缓存来维持最近在同一个控制器上验证的数据流。这对于数据流在某个交换机上处于非活动状态的情况也有效。因为期望中IT 网络用户是移动的，可以想象，他们会改变无线接入点，这可能会导致他们与网络边缘物理接入点的关联发生改变。如果一条规则存在于高速缓存中，控制器会将规则发送给交换机，并且进行PACKET_OUT操作，这会将原始的数据报文返回给转发流水线。

身份验证的结果可能是如下之一。

- AUTHENTICATED_MAC_PHONE
此MAC地址是一个注册过的MAC 地址，而且它属于经过批准的手机类型，可以接入IMS/SIP子系统。这种情况下，发送到交换机上的流表修改信息将表明，与该MAC地址相匹配的所有流量都被允许访问网络的IMS/SIP区域。这可以简单地用与该IMS/SIP基础设施（可以是二层或三层）相连的逻辑端口所匹配的出端口动作来表示。根据底层网络的管道系统——例如，如果不是采用逻辑 隧道来表示这个访问，而是采用共享的三层结构及OpenFlow的传统转发动作（NORMAL）——该规则可能需要进一步的加工，以特别地把分配给IMS/SIP系统的地址前缀作为目的IP来匹配。

- AUTHENTICATED_MAC
此MAC地址是一个经过注册的MAC地址，但该设备不是电话。在这种情况下，发送给交换机的流表修改信息，将允许所有与该MAC地址相匹配的流量，访问网络的内部网络/互联网区域。这可以通过一个非常通用的、基于此源MAC地址和连接到该网络区域的出端口的流表规则来实现，这有着类似的关于底层管道系统的注意事项。在采用与传统网络共享的三层结构以及OpenFlow的传统转发动作（NORMAL）的情况下，通过附加的匹配规则，可以显式地拒绝目的IP是SIP/IMS区域前缀的数据流。

- AUTHENTICATION_FAILED
此MAC地址未注册。在这种情况下，发送给交换机的流表修改信息将创建一条规则，与所有来自那个MAC的流量，以及一个代表了网络“洗罪所”区域（这是客户对丢弃分组或者注册服务器所在网络的俗称）的出端口相匹配。

本例中有一些潜在问题需要修正或者还未得到解决，解决它们可能会改进这个示例。到目前为止，只展示了一些最起码的动态策略，这很难用接入交换机上的传统访问控制列表来表达。5在典型的网络中，更为复杂的ACL比较常见。

5.在这个例子中，SDN也被用来一般化访问控制部署，并且可以用一种与厂商无关的方式来部署，不使用任何特定于某个厂商的ACL语法/语义，而这种ACL语法/语义是采用标准化SDN协议作为配置工具的基本诉求之一。

12.5　采用虚拟防火墙来扩充用例

当需要为任何经过验证的MAC地址提供支持时，这个模型的局限性就显露出来，此时不能再使用简单的网络访问控制。这就开辟了一系列可能性，从原先的仅支持VoIP设备，转而到任何计算设备都可以被连接到企业IT网络。处理来自桌面电话和笔记本电脑软件电话，或者有着更高服务质量要求的媒体应用（例如，使用一个特殊的DiffServ字段（DSCP）来标记数据报文，让该流量在转发基础设施中获得更高服务类别的对待），使得这个简单的场景变得更加复杂。6

6.在使用OpenFlow（以逐节点方式实现QoS处理，假设所有的节点都被OpenFLow控制）时，还有其他的选项。例如，“可选的” Set-Queue（设置队列）动作可以将数据报文分配到一个队列中，假设交换机支持队列以及队列属性发现（对队列参数MIN/MAX 速率的配置以及使用EXPERIMENTER字段交换信息在OpenFlow 1.2及以后版本中支持）。这可以和OpenFlow 1.3中“可选”的Meter结构组合使用，以影响很多不同的QoS动作。然而，因为这些特性是新的、可选的，而实际上的队列配置仍然和OpenFlow线上协议分离，所以本章采用了一个更简单的示例，这个示例依赖于外部的（非OpenFlow 的）QoS处理。

不幸的事实是，很多原因导致了简单的数据流匹配规则在这里不起作用。第一，大多数媒体应用程序在UDP封包中使用RTP，这导致数据流建立之后，发送者和接收者会使用不固定的端口。数据流通过一个独立的控制协议建立。这种协议中的典型是SIP，但是在某些高级的服务中，控制频道可能被加密，这可能会降低特征检测的效率。完全不使用防火墙，并且给予所有未知的UDP数据包优先级的替代方案，很容易被终端用户滥用。在这一点上，需要防火墙提供的传统服务，使用应用 程序特征来检测这些数据流。这就需要防火墙监控一部分流量或数据流样本，这部分流量或数据流样本可以用来检测应用程序特征。

这种方法有两种可能的解决方案。第一种，在控制器之上建立一个类防火墙的应用程序，7或者第二种，在数据流的某个位置用一个防火墙（物理的或虚拟的）来识别流量。这个应用程序可以进行恰当的QoS处理。要在OpenFlow控制器的基础上构建这个应用程序，必须使用OpenFlow交换机/控制器组合的PACKET_IN功能或者创建一个测试接入端口（tap）规则。

7.“ 之上”并不意味着防火墙应用程序虚拟机和控制器在一个设备上运行，因为OpenFlow的北向API通常是RESTful的接口。但是需要注意的是，将数据报文从控制器推送到类防火墙应用，所产生的任何延迟都可能会导致以及影响应用表现出的“响应速度”。对于这种应用，如果媒体数据流是一个视频（特别是视频聊天），这个数据流很可能会很大并且长度较大（假设这个长度函数更像是一次会议，而会议时间通常是以15分钟的增量来计算的）。如果所有的媒体流都是VoIP，应用程序的响应速度将会更加关键，因为数据流的长度可能相对较小（当数据流表项就位，启用QoS处理时，相应的数据流可能已经停止了）。

为了避免让防火墙应用负荷过重，可以使用主动式数据流规则，来限制发往未知UDP端口的PACKET_IN流量。在这种情况下， 必须小心并且了解不同版本的OpenFlow在这个机制上所做的改动。如果控制器和交换机不支持OpenFlow 1.3，那么PACKET_IN机制必须在控制器和代理之间使用TCP控制会话。因为代理维护着TCP 会话的序列号，所以很难甚至不可能将其从数据包路径8上移除或者对数据报文处理进行任何形式的性能增强，使得用这种方法实现防火墙应用程序变得 不可行。需要注意的是，随着OpenFlow 1.3的出现，可以使用UDP数据流来进行PACKET_IN操作，这就使得在控制器上的应用变得更加有用。9

8.这个路径是传统意义上路由器和交换机的“慢”路径（更低的数据包吞吐量，交换机/路由器上代理进程带来的更多的CPU使用）。
9.在本书编写时，使用基于UDP的PACKET_IN功能的经验还很少。

在控制器上构建应用程序的另一个方法，是创建一条tap规则，将流量镜像到防火墙应用程序。这条规则将复制输出到两个单独的端口，作为匹配未知UDP数据流的动作。10在这种情况下，当应用程序感知到了媒体应用，并且识别了特定流的端口后，应用程序会降低/丢弃匹配的流量并且通过控制器API发回数据流变更信息。

这种方式的一个例子可以在FortNox11/FRESCO12组合（SRI）中见到，它结合了一个冲突缓和模块（确保多个来源的数据流规则都遵循策略）以及一个脚本/开发框架，该框架允许插件式模块来反映/扫描/影响流量转发。

10.顺便提一下，虚拟Tap应用是OpenFlow控制器的一个特殊应用程序，它使用同样的机制，将流量镜像发送到一个监控设备上。
11.http://www.csl.sri.com/users/vinod/papers/fortnox.pdf
12.http://www.openflowsec.org/OpenFlow_Security/Publications.html

由于基于控制器（on-top）和tap的解决方案的吸引力有限，所以可以尝试使用联机防火墙的替代解决方案，其操作UDP流量的方式可以减轻防火墙的负荷（图12-5）。

图12-5：混合网络中修改后的网络访问控制，使用防火墙以及OpenFlow

这个设计样品的一些细节包括：

- IRB（或逻辑隧道）接口用于OpenFlow的传统转发动作（Normal）来转发所有的“非-UDP流量”至路由实例。在交换机/路由器的OpenFlow配置中，这个IRB（或逻辑隧道）接口被配置为一个OF端口。

- 两个逻辑交换结构被用来构建一个环路，使得防火墙可以对未知的UDP流量做QoS处理。逻辑交换机允许出于管理原因进行的规则划分。外部自环（loopback）可以通过防火墙在物理上创建（相对在逻辑交换机之间而言）。在进行这项设计时，通常认为交换机端口资源要比防火墙资源廉价。

- 交换机-B中的端口到端口的OpenFlow规则将所有从防火墙返回的流量，包括可能处理过的未知UDP流量，通过回路推送至交换机-A。之后，交换机-A中的端口到端口规则将来自自环的流量推送至IRB（以及一个静态关联的QoS策略）。

12.6　反馈与优化

运行在控制器上以及防火墙内部的防火墙应用程序都有一个共同的优化目标：将通过防火墙的流量最小化。这基于防火墙资源在管理扩展性时，带来了额外的硬件或操作上的成本的假设。一旦一个特定的媒体流，包括非固定的端口，被防火墙应用程序所识别，就需要一个反馈机制来安装一条特定的数据流规则，让这个流量通过流水线传送至传出端口。

然而，在这个OpenFlow例子中，QoS处理需要控制器/交换机要么支持可选的SET QUEUE基本操作，正如之前的注脚所述，这个基本操作有一个相关的对于消息传递的支持，以发现端口队列的分配以及性质；要么支持可选的直接设置数据包DSCP的功能。后者将依赖于外部设置的传出端口上的QoS策略。支持这两个功能中任何一个的OpenFlow最低版本是1.2。

在网元设备、服务、网络中的逻辑点之间创建反馈功能对于优化网络资源的使用是十分关键的，并且，不论使用的是什么SDN控制方案或协议，这都是许多示例的基础。更确切地说，虽然在本节中使用了OpenFlow的示例，但在网络控制和网络资源之间，开启并促进反馈回路却是十分基本的。这种反馈回路原理将在接下来的示例中进行讨论。

12.7　入侵检测/威胁缓解

图12-6所示的入侵检测/威胁缓解系统（IDS）使用了一个相似的策略，通过将规则划分为几个部分，来将网络服务网元设备（一个物理或虚拟IDS系统）的负荷最小化。

图12-6：采用OpenFlow的动态威胁缓解

- 利用IP源和目的地址前缀进行数据流转发的通用规则。

- 为这些源和目的之间特定和被批准的数据流，准备的更精细的（如更长的匹配以及更高的优先级）规则。

- 处理数据流失配（UNKNOW 流量）的规则，以及一条使用类似tap应用程序那种动作集来复制数据包，并且将这一失配转发给IDS的规则。IDS软件可以进行设备分析数据流特征匹配以及其他的任务。

- 根据分析的结果，一个允许该流量通行的特定的数据流表项，可能会通过对位于拦截点的OpenFlow控制器，或者一个特定流表项的API调用来安装。这项操作也可能是DROP（丢弃）该数据流，这条规则可以被安装在入口交换机上。

无论是哪一种情况，该数据流都不会继续经过IDS/UTM。

理想情况下，这个反馈回路会尽可能创建一个学习系统，这样就可以利用这些学习到的行为，补全默认的规则和策略。入侵检测以及威胁缓解的更偏向逻辑驱动的方面，例如追踪期望的行为或分析发生的变化的逻辑，比如一个已知的打印设备开始向一个计算设备发送数据流，乃至网络映射或端口扫描，可能很难用一个小规模的规则集合来实现，所以不采用学习的方法。然而，在这个具体的示例中，还是可以期待它使用某种程度的学习机制。

如果将链接不同服务视为一个SDN应用程序13，那么不仅反馈回路变得可以优化，触发的操作（如基于DPI检查以及策略规则）也可以使得数据流路径变得更加动态。这进一步地限制了学习更大规模永久数据流规则集的能力。

13.本章一直讨论NAC以及它的衍生示例，但是将示例迁移到了服务虚拟化的领域，即使没有显式地展示一个服务链。

这种反馈回路的示例数不胜数，特别是，图12-7所示的最近移动领域新增的3GPP流量导向功能（TDF）展示了类似的功能。

图12-7：流量导向功能

TDF（一般是一个DPI设备）被PCRF（通过Sd接口）所控制，来寻找特定的应用程序数据流，当流被检测到时，TDF使用同样的接口来向PCRF报警。反过来，PCRF可能命令PCEF用Gx接口安装一个变更规则。

12.8　小结

本章展示了输入流量检测的用例。这些示例展示了如何用简单的防火墙规则，或者访问控制列表（ACL）来将输入流量进行分类，以及采取相对应的操作。这里的防火墙既包括了传统的防火墙设备，也包括了虚拟防火墙设备。接着，本章扩充了这些简化的示例，来演示如何使用SDN的两个关键的原则：逻辑集中式的控制以及输入流量检测，来替换网络访问控制（NAC）协议。之后，展示了如何进一步应用这种方法实现动态威胁缓解。在不断深入的过程中，讨论了为什么启用另一个软件定义网络的原则即，应用-控制器反馈回路是关键的，并且特别讨论了为什么没有它就无法进行某些优化。

第13章　最后的思考与结论

13.1　什么是真正的SDN

大多数推动探索SDN的想法都是从革命性的理念开始的，但往往随着经验的积累，这些想法都变得常态化了。这种现象随着原型构建、实验室试验研究，以及前期部署的演进过程而自然地产生。所有这些工作都最终导致人们不断地革新观点，（希望）使网络可以更有效地提供服务。图13-1以可视化的方式显示了这些观念如何使当前的网络运行方式，变为一些不同的/新的未来运行方式。

图13-1：SDN将当前的运行方式（Present Method of Operation , PMO）调整为一个更为优化的未来运行模式（Future Mode of Operation，FMO），这个未来运行模式或许不是SDN最初所宣称的那么激进（图中的网状区域）

虽然现在为SDN选择一个成功技术还为时太早，甚至对SDN下一个成功的定义都还太早，但有一件事是肯定的，即对SDN的探索将改变目前的网络运行方式。现在，问题来了：这种改变是否会将使运行方式变得更好？

这方面确实有一些进展，但可能不是很明显，因为很多情况下都是暗藏于表面之下的。

我们不应忘记，这是运营商的需要，正是他们在推动SDN的研发。截至2010年，大型网络运营商的运作处于创新的停顿点。在一个大规模的多厂商环境中支持无数服务所需的运营和业务支撑系统（OSS/BSS）成了创新上的拖累。更糟的是，这会对运营商的财务状况造成拖累。新的开启视频功能的、“永远在线”的移动设备的大量涌入，以及内容消费方式上的根本转变（即内容现在成为了网络媒体流），触发了对基础设施的惊人的增长需求。总之，互联网的模型正在变形为一种在运营商之间快速变化的、以内容为中心的相互关系，而非过去那种层次化的慢慢改变的访问范式。这基于这样一个事实，现有厂商的软件产品或新厂商的硬件产品所提供的新功能所开启的新的网络服务，运营商可能最少需要18个月的时间来开发、集成和部署。而与此同时，那些新兴的运营商（如谷歌、亚马逊和Facebook）却已找到了一种真正更好的方法。

需要坚持下述基本思想，因为它们在某种程度上可以解决目前的紊乱和停滞：

- 把服务开通配置从厂商特定的语义依存关系中解脱出来。

- 把网元设备虚拟化到一定程度，以便通过由池化和动态迁移所提供的灵活性，实现更大的规模和更低的成本。

- 把网络拓扑抽象为一种服务，以这种方式把网络应用程序从需要知道网络协议奥秘、或者需要了解海量数据中解放出来。

- 普遍地推广应用程序与网络之间信息的公开交换。

SDN实际上可能重新定义我们关于网络管理的设想和预期。对于迅速增多的虚拟化网元设备，如虚拟机管理程序中集成的交换机（hypervisor switch）、路由器和网桥，SDN控制器将以使人们想起传统的EMS/NMS/OSS的方式，通过提供服务开通配置、事件管理和分析数据流功能来行使职责。

我们已经尝试在本书中说明SDN的宽广范畴：

- 分布式和集中式控制模型之间的冲突。

- OpenFlow 如何能融入对SDN 的讨论，但现实中OpenFlow 并没有定义SDN，甚至也不会再支配SDN。

- 控制器的设计如何随着时间而演变，从单一的、实践上仅能用于试验和研究的实体，演进为集群式的/联盟式的系统。它们已经演进为支持（南向）多协议的实体，并采用大量的基础设施来支持应用程序的开发和状态一致性的设计。

- SDN 与虚拟化的融合所启动的虚拟化和主要的应用，以及这种融合推动SDN控制器成为网络管理的未来角色所产生的影响：数据中心的服务编排（今天）、网络功能虚拟化（不久的将来）、充分集成的虚拟化计算、存储和网络的服务链（将来）。

- 可编程性，对开放性和标准（这隐含在概念里，但在现实中却并不完整）的需要，以及控制器演变为提供健壮的、以网络为中心的应用服务的开发框架等基础目标。

平凡的细节往往阻挠像SDN 这种看似不错的想法。在SDN中，这些细节与管理技术有关，这对于大多人而言不太可能令人兴奋。但是现实情况是，我们需要艰苦的工作并付出平凡的努力来实施新的范式，并优化此范式及其经济学。SDN的旅程已经开始了，但我们预测距离其完成还有很长的路。

13.1.1　经济学

很多写博客的人都表示，虚拟化和SDN组合对于消费者而言顶多是一个经济上的零和命题。而在最坏的情况下，它实际上是一个否定命题。个人经验表明，这在目前来说是真的。研究公司（如IDC）的最新数据也显示了相同的结论。事实上，有研究表明，数据中心的IT管理成本因虚拟化的崛起而增加了80％。但是，这并不意味着应该就此止步。我们还有许多工作要做，以便跨越此点，达到SDN 可以真正为网络运营商提供净收益或利润的境界。

称为OpenDaylight项目的开源SDN控制器的引入就是一个证明，它可能涉及进一步优化商业部署的需要。这一步表明，市场实质上承认了SDN的价值在于应用程序，而不在于SDN控制器甚或是虚拟机管理程序。

消费者仍然盼望并需要SDN（特别是如果他们已经接受了虚拟化技术的情况下）。

SDN在短期内的经济结果可能是解决方案的组件成本的转变，因为SDN解决方案创建总和上更大的软件组件（无论是新的业务应用程序，还是新的/必要的管理应用）。

这并不是对网元设备（硬件）厂商的现有生态系统的威胁，只要他们自己的软件销售带动了自己的硬件销售（即他们保留了大部分或全部的金额）。有些厂商甚至宣称由于采用SDN的概念，他们在高端硬件上获得了收益。

嵌入式网元设备厂商都在积极地针对其嵌入式平台（如BNG）的虚拟化成本和收益做分析。而这样做时，他们必须考虑到进入新领域可能会做的优化（例如，丢弃不必要的会使代码库变得杂乱的功能、以更具成本效益配置的方式来拆解组件）。目前来看，硅芯片封装的性价比，比目前这代（带IO 优化的）Intel/ARM处理器[在每Gbit/s 的功耗和封装（footprint）方面] 更具有优势。

是否会永远这样，这还有待观察，但他们已经开始了服务的重构，以使之符合客户的期望，创造平台解决方案的新的、优化的版本，包括采用x86计算。

所以，虽然SDN 的直接经济影响是很难确定的，但其间接后果已经开始显现。

13.1.2　SDN实际上与运行和管理相关

本书还没有完成对SDN 在管理方面的探讨，因为作为新一代运营和业务支撑系统（BSS/OSS）它还在不断演进，以便与一个更加虚拟的/ 可编程的/灵活的网络并驾齐驱。

传统的运营和业务支撑系统（BSS/OSS）厂商，如BMC 公司、Amdocs公司、CA公司等，都在云OSS市场中与IPsoft、Tail-f和Service Now等公司进行竞争，在这些环境中实时OSS的革新（例如，纳入集成策略引擎和嵌入式分析等能力）已经开始。

这样的环境也为传统网络设备厂商（如思科公司、阿尔卡特朗讯公司）创造机会，以使其更充分地参与下一代OSS/BSS（以及令人尊敬的SDN重量级公司，如VMware公司等的参与）。

最后，SDN的重点和动机之一就在于优化操作。本书前面谈到了网络与应用程序之间的鸿沟，正是这个比喻为我们的判断提供了依据：SDN到底为网络用户和运营商解决什么问题，或者说SDN该把什么功能做得更好？

13.2　SDN的多种定义

SDN仍在演进为运行层次的抽象。关于“SDN是什么”有不同的一般性定义，其不同之处与保留的分布式控制平面的量相关（如图13-2所示）。

ONF提供了“转发平面型SDN”（forwarding plane SDN）的定义（推倒重来的全新设计），其中已经没有分布式控制平面的真正痕迹了（可以说，在像OAM和BFD等需要高频率回路的应用中，还有一个不可或缺的分布式控制平面）。转发平面SDN的抽象层是逐跳转发的表项，以便构建一个流的路径（与之对应的是“叠加型SDN”模型中，仅在该网络的边缘对隧道的首和尾进行编程）。

图13-2：SDN的多种定义（抽象和控制平面)

“叠加型SDN”（overlay SDN）的定义，侧重于建立灵活的叠加隧道，以便创建虚拟网络，并假定分布式控制平面存在和作用于承载网络，且实际上很有帮助。例如，ISIS擅长发现网元设备，非常稳定，因而在承载网络的“网络自举”问题上很有帮助。承载网络的分布式控制平面被假定为在一定程度上是优化过的（例如，高度支持等价多路径，即ECMP）。虽然这种模式假定对现有的分布式控制范式的复用，但与“控制平面型SDN”相比这是一种简单的分布式控制，因为它并没有假定使用MPLS或类似于BGP这样的更高级别的分布式控制。这种简单的分布式控制范式结合了控制器来管理大部分外部状态（这些状态可能已在“控制平面型SDN”模型中被BGP地址族携带了）。

传统的网络设备厂商提出了“控制平面型SDN”（control plane SDN）的定义，它关注现有IP/MPLS RIB（以及关注路由和安全策略）的可编程性。这种模式假定对现有的分布式范式（有一些潜在的简化）予以重用（reuse）。这种更高的抽象级别，使控制器不再需要了解“转发平面型SDN”定义中伴随而来的网元设备硬件的转发能力：

- 在“控制平面型SDN”里，可以采用逻辑上的集中式，特别是集中化的代理（proxy），提炼必要的适用于较小的/弱的转发实体（例如，一个基于虚拟机管理程序中集成的交换机）上特定应用的转发表项集合。

- 在“控制平面型SDN”中，可以进行简化[例如，用网段路由（segment routing）来消除通过LDP或RSVP的标签分发，或用XMPP来省去创建和填充VRF的大量配置]。

- 在“控制平面型SDN”中，通过网段路由结合PCE服务器的可编程性扩展（不必创建LSP 的叠加网络全网状链接），有可能做到基于源/目的的路由。

对于不同的SDN模式，“逻辑上集中式，但物理上分布式”的口头禅（提出这个说法，是用来解决高可用性的、地理上分散部署等现实问题）的核心仍然是分布式，所以“状态达成共识”的问题仍在这种“逻辑上集中式、但物理上分布式”的新分布式机制中存在。

13.3　人们正在取得进步吗

在写这本书时，作者看到很多优秀的应用程序通过私有API 绑定到私有控制器。各种“孤岛思维”的利润增值方式，已经不适合SDN已经开始着手解决的、当前运营和业务支撑系统（OSS/BSS）问题。如果没有真正的应用程序可移植性和对互操作性的一些合理期望，SDN就不会进步，并会作为另一个风潮而不了了之。这还有待观察：控制器的框架式方法及OpenDaylight 项目的倡议能否创建一个事实上的标准，或者，IETF、ETSI、ITU和ONF等组织中更长的标准化之路是否能带来解决方案或只是在添乱。

虽然对SDN的概念及其吸引人们的那些方面感到激动是很好的，但这样也很容易陷入了那种看见独角兽的神话。为此，作者认为还有很多的研究和扎实的辛勤工作需要做，例如故障排除（叠加网比承载网更难做故障排除，因为底层转发关乎所有流操作，需要有一个潜在的新工具集）、安全性、验证和策略（其中大部分是今天正在被学术界所研究的，并且慢慢地进入标准和企业联盟的考虑范围）。这些领域会让我们想起在运行领域关于新技术所做的多年辛勤工作，例如针对MPLS 或IP 优化它们在商业网络中的使用。这些平凡的工作往往还走在SDN 前面。所以考虑到这一点，本书封面上的鸭子形成了对SDN今天的状态及其未来的恰当比喻：有非常多“水面下的”实际工作正在开展，它们可能是不可见的或是并不明显的。但是，如果这些工作能继续开展下去，就可以很好地推动这只鸭子抵达其目标。

术语表

A | affinity亲和度
API（Application Programming Interface）应用编程接口
ALTO（Application-Layer）应用层流量优化
B | Bandwidth Calendaring带宽时间规划
Bandwidth Calendaring Application带宽时间规划应用
Broadcom博通公司
C | code point字段
commodity hardware商用硬件
connectivity连通性
CSPF带约束的最短路径优先
D | data center fabric数据中心交换矩阵
DB数据库
DC 数据中心
degree of multitenancy 多租户共享度
Diffusion of Responsibility 责任分散
E | elastic computing弹性计算
element 网元设备
Entropy Label 熵标签
Ethernet Tag 以太网标签
EVPN 以太网VPN
F | flow流
FIB转发信息库
H | hockey stick graph曲棍球杆曲线
homogeneous同构的
hyper virtualization 超虚拟化
hypervisor 虚拟机管理程序
HAL 写硬件抽象层
I | ICMP（Internet Control Messages Protocol）网际控制报文协议
Instance 实例
Internet 互联网
I2RS 路由系统接口
intermittent no synchronization 间歇性非同步
L | LISP（Locator ID Split） 位置标识分离
M | MAC（Media Access Control） 媒体访问控制
make before break 先接后断
Manipulation 操控
Middlebox 中间盒
molibity 移动性
MOSPF（Multicast Open Shortest Path First）多播开放式最短路径优先
MPLS（Multiprotocol Label Switching）多协议标签交换
MPLS stacked label MPLS层叠标签
N | NB INTFC with MANO ORCH 与MANO 编排器的北向接口
(network) element 网元设备
Northbound Interface 北向接口
O | Orchestration 服务编排
OSI（Open System Interconnection）开放式系统互联
Overlay叠加
OSS运营支撑系统
P | pod机架
Proprietary专有
PCE（path computation engine）路径计算引擎
R | rack机架
RIB 路由信息库
S | SB INTFC with infrastructure与网络基础设施南向接口
Scheduler调度器
SDN（Software Defined Networks）软件定义网络
signaling发信令
Southbound Interface南向接口
SPF 最短路径优先
spine/leaf骨干/叶结点
suspended animation历程中断
T | TCP（Transmission Control Protocol）传输控制协议
Tenant租户
Tenant Load Balancer租户负载均衡
Topology拓扑结构
U | UDP（User Datagram Protocol）用户数据报协议
Underlay network承载网络
v | VM虚拟机
VPN虚拟专用网络
W | wire protocol线路协议

关于封面

本书封面上的动物是秋沙鸭（Mergus merganser），也被称为普通秋沙鸭。这些大型的鸭子生活在欧洲、亚洲以及北美的河流和湖泊周边的森林栖息地。

这些鸟有一个绰号“锯嘴鸭”（sawbills），因为它们的喙上有帮助它们抓鱼的锯齿，鱼是它们的主食。它们也会吃软体动物、甲壳类、两栖类和其他水生猎物。它们一贯的狩猎技巧是在水面上漂一段距离，然后一边捕鱼一边返回上游，一路上反复地潜水前进。它们是游泳健将，并且通过视觉来寻找它们的大部分猎物。

雄性和雌性秋沙鸭有着不同的羽毛，雄性为白色，有着深绿色闪光的头部和背部，而雌性的羽毛是更柔和的灰色，头部红褐色。它们喜欢在树洞中筑巢，但也会选择巢箱或石隙，这取决于它们所处的环境。早春时节，雌性会产下9~12颗蛋，然后用约一个月时间来孵化这些蛋。破壳而出的一两天之内，小鸭子就会下水，并且很快学会用小鱼和昆虫来填饱肚子。

这些鸭子有社会性，生活在小群体中。冬季，它们偶尔会聚成一个规模数千的“游荡的鸭群”。每只秋沙鸭平均每天吃掉280~560 克的鱼，这就可能与捕鱼业产生矛盾。

封面的图片来自于滨江自然历史博物馆（Riverside Natural History）。封面字体是Adobe ITC Garamond，正文字体是Adobe Minion Pro，标题字体是Adobe MyriadCondensed，代码字体是Dalton Maag 公司开发的Ubuntu Mono。

Table of Contents

版权信息
版权声明
O’Reilly Media, Inc.介绍
蒋林涛推荐序
专家推荐语
译者序

2014：超越炒作，进入部署SDN的时代（David Ward中文版序）

作者中文版序
David Meyer序
David Ward序
前言
Thomas Nadeau的致谢
Ken Gray的致谢
第1章　引言

第2章　集中式与分布式的控制平面和数据平面

- 2.1　引言

- 2.2　控制平面和数据平面做什么

- 2.2.1　控制平面
- 2.2.2　数据平面
- 2.2.3　在控制平面和数据平面之间传递信息
- 2.2.4　为什么控制平面与数据平面分离变得重要

- 2.3　分布式控制平面

- 2.3.1　IP和MPLS
- 2.3.2　建立IP承载网
- 2.3.3　收敛时间
- 2.3.4　负载均衡
- 2.3.5　高可用性
- 2.3.6　建立MPLS叠加
- 2.3.7　组播复制

- 2.4　集中式控制平面

- 2.4.1　逻辑上的集中式与字面含义上的集中式
- 2.4.2　ATM/LANE
- 2.4.3　路由服务器

- 2.5　小结

第3章　OpenFlow

- 3.1　引言

- 3.2　OpenFlow线路协议

- 3.2.1　复制

- 3.2.2　 FAWG（转发抽象工作组，Forwarding Abstraction Workgroup）

- 3.2.3　配置和扩充性（Extensibility）

- 3.2.4　体系结构

- 3.3　混合方案

- 3.3.1　午夜行船模型

- 3.3.2　双功能交换机

- 3.4　小结

第4章　SDN控制器

- 4.1　引言

- 4.2　基本概念

- 4.2.1　VMware的控制器
- 4.2.2　Nicira的控制器
- 4.2.3　VMware/Nicira的控制器
- 4.2.4　OpenFlow相关的控制器
- 4.2.5　Mininet仿真器
- 4.2.6　NOX/POX控制器
- 4.2.7　Trema控制器
- 4.2.8　Ryu控制器
- 4.2.9　Big Switch公司/Floodlight控制器

- 4.3　以网络三层为中心的架构

- 4.3.1　三层VPN的控制器

- 4.3.2　路径计算单元（PCE）服务器

- 4.4　Plexxi公司的控制器
- 4.5　Cisco公司的OnePK控制器
- 4.6　小结

第5章　网络可编程性

- 5.1　引言

- 5.2　管理接口

- 5.3　应用程序与网络之间的鸿沟

- 5.3.1　命令行界面（CLI）
- 5.3.2　NETCONF和NETMOD
- 5.3.3　SNMP

- 5.4　现代的编程接口

- 5.4.1　发布和订阅接口
- 5.4.2　XMPP
- 5.4.3　谷歌公司的Protocol Buffers
- 5.4.4　Thrift
- 5.4.5　JSON
- 5.4.6　I2RS

- 5.5　现代的服务编排

- 5.5.1　OpenStack
- 5.5.2　CloudStack
- 5.5.3　Puppet

- 5.6　小结

第6章　数据中心的概念与结构

- 6.1　引言

- 6.2　多租户数据中心

- 6.3　虚拟化多租户数据中心

- 6.3.1　服务编排
- 6.3.2　连接租户到互联网/VPN
- 6.3.3　虚拟机迁移与弹性
- 6.3.4　数据中心互连（DCI）
- 6.3.5　关于数据中心分布式计算的谬误
- 6.3.6　数据中心分布式计算的陷阱

- 6.4　数据中心网络的SDN解决方案

- 6.4.1　网络承载层

- 6.4.2　叠加网络

- 6.5　小结

第7章　网络功能虚拟化

- 7.1　引言

- 7.2　虚拟化与数据平面I/O

- 7.2.1　数据平面I/O

- 7.2.2　I/O小结

- 7.3　服务工程路径（Service Engineered Path）

- 7.4　服务位置与服务链

- 7.4.1　元数据
- 7.4.2　一种应用层方法
- 7.4.3　规模

- 7.5　ETSI NFV

- 7.6　非ETSI NFV

- 7.6.1　Middlebox研究
- 7.6.2　Embrane/LineRate
- 7.6.3　平台虚拟化

- 7.7　小结

第8章　网络拓扑结构与拓扑信息抽象

- 8.1　引言
- 8.2　网络拓扑结构
- 8.3　传统方法
- 8.4　LLDP

- 8.5　BGP-TE/LS

- 用BGP-LS来支持PCE

- 8.6　ALTO

- BGP-LS和PCE与ALTO互动

- 8.7　I2RS拓扑

- 8.8　小结

第9章　构建SDN框架

- 9.1　引言
- 9.2　先写代码，再问问题
- 9.3　瞻博公司的SDN框架

- 9.4　IETF的SDN框架

- 9.4.1　SDN（P）

- 9.4.2　ABNO

- 9.5　OpenDaylight的控制器/框架

- 9.5.1　API
- 9.5.2　高可用性和状态存储
- 9.5.3　分析
- 9.5.4　策略

- 9.6　小结

第10章　带宽调度、操控和时间规划的用例

- 10.1　简介

- 10.2　带宽时间规划

- 10.2.1　基础拓扑结构以及基本概念
- 10.2.2　OpenFlow和PCE拓扑结构
- 10.2.3　配置示例
- 10.2.4　OpenFlow业务开通示例
- 10.2.5　控制器增强
- 10.2.6　采用PCE配置的叠加网络示例
- 10.2.7　深入调研：大举向新领域进军

- 10.3　在即时CSPF中使用大数据和应用程序超虚拟化技术

- 10.4　扩展拓扑结构

- 10.5　小结

第11章　数据中心叠加网、大数据和网络功能虚拟化的用例

- 11.1　引言

- 11.2　数据中心服务编排

- 11.2.1　创建租户和虚拟机状态
- 11.2.2　转发状态
- 11.2.3　数据驱动的学习
- 11.2.4　控制平面发信令
- 11.2.5　对扩展性和性能的考虑

- 11.3　Puppet（DevOps解决方案）

- 11.4　网络功能虚拟化（NFV）

- NFV的可移动性

- 11.5　优化的大数据

- 11.6　小结

第12章　输入流量监测、分类及触发操作的用例

- 12.1　引言
- 12.2　防火墙
- 12.3　防火墙即服务
- 12.4　网络访问控制的替代方案
- 12.5　采用虚拟防火墙来扩充用例
- 12.6　反馈与优化
- 12.7　入侵检测/威胁缓解
- 12.8　小结

第13章　最后的思考与结论

- 13.1　什么是真正的SDN

- 13.1.1　经济学

- 13.1.2　SDN实际上与运行和管理相关

- 13.2　SDN的多种定义

- 13.3　人们正在取得进步吗

术语表
关于封面
目录