第3章:物理鏈路層協(xié)議v4.7_第1頁
第3章:物理鏈路層協(xié)議v4.7_第2頁
第3章:物理鏈路層協(xié)議v4.7_第3頁
第3章:物理鏈路層協(xié)議v4.7_第4頁
第3章:物理鏈路層協(xié)議v4.7_第5頁
已閱讀5頁,還剩142頁未讀, 繼續(xù)免費閱讀

下載本文檔

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

文檔簡介

第3章

物理鏈路層協(xié)議

或者主機-網(wǎng)絡(luò)層協(xié)議

(LAN協(xié)議&WAN協(xié)議)《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議2在TCP/IP協(xié)議族中,物理鏈路層主要有三個目的:(1)為IP模塊發(fā)送和接收IP數(shù)據(jù)報;(2)為ARP模塊發(fā)送ARP請求和接收ARP應(yīng)答;(3)為RARP發(fā)送RARP請求和接收RARP應(yīng)答。TCP/IP支持多種不同的鏈路層協(xié)議,這取決于網(wǎng)絡(luò)所使用的硬件,如以太網(wǎng)、令牌環(huán)網(wǎng)、FDDI(光纖分布式數(shù)據(jù)接口)及RS-232串行線路等?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議3本章學習要求:了解:局域網(wǎng)協(xié)議--IEEE802系列。掌握:以太網(wǎng)第二版、802.3和802.1Q。掌握:SLIP&PPP。了解:面向字符型數(shù)據(jù)鏈路層協(xié)議實例—BSC。掌握:面向比特型數(shù)據(jù)鏈路層協(xié)議實例—HDLC。了解:FR&ATM?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議43.1基本概念

3.1.1物理線路與數(shù)據(jù)鏈路線路—鏈路物理線路—數(shù)據(jù)鏈路《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議5實際數(shù)據(jù)路徑與虛擬數(shù)據(jù)路徑《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議63.2局域網(wǎng)協(xié)議

本節(jié)是關(guān)于局域網(wǎng)協(xié)議的概述,其內(nèi)容涵蓋了IEEE802系列數(shù)據(jù)鏈路層協(xié)議。數(shù)據(jù)鏈路層的各種服務(wù)如圖所示。《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議73.2局域網(wǎng)協(xié)議Ethernet幀格式的發(fā)展 1980DEC,Intel,Xerox制訂了EthernetI的標準

1982DEC,Intel,Xerox又制訂了EhternetII的標準

1982IEEE開始研究Ethernet的國際標準802.3

1983迫不及待的Novell基于IEEE的802.3的原始版開發(fā)了專用的Ethernet幀格式

1985IEEE推出IEEE802.3規(guī)范

后來為解決EthernetII與802.3幀格式的兼容問題推出折衷的EthernetSNAP格式《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議8局域網(wǎng)(協(xié)議)封裝分隔在數(shù)據(jù)鏈路層的幀須能相互區(qū)分.對于每一幀,幀的開始和結(jié)束位置被標識出來,幀的有效載荷必須和數(shù)據(jù)鏈路層的頭和尾區(qū)分出來.協(xié)議標識因為許多組織使用諸如TCP/IP,IPX或AppleTalk這樣的多協(xié)議族,所以協(xié)議必須相互區(qū)分.地址分配對于共享訪問的局域網(wǎng)(如以太網(wǎng))技術(shù),源節(jié)點和目標節(jié)點必須被標識.位級別的完整性檢查為了偵測到被硬件接收到的整個幀的位級別的錯誤,需要以校驗和形式進行位級完整性檢查(能檢測到所有的單個位錯誤!).校驗和由源節(jié)點計算,并被包含在幀頭或幀尾中.目標節(jié)點重新計算校驗和,并且檢查是否與包含的校驗和不同.如果校驗和匹配,那么該幀被認為沒有位級別的錯誤.如果不匹配,那么幀就會被丟棄.這種幀校驗是附加到其他上層協(xié)議(如IP或TCP)的校驗和上的.問題:對于數(shù)據(jù)的完整性和驗證服務(wù)???需要使用IPSec協(xié)議。《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議93.2局域網(wǎng)協(xié)議

以太網(wǎng)一般是指數(shù)字設(shè)備公司(DigitalEquipmentCorp.)、英特爾公司(IntelCorp.)和Xerox公司在1982年聯(lián)合公布的一個標準。它是當今TCP/IP采用的主要的局域網(wǎng)技術(shù)。它采用一種稱作CSMA/CD的媒體接入方法,其意思是帶沖突檢測的載波偵聽多路接入(CarrierSense,Multiple

AccesswithCollisionDetection)。它的速率為10Mb/s,地址為48bit。幾年后,IEEE(電子電氣工程師協(xié)會)802委員會公布了一個稍有不同的標準集,其中802.3針對整個CSMA/CD網(wǎng)絡(luò),802.4針對令牌總線網(wǎng)絡(luò),802.5針對令牌環(huán)網(wǎng)絡(luò)?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議10在TCP/IP世界中,以太網(wǎng)IP數(shù)據(jù)報的封裝是在RFC894[Hornig1984]中定義的,IEEE802網(wǎng)絡(luò)的IP數(shù)據(jù)報封裝是在RFC1042[PostelandReynolds1988]中定義的。RFC要求每臺Internet主機都與一個10Mb/s的以太網(wǎng)電纜相連接:1)必須能發(fā)送和接收采用RFC894(以太網(wǎng))封裝格式的分組。2)應(yīng)該能接收與RFC894混合的RFC1042(IEEE802)封裝格式的分組。3)也能夠發(fā)送采用RFC1042格式封裝的分組。如果主機能同時發(fā)送兩種類型的分組數(shù)據(jù),那么發(fā)送的分組必須是可以設(shè)置的,而且默認條件下必須是RFC894分組?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議11最常使用的封裝格式是RFC894定義的格式。如下圖顯示了兩種不同形式的封裝格式。圖中每個方框下面的數(shù)字是它們的字節(jié)長度。兩種幀格式都采用48bit(6字節(jié))的目的地址和源地址(802.3允許使用16bit的地址,但一般是48bit地址)接下來的2個字節(jié)在兩種幀格式中互不相同。在802標準定義的幀格式中,長度字段是指它后續(xù)數(shù)據(jù)的字節(jié)長度,但不包括CRC檢驗碼。以太網(wǎng)的類型字段定義了后續(xù)數(shù)據(jù)的類型。在802標準定義的幀格式中,類型字段則由后續(xù)的子網(wǎng)接入?yún)f(xié)議(Sub-networkAccessProtocol,SNAP)的首部給出?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議12IEEE802.2/802.3(RFC1042)以太網(wǎng)封裝格式(RFC894)《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議13在以太網(wǎng)幀格式中,類型字段之后就是數(shù)據(jù);而在802幀格式中,跟隨在后面的是3字節(jié)的802.2LLC和5字節(jié)的802.2SNAP。目的服務(wù)訪問點(DestinationServiceAccessPoint,DSAP)和源服務(wù)訪問點(SourceServiceAccessPoint,SSAP)的值都設(shè)為0xaa。Ctrl字段的值設(shè)為3。隨后的3個字節(jié)orgcode都置為0。再接下來的2個字節(jié)類型字段和以太網(wǎng)幀格式一樣(其他類型字段值可以參見RFC1340[ReynoldsandPostel1992])。CRC字段用于幀內(nèi)后續(xù)字節(jié)差錯的循環(huán)冗余碼檢驗(檢驗和)(它也被稱為FCS或幀檢驗序列)。802.3標準定義的幀和以太網(wǎng)的幀都有最小長度要求。802.3規(guī)定數(shù)據(jù)部分必須至少為38字節(jié),而對于以太網(wǎng),則要求最少要有46字節(jié)。為了保證這一點,必須在不足的空間插入填充(pad)字節(jié)。在開始觀察線路上的分組時將遇到這種最小長度的情況。《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議14早期以太網(wǎng)幀格式與802.3以太網(wǎng)幀幀格式相比,有細微變化。它是一個類型字段(也叫以太網(wǎng)字段)代替長段字段(均為兩個字節(jié))。如圖所示為EthernetII幀格式。

