基于P4的CoLoR架構(gòu)控制平面的設(shè)計(jì)與實(shí)現(xiàn)

劉若涵，羅洪斌，溫興泵

（1.北京交通大學(xué)電子信息工程學(xué)院，北京 100044；2.北京航空航天大學(xué)計(jì)算機(jī)學(xué)院，北京 100083）

1 引言

1.1 背景

隨著現(xiàn)代科技的進(jìn)步，網(wǎng)絡(luò)互聯(lián)帶來的便捷已經(jīng)體現(xiàn)在人類生活的各個(gè)角落，層次化的結(jié)構(gòu)設(shè)計(jì)為互聯(lián)網(wǎng)帶來的成就不勝枚舉。然而不得不引起重視的是，隨著用戶需求的日益多元化和復(fù)雜化，傳統(tǒng)網(wǎng)絡(luò)體系結(jié)構(gòu)在進(jìn)行功能擴(kuò)展時(shí)存在諸多問題：隨著用戶規(guī)模的不斷擴(kuò)大和各種網(wǎng)絡(luò)新應(yīng)用的不斷增加，協(xié)議的更新迭代使得網(wǎng)絡(luò)優(yōu)化的難度增加，同時(shí)各種新型服務(wù)增加了運(yùn)維成本。僅僅在現(xiàn)有網(wǎng)絡(luò)架構(gòu)的基礎(chǔ)上改良已經(jīng)難以解決其根本問題[1]，北京交通大學(xué)下一代互聯(lián)網(wǎng)互聯(lián)設(shè)備國(guó)家工程實(shí)驗(yàn)室提出了以信息為中心的CoLoR[2]新網(wǎng)絡(luò)體系架構(gòu)，旨在通過重新設(shè)計(jì)互聯(lián)網(wǎng)來實(shí)現(xiàn)可擴(kuò)展和高效的內(nèi)容分發(fā)功能。

必須引起重視的是，無論是創(chuàng)新思想的網(wǎng)絡(luò)架構(gòu)還是網(wǎng)絡(luò)協(xié)議，必須在實(shí)際環(huán)境中部署，才能在最大程度上對(duì)其功能與性能進(jìn)行檢測(cè)[3]，但新協(xié)議或網(wǎng)絡(luò)架構(gòu)在現(xiàn)有運(yùn)營(yíng)網(wǎng)絡(luò)中進(jìn)行部署和測(cè)試是復(fù)雜的。CoLoR對(duì)互聯(lián)網(wǎng)網(wǎng)絡(luò)層進(jìn)行了重新設(shè)計(jì)，加入了新的字段，隨著研究推進(jìn)，CoLoR的報(bào)頭格式和邏輯在不斷完善、改進(jìn)。在現(xiàn)有網(wǎng)絡(luò)環(huán)境中部署測(cè)試時(shí)，為了支持新的協(xié)議字段/報(bào)頭，使得協(xié)議首部?jī)?nèi)容不斷增加、標(biāo)準(zhǔn)更加復(fù)雜[4]，此外還需要對(duì)每個(gè)網(wǎng)絡(luò)設(shè)備進(jìn)行配置和更新操作。在這種情況下，CoLoR架構(gòu)的完善與推廣是一個(gè)緩慢且極具挑戰(zhàn)性的過程，因?yàn)樗婕霸诰W(wǎng)絡(luò)中執(zhí)行新的、非常規(guī)的處理邏輯和匹配內(nèi)容，除了仍然需要解決的算法挑戰(zhàn)，描述一些CoLoR實(shí)例顯然缺乏硬件支持。因此，需要一種更靈活的系統(tǒng)實(shí)現(xiàn)方法，使CoLoR可以很方便地被部署、測(cè)試、調(diào)整、升級(jí)，這對(duì)提高對(duì)新協(xié)議、新網(wǎng)絡(luò)構(gòu)架的研究效率，加快業(yè)界對(duì)CoLoR的接納、部署和推廣，是十分必要的。

P4[5]（programming protocol-independent packet processor）作為一種潛在的“OpenFlow2.0”的發(fā)展方向，區(qū)別于現(xiàn)有的OpenFlow通過流表指導(dǎo)固定功能[6]的交換機(jī)轉(zhuǎn)發(fā)數(shù)據(jù)流，P4通過軟件編程的方式重新定義轉(zhuǎn)發(fā)設(shè)備所識(shí)別的字段以及對(duì)數(shù)據(jù)分組的處理流程和邏輯，旨在解決OpenFlow可編程性和可拓展性方面的局限性問題。

P4有其特有的交換機(jī)模擬器BMv2（behavior model version 2），P4的核心思想可以用抽象轉(zhuǎn)發(fā)模型進(jìn)行描述，其中有兩個(gè)主要操作：配置和填充[7]。配置操作完成對(duì)分組處理器的編程，通過JSON格式的配置文件指定每個(gè)階段處理的首部字段，設(shè)置BMv2在match+action[5]階段所要匹配的內(nèi)容和順序，并定義對(duì)應(yīng)動(dòng)作域；填充操作主要是進(jìn)行具體流表?xiàng)l目的添加或刪除。

P4的“全”可編程性體現(xiàn)在其可重構(gòu)性、協(xié)議無關(guān)性和目標(biāo)獨(dú)立性 3個(gè)方面[8]，其中協(xié)議無關(guān)性指的是它不與任意一個(gè)特定協(xié)議綁定，所有的流規(guī)則、流表和執(zhí)行順序都由控制器制定后下發(fā)給交換機(jī)。P4的優(yōu)勢(shì)體現(xiàn)在對(duì)新的網(wǎng)絡(luò)協(xié)議與架構(gòu)進(jìn)行驗(yàn)證與測(cè)試以及版本的迭代更新，與傳統(tǒng)設(shè)備需要重新修改協(xié)議棧并進(jìn)行重新配置相比，這種通過可編程來重新定義交換機(jī)的方式大幅度加快了科學(xué)研究的進(jìn)程。

