NFV相關(guān)

隨著云計(jì)算、SDN、虛擬化等理念和技術(shù)的不斷成熟，以通用替代專有將原本傳統(tǒng)專業(yè)的網(wǎng)元設(shè)備上的網(wǎng)絡(luò)功能提取出來虛擬化、軟件化，運(yùn)行在通用的硬件平臺(tái)上，這種變化即網(wǎng)絡(luò)功能虛擬化，Network Function Virtualization (NFV)。網(wǎng)絡(luò)對(duì)用戶提供的服務(wù)是由多種運(yùn)行在虛擬容器中的網(wǎng)絡(luò)功能組合而成的，其中每一個(gè)小的網(wǎng)絡(luò)功能其實(shí)就是個(gè)網(wǎng)絡(luò)服務(wù)Network Function as a Service (NFaaS)。當(dāng)網(wǎng)絡(luò)重載時(shí)只需要增加網(wǎng)絡(luò)功能節(jié)點(diǎn)即可達(dá)到擴(kuò)容；網(wǎng)絡(luò)輕載時(shí)釋放網(wǎng)絡(luò)功能節(jié)點(diǎn)即可減少資源占用；新業(yè)務(wù)部署只是多種網(wǎng)絡(luò)功能的重新組合。網(wǎng)絡(luò)功能虛擬化讓網(wǎng)絡(luò)更加靈活。

ONOS Framework (ONOSFW) for OPNFV

OPNFV是一個(gè)網(wǎng)絡(luò)功能虛擬化的開放框架，ONOSFW項(xiàng)目使ONOS作為SDN控制器集成進(jìn)OPNFV框架中，實(shí)現(xiàn)OpenStack利用ONOS進(jìn)行虛擬網(wǎng)絡(luò)資源管理。

用戶通過OpenStack提出對(duì)網(wǎng)絡(luò)的需求，ONOS實(shí)現(xiàn)Neutron L2、L3插件獲取網(wǎng)絡(luò)、主機(jī)數(shù)據(jù)。ONOS的VTN Resource manager App負(fù)責(zé)存儲(chǔ)從Neutron獲取的數(shù)據(jù)，并對(duì)外提供統(tǒng)一的接口。

VTN manager App根據(jù)網(wǎng)絡(luò)數(shù)據(jù)生成配置信息及流表，通過OVSDB和Openflow完成對(duì)OVS的配置及流表下發(fā)實(shí)現(xiàn)主機(jī)互通。VTN manager App監(jiān)聽ONOS core事件，同時(shí)通過VTN Resource manager監(jiān)聽Neutron事件，當(dāng)OVS或主機(jī)上下線時(shí)更改配置信息及流表，及時(shí)響應(yīng)網(wǎng)絡(luò)變化。

圖表 1. ONOSFW 示意圖

Service Function Chaining (SFC)

很多場景中，需要把用戶的數(shù)據(jù)分類，不同類型的數(shù)據(jù)要做不同的處理。例如移動(dòng)終端用戶數(shù)據(jù)等在運(yùn)營商的網(wǎng)絡(luò)中有一些要根據(jù)流量計(jì)費(fèi)，有一些要根據(jù)需要送到特定服務(wù)提供商等。Service Function Chaining (SFC)業(yè)務(wù)鏈就是把流量分類后，為不同類別的流量定制不同路徑做分類處理的技術(shù)。

ONOSFW項(xiàng)目讓主機(jī)間實(shí)現(xiàn)了互通，在此基礎(chǔ)上，給某一些VM賦予一些業(yè)務(wù)功能（例如防火墻，DPI等），則這些VM在SFC場景中稱為SF（Service Function）。一個(gè)數(shù)據(jù)包從源發(fā)出，根據(jù)用戶指定沿途會(huì)順序經(jīng)過多個(gè)SF，這些SF組成的路徑就是SFP（Service Function Path）。ONOS的SFC就是讓ONOS按照用戶策略給OVS下發(fā)流表，控制數(shù)據(jù)包走不同的SFP。

圖表 2. ONOS SFC場景示意圖

CORD

CORD即Central Office Reimagined as a Datacenter的縮寫，用SDN、NFV、Cloud技術(shù)，基于商用硬件和開源軟件試圖搭建打造一個(gè)面向未來的運(yùn)營商Central Office。目前ONOS已經(jīng)有面對(duì)移動(dòng)網(wǎng)絡(luò)的M-CORD，面對(duì)企業(yè)網(wǎng)絡(luò)的E-CORD，和面對(duì)固定網(wǎng)絡(luò)的R-CORD。

