Announcement

**luancb** · 04-04-2009, 11:03 AM

3.1.2: Dịch vụ phân biệt DiffServ

Hình 3.9: Mô hình mạng DiffServ

- Cấu trúc của mô hình DiffServ bao gồm nhiều lớp dịch vụ và mỗi lớp sẽ được cung cấp một lượng tài nguyên xác định.
- Ví dụ trong mạng bao gồm hai lớp dịch vụ: “nỗ lực tối đa” và “độ ưu tiên” (premium). Điều này có nghĩa là những gói dữ liệu thuộc lớp ưu tiên sẽ được cung cấp chất lượng dịch vụ tốt hơn: dữ liệu được đảm bảo, ít mất hơn và có độ trễ thấp hơn.
- Điểm khác nhau giữa mô hình DiffServ và IntServ: IntServ dùng giao thức báo hiệu để thông báo cho các nút mạng chất lượng dịch vụ mà luồng yêu cầu. Với mô hình DiffServ,

trên mỗi gói dữ liệu sẽ chứa thông tin xác định lớp dịch vụ. Thông tin này được gọi là điểm mã dịch vụ phân biệt DSCP (Differentiated Service Code Point) của tiêu đề IP, tiền thân là vùng ToS (Type of Service). Như vậy trên lý thuyết chúng ta có tất cả 64 lớp dịch vụ khác nhau nhưng trong thực tế số lượng lớp dịch vụ ít hơn nhiều.
- Câu hỏi đặt ra ở đây là các bộ định tuyến sẽ làm gì khi nhận gói dữ liệu với giá trị DSCP nào đó?
- Giá trị DSCP cho biết yêu cầu chất lượng dịch vụ mà gói dữ liệu yêu cầu mạng cung cấp hay nói cách khác DSCP xác định một hành vi hop PHB (Perhop behavior). Ngoài những giá trị PHB chuẩn, trong nội bộ một mạng có thể định nghĩa riêng những giá trị PHB. Sau đây là một số giá trị PHB chuẩn:
• Giá trị mặc định (Default): tương đương với yêu cầu nỗ lực tối đa.
• Chuyển tiếp nhanh EF (Expedited Forwarding): gói dữ liệu có giá trị này sẽ có thời gian trễ nhỏ nhất và độ mất gói thấp nhất.
• Chuyển tiếp bảo đảm AF (Assured Forwading): mỗi PHB mang một giá trị AFxy. Giá trị x cho phép xác định hàng đợi dành cho gói, giá trị y xác định mức độ ưu tiên hay nói cách khác là khả năng mất gói khi xảy ra hiện tượng nghẽn mạch hoặc tranh chấp. Như vậy, nếu các gói được đánh dấu AF11, AF12, AF13 thì chúng được xếp chung vào một hàng đợi nhưng mức ưu tiên của các gói AF13 thấp hơn và xác suất mất cao hơn. Riêng các gói AF2y có hàng đợi khác gói AF1y. Số lượng AF PHB là 12, trong đó x có 4 giá trị và y có 3 giá trị. Và điều quan trọng cần phải nhắc đến là các gói AFx1, AFx2, AFx3 sẽ được đưa vào cùng một hàng đợi để không bị mất thứ tự.
-Mỗi thiết bị định tuyến sẽ lưu giữ một bảng ánh xạ giá trị DSCP của gói với giá trị PHB, từ đó xác định phương thức xử lý gói.

Hình 3.10: Mô hình DiffServ tại biên và mạng lõi

3.1.3 Sự khác nhau giữa IntServ và DiffServ
Trong một mạng sử dụng QoS, chúng ta có thể không cần dùng đến IntServ hay DiffServ mà mạng vẫn chạy bình thường, tuy nhiên nếu có ứng dụng DiffServ hay IntServ vào thì sẽ cho kết qua tốt hơn nhiều, và có thể đảm bảo chất lượng dịch vụ cao hơn.
DiffServ ra đời để khắc phục các khuyết điểm của IntServ, giữa chúng có những sự khác nhau:
DiffServ IntServ
Không dùng bất kì giao thức báo hiệu nào để dành trước băng thông mạng, do vậy tiết kiệm được băng thông mạng. Dùng giao thức báo hiệu RSVP để dành trước băng thông mạng, do đó sẽ tốn tài nguyên mạng vô ích.
Có thể sử dụng cho mạng lớn và cả mạng nhỏ với số lưu lượng rất lớn Chỉ có thể sử dụng cho mạng cỡ nhỏ với số lượng lưu lượng nhỏ
Ít tốn tài nguyên mạng Tốn nhiều tài nguyên mạng
Xét ưu tiên gói trên từng chặn Khởi tạo một kênh truyền trước khi truyền
Khả năng mở rộng mạng cao và phục vụ đa dịch vụ Khả năng mở rộng mạng thấp và phục cụ ít dịch cụ.
Hình 3.11: Sự khác nhau giữa DiffServ và IntServ

3.2 PHÂN LOẠI VÀ ĐÁNH DẤU
QoS là khả năng cung cấp các mức xử lý khác nhau hướng đến các lớp lưu lượng riêng. Trước khi các ứng dụng hay các kỹ thuật QoS được áp dụng, lưu lượng phải được nhận biết và sắp xếp vào trong các lớp khác nhau. Thiết bị mạng sử dụng sự phân loại để nhận biết lưu lượng theo các lớp riêng biệt. Sau khi lưu lượng mạng được sắp xếp, việc đánh dấu được thực hiện bằng cách gắn thẻ cho các gói riêng biệt để các thiết bị mạng khác có thể thực hiện các chức năng QoS cho các gói đó khi chúng di chuyển thông qua mạng.
1. Phân loại:
- Phân loại đươc thực hiện để nhận dạng lưu lượng và phân chia lưu lương thành các lớp khác nhau. Để phân loại gói, ta dùng bộ mô tả lưu lượng để phân chia các gói trong phạm vi các nhóm riêng biệt để định nghĩa các gói đó. Một số bộ mô tả đặc trưng dùng để phân loại gói bao gồm: bộ giao tiếp ngõ vào, độ ưu tiên IP (IP Precedence), DSCP, địa chỉ nguồn hay địa chỉ đích và các ứng dụng. Sau khi gói đã được định danh, chúng có khả năng được tiến hành các chức năng QoS trên mạng.
- Với việc sử dụng phân loại gói, nhà quản trị mạng có thể phân vùng lưu lượng mạng thành nhiều mức ưu tiên hay nhiều lớp dịch vụ. Khi bộ đặc tả lưu lượng được sử dụng để phân loại, lưu lượng nguồn đồng ý tham gia để thoả thuận các giới hạn và mạng sẽ thực hiện các giới

