요약

  • RFC 3332는 적응(adaptation) 경계를 MTP3 위로 옮겼습니다. 시그널링 게이트웨이는 MTP2와 MTP3를 종단하고, ISUP·SCCP 등 MTP3 사용자 트래픽을 라우팅 키(Routing Key)로 선택되고 라우팅 컨텍스트(Routing Context)로 식별되는 IP 애플리케이션에 전달했습니다.
  • 등록, ASP 활성화, SS7 목적지 가용성은 서로 별개의 확인(영수증)이었습니다. 게이트웨이는 키를 수락하고 애플리케이션 프로세스를 활성화한 뒤에도 해당 목적지를 사용할 수 없다고 보고할 수 있었습니다. RFC 4666은 2006년에 RFC 3332를 대체(obsolete)했으므로, 이전 문서는 역사적 근거이며 현재 프로토콜 권위가 아닙니다.

경로가 정책 객체가 되다

기존의 SS7 노드에서는 네트워크 라우팅과 로컬 사용자 부분(user part) 사이의 관계가 대체로 하나의 시스템 안에 담겨 있었습니다. RFC 3332는 그 관계를 분산시켰습니다. 이 문서가 정의한 시그널링 게이트웨이는 네이티브 SS7을 수신하고 MTP2와 MTP3를 종단한 뒤, MTP3 사용자 메시지(예: ISUP 호 제어나 SCCP 트래픽)를 IP 전송 위에서 애플리케이션 서버 프로세스(Application Server Process)로 보냈습니다. 선택된 MTP 네트워크 관리 이벤트 역시 같은 경계를 넘어 전달되었습니다.

이는 RFC 3331의 M2UA와는 다른 절단 방식이었습니다. M2UA는 물리적 시그널링 링크와 MTP2를 게이트웨이에 남겨 두고, 원격 MTP3가 인터페이스 식별자(Interface Identifier)를 통해 그 경계를 운영하도록 했습니다. M3UA는 한 계층 위에서 절단했습니다. MTP3 자체는 게이트웨이에 머물렀고, 원격 애플리케이션은 특정 물리 링크에 대한 제어권이 아니라 MTP3 사용자가 기대하는 서비스를 받았습니다.

상위 계층 사용자가 옮겨진 이상, 게이트웨이는 어떤 원격 애플리케이션이 어떤 시그널링을 소유하는지 결정하는 규칙이 필요했습니다. RFC 3332는 그 규칙을 라우팅 키(Routing Key)라고 불렀습니다. 키는 서비스 정보 옥텟(Service Information Octet), 목적지 및 발신지 포인트 코드, 회선 식별 범위, 또는 목적지/발신지/SCCP 서브시스템 조합을 통해 범위를 기술할 수 있었습니다. 애플리케이션 서버(Application Server)는 하나의 키를 서비스하는 논리적 실체였고, 라우팅 컨텍스트(Routing Context)는 프로토콜 메시지에서 키를 식별하는 압축된 값이었습니다.

이 변화는 개념적으로 큰 것이었습니다. 경로는 더 이상 단순히 시그널링 네트워크를 통과하는 경로가 아니었습니다. 적응 경계에서 그것은 행정적 선언이기도 해졌습니다. 즉, “이런 속성을 가진 트래픽은 이 애플리케이션 서비스에 속한다”는 선언이었습니다. 키는 그 사실을 발견하지 않습니다. 운영자가 그것을 프로비저닝하거나, 피어가 라우팅 키 관리를 통해 제안하면 게이트웨이가 등록을 수락하거나 거부합니다.

수락이 곧 권한은 아니다

성공적인 등록 응답은 유용한 확인(영수증)이 될 수 있습니다. 특정 시점에 SGP가 제안된 매핑을 수락하고 라우팅 컨텍스트를 반환했다는 사실을 보여주기 때문입니다. 그러나 그 응답은 피어가 해당 포인트 코드를 대표할 권한이 있었는지, 다른 키가 겹쳤는지, 로컬 정책이 올바른지, 목적지가 실제로 도달 가능한지를 보여주지 않습니다.

이 구분이 중요한 이유는 라우팅 키의 필드가 권위적으로 보이기 때문입니다. 목적지 포인트 코드, 서비스 지시자, 회선 범위는 좌표처럼 생겼습니다. 그러나 좌표는 소유권을 증명하지 못합니다. 네트워크 어피어런스(Network Appearance)는 또 하나의 로컬 한정 조건을 추가합니다. 같은 포인트 코드 값이 별개의 SS7 네트워크에서 재사용될 수 있으므로, 이 어피어런스는 그 값이 어느 네트워크에 속하는지 피어들이 해석하도록 돕는 것입니다. 이는 공유된 맥락이지 전역 인증서가 아닙니다.

