Router & Routing Protocol

우선 라우터에 대해 생각을 해보자. 라우터의 구성요소는 크게 어떻게 되어있을까?

• 인터페이스
• Buffer(Incoming, Outgoing)
• CPU(Processing module) - 버퍼에서 버퍼로 패킷을 옮김.
• Routing Table
• Routing Protocol Module - Routing Protocol을 진행하여 Shortest Path를 찾아 Routing Table Entry를 채움.

여기서 Routing Protocol Module을 자세히 보자. Routing의 궁극적인 목적은 목적지까지 가는 가장 좋은 길 혹은 가장 빠른 길을 찾는 것이다. 그래서 라우터는 어떤 패킷을 받았을 때, 이 패킷을 어디로 보낼 지를 결정해야 한다. 라우터가 패킷을 어디 인터페이스로 보내느냐에 따라 해당 패킷이 거치는 경로가 달라지기에, 가장 최선의 길로 이 패킷이 이동할 수 있도록 결정해야 한다.

이 판단은 Routing Table이 있어야 가능하다. 이때, Routing Table에 Entry들을 구성하기 위해 Routing Protocol이 존재했다. RIP이나 OSPF와 같은 프로토콜들이 진행되면서 Router Link LSA, Network Link LSA를 만들어 Flooding하게 되고 이후 Dijkstra 같은 알고리즘이 구동되어 Shortest Path를 구성하게 된 후, 이를 바탕으로 라우터는 Entry를 채워놓게 된다.

Tranditional Control Plane

이렇게 Router들이 패킷을 받으면 Routing Table Entry를 lookup하는 것을 match라고 하고, match의 결과로 패킷을 어느 버퍼로 옮길 지 결정한 후에 패킷을 Outgoing buffer로 옮기는 것을 action이라고 한다. 이러한 Routing Protocol은 라우터들 각각에서 동작된다.

지금까지는 Destination Address를 보고 match 후 action을 진행했다. 그러나, 일반적으로는 Destination address 뿐만 아니라 Source address, Protocol field, Port 번호 등 Destination address만 고려하는 것이 아니라 여러 요소들을 한번에 고려해야 한다.

즉, 똑같은 Source에서 똑같은 Destination로 가도 패킷의 경로가 다를 수도 있다는 말이다. 또한, Cost가 동일하다면 양쪽으로 트래픽을 나누어 보내는 Load balancing을 수행하기도 하고, 패킷에 문제가 있거나 위험한 패킷이라고 판단이 들면 Discard 시키는 등 application layer까지도 고려해야 한다. 이렇게 실제로는 여러 Action들이 존재한다.

이렇게 Routing Protocol 내지는 다른 여러 Action들은 전부 "오버헤드"라고 말할 수 있다. 그렇지만, 실제 패킷을 잘 보내기 위해 사용하는 오버헤드이기 때문에 필수적인 오버헤드이다. 이런 정보들을 Control Information이라고 하고, 이런 것들을 관리하는 곳을 Control Plane이라고 한다.

Network-Layer-Post
Control Plane의 경우 Network Layer의 한 부분으로 이 포스트에서 확인할 수 있다.

SDN (Software Defined Network)

그러나, 기존 방식에서는 라우터들마다 모두 Routing Protocol을 구동시켜야 했다. 이 방식에서 벗어나 굳이 라우터들이 이러한 오버헤드를 처리하지 않고 따로 서버를 하나 두고 이 서버에서 모든 LSA를 받아 오버헤드들을 계산하고 다시 라우터들에게 계산 결과를 reply 해준다면 어떨까? 하는 접근이 대두되었다.

이렇게 되면 Dijkstra 알고리즘을 계산하는 기능을 라우터들이 모두 가지고 있는 것이 아니라 서버 하나에서 이들을 처리하게 해준다면, 라우터는 훨씬 가벼워지게 된다. 이런 접근을 SDN Approach라고 한다. 라우터는 이제 서버로 LSA를 보내주기 위해서 Agent라는 프로그램만 가지고 있으면 된다.

그러면 라우터가 할 일은 서버에 LSA를 보내 서버가 보내준 Response를 Routing Table에 넣기만 하면 된다. SDN에서도 역시 소스와 목적지가 같아도 다른 경로로 보내거나 Load balancing하는 등의 action들이 가능하다.

이제는 라우터에 Routing Protocol이 없게 되었다. 즉, RIP이나 OSPF 과정들 중 일부만을 라우터에서 시행하고 나머지는 서버에서 돌리는, 그저 Control Plane이 없는 라우터가 되고, 이 정보를 받아오는 테이블은 이제 Flow table이라고 한다. 근데 그냥 Routing Table이라고 불러도 무관하다.

최근 나오는 네트워크 관련 논문들의 70% 이상의 논문들은 전부 SDN과 관련한 논문들이다.

OpenFlow

