Multicast Basics

Multicast Routing Basics
배움과나눔N교육센터 http://www.lsinc.co.kr
10-1
이 장에서는 IP Multicast의 기본적인 개념과 관련 Protocol들에 대해 배울 것이다.
1
개관
IP 패킷 전송 방식
멀티캐스팅 주소 체계
IGMP(Internet Group Management Protocol)
CGMP(Cisco Group Management Protocol)
멀티캐스팅 라우팅 프로토콜
멀티캐스팅 설정 및 활용
10-2
이 장에서 배우는 내용들은 다음과 같다.

IP 패킷 전송 방식:
대표적인 IP packet의 전송방식인 Unicast, Boradcast, Multicast에 대한
개념과 장.단점을 배운다.
멀티캐스팅 주소 체계:
IP Multicast에서 사용하는 주소 체계를 이해한다.
IGMP(Internet Group Management Protocol):

Router와 Host들이 Multicast Group에 어떻게 참여하고 해제되는지를 IGRP의
동작을 통해 알아본다.
CGMP(Cisco Group Management Protocol):

Router와 Switch사이에서 Multicast traffic의 전달을 위해 CGMP를 어떻게
활용하는지 알아본다.
멀티캐스팅 라우팅 프로토콜:

IP Multicast Routing Protocol들의 개념과 종류, 그리고 그들의 동작을 이해
한다.
멀티캐스팅 설정 및 활용:
IP Multicast Network 구성과 Multicast를 기반으로 하는 Multimedia
Application들을 구성하고 그들의 동작을 통해 실질적인 Multicast의 활용을
배운다.
2
IP Packet 전송 방식
10-3
이 장에서는 IP 패킷을 전송하는 세 가지 방식인 유니캐스팅, 멀티캐스팅, 브로드캐

스팅의 차이점과 멀티캐스팅의 장점에 대하여 설명한다.
3
유니캐스팅
송신자
비수신자
수신자 수신자 비수신자

수신자
유니캐스트를 이용하는 응용프로그램은 모든 클라이언트 유니캐스트 주소로 각각의 패킷들의 하나의

복사본을 각각 전송함
10-4
유니캐스팅은 일 대 일로 패킷을 전송한다. 유니캐스트를 이용하는 응용프로그램은 이 패킷을

받기를 원하는 모든 클라이언트들의 각각의 유니캐스트 주소로 패킷들의 복사본을 각각 따로
보낸다. 이 방식은 신뢰성 있는 전송을 필요로 하고 데이터 크기가 작고 인터액티브한 트랜잭
션 지향형 응용프로그램에 적합한 전송방식이다. 이런 이유로 대용량의 데이터를 동시에 여러
네트워크와 여러 클라이언트에 동시에 보내고자 할 때는 적합하지 못하다.
트래픽의 특성을 분석할 때는 클라이언트 측만 보지 말고 그 트래픽을 전송하는 서버에 미치
는 영향, 서버가 존재하는 네트워크에 미치는 영향, 전송을 담당하는 전체 네트워크에 미치는
영향, 데이터를 전송 받는 클라이언트 컴퓨터들에 미치는 영향과 같은 것들을 종합적으로 분
석해야 한다. 이러한 생각을 가지고 유니캐스트형 데이터 전송을 분석해 보자.
첫째는 서버측면을 우선 살펴보면 동일 데이터를 받기 원하는 모든 클라이언트 별로 보내고자

하는 데이터를 따로따로 복사본을 만들어야 하기 때문에 부하가 심하게 걸리게 된다. 또 서버
가 존재하는 네트워크 측면에서도 동일 데이터의 여러 복사본들이 전송되어야 함으로 트래픽
이 심하게 발생된다.
둘째는 전송할 네트워크 입장에서 살펴보면 대상 클라이언트가 존재하는 곳으로만 전송되기

때문에 트래픽이 확산되지 않는 측면은 바람직하다. 그러나 만약 같은 네트워크에 존재하는
여러 클라이언트 호스트들에게 동일 데이터를 보내야 할 때에는 여러 복사본이 따로따로 클라
이언트 호스트들에게 전달되어야 함으로 특정 네트워크로 전송되는 부분들에 대한 트래픽이
오히려 증가될 수 있다.
셋째는 클라이언트 입장에서는 오직 수신을 원하는 클라이언트만 받기 때문에 이러한 측면에

선 효율적이다라고 할 수 있다. 그러나 이런 동작이 TCP/IP IP 3-계층에 대응하는 개념으로서
설명한다면 맞는 말이지만 TCP/IP 2-계층과 관련한 실제적인 측면에서 꼭 그렇다고 말할 수
없다. 만약 2-계층 기술이 BMA(Broadcast-Based Multi Access) Ethernet기술을 사용하고 있고
허브를 통하여 여러 클라이언트들이 연결되어 있다면 비록 3-계층에서의 처리는 특정 호스트
에게만 전송되는 것을 기대하겠지만 2-계층에서의 처리는 기본적으로 허브의 모든 포트로
Flooding됨으로써 그 데이터를 받기를 원하는 않는 클라이언트 호스트까지 받게 될 것이다.
그렇기 때문에 완벽하게 유니캐스팅이 되었다고 말하기가 기술적으로는 곤란하다. 하지만
Ethernet 스위치를 사용하여 처리된다면 3-계층 유니캐스팅은 Unknown 상태가 아닌 이상 2-계
층에서도 클라이언트 호스트가 존재하는 포트로만 전달됨으로써 완벽하게 유니캐스팅이 구현
될 것이다.
결론적으로 유니캐스팅은 서버에게는 클라이언터 호스트의 접속 숫자만큼 부하를 주게된다.

네트워크측면에 끼치는 영향을 보면 트래픽이 전체적으로 확산이 되지 않는 측면은 효율적이
지만 특정 네트워크에 동일한 다수의 트래픽이 전송될 때는 특정 네트워크에 많은 부하를 발
생할 수도 있다. 클라이언트 측면에서 본다면 특정 호스트에게만 데이터가 전송되어 바람직하
지만 2-계층 하부 네트워크의 어떤 기술에 적용되었는가에 따라 달라질 수 있는 것 이다.
4
유니캐스트 트래픽 (계속)
송신자 2 Mb x 100 = 200 Mb
2 Mb x 100 = 200 Mb
2 Mb x 100 = 200 Mb
2 Mb x 100 = 200 Mb
수신자1 …. 수신자100
10-5
위의 경우는 최악의 상황을 고려한 것이다.

위의 슬라이드처럼 한 종단 네트워크에 100명의 사용자가 동시에 접속해서 2Mbps 속
도로 전송되는 데이터를 유니캐스트 방식으로 받는다고 했을 때 발생될 수 있는 상
황을 보면 심각하다.
일단 서버는 100명에게 동일 데이터를 개별적으로 보내기 위해서 2Mbps짜리 100개의
데이터를 복사본을 준비해야 할 것이다. 이렇게 되면 서버에 엄청난 부하가 있을 것
이다. 즉 2Mbps * 100 = 200Mbps의 대역폭으로 라우터에게 보내질 것이다. 이런 경
우 서버가 존재하는 네트워크가 FastEthernet나 Gigabit Ethernet에 전-이중 통신을
사용하여 전송한다면 전혀 문제될 것이 없다. 하지만 일반적으로 사용되고 있는
10Mbps Ethernet을 이용한 전송은 문제가 된다.
네트워크에 전송할 때 라우터와 라우터 사이가 WAN구간이라면 과연 200Mbps를 잘 전
달할 수 있을까? 그리고 슬라이드 예처럼 전체 네트워크로 분산되지 않고 특정한 네
트워크로만 집중적으로 전달된다면 과다한 트래픽들로 인해 특정 네트워크의 부하가
엄청나게 늘 것이다. 결론적으로 클라이언트 호스트들은 각각 2Mbps 데이터를 하나
만 받을 것이다.
5
브로드캐스팅
송신자
비수신자
나는 데이터를 받기를
원하지 않지만, 내
CPU는 계속해서
데이터를 처리해야
한다.

수신자
호스트 중 데이터를 받기 원치 않는 것들도 브로드캐스트 트래픽을 반드시 처리해야 함
10-6
브로드캐스트는 패킷을 불특정 다수에게 동시에 전달하기 위해서 사용한다. 주로 관리용 데

이터 전송이나 방송용 비디오 스트림을 전달하기 위해서 사용한다. 라우터와 스위치, WINS
서비스 등을 설명할 때 브로드캐스트는 모든 문제의 원천인 것처럼 이야기했었다. 그래서 독
자들은 브로드캐스트는 무조건 나쁜 것으로 인식하고 있지나 않는지 걱정된다. 문제가 있다
하더라도 상황에 따라 필요할 때는 이용해야 하는 것이다. 다만, 사용시 발생하는 문제점들
을 해결하기 위한 방안도 Broadcast Domain, VLAN(Virtual LAN), P-Node NetBIOS Name
Resolution같은 개념과 기술들을 통해 마련하면 되는 것이다.
첫째는 서버의 입장에서 보면 수 백 개의 호스트에 패킷을 전송할 지라도 오직 한 개의 패킷

만 전송하면 된다. 당연히 서버의 부하는 적을 것이다. 서버가 존재하는 네트워크에도 실제
하나의 패킷만 전달됨으로 네트워크 트래픽도 적다. 물론 서버가 존재하는 네트워크에 다른
서버들이 많이 존재한다면 해당 서버들도 원치 않는 데이터를 받아야 하는 것은 문제이다.
둘째는 전송하는 네트워크 측면에서 보면 개념적으로 비록 하나의 패킷이지만 전 네트워크로

확산이 될 것이다. 그러나 데이터를 받을 클라이언트들이 모여있는 네트워크로는 오직 하나
의 패킷만 전달되어 적은 트래픽이라고 할 수 있다. 즉 확산된다는 측면은 좋지 않지만 특정
한 네트워크로 전달되는 부하는 적다는 것이다.
셋째는 클라이언트 호스트들인데 위의 슬라이드처럼 하나의 트래픽이 모든 클라이언트 호스

트에게 전달되기 때문에 트래픽의 양 자체는 적지만 그 패킷이 전달되기 원하는 혹은 원치
않는 모든 클라이언트 호스트들에게 모두 전달될 것이다. 즉 원치 않는 클라이언트 호스트들
도 이 브로드캐스트 트래픽을 처리해야 함으로써 원치 않는 클라이언트들이 존재하는 네트워
크 대역폭과 CPU자원들을 소모하게 만든다. 이 부분이 직접적으로 브로드캐스트 관련 문제의
원천이 되는 중요한 부분이다.
개념적인 측면에서는 위와 같지만 실제적인 측면에서 브로드캐스트는 스위치의 VLAN, 라우터

의 Broadcast Domain(Bridge Group)등의 로컬 네트워크를 넘어 다른 네트워크로 전달되지 않
는다. 물론 Cisco사의 라우터의 경우 IP Helper-Address 명령을 사용하면 유니캐스트로 바꾸
어 보낼 수는 있다. 결과적으로 원래의 의도나 개념처럼 브로드캐스트를 이용해서 라우터나
스위치의 VLAN 밖으로 보내는 것은 현실적으로 불가능하다. 이런 이유 때문에 하나의 로칼
네트워크에 존재하는 거의 모든 호스트들이 브로드캐스트를 받아야 할 때 사용하는 것이 바
람직하다.
6
멀티캐스팅
• 2Mb
송신자
• 2Mb
비수신자
• 2Mb
• 2Mb
• 2Mb • 2Mb
• 2Mb
• 2Mb
• 2Mb

수신자
멀티캐스트 서버는 하나의 데이터 스트림을 여러 대의 클라이언트에게 동시에, 전달하기 위한
특별한 멀티캐스트주소를 이용함
10-7
멀티캐스트는 하나의 패킷을 특정 다수에게 동시에 전달하기 위해서 사용한다. 관리

용 트래픽이나 비디오 스트리밍 방송, 화상회의 등을 구현 시 주소 사용한다. 용도
는 브로드캐스트와 비슷하다. 그러나 차이점은 전달대상이 특정 다수라는 점이다.
정해진 호스트들 즉 특정한 멀티캐스트 주소에 등록된 호스트들에만 데이터가 전달
된다.
특징을 보면 아래와 같다.
첫째는 슬라이드에서 보면 서버는 브로드캐스트와 마찬가지로 여러 수신자들에게 패
킷을 보낼 지라도 오직 하나만 만들어서 보낸다. 그렇기 때문에 서버의 부하나 서버
가 속한 네트워크에 대한 부하는 적다.
둘째는 네트워크 측면에서는 브로드캐스트와 다르게 전체 네트워크로 확산되지 않고

