以太网协议报文格式.docx

以太网协议报文格式.docx

《以太网协议报文格式.docx》由会员分享，可在线阅读，更多相关《以太网协议报文格式.docx（36页珍藏版）》请在冰豆网上搜索。

以太网协议报文格式

的以太类型/长度字段则放在Q-标签的后面。

TPID后面是两个字节的标签控制信息（TCI）。

（IEEE802.1p优先级（QoS）和VLAN ID）。

Q标签后面就是通常的帧内容。

802.3以太网帧结构

前导码

帧开始符

MAC目标地址

MAC源地址

802.1Q 标签（可选）

以太类型或长度

负载

冗余校验

帧间距

101010107个octet

101010111个octet

6octets

6octets

（4octets）

2octets

46–1500octets

4octets

12octets

64–1522octets

72–1530octets

84–1542octets

▪标签协议识别符（TagProtocalIdentifier,TPID）:

一组16位元的域其数值被设定在0x8100以用来辨别某个IEEE802.1Q的帧为已被标签的，而这个域所被标定位置与乙太形式/长度在未标签帧的域相同，这是为了用来区别未标签的帧。

▪优先权代码点（PriorityCodePoint,PCP）:

以一组3位元的域当作IEEE802.1p优先权的参考，从0（最低）到7（最高），用来对资料流（音讯、影像、档案等等）作传输的优先级。

▪标准格式指示（CanonicalFormatIndicator,CFI）:

1位元的域。

若是这个域的值为1，则MAC地指则为非标准格式；若为0，则为标准格式；在乙太交换器中他通常默认为0。

在乙太和令牌环中，CFI用来做为两者的相容。

若帧在乙太端中接收资料则CFI的值须设为1，且这个端口不能与未标签的其他端口桥接。

▪虚拟局域网识别符（VLANIdentifier,VID）:

12位元的域，用来具体指出帧是属于哪个特定VLAN。

值为0时，表示帧不属于任何一个VLAN；此时，802.1Q标签代表优先权。

16位元的值0x000和0xFFF为保留值，其他的值都可用来做为共4094个VLAN的识别符。

在桥接器上，VLAN1在管理上做为保留值。

这个12位元的域可分为两个6位元的域以延伸目的（Destination）与源（Source）之48位元地址，18位元的三重标记（Triple-Tagging）可和原本的48位元相加成为66位元的地址。

0、以太网的封装格式（RFC894）

IEEE802.2/802.3（RFC1042）

一个0x0800的以太类型说明这个帧包含的是IPv4数据报。

同样的，一个0x0806的以太类型说明这个帧是一个ARP帧，0x8100说明这是一个IEEE802.1Q帧，而0x86DD说明这是一个IPv6帧，而0x8864有PPPoE封装（其他以太网类型见附2）

1、以太网PAUSE帧

IEEE802.3x是全双工以太网数据链路层的流控方法。

当客户终端向服务器发出请求后,自身系统或网络产生拥塞时,它会向服务器发出PAUSE帧,以延缓服务器向客户终端的数据传输。

　　有关交换机的流量控制机制：

　　定义：

流量控制用于防止在端口阻塞的情况下丢帧，这种方法是当发送或接收缓冲区开始溢出时通过将阻塞信号发送回源地址实现的。

流量控制可以有效的防止由于网络中瞬间的大量数据对网络带来的冲击，保证用户网络高效而稳定的运行。

　　两种控制流量的方式：

　　1，在半双工方式下，即半双工背压控制，是通过反向压力（backpressure）即我们通常说的背压计数实现的，这种计数是通过向发送源发送jamming信号使得信息源降低发送速度。

　　2，在全双工方式下，流量控制一般遵循IEEE802.3X标准，是由交换机向信息源发送“pause”帧令其暂停发送。

　　采用流量控制，使传送和接受节点间数据流量得到控制，可以防止数据包丢失。

PAUSE帧格式：

MAC控制帧通过其唯一的类型域标识符（0x8808）识别。

pause格式：

目的地址：

组播地址（01-80-C2-00-00-01）

源地址：

类型：

8808

MAC控制操作码:

