요약

  • 요약 갱신(summary refresh)은 이미 전체로 광고된 Path 또는 Resv 상태를 이름으로 지정합니다. 이는 알려진 설명을 갱신할 뿐이며, 오래된 식별자를 반복한다고 해서 새로운 예약이나 변경된 예약을 도입할 수는 없습니다.
  • 알 수 없는 식별자는 누락된 설명에 대한 요청을 유발할 수 있습니다. 그러나 인식 가능한 식별자에 손상된 상태가 결부되어 있으면 이 검사를 피할 수 있는데, RFC 2961이 명시적으로 인정한 한계입니다.
  • 가끔씩 수행되는 전체 갱신, 재시작 복구 절차, 그리고 이후의 인접 장애 감지 등이 반복(리프레시)이 수행해 온 작업을 보존했습니다. 유지 관리 트래픽을 줄였다고 해서 그 작업이 불필요해진 것은 아닙니다.

목록에 있는 모든 항목이 발견되었다

라우터가 식별자 목록을 받는 상황을 상상해 보십시오. 목록의 모든 식별자를 인식하고, 연관된 예약 상태를 찾아 해당 항목의 수명을 연장합니다. 누락 상태 응답은 필요하지 않습니다. 유지 관리 작업은 아무런 이변 없이 진행된 것처럼 보입니다.

이제 유지된 설명 하나가 내부적으로 잘못되었지만, 그 식별자는 여전히 인식 가능하다고 가정해 보십시오. 짧은 수신 메시지에는 그 설명이 반복되어 있지 않습니다. 조회가 성공했다고 해서 오류가 드러나는 것은 아닙니다. 그 내용이 다시 제시되지 않은 채 레코드는 이 작업을 통과해 살아남을 수 있습니다.

이것은 재구성된 장애 사례가 아니라 사고 실험입니다. 그 근거는 이례적으로 명시적인데, 2001년 4월에 발표된RFC 2961의 5.5절이 RSVP의 요약 갱신과 일반 전체 갱신 사이의 가능한 간극으로 내부 상태 손상을 지목합니다. 이 문서는 더 저렴한 유지 관리 작업이 더 비싼 작업이 관찰하던 모든 것을 관찰한다고 주장하지 않습니다.

그 단서가 바로 이 역사에서 흥미로운 부분입니다. 변화는 단순히 어떤 프로토콜이 같은 내용을 더 짧게 표현하는 방법을 찾았다는 것이 아니었습니다. “이것을 계속 유지하라”고 말하는 것과 “이것”의 내용을 반복하는 것을 분리한 것입니다.

반복은 두 가지 역할을 하고 있었다

RSVP의 원래 사양인 1997년 9월의RFC 2205는 주기적 갱신을 통해 Path 및 Resv 상태를 유지했습니다. 오랫동안 갱신되지 않으면 그 소프트 상태는 만료됩니다. 명시적 해제로 더 일찍 해제할 수 있었지만, 해제 메시지의 손실이 영원한 예약을 남기도록 설계되지는 않았습니다.

주기적인 전체 설명은 복구 기능도 제공했습니다. 이전 교환에서 유실되거나 놓친 정보는 다시 도착할 수 있었습니다. 라우팅이 변경되면 적절한 신호 상태를 새 경로를 따라 수립해야 했고, 반복은 프로토콜이 모든 개별 전환이 처음부터 완벽하게 전달되기를 기다리지 않도록 만들었습니다.

이 두 가지 역할은 비용을 공유했습니다. 유지되는 상태가 많으면 보내고 처리해야 할 설명도 많아집니다. 간격을 늘리면 반복되는 작업이 줄어들지만 복구와 정리는 느려질 수 있고, 간격을 줄이면 더 큰 비용을 치르고 더 자주 기회를 얻게 됩니다. 반복되는 정보 전부가 기능 없는 중복은 아니었습니다.

