RFC 1926, 음향 IP 패킷의 사라진 종료 신호

요약

RFC 1926은 완전한 4비트 문자표, 시작 문자, 모스 변조, 일곱 개의 반송파 주파수를 정의하지만, 수신기가 한 프레임의 끝을 어떻게 인식하는지는 정의하지 않는다.
동시대의 최소 링크 사양들은 작다고 해서 암묵적이라는 뜻은 아님을 보여준다. SLIP조차 구분 문자와 이스케이프 규칙을 명시하고, PPP 프레이밍은 동기화, 투명성, 무결성, 무효 프레임 처리를 규정한다.
역사적 교훈은 음향 IP가 불가능했다는 것이 아니다. 송신자의 가역적 조리법은 수신자 상태와 실패 경계가 공유되고 검증 가능할 때에만 상호 운용 가능한 프로토콜이 된다는 것이다.

첫 비프음 다음은 무엇인가?

수신기가 시작 신호로 지정된 모스 문자b를 감지했다고 상상해 보라. 뒤이어 더 많은 문자가 온다. 각각은 16자 알파벳에 속한다. 그리고 나서 침묵이 온다.

이 침묵이 프레임을 닫는 것일까? 아니면 단지 모스 요소나 문자 사이의 간격일 뿐일까? 간섭이 다음 톤을 지워버린 것일까? 송신자가 IP 헤더 중간에 멈춘 것일까? 수신기는 지금까지 받은 것을 전달해야 할까, 기다려야 할까, 폐기해야 할까, 아니면 다음 전송을 계속 이어 붙여야 할까?

이 퍼즐은 현대 프로토콜 체크리스트에서 들여온 것이 아니다.RFC 1926 자체안의 비대칭이 만들어낸 것이다. 두 페이지짜리 메모는 송신자에게 정밀한 작은 절차를 제공한다. 데이터그램을 “network beep order”의 4비트 조각으로 나누고, 16가지 가능한 값을 모두 문자에 대응시키고, 앞에b를 붙이고, 일반 모스 부호로 안정적인 톤을 켠다. 일곱 가지 “Acoustical Signature” 주파수, 440~784 Hz 중에서 골라 여러 “Local Acoustical Network”가 공존할 수 있게 한다. 정상 동작에는 440 Hz를 사용한다.

그리고 수신 절차는 링크의 나머지 절반을 한 문장으로 압축한다. 그 과정을 거꾸로 수행하라.

역방향 처리는 문자표를 뒤집을 수 있다. 하지만 그것만으로는 수신기에 관측된 소리 중 어느 것이 하나의 유효한 문자 스트림인지 알려줄 수 없다. 문자표는 “이 문자가 어떤 4비트를 나타내는가?”라는 질문에, 프레이밍과 타이밍이 “어떤 문자가 들렸는가?”, “어떤 문자들이 이 데이터그램에 속하는가?”라는 질문에 답한 이후에만 답할 수 있다.

정확한 문서적 지위를 가진 농담

이 메모는 1996년 4월 1일자로 Informational로 표시되었다. 상태 문구는 어떤 종류의 인터넷 표준도 지정하지 않는다고 말한다.RFC Editor의 현재 목록은 이를 Independent Stream에 분류한다. 이 현재 라벨을, 1996년에 현대 스트림 절차의 모든 요소가 동일한 형태로 이미 존재했다는 증거로 거슬러 투영해서는 안 된다.

그럼에도 이 장르는 잘 문서화되어 있다.RFC 8700의 시리즈 역사는 4월 1일 RFC를 특별한 Independent Stream 관행, 즉 공식 기술 검토 및 승인 절차 없는 유머러스한 제출물로 묘사한다. 말장난은 구조적이다. ATM은 Acoustical Transmission Media가 되고, LAN은 Local Acoustical Network가 되며, AS 번호는 음악적 음높이가 된다. 이 유머는 빠진 공학이 드러날 만큼 살짝 완전해 보이는 데 기대어 작동한다.

이 지위가 중요한 이유는 RFC 번호가 아카이브 출판을 증명할 뿐 상호 운용성을 증명하지 않기 때문이다. 동결된 자료들은 RFC 1926에 대한 독립 구현, 적합성 교환, 소음 실험실 테스트, 운영 배치를 보고하지 않는다. 또한 아무도 그것으로 실험한 적이 없다는 것도 증명하지 않는다. 책임 있는 결론은 더 좁다. 문서만으로는 공통 수신자 선택을 확정하지 못한다.

