跳到主要内容

2. 链路层 (LINK LAYER)

2.1 引言 (INTRODUCTION)​

所有互联网系统，无论是主机还是网关，对链路层协议都有相同的要求。这些要求在 "互联网网关要求" [INTRO:2] 的第 3 章中给出，并由本节内容加以扩充。

2.2 协议逐步分析 (PROTOCOL WALK-THROUGH)​

无 (None)。

2.3 具体问题 (SPECIFIC ISSUES)​

2.3.1 Trailer 协议协商 (Trailer Protocol Negotiation)​

链路层封装的 trailer 协议 [LINK:1] 可以 (MAY) 被使用，但仅当已验证参与链路层通信的两个系统（主机或网关）都实现了 trailer 时方可。如果系统未在逐目的地址的基础上动态协商 trailer 协议的使用，则默认配置必须 (MUST) 禁用该协议。

DISCUSSION (讨论)：

trailer 协议是一种链路层封装技术，它重新排列在物理网络上发送的分组的数据内容。在某些情况下，trailer 通过减少操作系统内部的数据拷贝量，提高了更高层协议的吞吐率。更高层协议并不知道 trailer 的使用，但如果使用了该协议，发送方和接收方主机都必须 (MUST) 理解该协议。

不当地使用 trailer 会导致非常令人困惑的症状。只有具有特定大小属性的分组才会使用 trailer 封装，并且通常只有一小部分被交换的分组具有这些属性。因此，如果使用 trailer 的系统与不使用 trailer 的系统交换分组，一些分组会消失在黑洞中，而另一些却被成功投递。

IMPLEMENTATION (实现)：

在以太网上，使用 trailer 封装的分组使用一个不同的以太网类型 [LINK:1]，并且 trailer 协商是在使用 ARP 发现目的系统的链路层地址时执行的。

具体而言，ARP 交换以通常的方式使用正常的 IP 协议类型完成，但想要使用 trailer 的主机将发送一个额外的 "trailer ARP 应答 (trailer ARP reply)" 分组，即指定 trailer 封装协议类型、但在其他方面具有正常 ARP 应答格式的 ARP 应答。如果一台配置为使用 trailer 的主机从远程机器收到一个 trailer ARP 应答消息，它可以将该机器加入理解 trailer 的机器列表，例如通过标记 ARP 缓存中的相应表项。

希望接收 trailer 封装的主机在每次完成 IP 的正常 ARP 消息交换时都会发送 trailer ARP 应答。因此，收到针对其 IP 协议地址的 ARP 请求的主机，除了发送正常的 IP ARP 应答外，还会发送一个 trailer ARP 应答；发送了 IP ARP 请求的主机在收到相应的 IP ARP 应答时会发送一个 trailer ARP 应答。通过这种方式，IP ARP 交换中请求方或应答方主机都可以请求接收 trailer 封装。

这一方案使用额外的 trailer ARP 应答分组，而不是为 trailer 协议类型发送 ARP 请求，其目的是避免与行为不端的主机持续交换 ARP 分组 —— behaving contrary to any specification or common sense（违背任何规范或常识）的主机，会以另一个 IP 的 ARP 应答来响应 trailer 的 ARP 应答。这一问题通过以下方式避免：仅当 IP ARP 应答回应了一个未决请求时，才在收到 IP ARP 应答时发送 trailer ARP 应答；当收到 IP ARP 应答时主机的硬件地址仍未知时即属此情形。trailer ARP 应答始终可以随着回应 IP ARP 请求的 IP ARP 应答一并发送。

2.3.2 地址解析协议 -- ARP (Address Resolution Protocol -- ARP)​

2.3.2.1 ARP 缓存验证 (ARP Cache Validation)​

地址解析协议 (ARP) [LINK:2] 的实现必须 (MUST) 提供一种机制来清除过时的缓存表项。如果该机制涉及超时，则超时值应该 (SHOULD) 可配置。

必须 (MUST) 包含一种防止 ARP 洪泛（以高速率重复发送针对同一 IP 地址的 ARP 请求）的机制。推荐的每目的地址最大速率为每秒 1 次。

DISCUSSION (讨论)：

