Tóm tắt Luận án - Nghiên cứu cải thiện diffserv qos trong mạng TP

g thể thiếu và ngày càng quan trọng hơn. Trong khi đó, các nhu cầu về dịch vụ không còn đơn điệu như trước và trên thực tế các ứng dụng đòi hỏi QoS xuất hiện ngày càng nhiều. Bối cảnh này đã đặt ra cho mạng IP nhiều thách thức mới, đòi hỏi mạng IP phải có các cơ chế QoS hoàn chỉnh để đáp ứng nhu cầu đa dịch vụ đang gia tăng. Trong cố gắng đầu tiên tăng cường khả năng QoS cho mạng IP, tổ chức IETF đã đưa ra cơ chế Integrated Services (IntServ). Nhưng IntServ sớm tỏ ra phức tạp, không có tính khả triển (scalability) nên Differentiated Services (DiffServ) được IETF đề xuất như là cơ chế thay thế IntServ. Về lý thuyết DiffServ là kiến trúc QoS quan trọng cho mạng IP, là cơ sở QoS trong IPv6 và có khả năng phối hợp với MPLS - 35 - khiển chấp nhận nối gần giống như môi trường mạng theo chế độ có kết nối. - 34 - 0,03 trong khi chạy DiffServ không dùng CAC với cùng điều kiện tải có xác suất mất gói trung bình khoảng 0,35 (chỉ mô phỏng độc lập tại tầng mạng, không kết hợp cơ chế hỗ trợ ở tầng giao vận như cơ chế điều khiển cửa sổ của TCP). Hiệu suất sử dụng liên kết cũng khá cao, đạt 90% với xác suất mất gói xấp xỉ 10-4 . 2. Kiến nghị hướng phát triển Vấn đề thực hiện QoS cho mạng IP là bài toán lớn, đòi hỏi sự phối hợp giải quyết từ nhiều giải pháp khác nhau. Hai giải pháp được đề xuất ở đây cần được tiếp tục nghiên cứu phát triển. Đối với giải pháp thực hiện AFij dựa vào CQM cần nghiên cứu thiết kế module điều khiển thích hợp, chú trọng thời gian tác động của bộ điều khiển nếu thực hiện bằng phần cứng theo lý thuyết điều khiển truyền thống. Nếu thực hiện bằng phần mềm cần đánh giá độ phức tạp của thuật toán CQM bao hàm thuật toán token bucket động. Đối với giải pháp điều khiển chấp nhận kết nối thì trước hết cần tiếp tục nghiên cứu mở rộng cho trường hợp liên domain. Kế đến là lý thuyết hóa đăng ký và giải phóng tài nguyên không tường minh trong mạng theo chế độ connectionless, từ đó xây dựng mô hình định lượng hợp lý làm cơ sở áp dụng các thủ tục điều - 3 - tạo ra cơ chế QoS mạnh. Tuy nhiên, trên thực tế các triển khai DiffServ vẫn chưa đầy đủ các lớp dịch vụ như đặc tả, từ đó việc cung cấp QoS trên mạng IP chưa được phổ biến, phần lớn các phiên truyền thông hiện nay đều phải chạy với mức best-effort. Thiết nghĩ cải thiện IP QoS trước hết phải cải thiện DiffServ, vì vậy cần phải tìm ra nguyên nhân khiến DiffServ có những yếu kém thực tế và đề ra giải pháp để khắc phục. Có nhiều nguyên nhân, ở đây có thể nêu ra hai nguyên nhân nổi trội. Nguyên nhân thứ nhất thuộc về phương pháp hiện thực DiffServ hiện nay; theo gợi ý của IETF, tất cả các hiện thực DiffServ đều dùng thuật toán quản lý hàng đợi tích cực RED để tạo các lớp dịch vụ khác biệt, nhưng các nghiên cứu cho thấy cách dùng RED có khó khăn. Bản thân RED không phải là cơ chế điều khiển nghẽn chính quy, không hỗ trợ chia sẻ tài nguyên và đặc biệt rất khó chọn lựa các tham số hoạt động cho nó mà không ảnh hưởng xấu đến phẩm chất của mạng. Nguyên nhân thứ hai là DiffServ của IETF không cung cấp cơ chế end-to-end QoS và không có phương pháp điều khiển các lớp QoS giữa các nhà điều hành mạng khác nhau. Thực tế, ứng dụng của người dùng không có cách gì để yêu cầu một lớp dịch vụ đặc biệt vì không có điều khiển chấp nhận kết nối (Connection Admission Control). Thiếu - 4 - điều khiển chấp nhận nối sẽ khó ngăn chặn tình trạng quá tải khiến cho khả năng cung cấp QoS không đảm bảo. Từ khảo sát phân tích trên đây, Nghiên cứu sinh nhận thức rằng DiffServ là cơ chế QoS quan trọng hàng đầu của mạng IP nên mục đích, đối tượng và phạm vi nghiên cứu trong luận án như sau: Mục đích nghiên cứu Làm sáng tỏ hiện trạng và xu thế của IP QoS. Tìm nguyên nhân của các hạn chế về thực hiện IP QoS theo kiến trúc DiffServ hiện nay. Đề xuất giải pháp nhằm cải thiện DiffServ trên phương diện thực hiện và cơ chế hoạt động, với hai mục tiêu chủ yếu là : Đề xuất giải pháp thuận lợi hiệu quả để thực hiện các lớp dịch vụ con AFij và đề xuất cơ chế điều khiển chấp nhận kết nối (CAC) cho DiffServ domain. Đối tượng và phạm vi nghiên cứu Nghiên cứu kiến trúc DiffServ QoS và DiffServ domain. Tập trung vào hướng triển khai DiffServ domain, thực hiện các lớp dịch vụ tại các DiffServ router và cơ chế đảm bảo end-to-end QoS. Phương pháp nghiên cứu Với định hướng nghiên cứu ứng dụng, công việc thực hiện luận án bước đầu gồm thu thập tài liệu, thực nghiệm trên các thiết bị và hệ thống. Kế tiếp là khảo sát các giải pháp thực hiện DiffServ trên thực tế, - 33 - Kết quả là hàng đợi được duy trì với độ dài ổn định, bộ đệm không bị tràn. Có thể thay đổi độ dài ổn định của hàng đợi bằng cách thay đổi giá trị tham chiếu qref của bộ điều khiển. Muốn sử dụng hết kích thước bộ đệm chỉ cần điều chỉnh qref. 2. Áp dụng cơ chế quản lý hàng đợi CQM thực hiện các lớp dịch vụ AF (AFij) cho mạng DiffServ. Trong đó, cấu hình giá trị tham chiếu qref khác nhau cho các bộ điều khiển khác nhau để tạo ra các lớp dịch vụ khác biệt AFij trong mỗi DiffServ router. Kết quả là tạo ra được các dịch vụ khác biệt một cách dễ dàng như dự kiến, điều chỉnh được một cách linh động. Bộ đệm ngõ ra được sử dụng với một mức ổn định theo cấu hình, không xảy ra hiện tượng nghẽn. Tài nguyên được sử dụng hiệu quả vì khi một lớp dịch vụ ở trạng thái không tải, tài nguyên đang giữ bị thu hồi để cấp cho lớp dịch vụ khác đang cần. 3. Đề xuất giải pháp CAC theo hướng phân tán cho DiffServ domain, gồm tập tiêu chuẩn quyết định cục bộ có bổ sung ràng buộc trên số luồng nhằm khắc phục mâu thuẩn cơ bản giữa đặc tính kết nối và không kết nối, và cơ chế báo hiệu kết nối không tường minh phù hợp với tiêu chuẩn quyết định cục bộ này để cộng tác thực thi thủ tục CAC. Kết quả là xác suất mất gói thấp, chỉ khoảng dưới - 32 - Hình 3.25 Đồ thị tương quan giữa xác suất mất gói và hiệu suất. Bảng 3.4 Các tham số của nguồn 2 (Expo2) Tham số Giá trị Packet size 125 bytes Burst time 400 ms Idle time 325 ms Data rate 64 kbps C. KẾT LUẬN VÀ KIẾN NGHỊ 1. Kết luận Luận án “Nghiên cứu cải thiện DiffServ QoS trong mạng IP” có các kết quả : 1. Đề xuất cơ chế quản lý hàng đợi CQM, trong đó lấy token bucket kết hợp với bộ điều khiển làm cơ chế điều khiển cục bộ tại router, điều khiển lưu lượng đổ vào bộ đệm theo nguyên lý phản hồi. - 5 - nghiên cứu các đề xuất cải tiến điển hình. Trên cơ sở đó xây dựng các giải pháp mới dùng công cụ toán học và mô phỏng máy tính để kiểm chứng, đúc kết nguyên lý áp dụng và tham gia hội thảo. Kết quả chính của luận án : + Đã làm rõ hiện trạng và xu thế cũng như cách thức thực hiện một hạ tầng QoS cho mạng IP theo kiến trúc DiffServ. Thiết nghĩ, trong điều kiện công nghệ chế tạo thiết bị mạng của nước ta còn chưa phát triển thì việc tìm hiểu để nắm bắt cách thức thực hiện các giải pháp cụ thể trên thiết bị là bước tiếp cận ban đầu hợp lý. + Đã đưa ra giải pháp thực hiện DiffServ mới. Trong đó, đã thiết kế cơ chế quản lý hàng đợi CQM dùng token bucket kết hợp với bộ điều khiển. Vận dụng CQM thực hiện được các lớp dịch vụ trong AF PHB một cách dễ dàng cùng với khả năng kiểm soát nghẽn chính qui hơn so với cơ chế dùng thuật toán RED, cách thực hiện này cũng tạo điều kiện để các lớp dịch vụ chia sẻ tài nguyên với nhau. + Đã phát triển phương pháp điều khiển chấp nhận kết nối cho DiffServ domain. Trong đó, đề xuất ý tưởng báo hiệu không tường minh, xây dựng tiêu chuẩn quyết định đặc trưng làm nền tảng. Cơ chế điều khiển chấp nhận kết nối mới vẫn đảm bảo được tính khả triển (scalability) vốn có của mạng DiffServ và - 6 - tạo triển vọng cung cấp end-to-end QoS cho mạng DiffServ một cách đơn giản. Luận án gồm 129 trang có bố cục như sau: Mở đầu : 8 trang Chương 1- Tổng quan IP QoS : 11 trang Chương 2- Các giải pháp chính cho QoS trong mạng IP hiện nay và những hạn chế : 26 trang Chương 3- Đề xuất các giải pháp nhằm cải thiện QoS cho mạng IP theo kiến trúc DiffServ: 54 trang 3.1 Cơ sở nghiên cứu và các mục tiêu chính : 2 trang 3.2 Giải pháp thực hiện AFij cho mạng DiffServ : 31 trang 3.3 Giải pháp điều khiển chấp nhận kết nối cho mạng DiffServ : 20 trang 3.4 Kết luận : 1 trang Kết luận và kiến nghị hướng phát triển : 3 trang Danh mục các công trình của tác giả : 2 trang Tài liệu tham khảo : 99 tài liệu tham khảo (11 trang) Luận án có 33 hình và 04 bảng B. NỘI DUNG Chương 1 - Tổng quan IP QoS 1.1 Giới thiệu IP QoS - 31 - s 0.5e-6, 0.6e-6, 0.7e-6, 0.8e-6, 0.9e-6, 1e- 6,1.1e-6, 1.2e-6, 1.3e-6, 1.4e-6, 1.5e-6, 1.6e-6, 1.7e-6, 1.8e-7 Mô phỏng được thực hiện đầu tiên với nguồn 1 (Expo1) với tham số s được thay đổi như trong bảng 3.2. Mô phỏng lại được thực hiện tiếp tục với nguồn 2 (Expo2) với tham số được mô tả trong bảng 3.3. Kết quả mô phỏng được trình bày trên hình 3.25. Trong trường hợp của nguồn 1, ta thấy rằng hiệu suất sử dụng liên kết đạt xấp xỉ 90% ứng với xác suất mất gói rất thấp. Khi hiệu suất đạt xấp xỉ 95% thì xác suất mất gói cũng chỉ khoảng 8,2.10-4. Điều này cho thấy việc sử dụng giải pháp CAC đã cải thiện được chất lượng dịch vụ qua giảm xác suất mất gói mà vẫn đảm bảo được hiệu suất sử dụng liên kết ở mức cao. So sánh kết quả giữa nguồn 1 và nguồn 2 thấy rằng sự khác biệt tỉ lệ giữa burst time và idle time cũng ảnh hưởng đến chất lượng phục vụ, cụ thể là khi tỉ lệ burst time lớn sẽ dẫn đến xác suất mất gói lớn hơn. Qua kết quả mô phỏng cũng chứng tỏ rằng tham số s thực sự đóng vai trò điều khiển nhằm tối ưu giữa hai tham số xác suất mất gói và hiệu suất sử dụng liên kết cho một nguồn xác định. - 30 - đầu 30 35.10-3 35.10-3 60 65.10-3 65.10-3 90 95.10-3 95.10-3 120 12,5.10- 3 12,5.10- 3 150 15,5.10- 3 15,5.10- 3 180 16,9.10- 3 18,5.10- 3 210 74,4.10- 3 21,5.10- 3 240 17.4.10- 2 24,5.10- 3 270 25,2.10- 2 27,5.10- 3 300 32,8.10- 2 1.10-4 330 35,4.10- 2 4,9.10-4 360 38,7.10- 2 36,5.10- 3 390 39,4.10- 2 10,3.10- 4 420 40,9.10- 2 42,5.10- 3 3.3.6.2 Đánh giá xác suất mất gói và hiệu suất sử dụng liên kết qua mô phỏng với các nguồn lưu lượng khác nhau Bảng 3.3 Các giá trị của s Tham số Các giá trị - 7 - Ngày nay IP là nền tảng cho mạng hội tụ đa dịch vụ. Chủ đề QoS trong mạng IP được quan tâm nghiên cứu dưới tên gọi IP QoS. Có bốn tham số đo lường chính của IP QoS là thông lượng (throughput), độ trễ (end-to-end delay), độ biến động trễ (jitter) và độ tổn thất gói (packet loss). 1.2. Phương thức cơ bản cung ứng QoS trong mạng IP Ba phương thức cơ bản thường dùng để hỗ trợ QoS trong mạng IP, đó là cung ứng có dự phòng cho mạng, xếp hàng và phân loại. 1.3. Cơ chế kiểm soát chất lượng mạng phổ biến cho mạng IP Ba nhóm cơ chế chính nhằm đạt được một chất lượng mạng tốt hơn mức “Best Effort” truyền thống trên mạng IP, đó là: - Cung cấp dung lượng vượt yêu cầu - Đăng ký trước tài nguyên: tiêu biểu là Intserv - Ưu tiên hóa các dịch vụ và người dùng: tiêu biểu là DiffServ Chương 2 -Các giải pháp chính cho QoS trong mạng IP hiện nay và những hạn chế 2.1 Phát triển IP QoS theo cơ chế DiffServ DiffServ là một tập hợp công nghệ cho phép nhà cung cấp dịch vụ mạng đưa ra các dịch vụ mạng khác - 8 - nhau cho khách hàng cũng như cho các dòng lưu lượng mạng của họ. Kiến trúc DiffServ chứa hai thành phần chính. Một là nguyên tắc ứng xử công bằng phổ quát trên từng bước gọi là PHB (per hop behaviors) và thứ hai là chính sách cấu hình các thông số trên đường dẫn chuyển gói cho từng PHB. Hiện có hai PHB được định nghĩa là EF (Expedited Forwarding), AF (Assured Forwarding). Công việc phát triển một hệ thống DiffServ liên quan đến tổ chức và phát triển hai thành phần chính là bộ điều chỉnh lưu lượng (traffic conditioner) tại router biên (edge router) và các PHB tại các router, đặc biệt là các router bên trong (core router). Mỗi PHB được thể hiện qua hai cơ chế: cơ chế quản lý hàng đợi và cơ chế lập lịch gói. Trong đó, nguyên lý quản lý hàng đợi tích cực RED (Random Early Detection) được dùng để quản lý hàng đợi cho DiffServ. Vì RED có thể hủy gói một cách ngẫu nhiên theo thông số xác suất qua thao tác cấu hình, nên có thể được dùng để thực hiện động thái AF (Assure Forwarding behavior) trong DiffServ. Theo các nghiên cứu cho thấy để hệ thống dùng RED ổn định cần phải chọn tham số hoạt động cho RED theo các tiêu chí nhất định và trong một phạm vi xác định của các yếu tố khách quan như cự ly truyền. - 29 - Bảng 3.1 Các tham số của nguồn 1 (Expo1) Tham số Giá trị Packet size 125 bytes Burst time 200 ms Idle time 200 ms Data rate 64 kbps Kết quả mô phỏng xác định xác suất mất gói (packet loss probability) trong trường hợp không có điều khiển chấp nhận kết nối được mô tả trong hình 3.23 và hình 3.24 mô tả xác suất mất gói khi có thủ tục CAC tham gia. Cụ thể hơn, bảng 3.2 đưa ra số liệu so sánh xác suất mất gói giữa hai trường hợp. Từ kết quả cho thấy, khi có cơ chế điều khiển chấp nhận kết nối, xác suất mất gói giảm đi rất nhiều so với trường hợp chạy DiffServ nguyên bản không CAC. Hình 3.23 Xác suất mất gói trong trường hợp không dùng giải pháp CAC. Hình 3.24 Xác suất mất gói trong trường hợp có dùng cơ chế CAC được đề nghị. Bảng 3.2 Bảng so sánh xác suất mất gói giữa hai trường hợp không dùng CAC và dùng CAC Thời điểm tính toán T (s), tính từ thời điểm ban Xác suất mất gói khi không dùng CAC Xác suất mất gói khi dùng CAC - 28 - 3.3.5 Hoạt động điều khiển chấp nhận kết nối theo phương pháp được đề xuất Mỗi user với cấp dịch vụ đã thỏa thuận trước với ISP trong hợp đồng lưu lượng (SLA), dùng thủ tục báo hiệu gửi yêu cầu tạo kết nối không tường minh với đối tác. Kết nối không tường minh chỉ được chấp nhận khi tất cả các router liên quan đều thỏa điều kiện CAC. Các router sẽ áp dụng tiêu chuẩn quyết định đã được xây dựng để thực hiện thủ tục CAC cục bộ trên từng lớp dịch vụ. 3.3.6 Kết quả của giải pháp được đề xuất Hình 3.22 Sơ đồ mạng thực hiện mô phỏng. Sơ đồ mạng mô phỏng như hình 3.22. Chương trình được viết bằng ngôn ngữ OTcl và C++ được biên dịch bằng gcc trong NS-2 phiên bản 2.29. 3.3.6.1 Kết quả mô phỏng và so sánh với hệ thống hiện hữu Dùng mô hình nguồn đóng-ngắt (ON-OFF) với thời gian đóng ngắt tuân theo phân bố mũ như mô tả trong bảng 3.1. Đích Nguồn Ingress router Core router 10Mbps 10Mbps Egress router - 9 - Điều này không phải lúc nào cũng dễ dàng trên mạng thực tế, khi mà nhu cầu kết nối cũng như lưu lượng luôn biến động. Đây cũng là lý do vì sao các triển khai DiffServ hiện nay vẫn chưa thực hiện một cách đầy đủ các dịch vụ như trong đặc tả. DiffServ vẫn đang cần có các giải pháp thực tế hơn để việc triển khai được dễ dàng và hoạt động bền vững hơn. 2.3 Vấn đề quản lý đăng ký tài nguyên trong mạng DiffServ Kiến trúc DiffServ không đảm bảo một QoS từ đầu cuối đến đầu cuối (end-to-end QoS) vì không có cơ chế quản lý đăng ký tài nguyên. Trong nỗ lực cải thiện sự yếu kém này, có nhiều đề xuất bổ sung cơ chế kiểm soát đăng ký tài nguyên cho DiffServ hay còn gọi là điều khiển chấp nhận các yêu cầu QoS từ người dùng. Các giải pháp được đề nghị cho đến nay thể hiện thành hai nhóm: tập trung và phân tán. Trong đó, giải pháp tập trung đưa ra khái niệm Bandwidth Broker, tuy nhiên giải pháp này vấp phải khuyết điểm là tạo ra một điểm lỗi nhạy cảm cho toàn bộ hệ thống. Giải pháp RMD, PBAC, GRIP và PCN mang tính tiêu biểu cho các giải pháp điều khiển chấp nhận phân tán. Tuy nhiên, các giải pháp này vẫn còn tồn tại các hạn chế cần phải vượt qua để trở thành hiện thực. Bổ sung cơ chế điều khiển chấp nhận cho DiffServ là điều - 10 - hiển nhiên và hết sức cấp thiết nhằm đạt được một giải pháp QoS hoàn chỉnh cho mạng IP. 2.4 Phát triển IP QoS trên nền MPLS MPLS giải quyết vấn đề QoS cho mạng IP bằng cách thiết lập các đường dẫn tường minh qua mạng. Các đường dẫn được gọi là LSP (Label Switching Path) cung cấp một phương tiện để đảm bảo một chất lượng dịch vụ đặc biệt. Để hỗ trợ DiffServ, có thể linh hoạt ánh xạ các BA (Behavior Aggregate) vào các đường dẫn LSP sao cho phù hợp nhất. Chương 3 - Đề xuất các giải pháp nhằm cải thiện QoS cho mạng IP theo kiến trúc DiffServ 3.1 Cơ sở nghiên cứu và các mục tiêu chính Dựa vào mô hình toán học và mô phỏng máy tính để nghiên cứu đề xuất giải pháp thực hiện AFij mà không dùng RED và đề xuất giải pháp điều khiển chấp nhận nối cho mạng DiffServ tránh các hạn chế của hai giải pháp tiêu biểu như RMD, PBAC, GRIP và PCN. 3.2 Giải pháp thực hiện AFij cho mạng DiffServ 3.2.1 Giới thiệu đề xuất Theo đặc tả kiến trúc DiffServ thì AF PHB phức tạp hơn EF PHB, AF PHB có đến bốn lớp con và trong mỗi lớp con lại được chia ra thành ba mức ưu tiên, như vậy AF PHB có 12 mức dịch vụ, ở đây tạm gọi là các AFij trong đó iÎ[0,3] và jÎ[0,2], việc thực hiện các AFij này vẫn còn hạn chế và phụ thuộc nhiều - 27 - các router như sau: (các chi tiết được trình bày bên trong cuốn luận án) ( ) ï ï ï î ï ï ï í ì m£÷ ø ö ç è æ +× × - m £+ m ^ sp m sp rSe r e 1 2 1 1n (s>0) (3.30) Trong đó: n là số luồng được chấp nhận µ là dung lượng đầu ra được gán cho lớp tương ứng tại router Ŝ là tải hiện hành ước lượng được rm là tốc độ trung bình của nguồn lưu lượng yêu cầu đăng ký p là tốc độ đỉnh s là tham số điều khiển, s qui định giới hạn băng thông được dùng hay (ŝ + r)max= n.m Như đã nói trong mục đích thiết kế ban đầu, mỗi router sẽ giữ một tham số n để chỉ ra số luồng đã được chấp nhận, một luồng mới với tốc độ yêu cầu rm được chấp nhận nếu n và rm thỏa mãn đồng thời hệ bất đẳng thức trên. Tham số s đóng vai trò là tham số điều khiển trong cơ chế điều khiển chấp nhận kết nối và được xác định tùy vào hệ số n. - 26 - dấu, egress router sẽ gửi thông báo không chấp nhận cho ingress router (hình 3.21) . Hình 3.21 Thủ tục báo hiệu khi yêu cầu bị từ chối. Thủ tục cần sử dụng các gói điều khiển chính như sau: Request packet, Accept packet, Reject packet, Release packet, Clear packet, Confirm packet. 3.3.3 Phương pháp ước lượng tải tại DiffServ router Trong phương pháp được đề xuất trong luận án này sẽ áp dụng phương pháp ước lượng tải được công bố bởi S. Jamin. Mỗi router phải ước lượng tài nguyên bị chiếm bởi các luồng hiện hành, gọi là ŝ, đây là tham số đầu vào của tập quyết định trong thủ tục CAC. 3.3.4 Xây dựng tiêu chuẩn quyết định Phần này đã áp dụng Chernoff bound cho các phân bố của một tổng các biến ngẫu nhiên độc lập để phân tích và xây dựng được tiêu chuẩn quyết định cho QoS request Request packet Request packet Marked request packet Reject packet Clear packet Không đủ tài nguyên n+1 n+1 n-1 n-1 Ingress router Egress router Core Router Core Router - 11 - vào thuật toán RED. Phương pháp được đề nghị ở đây xuất phát từ hai ý tưởng sau: - Đưa bộ điều khiển vào tham gia quản lý hàng đợi. - Dùng thuật toán token-bucket có tốc độ token linh động để thực hiện chức năng giám sát và hủy gói. Trên cơ sở đó xây dựng nên cơ chế quản lý hàng đợi mới, đặt tên là cơ chế quản lý hàng đợi có thể điều khiển được, dịch sang tiếng Anh là CQM (Controllabe Queue Management). Dùng cơ chế CQM để thay thế cho cơ chế AQM (Active Queue Management) và do đó không dùng RED nữa. Phần cơ bản của phương pháp là cơ cấu gồm token bucket và bộ điều khiển tạo thành cặp gắn kết cho cơ chế, trong đó token bucket sẽ chịu trách nhiệm giám sát và hủy gói tùy vào số token mà nó đang có, còn bộ điều khiển sẽ điều khiển tốc độ luồng token đổ vào token bucket tùy vào chiều dài hàng đợi. Việc thay đổi mức tham chiếu của bộ điều khiển sẽ là điểm then chốt để thực hiện các lớp con khác nhau của AF PHB. 3.2.2 Thiết kế cơ chế quản lý hàng đợi CQM bằng token bucket và bộ điều khiển Sơ đồ nguyên lý được trình bày trên hình 3.8. Lượng gói số liệu đi vào hàng đợi trong khoảng thời gian nào đó tùy vào khả năng tích lủy token của token - 12 - bucket trong khoảng thời gian đó. Vì vậy, để quản lý lưu lượng đi vào hàng đợi thì phải kiểm soát tốc độ dòng token đổ vào token bucket. Điều chỉnh tốc độ token hợp lý sẽ quản lý được hàng đợi một cách hiệu quả và ngăn chặn được tình trạng tắc nghẽn. Hình 3.8 Mô hình hoạt động của cơ chế quản lý hàng đợi dùng token bucket và bộ điều khiển. Tính hợp lý đặt ra ở đây xoay quanh mục tiêu là khi kích thước hàng đợi còn trống càng nhỏ thì lưu lượng đổ vào hàng đợi phải càng ít và do đó tốc độ token cũng phải càng nhỏ. Kịch bản này hoàn toàn phù hợp với vai trò của một bộ điều khiển. Vì vậy, công việc điều chỉnh tốc độ token này được giao cho bộ điều khiển, bộ điều khiển được đặt ở khoảng giữa hàng đợi và token bucket. Căn cứ vào độ lệch giữa mức tham chiếu được cấu hình và kích thước của hàng đợi, bộ điều khiển sẽ phát ra tốc độ token phù hợp để sử dụng y(t) q(t) u(t) r(t) v(t) b C Bộ điều khiển qref - 25 - Hình 3.20 Thủ tục báo hiệu kết nối với yêu cầu được chấp nhận. Hình 3.20 mô tả hoạt động của thủ tục báo hiệu kết nối không tường minh trong trường hợp yêu cầu kết nối được chấp nhận. Khi user gửi yêu cầu đến ingress router thì router này sẽ phát ra gói yêu cầu để thăm dò domain, nếu một core router có đủ tài nguyên để chấp nhận thì nó tiếp tục chuyển yêu cầu này đến router kế tiếp và tăng tham số n lên một đơn vị, ngược lại nếu không đáp ứng yêu cầu thì router phải đánh dấu gói bằng cách dựng một bit cờ và chuyển gói này đi tiếp. Nếu router nhận được gói bị đánh dấu thì sẽ chuyển gói đi tiếp mà không làm công việc nào khác. Ở egress router khi nhận một gói yêu cầu chưa bị đánh dấu, nếu có đủ tài nguyên thì sẽ tăng tham số n lên một đơn vị và gửi thông báo chấp nhận cho ingress router biết. Ngược lại nếu nhận gói yêu cầu bị đánh - 24 - 3.3.2 Thiết kế cơ chế báo hiệu cho kết nối không tường minh 3.3.2.1 Khái niệm kết nối không tường minh Trên thực tế có trường hợp hai thực thể truyền thông có thể trao đổi thông tin với nhau nhưng giữa chúng không có một kết nối rõ ràng nào. Trong trường hợp này có thể xem hai thực thể truyền thông được nối với nhau bằng một kết nối không tường minh. 3.3.2.2 Thiết kế cơ chế báo hiệu kết nối không tường minh cho môi trường DiffServ Về cơ bản thì thủ tục báo hiệu là giữa ingress router và egress router nhằm hỏi DiffServ domain có cho một kết nối không tường minh hay không. Trong chế độ họat động không kết nối, core router chấp nhận một luồng mới nhưng tải thực sự của luồng này có thể được định tuyến qua router khác và router lại có thể tiếp tục cho phép nhiều luồng mới vì tải thực tế qua nó vẫn còn trong hạn định. Điều này dẫn đến tình trạng quá tải trong domain. Giải pháp được nghiên cứu sinh đưa ra là bổ sung một ràng buộc (hay luật) vào tập tiêu chuẩn quyết định CAC dựa trên số luồng hiện hành được router cho phép. Để tạo điều kiện thực hiện ràng buộc bổ sung này, các DiffServ router phải theo dõi số lượng luồng đã chấp nhận, gọi là n. Ingress router Core Router Egress router QoS request Request packet Request packet Request packet Accept packet n+1 n+1 n+1 n+1 Core Router - 13 - hàng đợi hiệu quả và không để xảy ra tình trạng hàng đợi bị tràn. Biểu diễn toán học theo mô hình luồng động của cơ cấu này như sau: (phân tích động học được trình bày chi tiết trong cuốn luận án) ( ) )t(uC)0)t(q(1tq +×>-= · ( ) ( )( ) ( ) ( )úû ù êë é +×>= T ty tr0tv1tu (3.1) 3.2.3 Áp dụng cơ chế quản lý hàng đợi CQM gồm token bucket-controller để thực hiện các AFij trong mạng IP DiffServ 3.2.3.1 Nguyên lý và kiến trúc thực hiện AFij tại các DiffServ router dùng token bucket_controller Mục tiêu chính ở đây là thực hiện các lớp PHB phụ (subclass) hay AFij trong mỗi lớp AF. Theo kiến trúc DiffServ thì mỗi lớp AF có ba lớp phụ ứng với ba mức bị chọn để hủy khác nhau. Vì việc thực hiện các AFij là giống nhau trong các lớp AF nên ở đây chỉ trình bày phương pháp thực hiện trong một lớp AF. Sơ đồ nguyên lý được mô tả trên hình 3.13. Mỗi AFij được thực hiện bằng cơ chế quản lý hàng đợi có điều khiển CQM gồm một token bucket hai trạng thái (có tích hợp trạng thái luôn đầy) và một bộ điều khiển. Như vậy trong mỗi lớp AF sẽ có ba bộ token bucket-controller. Hệ thống này được thiết kế để có hai chế độ hoạt động tách biệt gọi là chế độ hoạt - 14 - động tự do và chế độ hoạt động có ràng buộc. Chế độ hoạt động tự do ứng với các khóa K chuyển đến vị trí 0 để kết nối với token bucket luôn đầy CTB (constant token bucket). Token bucket luôn đầy luôn có đầy đủ token để chuyển gói số liệu đi. Vì vậy trong chế độ hoạt động tự do, các gói IP từ tất cả các lớp phụ AFij đều được chuyển đi mà không bị bất kỳ hạn chế nào. Chế độ hoạt động này nhắm đến thỏa mãn các nhu cầu của lưu lượng AF đã được định chế tại các router biên (theo hợp đồng lưu lượng) trong điều kiện mức độ tải tại router còn nhẹ. - 23 - nhưng chiều dài hàng đợi gia tăng và đạt ổn định tại một mức xác định xấp xỉ 280. Điều này chứng tỏ đã đảm bảo điều khiển nghẽn cho hàng đợi đầu ra. 3.3 Giải pháp điều khiển chấp nhận kết nối cho mạng DiffServ 3.3.1 Giới thiệu đề xuất Vì các mạng DiffServ hoạt động theo chế độ không tạo kết nối (connectionless), do đó các router có thể mắc lỗi khi chấp nhận quá nhiều luồng mới nếu nó chỉ dựa vào đo lường trên tải hiện hành để thực hiện chức năng đăng ký. Chưa có một giải pháp nào chú ý đến vấn đề này và đây cũng là lý do tại sao RMD, PBAC, GRIP và PCN vấp phải các hạn chế. Trong phần này sẽ đề xuất một giải pháp điều khiển chấp nhận kết nối có thể tránh được các hạn chế của các giải pháp khác nhờ tập trung khắc phục vấn đề nêu trên. Cụ thể là sẽ bổ sung ràng buộc vào tiêu chuẩn quyết định trong CAC để hạn chế sự cho phép quá mức số luồng. Giải pháp được đề nghị gồm có hai phần chính: - Cơ chế báo hiệu cho kết nối không tường minh. - Tiêu chuẩn quyết định cho các DiffServ router thực hiện CAC. Phương pháp điều khiển chấp nhận kết nối ở đây được phát triển để hoạt động cho từng PHB riêng biệt nhằm tương thích với môi trường DiffServ. - 22 - a. Động thái của u1(t) b. Động thái của u2(t) c. Động thái của u3(t) d. Động thái của q(t) Hình 3.19 Động thái của các thành phần trong cơ cấu. Từ kết quả trên hình 3.19 dễ dàng nhận thấy, u2(t) và u3(t) giảm nhanh xuống 0 tương ứng với tất cả các gói đến bị hủy hay đánh dấu, như hình 3.19b và 3.19c. Trong đó, nếu để ý sẽ thấy u3(t) giảm nhanh hơn u2(t) và tiếp cận 0 sớm hơn. Điều này có nghĩa là AFi3 hủy gói một cách triệt để trước khi AFi2 làm công việc tương tự. Cũng nhận ra rằng tốc độ u1(t) của AFi1 giảm nhưng vẫn lớn hơn 350 vì đây là lớp có ưu tiên cao nhất (xem hình 3.19a). Kế tiếp, động thái của hàng đợi đầu ra được thể hiện trên hình 3.19d cho thấy mặc dù lượng tải lớn - 15 - Hình 3.13 Sơ đồ nguyên lý thực hiện AFij trong một lớp AF. Khi hệ thống rơi vào tình trạng có nguy cơ bị nghẽn, thành phần được gọi là bộ giám sát AF (AF monitor) sẽ chuyển khóa K sang vị trí 1 để nối vào token bucket bên trái, tương ứng với token bucket chuyển sang làm việc ở trạng thái thông thường của nó. Lúc này, hệ thống sẽ vào chế độ hoạt động có ràng Controller b2 y2(t) qref2 AFi2 Controller b1 y1(t) qref1 AFi1 Controller b3 y3(t) qref3 AFi3 u1(t) u2(t) u3(t) r1(t) r3(t) r2(t) Output C q(t) B Constant Token Bucket Constant Token Bucket Constant Token Bucket 0 1 K 0 1 K 0 1 K v1(t) v2(t) v3(t) AF Monitor - 16 - buộc. Trong chế độ ràng buộc, lưu lượng của các lớp phụ AFij chịu sự quản lý của token bucket trong sự cộng tác với bộ điều khiển. Bộ điều khiển sẽ lấy thông tin về chiều dài hiện hành của hàng đợi qua cơ cấu phản hồi, từ đó phát ra một tốc độ token hợp lý sao cho không để hàng đợi bị nghẽn. Token bucket sẽ hủy hay đánh dấu các gói IP đến nếu không có đủ token để chuyển chúng vào hàng đợi chung ở đầu ra. Mức hủy gói của mỗi token bucket thực sự là cụ thể hóa mức độ bị chọn để hủy (drop precedence) của AFij và mức hủy này là khác nhau giữa các AFij. Trong hệ thống này, kích thước hàng đợi tham chiếu qref (thông số được cấu hình) được dùng như tham số then chốt để tạo nên các mức hủy gói khác nhau. Giá trị tham chiếu này càng lớn thì mức hủy gói càng nhỏ. Do đó, sẽ cấu hình (gán) qref1>qref2>qref3 nếu như AFi1, AFi2 và AFi3 lần lượt là dịch vụ vàng (Gold service), dịch vụ bạc (Silver service) và dịch vụ đồng (Bronze service). Các giá trị của qref tùy thuộc vào mức độ khác biệt muốn tạo ra giữa các lớp phụ AFij của nhà cung cấp dịch vụ. 3.2.3.4 Mô hình động học của cơ cấu thực hiện các AFij Động học của hệ thống theo mô hình luồng động được biểu diễn như sau: - 21 - Hình 3.18- Cải thiện hiệu quả sử dụng khi nâng mức tham chiếu qref. 3.2.4.2 Kết quả mô phỏng và đánh giá phương pháp thực hiện AFij được đề xuất Để minh chứng cho tính khả thi của giải pháp thực hiện AFij được đề xuất, hệ thống đã được mô phỏng trên máy tính dùng phần mềm Matlab. Mục đích của mô phỏng gồm: kiểm chứng sự khác biệt giữa các AFij trong hệ thống, khảo sát tính ổn định của hệ thống và khả năng điều khiển nghẽn. Quá trình khảo sát tập trung vào biểu hiện của tốc độ lưu lượng đầu ra của token bucket hay các ui(t), biểu hiện động thái của hàng đợi