지난번에도 설명한 바와 같이 IP 멀티캐스팅을 위해서는 클래스 D 어드레스를 사용한다. 클래스 D 어드레스는 첫 번째 옥텟(Octet)의 상위 비트(High-Order Bit)가 1110으로 고정되고 28비트의 멀티캐스트 그룹 ID(Multicast Group ID) 어드레스가 그 다음에 위치한다(그림 1). 클래스 D 어드레스의 범위는 224.0.0.0 에서 239.255.255.255까지다. 첫 번째 옥텟의 상위 비트가 이 224 베이스(224-base) 어드레스를 구별해 준다.
이 어드레스도 클래스 A, B, C와 마찬가지로 IANA(www.iana.org) 로부터 각 기업이나 단체가 할당받아야 한다. 단일 IP 어드레스 방식으로 배정받는 IP 멀티캐스트 어드레스는 하나의 어드레스만으로도 여러 개의 호스트에 동시에 데이터를 전송할 수 있기 때문에 그룹 단위의 할당은 불필요하다. 일종의 TV나 라디오의 방송 채널과 같은 것이라고 생각하면 된다.

멀티캐스팅 어드레스 체계
물론 기업이나 단체에 따라 여러 개의 클래스 D IP 어드레스를 받기도 하는데 어드레스를 여러 개 가지고 있다면 여러 채널을 확보하고 있는 것이나 마찬가지다. 클래스 D IP 멀티캐스트 어드레스도 제한적인 자원이기 때문에 기업이나 단체들은 현재는 사용하지 않더라도 향후 멀티캐스트 인터넷 방송 등을 위해 미리 어드레스를 확보하고 있다.
클래스 A, B, C의 사설 IP 어드레스와 마찬가지로 클래스 D도 239.0.0.0에서 239.255.255.255까지의 관리 영역(Administrative Scoping)이라는 사설 멀티캐스트 영역을 갖고 있다. 기업이나 단체의 내부 네트워크에서만 화상 회의나 인터넷 방송을 멀티캐스트로 전송하려면, IANA에 등록하지 않고서도 이 어드레스 영역을 사용해 서비스할 수 있다.
참고로 클래스 D IP 멀티캐스트 어드레스는 종종 멀티캐스트 그룹 어드레스(Multicast Group Address), 멀티캐스트 그룹 ID라고 불린다. 하나의 클래스 D IP 어드레스가 여러 호스트 그룹에 동시에 전달되기 때문에 붙여진 것이다.
멀티캐스트용 2계층 어드레스는 각각의 네트워크 기술마다 미리 정해져 있다. 이더넷, 토큰링, FDDI에서 사용하는 방법은 3계층 멀티캐스트 IP 어드레스의 일부 어드레스를 멀티캐스팅용 MAC 어드레스로 지정한 어드레스의 뒤에 붙이는 방법을 사용하고 있다.
48비트를 사용하는 이더넷 어드레스는 01.00.5E를 멀티캐스트 MAC 어드레스의 시작 부분으로 예약해 뒀다. 16진수인 01.00.5E를 2진수로 변환한 00000001.00000000.01011110.의 맨 뒤에 0비트를 추가해 00000001.00000000.01011110.0을 만든다. 3계층 클래스 D의 왼쪽에서 9번째 비트를 제외한 10번째부터 32비트를 그대로 이 어드레스의 뒷부분에 매핑해 멀티캐스트용 이더넷 MAC 어드레스를 생성한다(그림 2).
주의해야 할 점은 클래스 D 멀티캐스트 IP 어드레스의 뒤쪽 세 개의 옥텟을 모두 사용하는 것이 아니라 두번째 옥텟의 첫번째 비트인 이진수 1, 즉 십진수로 표현했을 때 128을 나타내는 비트는 사용하지 않는 다는 것이다.

