요약

  • RFC 3353은 트래픽 기반 멀티캐스트 LSP가 부트스트랩 의존성을 담을 수 있음을 보여주었다. 새 브랜치는 트래픽을 트리거로 필요로 했지만, 브랜치가 존재하기 전에는 레이어 2가 그 트래픽을 전달할 수 없었다.
  • 레이어 2/레이어 3 혼합 포워딩 또는 업스트림 주도 라벨 설정이 다리 역할을 제공했지만, 패킷 도착, 라우팅 상태, 라벨 신호 처리, 프로그램된 복제, 수신자 전달은 여전히 별개의 사실이었다.

어떤 멀티캐스트 트리가 이미 한 수신자에게 패킷을 전달하고 있다고 가정하자. 다른 다운스트림 라벨 스위칭 라우터 뒤에 두 번째 수신자가 나타났다. 경제적인 정책은 매력적이다. 트래픽이 존재할 때만 라벨을 할당하는 것이다. 두 번째 라우터는 패킷을 보고, 해당 스트림이 중요하다는 것을 학습하고, 새로운 라벨 지정 브랜치를 트리거해야 한다.

그러나 그럴 수 없다. 적어도 레이어 2만으로는. 패킷은 아직 수립되지 않은 라벨 스위치드 경로를 통해 도착하지 않을 것이다. 트리거는 경로를 기다리고, 경로는 트리거를 기다린다.

이것이 RFC 3353 섹션 5.3.1에서 설명한 "닭이 먼저냐 달걀이 먼저냐" 문제다. 이 표현이 중요한 이유는 프레임워크 다이어그램이 감출 수 있는 것을 드러내기 때문이다. "트래픽 기반"은 자기완결적인 정책처럼 들린다. 그러나 분기되는 시스템에서 그것은 의존성 그래프다. 다운스트림 라벨 경로가 존재하기 전에 누군가는 첫 패킷을 관찰해야 하고, 누군가는 그 관찰을 바인딩으로 바꿀 권한을 가져야 한다.

RFC 3353은 프로토콜 표준이 아니라 Informational 개요 문서였다. 그 임무는 IP 멀티캐스트 라우팅이 MPLS와 만날 때 생기는 선택들을 지도화하는 것이었다. 유니캐스트는 라벨 스위칭을 비교적 선형적으로 보이게 했다. 포워딩 등가 클래스가 다음 홉을 가리키고, 라벨은 안정적인 경로를 따라갈 수 있다. 멀티캐스트에는 소스, 그룹, 여러 개의 송출 인터페이스가 있었다. 그 포워딩 대상은 트리였고, 서로 다른 라우팅 프로토콜이 서로 다른 트리를 구축할 수 있었다.

세분성은 이미 더 비쌌다. 공유 트리는(*,G)상태를 사용했는데, 소스와 무관하게 그룹당 하나의 트리였다. 소스 트리는(S,G)상태를 사용했는데, 소스와 그룹의 조합마다 하나의 트리였다. 공유 상태는 라벨 수를 줄일 수 있지만, 이를 엔드투엔드로 매핑하려면 멀티포인트투멀티포인트 동작과 병합이 필요할 수 있었다. 소스별 상태는 일부 병합 문제를 피하는 대신 더 많은 라벨을 소비했다. RFC 3353은 어떤 표현도 모든 네트워크를 지배한다고 주장하지 않았다.

플러드 앤 프루닝 방식의 프로토콜은 타이밍을 더 날카롭게 만들었다. 이들은 데이터가 나타나면 상태를 만들고, 원하지 않는 브랜치를 프루닝하고, 이후 비활동 상태가 되면 상태를 제거할 수 있었다. 그 트리는 휘발성이었다. 레이어 2가 모든 변화를 미러링한다면 라벨 설정이 빨라야 했고 라벨 공간은 뒤집힐 수 있었다. 트래픽 전에 라벨을 설치하면 사용되지 않는 트리가 자원을 소비했다. 설치가 트래픽을 기다린다면 첫 패킷이 제어 메커니즘의 일부가 되었다.

프레임워크는 세 가지 트리거를 구분했다. 요청 기반 LSP는 멀티캐스트 Join, Prune 또는 자원 예약 메시지를 따를 수 있었다. 토폴로지 기반 LSP는 패킷이 흐르지 않더라도 멀티캐스트 라우팅 테이블을 복제할 수 있었다. 트래픽 기반 LSP는 실제 데이터가 도착할 때까지 기다릴 수 있었다. 각 방식은 하나의 속성을 얻고 다른 하나를 지불했다. 제어 결합, 유휴 상태, 설정 지연, 프로토콜 확장 또는 관찰 복잡성이 그 대가였다.

