A Brief Introduction to Named Data Networking

---

layout: post
title: "A Brief Introduction to Named Data Networking"
categories:

• NDN
  tags:
• NDN
  lang: ko
  author: "uni2u"
  meta: "Springfield"

---

Abstract

Named Data Networking (이하: NDN) 은 데이터 name 을 통해 컴퓨팅 디바이스를 네트워크화 하도록 설계되었다. 이러한 NDN 의 변화는 built-in multicast, in-network caching, multi-path forwarding, securing data directly 을 포함하고 있다. NDN 은 현재의 TCP/IP 아키텍처로 달성하기 어려운 간헐적 연결 환경인 모바일 ad-hoc 에서도 탄력적인 통신을 가능하게 한다.

모든 네트워크의 목적은 데이터의 전송이다. 이 데이터 전달 방식을 정의하는 것이 네트워크 아키텍처의 역할이다. 네트워크 아키텍처 설계는 다음과 같은 두 가지 기본적인 결정이 필요하다.

• 데이터 전송에 사용되는 namespace
• 전달을 위한 구체적 메커니즘

데이터 전송에 사용되는 namespace 설계 결정에는 두 가지 주요 옵션이 있다.

• naming location: 데이터를 전달할 위치
• naming bits: 데이터 자체

현재 TCP/IP 아키텍처는 네트워크 namespace 설계의 첫번째 옵션인 location naming 과 회선 교환 네트워크가 사용하는 통신 모델을 선택했다.

NDN 은 naming bits 라는 네트워크 namespace 설계의 두번째 옵션을 선택했다. NDN 은 데이터에 name 을 설정하는 것으로 IoT 센서에서 클라우드 서버에 이르는 장치들을 네트워킹하도록 설계되어 있다.

[Fig1] Comparing IP and NDN protocol hourglasses

NDN 에서 데이터 검색을 위한 프로토콜에는 두 가지 유형의 패킷이 있다.

• Interest Packet
• Data Packet

두 패킷 유형 모두 데이터 name 을 전송한다. 두 패킷 모두 요청자에 대한 주소나 정보를 포함하지 않는다.

[Fig2] In an NDN network, a Interest packet can fetch one Data Packet back from either the original data producer, or a router cache, or from a dedicated data repository

현재 대부분 인터넷 애플리케이션은 name 으로 콘텐츠를 요청하는 웹 프로토콜에 구축되어 있으며 NDN 은 request-reply 통신 모델을 채택하고 네트워크 계층의 애플리케이션 데이터 name 을 직접 사용하여 네트워크 서비스가 애플리케이션 통신 패턴에 가장 잘 부합하도록 한다. 그러나 애플리케이션에서만 사용되는 HTTP 요청에 사용되는 URL 과 대조적으로 NDN 데이터 name 또한 데이터를 가져오기 위해 네트워크 계층에 사용된다.

애플리케이션 프로토콜로서 HTTP 와 네트워크 계층 프로토콜로서 NDN 의 중요한 차이점은 각각의 책임소재이다. 1) HTTP 는 전송 연결을 통해 실행된다. (예: 요청자와 데이터 소스간 패킷을 안정적으로 전달하는 TCP 또는 QUIC). 따라서 웹 애플리케이션은 요청을 전송하고 요청에 대한 응답 (또는 연결 오류) 을 기다리면 된다. 2) NDN 은 로컬 범위의 IoT 네트워크, 모바일 기기로 만들어진 ad-hoc 네트워크 또는 인터넷을 통해 패킷을 전달하므로 NDN Interest 패킷은 요청된 데이터를 가져오기 위해서 여러 hop 을 이동할 수 있으며, 요청자가 전송한 Interest 에 대하여 데이터 패킷으로 응답한다.

네트워크 계층에 대한 위 차이점 외에도, NDN 데이터 패킷은 다른 두 측면에서 HTTP 데이터 객체와 다르다.

첫째, HTTP 응답 메시지가 기본 TCP 연결에 의해 요청 URL 에 암묵적으로 바인딩 되지만, 모든 NDN 데이터 패킷은 요청된 콘텐츠 외에 데이터 name 을 명시적으로 전송하고, 데이터 생성시 그 name 을 암화화하여 콘텐츠에 바인딩하는 서명을 사용한다; 콘텐츠는 필요시 암호화할 수 있다.

