Report 中來判斷網路中的 Router 是否存在或是否支援 IGMPv3(這是為了協助不支援 IGMPv3 的 Router 完成 Multicasting)。綜合以上資訊，CS 會判斷此封包要馬上繼續往 下傳送，還是要延遲一段時間再傳送，或是直接 Drop(當 CS 發現 Source Address Lists 中有些 Receivers 已不存在，就直接 Drop 此訊息)，並把判斷結果回覆 Communication Control Agent 來做後續的傳輸處理。
雖然 Communication Control Agent 機制比其他的 Multicast 協定多一道額外傳輸 檢查程序及多繞一個路徑，但其所扮演的過濾角色可以支援對 QoS 的要求以及
Congestion Control。由模擬結果的數據可以看出此額外的開銷對整體的傳輸還是有正 面的助益。
3.3 Coordinator Server Functionality
接下來再對 CS 所扮演的角色和功能做更詳細的說明:
3.3.1 Data Buffer
在介紹 Communication Control Agent 時有提到 CS 是一個被諮詢的角色，同時提 供資訊傳送的規則，而它本身並不實際參與 data forwarding，所以相對於其他的研究 方案如 MNet[27]，比較不會形成資料傳送上的 Bottleneck，甚至於在頻寬限制下可以 考慮把 CS 設置在網段以外。當某些特殊情況發生時 CS 會充當 Data Buffer，也就是當 Router 不支援 IGMPv3 和 Receiver 因為移動而引發的 Handover 發生時。在 Handover 期間的 Multicast Packets 可以由 CS 代為儲存(Caching)，等 Handover 完成後再由 CS 直接以 Unicasting 方式透過建立與 Receiver 的 Tunnel 來補傳資料，因此每當 CS 接收 由 Communication Control Agent 送過來的 Multicast Packets，都會把它 Queuing 起 來，至於 Queue 的數量大小可以設定一個 Threshold 值來依據 Receiver 端發生 Handover 的頻率來調整，也就是 Qsize = F (Frequency of Handover)，而協助不支援 IGMPv3 的 Router 完成 SSM 的做法會在以下章節做介紹。
‧
3.3.2 Congestion Control
利用 Communication Control Agent 的協助，以取得每一次 Receivers 的 ACK 回覆 訊息，也就是 Receivers 端的 Edge Router 上的 Communication Control Agent 會複製 一份 ACK 訊息傳送到 CS，如此 CS 就可以監看每個 Receivers 的狀態。當在設定時間內 沒有收到某一個 Receiver 的 ACK 回應時，就當此 Receiver 已離開此群播組。當 Source 端 Edge Router 的 Communication Control Agent 送來的 Multicast Packets 的 Source Address Lists 中如果有此 Receiver 就直接把它從 Source Address Lists 中剔除，如 果 Source Address Lists 只有此 Receiver 則把整個 Multicast Packets 捨棄，由此監 聽 Receivers 端的 ACK 回覆的作法比起由 Routers 週期性的廣播 Query 訊息的方式，更 可以降低 Control Message 的 Overhead。而且計算每次 Receivers 的 ACK 回應時間的 Jitter 和 Delay 情況來佐以判斷網路 Congestion 情況，以適時調整 Multicast Packets 的傳送頻率或延遲傳送來減輕頻寬的負荷，當然比起用 MAC 層交換 RTS/CTS (Request to Send/Clear to Send)來判斷網路的 Congestion，使用 Receivers 的 ACK 來判斷
Congestion 的情況是比較不直接的，因此會有失真和延遲的情況，但是可以降低由 RTS/CTS 的控制訊息交換的本身對 Congestion 造成的衝擊，當然也可以考慮把 MAC 層的 Protocol 加入 CLIMP 架構中，只是如此做會使得控制層級變多，增加計算的複雜度，因 而使得由 MAC 層提供的效益，相互抵消。
以下就 Communication Control Agent 如何配合 Coordinator Service 來有效控制 Congestion 做說明。首先我們針對各別的 Receivers 的 ACK 來計算其 Delay 和 Jitter 情況，再針對 Delay 和 Jitter 的值，設定其 Threshold 值，當然也可以加入針對封包 中 TOC 欄位的特殊傳輸要求而設的 Threshold Value，藉以安排封包的傳送次序。為簡 化計算處理的複雜度，我們把它分成三種不同的傳輸等待等級(High Priority / Normal Priority / Low Priority)，並對映的存入 Routers 的 Data Queue 中，假設 Delay 的 Threshold Value 為 DT，而 Jitter 的 Threshold Value 為 JT，其 Scheduling 的判斷
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
流程如同下圖如示:
圖 3.3 封包排程決策流程圖
3.3.3 Switch Protocol When Router Without IGMPv3 Support
IGMP 目前已普遍的被使用在各類型的網路中，大部份的 Router 都有支援。但 IGMPv3 是較新的版本，不見得每個 Router 都支援。在 IGMPv3 的說明文件中有提到它可以向下 相容較低的版本，但是較低的 IGMP 版本是無法辨視 IGMPv3 的封包，會直接捨棄它，所 以我們要藉助 Communication Control Agent 和 CS 的共同合作來協助不支援 IGMPv3 的 Router 也可享受 SSM 所帶來的好處。當 Router 收到無法辨視的封包時，它可透過 Communication Control Agent 的協助，把 Multicast Packets 傳給 CS，此時 CS 本身 就扮演 PIM-SM 的 Rendezvous Point，以 PIM-SM 協定來轉發 Multicasting 資料。
3.3.4 Source Discovery Agent
之前的討論有提到，SSM 本身不需要 MSDP 的支援，因為 Source 端的位址資訊是已 知條件，但是在這裡我們為什麼又要提出類似的作法呢? 那是因為它不單是 Source Discovery 的功用而已，它更像是 Publisher 的 Manager，Receiver 要接收 Multicast Packets 必須要加入群播群組才行(Pull)。可是我們提出的構想是主動式的提供
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
(Push)，Receiver 除了加入群播群組來接收 Multicast Packets 外，也可以在每一次加 入時，同時提出訂閱(Subscribe)申請，而此申請會一直有效，直到 Receiver 提出取消 訂閱(Unsubscribe)申請或是 Source 節點 fail。當一個 Receiver 提出對某一個(S,G) 的 Multicast Packets 訂閱申請，CS 會記錄它並交由 Source Discovery Agent 來管理，
所以當某一個 Receiver 進入某一個 Edge Router 的服務範圍並提出取得 IP 申請的同時 Communication Control Agent 會通知 CS，所以只要有此 Receiver 在訂閱狀態中屬於 某一個(S,G)的 Multicast Packets 在傳送時，CS 就會把此 Receiver 主動加入接收群組 中，所以此 Receiver 不用透過 Join(S,G)過程就可以開始接收 Multicast Packets，要 這樣做必須是 Receiver 的 Edge Router 中剛好有此(S,G)的其他 Receiver 才行，當然 CS 也可以主動協助完成在那個 Edge Router 建立一個群播群組。但這樣做有一個風險，
可能此 Receiver 並沒有意願接收此 Multicast Packets，只是他忘了取消訂閱而已，所 以主動建立一個新群播群組並不是一個好主意，所以 Source Discovery Agent 提供了 一個主動式 Multicasting 的機制，至於如何和 Receiver 有更好的互動是未來可以再深 入研究的問題。
以下是 Source Discovery Agent 的運作示意圖:
圖 3.4 Source Discovery Agent 的運作示意圖
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
當有 Source 端要傳送 multicast packets 或是有 Source 要提供 Multicasting 服務時，
它會向 Edge Router 提出資料傳送的需求訊息。當 Edge Router 收到此訊息後，它會把 它再 Forward 給 CS 知道，至此 CS 就會知道網路中有多少 Multicasting Source 提供服 務，再週期性的把各(S,G)訊息向 Routers 廣播，當然此廣播行為可視情況調整，因為 IGMP 本身的 Membership Report 就已包含這些資訊，所以除非需要跨網段的(S,G)資訊，
因此 MH(Mobile Host/Receiver)可以由 Edge Router 知道網路中有那些 Multicasting 資源可用，當它想加入(S,G)群播群組時會向 Edge Router 申請加入(S,G)群播群組的同 時也可以提出 Subscribe(S,G)的申請，或只是單純的 Join(S,G)或是單純的
Subscribe(S,G)，然後 Receiver 端的 Edge Router 會一路往前轉送 Join(S,G)訊息到 Source 端的 Edge Router，同時也知會 CS，然後再由 Source 端的 Edge Router 藉著 RPF 來建立到達 Receiver 端的 Edge Router 的傳輸路徑，至此完成加入程序。以下還會有 更詳細的圖文說明來解釋 Multicasting 的運作過程。