IP MultiCast 일반

Contents

1. 2003/12/10 : multicast 주소영역 관련 내용 추가 - [yundream]
2. 2010/7/13 : 내용 좀 수정

인터네트 환경이 눈부시게 발전했지만 인터네트를 가로지르는 데이터양은 이에 초과해서 늘어나고 있다. 요즘 대두되고 있는 원격 회상 회의, 원격 교육, 인터넷 대화형 TV등의 서비스는 엄청난 양의 데이터 교환이 필요하며, 인터네트 망의 한계 때문에 특별한 경우를 제외하고 원할한 서비스가 사실상 불가능하다. 혹은 서비스질이 크게 떨어지거나 상당한 비용을 지불해야 한다.

단순하게 생각하면 돈을 투자해서 네트워크 망 환경을 크게 개선시키면 되긴 하겠지만 엄청난 비용과 시간이 필요한 작업이다. 그렇다면 이러한 망 환경의 개선과 더불어 소프트웨어적인 다른 방법을 동원해서 문제를 해결하는게 더 좋은 방법일 것이이번에는 소프트웨어적인 문제 해결방법중 하나인 멀티캐스팅에 대해서 알아보도록 하겠다.

캐스팅은 "던진다"라는 뜻을 가진다. 여기에서는 정보를 전달하는 행위를 의미한다. 이 캐스팅에는 다양한 방식이 존재한다. TV나 라디오와 같이 모든 임의의 대상에 정보를 전달하는 방식이 있는가 하면, 전화와 같이 특정 상대와 1:1로 정보를 주고 받는 방식이 있다. 또한 두개 방식을 함께 사용하는 정보 전달 방식도 있다. 지휘소로 부터 1:1로 명령을 받은 다음 하위 부대에 방송하는 방식도 있다.

네트워크도 데이터를 전송하는 세가지 캐스팅 기법이 있다. 이 캐스팅 기법은 위에서 설명한 방식과 거의 동일하다. 아래 컴퓨터 네트워크에서 사용하는 캐스트의 종류를 보여주고 있다.

WAN과 LAN상에서 이루어지는 가장 일반적인 방식으로 서버와 클라이언트가 1대 1로 연결되고 데이터를 주고 받는다. 만약 하나의 서버에 100개의 클라이언트가 연결한다면 100개의 연결이 만들어 지고 서버는 동일한 데이터를 100개 복사해서 각각의 클라이언트에게 전송하게 될 것이다. 이 방식은 구현이 간단하고 웹과 같이 각 클라이언트로 다른 데이터를 보내야 하는 분야에서는 쓸만하지만 동일한 데이터를 다수의 유저에게 전달시켜야 하는 실시간 멀티미디어 서비스에는 그리 적합하지 않다. 대량의 동일한 데이터가 유저 수만큼 복사되기 때문이다.

소켓을 통한 일반적은 네트워크 프로그램은 유니캐스트 방식으로 작동한다.

브로드캐스팅(boradcasting)는 보내고자 하는 정보를 모든 수신자에게 보내는 방식으로, 서브네트워크에서 하나의 호스트가 데이터를 보내면 서브네트워크의 모든 호스트로 데이터가 전송된다. 데이터를 받을지 아니면 무시할지는 순전히 받는 측에서 결정하게 된다.

브로드 캐스팅은 주로 서브 네트워크 환경에서 주변의 호스트 정보를 알아오기 위한 데이터 교환용으로 널리 사용된다. 가장 대표적인 브로드 캐스팅 데이터는 arp(:12)데이터가 될것이다. 스위칭 라우터를 예로 들어서 생각해보도록 하자. 스위칭 라우터는 외부에서 들어온 데이터를 서브네트워크의 적당한 호스트로 보내야 할것이다. 이러한 작업을 위해서 보통 IP를 사용하는데, IP는 논리적인 값으로써 변경될 수 있는 값이므로 IP만 가지고 원하는 호스트와 통신하는건 적절하지 못하다. 이러한 문제를 해결하기 위해서 이더넷카드의 물리적인 번호와 IP번호를 맵핑시키는 방법을 사용하게 된다. 이더넷카드는 전 세계에서 유일한 48bit의 고유번호를 가지고 있으며 이 정보와 IP주소를 맵핑 시킴으로써 주변의 호스트 정보를 알 수 있게 된다. 라우터는 처음 부팅시 주변 호스트의 물리적 주소와 IP주소를 알아내야 하는데 이때 사용되는 프로토콜이 arp이며, 모든 주변 호스트에 대한 정보를 알아야 되므로 arp 요청을 브로드 캐스팅 하게 된다.

