Giao thức OpenFlow

Chuẩn OpenFlow mô tả đ y là giao thức đƣợc sử dụng cho giao tiếp trên controlpath.

Các bộ chuyển mạch dùng giao thức này để báo hiệu sự tồn tại của chúng với khối điều khiển, và để chuyển tiếp các gói tin mà không tìm thấy sự so khớp trong bảng luồng tới bộ điều khiển để bộ điều khiển quyết định hành động nào sẽ đƣợc thực hiện. Khối điều khiển dùng giao thức này để tạo, biên tập, xóa các luồng trong bảng luồng chuyển mạch và tập hợp các thông tin thống kê từ bộ chuyển mạch.

Có 3 loại bản tin khác nhau:

 Bản tin bộ điều khiển – bộ chuyển mạch (Controller-To-Switch)

 Bản tin không đồng bộ (Asynchronous)

 Bản tin đối xứng (Symmetric)

3.3.1 Các ản tin Controller-To-Switch

Các bản tin này đƣợc khởi tạo bởi khối điều khiển và đƣợc gửi tới bộ chuyển mạch. Chúng có thể không nhất thiết phải yêu cầu một bản tin trả lời từ bộ chuyển mạch. Có các loại bản tin sau:

 Features: Khi một bộ chuyển mạch kết nối tới khối điều khiển, khối điều

khiển truy vấn các đ c tính của nó. Bộ chuyển mạch trả lời với bản tin Features Reply và liệt kê các khả năng của nó, ví dụ nhƣ các cổng nó đề xuất.

 Configuration: thiết lập và truy vấn các tham số cấu hình của một bộ chuyển

mạch. Bộ chuyển mạch chỉ trả lời khi đƣợc hỏi.

 Modify-State: Thêm ho c xóa các luồng trong bảng luồng của bộ chuyển

mạch ho c thiết lập các thuộc tính của cổng.

 Read-State: Khối điều khiển hỏi các giá trị thống kê từ bảng luồng các bộ

chuyển mạch. Bộ chuyển mạch trả lời với các giá trị tƣơng ứng.

 Send-Packet: Một gói tin đƣợc đóng gói trong ản tin này đƣợc gửi ra ngoài

52

 Barrier: Khối điều khiển có thể gửi một bản tin Barrier Request để bảo đảm

các bản tin đƣợc gửi trƣớc khi yêu cầu này đƣợc thực thi bởi bộ chuyển mạch trƣớc khi các bản tin mới đến sau khi bản tin Barrier Request đến. Bộ chuyển mạch gửi bản tin Barrier Relay khi thực thi thành công các bản tin.

3.3.2 Các ản tin không đồng ộ

Các bản tin này đƣợc gửi từ bộ chuyển mạch tới khối điều khiển để thông báo các sự cố. Có các loại bản tin sau:

 Packet-In: Nếu một gói tin nhận đƣợc trên một cổng bộ chuyển mạch và

không có chỉ mục trong bảng luồng, bộ chuyển mạch sẽ đóng gói gói tin và gửi nó tới khối điều khiển để kiểm tra thêm. Nếu bộ chuyển mạch có khả năng lƣu trữ tạm, chỉ một phần của gói tin (m c định 128 bytes) sẽ đƣợc gửi tới khối điều khiển. Hành động chuyển tiếp gói tin tới Controller cũng sẽ tạo ra một bản tin Packet-In.

 Flow-Remove: Các chỉ mục trong bảng luồng đƣợc thêm với các giá trị

thời gian timeout và idle sau khi ch ng đƣợc tự động xóa bỏ. Các sự kiện này đƣợc thông báo tới khối điều khiển bởi các bản tin Flow-Remove.

 Port-Status: Khi các cổng của một bộ chuyển mạch thay đổi trạng thái,

