요약

  • RFC 3476은 OIF 광 UNI 필드를 공개 LDP 및 RSVP 네임스페이스에 등록했지만, 해당 필드의 내용과 사용법을 반복적으로 OIF 사양에 위임했습니다.
  • 문서에 명시된 오류 — 다이버시티 사용 불가, 서비스 수준 사용 불가, 알 수 없는 연결, 무단 발신자 또는 수신자 — 는 등록된 번호를 인식하는 것은 첫 번째 수신 절차일 뿐이며 서비스의 증명이 아님을 보여줍니다.

번호는 표준 기구가 관리할 수 있는 가장 작은 것 중 하나입니다. 그렇기 때문에 중요한 것입니다. 두 구현체가 같은 숫자 값에 서로 다른 의미를 부여하면, 동일한 비트를 파싱하면서도 현실에 대해 서로 불일치할 수 있습니다. 레지스트리는 그 충돌을 막아줍니다. 하지만 그 현실이 실제로 일어나게 만들지는 않습니다.

RFC 3476은 이 구분을 특히 명확하게 담아냈습니다. 2003년 3월에 발행된 이 문서는 인터넷 표준이 아니라 Informational 문서였습니다. 광 인터네트워킹 포럼(Optical Internetworking Forum)은 광 사용자-네트워크 인터페이스용 시그널링을 설계하면서 가능한 한 IETF 기반 기능, 즉 LDP, RSVP, RSVP-TE, 그리고 발전 중이던 GMPLS 작업을 재사용하고자 했습니다. 소수의 UNI 전용 추가 항목에 필요한 값은 IANA가 관리하는 프로토콜 네임스페이스에 있었습니다.

그래서 이 문서는 카탈로그처럼 보입니다. LDP의 경우 IPv4, IPv6, NSAP 형식의 Source ID와 Destination ID TLV를 나열했습니다. Egress Label, Local Connection ID, Diversity, Contract ID, UNI Service Level을 추가했습니다. 할당된 범위는 0x0960부터 0x0970까지였습니다. RSVP의 경우 클래스 번호 229, C-Type 1의 GENERALIZED_UNI 객체와 클래스 1, C-Type 11의 UNI_IPv4_SESSION을 정의했습니다. GENERALIZED_UNI 하위 객체는 발신 및 수신 전송 네트워크 주소, 다이버시티, 이그레스 라벨, 서비스 수준을 담았습니다.

그러나 이 카탈로그는 일관되게, 할당이 곧 서비스 정의라고 가장하는 데서 멈췄습니다. 거의 모든 필드에 대해 RFC 3476은 내용과 사용법이 OIF UNI 사양에 기술되어 있다고 명시했습니다. 공개 번호는 안정적인 고리를 제공했고, 외부 사양이 규칙을 제공했습니다. 구현체는 양쪽 모두를 필요로 했고, 운영자는 여전히 요청이 허용되는지, 가능한지를 판단해야 했습니다.

이 분리는 단지 편집상의 것이 아니라 제도적인 것이었습니다. OIF에는 서비스 지향적인 계약이 있었습니다. IETF 프로토콜은 시그널링 전송을 제공했습니다. IANA는 공유 숫자 네임스페이스를 충돌 없이 유지했습니다. 각 기관은 사슬의 서로 다른 부분을 통제했습니다. RFC 발행이 OIF 정책을 조용히 IANA로 이전하지 않았고, IANA 항목이 OIF 서비스를 IETF 표준으로 만들지도 않았습니다.

할당 경계 자체도 혼합되어 있었습니다. UNI 전용 LDP 상태 값은 사전 사용(private-use) 범위인 0x3Fxxxxxx에 위치했고 IANA 관리를 요구하지 않았습니다. Status Enquiry와 Status Response라는 두 제안 메시지는 이미 폐기(obsolete) 처리되어 있어서, RFC는 그에 대한 번호를 요청하지 않았습니다. 따라서 레지스트리 기록은 선별의 역사이기도 했습니다. 일부 구성 요소는 공개 네임스페이스에 들어갔고, 일부는 사적으로 남았으며, 일부는 할당 전에 사라졌습니다.

오류 코드는 이 문서에서 가장 드러내는 문장들입니다. RSVP는 다이버시티가 사용 불가하다고, 요청된 서비스 수준이 사용 불가하다고, 연결 식별자가 유효하지 않거나 알 수 없다고 답할 수 있었습니다. 정책 제어는 무단 발신자나 무단 수신자를 거부할 수 있었습니다. 이러한 결과들은 번호 인식의 실패가 아니었습니다. 그것들은 더 뒷단 계층에서의 결정이었습니다.

