[發(fā)明專利]在IP隧道路徑上執(zhí)行隧道信令的方法和裝置

無效

• 申請?zhí)枺?/td>: 201210536386.9
• 申請日: 2006-10-11
• 公開（公告）號: CN103220202A
• 公開（公告）日: 2013-07-24
• 發(fā)明（設(shè)計(jì)）人: S-H·李;J-H·方;C·齊沈;H·舒勒澤瑞恩
• 申請（專利權(quán)）人: 三星電子株式會社;紐約市哥倫比亞大學(xué)托管會
• 主分類號: H04L12/46
• 分類號: H04L12/46;H04L12/70;H04L29/06
• 代理公司: 上海專利商標(biāo)事務(wù)所有限公司 31100
• 代理人: 潘明婳

本發(fā)明是申請日為2008年5月26日申請?zhí)枮?00680044113.5、發(fā)明名稱為“在IP隧道路徑上執(zhí)行隧道信令的方法和裝置”的中國專利申請的分案申請。

技術(shù)領(lǐng)域

本發(fā)明涉及在IP隧道路徑上執(zhí)行隧道信令的裝置和方法。尤其是，本發(fā)明涉及通過在IP隧道路徑上生成并發(fā)送對應(yīng)于端對端信令流的隧道信令流來執(zhí)行隧道信令的裝置和方法。

背景技術(shù)

隨著因特網(wǎng)技術(shù)正變得越來越普遍，下一代通信網(wǎng)絡(luò)正被發(fā)展成具有集成了基于網(wǎng)間協(xié)議（IP）的核心網(wǎng)與各種接入網(wǎng)的結(jié)構(gòu)的“全I(xiàn)P”網(wǎng)絡(luò)。在“全I(xiàn)P”網(wǎng)絡(luò)中，諸如公共交換電話網(wǎng)（PSTN）等有線網(wǎng)絡(luò)和支持例如國際移動電信-2000（IMT-2000）的無線網(wǎng)絡(luò)被鏈接至基于IP的核心網(wǎng)以便作為一個(gè)集成的IP網(wǎng)絡(luò)來運(yùn)作。

不同類型的網(wǎng)絡(luò)的集成經(jīng)常發(fā)生在支持用于支持移動性和服務(wù)質(zhì)量（QoS）的IP版本6（IPv6）地址系統(tǒng)的網(wǎng)絡(luò)和常規(guī)的IP版本4（IPv4）網(wǎng)絡(luò)之間，以及發(fā)生在IP網(wǎng)絡(luò)和非IP網(wǎng)絡(luò)之間。因此，需要一種通過包括支持IPv4的網(wǎng)絡(luò)裝置和支持IPv6的網(wǎng)絡(luò)裝置的整個(gè)網(wǎng)絡(luò)提供集成的因特網(wǎng)服務(wù)的網(wǎng)絡(luò)鏈接技術(shù)。

IP隧道技術(shù)作為實(shí)現(xiàn)IP網(wǎng)絡(luò)和非IP網(wǎng)絡(luò)之間或不同類型的IP網(wǎng)絡(luò)之間的集成的一項(xiàng)技術(shù)已成為關(guān)注焦點(diǎn)。IP隧道是一種通過在網(wǎng)絡(luò)上的兩個(gè)節(jié)點(diǎn)之間的虛擬管道發(fā)送分組的封裝方法。兩個(gè)節(jié)點(diǎn)之間的分組發(fā)送路徑被叫做IP隧道路徑或IP隧道。在IP隧道路徑上發(fā)送的分組包括常規(guī)的數(shù)據(jù)分組以及包含用于執(zhí)行諸如QoS和資源保留等特定操作的信令消息的信令分組。

通常，通過根據(jù)形成IP隧道路徑的網(wǎng)絡(luò)類型按合適的形式將隧道IP頭添加到數(shù)據(jù)分組中，在IP隧道路徑上發(fā)送常規(guī)的數(shù)據(jù)分組。例如，當(dāng)IPv6數(shù)據(jù)分組在按IPv4協(xié)議運(yùn)作的IP隧道路徑上傳送時(shí)，包括IP隧道路徑的兩個(gè)端點(diǎn)的地址的IPv4頭被添加至IPv6數(shù)據(jù)分組中。

