요약

  • RFC 3108에서 SDP는 트래픽이 기술 대상 ATM 노드로부터 멀어질 때 '포워드'라고 불렀다. 반면 ATM 베어러 시그널링은 베어러 설정을 시작한 엔드포인트로부터 멀어질 때 '포워드'라고 불렀다. 백워드 설정에서는 동일한 매개변수가 계층 사이에서 이름이 바뀌었다.
  • 4바이트eecid는 서비스 수준 통화 기록과 이후의 베어러 요청을 일대일로 연결했다. 이는 지역적으로 범위가 한정된 상관 키였을 뿐, 발신자 신원도, 전역 연결 이름도, 미디어가 흐르고 있다는 증거도 아니었다.

잘못된 좌표계 속의 올바른 값

하나의 미디어 게이트웨이 옆에 두 개의 제어 패널이 있다고 상상해 보자. 첫 번째 패널은 피크 셀 레이트가 게이트웨이를 떠나는 트래픽이기 때문에 포워드라고 말한다. 두 번째 패널은 동일한 레이트가 백워드라고 말한다. 원격 게이트웨이가 베어러를 시작했고 이 게이트웨이가 설정 요청을 받았기 때문이다. 어느 패널도 틀리지 않았다. 각자 다른 원점을 선택했을 뿐이다.

바로 이것이 2001년 5월 표준 트랙(Standards Track)으로 발표된 RFC 3108에 담긴 번역 문제였다. 이 문서는 원래의 세션 기술 프로토콜(Session Description Protocol)인 RFC 2327의 문법을 확장하여 컨트롤러와 게이트웨이가 ATM 및 AAL2 베어러 연결을 기술할 수 있도록 했다. 주소, 어댑테이션 계층, 트래픽 디스크립터, 품질 매개변수, 베어러 유형, 채널 식별자, 서비스 선택에 대한 속성을 제공했다. 이러한 기술은 SIP, MGCP 또는 Megaco/H.248 제어 교환과 함께 전달될 수 있었다.

역사적 관심은 그 목록 이면에 있다. 서비스 수준 통화 제어와 ATM 베어러 시그널링은 독립적인 시스템이었다. 전화나 멀티미디어 통화를 시작한 측이 반드시 그 통화를 실어 나르는 스위치드 가상 연결(SVC)을 시작하는 것은 아니었다. 이 역할들이 분리되는 순간, 익숙한 방향성 단어들은 더 이상 이식 가능하지 않게 되었다.

RFC 3108은 포워드를 기술 대상 ATM 노드를 기준으로, 즉 그 노드로부터 멀어지는 방향으로 정의했다. 백워드는 그 노드를 향하는 방향이었다. 이 규칙은 서비스 통화나 베어러를 누가 시작했는지와 무관하게 안정적으로 유지되었다. ATM과 AAL2 시그널링은 또 다른 관례를 사용했다. 거기서 포워드는 베어러 설정 요청을 보낸 엔드포인트에서 받은 엔드포인트로 향하는 방향이었다.

서비스를 시작한 게이트웨이가 베어러도 함께 시작하는 경우 두 프레임은 정렬될 수 있었다. 그러나 백워드 베어러 모델에서는 서비스를 시작한 게이트웨이가 대신 베어러 요청을 종단했다. 그 게이트웨이로부터 멀어지는 트래픽 디스크립터는 SDP 기술에서는 포워드로 남지만 ATM 설정에서는 백워드가 되었다. 게이트웨이는 의미를 뒤집어야 했다. 바이트 단위로 충실하게 복사하는 것은 의미 오류를 낳았을 것이다.

방향은 문법이 아니라 데이터였다

RFC 3108은atmQOSparms,atmTrfcDesc같은 속성에 방향을 명시적으로 담았다. 이들의directionFlag는f,b,fb일 수 있었다. 즉 포워드, 백워드 또는 둘 다였다. 이러한 라인에서는 다른 매개변수가 미지정, 부적용 또는 다른 곳에서 제공되어로 표시되는 경우에도 플래그가 필수였다.

트래픽 값은 장식이 아니었다. 디스크립터는 피크 셀 레이트와 지속 셀 레이트, 버스트 크기, 지연 편차, 전송 지연, 허용 가능한 손실 비율을 담을 수 있었다. 게이트웨이가 유효한 값을 잘못된 방향에 붙이면 세션 기술은 여전히 파싱되면서 의도된 자원 계약은 뒤집혔다. 어느 한 경로가 잘못된 용량이나 품질 제약을 받을 수 있었고, 그 결과 컨트롤러는 실제로는 동일한 흐름에 대해 합의한 적이 없는 메시지들 간의 합의를 보고할 수도 있었다.

바로 이런 이유로 RFC 3108은 SDP를 위한 ATM 어휘 정도로 환원될 수 없다. 이 문서는 번역 경계를 명시했다. 구현체는 최소한 네 가지 사실을 유지해야 했다. SDP 기술이 어떤 노드에 대한 것인지, 어떤 엔드포인트가 서비스 수준 제어를 시작했는지, 어떤 엔드포인트가 베어러 설정을 시작했는지, 그리고 현재 처리 중인 필드를 어떤 관례가 지배하는지. 이러한 사실 없이는 '포워드'라는 단어 자체가 불완전한 증거였다.

