PPP 的HDLC封裝重點(diǎn)_第1頁(yè)
PPP 的HDLC封裝重點(diǎn)_第2頁(yè)
PPP 的HDLC封裝重點(diǎn)_第3頁(yè)
PPP 的HDLC封裝重點(diǎn)_第4頁(yè)
PPP 的HDLC封裝重點(diǎn)_第5頁(yè)
已閱讀5頁(yè),還剩8頁(yè)未讀 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶(hù)提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、 PPP 協(xié)議的類(lèi)HDLC封裝摘要: PPP協(xié)議(RFC1661)提供了一種在PPP鏈路之上傳送多協(xié)議數(shù)據(jù)報(bào)文的方法。本文檔描述使用類(lèi)HDLC幀封裝PPP數(shù)據(jù)包的方法。1.簡(jiǎn)介: 本文提供對(duì)在按位和按字節(jié)同步鏈路和八位數(shù)據(jù)(無(wú)奇偶位)異步鏈路上幀封裝地詳細(xì)說(shuō)明,這些鏈路必須是完全雙工,但可以是通過(guò)電路切換來(lái)實(shí)現(xiàn)的雙工。 通過(guò)轉(zhuǎn)義機(jī)制實(shí)現(xiàn)控制數(shù)據(jù)(如:XON/XOFF)在鏈路上的透明傳輸,也可以刪除鏈路中的由硬件或軟件插入的控制字符。 一些協(xié)議允許錯(cuò)誤自由傳送,有的提供了某一條件下的錯(cuò)誤檢測(cè)措施,有的干脆沒(méi)有。PPP協(xié)議使用HDLC幀監(jiān)測(cè)序列來(lái)進(jìn)行錯(cuò)誤檢測(cè)。這可以很容易地用硬件實(shí)現(xiàn),也可用軟件實(shí)

2、現(xiàn)。(本文提供了一種軟件實(shí)現(xiàn)方法)。1.1. 需求說(shuō)明: 1.1 必要的規(guī)范必須: 該詞,或者形容詞”必需的”,是在協(xié)議中必須被滿(mǎn)足的.決不能: 協(xié)議中絕對(duì)被禁止的.應(yīng)該: “被推薦的”,協(xié)議中,如果在某種具體的環(huán)境下,有合法的理由可以忽略該項(xiàng)目,但是完整的實(shí)現(xiàn)必須理解,在做出一個(gè)不同選擇之前必須仔細(xì)的考慮. 可以: “任選的”,該項(xiàng)目是可選的.一個(gè)不包括任選項(xiàng)目的實(shí)現(xiàn)必須能與包括該項(xiàng)目的實(shí)現(xiàn)進(jìn)行互操作.實(shí)現(xiàn): 表示協(xié)議的一個(gè)具體實(shí)現(xiàn). 1.2 術(shù)語(yǔ):1> 數(shù)據(jù)包(datagrame): 在網(wǎng)絡(luò)層傳輸?shù)膯卧?一個(gè)數(shù)據(jù)包可以被封裝成一個(gè)或多個(gè)分組信息包 (packet)通過(guò)數(shù)據(jù)鏈路層.2&

3、gt; 幀(frame):數(shù)據(jù)鏈路層傳輸?shù)膯卧?.一個(gè)正可以包括一個(gè)頭部,或者還包括一個(gè)尾部,還有若干數(shù)據(jù)單元.3> 分組信息包(packet):封裝的基本單元,它是網(wǎng)絡(luò)層與數(shù)據(jù)鏈路層之間的接口數(shù)據(jù)單元.它一般與幀對(duì)應(yīng),但在數(shù)據(jù)鏈路層正在進(jìn)行分片或者多個(gè)分組信息包被集成到單一的幀時(shí)出現(xiàn)例外.4> 對(duì)等方(peer):點(diǎn)到點(diǎn)鏈路的另一端.5> 靜默丟棄(silently discard):實(shí)現(xiàn)不作任何處理丟棄分組包.實(shí)現(xiàn)應(yīng)該提供紀(jì)錄這種錯(cuò)誤的能力,并且應(yīng)該在一個(gè)統(tǒng)計(jì)數(shù)其中紀(jì)錄該事件.2. 物理層需求: PPP可以通過(guò)大多數(shù)的DTE/DCE(如EIA RS-232-E, EIA

4、RS-422和CCITT V.35)接口進(jìn)行操作,PPP協(xié)議的唯一要求就是全雙工通道,可以采用異步方式,位同步方式和字節(jié)同步方式,實(shí)現(xiàn)PPP的透明數(shù)據(jù)鏈路。接口格式:PPP物理層提供8位組接口,對(duì)于子八位組的支持程度無(wú)具體規(guī)定。 傳輸速率: PPP協(xié)議對(duì)傳輸速率無(wú)任何特別的限制,它對(duì)速率的要求與DTE/DCE接口保持一致。 控制信號(hào): PPP協(xié)議不需要類(lèi)似如RTS,CTS,DCD,DTR之類(lèi)的控制信號(hào)。當(dāng)然,在條件許可得情況下,使用這些信號(hào)可以達(dá)到更好的性能,特別,這些信號(hào)在LCP選項(xiàng)自動(dòng)協(xié)商時(shí)被用來(lái)表示UP和DOWN事件【RFC1661】。當(dāng)這些信號(hào)不可用時(shí),實(shí)現(xiàn)必須在初始化時(shí)發(fā)送UP信號(hào),

