요약

  • RFC 3037은 일반적으로 라우팅된 수신지 기반 경로를 따라 MPLS 포워딩을 수행하는 장치에 대해 기본 LDP 구현을 권고했다. 이는 모든 MPLS 장치에 LDP를 의무화한 것이 아니며, 어떤 인스턴스가 구성되어 동작 중임을 입증한 것도 아니었다.
  • 이 문서는 기본 홉바이홉 라벨 배포를 명시적 라우팅 기반 트래픽 엔지니어링과 분리했으며, 탐색, TCP 연결, 매개변수 합의, 운영 세션, 바인딩 교환, 유지된 상태, 포워딩 프로그래밍, 관측된 트래픽이라는 여러 독립적인 증빙을 노출했다.

RFC 3037에서 가장 지나치게 읽히기 쉬운 단어는 프로토콜 이름이 아니라 “권고했다(recommended)”이다. 짧은 요구 수준 섹션에서 이 문서는 수신지 기반 라우팅이 선택한 일반 라우팅 경로를 따라 MPLS 포워딩을 수행하는 장치에 LDP 구현을 권고했다. 이는 범위가 제한된 엔지니어링 판단이었다. 보편적 의무 사항도, 구현 인증서도, 운영 중인 네트워크에서 온 보고서도 아니었다.

2001년 1월 Informational RFC로 공개된 이 문서는 적용 범위에 대한 질문에 답했다. MPLS 라벨을 배포하는 여러 가능한 방식 중 기본 LDP는 어디에 들어맞는가? 그 답은 일반 라우팅 경로 주위에 경계를 그렸다. 이 경계를 정확히 읽으려면 프로토콜의 적합성이 운영상의 사실을 대신하지 않도록 거부해야 한다.

범위 안의 경로는 일반 라우팅 경로였다

MPLS 포워딩은 인접한 LSR(Label Switching Router)들이 서로 간, 그리고 그들을 통과하는 라벨의 의미를 공유할 것을 요구했다. LDP는 한 LSR이 자신이 만든 바인딩을 알리는 절차를 제공했다. RFC 3037은 이 절차들이 수신지 기반 라우팅이 이미 선택한 경로, 즉 MPLS 홉바이홉 포워딩을 따른 라벨 배포를 지원한다고 기술했다.

이 역할은 이기종 장비를 가로지를 수 있었다. LDP와 IP 라우팅 평면, ATM 또는 프레임 릴레이 크로스커넥트를 프로그래밍할 수 있는 소프트웨어가 결합하면 별도의 오버레이나 기술 고유의 주소 지정·라우팅 체계 없이도 스위칭 네트워크를 통해 IP를 운반할 수 있었다. 독립형 LDP는 또한 모든 홉에서 피기백 가능한 동일한 라우팅 프로토콜을 요구하는 일을 피했다.

각 “할 수 있었다”는 대상이 제한적이다. 이 아키텍처는 하나의 의존성을 제거할 수 있었다. 그러나 이름이 붙은 스위치에 크로스커넥트 소프트웨어가 존재하는지, 모든 홉이 세션을 수립하는지, 그 결과 경로가 트래픽을 실어 나르는지는 증명하지 않았다. 적용성은 시스템을 조립하는 한 가지 방법을 식별했다. 조립이 실제로 일어났다는 보고가 아니었다.

같은 경계가 기본 LDP와 트래픽 엔지니어링을 분리했다. 명시적 라우팅된 LSP는 일반 라우팅이 선택할 경로를 따를 필요가 없었다. RFC 3037은 CR-LDP와 RSVP-TE 확장을 두 가지 가능한 설정 메커니즘으로 명시했고, 당시 기술적 우위에 대한 합의가 없다는 점을 기록했다. 관리자는 자신의 필요와 상황에 따라 선택하게 되어 있었다. 기본 LDP의 확장 메커니즘은 추가 작업을 가능하게 했을 뿐, 확장 지점이 존재한다는 이유만으로 그 확장을 기본 프로토콜의 일부로 만들지 않았다.

권고는 모든 상자가 아니라 하나의 기능에 붙었다

요구 문장은 정밀했다. 구현은 일반 라우팅된 수신지 기반 경로를 따라 MPLS 포워딩을 수행하는 장치에 대해 권고되었다. 조건이 중요하다. 이 기능 밖의 장치는 기본 LDP가 없다는 이유만으로 비준수가 되지 않으며, LDP 코드가 들어 있는 장치도 적용성 명세가 그렇게 선호한다는 이유만으로 운영 중이 되지 않는다.

