KR102275765B1 - 소프트웨어 정의 네트워크에서 플로우 룰 트랜잭션을 처리하는 방법, 장치 및 컴퓨터 프로그램 - Google Patents

Abstract

본 발명의 실시예를 따르는 소프트웨어 정의 네트워크의 컨트롤러에서 플로우 룰 데이터베이스를 운영하는 방법은, 상기 네트워크에 포함된 스위치 식별정보, 상기 스위치 각각에 적용된 플로우 테이블 식별 정보, 상기 네트워크에 적용할 수 있는 플로우 룰의 모든 매치 필드 항목, 상기 매치 필드 항목의 내용 및 상기 플로우 룰의 인스트럭션을 기록하기 위한 제 1 테이블을 생성하는 a 단계; 적어도 하나 이상의 플로우 룰을 하나의 단위로 적용하기 위한 트랜잭션의 식별 정보를 기록하는 제 2 테이블을 생성하고, 상기 제 1 테이블에 상기 트랜잭션의 식별 정보를 기록하기 위한 트랜잭션 필드를 생성하는 b 단계; 임의의 트랜잭션이 시작되고, 상기 트랜잭션에 포함된 제 1 플로우 룰 추가 메시지 및/또는 제 2 플로우 룰 삭제 메시지를 상기 트랜잭션 식별 정보와 함께 상기 제 1 테이블에 기록하는 c 단계; 상기 트랜잭션이 적용 (commit)되면, 상기 제 1 테이블의 상기 트랜잭션 식별 정보를 미리 설정된 값으로 변경하고, 상기 트랜잭션 식별정보가 변경된 경우에 한하여 모든 어플리케이션에서 상기 제 1 플로우 룰 추가 및/또는 상기 제 2 플로우 룰 삭제된 내용이 상기 제 1 테이블에서 조회되도록 설정하는 d 단계를 포함하는 것을 특징으로 한다.

Description

소프트웨어 정의 네트워크에서 플로우 룰 트랜잭션을 처리하는 방법, 장치 및 컴퓨터 프로그램 {METHOD, APPARATUS AND COMPUTER PROGRAM FOR PROCESSING FLOW RULE TRANSACTIONS IN SOFTWARE DEFINED NETWORK}

본 발명은 소프트웨어 정의 네트워크를 제어하는 방법 및 장치에 대한 것이다. 보다 구체적으로 본 발명은 소프트웨어 정의 네트워크에서 적어도 하나 이상의 플로우 룰을 하나의 오퍼레이션으로 적용하여 저장소의 플로우 룰 데이터베이스 변경의 원자성을 보장하고, 나아가 스위치와 저장소의 플로우 룰의 동기화를 보장하는 방법 및 장치에 대한 것이다.

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

SDN 시스템은 일반적으로 전체 네트워크를 제어하는 컨트롤러 서버, 상기 컨트롤러 서버에 의해 제어되며 패킷을 처리하는 복수의 오픈플로우 스위치, 및 오픈플로우 스위치의 하위 계층에 해당하는 호스트를 포함하여 구성될 수 있다.

오픈플로우 스위치는 패킷의 송수신 기능만을 담당하며, 패킷의 경로 설정, 관리 및 제어는 모두 컨트롤러 서버에서 이루어진다. 즉, 네트워크 장비를 이루는 데이터 플레인(Data Plane)과 컨트롤 플레인(Control Plane)을 분리하는 것이 SDN 시스템의 기본 구조라 볼 수 있다.

OpenFlow Switch Specification Version 1.5.0 (2014.12.19)

본 발명은 SDN 환경에서 적어도 하나 이상의 플로우 룰을 하나의 오퍼레이션으로 적용하기 위하여 플로우 룰 트랜잭션 (transaction)을 처리하는 방법 및 장치를 제공하는 것을 목적으로 한다. 나아가 본 발명은 스위치의 플로우 테이블과 저장소의 플로우 룰 데이터베이스의 동기화 및 원자성을 보장하는 방법 및 장치를 제공하는 것을 목적으로 한다.

본 발명의 실시예를 따르는 소프트웨어 정의 네트워크의 컨트롤러에서 플로우 룰 데이터베이스를 운영하는 방법은, 상기 네트워크에 포함된 스위치 식별정보, 상기 스위치 각각에 적용된 플로우 테이블 식별 정보, 상기 네트워크에 적용할 수 있는 플로우 룰의 모든 매치 필드 항목, 상기 매치 필드 항목의 내용 및 상기 플로우 룰의 인스트럭션을 기록하기 위한 제 1 테이블을 생성하는 a 단계; 적어도 하나 이상의 플로우 룰을 하나의 단위로 적용하기 위한 트랜잭션의 식별 정보를 기록하는 제 2 테이블을 생성하고, 상기 제 1 테이블에 상기 트랜잭션의 식별 정보를 기록하기 위한 트랜잭션 필드를 생성하는 b 단계; 임의의 트랜잭션이 시작되고, 상기 트랜잭션에 포함된 제 1 플로우 룰 추가 메시지 및/또는 제 2 플로우 룰 삭제 메시지를 상기 트랜잭션 식별 정보와 함께 상기 제 1 테이블에 기록하는 c 단계; 상기 트랜잭션이 적용 (commit)되면, 상기 제 1 테이블의 상기 트랜잭션 식별 정보를 미리 설정된 값으로 변경하고, 상기 트랜잭션 식별정보가 변경된 경우에 한하여 모든 어플리케이션에서 상기 제 1 플로우 룰 추가 및/또는 상기 제 2 플로우 룰 삭제된 내용이 상기 제 1 테이블에서 조회되도록 설정하는 d 단계를 포함하는 것을 특징으로 한다.

본 발명에 따르면 SDN 환경에서 네트워크 정책을 효율적으로 운영할 수 있다. 보다 구체적으로 본 발명의 실시예를 따르면, 복수의 플로우 룰을 트랜잭션 단위로 데이터베이스에 적용하여 저장소의 플로우 룰 변경의 원자성을 보장할 수 있다. 나아가 본 발명의 실시예를 따르면, 네트워크에 더이상 적용되지 않는 플로우 룰을 효율적으로 저장소에서 삭제할 수 있어 데이터베이스를 위한 메모리 공간을 줄일 수 있으며, 하나의 트랜잭션에 포함된 플로우 룰의 충돌을 방지할 수 있는 효과가 있다.

나아가 본 발명에 따르면, 저장소의 플로우 룰 데이터베이스의 변경의 원자성이 보장되고, 스위치의 플로우 테이블과 저장소의 플로우 룰 데이터베이스의 동기화가 보장되어 네트워크 운영의 신뢰도 및 통신장애에 대비한 내구성이 높아지는 효과가 있다.

