• 产品与解决方案
  • 行业解决方案
  • 服务
  • 支持
  • 合作伙伴
  • 新华三人才研学中心
  • 关于我们

H3C ADWAN解决方案技术白皮书

【发布时间:2017-06-11】

1 前言·· 1

1.1 传统广域网的问题·· 1

1.2 云计算对广域网的需求·· 2

1.3 运营商转型对广域网的需求·· 2

1.4 广域网变革已成为必然·· 3

1.5 采用SDN思想构建新一代广域网·· 4

1.6 H3C新一代广域网 — ADWAN方案·· 5

2 ADWAN解决方案介绍·· 5

2.1 方案架构·· 5

2.2 方案特点·· 6

2.3 应用场景·· 6

2.3.1 运营商的应用场景·· 6

2.3.2 企业/行业的应用场景·· 6

2.3.3 互联网的应用场景·· 7

3 构建ADWAN方案的关键技术·· 7

3.1 SDN — ADWAN的核心思想·· 8

3.2 ODL — ADWAN的支撑平台·· 8

3.2.1 ODL介绍·· 8

3.2.2 ODL控制器架构·· 8

3.2.3 ODL架构很好的支撑ADWAN APP开发·· 9

3.3 Segment Routing — ADWAN的控制平面协议·· 9

3.3.1 Segment Routing的基本概念·· 10

3.3.2 Segment Routing的控制平面·· 11

3.3.3 Segment Routing的转发平面·· 11

3.3.4 Segment Routing的优势·· 12

3.4 BGP-LS — ADWAN的可视化基础·· 12

3.4.1 BGP-LS协议介绍·· 12

3.4.2 BGP-LS在ADWAN方案中的应用·· 13

3.5 PCEP — ADWAN的路径控制通道·· 13

3.5.1 PCEP协议介绍·· 13

3.5.2 PCEP在ADWAN方案中的应用·· 14

3.5.3 PCEP的发展·· 15

3.6 RESTful API — ADWAN的北向接口协议·· 15

3.6.1 REST & RESTFUL介绍·· 15

3.6.2 RESTful已成为目前主流的应用接口·· 16

3.7 NETCONF — ADWAN的南向接口协议·· 16

3.7.1 NETCONF协议介绍·· 16

3.7.2 NETCONF在ADWAN方案中的应用·· 17


1 前言

1.1 传统广域网的问题

长期以来,广域网主要负责各网络节点的互联互通,比如总部和分支之间,分支和分支之间,数据中心之间等,和业务应用属于两个独立的系统,基本上没有联系,更多的是作为业务系统的传输通道,实现业务流量的被动“承载”,但随着云计算、移动互联网等应用模式的发展和流量模型的改变,很多时候需要网络能主动“适应”业务流量,做到应用随需而变,但是由于目前的网络在管理上主要是面向设备而非业务的管理,视角上更多的是基于节点而非全局的视角,因此,产生了很多无法解决的问题:

Ø 业务部署慢,上线周期长:

l 广域网设备分散,业务开通时需要逐台部署,手工配置,部署工作量很大;

l 广域网业务众多,配置复杂,手工配置容易出错,开通周期长;

Ø 流量调度难,缺乏灵活性:

l 由于缺乏整网视角,设备各自基于路由进行选路,选出来的是最短路径而非最优路径,带宽利用率低。

l 传统的策略路由和流量工程,局限性大,配置复杂,无法动态适应网络状态和应用需求的变化。

Ø IT维护人员的运维体验很差:

l 网络管理手段有限,手工为主,对IT维护人员的技能要求较高。

l 流量和业务无可视化呈现,造成故障无法快速识别和定位,运维难度大。

Ø 网络开放能力弱,无法适应业务对网络的要求:

l 设备复杂,网络封闭,可编程能力弱,无法满足业务快速部署和灵活定制需求。

l 网络和应用静态绑定,无法有效联动,难以提高云计算应用体验。

图1 传统广域网问题

1.2 云计算对广域网的需求

随着云计算的快速发展和大规模部署,企业IT已经从传统的数据中心向云计算数据中心转型,在这个过程中,用户对应用的体验需求是不会变的,用户希望访问云应用,能像访问本地应用一样快,一样安全,但流量模型发生了根本改变,对广域网的需求也发生了很大改变,主要体现在以下几点:

Ø 本地应用迁移到云端后,原来这些应用在本地运行,独享局域网带宽,现在变为云端运行,共享广域网带宽来进行数据交互,对广域网的带宽、承载能力、可扩展性、可靠性等都提出了更高的要求。

Ø 各地的本地应用都要通过广域网和云端进行通信,这个时候广域网的业务种类变得很多、流量也变得更加复杂,为了保证应用体验不受影响,需要面向不同用户实现差异化、精细化调度,保障各类用户的服务质量。

Ø 云计算数据中心的规模部署,数据中心之间的互联互通和数据同步越来越多,需要专门的DCI网络来承载和保障这些流量,同时要求DCI网络具备实时感知、统一编排、灵活调度,动态适应云计算应用的能力。

传统广域网架构复杂、扩展困难、封闭僵化,难以适应云计算的需求,需要广域网进行重构和变革。

图2 云计算对广域网的需求

1.3 运营商转型对广域网的需求

随着近些年数据中心、云计算、移动互联网的快速发展,用户除了基本上网需求外,对业务的丰富性和体验感要求越来越高,但目前运营商主要还是提供网络的互联互通,网络和业务基本上是割裂的,因此产生了很多突出的问题,如:

Ø 增量不增收: 业务流量呈现爆炸式的增长,但运营商发现收入并没有随着流量的增长而增长,反而和流量的剪刀差越来越明显。

Ø 网络成本高: 随着流量的增长需要不断扩容现有的网络,增加带宽,来满足用户的需求;新业务也要求购买和部署新的物理设备,而这些网络设备各自封闭的系统需要专门的人员来熟悉,技能难以复用,造成维护成本很高;专属的设备对机房、电源等的要求也有可能不同,也会导致运营成本的上升。

Ø 业务交付慢: 由于各设备系统封闭,缺乏标准的开放接口和自动化的部署工具,因此,每开通一个新业务,要求各设备之间配合设计、开发和调试,涉及到各个部门、不同厂商的协调,而且硬件设备需要挨个站点安装、升级和调试,整个周期很长。

Ø 竞争压力大:现有的网络结构复杂、设备封闭、缺乏灵活性,在面对虚拟运营商和互联网厂商的竞争时,压力会越来越大。

面对上述的这些问题,进行业务转型已经成为运营商的普遍共识,要进行业务转型,就需要解决以下几个主要问题:

Ø 网络架构的重构和优化,通过引入SDN技术和思想,搭建一个开放的网络平台,能够全局调控网络资源,以业务驱动网络,使网络从功能向服务转型,产生新的增值。

Ø 现网资源的利用和发挥,通过精细化的流量调度,为不同的用户提供差异化的网络服务,充分利用和挖掘现网资源,最大发挥整个网络的价值。

Ø 运维管理的简化和自动化,通过开放接口,开发一些丰富的运维应用,实现网络自动化、可视化,来简化运维。

总的来看,运营商现有网络难以适应业务转型的要求,除已经和正在进行SDN改造的数据中心网络外,也需要对城域、骨干等网络进行重构和变革。

图3 运营商转型对广域网的需求

1.4 广域网变革已成为必然

为了应对传统广域网、云计算以及运营商转型中遇到的各种问题和挑战,广域网急需重构和变革,形成新一代的广域网,如下图所示,我们认为变革后的新一代广域网需要具备以下能力:

1. 灵活的编程定制能力:可以基于用户业务进行灵活的定制编程;

2. 全局的控制调度能力:管理系统具有整网视角,可以基于整网的流量进行调度和调整;

3. 开放的网络构建能力:打破传统网络设备封闭的管理控制方式,快速的部署构建整个网络;

4. 简化的运维部署能力:支持开放的接口,通过开放接口,开发一些丰富的运维应用,简化系统的运维和部署;

5. 可视的状态呈现能力:实时监控资源变化,做到整个网络可视化,方便用户运维管理。

图4 新一代广域网示意图

1.5 采用SDN思想构建新一代广域网

随着SDN的发展,已经由最初的以Openflow为代表的狭义SDN演变为以软件定义网络为核心广义SDN,现在SDN更多代表构建网络的一种架构、一种思想,其本质和目标主要包含以下几点:

Ø 软件定义网络:就是用软件定义的思想来设计新的网络架构,让网络能够主动适应用户业务和流量变化,而不是被动的承载流量

Ø 应用驱动网络:以应用为源头,用自动化的方式驱动网络进行动态调整,快速满足实际的业务需求;

