編寫協(xié)議無關包處理器

P4：編寫協(xié)議無關的包處P4:ProgrammingProtocol-IndependentPacket北郵–作，比如OpenFlow。在OpenFlow當前的協(xié)議形態(tài)中，它精確地指定了供它操作的協(xié)議頭。這個協(xié)議頭集合已經(jīng)在短短的幾年時間中，從12個域增長到了41個域，這同時也在這篇中P4作為一個展示了OpenFlow在未來應該如何演進的草案協(xié)議我們以下將會以如何使用P4配置交換機來添加一個新的分層次的為例，講解第一章介無關的接口（OpenFlow。這一點也使得一個控制平面能夠控制來自不同硬件和軟件1-1OpenFlow標準支持的匹配OpenFlow接口一開始很簡單，只抽象了單個規(guī)則表，并且表中只能在數(shù)據(jù)包特定的十二個首部區(qū)域上進行匹配（MAC地址、IP地址、載荷協(xié)議類型、TCP/UDP1，歸結(jié)起來出它們的能力營者越來越想要使用新的包封裝形式（NVGRE、VXLAN和STT，他們采取部署OpenFlow的協(xié)議標準，我們認為未來的交換機應該為包解析和首部域匹配支持靈的“OpenFlow2.0”接口OpenFlow1.x標準，上述這樣一個通用的可擴近段時間的設計方案表明，這樣的靈活性可以在定制的ASIC上實現(xiàn)太比特級的速率[1,2,3]。編寫這種新一代的交換是非常不容易的。每一個有其自身的低級1-1展示了P4和已有的協(xié)議接口之間的關系。P4用來配置交換機。告訴它們應該如何處理數(shù)據(jù)包。已有的協(xié)議接口（例如OpenFlow）負責將轉(zhuǎn)送入固定功能的交換機。P4為編程控制網(wǎng)絡提升了抽象等級，作為一個控制器與交換機之間的普通接口進行工作。換言之，我們相信未來幾代的OpenFlow協(xié)議應該允許控制器1-1P4–目標無關性：正如C開發(fā)者不需要知道底層具體是什么CPU在工作一樣，控P4P4P4程序是如何指定首部、包解析器、多個“匹配-動作”表和多個表之間的控制流程的。最后，我們討論P4編譯器如何將P4程序到目標交換機上。其他相關研究。2011年，Yadavetal.4]OpenFlow提出了一種抽象轉(zhuǎn)發(fā)模型，但沒有強調(diào)編譯器這一角色。[1]提出了可編程包解析的概念。最近，Song[5]提（POF，NP（TTP近期有關NOSIX[7]的一些工作也參考了我們“匹配–轉(zhuǎn) 、擁塞控制和隊列管理[8,9]。模塊化的路由器Click[10]支持軟件層面靈活的包處理，但沒法將這些處理程序到大量的目標硬件交換設備上。第二章抽象的轉(zhuǎn)發(fā)模型1“匹配–執(zhí)行動作”的流程組合轉(zhuǎn)發(fā)數(shù)據(jù)包，其中“匹配–執(zhí)行動作”的過程可以是串行的、并行的或者是二者結(jié)合的。源于對OpenFlow的探索，我們的模型包含了三個一般化。首先，OpenFlow假設有一個固定的包解析器，在這一點上我們的模型能夠支器、路由器）被不同的技術（例如固定功能的ASIC交換、NPU、可重配置的交換的軟件交換機到最快速的基于ASIC的交換機。–執(zhí)行動作”各階段的順序，指定了每個階段要處理的協(xié)議首部區(qū)域。配置操作決定了動作”表中，或從其中移除。其中，表本身是在配置操作的時候指定好的。下顯而易見，配置階段對于固定功能的AIC來說是沒有意義的；對于這類交換機，4編譯器的工作是簡單地檢查是否能夠支持4程序。相反地，正如2,3中所描述，提取出來的首部區(qū)域接下來會被傳遞到“匹配–動作”表。這個表被分為表和出口表兩部分。雖然兩個表都可能會修改包首部，但是的“匹配–動作”決定或觸發(fā)流量控制。出口的“匹配–動作”在包首部上為每一個動作目標單獨做一輪修2-1a同成包。一入端傳的排隊策略的處理方式同當前OpenFlow的一樣：通過一個動作將一個數(shù)據(jù)包到DRR輪詢）的選擇是交換機配置的一部分。ECN比特位，或者交換機可能會使用“匹配–動作”表實現(xiàn)一個私有的擁塞控制機制。第三章一門編程語言據(jù)包將如何被處理。本文的主要目標是提出這門P4編程語言。盡管如此，我們用特性。比如，這樣的語言需要式來表達解析器是如何被編程的，由此解析器能夠知道它應該處理什么樣的數(shù)據(jù)包格式；因此開發(fā)者需要法來什么樣的首部類型是可能會出現(xiàn)并被處理的。例如，開發(fā)者可以指明IPv4首部的格式，以及什么樣的首部可能合法地遵循了IP首部。通過合法的首部類型促進了P4中的定析。新的隧道首部可能需要被添加，校驗和可能需要重新校驗。這促使P4作為一種必要的控制流程序，通過使用已的首部類型和動作的原語集合，來描述首部區(qū)域的處理過CPU內(nèi)核中應該如何被處理。但它不完全符合我們的需求。我們需要一門能夠?qū)ⅰ敖馕雳C匹配–動作”流水線到指定的硬件上的語言。另外，Click–交換機架構(gòu)而設計的，因此不允許開發(fā)者描述–動作”表。最后一點，Click使人們更難它們是需要串行執(zhí)行的。依賴可以通過分析TDGs表依賴圖而識別；這些圖描述了輸入這引領我們提出一種兩步編譯過程。在頂層，開發(fā)者使用必要的能描繪P4控制流的語言來編寫數(shù)據(jù)包的處理程序；在這一層之下，編譯器將對P4的描述翻譯成TDG表依賴圖，以促進依賴的分析，然后編譯器將會把TDG到具體的交換機對象上。P4P4TDG的過程更加容易?？偟膩碚f，P4Click的普適性和OpenFlow1.0的不靈活性一個折衷點。Click的普適性讓依賴的推測和3-1二層/TDG第四章P4語言示我們通過深入地測試一個簡單的例子來探索P4。許多網(wǎng)絡的部署分為邊緣和兩種；終端主機直接連接在邊緣設備上，邊緣設備之間通過后方的高帶寬網(wǎng)互聯(lián)。所有的協(xié)議都設計去支持這樣的架構(gòu)（比如MPLS[11]和PortLand[12]，主要目的是簡考慮到一個簡單二層網(wǎng)絡的部署，邊緣的TOR交換設備通過兩層的連接在一起。我們假設終端主機的數(shù)量在不斷增長，并且層的二層轉(zhuǎn)即將存滿溢出。MPLS是一個簡化層的選擇，但實現(xiàn)一個多的分布式協(xié)議是一項到令人怯步的任務。PortLand看起來看有趣，但是它要求重寫MAC地址（這可能破壞已有的網(wǎng)絡調(diào)試工具的正常工作ARP請求。P4是我們能夠表達一種個性化的解決方案，同時只需要對網(wǎng)絡架構(gòu)做出做小限度的改變。這個方案稱為mTag：它結(jié)合了PortLand的分層路由思想和類似MPLS可以由終端主機的網(wǎng)卡添加，但是在我們這個例子中，由第一個TOR交換機能的P4程序?qū)⒈冗@復雜很多倍。P4概–Actions：P4支持通過更簡單的協(xié)議無關的原語構(gòu)造復雜的執(zhí)行動作。這些復雜的動作可以在“匹配–動作”表中使用。ControlPrograms–動作”表處理數(shù)據(jù)包的順序。一個簡單又必要的程序描述了“匹配–動作”表之間的控制流。首部格P4借用了許多他們的想法。通常地，每一個首部的詳細闡述都是通過一個各首部區(qū)稱和長度的有序列表來完成?？蛇x的首部區(qū)域注解允許我們約束區(qū)域的取值范圍或可變長區(qū)域的最大長度。例如，標準的以太網(wǎng)和VLAN首部被詳細闡述如下：header{fieldsdst_addr:48;//widthinbitssrc_addr:48;ethertype:}}header{fieldspcp:cfi:vid:ethertype:}}mTag首部可以直接添加，而不必替換已有的這些。首部區(qū)稱表明層有兩層的匯聚。每一個交換機都被編寫了一些規(guī)則來檢查這些字節(jié)中的某一個。具header{fieldsup1:up2:down1:down2:ethertype:}}數(shù)據(jù)包解析P4假設底層交換機可以實現(xiàn)一個狀態(tài)機，這個狀態(tài)機能夠自頭至尾橫貫數(shù)據(jù)包的–動作”表進行處理。P4把狀態(tài)機直接描述成從一個首部到下一個首部的過渡轉(zhuǎn)移的集合。每一個過渡轉(zhuǎn)移可能會被當前首部中的值觸發(fā)。例如，我們按如下內(nèi)容描述mTag狀態(tài)機：parser{}parser{switch(ethertype){case0x8100:vlan;case0x9100:vlan;case0x800:ipv4;//Other}}parser{switch(ethertype){case0x800:ipv4;//Other}}parser{switch(ethertype){case0x800:ipv4;//Other}}start狀態(tài)開始，一直行進直到到達了明stop狀態(tài)或是遭遇到–mTag的解析器是非常簡單的：它只有四種狀態(tài)。真實網(wǎng)絡中的解析器會要求有比這多上許多的狀態(tài)；例如，Gibbet.al.[16Figure3(e)]定義的那個解析器就擴展到了一百多種狀態(tài)。表的規(guī)接下來，開發(fā)者需要描述定義好的首部區(qū)域?qū)⒃凇捌ヅ洙C執(zhí)行動作”階段如何進在我們簡單的mTag例子中，邊緣交換機匹配二層目的地和VLANID，然后選擇一個mTag添加到首部中。開發(fā)者定義一張表來匹配這兩個首部區(qū)域，以及執(zhí)行一個添加mTag首部的動作（見后文。其中的reads屬性了要匹配哪些首部區(qū)域，同時限定了匹配類型（精確匹配、三重匹配等。actions–動作”表可能會對數(shù)據(jù)包執(zhí)行的動作。動作將會在本文后續(xù)部分講解。max_size–動表的規(guī)范允許P4編譯器決定表需要多大的空間，以及在什么樣的（TCAM或SRAM）上實現(xiàn)這個表。tablemTag_table{readsvlan.vid:exact;}actions//Atruntime,entriesareprogrammedwith//forthemTagaction.Seebelow.}max_size:}在控制程序一節(jié)（§4.6）中。tablesource_check//Verifymtagonlyonportstothecorereads{mtag:valid;//Wasmtagparsed?metadata.ingress_port:exact;}actions{//Eachtableentryspecifies*one*//IfinappropriatemTag,sendtoCPU//Ifmtagfound,stripandrecordinmetadata//Otherwise,allowthepackettocontinue}max_size:64;//Oneruleper}tablelocal_switching//Readsdestinationandchecksif//Ifmissoccurs,gotomtag}tableegress_check//Verifyegressis//Donotretagpacketsreceivedwith//Readsegressandwhetherpacketwas}下發(fā)。P4假設一個動作功能中的原語是并行執(zhí)行的。（沒有并行執(zhí)行能力的交換設actionadd_mTag(up1,up2,down1,down2,{//CopyVLANethertypetomTag//SetVLAN’sethertypetosignalmTagset_field(vlan.ethertype,0xaaaa);set_field(mTag.up1,up1);set_field(mTag.up2,up2);set_field(mTag.down1,down1);//Setthedestinationegressportaswell}如果某個動作需要有輸入?yún)?shù)（例如mTag中的up1值在這個例子換機將mTag在VLAN之后，VLAN的Ethertype字段為0xaaaa，表明其后跟隨的是mTag。在邊緣交換機上執(zhí)行的相作沒有展示出來，這些動作將會從數(shù)據(jù)包中剝?nèi)Tag。Set_fieldAdd_header：添加一個有效的特定的首部（以及它所有的首部區(qū)域；Checksum：計算首部區(qū)域的一些集合的校驗和（比如IPv4校驗和控制程制流?？刂屏髯鳛橐粋€程序通過一個函數(shù)、條件和表的組成的集合進行指定。4-1mTag4-1mTag實現(xiàn)展示了一個期望的控制流的圖形化表示。在包存在于連接到交換機的端口上。source_check也會從數(shù)據(jù)包中剝?nèi)Tag，同個元數(shù)據(jù)以避免再次往數(shù)據(jù)包中添加。local_switching表稍后將會被運行。如果沒有匹配上，就意味著這個數(shù)據(jù)包的目的會用來匹配這個數(shù)據(jù)包。本地和送往層的轉(zhuǎn)發(fā)控制都可以被egress_check表處理。這個表將會在轉(zhuǎn)發(fā)目的地未知的情況下，上送一個通知到層。controlmain()//VerifymTagstateandportareconsistent//Ifnoerrorfromsource_check,continueif(!defined(metadata.ingress_error)){//Attempttoswitchtoendhostsif(!defined(metadata.egress_spec))//Notaknownlocalhost;trymtagging}//Checkforunknownegressstate//badretaggingwithmTag.}}第五章P4程為了讓網(wǎng)絡能夠?qū)崿F(xiàn)我們的P4程序，我們需要編譯器來把目標無關的描述到編譯包解析Current表LookupNext**編譯控制程§4.6中必要的控制流描述是便的指定交換機的邏輯轉(zhuǎn)為的方法，但它不正如§3中所討論的，編譯器遵循兩階段的編譯過程。它首先把P4控制程序轉(zhuǎn)換成TDG表依賴圖描述這樣的一個中間結(jié)果，編譯器分析這個描述以查明表之間的依賴。針對特定目標設備的第二步將會把這個依賴圖到交換設備的特定資源上。下。編譯器直接將mTag表圖到交換機的表中。編譯器使用表類型信息來限制表的內(nèi)含RAM和TCAM編譯器可以配置哈希散列，使用RAM來對邊緣交換機的mTag_table表執(zhí)行有效的精確匹配。而層的mTag轉(zhuǎn)是要匹配比特位的一個子集，它將被到TCAM中去執(zhí)行匹配。子中，mTag_table表和local_switching表可以并行執(zhí)行直到設置mTag動作的執(zhí)行。據(jù)，在最終的執(zhí)行中使用。在mTag例子中，無論是mTag的添加還是移除，都能編譯器可以將大量的P4表到較少量的物理表中。在mTag例子中，本地交換可以將原本應寫入兩個P4表中的規(guī)則重新編寫，生成在單個物理表中的規(guī)則。第六章總SDN的愿望是單個控制平面可以直接交換設備網(wǎng)絡。OpenFlow通過提供單一的廠商無依賴的API來支持這個目標。盡管如此，目前的OpenFlow面向的是那些現(xiàn)細節(jié)是否支持。編譯器將一個命令程序轉(zhuǎn)換成TDG表依賴圖，這可以被到家討論。在這個提案換設備仍有幾個方面有待定義（例如擁塞控制原語、排隊策略、流量。盡管如此，我們相信創(chuàng)造一門配置語言的這種方法，將會引領我們實參考文C.Kozanitis,J.Huber,S.Singh,andG.Varghese,“Leamultipleheadersinasinglebound:Wire-speedparsingusingthesystem,”inIEEE ,pp.830–838,2010.P.Bosshart,G.Gibb,H.-S.Kim,G.Varghese,N.McKeown,M.Izzard,F.Mujica,andM.Horowitz,“Forwardingmetamorphosis:Fastprogrammablematch-actionprocessinginhardwareforSDN,”in M,2013. EthernetSwitchSilicon s/white-papers/ethernet--sdn-N.YadavandD.Cohn,“OpenFlowPrimitiveSet.”,JulyH.Song,“Protocol-obliviousforwarding:UnleashthepowerofSDNthroughafuture-proofforwardingplane,”in MHotSDNWorkshop,Aug.2013. ionsworkinggroupcharter.”,Apr.M.Raju,A.Wundsam,andM.Yu,“NOSIX:AlightweightportabilitylayerfortheSDNOS,”ACMMComputerCommunicationsReview,2014.V.Jeyakumar,M.Alizadeh,C.Kim,andD.Mazieres,“Tinypacketprogramsforlow-latencynetworkcontrolandmonitoring,”inACM MHotNetsWorkshop,Nov.2013.A.Sivaraman,K.Winstein,S.Subramanian,andH.Balakrishnan,“Nosilverbullet:ExtendingSDNtothedataplane,”inACM MHotNetsWorkshop,Nov.2013.E.Kohler,R.Morris,B.Chen,J.Jannotti,andM.F.Kaashoek,“TheClickmodularrouter,”ACMTransactionsonComputerSystems,vol.18,pp.263–297,Aug.2000.“MultiprotocolLabelSwitchingCharter.”R.NiranjanMysore,A.Pamboris,N.Farrington,N.Huang,P.Miri,S.Radhakrishnan,V.Subramanya,andA.Vahdat,“PortLand:Ascalablefault-tolerantlayer2d enter