KR101581510B1 - 다중 제어장치를 구비한 환경에서 제어장치의 제어 권한 변경 방법 - Google Patents

Abstract

다중 제어장치를 구비한 환경에서 제어장치의 제어 권한 변경 방법이 개시된다. 통신장치에서 수행되는 제어 권한 변경 방법은 새로운 주제어장치인 제2 제어장치로부터 제2 제어장치의 역할을 주제어장치로 변경할 것을 요청하는 역할 변경 요청 메시지를 수신하고, 이전의 주제어장치인 제1 제어장치로 제어 권한 변경의 확인을 위한 상태 요청 메시지를 전송한 후, 제1 제어장치로부터 수신한 상태 확인 메시지에 따라 제2 제어장치의 주제어장치 역할 변경에 대한 수락 여부를 결정한다. 따라서, 마스터 컨트롤러의 역할 변경시 신뢰성을 보장할 수 있다.

Description

다중 제어장치를 구비한 환경에서 제어장치의 제어 권한 변경 방법{METHODS FOR CHANGING AN AUTHORITY OF CONTROL FOR A CONTROLLER IN MULTIPLE CONTROLLER ENVIRONMENT}

본 발명은 소프트웨어 정의 네트워킹 기술에 관한 것으로, 더욱 상세하게는 다중 제어장치를 구비한 환경에서 제어장치의 제어 권한 변경 방법에 관한 것이다.

일반적인 라우터 또는 스위치 기반으로 구성된 네트워크는 복잡한 프로토콜과 기능을 기반으로 구성되고, 각 장비 업체마다 장비를 운영하는 방식이나 사용자 인터페이스가 다르기 때문에 네트워크 운용자 또는 연구자가 새로운 네트워크 프로토콜을 개발하여 네트워크에 적용하기가 어렵고 네트워크를 확장하거나 네트워크 장비들을 서로 연동시키기 어려운 문제가 있다. 이와 같은 문제를 해결하기 위해 개방형 인터페이스를 갖는 스위치나 라우터 기술이 연구되었으나, 개방형 인터페이스를 제공하는 네트워크 기술들은 성능 대비 가격이 높기 때문에 상용화에 어려움이 있었다.

오픈플로우(OpenFlow) 기술은 고비용 문제를 해결하면서 사용자 또는 개발자에게 개방형 표준 인터페이스를 제공하기 위해서 출현하였다.

오픈플로우 기술은 네트워크 스위치의 패킷 포워딩(Packet Forwarding) 기능과 제어 기능을 분리하고, 이들 두 기능 간의 통신을 위한 표준화된 프로토콜을 제공한다. 따라서, 오픈플로우 기술을 이용하면 외부 제어 장치에서 구동되는 소프트웨어를 이용하여 장비 제조업체와 무관하게 스위치 내의 패킷 경로를 결정할 수 있고, 기존보다 더 정밀하게 트래픽을 관리할 수 있다.

ONF(Open Networking Foundation)는 오픈플로우를 기반으로 네트워크를 좀 더 손쉽게 프로그램할 수 있는 소프트웨어 정의 네트워킹(SDN: Software Defined Networking, 이하, 'SDN'이라 약칭함) 기술을 정의하였다.

오픈플로우 기반 SDN 구조는 오픈플로우 스위치(OpenFlow Switch)와 컨트롤러(Controller)를 포함하고, 오픈플로우 스위치와 컨트롤러는 오픈플로우 프로토콜에 의해 상호 연결된다.

오픈플로우 기반 SDN 네트워크에서는 컨트롤러가 스위치에게 플로우 테이블 정보를 제공하고, 스위치는 제공받은 플로우 테이블 정보를 이용하여 패킷의 속성을 변경하거나, 패킷의 흐름을 제어하는 방식으로 패킷을 처리한다.

스위치는 다수의 컨트롤러와 연결될 수 있고, 스위치와 연결된 각 컨트롤러는 마스터(Master), 슬레이브(Slave) 및 동등(Equal) 중 어느 하나의 제어 권한을 가질 수 있다. 여기서, 마스터로 동작하는 컨트롤러는 스위치에게 트래픽 제어와 관련된 명령 기능을 수행하므로, 스위치의 입장에서는 마스터 컨트롤러의 권한을 어떤 컨트롤러가 갖는지가 매우 중요하다.

한편, ONF 이외에도 IETF(Internet Engineering Task Force), ETSI(European Telecommunications Standards Institute), ITU-T(International Telecommunications Union Telecommunication) 등과 같은 표준화 단체에서도 SDN 기반의 네트워크에 대한 표준화를 진행하고 있다.

예를 들어, IETF의 I2RS(Interface to Router System) 워킹 그룹(Working Group)에서는 기존의 네트워크 장비를 외부에서 감시하고 제어할 수 있도록 개방형 인터페이스를 제공하기 위한 표준화를 진행하고 있다.

I2RS에서 하나의 에이전트(Agent)는 다수의 클라이언트(Client)와 통신할 수 있으며, 클라이언트는 에이전트와의 사전 절차를 수행하여 역할(security role)을 부여받는다. 즉, 각 클라이언트는 서로 다른 역할을 부여받을 수 있고, 부여된 역할에 의해 각 클라이언트가 에이전트에 전송하는 명령어의 우선순위(precedence)가 결정되기도 한다. 따라서, I2RS에서도 클라이언트의 역할은 매우 중요하다. I2RS의 클라이언트와 에이전트는 각각 오픈플로우에서 컨트롤러와 스위치에 대응된다.

상술한 바와 같이 다중 컨트롤러가 스위치 또는 라우터 등과 같은 통신 장치와 연결되고, 마스터 권한을 가진 컨트롤러가 통신 장치의 동작을 제어하는 네트워크 환경에서는 컨트롤러의 역할이 매우 중요하다. 따라서, 컨트롤러의 역할(또는 권한) 변경에 대한 신뢰성이 반드시 보장되어야 한다.

그러나, 종래에는 컨트롤러의 역할이 변경되면 새로 마스터 권한을 획득한 컨트롤러가 스위치에게 역할 변경을 일방적으로 통보하는 방법을 사용하였기 때문에 컨트롤러의 역할 변경에 대한 신뢰성을 보장할 수 없는 단점이 있었다.

본 발명의 목적은 다수의 제어 장치를 구비하는 네트워크 환경에서 제어 장치의 역할 변경에 대한 신뢰성을 보장할 수 있는 제어 권한 변경 방법을 제공하는 것이다.

본 발명에서 이루고자 하는 목적들은 상기한 목적으로 제한되지 않으며, 언급하지 않은 다른 목적들은 하기의 기재로부터 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

본 발명의 목적을 달성하기 위한 본 발명의 일 측면에 따른 제어 권한 변경 방법은 통신장치에서 수행되는 제어 권한 변경 방법으로, 새로운 주제어장치인 제2 제어장치로부터 상기 제2 제어장치의 역할을 주제어장치로 변경할 것을 요청하는 역할 변경 요청 메시지를 수신하는 단계와, 이전의 주제어장치인 제1 제어장치로 제어 권한 변경의 확인을 위한 상태 요청 메시지를 전송하는 단계 및 상기 제1 제어장치로부터 수신한 상태 확인 메시지에 따라 상기 제2 제어장치의 주제어장치 역할 변경에 대한 수락 여부를 결정하는 단계를 포함한다.

여기서, 상기 역할 변경 요청 메시지는 상기 제2 제어장치의 역할이 주제어장치임을 나타내는 식별 정보를 포함할 수 있다. 또한, 상기 식별 정보는 상기 제1 제어장치의 식별 정보가 증가된 값을 가질 수 있다. 또한, 상기 식별 정보는 제너레이션 아이디(generation ID)로 구성될 수 있다.

여기서, 상기 상태 요청 메시지를 전송하는 단계는 상기 제2 제어장치의 역할을 나타내는 식별 정보를 상기 상태 요청 메시지에 포함시켜 전송할 수 있다.

