요약

  • RFC 2205는 RSVP 예약을 수신자 주도의 홉바이홉 방식으로 정의했습니다. 각 노드는 여전히 자원 및 정책 검사를 통과하고, 트래픽 제어 상태를 설치하며, 일치하는 갱신 메시지로 그 상태를 유지해야 했습니다.
  • ResvConf는 종단 간 서비스의 증거가 아닙니다. 표준은 어떤 보장도 하지 않는다고 명시합니다. 방어 가능한 주장은 경로, 요청, 로컬 판단, 설치된 규칙, 갱신 에포크, 확인 범위, 측정된 데이터 플레인 결과를 결합해야 합니다.

가장 정직한 예약은 사라지는 예약이다

대시보드가 어떤 흐름이 예약되었다고 표시한다고 가정해 봅시다. 이 신호가 안심이 되는 이유는 바로 '예약'이라는 단어가 견고해 보이기 때문입니다. 그러나 RSVP에서 가장 많은 것을 드러내는 사건은 최초의 긍정적 메시지가 아니라, 일치하는 갱신이 더 이상 도착하지 않아 라우터가 상태를 삭제하는 순간입니다.

이 삭제는 부끄러운 예외가 아니라 계약 그 자체입니다. RFC 2205는 Path 및 예약 상태를 '소프트 상태(soft state)'로 기술합니다. Path와 Resv 메시지가 이를 생성하고, 이후 메시지가 이를 갱신하며, 정리 타이머가 갱신이 중단되면 이를 제거합니다. 프로토콜은 일정 범위 내의 신호 패킷 손실은 견딜 수 있지만, 어제의 요청이 오늘의 경로에 대한 영구적 권리 주장이 되도록 허용하지 않습니다.

이 설계는 시간을 증거의 일부로 만듭니다. '예약됨'이라는 상태는 수신자, 발신자 집합, 경로, 트래픽 명세, 정책 판단, 설치된 처리 방식, 마지막 일치 갱신, 만료 시한을 함께 명시하지 않으면 불완전합니다. 이러한 필드가 없으면 상태 표시는 그것을 참으로 만들던 메커니즘을 잃어버린 것입니다.

요청은 데이터와 반대 방향으로 이동한다

RSVP의 방향성은 중요합니다. 발신자는 데이터가 흐를 경로를 따라 주기적으로 Path 메시지를 하류로 보냅니다. RSVP를 지원하는 각 노드는 이전 홉을 포함한 경로 상태를 기록합니다. 그 다음 수신자는 기록된 경로 정보를 이용해 홉바이홉으로 상류로 이동하는 Resv 요청을 생성합니다.

수신자 주도 모델은 유니캐스트와 변하는 멀티캐스트 그룹을 위해 만들어졌습니다. 수신자마다 다른 서비스를 요청할 수 있고, 그 요청들은 발신자 쪽으로 이동하면서 병합될 수 있습니다. 따라서 라우터가 상류로 전달하는 요청은 자신이 받은 요청과 다를 수 있습니다. 로컬 트래픽 제어가 흐름 명세를 조정할 수 있고, 여러 하류 브랜치가 결합될 수 있기 때문입니다.

결과적으로 캡처된 Resv 패킷은 한 지점에서의 요청에 대한 증거이지 예약 전체의 지도가 아닙니다. 캡처된 Path 패킷은 한 노드에서 보이는 경로 상태를 보여줄 뿐, 역방향 신호가 관련된 모든 홉에 도달했음을 증명하지 않습니다. 허용 판단을 고려하기도 전에, 두 메시지는 분산된 대화의 서로 다른 절반을 기술하는 것입니다.

모든 홉은 두 개의 별개 질문에 답한다

각 중간 노드에서 RSVP는 요청을 허용 제어와 정책 제어에 전달합니다. 허용 제어는 충분한 자원이 있는지를 묻고, 정책 제어는 요청자에게 예약 자격이 있는지를 묻습니다. RFC 2205는 두 답변이 모두 긍정적이어야 한다고 요구합니다.

그제서야 노드는 요청된 서비스를 위해 패킷 분류기와 패킷 스케줄러, 또는 적절한 링크 계층 메커니즘을 구성합니다. RSVP는 QoS 및 정책 매개변수를 전송하지만 그 실질을 모두 해석하지는 않습니다. 그 권한은 로컬 트래픽 제어 및 관리 시스템에 남아 있습니다.

이러한 경계는 흔한 지름길을 막습니다. 충분한 용량은 허가가 아닙니다. 허가가 설치는 아닙니다. 하나의 아웃바운드 인터페이스에 설치된 것이 나머지 경로의 설치는 아닙니다. 제어 메시지가 수용되었다는 것이 실제 패킷이 분류기와 일치하고 예정된 처리를 받았음을 보여주지는 않습니다.

1997년 적용성 문서인 RFC 2208은 이 제도적 문제를 명확히 했습니다. 라우터의 처리·저장 능력, 집계, 보안, 정책 제어가 모두 배포에 영향을 미쳤습니다. 이 주의사항을 현재의 실태 조사로 바꿔서는 안 되지만, 신호 형식 하나가 예약을 둘러싼 운영 체계 전부를 제공할 수 없었던 이유를 설명합니다.

확실성을 거부하는 확인

RSVP는 수신자가 확인을 요청할 수 있게 합니다. 요청이 병합 지점에 도달했고 같거나 더 큰 예약이 이미 존재하는 경우, 노드는 해당 요청을 더 전달하지 않고 ResvConf를 반환할 수 있습니다. 이것은 이상적인 녹색 영수증처럼 보입니다.

그러나 RFC 2205는 그러한 해석을 거부합니다. ResvConf 수신은 아무런 보장도 주지 않는다고 명시합니다. 문서는 구체적인 사례를 제시합니다. 두 수신자의 요청이 병합되어, 한쪽은 확인을 받을 수 있지만 다른 쪽의 요청은 아직 일치하는 발신자에게 전파되지 않았고 실패할 수도 있습니다. ResvConf 뒤에 ResvErr가 올 수 있습니다.

안전한 진술은 더 좁습니다. 특정 노드가 자신에게 보이는 상태를 사용해 확인 요청을 처리했다는 것입니다. 이 확인은 모든 홉이 흐름을 수용했음을, 모든 분류기와 스케줄러가 요청을 반영했음을, 경로가 변하지 않았음을, 애플리케이션이 약속된 품질을 경험했음을 증명하지 않습니다.

이것은 겸손함을 위한 겸손함이 아닙니다. 하나의 긍정적 제어 플레인 이벤트가 종단 간 서비스 증명서로 둔갑하는 것을 막는 보호 장치입니다.

경로 변경은 오래된 진실의 만료를 만든다

Path와 Resv 메시지는 멱등(idempotent)합니다. 경로가 바뀌면 다음 Path 메시지가 새 경로에 상태를 만들고, 이어지는 Resv 메시지가 거기에 예약 상태를 쌓습니다. 이전 경로의 미사용 구간은 시간이 지나 만료되는 것이 허용됩니다.

명시적 PathTear와 ResvTear 메시지는 상태를 더 빨리 제거할 수 있지만, 신뢰성 있게 전달되지는 않습니다. 삭제 메시지가 유실되어도 살아남을 수 있는 이유는 임대가 만료되기 때문입니다. 따라서 RSVP의 정리 속성은 어떤 단일 삭제 메시지보다 강합니다. 갱신의 지속이 멈추면, 부재 자체가 결국 오래된 권리 주장을 철회합니다.

같은 메커니즘은 미묘한 부분 상태를 만들어냅니다. 한 노드에서 허용이 실패하면, 실패 지점 하류의 예약은 남아 있을 수 있습니다. 표준은 이를 보존하여 수신자가 경로의 일부 구간에서 서비스를 얻거나 일시적 경로 장애에서 빠르게 복구할 수 있도록 합니다. 하류 라우터는 종단 간 예약이 존재하지 않는 상황에서도 설치된 예약 상태를 정직하게 보고할 수 있습니다.

따라서 유용한 기록은 요청이 어디서 멈췄는지, 어떤 상태가 남아 있는지, 그리고 왜 그런지를 보여주어야 합니다. 분산된 경로를 하나의 불리언 값으로 축소하면 프로토콜이 다루도록 설계된 바로 그 조건이 사라집니다.

갱신 바이트를 줄인다고 영구 예약이 되지는 않는다

전체 Path·Resv 갱신은 비용이 클 수 있습니다. RFC 2961은 갱신 절감 확장을 도입했습니다. 메시지 식별자, 지정된 신호에 대한 홉별 승인, 번들링, 그리고 모든 객체를 반복하지 않고도 알려진 상태를 갱신할 수 있는 Summary Refresh 메시지입니다.

효율 개선은 갱신의 표현을 바꿀 뿐, 그 의미를 바꾸지 않습니다. Summary Refresh는 일반 Path·Resv 갱신의 동기화 속성을 보존해야 합니다. 수신자가 지정된 상태를 찾지 못하면 갱신 NACK을 반환할 수 있습니다. 메시지 승인은 신호가 도착했음을 보여주는 홉별 증거이지, 종단 간 서비스의 증명이 아닙니다.