멀티캐스팅을 위한 어드레스 매핑
다음 (그림 3)의 예를 통해 보다 구체적으로 살펴보고 발생할 수 있는 문제점도 생각해 보자.
(그림 3)은 227.154.65.50의 이진수 표현인 11100011.10011010. 01000001.00110010의 뒷부분 세 개의 옥텟을 01.00.5E의 이진수 표현인 00000001.00000000.01011110.0에 연결해 00000001.00000000. 01011110.00011010.01000001.00110010 즉, 01.00.5E.1A.41.32라는 멀티캐스트 MAC 어드레스를 매핑하는 과정을 보여주고 있다.
그런데 중요한 점은 227.154.65.50의 11100011.10011010. 01000001.00110010의 아홉번째 128을 나타내는 1비트를 사용하지 않았기 때문에 01.00.5E.1A.41.32가 된다는 점을 주의해야 한다. 만약 이 비트를 사용했다면 01.00.5E.9A.41.32가 됐을 것이다.
하지만 여기서는 한가지 문제가 발생할 수 있다. 227.26.65.50의 클래스 D IP 멀티캐스트 어드레스가 매핑된 이더넷 MAC 어드레스가 227.26.65.50의 이진수 형태의 9번째 비트를 사용하지 않기 때문에 01.00.5E.1A.41.32 만들어져 결국 227.154.65.50과 동일하게 표기된다. 이같은 상황이 큰 문제가 되지 않는 이유는 다음과 같다.
첫째는 227.26.65.50와 227.154.65.50처럼 MAC 어드레스가 중복되는 클래스 D 멀티캐스트 어드레스를 동시에 사용하거나 클라이언트 애플리케이션이 동시에 받을 확률이 일단 적기 때문이다. 둘째는 2계층에서는 같은 어드레스로 처리되지만, 어차피 3계층으로 올라오면서 목적지 클래스 D 멀티캐스트 어드레스가 다를 것이고 4계층의 UDP 포트 번호도 다를 것이다. 이것을 사용할 애플리케이션에게 전달하게 됨으로써 결국 3계층에서 흥미없는 목적지 어드레스이거나 포트 번호면 패킷을 버리면 되는 것이다.
셋째는 나중에 따로 설명하겠지만 원래 이더넷 스위치는 멀티캐스트를 브로드캐스트와 동일하게 처리해도 문제가 없다고 생각한다. 즉, 시스코의 CGMP와 같은 기능을 가지고 있지 않는 이더넷 스위치나 허브는 멀티캐스트 MAC 어드레스를 가진 프레임이 들어오면 전 포트로 플러딩(Flooding)한다. 하필이면 중복이 생겨서 다른 호스트가 쓸모없는 패킷을 받지만 전체적으로 플러딩하는 것에 비하면 별 문제될 것은 없다는 것이다.
송신하는 장치가 수신하는 호스트에게 패킷을 보내기 위해 목적지 멀티캐스트 IP 어드레스에 대응하는 멀티캐스트 어드레스를 자동으로 생성해 프레임의 목적지 MAC 어드레스로 지정할 수 있다. 따라서 멀티캐스트에서는 ARP 작업을 유니캐스팅처럼 수행하지 않아도 된다. 마찬가지로 브로드캐스트 어드레스는 FFFF.FFFF.FFFF로 정해져 있어 또한 ARP가 필요 없다.
자동적으로 생성되는 이더넷, 토큰링, FDDI의 MAC 어드레스와 다르게 WAN 기술과 프로토콜은 예약된 어드레스를 사용하거나 어드레스를 직접 지정할 수 있도록 하고 있다. 프레임 릴레이에서 멀티캐스트는 DLCI 1019에서 1022까지로 예약돼 있으며, X.25, ATM, SMDS 등은 ‘E.164 Multicast Address exxx.xxxx.xxxx’ 형태의 명령을 통해 지정할 수 있다.
멀티캐스트 어드레스의 표현방식은 3계층 클래스 D IP 멀티캐스트 그룹 어드레스와 2계층 멀티캐스트 MAC 어드레스의 매핑을 통해 자동으로 생성된다.

IGMP 프로토콜의 역할
이번에는 IP 멀티캐스팅에서 IGMP(Internet Group Management Protocol)의 역할에 대해서 알아보자.
IP 멀티캐스트와 관련한 세 가지 중요한 프로토콜에는 IGMP, CGMP, 멀티캐스팅 라우팅 프로토콜이 있다. 먼저 CGMP는 멀티캐스트가 가능한 스위치와 멀티캐스트가 가능한 라우터간에 통신하는 프로토콜로 멀티캐스트가 가능한 호스트가 IGMP를 통해 자신이 받기를 원하는 멀티캐스트 그룹 어드레스를 라우터에게 알렸을 때 그 어드레스로 등록된 호스트들의 MAC 어드레스를 멀티캐스트가 가능한 라우터가 스위치에게 알리는 프로토콜이다.
멀티캐스트 라우팅 프로토콜(Multicast Routing Protocol)은 호스트가 알린 멀티캐스트 그룹 어드레스를 이용해 멀티캐스트가 가능한 라우터와 라우터간에 멀티캐스트 전송 경로를 구성하기 위해 통신하는 프로토콜이다.
IGMP는 (그림 4)와 같이 멀티캐스트가 가능한 호스트와 멀티캐스트가 가능한 라우터 간에 통신하는 프로토콜로 주로 호스트가 멀티캐스트 그룹 어드레스를 라우터에게 등록하는 프로토콜이다. 이것은 멀티캐스트 기능을 제공하기 위한 호스트용 프로토콜로 일반 호스트, 라우터, 스위치에 거의 기본적으로 탑재돼 있다.
이 프로토콜의 용도는 호스트가 멀티캐스트 데이터를 받고자하는 목적지 어드레스인 멀티캐스팅 그룹 어드레스(클래스 D 멀티캐스팅 어드레스)를 라우터에게 알려 멤버로 등록한 후 그 어드레스로 전송되는 패킷을 전송해 달라고 요구하거나, 더 이상 데이터를 수신을 원치 않으면, 라우터에게 해지를 요구할 때 사용된다.
라우터는 IGMP를 통해 네트워크 환경 안에 멀티캐스트 클라이언트 호스트가 존재한다는 것을 인식하고 자신의 한 인터페이스를 통해서 데이터가 그 멀티캐스팅 그룹 어드레스의 목적지 어드레스로 들어오면 이 멀티캐스팅 그룹 어드레스를 등록한 호스트가 있는 인터페이스로 그 데이터 경로를 설정하는 것이다.
또한, IGMP를 통해서 등록된 멀티캐스팅 그룹 어드레스와 이 어드레스를 등록한 호스트의 MAC 어드레스(유니캐스트 MAC 어드레스)를 CGMP 프로토콜로 스위치에 보내, 스위치가 전체 포트에 플러딩하는 것이 아니라 멀티캐스팅 그룹 어드레스에 등록한 호스트를 가진 포트에만 데이터를 전달할 수도 있다.
한편 라우터는 IGMP를 통해 등록한 호스트가 계속해서 멀티캐스트 데이터를 받고자하는지 질의하는 용도로도 사용한다.

IGMP의 동작 과정
IGMP는 버전 1과 버전 2가 있는데 여기서는 주로 버전 2에 대하여 설명하겠다. 첫번째로 (그림 5)에서와 같은 다중 메시지 형식(Multiple Message Type)은 IGMP 패킷의 전송 목적을 나타낸다.

