前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >以太网自协商机制--双绞线自协商(十二)

以太网自协商机制--双绞线自协商(十二)

作者头像
追宇星空
发布2024-07-01 15:40:40
830
发布2024-07-01 15:40:40
举报
文章被收录于专栏:追宇星空

自协商基理(一)

MultiGBASE-T自协商,主要协商的内容为“速度双工”、“主从”两个关键项(协商失败,链路不能正常建立链接)和“流控”、“EEE”、“Fast Retrain”、“PMA training reset request” 、“PHY short reach mode” 、“10GBASE-T loop timing”六个非关键项(协商失败,链路能正常建立链接)。下面先介绍MultiGBASE-T自协商的BasePage和ExtendedNextPage的bits分配, 然后就这八大类自协商内容进行阐述。

自协商Pages交互方式

MultiGBASE-T PHY按顺序地不间断地交换一个自动协商基本页、一个ExtendedNextPage (Message),和一个ExtendedNextPage (Unformatted)。

MultiGBASE-T 编码格式

速度双工协商

速度双工协商根据应用场景不同需要将MultiGBAE-T分为“原生模式”和“兼容模式”两大类进行讨论。

MultiGBAE-T工作于“原生模式”时(Base Page + Extended Next Pages):

主要靠设置MultiGBASE-T的“本地广告能力寄存器AN BASE Page Ability 1 Register (DEVAD = 7, REGAD = 0x0013)”的bit9:5、“本地控制寄存器1000BASE-T Control (DEVAD = 7, Address = 0xFFE9)”的bit9:8和“本地控制寄存器AN Control (DEVAD = 7, Address = 0x0020)”的bit12:10 &&bit8:7实现的。下面为描述问题方便,把Reg 7.32.bit11:10+Reg 7.32.bit12+Reg 7.32.bit8:7+Reg 7.65513.bit9:8+Reg 7.19.bit9:5合并为T[16:5].本端和远端选择彼此都有的能力(T[16:5]中的置1的相关bit)中优先级高的那种能力作为本端PHY和远端PHY的实际工作的速度双工状态。

MultiGBAE-T工作于“兼容模式”时(Base Page + Next Pages):

主要靠设置MultiGBASE-T的“本地广告能力寄存器Copper Autonegotiation Advertisement (DEVAD = 7, Address = 0xFFE4)”的bit9:5、“本地控制寄存器1000BASE-T Control (DEVAD = 7, Address = 0xFFE9)”的bit9:8实现的。下面为描述问题方便,把Reg 7.65513.bit9:8+Reg 7.65508.bit9:5合并为T[11:5].本端和远端选择彼此都有的能力(T[11:5]中的置1的相关bit)中优先级高的那种能力作为本端PHY和远端PHY的实际工作的速度双工状态。

PHY能力优先级由高到低排序如下:

40GBASE-T full duplex[尚没有芯片支持]

25GBASE-T full duplex[尚没有芯片支持]

10GBASE-T full duplex

5GBASE-T full duplex

2.5GBASE-T full duplex

1000BASE-T full duplex

1000BASE-T[已淘汰]

100BASE-T2 full duplex[已淘汰]

100BASE-TX full duplex

100BASE-T2[已淘汰]

100BASE-T4[已淘汰]

100BASE-TX

10BASE-T full duplex

10BASE-T

下面分为“本端远端均为MultiGBASE-T PHY”、“一端为MultiGBASE-TPHY,另一端为千兆PHY” 和“一端为MultiGBASE-T PHY,另一端均为百兆PHY”三种情况讨论。

“本端远端均为MultiGBASE-T PHY”:

此场景下,本端PHY和远端PHY均使用MultiGBAE-T“原生模式”(Base Page + Extended Next Pages)。

例子1:本端PHY的T[16:5]=2b001111001100;双绞线另一侧的远端PHY的T[16:5]=2b000100000100。此时他俩的彼此能力的交集为PHY的T[16:5]=2b000100000100,即双绞线链路双方都支持的PHY能力为T[7]=1(100BASE-TX half duplex)和T[13]=1(5GBASE-T full duplex),并且因为优先级顺序为5GBASE-T full duplex > 100BASE-TX half duplex,故此时本端和远端速度双工自协商的结果为“5GBASE-T full duplex”;

例子2:本端PHY的T[16:5]=2b001111001100;双绞线另一侧的远端PHY的T[16:5]=2b001001001000。此时他俩的彼此能力的交集为PHY的T[16:5]=2b001001001000,即双绞线链路双方都支持的PHY能力为T[8]=1(100BASE-TX full duplex)、T[11]=1(1000BASE-T full duplex) 和T[14]=1(10GBASE-T full duplex),并且因为优先级顺序为10GBASE-T full duplex > 1000BASE-T full duplex > 100BASE-TX full duplex,故此时本端和远端速度双工自协商的结果为“10GBASE-T full duplex”;

例子3:本端PHY的T[16:5]=2b00100000000;双绞线另一侧的远端PHY的T[16:5]=2b000110001100。此时他俩的彼此能力的交集为PHY的T[11:5]=2b000000000000,即双绞线链路双方没有PHY能力交集,故此时本端和远端永远无法建立正确链接。

写到这里,可能很多小伙伴会感到困惑,既然MultiGBASE-T PHY普遍支持10GBASE-T,IEEE为啥又提出了5GBASE-T和2.5GBASE-T这两种PHY标准呢?在“MultiGBASE-T PHY简介”章节部分可知,10GBASE-T PHY对双绞线网线类型是有要求的,使用Cate6 STP和Cate6A支持100米,使用cate6 UTP只支持55m,而我们实践中大量使用的双绞线类型为cate5e UTP,这就是一个很现实矛盾。如果1000M的带宽不够,而暂时又不需要10G的场景下(典型就是wifi 6无线路由器的WAN口。wifi6 160MHz单流(单天线)最大速率为1.2Gbps,满载8条流(8天线)时无线路由器的理论极限速率为1.2Gbps*8=9.6Gbps。又因为wifi的速率是上行加下行,故WAN口以太网的5Gbps(此时上行加下行为10Gbps)是足够的),5GBASE-T/2.5GBASE-T是一个很好折衷性选择,而且5GBASE-T/2.5GBASE-T PHY 支持基于双绞线cate5e UTP 100米,可以充分利用旧的网线布线设施。当然笔者在这里提供一个小小的建议,在新建的写字楼装修时(进行光纤和双绞线布线时),建议直接使用单模10KM的光纤和cate6a布线。

40GBASE-T和25GBASE-T目前尚没有芯片支持。在光纤比面条还便宜的时代,IEEE定义这两种PHY的初衷是啥,说实话笔者也不是很理解。40GBASE-T和25BASE-T需要使用昂贵的cate8双绞线,而且最大传输距离只有30米,对比40GBASE-R/25GBASE-R两种光纤以太网技术标准, 40GBASE-T和25GBASE-T的优势究竟在哪呢?欢迎读者朋友们在评论区里给出真知灼见。

博通的MultiGBASE-T的BCM84891L不支持10BASE-T full duplex和10BASE-T half duplex能力(这也无伤大雅,毕竟只支持10M的PHY基本已经被历史淘汰了)。不过作为博通的老对手,Marvell的MultiGBASE-T的88X3540倒是支持10BASE-T full duplex和10BASE-T half duplex能力的。

“一端为MultiGBASE-T PHY,另一端为千兆PHY”:

千兆PHY基于是否可理解Extended Next Page分两种情况讨论。

千兆PHY可理解Extended Next Page:

此场景下MultiGBASE-T PHY应使用“原生模式”(Base Page + Extended Next Pages)与远端千兆PHY进行FLP-Bursts自协商交互,千兆PHY使用Base Page + Next Pages与远端MultiGBASE-T PHY进行FLP-Bursts交互。MultiGBASE-T PHY必须理解Next Pages(以太网向下兼容的基本要求),因为千兆PHY可以理解远端发送过来的Extended Next Pages(尽管千兆PHY不支持主动对外发送Extended Next Pages)。故双绞线双方可以选择彼此支持的PHY能力中的优先级最高的PHY能力作为最终的协商结果。

千兆PHY不可理解Extended Next Page:

此类千兆PHY通常是设计年代久远(设计的时候,IEEE的Extended Pages交互标准尚未提出)。此场景下MultiGBASE-T PHY应使用“兼容模式”(Base Page + Next Pages)与远端进行FLP-Bursts自协商交互,千兆PHY使用Base Page + Next Pages与远端MultiGBASE-T PHY进行FLP-Bursts交互。MultiGBASE-T PHY必须理解Next Page(以太网向下兼容的基本要求)。此时的情况与“10M/100M/1000M自协商基理”章节已详细介绍过,这里不再赘述。

写到这里,可能小伙伴会有疑惑,MultiGBASE-T PHY自协商的“原生模式”和“兼容模式”需要根据远端千兆PHY的型号的不同而改变,那程序怎么做到普适性呢?答案其实很简单,那就是MultiGBASE-T PHY自协商的两种模式默认初始化都使能(这两种自协商模式的寄存器开关是独立的,分别为7.0.12和7.65503.12)。笔者曾经使用过某国产网络测试仪厂家的MultiGBASE-T网口与某国产以太网交换机的千兆电口通过双绞线互联,双方只能协商成100Base-T full duplex模式(预期正确模式应该是协商成1000Base-T full duplex模式)。后期经过笔者仔细排查,发现网络测试厂商将MultiGBASE-T网口的自协商模式只使能了“原生模式”(“兼容模式”被刻意关闭),同时以太网交换机的千兆电口PHY不理解远端的Extended Next Pages内容,这样的结果就是,两个“后进生”只能理解彼此的BASE PAGE的内容,故最终误协商成了100Base-T full duplex模式。

“一端为MultiGBASE-T PHY,另一端为百兆PHY”:

MultiGBASE-T PHY初始使用“原生模式”(Base Page + Extended Next Pages或者使用“兼容模式”(Base Page + Next Pages))与远端进行FLP-Bursts自协商交互均可,百兆PHY使用Base Page。经过第一个周期的互相协商,MultiGBASE-T PHY发现远端只支持Base Page,后续的协商MultiGBASE-T PHY只对外发送Base Page。后续过程在“10M/100M自协商基理”章节部分已经详细介绍过,这里就不再赘述了。

主从协商

在MultiGBASE-T模式中,链路的两端执行环路定时(loop timing)(10GBASE-T环路定时是可选的,40GBASE-T/25GBASE-T/5GBASE-T/2.5GBASE-T是必须的)。链接的一端协商配置为主设备,另一个协商配置为从设备。主设备发送和接收时钟锁定在本地晶振输入。从设备发送和接收时钟被锁定到传入的接收数据流。环路定时(loop timing)通过确保发射机和接收机在链路的每一端都以相同的频率工作。

主从协商的还有一个作用就是:主设备使用G(X) = 1 + X39+ X58作为加扰的生成多项式,从设备使用G(X) = 1 + X19 + X58作为加扰的生成多项式。主从设备使用不同的加扰生成多项式进行扰码才使得一对双绞线上在同一时刻传输两个方向的数据成为可能(对光纤单纤双向传输光模块熟悉的小伙伴是不是对这种方式似曾相识?这两个不同的生成多项式类似于的单纤双向的光模块的1310nm/1550nm发送波长。“双绞线的主从配对使用”类似于“1310nm发送波长的光模块和1550nm发送波长的光模块两种型号配对使用”)。

主从协商根据应用场景不同需要将MultiGBAE-T分为“原生模式”和“兼容模式”两大类进行讨论。

MultiGBASE-T工作于“原生模式”时(Base Page + Extended Next Pages):

主要靠设置MultiGBASE-T的“本地控制寄存器AN Control (DEVAD = 7, Address = 0x0020)”的bit15:13实现的。

MultiGBASE-T工作于“兼容模式”时(Base Page + Next Pages):

主要靠设置MultiGBASE-T的“本地控制寄存器1000BASE-T Control (DEVAD = 7, Address = 0xFFE9)”的bit12:10实现的。

软件需要保证上述两个寄存器的主从能力比特设置相同

“原生模式”和“兼容模式”的使用场景在“速度双工协商”章节已做介绍,这里不再赘述了。

本端与远端具体协商规则如下表:

网络管理员应该避免出现上述表格的最后两种情况,一旦出现此情况MULTIGBASE-T自协商将永远无法完成,故此时本端和远端永远无法建立正确链接。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2024-04-18,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 追宇星空 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档