中文RFC文档完整版

组织：中国互动出版网（http://www.china-pub.com/） RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm） E-mail：ouyang@china-pub.com 译者：15222775@61.(15222775@61. hbzzx2001@yahoo.com.cn ) 译文发布时间：2002-1-15 版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须 保留本文档的翻译及版权信息。 RFC 827 ............................ 外部网关协议( EGP) ................................Eric C. Rosen Bolt Beranek and Newman Inc. October 1982 它被用于为网关建立一个标准，能够用它对互相猜疑的网关进行处理。 本文档是该标准的一个草稿。 您的意见我们热烈欢迎。 RFC 827 Bolt Beranek and Newman Inc. Eric C. Rosen 目录 1 介绍.......................................... 1 2 邻机探测.................................. 8 3 邻机可达性协议....................... 11 4 网络可达性( NR)报文.................... 15 5 NR报文轮询.............................. 22 6 发送NR报文.................................. 25 7 间接邻居................................... 27 8 怎样成为一个支线网络............................. 28 9 局限性.......................................... 32 1 介绍 DARPA卫星网Catenet应该是一个不断地发展的系统,有越来越多的主机和越来越多的网络参予其中。 当然,这将需要越来越多的网关。 过去,象这样的扩充以一种相对无组织的方式进行的。 新网关--往往包含与现存网关截然不同的软件--会不断的增加，而且将通过GGP协议迅即参予公共的路由选择算法。 然而,随着国际互联网络发展的越来越大，这种简单的扩充方式亦变得越来越行不通。 存在很多理由∶ -路径选择算法的开销变得过于庞大； -由于参予单一公共的路径选择算法的各种迥然不同的网关不断增加，致使无法进行维修和故障隔离，因为再也不能将国际互联网络作为一个综合通信系统来对待。 -网关软件和算法特别是路径选择算法,变得太严格和不灵活，因为任何被提议的改变必须由太多不同的地点与太多不同的人员来完成。 将来,国际互联网络应该发展成一组独立的域或"自治系统",每个包含一套相对同构的网关（有一或多个）。 协议特别是这些网关在它们自身当中使用的协议，将要成为专用的事物，而且决不需要在特定的域或系统外面的网关中实现。 在最简单的情况下,一个自治系统可能仅包含单个（例如）将一个局域网连接到ARPANET上的网关。 象这样的网关多半称作"支线网关",因为它唯一的用途是将局域网与国际互联网络的其他部分连接起来，而不是打算用于处理任何发自或去往那个特定局域网的通信。在不久的将来,我们将把国际互联网络视为一组自治系统，其中一个由位于ARPANET and SATNET上的DARPA网关组成，并且其余的是到局域网的支线网关。 前面的系统,我们应该称作"核心"系统,将被后面的系统作为一个运输或"长途"运输系统。 然而,国际互联网络最终可能由很多平等的自治系统组成，他们中的任何一个都能用作为(具有某些约束，将在以后讨论）发自于任何系统并且驶往任何系统的通信的一个传播介质。 当更加复杂的组合产生时,将任何一个自治系统视作一个"核心"系统显然是不合适的。 然而为了具体起见，以及因为外部网关协议的初期实现应该集中在将"支线网关"连接到位于ARPANET and SATNET上的DARPA网关上，所以我们将在我们的实例与讨论中时常使用术语"核心"网关。 外部网关协议( EGP)的宗旨是，当允许最终用户将所有自治系统的复合物看作单个国际互联网络时，利用一个固定的、统一的地址空间，使一个或多个自治系统能够作为发自于其它的自治系统和驶往其它的自治系统的通信的传播介质使用。 数据报穿越国际互联网络的路由与跨过的自治系统的数目，对最终用户来说是透明的(当然,除非最终用户使用IP "源路由"选项)。 在外部网关协议的描述中，我们故意给特殊的自治系统的设计师与实现者留下了许多活动余地，特别在计时器大小方面。 我们之所以这样做是因为我们料到不同的网关实现与不同的国际互联网络环境会产生不同的需求与目标,所以没有适用于所有情况的单一的明确的实现规范。 然而,这并不意谓着符合这规范的任何实现都能正常工作,或我们已经留下活动余地对性能来说使无关紧要的。 事实上（例如）这里没有规定某些超时值却并不意味着指定一个任意值都能工作得很好。 自治系统将被指定一个16位的标识号码(现在很多时候也用同样的方法给网络和协议分配编码）,并且每个EGP报头为这个号码贮有一个字。零不会分配给任何自治系统;更确切些,在这个域中存在一个零将表明当前没有号码。 我们必须引进一个网关是另一个网关的邻机( NEIGHBOR)这一概念。在最简单而且最普遍的情况中，如果存在一个每个网关都具有一个到达此网络的接口的网络的话，我们将这两个网关称作"邻机"。 然而,为了容许以下两个情况，我们需要一个更广义的"邻机（neighbor） "概念∶ a)两个网关可认为是邻机，尽管他们并不是通过一个(在一般意义上的术语)网络直接连接，而是通过单根链路、HDLC线路、或某些类似物"直接连接"。 b)两个网关可认为是邻机，尽管他们是通过一个对他们来说是透明的" internet "进行连接的。 也就是说,我们希望能够说两个网关是邻机，即使他们通过一个internet连接，只要该网关在他们的包转发算法中没有利用internet的内部结构方面的知识。 为了处理所有这些情况,我们说两个网关是邻机，如果他们是通过某种内部结构对他们来说是透明的传播介质连接的。 (邻机概念更全面的讨论参见IEN 184.) 如果两个邻机属于同一个自治系统,我们把他们叫做内部邻机;如果两个邻机不属于同一个自治系统,我们把他们叫做外部邻机。 为了一个系统能将另一个作为传播介质使用，互为外部邻机的网关必须能够找出哪些网络经由其他网络是可以到达的。 外部网关协议能使这些信息在外部邻机之间传送。 因为它是一个轮询协议,它也能使每个网关去控制它发送和接收网络可达性信息的速度,容许每个系统控制它的自己的开销。 它也能使每个系统拥有一个独立的路由算法，它的运行不会由于其他的系统的故障而受干扰。 它必须清楚地知道所有的自治系统，路由将在这些拥有自己的路由算法实现的系统内部的网关之间完成。 (由单个支线网关组成的单个自治系统通常不需要路由算法.) 外部网关协议不是一个路由算法。 它能使外部邻机交换所有的路由算法都可能需要的信息,不过未指定网关如何处理这些信息。某些自治系统的内部路由算法的 "路由更新"可能（或可能不）在格式上于外部网关协议的报文相仿。 在DARPA "核心"系统中的网关将开始使用GGP协议(旧的网关至网关协议)作为他们的路由算法,不过这些受变化的影响的。在其他自治系统中的网关可能使用他们自己的内部网关协议( IGPs),可能或可能不类似于任何其他自治系统的IGP。他们当然可以使用GGP,可是不允许用在其他自治系统中的网关交换GGP报文。 还必须清楚地知道，外部网关协议没有打算提供能被作为普通范围或分层路由选择算法的输入使用的信息。 它是为连接成一个树的一组自治系统设计的,没有循环。 它不能传递充分的信息去防止路由回路，如果循环存在于拓扑之中. 外部网关协议有三部分∶ ( a)邻机探测协议, ( b)邻机可达性协议,与( c)网络可达性判断。 注意，EGP定义的所有报文仅用来传播单个"路程段"。 也就是说,他们在一个网关发起并且去往一个邻机网关，没有介于其间的网关用作媒介。 所以,生存时间( TTL)域应该设成一个很小的值。 在不是发给他们的报文流中遇到EGP报文的网关可能丢弃他们。 ２邻机探测 从一个外部网关获得路由选择信息之前,必须将那个网关作为一个直接相邻获取。(直接和间接相邻之间的区别在后边的章节给出.)为了使两个网关变成直接相邻,按照前面定义的理解他们必须是邻机,并且他们必须运行只不过是一个标准的三次握手式的邻机探测协议。 一个网关希望与另一个网关启动邻机探测，则给它发送一个邻机探测请求。这个报文应该重复传送(以适当的速度,大约每30秒一次)，直到接到一个邻机探测应答。该请求总是包含一个标识号码，用以拷贝到应答中，所以请求和应答能够进行配对。 收到一个“邻机探测请求”的网关必须决定它是否希望变成请求发起者的直接邻机。 如果不,它可以通过它的选项响应以一个邻机探测拒绝报文,随意地规定拒绝的理由。否则,它应该发送一个“邻机探测应答”报文。 它还必须发送一个“邻机探测请求”报文,除非它早已这样做了。 两个网关变成直接邻机，当每个已经发送一个邻机探测报文给另一个,并且来自另一个的对应的“邻机探测应答”已经收到时。 不匹配的应答或拒绝经过一段合理的时间之后应该被丢弃。 然而,所有这些不匹配的报文方面的信息可能对诊断有用。 来自一个已是直接邻机网关的“邻机探测报文”应该用一个“应答”和一个“邻机探测报文”给以响应。 如果从一个预期的邻机收到一个“邻机探测应答”,可是经过一段时间后，没有收到那个预期的邻机的“邻机探测报文”,邻机探测协议应该被认为还未完成。 一个“邻机终止”报文(见下文)当即被发送。如果一个网关仍然希望获取另一个作为一个邻机,该协议必须从头开始重来。 如果一个网关希望终止作为某个外部网关的邻机,它发送一个“邻机终止”报文。 收到“邻机终止”报文的网关应该总是响应以一个“邻机终止”确认。 它应该停止将该报文的发送者视为一个任何方面的邻机。 因为有众多的的协议运行在直接邻机(见下文)间,如果某网关已不需要是其它的的直接邻机,它用一个“邻机终止”报文"有礼貌的"指出这个事实。该“邻机终止”报文应该被重复传输(直到某些次