PPP 的HDLC封装_(重点).doc

PPP 协议的类HDLC封装摘要： PPP协议(RFC1661)提供了一种在PPP链路之上传送多协议数据报文的方法。本文档描述使用类HDLC帧封装PPP数据包的方法。1.简介： 本文提供对在按位和按字节同步链路和八位数据（无奇偶位）异步链路上帧封装地详细说明，这些链路必须是完全双工，但可以是通过电路切换来实现的双工。 通过转义机制实现控制数据（如：XON/XOFF）在链路上的透明传输，也可以删除链路中的由硬件或软件插入的控制字符。 一些协议允许错误自由传送，有的提供了某一条件下的错误检测措施，有的干脆没有。PPP协议使用HDLC帧监测序列来进行错误检测。这可以很容易地用硬件实现，也可用软件实现。（本文提供了一种软件实现方法）。1.1. 需求说明： 1.1 必要的规范必须: 该词,或者形容词”必需的”,是在协议中必须被满足的.决不能: 协议中绝对被禁止的.应该: “被推荐的”,协议中,如果在某种具体的环境下,有合法的理由可以忽略该项目,但是完整的实现必须理解,在做出一个不同选择之前必须仔细的考虑. 可以: “任选的”,该项目是可选的.一个不包括任选项目的实现必须能与包括该项目的实现进行互操作.实现: 表示协议的一个具体实现. 1.2 术语:1 数据包(datagrame): 在网络层传输的单元.一个数据包可以被封装成一个或多个分组信息包 (packet)通过数据链路层.2 帧(frame):数据链路层传输的单元 .一个正可以包括一个头部,或者还包括一个尾部,还有若干数据单元.3 分组信息包(packet):封装的基本单元,它是网络层与数据链路层之间的接口数据单元.它一般与帧对应,但在数据链路层正在进行分片或者多个分组信息包被集成到单一的帧时出现例外.4 对等方(peer):点到点链路的另一端.5 静默丢弃(silently discard):实现不作任何处理丢弃分组包.实现应该提供纪录这种错误的能力,并且应该在一个统计数其中纪录该事件.2. 物理层需求： PPP可以通过大多数的DTE/DCE（如EIA RS-232-E, EIA RS-422和CCITT V.35）接口进行操作，PPP协议的唯一要求就是全双工通道，可以采用异步方式，位同步方式和字节同步方式，实现PPP的透明数据链路。接口格式：PPP物理层提供8位组接口，对于子八位组的支持程度无具体规定。 传输速率： PPP协议对传输速率无任何特别的限制，它对速率的要求与DTE/DCE接口保持一致。 控制信号： PPP协议不需要类似如RTS,CTS,DCD,DTR之类的控制信号。当然，在条件许可得情况下，使用这些信号可以达到更好的性能，特别，这些信号在LCP选项自动协商时被用来表示UP和DOWN事件【RFC1661】。当这些信号不可用时，实现必须在初始化时发送UP信号，但不能发送DOWN事件。 因为控制信号不是必须的，物理层功能可以被数据链路层功能减弱，隐藏物理层传输的细节，在移动蜂窝无线网络和其它一些快速的链路切换更是如此。 当在同一小区的不同蜂窝之间移动时，尽管在几种不同的频率之间进行切换，但实现时可以把整个小区当作单一的链路。这条链路被认为是与小区控制中心相连，而不是独立的单元无线收发器相连，然而，当链路被切换到一个不同的管理站时，链路应当重建它的配置。 由于数据的突发性，一些实现选择在休眠时间断开物理连接，当数据流开始时在不通知数据链路层的情况下再重建连接。可靠的实现应该避免使用这些方法，应为降低建立的期限将导致安全性的降低，实现应当在链路断开后一定的时间内发送链路DOWN事件，该时间段值得确定方法很有争论，它应根据话务量，呼叫建立时间，安全关系的建立时间等因素来确定。3. 数据链路层：PPP协议使用HDLC帧格式【ISO 3309-1979】封装，最近该标准的第四版对在异步方式使用HDLC帧进行了一些修改。PPP控制过程使用控制域译码。3.1. 帧格式： 下图为PPP的HDL帧格式，该图不包括因传输而引入的停止位和起始位，各个域从左向右传送。FlagAddressControlProtocolInformationPaddingFCSFlagInter-frame Fill or next Address0111111011111111000000118/16 bits*16/32 bits01111110 协议域，信息域，填充域在PPP协议封装中描述【RFC1661】. 标志序列：每一帧都以一个标志序列开始和结束，用来进行帧同步。该标志的二进制表示为01111110(十六进制为： 0x7e)，在两个帧之间只需要一个标志序列，两个连续的标志序列表示一个空帧，空帧将被静默丢弃，该丢弃不被视为FCS校验错误。 地址域：一个8位组，包含二进制序列1 (十六进制为： 0xff)，是所有站的地址，不分配单一站地址，实现时必须识别和接受全站地址（1111111）。以后后可能使用其它长度和数值得地址，通过预先的协商亦可可能使用其它长度和数值得地址，带有无效地址的帧应该被静默丢弃。 控制域：一个8位组，包含二进制序列00000011(十六进制为：0x03)，以后后可能使用其它长度和数值的控制域，通过预先的协商亦可可能使用其它长度和数值得控制域，带有无效控制域的帧应该被静默丢弃。 帧校验域(FCS) ：默认值为两个8位组的FCS，4个8位组的FCS也被定义，它可能在PPP的LCP Extensions中使用【RFC 1570,】。有可能在以后或通过双方同意使用其它的FCS长度。FCS域通过计算地址域，控制域，协议域，信息域，填充域的每一比特尔得到。不包括停止位和开始位，也不包括标志位和FCS域自身。当接收到异步控制转义字符时，在计算FCS之前应被抛弃。附录中有FCS的详细信息。 信息域和填充域的结束位置通过定位结束标志序列，移去校验域后可以确定。3.2. 基本帧格式的修改： 链路控制协议能够协商修改标准的HDLC帧格式，然而，修改后的帧格式总是与标准格式有着明显得差异。地址和控制域压缩：当使用类HDLC标准帧时，地址域和控制域包含十六进制值0xff 和0x03，当使用其它地址域和控制域时，不准协商地址和控制域压缩。在传送时，压缩地址和控制域只是简单地省略。 当接收方收到HDLC帧时，通过检查前两个8位组就可以解压缩，假如帧中含有值0xff和0x03，它们就被视为地址域和控制域，若没有，则认为帧被压缩，地址域和控制域没传送。 通过定义，可使协议域中的第一个8位组永远不为0xff，协议域的值也不能为0x00ff，避免使用协议压缩算法时协议域与信息域的第一个8位组是0x03时引起的歧义。4. 八位组填充帧： 透明性：使用8位组填充过程实现数据的透明传输。定义控制转义8位组为01111101（0x7d）。即使是发送方的最小实现也必须实现转义标志序列和控制转义字节，在校验计算完成后，发送器检测整个帧，每个标志序列、控制转义字节和任何ACCM的8位组，都用两个8位组（一个控制转义8位组需要转义的8位组与0x20进行异或后的值）来组成。接收方必须能正确处理所有的控制转义序列。接收方在进行校验计算之前，每个小于0X20的字节都要进行检查，假如它在接收方的ACCM中，它将被去除。每个转义控制字节也应被去除，再将下一个8位组与0X20异或，除非它是标志序列。 下面举一些例子加以说明，转义数据在链路中传送如下： 0x7e 在链路中传送为： 0x7d, 0x5e. (标志序列) 0x7d在链路中传送为： 0x7d, 0x5d. (控制转义) 0x03在链路中传送为： 0x7d, 0x23. (ETX) 一些有流量控制软件的调制解调器截取发送的DC1和DC3，而忽略第8位（奇偶校验位）。这些数据在链路中以如下方式传输： 0x11在链路中传送为： 0x7d, 0x31. (XON) 0x13在链路中传送为： 0x7d, 0x33. (XOFF) 0x91在链路中传送为： 0x7d, 0xb1. (XON with parity set) 0x93在链路中传送为： 0x7d, 0xb3. (XOFF with parity set)4.3. 无效帧：当帧的长度太小时（使用16位校验时，小于4个八位组）或以一个控制转义字节一个标志序列结束，或异常帧（当需要传送1时却传送了0作为停止位）都被静默丢弃，不作为FCS的校验错误。 4.4. 时间填充：4.4.1. 子帧同步： 对于内部字节的时间间隔填充无具体的规定。标志位必须在帧之间传送。4.4.2. 异步： 8位组之间的空闲时间必须传送连续的“1”（标志链路占用状态），帧之间的空闲可看作8位组之间空闲的扩展，因为标志序列既可作为帧的开始也可作为帧的结束，这样可以每一帧可以节省一个字节，降低延迟增加带宽。在接收了任何帧以后，在另一帧开始之前有一个空闲时间。稳健的传送实现不应采用这些技巧，因为降低延迟的代价就是降低文档性。噪声较大的链路可能使接收器接收垃圾字符并把他们作为接收帧的一部分。假如发送器在发送下一帧之前不发送一个新的标志序列将导致产生无效的帧。4.5. 传送考虑：4.5.1. 字节同步： 定义不同的编码规则是所使用的DTE/DCE的责任，不在本讨论的范围之内。4.5.2. 异步： 所有的八位组按低位优先的原则传送，一个起始位，八个数据位和一个停止位，对于7位异步链路无具体规定。5. 位填充帧：5.1. 标志序列： The Flag Sequence indicates the beginning or end of a frame, and is used for frame synchronization. The bit stream is examined on a bit-by-bit basis for the binary sequence 01111110 (hexadecimal 0x7e). The shared zero mode Flag Sequence 011111101111110 SHOULD NOT be used. When not avoidable, such an implementation MUST ensure that the first Flag Sequence detected (the end of the frame) is promptly communicated to the link layer. Use of the shared zero mode hinders interoperability with bit-synchronous to asynchronous and bit- synchronous to octet-synchronous converters.5.2. 透明性： After FCS computation, the transmitter examines the entire frame between the two Flag Sequences. A 0 bit is inserted after all sequences of five contiguous 1 bits (including the last 5 bits of the FCS) to ensure that a Flag Sequence is not simulated. On reception, prior to FCS computation, any 0 bit that directly follows five contiguous 1 bits is discarded.5.3. 无效帧： Frames which are too short (less than 4 octets when using the 16-bit FCS), or which end with a sequence of more than six 1 bits, are silently discarded, and not counted as a FCS error.5.4. Time Fill There is no provision for inter-octet time fill. The Flag Sequence SHOULD be transmitted during inter-frame time fill. However, certain types of circuit-switched links require the use of mark idle (continuous ones), particularly those that calculate accounting based on periods of bit activity. When mark idle is used on a bit-synchronous link, the implementation MUST ensure at least 15 consecutive 1 bits between Flags during the idle period, and that the Flag Sequence is always generated at the beginning of a frame after an idle period. This differs from practice in ISO 3309, which allows 7 to 14 bit mark idle.5.5. 传送考虑： All octets are transmitted least significant bit first. The definition of various encodings and scrambling is the responsibility of the DTE/DCE equipment in use, and is outside the scope of this specification. While PPP will operate without regard to the underlying representation of the bit stream, lack of standards for transmission will hinder interoperability as surely as lack of data link standards. At speeds of 56 Kbps through 2.0 Mbps, NRZ is currently most widely available, and on that basis is recommended as a default. When configuration of the encoding is allowed, NRZI is recommended as an alternative, because of its relative immunity to signal inversion configuration errors, and instances when it MAY allow connection without an expensive DSU/CSU. Unfortunately, NRZI encoding exacerbates the missing x1 factor of the 16-bit FCS, so that one error in 2*15 goes undetected (instead of one in 2*16), and triple errors are not detected. Therefore, when NRZI is in use, it is recommended that the 32-bit FCS be negotiated, which includes the x1 factor. At higher speeds of up to 45 Mbps, some implementors have chosen the ANSI High Speed Synchronous Interface HSSI. While this experience is currently limited, implementors are encouraged to cooperate in choosing transmission encoding.6. 异步到同步的转换： There may be some use of asynchronous-to-synchronous converters (some built into modems and cellular interfaces), resulting in an asynchronous PPP implementation on one end of a link and a synchronous implementation on the other. It is the responsibility of the converter to do all stuffing conversions during operation. To enable this functionality, synchronous PPP implementations MUST always respond to the Async-Control-Character-Map Configuration Option with the LCP Configure-Ack. However, acceptance of the Configuration Option does not imply that the synchronous implementation will do any ACCM mapping. Instead, all such octet mapping will be performed by the asynchronous-to-synchronous converter.7. 附加的LCP配置选项： The Configuration Option format and basic options are already defined for LCP 1. Up-to-date values of the LCP Option Type field are specified in the most recent Assigned Numbers RFC 10. This document concerns the following values:7.1. 异步控制转义字符映射 (ACCM) 描述：这个配置选项提供了一种在异步链路上进行透明传送控制字符的协商方法。每个异步链路的端点维护两个异步控制字符映射表。接收方的ACCM是32位，发送方ACCM可以达到256位。每一个端点2个，两端共4个，对于异步链路，默认接收方的ACCM是0XFFFFFFFF，默认发送方的ACCM也是0XFFFFFFFF，加上控制转义和标志序列字符自身，再加上其它任何要发送的转义字符（预先配置）。对于其它类型的链路，因为无需转义映射，所有ACCM的默认值是0。默认值允许所有的ASCII控制字符（包括所有的小于0x20的字节，不包括DEL）在所有的数据设备上进行透明传送。发送者亦可用控制转义格式发送从0X40到0Xff之间的值（不包括0x5e）。因为这些字节的值未协商，所以这没有解决接收方不能处理非控制字符的问题。此外，因为技术不能影响第8位，所以这也不能解决只能传送7位数据位的通讯链路的问题。 Note that this specification differs in detail from later amendments, such as 3309:1991/Amendment 2 3. However, such extended transparency is applied only by prior agreement. Use of the transparency methods in this specification constitute a prior agreement with respect to PPP. For compatibility with 3309:1991/Amendment 2, the transmitter MAY escape DEL and ACCM equivalents with the 8th (most significant) bit set. No change is required in the receiving algorithm. Following ACCM negotiation, the transmitter SHOULD cease escaping DEL. However, it is rarely necessary to map all control characters, and often it is unnecessary to map any control characters. The Configuration Option is used to inform the peer which control characters MUST remain mapped when the peer sends them. The peer MAY still send any other octets in mapped format, if it is necessary because of constraints known to the peer. The peer SHOULD Configure-Nak with the logical union of the sets of mapped octets, so that when such octets are spuriously introduced they can be ignored on receipt. 异步控制转义字符映射配置选项的格式如下：（从左到右传送） Type 2 Length 6 ACCM ACCM字段占4个字节，表明要映射的控制字符集合，映射发送时高位在前。每位对应于一个与位置相等的值，假如某一位置0，则该位位置值对于的八位组不需要转义，否则该位要进行转义映射。例如第19位设为0，则ASCII控制字符19(DC3, Control-S)以原始方式发送，无需转义。 A. 推荐的 LCP 选项： 对于高速链路：Magic Number，Link Quality Monitoring，No Address and Control Field ，Compression，No Protocol Field Compression 对于低速链路和异步链路：Async Control Character Map，Magic Number，Address and Control Field Compression，Protocol Field CompressionB. PPP帧的自动识别： 有时候需要监测PPP帧，例如在注册时。下面的字节序列都是有效的PPP LCP侦： 7e ff 03 c0 21 7e ff 7d 23 c0 21 7e 7d df 7d 23 c0 21 Note that the first two forms are not a valid username for Unix. However, only the third form generates a correctly checksummed PPP frame, whenever 03 and ff are taken as the control characters ETX and DEL without regard to parity (they are correct for an even parity link) and discarded. Many implementations deal with this by putting the interface into packet mode when one of the above username patterns are detected during login, without examining the initial PPP checksum. The initial incoming PPP frame is discarded, but a Configure-Request is sent immediately.C. 快速帧校验序列(FCS)的实现：FCS最初设计为硬件实现，当数据位发送到线路时，发送方边发送边计算FCS值，最后将FCS的值和帧结束标志序列发送到线路，完成一个帧的传送。接收方在没有收到帧结束标志序列之前无法确定合适FCS值计算应该结束。因此只有对包括FCS域在内的字节进行校验计算，当到达到帧结束标志序列时，判断FCS的计算结果是否为某一特定值，从而确定帧是否正确。C.1. FCS 表的产生： 下面的代码产生一个表供计算FCS-16查找： /* * The FCS-16 generator polynomial: x*0 + x*5 + x*12 + x*16. */ #define P 0x8408 main() register unsigned int b, v; register int i; printf(typedef unsigned short u16;n); printf(static u16 fcstab256 = ); for (b = 0; ; ) if (b % 8 = 0) printf(n); v = b; for (i = 8; i-; ) v = v & 1 ? (v 1) P : v 1; printf(t0x%04x, v & 0xFFFF); if (+b = 256) break; printf(,); printf(n;n); C.2. FCS-16 的计算方法： 下面的代码提供了一种查表计算FCS16的方法： /* * u16 represents an unsigned 16-bit number. Adjust the typedef for * your hardware. */ typedef unsigned short u16; /* * FCS lookup table as calculated by the table generator. */ static u16 fcstab256 = 0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf, 0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7, 0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e, 0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876, 0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd, 0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5, 0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c, 0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974, 0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb, 0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3, 0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a, 0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72, 0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9, 0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1, 0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738, 0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70, 0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7, 0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff, 0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036, 0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e, 0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5, 0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd, 0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134, 0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c, 0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3, 0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb, 0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232, 0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a, 0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1, 0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9, 0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330, 0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78 ; #define PPPINITFCS16 0xffff /* Initial FCS value */ #define PPPGOODFCS16 0xf0b8 /* Good final FCS value */ /* * Calculate a new fcs given the current fcs and the new data. */ u16 pppfcs16(fcs, cp, len) register u16 fcs; register unsigned char *cp; register int len; ASSERT(sizeof (u16) = 2); ASSERT(u16) -1) 0); while (len-) fcs = (fcs 8) fcstab(fcs *cp+) & 0xff; return (fcs); /* * How to use the fcs */ tryfcs16(cp, len) register unsigned char *cp; register int len; u16 trialfcs; /* add on output */ trialfcs = pppfcs16( PPPINITFCS16, cp, len ); trialfcs = 0xffff; /* complement */ cplen = (trialfcs & 0x00ff); /* least significant byte first */ cplen+1 = (trialfcs 8) & 0x00ff); /* check on input */ trialfcs = pppfcs16( PPPINITFCS16, cp, len + 2 ); if ( trialfcs = PPPGOODFCS16 ) printf(Good FCSn); C.3. 32位FCS 计算方法： /* * The FCS-32 generator polynomial: x*0 + x*1 + x*2 + x*4 + x*5 * + x*7 + x*8 + x*10 + x*11 + x*12 + x*16 * + x*22 + x*23 + x*26 + x*32. */ /* * u32 represents an unsigned 32-bit number. Adjust the typedef for * your hardware. */ typedef unsigned long u32; static u32 fcstab_32256 = 0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3, 0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988, 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91, 0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de, 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7, 0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, 0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5, 0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172, 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b, 0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940, 0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59, 0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116, 0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f, 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924, 0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d, 0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a, 0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433, 0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818, 0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01, 0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e, 0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457, 0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c, 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65, 0x4db26158, 0x