3. Cấu trúc các chương
2.2.5.5 Hàng đợi công bằng có trọng số WFQ và hàng đợi theo lớp
bằng có trọng số CB-WFQ
Mặc dù WRR đã khắc phục được nhược điểm thứ nhất của hàng đợi công bằng FQ nhưng WRR chưa giải quyết được ảnh hưởng của kích thước gói tin đối với băng thông chia sẻ. Hàng đợi WFQ nhằm giải quyết nhược điểm thứ hai của hàng đợi FQ. Giống như FQ lưu lượng đầu vào được nhóm vào m hàng đợi. Tuy nhiên băng thông đầu ra được phân bổ tới m hàng đợi theo trọng số được xác định bởi yêu cầu băng thông của các lớp lưu lượng thay vì chia đều. Trong FQ mỗi khi bộ lập lịch tới một hàng đợi, gói tin sẽ được truyền ra khỏi hàng đợi. Khác với FQ, bộ lập lịch WFQ sẽ tính toán thời gian hoàn thành của các gói tin ở đầu các hàng đợi và gửi các gói tin tới đầu ra theo thứ tự thời gian hoàn thành đó.
Hàng đợi CB-WFQ tương tự như hàng đợi WRR, sự khác biệt của CB-WFQ so với WRR là cách sử dụng cơ chế công bằng có trọng số tại các lớp i thay vì sử
dụng cơ chế hàng đợi công bằng. Tiếp cận này theo hướng mềm hoá hơn nữa đối với yêu cầu băng thông không đồng nhất.
2.2.6 Định dạng lƣu lƣợng (Traffic Shaping)
Định dạng lưu lượng là để điều hoà tốc độ luồng lưu lượng vào tại bộ đệm nhằm để đầu ra thay đổi “mềm mại” hơn. Theo ý tưởng như vậy các hành vi lưu lượng được điều chỉnh theo các dạng lưu lượng đã được xác định trước, ví dụ theo các thoả thuận mức dịch vụ SLA. Việc điều chỉnh tốc độ lưu lượng giống như quá trình dừng và đi, thời gian trễ tại bộ đệm sẽ làm các gói tin tại đầu ra được điều chỉnh theo yêu cầu. Có hai dạng định dạng lưu lượng thường dùng là định dạng lưu lượng thuần và định dạng lưu lượng “giỏ thẻ bài”.
2.2.6.1 Định dạng lƣu lƣợng “thuần” (Pure traffic shaping)
Hình 2.8: Định dạng lưu lượng thuần
Hình 2.8 chỉ ra nguyên lý định dạng lưu lượng thuần. Các gói tin đến được đưa vào bộ đệm (“giỏ”) có độ sâu d, sau đó được gửi ra liên kết đầu ra với tốc độ bằng hằng số, tốc độ hằng số này được gọi là tốc độ rò r.
Định dạng lưu lượng thuần giúp không gây ra bùng nổ lưu lượng trên các mức đầu ra. Thông thường tốc độ rò r luôn được chọn nhỏ hơn dải thông của đường truyền ra C (r<C). Tuy nhiên, với định dạng lưu lượng thuần, tốc độ rò r
có thể được đặt bằng hoặc xấp xỉ tốc độ lớn nhất của tốc độ đầu ra. Nếu kích Độ sâu của
giỏ d
Tốc độ rò r
Tốc độ gói đầu ra r
Các gói bùng nổ lưu lượng vào
thước bùng nổ gói tin đến vượt quá độ sâu của giỏ - d, thì các gói đến khi “giỏ” đầy sẽ bị loại bỏ.
2.2.6.2 Định dạng lƣu lƣợng kiểu giỏ có sử dụng thẻ bài (Token bucket)
Hình 2.9: Định dạng lưu lượng bùng nổ kiểu giỏ có sử dụng thẻ bài.
Hình 2.9 chỉ ra nguyên lý định dạng lưu lượng kiểu giỏ có sử dụng thẻ bài. Các thẻ bài được đưa vào giỏ với tốc độ bằng hằng số, được gọi là tốc độ thẻ bài
r. Tốc độ thẻ bài tương tự với tốc độ thông tin cam kết CIR. Độ sâu của giỏ d thể hiện kích thước bùng nổ cảm kết CBS. Nếu giỏ đầy, không một thẻ bài nào được đưa vào giỏ.
Mỗi một thẻ bài cho phép bộ đệm lưu lượng đầu vào gửi ra một byte dữ liệu. Khi không còn gói nào trong bộ đệm được gửi ra, đáy của giỏ được đóng lại và không một thẻ bài nào được lấy ra. Khi vẫn còn gói tin trong bộ đệm, thẻ bài được rút ra theo tốc độ liên kết đầu ra (C) và các gói được chuyển tới đầu ra. Nếu giỏ xả hết các thẻ bài, các gói trong bộ đệm phải đợi cho đến khi các thẻ bài được đưa vào giỏ.
Độ sâu của giỏ d
Tốc độ rò C Kích thước bộ đệm B Tốc độ liên kết C Thẻ bài khả dụng Tốc độ thẻ bài r Các gói bùng nổ lưu lượng vào
Tràn bộ đệm
Kết quả của hoạt động này là các gói tin được chuyển tới liên kết đầu ra tại tốc độ liên kết C. Kích thước bùng nổ được giới hạn bởi độ sâu của giỏ d. Khi các thẻ bài được đưa vào trong giỏ với tốc độ r, thì tốc độ trung bình dài hạn của gói tại đầu ra là r.
CHƢƠNG 3. MÔ HÌNH DỊCH VỤ TÍCH HỢP INTSERV
3.1 Tổng quan IntServ
Ý tưởng ban đầu của 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 thông thường (các gói có thể đi qua các tuyến khác nhau để tới đích), dịch vụ tích hợp cho phép thiết lập một tuyến và dành trước tài nguyên trước khi gửi dữ liệu. Đ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. Có hai dịch vụ được định nghĩa:
Dịch vụ đảm bảo - GS (Guaranteed Service) áp dụng cho các dịch vụ với yêu cầu về độ trễ của dịch vụ được xác định trước.
Dịch vụ tải được điều khiển - CLS (Controlled-Load Network Service) áp dụng cho các ứng dụng yêu cầu độ tổn thất gói thấp.
Trong IntServ một luồng IP đơn lẻ được xác định bởi các tham số cơ bản sau: Định danh 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 phải cung cấp đặc tả luồng. Đặc tả luồng bao gồm các đặc tính về 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ổ lưu lượng và các tham số của “giỏ thẻ bài” (token bucket). 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 về hiệu năng như trễ, biến động trễ và tỷ lệ tổn thất gói.
Sau đó yêu cầu thiết lập dự trữ tài nguyên có thể được gửi tới mạng. Nếu có 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 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.
Trong quá trình truyền từ nguồn tới đích gói tin phải đi qua nhiều chặng. 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à nhiệm vụ khó khăn do các hạn chế trong định tuyến IP truyền thống. Bộ định tuyến IP thường sử dụng các số đo như trễ, chặng (hop) hay một số thông số khác để tính toán đường đi ngắn nhất. Tuy nhiên đường dẫn ngắn nhất có thể không có được khả năng truyền tải trong khi đó đường dẫn dài hơn lại có khả năng đó. Vấn đề định tuyến có thể trở nên phức tạp bởi một số ứng dụng yêu cầu nhiều tham số QoS (ví dụ về 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 gói tin 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 IntServ. 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 theo từng chặng.
3.2 Kiến trúc IntServ
Hình 3.1: Mô hình hoạt động dịch vụ tích hợp IntServ
IntServ có 4 thành phần, thành phần điều khiển việc chấp nhận, thành phần phân loại, lập lịch (3 thành phần này cung cấp việc điều khiển lưu lượng) và giao
Quản lý chính sách Điều khiển chấp nhận Bảng định tuyến Phân loại Lập lịch Số liệu Tiến trình RSVP Quản lý chính sách Điều khiển chấp nhận Bảng định tuyến Phân loại Lập lịch Tiến trình RSVP RESV Hướng đăng kí
PATH
thức dành trước tài nguyên. Hình 3.1 minh hoạ mô hình hoạt động của dịch vụ tích hợp IntServ.
3.2.1 Đ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 tài nguyên 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 không có sẵn tài nguyên được yêu cầu. Có hai hướng tiếp cận để giải quyết xem tài nguyên nào là sẵn sàng đó là dựa theo đo đạc và dựa theo tham số.
Trong hướng tiếp cận dựa theo tham số, điều khiển chấp nhận sẽ tính toán các nguồn tài nguyên khả dụng dựa trên các chỉ tiêu kỹ thuật và yêu cầu dành trước tài nguyên hiện tại.
Trong hướng tiếp cận 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 tài nguyên nào 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ù không đảm bảo chặt chẽ các cam kết tài nguyên.
3.2.2 Phân loại
Giao thức RSVP sử dụng 5 tiêu đề trong gói tin IP để nhận dạng gói tin thuộc về các luồng đã yêu cầu 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 danh giao thức, cổng nguồn và đích.
3.2.3 Lập lịch
Là bước cuối cùng trong việc dành trước tài nguyên. Nó quyết định gói tin nào sẽ được gửi kế tiếp khi tuyến kết nối đi đã 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. Các kỹ thuật của bộ lập lịch đã được trình bày ở chương trước.
Kiến trúc IntServ định nghĩa hai loại dịch vụ chính: Dịch vụ đảm bảo GS và dịch vụ tải được điều khiển CLS. Mỗi dịch vụ này cung cấp một dạng rất khác của đảm bảo QoS. [2]
Dịch vụ đảm bảo: được định nghĩa trong RFC 2212 [8], cung cấp các giới hạn cứng về các độ trễ xếp hàng mà gói tin sẽ phải trải qua trong một router. Về bản chất, một phiên yêu cầu GS là yêu cầu các bit trong gói tin của nó được đảm bảo truyền đi với tốc độ không dưới một giá trị nhất định.
Dịch vụ tải được điều khiển: được định nghĩa trong RFC 2211 [8]. Một phiên nhận CLS sẽ nhận một QoS xấp xỉ với QoS mà cùng luồng đó sẽ nhận từ một phần mạng không có tải. Nói cách khác, phiên có thể thừa nhận rằng “một tỉ lệ phần trăm rất cao” của các gói tin sẽ đi qua router thành công mà không bị loại bỏ và sẽ chịu một độ trễ xếp hàng trong router gần như bằng 0. Thật thú vị, CLS không tạo ra một sự đảm bảo chất lượng thực thi – nó không chỉ định cái gì cấu thành “một tỉ lệ phần trăm rất cao” của các gói tin hay QoS gì gần xấp xỉ với QoS của một phần mạng không có tải. CLS hướng tới các ứng dụng đa phương tiện được phát triển cho Internet ngày nay. Những ứng dụng này hoạt động khá tốt khi mạng có tải nhẹ, nhưng hiệu suất lại giảm mạnh khi mạng ở trong trạng thái tải nặng hơn nhiều.
3.3 Giao thức dành trƣớc tài nguyên - RSVP (Resource Reservation Protocol)
3.3.1 Giới thiệu chung
Giao thức dành trước tài nguyên RSVP được giới thiệu trong RFC 2205 [8]. RSVP là một giao thức thiết lập tài nguyên dự phòng để đảm bảo QoS trong mạng IP. Nó 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).
Máy chủ nguồn và máy chủ đích trao đổi các thông báo 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 trung gian (router). Máy chủ nguồn khởi tạo yêu cầu dành tài nguyên nhưng việc xác định nguồn tài
nguyên sẵn sàng và yêu cầu tài nguyên thực tế lại bắt nguồn từ máy chủ đích. Trạng thái dành tài nguyên tại các nút RSVP không phải là cố định mà có thể làm mới theo định kỳ.
RSVP không phải là giao thức định tuyến mà là giao thức báo hiệu, các thông báo RSVP được chuyển đi trên cùng một đường dẫn với các gói tin sẽ được chuyển đi và được xác định bởi bảng định tuyến trong bộ định tuyến IP. Các nút dọc theo tuyến phải giữ trạng thái dành tài nguyên, do vậy khi mạng lớn RSVP sẽ trở nên không thực tế và khó mở rộng.
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 truyền qua mạng. Giao thức RSVP cũng sử dụng để duy trì và làm mớ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 trên đườ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 kết với các thiết bị 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 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 giao thức RSVP bao gồm VoIP, kỹ thuật chuyển mạch nhãn đa giao thức - MPLS (Multiprotocol Label Switching).
Hình 3.2: Nguyên lý hoạt động của RSVP
Hình 3.2 chỉ ra nguyên lý hoạt động của RSVP. Máy chủ nguồn gửi thông báo PATH cho một luồng dữ liệu hay còn gọi là một phiên truyền thông. Thông báo PATH chứa những đặc tính của luồng dữ liệu sẽ được gửi và đ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 luồng và các đặc tính của luồng vào cơ sở dữ liệu để khi thông báo RESV tương ứng được gửi ngược từ máy chủ nhận, bộ định tuyến sẽ so sánh thông tin tương quan chứa trong thông báo PATH và RESV. Khi máy chủ nhận nhận được thông báo PATH nó sẽ gửi thông báo RESV nhằm xác nhận và chỉnh sửa thông tin yêu cầu đã được gửi trong thông báo PATH, đây là thông tin về việc dành trước tài nguyên cho đường dẫn mà gói tin sẽ được đi qua.
RSVP giữ trạng thái mềm cho các tài nguyên trong bộ định tuyến. Trạng thái mềm này được cung cấp 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 mới định kì là 30s.
3.3.3 Các kiểu dành trƣớc tài nguyên RSVP
Có ba kiểu dự phòng tài nguyên được định nghĩa trong RFC 2205 [8] minh họa 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 hiện liệt kê một danh sách máy gửi, trong khi đó kiểu lựa chọn wildcard liệt kê toàn bộ máy chủ trong phiên.
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 được tạo ra cho từng máy gửi. Trong kiểu dành trước tài nguyên chi 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, 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 (Shared Explicit) và kiểu bộ lọc Wildcard WF (Wildcard - Filter).
3.3.4 Định dạng thông báo RSVP
Thông báo RSVP gồm một tiêu đề chung và các đối tượng như trên hình 3.4