여기서, 상기 제2 제어장치의 주제어장치 역할 변경에 대한 수락 여부를 결정하는 단계는, 상기 상태 확인 메시지에 기초하여 상기 제1 제어장치의 역할 변경을 확인하는 단계와, 상기 제1 제어장치의 역할이 변경된 경우 상기 제2 제어장치를 주제어장치로 변경하는 단계 및 상기 제2 제어장치에 상기 제2 제어장치가 주제어장치로 변경되었음을 지시하는 역할 변경 응답 메시지를 전송하는 단계를 포함할 수 있다. 또한, 상기 제2 제어장치의 주제어장치 역할 변경에 대한 수락 여부를 결정하는 단계는, 상기 상태 확인 메시지에 기초하여 상기 제1 제어장치의 역할 변경을 확인하는 단계와, 상기 제1 제어장치의 역할이 변경되지 않은 경우, 상기 제1 제어장치를 주제어장치로 유지하는 단계 및 상기 제2 제어장치의 역할이 변경되지 않았음을 지시하는 오류 메시지를 상기 제2 제어장치에 전송하는 단계를 포함할 수 있다.

또한, 본 발명의 목적을 달성하기 위한 본 발명의 다른 측면에 따른 제어 권한 변경 방법은 제2 제어장치에서 수행되는 제어 권한 변경 방법으로, 상기 제2 제어장치의 역할을 주제어장치로 변경할 것을 요청하는 역할 변경 요청 메시지를 통신장치에 전송하는 단계와, 상기 통신장치로부터 역할 변경 수락 또는 역할 변경 오류를 지시하는 역할 변경 응답 메시지를 수신하는 단계 및 상기 통신장치로부터 역할 변경 수락을 지시하는 메시지를 수신하는 경우 역할을 주제어장치로 변경하는 단계를 포함한다.

여기서, 상기 역할 변경 요청 메시지는 상기 제2 제어장치가 주제어장치임을 나타내는 제너레이션 아이디 및 역할 정보를 포함할 수 있다.

여기서, 상기 역할 변경 응답 메시지를 수신하는 단계는, 상기 역할 변경 응답 메시지가 오류를 지시하는 경우, 상기 제2 제어장치의 제어 권한을 변경하지 않는 단계를 포함할 수 있다.

또한, 본 발명의 목적을 달성하기 위한 본 발명의 또 다른 측면에 따른 제어 권한 변경 방법은 통신장치에서 수행되는 제어 권한 변경 방법으로, 새로운 주제어장치인 제2 제어장치로부터 상기 제2 제어장치의 역할을 주제어장치로 변경할 것을 요청하는 역할 변경 요청 메시지를 수신하는 단계와, 상기 역할 변경 요청 메시지에 포함된 식별 정보를 기저장된 식별 정보와 비교하여 역할 변경 요청에 대한 유효성을 판단하는 단계 및 상기 역할 변경 요청 메시지의 유효성이 없는 경우 상기 제2 제어장치에 오류 메시지를 전송하는 단계를 포함한다.

여기서, 상기 식별 정보는 제너레이션 아이디로 구성될 수 있다.

여기서, 상기 역할 변경 요청에 대한 유효성을 판단하는 단계는, 상기 역할 변경 요청 메시지에 포함된 제너레이션 아이디를 기저장된 제너레이션 아이디와 비교하는 단계 및 상기 역할 변경 요청 메시지에 포함된 제어레이션 아이디가 상기 기저장된 제너레이션 아이디 보다 크지 않은 경우 상기 역할 변경 요청 메시지의 유효성이 없는 것으로 판단하는 단계를 포함할 수 있다.

여기서, 상기 제어 권한 변경 방법은 상기 역할 변경 요청 메시지의 유효성이 있는 경우, 상기 제2 제어장치에 상기 제2 제어장치의 역할 정보를 포함하는 역할 변경 응답 메시지를 전송하는 단계를 더 포함할 수 있다.

본 발명의 실시예에 따른 다중 제어장치를 구비한 환경에서 제어장치의 제어 권한 변경 방법에 따르면, 스위치가 새로운 마스터 컨트롤러로부터 역할 변경을 요청하는 메시지를 수신하면, 이전의 마스터 컨트롤러에게 역할 변경의 확인을 요청하고 이에 대한 응답을 수신하여 역할 변경의 유효성을 판단한 후, 역할 변경의 유효성이 검증된 경우에만 스위치 내에서 마스터 컨트롤러를 변경한다.

따라서, 복수의 컨트롤러가 스위치에 연결된 환경에서, 마스터 컨트롤러의 역할 변경시 신뢰성을 보장할 수 있다.

도 1은 SDN 시스템의 구성을 나타내는 블록도이다.
도 2는 플로우 테이블에 포함되는 플로우 엔트리들의 구조를 나타낸다.
도 3은 다중 컨트롤러 환경에서 슬레이브 컨트롤러가 마스터 컨트롤러로 역할을 변경하는 과정을 나타내는 개념도이다.
도 4는 다중 컨트롤러 환경에서 슬레이브 컨트롤러가 마스터 컨트롤러로 역할을 변경하는 과정을 나타내는 순서도이다.
도 5는 본 발명의 일 실시예에 따른 컨트롤러의 역할 변경 방법을 나타내는 순서도이다.
도 6은 본 발명의 일 실시예에 따른 컨트롤러의 역할 변경 과정을 보다 상세하게 나타내는 순서도이다.
도 7은 본 발명의 다른 실시예에 따른 컨트롤러의 역할 변경 과정을 나타내는 순서도이다.
도 8은 본 발명의 실시예에 따른 컨트롤러의 역할 변경 과정에서 사용되는 메시지의 일 예를 나타내는 것이다.
도 9는 본 발명의 실시예에 따른 컨트롤러의 역할 변경 방법을 수행하는 컨트롤러 및 스위치의 구성을 나타내는 블록도이다.

본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세하게 설명하고자 한다.

그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.

제1, 제2 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.

어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.

본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가진 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.

이하, 본 발명에서 언급되는 '제어 장치' 또는 '컨트롤러'는 트래픽의 흐름을 제어하기 위해 관련 구성 요소(예를 들면, 스위치, 라우터 등)를 제어하는 기능 요소(entity)를 의미하는 것으로, 물리적인 구현 형태나 구현 위치 등에 한정되지 않는다. 예를 들어, 상기 컨트롤러는 ONF, IETF, ETSI 및/또는 ITU-T 등에서 정의하고 있는 컨트롤러 기능 요소(entity)를 의미할 수 있다. 또한, 본 발명에서 언급되는 '통신 장치' 또는 '스위치'는 트래픽(또는 패킷)을 실질적으로 포워딩하거나 스위칭 또는 라우팅하는 기능 요소를 의미하는 것으로, ONF, IETF, ETSI 및/또는 ITU-T 등에서 정의하고 있는 스위치, 라우터, 스위치 요소, 라우터 요소, 포워딩 요소 등을 의미할 수 있다.

또한, 이하에서 기술되는 본 발명의 실시예들은 SDN 기술의 표준화를 수행하고 있는 ONF, IETF, ETSI, ITU-T들에서 작성된 표준 문서들에 의해 뒷받침될 수 있다. 즉, 본 발명의 실시예들 중 본 발명의 기술적 사상을 명확히 드러내기 위해 구체적으로 설명하지 않은 내용들은 상기의 표준화 단체들에서 작성한 표준 문서들에 의해 뒷받침될 수 있다. 또한, 본 발명에서 사용되는 모든 용어들은 상기 표준 문서에 의해 설명될 수 있다.

이하, 첨부한 도면들을 참조하여, 본 발명의 바람직한 실시예를 보다 상세하게 설명하고자 한다. 본 발명을 설명함에 있어 전체적인 이해를 용이하게 하기 위하여 도면상의 동일한 구성요소에 대해서는 동일한 참조부호를 사용하고 동일한 구성요소에 대해서 중복된 설명은 생략한다.

