電腦網路與連結技術第七章 區域網路模型 上一頁    下一頁

7-6 LLC通訊協定

內容:

  • 7-6-1 Type 1 非連接服務

  • 7-6-2 Type 2 連接導向服務

  • 7-6-3 Type 非連接附確認服務

LLC可提供給網路層多種服務類別,不同的服務類別有相對應的介面程式呼叫,來建立兩個LLC通訊實體之間連線。LLC提供給網路層的服務類別,有下列三種:

  • Type 1:非連接服務(Connectionless Service

  • Type 2:連接導向服務(Connection Oriented Service

  • Type 3:非連接附確認服務(Connectionless with Acknowledgement Service

其中Typ1Type3服務方式係提供非連接方式,Type 2服務則提供連接方式。在Type1Type 3服務下,每一筆被傳送的資料單元(LLC-PDU)都被當成一個通訊中的獨立個體。網路中根據其中的目的位址來傳送資料,也就一般所說的『電報傳輸』(Datagram)方式服務,並不保證資料是否可以安全到達目的地。Type 3增加回應確認的功能,目的地如果有接收到訊息,會回應一個確認訊息給傳送端。在Type 2服務之下,資料傳送之前必須建立通訊連線(虛擬鏈路),然後才依照連線傳送資料。此時傳送端的LLC和接收端的LLC會依照通訊協定標準,排除各種傳輸中發生的問題,如資料錯誤、資料重複、順序不對等等。如此才能使資料正確又按照順序(In-order)傳送。

7-6-1 Type 1 非連接服務

Type 1非連接服務』(Connectionless Service)沒有『回應基礎呼叫』和『確認基礎呼叫』,只提供要求和通知兩種介面程式。一般應用在廣播訊息給所有工作站,或應用在建立連線時的控制訊息傳送。它的介面程式呼叫時序如圖 7-15 所示。

7-15 Type 1 非連接服務

當上層通訊軟體要求Type 1 非連接服務的傳送方式時,LLC 會用到下列 U-format 的命令(命令格式請參考圖 7-10)。

  • 未編號資料(UI):傳送端的 LLC 利用 UI 命令發送資料,在 LLC-PDU 中的 DSAP 位址可以是個別位址、群組位址或廣播位址。UI 命令並沒有序號,因此每一筆資料都是獨立性的。

  • XID Type 1 中,傳送端可以利用 XID 命令查詢 LLC 的群組位址或個別位址。接收到 XID 命令者,同樣以 XID 命令回應給發送者,但都採用個別地址發送。

  • TEST此命令適用於測試 LLC 之間的連線是否還存在。接到 TEST 命令者也是回應 TEST 命令。

如圖 7-16 中,User_A 欲發送訊息給 User_B。當 LLC_A 接收到 DL_UNITDATA-request 介面程式後,依照程式內包含的命令(UIXID TEST)傳送給對方 LLC_BLLC_B 再將該命令包裝為 DL_UNITDATA.indication 介面程式傳送給 User_B

7-16 Type 1 U-format 命令

7-6-2 Type 2 連接導向服務

Type 2連接導向服務』(Connection-oriented Service)的連線管理包含連線建立、資料傳送與連線終止等三個時相,如圖 7-17 所示。相同的,Type 2 服務會使用到 Type 2 的介面程式。以下分別介紹它們與格式命令之間的關係:(有關格式命令請參考 7-4 節介紹)

7-17 Type 2 連接導向連線運作圖

(A) 連線之建立、終止與 U-format 命令

在圖 7-17 的連線建立時相中,會使用到 U-format 格式中的 SAMEUA DM命令,它們之間的關係如圖 7-18 所示。首先,要求連線端 User_A傳送 DL_Connect.request LLC_ALLC_A 發送 SAME(設定連線模式)命令給對方 LLC_BLLC_B 再傳送 DL_Connect.indication 給上層使用者 User_BUser_B 回應 DL_Connect.response LLC_B,其中包含是否同意連線的訊息。如同意連線,則 LLC_B 回應 UA LLC_A;否則回應 DMLLC_A LLC_B 的回應訊號包裝後,以 DL_Connect.confirm 回應給 User_A

連線終止的動作如同連線建立,它會用到 U-format 中的 DISC DM 兩個命令。首先 LLC_A 收到 DL_Disconnect.request 便發出 DISC 給對方 LLC_BLLC_B 再將該訊號包裝成 DL_Disconnect.indication LLC_B 的使用者 User_BUser_B 回應 DL_Disconnect.response LLC_BLLC_B 便發送 DM LLC_ALLC_A 再回應 DL_Disconnect.confirm LLC_A 的使用者(User_A)。

7-18 Type 2 建立連線的訊號方式

(B)資料傳送與 I-formatS-format 命令

7-19 為資料傳送的訊號方式。如果 LLC_A LLC_B 兩端之間都在傳送資料,它們之間確認訊號是利用『搭順風車』(Piggyback)方式回應。也就是 LLC 接收 DL_DATA.request 時,將 N(S) N(R) 包裝於 I-format 的命令格式之中,而其中 N(R) 就是以搭順風車方式回應確認(滑動視窗法),如圖 7-21 中的 (1) 訊號。但如果只有單方向傳送資料,接收端無法搭順風車回應訊號給傳送端。這種情況下接收端必須使用 S-format LLC-PDU 來回應確認訊息(N(R))。而在 S-format 之中只有 N(R) 欄位,而沒有 N(S) 的欄位。其中:

  • Receive ReadyRR):用來回覆收到的資料單元,同時表示可以繼續接收資料,如圖 7-21 (2) 訊號。

  • Receive Not ReadyRNR):用以回覆收到的資料單元,並告訴對方暫時無法在接收資料。可能是緩衝器已滿或其他原因,等到原因排除後,再送出 RR 訊號表示可以繼續接收資料,如圖 7-21 (3) 訊號。

  • RejectREJ):用來要求對方重新傳送 I-format 命令。REJ 要求從 N(R) 開始的序號重新傳送,同時也表示在 N(R) 序號之前的資料以正常方式接收,如圖 7-21 (4) 訊號。

