網(wǎng)絡(luò)行業(yè)的發(fā)展如果非要?dú)w納出一個(gè)明確的發(fā)展趨勢(shì)的話(huà)，那這個(gè)趨勢(shì)無(wú)疑是“開(kāi)放”。業(yè)界有一個(gè)奇怪的現(xiàn)象，但凡涉及到“開(kāi)源、開(kāi)放”的技術(shù)或者社區(qū)，好像都比較受到追捧，網(wǎng)絡(luò)行業(yè)也不外如是，那么到底什么是開(kāi)放網(wǎng)絡(luò)呢？

網(wǎng)絡(luò)用戶(hù)和運(yùn)營(yíng)商長(zhǎng)期以來(lái)一直在傳播這樣一個(gè)觀(guān)點(diǎn)，他們認(rèn)為開(kāi)放是指支持組織的自由替代。如果我現(xiàn)在在網(wǎng)絡(luò)中有個(gè)A盒子，它可以用B盒子加以取代，那這就是開(kāi)放網(wǎng)絡(luò)。但是這是不是就意味著用戶(hù)可以簡(jiǎn)單地在同一個(gè)位置取代設(shè)備？這些接口是否完全相同？用戶(hù)能夠接受需要微調(diào)以支持硬件取代的網(wǎng)絡(luò)嗎？甚至是只支持主流硬件替代的“開(kāi)放”網(wǎng)絡(luò)嗎？

撲朔迷離的未來(lái)

傳統(tǒng)網(wǎng)絡(luò)設(shè)備有三種類(lèi)型的接口。一類(lèi)支持端口/中繼數(shù)據(jù)平面連接。另一種支持的控制交互，第三種支持設(shè)備管理。軟件組件在某種意義上等同于身，需要獨(dú)立的接口，通常被稱(chēng)為應(yīng)用程序接口即API，我們將網(wǎng)絡(luò)軟件API歸類(lèi)于設(shè)備接口相同的第三個(gè)種類(lèi)中。事實(shí)上，像托管路由實(shí)例一樣的網(wǎng)絡(luò)軟件將具備這三類(lèi)接口，但是它們同時(shí)還具有一整套設(shè)備從未顯示的API，而這些API使軟件定義中的開(kāi)放性變得撲朔迷離。

假設(shè)用戶(hù)需要托管一個(gè)Virtual_Router單個(gè)軟件元素，用戶(hù)必須能夠?qū)⑵洳渴鹪谛枰浖鸵唤MAPI的服務(wù)器上，用戶(hù)必須能夠管理服務(wù)器和路由器實(shí)例。

當(dāng)用戶(hù)希望能夠擴(kuò)展虛擬路由器的端口和中繼接口時(shí)，這種情況將變得不受控制。端口和中繼件必須連接核心路由器元素——另一套API，用戶(hù)可以在完整的軟件定義網(wǎng)絡(luò)（SDN）或網(wǎng)絡(luò)功能虛擬化（NFV）中輕松識(shí)別幾十個(gè)API，并且部署完成的SDN/NFV可能具有數(shù)萬(wàn)個(gè)API。處理數(shù)量呈爆炸式增長(zhǎng)的API，廠(chǎng)商給出的方式是將API發(fā)布在某種目錄中。

然而，這種方式效果非常有限，因?yàn)锳PI不是我們?cè)谠O(shè)備中可以看到的物理接口，設(shè)備通過(guò)物理接口以非常具體的方式互通。API不會(huì)描述集體圖案管虛擬設(shè)備的工作原理，而是如何在虛擬設(shè)備內(nèi)部進(jìn)行工作。API支持軟件組件工作流程，但是當(dāng)路由器具備標(biāo)準(zhǔn)功能時(shí)，每個(gè)路由器供應(yīng)商將其軟件分成相同的組件？還是使用完全相同的信息格式來(lái)進(jìn)行通信？

舉個(gè)規(guī)?；W(wǎng)絡(luò)軟件的負(fù)載能力的例子，一個(gè)廠(chǎng)商可能會(huì)在其“規(guī)模化控制”API中要求每個(gè)分組數(shù)據(jù)包的規(guī)模限制，另一廠(chǎng)商可能希望根據(jù)托管它的處理器的CPU利用率來(lái)規(guī)?；M件的副本。第三個(gè)廠(chǎng)商可能都不接受明確的規(guī)?；刂啤．?dāng)今開(kāi)放的最大問(wèn)題是，開(kāi)放API不僅僅意味著已發(fā)布的API，還意味著通過(guò)API的信息格式，并且取決于軟件實(shí)現(xiàn)的細(xì)節(jié)。

基于意圖（intent）

網(wǎng)絡(luò)軟件正在試圖通過(guò)一種基于所謂“意圖”的層次建模來(lái)解決這個(gè)問(wèn)題，意圖模式描述“what”所指的是功能而不是實(shí)現(xiàn)方式（How）。由于暴露了特定的屬性顯式API，虛擬路由首先被建模，任何想要成為虛擬路由的東西都必須具備這樣的高級(jí)模型。其中可能會(huì)定義“port-instances”和“trunk-instances”，它們描述了虛擬路由的各項(xiàng)功能，但在某種程度上，某一部分的意圖模型包含隱藏或?qū)Ｓ玫倪壿?，這些是不開(kāi)放的。

用戶(hù)可以根據(jù)開(kāi)放的定義將一個(gè)兼容的虛擬路由替換成另一個(gè)虛擬路由，如果虛擬路由模型分解成“port-instances”和“trunk-instances”模型，那么也可以通過(guò)替換這些加以實(shí)現(xiàn)。然而，如果基本的核心路由邏輯不是單獨(dú)建模的，那么用戶(hù)不能實(shí)現(xiàn)設(shè)備或虛擬路由的替換。

這意味著在我網(wǎng)絡(luò)軟件和軟件驅(qū)動(dòng)的網(wǎng)絡(luò)中，我們承認(rèn)了一切都不開(kāi)放且不允許實(shí)現(xiàn)專(zhuān)有的變化的方式來(lái)表述所謂的開(kāi)放性的概念擴(kuò)展。這意味著開(kāi)放API本身就是一個(gè)笑話(huà)，因?yàn)樗痪邆淙魏我饬x，開(kāi)放的未來(lái)是將功能與實(shí)現(xiàn)分開(kāi)的軟件建模的未來(lái)。

我們應(yīng)該關(guān)注的是如何建立軟件建模，如果我們可以為設(shè)備和設(shè)備網(wǎng)絡(luò)定義標(biāo)準(zhǔn)結(jié)構(gòu)，并且可以在基于意圖的層次結(jié)構(gòu)上構(gòu)建這種標(biāo)準(zhǔn)的網(wǎng)絡(luò)，我們未來(lái)的軟件定義網(wǎng)絡(luò)元素將遍地開(kāi)花，這也是我們所期待的。