專(zhuān)利名稱(chēng)：在通信網(wǎng)中管理多播傳遞內(nèi)容的方法和系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及用于在通信網(wǎng)中管理多播傳遞內(nèi)容的方法和系統(tǒng)。
背景技術(shù)：
互聯(lián)網(wǎng)上的通信是基于數(shù)據(jù)分組的傳輸。
數(shù)據(jù)分組可以以不同的模式被發(fā)送，包括
.單播傳輸數(shù)據(jù)的分組被發(fā)送到由在分組內(nèi)規(guī)定的單播IP地址 標(biāo)識(shí)的單個(gè)主機(jī)；
.廣播傳輸數(shù)據(jù)的分組被發(fā)送到位于同一個(gè)網(wǎng)絡(luò)或子網(wǎng)絡(luò)中的、 由IP廣播地址標(biāo)識(shí)的所有主機(jī)；以及
-多播傳輸數(shù)據(jù)的分組被發(fā)送到由IP多播地址識(shí)別的任意主機(jī) 組組成的組。
關(guān)于多播傳輸，應(yīng)當(dāng)指出，當(dāng)同一個(gè)數(shù)據(jù)分組必須傳送到一個(gè)以 上的主機(jī)時(shí)，多播傳輸允許達(dá)到更大的效率，這是因?yàn)樵诮o定的網(wǎng)絡(luò) 上傳送時(shí)分組的拷貝數(shù)目被最小化。
多播傳輸是通過(guò)使用能夠把具有IP多播地址的數(shù)據(jù)分組正確地 路由到構(gòu)成多播組(MG)的主機(jī)組的、所謂的多播路由器實(shí)施的。
在主機(jī)與路由器之間的多播互動(dòng)由協(xié)+義規(guī)定，該協(xié)議允許主才幾請(qǐng) 求加入或離開(kāi)多播組。具體地，使用由IETF標(biāo)準(zhǔn)化的IGMP(互聯(lián)網(wǎng) 組管理協(xié)議)。
更具體地，IGMP協(xié)議的三個(gè)版本4皮標(biāo)準(zhǔn)化，即，IGMPvl(IETF RFC 1112)， IGMPv2(IETF RFC 2236)，和IGMPv3(IETF RFC 3376)。 協(xié)議的第一個(gè)版本，即IGMPvl,僅僅提供兩種類(lèi)型的消息 '成員(membership)凈艮告(或加入)；以及 '成員詢問(wèn)。
主機(jī)發(fā)送規(guī)定它們有興趣加入的組的多播地址的成員報(bào)告。 當(dāng)多播路由器接收到對(duì)于組的成員報(bào)告時(shí)，它開(kāi)始把尋址到該組
的多播流量轉(zhuǎn)發(fā)到接口，成員報(bào)告從該接口到達(dá)。
.離開(kāi)消息。
除了上述的IGMPvl協(xié)議的相同特性以外，這個(gè)協(xié)議實(shí)質(zhì)上提供 了允許主機(jī)明確地通知它離開(kāi)多播組的打算(離開(kāi)消息)的能力。而且， 有可能把成員詢問(wèn)發(fā)送到特定的多播組。另外，在IGMPv2成員詢問(wèn) 內(nèi)，主機(jī)被告知，路由器為接收成員組保持該組在特定的接口上是活 動(dòng)的所需要的最大時(shí)間。
IGMPv3協(xié)議提供源特定的多播選項(xiàng)，該選項(xiàng)允許主機(jī)在成員報(bào) 告消息中規(guī)定多播流量的源。
有可能規(guī)定以下模式的源
.排它模式主機(jī)提供它不希望從其接收流量的源的列表；以及 .包括模式主機(jī)指示它希望從其接收流量的源的列表。 多播路由器存儲(chǔ)被授權(quán)的源的列表，以決定是否在特定的網(wǎng)絡(luò)分 段上路由多播分組。
US 2003/0147392描述了一個(gè)過(guò)程，其中為了使得客戶主機(jī)能夠 了解記帳信息或鑒權(quán)失敗信息，通過(guò)把有關(guān)記帳的信息或關(guān)于客戶主 才幾的鑒權(quán)失敗的原因的信息添加到基于IGMP或MLD的協(xié)i義分組， 而把記帳信息或鑒權(quán)失敗原因從路由設(shè)備通知到客戶主機(jī)，其中上述 協(xié)議分組是客戶端主機(jī)與路由器設(shè)備之間的多播控制分組。
US 2005/0080901描述了用于根據(jù)網(wǎng)絡(luò)策略，諸如機(jī)器和用戶身 份，授權(quán)多播組成員的方法和設(shè)備。末端站通過(guò)LAN鏈路與LAN交 換機(jī)通信。LAN交換機(jī)禁止末端站在末端站或末端站的用戶被鑒權(quán)之 前加入任何多播組。 一旦末端站或末端站的用戶被鑒權(quán)，LAN交換機(jī) 就授權(quán)末端站加入與為末端站或用戶規(guī)定的多播組授權(quán)一致的一個(gè)或 多個(gè)多播組。LAN交換機(jī)迫使多播組授權(quán)參加者窺探(snoop)從末 端站接收的IGMP成員報(bào)告或處理從路由器接收的IGMP加入消息。