도 1은 소프트웨어 정의 네트워크의 구성을 설명하기 위한 도면
도 2는 플로우 룰 유실의 문제점을 설명하기 위한 도면
도 3은 본원발명의 실시예를 따르는 컨트롤러의 룰싱크 어플리케이션을 포함하는 아키텍처에 대해 설명하기 위한 도면
도 4는 본 발명의 실시예를 따라 룰싱크 어플리케이션에서 스위치와 저장소의 플로우 룰의 동기화를 수행하는 방법을 설명하기 위한 도면
도 5는 본 발명의 실시예를 따라 플로우 룰 데이터베이스를 운영하는 예시를 설명하기 위한 도면
도 6은 본 발명의 실시예를 따라 플로우 룰 데이터베이스를 운영하는 방법을 설명하기 위한 순서도
도 7은 룰싱크 어플리케이션이 저장소를 기준으로 스위치에 플로우 룰 동기화를 수행하면서 발생할 수 있는 문제를 설명하기 위한 도면
도 8은 본 발명의 실시예를 따라 플로우 룰 트랜잭션을 처리하는 예시를 설명하기 위한 도면
도 9는 본 발명의 실시예를 따라 플로우 룰 트랜잭션을 처리하는 방법을 설명하기 위한 순서도
도 10은 본 발명의 실시예에 따라 플로우 룰 충돌 이슈를 처리하는 방법을 설명하기 위한 순서도

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

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

본 발명의 명세서에서 “플로우 룰”의 용어는 해당 업계의 통상의 기술자 입장에서 소프트웨어 정의 네트워크에서 컨트롤러 서버가 적용하는 네트워크 정책을 의미하는 것으로 이해되어야 한다.

나아가 본 발명의 명세서에서 플로우 테이블, 플로우 룰 데이터베이스의 변경(updating)은 테이블 및/또는 데이터베이스를 구성하는 엔트리의 추가(add), 삭제(delete) 및/또는 수정(modify)을 포함하는 개념으로 이해될 수 있다.

나아가 본 명세서에서 오픈플로우 스위치(200)는 오픈플로우 프로토콜만을 지원하는 스위치, 오픈플로우 프로토콜을 지원하는 가상 스위치, 오픈플로우 프로토콜을 지원하는 일반적인 L2 스위치를 포함하는 개념으로 이해될 수 있다.

도 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)가 오픈플로우 스위치인 경우를 중심으로 설명하도록 한다.

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

오픈플로우 프로토콜을 따르면, 스위치(200)는 컨트롤 채널(Control Channel)을 통해 컨트롤러 서버(100)와 정보를 교환하고, 파이프라인(Pipeline) 프로세싱을 위한 하나 이상의 플로우 테이블(Flow table), 그룹 테이블, 미터 테이블 및/또는 패킷 전달을 위한 네트워크 인터페이스로 하나 이상의 포트를 가질 수 있다.

스위치의 플로우 테이블, 그룹 테이블, 미터 테이블 및/또는 포트는 컨트롤러 서버(100)의 제어에 의해 변경될 수 있다. 보다 구체적으로 컨트롤러 서버는 변경 메시지(Mod Message)를 오픈플로우 스위치(200)에게 전송하여 스위치를 변경할 수 있다. 본 명세서에서 스위치의 변경은 해당 스위치의 플로우 테이블, 그룹 테이블, 미터 테이블 및/또는 포트 등에 대한 변경을 포함하는 개념이다.

그런데 현재의 SDN 구조에서는 플로우 룰의 유실 등의 이유로 저장소의 플로우 룰 데이터베이스와 스위치의 플로우 테이블의 원자성을 보장할 수 없는 문제가 있다.

예를 들어 도 2에 도시된 SDN 아키텍처의 예에서, 어플리케이션 레이어 210에 속하는 임의의 어플리케이션에서 컨트롤 레이어 220를 통해 인프라스트럭쳐 레이어 230에 속하는 임의의 스위치에 대한 플로우 룰을 변경하는 경우를 고려할 수 있다. 이 경우 플로우 룰 유실은 크게 4가지 경우에서 발생할 수 있다.

첫째로 어플리케이션에 할당된 큐가 가득차서 플로우 룰 유실이 발생하는 경우이다. 둘째로 TCP 소켓 큐가 가득차서 플로우 룰 유실이 발생할 수 있다. 셋째로 컨트롤러 큐가 가득차거나, 넷째로 스위치의 CPU, 큐 등의 자원 부족에 의한 플로우 룰 유실이 발생할 수 있다. 그러나 어플리케이션은 플로우 룰이 유실되지 않고 해당 스위치에 적용되었는지 여부와 무관하게 저장소(240)에 플로우 룰 변경사항을 기록하게 된다.

이와 같이 현재의 SDN 구조에서는 스위치에 적용된 플로우 룰과 저장소의 플로우 룰 데이터베이스의 원자성이 보장되지 않는 문제가 있다. 즉, 스위치 변경 사항과 저장소의 플로우 룰 데이터베이스 변경 사항의 동기화가 보장되지 않기 때문에, 경로 계산의 신뢰성이 낮아지고, 이는 특히 고도의 보안이 요구되는 네트워크 환경에서 큰 문제가 될 수 있다.

따라서 본 발명의 실시예를 따르는 컨트롤러는 저장소의 플로우 룰 데이터베이스와 스위치의 플로우 테이블을 동기화하는 기능을 수행하는 어플리케이션을 운영할 수 있다.

도 3은 본원발명의 실시예를 따르는 컨트롤러의 룰싱크 어플리케이션을 포함하는 아키텍처에 대해 설명하기 위한 도면이다.

본 발명의 실시예를 따르면, 컨트롤러는 저장소 340의 플로우 룰 데이터베이스와 데이터패스, 즉 스위치에 적용된 플로우 테이블의 동기화를 위한 룰 싱크 어플리케이션 360을 운용할 수 있다.

이를 위하여 어플리케이션 레이어에 속하는 다른 어플리케이션 350은 플로우 모드 메시지를 스위치 330에 전송하기 전에 상기 플로우 모드 메시지의 내용을 저장소 340의 플로우 룰 데이터베이스에 저장하도록 동작할 수 있다.

한편, 룰 싱크 어플리케이션 360은 임의의 주기로 FLOW_STATS_REQUEST메시지를 이용하여 스위치에 적용된 플로우 테이블의 내용을 확인하고, 저장소 340에 접근하여 플로우 룰 데이터베이스를 조회하도록 기능할 수 있다. 이후 룰 싱크 어플리케이션은 스위치에 적용된 플로우 테이블과 저장소의 데이터베이스의 내용을 일치시키도록 기능할 수 있다

보다 구체적으로, 룰 싱크 어플리케이션 360은 저장소의 플로우 룰 데이터베이스와 스위치의 플로우 테이블의 내용이 일치하는 경우, 동기화를 위하여 저장소의 해당 플로우 룰의 타임 스탬프를 업데이트할 수 있다. 그런데, 스위치의 특정 플로우 룰의 만료 시간 (expire time)이 종료된 경우라면, 플로우 모드 메시지를 이용하여 해당 룰을 스위치에 다시 적용(add)할 수 있다.

한편, 룰 싱크 어플리케이션 360은 저장소의 플로우 룰 데이터베이스에 존재하는 룰이 스위치의 플로우 테이블에는 적용되어 있지 않은 경우, 플로우 모드 메시지를 이용하여 해당 룰을 스위치에 추가 (add)할 수 있다. 나아가 저장소의 플로우 룰 데이터베이스에 존재하지 않는 룰이 스위치의 플로우 테이블에는 적용되어 있는 경우, 해당 스위치에 플로우 룰을 삭제 (delete) 하도록 플로우 모드 메시지를 전송할 수 있다.

도 4는 본 발명의 실시예를 따르는 SDN에서 룰싱크 어플리케이션이 동작하여 스위치와 저장소의 플로우 룰의 동기화하는 방법을 설명하기 위한 도면이다.

