KR101776650B1 - Ｓｄｎ 교환기가 정확한 흐름 엔트리를 획득하는 방법, 및 ｓｄｎ 교환기, 제어기, 및 시스템 - Google Patents

Abstract

본 발명의 실시예는 SDN 교환기가 정확한 흐름 엔트리를 획득하는 방법을 개시하며, 상기 방법은 제2 SDN 교환기에 적용되고, 상기 제2 SDN 교환기는 제1 SDN 교환기 및 SDN 제어기에 접속되며, 상기 SDN 제어기는 각각의 SDN 교환기와 대역내 통신 방식으로 통신하며, 상기 방법은: 상기 제1 SDN 교환기가 SDN 제어기에 대한 신뢰 가능한 접속을 먼저 구축하는 단계; 그런 다음 상기 신뢰 가능한 접속에 대한 프로토콜에 대응하는 패킷에 기초하여 제1 제어 메시지를 송신하는 단계; 상기 제1 SDN 교환기의 경로 정보를 제에 메시지에 부가하는 단계; 및 이어서 상기 제1 제어 메시지를 수신하는 각각의 SDN 교환기가, 각각의 SDN 교환의 경로 정보를 제1 제어 메시지에 부가하는 단계를 포함하며, 이에 따라 최종적으로 SDN 제어기는 제1 SDN 교환기에 흐름 테이블을 전달할 수 있는 전체 경로를 알게 된다.

Description

ＳＤＮ 교환기가 정확한 흐름 엔트리를 획득하는 방법, 및 ＳＤＮ 교환기, 제어기, 및 시스템 {METHOD FOR ACQUIRING, BY SDN SWITCH, EXACT FLOW ENTRY, AND SDN SWITCH, CONTROLLER, AND SYSTEM}

본 출원은 2013년 10월 26일 중국특허청에 출원되고 발명의 명칭이 "METHOD FOR ACQUIRING, BY SDN SWITCH, EXACT FLOW ENTRY, AND SDN SWITCH, CONTROLLER, AND SYSTEM"인 중국특허출원번호 No. 201310514564.2에 대한 우선권을 주장하는 바이며, 상기 문헌은 본 명세서에 원용되어 병합된다.

본 발명은 통신 기술 분야에 관한 것이며, 특히 SDN 교환기가 정확한 흐름 엔트리를 획득하는 방법, SDN 교환기, SDN 제어기, 및 SDN 시스템에 관한 것이다.

소프트웨어 정의 네트워크(Software Defined Network, SDN)는 새로운 네트워크 아키텍처이고, 점차 연구되고 응용되고 있으며, 현재의 SDN은 주로 개방흐름(OpenFlow) 프로토콜에 기초해서 실행되고 있다. OpenFlow 프로토콜에 기초한 SDN 네트워크를 이하에서는 OpenFlow 네트워크라 하고, OpenFlow 네트워크는 개방흐름 제어기(OpenFlow Controller, OFC) 및 개방흐름 교환기(OpenFlow Switch, OFS)를 포함한다. OFS는 흐름 테이블(Flow Table)을 현지에 유지하고, 상기 흐름 테이블은 복수의 흐름 엔트리를 포함한다. 포워딩될 패킷이 흐름 테이블 내에 대응하는 흐름 엔트리를 가지면, 그 패킷은 흐름 테이블에 따라 포워딩 되고, 흐름 테이블 내에 대응하는 흐름 엔트리가 없으면, OFS는 OFC에 명령을 요구하고, OFC는 OFS의 요구를 수신한 후 흐름 테이블 내의 흐름 엔트리를 OFS에 전달하며, OFS는 그 전달된 흐름 엔트리를 획득한 다음 그 흐름 엔트리를 흐름 테이블에 부가하고, 새로운 흐름 테이블에 따라 패킷을 포워딩한다.

OpenFlow 네트워크에서, OFS는 일반적으로 초기의 흐름 테이블을 획득하여야 하며(즉, OFS는 OFC에 요구를 송신하고, OFC는 그 요구를 수신한 후 흐름 엔트리를 전달하며), 이에 따라 OFS는 패킷을 포워딩할 수 있다. 종래기술에서, 일반적으로, 흐름 테이블은 제어 평면이 데이터 평면과 분리되는 방식으로 획득된다.

도 1은 종래기술에서 OpenFlow 네트워크의 아키텍처에 대한 개략도이며, 도 1을 참조하면, OFC, 종래의 교환기, 복수의 OFS(OFS1 내지 OFS6)를 포함하며, 종래의 교환기, OFS1 내지 OFS6, 및 OFC는 제어 평면을 형성하고, OFS1 내지 OFS6과 OFC는 데이터 평면을 형성한다. OFS는 종래 교환기의 작업 모드에서 그리고 링크 계층 발견 프로토콜(Link Layer Discovery Protocol, LLDP) 또는 스패닝 트리 프로토콜(Spanning Tree Protocol, STP)과 같은 프로토콜에 기초해서 제어 평면을 초기화하며, 즉, 제어 평면이 초기화된 후, STP와 같은 프로토콜을 사용하여 생성된 포워딩 테이블을 사용함으로써 다양한 OpenFlow 제어 메시지를 포워딩하며, OFC는 제어 평면을 사용함으로써 OFS에 초기의 흐름 엔트리를 전달하고, OFS는 흐름 엔트리를 수신한 다음 흐름 엔트리를 OFS의 흐름 테이블에 부가하여, 초기의 흐름 테이블을 획득할 수 있다. 또한, 흐름 테이블에 따라 패킷을 처리하고, 이 패킷은 데이터 평면을 사용하여 포워딩된다.

종래기술에서는, 제어 평면과 데이터 평면은 2개의 상이한 물리적 네트워크이며, 하나 이상의 종래 교환기가 더 필요하며, 이는 하드웨어 비용을 증가시키고, 또한, 이 2개의 물리적 네트워크를 유지하기 위해서는 2개의 네트워크 관리 시스템이 필요하며, 이 역시 유지보수 비용을 증가시킨다.

본 발명의 실시예는 소프트웨어 정의 네트워크(software defined network, SDN) 교환기가 정확한 흐름 엔트리를 획득하는 방법, 정확한 흐름 엔트리, 대응하는 SDN 교환기, SDN 제어기, 및 SDN 시스템을 제공하며, 본 발명의 실시예는 SDN 교환기가 패킷을 포워딩하는 방법, 이 방법에 대응하는 SDN 교환기를 더 제공하며, 마지막으로, 본 발명의 실시예는 OFS가 경로 정보를 획득하는 방법, 이 방법에 대응하는 OFS를 제공한다. 본 발명의 실시예에서 제공하는, SDN 교환기가 정확한 흐름 엔트리를 획득하는 방법은 종래기술에 존재하는, 하드웨어 비용 및 유지보수 비용이 높다는 문제점을 해결하는 데 사용된다.

제1 관점의 제1 실시 방식에서, 본 발명의 실시예는 소프트웨어 정의 네트워크(software defined network, SDN) 교환기가 정확한 흐름 엔트리를 획득하는 방법을 개시하며, 상기 방법은 제2 SDN 교환기에 적용되고, 상기 제2 SDN 교환기는 제1 SDN 교환기 및 SDN 제어기에 접속되어 SDN 네트워크를 형성하며, 상기 SDN 제어기는 각각의 SDN 교환기와 대역내 통신 방식(inband communication manner)으로 통신하며, 상기 방법은:

상기 제1 SDN 교환기에 의해 송신되고 경로 정보를 수집하는 데 사용되는 제1 제어 메시지를 수신하는 단계 - 상기 제1 제어 메시지는 제1 SDN 교환기의 경로 정보를 반송(搬送)하며, 상기 제1 제어 메시지는 제1 SDN 교환기와 SDN 제어기 사이에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷으로 반송됨 - ;

상기 제2 SDN 교환기의 경로 정보를 상기 제1 제어 메시지에 부가하여 갱신된 제1 제어 메시지를 획득하는 단계; 및

상기 갱신된 제1 제어 메시지를 포함하는 최종적으로 갱신된 제1 제어 메시지를 수신한 후, 상기 SDN 제어기가, 각각의 SDN 교환기에 의해 상기 최종적으로 갱신된 제1 제어 메시지에 부가된 경로 정보에 따라 SDN 제어기와 제1 SDN 교환기 간의 루팅 경로를 결정하고 상기 루팅 경로에 따라 제1 SDN 교환기에 정확한 흐름 엔트리를 전달할 수 있도록, 상기 제2 SDN 교환기의 경로 정보가 부가되는 갱신된 제1 제어 메시지를 SDN 제어기에 포워딩하는 단계

를 포함한다.

제1 관점의 제1 실시 방식을 참조해서, 제1 관점의 제2 실시 방식에서, 상기 제1 SDN 교환기와 SDN 제어기 사이에 구축된 신뢰 가능한 접속은 TCP 접속을 포함하고, 상기 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷은 TCP/IP 패킷이고, 상기 TCP 접속은 상기 제2 SDN 교환기가 제1 SDN 교환기와 SDN 제어기 사이에서 수행되는 3-웨이 TCP 핸드셰이크에 관한 정보를 반송하는 TCP/IP 패킷을 포워딩함으로써 구축된다.

제1 관점의 제1 실시 방식을 참조해서, 제1 관점의 제3 실시 방식에서, 상기 제2 SDN 교환기는 정확한 흐름 테이블을 포함하고, 상기 정확한 흐름 테이블은 복수의 정확한 흐름 엔트리를 포함하고, 각각의 정확한 흐름 엔트리는 복수의 매치 필드 및 상기 복수의 매치 필드에 대응하는 명령을 포함하며,

상기 제2 SDN 교환기가 제1 SDN 교환기와 SDN 제어기 사이에서 수행되는 3-웨이 TCP 핸드셰이크의 메시지를 반송하는 TCP/IP 패킷을 포워딩하는 단계는,

상기 제2 SDN 교환기가 제1 SDN 교환기로부터 송신된 제1 TCP/IP 패킷을 수신하는 단계;

상기 수신된 제1 TCP/IP 패킷 내의 복수 편의 특징 정보를 획득하는 단계 - 상기 특징 정보는 제2 SDN 교환기 내의 정확한 흐름 테이블의 정확한 흐름 엔트리 내의 매치 필드에 대응함 - ; 및

상기 복수 편의 특징 정보와 상기 제2 SDN 교환기 내의 정확한 흐름 테이블 간의 정확한 정합을 수행하는 단계, 상기 정확한 정합이 실패하고 상기 수신된 제1 TCP/IP 패킷이 제1 유형의 TCP 핸드셰이크 메시지를 반송하는 것으로 판정되면, 상기 복수 편의 특징 정보 중 한 편 이상의 특징 정보와 상기 정확한 흐름 테이블 간의 와일드카드-매치(wildcard-match) 정합을 수행하는 단계 - 상기 와일드카드-매치 정합 동안 사용된 하나 이상의 매치 필드에 대응하는 명령을 사용하여 결정되는 포워딩 루트는 SDN 제어기에 최종적으로 도달할 수 있는 루트임 - , 및 상기 와일드카드-매치 정합이 성공하면, 상기 와일드카드-매치 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라, 상기 제1 TCP/IP 패킷을 SDN 제어기에 포워딩하기 위해 상기 제1 유형의 TCP/IP 핸드셰이크 메시지를 반송하는 수신된 제1 TCP/IP 패킷을 처리하는 단계 - 상기 제1 유형의 TCP/IP 핸드셰이크 메시지는 제1 TCP 핸드셰이크의 메시지 또는 제3 TCP 핸드셰이크의 메시지임 -

를 포함한다.

제1 관점의 제3 실시 방식을 참조해서, 제1 관점의 제4 실시 방식에서, 상기 제2 SDN 교환기가 제1 SDN 교환기와 SDN 제어기 사이에서 수행되는 3-웨이 TCP 핸드셰이크의 메시지를 반송하는 TCP/IP 패킷을 포워딩하는 단계는:

상기 제2 SDN 교환기가 상기 SDN 제어기로부터 송신된 제3 TCP/IP 패킷을 수신하는 단계 - 상기 제3 TCP/IP 패킷은 제2 핸드셰이크의 메시지를 반송함 - ;

상기 제3 TCP/IP 패킷 내의 복수 편의 특징 정보를 획득하는 단계 - 상기 특징 정보는 제2 SDN 교환기 내의 정확한 흐름 테이블의 정확한 흐름 엔트리 내의 매치 필드에 대응함 - ; 및

상기 복수 편의 특징 정보와 상기 제2 SDN 교환기 내의 정확한 흐름 테이블 간의 정확한 정합을 수행하는 단계, 상기 정확한 정합이 성공하면, 상기 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라 포워딩을 수행하는 단계, 및 상기 정합이 실패하고 상기 제3 TCP/IP 패킷이 제2 TCP 핸드셰이크의 메시지를 반송하는 것으로 판정되면, 제3 TCP/IP 패킷을 브로드캐스팅하는 단계

를 더 포함한다.

제1 관점의 제2 실시 방식 내지 제4 실시 방식 중 임의의 실시 방식을 참조해서, 제1 관점의 제5 실시 방식에서, 상기 제2 SDN 교환기는 상기 정확한 흐름 테이블을 저장하고, 상기 정확한 흐름 테이블은 복수의 정확한 흐름 엔트리를 포함하고, 각각의 정확한 흐름 엔트리는 복수의 매치 필드 및 상기 복수의 매치 필드에 대응하는 명령을 포함하며,

상기 제1 SDN 교환기에 의해 송신되고 경로 정보를 수집하는 데 사용되는 제1 제어 메시지를 수신하는 단계; 상기 제2 SDN 교환기의 경로 정보를 상기 제1 제어 메시지에 부가하여 갱신된 제1 제어 메시지를 획득하는 단계; 및 상기 제2 SDN 교환기의 경로 정보가 부가되는 갱신된 제1 제어 메시지를 SDN 제어기에 포워딩하는 단계는:

상기 제2 SDN 교환기가, 상기 제1 SDN 교환기로부터 송신되고 제1 제어 메시지를 반송하는 제2 TCP/IP 패킷을 수신하는 단계 - 상기 제2 TCP/IP 패킷은 복수 편의 특징 정보를 포함하고, 상기 특징 정보는 제2 SDN 교환기 내의 정확한 흐름 테이블의 정확한 흐름 엔트리 내의 매치 필드에 대응함 - ; 및

상기 제2 SDN 교환기가, 상기 제2 TCP/IP 패킷 내의 특징 정보와 상기 정확한 흐름 테이블 간의 정확한 정합을 수행하는 단계, 상기 정확한 정합이 실패하고 상기 수신된 제2 TCP/IP 패킷이 제1 제어 메시지를 반송하는 것으로 판정된 후, 상기 TCP/IP 패킷 내의 한 편 이상의 특징 정보 및 상기 정확한 흐름 테이블에 따라 와일드카드-매치 정합을 수행하는 단계 - 상기 와일드카드-매치 정합 동안 사용된 하나 이상의 매치 필드에 대응하는 명령을 사용하여 결정되는 포워딩 루트는 SDN 제어기에 최종적으로 도달할 수 있는 루트임 - , 상기 와일드카드-매치 정합이 성공하면, 제2 SDN 교환기의 경로 정보를 제1 제어 메시지에 부가하여, 상기 제2 SDN 교환기의 경로 정보가 부가되는 갱신된 제1 제어 메시지를 획득하는 단계, 및 상기 와일드카드-매치 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라, 상기 갱신된 제1 제어 메시지를 상기 SDN 제어기에 포워딩하는 단계

를 포함한다.

제1 관점의 제5 실시 방식을 참조해서, 제1 관점의 제6 실시 방식에서, 상기 와일드카드-매치 정합이 실패하면, 상기 제2 SDN 교환기의 이용 가능한 출력 포트가 획득되고, 각각의 이용 가능한 출력 포트에 대응하는, 상기 제2 SDN 교환기의 경로 정보는 제1 제어 메시지에 부가되며, 각각의 이용 가능한 출력 포트에 대응하는, 상기 제2 SDN 교환기의 경로 정보가 부가되는 갱신된 제1 제어 메시지는 상기 이용 가능한 출력 포트로부터 SDN 제어기에 포워딩된다.

제1 관점의 제3 내지 제6 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제1 관점의 제7 실시 방식에서, 상기 특징 정보는 목적지 MAC, 목적지 IP, 및 목적지 포트 번호를 포함하고, 상기 정확한 흐름 테이블 내의 흐름 엔트리 내의 와일드카드-매치 정합에 사용되는 매치 필드는 목적지 MAC, 목적지 IP, 및 목적지 포트 번호이며,

상기 복수 편의 특징 정보 중 한 편 이상의 특징 정보와 상기 정확한 흐름 테이블 간의 와일드카드-매치 정합을 수행하는 단계, 및 상기 와일드카드-매치 정합이 성공하면, 상기 와일드카드-매치 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라, 상기 제1 유형의 TCP/IP 핸드셰이크 메시지를 반송하는 수신된 제1 TCP/IP 패킷을 처리하는 단계는:

상기 복수 편의 특징 정보 내의 목적지 MAC, 목적지 IP, 및 목적지 포트 번호와 상기 흐름 엔트리 내의 목적지 MAC, 목적지 IP, 및 목적지 포트 번호 간의 정합을 수행하는 단계, 및 상기 정합이 성공하면, 상기 매칭에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라 상기 수신된 제1 TCI/IP 패킷을 처리하는 단계

를 포함한다.

제1 관점의 제1 내지 제7 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제1 관점의 제8 실시 방식에서,

상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 실행되고, 상기 제1 제어 메시지는 상기 OpenFlow 프로토콜로 정의된 OFPT_HELLO 메시지를 포함하고, 상기 OFPT_HELLO 메시지의 본문 필드는 확장된 후에 경로 정보를 반송하는 데 사용되며,

상기 제2 SDN 교환기의 경로 정보를 상기 제1 제어 메시지에 부가하여 갱신된 제1 제어 메시지를 획득하는 단계는:

상기 제2 SDN 교환기의 경로 정보를 상기 경로 정보를 반송하는 데 사용되는, OFPT_HELLO 메시지 내의 확장된 본문 필드에 부가하여, 갱신된 OFPT_HELLO 메시지를 획득하는 단계

를 포함하며,

상기 갱신된 제1 제어 메시지를 포함하는 최종적으로 갱신된 제1 제어 메시지를 수신한 후, 상기 SDN 제어기가, 각각의 SDN 교환기에 의해 상기 최종적으로 갱신된 제1 제어 메시지에 부가된 경로 정보에 따라 SDN 제어기와 제1 SDN 교환기 간의 루팅 경로를 결정하고 상기 루팅 경로에 따라 제1 SDN 교환기에 정확한 흐름 엔트리를 전달할 수 있도록, 상기 제2 SDN 교환기의 경로 정보가 부가되는 갱신된 제1 제어 메시지를 SDN 제어기에 포워딩하는 단계는:

상기 갱신된 OFPT_HELLO 메시지를 포함하는 최종적으로 갱신된 OFPT_HELLO 메시지를 수신한 후, 상기 SDN 제어기가, 각각의 SDN 교환기에 의해 상기 최종적으로 갱신된 OFPT_HELLO 메시지에 부가된 경로 정보에 따라, SDN 제어기와 제1 SDN 교환기 간의 루팅 경로를 결정하고, 상기 루팅 경로에 따라 제1 SDN 교환기에 정확한 흐름 엔트리를 전달할 수 있도록, 상기 제2 SDN 교환기의 경로 정보가 부가되는 갱신된 OFPT_HELLO 메시지를 SDN 제어기에 포워딩하는 단계

를 포함한다.

제1 관점의 제1 내지 제8 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제1 관점의 제9 실시 방식에서, 상기 제2 SDN 교환기의 경로 정보가 부가되는 갱신된 제1 제어 메시지를 SDN 제어기에 포워딩하는 단계는:

상기 제2 SDN 교환기의 경로 정보가 부가되는 상기 갱신된 제1 제어 메시지를 SDN 제어기에 직접적으로 포워딩하는 단계 - 상기 최종적으로 갱신된 제1 제어 메시지는 상기 갱신된 제1 제어 메시지임 - ; 또는

하나 이상의 다른 SDN 교환기를 사용함으로써, 상기 제2 SDN 교환기의 경로 정보가 부가되는 상기 갱신된 제1 제어 메시지를 SDN 제어기에 간접적으로 포워딩하는 단계

를 포함하며,

상기 최종적으로 갱신된 제1 제어 메시지는, 각각의 다른 SDN 교환기가 이전의 SDN 교환에 의해 송신된 제1 제어 메시지를 수신하고 각각의 다른 SDN 교환기의 경로 정보를 제1 제어 메시지에 부가한 후, 각각의 다른 SDN 교환기에 의해 SDN 제어기에 최종적으로 송신되는 제1 제어 메시지이다.

제1 관점의 제1 내지 제9 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제1 관점의 제10 실시 방식에서, 상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 실행되고, 상기 방법은:

상기 SDN 제어기로부터 송신되고 상기 OpenFlow 프로토콜로 정의된 OFPT_FLOW_MOD 메시지를 수신하는 단계 - 상기 OFPT_FLOW_MOD 메시지는 목적지 SDN 교환기에 의해 요구되는 복수의 정확한 흐름 엔트리를 반송함 - ; 및

상기 수신된 메시지가 상기 제2 SDN 교환기에 송신된 OFPT_FLOW_MOD 메시지인 것으로 판정될 때, 상기 OFPT_FLOW_MOD 메시지에 반송된 복수의 정확한 흐름 엔트리를 추출하고 그런 다음 상기 복수의 정확한 흐름 엔트리를 현지의 정확한 흐름 테이블에 부가하는 단계

를 더 포함한다.

제1 관점의 제1 내지 제9 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제1 관점의 제11 실시 방식에서, 상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 실행되고, 상기 방법은:

상기 SDN 제어기로부터 송신되고 상기 OpenFlow 프로토콜로 정의된 OFPT_FLOW_MOD 메시지를 수신하는 단계 - 상기 OFPT_FLOW_MOD 메시지는 상기 루팅 경로 상에 위치하는 복수의 SDN 교환기에 의해 요구되는 복수의 정확한 흐름 엔트리 및 상기 루팅 경로 상의 각각의 SDN 교환기에 대응하는 경로 정보를 반송하며, 상기 루팅 경로 상의 각각의 SDN 교환기는 하나 이상의 정확한 흐름 엔트리를 사용함 - ; 및

상기 수신된 메시지가 상기 제2 SDN 교환기에 송신된 OFPT_FLOW_MOD 메시지인 것으로 판정될 때, 상기 제2 SDN 교환기에 대응하는 경로 정보에 따라, 상기 제2 SDN 교환기에 의해 사용되어야 하는 하나 이상의 정확한 흐름 엔트리를 추출하고, 상기 추출이 완료된 후 OFPT_FLOW_MOD 메시지를 루팅 경로 상의 다음 노드에 포워딩하는 단계

를 더 포함한다.

제1 관점의 제1 내지 제11 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제1 관점의 제12 실시 방식에서, 상기 경로 정보는 제1 제어 메시지를 송신 또는 수신하는 SDN 교환기의 ID, 제1 제어 메시지를 수신하는 데 사용되는 포트 번호, 및 제1 제어 메시지를 송신하는 데 사용되는 포트 번호를 포함한다.

제2 관점의 제1 실시 방식에서, 본 발명의 실시예는 소프트웨어 정의 네트워크(software defined network, SDN) 교환기가 흐름 테이블을 획득하는 방법을 개시하며, 상기 방법은 SDN 제어기에 적용되고, 상기 SDN 제어기는 제2 SDN 교환기에 접속되고, 상기 제2 SDN 교환기는 제1 SDN 교환기에 접속되어 SDN 네트워크를 형성하며, 상기 SDN 제어기는 각각의 SDN 교환기와 대역내 통신 방식으로 통신하며, 상기 방법은:

상기 제2 SDN 교환기에 의해 포워딩된 최종적으로 갱신된 제1 제어 메시지를 수신하는 단계 - 상기 최종적으로 갱신된 제1 메시지는 갱신된 제1 제어 메시지를 포함하며, 상기 갱신된 제1 제어 메시지는 상기 제2 SDN 교환기가 제1 SDN 교환기에 의해 송신되고 경로 정보를 수집하는 데 사용되는 제1 제어 메시지를 수신한 후, 제2 SDN 교환기가 제2 SDN 교환기의 경로 정보를 제1 제어 메시지에 부가함으로써 획득되며, 상기 제1 제어 메시지는 제1 SDN 교환기의 경로 정보를 반송하며, 상기 제1 제어 정보는 제1 SDN 교환기와 SDN 제어기 사이에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷으로 반송됨 - ;

각각의 SDN 교환기에 의해 부가되고 상기 최종적으로 갱신된 제1 제어 메시지에 반송된 경로 정보에 따라 SDN 제어기와 제1 SDN 교환기 간의 루팅 경로를 획득하는 단계; 및

상기 루팅 경로에 따라 제1 SDN 교환기에 정확한 흐름 엔트리를 전달하는 단계

를 포함한다.

제2 관점의 제1 실시 방식을 참조해서, 제2 관점의 제2 실시 방식에서, 상기 제1 SDN 교환기와 SDN 제어기 사이에 구축된 신뢰 가능한 접속은 TCP 접속을 포함하고, 상기 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷은 TCP/IP 패킷이고, 상기 TCP 접속은 상기 제2 SDN 교환기가 제1 SDN 교환기와 SDN 제어기 사이에서 수행되는 3-웨이 TCP 핸드셰이크의 메시지를 반송하는 TCP/IP 패킷을 포워딩함으로써 구축된다.

제2 관점의 제1 내지 제2 실시 방식을 참조 중 어느 하나의 실시 방식을 참조해서, 제2 관점의 제3 실시 방식에서, 상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 실행되고, 상기 제1 제어 메시지는 상기 OpenFlow 프로토콜로 정의된 OFPT_HELLO 메시지를 포함하고, 상기 OFPT_HELLO 메시지의 본문 필드는 확장된 후에 경로 정보를 반송하는 데 사용된다.

제2 관점의 제1 내지 제3 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제2 관점의 제4 실시 방식에서, 상기 제2 SDN 교환기에 의해 포워딩된 최종적으로 갱신된 제1 제어 메시지를 수신하는 단계는:

상기 제2 SDN 교환기에 의해 포워딩된 상기 최종적으로 갱신된 제1 제어 메시지를 직접적으로 수신하는 단계;

또는,

상기 제2 SDN 교환기의 경로 정보가 부가되는 상기 갱신된 제1 제어 메시지에 대해서, 하나 이상의 다른 SDN 교환기를 사용함으로써, 상기 제2 SDN 교환기에 의해 포워딩된 상기 최종적으로 갱신된 제1 제어 메시지를 간접적으로 수신하는 단계

를 포함하며,

상기 최종적으로 갱신된 제1 제어 메시지는, 각각의 다른 SDN 교환기가 이전의 SDN 교환에 의해 송신된 제1 제어 메시지를 수신하고 각각의 다른 SDN 교환기의 경로 정보를 제1 제어 메시지에 부가한 후, 각각의 다른 SDN 교환기에 의해 SDN 제어기에 최종적으로 송신되는 제1 제어 메시지이다.

제2 관점의 제1 내지 제4 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제2 관점의 제5 실시 방식에서, 상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 실행되고, 상기 루팅 경로에 따라 제1 SDN 교환기에 정확한 흐름 엔트리를 전달하는 단계는:

상기 OpenFlow 프로토콜로 정의된 OFPT_FLOW_MOD 메시지에 상기 제1 SDN 교환기에 의해 요구되는 복수의 정확한 흐름을 부가하는 단계; 및

상기 OFPT_FLOW_MOD 메시지를 수신한 후, 상기 제1 SDN 교환기가 OFPT_FLOW_MOD 메시지에 반송된 복수의 정확한 흐름 엔트리를 추출하고 그런 다음 상기 복수의 정확한 흐름 엔트리를 현지의 정확한 흐름 테이블에 부가할 수 있도록, 상기 루팅 경로에 따라 제1 SDN 교환기에 OFPT_FLOW_MOD 메시지를 송신하는 단계

를 포함한다.

제2 관점의 제1 내지 제5 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제2 관점의 제6 실시 방식에서, 상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 실행되고, 상기 루팅 경로에 따라 제1 SDN 교환기에 정확한 흐름 엔트리를 전달하는 단계는:

상기 루팅 경로 상에 위치하는 복수의 SDN 교환기에 의해 요구되는 복수의 정확한 흐름 엔트리 및 상기 루팅 경로 상의 각각의 SDN 교환기에 대응하는 경로 정보를 상기 OpenFlow 프로토콜로 정의된 OFPT_FLOW_MOD 메시지에 부가하는 단계 - 상기 루팅 경로 상의 각각의 SDN 교환기는 하나 이상의 정확한 흐름 엔트리를 필요로 함 - ; 및

상기 OFPT_FLOW_MOD 메시지를 수신한 후, 상기 다른 SDN 교환기가 상기 경로 정보 및 상기 OFPT_FLOW_MOD 메시지 내의 경로 정보에 따라, 상기 다른 SDN 교환기에 의해 요구되는 추출 흐름 엔트리를 추출하고, 나머지 추출 흐름 엔트리를 포워딩하며, 제1 SDN 교환기에 의해 요구되는 정확한 흐름 엔트리를 제1 SDN 교환기에 최종적으로 포워딩할 수 있도록, 상기 루팅 경로에 따라 상기 OFPT_FLOW_MOD 메시지를 다른 SDN 교환기에 전달하는 단계

를 포함한다.

제3 관점의 제1 실시 방식에서, 본 발명의 실시예는 소프트웨어 정의 네트워크(software defined network, SDN) 교환기를 개시하며, 상기 SDN 교환기는 제2 SDN 교환기이고, 상기 제2 SDN 교환기는 제1 SDN 교환기 및 SDN 제어기에 접속되어 SDN 네트워크를 형성하며, 상기 SDN 제어기는 각각의 SDN 교환기와 대역내 통신 방식으로 통신하며, 상기 제2 SDN 교환기는:

상기 제1 SDN 교환기와 상기 SDN 제어기 사이에 신뢰 가능한 접속이 구축되어, 상기 제1 SDN 교환기와 상기 SDN 제어기 사이의 메시지 교환을 수행하도록 구성되어 있는 접속 구축 유닛;

상기 제1 SDN 교환기에 의해 송신되고 경로 정보를 수집하는 데 사용되는 제1 제어 메시지를 수신하도록 구성되어 있는 제1 수신 유닛 - 상기 제1 메시지는 제1 SDN 교환기의 경로 정보를 반송하며, 상기 제1 제어 정보는 상기 신뢰 가능한 접속에 대응하는 패킷으로 반송됨 - ;

상기 제1 수신 유닛에 의해 수신된 제1 제어 메시지에 상기 제2 SDN 교환기의 경로 정보를 부가하여 갱신된 제1 제어 메시지를 획득하는 경로 부가 유닛; 및