Ø 软件简化运维:通过软件应用参与网络的整个生命周期,实现自动化的业务部署、可视的网络呈现、灵活的流量调度,最终简化网络的管理运维。

为了达到SDN思想所定义的目标,需要通过一些技术手段来实现,现在普遍采用的手段包括转控分离、控制集中化、以及开放接口等,这些手段不仅仅适用于构建数据中心网络,也同样能够实现新一代的广域网,例如:

1. 转控分离:

l 重构网络架构,简化设备和部署,降低CAPEX(资本性支出)和OPEX(运营成本)。

l 增加网络扩展性,提高网络性能和可靠性。

2. 控制集中化:

l 整合网络资源,加快业务部署,促进网络从功能向服务转型,产生增值。

l 全局控制和调度,优化流量分布,保障业务质量,提高网络利用率。

3. 开放接口:

l 差异化定制网络,促进IT和CT融合,快速适应业务需求,带来新的增值。

l 开发丰富的APP,实现网络自动化、可视化,简化运维。

1.6 H3C新一代广域网 — ADWAN方案

H3C凭借长期在广域网领域的技术积累和丰富经验,深入调研用户实际应用中存在的痛点和需求,采用SDN思想及其相关技术开发了新一代广域网整体解决方案,这个方案帮助用户构建了一个架构开放、灵活编程、易于运维的广域网,来承载日益丰富的应用流量,最终实现应用按需驱动网络、网络动态适应应用,我们把这样一个新一代的广域网称为应用驱动的广域网,即ADWAN(Application-driven Wide Area Network)。

2 ADWAN解决方案介绍

2.1 方案架构

图5 ADWAN方案架构

如上图所示,ADWAN方案和其他场景下的SDN网络架构一样,也是一个分层、开放、灵活的网络架构,如下图所示,整个ADWAN方案分为网络设备、控制器+APP、管理编排三个层次:

Ø 网络设备层:网络设备接收SDN控制器的控制和管理,除了传统的SNMP、NETCONF、命令行等方式外,支持SDN架构下的BGP-LS、BGP Flowspec、PCEP、Openflow等协议,和控制器进行通信;同时在转发层面进行优化,支持Segment Routing、Openflow硬件转发,提供高性能的转发平面。

Ø 控制器+APP层:整个方案基于开源的ODL平台,支撑各种APP集成;根据广域网不同的场景,比如DCI网络、骨干网、分支接入等,开发定制化、场景化的APP,满足用户在不同场景下的网络需求;南向通过标准南向接口协议和设备互通;北向面向用户提供定制化的API接口,实现和编排系统集成,满足用户差异化的业务需求。

Ø 管理编排层:通过调用APP提供的API接口,实现业务流组定义(Qos优先级、五元组、VPN等)和业务的策略定义和管理编排,全网的实时监控、可视化呈现、及故障排查等,进而增强网络的可视化,简化网络的运维管理。

2.2 方案特点

华三ADWAN方案,基于全局视角,通过统一整合全网资源、多维观测网络状态、智能分析运行数据,使整个网络实现多层次、全方位的可视化,并根据用户策略和应用需求进行集中控制、全局调度、及实时调优,实现应用驱动的广域网服务,它具有以下特点:

Ø 全开放:首先是架构开放,网络的各个层次、不同组件是解耦的,做到网络可以很容易的扩展,也能很好的兼容多个厂商的设备;其次是接口开放,网络各组件之间通过开放、标准的接口来通信,从设备到控制器到控制器、APP提供多层次的、不同抽象度的API接口,赋予网络灵活的可编程可定义能力,能够让应用很容易的使用网络服务。

Ø 场景化:基于场景化的开发思路,提供面向业务的可定制APP应用,满足不同场景用户需求。

Ø 全流程:全流程重构广域网,整网视角管理和控制网络,简化运维管理。

Ø 端到端:业务驱动网络,基于业务应用的不同需求动态部署安全、WAN优化、CDN缓存等,提供端到端的网络服务。

Ø 可迁移:兼容传统网络,支持平滑迁移到SDN方案。

2.3 应用场景

ADWAN方案基于场景化的思路,有针对性的开发了不同的APP应用,来满足运营商、企业/行业、及互联网等不同类型用户的需求。

2.3.1 运营商的应用场景

ADWAN方案在运营商主要有以下几个典型应用场景:

运营商骨干网

城域网专线

IP RAN

场景描述

Full-Mesh网络,拓扑结构复杂

