KR102394773B1 - 네임 기반 인-네트워크 프로세싱 방법 및 시스템 - Google Patents

Abstract

본 발명은 네임 기반 인-네트워크 시스템에서 데이터 처리를 위해 INP 실행 위치를 결정하는 방법을 제공할 수 있다. INP 실행 위치를 결정하는 방법은 제 1 라우터가 INP 인터레스트 패킷을 수신하는 단계, 제 1 라우터가 INP 인터레스트 패킷에 포함된 유저 정책 정보 및 제한 조건 정보에 기초하여 제 1 라우터에서 INP를 실행할지 여부를 결정하는 단계를 포함할 수 있다. 이때, 제 1 라우터가 INP를 실행할 수 있는 경우, 제 1 라우터는 실행 환경을 생성하여 함수를 실행하고, 제 1 라우터가 INP를 실행할 수 없는 경우, 제 1 라우터는 INP 인터레스트 패킷을 제 2 라우터로 전달할 수 있다.

Description

네임 기반 인-네트워크 프로세싱 방법 및 시스템 {Method and System for processing Name-based In-network}

본 발명은 네임 기반 인-네트워크 프로세싱 방법 및 시스템을 제공할 수 있다.

본 발명은 네임 기반 네트워크 환경에서 네트워크 인프라가 유저에게 원하는 데이터를 제공하는 역할 및 데이터에 대한 프로세싱도 함께 지원하는 방법을 제공할 수 있다.

구체적으로, 네임 기반 네트워크 환경에서 네임 기반의 유저 데이터에 대한 처리 요청을 전달 받은 후, 네트워크 내의 적절한 위치에서 필요한 컴퓨팅 작업을 수행하여 유저에게 리턴하는 방법을 제공할 수 있다.

최근의 인터넷의 주된 응용은 전통적인 point-to-point 형태의 통신보다는 대규모의 콘텐츠에 대한 생산과 전달로 변화했으며, 인터넷 유저는 그들이 원하는 콘텐츠가 무엇인지에 신경을 쓰지 그 콘텐츠가 어디에 위치하는가는 관심이 없다. 이에 대한 대응으로 기존의 호스트 중심의 통신 메커니즘에서 벗어나 네임드 인포메이션(또는 콘텐츠 또는 데이터)에 초점을 맞춘 정보 중심 네트워킹 (ICN: Information Centric Networking)의 개념이 등장하게 되었으며, 이를 위한 네임 기반 네트워크 프로세싱 방법이 필요할 수 있다. ICN에서는 모든 데이터에 이름을 부여하고 이 이름을 기반으로 통신이 수생된다. ICN의 대표적인 프로젝트로는 CCN (Content Centric Networking), NDN (Named Data Networking) 등이 있다. CCN과 NDN은 같은 뿌리를 가진 프로젝트로서 개념적으로 큰 차이는 없기 때문에 하기에서는 NDN으로 통칭한다. 또한, 콘텐츠, 데이터 등의 용어도 NDN에서 사용하는 데이터로 통일하여 지칭한다.

본 발명은 네임 기반 인-네트워크 프로세싱 방법 및 시스템을 제공하는데 목적이 있다.

본 발명은 ICN 기반의 네트워크에서 인-네트워크 프로세싱을 위한 실행 노드를 결정하는 방법을 제공하는데 목적이 있다.

본 발명은 실행 노드를 결정하는데 있어서 중앙집중식 서버의 도움 없이 콘텐츠 기반의 라우팅 방식을 통해 최적의 실행 노드를 선정하는 방법을 제공하는데 목적이 있다.

본 발명은 함수의 특성과 유저 정책을 반영하여 최적의 실행 노드를 선정하는 방법을 제공하는데 목적이 있다.

본 발명은 새로운 요청에 대해서 바로 최적의 노드가 선정되도록 하는 방법을 제공하는데 목적이 있다.

본 발명의 일 실시예에 따르면, 네임 기반 인-네트워크 시스템에서 데이터 처리를 위해 INP(In-Network Processing) 실행 위치를 결정하는 방법을 제공할 수 있다. 이때, INP 실행 위치를 결정하는 방법은 제 1 라우터가 INP 인터레스트 패킷을 수신하는 단계, 제 1 라우터가 INP 인터레스트 패킷에 포함된 유저 정책 정보 및 제한 조건 정보에 기초하여 제 1 라우터에서 INP를 실행할지 여부를 결정하는 단계를 포함할 수 있다. 이때, 제 1 라우터가 INP를 실행할 수 있는 경우, 제 1 라우터는 실행 환경을 생성하여 함수를 실행하고, 제 1 라우터가 INP를 실행할 수 없는 경우, 제 1 라우터는 INP 인터레스트 패킷을 제 2 라우터로 전달할 수 있다.

본 발명의 일 실시예에 따르면, 네임 기반 인-네트워크 시스템에서 데이터 처리를 위해 INP 실행 위치를 결정하는 라우터를 제공할 수 있다. 이때, 라우터는 정보를 송수신하는 송수신부, 송수신부를 제어하는 프로세서를 포함할 수 있다. 이때, 프로세서는 송수신부를 통해 INP 인터레스트 패킷을 수신하고, INP 인터레스트 패킷에 포함된 유저 정책 정보 및 제한 조건 정보에 기초하여 라우터에서 INP를 실행할지 여부를 결정할 수 있다. 이때, 라우터가 INP를 실행할 수 있는 경우, 프로세서는 실행 환경을 생성하여 함수를 실행하고, 라우터가 INP를 실행할 수 없는 경우, 프로세서는 INP 인터레스트 패킷을 다른 라우터로 전달할 수 있다.

본 발명의 일 실시예에 따르면, 네임 기반 인-네트워크 시스템에서 데이터 처리를 위해 INP 실행 위치를 결정하는 시스템을 제공할 수 있다. 이때, INP 실행 위치를 결정하는 시스템은 복수 개의 라우터를 포함하고, 시스템은 유저로부터 수신한 데이터를 처리하되, 시스템이 데이터 처리를 위해 INP 실행 위치를 결정하는 경우, 복수 개의 라우터 중 제 1 라우터가 INP 인터레스트 패킷을 수신하고, 제 1 라우터가 INP 인터레스트 패킷에 포함된 유저 정책 정보 및 제한 조건 정보에 기초하여 제 1 라우터에서 INP를 실행할지 여부를 결정할 수 있다. 이때, 제 1 라우터가 INP를 실행할 수 있는 경우, 제 1 라우터는 실행 환경을 생성하여 함수를 실행하고, 제 1 라우터가 INP를 실행할 수 없는 경우, 제 1 라우터는 INP 인터레스트 패킷을 제 2 라우터로 전달할 수 있다.

또한, 네임 기반 인-네트워크에서 데이터 처리를 위해 INP 실행 위치를 결정하는 방법, 장치 및 시스템에서 다음 사항들이 공통으로 적용될 수 있다.

또한, 본 발명의 일 실시예에 따르면, INP 인터레스트 패킷에는 라우팅 네임(Routing name), 함수 네임(Function name) 및 함수 아규먼트 네임(Function Argument name)이 포함될 수 있다.

이때, 본 발명의 일 실시예에 따르면, 라우팅 네임은 INP 인터레스트 패킷의 라우팅 방향을 지시하고, 함수 네임 및 함수 아규먼트 네임은 INP가 실행되는 경우에 실행 환경이 생성되어 함수가 실행되는 과정에서 이용될 수 있다.

또한, 본 발명의 일 실시예에 따르면, 유저 정책 정보는 데이터 인접 위치 선호 정책(NEAR DATA), 클라이언트 인접 위치 선호 정책(NEAR_CLIENT) 및 인프라 위임 정책(ANY) 중 적어도 어느 하나로 설정될 수 있다.

