KR102134895B1

KR102134895B1 - 멀티호밍 sctp노드 상에서 동작하는 sctp 유저 어플리케이션의 패킷 분석 시스템 및 그 방법

Info

Publication number: KR102134895B1
Application number: KR1020190156118A
Authority: KR
Inventors: 김영진; 최용웅
Original assignee: 주식회사 모비젠
Priority date: 2019-11-28
Filing date: 2019-11-28
Publication date: 2020-07-17

Abstract

본 발명의 일 실시 예는, 멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 방법으로서, 적어도 두 개 이상의 IP주소를 갖는 발신 SCTP노드에서 하트비트 청크(HEARTBEAT chunk)를 적어도 두 개 이상의 IP주소를 갖는 수신 SCTP노드에 송신하는 하트비트청크송신단계; 상기 수신 SCTP 노드로부터 상기 하트비트 청크에 대응되는 하트비트 애크 청크(HEARTBEAT ACK chunk)를 수신하는 하트비트애크청크수신단계; 상기 하트비트청크 및 상기 하트비트 애크 청크에 포함된 정보를 기초로 하여, SCTP 노드 테이블을 생성하는 테이블생성단계; 상기 생성된 SCTP 노드 테이블을 기초로 하여, 상기 발신 SCTP노드 및 상기 수신 SCTP노드의 대표 IP주소를 결정하는 대표주소결정단계; 및 상기 결정된 대표 IP주소를 기초로 프로시져 키를 구성하여 상기 발신 SCTP노드 및 상기 수신 SCTP노드간에 송신된 패킷을 분석하는 패킷분석단계를 포함한다.

Description

멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 시스템 및 그 방법 {System for analyzing packet of SCTP user application in multi-homing SCTP node and method thereof}

본 발명은 멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 시스템 및 그 방법에 관한 발명으로서, 보다 구체적으로는 SCTP노드간에 설정된 메시지 전송경로가 변화하더라도 SCTP 유저 어플리케이션 프로토콜의 프로시저(procedure)를 분석할 수 있도록 하는 방법 및 그 방법을 구현하기 위한 시스템에 관한 것이다.

과거 인터넷에서의 수송계층 프로토콜은 TCP 및 UDP로 제한되어 왔으나, TCP 및 UDP 기반의 인터넷 프로토콜은 기존의 전기통신망에서 제공되던 전화서비스를 비롯하여 새로이 개발되는 멀티미디어 스트리밍 서비스 제공에는 부적합한 문제점이 지적되었으며, 이에 따라, IETF에서는 2000년 10월에 SCTP(Stream Control Transmission Protocol)을 RFC2960으로 제정하였다. SCTP 개발의 초기 목적은 인터넷 망에서의 전화서비스의 신호전달에 있었으나, 최근에는 범용 수송계층 프로토콜로서, 모든 종류의 인터넷 응용서비스로 확대적용되고 있다.

SCTP는 UDP의 메시지 지향(message-oriented)특성과 TCP의 연결형 신뢰성 제공 특성을 조합한 프로토콜이다. 또한, SCTP는 멀티스트리밍(multi-streaming) 및 멀티호밍(multi-homing)특성을 제공하며, 세션 초기화 및 종료단계에서도 기존 TCP에서 문제점으로 지적되던 TCP-SYN 공격 문제 및 "half-open closing" 문제를 해결한 프로토콜이다.

SCTP 수송계층 프로토콜은 VoIP(Voice over IP)신호전달 외에도, 다중 미디어를 전송하는 웹 응용, AAA(Authentication, Authorization, Accounting)등의 고도의 신뢰성을 요구하는 보안 응용, 실시간 신뢰성을 요구하는 mission-critical 응용서비스 등에서 하부 프로토콜로 사용될 수 있으며, 특히, all-IP 기반 이동통신망에서 핸드오버 기능을 용이하게 제공할 수 있다.

SCTP는 응용 계층과 네트워크 계층 사이에 위치한다. SCTP는 SCTP peers간에 응용 데이터를 APIs(Application Programming Interfaces)로 전달받아 IP망을 통해 전송하는 기능을 수행한다. 각 SCTP 노드는 하나의 SCTP 세션에서 여러 개의 IP 주소를 사용할 수 있다.

SCTP는 두 지점간에 메시지 전송을 위해 다중경로(multiple path) 및 다중스트림(multiple stream)기능을 사용한다. 두 SCTP 지점간의 SCTP 연결을 "SCTP association"이라 호칭한다. 특정 SCTP association에서의 전송 절차는 크게 연결초기화(initiation), 데이터전송(data transfer) 및 연결종료(shutdown) 단계로 나뉘어진다. SCTP 패킷 혹은 PDU(Protocol Data Unit)은 하나의 헤더(header)와 여러 개의 청크들(chunks)로 구성되며, 각 청크는 제어정보 혹은 응용데이터를 포함한다. SCTP 스트림(streams)에서 각 데이터는 순차적으로 전달되며, 멀티호밍 특성을 활용하여 망 장애(network failure)에 대비한 복구 기능을 수행할 수 있다.

SCTP 패킷의 헤더에는 송신자 포트번호(16 bits), 수신자 포트번호(16 bits), verification tag(32 bits) 및 전체 패킷에 대한 Checksum(32 bits) 정보가 포함된다. Verification tag 값은 association 별로 할당되며, 세션 식별자로 사용된다. 하나의 SCTP 패킷은 여러 개의 데이터 및 제어 청크(chunks)를 포함할 수 있으며, 데이터 청크(data chunk)의 경우 Type, Length 정보와 함께 해당 데이터 청크에 대한 TSN, SSN 번호를 포함하여, 추후 오류제어 및 흐름제어 등에 사용된다.

SCTP는 데이터 청크와 함께 여러 개의 제어 청크(contol chunks)들을 사용하며, 추후 SCTP 확장 작업과 함께 제어 청크들의 수는 증가할 수 있다. SCTP 기본 규격(RFC 2960)에 정의된 주요 제어 청크의 종류를 정리하면 표 1과 같다.

4G 또는 5G 네트워크 환경에서 단말과 코어 시스템(Core System)간에 신호 메시지를 전달하기 위해서는, S1AP, X2AP, F1AP 및 NGAP 등의 프로토콜이 사용되며, 이 프로토콜들은 SCTP 위에서 동작한다. SCTP 유저 어플리케이션(User Application)은 위와 같은 프로토콜을 구현하여, 프로토콜 메시지를 패킷에 실어 다른 SCTP 유저 어플리케이션으로 전송한다. 패킷을 분석하는 IT분야에서는, SCTP 유저 어플리케이션의 통신 품질 및 오류 정보를 실시간으로 모니터링하기 위해서 어플리케이션간에 송수신되는 네트워크 패킷을 통해 프로토콜의 메시지 및 프로시져(procedure)를 분석한다.

다수의 SCTP 노드들이 전송하는 패킷들 중에서 실시간으로 하나의 프로시져를 분석하기 위해서는, 프로토콜 메시지를 포함한 패킷 정보로서, 발신 노드 IP주소, 수신 노드 IP주소, 발신 노드 SCTP 포트, 수신 노드 SCTP 포트, 프로토콜의 Procedure 종류정보가 기본적으로 필요하다. 전술한 다섯 가지의 정보를 프로시져 키(Procedure Key)로 구성하여 프로시져 키가 일치하는 패킷들을 탐색하여, 하나의 프로시져를 분석할 수 있다. 이하에서는, 하나의 프로시져를 구성하는 여러 메시지들 중에 첫 요청 메시지를 발송한 노드를 발신 노드, 그 요청메시지를 수신한 노드를 수신 노드라고 통칭하도록 한다.

다만, 프로토콜 메시지를 전송하는 SCTP노드가 싱글 호밍(Single-Homing)이 아닌 멀티(Multi-Homing)인 경우에는 프로시져 키의 값이 달라지는 문제점이 발생하여, SCTP 유저 어플리케이션의 현재 상태를 제대로 모니터링할 수 없게 될 뿐만 아니라, 부정확한 프로시져 분석 데이터가 생성될 수 있다.

도 1은 싱글호밍 SCTP 노드 간 S1AP 프로시져 통신 과정의 일 예를 설명하기 위한 도면이다.

보다 구체적으로, 도 1은 싱글호밍 SCTP노드 간에 InitialContextSetup 프로시져가 통신되는 경우를 나타내고 있다. 싱글호밍 SCTP노드는 노드별로 하나의 IP주소만 사용하므로, 두 노드 간 하나의 전송 경로만 설정될 수 있다. 도 1에서, InitialContextSetup Request 메시지와 InitialContextSetup Response 메시지의 프로시져 키는 동일하므로, 하나의 프로시져로 엮어서 분석될 수 있다.

반면, 멀티호밍 SCTP 노드는 여러 개의 IP주소를 사용하므로, 두 노드 간에 여러 개의 전송 경로가 설정될 수 있다. 각 SCTP 노드는 SCTP Association startup 동안 여러 전송 경로 중 하나를 주 전송경로(primary path)로 결정한다. SCTP 유저 어플리케이션은 구현 예에 따라서 주 전송경로를 결정할 수 있으며, 메시지를 주 전송경로가 아닌 다른 전송경로를 통해 전송할 수도 있다.

