Docstoc

IP Multicast

Document Sample
IP Multicast Powered By Docstoc
					IP Multicast

      한국외국어대학교
       정보통신공학과
          홍 진표
     jphong@hufs.ac.kr



                         Page 1
Introduction
Intra-Domain Multicast Routing
Inter-Domain Multicast Routing
New Multicast Routing Protocols
Reliable Multicasting


                                  Page 2
      Motivation for Multicast Support
      within the Network


                               D                                D


A          B         C             A        B          C


                               E                                E



    4 end-to-end connections           1 multicast connection




                                                            Page 3
Applications for Multicasting
                   Real - time        Non - real - time

             . Video server         . Replication
                                      . Video & Web servers
             . Videoconferencing      . kiosks
Multimedia
             . Internet audio       . Content delivery

             . Graphics & audio     . Intranet & Internet



             . Stock quotes         . Information delivery
                                      . Server-server
             . News feeds             . Server-desktop
Data-only
             . Whiteboards          . Database replication

             . Interactive gaming   . Software distribution




                                                              Page 4
     Network Requirement and Possible
     Solution


Requirement                             Solution
Increased network bandwidth             Gigabit Ethernet, ATM
Bandwidth-efficient group delivery of   IP Multicasting
  infor
Deivery of real-time data, including    QoS (using RSVP, for example)
  synchronized multimedia




                                                                    Page 5
Multicast Protocol




                     Page 6
Introduction
Intra-Domain Multicast Routing
Inter-Domain Multicast Routing
New Multicast Routing Protocols
Reliable Multicasting



                                  Page 7
     IP Multicast Address
   Class D 주소
       224.0.0.0 ~ 239.255.255.255
       멀티캐스트 그룹에 유일하게 할당
   Well-known address
       224.0.0.0, 224.0.0.1 ~224.0.0.255


224.0.0.1 All systems on this subnet   224.0.0.6   All OSPF designated routers
224.0.0.2 All routers on this subnet   224.0.0.9   All RIP2 routers
224.0.0.4 All DVMRP routers            224.0.0.13 All PIM routers
224.0.0.5 All OSPF routers             224.0.0.15 All CBT routers



                                                                          Page 8
     IGMP
   Internet Group Membership Protocol
       라우터와 host 간의 IGMP 메시지 교환
       Subnet의 각 Host가 소속 Router에게 자신이
        multicast group member임을 알리는 signaling
        protocol
       라우터가 먼저 subnet 안에 특정 그룹 member가
        있는지를 query하기도 함
       IGMP version 1, 2, 3




                                                 Page 9
     IP Multicast in Subnet: Ethernet
   IEEE 802 MAC 주소와 Class D주소의 매핑
       IEEE 802 MAC Multicast address : 01-00-5E
       ARP 필요 없음




                                                    Page 10
    IP Multicast in Subnet: ATM
   Multicast connection
    are often set up “by
    hand” and are typically
    in the form of PVC
   UNI 4.0 defines
    multicast signaling and
    a leaf-initiated join
    procedure
   Adding multicast
    to an ATM switch
       Cell duplication
       Copy network


                                  Page 11
     Routing & Forwarding
   Multicast routing
       IP 라우터에 의해 수행되는 활동
       Source에서 group member에 이르는 경로결정
       경로결정(routing) 방식에 따라 routing protocol 분류
       Multicast Tree 구성 방식을 의미함
   Multicast forwarding
       Routing 경로에 따라 packet forwarding
       각 packet에 대해 incoming/outgoing interface 결정




                                                      Page 12
     RPM (Reverse Path Multicasting)
   가장 기본적인 multicast routing 기법
       Flooding(broadcasting)/Prune 기반
       DVMRP, PIM-DM 프로토콜에서 사용
   진화단계
       RPB (RP Broadcasting): Flooding + Reverse Path
       TRPB (Truncated RPB): RPB + Truncated
       RPM : TRPB + Prune




                                                         Page 13
     RPB
   Broadcasting + Reverse Path
       패킷이 source로부터 최단 경로를 통해 온 것이면 forwarding
       neighbor router 정보 이용하여 필요 없는 패킷의 전송 방지
        가능
            Poison Reverse 메시지 이용(DVMRP)
            State 정보 사용(link state)




                                             Page 14
     TRPB
   RPB + Truncated
       Multicast router maintains the group membership of leaf
        network




                                                                  Page 15
     RPM
   TRPB + Prune (Broadcasting/Prune)
       multicast packets must be periodically forwarded to every
        router in the Internet
       each router is required to main state information for all groups
        and each source




                                                                  Page 16
     Join Types
   Implicit Join (or Data Driven): 소극적 Join
       Receiver  Router (Subnetwork): IGMP
       Subnet Router에 Data 도착후 Tree 구성
       DVMRP, PIM-DM
   Explicit Join : 적극적 Join
       Receiver  Router (Subnetwork)
       Router  Center (Network)
       Router와 Center를 연결하는 경로 (Tree) 구성
       CBT, PIM-SM



                                                Page 17
     RPM
   SBT(Source Based Tree) 구성 방식 중 하나
       Broadcasting/Prune 메커니즘
       source에서 각 receivers에 이르는 최단경로 트리 구성
       DVMRP & PIM-DM의 핵심 알고리즘
   RPM 단점: 확장성(scalability)
       멀티캐스트 packet이 주기적으로 모든 라우터에 전송됨
       특히 Wide 영역의 Inter-network에서 치명적인 문제점 야기
       근본적인 이유는 Receiver의 Implicit Join 메커니즘 때문
        (receiver는 소속 라우터에게만 Join 정보를 전송)
       확장성 문제는 네트웍 자원(대역폭) 이용의 비효율을 초래




                                               Page 18
     Tree Types
   Source Based Tree (SBT)
       Source에서 각 receivers에 이르는 shortest-path tree
        구성
       Single Sender에 적합
       DVMRP, PIM-DM, MOSPF
   Center Based Tree (Shared Tree)
       Center (node or router) : Core, Rendezvous Point
       Source 및 모든 receivers는 Center로 접속함
       Multiple Senders에 적합
       CBT, PIM-SM


                                                      Page 19
