IT
posted by 구름너머 2007. 8. 28. 18:53
멀티캐스팅라우팅프로토콜 | N/W 및 통신 2007.02.12 13:46
코알라(jeonghee65) http://cafe.naver.com/itpride/246 이 게시물의 주소를 복사합니다
유니캐스트 라우팅 프로토콜은 호스트의 위치와 목적에 상관없이 일단 라우팅 테이블이 만들어지고 나면 네트워크의 변화가 없는 한 지속적으로 이를 유지한다. 또한 한번 만들어진 라우팅 테이블의 경로들 중 일부가 실제 패킷의 전달을 위해 자주 사용 되지 않고 어쩌다 사용되는 라우팅 경로라 할지라도 항상 라우팅 테이블에서 관리된다.





장점은 라우팅 테이블에 항상 존재하는 경로 정보 때문에 데이터 전달 요청에는 빠르게 반응할 수 있다.
하지만 유니캐스트 라우팅은 언젠가 사용할 수 있다는 가능성 때문에 지속적으로 경로 정보를 유지해야 함으로 라우팅 정보의 유지보수에 소모되는 자원의 낭비가 심하다. 그리고 경우에 따라서는 많은 라우팅 테이블을 갖고 있어야 하기 때문에 라우팅 테이블을 검색하기 위한 시간 낭비가 많아져 패킷 전달 속도의 저하가 전체 네트워크에 존재하는 모든 라우터에서 발생할 수 있다.
반면 멀티캐스트 라우팅 프로토콜은 라우터간에 통신하는 프로토콜로 멀티캐스트 데이터 패킷을 보내는 소스 호스트로부터 그 데이터를 받는 목적지 호스트까지의 경로를 만들기 위한 다양한 기능을 제공한다.
유니캐스트 라우팅에 비해 멀티캐스트 라우팅은 위치와 목적 정보를 기반으로 만들어 진다. 또한 멀티캐스트 라우팅 경로는 미리 만들어 지는 것이 아니라 서버나 클라이언트 호스트가 멀티캐스트 데이터를 주고받기 위한 IGMP 보고(Report)가 있을 때 만들어 지며 이후 모든 서버나 클라이언트 호스트가 멀티캐스트 데이터를 주고받는 프로그램을 종료하면 자동적으로 멀티캐스트 라우팅 경로는 제거된다. 즉 멀티캐스트 라우팅 정보는 필요에 의해 생성되고 제거되는 방식을 택하고 있다.
물론 이같은 특징은 데이터의 전달요구가 있을 때 바로 반응하지 못한다는 문제가 있기는 하지만 불필요한 라우팅 목록을 갖고 있지 않으므로 관리되는 라우팅 목록의 수가 적다. 때문에 유니캐스팅처럼 라우팅 테이블의 크기 증가로 인한 성능 저하 문제나 많은 라우팅 정보를 유지하기 위한 관리상의 부하도 적다.
또한 멀티캐스트 라우팅 테이블의 갱신은 네트워크의 변화에 의해 이뤄지는 것이 아니라 서버나 클라이언트 호스트가 멀티캐스팅 애플리케이션을 시작하고 종료할 때 IGMP에 의한 등록과 탈퇴 요구에 의해서 이뤄진다.