표 2는 도 1과 같은 싱글호밍 SCTP 노드 간 S1AP 프로시져 통신 과정을 표로 나타내고 있다. 표 2를 참조하면, 전송순서와 상관없이 발신노드 IP주소, 수신노드 IP주소가 동일하게 유지되는 것을 알 수 있다.

도 2는 멀티호밍 SCTP 노드 간 S1AP 프로시져 통신 과정의 일 예를 설명하기 위한 도면이다.

보다 구체적으로, 도 2는 멀티호밍 SCTP노드 간에 InitialContextSetup 프로시져가 통신되는 경우를 나타내고 있다. 멀티호밍 SCTP노드는 노드별로 여러 개의 IP주소를 사용하므로, 두 노드 간에는 여러 전송 경로가 설정될 수 있다. 도 2를 참조하면, InitialContextSetup Request 메시지가 전송된 경로와 InitialContextSetup Response 메시지가 전송된 경로가 서로 달라서, 발신 노드 IP주소가 달라져서, 프로시져 키(procedure key)도 달라지고, 하나의 프로시져로 분석될 수 없게 된다. 다른 예로서, InitialContextSetup Response 메시지가 실선 화살표가 아니라(2.2.2.1에서 1.1.1.2로), 점선 화살표(2.2.2.2에서 1.1.1.1 또는 1.1.1.2로)로 전송된 경우에도 IP주소가 달라져서 하나의 프로시져로 분석될 수 없다.

표 3은 멀티호밍 SCTP 노드 간 S1AP 프로시져에서 전송경로가 달라짐에 따라서, 발신노드 IP주소 불일치가 발생되는 현상을 나타내고 있으며, 표 2와 함께 이해될 수 있다.

도 2와 같이, 멀티호밍 SCTP노드간의 통신에 있어서, 전송 경로의 변동 가능성에 의해서 하나의 프로시져로 분석이 안되는 경우, SCTP 유저 어플리케이션의 현재 상태가 제대로 모니터링될 수 없어서, 부정확한 분석 데이터가 생성될 수도 있다.

본 발명이 해결하고자 하는 기술적 과제는, 하트비트(HEARTBEAT) 프로시저를 통해서 멀티호밍 기능을 사용하는 SCTP노드의 여러 IP주소를 실시간으로 자동탐색하여 IP 주소 정보를 구축할 수 있는 방법 및 그 방법을 구현하기 위한 시스템을 제공하는 데에 있다.

상기 기술적 과제를 해결하기 위한 본 발명의 일 실시 예에 따른 방법은, 멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 방법으로서, 적어도 두 개 이상의 IP주소를 갖는 발신 SCTP노드에서 하트비트 청크(HEARTBEAT chunk)를 적어도 두 개 이상의 IP주소를 갖는 수신 SCTP노드에 송신하는 하트비트청크송신단계; 상기 수신 SCTP 노드로부터 상기 하트비트 청크에 대응되는 하트비트 애크 청크(HEARTBEAT ACK chunk)를 수신하는 하트비트애크청크수신단계; 상기 하트비트청크 및 상기 하트비트 애크 청크에 포함된 정보를 기초로 하여, SCTP 노드 테이블을 생성하는 테이블생성단계; 상기 생성된 SCTP 노드 테이블을 기초로 하여, 상기 발신 SCTP노드 및 상기 수신 SCTP노드의 대표 IP주소를 결정하는 대표주소결정단계; 및 상기 결정된 대표 IP주소를 기초로 프로시져 키를 구성하여 상기 발신 SCTP노드 및 상기 수신 SCTP노드간에 송신된 패킷을 분석하는 패킷분석단계를 포함한다.

상기 기술적 과제를 해결하기 위한 본 발명의 다른 일 실시 예에 따른 시스템은, 멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 시스템으로서, 적어도 두 개 이상의 IP주소를 갖는 발신 SCTP노드에서 하트비트 청크(HEARTBEAT chunk)를 적어도 두 개 이상의 IP주소를 갖는 수신 SCTP노드에 송신하는 하트비트청크송신부; 상기 수신 SCTP 노드로부터 상기 하트비트 청크에 대응되는 하트비트 애크 청크(HEARTBEAT ACK chunk)를 수신하는 하트비트애크청크수신부; 상기 하트비트청크 및 상기 하트비트 애크 청크에 포함된 정보를 기초로 하여, SCTP 노드 테이블을 생성하는 테이블생성부; 상기 생성된 SCTP 노드 테이블을 기초로 하여, 상기 발신 SCTP노드 및 상기 수신 SCTP노드의 대표 IP주소를 결정하는 대표주소결정부; 및 상기 결정된 대표 IP주소를 기초로 프로시져 키를 구성하여 상기 발신 SCTP노드 및 상기 수신 SCTP노드간에 송신된 패킷을 분석하는 패킷분석부를 포함한다.

본 발명의 일 실시 예는, 상기 방법을 실행시키기 위한 프로그램을 저장하고 있는 컴퓨터 판독가능한 기록매체를 제공할 수 있다.

본 발명에 따르면, 멀티호밍 SCTP 노드간의 통신이 이루어지는 데에 있어서, 프로시저 키(procedure key)를 만들 때, 메시지가 어떤 IP주소로 전송되더라도 동일한 프로시저 키를 만들 수 있게 되어, 프로시저 분석이 가능해짐에 따라, SCTP 유저 어플리케이션의 현재 상태를 모니터링하여 정확한 분석 데이터를 생성할 수 있다.

도 1은 싱글호밍 SCTP 노드 간 S1AP 프로시져 통신 과정의 일 예를 설명하기 위한 도면이다.
도 2는 멀티호밍 SCTP 노드 간 S1AP 프로시져 통신 과정의 일 예를 설명하기 위한 도면이다.
도 3은 멀티호밍 SCTP 노드 간 하트비트 프로시져 통신의 일 유형을 설명하기 위한 도면이다.
도 4 및 도 5는 멀티호밍 SCTP 노드간 하트비트 프로시져 통신의 두 가지 유형을 각각 나타내고 있다.
도 6은 하트비트 맵과 하트비트 타이머 큐를 도식적으로 나타낸 도면이다.
도 7은 하트비트 청크가 처리되는 과정을 설명하기 위한 도면이다.
도 8은 하트비트 애크 청크 처리시에 하트비트 키가 검색되는 과정을 도식적으로 나타낸 것이다.
도 9는 하트비트 프로시져를 통해 획득된 정보들을 도식적으로 나타낸다.
도 10은 node_map에 기존에 생성된 노드 엘리먼트가 있는지 여부를 찾기 위해 사용되는 의사코드의 일 예를 나타낸다.
도 11은 도 10의 의사코드를 통해서 node element를 찾는 과정을 도식적으로 나타낸 도면이다.
도 12는 rcv_node_1, rcv_node_2가 모두 존재하는 경우에 있어서 적용되는 의사코드를 나타낸다.
도 13은 rcv_node_1는 존재하지만, rcv_node_2가 존재하지 않는 경우에 있어서 적용되는 의사코드를 나타낸다.
도 14는 rcv_node_1은 존재하지 않지만, rcv_node_2는 존재하는 경우에 있어서 적용되는 의사코드를 나타낸다.
도 15는 송신 노드와 수신 노드 모두 존재하는 경우에 적용되는 의사코드를 나타낸다.
도 16 및 도 17은 송신 노드만 존재하는 경우에 적용되는 의사코드를 나타낸다.
도 18 및 도 19는 수신 노드만 존재하는 경우에 적용되는 의사코드를 나타낸다.
도 20은 송신 노드 및 수신 노드 모두 존재하지 않는 경우에 적용되는 의사코드를 나타낸다.
도 21은 도 4와 같은 유형의 상태에서 테이블생성부가 생성한 SCTP 노드 테이블의 일 예를 도식적으로 나타낸다.
도 22는 도 21의 결과에서 도 5의 하트비트 프로시져 정보를 추가적으로 처리하여 저장한 경우 생성되는 SCTP 노드 테이블(자료구조)의 일 예를 도식적으로 나타낸다.
도 23 및 도 24는 셧다운 또는 어보트 프로시져가 발생한 경우에 적용되는 의사코드를 나타내고 있다.
도 25는 IP주소를 치환하는 과정을 의사코드로 구현한 것을 나타낸 도면이다.
도 26은 전술한 자료구조들과 메시지 이벤트를 하나의 클래스로 추상화하여 정리한 결과를 나타낸다.

실시 예들에서 사용되는 용어는 본 발명에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어들을 선택하였으나, 이는 당 분야에 종사하는 기술자의 의도 또는 판례, 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 발명의 설명 부분에서 상세히 그 의미를 기재할 것이다. 따라서 본 발명에서 사용되는 용어는 단순한 용어의 명칭이 아닌, 그 용어가 가지는 의미와 본 발명의 전반에 걸친 내용을 토대로 정의되어야 한다.

명세서 전체에서 어떤 부분이 어떤 구성요소를 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있음을 의미한다. 또한, 명세서에 기재된 "…부", "…모듈" 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 이는 하드웨어 또는 소프트웨어로 구현되거나 하드웨어와 소프트웨어의 결합으로 구현될 수 있다.

