요약

  • TUBA는 TCP, UDP 및 많은 인터넷 애플리케이션을 네트워크 계층 위에 그대로 유지하되, IPv4를 CLNP와 그 구조화된 NSAP 주소로 대체할 것을 제안했습니다.
  • 이 전환은 라우터 지원만으로는 충분하지 않았습니다. 호스트, DNS 레코드, IPv4에 대한 내장된 가정, 경로 집합 그리고 CLNP를 변경할 권한까지 모두 중요한 변수였습니다.

유지된 것과 바뀐 것

1992년 6월, Ross Callon의RFC 1347은 서로 연결된 두 가지 압박 — 32비트 IPv4 주소의 고갈과 백본 라우팅 테이블의 급속한 성장 — 에 대한 장기적 해답을 제시했습니다. 이 메모는 제안을 TUBA, 곧 “TCP and UDP with Bigger Addresses(더 큰 주소를 가진 TCP와 UDP)”라고 불렀습니다. 이 제안은 IPv4 자체를 확장하는 것이 아니라 다른 네트워크 계층을 제안한 것입니다. 익숙한 애플리케이션과 전송 계층은 그대로 두고, TCP와 UDP를 ISO 비접속형 네트워크 프로토콜(CLNP) 위에서 구동하며, IP 주소 대신 네트워크 서비스 접근 지점(NSAP) 주소를 사용하자는 것이었습니다.

이 이름은 라우터가 전달할 것이 아니라 애플리케이션에게 보이는 부분이 무엇인지를 설명한 것입니다. 자체 프로토콜 내부에 32비트 주소를 담지 않는다면, 브라우저, 메일 프로그램, 파일 전송 프로그램은 계속 TCP나 UDP를 사용할 수 있었습니다. 그러나 그 전송 계층 아래에서는 패킷 형식, 주소 지정, 포워딩이 모두 달라지게 됩니다. Callon은 완전히 새로운 네트워크 프로토콜을 구현하고 배포하는 데는 시간과 노력이 들지만, CLNP는 이미 비접속형 데이터그램 서비스를 제공하고 있었고 일부 인터넷 백본과 지역 네트워크에 존재했으므로, 재사용이 새로 만들어야 할 장치의 양을 줄여줄 것이라고 주장했습니다.

이것은 OSI로의 전면 전환이 아니었습니다. TUBA의 주장은 더 좁았습니다. IP를 대체하되, TCP와 UDP는 그대로 두고, OSI 애플리케이션이나 전송 계층을 요구하지 않는다는 것이었습니다. 1993년 12월에 발표된 실험적(Experimental) 메모인RFC 1561은 이어서 TUBA 환경을 위한 CLNP 프로파일을 규정했습니다. 또한 CLNP와 IP가 서비스 측면에서는 유사하지만 세부에서는 동일하지 않다는 점을 인정했습니다. 즉, 이 프로파일은 인터넷 프로토콜들이 기대하는 의미를 보존해야 했습니다.

전환은 네트워크 가장자리에서도 일어나야 했다

RFC 1347은 구형 호스트와 업그레이드된 호스트가 나란히 동작하는 모습을 스케치했습니다. 업그레이드된 호스트는 DNS에 평범한 IP 주소를 요청해 구형 스택을 사용할 수도 있고, 더 긴 NSAP 주소를 받아 CLNP 위에서 TCP나 UDP를 전송할 수도 있었습니다. 따라서 DNS에는 새로운 긴 주소 레코드가 필요했습니다. 라우터는 멀티프로토콜 장비든 별도의 라우터 집합이든, IP와 CLNP를 모두 포워딩해야 했습니다. 이 제안은 각 패킷을 두 프로토콜 사이에서 변환하거나 터널링할 것을 요구하지 않았습니다. 이름 조회가 돌려준 주소가 어느 네트워크 계층을 사용할지를 결정했습니다.

