KR101641496B1 - 소프트웨어 정의 네트워크에서 스위치의 상태 변경 방법 및 장치 - Google Patents

Abstract

본 발명은 소프트웨어 정의 네트워크에서 스위치의 상태를 변경하는 방법 및 장치에 대한 것으로, 복수의 스위치에 대한 플로우 룰 변경이 원자성을 가지는 경우, 상기 플로우 룰에 대해 하나의 식별 정보를 부여하는 단계; 상기 플로우 룰에 대한 변경 대기를 지시하는 메시지를 해당 스위치들에게 전송하는 제 1 변경 단계; 및 상기 변경 대기를 지시하는 메시지를 수신한 모든 스위치들로부터 변경 대기에 대한 성공 보고 메시지를 수신한 경우, 상기 플로우 룰에 대한 변경을 승인하는 메시지를 상기 스위치들에게 전송하는 제 2 변경 단계를 포함하는 것을 특징으로 한다.

Description

소프트웨어 정의 네트워크에서 스위치의 상태 변경 방법 및 장치 {METHOD AND APPARATUS FOR UPDATING SWITCH STATES OF SOFTWARE DEFINED NETWORK}

본 발명은 소프트웨어 정의 네트워크를 제어하는 방법 및 장치에 대한 것이다. 보다 구체적으로 본 발명은 소프트웨어 정의 네트워크의 컨트롤러 서버가 복수의 스위치의 상태 변경 시점을 제어하는 방법 및 장치에 대한 것이다.

SDN(Software Defined Networking, 소프트웨어 정의 네트워킹, 이하 SDN이라 칭함) 기술은 네트워크의 모든 네트워크 장비를 지능화된 중앙관리시스템에 의해 관리하는 기술을 의미한다. SDN 기술에서는 기존 하드웨어 형태의 네트워크 장비에서 자체적으로 수행하는 패킷 처리와 관련된 제어 동작을 소프트웨어 형태로 제공되는 컨트롤러가 대신하여 처리하게 함으로써, 기존의 네트워크 구조보다 다양한 기능을 개발하고 부여할 수 있다는 장점을 갖는다.

SDN 시스템은 일반적으로 전체 네트워크를 제어하는 컨트롤러 서버와, 상기 컨트롤러 서버에 의해 제어되며 패킷을 처리하는 복수의 오픈플로우 스위치와, 오픈플로우 스위치의 하위 계층에 해당하는 호스트를 포함하여 구성된다. 여기에서 오픈플로우 스위치는 패킷의 송수신 기능만을 담당하게 되고, 패킷의 경로 설정, 관리 및 제어는 모두 컨트롤러 서버에서 이루어진다. 즉, 네트워크 장비를 이루는 Data Plane과 Control Plane을 분리하는 것이 SDN 시스템의 기본 구조라 볼 수 있다.

그런데 특정한 경우에서는 상기에서 설명한 기본 SDN 시스템이 비효율적으로 동작하는 경우가 있다. 컨트롤러 서버는 오픈플로우 스위치에게 플로우 룰을 전달하여 패킷의 경로를 설정하고 제어하는데, 복수의 스위치의 업데이트, 즉 상태 변경이 완전히 동일한 시점에 발생하는 것이 아니기 때문에 임의의 플로우 룰에 관련된 각각의 스위치의 상태 변경 시점에 따라 패킷의 경로가 다르게 도출되는 경우가 그것이다. 이와 같은 예외 상황까지 모두 컨트롤러 서버나 어플리케이션에서 고려하도록 하는 것은 리소스를 불필요하게 사용하고, 네트워크 안정성을 저하시키는 요인이 될 수 있다.

본 발명은 SDN 환경에서 복수의 스위치의 상태 변경을 원자적(atomic)으로 처리하여 네트워크 운영의 신뢰성을 높일 수 있는 방법 및 장치를 제공하는 것을 목적으로 한다.

상기 문제를 해결하기 위하여 본 발명의 실시예를 따르는 소프트웨어 정의 네트워크에서 컨트롤러 서버가 스위치의 상태를 변경하는 방법은, 복수의 스위치에 대한 플로우 룰 변경이 원자성(atomicity)을 가지는 경우, 상기 플로우 룰에 대해 하나의 식별 정보를 부여하는 단계; 상기 플로우 룰에 대한 변경 대기를 지시하는 메시지를 해당 스위치들에게 전송하는 제 1 변경 단계; 및 상기 변경 대기를 지시하는 메시지를 수신한 모든 스위치들로부터 변경 대기에 대한 성공 보고 메시지를 수신한 경우, 상기 플로우 룰에 대한 변경을 승인하는 메시지를 상기 스위치들에게 전송하는 제 2 변경 단계를 포함하는 것을 특징으로 한다.

