Diameter - 메세지 규격

노력하는백엔드·2025년 8월 11일
diameter이론
0

이론 정리

목록 보기
7/9

Diameter Header

  • 메시지의 유형, 처리 방법 등의 정보를 담은 핵심 부분
  • 목적
    • 메시지를 정확하게 구분
    • 올바른 경로/노드/애플리케이션으로 전달 및 처리 (메시지를 보고 노드가 라우팅테이블에서 전달 및 처리)
    • 요청-응답 매칭 (hob by hob Identifier)
    • 중복 메시지/에러/재전송 식별(endtoend Identifier, command flags)
  • 헤더 구조
    • Version: 프로토콜 버전(항상 1)
    • Message Length: 전체 메시지(헤더+AVP)의 바이트 길이, 4의 배수
    • Command Flags: 메시지의 특성(R: 요청/응답, P: 프록시 가능, E: 에러, T: 재전송 등)
    • Command Code: 메시지의 종류(예: 인증 요청/응답 등), IANA에서 관리
    • Application-ID: 어떤 Diameter 애플리케이션(인증, 회계 등)에 속하는지 구분
    • Hop-by-Hop Identifier: 각 연결별로 요청-응답을 매칭하는 고유 값(응답시 그대로 반환)
    • End-to-End Identifier: 전체 Diameter 네트워크에서 메시지 중복을 방지하는 고유 값
    • AVPs(Attribute-Value Pairs): 실제 데이터(속성-값 쌍), 헤더 다음에 붙음
  • Command Flags의 각 비트
    • R(Request): 1이면 요청, 0이면 응답
    • P(Proxiable): 1이면 프록시/릴레이/리다이렉트 가능
    • E(Error): 1이면 에러 메시지(응답만 해당)
    • T(Retransmitted): 1이면 재전송된 메시지

Command Code(명령 코드)

  • 각 명령(요청/응답)은 고유한 Command Code 보유
    • 요청/응답 구분은 Command Flag의 R 비트로 식별
  • 메시지가 어떤 동작을 수행할지 지정
  • 각 명령의 세부 사항은 Command Code Format(CCF)로 정의
  • Command Code 예시
명령 이름약어코드참고 절
Capabilities-ExchangeCER/CEA2575.3
Re-AuthRAR/RAA2588.3
AccountingACR/ACA2719.7
Abort-SessionASR/ASA2748.5
Session-TerminationSTR/STA2758.4
Device-WatchdogDWR/DWA2805.5
Disconnect-PeerDPR/DPA2825.4

Command Code Format 명령 형식 정의

  • CCF는 명령에 포함되어야 할 AVP(속성-값 쌍)와 규칙을 표준 문법(ABNF)으로 정의한다.
  • 주요 문법요소:
    • <> : 고정 위치 AVP
    • {} : 반드시 포함되어야 할 AVP(필수, 위치 무관, 1개 이상)
    • [] : 선택적 AVP(0개 또는 1개)
    • 1*{} : 최소 1개 이상의 반복(예: 1*{ Origin-Host }는 Origin-Host가 1개 이상 있어야 함)
    • min*max : 반복 최소/최대 개수 지정
    • "AVP" : 정의에 포함되지 않은 임의의 AVP 허용(확장성 목적)
  • R, P, E 비트:
    • REQ : 요청 메시지(R 비트 1)
    • PXY : 프록시 가능(P 비트 1)
    • ERR : 에러 메시지(E 비트 1)

Diameter 명령어 명명 규칙

  • 명령어는 한개의 영단어에 Request, Answer 동사를 붙여 구성
  • 영단어는 하이픈(-)으로 구분
  • 요청/응답은 동일한 Command Code 사용
  • R 비트가 설정되면 해당 동작은 Request 요청 역할
  • 수신자는 요청을 처리한 뒤 결과 코드를 포함한 응답 메시지를 반환(R 비트 해제)

Diameter AVPs

인증, 인가, 과금, 라우팅 등 각종 정보와 설정을 전달하는 기본 데이터 단위

  • OctetString 타입 AVP 경우 32비트(4바이트) 경계에 맞게 0으로 패딩 처리, 패딩은 length에 들어가지 않음