RFC 2961은 트리거(trigger)와 갱신(refresh)을 신중하게 구분했습니다. 새롭거나 변경된 상태 설명에는 트리거 메시지가 필요했습니다. 정책이나 ADSPEC 오브젝트에 대한 변경조차 여기에 포함되며, 대역폭 수치가 변하지 않았다는 것이 전체 설명이 변하지 않았다는 것을 반드시 의미하지는 않았습니다. 갱신은 기존 정보를 반복하는 것이지, 오래된 참조 아래에서 서로 다른 결정을 조용히 도입하는 것이 아니었습니다.

이것은 무엇을 축약할 수 있는지를 제한했습니다. 발신자가 요약에서 상태를 참조하려면 먼저 MESSAGE_ID를 실은 전체 Path 또는 Resv 메시지로 그 상태를 광고해야 했습니다. 이후의 참조는 이전 설명에 의존했으며, 새 설명을 추론하라는 지시가 아니었습니다.

더 짧은 설명, 아직 더 긴 침묵은 아니었다

Srefresh는 이전에 광고된 Path 및 Resv 상태의 식별자를 나열할 수 있었습니다. 대응하는 상태를 찾은 수신자는 모든 오브젝트를 다시 받지 않고도 그 상태를 갱신할 수 있었습니다. 요약되는 상태에 대해서는 일반적인 반복 전체 메시지를 생략할 수 있었습니다.

그러나 2001년 설계는 요약 갱신이 대체하는 전체 갱신보다 더 드물게 수행되는 것을 허용하지 않았습니다. 즉각적인 절감은 각 시점에 전달되는 설명에 있었습니다. 이를 단순히 타이머 간격의 증가로 다루면 이후의 설계를 이전 설계에 억지로 끼워 넣는 것이 됩니다.

식별자에는 의도적으로 한정된 의미가 부여되어 있었습니다. MESSAGE_ID에는 식별자뿐 아니라 에포크(epoch)가 포함되었고, 생성 주소가 그 범위를 결정했습니다. 원래의 Path 및 Resv 메시지에서 그 주소는 RSVP_HOP에서 나왔으며, 반드시 바깥 패킷의 IP 출발지와 같지 않았습니다. 재시작은 새 에포크를 도입할 수 있어, 오래된 실행 이력이 새 이력으로 오인되는 일을 막았습니다.

이 어느 것도 식별자를 유지된 콘텐츠의 다이제스트로 만들지는 않았습니다. 그것은 전역적인 예약 제목도, 인증 코드도 아니었습니다. 식별자는 관련 맥락에서 이전에 광고된 상태를 선택하는 데 도움을 줄 뿐이었습니다. 선택과 선택된 필드 전체의 검증은 서로 다른 작업으로 남았습니다.

같은 문서의 다른 확장들은 다른 비용을 다루었습니다. Bundle은 완전한 RSVP 메시지 여럿을 하나의 데이터그램에 담았으며, 그 자원 수요를 하나의 승인된 예약으로 합치지는 않았습니다. 승인 응답과 빠른 재전송은 개별 메시지의 전달을 개선했습니다. 담기와 전달과 승인은 성공의 상호 교환 가능한 의미가 아니었습니다.

부재는 설명을 요청할 수 있었다

적절한 수신자가 요약이 인용한 상태를 찾지 못하면, MESSAGE_ID_NACK이 누락된 참조를 식별했습니다. 아직 대응하는 상태를 보유한 발신자는 그것을 일반 Path 또는 Resv 메시지로 전송해야 했습니다. 더 이상 일치하는 상태가 없다면, 식별자만으로는 재생성할 설명이 없습니다.

이 부정 승인은 대역폭 요청이 거부되었다는 뜻이 아니었습니다. 상태 참조를 해석할 수 없다는 뜻이었습니다. 두 의미를 혼동하면 동기화 문제가 용량 진단으로 바뀌어 버립니다. 반대로 대체 설명의 성공적인 전달만으로 종단 간 예약이 승인되었다는 증명이 되지는 않습니다.

멀티캐스트에는 또 하나의 단서가 필요했습니다. 요약의 모든 수신자가 표현된 모든 상태를 보유해야 하는 것은 아니었습니다. 출발지와 그룹 정보, 역방향 경로 검사가 어떤 수신자가 참여해야 하는지를 결정했습니다. 표현된 흐름과 무관한 노드는 자신이 결코 필요로 하지 않았던 레코드가 없다는 이유만으로 복구를 요구해서는 안 됩니다.