쪾 0x11: 멤버십 쿼리(Membership Query)를 나타내며, 라우터가 호스트에게 주로 보낸다. 멀티캐스트 데이터를 받기를 원하는 클라이언트가 있는지(General Query), 특정한 멀티캐스팅 그룹 어드레스로 전송되는 데이터를 계속 받기를 원하는 호스트가 있는지(Specific Query) 등의 질의에 사용한다.
쪾 0x12: 버전 1 멤버십 리포트는 호스트가 버전 1로 자신이 데이터를 받기를 원하는 멀티캐스팅 그룹 어드레스를 보고할 때 사용된다.
쪾 0x16: 버전 2 멤버십 리포트는 호스트가 버전 2로 자신이 데이터를 받기를 원하는 멀티캐스팅 그룹 어드레스를 보고할 때 사용된다.
쪾 0x17: 해지 리포트(Leave Report)는 버전 2에만 있는 기능으로 호스트가 라우터에게 자신이 등록한 멀티캐스팅 그룹 어드레스로 오는 데이터를 더 이상 받고 싶지 않을 경우, 자신이 등록한 멀티캐스팅 그룹 어드레스를 명시적으로 해지해 달라고 요구하는 명령이다.

최대 반응 시간(Max. Resp. Time)은 멀티캐스트 그룹 어드레스의 등록과 해지를 빠르게 수행하기 위해서 사용한다. 라우터가 질의를 호스트들에 보내고 일정한 시간 동안 응답이 없으면 관련된 멀티캐스팅 그룹 어드레스를 빠르게 해지하기 위해서 사용한다. 1/10초 단위로 지정하며, 기본값은 10초다.
그룹 어드레스는 호스트가 라우터에게 보고하거나 라우터가 호스트에게 질의할 때 사용하는 멀티캐스트 그룹 어드레스다. 호스트가 라우터에게 등록할 때는 데이터의 수신을 원해 등록이나 해지를 요구하는 멀티캐스트 그룹 어드레스가 들어간다. 라우터가 일반 쿼리(General Query)를 수행할 때는 0.0.0.0이, 지정 쿼리(Specific Query)를 수행할 때는 특정한 멀티캐스팅 그룹 어드레스가 들어간다.
멀티캐스팅 방식을 통해 데이터를 전송받기를 원하는 애플리케이션을 수행하면 호스트는 IGMP를 통해 자신이 데이터를 받기를 원하는 멀티캐스팅 그룹 어드레스를 라우터에 보내 등록한다. 그래서 라우터가 이 멀티캐스팅 그룹 어드레스의 목적지로부터 오는 데이터가 있으면 이 데이터를 등록한 호스트가 있는 인터페이스로 전송한다.
(그림 6)에서 호스트 A는 멀티캐스팅 방식으로 데이터 수신을 요구하는 애플리케이션을 수행했는데 목적지 멀티캐스팅 그룹 어드레스가 227.26.65.50인 패킷을 받기 원한다. 이 어드레스를 224.0.0.2를 가진 목적지 어드레스로 즉시 전송한다. 224.0.0.2는 멀티캐스트 어드레스 중에서 현재 서브넷에 존재하는 멀티캐스팅이 가능한 모든 라우터들을 나타내는 용도로 예약된 어드레스다. 마찬가지로 라우터가 호스트와 통신할 때 자주 사용하는 어드레스는 224.0.0.1이다. 이것은 현재 서브넷에 존재하는 멀티캐스팅이 가능한 모든 호스트를 나타낸다.
호스트 A가 등록한 결과를 라우터에서 ‘show ip igmp group’라는 명령으로 확인한 것이 다음 내용이다. 마지막에 Last Reporter가 호스트 A의 어드레스로 되어 있다.

Router>show ip igmp Group
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
227.26.65.50 Ethernet0 6d17h 00:02:31 10.10.10.101

