RFC4326中文文档

最新推荐文章于 2024-08-09 07:09:56 发布

写程序的胖子

最新推荐文章于 2024-08-09 07:09:56 发布

阅读量683

点赞数 1

分类专栏：技术文章文章标签： RFC ULE 中文

技术文章专栏收录该内容

5 篇文章 1 订阅

订阅专栏

当你在凝视深渊时，深渊也在凝视你。

VERSION : 2018/10/23 9:23:24
AUTHOR : zhanghaoli12345@163.com
NOTE : 此文档为依照RFC4326文档翻译而来。文档中若有任何错误希望可以通过邮箱告知。

文章目录

0 MPE 和 ULE
1 Introduction
2 Conventions Used in This Document
3 Description
4 SNDU Format
- 4.1 Destination Address Abent (D) Field
- 4.2 Length Field
- 4.3 End Indicator
- 4.4 Type Field
- - 4.4.1 Type 1：Next-Header Type Fields
  - 4.4.2 Type 2：EtherType Compatible Type Fields
- 4.5 SNDU Destination Address Field
- 4.6 SNDU Tariller CRC
- 4.7 Description of SNDU Formats
5 ExtenSion headers
- 5.1 Test SNDU
- - 5.2 Bridged Frame SNDU Encapsulate
- 5.3 Extension-Padding Optional Extension Header
6 Processing at the Encapsulation
- 6.1 SNDU Encapsulation
- 6.2 Procedure for Padding and Packing
7 Receiver processing
- 7.1 Idle State
- - 7.1.1 Idle State Payload Pointer Checking
- 7.2 Processing of a Received SNDU
- - 7.2.1 Reassembly Payload Pointer Check
- 7.3 Other Error Conditions
8 Summary
9 Acknowledgements
10 Security Considerations
11 IANA Considerations
- 11.1 IANA Guidelines
12 References
- 12.1 Normative References
- 12.2 Informative References
Appendix A SNDU Packing Examples
Appendix B SNDU Encapsulation

0 MPE 和 ULE

目前，在将 IP 数据封装成 SNDU(Sub Network Encapsulation) 时普遍使用 MPE 方式实现。但是 MPE 在设计最初并非针对 IP 数据。在封装和解封装时只用到了 MPE 12字节头部信息中的部分字段，降低了传输效率。同时 MPE 不支持 IPv6 协议。依次为背景，ULE 作为新的封装方式在2005年被IETF提出，于同年12月成为RFC。

1 Introduction

2 Conventions Used in This Document

3 Description

4 SNDU Format

采用 ULE 方式封装 PDUs 得到的 SNDU(每个 SNDU 都是一个 MPEG-2 有效载荷单元 ) 格式如下：

< ----------------------------- SNDU ----------------------------- >
+-+-------------------------------------------------------+--------+
|D| Length | Type | Dest Address* |           PDU         | CRC-32 |
+-+-------------------------------------------------------+--------+

ULE 中所有的多字节值都以网络序传输，每个字节的最高有效位放置在8-bit字段的最左侧。

4.1 Destination Address Abent (D) Field

D 字段， 1-bit。指示是否存在 Dest Address 字段。值为 0 - 存在，值为 1 - 不存在。
End Indicator 必选以 D = 1 发送。其他 SNDUs 可以以 D = 1/0 发送。默认方式以 D = 0 发送。

4.2 Length Field

长度字段， 15-bit。指示从Type后到CRC（包括）的字节数。

4.3 End Indicator

当 SNDU 后面紧随的两个字节为 0XFFFF，标识这是一个 End Indicato（即，D=1，Length=0X7FFFF）。这就向接收者指明后续没有其他 SNDUs 出现。也没有 Dest Address 字段。 0XFFFF 在 MPEG-2 中有特殊的语义，用于表示填充。

4.4 Type Field

类型字段，16-bit。类型字段标识 SNDU 中负载的类型，或存在 Next-Header。可以分配给该字段的值分为两部分，类似于以太网的分配。

EtherType 最初由 Xerox 根据Ethernet v2 Specification [DIX] 定义。在规范 IEEE 802.3 [IEEE-802.3,ISO-8802-2] 之后，小于 1536 的 EtherTypes 充当了长度指示器的角色。以太网接收者通过这个特性来区别 LLC 帧。

当接收者接收到带有两个长度字段的 PDU 时，可以能会出现模棱两可的情况，接受者需要验证实际长度和长度字段，并确保不传输错误的值。ULE 原本只有一个长度值，避免了这样的情况，但 LLC 帧的桥接重新引入了这样的情况。

ULE 本身不需要识别以太网 LLC的模式，并且 ULE 总是带有显示的长度位，因此做了如下修改：

