Nghiên cứu cải thiện diffserv qos trong mạng ip (tt)

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