Overview

One-to-One = Unicast

One-to-Many = Multicast

One-to-All = Broadcast

통신을 다수의 대상과 하려면 어떡해야 할까요?
만약 Unicast를 여러 번 날린다면 현재 네트워크에서 트래픽에 오버헤드가 발생할 겁니다.
만약 Broadcast를 날린다면 보안 상의 위험이 생길 수도 있고, 대상에 속하지 않는 호스트들이 데이터 수신을 위해 오버헤드를 감수해야 할 겁니다.

따라서 내가 원하는 대상들만을 목표로 패킷을 날려 효율적으로 자원을 이용하는 것이 좋을 겁니다.

IGMP는 바로 이러한 요구사항에 의해 설계된 프로토콜입니다.

Multicast Architecture

Multicast 프로토콜은 기본적으로 아래와 같이 계층화되어 설계되었습니다.
이를 감안하고 아래의 내용을 읽어주세요.

서비스 제공자, 수신자, 중심 라우터가 존재하는데요.

서비스 제공자는 중심 라우터에게 데이터를 제공하는 책임을 집니다.
서비스 수신자는 중심 라우터에게 그룹에 가입하거나 탈퇴하는 등의 행위를 요청할 책임을 집니다.
중심 라우터는 그룹을 관리하고, 서비스 제공자로부터 받은 데이터를 수신자에게 분배하는 역할을 합니다.

Multicast Address

Multicast를 통해 대역폭의 낭비를 줄이고, 효율성과 확장성을 얻는 것이 목표인데요.

이를 위해서 기존의 IPv4 주소와는 다르게 고유하게 그룹을 식별할 새로운 주소를 도입하는데요.

이를 통해 sender는 수신자의 정보에 대해서 신경쓸 필요가 없어집니다.
자신이 보낼 그룹의 식별자에 대해서만 알면 됩니다.

또한 receiver는 만약 네트워크 위치를 바꾸더라도 sender에게 이를 알릴 필요 없이 데이터를 수신할 수 있습니다.

이전에 IPv4 주소에 대해서 다룰 때, class D(prefix 1110, 224.0.0.0 ~ 239.255.255.255)가 multicast를 위해 예약되었던 것을 기억하시나요?
바로 이때 class D 주소가 사용됩니다.

Multicast에서 라우터의 역할은 중요한데요.
그룹 멤버 간의 링크를 유지하고 데이터를 분배해야할 책임이 있기 때문입니다.

Multicast Service Model

1. 수신자는 Multicast group에 가입하고 multicast 주소를 통해 식별됩니다.
2. 송신자는 data를 multicast 주소를 통해 송신합니다.
3. Network는 데이터를 각 수신자에게 Best Effort를 통해 전송합니다.

Routing

멀티캐스팅에 관여하는 라우터들을 멀티캐스트 라우터(MR)이라고도 부릅니다.

각 MR은 자신이 관리하는 그룹의 멤버에게 데이터가 분배될 수 있도록 인터페이스를 관리하여 경로를 형성합니다.

이러한 경로는 MR 중 하나를 루트로 하는 하나의 트리로 표현됩니다.
이 루트가 되는 MR를 루트라우터라고 부르는데요.
루트라우터는 서비스 제공자로부터 데이터를 제공받아 모든 그룹 멤버에게 데이터를 분배하기 위한 중심점이 됩니다.
따라서 루트라우터를 어떻게 설정하는지가 Multicast Routing의 핵심적 요인인데요.

크게 2가지 방식이 있습니다.

1. Source Based Tree

서비스 제공자가 속한 네트워크의 라우터가 곧 루트가 되어 그룹을 관리하는 형태입니다.
기본적으로 각 서비스 제공자로부터 최소비용경로로 수신자에게 도달하는 트리입니다.
따라서 end-to-end delay가 짧다.

그러나 멀티캐스트는 그룹 망 내의 모든 라우터가 관련 정보를 저장하고 관리해야하는데,

Source Based의 경우 모든 라우터가 모든 그룹(송신자)에 대해서 이러한 정보를 저장, 관리해야 하기 때문에 망내 부담이 커지고 거대한 네트워크에서 다양한 서비스 제공이 어려워집니다(낮은 확장성).

2. Group Shared Tree

Group을 기준으로 트리의 루트를 형성하는 방식입니다.

따라서 Group 내에 여러 개의 서비스 제공자가 존재할 수 있습니다.

Group을 기준으로 루트 라우터가 형성되기 때문에 모든 데이터 제공이 루트 라우터를 거치는 오버헤드가 발생합니다.

따라서 비교적 높은 딜레이(최대 2배)가 발생하고, 루트 라우터에 트래픽이 집중되는 문제가 있습니다.

하지만 그룹 단위로 라우터들이 상태를 관리하기 때문에 거대한 네트워크에서도 높은 확장성으로 서비스를 제공할 수 있습니다.

IGMP

멀티캐스팅의 설계와 라우팅에서의 고려요소를 알아보았습니다.

이제 구체적으로 그룹이 어떻게 관리되는지 알아볼 것인데요.
인터넷 상에서 이러한 그룹을 관리하기 위해 IGMP가 만들어졌습니다.

IGMP는 멀티캐스팅 그룹을 생성하고, 멤버십 리스트를 관리하는데요.
이 때 멤버십에 가입한 멤버는 호스트나 라우터 모두 가능합니다.

이때 주의할 점은 멀티캐스트 라우팅 테이블은 특수한 라우팅 프로토콜에 의해 업데이트된다는 점입니다. 즉, IGMP는 라우팅에 대해서 관여하지 않습니다.

멀티캐스트 라우터는 자신과 연결된 각 그룹이 향할 인터페이스를 리스트로 관리합니다.

IGMP messages

IGMP 메세지는 크게 Query와 Membership Report, Leave Report 3가지 종류로 나뉘고 그 중 Query는 다시 General과 Special로 나뉩니다.

IGMP 패킷은 아래와 같이 메세지 타입, 최대 응답 시간(10초 단위), 체크섬과 그룹 주소로 이루어집니다.

이때 General Query는 주소를 0으로 한다는 점에 주의합니다.

Joining(Leaving) a Group

먼저 수신자가 그룹에 가입하는 경우를 살펴보겠습니다.

각 호스트(혹은 라우터)는 Membership Report(MR) 패킷을 통해 그룹에 가입할 수 있습니다.

호스트는 자신이 구독한(가입한) 그룹의 id들을 리스트로 관리하는데요. 만약 새로운 그룹 id가 있을 경우 MR을 보내게 됩니다.

마찬가지로 라우터도 각 인터페이스마다 연결된 그룹의 id들을 리스트로 관리하는데요.

만약 어떤 인터페이스에서 새로운 그룹 id의 MR이 도착하면, 해당 인터페이스를 제외한 모든 인터페이스로 MR을 전달합니다.

General & Special Query

멀티캐스트 라우터들은 주기적으로 자신과 연결된 인터페이스의 노드(호스트 or 라우터)들에게 어떤 그룹을 구독하고 있는지 질의를 보냅니다.

이 때 General Query의 경우 노드들이 구독 중인 모든 그룹에 대해서 질의를 보내고
Special Query는 특정 그룹에 대해서 구독 여부를 질의한다는 차이가 있습니다.

이때 노드들은 반드시 10초 안에 자신이 구독 중인 각 그룹 id에 대해서 membership request를 보내야 합니다.

이 때 한 번에 너무 많은 membership report가 라우터에 몰릴 위험이 존재하는데요.

이를 위해 Delayed Response라고 하는 기법을 적용합니다.
만약 Query에 응답하는 Membership Report의 경우 각 그룹마다 10초 이내의 시간에서 랜덤한 시간을 설정해 그 시간 동안 응답을 delay한 뒤 membership report를 보냅니다.

query의 목적은 해당 인터페이스에 한 명이라도 구독자가 존재하는지 점검하는 것입니다.

따라서 자신의 네트워크에서 이미 누군가 membership report가 날리면 해당 그룹에 대해선 응답할 필요가 없어지는데요.
이때 아직 응답을 delay 중일 경우 해당 작업을 그냥 취소합니다.

이 경우 time 12에 Host A의 그룹 228.42.0.0에 대한 타이머가 종료되어 membership report가 전송됩니다.

따라서 host B의 해당 그룹 타이머도 즉시 취소됩니다.

time 30에는 225.14.0.0에 대한 Host A의 타이머가 종료되어 membership report를 날리고 해당 그룹의 Host C 타이머가 취소됩니다.

IGMP with IP datagram

마지막으로 다루어볼 것은 IGMP 전체 패킷의 모습인데요.

IGMP는 network layer의 프로토콜이지만, IP 패킷에 감싸집니다.
이 때, IP 헤더의 protocol 필드는 2이며 ttl은 1로 설정되는데요.
ttl이 1인 이유는 패킷이 LAN을 벗어날 필요가 없기 때문입니다.

일단 라우터에 IGMP 패킷을 전달하고 나면 나머지는 라우터가 관리를 하게 됩니다.

한편, IP 주소는 아래와 같이 예약됩니다.

Leaving의 경우 인터페이스 내의 모든 라우터에게 요청하여 그룹에게 leaving을 보냅니다.

라우터는 이 때, query를 보내 구독 중인 호스트를 다시 한 번 체크합니다.

또한 data link 차원에서 그룹을 관리할 필요성이 있는데요.
switch 차원에서 그룹을 관리하기 위해 class D 주소를 ehternet 주소로 맵핑하기도 합니다.