# 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等都能分開，不需要相互依賴，以此來增加市場的豐富性，並將網路設備的控制權轉移回消費者手上，使得消費者能將其更貼近自身需求。
#### 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。

不過，若是要將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安全通訊，如下圖：

為了滿足SDN的定義，我們希望Control Plane與Data Plane是完全分離的--甚至是在cloud上運行Control Plane，並控制代表Data Plane的交換機。為了兼顧Scalability和availability，在雲端運行的Controller也可以是由多台server(vm)組成，來實現不同的Controller功能。所以，若是需要更多Data Plane，只需加入bare-metal的機器就行；若是需要更多功能，在cloud上增加Server(vm)就行。
### 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入口便可以辦到。
當網路變成這樣的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
- 當VM1欲向VM3發送ARP查址時，VETP1會將該封包封裝成VXLAN封包，丟給VETP2後由他進行解析，得知是要給VM3後再將內層封包遞給VM3，過程中VM2、VM4完全不知情，對Switch來說只是Host1、Host2之間在傳遞udp封包

#### 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，因此可實現高效率。

### 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

### Usage
#### Implement VLAN using ovs
OVS的虛擬交換機能處理虛擬機間的VLAN功能，在預設模式下port對應到一個VLAN tag，進入該port的封包將被vswitch打上該tag，離開時移除。
而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功能，以下為架構圖：

先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

接著建立兩個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.

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

於是接下來我們開始為端口加上VLAN tag，先確認先前在show指令中出現的幾個port分別是接在哪個VM上：
接著照架構將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到了。
這次從VM3來做測試：

我們發現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