多媒體網路 (Multimedia Networking)

Presentation on theme: "多媒體網路 (Multimedia Networking)"— Presentation transcript:

1 多媒體網路 (Multimedia Networking)

2 簡介 隨著網路的快速發展，我們在網路上使用多媒體資料的機會越來越多，同時多媒體網路也漸漸受到重視，所以就有許多因應多媒體網路的協定產生了。

3 網路中的多媒體 在網路中的多媒體有以下幾個特徵： 對於延遲（delay）較敏感 可以容忍資料遺失（loss tolerant）
資料具有連續性（continuous data）

4 網路中的多媒體（2） 多媒體應用程式的分類 串流儲存式（streaming stored）的audio和video
先從網路下載多媒體檔案，再播放 串流即時式（streaming live）的audio和video 直接透過網路播放多媒體檔案 即時交談式（real-time interactive）video 可依照我們的需求播放多媒體檔案

5 網路中的多媒體（3） 串流儲存式（streaming stored）的audio和video
由使用者端去要求播放事先儲存在伺服器端的多媒體檔案並透過網路傳送 使用者可控制多媒體檔案的播放 延遲：從使用者要求到播放開始的時間大約會有1秒到10秒之間

6 網路中的多媒體（4） 單向即時（unidirectional real-time）模式 因為real-time所以直接由網路傳送播放
也因為是即時播放，所以使用者不能控制多媒體播放，只能聽和看 例如：線上TV，線上廣播

7 網路中的多媒體（5） 交談式即時（Interactive real-time）模式 Jitter
但是因為為交談式所以所傳送的資料並不像單向模式那麼簡單，所以所造成的延遲會增加 Video：< 150 msec可接受範圍 Audio：< 150 msec為良好，<400可接受範圍 Jitter 在同一個多媒體串流中的封包的延遲變化程度

8 網路中的多媒體（6） 在我們現在所使用的Internet是使用best effort傳送，所以對於傳送多媒體資料會有很大的影響，例如：沒有辦法對於delay或是delay variation提供保證 目前往處理封包大都是： 每一個封包的地位平等 FIFO 所以我們必須將所要處理的封包做分類

9 如何應用現在的網路傳送多媒體 使用UDP來傳送 在接收端使用暫存器和控制播放的速度已減少jitter 將封包加上時間標籤以利播放
將不重要的封包丟掉

10 如何使現在的網路更適合傳送多媒體 我們必須改變網路所使用的協定可以讓我們所使用的應用程式可以預先保留端對端的頻寬
所使用的協定必須要可以保留頻寬 例如：RSVP 必須改變router上scheduling policies來實現保留頻寬 我們必須需要更複雜的軟體來實現在使用者和router上面

11 Streaming Stored & Audio & Video
Streaming stored media Audio和vedio檔案儲存在伺服器裡 由使用者發出要求存取 Audio和vedio檔案會在請求後10秒後送出 與伺服器端的交談行為是允許的 這裡指的是我們可以將多媒體檔案依照我們需求作動作（暫停、倒轉、前進）

12 Streaming Stored & Audio & Video
Media player 移除jitter 解壓縮多媒體檔案 錯誤更正 圖形化介面讓我們更好控制多媒體播放 可以讓我們將播放程式嵌入到瀏覽器中 例如：Microsoft media player、Quick time、Real time player…

13 網頁伺服器的多媒體串流（1） 瀏覽器透過HTTP要求多媒體資料 伺服器透過HTTP回應瀏覽器
瀏覽器會去呼叫media player來播放多媒體資料 缺點： Media player必須透過瀏覽器和伺服器溝通

14 網頁伺服器的多媒體串流（2） 瀏覽器和伺服器一樣透過HTTP溝通 瀏覽器只會收到meta file，並且呼叫media player
Media player會透過TCP和伺服器建立連線，並使用HTTP交換訊息且開始播放檔案 缺點： 雖然不需透過瀏覽器接收多媒體資料，但是透過HTTP不能讓我們使用快轉、倒轉、暫停等功能 也許我們可以試試使用UDP來傳送

15 多媒體串流伺服器 透過網頁伺服器達成多媒體需求的溝通 Media player再與多媒體串流伺服器利用UDP溝通，取代了TCP的使用

16 即時串流協定（Real Time Streaming Protocol: RTSP）
RFC：2326 用戶端與伺服器模式的應用層協定 提供使用者一些控制多媒體功能，例如：快轉、倒轉、暫停等… 使用HTTP協定傳送多媒體資料，但是HTTP本身無法儲存連續性的多媒體資料

