3. Cấu trúc các chương
5.2.1.2 Thực hiện và phân tích kết quả mô phỏng 1
Thực hiện mô phỏng với lịch trình quy định trong script mô phỏng:
Thời điểm 0.5s luồng 1 bắt đầu truyền.
Thời điểm 2s luống 2 bắt đầu truyền.
Thời điểm 5s cả hai luồng ngưng truyền. Kết quả:
Luồng 1: Truyền 84 gói, mất 244 gói, tỉ lệ mất 28.9%
Luồng 2: Truyền 599 gói, mất 240 gói, tỉ lệ mất 42.9%
Hình 5.5: Lưu lượng các luồng trong thực nghiệm 1
1 3 5 7 9 0 10 2 4 6 8 UDP CBR CBR UDP Sink Sink
Nhận xét:
Mạng IP sử dụng giải thuật định tuyến chọn đường ngắn nhất, do vậy cả hai đường đều đi theo con đường là 1_3_5_7_9. Băng thông trên đường này không đủ cho cả hai luồng, do vậy tất yếu xảy ra tắc nghẽn. Kết quả quan sát cho thấy cả hai luồng chia sẽ băng thông khá cân bằng và đều bị rớt gói tin tại router n3. Trong khi đó các đường khác có đủ băng thông nhưng lại không được sử dụng. Đây chính là vấn đề sử dụng tài nguyên không hiệu quả trong mạng IP thông thường.
5.2.2 Thực nghiệm 2: Mô phỏng mạng IP có hỗ trợ việc đặt trƣớc tài nguyên
Mục tiêu của thực nghiệm này nhằm mô phỏng quá trình tranh chấp dự trữ trước tài nguyên. Khi một nguồn tài nguyên đã được dự trữ trước, nếu có một yêu cầu giành trước tài nguyên tiếp theo mà không còn tài nguyên khả dụng thì yêu cầu đó bị từ chối.
5.2.2.1 Thiết lập cấu hình mô phỏng 2
Mô hình vật lý của mạng mô phỏng có cấu hình như đã giới thiệu trong hình 5.3, trong đó nút 0 và nút 10 là các router thông thường. Các nút từ 1 đến 9 là các router hỗ trợ RSVP tạo thành một miền IntServ.
Hai nguồn sinh lưu lượng được gắn vào nút n0 tương ứng với nó có hai đích nhận lưu lượng (sink0 và sink1) gắn vào nút n10 tương tự như thực nghiệm 1. Mỗi nguồn phát lưu lượng với tốc độ 0.8Mbps, kích thước gói 600B. Các luồng đều được truyền theo tuyến tường minh ER (Explicit Routing) định trước.
5.2.2.2 Thực hiện và phân tích kết quả mô phỏng 2
Thực hiện mô phỏng với lịch trình quy định trong script mô phỏng, các thời điểm bắt đầu, kết thúc các sự kiện như trong thực nghiệm 1.
Thời điểm 0.5s luồng một bắt đầu truyền trên tuyến được thiết lập tường minh ER = 1_2_4_6_5_7_9 ràng buộc BW = 0.8Mbps.
Thời điểm 2s luồng hai bắt đầu truyền trên tuyến được thiết lập tường minh ER = 1_3_5_7_9 với ràng buộc BW = 0.8Mbps.
Thời điểm 5s cả hai luồng ngưng truyền. Quan sát hoạt động của mạng trên cửa sổ NAM:
Với NAM, ta có thể quan sát được hoạt động của mạng mô phỏng trong thực nghiệm. Nguồn lưu lượng màu xanh da trời là luồng một, luồng lưu lượng màu xanh lá cây là luồng hai. Hai luồng cùng truyền qua kết nối n5-n7, luồng hai bị rớt gói tin tại nút n7,
Hình 5.6: Hình ảnh hoạt động của mạng trong thực nghiệm 2 trên cửa sổ
nam
Phân tích quá trình thiết lập dự trữ tài nguyên qua tệp vết thu được:
Để thiết lập một luồng dự trữ trước tài nguyên, trước tiên bên gửi phát một bản tin Path dọc theo tuyến tường minh ER. Bản tin Path chứa một session-id và các yêu cầu băng thông. Khi bản tin Path tới đích bên nhận đáp ứng bằng một bản tin Resv. Bản tin Resv được truyền theo hướng ngược với bản tin Path bằng cách dùng thông tin của hop kề trước trong bản tin Path, nó cũng chứa cùng session-id như bản tin Path tương ứng. Bản tin Resv sẽ thiết lập việc giữ trữ tài nguyên ở các router, khi bản tin Resv tới đích thì quá trình thiết lập dự trự tài nguyên hoàn thành.
2 PATH EVENT at 0.132 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0 4 PATH EVENT at 0.163 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0
6 PATH EVENT at 0.194 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0 5 PATH EVENT at 0.225 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0 7 PATH EVENT at 0.256 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0 9 PATH EVENT at 0.287 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0 7 RESV EVENT at 0.318 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0 5 RESV EVENT at 0.349 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0 6 RESV EVENT at 0.380 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0 4 RESV EVENT at 0.410 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0 2 RESV EVENT at 0.441 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0 1 RESV EVENT at 0.473 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0 3 PATH EVENT at 0.732 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0 5 PATH EVENT at 0.763 : SID: 1 RATE: 800000 BUCKET: 5000 SENDER: 0 7 PATH EVENT at 0.793 : SID: 1 RATE: 800000 BUCKET: 5000 SENDER: 0 9 PATH EVENT at 0.828 : SID: 1 RATE: 800000 BUCKET: 5000 SENDER: 0 9 RESVERROR EVENT at 0.893 : SID: 1 CODE: 1 VALUE: 0 NODE: 7 Kết quả truyền các luồng:
Luồng 1 truyền 751 gói tỉ lệ mất gói 0%.
Luồng 2 truyền 500 gói, mất 358 gói tỉ lệ mất gói 71.5 %.
Hình 5.7: Lưu lượng các luồng trong thực nghiệm 2
Nhận xét:
Luồng một được thiết lập trước theo tuyến ER = 1_2_4_6_5_7_9, luồng hai được thiết lập sau theo tuyến ER = 1_3_5_7_9. Như vậy hai luồng lưu lượng cạnh tranh băng thông nhau trên đường truyền n7-n9 do đường truyền này không
đủ băng thông cho cả hai tuyến. Do luồng một được thiết lập trước và đã thực hiện quá trình đặt trước tài nguyên, đến khi luồng hai thiết lập thì không còn đủ tài nguyên nữa nên việc thiết lập đặt trước tài nguyên của luồng hai bị thất bại. Luồng hai sẽ truyền theo kiểu best-effort, nghĩa là tận dụng lượng băng thông 0.2Mbps còn lại trên kết nối.
5.2.3 Thực nghiệm 3: Mô phỏng hoạt động tự khôi phục kết nối đƣờng truyền bị “đứt”
Mục tiêu của thực nghiệm này nhằm mô phỏng hoạt động của mạng RSVP khi một kết nói bị đứt. Nó sẽ tự động khôi phục và truyền theo một tuyến khả dụng mới với tài nguyên được dự trữ trước.
5.2.3.1 Thiết lập cấu hình mô phỏng 3
Mô hình vật lý của mạng mô phỏng có cấu hình như đã giới thiệu trong hình 5.3, trong đó nút 0 và nút 10 là các router thông thường. Các nút từ 1 đến 9 là các router hỗ trợ RSVP tạo thành một miền IntServ.
Có một nguồn sinh lưu lượng được gắn vào nút n0 tương ứng với nó có một đích nhận lưu lượng (sink0) gắn vào nút n10. Nguồn phát lưu lượng với tốc độ 0.8Mbps, kích thước gói 600B.
Hình 5.8: Cấu hình mạng mô phỏng thực nghiệm 3
5.2.3.2 Thực hiện và phân tích kết quả mô phỏng 3
Thiết lập đường truyền tường minh ER = 1_3_5_7_9
Thời điểm 0.5s luồng 1 bắt đầu truyền trên tuyến tường minh.
Thời điểm 2s đường truyền giữa n5-n7 bị đứt.
1 3 5 7 9
0 10
2 4 6 8
CBR
Thời điểm 5s luồng 1 ngưng truyền. Quan sát hoạt động của mạng trên cửa sổ NAM:
Với NAM, ta có thể quan sát được hoạt động của mạng mô phỏng trong thực nghiệm. Quá trình này bao gồm việc đặt trước tài nguyên, việc đứt đường truyền giữa n5-n7, việc khôi phục đường truyền giữa thực thể nguồn và đích.
Hình 5.9: Hình ảnh hoạt động của mạng trong thực nghiệm 3 trên cửa sổ
nam
Phân tích quá trình thiết lập dự trữ tài nguyên qua tệp vết thu được:
Tại thời điểm 0.232s bên phát gửi bản tin Path dọc theo tuyến tường minh tới bên nhận. Khi bản tin Path tới bên nhận, bản tin Resv sẽ được gửi tương ứng theo hướng ngược với bản tin Path bằng cách dùng thông tin của hop kề trước trong bản tin Path. Tại thời điểm 2.031s có lỗi xảy ra tại nút n7, nó sẽ gửi bản tin ResvTear và PathTear tới các nút theo các hướng tương ứng tới bên nhận và bên gửi.
3 PATH EVENT at 0.232 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0 5 PATH EVENT at 0.263 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0 7 PATH EVENT at 0.293 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0 9 PATH EVENT at 0.325 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0
7 RESV EVENT at 0.356 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0 5 RESV EVENT at 0.386 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0 3 RESV EVENT at 0.417 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0 1 RESV EVENT at 0.448 : SID: 0 RATE: 800000 BUCKET: 5000 SENDER: 0 9 RESVERROR EVENT at 2.031 : SID: 0 CODE: 1 VALUE: 0 NODE: 7 7 RESVTEAR EVENT at 2.061 : SID: 0 SENDER: 0
3 PATHTEAR EVENT at 2.091 : SID: 0 SENDER: 0 5 PATHTEAR EVENT at 2.125 : SID: 0 SENDER: 0
Kết quả truyền luồng: luồng truyền 751 gói, mất 6 gói, tỉ lệ mất 0.79%.
Hình 5.10: Lưu lượng luồng trong thực nghiệm 3
Hình 5.11: Biến thiên trễ của luồng trong thực nghiệm 3
Khi đường truyền n5-n7 bị đứt, nút (router) n5 tự động định tuyến và xác định lại đường ngắn nhất từ n5 tới nút đích. Đường dẫn ngắn nhất này là 5_6_8_9. Đồng thời nút n5 phát ra bản tin PathErr tới nút n1 và nút n7 phát ra bản tin ResvErr tới nút n9. Nút n1 sẽ phát bản tin PathTear và nút n9 sẽ phát bản tin ResvTear để giải phóng tài nguyên trên đường truyền. Sau khi giải phóng tài nguyên trên các nút, luồng sẽ tự động định tuyến theo tuyến mới 1_2_4_6_8_9. Khi truyền trên tuyến mới thì độ trễ của luồng tăng lên tương ứng với số router phải truyền qua tăng lên.
5.3 Thực nghiệm mô phỏng mô hình DiffServ
5.3.1 Mục tiêu thực nghiệm
Trong thực nghiệm này tôi thiết lập một mô hình DiffServ bao gồm dịch vụ đàm thoại VoiceIP, dịch vụ Video, dịch vụ truyền file Ftp. Mục tiêu là kiểm tra sự linh hoạt của các mô-đun DiffServ trong việc định nghĩa và cung cấp tập các tham số hiệu năng phù hợp với các yêu cầu. Mô hình đưa ra chỉ là một ví dụ tập trung vào mô hình thực thi hơn là mô hình thiết kế.
Diffserv Network Server VoiceIP ` Server Video ` Server FTP Provier Router
Provier Edge Router Client Edge Router
Client Voice IP ` Client Video ` Client FTP Server VoiceIP ` Server Video ` Server FTP Provier Router Server VoiceIP ` Server Video ` Server FTP Provier Router
Hình 5.12:Kiến trúc của mô hình mô phỏng
Kết quả thực nghiệm nhằm đánh giá các vấn đề sau:
So sánh chuyển tiếp nhanh EF PHB trong mạng DiffServ với mạng thông thường: các thông số về độ trễ, thông lượng và sự mất mát gói tin.
So sánh các mức khác nhau trong chuyển tiếp AF PHB: Đánh giá cơ chế loại bỏ gói tin sớm WRED với các lớp lưu lượng FTP khác nhau. WRED cho phép loại bỏ đồng thời nhưng với các mức khác nhau các gói tin dựa vào tiêu đề của các gói tin đó (mức ưu tiên loại bỏ được mã hoá trong DSCP). Mục đích của thực nghiệm là tìm ra các tham số tốt nhất để số lượng gói tin TCP truyền lại là nhỏ nhất phụ thuộc vào số lượng gói tin bị mất và đưa ra mức hiệu năng mong muốn.
5.3.2 Thiết lập cấu hình mô phỏng
Để đáp ứng được các mục tiêu trên, tôi xây dựng một mô hình DiffServ trên NS có các thông số như trên hình 5.13. Mạng có 21 nút, có 6 router và 15 máy
chủ được triển khai. Đường truyền giữa các nút đều là full-duplex, không có lỗi. Với mô hình này ta có thể làm nổi bật được hành vi chuyển tiếp của DiffServ đối với các loại lưu lượng khác nhau (VoiceIP, Video, FTP).
Router biên DiffServ kết nối với các các router có các loại lưu lượng khác nhau có giao diện vào như bảng dưới. Bộ lập lịch WRR được chọn trong suốt quá trình mô phỏng.
Bảng 5.1: TCS cho giao diện vào e1
Kiểu lƣu lƣợng PHB DSCP Trọng số Bộ đo Bộ loại bỏ VoiIP EF 10 6 Token bucket, CIR 64 kbps, CBS 1k byte Loại ngoài hồ sơ Video EF 20 20 Token bucket, CIR 384 kbps, CBS 10k byte Loại ngoài hồ sơ
FTP AF11 AF12 AF13 30 32 34 4 x WRED: 50, 70, 0.1 30, 50, 0.2 10, 30, 0.5 Khác Mặc định 40 1 Token bucket, CIR 700 kbps, CBS 100k byte Loại ngoài hồ sơ
Hình 5.13:Cấu hình mạng mô phỏng DiffServ trong NS2
Nguồn sinh lưu lượng voice: sử dụng nguồn phát kiểu EXP (Exponential On/Off) chạy tại các nút Server VoiceIP. Nguồn EXP này có những khoảng thời gian phát với tốc độ không đổi 64Kbps (On time) xen kẽ với những khoảng thời gian tạm ngừng (Off time). Độ dài các chu kỳ On/Off này được lấy ngẫu nhiên theo phân phối mũ với giá trị trung bình là 1s. Nguồn phát EXP này sử dụng thực thể giao vận UDP để phát tin tới thực thể null ở bên nút nhận Client VoiceIP.
Nguồn sinh lưu lượng video: sử dụng nguồn phát CBR (Constant Bit Rate) chạy tại các nút Server Video. Nguồn CBR sử dụng thực thể giao vận UDP để phát tin với tốc độ không đổi 384 Kbps tới thực thể null bên nút nhận Client Video.
Nguồn sinh lưu lượng data: sử dụng nguồn phát FTP (mô phỏng dịch vụ truyền tệp) chạy tại các nút Server FTP. Nguồn FTP sử dụng thực thể giao vận TCP để phát tin tới thực thể sink (nhận và gửi trả lại ACK) bên nút nhận Client FTP.
Ngoài ra để quá trình mô phỏng giống thực tế, trong mạng DiffServ tôi còn tạo ra có các lưu lượng nền khác từ các mạng ngoài DiffServ, truyền theo kiểu cố gắng tối đa. Do lưu lượng nguồn FTP có cơ chế truyền theo kiểu thích nghi nên trong mô phỏng này ta sử dụng nguồn phát FTP để tạo ra các lưu lượng cố gắng tối đa.
5.3.3 Thực hiện mô phỏng
Tôi đã tiến hành 2 mô phỏng trong trường hợp sử dụng và không sử dụng DiffServ với các điều kiện giống nhau. Trong cả hai trường hợp, mô phỏng được tiến hành trong thời gian 50s. Tại thời điểm 0.1 các nguồn FTP, CBR và EXP bắt đầu phát tin vào đường truyền. Đến thời điểm 50s, tất cả các nguồn đầu ngừng phát.
Tiến trình mô phỏng được chia làm hai phần với mục đích khác nhau.
Phần A: Có các tham số cấu hình như ở trên, nhằm để đánh giá các dịch vụ chuyển tiếp nhanh.
Phần B: Thay đổi các tham số của WRED, nhằm đưa ra mức hiệu năng mong muốn của dịch vụ bảo đảm truyền lưu lượng FTP. Các tham số WRED trong các trường hợp được chỉ ra trong hình dưới. Bao gồm ba trường hợp đó là ngưỡng loại bỏ không trùng nhau, trùng nhau một phần và trùng nhau hoàn toàn. Trọng số không thay đổi trong cả ba trường hợp 0.1 cho loại bỏ mức 0 DP0, 0.2 cho DP1 và 0.5 cho DP2. Bảng 5.2: Tập các tham số WRED Trƣờng hợp 1 Trƣờng hợp 2 Trƣờng hợp 3 Trƣờng hợp 4 Trƣờng hợp 5 Trƣờng hợp 6 DP0 50 70 65 95 45 65 40 60 20 60 20 80 DP1 30 50 35 65 30 50 30 50 20 60 20 80 DP2 10 30 5 35 15 35 20 40 20 60 20 80
Hình 5.14 minh hoạ một trường hợp của tập tham số WRED (trường hợp1) của bảng 5.2.
Hình 5.14: Tập các tham số của WRED trường hợp một
5.3.4 Kết quả mô phỏng và nhận xét
Phần A: Các dịch vụ chuyển tiếp nhanh
Do các nguồn voice đều có các tham số cấu hình giống nhau nên ta chỉ so sánh độ trễ và thông lượng của một nguồn trong hai trường hợp sử dụng và không sử dụng Diffserv. Ta cũng làm tương tự như vậy đối với nguồn Video.
Từ hình 5.15 chúng ta thấy, với nguồn voice khi không sử dụng Diffserv độ trễ biến thiên chủ yếu trong một miền từ 130 ms – 240 ms, giá trị trung bình là 191 ms. Khi áp dụng Diffserv, độ trễ biến thiên trong một dải hẹp từ 60 ms – 65 ms, giá trị trung bình là 62 ms. Chúng ta thấy rõ, việc áp dụng DiffServ vừa đảm bảo được các ràng buộc về thời gian truyền tin đồng thời tạo thuận lợi cho việc thiết lập các tham số nhằm khử jitter (playout delay) ở phía nhận.
Hình 5.15: Biến thiên độ trễ các gói tin nguồn voice
Từ hình 5.16 chúng ta thấy với nguồn video, khi không áp dụng Diffserv, độ trễ của các gói tin biến thiên chủ yếu trong miền từ 100 ms – 260 ms, giá trị trung bình là 193 ms. Chiến lược Diffserv giúp cải thiện đáng kể giá trị độ trễ này. Cụ