상기 갱신된 제1 제어 메시지를 포함하는 최종적으로 갱신된 제1 제어 메시지를 수신한 후, 상기 SDN 제어기가, 각각의 SDN 교환기에 의해 상기 최종적으로 갱신된 제1 제어 메시지에 부가된 경로 정보에 따라 SDN 제어기와 제1 SDN 교환기 간의 루팅 경로를 결정하고 상기 루팅 경로에 따라 제1 SDN 교환기에 정확한 흐름 엔트리를 전달할 수 있도록, 상기 경로 부가 유닛이 제2 SDN 교환기의 경로 정보를 부가하는 상기 갱신된 제1 제어 메시지를 SDN 제어기에 포워딩하도록 구성되어 있는 포워딩 유닛

을 포함한다.

제3 관점의 제1 실시 방식을 참조해서, 제3 관점의 제2 실시 방식에서, 상기 제1 SDN 교환기와 상기 SDN 제어기 사이에 구축된 신뢰 가능한 접속은 TCP 접속을 포함하고, 상기 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷은 TCP/IP 패킷이며,

상기 접속 구축 유닛은 구체적으로, 제1 SDN 교환기와 SDN 제어기 사이에 TCP 접속이 구축되어, 제1 SDN 교환기와 SDN 제어기 사이에서 수행되는 3-웨이 TCP 핸드셰이크의 메시지를 반송하는 TCP/IP 패킷을 포워딩하도록 구성되어 있다.

제3 관점의 제2 실시 방식을 참조해서, 제3 관점의 제3 실시 방식에서, 상기 제2 SDN 교환기는 정확한 흐름 테이블을 포함하고, 상기 정확한 흐름 테이블은 복수의 정확한 흐름 엔트리를 포함하고, 각각의 정확한 흐름 엔트리는 복수의 매치 필드 및 상기 복수의 매치 필드에 대응하는 명령을 포함하며,

상기 접속 구축 유닛은:

상기 제1 SDN 교환기로부터 송신된 제1 TCP/IP 패킷을 수신하도록 구성되어 있는 수신 서브유닛;

상기 수신 서브유닛에 의해 수신된 제1 TCP/IP 패킷 내의 복수 편의 특징 정보를 획득하도록 구성되어 있는 특징 정보 획득 서브유닛 - 상기 특징 정보는 제2 SDN 교환기 내의 정확한 흐름 테이블의 정확한 흐름 엔트리 내의 매치 필드에 대응함 - ; 및

상기 특징 정보 획득 서브유닛에 의해 획득되는 TCP/IP 패킷 내의 복수 편의 특징 정보와 상기 제2 SDN 교환기 내의 정확한 흐름 테이블 간의 정확한 정합을 수행하고, 상기 정확한 정합이 실패하고 상기 수신된 제1 TCP/IP 패킷이 제1 유형의 TCP 핸드셰이크 메시지를 반송하는 것으로 판정되면, 상기 복수 편의 특징 정보 중 한 편 이상의 특징 정보와 상기 정확한 흐름 테이블 간의 와일드카드-매치 정합을 수행하고 - 상기 와일드카드-매치 정합 동안 사용된 하나 이상의 매치 필드에 대응하는 명령을 사용하여 결정되는 포워딩 루트는 SDN 제어기에 최종적으로 도달할 수 있는 루트임 - , 그리고 상기 와일드카드-매치 정합이 성공하면, 상기 와일드카드-매치 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라, 상기 제1 유형의 TCP 핸드셰이크 메시지를 반송하는 상기 제1 TCP/IP 패킷을 SDN 제어기에 포워딩하기 위해 상기 제1 유형의 TCP/IP 핸드셰이크 메시지를 반송하는 상기 수신된 제1 TCP/IP 패킷을 처리하도록 구성되어 있는 제1 정합 서브유닛 - 상기 제1 유형의 TCP/IP 핸드셰이크 메시지는 제1 TCP 핸드셰이크의 메시지 또는 제3 TCP 핸드셰이크의 메시지임 -

을 포함한다.

제3 관점의 제3 실시 방식을 참조해서, 제3 관점의 제4 실시 방식에서, 상기 수신 서브유닛은 상기 SDN 제어기로부터 송신된 제3 TCP/IP 패킷을 수신하도록 구성되어 있으며, 여기서 상기 제3 TCP/IP 패킷은 제2 핸드셰이크의 메시지를 반송하며,

상기 특징 정보 획득 서브유닛은 상기 수신 서브유닛에 의해 수신된 제3 TCP/IP 패킷 내의 복수 편의 특징 정보를 획득하도록 구성되어 있으며, 여기서 상기 특징 정보는 제2 SDN 교환기 내의 정확한 흐름 테이블의 정확한 흐름 엔트리 내의 매치 필드에 대응하며, 그리고

상기 제1 매칭 서브유닛은 상기 특징 정보 획득 서브유닛에 의해 획득되는 제3 TCP/IP 패킷 내의 복수 편의 특징 정보와 상기 제2 SDN 교환기 내의 정확한 흐름 테이블 간의 정확한 정합을 수행하고, 상기 정확한 정합이 성공하면, 상기 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라 포워딩을 수행하며, 그리고 상기 정합이 실패하고 상기 제3 TCP/IP 패킷이 제2 TCP 핸드셰이크의 메시지를 반송하는 것으로 판정되면, 제3 TCP/IP 패킷을 브로드캐스팅하도록 구성되어 있다.

제3 관점의 제1 내지 제4 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제3 관점의 제5 실시 방식에서, 상기 제2 SDN 교환기는 상기 정확한 흐름 테이블을 저장하고, 상기 정확한 흐름 테이블은 복수의 정확한 흐름 엔트리를 포함하고, 각각의 정확한 흐름 엔트리는 복수의 매치 필드 및 상기 복수의 매치 필드에 대응하는 명령을 포함하며,

상기 제1 수신 유닛은 구체적으로,

상기 제1 SDN 교환기로부터 송신되고 제1 제어 메시지를 반송하는 제2 TCP/IP 패킷을 수신하도록 구성되어 있으며, 여기서 상기 제2 TCP/IP 패킷은 복수 편의 특징 정보를 포함하고, 상기 특징 정보는 제2 SDN 교환기 내의 정확한 흐름 테이블의 정확한 흐름 엔트리 내의 매치 필드에 대응하며,

상기 경로 부가 유닛은:

제2 수신 서브유닛에 의해 수신된 상기 제2 TCP/IP 패킷 내의 특징 정보 및 상기 정확한 흐름 테이블에 따라 정확한 정합을 수행하고, 상기 정확한 정합이 실패하고 상기 수신된 제2 TCP/IP 패킷이 제1 제어 메시지를 반송하는 것으로 판정된 후, 상기 TCP/IP 패킷 내의 한 편 이상의 특징 정보 및 상기 정확한 흐름 테이블에 따라 와일드카드-매치 정합을 수행하도록 구성되어 있는 제2 매칭 서브유닛 - 여기서 상기 와일드카드-매치 정합 동안 사용된 하나 이상의 매치 필드에 대응하는 명령을 사용하여 결정되는 포워딩 루트는 SDN 제어기에 최종적으로 도달할 수 있는 루트임 - ; 및

상기 제2 매칭 서브유닛의 와일드카드-매치 정합이 성공할 때, 제2 SDN 교환기의 경로 정보를 제1 제어 메시지에 부가하여, 상기 제2 SDN 교환기의 경로 정보가 부가되는 갱신된 제1 제어 메시지를 획득하도록 구성되어 있는 부가 서브유닛

을 포함하며, 그리고

상기 포워딩 유닛은:

상기 와일드카드-매치 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라, 상기 부가 서브유닛의 프로세싱 후에 획득되는 상기 갱신된 제1 제어 메시지를 상기 SDN 제어기에 포워딩하도록 구성되어 있는 제1 포워딩 서브유닛

을 포함한다.

제3 관점의 제5 실시 방식을 참조해서, 제3 관점의 제6 실시 방식에서, 상기 부가 서브유닛은, 상기 제2 매칭 서브유닛의 와일드카드-매치 정합이 실패하면, 상기 제2 SDN 교환기의 이용 가능한 출력 포트를 획득하고, 각각의 이용 가능한 출력 포트에 대응하는, 상기 제2 SDN 교환기의 경로 정보를 제1 제어 메시지에 부가하도록 추가로 구성되어 있으며,

상기 포워딩 유닛은 각각의 이용 가능한 출력 포트에 대응하는, 상기 제2 SDN 교환기의 경로 정보를 상기 부가 서브유닛이 부가하는 상기 갱신된 제1 제어 메시지를, 상기 이용 가능한 출력 포트로부터 SDN 제어기에 포워딩하도록 구성되어 있는 제2 포워딩 서브유닛을 포함한다.

제3 관점의 제1 내지 제6 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제3 관점의 제7 실시 방식에서, 상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 실행되고, 상기 제1 제어 메시지는 상기 OpenFlow 프로토콜로 정의된 OFPT_HELLO 메시지를 포함하고, 상기 OFPT_HELLO 메시지의 본문 필드는 확장된 후에 경로 정보를 반송하는 데 사용되며,

상기 제1 수신 유닛은 구체적으로, 상기 접속 구축 유닛에 의해 구축된 신뢰 가능한 접속을 사용함으로써, 상기 제1 SDN 교환기에 의해 송신되고 상기 경로 정보를 수집하는 데 사용되는 OFPT_HELLO 메시지를 수신하도록 구성되고, 여기서, 상기 경로 정보를 반송하는 데 사용되는, 상기 OFPT_HELLO 메시지 내의 확장 본문 필드는 상기 제1 SDN 교환기의 경로 정보를 반송하며,

상기 경로 부가 유닛은 구체적으로, 상기 제2 SDN 교환기의 경로 정보를, 상기 경로 정보를 반송하는 데 사용되는, 상기 제1 수신 유닛에 의해 수신된 OFPT_HELLO 메시지 내의 확장 본문 필드에 부가하여, 갱신된 OFPT_HELLO 메시지를 획득하도록 구성되어 있으며,

상기 포워딩 유닛은 구체적으로, 상기 갱신된 OFPT_HELLO 메시지를 포함하는 최종적으로 갱신된 OFPT_HELLO 메시지를 수신한 후, 상기 SDN 제어기가, 각각의 SDN 교환기에 의해 상기 최종적으로 갱신된 OFPT_HELLO 메시지에 부가된 경로 정보에 따라 SDN 제어기와 제1 SDN 교환기 간의 루팅 경로를 결정하고 상기 루팅 경로에 따라 제1 SDN 교환기에 정확한 흐름 엔트리를 전달할 수 있도록, 상기 경로 부가 유닛이 제2 SDN 교환기의 경로 정보를 부가하는 상기 갱신된 OFPT_HELLO 메시지를 SDN 제어기에 포워딩하도록 구성되어 있다.

제3 관점의 제1 내지 제7 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제3 관점의 제8 실시 방식에서, 상기 포워딩 유닛은 구체적으로, 상기 제2 SDN 교환기의 경로 정보가 부가되는 상기 갱신된 제1 제어 메시지를 SDN 제어기에 직접적으로 포워딩하거나 - 상기 최종적으로 갱신된 제1 제어 메시지는 상기 갱신된 제1 제어 메시지임 - ; 또는

하나 이상의 다른 SDN 교환기를 사용함으로써, 상기 제2 SDN 교환기의 경로 정보가 부가되는 상기 갱신된 제1 제어 메시지를 SDN 제어기에 간접적으로 포워딩하도록 구성되어 있으며,

상기 최종적으로 갱신된 제1 제어 메시지는, 각각의 다른 SDN 교환기가 이전의 SDN 교환에 의해 송신된 제1 제어 메시지를 수신하고 각각의 다른 SDN 교환기의 경로 정보를 제1 제어 메시지에 부가한 후, 각각의 다른 SDN 교환기에 의해 SDN 제어기에 최종적으로 송신되는 제1 제어 메시지이다.

제3 관점의 제1 내지 제8 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제3 관점의 제9 실시 방식에서, 상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 실행되고, 상기 SDN 교환기는:

상기 SDN 제어기로부터 송신되고 상기 OpenFlow 프로토콜로 정의된 OFPT_FLOW_MOD 메시지를 수신하도록 구성되어 있는 제2 수신 유닛 - 상기 OFPT_FLOW_MOD 메시지는 목적지 SDN 교환기에 의해 요구되는 복수의 정확한 흐름 엔트리를 반송함 - ; 및

상기 제2 수신 유닛에 의해 수신된 메시지가 상기 제2 SDN 교환기에 송신된 OFPT_FLOW_MOD 메시지인 것으로 판정될 때, 상기 OFPT_FLOW_MOD 메시지에 반송된 복수의 정확한 흐름 엔트리를 추출하고 그런 다음 상기 복수의 정확한 흐름 엔트리를 현지의 정확한 흐름 테이블에 부가하도록 구성되어 있는 제1 흐름 엔트리 프로세싱 유닛

을 더 포함한다.

제3 관점의 제1 내지 제8 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제3 관점의 제10 실시 방식에서, 상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 실행되고, 상기 SDN 교환기는:

상기 SDN 제어기로부터 송신되고 상기 OpenFlow 프로토콜로 정의된 OFPT_FLOW_MOD 메시지를 수신하도록 구성되어 있는 제3 수신 유닛 - 상기 OFPT_FLOW_MOD 메시지는 상기 루팅 경로 상에 위치하는 복수의 SDN 교환기에 의해 요구되는 복수의 정확한 흐름 엔트리 및 상기 루팅 경로 상의 각각의 SDN 교환기에 대응하는 경로 정보를 반송하며, 상기 루팅 경로 상의 각각의 SDN 교환기는 하나 이상의 정확한 흐름 엔트리를 사용함 - ; 및

상기 제3 수신 유닛에 의해 수신된 메시지가 상기 제2 SDN 교환기에 송신된 OFPT_FLOW_MOD 메시지인 것으로 판정될 때, 상기 제2 SDN 교환기에 대응하는 경로 정보에 따라, 상기 제2 SDN 교환기에 의해 사용되어야 하는 하나 이상의 정확한 흐름 엔트리를 추출하고, 상기 추출이 완료된 후 OFPT_FLOW_MOD 메시지를 루팅 경로 상의 다음 노드에 포워딩하도록 구성되어 있는 제2 흐름 엔트리 프로세싱 유닛

을 더 포함한다.

제3 관점의 제1 내지 제10 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제3 관점의 제11 실시 방식에서, 상기 경로 정보는 제1 제어 메시지를 송신 또는 수신하는 SDN 교환기의 ID, 제1 제어 메시지를 수신하는 데 사용되는 포트 번호, 및 제1 제어 메시지를 송신하는 데 사용되는 포트 번호를 포함한다.

제4 관점의 제1 실시 방식에서, 본 발명의 실시예는 소프트웨어 정의 네트워크(software defined network, SDN) 제어기를 개시하며, 상기 SDN 제어기는 제2 SDN 교환기 접속되고, 상기 제2 SDN 교환기는 제1 SDN 교환기에 접속되어 SDN 네트워크를 형성하며, 상기 SDN 제어기는 각각의 SDN 교환기와 대역내 통신 방식으로 통신하며, 상기 SDN 제어기는:

상기 제2 SDN 교환기에 의해 포워딩된 최종적으로 갱신된 제1 제어 메시지를 수신하도록 구성되어 있는 제1 수신 유닛 - 상기 최종적으로 갱신된 제1 메시지는 갱신된 제1 제어 메시지를 포함하며, 상기 갱신된 제1 제어 메시지는 상기 제2 SDN 교환기가 제1 SDN 교환기에 의해 송신되고 경로 정보를 수집하는 데 사용되는 제1 제어 메시지를 수신한 후, 제2 SDN 교환기가 제2 SDN 교환기의 경로 정보를 제1 제어 메시지에 부가함으로써 획득되며, 상기 제1 제어 메시지는 제1 SDN 교환기의 경로 정보를 반송하며, 상기 제1 제어 정보는 제1 SDN 교환기와 SDN 제어기 사이에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷으로 반송됨 - ;

각각의 SDN 교환기에 의해 부가되고 상기 제1 수신 유닛에 의해 수신된 상기 최종적으로 갱신된 제1 제어 메시지에 반송된 경로 정보에 따라 SDN 제어기와 제1 SDN 교환기 간의 루팅 경로를 획득하도록 구성되어 있는 경로 획득 유닛; 및

상기 경로 획득 유닛에 의해 획득된 루팅 경로를 통해 제1 SDN 교환기에 정확한 흐름 엔트리를 전달하도록 구성되어 있는 흐름 테이블 전달 유닛

을 포함한다.

제4 관점의 제1 실시 방식을 참조해서, 제4 관점의 제2 실시 방식에서, 상기 제1 SDN 교환기와 SDN 제어기 사이에 구축된 신뢰 가능한 접속은 TCP 접속을 포함하고, 상기 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷은 TCP/IP 패킷이고, 상기 TCP 접속은 상기 제2 SDN 교환기가 제1 SDN 교환기와 SDN 제어기 사이에서 수행되는 3-웨이 TCP 핸드셰이크의 메시지를 반송하는 TCP/IP 패킷을 포워딩함으로써 구축된다.

제4 관점의 제1 내지 제2 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제4 관점의 제3 실시 방식에서, 상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 실행되고, 상기 제1 제어 메시지는 OFPT_HELLO 메시지를 포함하고, 상기 OFPT_HELLO 메시지의 본문 필드는 확장된 후에 경로 정보를 반송하는 데 사용된다.

제4 관점의 제1 내지 제3 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제4 관점의 제4 실시 방식에서, 상기 제1 수신 유닛은 구체적으로:

상기 제2 SDN 교환기에 의해 포워딩된 상기 최종적으로 갱신된 제1 제어 메시지를 직접적으로 수신하거나;

또는,

하나 이상의 다른 SDN 교환기를 사용함으로써, 상기 제2 SDN 교환기에 의해 포워딩된 상기 최종적으로 갱신된 제1 제어 메시지를 간접적으로 수신하도록 구성되어 있으며,

상기 최종적으로 갱신된 제1 제어 메시지는, 각각의 다른 SDN 교환기가 이전의 SDN 교환에 의해 송신된 제1 제어 메시지를 수신하고 각각의 다른 SDN 교환기의 경로 정보를 제1 제어 메시지에 부가한 후, 각각의 다른 SDN 교환기에 의해 SDN 제어기에 최종적으로 송신되는 제1 제어 메시지이다.

제4 관점의 제1 내지 제4 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제4 관점의 제5 실시 방식에서, 상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 실행되고, 상기 흐름 제어 전달 유닛은 구체적으로:

상기 OpenFlow 프로토콜로 정의된 OFPT_FLOW_MOD 메시지에 상기 제1 SDN 교환기에 의해 요구되는 복수의 정확한 흐름을 부가하고; 그리고

상기 제1 SDN 교환기가 OFPT_FLOW_MOD 메시지에 따라 정확한 흐름 엔트리를 획득할 수 있도록, 상기 루팅 경로를 통해 제1 SDN 교환기에 OFPT_FLOW_MOD 메시지를 송신하도록 구성되어 있다.

제4 관점의 제1 내지 제4 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제4 관점의 제6 실시 방식에서, 상기 흐름 제어 전달 유닛은 구체적으로:

상기 루팅 경로 상에 위치하는 복수의 SDN 교환기에 의해 요구되는 복수의 정확한 흐름 엔트리 및 상기 루팅 경로 상의 각각의 SDN 교환기에 대응하는 경로 정보를 상기 OpenFlow 프로토콜로 정의된 OFPT_FLOW_MOD 메시지에 부가하며 - 상기 루팅 경로 상의 각각의 SDN 교환기는 하나 이상의 정확한 흐름 엔트리를 필요로 함 - ; 그리고

상기 OFPT_FLOW_MOD 메시지를 수신한 후, 상기 다른 SDN 교환기가 상기 경로 정보 및 상기 OFPT_FLOW_MOD 메시지 내의 경로 정보에 따라, 상기 다른 SDN 교환기에 의해 요구되는 추출 흐름 엔트리를 추출하고, 나머지 추출 흐름 엔트리를 포워딩하며, 제1 SDN 교환기에 의해 요구되는 정확한 흐름 엔트리를 제1 SDN 교환기에 최종적으로 포워딩할 수 있도록, 상기 루팅 경로를 통해 상기 OFPT_FLOW_MOD 메시지를 다른 SDN 교환기에 전달하도록 구성되어 있다.

제5 관점의 제1 실시 방식에서, 본 발명의 실시예는 소프트웨어 정의 네트워크 시스템을 개시하며, 상기 시스템은: 제1 SDN 교환기, 제2 SDN 교환기, 및 SDN 제어기를 포함하며, 상기 제2 SDN 교환기는 제1 SDN 교환기 및 SDN 제어기에 접속되어 SDN 네트워크를 형성하며, 상기 SDN 제어기는 각각의 SDN 교환기와 대역내 통신 방식으로 통신하며,

상기 제1 SDN 교환기는 경로 정보를 수신하는 데 사용되는 제1 제어 메시지를 상기 제2 SDN 교환기에 송신하도록 구성되어 있으며, 여기서 상기 제1 메시지는 제1 SDN 교환기의 경로 정보를 반송하며, 상기 제1 제어 정보는 제1 SDN 교환기와 SDN 제어기 간에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷으로 반송되며;

상기 제2 SDN 교환기는 제1 제어 메시지를 수신하고 상기 제1 제어 메시지에 상기 제2 SDN 교환기의 경로 정보를 부가하여 갱신된 제1 제어 메시지를 획득하고, 제2 SDN 교환기의 경로 정보가 부가되는 상기 갱신된 제1 제어 메시지를 SDN 제어기에 포워딩하도록 구성되어 있으며,

상기 SDN 제어기는, 상기 제2 SDN 교환기에 의해 송신되고 상기 갱신된 제1 제어 메시지를 포함하는 최종적으로 갱신된 제1 제어 메시지를 수신하고, 각각의 SDN 교환기에 의해 상기 최종적으로 갱신된 제1 제어 메시지에 부가된 경로 정보에 따라, SDN 제어기와 제1 SDN 교환기 간의 루팅 경로를 결정하며, 상기 루팅 경로에 따라 제1 SDN 교환기에 정확한 흐름 엔트리를 전달하도록 구성되어 있다.

제4 관점의 제1 실시 방식을 참조해서, 제5 관점의 제2 실시 방식에서, 상기 제1 SDN 교환기와 상기 SDN 제어기 사이에 구축된 신뢰 가능한 접속은 TCP 접속을 포함하고, 상기 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷은 TCP/IP 패킷이며, 상기 TCP/IP 접속은, 상기 제2 SDN 교환기가, 제1 SDN 교환기와 SDN 제어기 사이에서 수행되는 3-웨이 TCP 핸드셰이크의 메시지를 반송하는 TCP/IP 패킷을 포워딩함으로써 구축된다.

제4 관점의 제2 실시 방식을 참조해서, 제5 관점의 제3 실시 방식에서, 상기 제2 SDN 교환기는 정확한 흐름 테이블을 저장하고, 상기 정확한 흐름 테이블은 복수의 정확한 흐름 엔트리를 포함하고, 각각의 정확한 흐름 엔트리는 복수의 매치 필드 및 상기 복수의 매치 필드에 대응하는 명령을 포함하며,

상기 제2 SDN 교환기는 구체적으로, 상기 제1 SDN 교환기로부터 송신된 제1 TCP/IP 패킷을 수신하고, 상기 수신된 제1 TCP/IP 패킷 내의 복수 편의 특징 정보를 획득하고 - 상기 특징 정보는 제2 SDN 교환기 내의 정확한 흐름 테이블의 정확한 흐름 엔트리 내의 매치 필드에 대응함 - , 그리고 상기 복수 편의 특징 정보와 상기 제2 SDN 교환기 내의 정확한 흐름 테이블 간의 정확한 정합을 수행하고, 상기 정확한 정합이 실패하고 상기 수신된 제1 TCP/IP 패킷이 제1 유형의 TCP 핸드셰이크 메시지를 반송하는 것으로 판정되면, 상기 복수 편의 특징 정보 중 한 편 이상의 특징 정보와 상기 정확한 흐름 테이블 간의 와일드카드-매치 정합을 수행하며 - 상기 와일드카드-매치 정합 동안 사용된 하나 이상의 매치 필드에 대응하는 명령을 사용하여 결정되는 포워딩 루트는 SDN 제어기에 최종적으로 도달할 수 있는 루트임 - , 그리고 상기 와일드카드-매치 정합이 성공하면, 상기 와일드카드-매치 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라, 상기 제1 TCP/IP 패킷을 SDN 제어기에 포워딩하기 위해, 상기 제1 유형의 TCP/IP 핸드셰이크 메시지를 반송하는 상기 수신된 제1 TCP/IP 패킷을 처리하도록 구성되어 있으며, 상기 제1 유형의 TCP/IP 핸드셰이크 메시지는 제1 TCP 핸드셰이크의 메시지 또는 제3 TCP 핸드셰이크의 메시지이며, 제1 SDN 교환기와 다른 OFS와 SDN 제어기 사이에서 상기 신뢰의 구축을 구축하는 데 사용되는 메시지의 교환을 실행하여, 상기 신뢰 가능한 접속을 구축한다.

제4 관점의 제2 내지 제3 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제5 관점의 제4 실시 방식에서, 상기 제2 SDN 교환기는 상기 정확한 흐름 테이블을 저장하고, 상기 정확한 흐름 테이블은 복수의 정확한 흐름 엔트리를 포함하고, 각각의 정확한 흐름 엔트리는 복수의 매치 필드 및 상기 복수의 매치 필드에 대응하는 명령을 포함하며,

상기 제2 SDN 교환기는 구체적으로, 상기 제1 SDN 교환기로부터 송신되고 제1 제어 메시지를 반송하는 제2 TCP/IP 패킷을 수신하고 - 상기 제2 TCP/IP 패킷은 복수 편의 특징 정보를 포함하고, 상기 특징 정보는 제2 SDN 교환기 내의 정확한 흐름 테이블의 정확한 흐름 엔트리 내의 매치 필드에 대응함 - , 상기 제2 TCP/IP 패킷 내의 특징 정보 및 상기 정확한 흐름 테이블에 따라 정확한 정합을 수행하고, 상기 정확한 정합이 실패하고 상기 수신된 제2 TCP/IP 패킷이 제1 제어 메시지를 반송하는 것으로 판정된 후, 상기 TCP/IP 패킷 내의 한 편 이상의 특징 정보 및 상기 정확한 흐름 테이블에 따라 와일드카드-매치 정합을 수행하며 - 여기서 상기 와일드카드-매치 정합 동안 사용된 하나 이상의 매치 필드에 대응하는 명령을 사용하여 결정되는 포워딩 루트는 SDN 제어기에 최종적으로 도달할 수 있는 루트임 - ; 그리고 상기 제2 매칭 서브유닛의 와일드카드-매치 정합이 성공할 때, 제2 SDN 교환기의 경로 정보를 제1 제어 메시지에 부가하여, 상기 제2 SDN 교환기의 경로 정보가 부가되는 갱신된 제1 제어 메시지를 획득하며, 상기 와일드카드-매치 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라, 상기 갱신된 제1 제어 메시지를 상기 SDN 제어기에 포워딩하도록 구성되어 있다.

제4 관점의 제1 내지 제4 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제5 관점의 제5 실시 방식에서, 상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 실행되고, 상기 제1 제어 메시지는 상기 OpenFlow 프로토콜로 정의된 OFPT_HELLO 메시지를 포함하고, 상기 OFPT_HELLO 메시지의 본문 필드는 확장된 후에 경로 정보를 반송하는 데 사용된다.

제4 관점의 제1 내지 제5 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제5 관점의 제6 실시 방식에서, 상기 제2 SDN 교환기는 구체적으로:

상기 제2 SDN 교환기의 경로 정보가 부가되는 상기 갱신된 제1 제어 메시지를 SDN 제어기에 직접적으로 포워딩하거나 - 상기 최종적으로 갱신된 제1 제어 메시지는 상기 갱신된 제1 제어 메시지임 - ; 또는

하나 이상의 다른 SDN 교환기를 사용함으로써, 상기 제2 SDN 교환기의 경로 정보가 부가되는 상기 갱신된 제1 제어 메시지를 SDN 제어기에 간접적으로 포워딩하도록 구성되어 있으며,

상기 최종적으로 갱신된 제1 제어 메시지는, 각각의 다른 SDN 교환기가 이전의 SDN 교환에 의해 송신된 제1 제어 메시지를 수신하고 각각의 다른 SDN 교환기의 경로 정보를 제1 제어 메시지에 부가한 후, 각각의 다른 SDN 교환기에 의해 SDN 제어기에 최종적으로 송신되는 제1 제어 메시지이다.

제4 관점의 제1 내지 제6 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제5 관점의 제7 실시 방식에서, 상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 실행되고, 상기 제2 SDN 교환기는:

상기 SDN 제어기로부터 송신되고 상기 OpenFlow 프로토콜로 정의된 OFPT_FLOW_MOD 메시지를 수신하고 - 상기 OFPT_FLOW_MOD 메시지는 목적지 SDN 교환기에 의해 요구되는 복수의 정확한 흐름 엔트리를 반송함 - ; 그리고

상기 수신된 메시지가 상기 제2 SDN 교환기에 송신된 OFPT_FLOW_MOD 메시지인 것으로 판정될 때, 상기 OFPT_FLOW_MOD 메시지에 반송된 복수의 정확한 흐름 엔트리를 추출하고 그런 다음 상기 복수의 정확한 흐름 엔트리를 현지의 정확한 흐름 테이블에 부가하도록 추가로 구성되어 있다.

제4 관점의 제1 내지 제6 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제5 관점의 제8 실시 방식에서, 상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 실행되고, 상기 제2 SDN 교환기는:

상기 SDN 제어기로부터 송신되고 상기 OpenFlow 프로토콜로 정의된 OFPT_FLOW_MOD 메시지를 수신하고 - 상기 OFPT_FLOW_MOD 메시지는 상기 루팅 경로 상에 위치하는 복수의 SDN 교환기에 의해 요구되는 복수의 정확한 흐름 엔트리 및 상기 루팅 경로 상의 각각의 SDN 교환기에 대응하는 경로 정보를 반송하며, 상기 루팅 경로 상의 각각의 SDN 교환기는 하나 이상의 정확한 흐름 엔트리를 사용함 - ; 그리고

상기 수신된 메시지가 상기 제2 SDN 교환기에 송신된 OFPT_FLOW_MOD 메시지인 것으로 판정될 때, 상기 제2 SDN 교환기에 대응하는 경로 정보에 따라, 상기 제2 SDN 교환기에 의해 사용되어야 하는 하나 이상의 정확한 흐름 엔트리를 추출하고, 상기 추출이 완료된 후 OFPT_FLOW_MOD 메시지를 루팅 경로 상의 다음 노드에 포워딩하도록 구성되어 있다.

제4 관점의 제1 내지 제8 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제5 관점의 제9 실시 방식에서, 상기 경로 정보는 제1 제어 메시지를 송신 또는 수신하는 SDN 교환기의 ID, 제1 제어 메시지를 수신하는 데 사용되는 포트 번호, 및 제1 제어 메시지를 송신하는 데 사용되는 포트 번호를 포함한다.

제6 관점의 제1 실시 방식에서, 본 발명의 실시예는 소프트웨어 정의 네트워크(software defined network, SDN) 제어기가 패킷을 포워딩하는 방법을 개시하며, 상기 SDN 교환기는 제2 SDN 교환기이고, 상기 제2 SDN 교환기는 정확한 흐름 테이블을 저장하고, 상기 정확한 흐름 테이블은 적어도 하나의 정확한 흐름 엔트리를 포함하고, 각각의 정확한 흐름 엔트리는 복수의 매치 필드 및 상기 복수의 매치 필드에 대응하는 명령을 포함하며, 상기 방법은:

제1 SDN 교환기로부터 송신된 패킷을 수신하는 단계 - 상기 패킷은 복수 편의 특징 정보를 포함하며, 상기 특징 정보는 상기 정확한 흐름 엔트리 내의 매치 필드에 대응함 - ;

상기 패킷 내의 특징 정보를 획득하는 단계; 및

상기 특징 정보와 상기 정확한 흐름 테이블 내의 정확한 흐름 엔트리 간의 정확한 정합을 수행하고, 상기 정확한 정합이 실패하면, 상기 복수 편의 특징 정보 중 한 편 이상의 특징 정보와 상기 정확한 흐름 테이블 내의 정확한 흐름 엔트리 간의 와일드카드-매치 정합을 수행하며 - 상기 와일드카드-매치 정합 동안 사용된 하나 이상의 매치 필드에 대응하는 명령을 사용하여 결정되는 포워딩 루트는 SDN 제어기에 최종적으로 도달할 수 있는 루트임 - , 그리고 상기 와일드카드-매치 정합이 성공하면, 상기 와일드카드-매치 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라, 상기 패킷을 SDN 제어기에 포워딩하는 단계

를 포함한다.

제6 관점의 제1 실시 방식을 참조해서, 제6 관점의 제2 실시 방식에서, 상기 정확한 정합이 성공하면, 상기 포워딩하는 단계는 상기 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라 수행되고,

상기 와일드카드-매치 정합이 실패하면, 상기 수신된 패킷은 브로드캐스팅을 통해 포워딩된다.

제6 관점의 제1 내지 제2 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제6 관점의 제3 실시 방식에서, 상기 제2 SDN 교환기는 제1 SDN 교환기 및 SDN 제어기에 접속되어 SDN 네트워크를 형성하며, 상기 SDN 제어기는 각각의 SDN 교환기와 대역내 통신 방식으로 통신한다.

제6 관점의 제1 내지 제3 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제6 관점의 제3 실시 방식에서,

상기 패킷은 제1 SDN 교환기와 SDN 제어기 사이에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷이며, 상기 패킷은 제1 SDN 교환기에 의해 송신되고 경로 정보를 수집하는 데 사용되는 제1 제어 메시지를 반송하는 데 사용된다.

제7 관점의 제1 실시 방식에서, 본 발명의 실시예는 소프트웨어 정의 네트워크(software defined network, SDN) 교환기를 개시하며, 상기 SDN 교환기는 제2 SDN 교환기이고, 상기 제2 SDN 교환기는 정확한 흐름 테이블을 저장하고, 상기 정확한 흐름 테이블은 복수의 정확한 흐름 엔트리를 포함하고, 각각의 정확한 흐름 엔트리는 복수의 매치 필드 및 상기 복수의 매치 필드에 대응하는 명령을 포함하며, 상기 제2 SDN 교환기는:

제1 SDN 교환기로부터 송신된 패킷을 수신하도록 구성되어 있는 수신 유닛 - 상기 패킷은 한 편 이상의 특징 정보를 포함함 - ;

상기 수신 유닛에 의해 수신된 패킷 내의 특징 정보를 획득하도록 구성되어 있는 획득 유닛;

상기 획득 유닛에 의해 획득된 한 편 이상의 특징 정보와 상기 정확한 흐름 테이블 내의 정확한 흐름 엔트리 간의 정확한 정합을 수행하도록 구성되어 있는 정확한 정합 유닛 - 상기 한 편 이상의 특징 정보는 상기 정확한 흐름 테이블 내의 정확한 흐름 엔트리 내의 매치 필드에 대응함 - ;

상기 정확한 정합 유닛에 의해 수행된 정확한 정합이 실패하면, 상기 복수 편의 특징 정보 중 한 편 이상의 특징 정보와 상기 정확한 흐름 테이블 내의 정확한 흐름 엔트리 간의 와일드카드-매치 정합을 수행하도록 구성되어 있는 와일드카드-매치 정합 유닛 - 상기 와일드카드-매치 정합 동안 사용된 하나 이상의 매치 필드에 대응하는 명령을 사용하여 결정되는 포워딩 루트는 SDN 제어기에 최종적으로 도달할 수 있는 루트임 - ; 및

상기 와일드카드-매치 정합 유닛에 의해 수행된 와일드카드-매치 정합이 성공하면, 상기 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라, 상기 패킷을 포워딩하도록 구성되어 있는 포워딩 유닛

을 포함한다.

제7 관점의 제1 실시 방식을 참조해서, 제7 관점의 제2 실시 방식에서, 상기 정합 및 포워딩 유닛은:

상기 정확한 정합이 성공하면, 상기 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라 포워딩을 수행하고,

상기 와일드카드-매치 정합이 실패하면, 브로드캐스팅을 통해 포워딩을 수행하도록 추가로 구성되어 있다.

제7 관점의 제1 내지 제2 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제7 관점의 제3 실시 방식에서, 상기 제2 SDN 교환기는 제1 SDN 교환기 및 SDN 제어기에 접속되어 SDN 네트워크를 형성하며, 상기 SDN 제어기는 각각의 SDN 교환기와 대역내 통신 방식으로 통신한다.

제7 관점의 제1 내지 제3 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제7 관점의 제4 실시 방식에서, 상기 패킷은 제1 SDN 교환기와 SDN 제어기 사이에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷이며, 상기 패킷은 제1 SDN 교환기에 의해 송신되고 경로 정보를 수집하는 데 사용되는 제1 제어 메시지를 반송하는 데 사용된다.

제8 관점의 제1 실시 방식에서, 본 발명의 실시예는 개방흐름 교환기(OpenFlow Switch, OFS)가 경로 정보를 수집하는 방법을 개시하며, 상기 방법은 제2 OFS에 적용되고, 상기 제2 OFS는 제1 OFS 및 흐름개방 제어기(OpenFlow Controller, OFC)에 접속되어 OpenFlow 네트워크를 형성하며, 상기 OFC는 대역내 통신 방식으로 각각의 OFS와 통신하며, 상기 방법은:

상기 제1 OFS에 의해 송신되고, 경로 정보를 수집하는 데 사용되며, 상기 OpenFlow 프로토콜에 정의되는 OFPT_HELLO 메시지를 수신하는 단계 - 상기 OFPT_HELLO 메시지의 본문 필드는 확장된 후 상기 경로 정보를 반송하는 데 사용되고, 상기 OFPT_HELLO 메시지는 제1 OFS의 경로 정보를 반송하며, 상기 OFPT_HELLO 메시지는 제1 OFS와 OFC 간에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷으로 반송됨 - ;

상기 제2 OFS의 경로 정보를 상기 OFPT_HELLO 메시지에 부가하여 갱신된 OFPT_HELLO 메시지를 획득하는 단계; 및

상기 갱신된 OFPT_HELLO 메시지를 포함하는 최종적으로 갱신된 OFPT_HELLO 메시지를 수신한 후, 상기 OFC가 각각의 OFS에 의해 상기 최종적으로 갱신된 OFPT_HELLO 메시지에 부가된 경로 정보에 따라 상기 OFC와 상기 제1 OFS 간의 루팅 경로를 결정하고, 상기 루팅 경로에 따라 정확한 흐름 엔트리를 제1 OFS에 전달할 수 있도록 상기 갱신된 OFPT_HELLO 메시지를 상기 OFC에 포워딩하는 단계

를 포함한다.

제7 관점의 제1 실시 방식을 참조해서, 제8 관점의 제2 실시 방식에서, 상기 경로 정보는 상기 OFPT_HELLO 메시지를 송신 또는 수신하는 OFS의 ID, 상기 OFPT_HELLO 메시지를 수신하는 데 사용되는 포트 번호, 및 상기 OFPT_HELLO 메시지를 송신하는 데 사용되는 포트 번호를 포함한다.

제8 관점의 제1 내지 제2 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제8 관점의 제3 실시 방식에서, 상기 갱신된 OFPT_HELLO 메시지를 상기 OFC에 포워딩하는 단계는:

상기 갱신된 OFPT_HELLO 메시지를 상기 OFC에 직접적으로 포워딩하는 단계 - 상기 최종적으로 갱신된 OFPT_HELLO 메시지는 상기 갱신된 OFPT_HELLO 메시지임 - , 또는

하나 이상의 다른 OFS를 사용함으로써 상기 갱신된 OFPT_HELLO 메시지를 상기 OFC에 간접적으로 송신하는 단계

를 포함하며,

여기서 상기 다른 OFS들은 상기 수신된 갱신된 OFPT_HELLO 메시지에 경로 정보를 부가하여 상기 최종적으로 갱신된 OFPT_HELLO 메시지를 획득한다.

제9 관점의 제1 실시 방식에서, 본 발명의 실시예는 개방흐름 교환기(OpenFlow Switch, OFS)를 개시하며, 상기 OFS는 제2 OFS이고, 상기 제2 OFS는 제1 OFS, 흐름개방 제어기(OpenFlow Controller, OFC) 및 적어도 하나의 다른 OFS에 접속되어 OpenFlow 네트워크를 형성하며, 상기 OFC는 대역내 통신 방식으로 각각의 OFS와 통신하며, 상기 제2 OFS는:

상기 제1 OFS에 의해 송신되고, 경로 정보를 수집하는 데 사용되며, 상기 OpenFlow 프로토콜에 정의되는 OFPT_HELLO 메시지를 수신하도록 구성되어 있는 수신 유닛 - 상기 OFPT_HELLO 메시지의 본문 필드는 확장된 후 상기 경로 정보를 반송하는 데 사용되고, 상기 OFPT_HELLO 메시지는 제1 OFS의 경로 정보를 반송하며, 상기 OFPT_HELLO 메시지는 제1 OFS와 OFC 간에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷으로 반송됨 - ;

상기 제2 OFS의 경로 정보를 상기 수신 유닛에 의해 수신된 OFPT_HELLO 메시지에 부가하여 갱신된 OFPT_HELLO 메시지를 획득하도록 구성되어 있는 경로 정보 부가 유닛; 및

상기 갱신된 OFPT_HELLO 메시지를 포함하는 최종적으로 갱신된 OFPT_HELLO 메시지를 수신한 후, 상기 OFC가 각각의 OFS에 의해 상기 최종적으로 갱신된 OFPT_HELLO 메시지에 부가된 경로 정보에 따라 상기 OFC와 상기 제1 OFS 간의 루팅 경로를 결정하고, 상기 루팅 경로에 따라 정확한 흐름 엔트리를 제1 OFS에 전달할 수 있도록, 상기 경로 정보 부가 유닛이 제2 OFS의 경로 정보를 부가하는 상기 갱신된 OFPT_HELLO 메시지를 상기 OFC에 포워딩하도록 구성되어 있는 포워딩 유닛

을 포함한다.

제9 관점의 제1 실시 방식을 참조해서, 제9 관점의 제2 실시 방식에서, 상기 경로 정보는 상기 OFPT_HELLO 메시지를 송신 또는 수신하는 OFS의 ID, 상기 OFPT_HELLO 메시지를 수신하는 데 사용되는 포트 번호, 및 상기 OFPT_HELLO 메시지를 송신하는 데 사용되는 포트 번호를 포함한다.

제9 관점의 제1 내지 제2 실시 방식 중 어느 하나의 실시 방식을 참조해서, 제9 관점의 제3 실시 방식에서, 상기 포워딩 유닛은 구체적으로:

상기 갱신된 OFPT_HELLO 메시지를 상기 OFC에 직접적으로 포워딩하거나 - 상기 최종적으로 갱신된 OFPT_HELLO 메시지는 상기 갱신된 OFPT_HELLO 메시지임 - , 또는

하나 이상의 다른 OFS를 사용함으로써 상기 갱신된 OFPT_HELLO 메시지를 상기 OFC에 간접적으로 포워딩하도록 구성되어 있으며,

여기서 상기 다른 OFS들은 상기 수신된 갱신된 OFPT_HELLO 메시지에 경로 정보를 부가하여 상기 최종적으로 갱신된 OFPT_HELLO 메시지를 획득한다.

본 발명의 실시예에서의 SDN 교환기가 정확한 흐름 엔트리를 획득하는 방법에서, SDN 제어기는 대역내 방식으로 각각의 SDN 교환기와 통신하고, 먼저 신뢰 가능한 접속이 구축된 다음, 그 구축된 신뢰 가능한 접속에 기초해서 각각의 SDN 교환기의 경로 정보를 반송하는 제어 메시지가 전송되며, 이에 따라 SDN 제어기는 그 수신된 제어 메시지에 반송되는 각각의 SDN 교환기의 경로 정보에 따라 SDN 제어기와 제1 SDN 교환기 간의 루팅 경로를 결정하고, 이 경로에 따라 정확한 흐름 엔트리를 제1 SDN 교환기에 전달할 수 있다. 전술한 방식에서는, 2개의 물리적 네트워크를 유지할 필요가 없으므로 하드웨어 비용 및 유지보수 비용을 절감한다.

본 발명의 실시예의 기술적 솔루션을 더 명확하게 설명하기 위해, 이하에서는 본 발명의 실시예를 설명하는 데 필요한 첨부된 도면에 대해 간략하게 설명한다. 당연히, 이하의 실시예의 첨부된 도면은 본 발명의 일부의 실시예에 지나지 않으며, 당업자라면 창조적 노력 없이 첨부된 도면으로부터 다른 도면을 도출해낼 수 있을 것이다.
도 1은 종래기술의 OpenFlow 네트워크의 아키텍처에 대한 개략도이다.
도 2는 본 발명의 실시예 1에 따라 OFS가 정확한 흐름 엔트리를 획득하는 방법에 대한 흐름도이다.
도 3은 본 발명의 실시예 2에 따라 제2 OFS가 제1 유형의 TCP 핸드셰이크 메시지를 처리하는 것에 대한 개략적인 흐름도이다.
도 4는 본 발명의 실시예 2에 따른 흐름 테이블에 대한 개략도이다.
도 5는 본 발명의 실시예 3에 따라 OFS가 제1 TCP 핸드셰이크의 메시지를 처리하는 것에 대한 개략적인 개괄도이다.
도 6은 본 발명의 실시예 3에 따라 OFS가 제1 TCP 핸드셰이크의 메시지를 처리하는 것에 대한 흐름도이다.
도 7은 본 발명의 실시예 3에 따라 OFS가 제1 TCP 핸드셰이크의 메시지를 반송하는 패킷의 패킷 헤더 내의 수 개의 필드에 대한 개략도이다.
도 8은 본 발명의 실시예 3에 따라 제2 OFS가 제1 TCP 핸드셰이크의 메시지의 패킷을 포워딩하는 것에 대한 개략도이다.
도 9는 본 발명의 실시예 3에 따라 제2 TCP 핸드셰이크의 메시지를 반송하는 패킷의 패킷 헤더 내의 수 개의 필드에 대한 개략도이다.
도 10은 본 발명의 실시예 3에 따라 OFS가 제2 TCP 핸드셰이크의 메시지를 처리하는 것에 대한 개략적인 개괄도이다.
도 11은 본 발명의 실시예 3에 따라 OFS가 제2 TCP 핸드셰이크의 메시지를 처리하는 것에 대한 흐름도이다.
도 12는 본 발명의 실시예 3에 따라 제3 TCP 핸드셰이크의 메시지를 반송하는 패킷의 패킷 헤더 내의 수 개의 필드에 대한 개략도이다.
도 13은 본 발명의 실시예 3에 따라 OFS가 제3 TCP 핸드셰이크의 메시지를 처리하는 것에 대한 개략적인 개괄도이다.
도 14는 본 발명의 실시예 3에 따라 OFS가 제3 TCP 핸드셰이크의 메시지를 처리하는 것에 대한 흐름도이다.
도 15는 본 발명의 실시예 4에 따라 경로 정보를 OPFT_HELLO 메시지의 본문 필드로 확장하는 것에 대한 개략도이다.
도 16은 본 발명의 실시예 4에 따라 OFS가 OPFT_HELLO 메시지를 처리하는 것에 대한 개략도이다.
도 17은 본 발명의 실시예 4에 따라 각각의 OFS에 OPFT_HELLO 메시지를 전송하는 것에 대한 개략도이다.
도 18은 본 발명의 실시예 4에 따라 각각의 OFS에 OPFT_HELLO 메시지를 전송하는 것에 대한 다른 개략도이다.
도 19는 본 발명의 실시예 5에 따라 OFS의 흐름 엔트리에 대한 개략도이다.
도 20은 본 발명의 실시예 5에 따라 OFC가 Hello 메시지를 수신한 후 OFC가 흐름 엔트리를 전달하는 것에 대한 개략도이다.
도 21은 본 발명의 실시예 5에 따라 OFS가 OFC에 의해 전달된 흐름 엔트리를수신한 후 처리하는 것에 대한 개략도이다.
도 22는 본 발명의 실시예 6에 따른 OFS의 하드웨어 구조도이다.
도 23은 본 발명의 실시예 6에 따라 소프트웨어장치를 사용하여 OFS를 실현하는 것에 대한 개략도이다.
도 24는 본 발명의 실시예 7에 따른 SDN 교환기의 개략적인 구조도이다.
도 25는 본 발명의 실시예 7에 따른 SDN 교환기 내의 접속 구축 유닛에 대한 개략적인 구조도이다.
도 26은 본 발명의 실시예 7에 따른 SDN 교환기 내의 경로 부가 유닛에 대한 개략적인 구조도이다.
도 27은 본 발명의 실시예 7에 따른 SDN 교환기 내의 포워딩 유닛에 대한 개략적인 구조도이다.
도 28은 본 발명의 실시예 8에 따른 SDN 제어기에 대한 개략적인 구조도이다.
도 29는 본 발명의 실시예 9에 따른 SDN 시스템에 대한 개략적인 구조도이다.
도 30은 본 발명의 실시예 10에 따라 SDN 교환기가 패킷을 포워딩하는 방법에 대한 개략적인 흐름도이다.
도 31은 본 발명의 실시예 11에 따른 SDN 교환기에 대한 개략적인 구조도이다.
도 32는 본 발명의 실시예 12에 따라 OFS가 경로 정보를 수집하는 방법에 대한 개략적인 흐름도이다.
도 33은 본 발명의 실시예 13에 따라 OFS의 개략적인 구조도이다.

본 발명의 실시예의 목적, 기술적 솔루션, 및 이점을 더 분명하고 잘 이해할 수 있도록 하기 위해, 이하에서는 특정한 실시예 및 관련 도면을 사용하여 본 발명을 상세히 더 설명한다.

실시예 1

본 발명의 실시예 1은 SDN 교환기가 정확한 흐름 엔트리를 획득하는 방법을 제공한다. 본 실시예에서, SDN 네트워크의 아키텍처는 현재 가장 광범위하게 응용되고 있는 OpenFlow 기술에 기초하여 실현될 수 있거나 다른 기술을 사용하여 실현될 수 있으며, 이것은 여기서 제한되지 않는다. 본 실시예에서, OpenFlow 네트워크의 아키텍처와 마찬가지로, SDN 네트워크의 아키텍처도 하나 이상의 SDN 교환기 및 하나 이상의 SDN 제어기를 포함한다. 이러한 SDN 교환기 및 SDN 제어기는 OpenFlow 프로토콜 또는 다른 프로토콜을 사용하여 통신할 수 있다. OpenFlow 프로토콜을 사용하면, SDN 교환기를 OpenFlow 교환기라 할 수 있고 OFS로 약칭하며, SDN 제어기를 OpenFlow 제어기라 할 수 있고 OpenFlow 제어기로 약칭하며, 이것은 다른 프로토콜이 사용될 때에도 마찬가지이다.

본 실시예 및 이하의 실시예에서는, OFS 및 OFC에 의해 형성되는 OpenFlow 네트워크에 기초하여 이러한 솔루션에 대해 상세히 설명하며, 당업자라면 SDN 제어기가 OFC와 같고, SDN 교환기가 OFS와 같다는 것을 생각할 수 있을 것이다. 당연히, 본 발명의 실시예에서, OpenFlow 네트워크에 기초한 관련 솔루션 역시 다른 유사한 프로토콜을 사용하여 실현되는 SDN 네트워크에 적용될 수 있다.

본 실시예에서, SDN 네트워크는 종래의 교환기를 필요로 하지 않으며, 제어 평면 및 데이터 평면 모두는 동일한 물리적 네트워크에 기반을 두며, 예를 들어, SDN 네트워크가 OpenFlow 네트워크에 기초하여 실현될 때, OFS 내의 물리적 포트는 제어 패킷을 송수신하도록 구성되며 또한 패킷을 송수신하도록 구성된다. 본 실시예 및 이하의 실시예에서, "제어 평면"의 개념은 종래기술에서의 "제어 평면"의 개념과 유사하며, 즉 관련 노드(예를 들어 OFC 및 각각의 OFS) 및 이러한 노드 간의 링크는 제어 메시지를 전송하는 데 사용되는 네트워크 평면을 형성하며, OFS는 이러한 노드 간의 제어 메시지의 교환에 의해 OFC에 의해 전달되는 흐름 엔트리를 획득하지만, 종래기술과 비교해서, 이러한 노드 간의 제어 메시지의 교환을 완료하는 데 종래의 교환기를 필요로 하지 않는다. "데이터 평면"의 개념도 마찬가지로 배경에서 언급한 바와 유사하며, 즉 일부의 관련 노드(OFC 및 각각의 OFS) 및 이러한 노드 간의 링크는 데이터 정보를 전송하는 데 사용되는 네트워크 평면을 형성하며, 각각의 OFS가 OFC에 의해 전달된 흐름 엔트리를 수신한 후, OFS는 흐름 엔트리에 따라 수신된 패킷을 포워딩한다. 동일한 물리적 네트워크에 기초하는 이러한 통신 방식을 "대역내 통신(inband communication)"이라 한다.

본 실시예에서 흐름 테이블을 획득하고 전달하는 방법은 제2 SDN 교환기에 적용되며, 이 방법은 제2 SDN 교환기에 의해 수행된다. "제2 SDN 교환기"는 제1 SDN 교환기의 제어 메시지를 SDN 제어기에 포워딩하는 SDN 교환기(즉, 흐름 테이블 획득 요구를 개시하는 SDN 교환기)를 말하며, 여기서 패킷을 포워딩하는 것은 직접 포워딩 및 간접 포워딩을 포함하며, 그러므로 네트워크 내에서 제1 SDN 교환기의 제어 메시지를 포워딩하도록 구성되어 있는 복수의 SDN 교환기가 있을 때, 이러한 SDN 교환기 각각은 "제2 SDN 교환기"로 간주될 수 있다. 본 실시예에서, 제2 SDN 교환기에 기초해서 설명하며, 다른 제2 SDN 교환기의 프로세싱 절차 역시 본 실시예에서 예로 든 제2 SDN 교환기와 유사하며, 이 SDN 교환기에 대해서는 본 실시예에서 더 이상 하나씩 설명하지 않는다. 본 실시예에서, SDN 제어기는 "대역내 통신" 방식으로 각각의 SDN 교환기와 통신한다.

구체적으로, 도 2를 참조하면, 실시예 1에서 SDN 교환기가 흐름 엔트리를 획득하는 방법은 이하를 포함한다:

S101: 제1 SDN 교환기에 의해 송신되고 경로 정보를 수집하는 데 사용되는 제1 제어 메시지를 수신하며, 여기서 상기 제1 메시지는 제1 SDN 교환기의 경로 정보를 반송(搬送)하며, 상기 제1 제어 정보는 제1 SDN 교환기와 SDN 제어기 사이에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷으로 반송된다.

SDN 네트워크가 OpenFlow 네트워크인 예를 사용하면, 하나 이상의 중간 OFS 및 OFC가 신뢰 가능한 접속 구축에 사용되는 메시지를 교환한 후, 제1 OFS에 신뢰 가능한 접속이 구축된다. 본 실시예에서, 각각의 OFS는 하나의 노드(예를 들어, 제1 OFS)로부터 다른 노드(예를 들어, OFC)로 메시지를 전송하기 위한 릴레이 노드로 기능할 수 있다.

본 실시예에서, "신뢰 가능한 접속"은 통신 신뢰도를 보장하기 위해 구축되는 접속을 말하며, 일반적으로, "신뢰 가능한 접속"은 재전송 메커니즘을 가지며, 예를 들어, TCP 접속(TCP 프로토콜을 사용하여 구축되는 접속)은 통상적인 신뢰 가능한 접속으로 간주되며, UDP 접속은 "비신뢰 가능한 접속"으로 간주될 수 있다. 본 실시예에서, TCP 접속 또는 SCTP 접속(SCTP 접속을 사용하는 접속)은 신뢰 가능한 접속으로서 사용될 수 있거나, UDP 또는 SSH와 같은 프로토콜은 이러한 프로토콜에 기초한 실시를 위해 부가되며, 예를 들어, TCP는 SSH와의 결합에 사용되거나, 또는 TCP는 UDP와의 결합에 사용된다.

본 실시예에서, "경로 정보"는 OFS 노드가 네트워크 내의 OFS 노드의 경로를 식별하는 데 사용되는 정보이고, 일반적으로, OFS의 포트 번호가 "경로 정보"로서 사용되며, 네트워크 내의 경로란 패킷이 한 노드(OFS 또는 OFC일 수 있다)의 포트로부터 다른 노드의 포트로 송신되는 통신 링크를 말하며, 본 실시예 및 이하의 실시예에서, 경로는 양방향이고, 전송 동안 패킷이 송신되고 복귀하는 채널은 동일한 경로이며, 예를 들어, OFS1이 패킷을 OFS1의 포트 11로부터 OFS3의 포트 33으로 송신하면, OFS3이 패킷을 OFS1에 송신해야 할 때, OFS3은 또한 포트 33을 사용하여 패킷을 OFS1의 포트 11에 송신한다.

본 실시예에서, OFS의 포트(port)란 프로토콜 포트("소프트웨어 포트"라고도 하며, 예를 들어, HTTP 애플리케이션에 정의된 포트 80을 말한다)가 아닌 물리적 포트를 말한다. OpenFlow 기술 분야 및 인터넷 기술 분야에서, 포트(port)는 물리적 포트 또는 소프트웨어 포트를 말할 수 있으며, 당업자라면 문맥에 따라 포트의 실제 의미를 알 수 있을 것이며, 예를 들어, 도 4를 참조하면, OFS 내의 흐름 엔트리 내의 명령 필드에 나타나는 포트 번호는 물리적 포트 번호이고, IP Port 필드 내의 포트 번호는 프로토콜 포트 번호를 나타낸다. 본 실시예 및 이하의 실시예에서, 당업자가 포트 상에서 사용하는 것과 설명의 편리를 위해, 포트마다, 그 포트가 "물리적 포트" 또는 "프로토콜 포트"를 나타내는지는 일일이 지시하지 않으며, 당업자라면 문맥을 참조하여 "포트"가 어느 유형의 포트인지를 쉽게 알 수 있을 것이다.

본 실시예에서, OpenFlow 프로토콜로 정의된 일부의 제어 메시지(여기서, "제1 제어 정보"로 명명함)는 경로 정보를 수집하도록 확장될 수 있으며, 예를 들어, 제1 제어 정보는 OFPT_HELLO 메시지일 수 있다. 구체적으로, OFPT_HELLO 메시지의 본문 필드는 경로 정보를 반송하는 데 사용되도록 확장될 수 있다. 다른 프로토콜에 기초하여 실행되면, 기존 프로토콜을 확장하는 유사한 방법을 사용할 수도 있고 일부의 새로운 필드가 이러한 확장을 실행하도록 프로토콜로 정의된다.

S102: 제2 SDN 교환기의 경로 정보를 제1 제어 메시지에 부가하여 갱신된 제1 제어 메시지를 획득한다.

단계 S101에서의 경로 정보에 대한 내용과 마찬가지로, SDN 네트워크가 OpenFlow 네트워크인 예를 사용하면, 여기서 경로 정보는 제2 OFS의 ID 및 포트 번호를 포함한다. 이 단계에서, 제1 OFS의 경로 정보가 제1 제어 메시지에 이미 있다는 것에 기초하여, 제1 제어 메시지에 경로 정보를 부가하여 갱신된 제1 제어 메시지를 획득한다. 이 단계가 수행된 후, 제1 제어 메시지에 중간 노드의 경로 정보가 부가되고, 이 경우, 제1 OFS가 어느 포트로부터 제1 제어 메시지를 송신하고 제2 OFS가 어느 포트로부터 제1 제어 메시지를 수신하는지를 알 수 있고, 제1 OFS와 제2 OFS 간의 경로를 알 수 있다.

본 실시예에서, "제1 제어 메시지"는 제1 OFS가 OFC에 송신하는 OpenFlow 프로토콜에서의 제어 메시지이며, 예를 들어, 이하에 설명되는 OPFT_HELLO 메시지이다. 당연히, 다른 프로토콜을 사용하여 SDN 네트워크가 실현될 때, 제1 제어 메시지는 다른 프로토콜에 기초하는 제어 메시지일 수도 있다. 제1 제어 메시지의 정의는 주로 제1 제어 메시지의 헤더 정보에 의해 결정된다. 메시지의 다른 부분의 내용이 변할 때(예를 들어, 메시지가 제2 OFS를 통과할 때 제2 OFS의 경로 정보가 메시지 내의 일부의 필드에 부가될 수 있다), 메시지는 여전히 본 실시예에서의 "제1 제어 메시지"라 할 수 있거나, 더 정확하게는 "갱신된 제1 제어 메시지"라 할 수 있다. "제1 제어 메시지"에 대해 다른 언급이 없다면, 당업자는 문맥을 참조하여 제1 제어 메시지의 의미를 이해할 수 있을 것이다(초기에 제1 OFS에 의해 송신되는 제1 제어 메시지 또는 제1 제어 메시지가 각각의 OFS를 통과한 후 새로운 경로가 부가되는 제1 제어 메시지).

S103: 상기 갱신된 제1 제어 메시지를 포함하는 최종적으로 갱신된 제1 제어 메시지를 수신한 후, SDN 제어기가, 각각의 SDN 교환기에 의해 상기 최종적으로 갱신된 제1 제어 메시지에 부가된 경로 정보에 따라 SDN 제어기와 제1 SDN 교환기 간의 루팅 경로를 결정하고 상기 루팅 경로에 따라 제1 SDN 교환기에 정확한 흐름 엔트리를 전달할 수 있도록, 상기 제2 SDN 교환기의 경로 정보가 부가되는 갱신된 제1 제어 메시지를 SDN 제어기에 포워딩한다.

이 단계에서, 상기 포워딩은 직접 포워딩 및 간접 포워딩으로 분류되고, 이응 상응해서, 최종적으로 갱신된 제1 제어 메시지도 다르다.