第一种 ULE 类型集合包含小于1536的值，这些类型字段值由 IANA 指定，并标识存在 Next-Header。

第二种 ULE 类型集合包含大于或等于1536的值，在ULE中，这个值与IANA EtherType注册表中IEEE/DIX类型赋值所指定的对应类型代码相同。

4.4.1 Type 1：Next-Header Type Fields

第一种 ULE 集合对应0到1535的值。这些值可用于标识特定的链路层协议，并且/或者指明存在携带附加可选协议字段的拓展头。这些值的使用由IANA协调。本文件定义了以下类型：
0X0000 ： Test SNDU
0X0001 ： Bridged Frame
0X0100 ： Extension-Padding

4.4.2 Type 2：EtherType Compatible Type Fields

第二种 ULE 集合对应 0X600(1536) 到 0XFFFF。这组值的分配遵循 DIX/IEEE 的分配（但不包括使用使用该字段作为长度指示器）。这个集合中值的分配必须使用 IANA EtherType 定义的值。以下为两个例子：
0X0800 ： IPv4 Payload
0X86DD : IPv6 Payload

4.5 SNDU Destination Address Field

SNDU Destination Address 字段为可选字段。当 IP 数据包使用共享链路路由（即，同一链路对应多个接收者）时，必须携带该字段。携带有结合 PID 值可以解释为链路层级地址的标识字段字段（如IPv4/IPv6de的目标地址，或桥接 MAC 地址）的 IP 单播/多播数据包可以忽略该字段。

当 SNDU 报头指示存在 SNDU Destination Address 字段（即，D=0）时，在 ULE 头第4字节之后存在一个 Network Point of Attachment(NPA) 字段。NPA为6字节，通常以十六进制表示，用于在应该处理接收到的SNDU的MPEG-2传输网络中识别接收方。值 0X00:00:00:00:00:00 不能用作SNDU中的目标地址。对于多播帧，地址的第一个字节的最低有效位被设置为1，其余字节指定链路层多播地址。值 0xFF:FF:FF:FF:FF:FF 是链接广播地址，表示这个SNDU将被发送到所有接收器。

携带IPv4子网络广播地址的IPv4数据包需要发送到具有相同网络前缀的所有系统。当出现SNDU目标地址(D=0)时，该值必须设置为NPA链路广播地址(0xFF:FF:FF:FF:FF:FF)

当 PDU 是 IP 多播包且存在 SNDU 目标地址(D=0)时，多播包的 IP 组目标地址必须映射到多播 SNDU 目标地址(按照在以太网中生成目标 MAC 地址的方法)。映射 IPv4 多播地址的方法在 [RFC1112] 中指定。映射 IPv6 多播地址的方法在 [RFC2464] 中指定。

4.6 SNDU Tariller CRC

每个 SNDU 必须在 SNDU 的最后四个字节中携带一个32位 CRC 字段。这个位置简化了用硬件计算 CRC 的过程。将使用 CRC-32 多项式。使用该多项式的例子还包括以太网、DSM-CC 节语法 [ISO-DSMCC] 和 AAL5 [ITU-3563]。这是一个32位的值，根据用十六进制表示的生成器多项式 0x104C11DB7 计算得到:

x^32+x26+x^23+x22+x^16+x12+x^11+x10+x^8+x7+x^5+x4+x^2+x1+x^0

封装器将 CRC-32 累加寄存器初始化为值 0xFFFF FFFF。然后，它为 CRC-32 累积一个传输值，该值包含从 SNDU 报头开始到 SNDU 结束的所有字节(不包括包含 CRC-32 的32为校验字段)，并将其放在 CRC 字段中。在 ULE 中，字节按照在 SNDU 中的位置递增的顺序进行处理;处理位的顺序不会颠倒。这种用法类似于 SCTP [RFC3309]，但不同于 SCTP [RFC3309]。

接收器通过独立计算相同的 CRC 值并将其与 SNDU 校验字段中的传输值进行比较来执行完整性检查。没有有效 CRC 的 SNDU 被丢弃，导致接收器进入空闲状态。

4.7 Description of SNDU Formats

SNDU 的格式由 (D) 和 SNDU 类型字段的组合决定。最简单的封装将 PDU 直接放入 SNDU 有效负载中。某些 Type-1 封装可能需要额外的标头字段。它们插入到 SNDU 中，位于 NPA 目标地址之后，并直接位于 PDU 之前。

这里定义了以下 SNDU 格式：
End Indicator：接收者应当进入空闲模式
IPv4 SNDU：有效负载是 IPv4 数据报
IPv5 SNDU：有效负载是 IPv6 数据报
Test SNDU：有效负载将被丢弃
Bridged SNDU：有效负载携带一个桥接 MAC 帧

其他格式由 IEEE 和 IANA 的相关分配定义。