通过VPN、优先级等实现业务区分和隔离

覆盖接入和汇聚网络,设备以交换机为主

用户以QinQ来区分和隔离,需要二层专线打通用户和数据中心网络

分基站接入、城域汇聚/核心层,接入采用二层增强以太网或与三层IP/MPLS相结合的技术,一般为交换机或路由器;汇聚/核心采用IP/MPLS技术,通常为路由器设备。

关键需求

优化网流量分布,挖掘带宽资源

提高业务部署和调整能力,增加收入

增强网络可视化,简化运维

简化网络结构,增强扩展性和灵活性

自动化部署和运维,为专线用户提供差异化服务质量

业务部署自动化,简化运维管理

流量灵活调度,保障业务SLA

2.3.2 企业/行业的应用场景

ADWAN方案在企业和行业主要有以下几个典型应用场景:

行业骨干网

行业纵向网

分支接入网

场景描述

Full-Mesh网络,多划分不同平面,平面之间互为备份

有纵向流量和横向流量,通过VPN、优先级等实现业务区分和隔离

树形多级纵向网络,节点为双设备双链路冗余,可能和上级网络跨域对接

以纵向流量为主,通过VPN实现业务区分和隔离

Hub-Spoke两级网络,多链路接入,分支数量多、位置分散

以纵向流量为主,通过ACL、DPI等实现业务区分和识别

关键需求

优化骨干网流量分布,提高链路利用率

提高网络可靠性,保障关键业务服务质量

简化网络运维管理,降低IT成本

基于灵活策略的业务流量选路控制

提高网络可靠性,保障关键业务服务质量

提供开放接口,促进CT和IT融合

部署自动化,网络可视化,简化运维管理

DPI识别,灵活选路,提高带宽利用率

用户接入认证,上网行为管理和审计

2.3.3 互联网的应用场景

ADWAN方案在互联网主要有以下几个典型应用场景:

DCI网络

DC出口网络

DC城域网

场景描述

DCI节点部署在区域边界,是由多台设备形成的集群,设备类型可以是路由器或交换机。

DCI节点之间通过专线互联,MPLS或IP网络,主要承载各地域之间的流量。

DCI节点和本区域内的IDC之间通过MAN互联。

部署在IDC出口,是由多台设备形成的集群,设备类型一般是路由器。

有外网和内网出口,外网出口连接不同的ISP,承载DC公网流量;内网出口连接DCI网络,承载本DC需要绕行异地DC公网出口的公网流量。

部署在区域内部,由多个MAN节点组成,每个节点由多台设备集群,设备类型一般是交换机。

MAN节点之间通过专线互联,承载本区域内IDC之间的流量。

MAN节点通过专线连到DCI节点上,承载IDC到异地的流量。

关键需求

全网路径优化和流量调度,均衡流量分布,提高专线利用率,降低线路成本。

按DSCP区分用户和业务,提供差异化的SLA。

收集并管理全网出口路由器的的路由。

基于链路质量、实时流量等进行选路(本地ISP或通过DCI异地绕行),转化为BGP路由,下发给设备,指导流量转发。

全网路径优化和流量调度,均衡分担节点流量,提高专线利用率,降低线路成本。

节点流量优先直连链路,次选绕行链路。

3 构建ADWAN方案的关键技术

ADWAN方案的目标是实现应用驱动的广域网服务,但如何做到这一点,会有很多技术和手段,可以说条条大路通罗马,具体选择哪条路,就要结合当前的技术成熟度和应用实践来确定了,下面我们详细介绍一下构建ADWAN方案的关键技术,其中既有核心的指导思想,也有关键的运行平台,还有重要的南北向接口协议,实际上,这些都是为整个ADWAN服务的,最终目标是为了使ADWAN更加开放、灵活、易用、可靠,同时又能够兼容传统网络,使用户的网络能够平滑迁移到SDN架构上,来快速满足用户不断变化的应用需求。

3.1 SDN — ADWAN的核心思想

我们都已经看到,SDN(软件定义网络)作为目前最热门的思想和技术,已经在数据中心、园区网等领域得到广泛应用和规模部署,使网络具备灵活编程、动态感知、及自动编排等能力,从而快速满足不断变化的应用需求。广域网虽然和数据中心等网络有很多不同,但在满足用户应用需求上是一样的,因此,将SDN引入到广域网领域中已经成为业界的普遍共识,那么以SDN为指导思想来构建我们的ADWAN方案也成了一个必然选择。

