요약

  • RFC 1663은 신뢰성 있는 전송을 하나의 PPP 링크에 대해 협상되는 선택적 속성으로 만들었습니다. Numbered Mode는 기존의 무번호 프레이밍을 한정된 순서 창, 확인 응답, 재전송 타이머, 그리고 절차가 실패했을 때 기본 모드로 돌아가는 정의된 경로로 대체했습니다.
  • 양단은 서로 다른 수신 창을 선택할 수 있었지만 같은 순서 법(modulus)을 사용해야 했습니다. Magic-Number는 누가 설정 절차를 시작할지 정했으며 어느 쪽도 인증하지 않았습니다. Numbered Mode가 이 필드들을 필요로 했기 때문에 주소·제어 필드 압축(ACFC)은 금지되었습니다.
  • 확인 응답의 경계는 정확했습니다. SABM 또는 SABME 뒤의 UA는 링크 절차를 확립했지만, 인증, 링크 품질 결정, NCP 구성, 라우팅, 애플리케이션 완료에는 여전히 각자의 근거가 필요했습니다.

하나의 데이터그램 손실이 자신보다 더 넓게 번질 수 있었다

HDLC 유사 링크 위의 일반 PPP는 패킷을 독립적인 데이터그램으로 취급했습니다. 익숙한 Address 필드는 All-Stations 주소를 가리켰고, Control 필드는 Unnumbered Information 값을 실었습니다. 손상된 프레임은 폐기할 수 있었으며, 링크 프로토콜은 평소 스트림 속에서 그 위치를 복원할 것을 약속하지 않았습니다.

그 경제성에는 인접 패킷이 상태를 공유할 때 대가가 있었습니다. RFC 1663은 압축을 중요한 사례로 지적했습니다. 송신자와 수신자가 동일한 압축 사전을 유지한다면, 압축된 데이터그램 하나를 잃는 것은 이후 데이터그램이 그대로 도착했더라도 해독 불가능하게 만들 수 있었습니다. 일부 압축 방식은 저렴하게 재설정될 수 있었습니다. 다른 방식들은 신뢰성 있고 순서가 보장된 링크 스트림의 이점을 받았습니다.

PPP 워킹 그룹은 모든 링크를 그런 스트림으로 바꾸지 않았습니다. 1994년 7월 명세는 LCP 구성 옵션 11, Numbered Mode를 통해 신뢰성 있는 전송을 선택 사항으로 만들었습니다. 한 단은 링크 설정 중에 이를 요청해야 했고, 상대는 이를 수락해야 했습니다. 기본값은 연결 없는 Unnumbered Information 그대로였습니다.

이 선택은 합의를 필요로 하는 쌍으로 한정했습니다. 최소 프레이밍을 중시하는 구현은 그대로 남을 수 있었습니다. 공유 상태 때문에 손실이 비싼 단들은 복구 루프를 추가할 수 있었습니다. 표준은 모든 링크나 모든 압축 방식이 그 비용을 치러야 한다고 선언하는 대신, 하나의 상호운용 가능한 메커니즘을 제공했습니다.

하나의 옵션이 두 개의 작은 필드를 바꿨다

Numbered Mode는 두 번째 PPP 패킷을 발명하지 않았습니다. Protocol, Information, Padding, Frame Check Sequence, 플래그는 확립된 역할을 유지했습니다. 변화는 Address와 Control 필드에서, ISO 7776 LAPB와 연관된 번호 부여 절차를 사용해 일어났습니다. 모드가 활성화되면 그 링크의 모든 프레임이 이를 사용해야 했고, 수신자는 번호 부여 프레임과 일반 UI 프레임을 마음대로 섞을 수 없었습니다.

그래서 매력적인 또 다른 최적화가 호환되지 않게 되었습니다. Address-and-Control-Field Compression은 원래 흔한ff 03쌍이 회선에서 사라지도록 허용했습니다. Numbered Mode에서 그 옥텟은 더 이상 불변의 장식이 아니었습니다. 링크 주소와 번호 부여 제어 정보를 실었기 때문입니다. RFC 1663은 따라서 단들이 ACFC를 협상하지 않도록 요구했습니다. RFC 1662는 더 넓은 규칙을 제공했습니다. 다른 Address 또는 Control 값은 사전 합의를 필요로 하며, 기본 쌍인 것처럼 압축으로 없앨 수 없습니다.

Frame Check Sequence는 바뀐 필드를 덮었습니다. 올바른 FCS는 수신된 비트가 협상된 프레이밍 규칙 아래 프레임과 일치함을 보여줄 수 있었습니다. 그러나 그 프레임이 현재 합의된 번호 부여 에포크에 속하는지는 보여줄 수 없었습니다. 상태는 여전히 중요했습니다.

