멀티캐스트 개요

멀티캐스트와 유니캐스트 비교

Junos® 운영 체제(Junos OS) 라우팅 프로토콜 프로세스는 다양한 라우팅 프로토콜을 지원합니다. 이러한 라우팅 프로토콜은 한 쌍의 클라이언트와 서버 간에 전송되는 유니캐스트 트래픽 스트림뿐만 아니라 단일 서버 소스와 여러 클라이언트 수신기 간에 전송되는 비디오, 오디오 또는 두 가지 모두를 포함하는 멀티캐스트 트래픽 스트림에 대해서도 라우팅 디바이스 간에 네트워크 정보를 전달합니다. 멀티캐스트에 사용되는 라우팅 프로토콜은 유니캐스트 라우팅 프로토콜과 여러 가지 주요 면에서 다릅니다.

정보는 유니캐스트, 브로드캐스트 및 멀티캐스트의 세 가지 기본 방법을 통해 네트워크를 통해 전달됩니다.

유니캐스트, 브로드캐스트 및 멀티캐스트의 차이점은 다음과 같이 요약할 수 있습니다.

• 유니캐스트: 한 원본에서 하나의 대상으로 일대일입니다.

• 브로드캐스트: 하나의 소스에서 가능한 모든 대상까지 일대일로.

• 멀티캐스트: 일대다, 한 소스에서 트래픽 수신에 관심을 표현하는 여러 대상으로.

  메모:

  이 목록에는 온라인 게임이나 화상 회의와 같이 동일한 수신기에 대한 소스가 많고 수신자가 소스의 역할을 하는 경우가 많은 다대다 응용 프로그램에 대한 특수 범주는 포함되어 있지 않습니다. 다대다는 일대다 멀티캐스트를 반복적으로 사용하는 서비스 모델이므로 고유한 프로토콜이 필요하지 않습니다. 원래 멀티캐스트 사양인 RFC 1112는 ASM(any-source multicast) 다대다 모델과 SSM(source-specific multicast) 일대다 모델을 모두 지원합니다.

유니캐스트 트래픽을 사용하면 네트워크를 통해 이동하는 많은 IP 패킷 스트림이 웹 사이트 서버와 같은 단일 소스에서 클라이언트 PC와 같은 단일 대상으로 흐릅니다. 유니캐스트 트래픽은 여전히 네트워크에서 정보 전송의 가장 일반적인 형태입니다.

브로드캐스트 트래픽은 단일 소스에서 네트워크에서 도달할 수 있는 모든 가능한 목적지(보통 LAN)로 흐릅니다. 브로드캐스트는 트래픽이 목적지에 도달하도록 하는 가장 쉬운 방법입니다.

텔레비전 네트워크는 브로드캐스트를 사용하여 비디오와 오디오를 배포합니다. 텔레비전 네트워크가 케이블 TV(CATV) 시스템인 경우에도 소스 신호는 가능한 모든 대상에 도달하므로 일부 채널의 콘텐츠가 스크램블되는 주된 원인입니다. 각 최종 사용자의 장치에 지속적으로 도착하는 엄청난 양의 불필요한 정보, 스크램블링의 복잡성과 영향, 관련 개인 정보 보호 문제로 인해 인터넷에서 브로드캐스트가 실현되지 않습니다.

멀티캐스트 트래픽은 유니캐스트(하나의 소스, 하나의 목적지)와 브로드캐스트(하나의 소스, 모든 목적지)의 양극단 사이에 있습니다. 멀티캐스트는 "단일 소스, 여러 대상" 트래픽 배포 방법으로, 특정 소스에서 정보를 수신해야 함을 명시적으로 나타내는 대상만 트래픽 스트림을 수신합니다.

IP 네트워크에서는 대상(클라이언트)이 소스(서버)와 직접 통신하지 않는 경우가 많기 때문에 소스와 목적지 사이의 라우팅 디바이스는 트래픽이 무분별하게 라우팅되는 것을 방지하기 위해 유니캐스트 또는 멀티캐스트 관점에서 네트워크의 토폴로지를 결정할 수 있어야 합니다. 멀티캐스트 라우팅 디바이스는 하나의 입력 인터페이스에서 수신된 패킷을 복제하여 여러 출력 인터페이스에서 복사를 전송합니다.

IP 멀티캐스트에서 소스 및 대상은 거의 항상 라우팅 디바이스가 아닌 호스트입니다. 멀티캐스트 라우팅 디바이스는 소스에서 대상으로 네트워크 전반에 걸쳐 멀티캐스트 트래픽을 배포합니다. 멀티캐스트 라우팅 디바이스는 네트워크에서 멀티캐스트 소스를 찾고, 여러 인터페이스에서 패킷 사본을 전송하고, 라우팅 루프를 방지하고, 관심 있는 대상을 적절한 소스와 연결하고, 원치 않는 패킷의 흐름을 최소화해야 합니다. 표준 멀티캐스트 라우팅 프로토콜이 이러한 기능의 대부분을 제공하지만 일부 라우터 아키텍처는 패킷의 여러 복사본을 보낼 수 없으므로 멀티캐스팅을 직접 지원하지 않습니다.

IP 멀티캐스트 사용