둘째, HTTP 는 동일한 URL 이 다른 콘텐츠를 검색할 수 있지만, NDN 데이터 패킷은 불변이다. 각 name 은 NDN 데이터 패킷을 고유하게 식별한다. 생산자가 데이터 패킷의 콘텐츠를 변경하면 콘텐츠의 버전이 적용된 새로운 name 의 패킷을 생성하여야 한다.

HOURGLASS-SHAPED NDN PROTOCOL STACK

기존 TCP/IP 네트워크와 NDN 네트워크의 가장 두드러진 유사성은 두 네트워크 모델 모두 모래시계 형태를 유지한다는 것이다. IP 와 마찬가지로, NDN 네트워크 프로토콜은 데이터그램 전달을 수행하고 데이터그램을 전달할 수 있는 전송 매체를 통해 실행된다. 미디어에는 TCP/UDP/IP 터널뿐만 아니라 인근 장치를 상호 연결하는데 가장 자주 사용되는 layer2 프로토콜이 포함될 수 있다. (현재 NDN 은 이것을 사용하여 상호 원격으로 NDN 지원 장치를 연결한다).

유사한 구조에도 불구하고, [Fig1] 은 소스와 목적지 주소를 기반으로 하는 IP 와 데이터 청크를 기반으로 하는 named, secured NDN 의 차이를 보여준다. 이러한 단순한 개념적 변화는 NDN 과 IP 사이의 심각한 차이로 이어진다:

• NDN 네트워크 계층에는 주소가 없다; 애플리케이션이 정의한 namespace 사용
• 따라서 NDN 은 데이터 위치 대신 데이터 name 사용
• NDN 에서 소비자들은 sender 가 패킷을 목적지로 보내는 대신 데이터를 가짐

[Fig3] Forwarding Process at an NDN Node: upstream indicates the direction of data producer and downstream is to data consumer

NDN AS A FORWARDING ENGINE

기본적으로 Interest 패킷은 요청된 데이터의 name 만 전송하며 요청자에 대한 정보는 포함하지 않는다. 각 NDN forwarder 는 이 Interest 를 전달할 인터페이스를 결정하기 위해 Interest 의 name 을 사용한다.

A. Stateful Forwarding Plane

[Fig3] 과 같이 각 NDN 노드의 forwarding 모듈에는 다음과 같은 세가지 기본 구성 요소가 포함되어 있다.

• Content Store (CS)
• Pending Interest Table (PIT)
• 라우팅 프로토콜 또는 자체 학습과 같은 다른 방법으로 채워지는 Forwarding Information Base (FIB) 를 포함하는 Forwarding Strategy

Interest IN 을 수신하면 forwarder 가 먼저 CS 를 점검한 후 PIT: CS 에서 일치하는 데이터가 발견되면 반환된다. (CS 에 일치하는 데이터가 없으면) PIT 항목이 발견되면 IN 의 수신 인터페이스가 PIT 에 추가된다. CS 나 PIT 에 일치하는 것이 없는 경우, forwarder 는 타임스탬프와 함께 PIT 에 IN 의 들어오고 나가는 인터페이스를 기록하면, Forwarding Strategy 는 FIB 와 관측된 성능에 기초하여 출력 인터페이스를 결정한다.

Interest 가 name 이 일치하는 데이터 패킷 D 가 있는 노드에 도달하면 D 는 모든 요청자에게 도달하기 위해 Interest 의 역방향 경로 (hop-by-hop) 를 통해 전달된다. 또한 D 는 동일한 데이터에 대한 향후 요청을 처리하기 위해 각 hop 의 CS 에 캐시될 수 있다. Interest-Data 교환은 각 hop 마다 폐쇄 피드백 루프를 생성하여 각 forwarder 가 데이터 검색 성능을 측정하고, hop-by-hop NACK 을 통한 forwarding 문제를 보고하며, 효과적인 정체 제어를 수행할 수 있도록 한다.

데이터 성능 측정을 위해 세 가지를 관찰한다.

첫째, NDN 은 데이터그램 전달을 위한 stateful forwarding plane 을 가지고 있다: 상태는 per-packet, per-hop 이다.

둘째, 대역폭 시간 라운드 트립 지연에 비례하여 크기가 조정되는 stateful forwarding plane 은 잠재적으로 NDN 라우터의 메모리에 높은 수요를 줄 수 있다.

마지막으로, NDN forwarder 는 Interest (PIT) 와 데이터 (CS) 를 모두 버퍼링 할 수 있는데, 이는 NDN 이 불리한 환경에서 간헐적 연결을 통해 기본적으로 통신할 수 있게 하는 고유 기능이다.