1.2 現(xiàn)狀

參考文獻(xiàn)[9]使用P4編寫NDN（named data networking，數(shù)據(jù)命名網(wǎng)絡(luò)）數(shù)據(jù)平面，流表通過定義一個(gè)軟件API來下發(fā)，但是當(dāng)系統(tǒng)較為復(fù)雜、功能模塊種類繁多時(shí)，僅僅使用API能否實(shí)現(xiàn)智能的流表計(jì)算和下發(fā)并不能得到保證。

CLI（command-line interface，命令行接口）可以對(duì)BMv2進(jìn)行簡(jiǎn)單流表的下發(fā)。但是一個(gè)CLI只能連接一個(gè) BMv2，不能提供針對(duì)全局網(wǎng)絡(luò)狀態(tài)制定的智能決策。為了實(shí)現(xiàn)新架構(gòu)可編程、自動(dòng)化的網(wǎng)絡(luò)控制能力，需要一個(gè)更高可擴(kuò)展性、更智能的控制平面。ONOS[10,11]是首款開源SDN[12]（software defined networking，軟件定義網(wǎng)絡(luò)）操作系統(tǒng)，參考文獻(xiàn)[13]在對(duì) ONOS的研究中加入了一個(gè)簡(jiǎn)單的針對(duì) BMv2的控制模型，但是對(duì)CoLoR提供的支持仍需完善。ONOS只支持如TCP/IP和以太網(wǎng) Ethernet等現(xiàn)有的協(xié)議，而CoLoR中的各種分組格式需要自行開發(fā)，而且要制定復(fù)雜的網(wǎng)絡(luò)策略、實(shí)現(xiàn)智能的轉(zhuǎn)發(fā)仍有許多問題尚待解決。

ONOS啟動(dòng)后需要激活對(duì) BMv2的驅(qū)動(dòng)（driver），并開啟默認(rèn)監(jiān)聽端口 40123，BMv2啟動(dòng)時(shí)指定該端口并主動(dòng)請(qǐng)求連接，并告知 ONOS其自身的thrift-port[14]。之后ONOS與BMv2通過兩條TCP連接交互：鏈路1通過40123端口接收BMv2上傳的問詢消息，鏈路2通過thrift接口實(shí)現(xiàn)ONOS對(duì)BMv2的管控，如配置文件和流表的下發(fā)以及通過遠(yuǎn)程接口調(diào)用控制BMv2構(gòu)造數(shù)據(jù)分組以及指定數(shù)據(jù)分組的出端口等。

具體原理如圖1所示。原始P4文件經(jīng)過編譯器（p4c-bmv2）轉(zhuǎn)化為JSON格式的配置文件[15]，轉(zhuǎn)化器（interpreter）將配置文件轉(zhuǎn)化成設(shè)備描述表（device-context），驅(qū)動(dòng)中建立設(shè)備（device）和默認(rèn)設(shè)備描述表之間的映射，之后北向抽象層通過API將配置文件和流表下發(fā)，并將網(wǎng)絡(luò)視圖提供給應(yīng)用層。

2 CoLoR架構(gòu)及其機(jī)制

與當(dāng)前僅使用一個(gè)命名空間（即IP地址）的TCP/IP網(wǎng)絡(luò)不同，CoLoR使用兩個(gè)全局命名空間：SID（server ID，服務(wù)標(biāo)識(shí)符）、NID（node ID，節(jié)點(diǎn)標(biāo)識(shí)符）和兩個(gè)本地命名空間：域內(nèi)路由定位、PID（path ID，路徑標(biāo)識(shí)符）。

區(qū)別于傳統(tǒng)網(wǎng)絡(luò)架構(gòu)以主機(jī)為中心的尋址方式，CoLoR貫徹以信息為中心的思想，為網(wǎng)絡(luò)中每個(gè)服務(wù)內(nèi)容分配唯一的標(biāo)識(shí)符SID，SID僅用于代表某項(xiàng)內(nèi)容，與其所處位置無關(guān)，服務(wù)注冊(cè)和請(qǐng)求時(shí)均依據(jù) SID；NID代表網(wǎng)絡(luò)中各節(jié)點(diǎn)的位置，用于認(rèn)證；域內(nèi)路由定位用于在域內(nèi)進(jìn)行路由；PID用于在域間定義路徑，由兩個(gè)域協(xié)商產(chǎn)生，不全球通告。

在CoLoR中，每一個(gè)AS（autonomous system，自治域）中都有一個(gè)RM（resource manager，資源管理器），自治域內(nèi)所有服務(wù)提供方都會(huì)把SID向本域RM進(jìn)行注冊(cè)，故而RM維護(hù)著一個(gè)存放內(nèi)容可達(dá)性信息的注冊(cè)表，用于對(duì)所請(qǐng)求服務(wù)的查詢；BR（border router，邊界路由器）用于連接其他自治域并沿 PID標(biāo)識(shí)路徑轉(zhuǎn)發(fā)CoLoR分組。

CoLoR的基本工作機(jī)制包括：服務(wù)注冊(cè)、內(nèi)容請(qǐng)求與數(shù)據(jù)分組轉(zhuǎn)發(fā)。一個(gè)完整的CoLoR系統(tǒng)的運(yùn)行流程如圖2所示，為了便于闡述，選擇域D2作為父域，RM2為父域RM，其他域都需向D2通告。

2.1 服務(wù)注冊(cè)

圖1 ONOS控制P4原理

圖2 CoLoR架構(gòu)運(yùn)行流程