임의의 시점에 해당 SDN에 적용된 플로우 룰에 대한 데이터베이스가 저장소 (416)에 저장되고 (단계 425) 특정 스위치 (410)에 플로우 테이블이 저장되어 있는 상태에서 (단계 420) 컨트롤러의 임의의 어플리케이션 (414)의 동작으로 스위치 410에 플로우 룰 A를 추가하는 경우를 고려할 수 있다. (단계 350)

본 발명의 실시예를 따르면, 어플리케이션 414은 스위치 410에 플로우 룰 A를 추가하기 위한 플로우 모드 메시지를 전송하기 전에, 저장소 416에 접근하여 플로우 룰 A를 기록(write)하고 (단계 440) 이후 플로우 룰 A를 추가하는 플로우 모드 메시지를 스위치에 전송할 수 있다. (단계 435) 추가된 플로우 룰은 저장소 416의 데이터베이스에 반영되고, (단계 345) 스위치 410의 플로우 테이블에 반영될 것이다. (단계 450)

이때 룰싱크 어플리케이션 412은 임의의 주기로 저장소에 접근하여 플로우 룰을 조회하고 (단계 455) FLOW_STATS_REQUEST메시지를 이용하여 스위치의 플로우 테이블의 내용을 조회할 수 있다. (단계 460)

이때, 플로우 룰 A가 유실되지 않고 스위치와 저장소에 모두 적용되어 있는 경우, 룰 싱크 어플리케이션 412은 동기화를 위하여 저장소의 해당 플로우 룰의 타임 스탬프를 업데이트할 수 있다. (단계 465) 그런데, 스위치에 플로우 룰 A의 만료 시간 (expire time)이 종료된 경우라면, 플로우 모드 메시지를 이용하여 해당 룰을 스위치에 다시 적용(add)할 수 있다. (단계 470)

한편, 룰 싱크 어플리케이션 412는 플로우 룰 A가 유실되어 스위치의 플로우 테이블에는 적용되어 있지 않으면, 플로우 모드 메시지를 이용하여 해당 룰을 스위치에 추가 (add)할 수 있다. 다만 플로우 룰 A가 저장소 416의 데이터베이스에만 유실되어 있는 경우, 동기화를 위하여 스위치 410에 플로우 룰을 삭제 (delete) 하도록 플로우 모드 메시지를 전송할 수 있다.

그런데, 현재의 SDN 저장소의 플로우 룰 데이터베이스의 데이터는 오픈플로우 패킷과 데이터 형태가 상이하다. 저장소에서는 IPv6, MPLS 프로토콜을 지원하기 위하여 상기 프로토콜에서 요구하는 모든 코드가 정의되어야 하기 때문이다. 예를 들어 <Priority 1로 패킷을 drop>하도록 스위치를 설정하는 간단한 플로우 룰이라고 하더라도, 저장소에 기록되는 것은 아래의 표 1에 미리 정의된 코드에 따라 작성된 표 2와 같은 형태의 데이터이다.

그러나 모든 룰에 대해 이와 같은 데이터를 저장하는 것은 메모리 공간의 상당한 오버헤드가 된다. 나아가 오픈플로우 패킷과 SDN 저장소의 플로우 룰 데이터베이스의 데이터 형태가 상이하기 때문에, 어플리케이션 레벨에서 플로우 룰을 저장소에 저장하거나, 저장소에 저장된 데이터베이스를 참고하기 위해서는 데이터 변환 기능이 추가적으로 요구된다. 그리고 본 발명의 실시예에 따라 룰싱크 어플리케이션을 운용하기 위해서는 각각의 플로우 룰에 대해 저장소의 데이터베이스를 검색하게 되는데, 전체 코드를 검색해야 하기 때문에 전체 시스템에 상당한 오버헤드가 되는 문제가 발생한다.

따라서 본 발명의 실시예를 따르는 컨트롤러는 별도의 필드를 새로 정의할 필요없이 플로우 룰 메시지를 그대로 저장하도록 저장소를 운용할 수 있다.

보다 구체적으로 본 발명의 실시예를 따르는 컨트롤러는 저장소의 플로우 룰 데이터베이스를 위하여 스위치의 식별 정보에 대한 제 1 테이블, 각각의 스위치에 적용된 플로우 테이블 식별 정보에 대한 제 2 테이블, 플로우 룰의 매치 필드를 기록하는 제 3 테이블, 나아가 플로우 룰의 인스트럭션의 내용을 기록하는 제 4 테이블을 운용할 수 있다.

이때, 상기 제 3 테이블은 플로우 룰의 매치 항목 세트를 비트 어레이로 표현하고, 상기 비트 어레이에 대한 해쉬값으로 상기 매치 항목 세트의 식별 정보를 표현할 수 있다. 나아가 상기 제 3 테이블은 상기 매치 항목 세트의 내용을 기록한 서브 테이블과 연결될 수 있다.

이후 컨트롤러는 상기 제 1 테이블 내지 제 4 테이블 및 상기 서브 테이블을 이용하여 플로우 룰의 내용을 기록할 수 있다.

도 5는 본 발명의 실시예를 따라 플로우 룰 데이터베이스를 운영하는 예시를 설명하기 위한 도면이다.

도 5의 예에서 테이블 522는 네트워크에 대한 스위치 식별정보를 기록한 테이블이며, 테이블 523은 스위치 10073012046에 적용된 플로우 테이블 식별 정보를 기록하는 테이블이다. 따라서 테이블 522의 552 행은 테이블 523과 연결되어 있다. 나아가 536은 스위치 식별정보 10073012046의 제 30 플로우 테이블에 적용되는 플로우 룰의 매치 필드를 기록하는 테이블이며, 556은 플로우 룰의 인스트럭션을 기록하는 테이블이다.

예를 들어 도 5의 예에서 컨트롤러의 어플리케이션이 510과 같은 플로우 룰을 저장소의 데이터베이스에 기록하는 경우를 고려할 수 있다. 상기 플로우 룰 510이 스위치 ID (512) 10073012046의 플로우 테이블 ID 30 (513)에 대한 것이기 때문에, 어플리케이션은 테이블 522에서 스위치 ID 10073012046 (552)를 검색하고, 552에 연결된 테이블 523을 확인할 것이다. 이후 어플리케이션은 테이블 523에서 테이블 ID 30 (553)을 검색하고, 553에 연결된 테이블 536 및 556을 확인할 것이다.

이후 어플리케이션은 플로우 룰 510의 타입 (514)이 플로우 룰 추가이기 때문에 매치 필드 (516) 및 인스트럭션 (517)의 내용을 테이블 536 및 556에 기록할 것이다.

보다 구체적으로 본 발명의 실시예를 따르는 어플리케이션은 플로우 룰 510의 매치 필드 516의 항목, 즉, dst-mac, dst-ip 및 vlan을 추출하고, 이를 전술한 표 1의 코드값을 이용하여 64 비트 어레이 (526)로 변환할 수 있다. 이후 매치 필드의 항목에 대한 비트 어레이 526에 해쉬 함수를 적용하여 해쉬값을 추출하고 이를 이용하여 테이블 536에 해쉬값에 해당하는 항목을 검색할 수 있다. 본 발명의 실시예와 같이 매치 필드 항목에 해쉬함수를 적용하면 검색의 오버로드가 줄어드는 효과가 있다.