따라서 이 복구 채널은 특정 종류의 부재만을 가시화했습니다. 그 침묵은 남아 있는 모든 것에 대한 무제한의 진술이 아니었습니다. 목록은 깨끗하게 해석될 수 있지만, 유지된 설명에는 목록이 드러내지 않는 오류가 담겨 있을 수 있습니다.

사양은 불편한 구분을 그대로 두었다

5.5절은 요약 갱신이 패킷 손실이나 라우팅 변경 같은 공통 이벤트를 다루지만, 전체 갱신과 정확히 같은 복구 속성을 제공하지는 않는다고 설명합니다. 내부 손상은 일반적인 설명은 잠재적으로 복구에 도움이 될 수 있지만 요약은 그러지 못할 수 있는 문제의 예로 제시됩니다.

문서는 두 가지 보조 방법을 제안하며, 그 차이가 중요합니다. 첫 번째는 트리거를 보낼 때 내부 상태에 대한 체크섬이나 다른 계산 값을 저장한 뒤 나중에 다시 계산하는 방법입니다. 이는 메시지를 생성했어야 했는데 생성하지 않은 상태 변경을 드러낼 수 있습니다. 문서는 이 방법이 내부 상태 손상으로부터 보호하지 않는다고 명시합니다. 이것은 놓친 트리거를 다루며, 가능한 모든 잘못된 기억 값을 다루지 않습니다.

두 번째 방법은 완전한 Path 및 Resv 갱신을 가끔 계속 보내는 것입니다. 그 간격은 요약 간격보다 길어, 축약된 일상 교환의 이점을 유지하면서 일반 갱신이 제공하는 복구 기회의 종류를 복원합니다. 전체 갱신은 같은 기간에 같은 상태의 중복된 요약을 반드시 동반할 필요는 없습니다. 상대적 빈도는 설정할 수 있습니다.

이 제안들을 “체크섬이 이웃의 상태를 검증한다”는 주장으로 묶으면 그 단서가 지워집니다. 발표되지 않은 로컬 변경을 감지하는 것과 완전한 설명을 교환에 되돌려 보내는 것은 서로 다른 개입입니다. 어느 쪽도 라우터의 올바름 전체를 보증하지 않습니다.

그 결과 만들어진 배열은 구식 행동으로 되돌아간 최적화보다 더 섬세합니다. 잦은 유지 관리는 저렴할 수 있고, 덜 잦은 전체 설명이 복구에 필요한 정보를 갱신합니다. 이 선택의 대가는 두 일정이 더 이상 동일한 관찰을 제공하지 않는다는 것입니다.

진짜 메시지라도 답을 생략할 수 있었다

인증은 생략된 콘텐츠가 다시 나타나게 하지 못합니다.RFC 2747은 자신의 핵심 가정 아래에서 RSVP 메시지 무결성과 인증된 이웃을 다룹니다. MESSAGE_ID는 그 무결성 메커니즘이 아니며, 무결성 보호는 기밀성을 위한 암호화가 아닙니다.

기대한 이웃이 보낸 진짜 요약조차 여전히 요약입니다. 누가 보냈는지를 확인하는 것이 그것이 참조하는 모든 로컬 유지 필드가 올바르다는 것을 확립하지는 못합니다. 이것은 프로토콜 기능들 사이의 역사적 구분이지, 오늘날 그 문서의 구식 암호 선택을 배포하라는 권고가 아닙니다.

승인 응답에도 비슷한 경계가 있습니다. 잘못된 구문은 승인해서는 안 되지만, 유효한 전달 응답도 결과 데이터 서비스를 측정하지는 않습니다. 자원 및 정책 처리에는 자기 고유의 의미가 남아 있습니다. 프로토콜은 메시지가 도착했다는 신뢰를 높일 수 있지만, 메시지가 기술하는 모든 것에 대한 증서를 발급하지는 않습니다.

