개요이 문서는 PIM-SM 멀티캐스트 라우팅 프로토콜 버전 2를 중심으로 소개하며, 이미 멀티캐스팅에 친숙해 있고, PIM-SM RFC 문서를 읽기 전에 개요를 필요로 하는 IT 관리자들을 위해 작성되었습니다. PIM-SM은 그룹이 분산되어 있는 WAN에서 효율적으로 운영할 수 있도록 구성되어, 기존 IP 멀티캐스트 모델인 수신자 초기 구성원 모델을 사용하고, 최단 공유 경로 트리를 지원하며, 특정 유니캐스트 라우팅 프로토콜에 의존하지 않고, 변화하는 네트워크 환경에 적응하기 위해 soft-state 메커니즘을 사용합니다.
 PPIM-SM(Protocol Independent Multicast-Sparse Mode)은 멀티캐스트 패킷을 멀티캐스트 그룹으로 라우트하고, WAN에서 효율적으로 분배 트리를 구축하도록 설계되어 있습니다. PIM-SM은 어떤 라우팅 프로토콜이 멀티캐스트 RIB(Routing Information Base - 라우팅 정보 베이스) 또는 Windows 용어로는 멀티캐스트 뷰에 들어가는지에 대한 라우트 정보를 사용할 수 있기 때문에 "프로토콜 독립적"이라고 합니다. 이러한 라우팅 프로토콜에는 유니캐스트 프로토콜(예: RIP(Routing Information Protocol), OSPF(Open Shortest Path First)) 등이 있지만, 라우팅 테이블을 차지하는 멀티캐스트 프로토콜(예: DVMRP)을 사용할 수도 있습니다. Sparse 모드는 멀티캐스트 그룹이 광범위한 지역에 드물게 존재하는 상황을 위해 프로토콜이 설계된 경우를 말합니다. Sparse-mode 프로토콜은 LAN 환경에서 작동할 수도 있지만, WAN에서 가장 효율적으로 작동합니다. sparse group은 다음과 같이 정의할 수 있습니다. 첫째, 그룹 구성원이 있는 현재 네트워크나 도메인 수가 인터넷의 네트워크나 도메인 수보다 현저하게 적은 경우, 둘째, 그룹 구성원들이 너무 큰 지역이나 광범위한 지역에 분산되어 있어 홉 수나 멀티캐스트 패킷 전달 범위를 제한하는 기타 형식에 의존할 수 없는 경우, 셋째, 현재 [dense mode] 오버헤드 구성을 무시할 만큼 충분한 자원이 인터네트워크에 없는 경우를 말합니다. 이와 반대로, DVMRP와 멀티캐스트 OSPF(MOSPF)와 같은 dense 모드 프로토콜은 멀티캐스트 그룹이 많고 대역폭이 충분한 상황에 맞게 구성되어 있습니다. 이 프로토콜을 사용하면 데이터 패킷과 구성원 보고서 정보를 멀티캐스트 소스나 관련 수신자로 연결되지 않는 인터페이스로 보낼 수 있고, 라우터는 이러한 노드의 연결 상태를 저장합니다. 물론 이 또한 불필요한 것입니다. 대부분의 호스트가 그 데이터에 연결되어 있고 제어 메시지의 흐름을 지원할 대역폭이 충분한 경우에는 이러한 오버헤드를 수용할 수 있지만 그렇지 않은 경우에는 비효율적입니다. PIM-SM은 데이터가 요청되지 않으면 어떤 호스트도 데이터를 필요로 하지 않는다고 가정합니다. 그러나 PIM은 sparse 모드와 상호 운용 가능한 dense 모드 특허권(PIM-DM)이 있습니다. PIM-SM은 다음과 같은 목표를 지원하도록 구성되었습니다.
