
## 📡 OpenFlow


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-05-31_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_10.16.42.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236228899-0)
SDN(Software-Defined Networking)은 네트워크 제어를 중앙에서 통합적으로 수행하는 구조다. 각 스위치는 단순히 패킷을 전달하고, 네트워크 전체를 어떻게 구성하고 제어할지는 하나의 중앙 컨트롤러가 결정한다. 이렇게 제어 평면과 데이터 평면을 분리한 구조는 유연하고 강력하지만, 여기서 한 가지 중요한 의문이 생긴다.


컨트롤러는 스위치에게 어떤 방식으로 명령을 전달할까? 예를 들어, ‘이런 조건의 패킷은 포트 3번으로 보내라’는 지시를 실제로 어떻게 전달하는 걸까?


바로 이 역할을 수행하는 것이 OpenFlow다. OpenFlow는 SDN 구조 안에서 컨트롤러와 스위치 사이의 통신을 담당하는 대표적인 프로토콜로, 컨트롤러가 계산한 포워딩 정책이나 트래픽 제어 명령을 스위치에 전달할 때 사용한다. 이 통신은 TCP 위에서 이루어져 필요에 따라 암호화도 적용할 수 있다.


OpenFlow는 하나의 명령어 묶음이 아니라, 컨트롤러가 네트워크 장비를 직접 제어할 수 있게 만들어주는 공식적인 언어라고 볼 수 있다. 스위치는 이 언어로 전달된 지시에 따라 내부 플로우 테이블을 수정하거나, 처리할 수 없는 패킷을 컨트롤러에게 다시 보내기도 한다.


이 글에서는 OpenFlow가 어떤 메시지들을 주고받으며, 실제로 컨트롤러와 스위치가 어떻게 협력하는지 하나씩 살펴본다. 이를 통해 SDN이라는 개념이 실제 네트워크에서 어떤 방식으로 구현되는지를 구체적으로 이해할 수 있을 것이다.


### controller-to-switch 메시지


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-05-29_%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB_12.33.12.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236231986-1)
controller-to-switch 메시지는 컨트롤러가 스위치의 동작을 직접 제어하거나 정보를 요청할 때 사용한다. 이 메시지 유형에는 여러 가지가 있다. 

- `features` 컨트롤러가 스위치의 기능을 조회할 때 사용된다. 컨트롤러가 쿼리를 보내면, 스위치는 자신이 지원하는 기능을 응답으로 알려준다.
- `configure` 컨트롤러가 스위치의 구성 파라미터를 조회하거나 설정할 때 사용된다. 스위치의 동작 방식을 제어하거나 제한할 수 있다.
- `modify-state` 컨트롤러는 스위치의 OpenFlow 테이블에 있는 플로우 항목을 추가, 삭제, 수정할 수 있다. 네트워크의 라우팅 경로를 동적으로 조정하거나 특정 트래픽에 대한 제어 정책을 적용할 수 있다.
- `packet-out` 컨트롤러가 특정 패킷을 스위치의 특정 포트를 통해 외부로 직접 전송하도록 지시할 때 사용된다. 일반적으로 스위치가 처리하지 못한 패킷을 컨트롤러가 수신한 후, 컨트롤러가 그에 대한 응답으로 패킷의 전송 경로를 명시할 때 활용된다.

### switch-to-controller 메시지


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-05-29_%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB_12.34.07.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236234615-2)
OpenFlow에서 switch-to-controller 메시지는 스위치가 네트워크 상의 변화나 특정 이벤트를 컨트롤러에게 알릴 때 사용된다. 비동기적으로 전달된다. 컨트롤러가 네트워크 상태를 실시간으로 파악하고 적절한 제어 결정을 내린다.

