1. Trang chủ
  2. » Kỹ Thuật - Công Nghệ

Chất lượng dịch vụ IP - Chương 3 pptx

27 180 1

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 27
Dung lượng 680,7 KB

Nội dung

43 Chương 3 MÔ HÌNH ỨNG DỤNG ðẢM BẢO QOS IP Chương này sẽ giới thiệu hai mô hình ứng dụng ñảm bảo QoS IP: Mô hình tích hợp dịch vụ IntServ và mô hình phân biệt dịch vụ DiffServ. Các kỹ thuật trình bày trong chương 3 sẽ ñược thảo luận chi tiết hơn trong từng mô hình. 3.1 MÔ HÌNH TÍCH HỢP DỊCH VỤ INTSERV 3.1.1 Các yêu cầu chức năng chung của IntServ. Mô hình dịch vụ tích hợp IntServ ñề xuất hai lớp dịch vụ bổ sung cho các dịch vụ IP truyền thống gồm:  Dịch vụ bảo ñảm GS cho ứng dụng yêu cầu giới hạn trễ và băng thông.  Dịch vụ ñiều khiển tải CL cho ứng dụng yêu cầu ñộ tổn thất gói thấp. Ý tưởng ban ñầu của các dịch vụ tích hợp là ñể hỗ trợ việc dành trước tài nguyên cho các luồng lưu lượng. Trái ngược với kiến trúc chuyển phát datagram (các gói sẽ ñi qua các tuyến khác nhau tại mọi thời ñiểm chúng ñược gửi), dịch vụ tích hợp cho phép dành toàn bộ một tuyến cho luồng dữ liệu. ðiều ñó ñược thực hiện bởi việc thiết lập một tuyến dành trước tài nguyên trước khi gửi dữ liệu. Thực chất của mô hình này là các bộ ñịnh tuyến và thiết bị mạng phải dành trước nguồn tài nguyên của nó ñể cung cấp các mức chất lượng dịch vụ cụ thể cho các gói mang lưu lượng người dùng. ðiều này yêu cầu các bộ ñịnh tuyến phải có khả năng ñiều khiển các luồng lưu lượng. Hình 3.1: Mô hình tích hợp dịch vụ Intserv 44 Cả hai lớp dịch vụ ñảm bảo và dịch vụ ñiều khiển tải phải ñược cài ñặt các ñường dẫn và dự trữ các tài nguyên trước khi truyền dữ liệu của họ. Sự ñiều khiển ñịnh tuyến sẽ quyết ñịnh cho việc có cấp nguồn cho yêu cầu hay không. Khi bộ ñịnh tuyến nhận ñược gói, bộ phân lớp sẽ thực hiện sự phân lớp ña trường và ñưa gói vào hàng ñợi ñặc biệt dựa trên kết quả của sự phân lớp. Cấu hình gói sau ñó sẽ lên lịch trình cho gói ñể ñạt ñược yêu cầu chất lượng dịch vụ của nó. Ứng dụng sẽ mô tả lưu lượng và tài nguyên nào mà nó sẽ cần. Sau ñó, mạng sẽ sử dụng giao thức dành trước tài nguyên (RSVP) ñể dành trước băng thông xác ñịnh trong mỗi bộ ñịnh tuyến dọc theo ñường ñi. Mỗi bộ ñịnh tuyến sẽ kiểm tra xem ở ñó nó có ñảm bảo tài nguyên ñược yêu cầu và duy trì tuyến khi ñược yêu cầu bởi yêu cầu dành trước tài nguyên. Khi tất cả các bước nhảy ñã ñược thiết lập, thiết bị gửi có thể gửi dữ liệu. Mô hình tích hợp dịch vụ IntServ mô tả các ứng dụng QoS trong mạng IP theo phương pháp nhận dạng luồng lưu lượng với 5 tham số cơ bản sau:  Nhận dạng giao thức  ðịa chỉ IP ñích  ðịa chỉ cổng ñích  ðịa chỉ IP nguồn  ðịa chỉ cổng nguồn ðể dự trữ tài nguyên cho một luồng lưu lượng, ứng dụng nguồn cần phải cung cấp các ñặc tính luồng. ðặc tính luồng gồm các ñặc tính lưu lượng và các yêu cầu chất lượng dịch vụ cho luồng ñó.  ðặc tính lưu lượng bao gồm tốc ñộ ñỉnh, tốc ñộ trung bình, kích thước bùng nổ và các tham số của gáo rò.  Các yêu cầu dịch vụ gồm băng thông tối thiểu và các yêu cầu hiệu năng như trễ, biến ñộng trễ và tỷ lệ tổn thất gói. Các dịch vụ tích hợp có thể ñược chia thành hai mặt bằng: mặt bằng ñiều khiển và mặt bằng dữ liệu.  Mặt bằng ñiều khiển thiết lập việc dành trước tài nguyên.  Mặt bằng dữ liệu thực hiện truyền dữ liệu. ðể yêu cầu một dành trước tài nguyên IntServ, trước tiên ứng dụng phải ñặc tính hoá ñược luồng lưu lượng của nó và tập hợp lại trong chỉ tiêu luồng lưu lượng. Sau ñó, yêu cầu thiết lập dự trữ tài nguyên có thể ñược gửi ñến mạng. Nếu có thể cam kết việc dự phòng, luồng ñó ñược ñưa vào bảng dự phòng tài nguyên. Khi gói tin ñến, khối lượng nhận dạng luồng sẽ nhận dạng gói tin thuộc về luồng ñặt trước và ñặt chúng vào trong hàng ñợi phù hợp ñể nhận ñược dịch vụ yêu cầu. 45 Việc lựa chọn ñường dẫn phù hợp cho chặng kế tiếp tại một nút là một nhiệm vụ khó khăn do các hạn chế trong việc ñịnh tuyến IP truyền thống. ðường dẫn cần ñược lựa chọn có thể ñã ñáp ứng ñược yêu cầu ñịnh ra. Tuy nhiên, ñịnh tuyến IP thường sử dụng các số ño như trễ, bước nhảy hay một số loại thông số khác ñể tính toán ñường ñi ngắn nhất. Do vậy, ñường dẫn ngắn nhất có thể không có ñược khả năng truyền tải, mặc dù ñường dẫn khác dài hơn lại có ñược khả năng ñó. Vấn ñề ñịnh tuyến có thể trở nên phức tạp hơn bởi một số ứng dụng có yêu cầu nhiều tham số QoS (ví dụ, cả băng thông và các yêu cầu về tổn thất gói tin). Tìm kiếm ñường dẫn phù hợp trong nhiều ñiều kiện ràng buộc rất phức tạp. Chính vì lý do ñó, mô hình ñảm bảo QoS cho IP ñầu tiên này không yêu cầu gắn các cơ chế ñịnh tuyến ñảm bảo QoS trong kiến trúc InterServ. Kiến trúc này giả sử rằng khối chức năng ñịnh tuyến của bộ ñịnh tuyến sẽ thực hiện ñịnh tuyến từng bước (hop by hop). Tài nguyên dành trước trong InterServ cần phải qua tất cả các nút trên ñường dẫn và thiết lập các dự phòng yêu cầu. Nó cũng phải truyền tải thông tin trong các phác thảo lưu lượng và các yêu cầu tài nguyên, do vậy mỗi nút cần quyết ñịnh liệu nó có chấp nhận việc dành trước hay không, nhận dạng luồng như thế nào và lập lịch cho gói tin. ðiều khiển chấp nhận Xử lý hai nhiệm vụ cơ bản là: Chấp nhận hay từ chối các yêu cầu dành trước và giám sát việc sử dụng tài nguyên. Việc dành trước tài nguyên cho một yêu cầu mới không thể ñược chấp nhận nếu nút không có sẵn tài nguyên yêu cầu. Có hai hướng tiếp cận ñể quyết ñịnh tài nguyên nào là sẵn sàng: Dựa trên ño ñạc và dựa theo tham số.  Trong hướng tiếp cận theo tham số, ñiều khiển chấp nhận sẽ tính toán các tài nguyên khả dụng dựa trên các chỉ tiêu kỹ thuật của yêu cầu dành trước tài nguyên hiện tại.  Trong hướng tiếp cận dựa theo ño ñạc, ñiều khiển chấp nhận ño lưu lượng thực sự trong mạng và sử dụng các phương pháp thống kê ñể quyết ñịnh xem liệu tài nguyên nào là khả dụng. Hướng tiếp cận này có ưu ñiểm là tối ưu hoá việc sử dụng mạng, mặc dù nó không thể ñảm bảo chặt chẽ các cam kết tài nguyên. Nhận dạng luồng RSVP Sử dụng 5 trường trong tiêu ñề gói tin IP ñể nhận dạng các gói tin thuộc về các luồng dành trước tài nguyên trong nút. Các trường này bao gồm: ñịa chỉ IP nguồn, ñịa chỉ IP ñích, nhận diện giao thức, cổng nguồn và cổng ñích. Lập lịch gói tin Là bước cuối cùng trong việc dành trước tài nguyên. Bộ lập lịch gói tin thực hiện việc 46 cấp pháp tài nguyên. Nó quyết ñịnh gói tin nào gửi kế tiếp khi tuyến kết nối ñi là sẵn sàng. Do ñó nó tác ñộng ñến trễ mà gói tin ñó phải chịu trong bộ ñịnh tuyến và bộ ñịnh tuyến không trực tiếp loại bỏ gói tin. 47 3.1.2 Giao thức dành trước tài nguyên RSVP (i) Giới thiệu chung Giao thức dành trước tài nguyên RSVP là một giao thức thiết lập tài nguyên dự phòng QoS IP, RSVP hỗ trợ cả IPv4 và IPv6 cũng như ứng dụng cho cả hai phương thức chuyển phát tin ñơn hướng và ña hướng (Unicast và multicast). Trong giao thức dành trước tài nguyên RSVP, các nguồn tài nguyên ñược dành trước theo các hướng ñộc lập. Máy chủ nguồn và máy chủ ñích trao ñổi các bản tin RSVP ñể thiết lập các trạng thái chuyển tiếp và phân loại gói tại mỗi nút. RSVP không phải là giao thức ñịnh tuyến mà là giao thức báo hiệu, các bản tin RSVP ñược chuyển ñi trên cùng ñường dẫn với các gói tin sẽ ñược chuyển và ñược xác ñịnh bởi bảng ñịnh tuyến trong bộ ñịnh tuyến IP.Các máy chủ sử dụng giao thức RSVP ñể yêu cầu QoS của mạng cho các luồng lưu lượng thực tế. Các bộ ñịnh tuyến sử dụng RSVP ñể tạo ra các yêu cầu QoS cho toàn bộ các bộ ñịnh tuyến dọc theo tuyến ñường gói tin chuyển qua mạng. Giao thức RSVP cũng sử dụng ñể duy trì và làm tươi trạng thái cho luồng ứng dụng yêu cầu QoS. Một số ñặc tính cơ bản của giao thức dành trước tài nguyên RSVP ñược liệt kê dưới ñây:  RSVP là giao thức báo hiệu ñể dành trước tài nguyên trong ñường dẫn từ nguồn tới ñích.  RSVP báo hiệu tới tất cả các thiết bị mạng về yêu cầu QoS của ứng dụng.  RSVP yêu cầu các ứng dụng khởi tạo yêu cầu.  RSVP hoạt ñộng liên ñiều hành với các kỹ thuật QoS khác ñể cải thiện ñộ ñảm bảo cho các tài nguyên dành trước. Giao thức dành trước tài nguyên RSVP thường ñược sử dụng cho các ứng dụng yêu cầu ñảm bảo các tham số băng thông và ñộ trễ. Các ứng dụng mạng hiện nay sử dụng RSVP như là giao thức báo hiệu gồm các ứng dụng cho VoIP và kỹ thuật lưu lượng MPLS (Multiprotocol Label Switching). RSVP ñược phát triển ñể chống lại tắc nghẽn mạng bằng cách cho phép các bộ ñịnh tuyến ñược quyết ñịnh ở mức cao. Tại mức này các bộ ñịnh tuyến có thể ñáp ứng các yêu cầu của một luồng ứng dụng và dự trữ tài nguyên mong muốn ngay cả khi mặt bằng chuyển tiếp gói không xử lý ñược. Mô hình báo hiệu RSVP ñược dựa trên xử lý ñặc biệt kiểu ña phương, mang bản tin báo hiệu tới các nút dọc tuyến ñường qua mạng theo luồng thực tế, quản lý trạng thái mềm, trao ñổi bản tin, dự phòng tài nguyên và tách báo hiệu QoS khỏi chức năng ñịnh tuyến. (ii) Hoạt ñộng của RSVP 48 Một phiên làm việc của giao thức dành trước tài nguyên RSVP thường sử dụng 3 tham số sau:  ðịa chỉ ñích  Nhận dạng giao thức  ðịa chỉ cổng ñích Hình 3.2 dưới ñây chỉ ra nguyên lý hoạt ñộng của RSVP. Máy chủ nguồn gửi bản tin Path tới ñích cho một luồng dữ liệu hay còn gọi là một phiên truyền thông. Bản tin Path chứa các ñặc tính cho luồng dữ liệu sẽ ñược gửi, bản tin Path ñi qua các bộ ñịnh tuyến trên ñường dẫn tới ñích. Các bộ ñịnh tuyến trên tuyến ñăng ký nhận dạng luồng và các ñặc tính luồng vào cơ sở dữ liệu. Bản tin Resv ñược phát ngược từ máy chủ nhận về máy chủ gửi nhằm xác nhận và chỉnh sửa các thông tin yêu cầu ñã ñược gửi ñi trong bản tin Path, ñây là các thông tin về dự phòng tài nguyên cho ñường dẫn mà gói tin sẽ ñược chuyển qua. Hình 3.2: Nguyên lý hoạt ñộng của RSVP RSVP giữ trạng thái mềm các tài nguyên trong các bộ ñịnh tuyến. Trạng thái mềm này ñược cung cấp ñộng theo các thông tin từ các thành viên trong phiên làm việc, tương thích với sự thay ñổi ñịnh tuyến và các yêu cầu thay ñổi tài nguyên của các luồng lưu lượng trong phiên. Thời gian làm tươi ñịnh kỳ thông thường là 30s. (iii) Các kiểu dành trước tài nguyên của RSVP Trong RFC 2205 [6] ñịnh nghĩa 3 kiểu dự phòng tài nguyên (minh hoạ trên hình 3.3). Hai kiểu ñiều khiển máy gửi ñược ñịnh nghĩa:  Kiểu lựa chọn hiện  Kiểu lựa chọn wildcard. Kiểu lựa chọn tuyến hiện liệt kê toàn bộ các máy gửi, trong khi ñó kiểu wildcard chỉ liệt kê toàn bộ máy chủ trong phiên. 49 Hình 3.3: Các kiểu dành trước tài nguyên ðiều khiển chia sẻ lưu lượng thực hiện ñiều khiển các ứng xử tài nguyên dành trước cho các máy gửi khác nhau trong cùng một phiên. Hai kiểu ñiều khiển chia sẻ lưu lượng ñược ñịnh nghĩa là:  Kiểu dành trước tài nguyên riêng biệt.  Kiểu dành trước tài nguyên chia sẻ. Trong kiểu dành trước tài nguyên riêng biệt, tài nguyên dành ñược tạo ra cho từng máy gửi. Trong kiểu dành trước tài nguyên chia sẻ, một tài nguyên chung ñược chia sẻ bởi các máy gửi trong phiên. Như chỉ ra trên hình 3.3 có 4 khả năng ñược tổ hợp từ các cách thức ñiều khiển chia sẻ tài nguyên và lựa chọn máy gửi. Tuy nhiên, một kiểu không ñược ñịnh nghĩa và ta còn 3 kiểu dành trước tài nguyên là: Kiểu bộ lọc cố ñịnh FF (Fixed Filter), Kiểu chia sẻ hiện SE (Shared Explicit) và kiểu bộ lọc Wildcard WF (Wildcard - Filter). (iv) Các dạng bản tin của RSVP Khuôn dạng bản tin RSVP có cấu trúc gồm một tiêu ñề chung và các trường chức năng thể hiện các ñối tượng như chỉ ra trên hình 3.4 (a). Mỗi một ñối tượng ñược cấu trúc bởi tiêu ñề ñối tượng và nội dung ñối tượng. Khuôn dạng tiêu ñề chung ñược chỉ ra trên hình 3.4 (b) có tổng ñộ dài là 8 bytes. Nó gồm 4 bit cho số hiệu phiên bản RSVP, 4 bit cờ, 8 bit sử dụng cho kiểu bản tin RSVP; 16 bit tổng kiểm tra, 8 bit sử dụng cho thời gian sống TTL của gói tin IP, 8 bit dự phòng và trường hiện thị ñộ dài bản tin gồm 16 bit. 50 Hình 3.4: Khuôn dạng bản tin RSVP và tiêu ñề chung RSVP Nếu trường tổng kiểm tra ñộ dài chứa toàn bộ giá trị 0, ñiều ñó thể hiện không cần kiểm tra các dữ liệu truyền ñi. ðộ dài bản tin RSVP bao gồm cả tiêu ñề và các ñối tượng trong bản tin. RSVP ñịnh nghĩa các kiểu bản tin sắp xếp theo thứ tự kiểu bản tin: 1. Path - Sử dụng ñể yêu cầu tài nguyên dành trước. 2. Resv - Gửi ñáp ứng bản tin ñường ñể thiết lập và duy trì dự trữ tài nguyên. 3. PathTear - Sử dụng ñể xoá dự trữ tài nguyên khỏi mạng theo hướng ñi. 4. ResvTear - Sử dụng ñể xoá bỏ tài nguyên khỏi mạng theo hướng về. 5. PathErr – Thông báo lỗi bản tin Path. 6. ResvErr - Thông báo lỗi bản tin Resv . 7. ResvConf – Là một bản tin tuỳ chọn, gửi ngược lại tới phía gửi của bản tin Resv ñể xác nhận rằng tài nguyên dự trữ xác ñịnh thực sự ñã ñược cài ñặt. 8. ResvTearConf - Sử dụng ñể xác nhận dự trữ tài nguyên xác ñịnh ñã bị xoá khỏi mạng. Khuôn dạng ñối tượng RSVP ñược chỉ ra trên hình 3.5 dưới ñây gồm 32 bit tiêu ñề ñối tượng và các nội dung ñối tượng có ñộ dài thay ñổỉ. Một ñối tượng ñộ dài có 32 bit ñịnh nghĩa ñộ dài tối ña cho phép của ñối tượng RSVP là 65,528 byte. Các ñối tượng RSVP ñược tổ chức thành lớp ñối tượng và kiểu ñối tượng. Hình 3.5: Khuôn dạng bản tin ñối tượng RSVP Trường chức năng “Class Num” ñịnh nghĩa lớp ñối tượng và trường chức năng “C Type” ñịnh nghĩa ñối tượng trong lớp. Các trường chức năng này tổ chức thành một cặp ñể mô tả các ñối tượng trong RSVP. Các lớp ñối tượng sau ñược ñịnh nghĩa trong RFC 2205.  NULL - Mô tả trạng thái của phiên.  SESSION – Mô tả phiên.  RSVP_HOP - Thể hiện các bước nhảy của bản tin RSVP.  TIME_VALUE – Mô tả giá trị thời gian chuyển tin.  STYLE – Mô tả kiểu bản tin. 51  FLOWSPEC – Mô tả ñặc tính luồng.  FILTER_SPEC – Mô tả ñặc tính bộ lọc.  SENDER_TEMPLATE - Mô tả khuôn dạng gói của ñối tượng gửi. ðối tượng FLOWSPEC chứa các tham số ñiều khiển lưu lượng gồm: tốc ñộ gáo rò token; kích thước gáo rò token, tốc ñộ ñỉnh , v v. ðối tượng kiểu bản tin (STYLE) ñược ñặt trong “Class num=8”, lớp này chỉ có một ñối tượng với C type -1. ðối tượng kiểu ñịnh nghĩa các kiểu dành trước tài nguyên. Hình 3.6: Khuôn dạng ñối tượng kiểu XX bit ðiều khiển chia sẻ 00 01 10 11 Dự phòng Tài nguyên phân biệt Tài nguyên chia sẻ Dự phòng Bảng 3.1: Các bit sử dụng cho ñiều khiển chia sẻ YYY bit ðiều khiển lựa chọn máy gửi 000 001 010 011-111 Dự phòng Lựa chọn Wildcard Lựa chọn hiện Dự phòng Bảng 3.2: Các bit sử dụng cho ñiều khiển lựa chọn máy gửi Hình 3.6 trên ñây chỉ ra khuôn dạng của ñối tượng kiểu. kiểu dành trước tài nguyên ñược ñịnh nghĩa bởi 5 bit cuối cùng. Trong ñó, 2 bit ñầu ñịnh nghĩa kiểu ñiều khiển chia sẻ tài nguyên và 3 bit ñiều khiển lựa chọn máy gửi. Ý nghĩa của các bit ñược thể hiện trong bảng 3.1 và bảng 3.2. 52 Hình 3.7: Cấu trúc bản tin Path và Resv trong RSVP Bản tin Path mô tả thông tin phiên truyền thông qua ñịa chỉ IP nguồn và ñịa chỉ IP ñích, cùng với một số ñặc tính của ñường ñi ñược phản ánh trong các ñối tượng RSVP_HOP và TIME_VALUE. Khuôn dạng của gói tin sẽ ñược chuyển ñi tương thích với các kiểu lọc ñược mô tả trong ñối tượng SENDER_TEMPLATE, các ñặc tính luồng của các ứng dụng từ máy gửi ñược mô tả trong ñối tượng SENDER_TSPEC. Cấu trúc bản tin Path ñược trình bày trên hình 3.7 (a). Trên hình 3.7 (b) mô tả cấu trúc chung của bản tin Resv, các ñối tượng của bản tin Resv nhằm xác nhận và sửa ñổi một số yêu cầu của bản tin Path cho phù hợp với hiện trạng thực tế của mạng. 3.2 MÔ HÌNH PHÂN BIỆT DỊCH VỤ DIFFSERV 3.2.1 Tổng quan về kiến trúc DiffServ. Kiến trúc mô hình phân biệt dịch vụ DiffServ ñược coi là bước phát triển tiếp theo của mô hình tích hợp dịch vụ IntServ. Một vấn ñề lớn nhất cò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. Với các mạng có số lượng dịch vụ và số lượng thiết bị mạng lớn, vấn ñề này trở nên khó khả thi ñối với các bộ ñịnh tuyến lõi cần phải xử lý lưu lượng rất lớn trong mạng. Tiếp cận của mô hình phân biệt dịch vụ DiffServ là 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. Trong DiffServ, băng thông và các tài nguyên mạng khác ñược chỉ ñịnh trong các lớp lưu lượng. Mặt khác, DiffServ hướng tới xử lý trong từng vùng dịch vụ phân biệt DS (Differential Service) thay vì xử lý từ ñầu cuối tới ñầu cuối như trong mô hình tích hợp dịch vụ IntServ. DiffServ chỉ cung cấp quan hệ ứng xử phân biệt tới các lớp lưu lượng, vì vậy DiffServ không cung cấp mức QoS cụ thể. ðể ñảm bảo một số mức chất lượng dịch vụ QoS cụ thể, DiffServ ñược hỗ trợ với ñiều khiển quản lý tại biên vùng DS nhằm phối hợp ñiều khiển các luồng lưu lượng vào mạng. Chất lượng dịch vụ ñược cung cấp bởi mô hình [...]... ñư c th hi n trên hình 3. 13 và trên b ng 3. 4 Hình 3. 13: 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 Th p 100010 AF42 Trung bình 100100 AF 43 Cao 100110 AF3 AF31 Th p 011010 AF32 Trung bình 011100 AF 33 Cao 100010 AF2 AF21 Th p 010010 AF22 Trung bình 010100 AF 23 Cao 010110 57 AF1 AF11 Th p 001010 AF12 Trung bình 001100 AF 13 Cao 001110 B ng 3. 4: Chi ti t các phân... 64 Tóm t t chương 3 Chương 3 t p trung vào hai mô hình ñ m b o ch t lư ng d ch v IP: mô hình tích h p d ch v IntServ và mô hình phân bi t d ch v DiffServ Các ñ c ñi m c a hai mô hình ñư c trình bày chi ti t nh m giúp ngư i ñ c n m b t rõ các khía c nh ng d ng c a hai mô hình trong m ng IP th c t M t s v n ñ ñư c trình bày trong chương 1 và chương 2 ñư c t ng k t và ng d ng trong chương 3 t o ra m... 1=40%, l p 2=60% 10 lu ng lưu lư ng ñ u vào như hình 1-BT3 Các lu ng lưu lư ng ñ u có kích thư c gói b ng nhau L p 1 x lý 2 lu ng L p 2 x lý 8 lu ng Yêu c u Xác ñ nh băng thông ñ u ra theo các lu ng ñ u vào 68 Tài li u tham kh o: 1 Kun I.Pack, QoS in Packet Network, The MITE coporation USA, Springer 2005 Print ISBN: 0 -3 8 7-2 33 89-X 2 Markus Peuhkuri, IP Quality of Service, Helsinki University of Technology,... trên hình1-BT1 Xác ñ nh tr ng thái Te và Tc sau 2 giây Bài 3: Xác ñ nh th t ưu tiên trong WFQ 67 Hình 1-BT3: Hàng ñ i cân b ng tr ng s Gi thi t: Có 3 hàng ñ i Hàng ñ i 1: 20% BW; Hàng ñ i 2: 30 % BW; Hàng ñ i 3: 50% BW Các gói có kích thư c như hình 1BT3 Yêu c u Xác ñ nh th t các gói t i c ng ñ u ra Bài 4: Xác ñ nh băng thông ñ u ra theo WRR Hình 1-BT4: Quay vòng tr ng s bit by bit Gi thi t: Mô hình hàng... phân thành 3 kh i ñư c g i là các pool B ng 3. 3 dư i ñây ch ra các kh i c a 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 B ng 3. 3: Các kh i ñi m mã d ch v phân bi t DSCP 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 Như v y, s phân l p d ch v c a pool 1 có th lên t i 32 và s... ToS trong tiêu ñ IPv4 (m c 1. 13) và trư ng phân l p lưu lư ng TC (Traffic Class) trong tiêu ñ IPv6 ñ ñánh d u gói ð i v i các b ñ nh tuy n ho t ñ ng trong mi n DS các trư ng ch c năng này ñư c thay b ng trư ng ch c năng d ch v phân bi t DS 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 dư i ñây ch ra c u trúc c a trư ng DS Hình 3. 11: C u trúc... QoS t p trung vào vi c h tr các d c tính IP QoS trong m ng Nói cách khác, m c tiêu là thi t l p ñi m tương ñ ng c a các ñ c tính QoS gi a IP và MPLS ch không ph i là làm cho MPLS QoS t t hơn IP QoS 59 M t lí do n a ñ kh ng ñ nh MPLS QoS không ph i là IP QoS là MPLS không ph i là giao th c xuyên su t MPLS không v n hành trong các máy ch và có th s t n t i các m ng IP không s d ng MPLS M t khác QoS là ñ... không thay ñ i v căn b n v mô hình d ch v IP Các nhà cung c p d ch v không bán d ch v MPLS, h cung c p các d ch v IP (hay Frame Relay và các d ch v khác), và do ñó n u h ñưa ra QoS thì ph i d a trên IP QoS (hay Frame Relay QoS,…) ch không ph i là MPLS QoS ði u này không có nghĩa là MPLS QoS không có vai trò như IP QoS Th nh t, MPLS giúp nhà cung c p ñưa ra d ch v IP QoS ch t lư ng hơn Th hai, hi n nay... tính b o m t và kh năng m m d o; h tr các giao di n t i các thi t b trong mi n Diffserv; h tr k thu t lưu lư ng trong các ng d ng m i như MPLS và GMPLS (RSVP-TE) Hình 3. 15: Th c hi n phân b nhãn qua RSVP-TE Các ñ c tính c a RSVP-TE [RFC 32 09] là s m r ng ph n lõi c a RSVP ñ thi t l p các tuy n ñư ng hi n d a trên ñ nh tuy n ràng bu c các LSP trong m ng MPLS s 61 d ng RSVP làm giao th c báo hi u D tr... Hình 3. 16: C u trúc b n tin RSVP-TE Các khuy n ngh m i ñ m r ng RSVP ñư c yêu c u tương thích hoàn toàn v i RSVP truy n th ng RSVP-TE có th d dàng phân bi t báo hi u thi t l p ñư ng LSP c a MPLS v i RSVP truy n th ng b ng cách ki m tra các ñ i tư ng ch a trong các b n tin Như v y h th ng báo hi u h p nh t mang m i ñ i tư ng c n thi t ñ thi t l p LSP m t cách m m d o Các ñ c ñi m cơ b n c a RSVP-TE h . mô hình dịch vụ IP. Các nhà cung cấp dịch vụ không bán dịch vụ MPLS, họ cung cấp các dịch vụ IP (hay Frame Relay và các dịch vụ khác), và do ñó nếu họ ñưa ra QoS thì phải dựa trên IP QoS (hay. lưu lượng ứng dụng trong mạng cung cấp dịch vụ, nó ñịnh nghĩa dịch vụ mà người sử dụng mong nhận ñược từ phía nhà cung cấp dịch vụ. Dịch vụ DiffServ ñược ñịnh nghĩa trong các thoả thuận mức dịch. trên bảng 3. 4. Hình 3. 13: 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 AF3 AF2 AF41 AF42 AF 43 AF31 AF32 AF 33 AF21 AF22 AF 23 Thấp

Ngày đăng: 23/07/2014, 20:21

TỪ KHÓA LIÊN QUAN

w