SBT (Source Based Tree)

   R = receiver
                       Source Router




          R        R              R


                                       Page 20
CBT (Center Based Tree)

   R = receiver        Source Router


    Center Router              R




          R         R              R


                                        Page 21
    SBT & CBT 비교
   SBT
       End-to-end maximum delay가 짧다
       Poor Scalability (large network 적용하기 어려움)
            Member 수가 증가함에 따라 불필요한 데이터 전송이 증가
   CBT
       Tree에서 maximum delay가 SBT 보다 길다
            실험결과에 의하면 평균적으로 SBT의 delay의 1.4배
       Good Scalability :Explicit Join
       특히 Multiple Senders 경우에 적합




                                                Page 22
Multicast Routing Protocols 분류

           Source Based   Center Based
               Tree           Tree

Implicit    DVMRP
  Join      PIM-DM

Explicit     MOSPF            CBT
 Join        PIM-SM         PIM-SM




                                         Page 23
     DVMRP: 개요
   SBT
   RPM 메커니즘 사용
       현재 MBONE에서 사용중인 프로토콜
   History
       Original 버전은 TRPB 방식 사용
       지금은 RPM 방식 사용
       현재 MBONE 에서 사용되는 버전은 초기 버전과
        많이 다름




                                      Page 24
    DVMRP: Basic Operation
   RPM 알고리즘을 다음과 같이 구현함
       첫번째 멀티캐스트 packet을 모든 down-link에
        broadcast
       packet을 받은 후 member 가 없는 leaf 라우터는 up-
        link에 prune 메시지를 전송 (최단경로 tree 구성)
       prune 메시지를 받은 라우터는 일정기간 메시지
        보유
       일정시간 후 prune 메시지가 expire 되면 다시
        broadcast 함
       prune된 라우터에 새로운 member가 접속되면
        “graft”메시지를 up-link에 보내어 다시 up-link들을
        active 시킴

                                          Page 25
     DVMRP: Router Function
   Source를 기준으로 각 Router의 Parent-Child 관계 결정
        Source에서 (metric 기준으로) 가까운 A가 C의 Parent가 됨




                         Source
                                           Active Branch
        Dominant A
                                           Inactive Branch
                                  B




                         C

                                                     Page 26
     DVMRP: 단점
   Distance Vector Routing Protocol
       Topology change에 대처가 느리다 (slow to converge)
       제한된 네트웍 diameter : 15 hops
   On-tree에 있지 않은 router도 tree 정보 유지함
       라우터 메모리 및 링크 대역폭 낭비
       member 수 증가에 따라 scalability 문제
       멀티캐스트 트래픽이 전체 네트웍을 따라
        주기적으로 broadcast됨.




                                              Page 27
     PIM-DM: 개요
   PIM(Protocol Independent Multicast)
       사용되는 Unicast Routing 프로토콜에 Independent
       PIM-DM과 PIM-SM은 서로 거의 관련이 없음
   PIM-DM(Dense Mode)
       PIM-DM은 DVMRP와 거의 비슷함
       Dense area를 대상으로 함
       SBT 및 implicit join 메커니즘 사용




                                           Page 28
     PIM-DM & DVMRP 비교
   Unicast routing protocol의 독립성
       DVMRP: RIP처럼 distance vector 알고리즘 사용
       PIM-DM: unicast protocol에 독립적
   Parent-Child relationship
       DVMRP: packet 도착시, child interface forwarding
       PIM-DM: 모든 out-going interface에게 forwarding
            특정 unicast protocol을 사용하지 않기 때문
            그 만큼 packet이 duplicate 되지만, parent-child 관계
             결정에 대한 overhead를 줄일 수 있음




                                                           Page 29
     MOSPF: 개요
   OSPF(Open Shortest Path First) 프로토콜
       OSPF는 라우터간에 unicast topology 정보를 분배함
       모든 라우터는 OSPF “Autonomous System”에 의해 관리됨
       OSPF 라우팅 table은 link-state 알고리즘에 의해 계산됨
        (효율적인 route 계산, 계층적 라우팅, load-balancing 등 제공)
   Multicast Extensions to OSPF
       OSPF version 2 (RFC-2178)에 포함됨
       Unicast OSPF link state 라우팅 프로토콜에 의해 topology 파악
       Source에서 receivers에 이르는 최단경로 tree 구성
       Data Driven & Explicit Join 사용




                                                    Page 30
     MOSPF: Operations
   Explicit Join 메커니즘
       각 라우터는 Group-Membership 정보를 포함하는
        Link State 정보를 전체 네트웍에 broadcasting
        (Explicit Join)
   Source Based Tree
       Source가 소속 라우터를 통하여 멀티캐스트
        Packet을 전송하면 Source 라우터에서 모든 active
        receiver에게 이르는 최단경로 tree가 구성됨
       최단경로 트리를 구하기 위해 Dijkstra 알고리즘이
        사용됨



                                          Page 31
     MOSPF: 단점
   LSA(Link State Advertisement) 트래픽 폭주
       새로운 (S,G) 멀티캐스트 트래픽에 대하여 최단경로
        Tree를 구하기 위해 Dijkstra 알고리즘이 수행됨
       네트웍 Topology를 구하기 위한 LSA 트래픽의
        교환이 매우 빈번하게 수행되어야 함
       Group Member가 없는 Router도 LSA 트래픽을
        교환하게 됨
       아울러 SBT의 단점: active source가 여럿 있을 경우
        각 source에 대하여 다른 SBT가 구성됨




                                           Page 32
     CBT(Core Based Tree): 개요
   Center (Core) Based Tree
   Shared Delivery Tree
       Group내의 모든 Active sender가 같은 Tree를 공유
   Bi-directional Tree
   Explicit Join 메커니즘 사용
       Member는 Core Router에 Join/Prune 메시지 전송
   Protocol Independent
       PIM-SM처럼 Unicast Routing Protocol에 독립적임.




                                              Page 33
     CBT: Bootstrap 메카니즘
   Core selection 방식
       Group의 Core Router 탐지
       Candidate Core Set 정보가 BSR (BootStrap Router)에 의해서
        모든 CBT 라우터에게 배포됨
       Core Set에 속하는 라우터는 BSR (BootStrap Router)에게
        수시로 자신이 live 함을 통보해야 함
       Subnet에서 Group member에게 IGMP Join 메시지를 받은
        Router는 Hash function을 이용하여 Core 노드 선택
                                 BSR               Keep Alive
                                                   Core 정보
           Candidate                   Candidate
           Core                        Core


                       R     R         R
                                                                Page 34
     PIM-SM: 개요
   PIM-SM = CBT + SBT
       Source 트래픽(delay)에 따라 CBT에서 SBT로 전환
   Uni-directional Tree
   Unicasting routing protocols에 독립적
   Explicit Join 메커니즘
   Large Sparse Area에 적합
   Core = Rendezvous Point




                                         Page 35
