NDN Tutorial

1. How NDN works

1.1 An example scenario: smart homes

  • 온도, 카메라, 조명 등 조절
  • IP solution
    • 정보를 얻기 위한 주소(address)를 알아야 함
      • 온도 조절기, 카메라, 홈 컨트롤러
    • 특정 주소로 request 를 보냄
  • NDN solution
    • 대상을 지정하지 않고 명시적으로 데이터 요청을 보냄

1.2 Data Packet

  • NDN 아키텍처의 가장 핵심적인 구성 요소
+------------------+  콘텐츠를 고유하게 식별
|       NAME       |  eq) /UCLA/BH234/temperature/timestamp
|                  |
+------------------+  info to help common data consumtion
|     MetaInfo     |  eq) FreshnessPeriod
|                  |
+------------------+
|     Content      |  Can be anything
|                  |
+------------------+
|    Signature     |  Signed by the data producer
|                  |
+------------------+
  • 데이터는 변경 불가능한 객체
    • 내용이 변경되면 서명뿐만 아니라 이름도 변경되어야 함

1.3 Interest Packets

  • 데이터를 검색하기 위해 interest 전송
+----------------------+  interest에 대한 data는 무엇인가
|         NAME         |  eq) /UCLA/BH234/temperature
|                      |
+----------------------+  데이터 선택 범위를 좁힘
| Selectors (optional) |  (narrow down data selection)
|                      |
+----------------------+  동일한 name을 가진
|        Nance         |  interest를 구별하는 난수
|                      |
+----------------------+
|InterestLifeTime, etc.|
|      (optional)      |
+----------------------+

1.4 Basic communication

  • 소비자(Consumer)는 데이터(Data)를 Pull
    • one interest for one data packet
    • interest 와 data name은 반드시 match
    • 속도 제어, 데이터 검증, 손실 탐지 및 복구, 다른 네트워크 인터페이스 탐색 등
  • 데이터(Data) 생산자(production)
    • Naming
    • Signing
    • 필요한 경우 Segmentation

1.5 It’s all about names

  • Data 와 Interest는 name을 가지고 있음 (no address; no port)
    • Name이 모든 차이점을 만든다: benefits & challenges.
  • Name은 application 별로 각 패킷에 할당, eq)
    • /UCLA/RoyceHall/ARFeed/FrontView/mp4/_frame=12/_chunk=20
  • Name은 계층적(hierarchical) 구성
    • name aggregation이 용이함
    • 데이터 소비를 위한 application 컨텍스트 보존 (eq: security)
  • 충돌을 피하고 communication을 원활하게하기 위한 Naming 규칙

1.6 The role of names

  • Name은 여러 레이어에서 디멀티플렉서로 사용
    • 각 레이어가 자체 식별자 (eq: address, port), 관리 및 상호 간의 식별자를 가질 필요가 없음
    • 다중 인터페이스 및 이동성의 경우 특정 주소 또는 포트에 바인딩되지 않음
  • Auto-configuration 및 auto-discovery
    • /_ThisRoom/Projector/command/TurnOn/…
  • Naming은 application 프로토콜 설계의 주요 부분
    • Naming 규칙을 알고 나면 모든 application에서 이 규칙을 사용하여 프로젝터에 액세스

1.7 Name Discovery

  • 소비자 application은 data name에 대해 어떻게 알 수 있는가?
    • 일반적으로 name prefix는 알고 있지만 완전한 name을 아는 것이 아님
  • In-network name discovery
    • 선택자(Selection)를 사용하여 선택 범위를 좁힐 수도 있음
+-------------+ /UCLA/BH234/temp                     +-------------+
|             | -----------------------------------> |             |
| application | /UCLA/BH234/temp/2017082109/_chunk=0 |   producer  |
|             | <----------------------------------- |             |
|             | /UCLA/BH234/temp/2017082109/_chunk=1 |             |
+-------------+ -----------------------------------> +-------------+
  • 특정 시나리오에 대한 기타 검색 메커니즘
    • eq) 관련 데이터의 알려진 name을 나열된 Manifest

1.8 Data-centric security

  • internet 환경에서 connection 보안을 아무리 설정하여도 서버 해킹의 위험성이 남아있음
  • NDN에서 생산자는 데이터에 서명하여 소비자가 불량 데이터를 얻는 시점을 알 수 있음

1.9 Authentication of NDN Data