또한, 본 발명의 일 실시예에 따르면, 유저 정책 정보가 클라이언트 인접 위치 선호 정책인 경우, INP 실행 위치는 제한 조건 정보를 만족하는 라우터 중 유저와 가장 가까운 라우터로 결정될 수 있다.

또한, 본 발명의 일 실시예에 따르면, 유저 정책 정보가 데이터 인접 위치 선호 정책인 경우, INP 실행 위치는 제한 조건 정보를 만족하는 라우터 중 데이터와 가장 인접한 라우터로 결정될 수 있다.

또한, 본 발명의 일 실시예에 따르면, 유저 정책 정보가 데이터 인접 위치 선호 정책이고, 제한 조건 정보가 만족하는 경우, 제 1 라우터는 INP 인터레스트 패킷을 수신하면 제 1 라우터가 최종 라우터인지 여부를 확인할 수 있다.

또한, 본 발명의 일 실시예에 따르면, 제 1 라우터가 최종 라우터인지 여부를 확인하는 경우, 1 라우터는 제 2 라우터로 수신한 INP 인터레스트 패킷, 제 1 라우터가 생성한 제 1 패킷 및 제 1 라우터가 생성한 제 2 패킷을 제 2 라우터로 전송할 수 있다.

이때, 본 발명의 일 실시예에 따르면, 제 1 라우터가 제 2 라우터로부터 제 1 패킷에 대한 응답 패킷을 수신하는 경우, 제 1 라우터는 최종 라우터로 결정될 수 있다.

또한, 본 발명의 일 실시예에 따르면, 제 1 라우터가 제 2 라우터로부터 제 2 패킷에 대한 응답 패킷을 수신하는 경우, 제 2 라우터에서 제 2 라우터가 최종 라우터인지 여부가 결정될 수 있다.

이때, 본 발명의 일 실시예에 따르면, 제 1 패킷은 Int(R)이고, 제 2 패킷은 Int(R/F/A/CLS)일 수 있다.

또한, 본 발명의 일 실시예에 따르면, 제한 조건 정보는 함수를 실행하기 위한 실행 환경에 대한 조건 정보를 지시할 수 있다.

또한, 본 발명의 일 실시예에 따르면, 제 2 라우터는 제 1 라우터의 다음 라우터일 수 있다.

본 발명에 따르면, 네임 기반 인-네트워크 프로세싱 방법 및 시스템을 제공할 수 있다.

본 발명에 따르면, ICN 기반의 네트워크에서 인-네트워크 프로세싱을 위한 실행 노드를 결정하는 방법을 제공할 수 있다.

본 발명에 따르면, 실행 노드를 결정하는데 있어서 중앙집중식 서버의 도움 없이 콘텐츠 기반의 라우팅 방식을 통해 최적의 실행 노드를 선정하는 방법을 제공할 수 있다.

본 발명에 따르면, 함수의 특성과 유저 정책을 반영하여 최적의 실행 노드를 선정하는 방법을 제공할 수 있다.

본 발명에 따르면, 새로운 요청에 대해서 바로 최적의 노드가 선정되도록 하는 방법을 제공할 수 있다.

본 개시에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

도 1은 NDN을 나타낸 도면이다.
도 2는 네임 기반의 인-네트워크 프로세싱(INP)을 나타낸 도면이다.
도 3은 NDN 패킷 구조를 기반으로 한 INP 인터레스트 패킷의 구조를 나타낸 도면이다.
도 4는 INP 라우터 구조와 INP 컴퓨팅 서버(Compute Server)를 나타낸 도면이다.
도 5는 INP 컴퓨팅 에이전트(INP Computing Agent, ICA)를 나타낸 도면이다.
도 6은 IRA에서 INP 실행 위치를 결정하는 방법을 나타낸 도면이다.
도 7은 INP 실행 위치를 결정하는 방법을 나타낸 도면이다.
도 8은 본 발명에 따라 각 노드의 구성을 나타낸 도면이다.

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

본 개시의 실시 예를 설명함에 있어서 공지 구성 또는 기능에 대한 구체적인 설명이 본 개시의 요지를 흐릴 수 있다고 판단되는 경우에는 그에 대한 상세한 설명은 생략한다. 그리고, 도면에서 본 개시에 대한 설명과 관계없는 부분은 생략하였으며, 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.

본 개시에 있어서, 어떤 구성요소가 다른 구성요소와 "연결", "결합" 또는 "접속"되어 있다고 할 때, 이는 직접적인 연결관계뿐만 아니라, 그 중간에 또 다른 구성요소가 존재하는 간접적인 연결관계도 포함할 수 있다. 또한 어떤 구성요소가 다른 구성요소를 "포함한다" 또는 "가진다"고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 배제하는 것이 아니라 또 다른 구성요소를 더 포함할 수 있는 것을 의미한다.

본 개시에 있어서, 제1, 제2 등의 용어는 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용되며, 특별히 언급되지 않는 한 구성요소들간의 순서 또는 중요도 등을 한정하지 않는다. 따라서, 본 개시의 범위 내에서 일 실시 예에서의 제1 구성요소는 다른 실시 예에서 제2 구성요소라고 칭할 수도 있고, 마찬가지로 일 실시 예에서의 제2 구성요소를 다른 실시 예에서 제1 구성요소라고 칭할 수도 있다.

본 개시에 있어서, 서로 구별되는 구성요소들은 각각의 특징을 명확하게 설명하기 위함이며, 구성요소들이 반드시 분리되는 것을 의미하지는 않는다. 즉, 복수의 구성요소가 통합되어 하나의 하드웨어 또는 소프트웨어 단위로 이루어질 수도 있고, 하나의 구성요소가 분산되어 복수의 하드웨어 또는 소프트웨어 단위로 이루어질 수도 있다. 따라서, 별도로 언급하지 않더라도 이와 같이 통합된 또는 분산된 실시 예도 본 개시의 범위에 포함된다.

본 개시에 있어서, 다양한 실시 예에서 설명하는 구성요소들이 반드시 필수적인 구성요소들을 의미하는 것은 아니며, 일부는 선택적인 구성요소일 수 있다. 따라서, 일 실시 예에서 설명하는 구성요소들의 부분집합으로 구성되는 실시 예도 본 개시의 범위에 포함된다. 또한, 다양한 실시 예에서 설명하는 구성요소들에 추가적으로 다른 구성요소를 포함하는 실시 예도 본 개시의 범위에 포함된다.

본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시예들을 참조하면 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 제시되는 실시예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시예들은 본 발명의 개시가 완전하도록 하고, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이다.