멀티캐스트를 통해 IP 네트워크는 인터넷 초기 단계에 널리 보급된 유니캐스트 데이터 전송 모델 이상의 것을 지원할 수 있습니다. 원래 1989년 RFC 1112에서 호스트 확장으로 정의된 멀티캐스트는 일대다 또는 다대다로 특성화될 수 있는 트래픽 흐름을 전달하는 효율적인 방법을 제공합니다.

유니캐스트 트래픽은 데이터 애플리케이션에만 국한되지 않습니다. 무선 여부에 관계없이 전화 통화에는 디지털 오디오 샘플이 포함되어 있고 디지털 사진 또는 비디오가 포함될 수 있으며 여전히 단일 소스에서 단일 대상으로 흐를 수 있습니다. 마찬가지로 멀티캐스트 트래픽은 멀티미디어 애플리케이션에만 국한되지 않습니다. 일부 데이터 응용 프로그램에서는 트래픽 흐름이 단일 소스에서 패킷을 필요로 하는 여러 대상으로(예: 여러 PC에 전달되는 뉴스 또는 주식 시세 표시기 서비스에서) 이루어집니다. 이러한 이유로, 두 용어 모두 일반적이지만 멀티캐스트 대상의 경우 listener보다 receiver라는 용어가 선호됩니다.

유니캐스트와 함께 작동할 수 있지만 멀티캐스트에 더 적합한 네트워크 애플리케이션에는 협업 그룹웨어, 원격 회의, 주기적 또는 "푸시" 데이터 전달(주식 시세, 스포츠 경기 결과, 잡지, 신문 및 광고), 서버 또는 웹 사이트 복제, 전쟁 시뮬레이션 또는 가상 현실과 같은 분산 대화형 시뮬레이션(DIS) 등이 포함됩니다. 일대다 또는 다대다 데이터 또는 다중 수신기가 있는 멀티미디어 애플리케이션의 네트워크 리소스 오버헤드를 줄이는 데 관여하는 모든 IP 네트워크는 멀티캐스트의 이점을 누릴 수 있습니다.

유니캐스트가 라디오 또는 뉴스 티커 서비스에서 사용되는 경우 각 라디오 또는 PC는 PC의 각 청취자 또는 시청자에 대해 별도의 트래픽 세션을 가져야 합니다(실제로 일부 웹 기반 서비스에 대한 방법임). 서버에서 사용하는 처리 부하와 대역폭은 더 많은 사용자가 서버에 "튜닝"함에 따라 선형적으로 증가합니다. 이는 인터넷의 글로벌 규모를 다룰 때 매우 비효율적입니다. 유니캐스트는 서버에 패킷 중복 부담을 가중시키고 사용자 수가 증가함에 따라 백본 대역폭을 점점 더 많이 소비합니다.

브로드캐스트를 대신 사용하는 경우 소스는 브로드캐스트 대상 주소를 사용하여 단일 IP 패킷 스트림을 생성할 수 있습니다. 브로드캐스트는 서버 패킷 중복 문제를 제거하지만 IP 브로드캐스트는 단일 서브네트워크로만 전송될 수 있고 IP 라우팅 디바이스는 일반적으로 별도의 인터페이스에서 IP 서브네트워크를 분리하기 때문에 IP에 좋은 솔루션은 아닙니다. IP 패킷 스트림을 문자 그대로 어디에나 보낼 수 있고 어떤 소스에도 "조정"할 필요가 없다고 해도 브로드캐스트는 대역폭 부담과 관심 없는 호스트가 많은 수의 패킷을 삭제해야 하기 때문에 매우 비효율적입니다. 브로드캐스트는 각 호스트에 패킷 거부 부담을 주고 백본 대역폭을 최대한 소비합니다.

라디오 방송국 또는 뉴스 티커 트래픽의 경우 멀티캐스트는 다른 방법의 단점과 모든 장점 없이 가장 효율적이고 효과적인 결과를 제공합니다. 멀티캐스트 패킷의 단일 소스가 모든 관심 있는 수신자에게 전달됩니다. 브로드캐스트와 마찬가지로 전송 호스트는 IP 패킷의 단일 스트림만 생성하므로 수신기가 1개이든 100만 개이든 상관없이 부하가 일정하게 유지됩니다. 네트워크 라우팅 디바이스는 패킷을 복제하고 패킷을 적절한 수신기로 전달하지만, 라우팅 디바이스에는 복제 역할만 새롭습니다. 전혀 관심이 없는 수신자로 구성된 서브넷으로 연결되는 링크는 멀티캐스트 트래픽을 전달하지 않습니다. 멀티캐스트는 발신자, 네트워크 및 수신자의 부담을 최소화합니다.

IP 멀티캐스트 용어

멀티캐스트에는 IP 멀티캐스트 라우팅 디바이스 및 네트워크에 적용되는 고유한 용어와 약어 세트가 있습니다. 그림 1 은 IP 멀티캐스트 네트워크에서 일반적으로 사용되는 몇 가지 용어를 보여줍니다.