(그림 7)은 호스트 C가 멀티캐스팅 애플리케이션을 시작하면 현재 라우터가 227.26.65.50 멀티캐스팅 그룹 어드레스를 갖고 있는 것과 상관없이 227.26.65.50 멀티캐스팅 그룹 어드레스에 대한 등록 작업을 수행한다. 따라서 Last Reporter가 호스트 C의 IP인 10.10.10.103으로 바뀐 모습을 나타내고 있다.
(그림 8)과 같이 등록된 멀티캐스팅 그룹 어드레스를 보유한 라우터는 그 멀티캐스팅 그룹 어드레스가 살아있어 계속적으로 데이터를 받기 원하는지 알기 위해 주기적으로 질의를 보낸다. 이 질의는 그 멀티캐스팅 그룹 어드레스를 등록한 모든 호스트가 듣게 된다.
질의에 대한 응답은 쓸모없는 트래픽을 줄이기 위해 서브넷 당, 그룹 당, 하나의 멤버만 보고한다. 어차피 라우터 입장에서는 그 서브넷에 하나라도 멀티캐스팅 그룹 어드레스에 해당하는 데이터를 받고자하는 호스트가 있다면 데이터를 내보내야 하기 때문이다.
(그림 9)는 멀티캐스트 애플리케이션이 종료되면 호스트는 IGMP를 이용해 자신이 등록한 멀티캐스팅 그룹 어드레스로부터 탈퇴하겠다는 것을 라우터에게 알려, 더이상 데이터를 보내지 않도록 조치하는 것을 말한다. 다음은 이 해지 과정을 단계별로 설명한 것이다.

① 호스트 A가 등록한 멀티캐스팅 그룹 어드레스를 탈퇴하기 위한 해지 메시지를 보낸다. 자신이 멤버로 속해있던 멀티캐스팅 그룹 어드레스 227.26.65.50을 목적지 어드레스 224.0.0.2로 탈퇴 메시지를 보내는 것이다. 앞에서도 언급한 바와 같이 224.0.0.2는 서브넷에 존재하는 멀티캐스팅이 가능한 모든 라우터를 말한다.
② 라우터는 227.26.65.50에 대해 멤버십을 유지하고 싶은 호스트가 있는지 그룹 지정 쿼리(Group Specific Query)를 목적지 어드레스 224.0.0.1로 보낸다. 앞에서도 언급한 바와 같이 224.0.0.1은 서브넷에 존재하는 모든 멀티캐스팅이 가능한 모든 호스트를 말한다.
③ 호스트 C가 여전히 227.26.65.50으로 들어오는 데이터를 받기를 원한다면, 멤버십을 계속 유지하고 싶다고 보고한다. 227.26.65.50은 계속해서 활성화된(Active) 상태로 남고 라우터는 227.26.65.50으로 목적지 어드레스로 들어오는 데이터를 해당 인터페이스로 계속해서 내보낼 것이다.

호스트 A가 탈퇴한 후 라우터의 IGMP 그룹 멤버십 상태는 다음과 같다(그림 10).

Router>show ip igmp Group
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
227.26.65.50 Ethernet0 6d17h 00:02:31 10.10.10.103

Last Reporter가 계속 10.10.10.103으로 유지되고 있다. 라우터는 227.26.65.50에 대해 Ethernet 0 쪽에 10.10.10.103을 비롯한 호스트가 지속적인 데이터 수신을 요구하는 것으로 인식하고 계속 데이터를 전송한다.
227.26.65.50 멀티캐스팅 그룹 어드레스에 속하는 마지막 호스트인 호스트 C가 애플리케이션을 종료하면 호스트는 IGMP를 통해 227.26. 65.50 멀티캐스팅 그룹 어드레스를 떠나기 위한 해지 메시지를 보낸다. 라우터는 227.26.65.50에 대한 그룹 지정 쿼리를 보내고 응답이 없으면 그룹은 타임 아웃된다. 라우터는 IGMP 그룹 멤버십 테이블에서 리스트를 제거하고 해당하는 인터페이스로 더 이상 데이터를 내보내지 않는다(그림 11).
호스트 C가 마지막으로 227.26.65.50의 그룹 멤버를 떠나게 된 후 라우터의 IGMP 그룹 테이블이 다음과 같이 비게 된다(그림 12).

Router>show ip igmp Group
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter

이와 같이 IGMP는 멀티캐스트가 가능한 호스트와 라우터간에 멀티캐스팅 그룹 어드레스에 호스트가 멤버로 등록, 탈퇴, 유지되기 위해 사용하는 프로토콜이다. 하는 일은 많고 중요한 프로토콜이지만 정작 관리자가 IGMP를 위해서 해야 할 일은 거의 없다.