구현은 여러 증빙 중 하나일 뿐이다. 소프트웨어는 기능이 비활성화된 채로 존재할 수 있다. 활성화된 프로세스가 피어를 찾지 못할 수 있다. 탐색이 TCP 연결로 이어지지 않을 수 있다. 연결이 매개변수 협상에 실패할 수 있다. 운영 세션이 유용한 바인딩을 전혀 교환하지 않을 수 있다. 바인딩이 포워딩 테이블에 도달하지 못할 수 있다. 프로그래밍된 라벨이 패킷 하나도 보지 못할 수 있다.

표준은 첫 번째 역량을 권고하면서 이후 어떤 상태도 관측하지 않았다. 이는 문서의 약점이 아니다. 바로 그 덕분에 권고가 각 제품과 운영자의 런타임을 모른 채 가정하지 않고 제품과 운영자를 넘어 다닐 수 있다.

세션은 연속된 단계였지, 단 하나의 녹색 불이 아니었다

RFC 3037은 LDP 제어 경로를 순서 있는 단계로 요약했다. 탐색은 잠재적 피어를 찾는다. 세션 설정은 TCP 연결을 수립한다. 피어들은 라벨 배포 방식을 포함한 매개변수를 협상한다. 합의 이후에만 세션이 라벨 배포를 위한 운영 세션이 된다.

TCP는 세션 메시지에 신뢰성 있는 전달을 제공하여, 배포된 라벨과 관련 LSP 상태가 주기적 갱신 없이 유지되도록 했다. 그러나 신뢰성은 바이트 스트림에 속한 것이다. 피어가 의도된 의미를 수용했다거나, 바인딩이 라우팅과 계속 정렬되어 있다거나, 포워딩 하드웨어가 프로그래밍되었다거나, 패킷이 수신지에 도달했다는 것을 증명하지 않는다.

주기적 바인딩 갱신의 부재는 증거 부담의 배치도 바꿨다. 내구성 있는 상태는 효율적이었지만, 이후 포워딩 장애를 조사하는 운영자는 재전송의 부재로부터 신선함을 추론할 수 없었다. 세션 연속성, 라우팅 의존성, 바인딩 수명 주기, 데이터 평면 사용은 각자 자신만의 타임스탬프를 필요로 했다.

모드 메뉴는 자원 논리를 담은 코드였다

LDP는 하나의 보편적 동작 조합을 규정하지 않았다. Downstream Unsolicited 모드에서 LSR은 어떤 FEC를 그 FEC에 대한 포워딩 준비가 되었을 때 알린다. Downstream on Demand 모드에서는 특정 요청에 응답한다. Liberal retention은 즉시 필요하지 않아도 피어로부터 학습한 라벨을 유지하고, conservative retention은 사용하지 않는 라벨을 내려놓는다. Independent control는 LSR이 스스로 판단할 때 알리도록 허용하고, ordered control는 FEC 넥스트 홉으로부터의 바인딩이나 이그레스 상태를 기다린다.

RFC 3037은 이 선택들을 희소성 중심으로 묶었다. ATM과 프레임 릴레이 링크처럼 라벨 값이 제약될 때, 이 문서는 온디맨드 배포, 보수적 유지, 순차 제어를 적절하다고 규정했다. 라벨이 풍부할 때는 비요청 배포, liberal 유지, 독립 제어가 유용한 라벨이 이미 있으므로 넥스트 홉 변경에 더 빠르게 대응할 수 있었다.

“적절하다”는 것은 조건부였지 절대적이지 않았다. 프로토콜은 다른 조합과 하이브리드 변형도 허용했다. 라벨을 아끼는 것은 유지된 대안을 버리는 대가를 치렀고, 대안을 유지하는 것은 상태를 소비했다. 일찍 알리는 것은 업스트림 청구가 나타나는 시점을 바꿨고, 기다리는 것은 설정 의존성을 바꿨다. 문서는 모든 네트워크에서 어떤 선택이 이기는지 보여주는 벤치마크가 아니라 결정 표면을 제공했다.

요구된 역량은 여전히 비활성화될 수 있었다

