Fundamentals of IP Multicast

Why Multicast?

=>하나의 회선에 하나의 패킷만 보내서 받고자 하는 장비에 모두 보내는것

=>multiple receivers가 같은 데이터(패킷)만 보내서 호스트(PC)나 라우터의 부하를 줄이고, 하나만 보내기때문에 낮은 대역폭을 사용 할 수 있다.

=> receivers 의 아이피는 알 필요가 없다 (경로가 여러개 있을때 요청한  인터페이스로 보내기때문에 클라이언트의 아이피는 의미가 없다.)

Unicast vs Multicast

아래와 같이 유니캐스트시에는 각각의 장비들로 각각의 패킷을 보내기 때문에 장비의 부하와 , 대역폭에 문제가 생기지만 

멀티캐스트는 유니캐스트의 문제를 해결 할 수 있다.

하지만 VOD서비스와 같은 요청에 의한 처리는 멀티캐스트로 불가능 하기 때문에 멀티캐스트는 리얼타임 프로토콜( 실시간 방송)에 많이 사용 된다.

리얼타임 프로토콜은 UDP를 이용한 멀티캐스트를 사용 하지만, TCP를 이용한 멀티캐스트을 사용 하기도 한다.(데이터 유실이 안되는 경우)

Multicast Advantages

멀티캐스트를 사용시,  네트워크의 트래픽 제어 및 cpu부하를 감소 시키며,  Distributed Applications  낮은 load로 사용 된다.

=> 사용자가 많든, 적든 변화 없이 사용 할 수 있다.

Downloading MBone Applications

(MBone : 멀티캐스트 백본 테스망)

사용 용도를 테스트 하기 위해서 MBone 이라는 백본망을 만들었으며, 2009년도에 중지 되었다.

sdr,vat,vic,wb 등 을 테스트 하기 위해 사용 되었음

아래 URL 에서 각  소스가 공개 되어 있음

- URL:  http://www-mice.cs.ucl.ac.uk/multimedia/software/

- Multiple platform support

 SunOS, Solaris, HP, Linux, Windows 95/98/2000, Windows NT, etc.

- Source code

IP Multicast Service Model

- RFC 1112에서 명시 되어 있으며, D클래스를 사용 한다.

- 한개의 멀티캐스트 아이피가 한개의 서비스를 진행 할 수 있다.( ch 11 mbc, 등등...하지만 igmp v3 를 이용 하면 다중 서비스를 진행 할 수 있다.)

=> 이때 한개의 서비스가 그룹으로 불린다. 이때 그룹에 join 을 하면 해당 서비스를 사용 할 수 있으며, leave 되면 서비스를 중지 시킬 수 있다.

- 그룹에 join 한 호스트느는 맴버라고 불리며, 그룹의 맴버(멀티캐스트 주소) 는 인터넷 어디에서든 수신 할 수 있다. 

- sender /receivers  는 구분 할 필요는 없으며,는 맴버가 될 필요가 없다.

- 라우터가 어떠한 멀티캐스트 가 있는지, 맴버가 있는지 체크 한뒤 해당 그룹으로 전달 하는데, 이때 최적의 경로로 패킷을 포워딩 한다.

IP Multicast Service Model

IP group addresses

-Class D address—high-order 3 bits are set (224.0.0.0)

224.0.0.0 ~239.255.255.255 아이피 대역을 멀티캐스트 대역으로 사용 한다.

Well known addresses designated by IANA

- Reserved use: 224.0.0.0 through 224.0.0.255 (시스템이 사용 하는 표준 프로토콜로 사용 하기 위해서 예약 되어 있으며, TTL이 1로 설정 되어 있다.)

   224.0.0.1 — all multicast systems on subnet (-> 모든 디바이스)

   224.0.0.2 — all routers on subnet (-> 서브넷에 있는 모든 L3장비)

   224.0.0.13 - PIM

   관련 링크:  “ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses”

 

Transient addresses, assigned and reclaimed dynamically

- Global scope: 224.0.1.0-238.255.255.255 (공인 멀티캐스트 대역대로 , TTL 255 어디든지 보낼수 있다.)