4.7.1 End Indicator

格式如下，这种格式必须标识 D=1。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|           0x7FFF            |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|															    |
=   A sequence of zero or more bytes with a value 0xFF filling  =
|           the remainder of the TS Packet Payload              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.7.2 IPv4 SNDU Encapsulate

IPv4 数据报直接使用两个标准 SNDU 结构之一进行传输，其中 PDU 直接放置在 SNDU 有效负载中。这两个封装如下。(请注意，IP数据报的有效负载是可变大小的，后面是CRC-32)。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|        Length (15b)         |         Type = 0x0800         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Receiver Destination NPA Address (6B)              |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
=                         IPv4 datagram                         =
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            (CRC-32)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|        Length (15b)         |          Type = 0x0800        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
=                           IPv4 datagram                       =
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             (CRC-32)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.7.3 IPv6 SNDU Encapsulate

IPv6数据报使用两个标准SNDU结构之一直接传输，其中PDU直接放置在SNDU有效负载中。如下图所示。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|        Length (15b)         |         Type = 0x86DD         | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Receiver Destination NPA Address (6B)              |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
=                           IPv6 datagram                       =
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             (CRC-32)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0                   1                   2                   3 
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|        Length (15b)         |         Type = 0x86DD         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
=                           IPv6 datagram                       =
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              (CRC-32)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5 ExtenSion headers

本节描述ULE封装的扩展格式。在ULE中，小于1536 的类型字段值表示扩展标头。这些值是从为 ULE 定义的独立 IANA 注册表中分配的。

使用单个 Type/Next-Haeder 字段简化了处理，并消除了维护多个 IANA 注册中心的需要。代价是每个扩展头至少需要2个字节。当没有扩展出现时基于简单的处理并维护一个简单的轻量级头是非常合理的。

ULE 扩展标头由 16-bit的 Type 字段标识。该字段被组织为5-bit零前缀、3-bit H-LEN字段和8-bit H-Type 字段，如下所示:

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0|H-LEN|    H-Type     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

H-LEN赋值描述如下:

0 - 标识强制拓展头
1 - 标识可选的 2B 拓展头（Type only）
2 - 标识可选的 4B 拓展头（Type + 2B）
3 - 标识可选的 6B 拓展头（Type + 4B）
4 - 标识可选的 8B 拓展头（Type + 6B）
5 - 标识可选的 10B 拓展头（Type + 8B）
>= 6 组合的H-LEN和H-TYPE值表示直接跟随这个类型字段的PDU的EtherType。

H-LEN 字段的值标识可选拓展头的总字节数（包含 2B Type 字段）。

H-LEN 值为0表示强制扩展标头。每个强制扩展标头都有一个预定义的长度，在H-LEN字段中没有标识。对于强制扩展标头的最大长度没有附加限制。强制扩展头可以修改所包含的PDU的格式或编码(例如，执行加密和/或压缩)。

H-Type 类型是一个1字节字段，它是256个强制标头扩展或256个可选标头扩展之一。这两种类型的扩展头的当前允许值集由IANA注册中心定义(第15节)。可选扩展的注册表值以H=1(即十进制 256-511)，但可与范围1-5的H-Length值一起使用。（这句话我看的不是很明白，看懂的麻烦帮我解释下。。。）

扩展头的两个示例是 Test SNDU 和使用 Extension-Padding。Test SNDU 强制扩展标头会导致整个PDU被丢弃。Extension-Padding 可选拓展头会导致随后(如果有的话)选项标头被忽略(例如:，共H-LEN 16-bit 字)。

带有扩展头的 SNDU 的一般格式是:

< --------------------------   SNDU   ------------------------- >
+---+--------------------------------------------------+--------+
|D=0| Length | T1 | NPA Address | H1 | T2 |    PDU     | CRC-32 |
+---+--------------------------------------------------+--------+
< ULE base header >             < ext 1 >
携带一个拓展头的 SNDU 封装格式（D=0）

其中：

D ： ULE D_bit(在本例中D=0; 在使用扩展标题时，NPA地址也可以省略)。
T1：基本头 Type 字段。在本示例中，标识 Next-Header。
H1：是为头 Type T1 定义的字段集。对于特定的 ULE 扩展头，可能有0或更多字节的信息.
T2：是 Next-Header 的 Type 字段，或是 PDU 携带的值大于1536的EtherType。

< --------------------------    SNDU   ------------------------- >
+---+---------------------------------------------------+--------+
|D=1| Length | T1 | H1 | T2 | H2 | T3 |      PDU        | CRC-32 |
+---+---------------------------------------------------+--------+
< ULE base header >< ext 1 >< ext 2 >
携带两个拓展头的 SNDU 封装格式（D=1）

