요약

  • RFC 3063은 레이블 할당이 스레드가 되감기기를 기다리도록 만들어, 루프 방지를 경로에서 추론된 약속이 아니라 경로 설정에 부과되는 조건으로 바꿨다.
  • 스레드의 고정 크기 색, 홉 수, TTL은 제어 메시지의 크기를 한정했지만, 보장 자체는 절차 안에 남아 있었다. 즉 배포, 패킷 전달, 모든 포워딩 전이의 안전성을 입증하지는 못했다.

레이블은 마지막 단계였다

RFC 3063에서 눈에 띄는 선택은 루프를 탐지한다는 것이 아니다. 네트워크에는 이미 제어 메시지가 너무 멀리 이동했거나 경로가 불일치하게 되었음을 알아차리는 방법이 있었다. 이 문서는 대신 탐지 절차를 결과를 낳는 행위에 묶는다. 즉 경로 제어 스레드가 되감기기 전까지는 레이블 매핑을 보류한다.

이 구분이 중요한 이유는 MPLS가 매 홉에서 전체 경로를 참조하며 포워딩하지 않기 때문이다. 레이블 스위칭 라우터(LSR)는 포워딩 등가 클래스(FEC)에 대한 레이블 바인딩을 사용한다. 하위 계층인 계층 3 라우팅 상태가 루프를 이루고 있는 상태에서 새로운 다음 홉이 선택되면, 레이블을 너무 일찍 배포하는 것은 그 루프를 물려받은 LSP를 만들어 낼 수 있다. RFC 3063은 설정을 하나의 관문으로 다룬다. 먼저 후보 경로가 스레드 규칙을 만족할 수 있음을 확립한 뒤에야 루프 방지 모드에서 매핑을 내보낸다.

이 메커니즘은 2001년 2월에 발행된 실험(Experimental) 제안으로, 인터넷 표준이 아니었다. 문서는 스레드를 경로 제어 메시지의 수열로 기술한다. 각 스레드는 세 가지 속성, 즉 색, 홉 수, TTL(time-to-live)을 지닌다. 색은 개시 노드의 IP 주소에, 이벤트와 노드에 걸쳐 고유하도록 의도된 이벤트 식별자를 결합한 것이다. 같은 색이 반복되거나 돌아오면 루프가 드러난다. 홉 수는 노드가 경로를 따라 엄격하게 증가하는 척도를 유지하도록 하며, 알고리즘이 루프를 발견했지만 일반적인 수를 쓸 수 없는 경우에는 특수한 '알 수 없음' 값이 처리한다. TTL은 제어 메시지가 이동할 수 있는 거리를 한정한다. 이는 길을 잃은 메시지에 대한 브레이크이지, 루프의 증명 자체가 아니다.

노드는 스레드를 이그레스 쪽으로 확장하거나, 호환되는 작업과 병합하거나, 이미 그 색으로 표시된 경로를 통해 돌아올 때 정지시키거나, 다음 홉이 사라지면 철회하거나, 그 스레드가 통과한 경로를 따라 승인을 되돌려 보냄으로써 되감을 수 있다. 방지 모드에서는 스레드가 되감긴 경우에만 레이블 매핑이 이동한다. 탐지 모드는 다르게 동작한다. 노드는 색이 지정된 스레드를 받았을 때 매핑을 되돌려 보낼 수 있지만, 그 매핑은 스레드를 되감지 않는다. 따라서 동일한 스레드 메커니즘이 서로 다른 두 가지 공개 정책을 지원하며, 둘 다를 단순히 “루프 방지”라고 부르면 이 운영상의 구분이 가려지게 된다.

이 제안의 경제성 역시 구체적이다. 크기가 경로에 따라 커지는 경로 벡터를 실어 나르는 것을 피한다. 대신 각 메시지는 고정 폭의 스레드 객체를 지니고, 라우터는 스레드가 지나가는 동안 링크에 색과 홉 수 상태를 기억한다. 되감기 이후에는 활성 색을 버리고 홉 수 상태만 남긴다. RFC 3063은 이를 통해 메시지 크기가 네트워크 크기와 독립적으로 한정되고 다음 홉 변경이 후보 경로의 다운스트림 노드에 국한된다고 주장한다. 이는 저자들의 설계 비교이며, 운영 네트워크에 대해 보고된 측정치가 아니다.

이 메커니즘은 새 스레드가 계층 3 루프를 만나는 동안 이전 경로를 유지할 수 있지만, RFC는 그 선택을 구현에 명시적으로 맡긴다. 또한 순차적 다운스트림 할당, VC 병합이 있는 네트워크와 없는 네트워크, 서로 다른 스레드를 사용한 부하 분할을 논의한다. 이러한 확장은 제안된 알고리즘의 폭을 넓힐 뿐, 실험 RFC를 벤더가 출하했거나 운영자가 사용했다는 증거로 바꾸지는 못한다.

패킷 추적이 아니라 제어 평면 영수증

RFC 3031의 MPLS 아키텍처는 레이블 배포 절차와 레이블 스위칭 포워딩을 분리한다. 따라서 되감기는 알고리즘이 검사한 제어 평면 상태에 대해 정확한 말을 해 줄 뿐이다. 그것은 레이블이 모든 포워딩 테이블에 올바르게 설치되었다는 것, 패킷이 그 경로를 건넜다는 것, 다른 이벤트 순서에서 과도 루프가 없었다는 것을 보여 주지 않는다. 이러한 주장에는 포워딩 평면 증거가 필요하다. FIB 상태, 카운터, 패킷 프로브, 그리고 정의된 관측 구간이 그것이다.

이후의 LDP 명세 RFC 5036은 Path Vector와 Hop Count TLV를 이용한 구성 가능한 루프 탐지를 문서화한다. 경로 벡터는 지나온 LSR 식별자를 기록하며, 식별자의 반복이나 구성된 한도에 도달하면 루프 처리가 이루어진다. 이는 RFC 3063의 스레드 제안과는 별개의 표준 트랙 LDP 메커니즘이다. 이후 명세에 그 존재가 있다고 해서 스레드 알고리즘의 배포 비중을 알 수 없으며, 표준화 과정이 기술적 이유로 RFC 3063을 거부했다는 것을 증명하지도 않는다. RFC 5715는 이후 토폴로지 변경 이후의 루프 없는 수렴을 다루는데, 이는 루프가 있는 LSP의 설치를 거부하는 문제와 관련되면서도 별개의 문제다.

역사적 교훈은 성공이나 실패라는 주장보다 더 좁고 더 유용하다. RFC 3063은 레이블 공개 앞에 제어 평면 영수증을 놓았다. 그 영수증은 계속 커지는 경로 벡터를 실어 나르지 않고도 설정 결정을 한정할 수 있었다. 그 결과물로 나온 경로는 RFC의 모델 안에서 “루프 없는” 것이었다. 실제 네트워크가 그 모델을 구현했는지, 변경 중에 이전 경로를 유지했는지, 패킷을 올바르게 전달했는지는 별개의 질문으로 남는다.