요약

  • RFC 2383는 ST2+ 홉 하나를 ATM 가상 회로 하나에 대응시키고 데이터·제어·관리 기능을 서로 구분했기 때문에, 대역폭이 예약된 데이터 경로와 그 경로의 장애를 보고할 수 있는 제어 경로는 동일한 객체가 아니었습니다.
  • ST2+ 복구 절차가 불명확했고 여러 에이전트가 동시에 ATM 장애를 감지할 수 있었기 때문에, 사양은NoRecover를 요구했습니다. 복구 요청을 거부하는 편이 네트워크가 지킬 수 없는 상호운용성 약속을 하는 것보다 정직했습니다.

회로는 대역폭을 예약할 수 있지만, 장애로부터 되돌아오는 길까지 예약하는 것은 아닙니다.

1998년 8월 ATM UNI 3.1 위에서 ST2+를 전송하기 위한 Informational 사양으로 공개된 RFC 2383이 드러낸 불편한 경계가 바로 그것이었습니다. 이 문서는 밀접한 매핑을 기술했습니다. 하나의 ST2+ 홉은 하나의 ATM 가상 회로를 사용하고, 그 회로는 다른 홉과 공유되지 않으며, 홉이 여러 회로에 걸쳐 스트라이핑되지도 않습니다. 따라서 허가(admission) 상태는 구체적인 베어러를 확보할 수 있었습니다. 그러나 그 베어러가 실패했을 때, 이 아키텍처에는 복구를 위한 단일하고 안전한 소유자가 존재하지 않았습니다.

사양의 답은 이례적으로 직설적이었습니다. 구현은 CONNECT에서NoRecover를 선택해야 했습니다. 요청자가 다른 값을 제시하면 수신자는 REFUSE와NoRecover사유로 그 요청을 거부해야 했습니다. RFC 2383은 이를 일부 제약이 있는 성공적인 복구 기능이라 부르지 않았습니다. 그 기능 자체를 주장하지 않고 복구를 애플리케이션에 맡겼습니다.

이 거부가 중요한 이유는, 주변 시스템에 흔히 복구로 오해되는 재료들이 많이 있었기 때문입니다. ATM은 연결 실패를 표시할 수 있었습니다. ST2+ 에이전트들은 제어 메시지를 교환했습니다. 스트림은 FlowSpec을 담고 홉별로 자원을 예약할 수 있었습니다. 새 연결을 수립하는 것도 가능했습니다. 그러나 그 사실들 중 어느 것도—혼자서도, 함께서도—모든 참여자가 누가 어느 세그먼트를 어떤 순서로, 작업을 중복시키거나 애플리케이션에 거짓 결과를 노출하지 않고 재건할지에 대해 합의한다는 것을 증명하지 못했습니다.

하나의 홉, 하나의 회로, 여러 종류의 진실

RFC 2383은 사용자 평면, 제어 평면, 관리 평면을 구분했습니다. 사용자 평면에서 ST2+ 데이터는 자신의 홉에 할당된 ATM 연결 위를 이동했습니다. 제어 평면에서 ST2+ 에이전트들은 SCMP 메시지를 교환했습니다. 관리는 주소를 선택하고 회로를 수립하며 그 상태를 관찰하는 로컬 장치를 다뤘습니다.

이 평면들은 하나의 경로로 합쳐지지 않았습니다. 문서는 의도적으로 SCMP 가상 회로를 규정하지 않았습니다. 구현은 IPv4 회로를 재사용하거나 ST2+ 제어를 위한 별도의 회로를 수립할 수 있었습니다. 스트림의 데이터와 SCMP 메시지는 동일한 ST2+ 라우팅 방향을 따라야 했지만, 같은 IP 주소로 가는 IPv4 경로는 반대 방향으로 흐를 수 있었습니다. 따라서 예약된 데이터 회로가 끊어진 상태에서도 제어 교환은 가능할 수 있고, 반대로 제어 경로가 데이터 경로와 다른 조건에서 실패할 수도 있었습니다.

이 때문에 “네트워크에 도달 가능하다”는 약한 진술이 됩니다. 도달 가능성은 IPv4 패킷이 경로를 찾았다는 뜻일 수도, SCMP 메시지가 에이전트에 도달했다는 뜻일 수도, ATM 스위치가 콜 상태를 보고했다는 뜻일 수도, 사용자 데이터가 여전히 특정 VC를 건너고 있다는 뜻일 수도 있습니다. 각각은 서로 다른 계층의 증거이며, 어느 것도 다른 것을 자동으로 보증하지 않습니다.