나아가 본 발명의 실시예를 따르는 소프트웨어 정의 네트워크에서 스위치가 패킷을 처리하는 방법은, 컨트롤러 서버로부터 플로우 룰에 대한 변경 대기를 지시하는 메시지를 상기 플로우 룰에 대한 식별 정보와 함께 수신한 경우, 상기 플로우 룰을 플로우 테이블에 대기 상태로 반영하고, 상기 컨트롤러 서버에게 변경 대기 성공 보고 메시지를 상기 식별 정보와 함께 전송하는 단계; 및 상기 플로우 룰이 적용되는 패킷을 수신한 경우, 상기 패킷을 패킷 저장을 위한 자료구조에 대기시키거나 또는 드랍(drop)하는 단계를 포함하는 것을 특징으로 한다.

한편 본 발명의 실시예를 소프트웨어 정의 네트워크에서 스위치가 패킷을 처리하는 방법은, 패킷을 수신하면, 플로우 테이블을 검색하여 매치되는 플로우 룰을 검색하는 단계; 및 상기 패킷에 매치되는 플로우 룰이 변경 대기 상태인 경우, 상기 패킷을 패킷 저장을 위한 자료구조에 대기시키거나 또는 드랍하는 단계를 포함하는 것을 특징으로 한다.

나아가 본 발명의 실시예를 따르는 소프트웨어 정의 네트워크에서 스위치를 변경하는 컨트롤러 서버는, 스위치와 정보를 송수신하는 통신부; 및 복수의 스위치에 대한 플로우 룰 변경이 원자성을 가지는 경우, 상기 플로우 룰에 대해 하나의 식별 정보를 부여하고, 상기 플로우 룰에 대한 변경 대기를 지시하는 변경 대기 메시지를 상기 식별 정보와 함께 해당 스위치들에게 전송하도록 제어하고, 상기 변경 대기 메시지를 수신한 모든 스위치들로부터 변경 대기 성공 보고 메시지를 수신한 경우, 상기 플로우 룰에 대한 변경을 승인하는 메시지를 상기 식별 정보와 함께 상기 스위치들에게 전송하도록 제어하는 제어부를 포함하는 것을 특징으로 한다.

한편 본 발명의 실시예를 따르는 소프트웨어 정의 네트워크에서 패킷을 처리하는 스위치는, 컨트롤러 서버와 정보를 송수신하는 통신부; 및 상기 컨트롤러 서버로부터 플로우 룰에 대한 변경 대기를 지시하는 변경 대기 메시지를 상기 플로우 룰에 대한 식별 정보와 함께 수신한 경우, 상기 플로우 룰을 플로우 테이블에 대기 상태로 반영하고, 상기 컨트롤러 서버에게 변경 대기 성공 보고 메시지를 전송하도록 제어하고, 상기 플로우 룰이 적용되는 패킷을 수신한 경우, 상기 패킷을 패킷 저장을 위한 자료구조에 대기시키거나 또는 드랍하는 제어부를 포함하는 것을 특징으로 한다.

나아가 본 발명의 실시예를 따르는 소프트웨어 정의 네트워크에서 스위치를 변경하는 처리를 실행시키기 위하여 매체에 저장된 컴퓨터 프로그램은, 복수의 스위치에 대한 플로우 룰 변경이 원자성을 가지는 경우, 상기 플로우 룰에 대해 하나의 식별 정보를 부여하는 기능; 상기 플로우 룰에 대한 변경 대기를 지시하는 변경 대기 메시지를 상기 식별 정보와 함께 해당 스위치들에게 전송하는 기능; 및 상기 변경 대기 메시지를 수신한 모든 스위치들로부터 변경 대기 성공 보고 메시지를 수신한 경우, 상기 플로우 룰에 대한 변경을 승인하는 메시지를 상기 식별 정보와 함께 상기 스위치들에게 전송하는 기능을 실행하는 것을 특징으로 한다.

나아가 본 발명의 실시예를 따르는 소프트웨어 정의 네트워크에서 패킷을 스위칭하는 처리를 실행시키 위하여 매체에 저장된 컴퓨터 프로그램은, 트롤러 서버로부터 플로우 룰에 대한 변경 대기를 지시하는 변경 대기 메시지를 상기 플로우 룰에 대한 식별 정보와 함께 수신한 경우, 상기 플로우 룰을 플로우 테이블에 대기 상태로 반영하고, 상기 컨트롤러 서버에게 변경 대기 성공 보고 메시지를 전송하는 기능; 및 상기 플로우 룰이 적용되는 패킷을 수신한 경우, 상기 패킷을 패킷 저장을 위한 자료구조에 대기시키거나 또는 드랍하는 기능을 실행하는 것을 특징으로 한다.

본 발명에 따르면, SDN 환경에서 복수의 스위치의 상태 변경을 원자적으로 수행할 수 있어 전체 네트워크 운영의 신뢰성이 높아지는 효과가 있다.

도 1은 소프트웨어 정의 네트워크의 구성을 설명하기 위한 도면
도 2은 종래 기술의 문제점을 설명하기 위한 도면
도 3는 본원발명의 실시예를 따라 스위치의 상태를 변경하는 구체적인 방법을 설명하기 위한 순서도
도 4는 본원발명의 실시예를 따라 스위치가 패킷을 처리하는 구체적인 방법을 설명하기 위한 순서도