+---------------------+
| /UCLA/RoyceHall/... |
| <data>              |
|                     |
| +----------------------------+
| |KeyLocator:                 |
| |/UCLA/RoyceHall/Manager/KEY |
| +----------------------------+
+---------------------+
    |
    |
    +--<Signed by>--+
                    |
                    V
   +------------------+
   | /UCLA/RoyceHall/ |
   | Manager/KEY      |
   |                  |
   | +-------------------------+
   | |KeyLocator:              |
   | |/UCLA/Campus/Manager/KEY |
   | +-------------------------+
   +------------------+
  • Key는 Named 데이터이며 다른 데이터와 마찬가지로 검색되고 보호

1.10 Name-based trust relationship and policy

+--------------------------------+
| /UCLA/Campus/Manager/Key       |
+---------------^----------------+
                |
                | valid if signed by
                |
+--------------------------------+
| /UCLA/RoyceHall/Manager/Key    |
+---------------^----------------+
                |
                | valid if signed by
                |
+--------------------------------+
| /UCLA/RoyceHall/CameraFeed/... |
+--------------------------------+
  • 데이터가 유효하려면 특정 키로 서명
  • 체인은 application의 신뢰 앵커로 연결

1.11 Trust Schema: Name-Based Definition of Trust Model

  • 데이터의 이름과 서명 키의 이름 사이의 관계를 체계화하여 신뢰 모델 구성

<> <CONST> token* token? [func] (:group:token)

       +-----------------------+
       | Local trust anchor(s) |
       +-----------------------+
                   |    
                   V    +-----+
             +-----------+    |
             | Key1 Rule | <--+
             +-----------+
               |       |
         +-----+       +-----+
         |                   |
         V                   V
   +-----------+       +-----------+
   | Key2 Rule | <---- | Key3 Rule |
   +-----------+       +-----------+
         |                   |
         V                   V
+---------------+     +---------------+
| Interest Rule |     |   Data Rule   |
+---------------+     +---------------+

1.12 Trust Schema as a Bag of Bits

  • 기본 NDN 메커니즘을 사용하여 배포
  • 다른 모든 데이터 패킷도 보안
  • 신뢰 스키마 데이터 성능
    • 휴대 전화는 수신 비디오 피드 데이터를 안정적으로 확인
    • 카메라가 비디오 피드 데이터에 서명
    • 카메라는 휴대 전화에서 command 유효성 검사
    • 라우터는 데이터 유효성 검사하고 요청을 인증

1.13 From a single node’s point of view

Traditional Networks

           +-----------------------------+
           |  Accept                     |
           |    ^                        |
           |    |                        |
           |  +---------+   X   +-----+  |
Packets ----> |  Dest?  | ----> | FIB | ---->
           |  +---------+       +-----+  |
           +-----------------------------+
----------------------------------------------------
NDN Networks

             +-------------------------------+
             |  Return Data                  |
             |        ^                      |
             |        |                      |
             |  +-----------+   X   +-----+  |
Interests ----> | Got Data? | ----> | FIB | ---->
             |  +-----------+       +-----+  |
             +-------------------------------+
             +-------------------------------+
             |   +-----------------------+   |
         <-----  |   Pending Interest?   |  <----- Data
             |   +-----------------------+   |
             +-------------------------------+

1.14 Forwarding Table (FIB)

  • name-prefixes 와 해당하는 next-hops 저장(stored)
    • e.g., /UCLA
  • incoming Interest’s name 과 longest prefix 매치 수행
    • e.g., /UCLA/RoyceHall/…
  • 다른 데이터 소스로 이어질 수 있는 여러 개의 next-hops
    • 특정 목적지가 아닌 데이터를 향해 전달
    • NDN은 루프에 대해 걱정할 필요가 없으므로 더 많은 forwarding

1.15 Building FIB

  • application은 데이터의 name-prefix를 로컬 노드에 등록
  • 전통 라우팅 알고리즘
    • 네트워크에 name-prefix를 어나운스
    • e.g., link state
  • “비 전통적인” 라우팅 알고리즘
    • 기본 NDN 네트워크 활용
    • e.g., Hyperbolic Routing
  • Flooding-based learning
    • Flood initial interest, 데이터 출처 관찰 및 FIB 항목 추가
    • local, ad-hoc 환경에 적합