然而，所描述的方法具有不適合用來發(fā)送包括與維護(hù)和管理網(wǎng)絡(luò)相關(guān)聯(lián)的信令消息的信令分組的一個(gè)方面。具體地，根據(jù)所描述的方法，不可能通過將信令分組作為常規(guī)數(shù)據(jù)分組處理從而在IP隧道路徑上反映與信令消息相關(guān)聯(lián)的操作。例如，由于與信令操作（諸如保留網(wǎng)絡(luò)資源以執(zhí)行涉及IP隧道路徑的QoS和發(fā)送路由警示選項(xiàng)或某個(gè)協(xié)議號）相關(guān)聯(lián)的信息被隧道IP頭封裝，所以它沒有在IP隧道路徑上的節(jié)點(diǎn)上顯示。因此，所描述的信令操作可能無法在IP隧道路徑上執(zhí)行。

另外，在常規(guī)的QoS方法的情況下，當(dāng)根據(jù)對應(yīng)于數(shù)據(jù)分組的服務(wù)流類型對在IP隧道路徑上發(fā)送的數(shù)據(jù)分組進(jìn)行分類以便為每種類型執(zhí)行調(diào)度時(shí)，如果在IP隧道路徑上發(fā)送的IP分組被隧道IP頭封裝，則不能在IP隧道路徑上識別出服務(wù)流類型。因此，所描述的調(diào)度操作會沒有被合適地執(zhí)行。

另一方面，可添加用戶數(shù)據(jù)報(bào)協(xié)議（UDP）頭用來在隧道路徑上識別QoS數(shù)據(jù)分組。然而，由于UDP頭相對大，所以通過將UDP頭添加至所有通過IP隧道路徑的分組會使開銷明顯增加。尤其是，因?yàn)閷τ谥T如IP電話（VoIP）等發(fā)送小分組的服務(wù)來說由于UDP頭的添加會使開銷變得較大，所以這種類型的隧道方法是不合適的。

另一方面，已公開一種通過使用由因特網(wǎng)工程任務(wù)組（IETF）提出的用于安全發(fā)送和接收IP層中的分組的IP安全（IPSEC）協(xié)議的安全參數(shù)索引（SPI）字段來封裝分組以便在IP隧道路徑上識別被封裝的消息的方法。根據(jù)這種方法，在不會由于添加附加的頭帶來任何開銷的情況下而在IP隧道路徑上存在優(yōu)良信令是有可能的。然而，該方法只能應(yīng)用于支持IPSEC協(xié)議的IP隧道路徑。

由于常規(guī)的資源保留協(xié)議（RSVP）不支持之后將要描述的由發(fā)送方啟動的信令并且沒有考慮到移動性（例如，會話標(biāo)識符值隨移動節(jié)點(diǎn)的越區(qū)切換而變化），因此采用所述的將IP頭或UDP頭添加至IP分組的方法或采用IPSECSPI字段的常規(guī)資源保留協(xié)議（RSVP）不能夠有效地支持主機(jī)的移動性。

此外，上述的常規(guī)技術(shù)不提供用于同時(shí)支持單獨(dú)隧道信令流和多個(gè)集合的隧道信令流的數(shù)據(jù)對象，因此，當(dāng)IP網(wǎng)絡(luò)的接收方和發(fā)送方之間的隧道部分和集合部分以重疊的形式共存或從重疊的形式中分離出來時(shí)，在這兩個(gè)部分中執(zhí)行信令和數(shù)據(jù)發(fā)送有一個(gè)依賴不同數(shù)據(jù)對象的問題。結(jié)果，IP分組的開銷增加，以用于存儲關(guān)于上述關(guān)系的信息，由此導(dǎo)致信令和數(shù)據(jù)發(fā)送的延時(shí)。

因此，增加了對執(zhí)行隧道信令的方法的關(guān)注，其中該方法對IP隧道路徑上的單獨(dú)隧道信令和集合隧道信令提供有效的支持和統(tǒng)一的管理。

為了解決常規(guī)技術(shù)的問題，提供一種在IP隧道路徑上執(zhí)行隧道信令的新技術(shù)。

發(fā)明內(nèi)容