요약

  • RSVP가 운반하는 객체들을 RFC 2210은 혼동하지 않았습니다:SENDER_TSPEC은 하류로 향하는 트래픽을 선언했고,ADSPEC은 하류 경로를 요약했으며,FLOWSPEC은 상류로 향하는 요청을 표현했습니다.
  • 일반 단절 비트는 최소 한 개의 요소가 RSVP와 통합 서비스(Integrated Services)를 지원하지 않음을 나타냈습니다. 이 경우 ADSPEC의 다른 모든 파라미터는 종단 간 요약으로서 신뢰할 수 없었습니다.
  • 서비스별 단절 비트는 더 구체적인 결함을 알렸습니다: RSVP를 인식하는 노드가 그 특정 서비스를 제공할 수 없다는 것입니다.
  • PATH_MTU값은 경로를 따라 그리고 병합 시에 줄어들었으며, 발신자가 처음 선언한 최대 크기 자체는 변경되지 않았습니다.
  • 자체 광고, 병합된 예약 또는 계산된 상한은 경로의 안정성, 모든 지점에서의 승인, 실제 관찰된 처리, 애플리케이션의 성공 중 어느 것도 증명하지 않았습니다.

요약은 사라지지 않고도 실패할 수 있었다

ADSPEC은 라우터 목록으로 설계되지 않았습니다.

One Pass With Advertising 모델에서 네트워크 요소들은 PATH 메시지가 수신자 쪽으로 전진하면서 합성 값들을 갱신했습니다. 그 덕분에 객체의 크기는 거의 일정하게 유지되었습니다. 수신자는 각 홉의 전체 이력 없이도 활용 가능한 요약을 얻었습니다.

이 절약에는 대가가 따랐습니다. 중간 요소가 RSVP/통합 서비스 계산에 기여할 수 없다면, 그 요약은 더 이상 전체 경로를 대표한다고 주장할 수 없었습니다. RFC 2210은 객체를 삭제하거나 모든 필드를 0으로 바꾸지 않았습니다. 대신 핵심 정보를 단절 비트에 실었습니다.

이 일반 비트가 설정되면 다른 파라미터들은 신뢰할 수 없는 것으로 규정되었습니다. 이 규칙은 그 값들의 종단 간 합성으로서의 범위에 적용되었습니다. 어떤 지역 값은 단절 이전에 정확히 계산되었을 수 있고, 다른 값은 이후에 정확히 갱신되었을 수도 있습니다. 빠져 있던 것은 그 값들을 하나의 경로 보고서로 읽는 데 필요한 연속성이었습니다.

이후의 라우터는 이 이력을 지울 수 없었습니다. 자신의 지원은 그 부재 노드를 소급적으로 참여자로 바꾸지 못했습니다. 따라서 비트는 압축 형식이 그렇지 않았다면 감추었을 한계의 흔적을 보존했습니다.

발신자는 경로를 측정하지 않았다

SENDER_TSPEC은 발신자의 것이었습니다.

이는 특히 토큰 버킷 파라미터와 최대 패킷 크기M으로 생성될 가능성이 있는 트래픽의 외피를 기술했습니다. RSVP는 이 선언을 하류 방향으로 운반했습니다. 노드들은 원래 TSpec을 자신의 관측에 맞춰 다시 쓰지 않았습니다.

이 세부 사항은 중요한 혼동을 막습니다.

TSpec은 모든 패킷이 규격 내에 유지될 것을 보증하지 않았습니다. 가용 대역폭을 측정하지도 않았습니다. 수신자가 무엇을 받아들일지 말하지도 않았습니다. 서비스 요소들이 요청을 평가할 수 있도록 트래픽의 형태를 알렸을 뿐입니다.

구현은 이후 규격 준수를 통제할 수 있었습니다. 프로필을 벗어난 패킷은 다른 처리를 받을 수 있었습니다. 그러나 이 실행상의 현실은 그다음 단계에 속했습니다. 선언은 자기 고유의 의미를 유지했습니다.

네트워크는 약속 없이 요약했다

ADSPEC은 참여하는 경로가 기록했습니다.

