요약

  • RFC 1070은 OSI 네트워크 계층 패킷을 IP 안에 캡슐화하여, 구현자들이 인터넷 게이트웨이를 수정하지 않고도 기존 인터넷을 통해 OSI 라우팅을 시험할 수 있게 했다. IP는 하위 네트워크를 제공했고, EON은 그 위의 서로 다른 논리적 토폴로지를 제공했다.
  • IP 주소, EON 주소,core.EON항목, 로컬 SNAcP 캐시, ES/IS 광고는 각각 서로 다른 사실을 확립했다. 이 메모의 오래된 목록 예시는 물리적 도달 가능성이 유지되는 동안 역할과 1홉 멤버십이 어긋날 수 있음을 보여주었다.

경고가 메커니즘보다 먼저 나온다. 1989년 2월에 발표된RFC 1070은 자신의 방법들을 제한된 실험에만 적합하며 운영 환경에는 부적합하다고 명시했다. 이 문장이 중요한 이유는, 설계 자체가 아직 덜 성숙한 네트워크 계층을 쉽게 교란할 수 있도록 만들어졌기 때문이다. 구현자들은 역할을 바꾸고, 라우팅 교환을 시험하고, 장애를 관찰할 수 있는 넓고 다양한 토폴로지가 필요했다. 기존 IP 게이트웨이의 소프트웨어를 교체했다면, 작동 중인 인터넷을 위험에 빠뜨리는 대가로 실험의 현실성이 확보될 수 있었을 것이다.

대안은 인터넷의 연결성을 빌리되 게이트웨이는 그대로 두는 것이었다. 완전한 OSI connectionless 네트워크 계층 PDU—CLNP, ES-IS 또는 IS-IS—가 IP 데이터그램 안에 담겼다. 각 사이트는 로컬 링크에서 OSI 프로토콜을 직접 실행하고, IP 게이트웨이가 사이를 가로막을 때만 인터넷을 호출했다. 이 메모는 그 운반체를 “IP 서브넷”이라 불렀다. 그 위의 실험은 EON, 즉 Experimental OSI-based Network라고 불렀다.

도달 가능한 주소가 곧 EON 이웃은 아니었다

서브넷이라는 용어의 이 사용은 의도적으로 논리적인 것이었다. RFC 1070은 참여 사이트의 거의 모든 시스템이 IP를 통해 도달 가능할 수 있지만, OSI 시험을 위해 자신이 IP 서브넷에 직접 연결되어 있다고 간주하는 것은 구성된 부분 집합뿐이라고 관찰했다. 한 기기는 OSI 종단 시스템(ES), 중간 시스템(IS) 또는 둘 다로 자신을 나타낼 수 있었고, 물리적 인터넷에서의 위치를 바꾸지 않고도 그 역할을 바꿀 수 있었다.

직접 EON은 각 ISO-gram을IPv4데이터그램의 데이터 필드에 넣고 프로토콜 번호 80을 사용했다. 설계자들은 OSI 계층이 단편화를 수행하도록 하여 그 동작이 시험되기를 원했지만, IP 단편화를 막을 수는 없어서 여전히 하위 계층에서의 재조립을 필요로 했다. 여기서도 계층들은 서로 다른 증거를 만들었다. IP 단편의 도착은 그 안에 담긴 OSI PDU가 재조립되었고, 수용되었고, 라우팅되었다는 것을 증명하지 않았다.

주소 지정은 그 분리를 지우지 않으면서도 운반체를 사용 가능하게 만들었다. EON NSAP 형식은RFC 1069를 따랐고, 4옥텟 인터넷 주소를 그 끝 근처에 내장했다. 따라서 대응하는 서브네트워크 접속 주소를 알고리즘적으로 도출할 수 있었다. 초기 로컬 영역 필드는 0이었고, 라우팅 도메인 번호는 IANA가 할당했다. 이 매핑은 IP 데이터그램을 어디로 보낼 수 있는지에 답했다. 그 대상이 현재 ES인지, IS인지, 1홉 EON 피어인지, 유용한 경로인지에는 답하지 않았다.