도 1은 SDN 시스템의 구성을 나타내는 블록도이다. 도 2는 플로우 테이블에 포함되는 플로우 엔트리들의 구조를 나타낸다.

도 1을 참조하면, SDN 시스템은 복수의 스위치 및 컨트롤러로 구성될 수 있고, 복수의 스위치와 컨트롤러는 오픈플로우 프로토콜을 이용하여 서로 통신할 수 있다. 도 1에서는 설명의 편의를 위하여 컨트롤러(110) 및 스위치(120)를 각각 하나씩만 도시하였으나, 컨트롤러(110) 및 스위치(120)는 실질적으로 각각 복수개로 구성될 수 있다.

스위치(120)는 패킷의 룩업(lookup) 및 포워딩(forwarding)에 사용하는 하나 또는 그 이상의 플로우 테이블(121)과 그룹 테이블(123)을 포함하고, 컨트롤러(110)와 통신을 위한 오픈플로우 채널(125)을 포함한다.

스위치에 포함된 각 플로우 테이블(121)은 플로우 엔트리(flow entries)들의 집합으로, 각 플로우 엔트리는 도 2에 도시한 바와 같이 매치 필드(match fields)(201), 우선순위(Priority)(202), 카운터(counters)(203), 명령어(Instructions)(204), 타임아웃(Timeouts)(205) 및 쿠키(Cookie)(206) 필드로 구성될 수 있다.

매치 필드(201)는 패킷의 매치를 위한 정보로, 유입 포트(ingress port), 패킷 헤더 정보를 포함할 수 있고, 선택적으로 이전 플로우 테이블에서 지정된 메타데이터를 포함할 수 있다. 우선순위(202)는 플로우 엔트리의 매칭 우선순위를 의미한다. 카운터(203)는 패킷이 매치되었을 때 갱신되는 값이다. 명령어(204)는 액션 집합(action sets)이나 파이프라인 처리(pipeline processing)를 변경하기 위해 사용된다. 타임아웃(205)은 플로우가 스위치에 의해 만료되기 전까지의 최대 시간 또는 유휴 시간(idle time)을 의미한다. 쿠키(206)는 컨트롤러에 의해 선택되는 불분명한 데이터 값(opaque data value)으로, 컨트롤러가 플로우 통계, 플로우 변경, 플로우 삭제 등을 필터링하기 위해 사용될 수 있다.

패킷의 처리를 위한 매칭은 스위치(120)에 포함된 복수의 플로우 테이블들(121) 중 첫번째 플로우 테이블로부터 시작되고, 이후의 플로우 테이블들에서 계속될 수 있다.

스위치(120)는 매칭 플로우 엔트리가 발견되는 경우, 매칭된 특정 플로우 엔트리와 연관된 명령을 실행한다. 또는 매칭 엔트리가 플로우 테이블에서 발견되지 않는 경우, 스위치(120)는 패킷을 오픈플로우 채널(125)을 통해 컨트롤러(110)로 포워딩하거나, 폐기(drop)할 수도 있고, 다음 플로우 테이블에서 매칭 처리를 계속할 수도 있다.

각 플로우 엔트리와 연관된 명령어들은 액션이나, 스위치 내에서 파이프라인 처리를 수정하기 위한 명령을 포함한다.

명령에 포함된 액션은 패킷 포워딩, 패킷 수정 및 그룹 테이블의 처리를 기술한다. 예를 들어, 액션은 패킷이 부가적인 처리를 규정하는 그룹으로 향하도록 지정할 수 있다. 여기서, 그룹은 플러딩(flooding) 및 보다 복합적인 포워딩을 처리하기 위한 액션 집합을 표현한다. 그룹을 통해 복수의 플로우 엔트리들과 연관된 패킷의 공통적인 출력 액션들을 효율적으로 변경할 수 있다.

파이프라인 처리 명령들은 연속적인 처리를 위해 패킷을 다음 플로우 테이블로 보내는 것과, 메타데이터 형태의 정보들이 플로우 테이블들간 교환되도록 한다. 플로우 테이블들에 대한 파이프라인 처리는 매칭 플로우 엔트리와 연관된 명령어 집합이 다음 플로우 테이블을 특정하지 않는 경우에 중지된다. 이 시점에서 패킷은 일반적으로 수정되거나 포워딩된다.

또한, 플로우 엔트리는 패킷을 포트로 포워딩 할 수 있다. 여기서, 포트는 일반적인 물리적 포트를 의미할 수도 있고, 스위치(120)에 의해 정의된 논리적 포트를 의미할 수도 있다. 또한, 포트는 미리 정의된 예약 포트(reserved port)를 의미할 수도 있다. 예약 포트는 패킷을 컨트롤러(110)로 전송하거나, 플러딩(flooding), 또는 오픈플로우가 아닌 일반적인 방법을 통한 패킷 포워딩 등의 포괄적인 포워딩 처리를 규정할 수 있다. 한편, 스위치(120)에 의해 정의된 논리적 포트는 링크 통합 그룹(link aggregation group), 터널(tunnels) 또는 루프백 인터페이스(loopback interface)를 명시할 수 있다.

그룹 테이블은 복수의 그룹 엔트리(group entries)를 포함한다. 각 그룹 엔트리는 그룹의 유형과 관련된 특정 의미(semantics)를 가지는 액션 버킷 목록(action buckets list)을 포함할 수 있다. 여기서, 액션 버킷은 액션들 및 연관된 파라미터들의 집합을 의미한다. 하나 또는 하나 이상의 액션 버킷에 포함된 액션들은 패킷들을 그룹으로 전달할 수 있다.

컨트롤러(110)는 오픈플로우 프로토콜을 이용하여 각 스위치(120)의 플로우 테이블(121)에 플로우 엔트리들(flow entries)을 추가(add), 갱신(modify) 또는 삭제(delete)할 수 있다.

오픈플로우 프로토콜은 컨트롤러-투-스위치(controller-to-switch), 비동기(asynchronous) 및 대칭(symmetric)의 세 가지 메시지 타입을 지원하며, 각 메시지 타입은 복수의 서브 타입 메시지들을 포함한다.

컨트롤러-투-스위치 메시지는 컨트롤러(110)에 의해 생성되는 메시지로, 스위치(120)를 직접적으로 관리하거나 스위치(120)의 상태를 검색하기 위해 사용된다. 비동기 메시지는 스위치(120)에 의해 생성되는 메시지로, 네트워크 이벤트 및 스위치(120)의 상태 변화에 상응하여 컨트롤러(110)에 저장된 정보를 갱신하기 위해 사용된다. 대칭 메시지는 스위치(120) 또는 컨트롤러(110)에 의해 생성되는 메시지로, 별도의 요청 없이 양방향으로 전송되는 메시지이다.

컨트롤러-투-스위치 메시지는 역할 요청(Role-Request) 메시지, 상태 변경(Modify-State) 메시지 및 배리어(Barrier) 메시지 등을 포함한다. 역할 요청 메시지는 컨트롤러(110)가 자신의 역할을 설정하거나 역할의 질의하기 위해 사용하는 메시지로, 주로 스위치가 다중 컨트롤러와 연결된 환경에서 사용된다. 상태 변경 메시지는 스위치(120)의 상태를 관리하기 위해 컨트롤러(110)가 스위치(120)로 전송하는 메시지로, 스위치(120)의 오픈플로우 테이블(121)에서 플로우 또는 그룹 엔트리에 대해 추가, 삭제 및 변경이나, 스위치(120)의 포트 특성을 설정하기 위해 사용된다. 배리어 메시지는 배리어 요청 및 배리어 응답 메시지로 구성되고, 컨트롤러(110)가 스위치(120)에 전송한 메시지들간의 의존성 일치와, 스위치(120)가 메시지들의 실행 완료를 컨트롤러(110)에 통보하기 위해 사용된다.