2个字节0x0001（Pause帧仅是MAC控制帧的一种，对于Pause帧，其在MAC控制帧中的操作码为00-01;）

MAC控制操作参数域：

2个字节代表要求对方停止的时间。

（MAC控制参数域，包含用于MAC控制相关的参数。

对于Pause帧，此处应填入要求对端设备暂停发送的时间长度，

由两个字节 （16位）来表示该长度，每单位长度为物理层芯片发送512位数据的时间。

所以发送一次Pause帧，要求对端设备暂停发送的时间长度为：

0-65535×（512/以太网传输速率）。

）

保留域。

2、以太网VLAN帧格式

一、IEEE802.1Q标签帧格式

Preamble

SFD

DA

SA

vlantag

Type/Length

……Date……

CRC

7B

1B

6B

6B

4B

2B

42-1496B

4B

Vlantag：

4字节，包含2个字节的标签协议标识（TPID）和2个字节的标签控制信息（TCI），TCI字段具体又分为：

priorty、CFI、VlanID，具体格式如下所示：

TPID

UserPriority

CFI

VID

2B

3b

1b

12b

⏹TPID（标签协议标识）：

2字节，用于标识帧的类型，其值为0x8100时表示802.1Q/802.1P的帧。

设备可以根据这个字段判断对它接收与否。

⏹TCI（标签控制信息字段）：

2字节，包括用户优先级（UserPriority）、规范格式指示器（CanonicalFormatIndicator）和VLANID。

●UserPriority：

3个bti，表示帧的优先级，取值范围0~7，值越大优先级越高，用于802.1p。

●CFI，1bit，值为0代表MAC地址是以太帧的MAC，值为1代表MAC地址是FDDI、令牌环网的帧。

●VID（VLANID）：

12bit，表示VLAN的值。

12bit共可以表示4096个VLAN，实际上，由于VID0和4095被802.1Q协议保留，所以VLAN的最大个数是4094（1-4094）个（据说VID＝0用于识别帧优先级。

4095（FFF）作为预留值）

二、IEEE802.1ad（QinQ）帧格式

基本概念

IEEE802.1ad的全称是“VirtualBridgedLocalAreaNetworksAmendment4:

ProviderBridges”，该协议的目标是业务提供商在为客户提供业务时使客户间的服务相互独立，没有相互依赖关系，同时尽量做到业务提供商透明地为客户提供业务。

该标准描述了业务提供商（运营商）如何利用和扩展802.1Q在一个统一的网络中为相互独立的客户提供以太网业务。

QinQ技术〔也称StackedVLAN或DoubleVLAN〕。

标准出自IEEE802.1ad,其实现将用户私网VLANTag封装在公网VLANTag中，使报文带着两层VLANTag穿越运营商的骨干网络（公网）。

在公网中报文只根据外层VLANTag（即公网VLANTag）传播，用户的私网VLANTag被屏蔽。

带双层VLANTag的报文结构，802.1ad的报文格式，基本同前面我们所讲的QinQ报文格式一致，主要的区别就是802.1ad中重新定义了TPID的值和把原来的CFI位修改为DEI（丢弃标识）位，如下图所示：

•C-VLAN：

CustomerVLAN，是用户网络内部使用的VLAN；

• S-VLAN：

ServiceVLAN，服务提供商网络中使用的VLAN，该VLAN标识VPN用户或者是用户的业务；

• CustomerBridge:

Customer网络中的Bridge，只能识别C-VLAN；

•ProviderBridge：

服务提供商网络中的Bridge，根据处理内容的不同又分为S-VLANBridge和ProviderEdgeBridge。

其中S-VLANBridge只能识别S-VLAN； ProviderEdgeBridge可以同时识别C-VLAN和S-VLAN；

•C-VLANComponent:

在Bridge内可识别、插入、删除C-VLAN的实体，每个端口一个，对C-VLAN的操作互相独立（两个端口上接收到相同的C-VLAN，但由于属于不同的客户最后的处理结果会不同）；

•S-VLANComponent:

在Bridge内可识别、插入、删除S-VLAN的实体，由于在一个Bridge内不存在相同的S-VLAN属于不同服务提供商的情况，因此在一个桥内只有一个S-VLAN的实体。

QinQ技术上完全可以多层堆叠，没有限制，仅受Ethernet报文长度的限制，具有很好的扩充性。

对于QinQ，业界有多种不同的称呼，比如TaginTag、VLANVPN、StackVLAN、SVLAN

QinQ每增加一层VLAN标签，就可以将所覆盖的用户VLAN数量增加4096倍，两层VLAN标签可以支持4K×4KVLAN，一般来说两层VLAN就可以满足绝大多数需求了。

相对基于MPLS的二层VPN，QinQ具有如下特点：

􀁺为用户提供了一种更为简单的二层VPN隧道；

􀁺不需要信令协议的支持，可以通过纯静态配置实现；

􀁺由于QinQ的实现是基于802.1Q协议中的Trunk端口概念，要求隧道上的设备都必须支持802.1Q协议。

QinQ主要可以解决如下几个问题：

􀁺缓解日益紧缺的公网VLANID资源问题；

􀁺用户可以规划自己的私网VLANID，不会导致和公网VLANID冲突；

􀁺为小型城域网或企业网提供一种较为简单的二层VPN解决方案；

QinQ实现过程如图3所示：

图3QinQ功能示意图

图3中CE交换机上行报文带有内层Vlan标签，报文到达汇聚交换机后，汇聚交换机可以根据不同的交换机端口给报文打上相应的外层标签，这样汇聚交换机每端口可以支持4KVlan的接入。

QinQ报文封装

QinQ的报文封装就是在原有802.1Q报文中的TAG头上再加上一层TAG封装，用来扩展VLAN的范围，如图1所示：

图1 QinQ报文封装

QinQ的报文转发过程

在通过QinQ实现简单的二层VPN过程中报文是按如下方式转发：

图2 QinQ报文转发过程

图2中在运营商网中使用VLAN20来标识客户A、VLAN30标识客户B，当客户A的报文到达运营商的边缘交换机时，边缘交换机均给客户A的报文打上一个外层标签（VLAN20），然后在VLAN20中转发，不会转发到VLAN30，报文在离开运营商网络时再剥离掉外层的标签，转发到用户A的网络，从而实现一个简单二层VPN功能。

QinQ报文的TPID值可调功能

TPID（TagProtocolIdentifier，标签协议标识）是VLANTag中的一个字段，IEEE802.1Q协议规定该字段的取值为0x8100。

IEEE802.1Q协议定义的以太网帧的Tag报文结构如下：

图3 IEEE802.1Q报文结构

通常在QinQ中设备的内外层标签的TPID值均采用协议规定的0x8100，但是某些厂商的设备将QinQ报文外层Tag的TPID值设置为0x9100或0x9200，为了和这些设备兼容，并提供较高的灵活性，我司支持QinQ功能的交换机基本上均提供了QinQ报文TPID值可调功能（需要注意有的设备整机支持，有的设备是端口支持），能修改QinQ设备的外层标签的TPID值。

（在本文的802.1ad部分我们将会看到802.1ad所规定的TPID为0x88a8，所以当设备同标准802.1ad设备作QinQ对接时也需要TPID可调功能）。

灵活QinQ（SelectiveQinQ）

在前面我们所讲的QinQ中，通常是以物理端口来划分用户或用户网络，当多个不同用户以不同的VLAN接入到同一个端口时则无法区分用户。

另外前面的QinQ方案是一种简单二层VPN的应用，在运行营商接入环境中往往需要根据用户的应用或接入地点（设备）来区分用户，基于这种应用产生了灵活QinQ方案。

简单讲灵活QinQ就是根据用户报文的Tag或其他特征（IP/MAC等），给用户报文打上相应的外层Tag，以达到区分不同用户或应用的目的。

当前灵活QinQ主要应用在运营商的接入网络中，在运营商网络中给接入用户分配一个VLAN，以达到便于问题追踪和防止不同用户间互访，用外层标签区分用户的应用；或在接入的环境中用外层标签来区分不同的接入地点，用内外两层标签唯一标识出一个接入用户。

在这样的应用中需要BRAS/SR设备支持QinQ的应用（能够终结双Tag）。