B. Routing in NDN Networks

NDN 네트워크는 라우팅 프로토콜을 실행하여 데이터 name 의 도달 가능성을 전파한다. 이것은 IP 주소의 도달 가능성을 전파하기 위해 라우팅 프로토콜을 실행하는 IP 네트워크와 유사하다. 그러나 IP 및 NDN 네트워크의 라우팅에는 몇가지 차이점이 있다.

첫째, NDN 라우팅 프로토콜은 NDN 애플리케이션이며 라우팅 업데이트는 name 이 지정되고 보안이 설정된 NDN 데이터 패킷이다. 따라서 NDN 라우팅 보안은 기본적으로 내장되어 있지만 보안에 대한 연구는 매우 부족하다.

둘째, NDN 은 각 FIB 항목이 Interest 루프에 대한 문제를 해소하기 위하여 multiple next hop 을 가질 수 있도록 multi-path forwarding 을 지원한다. IP 는 패킷 루핑에 대한 문제를 해소하기 위하여 next hop 이 하나만 존재한다.

셋째, 작은 크기의 NDN 네트워크는 라우팅 프로토콜을 실행하지 않을 수 있지만, self-learning 을 사용하여 데이터 가용성을 찾을 수 있다.

마지막으로, NDN stateful forwarding plane 은 FIB 가 forwarding 결정의 유일한 입력요소는 아니기 때문에 라우팅 프로토콜의 요구 사항과 중요성을 근본적으로 변경한다.

C. The Power of Using Names for Network Communication

인터넷은 개념적으로 간단한 작업을 수행함으로써 많은 삷을 변화시킨 다양한 애플리케이션을 가능하게 했다. 모든 호스트에서 다른 호스트로 IP 패킷을 전송한다. 라우팅과 포워딩은 이를 위한 네트워크 계층의 기본 전력을 제공한다. 이는 글로벌 규모로 한 호스트에서 다른 호스트로 이동하는 방법을 결정한다.

NDN 은 데이터를 naming 하고 name 에 대한 routing/forwarding 을 수행함으로 힘을 확대한다. 현재 휴대폰의 앱이 원하는 데이터를 얻으려면, 먼저 데이터 요청을 보낼 대상 IP 를 알아내야 한다. 이것은 사소한 작업이다. 앱은 의미있는 name 을 사용하며 주소 및 네트워크 토폴로지에 대해 전혀 알지 못한다. 오늘날 휴대폰이 DNS 를 조회하여 클라우드 서버의 주소를 찾고, 이웃의 스토리지 서버 (예: synology box) 가 파티에서 찍은 모든 사진을 호스팅할 수 있는 경우에도 클라우드가 앱의 요구를 처리하도록 한다.

NDN 을 사용하면 이웃의 스토리지 서버에 수집된 콘텐츠 (사진) 의 name 을 로컬로 알릴 수 있다. NDN 은 적절한 name 의 데이터를 제공하기 때문에 유선, 스토리지 또는 처리 차이를 알 수 없다. 라우팅 확장성을 적절하게 처리함으로써 동일한 기능이 큰 규모로 확장된다. NDN 은 네트워킹, 스토리지 및 처리를 하나의 통합 시스템으로 합친다.

D. Communication Security

암호, 보안 프로토콜 및 시스템 수준의 방어 기술의 진보에도 불구하고 보안은 현재까지 가장 큰 난제로 남아있다. NDN 은 이러한 과제를 근본적으로 다른 방식으로 해결한다. NDN 은 데이터 생산자가 각 데이터 패킷에 암호화 방식으로 서명하여 데이터 name, 생산자 및 콘텐츠를 함께 바인딩 하는 것으로 데이터를 직접보호한다. 데이터 기밀성이 필요할 때마다 데이터를 암화화 할 수 있다.

E. The Need For DATASET Synchronization

NDN Sync 또는 Sync 의 개념은 NDN 애플리케이션 개발에서 관찰된 공통의 필요성, 즉 다중성과 비동기적인 데이터 집합 동기화에서 비롯되었다. 이는 TCP 의 일반화로 볼 수 있다. TCP 와 달리 Sync 는 애플리케이션 생성 패킷 앞에 헤더를 추가하지 않고, 애플리케이션 데이터 전송 요구를 지원하기 위해 시스템 라이브러리에 구현된다.

---

• Reference Link：
  • https://named-data.net/wp-content/uploads/2019/01/NDN18.pdf