PIM Sparse Mode

Layer 2 Multicast Addressing

IP Multicast MAC Address Mapping (FDDI and Ethernet) 

멀티캐스트의 l2주소(mac주소) 연구중 처음에는 01-00-5e 로 시작 하는 mac 주소를 쓰고 뒤에 24bit에 대하여 멀티캐스트 주소로 복사 하려 했으나

연구중 박사 과정 학생과 교수와의 마찰로 인하여 25bit 까지 그대로 쓰고 23 bit 를 멀티캐스트에서 mac 주소로 쓰게 되었다.

그렇기 때문에 24 bit 를 고정 하지 않고 25bit를 고정 하여 아래와 같이 32개가 같은 멀티캐스트 mac 주소가 중복 된다.

IGMPv1

 

- 멀티캐스트가 만들어 질떄 igmp v1 이 만들어 졌으며 지금은 거의 사용 되지 않는다.

IGMPv2

RFC 2236

Group-specific query

- Router sends Group-specific queries to make sure there are no members present before stopping to forward data for the group for that subnet

=>v1 에서는 특정 멀티캐스트 데이터가 들어오면 라우터에서 주기적으로 genral query 를  보내 받을 호스트만 query 에 대한 응답을 하여 받는 구조로 작동 하였다.

 즉, genral query 에 응답이 없을 때만 멀티캐스트 데이터를 호스트로 전달 하지 않았는데 v2 에서는 leave group message 를 통하여 원하지 않을 떄 멀티캐스트 데이터를 받지 않

을 수 있으며 ,  leave 메세지로 서비스를 종료하기전 , 해당 그룹을 서비스 계속 할 수 있는 장비가 있을수 있기 때문에

Group-specific query 를 통하여 원하는 경우에 멀티 캐스트 데이터를 받을 수 있는 구조가 되었다.(자세한 설명 아래 참조)

Leave Group message

- v1마지막에 만들어졌으며, 멀티캐스트 데이터를 받고 싶지 않을때 보내는 igmp message 

 Querier election mechanism

- On multi-access networks, an IGMP Querier router is elected based on lowest IP address.  Only the Querier router sends Queries.

=>  Querier election mechanism는 다수의 라우터가 동일한 igmp 메세지를 받으면 어느 라우터가 처리 할지 정하는 mechanism

 Query-Interval Response Time

- General Queries specify “Max. Response Time” which inform hosts of the maximum time within which a host must respond to General Query. (Improves burstiness of the responses.)

 

Backward compatible with IGMPv1

=> 이기능 외에 igmp v1 과 호환 된다.

IGMPv2—Joining a Group

아래와같이 3대의 호스트가 있는 구조에서 h2 가 224.1.1.1 멀티캐스트 서비스를 받기 위해 igmp report 로 요청 하게 된다.(join 을 하게 되는것)

해당 igmp report 를 받은 first hop router 는 해당 igmp report 를 받은 인터페이스를 OIL 로 두고 224.1.1.1  에대한 멀티캐스트 데이터가 들어올 경우 

OIL  로 전송 하게 된다. show ip igmp group 을 통하여 해당 report 를 보낸 장비를 와 들어온 인터페이스, 그룹을 확인 할 수 있다.

IGMPv2—Querier Election

만약 라우터가 2대 일 경우, 두대의 라우터는 224.0.0.1 모든 장비에게 igmp query 를 상대방에 보내서 누가 처리 할지 ,

igmp 가 들어온 인터페이스로 보낸다(igmp 로 들어온 인터페이스로 다른 

라우터가 연결 되어 있기 때문에 igmp 가 들어온 인터페이스 query 를 보낸다.)

qeury 를 보낸뒤 해당 query 를 서로 비교 하여 낮은 아이피를 갖고 있는 장비가 Querier 가 되어 Querier가 해당 igmp 에대한 join을 비롯한 처리를 하게 된다.

Querier가 안된 장비는 non-Querier 로 선출 된다.

show ip igmp 인터페이스 명령어로 해당 인터페이스에 대한 igmp 정보를 확인 하여, Querier 혹은 non-Querier 에 대한 정보 등을 확인 할 수 있다.

