NFV相關
隨著云計算、SDN、虛擬化等理念和技術的不斷成熟,以通用替代專有將原本傳統專業的網元設備上的網絡功能提取出來虛擬化、軟件化,運行在通用的硬件平臺上,這種變化即網絡功能虛擬化,Network Function Virtualization (NFV)。網絡對用戶提供的服務是由多種運行在虛擬容器中的網絡功能組合而成的,其中每一個小的網絡功能其實就是個網絡服務Network Function as a Service (NFaaS)。當網絡重載時只需要增加網絡功能節點即可達到擴容;網絡輕載時釋放網絡功能節點即可減少資源占用;新業務部署只是多種網絡功能的重新組合。網絡功能虛擬化讓網絡更加靈活。
ONOS Framework (ONOSFW) for OPNFV
OPNFV是一個網絡功能虛擬化的開放框架,ONOSFW項目使ONOS作為SDN控制器集成進OPNFV框架中,實現OpenStack利用ONOS進行虛擬網絡資源管理。
用戶通過OpenStack提出對網絡的需求,ONOS實現Neutron L2、L3插件獲取網絡、主機數據。ONOS的VTN Resource manager App負責存儲從Neutron獲取的數據,并對外提供統一的接口。
VTN manager App根據網絡數據生成配置信息及流表,通過OVSDB和Openflow完成對OVS的配置及流表下發實現主機互通。VTN manager App監聽ONOS core事件,同時通過VTN Resource manager監聽Neutron事件,當OVS或主機上下線時更改配置信息及流表,及時響應網絡變化。

圖表 1. ONOSFW 示意圖
Service Function Chaining (SFC)
很多場景中,需要把用戶的數據分類,不同類型的數據要做不同的處理。例如移動終端用戶數據等在運營商的網絡中有一些要根據流量計費,有一些要根據需要送到特定服務提供商等。Service Function Chaining (SFC)業務鏈就是把流量分類后,為不同類別的流量定制不同路徑做分類處理的技術。
ONOSFW項目讓主機間實現了互通,在此基礎上,給某一些VM賦予一些業務功能(例如防火墻,DPI等),則這些VM在SFC場景中稱為SF(Service Function)。一個數據包從源發出,根據用戶指定沿途會順序經過多個SF,這些SF組成的路徑就是SFP(Service Function Path)。ONOS的SFC就是讓ONOS按照用戶策略給OVS下發流表,控制數據包走不同的SFP。

圖表 2. ONOS SFC場景示意圖
CORD
CORD即Central Office Reimagined as a Datacenter的縮寫,用SDN、NFV、Cloud技術,基于商用硬件和開源軟件試圖搭建打造一個面向未來的運營商Central Office。目前ONOS已經有面對移動網絡的M-CORD,面對企業網絡的E-CORD,和面對固定網絡的R-CORD。

圖表 3. ONOS CORD項目
CORD中的技術作用如下:
1、SDN,實現網絡設備控制面和數據面分離,使網絡能力開放、可編程;
2、NFV,實現網絡功能虛擬化,降低CAPEX及OPEX;
3、Cloud,利用云技術提升業務\\網絡伸縮性,使業務部署更敏捷。
CORD: NFV(NFaaS)
ONOS的NFV(NFaaS)項目是ONOS CORD項目的一個子項,它把CORD網絡的各種物理設備實現的功能,轉換為軟件實現的網絡服務Network Function Software (NFS)的組合,主要目的是降低CAPEX及OPEX,同時使網絡部署更加敏捷。
NFV項目中,用OpenVirteX (OVX)實現網絡功能虛擬化,用ONOS的VxLan實現NFS間的互通,用OpenCloud(XOS)平臺把項目中的開源軟件集合有機地結合在一起。

圖表 4. XOS、OpenStack和ONOS
CORD: Leaf-Spine Fabric with Segment Routing
Leaf-Spine Fabric網絡是數據中心的基礎網絡,可以為大規模的數據中心提供可靠的無阻塞的數據傳輸。ONOS的Leaf-Spine Fabric項目是CORD項目的另外一個子項,主要目的是用Segment Routing搭建Leaf-Spine Fabric網絡,作為NFV網絡的underlay網絡。

圖表 5. Leaf-Spine Fabric作為underlay網絡
CORD: vCPE + vOLT
GPON網絡中終端通過駐地網關(RGW)接入ONT(光網絡終端),經過分光器匯聚到OLT(光線路終端)上。OLT是GPON網絡中的匯聚節點,下行連接眾多的ONT,上行連接寬帶網絡網關(BNG)對業務做控制并連接到骨干網。

