基于P4的CoLoR架構控制平面的設計與實現

劉若涵，羅洪斌，溫興泵

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

1 引言

1.1 背景

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

必須引起重視的是，無論是創新思想的網絡架構還是網絡協議，必須在實際環境中部署，才能在最大程度上對其功能與性能進行檢測[3]，但新協議或網絡架構在現有運營網絡中進行部署和測試是復雜的。CoLoR對互聯網網絡層進行了重新設計，加入了新的字段，隨著研究推進，CoLoR的報頭格式和邏輯在不斷完善、改進。在現有網絡環境中部署測試時，為了支持新的協議字段/報頭，使得協議首部內容不斷增加、標準更加復雜[4]，此外還需要對每個網絡設備進行配置和更新操作。在這種情況下，CoLoR架構的完善與推廣是一個緩慢且極具挑戰性的過程，因為它涉及在網絡中執行新的、非常規的處理邏輯和匹配內容，除了仍然需要解決的算法挑戰，描述一些CoLoR實例顯然缺乏硬件支持。因此，需要一種更靈活的系統實現方法，使CoLoR可以很方便地被部署、測試、調整、升級，這對提高對新協議、新網絡構架的研究效率，加快業界對CoLoR的接納、部署和推廣，是十分必要的。

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

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

P4的“全”可編程性體現在其可重構性、協議無關性和目標獨立性 3個方面[8]，其中協議無關性指的是它不與任意一個特定協議綁定，所有的流規則、流表和執行順序都由控制器制定后下發給交換機。P4的優勢體現在對新的網絡協議與架構進行驗證與測試以及版本的迭代更新，與傳統設備需要重新修改協議棧并進行重新配置相比，這種通過可編程來重新定義交換機的方式大幅度加快了科學研究的進程。

1.2 現狀

參考文獻[9]使用P4編寫NDN（named data networking，數據命名網絡）數據平面，流表通過定義一個軟件API來下發，但是當系統較為復雜、功能模塊種類繁多時，僅僅使用API能否實現智能的流表計算和下發并不能得到保證。

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

ONOS啟動后需要激活對 BMv2的驅動（driver），并開啟默認監聽端口 40123，BMv2啟動時指定該端口并主動請求連接，并告知 ONOS其自身的thrift-port[14]。之后ONOS與BMv2通過兩條TCP連接交互：鏈路1通過40123端口接收BMv2上傳的問詢消息，鏈路2通過thrift接口實現ONOS對BMv2的管控，如配置文件和流表的下發以及通過遠程接口調用控制BMv2構造數據分組以及指定數據分組的出端口等。

具體原理如圖1所示。原始P4文件經過編譯器（p4c-bmv2）轉化為JSON格式的配置文件[15]，轉化器（interpreter）將配置文件轉化成設備描述表（device-context），驅動中建立設備（device）和默認設備描述表之間的映射，之后北向抽象層通過API將配置文件和流表下發，并將網絡視圖提供給應用層。

2 CoLoR架構及其機制

與當前僅使用一個命名空間（即IP地址）的TCP/IP網絡不同，CoLoR使用兩個全局命名空間：SID（server ID，服務標識符）、NID（node ID，節點標識符）和兩個本地命名空間：域內路由定位、PID（path ID，路徑標識符）。

區別于傳統網絡架構以主機為中心的尋址方式，CoLoR貫徹以信息為中心的思想，為網絡中每個服務內容分配唯一的標識符SID，SID僅用于代表某項內容，與其所處位置無關，服務注冊和請求時均依據 SID；NID代表網絡中各節點的位置，用于認證；域內路由定位用于在域內進行路由；PID用于在域間定義路徑，由兩個域協商產生，不全球通告。

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

CoLoR的基本工作機制包括：服務注冊、內容請求與數據分組轉發。一個完整的CoLoR系統的運行流程如圖2所示，為了便于闡述，選擇域D2作為父域，RM2為父域RM，其他域都需向D2通告。