본 발명은 이하에 기재되는 실시예들의 설명 내용에 한정되는 것은 아니며, 본 발명의 기술적 요지를 벗어나지 않는 범위 내에서 다양한 변형이 가해질 수 있음은 자명하다. 그리고 실시예를 설명함에 있어서 본 발명이 속하는 기술 분야에 널리 알려져 있고 본 발명의 기술적 요지와 직접적으로 관련이 없는 기술 내용에 대해서는 설명을 생략한다.

한편, 첨부된 도면에서 동일한 구성요소는 동일한 부호로 표현된다. 그리고 첨부 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시될 수도 있다. 이는 본 발명의 요지와 관련이 없는 불필요한 설명을 생략함으로써 본 발명의 요지를 명확히 설명하기 위함이다. 이하 첨부된 도면을 참조하여 본 발명의 바람직한 실시 예들을 상세히 설명한다.

도 1은 소프트웨어 정의 네트워크의 구성을 설명하기 위한 도면이다. 도 1을 참조하면, 소프트웨어 정의 네트워크(Software Defined Network)는 컨트롤러 서버(100), 네트워크 장비(200) 및 호스트(300)를 포함할 수 있다. 네트워크 장비(200)와 호스트(300)는 노드(Node)라고 지칭할 수 있으며, 링크(Link)는 2개의 노드 사이의 연결을 의미할 수 있다.

컨트롤러 서버(100)는 네트워크 장비(200)를 관리하는 기능을 하는 것으로, 복수의 네트워크 장비(200)를 중앙 집중형으로 관리 및 제어한다. 구체적으로 컨트롤러 서버(100)는 토폴로지 관리(Topology management), 패킷 처리와 관련된 경로 관리(Path management), 링크 디스커버리(Link discovery), 패킷 흐름인 플로우 관리(Flow management) 등의 기능을 하는 소프트웨어가 탑재된 형태로 구현될 수 있다.

네트워크 장비(200)는 컨트롤러 서버(100)의 제어에 따라 패킷을 처리하는 기능을 한다. 네트워크 장비(200)의 예로는 이동 통신 기지국, 기지국 제어기, 게이트웨이 장비, 유선 네트워크의 스위치, 라우터 등이 있다. 다만 설명의 편의를 위해 이하에서는 네트워크 장비(200)가 오픈플로우 스위치인 경우를 중심으로 설명하도록 한다.

특히 본 명세서에서 오픈플로우 스위치(200)는 오픈플로우 프로토콜만을 지원하는 스위치, 오픈플로우 프로토콜을 지원하는 가상 스위치, 오픈플로우 프로토콜을 지원하는 일반적인 L2 스위치를 포함하는 개념으로 이해되어야 한다.

소프트웨어 정의 네트워크에서 컨트롤러 서버(100)와 오픈플로우 스위치(200)는 상호간 정보를 주고 받아야 하며, 이를 위한 프로토콜로 널리 사용되는 것이 오픈플로우(OpenFlow) 프로토콜이다. 즉, 오픈플로우 프로토콜은 컨트롤러 서버(100)와 오픈플로우 스위치(200)간 서로 통신할 수 있는 표준 규격이다.

보다 구체적으로 설명하면, 오픈플로우 스위치(200)는 보안 채널(Secure Channel)을 통해 컨트롤러 서버(100)와 정보를 교환한다. 상기 보안 채널은 오픈플로우 스위치(200)와 원거리에 위치한 컨트롤러 서버(100) 간 통신 채널이며, 컨트롤러 서버(100)와 오픈플로우 스위치(200)간 교환되는 정보는 암호화된다.

그리고 오픈플로우 스위치 (200)에는 패킷을 규정 및 처리하고, 패킷에 관련된 통계 정보를 포함하는 플로우 테이블(Flow table)이 존재한다. 상기 플로우 테이블은 패킷 처리를 규정하는 플로우 룰(Flow Rule)로 구성되며, 상기 플로우 룰은 컨트롤러 서버(100)가 생성하여 오픈플로우 스위치(200)에 전송하는 플로우 모드 메세지(Flow-Mod Message)에 의해 추가, 수정 또는 삭제될 수 있다. 오픈플로우 스위치(200)는 상기 플로우 테이블을 참조하여 패킷을 처리한다.

상기 플로우 테이블은 크게 세 가지 정보, 즉 플로우를 정의하는 패킷 헤더 정보(Match), 패킷의 처리를 정의하는 동작 정보(Action) 및 플로우별 통계 정보(Stats)를 포함할 수 있다. 그리고 플로우 테이블을 이루는 각 행을 플로우 엔트리(Flow Entry)라고 칭한다.

호스트(300)는 오픈플로우 스위치(200)의 하위 계층에 해당하는 단말 등을 의미하는 것으로, 클라이언트 및 서버를 통칭하는 의미로 사용될 수 있다. 호스트(300)는 소프트웨어 정의 네트워크를 통해 다른 호스트에 보내기 위한 패킷을 생성하고, 상기 패킷을 네트워크 인터페이스의 포트를 통해 오픈플로우 스위치(200)로 전송할 수 있다.

