複製鏈接
請複製以下鏈接發送給好友

網絡控制協議

鎖定
網絡控制協議是一組獨立定義的協議。NCP層協議一般是在WAN連接的一端丟失了特定協議的成功操作的信息時被使用。
例如,如果一個用户要撥號進入Cisco路由器,該用户的機器一般不知道要使用哪個IP地址,因此必須通過NCP/IPCP協商從Cisco路由器獲得一個地址。然而,當在專用連接上使用PPP時,網絡管理者分配所有的網絡層屬性,因此NCP的能力並不重要。
中文名
網絡控制協議
外文名
Network control protocol
功    效
協商網絡層屬性
意    義
數據鏈路層協議。
定    義
是一組獨立定義的協議
應用範圍
計算機應用

網絡控制協議簡介

IrDA最具有成本優勢且協議簡單,但傳輸方向單一,不能 [1]  組網。WirelessUSB的成本較高,主要用於傳輸高速多媒體數據,不適合智能家庭的控制應用。藍牙主要用於傳輸語音,如果將其應用在智能家庭控制領域,那麼傳輸距離有限和控制協議比較複雜這兩個問題就會比較突出。Z-Wave是從ZigBee標準中精簡而來,但該技術目前尚不支持全球通用的2.4G頻段。ZigBee在傳輸距離、可靠性以及組網能力方面都極具優勢,不過其成本還不夠低。因此,我們認為,IrDA技術在智能家庭控制的低端市場仍會保有一定份額,但是在中高端市場,ZigBee是被廣泛看好的技術,將會產生無限的商機。
ZigBee技術實現的最大挑戰在於,如何為目標系統設計一個簡單易用的網絡控制協議。當採用ZigBee技術來設計智能家庭的控制應用時,從成本和資源角度來衡量,8位MCU就已經足夠,但要求ROM空間最好能大於32K,RAM空間不小於2K。4位MCU由於內部資源不夠,無法承載ZigBee的控制協議,所以市場機會不大。而16位MCU成本相對較高,也難以成為主流的選擇。問:貴公司的解決方案有哪些獨特的優勢?富士通微電子已推出了業內首個面向簡單應用的802.15.4/ZigBee無線開發套件。
該套件命名為WiLeKit,基於富士通微電子出色的低功耗8位微控制器MB95F108A,採用特別設計的簡單網絡控制協議,客户無需支付昂貴的認證費用,就可以為他們的現有產品上快速增加高可靠性的ZigBee無線控制功能。WiLeKit演示套件包含五個終端設備(enddevice)和一個網絡協調器(coordinator),從而使用户得以建造一個用於應用評估的簡單網絡。
該套件可設定手動和自動模式。在手動模式下,客户可在控制中心根據需要,通過按鍵隨時獲得網絡中任何一個終端的現場數據。在自動模式下,終端會自動定時地把現場數據傳輸到控制中心。

網絡控制協議協議種類

PPP的設計意圖是定義一個能夠在點到點線路上運送多種網絡協議的數據報(Datagram)的數據鏈路層協議。在Intemet體系結構中沒有OSI/RM中服務的概念,因此,PPP還必須涉及與網絡層間的數據交換問題,必須具備就數據鏈路層支持的網絡協議進行協商並進行相應配置的能力。這就是在PPP中需要涉及網絡控制協議(NCP)的原因,應當指出:NCP是數據鏈路層支持對多種網絡協議進行配置協商的手段,因此,使用網絡控制協議一詞很容易誤解為網絡層的控制協議,讀者應當正確理解其實質。
LCP為數據鏈路的建立與終止、控制、配置協商等提供了一種通用機制,因此,在NCP的定義中借用了這種機制,借用了LCP的PDU格式(只是協議代碼為表1中的NCP編碼),甚至PDU名稱也借用LCP的名稱。從這種意義上講,NCP主要是對相關協商內容的定義。 [2] 
IETF為多種網絡協議定義了相應的NCP,例如:支持IP協議的NCP被稱為IPCP(IP Control Protocol),支持Novell網的IPX的NCP叫做IPXCP等等。在PPP運作過程中,當進人網絡層協議處理階段時,首先通過LCP就鏈路測試和配置進行協商,然後利用NCP進行網絡配置協商。PPP允許在其上的網絡層有多種網絡協議,因此.可根據需要利用相應的NCP進行多次協商。以下是對IPCP作簡要的介紹。
IPCP的責任是在PPP鏈路兩端配置、激活和停止IP模塊。IPCP格式與LCP幾乎完全相同(參看圖1),

網絡控制協議單元格式

不同之處在於:
①協議字段 LCP的該字段為二—十進制“C021”,而IPCP的該字段為“8021”;
②PDU編碼字段 LCP使用代碼“1”一“12”,而IPCP只借用了其中的“1”一“7”,即Configure-Request、Configure-Ack、Configure-NAK、configure-Reject、Terrrdnate-Request、Terminate-Ack和Code-ReJect。應當注意,這一字段是在協議字段界定之下的特定PDU的編碼,因此,儘管同名,LCP協商的內容與數據鏈路層有關,而NCP協商的內容卻是與相關的網絡層協議有關。
RFCll72定義了兩類協商選項:IP-Addresses和Compression-Type;而RFCl332(1PCP)則增加了一個選項:IP-Address,但建議不再使用IP-Addresses。]P-Addresses建議者試圖對鏈路兩端的“源一的”IP“地址對”進行協商,而IP-Address僅就請求方使用的IP地址進行協商;由於前者在實踐中遇到許多實際問題,FRCl332中建議使用後者。

網絡控制協議參數格式

Compression Protocol在使用RFCll44規定Van Jacobson算法壓縮TCP/IP頭(注:UDP/TCP頭不適合壓縮)時,則該字段中代碼為“002D”(二一十進制),“Slot”是TCP/11)P實現中用於存放TCP/IP頭的緩存,每個Slot存放一個TCP/IP頭,故Slot數量關係到能緩存TCP/IP報文的數量,因此被列入協商對象;Slot-Id可取值為0一Max-Slot-Id,Comp-slot-Id用於表示該字段是否允許被壓縮(0表示不能,l表示可以)。
參考資料