재귀적 인터네트워크 아키텍처

Recursive Internetwork Architecture

RINA(Recursive InterNetwork Architecture)는 현재 주류인 인터넷 프로토콜 모음의 아키텍처에 대한 대안으로 제안된 새로운 컴퓨터 네트워크 아키텍처다.RINA의 기본 원칙은 컴퓨터 네트워킹은 단지 프로세스 간 통신이나 IPC일 뿐이며, 계층화는 전문화된 프로토콜로 기능보다는 하나의 반복적인 프로토콜 세트로, 범위/규모에 따라 이루어져야 한다는 것이다.현재 BGP, OSPF, ARP와 같은 프로토콜에 특정된 네트워킹 기능을 효과적으로 재조정하는 새로운 개념과 엔터티를 통해 상위 계층과 하위 계층의 프로토콜 인스턴스들과 하나의 계층 인터페이스의 프로토콜 인스턴스들.이러한 방식으로 RINA는 RTP, UDP와 같은 추가적인 전문 프로토콜 없이도 모빌리티, 멀티호밍, 서비스 품질과 같은 기능을 지원할 뿐만 아니라, 자율 시스템 및 NAT과 같은 개념 없이도 간소화된 네트워크 관리를 가능하게 한다고 주장한다.

배경

RINA 뒤에 숨겨진 원칙은 John Day가 2008년 저서 네트워크 아키텍처의 패턴에서 처음 제시하였다. 기본 지식으로 돌아가기.[1]이 작업은 TCP/IP의 존재 35년 동안 배운 교훈과 더불어 OSI의 실패의 교훈과 CYCYACADES, DECnet, 제록스 네트워크 시스템 등 지난 수십 년간의 다른 네트워크 기술의 교훈을 참작하여 새롭게 출발하는 것이다.

RINA와 같이 근본적으로 새롭고 서로 다른 네트워크 아키텍처의 출발점은 현재의 네트워크 아키텍처, 특히 인터넷 프로토콜 스위트와 그것의 기능적 계층화 등과 함께 실용적이거나 타협이 없는 솔루션을 가지고 있지 않은 것으로 보이는 다음과 같은 문제에 대한 해결 시도 또는 대응이다.

그림 1.TCP/IP 아키텍처의 기능 계층화
  • 전송 복잡성: IP와 TCP의 분리로 인해 비효율성이 발생하며, IP 단편화를 방지하기 위해 수행된 MTU 검색이 가장 명확한 증상이다.
  • 성능: TCP 자체는 핸드셰이크로 다소 높은 오버헤드를 전달하며, SYN 홍수 등의 취약성도 야기한다.또한, TCP는 스스로 조절하고 혼잡을 피하기 위해 패킷 드롭에 의존한다. 즉, 혼잡 통제는 사전 예방적이거나 예방적이지 않고 순전히 반응적이다.이것은 큰 버퍼와 나쁜 상호작용을 해서 완충재로 이어진다.[2]
  • 멀티호밍: IP 주소와 포트 번호가 너무 낮아서 두 개의 서로 다른 네트워크에서 애플리케이션을 식별할 수 없다.호스트 이름은 단일 IP 주소와 포트 번호 조합으로 확인되어야 하므로 DNS가 이 문제를 해결하지 못하며, ID 대신 별칭이 된다.또한 LISP도, i) 라우팅에 IP 주소인 로케이터를 여전히 사용하고, ii) 스코프의 모든 실체가 처음에는 식별자에 의해 위치한다는 점에서 잘못된 구분에 기초하고 있으며,[3] 또한 자체적인 확장성 문제를 도입한다.[4]
  • 이동성: IP 주소와 포트 번호 또한 네트워크 간에 이동할 때 애플리케이션을 식별하기에 너무 낮은 수준으로, 스마트폰과 같은 모바일 장치의 복잡성을 야기한다.해결책이지만, 실제로는 모바일 IP는 문제를 Care-of 주소로 완전히 전환하고 IP 터널을 도입하며, 이에 수반되는 복잡성을 수반한다.
  • 관리: IP 주소의 동일한 낮은 수준의 특성이 여러 주소 또는 심지어 주소 범위를 단일 호스트에 할당하도록 장려하여 할당에 부담을 주고 소진을 가속화한다.[5]NAT은 문제 해결을 지연시키고 잠재적으로 더 많은 문제를 일으킬 수 있음동시에 인터넷 프로토콜 스위트 아키텍처의 기능적 계층화는 두 가지 범위만을 위한 여지를 남겨 인터넷 관리의 세분화를 복잡하게 만들고 자율 시스템의 인위적인 개념을 요구한다.OSPF와 IS-IS는 상대적으로 문제가 적지만 잘 확장되지 않아 더 큰 네트워크와 도메인 간 라우팅에 BGP를 사용할 수밖에 없다.
  • 보안: 물리적으로 첨부파일을 방지하는 것 외에 IP 주소를 추가하거나 제거하기 위한 진정한 구성 가능한 정책이 없기 때문에 IP 주소 공간의 특성 자체가 취약한 보안으로 귀결된다.TLS와 IPSec은 솔루션을 제공하지만 복잡성을 수반한다.방화벽과 블랙리스트는 압도적이고 확장성이 없는 에고에 취약하다."[...] 경험을 통해 처음부터 아키텍처에 구축되지 않는 한 프로토콜 제품군에 보안을 추가하기 어렵다는 것을 알 수 있었다."[6]

