IGMP Version 1

2. IGMP Version 1

IGMP Version 1使用Query-Response模型來允許群播路由器和多層次交換器來確定在本網段內哪個群播群組是啟動的。在這個模型中，路由器或交換器充當IGMP 查詢路由器，每隔60秒週期性地發送IGMP Version 1 Membership Query給224.0.0.1。啟用群播的所有主機監聽該位址並接收Query Packet。主機以IGMP Version 1 Membership Report回覆，表示它要接收特定Group的Multicast Traffic；該網段中的路由器或交換器就可以了解群播群組中有哪些接收者。

主機可以通過發送一個或多個主動的Membership Report封包表明加入(Join)一個群播群組。如: 某個主機主動發送一個Report封包表明要接收群播群組(224.1.1.1)的流量。

主機通過停止處理群播群組訊務以及不回應IGMP Query的方式來離開群播群組。

IGMP Version 1依靠L3的IP Multicast Routing Protocol(PIM、DVMRP等)來解決同一網段中哪個路由器或多層次交換器成為查詢路由器。查詢路由器發送IGMP Version 1的Query來確定哪個群播群組是啟動的。通常Designated Router會被選擇為查詢路由器。IGMP Version 1的封包有2種：Member Query(224.0.0.1, 每60秒查詢一次)與Member Report。

主機群可以加入群播群組，但是IGMP Version 1沒有Leave訊息，路由器或多層次交換器需透過一個逾時機制的運作，讓那些沒有人接收的訊務不再送到不需要的主機成員。

圖5.1 IGMP Version 1封包格式

表 5.2 IGMP所使用Checksum函式

static unsigned short in_cksum(unsigned short *addr, int len) { int nleft = len; int sum = 0; unsigned short *w = addr; unsigned short answer = 0; while (nleft > 1) { sum += *w++; nleft -= 2; } if (nleft == 1) { *(unsigned char*)(&answer) = *(unsigned char*)w; sum += answer; } sum = (sum >> 16) + (sum & 0xffff); answer = ~sum; return (answer); }

IGMP (2)

群播IP位址

IANA(Internet Assigned Numbers Authority)定義了由 224.0.0.0 到 239.255.255.255 的 Class D 位址範圍內，Class D 位址保留及指派IP群播位址使用。Class D位址的前四個位元永遠是1110，與Class A、B、C位址範圍很不一樣的是，Class D不再區分子網段，故扣除固定的前四個位元，剩下的28個位元共可以產生2²⁸個群播群組。

下表是常見的 D 類別位址的部份清單，這些位址保留給IP群播所使用，並且在IANA登錄的。除此之外，仍有一些範圍的IP保留給開放及商業群組，在指定時須特別留意。

表5.1 Class D群播保留位址

IP 群播位址	描述
224.0.0.0	基本位址 (保留)。
224.0.0.1	「所有主機」群播群組包含相同網路區段上的所有系統。
224.0.0.2	「所有路由器」群播群組包含相同網路區段上的所有路由器。
224.0.0.5	「開放最短路徑優先 (OSPF)」All SPF Routers 位址。用來將 OSPF 路由資訊傳送到網路區段上所有 OSPF 路由器。
224.0.0.6	OSPF All Designated Routers 位址。用來將 OSPF 路由資訊傳送到網路區段上 OSPF 指定路由器。
224.0.0.9	RIP Version 2 群組位址。用來將 RIP 路由資訊傳送到網路區段上所有 RIP v2 路由器。
224.0.1.24	WINS 伺服器群組位址。用來支援 WINS 伺服器複寫的自動發現及動態設定。

群播有趣的是，來源端無須知道群組中有哪些接收端，接收者可以隨時加入或離開群組，這與電視廣播或電台是一樣的。群播 IP 傳輸會傳送到單一位址，但是卻由多個主機來處理。只有隸屬於群播群組的主機，會接收並處理傳送到群組的資訊。正在接聽指定的IP 群播位址的主機群組，稱為群播群組。

若來源端與接收端在同一LAN中，接收端只要調成接收此群播位址，即可接收資料。但若來源端與接收端不在同一LAN中，亦或說中間有經過路由器，此時情況較為複雜，路由器是可以選擇將群播的封包轉送到所有的LAN中，這樣的做法如同廣播，違反了群播的基本精神，沒有節省到網路資源。所以，路由器必須知道哪個網路內有隸屬於此群組的成員，方式就是透過查詢。每個版本的 IGMP 都會定義通訊協定，以用來交換及更新群播群組中指定主機成員的相關資訊。

