本篇文章是繼《基于sdn,nfv的服務感覺網絡架構上篇》對dpi進行進一步的深入解析，分析了在sdn中可能出現的三種部署情況，對第4-7層的業務需求以及業務感覺網絡架構作了一個深入的介紹。
在sdn網絡中部署dpi
sdn架構包括四個或者更多的層次，包括業務流層，業務應用層，控制層和節點層。下圖表示了dpi在用于流量整形、使用者分析、qoe和網絡安全時可能被嵌入的三個層，僅舉幾例。這些部署方案允許dpi資訊在網絡内共享，這樣隻要進行一次應用識别即可，進而節省了cpu和能耗。統一的dpi簡化了管理，因為所有的裝置對資訊流會共享一個“相似的觀點”。擁有提供dpi服務的基礎設施最主要的好處是，應用程式開發者不再需要把dpi合并—沒有必要推倒重來。
三種可能的部署情況：
業務應用層
dpi軟體可以相對輕松地被嵌入到業務應用層。然而一些應用程式的重新設計可能需要盡可能減小由于漫長的通信路徑造成潛在瓶頸的影響。比如，一些資訊流必須通過由節點到sdn控制器再到運作dpi引擎的應用程式這樣的路徑。資訊流被識别後，應用程式發送政策規則到節點引導資訊流的流動，是以通常情況下隻有一小部分的流量從節點發送到應用程式網絡。考慮到可能有延遲，這種dpi部署最好用于時效性不強的應用程式，如分析功能。
控制層
dpi軟體可以部署在sdn控制器中，它可以将網絡智能應用于自己的控制服務，或者通過北向接口的api發送到網絡應用層。節點(例如交換機，網絡裝置)處理流發送的第一個非空包到sdn控制器用于l4-l7分析，可能使用了openflow協定的一些擴充功能，後文會繼續讨論。把dpi放置在控制器中避免了節點帶來的成本增長;但是，部分資訊流(可能低于10%)必須被轉發，從節點到控制器，這可能導緻可擴充性和性能的一些問題。一個分布式控制器架構的設計可以最大限度地減少這些問題。
節點層
網絡節點也可以運作dpi軟體，識别應用程式id和中繼資料後，它們還可以：
直接應用預先定義的政策
将此資訊發送到sdn控制器或網絡應用程式，然後接受政策或規則。
當sdn控制器作為提取資訊的接受者，它可以在與網絡應用以某種形式對話之後訓示節點應用特定的政策。在這之後的所有同一類型的資訊流就不需要再被dpi分析了。與其他選擇相比，在節點層執行dpi最小化了等待時間，但這種方法也是最昂貴的，因為它需要最大量的dpi執行個體在網絡中。将來，dpi的執行個體數量可以通過标記或者傳送端至端資訊的方式來減少，如在最近的ietf草案通過加入網絡服務報頭(nsh)建議的增強建議。另外還有一些解決方法設想使用标記/标簽，配置通道等。
openflow的擴充需要l4-l7裝置
openflow作為sdn南向協定，用以攜帶交換機和sdn控制器之間每條資訊流中提取的中繼資料。這個附加的l4-l7智能将擴充到現有openflow協定中，超越使用者可配置的n元組的形式。這些新的“l4-l7的dpi”字段可能成為通用格式，被所有的交換機，控制器和應用程式運用。
這可以在openflow協定中引入的類型—長度—值元素實作，用以支援可選資訊的編碼，如以下字段。
規則：識别協定、應用程式(app id)和中繼資料
操作：諸如丢棄資料包，封裝和轉發資料包給控制器，或者轉發資料包到端口
統計：其中包括計算的中繼資料，http主機名，http cookie，和供應商特定屬性(vsa)
下圖展示了應用程式id、中繼資料字段和操作如何添加到openflow協定中。
業務感覺網絡架構
營運商部署基于sdn和nfv的網絡可以利用dpi實作的網絡智能來提供新的服務并且可以更好地管理帶寬。dpi通過幫助營運商識别和監管他們開展的廣泛服務和應用，為營運商針對他們的網絡提供更多的控制權。通過計算和dpi技術，這都是可以實作的。dpi将使控制器和應用程式做出更明智的決定，為網絡營運商節省成本，增加創收機會。
作者：何妍
來源：51cto