와일드카드는 이 점을 강화했다. 여러 필드에서$는 수신자가 허용되는 값을 선택하도록 했다. 하이픈은 필드에 따라 무관함, 암시됨, 미지정 또는 다른 메커니즘을 통해 알려짐을 의미할 수 있었다. 파서는 문법이 합법적임을 확인할 수 있었지만, 선택된 값이 하드웨어에 존재하는지, 정책상 허용되는지, 애플리케이션에 타당한지는 확인할 수 없었다.

하나의 서비스 통화, 하나의 베어러 요청, 하나의 로컬 조인

분리된 제어 경로는 두 번째 문제를 낳았다. 서비스 수준 지시가 ATM 설정 요청보다 먼저 게이트웨이에 도착할 수 있었다. 나중에 네트워크로부터 베어러 요청이 나타나면 게이트웨이는 그 요청이 어느 이전 서비스 컨텍스트에 속하는지 알아야 했다.

RFC 3108은 이 조인을 위해eecid, 즉 단대단 연결 식별자를 사용했다. 인용된 ATM 및 ISUP 설정에서는 4바이트bnc-id와 동의어였지만, SDP는 중립적인 이름을 사용했다. 이 값은 수신된 베어러 설정 요청 하나를 서비스 수준 통화 제어 기록 하나와 상관시켰다.

선택자는 설정 모델에 따라 달라졌다. 포워드 베어러 설정의 경우 통화 착신 게이트웨이가eecid를 선택하고, SDP를 통해 발신 게이트웨이 쪽으로 보낸 뒤, 발신 측이 시작한 베어러 요청에서 그 값을 다시 받았다. 백워드 설정의 경우 발신 게이트웨이가 값을 선택하고 SDP를 통해 착신 측으로 보낸 뒤, 착신 게이트웨이가 베어러를 시작할 때 그 값을 다시 받았다.

겉보기 왕복은 의도적인 인수인계였다. 베어러 설정을 종단할 노드가 미래의 요청을 자신이 인식할 수 있는 값을 선택했다. RFC 3108은 인터넷 전역, 심지어 모든 게이트웨이 전역이 아니라 그 종단 노드 내에서의 유일성을 요구했다. 값을 할당한 노드가 해제와 재사용을 통제했다. 요청이 도착한 후 값을 해제할 수 있었지만, 문서는 연결이 끝날 때까지 유지할 것을 권고했다.

이 범위 설정은 여러 유혹적인 추론을 차단한다.eecid는 사람을 명명하지 않았고, 가입자를 인증하지 않았고, ATM 회선을 할당하지 않았으며, 양방향 미디어가 존재한다는 증거도 아니었다. 그것은 두 프로토콜 경로를 가로지르는 로컬 데이터베이스 키였다. 일치하는 값은 상관 관계를 확립했다. 이후의 설정 및 연결(setup/connect) 교환이 베어러 상태를 확립했다. 서비스의 성립을 확인하려면 여전히 패킷과 애플리케이션 수준의 측정이 필요했다.

RFC 3108은 베어러 인코딩까지 소유하지는 않았다. 당대의 베어러 프로토콜이 이 값을 전달할 수 있는 방식—예컨대 특정 정보 요소—을 기술했지만, 그 전송은 해당 프로토콜에 맡겼다. SDP 기록과 ATM 시그널링 기록은 동일한 상관 관계를 표현하면서도 각각 별도로 관리되는 산출물로 남을 수 있었다.

기술, 설정, 트래픽은 서로 다른 세 가지였다

통화 설정 예제는 이 분리를 잘 보여준다. 미디어 게이트웨이 컨트롤러들이 서비스 정보를 교환했다. 각 컨트롤러는 자신의 게이트웨이에 지시했다. 그러면 한 게이트웨이가 이전에 교환된eecid와 함께 ATM 설정을 상대 게이트웨이로 직접 보냈다. 수신 측은 이 키를 사용해 이전 제어 컨텍스트를 찾아 connect 메시지를 반환했다. 이 시퀀스가 끝나고 나서야 미디어가 베어러를 사용할 수 있었다.

SDP 본문만 기록한 운영자는 무엇이 기술되었는지는 알 수 있었지만 무엇이 구축되었는지는 알 수 없었다. 제어 확인 응답은 게이트웨이가 지시를 수락했음을 보여줄 뿐, 원격 네트워크가 SVC를 허용했음을 보여주지 않았다. setup 메시지는 시도를 보여줄 뿐 connect를 보여주지 않았다. connect는 베어러가 설정되었음을 보여줄 뿐, 허용 가능한 지연이나 손실, 양방향 애플리케이션 동작을 보여주지 않았다.