5、但不能發(fā)送DOWN事件。 因?yàn)榭刂菩盘?hào)不是必須的,物理層功能可以被數(shù)據(jù)鏈路層功能減弱,隱藏物理層傳輸?shù)募?xì)節(jié),在移動(dòng)蜂窩無(wú)線(xiàn)網(wǎng)絡(luò)和其它一些快速的鏈路切換更是如此。 當(dāng)在同一小區(qū)的不同蜂窩之間移動(dòng)時(shí),盡管在幾種不同的頻率之間進(jìn)行切換,但實(shí)現(xiàn)時(shí)可以把整個(gè)小區(qū)當(dāng)作單一的鏈路。這條鏈路被認(rèn)為是與小區(qū)控制中心相連,而不是獨(dú)立的單元無(wú)線(xiàn)收發(fā)器相連,然而,當(dāng)鏈路被切換到一個(gè)不同的管理站時(shí),鏈路應(yīng)當(dāng)重建它的配置。 由于數(shù)據(jù)的突發(fā)性,一些實(shí)現(xiàn)選擇在休眠時(shí)間斷開(kāi)物理連接,當(dāng)數(shù)據(jù)流開(kāi)始時(shí)在不通知數(shù)據(jù)鏈路層的情況下再重建連接。可靠的實(shí)現(xiàn)應(yīng)該避免使用這些方法,應(yīng)為降低建立的期限將導(dǎo)致安全性的降低,實(shí)現(xiàn)應(yīng)當(dāng)在鏈路斷開(kāi)后一定

6、的時(shí)間內(nèi)發(fā)送鏈路DOWN事件,該時(shí)間段值得確定方法很有爭(zhēng)論,它應(yīng)根據(jù)話(huà)務(wù)量,呼叫建立時(shí)間,安全關(guān)系的建立時(shí)間等因素來(lái)確定。3. 數(shù)據(jù)鏈路層:PPP協(xié)議使用HDLC幀格式【ISO 3309-1979】封裝,最近該標(biāo)準(zhǔn)的第四版對(duì)在異步方式使用HDLC幀進(jìn)行了一些修改。PPP控制過(guò)程使用控制域譯碼。3.1. 幀格式: 下圖為PPP的HDL幀格式,該圖不包括因傳輸而引入的停止位和起始位,各個(gè)域從左向右傳送。FlagAddressControlProtocolInformationPaddingFCSFlagInter-frame Fill or next Address0111111011111111

7、000000118/16 bits*16/32 bits01111110 協(xié)議域,信息域,填充域在PPP協(xié)議封裝中描述【RFC1661】. 標(biāo)志序列:每一幀都以一個(gè)標(biāo)志序列開(kāi)始和結(jié)束,用來(lái)進(jìn)行幀同步。該標(biāo)志的二進(jìn)制表示為01111110(十六進(jìn)制為: 0x7e),在兩個(gè)幀之間只需要一個(gè)標(biāo)志序列,兩個(gè)連續(xù)的標(biāo)志序列表示一個(gè)空幀,空幀將被靜默丟棄,該丟棄不被視為FCS校驗(yàn)錯(cuò)誤。 地址域:一個(gè)8位組,包含二進(jìn)制序列1 (十六進(jìn)制為: 0xff),是所有站的地址,不分配單一站地址,實(shí)現(xiàn)時(shí)必須識(shí)別和接受全站地址(1111111)。以后后可能使用其它長(zhǎng)度和數(shù)值得地址,通過(guò)預(yù)先的協(xié)商亦可可能使用其它長(zhǎng)度和數(shù)