예컨대 제1 호스트(300a)가 제2 호스트(300b)로 패킷을 보내고자 할 때, 우선 제1 호스트(300a)는 보내고자 하는 패킷을 생성하고 상기 패킷을 제1 호스트(300a)와 연결된 오픈플로우 스위치(200a)로 전송한다. 패킷을 수신한 오픈플로우 스위치에 상기 패킷의 처리를 규정한 플로우 테이블이 존재하는 경우에는, 상기 규정대로 패킷을 처리한다. 그러나 오픈플로우 스위치(200a)에 상기 패킷에 관련된 플로우 테이블이 없는 경우에는, 오픈플로우 스위치(200a)는 컨트롤러 서버(100)에 패킷 유입을 알리는 패킷-인 메세지(Packet-in Message)를 전송한다. 컨트롤러 서버(100)는 상기 패킷의 처리를 규정하는 플로우 룰 변경 사항을 생성하여 오픈플로우 스위치(200a)로 전송하고, 오픈플로우 스위치(200a)는 이에 기반하여 상태를 변경하고 상기 패킷을 처리한다.

한편 제1 호스트(300a)가 제2 호스트(300b)로 패킷을 보낼 수 있는 경로는 다양할 수 있다. 전체 네트워크에는 복수의 오픈플로우 스위치(200) 및 호스트(300)가 존재하므로 각 노드마다 복수의 링크를 가지기 때문이다. 이때, 컨트롤러 서버(100)는 전체 네트워크 토폴로지 맵에 기반하여 상기 패킷을 보낼 수 있는 복수개의 경로 중에서 최적 경로를 연산한다. 그리고 컨트롤러 서버(100)는 연산된 최적 경로에 대한 정보를 오픈플로우 스위치(200)에 전송하고, 오픈플로우 스위치(200)는 상기 최적 경로로 패킷을 처리하는 것이 일반적이다.

도 2는 다수의 오픈플로우 스위치에 대한 플로우 룰의 변경 시점에 따라 발생할 수 있는 문제점을 설명하기 위한 도면이다.

예를 들어, 어떤 시점에서 컨트롤러 서버는 임의의 패킷이 오픈플로우 스위치 220에서 210, 210에서 230를 통해 호스트 250으로 전달되도록 경로를 설정할 수 있다. 이 경우 오픈플로우 스위치 210, 220 및 230은 상기 패킷의 해당 경로에 대한 제 1 플로우 룰을 컨트롤러 서버로부터 수신하여 플로우 테이블을 변경하고 이에 따라 패킷을 처리할 것이다. 이때 컨트롤러 서버는 해당 경로에 대한 우선 순위(priority)를 예를 들어 10으로 설정할 수도 있다.

이와 같은 상황에서 컨트롤러 서버가 임의의 패킷을 우선 순위 20으로 220 및 230을 통해 호스트 260으로 전달하도록 경로를 설정하는 제 2 플로우 룰을 추가하는 경우를 고려할 수 있다.

오픈플로우 표준에서는 복수의 오픈플로우 스위치의 플로우 룰 변경 시점의 일치는 보장하지 않는다. 따라서 220에게 제 1 과 제 2 플로우 룰이 적용되는 순간, 230에서는 제 2 플로우 룰이 적용되어 있지 않고 제 1 플로우 룰만이 적용될 수 있다. 이 경우 임의의 패킷이 220에서 우선 순위가 더 높은 제 2 플로우 룰에 따라 230으로 전달된 경우라도, 230은 이를 260으로 보내지 않고 제 1 플로우 룰에 따라 250으로 전달할 수 있다.

이와 같은 문제는 플로우 룰을 반영하는 복수의 스위치들 사이의 상태 변경 시점 차이에 의해 발생할 수도 있으나, 동시에 처리되어야 하는 플로우 룰과 다른 플로우 룰과의 충돌, 플로우 테이블의 공간 부족, 오픈플로우 스위치의 소프트웨어나 하드웨어의 장애 등으로 인하여 발생할 수도 있다.

이와 같이 현재의 SDN 구조에서는 복수의 스위치에 대한 플로우 룰 변경 등 상태 변경의 동시성을 보장할 수 없는 문제가 있다. 즉, 원자성(atomicity)을 가지는 플로우 룰 변경의 동시적 처리를 보장할 수 없기 때문에 경로 계산의 신뢰성이 낮아지고, 특히 고도의 보안이 요구되는 네트워크 환경에서 큰 문제가 될 수 있다.

따라서 본 발명은 상기와 같은 문제점을 해결하는 것을 목적으로 한다. 본 발명의 실시예를 따르면 복수의 오픈플로우 스위치의 플로우 룰 변경이 동시에 처리되어야 하거나 또는 동기화되어야 하는 경우, 컨트롤러 서버는 해당 플로우에 대해 고유한 식별 정보를 부여하고, 플로우 룰 변경 대기를 지시하는 1단계, 승인 또는 취소하는 2단계로 나누어서 스위치의 상태 변경을 진행할 수 있다. 이를 통해 컨트롤러 서버는 복수의 스위치에 대한 상태 변경을 원자적으로 수행할 수 있다.