17 即時串流協定（Real Time Streaming Protocol: RTSP）（續）
無法定義要如何對多媒體資料加封 無法限制多媒體資料透過什麼協定傳送 無法定義media player如何暫存資料 現實網路當中我們大多使用RTSP來當作傳送控制訊號（control message）的協定

18 out of band control RTSP的控制信息和多媒體資料使用不同的port號，所以我們稱為out-of-band
多媒體資料的資料結構並不是定義在RTSP，所以我們認為是in-band 如果RTSP的信息和傳送多媒體資料的port有重複的話，我們稱為interleaved

19 RTSP的運作程序

20 Meta file的範例 <title>Twister</title> <session>
<group language=en lipsync> <switch> <track type=audio e="PCMU/8000/1" src = "rtsp://audio.example.com/twister/audio.en/lofi"> e="DVI4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audio.example.com/twister/audio.en/hifi"> </switch> <track type="video/jpeg" src="rtsp://video.example.com/twister/video"> </group> </session>

21 RTSP session 每一個RTSP都有一個session的識別號，每一個識別號由伺服器選定
用戶端使用SETUP發出請求，然後伺服器會回應一個識別號給用戶端 用戶端會一直使用這一個識別號直到這一個session結束為止

22 RTSP交換訊息範例 C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0
Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/ OK Session 4231 C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0- C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Range: npt=37 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 S: OK

23 Real-time interactive applications
我們大多所使用的交談式應用有： PC對PC的電話 PC對家用電話 Dialpad Net2phone 視訊會議 Web cams 接著我們將詳細介紹PC對PC的網路電話

24 Internet phone over best-effort (1)
之前提過在現今網路會有packet delay、loss 和 jitter Internet phone的例子 在通話時才會產生封包 Bit rate為64kbps 通話時每20 msec會產生160 bytes的chunk Chunk＋header加封後利用UDP傳送 因為有可能資料流失，所以接收端必須有判斷的機制

25 Internet phone (2) Packet loss 端對端的延遲 Delay jitter 移除jitter的方法
使用UDP加封封包 Datagram可能會超出router queue 的TCP可以減少loss但是會增加delay 端對端的延遲 端對端的延遲在400 msec以內我們可以接受 Delay jitter 必須要在20 msec內 移除jitter的方法 sequence numbers timestamps delaying playout

26 Internet phone (3): fixed playout delay
這裡是使用固定的delay time q，而每一個trunk會被mark上一個time stamp 所以再接收端會在time=t+q時播放如果超出這歌時間就會丟棄這個資料 所以在這裡不需要sequence number q在這裡是一個trade off 較大的q，較少的封包被丟棄 較小的q，有較好的交談性

27 Internet phone (4): fixed playout delay
First playout schedule: begins at p Second playout schedule: begins at p’

28 Recovery from packet loss (1)
forward error correction (FEC) 每n個chunk為一個group，並加入一個額外的XOR chunk 所以總共會送出n+1個trunk，並會增加頻寬的1/n 可以從n+1 chunks中更正一個chunk 接收所有chunks的延遲必須要固定 Trade off n增加，頻寬、loss rate和播放延遲亦會增加

29 Recovery from packet loss (2)
2nd FEC scheme 下一個封包會夾帶一個跟前一個一樣但quality較差的封包，萬一前一個封包掉了，後一個可以補回來

30 Recovery from packet loss (3)
Interleaving 將一個封包在細分成數個小單位，然後前後交叉傳送以降低loss的機會

31 Real-Time Protocol (RTP)
RFC：1889 和前面的RTSP所不同的是RTP為了封包攜帶audio和video有定義封包的結構 RTP封包提供了 封包攜帶的資料格式識別 封包序號編號 時間標記 RTP通常在終端系統使用 RTP使用UDP來加封封包

32 RTP runs on top of UDP RTP和UDP共同組成了傳送層 應用成的程式透過RTP和UDP溝通 因為RTP是為了額外提供：
埠號，IP位址 錯誤更正 資料格式識別 封包序號編號 時間標記

33 RTP and QoS RTP並沒有提供適時的資料傳送和任何麼品質服務保證 RTP對於封包的加封只會在終端系統看的出來
因為如此在傳統的routing機制中沒有辦法對於RTP所傳送的封包最任何特別的服務 所以為了提供應用程式有品質服務保證，在網路之中必須使用類似RSVP這樣可以預先保留頻寬的機制來提供所需要的品質保證