창이 순서 언어를 골랐다

Numbered Mode 옵션은 1부터 127까지의 Window 값을 실었습니다. 이 값은 두 가지 연관된 한계를 담당했습니다. 수신자가 버퍼링할 의향이 있는 프레임 수와, 송신자가 확인 응답 없이 미결 상태로 둘 수 있는 프레임 수입니다. 옵션은 그래서 용량을 광고하면서 불확실성을 경계 지었습니다.

창은 또한 순서 번호 형식을 골랐습니다. 8 미만의 값은 modulo 8, 8 이상은 modulo 128을 사용했습니다. 버퍼가 다를 수 있으므로 단들은 서로 다른 창을 알릴 수 있었습니다. 그러나 다른 법으로 동작할 수는 없었습니다. 한쪽이 3비트 원에서 세는 동안 다른 쪽이 7비트 순서로 해석한다면, 그것은 더 작은 성능 불일치가 아니라 다른 회선 언어일 것입니다.

Configure-Nak은 더 작은 창은 제안할 수 있었지만 더 큰 창은 아니었습니다. 이 규칙은 제약된 수신자가 상대를 위해 메모리를 내놓지 않고 경계를 안쪽으로 당길 수 있게 했습니다. 또한 협상 응답이 상대가 제안한 적 없는 더 넓은 순서 형식으로 조용히 밀어넣는 일을 막았습니다.

같은 옵션은 HDLC 주소를 알렸습니다. 0은 사용 가능한 최종 주소가 아니며 적절한 대안과 함께 거부해야 했습니다. 동점 규칙은 충돌하는 제안을 처리했고, 창과 주소 비교로 단들을 구분할 수 없는 좁은 경우에만 무작위 선택을 사용했습니다. 여기에서조차 공유 규칙은 링크를 형성하는 데 필요한 조정만 풀었습니다. 조직적 신원을 확립하지는 않았습니다.

Magic-Number가 첫 발신자를 골랐다

Numbered Mode는 성공적인 Magic-Number 협상을 요구했습니다. LCP가 구성을 수락한 후, 수치적으로 더 작은 Magic-Number를 가진 단이 modulo 8이면 SABM, modulo 128이면 SABME를 보내 번호 부여 절차를 시작했습니다. 다른 단은 UA로 답했습니다.

이 순서는 피할 수 있는 경합을 제거했습니다. 양쪽 모두 링크 협상에 이미 있는 값들로 누가 먼저 말해야 하는지 도출할 수 있었습니다. SABM, SABME 또는 UA가 사라지면, 평소의 LCP 재시작 타이머와 카운터 매개변수가 다른 시도를 통제했습니다.

UA는 과잉 해석하기 쉽습니다. 이 교환에서 그것은 인접 단이 번호 부여 링크 설정을 수락했다는 뜻입니다. PPP 아키텍처는 여전히 인증, 링크 품질 결정, 네트워크 제어 프로토콜 구성을 데이터 링크 연결 확립 뒤에 두었습니다. 따라서 UA는 자격 증명이 수락되었거나, 링크가 품질 임계를 충족했거나, IP가 구성되었거나, 경로가 존재하거나, 어떤 원격 서비스가 요청을 받았다는 것을 증명할 수 없습니다.

Magic-Number에도 같은 규율이 필요합니다. PPP에서 그것은 단들을 구분하고 루프 걸린 링크를 감지하는 데 도움이 되었습니다. 자격 증명, 서명, 승인 주장이 아니었습니다. RFC 1663은 보안 문제를 논하지 않았습니다. 링크 신뢰성과 상대 신뢰는 하나의 값이 조정과 루프 감지에 모두 참여하더라도 별개의 질문으로 남았습니다.

실패에는 이름이 붙은 돌아갈 길이 있었다

신뢰성 메커니즘은 단들이 더 이상 그것을 공유하지 않음도 인식할 수 있을 때만 상호운용 가능합니다. RFC 1663은 절반만 번호 부여된 링크가 무한히 표류하는 대신 여러 경계를 명시했습니다.

재협상은 Numbered Mode가 아직 사용 중일 때 일어났습니다. 옵션이 다시 성공적으로 협상되지 않으면, 링크는 인증, 품질 결정, NCP 구성으로 진행하기 전에 Unnumbered Information로 돌아갔습니다. 현재 무번호 상태인 유능한 구현이 올바른 FCS의 비-UI 프레임을 받으면 Disconnected Mode(DM)로 답하고 즉시 LCP 협상을 재시작했습니다. DM을 받은 번호 부여 구현은 UI로 후퇴하고 새 LCP Configure-Request도 보냈습니다.

