IPv4의 기본 헤더는 20 바이트의 길이를 가지고 있으며 또한 IPv6의 경우에는 40 바이트의 길이를 가지고 있다. 그리고 IPv6의 경우에는 링크 계층에서 전송되는 최대 전송 단위인 MTU(Maximum Transmission Unit)가 최소 1280 바이트 이상 되어야 한다고 규정하고 있다. 그런데 현재 운용되고 있는 네트워크 중에는 저전력 또는 저속 등으로 자원이 제한된 노드들을 연결하기 위한 네트워크들이 존재하며 이러한 네트워크에서 제공하는 MTU는 IPv6에서 규정하고 있는 MTU보다 작은 경우가 존재한다. 또한 만일 실제 전송되는 데이터의 크기가 10 바이트 정도로 작은 크기의 데이터를 특히 IPv6 기반의 네트워크에서 전송하는 경우에는 데이터보다 헤더의 크기가 더 커서 효율이 떨어지게 된다. 이러한 문제점을 해결하기 위하여 2013년 7월 28일부터 8월 2일까지 독일 베를린에서 개최된 IETF 87차 회의에서는 압축과 관련된 두 개의 BoF가 개최되었다. 여기에서는 IETF 87차 회의에서 논의된 압축과 관련된 표준화 활동에 대해서 알아보고자 한다.

1. 6lo(IPv6 over network of resource-constrained nodes)

6lo는 센서와 같이 제안된 CPU와 메모리, 그리고 제한된 전력 자원을 가진 장치들로 구성된 네트워크에서 IPv6를 지원하기 위한 방법을 제공하기 위하여 제안되었다. 실제로 IPv6에서 요구하는 최대 전송 단위인 MTU는 최소 1280 바이트가 되어야 한다고 규정하고 있지만 IEEE 802.15.4 링크 계층에서 표준화가 진행되고 있는 프로토콜들의 MTU는 127 바이트로 제한된 것들이 있으며 이러한 링크 계층에서 IPv6 패킷을 전송하기 위한 적응 계층은 6LoWPAN(IPv6 over Low Power Wireless Personal Area Network) 워킹 그룹에서 RFC 4944로 표준화되었다. 또한 이 표준안에는 헤더 압축에 대한 내용도 정의되어 있다. 6LoWPAN에서 원래 작성하고자 했던 표준안은 완성이 되었으며 더 이상의 추가적인 작업이 없는 상태에서 RFC 4944를 기반으로 하여 (1) ITU-T G.9959 네트워크에서 IPv6 패킷을 전송하기 위한 프레임 포맷과 주소 설정 방법, (2) DECT 초저전력 기반 망에서 IPv6 패킷 전송 방안, (3) RS-485를 이용한 저속 시리얼 라인에서 IPv6 구동 방법과 같은 여러 가지 서로 다른 특성을 가진 링크 계층에서 IPv6를 지원하기 위한 방법, 그리고 (4) 6LoWPAN에서 정의된 헤더 압축 방법 외에 일반 헤더와 UDP와 ICMPv6와 같은 헤더와 유사한 페이로드를 압축하기 위한 기법, 그리고 (5) IPSec을 위한 헤더 압축 방법 등을 정의하기 위한 기고들이 제안되었다. 이 외에도 (6) IEEE802.15.4 무선 메쉬 네트워크에서 신뢰성 있는 무선 링크를 설정하고 구성하기 위한 메쉬 링크 설정 프로토콜, (7) 여러 개의 에지 라우터가 마치 하나인 것처럼 동작하는 방식, 그리고 (8) 단편화된 패킷을 효율적으로 재전송하는 방식 등도 제안되었지만, 6LoWPAN 워킹 그룹이 실질적으로 종료되어 더 이상 논의할 수 있는 공간이 없다는 것이 문제로 대두되었다. 이에 87차 IETF회의에서는 6LoWPAN의 후속 작업으로 제한된 자원을 가진 노드로 이루어진 네트워크에서 IPv6를 제공하기 위한 방안으로 6lo 워킹 그룹의 활동을 개시하기 위한 논의가 있었으며, 많은 사람들이 6lo 워킹 그룹의 필요성에 대해서 동의하였다.