도 5의 예에서, 비트 어레이 526의 해쉬값이 2인 경우, 테이블 536의 식별번호 2인 546행은 실질적으로 플로우 룰의 매치 필드의 항목이 dst-mac, dst-ip 및 vlan (548)임을 의미할 것이다. 이후 어플리케이션은 546에 연결된 서브 테이블 556의 566행에 매치 필드의 내용인 gwA, netB, netA를 기록할 수 있다. 나아가 어플리케이션은 566에 연결된 인스트럭션 테이블 527에 플로우 룰 510의 인스트럭션인 mod-vlan : {netB}, goto : 40을 기록할 수 있다.

이와 같이 저장소의 플로우 룰 데이터베이스를 운영하면, IPv6, MPLS 프로토콜에서 요구하는 모든 코드가 정의되고 지원되지만, 상기 코드에 따르는 형태로 데이터를 저장할 필요없이 오픈플로우 패킷을 그대로 기록할 수 있다. 이를 따르면 메모리 공간을 효율적으로 운영할 수 있고, 별도의 데이터 변환이 요구되지 않으며, 검색에 요구되는 리소스가 줄어들고 검색 속도가 향상되는 효과가 있다.

도 6은 본 발명의 실시예를 따라 플로우 룰 데이터베이스를 운영하는 방법을 설명하기 위한 순서도이다.

단계 610에서 컨트롤러는 네트워크에 포함된 스위치 ID를 기록한 제 1 테이블, 각각의 스위치에 적용된 플로우 테이블 ID를 기록한 제 2 테이블을 생성할 수 있다. 나아가 단계 610에서 컨트롤러는 플로우 룰에 적용할 수 있는 모든 매치 필드 항목을 미리 설정된 코드값을 이용하여 비트 어레이로 변환하고, 상기 비트 어레이에 해쉬 함수를 적용하여 해쉬값을 추출하여 상기 해쉬값으로 매치 필드 항목을 표현한 제 3 테이블을 생성할 수 있다. 나아가 제 1, 2, 3 테이블을 미리 연결할 수 있다.

단계 620에서 컨트롤러는 매치 필드 내용에 대한 제 4 테이블, 인스트럭션에 대한 제 5 테이블을 생성할 수 있다. 네트워크 정책이 결정되어 플로우 룰이 적용되기 전에는 상기 제 4 테이블 및 상기 제 5 테이블은 비워져 있을 수 있다.

이후 컨트롤러는 플로우 룰을 스위치에 적용하기 전에 저장소에 기록할 수 있다. 보다 구체적으로 컨트롤러의 임의의 어플리케이션에서 플로우 룰을 저장소의 데이터베이스에 기록하고자 하는 경우, 상기 플로우 룰의 매치 필드 항목을 미리 설정된 코드 값을 이용하여 비트 어레이로 변환하고, 상기 비트 어레이에 해쉬 함수를 적용하여 해쉬값을 추출할 수 있다. (단계 630)

이후 어플리케이션은 상기 플로우 룰에서 해당 스위치 ID 및 테이블 ID를 확인하고 상기 제 1 테이블 및 상기 제 2 테이블을 검색하고, 검색된 제 1 테이블 및 제 2 테이블에 연결된 제 3 테이블에서 상기 해쉬값을 검색할 수 있다. (단계 640)

이후 어플리케이션은 상기 제 3 테이블에서 검색된 상기 해쉬값에 연결된 상기 제 4 테이블의 임의의 영역에 상기 플로우 룰의 매치 필드 내용을 기록하고, 상기 제 4 테이블의 상기 영역에 연결된 상기 제 5 테이블의 임의의 영역에 상기 플로우 룰의 인스트럭션을 기록할 수 있다.

그런데, 도 5 내지 도 6에 예시된 실시예를 따라 저장소의 데이터베이스를 운영하더라도 플로우 룰 변경사항이 스위치 또는 저장소 데이터베이스에 적용되는 시점에 따라 룰싱크 어플리케이션의 동작에 따라 저장소와 스위치의 변경사항의 원자성이 보장되지 않는 문제가 있다.

도 7은 룰싱크 어플리케이션이 저장소를 기준으로 스위치에 플로우 룰 동기화를 수행하면서 발생할 수 있는 문제를 설명하기 위한 도면이다.

도 7에 도시된 바와 같이 스위치 410에 임의의 플로우 테이블이 적용되고 (단계 710), 저장소 416에 플로우 룰 데이터베이스가 저장되어 있으며 (단계 715) 스위치 410의 플로우 테이블과 저장소 416의 데이터베이스의 내용은 동기화되어 있는 상태를 고려할 수 있다.

이 경우, 예를 들어 임의의 어플리케이션 414에서 스위치 410에 적용된 임의의 플로우 룰 A를 삭제하는 경우를 고려할 수 있다. (단계 725) 어플리케이션 414는 스위치 410에 플로우 룰 A 삭제를 적용하기 전에 저장소 416의 데이터베이스에 플로우 룰 A 삭제를 기록할 것이다. (단계 730) 이후 어플리케이션 414는 스위치 410에 플로우 룰 A 삭제를 설정하는 메시지를 전송할 것이다. (단계 739)

그런데, 플로우 룰 A 삭제가 데이터베이스에 반영되기 전에 (단계 735) 룰 싱크 어플리케이션 412에서 저장소 416에 접근하여 플로우 룰을 조회하고 (단계 720), 플로우 룰 A 삭제가 스위치 410의 플로우 테이블에 반영되기 전에 (단계 746) 스위치의 플로우 테이블의 내용을 조회 (단계 737) 하는 경우가 발생할 수 있다.

이때 룰싱크 어플리케이션 412은 플로우 룰 A가 스위치와 저장소에 모두 적용되어 있는 것으로 판단하고, 플로우 룰 A 삭제 기록이 반영된 상태의 데이터베이스에 플로우 룰 A의 타임 스탬프를 업데이트할 수 있다. (단계 741) 이렇게 되면, 어플리케이션 414의 의도와는 달리 데이터베이스의 플로우 룰의 기록이 변경 (단계 743)되는 문제가 발생할 수 있다.

이후 룰싱크 어플리케이션 412에서 스위치의 플로우 테이블을 다시 조회 (단계 764)해서 변경된 데이터베이스와 비교하고, 어플리케이션 414에서 정상적으로 삭제한 플로우 룰 A가 무단으로 삭제된 것으로 판단할 수 있다. 이 경우, 룰싱크 어플리케이션 412는 스위치 410에 플로우 룰 A를 추가하게 될 것이다. (단계 766) 이렇게 되면 어플리케이션 414의 의도와는 달리 스위치의 플로우 테이블이 변경 (단계 769)되는 문제가 발생할 수 있다.

따라서 본 발명의 다른 실시예를 따르면 저장소의 플로우 룰 적용을 트랜잭션 단위로 수행하여 플로우 룰 데이터베이스 변경의 원자성을 보장하고, 저장소와 스위치의 플로우 룰의 일관성을 보장하도록 할 수 있다.

보다 구체적으로, 본 발명의 실시예를 따르면, 저장소의 데이터베이스에 트랜잭션 내용을 기록하는 트랜잭션 테이블을 운영하고, 플로우 룰의 인스트럭션의 내용을 기록하는 테이블에 트랜잭션 정보를 기록하는 필드를 추가하여 상기 트랜잭션 테이블과 연결하는 방식으로 저장소를 운영할 수 있다. 이러한 방식을 따르면, 트랜잭션이 적용 (commit)되어, 인스트럭션 테이블에 트랜잭션 아이디 필드가 0으로 변경되기 전에는 저장소의 기록이 어플리케이션에서 조회되지 않기 때문에 도 7과 같은 문제가 해결될 수 있다.