멀티캐스트 네트워크에서 핵심 구성 요소는 패킷을 복제할 수 있으므로 멀티캐스트가 가능한 라우팅 디바이스입니다. 기반이 되는 유니캐스트 네트워크와 정확히 동일한 토폴로지를 갖는 IP 멀티캐스트 네트워크의 라우팅 디바이스는 멀티캐스트 라우팅 프로토콜을 사용하여 수신기(수신기의 멀티미디어적 의미보다 선호되지만 수신기도 사용됨)를 소스에 연결하는 배포 트리를 구축합니다. 멀티캐스트 용어로 배포 트리는 소스(배포 트리의 루트가 소스)에 루팅됩니다. 소스로 향하는 라우팅 디바이스의 인터페이스는 업스트림 인터페이스이지만, 수신 또는 인바운드 인터페이스라는 덜 정확한 용어도 사용됩니다. 대역폭 사용을 최소한으로 유지하기 위해 라우팅 디바이스에서 하나의 업스트림 인터페이스만 멀티캐스트 패킷을 수신하는 것이 최선입니다. 수신기로 향하는 라우팅 디바이스의 인터페이스는 다운스트림 인터페이스이지만, 발신 또는 아웃바운드 인터페이스라는 덜 정확한 용어도 사용됩니다. 라우팅 디바이스에는 0N에서 –1개의 다운스트림 인터페이스가 있을 수 있으며, 이는 N 라우팅 디바이스의 논리적 인터페이스 수입니다. 루핑을 방지하기 위해 업스트림 인터페이스는 다운스트림 멀티캐스트 패킷의 사본을 수신하지 않아야 합니다.

그림 1: IP 네트워크의 멀티캐스트 용어

라우팅 루프는 반복적으로 복제되는 패킷의 위험 때문에 멀티캐스트 네트워크에서 치명적입니다. 최신 멀티캐스트 라우팅 프로토콜의 복잡성 중 하나는 유니캐스트 라우팅 프로토콜보다 훨씬 더 엄격하게 패킷 단위의 라우팅 루프를 피해야 한다는 것입니다.

루프 방지를 위한 역방향 경로 전달

라우팅 디바이스의 멀티캐스트 전송 상태는 수신기에서 배포 트리의 루트로 역방향 경로를 기반으로 보다 논리적으로 실행됩니다. RPF에서 수신된 모든 멀티캐스트 패킷은 모든 인터페이스에서 복제되거나 전달되기 전에 RPF 검사를 통과해야 합니다.

라우터가 인터페이스에서 멀티캐스트 패킷을 수신하면 라우터는 source 주소를 확인합니다. 그런 다음 라우터는 유니캐스트 경로를 통해 소스로 돌아가기 위한 주소로 동일한 주소를 사용할 destination 수 있는지 확인합니다. 유니캐스트 라우팅 테이블에서 발견된 발신 인터페이스가 멀티캐스트 패킷이 수신된 인터페이스와 동일한 인터페이스인 경우, 패킷이 RPF 검사를 통과합니다.

수신 인터페이스가 소스로 돌아가는 최단 경로에 있지 않기 때문에 RPF 검사에 실패한 멀티캐스트 패킷은 누락됩니다. 라우팅 디바이스는 RPF를 위해 별도의 테이블을 구축하고 유지할 수 있습니다.

루프 방지를 위한 최단 경로 트리

멀티캐스트에 사용되는 배포 트리는 소스에 뿌리를 두고 최단 경로 트리(SPT)이지만 소스가 네트워크 주변부에 있는 경우 이 경로가 길어질 수 있습니다. 백본에 을( shared tree 를) 배포 트리로 제공하면 멀티캐스트 소스가 네트워크의 중앙에 위치합니다. 코어 네트워크에 뿌리를 둔 공유 배포 트리는 스파스 모드 멀티캐스트 프로토콜의 기능인 랑데뷰 포인트(RP)로 작동하는 멀티캐스트 라우팅 디바이스에 의해 생성되고 유지됩니다.

루프 방지를 위한 관리 범위 지정

범위는 멀티캐스트 패킷을 포워딩할 수 있는 라우팅 디바이스와 인터페이스를 제한합니다. 멀티캐스트 범위 지정은 administrative RFC 2365 Administratively Scoped IP Multicast, 에 설명된 대로 범위 지정을 위해 멀티캐스트 주소 범위가 예약되어 있다는 의미에서 입니다. 경계의 라우팅 디바이스는 멀티캐스트 패킷을 필터링하고 패킷이 설정된 제한을 넘어 벗어나지 않도록 해야 합니다.

멀티캐스트 리프 및 브랜치 용어

라우팅 디바이스에 호스트가 있고 하나 이상의 관심 있는 수신기가 있는 각 서브네트워크는 배포 트리의 리프 입니다. 라우팅 디바이스는 서로 다른 인터페이스에 여러 리프를 가질 수 있으며, 리프가 있는 각 인터페이스에서 IP 멀티캐스트 패킷의 사본을 전송해야 합니다. 새로운 리프 서브네트워크가 트리에 추가되면(즉, 호스트 서브네트워크에 대한 인터페이스가 이전에 멀티캐스트 패킷의 사본을 수신하지 않음), 새로운 브랜치가 구축되고, 리프가 트리에 조인되며, 복제된 패킷이 인터페이스에서 전송됩니다. 특정 인터페이스의 리프 수는 라우팅 디바이스에 영향을 미치지 않습니다. 이 작업은 리프 1개 또는 100개에 대해 동일합니다.

