解耦重構 Internet BGP SDN
1 介紹/Why
高清視訊直播和雲端計算的蓬勃發展，帶來網際網路流量持續高速增長，主流雲公司的Internet出口頻寬都已經達到Tbps級別。 鑑於網路的擁堵大部分發生在出口互聯，Edge Peering Fabric的架構設計直接影響到終端客戶的使用者體驗， 2017年Google/Facebook對外發布了兩種不同的Edge 設計理念，本文試著以Google Espresso為主詳解下一代Cloud Edge的架構，並簡單介紹一下Facebook Edge Fabric。
藉助成功部署業界第一個SDN網 B4資料中心互聯的經驗，Google工程師重新設計了全新的Espresso Peering Fabric。在2017年Espresso已經部署了3年多，服務20%的Google使用者，也就是說你看5次Youtube，就有一次機會Espresso控制器幫你調優轉發路徑。Espresso採用SDN動態調整BGP出口頻寬，快速迭代最新特性，在全球TE控制器配合下，Espresso可以提供比傳統BGP路由多傳送13%的客戶流量。同時可以顯著提高每條鏈路利用率和端到端使用者體驗。有效減少了客戶流量的Rebuffers（減少35%-170%）。
首先簡單介紹一下Google的網路，截止2018年1月，Google全球有33個數據中心，100+多個POP站點，同時在不同運營商網路中有很多Offnet Cache站點。資訊從Google資料中心資訊大致經過DC-POP-Cache三級網路傳送到終端使用者。
Google的廣域網實際上分為B2全球骨幹網和B4（DCI）資料中心網際網路。如下圖所示。B4作為Google全球資料中心互聯採用自研交換機裝置，執行純IP網路。B2連線資料中心和POP點，採用廠家路由器裝置，並且執行MPLS RSVP-TE進行流量工程調節，正在進行SDN/SR改造。簡單的說，B4負責資料中心到資料中心的流量轉發（Machine to Machine），B2負責資料中心到使用者的流量轉發（Machine to User）。關於B4詳細資訊，請參考 ofollow,noindex">Google B4 廣域網SDN 的前世今生
Google在ONS Summit 2017上推出了他的第四個SDN控制器Espresso（濃縮咖啡），在Metro網路中新引入SDN控制器來調整出方向（Egress）流量。在Google B4 DCI網路中，所有裝置都是Google自己設計實現的。可以做到很好的端到端控制， Host/Switch/WAN全路徑流量可規劃和可程式設計（Walled Garden）。如何在開放的Internet BGP Peering上來提供Application Aware SDN？Google 嘗試用全新的Espresso來解決這個問題。
Espresso首要需求是： 動態調整每使用者/每應用流量，在PR出口避免擁塞 。現有的互聯Peering網路是依賴於BGP設計的。BGP設計之初是為了提供穩定的聯通性，完全沒有考慮網路的動態變化，網路的需求，容量和效能都在每時每刻變化（BGP doesnt consider Demand, Capacity and Performance）。舉個例子，對8.8.8.0/24的網段，可能有兩個ISP或者ASBR都發送相同的路由。ASBR會根據BGP策略選擇一個最優路徑，比如上圖中，選擇ASBR1。過了10分鐘，到ASBR1的鏈路擁塞了，BGP不會做任何動作。只有當這個8.8.8.0/24 prefix從路徑1不可達，BGP才會選擇次優化路徑。BGP號稱是動態路由協議，實際上是非常靜態的。但是BGP也不是無可救藥，BGP有很多靈活的策略，比如根據Local Preference /Community/ Add Path 去調整選路。 不過需要網路管理員手動調節。 雖然BGP有這麼多問題，但是大多數的傳統的SP/ISP還在採用BGP互聯，Google/Facebook還不能拋棄BGP，所以Google/Facebook引入SDN控制器來自動調節BGP出口流量。
Google Metro原有設計最重要的缺陷是沒有全域性觀Metro View， 沒有辦法進行全域性優化，引入新的特性 。通常Google在Metro實時監測百萬使用者的流量頻寬時延，不同應用不同優先順序流量在鏈路分佈。但是很難（受限）在路由器上進行細顆粒度的控制/改寫override BGP轉發行為。即便是可能去更改， 也需要廠商路由器裝置去配合。一般至少需要一年時間去通知廠商開發一個特性 ，才能成功部署在OTT網路中。無法滿足Google的應用快速迭代要求。
1.1 Egress/Ingress Peering Engineering
傳統的流量工程僅僅 關注在IGP域部分，致力於避免網路內部擁塞。對於Cloud/Video/CDN等業務，網路的瓶頸還存在於BGP Peering部分。傳統運營商能採用什麼思路來解決BGP流量工程問題呢。如何找到沒有擁塞的ASBR和BGP Peering鏈路進而提高網路傳送能力？
C/J的路由專家和OTT專家討論之後，提出了兩種不同的思路來解決。核心思想都是給Peering Link分配標籤，一種方式通過BGP-LU攜帶，另外一種通過BGP-LS攜帶。
● draft-gredler-idr-bgplu-epe-xx(RtBrick/Juniper)
● draft-ietf-idr-bgpls-segment-routing-epe-xx(Cisco/ Arrcus)
下面以BGP-LU方式為例解釋一下流程：
● 引入SDN控制器蒐集全網BGP prefix路徑資訊和Peering鏈路流量資訊（Netflow/Telemetry）
● SDN控制器跟ASBR建立BGP-LU（3107）鄰居，並且給每個Peer分配一個標籤。
● SDN控制器根據實時鏈路狀態，計算最優路徑，例如每隔30秒來根據（latency/bandwidth/optical SRLG etc）來選擇避免擁塞的ASBR或者某個鏈路。
● SDN控制器在Ingress頭結點（可以是vRouter/TOR，也可以在GW router）進行策略控制：
1.外層隧道採用Segment Routing壓上多個標籤，外層SR標籤找到ASBR，內層BGP-LU標籤找到Peering
2.外層隧道也可以採用GRE/LDP等，建立Ingress/ASBR的直連MPLSoGRE隧道。在ASBR上解掉GRE封裝，通過查詢MPLS標籤來指導Peering轉發。
在BGP EPE轉發路徑上有個比較特殊的屬性，從使用者網路AS內部到Peer ASBR的轉發，不需要查詢Internet路由表，僅僅需要MPLS轉發。
入方向（Ingress）流量根據Global LB(Google採用Meglev)或者BGP Addpath（運營商）來優化。這裡不再詳述。注意入方向進到ASBR流量可以是IP，ASBR只需要儲存Google/Facebook內部網路的Prefix轉發表（<<128K）。
利用給每個Peering分配標籤特性，把完全Internet轉發表的需求轉移到Ingress Router（或者Host），可以採用新型態的LSR /Lean Core裝置做Internet Peering，可以大幅減少網路投資。同時引入SDN控制器可以動態監控網路擁塞情況，動態調整BGP轉發策略，極大的減少了網路的人工干預。關於更多詳細的BGP EPE解決方案，請參考我們在2016年初在New Zealand Apricot上的演講。 http://t.cn/RnXyHhR
2 Espresso詳解
前面講到Espresso來改造Google Metro，通常來講Metro提供三個基本的功能
● 路由器：提供BGP路由與合作伙伴對等交換。
● 伺服器池：負載分擔和CDN靜態快取內容分發
● 伺服器池：提供反向TCP代理
全新的Cloud Edge架構設計需要支援超低時延應用，提供重要的Anti-DDoS功能，並且能有效利用CDN減少經過雲骨幹網的流量。
從上圖可以看到主流的OTT都部署了反向web代理。以Facebook為例，從首爾訪問俄勒岡的資料中心，在跨越太平洋光纜一般要引入75ms的單程延遲。如果沒有采用反向web代理（圖左），從客戶開始訪問到收到網頁，需要600ms。利用在東京的POP點裡面的反向Web代理之後，延遲可以降低到240ms。使用者體驗得到極大提高。
2.1 Espresso系統架構
為了更好的規劃Metro裡的流量排程，Espresso引入了全球TE控制器（B4中也採用了）和本地控制器（Location Controller）來指導主機發出流量選擇更好的外部Peering 路由器/鏈路，進行per flow Host到Peer的控制。
並且解耦了傳統Peering路由器，演進為Peering Fabric和伺服器叢集（提供反向Web代理）。
控制和轉發流程：
● 外部系統請求進入Google Metro，在Peering Fabric上被封裝成GRE，送到Meglev負載均衡和反向web代理主機處理。如果可以返回快取記憶體上的內容以供使用者訪問，則該資料包將直接從此處發回。如果CDN沒有快取，就傳送報文通過B2去訪問遠端資料中心。
● 主機把實時頻寬需求傳送給全域性控制器（GC）
● GC根據蒐集到的全球Internet Prefix情況，Service Class和頻寬需求來計算調整不同應用採用不同的Peering路由器和埠進行轉發，實現全域性出向負載均衡。
● GC通知本地控制器（LC）來對host進行轉發表更改。同時在PF交換機上也配置相應的MPLSoGRE 解封裝。
● 資料報文從主機出發，根據GC指定的策略，首先找到GRE的目的地址（PF），PF收到報文之後，解除GRE報文頭。根據預先分配給不同外部Peering的MPLS標籤進行轉發（注意，採用集中控制器，不需要引入BGP-LU來分配MPLS標籤）。如上圖所示，如果採用紅色MPLS標籤，就會轉發給紅色鏈路。
下面針對不同的子系統詳細講解。
2.2 全域性和本地控制器
全域性控制器是一個分散式系統，持續不斷的蒐集各類資訊，並且定期產生針對應用優化過的轉發規則。進行並且通過本地控制器（LC）在各個區域釋出。本地控制器提供本地決策，來快速應對本地鏈路和Prefix的變化。
為了實現應用感知，全域性控制器需要蒐集：
● BGP Peering/Prefix資訊，類似BMP全網路由和Peering關係。
● 使用者頻寬和效能需求，通過L7 Proxy蒐集每使用者頻寬，延遲需求，並彙總。一般針對/24目的路由產生相近的延遲資料。
● PF出介面每佇列鏈路利用率
全域性控制器的輸出是一個Egress Map規則，對特定{ POP | Prefix |Class }，選擇出口{ ASBR | Port }。
本地伺服器收到GC的應用優化規則，結合從EBGP過來的實時peering路由資訊，來產生主機轉發表。為了Anti-DDoS攻擊，還需要LC來下發大規模ACL轉發表項到主機。一臺本地控制器可以控制大概1000臺伺服器，持續不斷的更新主機轉發表項和ACL。
上圖可以看到，LC 收到GC 轉發規則之後，對每個主機，需要產生不同的{ Prefix | Application
Class } 採用不同的出口{ PF | Port | %}，並且迭代找到相應的GRE/MPLS 封裝。
2.3 解耦Peering Router 演進到Peering Fabric
Espresso 另一個主要的設計原則是解耦路由器，演變成Peering Fabric。
傳統的Peering 裝置，由廠家統一提供軟體和硬體。軟體新特性開發週期過長。把非必要的功能從
Peering 路由器拿掉，僅保留最簡單的MPLS（Label-Switch Fabric）資料轉發平面。SDN 軟體特性
開發工作由Google 工程師主導，可以極大提高 網路可程式設計性（Programmability） ：
1. BGP Speaker 功能，從路由器移出來，採用Google 自研Raven BGP 協議棧，執行在專用伺服器上，可以支援更多的Peering，執行更復雜的優化演算法，更精細的路由器控制。僅僅實現必要的Feature。
● a. 支援多核和Scale Out 控制平面，支援BGP Graceful Restart
● b. 同一個Peering fabric可以執行多個Raven例項。多個session可以平均分配到Raven例項。當Raven出錯時，僅僅影響少量的BGP session
● c. 之前採用Quagga，面臨一些問題，Quagga只有單執行緒，C語言除錯工具太少等。
2. 伺服器叢集：出方向（Egress）報文Internet路由查表/封裝和ACL訪問控制列表等放到在Edge裡面的大規模伺服器叢集。
● a. 每個Host裡面都存放完整Internet路由表。IPv4 FIB採用Compressed Multibyte Tire 演算法，採用Binary Tire做IPv6 FIB查表。
● b. Espresso現網執行環境每個Host中，大概有190萬Prefix/Service Class Tuple表項，佔用 1.2GB記憶體。 峰值可以做到每Host傳送37Gbps報文，大概3Mpps。查FIB表CPU佔用率 2.1-2.3%左右。
● c. Host裡儲存大規模Internet Facing ACL（MPLS Switch硬體表項太小），配合支援Anti-DDoS等業務，一小部分常用ACL放到PF裡面進行業務線速轉發。
3. Peering Fabric（PF, MPLS Switch）：進行MPLS轉發，僅支援小規模FIB表和ACL表項。減少路由器成本
● a. 採用Openflow來編輯MPLS轉發表，並且配置IP-GRE規則來匹配BGP協議報文傳送去相應伺服器，並生成MPLSoGRE轉發表。
● b. Switch裡面保留常用ACL（小規模）線速轉發。5% ACL可以匹配99%的流量。在軟體Host裡面儲存另外95%的ACL，從PF透過GRE tunnel把流量轉到Host做進一步處理。
4. Peering Fabric 控制器
● a. 對映BGP Peering到不同的Raven例項。
● b. 管理PF轉發表
2.4 配置管理紅色按鈕-Big Red Button
Espresso採用自動化Intent-Based配置管理工具。 收到人工可讀的意向（Intention）配置管理工具會翻譯詳細的可以被裝置理解的配置。
為了安全性和易用性考慮，Espresso提供了一個大紅按鈕（Big Red Button，BRB）配置管理功能。管理員可以很容易安全的關閉部分/全部系統功能：
● 可以告訴LC下發給所有主機採用本地最佳路由，不用接受全域性控制器指令。
● 可以移除一個或多個BGP鄰居。
● 點選BGP管理GUI可以移出流經這個Peer的流量。
3 Facebook Edge Fabric簡介
2017年Sigcomm大會，Google和Facebook同時釋出了兩種不同的Edge架構。下面簡單介紹一下Facebook Edge Fabric的架構。
● 首先，Edge Fabric也引入一個SDN/BGP控制器。
● SDN控制器採用多重方式蒐集網路資訊
● 控制器基於實時流量等相關資訊，來產生針對某個Prefix的最優下一跳。指導不同Prefix在多個ASBR之間負載均衡。
● 控制器和每個Peering Router建立另一個BGP 控制session，每隔30秒鐘用來改寫Prefix，通過調整Local Preference來改變下一跳地址。
● 因為BGP不能感知網路質量，Edge Server對特定流量做eBPF標記DSCP，並動態隨機選一小部分流量來測量主用和備用BGP路徑的端到端效能。排程仍然發生在PR上，出向擁塞的PR上做SR Tunnel重定向到非擁塞的PR上.如下圖所示：
從上圖可以看出Facebook採用的都是業界主流廠商支援的協議來實現Edge Fabric。同時有這樣一些限制：
● SDN控制器單點控制PR裝置。如果PR裝置已經Overload，需要通過PBR和ISIS SR Tunnel轉移到另一個沒有擁塞的PR，流量路徑不夠全域性優化。
● 控制器只能通過Prefix來控制流量，但是同一個prefix，可能承載視訊和Voice流量，頻寬和時延要求不同，Edge Fabric沒有Espresso那麼靈活。
Facebook介紹，最早他們的嘗試過集中不同的方案，從Host選路到PR，都不太成功。
● 從Host建立LSP到PR
● 從Host 標識DCSP，PR根據DSCP轉發到不同埠
● 從Host採用GRE tunnel到PR。
最後選擇了BGP Inject@PR方案，他們認為是現階段比較適合的方案。在最近的Network@Scale 2018大會上，Facebook工程師說，未來Edge Fabric架構可能考慮轉向BGP EPE和Segment Routing。
下表我們總結了兩種方案的比較，請參考。
4 總結和展望
本文介紹了三種不同的思路來解決BGP出口流量排程問題。
● BGP EPE：採用標準協議為主，SDN控制器通過BGP LU/BGP-LS/Netflow方式選路。
● Facebook Edge Fabric：SDN控制器計算最佳路徑，BGP Local Preference 方式來路由注入
● Google Espresso：主機存放完整Internet路由，SDN控制器找到相應ASBR/Port.
從端到端架構圖中，可以看出在一個POP或DC WAN， Core/Aggregation 裝置大多已經採用Lean /BGP Free Core解決方案不用儲存完整Internet路由。通過Espresso，Google改造/解耦了 Peering/ASBR 路由器，通過把大部分軟體控制功能移到伺服器。PF裝置可以採用更簡單的MPLS Switch（QoS能力強，大Buffer，小型FIB表，小型ACL表，類似B公司Jericho系列）。加上之前B4已經採用了CLOS架構的Stargate Switch裝置。
Google已經成為業界第一個在WAN網路中沒有采用傳統Router的OTT公司。全網已經改造為Switch/Server的架構。對於在POP和DC中有大規模伺服器的Google來講，在POP中的每個Server處理內容的基礎上加上1.2GB記憶體和2-3%的CPU來實現Internet路由查表和隧道封裝基本上是可以接受的。
相比Facebook Edge Fabric，Google Espresso完美的解決了Application Aware TE問題，但是開發工作量也是巨大， Google為Espresso開發了很多全新元件：
{ 全新層次化SDN控制器GC/LC，全新BGP協議Raven實現，全新主機IPv4/IPv6 轉發表， 全新路由器解耦PF MPLSoGRE隧道介面，實時L7 Proxy流量需求 }
Espresso 僅僅改造了Metro POP, 今後會不會在B2採用類似Espresso架構來打通Backbone和Peering Fabric進行跨越B2全網流量排程？期待Sigcomm 2019 Google能夠揭曉更多B2改造成果！
國內OTT Metro改造展望
雲端計算進入下半場，企業上雲（Cloud Onboarding），網路SDN動態調整的能力越發重要。從雲到網需要端到端聯動{ VPC/DCI | Metro | Cache | SDWAN }，OTT SDN全網改造勢在必行。
Google的網路改造方案是否過於複雜（Over Engineering）？Facebook Edge Fabric過於簡化，能否找到一條更適合中國OTT的技術路線來改造POP點？本人認為:
1. 技術路線應該選擇類似BGP EPE方案，跟Google保持一致。
● a. 不要採用BGP Inject方式，防止PR裝置過載。並且可以做全域性排程
2. 有條件情況下儘量採用Segment Routing + EPE 方式
● a. Google採用MPLSoGRE，是因為Metro/PoP一般比較小，內部也不會太擁塞。如果從超大資料中心跨越骨幹網，最好是採用SR+EPE，避免魚形TE問題。
● b. 對於BGP協議在伺服器實現的方式，入方向BGP協議報文可以走GRE。
3. 跟雲平臺和OTT網路使用者確定流量需求介面，支援Application Aware SDN
● a. 不光基於Prefix進行流量排程，最好分不同業務Class來指導轉發。
4. 裝置形態
● a. 大雲公司可以嘗試BGP跑在伺服器，並且在Host支援IPv4/IPv6全internet轉發表。但是需要工程師不斷調優。最近Linux Native 支援VRF，FRR等開源軟體也支援EVPN on Host。
● b. 建議採用PTX/NCS/Jericho/Jericho2等類似裝置，尤其是10T盒子/Chassis內建HBM2，一般1M FIB起跳，減少轉發表沒有太多裝置成本節省。
隨後我們會繼續詳解Google/Facebook/AWS 等OTT網路架構，下篇想談談Facebook DC, Fabric Aggregator, Express backbone，Edge Fabric和Open/R等，接下來也會詳解AWS網路和雲架構。敬請期待。
原文釋出時間為：2018-10-16
本文作者：gated