요약

  • RFC 947은 떨어져 있는 LAN들 사이에서 선별된 Cronus 브로드캐스트를 전달하는 호스트 기반 포워더와 리피터를 다루며, 그 사이의 일반 트래픽은 평범한 게이트웨이가 운반했습니다.
  • 저자들은 이 기능을 게이트웨이나 모든 Cronus 커널에 넣는 대신 호스트에 구현했고, 작동하는 구현은 상당한 패킷 필터링 비용을 드러냈습니다.

네트워크의 잘못된 가장자리에 도달한 메시지

Cronus는 어떤 호스트가 답을 갖고 있는지 먼저 알지 못한 채 로컬 브로드캐스트로 자원을 찾거나 서버 상태를 수집할 수 있었습니다. 하나의 이더넷 안에서는 편리한 방식이었습니다. 하지만 물리적 네트워크의 가장자리에서 그 편리는 끝났습니다. 브로드캐스트는 다른 인터넷 트래픽처럼 게이트웨이를 통해 단순히 전달되지 않았습니다. 결과로 생긴 문제는 일반적인 연결성 실패보다 좁은 것이었습니다. 서로 다른 네트워크의 호스트들은 통신할 수 있었고, 알려지지 않은 로컬 수신자에게 묻는 특정한 방식만이 그들 사이를 따라갈 수 없었습니다.

Ken Lebowitz와 David Mankins는 1985년 6월에 발표된RFC 947에서 그들의 해답을 설명했습니다. Cronus는 TCP와 UDP를 모두 사용했고, 그 브로드캐스트는 애플리케이션이 실제로 필요로 하는 것보다 많은 기계에 도달했습니다. 저자들은 멀티캐스트가 이런 선택적 청중에 더 잘 맞는다고 보았지만, 일부 네트워크 구현에는 그것이 없다고 밝혔습니다. 그래서 초기 Cronus 유틸리티는 브로드캐스트를 사용했습니다. 이들의 실험은 모든 게이트웨이를 Cronus 참여자로 취급하지 않으면서, 그 유틸리티를 둘 이상의 물리적 네트워크에 걸쳐 유지하는 방법을 물었습니다.

포워더는 송신 측 LAN에 연결된 호스트에서 수신 대기했습니다. 지정된 포트나 목적지 주소로 브로드캐스트 UDP 패킷을 선별하고, 일치하는 패킷을 멀리 있는 LAN의 리피터에게 보내는 메시지로 감쌌습니다. 설정 파일은 리피터들을 이름으로 지정했고 리피터마다 다른 패킷 선택 기준을 둘 수 있었습니다. 포워더는 설정된 각 리피터로 TCP 연결을 시도하고 실패 시 주기적으로 재시도했습니다. 먼 곳에서는 리피터가 그 패킷을 해당 LAN의 링크 계층 브로드캐스트 목적지로 LAN에 실었고, 원래 패킷의 출발지 주소는 그대로 유지했습니다. 사이의 게이트웨이들은 네트워크 사이에서 트래픽을 옮겼지만, 그 자체가 브로드캐스트 리피터가 되지는 않았습니다.

설정은 리피터가 아닌 호스트를 지목할 수도 있었습니다. 그 경우 포워더는 목적지를 브로드캐스트에서 그 호스트의 주소로 바꾸어 유니캐스트 데이터그램을 보냈습니다. 이 작은 옵션이 설계의 실제 범위를 보여줍니다. 이것은 모든 라우터에 모든 로컬 브로드캐스트를 전달하라고 지시하는 것이 아니라, 선택적으로 구성되는 배포 서비스였습니다. RFC는 Cronus의 필요를 중심으로 만들어진 서비스를 보고하면서, 그 메커니즘이 다른 브로드캐스트 기반 프로토콜에도 적용될 수 있다고 적었습니다.

게이트웨이가 밖에 머문 이유