이는 라우터에만 적용되는게 아닌 서브네트워크의 단일 호스트에도 적용된다. 호스트가 새로 부팅 되었을 경우 이 호스트는 주변 호스트에 대한 아무런 정보도 가지고 있지 않는다. 이 호스트의 주소가 192.168.0.25인데, 192.168.0.26로 데이터를 전송할 일이 생겼다고 가정해 보자. 이 호스트는 192.168.0.26호스트가 어디에 있는지 알지 못한다. 이를 위해서 arp 패킷을 브로드 캐스팅 형식으로 서브네트워크에 있는 모든 호스트에게 보내게 된다. 패킷의 내용은 이를 테면 "192.168.0.26 주소를 가지는 호스트는 MAC주소와 함께 응답을 달라"이다. 일치하는 주소의 호스트는 MAC 정보를 채워 넣어서 192.168.0.25로 패킷을 보내게 된다.

이 처럼 브로드 캐스팅이 유용하게 사용되는 영역도 있긴 하지만 동일한 데이터가 모든 서브 네트워크로 전송된다는 특징 때문에 네트워크에 과도한 부하를 주는 경우가 발생하기도 한다. 때문에 대부분의 라우터들은 브로드캐스팅을 허용하지 않는다. 서브네트워크에서 제한된 용도로만 사용할 수 있다.

유니캐스트방식은 사용하기 쉽지만 동일한 데이터를 연결갯수 만큼 서버에서 복사해야 한다는 단점이 있다. 100k로 압축된 영상 데이터를 전송한다고 가정해보자. 1000명의 유저가 들을 경우 무려 100M의 데이터를 서버에서 복사해야 한다. 멀티캐스트 방식의 경우에는 데이터 복사가 서버가 아닌 라우터에서 발생하므로 서버의 부하는 없을 것이다. 그러나 데이터를 모든 컴퓨터로 방송하므로 데이터 낭비가 생긴다. 200개의 컴퓨터로 이루어진 서브네트워크가 있다고 가정해 보자. 이중 IPTV방송을 시청하고픈 컴퓨터는 단지 10대이다. 브로드캐스팅을 하게 되면, 200개의 컴퓨터 모두에 데이터가 전달된다.

유니캐스팅과 멀티캐스팅의 차이 멀티캐스트 데이터는 라우터와 라우터 사이에는 유니캐스트 방식으로 데이터가 전달되며, 서브 네트워크에서는 멀티캐스트 채널에 참여한 컴퓨터에만 데이터가 전달된다. 200대의 컴퓨터로 이루어진 서브네트워크에서 10대의 컴퓨터가 멀니태스트 채널에 가입해 있다면, 해당 컴퓨터로만 데이터가 복사되어서 전달이 된다. 효율적으로 네트워크 자원을 사용함을 알 수 있다.

멀티캐스트은 일반적으로 UDP를 사용한다. 정해진 채널에 데이터를 일괄적으로 전송하는 것이기 때문에, TCP의 특성이 데이터 재 전송등의 기능이 필요없다. TCP를 사용한다면, 채널에 전송한 데이터의 흐름을 관리해야 할 건데, 이렇게 되면 데이터 전송이 지나치게 복잡해질 것이기 때문이다. UDP만을 사용할 수 있다는 것은 아니다. TCP도 사용할 수 있기는 하다. 하지만 멀티캐스트로 전송되는 데이터의 특성을 감안할 때, 굳이 TCP를 사용해야 할 경우는 그다지 많지 않을 것 같다.

다음은 지금 까지 다루었던 3가지의 캐스팅 방법을 비교한 그림이다.

그럼 멀티캐스팅에 대해서 좀더 자세히 알아보도록 하겠다.

