5.1 intriduction
Control Plane은 두형태가 존재한다.
1. 전통적 방식인 per-router control -> 라우터마다 라우팅 알고리즘이 구현되어 있는 상태
2. 최근방식인 logically centralized control -> software defined networking (SDN)
Per-router control
라우터들이 개별적으로 Routing Algorithm을 수행하며 정보를 주고받는다. 그리고 라우터별로 forwarding table을 유지하고 있다.
이것은 네비게이션과 비슷하다. 최단경로 또는 최저비용 또는 가장 혼잡하지 않는 경로를 알려준다. 즉 어떤 목적에 따라 경로를 정하는 것이다. 라우터에서도 똑같이 목적에 따라 Routing Algorithm을 설계할 수 있다.
여기서 Routing하는 부부은 control plane이고, forwarding하는 부분은 data plane이다.
logically centralized control plane
원격으로 떨어져 있는 controller가 각각의 local control agent(CA)와 상호작용한다. CA에서는 forwarding table을 계산한다. 라우터별로 CA가 있고, 중앙 Remote Controller에서는 CA로부터 정보를 받아서 Routing Algorithm을 수행한다. CA와 Remote Controller는 서로 상호작용 하면서 각각 라우터의 정보를 주고받을 수 있다.
5.2 routing protocols
라우팅 알고리즘의 분류는 static(정적), dynamic(동적) 으로 나뉜다. 이중 dynamic을 알아보자
Link state routing algorithm (링크 상태 라우팅 알고리즘) (global 라우팅 알고리즘)
링크 상태 알고리즘에서는 네트워크의 구성 topology(토폴로지)와 모든 링크 비용이 알려져 있어서 링크 상태 알고리즘의 입력값으로 사용될 수 있다.
=> 모든 노드들이 자신의 링크로 패킷을 네트워크상의 연결된 다른 모든 노드들에게 브로드캐스팅 한다.
=> 즉, 라우터는 네트워크 전체 상태 정보를 이용하여 모든 목적지 네트워크까지의 최적 경로를 계산한다. 또한 최적경로를 기반으로 각 네트워크에 대한 라우팅 테이블을 구성한다. (변화가 생기면 새로운 토폴로지 구성을 위해 전체 네트워크에게 자신의 상태를 통보한다.)
=> OSPF
Dijkstra's algorithm (다익스트라 알고리즘)
다익스트라 알고리즘은 음의 가중치가 없는 그래프를 가정하고, 모든 노드까지의 최단거리를 구하는 알고리즘이다.
다익스트라 알고리즘에서 최단 거리는 여러 개의 최단 거리로 구성된다. 하나의 최단 거리를 구할 때, 이전까지 구했던 최단 거리 정보를 그대로 사용한다는 특징을 가진다.
- D(a): 알고리즘의 현재 반복 시점에서 출발지 노드부터 목적지 a까지 경로의 최소 비용
- p(a): 출발지에서 a까지의 최소 비용 경로에서 a의 직전 노드
- N' : 노드의 집합 (최소 비용 경로가 확실하게 알려진)
단계를 몇개만 설명하자면
Step 0 : 노드집합 u // p(v) -> u에서 v까지 경로는 7이고 직전노드는 u // p(y) -> u에서 y까지 가는 경로없음 ∞
Step 1 : 노드집합 ux // p(v) -> u에서 v까지 경로 7과 w를 거쳐가는 경로 6이 존재 따라서 최소비용 6으로 설정 직전노드w p(w) -> 노드집합에 포함되어있으므로 설정x
Distance vector routing algorithm (거리 벡터 라우팅 알고리즘) (분산 라우팅 알고리즘)
네트워크 전체 정보를 이용하는 링크 상태 알고리즘과 달리 각각 라우터는 자신이 속한 네트워크 상태 정보로 거리정보를 갱신하며 이웃 라우터와 공유한다. 분산적, 반복적, 비동기적 알고리즘이다.
=> 각 라우터는 자신의 정보를 이웃하고만 공유, 주기적으로 정보 업데이트
=> BGP, RIP
Bellman-Ford algorithm (벨만-포드 알고리즘)
한 노드에서 다른 노드까지 최단거리를 구하기 위해 사용되는 알고리즘이다.
다익스트라 알고리즘과는 다르게 가중치가 음수인 경우에도 사용이 가능하다는 장점을 지니지만 시간 복잡도가 크기 때문에 가중치가 양수인 경우에는 사용될 이유가 없다.
네트워크에서는 간선의 비용이 음수가 될 수 없으나 라우팅 테이블의 크기가 적고, 간단하기 때문에 소규모 네트워크에서 사용되는 거리 벡터 라우팅 프로토콜에 사용되는 알고리즘이다.
- dx(y) : 노드 x부터 y까지 경로의 최소비용
- c(x,v) : x와 직접 접속된 이웃 노드중에서 v노드까지의 비용
u에서 z까지의 최소비용은 어떻게 될까?
명백하게, dv(z) = 5, dx(z) = 3, dw(z) = 3 인것을 볼 수 있다. 식에 대입해보면
du(z) = min { c(u,v) + dv(z), c(u,x) + dx(z), c(u,w) + dw(z) }
= min { 2 + 5 , 1 + 3 , 5 + 3 } = 4
5.3 intra-AS routing in the Internet
Intra-AS routing (AS 내부 네트워크), (= interior gateway protocol (IGP))
링크 상태 라우팅을 사용하고 다익스트라 최소 비용 알고리즘을 사용한다.
- 링크의 상태 변화가 있을 때만 AS내 모든 라우터에게 알려준다.
- Convergence time이 상대적으로 빠르다.
- 라우터 회사가 달라도 사용 가능하다는 개방형과 , 확장성, 보안성의 장점
- Broadcasting 방식으로 갱신 정보를 빨리 전파한다.
2. RIP (Routing Information Protocol)
단순화된 거리 벡터 라우팅 알고리즘을 사용한다.
초창기 인터넷에 사용되었다가 현재는 거의 사용하지x => 보안문제 취약
5.4 inter-AS routing in the Internet
Inter-AS routing (AS 외부 네트워크), (= Exterior Gateway Protocol (EGP))
1. BGP (Border Gateway Protocol)
BGP는 두가지 타입이 있다.
- eBGP (External BGP) : AS간 BGP 연결 -> 이웃 AS로부터 서브넷 도달 가능성 (reachability)정보 확보
- iBGP (Internal BGP) : AS 내의 BGP 연결 -> 같은 AS내 라우터 간 도달 가능성 (reachability)정보 전파
1c - 2a 와 2c - 3a 가 서로 메시지를 주고 받아서 연결을 만들었다. 이웃 AS간에 연결이 만들어졌는데, 이를 만드는 것이 eBGP가 하는 것이다.
1c 입장에서는 2a가 내게 연결되었다는 사실을 AS1 내부에 공유할 필요가 있다. 그래야 내부에서 외부로 나가는 어떤 데이터를 받았을 때 1c 라우터를 통해 밖으로 내보낼 수 있다는 것을 알 수 있기 때문이다. AS 내부에서 하는 것이 iBGP에서 하는 것이다.
- BGP session : 두개의 BGP 라우터가 semi-permanent TCP connection을 통해서 서로 메시지를 교환하는 것이다. 이것을 통해 다른 목적지로 가는 경로를 advertising(광고)할 수 있다.
X라는 네트워크가 3d에 붙은 상황이다. 그러면 3d는 X하고 붙었다고 iBGP를 통해서 내부에 broadcast한다. 3a가 이를 받고, 3a는 2c에게 AS3는 X하고 연결되어 있다고 알려준다. (AS3,X) 즉, 3a는 2c에게 X로 데이터를 forward할 수 있다고 약속하는 것이다.
- Path attributes (경로 속성)
내가 붙어있는 것에 대한 속성에 대해서 하나의 route를 형성하게 된다. 그래서 이 속성에는 두가지 종류가 있다.
1. AS-PATH : prefix advertisement하는 것을 통해서 AS들의 list가 붙는 것. (ex. X)
2. NEXT-HOP : 어떤 특정 내부의 AS 라우터가 그 다음 HOP AS로 간다는 정보. (ex. 2c)
X가 AS3에 붙은 상황이다.
3a는 X와 연결되었다는 정보(AS3,X)를 2c에게 알려주고 2c는 이를 받는다. AS2는 AS2 policy를 가지고 이것을 받아서 X로 가는 경로를 AS2 내부에 퍼트릴지 말지 결정한다. 퍼트린다고 하면 AS2 routers는 AS3,X를 accept한다.
그러면 같은 policy를 가지고 2a는 이것을 다른 AS에게 보낼지 말지 결정한다. 결정되면은 바깥에 advertise를 한다. 그래서 AS2,AS3,X를 전파한다. 경로를 하나씩 붙여나가는 것이다. AS1은 X로 보내는 데이터는 우선 AS2로 보내면 되겠다고 알게 된다.
AS1에서 AS3로 가는 길이 있는 경우. 1c 입장에서는 X로 가는 경로를 AS2와 AS3로부터 받아 X로 가는 경로가 두개가 있다. AS2와 AS3로부터 정보를 받았다. 둘 중에 어느 경로로 보낼까? 1c는 어떤 경로를 선택해서 iBGP를 통해 내부에 알린다. 자세한 것은 뒤에서 배운다.
- BGP message
BGP message는 TCP로 라우터들 간에 연결되어 있다. BGP message에는 네가지 타입이 있다.
- OPEN : TCP conntection을 open하는 메시지. 다른 라우터와 연결하게 되는 경우, 상호 인증을 하게 된다.
- UPDATE : 새로운 path에 대한 advertise를 업데이트라는 메시지를 통해 전달된다.
- KEEPALIVE : 업데이트가 없는 경우에 서로 주고받는게 없다면, 서로 살아있는지 죽어있는지 알 수가 없다. 그래서 서로 살아있다는 사실을 주기적으로 가끔 메시지를 보내서 알려준다.
- NOTIFICATION : 이런 메시지를 보냈는데 에러가 나거나, connection을 닫을 때 사용한다.
- BGP & OSPF forwarding table entries
BGP, OSPF가 적용됐을 때 forwarding table entries를 살펴보면
1a, 1b, 1d 전부 X로 가는 경로를 1c를 통해 알게 된다.(iBGP). 1d에서 OSPF를 통해 X로 가려면 1번 인터페이스로 가는 것이 기록되어 있다. 1a는 X로 가는 것은 2로 가면 된다는 table이 있다.
그 다음 경로 선택을 BGP에서는 어떻게 해줄까? 복수의 경로가 있는데 어느 경로를 선택할까. 이것은 여러가지 기술로 가능하다.
1. 어떤 policy를 가지고 결정한다. 내부 policy를 만들어서 이 규칙으로 결정한다.
2. 가장 가까운 AS-PATH를 통해 간다.
3, hot potato routing으로 자신의 라우터를 기준으로 최소 비용 으로 결정된다.
4. 다른 추가적인 기준을 가지고 할 수 있다. 기타 등등..
AS1과 AS3로부터 X의 연결 정보를 받는 상황.
2d는 2a와 2c로부터 정보를 받아, 2d는 2a와 2c 양쪽으로 보내도 된다는 것을 알게 된다. Hot Potato Routing에서는 자신의 라우터를 기준으로 적은 cost의 길을 선택한다. 여기선 2a의 cost가 적으니 2a에게 보내게 된다. 그러면 최종 경로는
2d-2a-1c-3a-3d-X 가 된다.
뜨거운 감자를 손에 쥐면 빨리 내던지게 된다. 이것과 같은 원리로 2d도 빨리 내던져야 하는데, 일단 cost가 가장 적은 2a한테 던져버리는 것이다.
- BGP achieving policy
A는 w가 자신에게 있다고 B와 C에게 알린다. 그리고 B는 이웃들에게 BGP 메세지를 알리는데 C에게 알릴 필요가 있을까? 그렇지 않다. 동일한 계급의 ISP 끼리는 상호 패킷을 알리지 않는다. (교수님 왈 국제적 국룰이라고 함)
policy 는 외부 네트워크인 inter-AS 간에 유효하다. 자기를 통과하는 것에 대한 control을 어떻게 해줄것인지에 대해 inter-AS간에 policy를 통해서 control할 수 있다. 내부 네트워크인 intra-AS는 같은 계급의 서비스 사업자가 하기 때문에 policy가 필요없다.
Intra-AS vs Inter-AS
1. Policy
- intra-AS : 같은 계급의 서비스 사업자 + 단일관리자 이기 때문에 policy가 필요 없다.
- inter-AS : 트래픽의 경로를 제어하기위해 policy가 필요하다.
3. Performance
- intra-AS : 성능과 관리가 중요하다.
- inter-AS : policy가 성능보다 우위에 있을 수 있다.
5.4 The SDN control plane
SDN (Software Defined Network)
SDN는 기존에 자유롭게 활동하던 라우터들을 한데 묶어 중앙 집중형으로 제어할수 있도록 하는 네트워크 가상화 접근 방식이다. 즉, 중앙에서 전체 네트워크를 제어하고 관리하는 것이다.
SDN에서 가장 핵심은 네트워크 장비의 Control Plane(제어부)와 Data Plane(전송부)의 분리이다.
Control Plane은 네트워크 장비를 제어하는 뇌에 해당하고, Data Plane은 데이터를 전송하는 역할을 하는 것이다.
- 작동원리
1. 각 라우터들은 flow table을 가지고 있다.
2. control plane과 data plane을 분리하였다.
3. control plane은 data plane의 스위치들로하여금 기능들을 보낸다.
4. control plane에는 이미 존재하는 여러 애플리케이션들을 활용한다.
Remote Controller는 local flow table을 만들어 data plane에 있는 라우터들에게 분배한다.
SDN 3계층
1) network-control apps (= 네트워크 제어 애플리케이션 계층)
컨트롤의 '뇌' 역할을 하며, SDN 컨트롤러에서 제공받은 API와 여러 서비스들을 이용해 제어 기능을 구현한다.
내부에 있는 app들은 분산되어 필요에 따라 쓰인다.
2) SDN controller (network OS에 해당) (= 네트워크 전역 상태 관리 계층)
위에 있는 network-control apps과 밑에 있는 data plane의 스위치들과 상호작용한다.
이들은 네트워크 상태 정보를 모두 가지고 있기 때문에 성능을 위한 분산 시스템, 문제에 대해 견디는 능력 등을 구현한다.
3) Data plane switches (= 통신 계층)
이들은 스위치 기능을 해주는 하드웨어이다. 이미 위에 컨트롤 장치들이 존재하기 때문에 단순히 포워딩만 하는 기능을 한다.
(flow table도 위에서 내려받기 때문에 밥숟가락만 들면 된다!)
OpenFlow protocol
OpenFlow protocol은 앞서 설명한 data plane과 control plane 사이의 프로토콜이다.
OpenFlow는 SDN을 구현하기 위한 기술 중 하나로, 컨트롤러와 스위치 사이에서 어떻게 동작하는지를
정의해 놓은 프로토콜이며 TCP를 사용하여 메시지를 교환한다. 메시지 종류에는 세가지가 있다.
1. Controller - to - switch messages
Controller에서 switch로, 위에서 아래로 내려가는 것이다. 이 때는 어떤 message가 내려갈까?
- features : controller가 switch features에 대한 쿼리를 보내서 switch가 응답한다.
- configure : controller가 parameter를 설정한다.
- modify-state : OpenFlow tabale을 추가, 삭제 및 수정한다.
- packet-out : controller가 switch port에서 패킷을 전송한다.
2. Switch - to - controller messages
switch에서 controller로, 아래서 위로 올라가는 messages이다.
- packet-in : 패킷을 controller에다가 전달한다.
- flow-removed : switch에 있는 flow table entry를 삭제한다.
- port status : controller에 port변경사항을 알린다.
3. 예외 메시지
Open
PC를 생각했을 때 PC는 맨 밑에 하드웨어가 있고, 그 위에 OS, 그 위에 Application이 있다. 하드웨어도 여러 종류, OS도 여러 종류, Application도 여러 종류이다. 이럴 때 맨 아래 Microprocessor 위에 Open Interface를 만들면, 그 위에 어떤 OS가 돌아가도 작동한다. OS와 Application 사이도 마찬가지다.
innovation이 급격하게 이루어지고 있고, 산업도 상당히 커져서 Open Interface는 꼭 필요하다.
Traffic engineering
traffic이 한번에 많이 들어 왔을 때 잘 관리해주기 위한 기술이다.
u에서 z로 보내려면은, 기존에는 라우팅 돌려서 경로를 결정해야한다. 그런데 역으로 생각해서 경로를 먼저 정해주고 보내주는 것은 어떨까?
예를 들면 u-z로 보낼 때 uvwz를 통해서만 traffic을 지나갈 수 있게 경로를 만들어주려고 한다. 그리고 x-z로 보낼 때 xwyz를 통해서만 지나갈 수 있게 만드려고 한다. 이것은 기존 라우팅 프로토콜로 불가능하다.
=> 이런 경로를 SDN에서 프로그래밍 해주는 것이다.
u-z로 보내는데 traffic을 분할하고 싶다. 절반은 uvwz로, 절반은 uxyz로. 이것은 load balancing하는 것인데, 라우팅 알고리즘이 두개 필요로 하게 된다. 그래서 기존 라우팅 프로토콜은 불가능하다.
=> 이런 경로를 SDN에서 프로그래밍 해주는 것이다.
5.6 ICMP: Internet Control Message Protocol
ICMP (Internet Control Message Protocol)
ICMP는 TCP/IP에서 IP 패킷을 처리할 때 발생되는 문제를 알려주는 프로토콜이다.
IP에는 오로지 패킷을 목적지에 도달시키기 위한 내용들로만 구성되어 있다. 따라서 정상적으로 목적지 호스트로 도달하는 경우 IP에서 통신이 성공하고 종료되므로 아무런 문제가 없다.
하지만 전달해야 할 호스트가 꺼져 있거나, 선이 단절된 비정상적인 경우 이 패킷 전달을 의뢰한 출발지 호스트에 이러한 사실을 알려야하지만, IP에는 그런 에러에 대한 처리 방법이 명시되어있지 않다.
이러한 IP의 부족한 점을 메꾸기 위하여 사용되는 것이 ICMP 프로토콜이다.
즉, ICMP는 도착지 호스트가 없거나, 포트가 닫혀 있는 등의 에러 상황이 발생할 경우 IP헤더에 기록되어 있는 출발지 호스트로 에러에 대한 정보를 보내주는 역할을 한다.
에러메세지로는 dest. network unreachable -> 목적지에 도달하지 못함 등이있다.
5.7 Network management and SNMP
관리를 받는 device들 (router, switch, host 등) 을 각각의 managed device라고 하면 이 device들이 데이터를 전달해서 하나의 어떤 관리체계를 만든다. 이를 Management Information Base (MIB)라고 부른다. 이 MIB 내에 모든 각각 device들의 object들의 현재 상태들이 저장이 된다.
각각의 host들이 하나의 agent이고, 그 안에 data가 있다. 그러면 위 그림의 위쪽 managing entity가 있고, MIB를 실행하는 것이 필요하다. (server일 수도 있다.) 이 컴퓨터에서 managing entity가 MIB를 전부 관리하게 되고 agent와 상호 작용하여data들을 가져온다.
managing entity와 managed device간에 주고받는 것에 대한 프로토콜이 필요해지는데 이 프로토콜의 대표적인 예로 SNMP가 있다.
SNMP ( Simple Network Management Protocol)
IP 기반 네트워크상의 각 호스트로부터 정기적으로 여러 관리 정보를 자동으로 수집하거나 실시간으로 상태를 모니터링 및 설정할 수 있는 서비스 프로토콜이다.
MIB 정보를 보내는 방법에는 두가지가 있다.
1. request/response mode : managed device 각각에 request 보내서 response하는 일반적인 방법
2. trap mode : 어떤 변화가 생겼을 때 데이터들을 같이 유지하는 방법이다. 자기가 갖고 있는 entity가 변화가 생겼을 때, 변화에 대한 것들을 managing entity 서버에 전달해준다. 특별하고, 예외적인 상황을 보고해주는 방법이다.
message type 정의이다.
'CS > 컴퓨터 네트워크' 카테고리의 다른 글
| Chapter 7 Wireless and Mobile Networks (2) | 2023.06.15 |
|---|---|
| Chapter 6 링크계층 (The Link Layer and LANs) (2) | 2023.06.06 |
| Chapter 4 네트워크 계층 (The Data Plane) (0) | 2023.06.03 |
| Chapter 3 전송계층 (Transport Layer) (0) | 2023.04.18 |
| Chapter 2 어플리케이션 계층 (Application Layer) (0) | 2023.04.10 |
댓글