홉 하나–VC 하나 규칙은 증거 모델을 더 선명하게 만들었습니다. 가상 회로는 임의의 베어러에 흩뿌려진 추상적 약속이 아니었습니다. 그것은 바로 그 홉의 베어러였습니다. 그러나 이 매핑은 장애도 국지화했습니다. 여러 홉에 걸친 스트림은 개별적으로 수립된 여러 회로와 에이전트에 의존했습니다. 한 회로의 상실을 감지하는 것은 끊어진 세그먼트를 식별해 줄 뿐, 그것만으로 종단 간 스트림을 재건하지는 못했습니다.

장애 감지는 복구 조율이 아니었다

RFC는 ST2+ HELLO 기능이 ATM 위에서는 지원되지 않아도 되도록 허용했습니다. ATM이 연결 실패를 충분히 알려줄 것으로 기대되었기 때문에 주기적인 HELLO 트래픽은 불필요해 보였습니다. 그러나 문서는 곧바로 감지가 왜 부족한지를 드러냈습니다. ST2+ 데이터와 SCMP 제어는 서로 다른 가상 회로를 사용할 수 있었고, 한 경로에서의 HELLO 결과는 다른 경로의 상태를 확정할 수 없었습니다.

같은 분리가 복구도 어렵게 만들었습니다. RFC 1819는 ST2+의 복구 동작을 기술했지만, RFC 2383은 그것을 이 환경에서는 불명확하고 불완전하다고 판단했습니다. ATM은 영향을 받는 모든 당사자에게 장애를 통지할 수 있었습니다. 따라서 여러 ST2+ 에이전트가 거의 같은 시점에 동일한 고장을 감지할 수 있었습니다. 각자 독립적으로 복구를 시도하면 그 행위들이 경쟁할 수 있었습니다. 한 에이전트가 상태를 해제하는 동안 다른 에이전트가 그것을 재건할 수 있고, 두 에이전트가 경쟁하는 대체 세그먼트를 만들 수 있으며, 하류 상태가 잘못된 시도에 붙을 수도 있었습니다.

프로토콜에는 트리거 이상의 것이 필요했습니다. 권한 규칙, 공유된 복구 식별자, 순서 규율, 그리고 감지·해제·재수립·스트림 재건·애플리케이션 수용을 서로 구분하는 영수증이 필요했습니다. RFC 2383은 그중 어느 것도 상호운용 가능한 복구 계약으로 제공하지 않았습니다.NoRecover를 의무화한 것은 바로 그 부재하는 제어 지점을 인정한 결과였습니다.

여기에 고장 표시와 결과 사이의 차이가 있습니다. 스위치는 VC가 사라졌다고 진실하게 말할 수 있습니다. 에이전트는 그 표시를 수신했다고 진실하게 말할 수 있습니다. 두 번째 회로는 허가가 성공했다고 진실하게 말할 수 있습니다. 그래도 애플리케이션은 의도한 스트림을 갖지 못하거나, 결과를 바꿔버리는 불연속과 함께 받을 수 있습니다. 이 연쇄에는 별개의 영수증이 필요합니다.

마지막 의무는 애플리케이션이 물려받았다

RFC 2383은 스트림 복구는 지원되지 않으며 애플리케이션이 이를 제공해야 한다고 명시했습니다. 그 한 문장이 애플리케이션을 마법처럼 재건에 능하게 만들지는 않았습니다. 다만 해결되지 않은 의무를, 연속성이 무엇을 의미하는지 판단할 만큼 충분한 맥락을 가진 계층에 배정한 것입니다.

어떤 애플리케이션에게 복구는 재연결 후 시퀀스 번호부터 이어서 하는 것일 수 있습니다. 또 다른 애플리케이션에게는 새 스트림을 시작하거나, 부분 출력을 버리거나, 중복 전달이 허용되는지 사람에게 묻는 것일 수 있습니다. 네트워크는 어떤 의미적 결과가 작업을 보존하는지 알지 못했습니다. 네트워크는 새 경로를 제공할 수는 있었지만, 기존 경로와 새 경로가 하나의 유효한 작업을 이루는지는 애플리케이션만이 판단할 수 있었습니다.