해당 IP 서브네트워크로 이어지는 라우팅 디바이스 인터페이스에 관심 있는 호스트가 없어 브랜치가 리프를 포함하지 않는 경우, 브랜치는 배포 트리에서 제거 되고 해당 인터페이스에 멀티캐스트 패킷이 전송되지 않습니다. 패킷은 배포 트리가 라우팅 디바이스에서 분기되는 경우에만 복제되어 여러 인터페이스로 전송되며, 어떤 링크도 패킷의 중복 흐름을 전송하지 않습니다.

일반적으로 동일한 멀티캐스트 소스에서 동일한 IP 패킷 스트림을 수신하는 모든 호스트의 집합을 그룹이라고 합니다. IP 멀티캐스트 네트워크에서 트래픽은 IP 멀티캐스트 주소 또는 그룹 주소를 기반으로 멀티캐스트 그룹에 전달됩니다. 그룹은 리프의 위치를 결정하고 리프는 멀티캐스트 네트워크의 브랜치를 결정합니다.

IP 멀티캐스트 주소 지정

멀티캐스트는 클래스 D IP 주소 범위(224.0.0.0 - 239.255.255.255)를 사용합니다. 클래스 D 주소는 일반적으로 멀티캐스트 주소 라고 합니다. 전체 클래스풀 주소 개념이 사용되지 않기 때문입니다. 멀티캐스트 주소는 IP 패킷에서 소스 주소로 나타날 수 없으며 패킷의 대상으로만 사용될 수 있습니다.

멀티캐스트 주소의 접두사 길이는 일반적으로 /32이지만 다른 접두사 길이도 허용됩니다. 멀티캐스트 주소는 디바이스의 물리적 집합이 아닌 수신기의 논리적 그룹화를 나타냅니다. 멀티캐스트 주소 블록은 여전히 기존 표기법의 접두사 길이 측면에서 설명할 수 있지만 편의상 가능합니다. 예를 들어, 232.0.0.0에서 232.255.255.255까지의 멀티캐스트 주소 범위는 232.0.0.0/8 또는 232/8로 쓸 수 있습니다.

인터넷 서비스 프로바이더(ISP)는 멀티캐스트 주소가 물리적 디바이스가 아닌 컨텐츠와 관련되기 때문에 일반적으로 고객에게 멀티캐스트 주소를 할당하지 않습니다. 수신자에게는 자신의 멀티캐스트 주소가 할당되지 않지만 콘텐츠의 멀티캐스트 주소를 알아야 합니다. 소스에는 콘텐츠 생성을 위해서만 멀티캐스트 주소를 할당해야 하며, 네트워크에서의 위치를 식별하기 위해서가 아닙니다. 모든 소스와 수신기에는 여전히 일반적인 유니캐스트 IP 주소가 필요합니다.

멀티캐스트 주소 지정은 대부분 수신자를 참조하며, 멀티캐스트 콘텐츠의 소스는 일반적으로 콘텐츠를 생성하는 멀티캐스트 그룹의 구성원도 아닙니다. 소스가 생성하는 패킷을 모니터링해야 하는 경우 모니터링은 로컬에서 수행할 수 있으며 패킷이 네트워크를 통과하도록 할 필요가 없습니다.

많은 응용 프로그램에는 자체 사용을 위해 다양한 멀티캐스트 주소가 할당되어 있습니다. 이러한 응용 프로그램은 해당 응용 프로그램에서 생성된 세션에 멀티캐스트 주소를 할당합니다. 일반적으로 멀티캐스트 주소를 정적으로 할당할 필요는 없지만 지정할 수 있습니다.

멀티캐스트 주소

멀티캐스트 호스트 그룹 주소는 상위 4비트가 1110인 IP 주소로 정의되며, 주소 범위는 224.0.0.0에서 239.255.255.255 사이 또는 단순히 224.0.0.0/4입니다. (이러한 주소는 클래스 D 주소라고도 합니다.)

IANA(Internet Assigned Numbers Authority)는 등록된 IP 멀티캐스트 그룹 목록을 유지 관리합니다. 기본 주소 224.0.0.0은 예약되어 있으며 어떤 그룹에도 할당할 수 없습니다. 224.0.0.1부터 224.0.0.255까지의 멀티캐스트 주소 블록은 로컬 유선 사용을 위해 예약되어 있습니다. 이 범위의 그룹은 라우팅 프로토콜 및 로컬 검색 메커니즘을 비롯한 다양한 용도로 할당됩니다.

239.0.0.0에서 239.255.255.255까지의 범위는 관리 범위 주소용으로 예약되어 있습니다. 관리 범위의 멀티캐스트 주소로 주소가 지정된 패킷이 구성된 관리 경계를 넘지 않기 때문에 그리고 관리 범위의 멀티캐스트 주소가 로컬로 할당되기 때문에 이러한 주소는 관리 경계를 넘어 고유할 필요가 없습니다.

레이어 2 프레임 및 IPv4 멀티캐스트 주소