2.1 服務注冊

圖1 ONOS控制P4原理

圖2 CoLoR架構運行流程

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

同理D1中S2也向其RM1發送注冊分組，注冊信息為（SID2、NID2），RM1向RM2進行通告，通告分組內容為（SID2、AS1、PID1）。

2.2 內容請求

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

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

同理，當 C請求 SID2對應的服務時發送get分組（SID2、NIDc），RM1發現 SID2注冊在本域，直接依據注冊信息查找 NID2，將 get分組轉發至S2。

2.3 數據轉發

一旦存儲所需服務的源節點接收到get消息，服務提供者即可得知請求者的 NID、所期望服務的SID以及途經的PID。因此，如圖2中過程?～?所示，D3中S1收到由C發來的get分組后，發送封裝請求者NID、PID和所請求內容DATA的數據分組回送，跨域過程逐級剝去最外層 PID，從BR7經PID2到BR6后剝去外層PID2，從BR3經PID1到BR1后剝去PID1，最后依據NIDc將所需服務轉發至請求者C。

同理D1中S2收到C發送的服務請求分組后，會發送數據分組（DATA、NIDc），經AR1后直接依據NIDc將所需服務轉發至請求者C。

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

而 P4的可編程性通過對交換機可識別的首部字段和處理邏輯進行重新定義，可以以一種十分便捷的方式改變對數據分組的處理方式。用P4實現的CoLoR架構繼承了協議無關的特性，控制器ONOS通過配置文件定義CoLoR分組格式和底層轉發設備BMv2處理CoLoR分組的邏輯，提取解析轉發設備不能識別的分組決策并進行相應的處理，實現CoLoR架構控制平面的功能。

3 用P4編寫CoLoR架構

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

3.1 P4編寫配置文件

（1）首部（header）

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

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

（2）解析器（parser）

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

圖4 P4語言定義的解析器

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

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

圖5 P4定義的匹配動作表

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

圖6給出了P4定義的流控制程序。流控制程序規定了匹配動作表的執行條件和順序。當 RM判斷分組類型為get分組時，進入流表table sid_nid進行匹配轉發。

圖6 P4定義的流控制程序

3.2 變長問題

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

（1）解析器

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

（2）流控制程序

進入流控制程序，滿足條件后進行流表匹配，完成相應動作。RM發現SID在域外時執行action：add_header添加newPid，在域內則依據NID轉發。

（3）逆解析器

將提取出來的各分組頭字段組合，extract和add_header動作操作的首部都會被激活變為valid，之前占位的newPid被激活，故而組合時會增加newPid分組頭。需要注意的是，PID采取倒序的方式插在get消息之后，最新加入的PID添加在所有PID最前邊即firstPid。

3.3 首分組問題

BMv2通過thrift接口向ONOS提供遠程接口調用服務。ONOS為BMv2下發配置文件和具體流表，也可以控制BMv2構造CoLoR分組從特定端口發出。這里以get分組為例，介紹遠程接口調用處理首分組問題。

（1）對于首個到達BMv2的get分組

圖7 解析流程

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

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

由于AR、RM等已經具有轉發邏輯和流表，具有獨立的轉發功能，get分組依據流表直接轉發，無需問詢 ONOS，匹配失敗執行默認動作send_to_cpu。

通過遠程接口調用轉發CoLoR分組時，由于CoLoR分組不再進入 match+action管道，要求ONOS完成下發給這個BMv2流表的所有功能，遠程接口調用只實現了對出端口的指定，但對分組內容的修改，需要ONOS自身完成，這一問題將在第4.3節中進行分析解決。

4 基于P4的CoLoR架構控制平面的實現

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

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

圖8 ONOS的控制平面實現框架

4.1 初始化主模塊

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

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

4.2 接收分組分析模塊

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

4.3 分組頭讀寫模塊

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