도 1은 NDN에 기초하여 동작하는 방법을 나타낸 도면이다. 상술한 NDN은 유저(110)와 연결된 하나 이상의 노드를 포함할 수 있다. 이때, 각각의 노드는 스토리지를 포함하거나 부착하고 있는 엔티티일 수 있다. 이때, 유저(110)가 요청한 콘텐츠는 유저(110) 근처에 위치한 노드에 포함되거나 부착된 스토리지로부터 획득할 수 있다. 즉, NDN은 콘텐츠가 각각의 노드에 배치될 수 있으며, 이를 통해 유저(110)에게 빠른 서비스가 가능할 수 있다. 또한, 일 예로, NDN은 IP 헤더 대신 콘텐츠의 명칭을 이용하여 콘텐츠를 송수신할 수 있다. 보다 상세하게는, 유저(110)가 요청하는 콘텐츠의 명칭으로 구성된 인터레스트를 브로드캐스팅할 수 있다. 이때, 인터레스트는 유저(110)의 콘텐츠 요청 패킷일 수 있다. 즉, 유저(110)는 콘텐츠를 요청하기 위해 인터레스트를 전송할 수 있다. 한편, 요청된 콘텐츠를 저장하고 있는 노드가 인터레스트를 수신하는 경우, 해당 노드는 인터레스트에 대한 응답으로 콘텐츠를 전달할 수 있다. 이때, 일 예로, 상술한 NDN은 유무선 네트워크에 기초하여 구현될 수 있으며, 상술한 실시예로 한정되지 않는다. 또한, 일 예로, NDN에서 포워딩 테이블은 펜딩 인터레스트 테이블(PIT : Pending Interest Table)과 포워딩 정보 베이스(FIB : Forwarding Information Base)로 나뉠 수 있다. 이때, PIT는 콘텐츠 요청자가 어디에 있는지를 지시하는 정보일 수 있다. 또한, FIB는 인터레스트가 어디로 전달되는지를 지시할 수 있다. PIT는 인터레스트의 명칭과 인터레스트의 도착 지점 간의 맵핑을 저장할 수 있다.

NDN 에서는 두 가지 패킷 타입이 사용될 수 있다. 이때, 패킷 타입은 상술한 인터레스트(Interest)와 데이터(Data) 패킷일 수 있다. 또한, NDN에서는 데이터 컨슈머(또는 유저)에 의해 통신이 시작될 수 있다. 이때, 컨슈머는 원하는 데이터의 이름을 인터레스트 패킷에 포함시켜 네트워크에 보내고, 라우터는 FIB(Forwarding Information Base)를 기반으로 라우팅을 수행할 수 있다. 만약 라우터가 인터레스트 패킷에 포함된 이름과 매칭되는 데이터를 갖고 있다면 해당 데이터를 데이터 패킷에 포함시켜 반대 방향으로 보낼 수 있다.

또한, 라우터는 다음 노드로 포워딩된 인터레스트 패킷 및 그에 대한 데이터 패킷이 도착하는 경우, 라우터는 목적지 정보를 PIT (Pending Information Table)을 통해 관리할 수 있다. 또한, 라우터는 미래의 동일한 요청을 보다 빨리 처리하기 위해 자신이 전달한 데이터를 CS (Content Store)에 일정시간 캐싱할 수 있다.

또한, 일 예로, 로컬 호스트에서의 프로세싱 (또는 컴퓨팅) 기능마저도 네트워크에 위탁하는 인-네트워크 프로세싱 (INP, In-network Processing)을 고려할 수 있다. 상술한 바를 통해, 로컬 호스트에 충분한 리소스가 없을 때에도 필요한 프로세싱 작업을 가능하게 할 수 있다. 또한, 프로세싱에 필요한 호스트를 로컬 호스트에 수신할 필요 없이 데이터 인접 노드에서 처리함으로써 보다 빠른 처리가 가능하고 네트워크 오버헤드를 줄일 수 있다.

이때, ICN 기반의 INP로서 NFN(Named Function Networking)과 NFaaS(Named Function as a Service)를 고려할 수 있다. 일 예로, NFN에서는 NDN에서의 네임 레졸루션(resolution)을 익스프레션 레졸루션(expression resolution)으로 확장하여 네트워크에서 원하는 정보를 찾아주는 것뿐만 아니라 계산 기능까지 제공하여 그 결과를 전달할 수 있다.

또한, 유저는 람다 표현식을 사용하여 원하는 함수 처리를 명명하고, 네트워크로 그 실행 결과를 전달할 수 있다. 이때, 유저는 람다 표현식에서 함수 이름을 먼저 오게 할 수도 있다. 또는, 유저는 람다 표현식에서 입력 데이터 이름을 먼저 오게 기술할 수 있으며, 상술한 바를 통해 인터레스트의 라우팅 방향을 지정할 수 있다. 한편, 네트워크는 람다 표현식에 기술된 데이터 혹은 함수 이름 중에 먼저 기술된 이름에 매칭된 콘텐츠를 찾을 때까지 인터레스트 라우팅을 계속할 수 있다. 이때, 네트워크는 매칭되는 노드를 만나면 그 노드에서 람다 표현식에 대한 레졸루션을 수행할 수 있다. 즉, 네트워크는 프로세싱 과정을 수행할 수 있다.

반면, NFaaS에서는 각 노드에서의 함수의 인기도에 따라 그 노드에 함수의 실행 코드의 인스톨 여부가 결정되는데, 인기도는 함수의 요청 빈도와 포워딩 전략(forwarding strategy)를 기반으로 한 유니커널 스코어 (unikernel score)에 따라 결정될 수 있다. NFaaS에서는 현재 지연 시간과 대역폭에 기반한 두 가지 포워딩 전략을 정의하고 있다. 일 예로, 지연 시간 기반의 전략을 사용하는 경우, 엣지 사이드 노드에서 상술한 바를 실행할 수 있다. 또한, 일 예로, 대역폭 기반의 전략을 사용하는 경우, 코어 사이드 노드에서 실행될 수 있으나, 상술한 실시예로 한정되지 않는다.

또한, NFN이나 NFaaS와 같이 기존의 ICN 기반의 인-네트워크 프로세싱 방식에서는 매칭되는 함수나 데이터를 가지고 있는 노드이거나, 요청된 함수에 대해 일정 수준 이상의 포인트를 채운 노드에 기초하여 프로세싱을 수행할 수 있다. 이때, 매칭되는 함수나 데이터를 가지고 있는 노드에 기초하는 경우, 콘텐츠의 매칭 여부로만 실행 노드를 결정하기 때문에 함수의 특성이나 유저 정책을 반영하여 실행 위치를 결정할 수 없다. 따라서, 해당 콘텐츠(함수 또는 데이터)가 캐싱되어 있는 라우터를 만날 때까지 계속 라우팅을 진행해야하기 때문에 캐시 히트되는 라우터를 만나지 못하는 경우에 함수 실행은 실패할 수 있다.

반면, 요청한 함수에 대해 일정 수준 이상의 포인트를 채운 노드에 기초하는 경우, 실행 노드의 결정이 함수의 인기도에 기반한 포인트에 의해 결정되기 때문에 포인트를 채우기까지의 수렴 시간이 필요할 수 있다. 따라서, 새로운 함수 요청의 경우, 해당 함수를 처리하는 위치는 최적의 위치가 아닐 확률이 높을 수 있다.

하기에서는 상술한 바에 기초하여 ICN 기술에 대해 NDN을 기준으로 서술하지만, 이에 한정되지 않는다.

이때, 일 예로, 도 2는 네임 기반의 인-네트워크 프로세싱(INP)을 나타낸 도면이다.

도 2를 참조하면, 네트워크는 INP 처리를 지원하는 INP 라우터와 INP 처리를 지원하지 않는 Non-INP 라우터로 구성될 수 있다. 이때, Non-INP 라우터는 INP 인터레스트 패킷을 네임 기반으로 다음 라우터로 포워딩 하는 역할만을 수행할 수 있다. 이때, INP 인터레스트는 일반적인 NDN 인터레스트 패킷과 동일한 패킷 처리 과정을 거치며, 이에 대해서는 후술한다.

INP 라우터는 INP 인터레스트 패킷을 수신하면 인터레스트에 포함된 유저 정책과 실행환경 제한조건을 참조하여 자신이 INP 실행을 수행할지 또는 다음 노드로 전달할지 여부를 결정할 수 있다.