아래에서는 첨부한 도면을 참고하여 본 발명의 실시 예에 대하여 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나 본 발명은 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시 예에 한정되지 않는다.

이하에서는 도면을 참조하여 본 발명의 실시 예들을 상세히 설명한다.

도 2에서 설명한 기존의 멀티호밍 SCTP 노드 간의 S1AP 프로시져 통신의 문제점을 해결하기 위해서, 본 발명은 멀티호밍 SCTP 노드가 가진 IP주소를 탐색하여 알아낸 IP주소들을 저장하고, 그 중 하나를 한 노드의 대표 IP로 결정한다. 본 발명에 따르면, 프로시져 키를 만들 때, 메시지가 어떤 IP주소로 전송되더라도 대표 IP주소로 치환할 수 있으므로, 매번 동일한 프로시져 키를 만들 수 있어서, 하나의 프로시져로 엮어서 분석하는 것이 가능해진다.

도 2를 참조하여 설명하면, 본 발명이 기존의 멀티호밍 SCTP노드 통신 시스템에 적용되는 경우, SCTP 노드 A의 IP 주소 1.1.1.1과 1.1.1.2가 탐색되고, 이 중 1.1.1.1이 대표 IP주소로 결정된다. 또한, SCTP 노드 B의 IP주소 2.2.2.1과 2.2.2.2가 탐색되고, 2.2.2.1가 대표 IP주소로 결정된다. 도 2에서 InitialContextSetup Request/Response 메시지가 전송될 때, 각 노드에서 사용된 IP주소가 SCTP 노드 A에서는 1.1.1.1로 치환되고, SCTP 노드 B에 대해서는 IP주소가 2.2.2.1로 치환되므로, 프로시져 키가 동일하여, 하나의 프로시져로 분석이 불가능하다는 기존의 문제점이 발생되지 않는다.

표 4는 본 발명에 따른 시스템을 구성하는 모듈(module)과 각 모듈이 수행하는 기능을 일괄적으로 나타내고 있는 표이다. 표 4를 참조하면, 본 발명에 따른 시스템은, 하트비트청크송신부, 하트비트애크청크수신부, 테이블생성부, 대표주소결정부 및 패킷분석부를 포함하며, 테이블생성부는 세부모듈로서 IP주소추출부 및 테이블값기록부를 포함한다는 것을 알 수 있다. 각 모듈의 명칭은 각 모듈이 수행하는 기능에 부합하게 명명되었으며, 표 4에 도시된 모듈들은 본 발명에 따른 전체 시스템을 구성하는 모듈들의 일 예이므로, 실시 예에 따라서, 후술하는 기능들을 구현하는 다른 모듈들을 더 포함할 수 있다는 것은 이 분야의 통상의 지식을 가진 자에게 자명할 것이다.

표 4의 각 모듈 및 세부모듈은 물리적인 모듈일 뿐만 아니라 논리적으로 구현되는 모듈일 수도 있다. 즉, 표 4의 모듈은 가시적인 장치뿐만 아니라 스크립트로 기능을 구현하는 프로그램 형식의 모듈의 범주를 모두 포함한다. 또한, 본 발명에 따른 시스템은 후술하는 발신 SCTP 노드 및 수신 SCTP 노드 중 어느 하나에 포함된 형태로 구현되거나, 두 노드와 독립적으로 분리되어 두 노드간의 패킷을 분석하기 위한 독자적 시스템으로 구현될 수도 있다.

설명의 편의를 위해서, 표 4의 모듈 및 세부모듈의 기능을 실시 예별로 나열하는 방식으로 설명하고 나서, 각종 도면을 통해서 각 모듈들이 구체적으로 동작하는 방식을 설명하기로 한다.

먼저, 하트비트청크송신부는 적어도 두 개 이상의 IP주소를 갖는 발신 SCTP노드에서 하트비트 청크(HEARTBEAT chunk)를, 적어도 두 개 이상의 IP주소를 갖는 수신 SCTP 노드에 송신한다. 여기서, 발신 SCTP 노드는 하트비트 청크를 송신하는 노드이고, 수신 SCTP 노드는 하트비트 청크를 수신하는 노드를 의미한다. 전술한 것과 같이, 실제적으로는, SCTP 패킷의 하나의 제어 청크에 하트비트 청크가 정의되지만, 직관적인 설명을 위해서, 패킷이 아니라 청크 기준으로 설명하기로 한다.

하트비트애크청크수신부는 수신 SCTP 노드로부터 하트비트 청크에 대응되는 하트비트 애크 청크(HEARTBEAT-ACK chunk)를 수신한다.

테이블생성부는 하트비트 청크 및 하트비트 애크 청크에 포함된 정보를 기초로 하여, SCTP 노드 테이블을 생성한다.

실시 예에 따라서, 테이블생성부는 IP주소추출부 및 테이블값기록부를 포함할 수도 있다. IP주소추출부는 하트비트 애크 청크를 분석하여, 발신 SCTP 노드의 IP주소 1개 및 수신 SCTP 노드의 IP주소 1개 내지 2개를 추출한다. 테이블값기록부는 추출된 IP주소들을 SCTP노드 테이블에 포함시키는 기능을 수행한다.

대표주소결정부는 SCTP 노드 테이블을 기초로 하여 발신 SCTP 노드 및 수신 SCTP 노드의 대표 IP주소를 결정한다.

패킷분석부는 결정된 대표IP주소를 기초로 프로시져 키(procedure key)를 구성하여, 발신 SCTP 노드 및 수신 SCTP 노드간에 송신된 패킷을 분석한다.

선택적 일 실시 예로서, 발신 SCTP 노드 및 수신 SCTP 노드는 같은 개수의 IP주소를 가질 수 있다. 다른 선택적 일 실시 예로서, 발신 SCTP 노드가 하트비트 청크를 송신할 때의 발신 SCTP 노드 IP주소 및 수신 SCTP 노드 IP주소와, 수신 SCTP 노드가 하트비트 애크 청크를 송신할 때의 발신 SCTP 노드 IP주소 및 수신 SCTP 노드 IP주소가 각각 불일치할 수도 있다. 본 선택적 일 실시 예는, 도 4 및 도 5를 통해서 구체적으로 후술하기로 한다.

전술한 설명은 본 발명의 효과를 부각시키고 본 발명의 범주를 명확히 하기 위해서, 본 발명을 포괄적으로 설명한 것이며, 이하에서는 본 발명을 이용하여, 어떻게 SCTP 노드의 IP주소를 사전에 자동으로 탐색하고, 어떤 방식으로 IP 주소를 저장하며, 어떻게 대표 IP주소를 결정하고, 어떤 방식으로 메시지 전송에 사용된 IP주소를 대표 IP로 치환하는지에 대한 구체적인 설명을 하기로 한다.

먼저, 두 SCTP 노드 간에 association이 완료되면, SCTP 패스 매니지먼트(path management)기능에 의해서 각 SCTP 노드는 상대 SCTP 노드(peer)의 여러 목적지 전송 주소(destination transport address) 중 idle로 판단된 전송 주소로 주기적으로 하트비트 청크(HEARTBEAT chunk)를 전송하여 접근가능성을 모니터링 해야 한다. 이때, 목적지 전송 주소가 idle하다는 것은, 목적지 전송 주소에 대한 하트비트 주기 동안 전송경로의 RTT(Round Trip Time)를 측정하기 위해 사용될 수 있는 새로운 청크 또는 하트비트 청크가 아직 전송되지 않은 상태를 의미한다.

즉, 한 개의 SCTP 노드는 상대 SCTP 노드의 목적지 전송 주소가 idle상태가 될 때마다 하트비트 청크(HEARTBEAT chunk)를 전송하므로, 하트비트 프로시져를 분석하면 SCTP 노드의 전송 주소들을 탐색할 수 있게 된다.

하트비트 프로시져는 Request 메시지인 하트비트 청크와 Response 메시지인 하트비트 애크 청크로 구성된다. 하트비트 청크와 하트비트 애크 청크는 멀티호밍 SCTP 노드 사이에서는 서로 다른 전송 경로로 전달될 수 있지만, 하트비트 애크 청크는 반드시 하트비트 청크가 전송된 Source IP 주소(발신 SCTP 노드의 특정한 하나의 IP주소)로만 전송되어야만 하는 제약사항이 있다.

도 3은 멀티호밍 SCTP 노드 간 하트비트 프로시져 통신의 일 유형을 설명하기 위한 도면이다

도 3은 2개의 IP주소를 사용하는 멀티호밍 SCTP 노드간 하트비트 프로시져가 통신되는 경우를 나타내는 것으로서, 원으로 표시된 부분처럼 하트비트 청크의 소스 IP주소와 하트비트 애크 청크의 목적지(destination) IP 주소는 반드시 일치해야만 한다. 도 3에서는 하트비트 청크를 송신한 SCTP 노드 A의 IP주소와 하트비트 애크 청크를 수신한 SCTP 노드의 A의 IP주소가 1.1.1.1로 동일하므로, 하나의 프로시져로 엮어서 패킷분석을 할 수 있다.