도 8은 본발명의 실시예를 따라 플로우 룰 트랜잭션을 처리하는 예시를 설명하기 위한 도면이다. 도 8의 예는 t_10에 플로우 룰 a 추가 및 플로우 룰 b 삭제를 위한 트랜잭션이 시작되며 (도 8a), t_11에서 플로우 룰 추가가 데이터베이스에 기록되며 (도 8a), t_12에서 플로우 룰 삭제가 데이터베이스에 기록되며 (도 8b), t_14에서 트랜잭션이 적용 (commit)되는 경우이다. (도 8c)

도 8의 예에서 테이블 822, 823, 836, 856은 도 5에 대한 설명에서 전술한 522, 523, 536, 556과 동일한 기능을 수행한다. 즉, 테이블 822는 네트워크에 대한 스위치 식별정보를 기록한 테이블이며, 테이블 823은 스위치에 적용된 플로우 테이블 식별 정보를 기록하는 테이블이다. 나아가 836은 해당 스위치의 해당 플로우 테이블에 적용되는 플로우 룰의 매치 필드의 항목을 기록하는 테이블이며, 856은 해당 매치 필드의 내용을 기록하는 테이블이다.

도 8의 예에서 테이블 857은 해당 매치 필드에 대한 인스트럭션을 기록하는 테이블이다. 도 8의 예에서 테이블 857은 해당 플로우 룰의 인스트럭션의 내용을 기록하는 인스트럭션 필드 864과 함께 플로우 룰 적용 시작 시간을 의미하는 start time stamp 필드 861, 적용 종료 시간을 의미하는 end time stamp 필드 862 및, 트랜잭션 ID 필드 863가 포함될 수 있다.

나아가 도 8에서 테이블 871 및 872은 트랜잭션 정보를 기록하기 위한 테이블로, 로컬 트랜잭션 정보 테이블인 871은 해당 어플리케이션이 속하는 컨트롤러 별 고유한 트랜잭션의 식별 정보 (로컬 트랜잭션 ID) 가 기록되며, 글로벌 트랜잭션 정보 테이블 872는 전체 네트워크에서 고유한 트랜잭션의 식별 정보 (글로벌 트랜잭션 ID) 및 트랜잭션 시작 시간이 기록되며, 테이블 873은 테이블 872와 연결되어 해당 트랜잭션이 포함하는 인스트럭션의 타입 및 내용이 기록될 수 있다. 상기 글로벌 트랜잭션 ID는 상기 로컬 트랜잭션 ID에 해당 컨트롤러 ID에 대한 정보를 추가하는 방식으로 생성될 수 있다.

도 8a의 예에서 컨트롤러의 어플리케이션이 트랜잭션을 t_10 시간에 시작하고, t_11 시간에서 플로우 룰 a 추가가 데이터베이스에 기록되는 경우를 고려할 수 있다.

이 경우, 도 8a의 예에서는 해당 어플리케이션이 속하는 컨트롤러에 대한 로컬 트랜잭션 ID가 테이블 871에 기록되고 (도 8a의 예에서 5), 상기 트랜잭션의 글로벌 트랜잭션 ID (도 8a의 예에서 22) 및 트랜잭션 시작 시간 t_10에 대한 정보가 테이블 872에 기록된 경우이다. 이후 글로벌 트랜잭션 ID 정보를 이용하여 테이블 872, 873 및 857이 연결될 것이다.

이후 t_11에서 어플리케이션은 테이블 873에 도 8a의 874와 같이 트랜잭션 22에 포함되는 플로우 룰의 상태가 add임이 기록할 것이다. 나아가 어플리케이션은 테이블 822 및 823을 검색하여 해당 스위치와 플로우 테이블에 연결된 테이블 836에 플로우 룰 a의 매치 필드의 항목을 검색하고, 연결된 테이블 856에 매치 필드의 내용을 기록하고, 연결된 테이블 857에 플로우 룰 a의 인스트럭션의 내용을 기록할 것이다. 나아가 어플리케이션은 테이블 857의 start time stamp 필드에 t_11, end time stamp 필드에 infinite를 기록하고, 글로벌 트랜잭션 ID 필드에 22를 기록할 것이다. (858)

나아가 도 8b의 예는 t_12 시간에 플로우 룰 b 삭제가 데이터베이스에 기록되는 경우이다. 이때 어플리케이션은 도 8b의 테이블 873에 874와 같이 트랜잭션 22에 포함되는 플로우 룰의 상태가 delete임을 기록할 것이다. 나아가 어플리케이션은 테이블 822, 823, 836, 856, 857을 검색하여 스위치 ID, 플로우 테이블 ID, 매치 필드 항목, 매치 필드 내용을 확인하여 삭제할 플로우 룰 b가 859임을 확인할 것이다. 이때 어플리케이션은 테이블 857의 859행의 end time stamp 필드 (862)를 infinite에서 t_12로 변경하여 플로우 룰 b가 삭제되었음을 데이터베이스에 기록하고, 글로벌 트랜잭션 ID 필드에 22를 기록할 것이다.

한편, 본 발명의 실시예를 따르면, 플로우 룰 데이터베이스는 변경 이력을 관리하기 위하여 변경 사항들이 기록될 수 있다. 따라서 플로우 룰 삭제의 경우에도 데이터베이스에서 해당 플로우 룰 데이터를 즉시 삭제하지 않고, end time stamp를 변경하여 플로우 룰 적용 종료 시간을 기록하는 방식으로 동작하며, 변경전 플로우 룰 데이터는 별도로 저장될 수 있다.

이와 같이 본 발명의 실시예를 따르는 데이터베이스에서 플로우 룰 삭제 메시지는 데이터베이스에 플로우 룰 적용이 종료되었음을 기록하고, 변경 전 플로우 룰 데이터는 별도로 저장하는 방식으로 동작하기 때문에 트랜잭션에서 플로우 룰 삭제 명령은 delete new와 delete old의 두가지로 데이터베이스에 반영될 수 있다. delete new는 트랜잭션이 적용(commit)되면 해당 플로우 룰이 삭제되었음을 기록하기 위한 것이고, delete old는 트랜잭션이 적용(commit)되면 해당 플로우 룰에 대한 데이터를 삭제하기 위한 것이다.

나아가 본 발명의 추가적인 실시예를 따르면, delete old에 대한 트랜잭션이 적용(commit)된 경우라도, 변경 이력을 관리하기 위하여 해당 데이터를 완전히 삭제하는 것이 아니라 가비지 데이터로 기록하고, 임의의 주기로 삭제하는 방식으로 동작할 수도 있다.

이를 위하여 본 발명의 실시예를 따르면, 저장소의 데이터베이스는 가비지 데이터를 기록하기 위한 가비지 테이블을 생성하고, delete old에 대한 트랜잭션이 데이터베이스에 기록되면, 삭제전 플로우 룰을 그대로 저장하고, 상기 트랜잭션이 적용 (commit)되면 저장된 플로우 룰의 주소를 가비지 테이블에 기록하는 방식으로 동작할 수도 있다.

