RFC 3477: 하나의 링크, 두 개의 로컬 이름

요약

RFC 3477은 안정적인 라우터 ID(Router ID)와 엔드포인트 로컬 인터페이스 ID(Interface ID)의 조합으로 포인트 투 포인트 무번호 링크를 지정하고 기록하는 방법을 RSVP-TE에 제공했다.
두 엔드포인트는 동일한 링크에 대해 서로 무관한 번호를 선택할 수 있었으며, ERO 의도, IF_ID 해석, RRO 관찰, 포워딩 현실은 각각 별개의 증거로 남았다.

“무번호 링크(unnumbered link)”라는 표현은 잘못된 그림을 불러일 일이다. 그것은 정체성에서 벗어난, 어떻게든 정체성을 회피한 연결처럼 들린다. 그러나 RFC 3477은 거의 정반대를 기술했다. 포인트 투 포인트 링크에는 이름이 있었지만, 어떤 엔드포인트의 이름도 그것을 할당한 기계 밖에서는 주권을 갖지 않았다.

한쪽 끝에서 LSR은 0이 아닌 32비트 식별자를 선택했다. 반대쪽 LSR은 또 다른 값을 선택했다. 각 값은 자신을 할당한 LSR 내에서만 고유하면 되었다. 명세는 두 값 사이에 사전 관계가 없음을 명시적으로 밝혔다. 따라서 같은 회선은 A 쪽에서 한 번호로, B 쪽에서 다른 번호로 로컬하게 알려질 수 있었다. 시점을 뒤집으면 “로컬”과 “원격”도 뒤집혔다.

이 소박한 규칙은 더 큰 역사적 교훈을 담고 있다. 인터넷은 좁은 범위를 폐지하기보다 그 범위를 보존함으로써 확장해 왔다. 로컬 식별자는 할당이 저렴하고 하나의 시스템이 다루기 쉽다. 그것의 범위가 식별자와 함께 이동할 때만 다른 시스템에게 의미를 갖는다. RFC 3477은 안정적인 라우터 ID로 그 범위를 제공했으며, 이는 LSR로의 어떤 경로라도 남아 있는 한 도달 가능을 유지하도록 의도된 루프백 스타일 주소가 일반적이었다.

유용한 이름은 인터페이스 ID만이 아니었다. 이름은 튜플, 즉 할당한 라우터의 정체성에 그것이 할당한 값의 조합이었다. 덕분에 서로 다른 라우터에서 동일한 32비트 값이 무해했고, 하나의 링크 양끝에서 서로 다른 값이 합법적이었다. 이는 또한 로컬 행정적 선택이 전역 자산 번호로 위장하는 것을 막았다.

엔드포인트들은 여전히 서로의 선택을 알아야 했다. RFC 3477은 그 지식을 얻는 여러 경로를 허용했다: 구성, 링크 관리 프로토콜(LMP), 포워딩 인접성이 관련될 때의 RSVP 또는 CR-LDP, 그리고 IS-IS나 OSPF 확장이었다. IGP가 트래픽 엔지니어링을 지원한다면, 같은 LSR의 IGP 모듈과 RSVP가 식별자에 대해 합의해야 했다. 튜플은 그 뒤의 연결이 유지될 때만 유용했다.

첫 번째 시그널링 증거는 경로 의도였다. RFC 3477은 명시적 경로 객체(ERO)에 무번호 인터페이스 ID 서브오브젝트를 추가했다. 타입 4, 길이 12로, 라우터 ID와 그 라우터가 할당한 인터페이스 ID를 담았다. ERO에서 튜플은 노드에게 경로가 어떤 무번호 링크를 사용하려는지를 알려주었다. 그것은 제안된 경로 안의 지시이지 링크를 통과했다는 증거가 아니었다.

다음 증거는 로컬 해석이었다. 노드가 무번호 발신 링크를 선택하면, 자신의 라우터 ID와 자신의 로컬 식별자를 IF_ID RSVP_HOP 객체에 넣었다. 수신 LSR은 이웃들이 할당한 식별자 표를 필요로 했다. 수신자는 메시지의 튜플을 그 지식과 대조하여 라벨 할당이 속하는 링크를 결정했다. 튜플을 대조할 수 없으면 RFC 3477은 IF_ID 오류, 코드 24, 값 16, “Unknown Interface Index”를 권고했다.