8、值得地址,帶有無(wú)效地址的幀應(yīng)該被靜默丟棄。 控制域:一個(gè)8位組,包含二進(jìn)制序列00000011(十六進(jìn)制為:0x03),以后后可能使用其它長(zhǎng)度和數(shù)值的控制域,通過(guò)預(yù)先的協(xié)商亦可可能使用其它長(zhǎng)度和數(shù)值得控制域,帶有無(wú)效控制域的幀應(yīng)該被靜默丟棄。 幀校驗(yàn)域(FCS) :默認(rèn)值為兩個(gè)8位組的FCS,4個(gè)8位組的FCS也被定義,它可能在PPP的LCP Extensions中使用【RFC 1570,】。有可能在以后或通過(guò)雙方同意使用其它的FCS長(zhǎng)度。FCS域通過(guò)計(jì)算地址域,控制域,協(xié)議域,信息域,填充域的每一比特爾得到。不包括停止位和開(kāi)始位,也不包括標(biāo)志位和FCS域自身。當(dāng)接收到異步控制轉(zhuǎn)義字符時(shí),在計(jì)

9、算FCS之前應(yīng)被拋棄。附錄中有FCS的詳細(xì)信息。 信息域和填充域的結(jié)束位置通過(guò)定位結(jié)束標(biāo)志序列,移去校驗(yàn)域后可以確定。3.2. 基本幀格式的修改: 鏈路控制協(xié)議能夠協(xié)商修改標(biāo)準(zhǔn)的HDLC幀格式,然而,修改后的幀格式總是與標(biāo)準(zhǔn)格式有著明顯得差異。地址和控制域壓縮:當(dāng)使用類(lèi)HDLC標(biāo)準(zhǔn)幀時(shí),地址域和控制域包含十六進(jìn)制值0xff 和0x03,當(dāng)使用其它地址域和控制域時(shí),不準(zhǔn)協(xié)商地址和控制域壓縮。在傳送時(shí),壓縮地址和控制域只是簡(jiǎn)單地省略。 當(dāng)接收方收到HDLC幀時(shí),通過(guò)檢查前兩個(gè)8位組就可以解壓縮,假如幀中含有值0xff和0x03,它們就被視為地址域和控制域,若沒(méi)有,則認(rèn)為幀被壓縮,地址域和控制域沒(méi)傳

10、送。 通過(guò)定義,可使協(xié)議域中的第一個(gè)8位組永遠(yuǎn)不為0xff,協(xié)議域的值也不能為0x00ff,避免使用協(xié)議壓縮算法時(shí)協(xié)議域與信息域的第一個(gè)8位組是0x03時(shí)引起的歧義。4. 八位組填充幀: 透明性:使用8位組填充過(guò)程實(shí)現(xiàn)數(shù)據(jù)的透明傳輸。定義控制轉(zhuǎn)義8位組為01111101(0x7d)。即使是發(fā)送方的最小實(shí)現(xiàn)也必須實(shí)現(xiàn)轉(zhuǎn)義標(biāo)志序列和控制轉(zhuǎn)義字節(jié),在校驗(yàn)計(jì)算完成后,發(fā)送器檢測(cè)整個(gè)幀,每個(gè)標(biāo)志序列、控制轉(zhuǎn)義字節(jié)和任何ACCM的8位組,都用兩個(gè)8位組(一個(gè)控制轉(zhuǎn)義8位組需要轉(zhuǎn)義的8位組與0x20進(jìn)行異或后的值)來(lái)組成。接收方必須能正確處理所有的控制轉(zhuǎn)義序列。接收方在進(jìn)行校驗(yàn)計(jì)算之前,每個(gè)小于0X20的字

11、節(jié)都要進(jìn)行檢查,假如它在接收方的ACCM中,它將被去除。每個(gè)轉(zhuǎn)義控制字節(jié)也應(yīng)被去除,再將下一個(gè)8位組與0X20異或,除非它是標(biāo)志序列。 下面舉一些例子加以說(shuō)明,轉(zhuǎn)義數(shù)據(jù)在鏈路中傳送如下: 0x7e 在鏈路中傳送為: 0x7d, 0x5e. (標(biāo)志序列) 0x7d在鏈路中傳送為: 0x7d, 0x5d. (控制轉(zhuǎn)義) 0x03在鏈路中傳送為: 0x7d, 0x23. (ETX) 一些有流量控制軟件的調(diào)制解調(diào)器截取發(fā)送的DC1和DC3,而忽略第8位(奇偶校驗(yàn)位)。這些數(shù)據(jù)在鏈路中以如下方式傳輸: 0x11在鏈路中傳送為: 0x7d, 0x31. (XON) 0x13在鏈路中傳送為: 0x7d, 0

