IP組播會議的第壹次大規模演示是在1992年3月的第23屆IETF大會上，當時它被用來向全世界的研究人員和感興趣的觀察者直播壹些會議。之後，壹些IETF會議在MBONE和壹些私有組播網絡上進行選擇性組播。
多播安全是壹個重要的問題。標準實用的通信安全解決方案壹般采用對稱加密。但是將其應用於IP多播流量可能會使任何接收者都有能力冒充發送者。這顯然是不能接受的。IETF的MSEC工作組正在開發安全協議來解決這個問題，其中大部分是在IPsec協議集的框架內開發的。
IPsec不能用於多播方案，因為IPsec安全關聯綁定到兩臺主機，而不是多臺主機。IETF提出了壹個新的協議——Tesla，在組播安全方面具有靈活性和說服力。組播協議分為主機和路由器之間的組成員協議和路由器之間的組播路由協議。群組成員協議包括IGMP(互聯網群組管理協議)。組播路由協議分為域內組播路由協議和域間組播路由協議。域內組播路由協議包括PIM-SM、PIM-DM、DVMRP等協議，域間組播路由協議包括MBGP、MSDP等協議。同時，為了有效抑制鏈路層組播數據的擴散，引入了IGMP監聽、CGMP等二層組播協議。為組播技術史做出了巨大貢獻！
IGMP建立並維護路由器直接網段的組成員信息。域內組播路由協議根據IGMP維護的這些組播組的成員信息，采用壹定的組播路由算法構建組播分發樹轉發組播數據包。域間組播路由協議在自治域之間發布具有組播能力的路由信息和組播源信息，使得組播數據可以在域間轉發。多播IP地址用於標識IP多播組。iana(Internet Assigned Number Authority)為IP組播分配D類地址空間，範圍從224.0.0.0到239.255.255.255。如下圖所示(二進制表示)，IP組播地址的前四位都是1110 octet(1)octet(2)octet(3)octet(4)110。
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx多播組可以是永久的也可以是臨時的。壹些多播組地址是正式分配的，這被稱為永久多播組。永久多播組的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.4 dvmrp(距離矢量多播路由協議)路由器。
224.0.0.5 OSPF(開放最短路徑優先)路由器
224.0.0.6 OSPF災難恢復(指定路由器)
224.0.0.7 st(共享樹)路由器
224.0.0.8主機
224.0.0.9 rip-2路由器
224.0.0.10 EIGRP(增強型內部網關路由協議)路由器224.0.0.11活動代理
224.0.0.12 dhcp服務器/中繼代理
224.0.0.13所有PIM(協議獨立多播)路由器
224.0.0.14 RSVP(資源預留協議)封裝
224.0.0.15所有cbt路由器
224.0.0.16指定了SBM(子網帶寬管理)。
224.0.0.17所有SBM
224.0.0.18 VRRP(虛擬路由器冗余協議)
239.255.255.255 SSDP議定書的使用
多播MAC地址
組播MAC地址的高24位為0x01005e，第25位為0，即高25位為固定值。MAC地址的低23位是多播IP地址的低23位。由於IP組播地址的前4位是1110，代表組播標識，後28位只有23位映射到MAC地址，這樣IP地址中的4位信息丟失，導致32個IP組播地址映射到同壹個MAC地址。在組播模式下，信息的發送方稱為“組播源”，信息的接收方稱為該信息的“組播組”，所有支持組播信息傳輸的路由器稱為“組播路由器”。加入同壹個組播組的接收成員可以廣泛分布在網絡的任何地方，即“組播組”沒有地域限制。應當註意，多播源不壹定屬於多播組。它向多播組發送數據，而不壹定是接收方。多個多播源可以同時向壹個多播組發送消息。
假設只有主機B、主機D和主機E需要信息，采用組播方式時，這些主機可以加入同壹個組播組。組播源只需要向這個組播組發送壹個報文，網絡中的路由器就會根據這個組播組中成員的分布情況對報文進行復制轉發，最終報文會準確的發送到主機B、主機D和主機E。IGMP協議在主機和與其直接相連的組播路由器之間運行。主機告訴本地路由器它想要加入並接受特定多播組的信息。同時，路由器通過該協議周期性地查詢局域網中某個已知組的成員是否活躍(即該網段是否還有屬於某個組播組的成員)，從而收集和維護所連接的網絡組的成員關系。
IGMP有三個版本。IGMPv1由RFC1112定義。目前普遍使用的是IGMPv2，由RFC2236定義。IGMPv3還是草稿。集團成員的基本查詢和上報流程在IGMPv1中定義。在此基礎上，IGMPv2增加了群組成員快速離開的機制。IGMPv3中增加的主要功能是成員可以指定是否接收來自某些組播源的消息。本文重點介紹IGMPv2協議的功能。
IGMPv2通過查詢者選舉機制為連接的網段選舉壹個唯壹的查詢者。查詢者定期發送通用群組查詢消息，查詢成員關系；主機發送報告消息來回答該查詢。加入組播組時，主機不必等待查詢消息，主動發送報告消息。當離開組播組時，主機發送離開組的消息；查詢者在收到離開群組的消息後，發送特定的群組查詢消息，以確定是否所有的群組成員都已離開。
通過上述IGMP機制，在組播路由器中建立壹個表，該表包括路由器的每個端口，以及該端口對應的子網上有哪些組的成員。當路由器接收到某個組G的數據報文時，它只將數據報文轉發給那些有G成員的端口。路由器之間如何轉發數據包是由路由協議決定的，IGMP協議對此不負責。網絡層二層組播的相關協議包括IGMP監聽、IGMP代理和CGMP協議。
IGMP窺探的實現機制是:交換機通過監聽主機發送給路由器IGMP成員的報告報文，形成組成員與交換機接口的對應關系；根據對應關系，交換機只將接收到組播包轉發給具有組成員的接口。
IGMP代理和IGMP探聽功能相同，但機制不同:IGMP探聽只通過監聽IGMP消息來獲取相關信息，而IGMP代理攔截最終用戶的IGMP請求，然後轉發給上層路由器。
CGMP(思科集團管理協議)是思科基於客戶機/服務器模型開發的私有協議。在CGMP的支持下，組播路由器可以根據接收到的IGMP包通知交換機哪些主機將加入和離開組播組，交換機可以利用這些信息構建的轉發表來確定將組播包轉發到哪些接口。GMRP是從主機到以太網交換機的標準協議，它使多播用戶能夠在第2層交換機上註冊多播成員。在眾多組播路由協議中，PIM-SM稀疏模式協議無關組播是目前應用最廣泛的協議。
在PIM-SM域中，運行PIM-SM協議的路由器定期發送Hello消息來發現相鄰的PIM路由器，並負責選舉多路接入網絡中的指定路由器(DR)。這裏，DR負責向其直接連接的組成員的多播分發樹根節點發送加入/修剪消息，或者向多播分發樹發送直接連接的多播源數據。1989公布了組播規範，但其使用受到限制。目前，互聯網上並不是所有的路由器都具備組播能力。在這種情況下，研究人員建立了組播骨幹網(姆博內),以便在現有環境下開發和測試組播協議的應用。姆博內支持多播數據包的路由，而不會幹擾其他互聯網流量。
姆博內是壹個跨越幾個大洲的實驗網絡，由誌願者完成。它是支持IP多播流量傳輸的互連子網和路由器的集合。作為互聯網上的虛擬網絡，姆博內通過隧道繞過互聯網上沒有組播能力的路由器。
隧道將多播數據包封裝在IP數據包(單播數據包)中，以通過不支持多播路由的網絡。如圖5所示，MR3和MR4是支持IGMP協議的具有組播能力的路由器。他們將組播包打包成單播包發送，同時也從接收到的單播包中取出組播包。R1和R2是沒有組播功能的路由器。它們傳輸與多播包封裝在壹起的單播包，就像其他普通單播包壹樣。點對多點應用是指壹個發送者和多個接收者的應用形式，是最常見的組播應用形式。
典型應用包括:
媒體廣播:演講、示威遊行、會議等預定活動。其傳統的媒體傳播手段通常采用電視和廣播。這種應用通常需要壹個或多個恒定速率的數據流。當采用多個數據流(例如語音和視頻)時，它們通常需要同步並且具有不同的優先級。它們往往要求更高的帶寬和更小的延遲抖動，但對絕對延遲的要求不是很高。
媒體推送:如新聞頭條、天氣變化、體育比分等非商業關鍵動態信息。它們要求低帶寬和無延遲。
信息緩存:如網站信息、執行代碼等基於文件的分布式復制或緩存更新。他們對帶寬和延遲有壹般要求。
事件通知:例如網絡時間、多播會話時間表、隨機數、密鑰、配置更新、有效網絡告警或其他有用信息。他們對帶寬的要求不壹樣，但壹般都比較低，對延遲的要求也壹般。
狀態監控:如股票價格、傳感設備、安全系統、生產信息或其他實時信息。這種帶寬要求根據采樣周期和精度的不同而不同，可能有恒定速率帶寬或突發帶寬要求，通常對帶寬和延遲的要求壹般。多點對多點應用是指多個發送者和多個接收者的應用形式。壹般每個接收者可以接收多個發送者發送的數據，同時每個發送者可以向多個接收者發送數據。
典型應用包括:
多點會議:通常，音頻/視頻和白板應用構成多點會議應用。在多點會議中，不同的數據流有不同的優先級。傳統的多點會議采用專門的多點控制單元來協調和分配它們。組播可以由任何發送者直接發送給所有接收者，多點控制單元用於控制當前的發言權。這種應用需要高帶寬和延遲。
資源同步:時間表、目錄和信息等分布式數據庫的同步。他們對帶寬和延遲的要求壹般。
並行處理:如分布式並行處理。它需要高帶寬和延遲。
協同處理:比如共享文檔的編輯。它對帶寬和延遲的要求壹般。
遠程學習:這實際上是壹個媒體廣播應用程序加上對上遊的支持(允許學生向教師提問)。它對帶寬和延遲的要求壹般。
討論組:類似於基於文本的多點會議，也可以提供壹些模擬表情。
分布式交互仿真(DIS):它要求高帶寬和高延遲。
多人遊戲:多人遊戲是壹個簡單的分布式交互模擬，具有討論組功能。它需要高帶寬和延遲。
Jam Session:這是壹個音頻編碼分享應用。它需要高帶寬和延遲。
多點到點應用
多點對點應用是指多個發送者和壹個接收者的應用形式。通常是雙向請求響應應用，任何壹端(多點或點)都可能發起請求。典型應用包括:
資源搜索:如服務定位，要求帶寬低，延遲壹般。
數據采集:是點對多點應用中狀態監控應用的逆過程。它可以由多個感測設備發送回數據收集主機。帶寬要求因采樣周期和精度而異，可能有恒定速率帶寬或突發帶寬要求。通常，這種應用對帶寬和延遲有普通的要求。
在線拍賣:拍賣師拍賣產品，多個競拍者將價格發回給拍賣師。
信息查詢:查詢者發出查詢，所有被查詢者回復。通常，這需要較低的帶寬，並且對延遲不敏感。
Juke Box:比如支持近乎點播的音視頻播放。通常，接收方使用“帶外”協議機制(如HTTP、RTSP、SMTP或多播)將倒帶請求發送到調度隊列。它需要高帶寬和普通延遲。