오늘날 이러한 문제들이 훨씬 더 예리하게 눈에 띄지만, 인터넷 프로토콜 제품군이 설계되었던 환경인 ARPANET의 시작부터 거의 제대로 된 선례와 사례가 있었다.

1972: ARPANET에서 멀티호밍을 지원하지 않음

1972년 팅커 공군기지는[7] 이중화를 위해 두 개의 다른 IMM에 연결을 원했다.ARPANET 설계자는 호스트 주소가 호스트가 연결된 IMM 포트 번호의 주소(전화에서 대여)이기 때문에 이 기능을 지원할 수 없다는 것을 깨달았다.ARPANET의 경우, 동일한 호스트의 두 인터페이스가 서로 다른 주소를 가지고 있었다. 즉, 주소가 너무 낮아서 호스트를 식별할 수 없었다.

1978: IP에서 TCP 분할

초기 TCP 버전은 동일한 프로토콜에서 오류 및 흐름 제어(현재 TCP)와 릴레이 및 멀티플렉싱(IP) 기능을 수행했다.1978년, 두 레이어의 스코프가 동일함에도 불구하고 TCP는 IP로부터 분리되었다.1987년까지 네트워크 커뮤니티는 IP 단편화의 문제를 잘 알고 있었고, IP 단편화가 유해하다고 생각할 정도였다.[8]그러나 TCP와 IP가 상호의존적이라는 증상으로 이해되지 않았다.

1981: 왓슨의 근본적인 결과는 무시되었다.

1981년 Richard Watson은 연결 관리에 의해 최대 패킷 수명(MPL)의 작은 요소에 의해 제한되는 타이머만 필요로 하는 신뢰할 수 있는 전송의[9] 기본 이론을 제공했다.왓슨 등은 이 이론에 기초하여 손짓 없이 단순히 세 개의 타이머를 묶어 연결 상태를 결정할 수 있는 델타-t 프로토콜을 개발했다.반면에, TCP는 명시적인 핸드셰이킹뿐만 아니라 연결 상태의 타이머 기반의 관리를 더 제한적으로 사용한다.

1983: 인터넷 작업 계층 손실

그림 2.INWG에서 보는 인터넷 아키텍처