12、x33. (XOFF) 0x91在鏈路中傳送為: 0x7d, 0xb1. (XON with parity set) 0x93在鏈路中傳送為: 0x7d, 0xb3. (XOFF with parity set)4.3. 無(wú)效幀:當(dāng)幀的長(zhǎng)度太小時(shí)(使用16位校驗(yàn)時(shí),小于4個(gè)八位組)或以一個(gè)控制轉(zhuǎn)義字節(jié)一個(gè)標(biāo)志序列結(jié)束,或異常幀(當(dāng)需要傳送1時(shí)卻傳送了0作為停止位)都被靜默丟棄,不作為FCS的校驗(yàn)錯(cuò)誤。 4.4. 時(shí)間填充:4.4.1. 子幀同步: 對(duì)于內(nèi)部字節(jié)的時(shí)間間隔填充無(wú)具體的規(guī)定。標(biāo)志位必須在幀之間傳送。4.4.2. 異步: 8位組之間的空閑時(shí)間必須傳送連續(xù)的“1”(標(biāo)志鏈路占用狀態(tài)),

13、幀之間的空閑可看作8位組之間空閑的擴(kuò)展,因?yàn)闃?biāo)志序列既可作為幀的開(kāi)始也可作為幀的結(jié)束,這樣可以每一幀可以節(jié)省一個(gè)字節(jié),降低延遲增加帶寬。在接收了任何幀以后,在另一幀開(kāi)始之前有一個(gè)空閑時(shí)間。穩(wěn)健的傳送實(shí)現(xiàn)不應(yīng)采用這些技巧,因?yàn)榻档脱舆t的代價(jià)就是降低文檔性。噪聲較大的鏈路可能使接收器接收垃圾字符并把他們作為接收幀的一部分。假如發(fā)送器在發(fā)送下一幀之前不發(fā)送一個(gè)新的標(biāo)志序列將導(dǎo)致產(chǎn)生無(wú)效的幀。4.5. 傳送考慮:4.5.1. 字節(jié)同步: 定義不同的編碼規(guī)則是所使用的DTE/DCE的責(zé)任,不在本討論的范圍之內(nèi)。4.5.2. 異步: 所有的八位組按低位優(yōu)先的原則傳送,一個(gè)起始位,八個(gè)數(shù)據(jù)位和一個(gè)停止位,對(duì)

14、于7位異步鏈路無(wú)具體規(guī)定。5. 位填充幀:5.1. 標(biāo)志序列: 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). used. When not avoidable, such an implementation MUST ensure that

15、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

16、 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 direc

17、tly follows five contiguous "1" bits is discarded.5.3. 無(wú)效幀: 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 provisi

18、on 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 o

19、n 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

20、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 representatio

21、n 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,

22、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

23、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.

24、 While this experience is currently limited, implementors are encouraged to cooperate in choosing transmission encoding.6. 異步到同步的轉(zhuǎn)換: There may be some use of asynchronous-to-synchronous converters (some built into modems and cellular interfaces), resulting in an asynchronous PPP implementation on on

25、e 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

26、 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配置選項(xiàng): The Configuration Option format and basic opt

27、ions 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. 異步控制轉(zhuǎn)義字符映射 (ACCM) 描述:這個(gè)配置選項(xiàng)提供了一種在異步鏈路上進(jìn)行透明傳送控制字符的協(xié)商方法。每個(gè)異步鏈路的端點(diǎn)維護(hù)兩個(gè)異步控制字符映射表。接收方的ACCM是32位,發(fā)送方ACCM可

