第三章

IEEE 802.2 邏輯鏈結控制 (LLC)

在IEEE 802系列的標準中將鏈結層(Data Link Layer) 分為二個部分，稱為「邏輯鏈結控制」(Logical Link Control, LLC) 及「媒介擷取控制」(Medium Access Control, MAC) 。其中 MAC 是制定如何使用傳輸媒介的通訊協定，如：

CSMA/CD 通訊協定 (IEEE 802.3) 是規範如何在匯流排 (Bus) 的網路結構下使用傳輸媒介。

Token-Bus 通訊協定 (IEEE 802.4) 是規範如何在匯流排的網路結構下利用訊標(token) 來控制傳輸媒介的使用。

Token-Ring通訊協定 (IEEE 802.5) 是規範如何在環狀 (Ring) 網路的結構下利用訊標來控制傳輸媒介的使用。

DQDB通訊協定 (IEEE 802.6) 是規範如何在雙匯流排 (Dual Bus) 的網路結構下達到以分散式佇列(Distributed Queue) 的方式來使用傳輸媒介。

無線網路通訊協定 (IEEE 802.11) 是規範如何在無線區域網路的結構下控制傳輸媒介的使用。

Demand-Priority 通訊協定 (IEEE 802.12) 是規範如何在環狀網路的結構下提供具有優先權等級之服務及控制傳輸媒介的使用。

在 LLC 方面 IEEE 802只制定了一種標準，各種不同的 MAC 都使用相同的LLC 。這使得更高層的通訊協定不必依賴區域網路的實際架構。LLC 的主要工作是控制訊號的交換，控制資料的流量 (data flow control) ，解釋上層通訊協定傳來的命令並且產生回應，以及克服資料在傳送的過程當中所可能發生的種種問題，如資料發生錯誤，重覆收到相同的資料，接收資料的順序與傳送的順序不符等等。LLC 的規格分為三大部分，如圖3-1 所示：

與網路層通訊協定的介面部分。

與MAC 層通訊協定的介面部分。

與其他工作站上的LLC 之間的通訊協定部分。

圖3-1 LLC 規格

不同工作站之網路層通訊協定可透過 LLC 來溝通。由於網路層上可能有許多種通訊協定同時存在，而且每一種通訊協定又可能同時與多個對象溝通，因此當 LLC 從 MAC 收到一筆資料時必須能夠判斷要送給網路層的那一個通訊協定。為了達到這種功能，LLC 提供了所謂的「服務點」(Service Access Point ，簡寫為 SAP) 如圖3-2 所示。服務點的使用可以簡化資料轉送的處理過程。如圖3-3 所示，每個網路層的通訊協定都可以使用多個服務點與其他工作站上的網路層通訊協定溝通。

圖3-2 LLC 提供服務點

圖3-3 服務點的使用

為了能夠辨認出 LLC 通訊協定間傳送的資料是屬於誰，每一筆 LLC 的資料（稱為 LLC data unit 或 LLC PDU）上都有「目的地服務點」(Destination Service Access Point, DSAP) 及「原始服務點」(Source Service Access Point，SSAP) ，如圖3-4 所示。一對 DSAP 與 SSAP 形成所謂的通訊連線(Connection)。由 SSAP 送出來的資料經過 LLC 的傳送之後便送給 DSAP，反之亦然。因此 DSAP 與 SSAP 成為獨立的通訊連線，彼此間所傳送的資料不會與其他通訊連線的資料交換。當然在傳送的過程中所有通訊連線的資料都必須經由唯一的 MAC 管道來傳送。

圖3-4 LLC PDU 格式

LLC 提供給網路層使用的服務有四種。分別稱為：

TYPE 1 服務

TYPE 2 服務

TYPE 3 服務

TYPE 4 服務