관련된 시계들은 여전히 분리되어 있습니다. 요청에는 에포크가 있습니다. 각 노드에는 갱신 주기와 정리 기한이 있습니다. 메시지 식별자에는 에포크와 이웃 범위가 있습니다. 설치된 트래픽 제어에는 자체 버전이 있습니다. 측정된 서비스에는 관측 구간이 있습니다. 갱신을 압축해서 대역폭을 아낀다고 그 시계들이 하나로 합쳐지지는 않습니다.

진단 응답은 스냅샷이지 결과가 아니다

RFC 2745는 요청자가 RSVP 노드들로부터 경로 또는 예약 상태를 수집할 수 있도록 DREQ와 DREP 메시지를 추가했습니다. 각 홉은 진단 응답을 첨부할 수 있고, 수집된 응답은 기대한 상태가 어디에서 없거나 다른지 드러낼 수 있습니다.

그러나 진단 메커니즘에는 고유한 한계가 있습니다. 응답은 조각화될 수 있고, 오류로 일찍 끝날 수 있으며, 다른 반환 경로를 택할 수 있고, 방화벽에 막힐 수 있고, 시간 초과될 수 있습니다. 더 근본적으로, DREP는 관측 시점에 저장된 제어 상태를 보고할 뿐입니다. 스케줄러가 그 상태를 의도한 패킷에 실제로 적용했는지, 지연·손실·처리량이 애플리케이션의 필요를 충족했는지 증명하지 않습니다.

진단은 또 하나의 증인을 더한다는 점에서 가치 있습니다. 위험해지는 경우는 증인에게 관찰하지 않은 것에 대해 증언하라고 요구할 때뿐입니다.

Zhang의 기여, 관할 신화 없이

IETF Datatracker는 Lixia Zhang을 RFC 2205의 저자로 등재하고 더 넓은 프로토콜 연구 이력을 기록합니다. 그녀의 UCLA 약력은 RSVP가 Xerox PARC 재직 시절에 구상되고 개발되었다고 말합니다. RFC 2205 자체는 연구 협업과 더 큰 표준화 커뮤니티의 기여를 인정하며, Robert Braden이 Zhang, Steven Berson, Shai Herzog, Sugih Jamin과 함께 규격을 편집했습니다.

Internet Hall of Fame은 Zhang의 업적을 RSVP 및 이후의 RSVP-TE 실무와 연결합니다. 그 인정은 배포 측정이 아니며, RSVP-TE는 원래의 통합 서비스 프로토콜과 동일하지 않습니다. 증거는 공동 설계와 지속적인 기여를 뒷받침합니다. 그러나 Zhang을 단독 발명가, 현재 운영자, IETF 합의의 소유자, 또는 어떤 살아 있는 서비스의 보증인으로 만들지는 않습니다.

이 귀속 경계는 프로토콜 자체를 닮았습니다. 저자는 메시지를 명세하는 데 기여할 수 있습니다. 수신자는 무엇을 요청할지 선택합니다. 라우팅은 경로를 선택합니다. 각 도메인은 허용과 정책을 적용합니다. 장비는 로컬 상태를 설치합니다. 운영은 성능을 관측합니다. 한 사람의 이름이 역사에 인간적 중심을 부여하더라도, 권한은 분산된 채로 남습니다.

한 단어를 위한 일곱 장의 영수증

'예약됨'이라는 단어는 일곱 가지 기록을 결합할 수 있을 때 방어 가능해집니다.

첫째는 경로 영수증입니다. 발신자, 세션, 경로, 이전 홉 상태, 시각. 둘째는 요청 영수증입니다. 수신자, 정확한 Resv 내용, 흐름 및 필터 명세, 확인 요청, 에포크. 셋째는 권한 영수증입니다. 각 관련 홉에서의 허용 및 정책 판단.

넷째는 설치입니다. 분류기·스케줄러 대상, 트랜잭션 결과, 구성 판독값. 다섯째는 갱신입니다. 갱신 주기, 마지막 일치 갱신, 정리 기한, Summary Refresh 식별자, 그리고 발생한 NACK. 여섯째는 ResvConf 또는 DREP의 범위입니다. 어떤 노드가, 어떤 상태에 대해, 언제 말했는가. 일곱째는 결과입니다. 실제 데이터 경로와 유한한 구간 동안 측정된 서비스.

어떤 한 영수증도 다른 영수증을 격상시키지 못합니다. 함께 모일 때 비로소 정밀한 주장이 성립합니다. 특정 수신자가 정의된 흐름에 대한 처리를 요청했고, 이름이 밝혀진 노드들이 명시된 정책 아래 이를 수용하고 명시된 제어를 설치한 후 알려진 갱신 에포크 동안 유지했으며, 관측된 트래픽이 측정된 결과를 받았다는 주장입니다. 이 결론은 시간을 초월한 녹색 배지보다 좁습니다. 그리고 훨씬 더 유용합니다.

출처