基於彈性分組環的組播傳輸路徑生成算法的製作方法
2023-05-11 00:20:36
專利名稱：基於彈性分組環的組播傳輸路徑生成算法的製作方法
技術領域：
本發明涉及彈性分組環和組播數據傳輸領域。
背景技術：
彈性分組環(RPR，Resilient Packet Ring)技術集IP的智能化、乙太網的經濟性和光纖環網的高帶寬效率、可靠性於一體，為高帶寬、高效率傳輸網絡提供了一個極佳的解決方案。RPR有別於傳統MAC，最吸引人的特點是具有電信級的可靠性，使其不僅僅局限於處理面向數據的業務傳送需求，同時可以形成處理多業務傳送的綜合傳輸解決方案。目前，IPTV、視頻會議等業務應用越來越廣泛，上述業務傳輸模型為單點對多點傳輸，如果採用單播和廣播傳輸方式，將會浪費大量的網絡資源，而組播技術有效地解決了上述問題，實現了 IP網絡中單點到多點的高效數據傳送，節約大量網絡帶寬、降低網絡負載。 基於RPR的多業務傳輸平臺勢必將承載IPTV、視頻會議等業務，RI3R平臺傳輸大量組播數據將是一種必然。RI3R傳輸平臺如何高效的完成組播數據傳輸，並對平臺帶寬佔用率降低到最低將是一項有價值的工作。基於RPR的組播傳輸路徑生成算法實現組播數據傳輸路徑拓撲結構的形成，並對該拓結構進行維護。
發明內容
本發明的主要內容是完成基於RPR的組播傳輸路徑生成算法，實現組播數據在 RI3R平臺上以最優路徑傳輸到各個目的節點，同時降低組播數據對RI3R平臺帶寬不必要的佔用。該算法的重點在於減少組播數據不必要的傳輸跳數，充分利用網絡帶寬，達到最優傳輸組播數據的目的。為達到上述目的，本發明的技術方案主要包括1. RI3R傳輸平臺，該平臺包含多個RI3R節點，每個RPR節點都採用一個乙太網中用到的48位MAC地址作為地址標識。組播傳輸路徑生成算法將在各個RPR節點上實現。2.組播伺服器，該伺服器是整個網絡的組播數據源，組播數據將發送到RPR傳輸平臺上部分RI3R節點。在組播轉發表建立過程中，RI3R節點記錄本節點所需要接收的組播組數據，如果數據到達本節點且本節點需要，則將該數據下環，如果數據仍需要傳向下一個節點時，該數據報將進行過環操作，否則剔除該數據。3.組播客戶端，組播客戶端將向RI3R平臺通知其需要接收的組播組。當組播查詢報文到達該組播客戶端時，也將報告其需要接收的組播組。組播數據的傳輸大致分為兩個部分，一個是組播轉發表的建立與維護，二是組播數據根據組播轉發表轉發，本發明屬於組播轉發表的建立與維護部分。在區域網中，組播數據轉發表由組播協議(IGMP)實現。組播協議的報文大致分為3中類型 普遍查詢IGMP查詢器定期向本地網絡發送IGMP通用查詢報文，以查詢該網絡有哪些組播組的成員；
組播成員報告當組播客戶端接收到普遍查詢報文時將向網絡發送其需要接收的組播組； 組播成員離開報告組播客戶端不再需要接收某個組播組數據時將發送成員離開報文，網絡將不會將該組播組的數據轉發到該組播客戶端上。在即R平臺上，為保證組播數據最優傳輸，佔用最少的網絡帶寬，各個即R節點將對IGMP協議報文分析，並建立和維護其組播轉發表，最優的傳輸路徑算法同時也在此時被使用，大致流程為1、普通查詢報文進入第一個RI3R節點(稱之為RI3R根節點)，該節點將普通查詢報文重新打包，廣播該報文到其他RPR節點(稱之為RPR分支節點)，RPR分支節點將報文轉發到各個組播客戶端；2、如果客戶端需要接收某個組播組的數據則發送組播成員報告報文，RPR分支節點接收到成員報告報文後，將建立組播成員列表，並將該報文轉發到RI3R根節點；3、RI^R根節點接收到成員報告報文時，通過傳輸路徑最優生成算法建立組播轉發表，該表包含的信息有組播組、組播數據東向轉發的TTL，組播數據西向轉發的TTL，該表的建立是以減少傳輸的跳數和到達需要該組播數據的RPR分支節點的時間為基礎。4、RI^R分支節點接收到組播客戶端的成員離開報文時，將判斷是否該分支下是否還存在其他組播客戶端在接收相同的組，如果不存在則將該成員離開報文轉發到RI3R根節佔.5、RI^R根節點接收到成員離開報文，將重新計算該組播組數據的傳輸路徑。
以下描述和附圖是為了更清楚的說明現有技術或本發明的技術方案，通過比較， 可更加深入的理解本發明的創新、優點以及實施細節。本發明通過實施例描述，因此本發明不受此處所公開的具體實施例的限制，下面將對附圖作進一步的說明圖1所示基於RPR的組播數據傳輸模型，在RI3R平臺中包含6個RI3R節點，編號分別為A、B、C、D、E和F。其中組播伺服器連接到RI3R節點A，因此該節點定義為RI3R根節點， 其它節點則定義為RPR分支節點。圖2所示為RI3R根節點上組播數據轉發表模型，當組播數據到達RI3R根節點時，通過查找該表，如果對應的組播組存在，則按照對應的傳輸方向和TTL值傳輸，否則丟棄數據包。圖3為實例一生成的組播傳輸表示意。圖4為實例二生成的組播傳輸表示意。圖5為實例三生成的組播傳輸表示意。
具體實施例方式下面根據附圖和實例對本發明做進一步詳細說明。實例一實例系統簡化模型如圖1所示，組播客戶端(1)需要接收224. 1. 1. 1組播組的數據，組播客戶端( 需要接收224. 1. 1. 2組播組的數據，那麼將在RI^R根節點上生成一張組播轉發表，該表如圖3所示。組播伺服器發送的組ID為224. 1. 1. 1的組播數據西向傳輸到 RI3R節點B，然後被剔除，其傳輸的跳數為1。組播伺服器發送的組ID為224. 1. 1. 2的組播數據西向傳輸到RI3R節點C，然後被剔除，其傳輸的跳數為2。如果採用廣播方式傳輸組播數據，兩個組的組播數據傳輸跳數都將為6，從而浪費了大量的網絡資源。實例二在圖1所示的簡化模型基礎上，如果，RPR分支節點B、C、E和F下有用戶接收組 ID為224. 1. 1. 1的組播數據，RPR根節點將建立一條組播轉發表，如圖4所示。組播ID為 224. 1. 1. 1的組播數據在RI3R根節點上，從東、西兩個方向傳輸，其TTL值都為2，此時數據傳輸到所有需要數據的節點的跳數為4。如果採用廣播或單方向傳輸時，其跳數為5。實例三在圖1所示的簡化模型基礎上，RPR分支節點B、D、E和F下，都有用戶接收組播組為224. 1. 1. 1的數據，RI3R根節點將建立一條組播轉發表，如圖5所示。組ID為224. 1. 1. 1 的組播數據從西向發送到RI3R節點B，從東向傳輸到節點F、E和D，數據到達所有節點的跳數為4。如果RI^R節點D的數據來自西向B，會導致跳數的增加，從而浪費網絡資源。以上所述，僅為本發明典型的具體實施方式
，但本發明的保護範圍並不局限於此， 任何熟悉該技術的人在本發明所揭露的技術範圍內，可輕易想到的變化或替換，都應涵蓋在本發明的保護範圍之內。因此，本發明的保護範圍應當以權利要求的保護範圍為準。
權利要求
1.基於RPR組播數據傳輸模型，其特徵包括基於RPR的組播傳輸網絡中，連接組播伺服器的節點為RPR根節點，其維護一張組播數據轉發表，連接組播客戶端的節點為PRP分支節點，其將建立一張組播成員表，用於判斷該節點需要接收的組播組數據。
2.組播數據轉發表，其特徵包括(1)組播組ID組播數據轉發表包含的組播ID極為組播IP位址；(2)東向傳輸TTL當組播數據查找到傳輸表後將向東向傳輸數據包，並設定TTL值；(3)西向傳輸TTL當組播數據查找到傳輸表後將向西向傳輸數據包，並設定TTL值。
3.組播數據轉發表計算方法，其特徵包括組播數據從東、西兩個方向傳輸，以最小的跳數為原則，減少其到達所有需要該組播組數據節點的跳數。
全文摘要
本發明主要實現一種基於RPR傳輸平臺的組播傳輸路徑生成算法，算法的目的是減少到達需要該組播數據的RPR節點時間，以及減少到達所有需要該組播數據的RPR節點所經過的跳數，從而提供整個網絡帶寬的利用率。
文檔編號H04L12/56GK102299840SQ20101021164
公開日2011年12月28日 申請日期2010年6月25日 優先權日2010年6月25日
發明者王發強 申請人:深圳市邦彥信息技術有限公司