KR101625399B1 - 소프트웨어 정의 네트워크에서의 tcp 연결 제어 방법 및 장치 - Google Patents

소프트웨어 정의 네트워크에서의 tcp 연결 제어 방법 및 장치 Download PDF

Info

Publication number
KR101625399B1
KR101625399B1 KR1020150011887A KR20150011887A KR101625399B1 KR 101625399 B1 KR101625399 B1 KR 101625399B1 KR 1020150011887 A KR1020150011887 A KR 1020150011887A KR 20150011887 A KR20150011887 A KR 20150011887A KR 101625399 B1 KR101625399 B1 KR 101625399B1
Authority
KR
South Korea
Prior art keywords
message
flow
host
tcp
network equipment
Prior art date
Application number
KR1020150011887A
Other languages
English (en)
Inventor
송용주
Original Assignee
아토리서치(주)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 아토리서치(주) filed Critical 아토리서치(주)
Priority to KR1020150011887A priority Critical patent/KR101625399B1/ko
Application granted granted Critical
Publication of KR101625399B1 publication Critical patent/KR101625399B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0695—Management of faults, events, alarms or notifications the faulty arrangement being the maintenance, administration or management system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/19—Flow control; Congestion control at layers above the network layer
    • H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

소프트웨어 정의 네트워크에서의 TCP 연결 제어 방법 및 장치가 개시된다. 본 발명의 일 실시예에 따른 컨트롤러 서버의 TCP 연결 제어 방법은 SDN(소프트웨어 정의 네트워킹) 환경에서 컨트롤러 서버가 양 종단의 TCP연결을 제어하는 방법으로서, a) 장애가 발생한 호스트와 연결된 네트워크 장비로부터 포트 상태 다운 메세지(Port-Status Down Message)를 수신하는 단계; b) 호스트를 도착지(Destination)로 하는 플로우의 존재 여부를 확인하는 단계; c) 플로우가 존재하는 경우, TCP 리셋 메세지(TCP-RST Message)를 생성하고 상기 네트워크 장비로 전송하는 단계; 및 d) 네트워크 장비로부터 TCP 리셋 메세지 유입을 알리는 패킷-인 메세지(Packet-In Message)를 수신하는 경우에는, 호스트를 출발지(Source)로 하고 플로우의 출발지를 도착지로 하여 TCP 리셋 메세지를 전송하도록 규정하는 플로우 수정 메세지(Flow-Mod Message)를 생성하고, 네트워크 장비로 전송하는 단계를 포함한다.

Description

소프트웨어 정의 네트워크에서의 TCP 연결 제어 방법 및 장치{METHOD AND APPARATUS FOR CONTROLLING TCP CONNECTION IN SOFTWARE DEFINED NETWORK}
본 발명은 TCP 연결 제어 방법 및 장치에 관한 것으로, 보다 상세하게는 소프트웨어 정의 네트워크(Software Defined Network)에서 호스트에 장애가 발생하였을 때 이를 원격 감지하여 TCP 연결을 해제하기 위한 TCP 연결 제어 방법 및 장치에 관한 것이다.
SDN(Software Defined Networking, 소프트웨어 정의 네트워킹, 이하 SDN이라 칭함) 기술은 네트워크의 모든 네트워크 장비를 지능화된 중앙관리시스템에 의해 관리하는 기술을 의미한다. SDN 기술에서는 기존 하드웨어 형태의 네트워크 장비에서 자체적으로 수행하는 패킷 처리와 관련된 제어 동작을 소프트웨어 형태로 제공되는 컨트롤러가 대신하여 처리하게 함으로써, 기존의 네트워크 구조보다 다양한 기능을 개발하고 부여할 수 있다는 장점을 갖는다.
한편, 클라이언트/서버 환경이나 분산 시스템 환경 등에 있어서 반대편 노드에 장애가 있는지 확인하는 것은 중요하다. 장애가 발생할 경우 서비스 운영에 상당한 지장이 발생할 뿐더러, 백업 서버 등으로 데이터를 옮겨가거나 클라이언트에 할당했던 자원을 회수 하는 등의 후속 조치가 이루어져야 하기 때문이다. 이는 SDN 기술에서도 마찬가지다.
일반적으로는 통신 시스템의 종류와 상관없이 두 종단 사용자(End User)간에 신뢰성 있는 연결을 위해 TCP/IP(Transmission Control Protocol/Internet Protocol)가 사용된다. 이 때, 양 종단(End to End)의 TCP 연결을 적절히 제어할 필요가 있다. TCP 연결을 제어하지 않는 경우에는 중계 라우터가 고장 나거나, 회선이 다운되더라도 종단 사용자 중 적어도 하나가 재가동되지 않는 한 TCP 연결이 계속 유지되기 때문이다. 이러한 TCP의 불필요한 연결은 시스템의 자원을 낭비하는 요인으로 작용한다.
TCP 연결 제어를 위한 기본적인 방법은 TCP 리셋 패킷(TCP-RST Packet)을 이용하는 것이다. 예컨대 TCP 연결에 있어 어느 한쪽의 노드가 다운되는 경우에는 상기 노드의 운영체제로부터 TCP 리셋 패킷(또는 TCP-FIN 패킷)이 상대 노드로 전송된다. 그리고 상기 TCP 리셋 패킷을 수신한 상대 노드에서는 상대편 노드에 장애가 발생한 것으로 인식해 TCP 연결을 강제로 해제 할 수 있다. 그러나 네트워크 선 자체가 물리적으로 끊기거나 노드의 하드웨어 또는 운영체제에 장애가 발생하는 경우에는, 장애가 발생한 노드에서 TCP 리셋 패킷을 자체적으로 보낼 수가 없어 상대 노드에서는 이를 확인할 방법이 없다는 한계가 있다.
이를 해결하기 위한 옵션으로는 TCP 킵얼라이브(keep-alive)가 이용되는 것이 일반적이다. TCP 킵얼라이브는 미리 정해지는 소정 주기에 따라 TCP 킵얼라이브 프로브 패킷을 상대 노드로 전송하고, 그에 대한 응답으로 TCP ACK(Acknowlegement)가 수신되지 않으면 TCP 연결을 해제하는 옵션이다. 그런데 이러한 TCP 킵얼라이브 옵션은 TCP 연결마다 타이머를 설정해야 하므로, 대형 서버에서는 부담이 크다는 문제가 있다. 그래서 TCP 킵얼라이브 옵션에서 상기 타이머의 주기는 일반적으로 15분 내지 2시간 정도로 설정된다. 즉 TCP 킵얼라이브 옵션을 사용하더라도 장애를 감지하는 데에는 수 분 내지 수십 분이 소요되므로, 초 내지 밀리초(mili-second) 이하의 장애감지는 사실상 어렵다.
본 발명은 SDN(소프트웨어 정의 네트워킹) 환경에서 양 종단에 추가 부하를 주지 않으면서도, 어느 한 쪽 종단의 장애를 초 내지 밀리초 이하로 감지 가능한 TCP 연결 제어 방법 및 장치를 제공하고자 한다.
본 발명의 일 측면에 따르면, SDN(소프트웨어 정의 네트워킹) 환경에서 컨트롤러 서버가 양 종단 호스트의 TCP연결을 제어하는 방법으로서, a) 장애가 발생한 호스트와 연결된 네트워크 장비로부터 포트 상태 다운 메세지(Port-Status Down Message)를 수신하는 단계; b) 상기 호스트를 도착지(Destination)로 하는 플로우의 존재 여부를 확인하는 단계; c) 상기 플로우가 존재하는 경우, TCP 리셋 메세지(TCP-RST Message)를 생성하고 상기 네트워크 장비로 전송하는 단계; 및 d) 상기 네트워크 장비로부터 상기 TCP 리셋 메세지 유입을 알리는 패킷-인 메세지(Packet-In Message)를 수신하는 경우에는, 상기 호스트를 출발지(Source)로 하고 상기 플로우의 출발지를 도착지로 하여 상기 TCP 리셋 메세지를 전송하도록 규정하는 플로우 수정 메세지(Flow-Mod Message)를 생성하고, 상기 네트워크 장비로 전송하는 단계를 포함하는 컨트롤러 서버의 TCP 연결 제어 방법이 제공될 수 있다.
삭제
이 때, 상기 장애는 상기 네트워크 장비와 호스트를 연결하는 네트워크 라인이 파손되거나, 상기 호스트의 하드웨어 또는 운영체제에 장애가 발생하는 것일 수 있다.
또한, 상기 b) 단계 이후, 기 인식된 토폴로지를 수정하고, 상기 플로우의 대체 경로를 연산하는 단계; 및 상기 플로우의 처리를 새로 규정하는 플로우 수정 메세지(Flow-Mod Message)를 생성하고, 상기 대체 경로 상의 네트워크 장비로 상기 플로우 수정 메세지를 전송하는 단계를 더 포함할 수 있다.
본 발명의 다른 측면에 따르면, SDN(소프트웨어 정의 네트워킹) 환경에서 양 종단 호스트의 TCP 연결을 제어하는 컨트롤러 서버로서, 네트워크 장비와 통신하는 통신부; 상기 네트워크 장비에 연결된 호스트에 장애가 발생하는 경우, 상기 호스트를 도착지(Destination)로 하는 플로우의 존재 여부를 확인하고, 상기 플로우가 존재하는 경우에는 TCP 리셋 메세지(TCP-RST Message)를 생성하고 상기 네트워크 장비로 전송하며, 상기 네트워크 장비로부터 상기 TCP 리셋 메세지 유입을 알리는 패킷-인 메세지(Packet-In Message)를 수신하는 경우, 상기 호스트를 출발지로 하고 상기 플로우의 출발지를 도착지로 하여 상기 TCP 리셋 메세지를 전송하도록 규정하는 플로우 수정 메세지를 생성하고 상기 네트워크 장비로 전송하는 제어부를 포함하는 컨트롤러 서버가 제공될 수 있다.
본 발명의 실시예들에 따르면, 컨트롤러 서버는 장애가 발생한 호스트를 도착지로 하는 플로우를 확인하고, 플로우가 존재하는 경우에는 TCP 리셋 메세지를 생성하여 반대편 호스트로 전송하도록 네트워크 장비를 제어함으로써, 양 종단 호스트에 추가 부하를 주지 않으면서도 TCP 연결을 제어할 수 있다.
또한, TCP 킵얼라이브 옵션을 초 단위 내지 밀리초 단위의 주기로 설정할 필요가 없어 시스템에 부담을 주지 않으면서도, 장애가 발생한 호스트를 초 내지 밀리초 이하로 감지하고 조치할 수 있다.
도 1은 소프트웨어 정의 네트워크의 구성을 설명하기 위한 도면이다.
도 2는 본 발명의 일 실시예에 따른 TCP 연결 제어 방법의 순서도이다.
도 3은 도 2의 단계 230 및 단계 270에 관련된 플로우 테이블의 예시를 나타내는 도면이다.
도 4는 도 2의 단계 230 이후, 컨트롤러 서버의 조치를 설명하기 위한 순서도이다.
도 5는 도 2의 컨트롤러 서버의 구성을 설명하기 위한 도면이다.
이하에서는 첨부된 도면을 참조하여 본 발명을 구체적으로 설명한다.
도 1은 소프트웨어 정의 네트워크의 구성을 설명하기 위한 도면이다. 도 1을 참조하면, 소프트웨어 정의 네트워크(Software Defined Network)는 컨트롤러 서버(100), 네트워크 장비(200) 및 호스트(310,320)를 포함할 수 있다. 네트워크 장비(200)와 호스트(310,320)는 노드(Node)라고 지칭할 수 있으며, 링크(Link)는 2개의 노드 사이의 연결을 의미할 수 있다.
컨트롤러 서버(100)는 네트워크 장비(200)를 관리하는 기능을 하는 것으로, 복수의 네트워크 장비(200)를 중앙 집중형으로 관리 및 제어한다. 구체적으로 컨트롤러 서버(100)는 토폴로지 관리(Topology management), 패킷 처리와 관련된 경로 관리(Path management), 링크 디스커버리(Link discovery), 패킷 흐름인 플로우 관리(Flow management) 등의 기능을 하는 소프트웨어가 탑재된 형태로 구현될 수 있다.
네트워크 장비(200)는 컨트롤러 서버(100)의 제어에 따라 패킷을 처리하는 기능을 한다. 네트워크 장비(200)의 예로는 이동 통신 기지국, 기지국 제어기, 게이트웨이 장비, 유선 네트워크의 스위치, 라우터 등이 있다. 다만 설명의 편의를 위해 이하에서는 네트워크 장비(200)가 오픈플로우 스위치인 경우를 중심으로 설명하고, 동일한 도면 부호를 병기하도록 한다.
소프트웨어 정의 네트워크에서 컨트롤러 서버(100)와 오픈플로우 스위치(200)는 상호간 정보를 주고 받아야 하며, 이를 위한 프로토콜로 널리 사용되는 것이 오픈플로우(OpenFlow) 프로토콜이다. 즉, 오픈플로우 프로토콜은 컨트롤러 서버(100)와 오픈플로우 스위치(200)간 서로 통신할 수 있는 표준 규격이다.
보다 구체적으로 설명하면, 오픈플로우 스위치(200)는 크게 소프트웨어 계층과 하드웨어 계층으로 구분된다. 상기 소프트웨어 계층은 보안 채널(Secure Channel)을 통해 컨트롤러 서버(100)와 정보를 교환한다. 상기 보안 채널은 오픈플로우 스위치(200)와 원거리에 위치한 컨트롤러 서버(100) 간 통신 채널이며, 컨트롤러 서버(100)와 오픈플로우 스위치(200)간 교환되는 정보는 암호화된다. 상기 하드웨어 계층에는 패킷을 규정 및 처리하고, 패킷에 관련된 통계 정보를 포함하는 플로우 테이블(Flow table)이 존재한다. 상기 플로우 테이블은 패킷 처리를 규정하는 플로우 룰(Flow Rule)로 구성되며, 상기 플로우 룰은 컨트롤러 서버(100)가 생성하여 오픈플로우 스위치(200)에 전송하는 플로우 모드 메세지(Flow-Mod Message)에 의해 추가, 수정 또는 삭제될 수 있다. 오픈플로우 스위치(200)는 상기 플로우 테이블을 참조하여 패킷을 처리한다.
상기 플로우 테이블은 크게 세 가지 정보, 즉 플로우를 정의하는 패킷 헤더 정보(Rule), 패킷의 처리를 정의하는 동작 정보(Action) 및 플로우별 통계정보(Stats)를 포함할 수 있다. 그리고 플로우 테이블을 이루는 각 행을 플로우 엔트리(Flow Entry)라고 칭한다.
호스트(310,320)는 오픈플로우 스위치(200)의 하위 계층에 해당하는 단말 등을 의미하는 것으로, 클라이언트 및 서버를 통칭하는 의미로 사용될 수 있다. 호스트(310,320)는 소프트웨어 정의 네트워크를 통해 다른 호스트에 보내기 위한 패킷을 생성하고, 상기 패킷을 네트워크 인터페이스의 포트를 통해 오픈플로우 스위치(200)로 전송할 수 있다.
예컨대 제1 호스트(310)가 제2 호스트(320)로 패킷을 보내고자 할 때, 우선 제1 호스트(310)는 보내고자 하는 패킷을 생성하고 상기 패킷을 제1 호스트(310)와 연결된 오픈플로우 스위치(200)로 전송한다. 오픈플로우 스위치(200)에 상기 패킷의 처리를 규정한 플로우 테이블이 존재하는 경우에는, 오픈플로우 스위치(200)가 상기 규정대로 패킷을 처리한다. 그러나 오픈플로우 스위치(200)에 상기 패킷에 관련된 플로우 테이블이 없는 경우에는, 오픈플로우 스위치(200)는 컨트롤러 서버(100)에 패킷 유입을 알리는 패킷-인 메세지(Packet-in Message)를 전송한다. 컨트롤러 서버(100)는 오퍼레이터의 정책이나 미리 설정된 알고리즘에 따라 상기 패킷의 처리를 규정하는 플로우 테이블을 생성하여 오픈플로우 스위치(200)로 전송하고, 오픈플로우 스위치(200)는 상기 플로우 테이블을 수신하고 이에 기반하여 상기 패킷을 처리한다.
제1 호스트(310)가 제2 호스트(320)로 패킷을 보낼 수 있는 경로는 다양할 수 있다. 전체 네트워크에는 복수의 오픈플로우 스위치(200) 및 호스트(320,320)가 존재하고, 이들 각 노드는 또한 복수의 링크를 가지기 때문이다. 이때, 컨트롤러 서버(100)는 전체 네트워크 토폴로지 맵에 기반하여 상기 패킷을 보낼 수 있는 복수개의 경로 중에서 최적 경로를 연산한다. 그리고 컨트롤러 서버(100)는 연산된 최적 경로에 대한 정보를 오픈플로우 스위치(200)에 전송하고, 오픈플로우 스위치(200)는 상기 최적 경로로 패킷을 처리하는 것이 일반적이다.
한편 본 발명과 관련하여, 제2 호스트(320)에 장애가 발생하는 경우가 있을 수 있다. 일반적인 경우에는 제2 호스트(320)에 장애가 발생하여 프로세스가 다운되는 경우에는 제2 호스트(320)의 운영체제는 TCP-FIN 패킷 또는 TCP-RST 패킷을 생성하고 제1 호스트(310)로 전송할 수 있다. 제1 호스트(310)는 상기 TCP-FIN 패킷 또는 TCP-RST 패킷을 수신함으로써, 제2 호스트(320)에 장애가 발생한 것을 감지할 수 있다. 따라서 제1 호스트(310)는 불필요한 TCP 연결을 방지하기 위해 제2 호스트(320)와의 TCP 연결을 해제할 수 있다.
문제는 제2 호스트(320)가 TCP-FIN 패킷 또는 TCP-RST 패킷을 제1 호스트(310)로 전송할 수 없는 경우다. 예컨대 제2 호스트(320)의 네트워크 선이 끊어지거나, 제2 호스트(320)의 운영체제 등에 장애가 생긴 경우다. 이 경우에는 제1 호스트(310)에서는 제2 호스트(320)에 장애가 발생한 것을 감지할 수 없다. 제2 호스트(320)로부터 TCP-FIN 패킷 또는 TCP-RST 패킷을 전송 받지 못해서다. 그러므로 제1 호스트(310) 및 제2 호스트(320) 간 TCP 연결은 불필요하게 계속 유지되며, 시스템 자원을 낭비하는 요인이 된다.
이하, 본 발명의 실시예들에 따른 TCP 연결 제어 방법을 설명한다.
도 2는 본 발명의 일 실시예에 따른 TCP 연결 제어 방법의 순서도이다. 도 2에서는 양 종단 노드로 제1 호스트(310), 제2 호스트(320)를 예시하고 있으며, 제2 호스트(320)에서 TCP 리셋 패킷(TCP-RST)을 제1 호스트(310)로 전송할 수 없는 장애가 발생한 경우를 상정한다. 예를 들면 상기 장애는 네트워크 장비와 호스트를 연결하는 네트워크 라인이 파손되거나, 호스트의 하드웨어 또는 운영체제에 장애가 발생하는 것이며, 그 이외에도 제2 호스트(320)가 TCP 리셋 패킷(TCP-RST) 또는 TCP-FIN 패킷을 보낼 수 없는 장애라면 모두 해당될 수 있다.
단계 210에서 제2 호스트(320)에 상기와 같은 장애가 발생하면 제2 호스트(320)가 연결된 오픈플로우 스위치(200A, 도 1 참고)는 이를 즉각 인지할 수 있다. 오픈플로우 스위치(200A)는 제2 호스트(320)와 연결되는 포트(Port)가 존재하며, 제2 호스트(320)에 상기 장애가 발생하였을 경우에는 상기 포트가 다운되기 때문이다. 그러나 단계 210에서는 제1 호스트(310)가 제2 호스트(320)의 장애를 감지하지 못한다.
단계 220에서 오픈플로우 스위치(200A)는 포트 상태 다운 메세지(Port-Status Down Message)를 생성하여 컨트롤러 서버(100)로 전송할 수 있다. 일반적으로 오픈플로우 스위치는 컨트롤러 서버에 인터페이스의 업/다운(Up/Down) 이벤트를 알리기 위해 포트 상태 메세지(Port-Status Message)를 전송할 수 있다. 상기 포트 상태 메세지는 오픈플로우 스위치의 IP를 출발지(Source)로 컨트롤러 서버의 IP를 도착지(Destination)으로 하는 것으로, 상기 오픈플로우 스위치에서 생성된다. 상기 포트 상태 메세지는 본 메세지를 전달하는 이유에 대한 정보, 해당 포트 번호, MAC 어드레스 정보 등을 포함한다. 컨트롤러 서버(100)는 단계 220에서 오픈플로우 스위치(200A)로부터 포트 상태 다운 메세지를 수신하고, 제2 호스트(320)의 장애를 감지할 수 있다.
단계 230에서 컨트롤러 서버(100)는 제2 호스트(320)를 도착지로 하는 플로우(Flow)가 존재하는지를 확인할 수 있다. 여기에서 플로우(또는 패킷 플로우)는 동일한 목적지(도착지)로 전송되는 패킷들의 흐름으로 정의될 수 있다. 상기 확인은 컨트롤러 서버(100)가 오픈플로우 스위치(200A)의 플로우 테이블(Flow Table)을 확인함으로써 수행 될 수 있다. 앞서 설명한 것과 같이 오픈플로우 스위치의 하드웨어 계층에는 패킷을 규정 및 처리하고, 패킷에 관련된 통계 정보를 포함하는 플로우 테이블이 존재하기 때문이다.
관련하여, 도 3a는 도 2의 단계 230에 관련된 플로우 테이블의 예시를 나타내는 도면이다. 도 3a를 참조하면, 오픈플로우 스위치(200A)에 존재하는 플로우 테이블은 해당 플로우의 출발지 IP 정보(IP Src), 도착지 IP 정보(IP Dsc) 및 상기 플로우의 처리 정보(Action)를 포함할 수 있다. 물론 플로우 테이블에는 상기 언급한 정보들 이외에도 많은 정보들(예컨대, Switch port, MAC src, MAC dst, Count 등)이 존재하나 이들 정보들은 공지의 것으로 구체적인 설명은 생략하도록 한다. 도 3a에 도시된 플로우 룰은 도착지 IP가 제2 호스트(320)인 패킷을 1번 포트(port)로 전송하라는 의미이며, 이를 통해 컨트롤러 서버(100)는 장애가 발생한 제2 호스트(320)를 도착지로 하는 플로우가 존재하고 있음을 인지할 수 있다. 그리고 출발지 IP 정보를 통해 상기 플로우의 출발지가 제1 호스트(310)임을 인지할 수 있다. 이 경우, 제1 호스트(310)에게 제2 호스트(320)에 장애가 발생했음을 인지시켜 줄 필요가 있다.
반면, 도 3a에 도시된 것과는 달리 도착지 IP가 제2 호스트(320)인 플로우 룰이 존재하지 않는 경우에는, 제2 호스트(320)를 도착지로 하는 플로우가 존재하지 않는다는 의미다. 이 경우에는 제2 호스트(320)에 장애가 발생하더라도 문제가 되지 않으므로 컨트롤러 서버(100)는 다른 포트 상태 다운 메세지가 올 때까지 대기할 수 있다.
다시 도 2를 참조하면, 단계 230에서 제2 호스트(320)를 도착지로 하는 플로우가 존재함을 확인한 경우, 단계 240에서 컨트롤러 서버(100)는 TCP 리셋 메세지(TCP-RST Message)를 생성할 수 있다. 상기 TCP 리셋 메세지는 상술한 것처럼 장애가 발생한 노드에서 상대편 노드로 전송하는 메세지로, 상기 상대편 노드는 TCP 리셋 메세지를 받으면 장애가 발생한 노드와의 TCP 연결을 강제로 해제할 수 있다. 상기 TCP 리셋 메세지의 생성을 위해서는 src MAC, dst MAC, protocol, src IP, dst IP, src Port, dst Port의 7개 정보가 필요할 수 있다. 상기 7개 정보를 얻기 위해서 컨트롤러 서버(100)는 오픈플로우 스위치(200A)에 존재하는 플로우 테이블을 참조하거나, 컨트롤러 서버(100)에 내장되어 있는 정보를 참조할 수 있다.
단계 250에서 컨트롤러 서버(100)는 단계 240에서 생성한 TCP 리셋 메세지를 오픈플로우 스위치(200A)로 전송할 수 있다. 이 때, 도 2에 도시되지는 않았으나, 오픈플로우 스위치(200A)에 존재하는 플로우 테이블에 TCP 리셋 메세지가 규정되어 있지 않은 경우에는, 오픈플로우 스위치(200A)는 컨트롤러 서버(100)에 패킷 유입을 알리는 패킷-인 메세지(Packet-In Message)를 전송할 수 있다.
단계 260에서 컨트롤러 서버(100)는 단계 250에서 오픈플로우 스위치(200A)가 상기 TCP 리셋 메세지의 유입을 알리는 상기 패킷-인 메세지를 전송하는 경우에 한해, 상기 TCP 리셋 메세지의 처리를 규정한 플로우 수정 메세지(Flow-Mod Message, Flow Modification Message)를 생성할 수 있다. 상기 플로우 수정 메세지는 컨트롤러 서버(100)가 오픈플로우 스위치(200)에 존재하는 플로우 테이블의 플로우 룰을 추가,수정 또는 삭제하는 것과 관련된 명령을 내리는 메세지를 의미한다.
만약, 단계 250에서 컨트롤러 서버(100)가 TCP 리셋 메세지를 오픈플로우 스위치(200A)로 전송하였을 때, 오픈플로우 스위치(200A)에 존재하는 플로우 테이블에 상기 TCP 리셋 메세지가 규정되어 있는 경우에는 단계 260은 생략될 수 있다.
한편, 컨트롤러 서버(100)가 상기 플로우 수정 메세지를 생성함에 있어서,컨트롤러 서버(100)는 제2 호스트(320)를 출발지(Source)로 하고, 제1 호스트(310)를 도착지(Destination)로 하여 상기 TCP 리셋 메세지를 전송하도록 규정하는 플로우 수정 메세지를 생성할 수 있다. 그리고 단계 270에서 컨트롤러 서버(100)는 상기 플로우 수정 메세지를 오픈플로우 스위치(200A)에 전송할 수 있다. 단계 260과 마찬가지로, 단계 250에서 컨트롤러 서버(100)가 TCP 리셋 메세지를 오픈플로우 스위치(200A)로 전송하였을 때, 오픈플로우 스위치(200A)에 존재하는 플로우 테이블에 상기 TCP 리셋 메세지가 규정되어 있는 경우에는 단계 270은 생략될 수 있다.
단계 280에서 오픈플로우 스위치(200A)는 상기 TCP 리셋 메세지에 대해 미리 규정된 플로우 테이블을 참조하거나, 단계 270에서 수신한 플로우 모드 메세지에 의해 변경된 플로우 테이블을 참조하여 상기 TCP 리셋 메세지를 처리할 수 있다. 관련하여, 도 3b는 오픈플로우 스위치(200A)가 도 2의 단계 270에서 수신한 플로우 모드 메세지에 의해 변경된 플로우 테이블을 나타낸다. 도 3b에 도시된 플로우 룰은 도착지 IP가 제1 호스트(310)인 패킷을 2번 포트(port)로 전송하라는 의미이며, 이에 따라 오픈플로우 스위치(200A)는 상기 TCP 리셋 메세지를 제1 호스트(310)로 전송할 수 있다. 이 때, 상기 TCP 리셋 메세지의 출발지 IP는 제2 호스트(320)로 지정되어 있으므로 제1 호스트(310)는 상기 TCP 리셋 메세지의 수신시 제2 호스트(320)가 전송한 것으로 인식할 수 있다.
다시 도 2를 참고하면, 단계 290에서 제1 호스트(310)는 단계 280에서 상기 TCP 리셋 메세지를 수신하고, 제2 호스트(320)에 장애가 발생하였음을 인지할 수 있다. 그리고 TCP 리셋 메세지를 수신하였으므로, 제1 호스트(310)는 제2 호스트(320)와의 TCP 연결을 해제할 수 있다.
상술한 바와 같이, 본 발명의 실시예들에 있어서 컨트롤러 서버(100)는 장애가 발생한 제2 호스트(320)를 도착지로 하는 플로우를 확인한 후, 플로우가 존재하면 TCP 리셋 메세지를 생성하여 반대편 종단인 제1 호스트(310)로 전송하도록 오픈플로우 스위치(200A)를 제어하게 된다. 이 때, 제1,2 호스트(310,320)에는 어떠한 수정도 가해지지 않는 바, 양 종단 호스트에 추가 부하를 주지 않으면서도 TCP 연결을 제어할 수 있다.
또한, TCP 킵얼라이브(keep-alive) 옵션을 초 단위 내지 밀리초 단위의 주기로 설정할 필요가 없어 시스템에 부담을 주지 않으면서도, 장애가 발생한 호스트를 초 내지 밀리초 이하로 감지하고 조치할 수 있다.
도 4는 도 2의 단계 230 이후, 컨트롤러 서버(100)의 조치를 설명하기 위한 순서도이다. 설명의 편의를 위해, 이하에서는 앞서 설명한 구성과 동일 구성에 대해서는 동일한 부호를 병기하기로 한다.
상술한 도 2에 대한 설명은, 제2 호스트(320)에 장애가 발생하였을 때 컨트롤러 서버(100)가 제2 호스트(320)의 장애를 반대편 종단인 제1 호스트(310)에게 알림으로써, 제1 호스트(310)가 제2 호스트(320)와의 TCP 연결을 해제할 수 있도록 한 것에 관한 것이다. 이 때, 제1 호스트(310)에 TCP 리셋 메세지를 보내는 것과는 별도로 제2 호스트(320)를 도착지로 하는 플로우에 대해서는 플로우 룰을 변경할 필요가 있다.
도 4를 참조하면, 단계 310에서 장애가 발생한 제2 호스트(320)와 연결된오픈플로우 스위치(200A)는 포트 상태 다운 메세지(Port-Status Down Message)를 생성하여 컨트롤러 서버(100)로 전송할 수 있다. 이는 도 2의 단계 210,220과 동일하므로 중복 설명은 생략한다.
단계 320에서 컨트롤러 서버(100)는 제2 호스트(320)를 도착지로 하는 플로우(Flow)가 존재하는지를 확인할 수 있다. 마찬가지로 도 2의 단계 230과 동일하므로 중복 설명은 생략한다. 확인 결과, 제2 호스트(320)를 도착지로 하는 플로우가 존재하지 않으면 크게 문제 되지 않으므로 컨트롤러 서버(100)는 다른 포트 상태 다운 메세지가 올 때까지 대기할 수 있다. 반면, 제2 호스트(320)를 도착지로 하는 플로우가 존재하면 컨트롤러 서버(100)는 상기 플로우에 관련된 플로우 룰을 변경해야 할 필요성이 있다.
이를 위해 단계 330에서 컨트롤러 서버(100)는 네트워크 토폴로지를 수정하고, 제2 호스트(320)를 도착지로 하는 플로우들의 대체경로를 연산할 수 있다. 그리고 단계 340에서 컨트롤러 서버(100)는 제2 호스트(320)를 도착지로 하는 플로우들이 상기 대체경로를 통해 다른 도착지 호스트로 전송되도록 패킷의 처리를 규정한 플로우 수정 메세지를 생성하고, 상기 플로우 모드 메세지를를 상기 대체 경로 상의 오픈플로우 스위치(200)로 전송할 수 있다. 단계 320 및 330은 도 2에서의 단계 240 내지 270과 병행하여 이루어질 수 있다.
도 5는 도 2의 컨트롤러 서버(100)의 구성을 설명하기 위한 도면이다. 도 5를 참고하면, 컨트롤러 서버(100)는 통신부(110) 및 제어부(120)를 포함할 수 있으며, 입력부(미도시), 표시부(미도시)를 더 포함할 수 있다. 한편, 통신부(110) 및 제어부(130)는 물리적으로 분리되어 존재할 수도 있다.
통신부(110)는 컨트롤러 서버(100)의 유무선 통신을 위한 데이터의 송수신 기능을 수행한다. 구체적으로 통신부(110)는 네트워크 장비인 오픈플로우 스위치(200)와 통신하는 역할을 수행한다. 이 때 사용되는 프로토콜이 오픈플로우(OpenFlow) 프로토콜일 수 있다.
제어부(120)는 컨트롤러 서버(100)의 전반적인 기능을 제어한다. 특히 본 발명의 실시예에서 제어부(120)는 오픈플로우 스위치(200)에 연결된 호스트에 장애가 발생하는 경우, 상기 호스트를 도착지(Destination)로 하는 플로우의 존재 여부를 확인하고, 상기 플로우가 존재하는 경우에는 TCP 리셋 메세지(TCP-RST Message)를 생성하고 오픈플로우 스위치(200)로 전송하는 기능을 할 수 있다.
또한, 이와 병행하여 제어부(120)는 상기 플로우가 존재하는 경우 상기 플로우의 대체 경로를 연산하고, 상기 플로우의 처리를 새로 규정하는 플로우 수정 메세지를 생성하고, 상기 대체 경로 상의 오픈플로우 스위치로 전송하는 기능을 할 수 있다.
그 외에도 제어부(120)는 도 2 및 도 4에서 설명한 컨트롤러 서버(100)가 하는 역할들을 모두 수행할 수 있도록 기능할 수 있으며, 이에 대해서는 앞에서 설명하였으므로 중복 설명은 생략하기로 한다.
이상, 본 발명의 실시예들에 대하여 설명하였다. 그러나 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자라면 특허청구범위에 기재된 본 발명의 기술적 사상의 범위 내에서 기술의 구체적 적용에 따른 단순한 설계변경, 일부 구성요소의 생략, 단순한 용도의 변경 등 본 발명을 다양하게 변형할 수 있을 것이며, 이러한 변형 역시 본 발명의 권리범위 내에 포함됨은 자명하다.
100: 컨트롤러 서버
110: 통신부
120: 제어부
200, 200A: 오픈플로우 스위치
310: 제1 호스트
320: 제2 호스트

Claims (8)

  1. SDN(소프트웨어 정의 네트워킹) 환경에서 컨트롤러 서버가 양 종단 호스트의 TCP 연결을 제어하는 방법으로서,
    a) 장애가 발생한 호스트와 연결된 네트워크 장비로부터 포트 상태 다운 메세지(Port-Status Down Message)를 수신하는 단계;
    b) 상기 호스트를 도착지(Destination)로 하는 플로우의 존재 여부를 확인하는 단계;
    c) 상기 플로우가 존재하는 경우, TCP 리셋 메세지(TCP-RST Message)를 생성하고 상기 네트워크 장비로 전송하는 단계; 및
    d) 상기 네트워크 장비로부터 상기 TCP 리셋 메세지 유입을 알리는 패킷-인 메세지(Packet-In Message)를 수신하는 경우에는, 상기 호스트를 출발지(Source)로 하고 상기 플로우의 출발지를 도착지로 하여 상기 TCP 리셋 메세지를 전송하도록 규정하는 플로우 수정 메세지(Flow-Mod Message)를 생성하고, 상기 네트워크 장비로 전송하는 단계를 포함하는 컨트롤러 서버의 TCP 연결 제어 방법.
  2. 삭제
  3. 청구항 1에 있어서,
    상기 장애는 상기 네트워크 장비와 호스트를 연결하는 네트워크 라인이 파손되거나, 상기 호스트의 하드웨어 또는 운영체제에 장애가 발생하는 것인 컨트롤러 서버의 TCP 연결 제어 방법.
  4. 청구항 1에 있어서,
    상기 b) 단계 이후,
    기 인식된 토폴로지를 수정하고, 상기 플로우의 대체 경로를 연산하는 단계; 및
    상기 플로우의 처리를 새로 규정하는 플로우 수정 메세지(Flow-Mod Message)를 생성하고, 상기 대체 경로 상의 네트워크 장비로 상기 플로우 수정 메세지를 전송하는 단계를 더 포함하는 컨트롤러 서버의 TCP 연결 제어 방법.
  5. SDN(소프트웨어 정의 네트워킹) 환경에서 양 종단 호스트의 TCP 연결을 제어하는 컨트롤러 서버로서,
    네트워크 장비와 통신하는 통신부;
    상기 네트워크 장비에 연결된 호스트에 장애가 발생하는 경우, 상기 호스트를 도착지(Destination)로 하는 플로우의 존재 여부를 확인하고, 상기 플로우가 존재하는 경우에는 TCP 리셋 메세지(TCP-RST Message)를 생성하고 상기 네트워크 장비로 전송하며, 상기 네트워크 장비로부터 상기 TCP 리셋 메세지 유입을 알리는 패킷-인 메세지(Packet-In Message)를 수신하는 경우, 상기 호스트를 출발지로 하고 상기 플로우의 출발지를 도착지로 하여 상기 TCP 리셋 메세지를 전송하도록 규정하는 플로우 수정 메세지를 생성하고 상기 네트워크 장비로 전송하는 제어부를 포함하는 컨트롤러 서버.
  6. 청구항 5에 있어서,
    상기 장애는 상기 네트워크 장비와 호스트를 연결하는 네트워크 라인이 파손되거나, 상기 호스트의 하드웨어 또는 운영체제에 장애가 발생하는 것인 컨트롤러 서버.
  7. 삭제
  8. 청구항 5에 있어서,
    상기 제어부는 상기 플로우가 존재하는 경우 상기 플로우의 대체 경로를 연산하고, 상기 플로우의 처리를 새로 규정하는 플로우 수정 메세지를 생성하고, 상기 대체 경로 상의 네트워크 장비로 전송하는 컨트롤러 서버.
KR1020150011887A 2015-01-26 2015-01-26 소프트웨어 정의 네트워크에서의 tcp 연결 제어 방법 및 장치 KR101625399B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020150011887A KR101625399B1 (ko) 2015-01-26 2015-01-26 소프트웨어 정의 네트워크에서의 tcp 연결 제어 방법 및 장치

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020150011887A KR101625399B1 (ko) 2015-01-26 2015-01-26 소프트웨어 정의 네트워크에서의 tcp 연결 제어 방법 및 장치

Publications (1)

Publication Number Publication Date
KR101625399B1 true KR101625399B1 (ko) 2016-05-30

Family

ID=57124754

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020150011887A KR101625399B1 (ko) 2015-01-26 2015-01-26 소프트웨어 정의 네트워크에서의 tcp 연결 제어 방법 및 장치

Country Status (1)

Country Link
KR (1) KR101625399B1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020111456A1 (ko) * 2018-11-26 2020-06-04 숭실대학교산학협력단 Sdn 네트워크의 tcp 세션 생성 방법 및 그 방법이 적용된 sdn 네트워크
KR102344263B1 (ko) * 2021-10-14 2021-12-29 한화시스템(주) 망 순간 단절 상황에서의 dds 안정성 유지 장치 및 그 방법

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101453758B1 (ko) * 2013-05-07 2014-10-22 한국산업기술대학교산학협력단 네트워크 장애 발생에 대비한 네트워크 운용방법

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101453758B1 (ko) * 2013-05-07 2014-10-22 한국산업기술대학교산학협력단 네트워크 장애 발생에 대비한 네트워크 운용방법

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020111456A1 (ko) * 2018-11-26 2020-06-04 숭실대학교산학협력단 Sdn 네트워크의 tcp 세션 생성 방법 및 그 방법이 적용된 sdn 네트워크
KR102344263B1 (ko) * 2021-10-14 2021-12-29 한화시스템(주) 망 순간 단절 상황에서의 dds 안정성 유지 장치 및 그 방법

