组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm)<br />
E-mail：ouyang@china-pub.com<br />
译者：党红梅（snowlily&nbsp;&nbsp;&nbsp;danghongmei@263.net）<br />
译文发布时间：2001－5－7<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须<br />
保留本文档的翻译及版权信息。<br />
<br />
<br />
Network&nbsp;Working&nbsp;Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;D.&nbsp;Clark<br />
Request&nbsp;for&nbsp;Comments:&nbsp;1287&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MIT<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;L.&nbsp;Chapin<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;BBN<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;V.&nbsp;Cerf<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;CNRI<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;R.&nbsp;Braden<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ISI<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;R.&nbsp;Hobby<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;UC&nbsp;Davis<br />
December&nbsp;1991<br />
<br />
<br />
未来的Internet&nbsp;体系结构<br />
(RFC&nbsp;1287&nbsp;&nbsp;Towards&nbsp;the&nbsp;Future&nbsp;Internet&nbsp;Architecture)<br />
<br />
本备忘录的状态<br />
这是一个提供信息的R&nbsp;F&nbsp;C&nbsp;，它讨论I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;体系结构未来可能演变的重大方向，<br />
及走向期望目标的建议步骤。它是提供给I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;社区讨论和评议用的。本文是为I&nbsp;n&nbsp;t&nbsp;<br />
e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;社区提供信息，而不是指定I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;标准，本文的分发不受限制。<br />
目录<br />
1．	简介	2<br />
1．1&nbsp;Internet体系结构	2<br />
1．2&nbsp;假设	3<br />
1．3&nbsp;开始一个规划过程	3<br />
2．选路与寻址	4<br />
2．1&nbsp;建议的方法	4<br />
2．2&nbsp;扩展的IP地址格式	5<br />
2．3&nbsp;建议的行动	6<br />
3．多协议体系结构	6<br />
3．1&nbsp;什么是“Internet&nbsp;”？	7<br />
3．2&nbsp;基于过程的多协议Internet&nbsp;模型	7<br />
4．安全体系结构	9<br />
4．1&nbsp;哲学准则	9<br />
4．2&nbsp;安全性周界	9<br />
4．3&nbsp;期望的安全性服务	9<br />
4．4&nbsp;建议的行动	10<br />
5．业务流控制与状态	10<br />
5．1&nbsp;假设和原则	10<br />
5．2&nbsp;技术议题	11<br />
5．3&nbsp;建议的行动	11<br />
6．现代应用	11<br />
6．1&nbsp;公共交换格式	12<br />
6．2&nbsp;数据交换方法	12<br />
7．参考资料	13<br />
附录A&nbsp;&nbsp;设定步骤	14<br />
幻灯片1	14<br />
幻灯片2	14<br />
幻灯片3	14<br />
幻灯片4	14<br />
幻灯片5	15<br />
幻灯片6	15<br />
幻灯片7	16<br />
幻灯片8	16<br />
幻灯片9	16<br />
幻灯片10	17<br />
幻灯片11	17<br />
幻灯片12	17<br />
附录B&nbsp;&nbsp;组成员	18<br />
第一组：选路与寻址	18<br />
第二组：多协议体系结构	18<br />
第三组：安全性体系结构	18<br />
第四组：业务流控制与状态	19<br />
第五组：现代应用	19<br />
安全问题	19<br />
作者联系方法	19<br />
<br />
1．	简介<br />
1．1&nbsp;Internet体系结构<br />
作为T&nbsp;C&nbsp;P&nbsp;/&nbsp;I&nbsp;P&nbsp;协议集之后的巨大计划，I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;体系结构在7&nbsp;0&nbsp;年代后期由<br />
一个网络研究小组[&nbsp;1&nbsp;、2&nbsp;、3&nbsp;、4&nbsp;]&nbsp;开发并测试。8&nbsp;0&nbsp;年代初期，体系结构中加入了若<br />
干重要的特性，如子网化、自治系统和域名系统[&nbsp;5&nbsp;、6&nbsp;]&nbsp;。最近又加入了I&nbsp;P&nbsp;组播[&nbsp;7&nbsp;]&nbsp;。<br />
在本体系结构框架内，I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;工程任务组(&nbsp;I&nbsp;E&nbsp;T&nbsp;F&nbsp;)一直以极大的活力和效率为I&nbsp;n&nbsp;<br />
t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;策划、定义、推广、测试和标准化协议进行不懈的工作。已完成的三个特别重<br />
要的领域是选路协议、T&nbsp;C&nbsp;P&nbsp;性能与网络管理。同时，I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;基础设施继续以惊<br />
人的速度增长。自1&nbsp;9&nbsp;8&nbsp;3&nbsp;年1&nbsp;月A&nbsp;R&nbsp;PA&nbsp;N&nbsp;E&nbsp;T第一次从N&nbsp;C&nbsp;P&nbsp;转换成T&nbsp;C&nbsp;P&nbsp;/&nbsp;I&nbsp;P&nbsp;时，<br />
I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的销售商、管理员、专家和研究人员一直以极大的努力坚强地工作，为他<br />
们的成功而奋斗不息。<br />
定义I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;体系结构的一组研究人员形成了I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;活动董事会(&nbsp;I&nbsp;A&nbsp;B&nbsp;)<br />
的初始成员。I&nbsp;A&nbsp;B&nbsp;由1&nbsp;9&nbsp;8&nbsp;1&nbsp;年D&nbsp;A&nbsp;R&nbsp;PA&nbsp;建立的一个技术顾问组发展成为I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;<br />
总技术和策略监督实体。I&nbsp;A&nbsp;B&nbsp;的成员年年有变化，以便更好地体现I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;社区<br />
中需求和议题的变化，及反映I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的国际化，但仍旧保持协议体系结构制定的<br />
关系。<br />
I&nbsp;A&nbsp;B&nbsp;创建了I&nbsp;E&nbsp;T&nbsp;F&nbsp;，为I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;实施协议的开发和工程设计。为了管理不断<br />
发展的I&nbsp;E&nbsp;T&nbsp;F&nbsp;活动，I&nbsp;E&nbsp;T&nbsp;F&nbsp;主持在I&nbsp;E&nbsp;T&nbsp;F&nbsp;内建立了I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;工程指导组(&nbsp;I&nbsp;E&nbsp;S&nbsp;<br />
G&nbsp;)。I&nbsp;A&nbsp;B&nbsp;和I&nbsp;E&nbsp;S&nbsp;G&nbsp;密切配合，共同批准I&nbsp;E&nbsp;T&nbsp;F&nbsp;内开发的协议标准。<br />
过去几年中，对基础体系结构有着不断增加的严峻考验的迹象，大部分由于I&nbsp;n&nbsp;t&nbsp;e&nbsp;<br />
r&nbsp;n&nbsp;e&nbsp;t&nbsp;持续不断的增长引起。对这些问题的讨论经常反映在许多主要的发送文件清单<br />
中。<br />
1．2&nbsp;假设<br />
对当前I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;体系结构中的问题，解决的优先次序取决于人们对T&nbsp;C&nbsp;P&nbsp;/&nbsp;I&nbsp;P&nbsp;与O&nbsp;S&nbsp;<br />
I&nbsp;协议集未来关系的观点。一种观点是让T&nbsp;C&nbsp;P&nbsp;/&nbsp;I&nbsp;P&nbsp;夭折在成功之中，然后转换到O&nbsp;S&nbsp;I&nbsp;协<br />
议。然而，许多在I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;协议产品和服务上花过大力气并获得成功的人们，急于要在<br />
已有的框架内尝试解决新的问题。而且，有些人相信O&nbsp;S&nbsp;I&nbsp;协议将会遇到许多同样类型的问<br />
题。<br />
为了着手解决这些问题，I&nbsp;A&nbsp;B&nbsp;和I&nbsp;E&nbsp;S&nbsp;G&nbsp;于1&nbsp;9&nbsp;9&nbsp;1&nbsp;年1&nbsp;月联合组织了一天有关I&nbsp;n&nbsp;t&nbsp;e&nbsp;<br />
r&nbsp;n&nbsp;e&nbsp;t&nbsp;体系结构议题的讨论会。这次会议的框架是由Dave&nbsp;Clark(见附录A&nbsp;中的幻灯片)整理<br />
的。关于T&nbsp;C&nbsp;P&nbsp;/&nbsp;I&nbsp;P&nbsp;与O&nbsp;S&nbsp;I&nbsp;协议的关系和未来方向问题上的讨论生气勃勃、富有挑战，有<br />
时还有激烈的争论。会议的重要成果是在下一个5&nbsp;~&nbsp;1&nbsp;0&nbsp;年涉及网络世界的下述四个基本假<br />
设上达成了共识。<br />
(1)&nbsp;TCP/IP&nbsp;和O&nbsp;S&nbsp;I&nbsp;协议集将在一个长时期内共存。<br />
O&nbsp;S&nbsp;I&nbsp;协议集引入的背后是强有力的政治和市场力量，以及以某些技术优势作后盾。然<br />
而，T&nbsp;C&nbsp;P&nbsp;/&nbsp;I&nbsp;P&nbsp;牢固确立的市场位置意味着在可预见的未来非常可能继续使用。<br />
(2)&nbsp;Internet&nbsp;将继续包括各种各样的网络和服务，永远不会是由一个单网络技术构成的。<br />
实际上接到I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;上的网络技术和特性的范围在下一个十年还将增加。<br />
(3)&nbsp;商用和专用网也将加入，但不能期望公共通信提供全部服务。将会形成公用网和专<br />
用网、公共通信与专用线路混用的局面。<br />
(4)&nbsp;Internet&nbsp;体系结构要能达到1&nbsp;09&nbsp;个网络的规模。<br />
I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的规模历史性地呈指数增长，在将来的某个时候估计可能会饱和，但预测<br />
到什么时候饱和，差不多和预测未来的经济一样容易。在任何情况下，负责工程设计的需要<br />
考虑一个有能力扩展到最坏情况规模的体系结构。指数9&nbsp;是比较模糊的数字，估计在7&nbsp;~&nbsp;1&nbsp;0&nbsp;<br />
之间变化。<br />
1．3&nbsp;开始一个规划过程<br />
I&nbsp;A&nbsp;B&nbsp;和I&nbsp;E&nbsp;S&nbsp;G&nbsp;会议的另一个成果是在体系结构进化中的下列五个最重要的领域<br />
上形成了共识。<br />
(1)&nbsp;选路与寻址<br />
这是一个最急需解决的体系结构的问题，因为它直接关系到Internet&nbsp;继续成功增长<br />
的能力。<br />
(2)&nbsp;多协议体系结构<br />
I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;正在朝着广泛的既支持T&nbsp;C&nbsp;P&nbsp;/&nbsp;I&nbsp;P&nbsp;又支持O&nbsp;S&nbsp;I&nbsp;协议集的方向迈进。<br />
对两个协议集的支持带来了技术难题，需要有一个计划，也就是一个体系结构来增加成<br />
功的机会。人们开玩笑地把这个领域看成是：“为了造福人类，问题变得更艰难”。<br />
C&nbsp;l&nbsp;a&nbsp;r&nbsp;k&nbsp;观察到转发网关(如邮件网关)在I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;运行中是非常有生命力的，但<br />
是它不属于体系结构或规划的一部分。该组成员讨论了围绕包含这样的网关的部分网络<br />
连接来建立体系结构的可能性。<br />
(3)&nbsp;安全性体系结构<br />
在设计I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;体系结构时，虽然考虑到了军事上的安全性，可是现代安全性<br />
议题是非常广泛的，它也包括了商业上的需求。还有，经验表明除非一开始就把它建立<br />
到体系结构中去，否则是很难在协议集内再加入安全性。<br />
(4)&nbsp;数据流控制及状态<br />
I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;将扩展以支持如语音和视频这样的“实时”应用。这就需要网关中有<br />
新的包排队机制(数据流控制)和附加的网关状态。<br />
(5)&nbsp;现代应用<br />
随着基础的I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;通信机制的成熟，需要不断革新和标准化，以创建新形式<br />
的应用。<br />
I&nbsp;A&nbsp;B&nbsp;和I&nbsp;E&nbsp;S&nbsp;G&nbsp;于1&nbsp;9&nbsp;9&nbsp;1&nbsp;年6&nbsp;月再次在S&nbsp;D&nbsp;S&nbsp;C&nbsp;召开三天的会议，讨论这5&nbsp;个<br />
课题。这次会议多少有点反常，被称为“体系结构的再处理”，召集在一起开会，表明<br />
有坚强的决心朝着规划体系结构的进化迈出第一步。除了I&nbsp;A&nbsp;B&nbsp;和IESG&nbsp;以外，由3&nbsp;2&nbsp;人<br />
组成的小组，包括了研究指导组(&nbsp;IRSG)的成员及少量的特邀客人。会议的第二天，分<br />
成5&nbsp;个组讨论，每个组讨论1&nbsp;个领域的问题。附录B&nbsp;列出了成员名单。<br />
本文件是从这些组的主席报告中收集得到的。该材料在亚特兰大召开的I&nbsp;E&nbsp;T&nbsp;F&nbsp;会<br />
议上介绍过，同时发表在会议记录中[&nbsp;8&nbsp;]&nbsp;。<br />
2．选路与寻址<br />
为了应付I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;预期的增长和功能的演变，I&nbsp;P&nbsp;寻址和选路结构需要改变。人们<br />
预测：<br />
·&nbsp;Internet&nbsp;将用完I&nbsp;P&nbsp;网络地址的某些地址类，如B&nbsp;类地址。<br />
·&nbsp;尽管该地址空间当前已被子分和管理，I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;将用完全部3&nbsp;2&nbsp;位I&nbsp;P&nbsp;地址空间。<br />
·&nbsp;IP&nbsp;网络号的总数将增长到一定时刻，就连较好的选路算法也不再能完成基于网络号<br />
的选路。<br />
·&nbsp;为了允许适应不同的TO&nbsp;S&nbsp;和策略，从一个源到一个目的地需要多个路由。这将需<br />
要新的应用和多种多样的转运服务来推动。源或源的代理，必须控制路由的选择。<br />
2．1&nbsp;建议的方法<br />
处理这些事情所需方法有通用的约定。<br />
(1)&nbsp;必须改变寻址方案，使网络号集聚成较大的单位，以此作为选路的基础。自治系统<br />
或行政管理域(&nbsp;A&nbsp;D&nbsp;)就是一种集聚的例子。<br />
集聚将完成若干目标：确定采用策略的范围，控制选路部件数，以及为网络管理提供部<br />
件。有些人认为如一个嵌套的A&nbsp;D&nbsp;那样，可进一步组合一些集聚。<br />
(2)&nbsp;必须提供某些有效的方法来计算公共路由，以及某些通用的方法来计算“特定”的<br />
路由。<br />
特定路由的通用方法将由“源路由”指定的形式来建立路由。<br />
会上，对期望A&nbsp;D&nbsp;如何集聚或选路协议如何组织来处理集聚边界，尚未达成完全一致<br />
的意见。可能使用一个非常通用的方案(参考文献C&nbsp;h&nbsp;i&nbsp;a&nbsp;p&nbsp;p&nbsp;a&nbsp;)，可是某些人倾向于一个更受<br />
限制的方案，并定义期望的网络模型。<br />
为了处理地址空间耗尽的问题，必须要么扩展地址空间，要么在网的不同部分重用3&nbsp;2&nbsp;<br />
位地址字段。下一节将描述几种可能的地址格式。<br />
或许更重要的问题是如何向新的方案迁移。所有迁移计划都需要某些路由器(或者I&nbsp;n&nbsp;t&nbsp;e&nbsp;<br />
r&nbsp;n&nbsp;e&nbsp;t内的其他部件)能重写包头，以适应只处理老格式或者只处理新格式的主机。除非格式<br />
变换能够进行算法上的推理，迁移本身需要在变换元素中建立某种状态。<br />
我们并不计划对体系结构进行一系列“小”的改变。从现在起，我们将着手实施一个计<br />
划，以便能渡过地址空间耗尽的难关。比起I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;社区近期承担的任务而言，这是一<br />
系列更长的规划行动，但迁移问题需要一个漫长的研制周期，同时很难发现有效的方法来处<br />
理某些更直接的问题。诸如B&nbsp;类地址的耗尽问题，从某种意义上讲，就其本身而论，不用<br />
长时间。因此，一旦我们着手进行一项变更的计划，就要求全部替代当前的3&nbsp;2&nbsp;位全球空间。<br />
(&nbsp;如果有非常巧妙、能很快应用、而又留有发展空间的想法浮现出来的话，本结论总是可以<br />
被修订的。这并不意味着我们不鼓励对于短期行动的创新性设想。但需要指出的是即使小的<br />
变更也要花长时间去推广应用)。<br />
仅有地址空间变换是不够的。同时还需要提供一个规模可伸缩的选路体系结构以及能更<br />
完善地管理I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的工具。建议的方法就是把A&nbsp;D&nbsp;作为选路的集聚单位。我们已经有<br />
部分方法来实现。I&nbsp;D&nbsp;R&nbsp;P&nbsp;能实现这一功能。B&nbsp;G&nbsp;P&nbsp;的O&nbsp;S&nbsp;I&nbsp;版本(&nbsp;I&nbsp;D&nbsp;R&nbsp;P&nbsp;)也能实现。B&nbsp;G&nbsp;P&nbsp;<br />
改进后也可实现。另外需要的附加设施是要有一张网络号到A&nbsp;D&nbsp;的映象表。<br />
为了若干原因(&nbsp;特定的路由和地址变换以及计费和资源分配)，我们将从“无状态”网<br />
关模型做起，在该模型中仅把预先计算好的路由存放在网关中，然后发展成另一个模型，该<br />
模型至少在某些网关中每个连接有状态。<br />
2．2&nbsp;扩展的IP地址格式<br />
扩展的I&nbsp;P&nbsp;地址格式有三个比较好的选择。<br />
(1)&nbsp;用同样位数不同含义的地址字段代替3&nbsp;2&nbsp;位地址字段。由此地址的唯一性只是在某<br />
个较小的区域(一个A&nbsp;D&nbsp;或者一个集聚的A&nbsp;D&nbsp;)内，而不在全球范围。当包穿越边界时，边<br />
界上的网关重写包地址。<br />
问题：(&nbsp;a&nbsp;)必须找到并重写包内的地址；(&nbsp;b&nbsp;)主机软件需作修改；(&nbsp;c&nbsp;)必须用某些方法建<br />
立地址映象。<br />
本方案是Van&nbsp;Jacobson&nbsp;的研究成果，也可参见Paul&nbsp;Ts&nbsp;u&nbsp;c&nbsp;h&nbsp;i&nbsp;y&nbsp;a&nbsp;为N&nbsp;AT&nbsp;所作的工作。<br />
(2)&nbsp;将3&nbsp;2&nbsp;位地址字段扩展至6&nbsp;4&nbsp;位(或其他值)，用以保持一个全球主机地址和主机所<br />
在的A&nbsp;D&nbsp;。<br />
这样的选择方案提供一个从主机到作为选路根据的A&nbsp;D&nbsp;的烦琐的映射。普通路由(是指<br />
基于目的地址而不需考虑源地址的选路)可直接从包地址中得到，正如目前进行的，不需要<br />
任何事先建立过程。<br />
(3)&nbsp;将3&nbsp;2&nbsp;位地址字段扩展至6&nbsp;4&nbsp;位(或其他值)，并用该字段作为“平面”主机标识符。<br />
需要时，用建立连接来为路由器提供从主机标识符到A&nbsp;D&nbsp;的映射。<br />
<br />
这6&nbsp;4&nbsp;位地址如以太网地址一样，可用来简化主机标识符的分配问题。<br />
所有以上选择方案作为迁移的一部分，都需要一个地址重写模块。第二和第三方案I&nbsp;P&nbsp;<br />
头需要改变，所以主机软件也要随之改变。<br />
2．3&nbsp;建议的行动<br />
建议采取下列行动：<br />
(1)&nbsp;时间表。<br />
对于上面提出的各种问题，要编制出一个估计的详细时间表，又要对一个新的寻址/选<br />
路体系结构编制出开发和推广应用的相应时间表。用这些时间表作为根据来评价用于变革的<br />
各种提案。这是I&nbsp;E&nbsp;T&nbsp;F&nbsp;的任务。<br />
(2)&nbsp;新地址格式。<br />
探索下一代地址格式的可选方案并提出一个迁移计划。特别是要构造一个作地址映射的<br />
网关样机。要理解这个任务的复杂性，以便指导我们思考有关迁移的方案选择。<br />
(3)&nbsp;基于A&nbsp;D&nbsp;的选路。<br />
采取步骤做出作为选路基础的网络集聚(&nbsp;A&nbsp;D&nbsp;)。特别是要为映射网络号到A&nbsp;D&nbsp;的一张<br />
全球映射表探索若干可选方案。这是I&nbsp;E&nbsp;T&nbsp;F&nbsp;的事情。<br />
(4)&nbsp;基于策略的选路。<br />
基于策略的选路要继续当前的工作。有下列明确的目标：<br />
·&nbsp;寻求方法以控制指定策略的复杂性(这是一个人类的接口议题，而不是算法复杂性议<br />
题)。<br />
·&nbsp;充分了解在网关中保持连接状态的议题。<br />
·&nbsp;充分了解连接状态建立议题。<br />
(5)&nbsp;进一步集聚的研究。<br />
作为研究活动，探索如何将A&nbsp;D&nbsp;集聚到仍然较大的选路元素中。<br />
·&nbsp;考虑体系结构应定义A&nbsp;D&nbsp;的“角色”，还是集聚的“角色”。<br />
·&nbsp;考虑用一个万能的选路方法，还是在A&nbsp;D&nbsp;和集聚以内和以外用不同的选路方法。<br />
现有的计划如D&nbsp;A&nbsp;RTnet&nbsp;工程项目帮助解决这些议题中的几个：如网关内的状态、状态<br />
建立、地址映射和计费等。研究开发界的其他试验也承担本领域的研究。<br />
3．多协议体系结构<br />
改变I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;以支持多协议集引起以下三个特殊的体系结构问题：<br />
·&nbsp;如何正确地定义I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;？<br />
·&nbsp;如何设计支持多个又不论何种协议集的I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;？<br />
·&nbsp;是为部分还是过滤了的网络设计连通性？<br />
·&nbsp;如何在体系结构中加入能明显地支持应用的网关？<br />
3．1&nbsp;什么是“Internet&nbsp;”？<br />
如果不首先确定我们认为的I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;是什么或者应该是什么的话，要想建设性地处<br />
理“多协议I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;”议题将是非常困难的。我们要把“I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;”和“I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;<br />
社区”区别开来，前者是由通信系统组成的，而后者是一群人和组织。大部分人接受后者的<br />
松散定义，即“认为他们自己是I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;社区的一部分”。I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;本身这种“社会<br />
学的”定义似乎是没有用的。<br />
不久以前，I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;被定义为I&nbsp;P&nbsp;网络连通性(&nbsp;I&nbsp;P&nbsp;和I&nbsp;C&nbsp;M&nbsp;P&nbsp;过去是、现在仍然是<br />
唯一“需要”的I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;协议)。如果我能p&nbsp;i&nbsp;n&nbsp;g&nbsp;你，你能p&nbsp;i&nbsp;n&nbsp;g&nbsp;我，那么我们都在I&nbsp;n&nbsp;<br />
t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;上，同时，I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;令人满意的工作定义可构想为I&nbsp;P&nbsp;对话系统的接近可过渡<br />
的最后结果。这样的I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;模型是简单的、统一标准的，或许最重要的是可测试的。<br />
I&nbsp;P&nbsp;网络连通性模型可清楚地判别系统是否“在I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;上”。<br />
随着I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的增长及其使用的技术已广泛的被商界接受，对一个系统“在I&nbsp;n&nbsp;t&nbsp;e&nbsp;<br />
r&nbsp;n&nbsp;e&nbsp;t&nbsp;上”的含义已经有所改变，应当包括：<br />
·&nbsp;具有部分I&nbsp;P&nbsp;网络连通性，受限于策略过滤器的任何系统。<br />
·&nbsp;运行T&nbsp;C&nbsp;P&nbsp;/&nbsp;I&nbsp;P&nbsp;协议集，不管是否从Internet&nbsp;的其他部分实际上可接入的任何系统。<br />
·&nbsp;能交换RFC&nbsp;822&nbsp;邮件，无需邮件网关的干预或邮件对象的转换的任何系统。<br />
·&nbsp;有e&nbsp;-&nbsp;m&nbsp;a&nbsp;i&nbsp;l&nbsp;连通到I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;，不论是否需要邮件网关或邮件对象转换的任何<br />
系统。<br />
对I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的这些定义仍是基于原始的网络连通性概念，只是“栈的向上移动”。<br />
在此，基于有区别的统一概念，提出I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的新定义：<br />
·&nbsp;“老的”I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;概念：以I&nbsp;P&nbsp;为基础,组织的原则是I&nbsp;P&nbsp;地址，也就是一个公<br />
共的网络地址空间。<br />
·&nbsp;“新的”I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;概念：以应用为基础,组织的原则是域名系统和目录，也就是<br />
一个公共的(虽然必定是多形式的)应用名字空间。<br />
这就告诉我们，“连接的状况”概念传统上是与I&nbsp;P&nbsp;地址(&nbsp;通过网络号)紧密联系在一起<br />
的，应该代之以与存放在分布式I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;目录中的名字和相关标识信息联系在一起的。<br />
I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;基于名字的定义意味着一个大得多的I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;社区，以及一个更为动态(&nbsp;和<br />
不可预测的)&nbsp;可运转的I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;。对I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;体系结构的争论，是基于在很宽的范围<br />
内对未来可能发展的适应性，而不局限于原来的设想。<br />
3．2&nbsp;基于过程的多协议Internet&nbsp;模型<br />
与其制订一个特殊的“多协议I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;”，接受一个预先确定特定协议数量的体系<br />
结构，倒不如建议采用一个面向过程的I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;模型，它可以适应不同的协议体系结构，<br />
符合传统的“能工作”原则。<br />
面向过程的I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;模型，作为一个基本前提，主张不包括稳定状态“多协议I&nbsp;n&nbsp;t&nbsp;e&nbsp;<br />
r&nbsp;n&nbsp;e&nbsp;t&nbsp;”的体系结构。最基本的驱动I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;进化的力量不是推动它朝多协议多样化发<br />
展(虽然事实上永远不可能达到)。要说明的是I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;发展的趋势是向同质性进化，作<br />
为最“热动稳定”状态，<br />
下面描述一个新的基于过程的Internet&nbsp;体系结构的四个部分：<br />
第1&nbsp;部分：核心I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;体系结构。<br />
这是传统的基于T&nbsp;C&nbsp;P&nbsp;/&nbsp;I&nbsp;P&nbsp;的体系结构。是I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;进化的“磁铁中心”，公认(&nbsp;1&nbsp;)<br />
同质性仍然是处理互连网多样化的最好方法；(&nbsp;2&nbsp;)&nbsp;I&nbsp;P&nbsp;网络连通性仍然是I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的最<br />
佳基本模型(在全球I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;中，不论I&nbsp;P&nbsp;无处不在的实际状态是否是一个现实)。<br />
一开始，I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;体系结构只包括第1&nbsp;部分。然而I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的成功在于它超出<br />
了原来的设想。无处不在和高度统一，对极大地丰富Internet&nbsp;“基因库”作出了贡献。<br />
新I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;体系结构增加的两个部分扩大了I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的广度和深度。<br />
第2&nbsp;部分：链路共享。<br />
传输媒体、网络接口及低层链路协议等物理资源是由多个非交互的协议集所共享的。这<br />
部分体系结构被认为是必须且适合于共存的，但不涉及到互操作性；被称为ships&nbsp;in&nbsp;the&nbsp;night&nbsp;<br />
(&nbsp;S&nbsp;.&nbsp;I&nbsp;.&nbsp;N&nbsp;.&nbsp;)。<br />
当然，共存的协议集实际上不是纯粹孤立的；在真正的I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;系统中，S&nbsp;.&nbsp;I&nbsp;.&nbsp;N&nbsp;.<br />
会引发管理、无冲突、协调和公平性等议题。<br />
第3&nbsp;部分：应用互操作性。<br />
虽然缺乏互连普遍性(即“基础栈”的互操作性)，但只要在I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;系统的不相邻<br />
社区之间安排应用的基本语义能以传递信息，仍然可能获得普遍的应用功能。这可以通过应<br />
用转发站，或者由用户代理，对不同的由共同语义表示的应用服务提供一致的虚访问方法来<br />
完成。<br />
体系结构的这一部分，强调了I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的最终作用是作为应用间的通信基础，而不<br />
是它本身的结局。在一定程度上，使一个应用群体和他们的用户能够从一个基础协议集过渡<br />
到另外一个，而不会发生难以接受的功能丢失，这可被称为“过渡起动器”。<br />
将第2&nbsp;和第3&nbsp;部分加入到原始的I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;体系结构中，充其量是一件好坏半掺的<br />
事情。虽然大大增加了I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的广度和I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;社区的规模，但也会引入复杂性、<br />
价格和管理等重大问题，同时还会出现功能的丢失(特别对第3&nbsp;部分而言)。第2&nbsp;和第3&nbsp;部<br />
分不可避免地背离了第1&nbsp;部分所表示的同质性，但这是我们所不希望的。为了扩展I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;<br />
e&nbsp;t&nbsp;广度，某些功能丢失了，还要承受附加的系统复杂性和成本。而在一个完美的世界中，<br />
应该不需付出这些代价就可换得I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的进化和扩展。<br />
目前有一种趋势，I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的进化倾向于第1&nbsp;部分表示的同质性体系结构，而不是<br />
第2&nbsp;和第3部分表示的折衷的体系结构。第4&nbsp;部分表达了这种趋势。<br />
第4&nbsp;部分：混合/集成。<br />
第4&nbsp;部分认识到可以从不同的I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;协议体系结构中集成类似的元素以形成混<br />
合体，以便减少I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;系统的多样化和复杂性。同时也认识到可以影响已存在的I&nbsp;n&nbsp;t&nbsp;e&nbsp;<br />
r&nbsp;n&nbsp;e&nbsp;t&nbsp;基础设施以便I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;吸收“新东西”，并把已建立的I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的测试、评价<br />
和应用实践融入到“新东西”中去。<br />
本部分表达了I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的发展趋势，作为一个系统，试图回到原来由第1&nbsp;部分统一<br />
的体系结构所表示的“美好的状态”。虽然I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;将永远不会在未来的任意时刻回到<br />
统一的状态，但这是一个对I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;进化起作用的力量。<br />
按照这个动态的进程模型，在T&nbsp;C&nbsp;P&nbsp;/&nbsp;I&nbsp;P&nbsp;栈上通过RFC&nbsp;1006&nbsp;运行X&nbsp;.&nbsp;4&nbsp;0&nbsp;0&nbsp;邮件，集成<br />
I&nbsp;S&nbsp;-&nbsp;I&nbsp;S&nbsp;选路，传送网关以及对I&nbsp;P&nbsp;和C&nbsp;L&nbsp;N&nbsp;P&nbsp;协议的单个共同后继协议的开发，都是很好<br />
的例子。在第1&nbsp;部分主张的“磁场”影响下，参照第4&nbsp;部分混合的动态，它们显示了背离<br />
第2&nbsp;和第3&nbsp;部分的非统一性，而走向更好的同质性。<br />
4．安全体系结构<br />
4．1&nbsp;哲学准则<br />
I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;安全性体系结构开发的主题是简单、可测试性、可信度、采用的技术和安<br />
全周界<br />
标识。<br />
·&nbsp;安全性比协议和密码保密措施要求更多。<br />
·&nbsp;安全性体系结构和策略应该简单且容易理解。复杂性会引起错误理解和不良的实现。<br />
·&nbsp;实现应该是可测试的，以便确定是否满足了策略。<br />
·我们认为使任何安全性体系结构运行的硬件、软件和人是可以信任的。假设安全性策<br />
略实施的技术设备至少和个人计算机及工作站具有同样的能力。我们不需要能力差的部件受<br />
到自保护(但可能会用诸如链路级密码编码设备进行外部补救)。<br />
·&nbsp;最后，认定安全性有效保护的周界是最根本的。<br />
4．2&nbsp;安全性周界<br />
有4&nbsp;种可能的安全性周界：链路级、网络/子网级、主机级和进程/应用级。每种施加不<br />
同的需求，能够接纳不同的技术，并能对何种系统部件可以被认为是有效的做出不同的假设。<br />
隐私强化邮件是一种进程级安全系统的例子，另一个例子是为S&nbsp;N&nbsp;M&nbsp;P&nbsp;提供身份验证<br />
和保密。主机级安全性一般是在主计算机的通信口上用一个外部安全机制。网络或子网安全<br />
性则应用从子网到“外部”的网关/路由器上的外部安全性能力。链路级安全性采用传统的<br />
点对点或媒体级(如以太网)密码编码机制。<br />
关于网络/子网安全性保护存在许多开放的问题，不单是主机级(端/端)安全性方法与网<br />
络/子网级安全性方法之间存在潜在的不匹配，而且网络级保护也不能处理安全性周界内出<br />
现的威胁。<br />
在进程级采用保护，假定基础的程序和操作系统机制是可以信任的，不会由于使用了相<br />
应的安全机制而妨碍应用程序。当安全性周界在系统体系结构中向下移至链路级，就要做有<br />
关安全威胁的许多假设，以便得出这样的论点，就是在一个特定周界的实施是有效的。例如，<br />
如果只有链路级使用加密编码，我们可以假设来自外部的攻击，只通过通信线，那么主机、<br />
交换机和网关实际上是被保护的，同时人和所有部件中的软件都是可以信任的。<br />
4．3&nbsp;期望的安全性服务<br />
如果在系统的应用级和较低级实现选定和非选定的接入控制，则需要可验证的正规的名<br />
字。除此之外，还需要实施完整性(&nbsp;防修改、防欺骗、防重放)，保密性和防止否认服务。<br />
在某些情况下，可能还需要防止报文传输的否认或防止秘密信道。<br />
已经有一些标准部件用以建立I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;安全系统。可以采用密码算法(如D&nbsp;E&nbsp;S&nbsp;、R&nbsp;<br />
S&nbsp;A&nbsp;、E&nbsp;lG&nbsp;a&nbsp;m&nbsp;a&nbsp;1&nbsp;和其他可能的公共密钥和对称密钥算法)，也可以采用如M&nbsp;D&nbsp;2&nbsp;和M&nbsp;D&nbsp;5&nbsp;<br />
的散列函数。<br />
根据O&nbsp;S&nbsp;I&nbsp;的意义需要可鉴别的名字，并且为了便于人们了解标识符和目录服务，非常<br />
需要一个指派标识符以及广泛使用目录服务的基础设施。把公共密钥与可鉴别的名字捆绑在<br />
一起，并把能力和许可与可鉴别的名字捆绑在一起的认证概念，具有很多优点。<br />
在路由器/网关级，采用地址和协议过滤器及其他配置控制，能有助于形成一个安全性<br />
系统。把建议的O&nbsp;S&nbsp;I&nbsp;安全性协议3&nbsp;(&nbsp;S&nbsp;P&nbsp;3&nbsp;)和安全性协议4&nbsp;(&nbsp;S&nbsp;P&nbsp;4&nbsp;)作为I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;安全性<br />
体系结构的可能要素,&nbsp;要给予认真的考虑。<br />
最后，必须看到，在未实施安全存储的P&nbsp;C&nbsp;或笔记本电脑系统上，安全地存储秘密信<br />
息(诸如一个公共密钥对的秘密部分)，还没有好的解决方案。<br />
4．4&nbsp;建议的行动<br />
建议采取下列行动：<br />
1：安全性参考模型。<br />
需要建立一个I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的安全性参考模型，并迅速地得到开发。该模型应该建<br />
立目标周界，并用文件形式建立安全性体系结构目标。<br />
2：隐私强化邮件(&nbsp;P&nbsp;E&nbsp;M&nbsp;)。<br />
对于隐私强化邮件，最关键的步骤看来是建立：(&nbsp;1&nbsp;)认证生成和管理基础设施；(&nbsp;2&nbsp;)&nbsp;<br />
X&nbsp;.&nbsp;5&nbsp;0&nbsp;0目录服务以提供通过可鉴别的名字访问公共密钥。在推广使用本系统时，还需<br />
要对专利方面的限制和出口限制给予认真关注。<br />
3：分布式系统安全性。<br />
对分布式系统的应用，不论是简单的客户机/服务器系统还是复杂的分布式计算环<br />
境，都需要检查安全设施。例如，对授予与可鉴别的名字捆绑在一起的许可/能力的认<br />
证的实用性应受到检查。<br />
4：主机级安全性。<br />
对面向主机的安全性，应当对S&nbsp;P&nbsp;4&nbsp;予以评估，S&nbsp;P&nbsp;3&nbsp;也在考虑之列。<br />
5：应用级安全性。<br />
不论是为了服务的直接实用性(如P&nbsp;E&nbsp;M&nbsp;.&nbsp;S&nbsp;N&nbsp;M&nbsp;P&nbsp;身份验证)，还是为了获得能够形成I&nbsp;<br />
n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t安全性体系结构精华的有价值的实际经验，都应该实施应用级安全性服务。<br />
5．业务流控制与状态<br />
目前的I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;平等地处理所有的I&nbsp;P&nbsp;数据报。每个数据报对同一连接、同一<br />
应用、同一应用类别、同一用户类，不论它和其他包有任何关系，都是独立地转发的。<br />
虽然在I&nbsp;P&nbsp;头中定义了服务类型位和优先权位，但通常都没有实施，事实上还不清楚如<br />
何去实施它们。<br />
众所周知，未来的I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;需要支持尽力而为所不能满足的大量应用，如电视<br />
会议的包图像和语音。为了处理实时业务流，要求在路由器中有以附加的状态来控制的<br />
业务流控制机制。<br />
5．1&nbsp;假设和原则<br />
·&nbsp;假设：I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;需要为业务流的特定子集支持性能保证。<br />
遗憾的是对术语“性能”、“保证”或“子集”，远不能给出精确的定义。研究仍需<br />
要对这些问题做出回答。<br />
·&nbsp;默认的服务将继续是当前无服务保证的“尽力而为”数据报分发服务。<br />
·&nbsp;路由器机制可分割为两部分：(&nbsp;1&nbsp;)转发路径；(&nbsp;2&nbsp;)发生在后台的控制计算(如选路)。<br />
转发路径必须高度优化，有时由硬件辅助完成，因此相对而言很昂贵，而且难于变<br />
更。运行在转发路径上的业务流控制机制，是由发生在后台的选路和资源控制计算创建<br />
的状态来控制的。在改变路由器的转发路径时，最多起动一次，所以最好一开始就使它<br />
正确。<br />
·&nbsp;新的扩展必须运行在一个高度异质的环境中。在该环境中，某些部分将永远不支持<br />
保证。对一个路径上的某些段(如高速局域网)，即使当显式资源预留不用时，“超配给”<br />
(即超过容量)也会对实时业务给予满足要求的服务。<br />
·&nbsp;组播分发或许是最根本的。<br />
5．2&nbsp;技术议题<br />
需要解决的技术议题，包括：<br />
(1)&nbsp;资源建立。<br />
为了支持实时业务流，从源到目的地的路由上的路由器中需要预留资源。该新的路<br />
由器状态应该是“硬”的(如建立连接)还是“软”的(即缓冲的状态)？<br />
(2)&nbsp;资源捆绑与路由捆绑。<br />
选择从源到目的地的一条路由传统上是由一个动态选路协议来完成的。资源捆绑和<br />
选路可以重叠在单个复合进程中，或者也可以基本上独立地完成。这就要求在复杂性和<br />
效率之间折衷考虑。<br />
(3)&nbsp;另一组播模型。<br />
I&nbsp;P&nbsp;组播用一个逻辑寻址模型，在该模型中，目标地址本身与一个组联系。在S&nbsp;T-&nbsp;2&nbsp;<br />
中，一个组播会话中的每个主机在它的建立包中包括一系列显式目标地址。每一种方法<br />
都有优点和缺点。当前还不十分清楚对n&nbsp;路电视会议而言，哪个会占优势。<br />
(4)&nbsp;资源建立与行政管理域间的选路。<br />
不论倾向于哪种资源保证，必须保持穿越一条任意的端对端并包括多个A&nbsp;D&nbsp;的路<br />
由。因此，任何资源建立机制必须与包含在IDPR&nbsp;中的路由建立机制平稳地配合。<br />
(5)&nbsp;计费。<br />
资源保证子集(“类别”)可以是自然的计费单位。<br />
5．3&nbsp;建议的行动<br />
此处所谓的行动是指对上面列出的技术议题的进一步研究，紧随其后的是相应协议<br />
的开发和标准化。D&nbsp;A&nbsp;RT&nbsp;n&nbsp;e&nbsp;t&nbsp;，D&nbsp;A&nbsp;R&nbsp;PA&nbsp;研究测试床网络，在本研究中将起重要作用。<br />
6．现代应用<br />
人们不禁要问“我们想要何种基于网络的应用，为什么现在还没有？”很容易列出<br />
一张潜在应用的大表，其中许多都将基于客户机/服务器模型。然而问题中更有意思的<br />
是：“为什么还没有人来做呢？”回答是：方便应用程序编写的工具尚不存在。<br />
首先，对于许多将用于穿越网络的数据术语，需要一套公共交换格式。定义了公共<br />
交换格式后，还需便于开发应用程序移动数据的工具。<br />
6．1&nbsp;公共交换格式<br />
为使信息有意义，应用程序必须知道它们要交换的信息的格式。考虑下面的格式类<br />
型：<br />
(1)&nbsp;文本—文本是最标准的，但今天的国际性I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;还需要有除了USASCII&nbsp;<br />
以外的字符集。<br />
(2)&nbsp;图像—当进入“多媒体时代”，图像变得越来越重要，但需要对如何在信息包<br />
中表示图像信息取得一致。<br />
(3)&nbsp;图形—和图像一样，矢量图形信息需要一个共同的定义。有了定义的格式才能<br />
交换类似结构蓝图的细节。<br />
(4)&nbsp;视频—先要知道从网络上来的视频信息的格式，才能在工作站上运行视频窗<br />
口。<br />
(5)&nbsp;模拟音频—当然，人们需要的是伴有声音的视频，但这样的格式应该可以表示<br />
所有类型的模拟信号。<br />
(6)&nbsp;显示—我们打开工作站上的窗口，并打开另一个人的工作站上的窗口，给它显<br />
示与研究项目有关的某些数据，所以需要一个通用的窗口显示格式。<br />
(7)&nbsp;数据对象—对进程间的通信，类似整数、实数、串等数据的格式需要一致。<br />
这些格式的相当一部分正在由几个标准组定义。我们需要为Internet&nbsp;的每一类取得<br />
一种一致的格式。<br />
6．2&nbsp;数据交换方法<br />
应用程序将需要下列的数据交换方法：<br />
(1)&nbsp;存储转发。<br />
不是每个人所有时间都在网上。需要一个标准手段向有时连在网上的主机提供信息<br />
流，也就是需要一个通用的存储转发服务。组播也应包括在这一服务中。<br />
(2)&nbsp;全球文件系统。<br />
在网上，大部分数据访问可以被分解成单个文件访问。如果有一个真正的全球文件<br />
系统，那就能访问I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;上的任何文件(假定被许可的话)。你曾经需要用F&nbsp;T&nbsp;P&nbsp;<br />
吗？<br />
(3)&nbsp;进程间通信。<br />
对一个真正的分布式计算环境，需要通过一些手段使进程在网络上能通过一个标准<br />
方法来交换数据。这样的需求包括R&nbsp;P&nbsp;C&nbsp;、A&nbsp;P&nbsp;I&nbsp;等。<br />
(4)&nbsp;数据广播。<br />
许多应用程序要求发送同样的信息到其他许多主机，因此需要一个标准且高效的方<br />
法来完成这功能。<br />
(5)&nbsp;数据库访问。<br />
对于好的信息交换，需要为访问数据库指定一个标准方法。全球文件系统能使你获<br />
得数据，但数据库访问方法将告诉你有关它的结构和内容。<br />
上述许多项正在由其他组织着手拟订，但对Internet&nbsp;的互操作性，还需要在方法上<br />
取得一致。<br />
最后，现代应用需对本文中两个较早领域的问题寻找解决方案。从业务流控制与状<br />
态领域而言，应用需要发送实时数据的能力。这意味着数据能在一个确定的时间范围内<br />
分发。从安全性领域而言，应用也需要全球身份验证和访问控制系统。今天的Internet<br />
由于缺乏可信度和安全，失去了许多有用的应用。这要求在明天的应用中得到解决。<br />
7．参考资料<br />
[1]&nbsp;&nbsp;Cerf,&nbsp;V.&nbsp;and&nbsp;R.&nbsp;Kahn,&nbsp;"A&nbsp;Protocol&nbsp;for&nbsp;Packet&nbsp;Network<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Intercommunication,"&nbsp;IEEE&nbsp;Transactions&nbsp;on&nbsp;Communication,&nbsp;May<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1974.<br />
<br />
&nbsp;&nbsp;&nbsp;[2]&nbsp;&nbsp;Postel,&nbsp;J.,&nbsp;Sunshine,&nbsp;C.,&nbsp;and&nbsp;D.&nbsp;Cohen,&nbsp;"The&nbsp;ARPA&nbsp;Internet<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Protocol,"&nbsp;Computer&nbsp;Networks,&nbsp;Vol.&nbsp;5,&nbsp;No.&nbsp;4,&nbsp;July&nbsp;1981.<br />
<br />
&nbsp;&nbsp;&nbsp;[3]&nbsp;&nbsp;Leiner,&nbsp;B.,&nbsp;Postel,&nbsp;J.,&nbsp;Cole,&nbsp;R.,&nbsp;and&nbsp;D.&nbsp;Mills,&nbsp;"The&nbsp;DARPA<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Internet&nbsp;Protocol&nbsp;Suite,"&nbsp;Proceedings&nbsp;INFOCOM&nbsp;85,&nbsp;IEEE,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Washington&nbsp;DC,&nbsp;March&nbsp;1985.&nbsp;&nbsp;Also&nbsp;in:&nbsp;IEEE&nbsp;Communications<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Magazine,&nbsp;March&nbsp;1985.<br />
<br />
&nbsp;&nbsp;&nbsp;[4]&nbsp;&nbsp;Clark,&nbsp;D.,&nbsp;"The&nbsp;Design&nbsp;Philosophy&nbsp;of&nbsp;the&nbsp;DARPA&nbsp;Internet<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Protocols",&nbsp;Proceedings&nbsp;ACM&nbsp;SIGCOMM&nbsp;'88,&nbsp;Stanford,&nbsp;California,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;August&nbsp;1988.<br />
<br />
&nbsp;&nbsp;&nbsp;[5]&nbsp;&nbsp;Mogul,&nbsp;J.,&nbsp;and&nbsp;J.&nbsp;Postel,&nbsp;"Internet&nbsp;Standard&nbsp;Subnetting<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Procedure",&nbsp;RFC&nbsp;950,&nbsp;USC/Information&nbsp;Sciences&nbsp;Institute,&nbsp;August<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1985.<br />
<br />
&nbsp;&nbsp;&nbsp;[6]&nbsp;&nbsp;Mockapetris,&nbsp;P.,&nbsp;"Domain&nbsp;Names&nbsp;-&nbsp;Concepts&nbsp;and&nbsp;Facilities",&nbsp;RFC<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1034,&nbsp;USC/Information&nbsp;Sciences&nbsp;Institute,&nbsp;November&nbsp;1987.<br />
<br />
&nbsp;&nbsp;&nbsp;[7]&nbsp;&nbsp;Deering,&nbsp;S.,&nbsp;"Host&nbsp;Extensions&nbsp;for&nbsp;IP&nbsp;Multicasting",&nbsp;RFC&nbsp;1112,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Stanford&nbsp;University,&nbsp;August&nbsp;1989.<br />
<br />
&nbsp;&nbsp;&nbsp;[8]&nbsp;&nbsp;"Proceedings&nbsp;of&nbsp;the&nbsp;Twenty-First&nbsp;Internet&nbsp;Engineering&nbsp;Task<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Force",&nbsp;Bell-South,&nbsp;Atlanta,&nbsp;July&nbsp;29&nbsp;-&nbsp;August&nbsp;2,&nbsp;1991.<br />
附录A&nbsp;&nbsp;设定步骤<br />
幻灯片1<br />
————————————————————————————<br />
I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;向何处去？<br />
体系结构的选择<br />
IAB/IESG&nbsp;--&nbsp;1990&nbsp;年1&nbsp;月<br />
David&nbsp;D.&nbsp;Clark<br />
——————————————————————————————<br />
幻灯片2<br />
————————————————————————————<br />
<br />
设定讨论的课题<br />
目的：<br />
·&nbsp;为I&nbsp;A&nbsp;B&nbsp;、I&nbsp;E&nbsp;S&nbsp;G&nbsp;及I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;社区建立一个理解的共同框架。<br />
·&nbsp;了解要解决的问题集<br />
·&nbsp;了解为我们敞开的解决方案的范围<br />
·&nbsp;得出某些结论或“总结论”。<br />
————————————————————————————<br />
幻灯片3<br />
————————————————————————————<br />
若干声明—我的见解<br />
两个不同的目标：<br />
·&nbsp;使建立I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;成为可能。<br />
·&nbsp;定义I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的一套协议。<br />
声明：这些目标有非常不同的含义。协议只不过是一种手段，然而是一种有力的手段。<br />
声明：如果I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;获得成功及增长，就将需要专门的设计。这就需要至少另一个十年<br />
的<br />
继续努力。<br />
声明：不加控制的增长将会导致混乱。<br />
声明：从根本上解决问题看来是走向成功的唯一方法。从上向下命令是无力的。<br />
————————————————————————————<br />
幻灯片4<br />
————————————————————————————<br />
报告提纲<br />
(1)	问题空间和解决方案空间。<br />
(2)	一系列专门问题—供讨论用。<br />
(3)	回到顶层问题—供讨论用。<br />
(4)	行动计划—供总体讨论用。<br />
设法从技术研究中将功能需求分离出来。<br />
了解我们是如何受到问题空间和解决方案空间的限制。<br />
是否体系结构除了协议以外别无其他？<br />
————————————————————————————<br />
幻灯片5<br />
————————————————————————————<br />
问题空间是什么？<br />
选路与寻址：<br />
大到什么程度，采用何种拓扑结构及选路模型？<br />
逐渐变大：<br />
用户服务；主机和网络采用何种技术？<br />
I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的舍弃：<br />
计费、控制的使用和修复故障。<br />
新服务：<br />
视频？事务处理？分布计算？<br />
安全性：<br />
终端节点还是网络？路由器还是转发器？<br />
————————————————————————————<br />
幻灯片6<br />
————————————————————————————<br />
限定解决方案的空间<br />
从当前的状态能迁移到多远？<br />
·&nbsp;我们能改变I&nbsp;P&nbsp;头吗(除了O&nbsp;S&nbsp;I&nbsp;外)？<br />
·&nbsp;我们能以命令方式改变主机的需求吗？<br />
·&nbsp;我们能管理一个长期迁移目标吗？—始终如一的方向与多种多样的目标、资金来源。<br />
我们能接受网络级的连通性吗？<br />
·&nbsp;转发将来会被抛弃吗？<br />
·&nbsp;安全性以及变换是一个关键议题。<br />
·&nbsp;需要一个基于转发的体系结构吗？<br />
如何能够和必须管理I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;？<br />
·&nbsp;我们能管理或者限制网络的连通性吗？<br />
研究开发什么协议？一个还是多个？<br />
————————————————————————————<br />
幻灯片7<br />
————————————————————————————<br />
多协议I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t<br />
“把问题想得难一点对人类有好处。”<br />
我们是迁移、互操作还是容忍多协议？<br />
·&nbsp;不是所有的协议集在同一时期都有同样的功能范围。<br />
·&nbsp;Internet&nbsp;需要特定的功能。<br />
声明：基本的矛盾(非宗教性的或恶意的)：<br />
·&nbsp;满足I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;积极进取的需求。<br />
·&nbsp;处理O&nbsp;S&nbsp;I&nbsp;迁移。<br />
结论：一种协议必定为主导，其他协议必定为辅助。我们什么时候“切换”到O&nbsp;S&nbsp;I&nbsp;？<br />
请考察本文下面的每张幻灯片。<br />
————————————————————————————<br />
<br />
幻灯片8<br />
————————————————————————————<br />
选路和寻址<br />
什么是I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的目标规模？<br />
·&nbsp;如何将地址和路由联系起来？<br />
·&nbsp;拓扑模型是什么？<br />
·&nbsp;什么是可能的解决方案？<br />
选路要求什么样的策略范围？<br />
·&nbsp;BGP&nbsp;和I&nbsp;D&nbsp;R&nbsp;P&nbsp;是两个解答。问题在那儿？<br />
·&nbsp;固定类别或可变路径？<br />
·&nbsp;源控制的选路是最低要求。<br />
如何无缝地支持移动主机？<br />
·&nbsp;新地址类，再捆绑到本地地址，用D&nbsp;N&nbsp;S&nbsp;吗？<br />
是否要推动I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;组播？<br />
————————————————————————————<br />
幻灯片9<br />
————————————————————————————<br />
逐渐变大—一个老题目<br />
(寻址与选路在前一张幻灯片上。)<br />
在下一个十年中需要什么样的用户服务？<br />
·&nbsp;我们能否构筑一个计划？<br />
·&nbsp;需要体系结构方面的改变吗？<br />
是否有更好的处理速度、包大小等范围的需求。<br />
·&nbsp;是否取消分段策略？<br />
我们将支持什么主机范围(如UNIX&nbsp;环境)？<br />
————————————————————————————<br />
幻灯片10<br />
————————————————————————————<br />
处理舍弃<br />
I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;是由独立管理和控制的部分组成的。<br />
为网络收费需要什么支持？<br />
·&nbsp;体系结构不隐含按容量收费、重记帐和为丢失包付费。<br />
·&nbsp;是否需要控制以提供记帐标识符或选路？<br />
需求：必须支持有控制共享的链路。(简单的形式是基于链路标识符的类别)。<br />
·&nbsp;如何一般化？<br />
对故障隔离是否更加需要？(我投赞成票！)<br />
·&nbsp;我们如何能找到可以交谈的经理们？<br />
·&nbsp;我们需要主机上的服务吗？<br />
————————————————————————————<br />
幻灯片11<br />
————————————————————————————<br />
新服务<br />
要支持视频和音频吗？是实时吗？百分比多少？<br />
·&nbsp;需要计划从研究结果得到什么，什么样的质量？<br />
·&nbsp;向供货商交底的目标日期。<br />
我们能“更好”地支持事务处理吗？<br />
·&nbsp;TCP&nbsp;能做吗？V&nbsp;M&nbsp;T&nbsp;P&nbsp;呢？介绍呢，还是刹车？<br />
哪些象样的应用即将出笼？<br />
·&nbsp;分布计算—它真的将发生吗？<br />
·&nbsp;信息网络技术吗？<br />
————————————————————————————<br />
幻灯片12<br />
————————————————————————————<br />
安全性<br />
能坚持说终端节点是唯一防线吗？<br />
·&nbsp;在网络内部我们能做什么？<br />
·&nbsp;能要求主机做什么？<br />
能容忍转发器或安排它们的结构吗？<br />
能找到一个更好的方法来构筑安全性边界吗？<br />
需要全球身份验证吗？<br />
有新的主机需求吗？<br />
·&nbsp;登录。<br />
·&nbsp;身份验证。<br />
·&nbsp;管理接口。电话号码或访问点。<br />
————————————————————————————<br />
附录B&nbsp;&nbsp;组成员<br />
第一组：选路与寻址<br />
Dave&nbsp;Clark,&nbsp;MIT&nbsp;&nbsp;[Chair]<br />
Hans-Werner&nbsp;Braun,&nbsp;SDSC<br />
Noel&nbsp;Chiappa,&nbsp;Consultant<br />
Deborah&nbsp;Estrin,&nbsp;USC<br />
Phill&nbsp;Gross,&nbsp;CNRI<br />
Bob&nbsp;Hinden,&nbsp;BBN<br />
Van&nbsp;Jacobson,&nbsp;LBL<br />
Tony&nbsp;Lauck,&nbsp;DEC.<br />
<br />
第二组：多协议体系结构<br />
Lyman&nbsp;Chapin,&nbsp;BBN&nbsp;&nbsp;[Chair]<br />
Ross&nbsp;Callon,&nbsp;DEC<br />
Dave&nbsp;Crocker,&nbsp;DEC<br />
Christian&nbsp;Huitema,&nbsp;INRIA<br />
Barry&nbsp;Leiner,<br />
Jon&nbsp;Postel,&nbsp;ISI<br />
第三组：安全性体系结构<br />
Vint&nbsp;Cerf,&nbsp;CNRI&nbsp;&nbsp;[Chair]<br />
Steve&nbsp;Crocker,&nbsp;TIS<br />
Steve&nbsp;Kent,&nbsp;BBN<br />
Paul&nbsp;Mockapetris,&nbsp;DARPA<br />
<br />
第四组：业务流控制与状态<br />
Robert&nbsp;Braden,&nbsp;ISI&nbsp;&nbsp;[Chair]<br />
Chuck&nbsp;Davin,&nbsp;&nbsp;MIT<br />
Dave&nbsp;Mills,&nbsp;University&nbsp;of&nbsp;Delaware<br />
Claudio&nbsp;Topolcic,&nbsp;CNRI<br />
<br />
第五组：现代应用<br />
Russ&nbsp;Hobby,&nbsp;UCDavis&nbsp;&nbsp;[Chair]<br />
Dave&nbsp;Borman,&nbsp;Cray&nbsp;Research<br />
Cliff&nbsp;Lynch,&nbsp;University&nbsp;of&nbsp;California<br />
Joyce&nbsp;K.&nbsp;Reynolds,&nbsp;ISI<br />
Bruce&nbsp;Schatz,&nbsp;University&nbsp;of&nbsp;Arizona<br />
Mike&nbsp;Schwartz,&nbsp;University&nbsp;of&nbsp;Colorado<br />
Greg&nbsp;Vaudreuil,&nbsp;CNRI.<br />
<br />
安全问题<br />
在本文档中不讨论安全问题。<br />
作者联系方法<br />
David&nbsp;D.&nbsp;Clark<br />
&nbsp;&nbsp;&nbsp;Massachusetts&nbsp;Institute&nbsp;of&nbsp;Technology<br />
&nbsp;&nbsp;&nbsp;Laboratory&nbsp;for&nbsp;Computer&nbsp;Science<br />
&nbsp;&nbsp;&nbsp;545&nbsp;Main&nbsp;Street<br />
&nbsp;&nbsp;&nbsp;Cambridge,&nbsp;MA&nbsp;02139<br />
<br />
&nbsp;&nbsp;&nbsp;Phone:&nbsp;(617)&nbsp;253-6003<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;ddc@LCS.MIT.EDU<br />
<br />
&nbsp;&nbsp;&nbsp;Vinton&nbsp;G.&nbsp;Cerf<br />
&nbsp;&nbsp;&nbsp;Corporation&nbsp;for&nbsp;National&nbsp;Research&nbsp;Initiatives<br />
&nbsp;&nbsp;&nbsp;1895&nbsp;Preston&nbsp;White&nbsp;Drive,&nbsp;Suite&nbsp;100<br />
&nbsp;&nbsp;&nbsp;Reston,&nbsp;VA&nbsp;22091<br />
<br />
&nbsp;&nbsp;&nbsp;Phone:&nbsp;(703)&nbsp;620-8990<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;vcerf@nri.reston.va.us<br />
<br />
&nbsp;&nbsp;&nbsp;Lyman&nbsp;A.&nbsp;Chapin<br />
&nbsp;&nbsp;&nbsp;Bolt,&nbsp;Beranek&nbsp;&&nbsp;Newman<br />
&nbsp;&nbsp;&nbsp;Mail&nbsp;Stop&nbsp;20/5b<br />
&nbsp;&nbsp;&nbsp;150&nbsp;Cambridge&nbsp;Park&nbsp;Drive<br />
&nbsp;&nbsp;&nbsp;Cambridge,&nbsp;MA&nbsp;02140<br />
<br />
&nbsp;&nbsp;&nbsp;Phone:&nbsp;(617)&nbsp;873-3133<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;lyman@BBN.COM<br />
<br />
&nbsp;&nbsp;&nbsp;Robert&nbsp;Braden<br />
&nbsp;&nbsp;&nbsp;USC/Information&nbsp;Sciences&nbsp;Institute<br />
&nbsp;&nbsp;&nbsp;4676&nbsp;Admiralty&nbsp;Way<br />
&nbsp;&nbsp;&nbsp;Marina&nbsp;del&nbsp;Rey,&nbsp;CA&nbsp;90292<br />
<br />
&nbsp;&nbsp;&nbsp;Phone:&nbsp;(310)&nbsp;822-1511<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;braden@isi.edu<br />
<br />
&nbsp;&nbsp;&nbsp;Russell&nbsp;Hobby<br />
&nbsp;&nbsp;&nbsp;University&nbsp;of&nbsp;California<br />
&nbsp;&nbsp;&nbsp;Computing&nbsp;Services<br />
&nbsp;&nbsp;&nbsp;Davis,&nbsp;CA&nbsp;95616<br />
<br />
&nbsp;&nbsp;&nbsp;Phone:&nbsp;(916)&nbsp;752-0236<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;rdhobby@ucdavis.edu<br />
<br />
RFC1287:&nbsp;Towards&nbsp;the&nbsp;Future&nbsp;Internet&nbsp;Architecture&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;未来的Internet&nbsp;体系结构<br />
<br />
<br />
1<br />
China-pub&nbsp;RFC中文翻译计划<br />