劉若涵，羅洪斌，溫興泵

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

1 引言

1.1 背景

隨著現(xiàn)代科技的進(jìn)步，網(wǎng)絡(luò)互聯(lián)帶來的便捷已經(jīng)體現(xiàn)在人類生活的各個角落，層次化的結(jié)構(gòu)設(shè)計為互聯(lián)網(wǎng)帶來的成就不勝枚舉。然而不得不引起重視的是，隨著用戶需求的日益多元化和復(fù)雜化，傳統(tǒng)網(wǎng)絡(luò)體系結(jié)構(gòu)在進(jìn)行功能擴(kuò)展時存在諸多問題：隨著用戶規(guī)模的不斷擴(kuò)大和各種網(wǎng)絡(luò)新應(yīng)用的不斷增加，協(xié)議的更新迭代使得網(wǎng)絡(luò)優(yōu)化的難度增加，同時各種新型服務(wù)增加了運(yùn)維成本。僅僅在現(xiàn)有網(wǎng)絡(luò)架構(gòu)的基礎(chǔ)上改良已經(jīng)難以解決其根本問題[1]，北京交通大學(xué)下一代互聯(lián)網(wǎng)互聯(lián)設(shè)備國家工程實(shí)驗室提出了以信息為中心的CoLoR[2]新網(wǎng)絡(luò)體系架構(gòu)，旨在通過重新設(shè)計互聯(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)境中部署，才能在最大程度上對其功能與性能進(jìn)行檢測[3]，但新協(xié)議或網(wǎng)絡(luò)架構(gòu)在現(xiàn)有運(yùn)營網(wǎng)絡(luò)中進(jìn)行部署和測試是復(fù)雜的。CoLoR對互聯(lián)網(wǎng)網(wǎng)絡(luò)層進(jìn)行了重新設(shè)計，加入了新的字段，隨著研究推進(jìn)，CoLoR的報頭格式和邏輯在不斷完善、改進(jìn)。在現(xiàn)有網(wǎng)絡(luò)環(huán)境中部署測試時，為了支持新的協(xié)議字段/報頭，使得協(xié)議首部內(nèi)容不斷增加、標(biāo)準(zhǔn)更加復(fù)雜[4]，此外還需要對每個網(wǎng)絡(luò)設(shè)備進(jìn)行配置和更新操作。在這種情況下，CoLoR架構(gòu)的完善與推廣是一個緩慢且極具挑戰(zhàn)性的過程，因為它涉及在網(wǎng)絡(luò)中執(zhí)行新的、非常規(guī)的處理邏輯和匹配內(nèi)容，除了仍然需要解決的算法挑戰(zhàn)，描述一些CoLoR實(shí)例顯然缺乏硬件支持。因此，需要一種更靈活的系統(tǒng)實(shí)現(xiàn)方法，使CoLoR可以很方便地被部署、測試、調(diào)整、升級，這對提高對新協(xié)議、新網(wǎng)絡(luò)構(gòu)架的研究效率，加快業(yè)界對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ù)據(jù)分組的處理流程和邏輯，旨在解決OpenFlow可編程性和可拓展性方面的局限性問題。

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

P4的“全”可編程性體現(xiàn)在其可重構(gòu)性、協(xié)議無關(guān)性和目標(biāo)獨(dú)立性 3個方面[8]，其中協(xié)議無關(guān)性指的是它不與任意一個特定協(xié)議綁定，所有的流規(guī)則、流表和執(zhí)行順序都由控制器制定后下發(fā)給交換機(jī)。P4的優(yōu)勢體現(xiàn)在對新的網(wǎng)絡(luò)協(xié)議與架構(gòu)進(jìn)行驗證與測試以及版本的迭代更新，與傳統(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ù)平面，流表通過定義一個軟件API來下發(fā)，但是當(dāng)系統(tǒng)較為復(fù)雜、功能模塊種類繁多時，僅僅使用API能否實(shí)現(xiàn)智能的流表計算和下發(fā)并不能得到保證。

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

ONOS啟動后需要激活對 BMv2的驅(qū)動（driver），并開啟默認(rèn)監(jiān)聽端口 40123，BMv2啟動時指定該端口并主動請求連接，并告知 ONOS其自身的thrift-port[14]。之后ONOS與BMv2通過兩條TCP連接交互：鏈路1通過40123端口接收BMv2上傳的問詢消息，鏈路2通過thrift接口實(shí)現(xiàn)ONOS對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ū)動中建立設(shè)備（device）和默認(rèn)設(shè)備描述表之間的映射，之后北向抽象層通過API將配置文件和流表下發(fā)，并將網(wǎng)絡(luò)視圖提供給應(yīng)用層。

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

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

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

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

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