1.16 Content Store (CS)

  • 모든 노드는 NDN에 의해 데이터 캐시
    • Transparent
    • In-Network
    • On-path
  • 장점
    • ISP의 중복 트래픽 줄임
    • 제작자의 서버 부하 줄임 (특히 공격하는 동안)
    • 소비자의 응답 시간을 줄임
    • RTT의 시간 규모에서도 손실 복구 및 이동성 지원
  • 데이터 생산과 데이터 소비 분리
    • 자연스럽게 DTN 유형의 통신 지원

1.17 Pending Interest Table (PIT)

+---+
| A | <----DATA----+
+---+              |
  |                |
  +--INTEREST--+   |   +--------DATA-------+
               V   |   V                   |
              +-----------+              +---+
              |    PIT    |              |   |
              +-----------+              +---+
               ^   |   |                   ^
  +--INTEREST--+   |   +------INTEREST-----+
  |                |
+---+              |
| B | <----DATA----+
+---+
  • 소비자에게 Data를 보내기 위한 NDN
    • 각 항목 기록 (name, nonce, incoming faces)
    • 새로운 interest가 전송 될 때 생성
    • 동일한 Name을 가진 interest가 더 많이 도착하면 업데이트
    • 일치하는 데이터가 반환되면 삭제

1.18 Benefits of PIT

  • Native multicast
    • 멀티 캐스트와 유니 캐스트 작업간에 차이가 없음
  • 중복 패킷 억제 e.g) forwarding loops로 인해 발생
    • mobile, ad hoc communication에 중요
  • 모든 홉에서 데이터 검색의 success/performance에 대한 closed-loop로 피드백 제공
 +---+               +---+               +---+               +---+
 |   | --INTEREST--> |   | --INTEREST--> |   | --INTEREST--> |   |
 |   |               | R |       X       | R |               |   |
 |   | <----DATA---- |   | <----DATA---- |   | <----DATA---- |   |
 +---+               +---+               +---+               +---+
-------------------------------------------------------------------
 +---+               +---+       X       +---+               +---+
 |   | ---Packet---> |   | ---Packet---> |   | ---Packet---> |   |
 +---+               +---+               +---+               +---+

1.19 Forwarding Strategy

  • FIB는 여러 Forwarding 옵션 제공
  • PIT는 오류 감지 및 성능 피드백을 가능하게함
  • 위의 내용을 토대로 Forwarding Strategies는 데이터 검색에 가장 적합한 전달 결정
    • e.g., 경로 변경을 최소화하거나 최단 지연을 찾거나 높은 처리량을 찾거나 항상 multicast/broadcast 등
                                      +---+
                   +----INTEREST----> | R |
                   |                  +---+
                   |                    |
                 +---+ <------DATA------+
----INTEREST---> | R | 
                 +---+
                   |                  +---+
                   +--X--INTEREST --> | R |
                                      +---+

1.20 Summary of how NDN works

  • 데이터는 Name으로 식별(identified)되고 생산자가 서명(signed)
  • interest는 일치하는 데이터를 검색하기 위해 Name을 포함
  • 데이터 중심 보안 및 Name 기반 신뢰 스키마
  • in-network caching, native multicast, 다목적 forwarding 전략(strategies)을 지원하는 상태 저장(stateful) data-plane

2. Open Research Problems

2.1 NDN Research

  • NDN은 새로운 네트워크 아키텍처
    • 기존의 point-to-point conversation 에서 분산 데이터(distributed data) 생성, 검색(retrieval) 및 소비(consumption)에 이르기까지
  • 내장 보안(built-in security)과 함께 응용 프로그램과 네트워크에 대한 재고(rethinking)가 필요
    • 특정 네트워크 환경에서 NDN 작동?
    • NDN의 기능을 최대한 활용하는 방법?
    • NDN의 성능을 최적화하는 방법?
  • 응용 프로그램, 보안 및 네트워크의 주요 연구 문제

2.2 Applications

  • NDN은 네트워크 의미론(network semantics)을 응용 프로그램 의미론에 가깝게 함
  • 데이터 중심의 앱 디자인이 NDN을 최대한 활용
  • 우리는 응용 프로그램을 작성하여 네트워크 아키텍처 연구를 추진
  • 특히, 분산 컴퓨팅을 위한 현재 cloud-centric 패러다임 (동적 대기 시간이 적은 모바일 앱을 지원하지 못하고 있는) 에 대한 클라우드 지원 대안