PIM-SM: Operation
                                                  Link
                                                  Data
                                                  Control




       A            B         RP          D




                C                  E


   The Rendevous Point (RP) is the shared root,
   and is administratively assigned.
PIM-SM: Operation
                        Receiver 1 Joins Group G
                        C Creates (*, G) State, Sends
                        (*, G) Join to the RP




     A       B           RP           D
                      Join




         C                    E



         Receiver 1
PIM-SM: Operation
                      RP Creates (*, G) State




     A       B        RP            D




         C                 E



         Receiver 1
PIM-SM: Operation
                            Source 1 Sends Data
      Source 1
                            A Sends Registers to the RP


                 Register




     A             B        RP           D




             C                   E



             Receiver 1
PIM-SM: Operation
                                      RP De-Encapsulates Registers
         Source
                                      Forwards Data Down the Shared Tree
                                      Sends Joins Towards the Source



             Join              Join


     A                B               RP           D




                  C                        E



                  Receiver 1                   Receiver 2
PIM-SM: Operation
                               RP Sends Register-Stop
         Source
                               Once
                               Data Arrives Natively

             Register-Stop




     A                B        RP           D




                  C                 E



                  Receiver 1
PIM-SM: Operation
         Source           Shared tree rooted at the RP

                          Question:
                          What if this is suboptimal path?



     A                B          RP          D




                  C                   E



                  Receiver 1
PIM-SM: Operation
               Source
                             Answer:
                             Switch over to shortest path tree.




          A                 B         RP         D

 (S, G) Join



                        C                  E



                        Receiver 1
PIM-SM: Operation
         Source
                               Shortest path tree rooted
                               at the source.




     A                B        RP          D




                  C                 E



                  Receiver 1
PIM-SM: Operation
         Source       NOTE: RP still important !
                      Required to support sources which
                      arrive later or are not known by application.




     A                B           RP           D
                                                           Source 2




                  C                    E

                             RP also:
                             - announces active sources via MSDP
                  Receiver 1
                             - identifies group modality
                             - serves as root for bidir
     요약
   Intra-Domain Multicast Routing Protocols
       Source Based Tree: DVMRP,MOSPF,PIM-DM
       Center Based Shared Tree:CBT,PIM
   전망
       Dense Area : DVMRP & PIM-DM
       MOSPF의 breakdown
       Sparse Area : CBT & PIM-SM
       QoS-based another 프로토콜: QoSMIC ?
       Non-center based another 프로토콜 ?



                                                Page 46
     참고문헌
   IETF/Routing Area/Working Groups
       IDMR/IDR/OSPF/MOSPF/IS-IS/PIM
       Internet-Drafts
       RFC (Request For Comments)
   Textbook
       Deploying IP Multicast in the Enterprise
        Thomas A. Maufer, Prentice-Hall, ISBN 0-13-897687-
        2, 1998)




                                                     Page 47