AVP Header

  • AVP Code
    • AVP를 식별하는 고유 번호, Vender-ID와 결합해 유일성을 가짐
      • 같은 AVP 코드여도 vender-id에 따라 의미가 다를 수 있음
      • 그래서 다르게 식별
    • 1~255 = RADIUS, 256 이상 Daimeter 전용
  • AVP Flags
    • 8비트 플래그
    • V(Vender-Specific) : 1 = Vender-ID 필드 포함, Verder의 특수한 AVP 라는 뜻
    • M(Mandatory) : 필수여부, 수신자가 해당 AVP를 이해해야만 한다는 뜻
    • P(Protected) : 향후 End to End 보안용으로 예약, 현재는 0으로 고정
    • r(Reserved) : 예약 비트, 항상 0
  • AVP Length
    • 3바이트
    • AVP 전체(header + vender-id + data)의 길이
    • 실제 AVP와 길이가 잘못될 시 거부해야 함
  • Optional Header Element
    • AVP Header에 선택적인 필드가 존재하며, V flag가 활성화 될 시 추가된다.
    • Vender-ID
      • V 비트가 1일 때 4바이트 Vender-ID가 헤더에 추가됨
      • IANA가 할당한 코드로써, Vender 별 고유 AVP를 구현할 때 사용
      • Vender-ID 값이 0이면 IETF 표준 AVP로 간주, 만약 0이라면 추가하지 않는 것을 권장

Diameter Peers

피어 : 자신과 직접 통신 가능한 다른 Diameter 노드이다.

피어는 클라이언트, 서버, relay, proxy 등 어떤 역할이든 될 수 있음

네트워크에서 피어 : 실제로 연결된 상대이며, 서로 프로토콜을 주고 받는 짝

Peer 연결

  • 모든 노드와 연결하지 않고, 각 도메인(Realm) 마다 최소 2개(주요, 보조) 피어와 연결해둔다.
  • 주로 주요 피어를 통해 보내지만 장애 발생 시 자동으로 보조 피어로 전환하여 서비스가 중단되지 않게 해야함
  • 피어가 여러개 있다면 로드 밸런싱 가능
  • 피어가 응답하지 않고, 일정 시간 동안 신호(DWA 등)이 없으면 의심(Suspect) 상태로 변경 의심 상태의 피어에는 더 이상 요청을 보내지 않고 failover 진행
  • 피어가 3번 연속 정상 응답하면 정상으로 상태 복구
  • 주요 피어가 사라지면 다른 피어가 그 역할을 이어받아 연결 유지

Peer 발견

노드는 누구와 연결할지, 어떻게 찾을 지도 매우 중요

피어 찾는 방식

  1. 수동 설정 : 네트워크 관리자가 직접 입력
  2. 자동 검색 : DNS(NAPTR, SRV) 레코드 기반

탐색 순서

  1. 수동으로 설정된 목록에서 연결 가능한 Peer 검색(정적 피어)
  2. 없으면 DNS 질의를 통해 해당 도메인에 적합한 Diameter 서버 주소를 자동으로 검색(동적 피어)

특징

  • DNS를 통해 찾은 도메인은 실제 서버의 인증서와 일치해야한다.
  • DNS로 찾았다고 해서 모드 피어가 될 수 있는 건 아니다. 반드시 Diameter 역할을 할 권한이 있는지 별도로 검증해야 함(Supported-Application-Id)
  • DNS로 등록된 피어는 DNS TTL이 지나면 새로 갱신 하거나 만료시켜야 함

Capabilities Exchange(기능 교환)

피어 연결 후 서로 지원하는 기능을 공유하는 절차

  • 노드가 서로 연결되면, 자신의 기능, 버전 보안 방식 등을 지원하는지 서로 알림
  • 서로 지원하지 않는 명령이나 실수로 보내지 않도록 하는 용도
  • 공통으로 지원하는 애플리케이션이나 보안 방식이 없으면 연결 종료

