專利名稱：基于彈性分組環(huán)的組播傳輸路徑生成算法的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及彈性分組環(huán)和組播數(shù)據(jù)傳輸領(lǐng)域。
背景技術(shù)：
彈性分組環(huán)(RPR，Resilient Packet Ring)技術(shù)集IP的智能化、以太網(wǎng)的經(jīng)濟(jì)性和光纖環(huán)網(wǎng)的高帶寬效率、可靠性于一體，為高帶寬、高效率傳輸網(wǎng)絡(luò)提供了一個極佳的解決方案。RPR有別于傳統(tǒng)MAC，最吸引人的特點(diǎn)是具有電信級的可靠性，使其不僅僅局限于處理面向數(shù)據(jù)的業(yè)務(wù)傳送需求，同時可以形成處理多業(yè)務(wù)傳送的綜合傳輸解決方案。目前，IPTV、視頻會議等業(yè)務(wù)應(yīng)用越來越廣泛，上述業(yè)務(wù)傳輸模型為單點(diǎn)對多點(diǎn)傳輸，如果采用單播和廣播傳輸方式，將會浪費(fèi)大量的網(wǎng)絡(luò)資源，而組播技術(shù)有效地解決了上述問題，實(shí)現(xiàn)了 IP網(wǎng)絡(luò)中單點(diǎn)到多點(diǎn)的高效數(shù)據(jù)傳送，節(jié)約大量網(wǎng)絡(luò)帶寬、降低網(wǎng)絡(luò)負(fù)載。 基于RPR的多業(yè)務(wù)傳輸平臺勢必將承載IPTV、視頻會議等業(yè)務(wù)，RI3R平臺傳輸大量組播數(shù)據(jù)將是一種必然。RI3R傳輸平臺如何高效的完成組播數(shù)據(jù)傳輸，并對平臺帶寬占用率降低到最低將是一項(xiàng)有價值的工作。基于RPR的組播傳輸路徑生成算法實(shí)現(xiàn)組播數(shù)據(jù)傳輸路徑拓?fù)浣Y(jié)構(gòu)的形成，并對該拓結(jié)構(gòu)進(jìn)行維護(hù)。

發(fā)明內(nèi)容
本發(fā)明的主要內(nèi)容是完成基于RPR的組播傳輸路徑生成算法，實(shí)現(xiàn)組播數(shù)據(jù)在 RI3R平臺上以最優(yōu)路徑傳輸?shù)礁鱾€目的節(jié)點(diǎn)，同時降低組播數(shù)據(jù)對RI3R平臺帶寬不必要的占用。該算法的重點(diǎn)在于減少組播數(shù)據(jù)不必要的傳輸跳數(shù)，充分利用網(wǎng)絡(luò)帶寬，達(dá)到最優(yōu)傳輸組播數(shù)據(jù)的目的。為達(dá)到上述目的，本發(fā)明的技術(shù)方案主要包括1. RI3R傳輸平臺，該平臺包含多個RI3R節(jié)點(diǎn)，每個RPR節(jié)點(diǎn)都采用一個以太網(wǎng)中用到的48位MAC地址作為地址標(biāo)識。組播傳輸路徑生成算法將在各個RPR節(jié)點(diǎn)上實(shí)現(xiàn)。2.組播服務(wù)器，該服務(wù)器是整個網(wǎng)絡(luò)的組播數(shù)據(jù)源，組播數(shù)據(jù)將發(fā)送到RPR傳輸平臺上部分RI3R節(jié)點(diǎn)。在組播轉(zhuǎn)發(fā)表建立過程中，RI3R節(jié)點(diǎn)記錄本節(jié)點(diǎn)所需要接收的組播組數(shù)據(jù)，如果數(shù)據(jù)到達(dá)本節(jié)點(diǎn)且本節(jié)點(diǎn)需要，則將該數(shù)據(jù)下環(huán)，如果數(shù)據(jù)仍需要傳向下一個節(jié)點(diǎn)時，該數(shù)據(jù)報(bào)將進(jìn)行過環(huán)操作，否則剔除該數(shù)據(jù)。3.組播客戶端，組播客戶端將向RI3R平臺通知其需要接收的組播組。當(dāng)組播查詢報(bào)文到達(dá)該組播客戶端時，也將報(bào)告其需要接收的組播組。組播數(shù)據(jù)的傳輸大致分為兩個部分，一個是組播轉(zhuǎn)發(fā)表的建立與維護(hù)，二是組播數(shù)據(jù)根據(jù)組播轉(zhuǎn)發(fā)表轉(zhuǎn)發(fā)，本發(fā)明屬于組播轉(zhuǎn)發(fā)表的建立與維護(hù)部分。在局域網(wǎng)中，組播數(shù)據(jù)轉(zhuǎn)發(fā)表由組播協(xié)議(IGMP)實(shí)現(xiàn)。組播協(xié)議的報(bào)文大致分為3中類型 普遍查詢IGMP查詢器定期向本地網(wǎng)絡(luò)發(fā)送IGMP通用查詢報(bào)文，以查詢該網(wǎng)絡(luò)有哪些組播組的成員；
組播成員報(bào)告當(dāng)組播客戶端接收到普遍查詢報(bào)文時將向網(wǎng)絡(luò)發(fā)送其需要接收的組播組； 組播成員離開報(bào)告組播客戶端不再需要接收某個組播組數(shù)據(jù)時將發(fā)送成員離開報(bào)文，網(wǎng)絡(luò)將不會將該組播組的數(shù)據(jù)轉(zhuǎn)發(fā)到該組播客戶端上。在即R平臺上，為保證組播數(shù)據(jù)最優(yōu)傳輸，占用最少的網(wǎng)絡(luò)帶寬，各個即R節(jié)點(diǎn)將對IGMP協(xié)議報(bào)文分析，并建立和維護(hù)其組播轉(zhuǎn)發(fā)表，最優(yōu)的傳輸路徑算法同時也在此時被使用，大致流程為1、普通查詢報(bào)文進(jìn)入第一個RI3R節(jié)點(diǎn)(稱之為RI3R根節(jié)點(diǎn))，該節(jié)點(diǎn)將普通查詢報(bào)文重新打包，廣播該報(bào)文到其他RPR節(jié)點(diǎn)(稱之為RPR分支節(jié)點(diǎn))，RPR分支節(jié)點(diǎn)將報(bào)文轉(zhuǎn)發(fā)到各個組播客戶端；2、如果客戶端需要接收某個組播組的數(shù)據(jù)則發(fā)送組播成員報(bào)告報(bào)文，RPR分支節(jié)點(diǎn)接收到成員報(bào)告報(bào)文后，將建立組播成員列表，并將該報(bào)文轉(zhuǎn)發(fā)到RI3R根節(jié)點(diǎn)；3、RI^R根節(jié)點(diǎn)接收到成員報(bào)告報(bào)文時，通過傳輸路徑最優(yōu)生成算法建立組播轉(zhuǎn)發(fā)表，該表包含的信息有組播組、組播數(shù)據(jù)東向轉(zhuǎn)發(fā)的TTL，組播數(shù)據(jù)西向轉(zhuǎn)發(fā)的TTL，該表的建立是以減少傳輸?shù)奶鴶?shù)和到達(dá)需要該組播數(shù)據(jù)的RPR分支節(jié)點(diǎn)的時間為基礎(chǔ)。4、RI^R分支節(jié)點(diǎn)接收到組播客戶端的成員離開報(bào)文時，將判斷是否該分支下是否還存在其他組播客戶端在接收相同的組，如果不存在則將該成員離開報(bào)文轉(zhuǎn)發(fā)到RI3R根節(jié)占.5、RI^R根節(jié)點(diǎn)接收到成員離開報(bào)文，將重新計(jì)算該組播組數(shù)據(jù)的傳輸路徑。


以下描述和附圖是為了更清楚的說明現(xiàn)有技術(shù)或本發(fā)明的技術(shù)方案，通過比較， 可更加深入的理解本發(fā)明的創(chuàng)新、優(yōu)點(diǎn)以及實(shí)施細(xì)節(jié)。本發(fā)明通過實(shí)施例描述，因此本發(fā)明不受此處所公開的具體實(shí)施例的限制，下面將對附圖作進(jìn)一步的說明圖1所示基于RPR的組播數(shù)據(jù)傳輸模型，在RI3R平臺中包含6個RI3R節(jié)點(diǎn)，編號分別為A、B、C、D、E和F。其中組播服務(wù)器連接到RI3R節(jié)點(diǎn)A，因此該節(jié)點(diǎn)定義為RI3R根節(jié)點(diǎn)， 其它節(jié)點(diǎn)則定義為RPR分支節(jié)點(diǎn)。圖2所示為RI3R根節(jié)點(diǎn)上組播數(shù)據(jù)轉(zhuǎn)發(fā)表模型，當(dāng)組播數(shù)據(jù)到達(dá)RI3R根節(jié)點(diǎn)時，通過查找該表，如果對應(yīng)的組播組存在，則按照對應(yīng)的傳輸方向和TTL值傳輸，否則丟棄數(shù)據(jù)包。圖3為實(shí)例一生成的組播傳輸表示意。圖4為實(shí)例二生成的組播傳輸表示意。圖5為實(shí)例三生成的組播傳輸表示意。
具體實(shí)施例方式下面根據(jù)附圖和實(shí)例對本發(fā)明做進(jìn)一步詳細(xì)說明。實(shí)例一實(shí)例系統(tǒng)簡化模型如圖1所示，組播客戶端(1)需要接收224. 1. 1. 1組播組的數(shù)據(jù)，組播客戶端( 需要接收224. 1. 1. 2組播組的數(shù)據(jù)，那么將在RI^R根節(jié)點(diǎn)上生成一張組播轉(zhuǎn)發(fā)表，該表如圖3所示。組播服務(wù)器發(fā)送的組ID為224. 1. 1. 1的組播數(shù)據(jù)西向傳輸?shù)?RI3R節(jié)點(diǎn)B，然后被剔除，其傳輸?shù)奶鴶?shù)為1。組播服務(wù)器發(fā)送的組ID為224. 1. 1. 2的組播數(shù)據(jù)西向傳輸?shù)絉I3R節(jié)點(diǎn)C，然后被剔除，其傳輸?shù)奶鴶?shù)為2。如果采用廣播方式傳輸組播數(shù)據(jù)，兩個組的組播數(shù)據(jù)傳輸跳數(shù)都將為6，從而浪費(fèi)了大量的網(wǎng)絡(luò)資源。實(shí)例二在圖1所示的簡化模型基礎(chǔ)上，如果，RPR分支節(jié)點(diǎn)B、C、E和F下有用戶接收組 ID為224. 1. 1. 1的組播數(shù)據(jù)，RPR根節(jié)點(diǎn)將建立一條組播轉(zhuǎn)發(fā)表，如圖4所示。組播ID為 224. 1. 1. 1的組播數(shù)據(jù)在RI3R根節(jié)點(diǎn)上，從東、西兩個方向傳輸，其TTL值都為2，此時數(shù)據(jù)傳輸?shù)剿行枰獢?shù)據(jù)的節(jié)點(diǎn)的跳數(shù)為4。如果采用廣播或單方向傳輸時，其跳數(shù)為5。實(shí)例三在圖1所示的簡化模型基礎(chǔ)上，RPR分支節(jié)點(diǎn)B、D、E和F下，都有用戶接收組播組為224. 1. 1. 1的數(shù)據(jù)，RI3R根節(jié)點(diǎn)將建立一條組播轉(zhuǎn)發(fā)表，如圖5所示。組ID為224. 1. 1. 1 的組播數(shù)據(jù)從西向發(fā)送到RI3R節(jié)點(diǎn)B，從東向傳輸?shù)焦?jié)點(diǎn)F、E和D，數(shù)據(jù)到達(dá)所有節(jié)點(diǎn)的跳數(shù)為4。如果RI^R節(jié)點(diǎn)D的數(shù)據(jù)來自西向B，會導(dǎo)致跳數(shù)的增加，從而浪費(fèi)網(wǎng)絡(luò)資源。以上所述，僅為本發(fā)明典型的具體實(shí)施方式
，但本發(fā)明的保護(hù)范圍并不局限于此， 任何熟悉該技術(shù)的人在本發(fā)明所揭露的技術(shù)范圍內(nèi)，可輕易想到的變化或替換，都應(yīng)涵蓋在本發(fā)明的保護(hù)范圍之內(nèi)。因此，本發(fā)明的保護(hù)范圍應(yīng)當(dāng)以權(quán)利要求的保護(hù)范圍為準(zhǔn)。
權(quán)利要求
1.基于RPR組播數(shù)據(jù)傳輸模型，其特征包括基于RPR的組播傳輸網(wǎng)絡(luò)中，連接組播服務(wù)器的節(jié)點(diǎn)為RPR根節(jié)點(diǎn)，其維護(hù)一張組播數(shù)據(jù)轉(zhuǎn)發(fā)表，連接組播客戶端的節(jié)點(diǎn)為PRP分支節(jié)點(diǎn)，其將建立一張組播成員表，用于判斷該節(jié)點(diǎn)需要接收的組播組數(shù)據(jù)。
2.組播數(shù)據(jù)轉(zhuǎn)發(fā)表，其特征包括(1)組播組ID組播數(shù)據(jù)轉(zhuǎn)發(fā)表包含的組播ID極為組播IP地址；(2)東向傳輸TTL當(dāng)組播數(shù)據(jù)查找到傳輸表后將向東向傳輸數(shù)據(jù)包，并設(shè)定TTL值；(3)西向傳輸TTL當(dāng)組播數(shù)據(jù)查找到傳輸表后將向西向傳輸數(shù)據(jù)包，并設(shè)定TTL值。
3.組播數(shù)據(jù)轉(zhuǎn)發(fā)表計(jì)算方法，其特征包括組播數(shù)據(jù)從東、西兩個方向傳輸，以最小的跳數(shù)為原則，減少其到達(dá)所有需要該組播組數(shù)據(jù)節(jié)點(diǎn)的跳數(shù)。
全文摘要
本發(fā)明主要實(shí)現(xiàn)一種基于RPR傳輸平臺的組播傳輸路徑生成算法，算法的目的是減少到達(dá)需要該組播數(shù)據(jù)的RPR節(jié)點(diǎn)時間，以及減少到達(dá)所有需要該組播數(shù)據(jù)的RPR節(jié)點(diǎn)所經(jīng)過的跳數(shù)，從而提供整個網(wǎng)絡(luò)帶寬的利用率。
文檔編號H04L12/56GK102299840SQ20101021164
公開日2011年12月28日 申請日期2010年6月25日 優(yōu)先權(quán)日2010年6月25日
發(fā)明者王發(fā)強(qiáng) 申請人:深圳市邦彥信息技術(shù)有限公司