Introduction
Intra-Domain Multicast Routing
Inter-Domain Multicast Routing
New Multicast Routing Protocols
Reliable Multicasting



                                  Page 48
    기존 Multicast Routing Protocol의 한계
   DVMRP
       Flooding and Pruning을 sparse한 member를 가진
        wide-area multicast에 적용하기 어려움
   MOSPF
       기본적으로 inter-domain multicast routing을 support
       반면, 200 node이상 scale을 지원해 주지 못하는
        OSPF의 scalability한계를 가짐
       protocol 종속적이며, 모든 domain이 unicast routing
        protocol로 OSPF를 사용하지 않을 수 있음




                                                Page 49
    기존 Multicast Routing Protocol의 한계(2)
   PIM-DM
       DVMRP와 같은 한계를 가짐.
   PIM-SM
       RP 선정의 문제점
            RP가 multicast group member로부터 멀리 떨어진 domain에
             위치
            Poor network connectivity를 가진 domain에 RP가 존재 할
             수 있으며, 전체 multicast group에 좋지 않은
             performance를 초래
   CBT
       Poor network connectivity를 가진 domain에 core가
        존재


                                                      Page 50
     H-DVMRP
   Network을 “region”으로 분할하고 two level의
    계층구조로 나눔.
       Top-level : region들로 구성
       Lower-level : region들 내의 subnet으로 구성
       각 region들은 unique ID를 갖음
   Intra-region multicast routing은 다른 protocol을 쓸 수
    있다. (->boundary routers)
   (source, group)대신 (region_ID, group)형태
   All Boundary Routers (ABR) group
       직접 연결된 모든 region들 내에 예약된 multicast group
       Scope limit



                                                   Page 51
H-DVMRP




          Page 52
     H-PIM
   Architecture
       RP : level을 가짐, DR은 level 0
       상위 level에서 하위 level로 announce message를 보냄
       RP들은 자신이 shared tree에 속하는지를 판단.
            True이면 join state에 따라 전송
            False이면 상위 level RP로 register message 전송
       각 C-RP는 자신과 같은 level의 C-RP들을 알며, 같은 정보를
        유지
   프로토콜의 복잡성 증가
   Sub-optimal RP가 선택될 수 있음.
   계층적 RP list의 유지 및 분배가 어려움.
   OCBT도 H-PIM과 거의 유사(core level)

                                                        Page 53
H-PIM




        Page 54
     Issues
   많은 protocol이 사용됨에 따라 protocol간
    interoperability가 커다란 issue가 될 수 있음.
   Hierarchical routing은 router resource에 대한
    요구를 감소 (단, level이 많으면 많을 수록 복잡)
   Border (or boundary) router는 서로 다른
    interface의 intra-domain과 inter-domain을 수행
   Solution
       MSDP/PIM-SM model
       BGMP/MASC model



                                         Page 55
     MSDP (Multicast Source Discovery
     Protocol)
   draft-ietf-msdp-spec-12
   해당 멀티캐스트 그룹의 source가 어디에
    위치하고 있는지를 탐색
   여러 PIM-SM domains내에 RPs와 source를 연결
       PIM-SM domain은 자신의 RP를 가지고 있다.
   MSDP peering
       TCP connection between MSDP routers : 639 port
       Exchange control information
       Discover multicast source from other domains



                                                    Page 56
            MSDP Overview
          MSDP Example
                                                                                    Domain E
MSDP Peers
Source Active            SA                                                              RP
Messages
                                                                          SA                           r
                                                 Domain C

                                                          RP                                  Join (*, 224.2.2.2)
                                                                                   SA
                   Domain B SA                                       SA


                         RP

                                                     SA                             RP


                               SA                                                 Domain D
                                                              SA Message
                                                           192.1.1.1, 224.2.2.2
                                          RP
     SA Message
  192.1.1.1, 224.2.2.2         s
                                          Domain A
                        Register
                   192.1.1.1, 224.2.2.2
         MSDP Overview
       MSDP Example
                                             Domain E
MSDP Peers
                                                  RP

                                                        r
                                Domain C

                                    RP

             Domain B

                RP


                                             RP

                                           Domain D

                         RP
                     s
                         Domain A
            MSDP Overview
         MSDP Example
                                                    Domain E
MSDP Peers

Multicast Traffic                                        RP

                                                               r
                                       Domain C

                                           RP

                    Domain B

                       RP


                                                    RP

                                                  Domain D

                                RP
                            s
                                Domain A
            MSDP Overview
         MSDP Example
                                                    Domain E
MSDP Peers

Multicast Traffic                                        RP

                                                               r
                                       Domain C

                                           RP

                    Domain B

                       RP


                                                    RP

                                                  Domain D

                                RP
                            s
                                Domain A
            MSDP Overview
         MSDP Example
                                                    Domain E
MSDP Peers