傳送Query給此子網段中所有的系統，位址為224.0.0.1，或傳送給特定的群組位址，若有主機有回應時，則路由器才將封包轉送到此子網路。若於特定時間內，沒有主機做回應時，路由器將視為此子網段內，沒有主機需要此份封包，而停止轉送。

為了減少傳送的等待時間，主機端會主動發出Report訊息給路由器，當路由器收到Report訊息時，會馬上轉送該群播群組的訊務到主機所屬的子網路，而子網路中只要送出一個Report就夠了。或者由主機主動發送Leave訊息給路由器，告知此成員退出這個群播群組。

IP 群播的其他重要方面包含下列項目：成員資格是動態的，允許主機隨時加入及離開群組。將主機加入群播群組的能力乃是透過傳送IGMP的訊息來實現。如果連線路由器支援IP群播及群組成員資格資訊的傳播，則群組大小不受限制，成員可以屬於多個 IP 網路中。

Class D保留範圍中的單一IP位址識別每個群播群組。每個群組的所有主機成員共用該群組所保留的IP位址，他們接聽及接收任何傳送到該群組 IP 位址的資訊。將IP群播位址對應到一組保留的媒體存取控制群播位址。Ethernet與FDDI介面把群播IP位址較低的23個位元對應到保留MAC位址較低的23個位元，以形成群播MAC位址，如CLASS D的IP位址235.147.18.40(十六進位為EB.93.12.28)用來形成MAC位址0100.5E13.1228。

網際網路群組管理通訊協定(1)

第一份有關群播的RFC於1986年由Steve Deering撰寫完成，但大家對於了在群播的需求是近幾年來才開始興起的，因為企業界對於一對多乃至於多對多的傳輸需求增加，而單播的對於每一個連線均複製發送一份封包，消耗掉過多的骨幹網路頻寬，且造成發送端的多重負擔，若使用廣播的方式傳送資料則會增加網路上其他主機的負擔，因為不管主機需不需要這一筆資料，使用廣播的方式均會傳送。

遍及整個Internet的群播，必需等待跨AS(inter-as)通訊協定的研究發展完成，例如Multi-protocol BGP(MBGP)及Border Gateway Multicast Protocol(BGMP)等。沒有適當的協定出現，群播勢必無法於Internet上普及。

RFC 1112「Host Extensions for IP Multicasting」中，定義 IP 群播在 TCP/IP 網路中的使用標準。除了定義群播位址及主機如何支援群播外，此 RFC 也定義「Internet Group Management Protocol, Version 1」。RFC 2236「Internet Group Management Protocol, Version 2」則定義 IGMP Version 2。目前中華電信IPTV環境中，群播電視使用IGMP Version 2，也就是說每一個頻道只會指定群播IP與Port，無法指定來源IP，故當一個Group IP由兩個以上的來源端同時發送時，解碼器會夾雜接收數個串流，而導致畫面無法解碼，也會超過DSL所能承載的頻寬而掉封包。

使用「Internet Group Management Protocol, Version 3」 之後，主機可指定要由特定的來源端接收群播的流量，可以是一部編碼器或是支援群播的視訊伺服器，也可以由指定特定來源以外的所有來源端接收群播流量。以下分別介紹IGMP Version 1、Version 2與Version 3。

[IPTV] 實作MPEG2視訊分析 - 簡介視訊監控儀(3)

IneoQuest Geminus系列

圖IneoQuest Geminus G10

Geminus IPTV品質視訊測試儀是一個從1G~10Gbp的視訊監控、分析、模擬及測試的工具，比較特別的這套機組是採模組化設計，可擴展的硬體平臺。可依需要與使用介面購買卡板。

Geminus系列包含 G10 Max、G10 Base、G2X Max、G2X Base及Geminus G1-T，Geminus G2X 與 Geminus G1-T可連接至1Gb的視訊網路，Geminus G10則可連接於10 Gb的視訊網路。

所有Geminus系列針對視訊監控及分析均提供擴充性，G10 Max 與 Geminus G1-T提供一條實體的訊務產生線路供模擬用。