類型字段用來為上一層協(xié)議棧上的信息掌舵,它與802.2LLC報頭中的DSAP值所起的作用一樣。3.3以太網(wǎng)第二版、802.3And802.1Q

1以太網(wǎng)第二版(V2)目標MAC地址6字節(jié)源MAC地址6字節(jié)以太類型

2字節(jié)數(shù)據(jù)/填充46~1500字節(jié)FCS4字節(jié)前同步碼8字節(jié)詳細見下頁《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議15前導(dǎo)碼:64比特,交替的101010…形式,最后以10101011結(jié)束,提供同步地址:48比特,前3個字節(jié)為IEEE管理,后三個字節(jié)為廠家分配有三類地址:

單個地址(Individual),地址字段的最低一個比特為0,全球唯一

廣播地址(Broadcast):48比特地址全1時,為廣播地址

組播地址(Multicast):地址字段的最低一個比特為1類型:Type,16比特,標識數(shù)據(jù)字段中使用的高層協(xié)議。

TypeIP=0x0800,TypeARP=0x0806(見下頁詳表)數(shù)據(jù):網(wǎng)絡(luò)層用戶數(shù)據(jù)FCS:32比特的CRC校驗,根據(jù)地址、類型和數(shù)據(jù)字段的內(nèi)容計算得出。最大幀長度=1518字節(jié),最小幀長度=64字節(jié),最大傳輸單元MTU=1500字節(jié)以太網(wǎng)技術(shù)TheMaximumExtentEthernetNetwork《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議16《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議17以太網(wǎng)類型代碼(16進制)說明0800IP0806ARP0BADBanyanVINES6000~6009DEC6010~60143Com809BAppleTalk8137~8138Novell的IPX86DDIPv6《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議18這是一個以太網(wǎng)V2幀MAC報頭,此幀攜帶有ARP《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議19《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議20DLC:-----DLCHeader-----DLC:DLC:Frame1arrivedat23:33:39.6638;framesizeis60(003Chex)bytes.DLC:Destination=BROADCASTFFFFFFFFFFFF,BroadcastDLC:Source=StationWstDig488C11DLC:Ethertype=0806(ARP)DLC:ARP:-----ARP/RARPframe-----ARP:ADDRHEXASCII0000FFFFFFFFFFFF0000C0488C1108060001.........H......00100800060400010000C0488C1180010002.........H......002000000000000080010001000000000000................StationWstDig的廠商代碼是??《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議212以太網(wǎng)802.3

即:局域網(wǎng)的MAC子層-IEEE802.3IEEE802.3幀結(jié)構(gòu)以太網(wǎng)802.3幀格式如圖所示。它含有一個長度字段而不是以太網(wǎng)V2幀中的類型字段,其中信息字段中還含一個802.2LLC報頭。一個802.3長度字段的值將總小于0x0600。前導(dǎo)碼:56比特,交替的101010…形式SFD:起始幀分隔符,8比特10101011;IEEE802.3的幀格式是HDLC的一種變形《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議22地址:6字節(jié)或2字節(jié),地址第0比特為用于區(qū)分該地址為單個MAC地址,還是組地址;6字節(jié)地址中第1比特為該地址為全局管理還是本地管理。源地址和目的地址的長度必須相同。幀長度:16比特,數(shù)據(jù)字段中的字節(jié)數(shù)。數(shù)據(jù)字段和填充:

數(shù)據(jù)字段包含MAC層之上的信息,包括IEEE802.2和其以上的數(shù)據(jù)信息,最少46個字節(jié),如果數(shù)據(jù)字段不足46字節(jié),要使用填充字段。數(shù)據(jù)字段和填充字段之和不能超過1500字節(jié)。FCS:32比特的CRC,根據(jù)地址字段、幀長度字段、數(shù)據(jù)和填充字段的內(nèi)容進行計算。《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議23LLC幀作為數(shù)據(jù)送入MAC幀中《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議24《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議25DLC:-----DLCHeader-----DLC:DLC:Frame1arrivedat09:18:37.3543;framesizeis143(008Fhex)bytes.DLC:Destination=Station3Com676974DLC:Source=Station3Com741178DLC:802.3length=129DLC:LLC:-----LLCHeader-----LLC:LLC:DSAP=F0,SSAP=F0,Command,Iframe,N(R)=29,N(S)=109LLC:NETB:-----NETBIOSDataOnlyLast-----ADDRHEXASCII000002608C67697402608C7411780081F0F0.`.git.`.t.x....0010DA3A0E00FFEF1600000000006B161901.:..........k...0020FF534D422D0000000008000000000000.SMB-...........003000000000000000001808050000009407................00400F2E0058000100400016002000000000...X...@.......005000010000000000FEFFFFFF0000000017................0060005C33434F4D5C4D5342454E43485C53.\3COM\MSBENCH\S0070594E432E434D44000AFF000000000000YNC.CMD.........0080000000001000000000000000000000...............《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議26局域網(wǎng)的LLC子層—802.2802.3以太幀中的LLC報頭如圖所示。LLC報頭是信息字段的第一部分,它包含了用來向適當?shù)木W(wǎng)絡(luò)層服務(wù)傳輸數(shù)據(jù)的預(yù)留編碼。LLC報頭要做到這一點,需要使用服務(wù)訪問點(SAP),它指出此幀要到達的網(wǎng)絡(luò)層中的協(xié)議。前導(dǎo)幀起始定界符目的地址源地址長度信息FCS字節(jié)72或612或62N字節(jié)4LLC報頭LLC數(shù)據(jù)DSAPSSAP控制NOTE:FCS字段,也稱為CRC字段《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議27局域網(wǎng)的LLC子層04HIBMSNA路徑控制協(xié)議06HIP協(xié)議AAHSNAP子網(wǎng)訪問協(xié)議LLC子層的數(shù)據(jù)幀格式DSAP地址:目的服務(wù)訪問點地址,1字節(jié),是數(shù)據(jù)幀預(yù)定要到達的數(shù)據(jù)鏈路層以上的目的服務(wù)訪問點(SAP)。例如,如果該數(shù)據(jù)幀是用于NOVELL網(wǎng)際包交換協(xié)議(IPX),那么DSAP取值為EOH。一些預(yù)留的SAP值有:以太網(wǎng)技術(shù)E0HNOVELLIPXF0HIBMNETBIOSFEHOSI網(wǎng)絡(luò)層協(xié)議《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議28SSAP地址:源服務(wù)訪問點地址,