3.2 ODL — ADWAN的支撑平台

3.2.1 ODL介绍

ODL(OpenDaylight)是Linux基金会旗下的一个开源控制器合作项目,致力于制定一个共同、开放的SDN平台为开发者使用,促进和建立商业产品和技术的发展,加速SDN产业的创新。目前已经有包括AT&T、NEC、Intel、Cisco、HP、H3C、华为等有众多设备商和运营商都积极参入其中,每个成员可使用ODL提供插件和其产品、服务的增强,为用户带来附加价值。

ODL项目于2013年2月启动,2014年2月发布第一个正式版本,每隔8个月发布一个正式版本,截止目前为止已发布了氢(Hy)、氦(He)、锂(Li)、铍(Be)四个正式版本,能够为服务提供商和企业提供自动化服务交付、网络资源优化、云计算、NFV、以及区域网络的自动化、可见性和可控制相关的解决方案。

ODL作为业界领先的、参与度最广的开源SDN控制器平台,已经在数据中心网络广泛应用,现在已逐步向广域网领域延伸和普及,H3C作为业界领先的新IT网络提供商,率先将ODL引入到广域网解决方案中,作为ADWAN方案的控制器平台,充分利用和发挥开源的优势和力量,以开源开放的APP开发模式,满足用户不同场景下的应用需求。

3.2.2 ODL控制器架构

软件定义网络框架:OpenDaylight

图6 ODL控制器架构

如上图所示,ODL控制器基本组件如下:

服务抽象层(SAL):控制器的内核,对外提供SAL-API,ODL主要采用MD-SAL (Model Driven SAL,模型驱动的服务抽象层)。

抽象层接口(SAL-API):SAL对外提供的接口;

插件(Plugin):在SAL上进行开发,实现某些功能,运行在SAL外,控制器内部,根据其数据传递方向可分为北向插件,南向插件,以及内部插件;

SAL服务(SAL-Service):常驻于ODL上的服务,相当于特殊的插件,提供基础服务,插件和应用调用它们;

北向接口(NB API):ODL为上层应用提供的API,一部分可以直接访问SAL,另一部分是插件提供的,通过YANG生成;

应用(Application) :实现某些完整功能,运行在控制器之上,应用可能会调用插件,也可能直接调用抽象层服务;

组件(Component):组件是ODL开发的模块,它可能是插件,可能是应用,也可能是二者的组合。

3.2.3 ODL架构很好的支撑ADWAN APP开发

ODL采用层次化、模块化、可插拔的控制器架构,可以部署在任何支持Java的平台之上,很好的支撑了ADWAN APP应用的开发:

采用OSGi体系结构,可对功能进行隔离,可以实现APP的动态加载和卸载,解决了可扩展、热部署等问题,实现了一个优雅、完整和动态的组件模型,APP无需重新引导可以动态地被远程安装、启动、升级和卸载,给使用者提供了方便。

整个架构中引入了SAL服务抽象层,使得北向RESTful API和南向接口之间的调用相互隔离,APP应用开发者可以不用关注设备细节,直接调用RESTful API接口就可以使用网络服务;支持各种南向接口协议,包括NETCONF、OpenFlow等,既可以和SDN设备进行通信,又可以很好的兼容传统网络设备。

基于模型驱动(MD-SAL)的开发模式,使用YANG工具建模,直接生成业务“骨架”,使开发者真正专注于具体业务。

3.3 Segment Routing — ADWAN的控制平面协议

MPLS(Multiprotocol Label Switching,多协议标签交换)是目前应用比较广泛的一种骨干网技术,它在无连接的IP网络上引入面向连接的标签交换概念,将第三层路由技术和第二层交换技术相结合,充分发挥了IP路由的灵活性和二层交换的简洁性,因此,很多运营商和企业都采用了MPLS技术来建设自己的网络,来实现跨地域、安全、可靠、可管理的网络服务。

但是,MPLS网络的部署和管理都非常复杂,对运维人员要求很高,限制了它的应用范围,另外,MPLS是基于目的的转发,不能很好地满足源端的需求,不能动态实现源上特定应用对于带宽和延迟的需求,无法基于业务对流量进行精细化调优。因此,出现了一种新的协议Segment Routing,它是对现有MPLS技术的高效简化,同时复用MPLS已有的转发机制,能很好的兼容目前的MPLS网络,并帮助现有MPLS网络向SDN的平滑演进。