ARP 规范 [LINK:2] 建议但不要求一种超时机制，以在主机更改其以太网地址时使缓存表项失效。代理 ARP（见 [INTRO:2] 第 2.4 节）的普遍存在显著增加了主机中缓存表项变得无效的可能性，因此现在主机需要某种 ARP 缓存失效机制。即使在没有代理 ARP 的情况下，较长的缓存超时周期对于自动纠正任何可能已被缓存的错误 ARP 数据也是有用的。

IMPLEMENTATION (实现)：

已有四种机制被使用，有时是组合使用，以清除过时的缓存表项。

(1) 超时 (Timeout) —— 定期使缓存表项超时，即使它们正在被使用。注意，当缓存表项被 "刷新" 时（通过观察来自相关系统的 ARP 广播的源字段，而不论目标地址为何），该超时应当被重启。对于代理 ARP 情形，超时需要在约一分钟的量级。

(2) 单播轮询 (Unicast Poll) —— 通过定期向远程主机发送一个点到点 ARP 请求来主动轮询它，如果在 N 次连续轮询中均未收到 ARP 应答，则删除该表项。同样，超时应当在约一分钟的量级，且通常 N 为 2。

(3) 链路层建议 (Link-Layer Advice) —— 如果链路层驱动程序检测到投递问题，则清除相应的 ARP 缓存表项。

(4) 更高层建议 (Higher-layer Advice) —— 提供从互联网层到链路层的调用来指示投递问题。该调用的作用将是使相应的缓存表项失效。该调用类似于从传输层到互联网层的 "ADVISE_DELIVPROB()" 调用（见第 3.4 节），事实上 ADVISE_DELIVPROB 例程可能反过来调用链路层建议例程以使 ARP 缓存表项失效。

方法 (1) 和 (2) 涉及约一分钟或更短时间的 ARP 缓存超时。在没有代理 ARP 的情况下，如此短的超时可能在非常大的以太网上产生明显的开销流量。因此，可能有必要配置主机以延长 ARP 缓存超时。

2.3.2.2 ARP 分组队列 (ARP Packet Queue)​

链路层应该 (SHOULD) 保存（而不是丢弃）每一组发往同一未解析 IP 地址的分组中至少一个（最新的）分组，并在地址被解析后传输所保存的分组。

DISCUSSION (讨论)：

不遵循此建议会导致每次交换的第一个分组丢失。尽管更高层协议通常可以通过重传来应对分组丢失，但分组丢失确实会影响性能。例如，丢失一个 TCP 打开请求会使初始往返时间估计被夸大。基于 UDP 的应用（如域名系统）受到的影响更为严重。

2.3.3 以太网与 IEEE 802 封装 (Ethernet and IEEE 802 Encapsulation)​

以太网的 IP 封装在 RFC-894 [LINK:3] 中描述，而 RFC-1042 [LINK:4] 描述了 IEEE 802 网络的 IP 封装。RFC-1042 详述并替换了 [INTRO:2] 第 3.4 节中的讨论。

每台连接到 10Mbps 以太网电缆的互联网主机：

  • 必须 (MUST) 能够使用 RFC-894 封装发送和接收分组；
  • 应该 (SHOULD) 能够接收 RFC-1042 分组，并与 RFC-894 分组混合；且
  • 可以 (MAY) 能够使用 RFC-1042 封装发送分组。

实现了同时发送 RFC-894 和 RFC-1042 封装的互联网主机必须 (MUST) 提供一个配置开关来选择发送哪一种，并且该开关必须 (MUST) 默认为 RFC-894。

请注意，RFC-1042 中的标准 IP 封装不使用 IEEE 为 IP 保留的协议 id 值 (K1=6)；相反，它使用一个（K1=170）暗示扩展（"SNAP"）的值，该扩展可用于存放 Ether-Type 字段。互联网系统不得 (MUST NOT) 发送使用 K1=6 的 802 分组。

以太网和 IEEE 802 网络上从互联网地址到链路层地址的地址转换必须 (MUST) 由地址解析协议 (ARP) 管理。

以太网的 MTU 为 1500，802.3 的 MTU 为 1492。

DISCUSSION (讨论)：