2. TCMTF(Tunneling Compressed Multiplexed Traffic Flows)

최근에 작은 크기로 이루어진 데이터를 인터넷을 통하여 전송하는 응용들이 보편화되며 또한 이러한 응용들로부터 전송되는 트래픽이 폭발적으로 증가하고 있다. 첫 번째로 인터넷을 통한 VoIP나 화상 회의, 원격 비디오 경비, 온라인 게임 등과 같은 쌍방향 실시간 멀티미디어 서비스로부터 발생하는 실시간 트래픽이 급격히 증가하고 있다. 이러한 멀티미디어 서비스들은 수십 바이트 정도의 작은 패킷을 사용하며 또한 실시간 서비스를 제공하기 위하여 작은 크기의 패킷들이 빈번하게 전송되어야 한다. 두 번째로 인터넷 메신저 또는 센서들로부터 전송되는 데이터들은 지연에 민감하지는 않지만 역시 데이터의 크기가 수십 바이트 정도로 작다. 따라서 이러한 크기가 작은 데이터를 인터넷을 통하여 전송하는 경우에는 오버헤드가 상당히 증가하게 된다. 실제로 IPv4/UDP/RTP 헤더의 크기는 40 바이트이며 IPv6의 경우에는 헤더의 크기가 60 바이트가 된다. 이러한 네트워크에서 크기가 10 바이트인 데이터 샘플을 전송하는 경우에는 데이터보다 헤더의 크기가 훨씬 커서 네트워크가 비효율적으로 사용되는 문제가 발생하게 된다. 만일 작은 크기의 데이터 여러 개를 하나의 IP 패킷에 함께 실어 보낸다면 효율은 증가하게 될 것이다. 즉, 여러 개의 플로우가 동일한 경로를 공유하는 경우에 서로 다른 플로우로부터 발생하는 데이터를 하나의 IP 패킷에 실어 보낸다면, 여러 데이터를 하나의 패킷에 넣는 방법인 다중화를 위하여 필요한 약간의 지연을 허용한다면 인터넷의 대역폭을 아낄 수 있을 것이다. 그렇지만 이러한 약간의 지연은 게임과 같이 실시간 전송을 필요로 하는 응용들에게는 품질에 영향을 미칠 수 있을 것이다. 따라서 이러한 다중화를 하기 위하여 필요한 추가적인 지연은 각각의 플로우 또는 응용이 요구하는 지연 관련 품질 요구사항을 충족할 수 있는 범위 내에서 가능할 것이다. 다음 그림은 여러 개의 작은 크기의 데이터를 하나의 패킷에 실어 보내는 경우의 예를 보여준다. 인터넷의 성능은 패킷의 크기 보다는 패킷의 갯수에 좌우한다. 따라서 작은 크기의 여러 개의 패킷을 전송하는 것보다 큰 크기의 하나의 패킷을 전송하는 것이 인터넷의 성능을 향상시키는데 중요하다고 할 수 있다.

<그림 1> TCM-TF 기본 개념

