網路控制協定是一組獨立定義的協定。NCP層協定一般是在WAN連線的一端丟失了特定協定的成功操作的信息時被使用。
例如，如果一個用戶要撥號進入Cisco路由器，該用戶的機器一般不知道要使用哪個IP位址，因此必須通過NCP/IPCP協商從Cisco路由器獲得一個地址。然而，當在專用連線上使用PPP時，網路管理者分配所有的網路層屬性，因此NCP的能力並不重要。
基本介紹
- 中文名：網路控制協定
- 外文名：Network control protocol
- 功效：協商網路層屬性
- 意義：數據鏈路層協定。
- 定義：是一組獨立定義的協定
- 套用範圍：計算機套用
簡介,協定種類,單元格式,參數格式,
簡介
IrDA最具有成本優勢且協定簡單，但傳輸方向單一，不能組網。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主要是對相關協商內容的定義。
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表示可以)。
