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

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

撲朔迷離的未來

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

假設用戶需要托管一個Virtual_Router單個軟件元素，用戶必須能夠將其部署在需要軟件和一組API的服務器上，用戶必須能夠管理服務器和路由器實例。

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

然而，這種方式效果非常有限，因為API不是我們在設備中可以看到的物理接口，設備通過物理接口以非常具體的方式互通。API不會描述集體圖案管虛擬設備的工作原理，而是如何在虛擬設備內部進行工作。API支持軟件組件工作流程，但是當路由器具備標準功能時，每個路由器供應商將其軟件分成相同的組件？還是使用完全相同的信息格式來進行通信？

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

基于意圖（intent）

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

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

這意味著在我網絡軟件和軟件驅動的網絡中，我們承認了一切都不開放且不允許實現(xiàn)專有的變化的方式來表述所謂的開放性的概念擴展。這意味著開放API本身就是一個笑話，因為它不具備任何意義，開放的未來是將功能與實現(xiàn)分開的軟件建模的未來。

我們應該關注的是如何建立軟件建模，如果我們可以為設備和設備網絡定義標準結構，并且可以在基于意圖的層次結構上構建這種標準的網絡，我們未來的軟件定義網絡元素將遍地開花，這也是我們所期待的。

責任編輯：Ct