따라서 사고 조사자에게는 완전한 선택 확인이 필요합니다. 키 필드, 네트워크 어피어런스, 등록 요청과 응답, 결과 라우팅 컨텍스트, 구성 출처, 승인 변경 사항이 그것입니다. 라우팅 컨텍스트를 담은 패킷은 발신자가 로컬적으로 의미 있는 숫자를 사용했다는 사실만 증명합니다. 매핑 표가 없다면 그것은 의도된 트래픽 도메인에 대해 아무것도 말해 주지 않습니다.

겹치거나 지나치게 넓은 키는 특히 위험합니다. SCTP 연관(association)을 끊지 않은 채, 그런 키는 정상적으로 보이는 시그널링을 잘못된 애플리케이션에 전달할 수 있습니다. 전송 대시보드는 녹색으로 유지되는 반면, 그 뒤에서 호 상태나 데이터베이스 트랜잭션이 갈라질 수 있습니다. 이 실패는 패킷 손실이 아니라, 성공적인 선택이라는 형태로 표현된 잘못된 정책입니다.

세 개의 상태 머신은 하나로 합쳐지지 않았다

RFC 3332는 전송, 애플리케이션, 시그널링 네트워크 상태를 분리했습니다. SCTP는 연관과 스트림을 제공했습니다. ASP 상태 관리는 DOWN, INACTIVE, ACTIVE 프로세스를 구분했습니다. 애플리케이션 서버 상태와 트래픽 모드(Override, Loadshare, Broadcast)는 어떤 활성 프로세스가 선택된 트래픽을 받아야 하는지 결정했습니다. 그 어느 상태도 SS7 목적지가 실제로 도달 가능한지를 기술하지 않았습니다.

목적지의 진실은 다른 메커니즘을 통해 도착했습니다. 시그널링 네트워크 관리 메시지는 목적지 사용 불가(Destination Unavailable), 목적지 가용(Destination Available), 시그널링 혼잡(Signalling Congestion), 목적지 사용자 부분 불가(Destination User Part Unavailable)를 보고했고, 감사 메시지는 현재 목적지 상태를 문의할 수 있었습니다. 하나의 ASP가 여러 게이트웨이를 사용할 때, M3UA는 게이트웨이별 경로 상태를 유지하면서 MTP3 사용자에게 노출하는 전체 가용성을 도출해야 했습니다.

이로 인해 완전히 유효하지만 운영상은 곤란한 장면이 생깁니다. SCTP 연관이 수립되어 있고, ASP가 어떤 라우팅 컨텍스트에 대해 ACTIVE 상태이며, 동시에 DUNA가 그 키가 선택한 목적지를 사용할 수 없다고 보고하는 것입니다. 모순은 없습니다. 첫째는 전송에 관한 사실이고, 둘째는 애플리케이션 자격에 관한 사실이며, 셋째는 SS7 경로에 관한 사실입니다. 하나의 상태 표시등은 정보를 파괴합니다.

DAVA 역시 같은 방식으로 한정됩니다. 그것은 보고하는 M3UA 계층의 현재 관점에서 그 목적지가 가용하다고 간주한다는 뜻입니다. DAVA는 ISUP 호출이 완료되었음을, SCCP 트랜잭션이 최종 애플리케이션에 도달했음을, 보고 이후에도 목적지가 도달 가능하게 남았음을 증명하지 않습니다. 사용자 부분(user part)의 결과에는 자체적인 확인, 응답 또는 오류 증거가 필요합니다.

페일오버는 선택은 보존하되 지식은 보존하지 않을 수 있다

M3UA는 여러 ASP와 여러 SGP를 지원하여 프로세스나 경로가 실패할 때 트래픽을 옮길 수 있게 했습니다. 그 중복성은 가치가 있었지만 조정 문제를 넓혔습니다. 교체 ASP는 오래된 목적지 상태를 가진 채 같은 키에 대해 활성화될 수 있습니다. 살아남은 연관은 경로가 바뀐 뒤에도 트래픽을 계속 운반할 수 있습니다. 게이트웨이 전환은 라우팅 컨텍스트가 동일하게 유지되더라도 가용한 SS7 경로를 바꿀 수 있습니다.

