요약

  • RFC 1490은 프레임 릴레이(Frame Relay) 네트워크의 최대 프레임 크기를 초과하는 패킷을 조각화할 것을 강제가 아닌 제안으로 담았고, 재조립은 네트워크 장비의 경계에서 이루어지도록 했습니다.
  • 이 메커니즘은 하나의 가상 회선에서 엄격한 순서를 가정했습니다. 조각 하나가 누락되거나 손상되면 메시지 전체가 폐기되었고, 재전송은 상위 프로토콜의 몫이었습니다.
  • 1998년 RFC 2427은 멀티프로토콜 캡슐화가 널리 구현되었음을 밝히면서도, 이 알고리즘은 상호 운용 가능한 구현이 없었다고 기술하고 이를 FRF.12로 대체하며 제거했습니다.

이 평가는 RFC 1490 전체에 대한 것이 아닙니다. 1998년에 발행된RFC 2427은 자신이 대체하는 멀티프로토콜 캡슐화가 널리 구현되고 사용되었다고 설명합니다. 같은 부록에서 이 문서는RFC 1490의 조각화 알고리즘에 대해 어떤 구현도 서로 상호 운용되지 않았다고 밝힙니다. 이 메커니즘은 새 사양에서 사라지고 FRF.12에 자리를 내주었습니다. 다만 이 문서는 그 코드를 작성한 사람이 아무도 없었다고 주장하는 것이 아닙니다. 구현들이 상호 운용되지 않았다고 말할 뿐입니다. 이 구분이 이야기의 핵심입니다.

1993년의 난제는 구체적인 것이었습니다. 7월에 발행된RFC 1490은 라우팅되거나 브리징된 트래픽을 프레임 릴레이 백본 위로 운반하는 방법을 기술합니다. 네트워크에 따라 최대 프레임 크기는 262바이트까지 내려갈 수 있었습니다. 이미 캡슐화된 패킷은 이 한도를 넘을 수 있었습니다. 따라서 RFC는 조각화와 재조립을 권장하되 선택 사항으로 두었습니다. 멀티프로토콜 전송은 모든 장비 쌍이 이 특정 기능을 채택하지 않아도 동작할 수 있었습니다.

이 메커니즘의 적용 범위는 결정적이었습니다. RFC 1490의 조각화는 작은 IP 데이터그램의 연속처럼 인터넷 전체를 가로지르지 않았습니다. 프레임 릴레이 네트워크의 양 끝에 접속된 장비인 DTE에서 멈췄습니다. 송신 측은 먼저 패킷을 캡슐화한 뒤 네트워크에 맞는 프레임으로 나누었습니다. 수신 DTE는 패킷을 재조립한 후 통상의 처리로 넘겼습니다. IP 데이터그램의 크기와 식별자는 이 과정 때문에 변하지 않았습니다.

RFC 791은 IP 계층에서 이루어지는 또 다른 조각화를 기술합니다. 데이터그램이 식별자, 오프셋, 플래그를 지니고 목적지 IP가 이를 재조립합니다. 반면 RFC 1490은 이미 캡슐화된 패킷 주위에 조각화 봉투를 두고 프레임 릴레이 경계에서, 즉 운반되는 프로토콜이 처리되기 전에 재조립을 기다립니다. 두 절차 모두 데이터를 나누지만, 지시하는 네트워크 계층과 수신 주체가 다릅니다.

RFC 1490의 형식은 진행 중인 메시지의 상태를 유지해야 했습니다. 각 조각은 캡슐화 식별자, 2옥텟 시퀀스 번호, 오프셋, 마지막 조각임을 표시하는 비트를 담았습니다. 시퀀스 번호는 조각화된 새 메시지마다 증가했고, 시작 시에는 임의의 값에서 출발했습니다. 오프셋은 32옥텟 단위로 계산되었으며 첫 조각은 0에서 시작했습니다. 이 필드들은 수신자가 조각들을 식별하고 제자리에 놓고 메시지가 완결되는 시점을 알도록 하는 데 필요했습니다.

서비스 계약이 이 형식을 보완했습니다. 조각들은 오프셋 0부터 마지막 조각까지 순서대로 도착해야 했습니다. 같은 회선으로 향하는 다른 데이터가 끼어들어서는 안 되었습니다. 양 끝은 최소 2KiB를 재조립할 수 있어야 했고, 8KiB가 권장되었습니다. 조각 하나가 누락되거나 손상되면 장비는 메시지 전체를 폐기했습니다. 재전송은 상위 프로토콜의 몫이었습니다. 이 절차는 조각 단위의 재시도를 예정하지 않았습니다.

RFC는 재조립 타이머도 정의하지 않았습니다. 프레임 릴레이 서비스가 요구하는 순서 보존 전달을 근거로 들었고, 따라서 수신자가 로컬 시간 만료로 불완전한 시퀀스를 폐기 대상으로 판정할 일이 없다고 보았습니다. 이는 사양에 적힌 가정이며, 모든 운영자가 이를 준수했거나 모든 장비가 이를 활용할 수 있었다는 증거가 아닙니다. 미완성 메시지가 차지하는 메모리는 여전히 실제 부담이었고, 조각 하나의 손실은 언제나 전체를 폐기로 이끌었으며, 회복은 상위 계층의 재전송에 의존했습니다.

5년 뒤 RFC 2427은 결과를 명시적으로 분리합니다. RFC 1490의 전체 캡슐화는 섹터별 문서에 걸쳐 널리 구현되었다고 기술하면서도, 당시 조각화 알고리즘의 상호 운용 가능한 구현은 존재하지 않았다고 보고합니다. 이 문서는 이 메커니즘이 일부 프레임 릴레이 응용에는 부족하다는 지적이 있었다고 언급하며, 이를 제거하고 FRF.12를 지시합니다. 공급업체도, 패킷 추적도, 구체적 결함도 언급하지 않습니다. 근거는 결과를 이야기할 수 있게 해주지만 원인을 지어낼 수는 없게 합니다.

따라서 두 가지 지름길을 피해야 합니다. 첫째는 하나의 옵션 실패를 RFC 1490이 채택되지 않았다는 증거로 삼는 것입니다. RFC 2427은 캡슐화에 대해서는 정반대로 기술합니다. 둘째는 캡슐화의 광범위한 사용으로부터 모든 옵션이 호환되었다고 추론하는 것입니다. 같은 부록은 조각화 알고리즘이 호환되지 않았다고 단언합니다. 하나의 표준에는 여러 계약이 담깁니다. 하나는 제품 사이를 오갈 수 있지만 다른 하나는 결코 공통의 상호 운용 기반이 되지 못할 수 있습니다.

역사적 사실은 코드가 항상 문서를 이긴다는 것이 아니며, 상호 운용성 없는 옵션이 문서 전체를 무효로 만든다는 것도 아닙니다. 더 정밀한 사실은 이것입니다. “RFC 1490 호환”이라는 라벨은 운영상의 질문에 답하지 않습니다. 어떤 기능인가? 회선당 최대 크기는 얼마인가? 두 DTE가 같은 조각 형식과 같은 순서 규칙을 아는가? 메시지가 완결되는 시점을 아는가? RFC 2427은 메커니즘별로 결과를 문서화했습니다. 캡슐화에는 호환성 집합이 있었고 조각화에는 없었습니다. FRF.12로의 대체는 이 역사에 기록되어 있으되, 그 보편적 채택을 입증하지는 않습니다.