其中 TYPE 1 服務及TYPE 3 服務是提供不需要依靠通訊連線(Connectionless Service) 的服務。而 TYPE 2 服務則是提供通訊連線式的服務 (Connection oriented Service) 。在 TYPE 1 的服務之下，每一筆被傳送的資料 (LLC PDU) 都被當成是獨立的個體，網路根據其中的目的地位址來傳送資料，也就是一般所謂的 datagram 式服務。此類服務並不保證資料可以安全且正確的傳送到對方。在資料的傳送過程當中如果發生狀況，如資料錯誤或損毀，則資料會被丟棄並且沒有重送的功能。在 TYPE 2 的服務之下，則為了提供資料正確且按照秩序的傳送，必須依賴通訊連線的建立。在資料傳送之前首先必須建立通訊連線，然後才能開始傳送資料。此時傳送者的 LLC 與接收者 LLC 之的通訊協定會排除各種困難與問題，如資料錯誤、資料重覆、秩序不對等等，正確的傳送資料。在資料傳送完之後則可將通訊連線結束。TYPE 3 和 TYPE 1 相似，不過針對每一筆接到的資料都要回一個「回覆」(Acknowledgement) 訊息。TYPE 4 服務則同時提供以上三種服務。

LLC 提供給網路層的服務是利用下列三種基礎呼叫 (primitives)：

要求 (Request)

通知 (Indication)

確認 (Confirm)

如圖3-5 所示，網路層軟體經由「要求」基礎呼叫 (Request primitive) 來提出服務的要求。此要求經過網路的傳送之後到達對方。接收者的 LLC 則以「通知」基礎呼叫 (Indication primitive) 來指示其上端的網路層軟體。其上端網路層軟體的回應則經由網路傳送回來，LLC 則以「確認」基礎呼叫 (Confirm primitive) 來回答剛才所提出的要求（如要求成功或失敗等）。

圖3-5 基礎呼叫的使用

在 TYPE 1 的服務中由於不提供可靠的傳送服務，因此沒有「確認基礎呼叫」，其提供的服務只有二個基礎呼叫：

DL-UNITDATA.request （傳送資料）

DL-UNITDATA.indication（指示接收資料）

在 TYPE 2 的服務中則根據不同的功能將所提供的基礎呼叫分為五類：

(1) 通訊連線的建立(Connection establishment)

(2) 資料的傳送(Data transfer)

(3) 通訊連線的終止(Connection termination)

(4) 通訊連線的重設(Connection resetting)

(5) 通訊連線的資料流量控制(Connection flow control)

圖3-6 所示為建立通訊連線的過程範例。其中：

網路層軟體利用DL_CONNECT.request 來要求其下的LLC 表示其欲建 立一個通訊連線（對象是誰則在指令的參數中記載）。

此要求經過網路的傳送之後到達接收端的 LLC，並且在確認 DSAP 後，LLC 利用 DL_CONNECT.indication 來通知其上的網路層軟體表 示有人欲與其建立通訊連線。

接收端的 LLC 同意此要求後，以 DL_CONNECT.response 回應。

在傳送端的 LLC 以 DL_CONNECT.confirm 來回答該要求的結果（可能成功或失敗）。

圖3-6 建立通訊連線過程範例

TYPE 3 服務提供的是不建立通訊連線但有回覆確認的傳送服務，其提供的基礎呼叫有：

DL_DATA_ACK.request

DL_DATA_ACK.indication

DL_DATA_ACK_STATUS.indication

DL_REPLY.request

DL_REPLY.indication

DL_REPLY_STATUS.indication

DL_REPLY_UPDATE.request

DL_REPLY_UPDATE_STATUS.indication

　

LLC 利用 MAC 所提供的服務來傳送 LLC PDU。MAC 則利用下列三種基礎呼叫來提供服務：

LLC 利用 MA_UNITDATA.request來要求 MAC 將一個 PDU 傳送給一個或多個指定的 LLC。當接收站的 MAC 接收到一個 PDU 後則利用MA_UNITDATA.indication 來通知其上方的 LLC。接收站的 LLC 的回應則由網路傳送回來，傳送站的 MAC 則利用 MA_UNITDATA_STATUS.indication 來提供該要求是成功或失敗的消息。

　  3.4 LLC 通訊協定

