3.3.1 Định tuyến mỗi luồng trong OpenQoS
Internet hiện nay không cho phép định tuyến trên nền tảng mỗi luồng. Khi một gói tin đến tại bộ định tuyến, nó sẽ kiểm tra cặp địa chỉ nguồn và đích của gói tin với các mục trong bảng định tuyến và chuyển tiếp theo quy tắc xác định trước (ví dụ như các giao thức địch tuyến) được cấu hình bởi nhà điều hành mạng. Mặt khác, OpenFlow cung cấp sự linh hoạt để xác định các kiểu luồng khác nhau để thiết lập có thể liên kết các hoạt động và các quy tắc. Ví dụ như một kiểu luồng có thể được chuyển tiếp nhờ thuật toán định tuyến đường đi ngắn nhất trong khi các
luồng khác có thể theo các cấu hình định tuyến thủ công qua mạng. Vì vậy, mỗi luồng (gói tin) có thể được xử lý khác nhau tại lớp mạng.
Trong OpenFlow, chúng ta có thể xác định các luồng theo nhiều cách. Luồng có thể chưa các dạng gói tin giống hoặc khác nhau. Ví dụ, các gói tin với TCP công số 80 (dành cho HTTP) có thể được một luồng xác định, hoặc các gói tin có tiêu đề RTP có thể chỉ một luồng mang tiếng, một mạng video hoặc cả hai. Về bản chất, nó có thể thiết lập các luồng như một sự kết hợp các trường tiêu đề như mình họa
Hình 3. 3: Các trường nhận dạng luồng trong OpenFlow
Nhưng các nhà điều hành mạng cũng nên đặt các giới hạn công suất xử lý của các thiết bị mạng (router hoặc Switch) vào tài khoản. Để tránh phức tạp tra cứu bảng lưu lượng, việc nhận dạng luồng nên được khéo léo thiết lập và tổng hợp nếu có thể. Trong OpenFlow, thiết bị mạng lưu trữ các luồng và các quy tắc liên quan ở các bảng luồng được xử lý như một đường ống dẫn.
Hình 3. 4: Các bảng luồng và xử lý đường ống của chúng Mục đích của việc xử lý đường ống là để giảm thời gian xử lý gói.
OpenQoS khai thác mô hình chuyển tiếp luồng cơ sở của OpenFlow để chúng phân biệt dữ liệu và lưu lượng đa phương tiện. Các luồng đa phương tiện có thể được xác định bằng cách sử dụng các trường tiêu đề gói tin hoặc các giá trị sau:
TOS (loại dịch vụ) trường IPv4
Trường lớp lưu lượng trong IPv6
Nếu máy chủ đa phương tiện biết được, địa chỉ IP nguồn
Các cổng nguồn hoặc đích giao vận
Người ta mong muốn xác định các luồng theo các tiêu đề gói tin lớp thấp hơn (Lớp 2, lớp 3) khi đó sự phức tạp trong việc phân tích gói tin thấp hơn so với việc xử lý lên đến tầng trên (Lớp 4). Do đó, để xác định các luồng đa phương tiện bằng cách sử dụng các trường trong MPLS được coi như lớp nằm giữa lớp liên đến dữ liệu và lớp mạng (lớp 2.5) thêm vào đó là khả năng chuyển mạch cực nhanh. Tuy nhiên trong một số trường hợp các trường tiêu đề lớp trên cũng có thể được yêu cầu phân loại gói tốt hơn, điều mà OpenFlow cho phép xác định linh hoạt sử dụng các trường lớp trên (lớp 4). Bên cạnh đó, các xác định luồng có thể không dựa trên IP hiện tại. Bất kỳ hệ thống địa chỉ với thông tin mức dịch vụ có thể được sử dụng để xác định loại các luồng đa phương tiện.
Để tính toán các đường đi QoS, nó là điều cần thiết để thu thập thông tin cập nhật trạng thái mạng toàn cầu như độ trễ, tỷ lệ mất gói mỗi liên kết. Hiệu suất của bất kỳ thuật toán định tuyến có liên quan trực tiếp đến cách để có thông tin trạng thái mạng chính xác. Trong các mạng lớn, thu thập thông tin các trạng thái mạng toàn cầu có thể là một thách thức bởi quy mô mạng. Vấn đề càng trở nên khó khắn hơn trong mạng Internet vì các kiến trúc phân tán hoàn toàn (hop by hop). OpenFlow giúp giảm bớt việc này bằng cách sử dụng một bộ điều khiển trung tâm. Thay vì chia sẻ thông tin trạng thái mạng với tất cả các bộ định tuyến khác, bộ chuyển tiếp OpenFlow trực tiếp gửi thông tin trạng thái mạng địa phương tới bộ điều khiển. Sau đó bộ điều khiển thu thập thông tin trang thái của các bộ chuyển tiếp và tính toán các tuyến đường phù hợp khả thi nhất.
3.3.2 Tối ưu hóa định tuyến động QoS
Việc định tuyến động giống như vấn đề về hạn chế đường dẫn ngắn nhất (CSP - Constrained Shortest Path). Trong các ứng dụng đa phương tiện, chỉ số QoS
điển hình là sự mất gói tin, trễ và trế biến đổi (jitter). Tuy nhiên chỉ số QoS có thể khác nhau tùy thuộc vào loại ứng dụng, chẳng hạn như:
Các ứng dụng đa phương tiện tương tác có yêu cầu nghiêm ngặt về độ trễ giữa các thiết bị đầu cuối (ví dụ 150-200ms cho hội nghị truyền hình). Vì vậy hạn chế vấn đề CSP nên dựa vào tổng trễ.
Các ứng dụng luồng video đòi hỏi điều kiện mạng ổn định cho phát sóng video liên tục, tuy nhiên trễ khởi động ban đầu có thể khác nhau. Điều này cho thấy rằng các trễ biến đổi được yêu cầu phải có giới hạn, vì vậy hạn chế vấn đề CSP phải dựa trên trễ biến đổi.
Đây là điều rất quan trọng để lựa chọn số đo chi phí và các hạn chế mà cả hai đều là đặc trưng cho các điều kiện mạng giúp hỗ trợ các yêu cầu QoS.
3.4 Một số kết quả chức năng quản lý định tuyến và tính toán định tuyến của OpenQoS trong mạng của OpenQoS trong mạng
3.4.1 Mô hình thử nghiệm
Mô hình xây dựng một mạng lưới được biểu diễn như một hình vẽ đơn giản có hướng G(N,A) với N là tập hợp các nút và A là tập hợp các liên kết, do đó liên kết (i,j) là một cặp lệnh, đi ra từ nút I và đến nút j. Cùng đó Rst là tập hợp các tuyến đường (tập con của A) từ nút nguồn s đến nút đích t. Đối với bất kỳ tuyến đường
st rR ta xác định được chi phí fC và độ trễ fD bằng cách tính ij ( , ) ( ) C i j r f r c (1) ij ( , ) ( ) D i j r f r d (2)
Trong đó cij và dij là hệ số chi phí và trễ của các liên kết (i,j) tương ứng. Việc tìm kiếm về CSP có thể tìm một đường định tuyến có giá trị r để hàm chi phí fCcó giá trị nhỏ nhất với độ biến đổi trễ fD Dmax dựa trên công thức:
*
max
arg min{ ( ) |r c st, D( ) }
Ở đây bài toán chọn chi phí sau:
ij ij ij ( , )
c g d i j A (4)
Hình 3. 5: Mô hình mạng kiểm tra OpenFlow [10]
Với gij biểu diễn giá trị cho lưu lượng liên kết (i,j) bị ùn tắc và dij là số đo độ trễ. OpenQoS sẽ thu thập các tham số cần thiết gij và dij để dùng cho chức năng quản lý định tuyến. Thuật toán LARAC (Lagrangian Relaxation Based Aggregated Cost) được sử dụng cho chức năng tính toán định tuyến của OpenQoS, đây là một thuật toán thời gian đa thức giúp tìm kiếm hiệu quả một tuyến đường tốt mà ít sai lệch. Khi chức năng quản lý định tuyến cập nhật các tham số QoS hoặc chức năng quản lý topo phát hiện các thay đổi trong cấu trúc mạng, chức năng tính toán định định tuyến chạy thuật toán LARAC để giải quyết vấn đề CSP.
Mô hình thử nghiệm gồm ba bộ OpenFlow kích hoạt Switch Pronto 3290, một bộ điều khiển và máy host. Như trong hình, thiết bị chuyển mạch được kết nối trong một hình tam giác để có sự đa dạng về đường đi. Mỗi chuyển mạch khởi tạo
như hình 3.5). OpenQoS được đặt trên một bộ điều khiển OpenFlow, Floodlight. Ở đây có thể sử dụng bộ điều khiển thay thế như NOX, Beancon, Maestro thành OpenQoS nhưng hiện tại Floodlight là bộ điều khiển ổn định nhất. Floodlight là một bộ điều khiển mã nguồn mở viết bằng Java, cung cấp một môi trường lập trình modun để ta dễ dàng thêm các Modul mới lên phía trên và quyết định những Modul nào có thể chạy. Ở đây, hai Modul chính được thêm vào cho phép quản lý chức năng định tuyến và chức năng tính toán đường đi. Chức năng quản lý Topo được thực hiện trong Floodlight là Modul trong OpenQoS. Những chức năng này là các khối cơ bản trong thiết kế của bộ điều khiển để có thể định tuyến QoS động
Quản lý định tuyến: Modul quản lý định tuyến cung cấp một trong các chức năng quan trọng trong bộ điều khiển QoS. Nó thu thập các thông tin trang tháí mạng cập nhật như tốc độ liên kết, băng thông khả dụng và gói tin rớt đếm ở các bộ chuyển tiếp. Bộ điều khiển yêu cầu các thống khác nhau từ các bộ chuyển tiếp bởi các bản tin FEATURE_REQUES và gửi lại các bộ chuyển tiếp bằng bản tin FEATURE_RELY gồm những số liệu yêu cầu.Để hỗ trợ QoS động, điều cần thiết là phải cần cập nhật thông tin trạng thái mạng. Thực hiện tính toán định tuyến phụ thuộc vào độ chính xác của dữ liệu thu thập được. Vì vậy bộ điều khiển OpenQoS thu thập định kỳ băng thông khả dụng với mỗi lin kết. Chu kỳ được thiết lập là 1 giây kể từ khi nó được chứng minh rằng lưu lượng Internet hoạt động như phân phối Posson độc lập. Sau khi nhận được số đo băng thông khả dụng ở các bộ chuyển tiếp, Module quản lý định tuyến phát hiện xem có tắc nghễn ở bất cứ liên kết nào và xác định tham số chi phí liên kết để sử dụng trong việc tối ưu hóa vấn đề đã trình bày công thức (3).
Mỗi liên kết có thể ở hai trạng thái: tắc nghẽn hoặc không tắc nghẽn. Trong thực tế, một liên kết được giả định là tắc nghẽn nếu việc sử dụng liên kết đó vượt quá giới hạn 75%-85% (Khoảng 70% băng thông được sử dụng thì liên kết bắt đầu bị tắc nghẽn). Các chi phí liên kết được xác định bằng cách sử dụng công thức (4), ở đó giá trị đo tắc nghẽn là:
ij ij ij ij ij ij ij ij 0.7 , 0.7 0, 0.7 T B B T T g B T (5)
Với Tij là tổng lưu lượng toàn bộ theo bps và Bijlà băng thông đạt được tối đa theo bps trên liên kết (i, j). Chú ý rằng, ở (5), các liên kết không tăc nghẽn nhận giá trị đo tắc nghẽn bằng 0. Tham số trễ dij ở (4) thiết lập là 1 để tương ứng với việc đếm hop. Điều này do việc triển khai chuyển mạch OpenFlow không có bất kỳ sự hỗ trợ việc thu thập số liệu thống kê liên quan đến trễ (tổng trễ, jitter). Để thêm một sự kiện dựa trên tự động định tuyến QoS, quản lý định tuyến phát tín hiệu đến bộ chuyển tiếp khi định tuyến QoS cần định tuyến lại. Tín hiệu này có thể đạt được bằng cách xoá một mục luồng cụ thể. Sau khi một mục luồng QoS bị xoá, các bộ chuyển tiếp không biết chuyển tiếp các gói mới đến, do đó chúng hỏi bộ điều khiển để xác định các mục luồng mới (các gói đa phương tiện) được định tuyến lại.Việc xoá luồng được cho phép trong hai trường hợp: (1) Nếu một liên kết không bị tắc nghẽn trước đó bây giờ bị tắc nghẽn, chúng ta xoá các mục luồng phù hợp với các gói tin đa phương tiện (QoS) trong bảng phân luồng của bộ chuyển tiếp. (2) Nếu một liên kết tắc nghẽn trước đó không bị tắc nghẽn trong ba giai đoạn cuối, ta một lần nữa xoá các luồng phù hợp. Ở đây ta yêu cầu ba giai đoạn của trạng thái không tắc nghẽn để đảm bảo không có biên động trong tỉ lệ lưu lượng ở liên kết.
Tính toán định tuyến: Ở Floodlight, việc tính toán định tuyến được thực hiện khi một tin nhắn PACKET_IN đến bộ điều khiển. Nó tính toán định tuyến đường ngắn nhất và đẩy luồng xác định đến các chuyển mạch theo đường dẫn phù hợp đó. Mặt khác, OpenQoS đầu tiên kiểm tra nếu nó là một gói đa phương tiện hoặc không, dựa trên luồng xác định lại thiết lập. Rồi module tính toán định tuyến tính hai đường dẫn giữa cặp nguồn và đích của gói tin đến. Một đường dẫn là đường dẫn QoS tối ưu và đường khác là đường ngắn
nhất. Lưu ý rằng các định tuyến QoS được tính toán sử dụng thuật toán LARAC.
3.4.2 Một số kết quả chức năng quản lý định tuyến và tính toán định tuyến của OpenQoS trong mạng tuyến của OpenQoS trong mạng
Để chứng minh cho hiệu suất thực hiện của OpenQoS, thí nghiệm xây dựng một môi trường luồng video qua một mạng thử nghiệm như trong hình 3.5. Trong suốt quá trình thử nghiệm ta sử dụng một chuỗi thử nghiệm được biết đến có 500 khung với độ phân giải 1280x720. Ta lặp chuỗi video chưa xử lý đảo ngược lại một lần để có 1000 khung kéo dài khoảng 40s. Sau đó ta mã hoá các chuỗi lặp định dạng H.264 sử dụng bộ mã hoá ffmpeg (v.0.7.3) ở ba tốc độ bit trung bình khác nhau để có:
Luồng 1 ở 1800kbps (32.55dB)
Luồng 2 ở 900 kbps (30.57dB)
Luồng 3 ở 450 kbps (28.75dB)
Ba luồng video H.264 này được dùng trong hai thử nghiệm sau: A. Luồng UDP
Trong thử nghiệm này, kịch bản thứ nhất đưa ra là hai bản sao của luồng 1 được gửi từ server ở địa chỉ 192.168.110.100 tới client vơi địa chỉ IP 192.168.110.101 (như hình 3.5). Server sử dụng phần mềm VLC chạy các luồng video sử dụng RTP/UDP. Một bản sao của video được gửi tới đích ở cổng 5004 trong khi đó một bản sao khác được gửi tới cổng 5005. Để thể hiện sự khác biệt hiệu suất về QoS, ta gán các luồng đa phương tiện (QoS flows) tới cổng giao vận số 5004. Do đó, các gói video đưa tới cổng 5004 được xác đinh như thành phần của một luồng đa phương tiện bởi bộ điều khiển OpenQoS và được định tuyến phù hợp trong khi các video khác (đưa tới cổng 5005) được xem như một luồng dữ liệu mà không hỗ trợ QoS (như Best effort).
Trong mỗi lần kiểm tra, lưu lượng cắt qua trong 10 giây được gửi tới từ tải (192.168.110.102) tới client một lần tại thời điểm bất kỳ. Client chạy hai phiên VLC player, lắng nghe các gói tin RTP/UDP ở cổng 5004 và 5005 để lưu các video
nhận được. Ta xem xét sự ảnh hưởng của lưu lượng cắt qua ở trên hai cổng 5005 và 5004. Các kết quả thu được bằng cách đo chất lượng của chúng sử dụng giá trị tín hiệu đỉnh tới tỉ lệ tạp âm (PSNR- peak signal to noise ratio) đối với video thô ban đầu như trong hình 3.6 và hình 3.7.
Hình 3. 6: Kết quả trường hợp tốt nhất của luồng UDP [10]
Hình 3. 7: Kết quả một trường hợp của luồng UDP [10]
Các đường nét đứt đọc đánh dấu sự bắt đầu và kết thúc của lưu lượng cắt ngang. Kết quả tốt nhất ở hình 3.6 ở đó video được hỗ trợ QoS (w/QoS) không bị ảnh hưởng bởi lưu lượng giao cắt và đầy đủ chất lượng video đề xuất, trong khi video không hỗ trợ QoS (w/o QoS) chất lượng bị giảm đáng kể. Tuy nhiên ở hình
khi thử nghiệm lặp đi lặp lại 20 lần, giai đoạn phục hồi tổn thất trung bình là 0.76 giây. Do đó hầu hết người sử dụng xem video không bị ảnh hưởng từ sự mất mát chất lượng trong một khoảng thời gian nhỏ như vật ngay cả khi sử dụng UDP không đảm bảo tin cậy.
B. HTTP dựa trên các luồng thích ứng
Kịch bản kiểm ra tiếp theo xây dựng tương tự như thảo luận trong phần A ở đó TCP được sử dụng như một giao thức giáo vận thay vì UDP. Các server gửi:
Luồng 1 hỗ trợ QoS
Một video không hỗ trợ QoS chọn thích ứng theo luồng 1, 2 và 3
Đối với luồng video thích ứng, ta sử dụng Adobe Flash Media Server 4,5. Về phía máy chủ, mỗi luồng video (luồng 1, 2 và 3) được chia thành các luồng phụ kéo dài 4 giây và một danh sách m3u8 liên quan được tạo ra. Tại phía khách hàng, bộ chới VLC đầu tiên tải danh sách m3u8 rồi chọn một luồng phụ tốc độ thich nghi thích phù hợp. Trong khi tải như hình 3.5 đặt lưu lượng qua 10 giây, video hỗ trợ QoS (như luồng 1) được định tuyến lại và video không hỗ trợ QoS có tốc độ thích ứng.
Hình 3.8 minh họa sự khác biệt về chất lượng giữa tốc đô thích ứng (w/o QoS) và định tuyến lại QoS của một mẫu kiểm tra. Kịch bản thí nghiểm lặp lại trên 30 lần và kết quả thu được không phát hiện được bất kỳ sự mất mát về chất lượng ở