1972년 초창기 네트워크 연구 커뮤니티를 통합하기 위해 국제 네트워킹 워킹 그룹(INWG)이 창설되었다.그것이 달성한 초기 과제들 중 하나는 1976년에 승인된 국제 네트워크 전송 프로토콜에 투표하는 것이었다.[11]주목할 만한 것은, 다른 모든 후보자들뿐만 아니라, 선택된 옵션들은 데이터 링크 (다른 유형의 물리적 미디어를 처리하기 위한), 네트워크 (다른 유형의 네트워크를 처리하기 위한)와 인터네트워크 (네트워크의 네트워크를 처리하기 위한)의 3가지 계층으로 구성되는 구조를 가지고 있었고, 각각의 계층은 주소 공간을 가지고 있었다.TCP/IP가 도입되었을 때 NCP 상단의 인터네트워크 계층에서 실행되었다.그러나 NCP가 종료되었을 때, TCP/IP가 네트워크 역할을 맡았고, 인터네트워크 계층이 손실되었다.[12]이는 오늘날 자율 시스템과 NAT이 관리를 용이하게 하기 위해 IP 주소 공간의 범위를 분할하고 재사용해야 하는 필요성을 설명한다.

1983: 누락된 주소 지정을 수정할 수 있는 첫 번째 기회

IP 주소보다 높은 수준의 주소의 필요성은 1970년대 중반부터 잘 이해되었다.그러나 응용 프로그램 이름은 도입되지 않았고 DNS는 설계 및 배치되어 잘 알려진 포트를 계속 사용하여 응용 프로그램을 식별하고 있다.웹과 HTTP의 등장으로 응용 프로그램 이름의 필요성이 생겨 URL로 이어졌다. 그러나 URL은 각 응용 프로그램 인스턴스를 컴퓨터와 특정 전송 연결의 물리적 인터페이스에 연결시킨다. URL은 URL이 IP 인터페이스의 DNS 이름과 TCP 포트 번호를 포함하고 있기 때문에 멀티호밍 및 이동성 문제를 응용 프로그램에 흘리기 때문이다.

1986: 혼잡 붕괴는 인터넷을 놀라게 한다.

데이터그램 네트워크의 혼잡통제의 문제는 1970년대부터 80년대 초반까지 알려져 있었지만,[13][14] 1986년 혼잡 붕괴는 인터넷을 기습적으로 잡았다.더 나쁜 것은 채택된 혼잡 제어인 이더넷 혼잡 방지 체계가 몇 가지 수정과 함께 TCP에 배치되었다.

1988: 네트워크 관리는 한 발짝 뒤로 물러선다.

1988년에 IAB는 나중에 CMIP의 객체지향 접근방식으로 전환하기 위해 SNMP를 초기 네트워크 관리 프로토콜로 사용할 것을 권고했다.[15] SNMP는 네트워크 관리의 한 단계 후퇴한 것이며, 필요한 보다 정교한 접근방식이 구현되는 동안 임시방편으로 정당화되었지만 전환은 일어나지 않았다.

1992: 누락된 주소 지정을 수정할 수 있는 두 번째 기회

1992년 IAB는 IPv4 기반 인터넷의 스케일링 문제를 해결하기 위한 일련의 권고안, 즉 공간 소비와 라우팅 정보 폭발을 다루었다.문제 완화를 위해 CIDR을 도입하거나, CLNP를 기반으로 한 다음 버전의 IP(IPv7)를 설계하거나, 이름 지정, 주소 지정 및 라우팅에 대한 연구를 계속하는 세 가지 옵션이 제안되었다.[16]CLNP는 인터페이스 대신 노드를 다루어 ARPANET으로 거슬러 올라가는 오래된 멀티호밍 문제를 해결하고, 더 나은 라우팅 정보 집계를 가능하게 하는 OSI 기반 프로토콜이었다.CIDR이 도입되었지만 IETF는 CLNP를 기반으로 한 IPv7을 받아들이지 않았다. IAB는 그 결정을 재고했고 IPng 프로세스가 시작되어 IPv6으로 절정에 이르렀다.IPng의 규칙 중 하나는 인터페이스의 이름을 계속하여 멀티호밍 문제를 영구화시키는 IP 주소의 의미론을 바꾸지 않는 것이었다.[5]

개요

그림 3.분산 애플리케이션 프로세스(DAP) 및 해당 구성 요소