3.3.1 Segment Routing的基本概念

Segment Routing由IETF SPRING工作组负责制定的标准协议,同时有多个工作组(如:OSPF、ISIS、PCEP等)也在定义对Segment Routing的扩展。

Segment Routing是一种Source Routing协议,由源节点来选择路径,并将路径转换成一个有序的segment列表封装到报文头中,设备只需要根据报文头中的路径信息进行转发。Segment表示任意类型指导报文转发的指令,例如Service–Context、Locator、IGP-based forwarding construct、BGP-based forwarding construct、Local value or Global Index,在MPLS网络中,Segment其实就是标签,路径就是用一个有序的标签列表来标识,即标签栈。

在Segment Routing协议中,定义了Prefix/Node Segment和Adjacency Segment两类标签:

Prefix/Node Segment:设备本身分配的标签,全网唯一。设备节点都有自己能够支持的标签范围,预留一段标签段作为SR Global Block (SRGB),通过IGP扩展或控制器通告标签时,通告SRGB和段内index,全网为设备节点分配一个全局Index,每设备上的标签为SRGB+Index。

图7 Prefix/Node Segment示意图

Adjacency Segment:为设备链路分配的标签,本节点有效。不使用SRGB 标签,设备节点支持的本地标签范围,通过IGP扩展或控制器通告标签时,通告标签值,一个标签值代表一个设备节点上的一条链路(实质就是为每一跳分标签)。

图8 Adjacency Segment示意图

3.3.2 Segment Routing的控制平面

我们前面说过,Segment Routing是对现有MPLS的简化和优化,尤其是控制平面,只需要支持IGP协议,不再需要部署LDP或RSVP-TE协议,具体表现在以下几个方面:

标签的分配和分发:传统的MPLS网络需要LDP等协议同步和分发各个节点的标签信息,Segment Routing不在需要LDP协议,只需要通过IGP协议(ISIS或OSPF)的SR扩展来同步,或者由控制器统一进行分配和下发,大大简化了设备运行的协议数量。

标签转发表的建立:同样的传统MPLS需要通过LDP协议分发标签后形成标签转发表,而且标签转发表的规模会非常大,而Segment Routing只需要IGP协议就可以完成标签转发表的建立,并且非常容易扩展,规模也很小,条目数为N(节点标签数量,一般为全网节点数量)+A(邻接标签数据,一般为设备接口数量)。

路径的标识和建立:在MPLS网络中,一个报文经过的路径为LSP(Label Switched Path,标签交换路径),通过手工指定或使用LDP、RSVP-TE协议动态建立。在Segment Routing协议中,路径是由一个有序的segment列表(标签栈)来表示,且被封装在报文头中进行转发,因此,Segment Routing路径不再依赖于逐跳的信令协议(LDP或RSVP-TE)来建立,而是直接由报文源节点或者控制器指定一个标签栈即可,中间的转发设备只需按标签栈的信息进行转发,非常简单。

3.3.3 Segment Routing的转发平面

如下图所示,由6台路由器组成的一个网络,通过IGP-SR扩展协议或控制器给设备分配Node标签(蓝色标识)和Adjacency标签(橙色标识),设备基于分配的标签形成标签转发表。

图9 Segment Routing标签转发表示意图

假设一个报文要从R1到R4,控制器计算完路径后是R1->R3->R5->R4(组合路径),即R1到R3可以按照最短路径进行转发,R3到R4必须经过R5,那么控制器对R1到R3使用Node标签,R3到R4使用Adjacency标签,将路径转化为SR标签栈就是{3, 305, 504},并下发到路径头节点设备R1,R1将标签栈封装到报文头中,路径上的转发设备R1、R2、R3,R4、R5根据标签转发表进行转发即可,详细过程如下图所示:

图10 Segment Routing报文转发表示意图

3.3.4 Segment Routing的优势

Segment Routing是对现有MPLS技术的高效简化,同时又充分发挥了MPLS的转发机制,因此,它的很多优势为新一代广域网提供了更好的基础支撑。

融合了设备自主转发和集中编程控制的优势:

ü 简化设备控制平面,减少路由协议数量,简化运维管理,降低运营成本

ü 标签转发表简单,容易扩展,规模也很小,一台设备上维护的转发表数为N(节点标签数量,一般为全网节点数量)+A(邻接标签数据,一般为设备接口数量),而传统MPLS网络则为N^2。

ü 支持集中控制,实现应用驱动的网络