圖表 6. GPON接入網
項目中的CPE指的是RGW設備是用戶網關,相當于用戶網絡到光纖接入網絡的出口。

圖表 7. CPE (RGW)功能
項目中所謂“vCPE”是把用戶駐地網關換成白盒交換機,由SDN控制器統一控制。而原來CPE實現的三層功能則在中心局中用NFV技術實現。
“vOLT”是把OLT功能分為兩部分,光信號處理等仍然使用物理設備,而匯聚后對業務的處理則同樣在中心局用NFV技術實現。

圖表 8. CORD項目中的vCPE和vOLT
ONOS特性增強類項目(Feature)
Kafka Integration
目前非Java語言寫的App只能使用ONOS Restful API,但很多數據或消息并沒有提供Restful接口只能通過Java API獲取。為了能讓非Java語言寫的App也能獲得這些數據,該項目提出在ONOS上集成Kafka系統的方案。Kafka是LinkedIn開發的一個開源的高吞吐分布式消息系統,結構如圖。集成后ONOS上會運行一個Kafka App作為外部App的代理,把ONOS Java API獲取到的數據發布到Kafka服務器上。

圖表 9. Kafka示意圖
Producer是消息的發布者;Broker是消息中間件處理結點,即kafka節點;Consumer是消息訂閱者。Broker中的Topic是按照消息類型來分的,而partition是具體的消息序列。
消息生產以后Producer會根據指定的策略把消息送到某個Broker上的某個topic的partition(即圖中part)中。消費者根據自己的需要自己到BROKER中獲取消息。
該項目提出在ONOS中增加JAVA語言開發的Kafka App,將ONOS的各種事件發布到Kafka服務器上,方便外部其他語言App訪問。
? 外部App向ONOS中的Kafka App注冊成為Consumer,并知會自己關心哪些事件;
? Kafka App創建對應事件的Listener,若該類型事件的Listener已經存在則不再創建,同時將Kafka服務器的地址和topic信息返回給外部App;
? 外部App根據Kafka App返回的信息,找到Kafka服務器,注冊成為Consumer,當有新消息送到時Kafka服務器會通知給外部App來服務器上獲取消息。

圖表 10. Kafka集成示意圖
YANG Models in ONOS
目的是在ONOS中引入模型化語言YANG。主要思路是在保持ONOS現有接口不變的情況下,用YANG Shell將ONOS目前的CORE北向接口YANG化,供YANG定義的App調用,同時對外提供Restconf接口。計劃完成ONOS的YANG Tools,以L3VPN為例實現App和南向驅動。

圖表 11. YANG Models
ONOS Multi-Clusters Peering Provider
同一個集群中的ONOS實例間的網絡信息是共享的,但是很多時候,端到端的業務會需要部署在跨多個ONOS集群的場景,此時ONOS集群間同樣需要網絡資源信息的共享。這個項目就提出可以讓ONOS集群間通過東西向接口共享網絡TOPO信息,部署跨ONOS集群的業務。
為了實現這個功能,ONOS新增了一種新的Provider即Multi-Clusters Peering Provider。它的功能主要由以下幾項:
1、在一個集群中,leadership機制會選出主Provider,只有主Provider才會將本集群中的網絡拓撲進行抽象,暴露給其他的Cluster;同時獲取其他Cluster的網絡信息并添加到自己的集群中。主Provider故障時leadership會重新選主。
2、Provider抽象本集群網絡信息的方法,是將本集群管理的網絡抽象為單個交換機,連接用戶設備和其他集群的ConnectPoint被抽象為該交換機的接口。其中連接用戶的ConnectPoint稱為CEP,與其他集群連接的鏈路稱為IL。Multi-Clusters Peering Provider在本地Store中存儲網絡拓撲與網絡抽象的對應關系,并將這些信息暴露給其他集群。并從其他集群獲取網絡抽象信息添加到自己的集群中。

圖表 12. Multi-Clusters Peering Provider對網路的抽象

圖表 13. 集群間網絡資源信息同步
3、連接到某一集群上的App發布集群間Intent時,Multi-Clusters Peering Provider會通過北向接口安裝Intent,并保存到本地Store中。

圖表 14. 集群間Intent安裝
審核編輯:郭婷
電子發燒友App
















評論