인터넷 프로토콜(IP)상에서 어떻게 멀티 캐스팅이 이루어질 수 있는가 ?

우리는 IP프로토콜이 관리등의 이유로 여러개의 클래스(class)로 나뉘어서 관리되고 있다는 것을 알고 있다. subnetworking을 참고하하라. 참고기사를 보면 단지 A, B, C 3개의 클래스만을 생각하고 있으나 이 외에도 D클래스가 사용되고 있다. 위 문서에서는 주제를 설명하는데 있어서 D클래스가 필요 없기 때문에 제외한 것 뿐이다.

D클래스는 224.0.0.1 에서 239.255.255.254의 범위를 가지며, 멀티캐스팅을 위해서는 이들 주소범위에 있는 주소가 할당되어 있어야 한다. 네트워크 호스트 그룹에 데이터를 전송한다는 멀티캐스팅의 특징으로 보통 라우터에 멀티캐스팅 주소가 할당이 된다.

이렇게 해서 라우터까지 데이터가 도달했다면 라우터는 자신이 관리하는 여러 호스트중 데이터 수신을 원하는 호스트에만 데이터를 전송해야 할 것이다. 어떤 방식으로 원하는 호스트에게만 찝어서 데이터를 보낼 수 있는지 알아 보도록 하자.

이러한 멀티캐스팅 데이터의 수신을 위해서 IGMP프로토콜을 사용한다. IGMP는 Internet Group Management Protocol의 줄임말로 인터네트 그룹 관리 규약이라고 불리운다. IGMP패킷은 다음과 같은 형식으로 전달된다.

요청 타입 설명

Type	설명
1	Create Group Request
2	Create Group Reply
3	Join Group Request
4	Join Group Reply
5	Leave Group Request
6	Leave Group Reply
7	Confirm Group Request
8	Confirm Group Reply

Create Group Request를 이용하면 멀티캐스팅 그룹생성을 요청할수 있는데, 그룹을 생성시킬 때 Code값을 명시함으로써 Public 혹은 Private로 그룹의 성격을 결정할 수 있다.

Code 설명

Code	설명
0	Public
1	Private

호스트가 Create Group Request를 이용해서 그룹의 생성을 요청하면 요청을 받은 호스트나 라우터는 다음과 같은 응답을 보내게 된다.

응답의 종류

Code	설명
0	Request Granted
1	Request denied, no resources
2	Request denied, invalid code
3	Request denied, invalid group address
4	Request denied, invalid access key
5 - 255	Request pending

IGMP checksum은 IGMP헤더에 포함된 메시지를 체크하기 위해서 사용되는 값이다. IGMP메시지를 받은 측에서는 checksum값과 IGMP헤더의 메시지와 비교하는 방식으로 잡음등으로 인한 패킷손실이 있었는지를 검사하게 된다.

Identifier은 현재 사용되어지지 않고 있으며, 0으로 채워져 있다.

Group Address는 IGMP헤더의 실질적인 핵심으로 라우터와 호스트들은 이 그룹주소에 자신이 받기를 원하는 멀티캐스팅데이터의 주소를 명시해서 라우터에게 전송함으로써 라우터에게 "나는 이 멀티캐스팅 그룹에 join되어 있음"을 알려주게 된다. 예를 들어 225.100.1.5에서 멀티캐스팅 데이터가 225.100.1.6으로 전송된다고 가정해 보자. 225.100.1.6에 있는 호스트들이 이 데이터를 라우터로 부터 받기 위해서는 IGMP패킷에 그룹주소를 225.100.1.5를 명시해서 라우터에 보내면 된다. 그러면 라우터는 멀티캐스팅 라우팅 테이블을 검사해서 어느 호스트로 데이터를 보내야 하는지 알 수 있게 된다.

