1． 簡介
1．1Internet體系結構
作為TCP/ip協議集之后的巨大計劃，Internet體系結構在70年代后期由
一個網絡研究小組[1、2、3、4]開發并測試。80年代初期，體系結構中加入了若
干重要的特性，如子網化、自治系統和域名系統[5、6]。最近又加入了IP組播[7]。
在本體系結構框架內，Internet工程任務組(IETF)一直以極大的活力和效率為In
ternet策劃、定義、推廣、測試和標準化協議進行不懈的工作。已完成的三個非凡重
要的領域是選路協議、TCP性能與網絡治理。同時，Internet基礎設施繼續以驚
人的速度增長。自1983年1月ARPANET第一次從NCP轉換成TCP/IP時，
Internet的銷售商、治理員、專家和研究人員一直以極大的努力堅強地工作，為他
們的成功而奮斗不息。
定義Internet體系結構的一組研究人員形成了Internet活動董事會(IAB)
的初始成員。IAB由1981年DARPA建立的一個技術顧問組發展成為Internet
總技術和策略監督實體。IAB的成員年年有變化，以便更好地體現Internet社區
中需求和議題的變化，及反映Internet的國際化，但仍然保持協議體系結構制定的
關系。
IAB創建了IETF，為Internet實施協議的開發和工程設計。為了治理不斷
發展的IETF活動，IETF主持在IETF內建立了Internet工程指導組(IES
G)。IAB和IESG密切配合，共同批準IETF內開發的協議標準。
過去幾年中，對基礎體系結構有著不斷增加的嚴重考驗的跡象，大部分由于Inte
rnet持續不斷的增長引起。對這些問題的討論經常反映在許多主要的發送文件清單
中。
1．2假設
對當前Internet體系結構中的問題，解決的優先次序取決于人們對TCP/IP與OS
I協議集未來關系的觀點。一種觀點是讓TCP/IP夭折在成功之中，然后轉換到OSI協
議。然而，許多在Internet協議產品和服務上花過大力氣并獲得成功的人們，急于要在
已有的框架內嘗試解決新的問題。而且，有些人相信OSI協議將會碰到許多同樣類型的問
題。
為了著手解決這些問題，IAB和IESG于1991年1月聯合組織了一天有關Inte
rnet體系結構議題的討論會。這次會議的框架是由DaveClark(見附錄A中的幻燈片)整理
的。關于TCP/IP與OSI協議的關系和未來方向問題上的討論生氣勃勃、富有挑戰，有
時還有激烈的爭論。會議的重要成果是在下一個5~10年涉及網絡世界的下述四個基本假
設上達成了共識。
(1)TCP/IP和OSI協議集將在一個長時期內共存。
OSI協議集引入的背后是強有力的政治和市場力量，以及以某些技術優勢作后盾。然
而，TCP/IP牢固確立的市場位置意味著在可預見的未來非常可能繼續使用。
(2)Internet將繼續包括各種各樣的網絡和服務，永遠不會是由一個單網絡技術構成的。
實際上接到Internet上的網絡技術和特性的范圍在下一個十年還將增加。
(3)商用和專用網也將加入，但不能期望公共通信提供全部服務。將會形成公用網和專
用網、公共通信與專用線路混用的局面。
(4)Internet體系結構要能達到109個網絡的規模。
Internet的規模歷史性地呈指數增長，在將來的某個時候估計可能會飽和，但猜測
到什么時候飽和，差不多和猜測未來的經濟一樣輕易。在任何情況下，負責工程設計的需要
考慮一個有能力擴展到最壞情況規模的體系結構。指數9是比較模糊的數字，估計在7~10
之間變化。
1．3開始一個規劃過程
IAB和IESG會議的另一個成果是在體系結構進化中的下列五個最重要的領域
上形成了共識。
(1)選路與尋址
這是一個最急需解決的體系結構的問題，因為它直接關系到Internet繼續成功增長
的能力。
(2)多協議體系結構
Internet正在朝著廣泛的既支持TCP/IP又支持OSI協議集的方向邁進。
對兩個協議集的支持帶來了技術難題，需要有一個計劃，也就是一個體系結構來增加成
功的機會。人們開玩笑地把這個領域看成是：“為了造福人類，問題變得更艱難”。
Clark觀察到轉發網關(如郵件網關)在Internet運行中是非常有生命力的，但
是它不屬于體系結構或規劃的一部分。該組成員討論了圍繞包含這樣的網關的部分網絡
連接來建立體系結構的可能性。
(3)安全性體系結構
在設計Internet體系結構時，雖然考慮到了軍事上的安全性，可是現代安全性
議題是非常廣泛的，它也包括了商業上的需求。還有，經驗表明除非一開始就把它建立
到體系結構中去，否則是很難在協議集內再加入安全性。
(4)數據流控制及狀態
Internet將擴展以支持如語音和視頻這樣的“實時”應用。這就需要網關中有
新的包排隊機制(數據流控制)和附加的網關狀態。
(5)現代應用
隨著基礎的Internet通信機制的成熟，需要不斷革新和標準化，以創建新形式
的應用。
IAB和IESG于1991年6月再次在SDSC召開三天的會議，討論這5個
課題。這次會議多少有點反常，被稱為“體系結構的再處理”，召集在一起開會，表明
有堅強的決心朝著規劃體系結構的進化邁出第一步。除了IAB和IESG以外，由32人
組成的小組，包括了研究指導組(IRSG)的成員及少量的特邀客人。會議的第二天，分
成5個組討論，每個組討論1個領域的問題。附錄B列出了成員名單。
本文件是從這些組的主席報告中收集得到的。該材料在亞特蘭大召開的IETF會
議上介紹過，同時發表在會議記錄中[8]。
2．選路與尋址
為了應付Internet預期的增長和功能的演變，IP尋址和選路結構需要改變。人們
猜測：
·Internet將用完IP網絡地址的某些地址類，如B類地址。
·盡管該地址空間當前已被子分和治理，Internet將用完全部32位IP地址空間。
·IP網絡號的總數將增長到一定時刻，就連較好的選路算法也不再能完成基于網絡號
的選路。
·為了答應適應不同的TOS和策略，從一個源到一個目的地需要多個路由。這將需
要新的應用和多種多樣的轉運服務來推動。源或源的代理，必須控制路由的選擇。
2．1建議的方法
處理這些事情所需方法有通用的約定。
(1)必須改變尋址方案，使網絡號集聚成較大的單位，以此作為選路的基礎。自治系統
或行政治理域(AD)就是一種集聚的例子。
集聚將完成若干目標：確定采用策略的范圍，控制選路部件數，以及為網絡治理提供部
件。有些人認為如一個嵌套的AD那樣，可進一步組合一些集聚。
(2)必須提供某些有效的方法來計算公共路由，以及某些通用的方法來計算“特定”的
路由。
特定路由的通用方法將由“源路由”指定的形式來建立路由。
會上，對期望AD如何集聚或選路協議如何組織來處理集聚邊界，尚未達成完全一致
的意見?？赡苁褂靡粋€非常通用的方案(參考文獻Chiappa)，可是某些人傾向于一個更受
限制的方案，并定義期望的網絡模型。
為了處理地址空間耗盡的問題，必須要么擴展地址空間，要么在網的不同部分重用32
位地址字段。下一節將描述幾種可能的地址格式。
或許更重要的問題是如何向新的方案遷移。所有遷移計劃都需要某些路由器(或者Inte
rnet內的其他部件)能重寫包頭，以適應只處理老格式或者只處理新格式的主機。除非格式
變換能夠進行算法上的推理，遷移本身需要在變換元素中建立某種狀態。
我們并不計劃對體系結構進行一系列“小”的改變。從現在起，我們將著手實施一個計
劃，以便能渡過地址空間耗盡的難關。比起Internet社區近期承擔的任務而言，這是一
系列更長的規劃行動，但遷移問題需要一個漫長的研制周期，同時很難發現有效的方法來處
理某些更直接的問題。諸如B類地址的耗盡問題，從某種意義上講，就其本身而論，不用
長時間。因此，一旦我們著手進行一項變更的計劃，就要求全部替代當前的32位全球空間。
(假如有非常巧妙、能很快應用、而又留有發展空間的想法浮現出來的話，本結論總是可以
被修訂的。這并不意味著我們不鼓勵對于短期行動的創新性設想。但需要指出的是即使小的
變更也要花長時間去推廣應用)。
僅有地址空間變換是不夠的。同時還需要提供一個規?？缮炜s的選路體系結構以及能更
完善地治理Internet的工具。建議的方法就是把AD作為選路的集聚單位。我們已經有
部分方法來實現。IDRP能實現這一功能。BGP的OSI版本(IDRP)也能實現。BGP
改進后也可實現。另外需要的附加設施是要有一張網絡號到AD的映象表。
為了若干原因(特定的路由和地址變換以及計費和資源分配)，我們將從“無狀態”網
關模型做起，在該模型中僅把預先計算好的路由存放在網關中，然后發展成另一個模型，該
模型至少在某些網關中每個連接有狀態。
2．2擴展的IP地址格式
擴展的IP地址格式有三個比較好的選擇。
(1)用同樣位數不同含義的地址字段代替32位地址字段。由此地址的唯一性只是在某
個較小的區域(一個AD或者一個集聚的AD)內，而不在全球范圍。當包穿越邊界時，邊
界上的網關重寫包地址。
問題：(a)必須找到并重寫包內的地址；(b)主機軟件需作修改；(c)必須用某些方法建
立地址映象。
本方案是VanJacobson的研究成果，也可參見PaulTsUChiya為NAT所作的工作。
(2)將32位地址字段擴展至64位(或其他值)，用以保持一個全球主機地址和主機所
在的AD。
這樣的選擇方案提供一個從主機到作為選路根據的AD的煩瑣的映射。普通路由(是指
基于目的地址而不需考慮源地址的選路)可直接從包地址中得到，正如目前進行的，不需要
任何事先建立過程。
(3)將32位地址字段擴展至64位(或其他值)，并用該字段作為“平面”主機標識符。
需要時，用建立連接來為路由器提供從主機標識符到AD的映射。

