Quá trình khởi tạo kết nối
Hình 4.5: Quá trình khởi tạo kết nối
Phân tích :
NHÓM 2
Hình 4.6: Bản tin HELLO
Bản tin HELLO sẽ kiểm tra các thông số như port, ip, lenght dùng để thực hiện thỏa thuận phiên bản giao thức OpenFlow giữa 2 thiết bị. Trong bản tin này, vùng version là phiên bản cao nhất của giao thức OpenFlow mà bên gửi có thể hỗ trợ. Bên nhận bản tin Hello này sẽ so sánh vùng version này với phiên bản của nó và chọn phiên bản thấp hơn giữa 2 giá trị này. Vùng Transaction ID dùng nhận diện giao dịch có giá trị 1407246630.
NHÓM 2
Hình 4.7: Bản tin OFPT_FEATURES_ REQUEST
Hình 4.8: Bản tin OFPT_FEATURES_ REPLY
NHÓM 2
Sau thủ tục bắt tay tạo kết nối (dùng bản tin HELLO). Việc đầu tiên bộ điều khiển thực hiện là gởi một bản tin OFPT_FEATURES_REQUEST để lấy được
Datapath ID và các đặc tính của chuyển mạch. Chuyển mạch sẽ đáp ứng lại với một bản tin OFPT_FEATURES_ REPLY với vùng datapath_id = 2 và một số thông tin về khả năng của chuyển mạch: số lượng gói cực đại chuyển mạch có thể đệm khi gởi các gói tới bộ điều khiển dùng các bản tin packet_in là 256 (n-buffer), số lượng bảng chuyển mạch có thể hỗ trợ là 254 (n_tables), thông tin các cổng của chuyển mạch (of_port_desc list), các hoạt động chuyển mạch có thể hỗ trợ
(actions).
Hình 4.9: Bản tin OFPT_SET_CONFIG
Bản tin OFPT_SET_CONFIG do bộ điều khiển gởi đến chuyển mạch để thiết lập chế độ hoạt động của chuyển mạch. Type = 9 cho biết đây là bản tin
OFPT_SET_CONFIG.
Transaction ID: số nhận diện giao dịch 1148076647
(OFPT_FRAG_NORMAL): chỉ thị bộ chuyển mạch xử lý các phân đoạn của gói IP một cách bình thường, có nghĩa là nó nên cố gắng chuyển tiếp các phân đoạn này đi qua các bảng OpenFlow.
NHÓM 2
Miss_send_len = 128 là số lượng byte của mỗi gói mà đường ống OpenFlow gởi đến bộ điều khiển khi nó không sử dụng hoạt động xuất đến cổng luận lý của bộ điều khiển, ví dụ khi gởi một gói với giá trị TTL không hợp lệ.
Hình 4.10: Bản tin OF_ECHO_REQUEST
NHÓM 2
Hình 4.11: Bản tin OF_ECHO_REPLY
Hai bản tin này sẽ gửi liên tục OFPT_ECHO_REQUEST và
OFPT_ECHO_REPLY để đo lường độ trễ hoặc băng thông của kết nối chuyển mạch – điều khiển để kiểm tra xem thiết bị đang hoạt động không.
NHÓM 2
Hình 4.12: Bản tin OFPT_FLOW_MOD
Khi bộ điều khiển muốn sửa đổi thông tin bảng lưu lượng, nó sẽ gửi một bản tin sửa đổi mục nhập luồng thông báo (OFPT_FLOW_MOD) tới switch. Thông báo này chứa thông tin cần thiết để xác định và sửa đổi mục từ bảng lưu lượng.
Bản tin thay đổi luồng OFPT_FLOW_MOD với vùng command =0 có tác dụng điều chuyển mạch thêm một luồng mới. Cùng với vùng match cho thấy mục luồng này chỉ điều khiển chuyển tiếp lưu lượng đi từ port 3 đến port 1, với idle_timeout = 60 và hard_timeout = 0 thì luồng mới này sẽ hết hạn sau 60’ không có lưu lượng, với flags= 0 thì chuyển mạch phải gởi bản tin loại bỏ luồng về bộ điều khiển khi đến thời hạn idle-timeout (60’) hoặc luồng bị xóa, với buffer_id=260 thì chuyển mạch phải lấy gói tương ứng trong bản tin packet_in (có buffer_id=260) ra khỏi bộ đệm và xử lý nó đi qua toàn bộ đường ống OpenFlow sau khi luồng này được đưa vào bản luồng.
NHÓM 2
Các bản tin OpenFlow được tạo ra do các gói ping (chuyển dữ liệu)
Thực hiện ping từ host1 sang host 3
Mininet > h1 ping h3
Hình 4.13: Bản tin OFPT_PACKET_IN BROADCAST
OFPT_PACKET_IN: gửi từ bộ chuyển mạch (cổng TCP 59222) đến bộ điều khiển (cổng TCP 6653), lý do chuyển bản tin này đến bộ điều khiển và vì nó không so trùng với bất kỳ mục nào trong bảng luồng, cổng vào port 1, tổng chiều dài là 60 và vùng data chứa frame ethernet (đóng gói bản tin của giao thức ICMP - lệnh ping).
NHÓM 2
Hình 4.14: Bản tin OFPT_PACKET_OUT BROADCAST
OFPT_PACKET_OUT: gửi từ bộ điều khiển (6653) đến chuyển mạch (59222), danh sách action chỉ gồm một hoạt động xuất ra port 65531.
OFPT_ERROR: thông báo khi controller có lỗi
Ngoài ra còn có các bản tin khác như OFPT_PORT_STATUS và
OFPT_FLOW_REMOVED
NHÓM 2
Hình 4.15: Bản tin OFPT_PACKET_IN
Hình 4.16: Bản tin OFPT_PACKET_OUT
NHÓM 2
CHƯƠNG 5: TÌM HIỂU VÀ TRIỂN KHAI BỘ ĐIỀU KHIỂN OPENDAYLIGHT 5.1 Giới thiệu
OpenDayLight là phần mềm mã nguồn mở dành cho Software Defined Networking (SDN) sử dụng giao thức mở cung cấp khả năng kiểm soát tập trung, có khả năng lập trình được và theo dõi các thiết bị mạng. Giống như nhiều Bộ điều khiển SDNs khác, OpenDaylight hỗ trợ OpenFlow, cũng như cung cấp các giải pháp mạng khác sẵn sàng để cài đặt khi có yêu cầu. OpenDayLight cung cấp giao diện cho phép kết nối các thiết bị mạng nhanh chóng và thông minh để tối ưu hiệu năng mạng. OpenDayLight Controller cung cấp northbound APIs, được sử dụng bởi các ứng dụng. Các ứng dụng này sử dụng controller để thu thập thông tin về mạng, chạy các thuật toán để kiểm soát, phân tích, sau đó sử dụng OpenDayLight Controller tạo các rules mới cho mạng. OpenDayLight Controller viết bằng ngôn ngữ Java, có nghĩa là có thể sử dụng OpenDayLight Controller trên bất kì môi trường nào hỗ trợ Java. Tuy nhiên để đạt hiệu năng tốt nhất, OpenDayLight nên chạy trên môi trường Linux hỗ trợ JVM tối thiểu 1.7
5.2 Kiến trúc OpendayLight
Kiến trúc OpendayLight gồm 5 lớp logic
Hình 5.1: Các lớp logic
NHÓM 2
Ứng dụng mạng và dịch vụ: Bao gồm các ứng dụng mạng logic kiểm soát và giám sát hành vi mạng, và các ứng dụng thương mại. Các ứng dụng này sử dụng bộ điều khiển để thu thập thông tin mạng, chạy thuật toán để thực hiện phân tích và sau đó sử dụng bộ điều khiển để sắp xếp các quy tắc mới nếu.
Ví dụ: Dlux (OpendayLight user Experience), DdoS (Distributed Denial of Service) Protection, OpenStack Neutron, SDNI Wrapper, VTN (Virtual Tenant Network) Coordinator
- API: Một tập hợp các giao diện chung cho các chức năng điều khiển OpenDayLight. OpenDayLight hỗ trợ khung Open Service Gateway Initiative (OSGi) và REST hai chiều cho API hướng Bắc. Khung OSGi được sử dụng cho các ứng dụng sẽ chạy trong không gian địa chỉ giống như bộ điều khiển, trong khi API REST (dựa trên web) được sử dụng cho các ứng dụng không chạy trong cùng một không gian địa chỉ (hoặc thậm chí trên cùng một máy) với bộ điều khiển.
- Các chức năng và dịch vụ: Các chức năng và dịch vụ điều khiển SDN
Hình 5.2: Các Dịch Vụ
Chú thích:
DOCSIS Abstraction:Data over Cable Service Interface Specification Abstraction
AAA:Authentication , Authorization & Accounting
LISP service: Locator/Identifier Separation Protocol service
ALTO Protocol Manager: Application Layer Traffic Optimization Protocol Manager
- Lớp trừu tượng dịch vụ (SAL): Cung cấp một chế độ xem thống nhất các tài nguyên mặt bằng dữ liệu,để các chức năng điều khiển có thể được thực hiện độc lập với giao diện và giao thức hướng nam.
NHÓM 2
Hình 5.3: Lớp Service Abstraction
- Giao diện và giao thức Southbound: Hỗ trợ OpenFlow, các giao thức khác theo tiêu chuẩn Nam, và giao diện nhà cung cấp cụ thể.
Hình 5.4: Giao diện Southbound
Chú thích:
OVSDB:Open vSwitch Database Protocol BGP:Boder Gateway Protocol
PCEP:Path Computation Element Protocol
CAPWAP: Control and Provisioning of Wireless Access Points SXP:Source-Group Tag eXchange Protocol
SNMP:Simple Network Management Protocol USC:Unified Secure Channel
SNBI:Secure Network Bootstrapping infrastructure LACP:Link Aggregation Controll Protocol
PCMM:Packet Cable MultiMedia COPS:Common Open Policy Service
Có một số khía cạnh đáng lưu ý đối với kiến trúc OpenDaylight. Thứ nhất, OpenDaylight bao gồm cả mặt bằng điều khiển và chức năng mặt phẳng ứng dụng. Do đó, OpenDaylight không chỉ là một bộ điều khiển SDN. Điều này cho phép các nhà quản lý mạng doanh nghiệp và viễn thông lưu trữ phần mềm nguồn mở trên các máy chủ riêng của họ để xây dựng cấu hình SDN. Các nhà cung cấp có thể sử dụng phần mềm này để tạo ra các sản phẩm có thêm các chức năng và dịch vụ mặt phẳng ứng dụng bổ sung.
Một khía cạnh quan trọng thứ hai của thiết kế OpenDaylight là nó không gắn với OpenFlow hoặc bất kỳ giao diện hướng nam cụ thể nào khác. Điều này cung cấp tính linh hoạt cao hơn trong việc xây dựng cấu hình mạng SDN. Yếu tố then chốt trong thiết kế này là SAL cho phép bộ điều khiển hỗ trợ nhiều giao thức trên giao diện hướng Nam và cung cấp các dịch vụ thống nhất cho các chức năng bộ điều khiển và cho các ứng dụng SDN. Hình 3.8 minh họa hoạt động của SAL. Khung OSGi cung cấp liên kết động các plug-in cho các giao thức hướng nam có sẵn. Khả năng của các giao thức này được trừu tượng hóa thành một tập hợp các tính năng có thể được viện dẫn bằng các dịch vụ máy
NHÓM 2
điều khiển thông qua một trình quản lý dịch vụ trong SAL. Người quản lý dịch vụ duy trì một đăng ký để lập bản đồ các yêu cầu dịch vụ để yêu cầu tính năng. Dựa trên yêu cầu dịch vụ, SAL bản đồ cho các plug-in thích hợp và do đó sử dụng các giao thức hướng Nam thích hợp nhất để tương tác với một thiết bị mạng nhất định
Hình 5.5: Các Lớp Trừu Tượng
Một điểm mạnh trong OpenDaylight là bộ phần mềm được mô đun hóa và có tính linh hoạt cao. Tất cả các mã được thực hiện trong Java và được chứa trong Java Virtual Machine (JVM) của riêng nó. Như vậy, nó có thể được triển khai trên bất kỳ phần cứng và nền tảng hệ điều hành nào hỗ trợ Java.
5.3 REST
REpresentational State Transfer (REST) là một kiểu kiến trúc được sử dụng để xác định các APIs. REST đã trở thành một phương thức chuẩn để xây dựng API hướng Bắc cho bộ điều khiển SDN. Một API REST, hay một API được RESTful (tuân thủ các ràng buộc của REST) không phải là một giao thức, ngôn ngữ hoặc tiêu chuẩn đã được thiết lập. Có tất cả sáu yêu cầu cơ bản mà một API phải tuân theo để RESTful. Mục tiêu của những ràng buộc này là tối đa hóa khả năng mở rộng và độc lập/khả năng tương tác của các tương tác phần mềm và cung cấp một phương thức đơn giản để xây dựng các API.
REST giả định rằng các khái niệm về truy cập dựa trên web được sử dụng cho sự tương tác giữa ứng dụng và dịch vụ ở cả hai bên của API. REST không xác định các chi tiết cụ thể của API nhưng áp đặt các ràng buộc về bản chất của sự tương tác giữa ứng dụng và dịch vụ. Sáu yêu cầu REST bao gồm:
NHÓM 2
• Client-server
• Stateless
• Cache
• Giao diện thống nhất
• Hệ thống được phân lớp
• Mã hóa theo yêu cầu