참고로 IGMP는 ICMP와 같은 레벨의 프로토콜(인터넷 프로토콜)로 IP+IGMP의 형태로 교환된다. 그러므로 라우터는 들어온 멀티캐스팅 데이터를 어느 호스트 IP로 보내야 할지를 결정할 수 있게 된다. 멀티캐스팅 라우터 테이블은 대충 아래와 같은 정보를 가지고 있다. {{{ 192.168.1.50 225.100.1.5 192.168.1.51 225.100.1.5 192.168.1.52 225.100.1.5 192.168.1.85 225.100.2.5 }}} 멀티캐스팅 라우터 테이블이 위와 같다고 할때 225.100.1.5에서의 멀티캐스팅 데이터는 50, 51, 52로 전송되고 225.100.2.5에서의 멀티캐스팅 데이터는 85로 전송될 것이다.

이상으로 멀티 캐스팅에 대한 개략적인 내용들에 대해서 알아보았다. 그렇다면 실제 인터넷 환경에서 멀티캐스팅이 효과적으로 이루어질 수 있는지 만약 그렇지 못하다면 다른 대안들이 있는지에 대해서 알아보도록 하자.

안타깝게도 인터넷상에서 멀티캐스팅 서비스를 하는건 그리 쉬운문제가 아니다. 이 문제에 관해서 irc의 joinc채널에서 [minzkn]님과 [산하]님과의 토론이 있었다.

토론의 결과 인터넷(WAN)환경에서의 멀티캐스팅의 전격적인 적용은 (아직 까지는)사실상 어렵다는 결론에 도달했다. 이유는 경로배정을 위한 라우터의 경우 멀티캐스트 IP를 라우팅 할 수 있어야 하는데, 현재 인터넷 상에는 멀티캐스팅 기능을 가지지 않은 장비가 상당히 존재하기 때문이며, 이 장비들을 모두 교체한다는 것이 사실상 불가능 하기 때문이다.

또하나 그게 가능한 환경이라고 할 지라도..안되는(어려운) 이유는 멀티캐스팅이 가져올 수 있는 불확실한 네트웍부하때문이다. 멀티캐스팅 IP를 가진 많은 인터넷 방송데이터들이 엄청나게 ISP의 라우터와 스위치로유입될것은 물론이거니와... 자칫 잘못하면.. 갈곳없는 데이터들이 스위치나 네트웍속을 떠돌아다닐 가능성이 존재한다. 결론은 멀티캐스팅은 공중파수준의 인터넷방송을 가능하게 할 수 있는 꿈의 기술인것은 사실이나 이것이 현실화되기위해선 전 라우터의 멀티캐스팅지원과 보다 더 우수하고 내부 대역폭이 더 큰 기가빗스위치들이 갖춰줘야 하며 ISP간의 연동망 및 백본망, 가정의 인터넷대역폭 등이 충분히 갖춰져야 하며-가정의 대역폭은 충분하다고 볼수 있겠군요- 멀티캐스팅 프로그램들이 어떤 문제를 야기시키지 않도록 잘 만들어져야만 한다는것이다-혹은 그런것을 처리해낼수 있는 라우터 내지는 스위치들이 갖춰진다면... 분명코 언젠가는 그런 환경이 될것이다... 대략 한 5년...정도 ?

사실, 월드컵 경기전에 국내의 유수 ISP 들이 모여 많은 회의를 하였었다. 월드컵 전 경기를 인터넷으로 멀티캐스팅 방송을 할것인가? 말것이가? 과연, 상업적 수익모델이 있나없나..결론은, 엄청난 돈을 들여서 국내의 모든 라우터를 멀티캐스팅이 가능한것으로-두루넷은 제가 알기로 원래부터 모든 라우터가 멀티캐스팅 가능했던걸로...- 교체한다 해봤자 그만한 수익도 없을것 같고 월드컵 이후에 그 장비들을 활용한 계속적인 컨텐츠가 없다란 결론에 도달하고 결국 포기했다. 아무리 꿈의 서비스라 할지라도 기업입장에서는 이윤을 창출 시켜야 하는데 아직은 시기상조 였던 것이다.

그렇지는 않다. 일단 무선환경에서의 경우 멀티 캐스팅은 필수고(무선의 특성상 원래 멀티캐스팅이 가능한 브로드캐스팅이므로), 특정한 환경(학교/연구소/회사)등에서의 화상회의와 같은 경우에 유용하게 쓰일 수 있을 것이기 때문이다.

