NYCU-LYX

Lecture 3 - Integrated Service (IntServ)

Motivation of IntServ (動機)

Assumptions of IntServ

Key Components of IntServ (關鍵IntServ元件)

How to Setup Resource Reservation in IntServ

Flow Specification（流規範）

範例：
Token Bucket的Token到達速率為 100 token/秒，bucket depth為 10 tokens。這意味著每秒有 100 個tokens進入bucket中，bucket中最多可以存儲 10個tokens。
當一個packet到達時，Regulator會檢查bucket中是否有足夠的token。如果有，Regulator會發送packet並從bucket中刪除等於該packet大小的token數。如果沒有，Regulator會丟棄packet。
Token bucket可以確保流量速率不超過bucket depth。這可以防止網絡過載並確保所有流量都能得到良好的服務質量（QoS）。

Challenges of Route Selection （路由選擇的挑戰）

路由選擇是一個複雜的問題，需要考慮多種因素，例如網絡拓撲、鏈路狀態、流量模式和 QoS 要求。簡單的路由算法，例如最短路徑算法，通常不能滿足這些要求。
IntServ 將路由與預留分開，可以解決以下問題：
提高路由的靈活性：IntServ 不需要路由模塊了解網絡中可用資源的狀態。這使得路由模塊可以更靈活地選擇路徑，例如根據網絡負載或 QoS 要求進行選擇。
簡化路由模塊的設計：IntServ 路由模塊不需要考慮資源預留的問題，這可以簡化其設計。
提高資源預留的效率：IntServ 可以通過集中資源預留來提高效率。
IntServ 的缺點是可能會導致路由與資源預留之間的矛盾。例如，路由模塊可能會選擇一條最短路徑，但該路徑上的資源不足以滿足預留要求。這種矛盾可能會導致丟包或服務質量下降。

More About Reservation Setup (更多預留設定)

Admission Control (進入許可控制)

特徵 RT-SYN RT-ASYN NRT
同步性 同步 異步 非同步
實時性 實時 實時 非實時
數據包到達時間 指定的時間窗口內 指定的時間窗口內，允許一定的延遲 任意時間
丟包或延遲的影響 嚴重 可接受 允許

Flow Identification (Flow 識別)

Packet Scheduling

Service Models Defined in IntServ

Reference: https://datatracker.ietf.org/doc/rfc2212/

RSVP

Path message 和 Reservation message 是 RSVP 中最重要的兩個消息。Path message 用於將發送方信息傳遞給接收方，並建立路徑狀態。Reservation message 用於由接收方向發送方指定所需的 QoS 和參數。

Explicit vs. wildcard server selection

Distinct vs. shared reservation

以下是一個表格，總結了 Explicit vs. wildcard server selection 和 Distinct vs. shared reservation：

Server selection Reservation Fixed filter (FF) Wildcard filter (WF) Shared explicit (SE)
Explicit Distinct √ × √
Explicit Shared × × √
Wildcard Distinct × √ ×
Wildcard Shared × √ √

示例

有一個路由器，具有兩個輸入接口 I1 和 I2，以及兩個輸出接口 O1 和 O2。有 3 個發送方 S1、S2 和 S3，以及 3 個接收方 R1、R2 和 R3。設 B 是要預留的資源的基本單位。

                         ________________
                     (a)|                | (c)
      ( S1 ) ---------->|                |----------> ( R1 )
                        |     Router     |      |
                     (b)|                | (d)  |---> ( R2 )
      ( S2,S3 ) ------->|                |------|
                        |________________|      |---> ( R3 )
                                                |

WF-style reservations

                             |
               Sends         |       Reserves             Receives
                             |
                             |       _______
         WF( *{4B} ) <- (a)  |  (c) | * {4B}|    (c) <- WF( *{4B} )
                             |      |_______|
                             |
      -----------------------|----------------------------------------
                             |       _______
         WF( *{4B} ) <- (b)  |  (d) | * {3B}|    (d) <- WF( *{3B} )
                             |      |_______|        <- WF( *{2B} )

Wildcard sender selection + 共享預訂(shared reservation)

showing the WF style, illustrates two distinct situations in which merging is required.

(1) Each of the two next hops on interface (d) results in a separate RSVP reservation request, as shown; these two requests must be merged into the effective flowspec, 3B, that is used to make the reservation on interface (d).

(2) The reservations on the interfaces (c) and (d) must be merged in order to forward the reservation requests upstream; as a result, the larger flowspec 4B is forwarded upstream to each previous hop.

(c) <- WF( {4B} ) : * {4B}

(d)<- WF( *{3B} ) : -
➝ * {3B} #two requests merged into effective flowspec 3B
(d)<- WF( *{2B} ) : -

(c) and (d) merged ➝ {4B} # {4B} > * {3B}, so larger flowspec 4B is forwarded

####

