網(wǎng)絡行業(yè)的發(fā)展如果非要歸納出一個明確的發(fā)展趨勢的話，那這個趨勢無疑是“開放”。業(yè)界有一個奇怪的現(xiàn)象，但凡涉及到“開源、開放”的技術或者社區(qū)，好像都比較受到追捧，網(wǎng)絡行業(yè)也不外如是，那么到底什么是開放網(wǎng)絡呢？
網(wǎng)絡用戶和運營商長期以來一直在傳播這樣一個觀點，他們認為開放是指支持組織的自由替代。如果我現(xiàn)在在網(wǎng)絡中有個A盒子，它可以用B盒子加以取代，那這就是開放網(wǎng)絡。但是這是不是就意味著用戶可以簡單地在同一個位置取代設備？這些接口是否完全相同？用戶能夠接受需要微調以支持硬件取代的網(wǎng)絡嗎？甚至是只支持主流硬件替代的“開放”網(wǎng)絡嗎？
撲朔迷離的未來傳統(tǒng)網(wǎng)絡設備有三種類型的接口。一類支持端口/中繼數(shù)據(jù)平面連接。另一種支持的控制交互，第三種支持設備管理。軟件組件在某種意義上等同于身，需要獨立的接口，通常被稱為應用程序接口即API，我們將網(wǎng)絡軟件API歸類于設備接口相同的第三個種類中。事實上，像托管路由實例一樣的網(wǎng)絡軟件將具備這三類接口，但是它們同時還具有一整套設備從未顯示的API，而這些API使軟件定義中的開放性變得撲朔迷離。
假設用戶需要托管一個Virtual_Router單個軟件元素，用戶必須能夠將其部署在需要軟件和一組API的服務器上，用戶必須能夠管理服務器和路由器實例。
當用戶希望能夠擴展虛擬路由器的端口和中繼接口時，這種情況將變得不受控制。端口和中繼件必須連接核心路由器元素——另一套API，用戶可以在完整的軟件定義網(wǎng)絡（SDN）或網(wǎng)絡功能虛擬化（NFV）中輕松識別幾十個API，并且部署完成的SDN/NFV可能具有數(shù)萬個API。處理數(shù)量呈爆炸式增長的API，廠商給出的方式是將API發(fā)布在某種目錄中。
然而，這種方式效果非常有限，因為API不是我們在設備中可以看到的物理接口，設備通過物理接口以非常具體的方式互通。API不會描述集體圖案管虛擬設備的工作原理，而是如何在虛擬設備內部進行工作。API支持軟件組件工作流程，但是當路由器具備標準功能時，每個路由器供應商將其軟件分成相同的組件？還是使用完全相同的信息格式來進行通信？
舉個規(guī)模化網(wǎng)絡軟件的負載能力的例子，一個廠商可能會在其“規(guī)模化控制”API中要求每個分組數(shù)據(jù)包的規(guī)模限制，另一廠商可能希望根據(jù)托管它的處理器的CPU利用率來規(guī)?；M件的副本。第三個廠商可能都不接受明確的規(guī)模化控制。當今開放的最大問題是，開放API不僅僅意味著已發(fā)布的API，還意味著通過API的信息格式，并且取決于軟件實現(xiàn)的細節(jié)。
基于意圖（intent）網(wǎng)絡軟件正在試圖通過一種基于所謂“意圖”的層次建模來解決這個問題，意圖模式描述“what”所指的是功能而不是實現(xiàn)方式（How）。由于暴露了特定的屬性顯式API，虛擬路由首先被建模，任何想要成為虛擬路由的東西都必須具備這樣的高級模型。其中可能會定義“port-instances”和“trunk-instances”，它們描述了虛擬路由的各項功能，但在某種程度上，某一部分的意圖模型包含隱藏或專用的邏輯，這些是不開放的。
用戶可以根據(jù)開放的定義將一個兼容的虛擬路由替換成另一個虛擬路由，如果虛擬路由模型分解成“port-instances”和“trunk-instances”模型，那么也可以通過替換這些加以實現(xiàn)。然而，如果基本的核心路由邏輯不是單獨建模的，那么用戶不能實現(xiàn)設備或虛擬路由的替換。
這意味著在我網(wǎng)絡軟件和軟件驅動的網(wǎng)絡中，我們承認了一切都不開放且不允許實現(xiàn)專有的變化的方式來表述所謂的開放性的概念擴展。這意味著開放API本身就是一個笑話，因為它不具備任何意義，開放的未來是將功能與實現(xiàn)分開的軟件建模的未來。
我們應該關注的是如何建立軟件建模，如果我們可以為設備和設備網(wǎng)絡定義標準結構，并且可以在基于意圖的層次結構上構建這種標準的網(wǎng)絡，我們未來的軟件定義網(wǎng)絡元素將遍地開花，這也是我們所期待的。
參考鏈接：http://www.nojitter.com/post/240172803/what-would-open-networking-look-like
京公網(wǎng)安備 11010502049343號