這64位地址如以太網地址一樣，可用來簡化主機標識符的分配問題。
所有以上選擇方案作為遷移的一部分，都需要一個地址重寫模塊。第二和第三方案IP
頭需要改變，所以主機軟件也要隨之改變。
2．3建議的行動
建議采取下列行動：
(1)時間表。
對于上面提出的各種問題，要編制出一個估計的具體時間表，又要對一個新的尋址/選
路體系結構編制出開發和推廣應用的相應時間表。用這些時間表作為根據來評價用于變革的
各種提案。這是IETF的任務。
(2)新地址格式。
探索下一代地址格式的可選方案并提出一個遷移計劃。非凡是要構造一個作地址映射的
網關樣機。要理解這個任務的復雜性，以便指導我們思考有關遷移的方案選擇。
(3)基于AD的選路。
采取步驟做出作為選路基礎的網絡集聚(AD)。非凡是要為映射網絡號到AD的一張
全球映射表探索若干可選方案。這是IETF的事情。
(4)基于策略的選路。
基于策略的選路要繼續當前的工作。有下列明確的目標：
·尋求方法以控制指定策略的復雜性(這是一個人類的接口議題，而不是算法復雜性議
題)。
·充分了解在網關中保持連接狀態的議題。
·充分了解連接狀態建立議題。
(5)進一步集聚的研究。
作為研究活動，探索如何將AD集聚到仍然較大的選路元素中。
·考慮體系結構應定義AD的“角色”，還是集聚的“角色”。
·考慮用一個萬能的選路方法，還是在AD和集聚以內和以外用不同的選路方法。
現有的計劃如DARTnet工程項目幫助解決這些議題中的幾個：如網關內的狀態、狀態
建立、地址映射和計費等。研究開發界的其他試驗也承擔本領域的研究。
3．多協議體系結構
改變Internet以支持多協議集引起以下三個非凡的體系結構問題：
·如何正確地定義Internet？
·如何設計支持多個又不論何種協議集的Internet？
·是為部分還是過濾了的網絡設計連通性？
·如何在體系結構中加入能明顯地支持應用的網關？
3．1什么是“Internet”？
假如不首先確定我們認為的Internet是什么或者應該是什么的話，要想建設性地處
理“多協議Internet”議題將是非常困難的。我們要把“Internet”和“Internet
社區”區別開來，前者是由通信系統組成的，而后者是一群人和組織。大部分人接受后者的
松散定義，即“認為他們自己是Internet社區的一部分”。Internet本身這種“社會
學的”定義似乎是沒有用的。
不久以前，Internet被定義為IP網絡連通性(IP和ICMP過去是、現在仍然是
唯一“需要”的Internet協議)。假如我能ping你，你能ping我，那么我們都在In
ternet上，同時，Internet令人滿足的工作定義可構想為IP對話系統的接近可過渡
的最后結果。這樣的Internet模型是簡單的、統一標準的，或許最重要的是可測試的。
IP網絡連通性模型可清楚地判別系統是否“在Internet上”。
隨著Internet的增長及其使用的技術已廣泛的被商界接受，對一個系統“在Inte
rnet上”的含義已經有所改變，應當包括：
·具有部分IP網絡連通性，受限于策略過濾器的任何系統。
·運行TCP/IP協議集，不管是否從Internet的其他部分實際上可接入的任何系統。
·能交換RFC822郵件，無需郵件網關的干預或郵件對象的轉換的任何系統。
·有e-mail連通到Internet，不論是否需要郵件網關或郵件對象轉換的任何
系統。
對Internet的這些定義仍是基于原始的網絡連通性概念，只是“棧的向上移動”。
在此，基于有區別的統一概念，提出Internet的新定義：
·“老的”Internet概念：以IP為基礎,組織的原則是IP地址，也就是一個公
共的網絡地址空間。
·“新的”Internet概念：以應用為基礎,組織的原則是域名系統和目錄，也就是
一個公共的(雖然必定是多形式的)應用名字空間。
這就告訴我們，“連接的狀況”概念傳統上是與IP地址(通過網絡號)緊密聯系在一起
的，應該代之以與存放在分布式Internet目錄中的名字和相關標識信息聯系在一起的。
Internet基于名字的定義意味著一個大得多的Internet社區，以及一個更為動態(和
不可猜測的)可運轉的Internet。對Internet體系結構的爭論，是基于在很寬的范圍
內對未來可能發展的適應性，而不局限于原來的設想。
3．2基于過程的多協議Internet模型
與其制訂一個非凡的“多協議Internet”，接受一個預先確定特定協議數量的體系
結構，倒不如建議采用一個面向過程的Internet模型，它可以適應不同的協議體系結構，
符合傳統的“能工作”原則。
面向過程的Internet模型，作為一個基本前提，主張不包括穩定狀態“多協議Inte
rnet”的體系結構。最基本的驅動Internet進化的力量不是推動它朝多協議多樣化發
展(雖然事實上永遠不可能達到)。要說明的是Internet發展的趨勢是向同質性進化，作
為最“熱動穩定”狀態，
下面描述一個新的基于過程的Internet體系結構的四個部分：
第1部分：核心Internet體系結構。
這是傳統的基于TCP/IP的體系結構。是Internet進化的“磁鐵中心”，公認(1)
同質性仍然是處理互連網多樣化的最好方法；(2)IP網絡連通性仍然是Internet的最
佳基本模型(在全球Internet中，不論IP無處不在的實際狀態是否是一個現實)。
一開始，Internet體系結構只包括第1部分。然而Internet的成功在于它超出
了原來的設想。無處不在和高度統一，對極大地豐富Internet“基因庫”作出了貢獻。
新Internet體系結構增加的兩個部分擴大了Internet的廣度和深度。
第2部分：鏈路共享。
傳輸媒體、網絡接口及低層鏈路協議等物理資源是由多個非交互的協議集所共享的。這
部分體系結構被認為是必須且適合于共存的，但不涉及到互操作性；被稱為shipsinthenight
(S.I.N.)。
當然，共存的協議集實際上不是純粹孤立的；在真正的Internet系統中，S.I.N.
會引發治理、無沖突、協調和公平性等議題。
第3部分：應用互操作性。
雖然缺乏互連普遍性(即“基礎?！钡幕ゲ僮餍?，但只要在Internet系統的不相鄰
社區之間安排應用的基本語義能以傳遞信息，仍然可能獲得普遍的應用功能。這可以通過應
用轉發站，或者由用戶代理，對不同的由共同語義表示的應用服務提供一致的虛訪問方法來
完成。
體系結構的這一部分，強調了Internet的最終作用是作為應用間的通信基礎，而不
是它本身的結局。在一定程度上，使一個應用群體和他們的用戶能夠從一個基礎協議集過渡
到另外一個，而不會發生難以接受的功能丟失，這可被稱為“過渡起動器”。
將第2和第3部分加入到原始的Internet體系結構中，充其量是一件好壞半摻的
事情。雖然大大增加了Internet的廣度和Internet社區的規模，但也會引入復雜性、
價格和治理等重大問題，同時還會出現功能的丟失(非凡對第3部分而言)。第2和第3部
分不可避免地背離了第1部分所表示的同質性，但這是我們所不希望的。為了擴展Intern
et廣度，某些功能丟失了，還要承受附加的系統復雜性和成本。而在一個完美的世界中，
應該不需付出這些代價就可換得Internet的進化和擴展。
目前有一種趨勢，Internet的進化傾向于第1部分表示的同質性體系結構，而不是
第2和第3部分表示的折衷的體系結構。第4部分表達了這種趨勢。
第4部分：混合/集成。
第4部分熟悉到可以從不同的Internet協議體系結構中集成類似的元素以形成混
合體，以便減少Internet系統的多樣化和復雜性。同時也熟悉到可以影響已存在的Inte
rnet基礎設施以便Internet吸收“新東西”，并把已建立的Internet的測試、評價
和應用實踐融入到“新東西”中去。
本部分表達了Internet的發展趨勢，作為一個系統，試圖回到原來由第1部分統一
的體系結構所表示的“美好的狀態”。雖然Internet將永遠不會在未來的任意時刻回到
統一的狀態，但這是一個對Internet進化起作用的力量。
按照這個動態的進程模型，在TCP/IP棧上通過RFC1006運行X.400郵件，集成
IS-IS選路，傳送網關以及對IP和CLNP協議的單個共同后繼協議的開發，都是很好
的例子。在第1部分主張的“磁場”影響下，參照第4部分混合的動態，它們顯示了背離
第2和第3部分的非統一性，而走向更好的同質性。
4．安全體系結構
4．1哲學準則
Internet安全性體系結構開發的主題是簡單、可測試性、可信度、采用的技術和安
全周界
標識。
·安全性比協議和密碼保密措施要求更多。
·安全性體系結構和策略應該簡單且輕易理解。復雜性會引起錯誤理解和不良的實現。
·實現應該是可測試的，以便確定是否滿足了策略。
·我們認為使任何安全性體系結構運行的硬件、軟件和人是可以信任的。假設安全性策
略實施的技術設備至少和個人計算機及工作站具有同樣的能力。我們不需要能力差的部件受
到自保護(但可能會用諸如鏈路級密碼編碼設備進行外部補救)。
·最后，認定安全性有效保護的周界是最根本的。
4．2安全性周界
有4種可能的安全性周界：鏈路級、網絡/子網級、主機級和進程/應用級。每種施加不
同的需求，能夠接納不同的技術，并能對何種系統部件可以被認為是有效的做出不同的假設。
隱私強化郵件是一種進程級安全系統的例子，另一個例子是為SNMP提供身份驗證
和保密。主機級安全性一般是在主計算機的通信口上用一個外部安全機制。網絡或子網安全
性則應用從子網到“外部”的網關/路由器上的外部安全性能力。鏈路級安全性采用傳統的
點對點或媒體級(如以太網)密碼編碼機制。
關于網絡/子網安全性保護存在許多開放的問題，不單是主機級(端/端)安全性方法與網
絡/子網級安全性方法之間存在潛在的不匹配，而且網絡級保護也不能處理安全性周界內出
現的威脅。
在進程級采用保護，假定基礎的程序和操作系統機制是可以信任的，不會由于使用了相
應的安全機制而妨礙應用程序。當安全性周界在系統體系結構中向下移至鏈路級，就要做有
關安全威脅的許多假設，以便得出這樣的論點，就是在一個特定周界的實施是有效的。例如，
假如只有鏈路級使用加密編碼，我們可以假設來自外部的攻擊，只通過通信線，那么主機、
交換機和網關實際上是被保護的，同時人和所有部件中的軟件都是可以信任的。
4．3期望的安全性服務
假如在系統的應用級和較低級實現選定和非選定的接入控制，則需要可驗證的正規的名
字。除此之外，還需要實施完整性(防修改、防欺騙、防重放)，保密性和防止否認服務。
在某些情況下，可能還需要防止報文傳輸的否認或防止秘密信道。
已經有一些標準部件用以建立Internet安全系統?？梢圆捎妹艽a算法(如DES、R
SA、ElGama1和其他可能的公共密鑰和對稱密鑰算法)，也可以采用如MD2和md5
的散列函數。
根據OSI的意義需要可鑒別的名字，并且為了便于人們了解標識符和目錄服務，非常
需要一個指派標識符以及廣泛使用目錄服務的基礎設施。把公共密鑰與可鑒別的名字捆綁在
一起，并把能力和許可與可鑒別的名字捆綁在一起的認證概念，具有很多優點。
在路由器/網關級，采用地址和協議過濾器及其他配置控制，能有助于形成一個安全性
系統。把建議的OSI安全性協議3(SP3)和安全性協議4(SP4)作為Internet安全性
體系結構的可能要素,要給予認真的考慮。
最后，必須看到，在未實施安全存儲的PC或筆記本電腦系統上，安全地存儲秘密信
息(諸如一個公共密鑰對的秘密部分)，還沒有好的解決方案。
4．4建議的行動
建議采取下列行動：
1：安全性參考模型。
需要建立一個Internet的安全性參考模型，并迅速地得到開發。該模型應該建
立目標周界，并用文件形式建立安全性體系結構目標。
2：隱私強化郵件(PEM)。
對于隱私強化郵件，最要害的步驟看來是建立：(1)認證生成和治理基礎設施；(2)
X.500目錄服務以提供通過可鑒別的名字訪問公共密鑰。在推廣使用本系統時，還需
要對專利方面的限制和出口限制給予認真關注。
3：分布式系統安全性。
對分布式系統的應用，不論是簡單的客戶機/服務器系統還是復雜的分布式計算環
境，都需要檢查安全設施。例如，對授予與可鑒別的名字捆綁在一起的許可/能力的認
證的實用性應受到檢查。
4：主機級安全性。
對面向主機的安全性，應當對SP4予以評估，SP3也在考慮之列。
5：應用級安全性。
不論是為了服務的直接實用性(如PEM.SNMP身份驗證)，還是為了獲得能夠形成I
nternet安全性體系結構精華的有價值的實際經驗，都應該實施應用級安全性服務。
5．業務流控制與狀態
目前的Internet平等地處理所有的IP數據報。每個數據報對同一連接、同一
應用、同一應用類別、同一用戶類，不論它和其他包有任何關系，都是獨立地轉發的。
雖然在IP頭中定義了服務類型位和優先權位，但通常都沒有實施，事實上還不清楚如
何去實施它們。
眾所周知，未來的Internet需要支持盡力而為所不能滿足的大量應用，如電視
會議的包圖像和語音。為了處理實時業務流，要求在路由器中有以附加的狀態來控制的
業務流控制機制。
5．1假設和原則
·假設：Internet需要為業務流的特定子集支持性能保證。
遺憾的是對術語“性能”、“保證”或“子集”，遠不能給出精確的定義。研究仍需
要對這些問題做出回答。
·默認的服務將繼續是當前無服務保證的“盡力而為”數據報分發服務。
·路由器機制可分割為兩部分：(1)轉發路徑；(2)發生在后臺的控制計算(如選路)。
轉發路徑必須高度優化，有時由硬件輔助完成，因此相對而言很昂貴，而且難于變
更。運行在轉發路徑上的業務流控制機制，是由發生在后臺的選路和資源控制計算創建
的狀態來控制的。在改變路由器的轉發路徑時，最多起動一次，所以最好一開始就使它
正確。
·新的擴展必須運行在一個高度異質的環境中。在該環境中，某些部分將永遠不支持
保證。對一個路徑上的某些段(如高速局域網)，即使當顯式資源預留不用時，“超配給”
(即超過容量)也會對實時業務給予滿足要求的服務。
·組播分發或許是最根本的。
5．2技術議題
需要解決的技術議題，包括：
(1)資源建立。
為了支持實時業務流，從源到目的地的路由上的路由器中需要預留資源。該新的路
由器狀態應該是“硬”的(如建立連接)還是“軟”的(即緩沖的狀態)？
(2)資源捆綁與路由捆綁。
選擇從源到目的地的一條路由傳統上是由一個動態選路協議來完成的。資源捆綁和
選路可以重疊在單個復合進程中，或者也可以基本上獨立地完成。這就要求在復雜性和
效率之間折衷考慮。
(3)另一組播模型。
IP組播用一個邏輯尋址模型，在該模型中，目標地址本身與一個組聯系。在ST-2
中，一個組播會話中的每個主機在它的建立包中包括一系列顯式目標地址。每一種方法
都有優點和缺點。當前還不十分清楚對n路電視會議而言，哪個會占優勢。
(4)資源建立與行政治理域間的選路。
不論傾向于哪種資源保證，必須保持穿越一條任意的端對端并包括多個AD的路
由。因此，任何資源建立機制必須與包含在IDPR中的路由建立機制平穩地配合。
(5)計費。
資源保證子集(“類別”)可以是自然的計費單位。
5．3建議的行動
此處所謂的行動是指對上面列出的技術議題的進一步研究，緊隨其后的是相應協議
的開發和標準化。DARTnet，DARPA研究測試床網絡，在本研究中將起重要作用。
6．現代應用
人們不禁要問“我們想要何種基于網絡的應用，為什么現在還沒有？”很輕易列出
一張潛在應用的大表，其中許多都將基于客戶機/服務器模型。然而問題中更有意思的
是：“為什么還沒有人來做呢？”回答是：方便應用程序編寫的工具尚不存在。
首先，對于許多將用于穿越網絡的數據術語，需要一套公共交換格式。定義了公共
交換格式后，還需便于開發應用程序移動數據的工具。
6．1公共交換格式
為使信息有意義，應用程序必須知道它們要交換的信息的格式?？紤]下面的格式類
型：
(1)文本—文本是最標準的，但今天的國際性Internet還需要有除了USASCII
以外的字符集。
(2)圖像—當進入“多媒體時代”，圖像變得越來越重要，但需要對如何在信息包
中表示圖像信息取得一致。
(3)圖形—和圖像一樣，矢量圖形信息需要一個共同的定義。有了定義的格式才能
交換類似結構藍圖的細節。
(4)視頻—先要知道從網絡上來的視頻信息的格式，才能在工作站上運行視頻窗
口。
(5)模擬音頻—當然，人們需要的是伴有聲音的視頻，但這樣的格式應該可以表示
所有類型的模擬信號。
(6)顯示—我們打開工作站上的窗口，并打開另一個人的工作站上的窗口，給它顯
示與研究項目有關的某些數據，所以需要一個通用的窗口顯示格式。
(7)數據對象—對進程間的通信，類似整數、實數、串等數據的格式需要一致。
這些格式的相當一部分正在由幾個標準組定義。我們需要為Internet的每一類取得
一種一致的格式。
6．2數據交換方法
應用程序將需要下列的數據交換方法：
(1)存儲轉發。
不是每個人所有時間都在網上。需要一個標準手段向有時連在網上的主機提供信息
流，也就是需要一個通用的存儲轉發服務。組播也應包括在這一服務中。
(2)全球文件系統。
在網上，大部分數據訪問可以被分解成單個文件訪問。假如有一個真正的全球文件
系統，那就能訪問Internet上的任何文件(假定被許可的話)。你曾經需要用FTP
嗎？
(3)進程間通信。
對一個真正的分布式計算環境，需要通過一些手段使進程在網絡上能通過一個標準
方法來交換數據。這樣的需求包括RPC、API等。
(4)數據廣播。
許多應用程序要求發送同樣的信息到其他許多主機，因此需要一個標準且高效的方
法來完成這功能。
(5)數據庫訪問。
對于好的信息交換，需要為訪問數據庫指定一個標準方法。全球文件系統能使你獲
得數據，但數據庫訪問方法將告訴你有關它的結構和內容。
上述許多項正在由其他組織著手擬訂，但對Internet的互操作性，還需要在方法上
取得一致。
最后，現代應用需對本文中兩個較早領域的問題尋找解決方案。從業務流控制與狀
態領域而言，應用需要發送實時數據的能力。這意味著數據能在一個確定的時間范圍內
分發。從安全性領域而言，應用也需要全球身份驗證和訪問控制系統。今天的Internet
由于缺乏可信度和安全，失去了許多有用的應用。這要求在明天的應用中得到解決。
7．參考資料
[1]Cerf,V.andR.Kahn,"AProtocolforPacketNetwork
Intercommunication,"IEEETransactionsonCommunication,May
1974.