ü 兼容现有设备,保障网络平滑演进

ü 零丢包路径切换

支持广泛的部署场景:

ü 骨干网、DCI

ü MPLS、IPv6网络

ü 传统网络、SDN网络

面向SDN的架构设计

3.4 BGP-LS — ADWAN的可视化基础

3.4.1 BGP-LS协议介绍

传统广域网很大的问题就是网络不够透明,可视化不够,导致管理人员很难管理整个网络,出现问题难以定位,运维压力很大。ADWAN方案的目标之一就是增强整个网络的可视化,管理人员可以很方便的看到整个网络的拓扑结构、链路状态、链路质量、及流量路径等,这其中用到的最基础的就是拓扑收集协议BGP-LS,BGP-LS已成为控制器的主流南向接口协议之一,它是在BGP协议的基础上进行扩展(如下图所示),用来发布网络中设备节点信息、链路属性(如:带宽、开销等)、链路状态、及拓扑信息等。

图11 BGP-LS的属性扩展

3.4.2 BGP-LS在ADWAN方案中的应用

如下图所示,BGP-LS以Domain域为单位,将Domain域内由支持TE扩展的IGP(OSPF-TE或ISIS-TE)协议收集的信息收集上来,发送给ADWAN控制器,由ADWAN控制器经过分析、整合后供流量调度、网络可视化等APP应用使用。

图12 BGP-LS在ADWAN方案中的应用

3.5 PCEP — ADWAN的路径控制通道

3.5.1 PCEP协议介绍

PCEP(Path Computation Element Communication Protocol)是一个用于传递路径信息的标准协议,最基本的协议有两个:

RFC4655 defined PCE Architecture (2006) — 定义了PCE的体系架构和基本组件

ü PCE(Path Computation Element):一个基于TEDB(TE topology database)计算带约束路径的软件模块,也可静态手工指定。PCE可以是网络中的一台路由器设备,也可以是网络外的一台服务器。

ü PCC(Path Computation Client):一个软件模块,向PCE发送路径计算请求,并从PCE接收路径计算应答。PCC通常位于网络中的路由器设备上。

RFC5440 defined PCEP (2009) — 定义了组件间的通信协议,即PCEP

ü PCEP(Path Computation Element Communication Protocol):通过PCEP协议实现PCC-PCE、PCE-PCE之间的通信,来传递计算请求和计算结果。

ü 在路径计算时,可以由PCC发起路径申请(被动模式),也可以由PCE主动下发路径(主动模式)。

3.5.2 PCEP在ADWAN方案中的应用

在ADWAN方案中,SDN控制器通常作为PCE,网络设备作为PCC,因此,PCEP已成为控制器主要的南向接口协议之一,用来传递路径等信息。

图13 PCEP在ADWAN方案中的应用

在协议定义中,PCE分为无状态的(Stateless PCE)和有状态的(Stateful PCE)两种:

Stateless PCE

ü PCE是没有记忆的,不会记录已经计算过的路径信息,包括路径状态、消耗的资源等。

ü PCE在计算新路径时,不会考虑网络拓扑、带宽资源、已存在路径等信息,只会针对当前路径需求来计算。

Stateful PCE

ü 网络拓扑、带宽资源、路径状态等信息会同步到PCE上,PCE会看到全网信息。

ü PCE在计算新路径时,除了路径本身的需求,还会将网络拓扑、带宽资源、已存在路径等信息作为输入参数一起进行计算。

图14 Stateless PCE和Stateful PCE的功能比较

从上述描述,我们可以看到无状态的PCE只能实现基本的路径计算,实际应用效果有限,因此,在ADWAN方案中,我们采用的是有状态的PCE,以支持更完善的路径计算功能。

3.5.3 PCEP的发展

在PCEP最初的定义中,主要是传递LSP路径信息,随着Segment Routing协议的发展,PCEP,也进行了相应的扩展,这样,控制器计算完路径后,转换成具体Segment Routing标签栈,就可以通过PCEP协议下发给设备,指导设备按标签栈指定的路径进行转发。

3.6 RESTful API — ADWAN的北向接口协议

3.6.1 REST & RESTFUL介绍

REST(Representational State Transfer)描述了一个架构样式的网络系统(如 Web 应用程序),它首次出现在 2000 年 Roy Fielding (HTTP 规范的主要作者之一)的博士论文中 。

REST是一种软件架构的设计风格而不是标准,它定义了一组约束条件和原则,满足这些约束条件和原则的应用程序或设计就是RESTful。

