목차
●Xcast 프로토콜
●Xcast 헤더 엔코딩 방식
●기존의 네트워크 상에 Xcast 도입을 위한 고려사항
1. Xcast 터널링
2. Premature X2U
3. Semi-permeable 터널링(IPv6)
●Xcast 멀티캐스팅 방식의 장점
●Xcast의 단점
●Xcast 헤더 엔코딩 방식
●기존의 네트워크 상에 Xcast 도입을 위한 고려사항
1. Xcast 터널링
2. Premature X2U
3. Semi-permeable 터널링(IPv6)
●Xcast 멀티캐스팅 방식의 장점
●Xcast의 단점
본문내용
efix '00'를 포함시킨다. 따라서 그 패킷들은 적어도 만약 모든 참여 단말이 Xcast를 지원한다면 모든 수신자로 전송될 것이다.
Xcast 멀티캐스팅 방식의 장점
- 라우터는 각 멀티캐스트 세션의 정보를 저장할 필요가 없다. 이것은 xcast가 세션 개수의 관점에서 매우 확정성이 뛰어나도록 한다.
- 멀티캐스트 주소를 할당할 필요가 없다
- 멀티캐스트 라우팅 프로토콜이 필요하지 않다. Xcast 피캣은 항상 유니캐스트 라우팅에 따라 경로를 결정하기 때문에 특별히 멀티캐스트라우팅 프로토콜을 요구하지 않는다.
- PIM-SM이나 CBT처럼 코어(core) 라우터가 없기 때문에, “single point of failure"가 없다. 공유 멀티캐스트 트리 방식과 달리, Xcast는 지연을 최소화하고 네트워크 효율성을 최대화 한다
- 기존의 멀티캐스트 라우팅 프로토콜은 만약 path가 대칭(symmetric)하지 않을 경우에 비최단경로(non-shortest-path)를 만들었던 반면 Xcast는 대칭형 경로가 요구되지 않는다.
- 유니캐스트 경로 변화에 자동적으로 반응한다. 기존의 멀티캐스트 라우팅 프로토콜에서는 유니캐스트와 멀티캐스트 라우팅 프로토콜 사이에 통신을 위한 특별한 노력이 필요하다. 많은 부분이 폴링 기반으로 구현하여 지연을 초래하였다.
- 좀 더 쉬운 보안기법과 인증이 가능해 진다. 종래의 멀리캐스트 그룹 모델과 달리, Xcast에서는 모든 송신자들이 모든 수신자 주소를 알아야만 한다. 이것은 송신자가 특정 수신자를 거부 할 수도 있고 특정 수신자로 가는 트래픽을 쉽게 계산할 수 있다는 것을 의미한다. 송신자 뿐만 아니라 보더 라우터 또한 자신의 도메인에서 몇 차례 패킷이 복제되어야 하는지 쉽게 알 수 있다. 이것은 쉽게 수신자의 수나 송신자 당 대역폭을 제한할 수 있도록 한다.
- 수신자 각각에 서로 다음 DiffServCodePoints(DSCP)를 포함하도록 할 수 있다. 기존의 멀티캐스트 프로토콜에서 각 서비스 크래스에 대하여 각각의 그룹을 만들어야 했지만 Xcast는 하나의 멀티캐스트채널 내에서 서로 다른 서비스 요구사항을 갖는 수신자를 갖도록 하 수 있다.
- Xcast 패킷은 트래픽 엔지니어링에 따른 유니케스트경로를 이용할 수 있다.
Xcast의 단점
- 각 패킷은 모든 수신자 주소를 포함한다. 수신자 주소목록을 압충하는 방법을 이용하는 것도 유용할 수 있다
- 헤더를 처리하는 오버헤드가 증가한다. 각 패킷에 있는 수신자 주소 각각은 라우팅 테이블의 참조를 필요로 한다. 따라서 n 개의 수신자를 갖는 Xcast 패킷은 n 개의 유니캐스트처럼 n번의 라우팅 테이블 참조가 필요하다. 추가적으로, 다음 홉 마다 서로 다른 헤더를 갖는 패킷이 만들어 져야 한다.
- Xcast는 오직 소수의 수신자들로 구성된 세션에만 적합하다. Xcast가 IETF회의 중계와 같은 다수의 가입자가 참여하는 세션에는 적합하지 않지만, 많은 수의 소규모 세션들을 지원한다는 점에서 기존의 멀티캐스트 방식을 보완하였다고 할 수 있다.
Xcast 멀티캐스팅 방식의 장점
- 라우터는 각 멀티캐스트 세션의 정보를 저장할 필요가 없다. 이것은 xcast가 세션 개수의 관점에서 매우 확정성이 뛰어나도록 한다.
- 멀티캐스트 주소를 할당할 필요가 없다
- 멀티캐스트 라우팅 프로토콜이 필요하지 않다. Xcast 피캣은 항상 유니캐스트 라우팅에 따라 경로를 결정하기 때문에 특별히 멀티캐스트라우팅 프로토콜을 요구하지 않는다.
- PIM-SM이나 CBT처럼 코어(core) 라우터가 없기 때문에, “single point of failure"가 없다. 공유 멀티캐스트 트리 방식과 달리, Xcast는 지연을 최소화하고 네트워크 효율성을 최대화 한다
- 기존의 멀티캐스트 라우팅 프로토콜은 만약 path가 대칭(symmetric)하지 않을 경우에 비최단경로(non-shortest-path)를 만들었던 반면 Xcast는 대칭형 경로가 요구되지 않는다.
- 유니캐스트 경로 변화에 자동적으로 반응한다. 기존의 멀티캐스트 라우팅 프로토콜에서는 유니캐스트와 멀티캐스트 라우팅 프로토콜 사이에 통신을 위한 특별한 노력이 필요하다. 많은 부분이 폴링 기반으로 구현하여 지연을 초래하였다.
- 좀 더 쉬운 보안기법과 인증이 가능해 진다. 종래의 멀리캐스트 그룹 모델과 달리, Xcast에서는 모든 송신자들이 모든 수신자 주소를 알아야만 한다. 이것은 송신자가 특정 수신자를 거부 할 수도 있고 특정 수신자로 가는 트래픽을 쉽게 계산할 수 있다는 것을 의미한다. 송신자 뿐만 아니라 보더 라우터 또한 자신의 도메인에서 몇 차례 패킷이 복제되어야 하는지 쉽게 알 수 있다. 이것은 쉽게 수신자의 수나 송신자 당 대역폭을 제한할 수 있도록 한다.
- 수신자 각각에 서로 다음 DiffServCodePoints(DSCP)를 포함하도록 할 수 있다. 기존의 멀티캐스트 프로토콜에서 각 서비스 크래스에 대하여 각각의 그룹을 만들어야 했지만 Xcast는 하나의 멀티캐스트채널 내에서 서로 다른 서비스 요구사항을 갖는 수신자를 갖도록 하 수 있다.
- Xcast 패킷은 트래픽 엔지니어링에 따른 유니케스트경로를 이용할 수 있다.
Xcast의 단점
- 각 패킷은 모든 수신자 주소를 포함한다. 수신자 주소목록을 압충하는 방법을 이용하는 것도 유용할 수 있다
- 헤더를 처리하는 오버헤드가 증가한다. 각 패킷에 있는 수신자 주소 각각은 라우팅 테이블의 참조를 필요로 한다. 따라서 n 개의 수신자를 갖는 Xcast 패킷은 n 개의 유니캐스트처럼 n번의 라우팅 테이블 참조가 필요하다. 추가적으로, 다음 홉 마다 서로 다른 헤더를 갖는 패킷이 만들어 져야 한다.
- Xcast는 오직 소수의 수신자들로 구성된 세션에만 적합하다. Xcast가 IETF회의 중계와 같은 다수의 가입자가 참여하는 세션에는 적합하지 않지만, 많은 수의 소규모 세션들을 지원한다는 점에서 기존의 멀티캐스트 방식을 보완하였다고 할 수 있다.