34 RTP Header Payload Type (7 bits)：提供了128種可能的encoding的方法
Payload type 0: PCM mu-law, 64 Kbps Payload type 3, GSM, 13 Kbps Payload type 7, LPC, 2.4 Kbps Payload type 26, Motion JPEG Payload type 31. H.261 Payload type 33, MPEG2 video Sequence Number (16 bits)：用來偵測封包的遺失LOSS

35 RTP Header Timestamp field (32 bytes)：用來反映出第一個資料封包的採樣和用來移除jitter
Synchronization Source identifier (SSRC)： 32 bits，當作是一個資料源頭的識別號，這一個識別好是亂數決定的

36 Real-Time Control Protocol (RTCP)
和RTP會同時發生作用 每一個RTP的session會用RTCP溝通，讓應用程式獲得有用的資訊 並且會統計有多少個封包被傳送、多少封包遺失、jitter變化 有了這一些資訊應用程式可以用來調整效能 例如：loss rate增大時…

37 RTCP - Continued 每一個RTP session都會有一個multicast address，而所有屬於這一個session的RTP和RTCP都會使用這一個address RTP和RTCP的封包是由不同的埠號來區分 RTCP會有三種report packets Receiver report packets Sender report packets Source description packets

38 RTCP--report packets Receiver report packets Sender report packets
紀錄封包遺失的片段、遺失的sequence number、平均的inter-arrival jitter Sender report packets RTP串流的SSRC、現在的時間、現在所傳送的封包個數和現在所傳送的byte數 Source description packets 傳送者的 、傳送者的名字、RTP串流所相關的SSRC，這一個封包提供了SSRC和使用者（機器）之間的對應

39 串流的同步 RTCP可以用來同步在同一個RTP session裡的多媒體串流
例如：視訊會議裡包含影像和聲音 在RTP封包裡的時間標記是依附video或audio的取樣率決定的，而不是real-time的 接收端會使用sender report packet的資訊來做同步

40 RTCP Bandwidth Scaling
RTCP約佔整個session的頻寬的5% 例如：傳送的速率為2Mbps，則RTCP約為100kbps 如果每一個接收端都傳送RTCP給所有其他的接收端，這樣RTCP的traffic會很大 RTCP佔的100kbps會在分為接收端75kbps（75%）和傳送端的25kbps（25%）

41 H.323 H.323亦是為了在網路上傳送多媒體資料所產生的一個協定，較有名的應用程式為：Microsoft Net meeting
Overview H.323 terminal H. 323 encoding Gatekeeper Gateway Audio codecs Video codecs

42 Overview (1) 目標：可以達到即時的通訊 由ITU所建議使用 應用的範圍 單獨的機器（例如：網路電話） 在PC上的應用
點對點或是多點的視訊會議

43 Overview (2) 在H.323裡面定義了 端點的機器如何撥接一個呼叫（call） 端點的機器如何交換共同的audio/video解碼
端點的機器如何和他的gatekeeper溝通 網路電話和一般PSTN/ISDN的電話如何溝通

44 Overview (3) Telephone calls Video calls Conferences Whiteboards

45 Overview (4) H.323 SS7, Inband

46 H.323的端點機器必須支援 G.711 ITU 所制訂的語音壓縮標準 RTP 將多媒體加封的協定 H.245 在端點機器之間用來傳送控制訊號的“Out-of-band” 控制協定 Q.931 用來建立撥接的signaling協定 RAS (Registration/Admission/Status) 通道協定 – 用來和gatekeeper溝通的協定

47 H.323 Terminal

48 H.323的編碼（encoding） Audio Video
H.323的終端機器必須支援G.711，用來傳送壓縮的與語音，voice rate = 56/64 kbps Optional：G.722, G.728, G.729 Video 對於H.323的終端機器是optional 終端機器必須支援QCIF H.261 (176x144 像素) H.261 option：CIF, 4CIF, 16CIF H.261是用來和使用多重64kbps的頻道溝通

49 Generating audio packet stream in H.323
Source Encoding: e.g., G.711 or G.723.1 RTP packet encapsulation UDP socket Internet or Gatekeeper

50 H.245 Control Channel 一個H.323串流可能會包含多個不同種類的多媒體資料
每一個H.323 session都會有一個H.245的控制頻道 H.245控制頻道是一個reliable（TCP）的控制頻道 主要任務 開啟或關閉一個多媒體頻道 相容性的交換 在開始傳送資料前，會先交換編碼的演算法