보다 구체적인 방법은 첨부된 도 3 및 도 4에 대한 설명과 함께 후술된다.

도 3는 본원발명의 실시예를 따라 복수의 오픈플로우 스위치에서 2단계로 플로우 룰 변경을 처리하는 구체적인 방법을 설명하기 위한 순서도이다.

도 3의 A는 플로우 룰 변경이 최종적으로 승인되어 오픈플로우 스위치에서 적용되는 경우이며, B와 C는 플로우 룰 변경이 최종적으로 취소되는 경우이다. 본원발명의 실시예를 따르면, 플로우 룰 변경에 원자성이 요구되는 경우, 복수의 스위치에 대한 해당 플로우 룰 변경은 일괄적으로 승인 되거나 취소될 수 있으며, 최종 승인 및 취소의 시점을 동기화할 수 있는 효과가 있다.

단계 310에서 컨트롤러 서버는 복수의 스위치에 대한 플로우 룰 변경이 원자성을 가지는 경우, 이후의 절차에서 해당 플로우 룰 변경을 식별할 수 있도록 해당 플로우 룰 및/또는 플로우 룰 변경에 대해 고유한 식별 정보를 부여할 수 있다. 상기 식별 정보는 컨트롤러 서버로부터 오픈플로우 표준에서 정의한 실험자 메시지 (Experimenter Message or Vendor Message)를 이용하여 전달될 수 있다.

도 3의 A는 본원발명에 따라 플로우 룰 2단계 변경이 최종적으로 승인되어 적용되는 경우에 대한 예시이다.

단계 312 및 314에서 컨트롤러 서버는 복수의 스위치에게 플로우 룰 변경 대기를 지시하는 1단계 변경을 진행할 수 있다.

보다 구체적으로 컨트롤러 서버는 복수의 스위치 1과 스위치 2에게 해당 플로우 룰에 대한 변경 대기를 지시하는 변경 대기 지시 메시지를 단계 310에서 발급한 식별 정보와 함께 전송할 수 있다. 이는 플로우 모드 메시지 (Flow-mod Message) 형태 일 수 있으며, 또는 실험자 메시지 (Experimenter Message or Vendor Message)의 형태일 수도 있다.

단계 316 및 단계 318에서 변경 대기 메시지를 수신한 스위치 1 및 스위치 2는 플로우 테이블에 해당 플로우 룰을 대기 상태로 반영할 수 있다.

예를 들어 플로우 룰이 추가된 경우라면, 플로우 엔트리를 추가하고 추가 대기 상태임을 표시하거나, 플로우 룰이 삭제된 경우라면, 해당 플로우 엔트리를 삭제하지 않고, 해당 플로우 엔트리에 삭제 대기 상태임을 표시할 수 있다. 나아가 플로우 룰이 수정된 경우라면, 수정전 플로우 엔트리에 삭제 대기 상태임을 표시하고 수정후 플로우 엔트리를 추가하여 추가 대기 상태임을 표시하는 방식으로 진행할 수 있다. 이와 같은 표시는 패킷을 대기 중인 플로우 룰을 적용하여 처리하지 않도록 하기 위한 것으로 다양한 변형이 가능할 수 있다.

나아가 단계 320 및 단계 322에서 스위치 1 및 스위치 2는 변경 대기가 성공했음을 보고하는 상태 메시지를 컨트롤러 서버에게 전송할 수 있다.

나아가 스위치 1 및 스위치 2는 해당 플로우 룰을 대기 상태로 플로우 테이블에 반영한 경우, 해당 플로우 룰을 적용받는 패킷을 수신하면 상기 패킷을 자료구조에 저장하고 플로우 룰 변경의 최종 승인 또는 취소 여부가 결정된 후 패킷을 처리할 수 있다.

상기 패킷을 저장하는 자료구조는 큐, 우선순위 큐, 스택, 힙, 트리 등 다양한 소프트웨어 자료구조일 수도 있다. 오픈플로우 스위치가 대기 상태의 플로우 룰을 적용받는 패킷을 처리하는 구체적인 방법은 첨부된 도 4와 함께 후술된다.

단계 320 및 단계 322에서 스위치 1 및 스위치 2 모두로부터 상태 변경 대기 성공을 보고하는 메시지를 수신한 컨트롤러 서버는 단계 324 및 단계 326에서 플로우 룰의 변경을 최종적으로 승인하는 메시지를 전송하여 2단계 상태 변경을 진행할 수 있다. 이는 실험자 메시지 (Experimenter Message or Vendor Message)의 형태로 해당 플로우 룰 및/또는 해당 플로우 룰 변경에 대한 식별 정보와 함께 전송될 수 있다.

