요약

  • RFC 3153은 PPP 수신 측이 한 방향으로 멀티플렉싱된 프레임을 수용할 것을 제안할 수 있게 했습니다. PPPMuxCP 교환이 성공하면 송신 측이 해당 형식을 사용할 수는 있었지만, 실제 멀티플렉싱된 프레임을 하나라도 보내도록 요구하지는 않았습니다.
  • 협상된 기본 PID는 생략된 프로토콜 식별자를 어떻게 복원할지 정의했습니다. 그렇다고 송신 측이 PFF를 0으로 지웠거나 필드를 생략했거나 바이트를 절약했다는 증거가 되지는 않습니다.
  • 실제 이득은 송출된 서브프레임, 트래픽 구성, 큐 타이밍, MRU 및 크기 제한, 오류 동작, 계층 순서에 따라 달라졌습니다. 기능, 회선 사용, 패킷 복원, 애플리케이션 결과는 각각 별도의 증거를 필요로 합니다.

이 협약은 페이로드가 아니라 봉투에 관한 것이었다

작은 패킷은 프레이밍에 불균형적으로 많은 바이트를 소모할 수 있습니다. HDLC 계열 프레이밍의 PPP는 각 패킷을 링크 자료, 프로토콜 필드, 프레임 체크 시퀀스로 감쌉니다. 일부 필드 자체는 협상으로 없애거나 압축할 수 있지만, RFC 3153은 개별 캡슐화된 패킷들이 여전히 오버헤드를 지불한다고 지적했습니다. PPP가 L2TP 같은 터널을 통해 운반될 때는 반복 비용이 다시 커질 수 있습니다.

제안은 단순했습니다. 여러 PPP 패킷을 하나의 외부 PPP 프레임에 담는 것입니다. 각 서브프레임 앞의 압축된 구분자가 수신 측에 프로토콜 식별자가 존재하는지, 해당 서브프레임이 몇 바이트인지 알려줍니다. 하나의 외부 프레임이 그렇지 않으면 각자 완전한 봉투가 필요했던 페이로드들을 함께 운반할 수 있습니다.

이 계산은 시간을 배제할 때만 자동적으로 들립니다. 송신 측은 아직 도착하지 않은 패킷을 결합할 수 없습니다. 또 하나의 적격 서브프레임을 기다리는 것은 결과 프레임이 패킷당 오버헤드를 줄이더라도 지연을 늘릴 수 있습니다. RFC 3153은 이를 명시적으로 말합니다. 구현자는 집합물이 커질 때 멀티플렉싱·역멀티플렉싱 지연과 프레이밍 효율의 균형을 맞추어야 합니다.

따라서 표준은 "작은 패킷이 빨라진다"고 약속하지 않았습니다. 형식과, 그 절충을 가능하게 하는 충분한 현지 선택권을 제공했을 뿐입니다. 절약된 바이트 수, 대기 시간, 직렬화 간격, 외부 프레임 손실, 하류 효과는 관찰 대상으로 남았습니다.

수신 측은 언어를 제안했고, 송신 측은 그것을 사용할지 선택했다

PPPMuxCP는 이 옵션의 제어 프로토콜입니다. 네트워크 제어 프로토콜(NCP) 단계에서 수신 측은 PPP 멀티플렉싱 프레임을 수용할 것임을 광고할 수 있습니다. 그 제안 없이 피어는 그런 프레임을 송신할 수 없습니다. 수신 지원은 각 방향마다 독립적으로 협상되므로, 한쪽의 성공적인 협상은 반대 경로에 대해 아무것도 말해주지 않습니다.

가장 중요한 것은, 성공이 송신을 강제하지 않는다는 점입니다. RFC는 PPPMuxCP가 협상된 후에도 피어가 멀티플렉싱 프레임을 보낼 의무가 없다고 명시합니다. 어떤 PPP 프레임을 집합할지 선택할 수 있고, 적격 패킷을 개별적으로 보낼 수도 있습니다.

그래서 "활성화됨" 플래그는 불완전한 역사 기록입니다. 그 한 단어는 수신 측이 형식을 제안했음을, 교환이 열린 상태에 도달했음을, 기본값이 수용되었음을, 송신 측이 정책을 설정했음을, 멀티플렉싱 데이터가 링크에 나타났음을, 혹은 단지 관리 인터페이스가 그 모든 조건을 한 단어로 합쳤음을 의미할 수 있습니다.

방어 가능한 감사는 방향을 명시합니다. 누가 수신을 제안했는지, 어떤 Configure 메시지가 확인 응답되었는지, 상태가 언제 사용 가능해졌는지, 그 방향에서 PPP 멀티플렉싱 프레임 프로토콜 값의 프레임이 이후 나타났는지를 기록합니다. 제어 평면의 허가와 데이터 평면의 사용은 결합된 증거이지 동의어가 아닙니다.

기본 PID는 비트가 실제로 지워지기 전까지 아무것도 절약하지 않았다