이 기능을 게이트웨이에 넣는 것은 명시적으로 검토된 대안이었습니다. 저자들은 몇 가지 이유로 그것을 거절했습니다. 게이트웨이는 수신자 테이블과, 그 테이블을 최신으로 유지하기 위한 게이트웨이 제어 프로토콜의 확장이 필요했을 것입니다. 유용한 메시지만 고르는 일에는 게이트웨이가 가진 것보다 더 높은 프로토콜 스택 지식이 필요할 수 있었습니다. Cronus 설치 환경은 그 기능을 결코 구현하지 않는 공급업체의 장비에 의존할 수도 있었습니다. 더 눈에 띄는 점은, 하위 게이트웨이를 관리하는 사람들이 Cronus를 재구성하는 사람들과 다를 수 있다는 것입니다. 네트워크 다이어그램에서 편리한 중심 위치가 실제로 이용 가능한 관리 위치는 아니었습니다.

Cronus 커널은 또 하나의 그럴듯한 자리를 제공했습니다. 그러나 메커니즘을 거기에 두면 참여하는 모든 커널이 서로의 주소를 알아야 했고, 시스템 구성을 바꾸는 유연성이 제한되었습니다. 해법이 Cronus에 더 단단히 묶일 수도 있었습니다. 호스트 프로세스는 이 배포 결정을 그것을 필요로 하는 시스템과 함께 두었습니다. 이 배치가 이 글의 역사적 경첩입니다. 확장은 네트워크 경계를 넘었지만, 그 운영 선택은 공유 게이트웨이 계층 바깥에 남았습니다.

저자들은 재브로드캐스트된 패킷이 포워더로 되돌아와 순환할 수 있다는 것을 알고 있었습니다. 그래서 포워더는 자기 LAN에 있는 리피터와는 연결하지 않았습니다. 또한 출발지 주소가 포워더의 LAN 밖인 패킷은 전달하지 않아, 두 LAN에 걸친 루프를 막았습니다. 이것들은 기술된 피드백 제어이지, 송신자 인증이나 보편적 루프 안전성의 주장이 아니었습니다. 원래 출발지 필드를 유지하려면 BBN의 TCP/IP 구현에 특수 기능이 필요했고, 권한 있는 프로세스가 다른 호스트의 출발지 주소로 전송할 수 있었습니다. 눈에 보이는 출발지 필드는 수신자에게 그 데이터그램이 어디서 왔다고 주장되는지를 알려줄 뿐, 그것만으로 신원을 증명하지는 않았습니다.

보고된 시험이 확립할 수 있는 것

경험 섹션은 두 개의 이더넷이 물리적으로 두 개의 다른 LAN에 의해 분리되어 있었다고 기록합니다. 두 네트워크 사이의 메시지는 최소 두 개의 게이트웨이를 건넜습니다. BBN 네트워킹 소프트웨어를 갖춘 4.2BSD UNIX의 VAX에서 분리된 포워더와 리피터 프로세스가 몇 달 동안 브로드캐스트 도메인을 확장했고, 저자들은 그 구성이 자신들의 목적에 잘 맞았다고 말했습니다. 이것은 하나의 구성에 대한 범위가 정해진 보고이며, 배포 수의 집계도 일반적인 인터넷 채택의 척도도 아닙니다.

성공에는 저자들이 숨기지 않은 비용이 있었습니다. 사용자 계층의 포워더는 공유 호스트에 도착하는 모든 UDP 패킷마다 깨어난 다음, 전달할 필요가 없는 패킷을 거절했습니다. 그들은 구성과 재브로드캐스트는 사용자 코드에 두면서 필터링을 커널로 옮기는 방안을 고려했습니다. 또한 리피터를 전용 마이크로컴퓨터 기반 실시간 시스템으로 옮길 계획도 있었습니다. RFC 947은 이것들을 완성된 결과가 아니라 가능한 해법으로 기록합니다.

RFC 919는 이미 브로드캐스트가 모든 수신 호스트에 부담을 지운다고 경고했고,RFC 922는 서브네팅 속에서의 IP 브로드캐스트를 다루었습니다. Cronus 보고서는 더 구체적인 교훈을 더합니다. 도달 범위를 넓히는 것만으로는, 어떤 패킷이 건널 자격이 있는지, 누가 그 결정을 구성할 수 있는지, 어느 기계가 그것을 검사하는 비용을 부담하는지를 정할 필요가 사라지지 않았습니다. 이 글의 근거는 저자들의 실험에서 끝납니다.RFC 1112를 포함한 이후의 멀티캐스트 명세는 다른 표준 지평을 표시할 뿐, 이 특정 설치가 대체되었다는 증거가 아닙니다.

출처