단계 328 및 단계 330에서 상태 변경 승인을 지시하는 메시지를 수신한 스위치 1 및 스위치 2는 해당 플로우 룰을 플로우 테이블에 적용한다. 단계 328 및 단계 330는 예를 들어 플로우 테이블에서 해당 플로우 엔트리의 대기 상태 마크를 삭제하거나, 대기 상태인 플로우 엔트리를 삭제하고 해당 플로우 룰에 대한 플로우 엔트리를 추가하는 방식으로 진행할 수도 있다. 이후 스위치 1 및 스위치 2는 자료구조에 대기 중인 패킷을 해당 플로우 룰에 따라 처리할 수 있다.

도 3의 B는 1단계 변경이 적용된 일부 스위치에서 변경 대기가 실패하여 모든 스위치의 변경이 최종적으로 취소되는 경우에 대한 예시이다.

단계 340 및 342에서 컨트롤러 서버는 복수의 스위치에게 플로우 룰 변경 대기를 지시하는 1단계 변경을 진행할 수 있다.

이후 변경 대기 메시지를 수신한 스위치 1은 단계 344에서 플로우 테이블에 해당 플로우 룰을 대기 상태로 반영하고 단계 348에서 변경 대기가 성공했음을 보고하는 상태 메시지를 컨트롤러 서버에게 전송할 수 있다. 나아가 스위치 1은 대기 상태임이 표시된 플로우 룰을 적용받는 패킷을 수신하면 상기 패킷을 자료구조에 저장할 수 있다.

그러나 변경 대기 메시지를 수신한 스위치 2는 단계 346에서 예를 들어 플로우 테이블의 저장 공간 부족 또는 소프트웨어나 하드웨어의 장애 등의 이유로 인하여 해당 플로우 룰을 플로우 테이블에 대기 상태로 반영하는 것을 실패할 수도 있다.

이 경우 단계 350에서 스위치 2는 변경 대기가 실패했음을 보고하는 상태 메시지를 컨트롤러 서버에게 전송할 수 있다. 이러한 메시지로는 OFPET_BAD_REQUEST 메시지, OFPET_BAD_ACTION 메시지, OFPET_BAD_INSTRUCTION 메시지, OFPET_BAD_MATCH 메시지, OFPET_FLOW_MOD_FAILED 메시지 등을 예시할 수 있다.

본 발명의 실시예를 따르면, 원자적 변경이 요구되는 플로우 룰이 적용되는 모든 스위치로부터 컨트롤러 서버가 변경 대기 성공 보고 메시지를 수신하지 못한 경우 전체 스위치에 대한 상태 변경이 취소되는 특징이 있다.

따라서 스위치 2로부터 변경 대기 실패 보고 메시지를 수신했기 때문에 모든 스위치로부터 성공 보고 메시지를 받지 못한 컨트롤러 서버는 플로우 룰의 변경을 최종적으로 취소하는 메시지를 스위치 1 및 스위치 2에게 전송할 수 있다. (단계 352 및 단계 354) 이때 컨트롤러 서버는 스위치 2에게는 변경 취소 메시지를 선택적으로 전송하거나 전송하지 않을 수 있다.

변경 취소 메시지는 예를 들어 실험자 메시지 (Experimenter Message or Vendor Message)의 형태로 해당 플로우 룰 및/또는 해당 플로우 룰 변경에 대한 식별 정보와 함께 전송될 수 있다.

단계 356에서 변경 취소를 지시하는 메시지를 수신한 스위치 1는 해당 플로우 룰을 플로우 테이블에 삭제하고, 플로우 테이블을 재탐색하여 자료구조에 대기하고 있는 패킷을 처리할 수 있다. 스위치 2도 이전 단계 346에서 결과적으로 대기 상태 변경은 실패했지만, 관련 기록이 남았거나 자료구조에 대기시킨 패킷이 존재하면 단계 358에서 기록을 삭제하고 플로우 테이블을 재탐색하여 자료구조의 패킷을 처리할 수 있다.

도 3의 C는 1단계 변경이 적용된 일부 스위치에서 변경 대기 결과에 대한 보고가 없어 모든 스위치의 상태 변경이 최종적으로 취소되는 경우에 대한 예시이다.

단계 370 및 372에서 컨트롤러 서버는 복수의 스위치에게 플로우 룰 변경 대기를 지시하는 1단계 변경을 진행할 수 있다.

이후 변경 대기 메시지를 수신한 스위치 2은 단계 374에서 플로우 테이블에 해당 플로우 룰을 대기 상태로 반영하고 단계 376에서 변경 대기가 성공했음을 보고하는 상태 메시지를 컨트롤러 서버에게 전송할 수 있다. 나아가 스위치 2은 대기 상태임이 표시된 플로우 룰을 적용받는 패킷을 수신하면 상기 패킷을 자료구조에 저장할 수 있다.

그러나 단계 378에서 컨트롤러 서버가 미리 설정된 시간 동안 스위치 1로부터 변경 대기의 성공 또는 실패 여부에 대한 보고 메시지를 수신하지 않으면, 컨트롤러 서버는 전체 스위치에 대한 상태 변경을 취소할 수 있다.