hạn đó với việc đảm bảo vế chất lượng dịch vụ. Các kỹ thuật chất lượng dịch vụ khác như giám sát lưu lượng, nắn dạng lưu lượng và kỹ thuật hàng đợi sử dụng bộ mô tả lưu lượng để đảm bảo giữ đúng thoả thuận. Việc phân loại nên được đặt ở biên mạng.
2. Đánh dấu:
- Hoạt động đánh dấu cho phép các thiết bị mạng phân loại gói hay khung (frame) dựa vào bộ mô tả lưu lượng đặc trưng. Một số bộ mô tả lưu lượng được sử dụng để đánh dấu gói như: lớp dịch vụ (CoS), DSCP, độ ưu tiên IP, nhóm QoS, chuyển mạch nhãn đa giao thức (MPLS). Việc đánh dấu được sử dụng để thiết lập thông tin trong tiêu đề gói lớp 2 hay lớp 3.
- Việc đánh dấu gói hay khung cùng với việc phân loại cho phép thiết bị mạng dễ dàng phân biệt các gói hay khung đã được đánh dấu. Đánh dấu là yếu tố hữu dụng vì nó cho phép thiết bị mạng dễ dàng nhận dạng các gói hay khung theo các lớp đặc trưng. Khi đó kỹ thuật QoS có thể ứng dụng tương thích để đảm bảo sự đúng đắn với các chính sách quản trị QoS.
3.2.1 Phân loại (classification)
Phân loại là việc các gói tin sẽ được đưa vào những hàng đợi khác nhau mỗi khi tới router, IOS của router bằng cách này hay cách khác phải phân biệt được các gói tin khác nhau với độ ưu tiên khác nhau để đưa vào các hàng đợi thích hợp, nó phải biết được gói tin nào có RTP (Real time protocol) headers để shape (định hướng) cho gói tin nhằm cung cấp đủ băng thông cho lưu lượng là voice. IOS phải phân biệt được đâu là VoIP và đâu là data, để làm điều này thì nó phải sử dụng Phân Loại (Classification).
Để có thể phân loại được gói tin, thông thường phải kiểm tra một số trường trong headers, sau khi phân loại, một QoS tool sẽ đưa gói tin vào hàng đợi thích hợp, hầu hết sự phân loại nhằm phân biệt đâu là gói tin VoIP và đâu là gói tin không phải VoIP.

Hình 3.12: Sự phân loại gói tin

Trong hình trên ta thấy: Việc phân loại được thực hiện ở tất cả các router trên links kết nối, ở router R3 sau khi phân loại sẽ đưa vào hàng đợi Queuing và sau đó là shaping (định hướng). Q1, Q2, Q3, Q4 lần lượt là các mức ưa tiên, ở đây ta thấy voice có mức ưa tiên cao nhất. ở bảng thứ 2 là shaping police ta sẽ tìm hiểu phần sau.
Ta có thể dùng một số tools để phân loại, ví dụ như dùng ACLs: Với ACL 101 để cho phép gói tin loại nào đó sẽ được xếp vào hàng đợi thứ 1, với ACL 102 để cho phép goi tin loại khác sẽ được xếp vào hàng đợi thứ 2, …
Sau khi đã được phân loại, các gói tin sẽ được đánh dấu (marking), việc đánh dấu sẽ đánh dấu vào một trường trong IP header, sau khi gói tin đã được đánh dấu, các tools còn lại trong QoS sẽ sử dụng “dấu” để tiến hành phân loại ở các chặng tiếp theo. Hai trường dùng để đánh dấu là IP Precedence và Differentiated Service Code Point (DSCP), chúng ta sẽ tìm hiểu kĩ chúng trong Chương 4.

Một số Tools cho phân loại và đánh dấu:

Hình 3.12: Tool cho phân loại và đánh dấu

Một ví dụ về phân loại:
Ở đây ta dùng ACLs để phân loại gói tin, ta sẽ phân dữ liệu thành 3 loại là:Voice (ACL 101), HTTP (ACL 102), FTP (ACL 104), SMTP (ACL 105), và Besteffort (ACL 103).
PE1(config)#access-list 101 permit udp any any range 16384 32768 ///ACL cho Voice
PE1(config)#access-list 102 permit tcp any any eq www ///ACL cho HTTP (www)
PE1(config)#access-list 103 permit ip any any ///ACL cho Best-effort
PE1(config)#access-list 104 permit tcp any any eq ftp ///ACL cho ftp
PE1(config)#access-list 105 permit tcp any any eq smtp ///ACL cho smtp
3.2.2 Đánh dấu (Marking)
Đánh dấu là một kĩ thuật dùng để tạo ra sự phân biệt giữa các gói tin của các loại dữ liệu khác nhau trong khi thực hiện QoS, việc đánh dấu sẽ thực hiện trên các một số trường có trong gói tin như IP precedent, DSCP, EXP, QoS group, QoS discard….
Việc đánh dấu thường được thực hiện sau khi gói tin đã được phân loại, Sau khi phân loại gói tin ta sẽ đánh dấu vào gói tin đó một giá trị, có thể đó là giá trị IP precedent, DSCP hay EXP…Các giá trị đã được đánh dấu sẽ được dùng để phân loại gói tin ở chặn tiếp theo và thực hiện QoS.
Ví dụ dưới đây sẽ đánh dấu gói tin Voice với giá trị EXP là 5, HTTP là 3, FTP và SMTP với EXP là 2 và Best Effort là 0:
PE1(config-pmap)#class Voice-dscp
PE1(config-pmap-c)#set mpls experimental topmost 5
PE1(config-pmap-c)#exit
****
PE1(config-pmap)#class HTTP-dscp
PE1(config-pmap-c)#set mpls experimental topmost 3
PE1(config-pmap-c)#exit
****
PE1(config-pmap)#class smtp-dscp
PE1(config-pmap-c)#set mpls experimental topmost 2
PE1(config-pmap-c)#exit
****
PE1(config-pmap)#class ftp-dscp
PE1(config-pmap-c)#set mpls experimental topmost 2
PE1(config-pmap-c)#exit
****
PE1(config-pmap)#class best-effort-dscp
PE1(config-pmap-c)#set mpls experimental topmost 0
PE1(config-pmap-c)#exit
Việc đánh dấu thường xảy ra tại ngõ vào của interface, tại đây gói tin sẽ được thu nhận và thực hiện đánh dấu lại (remark) nếu cần thiết, dấu vừa đánh sẽ tồn tại trong các hàng đợi ngõ ra của router này và trên đường truyền tới đích tiếp theo.
Thực chất của việc đánh dấu là ta sẽ set các giá trị trong gói tin lên các giá trị thích hợp mà ta cho là hợp lí.

