RFC 3474: 콜 ID는 연결이 아니었다

요약

RFC 3474는 ASON 콜(Call)의 수명 동안 일정하게 유지될 수 있는 CALL_ID를 제안했으며, 한 형태는 운영자와 노드를 넘어 전 세계적으로 고유할 수 있었다.
그 영속적인 이름은 하나의 관계를 식별했다. 해당 콜의 연결(Connection), RSVP 상태, 로컬 레이블, 설치된 자원, 물리적 연속성, 트래픽, 전달된 서비스는 여전히 별도의 근거를 필요로 했다.

기록은 사람들이 그것이 나타낸다고 상상하는 대상보다 오래 남을 수 있다. 2003년 3월, RFC 3474는 이것이 네트워크 제어 평면 안에서 어떻게 일어나는지 보여 주었다.

이 문서는 인터넷 표준이 아니라 Informational로 공표되었다. 자동 스위칭 광네트워크(ASON) 요구사항을 위한 GMPLS RSVP-TE에 대한 IANA 할당과 확장을 제안했다. 그 야망은 넓었다: 소프트 영구 연결, 콜과 연결의 구분, 재시작 동작, 추가 오류, 그리고 인접한 제어 도메인이 같은 기술이나 정책을 공유하지 않는 경계를 통과하는 방법이었다.

여기서 '콜(Call)'이라는 단어는 신중한 역할을 했다. 기존 GMPLS 시그널링은 연결(Connection)을 수립할 수 있었다. 즉, 트래픽을 실어 나르는 자원의 구체적 결합이었다. ASON 콜은 그와 달리 콜 컨트롤러가 관리하는 단말 간의 관계였다. 연결 컨트롤러는 그 관계 아래 하나 이상의 연결을 만들 수 있었다. 관계를 실현하는 데 쓰이는 행정적·상업적 관계와 자원은 같은 대상이 아니었다.

RFC 3474는 이 상위 계층의 관계에 CALL_ID를 부여했다. 연산자별 형태와 전 세계적으로 고유한 형태를 정의했다. 전역 구성은 ISO 국가 코드, ITU 캐리어 코드, 해당 조직이 관리하는 액세스 포인트 코드, 소스 LSR 주소, 로컬 식별자를 결합했다. 마지막 구성 요소는 64비트이며 콜의 수명 동안 일정하게 유지되어야 했다.

이 구성은 여러 네임스페이스를 결합하므로 권위 있게 들린다. 그러나 모든 필드는 운영상의 질문이 아니라 신원 질문에 답했다. 이 콜을 다른 콜과 구별할 수 있었다. 두 컨트롤러가 같은 관계를 지칭하는 데 도움이 될 수 있었다. 그러나 파장을 예약하거나, 크로스 커넥트를 구성하거나, 광섬유를 점등하거나, 패킷을 전송하거나, 고객을 만족시키지는 못했다.

고유성의 범위조차 주의가 필요했다. 연산자별 CALL_ID는 그 소스 LSR 주소 자체가 전 세계적으로 고유할 때 전 세계적으로 고유해질 수 있었다. RFC는 곧바로, 연산자가 자기 네트워크 안에서만 의미가 있는 주소를 사용할 경우 이 보장이 성립하지 않는다고 경고했다. 구문은 의도된 범위를 표현할 수 있었다. 그러나 식별자가 안전하게 주장할 수 있는 것은 여전히 할당 맥락이 결정했다.

할당에도 가시적인 권한 경계가 있었다. 최초 사용자는 CALL_ID에 0을 넣을 수 있었다. 그러면 첫 네트워크 노드가 값을 할당하거나 이미 0이 아닌 값을 검증했다. 중간 노드는 ASON 확장을 이해하지 못하는 노드를 포함해 이 개체를 변경 없이 그대로 전달해야 했다. 목적지는 이후 조치를 위한 참조로 이를 보유했다. Path, Resv, PathTear, PathErr, Notify 메시지에 걸쳐 이어지는 연속성 덕분에 그 관계는 추적 가능했다. 그러나 이것이 모든 메시지가 같은 연결 상태를 보고한다는 뜻은 아니었다.

기본 분리 모델에서 콜은 보통 하나 이상의 연결을 가졌다. 연결이 0개인 상태는 일시적으로 발생할 수 있었는데, 특히 브레이크 비포 메이크(break-before-make) 복원 중이었다. 교체 연결이 존재하기 전에 기존 연결이 제거될 수 있었고, 콜 관계와 그 CALL_ID는 그 공백 위에서 유지되었다. 따라서 콜 행을 가동 중 회선과 동일시하는 재고 시스템은 데이터 전송 계층에 연속성이 전혀 없을 때 정확히 그 시점에 연속성을 표시하게 된다.

RFC 3474는 이어서 CALL_OPS를 통해 더 완전한 선택적 분리를 기술했다. 여기서 콜은 연결 생성과 동시에 수립되거나 동기화되지 않을 수 있었다. 그 정상 상태에는 연결이 0개, 1개 또는 여러 개 존재할 수 있었다. 이것은 아키텍처의 허점이 아니었다. 관계와 연결성이 서로 다른 수명 주기를 가진다는 것을 아키텍처가 직접 진술한 것이었다.

이 구분은 제어 경계에서 중요했다. 콜 컨트롤러는 관계를 유지할지, 당사자를 수용할지, 상태를 동기화할지 결정했다. 연결 컨트롤러는 자원을 실은 연결을 다루었다. 한 권한은 콜을 수용하면서 다른 권한은 연결을 거부하거나, 지연시키거나, 교체하거나, 해체할 수 있었다. 그들의 결정을 하나의 'up' 필드로 합치면 누가 무엇을 결정했는지가 지워진다.

SPC_LABEL은 소프트 영구 연결의 가장자리에서 유사한 분리를 드러냈다. 이 개체는 영구 프로비저닝된 인그레스 구간을 스위칭 구간과 연관 지을 수 있었다. 그러나 그 연관 메커니즘은 제안 밖의 로컬 정책이었다. 비-GMPLS 서브네트워크를 넘어서, 레이블은 제어 평면 노드에 국소적이며 시그널링이 진행되기 전에 수동으로 프로비저닝되거나 발견될 수 있었다. 따라서 동일한 콜이 어떤 하나의 레이블도 종단간 증명이 되지 않은 채 여러 로컬 명명·자원 체제를 가로지를 수 있었다.

재시작 동작은 겉보기 연속성의 추가적인 가능한 출처를 더했다. 컨트롤러는 영속적인 콜 또는 연결 저장소에서 정보를 재구성하거나, 이웃으로부터 상태를 추론하거나, 관리 시스템으로부터 지시를 받을 수 있었다. 각 출처는 서로 다른 근거적 강도를 가졌다. 복구된 CALL_ID는 컨트롤러가 그 관계를 기억한다는 것을 보여줄 수 있었다. 그러나 그것만으로 이웃이 동의했는지, RSVP 거래가 완료되었는지, 하드웨어가 프로그래밍을 유지했는지, 물리 신호가 살아남았는지를 보여줄 수는 없었다.

알림도 계층을 하나로 합치지 않았다. CALL_ID는 콜에 속한 세션들과 함께 Notify에 실려 갈 수 있었고, 하나의 Notify가 여러 콜과 연관된 세션을 담을 수 있었다. 메시지 봉투, 콜 신원, 각 연결 상태는 별개로 남았다. 한 계층에 대한 알림이 자동으로 다른 계층을 인증하지 않았다.

표준 계보는 규율 있는 연대기가 필요하다. RFC 4139는 이후 ASON 적용성과 요구사항을 문서화했다. 2007년 표준 트랙에서 공표된 RFC 4974는 더 완전한 콜 시그널링을 규정하면서, 콜 자체는 트래픽 연결성을 제공하지 않으며 연결이 0개, 1개 또는 여러 개일 수 있다는 점을 명시했다. RFC 6004는 이후 그 절차를 중심으로 추가 UNI 확장을 만들었다. 이 문서들은 정제와 지속적 필요를 보여 준다. 그러나 이들이 RFC 3474를 소급하여 표준으로 만들거나, 특정 캐리어가 자신의 제안을 배치했다는 것을 증명하지는 않는다.

바로 여기서 Lu Heng의 기호·결정·운영 현실에 관한 구분이 실용적으로 작동한다. 전 세계적으로 고유한 식별자는 강력한 조율 기호다. 콜 컨트롤러의 수용은 결정이다. 연결 컨트롤러의 성공적 시그널링은 또 다른 결정이다. 설치된 자원, 물리적 연속성, 방향성 트래픽, 애플리케이션 전달은 관찰이다. 이들은 결합될 수 있지만, 데이터베이스가 하나의 키를 쓴다는 이유만으로 어떤 계층도 다음 계층의 권위를 물려받을 수는 없다.

그러므로 방어 가능한 기록은 별도의 타임라인에서 시작된다. CALL_ID를 누가 할당했는지, 어떤 형태와 고유성 범위를 썼는지, 소스 LSR 주소의 맥락, 콜이 시작되고 끝난 시점을 보존한다. 콜 컨트롤러 정책과 수용을 별도로 기록한다. 모든 연결에 고유한 신원, 연관 구간, RSVP 메시지, 레이블 매핑, 자원 프로그래밍, 해체 근거를 부여한다. 그런 다음 물리 신호, 트래픽, 서비스 관찰을 실제로 측정한 연결에 붙인다.

그 모델은 콜에 연결이 없는 상태를 잘못해서 중단(outage)이라 부르지 않고도 표현할 수 있다. 하나의 콜 아래 두 개의 교체 연결을 같은 회선이라 부르지 않고도 표현할 수 있다. 자원 경로가 바뀌는 동안 식별자는 안정적으로 유지되었다는 것을 보여줄 수 있다. 무엇보다 RFC 3474가 대답하려 하지 않았던 운영 질문에 답할 수 있다. 컨트롤러가 무엇이라 이름 붙인 관계가 있는지만이 아니라, 특정 시점에 어떤 연결성이 존재했는가.