멀티캐스팅 라우팅 프로토콜
멀티캐스팅 라우팅 프로토콜의 목적은 분산 트리(Distribution Tree)를 만드는 것이다. 분산 트리란 멀티캐스팅 데이터를 보내는 소스 호스트로부터 그 데이터를 받는 목적지까지 중복되지 않고 루프가 없는 최단경로를 갖고 있는 경로 정보다. 트리를 구성할 때는 루트(Root)가 누가 되는가가 중요한데 분산 트리의 경우는 소스에서 가장 가까운 라우터가 루트가 된다. OSPF의 SPF알고리즘에서는 각각의 라우터 자신이 루트가 되고, 이더넷 STP(Spanning Tree Protocol)는 루트 브리지(Root Bridge)에 해당하는 스위치가 루트인 것과 비교해 볼만하다.
IGMP를 통해 특정 멀티캐스트 그룹에 등록한 목적지 클라이언트 호스트와 멀티캐스트 데이터를 전송하는 소스 호스트 간에 라우터들이 있다고 가정하자. 이 라우터들은 호스트의 IGMP를 통한 등록을 받아서 멀티캐스트 데이터의 소스를 수신하는 라우터를 루트로 하고 그를 필요로 하는 목적지 라우터의 요청만을 받아들여 트리를 작성하게 된다. 그러므로 데이터가 전송될 필요가 없는 네트워크로는 트리에 정의되지 않기 때문에 데이터 복제와 전송이 발생하지 않는다.
유니캐스팅 라우팅 프로토콜이 거리 벡터(Distance Vector)와 링크 상태(Link State), 하이브리드(Hybrid)로 나뉘듯이 멀티캐스팅 라우팅 프로토콜도 동작 형태에 따라 소스 분산 트리(Source Distribution Tree)와 공유 분산 트리(Share Distribution Tree)의 두가지로 구분된다.
소스 분산 트리는 소스 지정 트리(Source Specific Tree), 소스 기반 스패닝 트리(Source-Based Spanning Tree), 덴스 모드(Dense Mode) 멀티캐스팅 라우팅 프로토콜이라고 불리기도 하는데 이름이 의미하듯이 데이터를 전송하는 소스가 중심이 돼, 목적지까지의 최적경로를 만들어 낸다.
공유 분산 트리는 중앙 지정 트리(Center Specific Tree), 루트 기반 스패닝 트리(Root-Based Spanning Tree), 스파스 모드(Sparse Mode)라고 불리기도 하는데 이 모드에서는 모든 소스, 목적지 라우터의 정보를 모으고 공유하는 중심적인 역할을 수행하는 라우터가 선발된다. 나중에 소스 호스트들은 이 중심 라우터까지 데이터를 전송하게 되며, 목적지 호스트들 또한 이 중심 라우터에서 필요한 데이터를 받아오는 형식을 취한다.








또한 멀티캐스트 라우팅 프로토콜들은 유니캐스트 라우팅 프로토콜이 만든 라우팅 테이블을 평가함으로써 분산 트리를 만들어 낸다.

소스 분산 트리
소스 분산 트리는 송신자에서 수신자 사이에 만들어진 최단 경로를 멀티캐스팅 데이터 전달용으로 사용한다. 소스에 따라 여러 개의 트리가 만들어지므로 소스의 증가로 인해 라우터 자원에 대한 소비가 많아진다.
소스 분산 트리는 RPF(Reverse Path Forwarding)이라는 프로토콜에 의해 만들어 진다. RPF는 만약 패킷이 라우터에게 전달되면 라우터는 그 패킷이 들어온 방향을 소스 중에 하나의 최단 경로로 판단되면 라우터는 소스가 들어온 인터페이스를 제외한 나머지 모든 인터페이스로 그 패킷을 밀어낸다. 이때 소스로부터 최단 경로에 해당하는 인터페이스를 페어런트 링크(Parent Link)라고 부르고 라우터가 패킷을 전달하는 나가는 쪽 인터페이스를 차일드 링크(Child Link)라고 부른다.
만약 로컬 라우터와 인접 라우터 사이의 링크가 최단경로가 아니거나 중복된 경로면 패킷을 그 링크로 전달하지 않는다. (그림 1)을 예로 들면, 호스트 3으로 전송되는 경로는 A-B-F-G를 이용할 도 있고, A-E-F-G를 이용할 수도 있지만 최단 경로가 아니기 때문에 A-F-G 경로가 선택된다. 또한 똑 같은 데이터를 E가 F에게 보내고 F는 E에게 보내게 되는데 이 경로는 중복된 경로로 판단해 데이터를 전송하지 않게 된다.

