---
# System prepended metadata

title: 111-2 專題研究筆記 Week 1-2

---

# 111-2 專題研究筆記 Week 1-2

## SDN(Software Defined Networking)
Reference : [Software-Defined Networks: A Systems Approach](https://sdn.systemsapproach.org/index.html "Title")
### Landscape
#### Market
被視為一種市場的轉變，過去電腦行業主要的類型為為了客戶的特定目的推出特定的Solution，這種模式被稱為*Vertical market*(垂直市場)，而*SDN*的目標是將市場改造為*Horizontal ecosystem*，即讓Hardware、OS、Application等都能分開，不需要相互依賴，以此來增加市場的豐富性，並將網路設備的控制權轉移回消費者手上，使得消費者能將其更貼近自身需求。
![](https://i.imgur.com/Uk4O53V.png)
#### Technical
將網路設備的不同層級間拆開，並將各個單位間的介面開放並完善定義，這種行為被稱為*disaggregation*。這些層級包括：
- Control Plane
根據現在使用的協定來決定網路行為，使用Routing table來協助考慮Path、Cost、Policy等條件並決定Route。
- Data Plane
根據Control plane的決策來forward封包，使用forwarding table決定封包轉送方式。e.g. Control Plane決定了route順序：A-B-C，因此下一站應該到B，data plane就會接著判斷要將packet送至B的話需要將其從哪個port送出，並判斷新的destination。

![](https://i.imgur.com/Od3Gewk.png)
不過，若是要將Control Plane與Data Plane完整分離，如何處理Control Plane給予Data Plane的instructions就變得格外重要，在2008年時一款知名的支援disaggregation的介面問世，其名為*Open Flow*。
###### *OpenFlow*
- 並不是第一個滿足disaggregation的協定，但其引出的*Flow Rules*很好的解決了forwarding的問題。
- *Flow Rules*是**Match**與**Action**的pair，**Match**會看到header field如*MAC Type*、*IP Addr*，**Action**決定packet是要："forward to one or more ports"、"drop"、"send up to controller"(Controller為switch中的Control Plane)。
- *OpenFlow*使用了Flow Table，可以想成是前述Forwarding table的abstraction。
- 定義了Controller與*OpenFlow Switch*間的TLS安全通訊，如下圖：![](https://i.imgur.com/cC9TKGu.png)

為了滿足SDN的定義，我們希望Control Plane與Data Plane是完全分離的--甚至是在cloud上運行Control Plane，並控制代表Data Plane的交換機。為了兼顧Scalability和availability，在雲端運行的Controller也可以是由多台server(vm)組成，來實現不同的Controller功能。所以，若是需要更多Data Plane，只需加入bare-metal的機器就行；若是需要更多功能，在cloud上增加Server(vm)就行。
![](https://i.imgur.com/CAudyW0.png)
### Use Cases
從各個不同的實例中來觀察SDN的價值。
#### Network Virtualization
網路的虛擬化，包括常見的*VPN(Virtual Private Network)*、*VLAN(Virtual Local Area Network)*。
###### VLAN
- 定義在*IEEE802.1q*，位於OSI第二層。
- 透過邏輯劃分網路終端，不受地理、設備限定。
- 增加網路維護方便度、效能(同個VLAN下的廣播封包不會傳到其他VLAN)
- 通常在switch上設定將某幾個port規劃到同個VLAN，減少collision
###### VPN
- 將私人網路開放到WAN，已註冊的使用者能建立穿隧通道至VPN Server
- 與VPN server建立加密通道(大部分有加密，如*L2TP*、*IPsec*)
- 遠端使用者能以位於該私人網路的型態在網路上活動


雖然這兩者在實際應用上已行之有年，但離SDN真正的定義仍然有些差距。可以想成他們只是將地址空間虛擬化，但其他的性質仍可以be virtualized。
在VLAN還需要手動在Switch上手動配置時，通過在cloud上集中分布的Control Plane，創建、修改、刪除各種網路行為只需要通過單一API入口便可以辦到。
![](https://i.imgur.com/TbYD1c8.png)
當網路變成這樣的programmatic，所有網路相關的行為都可以透過一系列的service來達成，那麼新的網路安全層級也要隨著上升。與其將更多的security feature塞進cloud，不如讓網路本身就具有安全的特徵，因此一種稱之為*microsegmentation*的行為出現，試著創建isolated的網路(microsegment)，如此便可以減少攻擊蔓延的情形發生。
那麼為了達到此目的，VLAN就顯得有些不足了，不只是只有4096個tag不符合公司的實際應用，在網路虛擬化後一個實體交換機port需要對應的mac位置大大增加，因此Data Plane上的address space便成為了限制，因此在2014年時，*VXLAN*(*Virtual eXtensible Local Area Network*)協議出現。
###### *VXLAN*
- 不同於VLAN將virtual第二層位址放在第二層標頭中，*VXLAN*將virtual ethernet frame整個放在一個udp封包中，實現了"透過Layer3滿足Layer2 subnet"
- 負責封裝和拆解這類udp封包的終端叫做*VETP(VXLAN Tunnel EndPoint)*，而該封包的外層IP address就是該VETP，通常一個物理主機就對應一個VETP
- 如下圖，Outer Mac header紀錄VETP間的通訊，Outer IP Header使得封包可以在第三層傳輸，而裡面用udp包著原始的第二層frame![](https://i.imgur.com/awoHy9J.jpg)
- 當VM1欲向VM3發送ARP查址時，VETP1會將該封包封裝成VXLAN封包，丟給VETP2後由他進行解析，得知是要給VM3後再將內層封包遞給VM3，過程中VM2、VM4完全不知情，對Switch來說只是Host1、Host2之間在傳遞udp封包![](https://i.imgur.com/gWbmN7I.png)

#### Software-Defined WANs
待補
#### Access 
待補

## OVS(Open vSwitch)
Reference : [Open vSwitch Documentation](https://docs.openvswitch.org/en/latest "Title")
### Overview
一個multilayer的software switch，支援802.1QVLAN、VXLAN、Geneve(類似VXLAN的協定)、QoS(Quality of Service)、OpenFlow 1.0等等，forwarding function使用Linux的Kernel module，因此可實現高效率。
![](https://i.imgur.com/n0BAmGT.png)

### Components
- ovs-vswitchd，switch本體的daemon，透過Linux的Kernel Module來實現flow-based的forwarding
- ovsdb-server，輕量級的database伺服器，儲存了configuration與table等等的資料
- ovs-dpctl，用來configure switch的Kernel Module
- ovs-vsctl，用來query或更新ovs-vswitchd的configuration
- ovs-appctl，使用者介面，傳送指令到OVS daemon

![](https://i.imgur.com/dLiCYIC.png)
### Usage
#### Implement VLAN using ovs
OVS的虛擬交換機能處理虛擬機間的VLAN功能，在預設模式下port對應到一個VLAN tag，進入該port的封包將被vswitch打上該tag，離開時移除。
![](https://i.imgur.com/DG3GIwx.jpg)
而OVS的端口VLAN還有其他模式能設置，如：
- trunk，滿足802.1q裡的VLAN trunk，能指定一系列的VLAN tag，負責相同VLAN但不同switch的終端溝通，因此該端口允許所有那些包含的tag傳輸，不在他負責的tag list裡面就drop。若收到不含有VLAN ID的封包，進入switch後該封包tag為0；若收到有tag則進入後仍保持該tag，而若發出沒有VLAN ID的封包則發出後將其802.1q header部分移除
- access，drop所有帶有VLAN ID的封包，只允許不帶有VLAN ID的封包進入，任何進入後的封包將被打上該端口的VLAN tag，而從其出去的封包也將被移除VLAN tag
- native-tagged，類似trunk，差別在若從此端口進入時不帶有VLAN header，將根據此端口的tag將其打上
- native-untagged，類似native-tagged，差別native的封包從此端口出去時將被去掉802.1q header

接下來將使用docker在Ubuntu server 20.05 LTS上實驗其VLAN功能，以下為架構圖：
![](https://i.imgur.com/E3S6Pi4.jpg)

先build docker image，參考這個[Dockerfile](https://gist.github.com/ederparaiso/4847aa4e117f2d1e35d14259e6ef8b2d "Title")來Build出可ssh的centos7 image。
    
    sudo docker build --rm -t c7-systemd-sshd .

接著建立4個VM，網卡設定none，等等由OVS來為這些VM指定網卡。


    
    docker run -t -i -d --name vm01 --net=none --privileged c7-systemd-sshd /bin/bash
    docker run -t -i -d --name vm02 --net=none --privileged c7-systemd-sshd /bin/bash
    docker run -t -i -d --name vm03 --net=none --privileged c7-systemd-sshd /bin/bash
    docker run -t -i -d --name vm04 --net=none --privileged c7-systemd-sshd /bin/bash

![](https://i.imgur.com/6c1k5tD.png)
接著建立兩個bridge。
    
    ovs-vsctl add-br vswitch0
    ovs-vsctl add-br vswitch1
使用ovs內建的docker工具給予VM1-4 vNIC以及ip位址等。
    
    ovs-docker add-port vswitch0 eth0 vm01 --ipaddress=192.168.1.2/24
    ovs-docker add-port vswitch1 eth0 vm02 --ipaddress=192.168.1.3/24
    ovs-docker add-port vswitch0 eth0 vm03 --ipaddress=192.168.1.4/24
    ovs-docker add-port vswitch1 eth0 vm04 --ipaddress=192.168.1.5/24
建立switch0到switch1的port，以及switch1到switch0的port
    
    ovs-vsctl add-port vswitch0 patch_to_vswitch1
    ovs-vsctl add-port vswitch1 patch_to_vswitch0
    
    ovs-vsctl set interface patch_to_vswitch1 type=patch
    ovs-vsctl set interface patch_to_vswitch0 type=patch

    ovs-vsctl set interface patch_to_vswitch0 options:peer=patch_to_vswitch1
    ovs-vsctl set interface patch_to_vswitch1 options:peer=patch_to_vswitch0
###### patch port: A pair of virtual devices that act as a patch cable. A patch port only has a single option, and that single option is the name of the patch port at the opposite end.![](https://i.imgur.com/LZGNaVv.png)



這些端口預設是trunk模式，可以port所有VLAN。
![](https://i.imgur.com/tVcn9Rw.png)
使用VM1 ping看看VM2(192.168.1.3)，方法為使用docker ps後確認其ID，再使用 docker exec 來在該container上輸入指令。
![](https://i.imgur.com/2kHy5i9.png)
可以看到目前VM1與VM2是互通的。
![](https://i.imgur.com/2xEwUnt.png)
ping了VM3(192.168.1.4)和VM4(192.168.1.5)發現也可以互通。

於是接下來我們開始為端口加上VLAN tag，先確認先前在show指令中出現的幾個port分別是接在哪個VM上：
![](https://i.imgur.com/FKXUTN4.png)
接著照架構將VLAN tag設好：
    
    ovs-vsctl set port 3bf3a0432f004_l tag=100 //VM1
    ovs-vsctl set port e3008375bc014_l tag=100 //VM2
    ovs-vsctl set port c402ab7f04e94_l tag=200 //VM3
    ovs-vsctl set port e22224266c7c4_l tag=200 //VM4

接著重新從VM1測試到其他人的聯通性，會發現除了與他同個VLAN tag(100)的VM2，VM3與VM4都無法從VM1 ping到了。
![](https://i.imgur.com/jAReOPy.png)
這次從VM3來做測試：

![](https://i.imgur.com/SI5Jgix.png)
我們發現VM3仍只能ping到與其同個VLAN下的VM4，VM1、VM2均無法ping到。

後續改動了trunk的範圍，讓trunk port只負責tag 100的封包，之後VM3和VM4也無法正常互ping了。


## How to read a paper

### The Three-Pass Approach
不要從第一個字看到最後一個字，會浪費太多時間且沒有效率，掌握Three-Pass的方法：
- The First Pass，讓自己對這篇paper的主題有個大致上的認識
- The Secoend Pass，開始對paper的內容有掌握與認識，但還不到細節上
- The Third Pass，有深度的讀懂論文的內容

### The first pass
快速地將整篇論文掃過一遍，藉此對論文有初步的大略認識，大概需要五到十分鐘。

- Title、abstract、introduction為重點
- 讀其他幾個section的標題，但不要看其內容
- conclusions為重點
- 掃一眼references區，在心中記下當中你曾經看過的論文

經過the first pass之後，應該對該篇paper有著初步的了解，不管是它的分類、上下文、假設是否為真、貢獻及文筆等，可以使自己決定要不要繼續讀下去。若以後自己要撰寫paper時，也可以想像自己的paper的大部分讀者都會使用the first pass，因此對於以上幾點就必須重點去滿足讀者，在abstract等等的區域顧好可讀性及讓人一目了然該篇paper主題。

### The second pass
第二遍閱讀時，開始細心地閱讀，但必須忽略某些細節如某些proof。這會幫助我們找到paper的關鍵重點，也可以在空白處將筆記記上。這大概需要1小時。

- 必須仔細的看過出現的圖片、圖表，還有他們的label、橫軸及縱軸。觀察圖表是否有低級錯誤，可以幫助我們判斷paper的優劣
- 將reference區域沒看過的paper記起來，將來去讀

之後我們應該能將整篇paper的主旨summarize出來，有些時候就算過了第二遍你仍然不能太明白整篇paper的主旨，這可能是該篇論文的文筆，又或是你對這篇論文的背景資料並不熟悉，又或是他使用的proof技巧是必要的（稍早前跳過的），這時候有三個選項可以給你選：

- 放下paper去睡覺
- 先去做好背景知識的補充，再重回paper
- 進行The third pass

### The third pass
第三遍的重點是*virtually re-implement*，意思是設想該篇paper的作者的研究情境，想像自己與該作者做出同樣的假設，並且重新開始進行該研究，同時將自己的想法與paper上真正的研究相比較，這可以幫助我們找到隱藏在paper後的某些失敗與假設。
這次閱讀需要極端的對細節的掌握，了解及對paper出現的每個想法與假設提出質疑，試想自己面對相同問題時會如何應對，這會給我們對於這些presentation與proof一些犀利的、獨到的看法，不只是對閱讀paper有幫助，同時也可幫助我們未來的研究。
這次閱讀對初學者來說需要4到5個鐘頭，但對有經驗的人來說大概只需要一個小時，經過這次閱讀後我們可以從記憶中將整篇論文的結構組合起來，並可以判斷該paper的優缺點，忽略不完整的假設及找到該研究的某些隱藏問題。

### Literature Survey
以文獻的調查來說，從Google Scholar或CiteSeer使用較合適的關鍵字來找到3到5篇**最近的**paper。對每篇paper進行one-pass，接著讀他們的related work區塊，我們應該會找到一個recent work的集合，若幸運的話可以找到recent的survey paper。
若沒有的話，找到引文及相關的重複出現作者姓名，這將會是該主題中關鍵的研究人員，並以他們為關鍵字觀察他們是否有新的paper出現，這會幫助我們找到這個主題的top conferences。
最後，在這些conference網站上觀察他們最新的近況，以及新出的paper。和我們之前找到的paper一起，對這些paper進行second pass，找到他們引用的、之前沒看過的paper，並重複這些步驟。
### Related work
- "Writing reviews for systems conferences"-Timothy Roscoe
- Henning Schulzrinne's comprehensive website
- George Whitesides's overview
- Simon Peyton Jones's website














