요약

  • RFC 3446은 여러 활성 PIM-SM 랑데부 포인트가 하나의 Anycast 주소를 광고하여 발신자와 수신자가 토폴로지상 가장 가까운 인스턴스 쪽으로 이동하도록 했고, 멀리 떨어진 단일 RP에 대한 의존을 줄였습니다.
  • 공유 주소는 복제본 간 조율을 식별할 수 없었습니다. MSDP 피어링, 라우터 ID, Source-Active 출발지/RPF 의미 체계에는 고유한 유니캐스트 주소가 필요했으며, 경로 선택이 성공했다고 해서 동기화된 상태나 멀티캐스트 전달이 증명되지는 않았습니다.

하나의 활성 매핑이 지리를 비싸게 만들었다

스파스 모드 멀티캐스트에서 랑데부 포인트는 만남의 장소였습니다. 발신자는 그곳에 등록했고, 수신자는 그곳을 향해 참여했으며, 공유 트리는 그곳에서 시작될 수 있었습니다.RFC 2362에 기록된 PIM-SM 설계에서는 하나의 멀티캐스트 그룹에 여러 RP를 설정할 수 있었지만, 한 번에 활성화될 수 있는 그룹-RP 매핑은 하나뿐이었습니다.

이 단일 매핑은 주소 이상의 것을 집중시켰습니다. 등록 캡슐화 해제를 집중시키고, 활성 RP가 실패할 때 복구 시간을 늘렸으며, 트래픽을 토폴로지적으로 먼 위치로 끌어당길 수 있었습니다.RFC 3446은 구체적인 대륙 규모 사례를 제시합니다. 유럽의 발신자와 수신자가 처음에는 미국의 RP로 트래픽을 보내고 비싼 링크를 다시 왕복해야 할 수 있었습니다.

운영자는 멀티캐스트 범위 224.0.0.0/4를 여러 RP에 나눌 수 있었습니다. 그러나 정적 분할은 트래픽 분포에 대한 사전 지식을 요구했습니다. 그룹이 바뀌면 균형을 맞추려면 주기적인 재설정이 필요했습니다. 주소 공간의 대칭성이 곧 워크로드의 대칭성은 아니었습니다.

2003년 1월 Dorian Kim, David Meyer, Hank Kilmer, Dino Farinacci가 발행한 RFC 3446은 인터넷 표준이 아니라 운영 메커니즘을 기술한 문서였습니다. 이 문서의일반 텍스트,RFC Editor 기록,Datatracker 문서,이력,참고 문헌,후속 인용,정오표 검색이 문서적 기록을 확립합니다. 이들은 어떤 특정 백본이 어떻게 수행했는지는 확립하지 않습니다.

앞문은 공유되었다

같은 그룹 범위를 담당하는 모든 RP는 대체로 논리적 루프백에 동일한 Anycast 주소를 받았습니다. 그룹-RP 매핑은 그 공유 주소를 가리켰습니다. 각 RP는 IGP에 /32 도달 가능성을 주입했습니다. 그러면 보통의 유니캐스트 라우팅이 발신자의 등록이나 수신자의 참여를 광고된 경로 중 가장 가까운 쪽으로 이끌었습니다.

이것은 기존 의사결정 체계의 강력한 재활용이었습니다. PIM은 인스턴스를 고르기 위해 새로운 전역 로드 밸런서를 만들 필요가 없었습니다. 도달 가능성의 변화는 클라이언트를 다른 RP 쪽으로 옮길 수 있었고, 여러 RP는 등록 캡슐화 해제 작업을 나눌 수 있었습니다.

그러나 겉으로 보이는 단순함은 설정의 동등성에 의존했습니다. 참여하는 모든 RP는 동일한 그룹 매핑을 가져야 했습니다. RP가 아닌 라우터는 정적 설정, Auto-RP, 또는 이후RFC 5059에 규정된 PIMv2 부트스트랩 메커니즘을 통해 그 매핑을 학습해야 했습니다. 공유된 앞문은 모든 제어 지점이 그 문이 무엇을 의미하는지에 대해 일치할 때에만 선택을 조율했습니다.

백플레인은 움직이지 않는 이름을 필요로 했다

RP들은 또한 활성 발신지에 대한 일관된 시각을 필요로 했습니다. RFC 3446은 그 조율을 위해 MSDP(이후RFC 3618에 문서화)를 사용했습니다. MBGP는 선택 사항이었고, MSDP는 이 메커니즘에서 필수였습니다.

MSDP 피어링은 Anycast 주소를 사용할 수 없었습니다. 그 끝점은 고유한 유니캐스트 주소여야 했습니다. 라우터는 또한 공유 주소를 자신의 라우터 ID로 선택하지 말아야 했습니다. 그렇지 않으면 피어링이나 인접성이 형성되지 않을 수 있었습니다. 가장 핵심적으로, Anycast 주소는 Source-Active 메시지에서 RP 주소로 실려서는 안 됩니다. MSDP 피어-RPF 검사가 실패하기 때문입니다.

