요약

  • RFC 3475는 처리된 Call Release가 해당 Call과 연관된 모든 Connection의 해제를 유발하도록 요구했다.
  • 각 Connection은 여전히 일반적인 Label Withdraw 및 Label Release 절차를 사용했으므로, Call 수준의 확인은 전체 집합에 걸친 원자적 신호 처리, 자원 정리, 트래픽 중단 또는 서비스 종료를 증명할 수 없었다.

하나의 명령이 끝내지 못한 여러 연산을 동시에 열 수 있다. RFC 3475는 그 문제를 자동 교환 광 네트워크(Automatically Switched Optical Network)의 제어 평면 안에 넣었다.

2003년 3월에 발표된 이 문서는 Internet Standard가 아니라 Informational이었다. 명시된 목적은 ITU-T ASON 작업에서 선택된 CR-LDP 확장에 대한 IANA 코드 포인트 할당을 기록하는 것이었다. 이 문서는 해당 확장의 사용 규칙을 ITU-T 문서에 명시적으로 남겨두었다. 이 구분이 중요하다. 이는 제안된 프로토콜 기능의 기록이지 보편적 배포의 증거가 아니었다.

ASON은 Call을 그 Connection들과 분리했다. Call은 당사자들 간의 관계를 기술했다. 하나 이상의 Connection이 네트워크 자원으로 그 관계를 구현할 수 있었다. 완전 분리 모델에서는 Connection 없이 Call이 존재할 수도 있었다. RFC 3475는 그 상위 객체에 대한 연산을 위해 Call Setup 및 Call Release 메시지를 도입했다.

Call Release는 Source ID, Destination ID, CALL_ID를 실었다. 어떤 네트워크 개체든 이를 보내 확립된 Call을 종료할 수 있었다. 적절한 상태 코드를 담은 Notification이 Call 해제를 발신자에게 보고했다. 언뜻 보면 단일 거래에 단일 영수증처럼 보인다.

그러나 다음 문장이 그 환상을 깨뜨렸다. Call Release의 수신 및 처리는 해당 Call과 연관된 모든 Connection의 해제를 유발해야 했다. 그 해제들은 Label Release 및 Label Withdraw 메시지를 사용하는 일반 CR-LDP 절차를 따랐다. 따라서 상위 계층 연산 하나가 하위 계층 상태 전이의 집합으로 확장된 것이다.

RFC 3036은 이 분기들이 왜 중요한지 보여준다. 하류(downstream) LSR은 Label Withdraw로 매핑을 철회하고, 수신자는 Label Release로 응답해야 했다. 상류(upstream) LSR도 더 이상 매핑이 필요 없을 때 Label Release를 보냈다. 이 메시지들은 피어, FEC 및 라벨 상태에 작용했다. 그것은 하나의 전역적인 "모두 지워짐" 비트가 아니었다.

Call에 Connection이 셋 있다면, 각각은 서로 다른 지점에 있을 수 있었다. 하나는 완전히 해제되었고, 하나는 피어 교환을 기다리고 있으며, 하나는 여전히 로컬 상태를 유지하고 있을 수 있다. RFC 3475는 셋 모두가 해제되도록 요구했다. 그러나 셋이 동시에 완료되었음을 증명하는 원자적 영수증을 만들지는 않았다. 성공적인 Call 수준 Notification과 완전한 Connection 수준 해제 대장은 서로 다른 질문에 답한다.

따라서 연관 관계의 시점이 근거가 되었다. 해제가 효력을 발생하는 순간, 시스템은 Call에 속한 모든 Connection의 스냅샷을 필요로 했다. 나중에 비어 있는 연관 목록을 읽는 것은 불충분했다. 몇 개의 분기가 존재했는지, 어느 것이 먼저 끝났는지, 무엇이 재시도했는지, 물리적 자원이 정리되기 전에 목록에서 사라진 것이 있는지를 보여줄 수 없기 때문이다.

CALL_ID는 이 팬아웃을 상호 연관하는 데 도움이 되었지만, 식별자가 완료를 제공하지는 않았다. 동일한 식별자가 해제 요청과 영향받는 관계들을 결합할 수는 있었다. 그러나 각 피어가 Label Withdraw를 처리했는지, 각 라벨 매핑이 사라졌는지, 크로스 커넥트가 용량을 반환했는지, 광 신호가 멈췄는지, 트래픽과 과금이 중단되었는지는 증언할 수 없었다.

소프트 영구 연결(soft permanent connection)은 또 하나의 경계를 더했다. 이 연결에서 사용자-네트워크 구간은 사전 프로비저닝되고, 네트워크 구간은 제어 평면이 수립했다. 제어되는 네트워크 Connection의 해제가 영구 엣지 구간에 무슨 일이 일어났는지 자동으로 기술하지는 않았다. 따라서 Call의 종료는 의도적으로 유지된 인프라와 공존할 수 있었다.

또 다른 RFC 3475 확장인 크랭크백(crankback)은 실패 측면에서 같은 논리를 강화했다. Notification은 Label Request가 자원 부족으로 막힌 지점을 식별하는 ER-HOP을 실을 수 있었고, 발신자는 그 지점을 우회하는 경로를 계산할 수 있었다. 장애 지점의 위치는 유용한 근거였지만, 다음 요청이 자원을 찾았거나 경로를 수립했다는 증명은 아니었다. 위치, 결정, 결과는 분리되어 있었다.

보안 절은 이 문서가 RFC 3036과 RFC 3212 이상의 새로운 우려를 추가하지 않는다고 말했다. 이 문장을 보증 주장으로 확대해서는 안 된다. 유효한 상태 메시지는 기반이 되는 세션과 구현의 보안 속성을 넘어 물리적 자원 상태, 상업적 권한 또는 서비스 결과를 인증하지 않는다.

이후의 ASON 문서들이 아키텍처를 다듬었고, RFC 4974는 RSVP-TE Call 절차를 표준화했다. 이것들을 소급 적용해 RFC 3475에 더 강한 지위나 다른 완료 의미를 부여할 수는 없다. 또한 특정 사업자가 그 CR-LDP 메시지를 사용했다는 증명도 되지 않는다.

Lu Heng의 현실 계층 원칙이 운영 기록의 틀을 제공한다. Call Release는 하나의 상징 계층에서의 명령이다. 그것을 처리하면 결정이 만들어진다. 각 Label Withdraw와 Label Release는 범위가 제한된 프로토콜 영수증이다. 로컬 상태 삭제, 하드웨어 재프로그래밍, 물리적 신호 변화, 트래픽 관측, 서비스 종료는 더 아래의 계층들을 차지한다. 공유된 CALL_ID는 기록들을 연결할 수 있지만, 첫 영수증이 마지막 영수증인 것처럼 행세하게 할 수는 없다.

방어 가능한 해제 대장은 해제 시점에 연관 Connection 집합을 고정해야 한다. 발신자, CALL_ID, Message ID, 상태 Notification, 처리 노드를 보존해야 한다. 모든 Connection에 대해 피어, FEC, 라벨 범위, Withdraw 및 Release 시각, 재시도, 상태 삭제, 자원 조치를 기록해야 한다. 물리적, 트래픽, 고객 관측은 별도로 뒤따른다. 모든 요구 분기가 유한한 결과를 가질 때에만 시스템은 Call 전체가 닫혔다고 말할 수 있다.

출처