思科談OpenDaylight

雖然依舊能在市場上看到思科的可擴展網絡控制器(XNC)，可是你可能已經注意到思科在最近的一段時間內，一直在談論其開放SDN控制器（替代XNC）。

顯然，思科擁有了基於OpenDaylight氫版本的其餘控制器，XNC已經到了退出歷史的舞臺的時刻。那麼該控制器對OpenDaylight架構作了哪些根本性的改變在下面咱們將談到。

OpenDaylight的核心

思科的開放SDN控制器的變化在控制平臺的服務抽象層，位於南向接口之上，如OpenFlow。這意味着隔離了應用程序所在的北向接口。這樣，應用程序和網絡設備端均可以與抽象層進行交互，這意味着你不須要擔憂是否一個應用程序知道如何與特定的設備交流。

2014年初發布了OpenDaylight的第一個版本——氫，使用了由API驅動的服務抽象層(AD-SAL)，由思科XNC構造。可是AD-SAL模式有其侷限性，也就是它須要知道網絡中設備全部的類型。若是要引入一個新的接口，必需要更新更新設備的驅動和控制器。

因此即便推出了OpenDaylight氫版本，思科仍然幫助推進另外一種模式:模型驅動的服務抽象層(MD-SAL)。MD-SAL的關鍵是Yang模型而不是設備APIs。應用程序能夠向模型請求更新，而後抽象層向網絡設備轉發請求。

在這個模型中，控制器不須要識別網絡設備的類型。該模型還能使OpenDaylight更模塊化；開發團隊能夠獨立工做，而且整合他們的代碼。

潛水艇和浴缸
爲了適應MD-SAL，思科的XNC派上了用場。全部基於OpenDaylight的控制器基礎設施必須調整。(AD-SAL仍可用，但MD-SAL顯然OpenDaylight的將來。)

沒有生產基於氫版本控制器的供應商未受影響，如博科。他們在氦版本發佈之後，正好能夠利用MD-SAL生產本身的控制器。

其餘供應商也作了許多工做，NEC就在最近完成了虛擬租戶網絡的移植，以適應MD-SAL。

惠普雖然還在用它的OpenDaylight控制器，但同時，該公司已與收購的ConteXtream收錄了一些基於OpenDaylight的代碼。在最新的鋰版本中，AD-SAL已經不建議使用了。預計在2016年的下一個版本中AD-SAL將徹底消失。

MD-SAL是OpenDaylight的核心元素。它反映了你會從任何平臺構建的SDN控制器中得到模塊驅動的舉動。這也是OpenDaylight項目合做做品的開放模式的一個例子。雖然有人人提出了反對意見，認爲MD-SAL太複雜，就像使用「潛艇穿越浴缸」，可是經過激烈的辯論，MD-SAL被看做是長期的解決方案。

本文轉載自SDNLAB，原文連接：http://www.sdnlab.com/12960.html