電氣工程及自動(dòng)化畢業(yè)設(shè)計(jì)（論文）外文翻譯-基于衛(wèi)星網(wǎng)絡(luò)的多路傳送協(xié)議

1、<p><b>　　中文3622字</b></p><p><b>　　附件D：</b></p><p><b>　　外文譯文</b></p><p>　　指導(dǎo)教師評(píng)語(yǔ)： </p><

2、;p>　　指導(dǎo)教師評(píng)定成績(jī) 簽字： </p><p>　　交叉評(píng)閱教師評(píng)語(yǔ)： </p><p>　　交叉評(píng)閱教師評(píng)定成績(jī) 簽字： </p><p>　　學(xué)生姓名： 完成日期

3、 2006 年 3月 10 日 </p><p><b>　　教 務(wù) 處</b></p><p><b>　　譯文： </b></p><p>　　基于衛(wèi)星網(wǎng)絡(luò)的多路傳送協(xié)議</p><p>　　在多種帶寬應(yīng)用里，需要將信息分配給大量潛在的接受站，這些接受站彼此是相互隔離的。因?yàn)閺V播衛(wèi)星

4、信道的傳輸能力極強(qiáng)，所以通信衛(wèi)星技術(shù)很適合傳播這種服務(wù)，是一種很好的選擇。盡管衛(wèi)星多路有著巨大的潛能，但是在衛(wèi)星網(wǎng)絡(luò)上很少存在對(duì)多路傳送服務(wù)支持的協(xié)議。雖然幾份多路傳送協(xié)議已經(jīng)供因特網(wǎng)的使用，但是他們對(duì)于衛(wèi)星網(wǎng)絡(luò)不是很好的選擇。在衛(wèi)星網(wǎng)絡(luò)涉及通訊時(shí)，傳輸協(xié)議的一關(guān)鍵部分受到了影響，這一部分是運(yùn)輸層。在這篇文章中，我們?cè)噲D提供針對(duì)空間和路徑的設(shè)計(jì)方法，在這種空間和路徑里，網(wǎng)絡(luò)部署和應(yīng)用的要求影響著布置在衛(wèi)星環(huán)境空間里的傳輸層。 我們也重視

5、在下一代衛(wèi)星多路傳送服務(wù)的發(fā)展過(guò)程中一些相互矛盾的問(wèn)題。</p><p><b>　　1 引言</b></p><p>　　在多種帶寬應(yīng)用里，比如軟件不斷改進(jìn)，分配計(jì)算，以及多媒體容量分配，需要一個(gè)將信息分配給許多潛在的接收者場(chǎng)所，這些接收者場(chǎng)所相互隔離得很遠(yuǎn)。通信衛(wèi)星就是自然的選擇，因?yàn)槠涔逃械牡男l(wèi)星帶寬能力。此外，在許多情況下，衛(wèi)星的基礎(chǔ)設(shè)施能被建立成提供一種更

6、廣泛的服務(wù)和方便的基礎(chǔ)設(shè)施，而基于陸地寬帶連接的基礎(chǔ)設(shè)施達(dá)不到這種要求。因此，雖然，今天許多寬帶傳輸是通過(guò)陸上設(shè)備連接，但是衛(wèi)星將起一個(gè)更大和更重要的角色，特別是點(diǎn)對(duì)多傳輸?shù)姆?wù)。</p><p>　　利用更高的頻率帶寬例如賈頻率（Ka-band）、點(diǎn)-線技術(shù)和板上的加工工藝的下一代衛(wèi)星通信系統(tǒng)正在研究中。賈頻帶(Ka-band)對(duì)于衛(wèi)星通信系統(tǒng)非常重要，因?yàn)樗峁└鼘挼膸?。用點(diǎn)-光線和板上的加工技術(shù)的使用能提