下面我们以S9500为例，看一下灵活QinQ的应用场景：

在S9500上实施QinQ，并在S9500上进行业务分流，分流的方式是利用灵活QinQ功能，灵活QinQ分流的依据有下面几种：

1） 根据端口的VLAN区间分流：

比如PC的VLAN范围1～1000，STB的VLAN范围1001～2000，网吧的VLAN范围2001～3000；

2） 根据报文的协议号分流：

比如PC采用PPPoE、STB采用IPoE，这些终端都通过一个VLAN上行，可以根据PPPoE和IPoE报文不同的协议号作为QinQ的分流依据；

3） 根据报文的目标IP地址分流：

对于相同源IP地址，相同报文封装不同的业务应用报文，比如PC上的SoftPhone产生的报文，需要根据报文目的IP地址实施灵活QinQ进行业务分流；

4） 根据QinQ的内层标签的区间，在某些级联交换机的组网模式中，下连的交换机已经实施了基于端口的QinQ，为了实现业务分流，可以根据QinQ的内层VLAN标签的区间实施灵活QinQ进行业务分流。

 上述应用场景可以用图4来直观的加以描述：

图4 灵活QinQ对多业务的识别标记

BPDUTunnel（L2ProtocolTunnel）

QinQ网络中，运营商网络对客户透明，当客户和运营商网络之间的连接有冗余时必然导致环路问题，如QinQ应用示意图2中的A客户。

这就需要运营商网络能透明传输STP/RSTP/MSTP报文，这样客户可以跨运营商网络构建自己的STP树，切断冗余链路。

另外为了保证客户全网VLAN配置的一致性，动态VLAN协议如GVRP、VTP等也要求通过运营商网络透传，如果客户使用GMRP作组播应用的话，GMRP报文也要求透传。

同时在透传这些报文时，需要区分开不同用户的二层协议报文。

我们知道以上这些BPDU报文是桥设备的二层控制报文（基本上是以LLC封装的），是与设备全局相关的，不带VLANTag，所以需要一种机制来传输用户的二层控制报文，从而引入了BPDUTunnel（Cisco:

Layer2ProtocolTunneling）的概念，通过Tunnel来传播用户的二层控制报文。

通常BPDUTunnel是这样实现的：

当Tunnel端口收到一个用户的BPDU后，把目的MAC修改为一个组播MAC，然后再给协议报文打上用户所属VLAN的Tag信息，组播MAC保证报文在VLAN内广播，同时标识这个报文是个BPDU-Tunnel报文，交换机在收到这个报文时上送CPU处理，还原其BPDU身份，并根据报文中用户所属的VLAN信息，把报文送到相应的客户网络。

当前我司的实现就采取了上述这种方法，收到用户的BPDU报文后，给这个报文的目的MAC修改为：

01-00-0c-cd-cd-d0，再加上运营商分配该用户的VLANTag，如图5所示：

图5 BPDU-Tunnel报文封装

在传统的QinQTunnel中是通过修改原协议报文的目的地址及加上用户所属VLAN标识来传递用户L2协议报文的（这样做的缺点在于需要在边缘设备上对报文进行修改加重设备CPU的负担）。

在802.1ad中为C-VLAN及S-VLAN分配了不同的保留地址，在Ｓ-VLAN中处理C-VLAN中的协议报文和处理普通的数据报文一样，从而不需要Tunnel就可以透明传输用户二层协议报文。

Assignment

Value

BridgeGroupAddress

01-80-C2-00-00-00

IEEE802.3FullDuplexPAUSEoperation

01-80-C2-00-00-01

IEEE802.1XPAEaddress

01-80-C2-00-00-03

ProviderBridgeGroupAddress

01-80-C2-00-00-08

Provider Bridge GVRPAddress

01-80-C2-00-00-0D

IEEE802.1ABLinkLayerDiscoveryProtocolmulticastaddress

01-80-C2-00-00-0E

表格 2：

保留的地址

SpanningTreeProtocol

Provider网络的STP操作和Customer网络的STP操作完全独立运行，相互不关联。

在Provider网络内部采用不同的BridgeGroupAddress（01-80-C2-00-00-08），对于用户的BPDU报文（01-80-C2-00-00-00）作为普通数据报文透传，不进行识别和处理。