- `packet-in` 스위치가 처리할 수 없는 패킷을 컨트롤러에게 전달할 때 사용된다. 이 메시지를 통해 패킷 자체와 함께 그에 대한 제어 권한도 컨트롤러로 넘어가며, 이후 컨트롤러는 packet-out 메시지를 통해 해당 패킷의 처리 경로를 지시할 수 있다.
- `flow-removed` 스위치 내 플로우 테이블에 등록된 항목이 삭제되었을 때 이를 컨트롤러에 알리는 역할을 한다. 이 기능은 플로우의 수명이나 정책 변화 등을 추적하는 데 유용하다.
- `port status` 스위치 포트의 상태 변화(예: 포트 연결 또는 해제, 오류 발생 등)를 컨트롤러에게 통지한다. 이를 통해 컨트롤러는 물리적 링크 상태를 포함한 네트워크 토폴로지의 변화를 감지하고, 필요한 경우 트래픽 경로를 재조정할 수 있다.

다행히도, 네트워크 운영자가 이러한 OpenFlow 메시지를 일일이 수작업으로 작성하고 전송해야 하는 것은 아니다. 실제 운영 환경에서는 컨트롤러가 제공하는 상위 수준의 추상화 계층과 API를 통해 메시지가 자동 생성되고 전달된다. 이러한 구조 덕분에 운영자는 효율적으로 네트워크를 제어할 수 있고, OpenFlow의 세부 구현에 대해 깊이 이해하지 않아도 된다.


### SDN Control Plane, Data Plane 상호작용 예시


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-01_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_2.40.44.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236237516-3)
SDN에서 control plane과 data plane이 상호작용하는 과정을 예시를 통해 살펴보면, 전통적인 링크 상태 라우팅 방식과 유사하지만 훨씬 더 유연하게 작동함을 알 수 있다. 


(1) 네트워크 내에서 스위치 S1이 링크 장애를 감지하면, OpenFlow의 `port status` 메시지를 사용해 컨트롤러에게 해당 사실을 통지한다. 이 메시지는 data plane에서 control plane으로 전달되는 첫 단계다.


(2, 3) 컨트롤러는 이 메시지를 수신하고, 내부적으로 관리하고 있는 링크 상태 정보를 갱신한다. 이때, 컨트롤러는 링크 상태나 토폴로지의 변화가 있을 경우 감지하고 반응할 수 있도록 사전에 등록된 애플리케이션을 호출할 수 있다. 예를 들어, Dijkstra 라우팅 알고리즘이 등록되어 있다면, 링크 상태 변화 이벤트가 발생할 때 자동으로 호출된다.


(4) 호출된 라우팅 애플리케이션은 컨트롤러 내부에서 유지되는 네트워크 그래프, 링크 상태 정보, 스위치 및 호스트 정보 등을 활용해 새로운 라우팅 경로를 계산한다. 이후 이 경로 정보에 따라 필요한 플로우 테이블이 다시 계산되고, OpenFlow 프로토콜을 통해 해당 스위치들에 반영된다. 이 전 과정은 RESTful API, 그래프 추상화, 통계 및 상태 정보와 같은 고수준 추상화를 통해 이루어지고 운영자는 전체 흐름을 명확하게 설계하고 통제할 수 있다.


![0d5259ce-9eec-497d-bc3a-9ddf14fcfb65.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236240687-4)
(5) 링크 상태 라우팅 애플리케이션은 SDN 컨트롤러 내의 플로우 테이블 계산 컴포넌트와 상호작용하게 된다. 이 컴포넌트는 갱신된 네트워크 상태 정보를 바탕으로 새로운 라우팅 경로를 계산하고, 그에 따라 각 스위치가 필요로 하는 플로우 테이블 항목을 다시 생성한다. 이때 라우팅 알고리즘은 전체 네트워크의 토폴로지를 전역적으로 파악할 수 있기 때문에, 장애 이후에도 최적화된 경로를 빠르게 재설정할 수 있다.


(6) 새롭게 계산된 플로우 테이블 정보는 이후 컨트롤러가 OpenFlow 프로토콜을 사용해 각 스위치에 전송한다. 이 과정을 통해 영향을 받은 스위치들은 기존의 경로 정보를 갱신하게 되고, 새로운 경로에 따라 패킷을 전달하게 된다.


### OpenDaylight (ODL)