비동기 메시지는 플로우 삭제(Flow-Removed), 포트 상태(Port-status) 메시지 등을 포함할 수 있다. 플로우 삭제 메시지는 스위치(120)가 플로우 테이블에서 플로우 엔트리가 삭제되었음을 스위치(120)에게 통보하기 위해 사용된다. 포트 상태 메시지는 스위치(120)가 포트의 변화를 통보하기 위해 사용된다.

대칭 메시지는 헬로(Hello), 에코(Echo), 에러(Error) 메시지 등을 포함할 수 있다. 헬로 메시지는 컨트롤러(110)와 스위치(120) 사이의 연결 생성시에 교환되는 메시지이다. 에코 메시지는 에코 요청 및 에코 응답 메시지로 구성되고, 스위치(120) 또는 컨트롤러(110)에 의해 전송될 수 있다. 에코 요청 메시지를 수신한 장치는 반드시 에코 응답 메시지를 전송해야 한다. 에러 메시지는 스위치(120) 또는 컨트롤러(110)에 의해 사용되는 메시지로 문제가 발생되었음을 연결 상대방에게 통보하기 위해 사용된다.

한편, 스위치는 하나의 컨트롤러와 연결을 생성할 수도 있고, 다중 컨트롤러와 연결을 생성할 수도 있다. 여기서, 스위치가 다중 컨트롤러와 연결을 생성하는 경우에는 하나의 컨트롤러와 연결을 생성하는 경우보다 신뢰성이 향상될 수 있다. 즉, 스위치가 다중 컨트롤러와 연결을 생성하는 경우, 스위치와 연결된 일부의 컨트롤러에 오류가 발생하거나 일부 컨트롤러와 연결이 해제되는 경우에도 스위치는 오픈 플로우 모드로 계속 동작을 수행할 수 있다.

다중 컨트롤러 환경에서 컨트롤러들은 컨트롤러-투-스위치 명령(commands)을 스위치에 전송할 수 있고, 스위치는 상기 컨트롤러-투-스위치 명령을 전송한 컨트롤러에게만 응답 또는 에러 메시지를 전송할 수 있다. 그러나, 비동기 메시지는 모든 컨트롤러에게 전송될 수 있다.

다중 컨트롤러 환경에서 각 컨트롤러의 기본 역할(default role)은 동등(equal) 이다. 역할이 동등인 컨트롤러들은 스위치에 대해 모든 액세스(full access) 권한을 가지며, 역할이 동등인 다른 컨트롤러들과 동일한 권한을 가진다. 컨트롤러는 슬레이브(slave)로 권한(또는 역할)을 변경할 수 있고, 슬레이브 컨트롤러는 스위치에 대해서 읽기 전용 접근(read-only access) 권한만 가진다. 또한, 컨트롤러는 마스터(master)로 권한을 변경할 수 있다. 마스터 컨트롤러는 동등 컨트롤러와 유사하게 스위치에 대해 모든 접근 권한을 가지나 스위치가 하나의 마스터 컨트롤러만 인정한다는 점에서 동등과 차이가 있다. 컨트롤러가 자신의 역할을 마스터로 변경하는 경우, 스위치는 기존의 마스터 역할을 가진 컨트롤러를 슬레이브 컨트롤러로 변환한다. 그러나, 스위치는 동등 모드로 동작하는 컨트롤러에 대해서는 역할을 변경하지 않는다. 또한, 컨트롤러의 역할이 마스터에서 슬레이브로 변경되어 스위치가 상기 컨트롤러의 역할을 변경할 때, 스위치는 컨트롤러 역할 상태 이벤트(role status event)를 생성하여 역할이 변경된 상기 컨트롤러에 역할 변경을 통보한다.

컨트롤러는 역할이 변경되면 자신의 역할이 변경되었음을 통보하기 위해 스위치에게 역할 요청(Role-Request) 메시지를 전송하고, 스위치는 역할 요청 메시지에 기초하여 자신과 연결된 스위치들의 역할을 변경하고 컨트롤러들의 변경된 역할을 기억한다. 스위치는 컨트롤러의 역할을 자체적으로 변경할 수 없고, 컨트롤러의 상태는 항상 컨트롤러의 요청에 의해서만 변경될 수 있다.

도 3은 다중 컨트롤러 환경에서 슬레이브 컨트롤러가 마스터 컨트롤러로 역할을 변경하는 과정을 나타내는 개념도이다.

도 3을 참조하면, 스위치(120)에 연결된 제1 컨트롤러(110-1)의 역할은 마스터이고, 제2 컨트롤러(110-2)의 역할은 슬레이브이며, 각 컨트롤러의 역할은 컨트롤러들간의 마스터 선출과정에 의해 미리 설정된 것으로 가정한다. 또한, 스위치(120)는 실제적으로 다수의 컨트롤러와 연결을 생성 및 유지할 수 있으나, 도 3에서는 설명의 편의를 위해 두 개의 컨트롤러(110-1, 110-2)가 스위치(120)에 연결된 것으로 예시하였다.

제1 컨트롤러(110-1)와 제2 컨트롤러(110-2)는 협상을 통해 서로의 역할을 변경하기로 결정하면, 마스터로 선출된 제2 컨트롤러(110-2)가 스위치(120)에게 역할 요청(Role-Request) 메시지를 전송한다. 여기서, 역할 요청 메시지는 컨트롤러가 자신의 역할을 설정하기 위해 사용하는 메시지로 컨트롤러-투-스위치(Controller-to-Switch) 타입의 메시지에 해당한다.

제2 컨트롤러(110-2)로부터 역할 요청 메시지를 수신한 스위치(120)는 자신과 연결된 기존의 마스터 컨트롤러인 제1 컨트롤러(110-1)의 역할을 슬레이브로 변경하고, 기존의 슬레이브 컨트롤러인 제2 컨트롤러(110-2)를 마스터 컨트롤러로 변경한다.

스위치(120)는 마스터 컨트롤러를 변경한 이후, 새로 마스터로 선출된 제2 컨트롤러(110-2)가 전송하는 명령만 수용하며, 보조 컨트롤러로 전환된 제1 컨트롤러(110-1)가 전송하는 트래픽 제어와 관련된 모든 명령은 거절한다.

도 4는 다중 컨트롤러 환경에서 슬레이브 컨트롤러가 마스터 컨트롤러로 역할을 변경하는 과정을 나타내는 순서도이다.

컨트롤러가 자신의 역할을 마스터 또는 슬레이브로 변경하기 위해서는 컨트롤러들 상호간의 마스터 선출과정을 거치게 되는데, 이 과정에서 컨트롤러들간 제너레이션 아이디(generation_id)의 할당이 조정된다. 제너레이션 아이디는 단순하게 증가하는 카운터 값으로 구성될 수 있고, 새로운 마스터가 선출될 때마다 값이 증가하도록 구성될 수 있다. 즉, 새로 마스터로 선출된 컨트롤러는 기존의 마스터 컨트롤러가 가지는 제너레이션 아이디 보다 더 큰 값의 제너레이션 아이디를 가지게 된다.

도 4를 참조하면, 신규 마스터가 선출되기 전에 마스터 컨트롤러인 제1 컨트롤러(110-1)는 컨트롤러-투-스위치(120) 메시지를 통해 스위치(120)에 명령을 제공한다(S401). 이 때, 제1 컨트롤러(110-1)가 가지는 제너레이션 아이디는 n(즉, generation_id=n)이라 가정한다. 또한, 제2 컨트롤러(110-2)의 역할은 슬레이브로 가정한다.

이후, 제1 컨트롤러(110-1)와 제2 컨트롤러(110-2)가 마스터 선출과정을 통해 제2 컨트롤러(110-2)가 새로운 마스터 컨트롤러로 선출되면, 제2 컨트롤러(110-2)의 제너레이션 아이디는 n+1(즉, generation_id=n+1)로 증가한다(S403).

새로운 마스터로 선출된 제2 컨트롤러(110-2)는 자신의 역할이 마스터로 변경되었음을 스위치(120)에게 통보하기 위해 역할 요청(Role-Request) 메시지를 스위치(120)에 전송한다(S405). 여기서, 역할 요청 메시지에는 제2 컨트롤러(110-2)의 제너레이션 아이디(즉, generation_id=n+1)가 포함된다.