또한, 발신 SCTP 노드는 하트비트 청크를 전송할 때, 하트비트 청크에 하트비트 정보 파라미터(Heartbeat information parameter)를 반드시 포함시켜야 한다. 이어서, 수신 SCTP 노드는 하트비트 청크 안의 하트비트 정보 파라미터를 원본 그대로 하트비트 애크 청크안에 포함시켜서 전송하게 된다. 따라서, 하트비트 청크와 하트비트 애크 청크안에는 하트비트 정보 파라미터가 공통적으로 포함된다.

하트비트 정보는 가변길이 정보로서, 일반적으로 발신 SCTP 노드가 하트비트 청크를 전송할 때의 현재 시간 및 목적지 전송 주소 정보를 포함한다. 다수의 SCTP 노드 간 전송되는 하트비트 프로시져들 중에서 하나의 하트비트 프로시져를 분석하기 위해서는 발신 SCTP 노드의 IP 주소(하트비트 청크의 소스 IP주소, 하트비트 애크 청크의 목적지 IP 주소)와 하트비트 정보 파라미터를 키(key)로 구성하여 일치하는 패킷들을 찾아내야 한다.

도 4 및 도 5는 멀티호밍 SCTP 노드간 하트비트 프로시져 통신의 두 가지 유형을 각각 나타내고 있다.

보다 구체적으로, 도 4는 수신 노드 B의 IP주소 2.2.2.2에서 하트비트 청크를 수신했음에도 불구하고, 수신 노드 B의 IP주소 2.2.2.1에서 하트비트 애크 청크를 송신하는 유형이고, 도 5는 수신 노드 A의 IP주소 1.1.1.2에서 하트비트 청크를 수신하였지만, 수신 노드 A의 IP주소 1.1.1.1에서 하트비트 애크 청크를 송신한 유형으로서 두 가지 유형 모두 발신 SCTP 노드의 IP 주소와 하트비트 정보 파라미터를 키로 구성하여 프로시져 분석이 가능하다.

본 발명은 도 3 내지 도 5와 같은 상황에서 네트워크를 통해 전송되는 패킷 흐름 속에서 패킷(메시지)를 실시간으로 분석하기 위해서 메시지 별로 처리를 수행하게 되며, 이하에서는, 설명의 효율성을 높이기 위해 각 단계를 메시지별로 대응시켜 설명하기로 한다.

본 발명에서는 하트비트 프로시져를 처리하기 위해서, 기존의 구조를 개량하여 사용한다. 구체적으로, 하트비트 청크(heartbeat chunk)는 하트비트 맵(heartbeat map)과 하트비트 타이머 큐(heartbeat timer queue)를 포함한다.

도 6은 하트비트 맵과 하트비트 타이머 큐를 도식적으로 나타낸 도면이다.

하트비트 맵은 하트비트 애크 청크와 연관된 하트비트 청크의 정보를 찾기 위해 사용된다. 하트비트 맵은 해시 맵(hash map) 자료구조로 키(heartbeat_key)는 snd_ip 및 hn_info로 구성되고, Value(heartbeat_value)는 rcv_ip_2, rcv_port, rcv_vtag로 구성된다.

먼저, snd_ip는 발신 노드의 IP주소를 의미하고, hb_info는 하트비트 정보 파라미터(heartbeat information parameter)를 의미한다. rcv_ip_2는 하트비트 청크 전송시에 사용된 수신 노드의 IP주소, rcv_port는 수신 노드의 SCTP 포트, rcv_vtag는 수신 노드의 SCTP Verification Tag를 의미한다. 여기서, rcv_ip_2에 숫자 2가 붙은 이유는, 하트비트 청크 전송 시 사용된 수신 노드의 IP주소와 하트비트 애크 청크 전송 시 사용된 수신 노드의 IP주소(rcv_ip_1)를 구분하기 위함이다. 하트비트 청크와 하트비트 애크 청크가 다른 경로로 전송된 경우, rcv_ip_1과 rcv_ip_2는 다르며, 같은 경로로 전송된 경우는 동일하다.

이어서, 하트비트 타이머 큐는 하트비트 맵에 삽입된 엘리먼트(element)가 지정된 시간 동안 처리되지 않는 경우, 하트비트 맵의 크기가 계속해서 커질 수 있으므로, 이를 방지하기 위한 수단이며, 지정된 시간 이후에 하트비트 맵의 엘리먼트를 삭제하기 위해서 사용된다. 하트비트 타이머 큐는 큐(queue) 자료구조로 Value는 time, snd_ip, hb_info로 구성된다. 여기서, time은 패킷이 유입된 시간으로서, 1970년 1월 1일로부터 경과한 시간을 초 단위로 나타내며, snd_ip는 발신 노드의 IP주소, hb_info는 하트비트 정보 파라미터를 각각 의미한다.

도 7은 하트비트 청크가 처리되는 과정을 설명하기 위한 도면이다.

표 4에서 설명한 하트비트청크송신부는, 하트비트 청크가 발생시 패킷으로부터 하트비트 키(발신 노드 IP주소, 하트비트 정보 파라미터), 하트비트 값(수신 노드 IP주소, 수신 노드 SCTP 포트, 수신 노드 SCTP Verification Tag)을 구성하여 하트비트 맵에 삽입한다.

표 5 및 표 6은 도 7에서 하트비트 청크를 처리한 후의 하트비트맵과 하트비트 타이머 큐의 자료구조 테이블을 각각 나타낸다. hb_info는 보통 8bytes 이상의 가변길이 데이터를 이용하나, 표 5 및 표 6에서는 설명의 편의를 위해서 4byte hex 코드로 표현되었다.

하트비트청크송신부는 하트비트 타이머 큐로 타이머 처리를 하기 위해서 하트비트 타이머 만료 기간을 몇 초로 할 지 사전에 설정하여야 한다. 일반적으로, 하트비트 프로시져 통신 소요시간 보다 더 길게 설정한다. 하트비트 타이머 처리 방법은 하트비트 청크 발생 시 마다 하트비트 타이머 큐의 첫 엘리먼트부터 순차적으로 조회하면서, 현재 유입된 패킷의 time값과 엘리먼트의 time값의 차이가 하트비트 타이머 만료 기간보다 큰 경우, timer가 만료된 것으로 판단하는 방식이 이용된다. 하트비트 타이머 큐는 FIFO(First In First Out) 자료구조이므로, 엘리먼트를 순차적으로 조회해 나갈 때 하트비트 타이머 만료 기간보다 크지 않은 엘리먼트가 발견되면 순차 조회를 중단하는 방식으로 운용될 수 있다. 즉, 타이머가 만료된 엘리먼트에 대해 하트비트 키와 일치하는 하트비트 맵의 엘리먼트를 삭제하고, 하트비트 타이머 큐의 엘리먼트도 삭제되는 방식으로 동작하게 된다.

이하에서는, 하트비트 청크가 송신된 이후의 과정으로서, 하트비트 애크 청크의 처리 방법을 설명한다. 하트비트 애크 청크 발생시 패킷으로부터 하트비트 키(발신 노드 IP주소, 하트비트 정보 파라미터)를 구성하여, 하트비트 맵에서 키가 일치하는 엘리먼트를 찾으면 하나의 하트비트 프로시져가 탐색된 것이 된다.

도 8은 하트비트 애크 청크 처리시에 하트비트 키가 검색되는 과정을 도식적으로 나타낸 것이다.

도 8을 참조하면, 하트비트 키인 발신 노드 IP주소 및 하트비트 정보 파라미터가 하트비트 맵에서 동일하게 존재하는 것을 알 수 있으며, 이 경우, 하나의 하트비트 프로시져가 탐색된 것이 된다.

본 발명에서는, 하트비트 애크 청크에서 추가적으로 발신 노드의 SCTP 포트(snd_port), 발신 노드의 SCTP Verification Tag(snd_vtag), 하트비트 애크 청크 전송 시 사용된 수신 노드의 IP주소(rcv_ip_1)에 대한 정보를 획득할 수 있다.

도 9는 하트비트 프로시져를 통해 획득된 정보들을 도식적으로 나타낸다.

도 9를 참조하면, 하나의 하트비트 프로시져 분석을 통해 발신 노드의 IP 주소 1개와 수신 노드의 IP 주소 1개 내지 2개(전송 경로가 같은 경우 1개, 다른 경우 2개)에 대한 정보가 획득될 수 있다는 것을 알 수 있다.

이어서, 테이블생성부가 SCTP 노드 테이블을 생성하는 과정을 설명한다.

하트비트 프로시져를 통해 획득된 정보들은 SCTP 노드 테이블로 저장되어 관리된다.

표 7 내지 표 9는 SCTP 노드 테이블을 구성하는 각각의 자료구조 테이블을 나타낸다. 표 7은 repr_ip_map, 표 8은 node_map, 표 9는 assoc_map을 각각 나타낸다.

먼저, repr_ip_map은 메시지 전송에 사용된 SCTP 노드의 IP주소를 대표 IP주소로 치환하기 위해 사용된다. repr_ip_map은 해시 맵(hash map) 자료구조로Key(repr_ip_key)는 ip(SCTP 노드의 ip주소)로 구성되고, Value(repr_ip_value)는 SCTP 노드의 대표 IP 주소인 repr_ip로 구성된다.