클라이언트가 존재하는 네트워크로만 전송된다. 클라이언트가 한곳에 몰려있는 상황
이라 할 지라도 단 한 개의 패킷만 전송되기 때문에 네트워크 관련 트래픽이 적다.
셋째는 패킷을 수신하는 클라이언트 호스트들 측면에서 보면 받기를 원하는 클라이

언트에게만 패킷이 전달된다. 이것은 유니캐스트적인 특성이다. 결론적으로 멀티캐
스트는 유니캐스트의 장점과 브로드캐스트의 장점을 적절하게 혼합해서 가지고 있다.
그러나 용도는 브로드캐스트와 거의 같은 용도이다.
7
IP 멀티캐스트 특징들
하나의 호스트 그룹에 전송

“best effort” 전송, 완벽한 신뢰성은 보장 못함
동적인 멥버쉽을 지원
다양한 수와 위치를 지원
하나 이상의 그룹 멤버쉽도 가능
여러 개의 스트림 호스트 지원 가능
10-8
아래의 내용들은 IP 멀티캐스트의 특징들이다.

•하나의 호스트 그룹(Host Group)에 전송한다. 서버가 패킷을 전송할 때 특정한
Multicast Group Address를 목적지 주소로 사용하는데 이 주소로 전송되어 오는
데이터를 받기 원하는 여러 대의 클라이언트들이 자신이 이 Multicast Group
Address에 등록되어있으면 동시에 여러 대의 클라이언트 호스트들이 패킷을 받
을 수 있다.
•Best Effort” 전송을 한다. 멀티캐스트 패킷은 UDP over IP를 이용하여 전송
된다. IP의 특성은 Best Effort 이고 UDP는 TCP에 비하여 신뢰성있는 전송은 보
장gkwl 못한다는 의미이다. 신뢰성은 보장하지 못하지만 최대한 노력해서 패킷
을 전달하려고 한다.
•동적인 멥버쉽을 지원한다. 멀티캐스트 환경에서 서버가 패킷을 전송하기 위해
서 사용하는 목적지 주소는 Class D의 특정한 주소 하나를 사용한다. 클라이언
트들은 서버가 보내는 Class D의 특정한 주소를 미리 IP Address처럼 아답터에
지정하는 것이 아니라 서버로부터 멀티캐스트 형태로 들어오는 패킷을 처리할
수 있는 응용프로그램을 띄우는 순간 3-계층 목적지 멀티캐스트 주소를 아답터
용 2-계층 멀티캐스팅 MAC Address를 만들어 내서 자신과 라우터에게 등록하는
것이다. 해당 응용프로그램을 종료하면 자동적으로 그 등록된 주소를 자신과 라
우터에서 해제한다.
•다양한 수와 위치를 지원한다. 다양한 클라이언트에 동시에 데이터를 전송할
수 있고 그 클라이언트 호스트들은 다양한 네트워크에 존재할 수 있다. 다만
그 네트워크들이 멀티캐스트를 지원할 수 있도록 구축되어 있어야 한다.
•하나 이상의 그룹 멤버십 지정이 가능하다. 이것은 하나의 클라이언트 호스트
가 여러 개의 멀티캐스트 주소로 데이터를 받는 여러 개의 응용프로그램을 동시
에 띄어놓고 여러 개의 서버 호스트로부터 각각 다른 멀티캐스트 주소로 전송되
어 오는 데이터를 동시에 받을 수 있다는 의미이다.
• 여러 개의 스트림 호스트 지원이 가능하다. 이것은 하나의 서버 호스트가 여러
개의 다른 멀티캐스트 주소로 데이터를 전송할 수 있다는 의미이다.
8
정리
구분 전송 영향 MAC IP Address Switching Routing
서버 네트 클라
워크 이언
트
유니캐스트 1대1 Bad Good Good 1대1 Class A, B, C IP Static

(Bad) IGP:RIP,OSPF,
IGRP,
EIGRP,ISIS
EGP:BGP
멀티캐스트 1 대 특정 Good Normal Good 01.00.5E. Class D UDP over IP, Static
다수 (Good) Multicast IGMP, DM:DVMRP,M
Group CGMP OSPF,PIM-DM
Addr. SM:CBT,PIM-
SM
브로드캐스트 1대 불특 Good Bad Bad FF.FF.FF.F Directed IP Helper-
정 다수 (Good) F.FF.FF Network Address
All Network IP Directed-
broadcast
10-9
전송은 유니캐스트는 1대 1로 멀티캐스트는 1대 특정 다수 그리고 브로드캐스트는 1

대 불특정 다수에게 데이터를 전달한다.
이에 따른 영향은 서버, 네트워크, 클라이언트측면으로 나누어 진다. 서버는 서버와
서버가 속한 네트워크에 영향을 주는 것을 의미한다. 네트워크에 끼치는 영향은 확
산되는 범위와 트래픽 양이 “()”로 표현되고 있다. 클라이언트측면의 부하는 전달
되는 클라이언트 호스트의 숫자와 해당 클라이언트 호스트가 속한 네트워크에 따른
영향이다.
유니캐스트는 서버에 미치는 영향이 Bad로 좋지않다. 네트워크상에는 확산이 되지
않는 측면에서는 Good이지만 특정 네트워크로 같은 트래픽이 동시에 갈 때는 많은
대역폭을 소모하기 때문에 Bad이다. 클라이언트입장에서는 대상 호스트만 받기 때문
에 Good이다.
멀티캐스트는 서버에 미치는 영향은 아주 적어서 Good이다. 네트워크상에 미치는 영
향은 약간은 확산이 있기 때문에 Normal이다. 전송되는 패킷은 오직 하나만 가기 때
문에 이에 따른 상대적 트래픽양이 작아서 (Good)이다. 클라이언트측면도 대상 호스
트만 받기 때문에 Good이다.
브로드캐스트는 보낼 서버가 하나만 전송하면 되므로 Good이다. 네트워크 측면에서
는 전체 네트워크로 확산되기 때문에 Bad이다. 트래픽 처리량은 하나의 패킷만 전송
되면 되기 때문에 Good이다. 하지만 클라이언트 측면에서의 영향은 수신대상이 아닌
클라이언트도 그 패킷을 처리해야 함으로 Bad이다.
결과적으로 이를 비교해 보았을 때 전체적으로 멀티캐스트가 Good, Normal(Good),
Good으로 가장 우수한다.
9
멀티캐스팅 주소 체계
10-10
이 장에서는 3-계층 멀티캐스팅 주소와 2-계층 물리적인 주소간의 매핑이 어떻게 이

루어지는 지에 대하여 설명을 비롯한 멀티캐스트의 전체적인 주소표현 방식에 대해
서 설명한다.
10
멀티캐스트 IP Address
28 Bits
Class D 1 1 1 0 Multicast Group ID
Class D 주소는 첫 번째 Octet안에 High-Order Bit들이 1110으로 고정되고,

28-Bit Group 주소가 그 다음에 위치
Class D 주소의 범위는 224.0.0.0에서 239.255.255.255 이고, 첫 번째
Octet안에 High-Order Bit들이 이 224-Base Address를 구별
IANA로 부터 각 기업/단체에게 할당
배정방식은 Class단위가 아닌 단일 IP Address방식
Administrative Scoping이라는 사설 멀티캐스트 영역을 가지고 있음
239.0.0.0 에서 239.255.255.255
10-11
앞에서도 설명한 바와 같이 IP 멀티캐스팅을 하기 위한 주소는 Class D 주소를 사용