절차

  1. A → B : CER 전송 (A의 정보가 담겨있음)
  2. B → A : CEA 응답 (B의 정보가 담겨있음)
  3. 공통적으로 지원하는게 없으면 연결 Reject
  4. 지원하면 peer를 맺으면서 공통적으로 지원하는 옵션으로 상대 peer 정보 저장

메시지 종류

  1. Capabilities-Exchange-Request(CER)
  • 내가 지원하는 모든 정보를 상대에게 알리는 첫 메시지
  • 포함 정보 : 노드 이름/도메인, IP, Vender ID, FW Version, Supported-Application-Id 등
  1. Capabilities-Exchange-Answer(CEA)
  • CER의 응답 메시지
  • 포함 정보는 CER과 동일
  • 응답 결과(성공, 실패)를 보내며, Result-Code로 사유를 알려줌

Disconnecting Peer Connections(피어 연결 해제)

피어가 연결을 끊을 때 상대방은 사유를 알기 어렵다.

상대방에서 혼동을 막기 위해, 끊긴 사유(Disconnect-Cause)를 명시적으로 알리는 절차 제공

메시지 종류

  1. Disconnect-Peer-Request(DPR)
  • 연결을 끊을 거라는 정보를 보내는 메시지
  • Disconnect-Cause AVP 필수 포함
  • 네트워크 장애 발생 시 대체 피어로 DPR을 보내지 않는다.(네트워크 장애 발생 시 상대노드는 끊긴 것으로 판단)
  1. Disconnect-Peer-Answer(DPA)
  • DPR의 응답 메시지
  • DPR을 보낸 노드는 DPA를 받으면, 연결을 끊음
  • 처리 결과가 필요하다면 에러 정보가 포함될 수 있음

Transport Failure Detection(전송 장애 감지)

네트워크 장애 발생 시 최대한 빨리 감지해야 함

신속히 감지해야 사용 불가능한 노드에게 메시지를 보내는 것을 줄이고 장애 조치도 효과적으로 할 수 있음

각 노드는 이를 위해 DWR과 DWA 메시지를 통해 능동적으로 전송 장애 감지

메시지 종류

  1. Device-Watchdog-Requset(DWR)
  • 일정 시간 피어 간 트래픽이 없을 시 상대의 정상 여부를 확인하기 위한 메시지
  • 전송 시 응답이 없으면 장애로 판단
  • 장애로 판단된 피어는 보내지 않음
  1. Device-Watchdog-Answer(DWA)
  • DWR에 대한 응답 메시지
  • 응답을 통해 피어가 정상적으로 동작함을 확인

Transport Failure Algorithm

RFC 3539에 정의된 알고리즘으로 실제 장애 감지 방법을 사용

모든 Diameter 구현체는 해당 알고리즘을 지원해야 함

  • [RFC 3539] 알고리즘
  1. 일정 시간(Watchdog Timer) 동안 피어로부터 어떠한 메시지도 받지 못하면 장애로 간주
  2. 이때, DWR을 주기적으로 보내서 응답을 기다린다.
  3. 일정 횟수(일반적으로 3회) 동안 응답이 없으면 연결이 끊긴 것으로 판단 → 피어 상태 변경(의심, 끊김)

Failover And Failback Procedures

  • 목적지 피어의 통신 장애가 발생하면, 대체 피어에 해당 메시지를 재 전송(Failover)
    • Hop-by-Hop Identifier로 다른 곳에 보내도 메시지 매칭 가능
  • 대체 피어가 없을 시 메시지의 E 비트를 활성화하며, DIAMETER_UNABLE_TO_DELIVER 코드를 포함해서 오류 응답
  • 장애 복구(Failback)가 되면, 해당 피어로 메시지 전송 가능
  • Failover 과정에서 중복 메시지 발생 가능서 있음
    • End-to-End Identifier와 Origin-Host AVP로 중복 메시지 식별