（2）分組頭讀寫模塊修改CoLoR分組內容，包括源地址、目的地址和標志位flag等，是為了解決遠程接口調用時的首分組問題。ONOS遠程接口調用指定出端口，但對分組內容的修改，需要分組頭讀寫模塊完成，繼續以get為例，簡要介紹分組頭讀寫模塊對分組內容的修改。

· 修改源地址、目的地址是為了實現CoLoR分組正常轉發：get首分組到達AR后需要將目的地址修改為本域RM的地址，并從相應端口轉發出去。而ONOS通過遠程接口調用為get指定了出端口，但目的地址仍為AR，從正確端口到達IR后，查詢ip_port后由于目的地址有誤最終仍舊無法正常到達RM，因此需要在ONOS中完成對CoLoR分組內容的修改，將目的地址改為本域RM的地址，只有修改過目的地址的get分組才能依據match+action傳遞給RM，其他過程同理，不再細述。

· 設置flag標志位是為了區分CoLoR分組路徑：到達AR的get分組有兩種情況，即從客戶端到RM和從RM到服務器；同樣到達BR的get分組有兩種情況：RM到外域BR和外域BR到RM。標志位flag對分組路徑進行區分，默認從客戶端發出的原始服務請求分組flag=0，經過AR走客戶端→RM路徑；經過RM處理后，改為flag=1；到達本域 BR走 RM→BR路線，同時使flag=0；到達外域BR走BR→RM路線，到達RM再次使flag=1；此時到達AR走RM→服務器路線，完成get路徑區分。

4.4 路徑計算模塊

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

4.5 流規則生成模塊

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

5 結果檢測

為對基于P4的CoLoR架構控制平面進行功能驗證并測試其性能，在實驗室實體機柜上部署了測試拓撲，使用Click[16]路由器模擬發分組。測試拓撲如圖9所示，其中沿PID1、PID2出去的設備PID1、PID2為虛擬主機，用于監控PID鏈路上的分組信息。

5.1 功能檢測

本文選擇一個域 D1為研究對象，通過對從D1發送出去的CoLoR分組和到達D1的CoLoR分組的轉發結果驗證其功能，其他域同理。

（1）注冊分組

圖9 測試拓撲

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

圖10 ONOS1解析域內注冊分組結果

圖11 PID2抓取通告分組結果

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

圖12 ONOS1解析域間通告分組結果

（2）服務請求分組

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

圖13 PID2抓取請求分組結果

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

圖14 server1抓取請求分組結果

（3）數據分組

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

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

圖15 PID2抓取數據分組結果

圖16 client1抓取數據分組結果

5.2 性能測試

（1）ONOS流表下發速率

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

（2）JSON文件切換時延

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

圖17 下發速率隨流表數目變化

圖18 JSON文件切換時延

6 結束語

本文簡要介紹了新網絡架構CoLoR的運行原理，分析了CoLoR架構推廣受到限制的因素，在此基礎上用P4實現CoLoR架構，詳細闡述了基于P4的CoLoR架構控制平面的設計與實現，介紹如何用P4語言定義RM、BR、AR、IR等設備的可以識別的首部字段和處理邏輯以及如何用ONOS控制P4實現CoLoR架構流程，并對其進行功能驗證和性能測試。

然而，圍繞基于 P4實現CoLoR架構，仍然有許多亟待解決的問題。本文重點側重于功能實現，如何在保證系統穩定運行的基礎上提升性能以及配置文件的不中斷切換等，有待進一步實現。

參考文獻：

[1]羅洪斌, 張宏科.智慧協同標識網絡體系：研究背景、思路與進展[J].電信科學, 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的按需智能路由系統研究與驗證[J].電信科學, 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]王曉峰, 吳建平, 崔勇.互聯網 IPv6 過渡技術綜述[J].小型微型計算機系統, 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 環境下的一種內容中心網絡架構及其實現[J].小型微型計算機系統, 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網向SDN演進的探討[J].電信科學, 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.