요약

  • RFC 3473는 RSVP-TE 장애 Notify가 기록된 비인접 노드에 직접 도달하고, RFC 2961의 확인(ACK) 메커니즘으로 수신을 확인할 수 있게 했다.
  • 또한 이 문서는 Notify가 PathErr나 ResvErr를 대체하지 않는다고 명시했다. 따라서 ACK는 장애 통보가 도착했다는 증거일 뿐, 상태 수렴, 보호 전환, 트래픽 복구 또는 애플리케이션 복구를 증명하지 않는다.

경보는 그것이 보고하는 복구보다 앞서 도착할 수 있다. RFC 3473는 이 구분을 프로토콜 형태로 드러냈다.

2003년 1월에 발표된 이 문서는 GMPLS 기능을 RSVP-TE에 담았다. RFC 3471의 일반화 라벨 모델 상당 부분을 Path와 Resv 메시지에 반영했다. 패킷, 타임슬롯, 파장, 포트 스위칭을 위한 라벨, 양방향 설정, 라벨 제약, 보호 속성, 분리된 제어 채널, 관리 상태, 재시작 복구 등이 그것이다. 가장 밀접한 쌍둥이 문서인 RFC 3472는 CR-LDP에 대해 같은 역할을 수행했다.

RSVP-TE에 추가된 한 가지 기능이 특정 문제를 해결했다. 평범한 PathErr와 ResvErr 메시지는 RSVP 상태를 따라 홉 단위로 전달된다. 명시적 라우팅된 LSP 장애에 가장 즉각 대응해야 할 노드는 몇 홉 떨어져 있을 수 있다. 평범한 오류 경로를 기다리면 인그레스 또는 경로의 지정된 제어 노드에서 의사결정이 지연될 수 있다.

이에 RFC 3473은 Notify Request 객체를 정의했다. Path 메시지는 상향 통보를 요청할 수 있고, Resv 메시지는 하향 통보를 요청할 수 있다. 이 객체는 IPv4 또는 IPv6 Notify Node를 지명한다. 각 수신자는 그 주소를 관련 상태와 함께 저장해야 하고, 중간 노드는 요청을 다음 홉으로 전달해야 한다.

이것은 영구적인 종단 간 식별자가 아니었다. 로컬 정책은 발신 Notify Node 주소를 바꿀 수 있다. 한 메시지가 여러 Notify Request 객체를 담을 때는 첫 번째만 유효하며, 나머지는 무시될 수 있고 전파되어서는 안 된다. 가장 중요한 것은, 요청을 담고 있다고 해서 Notify가 실제로 생성될 것이라는 보장은 없다는 점이다.

자격을 갖춘 오류가 발생하면 감지 노드는 기록된 비인접 목적지로 Notify를 보낼 수 있다. 대상이 아닌 중간 노드는 이를 그대로 전달하거나, 발신자는 대상 노드를 직접 가리키는 새 IP 헤더로 메시지를 캡슐화할 수 있다. 메시지는 라우터 얼러트 옵션을 제외했다. 장애 보고는 그것이 보고하는 장애의 홉 단위 경로와 구별되는 자기만의 경로를 갖게 된 것이다.

Notify에는 ERROR_SPEC와 세션 정보가 담긴다. ERROR_SPEC는 오류와 감지 노드 또는 장애 링크를 식별한다. 발신자 또는 플로우 기술자는 영향받는 RSVP 세션의 범위를 한정한다. 하나의 물리적 이벤트가 양방향 통보를 만들 수 있지만, 해당하는 선행 요청이 존재하지 않으면 노드는 이를 임의로 만들 수 없다.

신뢰성 있는 전달 메커니즘은 RFC 2961이 공급했다. 메시지 식별자 덕분에 Notify를 구별할 수 있고, 수신 Notify Node는 Ack를 돌려보내야 한다. 이 교환은 가치 있는 하나의 질문에 답했다. 이 RSVP 메시지가 이 목적지에 도달했는가?

그러나 운영자가 확인 메시지에 얹고 싶어 하는 다른 질문들에는 답하지 않았다. Ack는 ERROR_SPEC가 물리적으로 정확하다고 말하지 않는다. 모든 중간 RSVP 상태가 제거되거나 갱신되었다고 말하지 않는다. 대체 경로에 용량이 있거나, 보호 스위칭이 일어났거나, 광 크로스커넥트가 이동했거나, 패킷이 흐르거나, 애플리케이션이 재개되었다고도 말하지 않는다.

RFC 3473은 경계를 명시했다. Notify는 기존 오류 메시지를 대체하지 않는다. PathErr나 ResvErr를 유발하는 장애는 Notify도 유발할 수 있다. 빠른 메시지는 보충적인 증거 경로일 뿐, 평범한 RSVP 상태 기계의 커밋 기록이 아니다.

