요약

  • RFC 3654는 Control Element와의 연결이 끊어졌을 때 Forwarding Element가 반드시 포워딩을 계속하거나 반드시 중단해야 한다고 규정하지 않았다. 대신 연결 손실을 감지하고, 연결을 복구하고, 상태를 재동기화하며, FE의 대응을 사전에 정하도록 아키텍처에 요구했다.
  • RFC 7121은 이후 서로 다른 복구 모드를 기술했다. 하나는 연결 이전 상태로 돌아가는 것이고, 다른 하나는 백업 CE를 시도할 수 있으며 타임아웃까지 포워딩을 계속할 수 있다. 재연결만으로 모든 FE 상태가 복원되었다고 입증되지는 않는다.

하나의 시스템, 하나 이상의 역할을 하는 라우터

2003년 11월, RFC 3654는 네트워크 요소를 제어 요소와 포워딩 요소가 협력하는 구성으로 기술했으며, 외부에는 하나의 통합 IP 장치처럼 보일 수 있다고 했다. Control Element(CE)는 라우팅이나 시그널링 프로토콜 같은 제어 기능을 수행했다. Forwarding Element(FE)는 패킷 단위 작업을 처리했다. 이 분리는 논리적인 것이었고, RFC는 두 개의 물리적 섀시를 요구하지도 않았으며 실제 배포된 라우터가 이 아키텍처를 채택했다고 주장하지도 않았다. 문서가 제시한 근거는 공통 메커니즘이 확장성을 개선하고 두 평면이 독립적으로 진화하도록 할 수 있다는 점이었다.RFC 3654

이 분리는 애매한 구간을 만든다. FE에는 여전히 테이블과 프로그래밍된 기능이 남아 있을 수 있지만, 이를 관리하는 CE는 더 이상 연결되어 있지 않다. “컨트롤러가 실패했다”는 말만으로는 FE가 포워딩을 멈췄는지, 현재 상태를 유지하며 계속했는지, 백업을 찾고 있는지 알 수 없다. RFC 3654는 이 질문들을 분리된 문제로 드러냈다.

요구사항은 답이 아니라 결정을 규정했다

아키텍처 요구사항 7은 네 가지 의무를 묶었다: 연결 손실을 감지하고, 복구하고, 상태를 효율적으로 재동기화하며, CE가 부재 중에 FE가 무엇을 해야 하는지 사전에 정하는 것. 문서는 그 마지막 선택의 예로 포워딩 계속과 작업 중단을 제시하지만, 모든 네트워크 요소에 대해 어느 하나를 강제하지는 않는다. 프로토콜 요구사항 8도 같은 경계를 반복한다.RFC 3654

이것은 링크 모니터링 세부사항을 넘어선다. 현재 연결된 CE 없이 내려진 포워딩 결정은 트래픽을 유지하면서 정책 상태를 그대로 둘 수 있고, 중단은 갱신할 수 없는 상태에 기반한 포워딩을 피하지만 서비스를 끊는다. 이는 운영자나 시스템 설계자가 평가해야 할 결과이며, RFC가 관찰되었다고 말하는 결과가 아니다. 요구사항은 아키텍처가 장애 발생 전에 그 행동을 알 수 있도록 하되, 구현의 침묵이 우연히 결정하지 않도록 한다.

이후의 고가용성 규칙은 이 선택에 시계를 달았다

2010년에 Standards Track 프로토콜 사양으로 발표된 RFC 5810은 RFC 3654가 요구한 ForCES 프로토콜과 전송 매핑을 제공했다. RFC 5812는 FE의 능력, 상태, 구성 및 논리 기능 블록에 대한 모델을 정의했다. 이 세 가지는 서로 다르다: FE가 할 수 있는 것, 지금 하고 있는 것, CE가 하기를 원하는 것은 서로 바꿔 쓸 수 없는 기록이다.RFC 5810RFC 5812

2014년, RFC 7121은 네트워크 요소 내부의 고가용성 절차를 추가했다. FE Protocol 주체는 마스터 CE와 백업 CE를 식별하며, 하트비트 간격과 정책이 연결성 문제 감지에 도움을 준다. 기본 모드 0에서는 연결 손실 시 FE가 연결 이전 상태로 돌아가며, 이후 다시 연결되면 FE 상태를 다시 만들어야 한다. 모드 1은 재시작 복구를 사용한다: CE Failover Timeout Interval이 진행되는 동안 FE가 구성된 백업 CE를 라운드 로빈 순서로 시도한다. 미연결 상태에서는 구성된 CE 장애 조치 정책에 따라 포워딩을 계속할 수 있다. 간격이 만료되고 연결되지 않으면 FE는 연결 이전 상태로 들어가 포워딩 경로를 내린다.RFC 7121

재연결은 상태 복구와 같지 않다. RFC 7121은 CE가 FE가 단절 중 잃은 상태를 동기화하려 시도할 수 있다고 말하지만, 동기화 방법은 ForCES 아키텍처 밖에 두며, 일반적으로 새 구성 메시지와 질의가 관여할 것이라고 밝힌다. 따라서 프로토콜은 살아 있는 데이터 경로, 도달 가능한 백업, 그리고 조정된 FE 상태를 구분한다.

하트비트는 입력이지 경로에 대한 판정이 아니다

RFC 3654의 신뢰성 요구사항은 페이로드를 다르게 취급한다. 구성, 포워딩 테이블, 능력 정보는 견고하게 전달되어야 한다. 연결 손실 감지에 쓰이는 하트비트는 엄격한 신뢰성보다 시의성을 우선할 수 있다. 감지기라면 그것은 합리적이지만, 하트비트 전달과 포워딩 정확성은 서로 다른 증거라는 뜻이다. 놓친 신호는 연결 상태 전이에 기여할 수 있다. 그것만으로 물리적 장애, 잘못된 경로, 장치 전체의 상실을 입증하지는 않는다.RFC 3654

또 다른 ForCES 문서인 RFC 3532는 컨트롤러의 모델이 포워딩 요소보다 뒤처질 수 있는 동적 파티셔닝과 자원 변경을 다뤘다. 이것은 인접한 문제이지 이 글의 주제가 아니다. 이 글은 자원 재할당이나 낡은 인벤토리가 아니라 연결 손실 이후의 사전 정된 FE 행동과 고가용성 복구를 다룬다.RFC 3532RFC 3746

이 문서들은 아키텍처와 프로토콜 요구사항을 기록한 것이며, 특정 벤더, 배포, 장애 사건, 채택률을 기록하지 않는다. RFC 3654는 Informational이며, 이후의 Standards Track 사양들은 이 작업이 어떻게 구체화되었는지 보여주지만 어떤 특정 네트워크가 사용했다는 뜻은 아니다. 라우터 수준의 포워딩 의무는 RFC 1812가 제공하는 별개의 맥락이다.RFC 1812RFC 3654 기록RFC 3654 Datatracker

출처