跳至內容

互聯網組管理協定

本頁使用了標題或全文手工轉換
維基百科,自由的百科全書

互聯網組管理協定(英語:Internet Group Management Protocol,縮寫:IGMP)是用於管理網路協定多播組成員的一種通訊協定。IP主機和相鄰的路由器利用IGMP來建立多播組的組成員。像ICMP用於單播連接一樣,IGMP也是IP多播說明的一個完整部分。IGMP為互聯網協定的一種,屬於開放系統連結(OSI) 模組的第三層協定,IP主機用它將主機的多點傳送成員人數報告給臨近的多點傳送路由器。

IGMP版本0

[編輯]

RFC 966,16頁:

[編輯]

互聯網組管理協定(IGMP)被用在IP主機和它們即時相鄰多播代理之間,用以支援臨時組地址的分配和組成員的添加刪除。

RFC 988,1,2,3頁

[編輯]

IP多點廣播定義為一個去往主機群IP數據的傳輸,有零個或多個主機組成的主機群通過單個IP目的地址標識。一個多點播送數據報被投遞給它的目的主機群的所有成員,具有和常規單路傳送IP數據報同樣的「盡力」安全性,那就是說該數據報不保證達到目的地組的所有成員,或者不和其他數據報具有相同的順序。主機組的成員數是動態的;也就是說,主機隨時可以參加和離開組。 沒有對主機組中的成員的數目或地點加以限制,但是成員僅限於那些擁有專用的接入密碼的主機。一個主機可能同時是多個組的成員。一個主機即使不是一個組的成員也可以給它傳送數據報。主機組可能永久性或暫時性的。永久性組具有一個眾所周知的,官方分配的IP位址。它是地址,非該組的成員,也就是說永久性;任何時間,一個永久性組也許有許多成員,甚至可能有零個成員。 另一方面,臨時性的組,當有一個主機的請求建立時被動態地指派一個地址。當它的成員數降至零,臨時性的組要解散時,它的地址可以重新分配。

臨時組的建立和組員身份資訊的維護是多播代理(存在於互聯網閘道器或其他專用的主機內的實體)的職責。至少有一個多播代理直接與每個支援IP多點廣播的IP網絡或子網絡相連。主機通過用鄰機代理交換報文來請求新建一個組、加入或離開現有組。多播代理還擔負多點播送IP數據報的互連網絡運送工作。傳送一個多點播送IP數據報時,主機將它傳送到一個區域網絡多播地址那裏,哪些地址標識目的地主機組的所有鄰機成員。如果該組具有在其他網絡的成員,多播代理成為本地多播的輔助接收器並且通過互聯網閘道器系統中繼該數據報給其他網絡上的代理。最後,另一個網絡上的代理將數據報作為一個本地的多播傳送給他們自己目的組的鄰機成員。

2級:充分支援IP多點廣播。

[編輯]

2級容許一個主機去建立、加入和離開主機組,以及給主機組傳送IP數據報。它要求在主機內部實現IGMP並且擴充IP和區域網絡服務介面。本備忘錄以下的所有部分可適用於實現2級。

RFC 988,10頁:

[編輯]

IP模組內部,成員資格管理操作通過IGMP支援,這在附錄I.中規定。也使報文與每一上面規定的操作相對應,IGMP還規定一個「deadman timer」程式藉此主機定期用多播代理確認它們的組員資格。

IP模組必須維護一個數據結構,該數據結構列出主機當前所屬的所有主機組的IP位址、以及每個組的回送策略、存取關鍵字和時間變數。 這個數據結構被用於IP多址通訊傳輸服務,了解哪些輸出數據報給回送,通過接收服務了解哪些入局數據報去接受。IGMP和管理介面操作的用途是維護這個數據結構。

RFC 988,13頁:

[編輯]

IGMP被用在IP主機和它們的緊接的鄰機多點播送代理之間支援臨時組的生成,添加和刪除一個組的成員,定期證實組員身份。IGMP是一個不對稱協定而且這裏從一個主機觀點而非一個多播代理來加以說明。

ICMP(互聯網控制報文協定)一樣,IGMP是一個IP的組成部分。它要求通過所有主機對應的2級IP多點廣播規範完全地實現。IGMP報文被壓縮在IP數據報中,具有一個[[IP協定號列表|IP協定號碼]]2。所有IGMP報文具有以下格式:

位元組0 位元組1 位元組2 位元組3
0~15位元組 Type Code Checksum
16~31位元組 Identifier
32~47位元組 Group Address
48~79位元組 Access Key

Type,8位元,代表報文的類型:

  • 1:建立組要求
  • 2:建立組應答
  • 3:加入組要求
  • 4:加入組應答
  • 5:離開組要求
  • 6:離開組應答
  • 7:確認組要求
  • 8:確認組應答

Code,8位元,在一個建立組請求訊息中代碼欄位指出新的主機組將是公共的或私有的:

  • 0:公共
  • 1:私有

在一個回答資訊中,代碼欄位規定要求的結果

  • 0:請求答應
  • 1:要求被拒絕,無資源
  • 2:要求被拒絕,無效代碼
  • 3:要求被拒絕,無效組地址
  • 4:要求被拒絕,無效存取關鍵字
  • 5-255:要求掛起,幾秒後重試

IGMP Checksum,16位元,校驗和是從IGMP類型開始的IGMP報文中16位元一補碼和的16位元一補碼值。為了計算該校驗和,校驗和域應該為零。在封包傳輸過程中,校驗和被計算出來並插入域中。當收到封包的時候,校驗和再次被計算並相對於校驗和域進行驗證。當兩個校驗和不匹配時即發生錯誤。

Identifier,32位元,在一個確認組請求訊息中,識別碼欄位包含零。在所有其他的請求訊息中,識別碼域包含一個值以便將來自同一個主機的其他要求與該要求區別開來。在一個回答資訊中,識別碼域包含與在對應請求訊息中同樣的值。

Group Address,32位元

  • 在一個組建立請求報文中,組地址欄位包含零。在所有其他的請求訊息中,組地址域包含一個主機組地址。
  • 在一個組建立應答報文中,組地址域或包含新的指定的主機組地址(如果該要求被允許)或包含零(如果被拒絕)。在所有其他的應答報文中,組地址域包含與在對應請求報文中同樣的主機組地址。

Access Key,64位元,在一個組建立請求報文中,存取關鍵字欄位包含零。在所有其他的請求訊息中,存取關鍵字域包含分配給主機組在組地址域辨識的存取關鍵字(零對於公共的組)。在一個組建立應答報文中,存取關鍵字域或包含一個非零的64位元編號(如果要求一個私有組被允許)或包含零。在所有其他的應答報文中,存取關鍵字域包含與在對應要求中相同存取關鍵字。

IGMP版本1

[編輯]

RFC1054,10-13頁

[編輯]

互聯網組管理協定(IGMP v0)被IP主機用來向任何即時相鄰多播路由器報告它們的組成員關係。IGMP是一個不對稱協定,在此處從一個主機而不是從一個路由器的觀點進行說明。(IGMP也能對稱或不對稱地被用於多播路由器之間)

像ICMP一樣,IGMP是IP的一個整體部分。它要求通過所有主機對應的2級IP多點廣播規範完全地實現。IGMP報文被壓縮在IP數據報中,具有一個IP協定號碼2。此備忘錄詳細說明了IGMP的版本1。

非正式協定描述。多播路由器傳送主機成員關係查詢資訊(下文中稱為查詢)來發現在哪些主機組在它們附屬的本地網絡上有成員。查詢被寫入所有主機組地址(地址是224.0.0.1),攜帶的IP生存時間是1。

主機通過產生主機成員關係報告(下文中稱為報告)來響應一個查詢。報告各個主機組到它們所屬的收到查詢的用戶介面。為了避免並行報告產生「內爆」,同時也減少所傳輸的報告總數,採用了以下兩種技術:

  • 當一台主機收到一個查詢時,它並不是馬上傳送報告,而是為傳入查詢的網絡介面上每個它的組成員關係啟動一個報告延遲時間。每個時間是在0-D秒隨機選擇的不同的值。當一個時間截止時,就為相應的主機組產生一個報告。因此,報告散佈在一個D秒區間內而不是全部立刻發生。
  • 一個報告伴隨一個與主機組地址等價的IP目的地址被傳送,IP生存時間是1,所以,同一個網絡上同一個組的其他成員可以偵聽報告。如果一台主機聽到網絡上同組的一個報告,就停止自己對該組的計時並且不會向該組產生報告。因而,在正常情況下,在網絡上各組僅會由定時器截止最快的主機產生一個報告。注意到多播路由器收到所有的IP多播數據報,因此不需要明確註明地址。另外還要注意到路由器需要知道哪些主機屬於同一個組,除非在一個特殊網絡上至少一個主機屬於一個組。

