layout: post
title: "NDN - Tutorial"
categories:

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

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

저작자표시 비영리 변경금지

'Data Centric Network > NDN' 카테고리의 다른 글

A Brief Introduction to Named Data Networking (0)	2020.10.23
unikernel (0)	2019.12.17

NDN Tutorial

NDN Tutorial

1. How NDN works

1.1 An example scenario: smart homes

1.2 Data Packet

1.3 Interest Packets

1.4 Basic communication

1.5 It's all about names

1.6 The role of names

1.7 Name Discovery

1.8 Data-centric security

1.9 Authentication of NDN Data

1.10 Name-based trust relationship and policy

1.11 Trust Schema: Name-Based Definition of Trust Model

1.12 Trust Schema as a Bag of Bits

1.13 From a single node’s point of view

1.14 Forwarding Table (FIB)

1.15 Building FIB

1.16 Content Store (CS)

1.17 Pending Interest Table (PIT)

1.18 Benefits of PIT

1.19 Forwarding Strategy

1.20 Summary of how NDN works

2. Open Research Problems

2.1 NDN Research

2.2 Applications

2.3 Namespace Design

2.4 Application APIs

2.5 Usable Security

2.6 Research problems & approaches

2.7 Data Access Control

2.8 DDoS and Content Poisoning

2.9 Infrastructure-less environments

2.10 Forwarding Strategy

2.11 Sync

2.12 Congestion Control

2.13 Routing, Forwarding, and Caching

2.14 Scalable forwarding engine

3. What we have been doing

3.1 Application-driven architecture development

3.2 Protocol and Mechanism Design

3.3 Running Code and Evaluation Platforms

3.4 Research Community

4. For more information

'Data Centric Network > NDN' 카테고리의 다른 글

'Data Centric Network/NDN' Related Articles

티스토리툴바