SDN 네트워크가 OFS 네트워크인 예를 계속 사용해서, 직접 포워딩이면(즉, 제2 OFS가 OFC에 직접적으로 포워딩하고 어떤 중간의 OFS도 통과하지 않으면), 최종적으로 갱신된 제1 제어 메시지는 갱신된 제1 제어 메시지이며, 간접 포워딩이면(즉, 제2 OFS가 하나 이상의 다른 OFS를 사용하여 OFC에 제1 제어 메시지를 포워딩하면), 이전의 OFS에 의해 송신된 제1 제어 메시지를 수신한 후, 다른 OFS 각각은 각각의 다른 OFS의 경로 정보를 부가하고, 이에 따라 제1 제어 메시지는 지속적으로 갱신되고, 모든 OFS의 경로 정보를 포함하는 제1 제어 메시지는 최종적으로 OFC에 도착한다.

다른 OFS가 경로 정보를 부가하는 방식이 제2 OFS가 경로 정보를 부가하는 방식과 동일하고, 즉 다른 OFS 역시 다른 OFS의 ID 및 포트 번호를 제1 제어 메시지에 부가하여, 최종적으로 갱신된 제1 제어 메시지를 획득한다. 각각의 OFS가 각각의 OFS의 경로 정보를 부가하기 때문에, OFC는 제1 제어 메시지의 경로 정보에 따라, 제1 OFS가 어느 중간 OFS에 접속되고 제1 OFS가 어느 포트를 사용하여 메시지를 송신하는지를 알 수 있으며, 이에 따라 루팅 경로(즉, 제1 OFS에 의해 송신된 제1 제어 메시지가 중간 OFS를 통과하고 최종적으로 OFC에 도착하는 경로)가 획득될 수 있으며, 이 루팅 경로를 통해 제1 OFS에 흐름 엔트리가 전달된다(실제의 상황에서, 흐름 테이블은 루팅 경로에 기초하여 다른 관련 OFS에 전달될 수도 있고, 상세한 설명에 대해서는 이하의 실시예 5를 참조할 수 있다).

흐름 엔트리가 수신한 후, 제1 OFS는 로컬 흐름 테이블에 흐름 엔트리를 부가하고, 이어서 흐름 테이블 내의 각각의 흐름 엔트리에 따라 수신된 패킷을 포워딩할 수 있다. 실제의 응용에서, 각각의 OFS(또는 각각의 SDN 교환기)는 동일하고, 다른 OFS도 또한 본 실시예에서 제1 OFS와 같이 흐름 엔트리를 획득할 수 있으며, 제1 OFS도 또한 본 실시예에서 "제2 OFS" 또는 "다른 OFS"와 같이 다양한 유형의 메시지를 포워딩하도록 중간 OFS로서 기능할 수도 있다.

또한, 이 단계에서 포워딩된 제1 제어 메시지도 대응하는 프로토콜(예를 들어 TCP/IP 프로토콜)에 기초하여 패킷으로 반송되고, 일부의 패킷 캡슐화 절차도 포함될 수 있고, 이것은 모두가 종래기술에 속하며, 이러한 특정한 실행에 대해서는 여기서 상세히 설명하지 않는다.

본 실시예에서, 흐름 엔트리는 하나 이상의 종래 교환기를 필요로 함이 없이 전달될 수 있으며, 이에 의해 비용이 절감된다. 또한, 본 실시예에서, 데이터 평면 및 제어 평면이 모두 동일한 물리적 네트워크에 속할 수 있고, 종래기술과 비교해서, 하나의 물리적 네트워크가 감소되며, 이것은 하드웨어 비용을 절감하며, 또한, 본 실시예에서, 2개의 네트워크 관리 시스템이 2개의 물리적 네트워크에 대해 개별적으로 유지될 필요가 없으며, 이 또한 유지보수 비용을 절감한다.

실시예 2

전술한 실시예에 기초하여, SDN 네트워크가 OpenFlow 네트워크인 예를 사용하여, 신뢰 가능한 접속을 구축하는 방법에 대해 본 실시예에서 더 설명한다. 실시예 1에서, 신뢰 가능한 접속을 구축하는 방법이 TCP 또는 SCTP와 같은 프로토콜에 기초하여 구축될 수 있다는 것은 이미 설명되었으며, 본 실시예에서 현재 폭넓게 사용되는 TCP에 기초하여 추가의 설명이 이루어지며, 본 실시예를 사용함으로써, 당업자는 실시를 위해 다른 유사한 프로토콜(예를 들어 SCTP)을 사용할 수 있다는 것을 이해할 수 있을 것이다.

본 실시예에서, TCP 핸드셰이크 메시지의 기본적인 교환 절차는 종래기술에서 3-웨이 핸드셰이크(three-way handshake)가 완료되어야 하고, 즉 원시 노드가 목적지 노드(제1 핸드셰이크)에 SYN 메시지를 송신하는 것과 동일하며, SYN 메시지를 수신한 후, 목적지 노드는 SYN-ACK 메시지(이것은 "SYN+ACK", 즉 제2 핸드셰이크에 의해 표시될 수도 있다)를 원시 노드에 되돌려보내고, 그런 다음 원시 노드는 ACK 메시지를 목적지 노드에 송신하여(제3 핸드셰이크), 3-웨이 TCP 핸드셰이크를 완료한다. 이에 상응해서, SYN 메시지, SYN-ACK 메시지, 및 ACK 메시지를 각각 "제1 핸드셰이크의 메시지", "제2 핸드셰이크의 메시지", 및 "제3 핸드셰이크의 메시지"라 할 수 있으며, 각각의 메시지는 패킷(예를 들어 TCP/IP 패킷)의 형태로 반송되며, 이러한 기술은 당업자에게 잘 알려진 기술이며, 이에 대해서는 여기서 다시 설명하지 않는다.

본 실시예에서의 OpenFlow 네트워크에서, 제1 OFS와 OFC 간에는 하나 이상의 OFS가 있을 수 있으며, 그러므로 대부분의 경우, 제1 OFS는 OFC와 직접적으로 상호작용할 수 없으며, 제2 OFS 및 다른 OFS 중 하나 도는 적어도 하나는 교환된 메시지를 전송하는 릴레이 노드로서 기능해야 한다.

이러한 릴레이 노드가 교환된 메시지를 전송할 수 있도록 하기 위해, 방법은 제1 OFS가 TCP 핸드셰이크 메시지를 제1 OFS에 접속된 모든 OFS에 브로드캐스트하고, 메시지를 수신하는 각각의 OFS 역시 메시지를 다른 OFS에 브로드캐스트하며, 최종적으로 TCP 메시지를 OFC에 전송하며, 또한, TCP 핸드셰이크 메시지를 수신한 후, OFC가 먼저 TCP 핸드셰이크 메시지를 모든 접속된 OFS에 브로드캐스트하고, OFC의 응답 메시지를 수신한 후, 각각의 OFS 역시 메시지를 브로드캐스트하며, 최종적으로 TCP 핸드셰이크 메시지를 제1 OFS에 전송하는 것이며, 이에 따라 3-웨이 TCP 핸드셰이크의 교환이 완료될 수 있다.

브로드캐스팅은 상대적으로 더 많은 네트워크 자원을 점유하며, 이것은 브로드캐스트 스톰을 야기할 수 있으며, 그러므로 네트워크 자원을 더 잘 사용하고 브로드캐스트 스톰의 발생을 줄이기 위해, 본 실시예는 제1 OFS와 OFC 사이의 OFS에 TCP 핸드셰이크 메시지를 포워딩하는 새로운 방법을 제공한다. 제2 OFS가 제1 OFS에 의해 송신된 제1 유형의 TCP 핸드셰이크 메시지(제1 TCP 핸드셰이크의 메시지 및 제3 TCP 핸드셰이크의 메시지)를 수신하고, 다른 OFS를 사용하여 제1 유형의 TCP 핸드셰이크 메시지를 OFC에 포워딩하는 예를 사용하면, 도 3을 참조하여, 방법을 이하를 포함한다:

S21: 제2 OFS는 TCP/IP 패킷을 제1 OFS로부터 수신한다.

직접 수신 또는 간접 수신일 수 있으며(제1 OFS로부터의 제1 TCP/IP 패킷이 복수의 OFS를 통해 수신되며), 본 실시예는 TCP/IP에 기반을 두고 있으므로, 다양한 유형의 메시지가 모두 TCP/IP 패킷에 의해 반송된다.

S22: TCP/IP 패킷 내의 복수 편의 특징 정보를 획득하며, 여기서 특징 정보는 제2 OFS 내의 흐름 테이블의 흐름 엔트리 내의 매치 필드에 대응한다.

OpenFlow 네트워크 내의 OFS 모두는 포워딩에 사용되는 흐름 테이블을 가지며, 흐름 테이블은 하나 이상의 흐름 엔트리(flow entry, 또는 entry로 약칭)를 포함할 수 있으며, 각각의 흐름 엔트리는 하나 이상의 매치 필드(match field, 이하에서는 "필드"로 약칭하기도 함)를 포함하며, 구체적으로 목적지 MAC, 원시 MAC, 원시 IP, 목적지 IP, 및 TCP 포트 번호와 같은 매치 필드를 포함할 수 있으며, 또한, 흐름 엔트리는 흐름 엔트리에 대응하는 명령(instruction)을 더 가질 수 있으며, 예를 들어, 어느 포트를 통한 포워딩을 더 포함할 수 있다. (다양한 유형의 메시지를 반송하는 데 사용되는) 수신된 패킷이 흐름 테이블 정합 정책에 일치할 때, 패킷은 흐름 엔트리 내의 명령에 따라 포워딩된다.

도 4를 참조하면, 도 4는 흐름 테이블의 개략도이다. 흐름 테이블은 정확한 흐름 테이블 및 와일드카드-매치 흐름 엔트리를 포함한다. 각각의 흐름 엔트리는 매치 필드(목적지 MAC 및 목적지 IP) 및 이러한 매치 필드에 대응하는 명령(instruction)을 포함한다. "매치 필드" 및 "명령" 외에, 흐름 엔트리는 또한 다른 항목(예를 들어, 흐름 엔트리가 부딪히는 횟수에 대한 통계를 수집하는 데 사용되는 카운터)를 포함할 수 있고, 매치 필드에 있어서, 도면에 도시된 수 개의 매치 필드 외에, 다른 매치 필드도 포함될 수 있으며, 본 실시예에서, 설명을 쉽게 하기 위해, 모든 다른 정보를 열거하지 않는다.

정확한 흐름 엔트리와 와일드카드-매치 흐름 엔트리와의 차이점은, 정확한 흐름 엔트리에서는, 각각의 매치 필드가 정확한 값을 가지고, 매치 필드와 동등한 값만이 매치 필드와 일치하는 것으로 간주되는 반면, 와일드카드-매치 흐름 엔트리에서는, 일부의 매치 필드의 값이 제한되지 않으며(도 4에서 기호 "*"로 표시되어 있다), 임의의 값이 매치 필드와 일치하는 것으로 간주될 수 있다는 점이다.

도 4에서, 하나의 흐름 테이블은 복수의 흐름 엔트리를 가지며, 다른 실시예에서는, 흐름 테이블이 또한 2개의 흐름 테이블 "정확한 흐름 테이블" 및 "와일드카드-매치 흐름 테이블"로 분할될 수 있으며, 정확한 흐름 테이블은 정확한 흐름 엔트리만을 포함하고, 와일드카드-매치 흐름 테이블은 와일드카드-매치 흐름 엔트리를 포함하거나, 다른 실시예에서는, 다른 논리적 분할 형태가 있을 수도 있으며, 이것은 여기서 제한되지 않는다.

또한, 물리적 저장 평면 상의 "흐름 테이블"의 특정한 실시 방식은 본 실시예에서 제한되지 않으며, 예를 들어, 하나 이상의 흐름 테이블의 내용은 연속적인 물리적 공간에 순서대로 저장될 수도 있고 수 개의 물리적 공간에 저장될 수도 있다. 물리적 공간은 하드웨어 장치(예를 들어 FPGA) 내의 내장형 저장 공간일 수도 있고 범용 메모리 공간일 수도 있으며, 구체적으로, SDRAM, DDR SDRAM, 플래시 등이 물리적 공간의 저장 매체로 사용될 수 있다. 흐름 테이블 정합이 수행되면, 정합은 하드웨어 장치에 기초하여 수행될 수 있거나 정합은 (CPU에 의한 소프트웨어 프로그램을 실행함으로써) 소프트웨어를 사용하여 수행될 수도 있다.

본 솔루션의 다양한 실시예에서, 설명을 쉽게 하기 위해, 다른 언급이 없으면, 흐름 테이블은 정확한 흐름 테이블을 말하는 것이고, 즉 흐름 테이블은 정확한 흐름 테이블만을 포함하는 것이다. 와일드카드-매치 흐름 테이블을 사용하는 방법에 대해서는, 기존의 프로세싱 솔루션을 참조하면 되므로 여기서는 고려하지 않는다. 도 4에 도시된 와일드카드-매치 흐름 테이블은 흐름 테이블을 더 명확하게 설명하여 후술되는 "정확한 흐름 테이블 상에서의 와일드카드-매치 정합의 수행"의 개념을 더 잘 구별하기 위해 사용될 뿐이다.

이 단계에서, 수신된 TCP/IP 패킷은 흐름 엔트리 내의 일부의 매치 필드에 대응하는 복수 편의 특징 정보(예를 들어 목적지 MAC 및 목적지 IP)를 가지며, 이러한 복수 편의 특징 정보는 패킷 내에 (예를 들어, 패킷 헤더 내에) 캡슐화되고, OFS는 패킷을 수신하고 이 패킷을 분석함으로써 복수 편의 특징 정보를 획득할 수 있다.

S23: 복수 편의 특징 정보와 제2 OFS 내의 정확한 흐름 테이블 간의 정확한 정합을 수행하고, 정확한 정합이 실패이고 수신된 TCP/IP 패킷이 제1 유형의 TCP 핸드셰이크 메시지를 반송하는 것으로 판정되면, 복수 편의 특징 정보 중 한 편 이상의 특징 정보와 정확한 흐름 테이블 간의 와일드카드-매치 정합을 수행하며, 와일드카드-매치 정합이 성공하면, 정합에서 성공하는 와일드카드-매치 정합 엔트리 내의 명령에 따라, 제1 유형의 TCP 핸드셰이크 메시지를 반송하는 상기 수신된 제1 TCP/IP 패킷을 처리하여, 제1 TCP/IP 패킷을 OFC에 직접적으로 또는 간접적으로 포워딩한다.

본 실시예에서, 흐름 테이블 정합(여기서, 다시 강조하지만, 다른 언급이 없으면, 흐름 테이블은 정확한 흐름 테이블을 말한다)은 2가지 경우를 포함한다: 첫 번째 경우는 종래기술에서 사용되는 정확한 정합(exact-match)이며, 즉 정합은 정합이 수행되어야 하는 콘텐츠와 정합 흐름 엔트리 내의 각각의 매치 간에 수행되고, 각각의 매치 필드가 콘텐츠와 일치할 때만 정합이 성공한 것으로 간주하며, 다른 경우는 와일드카드-매치 정합(wildcard-match)이고, 정합이 수행되어야 하는 콘텐츠가 정합 흐름 테이블 내의 하나 이상의 매치 필드와 일치하면 와일드카드-매치 정합이 성공한 것으로 간주하고, 정확한 정합처럼 각각의 매치 필드가 콘텐츠와 일치할 필요가 없다. 여기서, "와일드카드-매치 정합"은 도 4에서의 와일드카드-매치 흐름 엔트리에 기초하여 와일드카드-매치 정합을 수행하는 것을 말하는 것이 아니라, 정확한 흐름 엔트리에 기초하여 와일드카드-매치 정합을 수행하는 것을 말하는 것이라는 점을 강조하는 바이다.

속도 및 융통성을 제고하기 위해, 본 실시예에서, 정확한 정합은 하드웨어를 사용하여 실행될 수 있으며, 와일드카드-매치 정합이 소프트웨어를 사용하여 실행될 수 있다. 소프트웨어와 하드웨어를 결합하는 시스템에서, 소프트웨어와 하드웨어의 흐름 테이블 정합을 실행하기 위해, CPU는 인터페이스를 사용해서 하드웨어 장치와 상호작용하여 흐름 테이블을 공유할 수 있다. 흐름 테이블을 공유하는 데는 여러 방식이 있을 수 있으며, 예를 들어, 소프트웨어가 정합을 필요로 할 때, 소프트웨어는 인터페이스를 사용하여 하드웨어 메모리로부터 카피를 획득하거나, 하드웨어가 흐름 테이블을 갱신할 때, 하드웨어는 인터페이스를 사용하여 소프트웨어에 카피를 송신하며, 소프트웨어와 하드웨어의 흐름 테이블 정합이 공유를 통해 완료될 수 있는 한, 흐름 테이블을 공유하는 특정한 방식 또는 이러한 방식과 유사한 등가의 방식(예를 들어, 정책을 사용하여 일부의 특정한 흐름 엔트리만을 카피하기)은 본 실시예에서 제한되지 않는다.

이 단계에서, 흐름 테이블에 대해 정확한 정합이 먼저 수행되고, 정확하게 일치하는 흐름 테이블이 없으면(즉, 흐름 테이블 내의 각각의 매치 필드와 일치할 수 있는 흐름 엔트리가 없으면), 흐름 테이블에 대해 "와일드카드-매치 정합"이 수행되고, 즉 복수 편의 특징 정보 중 한 편 이상의 특징 정보가 흐름 테이블 내의 흐름 엔트리 내의 하나 이상의(전부가 요구되는 것은 아님) 매치 필드와 일치하는지가 판정되고, 예이면, TCP 핸드셰이크 메시지는 매칭에서 성공하는 흐름 엔트리 내의 명령에 따라 처리되어, 핸드셰이크 요구 메시지를 OFS에 직접적으로 또는 간접적으로 포워딩한다. 예를 들어, 제2 OFS가 제1 OFS에 의해 송신된 제1 핸드셰이크(SYN 메시지)의 메시지를 수신한 후, 흐름 엔트리가 와일드카드-매치 정합에서 성공하면, 정합에서 성공하는 흐름 엔트리 내의 명령에 따라 프로세싱이 수행되며, 예를 들어, 특정한 포트로부터 포워딩되면서, 다른 OFS에 포워딩되고, 다른 OFS를 사용하여 OFC에 포워딩된다. 제2 OFS에 의해 포워딩된 패킷을 수신한 후, 다른 OFS는 제2 OFS처럼 프로세싱을 수행할 수 있거나, 브로드캐스팅을 통해 또는 다른 형태를 사용해서 프로세싱을 계속해서 수행할 수 있다.

설명을 쉽게 하기 위해, 여기서, 정확한 흐름 엔트리에서 "와일드카드-매치 정합"에 사용되는 매치 필드는 "와일드카드-매치 매치 필드"이고, "와일드카드-매치 매치 필드"를 가지는 정확한 흐름 엔트리를 "와일드카드-매치 정합 엔트리"라 하며, 이러한 "와일드카드-매치 매치 필드" 모두 매칭에서 성공할 때, 패킷은 와일드카드-매치 매치 필드에 대응하는 명령을 사용하여 제2 엔드에 포워딩될 수 있다. 이 단계에서, 흐름 테이블 상의 "와일드카드-매치 정합"을 수행하는 목적은 핸드셰이크 요구 메시지를 제2 엔드에 직접적으로 또는 간접적으로 포워딩하는 것이다. 하나 이상의 매치 필드가 구체적으로 "와일드카드-매치 매치 필드"로서 선택될 때, 이러한 수 개의 매치 필드에 대응하는 명령을 사용하여 결정되는 포워딩 루트가 제2 엔드에 최종적으로 도달할 수 있는 루트이기만 하면, 메시지는 하나 이상의 매치 필드에 대응하는 명령(명령의 콘텐츠는 일반적으로 어느 포트로부터 포워딩된다)을 사용하여 제2 엔드에 최종적으로 포워딩될 수 있으며, 이에 의해 와일드카드-매치 정합 동안 사용되는 매치 필드로서 사용된다. 일반적인 와일드카드-매치 매치 필드는 목적지 MAC, 목적지 IP, 및 목적지 포트(프로토콜 포트)일 수 있으며, 일반적으로, 제2 엔드의 특정한 애플리케이션은 이러한 수 개의 매치 필드를 사용하여 결정될 수 있으며, 그러므로 메시지를 제2 엔드에 포워딩하도록 이러한 수 개의 필드에 대해 매칭이 수행될 수 있다. 당연히, 실제의 애플리케이션에서, 2편의 정보(예를 들어 목적지 IP 및 목적지 포트) 또는 심지어 한 편의 정보가 제2 엔드의 애플리케이션을 결정할 수 있으면, 2편 또는 한편의 정보에 대해 매칭이 수행될 수 있으며, 최종적으로, 패킷은 매치 필드에 대응하는 명령을 사용하여 제2 엔드에 송신된다. 정확도를 높이기 위해, 매칭이 수행되어야 하는 다른 필드를 부가하는 것은 본 실시예에서 제한되지 않는다.

와일드카드-매치 매칭에 사용되는 전술한 흐름 엔트리는 제2 OFS(또는 각각의 다른 중간 OFS)가 이전에 획득된 OFC와 통신할 때 OFC에 의해 전달될 수 있고, 와일드카드-매치 매칭이 수행될 때 여전히 유효하다. 이러한 흐름 엔트리는 본래 일부의 다른 정보를 포워딩하는 데 사용되지만, 이러한 흐름 엔트리는 2 노드 간의 포워딩 경로를 포함할 수 있으며, 본 실시예는 이러한 흐름 엔트리에 존재하는 경로를 사용하여 와일드카드-매치 매칭을 통해 더 정확한 포워딩을 실행한다. 당연히, 이러한 흐름 엔트리가 이전에 저장되지 않았거나, 저장되었으나 흐름 엔트리가 무효이고 와일드카드-매치 매칭 동안 존재하지 않으면, "와일드카드-매치 매칭"이 성공할 수 없으며, 이 경우, 패킷은 브로드캐스팅을 통해 포워딩될 수 있다.

본 실시예에서, 특징 정보는 목적지 MAC, 목적지 IP, 및 목적지 포트 번호를 포함할 수 있으며, 흐름 테이블 내의 흐름 엔트리 내의 매치 필드는 목적지 MAC, 목적지 IP, 및 목적지 포트 번호를 포함할 수 있으며, 이에 따라, 단계 323에서, "복수 편의 특징 정보 중 한 편 이상의 특징 정보가 흐름 테이블 내의 흐름 엔트리 내의 하나 이상의 매치 필드와 일치하는지를 판정하는 단계"는 구체적으로 복수 편의 특징 정보의 목적지 MAC, 목적지 IP, 및 목적지 포트 번호가 흐름 테이블 내의 흐름 엔트리의 목적지 MAC, 목적지 IP, 및 목적지 포트 번호와 일치하는지를 판정하는 단계를 포함할 수 있다. 매칭에 사용되는 전술한 수 편의 특징 정보는 상대적으로 공통 특징 정보이며, 한 편 이상의 특징 정보를 부가하거나 감하는 것은 본 실시예에서 제한되지 않는다.

본 실시예에서 정확한 흐름 엔트리에 대해 와일드카드-매치 매칭을 수행함으로써 포워딩이 수행되고, 이에 따라 제1 유형의 핸드셰이크 메시지 역시 브로드캐스팅의 필요 없이 포워딩될 수 있으며, 이에 의해 브로드캐스팅 횟수가 감소하고, 이것은 자원을 더 감소시킬 수 있고 브로드캐스트 스톰을 억제할 수 있다.

실시예 3

전술한 실시예에 기초하여, 실시예 2에서의 3-웨이 TCP 핸드셰이크 메시지의 교환에 대해 본 실시예에서 상세히 설명한다.

도 5를 참조하면, 이 도면은 본 실시예에서 OpenFlow 네트워크의 개략도이며, 복수의 OFS: OFS1 내지 OFS6, 및 하나의 OFC를 포함한다. 여기서, OFS1은 제1 OFS이고, OFS3은 제2 OFS이고 OFS1에 직접적으로 접속되고(당연히, 실제로, 복수의 중간 OFS가 더 포함될 수 있다), 나머지 OFS2 및 OFS4 내지 OFS6은 전술한 실시예에서 "다른 OFS"로 간주될 수 있다.

1. 1 핸드셰이크

전술한 실시예에 기초하여, 도 5는 제1 TCP 핸드셰이크의 교환의 절차를 간략하게 도시하며, 즉 제1 OFS는 먼저 제1 TCP 핸드셰이크의 메시지를 브로드캐스트하며, 이것은 TCP_Req로 표시된다. 메시지는 구체적으로 TCP/IP 패킷이고, 패킷 헤더 내의 SYN은 1에 설정되어 있으며, ACK는 0에 설정되어 있다. 수신 후, 제2 OFS(OFS3)는 와일드카드-매치를 통해 제1 테이블을 검색하고, 정합 흐름 엔트리가 있으면, 명령을 사용하여 포워딩 정책을 수행하며, 예를 들어, 도 5에서 OFS5에 포워딩한다. 마찬가지로, OFS5도 와일드카드-매치를 통해 제1 테이블을 검색하고, 정합 흐름 엔트리가 있으면, 명령을 사용하여 포워딩 정책을 수행할 수 있다. OFS3도 OFS5도 도 5에서 브로드캐스트하지 않기 때문에, 다음의 호프 노드(hop node)로의 포워딩은 특정한 포트를 통해 수행되며, 네트워크 자원은 감소된다.

구체적으로, 도 5에 기초하여, 도 6을 참조하면, 본 실시예에서의 3-웨이 TCP 핸드셰이크에서의 제1 핸드쉐이트는 이하의 방법을 사용하여 완료될 수 있다:

S31: 제1 OFS는 전원이 켜진 다음 파라미터를 구성한다.

여기서, 제1 OFS는 도 5에서의 OFS1인 것으로 가정하고, 네트워크 케이블이 OFS1에 삽입되고 OFS1에 전원이 들어온 후, OFS1은 OFS1의 IP 어드레스를 포함한 일부의 파라미터를 구성하고(예를 들어, 커맨드 라인을 사용하여 구성하고), 관련 OFC의 IP 어드레스, 포트 번호, 및 접속 방식(TCP, SSL 등)을 구성하며, 특정한 구성 방식은 종래기술이므로, 여기서는 상세히 설명하지 않는다.

S32: 제1 OFS는 TCP 접속을 구축하는 데 사용되는 제1 TCP 핸드셰이크(TCP_Req)의 메시지를 생성하고, 제1 OFS의 포트(물리적 포트)를 사용하여 제1 TCP 핸드셰이크의 메시지를 외부로 브로드캐스트한다. TCP_Req는 구체적으로 TCP/IP 패킷이고, 도 7을 참조하면, 이 도면은 패킷에 포함된 수 개의 필드를 도시하며, 이러한 필드는 다음과 같이 설정된다:

src_mac: 제1 OFS의 MAC 어드레스; scr는 source의 약자이고, "원시"를 나타내고, 명세서의 다른 곳에서의 src의 의미는 다른 언급이 없으면 동일한 의미이며;

src_ip: 제1 OFS의 IP 어드레스;

dst_ip: S31에서 명시된 OFC의 IP 어드레스; dst는 destination의 약자이고, "목적"을 나타내고, 명세서의 다른 곳에서의 src의 의미는 다른 언급이 없으면 동일한 의미이며;

src_port: 고정 포트 번호에 설정될 수 있으며(프로토콜 포트 번호, 이것은 TCP 프로토콜이 여기서 사용되기 때문에 TCP 포트 번호이고, 달리 언급이 없으면 이하의 프로토콜 포트 번호도 또한 TCP 포트 번호라 하며), 예를 들어 "36653"이며;

dst_port: S31에서 명시된 OFC의 포트 번호(프로토콜 포트 번호), 예를 들어, "6633";

dst_mac: 의사 MAC 어드레스, FF-FF-FF-FF-FF-FF, 어드레스는, 다른 OFS가, 수신 후, 특별한 목적에 사용되는 값을 알 수 있게 하고 패킷을 폐기하지 않게 하는 데 사용되는 다른 약정 값일 수도 있으며, 모든 F에 대해, 기존의 네트워크에서는 디폴트에 의해 브로드캐스트되므로, 상기 값은 기존의 네트워크를 겸용하도록 설정되며;

SYN 비트는 1에 설정되고, ASK 비트는 0에 설정되며; 그리고

초기 TTL 값은 예를 들어 30에 설정되고, TTL 값은 네트워크에서 패킷의 생존시간을 정의하는 데 사용된다.

S33: 제2 OFS는 와일드카드-매치를 통해 흐름 테이블을 검색하여 제1 OFS에 의해 송신된 제1 TCP 핸드셰이크의 메시지의 패킷을 포워딩한다. 제1 TCP 핸드셰이크의 메시지를 수신한 후, 각각의 다른 OFS도 역시 제2 OFS처럼 유사한 프로세싱을 수행하고, 제1 TCP 핸드셰이크의 메시지를 OFC에 최종적으로 포워딩한다.

도 8을 참조하면, S33은 구체적으로 이하를 포함한다:

S331: 패킷의 헤더(header)를 분석한다.

헤더를 분석한 후, TTL, 원시/목적지 MAC, 원시/목적지 IP, 및 원시/목적지 포트와 같이, 후속 단계의 판정에 사용되는 복수 편의 정보가 획득될 수 있으며, 이어서, 각각의 OFS가 제2/제3 핸드셰이크의 메시지를 처리할 때, 각각의 OFS 역시 분석을 통해 이러한 복수 편의 정보를 획득하고, 분석을 통해 획득된 정보에 따라 판정을 수행한다.

S332: TTL이 0보다 큰지를 판정하고, 예이면 S333을 수행하고, 그렇지 않으면 패킷을 폐기한다.

S333: 흐름 테이블에 대한 정확한 정합을 수행하고, 정합된 엔트리가 있으면, 정합된 엔트리 내의 "명령" 필드의 값에 따라 포워딩을 수행하는 S334를 수행하며, 정합된 엔트리가 없으면, S335를 수행한다.

프로세싱 효율성을 높이고 융통성을 제고하기 위해, 전술한 단계 S331 내지 S334를 하드웨어(예를 들어 ASIC 또는 FPGA)를 사용하여 실행하여 프로세싱 속도를 높일 수 있으며, 후속의 단계는 소프트웨어를 사용하여 실행될 수 있으며(CPU는 소프트웨어 코드르 실행한다), 이것이 더 융통적이다.

S335: 목적지 IP 어드레스가 자신과 관련된 OFC의 IP 어드레스인지를 판정하고, 예이면, 단계 S336을 수행하고, 그렇지 않으면, 패킷을 폐기한다.

S336: 목적지 포트 번호가 자신과 관련된 OFC의 포트 번호인지를 판정하고, 예이면, 단계 S337을 수행하고, 그렇지 않으면, 패킷을 폐기한다.

S337: "ACK!=1 & SYN=1"(ACK 비트는 1과 같지 않고 SYN 비트는 1과 같다)인지를 판정하고, 예이면, S338을 수행하고, 그렇지 않으면, 패킷을 폐기한다. 이 단계는 제1 핸드셰이크의 메시지인지를 판정하는 데 사용된다. 본 실시예 및 이하의 실시예에서, OFS는 실제의 애플리케이션에서 많은 메시지를 수신하고, 다른 메시지에 대해서는 다른 프로세싱 방식을 가지므로, OFS는 메시지가 어떤 유형의 메시지인지를 판정해야 하고, 실제로 코드에 의해 실현될 때, 단계 전후에 다른 메시지인지를 판정하는 데 사용되는 어떤 다른 코드가 있을 수 있다는 것에 유의해야 하며, 본 실시예 및 이하의 실시예에서, 설명을 쉽게 하기 위해, 코드는 도시되어 있지 않으나, 본 실시예에 관련된 코드만은 도시되어 있다.

단계 S335 내지 단계 S337의 기능은 OFS에 의해 처리될 필요가 없는 패킷을 폐기하는 것이다.

S338: 흐름 테이블에 대해 와일드카드-매치 정합을 수행하고, 정합된 엔트리가 있으면, 정합된 엔트리 내의 "명령" 필드의 값에 따라 포워딩을 수행하는 S339를 수행하며, 정합된 엔트리가 없으면, 브로드캐스팅하는 S3310을 수행한다.

S339: 와일드카드-매치 정합에서 성공할 수 있는 정합된 엔트리가 있을 때, 정합된 엔트리 내의 "명령" 필드의 값에 따라 포워딩을 수행한다. 정합된 엔트리가 없으면, 브로드캐스팅이 수행될 수 있다.

전술한 S33은 제2 OFS가 패킷을 처리하고 포워딩하는 절차이며, 브로드캐스팅은 와일드카드-매치를 통해 흐름 테이블을 검색함으로써 감소되며, 이에 의해 네트워크 자원이 감소되고 브로드캐스트 스톰을 억제한다.

다른 OFS 역시 제2 OFS(예를 들어, OFS3)에 의해 사용된 방식과 동일한 방식으로 포워딩을 수행하여, 패킷 내의 제1 핸드셰이크(TCP_Req)의 요구 메시지를 OFC에 최종적으로 전송한다.

예를 들어, OFS3 및 OFS5도 또한 이러한 포워딩 및 프로세싱을 사용할 수 있다. 도 5에서, OFS3 및 OFS5 모두는 흐름 테이블에 대해 와일드카드-매치 정합을 수행할 수 있으며, 이에 따라 2개의 OFS는 브로드캐스팅의 필요 없이 패킷을 OFC에 포워딩할 수 있다. 당연히, 실제로, 흐름 테이블에 대한 정합(흐름 테이블에 대한 정확한 정합 및 와일드카드-매치 정합을 포함함)이 실패하면, 패킷은 브로드캐스팅을 통해 포워딩될 수 있으며, 예를 들어, OFS3은 OFS5 및 OFS2에 브로드캐스팅하고, OFS5는 OFS4, OFS6, 및 OFC에 브로드캐스팅한다.

이어서, 패킷을 수신한 후, OFC는 헤더를 분석하고, 패킷의 목적지 MAC 어드레스는 모두 F이므로, OFC는 패킷을 범용 브로드캐스트 패킷으로서 처리하고, 계층 2 어드레스를 제거하며, 패킷의 계층 3 콘텐츠에 대해 이하의 프로세싱을 수행한다(약정 MAC 어드레스가 사용되면, OFC 역시 목적지 MAC 어드레스가 약정 MAC 어드레스라는 것을 알게 된 후 이하의 프로세싱을 수행한다):

OFC는 패킷의 목적지 IP가 OFC의 IP와 같은지를 판정하고 패킷의 목적지 포트 번호가 OFC가 TCP 접속을 청취하는 포트 번호 및 OFC의 포트 번호와 같은지를 판정하며, 이것들 중 하나가 아니오이면 패킷을 폐기하며, 양자가 예이면, "ACK!=1 & SYN=1"이 충족되는지를 계속해서 판정하고, 예이면, 제1 핸드셰이크가 성공하고, 아니오이면, OFC 역시 패킷을 폐기한다. 전술한 수 개의 판정 순서는 제한되지 않는다.

2. 제2 핸드셰이크

제1 핸드셰이크가 성공한 후, OFC는 수신된 TCP_Req에 따라 제2 핸드셰이크(TCP_Res)의 메시지를 구축하며, 여기서 상기 메시지는 구체적으로 TCP/IP 패킷이다. 도 9를 참조하며, 이 도면은 제2 핸드셰이크의 메시지를 반송하는 패킷의 패킷 헤더 내의 필드와 제1 핸드셰이크의 메시지를 반송하는 패킷의 패킷 헤더 내의 필드 간의 대응관계도를 도시하며, TCP_Res의 패킷 헤더는 다음과 같이 설정된다:

TCPdst_mac: TCP_Req의 패킷 헤더 내의 src_mac와 같은, 제1 OFS의 MAC 어드레스;

src_mac: OFC의 MAC 어드레스;

src_ip: TCP_Req의 패킷 헤더 내의 dst_ip와 같은, OFC의 IP 어드레스;

dst_ip: 제1 OFS의 IP 어드레스;

src_port: OpenFlow 애플리케이션을 청취하는 데 사용되고, TCP_Req의 패킷 헤더 내의 dst_port와 같은, OFC의 TCP 포트 번호;

dst_port: OpenFlow 애플리케이션을 청취하는 데 사용되고, TCP_Req의 패킷 헤더 내의 src_port와 같은, OFS의 TCP 포트 번호;

OFS의 TCP 포트 번호이고, OpenFlow 애플리케이션을 청취하는 데 사용되고, TCP_Req의 패킷 헤더 내의 src_port와 같으며;

ACK 및 SYN 모두는 "1"에 설정되며, 그리고

초기의 TTL 값이 설정된다.

제2 핸드셰이크의 메시지를 구성한 후, OFC는 OFS에 제2 핸드셰이크의 메시지를 송신하고 제2 핸드셰이크의 메시지를 OFC에 접속된 하나 이상의 OFS에 송신할 수 있다. 바람직하게, OFC는 제1 핸드셰이크의 메시지를 수신하는 OFS에 제2 핸드셰이크의 메시지를 송신하거나, 극단적인 경우, OFC는 제2 핸드셰이크의 메시지를 브로드캐스트할 수 있다.

제2 핸드셰이크의 메시지를 수신한 후, 각각의 OFS는 먼저 흐름 테이블에 대해 정확한 정합을 수행하고, 정합이 성공하면, 특정한 포트를 사용하여 제2 핸드셰이크의 메시지를 포워딩하고, 정합이 실패하면, 제2 핸드셰이크의 메시지를 브로드캐스트한다. 제2 핸드셰이크의 메시지를 포워딩할 때, OFS는 와일드카드-매치 정합 방식으로 흐름 테이블에 대해 정합을 수행하지 않는다. 이것은 실제의 시나리오에서 제1 OFS가 일반적으로 새로운 OFS이고, 제1 OFS에 포워딩되는 흐름 엔트리가 다른 OFS에 존재하지 않으며, 그러므로 제2 핸드셰이크의 메시지가 흐름 테이블에 대해 와일드카드-매치 정합을 수행하는 방식으로 정확하게 포워딩할 수 없기 때문이다. 당연히, 제1 OFS에 포워딩되는 흐름 엔트리가 일부의 흐름 엔트리에 실제로 존재하는 시나리오에서, 정확한 포워딩은 브로드캐스팅을 통해 포워딩을 수행하는 대신 흐름 테이블에 대해 와일드카드-매치 정합을 수행하는 방식으로 포트로부터 실행될 수 있다.

또한, 제2 핸드셰이크의 메시지를 수행할 때, OFC로부터의 제2 핸드셰이크의 메시지가 OFS에 송신되는 것으로 OFS가 판정하면, OFS는 현지에 저장되어 있는 OFC의 IP와 MAC 간의 맵핑 관계를 갱신하고, 원래의 의사 MAC(모든 F)를 OFC의 실제의 MAC 어드레스로 대체하여, OFC에 송신될 패킷이 뒤이어서 구성될 때 사용되도록 한다.

도 10을 참조하면, 이 도면은 각각의 OFS가 제2 핸드셰이크의 메시지를 프로세싱하는 개략도이며, 구체적으로, 도 11을 참조하면, 각각의 OFS는 이하의 방법을 사용하여 제2 핸드셰이크의 메시지를 포워딩할 수 있으며, 이하를 포함한다:

S51: 헤더를 분석한다.

헤더가 분석된 후, TTL, 원시/목적지 MAC, 및 원시/목적지 IP와 같은 복수 편의 정보가 획득된다.

S52: TTL이 0보다 큰지를 판정하고, 예이면 S53을 수행하고, 그렇지 않으면 패킷을 폐기한다.

S53: 흐름 테이블에 대해 정확한 정합을 수행하고, 정합이 성공하면, "명령" 필드 내의 값에 따라 패킷을 포워딩하며(예를 들어, 패킷을 특정한 포트에 포워딩하고), 정합이 실패하면 S54를 수행한다.

프로세싱 효율성을 높이고 융통성을 제고하기 위해, 전술한 수 개의 단계는 하드웨어를 사용하여 실행될 수 있으며, 후속의 단계는 소프트웨어를 사용하여 실행될 수 있다.

S54: 목적지 MAC가 OFS의 MAC 어드레스인지를 판정하고, 예이면 단계 S55를 수행하고, 그렇지 않으면 단계 S59를 수행한다. 목적지 MAC 어드레스가 OFS의 MAC 어드레스인 것으로 판정되면, 이것은 패킷이 OFS에 송신된다는 것을 나타내고, 이 경우, 단계 S55 내지 단계 S58가 수행되며, 그렇지 않으면, 패킷이 다른 OFS에 송신된다는 것을 나타내고, OFS는 포워딩을 수행하는 중간 OFS이며, 이 경우, 단계 S59 내지 단계 S512가 수행된다. 패킷이 OFS에 송신되는지는 목적지 IP를 사용하여 판정될 수 있지만, 실제로, MAC는 계층 2 프로토콜이고 IP 앞의 패킷 헤더로부터 분석을 통해 획득되기 때문에, 따라서 MAC를 사용하여 분석하는 것은 프로세싱 속도를 높일 수 있다.

S55: 원시 IP 어드레스가 자신과 관련된 OFC의 IP 어드레스인지를 판정하고, 예이면 단계 S56을 수행하고, 그렇지 않으면 패킷을 폐기한다.

S56: 원시 포트 번호가 자신과 관련된 OFC의 포트 번호인지를 판정하고, 예이면 단계 S57을 수행하고, 그렇지 않으면 패킷을 폐기한다.

S57: "ACK=1 & SYN=1"(ACK 비트 및 SYN 모두가 1이다)이 충족되는지를 판정하고, 예이면 S58을 수행하고, 그렇지 않으면 패깃을 폐기한다.

S58: OFS는 OFC의 IP와 IP 어드레스 간의 맵핑 관계를 갱신하고, 즉 OFC의 IP 어드레스에 대응하는 실제의 MAC 어드레스를 기록하며(제1 OFS에 의해 송신된 의사 MAC는 제1 핸드셰이크 동안 수신되고, 여기서 갱신되어야 한다), 이에 따라 OFC에 송신되어야 하는 패킷이 이어서 구성될 때, 패킷 헤더 내에서 송신되어야 하는 OFC의 MAC 어드레스는 갱신된 값에 따라 설정될 수 있다. 이 점에서, 제2 TCP 핸드셰이크가 완료된다.

S59: 원시 IP 어드레스가 자신과 관련된 OFC의 IP 어드레스인지를 판정하고, 예이면 단계 S510을 수행하고, 그렇지 않으면 패킷을 폐기한다.

S510: 원시 포트 번호가 자신과 관련된 OFC의 포트 번호인지를 판정하고, 예이면 단계 S511을 수행하고, 그렇지 않으면 패킷을 폐기한다.

S511: "ACK=1 & SYN=1"이 충족되는지를 판정하고, 예이면 단계 S512를 수행하고, 그렇지 않으면 패킷을 폐기한다.

S512: 패킷을 브로드캐스트한다.

전술한 단계를 사용함으로써, 제2 핸드셰이크의 메시지를 반송하는 패킷은 제1 OFS(OFS1)에 최종적으로 전송되어 제2 핸드셰이크를 완료할 수 있다.

3. 제3 핸드셰이크