- Limited Scope: 239.0.0.0-239.255.255.255 (사설 멀티캐스트 대역)

    Site-local scope: 239.253.0.0/16 (TTL 16)

    Organization-local scope: 239.192.0.0/14(TTL 32)

    -> 사설로 사용 하면서 , 내부에서 사용 할때 TTL 16, 혹은 32로 되어 있는 사설 대역대를 사용한다.

    -> 예전에 개발되어 현재는 사설의 의미가 없음-> TTL 16이면 왠만한 인터넷으로 다 연결 될 수 있기 때문에

IP Multicast Addressing

정적 그룹 주소 할당

- ISP 에서 멀티캐스트 주소 할당시, 아이피 중복을 막기 위해 아래와 같은 규칙으로 설정 되서 중복을 막는다.

- Group range: 233.0.0.0 - 233.255.255.255

 첫번째 옥탯이 233 으로 시작되어 중간 2개의 옥택에 AS번호 마지막 옥택에 할당한 멀티캐스트로 멀티캐스트 중복을 막을수 

있도록 IETF 에서 선언 되었다.

=> 하지만, ISP망에서 IPTV망만 enable 되어 있으며 아직 일반 서비스를 위한 멀티캐스트는 isp 에 enable 되지 않았다.

Multicast Protocol Basics

- 멀티캐스트는 아래 3가지 프로토콜을 이용 한다.

1) Multicast Distribution Trees

2)Multicast Forwarding

3)Types of Multicast Protocols

  Dense Mode Protocols

  Sparse Mode Protocols

Multicast Distribution Trees

1.Source Distribution Tree

- 소스에서 가장 가까운 경로로 포워딩 하는 tree 구조 

Source 에서 receiver 로 멀티캐스트로 전송 하는 경우,  멀티캐스트가 enable 되어 있는 장비들로 멀티캐스트 데이터를 보내는데 

아래와 같은 구조에서 라우터가 여러대로 연결 될 경우에는 중복되는 데이터를 받을 수가 있다. 그럴 경우 receiver 는 제대로된 멀티캐스트 데이터를 받지 못하고 

중복된 멀티캐스트 데이터를 받을 수도 있다.

이때, 멀티캐스트가 enable 되어 있는 장비에서 해당 장비는 멀티캐스트 데이터를 보낸 소스 아이피 기준으로 라우팅 테이블에서 BEST 인것만 받으며,

만약 로드밸런싱으로 다중 경로 일 경우 아이피 높은 것만 받아, 중복되는 것을 막아서 tree를 그려서 포워딩 하는 구조 

Shortest Path 또는 Source Distribution Tree 라고 부른다.(=SPT)

이럴 경우 멀티캐스트 장비들은 소스아이피를 보고 처리 해야 하기 때문에 장비 부하가 생기지만,  RP가 필요 없다.

2.Shared Distribution Tree

- source 가 어디 있던지, 모든 멀티캐스트 데이터는 RP를 통해서 경로를 share 하는 tree 구조

경로를 share 하여, source 는 RP로만 데이터를 전송 하여 같은 경로를 통해서 멀티캐스트 데이터를 받을 수 있다.

이떄 멀티캐스트를 총괄 하는 Rendezvous Point(RP)를 통해서 서비스를 받는 

아래 그림과 같이 소스 아이피상관 없이  RP(PIM Rendezvous Point) 가 D 로 설정 되어 D만 recevier 로 전달하는 tree 구조

Shared Distribution Tree 라고 부르며 SDT라고도 부른다.

이런 경우 C와 E같은 경우는 소스의 아이피를 확인 할 필요 없이 멀티캐스트를 받기만 하는 장점이 있지만, RP가 반드시 존재 해야 한다.

이때, source 는 rp 에게 멀티 캐스트 데이터를 보내게 된다.

Distribution Trees 특징

 1)Source or Shortest Path trees

Shortest Path trees 는Source 에 따라서 (S x G) 테이블이 메모리에 저장 되어 source 별로 테이블이 생성된다 .

이럴경우 최적의 경로로 패킷이 포워딩 되어 딜레이가 적게 된다,

*(S.G): soruce group 관리 

 2)Shared trees

Shared trees 는 source 주소상관 없이 멀티캐스트의 갯수 만큼만 메모리에 저장 되어 그룹의 갯수만큼만 테이블이 저장 된다.

랑데뷰 포인트로만 가기 떄문에 딜레이 많이 생길 수 있다.

*(*,G): source는 상관없이 group 만 관리 

Multicast Forwarding

