요약

  • RFC 1989는 공통 링크 품질 보고 메커니즘을 로컬 정책에서 분리했습니다. 각 엔드포인트는 자체 기준과 대응 규칙으로 사용 가능 여부를 판단하면서 양방향의 손실을 도출할 수 있었습니다.
  • LQR은 전송되어 나간 관측값, 수신 시 저장된 값, 피어가 돌려보낸 값을 포함하는 누적 패킷·옥텟·보고 카운터를 사용했습니다. 델타 덕분에 두 관점이 비교 가능해졌고, 정밀한 계산 규칙이 서로 다른 하드웨어와 프레이밍 구현 간 정합성을 유지했습니다.
  • 보고서는 판정이 아니라 증거였습니다. 방향은 독립적으로 협상될 수 있었고, 카운터는 랩(wrap)할 수 있었으며, Magic-Number는 루프백 감지를 보조할 뿐이었고, 보안은 규정되지 않았으며, 품질 저하에서의 복구는 의도적으로 구현에 맡겨졌습니다.

캐리어가 정상이어도 링크는 불량할 수 있었다

물리적 캐리어는 존재합니다. PPP는 Opened 상태에 도달했습니다. 그럼에도 패킷이 라우터가 다른 경로를 선호하거나 회선을 재접속하거나 네트워크 계층 트래픽을 중단할 만큼 자주 사라집니다. 이 링크가 더 이상 사용할 수 없게 되었다는 것을 어떤 관측이 증명할까요?

PPP는 하나의 보편적인 백분율로 답하지 않았습니다. 1992년 5월 RFC 1333이 링크 품질 모니터링(Link Quality Monitoring)을 기술했고, 1996년 8월 RFC 1989가 이를 대체했습니다. 후속 사양은 개별 카운터보다 더 중요한 설계 경계로 시작합니다. 이 문서는 메커니즘을 완전히 정의하지만, 품질을 판단하고 그에 대한 조치를 결정하는 정책은 정의하지 않습니다.

이러한 거부는 중앙 권위가 수습해야 할 누락이 아니었습니다. 링크마다 서로 다른 트래픽을 실었고, 비용도, 대안도 달랐습니다. 2퍼센트의 패킷 손실률은 어떤 서비스에는 견딜 수 없지만 다른 서비스에는 견딜 수 있는 수준일 수 있습니다. 공통의 문제는 더 좁았습니다. 독립적으로 개발된 두 PPP 구현이, 운영자가 그 결과에서 서로 다른 결정을 내리더라도, 각 방향으로 무엇이 지나갔는지 비교 가능한 기록을 필요로 했다는 점입니다.

링크 품질 보고서(Link-Quality-Report, LQR)가 바로 그 기록이 되었습니다. LQR은 증거가 판단을 없애 준다고 가장하지 않으면서 증거를 상호 운용 가능하게 만들었습니다.

한쪽이 다른 쪽에게 보고를 요청했다

링크 품질 모니터링은 선택 사항이었고 기본적으로 비활성화되어 있었습니다. 보고서를 원하는 엔드포인트는 LCP 구성 옵션 타입 4(Quality-Protocol)를 Configure-Request에 담았습니다. LQR의 경우 프로토콜 값은 16진수 c025였습니다. 이 옵션을 확인(acknowledge)한 피어는 해당 프로토콜을 보내기로 합의한 것입니다.

이 문법은 방향성을 지닙니다. 요청자는 실질적으로 “모니터링 정보를 보내 달라”고 말합니다. 동시에 같은 정보를 돌려보내겠다고 약속하지는 않습니다. PPP는 두 방향을 독립적으로 협상할 수 있게 했고, RFC 1661은 반대 방향에 서로 다른 품질 프로토콜을 허용하기까지 했습니다. 다만 어떤 구현이든 LQR을 보내기로 합의했다면, 요청하지 않았거나 로컬 모니터링 정책을 채택하지 않았더라도 들어오는 LQR을 올바르게 처리해야 했습니다.

LQR의 경우 이 옵션은 4옥텟의 Reporting-Period를 추가했습니다. 이 값은 보고 사이의 최대 간격을 1/100초 단위로 표현했으며, 피어는 더 빨리 보고할 수 있었습니다. 값이 0이면 타이머가 아니라 응답 패턴을 선택합니다. LQR이 도착하면 즉시 하나를 보내는 것입니다. 협상이 양쪽이 0을 선택하고 서로를 영원히 기다리는 상황을 막았습니다.

이것은 자발적 조율의 간결한 예입니다. 엔드포인트가 요청하고 피어가 동의하기 전까지는 어떤 LQR도 나타나지 않습니다. 합의된 이후에는 프로토콜 c025와 보고 주기 규칙이 공유 의무를 형성합니다. 피어가 나중에 LQR에 대해 Protocol-Reject를 돌려보내면 발신자는 중단해야 합니다. 회선 상태는 무엇이 협상되고 관측되었는지를 증명하지만, 어느 운영자가 왜 그것을 원했는지는 증명하지 않습니다.

보고서는 하나의 양방향 링크에 대한 두 관점을 담았다