이 응답들은 불일치를 관측 가능하게 만들었습니다. 유효한 비트이지만 현재 제어 절차가 다른 프레임은 유효한 링크 상태로 승격되지 않았습니다. 한쪽이 기억한다는 이유만으로 번호 부여 절차가 살아남는 것도 허용되지 않았습니다.

복구 루프 자체도 경계가 있었습니다. 타이머 T1은 정보 프레임에 대한 응답을 재전송 전까지 기다리는 최대 시간을 측정했습니다. 명세는 이를 관측된 LAPB 왕복 지연에 맞춰 적응시키되, 프레임 크기·비트 전송률·처리 시간 기반의 대체 계산을 두도록 권고했습니다. T3는 링크 유휴를 표시하며 T1보다 커야 했습니다. N2는 한 프레임의 시도를 제한했고, 초과하면 링크를 종료해야 했으며, 권고 기본값은 3이었습니다.

3회 시도는 네트워크에 대한 보편적 진리가 아니었습니다. 이 특정 인접 링크 절차의 기본 경계였습니다. 운영자는 N2 소진만으로 상대가 응답을 멈춘 이유를 증명할 수 없었고, 애플리케이션은 링크 재전송 횟수를 자신의 트랜잭션 재시도 예산으로 취급할 수 없었습니다.

병렬 링크는 함축으로는 합쳐지지 않았다

이 한계는 같은 시스템들이 여러 물리 링크로 연결될 때 더 명확해집니다. PPP 링크는 기본적으로 독립적으로 확립·구성·종료되었습니다. 순서에 의존하는 압축 스트림은 다른 절차가 명시적으로 링크들을 묶지 않는 한 링크별로 남아야 했습니다.

RFC 1663은 ISO Multi-Link 주소 지정 절차를 언급했지만 그 구현을 폐기 예정으로 표시하고, 나중에 RFC 1990이 된 PPP 멀티링크 작업을 가리켰습니다. Numbered Mode와 멀티링크 시퀀싱은 관련되지만 별개의 질문에 답했습니다. 전자는 하나의 멤버 링크에서 순서 있는 전달을 복구했습니다. 후자는 단편이 여러 링크에 걸쳐 재조립되도록 번들 전체 순서 공간을 만들었습니다. 하나의 존재로부터 다른 하나를 추론해서는 안 됩니다.

이 구분은 운영적으로 유용합니다. Numbered Mode 확인 응답은 하나의 협상된 링크, 하나의 주소 배열, 하나의 법, 하나의 현재 상태에 속합니다. 물리적 인접이 무관한 것처럼 병렬 링크로, 더군다나 라우터 너머로 전송될 수 없습니다.

확인 응답이 가치 있었던 이유는 멈추었기 때문

IANA 레지스트리는 Numbered Mode에 안정적인 LCP 옵션 번호 11을 부여합니다. 그 할당 덕분에 구현들이 같은 요청을 이름으로 부릅니다. LCP Configure-Ack은 하나의 협상 에포크에 대한 정확한 값의 수락을 기록합니다. SABM 또는 SABME와 UA는 번호 부여 절차를 확립합니다. 이어지는 순서·확인 기록은 어떤 링크 프레임이 진전했고 무엇이 재전송되었는지에 대한 주장을 뒷받침합니다. DM, LCP 재시작 또는 N2 소진은 이 상태가 잃어버렸거나 버려졌음을 보여줍니다.

모든 단계가 근거이며, 어느 하나도 전체 시스템이 아닙니다. 인증 프로토콜은 신원 근거를 제공해야 합니다. 링크 품질 모니터링은 자신의 측정값과 로컬 판정을 제공해야 합니다. NCP 교환은 네트워크 계층 구성을 확립합니다. 라우팅 관측은 도달 가능성을 보여줍니다. 애플리케이션 식별자와 응답은 애플리케이션 결과를 확립합니다.

RFC 1663의 역사적 성취는 데이터가 최종 목적에 안전하게 도달했다는 보장이 아니었습니다. 더 작고 검증 가능한 계약이었습니다. 두 PPP 단이 자발적으로 신뢰성 있는 전송을 선택하면, 같은 순서 언어를 공유하고, 미결 작업을 경계 지으며, 진전을 확인하고, 상태가 어긋나면 어떻게 재시작하는지 합의한다는 것.

그 확인 응답이 상위 계층을 대변하지 못하게 함으로써, PPP는 각 계층이 자신의 근거로 판단할 여지를 보존했습니다. 링크에서 신뢰성이 더 강해진 것은 바로 그 주장이 지역적으로 유지되었기 때문입니다.

출처