모든 PPPMuxCP 협상에는 기본 프로토콜 식별자가 포함됩니다. 수신 측은 첫 서브프레임이 프로토콜 필드를 생략할 경우 가정할 값을 제안합니다. 첫 패킷이 그 프로토콜을 사용한다면, 송신 측은 프로토콜 필드 플래그(PFF)를 지우고 통상적인 PPP 프로토콜 필드 압축에 따라 한두 바이트를 생략할 수 있습니다.

"할 수 있습니다"가 메커니즘을 담고 있습니다. 기본값이 허용하더라도 송신 측은 필드를 제거할 의무가 없습니다. 개수에 대한 합의는 복원 규칙을 확립할 뿐, PFF가 0이었거나 필드가 없었거나 약속된 바이트 절약이 발생했다는 증거가 아닙니다.

이후 서브프레임도 같은 방식으로 반복되는 프로토콜 식별자를 생략할 수 있습니다. 송신 측은Last_PID에 최신 명시 값을 추적하고, 수신 측은Last_rcvd_PID를 유지합니다. PFF가 설정된 서브프레임은 새 프로토콜 식별자를 실어 상태를 갱신하고, PFF가 지워진 서브프레임은 현재 값을 상속합니다. 멀티플렉싱 프레임의 시작에서 양쪽은 협상된 기본값으로부터 상태를 도출합니다.

작은 상태지만 여전히 상태입니다. 캡처는 구분자, PFF, 프로토콜 필드를 순서대로 파싱해야 합니다. 설정된 기본값을 세는 것은 대체가 되지 않습니다. 외부 프레임만 세는 것도 불충분합니다. 두 구현이 같은 수의 집합물을 송출하면서 서로 다른 필드 생략 선택을 할 수 있습니다.

길이 필드는 효율을 국지적이고 유계한 결정으로 만들었다

각 구분자는 LXT와 LEN도 실고 있습니다. LXT는 1바이트 또는 2바이트 길이 필드를 선택하며, 나머지 비트가 서브프레임 크기를 기술합니다. RFC 3153의 예시 송신 측은 구성 가능한 최대 서브프레임 길이MAX_SF_LEN을 사용하고, 이를 초과하는 후보를 거부합니다. 또한 집합물 전체가 LCP를 통해 협상된 MRU를 초과하기 전에 멈춥니다.

세 번째 자연스러운 정지점은 빈 큐입니다. 구현은 타이머를 두어 불완전한 집합물이 다른 패킷을 무한히 기다리지 않게 할 수 있습니다. RFC는 또한 운영자가 지연 및 패킷 오류 사유로 멀티플렉싱 패킷을 MRU보다 상당히 작게 유지할 수 있다고 언급합니다.

이 규칙들은 "가능한 한 가득 채운다"가 설계에 대한 빈약한 서술임을 만듭니다. 더 큰 컨테이너는 외부 오버헤드를 더 많이 상쇄할 수 있습니다. 그러나 송신 측이 기다리는 동안 가장 이른 서브프레임을 지연시킬 수도 있고, 손상되거나 잃어버린 외부 프레임 하나가 더 많은 내부 패킷에 영향을 줄 수도 있습니다. 적절한 경계는 링크 속도, 오류율, 트래픽 버스트성, 프로토콜 구성, 큐 깊이, 애플리케이션의 지연 민감도에 따라 바뀝니다.

따라서 MRU는 성능 권고가 아니라 엄격한 상한입니다.MAX_SF_LEN은 측정된 최적값이 아니라 적격성 제어입니다. 타이머는 피어의 수신 제안의 일부가 아니라 현지 정책입니다. 각각은 서로 다른 증거에 속합니다.

역멀티플렉싱은 순서를 바꾸지 않고 패킷을 복원해야 했다

프로토콜 값0x0059로 표시된 외부 프레임을 받으면 디코더는 그 서브프레임들을 순서대로 훑습니다. 각 길이를 읽고, 프로토콜 식별자를 얻거나 재구성하고, 복원된 패킷을 통상 PPP 처리에 넘깁니다. 길이가 남은 데이터보다 많다고 주장하면 마지막 서브프레임은 폐기됩니다. 문제의 값은 그 서브프레임 또는 파싱 도중 이전에 나타났을 수 있습니다.

이 형식은 자기 안에 중첩될 수 없습니다. LCP 프레임은 멀티플렉싱 프레임 안에 두어서는 안 됩니다. 그리고 독립 패킷과 멀티플렉싱 패킷을 섞는 것이 재정렬을 허가하지 않습니다. RFC는 송신·수신 어느 쪽도 컨테이너 선택과 무관하게 패킷 순서를 바꿔서는 안 된다고 말합니다.

이 요구사항은 요약 카운터에서 쉽게 잃어버립니다. "서브프레임 3개 디코딩됨"은 집합물 전후의 독립 프레임에 대해 그것들이 어떤 위치에 있었는지 입증하지 못합니다. 유용한 추적은 외부 도착 순서, 구분자 경계, 재구성된 프로토콜 상태, 수신 측이 각 복원 패킷을 전달한 순서를 보존합니다.

