멀티캐스트 정리 #2 (IGMPv2 & IGMPv3)

Layer 2 Multicast Addresses

  멀티캐스트 정리 #1에서 multicast의 IP 주소 범위는 224.0.0.0 ~ 239.255.255.255라고 설명했는데 Layer 2에서는 multicast가 어떻게 동작할까? 멀티캐스트 group address는 special MAC address와 매핑 되어있다. 우선 상위 3 octet (24-bit)는 01-00-5E로 고정되어있다. 그리고 아래 그림 처럼 25번째 bit는 무조건 0으로 고정된다. 따라서, 표현할 수 있는 bit의 수는 23bit가 된다.

  그렇다면 multicast에서 사용하는 IP는 어떨까? IP 주소는 32bit로 구성되어 있고 첫 4bit는 1110으로 고정되어있다. (IP 주소가 224.0.0.0 ~ 239.255.255.255) 그러면 multicast에서 사용할 수 있는 unique한 IP 주소는 28bit가 된다. 28bit로 구성된 multicast IP address를 23bit의 MAC 주소로 매핑하게 되고 1:1로 매핑되지 않아 서로 다른 multicast IP를 가지지만 동일한 MAC address가 매핑되는 문제가 생긴다. 다시 말하면, 32개의 multicast IP address는 1개의 MAC address와 매핑된다.

  우선, 매핑 방법에 대해 간단히 알아보자. 우선, first byte는 individual/group bit (I/G) 또는 unicast/multicast bit이다. 1로 세팅되었을 경우 multicast frame으로 간주하며 25번째 bit는 언제나 0으로 세팅한다. 즉, 25번째 bit까지는 동일하며 그 이후의 bit는 multicast IP 주소의 bit를 그대로 복사하여 사용한다. 

  위의 매핑 방식을 통해서 PC에서 239.255.1.1로 IGMP join을 시도하면 NIC에서는 01-00-5E-7E-01-01로 변환하여 해당 정보를 수신할 수 있게 재 프로그래밍 한다. 즉, 224.0.0.5 (OSPF update, 01-00-5E-00-00-05)가 PC로 수신된 경우 CPU로 이 정보를 전달하지 않고 NIC에서 패킷을 drop한다.

 

Internet Group Management Protocol (IGMP)

  IGMP 프로토콜은 multicast를 수신하는 host에서 multicast group에 join하고 이 그룹에서 traffic을 받을 때 사용한다. 물론, IGMP를 사용하기 위해서는 host에서도 IGMP를 지원해야 하며, multicast group에 join해서 multicast traffic을 수신하려면 IGMP join 메시지를 router로 보내면 된다. 물론, router interface에 IGMP가 enable 되어있지 않다면 해당 join message는 무시된다.

 

  [IGMPv2]

IGMPv2의 메시지는 TTL을 1로 세팅해서 전송한다. 그 이유는 TTL이 0이 된 경우 그 패킷은 discard되는데 IGMP를 메시지를 수신한 rotuer에서 다른 router로 포워딩 할 필요가 없기 때문이다. IGMP 메시지의 구성은 아래와 같다. 

Type은 크게 아래와 같이 정의 되어있다.

 

  1) Membership Query (0x11) - 두 개의 sub-type이 존재하는데 하나는 General Query이고 다른 하나는 Group-specific Query이다. General Query는 같은 네트워크 내에 존재하는 memeber를 체크하기 위해 사용되며 multicast reserved IP address인 224.0.0.1을 사용한다. 이 때 group adress field는 0.0.0.0으로 설정되어 주기적으로 보내진다. Group-specific Query는 group addres field는 IP packet의 목적지 IP address가 되며 특정 그룹에 member가 있는 확인하는 용도로 쓰이며, leave group message에 대한 응답으로 host가 leave를 요청한 group으로 query가 된다.

  

  2) Version 2 membership report (0x16) - IGMP join으로 간주되고 host가 multicast 서비스를 이용할 때 사용된다.

  3) Version 2 leave group (0x17) - Join된 그룹에서 더 이상 multicast traffic을 수신하고 싶지 않을 경우 해당 type을 지정하여 사용한다.

  4) Version 1 membership report (0x12) - IGMPv1과 호환을 위해 사용

 

Max Resp Time은 Type이 0x11로 지정된 경우 (General and Grou-specific Query)만 사용되고 그 외엔 0x00으로 설정하여 전송된다. 이 것은 0.1초 단위로 설정 가능하며 host가 query에 대해 응답해야 하는 최대 시간을 설정하는 값이다. 10초가 기본값이다.

 