7、供雙向直接通訊的小而低功率低成本的用戶終端。這些系統(tǒng)很可能在全球通訊基礎(chǔ)設(shè)施中起重要作用。</p><p>　　盡管衛(wèi)星多路傳播潛力巨大，但在衛(wèi)星網(wǎng)絡(luò)上很少存在對(duì)多路傳送服務(wù)的支持的協(xié)議。雖然幾份多路傳送協(xié)議已經(jīng)供因特網(wǎng)使用，但是他們對(duì)于衛(wèi)星網(wǎng)絡(luò)不是很好的選擇。因此，為使下一代衛(wèi)星系統(tǒng)和多路傳送服務(wù)的有效率的集成就需對(duì)這幾份協(xié)議進(jìn)行研究和應(yīng)用。 在衛(wèi)星網(wǎng)絡(luò)涉及通訊時(shí)，傳輸協(xié)議的傳輸層受到了影響。</p>

8、;<p>　　2 我們考慮應(yīng)用于包括了衛(wèi)星寬帶的多路傳送服務(wù)的兩種最普通的拓?fù)浣Y(jié)構(gòu)</p><p>　?。?）衛(wèi)星網(wǎng)絡(luò)可以被作為地理上分配的高速局域網(wǎng)(LAN)的相互聯(lián)系的一塊橋梁部署。 在這腳本里，局域網(wǎng)通過(guò)一個(gè)或更多衛(wèi)星上線路連接衛(wèi)星（圖1（a））。這網(wǎng)絡(luò)拓?fù)洚a(chǎn)生了一個(gè)對(duì)等結(jié)構(gòu)： 衛(wèi)星和信道節(jié)點(diǎn)作為局域網(wǎng)的一個(gè)覆蓋網(wǎng)絡(luò)。 通常，局域網(wǎng)也能連接一個(gè)陸地的核心網(wǎng)絡(luò)。 這種網(wǎng)絡(luò)體系結(jié)構(gòu)為數(shù)據(jù)的多路傳

9、送分配提供獨(dú)特的機(jī)會(huì)。在這個(gè)腳本里，當(dāng)端口連接用于在帶外控制信息，及用戶反饋和數(shù)據(jù)重傳時(shí)。 這種連接或許能被用來(lái)有效地傳輸內(nèi)容給很多的站點(diǎn)。</p><p>　　圖1 衛(wèi)星網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu) (a)主干部署。 (b)直接家庭部署</p><p>　?。?）直接家庭(或者直接商業(yè))部署，在這種部署里，衛(wèi)星網(wǎng)絡(luò)由直接的或者雙方向的獨(dú)立的連接端子組成。在這種腳本里面。網(wǎng)絡(luò)有一種很全面的拓?fù)浣Y(jié)構(gòu)，用戶終

10、端與其他網(wǎng)絡(luò)沒(méi)有直接的聯(lián)系。地面終端通過(guò)位于所謂網(wǎng)絡(luò)操作中心(NOC)的一個(gè)通道節(jié)點(diǎn)訪問(wèn)核心網(wǎng)絡(luò)(圖（1）b)。這種傳送協(xié)議增加了傳輸信道 ,特別是當(dāng)數(shù)據(jù)要求可靠的交互時(shí)，因?yàn)橐粋€(gè)衛(wèi)星要求返回信道和用戶反饋的傳送帶外控制信息和數(shù)據(jù)重傳必須穿過(guò)這條衛(wèi)星信道。</p><p><b>　　3 丟失檢查和反饋</b></p><p>　　為了提供可靠性，一份協(xié)議需要鑒定不能

11、到達(dá)規(guī)定的目的地的包。 通過(guò)接收者返回丟失包通知給發(fā)送者。 傳統(tǒng)上，這個(gè)反饋有下列形式之一：</p><p>　　肯定應(yīng)答(ACK)： 接收者把包返回給發(fā)送者，表明包已經(jīng)被收到。 </p><p>　　否認(rèn)應(yīng)答(NACK)：接收者把包返回給發(fā)送者,表明包丟失,需要重傳。 </p><p>　　混合應(yīng)答(both ACK and NACK)；對(duì)多路傳送協(xié)議來(lái)說(shuō)，肯定回

