KR20230103044A

KR20230103044A - 터널 Ctrl 쓰레드를 이용한 데이터 통신에서의 터널 데이터 업데이트 처리방법

Info

Publication number: KR20230103044A
Application number: KR1020210193622A
Authority: KR
Inventors: 김종오; 이승우; 이상주
Original assignee: 주식회사 에프아이시스
Priority date: 2021-12-31
Filing date: 2021-12-31
Publication date: 2023-07-07

Abstract

본 발명은 데이터 통신에서의 터널 데이터 업데이트 처리방법에 관한 것이다. 본 발명은 패킷(packet)을 입력시키는 단계와 입력된 패킷에 에더넷(Ethernet) 헤더를 파싱(parsing)하는 단계와 기 패킷이 IP 패킷인지 여부를 확인하고, IP 패킷임이 확인되면 IP 헤더를 파싱(parsing)시키는 단계와 소스 IP의 대역이 터널 테이블에서 확인하여, 적절하면 터널 UDP(User Datagram Protocol) 헤더를 파싱시키는 단계와 터널 소스 포트와 터널 목적지 포트 여부를 터널 테이블에서 확인하는 단계와 상기 단계에서 확인되면, 등록된 터널 페킷으로 인증하는 단계와 상기 단계에서 등록된 터널 페킷이 데이터 페킷인지 여부를 확인하는 단계와 상기 단계에서 데이터 페킷이 확인되면 터널 헤더를 제거하고, 새로운 터널 헤더를 입히는 단계와 Statics를 업데이트하여 포트를 확인하는 단계와 터널 데이터를 네트워크로 전송시키는 단계를 포함하는 것을 특징으로 하는 것이다.

Description

터널 Ctrl 쓰레드를 이용한 데이터 통신에서의 터널 데이터 업데이트 처리방법{Tunnel data update method of data communication using tunnel Control thread}

본 발명은 터널 Ctrl 쓰레드를 이용한 데이터 통신에서의 터널 데이터 업데이트 처리방법에 관한 것으로, 더욱 자세하게는 많은 세션을 수월하게 처리하기 위한 터널 Ctrl 쓰레드를 이용한 터널 데이터 업데이트 처리 방법에 관한 것이다.

SDN/NFV, vEPC, IoT의 클라우드화 등 클라우드 기반 솔루션이 늘어남에 따라 데이터센터의 서버는 고성능 가상화 서버의 형태로 변화하고 있으며, 서버는 단일 서비스만을 제공하지 않으며, 다양하고 복합적인 서비스를 제공한다.

예를 들어, 하나의 서버에 여러 개의 웹 서버가 동작할 수 있고, 그와 동시에 보안 서버, 인증 서버 등의 기능이 동시에 수행될 수 있으며, 이는 서버에 추가되고 삭제되는 기능에 따라 소프트웨어 적으로 변경된다. 즉, 서버로 유입되는 패킷의 유형은 서버의 테넌트에 따라 다양해질 수 있다.

네트워크로부터 처음 패킷을 수신하는 부분은 NIC(Network Interface Card)이다. SDN/NFV 및 Cloud 컴퓨팅 기술의 발전에 따라, NIC 또한 40G, 100G 등으로 고속화, 대용량화 되어 가고 있는 추세로, 멀티 코어 기반의 전용 네트워크 프로세스를 사용한 NIC을 사용함으로써 고성능화를 하는 것이 하나의 대안으로 고려되고 있다.

하지만, 기존 멀티 코어 기반 NIC의 버퍼 할당 및 관리는 초기 프로그램 실행 시, 사전에 사용자에 또는 서비스에 의해 요구된 버퍼 설정 정보로 고정시켜 실행한다.

상기의 이유로 고정된 버퍼 할당 상태에서 유동적인 서버의 기능 추가 및 변경은 그에 최적화되지 못한 버퍼 자원 사용으로 버퍼 사용 측면과 패킷 프로세싱 측면에서 효율성을 감소시킨다.

또한, 캡슐화된 패킷으로 구성된 페이로드의 두 노드간의 전달 경로인 터널의 업데이트화가 제대로 이루어지지 않아 데이터 패킷의 소모가 심하다는 단점도 있었다.

최근에는 이러한 데이터 통신에서의 터널 업데이트 방법으로 터널 CTRL 쓰레드를 이용한 터널 업데이트 방법이 부각되고 있다.

대한민국 특허등록 제10-0785812호 대한민국 특허공개 제10-2017-0111455호 대한민국 특허공개 제10-2015-0081497호

따라서, 본 발명은 Tunnel 연결에 대한 설정을 하거나, Tunnel 세션을 통해 명령이 도착하였을 때, 명령 메시지를 읽어 명령 버퍼에 넣는 부분까지 Tunnel CTRL 쓰레드를 수행하는 것을 목적으로 하는 터널 CTRL 쓰레드를 이용한 데이터 통신에서의 터널 데이터 업데이트 처리방법을 제공할 수 있는 것을 목적으로 한다.

또한, 터널 CTRL 서브 쓰레드를 이용하여 터널 테이블에서의 업무 과부하를 대폭 줄일수 있는 터널 CTRL 쓰레드를 이용한 데이터 통신에서의 터널 데이터 업데이트 처리방법을 제공할 수 있는 것을 목적으로 한다.

이러한 문제를 해결하기 위하여 본 발명은 패킷(packet)을 입력시키는 단계와 입력된 패킷에 에더넷(Ethernet) 헤더를 파싱(parsing)하는 단계와 기 패킷이 IP 패킷인지 여부를 확인하고, IP 패킷임이 확인되면 IP 헤더를 파싱(parsing)시키는 단계와 소스 IP의 대역이 터널 테이블에서 확인하여, 적절하면 터널 UDP(User Datagram Protocol) 헤더를 파싱시키는 단계와 터널 소스 포트와 터널 목적지 포트 여부를 터널 테이블에서 확인하는 단계와 상기 단계에서 확인되면, 등록된 터널 페킷으로 인증하는 단계와 상기 단계에서 등록된 터널 페킷이 데이터 페킷인지 여부를 확인하는 단계와 상기 단계에서 데이터 페킷이 확인되면 터널 헤더를 제거하고, 새로운 터널 헤더를 입히는 단계와 Statics를 업데이트하여 포트를 확인하는 단계와 터널 데이터를 네트워크로 전송시키는 단계를 포함하는 것을 특징으로 하는 것이다.

그리고, 상기 단계에서는 상기 IP 페킷을 스마트 NIC를 통하여 수신받는 단계와 상기 터널 Ctrl 쓰레드 이용하여 상기 IP 페킷의 데이터를 로드 밸런싱(Load-balancing)을 하기 위한 분배하는 단계와 상기 데이터와 command 풀의 data가 Queue 데이터풀로 합쳐지는 단계와 상기 단계에서 합쳐진 데이터를 다수개의 터널 Ctrl 서브 쓰레드로 전달하는 S 3-4를 포함하는 것을 특징으로 한다.

그리고, 상기 단계에서는 상기 IP 패킷이 터널 구성 에이전트(Tunnel Configuration Agent)를 통하여 터널링 룰을 형성하여, 패킷 프로세싱 알고리즘에 따라 상기 터널 테이블에 등록되어 있으면 UDP 터널링 패킷으로 변경시키고, 등록되어 있지 않으면 호스트로 처리하는 것을 특징으로 한다.

그리고, 상기 단계에서 Statics는 터널링되는 패킷의 갯수인 것을 특징으로 하는 것이다.

또한, 데이터 통신에서의 터널 데이터 업데이트 프로세싱 시스템에 있어서, 도커(Docker)를 이용한 가상머신으로 동작하는 다수개의 터널 구성 에이전트( Tunnel Configuration Agent)와 Statics 쓰레드를 통한 터널링된 패킷에 대한 통계를 내어 전달하는 Statics 모니터를 포함하여 이루어지며, 애플리케이션이 동작하는 유저 스페이스와 터널 테이블과 터널링되는 패킷에 대한 통계를 내어 상기 Statics 모니터로 전달하는 Statics 쓰레드와 상기 유저 스페이스를 연결하는 pci 쓰레드와 터널 헤드를 결합 또는 제거시키는 엔캡/ 디캡 쓰레드를 포함하여 이루어지며, IP-UDP 터널링 기능을 오프로드시키는 스마트 NIC과 상기 유저 스페이스와 상기 스마트 NIC 사이에 형성되어 시스템 드라이브를 실행하기 위한 kernel 스페이스를 포함하는 것을 특징으로 하는 것이다.

또한, 상기 유저 스페이스의 터널 구성 에이전트에서 터널 설정을 입력하면, 상기 스마트 NIC의 터널 테이블에서 터널 설정을 완료하는 것을 특징으로 하는 것이다.

따라서, 본 발명은 터널 CTRL 쓰레드가 터널 세션을 관리하는 서버의 역할을 수행하여 터널 세션을 통해서 명령이 도착하였을 때, 명령 메시지를 읽어 명령 버퍼에 넣는 부분까지 터널 CTRL 쓰레드에서 수행할수 있도록 하여 작업을 나누어 실행할 수 있는 효과가 있는 것이다.

도 1은 본 발명에 의한 터널 Ctrl 쓰레드를 이용한 데이터 통신에서의 터널 데이터 업데이트 처리방법의 흐름도.
도 2는 터널 Ctrl 쓰레드를 이용하여 터널 Ctrl 서브 쓰레드로 데이터를 전달하는 과정의 흐름도.
도 3은 터널 Ctrl 쓰레드를 이용하여 터널 Ctrl 서브 쓰레드에 데이터의 전송 및 분배를 하는 것을 나타낸 도면.
도 4는 터널 테이블의 도면.
도 5는 터널 테이블의 등록을 확인하여, IP- UDP 터널링 패킷으로 변형시키는 과정을 나타낸 도면.
도 6은 데이터 통신에서의 터널 데이터 업데이트 프로세스 시스템의 블록도.
도 7a는 add 터널 요청 명령 메시지 테이블의 도면.
도 7b는 del 터널 요청 명령 메시지의 도면.
도 8은 스마트 NIC의 프로그램 구조의 사진.
도 9는 룰 등록의 관리 메세지 프로그램의 도면.
도 10은 룰 메시저 처리 흐름을 나타낸 도면.
도 11은 상기 도 10의 룰 메시지 처리의 응답 과정의 흐름도.

