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ậnphiê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.
Hình 4.7: Bản tin OFPT_FEATURES_ REQUEST
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ăngcủ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ếtlậ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.
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ônghợp lệ.
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.
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àychỉ đ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.
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).
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à
Hình 4.15: Bản tin OFPT_PACKET_IN
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
Ứ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.
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
đ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
• 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
5.4 Bộ điều khiển tập trung và phân tán
Một điểm quan trọng then chốt trong thiết kế kiến trúc là liệu một bộ điều khiển tập trung đơn lẻ hay bộ điều khiển phân tán sẽ được sử dụng để kiểm soát các switches trong mặt bằng dữ liệu.
Bộ điều khiển tập trung là một máy chủ duy nhất quản lý tất cả các switches trong mặt bằng dữ liệu trong mạng. Trong một mạng doanh nghiệp lớn, việc triển khai một bộ điều khiển duy nhất để quản lý tất cả các thiết bị mạng có thể dẫn đến khó sử dụng hoặc bất cập không mong muốn. Một kịch bản có khả năng hơn là nhà điều hành của một doanh nghiệp lớn hoặc mạng lưới các nhà cung cấp chia mạng lưới toàn bộ thành một số miền SDN không trùng lặp, còn được gọi là các “SDN islands” (Hình 3.9), được quản lý bởi các bộ điều khiển phân tán.
Hình 5.6: Cấu trúc miền SDN
Lý do sử dụng miền SDN bao gồm những điều sau:
- Khả năng mở rộng: Số lượng thiết bị mà bộ điều khiển SDN có thể quản lí được một cách khả thi là có giới hạn. Do đó, một mạng lớn phù hợp có thể cần phải triển khai nhiều bộ điều khiển SDN.
- Độ tin cậy: Việc sử dụng nhiều bộ điều khiển tránh rủi ro khi một bộ điều khiển duy nhất xảy ra lỗi.
- Riêng tư: Nhà cung cấp dịch vụ có thể chọn thực hiện các chính sách bảo mật khác nhau trong các miền SDN khác nhau. Ví dụ: một miền SDN có thể được dành riêng cho
một nhóm khách hàng thực hiện chính sách bảo mật tùy chỉnh cao của riêng họ, yêu cầu không được tiết lộ một số thông tin mạng trong miền này (ví dụ topo mạng) cho một thực thể bên ngoài.
- Triển khai gia tăng: Mạng của một hãng truyền thông công cộng có thể bao gồm các phần của cơ sở hạ tầng kế thừa và không kế thừa. Chia mạng thành nhiều miền SDN có thể quản lý riêng lẻ cho phép triển khai gia tăng linh hoạt. Bộ điều khiển phân tán có thể được sắp xếp trong một khu vực nhỏ, hoặc phân tán rộng rãi, hoặc kết hợp cả hai. Các bộ điều khiển được đặt chặt chẽ cung cấp lưu lượng cao và thích hợp cho các trung tâm dữ liệu, trong khi các bộ điều khiển phân tán thích hợp với các mạng lưới nhiều điểm. Thông thường, bộ điều khiển được phân bố theo chiều ngang. Tức là, mỗi bộ điều khiển sẽ điều khiển một tập hợp con không chồng chéo của các switches trong mặt bằng dữ liệu.Trong một kiến trúc phân tán, cần một giao thức để truyền thông giữa các bộ điều khiển. Về nguyên tắc, một giao thức độc quyền có thể được sử dụng cho mục đích này mặc dù một giao thức mở hoặc chuẩn sẽ rõ ràng là thích hợp hơn cho các mục đích tương tác. Các chức năng liên quan đến giao diện hướng Đông/hướng Tây cho một kiến trúc phân tán bao gồm việc duy trì cơ sở dữ liệu được phân chia và nhân rộng về topo và các tham số mạng, và các chức năng giám sát/thông báo. Chức năng thứ hai bao gồm việc kiểm tra xem bộ điều khiển có còn hoạt động hay không và điều phối các thay đổi trong việc chuyển đổi các bộ điều khiển sang bộ điều khiển.
5.5 Opendaylight SDNi
IETF đã phát triển một bản đặc tả kỹ thuật định nghĩa các yêu cầu chung để thiết lập luồng lưu lượng ngang hàng và trao đổi thông tin về khả năng tiếp cận qua nhiều tên miền, gọi là SDNi (SDNi: Một giao thức trao đổi bản tin cho các mạng định nghĩa phần mềm qua nhiều tên miền, draft-yin-sdn-sdni-00 .txt, ngày 27 tháng 6 năm 2012). Đặc tả SDNi (SDNi specification) không định nghĩa giao thức SDN ở hướng Đông/Tây mà cung cấp một số nguyên tắc cơ bản được sử dụng để phát triển một giao thức như vậy. Chức năng SDNi được định nghĩa trong đặc tả bao gồm những điều sau:
• Thiết lập luồng lưu lượng ngang hàng bắt nguồn từ các ứng dụng, chứa thông tin như yêu cầu truy cập, QoS và các mức dịch vụ phù hợp trên nhiều tên miền SDN.
• Trao đổi thông tin về khả năng tiếp cận để định tuyến giữa các miền SDN. Điều này sẽ cho phép một luồng đơn duy đi qua các miền SDNs và mỗi bộ điều khiển lựa chọn con đường thích hợp nhất trong số các đường dẫn khả dụng.
SDNi phụ thuộc vào các loại tài nguyên sẵn có và khả năng sẵn có được quản lý bởi các bộ điều khiển khác nhau trong mỗi miền. Do đó, điều quan trọng là phải thực hiện
các bộ điều khiển sẽ có tính linh động. Vì vậy cần có một số trao đổi siêu dữ liệu (metadata) cho phép SDNi trao đổi thông tin về các khả năng không xác định.Các loại thông điệp cho SDNi dự kiến bao gồm:
• Cập nhật khả năng tiếp cận.
• Thiết lập/cập nhật yêu cầu (bao gồm cả yêu cầu về khả năng ứng dụng như QoS, tốc độ dữ liệu, độ trễ...
• Cập nhật khả năng (bao gồm các tính năng liên quan đến mạng, chẳng hạn như tốc độ dữ liệu và QoS, và khả năng hệ thống và phần mềm có sẵn bên trong miền).
Chứa trong kiến trúc OpenDaylight là một khả năng SDNi để kết nối nhiều bộ điều khiển liên kết OpenDaylight trong mạng và chia sẻ thông tin topology trong số chúng . Khả năng này phù hợp với đặc tả IETF cho một chức năng SDNi. Ứng dụng SDNi có
thể triển khai trên bộ điều khiển OpenDaylight bao gồm ba thành phần.
• Trình kết hợp SDNi: Plug-in SDNi hướng Bắc hoạt động như một trình tổng hợp để thu thập thông tin mạng như topo, thống kê và định danh máy chủ lưu trữ.
• Plug-in này có thể phát triển để đáp ứng nhu cầu về dữ liệu mạng được yêu cầu chia sẻqua các bộ điều khiển SDN liên kết.
• SDNi REST API: API SDNi REST thu thập thông tin tổng hợp từ plug-in hướng Bắc (trình kết hợp SDNi).
• SDNi Wrapper: Wrapper SDNi BGP có trách nhiệm chia sẻ và thu thập thông