이는 일부 스위치에서 실패 보고 메시지를 발송할 수 없는 장애가 발생했거나 또는 컨트롤러 서버와 네트워크 연결 단절이 발생한 경우에 다른 스위치에서 너무 오랜 시간 대기하지 않도록 하여 전체 네트워크 운영의 신뢰성을 높이기 위한 것이다.

따라서 스위치 1의 보고 메시지가 없어서 모든 스위치로부터 성공 보고 메시지를 받지 못한 컨트롤러 서버는 플로우 룰의 변경을 최종적으로 취소하는 메시지를 스위치 1 및 스위치 2에게 전송할 수 있다. (단계 380 및 단계 382)

변경 취소 메시지는 예를 들어 실험자 메시지 (Experimenter Message or Vendor Message)의 형태로 해당 플로우 룰 및/또는 플로우 룰 변경에 대한 식별 정보와 함께 전송될 수 있다.

단계 386에서 변경 취소를 지시하는 메시지를 수신한 스위치 2는 해당 플로우 룰을 플로우 테이블에 삭제하고, 플로우 테이블을 재탐색하여 자료구조에 대기하고 있는 패킷을 처리할 수 있다. 스위치 1도 패킷을 자료구조에 대기시켰거나 플로우 테이블에 해당 플로우 룰을 반영한 경우라면, 단계 384에서 해당 플로우 룰을 삭제하고 플로우 테이블을 재탐색하여 패킷을 처리할 수 있다.

도 4는 본원발명의 실시예를 따라 오픈플로우 스위치가 패킷을 처리하는 구체적인 방법을 설명하기 위한 순서도이다.

오픈플로우 스위치는 단계 410에서 패킷을 수신한 경우, 단계 420에서 플로우 테이블을 탐색할 수 있다.

이때 해당 패킷이 적용되는 플로우 룰이 대기 상태로 표시되어 있는 경우, 오픈플로우 스위치는 단계 440에서 해당 패킷을 자료구조에 대기시킬 수 있다. 반면 해당 패킷이 적용되는 플로우 룰이 대기 상태 표시가 없는 일반적인 경우라면 단계 450에서 패킷을 해당 플로우 룰이 반영된 플로우 엔트리에 따라 처리할 수 있다.

한편 단계 440에서 자료구조에 대기한 패킷은 도 3에 대한 설명에서 전술한 방식으로 처리될 수 있다. 즉, 오픈플로우 스위치는 컨트롤러 서버로부터 대기 중인 플로우 룰에 대한 승인 또는 취소 메시지를 수신할 수 있으며, 승인된 경우라면 자료구조의 패킷을 해당 플로우 룰에 따라 처리하고, 취소된 경우라면 종래의 플로우 테이블을 다시 검색하여 적용되는 플로우 룰에 따라 자료구조의 패킷을 처리할 수 있다.

나아가 본 발명의 다른 실시예를 따르면, 오픈플로우 스위치는 단계 440에서 대기 중인 플로우 룰이 적용되는 패킷을 자료구조에 대기시키지 않고 드랍(drop)하는 방식으로 처리할 수 있다. 또는 자료구조에 대기시킨 후 미리 설정된 용량을 초과하면 순차적으로 드랍하거나, 또는 모두 드랍시키는 방식으로 처리할 수 있다.

또 다른 예로, 오픈플로우 스위치는 패킷을 자료구조에 대기시킨 후 컨트롤러 서버로부터 해당 플로우 룰 변경 취소 메시지를 수신하거나 또는 미리 설정된 시간동안 어떠한 메시지도 받지 못한 경우 해당 패킷을 드랍하는 방식으로 처리할 수도 있다.

한편 본 발명에서 컨트롤러 서버가 복수의 스위치에 대한 변경을 원자적으로 처리하는 대상은 플로우 룰에 제한되지 않는다. 즉, 본 발명의 실시예를 따르면 컨트롤러 서버가 오픈플로우 스위치로 전송하는 다양한 명령(command)인 OFPT_PACKET_OUT, OFPT_FLOW_MOD, OFPT_GROUP_MOD, OFPT_PORT_MOD, 및/또는 OFPT_TABLE_MOD 역시 원자적으로 처리될 수 있다.

본 명세서와 도면에 게시된 본 발명의 실시 예들은 본 발명의 기술 내용을 쉽게 설명하고 본 발명의 이해를 돕기 위해 특정 예를 제시한 것뿐이며, 본 발명의 범위를 한정하고자 하는 것은 아니다. 여기에 게시된 실시 예들 이외에도 본 발명의 기술적 사상에 바탕을 둔 다른 변형 예들이 실시 가능하다는 것은 본 발명이 속하는 기술 분야에서 통상의 지식 가진 자에게 자명한 것이다.

100 : 컨트롤러 서버
200, 200a, 210, 220, 230 : 오픈플로우 스위치
250, 260, 300, 300a, 300b : 호스트

Claims (13)

