요약

  • RFC 1963의 기본 Header-Last 형식은 송신자가 압축된 크기를 관찰한 뒤에야, 하나의 전송된 직렬 프레임이 다른 SDTP 패킷으로 이어져야 하는지 표시할 수 있게 했습니다.
  • 실제 분할 필드는 B와 F였습니다. E는 헤더 확장 존재 여부를 선택했고, SDTP는 시퀀스 번호를 담지 않았습니다. B/E/시퀀스는 RFC 1990의 별개 PPP 멀티링크 설계에 속했습니다.
  • Length 필드는 하나의 복합 PPP 프레임 안에 여러 SDTP 패킷을 분리할 수 있었고 Port 필드는 협상된 채널을 멀티플렉스할 수 있었지만, 어느 필드도 모든 조각이 도착했는지, 포트 라벨이 물리적 엔드포인트를 인증하는지, 애플리케이션이 복구했는지는 증명하지 못했습니다.

평범한 패킷 도식에서는 헤더가 먼저 옵니다. 헤더가 수신자에게 뒤따르는 내용을 어떻게 읽을지 알려주기 때문입니다. RFC 1963은 이 습관을 의도적으로 깨뜨렸습니다. 기본 PPP 직렬 데이터 전송 프로토콜(SDTP) 패킷은 전송된 직렬 데이터를 단말 적응 헤더보다 앞에 두고, 헤더 옥텟의 순서를 뒤집으며, 수신자가 양쪽 끝에서 읽도록 요구했습니다.

그 이유는 미학적인 것이 아니었습니다. RFC 1963은 DSU/CSU에서 동기 데이터를 압축하는 작업 이후 1996년 8월 Informational 메모로 발표되었습니다. 직렬 프레임이 압축되어 여러 SDTP 패킷으로 나뉘어야 할 수 있을 때, 송신자는 압축기가 충분한 출력을 내기 전에는 유효한 패킷 경계를 알지 못할 수 있었습니다. 적응 헤더가 먼저 온다면 송신자는 압축 크기를 알기 전에 경계를 선언해야 합니다. 헤더를 마지막에 두면 송신자는 그 크기를 관찰하고, 이 패킷이 전송된 프레임의 시작인지, 중간인지, 끝인지를 결정한 뒤, 헤더를 압축기에 넘길 수 있습니다.

이 형식은 시간을 레이아웃으로 바꾸었습니다. 데이터가 먼저 제공되고, 그 경계를 기술하는 결정은 나중에 확정됩니다. Header-First는 프레임이 SDTP 패킷에 걸쳐 나뉘지 않는 경우, 압축이 SDTP와 결합되지 않은 경우, 또는 구현의 하드웨어가 관례적 순서를 선호하는 경우를 위해 협상 가능한 상태로 남았습니다. 따라서 협상은 송신 경로에 맞는 표현을 선택하는 것이었습니다. 압축률을 보고하거나, 압축기 상태를 증명하거나, 수신자가 무엇을 재조립했는지 보여주지는 않았습니다.

SDTP에는 엄격한 진입점도 있었습니다. PPP가 먼저 네트워크 계층 프로토콜 단계에 도달해야 하고, 직렬 데이터 제어 프로토콜이 Opened에 도달해야 했습니다. 그때에야 IANA가 PPP-SDTP에 등록한 프로토콜 0x0049가 데이터를 운반할 수 있었습니다. 연관된 제어 프로토콜은 0x8049를 사용했습니다. Opened에 도달하는 것은 합의된 패킷 문법을 확립하는 것이었습니다. 이후의 패킷이 완전하고, 진짜이며, 유용하다는 것을 보장하지는 않았습니다.

기본적으로 하나의 PPP 정보 필드는 정확히 하나의 SDTP 패킷을 담았습니다. 선택적 Length 필드가 이 경제성을 바꿨습니다. SDTP의 Length-Field-Present 옵션과 RFC 1570의 LCP Compound-Frames 옵션이 모두 성공적으로 협상되면, 여러 SDTP 패킷이 하나의 PPP 정보 필드를 공유할 수 있었습니다. 각 Length 값은 자신의 Length 필드, 선택적 Port, 적응 헤더, 전송 데이터 및 홀수 비트 패딩을 포함한 길이를 커버했습니다. 1옥텟 필드는 2부터 255까지의 결합 길이를 기술했고, 2옥텟은 범위를 65535까지 늘렸으며, 0은 PPP 정보 필드의 나머지를 의미했습니다.

이것만으로 복합 컨테이너를 파싱 가능한 단위로 나눌 수 있었습니다. 그러나 협상된 맥락 밖에서 각 단위가 무엇을 의미하는지 추론하기에 충분하지 않았습니다. 인접한 두 단위는 서로 다른 조각, 프레임 또는 포트를 운반할 수 있었습니다. 정확한 Length는 파서가 어디서 멈춰야 하는지를 증명할 뿐, 원래 직렬 프레임이 최종 경계에 도달했는지, 앞선 모든 조각이 존재했는지는 증명하지 않았습니다.

Multi-Port는 또 하나의 이름공간을 추가했습니다. 이것이 없으면 모든 트래픽은 기본 포트 0으로 가고 Port 옥텟은 나타나지 않습니다. 협상이 성공하면 모든 SDTP 패킷이 포트 번호를 담습니다. 데이터 포트는 0부터 254까지였고, 255는 제어용으로 예약되어 있었습니다. 여러 구성 옵션이 포트별로 적용되었고, 포트 255의 흐름 제어 메시지는 모든 포트에 영향을 줄 수 있었습니다.

