SDN技术分享(十):GoogleFiber的宽带接入速率控制解决方案

本次分(zhuang)享(bi)呢,主要探讨一个新兴SP客户的案例。 G家,这是非传统的SP。我们一起来看一下G家的市场策略以及使用的关键技术.

内容比较多,我尽量讲得详细一些,大概要耽误大家一个多小时左右的时间。

BNG = Broadband Network Gateway,翻译成中文应该是“宽带业务网关”

(有些英文的名词术语呢,我就做一次名词的介绍,后续就并不翻译,以避免翻译带来的混淆)

Google Fiber是对美国传统电信运营商(AT&T, Verizon)发起的一次巨大的挑战

第一个BNG案例是美国本土的,但是这个解决方案仍然适用于其他的地区。Google前几年进入的宽带业务市场,Initiative就叫Google Fiber,对传统运营商的宽带接入网业务造成了一些威胁。Google Fiber在2011年开展宽带接入网业务, 提供非常高速度的宽带接入,这是他相对其他竞争者的优势所在. 这项业务提供1Gbps接入入户,是基于GPON的接入技术。一个有趣的方面就是Google Fiber的市场策略,是基于社区驱动的模式,这种模式决定了G家到底要进入哪个市场。

在一个社区内部,居民们上网注册并提交请求,基于收集的客户的兴趣点以及特定的市场,G家来决定到底是否值得进入本区域的市场和下期进行部署。除了部署非常高速度的宽带接入以外(这其实就已经足够让大多数社区居民很激动了好伐?),G家也推出其他项目,比如把公共研究机构免费接入Google Fiber(学校,研究所,医院,图书馆等等)。所以尽管Google Fiber和TW, ATT, COMCAST, VZ的部署比较起来看似很小,但增长率惊人,但同时也造成了传统电信运营商内部人士的担忧。举例:堪萨斯州的堪萨斯市, 有75%的接受率,并且有40%的家庭倾向于使用最贵的Double Play服务,那就是1Gbps接入速率的以太网和HDTV(高清晰度电视节目)。Google Fiber进入的这些市场是直接与时代华纳电信, AT&T, COMCAST, CENTURYLINK竞争的,关于G家进入宽带市场有很多推测,最后大多数人相信并且很多分析家已经指出来,G家的目的,就是raise the bar(有点不知道怎么翻译,大概是提高标准吧)并且刺激美国运营商们提供更快的宽带业务。

为什么要更快的网速?更快的宽带业务可以提供更多的在线服务,这就意味着用户愿意付更多的费用来享受服务,比如Google的核心业务,在免费服务的同时,针对特定客户群的特定需求投放广告,包括搜索,电子邮件,社交网络以及视频流服务等等。

美国的一家权威机构发布了关于全球范围内高速Internet的的研究 。他们发现,与其他国家相比较,大多数美国人花着更多的钱,用着更慢的宽带服务。所以我们其实能看到G家搞这个业务的初衷,部分原因就是激起行业竞争,为最终用户提供更快的网络,更低的价格。

其中一些例子,ATT在2014年中发布了U-verse GigaPower 1G的光纤业务,初期速率是300Mbps,在2015年已经达到1G的速率。并且COX公司也在2014年初发布了要为用户提供1G接入服务的消息。

接下来我们从部署的角度来看一下Google Fiber的情况。之前说过,是比较小范围的部署,目前是3个大城区,Utah地区,Kansas市和Texas州的Austin. G家发布了消息,将要拓展业务到34个新城市,包括盐湖城。

Again, 这是用户需求驱动模式的,用户只要上网注册,并正式提出需求,当需求足够多时,GOOGLE FIBER就会考虑在本地区部署业务。

我们来看一下Google Fiber的service plan(中文翻译应该叫“套餐”),如果大伙儿对美国SP的每月网费有所了解的话,应该能看得出来,G家提供的套餐和速率相比,是非常有竞争力的。

第一个是免费套餐,下载速率5Mbps,上传速率1Mbps,是免费上网哦~,有一个300块一次性安装费,提供一个网络盒子,没有服务费,没有合同费