12、答如果確認(rèn)消息丟,就會(huì)確認(rèn)內(nèi)部是不是有破裂問(wèn)題。當(dāng)許多接收者返回確認(rèn)包說(shuō)他們收到正確的包時(shí)候，問(wèn)題就會(huì)出現(xiàn).因?yàn)槊恳粋€(gè)它們收到的包都會(huì)引起了資源連接的網(wǎng)絡(luò)擁塞。另一個(gè)潛在的問(wèn)題就是發(fā)送者必須保持與接收者連接的狀態(tài)，那樣才能確定數(shù)據(jù)包是否被接受者全部正確地接受了。在大規(guī)模多路傳送應(yīng)用方面，存儲(chǔ)器和處理負(fù)荷變得很高。</p><p>　　NACK的反饋減少了一些問(wèn)題。在電纜陸地的網(wǎng)絡(luò)中，性能比較明顯。NACK-bas

13、ed確認(rèn)多路傳送協(xié)議比ACK-based確認(rèn)性能好。 在NACK-based的反饋里，接收者通過(guò)檢查按照包順序號(hào)的缺少來(lái)識(shí)別丟失的包，并且向被指定的發(fā)送者報(bào)告。發(fā)送者即不需要及時(shí)知道接收者在任一點(diǎn)的大小，也不需要在它的組中保持與每一個(gè)接收者的當(dāng)前連接狀態(tài)。 此外，NACK包的數(shù)量預(yù)計(jì)在在出錯(cuò)率上少于ACK。當(dāng)它自由傳送到緩沖區(qū)時(shí)，缺點(diǎn)就會(huì)產(chǎn)生，這個(gè)缺點(diǎn)是傳送者很難知道其包是否到達(dá)到了接受者了， 因?yàn)镹ACK包可能在輸送過(guò)程中丟失。對(duì)衛(wèi)星

14、多路傳送應(yīng)用來(lái)說(shuō)，與丟失檢查和用戶反饋有關(guān)的潛在的問(wèn)題是更加嚴(yán)重。由于在衛(wèi)星鏈路和潛在許多的接收者的高的出錯(cuò)率，即使基于NACK的反饋導(dǎo)致的不僅僅是一個(gè)內(nèi)破裂問(wèn)題， 而且傳輸?shù)难舆t會(huì)導(dǎo)致數(shù)據(jù)的重傳輸沒(méi)有可能了。 在主干部署里,陸地鏈路的存在允許支持,主要用于電纜陸地網(wǎng)絡(luò)發(fā)展的反饋集中的用法以及反饋抑制。但是，在直接家庭部署過(guò)程中，由于我們算法的應(yīng)用有限,將在第3.3節(jié)更進(jìn)一步精心講敘。</p><p><b

15、>　　3.1減少損失</b></p><p>　　包恢復(fù)機(jī)制是一個(gè)可靠的傳送協(xié)議的必要的組成部分。 </p><p>　　自動(dòng)重發(fā)請(qǐng)求(ARQ)是對(duì)于這目的的一種著名的技術(shù)。 在ARQ內(nèi)，發(fā)送者對(duì)丟失通知反應(yīng)是通過(guò)重傳丟失包來(lái)表現(xiàn)的。在衛(wèi)星多路傳送應(yīng)用中，對(duì)數(shù)據(jù)包的恢復(fù)來(lái)說(shuō)，由于幾個(gè)原因純ARQ結(jié)果是無(wú)效的。傳播長(zhǎng)延遲與衛(wèi)星鏈路有關(guān),在重請(qǐng)求期間導(dǎo)致很多延遲，使得敏感應(yīng)用