멀티 캐스트 라우팅은 유니캐스트 라우팅의 반대의 개념이다.

유니캐스트 라우팅은 해당 패킷을 어디로 보내는지 Destination 아이피를 보고 최적의 경로로 선택 한다.

멀티캐스트 라우팅은 패킷이 어디서 들어오는지 Source 아이피를 보고 최적의 경로를 선택 한다.

(  이때 , out going interface 가 다수가 될 수 있기 때문에 out going list ->ogi 라고도 부른다.)

Multicast Routing uses “Reverse Path Forwarding”

멀티캐스트 라우팅은  유니캐스트와 반대의 개념이기 떄문에 Reverse Path Forwarding(RPF)을 사용 한다.

(최근에는 유니캐스트로도 사용이 되는 경우도 있다.=> ip 스푸핑 공격시 사용 )

Reverse Path Forwarding (RPF)

What is RPF?

- RPF는 출발지 source 정보를 확인 하여  upstream(↔down stream) 방향을 체크하여 RPF체크를 한다. 

- The RPF Check멀티 캐스트 데이터가 들어오면 RIB를 보고,RPF를 RIB를 보고 체크하는데 성공시, 체크, 실패시 fail 이 된다,

- RPF Check 에 성공하면 요청한 인터페이스로 포워딩 하고 실패하면 무시 하게 된다.

- 모든 인터페이스로 포워딩 하지 않고 받고자 하는 인터페이스로만 포워딩 하는데 이 인터페이스를 OIL (out-going interface list) 라고 한다

RPF Check 에 성공한 인터페이스를 IIF(in-coming interface)라고 하며 IIF에게는 포워딩 하지 하지 않는다.(IIF 는 OIL 에 올라 가지 않는다.)

Example: RPF Checking

아래 그림과 같이 멀티캐스트 데이터를 받으면 RPF체크를 시작 한다.

A closer look: RPF Check Fails

아래와 같이 멀티 캐스트 RPF check 를 하여, 여러 인터페이스로 받아서 

RIB와 비교 , BEST가 아니면 RPF check를 fail 한다. 이럴 경우 해당 패킷 은 drop 된다.

A closer look: RPF Check Succeeds

check 시 성공이 되면  OIL 인터페이스로 포워딩 한다.

TTL Thresholds

What is a TTL Threshold?

- A “TTL Threshold” may be set on a multicast router interface to limit the forwarding of multicast traffic to outgoing packets with TTLs greater than the Threshold.

The TTL Threshold Check

1) All incoming IP packets first have their TTL    decremented byone.  If <= Zero, they are dropped.

2) If a multicast packet is to be forwarded out an    interface with a non-zero TTL Threshold; then it’s TTL    is checked against the TTL Threshold.  If the packet’s TTL    is < the specified threshold, it is not forwarded out the    interface.

A closer look: TTL-Thresholds

아래 그림과 같이 TTL값이 24로 들어올경우 Threshold를 적용 하여 해당 인터페이스의 Threshold 보다 높은 경우에 포워딩만 한다.

Administrative Boundaries

ttl Threshold 보다 아래 그림과 같이 acl 적용하여 차단하는 방법을 더 많이 사용 한다.

 Configured using the ‘ip multicast boundary <acl>’ interface command

Types of Multicast Protocols

Dense-mode

-  push 모델을 사용 한다.(밀어 넣는 방식)

-  멀티캐스트가 들어 오면 전체로 플러딩 되며, 만약 플러딩 받기 싫은 장비는 Pruned 를 보내 받지 않으며, 3분마다 작동 한다.

Sparse-mode

- Pull 모델을 사용 한다.(필요한것만 요청하여 당겨 받는 방식)

- 요청 오는 것만 처리 한다.(Explicit Join behavior=>명확한 join )

Multicast Protocol Review

Currently, there are 4 multicast routing protocols:

(x) DVMRPv3 (Internet-draft)

(x) DVMRPv1 (RFC1075) is obsolete and was never used.

(x) MOSPF (RFC 1584) “Proposed Standard”

PIM-DM (Internet-draft)

(x)CBT (Internet-draft)

PIM-SM (RFC 2362) “Proposed Standard

PIM-DM

-  프로토콜 상관 없이 별도의 테이블 없이 라우팅 테이블만 보고 포워딩 

 - 하지만 DM(dence mode) 이기 때문에 모두 flood 하고, pruned 를 보내 원하는 장비만 받을수 있도록 한다.