안전한 절차는 단순히 “연관 수립, ASP 활성, 재개”가 아니었습니다. 현재의 라우팅 키, 승인된 멤버십, 트래픽 모드, SGP별 목적지 상태, 혼잡, 재시작 조건을 조정해야 했습니다. DAUD가 존재하는 이유는 기억된 상태가 불충분하기 때문입니다. 감사 응답조차 시간 제한이 있는 관측이며, 다음 DUNA, DAVA 또는 혼잡 이벤트와 경합할 수 있습니다.

큐잉은 그 결과를 더 보기 어렵게 만듭니다. 부하 분산(Load sharing)은 한 프로세스가 아직 상태를 재구성하지 못한 채 트래픽을 여러 프로세스에 퍼뜨릴 수 있습니다. Override 모드는 모든 작업을 새 소유자에게 옮길 수 있습니다. 선택 규칙이 틀렸다면, 중복성은 그 잘못된 결정을 더 빨리 반복합니다. 목적지 증거가 오래되었다면, 페일오버는 소프트웨어의 가용성을 보존하면서 그것이 라우팅하는 근거인 진실을 악화시킵니다.

문서 자체에도 시간 경계가 있다

RFC 3332는 2002년 9월에 표준 트랙(Standards Track) 사양으로 공개되었습니다. 4년 뒤 공개된 RFC 4666은 명시적으로 그것을 대체했습니다. 역사적 문서는 아키텍처적 전환과 어휘를 드러낸다는 점에서 유용하지만, 현재의 프로토콜 해석은 후속 문서에 속합니다. 그 경계 없이 RFC 3332를 인용하면 기록 보관 근거가 거짓 현재 권위로 변합니다.

같은 주의는 인접 기록에도 적용됩니다. RFC 2719는 SIGTRAN 프레임워크를 설명합니다. RFC 9260은 현재의 SCTP 기본 사양입니다. RFC 3788은 SIGTRAN 보안 고려사항을 발전시켰습니다. RFC 4165는 M2PA의 피어 투 피어 링크 모델을 구분하는 데 도움이 됩니다. IANA는 여전히 시그널링 적응 메시지 클래스, 파라미터, SCTP 할당을 기록합니다. 그 어떤 기록도 특정 운영자가 M3UA를 배포하고 있음을, 어떤 경로가 활성 상태임을, 어떤 구현이 적합함을 증명하지 않습니다.

보안 역시 성공적인 교환에서 추론할 수 없습니다. SCTP 전송 메커니즘은 라우팅 키의 비즈니스 의미를 인증하지 않습니다. 암호적으로 식별된 피어조차 어떤 목적지 범위에 대해 무권한일 수 있고, 승인된 구성조차 틀릴 수 있습니다. 전송 보호, 피어 신원, 라우팅 승인, 목적지 상태는 여전히 별개의 통제입니다.

가장 오래가는 교훈은 네 개의 확인을 보존하는 것

RFC 3332의 가장 내구성 있는 통찰은 SS7이 IP를 넘을 수 있다는 것이 아닙니다. 네트워크 경계를 분산시키면 암묵적 관계가 정책 객체로 바뀐다는 것입니다. 이 객체들은 이름 붙이고, 버전 관리하고, 관측되어야 하며, 그 상태가 뒤에 있는 세계의 상태를 증명한다고 가장해서는 안 됩니다.

중대한 모든 전송에는 네 개의 확인을 보존하십시오. 첫째, 선택 확인: 전체 라우팅 키, 네트워크 어피어런스, 라우팅 컨텍스트, 구성 출처. 둘째, 애플리케이션 확인: 연관, ASP/AS 상태, 트래픽 모드, 활성 멤버십. 셋째, 경로 확인: 선택된 게이트웨이, 목적지 상태, 혼잡, 재시작, 감사 시퀀스. 넷째, 결과 확인: 트랜잭션을 닫는 사용자 부분의 확인, 응답 또는 실패.

게이트웨이의 키는 “이 시그널링을 어느 애플리케이션이 봐야 하는가?”에 답했습니다. 그것은 “시그널링 목적지에 도달할 수 있는가?”나 “원격 작업이 성공했는가?”에는 결코 답하지 않았습니다. 이 아키텍처가 작동한 이유는 프로토콜이 그 질문들을 분리해 두었기 때문입니다. 대시보드가 그것들을 다시 합쳐 놓을 때 운영이 실패합니다.

출처