IEEE 802.3 规范提供了在 10Mbps 以太网电缆上的运行，在这种情况下以太网和 IEEE 802.3 帧在物理上可以混合。接收方可以通过 802.3 长度字段的值来区分以太网和 802.3 帧；这个两字节字段在头部中与以太网帧的 Ether-Type 字段位置重合。特别地，802.3 长度字段必须小于或等于 1500，而所有有效的 Ether-Type 值都大于 1500。

另一个兼容性问题出现在链路层广播上。以一种帧格式发送的广播不会被只能接收另一种帧格式的主机看到。

本节的规定旨在尽可能地在同一条电缆上使支持 894 与支持 1042 的系统之间实现直接互操作。其目的是支持目前以仅 894 系统为主的局面，同时为 1042 系统可能变得普遍的将来提供轻松的过渡。

请注意，仅 894 系统无法与仅 1042 系统直接互操作。如果这两种系统类型被设置为同一条电缆上的两个不同逻辑网络，它们只能通过 IP 网关通信。此外，由于链路层广播的问题，双格式主机自动发现应发送哪种格式既无用途也不可能。

2.4 链路/互联网层接口 (LINK/INTERNET LAYER INTERFACE)​

IP 层与链路层之间的分组接收接口必须 (MUST) 包含一个标志，用于指示传入分组是否寻址到一个链路层广播地址。

DISCUSSION (讨论)：

尽管 IP 层通常不知道链路层地址（因为每种不同的网络介质通常具有不同的地址格式），但广播能力介质上的广播地址是一个重要的特例。参见第 3.2.2 节，尤其是关于广播风暴的讨论。

IP 与链路层之间的分组发送接口必须 (MUST) 包含 5 位 TOS 字段（见第 3.2.1.6 节）。

链路层不得 (MUST NOT) 仅因为某目的地址没有 ARP 缓存表项，就向 IP 报告 "目的不可达 (Destination Unreachable)" 错误。

特性 (Feature)章节 (Section)MUSTSHOULDMAYSHOULD NOTMUST NOT
Trailer 封装 (Trailer encapsulation)2.3.1x
未经协商默认发送 Trailer (Send Trailers by default without negotiation)2.3.1x
ARP2.3.2
清除过时的 ARP 缓存表项 (Flush out-of-date ARP cache entries)2.3.2.1x
防止 ARP 洪泛 (Prevent ARP floods)2.3.2.1x
缓存超时可配置 (Cache timeout configurable)2.3.2.1x
保存至少一个（最新的）未解析分组 (Save at least one (latest) unresolved pkt)2.3.2.2x
以太网与 IEEE 802 封装 (Ethernet and IEEE 802 Encapsulation)2.3.3
主机能够：(Host able to:)2.3.3
- 发送并接收 RFC-894 封装 (- Send & receive RFC-894 encapsulation)2.3.3x
- 接收 RFC-1042 封装 (- Receive RFC-1042 encapsulation)2.3.3x
- 发送 RFC-1042 封装 (- Send RFC-1042 encapsulation)2.3.3x
则配置开关以选择，默认 RFC-894 (Then config. sw. to select, RFC-894 dflt)2.3.3x
发送 K1=6 封装 (Send K1=6 encapsulation)2.3.3x
在以太网和 IEEE 802 网络上使用 ARP (Use ARP on Ethernet and IEEE 802 nets)2.3.3x
链路/互联网层接口 (Link/Internet Layer Interface)2.4
链路层向 IP 层报告广播 (Link layer report b'casts to IP layer)2.4x
IP 层向链路层传递 TOS (IP layer pass TOS to link layer)2.4x
无 ARP 缓存表项被视为目的不可达 (No ARP cache entry treated as Dest. Unreach.)2.4x

参考文献 (References):

  • [LINK:1] Leffler, S., and M. Karels, "Trailer Encapsulations", RFC-893, Univ. of California at Berkeley, April 1984.
  • [LINK:2] Plummer, D., "An Ethernet Address Resolution Protocol", RFC-826, November 1982.
  • [LINK:3] Hornig, C., "A Standard for the Transmission of IP Datagrams over Ethernet Networks", RFC-894, April 1984.
  • [LINK:4] Postel, J., and J. Reynolds, "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC-1042, February 1988.