나머지 부분은 이러한 사항에 대해 세부적으로 설명하고 PIM-SM 작동 방법에 대한 예제를 보여줍니다. 특히 1998년 6월자 RFC 2362에 명시된 PIM-SM 버전 2(시험 버전)에 중점을 두고 버전 1과 버전 2의 차이점을 설명하고 있습니다.
PIM-SM 프로토콜은 다음과 같은 부분으로 나눌 수 있습니다.
안정된 시스템이라는 가정 하에 즉, RP가 이미 결정된 상태라고 가정하고 각 부분에 대해 차례로 설명합니다. 마지막 부분에서 실제로 일어나는 현상들을 설명합니다. 그 전에, 먼저 다음에 대해 설명합니다.
이 용어들을 이해하면 PIM-SM 프로토콜을 쉽게 이해할 수 있습니다. Flooding and Reverse 경로 전달Flooding은 라우팅 정보에 의존하지 않는 라우팅을 위한 단순한 체계입니다. Flooding에서 패킷은 수신된 인터페이스 이외의 모든 인터페이스에 전달됩니다. 패킷이 복제되는 횟수를 제한하기 위해, 홉 수와 같은 메트릭이 사용됩니다. 메트릭이 지정된 임계값에 도달하면 패킷은 버려집니다. Flooding 오류는 각 패킷을 너무 많이 복제한다는 데 있습니다. 따라서 flooding은 패킷이 손실되지 않고 노드마다 각 패킷의 복사본을 전달하지만, 너무 많은 트래픽을 발생시키므로 패킷이 손실될 수도 있습니다. RPF는 Yogen Dalal.2세에 의해 처음으로 소개된 개념입니다. RPF는 최적화된 초과 형태로, I가 S에 도달하기 위해 라우터가 사용하는 인터페이스인 경우에만 라우터가 인터페이스 I를 통해 소스 S에서 패킷을 받습니다. RPF는 유니캐스트 라우팅 테이블을 참조하여 인터페이스가 맞는지 결정합니다. 이 기술은 표준 flooding과 관련된 오버헤드를 현저하게 줄여줍니다. 라우터는 오직 인접한 다른 한 라우터에서만 패킷을 받기 때문에, 패킷을 한 번만 초과합니다. 즉, 지점간 연결을 가정할 때, 각 패킷이 각 방향으로 한 번만 전송됩니다. 아래 그림 1은 RPF 예제를 나타낸 것입니다.
그림 1 RPF 예제 이 예제에서 라우터는 인터페이스 IO를 통해 172.16.0.0/20 네트워크의 소스에서 온 패킷을 버립니다. 이것은 라우팅 테이블이 이 인터페이스를 172.16.0.0/20 네트워크로 가는 최단 경로로 판단하지 않기 때문입니다. 만약 라우터에 이 네트워크로 전달할 패킷이 없다면 I1이 사용됩니다. 라우팅 테이블이 이 인터페이스를 네트워크의 최단 경로로 인식하기 때문에 인터페이스 I1을 통해 도착한 패킷이 전달됩니다. 라우터의 유니캐스트 라우팅 테이블이 멀티캐스트 패킷의 최단 경로를 결정합니다. 최단 경로 트리최단 경로 트리(SPT)는 소스 기반 트리라고도 합니다. 즉, 전달 경로는 소스까지의 최단 유니캐스트 경로를 기준으로 합니다. 그렇기 때문에 소스 트리를 유니캐스트 라우팅 테이블의 관점에서 최단 경로 트리라고 합니다. 만약 유니캐스트 라우팅 메트릭이 홉 수이면 멀티캐스트 SPT는 최소 홉 수로 분기됩니다. 메트릭이 지연되면 최소 지연으로 분기됩니다. 모든 멀티캐스트 소스의 경우 소스를 모든 수신기에 직접 연결해 주는 해당 멀티캐스트 트리가 있습니다. 일단 소스에 대한 트리와 트리에 연결된 그룹이 구성되면, 그 그룹 구성원에 대한 모든 트래픽은 이 트리로 전달됩니다. SPT는 송신 인터페이스 목록이 있는 (S, G) 엔트리가 있습니다. 여기서 S는 소스 주소이고, G는 멀티캐스트 그룹입니다. SPT를 사용하는 다른 프로토콜의 예로는 dense 모드 프로토콜인 DVMRP와 MOSPF가 있습니다. 아래 그림 2는 SPT의 예를 나타낸 것입니다.
그림 2 SPT 예제 이 예에서 Source1에 대한 SPT는 Router 1과 3의 연결을 통한 대체 경로가 있지만 Router 1의 인터페이스 I0를 통하고 있습니다. Source2에 대한 SPT는 약간 멀긴 하지만 대체할 수 있는 경로가 있지만 인터페이스 I3을 통하고 있습니다. 이 예에서 메트릭은 홉 수입니다. 공유 트리PIM-SM에 대한 공유 트리는 소스에서 트래픽을 모두 수신하고 수신기로 트래픽을 모두 전달하는 RP라고 하는 중앙 라우터에 의존하기 때문에 RP 트리(RPT-RP 트리)라고 합니다. 구성원이 중앙 노드로 명시적 조인을 보내므로 모든 호스트가 수신기라는 가정이 없는 셈입니다. 결과적으로, 소수 수에 관계 없이 각각의 멀티캐스트 그룹에 대해 하나의 트리가 있습니다. 그룹에 대해 알고 있는 유일한 라우터들은 해당 트리에 있고, 오직 관심 있는 수신기에만 데이터를 보냅니다. RPT에는 와일드카드 엔트리라고도 하는 (*, G) 엔트리가 있습니다. 여기서 G는 멀티캐스트 그룹입니다. RP로 수신기는 소스가 아직 존재하지 않더라도 조인할 위치를 갖습니다. 공유 트리는 단방향입니다. 즉, 데이터가 RP로부터 수신기로만 흐릅니다. RP 이외의 호스트가 트리로 보내면 데이터를 보내기 위해서는, 먼저 데이터가 네트워크 참가자들에게 멀티캐스트 되기 전에 터널링되어야 합니다. 즉, 수신기가 동시에 소스이면, 해당 수신기가 RP에 패킷을 보내기 위해 해당 트리를 사용할 수 없습니다. 오직 RP로부터 패킷을 수신하는 데에만 트리를 사용할 수 있습니다. 이것이 일반적으로 맞긴 하지만 예외적인 경우도 있습니다. 예를 들어, 소스가 RP와 수신기 사이에 있고 이미 트리상에 존재하는 경우입니다. 이러한 경우에는 데이터가 소스에서 수신기로 직접 흐르게 됩니다. RPT는 지연 시간이 길지만(패킷은 분배되기 전에 먼저 RP에 보내져야 함) 유지할 라우터 상태는 많지 않습니다. RPT가 적절한 응용 프로그램의 예를 들면 다음과 같습니다.
화상 회의 응용 프로그램은 SPT와 RPT를 모두 사용할 수 있습니다. PIM-SM은 이들을 동시에 사용할 수 있습니다. 연결 유지 패킷은 데이터 비율이 낮아도 보내지기 때문에 RPT는 이러한 패킷에 사용될 수 있습니다. 소스는 많은 양의 데이터를 보내기 때문에 SPT를 사용할 수 있습니다. 아래 그림 3은 PIM-SM RPT의 예를 나타낸 것입니다.
그림 3 공유 트리의 예 이 예에서, 네트워크 구성이 최단 경로 예에서의 구성과 동일할 수 있지만 트래픽은 흐름은 다릅니다. Source(1)에서 모든 멀티캐스트 트래픽은 Router 1의 인터페이스 I(1)을 거쳐서 Router 3(RP)으로 흐릅니다. Source(2)에서는 라우터 2의 인터페이스 I(2)를 지나 RP로 흐릅니다. 소스에서 이 중앙 포인트로의 경로가 최단 경로 루트입니다. 그러면 RP는 데이터를 명시적으로 멀티캐스트 그룹에 연결한 수신기들에게 단일 트리를 사용하여 분배합니다. 다중 RP들이 한 네트워크에 존재할 수는 있지만 각 멀티캐스트 그룹에 대해서는 반드시 한 개의 RP만 있어야 합니다. RP에서 수신기로의 경로가 가장 짧지만 소스에서 수신기들로의 최단 경로는 수신기에서 RP로의 경로와는 다릅니다. 그렇다면 "왜 RPT 대신 SPT를 사용하지 않는가?"라는 의문이 생길 것입니다. PIM-SM의 경우에는 두 가지 대답이 가능합니다. 첫째, PIM-SM은 트래픽의 용량이 허용된다면 수신기에 직접 연결된 마지막 홉 라우터가 RPT를 떠나 SPT에 연결해주는 방법이 있습니다. 이것을 SPT 스위치라고 하며, 이 문서의 뒷 부분에서 설명합니다. 둘째, RPT가 사용될 때 라우터는 그만큼의 상태를 유지할 필요가 없습니다. 이렇게 하면 필요한 메모리의 양을 줄어듭니다.
이제 네트워크 환경부터 시작하여 PIM-SM 프로토콜의 각 부분들에 대해 설명합니다. 처음에 설명한 것처럼, 여기서 RP가 이미 선택된 것으로 가정합니다. 마지막 단원에서 RP가 어떻게 선택되는지 설명합니다. Hello와 연결/Prune 등의 제어 메시지를 설명할 때 PIM-SM 버전 2를 참조했습니다. 버전 2 메시지들은 프로토콜 번호 103으로 IP 패킷에 캡슐화되었습니다. 버전 1 메시지들은 IGMP(Internet Group Management Protocol) 패킷에 캡슐화되었습니다. IP 캡슐화 형식이나 다른 제어 메시지에 대한 형식은 이 문서 마지막에 있는 "제어 메시지"를 참조하십시오. Hello 메시지PIM 라우터는 정기적으로 인접 PIM 라우터들을 발견하기 위해 Hello 메시지를 보냅니다. Hello 메시지는 224.0.0.13 주소(모든 PIM 라우터 그룹)를 사용하여 멀티캐스트됩니다. Holdtime 필드는 정보가 유효한 기간을 명시합니다. 라우터는 Hello 메시지가 수신되었다는 알림 메시지를 보내지 않습니다. 또한 다른 몇몇 프로토콜(예: DVMRP)과는 달리, Hello 메시지가 수신되었을 때 자동적으로 멀티캐스트 트래픽을 전달할 송신 인터페이스 목록에 인터페이스가 자동으로 추가되지 않습니다. PIM-SM은 명시적 연결 모델을 사용합니다. 즉, 트래픽이 인터페이스에 전달되기 전에 다운스트림 수신기가 반드시 특정 그룹에 연결되어야 합니다. 멀티캐스트 패킷 전달PIM-SIM 라우터는 멀티캐스트 트래픽을 멀티캐스트 그룹에 명시적으로 연결한 수신기에 연결되는 모든 인터페이스에 전달합니다. 수신기들은 IGMP 호스트 구성원 보고서를 자신이 속한 각 그룹에 보내어 전달합니다. 이 메시지들은 그룹 주소로 보내지고, 1 TTL(Time To Live)의 IP 시간을 갖고 로컬 서브네트워크에 제한됩니다. 라우터는 패킷이 전달되기 전에 RPF를 확인합니다. 트리가 RPT 혹은 SPT인지에 따라 라우터가 수행하는 RPF 검사 유형이 달라집니다. RPT인 경우에는 RP의 IP 주소를 사용하고, SPT일 경우에는 소스 주소를 사용합니다. 아래 그림 4는 이 두 가지에 대한 예제를 나타낸 것입니다.
그림 4 RPT와 SPT에서 RPF 검사 소스 162.10.4.1에서의 멀티캐스트 트래픽은 RPT를 사용합니다. 즉, 소스가 RPT를 멀티캐스트 그룹이 아닌 RP로 보냅니다. 라우터는 (S, G) 엔트리 보다 (*, G) 엔트리를 사용하여 이를 표시합니다. 이 트래픽을 보내기 전에 Router 1은 해당 유니캐스트 라우팅 테이블을 검사하여 RP로부터 패킷들이 정확한 인터페이스에 도달하고 있는지 확인합니다. 이 경우 패킷들은 인터페이스 I1에 도달하고 있으므로 정확한 인터페이스에 도달한 것이며 따라서 패킷들이 전달됩니다. 소스 162.10.4.2로부터 멀티캐스트 트래픽은 SPT(라우터는 소스에 대해 (S, G) 엔트리를 사용하여 이를 표시함)를 사용합니다. 이 경우 라우터는 소스의 IP 주소를 사용하여 RPF를 검사합니다. 이 때 소스로부터 트래픽이 정확한 인터페이스에 도달하고 있는지 확인하기 위해 유니캐스트 라우팅 테이블을 참조합니다. 이 경우 역시 정확하게 도달하고 있으므로, 트래픽이 전달됩니다. 정확한 인터페이스에 도달한 트래픽은 모든 송신 인터페이스(oif)로 보내지고, 만약 아래 조건들을 충족할 경우 다시 다운스트림 수신기로 보내집니다.
(*, G)나 (S, G) 엔트리에 대한 oif 목록이 있는 경우 공유 트리 연결앞에서 언급했듯이, 한 호스트가 멀티캐스트 그룹에 연결하려면 해당 호스트는 업스트림 라우터에 IGMP 메시지를 보냅니다. 이것은 라우터가 해당 그룹에 대한 멀티캐스트 트래픽을 받아들이기 시작한다는 것을 의미합니다. 이렇게 하려면 라우터는 자신이 연결할 RPT에 RP 신호를 보내야 하는데, PIM (*, G) 연결 신호를 RP 방향으로 업스트림 네트워크 환경에 보내야 합니다. 연결 메시지들은 ALL-PIM-ROUTERS 그룹인 244.0.0.13으로 홉끼리 멀티캐스트됩니다. 즉, 멀티 액세스 네트워크에서 모든 PIM 네트워크 환경은 이러한 연결을 인식하지만 지정된 업스트림 PIM 네트워크 환경만 이러한 연결을 수행합니다. 여기서 연결과 정리에 동일한 메시지가 사용됩니다. 이에 관해서는 문서 뒷 부분에서 다시 설명합니다. PIM 라우터가 다운스트림 라우터로부터 (*, G) 연결 신호를 받으면 이 라우터는 (*, G) state는 멀티캐스트 라우팅 테이블 내에 그룹 G가 있는지 확인합니다. 만약 state가 이미 있다면 연결 메시지는 공유 트리에 도달한 것이며 메시지가 보내진 인터페이스가 oif 목록에 있는 것입니다. 만약 state가 없으면 (*, G) 엔트리가 생성되고 인터페이스는 oif 목록에 포함되며 다시 연결 메시지가 RP로 보내집니다. 일단 (*, G) state가 마지막 홉 라우터에서 RP로 보내지면, G에 대한 멀티캐스트 트래픽은 그룹에 연결한 호스트에 도달할 수 있습니다. 아래 그림 5는 이 과정을 나타낸 것입니다.
그림 5 PIM 연결 예제 이 예에서, 수신기는 멀티캐스트 그룹 G에 연결하기 위해 IGMP 호스트 구성원 메시지를 Router 2에게 보냅니다. 이 수신기는 그룹에 연결한 Router 2에 연결된 첫째 수신기이므로, 라Router 2는 (*, G) state가 없습니다. Router 2는 oif 목록에 I4를 추가하며 엔트리를 만들고, 업스트림 네트워크 환경인 Router 1에 연결 메시지를 전달합니다. Router 1도 (*, G) state가 없으므로 이 과정을 반복하게 되며, 연결 메시지를 RP로 전달하게 됩니다. 이것은 RP가 연결 메시지를 받거나 이미 (*, G) state가 있는 업스트림 라우터가 연결 메시지를 받을 때까지 계속됩니다. 어느 경우이건, RP에서 수신기에 도달하는 RPT가 형성되지만, 수신기가 IGMP 메시지를 보내기 전에는 아무 것도 발생하지 않으며, 수신기는 연결 과정을 초기화합니다. 지정 라우터여러 라우터들이 멀티 액세스 네트워크(예: 이더넷)에 연결된 경우, 이 중 하나를 선택하여 일정 시간 동안 DR(designated router - 지정 라우터)로 작동해야 합니다. DR은 연결/정리 메시지를 RP로 보냅니다. DR을 선택하기 위해 네트워크의 각 PIM 라우터는 수신한 Hello 메시지의 IP 주소를 검사하여 네트워크 환경들이 수신한 Hello 메시지와 비교합니다. 최상위 주소를 가진 라우터가 DR이 됩니다. 그림 6은 이 과정을 설명한 것입니다.
그림 6 DR 선택 이 예에서 Router 2가 상위의 IP 주소를 가지고 있기 때문에 DR이 됩니다. 만약 지정된 시간동안 이 DR로부터 Hello 메시지를 받을 수 없다면 다른 DR이 선택됩니다. 이때도 역시 최상위 IP 주소가 DR이 됩니다. RP에 등록멀티캐스트 트래픽의 소스는 자신이 데이터를 보내는 그룹에 반드시 연결할 필요는 없습니다. 첫째 홉 라우터(DR)는 특정 소스로부터 그 소스에 대한 (S, G) state가 없이도 트래픽 받기를 시작할 수 있습니다. 즉, 트리를 통해 RP로 멀티캐스트 트래픽을 전할 방법에 대한 정보가 없습니다. 소스의 DR이 처음 멀티캐스트 패킷을 받으면 해당 패킷을 Register 메시지 내에 캡슐화하여 해당 그룹의 RP에 유니캐스트합니다. RP는 각 Register 메시지 캡슐을 풀어서 추출된 데이터 패킷을 RPT의 다운스트림 구성원에게 전달합니다. SPT를 다시 소스에 만들기 위해 RP가 (S, G) 연결을 DR에 다시 보낼 수도 있습니다. 이러한 현상은 데이터 속도 임계값에 도달할 때 주로 발생합니다. 일단 소스로부터 RP로 경로가 형성되면, DR은 RP에 트래픽을 보내기 시작합니다. 이 트래픽은 표준 IP 멀티캐스트 패킷뿐만 아니라 Register 메시지 내에 캡슐화되어 있습니다. 이것은 RP가 일시적으로 동일한 패킷들을 두 번 받을 수도 있다는 것을 의미합니다. RP가 정상적인 멀티캐스트 패킷을 감지하면 Router 1에게 Register-Stop 메시지(등록 패킷을 더 이상 보내지 말라는 의미의 메시지)를 보냅니다. 아래 그림 7은 등록 방법을 보여줍니다(라우터에 기존 상태가 없다고 가정).
그림 7 등록 패킷 예제 이 예는 멀티캐스트 데이터 전송을 시작할 소스를 보여줍니다. 소스의 DR인 Router 1은 (S, G) state를 만들어 Register 메시지에 캡슐화 한 패킷을 RP에 유니캐스트합니다. RP는 패킷을 받은 후 Register 메시지에서 멀티캐스트 데이터를 추출하고, 관심 있는 수신기가 있다면 RPT를 따라서 그 데이터를 전송합니다. SPT까 형성될 때까지 Router 1은 멀티캐스트 데이터를 포함하고 있는 Register 메시지를 RP로 계속 유니캐스트합니다. 일단 트리가 만들어지면, Router 1은 표준 IP 멀티캐스트 패킷으로 보내진 동일한 멀티캐스트 트래픽을 SPT를 따라 전달하기 시작합니다. 이것은 RP가 일시적으로 소스의 데이터를 Register 메시지와 SPT를 통해 받는다는 의미입니다. Register-Stop 메시지RP가 Register 메시지 내의 소스에서 캡슐화가 풀린 IP 패킷 형태로 트래픽을 받기 시작할 때, RP는 DR에 Register-Stop 메시지를 보냅니다. 이것은 DR에게 현재 트래픽이 SPT 상에서 표준 IP 멀티캐스트 패킷으로 보내진다는 의미입니다. 일단 DR이 메시지를 받으면, RP는 트래픽을 Register 메시지에 캡슐화하는 것을 멈추게 됩니다. 그림 8은 이 과정을 나타낸 것입니다.
그림 8 register-stop 패킷 예제 RP가 Register-Stop 메시지를 보내는 또 다른 경우는 어떤 수신기들도 멀티캐스트 그룹에 속하지 않는 경우입니다. 소스는 구성원이 없는 그룹으로 전송을 시작할 수 있습니다. RP는 이 패킷들을 버리고 Register-Stop을 보내어 DR이 Register 메시지를 보내는 것을 멈추게 합니다. 인터페이스 정리RP가 Prune 메시지를 받았을 때, RP는 더 이상 Prune 메시지에 명시된 소스로부터 트래픽을 전달하지 않습니다. Prune은 수신기에 바로 연결된 leaf 라우터로부터 생겨나는데, 이것을 DR이라 가정합니다. 만약 멀티캐스트 그룹의 마지막 구성원이 DR에 IGMP 버전 2 메시지(혹은 IGMP 버전 1에서는 시간 제한 신호)를 보내면 DR의 IGMP state는 삭제되고 인터페이스는 그룹 G에 대한 (S, G)와 (*, G) oif 목록 전체에서 삭제됩니다. 만약 (*, G) state의 oif 목록에 있는 모든 인터페이스가 삭제되면(즉, 라우터가 G의 멤버인 인터페이스 상에 어떤 수신기도 가지지 않는다면) prune 메시지가 공유 트리를 통해 RP로 보내지게 됩니다. 만약 업스트림 라우터 또한 널 oif 목록을 가진다면, 메시지는 RP로 계속 전달됩니다. 만약 라우터가 다른 인터페이스 상의 수신기들에 대해 여전히 (*, G) state를 갖는다면 PIM 네트워크 환경에서 연결 메시지를 받지 않는 한 이 인터페이스를 삭제합니다. 그림 9는 prune 과정을 보여주고 있습니다.
그림 9 pruning 과정의 예 이 예에서, leaf 라우터인 Router 2는 IGMP Leave 메시지를 수신기로부터 받습니다. Router 2는 이 메시지를 처리하고, 다른 그룹 구성원이 없기 때문에, (S, G) oif 목록뿐만 아니라 (*, G)에서 I4를 제거합니다. 라우터의 oif 목록에는 이제 아무 것도 없고, 따라서 (*, G) Prune 메시지를 RPT를 따라 I3를 지나 RP로 보냅니다. Prune 메시지는 Router 1이 수신합니다. 이렇게 되면 I3 인터페이스를 멀티캐스트 라우팅 테이블에 있는 (*, G) 엔트리의 oif 목록에서 제거하게 됩니다. 약간의 시간이 지나야 정리 효과가 나타납니다. 연결 메시지가 PIM 네트워크 환경에서 연결을 무시하라는 메시지를 받을 수도 있기 때문에 다중 액세스 네트워크에서 기다리는 것은 무척 중요합니다. 이 경우는 아무 것도 받치지 않았으므로 인터페이스는 정리됩니다. (*, G) oif 목록이 널 값이므로 (*, G) Prune이 RPT를 따라 RP로 전달됩니다. 이 과정은 RP가 메시지를 받거나 혹은 prune 결과로 해당 (*, G) oif 목록이 널이 되지 않는 라우터가 도착할 때까지 계속됩니다. Assert 메시지다중 액세스 네트워크에서 소스나 RP로 평행한 경로가 있을 수 있습니다. 이것은 여러 라우터들로부터 복제된 패킷을 받는 그룹 구성원들로 이어질 수 있습니다. 이 문제를 피하기 위해, PIM-SM은 지정된 전달자를 결정하기 위해 Assert 메시지를 사용합니다. 그림 10은 이러한 상황을 나타낸 것입니다.
그림 10 Assert를 필요로 하는 네트워크의 예 이 예에서 RP인 Router 1은 멀티캐스트 트래픽을 Router 2와 3에 전달합니다. 이 라우터들은 차례로 트래픽을 LAN으로 전달합니다. Router 3이 먼저 전송한다고 가정해 보십시오. Router 2는 oif 목록에 이 그룹을 가지고 있는 인터페이스에 멀티캐스트 패킷을 받습니다. 그 후 Router 2는 패킷을 Router 3으로 보내는 데, 이는 Router 3이 송신 인터페이스에서 데이터를 받았다는 것을 의미합니다. 송신 인터페이스에서 들어오는 패킷을 받는 것은 라우터들에게 LAN의 다른 PIM-SM 네트워크 환경들이 그 그룹에 트래픽을 전달하고 있다는 것을 알립니다. 즉, 그룹 구성원들이 복제 데이터를 수신하게 됩니다. 이러한 상황을 피하기 위해, 라우터는 Assert 메시지를 보내어 단일 라우터가 트래픽을 전달하도록 선택합니다. 다운스트림 라우터들은 이 Assert 메시지를 받고 선택된 라우터를 알 수 있고, 따라서, 그 다음에 연결할 메시지를 어디로 보낼 지 알 수 있습니다. 예에서, Router 5가 처음에 연결 메시지를 Router 3으로 보내지만, Router 4는 처음에 연결 메시지를 Router 2로 보냅니다. Assert 후에 모든 연결 메시지들은 어느 것이 지정된 전달자가 되는 가에 따라 Router 2나 Router 3으로 갑니다. Assert 얻기만약 모든 라우터들이 같은 유니캐스트 프로토콜을 사용하고 있다면, 최상의 메트릭을 가진 라우터가 Assert를 얻습니다. 예를 들어, 만약 모든 라우터가 RIP를 사용하고 있다면, 가장 적은 홉 수를 지닌 라우터가 선택됩니다. 메트릭이 같다면, 최상위의 IP 주소를 지닌 라우터가 선택됩니다. 만약 라우터들이 다른 유니캐스트 프로토콜을 사용하고 있다면, 메트릭은 비교될 수 없습니다. 예를 들어, OSPF 메트릭이 인터페이스의 속도를 기준으로 하지만, RIP는 홉 수를 메트릭으로 사용합니다. 이 경우 메트릭 기본값이 트래픽을 전달할 라우터와 인터페이스를 정리할 라우터를 결정하게 됩니다. 메트릭 기본값은 네트워크에서 작동하는 각 유니캐스트 프로토콜에 따라 설정될 수 있습니다. 라우터가 어떤 그룹에 대한 Assert 메시지를 수신할 때, 그 패킷 내의 메트릭 설정값은 자신의 값과 비교합니다. 만약 그 두 값이 일치하면 메트릭은 이 두 값을 비교하여 트래픽을 전달할 라우터를 결정합니다. 메트릭 기본값이 다르면 메트릭 우선 순위가 가장 낮은 것이 선택됩니다. SPT 전환트래픽 임계값(KB로 표시)은 마지막 홉 라우터에서 설정되어, 한 그룹에 대한 임계값이 초과되었을 경우 라우터는 RPT에서 SPT로 변경할 수 있습니다. 이러한 상황이 발생하면 DR은 (S, G) 연결을 패킷의 소스에 보냅니다. 이렇게 되면 소스 S에서 라우터로 SPT를 형성합니다. SPT로 전환은 멀티캐스트 트래픽을 전달할 때 최단 경로가 사용됨을 의미합니다. RP와 관련된 소스의 위치에 따라 이러한 전환은 네트워크 대기 시간을 현저하게 줄일 수 있지만, 늘어난 양의 state를 라우터에서 유지해야 한다는 문제가 있습니다. 전환이 발생해야 하는지 결정하기 위해 RPT를 따라 흐르는 트래픽의 총 비율이 주어진 시간 간격으로 계산됩니다. 일반적으로 이 비율을 초과하면 해당 그룹이 수신한 다음 패킷이 전환됩니다. 실제로 일어나는 현상에 대한 세부 사항 및 이 총 비율 계산 주기는 구현 방법에 따라 다릅니다. 특정 프로토콜별로 지정되지 않습니다. RP 결정PIM-SM 버전 1은 RP를 결정하기 위한 두 가지 방법이 있었습니다. 첫째 방법은 정적인 방법입니다. 이 방법은 각 leaf 라우터를 그룹이나 그룹 집단의 주소로 구성해야 합니다. 둘째 방법은 동적인 방법으로, Auto-RP라는 방법을 사용했습니다. PIM-SM 버전 2는 버전 1과 다릅니다. 버전 2는 부트스트랩 메시지들을 생성하기 위해 BSR(bootstrap router - 부트스트랩 라우터)를 사용합니다. 이 메시지들은 BSR을 선택하는 데 사용되며, RP 정보를 전달하는 데에도 사용됩니다. 이 메시지들은 각 링크상의 ALL-PIM-ROUTERS 그룹에 멀티캐스트 됩니다. 하나 혹은 그 이상의 라우터를 BSR 지원자로 구성할 수 있습니다. 만약 어떤 라우터가 BSR이 되어야 하는지 명확하지 않다면, 지원자들이 도메인을 광고로 채웁니다(RPF를 사용하면 초과 비용이 감소). 우선 순위가 가장 높은 라우터가 선택됩니다. 우선 순위가 모두 같을 경우에는 최상위의 IP 주소를 지닌 지원자가 BSR이 됩니다. 여기서 도메인은 PIM-SM 버전 2를 수행하는 라우터의 연속적인 집합으로, PIM 멀티캐스트 경계 라우터(PMBR)에 의해 정의된 공통 경계 내에서 작동하도록 구성된 것입니다. 간단히 말하면, PMBR은 각 PIM 도메인을 나머지 인터넷에 연결합니다. 자세한 내용은 RFC 2362 문서를 참조하십시오. RP 지원자가 되도록 구성된 라우터들은 이 정보를 BSR에 유니캐스트합니다. 일반적으로 BSR 지원자로 구성된 라우터들이 다시 RP로 구성됩니다. RP 지원자 알림에는 알리는 라우터의 주소 뿐만 아니라 서비스를 받을 수 있는 멀티캐스트 그룹의 주소까지도 포함됩니다. BSR은 그룹 주소와 함께 이러한 RP 지원자들(RP-Set)의 집합을 정기적으로 생성하는 부트스트랩 메시지에 포함합니다. 부트스트랩 메시지들은 도메인 내에서 홉 단위로 분배됩니다. 라우터들은 BSR이 생성한 부트스트랩 메시지를 수신하고 저장합니다. DR이 직접 연결된 호스트의 IGMP 또는 엔트리가 없는 그룹의 IGMP로부터 구성원 지시를 받을 때, DR은 해시 기능을 이용해서 그룹에 서비스를 제공할 수 있는 지원자 RP 중 한 주소에 그룹 주소를 매핑시킵니다. 이렇게 하면 DR은 Join/Prune 메시지를 해당 RP에 보내거나, 혹은 Register 메시지를 해당 RP에 유니캐스트합니다.
PIM-SM 버전 2가 아직 "테스트" 단계라 하더라도 현재 멀티캐스트 라우팅 프로토콜에서는 표준으로 간주되고 있습니다. 하지만 몇 가지 .문제가 아직 해결되지 않고 있습니다. 처음에 설명한 대로, PIM-SM 버전 2가 라우터 간 프로토콜이므로, PIM-SM 버전 2를 지원하기 위해서는 네트워크의 모든 라우터들이 업그레이드되어야 합니다. 두 번째 문제는, 지원자 RP의 수가 도메인의 크기와 선형적으로 비례하므로 프로토콜은 광범위하게 비례할 수 없습니다. G를 RP에 매핑하면 BSR 알림 초과가 포함되기 때문에 이러한 매핑을 수행해도 비례 문제가 발생합니다. 또 다른 문제는 RP의 위치입니다. 세계적으로 많은 ISP가 있지만 그 중 누구도 자신의 고객들 간의 멀티캐스트 서비스를 위해 다른 ISP의 도메인에 있는 RP에 의존하는 것을 원치 않습니다.
여기서는 PIM-SM으로 기호화된 주소 필드와 제어 메시지 형식과, 제어 메시지들이 PIM 메시지에 대한 표준 헤더와 IP 패킷 내에서 어떻게 캡슐화되는지 설명합니다. 이 메시지들에 대한 자세한 내용은 RFC 2362 문서를 참조하십시오. 여기서는 다음과 같은 형식을 설명합니다.
PIM Control-메시지 캡슐화아래 그림 11은 PIM-SM 제어 메시지가 IP 패킷 내에 포함되는 방법을 보여줍니다.
그림 11 캡슐화된 PIM 제어 메시지 PIM-SM 버전 2 메시지들은 프로토콜 번호가 103으로 설정된 IP 패킷에 캡슐화됩니다. PIM-SM 패킷 헤더PIM-SM 버전 2 패킷의 헤더는 아래 그림 12에서 나타나 있습니다.
그림 12 PIM-SM 버전 2 패킷 헤더 헤더 내의 이 필드들은 아래와 같은 값을 갖습니다.
각 제어 메시지의 종류는 서로 다른 Type의 값을 갖습니다. 아래 표 1을 참고하십시오. 표 1 PIM-SM 버전 2 메시지 형식 Type
인코드된 유니캐스트 주소인코드된 유니캐스트 주소 필드는 아래 그림 13에 나타난 형식을 갖습니다.
그림 13 인코드된 유니캐스트 주소 필드 하위 필드는 아래와 같은 값을 갖습니다.
아래 표 2는 IP 버전 4와 6에 대한 주소 패밀리 숫자를 나타낸 것입니다. 다른 숫자가 할당되었더라도 실제로는 거의 사용되지 않습니다. ICANN(Internet Corporation for Assigned Names and Numbers)에 의해 할당된 목록에 대해서는 http://www.icann.org/를 참고하십시오. 표 2 IP 버전 4와 6의 주소 숫자
인코드된 그룹 주소인코드된 그룹 주소 필드 형식은 아래 그림 14에 나타나 있습니다.
그림 14 인코드된 그룹 주소 필드 형식 하위 필드들은 다음 값들을 갖습니다.
Encoded Source Address이 필드는 아래 그림 15에 나온 형식을 사용합니다.
그림 15 인코딩된 소스 주소 필드의 형식 하위 필드들은 아래와 같은 값들을 갖습니다.
Assert MessageAssert 메시지는 아래 그림 16에 나타난 형식을 사용합니다.
그림 16 Assert 메시지 형식 필드들은 아래와 같은 값들을 가집니다.
Bootstrap Message부트스트랩 메시지는 원본 메시지가 최대 패킷 크기를 초과할 경우 기능 조각으로 나뉩니다. 단일 조각의 형태는 그림 17에 나타나 있습니다.
그림 17 부트스트랩 메시지 형식 필드는 다음과 같은 값을 사용합니다.
Candidate RP MessageCandidate RP 메시지는 아래 그림 18에서 나타난 형식을 사용합니다.
그림 18 지원자 RP 메시지 형식 필드들은 아래와 같은 값들을 가지고 있습니다.
Hello 메시지메시지
그림 19 Hello 메시지 형식 필드들은 아래와 같은 값들을 가지고 있습니다.
아래 표 3은 옵션 필드의 값을 나타낸 것입니다. 표 3 옵션 필드 값
중단 시간 매개 변수에 대한 값은 표 4에 나타나 있습니다. 표 4 중단 시간 매개 변수 값
0xFFFF의 시간 제한 값은 인접한 값이 결코 만료되지 않는다는 것을 의미합니다. 이 값은 주기적으로 Hello 메시지를 보내지 않도록 합니다. ISDN에 의해 제공되는 관세 연결에 유용합니다. 주기적인 Hello 메시지는 사용자 데이터 트래픽이 없어도 연결을 활성화시키는 역할을 하므로 고객에 대해 지속적으로 청구할 수 있습니다. Join/Prune 메시지Join/Prune 메시지는 아래 그림 20에 나타난 형식을 사용합니다.
그림 20 Join/Prune 메시지 형식 필드는 다음과 같은 값을 갖습니다.
Register 메시지Register 메시지의 형식은 아래 그림 21에 나타나 있습니다.
그림 21 Register 메시지 형식 필드들은 다음과 같은 값들을 가집니다.
Register-Stop 메시지Register-Stop 메시지는 아래 그림 22와 같은 형식을 사용합니다.
그림 22 Register-Stop 메시지 형식 필드들은 아래와 같은 값들을 갖습니다.
현재 PIM-SM은 멀티캐스트 라우팅 프로토콜의 표준이라고 할 수 있습니다. PIM-SM은 멀티캐스트 그룹이 널리 분포되어 있는 WAN에서 효율적으로 작동하도록 구성되었습니다. PIM-SM은 기존 IP 멀티캐스트 서비스 모델인 수신자 미개시 모델을 유지하고 공유 및 최단 경로 트리 모두 지원합니다. PIM-SM은 특정 유니캐스트 라우팅 프로토콜에 의존하지 않습니다. 즉, PIM-SM이 라우터 대 라우터 프로토콜이므로 PIM-SM 버전 2를 지원하기 위해서는 네트워크의 모든 라우터들이 업그레이드되어야 합니다. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
'Network > IPTV' 카테고리의 다른 글
| 뉴미디어 방송서비스 품질 만족도 평가 (0) | 2008.07.23 |
|---|---|
| 2008 상반기 IPTV 시장, 하나TV ‘주춤’ 메가TV ‘꾸준’ (0) | 2008.07.21 |
| IPTV 이용시 인터넷 속도 저하 발생 (0) | 2008.07.17 |
| IPTV 표준화 동향 (0) | 2008.07.17 |
| IPTV STB 셋톱박스 셋탑박스 (0) | 2008.07.16 |