Một số trường dùng cho đánh dấu:

Hình 3.13: Trường để đánh dấu

3.3 CÁC KĨ THUẬT HÀNG ĐỢI (CLASSIFICATION & QUEUING)
Vì tốc độ sử lý các gói tin của router là chậm hơn nhiều so với số lượng gói tin đến và cần truyền đi, vì vậy các gói tin cần phải xếp hàng và đợi trong một hàng dài nếu như không muốn bị drop, do đó kĩ thuật hàng đợi cần được áp dụng cho các router. Thường thì hàng đợi chỉ xảy ra ở ngõ ra của router khi đó ta gọi là hàng đợi ngõ ra (output
queuing), nhưng đôi khi hàng đợi cũng xảy ra ở ngõ vào ta gọi là hàng đợi ngõ vào (input queuing).

Hình 3.14: Hàng đợi trong router

Hình trên là một ví dụ về hàng đợi, ngõ vào với 4 gói tin kích thước 1500 byte mỗi gói, ở đây ta có hai hàng đợi :hàng thứ 1 đang có 3 gói tin đang chờ và băng thông của hàng này là 25% tổng băng thông, hàng thứ 2 chỉ có 1 gói tin đang chờ với băng thông là 75%, như vậy gói tin nào sẽ được gởi trước? Thật ra gói tin nào được gởi trước là tùy thuộc vào mức độ ưu tiên của hàng đợi đó và hàng đợi đó như thế nào so với các hàng đợi khác.

Hình 3.15: Các kĩ thuật hàng đợi và so sánh giữa chúng

3.3.1 First In-First Out Queuing
- Hàng đợi FIFO không có sự phân loại vì tất cả các gói đều thuộc về cùng một lớp. Một bộ định tuyến hay bộ chuyển mạch cần các hàng đợi xuất để giữ các gói trong khi chờ bộ giao tiếp sẵn sàng gửi gói. Trong khi các công cụ hàng đợi khác thể hiện các tính năng khác, như sắp xếp trật tự các gói, hàng đợi FIFO chỉ cung cấp một ý nghĩa giữ các gói trong khi chúng chờ để rời khỏi một cổng giao tiếp (interface). Hàng đợi FIFO sử dụng một hàng đợi đơn cho bộ giao tiếp. Vì chỉ có một hàng đợi nên không cần phân lớp để quyết định khi gói đi vào. Và cũng không cần lập lịch ban đầu để cho hàng đợi lấy gói tiếp theo. Chỉ quan tâm đến cách cấu hình chiều dài hàng đợi FIFO tránh tác động đến độ trễ và mất gói.
- Hàng đợi FIFO sử dụng kỹ thuật hủy gói cuối hàng đợi để quyết định khi nào bỏ gói hay cho gói vào hàng đợi. Nếu cấu hình một hàng đợi dài hơn, nhiều gói có thể đặt trong hàng đợi, nghĩa là hàng đợi ít khả năng đầy. Nếu không gian hàng đơi còn trống nhiều thì gói ít bị mất. Tuy vậy, với một hàng đợi dài, độ trễ và độ biến động trễ của gói tăng. Với hàng đợi ngắn, độ trì hoãn ít xuất hiện hơn, nhưng hàng đợi FIFO đơn sẽ đầy nhanh chóng, lúc này các gói mới sẽ bị hủy bỏ.

Hình 3.16: Hàng đợi FIFO

Lập lịch hàng đợi FIFO:
- Sau khi gói đi vào hàng đợi thì bộ định tuyến sẽ sử dụng thuật toán lập lịch để duy trì công việc. Lập lịch FIFO là thuật toán lập lịch truyền thống được sử dụng trong Internet, đây là thuật toán lập lịch đơn giản nhất. Trong thuật toán này bộ lập lịch truyền các gói theo thứ tự đến và hủy các gói khi hàng đợi đầy. Tuy nhiên, bộ lập lịch gói không có sự

phân biệt giữa các người sử dụng. Vì vậy nó không thể phân phối cho một số user độ trễ trung bình thấp hơn các người dùng khác. Mọi người dùng trong cùng lớp dịch vụ chịu cùng một độ trễ biến thiên (jitter delay). Ngoài ra, độ biến động trễ có xu hướng tăng lên khi số chặng tăng lên vì độ trễ hàng đợi của gói ở các chặng khác nhau không tương quan với nhau.
- Với FIFO, độ trễ trung bình của một người sử dụng có thể tăng lên nếu tổng tốc độ đến của tất cả người sử dụng tăng lên.
- Tuy nhiên việc sử dụng kỹ thuật hàng đợi FIFO có các nhược điểm:
• FIFO không hoàn toàn tin cậy khi một luồng không mong muốn tranh giành với các luồng có độ ưu tiên thấp. Các luồng không mong muốn gửi một số lượng lớn các gói (đa số các gói đó bị huỷ bỏ). Trong khi đó, các luồng với độ ưu tiên thấp gửi một số lượng gói xác định và hầu hết chúng bị hủy bởi vì hàng đợi lúc nào cũng đầy do các luồng không mong muốn đã chiếm hết không gian hàng đợi.
• Sự bùng nổ cao hay thấp gây ra tình trạng đầy hàng đợi FIFO. Các gói đi vào một hàng đợi đầy phải chờ một thời gian dài trước khi chúng được truyền. Nhưng ở thời điểm khác, hàng đợi có thể trống và các gói trong cùng một luồng không bị trì hoãn.
- Các ưu điểm của kỹ thuật hàng đợi FIFO
• Đây là kỹ thuật đơn giản và nhanh.
• Nó được hỗ trợ trên tất cả các nền tảng.
• Hàng đợi FIFO được hỗ trợ trong tất cả các phiên bản của Cisco IOS.
Để cấu hình cho hàng đợi FIFO ta phải unable tất cả các kĩ thuật hàng đợi khác có trong interface đó. Mặc định thì WFQ (Weighted Fair Queuing) sẽ được áp dụng cho các interface và nó chạy ở tốc độ E1 (khoảng 2M).
- Để disable WFQ ta dùng câu lệnh “no fair-queue”, Khi đã disable tất cả các kĩ thuật hàng đợi có trong interface thì FIFO sẽ mặc nhiên được sử dụng.
- Để chọn chiều dài cho hàng đợi ta dùng câu lệnh “hold-queue x out”.