服務(wù)注冊(cè)包括域內(nèi)注冊(cè)和域間通告兩個(gè)方面，如圖2中過程①～④所示。D3中服務(wù)提供者S1向本域RM3發(fā)送注冊(cè)信息，注冊(cè)內(nèi)容包括其SID和提供者自身NID，RM3收到注冊(cè)分組后，會(huì)在自身的注冊(cè)表里為這一SID添加條目存儲(chǔ)注冊(cè)信息，此即服務(wù)的域內(nèi)注冊(cè)部分；隨后RM3還需選擇域間路徑 PID2向其父域的 RM（D2的RM2）進(jìn)行通告，通告內(nèi)容為 SID、通告方 AS號(hào)和綁定PID，被通告方RM2需添加對(duì)該SID的通告條目，此即域間通告的流程。

同理D1中S2也向其RM1發(fā)送注冊(cè)分組，注冊(cè)信息為（SID2、NID2），RM1向RM2進(jìn)行通告，通告分組內(nèi)容為（SID2、AS1、PID1）。

2.2 內(nèi)容請(qǐng)求

請(qǐng)求者期望獲取某項(xiàng)服務(wù)時(shí)，會(huì)向其本地RM發(fā)送get請(qǐng)求消息。get消息應(yīng)包含請(qǐng)求者所期望的服務(wù)的SID和其自身NID。若RM在注冊(cè)表里找不到SID的條目，會(huì)發(fā)往父域問詢；若SID注冊(cè)在本域，則直接將請(qǐng)求分組轉(zhuǎn)發(fā)至服務(wù)提供者。

如圖2中過程⑤～⑩所示，當(dāng)D1中請(qǐng)求者C期望獲取由SID1標(biāo)識(shí)的服務(wù)時(shí)，會(huì)向其本地RM1發(fā)送 get請(qǐng)求消息；RM1在注冊(cè)表里查詢不到SID1的條目，會(huì)將路徑標(biāo)識(shí)PID1添加到請(qǐng)求分組尾部，并沿該路徑將這一get請(qǐng)求消息轉(zhuǎn)發(fā)至父域RM2；RM2收到get分組后，查詢到本域存儲(chǔ)了由D3通告來的關(guān)于SID1的通告條目，則依據(jù)通告信息將PID2封在get分組尾部，并沿該路徑將請(qǐng)求分組轉(zhuǎn)發(fā)至RM3；RM3查詢SID1條目發(fā)現(xiàn)注冊(cè)在本域內(nèi)，則依據(jù)注冊(cè)信息查找提供者NID（NID1），將get分組轉(zhuǎn)發(fā)至S1。

同理，當(dāng) C請(qǐng)求 SID2對(duì)應(yīng)的服務(wù)時(shí)發(fā)送get分組（SID2、NIDc），RM1發(fā)現(xiàn) SID2注冊(cè)在本域，直接依據(jù)注冊(cè)信息查找 NID2，將 get分組轉(zhuǎn)發(fā)至S2。

2.3 數(shù)據(jù)轉(zhuǎn)發(fā)

一旦存儲(chǔ)所需服務(wù)的源節(jié)點(diǎn)接收到get消息，服務(wù)提供者即可得知請(qǐng)求者的 NID、所期望服務(wù)的SID以及途經(jīng)的PID。因此，如圖2中過程?～?所示，D3中S1收到由C發(fā)來的get分組后，發(fā)送封裝請(qǐng)求者NID、PID和所請(qǐng)求內(nèi)容DATA的數(shù)據(jù)分組回送，跨域過程逐級(jí)剝?nèi)プ钔鈱?PID，從BR7經(jīng)PID2到BR6后剝?nèi)ネ鈱覲ID2，從BR3經(jīng)PID1到BR1后剝?nèi)ID1，最后依據(jù)NIDc將所需服務(wù)轉(zhuǎn)發(fā)至請(qǐng)求者C。

同理D1中S2收到C發(fā)送的服務(wù)請(qǐng)求分組后，會(huì)發(fā)送數(shù)據(jù)分組（DATA、NIDc），經(jīng)AR1后直接依據(jù)NIDc將所需服務(wù)轉(zhuǎn)發(fā)至請(qǐng)求者C。

CoLoR分組頭引入了新的字段如SID、NID、PID等，同時(shí)通過對(duì)CoLoR機(jī)制的分析不難發(fā)現(xiàn)，在服務(wù)請(qǐng)求發(fā)起到請(qǐng)求者接收到數(shù)據(jù)分組的過程中，RM、BR中需要經(jīng)過復(fù)雜的邏輯處理，PID一直處于動(dòng)態(tài)增減的狀態(tài)。在現(xiàn)有網(wǎng)絡(luò)中，新字段的添加需要對(duì)整個(gè)協(xié)議棧進(jìn)行修改，服務(wù)注冊(cè)、請(qǐng)求和數(shù)據(jù)分組轉(zhuǎn)發(fā)也涉及在網(wǎng)絡(luò)層執(zhí)行新的、非常規(guī)的處理邏輯和規(guī)則，需要對(duì)每個(gè)網(wǎng)絡(luò)設(shè)備進(jìn)行配置和更新，以支持新的協(xié)議字段/報(bào)頭。故而CoLoR的完善和推廣受實(shí)際部署的限制。

而 P4的可編程性通過對(duì)交換機(jī)可識(shí)別的首部字段和處理邏輯進(jìn)行重新定義，可以以一種十分便捷的方式改變對(duì)數(shù)據(jù)分組的處理方式。用P4實(shí)現(xiàn)的CoLoR架構(gòu)繼承了協(xié)議無關(guān)的特性，控制器ONOS通過配置文件定義CoLoR分組格式和底層轉(zhuǎn)發(fā)設(shè)備BMv2處理CoLoR分組的邏輯，提取解析轉(zhuǎn)發(fā)設(shè)備不能識(shí)別的分組決策并進(jìn)行相應(yīng)的處理，實(shí)現(xiàn)CoLoR架構(gòu)控制平面的功能。

3 用P4編寫CoLoR架構(gòu)

用P4實(shí)現(xiàn)CoLoR架構(gòu)時(shí)，各域中位于數(shù)據(jù)平面的BMv2設(shè)備（RM、BR、AR、IR等）都僅僅保留其轉(zhuǎn)發(fā)作用，其所能識(shí)別的首部和控制邏輯都由控制平面ONOS制定。ONOS檢測(cè)到BMv2連接時(shí)，通過TCP連接將配置文件以JSON格式下發(fā)，CoLoR分組到達(dá)BMv2后問詢ONOS獲取轉(zhuǎn)發(fā)所需流表，此后BMv2才具有獨(dú)立轉(zhuǎn)發(fā)的能力，后續(xù)CoLoR分組查詢BMv2中的流表匹配后直接進(jìn)行轉(zhuǎn)發(fā)，匹配失敗才會(huì)再次問詢 ONOS。以get分組為例，介紹如何使用P4定義BMv2所能識(shí)別的首部字段和處理邏輯及相關(guān)問題。

3.1 P4編寫配置文件

（1）首部（header）

圖3給出了P4語言定義的get分組頭類型，首部定義了get分組頭各字段及其長(zhǎng)度，這里給出了固定長(zhǎng)度部分，由于跨域過程中會(huì)增刪 PID，PID字段為可變長(zhǎng)度，在第3.2節(jié)中具體討論。每一種首部類型都有對(duì)應(yīng)的首部實(shí)例來存儲(chǔ)具體數(shù)據(jù)[16]。

圖3 P4語言定義的get分組頭類型

（2）解析器（parser）

圖4給出了P4語言定義的解析器，解析器規(guī)定了BMv2可以解析的分組頭和解析順序，在第3.2節(jié)中具體闡述。

圖4 P4語言定義的解析器

（3）匹配動(dòng)作表（table）[17]

圖5給出了RM處理get分組的一條匹配動(dòng)作表：table sid_nid，表中定義了匹配字段、對(duì)應(yīng)動(dòng)作和表容量，RM提取SID進(jìn)行精確匹配，依據(jù)匹配結(jié)果分別執(zhí)行對(duì)應(yīng)的動(dòng)作：若SID在域內(nèi)則修改源地址、目的地址轉(zhuǎn)發(fā)，若SID在域外則添加 PID后轉(zhuǎn)發(fā)，若匹配失敗，會(huì)在 table_miss后執(zhí)行提前設(shè)定的 default_action即 send_to_cpu問詢控制器。

圖5 P4定義的匹配動(dòng)作表

（4）流控制程序（control ingress）

圖6給出了P4定義的流控制程序。流控制程序規(guī)定了匹配動(dòng)作表的執(zhí)行條件和順序。當(dāng) RM判斷分組類型為get分組時(shí)，進(jìn)入流表table sid_nid進(jìn)行匹配轉(zhuǎn)發(fā)。

圖6 P4定義的流控制程序

3.2 變長(zhǎng)問題

解析器提取分組頭并依據(jù)現(xiàn)有分組頭字段判斷接下來解析分組頭的類型，解析的最終結(jié)果是進(jìn)入流控制程序處理數(shù)據(jù)分組。當(dāng)解析器工作時(shí)，會(huì)將當(dāng)前處理的數(shù)據(jù)分組頭字節(jié)的偏移量記錄在首部實(shí)例中，并在狀態(tài)遷移（即調(diào)用另一個(gè)解析器）時(shí)指向分組頭中下一個(gè)待處理的有效字節(jié)[18]?，F(xiàn)以RM處理get過程為例簡(jiǎn)要分析變長(zhǎng)問題，解析流程如圖7所示。

（1）解析器

get分組到來時(shí)首先提取 Ethernet分組頭解析，并依據(jù)etherType字段判斷：0x0800解析IP分組，否則停止解析，進(jìn)入流控制程序處理Ethernet分組；解析完成后偏移至IP分組頭字段，提取IP分組頭，解析并依據(jù)protocol字段判斷接下來解析分組頭類型：0xA0為請(qǐng)求分組，0xA1為數(shù)據(jù)分組，0xA2為注冊(cè)分組，0xA3為通告分組，否則停止解析處理IP分組；之后偏移至get分組頭字段，提取get分組頭，并依據(jù)pid_o字段判斷：pid_o=0xFF則解析newPid字段，0xFF為理論上不可能達(dá)到的值，故解析過程通常不會(huì)提取 newPid，僅用于對(duì) deparser（逆解析）階段的占位，默認(rèn)進(jìn)入下一個(gè)解析for_merge，依據(jù)pid_o進(jìn)行判斷：若為0則結(jié)束解析處理get分組；若不為0代表這個(gè)get分組已經(jīng)跨域，解析firstPid字段，最終會(huì)仍進(jìn)入流控制程序，結(jié)束解析。

（2）流控制程序

進(jìn)入流控制程序，滿足條件后進(jìn)行流表匹配，完成相應(yīng)動(dòng)作。RM發(fā)現(xiàn)SID在域外時(shí)執(zhí)行action：add_header添加newPid，在域內(nèi)則依據(jù)NID轉(zhuǎn)發(fā)。

（3）逆解析器

將提取出來的各分組頭字段組合，extract和add_header動(dòng)作操作的首部都會(huì)被激活變?yōu)関alid，之前占位的newPid被激活，故而組合時(shí)會(huì)增加newPid分組頭。需要注意的是，PID采取倒序的方式插在get消息之后，最新加入的PID添加在所有PID最前邊即firstPid。

3.3 首分組問題

BMv2通過thrift接口向ONOS提供遠(yuǎn)程接口調(diào)用服務(wù)。ONOS為BMv2下發(fā)配置文件和具體流表，也可以控制BMv2構(gòu)造CoLoR分組從特定端口發(fā)出。這里以get分組為例，介紹遠(yuǎn)程接口調(diào)用處理首分組問題。

（1）對(duì)于首個(gè)到達(dá)BMv2的get分組

圖7 解析流程

AR連接到 ONOS后，其初始轉(zhuǎn)發(fā)流表“protocol_dstAddr”為空（發(fā)送給控制器問詢的默認(rèn)流表不計(jì)），get分組到達(dá) AR后進(jìn)入其match+action管道，由于無法正確匹配而table_miss，執(zhí)行默認(rèn)動(dòng)作send_to_cpu，通過TCP連接問詢ONOS，此時(shí)get分組完成match+action過程，離開該管道。ONOS對(duì)請(qǐng)求信息進(jìn)行解析后，計(jì)算AR至RM的路徑并為該鏈路上所有設(shè)備下發(fā)流表。同時(shí)通過遠(yuǎn)程接口調(diào)用，控制 AR生成get分組并直接從其對(duì)應(yīng)端口發(fā)送出去，而不再經(jīng)過AR的match+action管道查詢流表轉(zhuǎn)發(fā)；get在各IR依據(jù)下發(fā)的流表匹配轉(zhuǎn)發(fā)；到達(dá)RM時(shí)，RM轉(zhuǎn)發(fā)流表為空，問詢ONOS，下發(fā)“sid_nid”流表并通過遠(yuǎn)程接口調(diào)用發(fā)送get分組。

（2）對(duì)于之后到來的get分組

由于AR、RM等已經(jīng)具有轉(zhuǎn)發(fā)邏輯和流表，具有獨(dú)立的轉(zhuǎn)發(fā)功能，get分組依據(jù)流表直接轉(zhuǎn)發(fā)，無需問詢 ONOS，匹配失敗執(zhí)行默認(rèn)動(dòng)作send_to_cpu。

通過遠(yuǎn)程接口調(diào)用轉(zhuǎn)發(fā)CoLoR分組時(shí)，由于CoLoR分組不再進(jìn)入 match+action管道，要求ONOS完成下發(fā)給這個(gè)BMv2流表的所有功能，遠(yuǎn)程接口調(diào)用只實(shí)現(xiàn)了對(duì)出端口的指定，但對(duì)分組內(nèi)容的修改，需要ONOS自身完成，這一問題將在第4.3節(jié)中進(jìn)行分析解決。

4 基于P4的CoLoR架構(gòu)控制平面的實(shí)現(xiàn)

圖8給出了ONOS的控制平面實(shí)現(xiàn)框架。實(shí)現(xiàn)的過程中涉及多個(gè) ONOS提供的服務(wù)：其中deviceService用于控制BMv2切換JSON文件和查詢流表信息等；flowService實(shí)現(xiàn)對(duì)流表從selector+treatment[19]到 match+action的轉(zhuǎn)換和持久化下發(fā)等；packetService接收來自BMv2的各種分組。

CoLoR初始化主模塊接收BMv2提交的包含CoLoR信息的TCP分組，接收分組分析模塊解析CoLoR分組的來源以及分組類型，進(jìn)行分流使之進(jìn)入相應(yīng)的處理過程：這些處理方法中調(diào)用了流規(guī)則生成模塊定義的流規(guī)則，具體的匹配參數(shù)由分組頭讀寫模塊提取解析得到，并依路徑計(jì)算模塊選路結(jié)果為其傳入流表的具體動(dòng)作參數(shù)，應(yīng)用流表對(duì)CoLoR分組進(jìn)行相應(yīng)處理。需要注意的是，其中首分組運(yùn)用分組頭讀寫模塊修改分組相應(yīng)字段的內(nèi)容，并通過遠(yuǎn)程接口調(diào)用傳送分組。之后到來的CoLoR分組到達(dá)RM、BR等設(shè)備時(shí)，由于已經(jīng)下發(fā)配置文件和流表，可以直接查詢流表，匹配成功直接轉(zhuǎn)發(fā)無需問詢 ONOS，匹配失敗才會(huì)執(zhí)行默認(rèn)動(dòng)作send_to_cpu。

圖8 ONOS的控制平面實(shí)現(xiàn)框架

4.1 初始化主模塊

CoLoR初始化主模塊為ONOS進(jìn)行分組處理的主模塊，主要實(shí)現(xiàn)的功能有與BMv2建立連接、接收含有CoLoR信息的TCP分組以及控制流表下發(fā)。

本文中流表下發(fā)模式設(shè)計(jì)為主動(dòng)與被動(dòng)結(jié)合。ONOS檢測(cè)到BMv2連接時(shí)就要主動(dòng)下發(fā)一些特定的默認(rèn)控制流表（如丟棄報(bào)文、對(duì)下一張流表進(jìn)行匹配、轉(zhuǎn)發(fā)給控制器等），其余流表當(dāng)BMv2問詢時(shí)，依據(jù)對(duì)CoLoR信息解析后生成，通過TCP連接下發(fā)。被動(dòng)模式的好處是當(dāng)規(guī)模擴(kuò)大時(shí)，BMv2無需時(shí)刻維護(hù)全部的流表，只有當(dāng)產(chǎn)生實(shí)際流量時(shí)才向ONOS獲取流表并存儲(chǔ)。且每條流表都設(shè)有定時(shí)器，超時(shí)后刪除，故而在很大程度上節(jié)省存儲(chǔ)空間。

4.2 接收分組分析模塊

接收分組分析模塊對(duì)到來的CoLoR分組進(jìn)行分流。ONOS對(duì)CoLoR分組進(jìn)行初步解析，獲得發(fā)送端BMv2的設(shè)備信息（如deviceID、deviceName等）和CoLoR分組類型信息（versionType），并據(jù)此分流，將CoLoR分組送到對(duì)應(yīng)的分組處理函數(shù)，理論上所有的BMv2設(shè)備（RM、AR、BR等）都應(yīng)實(shí)現(xiàn)對(duì)注冊(cè)分組、通告分組、請(qǐng)求分組、數(shù)據(jù)分組的處理邏輯。

4.3 分組頭讀寫模塊

（1）分組頭讀寫模塊解析CoLoR分組，為流規(guī)則生成模塊提供匹配參數(shù)，具體解析CoLoR分組信息如SID、NID、PID和versionType等字段，可作為路徑計(jì)算的源、目的地址依據(jù)或者作為流控制程序中流表執(zhí)行的判斷依據(jù)。

（2）分組頭讀寫模塊修改CoLoR分組內(nèi)容，包括源地址、目的地址和標(biāo)志位flag等，是為了解決遠(yuǎn)程接口調(diào)用時(shí)的首分組問題。ONOS遠(yuǎn)程接口調(diào)用指定出端口，但對(duì)分組內(nèi)容的修改，需要分組頭讀寫模塊完成，繼續(xù)以get為例，簡(jiǎn)要介紹分組頭讀寫模塊對(duì)分組內(nèi)容的修改。

· 修改源地址、目的地址是為了實(shí)現(xiàn)CoLoR分組正常轉(zhuǎn)發(fā)：get首分組到達(dá)AR后需要將目的地址修改為本域RM的地址，并從相應(yīng)端口轉(zhuǎn)發(fā)出去。而ONOS通過遠(yuǎn)程接口調(diào)用為get指定了出端口，但目的地址仍為AR，從正確端口到達(dá)IR后，查詢ip_port后由于目的地址有誤最終仍舊無法正常到達(dá)RM，因此需要在ONOS中完成對(duì)CoLoR分組內(nèi)容的修改，將目的地址改為本域RM的地址，只有修改過目的地址的get分組才能依據(jù)match+action傳遞給RM，其他過程同理，不再細(xì)述。

· 設(shè)置flag標(biāo)志位是為了區(qū)分CoLoR分組路徑：到達(dá)AR的get分組有兩種情況，即從客戶端到RM和從RM到服務(wù)器；同樣到達(dá)BR的get分組有兩種情況：RM到外域BR和外域BR到RM。標(biāo)志位flag對(duì)分組路徑進(jìn)行區(qū)分，默認(rèn)從客戶端發(fā)出的原始服務(wù)請(qǐng)求分組flag=0，經(jīng)過AR走客戶端→RM路徑；經(jīng)過RM處理后，改為flag=1；到達(dá)本域 BR走 RM→BR路線，同時(shí)使flag=0；到達(dá)外域BR走BR→RM路線，到達(dá)RM再次使flag=1；此時(shí)到達(dá)AR走RM→服務(wù)器路線，完成get路徑區(qū)分。

4.4 路徑計(jì)算模塊

路徑計(jì)算模塊用于計(jì)算路徑，為流規(guī)則生成模塊提供動(dòng)作域參數(shù)。讀取配置文件的鏈路信息和設(shè)備映射信息，提取并解析CoLoR分組的源、目的信息，計(jì)算以向ONOS發(fā)送問詢的BMv2為根生成的最短路徑樹，并選取到目的路徑的這條，得到所需路徑信息（包括經(jīng)過的設(shè)備以及該設(shè)備的出端口），將端口信息作為流表動(dòng)作域參數(shù)發(fā)送給對(duì)應(yīng)設(shè)備。

4.5 流規(guī)則生成模塊

流規(guī)則生成模塊是具體的流規(guī)則制定模塊。流規(guī)則的組成部分可以劃分為selector、treatment、forTable、deviceID和JSON[20]。其中selector部分用于條件匹配，包括匹配類型和匹配字段；treatment部分用于匹配達(dá)成后相應(yīng)動(dòng)作的執(zhí)行；deviceID確定流條目所對(duì)應(yīng)的設(shè)備；forTable用于指定流條目對(duì)應(yīng)JSON文件中的流表項(xiàng)；JSON用于將默認(rèn)配置文件與BMv2當(dāng)前文件對(duì)應(yīng)，定期檢測(cè)，發(fā)現(xiàn)不同后迅速切換。

5 結(jié)果檢測(cè)

為對(duì)基于P4的CoLoR架構(gòu)控制平面進(jìn)行功能驗(yàn)證并測(cè)試其性能，在實(shí)驗(yàn)室實(shí)體機(jī)柜上部署了測(cè)試拓?fù)?，使用Click[16]路由器模擬發(fā)分組。測(cè)試拓?fù)淙鐖D9所示，其中沿PID1、PID2出去的設(shè)備PID1、PID2為虛擬主機(jī)，用于監(jiān)控PID鏈路上的分組信息。

5.1 功能檢測(cè)

本文選擇一個(gè)域 D1為研究對(duì)象，通過對(duì)從D1發(fā)送出去的CoLoR分組和到達(dá)D1的CoLoR分組的轉(zhuǎn)發(fā)結(jié)果驗(yàn)證其功能，其他域同理。

（1）注冊(cè)分組

圖9 測(cè)試拓?fù)?/p>

本域通告給外域：D1中的server1發(fā)送注冊(cè)分組，注冊(cè)信息為“inside”（36 byte，其余部分用“__”補(bǔ)全，均省略，下同）。圖10給出了 ONOS1收到域內(nèi)注冊(cè)分組提取出的相關(guān)內(nèi)容，由versionType=0xA2判斷這是注冊(cè)分組，解析并保存注冊(cè)信息：SID=“inside”，NID=“server1”。D1內(nèi)注冊(cè)信息需向D2通告，對(duì)沿路徑 PID2出去的虛擬設(shè)備 PID2進(jìn)行抓取分組，結(jié)果如圖 11所示，由 versionType=0xA3可知這是通告分組，通告信息：SID=“inside”，PID=“PID2”。

圖10 ONOS1解析域內(nèi)注冊(cè)分組結(jié)果

圖11 PID2抓取通告分組結(jié)果

外域通告給本域：D2沿PID2向D1通告，ONOS1解析通告分組結(jié)果如圖 12所示，由versionType=0xA3判斷這是通告分組，通告信息：SID=“outside”，PID=“PID2”。

圖12 ONOS1解析域間通告分組結(jié)果

（2）服務(wù)請(qǐng)求分組

本域請(qǐng)求外域：D1中 client1請(qǐng)求 SID為“outside”的服務(wù)時(shí)，發(fā)送get分組沿PID2轉(zhuǎn)發(fā)至外域。圖13給出了對(duì)PID2抓取分組得到的結(jié)果，versionType=0xA0表示這是一個(gè)get分組，請(qǐng)求信息為：SID=“outside”，NIDc=“client1”，PID=“PID2”。

圖13 PID2抓取請(qǐng)求分組結(jié)果

外域請(qǐng)求本域：外域client1請(qǐng)求D1中SID為“inside”的內(nèi)容時(shí)，server1收到CoLoR分組，圖 14給出了對(duì)其抓取分組的結(jié)果，versionType=0xA0表示為get分組，請(qǐng)求信息為：SID=“inside”，NIDc=“client1”，PID=“PIDX”，這是外域get分組跨域到達(dá)本域時(shí)所添加的PID。

圖14 server1抓取請(qǐng)求分組結(jié)果

（3）數(shù)據(jù)分組

本域轉(zhuǎn)發(fā)至外域：D1中server1經(jīng)PID2收到get分組后回送數(shù)據(jù)分組。圖15給出了PID2進(jìn)行抓取分組的結(jié)果，versionType=0xA1表示這是一個(gè)data分組，內(nèi)容為：所請(qǐng)求內(nèi)容和NIDc=“client1”，data分組依據(jù)最后一次添加的 PID（PID2）跨域轉(zhuǎn)發(fā)后刪掉這一PID，故而此時(shí)看不到這一PID字段。

外域轉(zhuǎn)發(fā)至本域：外域收到D1中client1發(fā)送的get分組后回送數(shù)據(jù)，圖16對(duì) client1進(jìn)行wireshark抓取分組，versionType=0xA1表示這是一個(gè)data分組，內(nèi)容為：所請(qǐng)求內(nèi)容和NIDc=“client1”，因?yàn)閜id_o=0，表示請(qǐng)求者在本域，直接依據(jù)NIDc將data分組轉(zhuǎn)至client1。

圖15 PID2抓取數(shù)據(jù)分組結(jié)果

圖16 client1抓取數(shù)據(jù)分組結(jié)果

5.2 性能測(cè)試

（1）ONOS流表下發(fā)速率

ONOS通過thrift端口對(duì)BMv2下發(fā)流表，其流表的下發(fā)性能標(biāo)志著ONOS對(duì)BMv2的控制能力。測(cè)試中ONOS和BMv2分別部署在兩臺(tái)物理機(jī)上，并通過普通的二層交換機(jī)建立TCP連接，測(cè)試流表分為兩種：規(guī)模較小的流表“ip_port”匹配域和動(dòng)作域種類少，字段長(zhǎng)度為5 byte，信息量較少；規(guī)模較大的流表“sid_nid”匹配域和動(dòng)作域種類多，字段長(zhǎng)度為65 byte，信息量較多。如圖17所示，測(cè)試結(jié)果表明，ONOS對(duì)BMv2流表下發(fā)的平均性能大致在 750條/s（約每 1.3 ms添加一條流表），而且流表規(guī)模較小時(shí)性能更穩(wěn)定，隨著流表?xiàng)l目增加，性能下降較為緩慢。在測(cè)試過程中同時(shí)發(fā)現(xiàn)，當(dāng)ONOS在下發(fā)流表總數(shù)達(dá)到13萬時(shí)到達(dá)瓶頸，下發(fā)速率趨近于零，無法完成測(cè)試。ONOS下發(fā)流表后，同時(shí)自己緩存了一份相同的流表并定期下發(fā)，用于BMv2斷開重連后的流表恢復(fù)，下發(fā)總流表數(shù)目越多，ONOS需要緩存的流表數(shù)越多，因此導(dǎo)致性能到達(dá)瓶頸后急劇下降。因此在CoLoR中的SID的映射轉(zhuǎn)發(fā)表不能全部存儲(chǔ)到BMv2中，過期的SID條目會(huì)被BMv2和ONOS移除，get分組匹配失敗后向ONOS詢問該流表即可。

（2）JSON文件切換時(shí)延

ONOS切換 JSON文件有兩種情況：一是BMv2設(shè)備中的 JSON文件出現(xiàn)異常如重啟時(shí)，ONOS定時(shí)檢測(cè)，發(fā)現(xiàn)其與默認(rèn)文件不匹配時(shí)切換；二是CoLoR版本迭代更新時(shí)ONOS主動(dòng)更新默認(rèn)配置文件。JSON文件切換的過程會(huì)不可避免地出現(xiàn)丟失分組從而導(dǎo)致服務(wù)中斷，JSON文件切換時(shí)延越短越好，如圖18所示。測(cè)試結(jié)果表明，JSON文件的切換時(shí)延與大小的關(guān)系為正相關(guān)，如本次測(cè)試對(duì)象為AR、RM、IR、BR 4種設(shè)備對(duì)應(yīng)的JSON文件，其中BR處理邏輯最為復(fù)雜，JSON文件最大為59.1 KB，切換時(shí)延為4.648 ms。

圖17 下發(fā)速率隨流表數(shù)目變化

圖18 JSON文件切換時(shí)延

6 結(jié)束語

本文簡(jiǎn)要介紹了新網(wǎng)絡(luò)架構(gòu)CoLoR的運(yùn)行原理，分析了CoLoR架構(gòu)推廣受到限制的因素，在此基礎(chǔ)上用P4實(shí)現(xiàn)CoLoR架構(gòu)，詳細(xì)闡述了基于P4的CoLoR架構(gòu)控制平面的設(shè)計(jì)與實(shí)現(xiàn)，介紹如何用P4語言定義RM、BR、AR、IR等設(shè)備的可以識(shí)別的首部字段和處理邏輯以及如何用ONOS控制P4實(shí)現(xiàn)CoLoR架構(gòu)流程，并對(duì)其進(jìn)行功能驗(yàn)證和性能測(cè)試。

然而，圍繞基于 P4實(shí)現(xiàn)CoLoR架構(gòu)，仍然有許多亟待解決的問題。本文重點(diǎn)側(cè)重于功能實(shí)現(xiàn)，如何在保證系統(tǒng)穩(wěn)定運(yùn)行的基礎(chǔ)上提升性能以及配置文件的不中斷切換等，有待進(jìn)一步實(shí)現(xiàn)。

參考文獻(xiàn)：

[1]羅洪斌, 張宏科.智慧協(xié)同標(biāo)識(shí)網(wǎng)絡(luò)體系：研究背景、思路與進(jìn)展[J].電信科學(xué), 2015, 31(2)： 11-21.LUO H B, ZHANG H K.Smart and cooperative networks：background, basic ideas and progress[J].Telecommunications Science, 2015, 31(2)： 11-21.

[2]LUO H, CHEN Z, CUI J, et al.CoLoR： an information-centric internet architecture for innovations[J].IEEE Network, 2014,28(3)： 4-10.

[3]王歆平, 王茜, 劉恩慧, 等.基于 SDN的按需智能路由系統(tǒng)研究與驗(yàn)證[J].電信科學(xué), 2014, 30(4)： 8-14.WANG X P, WANG Q, LIU E H, et al.Research and verification on SDN-based on-demand smart routing system [J].Telecommunications Science, 2014, 30(4)： 8-14.

[4]王曉峰, 吳建平, 崔勇.互聯(lián)網(wǎng) IPv6 過渡技術(shù)綜述[J].小型微型計(jì)算機(jī)系統(tǒng), 2006, 27(3)： 385-395.WANG X F, WU J P, CUI Y.Survey of internet IPv6 transition technologies[J].Journal of Chinese Computer Systems, 2006,27(3)： 385-395.

[5]BOSSHART P, IZZARD M, IZZARD M, et al.P4： programming protocol-independent packet processors[J].ACM SIGCOMM Computer Communication Review, 2014, 44(3)：87-95.

[6]王振法, 王雷, 高翔宇, 等.POF 環(huán)境下的一種內(nèi)容中心網(wǎng)絡(luò)架構(gòu)及其實(shí)現(xiàn)[J].小型微型計(jì)算機(jī)系統(tǒng), 2016, 37(9)：1959-1963.WANG Z F, WANG L, GAO X Y, et al.Architecture and implementation of content-centric networking under POF environment[J].Journal of Chinese Computer Systems, 2016, 37(9)：1959-1963.

[7]Behavioral-model[EB].2016.

[8]p4language[EB].2017.

[9]SIGNORELLO S, STATE R, FRAN?OIS J, et al.NDN.p4：programming information-centric data-planes[C]//Netsoft Conference and Workshops, June 10, 2016, Seoul, Korea.Piscataway： IEEE Press, 2016： 384-389.

[10]What is ONOS?[EB].2015.

[11]VOELLMY A, WANG J.Scalable software defined network controllers[J].ACM SIGCOMM Computer Communication Review, 2012, 42(4)： 289-290.

[12]何曉明, 冀暉, 毛東峰, 等.電信IP網(wǎng)向SDN演進(jìn)的探討[J].電信科學(xué), 2014, 30(6)： 131-137.HE X M, JI H, MAO D F, et al.Discussion of evolution of carrier IP network to SDN [J].Telecommunications Science, 2014,30(6)： 131-137.

[13]P4 experimental support via BMv2[EB].2018.

[14]BERDE P, GEROLA M, HART J, et al.ONOS： towards an open, distributed SDN OS[C]//The Workshop on Hot Topics in Software Defined Networking, August 22, 2014, Chicago, IL,USA.New York： ACM Press, 2014： 1-6.

[15]The P4 language specification, version 1.1.0-release candidate[EB].2018.

[16]P4 status update： where are we now and what’s next?[EB].2017.

[17]BOSSHART P, GIBB G, KIM H S, et al.Forwarding metamorphosis： fast programmable match-action processing in hardware for SDN[J].ACM SIGCOMM Computer Communication Review, 2013, 43(4)： 99-110.

[18]Openstate.p4： supporting stateful forwarding in P4[EB].2018.

[19]HAN Y, RYU S, SUH Y J, et al.Design and implementation of LISP controller in ONOS[C]//Netsoft Conference and Work-shops, June 10, 2016, Seoul, Korea.Piscataway： IEEE Press,2016： 417-422.

[20]PARULKAR G, TOFIGH T, LEENHEER M D.SDN control of packet over optical networks[C]//Optical Fiber Communications Conference and Exhibition, March 22-26, 2015, Los Angeles,CA, USA.Piscataway： IEEE Press, 2015： W1G.4.

[21]KOHLER E.The click modular router[M].New York： ACM Press, 2001.