Similar Documents

Publication Publication Date Title
CN108141376B (zh) 网络节点、通信网络及通信网络中的方法
US10044830B2 (en) Information system, control apparatus, method of providing virtual network, and program
EP1675356B1 (en) Notification of failures in a trunk network
US9628324B2 (en) Openflow switch and failure recovery method in openflow network
EP2696542A1 (en) Method, ToR switch, and system for implementing protection switchover based on TRILL network
KR20140072343A (ko) Ｓｄｎ 망의 장애 대처 방법
US7974188B2 (en) Repeater and communication method
US20160080424A1 (en) Apparatus and method for reestablishing a security association used for communication between communication devices
JP2015012531A (ja) 通信システム、通信ノード、通信経路切替方法及びプログラム
KR101658824B1 (ko) 소프트웨어 정의 네트워크에서 플로우 룰을 변경하는 방법, 장치 및 컴퓨터 프로그램
CN103490951A (zh) 基于bfd的多跳链路中双向转发检测方法
US8060628B2 (en) Technique for realizing high reliability in inter-application communication
KR101625399B1 (ko) 소프트웨어 정의 네트워크에서의 tcp 연결 제어 방법 및 장치
EP2671348B1 (en) System and method for providing communication connection resilience
KR101610031B1 (ko) 소프트웨어 정의 네트워크에서 컨트롤러를 내장하는 오픈플로우 스위치의 제어방법 및 장치
JP5983733B2 (ja) 通信システム、制御装置、通信装置、情報中継方法及びプログラム
JP5558436B2 (ja) ネットワークシステムおよびネットワーク故障回避方法
KR101589384B1 (ko) Bgp 라우팅에 대한 장애 처리 방법
KR101587332B1 (ko) 컨트롤러와 네트워크 장치 간 연결 상태 확인 방법
JP5518771B2 (ja) 冗長ネットワークシステム、終端装置及び中継点隣接装置
JP5183689B2 (ja) 無線通信システム，無線通信装置及び無線通信方法
KR101969304B1 (ko) 패킷-아웃 메시지를 이용한 소프트웨어 정의 네트워킹 환경에서의 장애 처리 방법 및 컴퓨터 프로그램
EP2725738A1 (en) Method, device and system for transmitting data streams
KR101906437B1 (ko) 네트워크 보안 정책을 테스트하는 방법, 장치 및 컴퓨터 프로그램
KR101931543B1 (ko) 플로우-모드 메시지를 이용한 소프트웨어 정의 네트워킹 환경에서의 장애 처리 방법 및 컴퓨터 프로그램

Legal Events

Date Code Title Description
AMND Amendment
E601 Decision to refuse application
AMND Amendment
X701 Decision to grant (after re-examination)
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20190507

Year of fee payment: 4