이 위임은 증명 요건도 만들어냈습니다. 운영자가 ATM이 대체 VC를 수립했다는 이유만으로 스트림을 ‘복구됨’이라고 표시할 수는 없습니다. 증거는 고장 표시, 기존 회로와 새 회로의 식별자, 해제된 예약, 재건된 ST2+ 홉 상태, 종단 간 스트림 식별자, 그리고 애플리케이션 자신의 완료 신호를 결합해야 했습니다. 그 결합이 없다면 ‘복구됨’은 관찰된 결과가 아니라 열망을 묘사한 것입니다.

Lu Heng의 현실 계층 관점은 여기서 특히 유용합니다. 물리 링크 상태, ATM 콜 상태, ST2+ 에이전트 상태, SCMP 교환, 애플리케이션 세션, 사용자에게 보이는 결과는 서로 연관되어 있지만 동일하지 않은 계층을 차지합니다. 이것들을 하나의 초록불 지표로 압축하려는 유혹은 상징적 권력의 한 형태입니다. 대시보드는 진위를 판가름하는 구분들을 버리는 대가로 명확성을 얻는 것입니다.

허가는 여전히 정책 결정이었다

실패 이전에도 회로 수립에는 방향과 소유자가 있었습니다. RFC 2383은 스위치드 가상 회로에 대해, ATM 연결을 시작하는 당사자를 운영 정책이나 과금 정책에 따라 선택할 수 있다고 기술했습니다. 이 방향은 ST2+ 스트림이 구축되는 동안 사용되는 송신자→수신자 방향과 독립적이었습니다.

이 구분이 중요한 이유는 제어는 인센티브를 따르기 때문입니다. 콜 비용을 지불하는 당사자가 연결을 시작할 수 있고, 스트림을 구축하는 당사자는 다음 홉이 움직일 것으로 기대할 수 있으며, 장애를 관찰한 에이전트는 과금되는 대체 회로를 만들 권한이 없을 수 있습니다. 이 경계들을 무시하는 복구 설계는 기술적으로 그럴듯하지만 운영상 불가능할 수 있습니다.

FlowSpec-ATM 매핑에도 단단한 한계가 있었습니다. ST2+ 트래픽 특성과 서비스 품질은 ATM 파라미터로 번역되었으며, 이는 RFC 2211과 2212가 기술한 서비스 모델과 RFC 1755의 ATM 신호 처리 지침을 바탕으로 했습니다. UNI 3.1은 수립된 연결에서 QoS 변경을 지원하지 않았습니다. 지원되는 FlowSpec 변경이 다른 자원을 요구한다면, 구현은 기존 ATM 연결을 해제하고 새 연결을 수립해야 했습니다.

그것은 제자리 편집이 아니라 자원 할당 사이의 보관권 이전입니다. 새 요청이 평가되는 동안 기존 회로가 계속 트래픽을 운반할 수도 있고, 구현과 정책에 따라 대체가 성공하기 전에 해제될 수도 있습니다. RFC 2383은 매핑과 재건의 필요성을 규정했지만, 무손실 전환, 애플리케이션 상태 보존 또는 특정 배포의 동작을 증명하는 측정치를 공표하지는 않았습니다.

이 경계가 이 역사를 RFC 2380과 구분합니다. RFC 2380의 중심 문제는 축소된 할당과 구/신 약속 경계를 전제로 한 예약 변경이었습니다. RFC 2383의 더 예리한 문제는 ATM 장애 이후, 여러 에이전트가 고장을 볼 수 있음에도 프로토콜이 완전한 복구 권한을 갖지 못했다는 점에서 무엇이 일어나는가였습니다. 둘 다 자원 상태를 다루지만, 불확실성을 서로 다른 결정에 배치합니다.

명시적 거부도 상호운용성의 한 형태였다

NoRecover를 저자들이 끝내지 못한 기능의 부재로 보는 유혹이 있습니다. 그러나 그것은 긍정적인 상호운용성 선택이기도 했습니다. 한 구현이 사적인 복구 절차를 시도하고 다른 구현이 동일한 상태를 다르게 해석한다면, 그 조합은 중복, 누출된 예약, 또는 양 끝에서 애플리케이션 의미가 갈라지는 스트림을 만들어낼 수 있었습니다.

이 플래그를 요구한 것은 한계를 유일하게 안전한 방식으로 협상 가능하게 만들었습니다. 즉, 협상할 애매한 것이 전혀 없었다는 것입니다. 복구를 요청한 피어는 이름이 붙은 사유와 함께 REFUSE를 받았습니다. 실패는 이후의 장애 속에 숨겨지는 대신 설정 시점에서 드러났습니다.

