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
'CS > Network' 카테고리의 다른 글
Routing Protocols : (RIP, OSPF / BGP) (0) | 2021.12.05 |
---|---|
Per-router control (traditional routing algorithm) - LS, DV, Hierarchical routing (0) | 2021.12.05 |
IP : Internet Protocol (0) | 2021.12.04 |
Router = Data Plane + Control Plane (0) | 2021.12.04 |
Overview of Network Layer (0) | 2021.12.04 |