이것이 이 문서의 아키텍처적 핵심입니다. 공개 정체성은 “이 요청을 어떤 근처 인스턴스가 받아야 하는가?”에 답했습니다. 고유 정체성은 “이 상태를 어떤 구체적 피어가 시작했으며, 역경로 검사가 어느 끝점을 향해 성공해야 하는가?”에 답했습니다. 한쪽은 의도적으로 인스턴스 정체성을 숨겼고, 다른 쪽은 그것에 의존했습니다.

고유 역할에서 공유 이름을 사용하는 것은 로그를 어지럽히는 것 이상의 문제를 만들었습니다. 조율 알고리즘이 필요로 하는 책임성 자체를 깨뜨렸습니다. Anycast는 복제본을 위한 정체성 체계가 아니라, 그중 하나에 도달하기 위한 라우팅 방법이었습니다.

RP가 늘어나면 거리만이 아니라 상태도 변한다

이 설계는 더 빠른 페일오버와 분산된 캡슐화 해제를 약속했지만, 무료의 이중화는 아니었습니다. MSDP를 이렇게 사용하면 수신자-발신지 경로를 따라(S,G)상태를 강제했습니다. 수신자가 단일 RP에 뿌리를 둔 공유 트리에 머문다면 그 상태는 존재하지 않았을 수도 있었습니다. 랑데부 아키텍처를 옮기면 상태 배치가 바뀌고, 따라서 메모리, 체인지, 문제 해결 표면도 바뀌었습니다.

선택이 정의상 안정적인 것도 아니었습니다. RFC 3446은 유니캐스트 라우팅의 불안정성이 발신자나 수신자가 사용하는 실제 RP를 바꾼다고 언급합니다. Anycast 주소는 그대로인 채 서비스 인스턴스는 이동했습니다. 안정적인 이름이 불안정한 경로를 가릴 수 있었습니다.

보안도 같은 이분법을 따랐습니다. 유니캐스트 라우팅과 RP는 스푸핑 방지 보호가 필요했고, PIM 메시지와 MSDP 피어링에는 무결성 제어가 필요했습니다. 공유 주소로의 합법적으로 보이는 경로는 그 경로를 통해 도달한 RP의 상태를 인증해 주지 않았습니다.

이후의 PIM-SM 규격인RFC 4601과RFC 7761, 일반적인 Anycast 지침인RFC 4786, 그리고 PIM 기반 Anycast-RP 대안인RFC 4610은 주변 아키텍처가 어떻게 진화했는지 보여 줍니다. 이들은 맥락을 제공할 뿐, RFC 3446 단독으로 이후의 선택을 야기했다는 증명은 아닙니다.IANA 멀티캐스트 주소 레지스트리와PIM 매개변수는 할당된 기호를 증명할 뿐, 작동하는 트리나 전달된 패킷을 증명하지 않습니다.

가용성에는 여러 증빙이 있었다

Lu Heng의현실 계층 원칙은 공유 주소, IGP 경로, 선택된 인스턴스, MSDP 발신지 지식, PIM 포워딩 상태, 관찰된 패킷, 수신자 결과를 구분합니다. Anycast 경로는 라우팅 선택을 증명합니다. 그것은 RP 건강 상태, 일관된 매핑, 살아 있는 피어 메시, 완전한 발신지 상태, 성공적인 등록 캡슐화 해제, 또는 전달을 증명하지 않습니다.

실행 코드 우선주의는 운영 증거에 적절한 무게를 부여합니다. 대륙 규모 배치는 멀리 떨어진 단일 RP의 비용과 정적 그룹 공간 분할의 취약한 확장성을 드러냈습니다. 그에 대한 응답은 하나의 전역 컨트롤러를 선언하는 것이 아니라, 토폴로지가 지역적으로 선택하도록 하면서 입구 뒤에서 명시적인 동기화 프로토콜을 실행하는 것이었습니다.

최소 초기 규격개념은 이 절제를 명확히 합니다. 인스턴스를 조율하는 데 필요한 좁은 공유 주소와 규칙만을 표준화하고, 배치 토폴로지와 자발적 채택은 운영자에게 맡긴다는 것입니다. 이것은 편집적 해석이며, 저자들의 사적 의도에 대한 주장이 아닙니다.

RFC 3446의 오래 지속되는 교훈은 수평적 복제에는 서로 반대되는 두 종류의 이름 붙이기가 필요하다는 것입니다. 클라이언트는 복제본을 숨기는 안정적인 정체성을 필요로 합니다. 복제본은 서로를 드러내는 안정적인 정체성을 필요로 합니다. 이 두 역할을 혼동하면 하나의 주소가 주는 편의가 조율에 필요한 출처 추적 능력의 상실로 바뀝니다.

출처