51 Information flows

52 Gatekeeper（1） 在這裡gatekeeper是optional，提供
位址轉換成IP位址 頻寬的管理 因為billing的方便，H.323的calls可能會由gatekeeper管理 RAS是用來terminal-gatekeeper之間溝通的協定 H.323 terminals Gatekeeper Router Internet LAN = “Zone” RAS

53 Gatekeeper（2） H.323的設備必須要跟他那個區域的gatekeeper做註冊的動作
如果gatekeeper存在的話，每一個終端設備要撥接一個call的前要先經過gatekeeper同意 如果獲得同意，終端設備會傳送 給gatekeeper，裡面包含了要轉換成IP位址的資訊

54 Gateway IP區域和PSTN（or ISDN）的橋樑 終端設備使用H.245和Q.931和gateway溝通 PSTN
H.323 terminals Router Internet RAS Gatekeeper LAN = “Zone” IP區域和PSTN（or ISDN）的橋樑 終端設備使用H.245和Q.931和gateway溝通

55 Audio codecs MOS (Mean Opinion Score)

56 Video codecs H.261 (p x 64 kbit/s) H.263 (< 64 kbit/s) ISDN上傳送Video
Resolutions : QCIF, CIF H.263 (< 64 kbit/s) 低速率的溝通 Resolutions: SQCIF, QCIF, CIF,4CIF, 16CIF (128 x 96) (176 x 144) (352 x 288) (704 x 576) (1408 x 1152) SQCIF QCIF CIF 4CIF 16CIF

57 QoS in IP networks 現在的網路並沒有提供QoS的機制，所以IETF有些團體就在制訂一些可以提供QoS機制的protocol
目前正在制訂的有RSVP，Differentiated Services和Integrated Services 例子：

58 QoS的原理（1） Principle 1 在router轉送封包時分成不同的類別的封包 制訂新的分配不同類別的封包政策

59 QoS的原理（2） Principle 2 每一個不同的類別會受到不同的保護，以避免被其他的類別影響
因為如此，所以我們需要policy management來確保每一個頻寬的需求，通常我們都在終端執行

60 QoS的原理（3） Principle 3 當我們達到類別互相不干擾後，我們必須讓我們的頻寬使用效率達到最好

61 QoS的原理（4） Principle 4 基於link的容量限制下，我們需要Call Admission Control來管理一個call我們是不是要接受，如果容量滿了，我們必須block new call

62 QoS的原理—總整理 Packet classification Isolation：scheduling and policing
High resource utilization Call admission control

63 QoS Approaches

64 Scheduling And Policing Mechanisms
Scheduling（排程）：依照policies選擇下一個被傳送的封包 Policy FIFO：最簡單的機制，先進入暫存區的封包先傳送

65 Policing Mechanisms（2）
Priority Queuing：不同的priority有不同的暫存區，我們可以依照來源IP、目的地IP、TCP埠號…等來區分priority 傳送封包時永遠從最高優先權的先傳直到最高優先權的暫存區空了 可分為可中斷（preemptive）和不可中斷（non-preemptive）兩種

66 Policing Mechanisms（3）
Round Robin：用掃瞄的方式來傳送資料，每一次都從最高優先權的暫存區開始，一直掃到最低的，再由最高的開始

67 Policing Mechanisms（4）
Weighted Fair Queuing：為更一般化的Round Robin，基本上一樣是會由最高掃到最低的，但是會依照暫存區理的資料不同而停留的時間不同

68 Policing Mechanisms 三種標準 Average Rate Peak Rate Burst Size

69 Policing Mechanisms（2）
Token Bucket是我們最常用來控制input的burst size和average rate

70 Policing Mechanisms（3）
Bucket 可以擁有b個tokens：token 會以r token/sec產生，直到整個bucket塞滿tokens. 在時間 t 後，所傳送的封包會小於等於(r t+ b) Token bucket和WFQ結合可以提供delay的upper bound

71 Call Admission Session必須先定義他所需要的QoS需求，並且指出所要透過網路傳送的資料特徵
R-spec：定義被要求的QoS T-spec：定義所傳送資料的特徵 所以我們需要一個signaling協定來攜帶這一些訊息讓router之到來幫我們保留所需要的資源，RSVP是現在所常用的一個保留資源的signaling協定

72 Call Admission（2） Call Admission：router必須基於這一些call的T-spec、R-spec和現在所擁有的資源來決定要不要接受這一個call