圖表 3. ONOS CORD項(xiàng)目

CORD中的技術(shù)作用如下：

1、SDN，實(shí)現(xiàn)網(wǎng)絡(luò)設(shè)備控制面和數(shù)據(jù)面分離，使網(wǎng)絡(luò)能力開放、可編程；

2、NFV，實(shí)現(xiàn)網(wǎng)絡(luò)功能虛擬化，降低CAPEX及OPEX；

3、Cloud，利用云技術(shù)提升業(yè)務(wù)\\網(wǎng)絡(luò)伸縮性，使業(yè)務(wù)部署更敏捷。

CORD: NFV(NFaaS)

ONOS的NFV（NFaaS）項(xiàng)目是ONOS CORD項(xiàng)目的一個(gè)子項(xiàng)，它把CORD網(wǎng)絡(luò)的各種物理設(shè)備實(shí)現(xiàn)的功能，轉(zhuǎn)換為軟件實(shí)現(xiàn)的網(wǎng)絡(luò)服務(wù)Network Function Software (NFS)的組合，主要目的是降低CAPEX及OPEX，同時(shí)使網(wǎng)絡(luò)部署更加敏捷。

NFV項(xiàng)目中，用OpenVirteX (OVX)實(shí)現(xiàn)網(wǎng)絡(luò)功能虛擬化，用ONOS的VxLan實(shí)現(xiàn)NFS間的互通，用OpenCloud（XOS）平臺(tái)把項(xiàng)目中的開源軟件集合有機(jī)地結(jié)合在一起。

圖表 4. XOS、OpenStack和ONOS

CORD: Leaf-Spine Fabric with Segment Routing

Leaf-Spine Fabric網(wǎng)絡(luò)是數(shù)據(jù)中心的基礎(chǔ)網(wǎng)絡(luò)，可以為大規(guī)模的數(shù)據(jù)中心提供可靠的無阻塞的數(shù)據(jù)傳輸。ONOS的Leaf-Spine Fabric項(xiàng)目是CORD項(xiàng)目的另外一個(gè)子項(xiàng)，主要目的是用Segment Routing搭建Leaf-Spine Fabric網(wǎng)絡(luò)，作為NFV網(wǎng)絡(luò)的underlay網(wǎng)絡(luò)。

圖表 5. Leaf-Spine Fabric作為underlay網(wǎng)絡(luò)

CORD: vCPE + vOLT

GPON網(wǎng)絡(luò)中終端通過駐地網(wǎng)關(guān)（RGW）接入ONT（光網(wǎng)絡(luò)終端），經(jīng)過分光器匯聚到OLT（光線路終端）上。OLT是GPON網(wǎng)絡(luò)中的匯聚節(jié)點(diǎn)，下行連接眾多的ONT，上行連接寬帶網(wǎng)絡(luò)網(wǎng)關(guān)（BNG）對(duì)業(yè)務(wù)做控制并連接到骨干網(wǎng)。

圖表 6. GPON接入網(wǎng)

項(xiàng)目中的CPE指的是RGW設(shè)備是用戶網(wǎng)關(guān)，相當(dāng)于用戶網(wǎng)絡(luò)到光纖接入網(wǎng)絡(luò)的出口。

圖表 7. CPE (RGW)功能

項(xiàng)目中所謂“vCPE”是把用戶駐地網(wǎng)關(guān)換成白盒交換機(jī)，由SDN控制器統(tǒng)一控制。而原來CPE實(shí)現(xiàn)的三層功能則在中心局中用NFV技術(shù)實(shí)現(xiàn)。

“vOLT”是把OLT功能分為兩部分，光信號(hào)處理等仍然使用物理設(shè)備，而匯聚后對(duì)業(yè)務(wù)的處理則同樣在中心局用NFV技術(shù)實(shí)現(xiàn)。

圖表 8. CORD項(xiàng)目中的vCPE和vOLT

ONOS特性增強(qiáng)類項(xiàng)目（Feature）

Kafka Integration

目前非Java語言寫的App只能使用ONOS Restful API，但很多數(shù)據(jù)或消息并沒有提供Restful接口只能通過Java API獲取。為了能讓非Java語言寫的App也能獲得這些數(shù)據(jù)，該項(xiàng)目提出在ONOS上集成Kafka系統(tǒng)的方案。Kafka是LinkedIn開發(fā)的一個(gè)開源的高吞吐分布式消息系統(tǒng)，結(jié)構(gòu)如圖。集成后ONOS上會(huì)運(yùn)行一個(gè)Kafka App作為外部App的代理，把ONOS Java API獲取到的數(shù)據(jù)發(fā)布到Kafka服務(wù)器上。