RINA는 모든 상황에 적용되는 컴퓨터 네트워킹의 일반적인 원리를 해결하려는 노력의 결과물이다.RINA는 네트워킹뿐만 아니라 모든 분산 애플리케이션에 적용되는 개념과 결과도 다루지만 IPC 모델이라고 비공식적으로 알려진 모델의 구체적인 아키텍처, 구현, 테스트 플랫폼 및 궁극적으로는 배치다.[17]

RINA의 기본 실체는 분산 애플리케이션 프로세스 또는 DAP로, 호스트의 프로세스에 자주 대응한다.두 개 이상의 DAP가 그림 3에 나타낸 것과 같이 분산 애플리케이션 시설 또는 DAF를 구성한다.이러한 DAP는 Common Distributed Application Protocol 또는 CDAP를 사용하여 통신하며, 객체 형태로 구조화된 데이터를 교환한다.이러한 개체는 자원 정보 베이스 또는 RIB로 구성되며, 이것은 그들에게 명명 스키마와 논리적인 조직을 제공한다.CDAP는 원격 DAP의 개체에 대해 생성, 삭제, 읽기, 쓰기, 시작 및 중지라는 6가지 기본 작업을 제공한다.

정보 교환을 위해서는 DAP가 통신 서비스를 제공하는 기반 설비가 필요하다.이 설비는 분산 IPC 설비 또는 DIF라고 불리는 또 다른 DAF로, 이들의 임무는 IPC 서비스를 일정 범위에 걸쳐 제공하고 관리하는 것이다.DIF의 DAP는 IPC Processs 또는 IPCP라고 불린다.그들은 그림 3에 나타낸 것과 동일한 일반 DAP 구조와 IPC를 제공하고 관리하기 위한 몇 가지 특정 작업을 가지고 있다.이러한 업무는 그림 4와 같이 데이터 전송, 데이터 전송 제어, 계층 관리의 3가지 범주로 나눌 수 있다.범주는 복잡성을 증가시키고 빈도를 감소시킴으로써 정렬되는데, 데이터 전송은 가장 단순하고 빈번하게 이루어지며, 계층 관리는 가장 복잡하고 빈도가 낮으며, 데이터 전송 제어는 중간에서 이루어진다.

그림 4.RINA 네트워크 및 IPCP 구성 요소의 예

DAF인 DIF는 와이어와 잭을 제어하는 물리적 레이어 DIF까지 내려가면서 다른 기본 DIF 자체를 사용한다.RINA의 재귀는 여기서 비롯된다.그림 4에 나타낸 것처럼, RINA 네트워크는 대개 범위가 증가하는 DIF로 구성된다.그림 5는 웹이 RINA로 구성될 수 있는 방법의 예를 보여준다: 가장 높은 계층은 이메일이나 웹사이트에 해당하는 애플리케이션과 가장 가까운 계층이다; 가장 낮은 계층은 ISP 백본에 해당하는 상위 계층의 트래픽을 집계하고 멀티플렉스 한다.다중 제공자 DIF(공용 인터넷 등)는 ISP 계층 위에 뜬다.이 모델에서, 세 가지 유형의 시스템을 구분한다: DAP를 포함하는 호스트, 한 계층 내부의 내부 라우터, 그리고 패킷이 한 계층의 위아래로 이동하는 계층의 가장자리에 있는 경계 라우터.

그림 5여러 인터넷 작업을 지원하는 다중 RINA 네트워크.

DIF는 데이터 손실과 지연 시간에 대한 한계, 순서 또는 순서 없는 전달, 신뢰성 등과 같은 목표 DAP와 원하는 QoS 매개변수의 이름만 제공함으로써 하나 이상의 DAP에 흐름을 할당할 수 있도록 한다.DAP는 사용 중인 DIF를 신뢰하지 않을 수 있으므로 예를 들어 SDU 보호 모듈을 통해 데이터를 흐름에 쓰기 전에 데이터를 보호할 수 있다.모든 RINA 계층은 구조와 구성요소가 동일하고 동일한 기능을 제공하며, 구성이나 정책에서만 다르다.[18]이것은 운영체제의 메커니즘과 정책의 분리를 반영한다.