이 라벨이 유용한 이유는 양쪽 피어가 그 해석 방식에 합의했기 때문입니다. 그것은 신원 자격 증명이 아니었습니다. RFC 1963은 포트 번호를 케이블, 고객, 장치 또는 서비스에 암호학적으로 결합하지 않았습니다. 수신자는 로컬 상태에 따라 포트 7을 역다중화할 수 있었지만, 옥텟 자체만으로는 그 상태가 여전히 의도된 물리적 포트를 기술한다는 것을 증명할 수 없었습니다.

적응 헤더가 직렬 프레임의 경계를 제공했습니다. 동기 HDLC 유사 모드에서 B는 시작 조각을, F는 마지막 조각을 표시했습니다. 둘 다 설정되지 않으면 중간 조각이었고, 둘 다 설정되면 하나의 패킷에 온전한 프레임이 담긴 것이었습니다. 비동기 모드에서는 둘 다 설정되어야 했습니다. E 비트는 다른 역할을 했습니다. 선택적 CS 헤더 확장이 뒤따르는지를 말했습니다. 종료 비트가 아니었습니다.

이 구분이 중요한 이유는 익숙하지만 잘못된 축약어가 다른 프로토콜의 필드를 끌어들이기 때문입니다. RFC 1990 PPP 멀티링크는 멤버 링크 묶음 전반에서 B와 E, 그리고 12비트 또는 24비트 시퀀스 번호를 사용했습니다. RFC 1963은 그러지 않았습니다. SDTP에는 B/F, 확장용 E가 있고 시퀀스 필드가 없습니다. 시퀀스 진행으로부터 누락된 조각을 추론하는 멀티링크식 규칙도 담고 있지 않습니다.

RFC 자체가 도식을 단순히 복사하는 것이 아니라 본문을 읽어야 할 이유를 하나 드러냅니다. RFC의 B/F 표는 Begin Frame과 Final Frame 양쪽에 1,0을 인쇄하지만, 바로 위 문장은 F를 설정하면 마지막 조각이 표시된다고 말합니다. 주변 정의들은 B/F 의미론을 뒷받침합니다. 반복된 표 행은 두 번째 시작 코드의 근거가 아닙니다. 견실한 구현 기록은 그 모호성이 어떻게 처리되었는지를 보여주는 코드, 테스트 또는 패킷 트레이스가 필요할 것입니다. 이 글에는 그런 것이 없으며 어떤 구현 주장도 하지 않습니다.

더 날카로운 경계는 내부 프레임 검사에 있습니다. HDLC 유사 프레임의 경우 SDTP는 플래그 사이의 바이트만 전송했습니다. 플래그 자체는 이동하지 않았습니다. 내부 FCS는 기본적으로 함께 전송되었습니다. 협상된 FCS-Type은 대신 송신자에서 FCS를 제거하고 수신자에서 재생성할 수 있었습니다. RFC 1963은 PPP 신뢰 전송이나 다른 계층이 손실 패킷을 확실히 보고하지 않는 한 재생성을 사용해서는 안 된다고 경고했습니다. 또한 불완전하거나 손상된 프레임을 새로 생성된 정상 FCS와 함께 사용자에게 제시하는 것을 금지했습니다.

그 경고는 재구성을 둘러싼 여백입니다. B와 F는 파서에게 프레임이 시작과 끝으로 보이는 지점을 말해줍니다. Length는 SDTP 패킷이 끝나는 지점을 말해줍니다. Port는 어느 협상된 스트림이 바이트를 받는지 말해줍니다. 어느 것도 손실 통지를 제공하지 않습니다. 중간 패킷이 사라지고 다른 계층이 손실을 노출하지 않으면, 수신자는 불완전한 자료를 둘러싼 설득력 있는 경계를 가질 수 있었습니다. 새 체크섬은 그 부재를 허위 신뢰로 바꾸어 버립니다. 정확히 그 메모가 금지한 결과입니다.

RFC 1663은 별도로 협상되는 Numbered-Mode, 윈도우, 확인응답 및 재전송으로 다른 문제를 다루었습니다. RFC 1962는 압축 알고리즘 협상과 Reset 교환을 다루었습니다. 어느 메커니즘도 SDTP의 필드로 몰래 들여와서는 안 됩니다. Header-Last는 압축기의 타이밍과 협력하도록 설계된 것이지, 그 압축기를 협상하거나 상태를 복구하기 위한 것이 아니었습니다.

Lu Heng의 선언된 구조와 실행 가능한 증거 사이의 구분으로 읽어 보면, RFC 1963은 보기 드물게 솔직합니다. 작은 공유 문법을 선언합니다. 패킷 위치, 경계 비트, 선택적 범위, 포트 라벨입니다. 실행 중인 시스템은 여전히 순서대로의 도착, 손실 처리, 버퍼 정책, 로컬 포트 바인딩, FCS 처리, 사용자에게의 전달을 입증해야 합니다. 발표는 그 질문들을 정밀하게 만들 수 있습니다. 그러나 수신자를 대신하여 그 질문에 답할 수는 없습니다.

출처