Peer State Machine

  • 모든 노드는 피어별로 정해진 상태 머신 준수

  • 상태 머신은 모든 연결 관리를 표준화

  • 각 상태와 전이는 피어 사이의 실제 네트워크 이벤트에 의해 결정

    tip

    • 연결 과정에서 CER/CEA 메시지 교환과 election(중복 연결 해소)이 자동으로 이루어진다.
    • TLS/DTLS 연결을 우선적으로 사용해 보안을 보장하며, 연결이 닫힐 때 TLS/DTLS도 같이 종료한다.

Incomming Connections(수신 연결)

  • 피어로 연결 요청이 들어오면, 신원은 CER 메시지가 도착하기 전까지 알 수 없음
  • CER 메시지의 Origin-Host 정보를 통새 상대 피어 신원 확인
  • CER이 오기 전 다른 메시지가 수신되거나, 타임아웃이 발생 시 연결 종료

Event

  • 상태 머신에서 전이(Transition)와 동작(Action)은 이벤트로 인해 발생

    • Start : Diameter 애플리케이션이 피어와의 연결 시작을 요청함
    • R-Conn-CER : 연결이 성립되었고, CER 메시지가 수신됨을 알리는 신호
    • Rcv-Conn-Ack : 연결 성립이 성공적으로 확인됨
    • Rcv-Conn-Nack : 연결 성립이 실패했음
    • Timeout : 정해진 시간 내에 이벤트가 오지 않아 타임아웃 발생
    • Rcv-CER : 피어로부터 CER 메시지를 받음
    • Rcv-CEA : 피어로부터 CEA 메시지를 받음
    • Rcv-Non-CEA : CEA 이외의 메시지를 받음
    • Peer-Disc : 피어가 연결 끊김(디스커넥트)을 알림
    • Rcv-DPR : 피어로부터 Disconnect-Peer-Request를 받음
    • Rcv-DPA : 피어로부터 Disconnect-Peer-Answer를 받음
    • Win-Election : election(선택)에서 로컬 노드가 승리함
    • Send-Message : 메시지를 전송해야 함
    • Rcv-Message : CER, CEA, DPR, DPA, DWR, DWA 외의 메시지를 받음
    • Stop : 애플리케이션이 연결 종료(예: 시스템 셧다운)을 요청함

Action

  • 이벤트에 의해 발생
  • 대게 패킷 전송 혹은 연결 상태에 따른 조치
    • Snd-Conn-Req : 피어와의 전송 연결을 시작함
    • Accept : 수신 연결(R-Conn-CER 이벤트에 대한)을 수락함
    • Reject : 수신 연결을 거부함
    • Process-CER : 수신된 CER 메시지를 처리함
    • Snd-CER : 피어에게 CER 메시지를 보냄
    • Snd-CEA : 피어에게 CEA 메시지를 보냄
    • Cleanup : 필요시 연결을 종료하고 로컬 리소스를 해제함
    • Error : 에러 발생 시 전송 계층 연결을 해제하고, 리소스를 해제함
    • Process-CEA : 수신된 CEA 메시지를 처리함
    • Snd-DPR : 피어에게 Disconnect-Peer-Request를 보냄
    • Snd-DPA : 피어에게 Disconnect-Peer-Answer를 보냄
    • Disc : 전송 계층 연결을 끊고, 리소스를 해제함
    • Elect : election(선택) 과정을 진행함(5.6.4 참고)
    • Snd-Message : 메시지를 보냄
    • Snd-DWR : DWR 메시지를 보냄
    • Snd-DWA : DWA 메시지를 보냄
    • Process-DWR : DWR 메시지를 처리함
    • Process-DWA : DWA 메시지를 처리함
    • Process : 메시지를 처리함

Election Process(선택 과정)

  • 두 피어가 동시에 서로 연결 요청을 하면, 둘 중 한 연결만 남겨야 한다.
  • 자신의 Origin-Host와 CER의 Origin-Host를 사전 순으로 비교해 결정(사전 순으로 빠르면 연결)
  • 나머지 하나의 연결 시도는 DPR로 종료
profile
노력하는백엔드
열심히 노력하는 백엔드입니다.
이전 포스트

Diameter - 배경 및 용어 정리

다음 포스트

Spring Boot

0개의 댓글