LAN의 멀티캐스팅은 레이어 2에서 멀티캐스팅에 대한 조사를 시작하기에 좋은 장소입니다. 레이어 2에서 멀티캐스트는 IPv4 또는 IPv6 패킷 및 주소 대신 미디어 액세스 제어(MAC) 프레임과 주소를 처리합니다. 라우팅 디바이스 없이 특정 그룹에 멀티캐스트 소스를 전송하는 단일 LAN을 가정해 보겠습니다. 나머지 호스트는 멀티캐스트 그룹의 콘텐츠에 관심이 있는 수신자입니다. 따라서 멀티캐스트 소스 호스트는 유니캐스트 IP 주소를 소스로, 멀티캐스트 그룹 주소를 대상으로 패킷을 생성합니다.

이 패킷이 포함된 프레임에 어떤 MAC 주소가 사용됩니까? 패킷 소스 주소(멀티캐스트 컨텐츠를 생성하는 호스트의 유니캐스트 IP 주소)는 소스의 MAC 주소로 직접 쉽게 변환됩니다. 하지만 패킷의 대상 주소는 어떨까요? IP 멀티캐스트 그룹 주소입니다. 패킷의 멀티캐스트 그룹 주소에 해당하는 프레임의 대상 MAC 주소는 무엇입니까?

한 가지 옵션은 LAN이 LAN 브로드캐스트 MAC 주소만 사용하여 LAN의 모든 스테이션에서 프레임이 처리되도록 하는 것입니다. 그러나 이 절차는 패킷 및 프레임의 순환을 관심 있는 호스트로 제한하는 멀티캐스트의 전체 목적을 무효화합니다. 또한 호스트는 많은 멀티캐스트 그룹에 액세스할 수 있으며, 이로 인해 관심 없는 목적지에 대한 트래픽 양이 증가할 수 있습니다. 멀티캐스트 그룹을 지원하기 위해 LAN 수준에서 프레임을 브로드캐스트하는 것은 의미가 없습니다.

그러나 멀티캐스트를 위해 레이어 2 프레임을 효과적으로 사용할 수 있는 쉬운 방법이 있습니다. MAC 주소에는 유니캐스트에 대해 0으로 설정되고(LAN 용어는 개별 주소임) 멀티캐스트 주소임을 나타내기 위해 1로 설정된 비트가 있습니다. 이러한 주소 중 일부는 특정 벤더의 멀티캐스트 그룹 또는 MAC 수준 프로토콜을 위해 예약되어 있습니다. 인터넷 멀티캐스트 애플리케이션은 0x01-00-5E-00-00-00에서 0x01-00-5E-FF-FF-FF의 범위를 사용합니다. 멀티캐스트 수신기(TCP/IP를 실행하는 호스트)는 애플리케이션이 멀티캐스트 그룹에 가입할 때 이러한 주소 중 하나의 프레임을 수신합니다. 애플리케이션이 종료되거나 호스트가 패킷 계층(계층 3)에서 그룹을 탈퇴하면 호스트는 수신을 중지합니다.

즉, 레이어 3의 IPv4 멀티캐스트 주소를 레이어 2의 MAC 멀티캐스트 주소로 매핑하는 데 3바이트 또는 24비트를 사용할 수 있습니다. 그러나 멀티캐스트 주소를 포함한 모든 IPv4 주소의 길이는 32비트이므로 8개의 IP 주소 비트가 남습니다. IPv4 멀티캐스트 주소를 MAC 멀티캐스트 주소에 매핑하는 어떤 방법이 "충돌"(즉, 패킷 레이어의 서로 다른 두 IP 멀티캐스트 그룹이 프레임 레이어의 동일한 MAC 멀티캐스트 주소 매핑)의 가능성을 최소화합니까?

먼저, 모든 IPv4 멀티캐스트 주소는 동일한 4비트(1110)로 시작하므로 실제로는 8비트가 아닌 4비트만 문제가 된다는 점을 인식하는 것이 중요합니다. 서브넷 마스크에 따라 IPv4 주소의 마지막 비트가 호스트 비트로 거의 보장되므로 LAN은 IPv4 주소의 마지막 비트를 삭제해서는 안 됩니다. 그러나 가장 왼쪽에 있는 주소 비트인 상위 비트는 거의 항상 네트워크 비트이며 LAN은 하나만 있습니다(현재로서는).

나머지 24개의 MAC 주소 비트 중 다른 1비트는 예약되어(초기 0 은 인터넷 멀티캐스트 주소를 의미함) IPv4 주소에서 초기 1110 다음에 오는 5비트는 삭제됩니다. 나머지 23비트는 1대1로 MAC 주소의 마지막 23비트로 매핑됩니다. 이 프로세스의 예가 그림 2에 나와 있습니다.

그림 2: MAC 주소를 멀티캐스트 주소로 변환

이 프로세스는 동일한 MAC 멀티캐스트 주소에 매핑할 수 있는 32(2,⁵) IPv4 멀티캐스트 주소가 있음을 의미합니다. 예를 들어, 멀티캐스트 IPv4 주소 224.8.7.6 및 229.136.7.6 은 동일한 MAC 주소(0x01-00-5E-08-07-06)로 변환됩니다. 이는 실질적인 문제이며, 호스트는 두 멀티캐스트 그룹 모두에 전송되는 프레임에 관심이 있을 수 있으므로 IP 소프트웨어는 둘 중 하나를 거부해야 합니다.