부트스트랩 문제는 트래픽 기반 선택이 라벨 방향과 만날 때 나타난다. 업스트림 LSR이 이미 한 브랜치 쪽으로 스트림을 스위칭하고 있고 두 번째 다운스트림 LSR이 참여한다고 하자. 새 다운스트림 노드가 트래픽에서 트리거하려면 그 스트림을 수신해야 한다. 레이어 2에서 수신한다면, 빠져 있던 LSP가 어떻게든 이미 만들어진 것이다. 레이어 3에서 수신한다면, 업스트림 노드는 기존 스트림을 스위칭하면서 새 브랜치도 라우팅할 수 있어야 한다.

RFC 3353은 이 능력을 혼합 L2/L3 포워딩이라고 불렀다. 하나의 수신 멀티캐스트 패킷은 일부 인터페이스로는 라벨 스위칭을 통해, 다른 인터페이스로는 일반 IP 포워딩을 통해 나갈 수 있었다. 레이어 3 엔진은 또한 어떤 브랜치가 이미 레이어 2에서 처리되는지 알아야 했고, 그렇지 않으면 중복 패킷을 내보낼 수 있었다. 혼합 포워딩은 미학적 하이브리드가 아니었다. 그것은 가역적 부트스트랩 표면이었다. 첫 패킷은 라우트된 브랜치를 통해 이동하고, 설정에 필요한 관찰을 제공하고, 이후 패킷들이 라벨 지정 브랜치로 옮겨갈 수 있게 했다.

혼합 포워딩이 없다면 주도권은 업스트림으로 옮겨져야 했다. 업스트림 LSR은 배포 모델에 따라 다운스트림 라벨을 요청하거나 업스트림 할당 라벨을 광고할 수 있었다. RFC 3353의 호환성 표는 이 제약을 명시했다. 다운스트림 측이 라벨을 요청하는 트래픽 기반 동작은 혼합 L2/L3 포워딩이 있을 때만 작동했다. 트리거와 배포 모드는 독립적인 메뉴 선택이 아니었다.

이것이 이 글의 중심 증거 경계다. 업스트림 노드에서 관찰된 패킷은 하나의 패킷이 하나의 관찰 지점에 도달했음을 증명한다. 멀티캐스트 포워딩 캐시 미스는 로컬 캐시에 항목이 없었음을 증명한다. 멀티캐스트 라우팅 테이블 행은 로컬 제어 프로세스가 브랜치 설명을 설치하거나 유지했음을 증명한다. 라벨 메시지는 범위가 한정된 교환을 증명한다. 프로그램된 복제 항목은 로컬 포워딩 동작을 증명한다. 그중 어느 것도, 단독으로는, 모든 리프가 스트림을 수신했음을 증명하지 않는다.

RFC 3353의 Unix 포워딩 캐시 예시는 설정 이후에도 같은 경계를 보여준다. 첫 멀티캐스트 패킷은 커널의 멀티캐스트 포워딩 캐시에서 미스할 수 있었다. 멀티캐스트 데몬이 경로를 공급했고, 이후 패킷들은 레이어 2에서 스위칭될 수 있었다. 그러나 레이어 2가 인수하면 레이어 3 경로는 더 이상 그 패킷들을 보지 못한다. 레이어 3 캐시가 트래픽 카운터에 따라 항목을 만료한다면, 그 시야는 이제 살아 있는 스트림을 노화시켜 제거할 수 있었다.

제안된 해답은 레이어 2 측정으로 레이어 3 캐시 카운터를 갱신하는 것이었다. 그것은 실용적이었지만 하나의 투영을 만들었다. 그 카운터는 더 이상 "이 레이어 3 경로가 포워딩한 패킷"을 의미하지 않았다. 그것은 "현재 작업을 수행하는 레이어에서 보고된 활동"을 의미했다. 그 유용성은 소스, 타이밍, 리셋 동작, 귀속에 달려 있었다. 실행을 한 레이어 아래로 내리는 것이 관찰을 제거하지는 않았다. 관찰이 레이어 경계를 넘어서 이루어지게 만들었을 뿐이다.

공유 트리와 소스 트리는 또 다른 전환 문제를 더했다. PIM-SM에서 수신자가 랑데부 포인트 트리에서 소스 트리로 이동하는 동안(*,G)와(S,G)상태가 공존할 수 있었다. 같은 소스의 패킷이 잠시 두 수신 경로를 통해 라우터에 도달할 수 있었다. 레이어 3는 소스별 상태로 부적절한 복제본을 억제할 수 있었다. 순수 레이어 2 동작은 임시 중복을 수용하거나 더 많은 라벨과 병합을 요구했다. 다시 말해, 라벨은 어떤 복제본이 옳은지 결정하는 라우팅 의미론을 지우지 않았다.

