跳到主要内容

2. 链路层 (LINK LAYER)

2.1 简介 (INTRODUCTION)​

所有互联网系统 (包括主机和网关) 对链路层协议有相同的要求。这些要求在"互联网网关要求" [INTRO:2] 第 3 章中给出, 并在本节中进行了补充。

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

无。

2.3 具体问题 (SPECIFIC ISSUES)​

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

链路层封装的 Trailer 协议 [LINK:1] 可以 (MAY) 使用, 但仅当已验证链路层通信中涉及的两个系统 (主机或网关) 都实现了 Trailer 时。如果系统不在每个目的地基础上动态协商 Trailer 协议的使用, 则默认配置必须 (MUST) 禁用该协议。

讨论:

Trailer 协议是一种链路层封装技术, 重新排列在物理网络上发送的数据包的数据内容。在某些情况下, Trailer 通过减少操作系统内的数据复制量来提高高层协议的吞吐量。高层协议不知道 Trailer 的使用, 但如果使用 Trailer, 发送和接收主机都必须 (MUST) 理解该协议。

不当使用 Trailer 可能导致非常令人困惑的症状。只有具有特定大小属性的数据包才使用 Trailer 封装, 通常只有一小部分正在交换的数据包具有这些属性。因此, 如果使用 Trailer 的系统与不使用 Trailer 的系统交换数据包, 某些数据包会消失在黑洞中, 而其他数据包则成功传递。

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

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

地址解析协议 (Address Resolution Protocol, ARP) [LINK:2] 的实现必须 (MUST) 提供一种机制来刷新过时的缓存条目。如果此机制涉及超时, 应该 (SHOULD) 可以配置超时值。

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

讨论:

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

实现:

已使用四种机制 (有时组合使用) 来刷新过时的缓存条目:

(1) 超时 (Timeout) -- 定期使缓存条目超时, 即使它们正在使用中。注意, 当缓存条目被"刷新"时 (通过观察来自相关系统的 ARP 广播的源字段, 无论目标地址如何), 应重新启动此超时。对于代理 ARP 情况, 超时需要在一分钟左右。

(2) 单播轮询 (Unicast Poll) -- 通过定期向远程主机发送点对点 ARP 请求来主动轮询它, 如果从 N 次连续轮询中没有收到 ARP 回复, 则删除该条目。同样, 超时应在一分钟左右, 通常 N 为 2。

(3) 链路层建议 (Link-Layer Advice) -- 如果链路层驱动程序检测到传递问题, 刷新相应的 ARP 缓存条目。

(4) 高层建议 (Higher-layer Advice) -- 提供从互联网层到链路层的调用, 以指示传递问题。此调用的效果是使相应的缓存条目无效。

2.3.2.2 ARP 数据包队列 (ARP Packet Queue)​

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

讨论:

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

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

IP 在以太网上的封装在 RFC-894 [LINK:3] 中描述, 而 RFC-1042 [LINK:4] 描述了 IP 在 IEEE 802 网络上的封装。

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

  • 必须 (MUST) 能够使用 RFC-894 封装发送和接收数据包;
  • 应该 (SHOULD) 能够接收 RFC-1042 数据包, 与 RFC-894 数据包混合; 以及
  • 可以 (MAY) 能够使用 RFC-1042 封装发送数据包。

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

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

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

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

IP 层和链路层之间的数据包接收接口必须 (MUST) 包含一个标志, 以指示传入数据包是否寻址到链路层广播地址。

IP 和链路层之间的数据包发送接口必须 (MUST) 包含 5 位 TOS 字段 (参见第 3.2.1.6 节)。

链路层不得 (MUST NOT) 仅仅因为目的地没有 ARP 缓存条目就向 IP 报告目的地不可达错误。

功能章节MUSTSHOULDMAYSHOULD NOTMUST NOT
Trailer 封装2.3.1x
不协商就默认发送 Trailer2.3.1x
ARP2.3.2
刷新过时的 ARP 缓存条目2.3.2.1x
防止 ARP 泛洪2.3.2.1x
缓存超时可配置2.3.2.1x
保存至少一个未解析数据包2.3.2.2x
以太网和 IEEE 802 封装2.3.3
发送和接收 RFC-894 封装2.3.3x
接收 RFC-1042 封装2.3.3x
发送 RFC-1042 封装2.3.3x
配置开关选择, 默认 RFC-8942.3.3x
发送 K1=6 封装2.3.3x
在以太网和 IEEE 802 网络上使用 ARP2.3.3x
链路/互联网层接口2.4
链路层向 IP 层报告广播2.4x
IP 层向链路层传递 TOS2.4x
无 ARP 缓存条目视为目的地不可达2.4x

参考文献:

  • [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.
最后于 更新