前面二節所介紹的是 LLC 與網路層及 MAC 層的介面規格。在這節中我們將介紹 LLC 與 LLC 之間的通訊協定。

LLC 與 LLC 之間所傳送的 PDU 可分為三種命令：

1. 未編號命令 (Unnumbered Commands，稱為 U-格式命令) 。此類 PDU

沒有編號，共有 8 個功能不同的命令，如圖3-7 所示。

圖3-7 U-格式命令

2. 資料傳送命令(Information Transfer Command ，稱為 I-格式命令）。

此類 PDU 的控制欄 (control field) 有 2 個位元組，其中包含 Send count- N(S) 及 Receive count-N(R)，如圖3-8 所示。

此類 PDU 是用來傳送 TYPE 2服務的資料，即提供可靠的傳送功能。為了達到這個目的，每一筆資料都必須給予編號，稱為「順序編號」(sequence number) 。

PDU 上之 N(S) 及 N(R) 的意義為：

N(S)：這筆資料本身的順序編號。

N(R)：傳送這筆資料的 SSAP希望下一個收到對方 (DSAP) 送來的 PDU

上的 N(S) 值。

由於 N(S) 及 N(R) 都只有 7 個位元，因此其值介於 0 與 127 之間。通常順序編號由 0 開始，依傳送資料的順序逐次加 1，到達 127 之後又從 0 開始重覆使用。

圖3-8 I-格式命令

3. 管理命令 (Supervisory Commands ，稱為 S-格式命令）。此類 PDU 用 來管理通訊連線的使用，共有 3 個功能不同的命令，如圖3-9 所示。 這 3 種命令是通訊連線的接收端用來回應傳送端的要求時使用。其中

Receive Ready (RR) 命令表示通訊連線的接收端已經準備好可開始接收資料。

Receive Not Ready(RNR) 命令表示通訊連線的接收端尚未準備接收資料（可能由於工作太忙或貯存資料位置不夠）。

Reject(REJ) 命令表示拒絕接受傳送端的要求或資料（如要求不當或資料錯誤等等）。

圖3-9 S-格式命令

由於 TYPE 1 服務並沒有提供可靠的傳送服務，因此其通訊協定只有3 種未編號命令：

未編號資料 (Unnumbered Information,UI) 。此即為每筆都是獨立的TYPE 1 資料。此資料可能由一個 LLC 的 SAP 送給另外一個 LLC 上的一個或多個 SAP ，因為其上的 DSAP 可能是某一個工作站上的一個各別的 SAP，一群 SAP，或是全體 SAP，如圖3-10 所示。當 LLC 接收到一個未編號資料時並不做順序檢查(PDU中無此欄位)，也不回送回覆資料(Acknowledgement) 。因此若資料傳送發生錯誤則可能造成資料流失。 (a) DSAP 為各別的 SAP (b) DSAP 為一群 SAP (c) DSAP 為全體 SAP 圖3-10 未編號資料的使用

交換識別碼 (Exchange Identification, XID) 。此命令是讓二個工作站互相交換有關其所提供的服務的資訊。在 TYPE 2 服務時則用來告訴對方可連續傳送多少筆資料而不必等待回應。一個 LLC 可利用 XID 將本身的資訊傳送給另外一個 LLC 。當 LLC 收到 XID 時則必須回送一個 XID，其上並包含適當之資訊。使用 XID 命令來交換的資訊可能有：

檢查某一個工作站是否在網路上運作。當工作站關機或當機則不會有回答命令。因此可用此方法來初步檢查某一個工作站是否在網路上運作。

辨識到底有那些工作站屬於相同的一個群體地址。一個 LLC 可以將 XID 傳送給某一個工作站群體。每一個屬於此群體的工作站上的 LLC 在收到 XID 之後都必須回覆，因此可做到辨識的目的。

檢查工作站位址是否重覆。如果收到二個相同的回覆 XID 則表示有工作站位址相同。

上線通知。一個重新開機的工作站可以用 XID 來通知其他工作站表示其重新加入網路系統。已經開機的工作站也可定時的傳送 XID 表達它的存在。

測試 (Test)。此命令用來測試 LLC 到 LLC 間的路徑是否仍然存在。收到 Test 命令的 LLC 必須回覆一個 Test 命令。如果詢問的 Test 命令上有資訊則在回覆時必須將資訊也一併送回。

　

由於 TYPE 2 服務必須提供可靠的資料傳送，因此在資料傳送之前要先建立通訊連線。而且每一筆資料都有一個順序編號以便檢查那一筆資料流失或重覆，以及確保資料傳送的順序正確。每一筆傳送出去的資料都要先貯存在緩衝器內，並且啟動其計時器。如果在計時器未逾時(timeout) 之前收到對方的回覆表示正確收到該筆資料則將該資料於緩衝器中清除並且停止計時器。否則必須將該筆資料重送一次(retransmission) 。

在資料的傳送過程當中可能出現的問題主要有 3 種：

q 資料流失(lost)

q 資料重覆(duplicate)

q 資料接收順序不對(out of order)

造成資料流失的原因是資料在傳送時受到訊號干擾，導致資料錯誤被丟棄。造成資料重覆的原因是回覆資料流失。在此情況之下傳送端會因為計時器逾時而重送資料，結果接收端收到二筆完全一樣的資料。造成資料接收順序不對的原因是傳送端在傳送一連串資料後，每一筆資料在傳遞路徑上的延遲時間不同。如先送的資料可能流失，結果後送的資料反而先到達。

這三種問題都可以利用資料的順序編號來幫助解決。因為每一筆資料都有不相同的順序編號，因此當接收端收到二筆順序編號相同的資料時則表示資料重覆，可丟棄其中一筆。當資料檢查發現錯誤時也可以利用順序編號來回覆傳送端要求其重送該筆資料。如果接收資料的順序不對，則可以先按其順序編號貯存起來，待資料收齊之後再按照順序往上傳給網路層軟體。

通訊連線的建立與終止使用 U-格式命令與反應。建立通訊連線的過程如圖3-11 所示，當 LLC1 收到 UA(Unnumbered Acknowledgement) 命令時則表示 SSAP 與 DSAP 間的通訊連線已經建立完成。它們的 N(S) 值和N(R) 值都設為 0，然後彼此可以開始傳送／接收資料。至於通訊連線上的雙方向流量控制則是採用將在下一節中介紹的所謂「滑動視窗法」(Sliding Window method)。

圖3-11 通訊連線的建立

終止通訊連線的過程和建立時相似。通訊連線的任何一端都可以 DISC (Disconnect) 命令來要求終止通訊連線。只要接收到一個 UA 或 DM 反應則表示可將通訊連線終止掉。

滑動視窗法 (Sliding window) 的主要目的是在控制通訊連線上的資料流量。資料流量需要控制的原因則是每一個工作站的緩衝器有限。基本上，對於每一筆送出去的資料都要有一個緩衝器將其保存起來，直到收到對方的正確回覆為止。相同的，對於每一筆沒有按照順序接收到的資料，在往上送給網路層軟體之前也要先存在緩衝器中，直到按順序收齊且往上送之後才能將緩衝器空出來。因此，對於每一個通訊連線，系統都必須準備「傳送緩衝器」及「接收緩衝器」。而通常一個工作站都可以同時建立許多個通訊連線。尤其是伺服器(Server)，例如檔案伺服器、列印伺服器等等，往往需要同時建立數十個以上的通訊連線。所以在有限的緩衝器（或是主記憶體）之下，如何有效的分配緩衝器給每一個通訊連線也是極為重要的工作。

最簡單的分配法是每一個通訊連線只給一個傳送緩衝器。在這種情形之下，傳送端每送出一筆資料就必須停下來等待回覆資料。收到回覆資料之後才可以再送下一筆資料。這種方法稱為「停止與等待法」(Stop-and-wait)，如圖3-12 所示。其最大的優點在於簡單而且不需要大量緩衝器，而最大的缺點是資料傳送太慢，必須等待回覆資料，以及浪費通訊連線容量（回覆資料量佔了50% ）。

圖3-12 停止與等待流量控制法

為了增加資料傳送速度及減少回覆資料量，可採用所謂的「滑動視窗法」。在使用此方法中，必須利用順序編號(Sequence number) 。每一筆傳送的資料都有一個順序編號 N(S)。同時為了減少回覆資料量，每一筆資料上也載有回覆訊息 N(R)其意義為：

N(S)：這筆資料本身的順序編號。

N(R)：傳送這筆資料的 SSAP 希望下一個收到對方 (DSAP) 送來的資料上的 N(S) 值，也就是回覆說順序編號小於 N(R) 值的資料都已經正確的收到。

例如圖3-13 所示，該筆由工作站 A 送給工作站 B 的資料本身的順序編號為 5，而且 A 已經正確收到由 B 送來且順序編號小於 4 (如 0,1,2,3) 的資料，因此希望下一次收到 B 的資料其順序編號為 4。

圖3-13 N(S) 與 N(R) 之意義

為了易於說明 N(S) 及 N(R) 的使用，我們以圖3-14 來表示 N(S) 值及 N(R) 值的範圍 (0 ≦ N(S)，N(R) ≦ 127，不過為便於說明，在此假設 0 ≦ N(S)，N(R) ≦ 127)。其中灰色的部分分別稱為「傳送視窗」(Send window) 及「接收視窗」(Receive window)。以順時針方向為準，視窗的前頭及後頭分別稱為「前端」和「後端」。視窗的大小（包含多少個順序編號）稱為「視窗尺寸」(Window size) ，如圖3-14 中視窗尺寸分別為 3 和 5。其意義分別為：

傳送視窗：不必等待回覆訊息而可以連續傳送的資料的順序編號。如圖3-14 中，可連續送出順序編號分別為 0,1,2 的 3 筆資料。

接收視窗：可接收對方送來資料的順序編號。如圖3-14 中，可接收資料的順序編號為 0,1,2,3,4, 其他順序編號的資料都會被丟棄。

圖3-14 傳送視窗與接收視窗

由於每一個通訊連線都包含一對 SAP ，因此總共有 4 個視窗（每邊各使用二個），如圖3-15 所示。至於視窗尺寸的大小則是每一個工作站根據其緩衝器的多寡來決定的。其中每一個工作站先決定要給對方多少個緩衝器（接收視窗尺寸），然後將此值以 XID 命令送給對方，成為對方的傳送視窗尺寸。所以 4 個視窗是成對匹配的。

圖3-15 視窗之使用

接下來我們介紹視窗的使用方法及滑動原則，請參考圖3-15。當工作站 A 有一筆資料要傳送時，該筆資料的 N(S) 即是 A 的傳送視窗中未被使用過且最靠後端的順序編號。而 N(R) 即是 A 的接收視窗中最靠後端的順序編號。例如圖3-15 所示，A 所傳送的第一筆資料上的 N(S) 及 N(R) 都為 0。對於傳送視窗，使用過的順序編號必須先標記起來，一直等到收到對方的回覆訊息後才可消除。

當 A 收到一筆對方送來的資料時，必須檢查其上的 N(R)，其值代表傳送視窗中，順序編號介於視窗後端和 (N(R)-1+8) mod 8 之間的資料都被正確收到。此時傳送視窗可順時針滑動，直到其後端介於 (N(R)-1+8) mod 8 和 N(R) 之間。

當A 收到一筆對方送來的資料時，也必須檢查其上的 N(S)。如果 N(S) 的值不等於接收視窗中的最後端順序編號，則表示此資料沒有按順序到達。此時必須先將其存於緩衝器中，並且將該順序編號標記起來。如果 N(S) 的值等於接收視窗中的最後端順序編號，則此資料可以往上層遞送並且開始滑動視窗，直到視窗的最後端順序未被標記。在滑動的過程當中被移出視窗外的順序編號（也就是標記過的順序編號）的資料都可以按照編號順序往上層傳送。

接下來我們以一個較完整的例子來說明滑動視窗的原理及使用情形。如圖3-16(a) 所示，假設工作站 A 的傳送視窗尺寸為 3 而接收視窗的尺寸為 5。工作站 B 則相反。開始時，A 先傳送一筆資料給 B ，由於是第一筆資料因此其 N(S)＝0。因為 A 希望 B 送過來的下一筆資料的順序編號為 0，因此 N(R) 也等於 0。A 在傳送這筆資料後便將傳送視窗中順序編號為 0 者標記起來表示該順序編號已用過且未收到回覆訊息（圖中以無邊線之灰色圓形表示）。當 B 接收到這筆資料後發現其順序編號等於接收視窗的最後端，因此將視窗向前滑動一個位子並且將該筆資料往上層傳送，如圖3-16(b) 所示。

圖3-16(a)

圖3-16(b)

接著工作站 B 連續傳送二筆資料給工作站 A。其 N(S) 值分別為 0 和 1。由於剛才 B 的接收視窗已經滑動過，因此其希望 A 送過來的下一筆資料的順序編為1。所以 N(R) 皆為1 。這也表示要告訴 A 說前一筆資料已經正確收到。由於這二筆資料尚未收到回覆訊息因此在傳送視窗中標記起來。當這二筆資料到達 A 後，由於其 N(S) 值皆符合 A 的接收視窗值且位於接收視窗的最後端，因此 A 的接收視窗可向前滑動二格並且將該二筆資料往上層傳送。此時所有視窗的狀態如圖3-16(c) 所示。

圖3-16(c)

接下來工作站 A 連續送三筆資料給工作站 B。其 N(S)值分別為 1,2,3,而 N(R) 值則為 2 (告訴 B 說其傳送過來之順序編號為 0 及1 的資料已正確收到)。資料傳送後必須在 A 的傳送視窗中做好標記。假設在傳送的過程當中第一筆資料遺失，因此 B 只收到二筆。由於這二筆資料的順序編號都不在 B 的接收視窗的最後端，因此不可以往上層送，只能先存在緩衝器中然後標記起來（圖中以無邊線之灰色圓形表示）。在檢查 N(R) 的值為 2 後，B 的傳送視窗可以往前滑動二格，此時所有視窗的狀態如圖3-16(d) 所示。

接著工作站 B 送一筆資料給工作站 A。如圖3-16(e) 所示，其 N(S) 為2。由於 B 沒有收到 A 剛才所送來的第一筆資料（順序編號為 1），因此 B 所傳送的資料中 N(R)仍為 1。當工作站 A 收到資料後先檢查其 N(S) 為 2，於是往上層傳送且將接收視窗往前滑動一格。接著檢查其 N(R) 為 1 表示 B 並沒有收到該筆資料，於是在計時器逾時後重送該筆資料 (N(S)＝1) ，不過其 N(R) 應為 3，如圖3-16(f) 所示。當工作站 B 收到這筆重送的資料後便可將收齊的三筆資料往上層傳送並且滑動接收視窗三格。同時因為 N(R)為 3 表示前一筆傳送給 A 的資料已經被正確收到，可將傳送視窗往前滑動一格，其結果如圖3-16(f) 所示。

圖3-16(d)

圖3-16(e)

最後工作站 B 連續傳送 5 筆資料給工作站 A，如圖3-16(g) 所示。其 N(S) 值分別為 3,4,5,6,及 7。其 N(R) 值則都是 4。工作站 B 將資料傳送之後完成標記工作，而工作站 A 在接收之後則按照順序將資料往上層傳送並且滑動接收視窗。同時在檢查 N(R) 值為4 之後也將傳送視窗往前滑動一格，其結果如圖3-16(g) 所示。

圖3-16(f)

圖3-16(g)

由於TYPE 3服務沒有提供通訊連線式之服務因此也沒有流量控制的問題。使用TYPE 3 服務所傳送的每一筆資料都可要求回覆訊息藉以達到可靠傳送的目的。這與 TYPE 2 服務比較起來是較簡單，但對於大量資料的傳送則較為不便，只適用於少量資料之傳送。其使用方法如下：

網路層軟體可利用 DL_DATA_ACK.request 要求 LLC 將資料送給對方並且給一個回覆。對方的 LLC 在收到該筆資料後以 DL_DATA_ACK.indication 通知其上的網路層軟體並且隨即回送一回覆訊息。傳送端的 LLC 在收到此回覆訊息後以 DL_DATA_ACK_STATUS.indication 來通知資料的傳送結果，如圖3-17(a) 所示。如果資料無法傳送到對方則LLC 以 DL_DATA_ACK_STATUS.indication 來告知其失敗原因，如圖3-17(b) 所示。

除了主動傳送資料外，TYPE 3 服務也提供邀請其他工作站傳送資料的服務。如圖3-17(c) 所示，網路層軟體可利用 DL_REPLY.request來邀請（或詢問）對方傳送資料。對方的 LLC 以 DL_REPLY.indication 來通知其上層的網路層軟體並且立刻將資料傳送回去（如果有資料）。傳送端之 LLC 在收到此資料後以 DL_REPLY_STATUS.indication 來通知其邀請之結果。如果網路層軟體的邀請不適當則 LLC 可立即用 DL_REPLY_STATUS.indication 來告知失敗原因，如圖3-17(d) 所示。在邀請傳送的過程中，被邀請的對象應該先有資料存在 LLC 中才能在邀請來時將資料送回。網路層軟體可利用DL_REPLY_UPDATE.request 將一筆資料交給 LLC。如果在 LLC 尚未將資料送出之前又收到其上網路層軟體的資料則會將原先之資料丟棄只保留最新的資料。LLC 利用 DL_REPLY_UPDATE_ STATUS.indication 來通知網路層軟體其存放資料的結果。

(a) 資料傳送

(b) 不成功之資料傳送

(c) 詢問式資料傳送

(d) 詢問失敗

圖3-17 回覆式無通訊連線服務

3.1 何謂 LLC 中的服務點 (Service Access Point, SAP) ? 其目的為何 ?

3.2 請說明 LLC 資料格式中含有那些欄位 ?

3.3 LLC 提供給網路層那四種服務? 請分別簡單說明其特點。

3.4 LLC 提供給網路層的服務是利用那三種基礎呼叫 ?

3.5 何謂「停止與等待」 (Stop-and wait) 流量控制法 ? 其優缺點為何 ?

3.6 在 TYPE 2 服務中必須建立通訊連線。在連線上傳送資料中的 N(S) 及 N(R) 值代表何種意義 ?

3.7 請說明「滑動視窗」(Sliding Window)流量控制法的主要概念。並請與停止與等待法做比較。

3.8 何謂傳送視窗及接收視窗 ? 視窗尺寸之大小主要是根據什麼因素決定的 ?

3.9 傳送視窗向前滑動的時機為何 ?

3.10 接收視窗向前滑動的時機為何 ?

3.11 參考圖3-16(a)。請根據下列每一事件依序計算出工作站 A 及 B 傳送資料之 N(R) 及 N(S) 值。並且整理出傳送視窗及接收視窗結果。

(a) 工作站 A 傳送 3 筆訊框給工作站 B；其中第 2 筆訊框流失。

(b) 工作站 B 傳送 2 筆訊框給工作站 A；其中第 2 筆訊框流失。

(c) 工作站 A 傳送 3 筆訊框給工作站 B。

(d) 工作站 B 傳送 5 筆訊框給工作站 A。

3.12 參考圖3-16(a)。請根據下列每一事件依序計算出工作站 A 及 B 傳送資料之 N(R) 及 N(S) 值。並且整理出傳送視窗及接收視窗結果。

(a) 工作站 A 傳送 2 筆訊框給工作站 B；其中第 1 筆訊框流失。

(b) 工作站 B 傳送 1 筆訊框給工作站 A；此筆訊框流失。

(c) 工作站 A 因逾時 (timeout) 而重送第一筆訊框。

(d) 工作站 B 傳送 3 筆訊框給工作站 A。

　

3.13 TYPE 2 服務及TYPE 3 服務都可算是提供可靠的傳送服務。請比較其適用情 形。