한다. Class D 주소는 첫 번째 Octet안에 High-Order Bit들이 1110으로 고정되고
28-Bit Multicast Group ID 주소가 그 다음에 위치한다. Class D 주소의 범위는
224.0.0.0에서 239.255.255.255까지 이다. 첫 번째 Octet안에 High-Order Bit들이
이 224-Base Address를 구별해 준다.
이 주소도 Class A, B, C와 마찬가지로 IANA (http://www.iana.org/)로 부 터 각 기
업이나 단체들이 할당 받아야 한다. 배정방식은 Class 단위가 아닌 단일 IP Address
방식이다. 어차피 IP 멀티캐스트 주소는 하나의 주소만 가지고 있어도 여러 개의 호
스트들에게 동시에 보낼 수 있기 때문이다. 이것은 일종의 TV나 라디오의 방송 채널
과 같은 것이다. 물론 기업이나 단체에 따라서 여러 개의 Class D IP Address를 받
기도 하는데 주소를 여러 개 가지고 있다면 방송용 채널이 여러 개 있는 것이나 마
찬가지이다. Class D IP 멀티캐스트 Address도 제한적인 자원이기 때문에 각 기업나
단체들은 지금 현재는 사용하지 않더라도 미래에 멀티캐스트로 인터넷 방송을 보내
기 위하여 꼭 등록해 확보해 두어야 한다.
Class A, B, C의 Private IP Address와 마찬가지로 Class D도 Administrative
Scoping이라는 사설 멀티캐스트 영역을 가지고 있다. 영역은 239.0.0.0에서
239.255.255.255이다. 기업이나 단체의 내부 네트워크에서만 화상회의나 인터넷 방
송을 멀티캐스트로 전송하기를 원하면 이 주소 영역을 사용할 수 있다.
참고로 Class D IP 멀티캐스트 주소는 종종 Multicast Group Address, Mulitcast
Group ID라고 불린다. 하나의 Class D IP Address가 여러 대의 호스트 그룹들에게
동시에 전달되기 때문에 붙여진 것이다. 같은 의미로 해석하기 바란다.
11
멀티캐스트 MAC Address
1 4 5 9 10 16 17 24 25 32
Class D IP Address 1110
224
MAC에서 멀티캐스트
사용되지 않는 Group ID의 Low-order 23 Bit들이 Ethernet
5 Bit들 MAC Address로 복사된다.
01 00 5E
00000001 00000000 01011110 0
48-Bit Ethernet Address
10-12
멀티캐스트용 2-계층 주소는 각각의 네트워크 기술마다 미리 정해져 있다. Ethernet,

Token-Ring, FDDI에서 사용하는 방법은 3-계층 멀티캐스트 IP Address의 일부 주소
를 Multicasting용 MAC Address로 지정한 주소의 뒤에 붙이는 방법을 사용하고 있다.
48 Bit인 Ethernet MAC Address는 01.00.5E를 멀티캐스트 MAC Address의 시작 부분
으로 예약해 두었다. 01.00.5E(16)를 2진수로 변화시켜 00000001. 00000000.
01011110.에 마지막 0을 한 비트 추가하여 앞부분 00000001. 00000000. 01011110.0
를 만들다. 3계층 Class D의 왼쪽에서 9번째 비트를 제외한 10번째부터 32비트를 그
대로 이 주소의 뒷 부분에 매핑하여 멀티캐스트용 Ethernet MAC Address를 생성해
낸다.
12
IP 멀티캐스트 주소를 Ethernet 주소로 매핑: 예 1
Multicast Address: 227 . 154 . 65 . 50
1 1 1 0 0 0 1 1 1 0 0 1 1 0 10 0 1 0 0 0 0 01 0 0 1 1 0 0 10
Ethernet Address:
01 - 00 - 5E - 1A - 41 - 32
00000001 00000000 01011110 00011010 01000001 00110010
10-13
위 그림은 227.154.65.50에 대한 MAC Address가 어떻게 생성되는지를 보여주고 있다.
13
IP 멀티캐스트 주소를 Ethernet 주소로 매핑: 예 2
Multicast Address: 227 . 26 . 65 . 50
1 1 1 0 0 0 1 1 0 0 0 1 1 0 10 0 1 0 0 0 0 01 0 0 1 1 0 0 10
Ethernet Address:
01 - 00 - 5E - 1A - 41 - 32
00000001 00000000 01011110 00011010 01000001 00110010
10-14
227.26.65.50의 Class D IP Multicast Address가 매핑된 Ethernet MAC Address가

227.26.65.50의 이진수 형태의 9번째 비트를 사용하지 않기 때문에
01.00.5E.1A.41.32 만들어져 227.154.65.50와 같아진 모양을 나타내고 있다.
이러한 상황이 큰 문제가 될까? 그렇지는 않다. 이유는 아래와 같다.
첫째는 227.26.65.50와 227.154.65.50처럼 MAC Address가 중복되는 Class D 멀티캐
스트 Address를 동시에 사용하거나 클라이언트 응용프로그램이 동시에 받을 확률이
일단 적기 때문이다.
둘째는 2-계층에서는 같은 주소가 되어서 아답터가 받아들여 처리하지만 어차피 3-
계층으로 전달되면서 목적지 Class D Multicast Address와 UDP Port#가 다를 것이기
때문이다.
셋째는 이 다음에 설명되겠지만 원래 Ethernet 스위치는 멀티캐스트를 브로드캐스트
와 동일하게 처리해도 문제가 없이 생각한다. 즉, Cisco의 CGMP와 같은 기능을 가지
고 있지 않는 Ethernet 스위치나 허브는 멀티캐스트 MAC Address를 가진 프레임이
들어오면 전 포트로 Flooding한다.
14
기타
멀티캐스트 Address는 자동 만들어 지므로 ARP를 수행하지 않음

마찬가지로 브로드캐스트 Address는 FFFF.FFFF.FFFF 로 정해져 있어
ARP가 필요 없음
Frame-Relay 멀티캐스트 DLCI 1019 에서 1022로 예약되어 있음
X.25, ATM, SMDS E.164 multicast Address Exxx.xxxx.xxxx 형태
로 지정해 줌
z Smds multicast ip E180.0999.0999
z Atm multicast Address
10-15
송신하는 장치가 수신하는 호스트에게 패킷을 보내기 위해서 목적지 멀티캐스트 IP

Address에 대응하는 멀티캐스트 주소를 자동으로 생성해 프레임의 목적지 MAC
Address로 지정이 가능하기 때문에 멀티캐스트에서는 ARP작업을 유니캐스팅처럼 수
행하지 않아도 된다. 마찬가지로 브로드캐스트 주소는 FFFF.FFFF.FFFF로 정해져 있
어 또한 ARP가 필요 없다.
자동적으로 생성되는 Ethernet, Token-Ring, FDDI의 MAC Address와 다르게 WAN기술
과 프로토콜들은 예약이 된 것이나 주소를 직접 지정할 수 있도록 하고 있다.
Frame-Relay의 경우는 멀티캐스트 DLCI 1019 to 1022로 예약되어 있다.
X.25, ATM, SMDS 등은 E.164 Multicast Address exxx.xxxx.xxxx 형태로 명령을 통하
여 지정해 준다.
Smds multicast ip e180.0999.0999
Atm multicast address
15
IGMP
(Internet Group Management Protocol)
10-16
이 장에서는 IP 멀티캐스팅에서 IGMP(Internet Group Management Protocol)의 역할

에 대해서 설명한다.
16
Internet Group Management Protocol (IGMP)
IGMP는 IP 멀티캐스팅이 가능한 네트워크에서 호스트가 자신이 받기를 또
는 반응하기를 원하는 Multicasting Group Address(Class D Multicast
Address)를 라우터에게 알리거나 해제하는 프로토콜
누가 Multicast
누가 Multicast
Group IP
Group IP
224.10.15.60
224.10.15.60
멤버?
멤버?
Host E
Internet 비-멤버
무-반응
멤버
반응
Host D
멤버
반응
Host A Host C
Host B
멤버 비-멤버
멤버
반응 무-반응
반응
10-17
IP 멀티캐스트와 관련한 세 가지 중요한 프로토콜이 있다. IGMP, CGMP, 멀티캐스팅

라우팅 프로토콜이 그것이다.
CGMP는 멀티캐스트가 가능한 스위치와 멀티캐스트가 가능한 라우터간에 통신하는 프
로토콜로 멀티캐스트가 가능한 호스트들이 IGMP를 통해 자신이 받기를 원하는 멀티
캐스트 그룹주소를 라우터에게 알렸을 때 그 주소로 등록된 호스트들의 MAC Address
를 멀티캐스트가 가능한 라우터가 스위치에게 알리는 프로토콜이다.
멀티캐스트 라우팅 프로토콜(Multicast Routing Protocol)은 호스트들이 알린 멀티
캐스트 그룹 주소를 이용해 멀티캐스트가 가능한 라우터와 라우터간에 멀티캐스트
전송 경로를 구성하기 위하여 통신하는 프로토콜이다.
IGMP는 멀티캐스트가 가능한 호스트와 멀티캐스트가 가능한 라우터간에 통신하는 프
로토콜로 주로 호스트가 멀티캐스트 그룹 주소를 라우터에게 등록하는 프로토콜이다.
멀티캐스트의 기능성을 발휘하기 위한 호스트용 프로토콜로 일반 호스트, 라우터,
스위치들에 탑재되어있는 프로토콜이다.
IGMP는 현재까지 Version 1에서 Version 3까지 적용되었으며, 현재 시장에서 가장
많이 적용되는 것은 Version1, 2 이다. 또한 IGMP V2의 기능들이 현재 IPv6에서 지
원하는 ICMPv6의 기본적인 기능으로 포함되어 있다.
17
IGMPv1-패킷 형식
4 7 15 23 31
Version Type Unused Checksum
Group Address
Version
IGMP의 Version 정보를 표시한다.
Type
Router들과 Host사이에서 사용되는 IGMP Message 종류
z Membership Query
z Membership Report
Checksum
IGMP Message의 이상 유무를 검사하는 용도로 사용된다.
Group Address:
z Multicast Group Address(ID)
10-18
위 그림은 IGMPv1 Packet의 format을 보여주고 있다.

IGMP는 IP Packet에 의해 전달되는 Message이며, 기본적인 TTL값은 ‘1’이다. 따라서
Router의 특정 Local Network에서만 적용되는 Message이다.
IGMPv1 Packet은 다음과 같은 Field로 구성된다.
• Version Field
IGMP의 Version을 기술한다.
• Type
Message Type을 정의한다. IGMP Version1에서는 Router와 Host사이에서 교환되는 두
가지 Type의 Message를 교환한다.
- Membership Query
- Membership Report
• Checksum
IGMP Message의 이상 유무를 검사할 수 있는 정보들이 기록된다.
• Group Address
Multicast Group Address가 정의된다.
이 정보는 주로 Membership Report가 전달될 때 기록된다.
18
IGMPv1: Query-Response Process
1
IGMPv1 224.0.0.1 IGMPv1
Querier Query Non-Querier
R1 R2
X
224.1.1.1 224.1.1.1 H2 224.2.2.2 H3

H1
Report Report Report
3 2 4
IGMP는 기본적으로 Query-Response Model을 이용하여 Router가

Multicast group의 Active 상황을 알게 한다.
10-19
IGMPv1은 Router와 Host사이에서 Query-Response Model을 이용하여 Multicast Group의 Active

상황을 판단한다.
위 그림에서 H1과 H2는 224.1.1.1의 Multicast Group에 조인하여 Multicast Traffic 수신을 원하
고 있고, H3은 224.2.2.2에 대한 Multicast Group에 조인하고 싶어한다. 또한 R1과 R2사이에서
R1이 IGMP Query-Response를 수행하는 IGMPv1 Querier 로 지정되어 있다.
IGMPv1 Query-Response Operation을 다음과 같은 작업들을 통해 수행된다.
1.IGMPv1 Querier로 동작하는 R1은 주기적(기본 60초)으로 Local Network의 모든 호스
트들(224.0.0.1)에게 IGMPv1 Membership Query를 전송하여 특정 Multicast Group에 관
심을 갖는 호스트들이 존재하는지를 검색한다.
2.R1이 전송하는 IGMPv1 Membership Query를 모든 Host들이 수신하고, 이중에 H2가
224.1.1.1의 Multicast Group에 대한 Member가 되기 위해 IGMPv1 Membership Report
를 Router에게 전달한다. R1은 이러한 Report를 수신하여 H2가 224.1.1.1의 Multicast
Traffic을 수신하길 원하는 것으로 판단한다.
3.H1은 H2가 224.1.1.1에 대해 IGMPv1 Membership Report를 R1에게 전달하는 것을 수
신하므로 자신이 R1에게 전달하려 했던 IGMPv1 Membership Report를 전달하지 않는
다. 이것은 이미 H2가 H1 자신이 수신하길 원하는 224.1.1.1에 대해 IGMPv1
Membership Report를 전달했으므로 중복된 IGMPv1 Membership Report를 전달하지
않아도 되기 때문이다. 이러한 동작은 Host들이 특정 multicast Group에 대한 IGMPv1
Membership Report 메시지를 각자 전달하면서 발생하는 부담을 최소화 시킨다.
4.H3은 R1이 전달하는 IGMPv1 Membership Query를 수신 후 자신은 224.2.2.2라는
Multicast Group에 관심을 가지고 있음을 IGMPv1 Membership Report로 R1에게 전달
하게 된다.
결론적으로 R1은 자신이 host들에게 전달한 IGMPv1 Membership Query를 통해 현재 Local
Network에는 224.1.1.1과 224.2.2.2의 Multicast Group에 대해 수신을 원하는 Host들이 있음을
인지하며, 이로 인해 R1은 해당 Multicast Traffic들을 Local Network에 전달하게 된다.
참고로 현재 R2는 Host들과 IGMP관련 정보들을 교환하지는 않지만 R1과 host들이 교환하는
모든 정보들을 수신하면서 전체적인 실행정보들을 R1과 동일하게 관리한다.
19
IGMPv1: Report Suppress

R1 R2
X
224.1.1.1 224.1.1.1 H2 224.2.2.2 H3

H1
Host들의 Report Suppress 동작은 과도한 Multicast Group membership Report 관련

Traffic이 발생하지 않도록 한다.
10-20
IGMP Report Suppression 동작은 Multicast Group의 상태 정보를 관리하는 IGMP Traffic을 최소
화 하는데 그 목적이 있다.
다음은 IGMP Report Suppression 동작의 과정을 설명한 것이다.
1.특정 호스트가 IGMP Membership Query를 수신하면, 호스트는 자신이 join하고 싶은 특
정 Multicast Group에 대한 IGMP Membership Report를 전달하기 전에 Report-timer라는
프로세스를 시작한다. Report-timer는 기본적으로 “ 0”에서 “10”(Maximum response
interval)사이의 숫자 중 하나를 임의로 선택하고, 선택된 수치를 기준으로 discount하기
시작한다.
예를 들어 위 그림에서 H1과 H2는 모두 224.1.1.1의 Group에 대해 join하길 원하고 있다.
H1과 H2는 224.1.1.1에 대한 IGMP Membership Report를 전달하기 전에 Report-timer를
실행한다.
2.만약 Report-timer가 만료되면, 호스트는 자신이 join하길 원하는 Multicast Group으로
IGMP Membership Report를 전달한다.
H1은 0~10중에 9를 선택하여 9Æ8Æ7………Æ2Æ1Æ0
H2는 0~10중에 3를 선택하여 3Æ2Æ1Æ0 Æ IGMP Membership Report
3.위 결과로 인해 먼저 Report-timer가 만료된 H2가 IGMP Membership Report를 Router에게
전달한다. H2가 IGMP Membership Report를 전달하는 것을 H1이 수신하게 되면 자신
의 Report-timer Process를 멈춘다.
결과적으로 동일한 Multicast Group에 참가하려는 호스트수가 많은 환경에서는 IGMP Report
와 관련된 Traffic이 증가되는 문제가 있으므로 하나의 호스트가 대표로 Multicast Group에
Report하기만 해도, Local Network에 Multicast Traffic이 전달되므로 다른 호스트들은 별도의
Report없이 자신이 원하는 Multicast Traffic을 수신만 하면 된다.
20
IGMPv1: DR 선출

R1 R2
X
224.1.1.1 224.1.1.1 H2 224.2.2.2 H3

H1
하나의 Subnet에 다수의 Multicast Router가 존재하는 경우 Multicast Group Membership

Query Traffic의 최소화를 위해 DR(Designated Router)를 선출한다.
10-21
동일한 Subnet에 다수의 Multicast Router가 존재하는 경우 IGMP Query메시지들의 증가로 인

한 Bandwidth 점유 문제가 발생할 수 있다. 이런 경우 같은 Subnet에 존재하는 Multicast Router
들은 IGMP Query를 책임져야 하는 대표 Router (Designated Router)를 선출하게 된다.
참고로 RFC1112에서는 IGMPv1에서 DR를 선출하기 위한 상세한 기술 사양을 정의하지 않았
다. 따라서 IGMPv1이 동작하는 환경에서 DR을 선출하는 경우에는 상위 Layer에서 동작하는
Multicast Routing Protocol (PIM, DVMRP..)들에 의해 DR이 선출된다.
이와 반대로 뒤에서 설명하는 IGMPv2에서는 DR이 선출되는 기술 사양이 내장되어 있다.
21
IGMPv1: Join Process
IGMPv1 IGMPv1
Querier Non-Querier
R1 R2
H2 224.3.3.3 H3
H1 Unsolicited
Report
Host들은 자신이 원하는 Group에 참여하기 위해 Router의 다음 Memebership Query를

기다리지 않고 자신이 원하는 Group에 대한 Join Message를 즉시 전달한다.
10-22
호스트들은 자신이 원하는 Multicast Group에 Join하는 시간을 절감하기 위해서 Router
가 전달하는 주기적인 Membership Query의 주기를 기다리지 않는다. 따라서 호스트들은
자신이 특정 Multicast Group에 Join 해야 하는 상황에서는 즉시 Unsolicited
Membership Report를 전달하여 multicast Group에 Join한다.
참고로 IGMP는 호스트들이 Router에게 Multicast Traffic에 대한 수신 여부를 결정하는

용도로만 사용하는 것이지, 실제 Multicast Traffic을 전달하는 서버들은 IGMP를 통해
Router에게 특별히 전달하는 메시지들은 없다. Multicast Traffic을 생성하는 실제 서
버들은 Multicast가 동작하는 Router에게 자신이 전달하려고 하는 Multicast Traffic을
전달만 하면 된다.
22
IGMPv1: Leave Process

R1 R2
H3은 224.3.3.3에서
조용히 탈퇴
H1 H2 H3
Multicast Group에 참여한 Host가 해당 Multicast Group에서 탈퇴하는 경우

IGMPv1에서는 특별한 탈퇴 동작을 수행하지 않는다.
10-23
IGMPv1에서는 호스트들이 참여했던 특정 Multicast Group에 대한 탈퇴를 알리고 처리하

는 기능(Membership Leave Message)이 제공되지 않는다.
따라서 위 그림처럼 이전에 224.3.3.3에 Join하였던 H3이 해당 Group에서 탈퇴하면, 이
러한 사실을 Router가 인지 할 수 있는 방법이 없게 된다.
이로 인해 Router는 H3이 Join했던 224.3.3.3의 Multicast Traffic을 지속적으로 Local
Network에 전달하게 될 것이다.
IGMPv1에서는 특정 Group에 등록했던 Host들의 탈퇴 여부를 확인하기 위해 주기적인
Membership Query를 전달하여, 특정 Group에 등록된 Host들이 Membership Query에 대한
Report로 반응하는지를 검사하여 Active Group의 상태 정보를 관리한다.
만약 특정 Group에 대한 Membership Query에 대해 아무런 응답이 없는 경우에는 관련된
Member들이 존재하지 않는 것으로 판단하여 해당 Group의 Multicast Traffic을 Local
Network으로 전달하지 않는다.
IGMPv1 Membership Query를 수행하는 Router들은 3번의 Query Interval동안 해당
Multicast Group애 대해 Report가 없는 경우 관련 Member들이 탈퇴 했음을 인지한다.
이로 인해 Multicast Group에 Join했던 호스트들의 탈퇴를 인지하는 시간이 180(60초 *
3)초의 시간이 소요된다.
23
IGMPv2-패킷 형식
7 15 31
Type Max. Resp. Time Checksum
Group Address
Multiple message 형태(Type)들

z0x11: Membership Query
z0x12: Version 1 Membership Report
z0x16: Version 2 Membership Report
z0x17: Leave Report
Max. Resp. Time
z 1/10 Sec (Default = 10 Sec) 단위로 대응하는 보고를 보내기 전까지의 최고시간
Group Address:
z Multicast Group Address(ID) (0.0.0.0 - General Querie)
10-24
IGMPv2는 이전 RFC1112(IGMPv1)를 Update한 RFC2236에 소개되었다.IGMPv2는 이전

IGMPv1의 Query-Response방식을 기반으로 다음과 같은 특징이 추가 되었다.
• Querier Election Process
• Maximum Response Time
• Group-Specific Query Message
• Leave Group Message
IGMPv2 Packet은 아래와 같은 내용들을 표현하고 있다.

Multiple Message Type들은 IGMP 패킷의 전송 목적을 나타낸다.
• 0x11: Membership Query - 라우터가 호스트에게 주로 보낸다. 멀티캐스트 데이
터를 받기를 원하는 클라이언트가 있는지(General Query), 특정한 Multicast
Group Address전송되는 데이터를 계속 받기를 원하는 호스트가 있는지
(Specific Query)등의 질의에 사용한다.
• 0x12: Version 1 Membership Report - 호스트가 라우터의 질의에 대하여 반응
하는 것인데 호스트가 Version 1으로 자신이 데이터를 받기를 원하는
Multicast Group Address를 보고하는 것이다.
• 0x16: Version 2 Membership Report - 호스트가 라우터의 질의에 대하여 반응
하는 것인데 호스트가 Version 2로 자신이 데이터를 받기를 원하는 Multicast
Group Address를 보고하는 것이다.
• 0x17: Leave Report - Version 2에만 있는 기능으로 호스트가 라우터에게 자신
이 등록한 멀티캐스팅 그룹 주소로 오는 데이터를 더 이상 받고 싶지 않다고
자신이 등록한 Multicast Group Address을 명시적으로 해지해 달라는 것이다.
• Max. Resp. Time: Multicast Group Address의 등록과 해지를 빠르게 수행하기
위해서 사용한다. 라우터가 질의를 호스트들에 보내고 그것에 대하여 일정한
시간 동안 응답이 없으면 관련된 Multicast Group Address를 빠르게 해지하기
위해서 사용한다. 1/10 Second 단위로 지정한다. Default = 10 Second 이다.
• Group Address: 호스트가 라우터에게 보고하거나 라우터가 호스트들에게 질의
할 때 사용하는 Multicast Group Address이다. 호스트가 라우터에게 등록할 때
는 자신이 원하는 데이터를 받기 위해 등록을 원하는 경우, 또는 해지를 원하
는 Multicast Group Address가 들어간다. 라우터가 General Query를 수행할 때
는 0.0.0.0이, Specific Query를 수행할 때는 특정한 Multicast Group Address
가 들어간다.
24
IGMPv2—Group에 조인(등록)
10.10.10.101 10.10.10.101 10.10.10.103
HostA HostB HostC

227.26.65.50
Report
To: 224.0.0.2
10.10.10.1
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
10-25
위 그림처럼 특정 호스트에서 멀티캐스트 데이터를 전송 받기 원하는 응용프로그램을

수행하면 그 응용프로그램을 가진 호스트는 IGMP를 통해 자신이 데이터를 수신해야
하는 227.26.65.50의 Multicast Group Address을 라우터에 알리어 등록한다. 그러면
라우터는 호스트가 요구하는 Multicast Group Address을 목적지로 하는 Packet이 수
신되면 호스트가 존재하는 인터페이스로 전달하게 될 것이다.
위의 슬라이드에서 HostA는 멀티캐스트 데이터를 수신해야 하는 응용프로그램을 수행
했고, 그 결과 IP Packet의 목적지 주소가 227.26.65.50으로 설정된 IP Packet을 수
신하길 원하고 있다.
HostA는 IGMP를 통해 Router에게 227.25.56.50의 Member로 Join하고 싶다는
Membership Report를 전달하게 되는데, 이때 사용하는 IGMP Packet의 목적지 주소는
224.0.0.2으로 설정하여 전달한다.
224.0.0.2는 멀티캐스트주소들 중에서 현 서브넷에 존재하는 멀티캐스팅이 가능한 모
든 라우터들을 나타내는 용도로 예약된 주소이다. 마찬가지로 라우터가 호스트들과
통신할 때 자주 사용하는 주소가 있는 데 224.0.0.1이다. 이것은 현 서브넷에 존재하
는 멀티캐스팅이 가능한 모든 호스트들을 나타낸다.
HostA 호스트가 등록한 결과를 라우터에서 “show ip igmp group”라는 명령으로 확
인하면 현재 Router에 등록된 Group 정보를 확인 할 수 있다.
25
IGMPv2—Group에 조인(계속)
10.10.10.101 10.10.10.101 10.10.10.103
HostA HostB HostC

227.26.65.50
Report
To: 224.0.0.2
10.10.10.101 E0
Router>show ip igmp Group

227.26.65.50 Ethernet0 6d17h 00:02:31 10.10.10.103
10-26
위의 슬라이드는 호스트 HostC가 새로 멀티캐스팅 응용프로그램을 시작하면서 현재

라우터가 227.26.65.50 Multicast Group Address를 가지고 있는 것과 상관없이
227.26.65.50 Multicast Group Address에 대한 등록 작업을 수행한다. 그래서 Last
Reporter가 HostC의 10.10.10.103으로 바뀐 모습을 나타내고 있다.
26
IGMPv2 — Group 유지
10.10.10.101 10.10.10.101 10.10.10.103
HostA HostB HostC

227.26.65.50
227.26.65.50
Report Suppressed
Query
To:224.0.0.1
Group:227.26.65.50
10.10.10.101
IGMPv2
라우터는 주기적으로 질의를 보냄
z Subnet당, Group당, 하나의 멥버만 보고

z 다른 멥버들은 보고 안함
10-27
등록된 Multicast Group Address를 가지고 있는 라우터들은 그 Multicast Group

Address들이 지속적으로 데이터를 받기를 원하는지(Group의 Active 상태)를 알기 위
해 주기적으로 Query Message를 보낸다. 이 Query message는 해당 Multicast Group
Address를 등록한 모든 호스트들이 듣게 된다.
질의(Query Message)에 대한 응답은 쓸모 없는 트래픽을 줄이기 위해서 서브넷 당,
그룹 당, 하나의 멤버만 보고한다. 어차피 라우터 입장에서는 특정 서브넷에 특정
Multicast Group Address에 Join되어 데이터를 수신해야 하는 호스트가 하나라도 있
다면 데이터를 지속적으로 전송해야 하기 때문이다.
IGMPv2의 Membership Query Message에 설정하는 Maximum Response Time Field에는
Membership Query(질의)에 대한 Response(응답) Time 값이 설정되어 있다. Host들은
이 값에 설정된 수치를 기반으로 Query애 대한 응답 시간을 임의로 설정하여
Discount한다.
예를 들어 Membership Query Message에 설정된 Maximum Response Time 값이 “9”로
설정되었다면, Host들은“0”에서 “9”까지의 숫자 중 하나를 Random하게 선택하여
IGMP Report-timer갓으로 사용한다.
27
IGMPv2—Group 탈퇴
10.10.10.101 10.10.10.101 10.10.10.103
HostA HostB HostC

227.26.65.50 227.26.65.50
3
1 Report to
Leave to
227.26.65.50
224.0.0.2
2 Group Specific
Query to 227.26.65.50
10.10.10.101
1 HostA Group를 떠나기 위한 Leave Message를 보냄

1.
2.
2 라우터는 Group Specific Query를 보냄
3.
3 현재의 남아있는 멤버 호스트가 보고를 하고, Group은 Active 상태로 남음
10-28
IGMPv2 멀티캐스트 응용프로그램이 종료되면 호스트는 IGMP를 이용해서 자신이

Join했던 Multicast Group Address로부터 탈퇴하겠다는 것을 라우터에 알려 더
이상 데이터를 보내지 않도록 조치한다.
1. HostA 자신이 등록한 Multicast Group Address에서 탈퇴하기 위해 Leave Message
Router에게 전송한다.
2. 라우터는 227.26.65.50에 대해 아직도 멤버쉽을 유지하고 싶은 호스트가 있 는지
Group Specific Query를 Host들에게 전달한다.
3. 위 그림에서 현재 HostC가 여전히 227.26.65.50로 들어오는 데이터를 받기를 요
구하고 있으므로, 즉, 멤버쉽을 계속 유지하고 싶다는 의미로 Report Message를
Router에게 전달한다. 227.26.65.50은 계속해서 Active 상태로 남고 라우터는
227.26.65.50로 목적지 주소로 들어오는 데이터를 Local Network으로 전송한다.
28
IGMPv2—마지막 멤버 탈퇴
10.10.10.101 10.10.10.101 10.10.10.103
HostA HostB HostC

227.26.65.50
Leave to
1 224.0.0.2
2 Group Specific
Query to 227.26.65.50
10.10.10.1
1• 마지막 호스트가 Group를 떠나기 위하여 Leave Message를 보냄

2
• 라우터는 Group Specific Query를 보내고 보고가 없으면 Group은 Time Out됨
10-29
227.26.65.50 Multicast Group Address에 속하는 마지막 호스트인 HostC가 응용프로

그램을 종료하면 호스트는 IGMP를 통해서 227.26.65.50 Multicast Group Address를
떠나기 위한 Leave 메세지를 보낸다.
라우터는 227.26.65.50에 대한 Group Specific Query를 보내고 보고가 없으면 는
IGMP Group Membership 테이블에서 리스트를 제거하고 해당하는 인터페이스로 더 이
상 멀티케스트 데이터를 전송하지 않는다.
29
IGMPv2—마지막 멤버 탈퇴(계속)
10.10.10.101 10.10.10.101 10.10.10.103
HostA HostB HostC
10.10.10.1
Router>sh ip igmp Group

HostC이 떠난 후 라우터의 IGMP 상태
10-30
위 그림은 호스트 HostCrk 마지막으로 227.26.65.50의 그룹 멤버를 떠나게 된 후 라

우터의 IGMP Group 테이블의 상태를 보여 주고 있다.
30
IGMPv2: DR 선출

R1 R2
H1 H2 H3
하나의 Subnet에 다수의 Multicast Router가 존재하는 경우 Multicast Group Membership

Query Traffic의 최소화를 위해 DR(Designated Router)를 선출한다.
10-31
동일한 Subnet에 다수의 Multicast Router가 존재하는 경우 IGMP Query메시지들의 증가

로 인한 Bandwidth 점유 문제가 발생할 수 있다. 이런 경우 같은 Subnet에 존재하는
Multicast Router들은 IGMP Query를 책임져야 하는 대표 Router (Designated Router)를
선출하게 된다.
IGMPv2에서는 다음과 같은 동작을 기반으로 DR을 선출한다.
• IGMPv2 Router가 부팅되고 나면 각 Router들은 IGMP Query Message를 모든
Multicast System Group(224.0.0.1)에 전송한다. 이때 사용되는 Packet의
Source Address는 Router자신의 Interface의 IP가 되고 목적지 주소는
224.0.0.1이 된다.
• IGMP Query Message를 수신한 Router들은 자신이 IGMP Query Message를 전파한
Interface의 IP Address와 현재 다른 Router에서 수신한 IGMP Query Message의
IP Packet의 Source Address를 비교하여, 가장 작은 값의 IP Address를 가진
Router가 DR이 된다.
• 선출된 DR은 Querier Router로 그 역할을 수행하고, Non-Querier로 설정된 다른
Router들은 Querier timer process를 수행한다. 이러한 timer는 Querier에서 전
송되는 Membership Query Message를 수신할 때 마다 Reset되며, 기본적으로 250
초의 interval값을 가지고 있다.
• 만약 Querier timer가 만료되면 IGMP Querier가 down되었다고 판단하여 IGMP DR
을 선출하는 작업을 수행한다.
31
IGMPv3—Query Message Format
0 7 15 31
Max. Resp.
Type=0x11 Checksum
code
Group address
QR
S QQIC Number of sources(N)
V
Source addreess[1]
Source addreess[2]
.
.
.
Source addreess[N]
Source Filtering이 가능하다.

즉 Receiver는 자신이 원하는 Source의 Multicast traffic만을 수용 할 수 있다.
10-32
위 그림은 IGMPv3의 Packet Format이다.
32
IGMPv3—Report Message Format
0 7 15 31 0 7 15 31
Aux. data
Type=0x22 Reserved Chesksum Record type # of sources (N)
length
Reserved # of group records (M) Group address
Group record (1) Source address (1)

Source address (2)
.
Group record (2)
.
.
.
Source address (N)
.
. Auxiliary data
Group record (M)
z INCLUDE mode: receiver announces membership and list of hosts from

which to receive traffic (Traffic을 수신해야 하는 host들)
z EXCLUDE mode: receiver announces membership and list of hosts from

which not to receive traffic (Traffic을 받지 말아야 하는 host들)
10-33
IGMPv3는 Group Record Field를 이용하여 자신이 수신하기를 원하는 다수의

Multicast Source중 하나를 선택할 수 있다.
33
IGMPv3: Join & Leaves
Source = 1.1.1.1 Source = 2.2.2.2

Group = 224.1.1.1 Group = 224.1.1.1
R1 R2
R3
IGMPv3
Host_A Join Æ 1.1.1.1 224.1.1.1
Leave Æ 2.2.2.2 224.1.1.1
224.1.1.1의 Member
10-34
위 그림은 같은 Multicast Group 224.1.1.1에 대한 Source(1.1.1.1, 2.2.2.2)가

하나 이상인 인 상황인 보여주고 있다.
IGMPv3를 사용하는 Receiver인 Host_A는 224.1.1.1의 Group에 대한 Source를
1.1.1.1로 선택하고 2.2.2.2의 Source에 대해서는 수신을 원치 않을 수 있다.
34
CGMP
(Cisco Group Management Protocol)
10-35
이 장에서는 IP 멀티캐스팅에서 CGMP(Cisco Group Management Protocol)의 역할에

대해서 설명한다.
35
2-계층의 멀티캐스트 처리
송신자
비수신자
나는 비디오 스트림
데이터를 받기를
원하지 않지만, 내
CPU는 계속해서
1.5MB 데이터를
처리해야 한다.

수신자
10-36
Ethernet 스위칭 기술 에서 Ethernet 스위치는 Unknown 유니캐스팅과 Unregistered

멀티캐스팅, 그리고 브로드캐스팅은 모든 포트로 Flooding하는 특성을 가지고 있다.
스위치의 특성상 유니캐스팅은 지정된 포트로만 Forwarding하고, 멀티캐스팅과 브로
드캐스팅은 모든 포트로 Flooding하는 것인데 이렇게 되면 멀티캐스팅과 브로드캐스
팅의 처리 방법에 차이가 없게 되며, 이런 이유로 2-계층 수준에서는 3-계층의 세
가지 통신 방법을 완벽하게 지원하지 못하는 것이 된다. 물론 통신만 가능하다면 어
떠한 방식을 사용해도 상관은 없겠지만 비효율적인 것임에는 틀림없음으로 무엇인가
해결책을 찾아야 할 필요가 있다.
스위치에서 멀티캐스트를 브로드캐스트와 같은 방식으로 처리하게 되면 비효율적이
기 때문에 Cisco사는 CGMP라는 프로토콜을 만들어서 2-계층에서도 완벽하게 3-계층
TCP/IP의 모든 전송 방식을 지원하여 멀티캐스트가 스위치의 전 포트로 Flooding되
는 문제를 해결하고 있다.
36
CGMP(Cisco Group Management Protocol)
e port
나 0000.0c12.3456는 in R
P Jo
멀티캐스트 Group IGM
234.10.8.5에 E0/26
조인하고 싶다. E0: 0000.0c12.7777
MAC Address table
E0/1 E0/2 E0/1: 0000.0c12.3456
E0/2: 0260.8c01.2222
E0/26:0000.0c12.7777
CGMP Address table
HostA: 0000.0c12.3456 HostB: 0260.8c01.2222
CGMP는 Cisco-developed protocol

CGMP는 Catalyst Switch들이 Cisco Router로 부터 멀티캐스트 Client들의 존재를
배우도록 해 줌
10-37
CGMP는 Cisco사의 전용 프로토콜로 다른 벤더들의 Ethernet 스위치와 라우터에서는 이와 비슷

한 기능이 제공 되는지를 살펴 봐야 한다. Cisco사의 라우터와 스위치는 이 프로토콜을 이용
해서 2-계층 환경에서도 멀티캐스팅 그룹에 등록된 호스트의 포트에만 데이터를 전달할 수 있
는 기능을 제공한다.
CGMP를 지원하는 스위치에 멀티캐스트 트래픽이 들어오면 Multicast Group Address에 등록한
호스트들이 연결된 포트에만 데이터를 Forwarding해야 하는데 그러기 위해서는 스위치가
Multicast Group Address에 참여하는 호스트들의 포트들을 알아야 한다.
스위치에서는 Multicast Group Address에 참여하는 호스트들을 알아내는 기본적인 두가지 방
법이 있다. 하나는 스위치 스스로가 자신의 포트에 들어오는 패킷을 모니터하여 스스로 감지
하는 방법이 있고, 다른 하나는 라우터가 IGMP를 통해 등록한 호스트들의 MAC Address를 스위
치에게 알려주는 방법이다.
하지만 첫번째 방법은 효율적이지 못하다. 이유는 Multicast Group에 등록하고 탈퇴하는 모든
모든 IGMP 패킷들을 계속해서 모니터링 해야 하기 때문에 스위치 성능을 저하 시킬 수 있기
때문이다. 또한 엄격하게 말하면 IGMP는 IP와 같은 3-계층이기 때문에 3-계층 스위치는 멀티
캐스트 모니터링이 가능하지만 2-계층 전용 스위치는 멀티캐스트 모니터링이 불가능하다. 결
국 두번째 방법처럼 Multicast Group에 연결하는 호스트들이 IGMP를 통해 라우터에게 자신의
정보들을 등록하고 다시 라우터가 그 정보들을 스위치에게 알려주면 되는 것이다. 이 기능을
수행하는 것이 바로 CGMP 프로토콜의 역할이다.
CGMP(Cisco Group Management Protocol)는 Cisco가 독자적으로 개발하여 Catalyst 스위치와
Cisco 라우터 제품들에 탑재한 프로토콜로 라우터는 자신에게 Multicast Group들을 등록한
IGMP 호스트들의 MAC Address와 Multicast Group Address를 스위치에게 알려주어 스위치로 하
여금 Multicast Group Address에 대응하는 호스트들이 어느 포트에 연결되어있는가를 알아내
게 하는 프로토콜이며 주로 라우터와 스위치간에 통신하는 프로토콜이다.
슬라이드를 보면 MAC Address 0000.0c12.3456를 가진 호스트가 “나 0000.0c12.3456는
Multicast Group 234.10.8.5에 조인하고 싶다.” 라는 IGMP Join Report 메시지를 라우터에게
보내게 된다. 라우터는 이를 전송한 호스트의 MAC Address 0000.0c12.3456와 Multicast Group
Address인 234.10.8.5와 이 정보가 전송 되어 온 포트를 기억할 것이다.
또한 스위치는 자신의 MAC Address 테이블에 이미 자신의 포트에 연결되어 있는 두 개의 호스
트와 라우터의 MAC Address가 어느 포트에 연결되어 있는 지를 알고 있다.
37
CGMP (계속)
장치 0000.0c12.3456
234.10.8.5 Group에 조인
Device
0000.0c12.3456 ddd
dd.d
를 Port 0/1를 통하여
1 00.0c essage
접근이 가능. 0 PM
멀티캐스팅 Forwarding Table에 CGM
234.10.8.5를 추가함 E0/26
E0: 0000.0c12.7777
MAC Address table
E0/1 E0/2 E0/1: 0000.0c12.3456
E0/2: 0260.8c01.2222
E0/26:0000.0c12.7777
CGMP Address table

E0/1: 0100.5E0A.0805
0000.0c12.3456
라우터가 멀티캐스팅 Data를 호스트들 에게 전송 시
Dest. MAC Src. MAC Src. IP Dest. IP DATA
0100.5E0A.0805 0000.0c12.7777 203.254.81.1 234.10.8.5 가나다라마바사아
10-38
라우터는 E0 포트로 “장치 0000.0c12.3456가 234.10.8.5 Group에 조인했다”라는

내용을 담고 있는 CGMP 메세지를 스위치에게 내보낸다. 이때 라우터는
0100.0cdd.dddd라는 목적지 주소를 가지고 있는 프레임을 스위치에게 보내게 되는데
0100.0cdd.dddd는 CGMP Well-known MAC Address이며 Cisco의 스위치들은 이 MAC
Address를 목적지 주소로 하는 프레임이 들어오면 CGMP 메시지임을 인식하게 된다.
이 주소는 CGMP를 전달하기 위한 용도로 사용하기 위해 Cisco사가 지정한 주소이다.
라우터로 부터 CGMP 메세지를 전달 받은 스위치는 CGMP 메시지에 포함된 호스트의
MAC Address와 Multicast group address 정보를 확인한다. 그리고 호스트의 MAC
Address를 스위치의 MAC Address 테이블에 의거하여 End Station 0000.0c12.3456은
자신의 Port 0/1에 연결되어 있음을 인지하고 멀티캐스팅 전달용 테이블인 CGMP
Address 테이블에 234.10.8.5에 대한 멀티캐스팅 MAC Address인 0100.5E0A.0805와
Ethernet 0/1 포트와 연결시켜 놓는다.
다음은 라우터가 멀티캐스팅 데이터를 호스트들에게 전송 할 때 사용하는 프레임 구

조이다. 만약 슬라이드의 아래의 그림과 같은 구조를 가진 프레임을 스위치가 받게
되면 우선 Destination MAC Address가 0100.5E0A.0805이므로 이 주소 앞 부분의
0100.5E를 통해서 이 프레임이 멀티캐스트 프레임이라는 것을 스위치가 감지한다.
이후 스위치는 MAC Address 테이블이 아닌 CGMP Address 테이블을 검색하여
0100.5E0A.0805라는 주소가 E0/1 포트에 연결되어 있음을 확인하고 오로지 E0/1 포
트로만 이 프레임을 Forwarding할 것이다. 이렇게 2-계층 멀티캐스팅 환경에서도
등록된 포트로만 데이터가 Forwarding됨으로써 스위치에서도 3-계층 전송방식을 완
벽하게 지원할 수 있게 된다.
만약 스위치가 수신한 어떤 멀티캐스트 프레임에 대하여 CGMP Address table에 해당

주소와 포트 정보가 없다면 그러한 프레임들은 스위치의 전 포트로 전달될 것이다.
이것은 우리가 알고 있는 Unregistered Multicast에 대한 일반적인 처리이다.
38
CGMP Table 예
Switch#show mac-address-table multicast
Vlan Mac Address Type Ports
----- ------------------- ------ -------
1 0100.5e00.0118 IGMP Fa0/17, Fa0/18
1 0100.5e00.0128 IGMP Fa0/18
1 0100.5e00.0129 IGMP Fa0/18
1 0100.5e7f.fffe IGMP Fa0/17, Fa0/18
10 0100.5e60.e0e0 IGMP Fa0/4
11 0100.5e6a.eaea IGMP Fa0/4
11 0100.5e7f.fffa IGMP Fa0/3, Fa0/4
21 0100.5e7f.fffa IGMP Fa0/7, Fa0/8
Switch#
10-39
슬라이드는 Layer-3 Class D Multicasting Address가 Layer-2 Ethernet

Multicasting MAC Address로 변경되고, IGMP를 통해 Group Member로 라우터에 등록
된 후 라우터가 다시 CGMP를 통해서 스위치에 알린 Layer-2 CGMP 테이블을 표시하고
있다.
MAC Address가 모두 0100.5e 로 시작하고 있다. 첫 번째 라인 0100.5e00.0118 MAC

Address로 등록한 호스트가 F10/17, Fa0/18에 존재한다고 표시하고 있다. 나중에 스
위치는 목적지 MAC Address가 0100.5e00.0118로 들어오는 프레임은 Fa0/17, Fa0/18
로만 전송할 것이다. 즉, Layer-2 수준에서 지정된 포트로만 프레임을 전송하는
Collision Domain이 나뉘어지는 것이다.
39
IGMP Snooping
Layer 2 스위치들에서 수행
Layer 3 IGMP join/leave 메시지 모니터링
multicast 테이블 유지 및 변경
스위치의 수행능력에 충격을 가할 수 있음
예)
z Switch(config)# ip igmp snooping vlan vlan-id mrouter learn
{cgmp | pim-dvmrp}
cgmp—CGMP 패킬들 모니터링. 이 방법은 제어용 트래픽을 줄이는데 유용
pim-dvmrp—IGMP 질의 나 PIM-DVMRP 패킷들을 모니터링, 기본설정임
z Switch# show ip igmp snooping Æ Multicast에 참여한 port 정보
확인 가능
10-40
여러 가지 측면에서 CGMP가 효율적인 프로토콜임에는 틀림이 없지만, 최대의 단점

