요약

  • RFC 3472는 CR-LDP REQUEST, MAPPING 및 알림 절차에 GMPLS 기능을 인코딩했으며, 양방향 설정에서는 다운스트림 매핑이 돌아오기 전에 업스트림 방향이 사용 가능해질 수 있었다.
  • 따라서 전달된 REQUEST, 유효한 Upstream Label 또는 첫 방향별 트래픽은 부분적 접수일 뿐, 양방향, 물리 회로 또는 애플리케이션 서비스가 완료되었다는 증거가 아니었다.

양방향 경로는 하나의 대상이 한 번에 태어나는 것처럼 들린다. RFC 3472는 더 흥미로운 것을 다루었다: 두 방향이 서로 다른 시점에 실체가 될 수 있는 경로다.

2003년 1월 Standards Track으로 발표된 이 문서는 RFC 3471의 프로토콜 독립적 GMPLS 기능을 CR-LDP 메시지와 TLV로 옮겼다. 일반화 레이블 요청, 레이블, 웨이브밴드, 제안 레이블, 레이블 집합, 보호, 관리 상태 및 인터페이스 식별에 대한 구체적 형식을 정의했다. 당시 가장 가까운 대안은 RFC 3473의 RSVP-TE 인코딩이었다.

비대칭은 REQUEST에서 시작되었다. 양방향 LSP를 요청하려면 개시자가 Upstream Label을 포함해야 했다. 이 레이블은 요청을 보내는 시점에 전달에 유효해야 했다. 수신하는 각 노드는 해당 레이블을 수용할 수 있는지 확인했다. REQUEST를 전달하기 전에 중간 노드는 업스트림 방향의 송출 레이블을 할당하고 로컬 세그먼트들을 연결하는 내부 데이터 경로를 설정해야 했다.

이것은 나중에 설정하겠다는 단순한 약속이 아니었다. 요청은 통과하는 모든 노드가 자신의 업스트림 부분을 사용 가능하게 만든 후에만 앞으로 나아갔다. REQUEST가 종단 노드에 도달했을 때, 그 노드는 제공된 레이블을 사용해 개시자 쪽으로 즉시 업스트림 트래픽을 전송할 수 있었다.

다른 방향은 다른 시간순서를 따랐다. 일반화된 다운스트림 레이블은 MAPPING 메시지에 담겨 개시자 쪽으로 되돌아갔다. 모든 수신자는 매핑된 값이 수용 가능한지 확인했다. 수용 불가능한 값은 알림을 유발했고 Acceptable Label Set을 포함할 수 있었다. 따라서 업스트림 트래픽이 이미 존재할 수 있는 동안에도, 다운스트림 방향은 여전히 선택·검증·설치의 성공적인 귀환 파도에 의존했다.

이 부분 상태는 합법적인 프로토콜 동작이었으며, 자동으로 결함이 아니었다. 그러나 이로 인해 증거 언어가 중요해졌다. “양방향 요청이 수용됨”은 요청이 상대 끝단에 도달했고 업스트림 체인이 사용 가능함을 의미할 수 있다. 그것이 마지막 MAPPING이 반환되었음, 모든 다운스트림 레이블이 설치되었음, 또는 양방향 애플리케이션 교환이 성공했음을 반드시 의미하지는 않았다.

RFC 3472는 실제보다 강해 보이는 상태의 다른 예도 제공했다. Generalized Label Request는 LSP Encoding Type, Switching Type, G-PID를 담았다. 인그레스가 요청을 설정하고, 트랜짓은 보통 그대로 전달하며, Switching Type은 홉별로 바뀔 수 있었다. 모든 노드는 수신 인터페이스, 자기 자신, 송출 인터페이스 또는 터널을 검사했다. 포워딩 인접 터널을 사용하거나 생성할 수 있는지는 로컬 정책이 결정했다. 어떤 단일 전달된 REQUEST도 모든 곳에서 동일한 검사를 대표하지 않았다.

G-PID는 보통 이그레스에서 검사되며, 패킷 스위칭과 PHP에 대한 마지막 이전 홉(penultimate-hop) 예외가 있었다. 더 이른 트랜짓 노드에서 오류가 없었다는 것이 페이로드 유형이 이미 결정적 검사를 통과했음을 의미하지는 않았다.

Suggested Label은 더 약했다. 제안의 오류는 무시되었다. 다운스트림이 다른 레이블을 반환하면 업스트림은 재설정하거나 결과를 거부해야 했다. 가장 중요한 것은, 인그레스가 대응하는 레이블이 다운스트림에서 돌아오기 전까지 제안된 레이블로 데이터를 전송해서는 안 된다는 점이었다. 느린 하드웨어를 위한 선출발은 할당 권한이 아니었다.