(출처: http://www.ietf.org/proceedings/87/slides/slides-87-tcmtf-4.pdf)

RTP를 이용하는 VoIP는 작은 크기의 패킷으로 인하여 오버헤드가 상당히 큰 실시간 서비스의 전형적인 예라 할 수 있다. 이러한 낭비를 줄이기 위하여 RFC4170에서는 ECRTP(Enhanced Compressed RTP)에 의한 헤더 압축, PPPMux를 이용한 다중화, L2TPv6를 이용한 터널링과 같은 세 개의 서로 다른 계층을 이용하여 여러 개의 플로우가 하나의 경로를 공유하는 경우에 패킷을 그룹화하기 위한 방법을 정의하고 있다. 그렇지만 UDP/RTP를 이용하지 않고 UDP 자체를 이용하는 실시간 서비스가 등장하고 보편화되며 RoHC(Robust Header Compression)와 같은 새로운 헤더 압축이 제안되고 표준화되어서 UDP/RTP뿐만 아니라 UDP 또는 TCP 만을 이용하는 프로토콜이나 RFC4170에서 정의되지 않은 다른 헤더 압축 방법을 고려하기 위하여 RFC 4170을 확장하는 것이 필요하다는 논의가 있어 왔고, 이러한 RFC의 확장을 논의하기 위한 공간으로 TCMTF라는 새로운 워킹 그룹을 만들기 위한 회의가 있었다. TCMTF에서는 <그림 2>에 나타나 있는 것과 같이 (1) 헤더 압축, (2) 다중화, (3)터널링의 세 개의 계층을 정의하고, (1) 각각의 계층에서 사용될 수 있는 서로 다른 옵션들을 정의하기 위한 TCMTF 참조 모델의 표준화, (2) 다중화/역다중화 집합이 TCMTF 세션을 개설하고자 하는 경우에 각 계층에서 사용하고자 하는 옵션을 결정하고 또한 세션을 해지하기 위한 메커니즘을 정의하기 위한 TCMTF 협상 프로토콜 표준화, 그리고 (3) 대역폭 감소의 이익을 얻기 위하여 다중화를 하는 경우에 증가할 수 있는 지연과 지터가 서비스의 품질 요구 사항에 대한 영향을 고려하여 어떤 플로우는 다중화가 가능하고 또한 어떤 플로우는 다중화하지 않아야 되는지를 결정하는데 도움을 줄 수 있는 TCMTF 권고안 등의 표준화 등의 제정을 목표로 하고 있다.

<그림 2> TCM-TF 프로토콜 스택

(출처: http://www.ietf.org/proceedings/87/slides/slides-87-tcmtf-2.pdf)

87차 IETF 회의에서는 TCMTF 워킹 그룹 제정을 위한 회의가 있었는데, TCMTF에 대한 발표 후에 여러 가지 질문들이 제기되었다. 질문 중의 한 가지는 TCMTF와 관련된 특허는 어떤 것이 있는지를 조사했는지에 대한 것이었다. 그리고 두 번째로 TCP의 경우에는 TCP 세그먼트를 전송하면 ACK를 수신하기 위하여 클럭을 구동하는데, 서로 다른 TCP의 클럭의 동기로 여러 개의 패킷이 동시에 전송되는 경우가 발생할 수 있으며, 이러한 경우를 고려하거나 또는 해결하거나 완화하기 위한 경험이 있는지에 대한 질문이 있었다. 또한 다중화 된 패킷이 손실되는 경우에는 어떻게 동작하는지에 대한 질문도 있었다. 이 경우에는 패킷의 손실은 패킷에 포함된 모든 다중화된 패킷의 손실을 의미하는데, 패킷이 손실되면 혼잡 제어는 어떻게 동작하는지에 대한 질문도 있었으며, 이 외에도 IP 자체는 비연결형이므로 종단간에 터널이 유지되는지를 확인하기 위한 방법은 고려하는지와 경로 MTU는 어떻게 되는지에 대한 질문도 있었다. 또한 약간의 대역폭 이득을 얻는 것이 지연과 복잡도 증가에 비해서 얼마나 큰 이득이 있는지 등에 대한 이슈가 제기되었고, TCMTF에서 하고자 하는 범위를 다시 정의하고 또한 해결해야 할 사항을 추가로 논의하는 것이 필요하다는 의견이 많아서, TCMTF가 새로운 워킹 그룹이 되기 위해서는 좀 더 많은 논의가 이루어진 후에 가능할 것이라 생각한다.