2.3 Namespace Design

  • Data Namespace 디자인은 앱 디자인의 핵심 요소
    • 데이터 액세스, 전달, 보안 및 이름에 대한 다른 요구 사항 수집
  • Home IoT 사례
    • Name data, 작동 포인트, 장치, keys/certificates, 액세스 제어 정책
    • 종종 네 부분으로 된 이름: /A/B/C/D
      • A: 데이터 도달 방법 (e.g., localhop, home-guid, /edu/ucla 등)
      • B: 상위 수준 식별자 (e.g., living_room/temperature)
      • C: 파생 또는 관련 데이터 식별자 (e.g., KEY, _mimetype)
      • D: 유형별 접미사(suffixes) (e.g., 세그먼트 또는 일련 번호, 버전 등)
    • 데이터 패킷의 Keylocator: 신뢰와 관련된 또 다른 Name

2.4 Application APIs

  • API 및 앱 개념 변화:
    • 소비자 중심: 데이터 push 보다 pull
    • client/server 가 아닌 비동기 다중 노드 (Asynchronous multi-node) 데이터 보급
    • 로컬 및 글로벌 통신에 동일한 메커니즘 사용
  • Home IoT 사례
    • 기본 프리미티브로 검색(retrieval) 및 활성화(actuation) 가능
    • Discovery & bootstrapping은 기본 프리미티브(basic primitives) + 이름 규칙(name conventions) 을 사용하여 구현할 수도 있음
    • 계층 구조 이름(hierarchical name) 은 다른 계층에서도 공통적
    • Layer3 의 NDN

2.5 Usable Security

  • 앱 데이터 보안은 근본부터 구축 될 수 있지만 접근 방식과 도구는 새롭고 쉽게 사용할 수 있어야 함

  • Home IoT 사례

    • 체계화된 신뢰(schematized trust): 사용하기 쉬운 규칙과 더 많은 예제가 필요함
    • Name-based access control: 많은 옵션으로 이름만으로 개념화하기 어려움

2.6 Research problems & approaches

  • 네트워크가 응용 프로그램에 제공하는 공개 질문
    • Network storage (e.g: repo)
    • Indirection (e.g: NDNS)
    • Handling mobile publishers
  • Home IoT 사례
    • “Memory content cache”는 영구 튜플 저장소로 쉽게 확장
    • Certificate storage, name redirection, could는 인프라에 포함될 수 있음
    • 홈 네트워킹에서 차량 네트워킹에 이르기까지
      • 멀티 홈, 모바일
      • Local, neighborhood, global data

2.7 Data Access Control

  • 데이터 검색(retrieval)과 데이터 액세스 제어 분리
    • 누구든지 검색 할 수 있는 데이터를 암호화
    • 암호 해독 키에 대한 액세스 제어
  • 정확한 메커니즘 설계는 네트워크 환경 (e.g., resource constrained devices) 에 따라 다양한 옵션이 있을 수 있음

2.8 DDoS and Content Poisoning

  • NDN 아키텍처는 IP보다 DDoS 공격에 탄력적
    • 피해자가 기존 데이터에 대한 interest를 가진다면 효과적이지 않음
    • 공격 할 수있는 유일한 방법은 라우팅 가능하지만 존재하지 않는 데이터에 대해 interest flooding 하는 것이지만 PIT 행동에서 탐지
  • Content Poisoning
    • 기본적으로 라우터는 성능상의 이유로 데이터를 확인하지 않음
    • 소비자가 위조 된 데이터를 수신하고 라우터가 데이터를 검색하는 경우 문제가 발생할 수 있음

2.9 Infrastructure-less environments

  • 신뢰할 수 있는 고정 인프라가 없는 네트워크 환경
    • Mobile, ad hoc, wireless device-to-device, delay-tolerant network, 재난 복구 등
  • NDN 장점이 활용될 수 있는 환경
    • 모바일 노드에서 데이터 Fetching vs. chasing 또는 동시에 온라인에 있지 않은 두 노드 사이에 연결을 설정하거나 로컬 통신을 위해 클라우드를 거치는 것 등
  • Research issues
    • Auto-configuration, auto-discovery, device-to-device communication
    • Security models 및 mechanism
    • 이동성(mobility) 기반의 Routing, forwarding strategy 및 동시에 여러 인터페이스 사용