các bản tin Port-Status đƣợc gửi từ bộ chuyển mạch tới khối điều khiển để thông báo.

 Error: Tạo ra khi có lỗi xuất hiện trên bộ chuyển mạch, và khối điều

khiển đƣợc thông báo nhờ bản tin này.

3.3.3 Các ản tin đối xứng

Các bản tin đối xứng đƣợc trao đổi giữa khối điều khiển và bộ chuyển mạch theo cả hai chiều. Có các loại bản tin sau:

 Hello: Khi có một kết nối đƣợc thiết lập giữa bộ chuyển mạch và khối

điều khiển, các bản tin Hello đƣợc trao đổi.

 Echo: Để đo lƣờng sức sống, độ trễ, ăng thông các yêu cầu phản hồi và

53

 Vendor: Giao thức OpenFlow có thể đƣợc mở rộng bởi các nhà sản xuất

gọi là Vendor-Extensions. Bộ chuyển mạch và khối điều khiển có thể thông áo để chúng hiểu những sự mở rộng này bởi tên của chúng thông qua các bản tin Vendor.

3.4 Khối điều khiển OpenFlow và NOX

Khối điều khiển OpenFlow là thành phần trung tâm trong mạng OpenFlow,

thực hiện các quyết định các gói tin khác nhau sẽ đƣợc xử lý nhƣ thế nào. OpenFlow là một chuẩn mở, vì vậy ngày càng có nhiều sự triển khai phần mềm khác nhau đối với khối điều khiển. Tuy nhiên NOX là một trong số các nền tảng khối điều khiển tiên tiến và nổi bật nhất đã đƣợc triển khai.

NOX đƣợc phát triển bởi trƣờng đại học Stanford. Mục đích an đầu là để trở thành một “Hệ điều hành mạng”. Các quyết định liên quan đến luồng đƣợc thực hiện một cách tập trung. OpenFlow là công nghệ đƣợc sử dụng để điểu khiển các bộ chuyển mạch. NOX đƣợc xây dựng bằng C++ và Python , và đƣợc thiết kế theo cách nó có thể dễ dàng mở rộng bằng cách gọi thêm các thành phần. Nó đƣa ra một API mức cao phức tạp cho các chức năng mạng, và cho các bộ chuyển mạch ứng dụng OpenFlow. Các thành phần của NOX có thể đƣợc viết trong C++ và trong Python, tuy nhiên API Python là phát triển hơn. NOX đƣợc sử dụng thông dụng nhất trong khối điều khiển của OpenFlow. Nó có số lƣợng ngƣời dùng lớn, nhiều tài liệu, và đƣợc phát triển liên tục. Python API làm cho dễ dàng phát triển các thành phần.

3.5 Các ộ chuyển mạch

Sự phát triển của OpenFlow cho phép các bộ chuyển mạch mở ra các bộ chuyển mạch mềm, có thể đƣợc sử dụng cho các mạng máy tính thông thƣờng bởi các giao diện mạng là các cổng của các bộ chuyển mạch. Do chuẩn OpenFlow đang trở nên ổn định, một số nhà sản xuất bắt đầu tích hợp công nghệ OpenFlow vào phần sụn hệ thống của các bộ chuyển mạch phần cứng thƣơng mại. Ví dụ nhƣ các sản phẩm của Hewlett Packard, IBM đã hỗ trợ công nghệ OpenFlow.

54

3.6 Hệ điều hành mạng NOX 3.6.1 T ng quan về NOX 3.6.1 T ng quan về NOX

NOX là nền tảng của khối điều khiển OpenFlow có đầy đủ tính năng và có thể mở rộng. Nó đƣợc phát triên bởi Nicira Network Inc, vai trò nhƣ một API cho các dự án nội bộ của họ. Mã nguồn của NOX đƣợc công khai năm 2008, đƣợc đánh bản quyền dƣới GPLv3. NOX đƣợc phân phối trực tiếp từ một kho lƣu trữ từ trang web của nó tại http://www.noxrepo.org.

