PPP或以太网如何从错误中恢复？ [英] How does PPP or Ethernet recover from errors?

问题描述

查看数据链接级别标准，例如PPP 一般框架格式或以太网，不清楚如果校验和无效，会发生什么。 协议如何知道下一帧开始的位置？

Looking at the data-link level standards, such as PPP general frame format or Ethernet, it's not clear what happens if the checksum is invalid. How does the protocol know where the next frame begins?

只是扫描下一次出现的flag（在PPP）？如果是这样，如果分组有效负载恰好包含标志本身，会发生什么？我的观点是，无论是使用分组帧还是长度字段，不清楚如何从长度字段可能被破坏的无效数据包中恢复，或者成帧字节可能恰好是分组有效载荷。

Does it just scan for the next occurrence of "flag" (in the case of PPP)? If so, what happens if the packet payload just so happens to contain "flag" itself? My point is that, whether packet-framing or "length" fields are used, it's not clear how to recover from invalid packets where the "length" field could be corrupt or the "framing" bytes could just so happen to be part of the packet payload.

更新：我发现我正在寻找（这不是我所要求的严格）通过查找GFP基于CRC的框架。根据通信网络

UPDATE: I found what I was looking for (which isn't strictly what I asked about) by looking up "GFP CRC-based framing". According to Communication networks

GFP接收器通过三维图像同步到GFP帧边界，状态过程。接收器最初处于寻线状态，其中它一次检查四个字节，以查看在前两个字节上计算的CRC是否等于接下来的两个字节的内容。如果没有匹配，则GFP向前移动一个字节，因为GFP假定由物理层给出的八位位组同步传输。当接收机发现匹配时，它移动到预同步状态。在这种中间状态下，接收机使用临时PLI（有效载荷长度指示符）字段来确定下一帧边界的位置。如果已经实现成功的帧检测的目标号码N ，则接收机移动到同步状态。同步状态是接收机检查每个PLI的正常状态，使用cHEC（核心报头错误检查）进行验证，提取有效载荷，并进入下一帧。

The GFP receiver synchronizes to the GFP frame boundary through a three-state process. The receiver is initially in the hunt state where it examines four bytes at a time to see if the CRC computed over the first two bytes equals the contents of the next two bytes. If no match is found the GFP moves forward by one byte as GFP assumes octet synchronous transmission given by the physical layer. When the receiver finds a match it moves to the pre-sync state. While in this intermediate state the receiver uses the tentative PLI (payload length indicator) field to determine the location of the next frame boundary. If a target number N of successful frame detection has been achieved, then the receiver moves into the sync state. The sync state is the normal state where the receiver examines each PLI, validates it using cHEC (core header error checking), extracts the payload, and proceeds to the next frame.

$ b简而言之，每个数据包以length和CRC（length）开始。没有必要转义任何字符，并且数据包的长度是提前知道的。

In short, each packet begins with "length" and "CRC(length)". There is no need to escape any characters and the packet length is known ahead of time.

似乎有两种主要的数据包框架方法：

There seems to be two major approaches to packet framing:

• 编码方案（位/字节填充，曼彻斯特编码，4b5b，8b10b等）


• 未修改的数据+校验和）

前者更安全，后者更有效率。如果有效负载恰好包含有效的数据包，并且线路损坏导致进行的字节包含帧的起始字节序列，但这听起来很不可能，两者都容易出错。很难发现GFP的强大数据，但很多现代协议似乎都使用它，所以可以假设他们知道他们在做什么。

The former is safer, the latter is more efficient. Both are prone to errors if the payload just happens to contain a valid packet and line corruption causes the proceeding bytes to contain the "start of frame" byte sequence but that sounds highly improbable. It's difficult to find hard numbers for GFP's robustness, but a lot of modern protocols seem to use it so one can assume that they know what they're doing.

推荐答案

你已经非常接近正确的答案。基本上如果它以前导码开始，并以与校验和匹配的方式结束，那么它是一个框架，并传递到更高的层。

You're pretty close to the correct answer already. Basically if it starts with a preamble and ends in something that matches as a checksum, it's a frame and passed up to higher layers.

PPP和以太网都寻找下一个帧启动信号。在以太网的情况下，它是前导码，是64个交替位的序列。如果一个以太网解码器看到它，它只是假设一个帧是什么。通过捕获位，然后检查校验和是否匹配，它决定是否有一个有效的帧。

PPP and ethernet both look for the next frame start signal. In the case of Ethernet, it's the preamble, a sequence of 64 alternating bits. If an ethernet decoder sees that, it simply assumes what follows is a frame. By capturing the bits and then checking if the checksum matches, it decides if it has a valid frame.

对于包含FLAG的有效载荷，在PPP中，它被转义为额外的字节来防止这种误解。

As for the payload containing the FLAG, in PPP it is escaped with additional bytes to prevent such misinterpretation.

这篇关于PPP或以太网如何从错误中恢复？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！