요약

  • RFC 3936은 RSVP 할당 공간을 Standards Action, Expert Review, Vendor Private 사용으로 나누었지만, 모든 Class-Num은 기존의 미지 객체 동작 대역 안에 그대로 머물러 있었습니다.
  • 따라서 사적 값 하나가 오래된 노드로 하여금 메시지 전체를 거부하게 하거나, 익숙하지 않은 객체만 폐기하게 하거나, 그 객체를 그대로 전달하게 만들 수 있었습니다. 할당 권한과 실행 동작은 별개였습니다.

구형 라우터는 객체를 알 필요가 없었다

어떤 RSVP 메시지가, 그 안의 객체가 존재하기 전에 만들어진 노드에 도달하는 상상을 해보십시오. 노드는 새 객체의 의미를 파싱할 수 없습니다. 그래도 그 객체에 대해 동작할 수 있습니다.

이 결과는 1997년 RSVP 사양인RFC 2205에서 비롯됩니다. 객체 헤더는 8비트 Class-Num과 8비트 C-Type을 담습니다. 3.10절은 Class-Num 패턴에 동작을 부여합니다. 클래스가0bbbbbbb처럼 보이면 노드는 메시지 전체를 거부하고 Unknown 주체 Class 오류를 반환합니다.10bbbbbb처럼 보이면 노드는 객체를 무시하며, 전달하지도 오류를 보내지도 않습니다.11bbbbbb처럼 보이면 노드는 객체의 의미를 무시하되, 받은 메시지로부터 만들어지는 메시지들에서 그 객체를 검사 없이 그대로, 수정 없이 전달합니다.

RFC 2205의 RFC Editor 기록은 문서의 상태와 역사를 확정합니다. 그러나 운영상의 구별은 와이어 필드 안에 있습니다. 노드는 코드 포인트의 정치적 역사를 참조한 뒤에 동작하지 않습니다. 선행 비트 패턴을 읽을 뿐입니다.

이것이 2004년 10월에 BCP 96으로 발행된RFC 3936의 뒤에 놓인 엔지니어링 제약입니다. 이 메모는RFC 3209의 RSVP 및 트래픽 엔지니어링 확장을 갱신했습니다. 실험을 불가능하게 만들지 않으면서 확장이 충분한 검토를 받도록 하려는 목적이었습니다. 그러나 모든 새 클래스를 하나의 무차별 풀에서 할당할 수는 없었습니다. 그 풀은 이미 실행 지도였습니다.

아홉 개의 할당 구획이 세 개의 호환성 통로를 보존했다

RFC 3936은 각 Class-Num 동작 대역을 다시 나누었습니다. 거부 대역에서는 값 0–119가 Standards Action, 120–123이 Expert Review, 124–127이 Vendor Private였습니다. 객체 폐기 대역에서는 각각 128–183, 184–187, 188–191이었습니다. 미지 객체 전달 대역에서는 192–247, 248–251, 252–255였습니다.

현재IANA RSVP Parameters 레지스트리에도 그 아홉 구획이 그대로 표시되어 있습니다. 이 표를 행정적 정리라고 읽고 싶은 유혹이 있습니다. 더 정확하게는 하나의 행렬로 보는 것입니다. 한 축은 새로운 사용이 어떻게 승인되는지를 결정합니다. 다른 축은 낡은 코드가 그 사용을 이해할 수 없을 때 무엇을 하는지를 결정합니다.

Standards Action은 그 파급 결과가 이해된 널리 수용된 확장을 위한 것이었습니다. Expert Review 값은 보통 실험용이었으며, 그 사용과 처리를 문서화한 Experimental RFC를 통해 요청되어야 했습니다. Vendor Private 값은 개별적으로 등록되지 않았습니다.RFC 3936 정보 페이지는 BCP와 그것이 갱신하는 RFC를 확인해 주며,정오표 페이지는 원래 규칙을 조용히 고쳐 쓰는 대신 수정 사항을 검증하는 곳입니다.

이러한 문서적 경로 어느 것도 선행 비트 동작을 바꾸지 않습니다. 124–127에서 선택된 사적 클래스는 여전히 메시지 거부 통로에 속합니다. 188–191의 사적 클래스는 구형 노드에서 폐기되지만 메시지의 나머지는 계속 진행될 수 있습니다. 252–255의 사적 클래스는 그 노드를 통과해 그것을 인식하는 다운스트림 구현체까지 전달될 수 있습니다. “사적(Private)”은 누가 그 번호를 조율하는지에 답합니다. 네트워크가 그 옥텟으로 무엇을 하는지에는 답하지 않습니다.

사적 재사용에는 공개 판별자가 필요했다

RFC 3936은 서로 다른 기업, 벤더, 표준화 단체가 동일한 사적 코드 포인트를 재사용하는 것을 허용했습니다. 충돌을 피하기 위해 관련 데이터 필드의 처음 네 옥텟 워드가 SMI Private Enterprise Number를 담도록 요구했습니다. 이 식별자는 공개된IANA Private Enterprise Numbers 레지스트리에서 옵니다.