이때, 일 예로, INP 라우터에서 INP 실행이 결정된 경우, 사전에 설정된 실행 서버 중 하나를 선택하여 그 서버에서 실행환경의 생성을 요청할 수 있다. 이때, 해당 서버는 실행 환경을 생성하고 요청된 함수를 실행시켜 함수의 실행 인스턴스(running instance)를 생성할 수 있다. 이때, 서버의 로컬 환경에 실행 함수의 실행 코드 데이터가 없는 경우에는 별도의 NDN 데이터 전달 과정을 거쳐 실행 코드를 다운로드할 수 있다. 그 후, 생성된 함수의 실행 인스턴스는 함수 처리에 필요한 데이터를 데이터 발행자로부터 전달받아 데이터 처리를 수행한 후 그 결과를 유저에게 전달할 수 있다. 이때, 전달 과정은 NDN의 전달 방식과 동일할 수 있다.

일 예로, 도 2를 참조하면, 유저(210, User #1)은 INP로 콘텐츠를 요청할 수 있다. 즉, 유저(210)에 의해 INP 인터레스트 패킷이 INP 네트워크로 전달될 수 있다. 이때, 일 예로, INP #1은 유저(210)로부터 수신한 INP 인터레스트를 자신이 처리할지 또는 전달할지 여부를 결정할 수 있다. 일 예로, 도 2에서 INP #1은 NON-INP #1로 전달할 수 있다. 이때, NON-INP #1은 NON-INP인바 다시 INP #2로 전달할 수 있다. INP #2도 INP 인터레스트를 자신이 처리할지 또는 전달할지 여부를 결정할 수 있으며, 도 2에서는 INP #3으로 전달할 수 있다. 이때, INP #3은 INP 인터레스트를 직접 처리할 수 있으며, 이를 위해 서버에게 실행 환경의 생성을 요청할 수 있다. 이를 통해 실행 환경이 설정되고 요청된 함수를 실행시켜 함수의 실행 인스턴스(running instance)를 생성할 수 있다. 그 후, 생성된 함수의 실행 인스턴스는 함수 처리에 필요한 데이터를 데이터 발행자(Data Publisher #1, 220)로부터 전달받아 데이터 처리를 수행한 후 그 결과를 유저(210)에게 전달할 수 있다. 이때, 유저에게 전달되는 데이터는 INP 인터레스트 패킷의 반대 방향으로 전달될 수 있다.

또한, 네트워크는 INP 처리에 사용되는 함수의 실행 코드를 저장 관리하는 함수 레포지토리 (Function Repository)를 제공할 수 있다. 함수 실행 코드 제공자는 함수 레포지토리에 실행 코드를 등록할 수 있다. 또한, INP 처리를 실행하는 INP 서버는 함수 실행 코드를 함수 레포지토리로부터 전달 받아 함수를 실행할 수 있다. 함수 레포지토리가 네트워크에 존재하지 않는 경우에 INP 서버는 함수 실행 코드의 발행자로부터 직접 실행 코드 데이터를 전달 받아야 한다.

도 2에서 유저(User #1, 210)는 데이터 D1을 입력으로 함수 F1을 실행한 INP 결과를 얻기 위해 함수 F1과 데이터 D1을 네임으로 결합하여 네트워크에 INP 인터레스트를 보낼 수 있다. 이때 INP 실행 위치 결정에 반영할 유저 정책 P와 함수 실행 환경이 만족시켜야 하는 제한조건 C를 인터레스트에 포함할 수 있다. 유저 정책 P와 제한조건 C에 대해서는 후술한다.

상술한 바와 같이, INP 인터레스트는 라우터 INP#1, Non-INP#1, INP#2를 거쳐 INP#3로 전달되고, INP#3는 요청된 INP 실행을 결정하고 실행 환경을 생성하고 함수 F1의 실행 코드를 다운 받아 실행 인스턴스를 생성할 수 있다. 이때, 생성된 실행 인스턴스는 입력 데이터 D1을 데이터 발행자(Data Publisher #1, 220)으로부터 전달받아 데이터 처리를 수행한 후 그 결과를 다시 INP 인터레스트가 전달된 패스의 반대 방향 패스를 통해 유저(210)에게 전달할 수 있으며, 이는 상술한 바와 같다.

한편, INP 인터레스트에서는 네임은 하기 표 1의 표현식과 같이 구성될 수 있다. 일 예로, INP 네임은 라우팅 네임, 함수 네임, 함수의 아규먼트 네임이 결합되어 통합된 네임을 구성할 수 있다. 이때, 각각의 네임은 TLV (Type-Length-Value) 형태로 정의되며, 각각의 네임을 위한 개별 타입이 정의될 수 있다. 일 예로, NDN에서 일반적인 네임 타입 넘버를 7로 정의되어 있으며, 128~252 값을 애플리케이션 목적으로 사용할 수 있도록 하였는데 이 값을 사용하여 개별 타입을 정의할 수 있다. 하기 실시예에서는 라우팅 네임(routing_name)의 타입은 7, 함수 네임(function_name)은 222, 함수의 아규먼트 네임(argument_name)은 223을 사용하는 것으로 정의하였으나, 이는 하나의 일 예일 뿐, 이에 한정되지 않는다. 또한, 상술한 바 이외에도 INP 목적으로 생성되는 인터레스트 및 데이터 네임에 대해 별도의 타입 넘버를 지정하여 사용하는 것도 가능할 수 있다.

한편, 라우팅 네임은 상술한 FIB에 longest-prefix matching 되어 INP 인터레스트 패킷의 라우팅 방향을 결정하는데 활용될 수 있다. 이를 통해, 유저는 INP 인터레스트 패킷의 라우팅 방향을 지정할 수 있다. 일 예로, 라우팅 네임에 데이터 네임을 사용한 경우, INP 인터레스트는 해당 데이터 발행위치를 향해 라우팅 될 수 있다. 반면, 라우팅 네임에 함수 네임이 지정된 경우, INP 인터레스트 패킷은 해당 함수가 발행된 위치로 라우팅될 수 있다. 또 다른 일 예로, 라우팅 네임에 서버 네임이 직접 지정된 경우, INP 인터레스트 패킷은 INP 처리 노드로 라우팅될 수 있다.

또한, 일 예로, 함수 네임과 아규먼트 네임은 INP 라우터에서 INP 처리를 위한 목적으로 사용될 수 있다. 아규먼트 네임에는 함수 실행에 입력으로 사용될 복수의 입력값이 포함될 수 있으며, 처리 대상이 되는 데이터의 네임, 함수 실행을 위한 설정값 등이 포함될 수 있다.

INP 인터레스트에서 각각의 네임이 설정될 수 있으며, 이는 하기 수학식 1과 같을 수 있다.

[표 1]

또한, 일 예로, 도 3은 NDN 패킷 구조를 기반으로 한 INP 인터레스트 패킷의 구조를 나타낸 도면이다. 도 3을 참조하면, INP 인터레스트 패킷에서 네임은 상술한 바와 같이, 라우팅 네임, 함수 네임 및 아규먼트 네임으로 구성될 수 있다. 즉, NDN 패킷 구조 중 네임(name)에 대응되는 필드 구성이 상술한 바와 같이 복수 개의 네임으로 구성될 수 있다. 한편, 일 예로, 파라미터(Parameter)로서 유저 정책(Policy)과 함수 실행을 위한 제한조건(constraints)이 더 포함될 수 있다. 이때, 일 예로, 상술한 각각의 필드는 네임과 마찬가지로 별도의 TLV 형태로 정의될 수 있다.

이때, 일 예로, 유저 정책의 경우 INP 실행 위치 결정을 위한 유저 요구 사항을 반영하기 위한 필드일 수 있다. 보다 상세하게는, 유저는 트래픽을 줄이기 위해 INP의 실행 위치가 데이터 가까운 곳에서 실행되는 것을 원할 수도 있다. 또한, 일 예로, 유저는 응답 시간을 줄이기 위해 자신과 보다 가까운 위치에서 INP가 실행되기를 원할 수 있다. 또한, 일 예로, 상술한 유저 정책뿐만 아니라 다른 정책이 설정되는 것도 가능할 수 있으며, 상술한 실시예로 한정되지 않는다. 일 예로, 데이터 인접 위치 선호 정책 (NEAR_DATA)을 고려할 수 있다. 또 다른 일 예로, 클라이언트 인접 위치 선호 정책 (NEAR_CLIENT)을 고려할 수 있다. 또 다른 일 예로, 전적으로 인프라에 위임하는 정책(ANY)을 고려할 수 있으나, 다른 정책을 정의하여 사용할 수도 있다.

또한, 제한 조건 (constraint)은 함수 실행을 위한 실행 환경이 만족시켜야 하는 최소한의 조건을 의미할 수 있다. 일 예로, 최소한의 코어 할당 수, 또는 가속 처리를 위한 GPU의 지원 등이 될 수 있다. 제한 조건과 관련하여 각각의 제한 조건은 TLV 형태로 정의되어 별도의 타입 넘버가 할당될 수 있다. 또한, INP 라우터는 INP 처리 위치를 결정함에 있어 로컬 컴퓨팅 환경에서 제한 조건을 만족시킬 수 있는 실행 환경의 생성 가능 여부를 가장 먼저 검토할 수 있으며, 상술한 필드를 이를 위한 필드일 수 있다.

도 4는 INP 라우터 구조와 INP 컴퓨팅 서버(Compute Server)를 나타낸 도면이다. 도 4를 참조하면, INP 라우터(400)는 하나 이상의 컴퓨팅 서버(460, 470)과 연동되어 동작할 수 있다. 이때, 일 예로, INP 라우터(400)와 INP 컴퓨팅 서버(또는 서버들, 460, 470)은 NDN 네트워크로 연결될 수 있다. 즉, NDN 기반의 통신을 지원할 수 있다. 이때, INP 컴퓨팅 서버(460, 470)에는 INP 라우터(400)와 연동을 지원하는 INP 서버 에이전트(INP Server Agent, ISA, 461, 471)와 실행 환경(Execution Engine, 462, 463, 472, 473)으로 구성될 수 있다. 이때, ISA(461, 471)는 실행 환경의 생성 및 관리 기능을 수행할 수 있다. 또한, ISA(461, 471)는 함수 실행 관리 등의 기능을 수행하며 부가적으로 로컬 자원 상태를 주기적으로 IRA(INP Router Agent, 450)에 알리는 역할을 수행할 수 있다.

한편, INP 라우터(400)는 기존 NDN 라우터에서 지원하는 CS (Content Store, 420), PIT(430) 및 FIB(440)를 포함할 수 있다. 또한, 그 밖에도 INP 라우터(400)는 INP 필터(INP Filter, 410), IRA(450)를 더 포함할 수 있으며, 상술한 실시예로 한정되지 않는다.

이때, 일 예로, CS(420), PIT(430) 및 FIB(440)는 NDN 라우터에서의 역할과 동일한 기능을 수행할 수 있으며, 이는 상술한 바와 같다. 즉, CS(420)는 라우터를 지나는 데이터를 임시로 저장할 수 있다. 이때, NDN 라우터가 인터레스트를 수신하면 CS(420)에 매칭되는 데이터가 존재하는지를 체크하고, 매칭되는 데이터가 있으면 인터레스트가 수신된 인터페이스로 데이터를 전송하여 인터레스트 패킷이 더 이상 전달되는 것을 방지할 수 있다. 또한, PIT(430)는 다음 노드로 전달된 인터레스트의 수신 인터페이스와 송신 인터페이스에 대한 정보를 저장하며, 이미 전달된 인터레스트와 동일한 네임을 갖는 인터레스트가 수신된 경우 더 이상 전달하지 않고 단지 해당 인터레스트가 수신된 인터페이스 정보만을 추가할 수 있으며, 이는 상술한 바와 같다. 또한, FIB(440)는 네임 프리픽스에 대한 포워딩 정보를 가지고 있으며, 라우팅 프로토콜에 관리될 수 있다.

또한, 추가 구성으로, INP 필터(410)는 라우터에 수신된 인터레스트 및 데이터 패킷 중 INP 패킷만을 필터링 해 IRA(450)로 전달할 수 있다. 이때, INF 필터(410)는 수신된 패킷에 포함된 네임에 포함된 타입 넘버를 읽어 INP 타입에 해당되는지를 체크함으로써 INP 패킷인지 여부를 판별할 수 있다.

또한, IRA(450)는 INP 파서(INP Parser, 451), EE 공급자(EE Provisioner, 452), INP 위치 리솔버(INP Location Resolver, 453), 컴퓨팅 매니저(Compute Manager, 454) 및 컴퓨팅 자원 데이터베이스(Compute Resource DB, CRDB, 455) 중 적어도 어느 하나 이상을 더 포함할 수 있다.

이때, 컴퓨팅 매니저(454, CM)는 로컬 환경에서 INP 목적으로 사용 가능한 컴퓨팅 서버에 대한 설정 정보를 관리할 수 있다. 또한, CM(454)는 컴퓨팅 서버의 자원 정보를 주기적으로 모니터링하여 CRDB에 저장할 수 있다.

또한, 도 5는 INP 컴퓨팅 에이전트(INP Computing Agent, ICA)를 나타낸 도면이다.

도 5를 참조하면, ICA(510)는 자원 매니저(Resource Manager, 511), EE 매니저(EE Manager, 512) 및 로컬 함수 코드 매니저(Local Function Code Manager, 513) 중 적어도 어느 하나 이상을 포함할 수 있다. 이때, ICA(510) 역시 NDN에 기초하여 연결될 수 있다. 이때, ICA(510)는 각각의 구성을 통해서 자원 관리, 실행 환경 관리 및 함수 코드 관리를 수행할 수 있으며, 상술한 실시예로 한정되지 않는다. 자원 매니저(511)은 로컬 서버의 자원 관리를 담당하며 IRA의 컴퓨팅 매니저(454)의 요청에 의해 로컬 자원 상황을 전달할 수 있다. EE 매니저(512)는 EE공급자(452)의 요청에 의해 새로운 실행환경(EE)의 생성 및 삭제, 설정 관리 등을 담당하며, 실행환경이 생성되면 요청된 함수의 실행 코드를 다운로드 받아 실행하도록 하는 역할을 수행할 수 있다. 로컬 함수 코드 매니저(513)는 로컬 실행 환경에서 필요한 함수의 실행 코드를 관리하는 역할을 담당하며, 함수 구동을 보다 빨리 하기 위해 사전에 함수 레포지토리로부터 미리 실행 코드를 다운로드 받아 저장해 놓거나 이미 로컬 실행 환경에 다운로드 되어 실행되고 있는 실행 코드의 재사용을 위한 임시 저장소의 역할을 담당할 수 있다.

도 6은 IRA에서 INP 실행 위치를 결정하는 방법을 나타낸 도면이다. 도 6으 참조하면, 라우터가 INP 인터레스트 패킷을 수신한 경우, INP 파서는 INP 인터레스트 패킷에 포함된 네임으로부터 라우팅 네임, 함수 네임 및 아규먼트 네임 등을 구별할 수 있다. 또한, INP 파서는 파라미터 필드에 포함된 유저 정책과 제한 조건 등의 정보를 파악하는 역할을 수행할 수 있다.(S610)

다음으로, INP 위치 리솔버(ILR)은 INP 실행 위치를 결정하는 역할을 수행할 수 있다. 이때, INP 위치 리솔버는 컴퓨팅 자원 데이터베이스(Compute Resource DB)를 참조하여 INP 인터레스트에 정의된 제한 조건을 만족시킬 수 있는 컴퓨팅 서버가 로컬 환경에서 존재하는지 여부를 판단할 수 있다.(S620) 이때, 컴퓨팅 서버가 로컬 환경에서 존재하지 않는 경우, 즉 제한 조건을 만족하지 않는 경우, 라우터는 INP 인터레스트 패킷을 다음 라우터로 포워딩할 수 있다.(S630) 반면, 컴퓨팅 서버가 로컬 환경에 존재하는 경우, 즉 제한 조건을 만족하는 경우, ILR은 INP 실행을 위해 필요한 자원 할당이 가능한 컴퓨팅 서버를 검색할 수 있다.(S640) 이때, 컴퓨팅 서버의 자원 할당 가능 여부는 개별 서버에 따라 서로 다른 알고리즘에 의해 결정될 수 있으며, 이런 정보 역시 CM에 의해 수집되어 CRDB에 저장될 수 있다. 일 예로, 자원 할당이 가능한 서버가 없는 경우, 즉 자원이 충분하지 않은 경우, 라우터는 다음 라우터로 INP 인터레스트 패킷을 포워딩할 수 있다.(S630)

또한, 자원 할당이 가능한 서버가 있는 경우, 즉 자원이 충분한 경우, ILR은 INP 인터레스트에 명시된 유저 정책을 고려하여 로컬 서버에서 INP를 실행에 적합한지 여부를 판단할 수 있다.(S650) 일 예로, 유저 정책이 “CLIENT_NEAR”인 경우, 이미 해당 노드가 제한 조건을 만족시키고 필요한 자원 할당도 가능하기 때문에 EE 제공자를 통해 컴퓨팅 서버에 실행 환경을 생성하고 함수를 실행시킬 수 있다. 또 다른 일 예로, 유저 정책이 “ANY”인 경우, 실행 여부는 INP 라우터의 로컬 정책에 따라 실행 여부가 결정될 수 있다.

또한, 일 예로, 상술한 바에서 로컬 정책은 관리자에 의해 사전에 설정될 수 있다. 일 예로, 가용 자원량에 충분할 경우 무조건 실행 환경을 생성하고, 가용 자원량이 일정 수준 이하가 되면 다음 노드로 전달하는 확률을 점차 높일 수 있다.

이때, 유저 정책이 “CLIENT_NEAR”나 “ANY” 정책의 경우, 이미 실행 위치 결정 과정이 끝났기 때문에 트리거링 이벤트 없이 바로 실행 환경 생성 및 함수 실행 과정을 시작할 수 있다.(S660)

또 다른 일 예로, 유저 정책이 “NEAR_DATA”인 경우 유저는 되도록 데이터 위치와 인접한 위치에서 INP가 실행되길 원할 수 있다. 다만, INP 라우터는 해당 데이터의 위치를 알 수 없기 때문에 자신이 최적의 INP 실행 위치라는 판단을 내릴 수 없다. 즉, 라우팅 패스 상의 다음 노드가 자신 보다 더 적합한 위치인지를 파악하는 과정을 거쳐 데이터에 보다 가까운 노드가 발견되면 다시 그 노드의 다음 노드가 데이터에 보다 더 가까운 INP 실행 노드인지를 판단하는 과정을 반복적으로 수행하는 INP 실행 위치 결정 캐스케이딩 과정을 거쳐야 할 수 있다.

“NEAR_DATA” 정책을 반영한 실행 위치 결정을 위해 우선 자신이 데이터와 가장 인접한 실행 노드가 될 가능성에 대비해 EE 제공자에 실행 환경 생성 준비를 등록할 수 있다. 이는 로컬 자원에 대한 잠정적 예약을 의미할 수 있다. 이때 실행 환경 생성을 트리거링 하는 이벤트와 실행 환경 생성 후 함수 실행을 위한 커맨드 라인도 함께 등록될 수 있다. EE 제공자는 실행 환경 생성을 위한 준비만 할 뿐 실제 실행 환경의 생성은 트리거링 이벤트가 수신될 때 수행될 수 있다.

도 7은 INP 실행 위치를 결정하는 방법을 나타낸 도면이다.

도 7을 참조하면, INP Router #1 (IR#1, 710)이 라우팅 네임(routing_name, R), 함수 네임(function_name, F) 및 아규먼트 네임(argument_name, A)로 구성된 R/F/A라는 네임의 INP 인터레스트 패킷 Int(R/F/A)를 수신할 수 있다. 이때, ILR은 INP 실행 위치를 결정할 수 있다. 다만, 도 7은 설명의 편의를 위한 하나의 일 예일 뿐, 이에 한정되지 않는다. IR#1(710)의 ILR은 우선 제한 조건과 가용 자원량을 바탕으로 로컬 노드에서 INP 실행을 지원할 수 있는지 여부를 체크할 수 있다. 이때, INP 실행이 불가능하면 Int(R/F/A)를 다음 노드로 바이패스 시키고 과정을 종료할 수 있으며, 이는 도 6과 같다.

반면, 로컬 노드에서 INP 실행이 가능한 경우, ILR은 우선 현재 노드가 최종 노드인지 여부를 결정할 수 있다. 이때, ILR은 현재 노드가 최종 노드인지 여부를 결정하기 위해 로컬 Content Store (CS)에 라우팅 네임과 매칭되는 데이터가 캐싱되어 있는지 여부를 체크할 수 있다. 즉, 상술한 바와 같이, CS에는 콘텐츠가 캐싱될 수 있으며, CS에 라우팅 네임과 매칭되는 데이터가 있는 경우, 라우팅은 더 이상 진행될 필요가 없고, 해당 INP 라우터를 최종 실행 노드로 판단할 수 있다. 이때, 라우팅 네임 매칭이 성공한 경우, ILR은 EE 제공자를 통해 실행 환경을 즉각 생성하고 INP를 실행한 후 과정을 종료할 수 있다. 다음으로, ILR은 EE 제공자에 실행 환경 생성 준비를 등록하고, D(R)이 도착하면 실행 환경 생성이 시작되도록 트리거링 이벤트를 함께 등록할 수 있다.

다만, 상술한 바와 같이, ILR은 라우팅 패스 상의 다음 노드가 보다 적절한 노드인지를 파악하기 위해 부가적인 인터레스트 패킷을 생성하여 다음 노드로 전달할 수 있다. 이때, 노드는 수신된 Int(R/F/A) 패킷을 다음 노드로 전송함과 동시에 Int(R) 패킷 및 Int(R/F/A/CLR)을 생성하여 다음 노드로 포워딩 할 수 있다. 이때, Int(R)에 사용되는 네임 R은 NDN의 네임 타입과 구별되는 별도의 TLV 타입 넘버를 사용할 수 있다. 이를 통해, 상술한 NDN에서의 인터레스트 패킷과는 구분될 수 있다. 이때, PIT 테이블에 등록되는 Int(R)과 Int(R/F/A/CLS)의 인커밍 페이스는 로컬 IRA로 연결되는 페이스 face-IRA로 설정되어 나중에 이에 대한 데이터 패킷이 수신되면 IRA로 전달될 수 있다. 그 후, INP Router #2 (IR#2, 720)에서는 Int(R/F/A), Int(R) 및 Int(R/F/A/CLS) 등 3종류의 인터레스트 패킷이 수신될 수 있다. 이때, 이들 모두는 IF에 의해 필터링되어 IRA로 전달될 수 있다. 이때, IR#2(720)의 ILR은 상술한 바와 같이, 제한 조건과 가용 자원량을 바탕으로 로컬 노드에서 INP 실행을 지원할 수 있는지 여부를 체크할 수 있다. 이때, INP 실행이 불가능하면 Int(R/F/A)를 다음 노드로 바이패스 시키고 과정을 종료할 수 있다. 반면, IR#2(720)에서 INP 실행이 가능하면 ILR은 Int(R/F/A/CLS)에 대한 응답으로 데이터 패킷 D(R/F/A/CLS)를 보내 IR#2(720)에서 INP 실행 위치 결정 과정을 종료할 수 있다. 따라서, IR#1(710)이 D(R/F/A/CLS)를 수신하는 경우, IR#1(710)은 상술한 패킷을 PIT에 의해 IRA로 전달할 수 있다. 이때, IR#2(720)에서 INP 실행 위치 결정 과정이 종료될 수 있는바, IRA는 기존에 EE 제공자에서 등록된 실행 환경 생성 준비 엔트리를 삭제한 후 INP 실행 위치 결정 과정을 종료할 수 있다.

한편, IR#2(720)에서 다음 노드가 더 적절한 노드인지를 알아보기 위해 수신된 Int(R/F/A) 패킷을 그대로 다음 노드로 포워딩함과 동시에 Int(R)과 Int(R/F/A/CLR)을 생성하여 다음 노드로 포워딩할 수 있다. 이때, 상술한 바와 같이, Int(R)에 사용되는 네임 R은 NDN의 네임 타입과 구별되는 별도의 TLV 타입 넘버를 사용하기 때문에 일반 NDN에서의 인터레스트 패킷과는 쉽게 구분할 수 있으며, 이는 상술한 바와 같다. 즉, 캐스캐이딩 방식으로 INP 실행 위치가 결정될 수 있다.

반면, IR#1(710)에 데이터 패킷 D(R)가 수신되면 이 패킷 역시 PIT에 IRA로 전달되고 EE 제공자에 등록된 트리거링 이벤트에 매칭되어 실행 환경 생성 “G 함수 실행이 시작될 수 있다. 즉, IR#2(720)에서 데이터 패킷 D(R)이 IR#1(710)로 전송되는 경우라면 IR#1(710)에서 등록된 트리거링 이벤트에 기초하여 실행 환경 생성 및 함수 실행을 시작할 수 있다.

이때, EE 제공자에서 의해 특정 INP 인터레스트에 대한 INP 실행 환경 생성이 트리거링 되면, EE 제공자는 사전에 예약된 컴퓨팅 서버를 선택하여 해당 서버의 ISA에 실행 환경 생성 및 함수 실행을 요청할 수 있다. 그 후, 실행 환경이 생성되고, 함수가 실행될 수 있다. 이때, 함수의 러닝 인스턴스는 필요한 데이터를 전달 받아 연산을 수행한 후 그 결과를 유저에게 전달할 수 있다.

상술한 바를 통해 데이터 프로세싱을 네트워크에 위탁하는 INP 처리에 있어 중앙집중식 서버의 도움 없이 유저 정책을 반영하여 네트워크 내에서 최적의 실행 위치를 결정할 수 있다. 이를 통해, 유저 맞춤형으로 INP 실행 위치를 결정할 수 있으며 네트워크 효율성을 향상 시킬 수 있다. 또한 개별 함수의 요구 사항을 지원할 수 있는 실행 노드를 선택함으로서 개별 함수에 최적의 실행 환경을 제공할 수 있으며, 상술한 실시예로 한정되지 않는다.

또한, 상술한 바에서 INP가 실행됨은 해당 라우터(또는 노드)에서 데이터 발행자로부터 데이터를 전달받아 데이터를 처리 후 유저에게 전달함을 의미할 수 있다. 이때, INP가 실행되는 경우, 해당 라우터는 연결된 서버로 실행환경의 생성을 요청하고 해당 서버는 실행 환경을 생성하고 요청된 함수를 실행시켜 함수의 실행 인스턴스(running instance)를 생성할 수 있다. 그 후, 해당 라우터는 생성된 함수의 실행 인스턴스로 함수 처리에 필요한 데이터를 데이터 발행자로부터 전달받아 데이터 처리를 수행한 후 그 결과를 유저에게 전달할 수 있음을 의미할 수 있다. 즉, 상술한 동작을 결정하는 라우터(또는 노드)를 결정하는 방법일 수 있다.

도 8은 본 발명에 따라 각 노드의 구성을 나타낸 도면이다.

상술한 바와 같이, 인-네트워크 시스템에서 복수 개의 노드(또는 라우터)들이 존재할 수 있다. 이때, 인-네트워크 시스템에서 유저로부터 수신한 데이터를 처리하기 위해 INP 실행 위치를 결정할 수 있다. 즉, 인-네트워크에서 INP 실행을 위한 노드를 결정할 수 있다.

이때, 일 예로, 도 8의 장치 구성은 인-네트워크 시스템에서 노드(또는 라우터)에 대한 구성일 수 있다.

일 예로, 각각의 노(800)들은 도 8와 같이, 메모리(810), 프로세서(820) 및 송수신부(830) 중 적어도 어느 하나를 더 포함할 수 있다. 이때, 일 예로, 메모리(810)는 상술한 유저 정책 정보나 제한 조건 정보 등을 저장할 수 있다. 또한, 메모리(810)는 그 밖에 관련 정보들을 저장할 수 있으며, 상술한 실시예로 한정되지 않는다. 또한, 송수신부(830)는 INP 인터레스트 패킷을 전송하거나 INP가 실행된 데이터를 전송할 수 있다. 즉, 송수신부(830)는 데이터나 정보를 송수신하기 위한 구성일 수 있으며, 상술한 실시예로 한정되지 않는다.

또한, 프로세서(820)는 상술한 바에 기초하여 메모리(810)에 포함된 정보들을 제어할 수 있다. 또한, 프로세서(820)는 송수신부(1530)를 통해 인-네트워크 시스템과 관련된 정보를 다른 노드 또는 장치로 전송할 수 있으며, 상술한 실시예로 한정되지 않는다.

본 개시에 따른 방법을 구현하기 위해서, 예시하는 단계에 추가적으로 다른 단계를 포함하거나, 일부의 단계를 제외하고 나머지 단계를 포함하거나, 또는 일부의 단계를 제외하고 추가적인 다른 단계를 포함할 수도 있다.

본 개시의 다양한 실시 예는 모든 가능한 조합을 나열한 것이 아니고 본 개시의 대표적인 양상을 설명하기 위한 것이며, 다양한 실시 예에서 설명하는 사항들은 독립적으로 적용되거나 또는 둘 이상의 조합으로 적용될 수도 있다.

또한, 본 개시의 다양한 실시 예는 하드웨어, 펌웨어(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)를 포함한다.

810 : 메모리
820 : 프로세서
830 : 송수신부

Claims (20)

1. 네임 기반 인-네트워크 시스템에서 데이터 처리를 위해 INP(In-Network Processing) 실행 위치를 결정하는 방법에 있어서,
   제 1 라우터가 INP 인터레스트 패킷을 수신하는 단계;
   상기 제 1 라우터가 상기 INP 인터레스트 패킷에 포함된 유저 정책 정보 및 제한 조건 정보에 기초하여 상기 제 1 라우터에서 상기 INP를 실행할지 여부를 결정하는 단계;
   상기 제 1 라우터가 상기 INP를 실행할 수 있는 경우, 상기 제 1 라우터는 실행 환경을 생성하여 함수를 실행하고,
   상기 제 1 라우터가 상기 INP를 실행할 수 없는 경우, 상기 제 1 라우터는 상기 INP 인터레스트 패킷을 제 2 라우터로 전달하는 단계;를 포함하되,
   상기 유저 정책 정보는 데이터 인접 위치 선호 정책(NEAR DATA), 클라이언트 인접 위치 선호 정책(NEAR_CLIENT) 및 인프라 위임 정책(ANY) 중 적어도 어느 하나로 설정되는, INP 실행 위치 결정 방법.
   
2. 제 1 항에 있어서,
   상기 INP 인터레스트 패킷에는 라우팅 네임(Routing name), 함수 네임(Function name) 및 함수 아규먼트 네임(Function Argument name)이 포함되는, INP 실행 위치 결정 방법.
   
3. 제 2 항에 있어서,
   상기 라우팅 네임은 상기 INP 인터레스트 패킷의 라우팅 방향을 지시하고,
   상기 함수 네임 및 상기 함수 아규먼트 네임은 상기 INP가 실행되는 경우에 상기 실행 환경이 생성되어 상기 함수가 실행되는 과정에서 이용되는, INP 실행 위치 결정 방법.
   
4. 삭제
5. 제 1 항에 있어서,
   상기 유저 정책 정보가 상기 클라이언트 인접 위치 선호 정책인 경우, 상기 INP 실행 위치는 상기 제한 조건 정보를 만족하는 라우터 중 상기 유저와 가장 가까운 라우터로 결정되는, INP 실행 위치 결정 방법.
   
6. 제 1 항에 있어서,
   상기 유저 정책 정보가 상기 데이터 인접 위치 선호 정책인 경우, 상기 INP 실행 위치는 상기 제한 조건 정보를 만족하는 라우터 중 데이터와 가장 인접한 라우터로 결정되는, INP 실행 위치 결정 방법.
   
7. 제 6 항에 있어서,
   상기 유저 정책 정보가 상기 데이터 인접 위치 선호 정책이고, 상기 제한 조건 정보가 만족하는 경우, 상기 제 1 라우터는 상기 INP 인터레스트 패킷을 수신하면 상기 제 1 라우터가 최종 라우터인지 여부를 확인하는, INP 실행 위치 결정 방법.
   
8. 제 7 항에 있어서,
   상기 제 1 라우터가 상기 최종 라우터인지 여부를 확인하는 경우, 상기 제 1 라우터는 상기 제 2 라우터로 상기 수신한 INP 인터레스트 패킷, 상기 제 1 라우터가 생성한 제 1 패킷 및 상기 제 1 라우터가 생성한 제 2 패킷을 상기 제 2 라우터로 전송하는, INP 실행 위치 결정 방법.
   
9. 제 8 항에 있어서,
   상기 제 1 라우터가 상기 제 2 라우터로부터 상기 제 1 패킷에 대한 응답 패킷을 수신하는 경우, 상기 제 1 라우터는 최종 라우터로 결정되는, INP 실행 위치 결정 방법.
   
10. 제 8 항에 있어서,
    상기 제 1 라우터가 상기 제 2 라우터로부터 상기 제 2 패킷에 대한 응답 패킷을 수신하는 경우, 상기 제 2 라우터에서 상기 제 2 라우터가 최종 라우터인지 여부가 결정되는, INP 실행 위치 결정 방법.
    
11. 제 8 항에 있어서,
    제 1 패킷은 Int(R)이고, 제 2 패킷은 Int(R/F/A/CLS)인, INP 실행 위치 결정 방법.
    
12. 제 1 항에 있어서,
    상기 제한 조건 정보는 상기 함수를 실행하기 위한 상기 실행 환경에 대한 조건 정보를 지시하는, INP 실행 위치 결정 방법.
    
13. 제 1 항에 있어서,
    상기 제 2 라우터는 상기 제 1 라우터의 다음 라우터인, INP 실행 위치 결정 방법.
    
14. 네임 기반 인-네트워크 시스템에서 데이터 처리를 위해 INP(In-Network Processing) 실행 위치를 결정하는 라우터에 있어서,
    정보를 송수신하는 송수신부;
    상기 송수신부를 제어하는 프로세서를 포함하되,
    상기 프로세서는,
    상기 송수신부를 통해 INP 인터레스트 패킷을 수신하고,
    상기 INP 인터레스트 패킷에 포함된 유저 정책 정보 및 제한 조건 정보에 기초하여 상기 라우터에서 상기 INP를 실행할지 여부를 결정하고,
    상기 라우터가 상기 INP를 실행할 수 있는 경우, 상기 프로세서는 실행 환경을 생성하여 함수를 실행하고,
    상기 라우터가 상기 INP를 실행할 수 없는 경우, 상기 프로세서는 상기 INP 인터레스트 패킷을 다른 라우터로 전달하되,
    상기 유저 정책 정보는 데이터 인접 위치 선호 정책(NEAR DATA), 클라이언트 인접 위치 선호 정책(NEAR_CLIENT) 및 인프라 위임 정책(ANY) 중 적어도 어느 하나로 설정되는, INP 실행 위치를 결정하는 라우터.
    
15. 제 14 항에 있어서,
    상기 INP 인터레스트 패킷에는 라우팅 네임(Routing name), 함수 네임(Function name) 및 함수 아규먼트 네임(Function Argument name)이 포함되는, INP 실행 위치를 결정하는 라우터.
    
16. 제 15 항에 있어서,
    상기 라우팅 네임은 상기 INP 인터레스트 패킷의 라우팅 방향을 지시하고,
    상기 함수 네임 및 상기 함수 아규먼트 네임은 상기 INP가 실행되는 경우에 상기 실행 환경이 생성되어 상기 함수가 실행되는 과정에서 이용되는, INP 실행 위치를 결정하는 라우터.
    
17. 삭제
18. 제 14 항에 있어서,
    상기 제한 조건 정보는 상기 함수를 실행하기 위한 상기 실행 환경에 대한 조건 정보를 지시하는, INP 실행 위치를 결정하는 라우터.
    
19. 제 14 항에 있어서,
    상기 프로세서가 상기 INP 인터레스트 패킷을 전달하는 상기 다른 라우터는 상기 라우터와 연결된 다음 라우터인, INP 실행 위치를 결정하는 라우터.
    
20. 네임 기반 인-네트워크 시스템에서 데이터 처리를 위해 INP(In-Network Processing) 실행 위치를 결정하는 시스템에 있어서,
    상기 시스템은 복수 개의 라우터를 포함하고,
    상기 시스템은 유저로부터 수신한 데이터를 처리하되,
    상기 시스템이 상기 데이터 처리를 위해 INP 실행 위치를 결정하는 경우, 상기 복수 개의 라우터 중 제 1 라우터가 INP 인터레스트 패킷을 수신하고,
    상기 제 1 라우터가 상기 INP 인터레스트 패킷에 포함된 유저 정책 정보 및 제한 조건 정보에 기초하여 상기 제 1 라우터에서 상기 INP를 실행할지 여부를 결정하고,
    상기 제 1 라우터가 상기 INP를 실행할 수 있는 경우, 상기 제 1 라우터는 실행 환경을 생성하여 함수를 실행하고,
    상기 제 1 라우터가 상기 INP를 실행할 수 없는 경우, 상기 제 1 라우터는 상기 INP 인터레스트 패킷을 제 2 라우터로 전달하되,
    상기 유저 정책 정보는 데이터 인접 위치 선호 정책(NEAR DATA), 클라이언트 인접 위치 선호 정책(NEAR_CLIENT) 및 인프라 위임 정책(ANY) 중 적어도 어느 하나로 설정되는, INP 실행 위치를 결정하는 시스템.

Images