以上描述的還有兩個例外:首先,當收到一個查詢時,如果一個報告的延遲定時器已經開始計時,那個定時器不會被復位成一個新的隨機值,而是按其當前值繼續計時。第二,不會為全主機組(224.0.0.1)中的一個主機成員關係設置報告延遲定時器,該成員關係不會被報告。

如果一台主機使用一個偽亂數生成器來計算報告延遲,主機自己的一個專用IP位址應該被用作生成的一部分,以避免多個主機產生同樣延遲順序的幾率。

一台主機應該確認一個收到的報告在其IP目的域和IGMP組地址域有同樣的IP主機組地址,以確保該主機自己的報告不會被一個錯誤接收的報告取消。主機應當放棄除了主機成員關係查詢(Host Membership Query)或主機成員關係報告(Host Membership Report)之外任何形式的IGMP訊息。

多播路由器定期傳送查詢以重新整理當前特定網絡上的成員資訊。如果在一些查詢之後沒有收到一個特定組的報告,路由器就假定這個組沒有本地成員並且他們不需要為本地網絡上的組正向遠端的多播。查詢通常不是被頻繁傳送的(每分鐘少於一次),以保持主機和網絡上的IGMP額外開銷很低。儘管如此,當一個多播路由器啟動時,它也許會發出一些密集的查詢以便於快速建立其對於本地成員關係的資訊取得。

當一台主機加入到一個新的組時,它應當立即對該組傳送一個報告,而不是等待一個查詢,以防它正好是網絡上該組的第一個成員。為避免初始化報告遺失和損壞,建議此報告在短延時後重複1到2次。一個簡單的實現方法就是假設收到一個僅面向該組的查詢,設置該組的隨機報告延遲定時器。

RFC 1054,16,17頁

[編輯]

主機組地址分配:組地址捆綁 將IP主機組地址捆綁到物理主機上被認為和IP單播地址捆綁類似。一個IP單播地址被靜態捆綁到一個單IP網絡上的單個本地網絡介面。一個IP主機組地址是被動態捆綁到一個IP網絡組上的本地網絡組。

理解IP主機組地址並非捆綁到一個IP單播地址組非常重要。多播路由器不需要維持各個主機組獨立成員的列表。例如,一個連接到Ethernet的多播路由器僅需把一個Ethernet多播地址和各個有本地成員的主機組聯絡起來,而不是一個獨立IP成員或Ethernet地址的列表。

RFC 1112,第3頁

[編輯]

主機組地址 主機組由D類IP位址標記,即高四位為「1110」的那些IP位址。E類IP位址,即那些高四位為「1111」的IP位址,是為了將來的編址方式而保留的。在Internet標準的點分十進制表示中,主機組地址的範圍是從224.0.0.0到239.255.255.255。地址224.0.0.0被保證不分配給任何組,224.0.0.1被分配所有IP主機的永久組(包括閘道器)。它被用於標記在直接相連的網絡中所有多播主機。沒有多播地址(或其它IP位址)用來標記Internet上的所有主機。其它眾所周知的地址、永久組將在「已分配編號」(Assigned Numbers)文件中公佈。

RFC 1112,11頁:

[編輯]

Internet組管理協定(IGMP)用於IP主機向所有緊鄰的多播路由器報告它們的主機組成員關係。IGMP是不對稱的協定,將從主機的視角而不是從多播路由器的視角描述它。(IGMP也可以在多播路由器之間對稱或非對稱的使用。這樣的用法這裏沒有指定。)像ICMP一樣,IGMP是IP的一個組成部分。要在所有符合IP多播規範的2級主機上實現。IGMP報文封裝在IP數據報中,數據報的IP協定欄位為2。

RFC 1122,47頁:

[編輯]