7-19 Type 2 資料傳送的訊號方式

(C) 流量控制

LLC 雙方連線建立後,傳送端可連續發送多筆資料給對方,對方只要回應給傳送端已安全接收到第幾筆資料便可,不需要每一筆資料都回應確認訊號。流量控制就是管理雙方在通訊連線上多筆資料的流動,包括資料的確認和錯誤資料如何重新傳送。一般電腦網路上的流量控制都採用『滑動視窗法』(Sliding Window)。這裡我們僅針對 LLC 流量控制的特殊特性作簡單的介紹,至於詳細運作原理,請參考本書 3-4 節。

Type 2 連接導向的通訊鏈路是屬於雙工方式,表示雙方的 LLC 都可接收與傳送資料,因此,雙方都必須有傳送緩衝器和接收緩衝器。LLC 將接收到的資料填入接收緩衝器,在適當的時機再傳送給上一層通訊軟體。同樣的,LLC 將上一層所欲傳送的資料填入傳送緩衝器,再依序發送到對方。上一層的資料也許非常大,我們必須依照 LLC-PDU 封包的大小分割成若干個,再依照順序填入傳送緩衝器。也就是說,每一筆資料都編有序號,無論接收或傳送都必須依照序號順序。至於緩衝器空間是否足夠接收新的 PDU,可利用 I-format 內的 P/F 位元來通知對方。

7-20 (b) Type 2 的流量控制之 2

7-6-3 Type 3 非連接附確認服務

Type 3 非連接附確認』(Connectionless with Acknowledge)服務非常類似於Type 1,兩者皆是提供非連接方式。但 Type 3 接收端接收到訊息時,必須回應確認訊號,因此,它比Type 1較為可靠,一般應用於重要訊息廣播或查詢使用。

Type 3 服務中,每一筆資料都要求回應,以達到可靠性的傳輸。因此,對於大量資料傳送的效率較差,只適合用於少量資料的傳送。對於大量資料傳送還是 Type 2比較適合。基本上,Type 3 的傳送服務和 Type 2 有很大的不同點,Type 2 傳送資料是由上層發動後再由 LLC 傳送出去,回應訊號也是由上層通訊軟體告知後再由 LLC 發送給對方。Type 3 則不然,上層通訊軟體首先將欲發送的資料單元,存放在 LLC 層內,LLC 層再找適當的時機發送給對方 LLC。對方 LLC 接收到後,立即回應確認訊號給傳送端 LLC,再找適當的時機將資料單元傳送給上層的通訊軟體。因為在 Type 3 LLC-PDU 上沒有序列編號,所以一次只能傳送一個資料單元。如果,發送端的上一層速率過快,重覆傳送資料單元給 LLC 層,可能造成資料蓋覆,而遺失資料單元。同樣的,接收端的上層通訊軟體速率過慢,也可能會造成 LLC 層上的資料被蓋覆掉。有關於Type 3的傳輸運作方式有下列四種情況:

(A) 成功的資料傳送

網路層軟體可利用DL_DATA_ACK.Request要求LLC-A將資料傳送給對方,並要求對方回應。對方LLC-B接收到該筆資料後,以DL_DATA_ACK.indication通知其上層的通訊軟體(網路層)並且即時回送一個回覆訊息。LLC-A收到此回覆訊息以後以DL_DATA_ACK_STATUS.indication通知上一層通訊軟體(網路層),對方已正常接收到資料。如圖7-21 (a) 所示。

7-21 Type 3 的傳送方式

(B) 不成功的資料傳送

LLC-A傳送出資料訊息後,在一段時間後(Time out)沒有接收到對方LLC-B傳回來的回覆訊息,則LLC-ADL_DATA_ACK _STATUS.indication通知其上層通訊軟體(網路層),告知傳送失敗的原因。如圖 7-21 (b) 所示。

(C) 詢問資料傳送

除了主動傳送資料外,Type 3服務也提供邀請其他工作站傳送資料的服務。上層通訊軟體(網路層)可利用DL_REPLY.request邀請(或詢問)對方傳送資料。對方的LLC-BDL_REPLY.indication通知上一層通訊軟體(網路層),並且立即回覆訊息給傳送端。傳送端的LLC-A接收到回應訊息後,以DL_REPLY_ STATUS.indication通知上一層通訊軟體(網路層)邀請或詢問的結果。如圖 7-21 (c) 所示。

(D) 詢問失敗

如同詢問資料的傳送一樣,但當傳送端LLC-A經過一段時間後(Time out)未接收到對方回應訊息,便以DL_REPLY_STATUS.indication通知上層通訊軟體(網路層)詢問失敗的原因。如圖7-21 (d) 所示。

詢問式資料傳送必須要兩個介面程式配合。如上層通訊軟體有資料需要LLC層等待對方來詢問傳送,首先上層通訊程式以DL_REPLY_UPDATE.request,將資料填入LLC層,當LLC層接收到對方詢問傳送資料時,便立即將資料送出。LLC層接收到本身電腦填入資料,可以用DL_REPLY_UPDATE_STATUS.indication回應上層(網路層)已填入資料。如果上層通訊軟體重複填入資料,LLC層將保留最新資料,而拋棄舊資料。

 

翻轉工作室:粘添壽

 

電腦網路與連結技術:

 

 

翻轉電子書系列: