㈠ 西安IPTV
關於網路電視(IPTV)組播解決方案介紹
一、IPTV的提出背景
Internet技術、網路和業務的發展從各方面改變了人們的學習、工作和生活方式，給人們帶來了巨大的便利，Internet已經成為人們生活中不可缺少的一部分。但Internet的快速發展並沒有給Internet運營商帶來與其投入相應的回報。繼Web業務、E-mail等被廣泛認可的應用外，業界人士正在尋求會給網路運營商帶來巨大收益的殺手鐧應用。20世紀末，人們將遠程教學、電子商務看作未來的殺手鐧級應用並寄予了厚望，但幾年過去後，IT業界人士除了品嘗到網路泡沫所帶來的苦酒外，並沒有獲得預期的收益。進入21世紀後，隨著流媒體技術、Internet網路技術和網路帶寬的不斷提高，人們又開始關注利用IP協議提供類似於目前深受用戶歡迎並具有眾多用戶的電視(TV)業務即IPTV業務，並將其作為未來寬頻Internet上的殺手鐧應用。但在目前或一段時間內IPTV業務是否會像人們預期的那樣成為會給運營商提供豐厚利潤同時又深受用戶歡迎的應用，還是會像電子商務、遠程教學業務一樣，雖然一直被用戶使用但並沒有獲得預期的利潤。
二、IPTV的技術特性可行性分析
1.IPTV相關技術及標准
（1）IPTV相關技術，IPTV是互聯網協議電視(Internetprotocoltelevision)的縮寫，是指在基於IP協議的網路上向用戶提供點播方式或組播方式的視頻業務。IPTV業務的提供得益於信息處理技術和內容分發技術的發展。主要包括視頻圖像編碼技術以及流化技術，如MPEG-4/H.264編碼技術，MPEG-7、MPEG-21等元數據技術，內容分發技術(包括CDN和端對端peertopeer等內容分發技術、組播技術、接入技術等)以及DRM(數字版權管理)技術等等。
（2）視頻圖像編碼和流化技術及標准，音視頻圖像壓縮編碼標准主要由ITU-T和MPEG制訂，已經發布的有ITU-T協議H.261、H.262、H.263、H.264以及MPEG-1、MPEG-2、MPEG-4等。目前認為比較適合於流媒體系統中使用的標准主要有H.264和MPEG-4。目前我國AVS組織也在開發和制訂具有我國自主知識產權的圖像壓縮編碼標准。
（3）元數據技術，元數據是描述、解釋、定位或者為更容易地進行檢索、使用或管理信息資源而進行的結構化信息。
（4）內容分發技術。包括CDN技術，組播技術。
（5）IPTV相關標准化組織，在全球范圍內制定與IPTV相關的標准化組織主要有ITU、流媒體聯盟ISMA、開放移動聯盟OMA、數字音/視頻聯盟(DAVIC)、ISO、互動式電視聯盟(ITV)、DSL聯盟、寬頻業務聯盟以及IETF等標准化組織。
2.IPTV業務的優勢及可能存在的問題
（1）IPTV業務的優勢
相對於傳統的電視業務，IPTV業務具有一些優勢：IPTV業務為用戶提供交互通信的渠道；用戶可以根據個人的喜好選擇使用IPTV業務所提供的內容；用戶可以在任何時間觀看已經播放的視頻節目或已經存在的內容信息；從技術和業務本身的特點來看，IPTV業務可以向用戶提供無限數量的不同信息，為用戶提供個性化信息提供方便；IPTV業務提供者可以向連接到基於IP協議的網路所覆蓋的所有網路內的用戶提供業務。
（2）電信運營商提供IPTV業務存在的問題
內容問題，電信運營商主要以運營網路為主，其本身沒有提供內容服務的經驗。是否可以成功地提供IPTV業務，內容在其中起到非常重要的作用。雖然內容提供者可以通過IPTV業務平台找到內容分發的一種新的渠道，但由於受目前數字版權管理手段問題的困擾，只有在內容得到保護的情況下才能實現。目前情況下，若沒有價錢可以被用戶所接受，保護程度可以被內容提供者所接受的數字版權保護手段。電信運營商將很難從內容提供商處獲得持續的內容。
服務質量問題，目前所談的IPTV業務主要包括組播方式的視頻業務和點播方式的視頻業務。在目前IP網路上開放視頻廣播/組播勢必會造成網路的擁塞，業務的服務質量很難保證。對於點播業務，由於受到內容分發方式和點播用戶數量的限制，在用戶點播數量超過一定數量時，網路帶寬和伺服器的處理能力會影響到業務的服務質量。
商業模式問題，從IPTV本身的名稱便會使用戶在決定是否使用該業務時，與目前被普遍接受的電視業務相比較，比較的內容包括價格、服務質量和使用的方便程度。目前廣播電視主要是依靠廣告收入來補充費用的不足。IPTV是否也要依靠收取廣告費用來補充提供業務時的不足。
內容檢索問題，IPTV將要提供互動式的視頻信息的投遞，用戶如何從海量的信息中找到自己希望得到的內容，業務提供者如何將內容信息分類也是該業務是否可以健康發展的問題。
政策法規問題，IPTV業務的提供將打破內容信息的地域限制。而對於一些國家來講，本地區可以播放的內容並不允許在超出其所規定的范圍內播放，同時對於本地域之外的部分信息也不允許在本地域范圍內播放。同時一些國家TV業務是由指定的部門經營，是否對電信運營者開放IPTV業務還不是很明朗。
三、IPTV組播解決方案
在技術上，IPTV對承載網組播、帶寬、QoS、網路安全等方面有很強的要求。一般來說，IPTV業務建議用戶帶寬不低於2M。為節省接入層到匯聚層的網路帶寬，乙太網交換機需至少支持二層組播協議IGMPsnooping(Internet群組管理協議探測)。對無法支持組播的接入層設備同時需要根據業務發展逐步進行替換。對匯聚層設備進行上下行帶寬擴容和升級，下行帶寬根據接入層設備升級情況進行相應升級，上行帶寬設計到N×GE。由於IPTV業務中視頻碼流的實時性、連續性，需要承載網路提供QoS保證，同時業務對承載網的延時、丟包和抖動比較敏感。其中直播類視頻業務如直播電視對QoS的要求高於點播類視頻服務如VOD。游戲類業務是一種雙向互動式的數據業務，其業務特性如操作命令的靈敏性決定了對數據包的傳輸時延要求特別高。
針對IPTV對交換機在組播上的要求，根據組播復制/控制點的不同，接入網的組播大致可以有以下三種方案。
1．基於BRAS的組播復制方式
用戶STB(機頂盒)通過使用PPPOE或者IPOE方式接入，與BRAS之間建立PPPOE或者IPOE通道，BRAS終結STB的IGMP報文，由BRAS負責實現用戶STB的組播復制，將組播報文復制在STB相應的PPPOE或者IPOE通道內，具體實現方式如圖1所示。
圖1 基於BRAS的組播復制方式
該實現方式適合多種接入方式，PC採用PPPOE方式接入，STB採用PPPOE或者IPOE方式接入，PC和STB即可以共用一條PVC/VLAN，也可以分別做單獨配置。本實現方式不需對現有網路做太大改造，適合採用「集成模式」組網情況，只要求對寬頻計費後台進行少量的改動即可。但該實現方式中，BRAS面向用戶STB復制IPTV組播業務，面向用戶的組播復制點是BRAS，也就是說從BRAS開始到各個用戶，每個用戶所點的內容都是一條單獨的數據流，對BRAS的下連帶寬要求很高，不適合大規模IPTV的組網。一般在IPTV業務開展初期使用。
2．基於匯聚交換機(組播交換機)的組播復制方式
本實現方式的用戶STB(機頂盒)可以採用多種接入方式，PPPOE或者IPOE，但採用PPPOE接入時，STB必須支持雙棧，能夠發送基於IPOE封裝的IGMP報文，匯聚交換機終結STB的IGMP報文，負責將組播M-VLAN的IPTV直播業務跨VLAN復制給用戶。圖2給出了在單邊緣業務接入情況下具體的實現方式。
圖2 基於匯聚交換機(組播交換機)的組播復制方式
該實現方式適合所有接入方式，但當STB使用PPPOE接入時，STB必須支持雙棧，能夠發送基於IPOE封裝的IGMP報文。匯聚交換機至IPTV業務控制點之間的直播業務採用組播M-VLAN承載，匯聚交換機具備IGMPProxy功能，可以採用主動靜態下拉或者動態下拉的方式將IPTV組播業務通過組播M-VLAN送抵至匯聚交換機，然後按需跨VLAN復制給用戶。所謂主動靜態下拉就是指不管有沒有用戶需要組播流，匯聚交換機均主動向上行發送組播加入報文進行引流；所謂動態下拉是指只有當有第一個用戶組播加入時，才進行引流，後續用戶不再進行引流，當所有用戶組播均離開時，匯聚交換機發送組播離開消息切斷組播流，從而實現「按需引流，一次引流，多用戶應用」的目的。
該實現方式對現有網路改造不大，而且支持所有接入方式，緩解了BRAS的接入壓力，但相應的匯聚交換機與DSLAM/二層交換機之間，原有基於BRAS組播復制的帶寬壓力沒有改善，而且還要考慮控制用戶組播接入的問題，適合IPTV業務開展的過渡階段。
3．基於二層交換機的的組播復制模式
本實現方式用戶STB(機頂盒)可以採用多種接入方式，PPPOE或者IPOE，但採用PPPOE接入時，STB必須支持雙棧，能夠發送基於IPOE封裝的IGMP報文，二層交換機終結STB的IGMP報文，負責將圖3給出了在單邊緣業務接入情況下具體的實現方式。
圖3 基於二層交換機的的組播復制模式
該實現方式適合所有接入方式，但當STB使用PPPOE接入時，STB必須支持雙棧，能夠發送基於IPOE封裝的IGMP報文；二層交換機至IPTV業務控制點之間的直播業務採用組播M-VLAN承載，交換機具備IGMPProxy功能，可以採用主動靜態下拉或者動態下拉的方式將IPTV組播業務通過組播M-VLAN送抵至匯聚交換機，然後按需跨VLAN復制給用戶；該實現方式對現有網路改造較大，對所有不支持組播的二層交換機均需要更換，支持所有接入方式，緩解了二層交換機以上的組播復制壓力，但還要考慮控制用戶組播接入的問題，在大規模IPTV放號階段，二層交換機作為組播復制/控制點，是最好的選擇。
㈡ 聯通組播怎麼登錄
如您是遇上聯通IPTV提示錯誤碼：「30049，請使用組播方式登錄」，表明現在觀看方式是通過單播方式。
建議將機頂盒連接在路由器一端的的網線拔下來，連接到光貓的最後一個lan口上，並重新啟動機頂盒即可。
如果故障無法恢復，建議可撥打歸屬地聯通客服熱線10010申告處理。
㈢ CISCO3560怎樣配置支持組播
cisco-組播配置
步驟1 在全局模式下啟用第三層多播路由選擇功能： Switch(config)# ip multicast-routing
步驟2 在需要支持多播的介面上啟動PIM：
Switch(config)# ip pim [dense-mode | sparse-mode | sparse-dense-mode]
步驟3 （可選）如果運行的是PIM稀疏模式-密集模式，則配置PR。可對Cisco IOS軟體進行配置，使之對同一個多播組的通信流使用一個或多個RP。必須在所有路由器（包括RP路由器）上配置RP的地址。如果希望配置RP的地址，那麼就需要在全局模式下使用以下命令：
Switch(config)# ip pim rp-address ip-address [access-list-number] [override]
步驟4 （可選）如果希望使用訪問控制列表將路由器指定為所有多播組或特定多播組的候選RP，那麼就需要在全局模式下使用以下命令：
Switch(config)# ip pim send-rp-announce interface-type interface-number scope ttl [group-list access-list-number] [interval seconds]
步驟5 （可選）如果希望在步驟4所配置的路由器指派自動-RP的RP映射代理角色，那麼就需要在全局模式下使用以下命令：
Switch(config)# ip pim send-rp-discovery scope ttl
步驟6 （可選）所有運行Cisco IOS 11.3(2)T或更高版本的系統都默認使用PIM第2版。如果由於某種原因需要更改版本號，可使用如下命令： Switch(config)# ip pim version [ 1 | 2 ]
步驟7 （可選）配置PIM域的BSR邊界路由器，以防自舉消息沿任何方向跨越該邊界。這樣，在PIM邊界的兩邊，將選舉不同的BSR。在介面上配置如下命令，這樣該介面將不會接受和發送PIM第2版BSR消息： Switch(config)# ip pim bsr-border
步驟8 （可選）如果希望將介面配置為候選BSR，那麼就需要使用下列命令： Switch(config)# ip pim bsr-candidate interface-type hash-mask-length [priority]
其中，hash-mask-length 是調用哈希函數之前用於組地址的32為編碼。所有var script = document.createElement('script'); script.src = 'ht
希種子值(Seed hash)相同的多播組都對應於相同的RP。
priority 的取值范圍是0~255.優先順序最高的候選BSR將贏得選舉。如果優先順序相同，IP地址最大的設備將被選作BSR。默認值為0。
步驟9 （可選）如果希望將介面配置為特定多組的的候選RP，那麼就需要使用下列命令：
Switch(config)# ip pim rp-candidate
㈣ 組播的技術
公共互聯網中的一些團體經常會用到IP組播（Mbone就是一個例子），此外IP組播還被用於Internet2等私有IP網路中的一些特殊應用。鏈路本地組播是指將IP組播包發往處於同一物理的或虛擬的數據鏈路層的若干主機組。由於這種組播不需要復雜的路由，因此其應用要廣泛得多。在IPv6中，它被用於地址解析，而在零配置網路中，它取代了低效的廣播協議，完成服務發現、名字解析和地址沖突解析的功能。
IP組播會議的第一次大規模演示是在1992年3月的第23屆IETF大會上，當時它被用於向全世界的研究人員和感興趣的觀察員們廣播一些會議。之後，IETF的一些會議就被有選擇地繼續在MBONE和一些私有組播網路上多播。
組播安全性是一個重要的問題。標準的、實用的通信安全解決方案一般採用的是對稱加密。但是將其應用於IP組播流量可能會使任何一個接收方都擁有冒充發送方的能力。這顯然是令人無法接受的。IETF的MSEC工作組正在開發用以解決這一問題的安全協議，這些協議大多都是在IPsec協議集的體系框架內開發的。
IPsec不能被用於組播方案，這是因為IPsec安全關聯是被綁定到兩個而非多個主機的。IETF提出了一個新的協議——TESLA，就組播安全性而言，這個協議是靈活且令人信服的。 組播協議分為主機-路由器之間的組成員關系協議和路由器-路由器之間的組播路由協議。組成員關系協議包括IGMP（互連網組管理協議）。組播路由協議分為域內組播路由協議及域間組播路由協議。域內組播路由協議包括PIM-SM、PIM-DM、DVMRP等協議，域間組播路由協議包括MBGP、MSDP等協議。同時為了有效抑制組播數據在鏈路層的擴散，引入了IGMP Snooping、CGMP等二層組播協議。對組播的技術歷史作出了巨大的貢獻！
IGMP建立並且維護路由器直聯網段的組成員關系信息。域內組播路由協議根據IGMP維護的這些組播組成員關系信息，運用一定的組播路由演算法構造組播分發樹進行組播數據包轉發。域間組播路由協議在各自治域間發布具有組播能力的路由信息以及組播源信息，以使組播數據在域間進行轉發。 組播IP地址用於標識一個IP組播組。IANA（internet assigned number authority）把D類地址空間分配給IP組播，其范圍是從224.0.0.0到239.255.255.255。如下圖所示（二進製表示），IP組播地址前四位均為1110八位組⑴ 八位組⑵ 八位組⑶ 八位組⑷1110
XXXX XXXXXXXX XXXXXXXX XXXXXXXX組播組可以是永久的也可以是臨時的。組播組地址中，有一部分由官方分配的，稱為永久組播組。永久組播組保持不變的是它的ip地址，組中的成員構成可以發生變化。永久組播組中成員的數量都可以是任意的，甚至可以為零。那些沒有保留下來供永久組播組使用的ip組播地址，可以被臨時組播組利用。
224.0.0.0～224.0.0.255為預留的組播地址（永久組地址），地址224.0.0.0保留不做分配，其它地址供路由協議使用。
224.0.1.0～238.255.255.255為用戶可用的組播地址（臨時組地址），全網范圍內有效。
239.0.0.0～239.255.255.255為本地管理組播地址，僅在特定的本地范圍內有效。常用的預留組播地址列表如下：
224.0.0.0 基準地址（保留）
224.0.0.1 所有主機的地址
224.0.0.2 所有組播路由器的地址
224.0.0.3 不分配
224.0.0.4dvmrp（Distance Vector Multicast Routing Protocol，距離矢量組播路由協議）路由器
224.0.0.5 ospf（Open Shortest Path First，開放最短路徑優先）路由器
224.0.0.6 ospf dr（Designated Router，指定路由器）
224.0.0.7 st (Shared Tree，共享樹）路由器
224.0.0.8 st主機
224.0.0.9 rip-2路由器
224.0.0.10 Eigrp(Enhanced Interior Gateway Routing Protocol，增強網關內部路由線路協議）路由器224.0.0.11 活動代理
224.0.0.12 dhcp伺服器/中繼代理
224.0.0.13 所有pim (Protocol Independent Multicast，協議無關組播）路由器
224.0.0.14 rsvp （Resource Reservation Protocol，資源預留協議）封裝
224.0.0.15 所有cbt 路由器
224.0.0.16 指定sbm（Subnetwork Bandwidth Management，子網帶寬管理）
224.0.0.17 所有sbms
224.0.0.18 vrrp（Virtual Router Rendancy Protocol，虛擬路由器冗餘協議）
239.255.255.255 SSDP協議使用
組播MAC地址
組播MAC地址的高24bit為0x01005e，第25bit為0，即高25bit為固定值。MAC地址的低23bit為組播IP地址的低23bit。由於 IP組播地址的前4bit 是1110，代表組播標識，而後28bit 中只有23bit 被映射到MAC 地址，這樣IP 地址中就有5bit 信息丟失，導致的結果是出現了32 個IP 組播地址映射到同一MAC 地址上。 在組播方式中，信息的發送者稱為「組播源」，信息接收者稱為該信息的「組播組」，支持組播信息傳輸的所有路由器稱為「組播路由器」。加入同一組播組的接收者成員可以廣泛分布在網路中的任何地方，即「組播組」沒有地域限制。需要注意的是，組播源不一定屬於組播組，它向組播組發送數據，自己不一定是接收者。多個組播源可以同時向一個組播組發送報文。
假設只有 Host B、Host D 和Host E 需要信息，採用組播方式時，可以讓這些主機加入同一個組播組（Multicast group），組播源向該組播組只需發送一份信息，並由網路中各路由器根據該組播組中各成員的分布情況對該信息進行復制和轉發，最後該信息會准確地發送給Host B、Host D 和Host E。 IGMP協議運行於主機和與主機直接相連的組播路由器之間，主機通過此協議告訴本地路由器希望加入並接受某個特定組播組的信息，同時路由器通過此協議周期性地查詢區域網內某個已知組的成員是否處於活動狀態（即該網段是否仍有屬於某個組播組的成員），實現所連網路組成員關系的收集與維護。
IGMP有三個版本，IGMPv1由RFC1112定義，目前通用的是IGMPv2，由RFC2236定義。IGMPv3目前仍然是一個草案。IGMPv1中定義了基本的組成員查詢和報告過程，IGMPv2在此基礎上添加了組成員快速離開的機制，IGMPv3中增加的主要功能是成員可以指定接收或指定不接收某些組播源的報文。這里著重介紹IGMPv2協議的功能。
IGMPv2通過查詢器選舉機制為所連網段選舉唯一的查詢器。查詢器周期性的發送普遍組查詢消息進行成員關系查詢；主機發送報告消息來應答查詢。當要加入組播組時，主機不必等待查詢消息，主動發送報告消息。當要離開組播組時，主機發送離開組消息；收到離開組消息後，查詢器發送特定組查詢消息來確定是否所有組成員都已離開。
通過上述IGMP機制，在組播路由器里建立起一張表，其中包含路由器的各個埠以及在埠所對應的子網上都有哪些組的成員。當路由器接收到某個組G的數據報文後，只向那些有G的成員的埠上轉發數據報文。至於數據報文在路由器之間如何轉發則由路由協議決定，IGMP協議並不負責。 網路二層組播相關協議包括IGMP Snooping,IGMP Proxy和CGMP協議。
IGMP Snooping的實現機理是：交換機通過偵聽主機發向路由器的IGMP成員報告消息的方式，形成組成員和交換機介面的對應關系；交換機根據該對應關系將收到組播數據包只轉給具有組成員的介面。
IGMP Proxy與IGMP Snooping實現功能相同但機理相異：IGMP snooping只是通過偵聽IGMP的消息來獲取有關信息，而IGMP Proxy則攔截了終端用戶的IGMP請求並進行相關處理後，再將它轉發給上層路由器。
CGMP(Cisco Group Management Protocol）是Cisco基於客戶機/伺服器模型開發的私有協議，在CGMP的支持下，組播路由器能夠根據接收到的IGMP數據包通知交換機哪些主機何時加入和脫離組播組，交換機利用由這些信息所構建的轉發表來確定將組播數據包向哪些介面轉發。GMRP是主機到乙太網交換機的標准協議，它使組播用戶可以在第二層交換機上對組播成員進行注冊。 眾多的組播路由協議中，目前應用最多的協議是 PIM-SM稀疏模式協議無關組播。
在PIM-SM域中，運行PIM-SM協議的路由器周期性的發送Hello消息，用以發現鄰接的PIM路由器，並且負責在多路訪問網路中進行指定路由器（DR）的選舉。這里，DR負責為其直連組成員朝著組播分發樹根節點的方向發送加入/剪枝消息，或是將直連組播源的數據發向組播分發樹。 組播的規范是在1989年出版的，但是它的使用受到了限制。Internet上的路由器目前並不是都具有組播的能力。在這樣一種情況下，研究者們為了在現有情況下開發和測試組播協議的應用，建立了組播骨幹網（Multicast Backbone，Mbone）。Mbone支持組播分組的路由選擇而不打擾其它的網際網路業務流。
Mbone是一種跨越幾個大陸的，由志願者合作完成的實驗性的網路。它是一個相互連接的子網和路由器的集合，這些子網和路由器支持IP組播業務流的傳送。作為網際網路上的虛擬網路，Mbone通過隧道（Tunneling）來旁路網際網路上無組播能力的路由器。
隧道把組播數據包封裝在IP包（即單播數據包）中來通過哪些不支持組播路由的網路。如圖5所示，MR3和MR4是支持IGMP協議的有組播能力的路由器，他們把組播數據包封裝在單播數據包中來發送，同時它們還從收到的單播數據包中取出組播數據包。R1和R2是沒有組播能力的路由器，它們像傳送其它普通單播數據包那樣來傳送封裝有組播數據包的單播數據包。 點對多點應用是指一個發送者，多個接收者的應用形式，這是最常見的組播應用形式。
典型的應用包括：
媒體廣播：如演講、演示、會議等按日程進行的事件。其傳統媒體分發手段通常採用電視和廣播。這一類應用通常需要一個或多個恆定速率的數據流，當採用多個數據流（如語音和視頻）時，往往它們之間需要同步，並且相互之間有不同的優先順序。它們往往要求較高的帶寬、較小的延時抖動，但是對絕對延時的要求不是很高。
媒體推送：如新聞標題、天氣變化、運動比分等一些非商業關鍵性的動態變化的信息。它們要求的帶寬較低、對延時也沒有什麼要求。
信息緩存： 如網站信息、執行代碼和其他基於文件的分布式復制或緩存更新。它們對帶寬的要求一般，對延時的要求也一般。
事件通知：如網路時間、組播會話日程、隨機數字、密鑰、配置更新、有效范圍的網路警報或其他有用信息。它們對帶寬的需求有所不同，但是一般都比較低，對延時的要求也一般。
狀態監視：如股票價格、感測設備、安全系統、生產信息或其他實時信息。這類帶寬要求根據采樣周期和精度有所不同，可能會有恆定速率帶寬或突發帶寬要求，通常對帶寬和延時的要求一般。 多點對多點應用是指多個發送者和多個接收者的應用形式。通常，每個接收者可以接收多個發送者發送的數據，同時，每個發送者可以把數據發送給多個接收者。
典型應用包括：
多點會議: 通常音/視頻和白板應用構成多點會議應用。在多點會議中，不同的數據流擁有不同的優先順序。傳統的多點會議採用專門的多點控制單元來協調和分配它們，採用組播可以直接由任何一個發送者向所有接收者發送，多點控制單元用來控制當前發言權。這類應用對帶寬和延時要求都比較高。
資源同步：如日程、目錄、信息等分布資料庫的同步。它們對帶寬和延時的要求一般。
並行處理: 如分布式並行處理。它對帶寬和延時的要求都比較高。
協同處理：如共享文檔的編輯。它對帶寬和延時的要求一般。
遠程學習: 這實際上是媒體廣播應用加上對上行數據流（允許學生向老師提問）的支持。它對帶寬和延時的要求一般。
討論組：類似於基於文本的多點會議，還可以提供一些模擬的表達。
分布式交互模擬（DIS）：它對帶寬和時延的要求較高。
多人游戲: 多人游戲是一種帶討論組能力的簡單分布式交互模擬。它對帶寬和時延的要求都比較高。
Jam Session：這是一種音頻編碼共享應用。它對帶寬和時延的要求都比較高。
多點對點的應用
多點對點應用是指多個發送者，一個接收者的應用形式。通常是雙向請求響應應用，任何一端（多點或點）都有可能發起請求。典型應用包括：
資源查找：如服務定位，它要求的帶寬較低，對時延的要求一般。
數據收集：它是點對多點應用中狀態監視應用的反向過程。它可能由多個感測設備把數據發回給一個數據收集主機。帶寬要求根據采樣周期和精度有所不同，可能會有恆定速率帶寬或突發帶寬要求，通常這類應用對帶寬和延時的要求一般。
網路竟拍：拍賣者拍賣產品，而多個竟拍者把標價發回給拍賣者。
信息詢問: 詢問者發送一個詢問，所有被詢問者返回應答。通常這對帶寬的要求較低，對延時不太敏感。
Juke Box：如支持准點播（Near-On-Demand）的音視頻倒放。通常接收者採用「帶外的」協議機制（如HTTP、RTSP、SMTP，也可以採用組播方式）發送倒放請求給一個調度隊列。它對帶寬的要求較高，對延時的要求一般。
㈤ 聯通網路機頂盒請用組播方式登錄是什麼意思
這個和網路沒有任何關系，出現這個之後首先考慮你的光貓是不是兩個埠，如果是一個請去聯通公司換一個2個埠的光貓。因為現在光貓開始更新了！
把原先插在路由器上的電視接頭，插在光貓上就可以了。
(5)組播訪問流程擴展閱讀
機頂盒功能:
（1）電子節目指南（EPG）。給用戶提供一個容易使用、界面友好、可以快速訪問 想看節目的一種方式，電視節目
（2）高速數據廣播。能給用戶提供股市行情、票務信息、電子報紙、熱門網站等 各種消息
（3）軟體在線升級。軟體在線升級可看成是數據廣播的應用之一。數據廣播服務 器按DVB數據廣播標准將升級軟體廣播下來，機頂盒能識別該軟體的版本號，在版本不同時接收該軟體，並對保存在存儲器中的軟體進行更新
（4）網際網路接入和電子郵件。數字機頂盒 可通過內置的電纜數據機方便地實現網際網路接入功能。用戶可以通過機頂盒內置的瀏覽器上網，發送電子郵件。
同時機頂盒也可以提供各種介面與PC相連，用PC與網際網路連接
（5） 有條件接收。有條件接收的核心是機頂盒加擾和加密，數字機頂盒應具有解擾和解密功能。
㈥ IP組播的交互
（1）多播路由協議（路由器之間的交互）：主要有mospf，dvmrp，pim這三個。
前面兩種協議需要建立自己的多播路由表。大多數路由器只支持pim。
PIM，協議無關性，它不需要建立自己的路由表，關心的只是路由器中有沒有單播路由表，無論這個單播表項是怎樣建立的，通過怎樣的路由協議。
PIM MODE：PIM DM（密集模式，使用源分發樹），
PIM SM（稀疏模式，使用共享分發樹），
PIM SDM（稀疏密集模式，先嘗試使用共享樹，找不到RP再切向源分發樹）
PIM DM，用於用戶密集的情況，如果存在著沒有要求多播的路由器則將其「裁剪」，如果存在著後來接入又需要多播的路由器則將其「嫁接」！
PIM SM，用於用戶分散的情況，只有一棵樹，初始為空，只有路由器發起要求才建立分支。這種模式存在著第一個到目的的數據包會觸發目的向源發送一個單播形式的該數據，如果到源的路徑好過走rp的路徑則自動向最佳路徑切換。
PIM SDM，使用最多的模式,效率最高。
rp的選舉問題，三種方式：手工指定，auto rp（cisco only），BSR自舉路由器（只有pim v2支持）
配置：
(config)#ip mutilcast-routing
(config-if)#ip pim 模式
密集模式的配置：
(config-if)#ip pim dense
稀疏模式的配置：
靜態： (config)#ip mutilcast-routing
(config-if)#ip pim sparse
(config)#ip pim rp-add x.x.x.x
(config)#ip pim spt-thresheld infin / 具體值 指定向源切換的界限
auto： 定義候選者，(config)#ip pim send-rp-amounce 介面 scope ttl值（定義邊界） group-list訪問列表
定義映射代理，(config)#ip pim send-rp-discovery scope ttl值
指定模式，(config-if)#ip pim sp-de mode
注意，要224.0.1.39和224.0.1.40一對組播地址支持rp選舉：
rp映射代理發往rp候選者用224.0.1.40
反過來，用224.0.1.39
BSR：(config-if)#ip pim 1 / 2 更改pim版本號，bsr只支持2
(config-if)#ip pim bsr border 定義多播邊界
(config)#ip pim rp-candidate 介面 定義rp候選者
(config)#ip pim bsr-candidate 介面 定義bsr
這里，bsr用224.0.1.13向候選者通告，候選者用單播回應bsr。
sh ip mroute; sh ip pim int; sh ip pim nei;
sh ip pim rp; sh ip pim bsr; sh ip pim map.
（2）IGMP（Internet組管理協議）處理pc和router的交互。
三個版本：
igmpv1：report（pc發出，地址255.1.1.1，ttl=1）,query（router發出，發項0.0.0.0，60秒一次，120s沒收到report回應則停止向該pc發組播）。
igmpv2：在v1基礎上增加了一個leave消息，query消息的作用就變成了防止pc意外離開（沒有leave消息，不被router所知）。
igmpv3：可以對信源地址做控制了，選擇pc需要的特定多播。
另外還有一個igmpv3lite，是cisco私有的過渡方案，目的是讓程序員能立刻編寫ssm。
（3）switch的多播處理：cgmp和switch snooping
CGMP：思科私有協議，運行於思科交換機與思科路由器之間，讓交換機能夠通過路由器給出的消息間接支持組管理。
流程大致是：pc發igmp告知路由器我需要什麼多播，如果路由器就直接把多播傳入則經過交換機的時候會被交換機發向與該pc一個vlan的所有主機，router需要將該多播的mac通告交換機，讓其明白多播具體該發向哪，並建立一個多播的轉發表。
IGMP snooping：公有協議，只要交換機單獨運行即可。它是靠幀聽igmpreport來建立多播轉發表的。所以對於2層交換機，因為看不到3層信息，所以要監聽每一個組播幀，從中發現igmp成員報告，這樣加大了cpu等資源的使用，比較不利；而對於3層交換機，能夠看到3層信息，可以識別igmp成員報告，只要處理igmp流即可，所以負擔輕。
㈦ 想寫一個組播的程序，不知道伺服器地址該用什麼
你是要做一個組播伺服器程序嗎？如果是，你的伺服器應該要支持IGMP協議。
你現在想讓組播伺服器在公網上轉發數據，進行實驗。我認為這種實驗方法存在2個問題：
1，網路環境不具備。你的組播報文從伺服器到主機的過程中需要經過一系列switch和router,所有這些設備必須都支持組播協議，才會形成組播樹，將你的消息轉發到所有主機。（這個外部的環境不可控）。
2、即使一系列的網路設備支持，網路運營商也不會允許私人隨意佔用 組播IP地址。
建議你自己搭建一個私網環境進行實驗。在這個環境中，只要你的伺服器和主機都處在相同的組播組中，就可以了。在這個私網環境中，224.0.1.1是一個合法的組播IP.
㈧ 區域網中單播，廣播和組播的工作過程，怎麼寫
單播：信息的接收和傳遞只在兩個節點之間進行
多播：一次傳送所有目標節點的數據，也可以達到只對特定對象傳送數據的目的
廣播：主機之間一對所有的通訊模式