協定簡介
主機IP軟體需要進行組播擴展,才能使主機能夠在本地完了過上收發組播分組。但僅靠這一點是不夠的,因為跨越多個網路的組播轉發必須依賴於路由器。路由器為建立組播轉發路由必需了解每個組員在Internet中的分布,這要求主機必須能將其所在的組播組通知給本地路由器,這也是建立組播轉發路由的基礎。主機與本地路由器之間使用
Internet組管理協定(IGMP,Internet Group Management Protocol)來進行組播組成員信息的互動。在此基礎上,本地路由器再你信息與她組播路由器通信,傳播組播組的成員信息,並建立組播路由。這個過程與路由器之間的常規單播路由。這個過程與路由器之間的常規單播路由的傳播十分相似。IGMP是
TCP/IP中重要標準之一,所有IP組播系統(包括主機和路由器)都需要支持IGMP協定。
組播協定包括組成員管理協定和組播路由協定。組成員管理協定用於管理組播組成員的加入和離開,組播路由協定負責在路由器之間互動信息來建立組播樹。IGMP屬於前者,是組播路由器用來維護組播組成員信息的協定,運行於主機和和組播路由器之間。IGMP 信息
封裝在IP
報文中,其IP的協定號為2。
若一個主機想要接收傳送到一個特定組的組播數據包,它需要監聽發往那個特定組的所有數據包。為解決Internet上組播數據包的路徑選擇,主機需通過通知其子網上的組播路由器來加入或離開一個組,組播中採用IGMP來完成這一任務。這樣,組播路由器就可以知道網路上組播組的成員,並由此決定是否向它們的網路轉發組播數據包。當一個組播路由器收到一個組播分組時,它檢查數據包的組播目的地址,僅當接口上有那個組的成員時才向其轉發。
IGMP提供了在轉發組播數據包到目的地的最後階段所需的信息,實現如下雙向的功能:
主機通過IGMP通知路由器希望接收或離開某個特定組播組的信息。
路由器通過IGMP周期性地查詢區域網路內的組播組成員是否處於活動狀態,實現所連網段組成員關係的收集與維護。
IGMP共有三個版本,即IGMP v1、v2 和 v3。
IGMP v1
IGMPv1 定義了主機只可以加入組播組,但沒有定義離開成員組的信息,路由器基於成員組的逾時機制發現離線的組成員。
IGMPv1 主要基於查詢和回響機制來完成對
組播組成員的管理。當一個
網段內有多台
組播路由器時,由於它們都能從
主機那裡收到IGMP 成員關係報告
報文(Membership Report Message),因此只需要其中一台路由器傳送IGMP查詢
報文(Query Message)就足夠了。這就需要有一個查詢器(Querier)的選舉機制來確定由哪台
路由器作為IGMP 查詢器。對於IGMPv1 來說,由
組播路由協定(如PIM)選舉出唯一的
組播信息轉發者DR(Designated Router,
指定路由器)作為IGMP 查詢器。
IGMPv1 沒有專門定義離開
組播組的報文。當運行IGMPv1 的
主機離開某組播組時,將不會向其要離開的組播組傳送報告
報文。當
網段中不再存在該
組播組的成員後,IGMP
路由器將收不到任何發往該組播組的報告
報文,於是IGMP 路由器在一段時間之後便刪除該組播組所對應的組播轉發項。
IGMPv2
iGMPv2 是在版本1 上基礎上增加了主機離開成員組的信息,允許迅速向路由協定報告組成員離開情況,這對高頻寬組播組或易變型組播組成員而言是非常重要的。另外,若一個子網內有多個組播路由器,那么多個路由器同時傳送IGMP 查詢報文不僅浪費資源,還會引起網路的堵塞。為解決這個問題,IGMPv2。不同使用路由選舉機制, 能在一個子網內查詢多個路由器。
igmp版本2對版本1所做的改進主要有:
共享
網段表示一個網段上有多個
組播路由器的情況。在這種情況下,由於此
網段上運行igmp的
路由器都能從
主機那裡收到成員資格報告訊息,因此,只需要一個
路由器傳送成員資格查詢訊息,這就需要一個
路由器選舉機制來確定一個路由器作為查詢器。其選舉過程如下:
(1) 所有IGMPv2
路由器在初始時都認為自己是查詢器,並向本地網段內的所有
主機和路由器傳送IGMP 普遍組查詢(General Query)
報文(目的地址為:224.0.0.1);
(2) 本地網段中的其它IGMPv2
路由器在收到該
報文後,將報文的源IP 地址與自己的接口地址作比較。通過比較,IP 地址最小的
路由器將成為查詢器,其它路由器成為非查詢器(Non-Querier);
(3) 所有非查詢器上都會啟動一個定時器(即其它查詢器存在時間定時器OtherQuerier Present Timer)。在該定時器逾時前,如果收到了來自查詢器的IGMP查詢
報文,則重置該定時器;否則,就認為原查詢器失效,並發起新的查詢器選舉過程。
在igmp版本1中,查詢器的選擇由
組播路由協定決定;igmp版本2對此做了改進,規定
同一網段上有多個組播
路由器時,具有最小ip地址的組播路由器被選舉出來充當查詢器。
(2)igmp版本2增加了離開組機制
在igmp版本1中,
主機悄然離開
組播組,不會給任何組播
路由器發出任何通知。造成
組播路由器只能依靠組播組回響逾時來確定組播成員的離開。而在版本2中,當一個
主機決定離開時,如果它是對一條成員資格查詢訊息作出回響的主機,那么它就會傳送一條離開組的訊息。
(1) 該
主機向本地網段內的所有
組播路由器(目的地址為224.0.0.2)傳送離開組(Leave Group)
報文;
(2) 當查詢器收到該
報文後,向該
主機所聲明要離開的那個
組播組傳送特定組查詢(Group-Specific Query)報文(目的地址欄位和組地址欄位均填充為所要查詢的組播組地址);
(3) 如果該網段內還有該
組播組的其它成員,則這些成員在收到特定組查詢
報文後,會在該報文中所設定的最大回響時間(Max Response Time)內傳送成員關係報告報文;
(4) 如果在最大回響時間內收到了該
組播組其它成員傳送的成員關係報告
報文,查詢器就會繼續維護該組播組的成員關係;否則,查詢器將認為該
網段內已無該組播組的成員,於是不再維護這個組播組的成員關係。
(3)igmp版本2增加了對特定組的查詢
在igmp版本1中,
組播路由器的一次查詢,是針對該
網段下的所有組播組。這種查詢稱為普遍組查詢。
在igmp版本2中,在普遍組查詢之外增加了特定組的查詢,這種查詢
報文的目的ip地址為該
組播組的ip地址,報文中的組地址域部分也為該組播組的ip地址。這樣就避免了屬於其它
組播組成員的主機傳送回響
報文。
(4)igmp版本2增加了最大回響時間欄位
igmp版本2增加最大回響時間欄位,以動態地調整
主機對組查詢
報文的回響時間。
IGMPv3
IGMPv3 在兼容和繼承IGMPv1 和IGMPv2 的基礎上,進一步增強了
主機的控制能力,並增強了查詢和報告
報文的功能。
IGMPv3 增加了針對
組播源的過濾模式(INCLUDE/EXCLUDE),使
主機在加入某組播組G 的同時,能夠明確要求接收或拒絕來自某特定組播源S 的組播信息。當
主機加入
組播組時:
若要求只接收來自指定
組播源如S1、S2、……的組播信息,則其報告
報文中可以標記為INCLUDE Sources(S1,S2,……);
若拒絕接收來自指定
組播源如S1、S2、……的組播信息,則其報告
報文中可以標記為EXCLUDE Sources(S1,S2,……)。
IGMPv3 不僅支持IGMPv1 的普遍組查詢和IGMPv2 的特定組查詢,而且還增加了對特定源組查詢的支持:
z 普遍組查詢
報文中,既不攜帶組地址,也不攜帶源地址;
z 特定組查詢
報文中,攜帶組地址,但不攜帶源地址;
z 特定源組查詢
報文中,既攜帶組地址,還攜帶一個或多個源地址。
IGMPv3 報告
報文的目的地址為224.0.0.22,可以攜帶一個或多個組記錄。在每個組記錄中,包含有
組播組地址和組播源地址列表。組記錄可以分為多種類型,如下:
IS_IN:表示
組播組與組播源列表之間的過濾模式為INCLUDE,即只接收從指定組播源列表發往該組播組的組播數據。
IS_EX:表示
組播組與組播源列表之間的過濾模式為EXCLUDE,即只接收從指定組播源列表之外的組播源發往該組播組的組播數據。
z TO_IN:表示
組播組與組播源列表之間的過濾模式由EXCLUDE 轉變為INCLUDE。
TO_EX:表示
組播組與組播源列表之間的過濾模式由INCLUDE 轉變為EXCLUDE。
ALLOW:表示在現有狀態的基礎上,還希望從某些
組播源接收組播數據。如果當前的對應關係為INCLUDE,則向現有
組播源列表中添加這些組播源;如果當前的對應關係為EXCLUDE,則從現有
組播源列表中刪除這些組播源。
BLOCK:表示在現有狀態的基礎上,不再希望從某些
組播源接收組播數據。如果當前的對應關係為INCLUDE,則從現有組播源列表中刪除這些組播源;如果當前的對應關係為EXCLUDE,則向現有組播源列表中添加這些組播源。
實現步驟如下:
1、當主機某個進程加入一個組播組時,主機傳送一個IGMP 報告。若一個主機多個進程同時加入同一組,則傳送一個IGMP 報告。
2、進程離開一個多播組時,主機不傳送IGMP 報告,即便是組中最後一個進程離開多播組。當主機確定已不再有組成員後,在隨後收到的IGMP 查詢中就不應答報文。
3、多播路由器定時傳送IGMP 查詢是否還有其他主機包含有屬於多播組的進程。多播路由器必須向每個接口傳送IGMP 查詢。
4、主機通過傳送IGMP 報告來回響一個IGMP 查詢,對每個至少還包含一個進程的組均要發回IGMP 報告。
使用上述查詢和報告報文,多播路由器對每個接口保持一張映射表,表中記錄了接口上包含的一個或多個主機多播組。當路由器收到要轉發的多播數據報時,只需將該數據報轉發到該接口上。
IGMP 組播中存在的問題
組播的可靠性
IP 組播使用用戶數據報UDP 協定,然而UDP 是盡最大能力投遞的一種協定。因此,IP 組播套用勢必會遇到數據包丟失和亂序問題。為此,對於IGMP 不同類型的套用必須在確認方式( 肯定確認ACK 和否定確認NACK),集中確認與分布確認、重傳機制、流量控制、擁塞控制等方面綜合考慮,提出解決反案。迄今為止,儘管在廣域網環境中已經存在許多可靠組播協定,包括可靠組播協定RMP(ReliableMulticast Protocol),可擴可靠組播SRM(Scalable Reliable Multicast),和可靠組播傳輸協定RMTP(ReliableMulticast Transport Protocol)。組播的可靠性研究仍然是重點研究課題之一。
組播的安全性
組播安全性是只有註冊的主機才能夠向組傳送數據和接收組播數據。
然而IP 組播很難保證這一點。首先,IP 組播使用UDP,網路中任何主機都可以向某個組播地址傳送UDP 包;其次,Internet缺少對於網路層的訪問控制,組成員可以隨時加入和退出組播組,使得組播安全性問題仍然是一個技術難點。
IGMP 組播協定是IPv4 環境下重要的協定。IGMPv1 實現簡單,但是主機離開多播組延遲過大,選擇查詢路由器需要依賴具體的組播路由協定;IGMPv2缺少對主機進程加入多播組的定義,制約了其套用範圍。IGMPv3 主要改進是支持源特定組播。大部分的網路設備和主機作業系統協定棧都支持IGMPv1 和IGMPv2,但為適應複雜的網路需求,必須大力推進IGMPv3 協定的用套用。Windows XP 已經支持IGMPv3 ,UNIX 作業系統也可以與IGMP v1/ v2 版本向後兼容,組播技術有著廣闊的發展前景。
IGMP組播成員查詢
IGMP的組成員查詢利用報文中類型欄位0x11來標識。IGMP的組成員查詢包含了兩種子類型:一般組成員查詢(General Query)和特定組成員查詢(Group-Specific Query)。子類型利用報文中的組播組地址(Group Address)欄位來區分:組地址段等於0,表示一般組成員查詢;組地址地段不等於0,則表示特定組成員查詢,用於查詢本地網路中的每個指定組播組的成員,其中組播組的地址由組地址(Group Address)欄位來指定被查詢的組播組。在IGMPv1中只支持一般組成員查詢,IGMPv2支持特定組成員查詢。
一般組成員查詢
IGMP約定,本地路由器利用一般組成員查詢方式來周期性地向本網路內的所有主機傳送IGMP組成員查詢報文;本地網路中的主機在接收到IGMP查詢報文時,將會對該報文作出相應,返回一個組成員報告報文,通知路由器本主機所在的組播組的地址。
特定組成員查詢
正常情況下,IGMP採用一般組播組成員查詢來輪詢本地網路中的組成員信息。這種查詢並非針對某一個組播組,而是針對本地網路中所有組進行查詢。在某些特定環境中,路由器也需要查詢在本地網路中是否存在某個特定組播組的成員。這時可使用特定組成員查詢。