멀티캐스트 그룹에 대한 MAC 주소가 결정되면 호스트의 운영 체제는 기본적으로 LAN 인터페이스 카드에 멀티캐스트 그룹에 가입하거나 탈퇴하도록 명령합니다. 멀티캐스트 그룹에 가입되면 호스트는 멀티캐스트 주소로 전송된 프레임과 호스트의 유니캐스트 주소를 수락하고 다른 멀티캐스트 그룹의 프레임을 무시합니다. 물론 호스트가 동시에 둘 이상의 그룹에서 멀티캐스트 콘텐츠에 가입하고 받을 수 있습니다.

멀티캐스트 인터페이스 목록

멀티캐스트 라우팅 루프를 피하기 위해 모든 멀티캐스트 라우팅 디바이스는 항상 최단 경로를 통해 해당 멀티캐스트 그룹 컨텐츠의 소스로 연결되는 인터페이스를 인식해야 합니다. 이것은 업스트림(수신) 인터페이스이며 패킷은 멀티캐스트 소스로 다시 전달되지 않습니다. 다른 모든 인터페이스는 배포 트리의 브랜치 수에 따라 잠재적인 다운스트림(발신) 인터페이스입니다.

라우팅 디바이스는 멀티캐스트 포워딩 상태를 결정하는 프로세스인 수신 및 발신 인터페이스의 상태를 면밀히 모니터링합니다. 특정 멀티캐스트 그룹에 대한 멀티캐스트 포워딩 상태의 라우팅 디바이스는 기본적으로 해당 그룹의 콘텐츠에 대해 "켜져"있습니다. 라우팅 디바이스의 발신 인터페이스 목록에 있는 인터페이스는 해당 그룹의 수신 인터페이스 목록에 수신된 그룹 패킷의 사본을 보냅니다. 수신 및 발신 인터페이스 목록은 멀티캐스트 그룹마다 다를 수 있습니다.

라우팅 디바이스의 멀티캐스트 전송 상태는 일반적으로 (S,G) 또는 (*,G) 표기법으로 작성됩니다. 이들은 각각 "ess comma gee"와 "star comma gee"로 발음됩니다. (S,G)에서 S는 멀티캐스트 트래픽 소스의 유니캐스트 IP 주소를 의미하며, G는 S가 소스인 특정 멀티캐스트 그룹 IP 주소를 나타냅니다. 이 소스에서 전송된 모든 멀티캐스트 패킷은 소스 주소인 S와 대상 주소인 G를 갖습니다.

(*,G) 표기법의 별표(*)는 그룹 G로 전송하는 모든 멀티캐스트 애플리케이션 소스에 상태가 적용됨을 나타내는 와일드카드입니다. 따라서 두 소스가 멀티캐스트 그룹 224.1.1.2에 대해 정확히 동일한 콘텐츠를 생성하는 경우, 라우팅 디바이스는 (*,224.1.1.2)를 사용하여 두 소스에서 그룹으로 트래픽을 전달하는 라우팅 디바이스의 상태를 나타낼 수 있습니다.

멀티캐스트 라우팅 프로토콜

멀티캐스트 라우팅 프로토콜은 직접 연결된 서브넷(일반적으로 LAN)의 호스트가 특정 멀티캐스트 그룹으로부터 트래픽을 수신하고, 브랜치를 정리하고, 소스와 그룹을 찾고, 라우팅 루프를 방지하고자 할 때 멀티캐스트 라우팅 디바이스 모음이 배포 트리를 구축(조인)할 수 있도록 합니다.

다음과 같은 여러 멀티캐스트 라우팅 프로토콜이 있습니다.

• DVMRP(Distance Vector Multicast Routing Protocol) - 첫 번째 멀티캐스트 라우팅 프로토콜로, 여러 가지 제약으로 인해 대규모 인터넷 사용에 적합하지 않습니다. DVMRP는 고집적 모드 전용 프로토콜이며, 플러드 및 정리 또는 암시적 조인 방법을 사용하여 모든 곳에 트래픽을 전달한 다음 무관심한 수신자가 어디에 있는지 확인합니다. DVMRP는 (S,G) 형식의 소스 기반 배포 트리를 사용하며 RPF 검사를 위한 자체 멀티캐스트 라우팅 테이블을 구축합니다.

• MOSPF(Multicast OSPF) - 멀티캐스트 사용을 위해 OSPF를 확장하지만 고집적 모드에서만 확장합니다. 그러나 MOSPF에는 명시적 참가 메시지가 있으므로 라우팅 디바이스가 모든 소스의 멀티캐스트 트래픽으로 전체 도메인을 플러딩할 필요가 없습니다. MOSPF는 (S,G) 형식의 소스 기반 배포 트리를 사용합니다.