- 이중화 구조시 ,assert 메카니즘이 필요로 한다.

- 데이터를 모두 flood 하기 떄문에, 큰 네트워크 토폴로지 보다, 작은 네트워크의 토폴로지에서 사용 된다.

DENCE MODE EX)

Initial Flooding

source 가 receiver 에게 멀티캐스트를 보낼 경우  first hop router (제일 먼저 받는 라우터) , last hop router (destination 네트워크가 있는 라우터) 를 확인 ,

멀티캐스트들어오면 (s,g) 데이터를 볼 수 있다. 생성 된다

Pruning unwanted traffic

(s,g) 데이터를 보면 source 의 주소를 알 수 있기 떄문에 중간에 포워딩 하는 멀티캐스트 라우터들은  RPF체크를 하여

해당 source 의 아이피가 BEST 가 아닌 경우 fail 이 발생 하면 prune 메세지를 보내어 해당 인터페이스로 멀티캐스트 데이터를 수신 하지 않도록 요청 한다.

만약 이떄 스위치가 중간에 있는 멀티 엑세스 환경에서 멀티캐스트 데이터를 받아야 하는데 prune 메세지가 온 경우 자신은 멀티캐스트 데이터를 보내지 않았는데

prune 을 받아서, 자신에게는 멀티캐스트를 받아야 함으로, prune cancel 메세지를 3초 이내에 보내서 멀티캐스트를 받을 수 있도록 한다.

Results after Pruning

prun 메세지로 인하여 멀티캐스트를 보내지 않는 인터페이스를 제외한 나머지 인터페이스로 bset path 를 알게 되어 IIF 를 알게 되고

멀티캐스트 패킷이  OIL로 포워딩 된다. 이때 S,G 테이블은 3분이 지나면 초기화되므로, 3분마다 이러한 동작을 반복 한다.

## pim-dense-mode test lab

## 위 토폴로지에 모든 인터페이스에 아래와 같이 pim dense-mode 를 인터페이스에 enable 한다.

R10(config)# ip multicast-routing

R10(config)#inte e 1/7

R10(config-if)# ip pim dense-mode

#destination 이 되는 네트워크에 join 그룹을 추가 한다.

R10(config)# ip multicast-routing

R10(config)#inte e 1/7

R10(config-if)# ip pim dense-mode

R10(config-if)#  ip igmp join-group 224.1.1.1

R4(config)# ip multicast-routing

R4(config)#inte e 1/7

R4(config-if)# ip pim dense-mode

R4(config-if)#  ip igmp join-group 224.1.1.1

## R1에서 224.1.1.1 로 ping 테스트시 응답을 join 한 장비만 하는 것을 확인 할 수 있다.

R1#ping 224.1.1.1 repeat 1000

Type escape sequence to abort.

Sending 1000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:

Reply to request 0 from 10.10.109.10, 108 ms

Reply to request 0 from 10.10.200.4, 144 ms

## show ip mroute 를 통해서 S,G 테이블을 확인 할 수 있다.

R10#show ip mroute

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry,

       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

       U - URD, I - Received Source Specific Host Report,

       Z - Multicast Tunnel, z - MDT-data group sender,

       Y - Joined MDT-data group, y - Sending to MDT-data group

Outgoing interface flags: H - Hardware switched, A - Assert winner

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:10:10/stopped, RP 0.0.0.0, flags: DCL

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    Ethernet1/4, Forward/Dense, 00:06:50/00:00:00

    Ethernet1/7, Forward/Dense, 00:10:10/00:00:00

(10.1.1.1, 224.1.1.1), 00:06:41/00:02:59, flags: LT

  Incoming interface: Ethernet1/4, RPF nbr 10.10.109.9

  Outgoing interface list:

    Ethernet1/7, Forward/Dense, 00:06:41/00:00:00

(10.10.100.1, 224.1.1.1), 00:06:41/00:02:59, flags: LT

  Incoming interface: Ethernet1/4, RPF nbr 10.10.109.9

  Outgoing interface list:

    Ethernet1/7, Forward/Dense, 00:06:41/00:00:00