Lu Heng의 최소 초기 사양(minimum initial specification) 관점에서 보면, 이것은 불완전성의 규율된 사용입니다. 최소 사양은 불확실한 영역을 보증처럼 보이는 말로 채우지 않아야 합니다. 상호운용 가능한 핵심을 정의하고, 공유되지 않은 결정을 국지화하며, 이후 실행 중인 코드가 더 강한 계약을 증명할 여지를 남겨야 합니다. 여기서 전용 회로, 주소 지정, 설정, 자원 매핑은 공유 핵심에 속했고, 스트림 복구는 속하지 않았습니다.

실행 코드 관점은 다음 질문을 던집니다. 어떤 증거가NoRecover를 제거할 만한 근거가 될까요? 산문적인 확장으로는 부족합니다. 구현자들은 여러 에이전트가 동일한 ATM 장애 표시를 받고, 하나의 복구 권한을 선택하고, 중복을 억제하고, 기존 예약을 회계 처리하고, 대체를 수립하고, 올바른 스트림에 재결합하고, 애플리케이션에 모호하지 않은 결과를 노출하는 적대적 테스트를 갖추어야 합니다. 그 테스트에는 잃어버린 제어 메시지, 비대칭 경로, 그리고 데이터/제어 장애가 동시에 일어나지 않는 상황이 포함되어야 합니다.

RFC 2383은 그런 결과를 주장하지 않았습니다. 그 Informational 지위, 그리고 그 지위를 기록한 RFC Editor의 기록은 역사적 해석의 범위를 제한합니다. 이것은 배포 실태 조사가 아니라 프로토콜 사양이었습니다. IETF datatracker는 그 공개 이력을 기록합니다; 그것이 이 설계를 광범위한 사용의 증거로 바꿔주지는 않습니다.

보안은 연쇄의 한 모서리만을 보호했다

보안 논의 역시 한계가 분명했습니다. 문서는 자신의 최소 ATM 확장과 버그 수정이 ST2+나 UNI 3.1의 보안을 약화시키지 않는다고 기술했습니다. 또한 네트워크가 제공한 발신자 번호는, 검증될 경우 인증에 기여할 수 있다고 언급했습니다.

“기여한다”는 말이 핵심입니다. 발신자 신원은 누가 회로를 시작했는지 확립하는 데 도움될 수 있습니다. 그러나 FlowSpec이 애플리케이션 권한과 일치한다는 것, 표시된 발신자가 여전히 그 엔드포인트를 통제한다는 것, 대체 VC가 실패한 스트림에 속한다는 것, 애플리케이션이 재건된 세션을 수용했다는 것은 증명하지 않았습니다. 신원 증거는 한 모서리만 덮었고, 자원·상태·결과 증거는 여전히 별개였습니다.

같은 절제가 현대적 독법에도 적용되어야 합니다. RFC 2383을 특정 공급자가 ST2+ over ATM을 배포했다는 주장, 어떤 회로가 지연 목표를 충족했다는 주장, 장애가 복구되었다는 주장, 과금 정책이 특정 발신자를 선택했다는 주장에 사용할 수 없습니다. 그것들은 각자 자신의 기록을 요구하는 구현 및 운영 사실입니다.

RFC가 실제로 확립하는 것은 더 오래 지속됩니다. 자원 예약, 장애 감지, 제어 도달 가능성, 재건, 애플리케이션 성공은 서로 다른 주장입니다. 시스템은 처음 셋을 갖추면서 넷째가 없을 수 있고, 인프라를 재건하면서도 다섯째에서 실패할 수 있습니다. 1998년 RFC 2383은 그렇게 말하는 것을 타협 없는 하나의 플래그로 선택했습니다:NoRecover.

그 플래그는 실패 이후 아무 유용한 일도 할 수 없다는 고백이 아니었습니다. 그것은 권한, 순서, 최종 영수증이 표준화되지 않은 ‘완료된 복구’를 네트워크가 약속하도록 두지 않겠다는 거부였습니다. 회로는 자원을 예약할 수 있었습니다. 에이전트들은 회로가 끊어졌음을 알 수 있었습니다. 다시 시작한다는 의미는 여전히 애플리케이션의 소유였습니다.

출처