IGMPv2—Maintaining a Group

v1 에서는 서비스를 받을지 말지 라우터가 주기적으로 general query 를 보내서 확인 했다.

해당 query에 대하여 응답을  멤버중 가장 먼저 받은 장비가 응답을 하는데 , 이때 동시에도 받을 수 있다.

그렇기 때문에 repose time 을 query에 저장해서 보낸뒤 받은 장비는  repose time 을 18 등분 하여 그중 랜덤한 시간에 보낼 시간을 장비는 정한다.(like jam 신호)

그뒤 가장 빨리 report를 보낼수 있는 장비만 report message 를 보내고 나머지 장비들은 report message 를 보낼 필요가 없기 떄문에 아래 그림과 같은

중간에 스위치가 있는 구조에서는 suppressed 시켜서 동시에 보내지 않게 정한다.

.

IGMPv2—Leaving a Group

아래와 같이  rtr-a 라는 라우터가 224.1.1.1 멀티캐스트 그룹으로 1.1.11 이 report 요청으로 멀티캐스트 데이터를 포워딩 해주고 있다

실제로는 3대의 장비중 10 을 제외한 두대만 데이터가 포워딩 되고 있다.

만약 아래와 같이 report 를 요청했던 1.1.1.11 이 자신은 서비스를 받지 않기 위해서 v2 에서는 leave 메세지를 통하여,

더이상 서비스를 받지 않도록 할 수 있기에 라우터에게 224.0.0.2 모든 l3장비로 leave 메세지를 보낸다.

하지만 이때 같은 서비스를 받는 1.1.1.12 가 있기때문에서 라우터가 서비스를 종료 하면 1.1.1.12 가 서비스가 끊어 진다.

그것을 방지 하기 위해  leave 메세지를 받은 장비는 다시 한번 group specific query 를 224.1.1.1 로 보내고,  서비스를 계속 받아야 하는 

1.1.1.12 는 해당 query 를 보고 자신은 서비스를 계속 해야 하기 때문에 report 를 보내게 된다.

report 를 받은 라우터는 igmp group 의 report 정보를 1.1.1.12 로 변경 하여 서비스가 계속 될 수 있도록 한다.

만약, 1,1,1,12 또한 서비스가 종료 되면 동일한 방법으로 leave message 를 보내고 group specific query 에 응답이 없으면 멀티캐스트 포워딩을 종료 한다.

IGMPv2—Response Tuning

reponse에 대한 시간을 장비들은 reponse time 에18 등분 하여 해당 interval 에 report 를 보내게 된다.

아래와 같이 query 에 대한 응답 시간을 조절 할 수 있다.

변경된 inverval 시간은 show 명령어로 아래와 같이 확인 할 수 있다.

IGMPv3

- v3는 RP를 사용 하지 않고 사용 하는 구조를 갖기 위해 만들어 졌다.

- igmp v3 는 source 정보에 대하여 미리 설정 되어 설정 된 source 만 받고, 받지 않을 source 를 설정 한다.

미리 설정된 source 정보로 인하여 last hop router 는 처음 부터 (*,G) join 이 아닌, (s,G) join 을 하게 되어 SPT tree 를 좀더 빠르게 구성 하게 된다.

- 224.0.0.22 라는 igmp v3 report message 를 보내기 위한 멀티캐스트 주소가 할당 되어 있다.

 

- 이때 장비별로 source 를 선택 하기 때문에 v2와 틀리게 report 에 대하여 suppression 되지 않는 단점이 있다.

IGMPv3 Example

아래 그림과 같이 맴버가 224.1.1.1 에대하여 멀티캐스트 서비스를 받고 싶을때 224.1.1.1. 에 대하여 잘못 포워딩 되고 있는 정보가 있을 경우

충돌이 날 수 있다. 이때 igmp v3 는 원하는 source 만 받기 때문에 잘못 포워딩 되는 정보에 대하여 수신 하지 않는다.

IGMPv3—Joining a Group

호스트는 224.0.0.22 라는 igmp v3 메세지를 통하여 last hop router 에 v3 report message 를 보내 join 할 수 있게 된다.