이 오류가 중요한 이유는 더 큰 결론을 발명하지 않고 실패의 위치를 지정하기 때문이다. 그것은 이 수신자가 현재 지식 상태에서 이 이웃 범위의 이름을 해석할 수 없었다고 말할 뿐이다. 그 자체로 물리 회선이 부재했다거나, 송신자가 거짓말을 했다거나, IGP가 틀렸거나, 대체 경로가 없었다는 것을 증명하지 않는다. 매핑의 출처와 시각은 반드시 보존되어야 한다.

RFC 3477은 기록 경로 객체(RRO)를 위한 병행 서브오브젝트도 만들었다. 같은 타입 4와 길이 12의 튜플을 사용하지만, 서로 다른 증거적 역할을 수행했다. ERO는 시그널링이 향하려는 곳을 표현했다. RRO는 Path 메시지가 진행하면서 축적된 RSVP 경로 상태를 기록했다. 같은 인코딩을 재사용했다고 두 행위가 하나로 합쳐진 것은 아니다.

RRO 플래그는 이 분리를 더욱 선명하게 했다. 한 비트는 하류에서 로컬 보호가 가능함을 의미했다. 다른 비트는 로컬 보호가 사용 중임을, 보통 장애 이후 복구가 터널을 유지하고 있기 때문임을 의미했다. 보호 가능성과 보호 활성화는 서로 다른 사실이었다. 둘을 “보호됨”으로 평탄화하는 모니터링 시스템은 가장 중요한 이벤트를 폐기한다.

포워딩 인접성(Forwarding Adjacency)은 이 모델이 벌거벗은 물리 포트에 국한되지 않음을 보여주었다. 무번호 포워딩 인접성으로 광고된 LSP도 헤드 엔드에서 하나, 테일 엔드에서 또 하나의 식별자를 얻었다. 선택적 LSP_TUNNEL_INTERFACE_ID 객체, 클래스 193, C-타입 1은 Path에서 순방향 정체성을, Resv에서 역방향 정체성을 담았다. 구성된 링크에도 여전히 두 개의 행정적 시점이 있었다.

이후의 작업은 이 아이디어들을 더 넓은 GMPLS 및 트래픽 엔지니어링 아키텍처 안에 배치했다. OSPF와 IS-IS 확장이 로컬 및 원격 식별자를 광고했고, 링크 번들링이 이 방식을 컴포넌트 링크에 적용했으며, RFC 6107은 이후 Path Key 처리를 위해 RFC 3477을 갱신했다. 이 문서들은 계보를 설명하는 데 도움을 주지만, 2003년 1월의 구현이 무엇을 지원했는지에 대한 증거로 거슬러 읽혀서는 안 된다.

Lu Heng의 리얼리티 레이어 노트의 규율은 여기서 정확히 적용된다: 어떤 기록도 그 아래 층에서 권위를 빌려오지 말라. 라우터 ID는 번호에 범위를 부여할 뿐, 현재 도달 가능성을 증명하지 않는다. ERO는 의도를 이름 짓는다; 통과를 증명하지 않는다. RRO는 시그널링 상태를 기록한다; 독립적인 물리 텔레메트리가 아니다. 라벨 할당은 포워딩이 아니다. 프로그래밍된 인터페이스는 트래픽 전달이 아니다.

따라서 감사는 원시 RSVP 메시지, 세션, 방향, 송신자, 시각을 유지해야 한다. ERO 순서, IF_ID 튜플, 이웃 매핑 출처, 대조 결과, Path와 Resv 상태, 라벨 연산, RRO 순서와 플래그를 보존하라. 그런 다음에만 이러한 기록을 인터페이스 인벤토리, 인접성 상태, 포워딩 테이블, 알람, 트래픽 카운터와 결합하라. 모든 결합에는 자체 타임스탬프와 출처가 필요하다.

가장 중요한 것은, 인터페이스 ID를 그것을 할당한 라우터로부터 분리하지 않는 것이다. 32비트 값은 작은 전역 링크 주소가 아니다. 또한 두 엔드포인트 값을 발명된 표준 번호로 정규화해서도 안 된다. 그 차이는 데이터베이스의 더러움이 아니라, 누가 무엇을 이름 지을 권한을 가졌는지에 대한 이 아키텍처의 기록이다.

RFC 3477은 겉보기 결여를 담습된 형태의 다수성으로 바꾼 점에서 인터넷 역사에 자리한다. 무번호 링크는 하나의 보편적 이름을 필요로 하지 않았다. 두 개의 로컬 이름, 그들의 범위, 그리고 어느 시점을 말하는지를 신중히 밝히는 프로토콜이 필요했다. 모든 유용한 정체성이 전역적으로 시작해야 한다고 가장하는 것보다 강한 설계였다.