요약

  • RFC 3332의 M3UA는 트래픽 범위를 기술하는 Routing Key, 그 키를 식별하는 Routing Context, 그리고 로컬 SS7 네트워크 맥락을 구분하는 Network Appearance를 사용했다. 이들은 서로 관련되어 있었지만 서로 바꿔 쓸 수 있는 이름은 아니었다.
  • 하나의 ASP는 공유 SCTP 연결을 통해 여러 Application Server를 서비스할 수 있었고, ASP 상태는 AS별로 유지되었다. 따라서 녹색 전송 연결은 어떤 트래픽 집합이 활성 상태인지, SS7 목적지에 도달 가능한지, 또는 MTP3-User가 메시지를 수신했는지를 말해 주지 않았다.

세 개의 레이블, 세 가지 다른 질문

M3UA의 명명 체계는 포인트 코드가 재사용되기 전까지는 어휘 문제처럼 보일 수 있다. 그 순간 이것은 라우팅 문제가 된다. 하나의 SS7 네트워크가 다른 네트워크도 사용하는 포인트 코드를 할당할 수 있다. 시그널링 게이트웨이가 공유 연결을 통해 두 네트워크를 모두 실어 나르면, 숫자만으로는 메시지가 어느 영역에 속하는지 식별할 수 없다. 그래서 M3UA는 네트워크 맥락과, 트래픽을 선택하는 규칙과, 그 규칙에 이름을 붙이는 값을 서로 분리한다.

이 구분은 M3UA가 무엇을 위한 것인지에서 시작된다. 2002년 9월에 발표된 RFC 3332는 IP를 통해 전송되는 ISUP이나 SCCP 메시지 같은 MTP3-User 시그널링에 대한 어댑테이션을 정의한다. 원격 Application Server Process에서 M3UA는 이들 MTP3 사용자가 기대하는 프리미티브를 제공한다. 그 자체가 SS7 MTP3 계층이 되는 것은 아니다. Signalling Gateway가 SS7을 수신하는 동안, 원격 애플리케이션이 어댑테이션 프로토콜을 통해 사용자 부분을 소비할 수 있다. M3UA 제어 평면은 어떤 메시지가 어디로 가는지와, 어떤 SS7 맥락이 메시지 필드에 의미를 부여하는지 둘 다 말해야 한다.

RFC 3332는 의도적으로 서로 다른 작은 개체 집합으로 이 경계를 그렸다. Application Server는 특정 Routing Key에 대한 논리적 서비스다. 키는 선택 규칙이다. 즉, 처리할 트래픽 범위를 정의하는 SS7 매개변수 집합이다. 예로는 목적지 포인트 코드, 발신 포인트 코드, 서비스 지시자 등이 있고, 애플리케이션은 ISUP 회선 식별 코드나 SCCP 서브시스템 번호 같은 사용자 부분 필드를 추가할 수 있다. 이는 예시이지 보편적 조법이 아니다. 하나의 키는 비연속 범위를 기술할 수 있고, 유의미한 필드는 애플리케이션과 네트워크에 따라 달라진다.

Routing Context는 그 기준들의 압축 복사본이 아니다. Routing Key를 식별하는 값이다. SGP의 메시지 분배 기능이 트래픽을 키와 대조해 평가하고, 제어 메시지는 관련된 컨텍스트를 사용해 시작, 중지 또는 등록되어야 할 트래픽 집합을 참조한다. 키는 규칙이고, 컨텍스트는 그 규칙의 핸들이며, Application Server는 그 규칙이 선택하는 트래픽의 서비스라고 생각하면 된다. 이들을 서로 바꾸면 매칭 기준 또는 제어 동작에 사용되는 참조 중 하나를 잃게 된다.

네트워크 어피어런스는 보편적이지 않고 로컬이었다

Network Appearance는 다른 질문에 답한다. 이 시그널링 메시지는 어느 SS7 네트워크 맥락에서 해석되어야 하는가? 포인트 코드와 그 맥락이 함께 하나의 시그널링 노드를 식별한다. 이것은 게이트웨이가 동일한 포인트 코드 값을 재사용하는 여러 국가용 또는 사설 SS7 네트워크에 참여할 때 중요하다. 네트워크 차원이 없으면 겉보기에 정밀한 주소조차 두 개의 서로 다른 노드를 가리킬 수 있다.

그러나 Network Appearance는 인터넷 전역 네트워크 번호가 아니다. RFC 3332는 이를 Signalling Gateway Process와 Application Server 사이에서 조율되는 로컬 참조로 만들었다. RFC 3332를 폐기(obsolete)한 2006년 개정판 RFC 4666은 그 결과를 분명히 말한다. 동일한 하위 SS7 네트워크가 서로 다른 SGP에서 서로 다른 Network Appearance 값으로 표현될 수 있다. 매핑 기록 없이는 운영자가 게이트웨이 간에 정수를 비교해 같은 것을 가리킨다고 안전하게 가정할 수 없다.

