KR20200062948A - 인-네트워크 프로세싱 수행이 가능한 네트워크 노드의 네트워크 서비스 방법 - Google Patents

인-네트워크 프로세싱 수행이 가능한 네트워크 노드의 네트워크 서비스 방법 Download PDF

Info

Publication number
KR20200062948A
KR20200062948A KR1020180148971A KR20180148971A KR20200062948A KR 20200062948 A KR20200062948 A KR 20200062948A KR 1020180148971 A KR1020180148971 A KR 1020180148971A KR 20180148971 A KR20180148971 A KR 20180148971A KR 20200062948 A KR20200062948 A KR 20200062948A
Authority
KR
South Korea
Prior art keywords
inp
network
packet
node
nodes
Prior art date
Application number
KR1020180148971A
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 KR1020180148971A priority Critical patent/KR20200062948A/ko
Publication of KR20200062948A publication Critical patent/KR20200062948A/ko

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/22Alternate routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2212/00Encapsulation of packets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/59Providing operational support to end devices by off-loading in the network or by emulation, e.g. when they are unavailable

Landscapes

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

Abstract

본 발명은 본 발명은 인-네트워크 프로세싱 수행이 가능한 네트워크 노드(node)의 네트워크 서비스 방법에 관한 것이다. 특히, 본 발명은 이름 기반 네트워크 환경에서 인-네트워크 프로세싱 (INP, In-Network Processing) 서비스 제공을 위해, 우회 경로를 통해 서비스 실행이 가능하도록 유도하는 네트워크 서비스 방법 및 이를 구현하는 네트워크 노드에 관한 것이다. 본 발명에 따른 네트워크 노드의 네트워크 서비스 방법은, 설정된 최적 경로를 벗어난 INP 인터리스트 패킷(interest packet)을 수신하는 단계, 및 상기 수신된 인터리스트 패킷을 최적 경로가 아닌 인접 INP 노드로 전달하기 위해, 상기 인터리스트 패킷에 상기 인접 INP 노드 이름과 우회 속성 정보를 추가하여 인캡슐화(encapsulation)하여 전달하는 단계를 포함한다.

Description

