RFC903:反向地址转换协议
介绍
有些网络主机,例如无盘工作站,在启动的时候通常不知道协议地址,它们只知道硬件接口地址。为了使用象IP这样的高层协议进行通讯,它们必须从外部来发现它们的协议地址。我们的问题是没有标准机制来做这些。
Plummer的“地址转换协议”(ARP)[1]被设计用来解决一个相关的问题:给定主机的协议地址得到它的硬件地址。这篇RFC提出了“反向地址转换协议”。和ARP一样,我们假设一种广播介质,例如以太网。
Tcp/ip协议-Ip-网络协议分析
有些网络主机,例如无盘工作站,在启动的时候通常不知道协议地址,它们只知道硬件接口地址。为了使用象IP这样的高层协议进行通讯,它们必须从外部来发现它们的协议地址。我们的问题是没有标准机制来做这些。
Plummer的“地址转换协议”(ARP)[1]被设计用来解决一个相关的问题:给定主机的协议地址得到它的硬件地址。这篇RFC提出了“反向地址转换协议”。和ARP一样,我们假设一种广播介质,例如以太网。
引 言
拥塞控制在复杂的网络中公认的问题。我们发现,国防部的网间网协议(IP),一种纯数据报协议,和传输控制协议(TCP),一种传输层协议,当把它们一起使用时容易遭受不寻常的拥塞问题,这是由在传输层和数据报层之间的相互作用而引起的。特别的,IP网关对于被我们称为“拥塞崩溃”的现象而言是脆弱的,特别是当这种网关连到大范围的不同带宽的网络上的时候。我们研究了防止拥塞崩溃的方案。
由于这些协议在基于ARPANET IMP技术的网络上使用频繁,这些问题没有得到普遍的认识。基于ARPANET IMP的网络通常有一致的带宽和完全相同的交换节点,并且容量很大。对大多数TCP/IP主机和网络而言, 盈余的容量以及IMP系统控制主机传输量的能力已足以处理拥塞。然而,随着最近ARPANET分成两个互连的网络以及连到ARPANET上的具有不同特性的其他网络的增长,IMP系统良性特性中的可靠性已不足以允许主机迅速而可靠的通信。为了使网络成功的运转,必须改善拥塞控制。
福特航空航天及通信股份有限公司,和它的总公司,福特汽车公司,经营着如今实际存在的唯一一家私有的TCP/IP长距离网络。这个网络与四个网点相连(一个在Michigan,两个在Galifornia,另一个在England),它们中的一些还有大规模的本地网。这个网络交叉连接在ARPANET上但却使用它自己的长距离线路。福特公司各网点之间通过私人租赁线路进行传输,包括一条专用的横渡大西洋的卫星通讯线路。所有的交换节点都是没有点到点流量控制的纯IP报交换,并且所有主机运行的软件都是由福特公司或它的子公司编写或者经他们大量修改的软件。这个网络上的链接带宽变化很大,从1200到10,000,000bps。通常,我们已经没有能力购买昂贵的ARPANET那样的额外的长距离带宽,而且我们的长距离链接在高峰时期是超负荷的。几秒的传输时间在我们的网络里是如此的平常。由于我们的纯数据报定向,负荷过重和带宽的大范围变化,我们不得不去解决ARPANET/MILNET组织才刚开始认识到的问题。我们的网络对主机的TCP实现的次最优性能很敏感,包括与我们的网络连接或断开。我们力图检查在不同条件下的TCP性能,并且已经解决了一些TCP普遍存在的问题。在这里我们提出了两个问题及其解决办法。许多TCP实现有这些问题;如果对于某个给定的TCP实现,经过ARPANET/MILNET网关的吞吐量比经过一个单一的网络糟,那么很可能这个TCP实现存在这些问题中的一个或两个。
IP数据包以标准的实验以太网帧格式方式传输。以太网帧类型字段必须包含值513(100
1八进制)。帧数据字段要包含IP首部和IP数据。
如果需要,帧数据字段会被填充成实验以太网的最小长度。这种填充并不是IP包的一
部份,也不算在IP头的长度字段中。
在实验以太网上发送的数据包最大长度为1536个字节。推荐实现支持最大长度的包。
网关的设计必须能够接收最大长度的包,并且在必要的情况下,可以将过大的包分片。如
果一个系统不能接收最大长度的包,它应该采取步骤,在发送时减小包长,例如使用TCP最
大段长度[4]。
注意:在以太网上的数据包可能不再是一般Internet上默认的576字节的最大包长。连
接在一个以太网上的主机在向另一个以太网上的主机发送数据包时,应该注意。比较合适
的方法是发送一个较小的数据包以避免在中间的网关处被不必要地分割。在这一点上,请
参考[4]以得到更多的信息。
介绍:
本备忘录用于10MB/S,48位地址的以太网。IP数据包在3MB/S,8位地址的以太网中的传输过程见[3]。
帧格式:
IP数据包以标准的以太网帧格式方式传输。以太网帧数据必须包含十六进制数0800H以表示它的类型。帧数据要包含IP数据前面的IP首部。
发送到以太网的数据包的最小长度为1500个字节,因此,发送到以太网的IP数据包的最大长度为1500个字节。在实行中,推荐使用最大长度的包。网关的设计必须能够接收最大长度的包,并且在必要的情况下,可以将过大的包切割。如果一个系统不能接收最大长度的包,他应该采取步骤,在发送时减小包长,例如使用TCP最大段长度[4]。
注意:在以太网上的数据包可能不再是一般Internet上默认的576字节的最大包长。连接在一个以太网上的主机在向另一个以太网上的主机发送数据包时,应该注意。比较合适的方法是发送一个较小的数据包以避免在中间的网关处被不必要地分割。在这一点上,请参考[4]以得到更多的信息。
当前国际互联网络含有大量智能网关和很多无智能的网关。智能网关使用网间连接协议( GGP) [ 3]动态地交换它们自身间的路由选择信息。 无智能的网关不能动态地交换路由选择信息。
无智能的网关必须登记在智能网关路由表上,而且智能网关列表中的无智能的网关状态(例如,增加新无智能的网关)改变时需要人工干预。
在智能网关间路由通信量的量取决于智能网关的数目和网络的总数。因为无智能的网关典型情况下连接位于国际互联网络边缘的单个网络,典型地在路由表中为每个无智能的网关存在一个或者多个网络。
连接国际互联网络边缘的单个网络的网关多半称作"支线"网关。
当前用于智能网关的GGP程序有容量的限制。 急切地需要对这个程序进行重大改进。 这很难完成,因为智能网关由若干不同的团体维护,而且很难分离出这些网关的一个子集用于测试新程序。
DARPA catenet 有希望成为一个不断扩展的系统,因为有越来越多的网络上的越来越多的主机不断加入其中。当然这需要更多的网关。过去,这种扩展以一种相对无组织的形式进行。新网关,通常包含了于现存网关极为不同的的软件,将不断增加并立即通过EGP协议参与共同路由算法。然而随着因特网变得越来越大,这种简单的扩展方式变得越来越不可行。原因是:
——路由算法的开销变得过大;
——大量截然不同的网关参与同一路由算法,使得管理和错误隔离几乎不可能。因为已经不能将因特网看作是一个完全的通信系统。
——网关软件和算法尤其是路由算法台死板和缺乏灵活性,因为任何改变必须经过太多的部门和太多的人才能完成。
将来,我们希望因特网进化成一组单独的部分或“自治系统”。每个都是由一个或多个相对同构的网关组成。协议特别是(这些网关用在他们自身之间的)路由算法应当是一种私人问题,而绝不需要在网关内部实现,除非特殊部分或系统。
最简单的情况下,一个自治系统仅由单个网关组成,这个网关将局域网连到(如)ARPA网上。我们称这种网关为“烟头”网关,因为他唯一的目的是将本的网络连接到因特网的其他部分上,既没有打算用他处理发自本地网络内部的通信流也没有打算用他处理去网那个本地网的通信流。不久的将来,我们把因特网看作一组自治系统,一个由ARP网和STANET上的DARPA网关组成,其他的是一些到达局域网的网关。前者,被我们成为“核心”的系统——被后者用作为传输或“长途运输”系统。
最后,因特网由一组自治系统组成,每个可能被来自任意系统或去往任意系统的通信作为传输介质。这种常见的情况仍然是研究的主题。本论文仅仅描述了怎样用外部网关协议(EGP)把“烟头”网关连接到核心系统。
此RFC规定了CSNET(VAN网关)和其他组织所采用的在基于X.25的公用数据网上进行IP数据报传输的标准。
当数据报到达网络接口时,X.25虚电路按照要求打开以便进行传输。虚电路在经过几个待用周期(周期长度取决于与打开虚电路相关的开销)后被关闭;当接口耗尽虚电路时,一个虚电路也可能被关闭。需求高峰时期的虚电路管理算法在[1]中给出。
本RFC规范了一个ARPA Internet community上的标准。在ARPA Internet上的所有主机应当采用和实现这个标准。
此协议提供了一个独立于站点的,机器可读的日期和时间信息。时间服务返回的是以秒数,是从1900年1月1日午夜到现在的秒数,天哪,也不小呢。
设计这个协议的一个重要目的在于,网络上的许多主机并没有时间的观念,在分布式的系统上,我们可以想一想,北京的时间和东京的时间如何分呢?主机的时间往往可以人为改变,而且因为机器时钟内的误差而变得不一致,因此需要使用时间服务器通过选举方式得到网络时间,让服务器有一个准确的时间观念。不要小看时间,这对于一些以时间为标准的分布运行的程序简单是太重要了
点击下载:[PDF]RFC868中文版
本RFC规范了一个ARPA Internet community上的标准。在ARPA Internet上的所有主机应当采用和实现这个标准。
ECHO服务是一种非常有用的用于调试和检测的工具。这个IP协议的作用也十分简单,接收到什么原封发回就是了。
点击下载:[PDF]RFC862中文版