第二个是70块月费套餐,包括1Gbps互联网接入(上下行都是1Gbps),不包括电视业务,但是提供1TB的免费Google Drive,还有路由器网关,这需要用户签合同,承诺使用最少一年。

第三个是120块钱的Double Play业务,包括Internet (1Gbps)和高清TV业务,提供2TB的DVR Drive做本地存储,可以支持8路同时录像,免费提供1TB Google Drive 。所有这些硬件并没有每月的租用费,都包括在120块钱月费里。这需要用户签合同,承诺使用最少两年。

(注:PPT上最高价格已经不是最新的,最新价格是最高价格套餐月费130块,其他都相同,以上最新信息来自北卡和堪萨斯地区网站)

Google Fiber部署业务以来有两大vendor,而Juniper是其中一个,另一个不是Cisco而是Alcatel. 上图列举了Google Fiber部署模式的目标以及技术需求。从一个比较宏观的角度来说,就是关于有效和自适应的传送Internet和组播视频业务以及IPTV,架构方面是直连网络架构(稍后会有说明)。Google Fiber要求,在网络拥塞的时候,BNG(业务网关)能够为每家每户和PON的带宽分配提供有效的管理,基本上就是要求下行流量能够被根据需求做限速,以此来提供对每户业务和PON业务的同时保护。并且需要使用组播VPN技术有效地在BNG和核心网之间提供对组播业务的转发。组播业务要求从BNG到OLT接入网的下行流量只在组播频道中只发送一份。

另外,双组播源用来提供冗余,也是一个重要的技术要求,并且必须能通过单一机框和冗余机框部署。

OLT = optical line terminal, 光线路终端,在局方侧使用

PON = passive optical network,无源光纤网络,不需要用电源就可以完成信号处理

这些都是光传输网的术语,如果你一时不大明白,暂时先记住就可以了。

好,接下来我们来进入业务部署的具体技术探讨。

上面这张图代表了Google的网络拓扑以及接入模式。目前选择的BNG设备有两个考虑,一个是MX960,另一个是MX2010。从下面向上看,很明显,家庭用户接入到GPON接入商,彩色三角形代表的是分光器直接插入OLT支持的每一台PON设备。每个PON设备能够支持32户的每户1G接入。每户就是一个VLAN,我们叫Customer VLAN,CVLAN,所以其实这就是1:1 CVLAN的模式。一台PON的聚合带宽是2.5Gbps,OLT使用service VLAN(或者叫S-tag)来标识每一台PON设备。多台PON设备使用聚合以太网技术,合并4个万兆以太网直接接到BNG上,所以这就叫作OLT到BNG的直连部署模式,以后随着流量增加可以增加到2 X 40GE的样子。在顶端,我们看到有个视频头端直接把视频内容通过组播VPN分发到用户(源是冗余的),对用户的下行方向,BNG必须能够支持针对每家每户速率1Gbps的流量整形(Shaping),并同时能够对每个PON设备进行2.5Gbps的shaping,这才能保证不会造成业务的拥塞。

此图提供了一个 Google Fiber网络的概览,我们可以看到有三层网络,从上到下,都有不同的CoS调度层级,在不同的网络层次都有不同的带宽需求,最后我们可以看到VLAN级别的架构部署。我们集中看一下逻辑VLAN的层次,这里是1:1 CVLAN的部署模式,每家每户是一个CVLAN,上网流量和视频流量都被转发到每户。Google使用指定的组播VLAN来有效的分发组播流量。单一一份的组播流量通过特定的组播VLAN从BNG分发到OLT(中间链路是聚合以太网),最终的组播复制点就是OLT设备。

这里显示的是BNG和OLT设备之间使用的聚合以太网,在右侧你可以看到有冗余的视频分发点,使用组播VPN通过核心网来转发到BNG。BNG的一个另外的功能就是IGMP消息的join/leave的处理。OLT设备会发送组播流量给最终用户,实际上是组播流量通过组播VLAN被发送到OLT,BNG设备需要执行QoS策略,来保证每家每户组播流量不会超出shaping的数值。当IGMP join/leave的消息从每户机顶盒发给OLT设备的时候,OLT对这些IGMP消息打CVLAN的tag,并通过CVLAN发送给BNG设备。这样,BNG设备使用IGMP消息作为标识视频频道的方式,来识别具体是哪个频道,这家用了几个频道,等等。使用这个信息呢,可以做组播COS的调整,动态调节scheduler,允许组播流量占用单播流量的带宽。