73 Integrated Services RFC1633 這是為了在網路上提供QoS所發整展的一套機制
針對每一個應用程式的session做QoS 基於資源保留，所以router必須維護一個狀態訊息（virtual circuit state），並且需要記錄已經被保留資源和新的call所需要的資源

74 Integrated Services : Classes
Controlled Load：這是一個提供接近於一個可接受的QoS的class，應用於提供下載的router上 RFC2211 Providing the client data flow with quality of service closely approximation the QoS that same flow would receive from an unloaded network element Using capacity (admission) control to assure that this service is received even when the network element is overloaded. Applications: Adaptive real-time applications These applications perform quite well when the network is unloaded, but rapidly degrade in performance as the network becomes more loaded Controlled-load service simply prioritizes the packets in the flow, ensuring that they do not wait too long in router queues as they cross the network.

75 Integrated Services : Classes（2）
Guaranteed QoS：這是提供強健的QoS保證的class，用於對於delay較敏感的hard-real time應用程式 RFC2212 Providing firm bounds on the queueing delays that a packet will experience in a router. Applications: Hard real-time applications Audio and video playback applications that are intolerant of late-arriving packets

76 Introduction of RSVP Resource ReSerVation Protocol.
Allows applications running in hosts to reserve resources in the Internet for their data flows. Used by the routers to forward bandwidth reservation requests. RSVP software must be present in the receivers, sender, and routers.

77 RSVP in Hosts and Routers

78 Introduction of RSVP （2）
Two principle characteristics of RSVP It provides reservations for bandwidth in multicast trees(unicast is handled as a special case). It is receiver-oriented. RSVP reserves resources for only one direction data streams. RSVP is not a routing protocol It does not determine the links in which the reservations are to be made. An RSVP daemon consults the local routing databases to obtain routes.

79 Introduction of RSVP （3）
RSVP depends on an underlying routing protocol(unicast or multicast) to determine the routes for the flows RSVP is sometimes referred to as a signaling protocol that allows hosts to establish and tear-down reservations for data flows

80 RSVP: multicast- and receiver-oriented

81 RSVP Operation Example

82 A Few Simple Example

83 Differentiated Services（DS）
因為在Integrated Services上會有一些問題，所以又另外在衍生的另一個提供QoS的機制 Scalability：因為在Integrated Services需要維護記載一些state，所以當在高速的網路中時事很難去維護這麼多traffic flow所造成的state Flexible Service Models：Intserv 只有提供兩種 classes，我們需要更有彈性的區分 Simpler signaling：因為RSVP過於繁雜，所以我們需要一個較簡單signaling協定

84 Differentiated Services（2）
方法： 在核心網路的router中只會有一些簡單的功能（相較於邊端router） 不需要定義服務的類別

85 DiffServ Architecture

86 DiffServ Architecture（2）
DS domain: A DS domain is a set of DS nodes that are with the same service provisioning policy and set of PHB groups implemented on each node. DS region: A DS region is a set of one or more continuous DS domains. DS boundary nodes: DS boundary nodes interconnect the DS domain to other DS or non-DS-capable domains. DS Interior nodes: connect to other DS interior or boundary nodes within the same domain. DS ingress nodes: responsible for ensuring the traffic entering the DS domain conforms to any TCA between it and other domain. DS egress nodes: Perform traffic conditioning functions on traffic forwarded to a directly connected peering domain, depending on the details of the TCA between the two domains.

87 Edge Functions 在一個有DS功能的主機或是router都有
Classification：端點的機器會依照分類的規則將封包加上標記（mark） Traffic Conditioning：端點機器有可能會延遲後再轉送或是丟棄封包

88 Core Functions Forwarding：根據“Per-Hop-Behavior”（PHB）特定的封包類別來轉送封包
好處：router不需要維護或記載任何state

89 Classification and Conditioning
在現在的IP header（IPv4）裡的TOS欄位尚未被用到，在IPv6定義為traffic class 在這裡DS就是利用TOS一個byte來做classification Differentiated Service Code Point (DSCP)：6 bits 2 bits are currently unused

90 Classification and Conditioning（2）
Router會依照使用者所定義的user profile（rate和burst size）來對traffic profile做控制

91 DiffServ Components Classifier. Traffic Conditioner.
Service Level Agreement (SLA). Traffic Conditioning Agreement (TCA).

