Header Fields trong bảng luồng gồm các trƣờng mà gói tin đến đƣợc so sánh với:
- Cổng đến bộ chuyển mạch
- Địa chỉ nguồn và đích IEEE 802.3 Ethernet (MAC)
- Loại Ethernet IEEE 802.3
- VLAN ID và mức ƣu tiên IEEE 802.1Q
- Địa chỉ IP nguồn và đích
- Trƣờng IP proto
- IP Type Of Service (TOS) bits
- Các cổng TCP/UDP nguồn và đích.
Các gói tin có thể đƣợc đối chiếu với các trƣờng khác nhau qua mỗi lớp của mỗi gói tin từ lớp liên kết dữ liệu tới lơp giao vận cũng nhƣ trên cổng incoming bộ chuyển mạch. Giá trị đ c biệt ANY có thể đƣợc sử dụng để đối chiếu bất kỳ nội dung nào trong các trƣờng của 1 gói tin.
Cổng ảo (Virtual port) Mô tả
Yêu cầu chuẩn hóa
ALL Gửi gói tin ra ngoài mỗi giao diện trừ giao diện đã
nhận gói tin.
CONTROLLER Đóng gói gói tin và gửi nó tới khối điều khiển
dùng giao thức OpenFlow.
LOCAL Chuyển tiếp gói tin tới ngăn xếp mạng cục bộ nới
nó đƣợc xử lý thêm.
TABLE Thực hiện các hành động nhƣ mô tả trong bảng
luồng, chỉ với các bản tin Packet-out.
IN_PORT Gửi gói tin ra ngoài cổng nó đi vào.
49 NORMAL
Gửi gói tin tới đƣờng ống xử lý thông thƣờng của bộ chuyển mạch. Chủ yếu dành cho phần cứng của các bộ chuyển mạch hỗ trợ OpenFlow.
FLOOD
Gửi gói tin ra ngoài theo cây spanning tree nhỏ nhất. Các cổng OpenFlow cho phép các bộ chuyển mạch 1 bít NO_FLOOD, chỉ ra port không thuộc về cây spanning tree nhỏ nhất. Các gói so sánh với các chỉ mục có hoạt động này đƣợc gửi sau đó ra ngoài port của bộ chuyển mạch mà không thiết lập bit NO_FLOOD, không gồm port mà gói tin nhận đƣợc trên đó.
Bảng 3.1 Danh sách các cổng ảo cho các hoạt động chuyển tiếp được mô tả trong chuẩn OpenFlow
3.2.3 Các hoạt động thực hiện tr n luồng
Nếu một gói tin so khớp với một chỉ mục trong bảng luồng, không có ho c có nhiều hành động đƣợc thực hiện với gói tin. Chuẩn OpenFlow phân biệt giữa các hành động cần thiết mà một bộ chuyển mạch phải hỗ trợ và các hành động lựa chọn có ích nhƣng không nhất thiết phải hỗ trợ trong bộ chuyển mạch OpenFlow.
Một bộ chuyển mạch phải hỗ trợ việc chuyển tiếp các gói tin tới mỗi cổng vật lý. Ngoài ra còn có các cổng ảo đ c biệt nhƣ đã mô tả là các đích đến đ c biệt mà gói tin sẽ đƣợc chuyển tới nhƣ đề cập trong bảng trên.
Bên cạnh đó hành động DROP sẽ đƣợc thực hiện cho danh sách không có hành động nào. Các gói tin so khớp với môt chỉ mục trong bảng luồng mà có các hành động để trống sẽ bị hủy.
Hành động Enqueue đƣợc sử dụng cho đ t các gói tin trong hàng đợi mà gắn với một cổng và cung cấp cơ chế hỗ trợ QoS.
Hành động Modify-Field có thể đƣợc dùng để thay thế các thuộc tính của gói tin. Các thay đổi sau đối với một gói tin có thể thực hiện bởi hoạt động này:
- Thiết lập VLAN ID và mức ƣu tiên
- Bóc mào đầu VLAN
- Thay đổi địa chỉ MAC nguồn
- Thay đổi địa chỉ MAC đích
50
- Thay đổi địa chỉ IPv4 đích
- Thay đổi các bít IPv4 ToS
- Thay đổi cổng nguồn lớp giao vận
- Thay đổi cổng đích lớp giao vận
3.2.4 Thống k luồng
Chuẩn OpenFlow chuẩn hóa một số giá trị thông kê mà một bộ chuyển mạch phải cho biết. Các bộ đếm Counters đƣợc duy trì trên một số biến trên mỗi bảng, mỗi cổng, mỗi luồng và mỗi hàng đợi nhƣ trong ảng sau. Nếu giá trị bộ đếm không có trong bộ chuyển mạch, giá trị -1 sẽ đƣợc trả về.
51
3.3 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ộ