Multicast Traffic                                        RP

                                                               r
                                       Domain C

                                           RP

                    Domain B

                       RP


                                                    RP

                                                  Domain D

                                RP
                            s
                                Domain A
     BGMP (Border Gateway Multicast
     Protocol)
   draft-ietf-bgmp-spec-03
   Domain-border router들 사이에 bi-directional shared
    multicast tree를 만든다.
       State saving
   “shot-cut”인 source-specific branch를 shared tree에
    attach
       Long delay를 최소화
   MASC로 할당되는 multicast group address들을
    기반으로 root domain을 선택
   Border router with two components
       BGMP component
       Multicast Interior Gateway Protocol (M-IGP) component
            Any one of DVMRP, MOSPF, CBT, PIM-DM/SM


                                                                Page 62
     BGMP Join
   R/S는 DR에게 join을 알리기 위해 IGMP를 사용
   DR은 대응되는 M-IGP rule에 따라 domain의 BR로 Join-request를 전파
   BR의 M-IGP component는 BGMP component를 위해 join-alert(*, G)를
    생성
   BGMP는 root domain을 향한 next-hop peer로 BGMP-Join(*, G) message를
    전파
   Next-hop BR은 대응되는 (*, G) entry가 있는지 검사하고 없다면 entry를
    생성
   결국, BGMP(*,G)는 root domain RP에 도달하고 모든 path상에 있는
    BR들은 entry에 대응되는 routing table을 setup.




                                                           Page 63
     BGMP Data Traffic
   M-IGP를 사용해서 group member와 border
    router들에게 Multicast
   Destination domain border router에 도달할 때까지 data
    packet은 shared tree를 따라 flow
   Destination domain안에서 packet들은 M-IGP에 의해
    전송




                                              Page 64
     MASC (Multicast Address-Set Claim)
   RFC 2909
   계층적으로 멀티캐스트 주소를 domain에 따라
    할당

   Multicast Components
       MAAS (Multicast Address Allocation Server)
            Assigns unique multicast address to clients
            Monitors the domain’s address space utilization
       MASC Client
            Requests a multicast address dynamically to MAAS



                                                                Page 65
     MASC
   MASC domains form a hierarchical topology
       Top-Level domain
       Parent domain
       Child domain
   Address allocation
       Each claim address range is associated a lifetime
   MASC uses a claim-collide mechanism
       Claimant learns parent prefix and lifetime
       Claimant chooses a sub-prefix and lifetime
       Claimant sends claim to parent and siblings
       Claimant listens for collisions
       After, timeout, claimant can use prefix


                                                            Page 66
     Address Allocation (Example)
   Given
       A : 224.0.0.0/16            C : 224.0.1.1/25


   Sample Scenario
       A advertises its address range to all its children
       B claim a 224.0.1.0/24
       B listen for collision announcement for some period
       C send back collision announcement for
        224.0.1.0/24
       B claims another address, 224.0.128.0/24
       If there is no collision, B acquires 224.0.128.0/24

                                                       Page 67
    Summary
   MSDP/PIM-SM
       각 도메인마다 PIM-SM 방식을 사용
       MSDP를 사용하여 해당 멀티캐스트 그룹의 source가
        어디에 위치하고 있는지를 탐색
       Source와 domain의 RP router를 연결하는 방식
   BGMP/MASC
       MASC를 사용하여 각 도메인마다 멀티캐스트 주소를
        할당
       BGMP는 domain간 멀티캐스트 트리를 구성
       domain 내부에서는 domain-specific한 intra-domain
        multicast routing protocol이 사용

                                              Page 68
Introduction
Intra-Domain Multicast Routing
Inter-Domain Multicast Routing
New Multicast Routing Protocols
Reliable Multicasting



                                 Page 69
     New multicasting protocol
   SSM (source-specific multicast)
       1:N 환경을 위한 multicast
       IGMPv3를 사용



   X-CAST (Explicit Multicast)
       N:N 환경에서의 small group multicast
       IP packet내에 receiver list를 명시적으로 포함
            router간 별도의 multicast protocol을 사용하지 않음.
       Xcast+ : 기존 xcast의 scalability를 추구


                                                        Page 70
     ASM versus SSM
   Any-source multicast (ASM)
       Traditional multicast according to RFC 1112 (ISM service model)
       224.0.0.0 ~ 239.255.255.255
       Datagram (*, G) is delivered to hosts that request G
       One-to-many, many-to-many, join or leave
   Source-specific multicast
       232/8 (232.0.0.0 ~ 232.255.255.255) for IPv4 [globally
        assigned by IANA]
       FF2x for IPv6
       Datagram (S, G) is delivered to hosts that especially request (S,
        G).
       Defines a “channel” identified by (S, G) pair – IGMP 사용
       One-to-many only



                                                                  Page 71
     What if source is well-known?
   Simplify solution for well-known sources,
    particularly in cases where there is a single
    source sending to a given group.
       Allow immediate use of shortest forwarding path to
        a specific source, without need to create shared tree.
       Eliminate dependence on MSDP for finding sources.
       Simplify address allocation for global, single source
        groups when combined with elimination of shared
        trees (232/8).




                                                        Page 72
            SSM Objective
Join source, Get content on shortest path     Domain E
Join

Data Flow
                                                             r
                               Domain C
                                   r
             Domain B




                                                         r
                                            Domain D


                    s
                        Domain A
     Source Specific Multicast
   Allows first-hop router to respond to receiver initiated
    join requests for specific sources within a group.
   Allows first-hop router to send (S, G) join directly to
    source without creation of shared tree.
   Support elimination of shared tree state in 232/8,
    simplifying address allocation.
   Long term solution:
       IGMPv3 in routers and hosts
            Allows for inclusions lists and exclusion lists
       PIM-SSM
            Sends immediate PIM (S,G) joins based on include lists
            Prevents (*,G) joins from being sent
   Interim solutions:
       Achieve SSM functionality when IGMPv3 not yet deployed



                                                                      Page 74
     Using SSM
   Source simply send traffic to a host-group G
      Sendto (sock, pakcet, … , G, …)
   Receivers subscriber to (S, G) channel(s)
      setsockopt (sock, ..,
      IP_ADD_SOURCE_MEMBERSHIP, (S, G, iface), …)
   Receive traffic from “channel” S sending to G.
      recvfrom (sock, &packet, .. &source, …)
   Receiver need to know the sources before
    receiving


                                                Page 75
     IGMPv2
        1.1.1.10              1.1.1.11                 1.1.1.12

          H1                     H2                      H3
                                         Report for
                                          232.1.2.3



                                       1.1.1.1
                                   rtr-a                 2nd S,G join(s)

                                                 1st *,G join
Host sends IGMPv2 report for group
DR adds membership
DR sends *,G join to RP (it has to, it doesn’t know the sources)
DR sends S,G join to source (data provides the sources)
      IGMPv3
         1.1.1.10               1.1.1.11                 1.1.1.12

           H1                     H2       Report for      H3
                                            232.1.2.3
                                           source_list


                                        1.1.1.1
                                    rtr-a                   S,G join(s)

Host sends IGMPv3 report for group which can specify a list
of sources to explicity include.
IPMulticastListen (Socket, IF, G, INCLUDE, source-list)
DR adds membership.
DR sends S,G join directly to sources in the source_list, and is
not required to send *,G join to RP (and must not in 232/8).
PIM Source Specific Mode
               Source
                            Host learns of source, group/port
                            First-hop learns of source, group/port
                            First-hop send PIM s,g join directly




           A                B         RP           D
                                                           Out-of-band
 (S, G) Join                                             source directory,
                                                       example: web server


 (S, G) report          C                  E



                        Receiver 1
PIM Source Specific Mode
         Source
                               Result: Shortest path tree rooted
                               at the source, with no shared tree.




     A                B        RP           D




                  C                 E



                  Receiver 1
     Advantage of SSM
   No address management in SSM-Range
       All (Si, G) channels independent of each other
       Group address has only host-local significance
   No traffic from unwanted sources (access
    control)
   Handling of well-known source
       SSM requires only source-based forwarding tree
   Network benefits :
       Easily deployed
       Simpler management than ISM

                                                         Page 80
     X-CAST (Explicit Multicast)
   N:N환경에서의 기존 multicast protocol의 문제
       Scalability
       Allocation multicast address
       Access group control


   Narrowcast 유형의 multicast
       소규모 그룹통신 (소규모 영상회의, 소규모 IP
        telephony, network game)
       Session 수는 많으나, group의 member가 적은
        애플리케이션


                                            Page 81
     X-CAST
   IP packet내에 receiver list를 명시적으로 포함
       Router 간 별도의 Multicast protocol을 사용하지 않음.
       IPv4에서는 별도의 Xcast4 header를 정의
       IPv6는 확장 헤더를 이용
           Routing Extension and Destination Option header에 정의
   X2U (Xcast to Unicast)
       Sender는 모든 receiver의 주소를 header에 encoding
       Send to subnet router
       하나의 receiver만이 남았을 때, Xcast packet은
        common packet으로 변환하여 unicast packet으로
        전송
                [src = A | dest = B C D | payload]


                                                            Page 82
    Xcast 데이터 흐름
                                           Xcast
                                                             R8        C
                                 R5        R6        R7   unicast

                    Xcast
                                                             R9        D
A    R1        R2           R3
                                 unicast


                                           unicast
      Xcast                        R4                B
     unicast




                                                                    Page 83
     Xcast header 처리 과정
   Xcast header내에 열거된 receiver list에 따라 next
    hop을 결정하기 위해 routing table을 참조
   Next hop에 따라 receiver list를 재 분리
   앞선 과정에서 결정된 next hop들에 따라 각각 하나의
    packet들만을 전송하도록 기존 packet을 복사
   각 packet의 Xcast header내의 receiver list를 구분한
    다음 next hop에 맞게 수정
   수정된 packet들을 next hop으로 전송
   특정 hop에 하나의 receiver만이 존재하면, Xcast
    packet을 unicast packet으로 변환하여 전송(X2U)



                                            Page 84
     Existing network상에 Xcast를 도입
   Xcast 터널링
       기존 routing protocol을 사용하여 Xcast routing
        정보를 교환 및 유지
       Hop-by-hop 방식으로 forwarding 또는 non-Xcast
        router를 넘어 터널링
   Premature X2U
       만약 다음 라우터가 Xcast를 지원하지 못하는 것을
        알고 있다면, Premature X2U를 수행
       Xcast header내에 포함된 각 receiver list에 따라
        unicast packet을 전송
   Semi-permeable 터널링 (IPv6)
       IPv6에서만 가능 (hop-by-hop option header 추가)
                                              Page 85
Xcast Tunneling




  X1 routing table     X3 routing table     X7 routing table
  Dest       NextHop   Dest       NextHop   Dest       NextHop
  B          X3        A          X1        A          X3
  C          X3        C          X7        B          X3
  D          X3        D          X7        B          X3




                                                                 Page 86
     Advantage and disadvantage
   Advantage
       Multicast address를 할당하지 않음.
       별도의 Multicast routing protocol이 필요 없음.
       Shared-tree를 가지지 않음.


   Disadvantage
       각 packet은 모든 receiver address를 포함
       Header overhead
            추가적으로 next hop마다 서로 다른 header를 가짐.
       Only small group session에만 적합


                                                  Page 87
     Xcast+
   기존 xcast의 scalability를
    추구
       Core Network에서
        Xcast사용하고, Access
        Network에서는 기존의
        Multicast 방식을 이용
            1:N:N
       최종 단말에서 기존
        multicast protocol을
        사용함으로 기존 multicast
        receiver의 application을
        수용
       IGMPv3 이용



                                 Page 88