图15 RESTful的约束条件和原则

3.6.2 RESTful已成为目前主流的应用接口

REST约束条件作为一个整体应用时,将生成一个简单、可扩展、有效、安全、可靠的架构,简便、轻量级以及通过HTTP直接传输数据的特性,简化了客户端和服务器的实现。

在目前主流的三种Web服务交互方案中,REST相比于SOAP(Simple Object Access protocol,简单对象访问协议)以及XML-RPC更加简单明了,无论是对URL的处理还是对Payload的编码,REST都倾向于用更加简单轻量的方法设计和实现。

在REST定义中,服务器使用固定唯一的URI来标识一个资源(如:应用程序对象、数据库记录、算法、文档等),并向客户端公开。这样,对以资源为中心的Web应用来说,就可以用一致的接口(URI)将资源对外开放,并提供对资源的操作服务。

在REST架构中,通过不同的 HTTP 请求方法(比如 GET、PUT、POST 和 DELETE),实现用同一个URI对一个资源进行CRUD(创建、读取、更新和删除)操作。而要获取同一个资源的不同表现形式的数据(如:一张照片,或者照片的属性),只需要使用不同的 HTTP 请求头信息(如:Accept参数)就行了,这种通过请求头传递不同的状态,获得不同的数据,叫做“具象状态传输”。

3.7 NETCONF — ADWAN的南向接口协议

3.7.1 NETCONF协议介绍

随着网络规模的增大、复杂性的增加和异构性的增强,传统的网络管理协议SNMP已经不能适应当前复杂网络管理的发展,特别是不能满足配置管理的需求。在这一背景下,IETF在2003年5月成立了NETCONF工作组,该工作组主要负责制定基于XML的下一代网络配置协议NETCONF,该工作组已于2006年12月通过了NETCONF协议的基本标准RFC4741-4744。

图16 NETCONF协议结构

和大多数协议一样,NETCONF协议也采用了分层结构(如上图所示),包括内容层、操作层、RPC层、应用协议层4个层次,每个层分别对协议的某一个方面进行包装,并向上层提供相关的服务。分层结构能让每个层只关注协议的一个方面,实现起来更加简单,同时合理的解耦各个层之间的依赖,可以将各层内部实现机制的变更对其它层的影响降低到最低。

内容层:表示所配置的数据,与SNMP的MIB不同,NETCONF采用了XML(可扩展标记语言)作为配置数据和协议消息的编码方式,XML 可以表达复杂的、具有内在逻辑关系的、模型化的管理对象,而且由于它是W3C提出的国际标准,因而受到广大软件提供商的支持,易于进行数据交流和开发。

操作层:定义了一系列在RPC中应用的基本操作,主要包括取值操作、配置操作、锁操作和会话操作等,其中get、get- config用来对设备进行取值操作,而edit- config、copy- config、delete- config则是用于配置设备参数,lock和unlock 则是在对设备进行操作时为防止并发产生混乱的锁行为,close- session和kill- session则是相对比较上层的操作,用于结束一个会话操作。

RPC层:提供了一个简单的、传输协议无关的机制,通过使用<rpc> 和<rpc- reply> 元素对NETCONF协议的客户端和服务器端的请求和响应数据(即操作层和内容层的内容) 进行封装,正常情况下<rpc- reply> 元素封装客户端所需的数据或配置成功的提示信息,当客户端请求报文存在错误或服务器端处理不成功时,服务器端在<rpc- reply> 元素中会封装一个包含详细错误信息的<rpc- error> 元素来反馈给客户端。

应用协议层: NETCONF采用了可靠的、安全的、面向连接的传输协议,在传输层,NETCONF制定了RFC4742、RFC4743 和RFC4744 分别给出了向传输协议SSH、SOAP和BEEP映射的实现方案,这些方案通过加密和认证等方法来保证网络连接的安全性。

3.7.2 NETCONF在ADWAN方案中的应用

NETCONF作为目前应用最广泛的一个南向接口协议,在ADWAN方案中承担了一个非常重要的角色,它可以帮助ADWAN控制器实现对设备的信息收集、业务配置等管理操作,借助于NETCONF协议良好的扩展性,不需要漫长繁琐的标准讨论,可以根据需求灵活定义控制器和设备之间的管理内容,以对设备实现更丰富的控制,快速交付满足用户需求的方案。




 
新华三官网
联系我们