一、实验内容

内容：基于于北向API开发一个简单的应用，实现网络拓扑中最短路径的查找，并开发应用实现基于SDN网络的链路故障恢复功能。

具体要求：

1、在链路故障后，使用最短路径算法来选取新的传输路径。

2、在网络中所有链路均正常的情况下，h1到h2的传输路径为h1às1às4às5àh2。假设此时s1às2的链路发生故障断开连接，那么此时路径h1às1às4às5àh2便不再可行。为了保证主机h1和h2之间的正常通信需要查找新的路径，在链路故障发生时，实现主机之间通过新的路径传输数据。当s1和s4之间断开连接时，h1和h2会及时发现链路故障，同时及时查找出新的路径h1às1às4às5àh2，通过新路径传输数据。

二、实验流程

三、实验步骤

1.网络拓扑搭建

运行结果：

2.启动RYU

添加有关链路故障恢复功能的函数，包括删除交换机流表项和获取端口信息两个函数：

defdelete_flow(self, src_ip=None, src_port=None, dst_ip=None, dst_port=None, datapath =None):

        ofproto = datapath.ofproto

        parser = datapath.ofproto_parser

        inst =[parser.OFPInstructionActions(ofproto.OFPFC_APPLY_ACTIONS,actions)]

    mod = parser.OFPFlowMod(datapath=datapath,out_port=dst_port,

                    out_group=ofproto.OFPG_ANY,

                                    command=ofproto.OFPFC_DELETE,

                                    match=None,instructions=inst)

        datapath.send_msg(mod)

@set_ev_cls(ofp_event.EventOFPPortStatus,[CONFIG_DISPATCHER, MAIN_DISPATCHER, DEAD_DISPATCHER, HANDSHAKE_DISPATCHER])

    defget_OFPPortStatus_msg(self, ev):

        msg=ev.msg

        datapath=ev.msg.datapath

    dpid = msg.datapath.id

        ofproto=datapath.ofproto

        parser=datapath.ofproto_parser

    port=msg.desc.port_no

        #key1 = (dpid, port)

    #dpidPort_to_ip=self.network_monitor.DpidPort_to_ip[key1]

    reason=msg.reason

        if reason==ofproto.OFPPR_MODIFY:

        self.delete_flow(datapath=datapath,dst_port=port)

对于delete_flow函数，功能为删除交换机的流表项。调用RYU自带的parser.OFPFlowMod函数，对比add_flow函数，最主要的差别即为将内部的变量command变成ofproto.OFPFC_DELETE，代表流表删除。

对于get_OFPPortStatus_msg(self,ev)函数，功能为获取端口信息，一旦发生链路故障，获取发生故障的交换机的端口信息，然后调用delete_flow函数，删除这些交换机的流表信息。

运行结果：

3.分别h1 ping h2和h2 ping h1

结果：均可ping通。当h1 ping h2时，路径为s1às4às5，path含义：从switch1的1端口进，从switch1的3端口出，从switch4的1端口进，从switch4的2端口出，从switch5的2端口进，从switch5的3端口出。同理，h2 ping h1的路径为s5às4às1，均为最短路径。

4.重新进行h1 ping h2，并在ping的过程中手动断开switch1和switch4的连接

最初，传输路径为s1às4às5，当s1与s4断开，即网络传输路径发生链路故障，则流量传输路径变成了s1às2às3às5,也可看到客户端h1一直在发送数据，服务端h2也一直在接收数据。

1.北向接口

2.北向接口的分类

2.1 功能性北向接口

2.2 基于意图的业务模型描述

3.北向接口的实现

4. REST API

4.1 REST的几个重要概念

4.2 REST的约束条件与原则

4.3 REST API的设计规范

4.3.1 资源的原型

4.4 RESTful设计中URI命名的规范

4.4.1 资源命名规范

4.4.2 URI命名规范

4.4.3 URI的格式规范

4.5 URI的过滤

4.6 HTTP状态响应码

4.7HTTP元数据

4.8 Floodlight北向API

1.北向接口