복구는 기억을 빌릴 수 있었지만 포워딩을 발명할 수는 없었다

2007년 10월의RFC 5063은 GMPLS RSVP 우아한 재시작(graceful restart)을 요약의 계시적 사용법으로 확장했습니다. 다운스트림 이웃은 이전에 수신한 Path 메시지들의 이름을 제시함으로써 재시작한 업스트림 제어기를 도울 수 있었습니다. 이는 일반적인 요약의 관점을 뒤집는 것으로, 이웃이 이전에 보낸 것을 갱신하는 것이 아니라 이전에 받은 정보를 보고하는 것이었습니다.

인식 가능한 참조는 필요한 전체 복구 설명의 양을 줄일 수 있었습니다. 일치가 없으면 더 완전한 RecoveryPath 교환으로 이어질 수 있었습니다. 기능 표시와 복구 플래그가 이 절차를 일상적인 갱신과 구분했습니다.

그럼에도 다운스트림의 기억은 그 자체로 누락된 포워딩 상태를 만들 수 없었습니다. 복구는 신호 처리를 유지된 포워딩 상태와 연관시켜야 했습니다. 새로운 포워딩 배열을 만들려면 이웃의 설득력 있는 기억이 아니라 적절한 별도의 업스트림 Path 또는 인그레스 관리 지시와 적용 가능한 정책이 필요했습니다.

보안 논의도 인증을 재시작 전후 정보 간의 올바른 대응 관계와 분리했습니다. 신뢰된 이웃을 식별하는 것만으로 그 이웃의 재구성이 올바르다는 것이 입증되지 않았습니다. 제어 평면 정보를 복구하는 것은 트래픽이 의도된 경로를 사용하는 것을 보는 것과 같은 관찰이 아니었습니다.

이후의 설계들은 장애 감지기를 다시 배정했다

2009년에 발표된RFC 5439의 확장성 분석은 신호 트래픽뿐 아니라 상태별 메모리와 처리도 고려합니다. 긴 목록은 여전히 많은 식별자에 대한 작업을 요구합니다. 패킷 수를 줄인다고 개별 예약이 사라지지 않으며, 이 역사적 분석은 현재 라우터에 대한 보편적인 용량 수치를 제공하지 않습니다.

2018년 5월의RFC 8370은 훨씬 긴 갱신 간격을 신뢰할 수 있는 메시지 전달, 승인되지 않은 Path 및 Resv 메시지에 대한 별도의 더 짧은 처리, 그리고 명시적인 신호 인접 장애 감지와 결합했습니다. 인접 관계가 실패하면 그것을 통해 학습한 상태는 만료된 것으로 처리됩니다.

이것은 단지 타이머의 값이 커진 것이 아닙니다. 이전에 주기적 갱신에 결부되어 있던 작업 일부가 다른 메커니즘으로 배정되었습니다. 더 강한 승인 요건은 새 기법들의 구현에 속하며, 모든 구식 RFC 2961 노드에 소급적으로 가정할 수 없습니다. 필요한 기능이 없는 피어는 전통적 행동을 유지합니다.

IANA RSVP 파라미터 레지스트리는 공통 메시지 값, 오브젝트 클래스, 기능 비트를 기록합니다. 이 할당은 구현들이 의미에 대해 합의하게 해 줍니다. 그러나 특정 이웃이 기능을 활성화했음을 증명하지는 못합니다. 지원은 운용 속에서 관찰되어야 하며, 그 지원의 소멸은 한때 존재했다는 기억으로 대체될 수 없습니다.

이 문서들은 설계와 조건을 확립하지만, 모든 확장의 보편적 채택을 확립하지는 않습니다. 그 역사는 역할을 더 정확하게 분리해 온 역사입니다. 상태를 유지하는 것, 누락된 설명을 얻는 것, 실패한 이웃을 감지하는 것, 동작하는 예약을 수립하는 것은 서로 관련된 작업이었습니다. 더 짧은 메시지는 유용해졌지만, 그 모든 작업에 대한 답이 되지는 않았습니다.