圖表 9. Kafka示意圖

Producer是消息的發(fā)布者；Broker是消息中間件處理結(jié)點(diǎn)，即kafka節(jié)點(diǎn)；Consumer是消息訂閱者。Broker中的Topic是按照消息類型來分的，而partition是具體的消息序列。

消息生產(chǎn)以后Producer會(huì)根據(jù)指定的策略把消息送到某個(gè)Broker上的某個(gè)topic的partition（即圖中part）中。消費(fèi)者根據(jù)自己的需要自己到BROKER中獲取消息。

該項(xiàng)目提出在ONOS中增加JAVA語言開發(fā)的Kafka App，將ONOS的各種事件發(fā)布到Kafka服務(wù)器上，方便外部其他語言App訪問。

? 外部App向ONOS中的Kafka App注冊成為Consumer，并知會(huì)自己關(guān)心哪些事件；

? Kafka App創(chuàng)建對(duì)應(yīng)事件的Listener，若該類型事件的Listener已經(jīng)存在則不再創(chuàng)建，同時(shí)將Kafka服務(wù)器的地址和topic信息返回給外部App；

? 外部App根據(jù)Kafka App返回的信息，找到Kafka服務(wù)器，注冊成為Consumer，當(dāng)有新消息送到時(shí)Kafka服務(wù)器會(huì)通知給外部App來服務(wù)器上獲取消息。

圖表 10. Kafka集成示意圖

YANG Models in ONOS

目的是在ONOS中引入模型化語言YANG。主要思路是在保持ONOS現(xiàn)有接口不變的情況下，用YANG Shell將ONOS目前的CORE北向接口YANG化，供YANG定義的App調(diào)用，同時(shí)對(duì)外提供Restconf接口。計(jì)劃完成ONOS的YANG Tools，以L3VPN為例實(shí)現(xiàn)App和南向驅(qū)動(dòng)。

圖表 11. YANG Models

ONOS Multi-Clusters Peering Provider

同一個(gè)集群中的ONOS實(shí)例間的網(wǎng)絡(luò)信息是共享的，但是很多時(shí)候，端到端的業(yè)務(wù)會(huì)需要部署在跨多個(gè)ONOS集群的場景，此時(shí)ONOS集群間同樣需要網(wǎng)絡(luò)資源信息的共享。這個(gè)項(xiàng)目就提出可以讓ONOS集群間通過東西向接口共享網(wǎng)絡(luò)TOPO信息，部署跨ONOS集群的業(yè)務(wù)。

為了實(shí)現(xiàn)這個(gè)功能，ONOS新增了一種新的Provider即Multi-Clusters Peering Provider。它的功能主要由以下幾項(xiàng)：

1、在一個(gè)集群中，leadership機(jī)制會(huì)選出主Provider，只有主Provider才會(huì)將本集群中的網(wǎng)絡(luò)拓?fù)溥M(jìn)行抽象，暴露給其他的Cluster；同時(shí)獲取其他Cluster的網(wǎng)絡(luò)信息并添加到自己的集群中。主Provider故障時(shí)leadership會(huì)重新選主。

2、Provider抽象本集群網(wǎng)絡(luò)信息的方法，是將本集群管理的網(wǎng)絡(luò)抽象為單個(gè)交換機(jī)，連接用戶設(shè)備和其他集群的ConnectPoint被抽象為該交換機(jī)的接口。其中連接用戶的ConnectPoint稱為CEP，與其他集群連接的鏈路稱為IL。Multi-Clusters Peering Provider在本地Store中存儲(chǔ)網(wǎng)絡(luò)拓?fù)渑c網(wǎng)絡(luò)抽象的對(duì)應(yīng)關(guān)系，并將這些信息暴露給其他集群。并從其他集群獲取網(wǎng)絡(luò)抽象信息添加到自己的集群中。

圖表 12. Multi-Clusters Peering Provider對(duì)網(wǎng)路的抽象

圖表 13. 集群間網(wǎng)絡(luò)資源信息同步

3、連接到某一集群上的App發(fā)布集群間Intent時(shí)，Multi-Clusters Peering Provider會(huì)通過北向接口安裝Intent，并保存到本地Store中。

圖表 14. 集群間Intent安裝

審核編輯：郭婷