이 필드는 한정된 구성에서는 선택 사항이기도 하다. 하나의 SS7 네트워크만 서비스하는 게이트웨이에는 필요 없을 수 있고, 하나의 네트워크 맥락에만 전용된 연결에도 필요 없을 수 있다. 공유 연결에서 맥락을 구분해야 한다면 수신자를 위해 이를 실어 보낼 수 있다. 따라서 결핍은 '모든 네트워크가 하나'라는 증거가 아니라 프로비저닝된 토폴로지의 속성이다. 마찬가지로 일부 제한된 단일 키 사례에서는 모든 메시지에 Routing Context를 담아 보내는 대신 암시할 수 있다. 프로토콜은 구성이 값을 모호하지 않게 만들 때 생략을 허용한다. 운영자는 여전히 구성이 있어야 그 이유를 알 수 있다.

하나의 연결이 여러 애플리케이션 상태를 담을 수 있었다

이 구분은 장애 조치(failover)에서 다시 중요해진다. ASP는 프로세스 인스턴스이지 서비스 정의 자체가 아니다. 하나의 ASP는 두 개 이상의 Application Server를 위해 구성될 수 있고, 하나의 SCTP 연결은 여러 AS와 관련된 트래픽을 실어 나를 수 있다. 그 결과 RFC 3332는 ASP의 상태를 AS별로 유지한다. ACTIVE는 소켓이나 장비의 속성이 아니라, 특정 애플리케이션 서비스 내에서 프로세스가 가진 트래픽 상태다.

트래픽 모드는 이 범위를 실제 동작으로 만든다. Override는 하나의 활성 ASP를 선택하고 나머지는 백업으로 남길 수 있고, Loadshare는 활성 프로세스들 사이에서 트래픽을 나눌 수 있으며, Broadcast는 트래픽을 모든 적격 활성 프로세스에 보낼 수 있다. 적절한 선택 알고리즘은 애플리케이션에 따라 달라진다. SGP가 어떤 프로세스가 메시지를 수신할지 결정할 때, 상태 변경과 Routing Context, 구성된 키는 결합된 채 유지되어야 한다. AS나 컨텍스트 없이 'ASP 활성'이라고만 말하면 불충분하고, 'SCTP 연결 성립'은 서비스 적격성에 관해서는 더욱 정보가 없다.

원격 사용자의 시각은 또 다른 계층을 더한다. M3UA는 사용 불가, 도달 가능, 제한 또는 혼잡한 목적지에 대한 DATA와 네트워크 관리 표시를 실어 나를 수 있다. 전송 연결은 종단이 서로 통신할 수 있음을 증명할 뿐이다. 포인트 코드와 네트워크 어피어런스 쌍이 의도대로 해석되었는지, 메시지가 승인된 Routing Key와 매칭되었는지, 해당 AS에 대해 ASP가 ACTIVE였는지, 원격 ISUP/SCCP 프로세스가 작업을 완료했는지는 증명하지 않는다. 각 주장에는 자기 계층의 수신 증거가 필요하다.

2002년 역사에서 2006년 개정판이 중요한 이유

역사적 주제는 RFC 3332이며, 그 문서가 현재판이라는 주장이 아니다. RFC 4666은 2006년 9월에 RFC 3332를 폐기했다. 개정 문서는 동일한 중심 구분을 유지한다. Routing Key는 트래픽 선택을 기술하고, Routing Context는 그 키를 식별하며, Network Appearance는 SS7 네트워크 맥락을 제공하며 로컬로 유지된다. 후속 문서를 읽으면 폐기된 사양을 오늘의 규범 문서처럼 다루지 않으면서 어떤 설계 경계가 유지되었는지 확인할 수 있다.

IANA SCTP 레지스트리는 현재 M3UA용 페이로드 프로토콜 식별자 3을 나열하고 RFC 4666을 인용한다. 서비스 이름 레지스트리는 SCTP 포트 2905에m3ua를 나열한다. 이 항목들은 엔지니어에게 어느 코드 포인트와 등록 포트가 할당되었는지 알려 준다. 통신사가 M3UA를 사용한다거나, 구현이 적합하다거나, 특정 연결이 통화를 실어 나랐다는 것은 보여 주지 않는다. 마찬가지로 RFC 9260은 현재 SCTP 사양이며, 그 지위가 실제 배포된 M3UA 시스템이 이를 채택했다는 것을 확립하지 않는다.

RFC 3331의 M2UA는 인접하지만 다르다. 물리 링크가 게이트웨이에 머무는 동안 MTP2-사용자 경계를 실어 나른다. M3UA는 대신 MTP3-사용자 시그널링, 즉 ISUP이나 SCCP 페이로드를 포함할 수 있는 것을 전송한다. RFC 4233의 IUA와 RFC 4165의 M2PA는 각자 자신의 어댑테이션 경계를 갖는다. 공통의 SIGTRAN 계보나 SCTP 전송을 공유한다고 해서 이름이나 상태 모델이 서로 바꿔 쓸 수 있는 것은 아니다.

실용적 검증은 네 가지 질문을 따로 따지는 것이다. 어떤 SS7 매개변수가 이 트래픽을 선택했는가, 어떤 Routing Context가 그 선택에 이름을 붙였는가, 어떤 로컬 Network Appearance가 이 SGP/ASP 쌍에서 포인트 코드에 의미를 부여했는가, 그리고 어떤 AS별 ASP 상태가 전달을 허용했는가. 그런 다음에야 SCTP 연결을 전송 경로로 연결해야 한다. RFC 3332의 가장 오래 지속되는 교훈은 규칙의 핸들, 규칙 자체, 네트워크 영역, 메시지를 실어 나르는 회선이 같은 개체가 아니라는 것이다.

출처