發(fā)明內(nèi)容
申請(qǐng)人觀察到，至今為止，本領(lǐng)域中提出的解決方案不是完全令 人滿意的。
例如，在IGMP協(xié)議方面，本申請(qǐng)人注意到以下情形 .IGMP協(xié)議與任何形式的憑證無(wú)關(guān)，因此，不可能創(chuàng)建基于 IGMP協(xié)議的付費(fèi)服務(wù)；在當(dāng)前的實(shí)施例中，簡(jiǎn)單地添加請(qǐng)求成為某 個(gè)多播組的一部分的任何人，而不用驗(yàn)證他們的身份和/或相關(guān)的授 權(quán)；
.IGMP協(xié)議不提供對(duì)于分發(fā)給定的數(shù)據(jù)分組所必須的資源的可 用性的檢驗(yàn)，因此可能出現(xiàn)，即使在某個(gè)接口上建立了用于給定的內(nèi) 容項(xiàng)的分發(fā)，由于必須的帶寬的不可用性，它不能以完整的形式到達(dá) 用戶；以及
.IGMP協(xié)議不提供在從主機(jī)到給定組的成員報(bào)告之后肯定/否定 應(yīng)答的傳輸；這例如阻止把關(guān)于與給定多播組的鏈路失敗的原因(網(wǎng)絡(luò) 問(wèn)題、拒絕授權(quán)、不充分的信用，...)的信息發(fā)送到主機(jī)。 對(duì)于US 2003/0147392，本申請(qǐng)人注意到以下情形 .在以上的申請(qǐng)中提出的方法使得內(nèi)容的獲得依賴(lài)于鑒權(quán)和授權(quán) 過(guò)程的成功結(jié)果，這不可避免地引入等待時(shí)間，它在希望允許用戶快 速掃描所有可能內(nèi)容(跳過(guò)(zapping))時(shí)是不可接受的；
.所提出的解決方案設(shè)想在客戶端和路由器上引入控制實(shí)體，所 以，需要更新在牽涉到的部件上的軟件，這在已存在有各種不同的已 安裝軟件基礎(chǔ)的客戶端的情況下可能難以管理；
.所提出的解決方案設(shè)想修改預(yù)先存在的協(xié)議(IGMP)，以4更允許 在安裝在客戶端上的實(shí)體與安裝在服務(wù)供應(yīng)商的路由器上的實(shí)體之間 交換消息這種修改首先是發(fā)送用于用戶鑒權(quán)的憑證和在出現(xiàn)錯(cuò)誤的 情形下提供反饋到用戶所必須的各種狀態(tài)消息需要。發(fā)現(xiàn)這個(gè)方法是 有限的，因?yàn)樗淖兞嗽O(shè)計(jì)協(xié)議已具有的用途；以及
.所提出的解決方案沒(méi)有設(shè)想檢驗(yàn)在多播路由器與發(fā)送多媒體內(nèi) 容請(qǐng)求的主機(jī)之間的資源的可用性，這保證經(jīng)由適當(dāng)?shù)姆?wù)質(zhì)量(QoS) 參數(shù)的所發(fā)送多媒體內(nèi)容的有效可用性。
而且，對(duì)于US 2005/0080901，本申請(qǐng)人注意到以下情形
-所提出的解決方案使得多播流的分發(fā)依賴(lài)于授權(quán)過(guò)程的成功結(jié) 果，所以不可避免地受到等待時(shí)間的影響，該等待時(shí)間在希望允許用 戶快速掃描所有可能的內(nèi)容(跳過(guò))時(shí)是不可接受的；
.所述解決方案沒(méi)有設(shè)想檢驗(yàn)在多播路由器與發(fā)送多媒體內(nèi)容請(qǐng) 求的主機(jī)之間的資源的可用性，這保證經(jīng)由適當(dāng)?shù)腝oS參數(shù)的所發(fā)送 多媒體內(nèi)容的有效可用性；
.所述解決方案沒(méi)有設(shè)想有關(guān)被發(fā)送的成員報(bào)告的結(jié)果的用戶通
知；
.所述解決方案確實(shí)允許在用完信用和發(fā)送恰當(dāng)?shù)木娴侥┒丝?戶后通過(guò)斷開(kāi)連接創(chuàng)建預(yù)先付費(fèi)的服務(wù)；以及-所述解決方案限于實(shí)施該解決方案的網(wǎng)絡(luò)單元，它應(yīng)當(dāng)是以太網(wǎng) 交換機(jī)。所提出的解決方案所以不能應(yīng)用于其中客戶端直接連接到路 由器或傳輸技術(shù)不是以太網(wǎng)的其它網(wǎng)絡(luò)情況。
本申請(qǐng)人解決了如何保證在網(wǎng)絡(luò)帶寬節(jié)省方面和在數(shù)據(jù)分組的 多播傳輸中由最終用戶感知的響應(yīng)時(shí)間方面的效率問(wèn)題。
本發(fā)明的目的是提供至少克服某些上述問(wèn)題的、用于在通信網(wǎng)中 管理多播傳遞內(nèi)容的方法。
具體地，本發(fā)明具有提供受控制的、高效的、且有效的內(nèi)容的多
播傳遞的目的受控制是因?yàn)槭跈?quán)/撤銷(xiāo)由控制實(shí)體和根據(jù)該請(qǐng)求從其 到達(dá)的接口或線路的身份被管理；高效是因?yàn)樗沟镁W(wǎng)絡(luò)資源的占用 最小化；有效是因?yàn)樗ㄟ^(guò)使得內(nèi)容訪問(wèn)時(shí)間最小化和允許 (courtesy)/替換內(nèi)容的呈現(xiàn)而增強(qiáng)了用戶體驗(yàn)。
這個(gè)目的是通過(guò)涉及用于在通信網(wǎng)中管理多播傳遞內(nèi)容的方法 的本發(fā)明而達(dá)到的，該方法的特征在于包括以下步驟
.檢驗(yàn)來(lái)自至少一個(gè)主機(jī)的、將是多播組的一部分的加入請(qǐng)求，以 便確定與所請(qǐng)求的組的該主機(jī)相關(guān)的傳遞策略；以及
.按照所述傳遞策略把主機(jī)與多播組相關(guān)聯(lián)。
本發(fā)明還涉及用于在通信網(wǎng)中管理多播傳遞內(nèi)容的系統(tǒng)，其中包
括由復(fù)制管理器監(jiān)管的復(fù)制點(diǎn)的路由器與形成多播組的多個(gè)主機(jī)通 信，其特征在于，包括
.控制點(diǎn)，檢驗(yàn)來(lái)自至少一個(gè)主機(jī)的、將是多播組的一部分的加入 請(qǐng)求，以便確定與所請(qǐng)求的組的該主機(jī)相關(guān)的傳遞策略；以及
.所述控制點(diǎn)指令所述復(fù)制管理器按照它的傳遞策略把主機(jī)與多 播組相關(guān)聯(lián)。
通過(guò)傳遞策略，在這里傳遞策略是指一組規(guī)則，該規(guī)則按照與用 戶有關(guān)的特定條件(即，他/她的身份，他/她的信用)，連接性(可得到 的帶寬)，內(nèi)容(即，必須的帶寬和其它屬性)，和/或通常按照可以實(shí)時(shí) 獲得的、用于分析會(huì)話的參數(shù)引導(dǎo)對(duì)內(nèi)容請(qǐng)求的處理。這些規(guī)則確定 對(duì)請(qǐng)求執(zhí)行(實(shí)施)的行動(dòng)，即，授權(quán)初始請(qǐng)求或用不同的內(nèi)容引用 具體地，在本解決方案中，功能塊，此后稱(chēng)為實(shí)施點(diǎn)，可被插入 到數(shù)據(jù)/控制流中，并且接口到服務(wù)控制基礎(chǔ)結(jié)構(gòu)。實(shí)施點(diǎn)的專(zhuān)門(mén)的模 塊，此后稱(chēng)為偵聽(tīng)點(diǎn)，把關(guān)于多播內(nèi)容的獲得的用戶請(qǐng)求通知給控制 平面，并實(shí)行由后者根據(jù)其控制邏輯作出的決定。
解決方案設(shè)想偵聽(tīng)點(diǎn)可以阻止來(lái)自客戶端的加入請(qǐng)求，同時(shí)等待 來(lái)自控制平面的應(yīng)答("實(shí)時(shí)控制，，)，或可以與來(lái)自控制平面的應(yīng)答無(wú) 關(guān)地把那些加入請(qǐng)求立即傳遞給多播路由器("推遲控制")。
根據(jù)所接收的加入請(qǐng)求，偵聽(tīng)點(diǎn)提供適當(dāng)?shù)耐ㄖ⒌娇刂破矫?上的功能塊，此后稱(chēng)為控制點(diǎn)(CP)，它管理對(duì)于服務(wù)的獲得的授權(quán)。 授權(quán)例如包括以下的情形
-根據(jù)申請(qǐng)人的憑證對(duì)內(nèi)容的訪問(wèn)控制授權(quán)；
-網(wǎng)絡(luò)資源可用性檢驗(yàn)，以保證用于內(nèi)容獲得的適當(dāng)?shù)腝oS水平；
以及
，居民信用可用性檢驗(yàn)。
控制點(diǎn)發(fā)送關(guān)于授權(quán)的應(yīng)答到實(shí)施點(diǎn)的模塊，此后稱(chēng)為激勵(lì)點(diǎn) (AP)。優(yōu)選地，在激勵(lì)點(diǎn)與控制點(diǎn)之間的通信是異步的。換句話說(shuō)， 請(qǐng)求-應(yīng)答通信范例不是強(qiáng)制性的(IP》CP， CP->AP):每個(gè)實(shí)體可以啟 動(dòng)與另一個(gè)實(shí)體的通信，無(wú)論何時(shí)該通信變得必要時(shí)無(wú)論何時(shí)偵聽(tīng) 點(diǎn)接收到加入或離開(kāi)多播組的用戶請(qǐng)求時(shí)，它把這一點(diǎn)通知控制點(diǎn)， 和無(wú)論何時(shí)控制點(diǎn)想要強(qiáng)行控制行動(dòng)時(shí)，它發(fā)送消息到激勵(lì)點(diǎn)。
在推遲控制的情形下，CP授權(quán)邏輯提供隱含的授權(quán)(暗示同意)。 僅僅當(dāng)對(duì)于新的訪問(wèn)的授權(quán)或者正在進(jìn)行的內(nèi)容獲得應(yīng)當(dāng)被拒絕時(shí)， 控制點(diǎn)才發(fā)送消息到激勵(lì)點(diǎn)，從而按照拒絕授權(quán)的理由(資源是不可得 到的，用戶被禁止訪問(wèn)內(nèi)容、不充分的信用等等)，重新引導(dǎo)用戶到允 許/替換內(nèi)容。
在接收到重新引導(dǎo)消息后，激勵(lì)點(diǎn)發(fā)送消息到多播路由器，它強(qiáng) 迫用戶離開(kāi)原先的多播組和同時(shí)加入栽有允許/替換內(nèi)容的多播組。 在重新引導(dǎo)消息中，激勵(lì)點(diǎn)適當(dāng)?shù)鼐幊蘊(yùn)AT(網(wǎng)絡(luò)地址轉(zhuǎn)換)功
能，從而在客戶端訪問(wèn)接口上發(fā)送重新引導(dǎo)命令到IA模塊，以便用 客戶預(yù)期的IP多播組地址替代在多播允許/替換組分組中的目的地地 址字段。這樣，重新引導(dǎo)對(duì)于用戶的應(yīng)用透明地發(fā)生。
根據(jù)在激勵(lì)點(diǎn)與控制點(diǎn)之間的對(duì)話可以是完全異步的事實(shí)，解決 方案使能了高級(jí)服務(wù)特征，諸如時(shí)間有限的內(nèi)容預(yù)覽或在預(yù)先付費(fèi)計(jì) 費(fèi)的情形下信用超時(shí)的實(shí)時(shí)處理。


為了更好地了解本發(fā)明，現(xiàn)在參照附圖描述純粹打算作為例子以 及不被看作為限制的優(yōu)選實(shí)施例，其中 圖1顯示實(shí)施本發(fā)明的方法的系統(tǒng)； 圖2顯示系統(tǒng)按照方法運(yùn)行的第一例子； 圖3顯示路由器按照方法運(yùn)行的第二例子； 圖4顯示系統(tǒng)按照方法運(yùn)行的第三例子； 圖5顯示系統(tǒng)按照方法運(yùn)行的第四例子； 圖6顯示系統(tǒng)按照方法運(yùn)行的第五例子； 圖7顯示系統(tǒng)按照方法運(yùn)行的第六例子； 圖8顯示系統(tǒng)按照方法運(yùn)行的第七例子； 圖9顯示系統(tǒng)按照方法運(yùn)行的第八例子； 圖io顯示系統(tǒng)控制平面的結(jié)構(gòu)的例子；以及 圖11-17描述由按照本發(fā)明的方法執(zhí)行的具體控制操作。
具體實(shí)施例方式
圖1顯示執(zhí)行本發(fā)明的方法的系統(tǒng)。
具體地，標(biāo)號(hào)10表示在數(shù)據(jù)平面(DPL)上的多播路由器(MR)， 多播路由器10包括復(fù)制點(diǎn)(RP)13，復(fù)制點(diǎn)(RP)13在它的輸入端接收 多播內(nèi)容Sl,S2，…，Sn， Scl，…，Sck，并且具有與多個(gè)主機(jī)15通信的輸 出端口。
多播路由器10還包括復(fù)制管理器(RM)17(是已知類(lèi)型的，因此不詳細(xì)描述)，用于監(jiān)管復(fù)制點(diǎn)13的活動(dòng)。
復(fù)制點(diǎn)13照管輸入數(shù)據(jù)分組的物理復(fù)制，在用戶(主機(jī)15)連接 到的端口上分發(fā)它們。根據(jù)實(shí)施方案，復(fù)制點(diǎn)13可以通過(guò)不同的技術(shù) 實(shí)現(xiàn)，例如它可包含軟件處理、ASIC、網(wǎng)絡(luò)處理器或在分組復(fù)制時(shí)專(zhuān) 用的任何其它硬件或軟件部件。
復(fù)制管理器17管理在復(fù)制點(diǎn)13的輸入與輸出之間關(guān)聯(lián)的數(shù)據(jù)庫(kù) 13a(交叉連接庫(kù)-CCR)，并根據(jù)數(shù)據(jù)庫(kù)的內(nèi)容生成適當(dāng)?shù)鼐幊虖?fù)制點(diǎn) 13的必須原語(yǔ)。
中間代理(IA)18被布置在每個(gè)主機(jī)15與復(fù)制點(diǎn)13之間的、去向 主機(jī)15的線路上；中間代理18負(fù)責(zé)把接口(例如，線路)識(shí)別號(hào)加到 由主機(jī)15發(fā)送的IGMP信令上，以便以明確的方式和與所提供的憑 證無(wú)關(guān)地識(shí)別主才幾。
而且，如果內(nèi)容重新引導(dǎo)在主機(jī)15被連接到路由器10的時(shí)刻是 活動(dòng)的，則中間代理18執(zhí)行用于多播內(nèi)容的NAT/PAT(網(wǎng)絡(luò)地址轉(zhuǎn)換 /端口地址轉(zhuǎn)換)功能。
按照本發(fā)明，在用戶的信號(hào)流中(按照本例，在IGMP流中)，提 供實(shí)施塊(EF)20，用來(lái)與服務(wù)控制基礎(chǔ)結(jié)構(gòu)相接口；這樣的實(shí)施塊20 接收—從一側(cè)-與由中間代理18加上的信息合并在一起的用戶請(qǐng)求 (例如，即時(shí)加入請(qǐng)求或離開(kāi)請(qǐng)求)(在圖l和其它圖上為了簡(jiǎn)化起見(jiàn)， 僅僅顯示在一個(gè)中間代理18與實(shí)施塊20之間的鏈路，然而，假設(shè)每 個(gè)中間代理18被鏈接到實(shí)施塊20，以發(fā)送用戶請(qǐng)求到該實(shí)施塊)，以 及從另一側(cè)與復(fù)制管理器17通信，以便如下面所述地實(shí)施可允許的請(qǐng) 求。
因此系統(tǒng)被構(gòu)建成對(duì)于復(fù)制管理器是"透明的，，。
更詳細(xì)地，實(shí)施塊20包括偵聽(tīng)點(diǎn)(IP)24，用于通過(guò)中間4戈理18 接收來(lái)自 一個(gè)主機(jī)的、將是多播組的一部分的用戶加入請(qǐng)求(例如， IGMP加入)，并把這些加入請(qǐng)求以通知消息的形式轉(zhuǎn)發(fā)到控制平面 (CPL)上的控制點(diǎn)(CP)28，控制點(diǎn)28檢驗(yàn)將是多播組的一部分的每個(gè) 加入請(qǐng)求，以便確定與該主機(jī)相關(guān)的且用于所請(qǐng)求的組的傳遞策略。
根椐在主機(jī)處相關(guān)的和與所請(qǐng)求的多播組有關(guān)的檢測(cè)到的傳遞
策略，控制點(diǎn)28確定請(qǐng)求是否是可允許的，從而管理對(duì)于從主機(jī)15 請(qǐng)求的服務(wù)的獲得的授權(quán)。
偵聽(tīng)點(diǎn)24譯碼輸入請(qǐng)求，以便通知用于對(duì)于由用戶作出的請(qǐng)求 實(shí)行控制操作的控制點(diǎn)28。
偵聽(tīng)點(diǎn)24可以配備有數(shù)據(jù)庫(kù)(未示出)，它對(duì)于每個(gè)組和對(duì)于每個(gè) 接口，跟蹤針對(duì)發(fā)送的通用詢問(wèn)的、接收到的成員報(bào)告消息。以上的 數(shù)據(jù)庫(kù)也可以被有利地使用于操控離開(kāi)組而沒(méi)有產(chǎn)生適當(dāng)?shù)南⒌奶?定主機(jī)，這是因?yàn)槿绻趯?duì)于特定組的詢問(wèn)后沒(méi)有接收到回答，則認(rèn) 為對(duì)于該接口該組不再存在。因此，數(shù)據(jù)庫(kù)被更新，以及用于以上組 的離開(kāi)命令被發(fā)送到復(fù)制管理器。
控制點(diǎn)28，按照用于請(qǐng)求加入特定多播組的主機(jī)的檢測(cè)到的傳遞 策略，管理對(duì)于服務(wù)的獲得的授權(quán)。
給予術(shù)語(yǔ)"授權(quán)"的意義是最廣泛可能的意義。作為例子，考慮以 下情形
.基于主機(jī)15的憑證對(duì)于內(nèi)容的訪問(wèn)控制授權(quán)； .在對(duì)于內(nèi)容傳遞的請(qǐng)求時(shí)的網(wǎng)絡(luò)資源可用性檢驗(yàn)，用以保證用于 內(nèi)容獲得的適當(dāng)?shù)腝oS水平；以及
.在對(duì)于內(nèi)容獲得的請(qǐng)求時(shí)和在內(nèi)容獲得期間的剩余信用可用性檢驗(yàn)。
根據(jù)由控制點(diǎn)28作出的決定，授權(quán)回答可被發(fā)送到激勵(lì)點(diǎn) (AP)30。激勵(lì)點(diǎn)30應(yīng)用由控制點(diǎn)28采取的決定，與復(fù)制管理器28 和中間代理18進(jìn)行通信。
在授權(quán)過(guò)程中可以以兩種不同的方式涉及到控制點(diǎn)28:實(shí)時(shí)授權(quán) 和推遲授權(quán)。
在第一情形下(實(shí)時(shí)授權(quán))，偵聽(tīng)點(diǎn)24等待控制點(diǎn)28授權(quán)，阻止 來(lái)自主機(jī)的請(qǐng)求。在這種情形下，僅僅在存在由控制點(diǎn)28輸出的授權(quán) 回答時(shí)才執(zhí)行加入操作。
在推遲授權(quán)的情形下，由控制點(diǎn)28提供的授權(quán)邏輯是基于暗示
的同意即，控制點(diǎn)28僅僅在對(duì)于內(nèi)容的訪問(wèn)或內(nèi)容的當(dāng)前獲得的授 權(quán)應(yīng)當(dāng)被拒絕時(shí)才對(duì)于激勵(lì)點(diǎn)30采取行動(dòng)。
無(wú)論如何，在這兩種情形下，在控制點(diǎn)28與激勵(lì)點(diǎn)30之間的對(duì) 話，有利地，是異步的；然而，對(duì)話也可以藉助于不同的協(xié)議被執(zhí)行。
在缺乏從控制點(diǎn)28得出的授權(quán)的情形下，激勵(lì)點(diǎn)30被迫進(jìn)行內(nèi) 容重新引導(dǎo)，即，把來(lái)自替換內(nèi)容儲(chǔ)藏庫(kù)(ACR)35的替換內(nèi)容B提供 到用戶，而不是原先請(qǐng)求的內(nèi)容A。替換內(nèi)容按照授權(quán)被拒絕的理由 (資源是不可得到的，用戶被禁止訪問(wèn)內(nèi)容、不充分的信用等等)可以 是不同的。通常，替換內(nèi)容是被使用來(lái)向用戶說(shuō)明授權(quán)被拒絕的理由 的允許消息。為了實(shí)行內(nèi)容替代，激勵(lì)點(diǎn)30執(zhí)行以下任務(wù)
，命令中間代理18替代目的地IP地址，以把原先內(nèi)容A的相同 的多播地址分配給替換內(nèi)容B(NAT/PAT功能)；以及
'創(chuàng)建用于復(fù)制管理器17的適當(dāng)?shù)腎GMP消息，以迫使用戶/主機(jī) 15與原先的多播組不相關(guān)，以及同時(shí)關(guān)聯(lián)接收替換消息的多播組。
按照從激勵(lì)點(diǎn)30接收的IGMP消息，復(fù)制管理器17更新交叉連 接儲(chǔ)藏庫(kù)，由此以與由控制點(diǎn)28施加的限制條件一致的方式控制數(shù)據(jù)
分組的復(fù)制過(guò)程。
由中間代理18實(shí)行的NAT/PAT功能，在來(lái)自激勵(lì)點(diǎn)30的明確 請(qǐng)求后被激勵(lì)/去激勵(lì)。
對(duì)于以上詳細(xì)描述的實(shí)體(即，實(shí)體24， 28和30)的物理位置沒(méi)有 限制。這些實(shí)體被顯示和被討論為在邏輯上是不同的，但它們的物理 位置根據(jù)實(shí)施方案，該實(shí)施方案可以按照情形把多個(gè)邏輯功能分組到 單個(gè)物理實(shí)體。
下面將參照顯示信令流程的圖2描述在實(shí)時(shí)控制的情形下本發(fā)明 的運(yùn)行。
當(dāng)客戶(未示出)需要內(nèi)容S1時(shí)(I產(chǎn)join(Sl))時(shí)，從中間代理18截 取請(qǐng)求信號(hào)，中間代理18添加關(guān)于從其接收請(qǐng)求的接口(IF1)的信息， 并把請(qǐng)求傳遞到偵聽(tīng)點(diǎn)24(I產(chǎn)join(Sl， IFl))。優(yōu)選地，接口信息包括 關(guān)于把主機(jī)15連接到網(wǎng)絡(luò)的線路的信息。
根據(jù)需要的多播組，偵聽(tīng)點(diǎn)24確定對(duì)于所請(qǐng)求的內(nèi)容應(yīng)當(dāng)應(yīng)用 實(shí)時(shí)控制還是推遲控制。
假設(shè)實(shí)時(shí)控制，諸如圖2所示的，該請(qǐng)求(I尸授權(quán)請(qǐng)求(Sl，IFl)) 被轉(zhuǎn)發(fā)到控制點(diǎn)28，控制點(diǎn)28從調(diào)用的原語(yǔ)的類(lèi)型，識(shí)別它是對(duì)于 實(shí)時(shí)控制的請(qǐng)求。
在對(duì)許可性的肯定驗(yàn)證的情形下，控制點(diǎn)28立即對(duì)激勵(lì)點(diǎn)30應(yīng) 答(即，生成授權(quán)信號(hào)(If授權(quán)回答(OK，Sl，IFl)))，激勵(lì)點(diǎn)30將生成去 向復(fù)制管理器17的加入消息I產(chǎn)加入(S1，IF1)，它與原先從客戶端接收 的消息完全相同的。
在控制點(diǎn)28處對(duì)許可性的否定驗(yàn)證的情形下(見(jiàn)圖3)，信號(hào)流正 好與以上對(duì)于應(yīng)答消息(I產(chǎn)授權(quán)回答(NOK，Sl，IFl，reason))現(xiàn)在將具有 "否定"類(lèi)型的差異所述的完全相同。因此，激勵(lì)點(diǎn)30將命令復(fù)制管理 器(I^加入(Scl，IFl))把主機(jī)15與替換內(nèi)容(SscO相關(guān)聯(lián)，而不是與原 先請(qǐng)求的內(nèi)容(SO相關(guān)聯(lián)。為了對(duì)于用戶的應(yīng)用透明地實(shí)現(xiàn)這個(gè)內(nèi)容 重新引導(dǎo)，激勵(lì)點(diǎn)命令(I6-NAT(SC1—S1，IF1》對(duì)于服務(wù)于用戶接口的 中間代理的適當(dāng)?shù)腘AT操作。
提供給用戶的替換內(nèi)容的選擇是由控制點(diǎn)28根據(jù)由運(yùn)營(yíng)商拒絕 的和由專(zhuān)門(mén)提供的內(nèi)容管理器(圖3上未示出)實(shí)施的邏輯執(zhí)行的。
推遲控制的情形顯示于圖4和5。
在拒絕授權(quán)的情形下，操作類(lèi)似于參照?qǐng)D3描述的情形；然而， 重新引導(dǎo)操作由控制點(diǎn)28以完全異步的且未連接到特定的用戶請(qǐng)求 的方式一皮實(shí)施。
在推遲控制的情形下，偵聽(tīng)點(diǎn)28不阻止等待來(lái)自控制平面的應(yīng) 答的用戶信令。
根據(jù)它自己的內(nèi)部邏輯，控制點(diǎn)28確立用戶是否不再使能某些 內(nèi)容的獲得，因此，通過(guò)將可能涉及到獲得的中斷的、替換內(nèi)容 Scl，...Sck重新引導(dǎo)到用戶而通過(guò)激勵(lì)點(diǎn)30對(duì)復(fù)制管理器17起作用。
如圖5所示，重新引導(dǎo)是通過(guò)激勵(lì)點(diǎn)30發(fā)送命令D6-離開(kāi)(S1，IF1) D7-加入(Scl，IFl)到復(fù)制管理器17以使得用戶離開(kāi)(D6-離開(kāi)(S1，IF1))
當(dāng)前消費(fèi)的內(nèi)容和加入替換內(nèi)容(D7-加入(Scl，IFl))而實(shí)行的。
為了保證所執(zhí)行的重新引導(dǎo)對(duì)于客戶是透明的，激勵(lì)點(diǎn)30也將 命令(D8二NAT(Scl—Sl，IFl))用于代用流的網(wǎng)絡(luò)地址轉(zhuǎn)換NAT。
在對(duì)于多播組的成員的請(qǐng)求的情形下分析方法的工作(以兩種模 式，實(shí)時(shí)和推遲)后，我們現(xiàn)在將分析在用戶通過(guò)從正在消費(fèi)的內(nèi)容離 開(kāi)的特定請(qǐng)求離開(kāi)多播組的情形下(離開(kāi))，該解決方案的預(yù)期行為。
當(dāng)用戶請(qǐng)求離開(kāi)時(shí)在使用的應(yīng)用完全不知道正在消費(fèi)的是原先 請(qǐng)求的內(nèi)容還是替換內(nèi)容。
從客戶端到達(dá)的離開(kāi)請(qǐng)求Ll-離開(kāi)(S1)所以總是參考原先請(qǐng)求的 多播組，即使替換內(nèi)容到達(dá)用戶。對(duì)于內(nèi)容傳遞系統(tǒng)，根據(jù)用戶以前 是否被重新引導(dǎo)到替換內(nèi)容，兩種情形是可能的。這兩種情形的管理 稍微不同，正如下面描述的。
如圖6所示管理離開(kāi)非替換內(nèi)容。
對(duì)于圖6，當(dāng)客戶作出離開(kāi)請(qǐng)求(L1-離開(kāi)(S1))時(shí)，離開(kāi)信號(hào)從中 間代理18被傳送到偵聽(tīng)點(diǎn)24。
由于網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT)規(guī)則沒(méi)有被應(yīng)用到中間代理18 ，中間代 理18使得離開(kāi)信號(hào)(L2二離開(kāi)(S1，IF1))通過(guò)，而不用修改它涉及的多播 組。
在接收到離開(kāi)信號(hào)后，偵聽(tīng)點(diǎn)24又使得它直接繼續(xù)到復(fù)制管理 器17(L3-離開(kāi)(S1,IF1))，但還把這一點(diǎn)通知控制點(diǎn)28 (L4-停止一獲得 (Sl，IFl))。
在其中用戶代之以正在消費(fèi)替換內(nèi)容的情形下，方法的工作是在 圖7上描述的那樣。
為了促進(jìn)關(guān)于以前描迷的內(nèi)容替換過(guò)程的透明性，對(duì)于原先的多 播組的請(qǐng)求(Ll-離開(kāi)(S1))將從主機(jī)15(客戶)到達(dá)。
中間代理18根據(jù)配置的NAT規(guī)則轉(zhuǎn)換離開(kāi)請(qǐng)求(L2-離開(kāi) (Scl，IFl)),其中用由用戶實(shí)際上正在消費(fèi)的替換內(nèi)容的地址替代原先 的地址。
此后，正如參照?qǐng)D6描述的以前的情形那樣，偵聽(tīng)點(diǎn)24把轉(zhuǎn)換后的離開(kāi)消息轉(zhuǎn)發(fā)到復(fù)制管理器17(L3^離開(kāi)(Scl，IFl))以及通知控制 點(diǎn)28(L4M亭止—獲得(Scl，IFl))。
然而，不像以前的情形，控制點(diǎn)28現(xiàn)在發(fā)送命令(L5-停止一替換 —內(nèi)容—獲得(Scl，IFl))到激勵(lì)點(diǎn)30，以去除由激勵(lì)點(diǎn)30通過(guò)適當(dāng)?shù)刂?令中間代理18而實(shí)行的NAT規(guī)則(L6去除—NAT(Scl，IF1))。所以， 來(lái)自同一個(gè)主機(jī)的可能的將來(lái)加入請(qǐng)求將不使用NAT規(guī)則作為缺省 項(xiàng)。
除了由主機(jī)明白地請(qǐng)求以外，內(nèi)容獲得的終止也可以是由于與保 持活躍的消息相關(guān)的暫停時(shí)間到期而引起的，這對(duì)于多播路由器確定 它向其供應(yīng)復(fù)制的內(nèi)容的主機(jī)實(shí)際上是否對(duì)于內(nèi)容感興趣，是有用的。 沒(méi)有這些機(jī)制，多播路由器冒著繼續(xù)無(wú)限期地復(fù)制內(nèi)容的風(fēng)險(xiǎn)，即使
例如遇到硬件或軟件問(wèn)題)。
正如在背景技術(shù)部分中描述的，IGMP根據(jù)主機(jī)應(yīng)當(dāng)通過(guò)發(fā)送適 當(dāng)?shù)某蓡T報(bào)告消息而確認(rèn)的成員詢問(wèn)消息實(shí)施這些機(jī)制。
所以，以與系統(tǒng)的工作被限于對(duì)明確的離開(kāi)進(jìn)行正確的管理的相 同方式，限于這種類(lèi)型的機(jī)制的隱含的離開(kāi)也應(yīng)當(dāng)被正確地檢測(cè)和處 理。
在IGMP的特定情形下，解決方案如下面詳細(xì)描述的那樣工作(還 參閱圖8)。
只要從復(fù)制點(diǎn)13發(fā)送到主機(jī)15的成員詢問(wèn)消息Ql-詢問(wèn)(Scl) 由來(lái)自詢問(wèn)的主機(jī)15的回答成員報(bào)告消息Rl-報(bào)告(Scl)確認(rèn)，偵聽(tīng) 點(diǎn)24就使它本身限于把報(bào)告R2-報(bào)告(Sel，IFl)透明地轉(zhuǎn)發(fā)到復(fù)制管 理器17，這樣，多播路由器10不中止內(nèi)容傳遞。
替代地，假如無(wú)論什么原因，主機(jī)15沒(méi)有用成員報(bào)告消息確認(rèn) 被發(fā)送給它的成員詢問(wèn)消息Qh詢問(wèn)(Scl)(圖9)，當(dāng)暫停時(shí)間到期時(shí)， 偵聽(tīng)點(diǎn)24通知(L4-停止—獲得(Scl，IFl))控制點(diǎn)28,停止用戶的內(nèi)容 獲得，正如以上在客戶明確離開(kāi)的情形下已描述的那樣。如果獲得的 內(nèi)容是替換內(nèi)容(如圖8和9所示)，則控制點(diǎn)28還命令去除NAT規(guī)
則(L6-去除—NAT(Scl，IF))。
正如已公開(kāi)的那樣，在控制平面上操作的邏輯實(shí)體是控制點(diǎn)28。 控制點(diǎn)28被委托以對(duì)于所請(qǐng)求的或當(dāng)前正由用戶消費(fèi)的服務(wù)的
傳遞的控制。
正如已說(shuō)明的那樣，由控制點(diǎn)28按照與請(qǐng)求加入多播組的主機(jī) 相關(guān)的所檢測(cè)的傳遞策略執(zhí)行的控制功能可以具有不同的種類(lèi)以及可 以包含一個(gè)或多個(gè)以下項(xiàng)
-由主機(jī)15根據(jù)他的憑證控制內(nèi)容訪問(wèn)授權(quán)；
.當(dāng)由主機(jī)15作出對(duì)于傳遞內(nèi)容的請(qǐng)求時(shí)，控制網(wǎng)絡(luò)資源可用性， 以便在內(nèi)容獲得期間保證適當(dāng)?shù)腝oS水平；
-在內(nèi)容獲得期間由主機(jī)15作出對(duì)于傳遞內(nèi)容的請(qǐng)求時(shí)，控制剩 余的信用。
從基礎(chǔ)結(jié)構(gòu)的觀點(diǎn)看來(lái)，控制點(diǎn)28用作為在所牽涉到的各種實(shí) 體之間的協(xié)調(diào)器，每個(gè)實(shí)體操作特定的控制。
控制點(diǎn)28的特征在于用于滿足運(yùn)營(yíng)商的對(duì)于服務(wù)控制的需求的 定制部件。
所利用的控制實(shí)體的類(lèi)型事實(shí)上根據(jù)運(yùn)營(yíng)商希望實(shí)行的傳遞策 略的類(lèi)型。
例如，可以i殳想(圖10):
.AAA服務(wù)器40管理與鑒權(quán)、授權(quán)、和基本記帳有關(guān)的事務(wù)。正 如已知的那樣，A A A服務(wù)器是操控用戶對(duì)于訪問(wèn)到計(jì)算機(jī)資源的請(qǐng)求 和提供鑒權(quán)、授權(quán)、和記帳(AAA)服務(wù)的服務(wù)器程序。AAA服務(wù)器典 型地與網(wǎng)絡(luò)訪問(wèn)和網(wǎng)關(guān)服務(wù)器互動(dòng)以及與包含用戶信息的數(shù)據(jù)庫(kù)和目 錄互動(dòng)。設(shè)備或應(yīng)用藉以與AAA服務(wù)器通信的當(dāng)前標(biāo)準(zhǔn)是遠(yuǎn)程鑒權(quán) 撥號(hào)用戶服務(wù)(Radius);以及
.QoS服務(wù)器42,用于管理QoS事項(xiàng)。正如對(duì)于QoS術(shù)語(yǔ)已知的 那樣，它是指提供一致的、可預(yù)測(cè)的數(shù)據(jù)服務(wù)傳遞以滿足客戶應(yīng)用要 求的能力。
變化、和提供一致的數(shù)據(jù)吞吐容量的能力；
.服務(wù)器42m,實(shí)行內(nèi)容管理器(CM);以及
.服務(wù)器43，用于管理基于預(yù)先付費(fèi)(PP)的計(jì)費(fèi)。
控制點(diǎn)28的定制也是要諸如保證與常常沒(méi)有配備以標(biāo)準(zhǔn)接口的
所述控制實(shí)體的接口。
在例如AAA服務(wù)器42的情形下，可以使用諸如Radius或Tacacs
那樣的協(xié)議。
然而，相同的協(xié)議不適用于上述其它類(lèi)型的服務(wù)器42和43，因
為它們不總是有已建立的訪問(wèn)標(biāo)準(zhǔn)。
例如，到QoS服務(wù)器42的訪問(wèn)可以在各種模式下進(jìn)行
SOAP/XML (具有專(zhuān)用API接口)， http， Diameter等等。
控制點(diǎn)28至少根據(jù)在每種情形下確定的傳遞策略來(lái)管理對(duì)于訪
問(wèn)內(nèi)容的授權(quán)。傳遞策略具體地可以基于一個(gè)或多個(gè)以下項(xiàng) -內(nèi)容，諸如所需要的帶寬和/或其它屬性； .連接性，諸如可得到的帶寬和/或QoS(資源可用性)； 涉及到用戶的特定條件，諸如身份和/或計(jì)費(fèi)信息(剩余的信用)；
以及
.通過(guò)分析會(huì)話可以實(shí)時(shí)地獲取的其它參數(shù)。 如果授權(quán)失敗，則控制點(diǎn)28如上所述用來(lái)強(qiáng)迫中斷內(nèi)容傳遞(強(qiáng) 迫離開(kāi)多播組)或把用戶重新引導(dǎo)到替換內(nèi)容(例如，悲劇電影)。 控制點(diǎn)28還管理其它事物，包括 .管理記帳事件(開(kāi)始，停止)；
-基于用戶信息(用戶類(lèi)型或終端能力)或基于定位信息的內(nèi)容重 新引導(dǎo)；
.管理用戶的內(nèi)容獲得的終止。
控制點(diǎn)28經(jīng)由標(biāo)準(zhǔn)接口使得以上的功能對(duì)于框架的其余部分是
可得到的，控制點(diǎn)28通過(guò)標(biāo)準(zhǔn)接口可以執(zhí)行它的控制器功能。 在接口級(jí)別上提供所有必須信息，用于識(shí)別
.事件的類(lèi)型(授權(quán)請(qǐng)求，記帳開(kāi)始，…)；.它涉及到的用戶(請(qǐng)求接口 ，...)； .它涉及到的內(nèi)容(多播組，來(lái)自EPG的識(shí)別號(hào)，...)。 為調(diào)用控制點(diǎn)28來(lái)管理的每個(gè)功能，規(guī)定用于管理請(qǐng)求的適當(dāng) 邏輯。例如，對(duì)于管理內(nèi)容訪問(wèn)授權(quán)請(qǐng)求，控制點(diǎn)28被指令聯(lián)系哪些 控制服務(wù)器(和通過(guò)哪些原語(yǔ)來(lái)做到這一點(diǎn))，如何使用傳送給它的信 息，如何使用所聯(lián)系的各種控制服務(wù)器的應(yīng)答，以及基于這些，如何 產(chǎn)生對(duì)于該請(qǐng)求的應(yīng)答消息。
在以下的部分，將詳細(xì)說(shuō)明由控制點(diǎn)28執(zhí)行的某些特定操作。 圖11顯示在在線授權(quán)由于缺乏對(duì)于申請(qǐng)者的授權(quán)而被拒絕的情 形下由控制點(diǎn)28執(zhí)行的操作。 更具體地，操作如下
.授權(quán)請(qǐng)求100從偵聽(tīng)點(diǎn)24傳送到控制點(diǎn)28;
.控制點(diǎn)28把授權(quán)請(qǐng)求傳送110到AAA服務(wù)器40，在其中檢驗(yàn) 請(qǐng)求的可允許性；
AAA服務(wù)器40發(fā)現(xiàn)請(qǐng)求是不允許的，以及生成被傳送到控制點(diǎn) 28的拒絕信號(hào)120;
.控制點(diǎn)28把指令130給予內(nèi)容管理器42m，以便確定替換內(nèi)容；
-要使用的替換內(nèi)容的指示140被發(fā)送到控制點(diǎn)28;
.控制點(diǎn)28提供否定的授權(quán)回答145給激勵(lì)點(diǎn)30,在該授權(quán)回答 中規(guī)定把替換內(nèi)容提供到用戶而不是所請(qǐng)求的內(nèi)容，以及授權(quán)被拒絕 的理由。
圖12顯示在在線授權(quán)由于預(yù)先付費(fèi)用戶的不充分的信用而被拒 絕的情形下由控制點(diǎn)2 8執(zhí)行的操作。 更具體地，操作如下
.授權(quán)請(qǐng)求200從偵聽(tīng)點(diǎn)24傳送到控制點(diǎn)28;
.控制點(diǎn)28把授權(quán)請(qǐng)求傳送210到AAA服務(wù)器40，在其中檢驗(yàn) 請(qǐng)求的可允許性；
.AAA服務(wù)器40首先發(fā)現(xiàn)請(qǐng)求是可允許的，以及生成被傳送到控 制點(diǎn)28的OK信號(hào)220;.由OK信號(hào)220激活的控制點(diǎn)28生成指向具有預(yù)先付費(fèi)的用戶 的數(shù)據(jù)的服務(wù)器43的信用檢驗(yàn)請(qǐng)求230;
-服務(wù)器43生成被傳送到控制點(diǎn)28的拒絕信號(hào)240(即，用戶不 再有信用)；
.控制點(diǎn)28把指令250給予內(nèi)容管理器42m以便確定替換內(nèi)容；
以及
.要使用的替換內(nèi)容的指示260被發(fā)送到控制點(diǎn)28;
-控制點(diǎn)28提供否定的授權(quán)回答265給激勵(lì)點(diǎn)30，在該授權(quán)回答 中規(guī)定把替換內(nèi)容提供到用戶而不是所請(qǐng)求的內(nèi)容，以及授權(quán)被拒絕 的理由(即，對(duì)于內(nèi)容獲得不充分的信用)。
圖13顯示在在線授權(quán)由于網(wǎng)絡(luò)資源不可用性而被拒絕的情形下 由控制點(diǎn)28執(zhí)行的操作。
更具體地，操作如下
.授權(quán)請(qǐng)求300從偵聽(tīng)點(diǎn)24傳送到控制點(diǎn)28;
.控制點(diǎn)28把授權(quán)請(qǐng)求傳送310到AAA服務(wù)器40，在其中檢驗(yàn) 請(qǐng)求的可允許性；
AAA服務(wù)器40首先發(fā)現(xiàn)請(qǐng)求是可允許的(識(shí)別預(yù)先付費(fèi)的用 戶)，以及生成被傳送到控制點(diǎn)28的OK信號(hào)320;
由OK信號(hào)320激活的控制點(diǎn)28生成指向具有預(yù)先付費(fèi)的用戶 的數(shù)據(jù)的服務(wù)器43的信用檢驗(yàn)請(qǐng)求330;
.服務(wù)器43生成被傳送到控制點(diǎn)28的OK信號(hào)340(即，用戶具 有信用)；
-控制點(diǎn)28生成指向QoS服務(wù)器42的資源和接口的可用性請(qǐng)求
350;
QoS服務(wù)器42生成被傳送到控制點(diǎn)28的拒絕信號(hào)360(即，因 為沒(méi)有足夠的可得到資源來(lái)保證滿意的內(nèi)容獲得)；
.控制點(diǎn)28把指令370給予內(nèi)容管理器42m，以便確定替換內(nèi)容；
以及
.要使用的替換內(nèi)容的指示380被發(fā)送到控制點(diǎn)28;-控制點(diǎn)28提供否定的授權(quán)回答385給激勵(lì)點(diǎn)30，在該授權(quán)回答 中規(guī)定把替換內(nèi)容提供到用戶而不是所請(qǐng)求的內(nèi)容，以及授權(quán)被拒絕 的理由(即，在該時(shí)刻資源是不可得到的)。
圖14顯示在對(duì)于預(yù)先付費(fèi)用戶的未購(gòu)買(mǎi)內(nèi)容的預(yù)覽讓步的情形 下由控制點(diǎn)28執(zhí)行的操作。
更具體地，操作如下
.授權(quán)請(qǐng)求400從偵聽(tīng)點(diǎn)24傳送到控制點(diǎn)28;
.控制點(diǎn)28把授權(quán)請(qǐng)求傳送410到AAA服務(wù)器40，在其中檢驗(yàn) 請(qǐng)求的可允許性；
AAA服務(wù)器40發(fā)現(xiàn)請(qǐng)求410是可允許的(識(shí)別預(yù)先付費(fèi)的用戶 -預(yù)先付費(fèi)的用戶沒(méi)有購(gòu)買(mǎi)內(nèi)容，但被允許進(jìn)行預(yù)覽)，以及生成被傳 送到控制點(diǎn)28的OK信號(hào)420;
.由OK信號(hào)420激活的控制點(diǎn)28生成指向具有預(yù)先付費(fèi)的用戶 的數(shù)據(jù)的服務(wù)器43的信用檢驗(yàn)請(qǐng)求430;
.服務(wù)器43生成被傳送到控制點(diǎn)28的OK信號(hào)440(即，用戶具 有信用)；
.控制點(diǎn)28生成指向QoS服務(wù)器42的資源和接口的可用性請(qǐng)求
450;
QoS服務(wù)器42生成被傳送到控制點(diǎn)28的OK信號(hào)460; .由OK信號(hào)460激活的控制點(diǎn)向AAA服務(wù)器40請(qǐng)求470消除 預(yù)覽許可(為了避免用戶使用預(yù)覽可能性一次以上)；
點(diǎn)30;
'在預(yù)覽周期481的末端，控制點(diǎn)28把指令490給予內(nèi)容管理器 42m，以確定替換內(nèi)容；以及
.要使用的替換內(nèi)容的指示495被發(fā)送到控制點(diǎn)28;
.控制點(diǎn)28把表示要提供到用戶的替換內(nèi)容以及發(fā)生重新引導(dǎo)的 理由(即，預(yù)覽定時(shí)器到期)的重新引導(dǎo)消息496發(fā)送到激勵(lì)點(diǎn)30。
圖15顯示在對(duì)于預(yù)先付費(fèi)用戶的未購(gòu)買(mǎi)內(nèi)容的預(yù)覽拒絕的情形
下由控制點(diǎn)28執(zhí)行的操作。 更具體地，操作如下
-授權(quán)請(qǐng)求500從偵聽(tīng)點(diǎn)24傳送到控制點(diǎn)28;
-控制點(diǎn)28把授權(quán)請(qǐng)求傳送510到AAA服務(wù)器40,在其中檢驗(yàn) 請(qǐng)求的可允許性；
AAA服務(wù)器40檢查請(qǐng)求510和生成確認(rèn)用戶已被允許進(jìn)行預(yù)覽 的信號(hào)520-信號(hào)520被傳送到控制點(diǎn)28;
-由信號(hào)520激活的控制點(diǎn)28生成指向具有預(yù)先付費(fèi)的用戶的數(shù) 據(jù)的服務(wù)器43的信用檢驗(yàn)請(qǐng)求530;
.服務(wù)器43生成被傳送到控制點(diǎn)28的OK信號(hào)540(即，用戶具 有信用)；
.控制點(diǎn)28生成指向QoS服務(wù)器42的資源和接口的可用性請(qǐng)求
550;
QoS服務(wù)器42生成被傳送到控制點(diǎn)28的OK信號(hào)560;
.控制點(diǎn)28把指令570給予內(nèi)容管理器42m，以確定替換內(nèi)容；
.要使用的替換內(nèi)容的指示580被發(fā)送到控制點(diǎn)28;
.控制點(diǎn)28把表示要提供到用戶的替換內(nèi)容以及發(fā)生重新引導(dǎo)的 理由(即，預(yù)覽已被使用于請(qǐng)求的內(nèi)容)的重新引導(dǎo)消息發(fā)送到激勵(lì)點(diǎn) 30。
圖16顯示在預(yù)先付費(fèi)的用戶的內(nèi)容獲得期間檢測(cè)到不充分的信 用的條件的情形下由控制點(diǎn)28執(zhí)行的操作。 更具體地，操作如下
.不充分信用的信號(hào)600從管理預(yù)先付費(fèi)的用戶的服務(wù)器發(fā)送到 控制點(diǎn)28;
.為了保證QoS內(nèi)容而請(qǐng)求的頻帶分配被釋放610; .控制點(diǎn)28生成到AAA接口 40的、用于停止記帳的信號(hào)620; .控制點(diǎn)28生成到具有預(yù)先付費(fèi)的用戶的數(shù)據(jù)的服務(wù)器43的、用 于停止計(jì)費(fèi)的信號(hào)630;
.控制點(diǎn)28把指令640給予內(nèi)容管理器42m，以確定替換內(nèi)容；
.要使用的替換內(nèi)容的指示650被發(fā)送到控制點(diǎn)28;
-控制點(diǎn)28把表示要提供到用戶的替換內(nèi)容以及發(fā)生重新引導(dǎo)的 理由(即，信用到期)的重新引導(dǎo)消息655發(fā)送到激勵(lì)點(diǎn)3 0 。
圖17說(shuō)明涉及到內(nèi)容705獲得的結(jié)束的操作，以及更具體地-在內(nèi)容獲得期間，偵聽(tīng)點(diǎn)24把對(duì)于停止內(nèi)容獲得的請(qǐng)求700傳 送到控制點(diǎn)2.為了保證QoS內(nèi)容而請(qǐng)求的頻帶分配被釋放710;.控制點(diǎn)28生成到AAA服務(wù)器40的、用于停止記帳的請(qǐng)求720;以及.控制點(diǎn)28生成到內(nèi)容管理器42m的、用于停止計(jì)費(fèi)的請(qǐng)求730。 在所提出的解決方案中，現(xiàn)有技術(shù)的固有限制如下被克服 在本發(fā)明中，不必等待完成鑒權(quán)操作以把流量路由到用戶。這允 許保證適當(dāng)?shù)挠脩趔w驗(yàn)，即使在存在復(fù)雜的授權(quán)檢驗(yàn)的情形下；在其中主機(jī)被發(fā)現(xiàn)為未被授權(quán)接收給定的內(nèi)容的情形下，流量的傳輸隨后 被阻止。
在本發(fā)明中，控制實(shí)體正好位于網(wǎng)絡(luò)單元上，因此不需要對(duì)于被 安裝在客戶端上的軟件進(jìn)行修改。被安裝在第一網(wǎng)絡(luò)單元上的控制實(shí) 體能夠以明確的方式識(shí)別接口，或客戶請(qǐng)求源自的線路。這種類(lèi)型的 方法也具有更大的安全水平，這是因?yàn)樗鼘?duì)于由最終客戶進(jìn)行的可能 篡改是不開(kāi)放的。
本發(fā)明并不設(shè)想對(duì)于標(biāo)準(zhǔn)協(xié)議的任何改變。新的功能實(shí)體被插入 到信息流中，它在可保持不變的標(biāo)準(zhǔn)協(xié)議分組的通道上執(zhí)行授權(quán)控制或重新引導(dǎo)到允許消息的操作；創(chuàng)新的單元被限定并且僅僅在附加功 能實(shí)體之間交換，而不在標(biāo)準(zhǔn)功能末端點(diǎn)之間交換。
本發(fā)明設(shè)想通過(guò)與適當(dāng)?shù)目刂品?wù)器互動(dòng)和可能的重新引導(dǎo)到息，而檢驗(yàn)適當(dāng)?shù)馁Y源的可用性。
本發(fā)明設(shè)想通過(guò)以完全透明的方式用替代內(nèi)容(即，允許消息)替換由客戶請(qǐng)求的內(nèi)容的NAT/PAT功能而把消息發(fā)送到用戶，該替代
內(nèi)容然后由請(qǐng)求內(nèi)容的同一個(gè)應(yīng)用顯示。
本發(fā)明設(shè)想在從控制服務(wù)器接收到表示不充分信用的消息后，多
播控制實(shí)體通過(guò)NAT/PAT功能使得把允許消息重新引導(dǎo)到客戶，以 通知缺乏信用，而不是請(qǐng)求的內(nèi)容。
本發(fā)明給出技術(shù)上獨(dú)立的解決方案。如上所述，作為例子識(shí)別三 種應(yīng)用場(chǎng)合主機(jī)直接訪問(wèn)多播路由器的網(wǎng)絡(luò)、主機(jī)經(jīng)由具有以太網(wǎng) 第2層交換功能的設(shè)備訪問(wèn)多播路由器的網(wǎng)絡(luò)、以及主機(jī)經(jīng)由具有 ATM第2層功能的設(shè)備訪問(wèn)多播路由器的網(wǎng)絡(luò)。
權(quán)利要求
1.一種用于在通信網(wǎng)中管理多播傳遞內(nèi)容的方法，其特征在于包括步驟·檢驗(yàn)將是多播組的一部分的、來(lái)自至少一個(gè)主機(jī)(15)的加入請(qǐng)求，以針對(duì)所請(qǐng)求的組，確定與該主機(jī)相關(guān)的傳遞策略；以及·按照所述傳遞策略把主機(jī)與多播組相關(guān)聯(lián)。
2. 如權(quán)利要求1所述的方法，其中所述檢驗(yàn)步驟包括識(shí)別不可 允許的請(qǐng)求。
3. 如權(quán)利要求1所述的方法，其中在所述檢驗(yàn)步驟中，檢驗(yàn)對(duì) 于加入請(qǐng)求的授權(quán)的存在。
4. 如權(quán)利要求3所述的方法，其中在存在授權(quán)的情形下，執(zhí)行 把授權(quán)的主機(jī)(15)與所請(qǐng)求的多播組相關(guān)聯(lián)的步驟。
5. 如權(quán)利要求3所述的方法，其中在缺乏授權(quán)的情形下，執(zhí)行 把授權(quán)的主機(jī)(15)與不同于所請(qǐng)求的多播組的組相關(guān)聯(lián)的步驟。
6. 如權(quán)利要求3所述的方法，其中在缺乏授權(quán)的情形下，提供 生成與授權(quán)被拒絕的理由有關(guān)的至少一個(gè)允許消息并將其引導(dǎo)到未授 權(quán)的主機(jī)(15)的步驟。
7. 如權(quán)利要求1所述的方法，其中檢驗(yàn)加入請(qǐng)求的步驟是與藉 助于被布置在主機(jī)(15)和復(fù)制點(diǎn)(13)之間的中間代理(18)添加線路識(shí)別 符以便以明確的方式且與由主機(jī)(15)提供的憑證無(wú)關(guān)地標(biāo)識(shí)主機(jī)(15) 的步驟相關(guān)聯(lián)。
8. 如權(quán)利要求1所述的方法，其中檢驗(yàn)加入請(qǐng)求的步驟是與在 用于輸出通知消息的偵聽(tīng)點(diǎn)(24)處譯碼來(lái)自主機(jī)(15)的輸入加入請(qǐng)求 (IGMP報(bào)告，IGMP離開(kāi))的步驟相關(guān)聯(lián)。
9. 如權(quán)利要求8所述的方法，其中所述偵聽(tīng)點(diǎn)(24)配備有數(shù)據(jù)庫(kù)， 以及所述方法還包括以下步驟.發(fā)送詢問(wèn)到所述主機(jī)(15);-接收來(lái)自主機(jī)的成員報(bào)告作為對(duì)于所發(fā)送的詢問(wèn)的回答； .跟蹤在所述數(shù)據(jù)庫(kù)中發(fā)送的詢問(wèn)；.展現(xiàn)一組立即離開(kāi)主機(jī)的組的離去，如果在對(duì)于特定組的詢問(wèn)后 沒(méi)有接收到回答，則立即離開(kāi)主機(jī)離開(kāi)組而不產(chǎn)生適當(dāng)?shù)南ⅰ?br> 10. 如權(quán)利要求l所述的方法，其中檢驗(yàn)步驟包括檢驗(yàn)至少一個(gè) 授權(quán)的存在的步驟；所述授權(quán)包含以下的至少一項(xiàng)-基于主機(jī)(l 5)的憑證的對(duì)內(nèi)容的訪問(wèn)控制授權(quán)；，在對(duì)于內(nèi)容傳遞的請(qǐng)求后的網(wǎng)絡(luò)資源可用性檢驗(yàn)；以及 .在對(duì)于內(nèi)容獲得的請(qǐng)求后和在內(nèi)容獲得期間剩余的信用可用性檢驗(yàn)。
11. 如權(quán)利要求l所述的方法，還包括步驟當(dāng)加入請(qǐng)求被拒絕 時(shí)向復(fù)制點(diǎn)(13)的復(fù)制管理器(17)發(fā)送拒絕命令(30);復(fù)制點(diǎn)(13)負(fù)責(zé) 輸入數(shù)據(jù)分組的物理復(fù)制，并在所述主機(jī)連接到的端口上分發(fā)它們。
12. 如權(quán)利要求ll所迷的方法，其中所述復(fù)制管理器(17)根據(jù)所 述拒絕命令生成原語(yǔ)，用于編程，例如更新，所述復(fù)制管理器(17)的 數(shù)據(jù)庫(kù)，由此以與由所述傳遞策略施加的限制一致的方式控制數(shù)據(jù)分 組的物理復(fù)制過(guò)程。
13. 如權(quán)利要求l所述的方法，其中檢驗(yàn)加入請(qǐng)求的步驟包括確 定對(duì)于從主機(jī)(15)請(qǐng)求的內(nèi)容應(yīng)當(dāng)施加實(shí)時(shí)控制還是推遲控制的步 遞
14. 如權(quán)利要求13所述的方法，其中實(shí)時(shí)控制包括發(fā)送授權(quán)請(qǐng) 求到控制實(shí)體和在進(jìn)一步處理用戶加入請(qǐng)求之前等待授權(quán)回答的步 驟。
15. 如權(quán)利要求l所述的方法，其中推遲控制包括提供隱含授權(quán) 和僅僅當(dāng)對(duì)于請(qǐng)求的授權(quán)按照所述傳遞策略被拒絕時(shí)才阻止加入請(qǐng)求 的步驟。
16. 如權(quán)利要求l所述的方法，其中偵聽(tīng)點(diǎn)(24)接收來(lái)自主機(jī)(15) 的用戶加入請(qǐng)求，并把這些請(qǐng)求以通知消息的形式轉(zhuǎn)發(fā)到控制點(diǎn)(28)， 控制點(diǎn)(28)決定哪些加入請(qǐng)求是可允許的，因此管理對(duì)于從主機(jī)(15) 請(qǐng)求的服務(wù)的獲得的授權(quán)； 所述方法還包括以下步驟-通ii主機(jī)生成離開(kāi)信號(hào)來(lái)作出離開(kāi)請(qǐng)求(L1);.使得離開(kāi)信號(hào)通過(guò)所述偵聽(tīng)點(diǎn)(24)，而不用把任何網(wǎng)絡(luò)地址轉(zhuǎn)換 (NAT)規(guī)則應(yīng)用到離開(kāi)信號(hào)，由此不用修改離開(kāi)信號(hào)所涉及到的多播 組； 由偵聽(tīng)點(diǎn)(24)把離開(kāi)信號(hào)引導(dǎo)到監(jiān)管復(fù)制點(diǎn)(13)的活動(dòng)的復(fù)制管 理器(17)，所述復(fù)制點(diǎn)(13)負(fù)責(zé)輸入數(shù)據(jù)分組的物理復(fù)制，并在所述主 機(jī)(15)連接到的端口上分發(fā)它們。
17. 如權(quán)利要求16所述的方法，還包括以下步驟 .通知控制點(diǎn)(28)把離開(kāi)信號(hào)傳送到所述復(fù)制管理器(17)。
18. 如權(quán)利要求1所述的方法，其中偵聽(tīng)點(diǎn)(24)接收來(lái)自主機(jī)(15) 的用戶加入請(qǐng)求，并把這些請(qǐng)求以通知消息的形式轉(zhuǎn)發(fā)到控制點(diǎn)(28), 控制點(diǎn)(28)決定哪些加入請(qǐng)求是可允許的，因此管理對(duì)于從主機(jī)(15) 請(qǐng)求的服務(wù)的獲得的授權(quán)；所述方法還包括以下步驟，通過(guò)客戶端生成離開(kāi)信號(hào)來(lái)作出離開(kāi)請(qǐng)求(L1);-所述客戶端請(qǐng)求原先地址的內(nèi)容，但消費(fèi)替換內(nèi)容；.通過(guò)NAT規(guī)則轉(zhuǎn)換離開(kāi)請(qǐng)求(L2)，并用用戶實(shí)際上消費(fèi)的替換 內(nèi)容的地址替換原先的地址； 由偵聽(tīng)點(diǎn)(24)把轉(zhuǎn)換后的離開(kāi)信號(hào)引導(dǎo)到監(jiān)管復(fù)制點(diǎn)(13)的活動(dòng) 的復(fù)制管理器(17)，所述復(fù)制點(diǎn)(13)負(fù)責(zé)輸入數(shù)據(jù)分組的物理復(fù)制，并 在所述主機(jī)(15)連接到的端口上分發(fā)它們。
19. 如權(quán)利要求18所述的方法，還包括以下步驟 .由所述控制點(diǎn)(28)發(fā)送去除NAT規(guī)則的命令(L5)。
20. 如權(quán)利要求1所述的方法，其中偵聽(tīng)點(diǎn)(24)接收來(lái)自主機(jī)(15) 的用戶加入請(qǐng)求，并把這些請(qǐng)求以通知消息的形式轉(zhuǎn)發(fā)到控制點(diǎn)(28)， 控制點(diǎn)(28)決定哪些加入請(qǐng)求是可允許的，因此管理對(duì)于從主機(jī)(15) 請(qǐng)求的服務(wù)的獲得的授權(quán)；所述方法還包括以下步驟 .通過(guò)發(fā)送詢問(wèn)消息Q到主機(jī)(15)而詢問(wèn)主才幾(15);-接收來(lái)自被詢問(wèn)的主機(jī)(15)的回答成員報(bào)告消息R;-把報(bào)告消息轉(zhuǎn)發(fā)到復(fù)制管理器(17)，以使得繼續(xù)進(jìn)行到主機(jī)的內(nèi) 容傳遞；所述復(fù)制管理器(17)監(jiān)管復(fù)制點(diǎn)(13)的活動(dòng)，所述復(fù)制點(diǎn)(13) 負(fù)責(zé)輸入數(shù)據(jù)分組的物理復(fù)制，并在所述主機(jī)(15)連接到的端口上分 發(fā)它們。
21. 如權(quán)利要求1所述的方法，其中偵聽(tīng)點(diǎn)(24)接收來(lái)自主機(jī)(15) 的用戶加入請(qǐng)求，并把這些請(qǐng)求以通知消息的形式轉(zhuǎn)發(fā)到控制點(diǎn)(28)， 控制點(diǎn)(28)決定哪些加入請(qǐng)求是可允許的，因此管理對(duì)于從主機(jī)(15) 請(qǐng)求的服務(wù)的獲得的授權(quán)；所述方法還包括以下步驟.通過(guò)發(fā)送詢問(wèn)消息Q到主機(jī)(15)而詢問(wèn)主機(jī)(15);.在設(shè)置的時(shí)限內(nèi)等待來(lái)自被詢問(wèn)的主機(jī)(15)的回答成員報(bào)告消息R;.在所述時(shí)限內(nèi)沒(méi)有接收到回答的情形下，該方法包括通知(L4) 控制點(diǎn)28停止由主機(jī)(15)進(jìn)行內(nèi)容獲得的步驟。
22. 如權(quán)利要求l所述的方法，其中所述檢驗(yàn)步驟包括以下步驟的一個(gè)或多個(gè).根據(jù)主機(jī)的憑證控制主機(jī)(15)的內(nèi)容訪問(wèn)授權(quán)； .當(dāng)由主機(jī)(15)作出傳遞內(nèi)容的請(qǐng)求時(shí)，控制網(wǎng)絡(luò)資源可用性；以及.當(dāng)在內(nèi)容獲得期間由主機(jī)(15)作出傳遞內(nèi)容的請(qǐng)求時(shí)，控制剩余的信用。
23. 如權(quán)利要求l所述的方法，其中所述加入請(qǐng)求包括IGMP請(qǐng)求。
24. —種用于在通信網(wǎng)中管理多播傳遞內(nèi)容的系統(tǒng)，其中包括由 復(fù)制管理器(17)監(jiān)管的復(fù)制點(diǎn)(13)的路由器(10)與形成多播組的多個(gè)主 機(jī)(15)通信，其特征在于，包括.控制點(diǎn)(28)，檢驗(yàn)來(lái)自至少一個(gè)主機(jī)的、將是多播組的一部分的 加入請(qǐng)求，以便針對(duì)所請(qǐng)求的組，確定與該主機(jī)相關(guān)的傳遞策略；以 及.所述控制點(diǎn)(28)指令所述復(fù)制管理器(17)按照它的傳遞策略把主 機(jī)與多播組相關(guān)聯(lián)。
25. 如權(quán)利要求24所述的系統(tǒng)，其中偵聽(tīng)點(diǎn)(24)被提供來(lái)接收用 戶加入請(qǐng)求(IGMP報(bào)告、IGMP離開(kāi)等等)，并把到來(lái)的加入請(qǐng)求以通 知消息的形式轉(zhuǎn)發(fā)到所述控制點(diǎn)(28)。
26. 如權(quán)利要求24所迷的系統(tǒng)，其中提供了被安排在每個(gè)主機(jī) (15)與所述復(fù)制點(diǎn)(13)之間的中間代理(18);中間代理(18)添加線路識(shí) 別符以便以明確的方式和與所提供的憑證無(wú)關(guān)地標(biāo)識(shí)主機(jī)(15),以及 執(zhí)行網(wǎng)絡(luò)地址轉(zhuǎn)換功能。
27. 如權(quán)利要求24所述的系統(tǒng)，其中所述控制點(diǎn)(28)與包括以下 的至少一項(xiàng)的多個(gè)服務(wù)器通信.AAA服務(wù)器(40),用于涉及鑒權(quán)、授權(quán)和基本記帳的事務(wù)； .QoS服務(wù)器(42)，用于管理QoS事項(xiàng)； .服務(wù)器(42m),用于實(shí)現(xiàn)內(nèi)容管理器；以及 -服務(wù)器(43)，用于管理基于預(yù)先付費(fèi)的計(jì)費(fèi)。
全文摘要
用于在通信網(wǎng)中管理數(shù)據(jù)分組的多播傳遞的方法，包括以下步驟檢驗(yàn)將是多播組的一部分的、來(lái)自主機(jī)(15)的加入請(qǐng)求，以便針對(duì)所請(qǐng)求的組確定與該主機(jī)相關(guān)的傳遞策略，以及按照它們的傳遞策略把主機(jī)與多播組相關(guān)聯(lián)。
文檔編號(hào)H04L12/18GK101371494SQ200580052545
公開(kāi)日2009年2月18日 申請(qǐng)日期2005年12月28日 優(yōu)先權(quán)日2005年12月28日
發(fā)明者A·加羅法洛, A·帕里尼羅, E·馬菲歐尼, G·吉尼拉, M·尤里歐 申請(qǐng)人:意大利電信股份公司