에 Cisco사의 전용 프로토콜이라는 것이다. Layer-3 IP는 IETF에서 표준을 정하고,
Layer-2 Ethernet은 IEEE에 의하여 정해지고 있어 쉽게 CGMP와 같은 표준을 만들기
는 쉽지 않다.
CGMP와 다른 방법으로 IGMP Snooping이 있다. IGMP Snooping은 스위치가 호스트들이
IGMP를 통해서 라우터에 자신이 멀티캐스팅 데이터를 받기를 원하는 Class D 그룹
주소를 등록하는 것을 감시하여, 감시된 Group 주소를 MAC 주소로 전환해 해당 포트
에 직접 매칭하는 것이다.
이 방법을 이해하는 것은 별로 어렵지 않지만 수행할 때 몇 가지 문제가 있다. 첫째
는 IGMP는 Layer-3 프로토콜이다. 만약, 스위치가 오직 Layer-2기능만을 수행하고
있을 때 이 기능을 제공하기 위하여 기능을 추가해야 한다는 것이다.
둘째는 스위치가 포트에서 통신되는 모든 프레임이 IGMP인가를 조사해야 하는 문제
점이 있다. 이것을 스위치에 엄청난 CPU의 자원을 소모하게 될 것이다.
슬라이드의 아래의 예는 Cisco사의 3550 스위치에서 IGMP Snooping기능을 Enable하
는 명령을 나타내고 있다. Cisco사의 경우 순수 IGMP Snooping기능 외에 DVMRP와
CGMP까지 모니터링 하는 기능을 추가했다.
40
10-41
이 장에서는 Multicast Routing Protocol의 기본적인 개요와 특성들을 알아 보도록

