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 ở video không hỗ trợ QoS.