LQR 필드 이름은 보고서를 요청한 수신자를 기준으로 합니다. 패킷에는 발신자의 현재 누계 이상이 담겨 있습니다. 두 측정 지점 사이의 작은 확인(acknowledgement) 사슬을 운반합니다.

PeerOutPackets,PeerOutOctets,PeerOutLQRs는 발신자의 현재 송신 카운터를 기술합니다. 수신 시 로컬 구현은 논리적으로SaveInPackets,SaveInOctets, 폐기 및 오류 카운터, 그리고SaveInLQRs를 뒤에 붙입니다. 이 SaveIn 값들은 인바운드 링크로 전송된 비트가 아니라, 수신 프로세스가 그 시점에 관측한 것을 담습니다.

이후 반대 방향의 보고서에서 저장된 수신 관측값은PeerIn...값으로 돌아옵니다.LastOut...은 차례로 로컬 엔드포인트 자신의 이전 송신 누계에 대해 가장 최근에 수신한 기록을 반영합니다. 따라서 한 보고서는 자신이 보냈다고 말하는 것과 피어가 이전에 수신했다고 말한 것을 비교하면서 동시에, 피어가 보냈다고 말하는 것과 로컬에 도달한 것을 비교하게 해 줍니다.

이것은 패킷 하나하나에 대한 거래 영수증이 아닙니다. 누적 카운터에 의한 조정(reconciliation)입니다. 연속된 보고서를 빼면 델타가 나옵니다.PeerInPackets의 변화를LastOutPackets의 변화와 비교하면 송신 절반의 손실을 추정할 수 있고,SaveInPackets와PeerOutPackets가 수신 절반에 대해 같은 역할을 합니다. 옥텟 델타는 또 하나의 관점을 제공합니다. 피어의 폐기 및 오류 델타는 손실이 물리 경로가 아니라 혼잡한 수신 시스템에서 발생했는지를 시사할 수 있습니다.

“시사한다”는 표현이 중요합니다. 카운터는 설명을 제약할 뿐, 그것을 인증하거나 단일 원인을 증명하지 않습니다.

계산은 서로 다른 프레이밍 장비 속에서도 살아남아야 했다

두 제품이 모든 필드 이름에 합의하더라도 서로 다른 물리적 표현을 세면 결과가 갈릴 수 있었습니다. 어느 한쪽은 PPP 프레이밍을 주 프로세스에서 구현할 수 있고, 다른 쪽은 이스케이핑을 숨기는 모뎀이나 변환기, 하드웨어 장치를 사용할 수 있습니다. 그래서 RFC 1989는 구현에 로컬 바이트 카운터가 우연히 보여 주는 값을 보고하라고 요구하는 대신 기준점(reference point)을 지정했습니다.

프레임 검사 시퀀스(Frame Check Sequence)가 커버하는 옥텟이 셈에 포함됩니다. FCS 자체도 세며, 프레임당 플래그 옥텟 하나도 셉니다. 추가 플래그 시퀀스와 이스케이프 비트나 옥텟은 포함되지 않습니다. 의도는 소비되는 모든 물리 심볼이나 총 대역폭을 측정하는 것이 아니라 링크를 통과하는 정보를 재현 가능한 방식으로 나타내는 것입니다.InGoodOctets는 폐기 또는 오류로 계산된 프레임의 내용물을 제외합니다.

보고서에는 그 보고서 자체가 기여할 것으로 예상되는 패킷과 옥텟이 포함됩니다. 카운터는 단조 증가하지만 32비트 필드는 결국 0으로 랩(wrap)하므로, 올바른 델타 계산은 랩을 인식해야 합니다. 일부 인터페이스 카운터는 LCP가 수립 단계에 들어가도 공통 값으로 재설정되지 않습니다. 보편적인 시작점이 아니라 상대적 변화가 동기화를 제공합니다.

이런 세부 사항은 사건의 귀결이 여기에 걸리기 전까지는 관료적인 것처럼 보입니다. 한 엔드포인트가 이스케이프된 옥텟을 세고 다른 쪽이 세지 않으면, 그 차이는 손실과 흡사해 보입니다. 분석가가 랩을 넘어 일반적인 부호 있는 산술로 빼면, 건강한 구간이 거대한 음수 사건으로 변합니다. 상호 운용성에는 숫자를 교환하는 것만으로 부족했고, 그 숫자가 무엇을 뜻하는지에 대한 합의가 필요했습니다.

더 빨리 보고하는 것은 더 빨리 아는 것이 아니었다

LQR 패킷은 증거가 평범한 트래픽 뒤에 놓이지 않도록 최고 다중화 우선순위를 받았습니다. 그럼에도 보고 주기는 정책적 절충의 대상이었습니다. 좋은 링크에서 LQR은 불필요하며, 최대 간격은 활성 트래픽에 최대한 방해가 되지 않아야 합니다. 손실이 많은 링크에서는 긴 간격이 변동을 평활하지만 완전한 장애는 더 늦게 감지합니다.