2.10 Forwarding Strategy

  • 데이터 플레인(data-plane)을 스마트하게 만드는 강력한 메커니즘

  • 서로 다른 유형의 데이터, 서로 다른 네트워크에 각각의 전략 적용

  • example
    • large scientific data movement, VR/AR data, IoT data을 위한 각각의 전략
    • vehicular networks, smart homes, sensor networks, delay-tolerant networks, data-center networks 등을 위한 각각의 전략
    • 유연한 전략 구성 지원

2.11 Sync

  • 공유 데이터 세트의 다중 사용자(multi-party) 동기화(synchronization)
    • 각 당사자는 다른 하위 집합(subset)으로 시작할 수 있음
    • 시간이 지남에 따라 데이터 세트가 변경 될 수 있음
    • NDN 전송을 위한 추상화(abstraction)
    • TCP와 같은 안정적인 전송은 특별한 경우
      • 발신자(sender)가 전체 집합을 가지고 수신자(receiver)는 가지고 있지 않음
  • Basic approach
    • 서브셋의 효율적인 표현 및 교환, 데이터를 공유하고 중복을 제거(redundancy)하기 위해 multicast/broadcast를 활용
  • 제안된 다수의 해결책
    • 데이터 naming, 상태 표시(state representation), 변경 알림(change notification) 및 업데이트 검색(update retrieval)이 서로 다름

2.12 Congestion Control

  • NDN을 위한 다른 스토리
    • 단일 기본 RTT와 point-to-point 세션이 더이상 필요하지 않음
    • multipath, multi-source data 전송
    • congestion control을 위해 interest rate 규제
  • 어디에서나 hop-by-hop solutions 필요
    • 경로의 모든 노드 참여
    • 여러 경로(multiple path)와 여러 소스(multiple source)를 사용할 수 있어야 함
    • 전반적인 네트워크 동작에 미치는 영향

2.13 Routing, Forwarding, and Caching

  • NDN에서 Routing, Forwarding, Caching은 모두 관련
    • 예를 들어, 포워딩 결정은 캐시 가용성에 영향을 미치며, 이는 향후 포워딩 결정에 영향이 있음
  • 다른 네트워크 환경에서 이들을 공동으로 최적화
    • 데이터 센터, ISP 네트워크, 모바일 에지 네트워크 등
  • 새로운 라우팅 프로토콜 탐색(Explore new routing protocols)
    • 스마트 데이터 플레인을 사용하여 컨트롤 플레인의 요구 사항 완화
  • Routing Scalability
    • Table size
    • Routing churns

2.14 Scalable forwarding engine

  • 테이블 조회 및 업데이트 (FIB, PIT, CS)
    • Name 길이는 가변적(variable-length)
    • Table 크기가 클 수 있으며 내용(content)이 동적 일 수 있음
    • matching rule은 각 table 마다 다름
  • 많은 연구에서 다양한 데이터 구조를 제안
    • Hash tables, tries, bloom filter
    • 주로 FIB에 중점
    • CS와 PIT에 대한 더 나은 디자인이 필요

3. What we have been doing

3.1 Application-driven architecture development

  • 현재 포커스하고 있는 영역:
    • Mobile edge computing
    • Internet of Things
    • Navigable media
  • 다른 applications
    • Open mHealth (mobile health)
    • 빌딩 자동화 및 관리
    • Scientific “big data” (e.g., climate change)
    • 실시간(real time) 회의
    • Neighborhood solar
    • File sharing, chat, etc.

3.2 Protocol and Mechanism Design

  • 디자인 원칙을 명시하고 패킷 형식 및 프로토콜 사양 개발
  • Routing protocols
  • Forwarding Strategies
  • 테이블 구조 및 알고리즘
  • Name-based authentication, trust, access control
  • Sync protocols
  • Congestion control
  • …

3.3 Running Code and Evaluation Platforms

  • Network forwarder, libraries, tools
  • 기존 플랫폼 및 IoT 장치에서
  • Simulator, emulator, global testbed
  • All code is open sourced

3.4 Research Community

  • NDNCommunication
    • 2017 at Memphis, 73 people from 36 institutions
    • 2015 at UCLA, 116 people from 49 institutions
    • 2014 at UCLA, 87 people from 31 institutions
  • ACM ICN conference and ICN-related workshops
  • IRTF ICN RG
  • Both academia and industry

4. For more information

NDN Communication