하겠다.
41
목표: Shorted Path Distribution Tree 생성

IGP
zSource Distribution Tree
Root/Tree가 각 소스마다 존재
DVMRP, MOSPF, PIM-DM root 이 지점에서만
패킷 복제가
zShared Distribution Tree 일어남
하나의 Root/Tree를 공유
PIM-SM, CBT branch
EGP
z(DVMRP)
zMBGP(Multiprotocol BGP) leaf
zMSDP
나는 나는 나는
234.10.8.5 234.10.8.5 234.10.8.5
의 멤버 의 멤버 의 비멤버
10-42
멀티캐스팅 라우팅 프로토콜의 목적은 Distribution Tree(분산트리) 만드는 것이다.

분산 트리란 멀티캐스팅 데이터를 보내는 소스 호스트로부터 그 데이터를 수신하는
목적지 경로까지 Loop이 없는 최단 경로 정보이다.
분산트리를 구성할 때는 누가 Root가 되는가가 중요한데 Distribution Tree(분산 트
리)의 경우에는 소스에서 가장 가까운 라우터가 Root가 된다. OSPF의 SPF 알고리즘
에서는 라우터 자신이 Root이고, Ethernet Switched Network에서 Root Bridge에 해
당하는 스위치가 Root인 것과 비교해 볼만하다.
위 그림에서 보는 바와 같이 IGMP를 통해 특정한 Multicast Group에 등록한 목적지
클라이언트 호스트들과 멀티캐스트 데이터를 전송하는 소스 호스트간에 라우터들이
있다.
라우터들은 호스트들의 IGMP Join 등록을 받아서 멀티캐스트 데이터의 소스를 전송
하는 라우터를 Root로 하고, Multicast Traffic을 수신하길 원하는 라우터의 요청만
을 받아들여 트리를 작성하게 된다. 그러므로 데이터가 전송될 필요가 없는 네트워
크 경로는 트리에 정의되지 않기 때문에 불필요한 데이터 복제 및 전송이 발생하지
않는다.
멀티캐스팅 라우팅 프로토콜도 동작형태에 따라 크게 두 가지로 나뉘어 진다.
Source Distribution Tree와 Share Distribution Tree이다.
Source Distribution Tree는 Source Specific Tree, Source-Based Spanning Tree,
Dense Mode 멀티캐스팅 라우팅 프로토콜이라고 불리우기도 하는데 이름에서 의미하
듯이 데이터를 전송하는 소스가 중심이 되어 목적지까지의 최적경로를 만들어 낸다.
Share Distribution Tree는 Center Specific Tree, Root-Based Spanning Tree,
Sparse Mode이라고 불리우기도 하는데 이 모드에서는 모든 소스, 목적지 라우터들의
정보를 모으고 공유하는 중심적인 역할을 수행하는 라우터가 선발된다.
나중에 소스 호스트들은 이 중심 라우터까지 데이터를 전송하게 되며, 목적지 호스
트들 또한 이 중심 라우터에 가서 필요한 데이터를 받아오는 형식을 취하게 된다.
또한 멀티캐스팅 라우팅 프로토콜들은 유니캐스트 라우팅 프로토콜들이 만든 라우팅
테이블을 이용하여 Multicast Traffic의 Source의 최적 경로를 평가한다.
42
유니캐스트 라우팅 vs. 멀티캐스팅 라우팅 비교
Server B
Destination Source
Data 172.45.37.10
Address Address
172.13.107.5 172.45.37.10
Network
172.45.0.0
Network
172.13.0.0
- 관리측면
위치와 목적에 상관 없이 무조건 모든 경로를 생성하고 유지 한다.
라우팅 테이블이 커지면 유지보수에 부담이 커지고 속도 저하
-전송측면
특정 호스트로 도달 가능한 최적 경로를 찾으면 됨 – 간단하다.
Host A Host B
172.13.107.5 172.13.107.6
10-43
유니캐스팅 라우팅 프로토콜은 전송 측면에서 특정 Network으로 도달하기 위한 최