복원은 여전히 애플리케이션 전달이 아닙니다. 디코더는 이후 계층이 폐기하거나 지연시키거나 변형하는 구문적으로 유효한 PPP 패킷을 만들어낼 수 있습니다. 링크 증거는 하류 관찰과 결합되어야지 종단 간 결과로 승격되어서는 안 됩니다.

스택 순서는 구현 세부가 아니라 프로토콜의 일부였다

PPPMux는 홀로 존재하지 않았습니다. 멀티링크 PPP와 함께라면 옵션은 각 멤버 링크가 아니라 번들에 대해 협상됩니다. 송신 시 멀티플렉싱은 멀티링크 캡슐화 전에 일어나므로 MP 헤더가 PPPMux 헤더 바깥에 위치합니다. 멀티링크 프레임 자체를 멀티플렉싱 서브프레임으로 운반해서는 안 됩니다.

압축과 암호화 제어는 또 다른 순서 제약을 더합니다. PPP 멀티플렉싱은 번들 수준 CCP 또는 ECP 처리 후에, MP와 어떤 링크별 CCP 또는 ECP 전에 실행됩니다. PPPMux를 링크별 형식 위에 배치할 수 없는 구현은 멀티플렉싱이 협상되었을 때 그 링크별 프로토콜을 거부해야 합니다.

이들은 아키텍처 도표의 상자에 그치지 않습니다. 각 기능이 어떤 바이트를 보는지, 두 피어가 같은 시퀀스를 재구성하는지를 결정합니다. 두 장치가 PPPMux, 멀티링크, 압축, 암호화 지원을 각각 주장하면서도 호환 가능한 순서로 결합하지 못할 수 있습니다.

따라서 증거는 캡처가 취해진 계층을 식별해야 합니다. MP 이전 추적과 멤버 링크의 추적은 상호 교환 가능하지 않습니다. ECP에 대한 제어 확인 응답은 특정 집합물 주변에서 암호화가 활성이었음을 증명하지 않습니다. 기능 목록은 실행 순서가 아닙니다.

"추가 보안 고려사항 없음"은 보안 속성이 아니었다

RFC 3153은 PPP와 PPP 헤더 압축 방식에 적용되는 고려사항 외에 추가 보안 고려사항을 도입하지 않는다고 말합니다. 그 문장은 문서가 도입하는 것의 범위를 규정합니다. PPPMux에 인증, 무결성, 기밀성, 재전송 방지를 부여하지 않습니다.

ECP 순서 규칙의 존재가 ECP가 협상되었거나 그 보호가 성공했다는 증거도 아닙니다. 잘못된 서브프레임 길이, 파서 불일치, 재구성 상태의 상실은 멀티플렉싱 RFC가 발명한 새 위협 유형이 아니더라도 운영적으로 중요할 수 있습니다.

보안 주장은 자체 증거를 필요로 합니다. PPP 인증 상태, 암호화 협상, 관찰 가능한 곳의 키와 알고리즘, 프레임 무결성, 거부 동작, 이후 계층에 미치는 효과입니다. 멀티플렉싱 프레임을 수용한 파서는 신뢰가 아니라 형식 처리를 입증한 것입니다.

허가는 최소 공통 계층이었고, 이득은 국지적이며 측정 가능하게 남았다

RFC 3153의 설계는 상호운용성과 의무적 최적화를 혼동하지 않았다는 점에서 시사적입니다. 수신 측이 자신이 디코드할 의사를 가진 형식을 통제했습니다. 송신 측은 그 허가를 현재 트래픽과 현지 정책에 따라 사용할 수 있었습니다. 결정론적 플래그와 길이 규칙이 회선 형식을 상호운용 가능하게 만들었고, 큐와 타이밍 선택은 링크를 운영하는 참여자에게 남았습니다.

그것은 패킷 규모의 자발적 채택입니다. 적격 프레임을 집합하지 않는다고 피어가 규격 위반이 되지는 않았습니다. 수신 측의 제안 없이 집합물을 보내는 것은 위반이었습니다. 공통 계층이 호환성 경계를 정의했고, 실행 중인 코드가 언제 그 경계를 넘을지 결정했습니다.

이 구분은 역사적 진실을 보호합니다. 협상 로그는 옵션이 사용 가능했음을 입증할 수 있습니다. 패킷 캡처는 집합물이 송출되었고 필드가 어떻게 인코딩되었는지를 입증할 수 있습니다. 수신 측 추적은 복원을 입증할 수 있습니다. 짝지은 측정은 절약된 바이트와 새로 생긴 대기를 추정할 수 있습니다. 애플리케이션이 이득을 봤는지는 하류 시스템만이 보여줄 수 있습니다.

오래 남을 교훈은 멀티플렉싱이 항상 이긴다는 것이 아닙니다. 프로토콜은 발생했다고 주장하지 않으면서 최적화를 가능하게 할 수 있다는 것입니다. RFC 3153은 수신 측에 "이것을 이해할 수 있습니다"라고 말할 방법을 주었습니다. "사용했는가, 그리고 도움이 되었는가"라는 질문은 송신 측과 증거에 남겨두었습니다.

출처