• 양방향 PIM 모드 - PIM의 변형입니다. 양방향 PIM은 RP(Rendezvous Point) 주소에 뿌리를 둔 양방향 공유 트리를 구축합니다. 양방향 트래픽은 PIM-SM에서와 같이 최단 경로 트리로 전환하지 않으므로 경로 길이 대신 라우팅 상태 크기에 최적화됩니다. 이는 엔드투엔드 지연이 PIM Sparse 모드에 비해 더 길 수 있음을 의미합니다. 양방향 PIM 경로는 항상 와일드카드 소스(*, G) 경로입니다. 이 프로토콜은 (S,G) 경로 및 데이터 트리거 이벤트가 필요하지 않습니다. 양방향(*,G) 그룹 트리는 발신자에서 RP로 업스트림으로, RP에서 수신자로 다운스트림 트래픽을 전달합니다. 그 결과, 다른 PIM 모드에서 발견되는 엄격한 RPF(Reverse Path Forwarding) 기반 규칙은 양방향 PIM에 적용되지 않습니다. 대신 양방향 PIM(*,G)은 모든 소스 및 RP에서 트래픽을 전달합니다. 양방향 PIM 라우팅 디바이스는 많은 잠재적 수신 인터페이스에서 트래픽을 수용할 수 있는 기능을 가져야 합니다. 양방향 PIM은 소스특정(S,G) 상태가 필요하지 않기 때문에 확장성이 뛰어납니다. 양방향 PIM은 소스가 분산된 경우가 많고 수신기가 분산된 구축에 권장됩니다.

• PIM 고집적 모드 - 이 PIM 모드에서는 거의 모든 가능한 서브넷에 소스에서 멀티캐스트 트래픽을 수신하려는 수신기가 하나 이상 있다고 가정하므로, 네트워크는 가능한 모든 브랜치의 트래픽으로 플러딩 된 다음, 브랜치가 명시적으로(메시지로) 또는 암시적으로(시간 초과 침묵) 패킷 수신에 관심을 표명하지 않을 때 다시 정리됩니다. 이것은 멀티캐스트 작업의 고집적 모드 입니다. LAN은 고집적 모드 작동에 적합한 네트워크입니다. 일부 멀티캐스트 라우팅 프로토콜, 특히 오래된 프로토콜은 고집적 모드 작업만 지원하므로 인터넷에서 사용하기에 부적절합니다. DVMRP 및 MOSPF와 달리 PIM 고집적 모드에서는 라우팅 디바이스가 모든 유니캐스트 라우팅 프로토콜을 사용할 수 있으며 유니캐스트 라우팅 테이블을 사용하여 RPF 검사를 수행할 수 있습니다. PIM 고집적 모드에는 암시적 참가 메시지가 있으므로 라우팅 디바이스는 플러딩 및 정리 방법을 사용하여 어디에나 트래픽을 전달한 다음 무관심한 수신기가 어디에 있는지 확인합니다. PIM 고집적 모드는 모든 고집적 모드 프로토콜과 마찬가지로 (S,G) 형식의 소스 기반 배포 트리를 사용합니다. PIM은 또한 혼합 희소 및 고집적 그룹과 함께 희소 고집적 모드 모드를 지원하지만 해당 운영 모드에 대한 특별한 표기법은 없습니다. Sparse 고집적 모드 가 지원되는 경우, 멀티캐스트 라우팅 프로토콜은 일부 멀티캐스트 그룹이 Sparse가 되고 다른 그룹이 고밀도가 되도록 허용합니다.

• PIM Sparse 모드 - PIM의 이 모드에서는 가능한 수신기 중 극소수만이 각 소스의 패킷을 원하는 것으로 가정하므로 네트워크는 트래픽에 대한 관심을 (메시지로) 나타내는 리프가 하나 이상 있는 브랜치에서만 패킷을 설정하고 전송합니다. 이 멀티캐스트 프로토콜을 통해 라우팅 디바이스는 모든 유니캐스트 라우팅 프로토콜을 사용할 수 있으며 유니캐스트 라우팅 테이블을 사용하여 역경로 전달(RPF) 검사를 수행합니다. PIM Sparse 모드에는 명시적 참가 메시지가 있으므로 라우팅 디바이스는 관심 있는 수신기가 어디에 있는지 확인하고 이웃에 업스트림으로 참가 메시지를 전송하여 수신기에서 RP(Rendezvous Point)로 트리를 구축합니다. PIM Sparse 모드는 RP 라우팅 디바이스를 멀티캐스트 그룹 트래픽의 초기 소스로 사용하므로 모든 Sparse 모드 프로토콜과 마찬가지로 (*,G) 형식으로 배포 트리를 구축합니다. PIM Sparse 모드는 해당 경로가 특정 멀티캐스트 그룹의 트래픽에 대해 RP를 통하는 것보다 짧은 경우 (S,G) 소스 기반 트리로 마이그레이션됩니다. WAN은 스파스 모드 작동에 적합한 네트워크이며, 실제로 일반적인 멀티캐스트 지침은 어떤 상황에서도 WAN에서 고집적 모드 실행하지 않는 것입니다.

• CBT(Core Based Trees) - PIM Sparse 모드(Sparse 모드, 명시적 조인 및 공유(*,G) 트리)의 모든 특성을 공유하지만 PIM Sparse 모드보다 소스를 찾는 데 더 효율적이라고 합니다. CBT는 학술 토론 외에는 거의 접할 수 없습니다. CBT의 대규모 배치는 상업 또는 기타 방식으로 이루어지지 않습니다.