[2]Postel,J.,Sunshine,C.,andD.Cohen,"TheARPAInternet
Protocol,"ComputerNetworks,Vol.5,No.4,July1981.

[3]Leiner,B.,Postel,J.,Cole,R.,andD.Mills,"TheDARPA
InternetProtocolSuite,"ProceedingsINFOCOM85,IEEE,
WashingtonDC,March1985.Alsoin:IEEECommunications
Magazine,March1985.

[4]Clark,D.,"TheDesignPhilosophyoftheDARPAInternet
Protocols",ProceedingsACMSIGCOMM'88,Stanford,California,
August1988.

[5]Mogul,J.,andJ.Postel,"InternetStandardSubnetting
Procedure",RFC950,USC/InformationSciencesInstitute,August
1985.

[6]Mockapetris,P.,"DomainNames-ConceptsandFacilities",RFC
1034,USC/InformationSciencesInstitute,November1987.

[7]Deering,S.,"HostExtensionsforIPMulticasting",RFC1112,
StanfordUniversity,August1989.

[8]"ProceedingsoftheTwenty-FirstInternetEngineeringTask
Force",Bell-South,Atlanta,July29-August2,1991.
附錄A設定步驟
幻燈片1
————————————————————————————
Internet向何處去？
體系結構的選擇
IAB/IESG--1990年1月
DavidD.Clark
——————————————————————————————
幻燈片2
————————————————————————————