1字節(jié),幀的源服務(wù)訪問點。DSAP的值和SSAP的值總是指定完全相同的協(xié)議。SAP(16進制)說明04IBMSNA路徑控制(單個)05IBMSNA路徑控制(組)06IP08SNA0CSNA42IEEE802.1網(wǎng)橋生成樹協(xié)議BCBanyanVINESAA子網(wǎng)訪問協(xié)議(SNAP)E0NovellNetWareF0IBMNetBIOS《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議29N(S)-傳送方發(fā)送順序號N(R)-傳送方等待接收的順序號SS-分別表示接收就緒RR(00)、拒絕REJ(01)、接收未就緒RNR(10)MMMMM-修改功能比特,用于LLC子層邏輯連接的建立和管理。P/F-所發(fā)送的幀為命令幀時為P(0),為響應(yīng)幀為F(1)X-保留比特,置0信息傳送命令/應(yīng)答-I幀監(jiān)控傳送命令/應(yīng)答-S幀未分配編號傳送命令/應(yīng)答-U幀控制字段(1或2字節(jié)):指出一個管理幀或者一個信息幀,其中包含用于數(shù)據(jù)確認、錯誤恢復(fù)和流量控制等的發(fā)送幀和接收幀的計數(shù),這取決于幀的類型。對于局域網(wǎng)傳輸?shù)拇蠖鄶?shù)幀而言,其中要么包含發(fā)送幀的計數(shù)N(S)及接收幀的計數(shù)N(R),要么只含接收幀的計數(shù)N(R)。但對于后一種情況,必須同時包含“RR”管理幀命令(命令(即請求)),表明相應(yīng)的接收端就緒,可以接收更多的幀。其流量控制方式是:《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議30控制字段(1或2字節(jié)):其流量控制方式是:(1)如果接收端緩沖區(qū)都被占用,他向發(fā)送方傳輸一個“RNR”幀,告訴對方自己尚未準備就緒,無法處理更多的幀。當打印機正忙于打印時,通常會出現(xiàn)這種情況。(2)如果接收端已經(jīng)就緒,就會發(fā)出“RR”幀。兩個端結(jié)點之間就是通過這種方式進行流量控制的。NETBIOS和HDLC等協(xié)議就采用了這種控制。如果使用的傳輸協(xié)議是IPX或者TCP/IP,則控制字段將包含一個“03H”,而不含發(fā)送幀或者接收幀的計數(shù)。特別說明:控制字段一般總為“0x03”(TCP/IP)。信息字段:對于以太網(wǎng)來說,信息字段可以包含多達1500字節(jié)的數(shù)據(jù)。實際數(shù)據(jù)為

43-1497字節(jié)。《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議31

下面的幀片段說明了此幀的LLC部分。請問此幀正在執(zhí)行什么協(xié)議,并將送到上一層的NETBIOS進程?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議32《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議330000030000000001000cf18f210500c4f0f0..........!.....0010032c00ffef0800000000000000444f4d.,...........DOM002041494e3220202020202020201c533032AIN2.S02003031392020202020202020202000ff534d19..SM004042250000000000000000000000000000B%..............005000000000000000000000000000110000................006039000000000000000000e803000000009...............00700000000039005c000300010001000200....9.\.........008050005c4d41494c534c4f545c4e45545cP.\MAILSLOT\NET\00904e45544c4f474f4e0012000000530030NETLOGON.....S.000a000320031003900000000005c4d41494c.2.1.9.....\MAIL00b0534c4f545c4e45545c47455444433436SLOT\NET\GETDC4600c0380000000000000000000b000000ffff8...............00d0ffff..SAPMAC此幀正在執(zhí)行NETBIOS協(xié)議,并將送到上一層的NETBIOS進程?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議340000000a8a8c5b40000a8a2f21000030