我们在本次分享中主要探讨两个技术,一个是层次化用户目标Hierarchical Subscriber Targeting,另一个是层次化组播COS调整Hierarchical Multicast COS Adjust

我们先集中探讨Hierarchical Subscriber Target技术。我认为大部分同学都熟悉802.3AD聚合以太网技术。这个技术支持两种部署模式: 冗余优化模式 VS 带宽优化模式。冗余优化模式意味着一个捆绑里最少两个物理链路,但是每个物理链路都有一个冗余链路,数据流在同一时刻是流经一个链路的,另一个链路是处于standby模式的,如果主链路DOWN掉,备份链路就会取而代之。带宽优化模式就是流量流经所有的物理链路,可以使用所有的捆绑的带宽。这是一个非常容易理解的概念

那我们为什么需要Hierarchical Subscriber Target呢?主要的原因是Shaping的精度。下行流量在AE链路上的分布是通过链路之间的hash算法确定的。 有时候数据流并不能均匀分布,直接导致的结果就是shaping比预定时间更早的被调用,这就最终导致你所谓的1G流量业务并不能达到。

那么Targeting到底是什么?这是一个软件的功能呢,可以使得流量在一定时间内在多条物理链路上能得到均匀分布,运营商可以完全使用所有的带宽。

当前JUNIPER MX作为BNG设备所能支持的特性在这个页面列出来了,一个比较新的FEATURE就是Hierarchical Subscriber Targeting. 大伙儿可以看到,完全没有targeting的功能的时候(图中底部最左边的情况)每家每户的数据流基本能均匀分布在LAG的多链路上,这就造成了shaping的不准确的问题,targeting就是解决了这个问题,使得每户的流量在只跑在特定物理链路上,以便于被shaping。

这个feature在JUNIPER内部叫作IFL SET TARGETING,这个特性也是为了保证PON级别的流量shaping。从图中可以看到,与其让所有家庭&所有PON的流量分布在多物理链路上,我们的采取的方式是直接把多个用户流量汇聚到特定的PON设备上,然后走某一特定物理链路,这就保证了shaping的精度。其他PON设备所带的家庭用户的汇聚流量走特定的其他物理链路。

我们来看一下具体实现方式。主要目标呢,就是均匀分布PON设备的流量(在JUNOS内部叫IFL-SET, 多逻辑子接口集合,来均匀分摊AE捆绑链路的多条物理链路)。以前是为每户实现的,现在采用类似的方式是为PON设备以及PON设备下挂多户实现的。所以最后的实现结果就是,每户,每个PON设备以及PON设备下挂用户都可以实现主备链路,使用最轻载链路算法来分配PON。对于Google Fiber的部署模式来说,最轻载的意思是,对于特定PON设备下,最少的家庭用户流量(CVLAN流量)。

图中有一个例子,以PON1为例,PON1下所带的所有用户业务流量,会在OLT<->BNG设备中的多物理链路汇聚以太网中选择一个物理链路为主用,然后另一条会被选择为备用链路。

对于一个特定的PON设备,如何选择备份的物理链路呢?各位还记得上面说的,每个PON设备分配AE bundle里的一个主用物理链路和一个备用物理链路,所以备份链路的选择算法是依靠于AE的冗余模式的。这种实现的方式可以支持多板卡甚至跨机框的方式,跨板卡方式中,备份链路不会选择同一块板卡上的接口。跨机框方式中,备份链路总是会选择另一个机框(这是为了将冗余实现最大化)。上面几条配置里最重要的部分是AE聚合接口的备份链路是可以指定的,DOWN掉的链路也是可以被指定的。