92 Classifier Behavior Aggregate(BA) classifier:
BA classifier uses only the DiffServ codepoint(DSCP) in a packet’s IP header to determine the logical output stream to which the packet should be directed. Multi-Field(MF) classifier: MF classifier classifies packets based on one or more fields in the packet header. A common type of MF classifier is a 5-tuple classifier. (src addr, dest addr, src port, dest port, IP protocol)

93 Traffic conditioner Meter:
Metering is the function of monitoring the arrival times of packets on a traffic stream and determining the level of conformance of each packet to a profile. Types of meters: Average rate meter. Exponential weighted moving average meters. Token bucket meters.

94 Traffic conditioner (cont.)
Marker: Marker set the DSCP in a packet header. Marker may act on unmarked packets or may remark previously marked packets. Shaper: Shaper are used to shape traffic to a certain temporal profile. Dropper: Droppers simply discard packets with no parameters.

95 SLA Service Level Agreement(SLA): Static SLA:
A service contract between a customer and a service provider that specifies the forwarding service a customer should receive. A SLA may also specify traffic profiles and actions to traffic streams which are in- or out-of-profile. Static SLA: norm at the present time. first instantiated at the agreed upon service start date and may periodically be renegotiated.

96 SLA (cont.) Dynamic SLA: Challenging problems for Dynamic SLA :
may change as the traffic load fluctuates. dynamic SLAs change without human intervention and thus require an automated agent and protocol. Challenging problems for Dynamic SLA : Network providers have to balance frequently changing loads on different routers within the provider network. Customer equipments will have to adapt to dynamic SLAs. End user applications have to adapt their behavior during a session.

97 TCA Traffic Conditioning Agreement(TCA) specifies detailed service parameters for each service level: Traffic profiles. Metering rules. Marking rules. Discarding rules. Shaping rules.

98 Traffic Profiles A traffic profile specifies the temporal properties of a traffic stream selected by a classifier. In-profile packets may be allowed to enter the DS domain without further conditioning. Out-of-profile packets may be queued until they are in-profile(shaped), discarded(policed), marked with a new codepoint(remarked), or forwarded unchanged while triggering some accounting procedure.

99 Bandwidth Broker act the policy and call admission control manager in each DS domain. keep track of current allocation of marked traffic. interpret new requests to mark traffic according to policies and current allocation. parcel out marked traffic allocations and set up edge routers.

100 Bandwidth Broker Architecture
adjacent BB adjacent BB Inter-Domain Interface Policy Manager Interface application server User/App Interface user/ host Network Management Interface network operator Data Repository Routing Information Intra-Domain Interface edge routers edge routers

101 DS Code point

102 Per-Hop Behavior Per-hop Behavior(PHB)
is a description of the externally observable forwarding behavior of a DS node applied to a particular DS behavior aggregate. PHBs may be specified in terms of their resource priority relative to other PHBs, or their relative observable traffic characteristics. PHBs are implemented in nodes by buffer management and packet scheduling mechanisms.

103 Assured Forwarding PHB Group
Reference: IETF RFC 2597. Description: AF PHB group is a means for a provider DS domain to offer different levels of forwarding assurances for IP packets received from a customer DS domain. Four independent forwarding AF classes and with each AF class, three levels of drop precedence are defined. Packets of class x have smaller forwarding time(delay time) than class y, if x>y.

104 Assured Forwarding PHB Group (cont.)
Description: A packet with drop precedence p must be forwarded with higher probability than a packet with drop precedence q, if p<q. An IP packet that belongs to an AF class i and has drop precedence j within is marked with the AFij. A DS node must allocate a configurable, minimum amount of forwarding resources to each implemented AF class. An AF class may also be configurable to receive more forwarding resources than minimum when excess resources are available either from other AF classes or from other PHB groups.

105 Assured Forwarding PHB Group (cont.)
AF PHB recommend codepoint: AF1 AF2 AF3 AF4 010000 010010 010100 011000 100000 101000 011010 011100 100100 100010 101100 101010 low mid high

106 Expedited Forwarding PHB
Reference: IETF RFC 2598. Description: The EF PHB can be used to build a low loss, low latency, low jitter, assured bandwidth, end-to-end service through DS domains. The departure rate of the aggregate’s packets from DS nodes must equal or exceed a configurable rate. The EF traffic receives this rate independent of the intensity of any other traffic attempting to transit the node.

107 Expedited Forwarding PHB (cont.)
DSCP: Diffserv codepoint CU: currently unused EF PHB recommend codepoint: 101110