16、(例如錄像機(jī)流)的處理不能執(zhí)行。如果頻繁和進(jìn)一步消失在衛(wèi)星鏈路，就會(huì)導(dǎo)致高出錯(cuò)率和高突發(fā)錯(cuò)誤。所以，隨著衛(wèi)星傳輸?shù)膹V泛應(yīng)用，即使反饋機(jī)制能夠把丟失的信息傳回信號(hào)源，網(wǎng)絡(luò)的帶寬和進(jìn)程需要的時(shí)間，會(huì)被不同的接受端接受不同的丟失數(shù)據(jù)包而浪費(fèi)掉。幾份早期的論文把ARQ方法用在衛(wèi)星多路傳輸協(xié)議中。</p><p>　　3.2反饋禁止和集中</p><p>　　幾個(gè)現(xiàn)有的多路傳輸協(xié)議采取了反饋禁止和集

17、中來(lái)控制為反饋包的數(shù)量和反饋包的流，其目的是避免反饋破裂的問(wèn)題。衛(wèi)星多路傳送采用內(nèi)的這些方法的應(yīng)用性嚴(yán)重依賴網(wǎng)絡(luò)部署的結(jié)構(gòu)</p><p>　　數(shù)據(jù)通信協(xié)議反饋集中適用于一個(gè)合乎邏輯或者物理階層網(wǎng)絡(luò)。反饋集中依賴對(duì)源的中間實(shí)體收集，濾出和合并反饋信息。在主干腳本里面，對(duì)于中間局域網(wǎng)路由器來(lái)說(shuō)，收到來(lái)自接收者節(jié)點(diǎn)的反饋包而只把集中反饋信息報(bào)告給衛(wèi)星網(wǎng)關(guān)是可能的。網(wǎng)關(guān)節(jié)點(diǎn)能收到源的通過(guò)幾個(gè)路由器的單個(gè)反饋信息報(bào)告。

18、</p><p><b>　　3.3 包恢復(fù)</b></p><p>　　在面向無(wú)連接通訊里，反饋報(bào)告包返回發(fā)送人，發(fā)送人提出重傳。 為避免反饋內(nèi)破裂, 通信量集中在發(fā)送者, 并且降低包恢復(fù)潛在因素。幾份多路傳送協(xié)議采用本地恢復(fù)法。本地恢復(fù)允許指定節(jié)點(diǎn)緩存數(shù)據(jù)包, 代替發(fā)送者重傳。 因此，接收者首先通過(guò)這些結(jié)點(diǎn)來(lái)恢復(fù)丟失包。如果丟失包不能通過(guò)指定結(jié)點(diǎn)恢復(fù)，那么就會(huì)向發(fā)

19、送者請(qǐng)求重傳。用一個(gè)合乎邏輯或者物理層次的網(wǎng)絡(luò)是可能的, 通過(guò)它們中間路由器能緩存包，收到請(qǐng)求之后向上重傳。反饋集中路由器輔助了本地恢復(fù)提高了靈活性和多路協(xié)議的可靠性.</p><p>　　由于與衛(wèi)星鏈路相伴的長(zhǎng)時(shí)間的傳播延遲，包的本地恢復(fù)在衛(wèi)星網(wǎng)絡(luò)里特別重要。在主干部署里，衛(wèi)星網(wǎng)關(guān)和中間路由器是一個(gè)適合本地恢復(fù)的好場(chǎng)所。不過(guò)，伴隨反饋集中，路由器輔助本地恢復(fù)要求中間網(wǎng)絡(luò)部件的支持和它的可用性取決于路由器擴(kuò)展性的

20、存在。如果接收結(jié)點(diǎn)允許響應(yīng)重傳請(qǐng)求, 大體上路由器輔助本地恢復(fù)的可能，如果接受點(diǎn)被允許重發(fā)請(qǐng)求。在這種情況下，有效的反饋和包修復(fù)必須避免網(wǎng)絡(luò)的溢流問(wèn)題。在直接家庭部署中，所有接收者直接收到來(lái)自衛(wèi)星的包，在衛(wèi)星與接收者之間沒(méi)有中間路由器。因此，對(duì)于在這樣的網(wǎng)絡(luò)中本地恢復(fù)是比較困難的。</p><p><b>　　3.4數(shù)據(jù)通訊協(xié)議</b></p><p>　　在為研究陸