적 경로를 찾으면 되므로 멀티캐스팅 라우팅과 비교하여 상대적으로 간단하다. 하지
만 멀티캐스팅 라우팅 프로토콜의 경우에는 network상에 분산된 호스트들이 존재하
는 Group에 도달하기 위한 최적 경로를 판단해야 하므로 보다 복잡하다.
유니캐스트 라우팅 프로토콜은 호스트들의 위치와 목적에 상관없이 일단 라우팅 테

이블이 만들어지고 나면 네트워크의 변화가 없는 한 지속적으로 이를 유지한다. 또
한 한번 만들어진 라우팅 테이블의 경로들 중에 일부가 실제 패킷의 전달을 위해 자
주 사용 되지 않는 경로라 할지라도 항상 라우팅 테이블에서 관리되어 진다. 장점은
라우팅 테이블에 항상 존재하는 경로 정보 때문에 데이터 전달 요청에는 빠르게 반
응할 수 있다는 것이다.
하지만 유니캐스트 라우팅은 언젠가는 해당 경로가 사용할 수 있다는 가능성 때문에
지속적으로 경로 정보를 유지해야 함으로 라우팅 정보의 유지보수에 소모되는 자원
의 낭비가 심하다. 그리고 경우에 따라서는 많은 라우팅 테이블을 가지고 있어야 하
기 때문에 라우팅 테이블을 검색하기 위한 시간 소요가 많아져 패킷 전달 속도의 저
하가 전체 네트워크에 존재하는 모든 라우터에서 발생 할 수 있다.
결론적으로 Unicast Routing은 Network상에 존재하는 모든 고정된 목적지에 대해 최
적 경로 정보들을 생성하고 유지하는데 목적을 둔다.
43
멀티캐스트 라우팅 vs. 유니캐스팅 라우팅 비교
Dest. IP Dest. MAC
234.10.8.5을 위한 Multimedia Stream 234.10.8.5 01-00-5e-10-8-5
Network
172.6.0.0
Network Network
172.13.0.0 172.45.0.0
Host B
172.45.37.10
Host A
234.10.8.5
172.13.107.5
234.10.8.5
- 관리측면
위치와 목적을 두고 경로를 생성하고 유지 한다.
네트워크의 링크들의 상황에 따라 경로 정보가 변경되지 않고, Multicast Group의 상태가
변경될 때 경로 정보가 바뀐다.
-전송측면
Multicast Group의 상태에 따라 전송 경로가 결정되므로 복잡하다.
10-44
멀티캐스팅 라우팅 프로토콜은 멀티캐스트 데이터 패킷을 보내는 소스 호스트로부터