요컨대, RINA는 PDU와 SDU의 개념을 유지하지만 기능별로 레이어링하는 대신 스코프별로 레이어링한다.척도마다 특성과 속성이 다르다는 점을 고려하는 대신 모든 통신의 동작이 근본적으로 다른 매개 변수만으로 동일하다고 본다.따라서, RINA는 통신의 모든 측면을 개념화하고 매개변수화함으로써, 특정 프로토콜과 개념의 필요성을 없애고 가능한 한 많은 이론을 재사용하려는 시도다.

이름 지정, 주소 지정, 라우팅, 이동성 및 멀티호밍

위에서 설명한 것처럼, IP 주소는 멀티호밍과 이동성의 기반이 되는 식별자 수준이 너무 낮으며, 라우팅 테이블이 필요 이상으로 커지도록 요구하기도 한다.RINA 문학은 어드레스와 이름 지정에 관한 제리 솔처(Jerry Saltzer)의 일반 이론을 따른다.솔트저에 따르면, 응용 프로그램, 노드, 부착 지점 및 경로의 네 가지 요소를 식별할 필요가 있다.[19]애플리케이션은 하나 이상의 노드에서 실행될 수 있으며 네트워크에서 그것의 정체성을 잃지 않고 한 노드에서 다른 노드로 이동할 수 있어야 한다.노드는 한 쌍의 첨부 지점에 연결될 수 있으며 네트워크에서 노드 정체성을 잃지 않고 그 사이를 이동할 수 있어야 한다.디렉토리는 응용 프로그램 이름을 노드 주소에 매핑하며, 경로는 노드 주소와 첨부 지점의 순서다.이 점들은 그림 6에 예시되어 있다.

그림 6Saltzer의 이름 지정 및 주소 지정 이론의 예.

솔처는 운영체제에서 그의 모델을 가져갔지만, RINA의 저자들은 그것이 (전체 네트워크는 말할 것도 없고) 동일한 한 쌍의 노드 사이에 둘 이상의 경로를 가질 수 있는 인터넷 네트워크에 깨끗하게 적용될 수 없다고 결론지었다.그들의 해결책은 노드의 시퀀스로 경로를 모델링하는 것이다: 각 홉에서, 각각의 노드는 패킷을 다음 노드로 포워드 하기 위해 가장 적절한 부착 지점을 선택한다.따라서 RINA 루트는 2단계 프로세스로, 먼저 노드 주소의 시퀀스로서의 루트를 계산한 다음, 각 홉에 대해 적절한 부착 지점을 선택한다.포워딩 테이블을 생성하기 위한 단계: 포워딩은 여전히 단일 조회를 통해 수행된다.게다가 마지막 단계는 부하 분산을 위해 멀티홈을 이용하기 위해 더 자주 수행될 수 있다.

이러한 이름 구조와 함께 이동성과 멀티홈밍은 이름이 신중하게 선택한 속성을 가진 경우 본질적으로 지원된다[20].

  1. 응용 프로그램 이름은 응용 프로그램이 이동할 수 있도록 위치 독립적이다.
  2. 노드 주소는 위치 추적 가능하지만 경로에 독립적이다.
  3. 부착 지점은 원래 경로 추적에 의해 지정된다.

이 명명 체계를 재귀적 계층과 함께 RINA에 적용하면 애플리케이션 이름을 노드 주소로 매핑하는 것은 노드 주소를 첨부 지점에 매핑하는 것과 유사하다는 결론을 내릴 수 있다.간단히 말해서, 어떤 계층에서든, 위의 계층의 노드는 애플리케이션으로 볼 수 있고, 아래 계층의 노드는 첨부 포인트로 볼 수 있다.

프로토콜 설계

인터넷 프로토콜 스위트는 또한 일반적으로 프로토콜이 다른 프로토콜에서 중복되었는지 여부와, 따라서 이러한 것들이 정책으로 만들어질 수 있는지 여부와는 무관하게 독립적으로 설계되도록 지시한다.RINA는 운영체제의 메커니즘과 정책의 분리를 프로토콜 설계에 적용함으로써 이것을 피하려고 한다.[21]각 DIF는 서로 다른 등급의 서비스 품질을 제공하고 DIF가 낮은 수준일 경우 물리적 미디어의 특성에 적응하기 위해 서로 다른 정책을 사용한다.

RINA는 1981년 리처드 왓슨이 개발한 델타-T 프로토콜[10] 이론을 사용한다.왓슨의 연구는 신뢰할 수 있는 이적을 위한 충분한 조건이 세 개의 타이머를 묶는 것이라고 시사한다.델타-T는 연결 설정이나 해체 기능이 없다는 것을 보여주는 예다.또한 같은 연구에서는 TCP가 이미 이러한 타이머를 운용에 사용하고 있어 델타-T를 비교적 간단하게 만든다는 점에 주목한다.왓슨의 연구는 또한 동기화와 포트 할당은 별개의 기능이어야 하고, 포트 할당은 계층 관리의 일부여야 하며, 동기화는 데이터 전송의 일부가 되어야 한다고 제안한다.

보안

그림 7RINA의 보안 기능 구성.

RINA는 보안을 수용하기 위해 각 DIF/DAF가 보안 정책을 지정하도록 요구하고 있으며, 이러한 기능은 그림 7에 나와 있다.이를 통해 애플리케이션뿐만 아니라 백본, 스위칭 원단 자체를 보호할 수 있다.공공 네트워크는 단순히 보안 정책이 아무 것도 하지 않는 특수한 경우일 뿐이다.이것은 더 작은 네트워크의 오버헤드를 도입할 수 있지만 계층들이 그들의 보안 메커니즘을 조정할 필요가 없기 때문에 더 큰 네트워크로 더 잘 확장된다. 현재의 인터넷은 RINA보다 약 5배 더 구별되는 보안 실체를 필요로 하는 것으로 추정된다.[22]무엇보다도, 보안 정책은 또한 인증 메커니즘을 지정할 수 있다; 이것은 DAF나 DIF에 가입할 수 없는 DAP나 IPCP가 송신하거나 수신할 수 없기 때문에 방화벽과 블랙리스트를 허용한다.DIF도 IPCP 주소를 상위 계층에 노출시키지 않아 광범위한 종류의 맨인더중간 공격을 방지한다.

단순성에 중점을 둔 델타-T 프로토콜 자체의 설계도 한 요인이다.예를 들어, 프로토콜에는 핸드셰이크가 없기 때문에, SYN 홍수에서와 같이 위조가 가능한 제어 메시지나 잘못 사용될 수 있는 상태가 없다.동기화 메커니즘은 또한 이상 행동을 침입 시도와 더 상관관계가 있게 하여 공격을 훨씬 쉽게 탐지할 수 있게 한다.[23]

연구 프로젝트

2008년부터 2014년까지 PNA 책을 발간하면서 많은 RINA 연구 개발 작업이 이루어졌다.루이 푸진의 이름을 딴 푸진 소사이어티로 알려진 비공식 단체는 몇 가지 국제적인 노력을 조율한다.[24]

BU 연구팀

보스턴 대학교의 RINA 연구 팀 교수 아브라함 마타, 존 날과 루 Chitkushev에 의해, 그리고 RINA의 기초 조사 개발 UDP/IP에 자바[25][26]과 실험 기지에 대한 오픈 소스 원형 구현을 계속 하기 위해 국립 과학 재단과 EC의 보조금의 많은 상을 수상했다.h에GENI 인프라의 최고 수준.[27][28]BU는 푸진 소사이어티의 회원이기도 하며 FP7 IRATI와 PRESTINE 프로젝트에 적극적으로 기여하고 있다.BU는 이 외에도 RINA 개념과 이론을 컴퓨터 네트워킹 과정에 통합했다.

FP7 아이라티

IRATI는 i2CAT, Nextworks, iMinds, Interoute, Boston University 등 5개 파트너가 참여하는 FP7 지원 프로젝트다.이더넷 위에 리눅스 OS용 오픈 소스 RINA 구현을 생산했다.[29][30]

FP7 청정