이 구분은 Path_State_Removed 플래그에서도 나타난다. 전통적인 PathErr 전달은 중간 노드가 실제로 동작하리라는 보장이 없다. RFC 3473는 노드가 관련 Path 상태를 실제로 폐기했음을 보고할 수 있게 했다. 따라서 수신한 Notify와 상태 제거 증거를 담은 PathErr는 서로 다른 수신 증명이다. 어느 하나만으로는 모든 홉을 설명할 수 없다.

통보 집계는 또 하나의 층위를 추가한다. 노드는 같은 Notify Node로 향하고 같은 ERROR_SPEC를 공유하는 통보를 결합하려 노력해야 한다. 그룹화 방식은 구현에 따라 다르다. 이벤트 기반, 타이머 기반 또는 그 외 방식일 수 있다. 타이머 기반 구현의 기본 간격은 1밀리초다. 이는 심각한 장애 상황에서 제어 부하를 줄일 수 있지만, 메시지 시간이 곧 이벤트 시간이 아니며, 하나의 봉투가 여러 세션을 요약하면서 그 복구를 원자적으로 만들지 않음을 의미한다.

관리 상태는 수신 확인만으로는 부족한 이유를 보여준다. 중간 노드나 이그레스 노드는 Down 상태를 담은 Notify를 보낼 수 있다. 발신자는 그 후 설정 가능한 기간(기본 30초) 안에 Down 상태를 담은 대응하는 Path 메시지가 돌아오는지 확인해야 한다. 확인 상태가 나타나지 않으면 노드는 하향 상태를 철거하고 상향으로 tear 또는 오류를 보내야 한다. 프로토콜은 첫 장애 통보를 완료로 착각하지 않는다.

제어 채널 장애는 더 미묘한 사례를 제공한다. 재시작 대기 동안 이웃 노드는 리프레시가 계속되는 것처럼 기존 RSVP와 포워딩 상태를 유지할 수 있다. 제어 채널이 저하되었다가 이후 활성화되었다고 상향 노드에 통보할 수도 있다. 저하 통보는 데이터 플레인 장애를 의미하지 않고, 활성 통보는 모든 상태가 정합되었다는 뜻도 아니다. “복구되었다”라는 같은 말이 통신, RSVP 상태, 라벨 프로그래밍, 물리 신호, 전달된 트래픽을 가리킬 수 있다.

직접 경로는 보안 가정도 바꾸었다. RSVP의 평범한 무결성 모델은 홉 단위다. 홉 단위가 아닌 Notify는 그 사슬을 우회할 수 있으므로, RFC 3473는 동등한 종단 간 무결성과 인증을 위해 IPsec을 지목하거나 직접 Notify를 비활성화할 수 있게 했다. 인증되고 확인까지 받은 경보조차도 유한한 사실만 증명한다. 해당 키의 소유자가 특정 메시지를 보냈고, 특정 수신자가 그것을 받았다는 것뿐이다. 그 밑에 있는 광자, 패킷, 사업 결과를 인증하지 않는다.

이후 문서들은 복구를 더 명시적으로 다루었다. RFC 4090은 fast reroute를, RFC 4872는 종단 간 복구를, RFC 4873은 세그먼트 복구를 다루었다. 이 표준들은 추가적인 제어 동작과 범위를 공급했다. 그러나 통보, 선택, 스위칭, 관측된 복원을 하나의 사실로 합치지는 않았다.

Lu Heng의 실행 코드 원리는 이 선을 명확히 긋는다. 의도된 상태 전이가 그것을 실행해야 하는 시스템에서 관측되기 전까지, 수신된 Notify는 상징적 증거일 뿐이다. 최소 사양 원리는 RFC 3473이 경보 문법만 표준화하고 집계와 정책은 로컬에 남길 수 있었던 이유를 설명한다. 현실 층위 원리는 성공적인 ACK가 복구된 서비스의 권위를 빌리는 것을 막는다.

정직한 장애 기록은 요청을 설치한 Path 또는 Resv, 정책 재작성 후의 실효 목적지, 감지자와 ERROR_SPEC, 모든 세션 기술자, Message ID, 발신 시각, 수신 시각과 Ack를 보존해야 한다. 그리고 PathErr나 ResvErr의 진행 상황, 상태 제거 증거, 보호 또는 철거 결정, 프로그래밍된 하드웨어, 물리 신호, 방향별 트래픽, 애플리케이션 결과는 별도로 보관해야 한다. 마지막 항목들의 결합만이 “복구되었다”를 정당화한다. ACK는 이 이야기에서 훨씬 앞쪽에 속한다.

출처