강력한 헤더 압축

Robust Header Compression

ROHC(Robust Header Compression)는 인터넷 패킷의 IP, UDP, UDP-Lite, RTP, TCP 헤더를 압축하는 표준화된 방법이다.

헤더 압축 필요성

스트리밍 애플리케이션에서 IP, UDP 및 RTP의 오버헤드는 IPv4의 경우 40바이트, IPv6의 경우 60바이트가 된다. VoIP의 경우 이는 전송된 총 데이터 양의 약 60%에 해당한다. 그러한 큰 오버헤드는 용량이 자주 문제가 되지 않지만 대역폭이 부족한 광역 네트워크와 무선 시스템에 과도한 지역 유선 링크에서 허용될 수 있다.[1]

ROHC는 제한된 용량을 가진 링크 앞에 압축기를 놓고 그 링크 뒤에 압축기를 놓아 이러한 40바이트 또는 60바이트의 오버헤드를 보통 1 또는 3바이트로 압축한다. 압축기는 큰 오버헤드를 몇 바이트로만 변환하는 반면, 압축 해제기는 그 반대로 변환한다.

ROHC 압축 체계는 IETF와 같은 다른 압축 체계와 다르다. RFC 1144 및 RFC 2508은 무선 링크와 같이 패킷 손실률이 높은 링크에서 성능을 발휘한다.

주요 ROHC 압축 원리

ROHC 프로토콜은 다음과 같은 머리글의 정보 중복성을 이용한다.

  • 단일 네트워크 패킷(예: IP 및 UDP 헤더의 페이로드 길이)
  • 하나의 단일 스트림에 속하는 여러 네트워크 패킷(예: IP 주소)

중복 정보는 첫 번째 패킷에서만 전송된다. 다음 패킷은 식별자 또는 시퀀스 번호와 같은 가변 정보를 포함한다. 이러한 필드는 더 많은 비트를 저장하기 위해 압축된 형태로 전송된다.

더 나은 성능을 위해 패킷은 압축되기 전에 스트림으로 분류된다. 이 분류는 패키지 간 중복성을 이용한다. 분류 알고리즘은 ROHC 프로토콜 자체에 의해 정의되는 것이 아니라 장비 공급업체의 구현에 맡겨진다. 일단 패킷 스트림이 분류되면 가장 적합한 압축 프로파일에 따라 압축된다. 압축 프로필은 네트워크 헤더에서 다른 필드를 압축하는 방법을 정의한다. 다음과 같은 여러 압축 프로필을 사용할 수 있다.

  • 압축되지 않음
  • IP 전용
  • UDP/IP
  • UDP-Lite/IP
  • ESP/IP
  • RTP/UDP/IP
  • RTP/UDP-Lite/IP
  • TCP/IP

운전모드

RFC 3095에 따르면, ROHC 체계는 다음과 같은 세 가지 운영 방식을 가지고 있다.

  • 단방향 모드(U-모드)
  • 양방향 낙관 모드(O-모드)
  • 양방향 신뢰성 모드(R-모드)

컴프레서와 압축 해제기는 모두 U-모드에서 시작한다. 그런 다음 사용 가능한 리턴 링크를 사용할 수 있는 경우 O-모드로 전환할 수 있으며, 압축 해제기는 O-모드가 지정된 긍정적인 확인을 컴프레서로 전송한다. R-모드로의 전환도 같은 방법으로 달성된다.

단방향 모드(U-Mode)

단방향 작동 모드에서 패킷은 압축기에서 압축 해제기로의 한 방향으로만 전송된다. 따라서 이 모드는 압축기로의 복귀 경로를 사용할 수 없거나 바람직하지 않은 링크를 통해 ROHC를 사용할 수 있게 한다. 잠재적인 감압 오류를 처리하기 위해 압축기는 스트림 컨텍스트의 정기적인 새로 고침을 압축 해제기로 보낸다.

양방향 낙관 모드(O-Mode)

양방향 낙관 모드는 피드백 채널을 사용하여 오류 복구 요청 및 (선택적으로) 압축기로의 중요한 컨텍스트 업데이트 내용을 전송한다는 점을 제외하면 단방향 모드와 유사하다. O-모드는 압축 효율의 극대화를 목표로 하며 피드백 채널의 희박한 사용을 목표로 한다.

양방향 신뢰 모드(R-Mode)

양방향 신뢰할 수 있는 모드는 이전 두 모드와 여러 면에서 다르다. 가장 중요한 차이점은 피드백 채널의 보다 집중적인 사용과 매우 높은 잔류 비트 오류율을 제외하고 컴프레서와 압축 해제기 사이의 컨텍스트 동기화의 손실을 방지하는 압축기와 압축 해제기의 보다 엄격한 논리다.

컴프레서/디컴프레서 상태

압축기/디컴프레서 상태의 개념은 작동 모드에 직교한다. 모드가 무엇이든 컴프레서와 압축 해제기는 세 상태 중 하나에서 작동한다. 그것들은 기본적으로 유한한 상태의 기계들이다. 모든 수신 패킷은 컴프레서/디컴프레서의 내부 상태를 변경할 수 있다. 모든 상태는 정의된 동작과 압축 수준을 가리킨다.