다시 도 8에 대한 설명으로 복귀하면, 도 8b에서 delete new는 플로우 룰 b를 859와 같이 타임 스탬프와 글로벌 트랜잭션 ID를 변경하고, delete old는 변경되기 전 플로우 룰 b 860를 그대로 가비지 데이터로 저장하도록 동작할 수 있다.

나아가 도 8c의 예는 t_14 시간에 트랜잭션이 적용(commit) 되는 경우이다. 이때 어플리케이션은 도 8b의 테이블 857을 도 8c의 테이블 857과 같이 변경할 것이다.

보다 구체적으로 플로우 룰 b 삭제를 기록하기 위하여 859행의 end time stamp 필드를 데이터베이스에 기록된 시간인 t_12에서 적용(commit)된 시간인 t_14로 변경하고, 글로벌 트랜잭션 ID 필드를 22에서 0으로 변경하여 다른 어플리케이션에서 조회할 수 있도록 할 것이다. 동시에 변경전 플로우 룰 b에 대한 데이터 860을 가비지 데이터로 기록할 것이다.

동시에 플로우 룰 a 추가에 대한 858행의 start time 필드를 데이터베이스에 기록된 시간인 t_11에서 적용 (commit)된 시간인 t_14로 변경하고, 글로벌 트랜잭션 ID 필드를 22에서 0으로 변경하여 다른 어플리케이션에서 조회할 수 있도록 할 것이다.

그런데 트랜잭션 적용(commit) 시점에 859행의 글로벌 트랜잭션 ID 변경과 858 행의 글로벌 트랜잭션 ID 변경 시점이 완전히 일치하지 않을 가능성이 있다. 예를 들어 859행은 도 8b 상태인데, 858행은 도 8c와 같이 변경된 상태가 공존할 수 있다. 이 경우, 도 7에 대한 설명에서 전술한 문제가 여전히 발생할 수 있다.

따라서 본 발명의 다른 실시예를 따르면 트랜잭션 적용 (commit) 단계의 플로우 룰 변경의 일관성을 보장하기 위한 별도의 필드를 트랜잭션 정보 테이블 및 인스트럭션 테이블에 추가할 수 있다. 상기 필드는 리비전 필드로 해당 컨트롤러의 데이터베이스에서 트랜잭션 적용 (commit)이 완료되면 트랜잭션 정보 테이블의 리비전 값을 변경하고, 인스트럭션 테이블에서 변경된 리비전 값 이하의 리비전 값을 가지는 데이터만 다른 어플리케이션에서 조회할 수 있도록 설정하여 트랜잭션 적용 (commit) 단계의 비일관성의 문제를 해결할 수 있다.

보다 구체적으로 본 발명의 다른 실시예를 따르면 도 8d와 같이 로컬 트랜잭션 정보 테이블 871에 리비전 필드 891를 추가하고, 인스트럭션 테이블 857에 글로벌 트랜잭션 ID 필드 863와 함께 리비전 필드 893을 추가할 수 있다. 이때 리비전 필드 값은 로컬 값으로 해당 컨트롤러의 전체 트랜잭션에 대해 고유한 값을 가지는 것에 유의해야 한다.

한편, 어플리케이션은 트랜잭션이 시작되면 인스트럭션 테이블 857의 트랜잭션 ID 필드에 글로벌 트랜잭션 ID 값을 기재하고, 트랜잭션이 적용(commit)되면 인스트럭션 테이블 857의 글로벌 트랜잭션 ID 필드값을 0으로 변경하고, 리비전 필드의 값을 로컬 트랜잭션 정보 테이블 871의 리비전 값보다 1 추가된 값으로 변경할 수 있다. 이후 트랜잭션 적용이 완료되면 트랜잭션 정보 테이블 871의 리비전 필드 값을 1 추가할 수 있다. 이에 따르면 다른 어플리케이션은 글로벌 트랜잭션 ID 필드값이 0, 리비전 필드 값이 트랜잭션 정보 테이블의 리비전 값 이하인 데이터만 인스트럭션 테이블에서 조회할 수 있도록 하여 비일관성의 문제가 해결될 수 있다.

도 8d의 예에서, 트랜잭션이 적용 (commit)되면 인스트럭션 테이블 857의 리비전 필드 893은 로컬 트랜잭션 정보 테이블 871의 리비전 값 891보다 하나 큰 2로 변경되고, 이후 로컬 트랜잭션 정보 테이블 871의 리비전 필드 891도 카운터를 하나 올린 2로 변경되어 해당 트랜잭션의 내용이 다른 어플리케이션에서 조회 가능한 상태가 될 것이다.

도 9는 본 발명의 실시예를 따라 플로우 룰 트랜잭션을 데이터베이스에서 처리하는 방법을 설명하기 위한 순서도이다.

단계 910에서 데이터베이스의 기본 구조를 생성할 수 있다.

단계 910에서 컨트롤러는 네트워크에 포함된 스위치 ID를 기록한 제 1 테이블, 각각의 스위치에 적용된 플로우 테이블 ID를 기록한 제 2 테이블을 생성할 수 있다. 나아가 매치 필드 항목을 표현한 제 3 테이블, 매치 필드 내용에 대한 제 4 테이블, 인스트럭션에 대한 제 5 테이블을 생성하고 상기 제 1 테이블 내지 상기 제 5 테이블은 미리 연결될 수 있다. 나아가 상기 제 5 테이블은 인스트럭션의 내용을 기록하는 인스트럭션 필드, start time stamp 필드, end time stamp 필드, 글로벌 트랜잭션 ID 필드 및 리비전 필드가 포함될 수 있다.

단계 920에서 컨트롤러는 해당 어플리케이션이 속하는 컨트롤러에 대해 고유한 로컬 트랜잭션 정보를 기록하는 제 6 테이블 및 전체 네트워크에 대해 고유한 글로벌 트랜잭션 정보를 기록하는 제 7 테이블을 생성할 수 있다. 상기 제 6 테이블은 로컬 트랜잭션 ID 필드 및 리비전 필드가 포함될 수 있으며, 상기 제 7 테이블은 글로벌 트랜잭션 ID 및 인스트럭션의 타입이 기록되며, 이를 이용하여 상기 제 5 테이블과 연결될 수 있다.

나아가 컨트롤러는 적용되지 않는 플로우 룰 데이터의 위치를 기록하는 가비지 테이블을 생성할 수 있다. 이는 플로우 룰의 변경 이력을 관리하면서 동시에 미리 설정된 주기로 유효하지 않는 데이터를 삭제하여 메모리를 효율적으로 사용하기 위한 것이다.

단계 930에서 임의의 어플리케이션이 적어도 하나 이상의 플로우 룰을 포함하는 트랜잭션을 시작한 경우, 컨트롤러는 상기 제 6 테이블에 로컬 트랜잭션 ID를 기록하고, 연결된 제 7 테이블에 글로벌 트랜잭션 ID 및 트랜잭션 시작 시간을 기록할 것이다.

단계 940에서 해당 트랜잭션에 포함된 플로우 룰들이 데이터베이스에 기록될 수 있다.