21、地衛(wèi)星網(wǎng)絡(luò)時(shí)，需要在研究中作出巨大的努力來(lái)提供一個(gè)無(wú)所不在的端到端的擁塞控制算法。這要修改TCP協(xié)議使之與衛(wèi)星信道相配。另一個(gè)提議是在衛(wèi)星網(wǎng)絡(luò)接口處設(shè)置一個(gè)連接，并且運(yùn)行在末端結(jié)點(diǎn)與衛(wèi)星網(wǎng)關(guān)之間的TCP協(xié)議。當(dāng)在衛(wèi)星核心網(wǎng)絡(luò)運(yùn)行算法時(shí)，第二種方法在實(shí)際中有幾個(gè)優(yōu)點(diǎn)。它允許衛(wèi)星核心網(wǎng)絡(luò)提供最佳數(shù)據(jù)流而達(dá)到高效用。并且在一部分陸地網(wǎng)絡(luò)中，它也可能推開(kāi)擁塞到網(wǎng)絡(luò)邊緣，讓TCP擁塞控制機(jī)制處理?yè)砣?。在中心網(wǎng)絡(luò)中，問(wèn)題是減少流控制問(wèn)題而不是擁塞控

22、制問(wèn)題，因?yàn)樾l(wèi)星網(wǎng)絡(luò)帶寬是確定的確定和被許多有源連接共享了。然而衛(wèi)星網(wǎng)層與因特網(wǎng)隔離，流控制通過(guò)擁塞窗口執(zhí)行，也沒(méi)有必要去區(qū)分丟失是因?yàn)閾砣€是連接錯(cuò)誤。</p><p>　　為了使因特網(wǎng)與衛(wèi)星網(wǎng)絡(luò)隔離，要求在網(wǎng)關(guān)結(jié)點(diǎn)有額外的功能，然而，我們也相信衛(wèi)星提供者也愿意這樣的設(shè)計(jì)。因?yàn)樵谒麄兊木W(wǎng)絡(luò)中允許他們有完全的流控制。加上多播服務(wù)TCP控制的信道性能和算法，使得衛(wèi)星網(wǎng)絡(luò)有不可忽略的優(yōu)點(diǎn)。</p>&l

23、t;p><b>　　4 結(jié)論</b></p><p>　　在本章中，為支持多路服務(wù)，我提出了一個(gè)分類法和許多可選的設(shè)計(jì)概要。討論了怎么樣設(shè)計(jì)多路傳輸協(xié)議在衛(wèi)星網(wǎng)絡(luò)中的布置。我們的分類法是以多播傳輸協(xié)議IETF建筑塊為基礎(chǔ)。但是衛(wèi)星傳輸協(xié)議的組件腳本被兩個(gè)最一般的網(wǎng)絡(luò)部署影響。</p><p>　　我們也概括地論述了一些問(wèn)題，這些問(wèn)題在下一代衛(wèi)星多播服務(wù)網(wǎng)絡(luò)中是受

24、到批評(píng)的。像一些問(wèn)題如反饋內(nèi)破裂空缺和在傳輸層的包層的FEC碼在陸地網(wǎng)絡(luò)中已改變，但是考慮衛(wèi)星網(wǎng)絡(luò)的唯一特性時(shí)，它們不得不被引用。我們相信有效解決問(wèn)題方法和新技術(shù)的發(fā)展（例如額外處理與緩存）將在全球通信的基礎(chǔ)設(shè)施中表明衛(wèi)星網(wǎng)絡(luò)的真正價(jià)值。</p><p>　　譯文原文出處：Elahi, Ata. 《NETWORK COMMUNICATION TECHNOLOPY》 科學(xué)出版社 2002年 </p>