北向接口是SDN应用平面与控制平面之间的接口，通过控制器向上层业务应用开放的接口，为上层业务应用和资源管理系统提供灵活的网络资源抽象。

2.北向接口的分类

功能型北向接口：自下而上看网络，重点在网络资源抽象及控制能力的开放，包括拓扑、L2VPN、L3VPN、Tunnel等

基于意图的北向接口：自上而下看网络，关注应用或者服务的需求，同网络的具体技术无关。

2.1 功能性北向接口

功能型北向接口对应了功能型网络模型和网管模型，关注的是我能做什么，面向具体的网络功能，接口与网络技术方案相关。基于意图的北向接口对应了网络业务模型，关注的是我要什么，主要用于描述SDN网络使用者的需求，主要包括连接服务、资源需求、访问控制、流处理和策略逻辑等内容。

2.2 基于意图的业务模型描述

意图是用户在某一个上下文环境中，基于意图的表达，意图可以由对象和操作或对象和结果组成。其中，对象主要包括面向用户的节点、连接和流信息；操作用于描述用户期望的行为，可以用某个条件下做某个动作，同时遵守某种约束的模式来表达，比如在满足带宽、时延等网络条件下，在匹配哪些节点不可互通等限制下，执行标记优先级，实现转发的操作；结果描述的是用户希望达到的状态，包括期待结果和避免结果两类，可以用期望达到某一状态或避免达到某一状态的子句来进行表述，比如预期保证带宽利用率大于80%，或者避免端到端时延大于100ms等。

3.北向接口的实现

REST API：SDN北向接口的主流实现方式。实现REST API的控制器有RYU、Floodlight、Opendaylight。

其他方案有：RPC、JAVA API、CORBA、SOAP等。

4. REST API

REST API是主流的北向接口实现方式。

REST，表述化状态转移，指的是一组架构约束条件和原则，而满足REST设计规范或者架构风格就称之为RESTful，遵循RESTful设计的API就是REST API。

4.1 REST的几个重要概念

• 资源

资源是信息（包含所有数据或功能）的抽象，在WEB中的实例是一个超文本引用指向的目标。比如在普通的博客应用中，资源可能是包括了用户、博文或评论等；而在SDN中，这里的资源可能是链路、交换机、流表等。

• 资源标识符

资源标识符标识组件之间交互涉及的特定资源，在WEB中的实例是URI（URL包括URL和URN两种形式）。URI为统一资源标示符，URL是统一资源定位符，URL是URI的一个子集，或者说是一种具体的实现。对于一个REST API来说，一个资源一般对应一个唯一的URI，简单来说即使，REST通过URI来暴露资源。

• 表述

表述是用一个表述来捕获一个资源当前或预期的状态，在WEB中的实例为HTML文档、JPEG图片等。

• 元数据

元数据是描述数据的数据，分为表述元数据和资源元数据，在WEB中的实例为媒体类型、最后修改时间、源连接等。

4.2 REST的约束条件与原则

• 客户-服务器：实现解耦，通过客户端用户接口和服务器数据存储的分离，提高了客户端的便捷性，也提高了服务端的可伸缩性。由于实现了解耦，就能够允许客户端和服务端分组优化，彼此之间不受影响。
• 无状态：要求来自客户端的每一个请求必须包含服务器处理该请求所需要的所有信息。由于每个请求都被单独考虑，因此提高了可见性和可靠性。同时由于服务端是无状态的，能够很方便的实现水平扩展，提高了可扩展性。

无状态可以直接定义到服务器的资源，不依赖于服务器的会话状态

• 缓存：要求一个请求的响应中的数据标记为是否可缓存。如果可以，服务端可以重用相同请求的响应数据，这样做的好处是减少了服务端和客户端之间的交互次数，提高了效率
• 统一接口：强调组件之间要有一个统一的接口。也就是说，客户和服务器之间通信的方法必须是统一化的，例如使用标准的HTTP动作GET、POST、PUT、DELETE等
• 分层系统：分层用于限制组件的行为，将架构分为若干等级的层，运训服务器和客户端之间的中间层，例如反向代理、API网关等，代替服务器对客户端的请求进行回应。而对于客户端来说都是透明的。它只关心收到的HTTP响应，而不关心与它通信的组件是谁，提高了系统的可扩展性，也增加了系统的复杂性