유효한 GENERALIZED_UNI 객체를 생각해 보십시오. 클래스와 C-Type은 인식될 수 있습니다. 길이와 하위 객체는 파싱될 수 있습니다. 발신 및 수신 TNA 필드는 잘 형성되어 있을 수 있습니다. 그러나 그 어느 것도 발신자가 회선을 주문할 권리가 있다는 것, 수신자가 동의한다는 것, 실제로 서로 다른 두 광 경로가 존재한다는 것, 용량이 비어 있다는 것을 증명하지 못합니다. 같은 요청이 문법적으로 완벽하면서도 운영적으로 불가능할 수 있습니다.

이것이 명명(naming)과 통제(control) 사이의 경계입니다. 코드 포인트는 "이 비트를 이런 종류의 객체로 해석하라"고 말합니다. 그러나 "이 주체에게 따르라", "이 계약을 수락하라", "이 파장을 할당하라", "고객에게 서비스가 제공되었다고 선언하라"고는 말하지 않습니다. 이 문장들을 혼동하면 저수준 레지스트리 수신이 모든 후속 결정의 권위를 빌려오게 됩니다.

주변 RFC들도 이 한계를 강화합니다. RSVP는 소프트 상태와 예약 메시지를 유지합니다. RSVP-TE는 터널 시그널링을 추가합니다. LDP는 라벨을 배포합니다. GMPLS는 라벨을 패킷을 넘어 일반화합니다. 이러한 메커니즘은 요청을 전달하고 프로토콜 상태를 기록할 수 있지만, 하나의 파싱된 객체를 물리적 크로스 커넥트로 바꾸지는 못합니다. RFC 3471부터 3475까지도 신원, 시그널링 교환, 알림, 콜/연결 작업을 분리합니다. RFC 3476은 네임스페이스 이음새를 추가한 것이지, 그 계층들을 가로지르는 지름길이 아닙니다.

이후의 거버넌스 문서들이 이 행정 논리를 더 쉽게 명명하게 합니다. RFC 3936은 RSVP 값 할당 정책을 기술했습니다. RFC 8126은 IANA 고려사항이 IANA에 명확한 등록 지시를 주고, 기술 문서는 그 밖에 있어야 함을 강조했습니다. 이후 문서를 2003년의 규칙으로 소급 적용해서는 안 되지만, RFC 3476이 이미 하고 있던 일 — 의미론을 실행한다고 주장하지 않으면서 참조 가능한 번호를 발행하는 일 — 을 조명해 줍니다.

현재의 IANA 레지스트리는 그 흔적의 일부를 보존합니다. 값이 할당되고 참조되었다는 증거입니다. 필드 수준의 텔레메트리가 아닙니다. 레지스트리 페이지는 광 스위치가 요청을 수락했는지, 경로 계산이 다이버시티를 찾았는지, 크로스 커넥트가 프로그래밍되었는지, 광 신호가 존재했는지, 트래픽이 흘렀는지 보여줄 수 없습니다.

Lu Heng의 현실 계층 원칙은 이 역사적 교훈을 감사 방법으로 전환합니다. 원시 메시지와 그 숫자 식별자에서 시작하십시오. 관련 시점에 존재했던 레지스트리를 기준으로 해석하십시오. 정확한 RFC 및 OIF 사양 리비전을 열어 보십시오. 파서 결과를 기록하십시오. 그런 다음 한 계층씩 진행하십시오. 신원, 인증, 권한 부여, 입장 허가, 경로 계산, 자원 예약, 하드웨어 프로그래밍, 신호 관측, 트래픽, 서비스 결과 순으로.

사슬을 무너뜨리지 마십시오. 인식된 Source ID는 인증된 권한이 아닙니다. Diversity 하위 객체는 두 독립 경로가 아닙니다. Service Level 필드는 전달된 SLA가 아닙니다. Egress Label은 광 수령증이 아닙니다. 오류가 없다는 것은 모든 후속 작업이 완료되었다는 긍정적 증거가 아닙니다.

거부 경로도 동등한 주의를 요합니다. 오류 객체, 코드, 서브코드, 이를 발행한 노드, 시각, 그것이 응답한 요청을 보존하십시오. "다이버시티 사용 불가"는 명시된 거부 표면을 식별하므로 일반적인 실패보다 강력합니다. 그래도 숨겨진 토폴로지, 자원 데이터베이스의 정확성, 모든 대안의 불가능성을 증명하지는 못합니다.

RFC 3476은 가장 규율된 규모의 조율을 보여주기 때문에 인터넷 역사에서 자리합니다. 공개 레지스트리는 독립적인 구현체들이 같은 객체에 대해 이야기하게 만들 수 있습니다. 그것은 필요한 인프라입니다. 그러나 서비스에 대한 주권이 아니며, 서비스가 존재한다는 증거도 아닙니다. 번호는 사건을 열 뿐이며, 수령증들이 그것을 마무리해야 합니다.

출처