25、<p>　　Transport protocols in multicast via satellite</p><p>　　In a wide variety of broadband applications, there is a need to distribute information to a potentially large number of receiver sites that

26、 are widely dispersed from each other. Communication satellites are a natural technology option and are extremely well suited for carrying such services because of the inherent broadcast capability of the satellite chann

27、el. Despite the potential of satellite multicast, there exists little support for multicast services over satellite networks. Although severa</p><p>　　1. Introduction</p><p>　　In a wide variety

28、of broadband applications, such as software updates, distributed computing, and multimedia content distribution, there is a need to distribute information to a potentially large number of receiver sites that are widely d

29、ispersed from each other. Communication satellites are a natural option for this because of the inherent broadcast capability of the satellite channel. Also, a satellite-based infrastructure can, in many cases, be establ

30、ished to offer widespread service provisio</p><p>　　Next-generation satellite communication systems utilizing higher frequency bands such as the Ka-band, spot-beam technology and on-board processing are curr

31、ently under development。Ka-band is very desirable for satellite communication systems, because it offers abundant bandwidth. The use of spot-beam and on-board processing technologies enable the use of small, low-power, l

32、ow-cost user terminals that offer two-way direct communication. These systems are likely to play an important role in the glo</p><p>　　Despite the potential of satellite multicast, there exists little suppor

33、t for multicast services over satellite networks. Although several multicast protocols have been proposed for use over the Internet, they are not optimized for satellite networks. Therefore, efficient integration of next

34、 generation satellite systems and multicast services requires the study and adaptation of these protocols. One of the key multicast components that is affected when satellite networks are involved in the comm</p>

35、<p>　　2．We consider two of the most common topologies for multicast service support involving broadband satellites</p><p>　　(i) Satellite networks can be deployed as a backbone for interconnection of ge

36、ographically distributed high-speed local area networks (LAN). In this scenario, LAN are connected to the satellite backbone through one or more gateway nodes that have satellite uplink capability (Figure 1(a)). This net

37、work topology gives rise to a hierarchical structure: satellite and gateway nodes acting as an overlay network for the LAN(s). In general, LAN(s) may also have access to a terrestrial core network. This</p><p&

38、gt;　　Figure 1. Satellite network topologies. </p><p>　　(a) Case I: backbone deployment. (b) Case II: direct-to-home deployment.</p><p>　　(ii) A direct-to-home (or direct-to-business) deployment,

39、 where the network consists of independent ground terminals with direct unit- or bi-directional connection to the satellite. In this scenario, network has a star topology and user terminals have no direct access to other

40、 networks. Ground terminals access the terrestrial core network through a gateway node located at the so-called network operations center (NOC) (Figure 1(b)). This architecture imposes additional challenges on the transp

41、ort</p><p>　　3. Loss detection and feedback</p><p>　　To provide reliability, a protocol needs to identify the packets that failed to reach a given destination. This is achieved through loss-noti

42、fication (feedback) packets returned to the designated source by the receivers. Traditionally, this feedback has been in one of the following forms:</p><p>　　* Positive acknowledgments (ACK): Receivers retu

43、rn ACK packets to the designated source, indicating which packets have been received.</p><p>　　* Negative acknowledgments (NACK): Receivers return NACK packets to the designated source, indicating only packe

44、ts that are missing by a receiver.</p><p>　　* A hybrid approach (both ACK(s) and NACK(s)).</p><p>　　For multicast transport protocols, ACK-based loss-notification has been shown to lead to the A

45、CK implosion problem. The problem arises when a large number of multicast receivers return an ACK packet for every packet they receive correctly, causing a serious network congestion around the links of the source. Anoth

46、er potential problem is that the source is required to keep track of the size, and the current state of the reporting receiver-set, in order to identify the last data packet correctly re</p><p>　　NACK-based

47、feedback alleviates some of the problems. The performance comparison study presented in Reference confirms that NACK-based multicast transport protocols deliver better performance than their ACK-based counterparts in wir