멀티캐스팅이 관심의 대상이 되는 주된이유는,, 인터넷의 수익모델중 가장 크게 기대되는것이 바로 멀티미디어이기때문이다.. 현재 가장 비싼 광고료가 책정되는곳이 어디인가. 바로 TV이다..그만큼 동영상매체가 주는 파급효과는 큰것이다. 인터넷광고는 노출빈도수대 호감도가 반비례한다는 연구결과도 있을정도로 관심잇는 분야가 아니면 전혀 관심을 끌지 못하는것이 현재의 배너광고이다. 때문에, 이메일광고 휴대폰광고, 팝업창, 초기화면 등 여러가지 수익모델을 창출해내기 위한 인터넷기업들의 노력이 거세지고 있는 판국이다... 이러한 시점에서 공중파같은 고해상도에 버퍼링없는 인터넷방송이 가능하다면, 그것은 제 2의 TV시대가 열리는것이라고 볼 수 있겠다..

그리고 인터넷 멀티 캐스팅을 현재 인터넷 전체에 전격적으로 적용할 수 없지만 회사, 연구소, 학교등과 같은 영역에서는 충분히 멀티 캐스팅을 응용할 수 있다. 또한 다음장에 소개할 MBone와 같은 프로젝트를 이용하는등 기존에 구축되어 있는 인터넷 망을 활용하는 방법들도 존재한다.

멀티캐스팅 기술이 매우 훌륭한 기술이긴 하지만 현재 인터네트 환경에 적용하기에는 무리가 따른다. 그래서 생각한 것이 멀티캐스팅 전용망인 MBone망의 구축이다.

MBone(IP Multicast Backbone on ther Internet)은 Multicast Backbone의 줄임말로 IP 멀티캐스트가 가능한 네트워크들을 상호연결한 광역 네트워크 망이다. 위에서 설명했다시피 인터넷의 모든 백본 라우터들이 IP 멀티캐스트를 지원하는게 아니므로 전체 네트워크 상에서 멀티캐스트를 지원하는건 당분간 힘든일다.

MBone은 멀티캐스팅 기능을 지원하는 백본 라우터들만을 연결해서 광역 네트워크를 가로지르는 네트워크 터널을 만드는 프로젝트이다. 아래 그림은 MBone를 통해서 만들어지는 네트워크 터널에 대한 구조를 나타내고 있다. MBone은 인터넷을 가로지리는 가상 네트워크 계층(layer)이라고 볼수 있다. 네트워크 망에 대한 별도의 확장작업 없이 이미 존재하는 망을 활용할 수 있다는 점에서 (시간적으로나 비용적으로)매력적인 프로젝트이다.

MBONE

http://1.bp.blogspot.com/-WP6DR7r2YN4/TdaSpDiiJ1I/AAAAAAAAAnU/50njSyb18lg/s1600/mbone.gif

위 그림처럼 MBone은 다른 인터넷망과는 분리된 별도의 터널을 가지게 되므로 멀티캐스트에 최적화된 패킷의 구성이 가능하다. 이들 멀티캐스트 IP패킷은 IP해더와는 다른 헤더를 가진다. 즉 출발지 목적지정보에 개별 호스트의 IP가 명시되는게 아니고 각 터널의 종점 IP주소가 명시된다. 이때 사용되는 라우팅 프로토콜로는 DVMRP와 MOSPF(Multicast Open Shortest Path First), PIM(Protocol Independent Multicast)등이 사용되고 있다. 현재는 MOSIPF와 PIM이 널리 사용되고 있다.

종점라우터에 도착된 데이터는 라우터가 관리하는 호스트중 데이터 요청을 원하는 호스트로 전송된다. 이때 IGMP가 핵심적인 프로토콜로 사용된다.

소켓은 멀티캐스트를 지원한다. 멀티캐스트 데이터는 라우터에서 처리하는 것이기 때문에, 소켓 프로그램 입장에서는 크게 유니캐스트 방식과 크게 다른 점이 없다. 일반 A,B,C 클래스 주소 대신에

1. 멀티캐스트 주소를 이용해서 채널에 가입하고
2. 채널에 가입하고 탈퇴하기 위한 채널 제어