최소 사양도 명시적일 수 있다

작은 실제 프로토콜과의 비교는 시사적이다.RFC 1055의 SLIP 설명은 이 프로토콜을 IP 패킷을 프레임화하는 문자열, “그 이상도 이하도 아닌 것”으로 부른다. SLIP이 주소 지정, 패킷 유형 식별, 오류 정정, 압축을 제공하지 않는다고 공개적으로 말한다. 그럼에도 END 문자를 정의하고, 데이터에 END와 ESC가 나타나면 이스케이프하며, 잡음을 플러시하기 위해 END로 시작할 것을 권고하고, 송수신 로직을 제공하며, 실용적인 최대 데이터그램 권고를 제공한다.

그것이 규율로서의 최소 사양이다. 생략된 것은 이름이 붙여지고, 양쪽 종단이 합의해야 하는 것은 명시된다.

RFC 1662의 PPP용 HDLC 유사 프레이밍은 수신자 경계를 더욱 분명하게 만든다. 플래그가 프레임의 시작 또는 끝을 표시한다. 이스케이프나 비트 스터핑은 페이로드 데이터가 플래그를 사칭하는 것을 막는다. 프레임 체크 시퀀스가 손상을 감지한다. 무효 프레임과 프레임 간 채움에 대한 처리가 정의되어 있다. 이 메커니즘들은 모든 음향 실험에 강제되는 설계 선택이 아니라, “송신자를 뒤집어라”라는 지시가 여러 독립적인 수신자 결정을 미해결로 남긴다는 증거다.

제목의 두 번째 농담에도 진지한 대조물이 있다. 실제ATM 상의 Classical IP 및 ARP는 AAL5 위의 상호 운용 가능한 환경을 정의한다. 가상 연결 가정, 기본 LLC/SNAP 캡슐화, 9180옥텟 IP MTU, 주소 결정, 마지막 셀의 PDU 종료 표시, 그리고 상위 계층이 재전송을 담당한다는 명시적 진술이 그것이다. 완전성은 모든 계층이 모든 문제를 해결한다는 뜻이 아니다. 경계와 책임 계층이 보인다는 뜻이다.

알파벳에서 운용까지의 여섯 단계

RFC 1926은 증거 사다리로 읽기 가장 쉽다.

표현은 각 니블을 문자에 대응시킨다.
변조는 문자를 키잉된 톤으로 바꾼다.
프레이밍 계약은 수신자가 하나의 데이터그램을 한정할 수 있게 한다.
무결성과 복구 규칙은 잘림, 손상, 손실, 중복을 관측 가능하게 만든다.
상호 운용성 증거는 독립적으로 만들어진 종단들이 정상 및 손상 테스트 벡터를 주고받음을 보여준다.
운영 증거는 처리량, 지연, 손실, 범위, 공존, 실패 동작을 측정한다.

이 메모는 첫 두 단계와 세 번째 단계의 열쇠 하나를 제공한다. “일반 모스 부호”라는 표현은 점 지속 시간, 허용 오차, 재동기화, 경쟁 송신자 처리를 규정하지 않는다. 일곱 개의 음높이는 가능한 공유 채널을 라벨링할 뿐 경쟁이나 충돌 복구를 정의하지 않는다. 붐비는 장소에 대한 보안 조언은 경고이지 메커니즘이 아니다.

바로 여기서Running-Code Primacy가 이후의 유용한 검증 기준이 된다. 출판은 운영 현실이 아니며, 구현, 검증, 배치, 사용이 새로운 증거를 만든다.Minimum Initial Specification은 최소가 모호함을 의미하지 않는다는 결정적 정교화를 더한다. 상호 운용에 필요한 규칙은 적더라도 엄격해야 한다.Reality Layers는 RFC, 농담, 알파벳이라는 내구성 있는 상징을, 파형이 프레임화되고 검사되고 전달되는 실행 가능한 사실과 분리한다.

이 에세이들은 그 뒤에 나왔으며 Johnny Eriksson의 의도를 기술하지 않는다. 그들은 올바른 역사적 질문을 하도록 돕는다. 여기서 이용 가능한 증거로 볼 때 RFC 1926은 배치 테스트에서 실패한 것이 아니라, 테스트를 정의하기 전에 멈춘 것이다.