루프 탐지 규칙은 역량과 상태의 구분을 명시적으로 만들었다. LDP는 비-TTL MPLS 클라우드를 통과하는 LSP를 보호하는 메커니즘을 정의했다. 준수 LSR은 이를 구현해야 했지만, 운영자는 구성으로 이를 비활성화할 수 있었다.

따라서 한 장치는 준수를 진실로 보고하면서 동시에 루프 탐지가 꺼져 있음을 진실로 보고할 수 있었다. 활성화된 장치조차 도메인 전역 보호를 확립하지 않는다. 유용한 증거 사슬은 구현 지원, 로컬 구성, 피어 매개변수, 전파된 경로 벡터 또는 홉 정보, 라우트 상태, 관측된 포워딩이었다.

확장 메커니즘에도 같은 한계가 있었다. LDP는 새 메시지와 TLV를 도입하고, 인식되지 않는 것을 탐지하며, 구현이 지원하지 않을 때 응답하는 방법을 정의했다. RFC 3037은 모든 미래의 개선이 하위 호환될 수는 없다고 경고했다. 깔끔한 미지 TLV 절차는 진화를 더 안전하게 만들었다. 그러나 두 피어가 특정 확장을 공유한다는 것을 증명하지는 않았다.

확장성 주장은 용량이 아니라 비용을 명명했다

문서는 증분 배포가 확장될 수 있는 이유를 설명했다. 바인딩은 주기적 갱신이 필요하지 않았다. 또한 그 반대가 되는 비용도 명명했다. 희소 라벨 모드는 할당을 제한했다. Liberal 유지는 넥스트 홉 변경 이후의 재배포를 줄였다. 구현이 지원하는 TCP 연결 수가 피어 수를 한계 지었다. 경로 벡터 루프 탐지는 메모리, 처리량, 제어 트래픽을 추가했다.

이 문장들 중 어떤 것도 제품의 수치적 용량을 제공하지 않았다. 운영자는 여전히 관측된 피어 수, 라벨 공간 사용, 메모리, CPU, 메시지 비율, 재수렴 동작, 포워딩 결과가 필요했다. 프로토콜 속성은 어떤 카운터가 중요할지 설명할 수 있지만, 그 카운터의 값은 아니다.

보안도 마찬가지로 좁았다. 선택적 TCP MD5는 위조된 세그먼트가 LDP 세션 스트림에 주입되기 더 어렵게 만들 수 있었다. 이는 FEC를 정당한 것으로 인증하거나, 경로를 승인하거나, 바인딩의 진실을 입증하거나, 결과 LSP가 실어 나르는 애플리케이션을 보호하는 것이 아니었다.

이후의 합의가 이전의 스냅샷을 다시 쓰지 않았다

RFC 3037은 CR-LDP와 RSVP-TE가 둘 다 명시적 라우팅된 LSP의 미래적 후보였고, 문서가 기술적 합의 승자를 기록하지 않았던 시점을 포착했다. RFC 3209, RFC 3212, RFC 3213은 이후 두 분기의 상세를 규정했다.

2003년 2월, RFC 3468은 이후 워킹그룹과 IESG의 결정, 즉 새 MPLS 시그널링 작업을 RSVP-TE에 집중하고 CR-LDP에 대한 새 작업을 수행하지 않는다는 결정을 기록했다. 이는 기존 CR-LDP RFC의 상태를 의도적으로 그대로 두었고 개별 기여를 금지하지도 않았다. 그 결정은 나중 날짜의 표준 작업 배분에 대한 증거이다. 모든 운영자가 이전했다거나, 모든 구현이 사라졌다거나, 2001년 1월에 적힌 불확실성이 공개 시점에 거짓이었다는 증거가 아니다.

역사적 교훈은 동사에 대한 규율이다. 표준 기구는 권고한다. 벤더는 구현한다. 운영자는 활성화한다. 피어들은 탐색하고, 연결하고, 합의한다. 제어 평면은 배포한다. 하드웨어는 설치한다. 패킷은 통과한다. RFC 3037은 첫 번째 동사에 대해 명확했다. 나머지는 여전히 증빙을 필요로 했다.

출처

Lu Heng은 RFC 3037이나 관련 표준을 작성하거나 지지하지 않았다. 그의 에세이는 이 글에서 공개된 분석적 렌즈로 사용되었다.