이 설계는 점진적 운용을 가능하게 했지만, 의존 관계를 지워주지는 않았습니다. 호스트가 TUBA를 지원하면서도 IP 전용 네트워크에 놓여 있을 수 있었습니다. 일부 FTP와 NFS 사용처처럼 메시지 안에 IPv4 리터럴을 복사해 넣는 애플리케이션은 TCP가 여전히 존재한다는 이유만으로는 변경 없이 남아 있을 수 없었습니다. DNS 운영자, 호스트 구현자, 네트워크 운영자가 각각 전환의 한 부분을 담당했습니다. 더 큰 주소 필드가 효율적인 라우팅을 보장하지도 않았습니다. NSAP 할당의 계층 구조가 라우터가 경로를 집합(aggregation)할 수 있을 만큼 위상을 충분히 반영해야 했습니다.

이 제안의 매력적인 배포 논거는 CLNP를 처리할 수 있는 라우터가 이미 존재했다는 점이었습니다. 그러나 1995년 1월까지,RFC 1752는 이 주장과 종단 간 준비 상태 사이의 간극을 기록했습니다. 검토자들은 상당한 규모의 CLNP 지원 라우터 배포는 확인했지만, 많은 호스트나 실제 네트워크가 CLNP를 구동하고 있다는 데는 동의하지 않았습니다. 프로토콜을 포워딩할 수 있는 장비는 유용한 인프라이지만, 애플리케이션들이 그 프로토콜 위에서 서로 통신할 수 있다는 증거는 아니었습니다.

빌려온 프로토콜에는 주인이 있었다

재사용은 기술 설계 안에 거버넌스 문제를 끌고 들어왔습니다. RFC 1752는 CLNP의 헤더 정렬, 소스 라우트 동작, 오류 메시지 등 여러 필드에 대한 우려를 나열합니다. 일부 부분은 조정이 필요할 수 있었습니다. 그런데 TUBA 참여자들은 IETF가 기본 CLNP 사양을 수정할 수 있는지, 아니면 변경 사항이 ISO를 통과해야 하는지에 대해 의견이 갈렸습니다. 인터넷의 노력이 향후 수정이 다른 곳에서 통제될 수 있는 프로토콜에 의존하는 것은 단순한 서류 문제 이상이었습니다. 결함이 얼마나 빨리 고쳐질 수 있는지, 누가 상호 운용 가능한 프로파일을 정의할 수 있는지에 영향을 주었기 때문입니다.

IPng 최종 권고는 TUBA를 무의미하게 만들지 않았습니다.RFC 1752는 광범위한 논의 끝에 수정된 SIPP 프로토콜을 IPng의 기반으로 권고했습니다. 동시에 RFC 1752는 하나의 종합 결과를 서술합니다. SIPP가 기본 프로토콜의 상당 부분을 제공했지만, TUBA는 자동 구성과 전환 작업에 영향을 미쳤다는 것입니다. 이것이 TUBA를 단순히 실패한 대안이라 부르는 것보다 더 정확한 결론입니다. CLNP가 새로운 인터넷 계층이 되지는 않았지만, TUBA의 접근 방식은 인터넷 스택의 일부를 보존했고 아이디어도 기여했습니다.

Lu Heng의 이후Note:64는 1990년대에 대한 증거가 아니라 유용한 회고적 관점을 제공합니다. 참여자들이 상호 운용하기 위해 필요한 최소 규칙, 구현자가 로컬에서 선택할 수 있는 항목, 그리고 운영 중인 시스템에서 입증된 도입을 분리하자는 것입니다. TUBA의 역사는 이 세 가지 질문 모두에 부담을 줍니다. 프로토콜을 재사용하면 발명의 부담은 줄 수 있지만, 상호 운용성은 여전히 누가 그것을 변경할 수 있는지, 어떤 종단 시스템이 구현하는지, 운영자가 이를 전달하기로 선택하는지에 달려 있습니다.

출처