이하에서는 본 발명의 양호한 실시예를 첨부된 도면을 참조하여 상세히 설명한다. 우선 각 도면의 구성요소들에 참조부호를 부가함에 있어서, 동일한 구성요소들에 대해서는 비록 다른 도면상에 표시가 되더라도 가능한 한 동일 부호를 가지도록 하고 있음에 유의하여야 한다.

또한, 하기에서 본 발명을 설명함에 있어 관련된 공지기능 또는 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴수 있다고 판단되는 경우에는 그 상세한 설명을 생략한다.

또한, 본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위하여 사용된 것에 불과하므로, 본 발명을 한정하려는 의도가 아니며 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한 복수의 표현도 의미하는 것임을 미리 밝혀두고자 한다.

본 발명을 설명하기에 앞서, 본 발명의 명세서에 등장하는 용어에 대하여 간략하게 설명하기로 한다.

UDP(User Datagram Protocol)는 TCP보다 전송의 신뢰성은 떨어지지만, 전송속도가 비교적 빠른 프로토콜을 의미한다. 비연결형 지향형 프로토콜로 데이터를 독립적인 관계를 지니는 패킷인 데이터그램 단위로 처리하며, 데이터그램은 신뢰성보다는 연속성이 중요한 서비스, 예를 들면, 실시간 스트리밍 서비스에 자주 사용된다.

스마트 NIC(Smart Network Interface Card)는 네트워크로부터 처음 패킷을 수신하는 부분으로서, CPU(중앙처리장치)가 어플리케이션 처리에 집중할 수 있도록 하기 위해 네트워크 기능을 수행하여 고 성능화를 도모하는 것으로, 시스템 간에 주고 받는 패킷 데이터에서 TCP/IP Header를 제거하여, 어플리케이션 간의 통신 내용을 CPU가 바로 처리할 수 있는 것이다.

터널(Tunnel)이란 제어신호 및 데이터 전달을 위한 통로(터널) 역할을 하는 것으로, 프로토콜이나 이동단말 등의 수단에 페킷 등의 데이터를 전달할 수 있도록 돕는 역할을 한다.

가상 머신(Virtual Machine, VM)은 컴퓨팅 환경을 소프트웨어로 구현한 것으로서, 컴퓨터를 에뮬레이션하는 소프트웨어를 의미한다. 가상머신 상에서 운영체제나 응용 프로그램을 설치 및 실행을 할 수 있다.

쓰레드(thread)는 프로세스 내에서 실행되는 여러가지 흐름의 단위이다.

도 1은 본 발명에 의한 터널 Ctrl 쓰레드를 이용한 데이터 통신에서의 터널 데이터 업데이트 처리방법의 흐름도이고, 도 2는 터널 Ctrl 쓰레드를 이용하여 터널 Ctrl 서브 쓰레드로 데이터를 전달하는 과정의 흐름도이고, 도 3은 터널 Ctrl 쓰레드를 이용하여 터널 Ctrl-서브 쓰레드에 데이터의 전송 및 분배를 하는 것을 나타낸 도면이고, 도 4는 터널 테이블의 도면이고, 도 5는 터널 테이블의 등록을 확인하여, IP- UDP 터널링 패킷으로 변형시키는 과정을 나타낸 도면이고, 도 6은 데이터 통신에서의 터널 데이터 업데이트 프로세스 시스템의 블록도이고, 도 7a는 add 터널 요청 명령 메시지의 도면이고, 도 7b는 del 터널 요청 명령 메시지의 도면이고, 도 8은 스마트 NIC의 프로그램 구조의 사진이고, 도 9는 룰 등록의 관리 메세지 프로그램의 도면이고, 도 10은 룰 메시저 처리 흐름을 나타낸 도면이고, 도 11은 상기 도 10의 룰 메시지 처리의 응답 과정의 흐름도이다.

이하, 도 1을 참조하여 본 발명에 의한 데이터 통신에서의 터널 데이터 업데이트 처리방법에 대하여 설명하기로 한다.

먼저, 패킷(미도시) 데이터를 입력시킨다(S 1). 상기 페킷은 네트워크를 통해 전송되는 데이터의 전송단위(작은 데이터 조각)로서 데이터 통신에서 데이터를 효율성 있게 전송, 교환하기 위해 데이터(예, 파일 등)를 1,000~ 2,000 비트 정도의 적당한 길이로 분할하거나, 역으로 짧은 데이터(예, 캐릭터 또는 문자 정보)를 적당한 길이로 일괄하여, 그 각각에 수신인 번지 등과 같은 제어정보를 부여한 것을 말한다.

다음으로, 에더넷(Ethernet) 헤더를 파싱(parsing)하는 것이다(S 2).

상기 S 1에서 입력된 페킷을 에더넷 헤더(Ethernet header)를 파싱(실행할 수 있는 내부 포맷으로 변환시키는 것)하여 안전하고 효과적으로 페킷을 전송시킨다. 즉, 상기 에더넷 헤드로 인한 컴퓨터의 네트워킹을 시작한다.

상기 S 2에서 파싱된 패킷이 IP 패킷인지 여부를 확인하여, IP 패킷임이 확인되면 IP 헤더를 파싱(parsing) 시키는 것이다(S 3). 본 S 2에서 IP 패킷이 아니라고 확인되면 호스트(400)로 보내는 것이다.

그러나, 이와 같은 경우에는 터널 데이터(T)에 업무 과부하가 생겨서 작업량이 많아지게 되어, 자칫 처리 속도의 지연이 될 가능성이 매우 많다.

따라서, 본 발명은 터널 Ctrl 쓰레드(C) 및 터널 Ctrl 서브 쓰레드(S)를 구비하여 이러한 업무 로드를 줄여 줄수 있도록 하는데, 도 2는 터널 Ctrl 쓰레드를 이용하여 터널 Ctrl 서브 쓰레드로 데이터를 전달하는 과정의 흐름도인데, 상기 도 2와 도 3을 참조하여 이를 설명하기로 한다.

먼저, 상기 서술한 S 2에서의 확인된 IP 페킷을 스마트 NIC(200)를 통하여 수신받게 되는 것이다(S 3-1).

그러면, 터널 Ctrl 쓰레드(C)를 이용하여 상기 IP 페킷의 데이터를 로드 밸런싱(Load-balancing)을 통한 분배하게 된다(S 3-2).

상기 로드 밸런싱(Load-balancing)이란 데이터를 균형있게 분배하는 것인데, 데이터를 Enqueue화하여 입력하게 된다.

도 3을 참조하면, 상기 S 3-2에서의 데이터와 command Pool(도면부호는 생략)의 data들로 Queue 데이터(도면부호는 생략)로 합쳐지게 된다(S 3-3).

이와 같이, 합쳐진 데이터는 Dequeue화하여 출력되어 다수개의 터널 Ctrl 서브 쓰레드(S)로 전송할수 있도록 나누게 되는 작업을 실행하는 것이다.

상기 S 3-3에서 합쳐진 모든 데이터를 다수개의 터널 Ctrl 서브 쓰레드(S)로 전달한다(S 3-4). 그러므로, 호스트(400)로 보내주는 역할을 상기 터널 Ctrl 서브 쓰레드(S)가 작업을 나누어서 수행할수 있다. 참고로, 상기 터널 Ctrl 서브 쓰레드(S)의 갯수는 5~ 10개가 바람직할 것이다.

따라서, 상기와 같이 데이터들을 여러 곳의 터널 Ctrl 서브 쓰레드(S)로 각각 분산하여 배치하게 함으로서, 작업량을 크게 나누어지게 됨으로 인하여 터널 테이블(T)이 많은 세션을 수월하게 진행할수 있도록 하는 우수한 기능이 있는 것이다.

상기 IP 페킷의 소스 IP의 대역이 터널 테이블(도 4 참조, 도면부호의 기재는 생략)에서 찾아 확인하여, 적절하면 터널 UDP(User Datagram Protocol) 헤더를 파싱시킨다(S 4).

상기 IP 페킷을 스마트 NIC(200)에 터널 쓰레드(210)에 형성된 터널 테이블(T)에서 대조하여 이를 확인하고, 터널 UDP 헤더를 파싱한다.

도 5를 참조하면, 외부에서 수신되는 상기 IP 패킷을 터널 구성 에이전트(120: Tunnel Configuration Agent)를 통하여 터널링 룰(IP 주소 및 포트에 기초하여 생성되고, 처리 대상에 포함되는 IP 패킷의 리스트로 정의)을 형성하여, 패킷 프로세싱 알고리즘(packet processing algorithem)에 따라 매칭하여 상기 터널 테이블(T)에 등록되어 있으면 UDP 터널링 패킷으로 변경시키고, 등록되어 있지 않으면 호스트(400)로 처리한다.

따라서, 스마트 NIC(200)에 속해 있는 터널 테이블(T)에 규칙이 등록되면, 상기 스마트 NIC(200)에서 IP-UDP Encapsulation(캡슐화)/Decapsulation(제거)이 진행되는 것이다.

상기 IP 페킷의 포트가 터널 소스 포트(Tunnel src.port: 송신지 포트)와 터널 목적지 포트(Tunnel dst.port: 목적지 포트)인지의 여부를 모두 터널 테이블(T)에서 확인한다(S 5).

상기 S 5에서 상기 IP페킷이 터널 소스 포트와 목적지 소스 포트에 모두에 해당하면, 등록된 터널페킷으로 인증하는 것이다(S 6).

만일, 상기 S 5에서는 IP 페킷의 포트가 터널 소스 포트(Tunnel src.port: 송신지 포트)와 터널 목적지 포트(Tunnel dst.port: 목적지 포트)에 해당하지 않으면, 비 등록된 터널 페킷으로 간주하여 호스트(400)로 전송하는 것이다.

상기 S 6에서 등록된 터널 페킷이 데이터 페킷인지 확인한다(S 7). 만일, 데이터 페킷이 아니면 이것도 역시 호스트(400)로 전송한다.

상기 S 7에서 등록된 터널 페킷이 데이터 페킷임이 확인되면 터널데이터(T) 헤더(미도시)를 제거하고, 새로운 터널데이터(T) 헤더를 결합시킨다(S 8). 역시, 데이터 페킷이 아님이 확인되면 호스트(400)로 돌려보낸다.

Statics를 업데이트하여 포트를 확인하는 것이다(S 9).

상기 S 9에서, 상기 Statics는 터널링이 되는 IP 패킷의 갯수인 것인데, 본 S 9는 상기 IP 패킷들을 모두 업데이트시키는 단계인 것이다. 업데이트하는 동시에 해당하는 터널 소스 포트와 터널 목적지 포트를 확인하는 것이다.

마지막으로, 상기 S 9에서 새롭게 업데이트된 IP 페킷을 네트워크로 전송하는 것이다(S 10).

이하에서는, 본 발명에 의한 터널 Ctrl 쓰레드를 이용한 데이터 통신에서의 터널 데이터 업데이트 프로세스 시스템에 대하여 설명하기로 한다.

도 6을 참조하면, 본 발명의 시스템은 크게 애플리케이션(미도시)이 동작하는 유저 스페이스(100)와 IP-UDP 터널링 기능을 오프-로드시키는 스마트 NIC(200)와 상기 유저 스페이스(100)와 상기 스마트 NIC(200) 사이에 형성되어 시스템 드라이브를 실행하기 위한 kernel 스페이스(300)로 이루어진다.

유저 스페이스(100)는 도커(Docker)를 이용한 가상머신(110)으로 동작하는 다수개의 터널 구성 에이전트(120: Tunnel Configuration Agent)가 형성된다.

상기 터널 구성 에이전트(120)는 터널링을 할 때, 터널 소스 포트 및 터널 목적지 포트를 지정한다. 상기 터널 구성 에이전트(120)에서 터널 설정을 입력하면, 스마트 NIC(200)의 터널 테이블(T)의 내부 알고리즘에 입력하여 참조하여, 터널 설정을 완료한다. 참고로, 상기 터널 구성 에이전트(120)의 갯수는 3~ 20개가 바람직하다.

도시된 바와 같이, 내부에 터널 테이블(T)을 품고 있는 터널 쓰레드(210)는 데이터의 전송 및 분배를 할 수 있도록 터널 Ctrl- 서브 쓰레드(S)에 연결되어 있다.

상기 터널 CTRL-서브 쓰레드(S)는 상기 터널 쓰레드(210)와 연결되어 세션을 처리하고, Command 데이터의 내용을 파싱하고 명령을 실행하며, 그 결과에 대한 응답메시지를 호스트(400)로 전송한다.

터널 CTRL 쓰레드(C)는 상기 세션을 관리하며, 상기 터널 CTRL-서브 쓰레드(S)가 로드- 밸런싱하여 처리할수 있도록, 데이터를 분배하여 준다.

즉, 상기 세션을 관리하는 서버의 역할을 수행하는 상기 터널 Ctrl 쓰레드(C)는 상기 터널 테이블(T)에 과부하가 생기지 않도록 상기 터널 Ctrl-서브 쓰레드(S)로의 분배를 실행시킨다.

그리고, Statics 모니터(130)는 스마트 NIC(200)의 Statics 쓰레드(220)를 통한 터널링된 패킷에 대한 통계를 내어 관리자에게 전달한다.

스마트 NIC(200)는 터널 테이블(T)를 품고있는 터널 쓰레드(210)와 터널링되는 패킷에 대한 통계를 내어 상기 Statics 모니터(130)로 전달하는 Statics 쓰레드(220)가 형성된다.

PCI 쓰레드(230)는 스마트 NIC(200)과 상기 유저 스페이스(100)를 연결하여 주는 역할을 하는 것이다.

엔캡(Encapsuiation)/ 디캡(Decapsulation) 쓰레드(240)는 터널 데이터(T) 헤드(미도시)를 결합 또는 제거시키는 역할을 하는 것이다.

이하, 본 발명에 의한 터널 Ctrl 쓰레드를 이용한 데이터 통신에서의 터널 데이터 업데이트 프로세스 시스템의 작동 관계에 대하여 설명하기로 한다.

IP 패킷이 스마트 NIC(200)으로 진입하게 되면 터널링 룰을 스마트 NIC(200)에 있는 패킷 프로세싱 알고리즘에 입력시켜서, 상기 IP 페킷이 터널 테이블(T)에 등록되어 있는지 매칭을 한다.

터널 구성 에이전트(120)는 Docker(110)를 이용한 가상머신을 통해 동작하면서 상기 IP 페킷의 경로를 지정한다.

상기 터널 테이블(T)에 상기 IP 페킷이 등록이 되어 있으면 IP- UDP 터널링 패킷으로 변경시키고, 상기 터널 테이블(T)에 등록되어 있지 않으면 호스트(400)로 올려 처리한다.

이하에서는, 본 발명의 실시예에 의하면 상기 터널 테이블(T)이 감당할 과중한 세션을 크게 분담시키도록 하기 위하여 터널 CTRL 쓰레드(C)와 터널 CTRL 서브 쓰레드(S)가 형성되어 있는데, 이를 설명하기로 한다.

상기 터널 CTRL 쓰레드(C)는 터널의 세션을 관리하는 흡사, 서버의 역할을 수행하는 것이다.

도 7a와 도 7b를 참조하면, 호스트(400)로부터 터널의 세션에 연결된 패킷이 도착하면, 소켓(socket)에 대한 이벤트(Add, Del)를 읽어내고, 터널 연결에 대한 설정을 하거나, 터널 세션을 통해 명령이 도착했을 때, 명령 메시지를 읽어, 명령 버퍼(미도시)에 넣는 부분까지 터널 CTRL 쓰레드(C)에서 수행한다.

수신한 명령 메시지를 파싱하고, 명령 내용대로 실행하며, 그 결과를 호스트(400)로 보내주는 역할은 다수개의 터널 CTRL-서브 쓰레드(S)가 작업을 나눠서 수행한다.

상기 다수개의 터널 CTRL-서브 쓰레드(S)를 통하여 많은 세션을 수월하게 처리하기 위해서, 다수개의 터널 CTRL-서브 쓰레드(S)에게 Load-Balancing을 하여 처리하도록 한다.

명령을 각 수신할 때마다 명령어의 집합 Pool로부터 할당받은 메모리 공간에 소켓과 이벤트 정보, 그리고 호스트(400)로부터 수신한 데이터 정보를 넣고, 터널 CTRL-서브 쓰레드(S)와 연결된 Queue 중에 하나를 선택하여 해당 Queue에 Command data(도 3 참조, 도면부호는 생략)를 넣는다.

상기 Queue는 수신한 명령을 구분하고 Session ID 값(명령을 구별하기 위해 호스트가 할당한 값)에 의해 결정된다.

터널 CTRL-서브 쓰레드(S)는 Command data 내용을 파싱하고, 명령을 실행하며, 그 결과에 대한 응답 메시지를 생성하여 호스트(400)로 보낸다.

상기와 같은 절차를 거친 IP 페킷이 데이터 페킷인지 여부를 확인하여, 종래의 터널 헤더(미도시)를 제거하고, 새로운 터널 헤더를 결합시킨다.

상기 IP 페킷을 업데이트하여, 업데이트된 IP 페킷을 네트워크로 전송하다. 그리고, Statics 쓰레드(220)는 터널링된 IP 패킷에 대한 통계를 내어 유저 스페이스(100)의 Statics 모니터(130)로 전달한다.

이하, 도 8을 참조하여 스마트 NIC의 프로그램 구조의 사진을 참조하여, 관련되는 터널데이터 업데이트 프로세스 시스템(U)의 작동관계에 대하여 설명하기로 한다. 앞서 설명한 내용에 대한 중복적인 서술은 어느 정도 생략하기로 한다.

도시된 바와 같이, 스마트 NIC(200)과 호스트(400)의 양측으로 나뉘어지며, P2P(동등 계층간 통신망) 방식으로 파일 등을 주고 받는 형태인 것이다.

스마트 NIC(200) 측에는 상부에 패킷 처리 쓰레드인 앤캡/디캡 쓰레드(240)와 PCI 쓰레드(230)가 서로 연결되어 있다.

그리고, 상기 앤캡/디캡 쓰레드(240)와 PCI 쓰레드(230)의 양측에는 피어(Peer) 간에 네트워크 트래픽을 전송하기 위한 통신채널을 제공하는 mPIPE(m)와 상기 PCI 쓰레드(230)와 호환하는 TRIO(245)가 각각 연결되어 형성된다.

그리고, 하부에는 터널 테이블(T)을 품고 있는 터널 쓰레드(210)와 Statics 쓰레드(220)가 형성된다. 여기서, 상기 터널 쓰레드(210)는 터널 CTRL 쓰레드(C)의 명령을 받는 터널 CTRL-서브 쓰레드(S)가 연결되어 있는데, 앞서 설명하엿으므로 자세한 설명은 생략하기로 한다.

호스트(400) 측에는 Kernel 스페이스(300)와 리눅스 형태의 PCIe 드라이버(310), Docker(110) 그리고, 다수 개가 연결된 터널 구성 에이전트(120)가 DTR(data-terminal-ready: 데이터 전송 준비의 완료)의 상태로 이루어져 있다.

그리고, 상기 스마트 NIC(200)의 Statics 쓰레드(220)로부터 터널링된 IP 패킷에 대한 통계를 전송받는 Statics 모니터(130)가 형성된다.

터널 구성 에이전트(120)에서 터널 정보를 전송하는데, 상기 터널 정보는 네트워크, 터널 소스 포트, 터널 목적지 포트, 새(new) 터널 소스 IP, 새 터널 목적지 IP, 인터페이스이다.

그 다음, 상기와 같은 터널 정보를 전송받은 터널 Ctrl-서브 쓰레드(S)에서는 터널 정보를 업데이트시켜, 터널 설정 정보(success, failure, list)를 응답하여 상기 터널 구성 에이전트(120)에 전송하는 것이다.

도 9에 나타난 대로, 상기 터널 설정 정보의 결정은 상기 터널 스레드(210)의 터널 테이블(T) 룰을 통해 등록되어 있다고 판단하면 success, 등록되어 있지 않으면 fail, 그리고, success되거나 fail의 갯수는 list의 숫자로 기록하는 것이다.

add 부분은 0으로 되어 있어, 추가된 것이 없이 Socket Payload(터널쓰레드(210)와 터널 구성 에이전트(120) 간에 교환하는 메세지 구조, 도면부호는 생략)는 그대로이지만, 밑에 del은 IP주소인 오른편의 터널 소스 IP와 터널 목적지 IP는 모두 삭제되었다.

그리고, 밑에 list는 2(add와 del의 2번의 경우이므로)로서, add와 del의 공통 부분인

은 삭제되었고, 맨 왼쪽의 type(1 Byte)만이 기록된다.

도 10은 룰 메신저를 수신하여 처리의 흐름을 나타낸 것으로, 터널 구성 에이전트(120)가 응답 메세지를 전송하는 것을 나타낸 알고리즘이다.

먼저, 룰 메신저를 수신하여 터널테이블(T)의 Type 필드를 확인한다(Step 1). 상기 Type 필드는 숫자로 이를 확인(Step1)하게 되는데, add는 '0'이고 del은 '1'이고, list는 '2'로 정의된다.

즉, 룰에 있으면 add, 룰에 없으면 del, 경우의 수를 list로 기재할 수치를 판단하게 된다.

만일, 룰에 있어서 add로 기록되면, add 포맷을 파싱하여 포트 숫자를 검색한다.

만일, 포트가 존재하면 네트워크와 IP를 업데이트하여 sucess 메신저를 생성하여 이를 전송하고, 포트가 존재하지 않으면 토탈 list 숫자를 연속하여 검색해서, 네트워크, 포트, IP를 입력한 후에 역시 sucess 메신저를 생성하여 상기 응답메세지를 유저 스페이스(100)로 전송한다(Step 2-a).

만일, 룰에 존재하지 않아 del로 기록되면 del 포맷을 파싱하고, 포트 숫자를 검색한다.

해당하는 포트가 존재하면 해당 리스트를 삭제하여, sucess 메신저를 생성하여 이를 전송하고, 해당 포트가 존재하지 않으면 failure 메신저를 생성하여 이를 유저 스페이스(100)로 상기와 같은 응답 메세지를 전송한다(Step 2-b).

그리고, list는 list 포맷을 파싱하여 failure 메신저를 응답 메신저로 생성하여 유저 스페이스(100)로 상기 응답 메세지를 전송한다(Step 2-c).

도 11은 상기 도 10의 룰 메시지 처리의 응답 과정의 흐름도이다.

상기 도 10에서와 같은 과정으로 룰 메세지를 수신받았을 경우에 유저 스페이스(100)로 전달을 하기 위해서 반드시 응답 메세지를 전송하여야 하는데, 이 과정에 대하여 설명하기로 한다.

먼저, 응답메세지를 수신(Step 3)하여, 그 result 필드를 확인한다(Step 4). 상기 result 필드라는 것은 결과를 나타내는 수치인데 즉, success일 때는 1, failure일 때는 0, list일 때는 2를 의미한다.

도시된 바와 같이, 상기 result 필드를 확인하여 '0' 일 경우에는 failure 메세지, '1' 일 경우에는 success 메세지, '2'일 경우에는 list를 출력하는 것이다(Step 5).

이상에서와 같은 내용의 본 발명이 속하는 기술분야의 당업자는 본 발명의 기술적 사상이나 필수적 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로, 상기 기술한 실시 예는 예시된 것이며 한정적인 것이 아닌 것으로서 이해해야만 한다.

본 발명의 범위는 상기 상세한 설명보다는 첨부된 특허청구범위에 의하여 나타내어지며, 특허청구 범위의 의미 및 범위 그리고 그 등가 개념으로부터 도출되는 모든 변경 또는 변형된 형태가 본 발명의 범위에 포함되는 것으로 해석되어야 한다.

100 : 유저 스페이스 110 : Docker
120 : 터널 구성 에이전트 130 : Statics 모니터
200 : 스마트 NIC 210 : 터널 쓰레드
220 : Statics 쓰레드 230 : pci 쓰레드
240 : 엔캡/디캡 쓰레드 245 : TRIO
300 : kernel 스페이스 400 : 호스트(host)
T : 터널 테이블 P : mPIPE
S : 터널 CTRL-서브 쓰레드 C : 터널 CTRL 쓰레드
U : 터널 데이터 업데이트 프로세스 시스템

Claims

터널 Ctrl 쓰레드를 이용한 데이터 통신에서의 터널데이터 업데이트 처리방법에 있어서,
패킷(packet)을 입력시키는 S 1;
입력된 패킷에 에더넷(Ethernet) 헤더를 파싱(parsing)하는 S 2;
상기 패킷이 IP 패킷인지 여부를 확인하고, IP 패킷임이 확인되면 IP 헤더를 파싱(parsing)시키는 S 3;
소스 IP의 대역이 터널 테이블(T)에서 확인하여, 적절하면 터널 UDP(User Datagram Protocol) 헤더를 파싱시키는 S 4;
터널 소스 포트와 터널 목적지 포트 여부를 터널 테이블(T)에서 확인하는 S 5;
상기 S 5에서 확인되면, 등록된 터널 페킷으로 인증하는 S 6;
상기 S 6에서 등록된 터널 페킷이 데이터 페킷인지 여부를 확인하는 S 7;
상기 S 7에서 데이터 페킷이 확인되면 터널테이블(T) 헤더를 제거하고, 새로운 터널테이블(T) 헤더를 입히는 S 8;
Statics(220)를 업데이트하여 포트를 확인하는 S 9;
IP 페킷을 네트워크로 전송시키는 S 10을 포함하는 것을 특징으로 하는 터널 Ctrl 쓰레드를 이용한 데이터 통신에서의 터널 데이터 업데이트 처리방법.
제1항에 있어서,
상기 S 3에서는
상기 IP 페킷을 스마트 NIC(200)를 통하여 수신받는 S 3-1;
상기 터널 Ctrl 쓰레드(C)를 이용하여 상기 IP 페킷의 데이터를 로드 밸런싱(Load-balancing)을 하기 위한 분배하는 S 3-2;
상기 데이터와 command 풀의 data가 Queue 데이터풀로 합쳐지는 S 3-3;
상기 단계에서 합쳐진 데이터를 다수개의 터널 Ctrl 서브 쓰레드(S)로 전달하는 S 3-4를 포함하는 것을 특징으로 하는 터널 Ctrl 쓰레드를 이용한 데이터 통신에서의 터널 데이터 업데이트 처리방법.
제1항에 있어서,
상기 S 4에서는 상기 IP 패킷이 터널 구성 에이전트(120)를 통하여 터널링 룰을 형성하여, 패킷 프로세싱 알고리즘에 따라 상기 터널 테이블(T)에 등록되어 있으면 UDP 터널링 패킷으로 변경시키고, 등록되어 있지 않으면 호스트(400)로 처리하는 것을 특징으로 하는 터널 Ctrl 쓰레드를 이용한 데이터 통신에서의 터널 데이터 업데이트 처리방법.
제1항에 있어서,
상기 S 9에서 Statics는 터널링되는 패킷의 갯수인 것을 특징으로 하는 터널 Ctrl 쓰레드를 이용한 데이터 통신에서의 터널 데이터 업데이트 처리방법.
터널 Ctrl 쓰레드를 이용한 데이터 통신에서의 터널 데이터 업데이트 프로세싱 시스템에 있어서,
도커(Docker)를 이용한 가상머신(110)으로 동작하는 다수개의 터널 구성 에이전트(120: Tunnel Configuration Agent)와 Statics 쓰레드(220)를 통한 터널링된 패킷에 대한 통계를 내어 전달하는 Statics 모니터(130)를 포함하여 이루어지며, 애플리케이션이 동작하는 유저 스페이스(100);
내부에 터널 테이블(T)을 품고 있는 터널 쓰레드(210);
상기 터널 쓰레드(210)와 연결되어 세션을 처리하고, Command 데이터의 내용을 파싱하고 명령을 실행하며, 그 결과에 대한 응답메시지를 호스트(400)로 전송하는 터널 CTRL-서브 쓰레드(S);
상기 세션을 관리하며, 상기 터널 CTRL-서브 쓰레드(S)가 로드- 밸런싱하여 처리할수 있도록, 데이터를 분배하여 주는 터널 CTRL 쓰레드(C);
상기 Statics 모니터(130)로 터널링되는 패킷에 대한 통계를 생성하여, 전달하는 Statics 쓰레드(220);
상기 유저 스페이스(100)를 연결하는 pci 쓰레드(230)와 터널 데이터(T) 헤드를 결합 또는 제거시키는 엔캡/ 디캡 쓰레드(240)를 포함하여 이루어지며, IP-UDP 터널링 기능을 오프로드시키는 스마트 NIC(200);
상기 유저 스페이스(100)와 상기 스마트 NIC(200) 사이에 형성되어 시스템 드라이브를 실행하기 위한 kernel 스페이스(300)를 포함하는 것을 특징으로 하는 터널 Ctrl 쓰레드를 이용한 데이터 통신에서의 터널 데이터 업데이트 프로세싱 시스템.
제5항에 있어서,
상기 유저 스페이스(100)의 터널 구성 에이전트(110)에서 터널 설정을 입력하면, 상기 스마트 NIC(200)의 터널 테이블(T)에서 터널 설정을 완료하는 것을 특징으로 하는 데이터 통신에서의 터널 데이터 업데이트 프로세싱 시스템.