Label Set 처리는 물리적 의미를 명시적으로 만들었다. TLV는 개별 레이블이나 범위를 추가하거나 제외할 수 있었다. Label Set이 없다는 것은 모든 레이블이 수용 가능하다는 뜻이지 모두 사용 가능하다는 뜻이 아니었다. 각 노드는 수신한 집합을 자신의 다운스트림 인터페이스 자원과 교차시켰다. 교차가 비어 있으면 요청은 종료되었다. 변환 능력을 갖춘 노드는 전달 전에 집합을 제거할 수 있었다.

논리적 값도 링크마다 달랐다. 교차는 물리적 파장 또는 밴드를 기준으로 해야 했다; 노드는 논리 값을 일관된 물리적 의미로 매핑하거나 폐기해야 했다. 따라서 살아남은 논리 집합만 담은 추적은 이전의 제약과 변환을 생략할 수 있었다.

웨이브밴드는 특히 물리적인 변환을 추가했다. 스위치는 중심 주파수를 기준으로 파장을 미러링할 수 있었다. 그 경우 밴드의 한쪽 끝이 반대쪽 끝으로 나타남을 먼 쪽이 알 수 있도록 시작 레이블과 끝 레이블을 서로 맞바꿨다. 양방향 웨이브밴드 터널은 양방향 모두에서 이 연산을 요구했다. 간격 크기가 일치한다고 해서 파장 연관이 일치하는 것은 아니었다.

Explicit Label Control은 레이블 ER-Hop을 선행 주소 또는 인터페이스 식별자에 결합했다. 잘못된 순서, 방향 비트 또는 중복된 방향 항목은 경로 오류를 낳았다. 이 결합은 레이블의 의미가 인터페이스에서 분리될 수 없기 때문에 중요했다. 그러나 헤드 엔드가 그 정보를 얻는 방법은 문서 밖에 남아 있었다.

제어와 데이터의 분리는 하나의 부등가를 더 만들었다. IF_ID TLV는 시그널링이 다른 채널을 사용할 때 데이터 채널을 명명했고 MAPPING에 담겨 돌아왔다. 제어 세션의 실패는 기존 광 연결을 흔들어서는 안 되었으며, 복구 절차는 연결 무결성을 보존하도록 기대되었다. 따라서 복원된 CR-LDP 세션이 옛 크로스커넥트가 올바름을 증명하지 않았고, 잃어버린 세션이 빛이 멈췄음을 증명하지도 않았다.

실패 동작은 RSVP-TE와의 설계 차이를 드러냈다. CR-LDP에는 RFC 3473의 빠른 실패 알림에 해당하는 것이 없었다. RELEASE와 WITHDRAW는 바깥으로 전파되며 자원을 해제했다; 피드백은 실제 자원을 보고할 수 있었다. 해제 접수가 중요한 이유는 RFC 3472가 양방향 LSP가 제거될 때 업스트림과 다운스트림 레이블을 모두 무효로 만들기 때문이었다. 이후에도 계속 전달하는 하드웨어는 권한 있는 지속이 아니라 오래된 상태(stale)였다.

RFC 3468은 나중에 IETF가 RSVP-TE를 선호하여 CR-LDP의 표준 트랙 개발을 중단하기로 한 결정을 기록했다. 그 제도적 선택은 인터넷 역사의 일부지만, RFC 3472의 공학적 교훈을 지우거나 모든 구현이 한순간에 사라졌음을 증명하지는 않는다.

Lu Heng의 러닝 코드 우위 원칙은 이 경계를 올바르게 놓는다. REQUEST, TLV 또는 MAPPING은 프로그래밍된 경로와 방향별 트래픽이 그 효과를 확인하기 전까지는 기호적 조정 기록이다. 최소 사양 원칙은 로컬 터널 정책과 기술 세부사항이 공통 메시지 문법 밖에 남아 있던 이유를 설명한다. 현실 계층은 인가, 할당, 내부 크로스커넥트, 매핑, 트래픽, 애플리케이션 결과가 하나의 상태로 뭉개지지 않게 한다.

성실한 운영자는 요청 식별자와 경로, 각 노드의 인가, 각 업스트림 할당과 내부 연결, 종단의 첫 허용 전송, 돌아오는 모든 다운스트림 매핑, 양방향에서 관측된 트래픽, 그리고 최종 제거를 기록해야 한다. 양방향과 서비스 경계가 모두 일치한 후에야 “양방향”이 첫 REQUEST에 담긴 의도가 아니라 완성된 서비스를 기술한다.

출처