NOX đƣợc phát triển với mô hình lập trình tập trung, nghĩa là nó có khả năng điều khiển hoàn toàn một mạng bằng cách lập trình cho khối điều khiển trung tâm- gọi là NOX. Nó dùng chuẩn OpenFlow để điều khiển các bộ chuyển mạch trong mạng. Nó đƣợc phát triển trong C++ và Python dùng Simplied Wrapper và Interface Generator SWIG để tạo ra các giao diện giữa hai ngôn ngữ này. NOX đƣợc thiết kế thực hiện các chức năng có thể dễ dàng mở rộng. NOX gồm các thành phần thực hiện các chức năng mong muốn, các thành phần này sẽ đƣợc kích hoạt khi NOX khởi tạo. NOX nhìn các mạng nhƣ một tập hợp các luồng. Mỗi luồng là một chuỗi các gói tin đƣợc xác định bởi một số các thuộc tính, ví dụ địa chỉ IP/ MAC nguồn ho c đích và các số cổng. Việc thực hiện quyết định dựa trên cơ sở cho mỗi gói tin rõ ràng sẽ không khả thi cho mạng lớn, gây tốn kém tài nguyên các bộ chuyển mạch.

Các thử nghiệm cho thấy mỗi khối điều khiển có thể xử lý tới 100.000 luồng mỗi gi y. Điều này còn phụ thuộc vào sự lập trình của các thành phần xử lý luồng và các việc nó phải xử lý.

Các bộ chuyển mạch đƣợc nhận dạng bằng các datapath ID (dpid), là các giá trị hệ 16 gồm 48 bit, và chúng là duy nhất trong mạng OpenFlow.

3.6.2 Kiến tr c của NOX

NOX gồm các thành phần cơ ản sau: Khối lõi NOX, các thƣ viện, bộ sắp lịch sự kiện, và một vài thành phần khác. Khối lõi, các thƣ viện và bộ lập lịch sự

55

kiện xây dựng nên một nền tảng gồm các thành phần thực thi các chức năng khác nhau nhƣ mô tả trong hình sau. Lập trình NOX là công việc viết các thành phần.

Khối lõi NOX là thành phần cơ ản nhất trong kiến tr c NOX. Nó điều khiển các kết nối và điều phối các thực thể, thực thi các thành phần khác nhau. Nó thực hiện việc trả lời các bản tin OpenFlow do các bộ chuyển mạch gửi đến, tạo ra các sự kiện thông qua phân hệ sự kiện NOX khi cần. Các khối lõi NOX quản lý các kết nối controlpath cho từng bộ chuyển mạch OpenFlow có kết nối với nó. NOX cũng cung cấp các thƣ viện cho các thành phần khác sử dụng. Ví dụ một giao diện kết nối mạng thực hiện các chức năng nhƣ tạo ra, biên dịch, phân tích các loại gói tin khác nhau. Sự tƣơng tác với các thiết bị chuyển mạch OpenFlow đƣợc tách ra trong các thƣ viện, và có thể đƣợc sử dụng bên trong một thành phần khác. Ví nhƣ các luồng có thể đƣợc tạo ra, xóa bỏ, ho c các gói tin có thể đƣợc gửi ra ngoài một cổng của bộ chuyển mạch bằng cách sử dụng các chức năng cung cấp bởi các thƣ viện.

56

Sau khi các bản tin OpenFlow đến, phân hệ Event NOX đƣợc kích hoạt bởi khối lõi NOX để gửi một sự kiện tới từng thành phần đăng ký. Các mũi tên trong hình vẽ minh họa các đƣờng truyền thông tin trong NOX. Các thành phần có thể truyền thông tin với các thành phần khác dùng các sự kiện ho c gọi các hàm một cách trực tiếp bằng cách bao gồm và sử dụng các hàm của các thƣ viện.

3.6.3 Các thành phần