設定討論的課題
目的：
·為IAB、IESG及Internet社區建立一個理解的共同框架。
·了解要解決的問題集
·了解為我們敞開的解決方案的范圍
·得出某些結論或“總結論”。
————————————————————————————
幻燈片3
————————————————————————————
若干聲明—我的見解
兩個不同的目標：
·使建立Internet成為可能。
·定義Internet的一套協議。
聲明：這些目標有非常不同的含義。協議只不過是一種手段，然而是一種有力的手段。
聲明：假如Internet獲得成功及增長，就將需要專門的設計。這就需要至少另一個十年
的
繼續努力。
聲明：不加控制的增長將會導致混亂。
聲明：從根本上解決問題看來是走向成功的唯一方法。從上向下命令是無力的。
————————————————————————————
幻燈片4
————————————————————————————
報告提綱
(1) 問題空間和解決方案空間。
(2) 一系列專門問題—供討論用。
(3) 回到頂層問題—供討論用。
(4) 行動計劃—供總體討論用。
設法從技術研究中將功能需求分離出來。
了解我們是如何受到問題空間和解決方案空間的限制。
是否體系結構除了協議以外別無其他？
————————————————————————————
幻燈片5
————————————————————————————
問題空間是什么？
選路與尋址：
大到什么程度，采用何種拓撲結構及選路模型？
逐漸變大：
用戶服務；主機和網絡采用何種技術？
Internet的舍棄：
計費、控制的使用和修復故障。
新服務：
視頻？事務處理？分布計算？
安全性：
終端節點還是網絡？路由器還是轉發器？
————————————————————————————
幻燈片6
————————————————————————————
限定解決方案的空間
從當前的狀態能遷移到多遠？
·我們能改變IP頭嗎(除了OSI外)？
·我們能以命令方式改變主機的需求嗎？
·我們能治理一個長期遷移目標嗎？—始終如一的方向與多種多樣的目標、資金來源。
我們能接受網絡級的連通性嗎？
·轉發將來會被拋棄嗎？
·安全性以及變換是一個要害議題。
·需要一個基于轉發的體系結構嗎？
如何能夠和必須治理Internet？
·我們能治理或者限制網絡的連通性嗎？
研究開發什么協議？一個還是多個？
————————————————————————————
幻燈片7
————————————————————————————
多協議Internet
“把問題想得難一點對人類有好處?！?br />我們是遷移、互操作還是容忍多協議？
·不是所有的協議集在同一時期都有同樣的功能范圍。
·Internet需要特定的功能。
聲明：基本的矛盾(非宗教性的或惡意的)：
·滿足Internet積極進取的需求。
·處理OSI遷移。
結論：一種協議必定為主導，其他協議必定為輔助。我們什么時候“切換”到OSI？
請考察本文下面的每張幻燈片。
————————————————————————————