Introduction
Intra-Domain Multicast Routing
Inter-Domain Multicast Routing
New Multicast Routing Protocols
Reliable Multicasting



                                  Page 89
     RMT: Overview
   End-to-End Reliable Multicast Transport
       멀티캐스트 전송에서의 TCP 기능 제공
       가정: IP Multicast in Networks




                                              Page 90
     Feedback Implosion
   Feedback for error and flow control
       Unicast : Conveniently handled by TCP
       Multicasting : Feedback implosions
                             Source




                                      Receiver



                                                 Page 91
     Receiver Heterogeneity
   Point-to-point (unicast)
       Senders and receivers may easily adapt to underling
        situation
   Point-to-multipoint, multipoint-to-multipoint
       Different performance, distance, link speed from
        each distinct receiver
       “crying baby” syndrome
       Balance and efficiency problem
       Should satisfy distinct receivers




                                                      Page 92
     RMT: Issues
   Reliable Multicast
       Level of reliability
            Full reliability (data)
            Semi-reliability (video)
       Error Control (Loss Recovery)
       Flow and Congestion Control
            Transmission Rate Control
            Congestion Avoidance
   Scalability Issue in TCP-like RMT
       ACK/NACK Implosions
       RTT estimation
       Heterogeneous Receivers

                                         Page 93
     Solutions for scalability Issues
   Feedback control
       Suppressing feedback implosions
       Aggregating the feedback by intermediate receivers
   Loss recovery(Retransmission)
       Multicasting to the group
            Disadvantage : existing multiple copies in receivers
            Solution : setting up another group for retransmission
       Local repair
            Carried out by receivers(Use of scoping in IP Multicast)
       FEC(Forward Error Correction)
            Preventive step rather than corrective step
            needed resource reservation in advance
   Reliability guarantees and group size requirements are
    different for each application and network

                                                                        Page 94
     Classifying and Comparing Protocols
   How retransmission of lost packets is controlled

                                                 Retransmission
    Which end of session
    maintains the state of the
    connection and controls the          Sender-based      Receiver-based
    retransmission of lost packets

            How the receivers are organized
            for controlling the retransmission          Cloud   Tree   Ring




                                                                            Page 95
      Classifying and Comparing Protocols
   Sender-based VS Receiver-based
                 ACK


        Source                              Source




                          NACK

                                                     NACK




                          Receivers                               Receivers


                 Sender-based                           Receiver-based
 Sender의 역할                                            Sender의 역할
 - 모든 receiver들의 상태정보 유지                                - NACK(data 요구)에 대한 응답
 - Receiver들로부터의 모든 ACK, NACK을 처리                       재전송 작업을 receiver들로 분산
 Maximum throughput : receiver의 수에 의존적                 Sender-based 보다 scalability 증가
 - network resource & sender의 computing resource


                                                                                    Page 96
     Classifying and Comparing Protocols
   Receiver-based에서 receiver들의 조직 형태에 따른
    비교 Cloud          Tree           Ring
구조       No structure           Tree structure                         Ring structure
      .connectionless       .재전송 임무가 local group 으로     .모든 노드를 하나의 ring 으로 조직
특징    .membership 정보를 유지하
      지 않음
                            분산                          .각 노드는 global membership 정보 유지
                                                        .data transmission 과 ACK 의 동기화를 위해 token 사용
      .scalability 우수       .feedback implosion 문제를 제   .High performance and reliability
장점                          거

      .poor performance                                 .구현이 어렵다.
단점                                                        - 알고리즘 복잡도 가높다
                                                        . scalability 가 비교적 낮다.
             Source

                                                                           Receiver Set



                                              Source           Token


                            Group Leader                 ACK


                                                                                  NACK
                             Local ACK



                                    Leaf




                                                                                          Page 97
     Classifying and Comparing Protocols
   Ordering 제공에 따른 분류
       Unordered delivery
       Source-ordered protocol
       Totally-ordered protocol
   Characteristics for comparison of the prototols
       Reliability Mechanism
       Repair Request
       Feedback Control
       Retransmission
       Flow Control
       Locus of Control
       Ordering
       Late Join/Leave



                                                      Page 98
     Receiver-Initiated Protocols with
     Feedback Suppression
   NAK suppression
       Randomly delay a NAK
       Multicast a NAK to the sender and all receivers
   Pros. & Cons.                               sender
       + Reduce bandwidth
       - Additional complexity at receivers
          (timers, etc)
       - Increase latencies (timers)

                                                  X        X


                                                          Page 99
     Tree(Server)-based Hierarchical
     Recovery
   Solution for
       Server bottleneck - sender initiated
       Long recovery time - receiver initiated
       Most protocols are either pure receiver-initiated or use a hybrid
        approach
   Server (group leader)                               sender
       Each receiver assigned to server
       Servers can be subset of rcvrs             server                server
        or provided by network
       Can have more than 2 levels
   First multicast to all receivers and servers
   Servers perform loss recovery
                                                             receivers

                                                                  Page 100
     Forward Error Correction (FEC)
   Add redundancy in order to reduce need to
    recover from losses (e.g., Reed Solomon codes)
       (k,n) code
       for every k data pkts, construct n-k parity pkts
       can recover all data pkts if no more than n-k losses
   + reduce loss probability
   - greater overheads at end-hosts
   Q: can FEC reduce network resource utilization?



                                                       Page 101
 Potential Benefits of FEC
                                    Data Retransmission

                                               D2 D1
   Initial Transmission                   D3
                                          D3 D2 D1
              D2 D1
         X
         D3                               D3 D2
        D3 D2 D1                                    D1
              X
        D3 D2                       Parity Retransmission
           X    D1
                          P=D1 D2  D3        P

                                                P