• 按需代码

4.3 REST API的设计规范

REST API是基于HTTP协议进行设计的，一个REST API请求可以表示为HTTP动词+URI的形式。HTTP动词描述操作，URI标识资源在REST API中，比较常用的HTTP动词有以下6个HEAD、GET、POST、PATCH、PUT、DELETE。HEAD用于获取某个资源的头部信息；GET用于获取资源；POST用于创建资源；PATCH用于更新资源的部分属性；PUT用于更新资源；DELETE用于删除资源。

4.3.1 资源的原型

资源的原型主要有以下几种

• 文档：文档是资源的单一表现形式，可以理解为一个对象或者数据库中的一条记录
• 集合：集合可以理解为资源的一个容器，可以向集合里面添加资源（文档），
• 仓库：仓库是客户端管理的一个资源库，客户端可以向仓库中新增资源或者删除资源，或者从仓库中获取资源
• 控制器：孔子其资源模型可以执行一个方法，支持参数输入，结果返回。

4.4 RESTful设计中URI命名的规范

4.4.1 资源命名规范

文档类型的资源用名词单数命名；集合类型和仓库类型的资源用名词复数命名；控制器类型的资源用包含动词的词语命名。

4.4.2 URI命名规范

在URI设计中，字段可以是变量，在实际使用中可以按需替换。

4.4.3 URI的格式规范

• URI中分隔符“/”一般用来对应资源层级的划分，“/”不应该出现在URI的末尾。
• URI中尽量使用连字符“-”代替下划线“_”的使用。连字符一般用来分割URI中出现的字符串，来提高URI的可读性。
• URI中统一使用小写字母。
• URI中不要包含文件（或脚本）的扩展名，例如不要出现.php或者.json之类的后缀名。
• 增删改查的操作不要体现在URI中。

4.5 URI的过滤

URI使用query字段作为查询的参数补充，以标识一个唯一的资源。query可以作为过滤条件使用；也可以作为资源列表分页标示使用。

4.6 HTTP状态响应码

Restful设计中，还需要正确使用HTTP的响应状态码

2**：2开头的标识操作成功

3**：3开头的标识重定向，资源位置发生了变化

4**：4开头的标识客户端错误

5**：5开头的标识服务器错误

4.7HTTP元数据

RESTful设计中，还包括了元数据的设计，可以在HTTP头部设置元数据字段。

HTTP头部

• Content-Type表示body的数据格式，如Content-Type：application/json，表示主类型为application，数据格式是json。
• Content-Length：表示body数据体的大小。
• Last-Modified表示资源最后被修改的时间戳。
• ETag：表示服务器端资源版本的标示。
• Location：在响应header中使用
• Cache-Control，Expries，Date：通过缓存机制提升接口响应性能

4.8 Floodlight北向API

Floodlight北向API对外提供了四个模块，分别为OF流表、防火墙、ACL、多租户网络虚拟化。

ACL模块的API包括查询所有ACL规则、添加ACL规则、删除一条ACL、删除所有ACL。当设计使用POST动词创建ACL或使用DELETE动词删除某条ACL时，还需要在json中带上需要传输的数据。

北向接口概述

分类：功能型、基于意图

北向接口的实现

REST API

相关概念

Roy Thomas Fielding博士

遵循RESTful设计的API就是REST API

规范、简洁

资源

REST是面向资源的设计

资源标识符

URI 统一资源标示符

URL 统一资源定位符，URL是URI的子集

表述

用一个表述来捕获一个资源当前或预期的状态

元数据

描述数据的数据，分为表述元数据和资源元数据

REST约束条件

REST API设计规范

HTTP动作（六个）

• HEAD
• GET
• POST
• PATCH
• PUT
• DELETE

资源的类型

响应状态码

Floodlight北向API实现功能

ACL模块示例：

curl为例的命令