Checksum은 multicast traffic을 송신할 때 계산되어져야 하며 host는 이 값을 처리하기 전 검증해야 한다. IGMP 전체 message에 대해 1의 보수를 합하고 그 결과를 1의 보수 취한 값이 checksum이 되며 이는 TCP/IP에서 사용되는 표준 checksum 알고리즘을 따른다.

 

Group address는 앞서 설명한 것처럼 General Query를 보내는 경우 0.0.0.0으로 설정되고 그 이외엔 specfic한 group IP address로 설정된다.

 

  Host에서 multicast stream을 수신하기 위해 IGMP join 메시지를 (*참고 - IGMP RFC에 따르면 IGMP membership report가 정확한 용어이나 현장에서는 IGMP join을 통상적으로 사용) local router로 보내면 이 request를 multicast source로 PIM join 메시지를 다시 보낸다. local router가 multicast stream을 수신하면 이 것을 host가 요청한 interface로 전달한다. 이후, router는 주기적으로 general membership query를 보내게 된다. 이 query에 대한 응답으로 host는 random한 타이머 값 (0 ~ 10)을 설정 후, 이 타이머가 만료되면 membeship report를 보낸다. 만약 어떤 host가 random timer가 돌고 있는 중에 다른 host가 보낸 membership report (IGMP join)를 수신하면 해당 timer를 멈춰 불필요한 report가 전달되지 않도록 한다.

  host가 group을 leave하고 해당 host가 그룹내에 마지막 수신자였다면 224.0.0.2 group address를 설정해 leave group message를 router로 보낸다. (마지막 수신자가 아니라면 별도의 message 없이 group을 leave 함). Leave group message를 수신한 router는 이 때 specific-group membership query를 group multicast address로 보내 더이상 수신자가 없는 확인 후 해당정보를 router에서 삭제한다. 

 

  [IGMPv3]

IGMPv2에서는 membership report를 host에서 보낼 때, 어떤 source로 부터 multicast traffic을 받고 싶은지 명시하지 않는다. IGMPv3는 IGMPv2의 확장 개념으로 multicast source filering 기능이 추가되었다. IGMPv2와 v3의 차이는 IGMPv3에서는 membership query에 새로운 filed의 추가와 Version 3 membership report message type이 추가이다. Version 3 membership report에는 두 가지 mode가 있다.

 

Include mode는 host (멀티캐스트 수신자)는 어떤 source로 부터 multicast traffic을 받고 싶은지에 대한 source address의 리스트를 제공한다. 반대로 Exclude mode는 multicast traffic을 받고 싶지 않는 source에 대한 정보를 제공한다. 만약, IGMPv2처럼 모든 source로 부터 수신하는 경우라면 exclude mode를 사용하고 source를 제공하지 않아도 되는 정보를 비워두면 된다. IGMPv3는 Source Specific Multicast 서비스 방식에서 사용된다.

 

IGMPv2에서는 membership report를 host에서 보낼 때, 어떤 source로 부터 multicast traffic을 받고 싶은지 명시하지 않는다. IGMPv3는 IGMPv2의 확장 개념으로 multicast source filering 기능이 추가되었다. IGMPv2와 v3의 차이는 IGMPv3에서는 membership query에 새로운 filed의 추가와 Version 3 membership report message type이 추가이다. Version 3 membership report에는 두 가지 mode가 있다.

 

IGMP snooping

  기본적으로 스위치의 동작 방식은 MAC table에 목적지 MAC 주소가 없는 정보를 수신하면 연결되어 있는 모든 포트로 flooding을 한다. 즉, 일반적으로 스위치로 multicast traffic이 수신되면 연결된 모든 host들은 원하던 원하지 않던 이 traffic을 수신해야 하는 것이다. 시스코 스위치에서는 이러한 multicast flooding을 줄이기 위해 2 가지 방법을 사용할 수 있다. IGMP snooping이라는 단어에서 알 수 있듯이 switch와 host 사이에 multicast traffic을 listening 한다. 쉽게 말해, host에서 IGMP join / leave를 요청하면 해당 정보를 스위치에 MAC table에 저장하는 것이다.

 

  [IGMP snooping]

IGMP snooping은 가장 널리 사용되는 방법이다. 스위치에서는 IGMP join을 위한 interface table을 관리하고 multicast frame을 수신하면 IGMP join 메시지를 받은 interface로만 packet을 포워딩한다.  

 

  [Static MAC address entries]

IGMP snooping과 반대로 manually하게 MAC address 테이블을 관리할 수도 있는데 확장성에 용이하지 않기 때문에 권장하는 방법은 아니다.  

 

Reference site: https://datatracker.ietf.org/doc/html/rfc2236

CCNP and CCIE Enterprise Core ENCORE 350-401 Guide