举个栗子,一个捆绑端口,四个物理链路,四号链路DOWN掉,与此同时业务新部署了一台PON设备,此时此刻你必须分配主链路,链路选择算法此时并不关心备份链路的分配是否可以利用DOWN掉的链路与否,所以可以选择DOWN掉的链路作为备份。

从运维的角度来说,DOWN掉的链路肯定会在主链路DOWN掉之前被恢复(呵呵,搁国内可不一定了哦)。所以在安排备份链路时,你可能并不想把这条DOWN掉的链路放那儿置之不理。

Conserving Cos Scheduler Resources

这一页进一步解释了为什么逻辑端口集合(IFL SET) targeting的设计只选择了一个主链路和一个备份链路而不是选择多条备份链路。主要原因就是scalability相关以及内部调度器资源的转换。这个设计其实是为单一链路故障的情景优化的,并延伸扩展为主链路中断以后,L2调度节点对剩余链路资源上的再次优化。所以对下一页图中一个例子,PON1上分配两个shaper, 一个给LINK1一个给LINK2(LINK1和LINK2都是属于同一个AE bundle的)。这些shaper的分配是与主备链路的选择相对应的。如果LINK1中断,主链路以及二级调度节点已经在备份链路上应用了,这就使得丢包降低到最少。所以呢,如果一个PON设备DOWN掉,PON1有LINK1和LINK2分别作为主备链路,PON1的shaper分别应用到主备链路。所以如果主链路DOWN掉,备份链路的流量直接可以转发,业务中断最小化(sub-second level)

Link Failure Handling – Single Link (Primary) Failure

此页用实例来说明这个情景(指定为主链路的链路中断), 这个例子里, 所有的PON1下面的家庭用户已经被指定啦. LINK1是主, LINK2是备份链路. 基本上主成员链路不会造成主备链路的再次分配. 这种设计有个假设, 就是NOC TEAM成员会在一定时间段内修复中断的链路, 然后并没有对流量中断的情景做链路重新选择以及scheduling的修改的需求. 在此情景下, 主链路恢复以后, 流量会自动切回主链路.

Link Failure Handling – Dual Link (Primary + Backup) Failure

本页详细解释了在两个member link failure的情境下的hierarchical subscriber targeting算法的工作原理. 具体来说, 主备链路都在PON1上, 然后PON1 down掉. 前面一页PPT说的情况是正常的PON1相关流量流经LINK 1也就是主链路, 如果主链路DOWN那么就走备份链路. 这里要说的是, 如果主备都DOWN了的话, 那么就会激发主链路的重新选择流程. 所以除了选择新的主链路以外, 一个新的COS调度节点会被在主备链路上都应用, 在发生这种切换情况的时候, COS的算法也应该考虑进去. 当这种情况发生时, 流量临时被切换到剩余的端口调度器(port scheduler)上, 再说一次, 这是临时的, 在PON1全部DOWN掉的情况下的临时流量, 使用剩余的port scheduler. 与此同时, 也要选择新的备份链路. 所以呢, 当流量切换到新选的主链路上的时候, 经过一段时间, NOC的人把原来的主链路恢复的时候, 流量并不会自动切换回已经恢复的链路. 这样做的目的是防止流量切来切去导致对用户的影响.

说了这么多术语, 其实大白话就是说, 不仅要考虑到流量在主备链路上的切换, 同时COS的设置也要保证即使切换到备份链路上的流量也能有COS的保证.

Operational Behavior – AE Member Link Adds / Removes

这一页内容要说明一下增加或减少成员链路时QOS的targeting算法怎么工作的. Member link被加到bundle里, 对于现有的算法不受影响, 也就是说, 并不激发与PON关联的主备链路选择. 新member link加入时, 分配weight为0, weight数值就等于一个PON所带的在跑流量的家庭用户数. 现在这种情况, 一个新member link有0个PON, 0个家庭用户, 所以最开始的weight是0. 随着你添加新的PON设备和上线更多的接入家庭用户, 流量会在多条member link上有一个比较合理的分布(具体原理稍后说). 此时你如果从一个bundle中删除member link会怎么样? 如果你这么做的话, targeting算法会对所有的PON设备新选出一个主用链路. 这个新的主用链路在移除member link之间就已经被选出了(目的是为了尽可能减少转发流量的中断), 所有的PON以及所有与被移除的member link关联的接入用户都会被重新分配一个新的主用链路和备份链路.