(*, 224.0.1.40), 00:10:10/00:02:55, RP 0.0.0.0, flags: DCL

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    Ethernet1/4, Forward/Dense, 00:06:51/00:00:00

    Ethernet1/7, Forward/Dense, 00:10:11/00:00:00

PIM-DM Assert Mechanism

s1) 만약 아래 그림 과 같이 이중화된 구조에서 멀티캐스트를 포워딩 하는 경우 서로 멀티캐스트 데이터를 포워딩 할 , OIL 에서 동일한 멀티캐스트 데이트를 

받게 된다.

2) 동일한 멀티캐스트틑 받지 않기 위해서 서로 라우터들은 assert메세지를 보내 서로의 OIL로 멀티캐스트 데이터를 포워딩 하는 것 을 잠시 멈춘다.

PIM ASSERT MESSAGE 에는 서로 간의 best경로에 대한 ad와 metric 정보가 있다,

3) 해당 ad와 메트릭을 비교 , 낮은 수치가 winner가 되어 winner 만 포워딩 하게 된다. AD와 metric 이 동일 할 경우 아이피가 높은것 만 유지된다.

PIM-DM Assert Problem

아래와 같이 중복되는 트래픽을 받는 이중화 구조가 발생 하게 되면 아직 assert message 를 보내지 않고 포워딩을 시작 한다.

서로의 라우터에서 OIL 로 멀티캐스트 데이터가 들어 오는 것을 확인 하면 서로 ad와 아이피, 메트릭 정보를 보내게 되어 

pim assert메세지를 보내 winner 와 loser를 선출, winner 만이 포워딩 하게 된다.

loser는 아래와 같이 IIF로 멀티캐스트 데이터를 받지만 포워딩 하지는 않는다.

하지만 , winner 가 down 시 loser 로 바로 포워딩을 하지 않고 S,G를 3분마다 체크 하기 떄문에

백업이 빠르게 동작 하지 못하는 단점을 가지고 있다.

PIM-DM — Evaluation

작은네트워크에서는 효율적이지만 , 큰네트워크에는 효율적이지 못하다.

동작 방식은 간단 하지만 지속적인 flood 가 발생됨 

Advantages:

 커맨드가 간단하게 들어 간다.

Potential issues...

(S,G) 에 의하여 동작 되기 떄문에 복잡한 알고리즘이 작동 한다.

이중화 복구시 딜레이 시간이 최고 3분 까지 발생 한다.

shared tree 를 제공 하지 않는다.(단점이라고 하지만.. cisco에 나왔음)

PIM-SM (RFC 2362)

요청한 장비에게만 트래픽을 전달 한다.

소스아이피와 클라이언트간 연결을 해주는 포인트 RP를 선출 하여, RP를 통하여 데이터를 포워딩 한다.

- Senders는  멀티 캐스트 데이트를 보내기 위해 선출된 RP에서 regist (등록)을 하는데 이떄 sender 가 보낸 멀티캐스트 데이터를 처음 받는 장비가 

first hop router 가 되는데 이 first hop router 가 RP에게 unicast 로 regist 하게 된다.

이떄 유저(reciver)는 RP로 join 되어 RP와 연결 되고 RP가 최적의 경로를 알려 주게 되어 멀티캐스트 데이터를 보내는 방식이다.

(자세한 내용은 다음 쳅터에서 설명)

Appropriate for…

- 불필요한 flood 가 없기 때문에 enterprise 네트워크에서 사용 할 수 있다.

- Optimal choice for all production networks regardless of size and membership density.

- 맴버쉽에 위치에 상관 없이 가장 최적의 경로로 멀티캐스트 데이터를 보낼 수 있다.

PIM-SM Shared Tree Joins

- pim-sm 은 RP가 선출 되면 receiver 는 igmp report 메세지를 보내서 라우터에 join 한다.

해당 join 된 라우터는 source 를 모르기 떄문에 (*,G) 라는 테이블이 생성 된다.

그리고 해당 라우터는 source 를 모르기 때문에 라우터는 RP에게 join 해야 하는데 RP까지 가장 가까운 경로의  pim 네이버 에게 (*,G) 를 보내 pim join을 하게 된다 .

(pc 혹은 서버와 멀티캐스트 라우터는 igmp 로 join 하지만 멀티 캐스트 라우터들 간에 join 은 pim join 을 한다.

pim join 은 RP를 찾아 가기 위한 (*,G) join 과 source 주소를 알고 있는 source 까지 가기 위한  (s,g)join 두가지가 있다.)

pim join을 하게 되면 해당해당 igmp를 받은 라우터는  는 igmp report message 를 받는 인터페이는 OIL ( 해당 인터페이스로 멀티캐스트 데이터를 포워딩 해야 하기 때문에)

로 선출 되고 pim join 을 한 인터 페이스는 IIF로 선출 되어 IIF로만 멀티 캐스트 데이터를 받게 된다.

pim join이 된 네이버는 RP까지 pim join 되게 되고 RP에서 pim join 되면 RP는 자신이 RP이기떄문에 (*,G) 테이블에 IIF 를 NULL, PIM join 이 들어 온 인터페이스를

OIL 로 선출 하여 테이블에 올린다.

이렇게 RP에서 first hop router 까지 연결 된 상태가 되면 fisrt hop router 가 RP까지 가는 shared tree 가 생성 되게 된다.

PIM-SM Sender Registration

RP와 receiver 간의 shared tree 가 생성되어 RP로 멀티캐스트데이터가 들어오면 receiver 로 보내줄  준비가 되었다.

이상태에서 source 멀티캐스트를 보내면 source 가 보낸 멀티캐스트 데이터를 처음 받은 first hop router 는 source 주소와 멀티캐스트 주소(G)를 알고 있는데,

RP에게 등록 (regist ) 하기 위해 first hop router 는 기존 멀티캐스트 데이터에 l3해더를 추가 하여, RP에게 유니캐스트로 보낸다 .

이떄 추가된 해더에는 source 주소가 first hop router , destination 주소가 RP주소가 되어 RP가 해당 데이터를 받으면 L3 헤더를 열고, 멀티캐스트 데이터를 보는데,

이때 해당 데이터에 source 가 처음 보낸 source 의 아이피, destionation 에 멀티캐스트 주소를 알게 된다.

추가된 L3헤더를 빼면 멀티캐스트 데이터 이기 때문에 RP는 멀티캐스트 데이터를 shared tree 를 이용하여 receiver 에게 전달 하여 멀티캐스트 데이터를 전달한다.

또한,  RP는 first hop router 와 uni cast 로 계속 통신 할 수 없기 때문에 , RP는 source 쪽으로 (s,g) join 을 한다.(source 정보를 알고 있기 때문에 )

즉, RP는 source 까지 join 하여 souce tree 가 완성 된다.

source tree 가 완성 되면 더이상 unicast 로 통신 할 필요가 없기 때문에 souce 쪽으로 refister-stop 메세지를 보내 source 에서 regist 하지 않고 

source tree 를 이용 하여RP까지 데이터를 전송 하게 된다.

아래와 같이 트래픽이 RP를 통하여 receiver 에게 전달되는 flow를 확인 할 수 있는데 아래 flow 는 최적의 경로로 포워딩 되는 것이 아니다.

단순히 RP 를 통한 포워딩일 뿐 최적의 경로는 아닌데 , 이때 포워딩이 됬으며 receiver 에서 가장 igmp join 을 받은 last hop router 는 

포워딩 된 데이터를 보고 source 의 주소를 알 수 있다.

PIM-SM SPT Switchover

last hop router는 source 정보를 알고 (s,g)join 을 source 까지 bset path 로 join 하여 SPT tree 를 생성 한다.

SPT tree 가 생성 되면 기존 tree 에서 spt 와 틀린 경로의 인터페이스로 받는 라우터에게 prune 메세지를 보내 SPTtree 를 통한 

멀티캐스트 데이터 포워딩이 완료 된다 .

(이때 , RP로 가는 shared tree 에서 last hop router 만 (s,g) join 을 하는 이유는 중간 장비가 join을 해서 경로가 바뀌는 경우 

last hop router 까지 가는 경로의 다른 장비들도 s,g join 을 하게 되어 멀티캐스트 데이터를 중복으로도 받을 수 있기 때문이다.)

최종적으로는 아래와 같은 트래픽 flow 가 되는데 , RP는 결론적으로는 source 를 알려주는 역할을 통하여 SPT tree 를 그려주는 역할을 한다.

(단, igmp v3 에서는 ssm 기술을 통하여, source 정보를 last hop router 에게 전달하여 처음부터 s,g join 을 할 수 있도록 한다.)