스위치(120)는 제2 컨트롤러(110-2)로부터 역할 요청 메시지를 수신하고, 수신한 메시지에 포함된 제너레이션 아이디를 기존에 저장된 제너레이션 아이디와 비교하여 제너레이션 아이디가 증가한 경우, 제2 컨트롤러(110-2)의 역할을 마스터로 변경하고, 제2 컨트롤러(110-2)에 역할 응답 메시지를 전송한다(S407).

이후, 스위치(120)는 제1 컨트롤러(110-1)로부터 수신한 제어 명령은 더 이상 수용하지 않고(S409), 제2 컨트롤러(110-2)로부터 전송된 제어 명령만 수용하여 실행한다(S411).

도 3 및 도 4에 예시한 컨트롤러 역할 변경 방법에서는, 스위치에 연결된 복수의 컨트롤러 중 하나가 임의로 역할 요청 메시지를 스위치로 통보하는 경우, 스위치는 컨트롤러들간의 마스터 선출과정에서 증가하는 제너레이션 아이디의 비교만을 수행하여, 역할 요청 메시지에 포함된 제너레이션 아이디가 기존의 제너레이션 아이디 보다 크면 역할 변경을 즉시 수용하여 역할 변경 메시지를 전송한 컨트롤러의 역할을 마스터로 변경하고, 다른 컨트롤러의 마스터모드 동작을 차단한다.

상술한 바와 같은 스위치에서의 컨트롤러 역할 변경 방법은 컨트롤러가 스위치에 일방적으로 전송하는 역할 요청 메시지에 전적으로 의존할 뿐, 컨트롤러의 역할 변경에 대한 컨트롤러와 스위치간의 상호 확인 절차가 없다. 따라서, 임의의 컨트롤러가 악의적으로 역할을 변경하거나, 비정상적인 컨트롤러로부터 일방적으로 제공되는 메시지에 의해 스위치에서 컨트롤러의 역할이 임의로 변경되는 경우 트래픽 제어에 혼란이 발생할 수 있다.

스위치는 마스터 컨트롤러부터 주요 트래픽 제어 명령을 전달 받기 때문에, 마스터 컨트롤러의 역할이 매우 중요하다. 따라서, 스위치를 제어하는 마스터 컨트롤러의 역할 변경 과정에서는 신뢰성이 반드시 보장되어야 한다.

이하에서는 상술한 요구사항을 만족시킬 수 있는 본 발명의 실시예에 따른 컨트롤러의 제어 권한(또는 역할) 변경 방법을 설명한다.

도 5는 본 발명의 일 실시예에 따른 컨트롤러의 역할 변경 방법을 나타내는 순서도이다.

도 5는 스위치(520)가 제1 컨트롤러(510-1) 및 제2 컨트롤러(510-2)와 연결을 유지하고 있는 상황에서 제2 컨트롤러(510-2)의 역할이 슬레이브에서 마스터로 변경되는 과정을 예시한 것이다. 도 5에서 제1 컨트롤러(510-1)의 초기 역할은 마스터이고, 제2 컨트롤러(510-2)의 초기 역할을 슬레이브인 것으로 가정한다.

초기에 마스터 컨트롤러로 설정된 제1 컨트롤러(510-1)는 미리 정의된 제어 메시지(예를 들면, 컨트롤러-투-스위치)를 이용하여 스위치(520)에게 트래픽 제어 관련 명령을 제공한다(S501). 이 때, 제1 컨트롤러(510-1)는 마스터 컨트롤러에게 할당되는 식별 정보를 가질 수 있다. 여기서 식별 정보는 다양한 값 또는 데이터로 구성될 수 있고, 새로 선출된 마스터 컨트롤러에 할당되는 식별 정보는 기존의 마스터 컨트롤러에 할당된 식별 정보가 증가된 값으로 구성되거나 기존의 식별 정보와 다른 데이터를 가지도록 구성될 수 있으나, 이하에서는 설명의 편의를 위하여 식별 정보가 제너레이션 아이디인 것으로 가정하고, 새로 선출되는 마스터는 기존의 제너레이션 아이디가 증가된 값을 가지는 것으로 가정한다. 도 5에서 제1 컨트롤러(510-1)의 제너레이션 아이디는 n(즉, generation_id=n)으로 가정한다.

이와 같은 상황에서, 제2 컨트롤러(510-2)가 마스터로 역할을 변경하고자 하면 제1 컨트롤러(510-1)와 제2 컨트롤러(510-2)는 마스터 선출과정을 수행한다. 그리고, 마스터 선출 과정을 통해 제2 컨트롤러(510-2)가 새로운 마스터로 선출되면, 제2 컨트롤러(510-2)는 제1 컨트롤러(510-1)의 제너레이션 아이디(generation_id=n) 보다 더 큰 제너레이션 아이디(generation_id=n+1)를 획득하게 된다(S503).

이후, 새로운 마스터로 선출된 제2 컨트롤러(510-2)는 자신의 역할이 마스터로 변경되었음을 통보하기 위한 메시지(이하, 역할 요청(Role-Request) 메시지라 지칭함)를 스위치(520)에 전송한다(S505). 여기서, 역할 요청 메시지에는 제2 컨트롤러(510-2)의 제너레이션 아이디(즉, generation_id=n+1)가 포함될 수 있다.

스위치(520)는 제2 컨트롤러(510-2)로부터 역할 요청 메시지를 수신하고, 수신한 메시지에 포함된 제너레이션 아이디를 기존에 저장된 제너레이션 아이디와 비교하여 제너레이션 아이디의 증가 여부를 판단한다. 스위치(520)는 역할 요청 메시지에 포함된 제너레이션 아이디가 기존의 제너레이션 아이디 보다 더 큰 경우에는 제2 컨트롤러(510-2)의 역할 변경을 위한 상호 확인 절차(S507, S509)를 수행하고, 역할 요청 메시지에 포함된 제너레이션 아이디가 기존의 제너레이션 아이디 보다 크지 않은 경우에는 제2 컨트롤러(510-2)의 역할 변경을 위한 상호 확인 절차(S507, S509)를 수행하지 않을 수 있다. 또한, 역할 요청 메시지에 포함된 제너레이션 아이디가 기존의 제너레이션 아이디 보다 크지 않은 경우, 스위치(520)는 제2 컨트롤러(510-2) 및/또는 제1 컨트롤러(510-1)에 역할 변경에 오류가 발생하였음을 지시하는 오류 메시지를 전송하고, 제1 컨트롤러(510-1)의 역할을 마스터로 계속 유지할 수 있다.

도 5에서는 역할 요청 메시지에 포함된 제너레이션 아이디가 기존의 제너레이션 아이디 보다 더 큰 것으로 가정하고, 스위치(520)가 제2 컨트롤러(510-2)의 역할 변경을 위한 상호 확인 절차(S507, S509)를 수행하는 과정을 예시하였다. 상호 확인 절차는 컨트롤러의 역할 변경이 마스터 선출과정에 의해 정상적으로 수행되었는지를 확인하는 과정으로, 스위치(520)와 이전의 마스터 컨트롤러(도 5에서는 제1 컨트롤러(510-1))가 수행하는 절차를 의미할 수 있다.

스위치(520)는 제1 컨트롤러(510-1)에게 제너레이션 아이디(generation_id=n+1)를 포함하는 상태 확인 요청 메시지를 전송한다(S507). 여기서 상태 확인 요청 메시지는 다양한 형태로 구성될 수 있고, 예를 들어 에코 요청(Echo Request) 메시지로 구성될 수 있다.

