Giải pháp đảm bảo chất lượng dịch vụ trên mạng IP, đánh giá và so sánh hiệu quả đảm bảo QoS của Diffserv và Intserv

yên cho các luồng dữ liệu đơn hướng;  RSVP là cơ chế hướng về phía nhận, nghĩa là phía nhận dữ liệu khởi tạo và duy trì giữ trước tài nguyên sử dụng cho luồng dữ liệu đó;  RSVP duy trì “trạng thái mềm” tại Router và Host, hỗ trợ cho sự thay đổi linh hoạt về định tuyến;  RSVP chuyển tải và duy trì các tham số điều khiển lưu lượng và điều khiển chính sách;  RSVP cung cấp một số mô hình giữ trước tài nguyên để tương thích với các ứng dụng khác nhau;  RSVP hoạt động trong suốt với các router không hỗ trợ nó;  RSVP hỗ trợ cho cả các giao thức IPv4 và IPv6. 63 3.1.2.6 RSVP và IntServ RSVP gần đồng nhất với IntServ [7], [23], vì hiện tại nó mới chỉ chuyển tải các tham số IntServ được chuẩn hóa. RSVP hỗ trợ hai loại dịch vụ mô hình IntServ đưa ra là dịch vụ tải có điều khiển và dịch vụ cam kết. 3.1.2.6.1 Dịch vụ tải có điều khiển Các đối tượng xuất hiện trong bản tin PATH cho dịch vụ tải có điều khiển được mô tả sau đây: Bảng 3.4. Các tham số của các đối tượng CL khác nhau Đối tượng RSVP Tham số Mô tả Các đơn vị Địa chỉ đích Địa chỉ IP đơn hướng/đa hướng - Cổng IP Giao thức IP như UDP hoặc TCP - Mẫu gửi Cổng đích Số cổng đích - R Tốc độ gầu thẻ bài Byte/giây B Kích thước gầu thẻ bài Bytes P Tốc độ đỉnh Byte/giây m Đơn vị kiểm tra tối đa Bytes Đặc tính lưu lượng phía gửi (Sender Tspec) M Kích thước gói tối đa Bytes Các đối tượng RSVP trong các bản tin RESV giống như các đối tượng trong bản tin PATH, nhưng giá trị của các tham số có thể khác. Dịch vụ tải có điều khiển (CL) không sử dụng Rspec trong các bản tin RESV. Ba tham số đầu trong Tspec dùng để điều khiển thu nhận và kiểm soát. 3.1.2.6.2 Dịch vụ cam kết Các đối tượng được xác định khi yêu cầu dịch vụ cam kết được đưa ra như dưới đây. Chúng giống như dịch vụ tải có điều khiển và bổ sung thêm tham số Rspec. Bảng 3.5. Các tham số của dịch vụ cam kết Rspec Đối tượng RSVP Tham số Mô tả Đơn vị Rspec R Tốc độ Byte/giâp S Stack term Ms Ở đây, r liên quan tới đặc tính của lưu lượng còn R liên quan tới đặc tính của dành trước tài nguyên. Bằng cách chọn R>r chúng ta sẽ giảm được trễ hàng đợi. Tham số S biểu thị sự khác nhau giữa trễ mong muốn và trễ có được từ việc sử dụng dành trước thời gian. 64 3.2 MÔ HÌNH DỊCH VỤ PHÂN BIỆT - DIFFSERV 3.2.1 Tổng quan về mô hình DiffServ Trong phiên họp tháng 8 năm 1997, nhóm IETF đã đề xuất mô hình DiffServ [21] như một giải pháp QoS có tính khả thi cao hơn và xác định rõ yêu cầu cho dịch vụ phân biệt (DiffServ) với việc phát triển các chuẩn cho phương pháp này. Mô hình dịch vụ phân biệt DiffServ thừa nhận một khía cạnh trái ngược với IntServ. Vấn đề tồn tại của IntServ là các nguồn tài nguyên cần phải được duy trì trạng thái thông tin theo từng luồng, điều này trở nên khó khả thi đối với mạng có số lượng dịch vụ và số lượng thiết bị mạng lớn vì bộ định tuyến cần phải xử lý lưu lượng rất lớn trong mạng. Cách tiếp cận của DiffServ không xử lý theo từng luồng lưu lượng riêng biệt mà ghép chúng vào một số lượng hạn chế các lớp lưu lượng. DiffServ hướng tới xử lý trong từng dịch vụ phân biệt thay vì xử lý từ đầu cuối tới đầu cuối như mô hình IntServ. DiffServ định nghĩa một số tham số mà người sử dụng hiểu rõ cho ứng dụng của họ trong SLA như thỏa thuận về điều kiện lưu lượng TCA (Traffic Conditioning Agreement), hồ sơ lưu lượng (tham số của gáo rò token), các tham số hiệu năng (thông lượng, độ trễ, mất gói), cách thức xử lý các gói tin không phù hợp với thỏa thuận, luật đánh dấu và chia cắt lưu lượng. Trong mô hình DiffServ, các bộ định tuyến được chia làm hai loại: các bộ định tuyến biên nằm ở đường vành của tổ chức mạng có chức năng DiffServ; các bộ định tuyến lõi nằm bên trong tổ chức mạng có chức năng DiffServ. Đối với mô hình DiffServ các bộ định tuyến biên làm nhiệm vụ xử lý từng luồng IP vi mô. Các bộ định tuyến lõi thay vì phải xử lý số lượng rất lớn các luồng IP như trong cấu trúc IntServ, chỉ phải xử lý một vài luồng IP tổng. Luồng IP tổng chứa tất cả các gói của các luồng IP vi mô thuộc về cùng một chủng loại.[24] Hình 3.7. Tổng quan mô hình DiffServ 65 Mô hình DiffServ tại biên và lõi của mạng được mô tả cụ thể như sau: Hình 3.8. Mô hình DiffServ tại biên và lõi của mạng Mô hình này bao gồm một số thành phần như sau: DS-byte: byte xác định DiffServ là thành phần ToS của IPv4 và trường loại lưu lượng IPv6. Các bit trong byte này thông báo gói tin được mong đợi nhận được thuộc dịch vụ nào. Các thiết bị biên: nằm tại lối vào hay lối ra của mạng cung cấp DiffServ. Các thiết bị bên trong mạng DiffServ Quản lý cưỡng bức: các công cụ và nhà quản trị mạng giám sát và đo kiểm đảm bảo SLA giữa mạng và người dùng. Cơ chế DiffServ đưa ra sự phân loại cho 3 loại hình dịch vụ: dịch vụ ưu tiên, dịch vụ đảm bảo, dịch vụ ứng biến theo khả năng tối đa (dịch vụ được cung cấp bởi mạng Internet hiện nay). Đối với mỗi loại dịch vụ, DiffServ định nghĩa cách thức xử lý các gói IP tại các bộ định tuyến lõi. Gói IP của dịch vụ ưu tiên nhận được cách xử lý chuyển tiếp nhanh (EF-PHB - Expedited Forwarding-Per Hop Behaviour), đối với gói IP của dịch vụ đảm bảo nhận được cách xử lý chuyển tiếp đảm bảo (AF-PHB - Assured Forwarding-Per Hop Behaviour). Nguyên lý hoạt động của DiffServ: Khi bắt đầu đi vào mạng DiffServ tại bộ định tuyến biên, gói tin IP sẽ được phân loại. Bộ định tuyến biên thực hiện việc phân loại bằng cách kiểm tra mã DSCP (DiffServ Code Point) chứa chủng loại dịch vụ nằm trong phần đầu gói cùng với một số dữ liệu khác liên quan tới luồng vi mô của gói IP (địa chỉ đầu gửi, địa chỉ đầu nhận). Các gói tin đến bộ định tuyến có thể đã được đánh dấu hoặc chưa đánh dấu, bộ định tuyến xác định điểm mã điều khiển dịch vụ DSCP của gói tin và phân loại các gói tin theo phương pháp phân loại kết hợp hành vi BA. Các gói tin phân loại thành các lớp BA được chuyển tiếp theo hành vi từng bước PHB (Per Hop Behavior) được định nghĩa trước cho các BA. Mỗi PHB được thể hiện bởi giá trị DSCP và xử lý giống nhau đối với các gói tin trong cùng lớp BA. 66 Hình 3.9. Mô hình các bước dịch vụ phân biệt DiffServ Sau khi chủng loại của gói IP được xác định, bộ định tuyến biên sẽ áp dụng một số giải pháp điều chỉnh tiếp theo cho gói tin nếu cần thiết. Tùy thuộc vào mức độ tuân thủ cụ thể của gói IP và mức độ chặt chẽ của DiffServ, giải pháp được bộ định tuyến biên sử dụng có thể là đánh dấu gói, điều chỉnh gói (loại bỏ gói hoặc làm trễ gói một thời gian nhất định trước khi chuyển tiếp). Bộ định tuyến lõi có nhiệm vụ kiểm tra chủng loại của gói IP và chuyển tiếp gói tin IP theo cách gói tin đó được nhận, bao gồm định tuyến cho gói, hoặc xếp gói vào bộ đệm thích hợp nếu cần thiết. Mặc dù đã khắc phục được nhược điểm về tính áp dụng rộng của IntServ nhưng mô hình DiffServ chỉ có khả năng đảm bảo QoS cho luồng IP tổng. Hiện nay, mô hình DiffServ vẫn chưa được các nhà cung cấp dịch vụ triển khai trong mạng của họ cũng bởi nguyên nhân là sự cần thiết phải đầu tư nâng cấp mạng, thiếu động lực triển khai do tính tiện lợi của cung ứng thừa dung lượng cũng lý giải cho hiện trạng này. 3.2.2 Miền dịch vụ phân biệt và điểm mã dịch vụ phân biệt Một miền dịch vụ phân biệt DS gồm các nút DS (còn gọi là các bộ định tuyến hỗ trợ cơ chế dịch vụ phân biệt) hoạt động với một chính sách cung cấp dịch vụ chung và thiết lập các nhóm PHB được thực hiện trên mỗi nút. Các nút biên DS trong miền DS phân loại và điều khiển lưu lượng đầu vào để đảm bảo các gói đi qua miền được đánh dấu thích hợp để lựa chọn một PHB từ một nhóm các PHB được hỗ trợ trong phạm vi miền. Các nút trong miền DS lựa chọn ứng xử chuyển tiếp cho các gói dựa trên điểm mã dịch vụ DSCP của chúng, sắp xếp vào một trong các PHB theo yêu cầu. Việc quản trị một miền phải đảm bảo tin cậy để đảm bảo rằng các nguồn tài nguyên tương xứng được cung cấp và được dự trữ để hỗ trợ các SLA yêu cầu. 67 Hình 3.10. Miền dịch vụ phân biệt DS Các vùng DS có khả năng hỗ trợ các miền DS dọc theo đường định tuyến nối các miền trong vùng. Các miền DS trong vùng DS có thể hỗ trợ nội bộ trong các nhóm PHB khác nhau và các điểm mã khác nhau để sắp xếp PHB. Tuy nhiên, việc cho phép các dịch vụ nối ngang qua miền, các miền DS ngang hàng phải thiết lập mỗi miền một SLA ngang hàng chứa thoả thuận lưu lượng TCA phù hợp. Các bộ định tuyến hoạt động trong miền DS sử dụng trường chức năng dịch vụ phân biệt DS để đánh dấu gói. Trong 8 bit của trường DS, 6 bit được sử dụng cho điểm mã dịch vụ phân biệt DSCP và 2 bit dự phòng. Hình 3.11. Cấu trúc của trường phân biệt dịch vụ DS Các điểm mã dịch vụ phân biệt DSCP được phân thành 3 khối gọi là các pool. Bảng 3.6 chỉ ra các khối điểm mã dịch vụ phân biệt DSCP: Bảng 3.6. Các khối điểm mã dịch vụ phân biệt DSCP Pool Điểm mã DSCP Ứng dụng 1 XXXXX0 Tiêu chuẩn 2 XXXX11 Thử nghiệm/nội bộ 3 XXXX01 Thử nghiệm/nội bộ Pool 1 gồm các điểm mã DSCP sử dụng cho toàn cầu, pool 2 và pool 3 sử dụng cho mục đích thử nghiệm và nội bộ miền DS riêng. Trường chức năng ToS của IPv4 Trường phân lớp dịch vụ TC của IPv6 Trường dịch vụ phân biệt DS Điểm mã dịch vụ phân biệt DSCP Dự phòng (6 bit) (2 bit) 68 3.2.3 Phân bổ băng thông Phân bổ băng thông (BB – Bandwidth Broker) là một phần tử logic có vai trò quan trọng trong mạng DiffServ, có nhiệm vụ quản lý tài nguyên (băng thông) hay điều khiển chấp nhận cho mạng DiffServ. BB quản lý tài nguyên trong mạng DiffServ dựa trên thỏa thuận mức dịch vụ (SLA) đã được thỏa thuận trong vùng mạng đó. Ngoài ra, BB còn có chức năng quản lý liên kết mạng với các BB của các mạng gần kề để phối hợp các SLA trên các ranh giới mạng. Hình 3.12. Hoạt động của BB BB thu thập và quan trắc trạng thái của tài nguyên QoS trong mạng và tại các nút biên đến từ các mạng gần kề. Thông tin này cùng với thông tin chính sách được sử dụng để điều khiển chấp nhận yêu cầu QoS cho mạng. Quản lí chính sách sẽ so sánh các yêu cầu này với các nguyên tắc, nếu không đáp ứng sẽ từ chối. Thông tin trạng thái mạng từ BB còn được sử dụng để kiểm tra tài nguyên khả dụng hiện có trong mạng để đáp ứng các yêu cầu, thông tin nằm trong cơ sở dữ liệu của BB. 3.2.4 Xử lý gói tin trong DiffServ 3.2.4.1 Đặt vấn đề Đối với mạng Internet truyền thống, các kết nối được xử lý như nhau trong mạng. Đây là điểm trái ngược với các khái niệm khác, như mạng ATM (chế độ truyền không đồng bộ), có thể đáp ứng yêu cầu chất lượng dịch vụ đối với các kết nối ở mức cao hơn về xử lý và báo hiệu liên quan tới việc chấp nhận các kết nối mới và duy trì các kết nối đang BB1 BB2 BB3 USER AS1 AS2 AS3 Liên kết mạng Liên kết người sử dụng BB Trao đổi SLA Liên kết trong mạng Các Router 69 có. Mặt khác, vì tài nguyên mạng bị giới hạn nên việc đảm bảo hiệu suất yêu cầu phải từ chối các kết nối mới nếu tài nguyên không có sẵn. Điều này chính là điểm tương phản so với đặc tính Best-Effort của mạng Internet ngày nay. Hiện tại người ta đã nhìn nhận tầm quan trọng của việc phân biệt giữa các lớp kết nối và khả năng cấp phát tài nguyên cho các kết nối theo lớp của chúng, vì lý do này mà mô hình phân biệt DiffServ được đưa ra. Mô hình DiffServ hoạt động dựa trên việc đánh dấu các gói tin bắt đầu đi vào mạng theo mức hiệu suất cần cung cấp. Sau đó theo dấu này, các gói tin sẽ được xử lý khác nhau tại các nút mạng. Cách phổ biến để phân biệt gói tin là dùng bộ đệm RED, tức là dùng các tham số khác nhau cho các gói tin khác nhau. 3.2.4.2 Các phương pháp xử lý gói trong DiffServ Quy tắc ứng xử theo từng chặng là sự mô tả bề ngoài của ứng xử chuyển tiếp một nút DS được áp dụng cho một tập ứng xử DS cụ thể. Để tạo ra các hành vi chuyển tiếp gói được định nghĩa theo quy tắc ứng xử từng chặng PHB, các cơ cấu kỹ thuật đảm bảo QoS như AQM và lập lịch gói được ứng dụng. Nhóm làm việc về DiffServ của IETF định nghĩa hai loại PHB trong RFC 2598 [14], RFC 3246 và RFC 2597 [14]: Chuyển tiếp nhanh EF (Expedited Forwarding) và Chuyển tiếp đảm bảo AF (Assured Forwarding). 3.2.4.2.1 Chuyển tiếp nhanh EF PHB Chuyển tiếp nhanh được yêu cầu đưa ra các dịch vụ với khả năng tổn hao thấp, trễ thấp, thay đổi trễ thấp và đảm bảo băng thông. Một bộ định tuyến EF phải đảm bảo lưu lượng EF được đưa đến những bộ nhớ đệm nhỏ vì rung pha và trễ gây nên bởi thời gian mà gói sử dụng trong bộ nhớ đệm và hàng đợi. Khi xảy ra hiện tượng quá tải, nút biên miền DS không cho phép lưu lượng dạng này đi vào trong miền vì nó là nguyên nhân gây tắc nghẽn tại các bộ định tuyến trong miền DS. Vấn đề này được điều chỉnh bởi thỏa thuận mức dịch vụ SLA và xác định lưu lượng truyền có điều kiện. Hình 3.13. Xử lý chuyển tiếp nhanh EF PHB 70 Chuyển thiếp nhanh EF PHB khả thi nếu băng thông đầu ra và kích thước bộ nhớ đệm đủ để các luồng lưu lượng ra với tốc độ phục vụ µ. Tốc độ phục vụ µ luôn lớn hơn tốc độ đầu vào λ tại các bộ đệm EF. 3.2.4.2.2 Nhóm chuyển tiếp đảm bảo AF PHB DiffServ được thực hiện trong NS2 theo nhóm chuyển tiếp đảm bảo. Một gói tin phụ thuộc vào một luồng có thể nhận 3 mức ưu tiên cùng với luồng đó, được dùng để cung cấp xác suất mất gói thấp hơn cho các gói tin đồng bộ trong kết nối TCP. Do không giống các gói tin khác, việc các gói tin đồng bộ bị mất có thể gây gián đoạn liên lạc (thời gian time-out) rất dài. Ngoài việc phân biệt mỗi luồng, thì tất cả các luồng được phân thành các lớp (tối đa là 4 lớp) và các lớp khác nhau sẽ nhận được mức độ xử lý khác nhau. Chuyển tiếp đảm bảo với đặc điểm phân phối dữ liệu đảm bảo với khả năng mất gói thấp là điều kiện tốt nhất khi sử dụng các giao thức không thực hiện xử lý sửa lỗi hoặc không có giải pháp truyền lại gói. AF PHB bao gồm 4 lớp chuyển tiếp và mỗi lớp chuyển tiếp có 3 mức ưu tiên loại bỏ gói tin, mỗi lớp được gán một băng thông và khoảng nhớ đệm xác định. Nếu một gói phải bị loại bỏ, bộ định tuyến có cách nhận biết gói nào bị loại bỏ đầu tiên. Ngoài ra, mỗi lớp chuyển tiếp được phân bổ một số lượng cực nhỏ băng thông và bộ nhớ đệm. Nếu bộ nhớ đệm đầy, thì quá trình loại bỏ gói sẽ bắt đầu theo trật tự loại bỏ theo mức ưu tiên. Các phân loại AF được thể hiện trên hình 3.14 và trên bảng 3.7: Hình 3.14. Các phân lớp AF PHB Bảng 3.7. Chi tiết các phân lớp chuyển tiếp đảm bảo AF PHB Lớp PHB Phân lớp Dự đoán mất gói DSCP AF4 AF41 AF42 AF43 Thấp Trung bình Cao 100010 100100 100111 AF3 AF31 Thấp 011010 71 AF32 AF33 Trung bình Cao 011100 100010 AF2 AF21 AF22 AF23 Thấp Trung bình Cao 010010 010100 010110 AF1 AF11 AF12 AF13 Thấp Trung bình Cao 001010 001100 001110 Thực hiện đánh dấu gói: Mỗi gói IP mang một byte gọi là octet ToS (Type of Service). Byte này chiếm một vài phần trăm của lưu lượng hiện nay, và được thiết lập bằng 0. Rõ ràng đó là một đặc tính sử dụng không trọn vẹn của IP. Trong IPv6, có một byte tương đương gọi là byte loại lưu lượng. Nhiệm vụ đầu tiên của nhóm làm việc DiffServ là xác định lại byte này, định nghĩa giống nhau cho IPv4 và IPv6. Trường 6 bit này được biết như là trường dịch vụ phân biệt (trường DS) và được đánh dấu với một mẫu bit đặc biệt gọi là DSCP dùng để chỉ ra cách thức mỗi bộ định tuyến cần xử lý gói. Các gói DiffServ phải có một giá trị phù hợp trong trường DSCP. Để nhấn mạnh việc không có thông tin về phiên cần cất giữ, việc xử lý này được biết như là một PHB. ToS định nghĩa như trong hình 3.15: Hình 3.15. Cấu trúc của byte TOS Trường DS 6 bit có thể bao gồm tới 64 giá trị khác nhau. Nói chung, 64 PHBs khác nhau là cần thiết, nên một số codepoint dùng để dự trữ. Sự đánh dấu có thể xuất hiện trong hai vị trí:  Nguồn gốc phát sinh lưu lượng (ví dụ Web Server hoặc Gateway của hệ thống điện thoại IP) thực hiện đánh dấu lưu lượng. Điều này có được lợi thế là thực thể phân loại có thể biết rõ về ứng dụng nên đánh dấu các gói theo ứng dụng.  Một bộ định tuyến (như là bộ định tuyến đầu tiên mà lưu lượng gặp hoặc bộ định tuyến ở ranh giới khách hàng ISP) phân loại và đánh dấu lưu lượng. Điều này có lợi thế là không cần thay đổi Server, nhưng nó yêu cầu vài mở rộng “nhanh” trong bộ định tuyến. Rất may, nhiều bộ định tuyến đã có khả năng này, thay cho sử dụng IntServ/RSVP. 72 Một tuỳ chọn thứ ba, kết hợp lợi thế và bất lợi của cả hai, đối với Server sử dụng mô hình IntServ/RSVP để kết nối với bộ định tuyến biên, nhưng đối với bộ định tuyến biên dùng mô hình DiffServ cho sự liên lạc phạm vi rộng như Internet. Sử dụng đánh dấu: Các PHB được xác định theo các giới hạn về tài nguyên của chúng (bộ đệm, băng thông) có quan hệ ưu tiên với các PHB khác, hay trong các giới hạn về đặc điểm lưu lượng tường minh (trễ, tổn thất). Các PHB này có thể được dùng như là các khối làm sẵn để cấp phát các tài nguyên và nên được định rõ như một nhóm PHB chắc chắn. Các nhóm PHB thường chia sẻ áp dụng ràng buộc chung cho mỗi PHB trong phạm vi nhóm, như chính sách lập lịch gói hay quản lý bộ đệm. Khi một gói đi vào bộ định tuyến, việc định tuyến lựa chọn hợp lý cổng ra của nó và giá trị DSCP được sử dụng để chuyển gói tới hàng đợi hoặc xử lý tại cổng đó. Việc tiến hành phụ thuộc vào định nghĩa của PHB tương ứng. PHB được cấu hình bằng cơ chế quản lý mạng thiết lập bảng QoS bên trong bộ định tuyến. Nhóm làm việc DiffServ đã đưa ra phương pháp trong đó một vài PHB cơ sở cần sớm chuẩn hoá. Điều đó xuất phát từ kinh nghiệm (hầu hết từ việc triển khai giới hạn và thử nghiệm sử dụng trường mức ưu tiên IP để lựa chọn hoạt động chuyển tiếp. PHBs được chuẩn hoá như sau:  Hoạt động mặc định: giá trị DSCP là 0 và dịch vụ tương ứng là dịch vụ Internet mặc định hiện nay (không kiểm soát được hoàn toàn tắc nghẽn và mất mát).  Các hoạt động lựa chọn loại: 7 giá trị DSCP từ 001000 đến 111000 để lựa chọn 7 hoạt động, mỗi giá trị có xác suất chuyển tiếp cao hơn giá trị trước.  Chuyển tiếp nhanh (EF - Expedited Forwarding): Giá trị DSCP khuyến cáo là 101110 và hoạt động được định nghĩa như tốc độ chuyển hướng của lưu lượng EF phải bằng hoặc lớn hơn tốc độ cấu hình. EF dùng để tạo dịch vụ thời gian thực với một cấu hình tốc độ lưu lượng. Chuyển tiếp đảm bảo (AF - Assured Forwarding): Trên thực tế, một hoạt động AF thật sự gồm có 3 hoạt động con. Để thuận tiện ta gọi chúng là AF1, AF2, AF3. Khi mạng bị tắc nghẽn, các gói được đánh dấu với DSCP cho AF1có xác suất bị loại bỏ bởi bất kỳ bộ định tuyến nào là thấp nhất, và các gói được đánh dấu AF3 có xác suất cao nhất. Vì vậy, trong phạm vi loại AF, có thể dùng các xác suất rớt khác nhau. 3.2.5 Kết luận Việc triển khai DiffServ trên mạng không tạo ra băng thông rỗi mà ý tưởng cơ bản của nó là triển khai nhiều hàng đợi trên router để đảm bảo rằng các BA này được đảm bảo về chất lượng hơn các BA khác. Do đó cần phải đảm bảo năng lực mạng nhất định cho các bộ định tuyến. 73 3.3 KHUYẾN NGHỊ TRIỂN KHAI QoS TRÊN MẠNG IP Công nghệ IP được sử dụng thì việc triển khai QoS trên mạng IP là một yêu cầu quan trọng và thực tế. Từ những nghiên cứu của luận văn chúng tôi đưa ra một số khuyến nghị như sau:  Tổ chức triển khai mô hình liên kết hai mô hình DiffServ – IntServ để cung cấp dịch vụ QoS end-to-end cho khách hàng.  Nâng cấp mạng IP có hỗ trợ DiffServ để sẵn sàng cung cấp các dịch vụ phân biệt trên mạng lõi. Trường hợp triển khai các nút lõi mới thì các nút này phải hỗ trợ DiffServ.  Nâng cấp các nút truy nhập có hỗ trợ giao thức RSVP. 3.4 KẾT LUẬN Chương 3 giới thiệu tổng quan các mô hình dịch vụ cung cấp QoS như dịch vụ tích hợp (IntServ), dịch vụ phân biệt (DiffServ). Phân tích ưu nhược điểm của từng mô hình thông qua nguyên lý và cách thức thực hiện của mô hình đó.  Intergrated services(IntServ) Sắp xếp đường đi trước từ nguồn đến đích cho các dữ liệu được ưu tiên. Mỗi thiết bị mạng trên đường đi phải kiểm tra xem nó có thể hỗ trợ cho yêu cầu trên hay không. Khi yêu cầu tối thiểu được đáp ứng, ứng dụng nguồn sẽ được thông báo xác nhận. Sau đó, ứng dụng có thể sử dụng đường truyền. . Nhược điểm chính của mô hình dịch vụ tích hợp IS là những trở ngại phải đối mặt trong việc khai báo và quản lý tài nguyên của các kết nối tại tất cả các hệ định tuyến. Với sự phát triển bùng nổ của Internet hiện nay, các hệ định tuyến đường trục có thể phải thực hiện chuyển tiếp hàng trăm nghìn kết nối đồng thời và vì vậy, có thể bị quá tải, mặc dù cấu hình xử lý và lưu trữ tạm thời của các hệ định tuyến này đã được cải thiện đáng kể [25].  Differentiated services (DiffServ) Giải pháp IntServ tỏ ra không hiệu quả và không có khả năng mở rộng khi nhiều nguồn phải cạnh tranh với nhau về băng thông. Trong giải pháp DiffServ, mỗi router và switch sẽ quản lý gói riêng lẻ. Mỗi router sẽ có một chính sách riêng để quản lý và sẽ tự quyết định cách thức chuyển gói tin theo cách riêng. IntServ quản lý theo kiểu per-flow, trong khi DiffServ quản lý theo kiểu per-hop. Mỗi router và switch sẽ kiểm tra gói tin để quyết định sẽ chuyển tiếp gói tin đó như thế nào. Đối với mỗi gói tin nó sẽ đơn thuần gán vài thông số vào header. 74 Chương 4 ĐÁNH GIÁ MÔ HÌNH ĐẢM BẢO QoS IP QUA MÔ PHỎNG 4.1 ĐÁNH GIÁ CHUNG Mô hình IntServ phần nào đã giải quyết được nhiều vấn đề liên quan đến QoS trong mạng IP. Nhưng trên thực tế, mô hình này không thực sự đảm bảo được QoS xuyên suốt (end-to-end). Đã có nhiều cố gắng để thay đổi điều này nhằm đạt được một mức QoS cao hơn cho mạng IP và một trong những cố gắng đó là sự ra đời của mô hình DiffServ. DiffServ sử dụng việc đánh dấu gói và xếp hàng theo loại để hỗ trợ các dịch vụ ưu tiên qua mạng IP. Nguyên tắc cơ bản của mô hình DiffServ là:  Định nghĩa một số lượng nhỏ các lớp dịch vụ hay mức ưu tiên. Một lớp dịch vụ có thể liên quan đến đặc tính lưu lượng (băng tần min-max, kích cỡ burst, thời gian kéo dài burst,…).  Phân loại và đánh dấu các gói riêng tại biên của mạng vào các lớp dịch vụ.  Các thiết bị chuyển mạch, router trong mạng lõi sẽ phục vụ các gói theo nội dung của các bit đã được đánh dấu trong tiêu đề của gói. Từ những nguyên tắc này, mô hình DiffServ có nhiều lợi thế hơn IntServ:  Không yêu cầu báo hiệu cho từng luồng;  Dịch vụ ưu tiên có thể áp dụng cho một số luồng riêng biệt cùng một lớp dịch vụ. Nguyên tắc này cho phép nhà cung cấp dịch vụ dễ dàng cung cấp một số lượng nhỏ các mức dịch vụ khác nhau cho khách hàng có nhu cầu;  Không yêu cầu thay đổi tại các máy chủ hay các ứng dụng để hỗ trợ dịch vụ ưu tiên (công việc của thiết bị biên);  Hỗ trợ rất tốt dịch vụ VPN. Tuy nhiên, mô hình DiffServ cũng cần phải vượt qua một số vấn đề như:  Không có khả năng cung cấp băng tần và độ trễ bảo đảm như GS của IntServ hay ATM;  Vấn đề quản lý trạng thái Classifier của một số lượng lớn các thiết bị biên là một vấn đề cần quan tâm;  Thiết bị biên vẫn yêu cầu bộ Classifier chất lượng cao cho từng gói giống như trong mô hình IntServ  Chính sách khuyến khích khách hàng trên cơ sở giá cước cho dịch vụ cung cấp cũng ảnh hưởng đến giá trị của DiffServ. Bảng phân tích dưới đây chỉ ra sự khác nhau giữa hai mô hình này: 75 Bảng 4.1. So sánh mô hình IntServ và DiffServ Đặc tính IntServ DiffServ Phân biệt dịch vụ Theo từng luồng lưu lượng Tập các luồng lưu lượng Cơ sở phân loại lưu lượng Một vài trường tiêu đề IP Trường DS của tiêu đề IP Trạng thái tại các router (quản lí bộ đệm) Theo từng luồng Theo tập các luồng Loại dịch vụ phân biệt Xác định hoặc đảm bảo thống kê Đảm bảo tuyệt đối hoặc tương đối Sự sắp đặt cho dịch vụ Từ đầu cuối tới đầu cuối Nội bộ (từng chặng) Phạm vi dịch vụ Đơn hướng hoặc đa hướng Bất cứ nơi nào trong mạng Điều khiển chấp nhận Yêu cầu Chỉ yêu cầu cho dịch vụ tương đối Giao thức báo hiệu Yêu cầu (RSVP) Không yêu cầu với dịch vụ tương đối Quản lý mạng Giống như mạng chuyển mạch kênh Giống như mạng IP hiện tại Tính cước Dựa trên đặc tính luồng và yêu cầu QoS Dựa trên loại dịchvụ sử dụng Triển khai liên mạng Thỏa thuận đa phương Thỏa thuận song phương 4.2 MÔ PHỎNG VÀ KIỂM TRA QoS 4.2.1 Tổng quan chương trình mô phỏng mạng NS2 4.2.1.1 Giới thiệu chung NS (Network Simulator) là hệ thống mô phỏng mạng, đặc biệt là các giao thức điều khiển hoạt động của mạng, phát triển tại đại học Berkeley và viện công nghệ thông tin ISI (Information Science Institute), có khả năng mô phỏng nhiều kiểu mạng IP khác nhau. Nó mô phỏng việc thực hiện các giao thức mạng như TCP, UDP, các nguồn dữ liệu FTP, Telnet, Web, CBR và VBR, có cơ chế quản lí hàng đợi router như DropTail, RED và CBR. NS2 là một bộ mô phỏng sự kiện rời rạc, có thứ tự, người sử dụng có thể thay đổi cấu hình và mở rộng mô hình mạng rất dễ dàng bằng cách lập trình thêm vào một số mô-đun chương trình. NS2 dựa trên hai ngôn ngữ: một bộ mô phỏng hướng đối tượng, được viết bằng C++, và một bộ thông dịch OTcl (phần mở rộng hướng đối tượng của Tcl), được dùng để thực hiện các đoạn mã kịch bản của người dùng. Một công cụ khác được phát hành cùng với NS là Network Animator (NAM). Công cụ này cung cấp hình ảnh đồ họa về sự chuyển động của các nút trong mạng mô 76 phỏng và truyền thông giữa chúng. Đây là một công cụ rất có ích để tìm lỗi trong mã nguồn của giao thức. Trong thí nghiệm mô phỏng của luận văn, chúng tôi sử dụng công cụ NS2 phiên bản NS - 2.34. 4.2.1.2 Mô hình NS2 Dưới góc độ của người dùng, một hệ thống mô phỏng NS2 được mô hình hóa như sau: Hình 4.1. Mô hình NS2 đơn giản Từ mô hình trên có thể thấy, NS2 sử dụng ngôn ngữ Otcl với thư viện bao gồm các đối tượng: Bộ lập lịch các sự kiện; thư viện đối tượng các thành phần mạng và các modul thiết lập mạng. Nói cách khác, để sử dụng NS2, ta phải lập trình trên ngôn ngữ Otcl. Để cài đặt và chạy chương trình mô phỏng mạng bằng NS, ta phải viết Script trên ngôn ngữ Otcl, lập lịch cho các sự kiện, thiết lập cấu hình mạng (topo mạng) bằng cách sử dụng các đối tượng thành phần mạng, triệu gọi các hàm thư viện, báo cho các nguồn dữ liệu biết khi nào thì bắt đầu và kết thúc việc truyền gói tin trên mạng. Khi muốn tạo một đối tượng mạng mới, có thể viết mới một đối tượng hoặc bằng cách liên kết các đối tượng mạng đã có sẵn trong thư viện. Việc gắn kết đối tượng tạo nên đối tượng mới chính là điểm mạnh của NS2. NS2 sử dụng cả ngôn ngữ C++ và ngôn ngữ Otcl. NS2 hỗ trợ cấu trúc lớp kiểu phân cấp trong C++ (được gọi là cấu trúc lớp biên dịch), và một cấu trúc lớp tương tự trong ngôn ngữ Otcl (gọi là cấu trúc lớp thông dịch). Hai cấu trúc lớp phân cấp này có quan hệ chặt chẽ với nhau, dưới góc độ người sử dụng (không phải người lập trình phát triển NS), có tương ứng 1-1 giữa lớp trong cấu trúc lớp biên dịch và lớp trong cấu trúc lớp thông dịch Sơ đồ sau là ví dụ về sự phân cấp trong C++ và Otcl: Hình 4.2. Tương ứng C++ và Otcl 77 Mỗi ngôn ngữ được sử dụng với mục đích riêng. Otcl có thể được sử dụng: - Trong việc cấu hình, cài đặt và các công việc thực hiện “một lần” - Chỉnh sửa các đối tượng C++ đã có sẵn Và sử dụng C++ cho: - Khi làm các công việc đòi hỏi xử lý từng gói tin của luồng dữ liệu - Khi phải thay đổi các hành vi của các lớp C++ đã tồn tại Có thể hình dung tổ chức của NS qua sơ đồ sau: Hình 4.3. Kiến trúc của NS Sơ đồ kiến trúc của NS, nói chung có thể coi người dùng như đang đứng ở góc dưới bên trái, thiết kế và chạy hệ mô phỏng bằng ngôn ngữ Tcl và sử dụng các đối tượng Otcl trong thư viện. Bộ lập lịch các sự kiện và hầu hết các đối tượng thành phần mạng đều được viết bằng C++, và có thể triệu gọi từ Otcl thông qua giao tiếp tclcl, cả hệ thống kết hợp lại thành NS. Sơ đồ mô hình NS đơn giản cũng chỉ ra, khi kết thúc quá trình mô phỏng, ns có thể sinh ra một hay nhiều text file chứa số liệu chi tiết phục vụ cho việc phân tích quá trình mô phỏng, hoặc cũng có thể là đầu vào cho hệ mô phỏng bằng đồ hoạ (Network Animator : NAM). Hình 4.4 sẽ mô tả sự hoạt động của NS thông cua 3 mức, như chúng ta thấy có mức khung cảnh, mức Script và cuối cùng là ngôn ngữ C++. Tất cả những công việc của NS đều thông qua các Script của NS để gọi các hàm của C++ ở mức dưới cùng. Hình 4.4. Sơ đồ hoạt động của NS2 78 4.2.1.3 Cấu trúc của tệp bám vết Dữ liệu ra sau khi mô phỏng với NS-2 thường được lưu trong một tệp, tệp này được gọi là tệp dấu vết (trace file). Tệp dấu vết chứa thông tin về các sự kiện của gói tin xảy ra trong suốt thời gian mô phỏng theo từng tầng: tầng MAC, tầng mạng, tầng giao vận. Khi bám vết trong một tệp ASCII đầu ra, tệp bám vết có tên mở rộng .tr được tổ chức thành 12 trường. Ý nghĩa của các trường là: Hình 4.5. Các trường của tệp bám vết 1. Trường đầu tiên là kiểu sự kiện. Được đưa ra bằng một trong 4 biểu tượng r, +, -, d lần lượt tương ứng với nhận (ở đầu ra của kênh truyền), đã xếp vào hàng, đã ra khỏi hàng và bị loại. 2. Đưa ra thời điểm xảy ra sự kiện 3. Đưa ra nút đầu vào của kênh truyền mà sự kiện xảy ra ở đó 4. Đưa ra nút đầu ra của kênh truyền mà sự kiện xảy ra ở đó 5. Đưa ra kiểu gói tin (như CBR hay TCP) 6. Đưa ra kích thước gói tin 7. Một vài cờ 8. Đây là mã nhận dạng luồng (fid) IPv6 mà một người sử dụng có thể đặt cho môic dòng ở tập lệnh Otcl đầu vào. 9. Địa chỉ nguồn đưa ra dưới dạng “node.port” 10. Địa chỉ đích. 11. Số thứ tự gói tin của giao thức lớp mạng. 12. Mã nhận dạng duy nhất của gói tin. 4.2.1.4 Nguồn phát sinh lưu lượng NS hỗ trợ bốn loại nguồn phát sinh lưu lượng [18]: 1. EXPOO_Traffic: tạo lưu lượng dựa vào một phân phối On/Off theo hàm mũ. Các gói tin được gửi đi với tốc độ xác định trong suốt quãng thời gian on, và không có gói tin nào được gửi trong khoảng thời gian off. Khoảng thời gian on và off được tạo ra theo phân phối hàm mũ. Kích thước các gói tin không thay đổi. 2. POO_Traffic: tạo lưu lượng dựa vào phân phối On/Off Pareto. Loại này tương tự phân phối theo hàm mũ trừ khoảng thời gian on/off được thực hiện theo phân phối pareto. 3. CBR_Traffic: tạo lưu lượng với tốc độ không đổi được định sẵn. Kích thước gói tin là cố định nhưng có thể chọn các giá trị khác nhau. Ngoài ra, một bộ tạo số 79 ngẫu nhiên có thể được kích hoạt, để thay đổi khoảng thời gian các gói tin khởi hành trong một phạm vi nhất định. 4. TrafficTrace: là nguồn lưu lượng được ghi lại dưới dạng vết của một nguồn lưu lượng đến từ mạng thật. 4.2.2 Mô phỏng mô hình DiffServ 4.2.2.1 Định nghĩa các chính sách Tất cả các luồng có cùng địa chỉ nguồn và đích đều lệ thuộc vào một chính sách chung. Chính sách quy định loại bộ đo được dùng để đo các tham số lưu lượng đầu vào liên quan. Một bảng các chính sách được dùng trong NS2 để lưu trữ loại chính sách của mỗi luồng. Bảng này bao gồm: 1) Địa chỉ nút nguồn 2) Địa chỉ nút đích 3) Loại chính sách 4) Loại thiết bị đo 5) Điểm mã khởi đầu 6) CIR (tốc độ thông tin cho phép) 7) CBS (kích thước cụm cho phép) 8) C bucket (kích thước hiện thời của dung lượng cho phép) 9) EBS (kích thước cụm vượt mức) 10) E bucket (kích thước hiện thời của dung lượng vượt quá) 11) PIR (tốc độ thông tin tối đa) 12) PBS (kích thước cụm tối đa) 13) P bucket (kích thước hiện thời của dung lượng tối đa) 14) Thời gian đến của gói tin cuối 15) Tốc độ gửi tin trung bình 16) Độ dài cửa sổ TSW (TSW là chính sách dựa trên tốc độ truyền trung bình là lấy bình quân theo kích thước cửa sổ dữ liệu tính theo giây). Giá trị mặc định là 1 giây (1s). Mỗi loại chính sách sau đây định bộ đo mà nó sử dụng: 1) TSW2CM (TSW2CMPolicer): Dùng CIR và 2 thứ tự ưu tiên hủy gói. 2) TSW3CM (TSW3CMPolicer): Dùng một CIR, một PIR và 3 thứ tự ưu tiên hủy gói. Mức ưu tiên trung bình được dùng theo xác suất khi CIR vượt mức cho phép. 3) Token Bucket (TokenBucketPolicer): Dùng CIR; CBS và 2 thứ tự ưu tiên hủy gói. 80 4) Single Rate Three Color Marker (srTCMPolicer): Dùng CIR, CBS, EBS và PBS để chọn từ 3 drop precedences. 5) Two Rate Three Color Marker (trTCMPolicer): Dùng CIR, CBS, EBS và PBS để chọn từ 3 drop precedences. 6) NullPolicer: không rút ngắn các gói tin bất kỳ Một bảng chính sách định nghĩa cho mỗi loại chính sách điểm mã khởi đầu cũng như là một hay hai điểm mã giảm mức. Điểm mã khởi đầu thường được gọi là “green code” và điểm mã giảm mức thấp nhất là “red”. Nếu có một điểm mã khác ở giữa thì nó là “yellow”. 4.2.2.2 Kịch bản mô phỏng 1 Trong kết nối TCP, việc mất một số đoạn gây ảnh hưởng nhiều hơn lên hiệu năng của phiên kết nối so với các đoạn khác. Thực hiện ưu tiên dùng mô hình DiffServ sẽ làm hiệu suất kết nối TCP được cải thiện đáng kể. Mục đích của việc mô phỏng dùng mô hình DiffServ để chỉ ra rằng có thể đánh dấu ưu tiên các gói tin nhạy cảm mà không cần bất kỳ thông tin nào của lớp vận chuyển, do đó sẽ đơn giản hóa việc thực hiện đánh dấu ưu tiên các gói TCP. Yêu cầu bài toán Mở đầu cho phân loại dịch vụ: Hai mức ưu tiên được định nghĩa. Mức cao hơn “gói tin vào” hay “green packets” và mức thấp hơn “gói tin ra” hay “red packets”. Chúng ta tập chung vào chính sách đơn giản nhất có sẵn trong NS: cửa sổ thời gian trượt (5 chính sách: TSW2CM, TSW3CM,...). Một tốc độ cho phép CIR được định nghĩa cho mỗi router biên. Miễn là tốc độ kết nối dưới mức CIR thì tất cả gói tin được đánh dấu là mức ưu tiên cao. Khi tốc độ vượt mức CIR thì các gói tin được đánh dấu theo xác suất bình quân, mà tốc độ của gói tin được đánh dấu với mức ưu tiên cao cùng với CIR. Tốc độ truyền được tính theo tốc độ trung bình trên “cửa sổ TSW”; trong phần mô phỏng thì khoảng thời gian cửa sổ là 20 s. Thời gian mô phỏng kéo dài 60s. Thực hiện việc thay đổi CIR tại nút biên nguồn và nghiên cứu ảnh hưởng của nó đến hiệu suất. Topo mạng đơn giản với một nút thắt cổ chai được cấu hình như sau: Hình 4.6. Mô hình mạng 1 S0 E0 Sn E E1 D En Core S1 En-1 Sn-1    81 Mỗi nút nguồn được kết nối tới nút biên tương ứng nơi lưu lượng được đánh dấu theo các tham số được chỉ rõ ở dưới. Router biên được kết nối tới router lõi tại nút thắt cổ chai và sau đó qua một router khác để tới đích. Topo khảo sát với 15 nút nguồn, mỗi nút nguồn tạo ra các kết nối TCP. Mô phỏng với mạng LAN (có trễ truyền dẫn nhỏ) với đường truyền hoàn toàn đối xứng. Đánh giá hiệu năng mạng DiffServ với các tham số định trước: - Đường truyền giữa nút biên và nút nguồn tương ứng có độ trễ 0.01ms và băng thông 6Mbps. - Đường truyền giữa nút biên và nút đích tương ứng có độ trễ 0.01ms và băng thông 10Mbps. - Đường truyền giữa nút trung tâm và nút biên gắn với nút nguồn có độ trễ 0.1ms và băng thông 6Mbps. - Đường truyền giữa nút trung tâm và nút biên gắn với nút đích có độ trễ 1ms và băng thông 10Mbps. Mô hình lưu lượng: Một file được truyền có phân bố xác suất Pareto với tham số shape là 1.25 và kích thước trung bình 10kbytes. File được truyền đến mỗi nút nguồn theo tiến trình Poisson với tốc độ trung bình 5 file/giây. Nhiều phiên truyền từ cùng 1 nút nguồn có thể được kích hoạt đồng thời. Tham số quản lý việc xếp hàng: Hàng đợi được xây dựng tại router nút cổ chai, chọn kích thước hàng đợi là 100 gói tin. Các tham số quản lý hàng đợi tại các nút khác không ảnh hưởng đến kết quả. Trong hàng đợi thắt cổ chai tại nút trung tâm, quản lý hàng đợi multi-RED dùng phiên bản RIO-D (chọn tham số giống nhau cho cả 2 mức ưu tiên). Chọn tham số giống nhau với cả hai mức ưu tiên mục đích là để tạo ra các điều kiện cho phép nghiên cứu ảnh hưởng của DiffServ khi giảm xác suất mất các đoạn dễ bị mất và tác động của nó đến hiệu suất của hoạt động trên đường truyền TCP (độ trễ, thông lượng). set cir0 100000; # policing parameter set cir1 100000; # policing parameter Kích thước hàng đợi trung bình được giám sát, với mỗi loại gói tin (dùng hàm mũ chuẩn lấy trung bình với tham số wq = 0.01). Các gói tin có màu cho trước bắt đầu bị loại bỏ khi số hàng đợi trung bình của gói tin vượt quá giá trị minw (chọn minw = 15). Xác suất hủy gói tăng tuyến tính với kích thước hàng đợi trung bình cho đến khi đạt tới giá trị maxw = 45, trong đó xác suất hủy gói lấy giá trị maxp = 0.5. Khi vượt quá giá trị này thì xác suất hủy gói bằng 1. Tốc độ đến của các bít tại nút cổ chai là: 415*1.04*10 *8 5.672 0.22 Mbps 82 Kết quả trên thu được như sau: Một gói tin kích thước trung bình 1040 bytes trong 1000 bytes là dữ liệu và 40 bytes là mào đầu phụ. Một file ftp trung bình là 104 bytes dữ liệu có nghĩa là tổng kích thước trung bình khoảng 1.04*104*8 bits. Kết quả này thu được khi nhân số nút nguồn và chia cho thời gian trung bình giữa các file đến tại 1 nút. Kịch bản mô phỏng nhiều nguồn và mỗi nguồn tạo nhiều phiên TCP chia sẻ cùng một đường truyền nút cổ chai và một đích. Thiết đặt các tham số: set cir0 100000; #policing parameter set cir1 100000; #policing parameter set pktSize 1000 set NodeNb 15; # số nút nguồn set NumberFlows 360; # số luồng trên một nút nguồn set sduration 60; # thời gian mô phỏng Định nghĩa thời gian bắt đầu truyền và kích thước gói tin đến sau tiến trình Poissoon: For {set i 1} {$i<=$NodeNb} {incr i} { Set t [$ns now] For {set i 1} {$i<=$NumberFlows} {incr i} { $tcpsrc($i,$j) set sess $j $tcpsrc($i,$j) set node $i Set t [expr $t + [$RV value]] $tcpsrc($i,$j) set starts $t $tcpsrc($i,$j) set size [expr [$RVSize value]] $ns at [$tcpsrc($i,$j) set starts] $ftp($i,$j) send [$tcpsrc($i,$j) set size] $ns at [$tcpsrc($i,$ j) set starts] countFlows $i 1 }} For {set j 1} {$j<=NodeNb} {incr j} { Set Cnts($j) 0 Bảng kết quả thu được khi chạy mô phỏng: Trong đó: - TotPkts: Số gói tin gửi đến core router, yêu cầu router đưa vào bộ đệm rồi phân tuyến. 83 - TxPkts: Số gói tin core router xử lý được, tức là phân tuyến, chuyển tiếp cho edge router thành công. - edrops: Số gói tin router hủy sớm theo cơ chế của RED, nghĩa là gói tin gửi đến router, router phân tích các hàng đợi của nó và hủy ngay, không lưu trữ vào hàng đợi. - ldrops: Số gói tin router hủy do liên kết quá tải, nghĩa là gói tin đã được đưa vào hàng đợi, nhưng sau đó vẫn không thể chuyển tiếp được do liên kết bận. Tỷ lệ phân tuyến thành công của core router ; 0.987%, cho biết hiệu suất hoạt động của mạng là tương đối cao. Số gói tin dữ liệu được truyền thành công trong mô phỏng không phụ thuộc vào tốc độ CIR, với độ lệch chuẩn là 395 gói tin. Xác suất mất gói thấp dẫn đến thông lượng cũng thấp, nó luôn không đổi giống như một hàm của CIR. Trong mô phỏng, một file có kích thước trung bình 10Kbytes, là kích thước đã được tính trung bình trên mạng Internet. Việc gói tin bị mất sẽ làm giảm hiệu suất hoạt động của mạng, vì vậy loại trừ việc mất gói tin sẽ cải thiện đáng kể hiệu suất. 4.2.2.3 Kịch bản mô phỏng 2 Yêu cầu bài toán Mô phỏng mỗi chính sách làm thay đổi CBR rate để xem core router chịu tải đến đâu, khi nào thì tỉ lệ phân tuyến thành công không chấp nhận được nữa, tức tỉ lệ gói tin router hủy đi cao, so sánh giữa các chính sách khác nhau. Đồ thị vẽ ra dạng đường, trục x là rate, trục y là tỉ lệ phân tuyến thành công, mỗi một chính sách tạo ra một đường đồ thị. Cấu hình mạng như sau: Hình 4.7. Mô hình mạng 2 Mô phỏng mô hình mạng 2 với năm chính sách khác nhau: srTCM, trTCM, TB- WIRR, TSW2CM, TSW3CM. Mạng DiffServ với các tham số định trước: - Đường truyền giữa nút biên và nút nguồn tương ứng có độ trễ 5ms và băng thông 10Mbps. - Đường truyền giữa nút biên và nút đích tương ứng có độ trễ 5ms và băng thông 10Mbps. S1 E1 S2 E2 D1 D2 UDP CBR UDP CBR Null Null Core 84 - Đường truyền giữa nút trung tâm và nút biên gắn với nút nguồn có độ trễ 5ms và băng thông 5Mbps. - Đường truyền giữa nút trung tâm và nút biên gắn với nút đích có độ trễ 5ms và băng thông 5Mbp. Thực hiện Tính tỷ lệ phân tuyến thành công của core router. So sánh giữa các chính sách. Tỉ lệ phân tuyến thành công của core router = TxPkts/TotPkts, là một thông số quan trọng cho biết hiệu quả hoạt động của DiffServ. Bảng 4.2. Tỷ lệ phân tuyến thành công các core router của các chính sách Policy Rate TB-WIRR srTCM trTCM TSW2CM TSW3CM 2000000 1% 1% 1% 1% 1% 3000000 0.835% 0.830% 0.832% 0.838% 0.832% 4000000 0.627% 0.620% 0.623% 0.626% 0.622% 8000000 0.502% 0.5% 0.503% 0.501% 0.499% 10000000 0.5% 0.5% 0.5% 0.5% 0.499% Đồ thị sau biểu thị tỷ lệ phân tuyến được tổng kết trong bảng: Hình 4.8. Đồ thị tỷ lệ phân tuyến thành công của core router Ta nhận thấy với các tham số chính sách như nhau và với cùng tốc độ thì tỷ lệ phân tuyến là xấp xỉ như nhau. Với mỗi chính sách, ta thay đổi tốc độ thì tỷ lệ phân tuyến thay đổi như sau: Tốc độ dưới 2000000 thì tỷ lệ phân tuyến luôn bằng 1% tức là số gói tin router hủy sớm theo cơ chế của RED và số gói tin router hủy do liên kết quá tải là 0 kết quả là hiệu suất hoạt động của DiffServ luôn ở mức cao. Khi tốc độ trên 10000000 thì tỷ lệ này là 0.5%, điều này chứng tỏ tốc độ càng cao dẫn tới quá trình phân tuyến của core router giảm dần gây ảnh hưởng đến hiệu suất của DiffServ. 1 2000000 3000000 4000000 8000000 10000000 rate CBR 9000000 …….. 0.5 0 : TB-WIRR : srTCM tỉ lệ phân tuyến (%) 85 4.2.2.4 Kịch bản mô phỏng 3 Mạng LAN khảo sát có tô-pô và cấu hình như sau: Hình 4.9. Mô hình mạng khảo sát 3 Trong mô hình trên, S0 ... S2 là các nút mạng. E1, E2 là Egde có thể xem là các switch, giữa E2 và E2 là Core. CBR là nguồn sinh lưu lượng. Null là đích của nguồn sinh lưu lượng CBR. Kịch bản: Sử dụng NS2 mô phỏng một mô hình mạng bao gồm 3 nút bắt nguồn, 3 nút trung gian và 3 nút đích, đã được cấu hình như các nút ranh giới của miền DiffServ. Từ đó cho phép để thiết lập một cơ chế kiểm soát giao thông đa dạng, với chính sách srTCM, quản lý hàng đợi Drop và schedulers WIRR. Nguồn CBR được cố định với kích thước gói tin là 256 bytes. Các thông số và kịch bản của thí nghiệm được tóm tắt: Send Receive Traffic Class Protocol Traffic Rate Pkt S1 D1 EF UDP CBR 450 256 S2 D2 AF UDP CBR 450 256 S3 D3 BE UDP CBR 450 256 Chính sách sử dụng trong thí nghiệm là srTCM: S1 -> D1 S2 ->D2 S3 ->D3 srTCM srTCM srTCM CIR 400 400 400 CBS 10000 10000 20000 EBS 20000 15000 30000 PBS 10000 10000 10000 S0 E1 S2 E2 D1 D2 D3 UDP CBR UDP CBR Null Null Core S1 Null UDP CBR 86 Kết quả mô phỏng: Với mục đích của thí nghiệm là xác định và vẽ đồ thị sự thay đổi theo thời gian mô phỏng của hệ số sử dụng đường truyền của kết nối UDP. Kết quả thu được như sau: Results S1 ->D1 S2 -> D2 S3 -> D3 E1 -> E2 Sent 23185 24201 28350 75742 Receive 23185 17661 9975 50821 Drop 0 6546 18375 24921 Các luồng có cùng chính sách srTCM nhưng thay đổi tốc độ của mỗi luồng ta nhận thấy: S1 ->D1 tỷ thành công các gói tin gửi đi là 100%, ngược lại, S2 -> D2 với tốc độ lớn hơn 450 nên tỷ lệ thành công đạt được  73% và S3 -> D3 tăng tốc độ lên 700 thì tỷ lệ thành công của gói tin gửi đi chỉ đạt  35%. Hình 4.7. Đồ thị mô tả mất gói trong khoảng thời gian 120s Từ sơ đồ của hình vẽ ta nhận thấy, trong khoảng thời gian 120s các gói tin đi từ S1 -> D1 không bị mất mát trong quá trình truyền đi. Tỷ lệ mất gói tin lớn nhất nằm trên luồng E1 -> E2 và tỷ lệ mất gói tăng theo thời gian mô phỏng. Kết quả tính độ trễ và biến thiên trễ: Flow S1 -> D1 S2 -> D2 S3 -> D3 E1 -> E2 Delay 0.05579 0.194664 0.426573 0.166417 Jitter 0.001621 0.066632 0.260945 0.184243 Luồng S1 -> D1 với lớp lưu lượng EF có độ trễ và biến thiên trễ nhỏ nhất trong khoảng thời gian 120s với độ trễ là 0.05579, biến thiên trễ 0.001621. Luồng S3 -> D3 87 với lớp lưu lượng BE có tỷ lệ mất gói lớn nên độ trễ và biến thiên trễ cao hơn hẳn so với luồng S1 -> D1, đường đồ thị màu xanh (blue) thể hiện rõ nét độ trễ hàng đợi của lớp lưu lượng BE. Mất gói: kiểm tra ảnh hưởng của tốc độ đánh dấu CIR đến xác suất mất gói tin SYN và của gói tin dữ liệu đầu tiên trong kết nối, ta thấy rằng cần giảm việc mất gói tin cho cả hai để đạt được tốc độ CIR như mong muốn. Những gói tin dễ bị tấn công làm giảm hiệu suất đáng kể vì chúng gây ra thời gian gián đoạn dài. Trong mạng tốc độ cao thời gian truyền file rất ngắn (tổng thời gian truyền ngắn hơn nhiều thời gian time-out), vì thế ta mang muốn đạt hiệu suất cao hơn bằng cách loại trừ thời gian time- out này. Trong mạng tốc độ thấp thì việc loại trừ thời gian time-out là không cần thiết. Thông lượng: các luồng lưu lượng CBR0,CBR1,CBR2 đều truyền dữ liệu trong những khoảng thời gian như nhau nhưng thông lượng trung bình khác nhau. Với đường truyền phù hợp thì hiệu suất về thông lượng và độ trễ của UDP đạt được sẽ cao. 88 KẾT LUẬN Qua quá trình tìm hiểu và nghiên cứu dưới sự giúp đỡ nhiệt tình của thầy giáo hướng dẫn PGS.TS Hồ Sĩ Đàm, tôi đã hoàn thành luận văn: “Giải pháp đảm bảo chất lượng dịch vụ (QoS) trên mạng IP; đánh giá, so sánh hiệu quả đảm bảo QoS của DiffServ và IntServ”. Trong luận văn này, tôi đã tìm hiểu và giới thiệu khái quát về đảm bảo chất lượng dịch vụ, đánh giá chất lượng dịch vụ qua mạng IP. Một số vấn đề cốt lõi của các kỹ thuật đảm bảo QoS IP và tiêu chí đánh giá QoS thông qua việc đánh giá các tham số đặc trưng cho QoS IP. Đi sâu vào việc khảo sát, đánh giá hai mô hình IntServ và DiffServ ở những khía cạnh khác nhau đảm bảo chất lượng dịch vụ cho mạng IP, từ đó rút ra được những ưu – nhược điểm của từng mô hình. Luận văn giới thiệu một số chiến lược quản lý nghẽn như: hàng đợi FIFO, hàng đợi cân bằng trọng số, hàng đợi khách hàng, hàng đợi ưu tiên cũng như một số phương pháp tránh nghẽn như: RED, WRED, FRED, ARED. Các phương pháp này có thể được ứng dụng rộng rãi trong mạng viễn thông nhưng trong giới hạn của luận văn tôi chỉ tập trung nghiên cứu chúng trong mạng dịch vụ tích hợp, dịch vụ khác biệt. Luận văn cũng thực hiện lập trình mô phỏng xác định lượng băng thông cung cấp cho các luồng lưu lượng nhằm đánh giá mô hình DiffServ. Đảm bảo chất lượng dịch vụ cho mạng IP là một vấn đề lớn nên trong khuôn khổ luận văn này không thể nghiên cứu được đầy đủ, chi tiết hết về vấn đề kỹ thuật. Để có được cái nhìn tổng quan đầy đủ về giải pháp và ứng dụng QoS cho mạng IP còn nhiều vấn đề cần nghiên cứu như:  Nghiên cứu kiến trúc CQS. Kiến trúc này có trong mạng dịch vụ tích hợp và dịch vụ phân biệt. Kiến trúc CQS giúp làm tăng khả năng xử lý cho router trong vấn đề định tuyến các dịch vụ tích hợp.  Công nghệ Multimedia trên mạng IP.  Nghiên cứu các vấn đề kỹ thuật trong việc đảm bảo QoS IP và khả năng giám sát chất lượng dịch vụ trong mạng IP. V.v.v... Trên đây là những hướng nghiên cứu rất hấp dẫn mà chúng tôi hi vọng sẽ có điều kiện tiếp tục nghiên cứu trong một công trình dài hơi hơn. Luận văn đã đưa ra một cách tổng quát nhất về QoS IP cũng như đánh giá hai mô hình đảm bảo chất lượng dịch vụ mà tôi đã nghiên cứu trong thời gian qua. Tuy đã cố gắng để hoàn thành luận văn nhưng tôi chắc chắn sẽ không tránh khỏi những thiếu sót. Tôi rất mong được sự đóng góp ý kiến của các thầy cô và các bạn bè đồng nghiệp để luận văn được hoàn chỉnh hơn và tiếp tục được nghiên cứu trong tương lai. Tôi xin chân thành cảm ơn. 89 TÀI LIỆU THAM KHẢO Tiếng Việt [1] Trần Tuấn Hưng, “Phát triển và triển khai các giải pháp đảm bảo chất lượng dịch vụ trên nền mạng IP”. [2] Vũ Duy Lợi, Nguyễn Văn Vỵ, “Về đảm bảo chất lượng dịch vụ trên Internet”. [3] Vũ Hồng Sơn, Nguyễn Văn Dũng, Ngô Quang Thuận, “Đảm bảo chất lượng dịch vụ trên mạng IP bằng phương pháp Diffserv”. [4] Nguyễn Đình Việt, bài giảng “Đánh giá hiệu năng mạng máy tính”, 2008. Tiếng Anh [5] [DSTE-PRO] F. Le Faucheur, “Protocol Extensions for Support of DiffServ-aware MPLS Traffic Engineering” draft-ietf-tewg-diff-te-pro-03.txt, Feb 2002 [6] [E2E-QoS] V.FineBerg, “A Practical Architecture for Implementing End-to-End in an IP Network”, IEEE Communications Magazine, Jan 2002. [7]. Eitan Altman & Tania Jimenez , "Ns simulator for beginners", 2003-2004. [8] Grenville Armitage, “Quality of Service in IP networks”, April 07, 2000. [9] [10] [11] Jitae Shin, Daniel C. Lee, C.-C. Jay Kuo, “Quality of Service for Internet Multimedia”, July 24, 2003. [12] [MPLS-arch] Rosel et al. “Multiprotocol Label Switching Architechture” work in progress (draft -ietf-mplsframework-05) March 2000 [13] [MPLS-DiffServ] F. Le Faucheur, et al, “MPLS Support of Differentiated Services” RFC3270, May 2002. [14] Markus Peuhkuri, “IP Quality of Service”, Helsinki University of Technology, Laboratory of Telecommunications Technology, 2000. [15] Mario Marchese, “QoS over Heterogeneous Networks”, John Wiley & Sons, 2007. [16] Mike Flannagan CCIE No.7651, Richard Froom CCIE No.5102, Kevin Turek CCIE No.7284, “Cisco Catalust QoS: Quality of Service in Campus Networks”, June 06, 2003 [17] Quanlity of Service (QoS), Web Technology Document. [18]. The ns Manual, January 20, 2007, the VINT Project. 90 [19] Tim Szigeti - CCIE No. 9794, Christina Hattingh, “End-To-End QoS Network Design”, November 09, 2004 [20] WilliamC.Hardy, “QoS: Measurement and Evaluation of Telecommunications Quality of Service”, 2001. [21] The IETF Differentiated Services Working Group homepage, [22] [23] R. Braden, D. Clark and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC1633, June 1994. [24] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang and W. Weiss, "An Architecture for Differentiated Services", RFC2475, December 1998. [25] V.P. Kumar, T.V. Lakshman, D. Stiliadis, “Beyond Best Effort: Router Architectures for the Differentiated Services of Tomorrow’s Internet”, IEEE Communication Magazine, May 1998, pp. 152-164