OFC에 의해 송신된 TCP_Res를 수신한 후, 제1 OFS(OFS1)는 제1 핸드셰이크의 메시지(TCP_Req')를 구성하고, 여기서 메시지는 구체적으로 TCP/IP 패킷이다. 도 12를 참조하면, 이 도면은 제3 핸드셰이크의 메시지의 패킷 헤더 내의 필드와 제1 및 제2 핸드셰이크의 메시지의 패킷 헤더 내의 필드 간의 대응관계의 테이블이며, 패킷 헤더 내의 필드는 다음과 같이 설정된다:

dst_mac: OFC의 MAC 어드레스;

src_mac: 제1 OFS의 MAC 어드레스;

src_ip: 제1 OFS의 IP 어드레스;

dst_ip: OFS의 IP 어드레스;

src_port: TCP 접속을 청취하는 데 사용되는, 제1 OFS의 포트 번호;

dst_port: TCP 접속을 청취하는 데 사용되는, OFC의 포트 번호;

ACK는 "1"에 설정되고, SYN은 "0"에 설정되며; 그리고

초기의 TTL 값이 설정된다.

제1 OFS는 구성된 패킷을 브로드캐스트한다. 도 13을 참조하면, 이 도면은 제1 OFS로부터 OFC에 제3 핸드셰이크의 메시지를 송신하는 개략도이다. OFS1은 흐름 테이블을 가지지 않기 때문에, OFS1은 패킷을 브로드캐스트할 필요가 없으며, 패킷을 수신한 후, 각각의 중간 OFS는 흐름 테이블에 대해 와일드카드-매치 정합을 수행하는 방식으로 특정한 포트로부터 패킷을 포워딩할 수 있거나 브로드캐스팅을 통해 패킷을 포워딩할 수 있으며, 각각의 OFS는 다음의 방식에 따라 프로세싱을 수행할 수 있다:

S71: 헤더를 분석한다.

TTL, 포트 번호, 및 IP 어드레스와 같은 정보가 획득된다.

S72: TTL이 0보다 큰지를 판정하고, 예이면 S73을 수행하고, 그렇지 않으면 패킷을 폐기한다.

S73: 흐름 테이블에 대한 정확한 정합을 수행하고, 정합된 엔트리가 있으면, 정합된 엔트리 내의 "명령" 필드의 값에 따라 포워딩을 수행하며, 정합된 엔트리가 없으면, S74를 수행한다.

전술한 3개의 단계는 하드웨어를 사용하여 처리되어 프로세싱 속도를 증가시킬 수 있으며, 후속의 단계는 하드웨어를 사용하여 처리되어 프로세싱 융통성을 향상시킬 수 있다.

S74: 목적지 IP 어드레스가 자신과 관련된 OFC의 IP 어드레스인지를 판정하고, 예이면, 단계 S75를 수행하고, 그렇지 않으면, 패킷을 폐기한다.

S75: 목적지 포트 번호가 자신과 관련된 OFC의 포트 번호인지를 판정하고, 예이면, 단계 S76을 수행하고, 그렇지 않으면, 패킷을 폐기한다.

S76: "ACK=1 & SYN!=1"(ACK 비트는 1이고 SYN 비트는 1이 아니다)인지를 판정하고, 예이면, S77을 수행하고, 그렇지 않으면, 패킷을 폐기한다.

S77: 흐름 테이블에 대해 와일드카드-매치 정합을 수행하고, 정합이 성공하면, 정합에서 성공하는 정합된 엔트리 내의 "명령" 필드의 값에 따라 패킷을 포워딩하며, 정합이 실패하면, 패키승ㄹ 브로드캐스트한다.

S77에서 흐름 테이블에 대해 와일드카드-매치 정합을 수행하는 방식은 자원을 감소시키고 브로드캐스트 스톰을 방지한다.

각각의 OFS가 흐름 테이블에 대해 와일드카드-매치 정합을 수행하는 방식으로 패킷을 포워딩하는 방법은 TCP 접속을 구축하는 특정한 애플리케이션 시나리오에 반드시 제한되지 않는다는 것에 유의해야 하며, 본 실시예에서 "흐름 테이블에 대해 와일드카드-매치 정합"을 수행하는 방식은 OFC와의 교환 및 포워딩을 수행하는 데 복수의 OFS가 요구되는 시나리오가 포함되기만 하면 사용될 수 있다.

실시예 4

전술한 실시예에 기초하여, 각각의 OFS가 제어 메시지에 경로 정보를 부가하는 방법에 대해 구체적으로 본 실시예에서 설명한다.

본 실시예에서, 제어 메시지는 일부의 프로토콜에서의 사용자-정의 제어 메시지를 사용할 수 있거나, 기존의 자원을 더 잘 사용하거나 더 쉽게 실행할 수 있도록 하기 위해, 일부의 기존의 프로토콜에서의 제어 메시지가 확장될 수 있으며, 이에 따라 제어 메시지는 경로 정보를 반송할 수 있다. 본 실시예에서, OpenFlow 프로토콜에서의 OFPT_HELLO 메시지의 본문 필드가 확장되고, 이에 따라 본문 필드는 경로 정보를 반송할 수 있다.

OpenFlow 프로토콜은 TCP/IP 계층에 관한 프로토콜이고, TCP/IP를 사용할 때 반송된다. OpenFlow 프로토콜에서의 OFPT_HELLO 메시지는 버전 정보를 협상하는 데 사용되고, 그 본문 필드는 현재 보존되고 사용되지 않으며, 그러므로 메시지는 본문 필드에 기초하여 확장될 수 있다.

경로 정보는 네트워크에 경로를 형성하기 위한 각각의 노드에 의해 요구되는 정보를 식별하는 데 사용되고, 네트워크 내의 경로(또는, "루팅 경로"라고도 한다)는 패킷이 원시 노드로부터 다른 하나 이상의 노드를 통과하고 목적지 노드에 도착하는 경로를 말한다(당연히, 패킷은 중간 노드를 거치지 않고 목적지 노드에 직접적으로 도착할 수도 있다). 네트워크에서, 패킷이 그 노드의 어느 포트로부터 입력되고 어느 포트로부터 출력되는 것이 공개되면, 경로 중 전체 경로의 완전한 형성을 위해 노드에 의해 제공되는 경로의 세그먼트가 공개될 수 있으며, 각각의 노드가 이러한 경로 정보를 가지면, 원시 노드로부터 목적지 노드까지의 전체 경로가 결정될 수 있다.

경로 정보는 구체적으로: OFS의 ID, 제어 메시지를 수신하기 위해 OFS에 의해 사용되는 포트 번호(물리적 포트 번호), 및 제어 메시지를 송신하기 위해 OFS에 의해 사용되는 포트 번호(물리적 포트 번호)를 포함할 수 있다. OFS의 ID는 OFS를 식별하는 데 사용되고, OFC가 OFS를 식별할 수 있게 해주며, 예를 들어, 사용자-정의 고윳값이 ID로서 사용될 수 있거나, 기존의 프로토콜로 정의된 일부의 필드가 OFS의 ID로서 사용될 수 있으며, 예를 들어, OpenFlow 프로토콜에서 흔히 사용되는 datapath ID가 OFS의 ID로서 사용된다. 때때로, 각각의 물리적 OFS에 대해서, 하나의 물리적 OFS를 수 개의 논리적 OFS로 분할하기 위해 일부의 가상화된 동작이 수행될 수 있다는 것에 유의해야 하며, 이 경우, OFS의 ID는 수 개의 논리적 OFS의 ID로 간주될 수 있으며, 수 개의 논리적 OFS가 각각의 메시지에 대해 프로세싱하는 절차는 하나의 물리적 OFS의 프로세싱 절차와의 일치를 유지한다.

본 실시예에서, 트리플렛 [datapath_id, input_no, output_no]은 경로 정보를 지시하는 데 사용되고, OFS에 의해 수신된 OFPT_HELLO 메시지가 전술한 트리플렛을 이미 가지고 있으면, OFS는 이전의 트리플렛에 기초하여 이 노드의 트리플렛을 부가하여, 트리플렛 시퀀스를 형성하며, 이것은 다음의 방식으로 표현될 수 있다:

<[datapath_id, input_no, output_no], [datapath_id, input_no, output_no]......>

여기서:

datapath_id는 OFS를 식별하는 데 사용되고, 필드는 OpenFlow 프로토콜에 정의되고, 그 하위 48 비트는 교환기의 MAC 어드레스이고, 그 상위 16 비트는 실행기에 의해 정의되며(예를 들어, 가상 네트워크의 ID는 앞으로 OFS의 가상화를 실현하도록 사용되며);

input_no: 패킷이 들어가는, OFS의 포트의 번호; 및

output_no: 패킷이 포워딩되는, OFS의 포트의 번호.

도 15를 참조하면, 이 도면은 본 실시예에서 경로 정보를 OPFT_HELLO 메시지의 본문 필드로 확장하는 개략도이다. 도면에서, body_length 필드 아래의 필드는 경로 정보이고, 복수의 경로 정보 집합이 있을 수 있으며, 각각의 경로 정보 집합은 3부분: datapath_id, input_no, and output_no을 포함한다.

3-웨이 TCP 핸드셰이크의 교환이 완료된 후, 제1 OFS는 OFPT_HELLO 메시지를 생성하고, TCP/IP 패킷을 구성하며, 이 패킷을 브로드캐스트한다.

TCP/IP 패킷의 헤더는 다음과 같이 설정된다:

dst_mac: OFC의 MAC 어드레스;

src_mac: 제1 OFC의 MAC 어드레스;

src_ip: 제1 OFC의 IP 어드레스;

dst_ip: OFC의 IP 어드레스;

src_port: TCP 접속을 청취하는 데 사용되는, 제1 OFS의 포트 번호;

dst_port: TCP 접속을 청취하는 데 사용되는, OFC의 포트 번호;

초기의 TTL 값은 설정되며; 그리고

패킷 내의 페이로드는 OFPT_HELLO 메시지를 반송하며, 패킷 트리플렛 <[dpid_OFS1, --, output_no_OFS1]>은 OFPT_HELLO 메시지의 본문 필드에 부가되고, 여기서 dpid_OFS1은 경로 ID를 나타내고, "--"는 패킷이 들어가는, OFS 포트의 포트의 번호이고(OFS는 초기의 OFS이기 때문에, OFS는 다른 OFS로부터 패킷을 수신하지 않는다), 그리고 output_no_OFS1은 패킷이 포워딩되는, 제1 OFS(OFS1)의 포트의 번호이다.

제1 OFS(OFS1)에 의해 송신된 OFPT_HELLO 메시지의 패킷을 수신한 후, 제2 OFS(OFS3)는 OFPT_HELLO 메시지의 본문 필드에 경로 정보를 부가한다. 본 실시예에서, 각각의 OFS가 OFPT_HELLO 메시지의 패킷을 처리할 때, OFS는 또한 실시예 2 및 실시예 3에서 언급된 흐름 테이블에 대해 와일드카드-매치 정합을 수행하는 방식에 기초해서 패킷을 포워딩할 수 있으며, 정합이 성공하면, OFS는 정합된 엔트리 내의 "명령" 필드 내의 값에 따라 특정한 포트로부터 패킷을 포워딩하고, 정합이 실패하면, OFS는 미리 정의되어 있는 복수의 포트로부터 패킷을 브로드캐스트하거나 패킷을 포워딩할 수 있다. 이에 상응하여, 패킷이 포워딩되는 포트에 대해서, 포트의 정보를 포함하는 경로 정보는 OFPT_HELLO 메시지의 본문 필드에 부가된다. 구체적으로, OFPT_HELLO 메시지의 패킷을 수신한 후, 제2 OFS 및 각각의 다른 OFS는 도 16을 참조하는, 다음의 방법을 사용하여 패킷을 포워딩할 수 있다:

S91: 패킷을 분석하여 TTL, 포트 번호, IP 어드레스, 및 MAC 어드레스와 같은 정보를 획득한다.

S92: TTL이 0보다 큰지를 판정하고, 예이면 S93을 수행하고, 그렇지 않으면 패킷을 폐기한다.

S93: 흐름 테이블에 대한 정확한 정합을 수행하고, 정합된 엔트리가 있으면, 정합된 엔트리 내의 "명령" 필드의 값에 따라 특정한 포트에 패킷을 송신하며, 정합된 엔트리가 없으면, S94를 수행한다.

전술한 단계들은 하드웨어를 사용하여 실행되어 프로세싱 속도를 증가시킬 수 있으며, 후속의 단계들은 소프드웨어를 사용하여 실행되어 프로세싱 융통성을 향상시킬 수 있다.

S94: 목적지 IP 어드레스가 자신과 관련된 OFC의 IP 어드레스인지를 판정하고, 예이면, 단계 S95를 수행하고, 그렇지 않으면, 패킷을 폐기한다.

S95: 목적지 포트 번호가 자신과 관련된 OFC의 포트 번호인지를 판정하고, 예이면, 단계 S96을 수행하고, 그렇지 않으면, 패킷을 폐기한다.

S96: 패킷이 OFPT 유형의 메시지를 반송하는지를 판정하고, 예이면 S97을 수행하고, 그렇지 않으면 패킷을 폐기한다. 구체적으로, 판정은 패킷 내의 페이로드의 정보를 분석함으로써 수행될 수 있다.

S97: 메시지의 유형이 OFPT 유형의 OFPT_HELLO 메시지인지를 판정하고, 예이면 S98을 수행하고, 그렇지 않으면 패킷을 폐기한다.

S98: 흐름 테이블에 대해 와일드카드-매치 정합을 수행하고, 정합된 엔트리가 있으면 S99를 수행하며, 그렇지 않으면 S910을 수행한다.

S99: OFPT_HELLO 메시지의 본문 필드에 현재 OFS의 정보를 부가하고, S911을 수행한다.

S910: OFS의 현재 이용 가능한 출력 포트를 획득하고, S912를 수행한다.

일반적으로, 모든 이용 가능한 출력 포트가 선택될 수 있으며, 후속으로, 이러한 포트로부터 브로드캐스팅이 수행된다. 실제의 애플리케이션에서, 브로드캐스팅을 수행하도록 일부의 포트가 획득될 수도 있으며(예를 들어, 미리 명시되어 있는 일부의 포트가 획득되며), 모든 이용 가능한 포트가 반드시 획득될 필요는 없다.

S911: 정합된 엔트리 내의 "명령" 필드 내의 값에 따라 OFPT_HELLO 메시지의 패킷을 포워딩하고 그 절차를 종료한다.

S912: 각각의 이용 가능한 출력 포트에 대응하는 현재 OFS의 경로 정보를 OFPT_HELLO 메시지의 본문 필드에 부가하고, 예를 들어, 2개의 출력 포트가 있고 이 2개의 출력 포트는 개별적으로 port11 및 port22인 것으로 가정하고, datapath_id는 datapath_id1이고 input_no는 input_no1인 것으로 가정하며, 그런 다음 이하의 정보가 OFPT_HELLO 메시지의 본문 필드에 부가된다:

[datapath_id1, input_no1, port11], [datapath_id,1 input_no1, port22]

S913은 계속 수행된다.

S913: 포워딩을 위한 단계 910으로부터 이용 가능한 출력 포트를 획득하고 절차를 종료한다.

도 17 및 도 18을 참조하며, 이 도면들은 OFPT_HELLO 메시지를 각각의 OFS에 전송하는 개략도이다. 도면에서, Hello는 OFPT_HELLO 메시지를 나타내고("Hello 메시지"로 약칭한다), Hello 뒤의 브라켓 내의 수치는 다른 경로 정보가 부가되는 OFPT_HELLO 메시지를 나타낸다. OFPT_HELLO 메시지를 전송하는 프로세스의 본문 필드 내의 경로 정보의 변화에 대해 도 17 및 도 18을 사용하여 설명한다.

도 17을 참조하면, OFS1은 먼저 브로드캐스트하고 Hello 메시지를 송신하며, Hello 메시지를 수신한 후, OFS3 및 OFS5는 흐름 테이블에 대해 와일드카드-매치 정합을 수행한 다음 특정한 포트를 사용하여 Hello 메시지를 포워딩하며(예를 들어, OFS3은 포트 32를 사용한다), 이 경우, 각각의 Hello 메시지의 본문 필드 내의 정보는 다음과 같다:

Hello (1): < [dpid_OFS1, --, 11] >

Hello (2): < [dpid_OFS1, --, 12] >

Hello (3): < [dpid_OFS1, --, 11], [dpid_OFS3, 31, 32]>

Hello (4): < [dpid_OFS1, --, 11], [dpid_OFS3, 31, 33]>

Hello (5): < [dpid_OFS1, --, 11], [dpid_OFS3, 31, 33], [dpid_OFS5, 51, 52]>

도 18을 참조하면, OFS1은 먼저 브로드캐스트하고 Hello 메시지를 송신하며, OFS3은 흐름 테이블에 대해 와일드카드-매치 정합을 수행하고, 정합된 엔트리가 없다는 것을 알게 되고, 그러므로 또한 브로드캐스팅을 수행하고, Hello 메시지를 수신한 후, OFS5는 흐름 테이블에 대해 와일드카드-매치 정합을 수행한 다음 특정한 포트(52)를 사용하여 Hello 메시지를 포워딩하며, 이 경우, 각각의 Hello 메시지의 본문 필드 내의 정보는 다음과 같다:

Hello (1): < [dpid_OFS1, --, 11] >

Hello (2): < [dpid_OFS1, --, 12] >

Hello (3): < [dpid_OFS1, --, 11], [dpid_OFS3, 31, 32]>

Hello (4): < [dpid_OFS1, --, 11], [dpid_OFS3, 31, 33]>

Hello (5): < [dpid_OFS1, --, 11], [dpid_OFS3, 31, 33], [dpid_OFS5, 51, 52]>

OFC는 수신된 Hello(5) 메시지에 반송된 경로 정보에 따라, 메시지가 먼저 OFS1의 포트 11로부터 OFS3의 포트 31로 송신된 다음, OFS3의 포트 32로부터 OFS5의 포트 51로 송신되며, 최종적으로, OFS5의 포트 52로부터 OFC로 송신된다는 것을 알게 된다. 이에 상응해서, 리버스 경로(OFC로부터 OFS1로의 경로) 역시 결정될 수 있다(예를 들어, OFS5의 포트 51로부터 OFS3의 포트 32로 송신된다).

다른 실시예에서, OFPT_HELLO 메시지의 본문 필드의 확장은 전술한 실시예에 좌우되지 않을 수 있으며, 예를 들어, "먼저 신뢰 가능한 접속을 구축하는 단계", "먼저 정확한 정합을 수행한 다음 와일드카드-매치 정합을 수행하는 단계" 등의 전술한 단계가 사용되지 않을 수 있으나, 초점은 OFPT_HELLO 메시지의 본문 필드가 확장된 후 경로 정보를 반송하는 데 사용된다는 점을 지적하는 것일 뿐이며, 상세한 설명에 대해서는 실시예 12에서의 설명을 참조하면 된다.

실시예 5

전술한 실시예에 기초하여, 본 실시예는 OFC가 경로 정보를 획득한 후 흐름 엔트리(flow entry)를 전달하는 방법을 제공한다.

흐름 엔트리의 기능은 OFS가 브로드캐스팅을 수행하지 않을 수 있게 하는 것이고, 정확한 포워딩은 예를 들어, 현재, 도 16의 개략도에서의 흐름 엔트리를 사용하여 실행될 수 있고, 흐름 엔트리는 OFS1, OFS3, 및 OFS5로 전달되고, 이에 따라 OFS1로부터 OFC로의 메시지는 단방향 경로: OFS1->OFS3->OFS5->OFC를 통해 OFC에 전송될 수 있으며(또는 메시지는 역으로 전송될 수도 있다), 따라서 브로드캐스팅이 필요 없다(예를 들어, OFS1은 메시지를 OFS2에 송신하고, OFS3은 메시지를 OFS2에 송신한다).

경로 정보를 획득한 후, OFC는 각각의 OFS에 의해 요구되는 흐름 엔트리를 만들어낸다. 예를 들어, OFS1이 도 16에서의 OFC에 패킷을 송신하는 요구에 있어서, OFS1 내의 흐름 엔트리에 수 개의 주요 관련 필드가 있으며, 예를 들어, 목적지 IP, 목적지 MAC, 및 목적지 포트(소프트웨어 포트)는 OFC의 IP, MAC, 및 포트이고, 원시 IP, 원시 MAC, 및 원시 포트(소프트웨어 포트)는 OFS1의 IP, MAC, 및 포트이며, 명령은 포트(물리적 포트) 번호 11이다. 다른 OFS 내의 흐름 엔트리에 있어서도 유사하며, 단지 다양한 복수 편의 목적/원시 정보 및 명령 내의 포트의 포트 번호를 대응해서 조정하기만 하면 된다.

도 19를 참조하면, 이 도면은 일부의 OFS에 대한 흐름 엔트리의 개략도이다. 도 19에서, OFC는 경로 정보: OFS1->OFS3->OFS5->OFC를 수집하고, 그런 다음 OFC는 흐름 엔트리를 관련 OFS에 송신할 수 있으며, 예를 들어, 포워드 흐름 엔트리는 OFS1, OFS3, 및 OFS5에 전달될 수 있으며, 이에 따라 패킷은 OFS1로부터 OFC로 포워딩될 수 있고, OFS3에 있어서, OFS5는 리버스 흐름 엔트리를 전달하고, 이에 따라 패킷은 OFC로부터 OFS1 및 OFS3으로 포워딩될 수 있다.

도 19에서, 각각의 OFS의 MAC 어드레스는 "MAC_OFS name"으로 표시되고, 예를 들어, MAC_OFS1는 OFS1의 MAC 어드레스를 표시한다. OFS1의 IP 어드레스는 192.169.1.5인 것으로 가정하고, OFS3의 IP 어드레스는 192.168.1.12인 것으로 가정하고, OFS5의 IP 어드레스는 192.168.1.9인 것으로 가정하고, OFC의 IP 어드레스는 192.168.1.21인 것으로 가정하고, OFC의 TCP 포트 번호는 6633인 것으로 가정하며, OFC의 TCP 포트 번호는 36653인 것으로 가정한다. 필드는 개별적으로 교환기 포트(교환기의 입력 포트), 목적지 MAC, 원시 MAC, 원시 IP, 목적지 IP, 원시 포트, 목적지 포트, 및 정합이 성공할 때 실행되는 명령이고, 맨 좌측의 flow_entry는 흐름 엔트리를 표시한다.

도 19에서, flow_entry(51) 내지 flow_entry(55)는 OFS5에 특정되고, flow_entry(31) 내지 flow_entry(33)는 OFS3에 특정되고 flow_entry(11)가 OFS1에 특정되는 것에 특정된다. 구체적으로, OFS3 내의 흐름 엔트리를 예로 사용하면, flow_entry(31)은 OFC에 의해 OFS3에 송신되는 패킷을 포워딩하는 데 사용되고, flow_entry(32)은 OFC에 의해 OFS1에 송신되는 패킷을 포워딩하는 데 사용되고, flow_entry(33)은 OFS1에 의해 OFC에 송신되는 패킷을 포워딩하는 데 사용된다.

도 19에서의 예는 단지 흐름 엔트리 내의 일부의 관련 필드만을 열거하고, 흐름 엔트리 내의 다른 필드의 값은 당업자에 의해 실제의 애플리케이션 시나리오를 참조하여 쉽게 획득될 수 있다는 것에 유의해야 하며, 이에 대해서는 여기서 다시 설명하지 않는다.

OFC가 흐름 테이블을 전달할 때, OFC는 OFS 및 OFC의 호프 카운트의 올림 차순으로 각각의 OFS에 흐름 테이블을 전달할 수 있으며, 이 방법에서, 흐름 엔트리를 수신한 후, 호프 카운트가 가장 작은 (가장 근접한) OFS는 브로드캐스팅의 필요 없이 후속의 패킷에 대해 정확한 포워딩을 수행할 수 있다. 당연히, 브로드캐스팅 오버헤드가 고려되지 않으면, 흐름 엔트리는 브로드캐스팅을 통해 전달될 수 있다.

도 20을 참조해서, OFC가 Hello 메시지를 수신한 후 흐름 엔트리를 전달하는 예를 사용하고, 주요 절차는 이하를 포함한다:

S111: 헤더를 분석한다.

S112: 패킷 내의 목적지 IP가 OFC의 IP 어드레스와 같은지를 판정하고, 예이면 S113을 수행하고, 그렇지 않으면 패킷을 폐기한다.

S113: 패킷 내의 목적지 포트 번호가 TCP 접속을 청취하기 위한, OFC의 포트 번호와 같은지를 판정하고, 예이면 S114를 수행하고, 그렇지 않으면 패킷을 폐기한다.

S114: 패킷이 OFPT 유형의 메시지를 반송하는지를 판정하고, 예이면 S115를 수행하고, 그렇지 않으면 패킷을 폐기한다.

S115: OFPT 메시지의 유형이 OFPT_HELLO 메시지인지를 판정하고, 예이면 S116을 수행하고, 그렇지 않으면 패킷을 폐기한다.

S116: 원시 OFS와 OFC 간의 경로의 정보를 추출하고, 이어서 흐름 엔트리를 만들어내는 단계 S117과 S119를 수행한다(S117은 포워드 경로에 대한 흐름 경로에 특정되고, S119는 리버스 경로에 특정된다).

S117: 경로 상의 관련 OFS를 위해 OFC에 대한 흐름 엔트리를 만들어내고, S118을 수행한다.

OFC에 대한 흐름 엔트리는 포워딩을 위해 제1 OFS 및 중간 OFS에 대해 만들어진다.

S118: 경로 상의 관련 OFS에 흐름 엔트리를 전달한다.

OFC는 경로 상의 OFS 및 OFC의 호프 카운트의 올림 차순으로 각각의 OFS에 흐름 엔트리를 전달 또는 브로드캐스티할 수 있으며, 절차는 종료된다.

OFC가 경로 정보 내의 datapath_id를 사용하여 대응하는 IP 어드레스 및 MAC 어드레스를 찾아낼 수 없으면, OFC는 전달된 흐름 엔트리 내의 MAC 어드레스를 의사 MAC 어드레스(예를 들어, FF-FF-FF-FF-FF-FF)에 설정하고, 그것이 IPv4 어드레스이면, OFC는 datapath_id에 대응하는 어드레스를 IPv4 멀티캐스트 어드레스 또는 브로드캐스트 어드레스에 설정하고, 그것이 IPv6 어드레스이면, OFC는 datapath_id에 대응하는 어드레스를 IPv6 멀티캐스트 어드레스에 설정한다.

S119: 경로 상의 중간 OFS를 위해 OFC에 대한 흐름 엔트리를 만들어내고, S1110을 수행한다.

중간 OFS란 OFC에 의해 송신된 패킷을 제1 OFS에 포워딩하도록 구성되어 있는 OFS를 말한다.

S1110: 흐름 엔트리를 경로 상의 중간 OFS에 전달하고, S118과 마찬가지로, 흐름 엔트리는 호프 카운트에 기초하여 전달 또는 브로드캐스트될 수 있고, 절차는 종료된다.

마찬가지로, 브랜치를 수행하는 프로세스에서, OFC가 경로 정보 내의 datapath_id를 사용하여 대응하는 IP 어드레스 및 MAC 어드레스를 찾아낼 수 없으면, OFC는 전달된 흐름 엔트리 내의 MAC 어드레스를 의사 MAC 어드레스(예를 들어, FF-FF-FF-FF-FF-FF)에 설정하고, 그것이 IPv4 어드레스이면, OFC는 datapath_id에 대응하는 어드레스를 IPv4 멀티캐스트 어드레스 또는 브로드캐스트 어드레스에 설정하고, 그것이 IPv6 어드레스이면, OFC는 datapath_id에 대응하는 어드레스를 IPv6 멀티캐스트 어드레스에 설정한다.

흐름 엔트리를 구성 및 전달하는 방법에 대해 이하에 상세히 설명한다.

방법 1

기존의 OpenFlow 프로토콜이 뒤따르고, 흐름 엔트리는 OFPT_FLOW_MOD 메시지를 사용하여 반송되며, 각각의 OFPT_FLOW_MOD 메시지는 하나의 flow_entry만을 포함한다.

OpenFlow Spec 1.2 규범을 예로 사용하면, OFPT_FLOW_MOD 메시지의 구조는 다음과 같다:

struct ofp_flow_mod {

struct ofp_header header;

uint64_t cookie;

uint64_t cookie_mask;

uint8_t table_id;

uint8_t command;

uint16_t idle_timeout;

uint16_t hard_timeout;

uint16_t priority;

uint32_t buffer_id;

uint32_t out_port;

uint32_t out_group;

uint16_t flags;

uint8_t pad[2];

struct ofp_match match;//"매치 필드"에 구조체 변수를 정의한다.

struct ofp_instruction instructions[0];//"명령"에 구조체 변수를 정의한다.

};

struct ofp_header {

uint8_t version;

uint8_t type;

uint16_t length;

uint32_t xid;

}

OFC는 OFPT_FLOW_MOD 메시지를 반송하는 데 사용되는 TCP/IP 패킷을 구성하고, 패킷 헤더는 다음과 같이 설정된다:

dst_mac: OFS의 MAC 어드레스;

src_mac: OFC의 MAC 어드레스;

src_ip: OFC의 IP 어드레스;

dst_ip: OFS의 IP 어드레스;

src_port: 청취에 사용되는, OFC의 포트;

dst_port: TCP 접속을 청취하는 데 사용되는, OFS의 포트 번호; 및

초기의 TTL 값이 설정된다.

OFS는 경로 상의 흐름 엔트리를 획득해야 하는 OFS를 말하며, 예를 들어, 포워딩을 위한 제1 OFS 또는 중간 OFS일 수 있다.

패킷을 완전하게 구성한 후, OFC는 각각의 OFS에 패킷을 송신하며, 도 21을 참조하면, 패킷을 수신한 후, 각각의 OFS는 이하의 프로세싱을 수행한다:

S131: 헤더를 분석한다.

S132: TTL이 0보다 큰지를 판정하고, 예이면 S133을 수행하고, 그렇지 않으면 패킷을 폐기한다.

S133: 흐름 테이블에 대한 정확한 정합을 수행하고, 정합된 엔트리가 있으면, 정합된 엔트리 내의 "명령" 필드의 값에 따라 포워딩을 수행하며, 정합된 엔트리가 없으면, S134를 수행한다.

전술한 단계들은 하드웨어를 사용하여 실행될 수 있고 이하의 단계들은 소프트웨어를 실행될 수 있다.

S134: 목적지 MAC 어드레스가 OFS의 MAC 어드레스 또는 의사 MAC 어드레스인지를 판정하고(예를 들어, 모든 F), 예이면 S135를 수행하고, 그렇지 않으면 S1310을 수행한다.

S135: 원시 IP가 자신과 관련된 OFC의 IP 어드레스(또는 멀티캐스트 어드레스 또는 브로드캐스트 어드레스)인지를 판정하고, 예이면 S136을 수행하고, 그렇지 않으면 패킷을 폐기한다.

S136: 원시 포트 번호가 자신과 관련된 OFC의 포트 번호인지를 판정하고, 예이면 S137을 수행하고, 그렇지 않으면 패킷을 폐기한다.

S137: OFPT 유형의 메시지인지를 판정하고, 예이면 S138을 수행하고, 그렇지 않으면 패킷을 폐기한다.

S138: OFPT 메시지의 유형이 OFPT_FLOW_MOD인지를 판정하고, 예이면 S139를 수행하고, 그렇지 않으면 패킷을 폐기한다.

S139: OFPT_FLOW_MOD 메시지 내의 흐름 엔트리를 추출하고 이 흐름 엔트리를 흐름 테이블에 삽입한다. 구체적으로, OFS는 OFPT_FLOW_MOD가 OFS의 datapath_id를 포함하는지를 판정하고, 예이면 OFS는 datapath 및 정확한 매치와 관련 있는 하나 이상의 흐름 엔트리를 흐름 테이블에 부가하며, OFPT_FLOW_MOD에 포함되어 있는 MAC의 값이 FF-FF-FF-FF-FF-FF와 같고, MAC 어드레스에 대응하는 IP 어드레스가 멀티캐스트 어드레스 또는 브로드캐스트 어드레스이면, OFS는 교환기의 MAC 어드레스 및 IP 어드레스를 흐름 엔트리에 갱신하고, 절차가 종료된다.

S1310: 원시 IP가 자신과 관련된 OFC의 IP 어드레스인지를 판정하고, 예이면 S1311을 수행하고, 그렇지 않으면 패킷을 폐기한다.

S1311: 원시 포트 번호가 자신과 관련된 OFC의 포트 번호인지를 판정하고, 예이면 S1312를 수행하고, 그렇지 않으면 패킷을 폐기한다.

S1312: OFPT 유형의 메시지인지를 판정하고, 예이면 S1313을 수행하고, 그렇지 않으면 패킷을 폐기한다.

S1313: OFPT 메시지의 유형이 OFPT_FLOW_MOD인지를 판정하고, 예이면 S1314를 수행하고, 그렇지 않으면 패킷을 폐기한다.

S1314: 패킷을 브로드캐스트하고, 절차가 종료된다.

방법 2

다른 구성 방법은 OpenFlow 프로토콜에서의 OFPT_FLOW_MOD 메시지를 확장하고, 이에 따라 하나의 OFPT_FLOW_MOD 메시지는 OFS와 관련된 복수의 flow_entry를 포함할 수 있다. 이하의 구조체를 참조하면, p_multi_flow_mod_list의 구조체는 OFPT_FLOW_MOD 메시지 내의 확장부이다:

struct ofp_multi_flow_mod_list {

ofp_multi_flow_mod head;

ofp_multi_flow_mod tail;

uint8_t flow_entry_number;

}; //확장된 구조체

struct ofp_multi_flow_mod {

struct ofp_flow_mod;

struct ofp_multi_flow_mod *prior, *next;

}; //확장된 구조체

struct ofp_header {

uint8_t version;

uint8_t type;

uint16_t length;

uint32_t xid;

};

struct ofp_flow_mod_body {

uint64_t cookie;

uint64_t cookie_mask;

uint8_t table_id;

uint8_t command;

uint16_t idle_timeout;

uint16_t hard_timeout;

uint16_t priority;

uint32_t buffer_id;

uint32_t out_port;

uint32_t out_group;

uint16_t flags;

uint8_t pad[2];

struct ofp_match match;

struct ofp_instruction instructions[0];

};

전술한 절차는 방법 1에서의 포워딩 절차와 유사하지만, 단계 S139에서, 복수의 흐름 엔트리는 1회 추출될 수 있다.

방법 3

OpenFlow 프로토콜에서의 OFPT_FLOW_MOD 메시지가 확장되고, 이에 따라 OFPT_FLOW_MOD 메시지는 (OFS1, OFS3, OFS5, 및 OFC에 의해 형성된 경로를 예를 사용하여) 경로 상의 모든 관련된 OFS(예를 들어, OFS1, OFS3, 및 OFS5)의 복수의 흐름 엔트리(예를 들어, 도 30에 열거된 모든 flow_entry)를 포함할 수 있다. 경로 상의 모든 장치에 송신하는 단계가 수행되므로, datapath_id 식별자가 본 실시예에서의 구조체: ofp_flow_mod_body에 부가되어, 경로 상의 장치를 식별하며, 이에 따라 경로 상의 정보가 뒤이어서 포워딩될 수 있다:

struct ofp_multi_flow_mod_list {

ofp_multi_flow_mod head;

ofp_multi_flow_mod tail;

uint8_t flow_entry_number;

}; //extended struct

struct ofp_multi_flow_mod {

struct ofp_flow_mod;

struct ofp_multi_flow_mod *prior, *next;

}; //확장된 구조체

struct ofp_header {

uint8_t version;

uint8_t type;

uint16_t length;

uint32_t xid;

};

struct ofp_flow_mod_body{

uint64_t datapath_id; //확장된 항목

uint64_t cookie;

uint64_t cookie_mask;

uint8_t table_id;

uint8_t command;

uint16_t idle_timeout;

uint16_t hard_timeout;

uint16_t priority;

uint32_t buffer_id;

uint32_t out_port;

uint32_t out_group;

uint16_t flags;

uint8_t pad[2];

struct ofp_match match;

struct ofp_instruction instructions[0];

};

패킷 내의 페이로드가 확장 OFPT_FLOW_MOD를 반송하고 (OFS1, OFS3, OFS5, 및 OFC에 의해 형성된 경로를 예를 사용하여) 경로 상의 각각의 교환기(OFS1, OFS3, 및 OFS5)와 관련된 흐름 엔트리를 포함한다.

TCP/IP 패킷을 수신한 후, OFS가 메시지 유형이 OFPT_FLOW_MOD인 것으로 결정하면, OFS는 TCP/IP 패킷으로부터 OFS와 관련된 flow_entries를 추출하며(즉, ofp_flow_mod_body. datapath_id는 OFS의 datapath_id와 같다), 그런 다음 OFPT_FLOW_MOD에 포함된 OFS 모두가 메시지를 수신할 때까지 패킷을 계속 브로드캐스트한다.

실시예 6

전술한 실시예에 기초해서, 본 실시예는 SDN 교환기의 하드웨어 구조를 제공하며, 도 22를 참조하면, OFS의 하드웨어 구조를 예로 사용하면, 다른:

트랜스시버, 하드웨어 장치, 및 소프트웨어 장치

를 포함할 수 있다.

송수신기는 패킷을 송수신하도록 구성되어 있는 하드웨어 회로이거나, 하드웨어 장치를 가진 물리적 칩으로 제조될 수 있다.

하드웨어 장치는 또한 "하드웨어 프로세싱 모듈"이라 할 수도 있으며, 더 간단하게는, 약칭해서 "하드웨어"라 할 수도 있으며, 수신된 패킷을 처리하도록 구성되어 있다. 하드웨어 장치는 FPGA, ASCI 등에 기초한 전용의 하드웨어 회로(이것은 메모리와 같은 다른 액세서리 장치와 결합하여 사용될 수도 있다)를 주로 포함하여, 일부의 특정한 기능을 가진 하드웨어 회로를 실현하며, 프로세싱 속도는 일반적으로 범용 CPU의 속도보다 훨씬 빠르지만 기능은 주문된 후에 변경하기가 매우 어려우며, 그러므로 실시는 융통적이지가 않으며 일반적으로 일부의 고정 기능을 처리하도록 구성되어 있다. 실제의 애플리케이션에서, 하드웨어 장치는 또한 MCU(싱글칩 마이크로컴퓨터와 같은 마이크로프로세서), 또는 CPU와 같은 프로세서를 포함할 수 있으나, 이러한 프로세서의 주기능은 빅 데이터에 대한 프로세싱을 완료하는 것이 아니라 일부의 제어를 수행하는 데 주로 사용된다. 이러한 애플리케이션 시나리오에서, 이러한 장치에 의해 결합된 시스템이 하드웨어 장치이다.

소프트웨어 장치(또는 "소프트웨어"로 약칭하기도 한다)는 범용 CPU 및 일부의 액세서리 장치(메모리 또는 하드디스크와 같은 스토리지 장치)를 주로 포함하며, CPU는 소프트웨어 프로그래밍을 통해 대응하는 프로세싱 기능을 가질 수 있으며, 소프트웨어 장치가 소프트웨어를 사용하여 실현될 때, 소프트웨어 장치는 서비스 커맨드에 따라 융통성 있게 구성될 수 있으나, 속도는 일반적으로 하드웨어 장치의 속도보다 훨씬 느리다. 소프트웨어가 프로세싱을 완료한 후, 완전하게 처리된 데이터는 송수신기를 사용하여 하드웨어 장치에 의해 송신될 수 있거나, 완전하게 처리된 데이터는 송수신기에 접속된 인터페이스를 사용하여 송수신기에 송신될 수 있다.

본 실시예에서, 하드웨어 장치는 전술한 실시예에서 언급된 정확한 정합을 수행도록 구성될 수 있으며, 소프트웨어 장치는 전술한 실시예에서 언급된 와일드카드-매치 정합을 수행하도록 구성되어 있다. 즉, 송수신 회로를 통해 패킷을 수신한 후, OFS는 또한 처리용 하드웨어 장치에 패킷을 송신하고, 정합이 성공하면, OFS는 패킷을 포워딩하며, 정합이 실패하면, OFS는 처리용 소프트웨어 장치에 패킷을 송신한다(예를 들어, OpenFlow 프로토콜로 정의된 packet_in 메시지가 생성될 수 있으며, 패킷은 소프트웨어 장치에 송신된다).

하드웨어 및 소프트웨어 양자는 정확한 흐름 테이블을 저장하므로, 이 2가지는 맵핑 관계를 유지할 수 있으며, 이는 실시예 2에 상세히 설명되어 있으므로 이에 대해서는 여기서 다시 상세히 설명하지 않는다.

본 실시예에서 소프트웨어와 하드웨어를 결합하는 방식으로 사용함으로써, 프로세싱 속도가 보장되고 융통성이 유지된다.

당연히, 본 실시예는 소프트웨어 장치를 사용하여 실행되는 것에 제한되지 않으며, 예를 들어, 도 23을 참조하여, 이 도면은 하드웨어를 사용하여 실현되는 솔루션이며, 즉 프로세서는 메모리(예를 들어 하드디스크 또는 메모리)에 저장되어 있는 코드를 실행하여 대응하는 작동을 수행한다.

실시예 7

전술한 실시예에 기초하여, 도 24를 참조하면, 본 실시예는 SDN 교환기를 제공하며, 여기서 SDN 교환기는 제2 SDN 교환기이며, 제2 SDN 교환기는 제1 SDN 교환기 및 SDN 제어기에 접속되어 SDN 네트워크를 형성하며, 상기 SDN 제어기는 각각의 SDN 교환기와 대역내 통신 방식(inband communication manner)으로 통신하며, 상기 제2 SDN 교환기는,

상기 제1 SDN 교환기와 상기 SDN 제어기 사이에 신뢰 가능한 접속이 구축되어, 상기 제1 SDN 교환기와 상기 SDN 제어기 사이의 메시지 교환을 수행하도록 구성되어 있는 접속 구축 유닛(71);

상기 제1 SDN 교환기에 의해 송신되고 경로 정보를 수집하는 데 사용되는 제1 제어 메시지를 수신하도록 구성되어 있는 제1 수신 유닛(72) - 상기 제1 메시지는 제1 SDN 교환기의 경로 정보를 반송하며, 상기 제1 제어 정보는 상기 신뢰 가능한 접속에 대응하는 패킷으로 반송됨 - ;

상기 제1 수신 유닛에 의해 수신된 제1 제어 메시지에 상기 제2 SDN 교환기의 경로 정보를 부가하여 갱신된 제1 제어 메시지를 획득하는 경로 부가 유닛(73); 및

상기 갱신된 제1 제어 메시지를 포함하는 최종적으로 갱신된 제1 제어 메시지를 수신한 후, 상기 SDN 제어기가, 각각의 SDN 교환기에 의해 상기 최종적으로 갱신된 제1 제어 메시지에 부가된 경로 정보에 따라 SDN 제어기와 제1 SDN 교환기 간의 루팅 경로를 결정하고 상기 루팅 경로에 따라 제1 SDN 교환기에 정확한 흐름 엔트리를 전달할 수 있도록, 상기 경로 부가 유닛이 제2 SDN 교환기의 경로 정보를 부가하는 상기 갱신된 제1 제어 메시지를 SDN 제어기에 포워딩하도록 구성되어 있는 포워딩 유닛(74)

을 포함한다.

본 실시예에서, 상기 제1 SDN 교환기와 상기 SDN 제어기 사이에 구축된 신뢰 가능한 접속은 TCP 접속을 포함하고, 상기 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷은 TCP/IP 패킷이며,

상기 접속 구축 유닛은 구체적으로, 제1 SDN 교환기와 SDN 제어기 사이에 TCP 접속이 구축되어, 제1 SDN 교환기와 SDN 제어기 사이에서 수행되는 3-웨이 TCP 핸드셰이크의 메시지를 반송하는 TCP/IP 패킷을 포워딩하도록 구성되어 있다.

본 실시예에서, 상기 제2 SDN 교환기는 정확한 흐름 테이블을 포함하고, 상기 정확한 흐름 테이블은 복수의 정확한 흐름 엔트리를 포함하고, 각각의 정확한 흐름 엔트리는 복수의 매치 필드 및 상기 복수의 매치 필드에 대응하는 명령을 포함하며,

도 25를 참조하면, 상기 접속 구축 유닛(71)은 구체적으로:

상기 제1 SDN 교환기로부터 송신된 제1 TCP/IP 패킷을 수신하도록 구성되어 있는 수신 서브유닛(711);

상기 수신 서브유닛에 의해 수신된 제1 TCP/IP 패킷 내의 복수 편의 특징 정보를 획득하도록 구성되어 있는 특징 정보 획득 서브유닛 - 상기 특징 정보는 제2 SDN 교환기 내의 정확한 흐름 테이블의 정확한 흐름 엔트리 내의 매치 필드에 대응함 - ; 및

상기 특징 정보 획득 서브유닛에 의해 획득되는 TCP/IP 패킷 내의 복수 편의 특징 정보와 상기 제2 SDN 교환기 내의 정확한 흐름 테이블 간의 정확한 정합을 수행하고, 상기 정확한 정합이 실패하고 상기 수신된 제1 TCP/IP 패킷이 제1 유형의 TCP 핸드셰이크 메시지를 반송하는 것으로 판정되면, 상기 복수 편의 특징 정보 중 한 편 이상의 특징 정보와 상기 정확한 흐름 테이블 간의 와일드카드-매치 정합을 수행하고 - 상기 와일드카드-매치 정합 동안 사용된 하나 이상의 매치 필드에 대응하는 명령을 사용하여 결정되는 포워딩 루트는 SDN 제어기에 최종적으로 도달할 수 있는 루트임 - , 그리고 상기 와일드카드-매치 정합이 성공하면, 상기 와일드카드-매치 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라, 상기 제1 유형의 TCP 핸드셰이크 메시지를 반송하는 상기 제1 TCP/IP 패킷을 SDN 제어기에 포워딩하기 위해 상기 제1 유형의 TCP/IP 핸드셰이크 메시지를 반송하는 상기 수신된 제1 TCP/IP 패킷을 처리하도록 구성되어 있는 제1 정합 서브유닛(712) - 상기 제1 유형의 TCP/IP 핸드셰이크 메시지는 제1 TCP 핸드셰이크의 메시지 또는 제3 TCP 핸드셰이크의 메시지임 -

을 포함한다.

본 실시예에서, 상기 수신 서브유닛은 상기 SDN 제어기로부터 송신된 제3 TCP/IP 패킷을 수신하도록 구성되어 있으며, 여기서 상기 제3 TCP/IP 패킷은 제2 핸드셰이크의 메시지를 반송하며,

상기 특징 정보 획득 서브유닛은 상기 수신 서브유닛에 의해 수신된 제3 TCP/IP 패킷 내의 복수 편의 특징 정보를 획득하도록 구성되어 있으며, 여기서 상기 특징 정보는 제2 SDN 교환기 내의 정확한 흐름 테이블의 정확한 흐름 엔트리 내의 매치 필드에 대응하며, 그리고

상기 제1 매칭 서브유닛은 상기 특징 정보 획득 서브유닛에 의해 획득되는 제3 TCP/IP 패킷 내의 복수 편의 특징 정보와 상기 제2 SDN 교환기 내의 정확한 흐름 테이블 간의 정확한 정합을 수행하고, 상기 정확한 정합이 성공하면, 상기 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라 포워딩을 수행하며, 그리고 상기 정합이 실패하고 상기 제3 TCP/IP 패킷이 제2 TCP 핸드셰이크의 메시지를 반송하는 것으로 판정되면, 제3 TCP/IP 패킷을 브로드캐스팅하도록 구성되어 있다.

본 실시예에서, 상기 제2 SDN 교환기는 상기 정확한 흐름 테이블을 저장하고, 상기 정확한 흐름 테이블은 복수의 정확한 흐름 엔트리를 포함하고, 각각의 정확한 흐름 엔트리는 복수의 매치 필드 및 상기 복수의 매치 필드에 대응하는 명령을 포함하며,

상기 제1 수신 유닛은 구체적으로:

상기 제1 SDN 교환기로부터 송신되고 제1 제어 메시지를 반송하는 제2 TCP/IP 패킷을 수신하도록 구성되어 있으며, 여기서 상기 제2 TCP/IP 패킷은 복수 편의 특징 정보를 포함하고, 상기 특징 정보는 제2 SDN 교환기 내의 정확한 흐름 테이블의 정확한 흐름 엔트리 내의 매치 필드에 대응하며,

도 26을 참조하면, 상기 경로 부가 유닛은:

제2 수신 서브유닛에 의해 수신된 상기 제2 TCP/IP 패킷 내의 특징 정보 및 상기 정확한 흐름 테이블에 따라 정확한 정합을 수행하고, 상기 정확한 정합이 실패하고 상기 수신된 제2 TCP/IP 패킷이 제1 제어 메시지를 반송하는 것으로 판정된 후, 상기 TCP/IP 패킷 내의 한 편 이상의 특징 정보 및 상기 정확한 흐름 테이블에 따라 와일드카드-매치 정합을 수행하도록 구성되어 있는 제2 매칭 서브유닛(731) - 여기서 상기 와일드카드-매치 정합 동안 사용된 하나 이상의 매치 필드에 대응하는 명령을 사용하여 결정되는 포워딩 루트는 SDN 제어기에 최종적으로 도달할 수 있는 루트임 - ; 및

상기 제2 매칭 서브유닛의 와일드카드-매치 정합이 성공할 때, 제2 SDN 교환기의 경로 정보를 제1 제어 메시지에 부가하여, 상기 제2 SDN 교환기의 경로 정보가 부가되는 갱신된 제1 제어 메시지를 획득하도록 구성되어 있는 부가 서브유닛(732)

을 포함하며, 그리고

도 27을 참조하면, 상기 포워딩 유닛(74)은, 상기 와일드카드-매치 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라, 상기 부가 서브유닛의 프로세싱 후에 획득되는 상기 갱신된 제1 제어 메시지를 상기 SDN 제어기에 포워딩하도록 구성되어 있는 제1 포워딩 서브유닛(741)을 포함한다.

본 실시예에서, 상기 부가 서브유닛(732)은, 상기 제2 매칭 서브유닛의 와일드카드-매치 정합이 실패하면, 상기 제2 SDN 교환기의 이용 가능한 출력 포트를 획득하고, 각각의 이용 가능한 출력 포트에 대응하는, 상기 제2 SDN 교환기의 경로 정보를 제1 제어 메시지에 부가하도록 추가로 구성되어 있으며,

도 27을 참조하면, 상기 포워딩 유닛(74)은, 각각의 이용 가능한 출력 포트에 대응하는, 상기 제2 SDN 교환기의 경로 정보를 상기 부가 서브유닛이 부가하는 상기 갱신된 제1 제어 메시지를, 상기 이용 가능한 출력 포트로부터 SDN 제어기에 포워딩하도록 구성되어 있는 제2 포워딩 서브유닛(742)을 포함한다.

전술한 실시예와 마찬가지로, 본 실시예에서, 상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 실행되고, 상기 제1 제어 메시지는 상기 OpenFlow 프로토콜로 정의된 OFPT_HELLO 메시지를 포함하고, 상기 OFPT_HELLO 메시지의 본문 필드는 확장된 후에 경로 정보를 반송하는 데 사용되며,

상기 제1 수신 유닛은 구체적으로, 상기 접속 구축 유닛에 의해 구축된 신뢰 가능한 접속을 사용함으로써, 상기 제1 SDN 교환기에 의해 송신되고 상기 경로 정보를 수집하는 데 사용되는 OFPT_HELLO 메시지를 수신하도록 구성되고, 여기서, 상기 경로 정보를 반송하는 데 사용되는, 상기 OFPT_HELLO 메시지 내의 확장 본문 필드는 상기 제1 SDN 교환기의 경로 정보를 반송하며,

상기 경로 부가 유닛은 구체적으로, 상기 제2 SDN 교환기의 경로 정보를, 상기 경로 정보를 반송하는 데 사용되는, 상기 제1 수신 유닛에 의해 수신된 OFPT_HELLOW 메시지 내의 확장 본문 필드에 부가하여, 갱신된 OFPT_HELLO 메시지를 획득하도록 구성되어 있으며,

상기 포워딩 유닛은 구체적으로, 상기 갱신된 OFPT_HELLO 메시지를 포함하는 최종적으로 갱신된 OFPT_HELLO 메시지를 수신한 후, 상기 SDN 제어기가, 각각의 SDN 교환기에 의해 상기 최종적으로 갱신된 OFPT_HELLO 메시지에 부가된 경로 정보에 따라 SDN 제어기와 제1 SDN 교환기 간의 루팅 경로를 결정하고 상기 루팅 경로에 따라 제1 SDN 교환기에 정확한 흐름 엔트리를 전달할 수 있도록, 상기 경로 부가 유닛이 제2 SDN 교환기의 경로 정보를 부가하는 상기 갱신된 OFPT_HELLO 메시지를 SDN 제어기에 포워딩하도록 구성되어 있다.

본 실시예에서, 상기 포워딩 유닛은 구체적으로, 상기 제2 SDN 교환기의 경로 정보가 부가되는 상기 갱신된 제1 제어 메시지를 SDN 제어기에 직접적으로 포워딩하거나 - 상기 최종적으로 갱신된 제1 제어 메시지는 상기 갱신된 제1 제어 메시지임 - ; 또는

하나 이상의 다른 SDN 교환기를 사용함으로써, 상기 제2 SDN 교환기의 경로 정보가 부가되는 상기 갱신된 제1 제어 메시지를 SDN 제어기에 간접적으로 포워딩하도록 구성되어 있으며,

상기 최종적으로 갱신된 제1 제어 메시지는, 각각의 다른 SDN 교환기가 이전의 SDN 교환에 의해 송신된 제1 제어 메시지를 수신하고 각각의 다른 SDN 교환기의 경로 정보를 제1 제어 메시지에 부가한 후, 각각의 다른 SDN 교환기에 의해 SDN 제어기에 최종적으로 송신되는 제1 제어 메시지이다.

본 실시예에서, 상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 실행되고, 상기 SDN 교환기는:

상기 SDN 제어기로부터 송신되고 상기 OpenFlow 프로토콜로 정의된 OFPT_FLOW_MOD 메시지를 수신하도록 구성되어 있는 제2 수신 유닛 - 상기 OFPT_FLOW_MOD 메시지는 목적지 SDN 교환기에 의해 요구되는 복수의 정확한 흐름 엔트리를 반송함 - ; 및

상기 제2 수신 유닛에 의해 수신된 메시지가 상기 제2 SDN 교환기에 송신된 OFPT_FLOW_MOD 메시지인 것으로 판정될 때, 상기 OFPT_FLOW_MOD 메시지에 반송된 복수의 정확한 흐름 엔트리를 추출하고 그런 다음 상기 복수의 정확한 흐름 엔트리를 현지의 정확한 흐름 테이블에 부가하도록 구성되어 있는 제1 흐름 엔트리 프로세싱 유닛

을 더 포함한다.

대안으로, 상기 SDN 네트워크가 OpenFlow 프로토콜에 기초하여 실행될 때, 본 실시예는,

상기 SDN 제어기로부터 송신되고 상기 OpenFlow 프로토콜로 정의된 OFPT_FLOW_MOD 메시지를 수신하도록 구성되어 있는 제3 수신 유닛 - 상기 OFPT_FLOW_MOD 메시지는 상기 루팅 경로 상에 위치하는 복수의 SDN 교환기에 의해 요구되는 복수의 정확한 흐름 엔트리 및 상기 루팅 경로 상의 각각의 SDN 교환기에 대응하는 경로 정보를 반송하며, 상기 루팅 경로 상의 각각의 SDN 교환기는 하나 이상의 정확한 흐름 엔트리를 사용함 - ; 및

상기 제3 수신 유닛에 의해 수신된 메시지가 상기 제2 SDN 교환기에 송신된 OFPT_FLOW_MOD 메시지인 것으로 판정될 때, 상기 제2 SDN 교환기에 대응하는 경로 정보에 따라, 상기 제2 SDN 교환기에 의해 사용되어야 하는 하나 이상의 정확한 흐름 엔트리를 추출하고, 상기 추출이 완료된 후 OFPT_FLOW_MOD 메시지를 루팅 경로 상의 다음 노드에 포워딩하도록 구성되어 있는 제2 흐름 엔트리 프로세싱 유닛

을 더 포함할 수 있다.

본 실시예에서, 상기 경로 정보는: 제1 제어 메시지를 송신 또는 수신하는 SDN 교환기의 ID, 제1 제어 메시지를 수신하는 데 사용되는 포트 번호, 및 제1 제어 메시지를 송신하는 데 사용되는 포트 번호를 포함한다.

본 실시예를 사용함으로써, 비용이 절감될 수 있으며, SDN 교환기의 효율성을 포워딩을 하는 것은 향상될 수 있으며, 브로드캐스트 스톰은 감소될 수 있으며, 특정한 이유로, 전술한 실시예에서 분석을 참조하며, 여기서 다시 설명하지 않는다.

실시예 8

전술한 실시예에 기초해서, 본 실시예는 SDN 제어기를 개시하며, 상기 SDN 제어기는 제2 SDN 교환기 접속되고, 상기 제2 SDN 교환기는 제1 SDN 교환기에 접속되어 SDN 네트워크를 형성하며, 상기 SDN 제어기는 각각의 SDN 교환기와 대역내 통신 방식으로 통신하며, 도 28을 참조하여, 상기 SDN 제어기는:

상기 제2 SDN 교환기에 의해 포워딩된 최종적으로 갱신된 제1 제어 메시지를 수신하도록 구성되어 있는 제1 수신 유닛(81) - 상기 최종적으로 갱신된 제1 메시지는 갱신된 제1 제어 메시지를 포함하며, 상기 갱신된 제1 제어 메시지는 상기 제2 SDN 교환기가 제1 SDN 교환기에 의해 송신되고 경로 정보를 수집하는 데 사용되는 제1 제어 메시지를 수신한 후, 제2 SDN 교환기가 제2 SDN 교환기의 경로 정보를 제1 제어 메시지에 부가함으로써 획득되며, 상기 제1 제어 메시지는 제1 SDN 교환기의 경로 정보를 반송하며, 상기 제1 제어 정보는 제1 SDN 교환기와 SDN 제어기 사이에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷으로 반송됨 - ;

각각의 SDN 교환기에 의해 부가되고 상기 제1 수신 유닛에 의해 수신된 상기 최종적으로 갱신된 제1 제어 메시지에 반송된 경로 정보에 따라 SDN 제어기와 제1 SDN 교환기 간의 루팅 경로를 획득하도록 구성되어 있는 경로 획득 유닛(82); 및

상기 경로 획득 유닛에 의해 획득된 루팅 경로를 통해 제1 SDN 교환기에 정확한 흐름 엔트리를 전달하도록 구성되어 있는 흐름 테이블 전달 유닛(83)

을 포함한다.

본 실시예에서, 상기 제1 SDN 교환기와 SDN 제어기 사이에 구축된 신뢰 가능한 접속은 TCP 접속을 포함하고, 상기 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷은 TCP/IP 패킷이고, 상기 TCP 접속은 상기 제2 SDN 교환기가 제1 SDN 교환기와 SDN 제어기 사이에서 수행되는 3-웨이 TCP 핸드셰이크의 메시지를 반송하는 TCP/IP 패킷을 포워딩함으로써 구축된다.

본 실시예에서, 상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 실행되고, 상기 제1 제어 메시지는 OFPT_HELLO 메시지를 포함하고, 상기 OFPT_HELLO 메시지의 본문 필드는 확장된 후에 경로 정보를 반송하는 데 사용된다.

본 실시예에서, 상기 제1 수신 유닛은 구체적으로:

상기 제2 SDN 교환기에 의해 포워딩된 상기 최종적으로 갱신된 제1 제어 메시지를 직접적으로 수신하거나;

또는,

하나 이상의 다른 SDN 교환기를 사용함으로써, 상기 제2 SDN 교환기에 의해 포워딩된 상기 최종적으로 갱신된 제1 제어 메시지를 간접적으로 수신하도록 구성되어 있으며,

상기 최종적으로 갱신된 제1 제어 메시지는, 각각의 다른 SDN 교환기가 이전의 SDN 교환에 의해 송신된 제1 제어 메시지를 수신하고 각각의 다른 SDN 교환기의 경로 정보를 제1 제어 메시지에 부가한 후, 각각의 다른 SDN 교환기에 의해 SDN 제어기에 최종적으로 송신되는 제1 제어 메시지이다.

본 실시예에서, 상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 실행되고, 이에 상응해서, 상기 흐름 제어 전달 유닛은 구체적으로:

상기 OpenFlow 프로토콜로 정의된 OFPT_FLOW_MOD 메시지에 상기 제1 SDN 교환기에 의해 요구되는 복수의 정확한 흐름을 부가하고; 그리고

상기 제1 SDN 교환기가 OFPT_FLOW_MOD 메시지에 따라 정확한 흐름 엔트리를 획득할 수 있도록, 상기 루팅 경로를 통해 제1 SDN 교환기에 OFPT_FLOW_MOD 메시지를 송신하도록 구성되어 있다.

대안으로,

상기 흐름 제어 전달 유닛은 구체적으로:

상기 루팅 경로 상에 위치하는 복수의 SDN 교환기에 의해 요구되는 복수의 정확한 흐름 엔트리 및 상기 루팅 경로 상의 각각의 SDN 교환기에 대응하는 경로 정보를 상기 OpenFlow 프로토콜로 정의된 OFPT_FLOW_MOD 메시지에 부가하며 - 상기 루팅 경로 상의 각각의 SDN 교환기는 하나 이상의 정확한 흐름 엔트리를 필요로 함 - ; 그리고

상기 OFPT_FLOW_MOD 메시지를 수신한 후, 상기 다른 SDN 교환기가 상기 경로 정보 및 상기 OFPT_FLOW_MOD 메시지 내의 경로 정보에 따라, 상기 다른 SDN 교환기에 의해 요구되는 추출 흐름 엔트리를 추출하고, 나머지 추출 흐름 엔트리를 포워딩하며, 제1 SDN 교환기에 의해 요구되는 정확한 흐름 엔트리를 제1 SDN 교환기에 최종적으로 포워딩할 수 있도록, 상기 루팅 경로를 통해 상기 OFPT_FLOW_MOD 메시지를 다른 SDN 교환기에 전달하도록 구성되어 있다.

실시예 9

도 29를 참조하면, 본 실시예는 소프트웨어 정의 네트워크(software defined network, SDN) 시스템을 개시하며, 상기 시스템은 제1 SDN 교환기(91), 제2 SDN 교환기(92), 및 SDN 제어기(94)를 포함하며(하나 이상의 다른 중간 SDN 교환기(93)가 있을 수 있다), 상기 제2 SDN 교환기는 제1 SDN 교환기 및 SDN 제어기에 접속되어 SDN 네트워크를 형성하며, 상기 SDN 제어기는 각각의 SDN 교환기와 대역내 통신 방식으로 통신하며,

상기 제1 SDN 교환기(91)는 경로 정보를 수신하는 데 사용되는 제1 제어 메시지를 상기 제2 SDN 교환기(92)에 송신하도록 구성되어 있으며, 여기서 상기 제1 메시지는 제1 SDN 교환기(91)의 경로 정보를 반송하며, 상기 제1 제어 정보는 제1 SDN 교환기(91)와 SDN 제어기(94) 간에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷으로 반송되며;

상기 제2 SDN 교환기(92)는 제1 제어 메시지를 수신하고 상기 제1 제어 메시지에 상기 제2 SDN 교환기(92)의 경로 정보를 부가하여 갱신된 제1 제어 메시지를 획득하고, 제2 SDN 교환기(92)의 경로 정보가 부가되는 상기 갱신된 제1 제어 메시지를 SDN 제어기(94)에 포워딩하도록 구성되어 있으며,

상기 SDN 제어기(94)는, 상기 제2 SDN 교환기(92)에 의해 송신되고 상기 갱신된 제1 제어 메시지를 포함하는 최종적으로 갱신된 제1 제어 메시지를 수신하고, 각각의 SDN 교환기에 의해 상기 최종적으로 갱신된 제1 제어 메시지에 부가된 경로 정보에 따라, SDN 제어기(94)와 제1 SDN 교환기(91) 간의 루팅 경로를 결정하며, 상기 루팅 경로에 따라 제1 SDN 교환기(91)에 정확한 흐름 엔트리를 전달하도록 구성되어 있다.

본 실시예에서, 상기 제1 SDN 교환기(91)와 상기 SDN 제어기(94) 사이에 구축된 신뢰 가능한 접속은 TCP 접속을 포함하고, 상기 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷은 TCP/IP 패킷이며, 상기 TCP/IP 접속은, 상기 제2 SDN 교환기(92)가, 제1 SDN 교환기(91)와 SDN 제어기(94) 사이에서 수행되는 3-웨이 TCP 핸드셰이크의 메시지를 반송하는 TCP/IP 패킷을 포워딩함으로써 구축된다.

상기 제2 SDN 교환기는 정확한 흐름 테이블을 저장하고, 상기 정확한 흐름 테이블은 복수의 정확한 흐름 엔트리를 포함하고, 각각의 정확한 흐름 엔트리는 복수의 매치 필드 및 상기 복수의 매치 필드에 대응하는 명령을 포함하며,

상기 제2 SDN 교환기는 구체적으로, 상기 제1 SDN 교환기로부터 송신된 제1 TCP/IP 패킷을 수신하고, 상기 수신된 제1 TCP/IP 패킷 내의 복수 편의 특징 정보를 획득하고 - 상기 특징 정보는 제2 SDN 교환기 내의 정확한 흐름 테이블의 정확한 흐름 엔트리 내의 매치 필드에 대응함 - , 그리고 상기 복수 편의 특징 정보와 상기 제2 SDN 교환기 내의 정확한 흐름 테이블 간의 정확한 정합을 수행하고, 상기 정확한 정합이 실패하고 상기 수신된 제1 TCP/IP 패킷이 제1 유형의 TCP 핸드셰이크 메시지를 반송하는 것으로 판정되면, 상기 복수 편의 특징 정보 중 한 편 이상의 특징 정보와 상기 정확한 흐름 테이블 간의 와일드카드-매치 정합을 수행하며 - 상기 와일드카드-매치 정합 동안 사용된 하나 이상의 매치 필드에 대응하는 명령을 사용하여 결정되는 포워딩 루트는 SDN 제어기에 최종적으로 도달할 수 있는 루트임 - , 그리고 상기 와일드카드-매치 정합이 성공하면, 상기 와일드카드-매치 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라, 상기 제1 TCP/IP 패킷을 SDN 제어기에 포워딩하기 위해, 상기 제1 유형의 TCP/IP 핸드셰이크 메시지를 반송하는 상기 수신된 제1 TCP/IP 패킷을 처리하도록 구성되어 있으며, 상기 제1 유형의 TCP/IP 핸드셰이크 메시지는 제1 TCP 핸드셰이크의 메시지 또는 제3 TCP 핸드셰이크의 메시지이며, 제1 SDN 교환기와 다른 OFS와 SDN 제어기 사이에서 상기 신뢰의 구축을 구축하는 데 사용되는 메시지의 교환을 실행하여, 상기 신뢰 가능한 접속을 구축한다.

상기 제2 SDN 교환기는 구체적으로, 상기 제1 SDN 교환기로부터 송신되고 제1 제어 메시지를 반송하는 제2 TCP/IP 패킷을 수신하고 - 상기 제2 TCP/IP 패킷은 복수 편의 특징 정보를 포함하고, 상기 특징 정보는 제2 SDN 교환기 내의 정확한 흐름 테이블의 정확한 흐름 엔트리 내의 매치 필드에 대응함 - , 상기 제2 TCP/IP 패킷 내의 특징 정보 및 상기 정확한 흐름 테이블에 따라 정확한 정합을 수행하고, 상기 정확한 정합이 실패하고 상기 수신된 제2 TCP/IP 패킷이 제1 제어 메시지를 반송하는 것으로 판정된 후, 상기 TCP/IP 패킷 내의 한 편 이상의 특징 정보 및 상기 정확한 흐름 테이블에 따라 와일드카드-매치 정합을 수행하며 - 여기서 상기 와일드카드-매치 정합 동안 사용된 하나 이상의 매치 필드에 대응하는 명령을 사용하여 결정되는 포워딩 루트는 SDN 제어기에 최종적으로 도달할 수 있는 루트임 - ; 그리고 상기 제2 매칭 서브유닛의 와일드카드-매치 정합이 성공할 때, 제2 SDN 교환기의 경로 정보를 제1 제어 메시지에 부가하여, 상기 제2 SDN 교환기의 경로 정보가 부가되는 갱신된 제1 제어 메시지를 획득하며, 상기 와일드카드-매치 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라, 상기 갱신된 제1 제어 메시지를 상기 SDN 제어기에 포워딩하도록 구성되어 있다.

본 실시예에서, 상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 실행되고, 이 경우, 상기 제1 제어 메시지는 상기 OpenFlow 프로토콜로 정의된 OFPT_HELLO 메시지를 포함하고, 상기 OFPT_HELLO 메시지의 본문 필드는 확장된 후에 경로 정보를 반송하는 데 사용된다.

본 실시예에서, 상기 제2 SDN 교환기는 구체적으로, 제1 제어 메시지를 SDN 제어기에 직접 또는 간접 방식으로 포워딩할 수 있으며, 직접 포워딩 동안, 상기 최종적으로 갱신된 제1 제어 메시지는, 각각의 다른 SDN 교환기가 이전의 SDN 교환에 의해 송신된 제1 제어 메시지를 수신하고 각각의 다른 SDN 교환기의 경로 정보를 제1 제어 메시지에 부가한 후, 각각의 다른 SDN 교환기에 의해 SDN 제어기에 최종적으로 송신되는 제1 제어 메시지이다.

본 실시예에서, 상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 실행되고,

정확한 흐름 엔트리는 수 가지 방법을 사용하여 OpenFlow 프로토콜에 기초하여 반송될 수 있다.

제1 방법에 대응하는 실시예에서, 제2 SDN 교환기는 상기 SDN 제어기로부터 송신되고 상기 OpenFlow 프로토콜로 정의된 OFPT_FLOW_MOD 메시지를 수신하고, 여기서 상기 OFPT_FLOW_MOD 메시지는 목적지 SDN 교환기에 의해 요구되는 복수의 정확한 흐름 엔트리를 반송하며, 그리고

상기 수신된 메시지가 상기 제2 SDN 교환기에 송신된 OFPT_FLOW_MOD 메시지인 것으로 판정될 때, 상기 제2 SDN 교환기는 OFPT_FLOW_MOD 메시지에 반송된 복수의 정확한 흐름 엔트리를 추출한 다음 복수의 정확한 흐름 엔트리를 현지의 정확한 흐름 테이블에 부가한다.

제2 방법에 대응하는 실시예에서, 제2 SDN 교환기는,

상기 SDN 제어기로부터 송신되고 상기 OpenFlow 프로토콜로 정의된 OFPT_FLOW_MOD 메시지를 수신하고, 여기서 상기 OFPT_FLOW_MOD 메시지는 상기 루팅 경로 상에 위치하는 복수의 SDN 교환기에 의해 요구되는 복수의 정확한 흐름 엔트리 및 상기 루팅 경로 상의 각각의 SDN 교환기에 대응하는 경로 정보를 반송하며, 상기 루팅 경로 상의 각각의 SDN 교환기는 하나 이상의 정확한 흐름 엔트리를 사용하며; 그리고

상기 수신된 메시지가 상기 제2 SDN 교환기에 송신된 OFPT_FLOW_MOD 메시지인 것으로 판정될 때, 상기 제2 SDN 교환기는, 상기 제2 SDN 교환기에 대응하는 경로 정보에 따라, 상기 제2 SDN 교환기에 의해 사용되어야 하는 하나 이상의 정확한 흐름 엔트리를 추출하고, 상기 추출이 완료된 후 OFPT_FLOW_MOD 메시지를 루팅 경로 상의 다음 노드에 포워딩하도록 구성되어 있다.

본 실시예에서, 상기 경로 정보는 제1 제어 메시지를 송신 또는 수신하는 SDN 교환기의 ID, 제1 제어 메시지를 수신하는 데 사용되는 포트 번호, 및 제1 제어 메시지를 송신하는 데 사용되는 포트 번호를 포함한다.

실시예 10

전술한 실시예에 기초하여, 본 실시예는 SDN 제어기가 패킷을 포워딩하는 방법을 개시하며, 상기 SDN 교환기는 제2 SDN 교환기이고, 상기 제2 SDN 교환기는 정확한 흐름 테이블을 저장하고, 상기 정확한 흐름 테이블은 적어도 하나의 정확한 흐름 엔트리를 포함하고, 각각의 정확한 흐름 엔트리는 복수의 매치 필드 및 상기 복수의 매치 필드에 대응하는 명령을 포함하며, 상기 방법은 이하를 포함한다:

S301: 제1 SDN 교환기로부터 송신된 패킷을 수신하며, 여기서 상기 패킷은 복수 편의 특징 정보를 포함하며, 상기 특징 정보는 상기 정확한 흐름 엔트리 내의 매치 필드에 대응한다.

S302: 상기 패킷 내의 특징 정보를 획득한다.

S303: 상기 특징 정보와 상기 정확한 흐름 테이블 내의 정확한 흐름 엔트리 간의 정확한 정합을 수행하고, 상기 정확한 정합이 실패하면, 상기 복수 편의 특징 정보 중 한 편 이상의 특징 정보와 상기 정확한 흐름 테이블 내의 정확한 흐름 엔트리 간의 와일드카드-매치 정합을 수행하고, 여기서 상기 와일드카드-매치 정합 동안 사용된 하나 이상의 매치 필드에 대응하는 명령을 사용하여 결정되는 포워딩 루트는 SDN 제어기에 최종적으로 도달할 수 있는 루트이며, 그리고 상기 와일드카드-매치 정합이 성공하면, 상기 와일드카드-매치 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라, 상기 패킷을 SDN 제어기에 포워딩한다.

본 실시예에서, 상기 정확한 정합이 성공하면, 상기 포워딩하는 단계는 상기 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라 수행되고, 상기 와일드카드-매치 정합이 실패하면, 상기 수신된 패킷은 브로드캐스팅을 통해 포워딩된다.

본 실시예에서, 상기 제2 SDN 교환기는 제1 SDN 교환기 및 SDN 제어기에 접속되어 SDN 네트워크를 형성하며, 상기 SDN 제어기는 각각의 SDN 교환기와 대역내 통신 방식으로 통신한다.

본 실시예에서, 상기 패킷은 제1 SDN 교환기와 SDN 제어기 사이에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷이며, 상기 패킷은 제1 SDN 교환기에 의해 송신되고 경로 정보를 수집하는 데 사용되는 제1 제어 메시지를 반송하는 데 사용된다.

본 실시예를 사용함으로써, SDN 교환기의 효율성을 포워딩하는 것이 향상될 수 있으며, 또한 본 실시예에서의 솔루션에 기초해서 포워딩된 패킷의 유형은 본 실시예에서 제한되지 않는다.

실시예 11

전술한 실시예에 기초하여, 본 실시예는 실시예 10에서의 방법에 대응하는 SDN 교환기를 제공하며, 상기 SDN 교환기는 제2 SDN 교환기이고, 상기 제2 SDN 교환기는 정확한 흐름 테이블을 저장하고, 상기 정확한 흐름 테이블은 복수의 정확한 흐름 엔트리를 포함하고, 각각의 정확한 흐름 엔트리는 복수의 매치 필드 및 상기 복수의 매치 필드에 대응하는 명령을 포함하며, 도 31을 참조하면, 상기 제2 SDN 교환기는,

제1 SDN 교환기로부터 송신된 패킷을 수신하도록 구성되어 있는 수신 유닛(101) - 상기 패킷은 한 편 이상의 특징 정보를 포함함 - ;

상기 수신 유닛에 의해 수신된 패킷 내의 특징 정보를 획득하도록 구성되어 있는 획득 유닛(102);

상기 획득 유닛에 의해 획득된 한 편 이상의 특징 정보와 상기 정확한 흐름 테이블 내의 정확한 흐름 엔트리 간의 정확한 정합을 수행하도록 구성되어 있는 정확한 정합 유닛(103) - 상기 한 편 이상의 특징 정보는 상기 정확한 흐름 테이블 내의 정확한 흐름 엔트리 내의 매치 필드에 대응함 - ;

상기 정확한 정합 유닛에 의해 수행된 정확한 정합이 실패하면, 상기 복수 편의 특징 정보 중 한 편 이상의 특징 정보와 상기 정확한 흐름 테이블 내의 정확한 흐름 엔트리 간의 와일드카드-매치 정합을 수행하도록 구성되어 있는 와일드카드-매치 정합 유닛(104) - 상기 와일드카드-매치 정합 동안 사용된 하나 이상의 매치 필드에 대응하는 명령을 사용하여 결정되는 포워딩 루트는 SDN 제어기에 최종적으로 도달할 수 있는 루트임 - ; 및

상기 와일드카드-매치 정합 유닛에 의해 수행된 와일드카드-매치 정합이 성공하면, 상기 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라, 상기 패킷을 포워딩하도록 구성되어 있는 포워딩 유닛(104)

을 포함한다.

본 실시예에서, 상기 정합 및 포워딩 유닛은:

상기 정확한 정합이 성공하면, 상기 정합에서 성공하는 정확한 흐름 엔트리 내의 명령에 따라 포워딩을 수행하고,

상기 와일드카드-매치 정합이 실패하면, 브로드캐스팅을 통해 포워딩을 수행하도록 추가로 구성되어 있다.

상기 제2 SDN 교환기는 제1 SDN 교환기 및 SDN 제어기에 접속되어 (직접적으로 또는 간접적으로 접속될 수 있다) SDN 네트워크를 형성하며, 상기 SDN 제어기는 각각의 SDN 교환기와 대역내 통신 방식으로 통신한다.

상기 패킷은 제1 SDN 교환기와 SDN 제어기 사이에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷이며, 상기 패킷은 제1 SDN 교환기에 의해 송신되고 경로 정보를 수집하는 데 사용되는 제1 제어 메시지를 반송하는 데 사용된다.

실시예 12

전술한 실시예에 기초해서, 본 실시예는 개방흐름 교환기(OpenFlow Switch, OFS)가 경로 정보를 수집하는 방법을 제공하며, 상기 방법은 제2 OFS에 적용되고, 상기 제2 OFS는 제1 OFS 및 흐름개방 제어기(OpenFlow Controller, OFC)에 접속되어 OpenFlow 네트워크를 형성하며, 상기 OFC는 대역내 통신 방식으로 각각의 OFS와 통신하며, 도 32를 참조하면, 상기 방법은 이하를 포함한다:

S321: 상기 제1 OFS에 의해 송신되고, 경로 정보를 수집하는 데 사용되며, 상기 OpenFlow 프로토콜에 정의되는 OFPT_HELLO 메시지를 수신하며, 여기서 상기 OFPT_HELLO 메시지의 본문 필드는 확장된 후 상기 경로 정보를 반송하는 데 사용되고, 상기 OFPT_HELLO 메시지는 제1 OFS의 경로 정보를 반송하며, 상기 OFPT_HELLO 메시지는 제1 OFS와 OFC 간에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷으로 반송된다.

S322: 상기 제2 OFS의 경로 정보를 상기 OFPT_HELLO 메시지에 부가하여 갱신된 OFPT_HELLO 메시지를 획득한다.

S323: 상기 갱신된 OFPT_HELLO 메시지를 포함하는 최종적으로 갱신된 OFPT_HELLO 메시지를 수신한 후, 상기 OFC가 각각의 OFS에 의해 상기 최종적으로 갱신된 OFPT_HELLO 메시지에 부가된 경로 정보에 따라 상기 OFC와 상기 제1 OFS 간의 루팅 경로를 결정하고, 상기 루팅 경로에 따라 정확한 흐름 엔트리를 제1 OFS에 전달할 수 있도록 상기 갱신된 OFPT_HELLO 메시지를 상기 OFC에 포워딩한다.

상기 경로 정보는 상기 OFPT_HELLO 메시지를 송신 또는 수신하는 OFS의 ID, 상기 OFPT_HELLO 메시지를 수신하는 데 사용되는 포트 번호, 및 상기 OFPT_HELLO 메시지를 송신하는 데 사용되는 포트 번호를 포함한다.

본 실시예에서, 상기 갱신된 OFPT_HELLO 메시지를 상기 OFC에 포워딩하는 단계는:

상기 갱신된 OFPT_HELLO 메시지를 상기 OFC에 직접적으로 포워딩하는 단계 - 상기 최종적으로 갱신된 OFPT_HELLO 메시지는 상기 갱신된 OFPT_HELLO 메시지임 - , 또는

하나 이상의 다른 OFS를 사용함으로써 상기 갱신된 OFPT_HELLO 메시지를 상기 OFC에 간접적으로 송신하는 단계

를 포함하며,

여기서 상기 다른 OFS들은 상기 수신된 갱신된 OFPT_HELLO 메시지에 경로 정보를 부가하여 상기 최종적으로 갱신된 OFPT_HELLO 메시지를 획득한다.

본 실시예를 사용함으로써, 경로 정보는 기존의 OpenFlow 프로토콜에서의 메시지에 기초하여 반송될 수 있으며, 프로토콜은 변경될 필요가 없으며, 이것은 개발 비용을 절감한다.

실시예 13

전술한 실시예에 기초해서, 본 실시예는 실시예 12에서의 방법에 대응하는 OFS를 개시하며, 상기 OFS는 제2 OFS이고, 상기 제2 OFS는 제1 OFS, 흐름개방 제어기(OpenFlow Controller, OFC) 및 적어도 하나의 다른 OFS에 접속되어 OpenFlow 네트워크를 형성하며, 상기 OFC는 대역내 통신 방식으로 각각의 OFS와 통신하며, 도 33을 참조하여, 상기 제2 OFS는:

상기 제1 OFS에 의해 송신되고, 경로 정보를 수집하는 데 사용되며, 상기 OpenFlow 프로토콜에 정의되는 OFPT_HELLO 메시지를 수신하도록 구성되어 있는 수신 유닛(131) - 상기 OFPT_HELLO 메시지의 본문 필드는 확장된 후 상기 경로 정보를 반송하는 데 사용되고, 상기 OFPT_HELLO 메시지는 제1 OFS의 경로 정보를 반송하며, 상기 OFPT_HELLO 메시지는 제1 OFS와 OFC 간에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷으로 반송됨 - ;

상기 제2 OFS의 경로 정보를 상기 수신 유닛에 의해 수신된 OFPT_HELLO 메시지에 부가하여 갱신된 OFPT_HELLO 메시지를 획득하도록 구성되어 있는 경로 정보 부가 유닛(132); 및

상기 갱신된 OFPT_HELLO 메시지를 포함하는 최종적으로 갱신된 OFPT_HELLO 메시지를 수신한 후, 상기 OFC가 각각의 OFS에 의해 상기 최종적으로 갱신된 OFPT_HELLO 메시지에 부가된 경로 정보에 따라 상기 OFC와 상기 제1 OFS 간의 루팅 경로를 결정하고, 상기 루팅 경로에 따라 정확한 흐름 엔트리를 제1 OFS에 전달할 수 있도록, 상기 경로 정보 부가 유닛이 제2 OFS의 경로 정보를 부가하는 상기 갱신된 OFPT_HELLO 메시지를 상기 OFC에 포워딩하도록 구성되어 있는 포워딩 유닛(133)

을 포함한다.

상기 경로 정보는 상기 OFPT_HELLO 메시지를 송신 또는 수신하는 OFS의 ID, 상기 OFPT_HELLO 메시지를 수신하는 데 사용되는 포트 번호, 및 상기 OFPT_HELLO 메시지를 송신하는 데 사용되는 포트 번호를 포함한다.

본 실시예에서, 상기 포워딩 유닛(133)은 구체적으로:

상기 갱신된 OFPT_HELLO 메시지를 상기 OFC에 직접적으로 포워딩하거나 - 상기 최종적으로 갱신된 OFPT_HELLO 메시지는 상기 갱신된 OFPT_HELLO 메시지임 - , 또는

하나 이상의 다른 OFS를 사용함으로써 상기 갱신된 OFPT_HELLO 메시지를 상기 OFC에 간접적으로 포워딩하도록 구성되어 있으며,

여기서 상기 다른 OFS들은 상기 수신된 갱신된 OFPT_HELLO 메시지에 경로 정보를 부가하여 상기 최종적으로 갱신된 OFPT_HELLO 메시지를 획득한다.

실시예 7 내지 실시예 13에 포함되어 있는 솔루션의 특정한 단계들은 전술한 실시예(예를 들어, 실시예 1 내지 실시예 5)의 특정한 설명을 참조하여 당업자에 의해 획득될 수 있으므로, 실시예 7 내지 실시예 13에서 상세히 설명되어 있지 않다. 또한, 실시예 7 내지 실시예 13에서의 장치에 포함되어 있는 유닛(서브유닛)은 논리적 기능 분할이며, 이러한 유닛들의 특정한 실현 방식은 제한되지 않는다는 것에 유의해야 한다. 예를 들어, 이러한 유닛들은 실시예 6에서의 소프트웨어와 하드웨어를 결합하는 아키텍처에 기초해서 실현될 수 있거나 소프트웨어만의 아키텍처를 사용하여 실현될 수 있다. 유닛에 포함되어 있는 기능들은 전술한 방법 실시예에서의 방법에서의 단계들에 대응하므로, 당업자는 실시예 6에서의 특정한 장치에 따라 각각의 유닛을 실현할 수 있을 것이며, 예를 들어, 송수신기를 사용하여 장치 실시예에 포함되어 있는 일부의 수신 유닛들을 실현할 수 있을 것이다.

당업자라면 본 발명의 방법의 단계 중 일부 또는 전부는 관련 하드웨어에 명령을 내리는 컴퓨터 프로그램에 의해 구현될 수 있다는 것을 이해할 수 있을 것이다. 프로그램은 컴퓨터가 판독 가능한 저장 매체에 저장될 수 있다. 프로그램이 실행되면, 프로그램은 본 발명의 임의의 실시예에서 설명된 방법을 실행한다. 저장 매체는 자기디스크, 광디스크, 리드 온리 메모리(Read-Only Memory, ROM), 또는 랜덤 액세스 메모리(Random Access Memory, RAM)가 될 수 있다.

본 발명의 실시예의 목적, 기술적 솔루션 및 이점에 대해 위에서 설명하였다. 전술한 상세한 설명은 단지 본 발명의 예시적 실시예에 지나지 않으며, 본 발명의 보호 범위를 제한하려는 것이 아님은 물론이다. 창조적 노력 없이 당업자에 의해 이루어지는 어떠한 변형, 등가의 대체, 또는 개선이라도 본 발명의 보호 범위 내에 있게 된다.

Claims (26)

1. 소프트웨어 정의 네트워크(software defined network, SDN) 교환기가 흐름 테이블을 획득하는 방법으로서,
   상기 방법은 SDN 제어기에 적용되고, 상기 SDN 제어기가 제2 SDN 교환기에 접속되고 상기 제2 SDN 교환기가 제1 SDN 교환기에 접속되어 SDN 네트워크를 형성하며, 상기 SDN 제어기는 각각의 SDN 교환기와 대역내 통신 방식(inband communication manner)으로 통신하고, 상기 방법은,
   상기 제2 SDN 교환기에 의해 포워딩된 최종적으로 갱신된 제1 제어 메시지를 수신하는 단계 - 상기 최종적으로 갱신된 제1 제어 메시지는 갱신된 제1 제어 메시지를 포함하고, 상기 갱신된 제1 제어 메시지는, 상기 제2 SDN 교환기가 상기 제1 SDN 교환기에 의해 송신되고 경로 정보를 수집하기 위해 사용되는 제1 제어 메시지를 수신한 후에, 상기 제2 SDN 교환기가 상기 제2 SDN 교환기의 경로 정보를 상기 제1 제어 메시지에 부가함으로써 획득되는 것이고, 상기 제1 제어 메시지는 상기 제1 SDN 교환기의 경로 정보를 반송하며, 상기 제1 제어 메시지는 상기 제1 SDN 교환기와 상기 SDN 제어기 사이에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷 내에서 반송됨 -;
   상기 최종적으로 갱신된 제1 제어 메시지 내에 반송되는 각각의 SDN 교환기에 의해 부가된 경로 정보에 따라, 상기 SDN 제어기와 상기 제1 SDN 교환기 사이의 라우팅 경로를 획득하는 단계; 및
   상기 라우팅 경로에 따라 상기 제1 SDN 교환기에 정확한 흐름 엔트리를 전달하는 단계
   를 포함하는 방법.
2. 제1항에 있어서,
   상기 제1 SDN 교환기와 상기 SDN 제어기 사이에 구축된 신뢰 가능한 접속은 TCP 접속을 포함하고, 상기 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷은 TCP/IP 패킷이고, 상기 TCP 접속은 상기 제2 SDN 교환기가 상기 제1 SDN 교환기와 상기 SDN 제어기 사이에서 수행되는 3-웨이 TCP 핸드셰이크의 메시지를 반송하는 TCP/IP 패킷을 포워딩함으로써 구축되는 것인, 방법.
3. 제1항 또는 제2항에 있어서,
   상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 구현되고, 상기 제1 제어 메시지는 상기 OpenFlow 프로토콜로 정의된 OFPT_HELLO 메시지를 포함하고, 상기 OFPT_HELLO 메시지의 본문 필드는, 확장된 후의 경로 정보를 반송하는 데 사용되는, 방법.
4. 제1항 또는 제2항에 있어서,
   상기 제2 SDN 교환기에 의해 포워딩된 최종적으로 갱신된 제1 제어 메시지를 수신하는 단계는,
   상기 제2 SDN 교환기에 의해 포워딩된 상기 최종적으로 갱신된 제1 제어 메시지를 직접적으로 수신하는 단계 - 여기서 상기 최종적으로 갱신된 제1 제어 메시지가 상기 갱신된 제1 제어 메시지임 -; 또는
   상기 제2 SDN 교환기의 경로 정보가 부가된 상기 갱신된 제1 제어 메시지에 대해, 하나 이상의 다른 SDN 교환기를 사용함으로써 상기 제2 SDN 교환기에 의해 포워딩된 상기 최종적으로 갱신된 제1 제어 메시지를 간접적으로 수신하는 단계 - 여기서 상기 최종적으로 갱신된 제1 제어 메시지는, 상기 다른 SDN 교환기 각각이 이전의 SDN 교환기에 의해 송신된 제1 제어 메시지를 수신하고 상기 다른 SDN 교환기 각각의 경로 정보를 상기 제1 제어 메시지에 부가한 후에 상기 다른 SDN 교환기 각각에 의해 상기 SDN 제어기에 최종적으로 송신되는 제1 제어 메시지임 - 를 포함하는, 방법.
5. 제1항 또는 제2항에 있어서,
   상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 구현되고, 상기 라우팅 경로에 따라 상기 제1 SDN 교환기에 정확한 흐름 엔트리를 전달하는 단계는,
   상기 제1 SDN 교환기에 의해 요구되는 복수의 정확한 흐름 엔트리를 상기 OpenFlow 프로토콜로 정의된 OFPT_FLOW_MOD 메시지에 부가하는 단계; 및
   상기 OFPT_FLOW_MOD 메시지를 수신한 후에 상기 제1 SDN 교환기가 상기 OFPT_FLOW_MOD 메시지에 반송된 복수의 정확한 흐름 엔트리를 추출하고 상기 복수의 정확한 흐름 엔트리를 현지의 정확한 흐름 테이블에 부가할 수 있도록, 상기 라우팅 경로에 따라 상기 제1 SDN 교환기에 상기 OFPT_FLOW_MOD 메시지를 송신하는 단계를 포함하는, 방법.
6. 제1항 또는 제2항에 있어서,
   상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 구현되고, 상기 라우팅 경로에 따라 상기 제1 SDN 교환기에 정확한 흐름 엔트리를 전달하는 단계는,
   상기 라우팅 경로 상의 각각의 SDN 교환기에 대응하는 경로 정보 및 상기 라우팅 경로 상에 위치하는 복수의 SDN 교환기에 의해 요구되는 복수의 정확한 흐름 엔트리를 상기 OpenFlow 프로토콜로 정의된 OFPT_FLOW_MOD 메시지에 부가하는 단계 - 상기 라우팅 경로 상의 각각의 SDN 교환기는 하나 이상의 정확한 흐름 엔트리를 필요로 함 -; 및
   상기 OFPT_FLOW_MOD 메시지를 수신한 후에 다른 SDN 교환기가 상기 경로 정보 및 상기 OFPT_FLOW_MOD 메시지 내의 경로 정보에 따라 상기 다른 SDN 교환기에 의해 요구되는 정확한 흐름 엔트리를 추출하고, 나머지 정확한 흐름 엔트리를 포워딩하며, 상기 제1 SDN 교환기에 의해 요구되는 정확한 흐름 엔트리를 상기 제1 SDN 교환기에 최종적으로 포워딩할 수 있도록, 상기 라우팅 경로에 따라 상기 다른 SDN 교환기에 상기 OFPT_FLOW_MOD 메시지를 전달하는 단계를 포함하는, 방법.
7. 소프트웨어 정의 네트워크(software defined network, SDN) 제어기로서,
   상기 SDN 제어기가 제2 SDN 교환기에 접속되고 상기 제2 SDN 교환기가 제1 SDN 교환기에 접속되어 SDN 네트워크를 형성하며, 상기 SDN 제어기는 각각의 SDN 교환기와 대역내 통신 방식(inband communication manner)으로 통신하고,
   상기 제2 SDN 교환기에 의해 포워딩된 최종적으로 갱신된 제1 제어 메시지를 수신하도록 구성된 제1 수신 유닛 - 상기 최종적으로 갱신된 제1 제어 메시지는 갱신된 제1 제어 메시지를 포함하고, 상기 갱신된 제1 제어 메시지는, 상기 제2 SDN 교환기가 상기 제1 SDN 교환기에 의해 송신되고 경로 정보를 수집하기 위해 사용되는 제1 제어 메시지를 수신한 후에, 상기 제2 SDN 교환기가 상기 제2 SDN 교환기의 경로 정보를 상기 제1 제어 메시지에 부가함으로써 획득되는 것이고, 상기 제1 제어 메시지는 상기 제1 SDN 교환기의 경로 정보를 반송하며, 상기 제1 제어 메시지는 상기 제1 SDN 교환기와 상기 SDN 제어기 사이에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷 내에서 반송됨 -;
   상기 제1 수신 유닛에 의해 수신된 상기 최종적으로 갱신된 제1 제어 메시지 내에 반송되는 각각의 SDN 교환기에 의해 부가된 경로 정보에 따라, 상기 SDN 제어기와 상기 제1 SDN 교환기 사이의 라우팅 경로를 획득하도록 구성된 경로 획득 유닛; 및
   상기 경로 획득 유닛에 의해 획득되는 상기 라우팅 경로를 통해 상기 제1 SDN 교환기에 정확한 흐름 엔트리를 전달하도록 구성된 흐름 테이블 전달 유닛
   을 포함하는 소프트웨어 정의 네트워크 제어기.
8. 제7항에 있어서,
   상기 제1 SDN 교환기와 상기 SDN 제어기 사이에 구축된 신뢰 가능한 접속은 TCP 접속을 포함하고, 상기 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷은 TCP/IP 패킷이고, 상기 TCP 접속은 상기 제2 SDN 교환기가 상기 제1 SDN 교환기와 상기 SDN 제어기 사이에서 수행되는 3-웨이 TCP 핸드셰이크의 메시지를 반송하는 TCP/IP 패킷을 포워딩함으로써 구축되는 것인, 소프트웨어 정의 네트워크 제어기.
9. 제7항 또는 제8항에 있어서,
   상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 구현되고, 상기 제1 제어 메시지는 상기 OpenFlow 프로토콜로 정의된 OFPT_HELLO 메시지를 포함하고, 상기 OFPT_HELLO 메시지의 본문 필드는, 확장된 후의 경로 정보를 반송하는 데 사용되는, 소프트웨어 정의 네트워크 제어기.
10. 제7항 또는 제8항에 있어서,
    상기 제1 수신 유닛은 구체적으로,
    상기 제2 SDN 교환기에 의해 포워딩된 상기 최종적으로 갱신된 제1 제어 메시지를 직접적으로 수신하거나 - 여기서 상기 최종적으로 갱신된 제1 제어 메시지가 상기 갱신된 제1 제어 메시지임 -; 또는
    상기 제2 SDN 교환기의 경로 정보가 부가된 상기 갱신된 제1 제어 메시지에 대해, 하나 이상의 다른 SDN 교환기를 사용함으로써 상기 제2 SDN 교환기에 의해 포워딩된 상기 최종적으로 갱신된 제1 제어 메시지를 간접적으로 수신하도록 - 여기서 상기 최종적으로 갱신된 제1 제어 메시지는, 상기 다른 SDN 교환기 각각이 이전의 SDN 교환기에 의해 송신된 제1 제어 메시지를 수신하고 상기 다른 SDN 교환기 각각의 경로 정보를 상기 제1 제어 메시지에 부가한 후에 상기 다른 SDN 교환기 각각에 의해 상기 SDN 제어기에 최종적으로 송신되는 제1 제어 메시지임 - 구성되는, 소프트웨어 정의 네트워크 제어기.
11. 제7항 또는 제8항에 있어서,
    상기 SDN 네트워크는 OpenFlow 프로토콜에 기초하여 구현되고, 상기 흐름 테이블 전달 유닛은 구체적으로,
    상기 제1 SDN 교환기에 의해 요구되는 복수의 정확한 흐름 엔트리를 상기 OpenFlow 프로토콜로 정의된 OFPT_FLOW_MOD 메시지에 부가하고;
    상기 제1 SDN 교환기가 상기 OFPT_FLOW_MOD 메시지에 따라 정확한 흐름 엔트리를 획득할 수 있도록, 상기 라우팅 경로를 통해 상기 제1 SDN 교환기에 상기 OFPT_FLOW_MOD 메시지를 송신하도록 구성되는, 소프트웨어 정의 네트워크 제어기.
12. 제7항 또는 제8항에 있어서,
    상기 흐름 테이블 전달 유닛은 구체적으로,
    상기 라우팅 경로 상의 각각의 SDN 교환기에 대응하는 경로 정보 및 상기 라우팅 경로 상에 위치하는 복수의 SDN 교환기에 의해 요구되는 복수의 정확한 흐름 엔트리를 OpenFlow 프로토콜로 정의된 OFPT_FLOW_MOD 메시지에 부가하고 - 상기 라우팅 경로 상의 각각의 SDN 교환기는 하나 이상의 정확한 흐름 엔트리를 필요로 함 -;
    상기 OFPT_FLOW_MOD 메시지를 수신한 후에 다른 SDN 교환기가 상기 경로 정보 및 상기 OFPT_FLOW_MOD 메시지 내의 경로 정보에 따라 상기 다른 SDN 교환기에 의해 요구되는 정확한 흐름 엔트리를 추출하고, 나머지 정확한 흐름 엔트리를 포워딩하며, 상기 제1 SDN 교환기에 의해 요구되는 정확한 흐름 엔트리를 상기 제1 SDN 교환기에 최종적으로 포워딩할 수 있도록, 상기 라우팅 경로를 통해 상기 다른 SDN 교환기에 상기 OFPT_FLOW_MOD 메시지를 전달하도록 구성되는, 소프트웨어 정의 네트워크 제어기.
13. 소프트웨어 정의 네트워크(software defined network, SDN) 교환기가 패킷을 획득하는 방법으로서,
    상기 SDN 교환기가 제2 SDN 교환기이고, 상기 제2 SDN 교환기가 정확한 흐름 테이블을 저장하며, 상기 정확한 흐름 테이블은 적어도 하나의 정확한 흐름 엔트리를 포함하고, 각각의 정확한 흐름 엔트리는 복수의 매치 필드와 상기 복수의 매치 필드에 대응하는 명령을 포함하며, 상기 방법은,
    제1 SDN 교환기에 의해 송신된 패킷을 수신하는 단계 - 상기 패킷은 복수 편(piece)의 특징 정보를 포함하고, 상기 특징 정보는 상기 정확한 흐름 엔트리 내의 매치 필드에 대응함 -;
    상기 패킷 내의 특징 정보를 획득하는 단계; 및
    상기 정확한 흐름 테이블 내의 정확한 흐름 엔트리와 상기 특징 정보 사이의 정확한 정합을 수행하고, 상기 정확한 정합이 실패하면, 상기 정확한 흐름 테이블 내의 정확한 흐름 엔트리와 상기 복수 편의 특징 정보 중의 하나 이상의 특징 사이의 와일드카드-매치 정합을 수행하며 - 여기서, 상기 와일드카드-매치 정합 중에 사용되는 하나 이상의 매치 필드에 대응하는 명령을 사용함으로써 결정되는 포워딩 루트는 SDN 제어기가 최종적으로 도달 가능한 루트임 -, 상기 와일드카드-매치 정합이 성공하면, 상기 와일드카드-매치 정합이 성공한 정확한 흐름 엔트리 내의 명령에 따라 상기 패킷을 포워딩하는 단계
    를 포함하는 방법.
14. 제13항에 있어서,
    상기 정확한 정합이 성공하면, 상기 정확한 정합이 성공한 정확한 흐름 엔트리 내의 명령에 따라 포워딩이 수행되는, 방법.
15. 제13항 또는 제14항에 있어서,
    상기 제2 SDN 교환기는 상기 제1 SDN 교환기와 상기 SDN 제어기에 접속되어 SDN 네트워크를 형성하고, 상기 SDN 제어기는 각각의 SDN 교환기와 대역내 통신 방식으로 통신하는, 방법.
16. 제13항 또는 제14항에 있어서,
    상기 패킷은 상기 제1 SDN 교환기와 상기 SDN 제어기 사이에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷이며, 상기 패킷은 상기 제1 SDN 교환기에 의해 송신되고 경로 정보를 수집하기 위해 사용되는 제1 제어 메시지를 반송하기 위해 사용되는 것인, 방법.
17. 소프트웨어 정의 네트워크(software defined network, SDN) 교환기로서,
    상기 SDN 교환기가 제2 SDN 교환기이고, 상기 제2 SDN 교환기가 정확한 흐름 테이블을 저장하며, 상기 정확한 흐름 테이블은 복수의 정확한 흐름 엔트리를 포함하고, 각각의 정확한 흐름 엔트리는 복수의 매치 필드와 상기 복수의 매치 필드에 대응하는 명령을 포함하며, 상기 제2 SDN 교환기는,
    제1 SDN 교환기로부터 송신된 패킷을 수신하도록 구성된 수신 유닛 - 상기 패킷은 하나 이상의 편(piece)의 특징 정보를 포함함 -;
    상기 수신 유닛에 의해 수신된 패킷 내의 상기 특징 정보를 획득하도록 구성된 획득 유닛;
    상기 정확한 흐름 테이블 내의 정확한 흐름 엔트리와 상기 획득 유닛에 의해 획득된 하나 이상의 편의 특징 정보 사이의 정확한 정합을 수행하도록 구성된 정확한 정합 유닛 - 상기 하나 이상의 편의 특징 정보는 상기 정확한 흐름 테이블 내의 정확한 흐름 엔트리 내의 매치 필드에 대응함 -;
    상기 정확한 정합 유닛에 의해 수행되는 정확한 정합이 실패하면, 상기 정확한 흐름 테이블 내의 정확한 흐름 엔트리와 상기 하나 이상의 편의 특징 정보 중의 하나 이상의 특징 사이의 와일드카드-매치 정합을 수행하도록 구성된 와일드카드-매치 정합 유닛 - 여기서, 상기 와일드카드-매치 정합 중에 사용되는 하나 이상의 매치 필드에 대응하는 명령을 사용함으로써 결정되는 포워딩 루트는 SDN 제어기가 최종적으로 도달 가능한 루트임 -; 및
    상기 와일드카드-매치 정합 유닛에 의해 수행되는 와일드카드-매치 정합이 성공하면, 상기 와일드카드-매치 정합이 성공한 정확한 흐름 엔트리 내의 명령에 따라 상기 패킷을 포워딩하도록 구성된 포워딩 유닛
    을 포함하는 소프트웨어 정의 네트워크 교환기.
18. 제17항에 있어서,
    상기 포워딩 유닛은,
    상기 정확한 정합이 성공하면, 상기 정확한 정합이 성공한 정확한 흐름 엔트리 내의 명령에 따라 포워딩을 수행하고;
    상기 와일드카드-매치 정합이 실패하면, 브로드캐스팅을 통해 포워딩을 수행하도록 더 구성되는, 소프트웨어 정의 네트워크 교환기.
19. 제17항 또는 제18항에 있어서,
    상기 제2 SDN 교환기는 상기 제1 SDN 교환기와 상기 SDN 제어기에 접속되어 SDN 네트워크를 형성하고, 상기 SDN 제어기는 각각의 SDN 교환기와 대역내 통신 방식으로 통신하는, 소프트웨어 정의 네트워크 교환기.
20. 제17항 또는 제18항에 있어서,
    상기 패킷은 상기 제1 SDN 교환기와 상기 SDN 제어기 사이에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷이며, 상기 패킷은 상기 제1 SDN 교환기에 의해 송신되고 경로 정보를 수집하기 위해 사용되는 제1 제어 메시지를 반송하기 위해 사용되는 것인, 소프트웨어 정의 네트워크 교환기.
21. 오픈플로우 교환기(OpenFlow Switch, OFS)에 의해 경로 정보를 수집하는 방법으로서,
    상기 방법은 제2 OFS에 적용되고, 상기 제2 OFS는 제1 OFS 및 오픈플로우 제어기(OpenFlow Controller, OFC)에 접속되어 OpenFlow 네트워크를 형성하며, 상기 OFC는 대역내 통신 방식으로 각각의 OFS와 통신하며, 상기 방법은,
    상기 제1 OFS에 의해 송신되고, 경로 정보를 수집하기 위해 사용되며, OpenFlow 프로토콜로 정의되는 OFPT_HELLO 메시지를 수신하는 단계 - 여기서, 상기 OFPT_HELLO 메시지의 본문 필드는 확장된 후에 경로 정보를 반송하기 위해 사용되고, 상기 OFPT_HELLO 메시지는 상기 제1 OFS의 경로 정보를 반송하며, 상기 OFPT_HELLO 메시지는 상기 제1 OFS 및 상기 OFC 사이에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷 내에서 반송됨 -;
    상기 제2 OFS의 경로 정보를 상기 OFPT_HELLO 메시지에 부가하여 갱신된 OFPT_HELLO 메시지를 획득하는 단계; 및
    상기 갱신된 OFPT_HELLO 메시지를 포함하는 최종적으로 갱신된 OFPT_HELLO 메시지를 수신한 후에 상기 OFC가 상기 최종적으로 갱신된 OFPT_HELLO 메시지에 각각의 OFS에 의해 부가된 경로 정보에 따라 상기 제1 OFS와 상기 OFC 사이의 라우팅 경로를 결정하고, 상기 라우팅 경로에 따라 상기 제1 OFS에 정확한 흐름 엔트리를 전달할 수 있도록, 상기 갱신된 OFPT_HELLO 메시지를 상기 OFC에 포워딩하는 단계
    를 포함하는 방법.
22. 제21항에 있어서,
    상기 경로 정보는 상기 OFPT_HELLO 메시지를 송신 또는 수신하는 OFS의 ID, 상기 OFPT_HELLO 메시지를 수신하는데 사용되는 포트 번호, 및 상기 OFPT_HELLO 메시지를 송신하는데 사용되는 포트 번호를 포함하는, 방법.
23. 제21항 또는 제22항에 있어서,
    상기 갱신된 OFPT_HELLO 메시지를 상기 OFC에 포워딩하는 단계는,
    상기 갱신된 OFPT_HELLO 메시지를 상기 OFC에 직접적으로 포워딩하는 단계 - 여기서 상기 최종적으로 갱신된 OFPT_HELLO 메시지가 상기 갱신된 OFPT_HELLO 메시지임 -; 또는
    하나 이상의 다른 OFS를 사용하여 상기 갱신된 OFPT_HELLO 메시지를 상기 OFC에 간접적으로 포워딩하는 단계 - 여기서, 상기 다른 OFS는 수신된 상기 갱신된 OFPT_HELLO 메시지에 경로 정보를 부가하여 상기 최종적으로 갱신된 OFPT_HELLO 메시지를 획득함 - 를 포함하는, 방법.
24. 오픈플로우 교환기(OpenFlow Switch, OFS)로서,
    상기 OFS는 제2 OFS이고, 상기 제2 OFS는 제1 OFS, 오픈플로우 제어기(OpenFlow Controller, OFC), 및 적어도 하나의 다른 OFS에 접속되어 OpenFlow 네트워크를 형성하며, 상기 OFC는 대역내 통신 방식으로 각각의 OFS와 통신하며, 상기 제2 OFS는,
    상기 제1 OFS에 의해 송신되고, 경로 정보를 수집하기 위해 사용되며, OpenFlow 프로토콜로 정의되는 OFPT_HELLO 메시지를 수신하도록 구성된 수신 유닛 - 여기서, 상기 OFPT_HELLO 메시지의 본문 필드는 확장된 후에 경로 정보를 반송하기 위해 사용되고, 상기 OFPT_HELLO 메시지는 상기 제1 OFS의 경로 정보를 반송하며, 상기 OFPT_HELLO 메시지는 상기 제1 OFS 및 상기 OFC 사이에 구축된 신뢰 가능한 접속에 의해 사용되는 프로토콜에 대응하는 패킷 내에서 반송됨 -;
    상기 제2 OFS의 경로 정보를, 상기 수신 유닛에 의해 수신된 상기 OFPT_HELLO 메시지에 부가하여 갱신된 OFPT_HELLO 메시지를 획득하도록 구성된 경로 정보 부가 유닛; 및
    상기 갱신된 OFPT_HELLO 메시지를 포함하는 최종적으로 갱신된 OFPT_HELLO 메시지를 수신한 후에 상기 OFC가 상기 최종적으로 갱신된 OFPT_HELLO 메시지에 각각의 OFS에 의해 부가된 경로 정보에 따라 상기 제1 OFS와 상기 OFC 사이의 라우팅 경로를 결정하고, 상기 라우팅 경로에 따라 상기 제1 OFS에 정확한 흐름 엔트리를 전달할 수 있도록, 상기 경로 정보 부가 유닛이 상기 제2 OFS의 경로 정보를 부가한 갱신된 OFPT_HELLO 메시지를 상기 OFC에 포워딩하도록 구성된 포워딩 유닛
    을 포함하는 오픈플로우 교환기.
25. 제24항에 있어서,
    상기 경로 정보는 상기 OFPT_HELLO 메시지를 송신 또는 수신하는 OFS의 ID, 상기 OFPT_HELLO 메시지를 수신하는데 사용되는 포트 번호, 및 상기 OFPT_HELLO 메시지를 송신하는데 사용되는 포트 번호를 포함하는, 오픈플로우 교환기.
26. 제24항 또는 제25항에 있어서,
    상기 포워딩 유닛은 구체적으로,
    상기 갱신된 OFPT_HELLO 메시지를 상기 OFC에 직접적으로 포워딩하거나 - 여기서 상기 최종적으로 갱신된 OFPT_HELLO 메시지가 상기 갱신된 OFPT_HELLO 메시지임 -; 또는
    하나 이상의 다른 OFS를 사용하여 상기 갱신된 OFPT_HELLO 메시지를 상기 OFC에 간접적으로 포워딩하도록 - 여기서, 상기 다른 OFS는 수신된 상기 갱신된 OFPT_HELLO 메시지에 경로 정보를 부가하여 상기 최종적으로 갱신된 OFPT_HELLO 메시지를 획득함 - 구성되는, 오픈플로우 교환기.

Images