이것은 경제적인 형태의 네임스페이스 중첩이었습니다. IANA가 모든 독점 객체를 나열할 필요는 없었습니다. 수신 구현체는 사적 Class-Num을 본 뒤, 사적 형식을 안다면 기업 워드를 검사할 수 있었습니다. 두 회사가 같은 사적 숫자 슬롯을 차지하더라도 그들의 객체가 서로 구별 불가능해지지는 않았습니다.

경계가 중요합니다. 기업 번호는 서명이 아닙니다. 발신자를 인증하지도, 장치의 소유를 증명하지도, 페이로드를 보증하지도, 두 형식을 상호운용 가능하게 하지도 않습니다. RFC 3936은 기업 코드를 인식하지 못하는 구현체가 여전히 Class-Num 규칙에 따라 객체와 감싸는 메시지를 처리한다고 명시합니다. 내부 의미가 독점이더라도 외부 호환성 동작은 공개적으로 유지됩니다.

IPsec 흐름을 위한 RSVP 확장을 정의한RFC 2207은 RFC 3936이 언급한 가상 목적지 포트 공간의 출처 중 하나입니다. 이 예는 아키텍처를 강화합니다. 각 네임스페이스는 자신만의 할당 규칙과 처리 규칙이 필요합니다. “RSVP 확장”은 단일한 전역 허가가 아닙니다.

미지 클래스와 미지 서브타입은 서로 다른 실패였다

상위 비트 이야기는 객체 클래스 자체가 미지일 때 적용됩니다. RFC 2205는 알려진 Class-Num 안의 미지 C-Type을 다르게 취급합니다. 구현체는 클래스는 알지만 서브타입은 모르며, 일반적으로 오류와 함께 메시지 전체를 거부합니다. 익숙한 봉투가 익숙하지 않은 변형을 건너뛰어도 안전하게 만들지는 않습니다.

RFC 3936은 그 범위 설정을 보존했습니다. C-Type은 하나의 Class Number에 속합니다. 새 클래스를 정의하는 문서는 이후 C-Type이 어떻게 할당될지를 기술해야 합니다. 레거시 클래스의 경우, Standards Track 또는 Best Current Practice RFC가 대체하지 않는 한 기본값은 Standards Action으로 남았습니다.

경로 서브객체는 또 하나의 별개 네임스페이스입니다.RFC 3209의 공식 기록은 LSP 터널을 위한 RSVP-TE를 설명하고,RFC 3473은 이후의 GMPLS 시그널링 확장을 보여줍니다. RFC 3936은 EXPLICIT_ROUTE와 RECORD_ROUTE 서브객체 타입을 표준, 전문가, 사적 구간으로 나누고 사적 형식에 다시 기업 워드를 요구했습니다. 그러나 서브객체의 타입 필드는 Class-Num이 아니며, 둘 다 RSVP에 속한다고 해서 세 가지 미지 클래스 동작을 물려받지는 않습니다.

문서의 등급이 코드 변경을 제약했다

RFC 3936은 절차 변경을 다시 할당 레인에 연결했습니다. Standards Action 구간 항목의 처리 변경은 Standards Track RFC에 나타나야 했습니다. Expert Review 항목의 대응 변경은 Experimental RFC에 나타나야 했습니다. 따라서 레지스트리 결정이 거버넌스의 끝이 아니었습니다. 구현체가 무엇을 하도록 기대되는지를 바꾸려면 상응하는 검토 수준의 문서화가 필요했습니다.

정책 언어는 당대의RFC 2434지침에서 왔습니다.RFC 8126이 나중에 그 일반 IANA 지침을 대체했습니다. 후속 문서가 오늘의 어휘를 설명할 수는 있지만, 2004년의 RSVP 행렬을 소급하여 설계한 것은 아닙니다.

RFC 3936은 더 나은 검토가 RSVP 변경을 더 건축적으로 견고하게 하고 보안을 개선하기를 바랐습니다. 이는 근거이지 측정된 결과가 아닙니다. IANA 표는 어떤 구간과 기록된 할당이 존재하는지를 증명합니다. 그것은 어떤 벤더가 그것을 구현했는지, 어떤 사적 값이 실제 네트워크를 통과하는지, 구형 노드가 규칙을 올바르게 따랐는지, 특정 확장이 성공했는지는 밝혀주지 않습니다.

여기서 Lu Heng의최소 초기 사양과 이후의 자발적 채택의 구별, 그리고구동 코드(running code)의 우선성이 이 역사를 더 선명하게 만듭니다. 등록, 구현, 운영 사용은 서로 다른 주장입니다. RFC 3936은 첫 번째 주장이 호환성 통로를 지배하도록 만들었습니다. 나머지는 패킷 트레이스, 코드, 상호운용성 결과, 배포 기록만이 확립할 수 있었습니다.

지속되는 교훈은 단순히 IANA가 희소한 바이트 하나를 관리했다는 것이 아닙니다. 그 바이트는 이미 그 확장을 들어본 적 없는 코드를 위한 결정을 담고 있었습니다. RFC 3936은 공개 표준, 경계가 있는 실험, 독점적 작업을 그 상속된 기계 동작 안에 배치했습니다. 코드 포인트는 사적일 수 있었습니다. 미지 라우터에 미치는 그 영향은 결코 사적이지 않았습니다.