Problem Statement and Solution – Hierarchical Multicast CoS Adjust

这几页说明一个互联网接入的问题, 与Google Fiber的部署情景直接相关, 那就是层次化组播COS的调节. 问题是什么? 功能解决什么问题? IPTV与视频业务增长, 通过IP宽带网来转发视频业务, 对每户的接入带宽提出了很高的要求, PON以及每户接入带宽的过载比越来越大. 基于这种趋势, Google目前想解决的问题是, 在PON有过载比的情况下, 怎么保证视频流的质量以及是否能够基于每户做单一的SLA呢? 看这一张图大伙儿就会知道, 一般有2个拥塞点, 家庭用户处和PON设备处. 实现方式就是允许对每户部署shaper并且在PON的层面对每户部署汇聚带宽, 这样下行方向的流量会受到shaper的限流, 不会对上述2个拥塞点造成影响. 在Google Fiber的情况下, 每户是1Gbps带宽, 每个PON设备是2.5Gbps带宽.

主要是对BNG提出了要求, 要求BNG设备能动态地对部署在家庭层面和PON设备层面的特定shaper能同时自适应流量. 意思是说, 在视频以及HDTV高质量业务部署的同时, 能够通过动态调整shaper来牺牲其他相对不重要的带宽来保证视频流业务. 举例: 每户一个1Gbps的shaper, 允许shaper内的视频业务带宽增长, 从而牺牲其他业务如Internet访问要慢一点. 通过这么做, 实际上BNG包括了家庭网络以及PON设备, 并动态的调整这些shaper使得流量被动态的限制, 最终能达到为每个用户提供高质量视频业务. 这种实现支持IGMPV2和IGMPV3. 在这个例子里, IGMP是很重要的协议, 可以让BNG了解家庭用户消耗了多少组播频道. 具体的做法是通过CVLAN的IGMP消息来学得的, BNG可以获得多少组播数据流在被家庭用户消耗, 就可以动态调整下行单播流量(一般是Internet traffic). 原来的具体实现能够支持家庭用户级别的动态COS调度的调整, 这个新特性可以使得动态COS调度在家庭用户级别和PON设备级别可以同时进行.

Use Case Example – Hierarchical Multicast COS Adjust

这是一个实际案例的层次化的组播COS调整的功能. 这个例子显示了一个PON设备带4户家庭. 右上角表格显示了每户的1Gbps的shaper和每个PON设备的2.5Gbps的shaper. 当用户使用组播流量的时候, 你可以观察到这些shaper是如何的被动态调整的. 最终, 这个表格显示了BNT和OLT设备之间的组播流量信道的数量. 这里要注意的是: 如要有效的发送组播内容, BNG和OLT设备之间每个信道只能有一份流量的copy

让我们对这个例子进行更多的说明. 首先, home1用户的机顶盒请求channel1, 接下来就是机顶盒发出IGMP join request, 然后OLT设备接收到join request, OLT然后把这个和CVLAN信息关联的join request发给BNG, BNG就知道是哪一户或者哪几户接受了哪些组播频道的流量, 并对关联的账号进行流量调度与调整. Home1机顶盒请求了channel1, 右边这图的意思是home1和关联的PON1的流量都被降低了8Mbps以便于给channel1提供足够的带宽. 你可以看到channel1和channel2的流量在BNG和OLT之间转发. 下一步, home2机顶盒对channel2发起请求, 类似地, 只有home2的scheduler被调整带宽而PON设备的scheduler并没任何调整. 原因就是channel2的流量已经通过BNG和OLT之间的组播VLAN 转发, 所以在那种情况下没有必要调整PON设备级别的scheduler

下一步, home2对channel1发起请求, 同样的, 你会看到BNG和OLT之间的信道数量并没有发生变化, 仍然是channel1和channel2, 只是home2的shaper被调整了8Mbps下去, home2现在就开始看channel1的视频节目了, 此时并不需要再次调整PON设备的scheduler.