인-네트워크 프로세싱 수행이 가능한 네트워크 노드의 네트워크 서비스 방법 {Service Guarantee Method for Name based In-Network Processing}
본 발명은 인-네트워크 프로세싱 수행이 가능한 네트워크 노드(node)의 네트워크 서비스 방법에 관한 것이다. 특히, 본 발명은 이름 기반 네트워크 환경에서 인-네트워크 프로세싱 (INP, In-Network Processing) 서비스 제공을 위해, 우회 경로를 통해 서비스 실행이 가능하도록 유도하는 네트워크 서비스 방법 및 이를 구현하는 네트워크 노드에 관한 것이다.
본 발명과 관련된 네트워크 배경 기술을 설명하면 다음과 같다. 이름 기반 네트워크는, 원하는 콘텐츠가 어디에 있는지를 나타내는 위치 보다 어떤 콘텐츠 인지가 중요하다는 개념에서 시작한다. 이름 기반 네트워크는 유럽에서는 ICN (Information Centric Networking)으로, 미국에서는 NDN과 CCN (Content Centric Networking) 이라는 명칭으로 연구가 진행되고 있다. 이들은 end-to-end로 통신을 수행하는 기존 인터넷 통신 패러다임을 정보 중심의 통신으로 전환하려는 것이다. 즉, 종래 인터넷 망에서 데이터 전달은 콘텐츠의 정보와 무관하게 송수신지의 주소 정보를 통해 이루어지는 반면, 이름 기반 네트워크는 콘텐츠의 이름을 기반으로 라우팅(routing)이 이루어진다.
관련하여, 전술한 바와 같이, 이름 기반 네트워크 중, 널리 알려진 NDN 연구가 있다. NDN은 이름 기반 네트워크의 대표적인 연구로써, 급증하는 데이터와 함께 더 효율적이고 안전한 아키텍처를 지향한다. 구체적으로, NDN은 두 개의 패킷 타입으로서, 인터리스트 패킷(Interest packet)과 데이터 패킷(Data packet)을 사용한다. 사용자는 필요한 데이터 요청시, 해당 데이터 이름을 포함하는 인터리스트 패킷으로 요청하고, 해당 데이터는 데이터 패킷의 형태로 사용자에게 전달된다. 또한, NDN 라우터에서는 PIT (Pending Interest Table) 및 FIB (Forwarding Information Base) 테이블을 이용하여 라우팅을 수행하며, 전달된 데이터는 CS (Contents Store)에 일정 시간 동안 캐쉬 되어 다음 동일한 요청에 신속하게 응답하는 것이 가능하다.
또한, 최근 클라우드 서비스는, IaaS (Infrastructure-as-a-Service), SaaS (Software-as-a-Service), PaaS (Platform-as-a-Service), FaaS (Function-as-a-Service), 서버리스(Serverless)의 개념을 통합하여 다양한 서비스를 제공하고 있다. 특히 서버리스(Serverless)는 사용자들이 어플리케이션(application) 개발에 필요한 인프라의 구성 및 유지에 대한 복잡하고 한 노력 없이, 단지 어플리케이션 개별 기능 개발에 집중할 수 있는 플랫폼을 제공하는 클라우드 서비스의 한 분류이다. 또한, 상기 FaaS는 사용자들이 코드를 실행할 수 있는 환경을 동적으로 제공하는 개념이다.
상기 NFN (Named Function Networking)과 NFaaS (Named Function-as-a-Service)는 네트워크에서 함수나 서비스가 실행 가능하도록 NDN을 확장하는 대표적인 기술들이며, 이들은 사용자 장비를 포함하여 네트워크 노드에서 연산과 서비스가 실행될 수 있도록 개념과 방법, 절차를 정의하고 있다
인-네트워크 프로세싱(INP)으로 명명되는 INP 기술은 컴퓨팅 연산을 서버에서 네트워크 장비로 이전시키는 개념으로써, 네트워크에서 연산이 수행되기 때문에 빠른 서비스가 가능하고, 네트워크의 트래픽(traffic)을 줄일 수 있는 장점이 있다. 또한 서버의 부하가 감소되기 때문에 데이터 센터에서는 유지보수 비용을 크게 줄일 수 있는 장점이 있다. 상기 인-네트워크 프로세싱(INP)은, 인-네트워크 컴퓨팅(INC, In-Network Computing) 으로 명명되기도 한다.
관련하여, 종래 INP 기술은 일반적인 NDN 라우터 (이하, 'NDN 라우터' 또는 'NDN 노드')와 INP를 지원하는 NDN 라우터 (이하, 'INP 라우터' 또는 'INP 노드')가 공존하는 환경에서 라우팅을 수행하는 중간 노드 (예를 들어, INP 라우터)에서 자원 할당과 함수의 실행이 이루어게 된다. 단, 상기 경로 상에 INP 라우터가 존재하지 않거나 경로 상의 모든 INP 라우터의 자원이 부족할 경우 INP 요청을 처리할 수 없게 된다. 즉, 상기 경우에 있어서, INP 실행이 가능한 INP 노드로 INP 인터리스트 패킷을 전송해야 하지만, 종래 기존 라우팅 방법으로는 상기 인터리스트 패킷을 INP 노드로 전달할 수 있는 방법이 없게 되는 문제점이 있다.
따라서, 본 발명의 목적은, 전술한 종래 기술의 문제점을 해결하기 위해, 기반의 INP 서비스 제공시, 정해진 네트워크 경로 상에서 서비스 실행이 불가능할 경우라도, 우회 경로를 통해 서비스 실행이 가능하도록 유도함으로써, INP 서비스 제공을 최대한 보장하는 네트워크 노드 및 네트워크 서비스 방법을 제공하는 데 있다.
또한, 본 발명은 전술한 종래 기술의 문제점을 해결하기 위해, 기반의 INP 서비스 제공시, 정해진 네트워크 경로 상에서 서비스 실행이 불가능할 경우라도, 이름 기반 통신에 위치 기반 통신의 특성을 확장 적용하여 우회 경로를 통해 서비스 실행이 가능하도록 유도함으로써, INP 서비스 제공을 최대한 보장하는 네트워크 노드 및 네트워크 서비스 방법을 제공하는 데 있다.
본 발명의 다른 목적 및 장점들은 하기의 설명에 의해서 이해될 수 있으며, 본 발명의 실시예에 의해 보다 분명하게 알게 될 것이다. 또한, 본 발명의 목적 및 장점들은 특허청구범위에 나타낸 수단 및 그 조합에 의해 실현될 수 있음을 쉽게 알 수 있을 것이다.
상기 목적을 달성하기 위한, 본 발명의 인-네트워크 프로세싱 (INP, In-Network Processing) 수행이 가능한 네트워크 노드의 네트워크 서비스 방법은, 설정된 최적 경로를 벗어난 INP 인터리스트 패킷(interest packet)을 수신하는 단계, 및 상기 수신된 인터리스트 패킷을 최적 경로가 아닌 인접 INP 노드로 전달하기 위해, 상기 인터리스트 패킷에 상기 인접 INP 노드 이름과 우회 속성 정보를 추가하여 인캡슐화(encapsulation)하여 전달하는 단계를 포함한다.
본 발명의 실시예에 따르면, 중앙 집중 형태의 포워딩, 라우팅 제어를 수행하지 않는 분산 환경에서 네트워크 노드 간 자원 정보를 공유하기 위한 오버헤드 없이 네트워크 내에서 최대한 서비스를 제공할 수 있다. 또한, 기존 NDN, NFD 방식과의 호환으로 INP 서비스 실행을 보장할 수 있게 된다.
도 1 및 도 2는 본 발명의 이름 기반 네트워크에서, 인-네트워크 프로세싱(INP)을 수행하는 개념을 설명하기 위해 도시한 것이다.
도 3 및 도 4는 본 발명의 이름 기반 네트워크에서 사용되는 데이터 패킷 및 인터리스트 패킷의 속성 정보를 도시한 것이다.
도 5는 본 발명 실시예에 따른, 네트워크 INP 노드에서의, INP 인터리스트 패킷 수신시 동작을 도시한 것이다.
도 6은 본 발명 실시예에 따른, 네트워크 호스트 INP 노드에서의, INP 데이터 패킷 수신시 동작을 도시한 것이다.
도 7은 본 발명 실시예에 따른, 네트워크 일반 INP 노드에서의, INP 데이터 패킷 수신시 동작을 도시한 것이다.
도 8은 본 발명 실시예에 따른, 네트워크 동작을 설명하기 위해 예시적으로 도시한 것이다.
이하에서는 첨부한 도면을 참고로 하여 본 발명의 실시 예에 대하여 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나, 본 발명은 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시 예에 한정되지 않는다.
본 발명의 실시 예를 설명함에 있어서 공지 구성 또는 기능에 대한 구체적인 설명이 본 발명의 요지를 흐릴 수 있다고 판단되는 경우에는 그에 대한 상세한 설명은 생략한다. 그리고, 도면에서 본 발명에 대한 설명과 관계없는 부분은 생략하였으며, 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.
본 발명에 있어서, 서로 구별되는 구성요소들은 각각의 특징을 명확하게 설명하기 위함이며, 구성요소들이 반드시 분리되는 것을 의미하지는 않는다. 즉, 복수의 구성요소가 통합되어 하나의 하드웨어 또는 소프트웨어 단위로 이루어질 수도 있고, 하나의 구성요소가 분산되어 복수의 하드웨어 또는 소프트웨어 단위로 이루어질 수도 있다. 따라서, 별도로 언급하지 않더라도 이와 같이 통합된 또는 분산된 실시 예도 본 발명의 범위에 포함된다.
본 발명에 있어서, 다양한 실시 예에서 설명하는 구성요소들이 반드시 필수적인 구성요소들은 의미하는 것은 아니며, 일부는 선택적인 구성요소일 수 있다. 따라서, 일 실시 예에서 설명하는 구성요소들의 부분집합으로 구성되는 실시 예도 본 발명의 범위에 포함된다. 또한, 다양한 실시 예에서 설명하는 구성요소들에 추가적으로 다른 구성요소를 포함하는 실시 예도 본 발명의 범위에 포함된다.
이하, 첨부한 도면을 참조하여 본 발명의 실시 예들에 대해서 설명한다.
도 1 및 도 2는 본 발명의 이름 기반 네트워크에서, 인-네트워크 프로세싱(INP)을 수행하는 개념을 설명하기 위해 도시한 것이다.
도 1을 참조하면, 인-네트워크 프로세싱(INP)을 지원하는 이름 기반 네트워크 또는 NDN 네트워크(100)는, 네트워크내 다수의 데이터 저장소(102) 및/또는 함수 저장소(102), 일반 NDN 라우터들 (NDN 노드, 121, 122)과 INP 지원 NDN 라우터들 (INP 노드, 111, 112, 113)를 포함하여 구성된다. 단, 도 1은 INP 노드 (111)가 사용자 노드(101)와 데이터 노드(102)에 직접 연결된 경우를 도시하였으나, 이는 단지 설명의 편의를 위해 도시한 것으로, 본 발명 네트워크(100) 내의 각 노드들은 분산되어 서로 네트워킹으로 연결되어 있음은 자명하다.
본 발명의 NDN 네트워크(100)는 중앙 집중 형태의 포워딩, 라우팅 제어를 수행하지 않고, NDN 노드 및 INP 노드들 간에 자원 정보를 공유하지 않는 분산 환경으로 이루어 진다. 사용자 또는 요청자 (101)는 네트워크(100)로 데이터의 이름, 이를 가공할 함수의 이름, 정책 등의 정보를 패킷으로 전달하고, 네트워크(100)에서 라우팅이 수행되는 중간에 최적의 위치라 판단되는 노드에 실행을 위한 자원이 할당된다. 또한, 본 발명의 네트워크(100)는 On-demand 형태로 생성된 실행 환경에서 데이터와 함수가 수집되고 연산된 결과를 사용자에게 반환할 수 있게 된다. 관련하여, 본 발명 NDN 네트워크(100)는 다음과 같은 특징을 가진다,
첫째, 본 발명이 적용된 NDN 네트워크(100)에 접속하는 모든 호스트 노드들은 home_INP_router 가 어디 인지를 인식하고 있다. home_INP_router는 호스트를 책임지는 INP 라우터를 의미한다. 따라서, 예를 들어, home_INP_router는 호스트에서 가장 가까운 INP 라우터 (111)일 수도 있고, 관리적인 정책에 의해 다른 INP 라우터가 될 수도 있다. 관련하여, home_INP_router를 지정하는 방법과 절차는 본 발명의 기본 내용을 벗어나므로 별도로 정의하지 않을 것이다. 참고로 표준 NDN에 접속하는 모든 호스트들은 일반적으로 'NDN hub discovery procedure' 를 통해 가장 가까운 NDN 라우터를 찾게 되고, 이 절차는 호스트 노드로부터 멀티캐스트 전송, DNS 질의 등 다양한 방법으로 이루어질 수 있다.
둘째, INP 라우터 또는 INP 노드(111, 112, 113)는 INP를 제어하기 위한 모듈(111a, 112a, 113a)을 포함하고, INP 모듈은 각각 유일한 이름을 가진다. 상기 INP 모듈(111a, 112a, 113a)은 INP 수행을 위한 전체적인 절차를 제어한다. 즉, INP 패킷의 수신과 해석, 생성과 송신뿐만 아니라 기능의 실행을 위한 가상화 자원의 할당과 해제 등 INP 라우터 또는 INP 노드내에서의 전반적인 INP 관련 절차를 수행하게 된다.
셋째, INP 라우터 또는 INP 노드(111, 112, 113)는 NACK 메시지를 전송할 때 실패의 이유와 failed_nodes 리스트에 자신의 이름을 추가하여 전달한다. 상기 failed_nodes 리스트는 해당 요청을 수행하지 못한 라우터들의 이름을 순차적으로 포함한다. 따라서 INP 라우터 (111, 112, 113)는 NACK를 전달할 때 failed_nodes 리스트가 없으면 자신의 이름을 넣어 failed_nodes를 생성한 후 전달한다. 반면, 이미 failed_nodes 리스트가 있으면 자신의 이름을 마지막에 추가하여 전달한다. 상기 정보는 추후 본 발명에서 우회 경로를 결정할 때 참고할 중요한 정보가 되며, 이에 대해서는 상세히 후술할 것이다.
도 2를 참조하면, 사용자(101)가 전송하는 인터리스트 패킷은 NDN 절차에 따라 데이터 또는 함수의 저장소(102) 방향으로 최적의 경로(예를 들어, path 3)로 라우팅되어 전달된다. 여기서, 최적의 경로는 NDN 표준 방식 및 시스템 설계에 따라 다양한 방식으로 결정할 수 있다. 예를 들어, 시간이나 거리적으로 가장 최단 경로를 최적 경로로 설정할 수 있다. 단, 상기 최적 결정 방법은 본 발명의 기본 내용을 벗어나므로 자세한 설명은 생략한다.
관련하여, 최적 경로 3 상의 모든 INP 라우터가 자원 부족 등의 이유로 실행이 불가능하거나, 경로 3에 INP 노드가 하나도 없는 경우라면, 종래 NDN 네트워크는 사용자의 요청을 실행할 수 없게 되고, 사용자에게 실행 실패(fail) 통보하는 것으로 종료하게 될 것이다.
반면, 본 발명은 상기 최적 경로가 아니더라도 최적 경로 주위의 다른 INP 노드들로 우회하여 INP 서비스를 제공하는 방법을 제공하고자 한다. 즉, 최적 경로가 아니어도, 경로 2 (path 2)에서 경로 1 (path 1)의 방향 또는 경로 4 (path 2)에서 경로 5 (path 1)의 방향으로 비용이 증가하더라도 최적 경로를 우회하는 방향으로 사용자의 요청을 실행하고자 한다. 즉, 중앙 집중 제어 형태가 아닌 분산 환경에서 어떻게 인터리스트 패킷을 우회할 것인지가 본 발명의 해결 과제이다. 관련하여, 본 발명은 상기 인터리스트 패킷을 우회시키기 위해 다음과 같은 특징적 기법을 사용한다.
우선, 이름 기반 통신 상에서 위치 기반 통신의 특성을 활용한다. 즉, 본 발명에서는 인터리스트 패킷을 최적 경로 상에서 벗어난 인접 노드들로 전달하기 위해 인접 INP 모듈의 이름을 명시하여 인터리스트 패킷을 인접 INP 모듈로 전달하는 것을 특징으로 한다. 예를 들어, 우회 경로에 대한 시도는 인터리스트 패킷을 멀티캐스트(multicast)하는 방법도 가능하지만, 기존 NDN 포워딩 모듈의 수정 없이 멀티캐스트하려면 필요한 인접 INP 모듈이 별도로 관리되어야 하며, 멀티캐스트가 가능하다 하더라도 멀티캐스팅에 의한 오버헤드와 사용자의 요청이 네트워크 내의 여러 곳에서 실행되는 자원 낭비가 발생할 수도 있다. 따라서, 본 발명의 실시예는 멀티캐스트 방식이 아닌, 인접 INP 노드(또는 INP 모듈)의 이름을 직접 인터리스트 패킷에 포함하는 것을 바람직한 실시예로 제시하고자 한다. 단, 멀티캐스트 방식을 본 발명의 변형적 실시예로 적용할 수 있음은 자명하다.
또한, 사용자가 최초 전송한 인터리스트 패킷을 인접 INP 모듈로 전달하기 위해 인캡슐화(encapsulation)와 디캡슐화(decapsulation)를 적용한다. 즉, 우회해야 할 인터리스트 패킷을 수신한 INP 모듈은 이를 전달할 인접 INP 모듈을 결정하고, 인터리스트 패킷을 해당 모듈의 이름으로 인캡슐화(encapsulation)하여 전송한다. 인접 INP 모듈까지의 전달은 표준 NDN 라우팅에 이루어지며, 이를 수신한 INP 모듈은 자신의 이름을 제거하여 디캡슐화(decapsulation)를 수행하여, 최초 전달된 사용자의 인터리스트 패킷을 확인한다. 관련하여, 인접 INP 모듈에 대한 정보를 노드 간 공유하는 방법은 예를 들어, 대표적으로는 NLSR이 있으나, 이들 중 하나를 선택하는 방법은 기본적으로 인터리스트 패킷에 명시된 정책을 따르지만 해당 값을 포함하지 않을 경우 라우터 관리 정책에 따라 다양해질 수 있다. 또한, 현재 NDN 표준에 의하면 NDN 라우터가 패킷을 다음 노드로 전달할 때 다양한 포워딩 전략(forwarding strategy)를 정의하고 있으며, 기본적으로 'best route strategy'로 동작하지만 'client control strategy'를 활용하면 원하는 페이스(face)로 전달이 가능하다.
또한, INP 모듈이 본 발명의 동작을 수행할 수 있도록 인터리스트 패킷 및 데이터 패킷에 다음과 같은 속성 정보들을 추가 정의하는 것을 특징으로 한다. 단, 속성 정보 값은 선택적 옵션이며, INP 노드는 필요한 속성만을 선택적으로 포함할 수 있다.
도 3 및 도 4는 본 발명의 이름 기반 네트워크에서 사용되는 데이터 패킷 및 인터리스트 패킷의 속성 정보를 각각 예를 들어 도시한 것이다.
도 3을 참조하면, 본 발명의 데이터 패킷은, 'failed_nodes' 속성 정보를 포함할 수 있다. 'failed_nodes' 속성 정보는 최초 인터리스트 패킷이 전달된 경로 상에서 INP 실행이 불가능한 노드 리스트이며, INP 요청에 대한 NACK 패킷을 회신할 때 실행이 불가능한 경우 자신의 노드 이름을 추가할 수 있도록 한 것이다. 관련하여, 상기 'failed_nodes' 속성 정보의 추가는 INP 노드의 경우에만 해당된다.
도 4를 참조하면, 본 발명의 인터리스트 패킷은, 속성 정보로서 'exclude_nodes', 'detour_route', 'detour_hop_limit', 'max_detour_face', 'detour_policy', 'detour_retry_limit'을 포함할 수 있다.
구체적으로, 상기 'exclude_nodes' 속성 정보는, 사용자가 우회 경로를 통해 INP 요청을 할 때 중복된 실패를 방지하기 위해 우회하는 인터리스트 패킷을 전달하지 않기 위한 노드 리스트이며, INP 모듈은 NACK 데이터 패킷의 'failed_nodes' 리스트의 노드들을 전체 복사하거나 선택 복사하여 적용할 수 있다.
상기 'detour_route' 속성 정보는, 해당 인터리스트 패킷이 우회 경로를 사용하는 요청인지 명시한다. 예를 들어, 참(True) 값을 가질 경우 인터리스트 패킷을 포워딩할 때 exclude_nodes 리스트에 포함되는 노드로는 전달하지 않는다.
상기 'detour_hop_limit' 속성 정보는, 사용자가 몇 번째 홉(hop)까지 인터리스트 패킷을 우회시킬 것인지를 명시한다. 상기 'detour_hop_limit' 속성 정보 값은 INP 모듈을 거칠 때마다 1씩 감소시키며, 0을 수신한 INP 모듈은 해당 인터리스트 패킷을 더 이상 우회시키지 않고 패킷을 디캡슐화(decapsulation)하여 마치 자신이 최초 요청자(requester)인 것처럼 일반 INP 인터리스트 패킷을 전송한다.
상기 'max_detour_face' 속성 정보는 INP 모듈에서 인터리스트 패킷을 몇 개의 페이스(face)로 멀티캐스트 할지를 명시한다. 상기 'max_detour_face' 속성 정보가 1의 값을 가질 경우 하나의 페이스(face)로 전달되며, 1 이상의 값을 가질 경우에는, 네트워크 내에서 중복 실행을 감수할 경우 사용한다. 예를 들어, 경로 상에서 INP 실행이 안되는 긴급한 경우에도 활용할 수 있다.
상기 'detour_policy' 속성 정보는, 여러 개의 인접 INP 노드가 존재할 때 우회 INP 노드를 선택할 때 사용하는 정책을 명시한다. 예를 들어, 'any', 'near_data', near_client' 등 다양한 정책을 반영할 수 있으나 본 발명은 상기 예에 한정되지 않는다.
상기 'detour_retry_limit' 속성 정보는 우회 INP 요청도 실패할 경우 home_INP_router가 최대한 우회 INP 요청을 재시도하는 횟수를 명시한다.
따라서, 상기 패킷 속성 정보들을 활용하여, 사용자 또는 home_INP_router는 최초 INP 인터리스트 패킷에 대해 NACK를 수신하고 더 넓은 지역으로 우회 INP 인터리스트 패킷을 전송할 때 정책적으로 다양한 속성 조합을 생성할 수 있다. 또한, 사용자에 의해 각 속성을 명시하지 않을 경우 home_INP_router에 의해 속성 조합이 생성되거나, 명시하지 않은 속성이라도 각 INP 라우터의 정책이나 INP 모듈의 판단에 의해 동작이 결정될 수도 있다.
예를 들어, home_INP_router는 상기 'detour_retry_limit' 횟수 내에서 우회 INP 인터리스트 패킷을 여러 번 재시도할 수 있다. 이 때 그대로 또는 하나 이상의 속성을 변경할 수 있으나 복수의 속성값들을 동시에 무리하게 증가시킬 경우 네트워크 내에서 동일한 실행이 중복될 수 있을 뿐만 아니라 오버헤드가 커질 수 있으므로 신중할 필요가 있으며, 악의적인 이용을 막기 위해 정책적으로 각 INP 노드에서 해당 인터리스트 패킷을 거부하거나 일부 속성에 대한 적용을 무시할 수도 있다.
구체적으로, 예를 들어, 최초 전송 때보다 'failed_nodes' 리스트가 변경되었다면 그대로 재전송해도 무방하다. 단, 'failed_nodes' 리스트가 처음 전송 때와 동일하다면 다른 속성을 변경하는 것이 바람직하다. 예를 들어, 속성 정보를 변경 시에는, 'detour_policy' 변경, 'detour_hop_limit' 증가, 'max_detour_face' 증가, 'detour_hop_limit' 증가, 'max_detour_face' 증가와 같이 변경하는 것이 가능하다.
도 5 내지 도 7은 본 발명 실시예에 따른, 네트워크 INP 노드에서의 동작을 도시한 것이다, 구체적으로, 도 5는 네트워크 INP 노드에서의 INP 인터리스트 패킷 수신시 동작을 도시한 것이고, 도 6은 네트워크 호스트 INP 노드에서의 INP 데이터 패킷 수신시 동작을 도시한 것이고, 도 7은 네트워크 일반 INP 노드에서의 INP 데이터 패킷 수신시 동작을 도시한 것이다.
도 5는 INP 노드의 INP 모듈이 인터리스트 패킷을 수신했을 때의 절차를 나타낸다. 도 5를 참조하면, INP 모듈이 INP 타입의 인터리스트 패킷을 수신하면(501) 이를 디캡슐화(decapsulation) 한다(502). 이후, 인터리스트 패킷내의 'detour_route' 값이 참(true)인지 확인한다(503). 즉, 널(NULL)이나 거짓(false)의 경우 본 발명의 동작과 무관하므로 기존 INP 모듈의 동작을 수행한다(507).
반면, 'detour_route' 값이 참(true)인 경우 'detour_hop_limit' 값이 0인지를 확인한다(504). 만약 'detour_hop_limit' 값이 0일 경우 우회 전달이 종료되었으므로 자신 스스로 실행 가능한 지 확인한다(505). 만약 실행이 가능하면 실행 후 결과를 인캡슐화(encapsulation) 하여 전달한다(506). 반면, 505 단계 확인 결과, 스스로 실행이 불가능하면 더 이상 인터리스트 패킷을 우회시키지 않고 일반 INP 인터리스트 패킷을 전송한다(509). 추후 해당 인터리스트 패킷에 대한 실행 결과를 포함하는 데이터 패킷을 수신하면 이를 다시 인캡술화(encapsulation)하여 전달한다.
반면, 상기 504 단계에서, 'detour_hop_limit' 값이 0이 아닐 경우 'detour_hop_limit' 를 1 감소시키고 'detour_policy'와 'max_detour_face'를 고려하여 새로운 우회 INP 인터리스트 패킷을 전송한다(508). 이 때 해당 결과를 전달하기 위해 수신한 INP 인터리스트와 우회 INP 인터리스트 정보를 별도로 관리하는 것이 바람직하다.
도 6은 home_INP_router의 INP 모듈이 데이터 패킷을 수신했을 때의 절차를 나타낸다. 도 6을 참조하면, INP 모듈이 INP 타입의 데이터 패킷을 수신하면(601) 이를 디캡슐화(decapsulation) 한다(602). 이후 디캡슐화된 데이터 패킷이 NACK 이거나 'failed_nodes' 리스트를 포함하는 지를 확인한다(603). 상기 603 단계 판단결과, NACK 이거나 'failed_nodes' 리스트를 포함하는 경우가 아니라면 본 발명의 동작과 무관하므로 기존 INP 모듈의 동작을 수행한다(609). 반면, 상기 603 단계 판단 결과, NACK 이거나 'failed_nodes' 리스트를 포함하면 자신부터 데이터 및/또는 함수 저장소(repository)까지의 모든 INP 라우터가 실행이 불가능한 상태이므로 자신이 실행이 가능한 지 확인한다(604). 만약 상기 604 단계 확인 결과, 실행이 가능하면 실행 후 결과를 인캡슐화(encapsulation) 하여 전달한다(605). 반면, 상기 604 단계 확인 결과, 실행이 불가능하면, 우회 INP 요청에 대한 실패인지 확인한다 (606).
상기 606 단계 확인 결과, 우회 INP 요청에 대한 실패로 확인되면 'detour_retry_limit'만큼 재시도 되었는지 확인한다(607). 만약 'detour_retry_limit' 만큼 재시도했음에도 불구하고 실패한 경우라면, 사용자에게 실패를 보고한다(608). 또한, 'detour_retry_limit' 만큼 재시도하지 않은 경우라면, 필요에 따라 우회 INP 속성을 변경하고 우회 INP 요청을 재시도한다(611).
반면, 상기 606 단계 확인 결과, 우회 INP 요청에 대한 실패가 아니라고 확인되면, INP 모듈의 판단에 따라 사용자에게 실패를 보고하거나 또는 우회 INP 속성을 결정하여 우회 INP 요청을 시작한다(610).
도 7은 home_INP_router가 아닌 일반 INP 라우터의 INP 모듈이 데이터 패킷을 수신했을 때의 절차를 나타낸다. 도 7을 참조하면, INP 모듈이 INP 타입의 데이터 패킷을 수신하면(701) 이를 디캡슐화(decapsulation) 한다(702). 이후, 디캡슐화된 데이터 패킷이 NACK 이거나 'failed_nodes' 리스트를 포함하는 지를 확인한다(703). 상기 703 단계 판단결과, NACK 이거나 'failed_nodes' 리스트를 포함하는 경우가 아니라면 본 발명의 동작과 무관하므로 기존 INP 모듈의 동작을 수행한다(709). 반면, 상기 703 단계 판단 결과, NACK 이거나 'failed_nodes' 리스트를 포함하면 자신부터 데이터 및/또는 함수 저장소(repository)까지의 모든 INP 라우터가 실행이 불가능한 상태이므로 자신이 실행이 가능한 지 확인한다(704). 만약 상기 704 단계 확인 결과, 실행이 가능하면 실행 후 결과를 인캡슐화(encapsulation) 하여 전달한다(705). 반면, 상기 604 단계 확인 결과, 실행이 불가능하면, home_INP_router가 아닌 일반 INP 노드의 경우, 'failed_nodes' 리스트에 라우터 이름을 마지막에 추가한 NACK 데이터 패킷을 전송한다(707). 이 때 해당 INP 데이터에 대한 INP 인터리스트 정보가 별도 보관된 상태라면 인캡슐화(encapsulation) 하여 전송한다.
도 8은 본 발명 실시예를 구체적으로 설명하기 위해, 본 발명 네트워크 구조 및 동작을 예시적으로 도시한 것이다. 우선, 상세 동작 설명을 위해 패킷의 형태를 설명하면 다음과 같다.
I_INP(d+f)는, 데이터 d를 함수 f에 적용한 결과를 요청하는 INP 타입의 인터리스트 패킷을 의미한다. D_INP (d+f, NACK, failed_nodes=[x,y,z], reason="…” )는 d+f 요청에 대한 NACK 패킷으로 d+f를 실행하지 못한 INP 라우터 x, y, z 리스트와 실패의 이유를 포함하는 INP 타입의 데이터 패킷을 의미한다. Rx_INP 는, Rx 라우터의 INP 모듈의 이름을 의미한다. I_INP (Rx_INP / d+f, exclude_nodes=[y], detour_route=true …)는, d+f를 Rx_INP로 인캡슐화(encapsulation)한 INP 타입의 인터리스트 패킷이며, y를 포함하는 'exclude_nodes' 리스트 외에 여러 가지 우회 속성을 포함한다.
또한, 도 8의 네트워크는 다음과 같은 속성을 가짐을 가정한다. 예를 들어, 도 8의 네트워크에서 원형 노드(R5, R7, R10, R13, R14, R16, R17, R19)는 INP를 지원하지 않는 NDN 라우터이고, 사각 노드(R1, R2, R3, R4, R6, R8, R9, R11, R12, R15, R18, R20, R21)는 INP 라우터를 의미한다. 여기서 모든 링크의 비용을 1로 가정한다. 또한, 요청자(requester A)의 home_INP_router는 R9 노드이다. 또한, 요청자(requester A)에서 데이터까지의 최적 경로는 R9 - R10 - R11 - R12 - R13 로 가정한다. 또한, 현재 [R4, R9, R11, R12] 노드는 먼저 요청된 INP 인터리스트 패킷에 의해 할당 가능한 자원이 없는 경우이다. 또한, 사용자의 명시적인 요청이 없을 경우 R9_INP의 INP 관련 정책은, 예를 들어, 최대 우회 횟수=1, 전송할 인터리스트의 detour_hop_limit=0, max_detour_face=1, detour_policy='any', detour_retry_limit=3 으로 설정되어 있음을 가정한다.
상기 언급된 가정 하에서 전체 INP 수행 절차를 설명하면 다음과 같다. 우선, 요청자(requester A)는 I_INP (d+f), 즉 d+f에 대한 결과를 네트워크에 요청한다. 최적 경로로 라우팅 후 [R12, R11] 노드에서 실패했으므로 R9는 NACK INP 데이터 패킷을 수신한다. 즉, D_INP (d+f, NACK, failed_nodes=[R12, R11], reason=”no available resource” ).
이후, R9_INP는 자신이 실행 가능한 지 확인 후 가용 자원이 없음을 판단한다. 지금까지 우회 INP 요청이 시도되지 않았으므로 R9_INP는 정책에 따라 해당 요청에 대한 detour_retry_limit를 3으로 설정하고 우회 INP 인터리스트 패킷을 생성한다. 이 때 detour_policy가 'any'이므로 failed_nodes 리스트에 포함되지 않으면서 가장 가까운 R4 노드를 우회할 INP 노드로 선택한다. 만약 R9 - R10 - R11 - R12 - R13의 모든 노드가 INP를 지원하지 않는다면 'failed_nodes' 리스트가 NULL일 수 있으므로 R9_INP가 NACK에 대한 이유를 파악하여 우회 경로로 INP를 재요청할 지 판단해야 한다.
R9_INP는 수신한 failed_nodes 리스트와 자신의 이름을 합하여 다음과 같은 exclude_nodes를 포함하는 우회 INP 인터리스트 패킷을 R4로 전송한다. I_INP (R4_INP / d+f, exclude_nodes=[R12, R11, R9], detour_route=true, detour_hop_limit=0, max_detour_face=1, detour_policy='any' ).
R4_INP는 디캡슐화(decapsulation) 후, 이 요청이 우회 경로에 대한 INP 요청임을 인지하지만 detour_hop_limit 값이 0 이므로 더 이상 우회시키지 않고 일반 INP 인터리스트 패킷을 전송한다. 이 때 exclude_nodes 리스트에 포함된 노드로 향하는 페이스(face)로는 전송하지 않는다. 즉, I_INP (d+f )를 전송한다. 만약 상기 INP 인터리스트가 R4 - R5 - R10 - R11 - R12 - R13의 경로를 따라서 전송되었다고 가정하면, 최초 INP 요청을 실행하지 못했던 노드만 경로에 포함되어 있으므로 마찬가지로 실행할 수 없게 된다. 따라서 R4_INP는 failed_nodes=[R12, R11]의 NACK 데이터 패킷을 수신한다. 즉, D_INP ( d+f, NACK, failed_nodes=[R12, R11], reson="no available resource” ).
이후, R4_INP는 자신이 해당 요청을 처리할 수 있는 지 확인 후 처리할 수 없다면 NACK 데이터 패킷이 R9_INP로 전달될 수 있도록 다시 인캡슐화(encapsulation)하여 R9 방향으로 회신한다. 이 때 failed_nodes 리스트는 최초 R9_INP로부터 수신한 exclude_nodes=[R12, R11, R9], 이번에 수신한 failed nodes=[R12, R11], 그리고 자신의 라우터 이름인 [R4]의 합집합이다. 즉, D_INP ( R4_INP / d+f, NACK, failed_nodes=[R12, R11, R9, R4], reason="no available resource” ).
R9_INP가 NACK 데이터 패킷을 수신하면 우선 해당 요청에 대한 detour_retry_limit=3을 확인한다. 우회 요청을 재시도할 수 있으므로 우회할 범위를 설정하는 속성을 다시 결정해야 한다. 본 예에서는 failed_nodes 리스트가 변경되었으므로 exclude_nodes 리스트만 변경하고 동일한 속성으로 재요청을 수행하는 것이 가능하다. failed_nodes에 포함되지 않은 가장 가까운 노드 리스트는 [R1, R15]이며, R9_INP가 R1은 선택했다고 가정하면, R9_INP는 detour_retry_limit을 1 감소시키고, R1_INP로 패킷을 인캡슐화(encapsulation)하여 전송한다. 즉, I_INP ( R1_INP / d+f, exclude_nodes=[R12, R11, R9, R4], detour_route=true, detour_hop_limit=0, max_detour_face=1, detour_policy='any' ).
이후, R1_INP가 이를 수신하고 detour_hop_limit=0이므로 자신이 실행 가능한지 확인한다. R1에서 실행이 가능하므로 d+f를 실행하고 그 결과를 인캡슐화(ecapsulation)하여 R9으로 회신한다. 즉, D_INP ( R1_INP / d+f, result="...” ).
이후, R9_INP가 이를 수신하면 패킷을 디캡슐화(decapsulation)하여 결과를 요청자 A에게 전달한다. 즉, D_INP ( d+f, result="...” )를 요청자에게 전달한다.
본 개시의 다양한 실시 예는 모든 가능한 조합을 나열한 것이 아니고 본 개시의 대표적인 양상을 설명하기 위한 것이며, 다양한 실시 예에서 설명하는 사항들은 독립적으로 적용되거나 또는 둘 이상의 조합으로 적용될 수도 있다.
또한, 본 개시의 다양한 실시 예는 하드웨어, 펌웨어(firmware), 소프트웨어, 또는 그들의 결합 등에 의해 구현될 수 있다. 하드웨어에 의한 구현의 경우, 하나 또는 그 이상의 ASICs(Application Specific Integrated Circuits), DSPs(Digital Signal Processors), DSPDs(Digital Signal Processing Devices), PLDs(Programmable Logic Devices), FPGAs(Field Programmable Gate Arrays), 범용 프로세서(general processor), 컨트롤러, 마이크로 컨트롤러, 마이크로 프로세서 등에 의해 구현될 수 있다.
본 개시의 범위는 다양한 실시 예의 방법에 따른 동작이 장치 또는 컴퓨터 상에서 실행되도록 하는 소프트웨어 또는 머신-실행 가능한 명령들(예를 들어, 운영체제, 애플리케이션, 펌웨어(firmware), 프로그램 등), 및 이러한 소프트웨어 또는 명령 등이 저장되어 장치 또는 컴퓨터 상에서 실행 가능한 비-일시적 컴퓨터-판독가능 매체(non-transitory computer-readable medium)를 포함한다.
이상에서 설명한 본 발명은, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 있어 본 발명의 기술적 사상을 벗어나지 않는 범위 내에서 여러 가지 치환, 변형 및 변경이 가능하므로, 본 발명의 범위는 전술한 실시예 및 첨부된 도면에 의해 한정되는 것이 아니다.
100 : NDN 네트워크
111, 112, 113 : INP 노드
111a, 112a, 113a : INP 모듈
121, 122 : NDN 노드

Claims (1)

  1. 인-네트워크 프로세싱 (INP, In-Network Processing) 수행이 가능한 네트워크 노드의 네트워크 서비스 방법에 있어서,
    설정된 최적 경로를 벗어난 INP 인터리스트 패킷(interest packet)을 수신하는 단계, 및
    상기 수신된 인터리스트 패킷을 최적 경로가 아닌 인접 INP 노드로 전달하기 위해, 상기 인터리스트 패킷에 상기 인접 INP 노드 이름과 우회 속성 정보를 추가하여 인캡슐화(encapsulation)하여 전달하는 단계를 포함하는, 네크워크 노드의 네트워크 서비스 방법.
KR1020180148971A 2018-11-27 2018-11-27 인-네트워크 프로세싱 수행이 가능한 네트워크 노드의 네트워크 서비스 방법 KR20200062948A (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020180148971A KR20200062948A (ko) 2018-11-27 2018-11-27 인-네트워크 프로세싱 수행이 가능한 네트워크 노드의 네트워크 서비스 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020180148971A KR20200062948A (ko) 2018-11-27 2018-11-27 인-네트워크 프로세싱 수행이 가능한 네트워크 노드의 네트워크 서비스 방법

Publications (1)

Publication Number Publication Date
KR20200062948A true KR20200062948A (ko) 2020-06-04

Family

ID=71081140

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020180148971A KR20200062948A (ko) 2018-11-27 2018-11-27 인-네트워크 프로세싱 수행이 가능한 네트워크 노드의 네트워크 서비스 방법

Country Status (1)

Country Link
KR (1) KR20200062948A (ko)

Similar Documents

Publication Publication Date Title
EP3367638B1 (en) Load balancing method, device and system
CN112470436B (zh) 用于提供多云连通性的系统、方法、以及计算机可读介质
RU2742542C1 (ru) Способ, устройство и оборудование для передачи данных и считываемый носитель данных
US9762494B1 (en) Flow distribution table for packet flow load balancing
KR100984384B1 (ko) 클러스터 노드들을 권위적 도메인 네임 서버들로서사용하여 액티브 부하 조절을 하는 시스템, 네트워크 장치,방법, 및 컴퓨터 프로그램 생성물
US10205698B1 (en) Source-dependent address resolution
US9419940B2 (en) IPv4 data center support for IPv4 and IPv6 visitors
CN105610632B (zh) 一种虚拟网络设备及相关方法
CN109474936B (zh) 应用于多个lora网关之间的物联网通讯方法及系统
US8737388B2 (en) Method, apparatus and system for processing packets
WO2014190791A1 (zh) 一种网关设备身份设置的方法及管理网关设备
EP2534796A2 (en) Methods, systems, and computer readable media for providing local application routing at a diameter node
CN107404512B (zh) 资源订阅方法、资源订阅装置和资源订阅系統
CN110474802B (zh) 设备切换方法及装置、服务系统
US20180013673A1 (en) Data processing
EP3598705B1 (en) Routing control
KR102237299B1 (ko) 트래픽 엔지니어링 서비스 매핑
WO2022143818A1 (zh) 故障处理方法、控制面网元、切换决策网元及相关设备
CN109450768B (zh) 容器互联的方法及用于容器互联的系统
EP3503484B1 (en) Message transmission methods and devices
US20200186463A1 (en) Method and system for name-based in-networking processing
KR20200062948A (ko) 인-네트워크 프로세싱 수행이 가능한 네트워크 노드의 네트워크 서비스 방법
US20230102122A1 (en) Methods, systems, and computer readable media for identifying alternate delivery endpoints for mobile originated data and monitoring reports in a communications network
CN108632173B (zh) 一种资源访问系统及基于局域网的资源访问方法
US20080298366A1 (en) Agnostic Network Architecture