DEC LANBridge 100과 스패닝 트리 전환, 1985

요약

DEC의 LANBridge 100은 1986년에 분산 스패닝 트리 알고리즘을 제품에 담았다. 이 브리지는 별개의 이더넷 세그먼트가 하나의 확장 LAN으로 동작하게 하면서, 중복 경로는 대기 상태로 두었다.
IEEE 802.1D는 동일한 논리적 트리 결과를 유지했지만, Hello 프레임은 DEC의 것과 달랐다. 마이그레이션 브리지는 두 모드를 인식하고 한 번에 하나씩 실행할 수 있었다. 표준 공표만으로 설치된 브리지 전체가 상호 운용 가능해지는 것은 아니었다.

이더넷의 유용한 중복성은 곤란한 문제를 낳았다. 같은 LAN 세그먼트들을 잇는 브리지가 두 개 있으면 물리적 루프가 남을 수 있었다. 루프에 들어간 브로드캐스트 프레임은 계속 순환하며 이미 본 세그먼트에 다시 복제될 수 있었다. 따라서 브리지에는 어떤 링크가 일반 트래픽을 운반하고 어떤 링크가 백업으로 대기할지를 정하는 규칙이 필요했다.

Radia Perlman은 1985년 논문에서 확장 LAN에 대한 스패닝 트리의 분산 계산을 다루며 이런 규칙을 제시했다. 브리지들은 정보를 교환해 하나의 루트를 선정하고, 각 LAN마다 우선 브리지를 식별하며, 중복 경로는 활성 논리 트리에서 제외한다. 그녀의 논문은 이를 임의의 LAN 토폴로지에 대한 분산 알고리즘으로 틀을 잡았다. 논문은 수렴이 네트워크 직경에 비례한다고 보고하면서도, 각 브리지에 필요한 메모리와 각 LAN에 가해지는 통신 부담은 브리지나 링크의 총수에 따라 늘어나지 않는다고 기술했다. 이 논문은 방법을 확립했을 뿐, 제품 시장을 확립하거나 얼마나 많은 네트워크가 이를 사용했는지 보여 주지는 않았다.

DEC의 제품사 연혁은 표준 발표가 아니라 개발 프로젝트를 통해 이어졌다. 1986년 9월호 Digital Technical Journal은 Brooklyn Bridge라는 별명의 초기 프로토타입을 다루었다. 이 프로토타입은 실험실에서 동작했고, 이후 Tewksbury에 있는 이더넷과 Digital의 Engineering Network 사이에 설치되었다. 이 작업은 Janus라는 제품 프로젝트와 LANBridge 100으로 이어졌다. 이 브리지는 확장된 네트워크를 관리 가능하게 유지하면서 LAN을 투명하게 연결하는 것을 목표로 했다. 설계자들은 콘솔에 사람이 없어도 기동·운영되고, 루프 같은 문제 구성을 탐지하면서도 카운터와 선택된 설정을 네트워크 관리자에게 노출하기를 원했다. 따라서 중복성 결정은 더 큰 제품의 일부였다. 포워딩 하드웨어, 주소 학습, 관리 기능, 대기 동작이 함께 맞물려 동작해야 했다.

DEC 엔지니어들은 스패닝 트리 계산을 루프가 있는 물리 배치가 루프가 있는 포워딩 토폴로지가 되지 않도록 만드는 방식으로 기술했다. LANBridge 100은 링크를 백업으로 두고, 나머지 활성 링크들이 LAN들을 트리 형태로 연결하게 할 수 있었다. 이후 브리지나 경로가 고장 나면 어떤 링크가 활성인지 바뀔 수 있었다. 그러나 이것이 결과의 모든 경로가 애플리케이션 트래픽을 전달함을 증명하는 것은 아니었다. 이 알고리즘이 제어하는 것은 브리지의 포워딩 토폴로지였다.

다음 단계는 단순히 DEC의 프레임 이름을 바꾸는 일이 아니었다. DEC는 자신의 알고리즘을 IEEE에 제안했고, IEEE 802.1D MAC 브리징 표준은 결국 호환 가능한 트리 계산을 명시했다. IEEE의 표준 기록은 세 개의 날짜를 각각 제시한다. 1990년 5월 31일 위원회 승인, 같은 해 10월 18일 ANSI 승인, 1991년 3월 8일 공표이다. 이 날짜들은 표준화 단계를 기술할 뿐, 운영 중인 네트워크의 장비를 동시에 교체한 사실을 뜻하지 않는다.

Digital의 브리지 참고 문서가 실무적 격차를 설명한다. LANBridge 100 모드와 IEEE 802.1D 모드는 동일한 논리적 스패닝 트리를 계산할 수 있었지만, Hello 메시지에 서로 다른 멀티캐스트 주소를 사용했다. 한쪽 모드의 브리지는 다른 모드의 메시지를 해석하지 못했다. 두 종류가 같은 확장 LAN에 있으면 각자 자기 트리를 형성할 수 있었고, 토폴로지와 기동 순서에 따라 결과가 불확정하거나 불안정해질 수 있었다. 호환성은 브리지들이 실제로 교환하는 메시지에 존재했으며, 계산하려 의도한 그래프만으로는 성립하지 않았다.

DEC의 이후 제품인 LAN Bridge 150과 200, 그리고 DECbridge 500/600 계열은 Auto-Select 또는 마이그레이션 모드를 제공했다. 브리지는 구형 LANBridge 100의 Hello를 청취해 그 모드로 전환했다가, 레거시 장비가 남아 있지 않으면 IEEE 모드로 되돌아갈 수 있었다. 같은 장치가 두 트리를 동시에 돌리지는 않았다. 네트워크 관리자가 IEEE 모드에 고정할 수도 있었다. 매뉴얼은 남은 레거시 브리지를 찾아 교체를 계획하는 방법을 기술했지만, 얼마나 많은 고객이 그 마이그레이션을 완료했는지는 보고하지 않았다.

이것이 좁은 역사적 교훈이다. 표준은 공유되는 결과를 보존하면서도 구현들이 교환 지점에서는 여전히 어긋날 수 있다. 브리지 출하는 알고리즘을 작동 가능하게 만들었고, 802.1D는 이를 표준 기반의 규칙으로 만들었으며, 마이그레이션 장비는 혼재된 설치 환경에 그 둘 사이의 경로를 제공했다. 그중 어느 사건 하나만으로도 폭넓은 채택을 증명하지는 못한다. 근거가 뒷받침하는 것은 설계, 제품화, 표준화, 호환성 작업의 순서이며, 모든 이더넷 브리지가 같은 언어를 말하기 시작한 단일 시점이 아니다.