RFC 3108의chain속성은 같은 분리의 또 다른 양상을 다루었다. 연속된 SDP 기술은 하나의 세션에 대한 대안일 수도, 서로 다른 계층—예컨대 IP 세션과 그 ATM 캐리어—을 기술하는 것일 수도 있었다.chain은 한 기술이 다음 또는 이전 기술에 속함을 명시하면서 기술들이 깔끔하게 분리된 채로 남도록 했다. 연결이 곧 실행은 아니었다. 체인은 기술들을 연결했을 뿐, 어느 계층이든 실제로 동작하고 있다는 것을 증명하지 않았다.

이 계층적 독해는 이후의 SDP 역사를 과거에 투사하는 것도 막아준다. RFC 3264는 RFC 3108 이후인 2002년에 offer/answer 모델을 정식화했다. RFC 4566과 RFC 8866은 그 뒤에 SDP 자체를 개정했다. 이들은 지속되는 계보를 보여주지만, 2001년의 모든 ATM 기술이 이후의 교환 패턴을 따랐거나 RFC 3108 관례가 널리 배치되었다는 증거는 아니다.

보안은 외피에 속했다

RFC 3108은 보안에 대해 솔직했다. ATM과 AAL2 베어러의 암호화는 RTP 페이로드 암호화처럼 관례화되지 않았으며, 베어러 시그널링의 인증 역시 관례화되지 않았다고 명시했다. SDPk=라인은 키 또는 키를 얻는 방법을 표현할 수 있었지만, 표현이 곧 보호의 증거는 아니었다.

기술은 신뢰할 수 없는 가입자 구내의 장비로부터 올 수 있었다. RFC는 기술 내부에 새로운 보안 시스템을 만드는 대신, 그것을 감싸는 프로토콜이나 하위 계층에 의존했다. SIP, MGCP, Megaco 환경은 IPsec 인증과 선택적 암호화를 사용할 수 있었다. '할 수 있었다'는 표현이 중요했다. 사양 속의 안전한 구성은 특정 교환이 그것을 사용했는지, 어떤 피어 간에 보안 연관이 수립되었는지, 베어러 자체가 암호화되었는지를 말해주지 않았다.

따라서 증거 사슬에는 독립적인 기록들이 필요했다. 정확한 SDP 본문과 그 발신자, 기준 노드. 서비스 통화 역할. 베어러 설정의 원점. 번역된 방향 필드.eecid할당자와 범위. 베어러 요청과 connect. 인증 및 암호화 상태. 설치된 QoS. 카운터. 양방향 패킷. 그리고 애플리케이션의 결과.

이 역사는 이식 가능한 단어에 대한 경고다

RFC 3108은 쇠퇴하는 전송 기술에 덧붙는 복잡한 부록 정도로 쉽게 치부될 수 있다. 그러나 그것은 이 문서의 오래된 교훈을 놓치는 것이다. 분산 시스템은 owner, active, local, primary, forward 같은 평범한 단어를 계층을 넘어 재사용하는 경우가 잦다. 단어는 안정적으로 남아 있지만 좌표계는 바뀐다. 그 결과물인 메시지는 유효하고, 서명되어 있고, 충실히 복사되었음에도 다음 제어 표면에서는 틀릴 수 있다.

2001년의 미디어 게이트웨이는 더 권위 있는 문서를 고르는 방식으로 그 문제를 해결할 수 없었다. 두 기술 모두 각자의 계층 내에서 권위 있었다. 게이트웨이는 두 기술 사이를 번역하고, 어느 프레임이 적용되는지 알기에 충분한 출처 정보를 유지해야 했다. 상관 키는 기록들을 서로 합쳐버리는 척하지 않으면서 연결했다.

두 계층 모두 포워드라고 말했다. 그들은 전송 계층에 대해 의견이 다른 것이 아니라, 방향의 시작점이 어디인지에 대해 의견이 다른 것이었다. 게이트웨이의 임무는 동작 중인 베어러 상태와 관찰된 미디어가 기술을 증거로 대체할 수 있을 때까지 그 구분을 살아 있게 유지하는 것이었다.

출처

  1. https://www.rfc-editor.org/rfc/rfc3108.html
  2. https://www.rfc-editor.org/info/rfc3108
  3. https://datatracker.ietf.org/doc/rfc3108/
  4. https://www.rfc-editor.org/rfc/rfc2327.html
  5. https://www.rfc-editor.org/info/rfc2327
  6. https://datatracker.ietf.org/doc/rfc2327/
  7. https://www.rfc-editor.org/rfc/rfc2543.html
  8. https://www.rfc-editor.org/info/rfc2543
  9. https://www.rfc-editor.org/rfc/rfc2705.html
  10. https://www.rfc-editor.org/rfc/rfc2805.html
  11. https://www.rfc-editor.org/rfc/rfc3015.html
  12. https://www.rfc-editor.org/rfc/rfc3264.html
  13. https://www.rfc-editor.org/rfc/rfc4566.html
  14. https://www.rfc-editor.org/rfc/rfc8866.html