Các thành phần là những sự trìu tƣợng hóa trong NOX chứa đựng các logic thực tế. Mỗi thành phần có một chức năng cụ thể. Trong NOX, có 3 loại thành phần đƣợc phân biệt:

 Coreapps: đ y là các thành phần cơ ản, ví dụ nhƣ Messenger, SNMP, một

số thành phần thử nghiệm và các ví dụ.

 Netapps: là các thành phần cung cấp dịch vụ mạng, ví nhƣ Routing,

Authenticator, Spanning-tree, Monitoring, Topology, Discovery và nhiều thành phần khác.

 Webapps: NOX webserver là một thành phần loại này. Cũng có một thành

phần webservice, và một we serviceclient cơ ản để minh họa webserver và we service đƣợc sử dụng nhƣ thế nào. Mục đích của các thành phần này là để quản lý NOX thông qua các webservices.

Sự khác biệt này đƣợc thể hiện thông qua các thƣ mục khác nhau trong các mã nguồn. Mỗi thành phần lƣu trữ trong thƣ mục của riêng nó trong các danh mục chuẩn với bắt buộc là file meta.json. Đ y là file mang thông tin về thành phần, nhƣ tên của thành phần, những sự phụ thuộc của thành phần. Khai báo những sự phụ thuộc là cần thiết khi các thành phần phụ thuộc vào nhau. Ví dụ, thành phần topology tạo ra một hình vẽ về sơ đồ mạng. Nó phụ thuộc vào thành phần discovery, thành phần này tìm ra các kết nối trong mạng và tạo ra các sự kiện link_event.

57

Discovery

Thành phần này theo dõi các kết nối đang tồn tại trong mạng OpenFlow. Vì vậy giao thức khám phá lớp kết nối (Link Layer Discovery Protocol- LLDP) đƣợc sử dụng. Các khung LLDP chứa một số cấu trúc TLV (type-length-value). Những cấu trúc này chuyển thông tin về thiết bị nhận, ví dụ một loại TLV về ID của Chassis có một độ dài xác định và sẽ chuyển giá trị ID này.

Thành phần Discovery sử dụng các khung LLDP chứa TLV ID của Chassis mang datapath ID của bộ chuyển mạch, cổng ID TLV, chỉ rõ cổng ra của bộ chuyển mạch, và thời gian sống của TLV. Các khung LLDP đƣợc gửi ra từng cổng của bộ chuyển mạch. Khi một bộ chuyển mạch nhận đƣợc một khung LLDP trên một cổng, nó thông báo cho bộ điều khiển về gói tin vô danh bởi không có chỉ mục nào trong bảng luồng của bộ chuyển mạch. Khung đƣợc chuyển tới thành phần discovery bởi nó có chức năng xử lý và ph n tích gói tin đến. Nó sẽ cho biết thông tin về bộ chuyển mạch gửi, số cổng nội dung của khung LLDP, cổng nhận và cổng đến của bộ chuyển mạch, kết nối giữa các bộ chuyển mạch và các cổng đang tồn tại. Nó cũng giám sát các các kết nối đã iết thông qua việc định kỳ gửi ra các khung LLDP. Nếu một kết nối vô danh xuất hiện ho c một kết nối đang tồn tại bị mất, một sự kiện kết nối chứa các thông tin về kết nối đó đƣợc tạo ra để thông báo. Các thành phần khác có thể đăng ký các kết nối này và xây dựng cấu trúc mạng của riêng các thành phần đó dựa trên các thông tin đã xác định.

Điều quan trọng là không có các hub ho c các bộ chuyển mạch lớp 2 phi OpenFlow giữa các bộ chuyển mạch này, vì thế các gói tin LLDP sẽ đƣợc làm ngập toàn mạng và từng cổng đƣợc kết nối với nhau. Điều này là do thiếu một giao thức STP(Spanning Tree Protocol) đƣợc chuẩn hóa trong NOX và dẫn tới vòng l p trong mạng.