RFC 1070은 하지 않는 것들에 대해 명시적이었다. 이 메모는 생산 규모, 임의의 NSAP 형식, 모든 OSI 라우팅 프로토콜에 대한 필수 지원, ISO-gram을 위한 IP 라우팅 알고리즘, IP-to-CLNP 게이트웨잉을 제안하지 않았다. 인터넷이 OSI 네트워크로 이름이 바뀐 것은 아니었다. 인터넷은 OSI 라우팅과 주소 지정을 유지하는 실험 아래에서 패킷 서비스를 공급하고 있었다.

SNAcP은 IP가 약속하지 않은 브로드캐스트 서브넷을 만들어냈다

OSI 라우팅 교환은 “모든 종단 시스템”, “모든 중간 시스템” 같은 브로드캐스트 서브네트워크 의미를 가정했다. IP 기반은 EON에 그러한 그룹을 제공하지 않았다. RFC 1070은 OSI connectionless 계층과 IP 사이에 작은 SubNetwork Access Protocol, 즉 SNAcP를 삽입했다.

각 SNAcP는 자기 로컬 시스템이 ISO 8473 1홉 안에서 도달 가능하다고 간주하는 인터넷 주소들의 캐시를 유지했다. 개별 대상에는 한 복사본을 보냈다. 모든 ES, 모든 IS 또는 브로드캐스트에는 캐시된 주소들로 ISO-gram을 복제했다. 짧은 헤더는 버전, 주소 의미 체계, ISO Fletcher 체크섬을 담았다. 수신 시 로컬 SNAcP는 개별 트래픽과 브로드캐스트 트래픽은 항상 수용했고, all-ES 및 all-IS 형태의 수용 여부는 기기가 그 역할들에 대해 구성되어 있는지에 달렸다.

겉보기 브로드캐스트 네트워크는 따라서 복제 행위와 로컬 해석의 결합이었다. 캐시된 모든 주소로 보내진 패킷은 송신자의 캐시가 멤버십 관점을 가지고 있었다는 증거였다. 수용은 수신자의 역할 구성에 대한 증거였다. 어느 쪽도 캐시에 가능한 모든 참여자가 존재했는지, 그들의 역할이 최신인지, OSI 경로가 학습될지를 확립하지 않았다.

오류 처리도 같은 계층 구조를 유지했다. RFC 1070은ICMP의 destination-unreachable, parameter-problem 또는 time-exceeded 표시가 캐시된 피어를 사용 불가로 표시할 수 있고, source quench는 임시로 그렇게 할 수 있다고 제안했다. 응답은 로컬에 남겨졌다. “네트워크 관리에 통보”는 콘솔 한 줄, 카운터, 로그, 로컬 프로세스—또는 아무것도—를 의미할 수 있었다. 주소가 사용 불가가 되면 SNAcP는 복제 트래픽에서 그 주소를 생략하고, 개별 트래픽에 대해서는 오류를 반환했다. IP 계층의 관찰은 실험 링크에 대한 로컬 모델을 변경했지만, 오직 정책을 통해서만 그랬다.

한 목록은 토폴로지를 부트스트랩했고, 다른 하나는 단지 사람들을 도왔다

코어 시스템은 라우팅 교환이 피어를 가르치기 전에 피어를 필요로 했다. 그래서 RFC 1070은 IANA에 네 개의 파일을 배정했다.core.EON과core.EON-UDP는 두 실험 각각에서 논리적으로 ISO 1홉 거리에 있다고 간주되는 주소들을 공급했다.hosts.EON과hosts.EON-UDP는 응용과 사용자를 위해 참여 종단 시스템을 나열했다. 호스트 목록은 OSI connectionless 네트워크 계층에서 사용되지 않는다고 명시되었다.

구분은 파일명이 암시하는 것보다 더 선명했다.core.EON에 포함되었다고 해서 그 기기가 게이트웨이 또는 IS라는 뜻은 아니었다. ES, IS 또는 둘 다일 수 있었다. 새 코어 참여자는 자기 항목이 배포되기 전에도 운용될 수 있었지만, 재부팅된 피어들은 그에게 초기 ESH 또는 ISH 구성 메시지를 보내야 한다는 것을 알 방법이 없었다. 그 파일은 역할에 대한 완전한 설명이 아니라 운영상의 부트 지식이었다. 호스트 목록은 라우팅 입력이 아니라 설명적 편의였다.

RFC 1070의 가상 사이트 Fordor는 이 추상들을 증거 시험으로 바꿔준다. 주소192.5.2.1은 IS이자 코어 시스템으로 시작하고,192.5.2.2는 ES로 시작한다. 두 기기는 물리적 인터넷 연결성이 그대로인 상태에서 역할을 서로 바꾼다. IANA 목록이 즉시 갱신되지 않으면, 다른 코어 시스템들은 계속 구성 메시지를.1로 보내고, 이제 ES가 된.1이 그에 응답한다. 그들은.2에 접속해야 한다는 것을 알지 못하므로, 새 IS는 IP로는 도달 가능함에도 EON 토폴로지에서는 도달 불가능하게 나타난다.

.2가 부팅되어 OSI 라우팅 교환을 통해 광고하면, 중간 시스템들이 응답하고 캐시를 갱신할 수 있다. 그때 논리적 링크들이 나타난다. 케이블은 수리되지 않았고 IP 경로도 반드시 바뀌지 않았다. 바뀐 것은 네트워크 계층이 이용할 수 있는 증거였다: 레지스트리 시드, 역할 광고, 학습된 1홉 상태.

UDP 접속은 대체 신원이 아니라 병렬 실험을 만들었다

일부 구현자는 UDP에 대한 시스템 인터페이스는 있었지만 IP에 대한 직접 접근은 없었다. EON-UDP는 OSI NPDU를 포트 147의UDP데이터그램에 넣고 SNAcP를 UDP 위에 두었다. RFC 1070은 나머지 실험이 동일하다고 했지만, 두 형태가 직접 상호운용되지는 않는다고도 말했다. 게이트웨이가 만들어질 수는 있었지만, 그 설계와 라우팅은 범위 밖이었다. EON과 EON-UDP는 서로 다른 구현 제약을 위한 별개의 실험이었고, 별개의 코어 및 호스트 목록을 가졌다.

이 경계는 RFC 1070을 근처의 다른 작업들과도 분리한다.RFC 1006은 OSI 전송 서비스를 TCP 위에 실어 세션 이상의 계층이 TCP/IP 인터네트워크에서 실행될 수 있게 했다. RFC 1070은 OSI 네트워크 및 전송 계층을 IP 인터네트워크 위에 실었다. RFC 1069는 CLNP를 전달하는 게이트웨이에서 인터넷 라우팅과 주소 지정을 사용하는 것을 기술했고, RFC 1070은 그런 전달에서 OSI 라우팅과 주소 지정을 기술했다. 유사한 재료가 같은 계층의 실험을 의미하지는 않았다.

출처와 한계

RFC 1070은 제안이자 실험 시나리오이다. 이 문서는 의도된 메커니즘과 가상 토폴로지를 기록하며, 광범위한 EON 채택, 생산 적합성, 또는 이름이 알려진 현대 오버레이로의 인과적 단계를 기록하지 않는다.RFC 994와RFC 995는 당시의 CLNP 및 ES-IS 명세를 공급한다. 그러나 특정 EON 참여자가 올바르게 동작했다는 것을 증명하지는 않는다. Fordor 주소는 오래된 제어 상태를 보여주는 예시이며 사고 보고서가 아니다.

역사적 주장은 더 좁고 더 유용하다. 한 네트워크는 그 네트워크가 되지 않고도 다른 네트워크의 링크로 사용될 수 있다. 도달 가능성, 주소 매핑, 인정된 멤버십, 구성된 역할, 캐시된 인접성, 학습된 경로는—같은 패킷을 공유할 때조차—별개의 관찰로 남는다.