제1 컨트롤러(510-1)는 스위치(520)로부터 상태 확인 요청 메시지를 수신하면, 상태 확인 요청 메시지에 포함된 제너레이션 아이디(generation_id=n+1)와 자신의 제너레이션 아이디(generation_id=n)를 비교한다. 제1 컨트롤러(510-1)는 상태 확인 요청 메시지에 포함된 제너레이션 아이디가 자신의 제너레이션 아이디 보다 더 큰 경우, 상태 확인 요청 메시지에 포함된 제너레이션 아이디가 마스터 선출과정에서 선출된 제2 컨트롤러(510-2)의 제너레이션 아이디임을 확인하고, 스위치(520)에 상태 확인 응답 메시지를 전송한다(S509). 여기서, 상태 확인 응답 메시지는 역할 변경의 유효성 여부 정보 또는 제1 컨트롤러(510-1)의 역할 정보를 포함할 수 있다. 상태 확인 응답 메시지는 다양한 형태로 구성될 수 있고, 예를 들어 에코 응답(Echo Reply) 메시지로 구성될 수 있다.

스위치(520)는 제1 컨트롤러(510-1)로부터 상태 확인 응답 메시지를 수신하면, 수신한 메시지에 기초하여 제2 컨트롤러(510-2)의 역할이 정상적으로 변경되었는가를 판단한다. 스위치(520)는 제2 컨트롤러(510-2)의 역할 변경이 정상적으로 수행된 것으로 판단되는 경우 제2 컨트롤러(510-2)에게 역할 응답(Role-Request) 메시지를 전송하고, 스위치(520)내에서 제2 컨트롤러(510-2)의 역할을 마스터로 변경 한다(S511).

상기한 바와 같이 스위치(520)에서 제2 컨트롤러(510-2)에 대한 역할 변경이 완료되면, 스위치(520)는 새로운 마스터인 제2 컨트롤러(510-2)로부터 전송되는 제어 메시지(예를 들면, 컨트롤러-투-스위치 메시지)만 수용하고(S513), 제1 컨트롤러(510-1)로부터 전송되는 트래픽 제어 메시지는 수용하지 않는다(S515).

도 6은 본 발명의 일 실시예에 따른 컨트롤러의 역할 변경 과정을 보다 상세하게 나타내는 순서도이다.

도 6은 스위치(520)가 제1 컨트롤러(510-1) 및 제2 컨트롤러(510-2)와 연결을 유지하고 있는 상황에서, 제1 컨트롤러(510-1)와 제2 컨트롤러(510-2)가 마스터 선출과정을 통해 제2 컨트롤러(510-2)가 마스터로 선출된 경우의 역할 변경 과정을 예시한 것이다.

새로운 마스터 컨트롤러로 선출된 제2 컨트롤러(510-2)는 스위치(520)에 역할 요청 메시지를 전송한다(S601). 여기서, 역할 요청 메시지에는 제2 컨트롤러(510-2)의 제너레이션 아이디가 포함될 수 있다.

스위치(520)는 제2 컨트롤러(510-2)로부터 역할 요청 메시지를 수신하면, 제2 컨트롤러(510-2)의 제너레이션 아이디를 포함하는 상태 확인 요청 메시지를 제1 컨트롤러(510-1)에 전송한다(S603).

제1 컨트롤러(510-1)는 스위치(520)로부터 상태 확인 요청 메시지를 수신하면, 상태 확인 요청 메시지에 포함된 제너레이션 아이디(즉, 제2 컨트롤러(510-2)의 제너레이션 아이디)를 자신의 제너레이션 아이디와 비교하고(S605), 비교 결과에 기초하여 자신의 역할을 확인한다(S607).

이후, 제1 컨트롤러(510-1)는 제너레이션 아이디의 비교 결과에 상응하는 상태 확인 응답 메시지를 스위치(520)에 전송한다(S609). 여기서, 상기 상태 확인 응답 메시지는 제1 컨트롤러(510-1)의 현재 역할(role) 정보를 포함할 수도 있고, 역할 변경의 유효성 검증 결과를 지시하는 정보를 포함할 수도 있다. 또한, 상태 확인 응답 메시지는 제1 컨트롤러(510-1)의 제너레이션 아이디를 포함할 수도 있고, 제1 컨트롤러(510-1)의 역할을 지시하는 식별 정보를 포함할 수도 있다.

스위치(520)는 제1 컨트롤러(510-1)로부터 상태 확인 응답 메시지를 수신하면, 수신한 메시지에 포함된 정보에 기초하여 제2 컨트롤러(510-2)의 역할 변경의 유효성을 판단한다(S611). 여기서, 스위치(520)는 상태 확인 응답 메시지에 포함된 제1 컨트롤러(510-1)의 역할 정보가 슬레이브임을 지시하는 경우 제2 컨트롤러(510-2)의 역할 변경이 유효한 것으로 판단할 수 있다.

스위치(520)는 제2 컨트롤러(510-2)의 역할 변경이 정상적으로 수행된 것으로 판단되는 경우 제2 컨트롤러(510-2)에게 역할 응답(Role-Request) 메시지를 전송하고(S613), 스위치(520)내에서 제2 컨트롤러(510-2)의 역할을 마스터로 변경 한다(S617).

스위치(520)로부터 역할 응답 메시지를 수신한 제2 컨트롤러(510-2)는 자신의 역할을 마스터로 변경하고 스위치(520)에 대한 마스터 컨트롤러의 역할을 수행한다(S615).

도 7은 본 발명의 다른 실시예에 따른 컨트롤러의 역할 변경 과정을 나타내는 순서도로, 스위치가 컨트롤러의 역할 요청을 거절하는 과정을 보다 상세하게 나타낸 것이다.

도 7은 스위치(520)가 제1 컨트롤러(510-1) 및 제2 컨트롤러(510-2)와 연결을 유지하고 있는 상황에서, 스위치(520)가 제2 컨트롤러(510-2)의 역할 요청을 거절하는 과정을 예시한 것이다.

먼저, 제2 컨트롤러(510-2)는 스위치(520)에 역할 요청 메시지를 전송한다(S701). 여기서, 역할 요청 메시지에는 제2 컨트롤러(510-2)의 제너레이션 아이디가 포함될 수 있다.

스위치(520)는 제2 컨트롤러(510-2)로부터 역할 요청 메시지를 수신하면, 제2 컨트롤러(510-2)의 제너레이션 아이디를 포함하는 상태 확인 요청 메시지를 제1 컨트롤러(510-1)에 전송한다(S703).

제1 컨트롤러(510-1)는 스위치(520)로부터 상태 확인 요청 메시지를 수신하면, 상태 확인 요청 메시지에 포함된 제너레이션 아이디(즉, 제2 컨트롤러(510-2)의 제너레이션 아이디)를 자신의 제너레이션 아이디와 비교하고, 상태 확인 요청 메시지에 포함된 제너레이션 아이디가 자신의 제너레이션 아이디 보다 더 큰 값인가를 판단한다(S705).

이후, 제1 컨트롤러(510-1)는 제너레이션 아이디의 비교 결과에 따라, 스위치(520)에 역할 변경이 유효함을 지시하는 상태 확인 응답 메시지를 전송하거나, 역할 변경이 유효하지 않음을 지시하는 역할 오류 응답 메시지를 스위치(520)에 전송할 수 있다.

여기서, 제1 컨트롤러(510-1)는 상태 확인 요청 메시지에 포함된 제너레이션 아이디가 자신의 제너레이션 아이디 보다 더 큰 값을 가지는 경우에는 자신의 역할을 확인한 후(S707), 자신의 역할 정보를 포함하는 상태 확인 응답 메시지를 스위치(520)에 전송할 수 있다(S709).

또는, 제1 컨트롤러(510-1)는 상태 확인 요청 메시지에 포함된 제너레이션 아이디가 자신의 제너레이션 아이디 보다 큰 값이 아닌 경우에는 에러 정보를 포함하는 오류 응답 메시지를 스위치(520)에 전송할 수 있다(S711). 또는 제1 컨트롤러(510-1)는 상태 확인 요청 메시지에 포함된 제너레이션 아이디가 자신의 제너레이션 아이디 보다 큰 값이 아닌 경우에는 스위치(520)에 아무런 메시지를 전송하지 않도록 구성될 수도 있고, 이와 같이 구성되는 경우 스위치(520)는 미리 설정된 시간 동간 제1 컨트롤러(510-1)로부터 아무런 응답 메시지가 전송되지 않는 경우 제2 컨트롤러(510-2)의 역할 변경에 유효성이 없는 것으로 판단하도록 구성될 수도 있다.

