RFC系列协议--rfc4638--MTU/MRU

摘要

RFC 2516中描述的以太网点对点协议(PPPoE)要求协商最大接收单元(MRU)为1492。该文件概述了一种解决方案,该解决方案放宽了这一限制,允许协商的最大MRU大于1492,以最小化下一代宽带网络的碎片。

1.介绍

需要增加的最大传输和接收单位PPPoE协议是变得越来越重要,以减少网络中分裂。

2.术语

ATM   - Asynchronous Transfer Mode
PPP   - Point-to-Point Protocol
PPPoA - PPP over AAL5
PPPoE - PPP over Ethernet
MTU   - Maximum Transmit Unit
MRU   - Maximum Receive Unit
PC    - Personal Computer
CPE   - Customer Premises Equipment
RG    - Residential Gateway
BRAS  - Broadband Remote Access Server
DSLAM - Digital Subscriber Line Access Multiplexer
PPPoE - client PC, RG, or CPE that initiates a PPPoE session
PPPoE - server BRAS terminating PPPoE sessions initiated by client
PADI  - PPPoE Active Discovery Initiation
PADO  - PPPoE Active Discovery Offer
PADR  - PPPoE Active Discovery Request
PADS  - PPPoE Active Discovery Session-confirmation

3.解决方案

本文档中描述的过程并不严格遵守IEEE的以太网数据包大小标准,但是依赖于广泛部署的支持帧的以太网数据包格式,但是超过了定义的最大数据包长度。由于下一代宽带网络是建立在以太网系统支持baby-giants和jumbo帧载荷大小大于正常以太网MTU 1500个八位字节,BRAS充当PPPoE服务器必须支持PPPoE系统最新谈判超过1492八位位组为了限制支离破碎的数据包。
默认情况下,最大接收单元(MRU)选项必须遵循RFC 1661[2]中规定的规则,但不能协商到大于1492的大小,以保证与以太网网络段的兼容性,限制在1500-八位元帧。在这种情况下,由于PPPoE头是6个字节,而PPP协议ID是2个字节,PPP MRU不能大于1492。可选的PPPoE标记“PPP-Max-Payload”允许PPPoE客户端通过为它在发送和接收方向上支持的PPP payload提供最大的大小来覆盖这个默认的行为。当这样一个标签接收到PPPoE服务器,服务器可能会允许系统超过1492的谈判和MTU的使用超过1492,受限制的本地配置和按照规定提出在RFC 1661[2],范围内的最大有效载荷大小表示PPPoE客户机。

4.PPPoE发现阶段

如果PPPoE客户机想要使用高于1492字节的MTU/MRU,那么它必须在PADI和PADR包中包含一个可选的PPP-Max-Payload标记。如果PPPoE服务器能够支持高于1492字节的MTU/MRU,那么当从客户机接收到PPP-Max-Payload标记时,它必须使用PADO中的clients标记的回显和pad包进行响应。

Tag-name:   PPP-Max-Payload
Tag-value:  0x0120
Tag-length: 2 octets
Tag-value:  binary encoded value (max PPP payload in octets)

Tag-description:
此标记表示客户端和服务器能够支持给定的最大PPP有效负载,该负载大于发送和接收方向的1492字节。请注意,此值表示PPP有效负载;因此,它与PPP MRU协商中使用的值具有直接可比性。

5.LCP注意事项

5.1 MRU协商

以太网(没有jumbo帧)以来的最大有效载荷大小1500个八位字节,PPPoE头6个八位字节,和PPP协议ID 2八位字节的Maximum-Receive-Unit(系统)选项不能协商大小大于1492,除非PPPoE客户机和服务器都表示支持更大的系统的能力在PPPoE发现阶段。
PPP/PPPoE服务器的初始MRU协商必须遵循如下流程:

If PPPoE {
PPP_MRU_Max = 1492
If (PPP-Max-Payload-Tag) AND (PPP-Max-Payload-Tag > 1492)
Then PPP_MRU_Max = min (PPP-Max-Payload-Tag, Interface MTU-8)
}
"Normal" PPP_MRU_Negotiation (PPP_MRU_Max)

如果PPP-Max-Payload tag存在并且大于1492,那么在为正常的RFC 1661 [2] MRU协商选择最大值时,必须将它与服务器的接口MTU设置一起考虑,这将决定实际使用的MRU。
如果PPP-Max-Payload标签不存在或者存在但低于1492,那么现有的1492 octets的MRU约束必须保持适用,从而保持向后兼容性。总之,这表明了以下行为:

1.  When a "PPP-Max-Payload" tag is received,
      a. 此标记中的值将指示在MRU协商中允许接受或建议的最大MRU;
      b. 如果未协商MRU,则RFC 1661[2]将默认的MRU设置为1500。这将说明“PPP-Max-Payload”标签的值可以大于1500,但是在本例中,
          RFC 1661[2]将默认的MRU设置为1500,并且只有当MRU协商的更高(最大有效载荷)时,才会有使用“PPP-Max-Payload”标签值。
2.  When a "PPP-Max-Payload" tag is not received by either end, then
       RFC 2516 [1] sets the rule.

5.2 MRU测试和故障排除

如果协商的MRU的值大于1492字节,一旦会话打开,发送方应该可以选择发送一个或多个MRU大小的回送请求包。这允许它测试接收端和任何中间以太网段和设备是否能够处理这样的数据包大小。如果没有收到回音,发送方可以选择用1492个八位元的回音请求封包重复测试。如果这些封包收到回复,发送端不能发送大于此会话的1492字节的封包。默认情况下应该启用此功能。它应该是可配置的,并且可以在网络上禁用,因为在网络上有一些先验知识表明测试是不必要的。

6.参考协议规范

RFC 4638 MTU/MRU

温馨提示:
以上文章描述如有不清晰之处,欢迎在评论区评论,如有时间,会第一时间回复,谢谢!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值