Luận văn Nghiên cứu chất lượng dịch vụ dữ liệu thời gian thực trong mạng IP

vụ còn định nghĩa thêm một số lớp dịch vụ. Một ứng dụng sẽ xác định đặc tính của luồng lưu lượng mà nó đưa vào mạng đồng thời xác định một số yêu cầu về dịch vụ mạng. Đặc tính của lưu lượng Tspec (Traffic Specification) yêu cầu mức chất lượng dịch vụ Rspec (Reguired Specification). Vì thế các bộ định tuyến phải có khả năng thực hiện các công việc sau: Kiểm soát (Policing): Kiểm tra TSpec của luồng lưu lượng; nếu không phù hợp thì loại bỏ luồng. Điều khiển chấp nhận: Kiểm tra xem tài nguyên mạng có đáp ứng được yêu cầu của ứng dụng hay không. Nếu không thể đáp ứng, mạng sẽ từ chối. Phân lớp (Classification): Phân loại gói dữ liệu căn cứ vào mức yêu cầu chất lượng dịch vụ của gói. Hàng đợi và lập lịch (Queuing and scheduling): đưa gói dữ liệu vào hàng đợi tương ứng và quyết định huỷ gói dữ liệu nào khi xảy ra xung đột. 2.3.1. Các lớp dịch vụ: Có hai lớp dịch vụ: đảm bảo dịch vụ (Guaranteed Service) và kiểm soát tải (Control load service). 2.3.1.1. Đảm bảo dịch vụ: Cho phép giới hạn thời gian chuyển tiếp các gói dữ liệu đến đích trong một khoảng thời gian nhất định, đảm bảo dữ liệu không bị loại bỏ khi hàng đợi đầy. Thông tin Tspec phải bao gồm các thông số như: tốc độ đỉnh, kích thước lớn nhất của gói dữ liệu. Trong khi đó thông số quan trọng nhất của Rspec là tốc độ dịch vụ. Thông số này cho phép xác định băng thông mà lưu lượng cần khi đi trong mạng. Thông số này cùng với các thông số trong Rspec cho phép xác định thời gian trễ lớn nhất có thể chấp nhận được của dữ liệu. Nhược điểm của lớp dịch vụ này là hiệu quả sử dụng tài nguyên mạng thấp vì nó đòi hỏi mỗi luồng lưu lượng có hàng đợi riêng. 2.3.1.2. Kiểm soát tải: Các ứng dụng của dịch vụ này có thể chấp nhận khả năng mất dữ liệu và thay đổi độ trễ ở một mức độ nhất định. Luồng dữ liệu khi đi vào mạng sẽ được kiểm tra đối chiếu với những đặc tả lưu lượng Tspec đã được đăng ký. Nếu không phù hợp với các đặc tả đã được đăng ký trước thì dữ liệu sẽ được chuyển tiếp theo phương thức “nỗ lực tối đa”. 2.3.2. Giao thức dành trước tài nguyên RSVP: RSVP là giao thức báo hiệu cung cấp thủ tục để thiết lập và điều khiển quá trình chiếm giữ tài nguyên, hay nói cách khác RSVP cho phép các chương trình ứng dụng thông báo cho mạng những yêu cầu về mức chất lượng dịch vụ; và mạng sẽ hồi đáp chấp nhận hoặc không chấp nhận yêu cầu đó. Các bản tin RSVP được các bộ định tuyến hay các bộ chuyển mạch trên liên kết giữa hai đầu cuối gửi và nhận trao đổi với nhau để đáp ứng yêu cầu về mức chất lượng dịch vụ của ứng dụng. RSVP có 2 bản tin cơ bản: bản tin Path và bản tin Resv. Bản tin Path mang thông tin về đặc tả luồng lưu lượng Tspec và các thông tin như: địa chỉ IP của nút gửi, địa chỉ IP nút nhận, chỉ số cổng UDP. Và khi nhận được bản tin Path, nút mnạg đích sẽ gửi lại bản tin Resv. Bản tin Resv sẽ gửi kèm theo phần mô tả yêu cầu Rspec chỉ định kiểu dịch vụ tích hợp là kiểm soát tải hay đảm bảo dịch vụ; ngoài ra còn có dấu hiệu nhận dạng luồng (flow descriptor) mà mỗi bộ định tuyến trung gian sẽ tiến hành quá trình điều khiển chấp nhận (admission control). Nếu yêu cầu không được chấp nhận, do không đủ tài nguyên mạng thì bộ định tuyến sẽ báo lỗi về phía đầu thu. Nếu yêu cầu được chấp nhận thì bộ định tuyến sẽ gửi bản tin Resv đến bộ định tuyến đã gửi bản tin Path cho nó. Ngoài ra, RSVP là giao thức mềm, có nghĩa là các bản tin Path và Resv sẽ được gửi lại sau khoảng thời gian nhất định để duy trì lâu dài sự chiếm giữ tài nguyên. Nếu sau khoảng thời gian này không có bản tin nào gửi đi, sự dự trữ tài nguyên sẽ bị xoá bỏ. Điều này sẽ có một số ưu điểm và nhược điểm được trình bày sau: Mặt khác, lưu lượng RSVP có thể đi qua bộ định tuyến không hỗ trợ RSVP. Tại những bộ định tuyến này dịch vụ được phục vụ theo mô hình nỗ lực tối đa. Nói tóm lại, RSVP đóng vai trò quan trọng trong quá trình triển khai việc chuyển tải nhiều dịch vụ như: âm thanh, hình ảnh, và dữ liệu trong cùng một hạ tầng mạng. Các ứng dụng có thể lựa chọn nhiều mức chất lượng dịch vụ khác nhau cho luồng lưu lượng của mình. 2.3.3. Kiến trúc IntServ: Cấu trúc của các bộ định tuyến và các bộ chuyển mạch có hỗ trợ RSVP trong mạng: Hinh 2.3. Mô hình dịch vụ IntServ Như vậy ta thấy cấu trúc gồm các khối: Khối điều khiển lưu lượng bao gồm: bộ phân loại (Classifier), bộ lập lịch gói (Scheduler). Khối điều khiển thu nhận và thiết lập dự trữ bao gồm: thực thể điều khiển thu nhận và thực thể thiết lập dự trữ. Đầu tiên các ứng dụng đưa ra yêu cầu lớp dịch vụ: đảm bảo dịch vụ hoặc kiểm soát tải đồng thời đặt đường dẫn và chiếm giữ tài nguyên mạng cho việc truyền dữ liệu. Khối điều khiển thu nhận sẽ xem xét có thể đáp ứng được các yêu cầu mà dịch vụ đưa ra hay không. Bộ phân loại tiến hành phân loại và đưa các gói dữ liệu nhận được vào hàng đợi riêng. Bộ lập lịch sẽ lập cách xử lý để đáp ứng yêu cầu về chất lượng dịch vụ. Hình 2.4. Kiến trúc IntServ. Trong hình vẽ, ở bước 1, các ứng dụng đưa ra yêu cầu mức chất lượng dịch vụ dành cho luồng lưu lượng xác định qua giao diện dịch vụ ứng dụng. Bộ điều khiển thu nhận và thiết lập dự trữ đáp ứng yêu cầu của các ứng dụng bằng cách tạo ra các bản tin của giao thức RSVP yêu cầu chiếm giữ tài nguyên. Bản tin này sẽ đi qua các bộ định tuyến nằm trên đường dẫn từ đầu gửi đến đầu thu. Tại mỗi bộ định tuyến, khối điều khiển thu nhận sẽ tiến hành quá trình điều khiển chấp nhận kết nối, quyết định xem có thể đáp ứng được yêu cầu chất lượng dịch vụ mà ứng dụng đưa ra hay không. Nếu được, bộ định tuyến sẽ dựa vào thông tin trong bản tin RSVP để cấu hình cho bộ điều khiển lưu lượng. Chúng ta đã xem xét kiến trúc của mô hình tích hợp dịch vụ cũng như một giao thức rất quan trọng RSVP. Mô hình này cho phép triển khai các ứng dụng thời gian thực và lưu lượng truyền thông trên cùng một hạ tầng mạng. 2.4. Mô hình phân biệt dịch vụ DiffServ: 2.4.1. Mô hình: DiffServ là một tập hợp công nghệ cho phép nhà cung cấp dịch vụ mạng đưa ra các dịch vụ mạng khác nhau cho khách hàng cũng như cho các dòng lưu lượng mạng của họ. DiffServ được dự trù là một môi trường để phân biệt dịch vụ khả thi và cho phép một giải pháp module hoá các mục tiêu QoS cho các nhu cầu khác nhau của ứng dụng. Cơ sở của các mạng DiffServ là các router bên trong mạng lõi có khả năng chuyển các gói của các lưu lượng khác nhau theo cách ứng xử trên từng bước mạng khác nhau. DiffServ đưa ra khái niệm DSCP, dùng 6 bit của trường ToS trong header của gói IP và do đó có thể chỉ định đến 64 giá trị mã khác nhau. PHB của gói IP được chỉ ra bởi mã DSCP. Kiến trúc DiffServ không dùng bất kỳ sự báo hiệu nào giữa các router, tất cả các quyết định chuyển gói đều dựa theo mã DSCP. Kiến trúc DiffServ chứa hai thành phần chính. Một là nguyên tắc ứng xử (PHB) trên đường dẫn chuyển gói và thứ hai là chính sách cấu hình các thông số trên đường dẫn chuyển gói cho từng PHB. Kiến trúc DiffServ có thể được xem như là bộ tinh chế của mô hình quan hệ ưu tiên trong đề xuất đánh dấu ưu tiên IPv4. Kiến trúc này hoàn toàn có thể làm việc với các ứng dụng hiện hữu mà không yêu cầu bất cứ thay đổi nào đối với API của chúng. 2.4.2. Phát triển QoS theo cơ chế DiffServ: 2.4.2.1. Tổng quan về triển khai dịch vụ theo kiến trúc DiffServ: Để nhận các dịch vụ từ nhà cung cấp dịch vụ, người dùng cần phải có hợp đồng mức dịch vụ SLA với nhà cung cấp dịch vụ. Một SLA về cơ bản là chỉ ra lớp dịch vụ được hỗ trợ và lượng tải cho phép trong mỗi lớp. Một SLA có thể là tĩnh hay động (Static SLA hay dynamic SLA). SLA tĩnh được thoả ước theo định kỳ từng tháng hay năm. Một SLA động đòi hỏi người dùng phải dùng giao thức báo hiệu để yêu cầu dịch vụ cho từng cuộc gọi. Người dùng có thể đánh dấu vào gói IP để chỉ ra dịch vụ mong muốn và router nội bộ sẽ đánh dấu gói IP trên cơ sở đó. Tại ngõ vào mạng của nhà cung cấp dịch vụ, gói sẽ được phân loại và điều chỉnh theo SLA đã được ký kết. Lượng bộ đệm cần cho các hoạt động này cũng được chỉ ra trong SLA. Khi gói đi từ domain này sang domain khác, trường ToS của nó có thể được đánh dấu lại dựa trên SLA đã ký kết giữa các domain. DiffServ sử dụng các cơ chế phân loại, chỉnh dạng và lập lịch để cung cấp các dịch vụ như: Premium Service cho các ứng dụng yêu cầu độ trễ và biến động trễ đều nhỏ. Assured Service cho các ứng dụng yêu cầu độ tin cậy tốt hơn dịch vụ Best-Effort. Olympic Service cung cấp bộ ba dịch vụ gồm vàng, bạc và đồng với chất lượng dịch vụ của vàng là tốt nhất và đồng là thấp nhất. Kiến trúc DiffServ chỉ định nghĩa các mã DSCP ghi trong trường ToS và các PHB. Còn dịch vụ cụ thể như thế nào là do các nhà cung cấp dịch vụ quy định. DiffServ khác đáng kể so với IntServ. Thứ nhất, nó chỉ có một số giới hạn các lớp dịch vụ được chỉ định. Vì dịch vụ được gán theo lớp nên lượng thông tin trạng thái lớn hay nhỏ là tuỳ vào số lượng lớp thay vì số lượng luồng như IntServ, nhờ đó DiffServ có tính khả triển (scalability) cao. Thứ hai, các hoạt động phân loại, điều chỉnh phức tạp chỉ diễn ra ở biên giới mạng. Các router bên trong domain chỉ cần phân loại các BA. Do đó, dễ dàng thực hiện và triển khai DiffServ. Các mạng của nhà cung cấp dịch vụ thường có các router biên kết nối với khách hàng và nối với các core router. Core router cần phải chuyển gói đi rất nhanh nên nhiệm vụ của chúng phải đơn giản hơn. Các router biên không cần phải chuyển gói đi rất nhanh vì hầu hết các liên kết với khách hàng đều chậm. Vì vậy các router biên có nhiều thời gian để phân loại và điều chỉnh lưu lượng. Các router biên tại các điểm truy nhập mạng NAP là ngoại lệ vì chúng phải chuyển gói đi rất nhanh và còn phải xử lý phân loại và điều chỉnh nên phải được trang trí tốt nhất. Trong mô hình DiffServ có thể gia tăng triển khai dịch vụ Assured Service. Các router không có khả năng DiffServ sẽ bỏ qua trường ToS của gói Assured Service và chuyển gói dạng này theo dịch vụ Best-effort. Tuy nhiên, vì các gói của Assured Service không bị bỏ rơi tại các DiffServ router nên chất lượng toàn cục của lưu lượng Assured Service vẫn tốt hơn so với lưu lượng của Best-offort. Assured Service có thể được thực hiện như sau: Đầu tiên, sự phân loại và điều chỉnh được thực hiện tại router ngõ vào của mạng phía ISP. Nếu tốc độ của lưu lượng không vượt quá tốc độ bit được chỉ ra trong SLA thì chúng được xem nhu phù hợp với đặc tả người dùng (user profile) và ngược lại. Thứ hai, tất cả các gói phù hợp hay không phù hợp đều được đặt vào một hàng đợi để tránh sai thứ tự. Thứ ba, hàng đợi được quản lý bởi một cơ chế quản lý hàng đợi gọi là phát hiện sớm ngẫu nhiên RED. RED là cơ chế quản lý hàng đợi huỷ bỏ gói sớm để ngăn ngừa nghẽn mạng. Điều này sẽ tác động lên cơ chế điều khiển luồng TCP tại các đầu cuối khác nhau khiến cho tốc độ truyền sẽ thay đổi. Bằng cách này RED có thể ngăn chặn hàng đợi của router khỏi bị tràn và do đó tránh được động thái bỏ đuôi (tail-drop). Dịch vụ Best-effort có thể được xử lý theo cách khác hay tượng tự với lưu lượng không phù hợp của dịch vụ Assured Service. Premium Service cung cấp dịch vụ có yêu cầu độ trễ và biến động trễ thấp cho khách hàng nên sẽ đảm bảo truyền với tốc độ đỉnh một cách cố định. Mỗi khách hàng sẽ có một SLA với ISP, trong đó chỉ ra tốc độ đỉnh mong muốn cho một luồng hay một tập hợp nhiều luồng. Khách hàng phải đảm bảo không để vượt quá tốc độ đỉnh đã ký kết, nếu không lưu lượng sẽ bị huỷ. Về phía ISP sẽ đảm bảo băng thông theo hợp đồng phải luôn khả dụng cho lưu lượng của khách hàng. Trong các mạng ISP, sự tập trung lưu lượng từ các router biên đến các core router bên trong là không thể tránh khỏi, nhưng điều này không thành vấn đề vì tốc độ ngõ ra lớn hơn tốc độ ngõ vào rất nhiều. Tuy nhiên, sự tập trung lưu lượng đến core router từ các core router khác thì không thể đảm bảo điều tương tự. Bản thân DiffServ không thể giải quyết được khó khăn này. Công nghệ lưu lượng phải được dùng để tránh nghẽn gây ra bởi sự phân phối lưu lượng mất cân đối. Bằng cách hạn chế lượng băng thông được yêu cầu bởi lưu lượng Premium Service, người quản trị mạng có thể đảm bảo lưu lượng của Premium Service không làm ảnh hưởng xấu đến lưu lượng của các dịch vụ khác. Một cách khác là dùng WFQ giữa hàng đợi của Premium Service và hàng đợi Assured Service. 2.4.2.2. Phương pháp phát triển hệ thống DiffServ: Công việc phát triển hệ thống DiffServ liên quan đến tổ chức và phát triển hai thành phần chính là bộ điều chỉnh lưu lượng (traffic conditioner) tại router biên và các PHB tại các router, đặc biệt là các core router. Lộ trình của các gói tin là khi vào router biên chúng sẽ được điều chỉnh lưu lượng cho phù hợp với SLA, sau đó được đưa tới giao tiếp lối ra của router, tại đó chúng sẽ được đánh mã DSCP theo PHB (là EF, AF hay BE) tương ứng với SLA. Công việc này liên quan đến sự phân loịa và chuyển gói vào hàng đợi tương ứng. Các thức kiểm soát các hàng đợi này được xác định bởi cơ chế lập lịch (scheduling mechanism) được dùng. Bộ lập lịch cho gói tin chịu trách nhiệm hướng dẫn giải phóng các gói tin từ các hàng đợi khác và truyền chúng lên mạng một cách có trật tự. Bên trong mạng, căn cứ vào các PHB của từng gói các core router sẽ chuyển các gói đi theo cách xử lý cho từng PHB. Như vậy trong phần tử mạng đầu tiên là router biên sẽ được phát triển một bộ điều chỉnh lưu lượng và các PHB. Trong phần tử mạng kế tiếp là các core router chỉ cần phát triển các PHB. a. Phát triển bộ điều chỉnh lưu lượng: Bộ điều chỉnh lưu lượng sẽ gồm các thành phần con là classifier, marker, meter, remarker hay shaper hay dropper. Thông thường các thành phần này được thực hiện bằng cách dùng một token bucket đơn và một token buket kép (Dual Token Bucket). Qua đó các thông số của luồng đã cam kết theo SLA được cấu hình thành một token bucket profile. Các gói lấy được token được xem là các gói hợp lệ (in-profile packet) và các gói còn lại là không hợp lệ (out-profile). Các token bucket bảo vệ các luồng với cửa sổ nhỏ, ngăn chặn sự mất gói bằng cách chỉ đánh dấu hợp lệ. Hình 2.5. Cấu trúc logic của bộ điều chỉnh lưu lượng. b. Phát triển các PHB: Sau khi các gói đã đi qua giao tiếp đầu vào của một router mà không bị huỷ sẽ được chèn vào giao tiếp đầu ra của router. Hàng đợi tại đầu ra có thể là một hàng đợi đơn giữ tất cả các gói của các lớp lưu lượng hay gồm một số các hàng đợi, mỗi hàng đợi giữ gói cho mỗi lớp lưu lượng khác nhau. Mỗi PHB được thể hiện qua hai cơ chế: cơ chế quản lý hàng đợi và cơ chế lập lịch gói. * Cơ chế quản lý hàng đợi: Lưu lượng của mỗi user được đánh dấu là in-profile hay out-profile. Các gói in-profile được gán một mức huỷ gói (drop precedence) thấp hơn các gói out-profile và được mã hoá bằng mã DSCP ghi trong trường ToS của gói. Nguyên lý quản lý hàng đợi tích cực RED được dùng để quản lý hàng đợi cho DiffServ. RED cho phép router huỷ gói trước khi hàng đợi bị tràn. RED làm được điều này bằng cách huỷ các gói theo một xác suất tùy thuộc vào chiều dài hàng đợi trung bình. Để thực hiện các mức huỷ khác nhau hay để hình thành các AFij, có các phương pháp đã được dùng như WRED, nguyên lý hàng đợi gồm nhiều RED gọi là GRED. * Cơ chế lập lịch gói: Có một số cơ chế lập lịch gói có thể được áp dụng bao gồm: FIFO PQ WFQ PQWFQ, giải thuật này là sự kết hợp của PQ và WFQ như trình bày trong hình 2.6 dưới đây. Hình 2.6. Tổ chức của cơ chế lập lịch PQWFQ Lưu lượng ưu tiên cao được chuyển đi với mức ưu tiên cao nhất, bất chấp sự hiện diện của các lưu lượng khác, nhằm hỗ trợ cho các dịch vụ yêu cầu nghiêm ngặt về thời gian thực, trong DiffServ thì dành cho EF PHB. Những lưu lượng khác gồm AF PHB và BE được lập lịch chuyển đi theo cơ chế WFQ. 2.4.3. Vấn đề quản lý tài nguyên: 2.4.3.1. Khái quát hiện trạng: Trong quá trình thực hiện QoS cho mạng IP, điều dễ nhận thấy là mặc dù kiến trúc IntServ đảm bảo cung cấp QoS một cách chắc chắn nhưng lại vấp phải vấn đề khả triển. Vì vậy, IETF đã đề xuất DiffServ như là giải pháp thay thế, trong đó lấy sự khác biệt dịch vụ làm nền tảng và chia thành các lớp dịch vụ khác nhau, kiến trúc này đã khắc phục được nhược điểm của IntServ vì có tính khả triển rất tốt. Tuy nhiên, để đáp ứng các nhu cầu của đa dạng ứng dụng trên thực tế, kiến trúc được triển khai cần phải có các giải thuật quản lý lưu lượng nào đó. Các giải thuật lưu lượng có thể được phân loại theo đơn vị thời gian hoạt động của chúng hay theo khả năng điều khiển. Do đó, các giải thuật này có thể hoạt động theo mức gói, mức khối số liệu hay mức kết nối. Trong số các giải pháp điều khiển lưu lượng theo từng cuộc gọi hay từng kết nối thì điều khiển chấp nhận là một trong số các giải pháp phổ dụng nhất. Điều khiển chấp nhận tuỳ theo vị trí hoạt động mà có thể là tập trung hay phân tán. Đại diện tiêu biểu cho điều khiển chấp nhận nối phân tán là RSVP và một số các giải thuật khác. Các giải pháp tập trung tiêu biểu được đề xuất cho mạng DiffServ là giải pháp dùng một thành phần điều khiển gọi là Bandwidth Broker(BB). Ý tưởng cung cấp cơ chế điều khiển chấp nhận nối theo luồng cho các mạng IP DiffServ nhằm cải thiện chất lượng dịch vụ đã nhận được sự đồng thuận trong cộng đồng nghiên cứu Internet. Cần thiết định nghĩa thêm chức năng điều khiển chấp nhận kết nối cho kiến trúc DiffServ, để xác định xem có cho phép một luồng lưu lượng mới hay không. Thực tế, một hạn chế của DiffServ là thiếu một cơ chế điều khiển chấp nhận kết nối chuẩn và do đó không thể giải quyết một cách cơ bản bài toán nghẽn trên mạng Internet. Khi có quá tải trên một lớp dịch vụ thì tất cả các luồng của lớp dịch vụ này đều chịu một sự suy giảm chất lượng trầm trọng. Một vài giải thuật điều khiển chấp nhận nối cùng với các chỉ dẫn tham khảo trong đó. Các đề xuất này cùng chia sẻ ý tưởng mỗi nút mạng nên chấp nhận các luồng mới tuỳ vào các đo lường nghẽn giữa nguồn và đích và tiêu chuẩn quyết định cục bộ. Không có báo hiệu tường minh trong các router và quyết định sau cùng có cho phép hay từ chối một luồng mới được đẩy về biên của mạng IP. Một giải pháp khác kết hợp việc đo lường tại mỗi nút mạng với một pha thăm dò từ đầu cuối này đến đầu cuối kia, được gọi là GRIP. GRIP gần gũi với các cơ chế phân tán, gọi là EAC. Với GRIP, điều khiển chấp nhận kết nối được thực hiện bằng cách gửi một gói thăm dò từ nguồn đến đích và quyết định chấp nhận kết sẽ dựa vào đo lường băng thông cục bộ tại mỗi router. Cũng bằng cách thăm dò, giải pháp PBAC chấp nhận kết nối dựa vào tỉ lệ mất gói trong một pha thăm dò ngắn. Các gói thăm dò sẽ được thực hiện với tốc độ đỉnh của kết nối. Với tỉ lệ mất gói bị chặn bởi một giá trị ngưỡng qui định trước, một luồng chỉ được chấp nhận nếu tỉ lệ mất gói xác định trong pha thăm dò nhỏ hơn ngưỡng này. Gần đây có các giải pháp như là sự nối tiếp của giao thức báo hiệu điều khiển tải đơn giản LCLSP. Các giải pháp này tập trung phát triển một giải thuật quản lý lưu lượng ưu tiên dùng mô hình quyết định phân tán cùng với sự tính toán trạng thái tải trên cơ sở đăng ký hay đo lường nghẽn. Các giải pháp này được đề nghị trong tổ chức tiêu chuẩn IETF bao gồm RMD. Cho đến nay, có thể nói chủ đề bổ sung cơ chế điều khiển chấp nhận kết nối cho DiffServ rất được quan tâm và cũng đang được chuẩn hoá bởi IETF. 2.4.3.2. Giải pháp quản lý tài nguyên RMD: RMD là một kỹ thuật nhằm bổ sung điều khiển chấp nhận và chức năng đăng ký cho mạng DiffServ. RMD điều khiển lưu lượng bằng hai cách: điều khiển chấp nhận luồng mới và giải thuật loại bỏ một số luồng nếu mạng bị nghẽn. Qua đó RMD cung cấp một cơ chế QoS linh động đảm bảo tính khả triển. Các biên của domain được kiểm soát dựa vào một cơ chế điều khiển tải có phản hồi. Cơ chế này kiểm tra tài nguyên khả dụng trong tất cả các nút mạng trên đường truyền giữa hai biên của domain. Các router giữa hai nút biên áp dụng cơ chế báo hiệu NSIS. Một trong các đặc tính khả dụng quan trọng của RMD là các nút mạng bên trong không lưu giữ thông tin trạng thái của từng luồng. Chỉ yêu cầu lưu giữ trạng thái từng luồng tại các nút biên khi hoạt động quản lý dựa trên cơ sở đo lường. Khi hoạt động quản lý dựa trên cơ sở đăng ký thì cũng cần lưu giữ trạng thái nhưng là của tập hợp lưu lượng trên từng PHB (không phải cho từng luồng) tại các nút bên trong. RMD đăng ký theo từng đơn vị tài nguyên, một đơn vị tài nguyên có thể là một lượng băng thông nhất định, được đăng ký theo từng PHB tại mỗi nút dọc theo đường truyền giữa hai biên. Số đơn vị tài nguyên được gán cho một luồng nào đó và số lượng tài nguyên dùng trong một RMD domain được xác định bởi chính sách cục bộ được cấu hình trong QNF. Mô hình RMD QoS là linh hoạt có thể áp dụng cho đăng ký tài nguyên trên mạng lớn, truyền một lượng lớn các luồng thời gian thực cùng lúc, cũng có thể được dùng trong các mạng di động. Một kỳ vọng khác vào RMD là khả năng đáp ứng nhanh đối với tình huống hỏng liên kết hay nút. Khi nghẽn bị phát hiện, các nút bên trong sẽ thông báo cho các router biên bằng cách đánh dấu vào gói số liệu hay cài một bit trong thông điệp làm tươi để cảnh báo nghẽn. Các router biên sẽ quyết định huỷ bỏ một số luồng nào đó để cải thiện tình hình. * Hoạt động quản lý trên cơ sở đo lường: Nếu phương pháp quản lý tài nguyên trên cơ sở đo lường được dùng thì thành phần RMD chịu trách nhiệm đo lường và định kỳ cập nhật các tài nguyên khả dụng cho mỗi PHB. Quyết định chấp nhận sẽ căn cứ trên sự so sánh giữa số tài nguyên còn khả dụng và tài nguyên được yêu cầu. * Hoạt động quản lý trên cơ sở đăng ký: Khi dùng phương pháp này việc đăng ký tài nguyên là công việc thêm vào hay loại bỏ các đơn vị tài nguyên. Nguyên lý trạng thái mềm được dùng để kiểm soát trạng thái đăng ký được xác lập bên trọng một domain. Một trạng thái cần phải được làm tươi cho một luồng cụ thể. Nếu không được làm tươi, số đơn vị tài nguyên cho luồng sẽ bị thu hồi sau một khoảng thời gian định trước. Cũng có thể giải phóng tài nguyên bằng một thông điệp báo hiệu tường minh. 2.4.3.3. Giải pháp PCN: Giải pháp thông báo tiền nghẽn PCN là một giải pháp DiffServ trong đó các nút bên trong cố gắng phát hiện nghẽn. PCN tương tự như ECN là giải pháp đánh dấu các gói khi mạng thực sự bị nghẽn. Tuy nhiên, các giải thuật PCN thông minh hơn ở chỗ sẽ cố gắng phán đoán các nghẽn trước khi chúng xảy ra. Một nút trong mạng dùng PCN sẽ đánh dấu các gói IP mà nó chuyển đi khi dự báo có nguy cơ xảy ra nghẽn. Các nút biên nhận được các gói bị đánh dấu sẽ gửi một ước lượng mức đọ nghẽn đến nút lối vào để ngăn chặn việc chấp nhận các luồng mới, nhờ đó bảo vệ được các luồng hiện hữu. Các giải thuật đo và đánh dấu đóng vai trò hết sức quan trọng trong PCN. Hiện nay IETF đang bàn thảo hai hướng chính là Threshold marking và Excess marking. 2.4.4. Phát triển IP QoS trên nền MPLS: 2.4.4.1. MPLS hỗ trợ QoS cho IP: MPLS là một giải pháp để tăng tốc độ truyền số liệu qua mạng được để xuất bởi IETF. Như đã biết, trong hoạt động IP thông thường, header của gói được kiểm tra tại các điểm trung chuyển (mutiplexer, router hay switch) tốn nhiều thời gian làm tăng tổng thời gian trễ. Giải pháp hiệu quả hơn là đính nhãn (label) cho các gói sao cho việc phân tích các gói tại các điểm trung gian là không còn cần thiết nữa. MPLS thực hiện điều này bằng cách đính nhãn thích hợp cho các gói IP tại các lối vào của các router biên trong mạng dùng MPLS. Với MPLS nhà cung cấp dịch vụ có thể định nghĩa các đường dẫn đặc biệt cho lưu lượng qua mạng IP thay vì buộc các router trung gian phải đưa ra các quyết định chuyển gói. Như vậy, MPLS giải quyết vấn đề QoS cho mạng Ip bằng cách thiết lập các đường dẫn tường minh qua mạng. Các đường dẫn được gọi là LSP cung cấp một phương tiện để đảm bảo một chất lượng dịch vụ đặc biệt, chất lượng này được cung cấp từ hạ tầng mạng bên dưới theo mô hình phân lớp chức năng của ISO. Lưu lượng của một dạng nào đó có thể được nhóm lại trên một đường chuyển mạch nhãn đặc biệt, các kỹ thuật của công nghệ lưu lượng được áp dụng vào đường dẫn này để có một dung lượng nhằm đảm bảo một mức phẩm chất nào đó cho dịch vụ. 2.4.4.2. Kết hợp DiffServ và MPLS: MPLS có khả năng khôi phục và bảo vệ nhanh chóng hơn khi cấu hình mạng thay đổi so với các hệ thống IP chuẩn. Khả năng này được gọi là sự bảo vệ MPLS (MPLS protection) và chúng có thể cung cấp các mức bảo vệ khác biệt cho các đường dẫn khác nhau. Để hỗ trợ DiffServ, có thể linh hoạt ánh xạ các BA vào các đường dẫn LSP sao cho phù hợp nhất. Tuy nhiên, điều khó khăn là MPLS không nhận ra những gì được mang trong phần nội dung (payload) nên lớp MPLS không thể thấy được các DSCP của gói DiffServ. Cung cấp một giải pháp cho hỗ trợ DiffServ qua MPLS, trong đó có hai cách cơ bản để giải quyết khó khăn này. Thứ nhất là dùng một trường trong shim header để ánh xạ sang các PHB tương ứng với các DSCP trong IP header. Cách thứ hai là tạo ra các đường dẫn LSP riêng biệt cho mỗi PHB được chỉ ra bởi DSCP. Các LSP trong cách thứ nhất được gọi là E-LSP và trong cách thứ hai chúng được gọi là L-LSP. Ngoài ra, trong đề xuất ý tưởng dùng LSP của MPLS như là tuyến hướng dẫn các gói báo hiệu thực hiện thủ tục điều khiển chấp nhận kết nối trong mạng DiffServ. Điều này sẽ khắc phục khó khăn do không có đường dẫn tường minh để thực hiện thủ tục CAC trong mạng DiffServ. Từ đó sẽ bổ sung vào DiffServ khả năng quản lý và đăng ký tài nguyê