幻燈片8
————————————————————————————
選路和尋址
什么是Internet的目標規模？
·如何將地址和路由聯系起來？
·拓撲模型是什么？
·什么是可能的解決方案？
選路要求什么樣的策略范圍？
·BGP和IDRP是兩個解答。問題在那兒？
·固定類別或可變路徑？
·源控制的選路是最低要求。
如何無縫地支持移動主機？
·新地址類，再捆綁到本地地址，用DNS嗎？
是否要推動Internet組播？
————————————————————————————
幻燈片9
————————————————————————————
逐漸變大—一個老題目
(尋址與選路在前一張幻燈片上。)
在下一個十年中需要什么樣的用戶服務？
·我們能否構筑一個計劃？
·需要體系結構方面的改變嗎？
是否有更好的處理速度、包大小等范圍的需求。
·是否取消分段策略？
我們將支持什么主機范圍(如UNIX環境)？
————————————————————————————
幻燈片10
————————————————————————————
處理舍棄
Internet是由獨立治理和控制的部分組成的。
為網絡收費需要什么支持？
·體系結構不隱含按容量收費、重記帳和為丟失包付費。
·是否需要控制以提供記帳標識符或選路？
需求：必須支持有控制共享的鏈路。(簡單的形式是基于鏈路標識符的類別)。
·如何一般化？
對故障隔離是否更加需要？(我投贊成票！)
·我們如何能找到可以交談的經理們？
·我們需要主機上的服務嗎？
————————————————————————————
幻燈片11
————————————————————————————
新服務
要支持視頻和音頻嗎？是實時嗎？百分比多少？
·需要計劃從研究結果得到什么，什么樣的質量？
·向供貨商交底的目標日期。
我們能“更好”地支持事務處理嗎？
·TCP能做嗎？VMTP呢？介紹呢，還是剎車？
哪些象樣的應用即將出籠？
·分布計算—它真的將發生嗎？
·信息網絡技術嗎？
————————————————————————————
幻燈片12
————————————————————————————
安全性
能堅持說終端節點是唯一防線嗎？
·在網絡內部我們能做什么？
·能要求主機做什么？
能容忍轉發器或安排它們的結構嗎？
能找到一個更好的方法來構筑安全性邊界嗎？
需要全球身份驗證嗎？
有新的主機需求嗎？
·登錄。
·身份驗證。
·治理接口。電話號碼或訪問點。
————————————————————————————
附錄B組成員
第一組：選路與尋址
DaveClark,MIT[Chair]
Hans-WernerBraun,SDSC
NoelChiappa,Consultant
DeborahEstrin,USC
PhillGross,CNRI
BobHinden,BBN
VanJacobson,LBL
TonyLauck,DEC.

第二組：多協議體系結構
LymanChapin,BBN[Chair]
RossCallon,DEC
DaveCrocker,DEC
ChristianHuitema,INRIA
BarryLeiner,
JonPostel,ISI
第三組：安全性體系結構
VintCerf,CNRI[Chair]
SteveCrocker,TIS
SteveKent,BBN
PaulMockapetris,DARPA

第四組：業務流控制與狀態
RobertBraden,ISI[Chair]
ChuckDavin,MIT
DaveMills,UniversityofDelaware
ClaudioTopolcic,CNRI

第五組：現代應用
RussHobby,UCDavis[Chair]
DaveBorman,CrayResearch
CliffLynch,UniversityofCalifornia
JoyceK.Reynolds,ISI
BruceSchatz,UniversityofArizona
MikeSchwartz,UniversityofColorado
GregVaudreuil,CNRI.