Provider网络边缘的C-VLANcomponent端口可以参与用户STP拓扑的计算和用户BPDU的处理。

GVRP

Provider网络的GVRP操作和Customer网络的GVRP的操作完全独立运行，相互不关联。

在Provider网络内部采用不同的ProviderBridgeGVRPAddress（01-80-C2-00-00-0D），对于用户GVRP报文（01-80-C2-00-00-21）以及其他的GARP保留地址作为普通数据报文透传，不进行识别和处理。

Provider网络边缘的C-VLANcomponent端口可以参与用户的GARP报文的处理。

802.1ad对灵活QinQ的支持

802.1ad对灵活QinQ的支持同当前常见的灵活QinQ基本一致，在802.1ad中提供了两种确定用户所属S-VLAN的方式：

1、基于端口（Port-basedserviceinterface），在这种模式下用户是根据接入的端口来选择Ｓ-VLAN（ServiceInstance）的

2、基于C-VLAN（C-Taggedserviceinterfaces），在这种模式下是根据用户使用的C-VID来先择S-VLAN（ServiceInstance），即同当前我们所见的灵活QinQ类似。

1、IP报文格式

版本号：

pv4-ipv6

IP头部长度：

5words=5*4=20字节（不含选项）

TOS：

服务类型，包括一个3bit的IP优先级字段（现在已被忽略），3bit的TOS子字段和2bit未用为0；

4bit的TOS分别代表：

Bit3:

0=NormalDelay,1=LowDelay.

Bits4:

0=NormalThroughput,1=HighThroughput.

Bits5:

0=NormalRelibility,1=HighRelibility.

01234567

+-----+-----+-----+-----+-----+-----+-----+-----+---------------------|

||||

|PRECEDENCE|TOS|MBZ|

||||

+-----+-----+-----+-----+-----+-----+-----+-----+---------------------|

1、IP报文中，TOS（服务类型，现改名为DS，即区分服务）字节占8位（P2P1P0T3T2T1T0CU）；

其中：

前三个比特（P2P1P0）定义为IP优先级，取值范围为0-7；

第四至第七比特（T3T2T1T0）为TOS子字段,TO位备用：

第8个比特为未用位。

2、DSCP

DSCP由RFC2474定义，它重新命名了IP报头中TOS使用的那1字节，DSCP使用高6bit，最低2bit不用。

（DS5DS4DS3DS2DS1DS0CUCU）

RFC2474定义最高3比特为级别／类别选择代码（ClassSelectorCodepoints，CS），

其意义和IPv4报头中IP优先级的定义是相同的，CS0～CS7的级别相等于IP优先级0～7。

但它并没有定义第3到第5比特的具体含义以及使用规则。

DSCP使用6比特，可以定义64个优先级（0－63）。

IP首部兼容性

由于ECN修改了IP首部，所以存在以下兼容性问题：

1、以下RFC除了RFCs731,2474,2780这三个标准可以兼容ECN的增量部署之外，其他RFC实现均无法兼容ECN部署。

RFC791definedtheToS（TypeofService）octetintheIPheader.

01234567

+-----+-----+-----+-----+-----+-----+-----+-----+

|PRECEDENCE|TOS|0|0|RFC791

+-----+-----+-----+-----+-----+-----+-----+-----+

RFC1122includedbits6and7intheTOSfield,thoughitdidnot

discussanyspecificuseforthosetwobits:

01234567

+-----+-----+-----+-----+-----+-----+-----+-----+

|PRECEDENCE|TOS|RFC1122

+-----+-----+-----+-----+-----+-----+-----+-----+

TheIPv4TOSoctetwasredefinedinRFC1349[RFC1349]asfollows:

01234567

+-----+-----+-----+-----+-----+-----+-----+-----+

|PRECEDENCE|TOS|MBZ|RFC1349

+-----+-----+-----+-----+-----+-----+-----+-----+

TheIPv4TOSoctetwasredefinedinRFC1349[RFC1349]asfollows:

01234567

+-----+-----+-----+-----+-----+-----+-----+-----+

|DSCP