IGMP[RFC 1112]是一個用於在單個網絡上特定多播組中主機和閘道器間建立主機成員關係的協定。閘道器在連接一個多播路由協義時使用此資訊以支援通過Internet的IP多播。

此刻,IGMP的實現是可選的,沒有IGMP,一台主機仍然能參與它所在網絡的本地多播。

RFC 1122,67,68頁:

[編輯]

主機應當支援全連接網絡上的本地IP多播,為此聲明從D類IP位址到鏈路層的地址對映(見下文)。對本地IP多播的支援包括傳送多播數據報、加入多播組、接收多播數據報和離開多播組。這必須支援RFC 1112中除了IGMP協定自身之外的所有,這也是可選的。

IGMP提供容許帶有資訊需求的多播路由的閘道器,以支援複合網絡上的IP多播。此時,多播路由閘道器處於試驗性階段並沒有廣泛應用。因為主機沒有通過多播路由閘道器連接到網絡上,或者不需要接收來自其他網絡的多播數據報,IGMP服務沒有目的性,因此目前IGMP是任選的。儘管如此,RFC 1112的其他部分在當前被建議作為一個更好的本地廣播地址的選擇用於提供IP層接入的本地網絡多播地址。希望當多播路由閘道器廣泛使用的時候,在將來的數據中建議使用IGMP。

如果IGMP無法實現,主機應當在IP層被初始化且啟用時只有一個成員時仍然加入全主機(all-host)組(224.0.0.1)。

加入全主機(all-host)組將嚴格支援多播的本地使用,例如閘道器探測協定,甚至在IGMP無法實現的時候也是這樣。

當前為如下類型的網絡做了D類IP位址到本地網絡對映的說明:

  • Ethernet/IEEE 802.3
  • 任何支援廣播但不是多播的網絡,編址:所有D類IP位址對映到本地廣播地址。
  • 任何類型的對等連結(例如SLIP或HDLC連結):無需對映,所有IP多播數據報按現狀在本地幀中傳送

其他類型網絡的對映會在將來說明。主機應當為高層協定或應用提供一種決定哪種主機連接網絡支援IP多播編址的方法。

RFC 1812,84頁:

[編輯]

IGMP是一種用於在單個物理網絡上主機和多播路由器之間建立特定多播組內主機成員關係的協定。多播路由器在通過多播路由協定連接時使用此資訊,以支援Internet上的正向IP多播。路由器應當實現IGMP的多播路由器部分。

IGMP版本2

[編輯]

RFC 2236,1,2頁:

[編輯]

IGMPv2允許組成員關係的終止被迅速報告給路由協定,這一點在高頻寬多播組以及揮發性組成員關係的子網絡中很重要。

像ICMP一樣,IGMP是IP的一個完整部分。它要求在所有希望接收IP多播的主機上實現。IGMP訊息封裝在IP數據報中,其IP的協定號為2。所有在該文件中說明了的IGMP訊息均會用TTL為1進行傳遞,並在IP頭中包括了IP路由檢測選項。

RFC 2113,第2頁:

[編輯]

路由器警告選項語意是「路由器應該更仔細地檢查這個包」。通過在其協定訊息的IP頭裏包含路由器警告選項,RSVP能在對普通封包的推進有少量或沒有效能損失的情況下來截取訊息。

RFC 2236,4,5頁:

[編輯]

多播路由器使用IGMP(v2)獲知哪些組在其附屬物理網絡上有成員。多播路由器保留一個包括各附屬網絡多播組成員關係和各成員關係計時器的列表。多播組成員關係意味着在一個給定附屬網絡上至少出現一個多播組的一個成員,而不是所有成員的列表。當主機收到一個通用查詢時,將為各個組(不包括全系統組)設置延遲計時器,該組就是收到查詢的介面的一個成員。

當路由器接收到了報告,它就會把該組報告加入到一個組播組成員列表中,並且會為其成員關係設一個值為組成員生存週期的計時器。當一個主機加入了一個組播組,則應該立即傳送一個非請求的版本2的成員關係報告給組,以防它是網絡上該組的第一個成員。

當一主機離開一個組播組,如果它是最後一個主機,除它外沒有其他的機器來報告成員關係了,則它應該傳送一條離開組的訊息給所有路由器,地址為組播組(224.0.0.2)。

IGMP版本3

[編輯]

RFC 3376