PRISTINE is an FP7-funded project with 15 partners: WIT-TSSG, i2CAT, Nextworks, Telefónica I+D, Thales, Nexedi, B-ISDN, Atos, University of Oslo, Juniper Networks, Brno University, IMT-TSP, CREATE-NET, iMinds and UPC.그것의 주요 목표는 정체 제어, 자원 할당, 라우팅, 보안 및 네트워크 관리를 위한 혁신적인 정책을 구현하기 위한 RINA의 프로그래밍 가능성 측면을 탐구하는 것이다.

GEANT3+오픈콜 우승자 이리나

IRINA는 GEANT3+ 오픈콜의 자금지원을 받았으며, iMinds, WIT-TSSG, i2CAT, Nextworks 등 4개 파트너사와 함께 하는 프로젝트다.IRINA의 주요 목표는 차세대 NREN 및 GEANT 네트워크 아키텍처의 기초로서 재귀적 네트워크 아키텍처(RINA)의 활용을 연구하는 것이다.IRINA는 IRATI 프로토타입을 기반으로 구축되며, RINA를 현재 네트워킹 상태 및 연구 중인 관련 클린 슬레이트 아키텍처와 비교하고, RINA가 NREN 시나리오에서 어떻게 더 잘 사용될 수 있는지에 대한 사용 사례 연구를 수행하고, 연구의 실험실 시험을 보여줄 것이다.

참고 항목