그 데이터를 받는 목적지 호스트(Group)까지의 경로를 만들기 위한 다양한 기능들을
제공한다.
유니캐스팅 라우팅에 비해 멀티캐스팅 라우팅은 위치와 목적 정보를 기반으로 경로

정보들이 만들어 진다. 또한 멀티캐스트 라우팅 경로는 미리 만들어 지는 것이 아니
라 서버나 클라이언트 호스트가 멀티캐스트 데이터를 주고 받기 위한 IGMP Report가
있을 때 만들어 지며, 이후 모든 서버나 클라이언트 호스트가 멀티캐스트 데이터를
주고 받는 프로그램을 종료하면 자동적으로 멀티캐스팅 라우팅 경로는 제거된다. 즉
멀티캐스트 라우팅 정보는 필요에 의해 생성되고 제거되는 방식을 택하고 있다.
물론 이러한 특징은 테이터의 전달 요구가 있을 때 즉시 반응하지 못한다는 문제가

있기는 하지만 불필요한 라우팅 목록을 가지고 있지 않으므로 관리되는 라우팅 목록
의 수가 적다. 때문에 유니캐스팅처럼 라우팅 테이블의 크기 증가로 인한 성능 저하
문제나 많은 라우팅 정보를 유지하기 위한 관리상의 부하도 적다.
또한 멀티캐스트 라우팅 테이블의 갱신은 네트워크의 변화로 이루어지는 것이 아니
라 서버나 클라이언트 호스트가 멀티캐스팅 응용프로그램을 시작하고 종료할 때
IGMP에 의한 등록과 탈퇴 요구에 의해서 이뤄진다.
결론적으로 Multicast Routing은 Network상에 존재하는 Multicast Source들에 대한

최적 경로를 선택하고, 유동적으로 변화하는 수신자들의 경로 정보들을 유지하고 관
리하는데 그 목적이 있다.
44
Distribution Tree란?
Source1
224.1.1.1 traffic Source2

224.2.2.2 traffic
Receiver Receiver
224.1.1.1 224.1.1.1
224.2.2.2
- Loop이 없는 tree를 만들어 client가 있는 곳에만 traffic 전달

- RPF(Reverse Path Forwarding) 검사를 이용하여 Source traffic의 최단 경로 검증
10-45
멀티캐스팅 라우팅 프로토콜의 최종적인 목표는 멀티캐스팅 스트림을 보내는 소스로

부터 이것을 받는 여러 목적지 호스트까지의 Loop이 생기지 않는 최단 경로의 트리를
만들어 내는 것이다. RIP의 Split-horizon, Poison, Poison Reverse등의 Loop방지 메
커니즘, OSPF의 SPF알고리즘, Ethernet Switch의 Spanning Tree 알고리즘, BGP의 AS-
Path와 거의 같은 기능이고 말만 바꾼 것이다.
Loop이 생기지 않는 최단 경로를 찾기 위해서 멀티캐스팅 라우팅 프로토콜들은 기본적
으로 RPF(Reverse Path Forwarding)을 사용한다. 이 방법은 유니캐스팅 라우팅 프로토
콜에 의존하기 때문에 기본적으로 멀티캐스팅 라우팅이 되기 위해서는 필수적으로 유
니캐스팅 라우팅이 되어야 한다.
45
Multicast Routing의 Source, Root, Receiver
Server
192.168.1.1/24 (S, G)
목적지: S = Source
Server
224.5.5.5 G = Group
목적지:
224.5.5.5
R1 R2 R3
192.168.1.1/24 T1 T1 T3
R4 T1 R5 R6 R7
Host 1 Host 2 Host 3 Host 4

224.5.5.5 224.5.5.5 224.5.5.5 Non-Receiver
10-46
Multicast환경에서 Source란 Multicast Traffic을 전달하는 Server Host들, 더 정확

하게 표현한다면 Multicast Packet의 Source IP Address를 의미한다고 이해해도 된
다.
예를 들어 위 그림에서 R4는 224.5.5.5를 목적지로 하는 Multicast Traffic을 수신
하는 경로가 R1과 R5가 있는데, 이중 자신과 가장 근접한 곳에 위치한 R1으로부터
Multicast Traffic을 전달받을 것이다. 이는 R4입장에서 Unicast Routing Table을
참조하면 192.168.1.0/24로 도달하기 위한 최적의 경로가 R1을 경유하는 경로이므로
R4는 224.5.5.5를 대상으로 하는 Multicast Traffic의 수신 최적 경로를 R1으로 선
택하기 때문이다.
결론적으로 R4입장에서 보면 “224.5.5.5를 위한 Multicast 경로의 Root가 R1이
다.”라고 표현할 수 있는 것이다. 이처럼 Multicast Traffic의 수신을 위한 최적
경로를 판단하는 것이 Multicast Routing Protocol의 목적이며, 이는 최적 경로를
관리하는 Unicast Routing Protocol의 도움 없이는 가능하지 않을 것이다.
Receiver들은 자신이 수신하길 원하는 특정 Multicast Group에 Join하는 Host들을

의미한다. 만약 위 그림의 R7처럼 Multicast Traffic을 수신하는 Host이 없는
Router가 있다면, R7은 자신에게 Multicast Traffic을 전달하는 R3에게 자신은
224.5.5.5에 대해 등록된 host들이 없으므로 Multicast Traffic을 전달하지 말 것을
요청하게 된다.
R5는 224.5.5.5를 대상으로 하는 Multicast Traffic을 R1과 R2에서 수신한다. 이때

R5는 224.5.5.5를 대상으로 하는 Multicast Traffic의 Source인 192.168.1.1/24에
대한 최적 경로인 R2를 Root로 선택하고, R1에게는 224.5.5.5를 대상으로 하는
Multicast Traffic을 전달하지 말 것을 요청하게 된다. 하지만 차후에 R2가 Fail되
면 R5는 R1에서 224.5.5.5를 대상으로 하는 Multicast Traffic을 수신하게 된다.
Multicast Router들은 이처럼 Multicast Traffic이 전달되어야 하는 목적지와
Multicast Traffic이 수신되는 Source의 최적 경로를 선택하여 Distribution Tree라
는 경로 정보를 생성하게 된다. Multicast Routing에서는 목적지 경로(Client)들은
유동적이지만, Source (Server)의 경로는 유동적이지 않음을 생각해야한다.
46
Loop 검출
Reverse Path Forwarding (RPF): 멀티캐스팅 패킷을 하나의 인터
페이스로 받았을 때, 만약 그 인터페이스가 멀티캐스팅 소스로의 유니
캐스팅 IP 패킷을 보내는 사용이 되는 것이라면 그것을 받아들인다.
RPF X
RPF RPF
Multicast X
Source
10-47
Reverse Path Forwarding (RPF)란 멀티캐스팅 패킷을 하나의 인터페이스로 받았을

때, 만약 그 인터페이스가 멀티캐스팅 소스로의 유니캐스팅 IP 패킷을 보내는 최단
경로가 아니라면 이것을 Loop이거나 중복된 패킷이 들어온 것라고 판대해서 그것을
폐기하고, 다른 라우터에도 전달하지 않는 방법이다. 당연히 최적의 경로라면 다음
라우터들에게 전달할 것이다.
47
RPF 검사
소스 151.10.3.21 부터 온
멀티캐스팅 패킷
Unicast Route Table

Network Interface X
151.10.0.0/16 S1 패킷이 잘못된 인터페이
S0
198.14.32.0/24 S0 스에 도착!
204.1.16.0/24 E0 패킷을 폐기함.
S1 S2
E0 RPF 검사 실패!
소스 151.10.3.21 로 부터
유니캐스팅 Route Table 온 멀티캐스팅 패킷
Network Interface
패킷이 올바란 인터페이
151.10.0.0/16 S1
스에서 도착!
198.14.32.0/24 S0 S0
204.1.16.0/24 E0 다른 인터페이스로 전달
S1 S2
E0
RPF 검사 성공!
10-48
슬라이드의 위쪽 그림에서 소스 151.10.2.21을 소스로 가진 멀티캐스트 스트림이 라우터의 S0

로 들어왔다. 여기서 중요한 것은 멀티캐스트 주소를 검사하는 것이 아니라는 점이다. 들어온
151.10.2.21을 가지고 자신의 유니캐스팅 라우팅 테이블을 확인한다. 그런데, 이 라우터의 경
우 목적지가 151.10.0.0/16 네트워크의 경우 자신의 S1으로 패킷을 전달하도록 라우팅 테이블
이 설정된 것이다. 라우터 자신은 그 소스로 가기 위해서는 S1으로 가는데, 왜 그 소스에서 이
라우터에게 데이터를 보낸 때는 S1을 사용하지 않는가라는 개념이다. 즉, S0는 중복된 패킷이
거나 Loop이 생긴 것이다. 이 패킷을 폐기되고 다른 라우터에게도 전달되지 않는다.
아래쪽 그림은 소스 151.10.3.21로 부터 들어온 패킷이 S1으로 들어왔고, 라우팅 테이블도 그
네트워크로 가기 위해서 S1을 사용하므로 이것은 최적의 경로를 타고 들어온 패킷이라고 판단
해서 들어온 인터페이스를 제외한 나머지 인터페이스로 전달한다.
모든 라우터에서 이러한 방식을 통해서 불필요한 인터페이스를 제거하면, 멀티캐스팅 스트림을
보낸 소스로 부터 목적지까지 Loop이 생기지 않는 분산트리가 생성되는 것이다.
48
RPF Check 예
GWWEST#mtrace 192.168.15.1
Type escape sequence to abort.
Mtrace from 192.168.15.1 to 192.168.25.2 via RPF
From source (?) to destination (?)
Querying full reverse path...
0 192.168.25.2
-1 192.168.25.2 PIM [192.168.15.1/32]
-2 192.168.25.5 PIM [192.168.15.1/32]
-3 192.168.15.1
GWWEST#show ip rpf 192.168.15.1

RPF information for ? (192.168.15.1)
RPF interface: Serial0/0
RPF neighbor: ? (192.168.25.5)
RPF route/mask: 192.168.15.1/32
RPF type: unicast (eigrp 1)
RPF recursion count: 0
Doing distance-preferred lookups across tables
GWWEST#
10-49
슬라이드는 멀티캐스팅이 enable된 네트워크에서 관리자가 문제가 있을 시 RPF가

정상적으로 수행되는지를 알아보기 위한 두 가지 명령어 mtrace와 show ip rfp 명령의
결과를 보여주고 있다. 이 명령을 수행 시에 에러가 발생하면 안된다.
49
Source Distribution Tree
(S, G)
S = Source
Server
목적지: G = Group
234.10.18.5
Host 1 Host 2 Host 3 Host 4

234.10.18.5 234.10.18.5 234.10.18.5
Source-Specific Tree들은 송신자에서 수신자사이의 최단 경로를 구성

만약 로칼 라우터와 인접 라우터 사이의 링크가 최단경로가 아니거나 중복된 경로면,
패킷을 그 링크로 전달하지 않음
10-50
Source Distribution Tree는 Multicast Traffic을 생성하여 전달하는 Source Tree와

Multicast Traffic을 수신 받아야 하는 Branch로 나눌 수 있고, 이들은 Spanning
Tree에 의해 Root와 Branch로 구성된다. ( Shortest path tree라고 한다. )
Multicast Routing을 수행하는 Router들은 Multicast Traffic의 경로 정보를 관리하
기 위해 아래와 같은 (S, G)형식의 정보를 사용한다.
S = Multicast Traffic의 Source IP
G = Multicast Group
Source Tree를 관리하는 모든 Router들은 Network상에 존재하는 Multicast Source와
Branch tree 정보를 유지하고 관리한다. 설사 Router 자신이 Multicast Traffic 수
신을 원하는 수신자들이 없다 하더라도 Multicast Source와 Group정보를 관리한다.
Source-Specific Tree라고도 불리는 Source Distribution Tree들은 송신자에서 수신