덴스 모드 알고리즘과 덴스 모드 라우팅 프로토콜
덴스 모드의 핵심적인 알고리즘은 RPF다. 초기에는 멀티캐스팅 트래픽이 들어오면 소스 인터페이스를 제외한 다른 모든 인터페이스로 플러딩을 수행한다. 그래서 초기 트래픽은 모든 라우터와 모든 네트워크에 전달된다.
이를 수신한 멀티캐스팅 라우터는 멀티캐스트 패킷의 목적지 주소에 명시된 멀티캐스트 그룹 어드레스의 멤버가 있는지 판단하고, 만약 등록된 멤버가 없다면 멀티캐스트 트래픽을 수신한 소스 인터페이스로 ‘해당 멀티캐스트 그룹 어드레스에 등록된 멤버가 없으니 더 이상 데이터를 보내지 말라’는 가지치기 메시지(Prune Message)가 전송된다. 그 외에도 서로 인접한 라우터끼리 같은 멀티캐스트 그룹 어드레스의 목적지 주소를 가진 패킷을 서로 주고 받았을 때 이 인터페이스가 최적이 아닌 경로임을 서로 파악하면 가지치기 메시지(Prune Message)를 수행한다.
가지치기 메시지가 전달된 인터페이스로는 일정한 기간 동안 멀티캐스트 그룹 어드레스에 해당하는 메시지는 전달하지 않는다. 그러나 일정한 기간이 지나면 다시 주기적인 재 플러딩이 수행한다. 이같은 주기적인 플러딩 때문에 멀티캐스팅 클라이언트 입장에서는 보다 빨리 멀티캐스팅 데이터를 받을 수 있지만, 대역폭을 많이 소모하는 단점이 있다.
이 라우팅 프로토콜들은 소스 분산 트리 구성이 목표이다. 주로 집약적으로 분산된 수신자를 위해 사용하며 집약적이란 네트워크의 모든 라우터나 호스트들이 주로 하나의 멀티캐스팅 그룹에 속해 있으면서 이들 대부분이 멀티캐스트 데이터의 전송을 필요로 하고 있다는 의미다.
덴스 모드 라우팅 프로토콜은 멀티캐스팅 트래픽을 전달할 분산트리를 만들거나 유지하기 위하여 주기적인 플러딩에 의존한다. 그래서 이러한 플러딩을 감당할 만한 풍부한 대역폭을 갖고 있는 LAN 환경에서 주로 많이 사용한다.
하나의 네트워크 환경에서 대부분의 라우터가 멀티캐스트 트래픽을 전달한다고 하면 이 프로토콜을 사용하는 것이 바람직하다. 예를 들면 한 기업의 사장이 모든 직원들에게 연설하는 것을 실시간으로 전달하는 비디오 스트림 방송의 경우 거의 모든 직원들이 이것을 시청해야 하기 때문에 모든 라우터와 스위치, 호스트들이 이 멀티캐스팅 트래픽을 받아야 하는 경우에 적합하다.
이를 지원하는 대표적인 멀티캐스트용 라우팅 프로토콜로는 DVMRP(Distance Vector Multicasting Routing Protocol), MOSPF (Multicast Open Shortest Path First), PIM-DM(Protocol Inde pendent Multicast Dense Mode) 등이 있다.

·DVMRP
DVMRP는 RFC 1075에 정의되어있는 인터넷의 MBONE(Multi cast Backbone)에서 사용되는 인터넷 표준 프로토콜로 유니캐스팅 라우팅 프로토콜 중 BGP(Boarder Gateway Protocol)와 같은 수준의 프로토콜이다.
DVMRP는 RPF(Reverse Path Flooding)를 사용한다. 라우터는 멀티캐스트 패킷을 받은 소스 인터페이스(멀티캐스트 패킷이 발생한 소스쪽으로 되돌아 갈 수 있는 다른 인터페이스도 포함)를 제외한 다른 모든 인터페이스로 내보내진다. 이 기술은 멀티캐스팅 데이터 스트림이 모든 네트워크와 호스트에 도달할 수 있도록 해준다. 만약 라우터가 특정 멀티캐스팅 그룹에 대한 데이터를 거부하는 여러 개의 LAN을 연결하고 있다면 라우터는 패킷이 멤버가 존재하지 않는 곳으로 지속적으로 전달되는 것을 막기 위해 가지치기 메시지를 보낼 것이다.
DVMRP는 특정 멀티캐스팅 그룹에 대한 데이터를 요구하는 새로운 호스트에게 데이터를 전달하기 위해 주기적으로 재 플러딩을 수행한다. 이 때문에 주기적인 플러딩의 빈도는 새로운 클라이언트가 데이터를 받게 되는 시점과 직접적인 연관관계를 갖고 있다.
DVMRP는 자체적으로 어느 인터페이스로 보내면 소스로 되돌아가는가를 판단하기 위한 유니캐스트 라우팅 프로토콜을 갖고 있다. 이것은 RIP과 유사하게 홉(Hop) 수를 이용해 최적 경로를 찾는다. 비록 유니캐스트 라우팅 프로토콜을 이용하더라도 멀티캐스트 트래픽이 전달되는 경로는 유니캐스팅 데이터가 전달되는 경로와 다를 수 있다.

'IT' 카테고리의 다른 글

MSN 웹으로 이용하기  (0) 2007.08.30
라우팅의 종류  (0) 2007.08.29
RAID LEVEL  (0) 2007.08.27
L4  (0) 2007.08.27
SaaS(SW as a Service)로 눈을 돌리자  (1) 2007.08.22