보다 구체적으로, 플로우 룰 추가를 데이터베이스에 기록하기 위하여, 제 7 테이블에 해당 트랜잭션에 포함되는 플로우 룰의 상태가 add임을 기록하고, 제 1 내지 제 3 테이블을 검색하여 해당 스위치, 해당 플로우 테이블 및 매치 필드의 항목을 확인하고, 연결된 제 4 테이블에 매치 필드의 내용을 기록하고, 연결된 제 5 테이블에 인스트럭션의 내용을 기록할 것이다. 나아가 상기 제 5 테이블에 start time stamp 필드에 플로우 룰 추가 기록 시간, end time stamp 필드에 infinite를 기록하고, 트랜잭션 ID 필드에 해당 트랜잭션의 글로벌 ID를 기록할 것이다.

나아가, 플로우 룰 삭제를 데이터베이스에 기록하기 위하여, 제 7 테이블에 해당 트랜잭션에 포함되는 플로우 룰의 상태가 delete임을 기록하고, 제 1 내지 제 4 테이블을 검색하여 스위치 ID, 플로우 테이블 ID, 매치 필드 항목, 매치 필드 내용을 확인하여 삭제할 플로우 룰을 확인할 것이다.

이때 본 발명의 추가적인 실시예를 따르면, 상기 제 7 테이블에 플로우 룰의 상태를 delete new, delete old로 구분할 수 있다. 컨트롤러는 delete new에 따라 상기 제 5 테이블의 삭제 대상 플로우 룰의 end time stamp 필드를 infinite에서 플로우 룰 삭제 기록 시간으로 변경하고, 트랜잭션 ID 필드를 해당 트랜잭션의 글로벌 ID로 변경할 것이다. 나아가 delete old에 따라 삭제 대상 플로우 룰의 변경전 상태를 저장할 것이다.

단계 950에서 임의의 시점에 트랜잭션이 적용 (commit)될 수 있다.

보다 구체적으로, 플로우 룰 추가를 적용 (commit)하기 위하여, 제 5 테이블의 추가 대상 플로우 룰의 start time stamp 필드를 트랜잭션 적용 시간으로 변경하고, 트랜잭션 ID 필드를 0으로 변경하고, 리비전 필드를 제 6 테이블의 리비전 값보다 1 추가된 값으로 변경할 수 있다.

나아가, 플로우 룰 삭제를 적용 (commit)하기 위하여, 제 5 테이블의 삭제 대상 플로우 룰의 end time stamp 필드를 트랜잭션 적용 시간으로 변경하고, 트랜잭션 ID 필드를 0으로 변경하고, 리비전 필드를 제 6 테이블의 리비전 값보다 1 추가된 값으로 변경할 것이다. 나아가 삭제 대상 플로우 룰의 변경전 상태가 저장된 데이터의 주소를 가비지 테이블에 기록할 수 있다.

트랜잭션 적용 (commit)이 완료되면 제 6 테이블의 리비전 값을 1 추가할 수 있다. 본 발명의 실시예를 따르면, 트랜잭션 ID 값이 0이고, 리비전 값이 로컬 트랜잭션 정보를 기록하는 제 6 테이블의 리비전 값 이하인 데이터만 다른 어플리케이션에서 조회할 수 있다.

한편, 단계 960에서 데이터베이스의 메모리를 효율적으로 사용하기 위한 가비지 컬렉션 기능을 수행할 수 있다.

본 발명의 실시예를 따르면, 플로우 룰이 삭제된 경우라도, delete old에 따라 삭제 대상 플로우 룰은 가비지 테이블에 기록된 상태로 그대로 저장되고, delete new에 따라 삭제 대상 플로우 룰은 end time stamp가 변경된 상태로 제 7 테이블에 존속한다. 이는 변경이력을 관리하기 위한 것이나, 메모리 공간의 낭비 요인이 될 수 있다.

따라서 본 발명의 실시예를 따르면, 임의의 주기로 가비지 데이터가 메모리에서 삭제될 수 있다. 보다 구체적으로 임의의 시점에 인스트럭션 테이블 (제 5 테이블)과 가바지 테이블에 저장된 인스트럭션 리스트에서 end time stamp를 확인하고, 해당 시점 이전의 end time stamp를 보유하는 인스트럭션 데이터를 삭제하거나 또는 해당 시점으로부터 유효한 시점을 특정하여, 상기 유효한 시점 이전의 end time stamp를 보유하는 인스트럭션 데이터를 삭제하도록 설정할 수도 있다.

나아가 본 발명의 추가적인 실시예를 따르면, 복수의 트랜잭션 사이의 플로우 룰 충돌 여부를 확인하여 플로우 룰 충돌을 처리할 수 있다. (단계 970) 플로우 룰 충돌은 트랜잭션에 포함된 플로우 룰이 다른 트랜잭션에 포함된 플로우 룰과 매치 필드의 항목 및 내용이 동일하나 인스트럭션이 상이한 경우에 발생할 수 있다.

도 9의 예에서 단계 970은 단계 930 내지 950 이후에 수행하는 것으로 기재하였지만, 이는 단지 설명의 편의를 위한 것이다. 플로우 룰 충돌은 실제로는 단계 940을 수행하는 과정에서 발생하고 처리될 수 있다.

본 발명의 실시예를 따르면, 제 1 트랜잭션에 포함된 플로우 룰과 제 2 트랜잭션에 포함된 플로우 룰이 매치 필드 항목 및 매치 필드 내용은 동일하나, 플로우 타입 또는 인스트럭션이 상이한 경우, 플로우 룰 충돌로 판단하고, 에러 발생을 리턴 (return)하고 트랜잭션의 모든 내용을 롤백 (role back) 할 수 있다.

본 발명의 다른 실시예를 따르면, 제 1 트랜잭션과 제 2 트랜잭션이 충돌하는 경우, 트랜잭션 시작 시간이 앞서는 제 1 트랜잭션이 반영 (commit)될 때까지 나중에 시작된 제 2 트랜잭션을 수행하는 쓰레드가 대기 상태로 변경되고, 제 1 트랜잭션이 반영 (commit)된 후 대기 중인 상기 쓰레드가 다시 실행되는 방식으로 충돌을 처리할 수도 있다.

이때 본 발명의 추가적인 실시예를 따르면, 웨이트 큐 (Wait queue)에 제 2 트랜잭션 식별 정보를 저장하고, 제 1 트랜잭션의 commit이 완료되면, 웨이트 큐를 참고하여 제 2 트랜잭션을 검색할 수 있다. 이를 위해 데이터베이스는 웨이트 큐 리스트를 기록하는 테이블을 생성할 수 있으며, 매치 필드의 내용을 기록하는 제 4 테이블에 웨이트 큐의 주소를 기록하는 필드를 추가할 수 있다.

플로우 룰 충돌을 처리하는 보다 구체적인 설명은 첨부된 도 10에 대한 설명과 함께 후술된다.

도 10은 본 발명의 실시예에 따라 플로우 룰 충돌 이슈를 처리하는 방법을 설명하기 위한 순서도이다.

단계 1010에서 데이터베이스에 적어도 하나 이상의 플로우 룰을 포함하는 트랜잭션 a (Tx_a)와 트랜잭션 b (Tx_b)가 순차적으로 시작될 수 있다.

컨트롤러는 단계 1020에서 상기 Tx_a 및 Tx_b에 포함된 플로우 룰을 데이터베이스에 기록하면서, 임의의 플로우 룰의 매치 필드가 동일한 경우가 발생하면 (단계 1020), 시작 시점이 늦은 Tx_b를 수행하는 쓰레드를 대기 상태로 변경하고, Tx_b의 트랜잭션 식별 정보를 웨이트 큐에 저장하고, 해당 플로우 룰의 매치 필드의 내용을 기록하는 테이블의 웨이트 큐 필드에 상기 Tx_b의 식별 정보가 저장된 웨이트 큐의 주소를 기록할 수 있다. (단계 1030)