를 위한 두 가지 사항만 염두에 두고 프로그램을 개발하면 된다.

소켓은 socket(:12) 함수로 만든다. 만든 소켓은 setsockopt(:2)함수를 이용해서 멀티캐스트 그룹에 가입하면 된다.

소켓 옵션 레벨은 IPPROTO_IP이고, 아래의 옵션 이름 값으로 제어할 수 있다.

• IP_MULTICAST_LOOP : 데이터를 호스트로 루프백 시킬 것인지를 결정한다. 예를들어 멀티캐스트 채널로 자신이 전송한 메시지를 보고 싶다면 활성화 시켜야 한다.
• IP_MULTICAST_TTL : 멀티캐스트 데이터를 서브네트워크에서만 확인할 거라면, TTL을 1로 해서 외부로 나가지 않도록 한다.
• IP_MULTICAST_IF :
• IP_ADD_MEMBERSHIP : 어떤 멀티캐스트 그룹에 참가할지를 알려주기 위해서 사용한다. 멀티캐스트 그룹에 참가한 프로세스로 메시지가 전달된다.
• IP_DROP_MEMBERSHIP : 어떤 멀티캐스트 그룹에서 탈퇴하기를 위해서 사용한다.

IP_ADD_MEMBERSHIP를 이용해서 멀티캐스트 그룹에 참가시킬려면 ip_mreq 구조체에, 멀티캐스트 그룹관련 정보를 채워서 setsockopt의 옵션값으로 넘겨야 한다.

• imr_multiaddr : 참가할 그룹의 멀티캐스트 주소.
• imr_interface : 통신에 참가할 인터페이스 주소. 일반적으로 모든 인터페이스 주소에 대해서 참가하므로 INADDR_ANY를 사용하면 된다.

예를들어서 멀티캐스트 채널 "239.1.1.1"에 참가하고 싶다면, 다음과 같이 setsockopt를 사용하면 된다.

연구에 참고할 문서

INTERNET PROTOCOL VERSION 6 MULTICAST ADDRESS

IPv6 멀티캐스팅 주소는 RFC2373(IP Version 6 Addressing Architecture)에 정의되어 있다. 여기에는 멀티캐스트 주소를 위해서 고정영역(fixed scope)과 변경가능영역(variable)을 정의하고 있다.

IPv6 멀티캐스트 주소는 주소영역의 상위 한바이트(octet)의 값을 이용해서 구분한다. 만약 상위 한바이트의 주소의 값을 0xFF(11111111)로 설정하는 걸로 멀티캐스트 주소임을 명시한다. 이외의 다른 값들은 유니캐스트 주소들을 위한 용도로 사용된다.

IPv6의 경우 IPv6보다 할당된 주소영역이 매우 크므로 비교적 여유있게 자원을 사용할수 있고, 실제로 다양한 네트워크 환경의 지원이 가능하도록 주소영역들이 정의되어 있다. 다음은 현재 IPv6에서 지원되는 멀티캐스트 주소영역의 목록이다.

Node-Local Scope

Link-Local Scope

site-Local Scope

또한 네트워크 환경 뿐만 아니라 서비스의 종류에 따라서 다양한 주소영역이 준비되어 있다. 이렇게 서비스종류에 따라서 주소영역이 세분화 되어 있으므로, 응용 애플리케이션의 개발이 쉬워지고 Qos보다 현실적으로 적용가능해 질 것이다.

Variable Scope Multicast Address 멀티캐스팅의 특성에 맞게 멀티미디어와 관려된 많은 서비스들이 존재하고 있음을 알 수 있다. 멀티미디어 서비스 외에도 NIS, NTP, NSS와 같이 동일한 정보를 여러개의 서버로 배포하는 인터넷 서비스를 위한 주소영역도 예약되어 있음을 확인할 수 있다. X Display를 위한 서비스가 있는게 개인적으로 유독 눈에 띈다.

• IP 멀티 캐스팅
• KRNET'98 특강
• Multicast 예제
• Multicasting in the Internet
• MBone란
• 인터네트 그룹 다중전송 규약(IGMP)
• IGMP V1.0 RFC 988