캡슐화는 더 어려운 선을 그었다. 공유 트리의 송신자는 루트 쪽으로 패킷을 터널링할 수 있고, 그곳에서 패킷이 디캡슐화되었다. 그것은 레이어 3 동작이었으므로, 그 경계를 가로지르는 끊김 없는 엔드투엔드 레이어 2 LSP 경로는 존재할 수 없었다. MPLS는 여전히 다른 브랜치나 터널을 스위칭할 수 있었지만, 아키텍처 다이어그램은 패킷 해석이 IP로 돌아오는 지점을 보여주어야 했다.

라벨 배포 메커니즘은 그 자체의 트레이드오프를 지니고 있었다. 멀티캐스트 라우팅 메시지에 매핑을 실어 보내면 두 종류의 상태가 동기화되고 별도 메시지가 줄어들었다. 동시에 MPLS 동작을 각 멀티캐스트 프로토콜에 묶고, 일부 트리거 조합을 배제하고, LDP의 신뢰성 있는 TCP 교환을 주기적 소프트 상태로 교환하는 경우가 많았다. 동기화된 광고는 유용한 증거였지만, 브랜치가 설치되었거나 트래픽이 전환을 통과했다는 증명은 아니었다.

멀티액세스 링크는 소유권을 더 복잡하게 만들었다. 여러 다운스트림 라우터가 하나의 공유 매체에서 같은 멀티캐스트 라벨을 필요로 할 수 있었다. 이들은 모든 할당을 기억하거나, 라벨 공간을 나누거나, 할당자를 선출할 수 있었다. 업스트림 할당은 하나의 업스트림 노드가 트리를 공급한다는 사실을 단순화했지만, 토폴로지 변경이 그 할당자를 교체할 수 있었다. 다운스트림 할당은 업스트림 변경을 가로질러 라벨을 보존할 수 있었지만, 여러 다운스트림 노드가 서로 다른 값을 제안할 수 있었다. RFC 3353은 올바른 답이 장애 비용과 운영 비용에 달려 있으므로 선택을 열어 두었다.

이후 표준들은 트리를 더 명시적으로 만들었다. RFC 4461은 브랜치 복제, 리프 추가·삭제, 장애 보고, 확장성을 포함한 포인트투멀티포인트 트래픽 엔지니어링 LSP의 요구사항을 기술했다. RFC 4875는 이어서 P2MP LSP가 브랜치 라우터에서 결합되는 복수의 소스투리프 서브-LSP로 구성되는 RSVP-TE 신호 처리를 정의했다. 여기에는 중요한 한정이 포함되어 있었다. 데이터 플레인이 그 지점에서 트래픽을 복제하지 않더라도 신호 상태는 분기할 수 있다. 제어 플레인의 트리는 여전히 패킷 수신이 아니었다.

RFC 5332도 2002년 그림의 한 조각을 바로잡았다. RFC 3353은 MPLS 유니캐스트와 멀티캐스트를 위한 별도의 링크 계층 코드포인트를 언급했다. RFC 5332는 이 사용이 한 번도 배포되지 않았음을 기록하고, 두 번째 코드포인트를 멀티액세스 매체의 업스트림 할당 라벨 중심으로 재정의했다. 역사적 아키텍처는 그 바로잡음을 보존해야 한다. 초기 프레임워크는 보장된 배포 경로가 아니라 하나의 설계 공간을 포착한 것이었다.

2012년까지 RFC 6513의 멀티캐스트 VPN 아키텍처는 여전히 배포 트리와 유니캐스트 터널을 통한 인그레스 복제 사이의 선택을 노출하고 있었다. 엣지에서 복제하고 대역폭을 지불하거나, 공유 전송 상태를 구축하고 제어 플레인 복잡성을 지불하는 것이다. 이름과 프로토콜은 바뀌었지만 복제는 결코 공짜가 되지 않았다.

RFC 3353이 가치 있는 이유는 즉시 완성되는 자동화라는 허구를 거부했기 때문이다. 라벨 지정 브랜치 이전에는 패킷, 라우트된 우회 경로 또는 업스트림 결정이 있었다. 신호 처리 이후에도 여전히 프로그래밍, 복제, 확인해야 할 관찰이 남았다. 그 순서가 곧 시스템이었다.

출처