참조

  1. ^ 네트워크 아키텍처의 패턴: 기본 원리로 돌아가기, John Day(2008), 프렌티스 홀, ISBN978-0132252423
  2. ^ L. 푸진.패킷 교환 데이터 네트워크에서 흐름 제어에 대한 방법, 도구 및 관찰.IEEE 통신 거래, 29(4): 413–426, 1981
  3. ^ J. Day. 왜 loc/id split이 해답이 아니지, 2008.http://rina.tssg.org/docs/LocIDSplit090309.pdf에서 온라인으로 이용 가능
  4. ^ D. 마이어와 D.Lewis. 로케이터의 건축적 시사점ID 분리.https://tools.ietf.org/html/draft-meyer-loc-id-implications-01
  5. ^ a b R. 힌덴과 S.디어링."IP 버전 6 어드레싱 아키텍처".RFC 4291 (Draft Standard), 2006년 2월.RFC 5952, 6052에 의해 업데이트됨
  6. ^ D. Clark, L. Chapin, V. Cerf, R. Braden, R.취미. 미래 인터넷 건축을 지향한다.RFC 1287(정보), 1991년 12월
  7. ^ Fritz. E Froehlich; Allen Kent (1992). "ARPANET, the Defense Data Network, and Internet". The Froehlich/Kent Encyclopedia of Telecommunications. Vol. 5. CRC Press. p. 82. ISBN 9780824729035.
  8. ^ C.A. 켄트와 J.C.모굴. 유해하다고 여겨지는 파편화.ACM SIGCOMM, 1987년 컴퓨터 통신 기술 분야 프런티어 진행
  9. ^ R. 왓슨.신뢰할 수 있는 전송 프로토콜 연결 관리의 타이머 기반 메커니즘.컴퓨터 네트워크, 5:47–56, 1981
  10. ^ a b R. 왓슨.델타-t 프로토콜 사양.기술 보고서 UCID-19293, 로렌스 리버모어 국립 연구소, 1981년 12월
  11. ^ McKenzie, Alexander (2011). "INWG and the Conception of the Internet: An Eyewitness Account". IEEE Annals of the History of Computing. 33 (1): 66–71. doi:10.1109/MAHC.2011.9. ISSN 1934-1547. S2CID 206443072.
  12. ^ J. Day. 어떻게 층을 잃는가?2011년 프랑스 파리, 제2회 미래 네트워크 국제 회의
  13. ^ D. 데이비스.패킷 교환 데이터 네트워크에서 흐름 제어에 대한 방법, 도구 및 관찰.IEEE 통신 거래, 20(3): 546–550, 1972
  14. ^ S. S. Lam과 Y.C. Luke Lien.입력 버퍼 제한에 의한 패킷 통신 네트워크의 정체 제어 - 시뮬레이션 연구.컴퓨터에서의 IEEE 거래, 30(10), 1981.
  15. ^ 인터넷 건축 위원회인터넷 네트워크 관리 표준 개발을 위한 IAB 권고사항.1988년 4월 RFC 1052
  16. ^ 인터넷 건축 위원회IP 버전 7 ** 초안 8 ** 초안 IAB IP버전7, 1992년 7월
  17. ^ 존 데이, 이브라힘 마타, 카림 마타.네트워킹은 IPC: 더 나은 인터넷으로의 안내 원칙이다.2008년 ACM CoNEXT 컨퍼런스 진행 중.ACM, 2008
  18. ^ I. Matta, J. Day, V.이스하키안, K. 마타르, G.구순.선언적 전송: 더 이상 설계할 전송 프로토콜이 없고, 지정하기 위한 정책만 있다.기술 보고서 BUCS-TR-2008-014, 보스턴 CS Dept.U, 2008년 7월
  19. ^ J. 솔처.네트워크 대상의 이름 지정 및 바인딩.RFC 1498(정보), 1993년 8월
  20. ^ V. 이사키안, J. 아킨우니, F.Esposito, I. Matta, "재귀적인 인터넷 아키텍처에서 이동성과 멀티호밍을 지원하는 것에 대하여".컴퓨터 통신, 제35권, 제13권, 2012년 7월, 페이지 1561-1573
  21. ^ P. 브린치 한센.다중 프로그래밍 시스템의 핵.ACM 통신, 13(4): 238-241, 1970
  22. ^ J. Small (2012), Patterns in Network Security: An analysis of architectural complexity in securing Recursive Inter-Network Architecture Networks
  23. ^ G. Boddapati; J. Day; I. Matta; L. Chitkushev (June 2009), Assessing the security of a clean-slate Internet architecture (PDF)
  24. ^ A. L. 러셀, V. 셰퍼"ARPAnet과 인터넷의 그늘에서: 1970년대 루이 푸진(Louis Pouzin)과 사이클라데스(Cyclades) 네트워크의 그늘에서"http://muse.jhu.edu/journals/technology_and_culture/v055/55.4.russell.html에서 온라인으로 이용 가능
  25. ^ 플라비오 에스포지토, 유에펑 왕, 이브라힘 마타, 존 데이.서비스로서의 동적 계층 인스턴스화.2013년 4월 2~5월 USENIX 네트워크 시스템 설계 및 구현 심포지엄(NSDI '13, Lombard, IL, 2013년 4월)에서 시연.
  26. ^ 유에펑 왕, 이브라힘 마타, 플라비오 에스포지토, 존 데이.ProtoRINA 소개: 재귀-네트워킹 정책 프로그래밍의 프로토타입.ACM SIGCOMM 컴퓨터 통신 검토.제44권 2014년 7월 3일자.
  27. ^ 유에펑 왕, 플라비오 에스포지토, 이브라힘 마타."GENI 테스트베드를 사용하여 RINA 시연"제2차 GENI 연구 및 교육 실험 워크샵(GREE 2013), 솔트 레이크 시티, UT, 2013년 3월.
  28. ^ 유에펑왕, 이브라힘 마타, 나베엘 아크타르. "GENI보다 프로토리나(ProtoRINA)를 활용한 라우팅 정책 실험"제3회 GENI 연구 및 교육 실험 워크샵(GREE2014), 2014년 3월 19~20일, 조지아 주 애틀랜타
  29. ^ S. Vrijders, D.Stessens, D.콜레, F. 살베스트리니, E. 그라사, M. 타잔, L.Bergesio "재귀적 인터넷 작업 아키텍처 프로그래밍:IRATI 프로젝트 접근방식," IEEE 네트워크, Vol. 28, 2014년 3월 2일
  30. ^ S. Vrijders, D.Stessens, D.Colle, F. Salvestrini, V. Maffione, L. Bergesio, M. Tarzan, B. Gaston, E. Grasa; "재귀적 인터네트워크 아키텍처 프로토타입의 실험 평가", IEEEE Globcom 2014, 텍사스 오스틴,

외부 링크