node_map은 SCTP 노드의 정보를 관리하기 위해 사용된다. node_map도 해시 맵 자료구조를 갖고 있으며, Key(node_key)는 SCTP 노드의 대표 IP 주소(repr_ip)로 구성되고, Value(node_value)는 SCTP 노드의 association 정보(assoc_map) 및 SCTP 노드의 IP 주소(ip_set)들로 구성된다.

assoc_map은 node_map의 Value인 node_value의 member로서, 한 SCTP 노드와 연결된 Peer SCTP 노드들과의 association 정보를 관리하기 위해 사용된다. assoc_map도 해시 맵 자료구조를 갖고 있으며, Key(assoc_key)는 vtag 및 port로 구성된다. 여기서, vtag는 SCTP 노드 자신의 Verification Tag를 의미하고, port는 SCTP 노드 자신의 SCTP Port를 의미한다. 또한, assoc_map의 Value(assoc_value)는 peer_assoc_key와 peer_repr_ip로 구성된다. peer_assoc_key는 위의 assoc_key와 같은 데이터 유형이면서, Peer SCTP 노드의 association 정보를 표현하고, peer_repr_ip는 Peer Representative IP Address의 약칭으로서, Peer SCTP 노드의 대표 IP 주소를 의미한다. peer_assoc_key는 vtag 및 port를 포함하고, vtag는 peer SCTP 노드의 Verification Tag, port는 peer SCTP 노드의 SCTP Port를 각각 의미한다.

node_map에서 ip_set은 node_map의 Value인 node_value의 member로, 한 SCTP 노드에 대해 탐색된 모든 IP 주소들을 관리하기 위해 사용된다. ip_set은 hash set 자료구조로서, Value는 SCTP 노드의 IP 주소로 구성된다. 본 발명에서, 자료구조에 IP 주소 외에 vtag, port등의 association정보들을 포함시킨 이유는 association정보를 통해 peer SCTP 노드 정보를 찾기 위해서이다.

이하에서는, 하트비트 프로시져(HEARTBEAT Procedure)에서 획득된 정보를 위의 자료구조 테이블에 저장하는 방법을 설명하며, 설명의 편의를 위해서, 의사코드 (Pseudo code)를 추가하여 설명하기로 한다.

도 10은 node_map에 기존에 생성된 노드 엘리먼트가 있는지 여부를 찾기 위해 사용되는 의사코드의 일 예를 나타낸다.

먼저, snd_assoc_key 및 rcv_assoc_key를 다음과 같이 정의한다. snd_assoc_key는 Sender Association Key를 의미하고, snd_vtag와 snd_port로 구성된다. rcv_assoc_key은 Receiver Association Key를 의미하고, rcv_vtag와 rcv_port로 구성된다. snd_assoc_key 및 rcv_assoc_key는 assoc_map의 Key인 assoc_key와 동일한 데이터 유형이다.

snd_ip, rcv_ip_1, rcv_ip_2 각각을 Key로 repr_ip_map에서 연관된 repr_ip element를 찾고, repr_ip를 Key로 node_map에서 연관된 node element를 찾는다. 찾은 node element를 각각 snd_node, rcv_node_1, rcv_node_2로 참조한다. 단 rcv_ip_2는 도 4 및 도 5와 같이 rcv_ip_2가 rcv_ip_1과 다른 주소인 경우에만 찾는다.

도 11은 도 10의 의사코드를 통해서 node element를 찾는 과정을 도식적으로 나타낸 도면이다.

구체적으로, 도 11에는, snd_ip, rcv_ip_1, rcv_ip_2 각각을 Key로 repr_ip_map에서 연관된 repr_ip element를 찾고, repr_ip를 Key로 node_map에서 연관된 node element를 찾는 과정이 표현되어 있다.

위와 같은 과정을 거쳐서, 기존의 node element를 찾았다면, 수신 노드 엘리먼트를 병합하는 단계를 거쳐야 한다.

본 발명에서는, rcv_ip_1, rcv_ip_2 각각에 상응하는 node element인 rcv_node_1, rcv_node_2의 존재 유무에 따라, 총 4개의 경우의 수가 생긴다.

도 12는 rcv_node_1, rcv_node_2가 모두 존재하는 경우에 있어서 적용되는 의사코드를 나타낸다.

도 12의 의사코드는 rcv_ip_1과 rcv_ip_2의 주소가 다른 상황에서 둘 다 node element를 찾은 경우에 적용된다.

두 node element의 repr_ip가 동일한 경우에는, 같은 node element를 참조하므로 병합과정을 수행할 필요 없이 발신 노드 및 수신 노드의 엘리먼트를 구성하는 다음 단계로 넘어간다.

두 node element의 repr_ip가 다른 경우에는, 서로 다른 node element를 참조한다. 하트비트 프로시져(HEARTBEAT Procedure)를 통해 획득된 두 receiver IP 주소는 하나의 SCTP 노드에 속하므로, 서로 다른 두 node element를 하나로 병합한다. 여기서, rcv_node_2의 정보를 rcv_node_1로 이동시키고 rcv_node_2를 삭제하면 된다.

두 node element의 repr_ip가 다른 경우 다음 과정을 수행한다. 먼저, rcv_node_2의 ip_set의 각 ip element에 대해 ip를 Key로 repr_ip_map에서 연관된 repr_ip element를 찾는다. 이 repr_ip element의 Value인 repr_ip 값을 rcv_node_1의 repr_ip 값으로 변경하고, rcv_node_1의 ip_set에 ip element를 추가한다. 그 다음으로 rcv_node_2의 assoc_map의 각 assoc element에 대해 assoc_value의 peer_repr_ip를 Key로 node_map에서 연관된 peer node element를 찾는다. assoc_value의 peer_assoc_key를 Key로 peer node element의 assoc_map에서 연관된 peer assoc element를 찾는다. 그 다음에는, peer assoc element의 assoc_value안의 peer_repr_ip를 rcv_node_1의 repr_ip로 변경하고, rcv_node_1의 assoc_map에 assoc element를 추가하고, 마지막으로 node_map에서 rcv_node_2를 삭제한다.

도 13은 rcv_node_1는 존재하지만, rcv_node_2가 존재하지 않는 경우에 있어서 적용되는 의사코드를 나타낸다.

도 13은 rcv_ip_1에 해당하는 node element만 검색된 경우에 적용된다. 즉, rcv_ip_2가 rcv_ip_1과 같은 주소여서 node element를 찾지 않은 경우이거나, rcv_ip_2가 rcv_ip_1과 다른 주소이나 node element를 찾지 못한 경우이다. 따라서 rcv_ip_2가 rcv_ip_1과 다른 주소이면 후자의 경우이고, rcv_ip_2는 새로 탐색된 ip 주소이다. 만약 rcv_ip_2가 rcv_ip_1과 다르면, rcv_node_1의 ip_set에 element(Value: rcv_ip_2)를 추가하고, repr_ip_map에 element(Key: rcv_ip_2, Value: rcv_node_1의 repr_ip)를 추가한다.

도 14는 rcv_node_1은 존재하지 않지만, rcv_node_2는 존재하는 경우에 있어서 적용되는 의사코드를 나타낸다.

도 14는 rcv_ip_2에 해당하는 node_element만 찾은 경우에 적용된다. 여기서, rcv_ip_1은 rcv_ip_2와 다른 주소이며, 새로 탐색된 ip 주소이다. rcv_node_2의 ip_set에 element(Value: rcv_ip_1)가 추가되고, repr_ip_map에 element(Key: rcv_ip_1, Value: rcv_node_2의 repr_ip)가 추가된다.

마지막으로, rcv_node_1 및 rcv_node_2에 해당하는 node element가 검색되지 않은 경우가 있다. 이 경우, 바로 다음 단계로 넘어가게 되고, 여기서, receiver(수신 노드)의 node element를 생성하지 않는 이유는, 다음 단계 처리 과정에서 snd_node가 존재할 경우 snd_node의 association 정보를 통해 receiver의 node element를 찾을 수 있는 가능성이 있기 때문이다.

전술한 것과 같이 총 네 가지 경우의 수로 수신 노드 엘리먼트(receiver node element)가 병합되었다면, 그 다음에는 송신 노드 및 수신 노드의 엘리먼트를 구성하는 단계로 이어진다.

그 전 단계에서 병합된 하나의 receiver node element(rcv_node_1 또는 rcv_node_2)를 여기서부터는 rcv_node로 참조한다. 전단계와 마찬가지로, 본 단계도 snd_node와 rcv_node의 존재 유무에 따라, 총 4개의 경우의 수로 나뉘어진다.

도 15는 송신 노드와 수신 노드 모두 존재하는 경우에 적용되는 의사코드를 나타낸다.

첫 번째 경우의 수로서, 서로의 SCTP association정보가 일치하는지 확인하게 된다.

snd_assoc_key를 Key로 snd_node의 assoc_map에서 연관된 sender assoc element를 찾는다. sender assoc element를 찾은 경우, peer_assoc_key와 peer_repr_ip가 receiver association정보(rcv_assoc_key, rcv_node의 repr_ip)와 다른 경우에 업데이트한다. sender assoc element를 못 찾은 경우, assoc_map에 element(Key: snd_assoc_key, Value: (rcv_assoc_key, rcv_node의 repr_ip))를 추가한다.