Ví dụ:
R3(config)#int s 0/0
R3(config-if)#no fair-queue // disable WFQ ;
R3(config-if)#^Z
R3#sh int s 0/0
Serial0/0 is up, line protocol is up
Hardware is PowerQUICC Serial
Description: connected to FRS port S0. Single PVC to R1.
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY, loopback not set
Keepalive set (10 sec)

LMI enq sent 80, LMI stat recvd 73, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
Broadcast queue 0/64, broadcasts sent/dropped 171/2, interface broadcasts 155
Last input 00:00:02, output 00:00:03, output hang never
Last clearing of "show interface" counters 00:13:48
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo //hàng đợi FIFO được dùng
Output queue :0/40 (size/max) //Kích cỡ hàng đợi ngõ ra là 40 gói tin.
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
235 packets input, 14654 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
2 input errors, 0 CRC, 2 frame, 0 overrun, 0 ignored, 0 abort
264 packets output, 15881 bytes, 0 underruns
0 output errors, 0 collisions, 6 interface resets
0 output buffer failures, 0 output buffers swapped out
10 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up

+Thay đổi chiều dài hàng đợi ngõ ra thành 50 gói tin:
R3(config)#int s 0/0
R3(config-if)#hold-queue 50 out
R3(config-if)#^Z
!
R3#sh int s 0/0
Serial0/0 is up, line protocol is up
Hardware is PowerQUICC Serial
! Lines omitted for brevity
Queueing strategy: fifo
Output queue :0/50 (size/max) //chiều dài hàng đợi là 50 :
! Line omitted for brevity

3.3.2 Priority Queuing

Hình 3.17: Cách lấy gói tin của hàng đợi PQ

- Tính năng đặc biệt của PQ là ở bộ lập lịch. PQ lập lịch lưu lượng đảm bảo hàng đợi ưu tiên luôn được phục vụ trước. Với 4 mức ưu tiên: cao, trung bình, bình thường, và thấp. Nếu hàng đợi ưu tiên cao luôn có một gói đang chờ, bộ lập lịch luôn luôn lấy các gói trong hàng đợi ưu tiên cao. Nếu hàng đợi ưu tiên cao không có gói nào đang chờ nhưng có trong hàng đơi ưu tiên trung bình, một gói trong hàng đợi này sẽ được lấy và tiến trình cứ như thế tiếp tục.
- Bộ lập lịch PQ có một số thuận lợi và hạn chế. Các gói trong hàng đợi ưu tiên cao có thể đạt 100% băng thông liên kết, với độ trì hoãn nhỏ và độ biến động trễ nhỏ. Thật ra, khi nghẽn mạch, các gói trong hàng đợi ưu tiên thấp tốn nhiều thời gian phục vụ. Khi liên kết tắc nghẽn, các ứng dụng người dùng có thể ngừng làm việc nếu các gói đặt trong hàng đợi ưu tiên thấp.
- PQ phân lớp các gói dựa trên nội dung của các tiêu đề. Nó sử dụng tối đa 4 hàng đợi. Chỉ áp dụng chính sách hủy gói cuối hàng đợi (tail drop), mặt khác sau khi phân lớp các gói, nếu

hàng đợi tương ứng đầy, các gói bị bỏ. Mặt khác, chiều dài mỗi hàng đợi là nguyên nhân ảnh hưởng đến độ trễ và mất gói. Thật ra, PQ có thể thiết lập chiều dài hàng đợi trở về giá trị 0, có nghĩa là chiều dài hàng đợi “không giới hạn”. (“không giới hạn” có nghĩ là khi bộ định tuyến ra ngoài vùng nhớ, các gói không thể lập lịch, tuy nhiên chúng ta gặp vấn đề rắc rối hơn việc lập lịch cho gói nếu bộ định tuyến ngoài vùng nhớ.)

Hình 3.18: Tiến trình gởi gói tin của PQ

1. PQ có thể phân lớp các gói sử dụng danh sách điều khiển truy cập ACL với giao thức lớp 3. PQ cũng có thể so trùng trực tiếp không cần sử dụng ACL, đầu vào, chiều dài gói và cổng TCP và UDP.
2. Hủy bỏ gói cuối hàng đợi là chính sách bỏ gói mặc định.
3. Số hàng đợi cực đại là 4.
4. Chiều dài hàng đợi cực đại có thể là 0, nghĩa là hàng đợi có chiều dài “không xác định” theo lý thuyết. Mặc định là 20, 40, 60 và 80 tướng ứng với các hàng đợi ưu tiên cao,trung bình, bình thường và thấp.
5. Bên trong một hàng đợi, PQ sử dụng hảng đợi FIFO.
6. Khi lập lịch các hàng đợi, PQ luôn phục vụ các hàng đợi ưu tiên cao trước.

- Khi ngõ xuất không tắc nghẽn (nói một cách khác TX không đầy), các gói mới đặt vào TX một cách trực tiếp. Khi TX đầy, PQ thể hiện việc lập lịch. Khi tất cả các hàng đợi PQ truyền hết các gói (TX không đầy), tắc nghẽn dịu đi. Các gói mới đến lại vào TX, cho đến khi nó đầy trở lại, nó sẽ khởi động tiến trình hàng đợi với PQ.
- PQ làm việc tốt trong các chính sách QoS cần xử lý một loại lưu lượng với khả năng phục vụ tốt nhất. Tuy nhiên, dịch vụ PQ với các hàng đợi thấp giảm nhanh chóng, làm cho PQ không thiết thực cho hầu hết các ứng dụng hiện nay. Chẳng hạn, việc chạy một kết nối FTP, một trình duyệt web, một cuộc gọi NetMeeting, và 2 cuộc gọi VoIP khi xuất, các kết nối TCP với lưu lượng HTTP và FTP thường xuyên vượt quá thời gian cho phép.
Bảng tóm tắc tính năng PQ:

3.3.3 Custom Queuing
Custom Queuing (CQ) là kĩ thuật hàng đợi ra đời sau PQ, không giống như PQ, CQ sẽ phục vụ cho tất cả các hàng đợi có trong interface của nó thậm chí khi sảy ra nghẽn mạng. CQ có tất cả 16 hàng đợi, như vậy nó cho phép tối đa 16 lớp dịch vụ (vừa đủ cho các loại dịch vụ ngày nay). CQ còn không cung cấp cho một hàng đợi đặc biệt nào đó có mức ưu tiên cao hơn các hàng đợi khác và cũng không ưu tiên hàng đợi nào có low delay, low jitter, low loss…

