Đang tải... (xem toàn văn)
Nghiên cứu cải thiện DIFFSERV QoS trong mạng IP. Học viện Công nghệ Bưu chính Viễn thôngHọc viện Công nghệ Bưu chính Viễn thôngHọc viện Công nghệ Bưu chính Viễn thông.Nghiên cứu cải thiện DIFFSERV QoS trong mạng IP
- 1 - TẬP ĐOÀN BƯU CHÍNH VIỄN THÔNG VIỆT NAM HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG NGUYỄN HỒNG SƠN Nghiên cứu cải thiện DIFFSERV QoS trong mạng IP Tóm tắt Luận án TS Kỹ thuật: Kỹ thuật Viễn thông Mã số chuyên ngành 62 52 70.05 Người hướng dẫn: PGS.TS Lê Hữu Lập, TS Vũ Như Lân Hà Nội, 2010 - 2 - A. MỞ ĐẦU Ngày nay, mạng IP có vai trò thiết yếu trong lĩnh vực truyền thông. Sự phát triển nhanh chóng của Internet đã làm cho mạng IP trở thành giao thức không 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 q ref 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 q ref . 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 (AF ij ) 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 AF ij 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 - hin nhiờn v ht sc cp thit nhm t c mt gii phỏp QoS hon chnh cho mng IP. 2.4 Phỏt trin IP QoS trờn nn MPLS MPLS gii quyt vn QoS cho mng IP bng cỏch thit lp cỏc ng dn tng minh qua mng. Cỏc ng dn c gi l LSP (Label Switching Path) cung cp mt phng tin m bo mt cht lng dch v c bit. h tr DiffServ, cú th linh hot ỏnh x cỏc BA (Behavior Aggregate) vo cỏc ng dn LSP sao cho phự hp nht. Chng 3 - xut cỏc gii phỏp nhm ci thin QoS cho mng IP theo kin trỳc DiffServ 3.1 C s nghiờn cu v cỏc mc tiờu chớnh Da vo mụ hỡnh toỏn hc v mụ phng mỏy tớnh nghiờn cu xut gii phỏp thc hin AFij m khụng dựng RED v xut gii phỏp iu khin chp nhn ni cho mng DiffServ trỏnh cỏc hn ch ca hai gii phỏp tiờu biu nh RMD, PBAC, GRIP v PCN. 3.2 Gii phỏp thc hin AFij cho mng DiffServ 3.2.1 Gii thiu xut Theo c t kin trỳc DiffServ thỡ AF PHB phc tp hn EF PHB, AF PHB cú n bn lp con v trong mi lp con li c chia ra thnh ba mc u tiờn, nh vy AF PHB cú 12 mc dch v, õy tm gi l cỏc AFij trong ú iẻ[0,3] v jẻ[0,2], vic thc hin cỏc AFij ny vn cũn hn ch v ph thuc nhiu - 27 - cỏc router nh sau: (cỏc chi tit c trỡnh by bờn trong cun lun ỏn) ( ) ù ù ù ợ ù ù ù ớ ỡ mÊ ữ ứ ử ỗ ố ổ +ì ì - m Ê+ m ^ sp m sp rSe r e 1 2 1 1n (s>0) (3.30) Trong ú: n l s lung c chp nhn à l dung lng u ra c gỏn cho lp tng ng ti router l ti hin hnh c lng c r m l tc trung bỡnh ca ngun lu lng yờu cu ng ký p l tc nh s l tham s iu khin, s qui nh gii hn bng thụng c dựng hay ( + r) max = n .m Nh ó núi trong mc ớch thit k ban u, mi router s gi mt tham s n ch ra s lung ó c chp nhn, mt lung mi vi tc yờu cu r m c chp nhn nu n v r m tha món ng thi h bt ng thc trờn. Tham s s úng vai trũ l tham s iu khin trong c ch iu khin chp nhn kt ni v c xỏc nh tựy vo h s n . [...]... 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 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 các DiffServ router dùng token bucket_controller Trong chế độ họat động không kết nối, core router Mục... bucket luôn đầy luôn có đầy đủ 3.3 Giải pháp điều khiển chấp nhận kết nối cho token để chuyển gói số liệu đi Vì vậy trong chế độ mạng DiffServ hoạt động tự do, các gói IP từ tất cả các lớp phụ AFij 3.3.1 Giới thiệu đề xuất đều được chuyển đi mà không bị bất kỳ hạn chế nào Vì các mạng DiffServ hoạt động theo chế độ không Chế độ hoạt động này nhắm đến thỏa mãn các nhu cầu tạo kết nối (connectionless),... (subclass) hay AFij trong mỗi lớp AF Theo kiến trúc này có thể được định tuyến qua router khác và router DiffServ thì mỗi lớp AF có ba lớp phụ ứng với ba lại có thể tiếp tục cho phép nhiều luồng mới vì tải thực mức bị chọn để hủy khác nhau Vì việc thực hiện các tế qua nó vẫn còn trong hạn định Điều này dẫn đến AFij là giống nhau trong các lớp AF nên ở đây chỉ tình trạng quá tải trong domain Giải pháp... Confirm packet thành cặp gắn kết cho cơ chế, trong đó token bucket sẽ 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... bày phương pháp thực hiện trong một lớp AF Sơ nghiên cứu sinh đưa ra là bổ sung một ràng buộc (hay đồ nguyên lý được mô tả trên hình 3.13 luật) vào tập tiêu chuẩn quyết định CAC dựa trên số Mỗi AFij được thực hiện bằng cơ chế quản lý hàng luồng hiện hành được router cho phép Để tạo điều đợi có điều khiển CQM gồm một token bucket hai kiện thực hiện ràng buộc bổ sung này, các DiffServ trạng thái (có tích... thường của hiện trên hình 3.19d cho thấy mặc dù lượng tải lớn nó Lúc này, hệ thống sẽ vào chế độ hoạt động có ràng - 16 - - 21 - buộc Trong chế độ ràng buộc, lưu lượng của các lớp Hình 3.18- Cải thiện hiệu quả sử dụng khi nâng mức phụ AFij chịu sự quản lý của token bucket trong sự tham chiếu qref cộng tác với bộ điều khiển Bộ điều khiển sẽ lấy thông 3.2.4.2 Kết quả mô phỏng và đánh giá phương tin về chiều... điều (3.13) Đề nghị 1 có mục đích đơn giản là tạo ra một khiển nghẽn cũng như cải thiện hiệu quả sử dụng tài khoảng không gian dự phòng trên hàng đợi cho trường Động thái của chiều dài hàng đợi q(t) được trình nguyên hợp có lượng gói nhập quá mức do số token thừa bày trên hình 3.16, hình cho thấy số lượng gói trong Đề nghị 2: Trong chế độ hoạt động có ràng buộc, để hàng đợi thoạt đầu tăng nhanh lên đến... biên mắc lỗi khi chấp nhận quá nhiều luồng mới nếu nó chỉ (theo hợp đồng lưu lượng) trong điều kiện mức độ tải dựa vào đo lường trên tải hiện hành để thực hiện chức tại router còn nhẹ 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... 17 - · q (t ) = - 1(q ( t ) > 0) × C + b=20 å u (t ) 3 i i =1 é u (t ) = 1(v (t ) > 0) × êr (t ) i i ê ë i y (t )ù + i ú T ú û (3.7) Trong đó, T là khoảng thời gian truyền liên tục và C là băng thông của liên kết đầu ra Giá trị C này sẽ Tuy nhiên, chúng ta có thể cải thiện được tình trạng này một cách dễ dàng nếu như ép qref thêm một lượng thích hợp Lúc này tham số qref có thể đóng vai trò như một... tổng quát, ở đây sẽ đánh giá hệ thống theo trường hợp xấu nhất này Do đó, động học của hàng đợi cổ chai là chai mà còn giúp cải thiện hiệu suất sử dụng · q (t ) = - 1(q ( t ) > 0) C + å 1(v (t ) > 0) × [r (t ) 3 i =1 i i + y ( t)] i (3.9) (các phân tích chi tiết được trình bày trong cuốn luận án) 3.2.3.5 Điều kiện áp dụng CQM vào thực hiện AFij và hệ quả - 18 - - 19 - Đề nghị 1: Giả sử hàng đợi có kích