rcv_assoc_key를 Key로 rcv_node의 assoc_map에서 연관된 receiver assoc element를 찾는다. receiver assoc element를 찾은 경우, peer_assoc_key와 peer_repr_ip가 sender association정보(snd_assoc_key, snd_node의 repr_ip)와 다른 경우에 업데이트한다. receiver assoc element를 못 찾은 경우, assoc_map에 element(Key: rcv_assoc_key, Value: (snd_assoc_key, snd_node의 repr_ip))를 추가한다.

도 16 및 도 17은 송신 노드만 존재하는 경우에 적용되는 의사코드를 나타낸다.

도 16 및 도 17은, 두 번째 경우의 수로서, 송신 노드만 존재하는 경우에 적용되는 의사코드이다. 도 16 및 도 17은 snd_node의 assoc_map에서 receiver의 association 정보가 있는 경우 receiver node element를 찾는데 사용될 수 있다. 만약 receiver의 association 정보가 일치하지 않거나 없는 경우 rcv_ip_1을 대표 IP 주소로 새로운 receiver node를 생성한다.

snd_assoc_key를 Key로 snd_node의 assoc_map에서 연관된 sender assoc element를 찾는다.

sender assoc element를 찾은 경우 peer_assoc_key가 rcv_assoc_key와 동일하면 peer_repr_ip로 rcv_node를 찾기 위해 rcv_repr_ip로 저장한다. 만약 peer_assoc_key가 rcv_assoc_key와 다르면 peer_assoc_key를 rcv_assoc_key로, peer_repr_ip를 rcv_ip_1으로 업데이트하고, rcv_ip_1를 rcv_repr_ip로 저장한다.

sender assoc element를 찾지 못한 경우 assoc_map에 element(Key: snd_assoc_key, Value: (rcv_assoc_key, rcv_ip_1))를 추가하고 rcv_ip_1를 rcv_repr_ip로 저장한다.

rcv_repr_ip를 Key로 node_map에서 연관된 receiver node element를 찾는다.

receiver node element를 찾은 경우 rcv_assoc_key를 Key로 assoc_map에서 연관된 receiver assoc element를 찾는다.

receiver assoc element를 찾은 경우 peer_assoc_key와 peer_repr_ip가 sender association정보(snd_assoc_key, snd_node의 repr_ip)와 다른 경우 업데이트한다.

receiver assoc element를 찾지 못한 경우 assoc_map에 element(Key: rcv_assoc_key, Value: (snd_assoc_key, snd_node의 repr_ip))를 추가한다.

receiver node element를 찾지 못한 경우 node_map에 element(Key: rcv_repr_ip, Value: default)를 추가하고, 이 node의 assoc_map에 element(Key: rcv_assoc_key, Value: (snd_assoc_key, snd_node의 repr_ip))를 추가한다.

receiver node element의 ip_set에 rcv_ip_1를 추가하고 repr_ip_map에 element(Key: rcv_ip_1, Value: receiver node element의 repr_ip)를 추가한다.

만약 rcv_ip_2가 rcv_ip_1과 다른 경우 receiver node element의 ip_set에 rcv_ip_2를 추가하고 repr_ip_map에 element(Key: rcv_ip_2, Value: receiver node element의 repr_ip)를 추가한다.

도 18 및 도 19는 수신 노드만 존재하는 경우에 적용된 의사코드를 나타낸다.

도 18 및 도 19는, 세 번째 경우의 수로서, 수신 노드만 존재하는 경우에 적용되는 의사코드이다. 도 18 및 도 19는 rcv_node의 assoc_map에서 sender의 association 정보가 있는 경우 sender node element를 찾는데 사용될 수 있다. 만약 sender의 association 정보가 일치하지 않거나 없는 경우 snd_ip를 대표 IP 주소로 새로운 sender node를 생성한다.

rcv_assoc_key를 Key로 rcv_node의 assoc_map에서 연관된 receiver assoc element를 찾는다.

receiver assoc element를 찾은 경우, peer_assoc_key가 snd_assoc_key와 동일하면 peer_repr_ip로 snd_node를 찾기 위해 snd_repr_ip로 저장한다. 만약 peer_assoc_key가 snd_assoc_key와 다르면 peer_assoc_key를 snd_assoc_key로, peer_repr_ip를 snd_ip로 업데이트하고, snd_ip를 snd_repr_ip로 저장한다.

receiver assoc element를 찾지 못한 경우, assoc_map에 element(Key: rcv_assoc_key, Value: (snd_assoc_key, snd_ip))를 추가하고 snd_ip를 snd_repr_ip로 저장한다.

snd_repr_ip를 Key로 node_map에서 연관된 sender node element를 찾는다.

sender node element를 찾은 경우, snd_assoc_key를 Key로 assoc_map에서 연관된 sender assoc element를 찾는다.

sender assoc element를 찾은 경우, peer_assoc_key와 peer_repr_ip가 receiver association정보(rcv_assoc_key, rcv_node의 repr_ip)와 다른 경우 업데이트한다. sender assoc element를 찾지 못한 경우, assoc_map에 element(Key: snd_assoc_key, Value: (rcv_assoc_key, rcv_node의 repr_ip))를 추가한다.

sender node element를 찾지 못한 경우, node_map에 element(Key: snd_repr_ip, Value: default)를 추가하고, 이 node의 assoc_map에 element(Key: snd_assoc_key, Value: (rcv_assoc_key, rcv_node의 repr_ip))를 추가한다.

sender node element의 ip_set에 snd_ip를 추가하고 repr_ip_map에 element(Key: snd_ip, Value: sender node element의 repr_ip)를 추가한다.

도 20은 송신 노드 및 수신 노드 모두 존재하지 않는 경우에 적용되는 의사코드를 나타낸다.

도 20은, 네 번째 경우의 수로서, 송신 노드 및 수신 노드 모두 존재하지 않는 경우에 적용되는 의사코드이다. 도 20에 따르면, node_map에 둘 다 등록되지 않은 경우로 snd_ip를 대표 IP 주소로 sender node를 생성하고, rcv_ip_1를 대표 IP 주소로 receiver node를 생성한다.

node_map에 새로운 sender node element(Key: snd_ip, Value: default)를 추가한다.

sender node element의 assoc_map에 element(Key: snd_assoc_key, Value: (rcv_assoc_key, rcv_ip_1))를 추가한다.

sender node element의 ip_set에 snd_ip를 추가하고, repr_ip_map에 element(Key: snd_ip, Value: sender node element의 repr_ip)를 추가한다.

node_map에 새로운 receiver node element(Key: rcv_ip_1, Value: default)를 추가한다. receiver node element의 assoc_map에 element(Key: rcv_assoc_key, Value: (snd_assoc_key, snd_ip))를 추가한다.

receiver node element의 ip_set에 rcv_ip_1를 추가하고, repr_ip_map에 element(Key: rcv_ip_1, Value: receiver node element의 repr_ip)를 추가한다.

만약 rcv_ip_2가 rcv_ip_1과 다른 경우, receiver node element의 ip_set에 rcv_ip_2를 추가하고, repr_ip_map에 element(Key: rcv_ip_2, Value: receiver node element의 repr_ip)를 추가한다.

도 21은 도 4와 같은 유형의 상태에서 테이블생성부가 생성한 SCTP 노드 테이블의 일 예를 도식적으로 나타낸다.

도 21은 하트비트 프로시져 정보를 처리하여 획득된 SCTP 노드 관리 자료 구조로서, 후술하는 IP주소 치환 과정을 거쳐서 최종적으로 패킷 분석이 정확히 수행될 수 있도록 한다.

도 22는 도 21의 결과에서 도 5의 하트비트 프로시져 정보를 추가적으로 처리하여 저장한 경우 생성되는 SCTP 노드 테이블(자료구조)의 일 예를 도식적으로 나타낸다.

도 22를 도 21과 비교했을 때, SCTP 노드의 1.1.1.2 IP주소 정보가 추가된 것을 알 수 있으며, 이로써, 발신 SCTP 노드 및 수신 SCTP 노드의 모든 IP주소를 탐색하게 된다.

이하에서는, 그 다음 과정으로서, 셧다운 또는 어보트 프로시져에 대한 과정을 설명한다.

SCTP association은 SHUTDOWN Procedure(SHUTDOWN, SHUTDOWN ACK, SHUTDOWN COMPLETE chunk) 또는 ABORT Procedure(ABORT chunk)를 통해 종료된다. 두 SCTP 노드간 association 종료 시 SCTP 노드 관리 자료구조에 저장된 association 정보는 삭제된다. SHUTDOWN Procedure와 ABORT Procedure의 메시지 중에서 SHUTDOWN COMPLETE chunk 또는 ABORT chunk 메시지 발생 시마다 assoc_timer_queue에 삭제에 필요한 정보를 등록해 놓았다가, 추후, timeout될 때 association 정보를 삭제한다. 이때, timeout으로 삭제 처리를 지연시키는 것은 실시간으로 패킷을 분석하는 환경에서 SCTP 유저 어플리케이션 패킷이 늦게 도착하는 경우를 대비하기 위함이다.

