time4:it is about time

abstraction

介紹了TIME4， 利用精確地時間協調網絡更新。定義了的更新場景，叫做flow swap。定義了lossless flow allocation 無損流分配問題，展示了一些需要頻繁更新路徑的場景。論文工作已經被ONF採納，用於OPENFLOW1.5。

I. introduction

A. it is about time

同步時鐘更新在各個網絡中都是成熟的技術。PTP就是非常高精度的同步時鐘，精度爲1微秒。目前13個支持SDN的交換機中9個都支持PTP技術。
我們的工作，TIME4可以實現定時更新，本文也展示了一類更新場景使用精確時間是最好的選擇。

B. the challenge of dynamic traffic engineering in SDN

集中式網絡更新通常包含多個網絡設備，需要降低臨時混亂。SDN用於校園網，數據中心，廣域網，運營商網絡，移動網絡。廣域網和運營商網絡要求低丟包率。移動網絡要求對於視頻和音頻幀丟失率不超過10^ -4, 其他低優先級的包也不超過10^-3.
總之，所有的所有的網絡都要求低丟包率。

C. timed network update

如圖1展示了一個更新場景，只有同時更新S1,S3纔可以避免死鎖。
本文我們展示了一個動態環境，流會不斷的增加刪除或者重路由，流交換（ flow swap ）不可避免。accuracy就是我們的解決方案，但是不可能所有的更新同時應用在所有交換機，有一個小的間隔，我們稱之爲調度錯誤。

D. related work

大量的工作研究流表更新，（1）找一個更新順序序列，（2）兩階段等。然而這些方案對於死鎖，資源等沒有很好地解決方案，只是用於流更新一致性。
SWAN建議預留10-30%的鏈路空間緩解堵塞，B4提出臨時降低一些或者所有流的帶寬，他們可以解決資源問題，但是我們的方法可以優化這些解決方案。

E. contributions

• 定義了一類更新場景，爲流交換，展示了利用同步時鐘進行同步更新，提供了更好的解決方案。
• 展示了設計，實現，評估。
• 我們的工作包含一個openflow協議擴展，已經被1.5應用。

II. the lossless flow allocation(LFA) problem

A. inevitable flow swap

本節討論流交換的不可避免，而且沒有策略可以避免這種場景出現。
我們的分析基於不可分割的流問題，如圖2。
給一個有向圖，源節點s,目標節點d, 定義兩者的博弈： source （可以認爲是攻擊者）生成流，controller重新配置網絡轉發規則，達到儘量沒有丟包。
我們的觀點是：source有策略強制控制器進行流交換，也就是多個流同時進行更新的場景不可避免，體現我們的提出的定時更新的重要性。

B. model and definition

下面我們闡述lossless flow allocation（LFA）問題。source和controller之間的博弈，源不斷增加或者刪除流，控制器找出一條路徑。源的目的是漸增的增加流，迫使控制器執行流交換。控制器的目的是找到一個路徑減少丟包率。
我們展示源有策略實現迫使控制器進行流交換。

假設：1，每個流有固定的帶寬。2. 控制器要降低丟包 3.流不可切分。

定義流：SDN中爲共有一些屬性：例如源目的地址等。本文我們將一個流看做是源和目的之間一個session。
網絡可以表示爲一個有向有權重無環圖，$\color{red}{G = (V, E, c)}$.

其中V = Vin U {s,d}, Vin表示中間的節點，{s,d} 表示源和目的節點。
所有的直接連着s的節點表示爲O = {O1, O2, O3,}。
從源出發的邊爲無限容量，其餘邊容量爲c, 文中簡化，c= 1. 這樣的一個圖G就是LFA圖。
從 S出發的流定義爲F = {F1， F2, F3}每個流定義爲Fi = (i, fi, ri); 其中i表示index， fi表示流帶寬,ri表示控制器轉發給的節點。

控制器維持轉發功能Rcon: F×Vin ->Vin U {d}.

C. LFA 博弈

源策略Ss(F, Rcon) = (a, F)定義一組流的轉發功能，（a, F）代表源的下一步a ∈{add, remove}。
控制器策略Scon(Rcon, a, F) = U = {u1, u2, ……}，U就是一組更新。
注意當流被移除，控制器更新很簡單，我們主要討論添加新流。
theorem1. 存在策略Ss, 迫使控制器不得不執行流交換。

證明：如圖2b， 我們認爲m爲流入d的鏈路數量，
m = 1策略簡單，先討論m= 2。
兩個邊流入d,分別額爲 e1和e2，下面給一個例子。
如果source生成四個流
F1 = (1,0.35,o1), F2 = (2,0.35,o1), F3 = (3,0.45,o2),  F4 = (4,0.45,o2) 
有兩種情況。
 a. 控制器可能按照順序e1爲0.35和0.45，e2也是，
 然後source生成一個新流F5 = （5， 0.3, o1）只能移動0.35和0.45.
 出現場景流交換。
b. 控制器分配e1爲0.35和0.35， e2爲0.45， 0.45，
source生成兩個流F6,F7，帶寬分別爲0.2， 
將F6安排到e1後,需要交換0.35和0.45纔可以分配F7.
出現場景流交換。
當m > 2, 我們先生成m-2個帶寬爲1的流，佔據其他的鏈路，
問題降級爲m=2.

理論1展示了2-swap，我們後邊證明k-swap.

---

**theorem2. 交換機存在策略，迫使控制器進行K交換。**

證明：如果m是偶數，source生成m個流帶寬0.35， m個流帶寬0.45， m個流帶寬0.2, 每個鏈路都有一個0.35,0.45 和0.2 的流。
之後移除m個0.2帶寬的流，添加m/2個帶寬爲0.3的流。
按照理論1， 每個0.3流都會造成一個2-swap, 整個網絡就是一個m/2-swap.

如果m是奇數，source先生成帶寬爲1的流，之後按照上述偶數產生m-1/2-swap.

本文主要討論m=2的部分。

D. inpact of flow swap

定義矩陣表示流的超出額度oversubscription。
通過理論證明表示：流交換不僅僅不可避免，而且對整個網絡有較大的影響力。

III. design and implementation

A. protocol design

1. overview
   控制器設計一個執行時間發送給交換機，定義交換機執行命令的時間。
   time4需要控制器和交換機維持一個本地時鐘，允許時間觸發事件，本地時鐘是同步的，我們可以使用現有的同步時鐘，我們使用reversePTP.
2. openflow time extension
   我們提出一個擴展，該擴展允許openflow控制器向交換機發出命令規定執行時間。
   我們使用Bound（一組openflow 消息， 可以看做一個單獨的操作），我們的time extention定義爲scheduled Bundles(一組命令在一個指定的時間執行)。
   我們使用Bundle消息實現TIme4有兩個優點：

• （1）不需要改變消息結構，增加time擴展。
• （2）scheduled bundle允許取消命令。

圖5展示了scheduled bundle 消息流程。
（1）控制器發送bundle open 消息給交換機
（2）控制器發送add message ,每個add massage封裝一條openflow message, 例如flow_mod。
（3）發送bundle close消息
（4）發送bundle commit消息，可選的帶有一個執行時間Ts, 交換機將在預定的時間Ts執行命令。

bundle discard 消息 允許控制器不執行命令。bundle commit 消息發送之後，如果一個交換機發送error消息，控制器會發送discard消息給所有交換機，取消調度操作。

因此，當交換機收到bundle commit消息後後，交換機應該確定他是否有足夠的資源執行這個命令。
同樣定義了 bundle feature request消息，控制器詢問交換機是否支持scheduled bundles.

3. clock synchronization:reversePTP
   原有的PTP是一個單節點向其他節點分發自己的時間，reversePTP是所有的節點向master分發自己的時間，即交換機向控制器發送自己的時間。控制器可以得到自己的時鐘和每個交換機時鐘之間的偏差，offset（i）假設執行時間爲Ts, 那麼交換機i 的指令中執行時間爲Ts+offset(i).
   兩個好處

• （1）控制器處理複雜算法，交換機只是發送自己的時間
• （2）控制器可以追蹤每個時鐘的狀態，初始同步完成，控制器就會知道。

B. prototype design and implementation

如圖7爲系統架構，黑色部分是作者自己的實現。

• switch：交換機基於使用開源代碼 CPQD opensoftswitch, 添加一個switch scheduling模塊，當交換機收到控制器的scheduled bundle 消息，這個模塊可以在預定的時間調度執行對應的指令，這個模塊也可以處理收到的bundle feature request消息。

• 並且交換機跑着一個reversePTP master， 發送交換機時間給控制器。

• controller：控制器模塊時間基於CPDQ DPCTL，這完全是個命令行工具，擴展DPCL 添加time extension 模塊實現我們的需求。 新模塊可以爲bundle commit 指令定義一個執行時間，同樣課發送bundle feature request消息。

• 並且控制器運行着reversePTP，收到來了交換機的n個實例，按照偏移量計算命令執行時間。

IV. EVALUATION

未完待續。。。

---

注：本文介紹兩篇論文：
【1】 T. Mizrahi and Y. Moses, “TIME4: Time for SDN,” technical report, arXiv preprint, 2016.
【2】Tal Mizrahi, Yoram Moses， “Software Defined Networks: It’s About Time”，IEEE INFOCOM 2016.

---