스위치(520)는 제1 컨트롤러(510-1)로부터 수신한 응답 메시지에 기초하여 제2 컨트롤러(510-2)의 역할 변경에 대한 유효성 여부를 판단한다(S713). 여기서, 스위치(520)는 제1 컨트롤러(510-1)로부터 오류 응답 메시지를 수신한 경우에는 제2 컨트롤러(510-2)에게 역할 변경의 거절을 지시하는 역할 응답 메시지를 전송하고(S715), 스위치(520) 내에서 기존의 마스터 컨트롤러를 변경하지 않을 수 있다(S717).

또는, 스위치(520)는 제1 컨트롤러(510-1)로부터 상태 확인 응답 메시지를 수신하는 경우에는 역할 응답 메시지에 포함된 제1 컨트롤러(510-1)의 역할을 확인하여 마스터 컨트롤러의 역할이 정상적으로 변경되었는가를 확인한다. 여기서, 제1 컨트롤러(510-1)의 역할이 마스터를 지시하는 경우, 스위치(520)는 역할 변경이 정상적으로 이루어지지 않은 것으로 판단하고 제2 컨트롤러(510-2)에게 오류 메시지를 전송할 수 있다.

또는, 스위치(520)가 미리 설정된 시간 동안 제1 컨트롤러(510-1)로부터 아무런 응답 메시지를 수신하지 못하는 경우에는 제2 컨트롤러(510-2)에게 역할 오류 메시지를 전송하고, 스위치(520) 내에서 마스터 컨트롤러의 역할을 변경하지 않도록 구성될 수도 있다.

제2 컨트롤러(510-2)는 스위치(520)로부터 역할 오류 메시지를 수신하면, 자신의 역할의 변경하지 않고 기존의 역할을 그대로 수행할 수 있다(S719).

또는, 제2 컨트롤러(510-2)는 스위치(520)로부터 역할 오류 메시지를 수신하거나, 미리 설정된 시간 동안 역할 변경의 수락을 지시하는 역할 응답(Role-Request) 메시지를 수신하지 못하는 경우, 역할 변경을 요청하는 역할 요청 메시지를 스위치(520)에게 재전송할 수도 있다. 여기서, 스위치(520)는 제2 컨트롤러(510-2)로부터 미리 정해진 회수의 역할 요청 메시지를 수신하는 경우, 역할 변경을 수락하도록 구성될 수도 있다.

또한, 도 5 내지 도 7에서는 스위치(520)가 제1 컨트롤러(510-1)에게만 상태 확인 요청 메시지를 전송하는 것으로 예시하였으나, 스위치(520)가 복수의 슬레이브 컨트롤러와 연결된 경우, 스위치(520)는 모든 슬레이브 컨트롤러에 상태 확인 요청 메시지를 전송하지 않고, 이전의 마스터 컨트롤러에게만 상태 확인 요청 메시지를 전송하도록 구성될 수 있다.

도 8은 본 발명의 실시예에 따른 컨트롤러의 역할 변경 과정에서 사용되는 메시지의 일 예를 나타내는 것으로, 상태 확인 요청(State Request) 메세지와 상태 확인 응답(State Reply) 메시지의 구조를 예를 들어 도시한 것이다.

상태 확인 요청 메시지 및 상태 확인 응답 메시지는 동일한 포맷으로 구성될 수 있고, 버전(version), 타입(type), 길이(length), 트랜잭션 아이디(xid), 제너레이션 아이디(generation_id) 및 역할(Role) 필드를 포함할 수 있다.

버전(version) 필드는 1 바이트(byte)로 구성될 수 있고, 프로토콜의 버전을 나타낸다.

타입(type) 필드는 1 바이트로 구성될 수 있고, 메시지의 유형을 나타낸다.

길이(length) 필드는 2 바이트로 구성될 수 있고, 메시지의 길이를 나타낸다.

트랜잭션 아이디(xid) 필드는 4 바이트로 구성될 수 있고, 메시지의 요청시 발생한 트랜잭션 아이디를 나타낸다.

제너레이션 아이디(generation_id) 필드는 8 바이트로 구성될 수 있고, 새로 선출된 마스터 컨트롤러의 제너레이션 아이디를 나타낸다.

역할(Role) 필드는 4 바이트로 구성될 수 있고, 컨트롤러의 역할을 나타낸다. 여기서, 컨트롤러의 역할은 마스터(master), 슬레이브(slave), 동등(equal) 중 어느 하나로 설정될 수 있다.

스위치가 컨트롤러에게 상태 확인 요청(State Request) 메시지를 생성하여 전송할 때, 스위치는 제너레이션 아이디 필드에 해당 값을 설정하여 전송할 수 있고, 컨트롤러는 상태 확인 응답 메시지를 생성하여 스위치에 전송할 때 상기 역할 필드에 자신의 역할을 설정하여 전송할 수 있다.

도 9는 본 발명의 실시예에 따른 컨트롤러의 역할 변경 방법을 수행하는 컨트롤러 및 스위치의 구성을 나타내는 블록도이다.

도 9를 참조하면, 컨트롤러(510)는 프로토콜 처리부(511), 마스터 선출부(512), 역할 관리부(513)를 포함할 수 있다.

프로토콜 처리부(511)는 미리 정의된 프로토콜에 따라 스위치(520)와 통신하기 위한 처리를 수행한다. 즉, 프로토콜 처리부(511)는 미리 정의된 프로토콜에 따라 스위치(520)의 트래픽 제어 및 관리를 수행할 수 있다. 프로토콜 처리부(511)는 예를 들어 오픈플로우 프로토콜 또는 I2RS에서 정의된 프로토콜에 따라 스위치(520)의 제어 및 관리를 수행할 수 있다.

마스터 선출부(512)는 다른 컨트롤러의 마스터 선출부와 협상에 의해 마스터 선출을 수행한다. 여기서, 마스터 선출부(512)는 다른 컨트롤러의 마스터 선출부와 마스터 선출과 관련된 메시지를 송수신할 수 있고, 이를 통해 마스터를 선출할 수 있다.

역할 관리부(513)는 컨트롤러(510)의 역할 변경과 관련된 처리를 수행한다. 예를 들어, 역할 관리부(513)는 컨트롤러(510)의 현재 역할과 관련된 식별정보(예를 들면, generation_id)를 관리할 수 있고, 컨트롤러(510)의 역할 변경시 필요한 절차를 수행할 수 있다. 즉, 역할 변경부는 컨트롤러(510)가 마스터로 역할을 변경하는 경우에는 스위치(520)에 역할 요청 메시지를 전송할 수 있고, 스위치(520)로부터 수신한 응답 메시지에 기초하여 역할을 변경하거나 유지할 수 있다. 또는 컨트롤러(510)가 마스터에서 슬레이브로 역할을 변경하는 경우, 역할 관리부(513)는 스위치(520)로부터 역할 확인을 요청하는 상태 확인 요청 메시지를 수신하고, 이에 응답하여 자신의 역할을 판단한 후 역할 정보를 포함하는 상태 확인 응답 메시지를 스위치(520)에 전송할 수 있다.

스위치(520)는 프로토콜 처리부(521), 컨트롤러 역할 관리부(522) 및 트래픽 처리부(523)를 포함할 수 있다.

프로토콜 처리부(521)는 미리 정의된 프로토콜에 따라 컨트롤러(510)와 통신하기 위한 처리를 수행한다. 즉, 프로토콜 처리부(521)는 미리 정의된 프로토콜에 따라 컨트롤러(510)로부터 제어 명령을 수신하거나, 수신한 제어 명령에 대한 응답을 컨트롤러(510)로 전송할 수 있다. 프로토콜 처리부(521)는 예를 들어 오픈플로우 프로토콜 또는 I2RS에서 정의된 프로토콜에 따라 컨트롤러(510)와 통신할 수 있다.