비대칭성은 단순한 타이머 논리를 위험하게 만듭니다. 들어오는 보고서가 도착하여 송신 쪽이 매우 불량하다고 보여 줄 때, 로컬 보고서를 더 빨리 보내도 그 보고서들이 피어로 가는 길에서 잃어버릴 가능성이 크다면 도움이 되지 않습니다. 송신 쪽은 양호하지만 수신 쪽이 불량하다면, 더 잦은 시도가 일부 보고서가 도착할 기회를 주고 피어가 자기만의 관점을 형성하는 데 도움이 될 수 있습니다.

RFC 1989는 한 샘플로 판정하는 것을 거부했습니다. 보고서가 제시간에 도착하지 않거나, 받은 보고서가 정말 불량한 링크를 시사할 때는 최소한 하나의 추가 LQR을 보내야 합니다. 알고리즘적 결정에는 최소 두 번의 왕복 주기가 필요합니다. 보고서 부재는 지속적인 장애가 아니라 일시적 부하나 잃어버린 보고서를 반영할 수 있기 때문입니다.

문서는 히스테리시스를 제안하고 하나의 예로 N 중 K(K-out-of-N) 정책을 제시했습니다. 그러나 어느 쪽도 프로토콜로 만들지 않았습니다. 복구도 표준화하지 않았습니다. 어떤 구현은 LQR을 계속 보내면서 네트워크 제어 프로토콜(NCP)을 닫았다가 품질이 회복되면 다시 열 수 있고, 다른 구현은 경로를 전환하거나 연결을 끊을 수 있습니다. 비교 가능한 증거가 동일한 결과를 요구하지는 않았습니다.

카운터 보고서는 신뢰 프로토콜이 아니었다

LQR은 해당 옵션이 협상되었을 때 Magic-Number를 담았습니다. 들어오는 보고서에서 자신의 Magic-Number를 발견하면 루프백된 링크를 드러낼 수 있습니다. 협상이 없으면 이 필드는 0이고 무시됩니다. 이것은 PPP의 더 넓은 Magic-Number 메커니즘과 동일한 경계를 지켰습니다. 어떤 값은 배선이나 데이터 링크 이상을 감지하는 데 도움이 될 수 있지만, 사람이나 장치, 조직을 인증하지는 않습니다.

RFC 1989는 보안 문제를 논의하지 않는다고 명시합니다. 보고서에 대한 암호학적 무결성도, 보고하는 피어에 대한 독립 자격 증명도 정의하지 않습니다. 인증은 PPP의 인증 단계와 거기서 협상된 프로토콜에 속했습니다. 어떤 지점에서 관측된 LQR은 c025 형식의 보고서가 그 지점에 도달했다는 것을 증명할 뿐이며, 그 카운터 값들은 해당 링크의 신뢰 및 포획 조건 안에서의 주장으로 남습니다.

따라서 운영 기록은 여러 층을 보존해야 합니다. LCP 요청과 확인, 보고 주기, 실제 보고 도착 시각, 원시 카운터 값, 랩 처리, 계산된 델타, 로컬 기준, 정책 결과 및 후속 조치를 함께 보관하십시오. 이 사슬을 하나의 “링크 불량” 타임스탬프로 압축하지 마십시오. 보고서에는 그 판정이 담겨 있지 않았습니다.

최소 메커니즘은 정책을 돌릴 여지를 남겼다

PPP 링크 품질 모니터링이 중요한 이유는 피어들이 반드시 공유해야 하는 부분을 정확히 표준화했기 때문입니다. 이 프로토콜은 보고서를 어떻게 요청하는지, 피어가 최대 얼마나 자주 보고해야 하는지, 측정이 어디에서 이루어지는지, 양방향이 어떻게 표현되는지, 누적 관점이 어떻게 조정되는지를 고정했습니다. 그리고 운영자가 서비스에 어떤 품질을 요구하고 자신의 토폴로지가 어떤 처방을 지탱할 수 있는지 결정할 자유를 남겼습니다.

이런 배치는 상호 운용성을 희생하지 않고 실험을 가능하게 했습니다. 두 엔드포인트는 서로 다른 N 중 K 윈도우, 기준 또는 복구 절차를 운영하면서도 같은 LQR을 이해할 수 있었습니다. 이후의 구현은 더 엄격한 정책을 선택하기 위해 중앙 결정자의 허가가 필요하지 않았습니다. 협상된 공통 메커니즘을 지키기만 하면 되었습니다.

증거의 사다리는 여전히 좁습니다. IANA의 c025 할당은 패킷 유형을 식별합니다. Configure-Ack은 그 시점에 피어가 보고 의무를 수락했음을 증명합니다. 카운터 델타는 손실 추정을 뒷받침합니다. 폐기와 오류는 가설을 정교하게 합니다. 그 관측값을 사용 가능성 결정으로 바꾸는 것은 오로지 로컬 정책이며, 그 결과물을 확립하는 것은 오로지 이후의 라우팅, NCP, 링크 및 애플리케이션 증거입니다.

이 보고서는 불일치를 판독 가능하게 만들 수 있었습니다. 불일치를 폐지할 권한은 결코 갖지 못했습니다.

출처