使用这种方法，可以将多个扩展头串联起来。上图显示了包含两个扩展头的 SNDU。在本例中， T1 和 T2 的值都小于 1536 小数。每个都表示存在扩展标头，而不是直接跟随 PDU。T3 的值> 1535指示所携带的 PDU 的醚型。虽然 SNDU 可能包含任意数量的连续扩展标头，但 SNDU 通常不会携带大量扩展。

5.1 Test SNDU

Test SNDU 是 Type-1 的一种强制扩展头。这个报头必须是 SNDU 报头链中指定的最终(或唯一)扩展报头。这个 SNDU 的数据部分的结构不是由这个文档定义的。接收方可以在日志文件中记录接收情况，但必须丢弃所有 Test SNDU。D-bit 可以在 Test SNDU 中设置。

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|        Length (15b)         |         Type = 0x0000         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
=              Data (not forwarded by a Receiver)               =
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            (CRC-32)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2 Bridged Frame SNDU Encapsulate

桥接 SNDU 是 Type-1 的一种强制拓展头。这个报头必须是 SNDU 报头链中指定的最终(或唯一)扩展报头。有效负载包括 MAC 地址和 EtherType [DIX] 或 LLC Length [ISO-8802-2] 字段以及桥接 MAC 帧的内容。

当指定 NPA 地址(D=0)时，接收方必须丢弃所有携带 NPA 目标地址(或广播/多播地址)不匹配接收方 NPA 地址的 SNDU; SNDU 的负载由随后的桥接规则处理。没有 NPA 地址的 SNDU (D=1) 会导致接收端对所有接收到的 SNDU 负载按照桥接规则进行处理。

封装器还可以使用这种封装格式直接传输需要 LLC 封装的网络协议包 [IEEE-802.2, ISO-8802-2]。为此，它构造了一个 SNDU，它有一个桥接扩展头，其中包含预期的目标 MAC 地址、封装器的 MAC 源地址和 LLC-Length。PDU 包括一个 LLC 头，后面跟着所需的有效载荷。

 0                   1 					2 					3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|        Length (15b)         |         Type = 0x0001         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Receiver Destination NPA Address (6B)              |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                 MAC Destination Address (6B)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     MAC Source Address (6B)                   |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |    EtherType/LLC-Length (2B)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
=                 (Contents of bridged MAC frame)               =
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            (CRC-32)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
桥接有效载荷的 SNDU 格式（D=0）

 0                   1                   2                   3 
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|        Length (15b)         |         Type = 0x0001         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   MAC Destination Address (6B)                |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                     MAC Source Address (6B)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   EtherType/LLC-Length (2B)   |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
=                     (Contents of bridged MAC frame)           =
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           (CRC-32)                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
桥接有效载荷的 SNDU 格式（D=1）

EtherType/LLC-Length 字段根据 IEEE 802.3 [IEEE-802.2] 定义。

在这种特殊情况下，强制扩展标头格式可以解释为 EtherType [DIX] 或 LLC Length 字段(由IEEE 802 [IEEE-802.3]指定)，而不是 IANA 维护的 ULE Next-Header 注册表中分配的值。

被桥接的帧中的 MAC 地址应该按照 IEEE 指定的规则进行分配，并表示未知、单播、广播和多播链路地址。这些 MAC 地址表示目标 LAN 中的预期收件人，因此具有与 SNDU 报头中携带的NPA 地址不同的功能。

对于桥接帧，帧的 Type< 1536时引入了 LLC-Length 字段。接收机必须检查这个长度并丢弃任何长度大于 SNDU 有效载荷大小允许的帧。

在正常操作中，希望在转发之前删除附加到以太网帧的任何填充。这要求发送方知道这种以太网填充(例如，[DIX, IEEE-802.3])。

在封装器上接收的用于在ULE上继续传输的以太网帧携带局域网帧检查序列(LAN-FCS)字段（例如，用于以太网的CRC-32 [DIX, IEEE-802.3]）。

在进一步处理之前，封装器必须检查收到的所有帧的 LAN-FCS 值。用无效的 LAN-FCS 接收的帧必须丢弃。检查后，LAN-FCS 被删除(即，它不在桥接 SNDU 中转发)。与其他 ULE 帧一样，封装器将 CRC-32 附加到传输 SNDU 。在接收端，一个合适的 LAN-FCS 字段将被附加到桥接帧，然后在以太网接口上继续传输。

这种设计可以很容易地使用现有的网络接口卡实现，并且避免引入由于计算/校验两次桥接帧的完整检验而增加的效率成本。然而，它也引入了这样一种可能性，即在封装器和/或接收器上执行的处理中损坏的帧可能不会被最终的接收者检测到。这样的损坏通常不会导致无效的LAN-FCS)。