일반 조각에는 통합 서비스 홉 수, 경로 대역폭, 최소 지연, 합성 MTU가 들어갈 수 있었습니다. 보장 서비스(guaranteed) 조각에는 지연 상한 계산에 쓰이는 누적 오차 항들이 들어갈 수 있었습니다.

이 데이터는 수신자가 결정을 내리는 데 도움을 주었습니다. 그러나 아직 예약은 아니었습니다.

광고는 PATH 메시지가 처리된 시점의 경로에 해당했습니다. 라우팅 변경은 이 표현을 낡게 만들 수 있었습니다. 지역 자원의 변화는 승인 결정을 바꿀 수 있었습니다. 정책은 광고와 일치하는 요청이라도 거부할 수 있었습니다.

따라서 단절 없는 ADSPEC은 긍정적이지만 한정된 증거 요소였습니다: 그 메커니즘은 비트가 알려야 하는 종류의 불연속성을 기록하지 않았다는 것입니다. 미래를 보장하지는 않았습니다.

수신자가 요청하고, 그다음 네트워크가 결정했다

FLOWSPEC은 수신자에게서 나와 RESV 상태로 발신자 쪽으로 올라갔습니다.

수신자는 자신의 요구, TSpec, ADSPEC, 정책을 결합할 수 있었습니다. 보장 서비스에서는 합성 파라미터를 사용해 목표 상한과 호환되는 예약을 선택할 수 있었습니다. Controlled-Load에서는 그 서비스의 별도 정의에 따라 요청을 작성했습니다.

이 구조는 요청이지 관찰이 아니었습니다.

관련된 각 RSVP 요소는 TSpec과 FLOWSPEC을 적절한 트래픽 제어 모듈에 제시했습니다. 지역 정책과 승인 제어가 여전히 개입했습니다. 여러 예약이 병합될 수 있었습니다. 따라서 상류로 계속 올라가는 객체는 특정 수신자의 초기 요청과 달라질 수 있었습니다.

‘병합’이라는 단어는 통합된 진실이라는 인상을 줄 수 있습니다. 그것은 프로토콜과 제어의 연산을 지칭했습니다. 병합된 값은 그 지점에서 생산된 예약 상태를 설명했을 뿐, 이미 관찰된 모든 패킷의 동작을 설명하지 않았습니다.

서로 다른 두 질문을 위한 두 가지 단절

일반 비트와 서비스별 비트는 같은 영역을 다루지 않았습니다.

전자는 경로가 RSVP/통합 서비스의 일반 해석에 참여할 수 있는지를 물었습니다. 비참여 요소 하나만으로도 사슬이 끊기고 전체 요약이 신뢰할 수 없게 되었습니다.

후자는 특정 서비스가 경로의 RSVP 인식 요소들에서 이용 가능한지를 물었습니다. 라우터는 RSVP를 이해하고 객체를 처리하면서도 보장 서비스를 구현하지 않을 수 있었습니다. 이때 해당 서비스의 비트가 이 결함을 알려야 했습니다.

이 구분은 신호에 그것이 갖지 못한 능력을 부여하는 것을 막았습니다. 서비스 객체를 운반할 수 있다는 것이 그 서비스가 정의한 동작을 제공하는 것과 같지 않았습니다.

또한 모든 결함을 전반적 고장으로 해석하는 것도 막았습니다. 한 경로는 통합 서비스 메커니즘 측면에서는 일관되면서 특정 옵션은 지원하지 않을 수 있었습니다.

MTU는 세 가지 현실을 동시에 보여주었다

최대 패킷 크기는 여러 형태로 흘렀습니다.

TSpec에서M은 발신자가 생성할 수 있는 가장 큰 패킷을 표현했습니다. ADSPEC에서PATH_MTU는 요소가 더 낮은 지역 한계를 만나면 줄어들었습니다. 수신자가 여러 발신자를 고려하거나 한 지점이 여러 예약 분기를 병합할 때는 가장 작은 값이 공통 커버리지를 결정했습니다.

발신자는 자신의 원래 선언을 합성 결과와 동일하게 만들도록 수정하지 않았습니다.

이 공존은 데이터 이상이 아니었습니다. 이는 세 가지 서로 다른 질문을 보존했습니다: 발신원이 무엇을 생성할 수 있는가? 알려진 경로가 무엇을 커버할 수 있는가? 대표되는 모든 분기가 수용할 수 있는 최대 크기는 무엇인가?

