TCP/IP 協定與 Internet 網路:第五章 網際層協定 上一頁 下一頁
5-5 IGMP 協定
『網際群組管理協定』(Internet Group Management Protocol, IGMP)(RFC 1112)是作為管理 Internet 網路群組使用,譬如,主機或路由器如何加入某一群組或退出群組。當主機或路由器屬於某一群組後,便可依照群組位址向群組中的成員作多點傳送,如不屬於群組成員就無法收到該訊息。我們在 5-2-5 節有介紹過 IP 多點傳送是利用 Class D 位址格式,而 IGMP 是管理網路群組中,有關 Class D 位址的設定及分配問題。簡單的說,我們將一些主機或路由器組成一個群組,並給予一個 Class D 的位址,如果某一主機向該群組傳送資料時,只有該群組的成員可以接收到訊息,也稱之為『多點傳送』。基本上,每一個主機都有一個獨一無二的 IP 位址,如何再增加一個網路群組位址(Class D),則需要利用 IGMP 協定來管理群組之中的成員。
5-5-1 多點傳送位址
依照 IP 分級的歸類,Class D 等級位址為多點傳送位址,它的位址格式如圖 5-41 所示。
圖 5-41 Class D IP 多點傳送位址
如以一般 IP 位址表示法,Class D 的位址範圍是:
224.0.0.0 ~ 239.255.255.255
一般應用上會將 224.0.0.0 保留而不分配給任何群組。另外 224.0.0.1 為特殊群組,表示網路上任何主機或路由器都屬於該群組的成員,雖然如此定義這個群組的成員,已非常接近廣播位址(所有成員),其間仍有差別,如果主機或路由器沒具有接收群組位址的功能,它仍不會收到目的地為 224.0.0.1 的訊息。
一般 IP(Class A ~ Class C)欲被發送到網路上之前,在資料連結層(Ethernet 層),必須將 IP位址轉換成 Ethernet 位址,也許會透過 ARP 協定來詢問該 IP 位址的相對應 Ethernet 位址。但如果 IP 位址為 Class D 群組位址時,便無法透過 ARP 協定來詢問相對應的 Ethernet 位址,這應如何來達成多點傳送之目的呢?如果主機或路由器的網路卡沒有特殊的處理能力,當它準備發送多點傳送的 IP 位址時,它的 Ethernet 層便將目的位址(Ethernet 位址)設定為廣播位址(全部都為 1),讓網路上所有主機都接收到該訊框,再由上一層的通訊軟體來決定是否接受該訊息。雖然這種做法可以達到多點廣播的目的,但是整個網路的負荷會增加許多。譬如,一個視訊伺服器(VoD)欲廣播視訊給網路上 20 個收視的主機,但當時連線的主機有 100 部,則 100 部主機都必須接收該訊息,再由上層通訊軟體決定是否接收。
為了達到 Ethernet 層有多點傳送的功能,我們可以利用 Ethernet 網路的群組位址,其為 0x01.00.5E.00.00.00(48 位元)。而將 IP 多點傳送位址植入 Ethernet 群組位址上,植入的方法是將 IP 多點傳送位址的最後 23 位元,放置到 Ethernet 位址的後 23 位元內,如以 224.0.0.1 的位址對應到 Ethernet 位址是 0x01.00.5E.00.00.00.01,其對應方法如圖 5-42 所示。
圖 5-42 IP Class D位址植入 Ethernet 群組位址
這種植入法也有先天的缺點,多點傳送位址有 28 位元(32 - 4)的變化,而Ethernet 位址只能植入 23 位元,如果超過 23 位元的地址便無法被植入 Ethrnet 位址上,這可能會有不同的多點傳送位址而產生相同的 Ethernet 群組傳送位址。為了解決這個問題,我們儘量將 IP 多點位址設定在低位元組,在一般網路上的群組位只要超過 23 位元的表示量,這種機會可以說非常渺小,因此在使用上應該不會發生問題。
5-5-2 主機分類
在多點傳送的網路環境裡,我們可以將參與主機(或路由器)區分為下列三個等級:
● 等級 0(Level 0):此等級的主機沒有能力傳送或接收 IP 多點傳送封包。也有可能是該主機不參與網路任何群組的成員,當它決定參與群組時,可能會升級到等級 1 或 2。
● 等級 1(Level 1):此等級的主機可以傳送但無法接收 IP 多點傳送封包。一般此等級的主機或路由器都是週期性的廣播訊息給同一群組的成員,而它的功能也比較簡單,只要具有能將 IP 群組位址轉換成 Ethernet 的群組位址即可。
● 等級 2(Level 2):此等級主機具有傳送和接收 IP 多點傳送封包的功能。如具有接收 IP 多點傳送的功能則較為複雜,因為主機上的應用程式隨時都有可能加入或退出某一群組,主機必須能隨時決定是否接收某一群組的訊息。
一般網路上有參與群組工作的主機都具有等級 2 的能力。我們從另一觀點來看,主機是否參與某一群組是由它的應用程式(或稱為處理程序)來決定。也就是說,某一主機上也許會有許多應用程式各自參與不同群組,或者某一應用程式同時成為若干個群組的成員,因此,一個主機也許會屬於多個群組的成員,也可能隨時退出某一群組,這完全決定於該主機的應用程式。所以一般主機都必須維護一個多點傳送的表格,以紀錄當時每一個多點傳送位址有哪些應用程式銜接,或退出哪一群組。當主機接收到 IP 多點傳送封包時,再查閱該群組位址是否有應用程式使用。至於網路上主機如何要求加某一群組,或退出某一群組,這必須由參與群組的成員共同來協調,它們之間就必須利用 IGMP 協定來互相傳送訊息來從事協調的工作。
5-5-3 IGMP 封包結構
IGMP 也是屬於網際層的通訊協定之一,傳輸方式如同 ICMP 一樣,被包裝在 IP 封包內傳送。但 IGMP 有固定大小的封包,並沒有選擇性的訊息資料。IGMP 的封包為 8 位元組,再加上 IP 標頭 20 位元組,合計有 28 位元組,如圖 5-43 所示。
圖 5-43 IGMP 崁入 IP 封包中
圖 5-44 為 IGMP 封包格式,其中各欄位功能如下:
● 版本(Version):目前版本都為 1。
● 型態(Type):IGMP 的封包型態區分為兩種:
★ 查詢(Inquiry):(Type = 1)由多點傳送路由器(或主機)發送的查詢訊息。
★ 回應(Response):(Type = 2)由主機傳送的回應訊息。
● 標頭檢查集(Header Checksum):封包標頭的檢查集。
● 群組位址(Group Address):是一個 Class D 的 IP 位址。當 IGMP 封包為查詢時(Type = 1),該欄位內容為 0。
圖 5-44 IGMP 封包格式
5-5-4 IGMP 協定運作
IGMP 協定的主要功能是作為網路上路由器(或主機)之間協調如何加入某一群組,或由某一群組中退出,當路由器成功加入群組之後,便可依照群組位址和同一群組的成員相互通訊,而達到多點傳送的目的,以下介紹 IGMP 協定的運作情形。
(A) 加入一個多點傳送群組
加入多點傳送群組的基本概念,是讓處理程序(Process)加入主機給予的特定介面。一個群組位址給予一個特定介面,給予處理程序隨時加入或退出,在一部主機上也許維護多個群組界介面,而一個處理程序也可能加入多個群組。此群組介面是讓處理程序和群組中的成員連結在一起,當程序加入群組介面後,或許會由介面上接收訊息或發送多點傳送訊息,這些訊息都必須經過 IP 層包裝或拆裝成 IP 多點傳送封包。因此,在主機系統裡必須提供群組傳送的 API 介面,以提供多點傳送連接,一般在 Unix 系統裡都有提供多點傳送的 Socket 介面,其連結情形如圖 5-45 所示。
圖 5-45 處理程序加入群組之連結情形
由圖中可以看出,主機是藉由群組位址和 Socket 介面來辨識群組,因此,主機必需維護一個包含所有群組(至少有一個處理程序屬於該群組成員)的表格,以及屬於該群組之處理程序的參考數量。
(B) IGMP 報告與查詢
IGMP 訊息被多點傳送路由器用來追蹤網路上各路由器連接群組的情形,它的運作規則如下:
(1) 當第一個處理程序加入群組時,主機傳送一個 IGMP Response 報告。假如有多個處理程序加入同一群組,只需送出一份報告即可。這個報告被送到的介面與處理程序所加入的群組介面相同(如圖 5-46 所示)。
(2) 當處理程序離開群組時,主機不會送出報告(IGMP Response),即使是最後一個成員也是一樣。如果主機知道給定的群組中沒有成員,而收到 IGMP Inquiry 查詢時,也不會向該群組報告(不會送出 IGMP Response)。
(3) 一個多點傳送路由器(或主機),會在固定時間週期內送出 IGMP Inquiry 查詢,以查看是否有任何主機仍然有屬於任何群組的處理程序。路由器必需針對每一個介面傳送查詢訊息,查詢中的群組位址為 0(圖 5-44 中的 Group Address 欄位),因為路由器希望每個群組(在主機上有一個或數個成員)的主機都有一個回應。
(4) 主機收到 IGMP Inquiry 訊息後,以 IGMP Response 回應給群組,也表示所回應之群組至少還有一個以上的處理程序連接。
多點傳送路由器必需維護一個記錄著多點傳送群組中擁有一個或數個主機介面的表格,當路由器收到一個必須往前送(Forward)的多點傳送封包,它只將該封包往前送到下一個介面,該介面仍有主機和屬於該群組的處理程序。圖 5-46 為 IGMP Inquiry 和 IGMP Response 訊息發送情形,IGMP Inquiry 是路由器用來查詢主機上群組登錄的情形,而 IGMP Response 是主機用來回應路由器的查詢。
圖 5-46 IGMP 協定運作情形
(C) 存活時間(TTL)
多點傳送封包上的存活時間(Time-to-Live, TTL)顯得特別重要,因該欄位是在 IP 封包標頭上(請參考圖 5-10)。TTL 上的值乃決定多點傳送封包可跨越多少網路傳送,TTL =1 表示此封包只在同一子網路上傳送。路由器收到封包時,由 TTL 上的值決定是否往其它子網路傳送,如果(TTL –1)的值大於 0,則往下一個子網路作多點傳送。一般為了限制封包的傳輸量,都不會將 TTL 的值設定太大,應用實際環境下,同一群組成員也不會位於跨越太多的網路上。當路由器判斷 TTL = 0 時,就不會回應 ICMP 封包給原發送端。
(D) IGMP 協定實作
為了提高 IGMP 協定的執行效率,在實作上必須增加下列細節:
(1) 當主機傳送一個初始的 IGMP 報告時,並不保證該報告一定會被送達(因 IP 是電報傳輸),通常主機都會等待 0 ~ 10 秒的隨機時間,再傳送另一個報告。
(2) 當主機收到來自路由器的查詢,並沒有立即回應,而把回應排在最後(或等待一個隨機延遲時間)。當它發現有相同群組的成員回應給路由器,便可省略而不予回應,由圖 5-46 中可看出主機回應報告的目的位址為群組位址,因此,同一群組的成員也可以收到其它主機的回應訊息。
如圖 5-46,路由器所發送查詢訊號的目的位址為網路上所有主機和路由器(IP = 224.0.0.1),這也表示任何有群組介面的主機都可以給予回應,如果大家都即時回應恐造成封包風暴。由另一方面,對於多點傳送路由而言,乃希望知道所管轄的群組是否還有成員存在,至於多少成員並不重要,因此無需每一個主機都回應。