이후 Tx_a에 포함된 플로우 룰 기록 및 적용 (commit)이 완료되면 (단계 1040) 해당 매치 필드 내용을 기록하는 테이블의 웨이트 큐 필드의 주소 값을 참고하여 Tx_b를 검색하고, (단계 1050) Tx_b를 수행하는 쓰레드를 대기 상태에서 활성 상태로 변경하고 (단계 1060) Tx_b에 포함된 플로우 룰을 데이터베이스에 기록하는 방식으로 플로우 룰 사이의 충돌을 처리할 수 있다. (단계 1070)

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

100 : 컨트롤러 서버
200 : 오픈플로우 스위치
300 : 호스트

Claims (8)

1. 소프트웨어 정의 네트워크의 컨트롤러에서 플로우 룰 데이터베이스를 운영하는 방법에 있어서,
   상기 네트워크에 포함된 스위치 식별정보, 상기 스위치 각각에 적용된 플로우 테이블 식별 정보, 상기 네트워크에 적용할 수 있는 플로우 룰의 모든 매치 필드 항목, 상기 매치 필드 항목의 내용 및 상기 플로우 룰의 인스트럭션을 기록하기 위한 제 1 테이블을 생성하는 a 단계;
   적어도 하나 이상의 플로우 룰을 하나의 단위로 적용하기 위한 트랜잭션 식별 정보를 기록하는 제 2 테이블을 생성하고, 상기 제 1 테이블에 상기 트랜잭션 식별 정보를 기록하기 위한 트랜잭션 필드를 생성하는 b 단계;
   임의의 트랜잭션이 시작되고, 상기 트랜잭션에 포함된 제 1 플로우 룰 추가 메시지 및/또는 제 2 플로우 룰 삭제 메시지를 상기 트랜잭션 식별 정보와 함께 상기 제 1 테이블에 기록하는 c 단계;
   상기 트랜잭션이 적용 (commit)되면, 상기 제 1 테이블의 상기 트랜잭션 식별 정보를 미리 설정된 값으로 변경하고, 상기 트랜잭션 식별 정보가 변경된 경우에 한하여 모든 어플리케이션에서 상기 제 1 플로우 룰 추가 및/또는 상기 제 2 플로우 룰 삭제된 내용이 상기 제 1 테이블에서 조회되도록 설정하는 d 단계를 포함하고,
   상기 c 단계는,
   상기 제 1 플로우 룰에 해당하는 스위치, 플로우 테이블, 매치 필드 항목을 상기 제 1 테이블에서 검색하고, 상기 매치 필드 항목에 연결하여 상기 제 1 플로우 룰의 매치 필드의 내용을 기록하고, 상기 매치 필드의 내용에 연결하여 상기 제 1 플로우 룰의 인스트럭션을 기록하고, 상기 인스트럭션의 스타트 타임 스탬프 필드를 상기 제 1 플로우 룰 추가가 상기 데이터베이스에 기록된 시점으로 기록하는 단계; 및
   상기 제 2 플로우 룰에 해당하는 스위치, 플로우 테이블, 매치 필드 항목, 상기 매치 필드 항목에 연결된 매치 필드의 내용 및 상기 매치 필드의 내용에 연결된 인스트럭션을 상기 제 1 테이블에서 검색하고, 상기 인스트럭션의 원본 데이터의 앤드 타임 스탬프 필드를 상기 제 2 플로우 룰 삭제가 상기 데이터베이스에 기록되는 시점으로 변경하고, 상기 앤드 타임 스탬프 필드를 변경하기 전의 상기 인스트럭션의 변경전 데이터를 별도로 저장하는 단계를 포함하는 것을 특징으로 하는 데이터베이스 운영방법.
2. 제 1 항에 있어서, 상기 b 단계는,
   상기 제 1 테이블에 상기 플로우 룰이 적용되는 스타트 타임 스탬프, 상기 플로우 룰의 적용이 종료되는 앤드 타임 스탬프 필드를 생성하는 단계를 포함하는 것을 특징으로 하는 데이터베이스 운영방법.
3. 삭제
4. 제 1 항에 있어서, 상기 b 단계는,
   상기 제 1 테이블 및 상기 제 2 테이블에 상기 트랜잭션의 리비전 정보를 기록하는 리비전 필드를 생성하는 단계를 포함하는 것을 특징으로 하는 데이터베이스 운영방법.
5. 제 4 항에 있어서, 상기 d 단계는,
   상기 트랜잭션이 적용 (commit)되면, 상기 제 1 테이블의 리비전 필드의 값을 상기 제 2 테이블의 리비전 필드의 값보다 1 높은 값으로 기록하는 단계;
   상기 트랜잭션의 적용이 완료되면, 상기 제 2 테이블의 리비전 필드의 값을 1 추가하도록 변경하고, 모든 어플리케이션에서 상기 제 2 테이블의 변경된 리비전 필드값 이하의 리비전 필드 값을 가지는 데이터만 조회되도록 설정하는 단계를 포함하는 것을 특징으로 하는 데이터베이스 운영방법.
6. 제 5항에 있어서, 상기 c 단계는,
   상기 제 2 플로우 룰에 해당하는 상기 인스트럭션의 변경전 데이터를 제 3 테이블에 저장하는 단계;
   미리 설정된 주기로, 유효한 시점을 특정하고, 상기 유효한 시점 이전의 앤드 타임 스탬프를 가지는 플로우 룰을 상기 제 1 테이블 및 상기 제 3 테이블에서 삭제하는 단계를 포함하는 것을 특징으로 하는 데이터베이스 운영 방법.
7. 제 6항에 있어서, 상기 c 단계는,
   제 1 트랜잭션에 포함된 플로우 룰의 매치 필드가 상기 제 1 트랜잭션 이후에 시작한 제 2 트랜잭션에 포함된 플로우 룰의 매치 필드와 동일한 경우, 상기 제 2 트랜잭션을 수행하는 쓰레드를 대기 상태로 변경하는 단계; 및
   상기 제 1 트랜잭션의 적용이 완료되면, 상기 제 2 트랜잭션을 수행하는 쓰레드를 수행 상태로 변경하여 상기 제 2 트랜잭션을 상기 데이터베이스에 기록하는 단계를 포함하는 것을 특징으로 하는 데이터베이스 운영 방법.
8. 제 7항에 있어서,
   상기 쓰레드를 변경하는 단계는, 웨이트 큐에 상기 제 2 트랜잭션의 식별 정보를 저장하고, 상기 제 1 테이블에 상기 플로우 룰과 연결하여 상기 웨이트 큐의 주소를 기록하는 단계를 포함하며,
   상기 데이터베이스에 기록하는 단계는,
   상기 제 1 트랜잭션의 적용이 완료되면, 상기 웨이트 큐의 주소를 참고하여, 상기 제 2 트랜잭션을 수행하는 쓰레드를 대기 상태에서 수행 상태로 변경하고, 상기 제 2 트랜잭션의 내용을 상기 제 1 테이블에 기록하는 단계를 포함하는 것을 특징으로 하는 데이터베이스 운영 방법.

Images