RFC 2210은 이 한계에 실용적 결과를 붙였습니다. 커버되는 최대치보다 큰 패킷은 베스트 에퍼트(best effort) 처리만 받을 수 있었습니다.

따라서 예약의 존재는 플로우의 모든 패킷을 무차별적으로 예약된 것으로 분류할 근거가 되지 않았습니다. 크기는 범위의 일부였습니다.

보장 서비스 파라미터는 조건부로 남아 있었다

보장 서비스는 합성 파라미터를 추가했습니다:Ctot,Dtot,Csum,Dsum. RFC 2212의 규칙은 이들을 누적하고 트래픽 프로필과 함께 사용해 지연 상한을 도출할 수 있게 했습니다.

이 수학은 모델 안에서 보장을 검증 가능하게 만들었습니다. 그러나 모델의 가정을 제거하지는 않았습니다.

규격 내 트래픽, 지원되는 서비스, 승인된 예약, 합성 값들이 계속 적용되는 경로가 필요했습니다. 상한은 그 서비스가 정의하는 큐잉 동작에 관한 것이었습니다. 특정 패킷의 전달이나 애플리케이션 트랜잭션의 실행을 증명하지 않았습니다.

Controlled-Load는 다른 계약을 따랐습니다. 승인 제어 아래에서 규격 내 트래픽에 부하가 없는 베스트 에퍼트 네트워크에 가까운 서비스를 제공하되, 정확한 수치 지연이나 손실을 약속하지 않았습니다. 그 ADSPEC 조각은 같은 합성 항을 요구하지 않았지만, 참여 경로가 그 서비스를 제공할 수 있는지는 여전히 서비스별 비트가 말해야 했습니다.

두 서비스를 단순한 'QoS' 라벨로 취급하면 그 실질 내용이 지워졌을 것입니다.

예약 프로토콜은 서비스가 아니었다

RFC 2210은 접점의 위치에 있었습니다.

RFC 2205는 RSVP와 PATH/RESV 상태의 순환을 정의했습니다. RFC 2211과 RFC 2212는 Controlled-Load와 Guaranteed 동작을 정의했습니다. RFC 2215는 지역 및 합성 파라미터를 설명했습니다. RFC 2216은 네트워크 요소 수준의 서비스를 기술했습니다. RFC 2210은 이 세계들이 공통 객체를 어떻게 사용하는지 명확히 했습니다.

이 아키텍처는 RSVP가 자신이 전체 의미론을 소유하지 않은 내용을 운반할 수 있게 했습니다. 서비스 모듈은 신호 엔진이 불투명하게 취급하는 파라미터를 해석할 수 있었습니다.

이 분리는 의도적이었습니다: 신호는 요청 상태를 표시하고, 서비스는 처리를 정의하며, 트래픽의 관측은 여전히 또 다른 계층에 속했습니다.

보안도 같은 한계를 따랐습니다. 객체들은 스스로를 인증하지 않았습니다. 개선된 서비스 품질 접근은 형식에 맞는 FLOWSPEC의 존재만으로는 아니고 정책과 인증을 필요로 했습니다.

완전한 객체조차 여전히 증명하지 못한 것들

단절 비트 없는 ADSPEC, 유효한 FLOWSPEC, 발신자에게 도달한 병합된 예약을 가정해 봅시다.

신호가 여러 정의된 단계를 통과했다고는 말할 수 있습니다. 그러나 경로가 동일하게 유지될 것, 미래의 모든 승인이 성공할 것, 발신자가 항상 자신의 TSpec을 지킬 것, 모든 패킷이 기대된 처리를 받을 것, 텔레메트리가 상한을 확인할 것, 애플리케이션이 목표에 도달할 것은 아직 말할 수 없습니다.

이 부정들은 프로토콜의 가치를 떨어뜨리지 않습니다. 오히려 정확성을 돌려줍니다.

명세의 역할은 모든 불확실성을 없애는 것이 아닙니다. 각 객체가 정당하게 주장할 수 있는 것이 무엇인지를 정의하는 것입니다. RFC 2210은 이 정당성이 깨지는 순간까지도 인코딩한다는 점에서 주목할 만합니다.