One parity pkt can recover
different data pkts at different rcvrs         P


                                                         Page 102
     RMT: History
   A lot of Researches & Development
       http://research.ivv.nasa.gov/RMP/
       http://www.nard.net/~tmont/
   IRTF RM RG (Research Group)
   IETF RMT WG: 1999. 3 ~
       Building Block Approach: BBs & PIs
       One-to-Many Bulk Data Transport
   ITU-T SG7 | ISO/IEC JTC1/SC6
       ECTS & ECTP (X.ectp | ISO/IEC 14476)
            Enhanced Communications Transport Protocol


                                                          Page 103
     IETF RMT WG
   BB & PI approach
       One Size does not fit all
   Building Block drafts
       FEC (Forward Error Correction)
       GRA (generic Router Assist)
       Congestion Control: LCC, PGM-CC, TFMCC
       기타 PI-specific BBs: LCT, Tree
   3 PI (Protocol Instantiations)
       TRACK/ALC/NORM



                                                 Page 104
     TRACK: Overview
   Base Protocols
       RMTP-II: Talarian Corporation
            www.talarian.com
       TRAM: Sun MicroSystem (Java)
            www.experimentalstuff.com (JRMS)
   Related BBs
       Tree-Configuration: rmt-bb-tree-config-02.txt
       TRACK BB: rmt-bb-track-01.txt
       TFMCC (TCP-Friendly): will be made
       기타 BBs: TRACK Security, FEC, GRA


                                                        Page 105
     TRACK: Architecture
   Tree based ACK
       ACK packets flow children to root via parents




                                                        Page 106
     TRACK: Logical ACK Tree
   Tree Nodes
       Sender (Root), Service Nodes (Parent), Receivers
   Configuration Steps (automatic)
       Session Advertisement: Tree Information
       Service Node Discovery by Receiver
       Distance Measurement: TTL, Tree Level, ……
            Sender distance: from Sender to SN
            Neighbor distance: from SN to Receiver
       Selection and Bind to the best Service Node
            Loop-free ACK Tree



                                                      Page 107
     ALC: Overview
   Asynchronous Layered Coding: Features
       No feedback from receivers such as ACK/NACK
            Forward Error Correction: for error recovery
            Multi-rate transport: for congestion control
       Leading company: Digital Fountain
            www.digitalfountain.com
   Related BBs
       FEC: rmt-bb-fec-02.txt & rmt-bb-fec-info-00.txt
       LCT (Layered Coding Transport): rmt-bb-lct-00.txt
       LCC (Layered Congestion Cont.):rmt-bb-lcc-00.txt



                                                            Page 108
     NORM: Overview
   Base Protocol
       SRM (Scalable Reliable Multicast)
            미국 학계 중심으로 연구 진행
            www.aciri.org/floyd/srm.html
            MBONE whiteboard application
   Related BBs
       NORM BB: not yet made
            NACK suppression with back-off timer
       PGMCC: rmt-bb-pgmcc-00.txt




                                                    Page 109
    NORM PI
   NORM PI
       rmt-pi-norm-00.txt
            NORM BB + PGMCC BB
       NORM Packets
            Info, Data, NACK, ACK, Report
       Status: too premature
            Basic framework is not specified yet
            Use of ACK/NACK: scope-creep into TRACK (?)




                                                           Page 110
   요약: IETF RMT Protocols
                 TRACK PI        ALC PI      NORM PI

Error Control     Tree BB       FEC BB      NORM BB
(Base Docu.)     TRACK BB       LCT BB      (not yet)
 Congestion        TFMCC        LCC BB      PGMCC BB
  Control         (not yet)

  Additional      FEC BB       GRA BB (?)   FEC BB (?)
  (Optional)      GRA BB                    GRA BB (?)
Leading Player    Talarian       Digital       USA
                 Corporation    Fountain    Universities

                                                   Page 111
     Deployment Obstacles—
     Non-Technical Issues
   How to bill for the service
       Is the service what runs on top of multicast?
       Or is it the transport itself?
       Do you bill based on sender or receiver, or both?
   How to control access
       Should sources be rate-controlled like they are not for unicast
        routing?
       Should receivers be able to receive at a specific rate only?
   How to make your peers fan-out instead of you (reduce
    the replication factor in you own network)
       Closest exit versus latest entrance—all a wash
   How to avoid multicast from opening a lot of security
    holes
       Network-wide denial of service attacks
       Eaves-dropping simpler since receivers are unknown


                                                                 Page 112
     Deployment Obstacles—
     Technical Issues
   Source tree state will become
    a problem as IP multicast
    gains popularity
       When policy and access control per source will be
        the rule rather than the exception
   Group state will become a problem
    as IP multicast gains popularity
       10,000 three member groups across
        the Internet
   Hopefully we can upper bound the state in
    routers based on their switching capacity
                                                      Page 113
     Deployment Obstacles—
     Technical Issues
   ISPs are telling us they don’t want to depend on their
    competitor’s RP
       Do we connect shared trees together?
       Do we have a single shared tree
        across domains?
       Do we use source trees only for
        inter-domain groups?
   ISPs are telling us that the unicast and multicast
    topologies won’t be congruent across domains
       Due to physical/topological constraints
       Due to policy constraints
   We need a inter-domain routing protocol that
    distinguishes unicast versus multicast policy

                                                         Page 114

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:7
posted:12/17/2012
language:Unknown
pages:114