3.3.1 Cấu hình hệ thống
Kiến trúc hệ thống demo bao gồm một topo mạng SDN đơn giản đƣợc xây dựng trong mininet với một bộ điều khiển. Bộ điều khiển đƣợc sử dụng là bộ điều khiển tách rời Ryu. Để bắt đầu kịch bản, sử dụng mininet xây dựng môi trƣờng ta tạo ra topo mạng đơn giản để mô phỏng. Topo mạng với 2 thiết bị chuyển mạch OpenvSwitch và 2 host nhƣ hình 3.3 với câu lệnh sử dụng sau:
$ sudo mn –topo linear,2 --mac --switch ovsk --controller remote –x
Bảng 3.2 và hình 3.3 thể hiện mô tả các tham số sử dụng trong mô phỏng cũng nhƣ kết quả đầu ra của câu lệnh trên. Hệ thống demo đƣợc tạo ra sẽ là một topo mạng SDN có 2 nút chuyển mạch SDN đƣợc kết nối trực tiếp với nhau và đƣợc điều khiển thông qua một bộ điều khiển Ryu. Hình 3.4 thể hiện rõ hơn cấu hình mạng mô phỏng.
Hình 3.3Môi trƣờng mô phỏng trong mininet
Bảng 3.2 Tham số kịch bản mô phỏng Tham số Giá trị Giải thích
Topo Linear, 2 Topo với 2 switch đƣợc tạo ra
mac None Thiết lập địa chỉ mac tự động cho host
Switch ovsk Sử dụng OpenvSwitch
controller remote Sử dụng một bộ điều khiển tách rời
Hình 3.4 Cấu hình mạng mô phỏng
Hình 3.5 thể hiện các thông số phiên bản của Switch và các thông số trên
cổng chuyển mạch của các Switch đƣợc kiểm tra bằng câu lệnh ovs-vsctl show
thực hiện trong giao diện điều khiển mininet.
Kết quả thể hiện trên hình 3.5 cho thấy hệ thống chuyển mạch đang trao đổi với bộ điều khiển thông qua giao thức Openflow phiên bản 1.3 và Openflow lắng nghe trên cổ ng ptcp: 6632 để truy cập OVSDB. Phiên bản OpenvSwitch sử dụng là phiên bản 2.0.2. Hình 3.6 thể hiện bộ điều khiển Ryu đã kết nối thành công và điều khiển thiết bị chuyển mạch.
Hình 3.6 Kết nối thành công giữa bộ điều khiển Ryu và thiết bị chuyển mạch
3.3.2 Module điều khiển định tuyến đảm bảo QoS
Trong hệ thống mô phỏng, để thực hiện điều khiển định tuyến cho bộ chuyển mạch ở lớp cơ sở hạ tầng, phần mềm ứng dụng cho bộ điều khiển dựa trên ngôn ngữ Python đã đƣợc xây dựng. Việc sử dụng máy tính cỡ nhỏ với giá thành rẻ kết hợp với các phần mềm điều khiển mã nguồn mở cho phép giảm thiểu giá thành hệ thống là tăng tính linh hoạt trong việc ứng dụng hệ thống. Thiết bị điều khiển SDN kích thƣớc nhỏ đã điều khiển chuyển mạch qua giao thức OpenFlow.
Để xử lý tác vụ thêm vào bảng định tuyến, giá trị địa chỉ sẽ đƣợc kiểm tra sự
trùng lặp địa chỉ. Lỗi xảy ra khi (1) địa chỉ đích (dst_nw_addr) là default route
(0.0.0.0/0) và (2) địa chỉ đích trùng với địa chỉ nguồn của bản tin, thông báo lỗi sẽ đƣợc hiển thị trên màn hình điều khiển. Nếu không có lỗi xảy ra, địa chỉ mới sẽ
đƣợc gán thêm vào bảng với giá trị địa chỉ đích (dst_ip), định danh luồng tin
(route_id), mặt nạ địa chỉ (netmask) kèm địa chỉ bộ chuyển mạch hàng xóm chuyển
luồng dữ liệu khác. Đoạn code ở Hình 3.7 minh họa cho quá trình cập nhật vào bảng định tuyến.
Hình 3.7 Đoạn chƣơng trình cập nhật vào bảng định tuyến
Thêm nữa, hình 3.8 mô tả cách xử lý luồng dữ liệu gửi đến bộ chuyển mạch. Các địa chỉ hàng xóm của một bộ chuyển mạch đƣợc lấy ra từ bảng định tuyến
thông qua biến routing_tbl. Sau đó, luồng tin đi đến bộchuyển mạch sẽ đƣợc xử lý
ở hàm packet_in_handler(). Các gói tin đƣợc phân loại theo bản tin ARP, bản tin
ICMP, TCPhay UDP. Mỗi loại bản tin sẽ đƣợc phân tích địa chỉ đích và gửi đến đúng thiết bị đầu cuối kết nối với bộ chuyển mạch. Nếu các bản tin thuộc loại khác thì sẽ đƣợc xử lý để chuyển đến một nút chuyển mạch khác.
Hình 3.8 Đoạn chƣơng trình xử lý luồng dữ liệu đến
3.3.3 Đánh giá và nhận xét kết quả
Trong kịch bản đã mô phỏng hoạt động của hệ thống và sử dụng công cụ WireShark (phần mềm bắt các gói tin) khi thiết lập kết nối và truyền thông qua hệ thống chuyển mạch đƣợc thiết kế. Hình 3.9 thể hiện kết quả đạt đƣợc trong đó cho thấy hệ thống hoạt động đúng theo thiết kế. Các bản tin Openflow đƣợc sử dụng để trao đổi thông tin kết nối giữa bộ điều khiển (192.168.60.100) và hệ thống chuyển mạch trên mininet (192.168.60.20).
Hình 3.9 Bắt gói tin trao đổi bằng Wireshark
Hình 3.10 Trao đổi bản tin giữa bộ điều khiển Ryu và hệ thống chuyển mạch OpenvSwitch
Hoạt động của hệ thống có thể đƣợc tóm tắt nhƣ sau: khi mới kết nối, bộ điều khiển và hệ thống chuyển mạch sẽ trao đổi bản tin Hello với nhau (xem Hình 3.10) để thiết lập kết nối đàm phán phiên bản. Nếu đàm phán thất bại chúng sẽ gửi bản tin Error. Sau khi thiết lập kết nối xong, bộ điều khiển sẽ gửi bản tin Feature_Request để xác định đặc tính và chức năng của OVS. OVS sẽ trả lời bằng bản tin Feature_Respond. Tiếp theo bộ điều khiển gửi bản tin Multipath Request để truy vấn thông tin theo từng luồng dữ liệu (port, interface, …). OVS trả lời bằng Multipath_Respond chứa các thông tin trên. Tiếp đến bộ điều khiển gửi bản tin Flow_Mod (nhƣ trình bày trên Hình 3.11) khi muốn thay đổi trạng thái của OVS.
Khi các bản tin cơ bản đƣợc trao đổi xong thì 2 thiết bị sẽ trao đổi bản tin Echo để trao đổi thông tin về độ trễ, băng thông và tính linh hoạt. Bản tin Packet_In và Packet_Out dùng để trao đổi dữ liệu.
Hình 3.11Bản tin Openflow OFPT_FLOW_MOD
Trong kịch bản này đã thực hiện khảo sát tốc độ tối đa của cổng Ethernet trên hệ thống chuyển mạch đƣợc thiết kế. Để thực hiện điều này, chúng ta có thể sử
dụng cả 2 cách là: 1 là đo kiểm bằng lệnh hiển thị cấu hình (ovs-ofctrl show) và 2 là
tạo lƣu lƣợng tăng dần và truyền qua hệ thống chuyển mạch.
Để xác thực khả năng hoạt động của hệ thống, lƣu lƣợng ngẫu nhiên theo các tốc độ tăng dần đƣợc tạo ra và truyền qua các luồng dữ liệu đƣợc thiết lập QoS khác nhau của hệ thống chuyển mạch. Trong kịch bản này, lƣu lƣợng tại cổng 9000 đƣợc yêu cầu truyền với tốc độ tối đa của liên kết là 4 Mbps. Lƣu lƣợng trên cổng 9001 truyền với tốc độ cố định là 2 Mbps trong khi tốc độ truyền trên cổng 9002 đƣợc tăng dần sau mỗi khoảng thời gian 30 giây. Lƣu lƣợng trên hai cổng 9001 và 9002 đƣợc khởi phát bắt đầu chậm 30 giây so với lƣu lƣợng trên cổng 9000. Kết quả cho thấy, lƣu lƣợng trên cổng 9000 bị giảm dần nhƣờng lại bang thông cho các cổng có đƣợc thiết lập QoS. Tổng lƣu lƣợng trên cả 3 cổng luôn đảm bảo là khoảng 10 Mbps (bằng tốc độ tối đa cho phép). Hai cổng 9001 và 9002 có tốc độ lƣu lƣợng theo đúng yêu cầu QoS đƣợc thiết lập.
Để xác định khả năng hoạt động của hệ thống, ta tạo luồng lƣu lƣợng ngẫu nhiên tăng dần và truyền qua các cổng đƣợc thiết lập QoS khác nhau của hệ thống chuyển mạch. Sử dụng phần mềm iperf, đây là một công cụ đơn giản dễ sử dụng để kiểm tra băng thông qua hệ thống mạng, bắn lƣu lƣợng qua các cổng với một host đóng vai trò làm máy chủ và một host đóng vai trò là máy khách.
của hệ thống chuyển mạch Openflow. Kết quả cho thấy đối với cổng 9000 và 9002, do lƣu lƣợng không giám sát hoặc chỉ giới hạn tốc độ tối thiểu, tốc độ lƣu lƣợng đầu ra của cổng vẫn nhƣ tốc độ truyền vào hệ thống. Tuy nhiên, đối với cổng 9001, do tốc độ bị giới hạn cố định là 2 Mbps, nên khi truyền dữ liệu có tốc độ cao thì đều bị giới hạn không lớn hơn 2 Mbps. Khi tốc độ quá cao, ví dụ từ 4 Mbps tại giây thứ 100 thì cổng bị ngắt kết nối do tỉ lệ mất gói quá lớn.
Hình 3.12 Băng thông qua cổng 9000
Hình 3.14 Băng thông qua cổng 9002
Hình 3.15 Kịch bản đảm bảo QoS cho các cổng theo cấu hình thiết lập trƣớc
Ngoài ra, hình 3.15 thể hiện kịch bản đảm bảo QoS cho lƣu lƣợng tại các cổng của hệ thống chuyển mạch theo cấu hình đã thiết lập. Trong kịch bản này, lƣu lƣợng tại cổng 9000 đƣợc yêu cầu truyền với tốc độ tối đa của liên kết là 10 Mbps. Lƣu lƣợng trên cổng 9001 truyền với tốc độ cố định là 2 Mbps trong khi tốc độ truyền trên cổng 9002 đƣợc tăng dần sau mỗi khoảng thời gian nhất định. Lƣu
lƣợng trên hai cổng 9001 và 9002 đƣợc khởi phát bắt đầu chậm 30 giây so với lƣu lƣợng trên cổng 9000. Kết quả cho thấy, lƣu lƣợng trên cổng 9000 bị giảm dần để ƣu tiên cho các cổng có QoS đƣợc thiết lập. Tổng lƣu lƣợng trên cả 3 cổng luôn đảm bảo là khoảng 10 Mbps (bằng tốc độ tổng cho phép). Hai cổng 9001 và 9002 có tốc độ lƣu lƣợng theo đúng yêu cầu QoS đƣợc thiết lập.
3.4 Kết luận chƣơng
Nội dung chƣơng 3 trình bày triển khai mô phỏng kỹ thuật đảm bảo QoS trong hệ thống mạng SDN-IoT sử dụng công cụ mô phỏng mininet và bộ điều khiển SDN Ryu. Các mô phỏng đƣợc triển khai cho ba loại hình chất lƣợng dịch vụ cơ bản là best-effort, tốc độ cố định và tốc độ cao. Các kết quả đạt đƣợc thể hiện khả năng đảm bảo chất lƣợng dịch vụ linh hoạt của hệ thống dựa trên nền tảng công nghệ mạng định nghĩa bằng phần mềm.
KẾT LUẬN
Trong thời đại bùng nổ công nghệ thông tin, IoT đã và đang phát triển ngày càng mạnh về số lƣợng thiết bị kết nối, số lƣợng kết nối và loại hình kết nối,… Qua đó đòi hỏi yêu cầu càng cao của chất lƣợng các kết nối nhƣ về băng thông, độ trễ và các tham số khác. Do đó các giải pháp và công nghệ mạng đang hƣớng đến việc giải quyết các thách thức trên nhằm hỗ trợ số lƣợng kết nối lớn cũng nhƣ thiết bị và sự đa dạng của chủng loại thiết bị kết nối.Việc xây dựng các giải pháp để đảm bảo chất lƣợng mà không ảnh hƣởng tới các luồng dữ liệu khác trên mạng ngày càng thực sự cần thiết.
Trong luận văn này, học viên đã thực hiện nghiên cứu khái quát về công nghệ IoT và công nghệ mạng định nghĩa bằng phần mềm cũng nhƣ khả năng ứng dụng của SDN trong IoT (IoT định nghĩa bằng phần mềm). Nội dung luận văn đã tập trung khảo sát các giải pháp đảm bảo chất lƣợng dịch vụ (QoS) trong mạng IP và trong mạng IoT định nghĩa bằng phần mềm. Trên cơ sở đó, luận văn cũng trình bày triển khai mô phỏng ứng dụng giải pháp đảm bảo QoS trong mạng IoT định nghĩa bằng phần mềm và đánh giá hiệu năng của hệ thống. Việc đánh giá hiệu năng của giải pháp đảm bảo chất lƣợng dịch vụ đƣợc thực hiện theo ba loại hình dịch vụ cơ bản tiêu biểu bao gồm dịch vụ lƣu lƣợng Best-effort (dịch vụ truyền thống của mạng IP), dịch vụ tốc độ không đổi và dịch vụ lƣu lƣợng tốc độ cao. Các kết quả đạt đƣợc cho thấy sự thành công của giải pháp DiffServ trong hạ tầng mạng SDN- IoT.
Trên cơ sở các kết quả đã đạt đƣợc trong nội dung luận văn này, một trong các hƣớng phát triển nghiên cứu tiếp theo của đề tài luận văn là nghiên cứu triển khai ứng dụng công nghệ IoT định nghĩa bằng phần mềm và kỹ thuật đảm bảo QoS trong thực tế mạng lƣới của VNPT Bắc Ninh trong tƣơng lai gần nhằm cung cấp các giải pháp cho hạ tầng truyền thông thành phố thông minh.
TÀI LIỆU THAM KHẢO
[1]Vermesan Ovidiu, and Peter Friess (2014) “Internet of things-from research and
innovation to market deployment,” Vol. 29, Aalborg: River Publishers.
[2]Alasdair Gilchrist(2016), “Industry 4.0: The Industrial Internet of Things”.
[3]Wollschlaeger Martin, Thilo Sauter, and Juergen Jasperneite (2017), “The future
of industrial communication: Automation networks in the era of the internet of things and industry 4.0,” IEEE Industrial Electronics Magazine, vol. 11, no. 1, pp. 17-27.
[4]Bizanis, Nikos, and Fernando A. Kuipers (2016), “SDN and virtualization
solutions for the Internet of Things: A survey,” IEEE Access, vol. 4, pp. 5591- 5606.
[5]Samaresh Bera, Sudip Misra, and Athanasios V. Vasilakos (2017), “Software-
DefinedNetworking for Internet of Things: A Survey,” IEEE Internet of Things
Journal, vol. 4, no. 6, pp. 1994-2008.
[6]Omnes, Nathalie, Marc Bouillon, Gael Fromentoux, and Olivier Le Grand
(2015), "A programmable and virtualized network & IT infrastructure for the
internet of things: How can NFV & SDN help for facing the upcoming challenges," 18th International Conference on Intelligence in Next Generation Networks (ICIN), pp. 64-69.
[7]Diego Kreutz, Fernando M.V. Ramos, Paulo Esteves Verıssimo, Christian
Esteve Rothenberg, Siamak Azodolmolky, and Steve Uhlig (2015), “Software-
defined networking: A comprehensive survey,” Proceedings of the IEEE, vol.
103, no. 1, pp. 14-76.
[8]Andreas, Arsanasty Ba, Martin Reisslein, and Wolfgang Kellerer (2016),
“Survey on network virtualization hypervisors for software defined
networking,” IEEE Communications Surveys & Tutorials, vol. 18, no. 1, pp. 655-685.
[9]Hu, Fei, Qi Hao, and Ke Bao (2014), "A survey on software-defined networkand openflow: From concept to implementation, " IEEE Communications Surveys
& Tutorials, vol. 16, no. 4, pp. 2181-2206.
[10] https://thenewstack.io/sdn-series-part-iv-ryu-a-rich-featured-open-source-sdn- controller-supported-by-ntt-labs