CQ cung cấp một lượng băng thông ngang nhau cho tất cả các hàng đợi, việc lập lịch của CQ như sau:

Hình 3.19: Cách lấy gói tin của CQ

CQ sẽ kiểm tra lần lượt các hàng đợi, bắt đầu từ hàng đợi thứ 1, CQ sẽ lấy gói tin từ hàng đợi này cho tới khi số gói tin mà nó lấy vượt quá hoặc bằng giá trị cho phép, sau khi hàng đợi này đã được phục vụ với số gói tin nhu trên hoạc hàng đợi này không có gói tin thì CQ sẽ chuyển qua phục vụ cho hàng đợi kế tiếp và quá trình lặp lại như trên.
CQ không cho phép cấu hình băng thông cho từng hàng đợi mà chỉ cho phép cấu hình số gói tin sẽ lấy thừ hàng đợi đó. Ví dụ: ta thiết kế sẽ lấy 10000 bytes cho mỗi hàng đợi và ta có 5 hàng đợi tất cả, như vậy mỗi hàng đợi sẽ chiếm dụng băng thông là 20% (10000/50000). Bây giờ nếu ta thiết kế có 5 hàng đợi: hai hàng đầu tiên sẽ được phục vụ với số bytes là 5000, hai hàng tiếp theo là 10000, và hàng thứ 5 là 20000, như vậy hàng thứ nhất và thứ hàng mỗi hàng sẽ nhận băng thông là 10% (5000/50000), hai hàng tiếp theo mỗi hàng nhận là 20% (10000/50000) và thứ 5 là 40% trên tổng băng thông của link.
Khi thực hiện gởi gói tin, giả sử trong hàng đợi thứ 4 không có gói tin nào đang chờ, chỉ có hàng đợi 1,2,3 và 5 là có gói tin đang chờ, khi đó băng thông sẽ được phân phát lại như sau: hàng đợi thứ nhất nhận 12.5%, thứ 2 12.5%, thứ 3 25%, thứ 4 0% và thứ 5 là 50%.

Ta tính như sau:
Hàng đợi thứ 1 : =12.5%
Hàng đợi thứ 2: =12.5%
Hàng đợi thứ 3: =25%
Hàng đợi thứ 4: =50%
Quá trình gởi gói tin của CQ:

Hình 3.20: Quá trình gởi gói tin của CQ

1.CQ phân loại gói tin bằng các ACLs hoặc bằng các kĩ thuật khác.
2.Tail drop là kĩ thuật CQ dùng để chống nghẽn.
3.Tối đa là 16 hàng đợi.
4.Ta có thể set kích cỡ của hàng đợi về tới 0 (nghĩa là chiều dài là vô hạng).
5.Bên trong một hành đợi CQ sử dụng FIFO.

6.Khi lập lịch cho gói tin, CQ sẽ xoay vòng cho các hàng đợi (phục vụ cho hàng này xong thì tới hàng hàng khác).
Đặc điểm của CQ :
+ Không thích hợp cho các mạng cần low delay, low jitter,...
+ Không thể dành trước băng thông cho link.
+ Không cung cấp hàng đợi ưu tiên.
+ Không thích hợp cho Voice
+ Cho phép các hàng đợi được phục vụ xoay vòng.
+Cho phép các hàng đợi bình đẳng nhau.

Hình 3.21: Bảng tóm tắc CQ

3.3.4 Weighted Fair Queuing
WFQ là kĩ thuật hàng đợi mặc định trong router Cisco, nó khác với các hàng đợi PQ và FIFO ở các điểm sau:
+ Nó không cho phép cấu hình phân loại, WFQ phân loại gói tin theo flow, một flow bao gồm nhiều gói tin có cùng đích đến và cùng nguồn, cùng port đích và port nguồn. Sẽ

không có cấu hình nào rõ rang cho nó.
+ Tính năng lập lịch: WFQ dựa vào flow, do vậy những flow nào có độ ưu tiên cao hơn thì sẽ được phát trước.
+ Mỗi flow là một hàng đợi, vì vậy số hàng đợi trong WFQ có thể lên tới 4096 hàng đợi lớn hơn rất nhiều so với PQ hay FIFO.
Với WFQ ta có tối đa là 4096 hàng đợi trong 1 interface của router, số hàng đợi này cũng chính là số flow chảy vào router. Ví dụ: ta có 5 flow là Voice, 2 kết nối HTTP, 2 kết nối FTP thì khi đó ta sẽ có 5 hàng đợi trong router, như vậy số hàng đợi thay đổi theo số flow, chúng không cố định như trong các kĩ thuật khác

Hình 3.22: Cách lấy gói tin của WFQ

Hoạt động của WFQ như sau:

Hình 3.23: Tiến trình gởi gói tin của WFQ

+Khi gói tin vào interface, nó sẽ được phân loại thành các flow theo 5 thông số:
- IP source
- IP destination
- port source
- port destination
- Giao thức lớp 4 nó sử dụng là gì (TCP hay UDP)
WFQ dựa vào các trường như DSCP, ToS để phân loại gói tin và đưa nó vào các hàng đợi khác nhau. Những gói tin có IP precedent hay DSCP cao hơn sẽ có mức ưu tiên cao hơn.
Hai vấn đề quan trọng trong WFQ đó là :
a. Đối xử công bằng với tất cả các flow đang tồn tại : Giả sử ta có băng thông là 128 kbps và có 10 hàng đợi đang tồn tại, mỗi hàng đợi sẽ nhận được băng thông là 12.8 kbps. Nều số hàng đợi là 100 thì mỗi hàng đợi sẽ nhận băng thông là 1.28 kbps. Một vấn đề tồn tại ở đây là sự quá công bằng của WFQ, giả
b. sử trong số 10 hàng đợi trên hàng đợi thứ 1 cần băng thông là 5 kbps và hàng đợi thứ 2 cần băng thông là 30 kbps, nhưng vì WFQ chỉ cấp băng thông cho mỗi hàng đợi là 12.8 kbps, như vậy hàng đợi thứ 1 dư băng thông nó sẽ luôn được phục vụ tốt nhất, nghĩa là low delay, low jitter, low loss vì số gói tin trong hàng đợi của nó lúc nào cùng rất ít. Với hàng đợi thứ 2 thiếu băng thông vì vậy delay, jitter và loss của nó sẽ rất lớn.
c. Cung cấp thêm băng thông cho những flow có mức ưu tiên cao hơn (higher IP precedent hay higher DSCP) : Vẫn với giả sử trên 128 kbps cho 10 flow. Bây giờ giả sử có 5 flow với IP precedent bằng 0, và 5 flow với IP precedent bằng 1, 5 flow IP precedent 1 có mức ưu tiên cao hơn 5 flow IP precedent 0 theo đó tỉ số băng thông phân phối là 2:1, flow IP precedent 1 sẽ nhận băng thông là 17 kbps gấp đôi flow IP precedent 0 là 8.5 kbps, cách tính tỉ số này như sau:
= =
+ Sau khi được phân loại gói tin sẽ được tính giá trị SN (Sequence number) như sau:
SN = SN (trước đó) + Weight*length
SN : Sequence number
Weight : trọng số của gói tin , Weight=32384 / (IP_Precedence+1)
Length : Chiều dài gói tin
Bảng giá trị của Weight:

Hình 3.24: Bảng giá trị Weight

Ví dụ: Với gói tin có SN trước đó là 0, chiều dài là 1500 byte và precedent là 0 ta sẽ tính SN như sau:
SN = 0 + 1500*32384 = 48576000
- Sau đó quyết định có drop gói tin hay không dựa vào 2 thông số (còn gọi là Tail drop):
- Hold-queue: Nếu gói tin là này là gói mà làm vượt mức hold-queue (tổng số gói tin trong tất cả các hàng đơi) thì nó sẽ bị drop.
- CDT: (Congestion discard threshold) là số gói tin tối đa trong một hàng đợi, giá trị này có thể cấu hình cho phép từ 1 đến 4096.
+ Tiếp theo các gói tin nếu không bị drop sẽ đưa vào hàng đợi và chờ phát đi
+ Khi nằm trong hàng đợi các gói tin sẽ được lập lịch (scheduler logic), quá trình lập lịch dựa vào SN của gói tin, precedent và volume (Số gói tin đang có trong một hàng đợi).
- Những gói tin có SN càng nhỏ, precedent càng lớn, và volume càng nhỏ sẽ được chọn forward trước.
- Thứ tự ưu tiên như sau: Đầu tiên là SN, sau đó là precedent, và cuối cùng là volume.

Hình 3.25: Tính toán SN

Ví dụ:
Ta có 4 hàng đợi là flow 1, flow 2, flow 3, flow 4, với kích thức mỗi gói tin là 1500 byte, 1000 byte, 500 byte, 100 byte. Mỗi hàng đợi có 4 gói tin với precedent là 0, giả sử SN trước đó của các gói tin là 0, như vậy ta tính được các giá trị SN như hình sau:

Hình 3.26: Thứ tự gởi gói tin

Khi đó thứ tự forward gói tin là: 13, 5, 14, 15, 6, 1, 16, 7, 9, 2, 8, 3, 4, 11, 12.
Ví dụ cấu hình cho WFQ:

Hình 3.27: Ví dụ về mạng có dùng WFQ

R3#conf t
R3(config)#int s 0/0
R3(config-if)#fair-queue
R3(config-if)#^Z
R3#sh int s 0/0
Serial0/0 is up, line protocol is up
Hardware is PowerQUICC Serial
Description: connected to FRS port S0. Single PVC to R1.
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 9/255, rxload 8/255
Encapsulation FRAME-RELAY, loopback not set
Keepalive set (10 sec)
LMI enq sent 171, LMI stat recvd 163, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
Broadcast queue 0/64, broadcasts sent/dropped 378/2, interface broadcasts 347
Last input 00:00:01, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:28:46
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 8249
Queueing strategy: weighted fair
Output queue: 126/1000/64/8249 (size/max total/threshold/drops)
Conversations 6/7/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)

Available Bandwidth 1158 kilobits/sec
5 minute input rate 52000 bits/sec, 97 packets/sec
5 minute output rate 58000 bits/sec, 78 packets/sec
36509 packets input, 2347716 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
1 input errors, 0 CRC, 1 frame, 0 overrun, 0 ignored, 0 abort
28212 packets output, 2623792 bytes, 0 underruns
0 output errors, 0 collisions, 5 interface resets
0 output buffer failures, 0 output buffers swapped out
10 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
R3#show queueing fair
Current fair queue configuration:
Interface Discard Dynamic Reserved Link Priority
threshold queues queues queues queues
Serial0/0 64 256 0 8 1
Serial0/1 64 256 0 8 1
R3#show queueing fair int s 0/0
Current fair queue configuration:
Interface Discard Dynamic Reserved Link Priority
threshold queues queues queues queues
Serial0/0 64 256 0 8 1
R3# show queue s 0/0

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 11027
Serial0/0 64 256
Queueing strategy: weighted fair
Output queue: 79/1000/64/11027 (size/max total/threshold/drops)
Conversations 4/8/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1158 kilobits/sec
! Next stanza lists info about one of the VoIP calls
(depth/weight/total drops/no-buffer drops/interleaves) 37/5397/1359/0/0
Conversation 15, linktype: ip, length: 64
source: 192.168.3.254, destination: 192.168.2.251, id: 0x013B, ttl: 253,
TOS: 184 prot: 17, source port 16772, destination port 19232
! Next stanza lists info about one of the VoIP calls
(depth/weight/total drops/no-buffer drops/interleaves) 37/5397/1359/0/0
Conversation 125, linktype: ip, length: 64
source: 192.168.3.254, destination: 192.168.2.251, id: 0x0134, ttl: 253,
TOS: 184 prot: 17, source port 16638, destination port 19476
! Next stanza lists info about one of the HTTP TCP connections
(depth/weight/total drops/no-buffer drops/interleaves) 1/10794/36/0/0
Conversation 33, linktype: ip, length: 1404
5397
10794
source: 192.168.3.100, destination: 192.168.1.100, id: 0xFF50, ttl: 127,

TOS: 72 prot: 6, source port 80, destination port 1067
! Next stanza lists info about one of the HTTP TCP connections
(depth/weight/total drops/no-buffer drops/interleaves) 2/10794/34/0/0
Conversation 34, linktype: ip, length: 1404
source: 192.168.3.100, destination: 192.168.1.100, id: 0xFF53, ttl: 127,
TOS: 88 prot: 6, source port 80, destination port 1068
! Notice the TOS values versus the weight in the last two stanzas!
R3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#int s 0/0
R3(config-if)#fair-queue 100 64 10
R3(config-if)#hold-queue 500 out
R3(config-if)#^Z
!
R3#show interface serial 0/0
Serial0/0 is up, line protocol is up
Hardware is PowerQUICC Serial
Description: connected to FRS port S0. Single PVC to R1.
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 9/255, rxload 8/255
Encapsulation FRAME-RELAY, loopback not set
Keepalive set (10 sec)
LMI enq sent 198, LMI stat recvd 190, LMI upd recvd 0, DTE LMI up

LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
Broadcast queue 0/64, broadcasts sent/dropped 442/2, interface broadcasts 406
Last input 00:00:01, output 00:00:00, output hang never
10794
Last clearing of "show interface" counters 00:33:14
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 12474
Queueing strategy: weighted fair
Output queue: 95/500/100/12474 (size/max total/threshold/drops)
Conversations 5/6/64 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1158 kilobits/sec
! lines omitted for brevity
R3#show queueing fair
Current fair queue configuration:
Interface Discard Dynamic Reserved Link Priority
threshold queues queues queues queues
Serial0/0 100 64 10 8 1
Serial0/1 64 256 0 8 1
3.3.5 Class-Based Weighted Fair Queuing
Class-Based Weighted Fair Queuing (CBWFQ) là kĩ thuật hàng đợi ra đời sau WFQ, nó giống với WFQ ở chỗ: Cho phép sử dụng WFQ ngay bên trong một hàng đợi của nó, nhưng khác với WFQ ở chỗ: CBWFQ sử dụng Class để phân loại còn WFQ sử dụng flow.

CBWFQ có thể cấu hình băng thông thực sự cho một hàng đợi.

Hình 3.28: Tiến trình gởi gói tin của CBWFQ

Từ trái sang phải:
1.CBWFQ phân loại gói tin bằng ACLs, MPLS EXP, Port….
2.Quyết định drop gói tin bằng các kĩ thuật Tail drop hoặc WRED
3.Số hàng đợi tối đa là 64 và chiều dài hàng đợi tối đa là 64, các giá trị này là mặc định ta có thể set tùy theo ý muốn.
4.Bên trong mỗi hàng đợi ta có thể dùng FIFO hoặc WFQ.
Chú ý: WRED là kĩ thuật hàng đợi dùng để chống nghẽn, nó tốt cho một số loại dữ liệu nhưng cũng không tốt cho các dữ liệu như Voice hay Video vì các dữ liệu này cần không bị rớt trong mọi trường hợp.
CBWFQ vượt trội hơn các hàng đợi WFQ ở chỗ: Nó phân loại gói tin theo Class chứ không theo flow, như vậy dễ dàng cho ta thiết kế hơn.

Hình 3.29: các hàng đợi của CBWFQ

Bảng tóm tắt CBWFQ:

Cấu hình CBWFQ:

Kiểm tra lại cấu hình:

3.3.6 Low-latency Queuing
Low –latency Queueing (LLQ) là một kĩ thuật hàng đợi mà ở đó nó cho phép gói tin được phục vụ với chất lượng cao nhất (low delay, low jitter, low loss …).Nó đơn giản để cấu hình và đơn giản để hiểu. LLQ không phải là một hàng đợi tách biệt với các kĩ thuật hàng đợi khác, nó được sử dụng bên trong một kĩ thuật hàng đợi nào đó để làm tăng tính ưu tiên cho hàng đợi này, những hàng đợi có dùng LLQ thì nó được đối xử giống như hàng đợi PQ, nhưng với PQ thì nó không đảm bảo băng thông cho các hàng đợi khác còn với LLQ thì mặc dù vẫn có hàng đợi ưu tiên nhưng nó vẫn đảm bảo băng thông cho các hàng đợi không có LLQ.

Hình 3.30: Tiến trình gởi gói tin của LLQ

Hoặc:

Theo như giản đồ trên thì LLQ sẽ hoạt động không khác gì so với PQ bởi vì nó luôn phục vụ hàng đợi có mức ưu tiên cao hơn, chỉ khi nào hàng đợi này không còn gói tin thì

nó mới chuyển sang hàng đợi không có ưu tiên. Để khắc phục điều này LLQ sẽ làm như sau:

Hình 3.31: Tiến trình gởi gói tin của LLQ cải thiện
Như vậy mỗi khi hàng đợi LLQ vượt quá tốc độ cho phép hay băng thông cho phép thì các gói tin trong hàng đợi này sẽ bị rớt và chuyển qua phục vụ cho hàng đợi khác. Như vây hàng đợi LLQ chỉ có thể hoạt động ở tốc độ đã được thiết lập từ trước và không thể tranh chấp với các hàng đợi khác khi nó cần thêm băng thông, vậy các hàng đợi khác đã được đảm bảo về băng thông.
Như vậy LLQ là hàng đợi luôn được phục vụ trước nhưng nó có các chính sách để ngăn chặn việc tranh chấp băng thông với các hàng đợi khác khi xay ra vượt qua tốc độ cho phép.
Hàng đợi LLQ có ý nghĩa rất lớn trong các dữ liệu là Voice, Video…vì nó cho phép các dữ liệu này nhận được sự phục vụ tốt nhất có thể: low delay, low jitter, low loss..
Ví dụ cấu hình LLQ:
Để cấu hình một hàng đợi LLQ bên trong một hàng đợi nào đó ta dùng câu lệnh sau:
priority {bandwidth-kbps | percent percentage} [burst]
Ví dụ:
PE1(config-pmap)#class Voice-EXP

PE1(config-pmap-c)#priority 512 ///Mức ưu tiên cao nhất
PE1(config-pmap-c)#exit
Với cầu hình này, một hàng đợi của CBWFQ là Voice-EXP đã được cấu hình thêm bên trong đó là hàng đợi LLQ với băng thông là 512 kbps. Khi đó hàng đợi này sẽ có mức ưu tiên cao nhất trong tất cả các hàng đợi.
Bảng tóm tắt các kĩ thuật hàng đợi:

Bảng trên cho ta tóm tắt về các hàng đợi và các kĩ thuật drop mặc định của chúng, cột cuối cùng là số hàng đợi tối đa cho mỗi loại hàng đợi.

Cột thứ 2 là các kĩ thuật lập lịch cho gói tin trong mỗi hàng đợi.
Các trường dùng để phân loại của các kĩ thuật hàng đợi:

3.4 Định hướng và chính sách (Shaping and policing)
Định hướng và các chính sách là một một phần không thể thiếu trong các kĩ thuật QoS, các chính sách sẽ giúp cho các gói tin có được các mức ưu tiên phù hợp với đặc điểm của nó và sẽ drop gói tin khi tốc độ vượt qua mức so với cấu hình, Chính sách do kĩ sư thiết kế cho các loại dữ liệu khác nhau, nó tùy thuộc vào cảm tính của người kĩ sư và phụ thuộc vào thõa thuận giữa nhà cung cấp dịch vụ và khách hàng. Trong khi đó định hướng sẽ giúp cho các gói tin nhận được sự phục vụ đúng theo tốc độ đã định hình nó không drop gói tin mà chỉ làm cho gói tin chậm lại để không bị vượt quá tốc độ cho phép.
Cả hai công cụ shaping và policing đều đo tốc độ truyền hoặc nhận dữ liệu. Policing có khả năng loại bỏ những gói tin dư thừa để đảm bảo tốc độ truyền không vượt quá tốc độ thoả thuận.

Shaping sắp xếp các gói dư thừa này vào hàng đợi, và rồi đi ra khỏi hàng đợi ở tốc độ định hình.
Trong cả hai trường hợp, cả hai công cụ đều ngăn lưu lượng không được vượt quá tốc độ bit được định nghĩa bởi người quản trị.
Một lý do cổ điển để lựa chọn shaping là khi thiết bị ở đầu kia của đường truyền đang thực hiện policing. Ví dụ: giả sử R1 thuộc một doanh nghiệp và R2 thuộc ISP. R1 gửi gói tới R2 và R2 thực hiện policing, loại bỏ những lưu lượng vượt quá tốc độ xbps.
ISP có thể lựa chọn giám sát tại R2 để bảo vệ mạng tránh khỏi việc chấp nhận quá nhiều lưu lượng. R1 có thể được cấu hình đề shaping lưu lượng gửi tới R2 sao cho lưu lượng này ở tốc độ bằng với tốc độ ở phía giám sát ở R2, thay vì để dữ liệu thừa bị R2 loại bỏ.
Nói tóm lại, shaping và policing có thể đóng vai trò quan trọng trong trường hợp router có thể gửi nhiều lưu lượng hơn sự cho phép của hợp đồng lưu lượng. Shaping chỉ làm chậm lại tốc độ truyền gói để không vượt quá hợp đồng lưu lượng. Policing loại bỏ những gói để không vượt quá hợp đồng lưu lượng.

Hình 3.32: So sánh giữ policing và shaping

Theo hình như trên ta thấy với policing thì nó chỉ ứng xử với các gói tin vượt qua tốc độ cho phép bằng cách drop chúng để tốc độ vẫn đảm bảo vì vậy ngõ ra có dạng răng cưa. Còn

với Shaping thì nó cho ngõ ra mượt hơn bởi vì nó không ứng xử với các gó itn đã vượt quá tốc độ mà nó sẽ làm cho các gói tin chậm lại và đảm bảo tốc độ cho trước.
Ví dụ cấu hình policing và shaping:
+ Cấu hình theo policing:
class-map match-all IP
match ip precedence 3
class-map match-all VoIP
match ip precedence 5
policy-map child
class VoIP
priority 128
class IP
priority 1000
policy-map parent
class class-default
police 3300000 103000 103000 conform-action transmit exceed-action drop
service-policy child
+ Cấu hình theo Shaping:
policy-map parent
class class-default
shape average 3300000 103000 0
service-policy child.

**xinchao** · 10-05-2009, 02:49 PM

anh oi !
em dang lam ve diffserv/mpls su dung cac ky thuat hang doi,neu duoc anh co the share tai lieu cho em,hoac nick yahoo de chat ,co nhieu cai em ko hieu ma thoi gian ko con nhieu,cuoi thang nay em phai nop do an roi ma van chua mo phong duoc:(.
nick : kinhcan_dn85@yahoo.com

**tuxedo_0510** · 24-02-2010, 03:49 PM

úi, E cũng đang làm về diffserv/MPLS giống như bạn xinchao. A có tài liệu share luôn cho E với nhé.
thanh_inpg@yahoo.com
thanks A

**luancb** · 24-02-2010, 05:59 PM

Tài liệu các bạn cần đây ! Tải file đính kèm.

Attached Files

luan van QoS MPLS.doc (4.00 MB, 1055 views)

**tuxedo_0510** · 25-02-2010, 08:12 AM

thank A nhìu nhé!

**tuxedo_0510** · 22-03-2010, 09:00 PM

Lab QoS trong mạng MPLS

mình đang làm lab về QoS trong mạng MPLS mà ko tìm dc phần mềm để đo Qos. Mặc dù đã xây dựng và cấu hình mạng xong. A biết về phần mềm D-ITG chỉ giúp mìh. Hoặc ai đó biết về phần mền nào khác mà đo dc chất lượng dịch vụ trong mạng giả lập trên GNS3 thì post lên giúp mình nhé. Cảm ơn các bạn nhiều :)

**zizou315** · 29-03-2010, 10:33 PM

chào mọi người, mình đang làm đồ án tốt nghiệp về " kết hợp Diffserv - Mpls " để giải quyết vấn đề QoS, mình đang dùng NS2 để mô phỏng . Mọi người có tài liệu để mô phỏng các mô hình Pipe mode, short pipe mode , Uniform mode thì share cho mình với . Mình đang rất cần để hoàn thành đồ án tôt nghiệp. Thanks mọi người !
Mail của mình là pro0110@gmail.com

**realheaven** · 07-08-2010, 11:27 PM

xin lỗi cho mình hỏi, bài viết của bạn luancb ở trên là QoS cho IP hay MPLS vậy?
Nếu là của MPLS thì QoS của IP và MPLS khác nhau chỗ nào?
Thax!

**duyloc2011** · 09-10-2013, 05:42 PM

Anh luancb oi , anh co the jup huong dan su dung phan men D_ITG ?. em da lam ve cai nay nhung ko biet su dung no

**trangdangbt92** · 21-12-2014, 10:25 AM

Chào anh luancb, em cũng đang tìm hiểu về QoS em đang gặp vấn đề về việc làm sao để kiểm tra delay, jitter,...Trong luận văn trên em thấy có nội dung này " Flow number: 2
From 192.168.2.2:30000
To 192.168.3.2:30000
----------------------------------------------------------
Total time = 19.381000 s

Total packets = 1000
Minimum delay = 20.787000 s
Maximum delay = 30.235000 s
Average delay = 26.738128 s
Average jitter = 0.019012 s
Delay standard deviation = 2.613705 s
Bytes received = 92000
Average bitrate = 37.975337 Kbit/s
Average packet rate = 51.596925 pkt/s
Packets dropped = 0 (0.00 %)"
Em muốn hỏi làm sao đề có thể kiểm tra được kết quả như trên ạ.
EM cám ơn

Announcement

QoS trong MPLS (chương 3) !!!

QoS trong MPLS (chương 3) !!!

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment