計算機網(wǎng)絡原理-2013ch3數(shù)據(jù)鏈路層_第1頁
計算機網(wǎng)絡原理-2013ch3數(shù)據(jù)鏈路層_第2頁
計算機網(wǎng)絡原理-2013ch3數(shù)據(jù)鏈路層_第3頁
計算機網(wǎng)絡原理-2013ch3數(shù)據(jù)鏈路層_第4頁
計算機網(wǎng)絡原理-2013ch3數(shù)據(jù)鏈路層_第5頁
已閱讀5頁,還剩28頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領

文檔簡介

本講內(nèi)容面向比特的鏈路層協(xié)議HDLCHDLC協(xié)議概述HDLC的幀結(jié)構(gòu)因特網(wǎng)的點對點協(xié)議

PPPPPP

協(xié)議的工作原理PPP

協(xié)議的幀格式PPP

協(xié)議的工作狀態(tài)22013-09-2632013-09-26引言IEEE

802制訂了系列局域網(wǎng)標準,IEEE802涵蓋了物理層和數(shù)據(jù)鏈路層IEEE802.3:以太網(wǎng)IEEE802.4:令牌總線IEEE802.5:令牌環(huán)IEEE802.11

無線局域網(wǎng)WAN數(shù)據(jù)鏈路層標準HDLCPPPX.25Frame

Relay廣域網(wǎng)的數(shù)據(jù)傳輸方式廣域網(wǎng)分組交換電路交換點到點型X.25幀中繼ISDNPPPHDLC42013-09-26數(shù)據(jù)鏈路層向網(wǎng)絡層提供服務數(shù)據(jù)鏈路層向網(wǎng)絡層提供的三中可能的服務:1.無確認的無連接服務※

不建立邏輯

,接收方不確認,對丟失的幀測※適合于線路錯誤率很低,丟失幀檢測可交由上層完成,就大多數(shù)LAN在數(shù)據(jù)鏈路層上都使用該服務。有確認的無連接服務※

不建立邏輯

,接收方確認,對丟失的幀可檢測并要求發(fā)送方重發(fā),適合不可靠的信道,比如無線系統(tǒng)。有確認的面向連接服務※建立邏輯鏈路,接收方確認,對丟失的幀可檢測并要求發(fā)送方重發(fā),并對幀進行差錯檢測和糾正。52013-09-26數(shù)據(jù)鏈路層協(xié)議實例:HDLC

協(xié)議概述1974年,IBM

公司推出了面向比特的規(guī)程SDLC(Synchronous

Data

Link

Control)。后來ISO

把SDLC

修改后稱為HDLC(High-levelDataLinkControl),譯為高級數(shù)據(jù)鏈路控制,作為國際標準ISO

3309。CCITT

則將

HDLC

再修改后稱為鏈路接入規(guī)程LAP(Link

Access

Procedure)。 ,HDLC

的新版本又把

LAP

修改為

LAPB,“B”表示平衡型

(Balanced),所以LAPB

叫做鏈路接入規(guī)程(平衡型)。62013-09-2672013-09-26HDLC產(chǎn)生背景面向字符的通信規(guī)程報文格式不一樣傳輸透明性不好停止等待發(fā)送方式,傳輸效率低面向比特的通信規(guī)程以比特作為傳輸控制信息的基本單元數(shù)據(jù)幀與控制幀格式相同傳輸透明性好連續(xù)發(fā)送,傳輸效率高基本概念三種站類型主站:發(fā)送命令幀、數(shù)據(jù)信息幀和應答幀,并負責控制鏈路次站(從站):接收命令幀,向主站發(fā)送響應幀,并配合主站進行鏈路控制復合站(組合站):同時具有主站和從站功能兩種數(shù)據(jù)鏈路結(jié)構(gòu)配置非平衡配置:點---點工作,點---多點工作平衡配置:點---點工作(a)不平衡式鏈路結(jié)構(gòu)82013-09-26(b)平衡式鏈路結(jié)構(gòu)92013-09-26基本概念三種數(shù)據(jù)傳送方式正常響應方式NRM

(Normal

ResponseMode):數(shù)據(jù)傳輸由主站發(fā)起,從站只能響應主站的輪詢(poll)異步響應方式ARM