1. 소프트웨어 정의 네트워크 시스템에서 복수의 스위치의 상태를 변경하는 방법에 있어서,
   컨트롤러 서버가, 복수의 스위치에 대한 플로우 룰 변경이 원자성(atomicity)을 가지는 경우, 상기 플로우 룰에 대해 하나의 식별 정보를 부여하고, 상기 식별 정보 및 변경 대기를 지시하는 실험자 메시지와 함께, 상기 플로우 룰을 해당 스위치들에 전송하는 단계; 및
   상기 스위치가, 상기 플로우 룰을 플로우 테이블에 변경 대기 상태로 반영하고, 패킷을 수신하면, 플로우 테이블을 검색하여 매치되는 플로우 룰을 검색하고, 상기 패킷에 매치되는 플로우 룰이 변경 대기 상태인 경우, 상기 패킷을 자료구조에 저장하여, 상기 플로우 룰의 변경이 확정될 때까지 상기 패킷의 처리를 대기하고, 상기 패킷에 매치되는 플로우 룰이 변경 대기 상태가 아니면, 상기 패킷을 해당 플로우 룰에 따라 처리하는 단계를 포함하는 것을 특징으로 하는 스위치 상태 변경 방법.
2. 제 1항에 있어서,
   상기 컨트롤러 서버가, 상기 변경 대기를 지시하는 메시지를 전송한 모든 스위치들로부터 변경 대기에 대한 성공 보고 메시지를 수신한 경우, 상기 플로우 룰에 대한 변경을 승인하는 메시지를 상기 스위치들에 전송하고,
   상기 변경 대기를 지시하는 메시지를 전송한 하나 이상의 스위치들로부터 변경 대기 성공 보고 메시지를 수신하지 않은 경우, 상기 플로우 룰에 대한 변경을 취소하는 메시지를 상기 스위치들에 전송하는 단계를 더 포함하는 것을 특징으로 하는 스위치 상태 변경 방법.
3. 삭제
4. 제 2항에 있어서,
   상기 스위치가, 상기 플로우 룰을 플로우 테이블에 변경 대기 상태로 반영한 경우, 상기 컨트롤러 서버에 변경 대기 성공 보고 메시지를 상기 식별 정보와 함께 전송하는 단계를 포함하는 것을 특징으로 하는 스위치 상태 변경 방법.
5. 제 4항에 있어서,
   상기 스위치가, 상기 컨트롤러 서버로부터 대기 중 플로우 룰에 대한 변경을 승인하는 메시지를 상기 식별 정보와 함께 수신한 경우, 상기 플로우 룰을 상기 플로우 테이블에 반영하는 단계; 및
   상기 자료구조에 대기된 패킷을 상기 플로우 룰에 따라 처리하는 단계를 더 포함하는 것을 특징으로 하는 스위치 상태 변경 방법.
6. 제 4항에 있어서,
   상기 스위치가, 상기 컨트롤러 서버로부터 대기 중 플로우 룰에 대한 변경 취소 메시지를 상기 식별 정보와 함께 수신한 경우, 상기 플로우 룰을 상기 플로우 테이블에서 삭제하는 단계; 및
   상기 자료구조에 대기된 패킷을 상기 플로우 테이블에서 매치되는 플로우 룰에 따라 처리하는 단계를 더 포함하는 것을 특징으로 하는 스위치 상태 변경 방법.
7. 삭제
8. 제 6항에 있어서,
   상기 스위치가, 미리 설정된 시간 동안 컨트롤러 서버로부터 변경 대기 상태인 상기 플로우 룰에 대한 변경 승인 메시지가 수신되지 않는 경우, 상기 자료구조에 대기된 패킷을 드랍하는 단계를 더 포함하는 것을 특징으로 하는 스위치 상태 변경 방법.
9. 소프트웨어 정의 네트워크에서 복수의 스위치의 상태를 변경하는 시스템에 있어서,
   복수의 스위치에 대한 플로우 룰 변경이 원자성을 가지는 경우, 상기 플로우 룰에 대해 하나의 식별 정보를 부여하고, 상기 식별 정보 및 변경 대기를 지시하는 실험자 메시지와 함께, 상기 플로우 룰을 해당 스위치들에 전송하는 컨트롤러 서버; 및
   상기 플로우 룰을 플로우 테이블에 변경 대기 상태로 반영하고, 패킷을 수신하면, 플로우 테이블을 검색하여 매치되는 플로우 룰을 검색하고, 상기 패킷에 매치되는 플로우 룰이 변경 대기 상태인 경우, 상기 패킷을 자료구조에 저장하여, 상기 플로우 룰의 변경이 확정될 때까지 상기 패킷의 처리를 대기하고, 상기 패킷에 매치되는 플로우 룰이 변경 대기 상태가 아니면, 상기 패킷을 해당 플로우 룰에 따라 처리하는 적어도 하나 이상의 스위치를 포함하는 것을 특징으로 하는 스위치 상태 변경 시스템.
10. 삭제
11. 삭제
12. 삭제
13. 삭제

Images