Cấu trúc liên kết (Topology)

Thành phần cấu trúc liên kết phụ thuộc vào thành phần Discovery. Nó duy trì trong đại diện bộ nhớ của cấu trúc liên kết mạng hiện tại bằng cách quan sát các sự kiện

58

gia nhập và rời datapath đƣợc tạo ra bởi nhân NOX và chỉ ra rằng một bộ chuyển mạch gia nhập ho c rời mạng bởi các sự kiện kết nối từ modun discovery.

Các phƣơng thức để truy vấn về trạng thái mạng hiện tại:

 get datapath(): lấy danh sách các bộ chuyển mạch đang hoạt động hiện tại,

bao gồm cả các giá trị datapath ID của các bộ chuyển mạch.

 get_neighbors (datapathIDsrc): lấy các bộ chuyển mạch láng giềng

trực tiếp từ các giá trị datapath ID đã cho.

 is_internal(datapathID, port): Hàm Boolean kiểm tra khi kết nối

từ cổng và bộ chuyển mạch kết nối với một bộ chuyển mạch khác trong mạng OpenFlow.

 get_outlinks(datapathIDsrc, datapathIDdst):Với datapathIDdst đã

cho, một danh sách các kết nối giữa 2 bộ chuyển mạch đƣợc trả về. Ngƣợc lại các kết nối từ datapath ID nguồn đƣợc trả về.

Cây mở rộng (Spanning Tree)

Modun này tạo ra một cây mở rộng cơ ản trong mạng OpenFlow. Nó không tƣơng thích với chuẩn STP đã chuẩn hóa là IEEE 802.1D. Khi một bộ chuyển mạch gia nhập mạng, thành phần cây mở rộng STP đ t giá trị bit NO FLOOD trên từng cổng của bộ chuyển mạch để ngăn ch n các gói tin đến đƣợc gửi tới các kết nối có thể dẫn tới một vòng l p trong mạng.

Cây mở rộng đƣợc tính toán nhƣ sau:

Datapath ID của từng cổng đang hoạt động của bộ chuyển mạch trong mạng đƣợc liệt kê một danh sách. Danh sách này đƣợc sắp xếp và bộ chuyển mạch có giá trị datapath ID nhỏ nhất trở thành gốc của cây mở rộng. Gốc sẽ đƣợc gỡ bỏ khỏi danh sách, mỗi kết nối hƣớng ra ngoài từ bộ chuyển mạch này sẽ đƣợc kiểm tra. Các giá trị datapath ID từ các bộ chuyển mạch có thể đến bằng 1 hop đƣợc chuyển tới m t trƣớc của danh sách và đƣợc sắp xếp, bit NO FLOOD trên các cổng tƣơng ứng đƣợc đ t về zero, vì vậy các kết nối đƣợc thêm vào cây mở rộng. Bộ chuyển mạch kế tiếp đƣợc lấy từ đầu danh sách ứng cử viên và xử lý theo cùng một cách.

59

Từ đó các ộ chuyển mạch đƣợc kết nối trực tiếp với nhau. Nếu một bộ chuyển mạch không cho phép tính năng OpenFlow nằm giữa các bộ chuyển mạch sẽ phá hủy chức năng của thành phần cây mở rộng.

Thành phần cây mở rộng là cần thiết trong mạng OpenFlow để ngăn ngừa vòng l p trong mạng. Nếu không các giao thức khác nhƣ ARP dựa trên bản tin quảng bá không thể làm việc hiệu quả.

Giám sát (Monitoring)

Thành phần giám sát lƣu giữ tất các các loại số liệu thống kê của bộ chuyển mạch. Nó có một giao diện API có thể đƣợc sử dụng để truy vấn số liệu thống kê. Tất cả

các thống kê đề cập trong phần trình bày về Flow table đƣợc định kỳ tập hợp bởi