48、e line terrestrial networks. In NACK-based feedback, receivers detect missing packets by checking for gaps in the packet sequence numbers and report to the designated source. The source neither needs to know the size of

49、the receiver-set at any point in time, nor keeps </p><p>　　3.1 Loss reduction</p><p>　　A packet recovery mechanism is an essential component of a reliable transport protocol.</p><p>

50、;　　Automatic repeat request (ARQ) is a well-known technique for this purpose. In ARQ, sources respond to loss notification reports by retransmitting the missing packets. In a satellite multicast application, pure-ARQ for

51、 packet recovery turns out to be inefficient for several reasons. Long propagation delays associated with satellite links make the delay incurred during this repeat request process unacceptable for many delay sensitive a

52、pplications (e.g. video streaming). The frequent and deep fades</p><p>　　3.2 Feedback suppression and aggregation</p><p>　　Several existing multicast protocols adopt feedback suppression and fee

53、dback aggregation schemes to control the number and flow of feedback packets to avoid feedback implosion problem. Applicability of these methods in a satellite multicast application depends heavily on the architecture

54、of the deployed network.</p><p>　　Feedback aggregation is applicable in networks where a logical or physical hierarchy is possible. Feedback aggregation relies on intermediate entities to collect, filter-out

55、 and combine feedback information towards the source. In a backbone scenario, it is possible for intermediate LAN routers to aggregate feedback packets from receiver nodes and to report only the aggregated feedback infor

56、mation to the satellite gateways. Gateway nodes can further aggregate reports from several routers to pass </p><p>　　3.3 Packet recovery</p><p>　　In uncials communication, feedback reports are r

57、eturned to sender and retransmissions are initiated by the sender. In order to avoid feedback implosion and traffic concentration at the sender and to reduce the packet recovery latency, several multicast protocols adopt

58、 local recovery methods. Local recovery allows designated nodes to buffer data packets, and initiate retransmissions on behalf of the sender. Therefore, receivers first try to recover missing packets through these nodes.

59、 If the miss</p><p>　　Local recoveries of packets are particularly important in satellite networks because of the long propagation delays associated with satellite links. In a backbone deployment, satellite

60、gateways are in a very good position to assist in the local recovery together with other intermediate routers. However, as it is the case with feedback aggregation, router-assisted local recovery requires support from in

61、termediate network elements and its availability depends on existence of router extensions. A g</p><p>　　4. Protocol of data communications</p><p>　　There is an effort in the research community

62、to provide a ubiquitous end-to-end congestion control algorithm for hybrid satellite-terrestrial networks. This requires careful modification of the TCP protocol to match the characteristics of the satellite channels. An

63、other approach is to split a connection at the terrestrial-satellite network interface, and to run TCP between the end nodes and the satellite network gateways, while running a customized algorithm in the satellite-only

64、core network. T</p><p>　　Isolating the satellite network from the rest of the Internet would require additional functionality at the gateway nodes. However, we believe that satellite providers would be willi

65、ng to go with this design, since the implementation will allow them to have full control of the traffic flow in their networks. Adding to this the challenges of having a TCP-like behavior for multicast services, we belie

66、ve that, having a customized algorithm for the satellite network has considerable advantages.</p><p>　　5. Conclusion</p><p>　　In this chapter, we have presented a taxonomy and survey of various

67、design alternatives for supporting multicast services, and discussed how the design space of various multicast transport protocol components are constrained in the context of satellite networks. Our classification is bas

68、ed on the IETF building blocks for multicast transport protocols, but highlights which components of a general transport protocol are affected by the two most common satellite network deployment scenarios. </p>&l

69、t;p>　　We also outlined some of the issues that are critical in the development of next generation satellite multicast services. Some of these problems, such as feedback implosion avoidance and packet level FEC coding

70、at the transport layer, have counterparts in terrestrial networks, but they have to be addressed separately while taking into consideration the unique characteristics of satellite networks. We believe that efficient solu