표 10은 assoc_timer_queue의 자료 구조를 설명하기 위한 표이다. assoc_timer_queue는 queue 자료구조를 갖고 있으며, Value는, time, src_ip, dst_ip, src_port, dst_port로 구성된다. time은 Packet이 유입된 시간, src_ip는 Source IP Address, dst_ip는 Destination IP Address, src_port는 Source SCTP Port, dst_port는 Destination SCTP Port를 각각 의미한다.

도 23 및 도 24는 셧다운 또는 어보트 프로시져가 발생한 경우에 적용되는 의사코드를 나타내고 있다.

구체적으로, 도 23 및 도 24는 SCTP 노드 간의 association을 삭제하는 방법을 의사코드로 구현한 것이다.

먼저, assoc_timer_queue로 timer 처리를 하기 위해서 assoc timer 만료 기간을 몇 초로 할지 사전에 설정하여야 한다. 이 설정 값은 SCTP User Application Packet이 종료 메시지 발생 후 최대 몇 초간 더 전송될 수 있는지를 의미한다. SHUTDOWN COMPLETE chunk 또는 ABORT chunk 발생 시마다 assoc_timer_queue에 element(Packet time, Source IP Address, Destination IP Address, Source port, Destination port)를 추가한다.

Timer 만료 확인 시점은 HEARTBEAT chunk 발생 시마다 heartbeat_timer_queue를 확인한 후에 assoc_timer_queue를 확인한다. assoc_timer_queue의 첫 element부터 순차적으로 조회하면서 현재 유입된 Packet의 time 값과 element의 time 값의 차이가 assoc timer 만료 기간보다 큰 경우 timer가 만료된 것으로 판단한다. heartbeat_timer_queue처럼 assoc_timer_queue도 FIFO 자료구조이므로 element를 순차적으로 조회해 나갈 때 assoc timer 만료 기간보다 크지 않은 element가 발견되면 순차 조회를 중단하면 된다.

이어서, timer 만료된 element에 대해 다음 association 삭제 방법을 실행한다. src_ip, dst_ip 각각을 Key로 repr_ip_map에서 연관된 repr_ip element를 찾고 repr_ip를 Key로 node_map에서 연관된 node element를 찾는다. 찾은 node element를 각각 src_node, dst_node로 참조한다. src_node의 assoc_map을 순차 조회하면서 assoc element가 3개의 조건을 모두 만족할 때 assoc element를 삭제하고 조회를 중단한다. 3개의 조건은, assoc_key의 port가 src_port와 같고, peer_assoc_key의 port가 dst_port와 같으며, peer_repr_ip가 dst_node의 repr_ip와 같을 때 만족된 것으로 간주된다.

dst_node의 assoc_map을 순차 조회하면서 assoc element가 3개의 조건을 모두 만족할 때 assoc element를 삭제하고 조회를 중단한다. 3개의 조건은 assoc_key의 port가 dst_port와 같고, peer_assoc_key의 port가 src_port와 같으며, peer_repr_ip가 src_node의 repr_ip와 같을 때 만족된 것으로 간주된다.

src_node의 assoc_map에 저장된 element수가 0인 경우 ip_set의 모든 element에 대해 repr_ip_map에서 연관된 repr_ip element를 삭제하고, node_map에서 src_node를 삭제한다. dst_node의 assoc_map에 저장된 element 수가 0인 경우 ip_set의 모든 element에서 repr_ip_map에서 연관된 repr_ip element를 삭제하고, node_map에서 dst_node를 삭제한다.

도 25는 IP주소를 치환하는 과정을 의사코드로 구현한 것을 나타낸 도면이다.

SCTP 유저 어플리케이션 패킷을 분석하는 응용 프로그램에서 HEARTBEAT Procedure정보로 구축한 SCTP 노드 정보를 사용하여 SCTP 노드간 전송된 유저 어플리케이션 메시지 패킷의 Source IP 주소, Destination IP 주소를 각각 대표 IP 주소로 치환하면 Procedure Key를 동일하게 만들 수 있게 되어, 종래의 문제점을 해결할 수 있다.

응용 프로그램에서 function을 이용하여 치환을 할 경우, 도 25와 같은 의사코드(Pseudo Code)처럼 정의할 수 있다. function 내에서는 원래 IP 주소(origin_ip)를 Key로 repr_ip_map에서 연관된 repr_ip element를 찾는다. repr_ip element를 찾은 경우 repr_ip를 반환하고 repr_ip element를 찾지 못한 경우 원래 IP 주소를 반환한다.

최종적으로 패킷분석부는 대표 IP주소로 치환하는 방식으로 얻어진 결과를 분석함으로써, 멀티호밍 SCTP 노드 간의 패킷 분석의 정확도를 증대시킬 수 있게 된다.

도 26은 전술한 자료구조들과 메시지 이벤트를 하나의 클래스로 추상화하여 정리한 결과를 나타낸다.

도 26에서, 자료구조 정의는 C++11 프로그램 문법을 참조하여 기술되었다.

기존에는 Multi-Homing SCTP 노드간 메시지 전송경로가 변화하는 경우 IP 주소가 변경되어 User Application 프로토콜의 Procedure를 분석할 수 없었다.

반면, 본 발명에 따르면, 멀티호밍 SCTP 노드가 사용하는 IP 주소를 자동으로 탐색하여 구축한 IP 주소 정보를 바탕으로 SCTP 노드간 메시지 전송 경로가 변화하여 IP주소가 변경되더라도 SCTP 노드를 식별할 수 있게 되어, 유저 어플리케이션 프로토콜의 프로시져를 분석할 수 있다. 본 발명은, 멀티호밍 SCTP 노드뿐만 아니라 싱글호밍 SCTP 노드에도 적용가능하며, 두 종류의 SCTP 노드가 혼합되어 있는 환경에서도 적용될 수 있는 확장성을 가진다.

이상 설명된 본 발명에 따른 실시 예는 컴퓨터상에서 다양한 구성요소를 통하여 실행될 수 있는 컴퓨터 프로그램의 형태로 구현될 수 있으며, 이와 같은 컴퓨터 프로그램은 컴퓨터로 판독 가능한 매체에 기록될 수 있다. 이때, 매체는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체, CD-ROM 및 DVD와 같은 광기록 매체, 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical medium), 및 ROM, RAM, 플래시 메모리 등과 같은, 프로그램 명령어를 저장하고 실행하도록 특별히 구성된 하드웨어 장치를 포함할 수 있다.

한편, 상기 컴퓨터 프로그램은 본 발명을 위하여 특별히 설계되고 구성된 것이거나 컴퓨터 소프트웨어 분야의 당업자에게 공지되어 사용 가능한 것일 수 있다. 컴퓨터 프로그램의 예에는, 컴파일러에 의하여 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용하여 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드도 포함될 수 있다.

본 발명에서 설명하는 특정 실행들은 일 실시 예들로서, 어떠한 방법으로도 본 발명의 범위를 한정하는 것은 아니다. 명세서의 간결함을 위하여, 종래 전자적인 구성들, 제어 시스템들, 소프트웨어, 상기 시스템들의 다른 기능적인 측면들의 기재는 생략될 수 있다. 또한, 도면에 도시된 구성 요소들 간의 선들의 연결 또는 연결 부재들은 기능적인 연결 및/또는 물리적 또는 회로적 연결들을 예시적으로 나타낸 것으로서, 실제 장치에서는 대체 가능하거나 추가의 다양한 기능적인 연결, 물리적인 연결, 또는 회로 연결들로서 나타내어질 수 있다. 또한, “필수적인”, “중요하게” 등과 같이 구체적인 언급이 없다면 본 발명의 적용을 위하여 반드시 필요한 구성 요소가 아닐 수 있다.

본 발명의 명세서(특히 특허청구범위에서)에서 “상기”의 용어 및 이와 유사한 지시 용어의 사용은 단수 및 복수 모두에 해당하는 것일 수 있다. 또한, 본 *?* 발명에서 범위(range)를 기재한 경우 상기 범위에 속하는 개별적인 값을 적용한 발명을 포함하는 것으로서(이에 반하는 기재가 없다면), 발명의 상세한 설명에 상기 범위를 구성하는 각 개별적인 값을 기재한 것과 같다. 마지막으로, 본 발명에 따른 방법을 구성하는 단계들에 대하여 명백하게 순서를 기재하거나 반하는 기재가 없다면, 상기 단계들은 적당한 순서로 행해질 수 있다. 반드시 상기 단계들의 기재 순서에 따라 본 발명이 한정되는 것은 아니다. 본 발명에서 모든 예들 또는 예시적인 용어(예들 들어, 등등)의 사용은 단순히 본 발명을 상세히 설명하기 위한 것으로서 특허청구범위에 의해 한정되지 않는 이상 상기 예들 또는 예시적인 용어로 인해 본 발명의 범위가 한정되는 것은 아니다. 또한, 당업자는 다양한 수정, 조합 및 변경이 부가된 특허청구범위 또는 그 균등물의 범주 내에서 설계 조건 및 팩터에 따라 구성될 수 있음을 알 수 있다.

Claims

멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 방법으로서,
적어도 두 개 이상의 IP주소를 갖는 발신 SCTP노드에서 하트비트 청크(HEARTBEAT chunk)를 적어도 두 개 이상의 IP주소를 갖는 수신 SCTP노드에 송신하는 하트비트청크송신단계;
상기 수신 SCTP노드로부터 상기 하트비트 청크에 대응되는 하트비트 애크 청크(HEARTBEAT ACK chunk)를 수신하는 하트비트애크청크수신단계;
상기 하트비트청크 및 상기 하트비트 애크 청크에 포함된 정보를 기초로 하여, SCTP 노드 테이블을 생성하는 테이블생성단계;
상기 생성된 SCTP 노드 테이블을 기초로 하여, 상기 발신 SCTP노드 및 상기 수신 SCTP노드의 대표 IP주소를 각각 결정하는 대표주소결정단계; 및
상기 결정된 대표 IP주소를 기초로 프로시져 키를 구성하여 상기 발신 SCTP노드 및 상기 수신 SCTP노드간에 송신된 패킷을 분석하는 패킷분석단계를 포함하고,
상기 하트비트애크청크수신단계는,
상기 하트비트 청크를 송신한 IP주소가 상기 하트비트 애크 청크를 상기 하트비트 청크를 수신하지 않은 IP주소로부터 수신하고,
상기 발신 SCTP노드의 대표IP주소는,
상기 발신 SCTP노드의 IP주소들 중에서, 상기 발신 SCTP노드에서 상기 하트비트 청크를 송신하는 데에 사용된 적어도 한 개 이상의 IP주소를 대표하는 IP주소이고,
상기 수신 SCTP노드의 대표IP주소는,
상기 수신 SCTP노드의 IP주소들 중에서, 상기 수신 SCTP노드에서 상기 하트비트 애크청크를 송신하는 데에 사용된 적어도 두 개 이상의 IP주소인, 멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 방법.
제1항에 있어서,
상기 발신 SCTP노드 및 상기 수신 SCTP노드는 같은 개수의 IP주소를 갖는 것을 특징으로 하는 멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 방법.
제1항에 있어서,
상기 발신 SCTP노드가 상기 하트비트 청크를 송신할 때의 발신 IP주소 및 수신 IP주소와 상기 수신 SCTP노드가 상기 하트비트 애크 청크를 송신할 때의 발신 IP주소 및 수신 IP주소가 각각 불일치한 것을 특징으로 하는 멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 방법.
제1항에 있어서,
상기 테이블생성단계는,
상기 하트비트 청크와 상기 하트비트 애크 청크를 분석하여, 상기 발신 SCTP 노드의 IP주소 1개 및 상기 수신 SCTP 노드의 IP주소 1개 내지 2개를 추출하는 IP주소추출단계; 및
상기 추출된 IP주소들을 상기 SCTP 노드 테이블에 포함시키는 테이블값기록단계;를 포함하는 멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 방법.
제1항에 있어서,
상기 하트비트 청크는,
하트비트 맵(heartbeat map)과 하트비트 타이머 큐(heartbeat time queue)로 구성된 것을 특징으로 하는 멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 방법.
제5항에 있어서,
상기 하트비트 맵은,
상기 하트비트 청크를 전송할 때에 사용된 수신 SCTP 노드의 IP주소를 포함하는 것을 특징으로 하는 멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 방법.
제1항에 있어서,
상기 하트비트청크송신단계는,
상기 발신 SCTP 노드의 제1발신IP주소에서 상기 수신 SCTP노드의 제1수신IP주소로 상기 하트비트 청크가 송신되고,
상기 하트비트애크청크수신단계는,
상기 수신 SCTP노드의 제2수신IP주소로부터 상기 제1발신IP주소로 상기 하트비트 애크청크가 수신되고,
상기 테이블생성단계는,
상기 수신 SCTP 노드의 엘리먼트를 총 네 가지의 경우의 수로 구분하여 병합하고,
상기 네 가지의 경우의 수는,
1) 상기 제1수신IP주소 및 제2수신IP주소에 노드값이 모두 존재하는 제1경우,
2) 상기 제1수신IP주소에만 노드값이 존재하는 제2경우,
3) 상기 제2수신IP주소에만 노드값이 존재하는 제3경우,
4) 상기 제1수신IP주소 및 제2수신IP주소에 노드값이 모두 존재하지 않는 제4경우를 포함하고,
상기 SCTP 노드 테이블에 상기 발신 SCTP 노드 및 상기 수신 SCTP 노드의 IP주소를 모두 포함시키는 것을 특징으로 하는 멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 방법.
제1항 내지 제7항 중 어느 한 항에 따른 방법을 실행시키기 위한 프로그램을 저장하고 있는 컴퓨터 판독가능한 기록매체.
멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 시스템으로서,
적어도 두 개 이상의 IP주소를 갖는 발신 SCTP노드에서 하트비트 청크(HEARTBEAT chunk)를 적어도 두 개 이상의 IP주소를 갖는 수신 SCTP노드에 송신하는 하트비트청크송신부;
상기 수신 SCTP노드로부터 상기 하트비트 청크에 대응되는 하트비트 애크 청크(HEARTBEAT ACK chunk)를 수신하는 하트비트애크청크수신부;
상기 하트비트청크 및 상기 하트비트 애크 청크에 포함된 정보를 기초로 하여, SCTP 노드 테이블을 생성하는 테이블생성부;
상기 생성된 SCTP 노드 테이블을 기초로 하여, 상기 발신 SCTP노드 및 상기 수신 SCTP노드의 대표 IP주소를 각각 결정하는 대표주소결정부; 및
상기 결정된 대표 IP주소를 기초로 프로시져 키를 구성하여 상기 발신 SCTP노드 및 상기 수신 SCTP노드간에 송신된 패킷을 분석하는 패킷분석부를 포함하고,
상기 하트비트 청크를 송신한 IP주소에 상기 하트비트 애크 청크가 상기 하트비트 청크를 수신하지 않은 IP주소로부터 수신되고,
상기 발신 SCTP노드의 대표IP주소는,
상기 발신 SCTP노드의 IP주소들 중에서, 상기 발신 SCTP노드에서 상기 하트비트 청크를 송신하는 데에 사용된 적어도 한 개 이상의 IP주소를 대표하는 IP주소이고,
상기 수신 SCTP노드의 대표IP주소는,
상기 수신 SCTP노드의 IP주소들 중에서, 상기 수신 SCTP노드에서 상기 하트비트 애크청크를 송신하는 데에 사용된 적어도 두 개 이상의 IP주소인, 멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 시스템.
제9항에 있어서,
상기 발신 SCTP노드 및 상기 수신 SCTP노드는 같은 개수의 IP주소를 갖는 것을 특징으로 하는 멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 시스템.
제9항에 있어서,
상기 발신 SCTP노드가 상기 하트비트 청크를 송신할 때의 발신 IP주소 및 수신 IP주소와 상기 수신 SCTP노드가 상기 하트비트 애크 청크를 송신할 때의 발신 IP주소 및 수신 IP주소가 각각 불일치한 것을 특징으로 하는 멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 시스템.
제9항에 있어서,
상기 테이블생성부는,
상기 하트비트 청크와 상기 하트비트 애크 청크를 분석하여, 상기 발신 SCTP 노드의 IP주소 1개 및 상기 수신 SCTP 노드의 IP주소 1개 내지 2개를 추출하는 IP주소추출부; 및
상기 추출된 IP주소들을 상기 SCTP 노드 테이블에 포함시키는 테이블값기록부;를 포함하는 멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 시스템.
제9항에 있어서,
상기 하트비트 청크는,
하트비트 맵(heartbeat map)과 하트비트 타이머 큐(heartbeat time queue)로 구성된 것을 특징으로 하는 멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 시스템.
제13항에 있어서,
상기 하트비트 맵은,
상기 하트비트 청크를 전송할 때에 사용된 수신 SCTP 노드의 IP주소를 포함하는 것을 특징으로 하는 멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 시스템.
제9항에 있어서,
상기 하트비트청크송신부는,
상기 발신 SCTP 노드의 제1발신IP주소에서 상기 수신 SCTP노드의 제1수신IP주소로 상기 하트비트 청크를 송신하고,
상기 하트비트애크청크수신부는,
상기 수신 SCTP노드의 제2수신IP주소로부터 상기 제1발신IP주소로 상기 하트비트 애크청크를 수신하고,
상기 테이블생성부는,
상기 수신 SCTP 노드의 엘리먼트를 총 네 가지의 경우의 수로 구분하여 병합하고,
상기 네 가지의 경우의 수는,
1) 상기 제1수신IP주소 및 제2수신IP주소에 노드값이 모두 존재하는 제1경우,
2) 상기 제1수신IP주소에만 노드값이 존재하는 제2경우,
3) 상기 제2수신IP주소에만 노드값이 존재하는 제3경우,
4) 상기 제1수신IP주소 및 제2수신IP주소에 노드값이 모두 존재하지 않는 제4경우를 포함하고,
상기 SCTP 노드 테이블에 상기 발신 SCTP 노드 및 상기 수신 SCTP 노드의 IP주소를 모두 포함시키는 것을 특징으로 하는 멀티호밍 SCTP노드 상에서 동작하는 SCTP 유저 어플리케이션의 패킷 분석 시스템.