接下来home3的情况. Home3请求channel1的流量, 只有home3的1Gbps的shaper(针对家庭用户的)会被动态调整8Mbps. Home4请求channel1流量, 仍然, 只有1Gbps shaper会动态调整, PON设备无任何scheduler调整, 因为先前的PON设备级别的流量调整已经做过了. 最后, home3请求一个新的频道, channel3, 这时候会发生什么呢? 大伙儿会注意到home3已经降低了8Mbps的流量, home3的shaper已经调整了8Mbps流量, 然后BNG和OLT之间已经开始发送channel3的流量了, PON设备级别的scheduler也被调整了.

总结起来, 每一家每一户都有足够的组播频道来观看高清视频节目, BNG能够动态的针对PON设备级别和家庭用户级别动态的调整scheduler来保证视频接的带宽可以抢占其他类型的流量带宽. 这样就保证了视频节目的质量和用户的体验, 同时只有在家庭用户请求新的频道时, PON设备级别的scheduler才会调整.

原文发布于微信公众号 - SDNLAB(SDNLAB)

原文发表时间:2016-07-16

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏程序人生

Sound of silence: 数据传输的小众黑科技

上周面试了一个来自俄罗斯的 android 工程师。很 geek,对 office 的 binary format(不是后来的 xml format)做过深入的...

2845
来自专栏hrscy

初识 Unity3D

早些年,游戏引擎市场的变化是非常大的,其中有一些比较出色的软件。比如 unreal,但是 unreal 走的商业模式针对的是大型的游戏公司,大公司通过购买序列号...

1473
来自专栏企鹅号快讯

OpenContrail 移交 Linux 基金会、TensorFlow 曝安全风险……

导读 本周开源云业内倒是出现一些比较有趣的消息。首先是Deepo项目在GitHub上的爆红。小编简单了解了一下该项目,用“强大”来形容并不为过,其不但能实现快速...

2135
来自专栏斑斓

设计:小即是美

博尔赫斯说:“写散文体的短文——寓言、神话、短故事——给了我某种神秘的满足。想起这些篇章,就仿佛想到硬币:实在、结实、闪光的小物体,更多的东西的样品。”显然,小...

3415
来自专栏腾讯Bugly的专栏

微信iOS收款到账语音提醒开发总结

一、背景 为了解决小商户老板们在频繁交易中不方便核对、确认到账的痛点,产品MM提出了新版本需要支持收款到账语音提醒功能。这篇文章总结了开发过程中遇到的坑和一些小...

4436
来自专栏Java帮帮-微信公众号-技术文章全总结

​全球数据库排名/主流语言2017的改变

全球数据库排名 DB-Engines 发布了 2018 年 1 月份的数据库排名。排前 20 名的数据库中,Oracle 稳居第一,Redis 超过 Cassa...

3556
来自专栏编程一生

漫画:鉴权与安全访问控制的技术血脉

    十年前,静儿做的是传统软件的项目,都是企业定制的项目,系统安装在企业的机器上,通过硬件来做物理隔离。系统的安全访问控制靠操作系统来保证。

751
来自专栏SDNLAB

SDN技术分享(十):GoogleFiber的宽带接入速率控制解决方案

本次分(zhuang)享(bi)呢,主要探讨一个新兴SP客户的案例。 G家,这是非传统的SP。我们一起来看一下G家的市场策略以及使用的关键技术. 内容比较多,我...

3097
来自专栏Java架构

两个月拿到N个offer,看看我是如何做到的

北京-三年经验-Java,在金三银四这两个月期间(在五月初还去面试了几家,主要是三四月份期面试剧居多),我跳槽面试,前前后后我面试十五家公司,最终,成功拿到了o...

2615
来自专栏大数据挖掘DT机器学习

如何科学地蹭热点:用python爬虫获取热门微博评论并进行情感分析

甩锅の声明 1.本数据节选自新浪热门微博评论,不代表本人任何观点 2.本人不接受任何非技术交流类批评指责(夸我可以) 3.本次分析结果因技术问题存在一定误差(...

8935

扫码关注云+社区

领取腾讯云代金券