ROHC 알고리즘은 IP 패킷 흐름을 나타내기 위해 기본 프레임과 여러 가지 차이 프레임이 전송된다는 점에서 비디오 압축과 유사하다. 이는 기본 프레임이 손실되지 않는 한 ROHC가 가장 높은 압축 상태에서 많은 패킷 손실을 버틸 수 있는 장점이 있다.

컴프레서 상태

컴프레서의 상태 기계는 다음 세 가지 상태를 정의한다.

  • IR(Initialization and Refresh) 상태
  • 첫 번째 주문(FO) 상태
  • 2차 주문(SO) 상태

다른 컴프레서 상태에서의 작동

IR(Initialization and Refresh) 상태에서는 컴프레서가 방금 생성 또는 재설정되었으며 전체 패킷 헤더가 전송된다. 1차 주문(FO) 상태에서 컴프레서는 정적 필드(예: IP 주소 및 포트 번호)를 감지하여 연결부의 양쪽에 저장하였다. 압축기는 또한 FO 상태에서 동적 패킷 필드 차이를 전송하고 있다. 따라서 FO 상태는 본질적으로 정적 및 유사 동적 압축이다. SO(Second-Order) 상태에서 컴프레서는 RTP 시퀀스 번호와 같은 모든 동적 필드를 억제하고 논리 시퀀스 번호와 부분 체크섬만 전송하여 상대편이 다음 예상 패킷의 헤더를 예측적으로 생성 및 검증하도록 한다. 일반적으로 FO 상태는 모든 정적 필드 및 가장 동적 필드를 압축한다. SO 상태는 시퀀스 번호와 체크섬을 사용하여 모든 동적 필드를 예측적으로 압축하고 있다.

컴프레서 상태 간 전환

위의 상태 간의 전환은 컴프레서가 다음과 같은 경우에 발생한다.

  • 변형이 너무 많은 패킷을 압축하다
  • 압축 해제기로부터 긍정적인/부정적인 피드백을 받다
  • 주기적으로 맥락을 새로 고치다.

2차 ROC 헤더 – 1바이트 헤더

일반적인 ROHC 구현은 1바이트 ROHC 헤더를 40바이트 IPv4/UDP/RTP 또는 60바이트 IPv6/UDP/RTP(즉, VoIP) 헤더를 대체할 수 있는 2차 주문 상태로 단말기를 전환하는 것을 목표로 한다. 이 상태에서 8비트 ROHC 헤더에는 다음과 같은 세 가지 필드가 있다.

  • 1비트 패킷 유형 플래그(긴 ROC 헤더에 대해서만 '1'로 설정)
  • 4비트 시퀀스 번호(기본 프레임에서 -1 ... +14 패킷 범위 포함)
  • 3비트 CRC

압축 해제 상태

압축 해제기의 상태 기계는 다음과 같은 세 가지 상태를 정의한다.

  • 컨텍스트 상태 없음
  • 정적 컨텍스트 상태
  • 전체 컨텍스트 상태

위 상태 간의 전환은 압축 해제기:

  • 패킷의 압축을 성공적으로 풀다.
  • 여러 패킷의 압축을 풀지 못함

강건함

시퀀스 번호(SN) 필드의 크기는 컴프레서를 재설정하여 계속하려면 ROHC가 손실될 수 있는 패킷 수를 제어한다. W-LSB 알고리즘은 SN을 강력한 방법으로 압축하는 데 사용된다. 1바이트와 2바이트 ROHC 패킷의 시퀀스 번호 크기는 각각 4비트( -1/+14 프레임 오프셋 ) 또는 6비트( -1/+62 프레임 오프셋 )이므로, 1-2바이트 헤더로 손실된 프레임은 최대 62개까지 허용할 수 있다.

추가 압축 프로필

RFC 3095는 일반적인 압축 메커니즘을 정의한다. 특정 프로토콜 헤더 전용의 새로운 압축 프로파일을 정의하여 확장할 수 있다. 새로운 RFC는 새로운 프로토콜을 압축하기 위해 발표되었다.

  • RFC 3843은 IP 헤더 또는 IP 터널에 대한 압축 프로필을 정의한다.
  • RFC 4019는 UDP-Lite/IP 및 RTP/UDP-Lite/IP 헤더에 대한 압축 프로필을 정의한다.
  • RFC 6846은 TCP/IP 헤더에 대한 압축 프로필을 정의한다.

새로운 ROHC RFC

ROHC를 해석하고 구현하려고 할 때 일부에서 부딪힌 혼란을 해결하기 위해 RFC 4995와 RFC 5225를 새로 발행한 RFC가 두 개 있다. 첫 번째 문서는 ROHC 프레임워크를 정의하고, 두 번째 문서는 기존의 ROHC 프로파일의 새로운 버전을 정의한다.

참고 항목

참조

  1. ^ Michael Dosch and Steve Church. "VoIP In The Broadcast Studio". Axia Audio. Archived from the original on 2011-10-07. Retrieved 2011-06-21.

외부 링크