aaaa....[@.../!..0..00100300000c0112450000284c1e0000ff11......E..(L.....0020deab0a2f21000a8c5b40000007b70014.../!...[@......00306d56feedface0001000000000000mV............問題1:下面的幀片段說明了此幀的LLC部分。此幀正在執(zhí)行什么協(xié)議??答案:SNAP子網(wǎng)訪問協(xié)議《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議35DLC:-----DLCHeader-----DLC:DLC:Frame1arrivedat09:18:37.3543;framesizeis143(008Fhex)bytes.DLC:Destination=Station3Com676974DLC:Source=Station3Com741178DLC:802.3length=129DLC:LLC:-----LLCHeader-----LLC:LLC:DSAP=F0,SSAP=F0,Command,Iframe,N(R)=29,N(S)=109LLC:NETB:-----NETBIOSDataOnlyLast-----問題2:下面是較完整的片段。《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議36ADDRHEXASCII000002608C67697402608C7411780081F0F0.`.git.`.t.x....0010DA3A0E00FFEF1600000000006B161901.:..........k...Question:“Iframe”,N(R)=29,N(S)=109請問上面的信息各說明(代表)了什么?《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議37以太網(wǎng)MAC地址上的特殊位個體/群組(Individual/Group)位:指示單播(0)或多播(1)通用/本地管理(Universal/LocallyAdministered)位:指示是不是IEEE分配的地址(是IEEE分配設(shè)置為0)路由信息指示位:指明當前是否為MAC級的路由信息。只對令牌環(huán)網(wǎng)有意義?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議38《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議39以太網(wǎng)(V2)和IEEE802.3的比較相同

最大幀長度 最小數(shù)據(jù)字節(jié) 幀校驗FCS的計算不同 地址字段(802.3允許6或2字節(jié)地址)以太網(wǎng)的類型字段和IEEE802.3的長度字段互換

以太網(wǎng)和IEEE802.3不是完全相同的?。?!因此在網(wǎng)絡(luò)層及以上層次是不兼容的?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議403802.1Q虛擬局域網(wǎng)(VLAN)幀 IEEE802.1Q是虛擬橋接局域網(wǎng)的正式標準,它定義了同一個物理鏈路上承載多個邏輯子網(wǎng)VLAN的方法。 IEEE802.1Q在標準的IEEE802.3以太幀結(jié)構(gòu)中加入4個字節(jié),這4個字節(jié)統(tǒng)稱為虛擬局域網(wǎng)標簽(VLAN

Tag)。 實際上,VLAN成員的定義可以分為4種:

1根據(jù)端口劃分VLAN

2根據(jù)MAC地址劃分VLAN

3根據(jù)網(wǎng)絡(luò)層劃分VLAN--這種劃分VLAN的方法是根據(jù)每個主機的網(wǎng)絡(luò)層地址或協(xié)議類型(如果支持多協(xié)議)劃分的

4IP組播作為VLAN

IP組播實際上也是一種VLAN的定義,即認為一個組播組就是一個VLAN,這種劃分的方法將VLAN擴大到了廣域網(wǎng)

《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議41802.1Q協(xié)議定義了基于端口的VLAN模型,這是使用得最多的一種方式。如圖所示,每一個支持802.1Q協(xié)議的主機,在發(fā)送數(shù)據(jù)包時,都在原來的以太網(wǎng)幀頭中的源地址后增加了一個4字節(jié)的802.1Q幀頭,之后接原來以太網(wǎng)的長度或類型域,關(guān)于以太網(wǎng)幀頭的封裝格式,參見以太網(wǎng)方面的知識。

帶有802.1Q標簽頭的以太網(wǎng)幀

《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議42這4個字節(jié)的802.1Q標簽頭包含了2個字節(jié)的標簽協(xié)議標識(TPID--TagProtocolIdentifier,它的值是8100),和兩個字節(jié)的標簽控制信息(TCI--TagControlInformation),TPID是IEEE定義的新的類型,表明這是一個加了802.1Q標簽的文本,如下圖顯示了802.1Q標簽頭的詳細內(nèi)容。

圖802.1Q標簽頭

該標簽頭中的信息解釋如下:

LANIdentified(VLANID):這是一個12位的域,指明VLAN的ID,一共4096個,每個支持802.1Q協(xié)議的主機發(fā)送出來的數(shù)據(jù)包都會包含這個域,以指明自己屬于哪一個VLAN。

CanonicalFormatIndicator(cfi):這一位主要用于總線型的以太網(wǎng)與FDDI、令牌環(huán)網(wǎng)交換數(shù)據(jù)時的幀格式。

Priority:這3位指明幀的優(yōu)先級。一共有8種優(yōu)先級,主要用于當交換機阻塞時,優(yōu)先發(fā)送哪個數(shù)據(jù)包?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議43InternetProtocolSource:29Destination:1TransmissionControlProtocolSourceport:1162(1162)Destinationport:6000(6000)ADDRHEXASCII00060089fb1f300400540ef2481000020.`.....@.@.$...100800450000343b3740004006b7c88397..E..4;7@.@.....20208183972015048a17704e14df554d3d.......pN..UM=305c99801069183c4c00000101080a0004\...i.<L........40f0c80199a3f3Frame10(70onwire,70captured)EthernetIIDestination:00:60:08:9f:b1:f3Source:00:40:05:40:ef:24Type:802.1QVirtualLAN(0x8100)802.1QVirtualLAN000.............=Priority:0...0............=CFI:0....000000100000=ID:32Type:IP(0x0800)《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議444802.1p---了解802.1p協(xié)議定義了優(yōu)先級的概念,對于那些實時性要求很高的數(shù)據(jù)包,主機在發(fā)送時在MAC幀頭增加3位優(yōu)先級,指明該數(shù)據(jù)包優(yōu)先級高,這樣,當以太網(wǎng)交換機數(shù)據(jù)流量比較多時,它就會考慮優(yōu)先轉(zhuǎn)發(fā)這些優(yōu)先級高的數(shù)據(jù)包。802.1p協(xié)議還定義了通用屬性注冊協(xié)議GARP--GenericAttributeRegistrationProtocol。這里的Attribute是指組播MAC地址、端口過濾模式和VLAN等屬性,GARP協(xié)議實際上可以定義很多交換機應(yīng)該具有的特性,目前,它定義了GMRP--GARPMulticastRegistrationProtocol和GVRP--GARPVLANRegistrationProtocol兩個協(xié)議,以后會根據(jù)網(wǎng)絡(luò)發(fā)展的需要定義其他的特性。GARP定義了以太網(wǎng)交換機之間交換這些特性信息的方法,如何發(fā)送數(shù)據(jù)包,接收的數(shù)據(jù)包如何處理等等。ISL&DISLISL&DISL:思科交換鏈路內(nèi)協(xié)議和動態(tài)ISL協(xié)議(ISL&DISL:CiscoInter-SwitchLinkProtocolandDynamicISLProtocol)和802.1Q一樣,ISL作用于OSI模型第2層。所不同的是,ISL協(xié)議頭和協(xié)議尾封裝了整個第2層的以太幀。正因為此,ISL被認為是一種能在交換機間傳送第2層任何類型的幀或上層協(xié)議的獨立協(xié)議?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議45《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議463.4令牌環(huán)和SNAP----令牌環(huán)組成令牌環(huán)幀的各個字段如圖所示。令牌環(huán)網(wǎng)主要用于IBM環(huán)境中,當節(jié)點工作于源路由橋接(SRB)環(huán)境時,源地址中的一個特定的(預(yù)留)指示位將起作用。令牌格式《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議47《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議48幀開始/結(jié)束標志(SD/ED):標識幀的開始和結(jié)束,取值為JK0JK000和JK1JK1IE(說明:J和K是非數(shù)據(jù)標志);

E位(差錯標志):由環(huán)中繼轉(zhuǎn)發(fā)器RPU置位,RPU在轉(zhuǎn)發(fā)每個幀的同時,也執(zhí)行差錯校驗動作,并利用RPU具有的一位延遲來置位差錯標志。訪問控制字段(AC):

Pr/Rr:本幀優(yōu)先級和預(yù)定優(yōu)先級,

T:令牌標識,T=0時,標識對應(yīng)幀為令牌幀,T=1時,標識對應(yīng)幀為信息幀。

M:監(jiān)視位,由環(huán)路中的監(jiān)控器(或者具有監(jiān)控功能的RPU)填寫,發(fā)送結(jié)點發(fā)送該幀(或令牌)時,M置為0,當該幀經(jīng)過監(jiān)控器時,監(jiān)控器將該位置為1(監(jiān)測是否有故障,如有則置1)。如果監(jiān)控器發(fā)現(xiàn)監(jiān)視位已經(jīng)被置為1,則認為發(fā)送結(jié)點出了故障,未能按規(guī)定撤出該幀,此時監(jiān)控器負責撤出該幀,并發(fā)出令牌幀。

《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議49幀控制字段(FC):格式為“FFzzzzzz”;

FF:幀的種類,F(xiàn)F=00,MAC控制幀;FF=10,管理幀。FF=01,數(shù)據(jù)幀,本幀攜帶的LLC幀填放在DATA字段中;幀狀態(tài)標志(FS):格式為“ACxxACxx”;

由發(fā)送方復(fù)位和接收方置位,表示幀的收取狀況。

A:地址確認位,由接收方置位,表示幀中的目標地址(宿地址)正確;

C:信息復(fù)制位,由接收方置位,表示此幀已被接收方正確復(fù)制。

xx:保留未用?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議50DLC:-----DLCHeader-----DLC:DLC:Frame2arrivedat15:57:04.871;framesizeis67(0043hex)bytes.DLC:AC:Framepriority0,Reservationpriority0,Monitorcount1DLC:FC:LLCframe,PCFattentioncode:NoneDLC:FS:Addrrecognizedindicators:00,Framecopiedindicators:00DLC:Destination=StationIBM0033BFDLC:Source=StationIBM002FEBDLC:LLC:-----LLCHeader-----LLC:LLC:DSAP=E0,SSAP=E0,Command,Unnumberedframe:UILLC:IPX:-----IPXHeader-----IPX:ADDRHEXASCII0000184010005A0033BF10005A002FEBE0E0.@..Z.3...Z./...001003FFFF003200110000111110005A0033....2........Z.3《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議513.4令牌環(huán)和SNAP--LLC/子網(wǎng)訪問協(xié)議SNAP子網(wǎng)訪問(/接入)協(xié)議SNAP規(guī)范了在IEEE網(wǎng)絡(luò)上傳輸IP數(shù)據(jù)報的標準方法。換句話說,在IEEE802網(wǎng)絡(luò)上將IP數(shù)據(jù)報封裝于802.2LLC、SNAP數(shù)據(jù)鏈路層和802.3、802.4或802.5網(wǎng)絡(luò)物理層中。

SNAP包含于邏輯鏈路控制LLCIEEE802.2協(xié)議頭中,主要用來在IEEE802網(wǎng)絡(luò)上封裝IP數(shù)據(jù)包、地址解析協(xié)議ARP的請求和答復(fù)。SNAP協(xié)議頭依照于LLC協(xié)議頭并且包含了組織代碼,該組織代碼表示生產(chǎn)廠商的代碼,其余16位為以太類型EtherType代碼。在SNAP中,IP數(shù)據(jù)報的傳輸并不依賴于下層LAN技術(shù)(各種以太網(wǎng)和令牌環(huán)類型)的傳輸速率,它具有各種不同的傳輸速率(從1Mbps到20Mbps)。《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議52基本以太幀上的IP

最初的IP實現(xiàn)是在以太LAN上承載的。以太頭中的“以太類型”字段用來指示載荷中的IP包(800hex=IP)。IEEE802.xLAN上的IP IEEELAN使用更通用的過程來識別所承載的協(xié)議,即通過LLC子層的方法。在LLC中的目的業(yè)務(wù)接入點DSAP和源業(yè)務(wù)接入點SSAP的數(shù)值為一個特定的值,用來指示出現(xiàn)子網(wǎng)接入?yún)f(xié)議SNAP字段,而這一字段承載了上層協(xié)議的指示信息LLCDSAP(0xAA)IP報頭高層業(yè)務(wù)數(shù)據(jù)SNAPIPMAC幀SSAP(0xAA)控制0x03OUI3字節(jié)IEEE802.XMAC尾IEEE802.XMAC頭PID2字節(jié)加入SNAP是為了在802.x幀中加入IP協(xié)議和ARP協(xié)議。SNAP協(xié)議緊跟在LLC協(xié)議之后,并在802.x幀中打包,OUI是組織標識符,PID則標識了上層協(xié)議。《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議530000

1040000a8a8c5b40000a8a2f2100aaaa....[@.../!..0..001003

0000000800450000284c1e0000ff11......E..(L.....0020deab0a2f21000a8c5b40000007b70014.../!...[@......00306d56feedface0001000000000000mV............下面的幀片段說明了此幀的LLC部分。此幀正在承載SNAP子網(wǎng)訪問協(xié)議,并封裝IP數(shù)據(jù)包

《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議543.5WLAN與IEEE802.111997年6月,IEEE推出了802.11標準,開創(chuàng)了WLAN先河;目前,WLAN領(lǐng)域主要是IEEE802.11x系列與HiperLAN/x系列兩種標準。包括以下標準:a、IEEE802.11x系列802.11是1997年IEEE最初制定的一個WLAN標準。主要用于解決辦公室無線局域網(wǎng)和校園網(wǎng)中用戶與用戶終端的無線接入,其業(yè)務(wù)范疇主要限于數(shù)據(jù)存取,速率最高只能達2Mbit/s。由于它在速率、傳輸距離、安全性、電磁兼容能力及服務(wù)質(zhì)量方面均不盡人意,從而產(chǎn)生了其系列標準;802.11a高速WLAN協(xié)議,使用5G赫茲頻段。最高速率54Mbps,實際使用速率約為22-26Mbps與802.11b不兼容,是其最大的缺點。也許會因此而被802.11g淘汰。《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議55802.11b目前最流行的WLAN協(xié)議,使用2.4G赫茲頻段。最高速率11Mbps,實際使用速率根據(jù)距離和信號強度可變(150米內(nèi)1-2Mbps,50米內(nèi)可達到11Mbps)802.11b的較低速率使得無線數(shù)據(jù)網(wǎng)的使用成本能夠被大眾接受(目前接入節(jié)點的成本僅為10-30美元)。另外,通過統(tǒng)一的認證機構(gòu)認證所有廠商的產(chǎn)品,802.11b設(shè)備之間的兼容性得到了保證。兼容性促進了競爭和用戶接受程度?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議56802.11e基于WLAN的QoS協(xié)議,通過該協(xié)議802.11a,b,g能夠進行VoIP。也就是說,802.11e是通過無線數(shù)據(jù)網(wǎng)實現(xiàn)語音通話功能的協(xié)議。該協(xié)議將是無線數(shù)據(jù)網(wǎng)與傳統(tǒng)移動通信網(wǎng)絡(luò)進行競爭的強有力武器。802.11g802.11g是802.11b在同一頻段上的擴展。支持達到54Mbps的最高速率。兼容802.11b。該標準已經(jīng)戰(zhàn)勝了802.11a成為下一步無線數(shù)據(jù)網(wǎng)的標準。

《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議57802.11c為MAC/LLC性能增強;801.11d對應(yīng)802.11b版本,解決那些不能使用2.4GHz頻段國家的使用問題;802.11f用于改善802.11協(xié)議的切換機制,使用戶能在不同無線信道或接入設(shè)備點間可漫游;802.11h802.11h是802.11a的擴展,目的是兼容其他5G赫茲頻段的標準,如歐盟使用的HyperLAN2?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議58802.11i802.11i是新的無線數(shù)據(jù)網(wǎng)安全協(xié)議。802.11i及802.1x主要著重于安全性,802.11i能支持鑒權(quán)和加密算法的多種框架協(xié)議,支持企業(yè)、公眾及家庭應(yīng)用,802.1x的核心為具有可擴展認證協(xié)議EAP,可對以太網(wǎng)端口鑒權(quán),擴展至無線應(yīng)用;

已經(jīng)普及的WEP協(xié)議中的漏洞,將成為無線數(shù)據(jù)網(wǎng)絡(luò)的一個安全隱患。802.11i提出了新的TKIP協(xié)議解決該安全問題。《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議59802.11j的作用是解決802.11a與歐洲HiperLAN/2網(wǎng)絡(luò)的互連互通;802.11/WNG解決IEEE802.11與歐洲ETSI的BRAN—HiperLAN及日本ARAB--HiSWAN統(tǒng)一建成全球一致的WLAN公共接口;802.11n已將速率增強至108/320Mbit/s;并已進一步改進其管理開銷及效率802.11/RRM與無線電資源管理有關(guān)的標準,以增強802.11的性能;802.11/HT,以進一步增強802.11的傳輸能力,取得更高的吞吐量;

《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議60802.11Plus,擬制訂802.11WLAN與GPRS/UMTS之類多頻、多模運行標準,可有松耦合及緊耦合兩種類型。松耦合時兩種網(wǎng)絡(luò)分別部署,WLAN僅利用GPRS之類網(wǎng)絡(luò)的用戶數(shù)據(jù)庫,可通過MobileIP(MIP)提供兩網(wǎng)絡(luò)間的移動性,通過RADUIS(RemoteAccessDail—InUserService,遠程接入撥號用戶業(yè)務(wù))實現(xiàn)AAA(AuthenticationAuthorizationAccounting,鑒權(quán),授權(quán)和計帳),由于MIP可能導(dǎo)致高傳輸時延,從而不容易達到無縫隙會話切換;而緊耦合時,WLAN直接連至業(yè)務(wù)支持節(jié)點SGSN或標準化接口Gb、lu等,WLAN數(shù)據(jù)需經(jīng)_LTGPRS之類核心網(wǎng)轉(zhuǎn)發(fā),完全按GPRS方式進行AAA,此時,能在兩網(wǎng)絡(luò)間提供很強的移動性。為與藍牙在2.4GHz頻段較好共存,亦采用Adhoc網(wǎng)絡(luò)拓撲結(jié)構(gòu)及自適應(yīng)跳頻信道分配技術(shù)?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議61b、HiperLAN/x系列HiperLAN是由ETSI的RESl0工作組提出的歐洲WLAN標準。工作頻段為5.12—5.30GHz及17.1—17.3GHz。早期的HiperLAN/1采用GMSK調(diào)制,最高傳輸速率為23.5Mbit/s,與當時技術(shù)上較成熟的IEEE802.11b相比,無明顯優(yōu)勢;HiperLAN/2采用OFDM(正交頻分復(fù)用)作物理層手段,可將速率提高至54Mbit/s,并能有效對抗多徑干擾,以及與IEEE802.11a共享一些相同部件,在較大范圍內(nèi)取得較好的性能/價格比。其信道帶寬為22MHz,調(diào)制方式亦為OFDM--BPSK/QPSK/16/64QAM,系列化傳輸速率為6、9、12、18、27、36、54Mbit/s。

《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議623.5.1IEEE802.11幀格式IEEE802.11幀格式由IEEE802.11的頭和尾,以及IEEE802.2LLC的頭組成。如圖所示。Address1Address2DSAPSSAPControlPayloadAddress3FrameCheckSequenceFrameControlIEEE802.2LLCHeaderDuration/ID...IEEE802.11HeaderIEEE802.11TrailerSequenceControlAddress4持續(xù)時間/ID《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議63幀控制:2字節(jié)長,擁有關(guān)于幀類型和怎樣處理幀的控制信息。包含如下子字段:ProtocolVersionTypeSubtypeToDSFromDSMoreFragmentsRetryPowerManagementMoreDataWEPOrder協(xié)議版本:2位,指明用來創(chuàng)建幀的IEEE802.11的協(xié)議版本號。當前的IEEE802.11,設(shè)置為0。類型:2位,指明IEEE802.11幀的類型。定義了3個值:00,用于管理幀;01,用于控制幀;10,用于數(shù)據(jù)幀;11,預(yù)留。子類型:4位,指明管理、控制或者數(shù)據(jù)幀的特定類型?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議64TODS:1位標志,指明(被設(shè)為1時)幀的目的地是分布式系統(tǒng)、連接無線AP和提供對有線節(jié)點訪問的有線網(wǎng)絡(luò)。只有以紅外模式操作的無線節(jié)點才設(shè)置此值。FROMDS:

1位標志,指明幀是否來源于有線網(wǎng)絡(luò)。更多分段:

1位標志,指明(被設(shè)為1時)幀有更多的段,本幀也是某幀中的一段。如果幀沒有分段中或者是分段幀中的最后一段,則被設(shè)為0。重試:

1位標志,指明幀是重傳幀。ProtocolVersionTypeSubtypeToDSFromDSMoreFragmentsRetryPowerManagementMoreDataWEPOrder《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議65電源管理:

1位標志,當設(shè)為1時,指明傳輸?shù)臒o線節(jié)點運行在省電模式下。更多數(shù)據(jù):

1位標志,被設(shè)為1時指示無線AP至少有一個緩沖的幀要發(fā)送到無線節(jié)點。WEP:1位標志,當設(shè)為1時,指明有效載荷是用WEP(有效設(shè)備隱私協(xié)議)加密的。順序:

1位標志,被設(shè)為1時表示幀必須按順序處理。ProtocolVersionTypeSubtypeToDSFromDSMoreFragmentsRetryPowerManagementMoreDataWEPOrder《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議66持續(xù)時間/ID:2字節(jié),如果是控制幀則為其ID;(只有控制幀例外)其他幀則是指傳輸?shù)某掷m(xù)時間(微秒級),即就是NAV(NetworkAllocationVector)的值。地址1:目標MAC地址,6字節(jié),指明無線節(jié)點(在“特殊”模式中,由一個無線節(jié)點發(fā)送到另一無線節(jié)點或由無線AP發(fā)送到另一無線節(jié)點時)或者SSID(服務(wù)設(shè)置標識符)(從一個無線節(jié)點發(fā)送到一個無線AP時)的目標MAC地址。地址2:源MAC地址,6字節(jié),含有發(fā)送節(jié)點(在“特殊”模式中,由一個無線節(jié)點發(fā)送到另一無線節(jié)點或由無線AP發(fā)送到另一無線節(jié)點時)或服務(wù)集標識符SSID(從一個無線節(jié)點發(fā)送到一個無線AP時)的MAC地址。地址3:6字節(jié),含有用“特殊”模式發(fā)送到另一無線節(jié)點的幀的SSID、從無線AP發(fā)送到另一無線節(jié)點的幀的源地址,或者從無線節(jié)點發(fā)送到無線AP的幀的目的地址?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議67序列控制:用于流控,2字節(jié)長,有4位數(shù)據(jù)幀段號字段和12位序列號字段,這2個字段一起使用能使接收者丟棄重復(fù)的幀。當幀被分成段時,段號字段用來指示段的順序。如果沒有分段,就將該字段設(shè)置為0。序列號最小為0,最大為4095,當增加到超過最大值后,又從0開始。幀內(nèi)的所有段都有相同的序列號。地址4:6字節(jié)長,含有源無線節(jié)點的MAC地址。這個字段僅當幀的控制字段中TODS和FROMDS標志為1時才有效,用來指示無線AP之間的通信。凈載荷:0-2308B幀校驗序列:4字節(jié)長的CRC,提供從控制字段到有效載荷字段的所有字段的位級(BIT)完整性驗證。802.11FrameTypes:(exceptdataframes),managementframes,controlframes.

ManagementFrames:Managementframesareusedfortheinitialcommunicationbetweenstationsandaccesspoints.ControlFrames:Controlframesareusedforaccessingthechannelandacknowledgingframes.《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議68《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議69《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議70問題:隱藏終端和暴露終端隱藏終端和暴露終端問題產(chǎn)生的原因和影響:由于adhoc網(wǎng)絡(luò)具有動態(tài)變化的網(wǎng)絡(luò)拓撲結(jié)構(gòu),且工作在無線環(huán)境中,采用異步通信技術(shù),各個移動節(jié)點共享同一個通信信道,存在信道分配和競爭問題;為了提高信道利用率,移動節(jié)點電臺的頻率和發(fā)射功率都比較低;并且信號受無線信道中的噪聲、信道衰落和障礙物的影響,因此移動節(jié)點的通信距離受到限制,一個節(jié)點發(fā)出的信號,網(wǎng)絡(luò)中的其它節(jié)點不一定都能收到,從而會出現(xiàn)“隱藏終端”和“暴露終端”問題。隱藏終端”和“暴露終端”的存在,會造成adhoc網(wǎng)絡(luò)時隙資源的無序爭用和浪費,增加數(shù)據(jù)碰撞的概率,嚴重影響網(wǎng)絡(luò)的吞吐量、容量和數(shù)據(jù)傳輸時延?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議71隱藏終端隱藏終端是指在接收接點的覆蓋范圍內(nèi)而在發(fā)送節(jié)點的覆蓋范圍外的節(jié)點(如:C)。隱藏終端由于聽不到發(fā)送節(jié)點的發(fā)送而可能向相同的接收節(jié)點發(fā)送分組,導(dǎo)致分組在接收節(jié)點處沖突。沖突后發(fā)送節(jié)點要重傳沖突的分組,這降低了信道的利用率。《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議72隱藏終端又可以分為隱發(fā)送終端和隱接收終端兩種。在單信道條件下,隱發(fā)送終端可以通過在發(fā)送數(shù)據(jù)報文前的控制報文握手來解決。但是隱接收終端問題在單信道條件下無法解決。當A要向B發(fā)送數(shù)據(jù)時,先發(fā)送一個控制報文RTS;B接收到RTS后,以CTS控制報文回應(yīng)(CTS廣播);A收到CTS后才開始向B發(fā)送報文,如果A沒有收到CTS,A認為發(fā)生了沖突,重發(fā)RTS,這樣(同時)隱發(fā)送終端C能夠聽到B發(fā)送的CTS,知道A要向B發(fā)送報文,C延遲發(fā)送,解決了隱發(fā)送終端問題。對于隱接收終端,當C聽到B發(fā)送的CTS控制報文而延遲發(fā)送時,若D向C發(fā)送RTS控制報文請求發(fā)送數(shù)據(jù),因C不能發(fā)送任何信息,所以D無法判斷是RTS控制報文發(fā)生沖突,還是C沒有開機,還是C時隱終端,D只能認為RTS報文沖突,就重新向C發(fā)送RTS。因此,當系統(tǒng)只有一個信道時,因C不能發(fā)送任何信息,隱接收終端問題在單信道條件下無法解決?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議73暴露終端暴露終端是指在發(fā)送接點的覆蓋范圍內(nèi)而在接收節(jié)點的覆蓋范圍外的節(jié)點(如:B)。暴露終端因聽到發(fā)送節(jié)點的發(fā)送而可能延遲發(fā)送。但是,它其實是在接收節(jié)點的通信范圍之外,它的發(fā)送不會造成沖突。這就引入了不必要的時延?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議74暴露終端又可以分為暴露發(fā)送終端和暴露接收終端兩種。在單信道條件下,暴露接收終端問題是不能解決的,因為所有發(fā)送給暴露接收終端的報文都會產(chǎn)生沖突;暴露發(fā)送終端問題也無法解決,因為暴露發(fā)送終端無法與目的節(jié)點成功握手。當B向A發(fā)送數(shù)據(jù)時,C只聽到RTS控制報文,知道自己是暴露終端,認為自己可以向D發(fā)送數(shù)據(jù)。C向D發(fā)送RTS控制報文。如果是單信道,來自D的CTS會與B發(fā)送的數(shù)據(jù)報文沖突,C無法和D成功握手,它不能向D發(fā)送報文?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議75在單信道下,如果D要向暴露終端C發(fā)送數(shù)據(jù),來自D的RTS報文會與B發(fā)送的數(shù)據(jù)報文在C處沖突,C收不到來自D的RTS,D也就收不到C回應(yīng)的CTS報文。因此,在單信道條件下,暴露終端問題根本無法得到解決!《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議76隱藏終端和暴露終端問題的解決方法解決隱藏終端問題的思路是使接收節(jié)點周圍的鄰居節(jié)點都能了解到它正在進行接收,目前實現(xiàn)的方法有兩種:一種是接收節(jié)點在接收的同時發(fā)送忙音來通知鄰居節(jié)點,即BTMA系列;另一種方法是發(fā)送節(jié)點在數(shù)據(jù)發(fā)送前與接收節(jié)點進行一次短控制消息握手交換,以短消息的方式通知鄰居節(jié)點它即將進行接收,即RTS/CTS方式。這種方式是目前解決這個問題的主要趨勢,如已經(jīng)提出來的CSMA/CA、MACA、MACAW等。還有將兩種方法結(jié)合起來使用的多址協(xié)議,如DBTMA?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議77《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議78DistributedInterframeSpace(DIFS)ShortInterframeSpace(SIFS)RequestToSend(RTS)ClearToSend(CTS)《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議79《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議80持續(xù)時間計數(shù)器NAV(NetworkAllocationVectorWirelessLANscannotimplementCSMA/CDforthreereasons:1.Forcollisiondetectionastationmustbeabletosenddataandreceivecollisionsignalsatthesametime.Thiscanmeancostlystationsandincreasedbandwidthrequirements.2.Collisionmaynotbedetectedbecauseofthehiddenstationproblem.3.Thedistancebetweenstationscanbegreat.Signalfadingcouldpreventastationatoneendfromhearingacollisionattheotherend.《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議81《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議823.7SLIPANDPPPSLIP(SerialLineIP)—串行線路的Internet數(shù)據(jù)鏈路層協(xié)議PPP(Point-to-PointProtocol)—點-點協(xié)議SLIP與PPP用于串行通信的撥號線路上,是目前家庭計算機或公司用戶通過ISP接到Internet主要的協(xié)議?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議833.7.1SLIP協(xié)議SLIP出現(xiàn)于20世紀80年代初,最早是在BSDUNIX4.2版操作系統(tǒng)上實現(xiàn)的;SLIP協(xié)議支持TCP/IP協(xié)議;但不是Internet正式標準。SLIP提供在串行通信線路上封裝IP分組的最簡單方法。先對數(shù)據(jù)報進行了簡單的封裝,然后來用RS-232接口串行線路進行傳輸;SLIP通常也用來將遠程終端連接到UNIX主機,也可通過租用或撥號串行線路進行主機到路由器,以及路由器到路由器的通信?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議84典型的SLIP接入方式Internet的家庭或小型公司用戶通過調(diào)制解調(diào)器、電話網(wǎng)絡(luò)連接到ISP的調(diào)制解調(diào)器;ISP的調(diào)制解調(diào)器再通過它的路由器接入Internet;SLIP系統(tǒng)一般可以發(fā)送和接收1006B的IP數(shù)據(jù)報?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議85SLIP協(xié)議的幀結(jié)構(gòu)RFC1055文件對SLIP幀格式進行了討論;SLIP幀頭與幀尾的“C0”,是協(xié)議使用的惟一的一個控制字符;C0的二進制編碼比特序列是10000110000000(C為ASCII碼值)

C0的使用將影響SLIP幀數(shù)據(jù)的透明性;解決的方法是:字符填充

《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議86

SLIP協(xié)議的缺點使用SLIP協(xié)議時,通信的雙方都必須知道對方的IP地址,因為SLIP協(xié)議沒有為它們提供相互交換地址信息的方法;沒有設(shè)置協(xié)議類型字段,不具備同時處理多種網(wǎng)絡(luò)層協(xié)議的能力;沒有校驗和字段,差錯控制功能由高層的協(xié)議承擔;SLIP協(xié)議并不是Internet的協(xié)議標準,因此不同版本的之間就會存在著差別,使得互連變得困難。《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議873.7.2CSLIP協(xié)議SLIP協(xié)議通常運行于傳輸速率相對較低的串行線路上;在常用于Telnet之類的應(yīng)用程序中,人們提出了一種壓縮的SLIP(CSLIP)協(xié)議;RFC1144對CSLIP進行了定義;并說明在SLIP鏈路上如何使用它將IP和TCP頭壓縮為3到5個字節(jié)。Telnet是一種交互式的應(yīng)用程序,每次常常只傳送幾個字節(jié)的信息,通信效率低。

《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議883.7.3PPP協(xié)議基本特點PPP協(xié)議是Internet標準,RFC1660、RFC1661定義了PPP協(xié)議與幀結(jié)構(gòu);PPP協(xié)議處理了差錯檢測,支持面向字符型協(xié)議與面向比特型協(xié)議,可以支持IP協(xié)議及其他一些網(wǎng)絡(luò)層協(xié)議(例如IPX協(xié)議);PPP協(xié)議不僅在撥號電話線,并且在路由器─路由器之間的專用線上廣泛應(yīng)用;PPP協(xié)議是在大多數(shù)家庭個人計算機和ISP之間使用的協(xié)議,它可以作為在高速廣域網(wǎng)和社區(qū)寬帶網(wǎng)協(xié)議族的一部分。使用鏈路控制協(xié)議LCP(linkcontrolprotocol)來建立、配置、測試和拆除數(shù)據(jù)鏈路。使用網(wǎng)絡(luò)控制協(xié)議NCP(networkcontrolprotocol)來協(xié)商、配置不同網(wǎng)絡(luò)層的各種參數(shù)選項?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議89組成:4個部分

封裝:一種封裝多協(xié)議數(shù)據(jù)報的方法。PPP封裝提供了不同網(wǎng)絡(luò)層協(xié)議同時通過統(tǒng)一鏈路的多路技術(shù)。(人們)精心的設(shè)計PPP封裝,使其保有對常用支持硬件的兼容性。

鏈路控制協(xié)議LCP:為了在一個很寬廣的環(huán)境內(nèi)能足夠方便的使用,PPP提供了LCP。LCP用于就封裝格式選項自動的達成一致,處理數(shù)據(jù)包大小的變化,探測looped-back鏈路和其他普通的配置錯誤,以及終止鏈路。提供的其他可選設(shè)備有:對鏈路中對等單元標識的認證,和鏈路功能正常或鏈路失敗情況下的決定。

網(wǎng)絡(luò)控制協(xié)議NCP:一種擴展鏈路控制協(xié)議,用于建立、配置、測試和管理數(shù)據(jù)鏈路連接。

配置:通過鏈路控制協(xié)議使PPP鏈路很容易配置。該機制也應(yīng)用于其它控制協(xié)議如網(wǎng)絡(luò)控制協(xié)議(NCPs)

《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議90過程: -PPP鏈路建立,發(fā)送端PPP首先發(fā)送LCP幀來配置(有選擇)測試數(shù)據(jù)鏈路。 -選擇網(wǎng)絡(luò)層協(xié)議。在數(shù)據(jù)鏈路建立起來,并由LCP協(xié)調(diào)好之后,發(fā)送端PPP發(fā)送NCP幀來選擇和配置一個或多個網(wǎng)絡(luò)層協(xié)議?!疽陨蟽蓚€亦可稱為PPP連接。并可以細化為以下4steps:用LCP對PPP進行配置;使用PPP驗證協(xié)議進行驗證(可選);回叫(如:使用回叫控制協(xié)議CBCP)(可選);使用NCP進行協(xié)議配置(如:使用IPCP,壓縮控制協(xié)議CCP,加密控制協(xié)議ECP)】 -數(shù)據(jù)傳送,網(wǎng)絡(luò)層協(xié)議選擇完成后,就可以進行PPP數(shù)據(jù)傳送。 -鏈路關(guān)閉,外部事件發(fā)生(超時、用戶干預(yù))或由LCP或NCP關(guān)閉數(shù)據(jù)鏈路簡化過程如下圖:《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議91PPP協(xié)議簡化的階段流程圖開始《網(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議92PPP信息幀格式(PPP的幀格式類似HDLC的幀,但是面向字符的。)標志(flag):01111110

采用字符填充法,對數(shù)據(jù)域出現(xiàn)0x7e(首尾標志字符)、0x7d(轉(zhuǎn)義字符)和所有小于0x20的字符(ASCII控制字符)都必須在前增添轉(zhuǎn)義字符0x7d(ESC),本身的第六位還必須取反。如0x7e0x7d0x5e,0x010x7d0x21。

地址(address):值為“FF”(11111111),表示網(wǎng)中所有的站都接收該幀,目的是避免給每站分配鏈路地址??刂疲╟ontrol):值為“03”(00000011),表明是無序號幀,沒有采用序號和確認來進行可靠的傳輸。但在有噪音的環(huán)境里(無線網(wǎng)絡(luò)),則使用序號方式進行可靠傳輸。通過LCP可商議出省略這兩個固定字段的選項?!毒W(wǎng)絡(luò)協(xié)議與應(yīng)用》第3章物理鏈路層協(xié)議93協(xié)議(protocol):長度為2字節(jié),它標識出網(wǎng)絡(luò)層協(xié)議數(shù)據(jù)域的類型。 協(xié)議字段的編碼指出信息字段中攜帶什么類型的數(shù)據(jù)分組。以“0”開始的編碼表示攜帶的是網(wǎng)絡(luò)層的分組,如:IP(0x0021),IPX,OSICLNP,XNS等;以“1”開始的編碼表示攜帶的是用于協(xié)商協(xié)議的分組,包括用來協(xié)商鏈路參數(shù)的LCP(0xc021)和針對所支持的每種網(wǎng)絡(luò)層協(xié)議而定的不同NCP。通過LCP可商議出1個字節(jié)的協(xié)議字段。

常用的網(wǎng)絡(luò)層協(xié)議的類型主要有:

協(xié)議字段不同,后面的信息字段類型就不同。

0021H—TCP/IP002BH—NOVELL0023H—OSI 003DH—Multilink(多鏈路)

0027H—DEC 0xC021—信息字段是鏈路控制數(shù)據(jù)LCP 0x8021—信息字段是網(wǎng)絡(luò)控制數(shù)據(jù)NCP 0xC023—信息字段是安全性認證P

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 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

提交評論