자 사이에 만들어진 최단 경로를 멀티캐스팅 데이터 전달용으로 사용한다. 소스에
따라 여러 개의 트리가 만들어 짐으로 소스의 증가로 인해 라우터 자원에 대한 소비
가 많아진다.
Source Distribution Tree는 RPF(Reverse Path Forwarding)이라는 프로토콜에 의하
여 만들어 진다. RPF는 만약 패킷이 라우터에게 전달되면 라우터는 그 패킷이 들어
온 방향을 소스 중에 하나의 최단 경로를 판단되면 라우터는 소스가 들어온 인터페
이스를 제외한 나머지 모든 인터페이스로 그 패킷을 밀어낸다. 이때 소스로부터 최
단 경로에 해당하는 인터페이스를 Parent Link라고 부르고 라우터가 패킷을 전달하
는 나가는 쪽 인터페이스를 Child Link라고 부른다.
만약 로컬 라우터와 인접 라우터 사이의 링크가 최단경로가 아니거나 중복된 경로이
면 패킷을 그 링크로 전달하지 않는다. 위의 슬라이드를 예로 들면, Host 3으로 전
송되는 경로는 A-B-F-G를 이용할 도 있고, A-E-F-G를 이용할 수도 있지만 최단 경로
가 아니기 때문에 A-F-G 경로가 선택된다. 또한 똑 같은 데이터를 E가 F에게 보내고
F는 E에게 보내게 되는데 이 경로는 중복된 경로로 판단되어 데이터를 전송하지 않
게 된다.
50
Source Distribution Tree Example
(172.16.1.1, 234.10.18.5)
(172.16.1.1, 234.10.18.5) Incomming: S0
Incomming: E0 Outgoing: S1(Stop)
Outgoing: S0(Stop),S1(Stop),E1(Forward)
S0 R2 S1
T1 T3
Prun
목적지:
234.10.18.5 S0 S0
E1 E1
E0 R3 R4 E0
S1 S1
172.16.1.1/24 T1 Group Join
T1
234.10.18.5
Prun
S0 S1
(172.16.1.1, 234.10.18.5)
R1
Incomming: E1
Outgoing: E0
(172.16.1.1, 234.10.18.5)
Incomming: S0
Outgoing: S1(Stop)
10-51
위 그림은 Source Distribution Tree를 사용하는 환경에서 각 Router들이 Multicast

경로 정보를 어떻게 인지하고 있는지를 보여주고 있다.
Source Tree를 관리하는 Router들은 일반적으로 모든 Router들이 Multicast Traffic
을 수신할 것이라는 가정하에 동작하는 방식이므로, 각 Router들은 Multicast
Traffic이 수신되는 최적 경로를 계산하고, 그것에 대한 정보들을 각자 관리해야 한
다.
51
Shared Distribution Tree
Root for All

Source
Source1 Source2
224.1.1.1 traffic 224.2.2.2 traffic
Receiver Receiver
224.1.1.1 224.1.1.1
224.2.2.2
-Multicast 데이터를 보내는 모든 Source 하나의 Root를 공유(share)

-Center Specific Tree, Root-Based Spanning Tree, Sparse Mode
-종류: PIM sparse-Mode, CBT(Core Based Tree)
-용도
-설정이 복잡함
-대역폭이 부족한 WAN환경에서 사용
-소스와 목적지가 분산되어 있을 때 사용
10-52
각 Router들이 자신들만의 Source를 갖는 달리 Multicast Routing을 수행하는

Router들이 하나의 Root를 공유하는 방식을 사용한다. Shared Distribution Tree을
사용하는 환경에서는 공유되는 Root를 Rendezvous point(RP), Core라는 불리운다.
Shared Distribution Tree를 사용하는 환경에서는 Multicast Source는 반드시 Root
역할을 수행하는 Router에게 먼저 전달되어야 한다. 그러면 Receiver를 소유한
Router들은 Root역할을 수행하는 Router에 join하여 자신들이 필요한 Multicast
Traffic을 수신하게 된다.
Shared Distribution Tree는 분배 센터라고 하는 것을 사용하고 오직 하나의 멀티캐

스트 트리를 사용한다. 그렇기 때문에 부하는 적지만 약간의 End-to-End Delay가 발
생할 수 있다.
Source Distribution Tree는 각각의 (Source, Group)에 대하여 Shortest Path Tree
를 여러 개 만들기 때문에 트리가 여러 개 생기는 것에 비하여 Shared Distribution
Tree는 모든 멤버들에 의하여 공유되는 하나의 Source Delivery Tree를 만든다.
Shared Distribution Tree는 Common(Mono) Spanning Tree와 매우 비슷하고, Source
Distribution Tree는 Per-VLAN Spanning Tree와 아주 비슷하다.
장치들 중에 특정한 멀티캐스트 그룹 주소로부터 트래픽을 보내거나 받기를 원하는
경우에는 반드시 명시적으로 Shared Distribution Tree에 조인해야 하고 보내는 소
스나 받는 목적지 장치들이 같은 데이터를 전송할 때도 같은 트리를 이용한다.
52
Shared Distribution Tree Example
(*, 234.10.18.5)
Incomming: S0
Outgoing: null
(172.16.1.1, 234.10.18.5)
Incomming: E0 RP or Core (172.16.1.1, 234.10.18.5)
Outgoing: S0(Forward) Incomming: S0
Outgoing: S1
S0 R2 S1
T1 T3
목적지:
234.10.18.5 S0 S0
E1 E1
E0 R3 R4 E0
S1 S1
172.16.1.1/24 T1 Group Join
T1
234.10.18.5
S0 S1 (*, 234.10.18.5)
R1 Incomming: S0
Outgoing: null
(172.16.1.1, 234.10.18.5)
Incomming: S0
Outgoing: E0
10-53
Shared Distribution Tree를 관리하는 환경에서는 기본적으로 모든 Router들이

Multicast Traffic 수신을 원하는 것은 아니라, 실제로 Multicast Traffic 수신을
원하는 Router들만이 RP에 Join하여 Multicast Traffic을 수신하는 환경이다.
위 그림에서 현재 Multicast Traffic에 대해 수신을 요구하는 Router들과 관련 경로
경로 상에서만 Multicast Routing Table이 생성된다.
53
WE RUN TO IMPROVE YOUR VALUES.
10-54
54

Multicast Basics

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Multicast Basics

Uploaded by

Copyright:

Available Formats

Multicast Routing Basics

이 장에서는 IP Multicast의 기본적인 개념과 관련 Protocol들에 대해 배울 것이다.

이 장에서 배우는 내용들은 다음과 같다.

IGMP(Internet Group Management Protocol):

CGMP(Cisco Group Management Protocol):

멀티캐스팅 라우팅 프로토콜:

이 장에서는 IP 패킷을 전송하는 세 가지 방식인 유니캐스팅, 멀티캐스팅, 브로드캐

수신자 수신자 비수신자

유니캐스트를 이용하는 응용프로그램은 모든 클라이언트 유니캐스트 주소로 각각의 패킷들의 하나의

유니캐스팅은 일 대 일로 패킷을 전송한다. 유니캐스트를 이용하는 응용프로그램은 이 패킷을

첫째는 서버측면을 우선 살펴보면 동일 데이터를 받기 원하는 모든 클라이언트 별로 보내고자

둘째는 전송할 네트워크 입장에서 살펴보면 대상 클라이언트가 존재하는 곳으로만 전송되기

셋째는 클라이언트 입장에서는 오직 수신을 원하는 클라이언트만 받기 때문에 이러한 측면에

결론적으로 유니캐스팅은 서버에게는 클라이언터 호스트의 접속 숫자만큼 부하를 주게된다.

송신자 2 Mb x 100 = 200 Mb

위의 경우는 최악의 상황을 고려한 것이다.

수신자 수신자 비수신자

호스트 중 데이터를 받기 원치 않는 것들도 브로드캐스트 트래픽을 반드시 처리해야 함

브로드캐스트는 패킷을 불특정 다수에게 동시에 전달하기 위해서 사용한다. 주로 관리용 데

첫째는 서버의 입장에서 보면 수 백 개의 호스트에 패킷을 전송할 지라도 오직 한 개의 패킷

둘째는 전송하는 네트워크 측면에서 보면 개념적으로 비록 하나의 패킷이지만 전 네트워크로

셋째는 클라이언트 호스트들인데 위의 슬라이드처럼 하나의 트래픽이 모든 클라이언트 호스

개념적인 측면에서는 위와 같지만 실제적인 측면에서 브로드캐스트는 스위치의 VLAN, 라우터

수신자 수신자 비수신자

멀티캐스트는 하나의 패킷을 특정 다수에게 동시에 전달하기 위해서 사용한다. 관리

둘째는 네트워크 측면에서는 브로드캐스트와 다르게 전체 네트워크로 확산되지 않고

셋째는 패킷을 수신하는 클라이언트 호스트들 측면에서 보면 받기를 원하는 클라이

 하나의 호스트 그룹에 전송

아래의 내용들은 IP 멀티캐스트의 특징들이다.

구분 전송 영향 MAC IP Address Switching Routing

유니캐스트 1대1 Bad Good Good 1대1 Class A, B, C IP Static

전송은 유니캐스트는 1대 1로 멀티캐스트는 1대 특정 다수 그리고 브로드캐스트는 1

이 장에서는 3-계층 멀티캐스팅 주소와 2-계층 물리적인 주소간의 매핑이 어떻게 이

Class D 1 1 1 0 Multicast Group ID

 Class D 주소는 첫 번째 Octet안에 High-Order Bit들이 1110으로 고정되고,

앞에서도 설명한 바와 같이 IP 멀티캐스팅을 하기 위한 주소는 Class D 주소를 사용

Class D IP Address 1110

00000001 00000000 01011110 0

48-Bit Ethernet Address

멀티캐스트용 2-계층 주소는 각각의 네트워크 기술마다 미리 정해져 있다. Ethernet,

Multicast Address: 227 . 154 . 65 . 50

00000001 00000000 01011110 00011010 01000001 00110010

위 그림은 227.154.65.50에 대한 MAC Address가 어떻게 생성되는지를 보여주고 있다.

Multicast Address: 227 . 26 . 65 . 50

00000001 00000000 01011110 00011010 01000001 00110010

227.26.65.50의 Class D IP Multicast Address가 매핑된 Ethernet MAC Address가

 멀티캐스트 Address는 자동 만들어 지므로 ARP를 수행하지 않음

송신하는 장치가 수신하는 호스트에게 패킷을 보내기 위해서 목적지 멀티캐스트 IP

이 장에서는 IP 멀티캐스팅에서 IGMP(Internet Group Management Protocol)의 역할

IP 멀티캐스트와 관련한 세 가지 중요한 프로토콜이 있다. IGMP, CGMP, 멀티캐스팅

Version Type Unused Checksum

위 그림은 IGMPv1 Packet의 format을 보여주고 있다.

224.1.1.1 224.1.1.1 H2 224.2.2.2 H3

IGMP는 기본적으로 Query-Response Model을 이용하여 Router가

IGMPv1은 Router와 Host사이에서 Query-Response Model을 이용하여 Multicast Group의 Active

IGMPv1 224.0.0.1 IGMPv1

224.1.1.1 224.1.1.1 H2 224.2.2.2 H3

Host들의 Report Suppress 동작은 과도한 Multicast Group membership Report 관련

IGMPv1 224.0.0.1 IGMPv1

224.1.1.1 224.1.1.1 H2 224.2.2.2 H3

하나의 Subnet에 다수의 Multicast Router가 존재하는 경우 Multicast Group Membership

동일한 Subnet에 다수의 Multicast Router가 존재하는 경우 IGMP Query메시지들의 증가로 인

Host들은 자신이 원하는 Group에 참여하기 위해 Router의 다음 Memebership Query를

참고로 IGMP는 호스트들이 Router에게 Multicast Traffic에 대한 수신 여부를 결정하는

IGMP(Internet Group Management Protocol):

CGMP(Cisco Group Management Protocol):

멀티캐스팅 라우팅 프로토콜:

유니캐스트를 이용하는 응용프로그램은 모든 클라이언트 유니캐스트 주소로 각각의 패킷들의 하나의

호스트 중 데이터를 받기 원치 않는 것들도 브로드캐스트 트래픽을 반드시 처리해야 함

하나의 호스트 그룹에 전송

Class D 주소는 첫 번째 Octet안에 High-Order Bit들이 1110으로 고정되고,

멀티캐스트 Address는 자동 만들어 지므로 ARP를 수행하지 않음

Multiple message 형태(Type)들

라우터는 주기적으로 질의를 보냄

CGMP는 Cisco-developed protocol

목표: Shorted Path Distribution Tree 생성