28、以達(dá)到256位。每一個(gè)端點(diǎn)2個(gè),兩端共4個(gè),對(duì)于異步鏈路,默認(rèn)接收方的ACCM是0XFFFFFFFF,默認(rèn)發(fā)送方的ACCM也是0XFFFFFFFF,加上控制轉(zhuǎn)義和標(biāo)志序列字符自身,再加上其它任何要發(fā)送的轉(zhuǎn)義字符(預(yù)先配置)。對(duì)于其它類(lèi)型的鏈路,因?yàn)闊o(wú)需轉(zhuǎn)義映射,所有ACCM的默認(rèn)值是0。默認(rèn)值允許所有的ASCII控制字符(包括所有的小于0x20的字節(jié),不包括DEL)在所有的數(shù)據(jù)設(shè)備上進(jìn)行透明傳送。發(fā)送者亦可用控制轉(zhuǎn)義格式發(fā)送從0X40到0Xff之間的值(不包括0x5e)。因?yàn)檫@些字節(jié)的值未協(xié)商,所以這沒(méi)有解決接收方不能處理非控制字符的問(wèn)題。此外,因?yàn)榧夹g(shù)不能影響第8位,所以這也不能解決只能傳送

29、7位數(shù)據(jù)位的通訊鏈路的問(wèn)題。 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 wit

30、h 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

31、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

32、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. 異步控制轉(zhuǎn)義字符映射配置選項(xiàng)的格式如下:(從左到右傳送) Type 2 Length 6 ACCM ACCM字段占4個(gè)字節(jié),表明要映射的控制字符集合,映射發(fā)送時(shí)高位在前。每位對(duì)應(yīng)于一個(gè)

33、與位置相等的值,假如某一位置0,則該位位置值對(duì)于的八位組不需要轉(zhuǎn)義,否則該位要進(jìn)行轉(zhuǎn)義映射。例如第19位設(shè)為0,則ASCII控制字符19(DC3, Control-S)以原始方式發(fā)送,無(wú)需轉(zhuǎn)義。 A. 推薦的 LCP 選項(xiàng): 對(duì)于高速鏈路:Magic Number,Link Quality Monitoring,No Address and Control Field ,Compression,No Protocol Field Compression 對(duì)于低速鏈路和異步鏈路:Async Control Character Map,Magic Number,Address and Contro

34、l Field Compression,Protocol Field CompressionB. PPP幀的自動(dòng)識(shí)別: 有時(shí)候需要監(jiān)測(cè)PPP幀,例如在注冊(cè)時(shí)。下面的字節(jié)序列都是有效的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, whenev

35、er 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 exa

36、mining the initial PPP checksum. The initial incoming PPP frame is discarded, but a Configure-Request is sent immediately.C. 快速幀校驗(yàn)序列(FCS)的實(shí)現(xiàn):FCS最初設(shè)計(jì)為硬件實(shí)現(xiàn),當(dāng)數(shù)據(jù)位發(fā)送到線(xiàn)路時(shí),發(fā)送方邊發(fā)送邊計(jì)算FCS值,最后將FCS的值和幀結(jié)束標(biāo)志序列發(fā)送到線(xiàn)路,完成一個(gè)幀的傳送。接收方在沒(méi)有收到幀結(jié)束標(biāo)志序列之前無(wú)法確定合適FCS值計(jì)算應(yīng)該結(jié)束。因此只有對(duì)包括FCS域在內(nèi)的字節(jié)進(jìn)行校驗(yàn)計(jì)算,當(dāng)?shù)竭_(dá)到幀結(jié)束標(biāo)志序列時(shí),判斷FCS的計(jì)算結(jié)果是否為某一特定值,從

37、而確定幀是否正確。C.1. FCS 表的產(chǎn)生: 下面的代碼產(chǎn)生一個(gè)表供計(jì)算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 %

38、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 的計(jì)算方法: 下面的代碼提供了一種查表計(jì)算FCS16的方法: /* * u16 represents an unsigned 16-bit

39、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,

40、 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, 0x5

41、4b5, 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,

42、 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, 0x9

43、581, 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,

44、 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, 0x0

45、c60, 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,

46、 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 pppfcs1

47、6(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;

48、 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

49、); if ( trialfcs = PPPGOODFCS16 ) printf("Good FCSn"); C.3. 32位FCS 計(jì)算方法: /* * 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 * you

50、r 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, 0x84

51、be41de, 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7, 0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, 0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5, 0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172, 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b, 0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940, 0x32

52、d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59, 0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116, 0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f, 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924, 0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d, 0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a, 0x71b18589, 0x06

53、b6b51f, 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, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2, 0

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶(hù)所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶(hù)上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶(hù)上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶(hù)因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

評(píng)論

0/150

提交評(píng)論