FF-style reservations

            Sends         |       Reserves             Receives
                          |
                          |       ________
     FF( S1{4B} ) <- (a)  |  (c) | S1{4B} |  (c) <- FF( S1{4B}, S2{5B} )
                          |      |________|
                          |      | S2{5B} |
                          |      |________|
     ---------------------|---------------------------------------------
                          |       ________
                  <- (b)  |  (d) | S1{3B} |  (d) <- FF( S1{3B}, S3{B} )
     FF( S2{5B}, S3{B} )  |      |________|      <- FF( S1{B} )
                          |      | S3{B}  |
                          |      |________|

              Figure 6: Fixed-Filter (FF) Reservation Example

Explicit sender selection+ 區分預訂(distinction reservation)

Figure 6 shows Fixed-Filter (FF) style reservations. For each outgoing interface, there is a separate reservation for each source that has been requested, but this reservation will be shared among all the receivers that made the request.

The flow descriptors for senders S2 and S3, received through outgoing interfaces (c) and (d), are packed (not merged) into the request forwarded to previous hop (b). On the other hand, the three different flow descriptors specifying sender S1 are merged into the single request FF( S1{4B} ) that is sent to previous hop (a).

S2 and S3 only one flow descriptors ➝ packed into the request forwarded to previous hop (b)

S1 three different flow descriptors ➝ merged into the single request FF( S1{4B} ) and sent to previous hop (a)

SE reservations

            Sends         |       Reserves             Receives
                          |
                          |       ________
     SE( S1{3B} ) <- (a)  |  (c) |(S1,S2) |   (c) <- SE( (S1,S2){B} )
                          |      |   {B}  |
                          |      |________|
     ---------------------|---------------------------------------------
                          |      __________
                  <- (b)  | (d) |(S1,S2,S3)|  (d) <- SE( (S1,S3){3B} )
     SE( (S2,S3){3B} )    |     |   {3B}   |      <- SE( S2{2B} )
                          |     |__________|

            Figure 7: Shared-Explicit (SE) Reservation Example

Explicit sender selection + 共享預訂(shared reservation)

Figure 7 shows an example of Shared-Explicit (SE) style reservations. When SE-style reservations are merged, the resulting filter spec is the union of the original filter specs, and the resulting flowspec is the largest flowspec.

S1 最大是 S1{3B}

(S2,S3)最大是 {3B}

RFC 2205: Resource ReSerVation Protocol (RSVP)

Disadvantage of IntServ

More About Adspec

Adspec object 在 RSVP 中用於以下目的：

以下是一個 Adspec object 的示例：

Adspec object {
  Default general parameters fragment {
    Minimum path latency: 10ms
    Path bandwidth: 100Mbps
    Integrated Services hop count: 5
    Global break bit: 0
    Path MTU: 1500 bytes
  }
  Guaranteed service fragment {
    Ctot: 1ms
    Dtot: 5ms
    Csum: 0.5ms
    Dsum: 2.5ms
  }
  Controlled load service fragment {
    // No extra data
  }
}

One Pass v.s. One Pass with Advertising(OPWA)

一次性傳輸模型是一種 RSVP 預訂模型，其中發送方和接收方只交換一次消息來建立預訂狀態。這種模型的優點是高效，但它不支持確定路徑特徵或路徑是否能夠支持所需 QoS 的功能。

OPWA（One Pass With Advertising）是一種增強功能，它允許發送方在其 PATH 消息中包含一個 Adspec。Adspec 是一種數據結構，用於在發送方和接收方之間傳遞有關端到端路徑特性的信息。

通過在 PATH 消息中包含 Adspec，發送方可以收集有關路徑的信息，包括路徑帶寬、路徑延遲和路徑是否支持集成服務。這些信息可以幫助發送方確定路徑是否能夠支持所需 QoS。

以下是 OPWA 工作原理的一個概述：

  1. 發送方發送一個 PATH 消息，其中包含一個 Adspec。
  2. 路由器在 PATH 消息中修改 Adspec，以反映路徑的實際特性。
  3. 接收方收到 PATH 消息後，檢查 Adspec，以確定路徑是否能夠支持所需 QoS。
  4. 如果路徑能夠支持所需 QoS，則接收方發送一個 RESV 消息來建立預訂狀態。
  5. 如果路徑無法支持所需 QoS，則接收方發送一個 REJECT 消息。

Slack Term (鬆弛因子)

Slack term = desired delay - actual delay

Slack term可以用於以下目的：

Slack term的值通常以微秒為單位指定。Slack term越大，路由器就越有靈活性來處理延遲變化。但是，Slack term越大，Flow的bandwidth就越低。

Slack term是一個重要的 RSVP 參數，可用於為保證服務流提供 QoS 保證。以下是一個鬆弛因子的示例：

RSpec {
  Flowspec {
    Bandwidth: 2.5 Mbps
    Delay: 10ms
  }
  Slack term: 5ms
}

這個示例指定了 2.5 Mbps 的帶寬和 10ms 的延遲。鬆弛因子為 5ms，這意味著路由器最多可以增加 5ms 的延遲，而不會影響流的 QoS。