Generalized Forward and SDN - OpenFlow

IP와 SDN의 차이

IP : 목적지 기반 (destination based forwarding)

SDN : generalized forwarding

 

IP : look up & forwarding

SDN : match-plus-action

 

Logically centralized control plane

A distinct (typically remote) controller interacts with local control agents (CAs)

각 control agent(CA)는 

remote controller에게 상태 정보를 전달

즉 forwarding에 사용할 테이블을 따로 가기에 control , data plane이 분리 됨

SDN 네트워크에서는
루트 계산을 하는 device와
forwarding을 하는 device가 
물리적으로 서로 다른 device이다.

 

그럼 remote controller는

openflow 표준 프로토콜에 따라 테이블 대로 계산하여 forwarding

 

generalized라고 하는 이유는

목적지 주소만이 아니라

header의 multiple field로 flow라는 개념을 가지고

forwarding을 함

flow table에 각 flow 별로 정의

 

Flow Table : software-defined networking (SDN)

각 router는

logically centralized routing controller에 의해 계산/분배되는

flow table을 보유

 

목적지 주소와 포트 외의 정보까지 포함

2,3,4 layer의 필드들을 복합적으로 매치 시킴

즉 match+action

 

controller에 의해 계산되고 분배된 router 속  flow table은

router의 match+action rule을 정의한다

SDN 네트워크에서
incoming packet에 대한 action을 결정하기 위해
match 대상이 되는 것은 
2, 3, 4 계층 모두에 대해
헤더의 필드들 중 선택적으로 match 가능

 

action의 종류

- 여러 필드 정보를 복합적으로 가져오니 다양한 action이 가능

이들을 지원하기 위한 middlebox와 link-layer function가 필요

이런 기능을 각 end system에 두기 어렵기에 centralized routing 방식을 이용

• forwarding
• load balancing
• rewriting header (NAT)
• Blocking/dropping or deep packet inspection (Firewall)

switching 기능만 하면 되기에

router 외에도 다른 기기도 가능해서

router라고 부르지 않고 packet switch라고 부름

 

• match: IP address and port
• action: rewrite address and port
 별도의 NAT 장비가 아닌 SDN의 switch에서 NAT 기능을 구현할 수 있다.

 

전통적인 IP 네트워크의 data plane에서는
forwarding table을 사용해
destination address based forwarding을 한 것에 반하여 

SDN 네트워크에서는
flow table을 사용하여
flow기반의 generalized forwarding을 하게 된다.


전통적인 IP network에서는 
destination address가 동일한 packet은
반드시 동일하게 forwarding해야 했지만

SDN에서는 
목적지 주소가 동일함에도 불구하고 
다른 경로로의 forwarding이 가능하고,
load balancing도 가능하다

 

 

 

OpenFlow

data plane abstraction

flow는 header field에 의해 정의

== match == delivery에 대해 특정 속성을 공유하는 패킷 집단

 

generalized forwarding : simple packet-handling rules

• pattern : packet header fields 속 값과 match하는지
• actions : match된 packet을 drop, forward, modify하거나 controller에 send. prefix에 따라 어느 것인지 인식

• priority : 중첩된 pattern을 명확하게 하기
• counters : # bytes and # packets

 

Flow Table Entries

• rule: link, network, transport layer의 header 정보 보유
• action: forward, encapsulate, drop, send, modify
• stat(istic) : packet + byte counters

  

 

OpenFlow abstraction

match+action 방식으로 서로 다른 다양한 장치에서도 작동하도록 할 수 있다

 

router

• match: longest dest IP prefix
• action: forward out a link

switch

• match: dest MAC address
• action: forward or flood

firewall

• match: IP 주소, TCP/UDP port
• action: permit or deny

 

NAT

• match: IP 주소, port
• action: rewrite address and port

 

 

 

OpenFlow Example

Simple forwarding Example

host6 -> host4 경로에 다른 곳을 꼭 거쳐서 가야할 때

Load Balancing Example

Firewalling Example

ex)

1번 문제

128.119.40.128/26이라는 prefix를 가진 subnet이 가질 수 있는

하나의 IP 주소를 적어보자

 

2번 문제

128.119.40.64/26 형태의 주소 블럭을 소유한 ISP가 있다고 가정해보자

이 블럭으로부터 크기가 동일한 4개의 subnet을 만들어야 한다면? 

(00~11 = 2bit) 가 필요

 

3번 문제

2400 byte dategram을 700 byte의 MTU를 가진 link에 전송하려한다.

original datagram은 422로 식별할 수 있게 표시되어있다.

fragment area가 얼마나 생성됐을까?

IP datagram에서 fragmentation과 관련된 다양한 필드에는 어떤 값이 들어있을까?

 

각 fragment 속 data field의 최대 크기 = 680

• 왜냐하면 IP datagram에 20 byte는 기본적으로 잡아먹기 때문 (700-20)
• payload = 2400-20
• original 의 payload size // fragment의 payload size

  =  (2400-20)//680 = 4

그러므로 4개의 fragment가 생성되어야 함

 

각 fragment마다 (identification number , flag, offset , size)

• identification number = 422
• offset = 각 0, 85, 170, 255  <= 680/4만큼 덧셈
• 마지막 fragment 크기 = ((2400-20) - 680*3) + 20 = 340 + 20 = 360
• 마지막 fragment를 제외한 나머지 = 각 700 bytes 크기 (IP 헤더 포함)
• 처음 3개의 fragment의 flag는 1
• 마지막 fragment의 flag = 0