컨트롤러 역할 관리부(522)는 컨트롤러(510)의 역할과 관련된 처리를 수행한다. 예를 들어, 컨트롤러 역할 관리부(522)는 임의의 컨트롤러로부터 역할 요청 메시지를 수신하면, 이전의 마스터 컨트롤러에게 역할 변경의 확인을 요청하는 상태 확인 요청 메시지를 전송할 수 있다. 또한, 컨트롤러 역할 관리부(522)는 이전의 마스터 컨트롤러로부터 상태 확인 응답 메시지를 수신하면 수신한 메시지에 기초하여 역할 변경의 유효성을 검증하고, 검증 결과에 기초하여 역할 변경을 요청한 컨트롤러에게 역할 변경 수락 또는 역할 변경 거절을 지시하는 응답 메시지를 전송할 수 있다. 여기서, 역할 변경의 유효성이 검증된 경우, 컨트롤러 역할 관리부(522)는 역할 변경을 요청한 컨트롤러의 역할을 마스터로 변경할 수 있다.

트래픽 처리부(523)는 컨트롤러(510)의 제어에 기초하여 트래픽을 처리하는 기능을 수행한다. 여기서, 트래픽 처리부(523)는 컨트롤러(510)의 제어에 따라 오픈플로우 테이블을 관리할 수 있고, 오픈플로우 테이블에 기초하여 트래픽을 처리할 수 있다.

이상 실시예를 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.

110 : 컨트롤러 110-1 : 제1 컨트롤러
110-2 : 제2 컨트롤러 120 : 스위치
121 : 플로우 테이블 123 : 그룹 테이블
125 : 오픈플로우 채널 201 : 매치 필드
202 : 우선순위 203 : 카운터
204 : 명령어 205 : 타임아웃
206 : 쿠키 510 : 컨트롤러
510-1 : 제1 컨트롤러 510-2 : 제2 컨트롤러
511 : 프로토콜 처리부 512 : 마스터 선출부
513 : 역할 관리부 520 : 스위치
521 : 프로토콜 처리부 522 : 컨트롤러 역할 관리부
523 : 트래픽 처리부

Claims (14)

1. 통신장치에서 수행되는 제어 권한 변경 방법에 있어서,
   새로운 주제어장치인 제2 제어장치로부터 상기 제2 제어장치의 역할을 주제어장치로 변경할 것을 요청하는 역할 변경 요청 메시지를 수신하는 단계;
   이전의 주제어장치인 제1 제어장치로 제어 권한 변경의 확인을 위한 상태 요청 메시지를 전송하는 단계; 및
   상기 제1 제어장치로부터 수신한 상태 확인 메시지에 따라 상기 제2 제어장치의 주제어장치 역할 변경에 대한 수락 여부를 결정하는 단계를 포함하되,
   상기 상태 요청 메시지를 전송하는 단계는,
   상기 제2 제어장치의 역할을 나타내는 식별 정보를 상기 상태 요청 메시지에 포함시켜 전송하는 것을 특징으로 하는 제어 권한 변경 방법.
2. 청구항 1에 있어서,
   상기 역할 변경 요청 메시지는,
   상기 제2 제어장치의 역할이 주제어장치임을 나타내는 식별 정보를 포함하는 것을 특징으로 하는 제어 권한 변경 방법.
3. 청구항 2에 있어서,
   상기 식별 정보는
   상기 제1 제어장치의 식별 정보가 증가된 값인 것을 특징으로 하는 제어 권한 변경 방법.
4. 청구항 2에 있어서,
   상기 식별 정보는 제너레이션 아이디(generation ID)인 것을 특징으로 하는 제어 권한 변경 방법.
5. 삭제
6. 청구항 1에 있어서,
   상기 제2 제어장치의 주제어장치 역할 변경에 대한 수락 여부를 결정하는 단계는,
   상기 상태 확인 메시지에 기초하여 상기 제1 제어장치의 역할을 확인하는 단계;
   상기 제1 제어장치의 역할이 변경된 경우 상기 제2 제어장치를 주제어장치로 변경하는 단계; 및
   상기 제2 제어장치에 상기 제2 제어장치가 주제어장치로 변경되었음을 지시하는 역할 변경 응답 메시지를 전송하는 단계를 포함하는 것을 특징으로 하는 제어 권한 변경 방법.
7. 청구항 1에 있어서,
   상기 제2 제어장치의 주제어장치 역할 변경에 대한 수락 여부를 결정하는 단계는,
   상기 상태 확인 메시지에 기초하여 상기 제1 제어장치의 역할 변경을 확인하는 단계;
   상기 제1 제어장치의 역할이 변경되지 않은 경우, 상기 제1 제어장치를 주제어장치로 유지하는 단계; 및
   상기 제2 제어장치의 역할이 변경되지 않았음을 지시하는 오류 메시지를 상기 제2 제어장치에 전송하는 단계를 포함하는 것을 특징으로 하는 제어 권한 변경 방법.
8. 제2 제어장치에서 수행되는 제어 권한 변경 방법으로,
   상기 제2 제어장치의 역할을 주제어장치로 변경할 것을 요청하는 역할 변경 요청 메시지를 통신장치에 전송하는 단계;
   상기 통신장치로부터 역할 변경 수락 또는 역할 변경 오류를 지시하는 역할 변경 응답 메시지를 수신하는 단계; 및
   상기 통신장치로부터 역할 변경 수락을 지시하는 메시지를 수신하는 경우 역할을 주제어장치로 변경하는 단계를 포함하되,
   상기 역할 변경 응답 메시지를 수신하는 단계는,
   상기 역할 변경 응답 메시지가 오류를 지시하는 경우, 상기 제2 제어장치의 제어 권한을 변경하지 않는 단계를 포함하는 것을 특징으로 하는 제어 권한 변경 방법.
9. 청구항 8에 있어서,
   상기 역할 변경 요청 메시지는
   상기 제2 제어장치가 주제어장치임을 나타내는 제너레이션 아이디 및 역할 정보를 포함하는 것을 특징으로 하는 제어 권한 변경 방법.
10. 삭제
11. 통신장치에서 수행되는 제어 권한 변경 방법에 있어서,
    새로운 주제어장치인 제2 제어장치로부터 상기 제2 제어장치의 역할을 주제어장치로 변경할 것을 요청하는 역할 변경 요청 메시지를 수신하는 단계;
    상기 역할 변경 요청 메시지에 포함된 식별 정보를 기저장된 식별 정보와 비교하여 역할 변경 요청에 대한 유효성을 판단하는 단계;
    상기 역할 변경 요청 메시지의 유효성이 없는 경우 상기 제2 제어장치에 오류 메시지를 전송하는 단계; 및
    상기 역할 변경 요청 메시지의 유효성이 있는 경우, 상기 제2 제어장치에 상기 제2 제어장치의 역할 정보를 포함하는 역할 변경 응답 메시지를 전송하는 단계를 포함하는 제어 권한 변경 방법.
12. 청구항 11에 있어서,
    상기 식별 정보는 제너레이션 아이디인 것을 특징으로 하는 제어 권한 변경 방법.
13. 청구항 12에 있어서,
    상기 역할 변경 요청에 대한 유효성을 판단하는 단계는,
    상기 역할 변경 요청 메시지에 포함된 제너레이션 아이디를 기저장된 제너레이션 아이디와 비교하는 단계; 및
    상기 역할 변경 요청 메시지에 포함된 제어레이션 아이디가 상기 기저장된 제너레이션 아이디 보다 크지 않은 경우 상기 역할 변경 요청 메시지의 유효성이 없는 것으로 판단하는 단계를 포함하는 것을 특징으로 하는 제어 권한 변경 방법.
14. 삭제

Images