이러한 SDN approach에서도 표준이 필요하다. 제작사가 모두 달라도 통신은 되어야 하기 때문에 프로토콜의 표준이 필요해지는데, 이 표준 프로토콜을 OpenFlow라고 한다.

이것은 네트워크 스위치나 라우터에 Forwarding Plane의 Access를 제공하여 Routing Table Entry를 제공하는 통신 프로토콜이라고 정의할 수 있다. 서버는 네트워크 컨트롤러에서 Path를 계산하고, 다시 Router에게 계산 결과를 내려준다.

OpenFlow Switch에서도 Packet이 들어오면 Flow Table을 lookup하는 match를 수행하고, 패킷을 특정 버퍼로 옮기거나, 버리거나, 헤더를 일부 수정하는 등의 action을 수행할 수 있다. 즉, 실제 패킷을 보내는 Data Plane은 똑같다.

예를 들면, 이렇게 할 수 있다.

이걸 OpenFlow 형식에 맞춰보면

다음과 같이 플로우를 진행할 수 있다. 이런 것들은 SDN에서 라우터, 즉 Control Plane이 없는 라우터에서 가지고 있다. 라우터에서 Data plane만 가지고 있는 라우터는 Switch라는 이름으로 불린다.

OpenFlow가 적용된 네트워크 사진을 보자.

이 경우는 Congestion이 발생하지 않게 Source에 따라 Load balancing을 해준 모습이다. 이처럼 Shortest path가 아니더라도 특정 경로로 보내고자 하는 관리자가 트래픽에 개입하는 것을 Traffic Engineering이라고 한다.

이 외에도 Firewalling, 즉 방화벽 개념처럼 특정 라우터로부터는 패킷을 받고 싶지 않다면 Flow table에 해당 라우터에 대한 정보는 입력하지 않게 하여 자연스럽게 패킷이 Discard 되도록 할 수도 있다.

SDN Control Plane

그러면 SDN처럼 Control Plane을 서버에서 따로 관리하는 방식의 장점은 뭘까?

우선, 기존 방식에서는 라우터마다 네트워크 관리자가 설정을 모두 해줘야 했다. 그러다보니 의도치 않은 실수가 발생할 수도 있는 등 문제가 생길 수 있었다. 그래서 이걸 프로그래밍을 통해 해결하려고 한 것이다.

또한, 기존 OSPF나 RIP같은 Routing Protocol들은 Load balancing을 수행할 수 없었다. 그러나, SDN에서는 Match에서 Source address, Ptorocol field, Transport address(Port) 등을 고려하기 때문에 Load balancing이 가능해진다.

게다가, Shortest Path가 아닌 특정 경로를 선택하게 하는 Traffic Engineering도 가능해진다라는 것이다.

SDN Layer

SDN의 요지는 라우터의 무거운 기능들을 각기 분리하여 다른 부분들로 나누었다는 점이다.

• Data plane switches
  Data plane에 해당하는 부분으로 Forwarding을 위한 기능만이 존재한다. 여기 switch들은 Flow table과 통신을 위한 프로토콜을 가지고 있다.
• SDN Controller
  Control plane에 해당하며 이 부분을 Network OS라고 부르기도 한다. 이 컨트롤러는 네트워크와 관련된 정보를 받아 처리하는 기능을 가지고 있다.
• Network-control apps
  Control Plane에 해당하며 애플리케이션 라우팅 프로토콜이나 Access Control, Load balancing 등과 같이 실제 애플리케이션에서 동작할 수 있는 기능들을 가지고 있는 Application layer에 속한다.

이러한 장치들은 서로 독립된 장치들이기 때문에 프로토콜들이 전부 정해져 있어야 하고, 이 프로토콜이 확실하게 정해져 있기 때문에 이를 올바르게 따르기만 한다면 각기 다른 회사에서 이 장치들을 따로 만들어도 된다. 이 프로토콜 표준은 OpenFlow를 많이 사용한다고 앞에서 이미 기술한 바 있다.

또, 오른쪽 그림같은 경우는 이런 SDN을 일반화시킨 것으로, 이를 NFV(Network function virtualization)이라고 한다.

NFV 같은 경우는 ONOS, OpenDaylight(ODL)이라는 단체에 따라 표준화된 NFV에 약간의 차이가 존재한다.

이 SDN을 구축하는 것은 인터넷에서 검색을 통해 쉽게 알아낼 수 있다. 이후, 필요한 어플리케이션에는 어떤 것들이 있고 어떻게 구현해야 할까? 라는 질문들을 던질 수 있다. 이런 고민들을 찾아나가는 것들이 이제 논문이 되고, SDN 자체 또한 오픈 소르로 되어있기 때문에 이 코드를 분석하는 것만으로도 자신의 잠재력과 시장 가치가 상승하게 된다. 기회가 된다면 꼭...
ONOS : https://github.com/opennetworkinglab
OpenDaylight : https://github.com/opendaylight