이떄 incluede(허용),exclude(비허용) 정보가 없으면 v2처럼 작동 하게 된다.

IGMPv3—Joining specific Source(s)

 

include 를 통하여 아래와 같이 특정 source 에서만 받게 설정 하여 멀티캐스트 데이터를 수신 한다.

IGMPv3—Excluding specific Source(s)

exclude 를 통하여 특정 source 에 대하여 받지 않게 설정 할 수 있다.

IGMPv3—Maintaining State

v2와 틀리게 v3 는 source 에 대한 정보가 모두 틀리기 때문에 suppres 되지 않는다.

L2 Multicast Frame Switching

Problem: Layer 2 Flooding of Multicast Frames

=> 멀티캐스트의 가장큰 문제점중 l2 에서 모두 flooding 하는 문제점이 있다.

Solution 1: IGMP Snooping

- 스위치가 IGMP메세지를 읽어서 ASICs 에 의하여 하드웨어 적으로 처리한다.

아래와 같이 스위치에서 host1과 4번이 통신 하는 경우 스위치는 mac 주소를 학습하여 해당 mac 주소에 대한 정보와 포트를 테이블에 저장 한다.

그리고 추후 포워딩 될때 테이블을 보고 포워딩 하게 된다.

만약 host 1에 2번 인터페이스를 통하여 igmp report 메세지를 보낼 경우 해당 224.1.2.3 에 대한 아이피의 mac 정보를 

모르기 때문에 전체 포트로 flooding 된다.

그렇게 되면 멀티캐스트를 처리 하기 위해  멀티캐스트 주소가 들어오면 cpu 로 전달 해서 저장 한다.

(이때 스위치는 항상 0번 포트에 대하여 cpu로 가는 포트로 인식 하기 때문에 0번 포트와 1,2 포트가 저장이 된다.)

그후, 5번 포트로 igmp report 가 발생 되면 다시 cpu 에도 동일하게 저장된다.

해당 멀티캐스트 정보가 5번포트도 추가 되었다.

이상태에서 멀티캐스트 데이터가 들어오면 정상적으로 처리는 되나 ,CPU로 처리 되기 떄문에 CPU에 대한 부하가 많이 발생 된다.

CPU적으로 처리 하는 것을 보완 하고자, L3기능 을 하는 ASICs 을 이용 하여 하드웨어 적으로 처리하기로 했다.

0100.5~ 로 시작 하는 mac 주소에 대하여 igmp 로 들어 오는 정보만 igmp entry 에 저장 하도록 한다.

만약 mac주소는 맞지만 , igmp 가 아닌 경우 entry 에서 저장 하고

igmp 만 cpu 가 처리 하도록 하여 igmp report message 가 들어오면 cpu 를 거쳐서 처리 하도록 한다.

igmp 가 아닌 경우 asic 에 의하여 하드웨어 적으로 포워딩 된다.

Solution 2: CGMP—Cisco Group Multicast Protocol

cisco 전용 기술로 last hop router와 스위치 간 cgmp join을 통하여 라우터가 스위치에게 멀티캐스를 전달할 호스트의 mac 정보를 전달,

스위치는 해당 mac 으로만 포워딩 할 수 있도록 한다.

아래와 같이 igmp report message 에는 mac 주소 정보가 있기 때문에 스위치에게 mac 주소를 전달 할 수 있다.

cgmp 가 join 되어 있는 경우 아래와 같이 특정 호스트가 igmp report message 를 보내게 되고 

해당 report 를 받은 라우터는 스위치에서 mac 정보를 전달 하게 된다.

해당 mac 정보를 받게 된 스위치는 해당 멀티캐스트 mac 과 호스트의 정보를 entry 에 저장 하게 되며 

추가적인 report 가 발생 하면 

또다시 entry 에 저장 하게 된다.

최종적으로는 해당 멀티캐스트 mac 주소에 대한 정보가 라우터에 의하여 학습되게 된다.

멀티캐스트 정보가 발생 하면 cpu 를 거치지 않고 바로 포워딩 되게 된다.