• PIM SSM(Source-Specific Multicast) - 클라이언트가 RP의 도움 없이 소스에서 직접 멀티캐스트 트래픽을 수신할 수 있는 PIM Sparse 모드 개선. IGMPv3와 함께 사용하여 수신기와 소스 간의 최단 경로 트리를 생성합니다.

• IGMPv1 - RFC 1112, IP 멀티캐스팅을 위한 호스트 확장에 정의된 원래 프로토콜입니다. IGMPv1은 라우팅 디바이스에 명시적 참가 메시지를 전송하지만, 호스트가 그룹을 탈퇴할 때를 결정하기 위해 시간 제한을 사용합니다. 세 가지 버전의 IGMP(Internet Group Management Protocol)가 수신기 호스트와 라우팅 디바이스 간에 실행됩니다.

• IGMPv2 - RFC 2236, 인터넷 그룹 관리 프로토콜, 버전 2에 정의되어 있습니다. 다른 기능 중에서도 IGMPv2는 참가 메시지에 명시적 탈퇴 메시지를 추가합니다.

• IGMPv3 - RFC 3376, 인터넷 그룹 관리 프로토콜, 버전 3 에서 정의됨. 다른 기능 중에서도 IGMPv3는 멀티캐스트 그룹 또는 SSM(Source-Specific Multicast)의 단일 콘텐츠 소스 지원을 최적화합니다. PIM SSM과 함께 사용하여 수신기와 소스 간의 최단 경로 트리를 생성합니다.

• 부트스트랩 라우터(BSR) 및 자동 RP(랑데부 포인트) - 스파스 모드 라우팅 프로토콜이 라우팅 도메인(AS(Autonomous System) ) 내에서 RP를 찾을 수 있도록 허용합니다. RP 주소는 정적으로도 구성할 수 있습니다.

• MSDP(Multicast Source Discovery Protocol) - 하나의 멀티캐스트 라우팅 도메인에 있는 그룹이 다른 라우팅 도메인에서 RP를 찾을 수 있도록 허용합니다. 모든 수신기와 소스가 동일한 라우팅 도메인에 있는 경우 RP에서 MSDP가 사용되지 않습니다. 일반적으로 PIM Sparse 모드 RP와 동일한 라우팅 디바이스에서 실행됩니다. 모든 수신기와 소스가 동일한 라우팅 도메인에 있는 경우에는 적합하지 않습니다.

• 세션 공지 프로토콜(SAP) 및 세션 설명 프로토콜(SDP) - 멀티캐스트 세션 이름을 표시하고 해당 이름을 멀티캐스트 트래픽과 연관시킵니다. SDP는 멀티미디어 컨퍼런스 세션을 광고하고 세션에 참여하려는 참가자에게 설정 정보를 전달하는 세션 디렉토리 프로토콜입니다. 클라이언트는 일반적으로 SDP를 사용하여 공지 패킷을 잘 알려진 멀티캐스트 주소 및 포트로 주기적으로 멀티캐스팅하여 컨퍼런스 세션을 알립니다.

• PGM(Pragmatic General Multicast) - 멀티캐스트 트래픽에 안정성을 추가하기 위해 IP 레이어와 멀티캐스트 애플리케이션 간에 사용할 수 있는 멀티캐스트 트래픽용 특수 프로토콜 레이어입니다. PGM을 통해 수신자는 모든 경우에 누락된 정보를 감지하고 수신자 애플리케이션에 필요한 경우 대체 정보를 요청할 수 있습니다.

멀티캐스트 라우팅 프로토콜 간의 차이는 표 1에 요약되어 있습니다.

링크 또는 오버로드된 라우팅 디바이스에서 높은 비트 오류 속도로 인한 재전송은 반복되는 유니캐스트만큼 멀티캐스트를 비효율적으로 만들 수 있다는 점을 인식하는 것이 중요합니다. 따라서 TCP(Transmission Control Protocol)에서 제공하는 세션 지원(그러나 TCP는 항상 누락된 세그먼트를 다시 전송함) 또는 UDP(User Datagram Protocol) 데이터그램 서비스의 간단한 삭제 후 계속 전략(재정렬이 문제가 될 수 있음)과 관련하여 많은 멀티캐스트 애플리케이션에서 절충안이 있습니다. 최신 멀티캐스트는 UDP를 거의 독점적으로 사용합니다.

T 시리즈 라우터 멀티캐스트 성능

주니퍼 네트웍스 T 시리즈 코어 라우터는 최소한의 라우터 로드로 극단적인 멀티캐스트 패킷 복제 요구 사항을 처리합니다. 각 메모리 구성 요소는 멀티캐스트 패킷을 최대 두 번 복제합니다. 최대 팬아웃과 관련된 최악의 시나리오에서도 1개의 입력 포트와 63개의 출력 포트에 패킷 사본이 필요한 경우 T 시리즈 라우팅 플랫폼은 멀티캐스트 패킷을 6번만 복사합니다. 대부분의 멀티캐스트 배포 트리는 훨씬 희소하므로 대부분의 경우 두 개 또는 세 개의 복제만 필요합니다. 어떠한 경우에도 T 시리즈 아키텍처는 가장 큰 멀티캐스트 팬아웃 요구 사항에도 불구하고 멀티캐스트 성능에 영향을 미치지 않습니다.