2.1 服務(wù)注冊

圖1 ONOS控制P4原理

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

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

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

2.2 內(nèi)容請求

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

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

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

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

一旦存儲所需服務(wù)的源節(jié)點(diǎn)接收到get消息，服務(wù)提供者即可得知請求者的 NID、所期望服務(wù)的SID以及途經(jīng)的PID。因此，如圖2中過程?～?所示，D3中S1收到由C發(fā)來的get分組后，發(fā)送封裝請求者NID、PID和所請求內(nèi)容DATA的數(shù)據(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ā)至請求者C。

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

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

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

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

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

3.1 P4編寫配置文件

（1）首部（header）

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

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

（2）解析器（parser）

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

圖4 P4語言定義的解析器

（3）匹配動作表（table）[17]

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

圖5 P4定義的匹配動作表

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

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

圖6 P4定義的流控制程序

3.2 變長問題

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

（1）解析器

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

（2）流控制程序

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

（3）逆解析器

將提取出來的各分組頭字段組合，extract和add_header動作操作的首部都會被激活變?yōu)関alid，之前占位的newPid被激活，故而組合時會增加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）對于首個到達(dá)BMv2的get分組

圖7 解析流程

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

（2）對于之后到來的get分組

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

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

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

圖8給出了ONOS的控制平面實(shí)現(xiàn)框架。實(shí)現(xiàn)的過程中涉及多個 ONOS提供的服務(wù)：其中deviceService用于控制BMv2切換JSON文件和查詢流表信息等；flowService實(shí)現(xiàn)對流表從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ù)由分組頭讀寫模塊提取解析得到，并依路徑計算模塊選路結(jié)果為其傳入流表的具體動作參數(shù)，應(yīng)用流表對CoLoR分組進(jìn)行相應(yīng)處理。需要注意的是，其中首分組運(yùn)用分組頭讀寫模塊修改分組相應(yīng)字段的內(nèi)容，并通過遠(yuǎn)程接口調(diào)用傳送分組。之后到來的CoLoR分組到達(dá)RM、BR等設(shè)備時，由于已經(jīng)下發(fā)配置文件和流表，可以直接查詢流表，匹配成功直接轉(zhuǎn)發(fā)無需問詢 ONOS，匹配失敗才會執(zhí)行默認(rèn)動作send_to_cpu。

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

4.1 初始化主模塊

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

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

4.2 接收分組分析模塊

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

4.3 分組頭讀寫模塊

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

（2）分組頭讀寫模塊修改CoLoR分組內(nèi)容，包括源地址、目的地址和標(biāo)志位flag等，是為了解決遠(yuǎn)程接口調(diào)用時的首分組問題。ONOS遠(yuǎn)程接口調(diào)用指定出端口，但對分組內(nèi)容的修改，需要分組頭讀寫模塊完成，繼續(xù)以get為例，簡要介紹分組頭讀寫模塊對分組內(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中完成對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對分組路徑進(jìn)行區(qū)分，默認(rèn)從客戶端發(fā)出的原始服務(wù)請求分組flag=0，經(jīng)過AR走客戶端→RM路徑；經(jīng)過RM處理后，改為flag=1；到達(dá)本域 BR走 RM→BR路線，同時使flag=0；到達(dá)外域BR走BR→RM路線，到達(dá)RM再次使flag=1；此時到達(dá)AR走RM→服務(wù)器路線，完成get路徑區(qū)分。

4.4 路徑計算模塊

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

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

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

5 結(jié)果檢測

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

5.1 功能檢測

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

（1）注冊分組

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.2 性能測試

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

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

（2）JSON文件切換時延

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

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

圖18 JSON文件切換時延

6 結(jié)束語

本文簡要介紹了新網(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è)計與實(shí)現(xiàn)，介紹如何用P4語言定義RM、BR、AR、IR等設(shè)備的可以識別的首部字段和處理邏輯以及如何用ONOS控制P4實(shí)現(xiàn)CoLoR架構(gòu)流程，并對其進(jìn)行功能驗證和性能測試。

然而，圍繞基于 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)識網(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)研究與驗證[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ī)系統(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ī)系統(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.