Nghiên cứu chất lượng dịch vụ trong mạng IP

n đánh dấu và một bit trong phần tiêu đề gói tin chỉ ra cho bộ phận đánh dấu có thể tìm ra gói tin đó thuộc loại ưu tiên hay không. RIO khác với WRED ở chỗ nó hiệu chỉnh hàm EWMA dựa trên đánh dấu gói tin. Mục đích của RIO là phân biệt những gói tin trong những thời gian tắc nghẽn. Nó làm điều đó bằng cách chạy hai thuật toán chiếm dụng EWMA song song trên cùng một hàng đợi- QavgIN cho những gói tin vào và QavgOUT cho những gói tin ra. Tương tự hình 3.13, hai bộ giá trị minTH, maxTH và minP một cho gói tin vào và một cho gói tin ra. MinTH và maxTH cho những gói tin vào nhỏ hơn cho những gói tin ra, trong khi đó minP cho những gói tin ra lớn hơn cho những gói tin vào. Khi tính toán hàm xác suất huỷ cho những gói tin vào, mức chiếm dụng hàng đợi được lấy từ QavgIN, trong khi cho những gói tin ra, mức chiếm dụng hàng đợi được lấy từ QavgOUT. QavgIN dựa trên mức chiếm dụng hàng đợi trung bình của từng gói tin riêng lẻ, trong khi QavgOUT dựa trên tổng số mức chiếm dụng hàng đợi trung bình (của cả những gói tin vào và ra). Trong thuật toán này, số lượng gói tin đi ra khỏi hàng đợi không ảnh hưởng tới xác suất huỷ bỏ của những gói tin vào hàng đợi. 4.4.3.3 Tương thích RED Với sự có mặt của ít luồng TCP, tắc nghẽn có thể hình thành tương đối chậm và Wq có thể thấp. Tuy nhiên việc cùng một giá trị Wq trong trường hợp nhiều luồng TCP dẫn đến pha tránh tắc nghẽn của RED không đáp ứng đủ sớm hoặc đủ mạnh. Ngược lại, chọn lọc Wq cho phép RED đối phó đủ nhanh với nhiều luồng TCP có thể dẫn tới mất gói trường hợp mất gói toàn bộ khi ít luồng TCP chia sẻ một hàng đợi. Hình 4.11: ARED thay đổi giá trị maxp ARED cố gắng giải quyết vấn đề này bằng cách cho phép RED cải tiến các tham số dựa trên lịch sử tắc nghẽn gần đây. ARED tập trung vào N kết nối chia sẻ một hàng đợi, hiệu quả bất kì sự huỷ gói tin nào mà RED gây ra là giảm tải trọng bởi hệ số (1-1/(2*N)). Nói cách khác, khi N tăng, RED cần hoạt động mạnh hơn để đạt được hiệu quả không đổi.. Để giải quyết vấn đề này, ARED điều chỉnh maxP dựa trên sự thay đổi gần nhất của Qavg. Nếu Qavg thấp hơn minth, maxp được tính lại thận trọng hơn. Nếu Qavg tăng lên quá maxth, giá trị maxp lớn hơn được tính lại. Nếu Qavg dao động quanh minth, ARED giảm maxp một cách liên tục. Nếu Qavg dao động quanh maxth, maxp tăng liên tục (do sự huỷ gói không bị ảnh hưởng), hình 4.11. Kết quả là thuật toán ARED thay đổi tải trong hàng đợi do tăng hay giảm số lượng luồng TCP đi qua hàng đợi đó ở bất kì thời điểm nào. Thuật toán hoạt động không đòi hỏi bất cứ thông tin mở rộng chính xác nào về số lượng các luồng. 4.4.3.4 Luồng RED Nhận diện luồng ngẫu nhiên sớm (FRED) là một thuật toán RED tinh vi hơn. Giải pháp để giải quyết xu hướng không công bằng khi hàng đợi bị chia sẻ bởi nhiều luồng có thông báo tắc nghẽn sớm khác nhau. Đặc tính này được gọi là “Nhận diện tắc nghẽn sớm động”: Những luồng không tương thích - giao thức truyền tải lờ đi việc huỷ bỏ gói. Những luồng tốc độ cao - những kết nối TCP với thời gian trễ vòng (RTT) ngắn, do đó phải nhanh chóng khôi phục những gói tin bị huỷ. Những luồng tốc độ thấp - những kết nối TCP với RTT dài, do đó chậm khôi phục những gói tin bị huỷ. Khi có sự trộn lẫn giữa những luồng trên qua một hàng đợi có thuật toán quản lý RED, những luồng không tương thích có thể đặt Qavg trên giá trị minTH và do đó gây nên mất gói cho tất cả các luồng thậm chí cả khi những luồng khác cũng làm như vậy. Tương tự như vậy, những luồng tốc độ cao ít bị ảnh hưởng bởi việc mất bất kỳ gói đơn lẻ nào hơn là những luồng tốc độ thấp do tốc độ khôi phục gói tin TCP phụ thuộc vào RTT của luồng. Hiệu quả chung là những thông báo tắc nghẽn ảnh hưởng khác nhau tới những luồng khác nhau. FRED kiểm soát tình trạng này bằng cách điều chỉnh cách ứng xử với từng gói tin bị huỷ dựa trên những trạng thái ngắn hạn của từng luồng (chỉ với những luồng có những gói tin trong hàng đợi). Hai biến minq và maxq đại diện cho số lượng gói của bất kì luồng nào được đặt trong hàng đợi. Biến Avgcq đại diện cho số lượng gói trung bình ước lượng của mỗi luồng trong hàng đợi. Khi Qavg thấp hơn maxTH, FRED luôn chấp nhận những gói tin của những luồng có nhỏ hơn minq gói tin trong hàng đợi. Thiết lập minq giữa 2 và 4 đảm bảo không gian hàng đợi thấp nhất cho những kết nói tốc độ thấp. Nếu luồng có nhiều hơn minq gói trong hàng đợi, FRED huỷ các gói mới bất chấp Qavg. Khi một luồng có số lượng gói giữa minq và maxq trong hàng đợi, FRED sử dụng RED thông thường để nhận ra gói mới được chấp nhận hay phải huỷ bỏ. Mặc dù FRED không đòi hỏi xếp hàng từng luồng nhưng nó đòi hỏi những bộ định tuyến thiết lập tình trạng cho từng luồng, thêm vào vài sự phân loại tương ứng với sự thay đổi trước của RED. 4.5 Lập lịch Lập lịch điều khiển đặc trưng thời gian của việc lưu thoát gói khỏi mỗi hàng đợi - thường tại giao diện đầu ra hướng tới router hoặc host tiếp theo, nhưng cũng có thể là tại các điểm hàng đợi trong một router. Các router truyền thống chỉ có một hàng đợi đơn trên một giao diện kết nối đầu ra. Như vậy lập lịch có nhiệm vụ đơn giản là lôi các gói ra khỏi hàng đợi nhanh bằng khả năng kết nối có thể chuyển được. Trong các router có kiến trúc CQS, mỗi giao diện có một tầng bộ lập lịch chia sẻ khả năng chứa của kết nối đầu ra giữa sự kết hợp các hàng đợi trong giao diện. Chia sẻ kết nối đạt được một sự sắp xếp lịch, khi nào và xảy ra như thế nào. Bộ lập lịch chủ yếu cưỡng chế quyền ưu tiên tương đối, hạn chế trễ, hoặc băng thông chủ định giữa các lớp lưu lượng khác nhau. Một bộ lập lịch có thể thiết lập băng thông khả dụng nhỏ nhất cho một lớp đặc biệt bằng cách đảm bảo rằng các gói được lấy ra khỏi hàng đợi có quan hệ với các lớp đó một cách thông thường. Một bộ lập lịch cũng có thể cung cấp định hướng tốc độ. Bằng cách giới hạn tần số trong hàng đợi của lớp nào được phục vụ dựa vào thiết kế của một bộ lập lịch, nó có thể áp đặt hai giới hạn băng thông dưới và trên trên cho mỗi hàng đợi hoặc cho một số hàng đợi . Tất cả các thiết kế bộ lập lịch có những kiểu dịch vụ đặc trưng của riêng nó – cách mà nó lựa chọn hàng đợi dịch vụ. Bộ lập lịch đơn giản nhất tập trung vào hàng đợi phục vụ trong một số hàng đợi dự đoán trước. Các bộ lập lịch tiên tiến hơn cho phép tương đối hoặc toàn bộ băng thông để thiết lập cho mỗi hàng đợi và chúng tiếp tục hỗi trợ thêm vào các kiểu dịch vụ để đảm bảo băng thông trung bình hoặc trễ đạt được bởi mỗi hàng đợi giới hạn trong cấu hình. 4.5.1 Định hướng tốc độ “Rate shaping” Giống như kiểm soát và đánh dấu, “Rate shaping”sử dụng giới hạn hoặc cưỡng chế sự không tiên đoán được của lớp lưu lượng nhất định. Khác với kiểm soát và đánh dấu “Rate shaping” yêu cầu các hàng đợi, quản lý hàng đợi và lập lịch – không kể có hay không chức năng định hướng được xây dựng vào một bộ lập lịch chịu tác động một kết nối chia sẻ hoặc hoạt động độc lập. Tại sao lại làm như vậy? Mộ hệ thống cho phép hàng đợi làm rỗng nhanh tới mức có thể (được giới hạn bởi tốc độ dòng đầu ra hoặc tốc độ truyền dẫn của tầng chuyển mạch), Nó thấy được sự tăng lên trong sự bùng nổ đường xuống của lưu lượng chuyển qua hàng đợi đó. Thậm chí nếu nguồn lưu lượng truyền thống đang truyền gói tại tốc độ ổn định tương đối thì sự hoà hợp của nhiều nguồn bùng nổ không đáng kể đi qua nhang tới mức có thể được mà các điểm đạt được trong sự tăng bùng nổ. Các bùng nổ thêm vào này có thể dẫn tới việc kiểm soát không cần thiết, sự xâm chiếm quản lý hàng đợi tích cực, hoặc chắc chắn hàng đợi tràn luồng xuống. Định hướng có thể cũng giúp cân bằng mong muốn khác nhau. Nếu khách hàng thường xuyên nhận tín hiệu tốt hơn băng thông đảm bảo cực tiểu, thì một nhận thức xuất phát từ bên ngoài khách hàng bắt đầu kết hợp hoạt động truyền thống mà họ thấy tín nhiệm. Nếu sức chứa để dành luôn co hẹp lại, khách hàng sẽ nhận hoạt động edge – to – edge kết thúc tốc độ đảm bảo và giống như được nhận ra sự thay đổi này như một sự xác nhận xuống cấp, khi đó định hướng tốc độ có thể ưu tiên hơn cho các dịch vụ này. Định hướng tôc độ ưu tiên từ thời gian kết nối khách hàng giup định hướng hy vọng khả năng dài hạn của dịch vụ. Bộ lập lịch và gáo rò. Định hướng tốc độ đạt được bởi giới hạn tốc độ trong hàng đợi được dịch vụ, thậm chí khi bộ lập lịch có hoặc không có gì cả. Nếu các gói tới nơi trong một khoảng thời gian liên gói ngắn hơn được xem xét bởi bộ lập lịch chúng được xếp hàng – trôi ra khỏi sự bùng nổ thông thường. Hình 2.6 biểu diễn một bộ lập lịch không bao giờ lấy mẫu đỉnh hàng đợi thườn xuyên hơn một lần T giây. Các gói được dời đi cách nhau các khoảng T giây. Việc định hướng không bắt buộc các bộ lập lịch chia sẻ kết nối thông thường. Định hướng cũng có thể áp dụng một hàng đợi đơn độc lập với các hàng đợi khác trong hệ thống. Như là một viễn cảnh thường được ấn định cho một gáo rò, các gói qua lỗ thủng ra bê ngoài ở một tốc độ cố định. Thông thường, một tầng định hướng gắn kết quả tốc độ phát gói của nó trong tốc độ bit khả dụng biến đổi (bởi vì các gói IP thay đổi kích thước từ gói này sang gói khác). Nếu thúc đẩy định hướng tránh quá tải thì giai đoạn xử lý chậm hơn giới hạn gói trên giây, tiếp cận này có thể được chấp nhận. Tuy nhiên, nếu sự định hướng được dùng cho cưỡng bức tốc độ trung bình qua hàng đợi thì khoảng thời gian phục vụ cần thiết thay đổi một cách mềm dẻo. 4.5.2 Lập lịch đơn giản Các bộ lập lịch đơn giản nhất tập trung vào việc phục vụ các hàng đợi trong một vài thứ tự có thể dự đoán trước. Mục đích của chúng là điều chỉnh các chu kỳ dịch vụ hơn là độ thông qua nhận được bằng lưu lượng chuyển qua chúng. 4.5.2.1 Ưu tiên tuyệt đối Một kỹ thuật lập lịch bao gồm phân loại các hàng đợi bằng cách giảm dần độ ưu tiên và phục vụ một hàng đợi tại mức ưu tiên đã được đưa ra chỉ khi các hàng đợi có mức ưu tiên cao hơn rỗng. đường liên kết hàng đợi 1 hàng đợi 2 hàng đợi 3 hàng đợi 4 bộ lập lịch Hình 4.12 Nhiều hàng đợi cho một bộ lập lịch Trong hình vẽ trên, bộ lập lịch coi hàng đợi 1 có độ ưu tiên cao hơn hàng đợi 2, hàng đợi 2 có độ ưu tiên cao hơn hàng đợi 3, hàng đợi 3 lại có độ ưu tiên cao hơn hàng đợi 4. Hàng đợi 1 được phục vụ với tốc độ phù hợp với tuyến có thể truyền các gói mỗi khi hàng đợi có các gói phải đợi. Chỉ khi hàng đợi 1 rỗng, bộ lập lịch mới xem xét đến hàng đợi 2, cũng tương tự như vậy, nó được phục vụ tại tốc độ truyền dẫn của tuyến nếu có gói sẵn sàng để truyền đi và hàng đợi 1 rỗng. Tương tự như vậy, hàng đợi 3 được phục vụ tại tốc độ tuyến khi hàng đợi 1 và 2 rỗng. Hàng đợi 4 được phục vụ tại tốc độ tuyến khi hàng đợi 1, 2 và 3 rỗng. Tuy nhiên, nguyên tắc dịch vụ (service discipline) này cho phép các hàng đợi có độ ưu tiên cao làm cho các hàng đợi có độ ưu tiên thấp thiếu băng tần. Ví dụ, nếu lớp lưu lượng được sắp xếp vào hàng đợi 1 chiếm 100% năng lực của tuyến đầu ra trong một khoảng thời gian thì bộ lập lịch sẽ không bao giờ quay vòng để phục vụ các hàng đợi 2, 3 hay 4. Để tránh sự thiếu hụt này, trong trường hợp đặc biệt, chính sách luồng hay định dạng tốc độ phải được giới thiệu để đảm bảo rằng lớp lưu lượng đặt vào hàng đợi 1 không bao giờ được chiếm hết năng lực của tuyến đầu ra. Việc thực hiện này đảm bảo rằng hàng đợi 1 rỗng thường xuyên hơn, cho phép bộ lập lịch phục vụ các hàng đợi có độ ưu tiên thấp hơn. Lập lịch theo độ ưu tiên rất hữu ích trong việc cung cấp cho lớp lưu lượng có độ trễ thấp. Giả sử rằng lớp X yêu cầu độ trễ từ đầu cuối đến đầu cuối thấp, được sắp xếp vào hàng đợi có độ ưu tiên cao nhất trên từng chặng, tốc độ của lớp lưu lượng này được định dạng hoặc giới hạn để không làm các hàng đợi khác bị "đói". Xét xem điều gì xảy ra nếu một gói từ lớp X đến. Nếu bộ lập lịch rỗi, hàng đợi có độ ưu tiên cao nhất sẽ được phục vụ ngay lập tức, nếu bộ lập lịch bận vì đang truyền một gói từ hàng đợi khác, hàng đợi có độ ưu tiên cao nhất chỉ đợi với điều kiện nó chỉ truyền gói đó. Độ trễ trong trường hợp xấu nhất phụ thuộc vào tốc độ đường truyền và kích thước tối đa của gói, hay đơn vị truyền tối đa (MTU-Maximum Transmission Unit) của tuyến. 4.5.2.2 Round-Robin Một thuật toán có thể được lựa chọn có tên là Round-Robin, tránh sự thiếu hụt hàng đợi bằng cách quay vòng chúng. Các hàng đợi rỗng được bỏ qua, bộ lập lịch luôn luôn chuyển đến hàng đợi kế tiếp trong chuỗi có gói được truyền. Hình 4.12 là một ví dụ, các hàng đợi có thể được quay vòng theo thứ tự: 1, 2, 3, 4, 1, 2, 3, 4,... liên tiếp. Nếu mỗi hàng đợi có các gói để truyền, việc truyền dẫn sẽ được lập lịch phù hợp với hàng đợi. Nếu một vài hàng đợi rỗng, các hàng đợi còn lại sẽ được phục vụ nhiều hơn, trong một vài trường hợp, một lớp có thể nhận tất cả băng tần của tuyến nếu các hàng đợi khác rỗng (ví dụ, bộ lập lịch lấy các gói từ hàng đợi 3 cũng như tuyến cho phép nếu các hàng đợi 1, 2 và 4 không có bất kỳ lưu lượng nào). Để tránh sự thiếu hụt, khi một gói đến một hàng đợi rỗng, hàng đợi đó được phục vụ trong khi vẫn quay vòng bộ lập lịch. Nhược điểm của việc lập lịch Round-Robin là việc giới hạn độ trễ rất khó thực hiện. Không giống như việc lập lịch ưu tiên, nó không thể phân một hàng đợi cho lưu lượng có độ trễ thấp. Chu kỳ phục vụ hàng đợi phụ thuộc hoàn toàn vào việc có bao nhiêu hàng đợi khác chứa các gói tại thời điểm đó và độ dài của các gói đó. Xét một giao diện với N hàng đợi, một đường truyền với tốc độ Lrate và một đơn vị truyền tối đa (MTU) Plen. Thời gian cần để truyền một gói với kích thước MTU (gói dài nhất có thể được truyền) là Plen/Lrate. Vì vậy trong trường hợp xấu nhất, một gói có thể đến một hàng đợi rỗng đã bị bỏ qua và phải chờ (N-1)*(Plen/Lrate)(s) cho đến khi bộ lập lịch quay vòng trở lại. 4.5.3 Lập lịch tương thích DRR (Deficit Round Robin) là sự mở rộng của RR. DRR xem có bao nhiêu byte được truyền từ một hàng đợi cho trước, so sánh với số byte phải được truyền và xem xét sự khác nhau đó. Sự khác nhau này được sử dụng để thay đổi chu kỳ dịch vụ của hàng đợi, bằng cách đó, điều chỉnh tốc độ bít đạt được bởi mỗi hàng đợi. DRR chỉ định cho mỗi hàng đợi một hằng số QN (cũng được gọi là quantum), và một biến DN (cũng được gọi là deficit). QN thể hiện số lượng byte trung bình dài hạn trong mỗi chu kỳ mà chúng ta muốn hàng đợi truyền. DN được khởi đầu là 0 cho tất cả các hàng đợi và được thiết lập lại là 0 bất cứ khi nào 1 hàng đợi rỗng. Khi bộ lập lịch đi đến một hàng đợi mới, nó xác lập lại bộ đếm Bsent, phản ánh số byte được truyền từ hàng đợi hiện tại trong vòng này. Các gói được truyền từ hàng đợi N hiện tại nếu có 2 điều kiện sau: - Hàng đợi có gói để truyền. - (QN+DN) ≥ (Bsent+số byte trong gói kế tiếp trong hàng đợi). Nếu hàng đợi rỗng, DN được xác lập lại là 0. Tuy nhiên, nếu bộ lập lịch ngừng hoạt động trước khi hàng đợi rỗng, sẽ tồn tại một lượng chênh lệch giữa số lượng byte được hy vọng truyền (QN+DN) và số lượng byte truyền Bsent. DN của hàng đợi được thiết lập lại là (QN+DN –Bsent) và bộ lập lịch di chuyển đến hàng đợi tiếp theo. Đối với mỗi hàng đợi, giá trị (QN+DN) thể hiện số byte lớn nhất có thể được truyền trong một chu kỳ dịch vụ. Giả sử rằng các gói không bao giờ lớn hơn Plen (đơn vị truyền tối đa MTU của tuyến), DN cũng sẽ không bao giờ lớn hơn Plen. Trong một khoảng thời gia dài, sau khi bộ lập lịch quay vòng qua tất cả N hàng đợi K lần, số byte mong muốn truyền của hàng đợi N là K*QN. Giá trị này không bao giờ vượt quá số lượng byte thực sự truyền một lượng là Plen. Mỗi hàng đợi có thể có giá trị QN khác nhau...Nếu ít hơn N hàng đợi có gói để truyền, băng tần của tuyến được phân chia theo tham số QN của các hàng đợi có gói. 4.6 Sắp xếp đường liên kết phân cấp Trong các mạng thực tế yêu cầu về chia sẻ liên kết thường quá phức tạp cho một loại bộ lập lịch đơn. Các luồng lưu lượng có quan hệ phân cấp cùng nhau thường chia sẻ các kiên kết và điều kiện này yêu cầu các router có khả năng lập lịch phân cấp. Ví dụ, cho rằng một liên kết được chia sẻ bộ lưu lượng thuộc một số công ty, mỗi công ty có thể mua hẳn một đường cực tiểu của băng thông kết nối nhất định. Tình huống này có thể đạt được bằng cách ấn định lưu lượng tới hàng đợi trên cơ sở công ty và sử dụng bộ lập lịch đơn. Tuy nhiên, mỗi công ty cũng có thể có nhiều quy tắc riêng quản lý cách xử lý các luồng riêng trong tổng số của chúng trong suốt giai đoạn nghẽn. Cưỡng bức các mức lưu lượng phân loại thêm vào tại cùng một node vì sự chia sẻ liên kết mức dưới yêu cầu một hàng đợi phân cấp và giải pháp lập lịch. Hình 4.13 biểu diễn một trường hợp đơn giản, công ty A và công ty B đã được dành nhiều đường chia sẻ không đều (30% và 70%) của đường kết nối khoảng cách dài tốc độ 2Mbps và đường liên kết truy nhập nội bộ là 10Mbps. Khi cả hai công ty cùng gửi tại hoặc qua đường chia sẻ đảm bảo của họ thì router truy cập được yêu cầu để đảm bảo tỉ lệ phân chia 30:70. Tuy nhiên, hợp đồng chia sẻ cũng có thể thêm một yêu cầu nếu một công ty không sử dụng chia sẻ của nó thì sức chứa dư thừa là sẵn sàng cho công ty khác. Như vậy, khi công ty A sử dụng ít hơn 0.6 Mbps thì công ty B được phép tràn quá 70%. Và ngược lại. Hình 4.13:Lưu lượng có thể có sự phận cấp trong quan hệ nội bộ Thêm vào đó trong lưu lượng kết hợp của mỗi công ty tạo bởi nhiều luồng riêng thuộc các ứng dụng TCP và UDP khác nhau. Trong suốt thời gian nghẽn tại router truy cập, mỗi công ty muốn luồng UDP nhận được 20% và luồng TCP nhận được 80% tổng lưu lượng tương ứng. Thừa nhận rằng TCP có thể được phép sử dụng bất kì khả năng luồng lưu lượng UDP không dùng ,và thay thế linh hoạt. Ví dụ, nếu cả hai công ty đều sử dụng đường phân chia dành cho nó, thì lưu lượng UDP của công ty A sẽ là 0.12Mbps và lưu lương TCP của nó nhận 0.48Mpbs. Tuy nhiên nếu lưu lượng UDP của công ty A rơi xuống 0.05Mpbs thì lưu lượng TCP của công ty được B được mở rộng tới 0.55Mbps – không đưa cho công ty B một một phần nào. Một kết quả bổ sung của chia sẻ liên kết phân cấp là nếu công ty B tụt xuống của nó tới 0.5Mpbs thì công ty A có thể được phép mở rộng và dùng hết 1.5Mbps – TCP và UDP của nó chia 1.5Mbps theo tỉ lệ 20:80. Dịch vụ mong muốn trong hình 4.13 yêu cầu bộ lập lịch phân cấp hai tầng như được chỉ ra trong hình 4.14. Ví dụ này gồm 4 hàng đợi, hai nhóm và mỗi nhóm dành cho mỗi công ty và một hàng đợi trong mỗi nhóm cách ly các gói UDP và TCP (hình 4.14 không chỉ ra kỹ thuật phân loại, nó phải có thông tin đầy đủ các gói phân biệt của cả hai công ty và loại giao thức). Một cách hợp lí, người ta có thể xem sự chia sẻ liên kết như là bị cưỡng chế bởi các bộ lập lịch nối nhau. Mỗi nhóm có bộ lập lịch một cách thuận lợi với tỷ lệ phân chia yêu cầu 20:80 (UDP : TCP). Link Hàng đợi UDP Công ty B Hàng đợi TCP Hàng đợi UDP Hàng đợi TCP Công ty A Hình 4.14 Bộ lập lịch phân cấp được yêu cầu “Khối quản lý nguồn và chia sẻ liên kết cho mạng gói ” của Floyd và jacobson đã tập trung vào sử dụng hàng đợi phân loại cơ sở (CBQ) cho thực hiện chia sẻ phần nào liên kết. 4.7 Dịch vụ tích hợp Internet truyền thống đưa ra rất nhiều mức chất lượng rịch vụ (QoS) cho kết nối trực tuyến, nó có tên là dịch vụ hỗi trợ tối đa. Tất cả sự khác nhau trong số các khách hàng có ảnh hưởng xấu trong các loại kết nối : modem tương tự, mạng tích hợp dịch vụ ISDN, hay đường dây kết nối qua đường dây điện thoại (dial-up), đường dây thuê bao riêng (leased – line). Trong những năm gần đây những nhà cung cấp mạng internet đã phát triển nhiều loại hình dịch vụ với nhiều ứng dụng mới khác nhau như những dịch vụ đa phương tiện, những dịch vụ mạng riêng ảo…. Yêu cầu ứng dụng: Ứng dụng có thể thấy được thông qua thông qua tập trung vào các driver của Internet. Nói theo cách khác, mạng tồn tại nhằm đáp ứng các yêu cầu của các ứng dụng. Những ứng dụng có thể mô tả thông qua hai thuộc tính Tốc độ truyền dẫn dự báo trước Dung sai trễ Phụ thuộc vào những sự mô tả của tốc độ truyền dẫn, những ứng dụng có thể được phân loại theo bảng phân loại dưới đây Bảng 4.1 Mô tả những ứng dụng Luồng Có tốc độ truyền dẫn dự báo trước và các hằng số truyền dẫn có liên quan (hằng số tốc độ CBR). Sự ứng dụng trong phân loại có xác định giới hạn về tốc độ. Ví dụ luồng video thoại trên IP..... sự bùng nổ lưu lượng Ngược lại với trên là truyền dẫn thay đổi và không dự báo trước của khối dữ liệu . Nó thì không xác định về miền giới hạn về tốc độ. ví dụ như truyền file..... Phụ thuộc vào dung sai độ trễ, những ứng dụng có thể vào một trong những trường hợp của bảng phân loại sau: Bảng 4.2 Những yêu cầu cần thiết của ứng dụng trong những trường hợp quan trọng. Asynchronuos Đây là những ứng dụng mềm dẻo không cần đòi hỏi định thời ví dụ như :truyền dẫn mail, truyền dẫn file... Synchronuos Đây là những ứng dụng linh hoạt không yêu cầu định thời thời gian ví dụ Web browsing .. Interactive (sự tương tác) Những ứng dụng ở đây về chất lượng sử dụng và về khả năng không phụ thuộc vào sự phân phối thời gian nhưng thoả mãn người sử dụng ở một số phạm vi (ví dụ: telnet, Web browsing...) Ioschronuos or conversational Chất lượng sử dụng được bị ảnh hưởng bởi trễ ( ví dụ IP telephony) Mission-critical (nhiệm vụ then chốt) Chức năng bị thiệt hại nếu độ trễ yêu cầu không tính đến thời tiết . (ví dụ: toll qualiti IPT) Dịch vụ tích hợp (IntServ), đứng trước nhu cầu ngày càng tăng trong việc cung cấp các dịch vụ thời gian thực (thoại, Video), băng thông cao (đa phưng tiện) dịch vụ tích hợp IntServ đã ra đời. Đây là sự phát triển của mạng IP nhưng đồng thời cung cấp dịch vụ truyền thống nỗ lực tối đa và các dịch vụ thời gian thực (minh hoạ trên Hình 4.15). Động lực thúc đẩy mô hình này chủ yếu là một số lý do cơ bản sau đây: Dịch vụ nỗ lực tối đa không còn đủ tốt nữa: ngày càng có nhiều ứng dụng khác nhau có những yêu cầu khác nhau về đặc tính lưu lượng được triển khai, đồng thời người sử dụng ngày càng yêu cầu cao hơn về chất lượng dịch vụ. Các ứng dụng đa phưng tiện cho gói ngày càng xuất hiện nhiều: mạng IP phải có khả năng hỗ trợ không chỉ đơn dịch vụ mà phải hỗ trợ tích hợp đa dịch vụ của nhiều loại lưu lượng khác nhau từ thoại, số liệu đến Video. Tối ưu hoá hiệu suất sử dụng mạng và tài nguyên mạng: đảm bảo hiệu quả sử dụng và đầu tư. Tài nguyên mạng sẽ được dự trữ cho lưu lượng có độ ưu tiên cao hơn, phần còn lại sẽ dành cho số liệu nỗ lực tối đa. Cung cấp dịch vụ tốt nhất: mô hình dịch vụ IntServ cho phép nhà cung cấp mạng cung cấp được dịch vụ tốt nhất khác biệt với các nhà cung cấp cạnh tranh khác. øng dông Ph©n lo¹i LËp lÞch Setup Data Setup Ph©n lo¹i LËp lÞch Giao thøc ®Þnh tuyÕn/Database §iÒu khiÓn chÊp nhËn/ c­ìng bøc IP Data C¸c b¶n tin setup ®Æt tr­íc Hình 4.15 : Mô hình dịch vụ tích hợp Trong mô hình này có một số thành phần tham gia như sau: Giao thức thiết lập: Setup cho phép các máy chủ và các router dự trữ động tài nguyên trong mạng để xử lý các yêu cầu của các luồng lưu lượng riêng, RSVP, Q.2931 là một trong những giao thức đó. Đặc tính luồng: xác định chất lượng dịch vụ QoS sẽ cung cấp cho luồng riêng biệt. Luồng được định nghĩa như một luồng các gói từ nguồn đến đích có cùng yêu cầu về QoS. Về nguyên tắc có thể hiểu đặc tính luồng như băng tần tối thiểu mà mạng bắt buộc phải cung cấp để đảm bảo QoS cho luồng yêu cầu. Điều khiển lưu lượng: trong các thiết bị mạng (máy chủ, router, chuyển mạch…) có thành phần điều khiển và quản lý tài nguyên mạng cần thiết để hỗ trợ QoS theo yêu cầu. Các thành phần điều khiển lưu lượng này có thể được khai báo bởi giao thức báo hiệu như RSVP hay nhân công. Thành phần điều khiển lưu lượng bao gồm: Điều khiển chấp nhận: xác định thiết bị mạng có khả năng hỗ trợ QoS theo yêu cầu hay không; Thiết bị phân loại (Classifier): nhận dạng và lựa chọn lớp dịch vụ dựa trên nội dung của một số trường nhất định trong mào đầu gói; Thiết bị lập lịch (Scheduler): cung cấp các mức chất lượng dịch vụ QoS trên kênh ra của thiết bị mạng. Đoạn dưới đây là một số nét chính về kiến trúc chi tiết của dịch vụ tích hợp . 4.7.1 Một số mô hình của dịch vụ tích hợp Trong những nét chính về dịch vụ tích hợp IETF đã định nghĩa hai dịch vụ mạng thêm vào dịch vụ hỗi trợ tối đa truyền thống , tên của hai dịch vụ đó là: The guaranteed Quality of Service (đảm bảo chất lượng của dịch vụ hay còn gọi là các dịch vụ đảm bảo). Các ứng dụng cung cấp thuộc loại này có thể kể đến: hội nghị truyền hình chất lượng cao, thanh toán tài chính thời gian thực,... the controlled Load Quality of service (chất lượng dịch vụ tải điều khiển còn gọi là các dịch vụ kiểm soát tải) Dịch vụ đảm bảo (GS) Định nghĩa nét chính của dịch vụ tích hợp trong tiêu chuẩn RFC 2212 như sau: Dịch vụ đảm bảo cung cấp giới hạn nhất định dựa trên trễ hàng đợi dữ liệu từ đầu cuối tới đầu cuối. Những dịch vụ này có khả năng cung cấp đảm bảo cả hai thông số trễ và băng thông… Dịch vụ đảm bảo này đảm bảo sự định tuyến dữ liệu đảm bảo sẽ đến trong thời gian được phân phát và không bị mất gói do bởi luồng bị tràn hàng đợi, nó được cung cấp luồng lưu lượng với thông số riêng. Dịch vụ này được mong đợi cho những dịch vụ cần sự đảm bảo nhất định về dữ liệu sẽ đến trong thời gian qui định nghiêm ngặt cần thiết. Ứng dụng này cung cấp đặc điểm mong đợi hồ sơ lưu lượng , tính toán mạng, trễ từ đầu cuối tới đầu cuối của nó được đảm bảo. Nếu trễ này trong giới hạn mong đợi của ứng dụng, ứng dụng sẽ được chắc chắn rằng gói sẽ được phân chia trên đường dẫn trong sự tính toán giới hạn trễ. GS yêu cầu đặc điểm của bản thân ứng dụng tồn tại tròn giới hạn kích cỡ tốc độ và sự bùng nổ lưu lượng (các thông số của token bucket ). Trễ đầu cuối tới đầu cuối được tạo bởi sự kết hợp bởi trễ đường dẫn với trễ hàng đợi thông qua tất cả các NE. Trễ hàng đợi của NE phụ thuộc vào các thông số của gáo token được cung cấp bởi các úng dụng. Mạng tính toán ngay cả trong trường hợp xấu nhất của trễ, nó được đảm bảo dựa trên những thuật toán hàng đợi. GS không cố gắng vượt giới hạn hay xác định số lượng trễ nhỏ nhất, trễ trung bình hay biến động trễ- chỉ trong trường hợp trễ xấu nhất được đảm bảo. GS chủ yếu phù hợp với những ứng dụng yêu cầu thời gian thực. Sự giới hạn trễ trong trường hợp xấu nhất thì nó giới hạn biến động trễ trong trường hợp xấu nhất (vì lý do kích thước bên ngoài bộ đệm). Tải điều khiển Sự định nghĩa những nét chính của về tải điều khiển được nói rõ trong tiêu chuẩn RFC 2211 dưới đây: Cách thức end – to –end đã cung cấp cho ứng dụng bởi một chuỗi các phần tử mạng, sự cung cấp dịch vụ tải điều khiển chặt chẽ thấy được qua những ứng dụng dịch vụ hỗi trợ tối đa “dưới điều kiện không tải” từ chuỗi những phần tử mạng. Ngữ cảnh những điều kiện không tải nghĩa là “không nghẽn hay tải không nặng nề”. Như vậy CL cung cấp chỉ dịch vụ rất tốt, nhỏ bé, của đường dẫn hỗi trợ tối đa không nghẽn có liên quan. RFC 2211 tuôn theo như sau: Tỷ lệ cao gói truyền dẫn sẽ được phân phát thành công bởi mạng cho những node tiếp nhận (tỷ lệ gói phân chia không thành công trong khoảng đóng gần đúng với tốc độ lỗi gói cơ sở của truyền dẫn trung bình). Quá trình trễ truyền dẫn bởi tỷ lệ rất cao của sự phân phối gói sẽ không mong đợi quá trình trễ truyền dẫn nhỏ nhất bởi bất kỳ gói được phân phối thành công nào (trễ truyền dẫn nhỏ nhất bao gồm trễ do speed- of –light, quá trình xử lý trong các router, kết nối các thiết bị dọc theo đường truyền). Luồng yêu cầu dịch vụ tải điều khiển mong đợi dịch vụ hỗi trợ tối đa thông qua mạng không tải. Dịch vụ tải điều khiển có thể được cân nhắc dịch vụ hỗi trợ tối đa riêng và có hiệu lực tối đa cho sự cho phép những luồng ứng dụng khác chia sẻ mạng trong khi cưỡng ép sự ảnh hưởng lẫn nhau giữa chúng. So sánh giữa hai dịch vụ Sự giống nhau giữa hai dịch vụ: Cả hai dịch vụ này đều được cung cấp điều khiển trễ và mất gói, dành trước tài nguyên giả định và được gọi là những kỹ thuật điều khiển xác nhận sử dụng mô tả lưu lượng gáo token . Sự khác nhau cơ bản giữa hai dịch vụ mang này là: Dịch vụ chất lượng đảm bảo cung cấp chính xác giới hạn trên trễ lớn nhất và không mất gói cho việc kết nối. Chú ý rằng nó cũng không xác định trễ tối thiểu hay giá trị độ lớn biến động trễ tối thiểu. Về ý nghĩa lý thuyết giới hạn trên của trễ lớn nhất nó được đảm bảo thông qua việc cấp phát băng thông. Sự đảm bảo chất lượng của nhân tố mạng yêu cầu chính xác gọi là điều khiển xác nhận nó được thực hiện dựa trên sự sử dụng cung cấp gáo token hay còn gọi là gáo rò. Một cách khác đưa ra cho dịch vụ dảm bảo chất lượng trên tất cả nhân tố mạng ngay lập tức theo các đường liên kết phải hỗi trợ dịch vụ này. Ngoài ra bộ phận hỗi trợ dịch vụ có thể hoạt động tốt hơn. Ví dụ khi sảy ra tắc nghẽn trên đường dây thì trong quá trình sảy ra tắc nghẽn nó sẽ được hỗi trợ trong khi việc cung cấp thêm đường liên kết chưa được thực hiện. Nhân tố mạng tải điều khiển đưa ra tương đương một dịch vụ ảo của mạng không tải đưa ra. Chú ý rằng sự định nghĩa không chứa một sự chính xác đặc biệt nào về chất lượng dịch vụ; do đó những sự riêng biệt thì chỉ rất đơn giản . Những yêu cầu ứng dụng của tải điều khiển đưa ra có thể mong đợi: Do ảo nên không bị mất Trễ trên mạng là nhỏ nhất, biến động trễ là rất thấp ... Tương tự cho việc đảm bảo chất lượng dịch vụ chính xác gọi là xác nhận cần thiết. cơ sở cho điều khiển xác nhận là mô tả lưu lượng gáo dò. 4.7.2 Một số vấn đề liên quan trong Inserv Kiểm soát lưu lượng Theo điều khiển xác nhận, nếu sự kết nối đăng nhập vào trong hệ thống mà lưu lượng của nó là nằm trong bản đàm phán về các đặc điểm và gía trị lưu lượng, thì mạng phải cung cấp QoS đàm phán cho liên kết đó. Các router biên giới mạng thực hiện giám sát khuân dạng lưu lượng người sử dụng như xác thực của người sử dụng cho sự dành trước tài nguyên. Những chức năng này gọi là kiểm soát lưu lượng . Hầu hết đối tượng thông thường của kiểm soát lưu lượng là giới hạn tốc độ lớn nhất của sự truyền tải hay tiếp nhận lưu lượng trên giao diện ... cho việc thiết lập quản lý băng thông thông qua giới hạn lớn nhất về tốc độ. Sự kiểm soát này hầu hết được thực hiện bắt buộc tại biên của mạng. Lưu lượng truyền dẫn với tham số tốc độ vượt quá ngưỡng thì nó sẽ bị cắt hay truyền với một độ ưu tiên khác. Hầu hết bộ điều chỉnh lưu lượng thông thường là “token bucket” hay gáo rò (Hình 4.16) “token bucket ”được mô tả bởi ba tham số :tốc độ thẻ , độ dài gáo thẻ , tốc độ luồng. Luồng được đồng ý với p>>r , khi giả thuyết là vô hạn. hiện nay nó cũng có thể sử dụng “token bucket ” cho điều chỉnh lưu lượng phụ thuộc vào các tham số, hoặc bị loại, đánh dấu hay thay đổi độ ưu tiên về lưu lượng dựa trên cơ sở bản hợp đồng . Token bucket được mô tả ở Hình 4.17 dưới đây. Token bucket (dữ liệu đầu vào) Leaky bucket độ sâu của gói nước chảy vào luồng nước chảy ra (tốc độ qua gáo) P b tokens r = token rate p= peak rate >= r b= token bucket length (max ) r Hình 4.16: leaky and token bucket traffic b t Hình 4.17: Đồ thị lưu lượng trong token bucket Điều khiển lưu lượng Trong yếu tố mạng vấn đề cải thiện chất lượng dịch vụ là một vấn đề luôn luôn được đặt ra, điều khiển lưu lượng hợp lý cũng cải thiện đáng kể QoS. Về cơ bản bất cứ kỹ thuật định tuyến nào cũng đảm bảo hai vấn đề : Thiết lập tối ưu trên cơ sở thước đo nhất định Xem xét băng tần khả dụng trên trường kênh riêng. Trong kỹ thuật lưu lượng thì mục tiêu của nó được chia ra làm hai mục tiêu chính: Các mục tiêu định hướng lưu lượng: nâng cao chất lượng QoS bằng giảm thiểu thất thoát gói, trễ; tăng tối đa băng thông cung cấp cho nó; và bắt buộc thực thi SLA. Các mục tiêu định hướng nguồn tài nguyên: Tối ưu hóa sử dụng nguồn tài nguyên. Trong đó băng thông được coi là một thông số quan trong nhất của tài nguyên mạng. Như vậy mục đích chính của định hướng nguồn tài nguyên là giảm thiểu tối đa tắc nghẽn. Như vậy điều khiển lưu lượng thực chất là một giải pháp thông qua QoS được cung cấp, trong các phần tử mạng. Các thành phần của điều khiển lưu lượng gồm có: Lập lịch gói Phân loại gói Đánh dấu gói Hình 4.18: Node dịch vụ tích hợp Những chức năng điều khiển xác nhận mô tả tổng quan bởi Hình 4.18 Lập lịch Hoạt động của lập lịch gói là một quy tắc quan trọng trong tất cả chất lượng dịch vụ mạng , từ đây nó cung cấp phương thức định quyền ưu tiên trong các các gói khác nhau đang chờ để được phân loại quyền ưu tiên . Mô hình lý tưởng làm cơ sở của những dịch vụ mạng tích hợp là lập lịch hàng đợi với trọng số phù hợp (WFQ) , nó là công cụ dẫn xuất gói của lập lịch chia sẻ xử lý tổng quát (GPS). Những bộ lập lịch GPS tin cậy mức cao của của phân tách lưu lượng, phân phối và phân chia lại nguồn tài nguyên tốc độ cơ sở khi có khả năng hệ thống bị vượt quá. Những tham số khi mô tả lưu lượng bằng “token bucket” (ri , bi) i= 1...N và khả năng dịch vụ của C, mỗi luồng lưu lượng được đảm bảo giới hạn trễ trong trường hợp xấu nhất và mất sẽ bằng không nếu bộ đệm được phân của chúng và hệ thống ổn định giá trị xem hình [3.7.4]. Trong viễn cảnh chung một trọng số được đăng kí cho mỗi một hàng đợi tách biệt , nó quyết định tới sự chia sẻ tài nguyên băng thông của kết nối. Nó rất quan trọng cho việc hiểu, dịch vụ tích hợp trong những yêu cầu chung về tỉ lệ mức luồng làm bộ đệm trong node (xem Hình 4.19). Từ đó định lượng cho trường hợp xấu nhất về quyền sở hữu khi cân nhắc trong mạng đường trục. Giao thức dành trước tài nguyên Giao thức dành trước tài nguyên (RSVP) nó là một giao thức báo hiệu cuối-tới-cuối cho việc quản lý tài nguyên. Nó có thể thao tác riêng lẻ hoặc lọc định dạng luồng thiết lập một con đường dành trước tài nguyên gốc từ ngoài tiếp nhận; có hỗi trợ điểm đa điểm “multicash” và yêu cầu dành trước tài nguyên hợp lại hiệu quả cho cây phân loại điểm đa điểm . 1 2 3 N C Hình 4.19: Bộ lập lịch trọng số phù hợp Mặc dù RSVP xây dựng một cách dành trước tài nguyên, cả hai nhóm có thể được bắt đầu song song, và độc lập với nhau. RSVP lằm ở (transport layer) lớp giao vận, khi miêu tả tuy nhiên nó không diễn tả dữ liệu ứng dụng nhưng lại quản lý tài nguyên của ứng dụng. Thỉnh thoảng RSVP được giả định cho những đường liên kết điều khiển rất tốt, mặc dù RSVP độc lập những giao thức định tuyến người sử dụng, do đó nó dễ nhận thấy định tuyến biến đổi thông qua những đường dẫn. RSVP duy trì dành trước tài nguyên, nó phụ thuộc vào mô hình trạng thái mềm, … nó ưu tiên những trạng thái dành trước tài nguyên đã cập nhật . Nó liên hệ với phương pháp tiếp cận với không liên kết của IP. Nếu cho bất kì nguyên nhân nào cập nhật dành trước được huỷ bỏ, sự dành trước tài nguyên được tự động tách ra trong những nhân tố mạng. Theo lẽ tự nhiên, ở đây nó cũng là bản tin tín hiệu rõ ràng cho tách ra dành trước tài nguyên cốt để không chờ đến ngoài thời gian . RSVP và khả năng mở rộng RSVP khởi đầu được thiết kế để hỗ trợ dự trữ tài nguyên cho các luồng ứng dụng riêng và đây là nhiệm vụ và về những thách thức khả năng mở rộng của nó. Nói chung thuật ngữ này được sử dụng để chỉ giới hạn sử dụng tài nguyên, và sử dụng tài nguyên như thế nào khi mạng tăng lên. Dự trữ tài nguyên cho các luồng ứng dụng riêng rõ ràng ảnh hưởng xấu đến khả năng mở rộng. Chúng ta có thể cho rằng mỗi người sử dụng sẽ dự trữ tài nguyên tại một vài tốc độ trung bình, vì thế số tài nguyên dự trữ được tạo ra qua mạng lớn có khả năng tăng nhanh bằng số người sử dụng mạng. Điều này sẽ dẫn đến chi phí lớn nếu mỗi bộ định tuyến phải lưu trữ trạng thái tài nguyên dự trữ cho luồng ứng dụng riêng. Chính xác hơn nếu nói rằng mức dự trữ tài nguyên cho các luông ứng dụng là kém hơn so với RSVP. Sự khác nhau này đặc biệt quan trọng khi chúng ta xem xét rằng RSVP không những đòi hỏi cho việc dự trữ tài nguyên cho các luồng ứng dụng riêng mà còn dự trữ tài nguyên cho lưu lượng tổng hợp. 4.8 Dịch vụ khác biệt 4.8.1 Khái niệm về dịch vụ DiffServ Việc đưa ra mô hình IntServ đã có vẻ như giải quyết được nhiều vấn đề liên quan đến QoS trong mạng IP. Tuy nhiên 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 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. Hiện tại IETF đã có một nhóm làm việc DiffServ để đưa ra các tiêu chuẩn RFC về DiffServ. 4.8.2 Một số nguyên tắc cơ bản của DiffServ như sau Đị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 biệt 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 bít đã được đánh dấu trong mào đầu của gói. Với nguyên tắc này, DiffServ có nhiều lợi thế hơn so với 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ụ. Điều 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. Đây là công việc của thiết bị biên. Hỗ trợ rất tốt dịch vụ VPN. Tuy nhiên có thể nhận thấy DiffServ cần vượt qua một số vấn đề như: Không có khả năng cung cấp băng tần và độ trễ đảm bảo như GS của IntServ hay ATM; 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; 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 đề không nhỏ cần quan tâm; 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. 4.8.3 Mô hình DiffServ Mô hình DiffServ 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 bít 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 (router 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. Kiến trúc của Diffserv: Kiến trúc của dịch vụ khác biệt làm cơ sở cho mô hình đơn giản, lưu lượng nhập vào mạng đã được phân loại và điều kiện có thể thì từ biên giới của mạng, và được đăng nhập cho khối kết hợp cách thức khác biệt (diffirent behavior aggregates Bas) với mỗi Bas được nhận biết bằng mã trọng điểm của mỗi dịch vụ khác biệt single Difserv Code-Point (DSCP) (Hình 4.20). Trong lõi của mạng, những gói được tìm phụ thuộc vào cách thức từng trạng, per- hop behavior ( PBH), liên hệ với DSCP. Hình 4.20: Dịch vụ khác biệt tập trung đơn giản sự phức tạp định tuyến lõi Khối tự trị nhỏ nhất của dịch vụ khác biệt được gọi là miền dịch vụ khác biệt, những dịch vụ được xác định chắc chắn bởi các nguyên lý nhận biết. Miền bao gồm hai loại node : những bộ định tuyến biên những bộ định tuyến lõi Những node lõi chỉ chuyển tiếp gói, nó không tham gia vào phần tín hiệu, kiến trúc này hoàn thành khả năng định lượng bởi sự thực hiện những chức năng phân loại và điều kiện phức tạp, chỉ ở biên giới của mạng, và những bộ định tuyến lõi không lưu trữ thông tin về những luồng riêng biệt. Trường dịch vụ khác biệt trong tất cả phần tiêu đề gói chứa thông tin cần thiết cho sự nhận biết hàng đợi ưu tiên, kỹ thuật lập lịch và loại bỏ, nó được gọi là cách thức xử lý từng trạng (PBH). Mặc PBHs xác định thông số QoS, những khách hàng chỉ đựơc quan tâm trong những dịch vụ đưa ra. Do đó khách hàng và nhà cung cấp dịch vụ phải thoả thuận với nhau về từng khía cạnh của dịch vụ cụ thể. Bản hợp đồng này được gọi là sự thoả thuận mức dịch vụ (SLAs : service level agreements). Bên cạnh SLAs là một công nghệ rành riêng nó được gọi là mức dịch vụ đặc biệt ( SLS :service level speciffication ), chứa những khía cạnh khác như chi phí cho một số kỹ thuật, khoảng thời gian …Từ những điểm chính của công nghệ có lẽ phần quan trọng nhất của SLS là điều kiện riêng để lưu lượng qua (TCS : Traffic Condition Speciffication) nó tổng hợp chi tiết thông số mức dịch vụ như giá trị luồng vào mong đợi, tỉ lệ mất hay trễ; hồ sơ lưu lượng cho những yêu dịch vụ có thể được cung cấp và những thao tác bên ngoài hồ sơ lưu lượng “out of profile” . Một cách khác cung cấp dịch vụ cuối tới cuối, những miền dịch vụ khác biệt riêng biệt cần cho sự hợp tác, miền đầu tiên phải nói đến là thoả thuận với khách hàng trong khi tất cả các miền kế tiếp thực hiện thoả thuận với những khách hàng khác. Như thiết lập miền dịch vụ gọi là khác biệt. Một ví dụ về dịch vụ khác biệt Hình 4.21 Hình 4.21: Kiến trúc dịch vụ khác biệt Theo như ở trên bắt đầu của một dịch vụ, cũng giống như trạm những tổng đài cuối hay những bộ định tuyến biên giới nối vào cổng nó đánh dấu những gói của luồng trong những trường dịch vụ khác biệt phụ thuộc vào sự đồng ý của nó. Nhóm làm việc về dịch vụ khác biệt IETF đã định nghĩa trường DS cho cả hai loại gói IPv4 hình 1.12 và IPv6 1.14. Trong IPv4 ToS (type of service ) được sử dụng cho mục đích này. Trong IPv6 byte Traffic Class được định nghĩa bao gồm trường DS. Sáu bít của trường được sử dụng cho điểm mã dịch vụ khác biệt (DSCP :Diffserv code-point) trong khi hai bít còn lại để trống dành quyền sử dụng cho mục đích này, với IPv6, byte loại lưu lượng được định nghĩa bao gồm trường DS. Sáu bít của trường được sử dụng cho DSCP trong khi hai bít còn lại chưa được sử dụng. DSCP cũng duy trì khả năng backwark với trường của IPv4 truyền thống . 4.8.4 Một số vấn đề liên quan Điều kiện và phân loại lưu lượng Một bản SLS đã có sự thoả thuận, dịch vụ cung cấp phải cấu hình những điều kiện lưu lượng. Ở giữa các Router biên giới giữa bất kì hai mạng bao gồm “host ” cuối riêng rẽ cũng vậy. Điều khiển lưu lượng là cần thiết cho sự phân chia độ ưu tiên mạng và cho việc bảo vệ những dịch vụ của quá tải hoặc lưu lượng không thực hiện. Lập chính sách phân loại lưu lượng định nghĩa tập con của lưu lượng, nó có thể tiếp nhận dịch vụ khác bằng các điều kiện và sơ đồ cho một hay nhiều hơn một cách thức khối kết hợp trong miền dịch vụ khác biệt. Bộ phân loại gói lựa chọn những gói trong luồng lưu lượng trên cơ sở nội dung của một số phần của tiêu đề gói. Hai loại của bộ phân loại đã được định nghĩa. Bộ phân loại BA phân loại gói dựa trên cơ sở chỉ duy nhất những điểm cốt yếu của một trường tiêu đề của dịch vụ khác biệt . Bộ phân loại đa trường MF(multi - field) thì ngược lại nó phân loại dựa trên một hay nhiều hơn một trường tiêu đề, như địa chỉ nguồn, địa chỉ đích, trường DS, giao thức ID, số lượng cổng nguồn…và các thông tin khác như giao diện đến. Hình 4.22 : Điều khiển lưu lượng ở một node dịch vụ khác biệt Những bộ phân loại phân loại gói được sử dụng cho điều khiển lộ trình gói phù hợp một số quy tắc cho sự xử lý sau này. Điều khiển lưu lượng thực hiện sự ghi lại , tạo khuôn dạng, kiểm soát và đánh dấu lại cho sự chắc chắn rằng lưu lượng đăng nhập miền DS thực hiện cho một số điều chỉnh đặc biệt về lưu lượng trong TCS xem Hình 4.22. Trên cơ sở điều kiện lưu lượng được phân loại cũng như bên trong “in- profile” hay ngoài “out – profile”. Những gói bên ngoài của profile có thể đựợc xếp hàng cho đến khi vào trong hồ sơ in-profile (định hướng ), loại bỏ (kiểm soát ), đánh dấu lại với code-point (re-maked), hoặc chuyển đổi. Xa hơn thế, các gói out- of - profile có thể được lộ trình hoá một hay nhiều hơn một tổ hợp tổ hợp cách thức. Quản lý bộ đệm và lập lịch của dịch vụ khác biệt Không giống như dịch vụ khác biệt về cách tiếp cận khung dịch tích hợp vì cách tiếp cận của dịch vụ khác biệt không xác định rõ cấu trúc lập lịch nhưng chỉ yêu cầu tương đối sự phân loại lưu lượng khác nhau. Sự thực thi được hình thành đã loại bỏ sự sản xuốt phần cứng. Đến nay vẫn có kiến trúc hàng đợi có tên là hàng đợi cơ sở phân loại (CBQ: Class Base Queueing), nó dường như là ứng cử viên sáng giá cho lập lịch khác biệt phổ biến. CBG có thể được cân nhắc theo thứ bậc, ưu tiên trọng số trên bộ lập lịch WFQ (xem Hình 4.19). Sự vận hành dựa trên sự tập hợp phân loại lưu lượng. Với CBQ, phân cấp phân loại lưu lượng đa mức một là có thể được cấu trúc ưu tiên hay cấu trúc trọng số, cơ sở ưu thế của phân loại này được thiết lập. Mỗi loại của nhóm phân loại có thể tối đa về băng thông truy nhập hay cho phép mượn từ nhóm khác. Hình 4.23 trình diễn ví dụ cho những lưu lượng Video, audio và hỗi trợ tối đa giống như FTP hay telnet. Hàng đợi cơ sở phân loại (CBQ) Class A ftp telnet vidio audio 50% 30% 20% 10% 20% 10% 10% Class B vidio audio 5% 15% Class C vidioo 30% Hình 4.23 Hàng đợi cơ sở phân loại Một chú ý rằng ,những loại lưu lượng giống như …audio, có thể xuốt hiện ở phân loại lập lịch khác biệt với điều kiện chất lượng phải khác nhau. Phân chia các dịch vụ khác biệt Trong miền dịch vụ đưa ra có thể được nhóm lại cho việc định lượng hay đặc tính chất lượng. Sự phân tích định lượng dịch vụ đưa ra đảm bảo là khó khăn nó có thể xác nhận bởi thước đo phù hợp không tương thích bất kì những dịch vụ tồn tại song song khác. Định tính chất lượng dịch vụ trên phương thức khác thì không cung cấp sự đảm bảo chính xác nhưng hơn thế tương quan với quyền ưu tiên phụ thuộc vào những dịch vụ rất nhiều . Ở đây, sự xác nhận các dịch vụ chỉ có thể được thực hiện tương đối giữa nhiều thành phần dịch vụ. Một cách khác của dịch vụ khác biệt được thể hiện qua phương thức lựa chọn dựa trên QoS được cung cấp. Những tiêu chuẩn của dịch vụ Có những tiêu chuẩn về dịch vụ được IETF đưa ra . (i) Mặc định (best-effort) PHB (ii) Nhóm bộ lựa chọn phân loại cho IP tương thích với quyền ưu tiên. (iii) Nhóm PHB chuyển đổi giả định (iv) tiến hành chuyển đổi PHB Sự mặc định PBH (i) phải có hiệu lực trong tất cả các node thụôc dịch vụ khác biệt. Cho ví dụ như code-point ‘000000’ cho toàn bộ cách thức mặc định. Ngoài ra, không một gói nào DSCPs không biết có thể được vạch ra cho PHB mặc định. Nhóm bộ phân loại PHB (ii) thiết lập khả năng backwark cho những khái định nghĩa trường ToS. Cách viết khác, phụ thuộc vào code – point với giá trị ‘xxx000’ có thể được lược đồ hoá cho những PHB nó tương hợp tốt nhất với mã quyền ưu tiên IP cá biệt. Tám mã code- points thiết lập mô hình khác biệt dịch vụ tương ứng. (iii) nhóm PHB chuyển đổi giả định có hai tham số (x) được dùng để xác định thứ tự quyền ưu tiên. (y) được sử dụng để định nghĩa cho sự xác định cấp bậc mức độ quan trọng để loại bỏ gói. Ví dụ: cho AF11 và AF12 vào hàng xếp cho bộ đệm giống nhau tuy nhiên AF12 có khả năng bị loại bỏ khỏi bộ đệm cao hơn trong trường hợp xảy ra tắc nghẽn. Chú ý rằng có thể thấy rõ rằng ta có thể sử dụng bộ đệm khác nhau cho AF11 và AF12, tuy nhiên phải tránh sự sắp xếp lại gói. Giá trị 12AF code- points được phân chia vào trong 4 phân loại AF và 3 thứ tự mức ưu tiên loại bỏ trong mỗi phân loại AF. (iv) cung cấp dịch vụ định lượng với sự đảm bảo hà khắc, đó là mất gói thấp, sự tiềm tàng phải nhỏ, biến động trễ thấp và cấp cho tốc độ đỉnh tuỳ theo bản thoả thuận quyết định tốc độ bit. Dịch vụ này xuốt hiện như đường dây thuê riêng ảo ‘virtual leased line’ cho khách hàng. Nếu quyền ưu tiên không giới hạn của lưu lượng EF được cho phép trong hệ thống sau khi sử dụng tài nguyên của tầng phân loại EF phải có giới hạn cốt để tránh sự thiếu thốn của lưu lượng ưu tiên bị giảm xuống. Thu hồi băng thông Những phần tử thu hồi băng thông (BB: Bandwidth Brokering) thực hiện quản lý mềm dẻo nguồn tài nguyên trong mạng dịch vụ khác biệt (ví dụ: Call admission control, cấu hình của router, tín hiệu phân chia tài nguyên, sự nhận thực). BBs không chỉ chịu trách nhiệm cho quản lý tài nguyên, chúng cũng điều khiển sự liên lạc miền liên kết cốt để đảm bảo chất lượng dịch vụ cho lưu lượng đa miền. Từ vẻ bề ngoài này, BBs có thể được quan tâm các tác nhân nguồn tài nguyên, chúng tiếp nhận yêu cầu người sử dụng và quyết định có hay không chia sẻ giá trị nguồn tài nguyên giữa những người sử dụng cho những yêu cầu của chúng. Nếu câu trả lời là có, chúng để dành những yêu cầu tổng số của nguồn tài nguyên cho những yêu cầu sử dụng bởi cấu hình những node mạng phụ thuộc vào những dịch vụ đã được xác định rõ. BBs được đăng ký cho những miền. Kết luận chương Chương IV trình bày cụ thể từng kỹ thuật trong mạng IP có tham gia vào quá trình xử lý luồng, các giải pháp, cơ chế hay nguyên lý hoạt động trong các kỹ thuật. Trong quá trình xử lý một số vấn đề phát sinh như nghẽn mạng … đòi hỏi phải có những phương thức xử lý thích hợp, Ở chuơng này đưa ra những giải pháp đó. Từ đó thấy được mối quan hệ tương quan cụ thể tới QoS trong mạng. Cách thức xử lý, quản lý để nâng cao chất lượng dịch vụ mạng. KẾT LUẬN Sau một thời gian tìm hiểu bản đồ án”nghiên cứu chất lượng dịch vụ trong mạng IP” đã hoàn thành với những nội dụng chính sau đây: Tìm hiểu tổng quan về mô hình TCP/IP Tìm hiểu chung về QoS. Nghiên cứu tổng quan về chất lượng dịch vụ trong mạngIP. Nghiên cứu một số kỹ thuật hỗi trợ chất lượng dịch vụ trong mạng IP. Bản đồ án tìm hiểu QoS theo một trình tự: từ cái nhìn chung về QoS đến một quan điểm cụ thể QoS trong mạng IP, trong đó nhấn mạnh về khía cạnh quản lý mạng. Do kiến thức còn nhiều hạn chế và thời gian có hạn, lĩnh vực còn mới nên đồ án mới chỉ tìm hiểu dưới dạng tổng quan, không đi sâu vào những nội dung cụ thể. Bài toán nâng cao chất lượng dịch vụ mới chỉ xét trên quan điểm của nhà quản lý mạng, còn một số quan điểm của người sử dụng cụ thể, quan điểm nâng cao chất lượng bằng phương pháp quản lý nhân lực…không được trình bày ở đây. Mô hình mạng từ biên tới biên mới chỉ đưa ra hai mô hình intserv và diffserv còn những mô hình khác chưa được nêu ra ở đây. Từ những kết quả đạt được trong bản đồ án này có thể tiếp tục đi sâu nghiên cứu chi tiết hơn về các giải pháp, những giao thức, và một số mô hình dịch vụ mạng khác hỗi trợ QoS trong mạngIP. Mặc dù đã hết sức cố gắng nhưng đồ án không tránh khỏi có những thiếu sót. Em xin được tiếp tục tiếp thu mọi ý kiến góp ý, sửa chữa của các thầy cô và các bạn để có thể hoàn thiện đề tài này sâu hơn. Để có được kết quả như ngày hôm nay là nhờ công lao dạy dỗ của các thầy cô giáo, đặc biệt là TS. Nguyễn Tiến Ban đã hướng dẫn, giúp đỡ em trong công việc cùng với sự giúp đỡ của gia đình cùng và các bạn. Em xin gửi lời cảm ơn chân thành tới thày cô giáo và gia đình, bạn bè đã sát cánh với em, giúp đỡ em. Xin chân thành cảm ơn ! SV: Phó Tiến Dũng