본문 바로가기
네트워크/컴퓨터 네트워크 수업

4-4. Generalized Forwarding, SDN

by dustnn 2024. 11. 24.

4-1. Overview of Network Layer

4-2. What's inside a router

4-3. IP(Internet Protocol) : forwarding을 위해 사용

(1) datagram format & fragmentation

(2) IPv4 addressing

(3) network address translation(NAT)

(4) IPv6

4-4. Generalized Forwarding, SDN(Software-Defined Network)

4-5. Middleboxes : 새롭게 생겨나는 기능들을 router의 핵심 계층으로 실을 수 없어 만드는 별도의 box


router

header에 있는 prefix를

forwarding table을 참고해

"longest prefix matching"으로

lookup & forwarding한다고 했었다.

 

SDN은 router의 새로운 패러다임이다.

 

SDN

 

 

data plane이 SDN기반이면 어떤 일들이 이루어지는지에 대해 중점적으로 볼 것이다.

 

SDN에서는 generalized forwarding이 이루어진다.

 

Generalized forwarding

 

"match + action"(lookup&forwarding 보다 많은 기능)

- 많은 header fields가 영항을 줌(frame header/IP header/TCP header) => flow 형성

- 이 flow를 기반으로 많은 action 가능(drop/copy/modify/log) => "router" 대신 "packet switch"라 부름

- "flow" 기반으로 forwarding하기 때문에 forwarding table 대신 flow table을 사용한다.

 

<-> destination-based forwarding: destination의 IP address 기반 => forwarding table 사용

 

Router Packet Switch
forwarding table flow table
lookup & forward match + action

 

flow table

 

flow table에는 "match" entry와 "action" entry가 존재한다.

match에서 동일한 property를 공유하는 packet 그룹을 "flow"라고 한다.

아까 말했듯 flow는 link-, network-, transport-layer의 header field를 통해 결정된다.

같은 flow를 가진 packet들은 동일한 "match" entry, "action" entry를 부여받는다.

 

 

flow table 안에 있는 entries

- "match" entry

"a set of header field values" 존재

* 들어오는 packet의 header field 값들이 entry와 매칭됨

* 매칭 안 되면 drop되거나 send to controller

위 예에서 match entry

* link-, network-, transport-layer의 header 모두 봄!!(<-> forwarding table에서는 only network layer header만 참고..)

 

- "action" entry

매칭 된 packet에 한해 block/drop, forward, modify fields in headers, send to a controller/special server, copy etc..

=> forwarding에만 국한x 다양한 action 취할 수 있음

* SDN network 에서는 central controller가 flow table 작성해 packet switch들에게 내려보내줌

* special server는 가령 그 packet에 대해 특정 목적을 가지고 검사

위 예에서 action entry

 

- "counters"

flow table 각 entry에 매칭된 packet수와 byte수 통계내서 갖고 있음

 

entries와 entries 내용

 

match + action 예

 

1. Destination-based forwarding

 

- IP destination address: 이것만 특정 => destination based forwarding과 같은 역할

- Action: Forward(6): 6번 포트로 forwarding => traditional router와 똑같음

 

 

 

2. Layer 2 destination-based forwarding

 

- Mac dst: 이것만 특정 => Layer 2의 switch와 같은 역할

- Action

mac dst 정했으면 router로 가야 함.

end host에서 first hop router로 가기 위해서는 switch를 통해야 하는데

switch로 가는 link 타기 위해서는 mac frame의 header에 mac destination 주소를 사용해야 한다.

 

3. Firewall

- TCP dport: 22

- Action: drop

=> TCP destination port=22이면 drop 시킴 => firewall과 같은 역할

 

4. Firewall

 

- IP Src: 128.119.1.1

- Action: drop

=> IP source가 128.119.1.1이면 drop => firewall과 같은 역할

 

 

OpenFlow example

 

(예시1)

 

하나의 네트워크 내 각 라우터들은 일관된 행동을 보여야 충돌 없이 원활한 네트워크 동작이 가능하다.

이때 일관된 과정을 위해 controller가 flow table을 orchestrate시키는 것이다.

 

예컨대 "h5/h6가 h3/h4로 가기 위해서는 s1과 s2를 경유해야 한다"고 할 때

controller가 flow table을 어떻게 작성하는지에 대해 알아보자.

 

1. s3의 flow table

- match

* IP Src = 10.3.*.* => h5와 h6의 IP 주소는 모두 10.3.x.x이기 때문에

* IP Dst = 10.2.*.* => h3과 h4의 IP 주소는 모두 10.2.x.x

 

- action

* 3번으로 forward => s1과 s2를 경유해야 하는데 그러기 위해서는 s1부터 경유해야 하기 때문에

 

2. s1의 flow table

- match

* ingress port = 1 => s3로부터 들어오기 때문에

* IP Src = 10.3.*.* => h5와 h6의 IP 주소는 모두 10.3.x.x이기 때문에

* IP Dst = 10.2.*.* => h3과 h4의 IP 주소는 모두 10.2.x.x

 

- action

* 4번으로 forward => s2로 보내기 위해

 

3. s2의 flow table

 

<h3에게 보낼 때>

- match

* ingress port = 2 => s1로부터 들어오기 때문에

* IP Dst = 10.2.0.3 => h3의 주소

 

- action

* 3번으로 forward => h3으로 보냄

 

<h4에게 보낼 때>

- match

* ingress port = 2 => s1로부터 들어오기 때문에

* IP Dst = 10.2.0.4 => h4의 주소

 

- action

* 4번으로 forward => h4으로 보냄

 

 

=> 이렇게 전통적인 방법에서는 볼 수 없던, router 별로 flow table을 두어 행동을 일관되도록 하는 방법이 openflow 방식이다.

 

 

(예시 2)

 

만약 h3과 h4가 동시에 s1로 보내고 싶을 때,,

두 가지가 같은 route를 사용하므로 버거울 수 있다.

load balancing을 해야 하는데 

다음과 같이 하면 된다.

h3 -> 10.1.*.* 하려면) s2 -> s1

h4 -> 10.1.*.* 하려면) s2 -> s3 -> s1

따라서 flow table 내용은 다음과 같으면 된다.

<h3으로부터 올 때>

- match

* ingress port = 3 => h3으로부터 온 것은 3으로 들어오기 때문

* IP Dst = 10.1.*.* => s1에 묶인 h1,h2의 IP 주소는 모두 10.1.*.*

 

- action

* 2번으로 forward => s1로 보냄

 

<h4로부터 올 때>

- match

* ingress port = 4 => h4으로부터 온 것은 4로 들어오기 때문

* IP Dst = 10.1.*.* => s1에 묶인 h1,h2의 IP 주소는 모두 10.1.*.*

 

- action

* 1번으로 forward => s3로 우선 보내야 하기 때문

 

 

(예시 3) firewall

만약 s3로부터 오는 것만 받고 싶을 때,, => s1에 속한 h1,h2 에게 아예 match entry를 안 주면 된다. => drop

 

<s3으로부터 올 때>

1. h3으로 보내야 할때

- match

* IP Src = 10.3.*.*

* IP Dst = 10.2.0.3 => h3의 IP주소

 

- action

* 3번으로 forward => h3로 보냄

 

2. h4으로 보내야 할 때

- match

* IP Src = 10.3.*.*

* IP Dst = 10.2.0.4 => h4의 IP주소

 

- action

* 4번으로 forward => h4로 보냄

 

 

<s1로부터 올 때>

Src에 없음 !! => drop

 

 


정리

 

 

이런 식으로 match+action만으로 많은 device의 역할(Router/Switch/Load Balancing/Firewall/NAT/DPI)을 대신 수행할 수 있게 된다.

=> 여태까지는 middlebox를 통해 부가적인 기능들(Load Balancing/Firewall/NAT/DPI)을 해야 했는데 match+action은 하나의 장비로 가능케 함

 

Router

- match: longest destination IP prefix

- action: forward out a link

 

Switch

- match: destination MAC address

- action: forward or flood

 

Load Balancing

- match: destination address

- action: forward more than one output port leading to a service

 

Firewall

- match: IP addresses and TCP/UDP port numbers

- action: permit or deny

 

NAT
- match: IP address and port

- action: rewrite address and port

 

DPI(Deep Packet Inspection)

- match: IP address and port

- action: send matched packet to a special server for further processing and action