(AsynchronousResponse

Mode):從站可以主動發(fā)送響應幀異步平衡方式ABM

(Asynchronous

BalanceMode):任一復合站都可以發(fā)起數(shù)據(jù)傳輸HDLC

工作方式102013-09-26112013-09-26HDLC

的幀結(jié)構(gòu)標志F地址A控制C信息Info幀檢驗序列FCS標志F比特80111111088可變168FLAG

在接收端只要找到標志字段就可確定一個幀的位置ADDRESS

FIELD命令幀:對方站地址;響應幀:本站地址FCS

檢驗區(qū)間透明傳輸區(qū)間FRAME

CHECKCRCINFORMATION

FIELD數(shù)據(jù),0或者多位需要傳輸?shù)男畔ONTROL

FIELD最復雜,用來包含幀序列號以及協(xié)議信息等控制信息,實現(xiàn)HDLC

的許多重要功能122013-09-26透明傳輸采用零比特填充法

就可傳送任意組合的比特流,或者說,就可實現(xiàn)數(shù)據(jù)鏈路層的透明傳輸。當連續(xù)傳輸兩個幀時,前一個幀的結(jié)束標

志字段

F

可以兼作后一幀的起始標志字段。當暫時沒有信息傳送時,可以連續(xù)發(fā)送標

志字段,使收端可以一直和發(fā)端保持同步。HDLC

幀的控制字段標志F地址A控制C信息Info幀檢驗序列FCS標志F比特888可變1680N(S)P/FN(R)10SP/FN(R)11MP/FM1

2

3

4

5

6

7

8I

幀:S幀:U幀:132013-09-26I(Information)幀信息幀(I幀)用于提供面向連接的數(shù)據(jù)傳輸。協(xié)議使用了滑動窗口協(xié)議,序列號的長度是3位,在任何時刻允許7個(231)未被確認的幀處于等待狀態(tài)。發(fā)送站用N(S)來所發(fā)送的幀序號。接收站用N(R)給出確認,表示已正確接收N(R)1個幀,下一個要接收的幀序號為N(R)。0N(S)P/FN(R)142013-09-260Send

countPoll/fina

bitReceive

countHDLC:

Sliding

WindowAcknowledgement234561123456Send

count Receive

count7070123456Send

count7

0123456Receive

count7

001010152013-09-26frame.sendCount

:=

sendCountframe.receiveCount

:=

receiveCountframe.Data

:=

data…frame.sendsendCount++If

checksOutOK(frame.CRC)

thenIfframe.sendCount

=

receiveCount

thenbeginFrame.acceptsendCount

:=frame.receiveCountreceiveCount++end16120S(Supervisory)幀

幀(S幀)用于在面向連接的數(shù)據(jù)傳輸過程中執(zhí)行數(shù)據(jù)鏈路的

功能,

如確認、要求重發(fā)和請求暫停等。S字段用于定義S幀的類型,共有4種S幀,S幀不含信息字段,故不設發(fā)送序號。10SP/FN(R)ACKNAKU(Unnumbered)幀11MP/FM1

2

3

4

5

6

7

8無

幀(U幀):用于提供無連接的數(shù)據(jù)傳輸和鏈路控制功能,如設置工作方式、拆除鏈路等。其中,M字段(第3、4、6、7、8

比特)用于定義U幀的類型,共有19種U幀。無編號幀主要起控制作用,可在需要時隨時發(fā)出。172013-09-26182013-09-26P/F位若P/F值為零,則該比特并沒有任何意義。只有當

P/F

值為

1時才具有意義。注意:在不同的數(shù)據(jù)傳送方式中,P/F

比特的用法是不一樣的。在說明幀的傳送過程中,為了更清楚地表示P/F比特的作用,往往將它寫為P

比特或F

比特。探詢位P是主站用來請求(探詢)次站發(fā)送信息或作出響應的。終結(jié)位F是次站用來響應主站探詢的。數(shù)據(jù)鏈路連接建立和拆除示例192013-09-26HDLC三種控制幀小結(jié)202013-09-26212013-09-26本講內(nèi)容面向比特的鏈路層協(xié)議HDLCHDLC協(xié)議概述HDLC的幀結(jié)構(gòu)因特網(wǎng)的點對點協(xié)議

PPPPPP

協(xié)議的工作原理PPP