IneoQuest的設備能夠針對IPTV即時品質監測、障礙定位和視訊流模擬。運用高速FPGA晶片，Geminus平臺提供10Mbps到10Gbps速率，同時支援IPTV視訊品質監測和障礙定位的完整解決方案。根據不同的模組，Geminus提供多樣的硬體測試組合。產品功能如下：

• 最多即時監控及量測2000個Video Stream。

• 最多4個streaming port，4個1Gbps或者2個10Gbps。

• 支援10/100/1000 Mbps LX及TX。G10模組支援10 Gbps XFP port。

• 依據需要定義告警門檻。

• 自動從MPEG-2 Transport Stream檢測節目名稱(需來Source端有提供)。

• 記錄即時節目和回傳即時解碼到監控中心(實用度待商確)。

• 支持多種的視訊格式（MPEG2，MPEG-4，H.264，VC1，AVS，MPEG-2 TS， ISMA）。

• 支援RFC3357 RTP 傳輸品質分析。

• 依據PID的告警值進行監測和告警。

• 支援SNMP 和 Syslog 數據收集。

• HTML使用者介面。

 

 

IneoQuest由於對台灣某IPTV業者使用的系統沒有全面進行客制化，所有對於Unicast與NVOD主機Pumping出的Multicast串流無法解析，其實這部份筆者還幫原廠throuble-shooting，提供RTSP語法，對於要賣設備的廠商，比購方不熟這一點是不及格的，後來廠商還打著我的名號到其他分公司推廣，其實像我這種小咖，就不用報出大名出來了，而且替不合用的設備背書，自己挖坑自己跳？其實RTSP與IGMP語法非常簡單，這次本公司的升資考試還有考到IGMP Version1的protocol，剛好我有Implement過，關於這部份後面的章節會講到。一直欠東欠西真不好意思，但內容真的很多，就請大家忍耐一下。

 

上一篇: [IPTV] 實作MPEG2視訊分析 - 簡介視訊監控儀(2)
http://ithelp.ithome.com.tw/question/10053086

下一篇: [IPTV] 網際網路群組管理通訊協定(1)
to be continued...

中華電信九月份營業收入159.4億元

 

中華電信九月份營業收入159.4億元

中華電信公司九十九年九月份自結營業收入159.4億元，較去年同期成長1.9 %，累計一至九月營業收入1385.9億元，較去年同期成長1.5 %。在營業利益方面，九月份及累計一至九月分別為41.7億元及431.0億元，較去年同期分別減少3.4 %及成長2.2 %。在純益方面，九月份及累計一至九月分別為35.9億元及369.8億元，較去年同期分別減少2.5 %及成長11.5 %。在每股稅後盈餘方面，九月份及累計一至九月分別為0.37元及3.81元，較去年同期之0.38元及3.42元分別減少2.5%及成長11.5%。

在第三季財務預測達成方面，累計七至九月份營業收入為468.1億元，達成本季財務預測464.2億元之100.9%；營業利益為140.1億元，達成本季財務預測139.5億元之100.4   %；稅前利益為142.0億元，達成本季財務預測141.1億元之   100.6%；每股稅後盈餘1.23元，達成本季財務預測1.22元之101.1%。

該公司表示，九月份營業收入較去年同期成長1.9 %，主要係因客戶專案建置、行動加值及寬頻接取營收成長抵銷了費率調降對相關營收之衝擊。累計一至九月份營業收入較去年同期成長，主要來自於行動加值與智慧型手機銷售，以及網際網路與加值、企客ICT及其它服務、寬頻接取、國際數據交換等營收增加所致。至於營業利益方面，九月份較去年同期減少1.5億元，主因費率調降對營收造成衝擊，加上認列客戶專案建置成本與估列獎金及員工紅利增加等所致。累計一至九月營業利益則因營收較去年同期成長而增加。至於每股稅後盈餘成長，除因營業利益增加外，亦受惠於政府調降營利事業所得稅稅率至17%。

由於行動上網服務營收大幅成長，該公司累計一至九月之行動加值收入較去年同期成長29.2%，占行動服務營收達14.6%。寬頻(含ADSL及FTTB) 8M以上高速率用戶數達229萬戶，其中光世代用戶數持續成長，累計用戶數已達196萬戶。