> 모듈형 설계 + 다양한 프로토콜 지원 = 유연한 플랫폼

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-01_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_2.53.25.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236243862-5)
OpenDaylight(ODL) 컨트롤러는 모듈화된 아키텍처를 기반으로 다양한 네트워크 제어 기능과 서비스를 유연하게 지원하는 오픈소스 SDN 플랫폼이다. 가장 상위에는 트래픽 엔지니어링, 방화벽, 부하 분산 등과 같은 네트워크 오케스트레이션 기능 및 응용 애플리케이션이 위치하고 이들은 Northbound API를 통해 ODL 컨트롤러와 통신한다. 이 API 계층에서는 REST, RESTCONF, NETCONF와 같은 표준 인터페이스가 사용되어 외부 애플리케이션이 컨트롤러 내부의 데이터 및 기능에 접근할 수 있도록 한다.


그 아래에는 AAA(인증, 인가, 계정관리)와 같은 향상된 서비스와 함께 기본적인 네트워크 기능들이 구성된다. 이 기능 모듈에는 네트워크 토폴로지를 처리하는 모듈, 스위치 관리 모듈, 통계 정보 관리 모듈, 포워딩 룰 관리, 호스트 추적 모듈 등이 포함되어 있고 구성 데이터와 운영 데이터 저장소와도 연결된다. 이 계층은 네트워크의 상태를 파악하고 필요한 조치를 결정하는 중추적인 역할을 수행한다.


이 모든 기능들은 Service Abstraction Layer(SAL)을 통해 서로 연결된다. SAL은 내부와 외부의 다양한 애플리케이션 및 서비스 모듈들 간의 연결을 중개하는 계층으로, 모듈 간의 독립성과 재사용성을 높여준다. SAL은 특히 Southbound API와도 연결되는데, 이 하위 계층에서는 OpenFlow, NETCONF, SNMP, OVSDB 등의 프로토콜을 이용해 실제 네트워크 장비와 직접 통신이 이루어진다.


### ONOS

> 대규모 분산 네트워크에 적합한 컨트롤러

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-01_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_2.53.34.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236246424-6)
ONOS(Open Network Operating System) 컨트롤러는 고신뢰성과 확장성을 중심으로 설계된 SDN 플랫폼으로 대규모 네트워크 인프라에서의 안정적인 제어를 목표로 한다. ONOS 아키텍처의 특징 중 하나는 제어 애플리케이션이 컨트롤러와 분리되어 있다는 점이다. 라우팅, 방화벽, 트래픽 엔지니어링, 부하 분산 등의 네트워크 애플리케이션은 ONOS의 외부에서 동작하면서 Northbound API를 통해 컨트롤러와 통신한다.


ONOS는 Intent Framework를 통해 고수준의 서비스 명세 방식을 지원한다. 이 프레임워크는 “어떻게(how)”보다 “무엇을(what)” 중심으로 서비스를 정의할 수 있게 해준다. 예를 들어 운영자는 특정 두 호스트 간 연결을 요청하기만 하면 ONOS가 그 구현 방법을 자동으로 결정해준다. 네트워크 제어를 직관적이고 정책 중심의 네트워크 운용을 가능하게 한다.


내부적으로 ONOS는 분산 코어에 많은 비중을 두고 있고 서비스의 신뢰성, 상태 복제, 성능, 확장성 등을 보장하기 위한 기반이다. 코어는 다양한 상태 정보를 관리하는 모듈들(예: 디바이스, 링크, 호스트, 플로우, 패킷 등)로 구성되어 있으며, 이 정보는 애플리케이션이 필요한 제어 결정을 내리는 데 활용된다.


Southbound API 계층에서는 OpenFlow, Netconf, OVSDB 등의 프로토콜을 통해 실제 네트워크 장비와 상호작용한다. 이 계층도 추상화되어 있어서, 다양한 장비와 기술을 통합적으로 관리할 수 있도록 설계되어 있다. 전체적으로 ONOS는 구조적으로 견고하고 추상화 수준이 높다.



SDN Control Plane, Data Plane 상호작용 예시

SDN 안에서의 OpenFlow 역할과 동작 방식