協(xié)議的幀格式PPP

協(xié)議的工作狀態(tài)因特網(wǎng)的點對點協(xié)議PPPPPP

協(xié)議的工作原理現(xiàn)在全世界使用得最多的數(shù)據(jù)鏈路層協(xié)議是點對點協(xié)議PPP(Point-to-PointProtocol)。用戶使用撥號

線接入因特網(wǎng)時,一般都是使用

PPP

協(xié)議。222013-09-26用戶撥號入網(wǎng)的示意圖路由器調(diào)制解調(diào)器調(diào)制解調(diào)器因特網(wǎng)服務提供者(ISP)用戶家庭撥號

線使用

TCP/IP

的PPP

連接使用

TCP/IP

的客戶進程路由選擇進程至因特網(wǎng)…PC

機232013-09-26242013-09-26PPP

協(xié)議1992

年制訂了PPP

協(xié)議。經(jīng)過

1993

年和1994

年的修訂,現(xiàn)在的PPP

協(xié)議已成為因特網(wǎng)的正式標準[RFC

1661]。PPP協(xié)議有三個組成部分一個將IP

數(shù)據(jù)報封裝到串行鏈路的方法。鏈路控制協(xié)議LCP(Link

Control

Protocol)。網(wǎng)絡控制協(xié)議NCP(Network

ControlProtocol)。PPP協(xié)議組成PPP協(xié)議主要由鏈路控制協(xié)議(LCP)、網(wǎng)絡控制協(xié)議族(NCPs)和用于

方面的驗證協(xié)議族(PAP和CHAP)組成。PPP

EncapsulationTCP/IPNovell

IPXAppleTalkMultiple

protocolencapsulations

usingNCPs

in

PPPLink

setup

and

controlusing

LCP

in

PPP252013-09-26PPP協(xié)議棧IP

IPX

其他網(wǎng)絡協(xié)議NCP網(wǎng)絡控制協(xié)議驗證;其他選項LCP物理介質(zhì)(同步/異步)物理層數(shù)據(jù)鏈路層網(wǎng)絡層262013-09-26272013-09-26PPP

協(xié)議的幀格式PPP

的幀格式和HDLC

的相似。標志字段F

仍為

0x7E(符號“0x”表示后面的字符是用十六進制表示。十六進制的7E的二進制表示是01111110)。地址字段A

只置為

0xFF。地址字段實際上并不起作用??刂谱侄蜟

通常置為

0x03。PPP

是面向字節(jié)的,所有的PPP幀的長度都是整數(shù)字節(jié)。PPP

協(xié)議的幀格式21字節(jié)1

1

12PPP

幀PPP

有一個

2

個字節(jié)的協(xié)議字段。當協(xié)議字段為0x0021

時,PPP

幀的信息字段就是IP數(shù)據(jù)報。若為0xC021,則信息字段是PPP

鏈路控制數(shù)據(jù)。若為

0x8021,則表示這是網(wǎng)絡控制數(shù)據(jù)。先發(fā)送首部IP

數(shù)據(jù)報尾部F7EAFFC03協(xié)議信

分不超過1500

字節(jié)FCSF7E282013-09-26292013-09-26透明傳輸問題當PPP

用在同步傳輸鏈路時,協(xié)議規(guī)定采用硬件來完成比特填充(和HDLC

的做法一樣)。當PPP

用在異步傳輸時,就使用一種特殊的字符填充法。302013-09-26字符填充法將信息字段中出現(xiàn)的每一個0x7E字節(jié)轉(zhuǎn)變成為

2

字節(jié)序列(0x7D,0x5E)。若信息字段中出現(xiàn)一個0x7D

的字節(jié),則將其轉(zhuǎn)變成為

2

字節(jié)序列(0x7D,0x5D)。若信息字段中出現(xiàn)ASCII

碼的控制字符(即數(shù)值小于0x20的字符),則在該字符前面要加入一個0x7D

字節(jié),同時將該字符的編碼加以改變。312013-09-26不提供使用序號和確認的可靠傳輸PPP協(xié)議之所以不使用序號和確認機制是出于以下的考慮:在數(shù)據(jù)鏈路層出現(xiàn)差錯的概率不大時,使用比較簡單的P

溫馨提示

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

評論

0/150

提交評論