HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG

CƠ SỞ THÀNH PHỐ HỒ CHÍ MINH

-----------oOo----------

Bài giảng chuyên đề

SDN

Khoa Viễn Thông II

Giảng viên biên soạn : Nguyễn Xuân Khánh

- 01/2019-
 MỤC LỤC
DANH MỤC HÌNH VẼ ...........................................................................................................................ii

Phần 1 : OpenFlow ..............................................................................................................................1

1.1. Kiến trúc SDN ........................................................................................................................ 1

1.2. OpenFlow : ............................................................................................................................ 2

1.2.1. Kiến trúc chuyển mạch luận lý : ............................................................................................ 3

1.2.2. Các thành phần của Flow-Table ............................................................................................ 4

1.2.3. Đường ống Flow-Table .......................................................................................................... 7

1.3. Giao thức OpenFlow : ........................................................................................................... 8

1.3.1. Các bản tin Controller-to-Switch ......................................................................................... 10

1.3.2. Các bản tin Asynchronous ................................................................................................... 14

1.3.3. Các bản tin Symmetric ......................................................................................................... 16

Phần 2 : Giả lập SDN và phân tích OpenFlow .....................................................................................19

2.1 Mininet :.................................................................................................................................... 19

2.2 Tiến trình công việc trong Mininet : ......................................................................................... 20

2.2.1 Tạo một mạng ...................................................................................................................... 20

2.2.2 Tương tác với mạng : ........................................................................................................... 21

2.2.3 Tùy chỉnh mạng:................................................................................................................... 21

2.2.4 Chia sẽ một mạng : .............................................................................................................. 22

2.2.5 Chạy trên phần cứng:........................................................................................................... 22

2.3 Phân tích OpenFlow trên Mininet ............................................................................................ 23

2.3.1 Đồ hình mạng ....................................................................................................................... 23

2.3.2 Các bước thực hiện và phân tích : ....................................................................................... 23

TỪ VIẾT TẮC……………………………………………………………………………………………………….………31
TÀI LIỆU THAM KHẢO ...............................................................................................................31

i
 DANH MỤC HÌNH VẼ VÀ BẢNG

Hinh 1.1 Kiến trúc luận lý của SDN ……………………………………………….2

Hình 1.2 Chuyển mạch OpenFlow …………………………………………………3
Hình 1.3 Các thành phần của bảng luồng…………………………………………. 4
Hình 1.4 Luồng gói đi qua chuyển mạch tương thích OpenFlow ………….……...7
Hình 2.1 : Minh họa các thành phần và kết nối trong một mạng 2 host được
tạo ra bởi Mininet..................................................................................... 9
Hình 2-2 Đồ hình mạng gồm 1 switch và 4 host ………………………………….23
Hình 2-3 Dùng lệnh ping để kiểm tra tác động của các mục luồng......................... 26
Hình 2-4 Bản tin Hello ………………………………………………………….…26
Hình 2-5 Bản tin OFPT_FEATURE_REQUEST ………………………………....27
Hình 2-6 Bản tin OFPT_FEATURE_REPLY …………………………….……....27
Hình 2-7 Bản tin OFPT_SET_CONFIG …..……………………………………....28
Hình 2-8 Bản tin OFPT_PACKET_IN……………………………………..………29
Hình 2-9 Bản tin OFPT_PACKET_OUT ………………………………………….29
Hình 2-30 Bản tin OFPT_FLOW_MOD …………………………………………..30
Bảng 1.1 Các bản tin OpenFlow …………………………………………………….9

ii
Phần 1 : OpenFlow

Phần 1 : OpenFlow
1.1. Kiến trúc SDN

Hình 1.1 minh họa cấu trúc luận lý của một SDN, một bộ điểu khiển trung tâm thực
hiện tất cả các chức năng phức tạp, như định tuyến, đặt tên luồng, khai báo chính sách và
kiểm tra bảo mật. Bộ điều khiển này cấu thành mặt bằng điều khiển SDN, và bao gồm một
hoặc nhiều server SDN.

Bộ điều khiển SDN định nghĩa các luồng dữ liệu trong mặt bằng dữ liệu SDN. Mỗi
luồng qua mạng đầu tiên phải có được sự cho phép của bộ điều khiển còn bộ điểu khiển sẽ
thẩm tra chính sách mạng xem luồng thông tin này có được phép hay không . Nếu bộ điểu
khiển cho phép luồng này thì nó sẽ tính toán một tuyến đi cho luồng đi qua, và bổ sung một
mục thông tin cho luồng này trong mỗi chuyển mạch dọc theo đường đi mà luồng này đi qua.
Với tất cả các chức năng phức tạp do bộ điều khiển đảm trách, các chuyển mạch quản lý các
bảng luồng gồm các mục do bộ điều khiển ấn định. Thông tin giữa bộ điều khiển và các
chuyển mạch sử dụng một giao diện và giao thức được chuẩn hóa. Hầu như, giao diện và giao
thức thông dụng nhất là đặc tả OpenFlow.

Kiến trúc SDN có độ linh động đáng kế, nó có thể hoạt động với những loại chuyển
mạch khác nhau và với các lớp giao thức khác nhau. Các bộ điểu khiển SDN và các chuyển
mạch có thể thực hiện như các chuyển mạch Ethernet (lớp 2), các router Internet (lớp 3), các
chuyển mạch lớp transport (lớp 4), hoặc chuyển mạch và định tuyến lớp ứng dụng. SDN dựa
vào các chức năng chung trong các thiết bị kết nối mạng liên quan thiết yếu đến việc chuyển
tiếp các gói tin theo một vài dạng định nghĩa luồng.

Trong một kiến trúc SDN, một chuyển mạch thực hiện các chức năng sau :

 Chuyển mạch đóng gói và chuyển tiếp gói đầu tiên của một luồng tới một bộ điều
khiển SDN, cho phép bổ điều khiển quyết định xem luồng này có được bổ sung
vào bảng luồng của chuyển mạch hay không

 Chuyển mạch chuyển tiếp các gói đến đi ra cổng thích hợp dựa trên bảng luồng.
Bảng luồng này có thể bao gồm thông tin ưu tiên do bộ điều khiển ấn định

 Chuyển mạch có thể loại bỏ gói một cách tạm thời hoặc cố định của một luồng theo
lệng của bộ điều khiển. Sự loại bỏ gói có thể sử dụng cho mục đích an ninh, tấn
công từ chối dịch vụ hoặc do yêu cầu quản lý lưu lượng.

Bộ điều khiển SDN quản lý trạng thái chuyển tiếp của các chuyển mạch trong SDN.
Sự quản lý này được thực hiện qua một giao tiếp API không ảnh hưởng bởi các thiết bị của

1
Phần 1 : OpenFlow

các nhà cung cấp khác nhau và cho phép bộ điều khiển giải quyết nhiều loại yêu cầu khai
thác khác nhau mà không cần thay đổi những hoạt động cấp thấp của mạng và địa hình mạng

Hinh 1.1 Kiến trúc luận lý của SDN

Với sự tách biệt các mặt bằng dữ liệu và mặt bằng điều khiển, SDN cho phép các ứng
dụng thao tác một thiết bi mạng trừu tượng mà không cần quan tâm đến các chi tiết về sự
hoạt động của thiết bị. Như vậy, người quản lý mạng có khả năng tạo và triển khai một cách
nhanh chóng các ứng dụng mạng mới, bố trí lại các luồng lưu lượng mạng để đáp ứng những
yêu cầu cụ thể về hiệu năng và bảo mật.

1.2. OpenFlow :

Để đưa khái niệm SDN vào trong thực hiện thực tế, thì SDN phải đáp ứng 2 yêu cầu
quan trọng. Thứ nhất là phải có kiến trúc luận lý chung trong tất cả các chuyển mạch, các bộ
định tuyến và các thiết bị mạng khác được điểu khiển quản lý bởi một bộ điều khiển SDN.
Kiến trúc luận lý này có thể được thực hiện theo các cách khác nhau trên các thiết bị của các
nhà cung cấp khác nhau và trong các loại thiết bị mạng khác nhau, miễn sao bộ điều khiển

2
Phần 1 : OpenFlow

SDN nhìn thấy chúng là một chức năng chuyển mạch luận lý đồng nhất. Thứ hai là cần phải
có một thủ tục chuẩn, an toàn giữa bộ điều khiển SDN và thiết bị mạng.
Cả 2 yêu cầu này được giải quyết bởi OpenFlow. OpenFlow vừa là một giao thức
giữa bộ điều khiển SDN và các thiết bị mạng, vừa là một đặc tả về cấu trúc luận lý của những
chức năng chuyển mạch mạng. OpenFlow được định nghĩa trong đặc tả chuyển mạch
OpenFlow được công bố bởi ONF (Open Networking Foundation). ONF là một tổ chức gồm
các nhà cung cấp phần mềm, các mạng phân phối nội dung, và các nhà cung cấp thiết bị
mạng với cùng một mục đích là thúc đẩy SDN.
Đặc tả đầu tiên của OpenFow (phiên bản 1.0) là do đại học Stanford phát triển và
được sử dụng rộng rãi. OpenFlow 1.2 là phiên bản đầu tiên do ONF phát triển sau khi thừa
hưởng dự án OpenFlow từ Stanford. OpenFlow phiên bản 1.3 mở rộng đáng kể những chức
năng của đặc tả và trở thành một cơ sở vững chắc cho các thực hiện OpenFlow mang tính
thương mại trong tương lai. ONF dự kiến phiên bản này là một mục tiêu ổn định cho các nhà
cung cấp chip và phần mềm, vì thế nếu có sự thay đổi nào trong tương lai có thể dự đoán
trước cũng rất nhỏ.
Trước khi tiếp tục, chúng ta nên xác định từ luồng (Flow) có ý nghĩa là gì. Thuật ngữ
này không được định nghĩa trong đặc tả OpenFlow, và cũng không có trong tất cả các tài liệu
về OpenFlow. Trong những điều kiện thông thường, một luồng là một một chuỗi các gói có
cùng một tập các giá trị vùng mào đầu di chuyển qua một mạng. Cho ví dụ, một luồng có thể
bao gồm tất cả các gói với cùng các địa chỉ IP nguồn và đích, hoặc tất cả các gói có cùng giá
trị nhận diện VLAN

1.2.1. Kiến trúc chuyển mạch luận lý :

Hình 1.2 Chuyển mạch OpenFlow

3
Phần 1 : OpenFlow

Hình 1.2 minh họa cấu trúc cơ bản của môi trường OpenFlow. Một bộ điểu khiển
SDN truyển thông với các chuyển mạch tương thích OpenFlow sử dụng giao thức OpenFlow
chạy qua kết nối SSL (Secure Sockets Layer). Mỗi chuyển mạch kết nối tới các chuyển mạch
OpenFlow khác và có thể tới các thiết bị end-user nơi là các điểm xuất phát và đích đến của
các luồng gói. Bên trong mỗi chuyển mạch, mỗt chuỗi các bảng - thường được thực hiện
trong phẩn cứng hoặc phần dẽo – được sử dụng để quản lý các luồng gói đi qua chuyển mạch.
Đặc tả OpenFlow định nghĩa 3 loại bảng trong kiến trúc chuyển mạch luận lý. Một
bảng luồng dùng vùng Match để so trùng các gói đến với một luồng cụ thể và chỉ ra những
chức năng được thực hiện trên các gói này. Có thể có nhiều bảng luồng hoạt động theo một
kiểu đường ống. Một bảng luồng có thể định hướng một luồng tới một bảng nhóm, tại đây có
thể kich khởi một tập nhiều loại hoạt động ảnh hưởng đến một hoặc nhiều luồng. Một bảng
đo lường (Meter) có thể kích khởi một tập nhiều loại hoạt động liên quan đến hiệu năng trên
một luồng.
Một chuyển mạch trong kiến trúc SDN thực hiện các chức năng sau:

 Đóng gói và chuyển tiếp gói đầu tiên của một luồng tới một bộ điều khiển SDN,
cho phép bộ điều khiển này quyết định luồng này sẽ được bổ sung vào bảng luồng
hay không.
 Chuyển mạch dựa vào bảng luồng để chuyển tiếp các gói vào đi ra cổng đầu ra
thích hợp. Bảng luồng có thể bao gồm thông tin độ ưu tiên được bộ điều khiển sử
dụng để điều khiển độ ưu tiên của các luồng lưu lượng.
 Chuyển mạch có thể tạm thời hoặc thường trực loại bỏ các gói của một luồng cụ
thể do bộ điều khiển ra lệnh. Việc loại bỏ gói có thể được dùng cho mục đích an
toàn, hạn chế tấn công từ chối dịch vụ hoặc do các yêu cầu về quản lý lưu lượng.

1.2.2. Các thành phần của Flow-Table

Hình 1.3 Các thành phần của bảng luồng

Khối cơ bản của kiến trúc chuyển mạch luận lý là bảng luồng. Mỗi gói đi vào một
chuyển mạch sẽ đi qua một hoặc nhiều bảng luồng. Mỗi bảng luồng chứa nhiều mục bao gồm
6 thành phần :
 Match Fields : được dùng để chọn ra các gói phù hợp với các giá trị trong các vùng
này
 Priority : độ ưu tiên tương đối của các mục trong bảng luồng
 Counters : Cập nhật số lượng những gói phù hợp. Đặc tả OpenFlow định nghĩa
nhiều loại thống kê và định thời. Ví dụ số lượng các byte và các gói nhận được trên
một cổng, trên một bảng luồng, và trên một mục trong bảng luồng; số lượng các
gói bị loại bỏ, và thời khoản của một luồng.
 Instructions : Những hoạt động được thực hiện nếu có sự so trùng với vùng Match
Fields

4
Phần 1 : OpenFlow

 Timeouts : Thời lượng nhãn rỗi tối đa trước khi một luồng được chuyển mạch xem
như hết hiệu lực
 Cookie : Giá trị dữ liệu tùy theo tình huống và do bộ điều khiển chọn. Bộ điều
khiển có thể sử dụng giá trị này để lọc những giá trị thống kê luồng, thay đổi luồng,
và xóa luồng ; nó không được dùng khi đang xử lý các gói tin.
Một bảng luồng có thể có một mục luồng “bỏ qua bảng” (không dùng bảng). Mục này
có tất cả Match Fields có ký tự thay thế wildcard ( mọi vùng đều phù hợp bất chấp giá trị
nào) và có độ ưu tiên thấp nhất (độ ưu tiên 0). Thành phần Match Fields của một mục bảng
luồng có 2 loại : những vùng bắt buộc (các chuyển mạch tương thích OpenFlow phải hỗ trợ)
và những vùng tùy chọn. Những vùng bắt buộc gồm :
 Cổng vào : Giá trị nhận diện cổng đến trên chuyển mạch (nơi gói đi vào chuyển
mạch). Nó có thể là một cổng vật lý hoặc một cổng ảo được định nghĩa trên chuyển
mạch
 Địa chỉ Ethernet nguồn và đích : Mỗi mục có thể là một địa chỉ chính xác (đầy đủ),
một giá trị mặt nạ bit (chỉ một vài bit địa chỉ được kiểm tra), hoặc một giá trị
wildcard (phù hợp bất kỳ giá trị nào)
 Địa chỉ IPv4 or IPv6 nguồn và đích : Mỗi mục có thể là một địa chỉ chính xác, một
giá trị mặt nạ bit, một giá trị mặt nạ mạng con, hoặc một giá trị wildcard.
 Các cổng TCP nguồn và đích : Phù hợp chính xác hoặc giá trị wildcard
 Các cổng UDP nguồn và đích : Phù hợp chính xác hoặc giá trị wildcard
Các vùng tùy chọn (chuyển mạch OpenFlow có thể hỗ trợ hoặc không hỗ trợ) :
 Cổng vật lý : Vùng này được dùng để định rõ cổng vật lý nằm bên dưới khi gói
được nhận trên một cổng luận lý
 Metadata : Thông tin bổ sung có thể được chuyển từ một bảng này tới một bảng
khác trong khi xử lý một gói.
 Kiểu Ethernet : Vùng kiểu Ethernet
 Độ ưu tiên VLAN ID và VLAN USER : Các vùng trong mào đầu VLAN
IEEE802.1Q
 Vùng DS và ECN IPv4 or IPv6 : Các vùng dịch vụ phân biệt và thông báo tắc
nghẽn tường minh.
 Các cổng nguồn và đích SCTP (Stream Control Transmission Protocol) : Phù hợp
chính xác hoặc giá trị wildcard
 Các vùng Code và Type trong ICMP (Internet Control Message Protocol) : Phù
hợp chính xác hoặc giá trị wildcard.
 Opcode trong ARP (Address Resolution Protocol) : Phù hợp chính xác theo vùng
Ethernet Type
 Các địa chỉ IPv4 nguồn và đích trong payload ARP: Có thể là một địa chỉ chính
xác, một giá trị mặt nạ bit, một giá trị mặt nạ mạng con, hoặc một giá trị wildcard.
 Nhãn luồng IPv6 l : Phù hợp chính xác hoặc giá trị wildcard.
 Các vùng Code và Type ICMPv6: Phù hợp chính xác hoặc giá trị wildcard.

5
Phần 1 : OpenFlow

 Địa chỉ mục tiêu IPv6 trong giao thức khám phá láng giềng : Trong một bản tin
khám phá láng giềng IPv6.
 Địa chỉ IPv6 nguồn và mục tiêu trong giao thức khám phá láng giềng : Các tùy
chọn địa chỉ lớp liên kết trong một bản tin khám phá láng giềng IPv6.
 Giá trị nhãn, lớp lưu lượng và đáy của chồng nhãn trong MPLS (Multiprotocol
Label Switching) : Các vùng trong nhãn trên cùng của chồng nhãn MPLS
Như vậy, OpenFlow có thể được dùng với lưu lượng mạng gồm nhiều loại giao thức
và dịch vụ mạng. Một điểm cần lưu ý là ở lớp liên kết dữ liệu hoặc lớp truy xuất môi trường
truyền MAC , OpenFlow chỉ hỗ trợ Ethernet. Như vậy, hiện nay OpenFlow không thể điều
khiển lưu lượng lớp 2 qua các mạng không dây.
Đến đây chúng ta có thể định nghĩa chính xác thuật ngữ luồng (flow). Từ khía cạnh
của một chuyển mạch riêng biệt, một luồng là một chuỗi các gói thỏa mãn một mục cụ thể
trong một bảng luồng. Theo định nghĩa hướng gói này, luồng là một hàm các giá trị của các
vùng header của các gói cấu thành luồng, và nó không phụ thuộc vào con đường chúng đi qua
mạng. Tổ hợp các mục luồng trong nhiều chuyển mạch xác định một luồng được gán vào một
đường đi cụ thể qua mạng.
Thành phần instruction của một mục bảng luồng gồm một tập các lệnh được thực thi
nếu gói so trùng với mục này. Trước khi miêu tả các loại lệnh, chúng ta định nghĩa các thuật
ngữ “Action” và “Action Set”. Action miêu tả sự chuyển tiếp gói, thay đổi gói, và những hoạt
động xử lý bảng nhóm. Đặc tả OpenFlow gồm những hoạt động sau:
 Output : chuyển tiếp gói ra một cổng cụ thể
 Set-Queue : thiết lập nhận diện hàng đợi cho một gói. Khi gói được chuyển tiếp tới
một cổng sử dụng hoạt động Output, nhận diện hàng đợi xác định hàng đợi nào kết
hợp với cổng này được dùng cho hoạt động phân lịch và chuyển tiếp gói. Hoạt
động chuyển tiếp được thực hiện theo cấu hình hàng đợi và được dùng để cung cấp
điều khiển QoS cơ bản.
 Group : Xử lý gói theo nhóm cụ thể.
 Push-Tag/Pop-Tag : Đưa vào hoặc lấy ra một vùng tag trong một gói VLAN hoặc
MPLS
 Set-Field : Nhận diện các hoạt động thiết lập vùng khác nhau theo kiểu vùng của
chúng, chúng thay đổi giá trị các vùng header tương ứng trong gói.
 Change-TTL : Các hoạt động Change-TTL khác nhau thay đổi các giá trị của vùng
IPv4 TLL, IPv6 Hop Limit, hoặc MPLS TTL trong gói.
Action Set là một danh sách các hoạt động liên quan đến một gói được tích lũy trong
quá trình gói này được xử lý bởi mỗi bảng luồng và được thực thi khi gói đi ra khỏi đường
ống xử lý. Những lệnh này có 4 loại :
 Định hướng gói qua đường ống: Lệnh Goto-Table định hướng tới một bảng đứng
sau dọc theo đường ống. Lệnh Meter điều khiển gói chuyển đến một bộ đo lường
cụ thể (ví dụ thống kê gói truyền)
 Thực hiện action trên gói : Những hoạt động có thể được thực hiện trên gói khi nó
được so trùng với một mục bảng
6
Phần 1 : OpenFlow

 Cập nhật action set : hợp nhất những hoạt động cụ thể thành tập hoạt động hiện
hành cho gói này trên luồng này, hoặc xóa tất cả hoạt động trong tập hoạt động.
 Cập nhật metadata : Một giá trị siêu dữ liệu có thể được kết hợp với một gói. Nó
được dùng để mang thông tin từ một bảng luồng này đến một bảng luồng kế theo
1.2.3. Đường ống Flow-Table

Một chuyển mạch bao gồm một hoặc nhiều bảng luồng. Nếu có nhiều bảng luồng, thì
chúng được tồ chức thành một đường ống như trong hình 1.4 với các bảng được đánh nhãn
tăng dần bắt đầu từ 0

Hình 1.4 Luồng gói đi qua chuyển mạch tương thích OpenFlow

Khi một gói đến một bảng để thực hiện so trùng, đầu vào cho hoạt động này gồm gói,
nhận diện cổng đầu vào, giá trị siêu dữ liệu, và tập hoạt động kết hợp. Đối với bảng 0, giá trị
siêu dữ liệu là trống và tập hoạt động là vô hiệu. Tiến trình diễn tiến như sau :
1. Tìm ra mục luồng để thực hiện so trùng có độ ưu tiên cao nhất. Nếu không có sự
so trùng trên bất kỳ mục nào và không có mục table-miss (bỏ qua bảng này), thì
gói bị loại bỏ. Nếu chỉ có một sự so trùng trên mục table-miss, thì mục này chỉ ra
một trong 3 hoạt động sau :
a. Gởi gói tới bộ điều khiển. Hoạt động này cho phép bộ điểu khiển định nghĩa
một luồng mới cho gói này và những gói tương tự, hoặc quyết định loại bỏ
gói.
7
Phần 1 : OpenFlow

b. Đính hướng gói đến một bảng luồng khác theo hướng xuôi theo đường ống
c. Loại bỏ gói.
2. Nếu có sự so trùng trên một hoặc nhiều mục khác mục table-miss, thì sự so trung
được xác định theo mục so trùng có độ ưu tiên cao nhất. những hoạt động tiếp theo
sau có thể được thực hiện là :
a. Cập nhật bất kỳ bộ đếm nào kết hợp với mục này.
b. Thực thi bất kỳ lệnh nào kết hợp với mục này. Những lệnh này có thể bao gồm
cập nhật tập hoạt động, cập nhật giá trị siêu dữ liệu, và thực hiện các hoạt
động
c. Gói sau đó được chuyển đến một bảng luồng tiếp theo trong đường ống, tới
bảng nhóm, hoặc tới bảng đo lường, hoặc nó có thể được đính hướng tới một
cồng đầu ra
Đối với bảng cuối cùng trong đường ống, việc chuyển tiếp tới một bảng luồng khác
không được thực hiện và nếu một gói cuối cùng được đính hướng tới một cổng đầu ra, thì tập
hoạt động tích lũy được thực thi và sau đó gói được đưa vào hàng đợi đầu ra của cổng này.

1.3. Giao thức OpenFlow :

Giao thức OpenFlow miêu tả các trao đổi bản tin được thực hiện giữa một bộ điều
khiển OpenFlow và một chuyển mạch OpenFlow . Thông thường, giao thức này được thực
hiện qua kênh SSL (Secure Socket Layer) hoặc TLS (Transport Layer Security) nhằm mục
đích cung cấp một kết nối OpenFlow an toàn

Giao thức OpenFlow cho phép bộ điều khiển thực hiện thêm, cập nhật, và xóa các
hoạt động trên mục luồng của các bảng luồng. Nó hỗ trợ 3 kiểu bản tin được trình bày trong
bảng 1.1

 Controller-to-Switch: những bản tin này được khởi phát bởi bộ điều khiển và
trong một vài trường hợp nó yêu cầu một đáp ứng từ chuyển mạch. Lớp các bản
tin này cho phép bộ điều khiển quản lý trạng thái luận lý của chuyển mạch, bao
gồm cấu hình và các chi tiết của các mục bảng luồng hoặc bảng nhóm. Lớp này
cũng bao gồm bản tin Packet-out. Bản tin này được sử dụng khi một chuyển mạch
phát một gói tới bộ điều khiển và bộ điều khiển quyết định không loại bỏ gói này
nhưng định hướng nó tới một cồng đầu ra của chuyển mạch.

 Asynchronous : Những loại bản tin này được gởi đi mà không có sự yêu cầu từ bộ
điểu khiển. Lớp bản tin này bao gồm các bản tin trạng thái khác nhau gởi tới bộ
điều khiển. Nó cũng bao gồm bản tin Packet-in mà chuyển mạch có thể sử dụng
để gởi một gói tới bộ điểu khiển khi không có sự so trùng bảng luồng

 Symmetric : Những bản tin này được gởi mà không có sự yêu cầu từ bộ điều
khiển hoặc từ chuyển mạch. Các bản tin Hello thường được truyền tới lui giữa bộ
điều khiển và chuyển mạch khi kết nối được thiết lập lần đầu. Các bản tin Echo và
Reply có thể được sử dụng bởi bộ chuyển mạch hoặc bộ điều khiển để đo lường
8
Phần 1 : OpenFlow

độ trễ hoặc băng thông của kết nối chuyển mạch – điều khiển hoặc chỉ để kiểm tra
xem thiết bị đang hoạt động hay không. Các bản tin Experimenter để đưa các đặc
tính được xây dựng vào trong các phiên bản OpenFlow tương lai.

Bản tin Miêu tả

Controller-to-Switch
Features Yêu cầu các khả năng của một chuyển mạch. Chuyển mạch đáp
ứng cho biết các khả năng của nó
Configuration Thiết lập và chất vấn các thông số cấu hình. Chuyển mạch đáp lại
với các thiết lập cấu hình
Modify-State Thêm, xóa và thay đổi các mục luồng/nhóm và thiết lập các thuộc
tính của cổng chuyển mạch
Read-State Thu thập thông tin từ chuyển mạch, như cấu hình hiện hành, các
thống kê, và các khả năng
Packet –out Định hướng gói tới một cổng cụ thế trên chuyển mạch
Barrier Bộ điều khiển sử dụng các bản tin yêu cầu/ đáp ứng Barrier để
đảm bảo những phụ thuộc bản tin đã được đáp ứng hoặc để nhận
các thông báo về các hoạt động đã hoàn tất.
Role-Request Thiết lập hoặc chất vấn vai trò của kênh OpenFlow. Bản tin hữu
ích khi chuyển mạch kết nối tới nhiều bộ điểu khiển.
Asynchronous- Thiết lập bộ lọc các bản tin bất đồng bộ hoặc chất vấn bộ lọc đó.
Congfiguration Được dùng khi chuyển mạch kết nối tới nhiểu bộ điều khiển
Asynchronous
Packet-in Chuyển gói tới bộ điều khiển
Flow-Removed Báo cho bộ điều khiển về việc loại bỏ một mục luồng ra khỏi một
bản luồng
Port-Status Báo cho bộ điều khiển về một sự thay đổi trên một cổng.
Symmetric
Hello Được trao đổi qua lại giữa chuyển mạch và bộ điều khiển vào lúc
khởi động kết nối
Echo Các bản tin yêu cầu/ đáp ứng Echo được gởi đi từ chuyển mạch
hoặc bộ điểu khiển, và chúng phải đáp trả một hồi đáp Echo.
Error Thông báo cho bộ điều khiển hoặc chuyển mạch về trạng thái lỗi
hoặc sự cố
Experimenter Dùng cho các chức năng bổ sung

Bảng 1.1 Các bản tin OpenFlow

9
Phần 1 : OpenFlow

1.3.1. Các bản tin Controller-to-Switch

 Bản tin feature OFPT_FEATURE_REQUEST được bộ điều khiển sử dụng để nhận

diện ra chuyển mạch và đọc các khả năng cơ bản của nó. Vào lúc thiết lập phiên, bộ điều
khiển sẽ gởi bản tin này tới chuyển mạch và bộ chuyển mạch phải đáp ứng lại bản tin
OFPT_FEATURE_REPLY.

struct ofp_switch_features {
struct ofp_header header;
unit64_t datapath_id ; /*nhận diệndatapath. 64 bit thấp là địa chỉ MAC, 16
bit được định nghĩa tuy theo việc thực hiện */
unit32_t nbuffers; /* số lượng gói tối đa được đệm đồng thời */
unit8_t n_tables; /* số lượng bảng được hỗ trợ bởi datapath */
unit8_t auxiliary_id; /* nhận diện các kết nối phụ */
unit8_t pad[2]; /* đệm thêm để chẳn 64 bit */
/* các đặc tính */
Unit32_t capabilities; /* các khả năng hỗ trợ của switch */
Unit32_t reserved;
};
OFP_ASSERT (sizeof (struct ofp_switch_features) == 32)

Vùng datapath_id nhận diện duy nhất một datapath. 48 bit thấp dành cho địa chỉ cấp
MAC của switch, 16 bit bit cao tùy thuộc vào sự thực hiện. Ví dụ : 16 bit cao là một VLAN
ID dùng phân biệt nhiều chuyển mạch ảo trên một chuyển mạch vật lý đơn.
Vùng n_buffers chỉ ra số lượng gói cực đại chuyển mạch có thể đệm khi nó đang gởi
các gói đến bộ điều khiển dùng các bản tin packet_in
Vùng n_tables miêu tả số lượng bảng chuyển mạch có thể hỗ trợ, mỗi bảng có thể có
một tập khác nhau các vùng so trùng được hỗ trợ, các hoạt động và số lượng các mục. Khi bộ
điều khiển và chuyển mạch thông tin với nhau lần đầu tiên, bộ điều khiển sẽ tìm ra chuyên
mạch hỗ trợ bao nhiêu bảng thông qua bản tin đáp ứng cho bản tin này.
Vùng auxiliary_id nhận diện loại kết nối từ chuyển mạch đến bộ điều khiển, đối với
kết nối chính vùng này bằng không, đối với kết nối phụ vùng này mang giá trị khác không.
Vùng khả năng sử dụng một tập các cờ sau :
enum ofp_capabilities {
OFPC_FLOW_STATS = 1 << 0, /* các thống kê luồng*/
OFPC_TABLE_STATS = 1 << 1, /* các thống kê bảng*/
OFPC_PORT_STATS = 1 << 2, /* các thống kê cổng*/
OFPC_GROUP_STATS = 1 << 3, /* các thống kê luồng*/
OFPC_IP_REASM = 1 << 5, /* có thể tập hợp lại các đoạn IP*/
OFPC_QUEUE_STATS = 1 << 6, /* các thông kê hàng đợi*/
OFPC_PORT_BLOCKED = 1 << 8, /* chuyển mạch sẽ chặn các port đang lặp vòng*/
};

10
Phần 1 : OpenFlow

Bit OFPC_PORT_BLOCKED cho biết một giao thức khác OpenFlow, ví dụ 802.1D
Spanning Tree, sẽ nhận ra lặp vòng và chặn các port để tránh các gói lặp vòng. Nếu bit này
không thiết lập, thì trong hầu hết các trường hợp bộ điều khiển sẽ thực hiện một cơ chế tránh
gói lặp vòng
 Bản tin cấu hình
Bộ điều khiển có thể thiết lập hoặc yêu cầu các thông số cấu hình trong chuyển mạch
thông qua các bản tin OFPT_SET_CONFIG_REQUEST và OFPT_GET_CONFIG_
REQUEST. Chuyển mạch đáp ứng bằng bản tin OFPT_GET_CONFIG_REPLY và không
đáp ứng cho một yêu cầu thiết lập cấu hình (OFPT_SET_CONFIG_REQUEST).
struct ofp_switch_config {
struct ofp_header header;
unit16_t flags ; /*Bitmap của OFPC_* flags */
unit16_t miss_send_len; /* số lượng byte tối đa của gói mà datapth sẽ gởi đến bộ
điều khiển */
};
OFP_ASSERT (sizeof (struct ofp_switch_config) == 12)
Các cờ :
enum ofp_confi_flags {
OFPC_FRAG_NORMAL = 0,, /* không xử lý đặc biệt cho các phân đoạn*/
OFPC_FRAG_DROP = 1 << 0,, /* loại bỏ các phân đoạn*/
OFPC_FRAG_REASM = 1 << 1, /* tái hợp các phân đoạn nếu OFPC_IP_REASM
được thiết lập*/
OFPC_FRAG_MASK = 3,
};
Các cờ này cho biết các phân đoạn IP được xử lý bình thường , loại bỏ hay tái hợp.
Xử lý ‘bình thường” có nghĩa là sẽ có một nổ lực để chuyển các phân đoạn qua các bảng
OpenFlow
 Các bản tin thay đổi trạng thái: OFP_TABLE_MOD, OFP_FLOW_MOD, OFP_
GROUP_MOD, OFP_PORT_MOD, OFP_METER_MOD
Bộ điều khiển có thể dùng bản tin yêu cầu OFP_TABLE_MOD để cấu hình trạng thái
động trong một bảng luồng. Bản tin này có cấu trúc như sau :
struct ofp_table_mod {
struct ofp_header header;
unit8_t table_id ; /*Nhận diện của bảng*/
unit8_t pad[3]; /*đệm chẳn 32bit */
unit32_t config; /*Bitmap của các cờ */
/*danh sách đặc tính thay đổi bảng*/
Struct ofp_table_mod_prop_header properties[0]
11
Phần 1 : OpenFlow

};
OFP_ASSERT (sizeof (struct ofp_table_mod) == 16)

Table-id là nhận diện bảng mà cấu hình thay đổi sẽ tác động. Nếu table-id là OFPTT_
All thì cấu hình sẽ tác động đến tất cả các bảng trong switch. Vùng config là một bitmap cấu
hình các hành vi của bảng, nó gồm các cờ sau :
enum ofp_table_config {
OFPTC_DEPRECATED_MASK = 3,
OFPTC_EVICTION = 1 << 2,
OFPTC_VACANCY_EVENTS = 1 << 3,
};

Cờ OFPTC_EVICTION điều khiển sự thu hồi mục luồng trong bảng luồng. Nếu cờ
này được thiết lập thì chuyển mạch có thể thu hồi lại mục luồng từ bảng luồng. Nếu cờ này
không được thiết lập thì chuyển mạch không thể thu hồi mục luồng từ bảng luồng. hoạt động
thu hồi này là một tùy chọn và vì thể chuyển mạch có thể không hỗ trợ thiết lập cờ này.
Cờ OFPTC_VACANCY_EVENTS điều khiển sự kiện tạo khoản trống trong bảng.
Nếu cờ này được thiết lập, thì chuyển mạch phải tạo những sự kiện tạo khoảng trống cho
bảng đó. Các thông số cho sự kiện tạo khoản trống có thể được chỉ ra trong đặc tính
OFPTMPT_VACANCY.
Vùng properties là một danh sách các đặc thính thay đổi bảng, nó miêu tả các thông
số động của cấu hình bảng. Các loại đặc tính thay đổi bảng hiện nay như sau :
enum ofp_table_mod_prop_types {
OFPTMPT_EVECTION = 0x2, /* đặc tính thu hồi */
OFPTMPT_VACANCY = 0x3, /* đặc tính tạo khoản trống */
OFPTMPT_EXPERIMENTER = 0xFFFF, /* đặc tính thử nghiệm*/
};

Một định nghĩa đặc tính bao gồm loại đặc tính, chiều dài, và bất kỳ dữ liệu kết hợp
nào.

struct ofp_table_mod_prop_header {
struct ofp_header header;
unit16_t type ;
unit16_t lenght;
};
OFP_ASSERT (sizeof (struct ofp_table_mod_prop_header) == 4)
 Bản tin Packet-out : Bộ điều khiển dùng bản tin Packet-out OFPT_PACKET_OUT
để gởi một gói đi ra thông qua datapath
struct ofp_packet_out {

12
Phần 1 : OpenFlow

struct ofp_header header;

unit32_t buffer_id ; /*Nhận diện do datapath ấn định*/
unit32_t in_port; /*cổng vào của gói hoặc cổng OFPP_CONTROLLER */
unit16_t actions_len; /*kích thước của dãy action tính theo byte */
unit8_t pad[6];
Struct ofp_table_mod_prop_header action[0] /*danh sách action */
/*theo sau danh sách action có kích thước biến đổi là dữ liệu. Dữ liệu này chỉ hiện diện*/
/* và có ý nghĩa đầy đủ nếu buffer_id == -1 */
/*unit8_t data[0];*/
};
OFP_ASSERT (sizeof (struct ofp_packet_out) == 24)

Buffer_id giống như trong bản tin ofp_packet_in . Nếu buffer_id là

OFP_NO_BUFFER (0xffff ffff), thì dữ liệu gói được bao gồm trong phần dữ liệu, và gói
được đóng gói trong bản tin được xử lý theo những action trong vùng action. Nếu buffer_id
có giá trị, thì gói tương ứng được lấy ra khỏi bộ đệm và được xử lý theo những action của bản
tin.

Vùng in_port là cổng lối vào kết hợp với gói mà OpenFlow đang xử lý. Nó phải được
thiết lập đến một cổng chuẩn hoặc cổng luận lý OFPP_CONTROLLER. Ví dụ, vùng này
được sử dụng khi xử lý gói dùng OFPP_TABLE, OFPP_IN_PORT, OFPP_ALL và các
group.
Vùng action là danh sách các action xác định cách thức chuyển mạch xử lý gói này
như thế nào. Nó có thể là hoạt động thay đổi gói, xử lý nhóm, và một cổng đầu ra. Bắt đầu từ
bảng luồng đầu tiên, danh sách action này cũng có thể chỉ ra port danh riêng OFPP_TABLE
như là một hoạt động xuất để xử lý gói qua đường ống OpenFlow. Nếu OFPP_TABLE được
chỉ ra trong vùng action, thì vùng in_port được sử dụng làm cổng lối vào trong quá trính tìm
kiếm bảng luồng.
 Bản tin Barrier
Khi bộ điều khiển muốn đảm bảo những phụ thuộc bản tin đã được đáp ứng hoặc
muốn nhận các thông báo về các hoạt động đã hoàn thành, nó có thể sử dụng bản tin
OFPT_BARRIER_REQUEST. Vào lúc nhận bản tin barrier, chuyển mạch phải hoàn tất việc
xử lý tất cả các bản tin nhận được trước đây, bao gồm những bản tin hồi đáp hoặc báo lỗi
tương ứng đang được gởi, trước khi xử lý bất kỳ các bản tin nào đến sau bản tin này. Khi xử
lý như trên hoàn tất, chuyển mạch phải gởi một bản tin hồi đáp OFPT_BARRIER_REPLY
với số nhận diện giống như trong bản tin barrier-request ban đầu.
 Bản tin Role-Request : Bộ điểu khiển dủng bản tin OFPT_ROLE_REQUEST để
thay đổi vai trò của nó. Bản tin có cấu trúc như sau
struct ofpt_role_request {
struct ofp_header header;
unit32_t role ; /*Một trong các vai trò OFPCR_ROLE_*. */
unit8_t pad[4]; /* đệm chẳn 64 bit */
13
Phần 1 : OpenFlow

unit64_t generation_id; /* nhận diện bầu chọn master */

};
OFP_ASSERT (sizeof (struct ofp_role_request) == 24)

Vùng role là vai trò mới mà bộ điều khiện muốn có, nó có những giá trị sau :
enum ofp_controller_role {
OFPCR_ROLE_NOCHANGE = 0, /* không thay đổi vai trò hiện hành */
OFPCR_ROLE_EQUAL = 1, /* vài trò mặc định, truy xuất đầy đủ */
OFPCR_ROLE_MASTER = 2, /* truy xuất đầy đủ, ở vai trò master*/
OFPCR_ROLE_SLAVE =3, /*truy xuất chỉ đọc*/
};
Nếu giá trị role trong bản tin là OFPCR_ROLE_MASTER hoặc OFPCR_ROLE_
SLAVE , thì chuyển mạch phải xác nhận giá trị generation-id để xem các bản tin này có quá
cũ hay không. Nếu xác nhận này báo lỗi (bản tin quá cũ), thì chuyển mạch phải loại bỏ yêu
cầu vai trò và hồi đáp bản tin báo lỗi có OFPET_ROLE_REQUEST_FAILED và mã
OFPRRFC_STALE.
Nếu giá trị vùng role là OFPCR_ROLE_MASTER, thì tất cả các bộ điều khiển khác có
vai trò là OFPCR_ROLE_MASTER được chuyển thành vai trò OFPCR_ROLE_SLAVE . Nếu
giá trị vùng role là OFPCR_ROLE_NOCHANGE , thì vài trò hiện hành của bộ điều khiển
không thay đổi; điều này cho phép bộ điều khiển chất vấn vai trò hiện hành của nó mà không
thay đổi vai trò.
Vào lúc nhận một bản tin OFPT_ROLE_REQUEST , nếu không có lỗi xảy ra, thì
chuyển mạch phải đáp ứng lại bản tin OFPT_ROLE_REPLY. Cấu trúc bản tin này giống như
bản tin OFPT_ROLE_REQUEST, và vùng role là vai trò hiện hành của bộ điều khiển. Vùng
generation_id được thiết lập là generation_id hiện hành (generation_id kết hợp với yêu cầu
vai trò thành công sau cùng với vai trò OFPCR_ROLE_MASTER hoặc
OFPCR_ROLE_SLAVE), nếu generation_id hiện hành chưa bao giờ được bộ điều khiển thiết
lập, thì vùng generation_id trong bản tin hồi đáp phải được thiết lập đến giá trị vùng cực đại
(tương đương không dấu là -1).
Nếu chuyển mạch phải thay đổi vai trò một bộ điều khiển khác từ OFPCR_ROLE_MASTER
thành OFPCR_ROLE_SLAVE , thì nó phải gởi đến bộ điều khiển đó một bản tin OFPCR
_ROLE_STATUS
1.3.2. Các bản tin Asynchronous

 OFP_PACKET_IN : Khi các gói được datapath nhận và gởi đến bộ điều khiển, thì
chúng được gởi trong các bản tin này.
struct ofpt_packet_in {
struct ofp_header header;
unit32_t buffer_id; /* ID do datpath gán*/
unit16_t total_len; /* chiều dài đầy đủ của frame */
unit8_t reason; /* lý do gói được gởi đi */

14
Phần 1 : OpenFlow

unit8_t table_id; /* ID của bảng được tìm kiếm */

unit64_t cookie; /*cookie của mục luồng được tìm kiếm */
structure ofp_match match /* siêu dữ liệu gói, kích thước biến đổi */
//unit8_t pad[2]; /*hiệu chỉnh giới hạn 64 bit + 16 bit*/
//unit8_t data[0]; /*Ethernet frame*/
};
OFP_ASSERT (sizeof (struct ofp_packet_in) == 32)

Buffer_id là một giá trị tùy thuộc vào từng trường hợp khác nhau và được datapath sử
dụng để nhận diện một gói được đệm. Khi một gói được đệm, một số lượng byte nào đó của
nó được chứa trong phần data của bản tin này. Nếu gói được gởi đi do một hoạt động “send to
controller”, một số lượng max_len byte từ ofp_action_output của yêu cầu thiết lập luồng
được gởi đi. Nếu gói được gởi vì những ly do khác, ví dụ một TTL không hợp lệ, thì ít nhất
miss_send_len (mặc định = 128) byte được gởi đi. Nếu packet không được đệm – hoặc do
không còn bộ đệm khả dụng, hoặc do được yêu cầu thông qua hằng số
OFPCML_NO_BUFFER (oxffff) – toàn bộ gói được bao gồm trong phần data, và buffer_id
là OFP_NO_BUFFER.
Vùng data chứa gói cần gởi đi, hoặc một phần của gói nếu gói được đệm.
Vùng reason cho biết ngữ cảnh tạo ra bản tin Packet_in và có thể là một trong các giá
trị sau
enum ofp_packet_in_reason {
OFPR_TABLE_MISS = 0, /* không so trùng luồng(mục table-miss) */
OFPR_APPLY_ACTION = 1, /* Xuất tới bộ điều khiển theo apply_actions */
OFPR_INVALID_TTL = 2, /* packet có TTL không có giá trị */
OFPR_ACTION_SET = 3, /* Xuất tới bộ điều khiển theo action_set */
OFPR_GROUP = 4, /* Xuất tới bộ điều khiển theo group bucket */
OFPR_PACKET_OUT = 5, /* Xuất tới bộ điều khiển theo packet_out*/
};
Vùng cookie chứa cookie của mục luồng gây ra gói được gởi đến bộ điều khiển.
Vùng match phản ánh các herder của gói và ngữ cảnh khi sự kiện tạo ra bản tin
packet_in xảy ra.
 Bản tin loại bỏ luồng OFPT_FLOW_REMOVED : datapath dùng bản tin này để
thông báo với bộ điều khiển (nếu bộ điều khiển yêu cầu) khi các mục luồng hết hạn thời gian
tồn tại hoặc bị xóa khỏi bảng.
struct ofpt_flow_removed {
struct ofp_header header;
unit64_t cookie; /* giá trị tùy theo tình huống, được bộ điều khiển chọn*/
unit16_t Priority; /* mức độ ưu tiên của mục luồng */
unit8_t reason; /* một trong số OFPRR_*. */
unit8_t table_id; /* ID của bảng */

15
Phần 1 : OpenFlow

unit32_t duration_sec;
unit32_t duration_nsec;
unit16_t idle_timeout;
unit16_t hard_timeout;
unit64_t packet_count;
unit64_t bytet_count;
structure ofp_match match
};
OFP_ASSERT (sizeof (struct ofp_flow_removed) == 56);
/*thời gian luồng đã tồn tại tính theo giậy*/
/*thời gian luồng đã tồn tại tính theo nano giấy khi
vượt qua duration_sec*/
/*thời gian nhàn rỗi tối đa của luồng*/
/*thời gian tồn tại của luồng*/
/* Miêu tả của các vùng so trùng, kích thước biến đổi */

Vùng reason là một trong các giá trị sau :

enum ofp_flow_removed_reason {
OFPRR_IDLE_TIMEOUT = 0,
OFPRR_HARD_TIMEOUT = 0,
OFPRR_DELETE = 0,
OFPRR_GROUP_DELETE = 3,
OFPRR_METER_DELETE = 4,
OFPRR_EVICTION = 5,
};
/* thời gian nhàn rỗi vượt quá idle_timeout */
/* thời gian vượt quá hard_timeout */
/* bị thu hồi bởi một bản tin xóa luồng*/
/* Group bị xóa */
/* Meter bị xóa */
/* Thu hồi để giải phóng các tài nguyên */

 OFPT_PORT_STATUS : khi port được thêm vào, thay đổi, hoặc xóa, datapath
dùng bản tin này để thông báo trạng thái port cho bộ điều khiển
struct ofpt_port_status {
struct ofp_header header;
unit8_t reason; /* một trong các giá trị OFPPR_*. */
unit8_t pad[7] /* đệm làm chẵn 64 bit */
structure ofp_port desc
};
OFP_ASSERT (sizeof (struct ofp_port_status) == 56);

Vùng reason có một trong các giá trị sau :

enum ofp_port_reason {
OFPPR_ADD = 0, /* port được thêm vào */
OFPPR_DELETE = 1, /*port bị xóa */
OFPPR_MODIFY = 2, /* một vài thuộc tính của port đã thay đổi*/
};
Vùng desc là một miêu tả port. Không cần miêu tả đầy đủ các đặc tính, chỉ cần những
đặc tính đã thay đổi.

1.3.3. Các bản tin Symmetric

 Hello : bản tin này bao gồm một header openflow và một tập các phần tử hello có
kích thước biên đổi.
16
Phần 1 : OpenFlow

struct ofp_hello {
struct ofp_header header;
unit8_t reason; /* một trong các giá trị OFPPR_*. */
/* danh sách các phần tử hello */
structure ofp_hello_elem_header element[0];
};
OFP_ASSERT (sizeof (struct ofp_hello) == 8);

Vùng elements là tập các phần tử hello chứa dữ liệu tùy chọn để thông báo thủ tục bắt
tay ban đầu của kết nối. Danh sách các loại phần tử hello hiện nay được định nghĩa như sau :
enum ofp_hello_elem_type {
OFPHET_VERSIONBITMAP = 1, /* Bitmap của biên bản được hỗ trợ*/
};
Một định nghĩa phần tử gổm kiểu, chiều dài phần tử và dữ liệu kết hợp :
struct ofp_hello_elem_header {
unít16_t type; /* OFPHET_VERSIONBITMAP */
unít16_t lenght; /*Chiều dài tính theo byte của phần tử này */
};
OFP_ASSERT (sizeof (struct ofp_hello_elem_header) == 4);

Phần tử OFPHET_VERSIONBITMAP sử dụng cấu trúc và các vùng sau :

struct ofp_hello_elem_versionbitmap {
unít16_t type; /* OFPHET_VERSIONBITMAP */
unít16_t lenght; /*Chiều dài tính theo byte của phần tử này */
unít32_t bitmap[0]; /*Danh sách các bitmap */
};
OFP_ASSERT (sizeof (struct ofp_hello_elem_versionbitmap) == 4);
Vùng bitmap cho biết tập các phiên bản giao thức chuyển mạch OpenFlow mà thiết bị
hỗ trợ và có thể được dùng trong giai đoạn thương lượng phiên bản. số lượng các bitmap phụ
thuộc vào số phiên bản cao nhất được hỗ trợ: các phiên bản 0-31 được mã hóa trong bitmap
đầu tiên, phiên bản từ 32-64 được mã hóa trong bitmap thứ hai và v.v..Ví dụ nếu chuyển
mạch hỗ trợ chỉ phiên bản 1.0 (ofp_version=0x01) và phiên bản 1.3 (ofp_version=0x04), thì
bitmap đầu tiên được thiết lập giá trị 0x00000012
 Echo request : bản tin này bao gồm một mào đầu OpenFlow và một vùng dữ liệu
có chiều dài tùy ý. Vùng dữ liệu có thể có một timestamp của bản tin để kiểm tra độ trễ, chiều
dài khác nhau để đo băng thông, hoặc kích thước bằng không, lúc này bản tin echo chỉ để
thẩm tra sự hoạt động giữa chuyển mạch và bộ điều khiển
 Echo Reply: bao gồm một mào đầu OpenFlow và vùng dữ liệu không thay đổi của
bản tin yêu cầu echo

17
Phần 1 : OpenFlow

 Error : chuyển mạch và bộ điều khiển sử dụng bản tin này để thông báo sự cố của
kết nối cho đầu bên kia kết nối. Chúng hầu như được bộ chuyển mạch sử dụng để chỉ báo lỗi
trong một yêu cầu của bộ điều khiển. Bản tin OFP_ERROR_MSG có cấu trúc như sau :
struct ofp_error_msg {
struct ofp_header header;
unit16_t type:
unit16_t code;
unit8_t data[0]; /* Dữ liệu có chiều dài có thể thay đổi. ý nghĩa tùy
theo type và code */
};
OFP_ASSERT (sizeof (struct ofp_error_msg) == 12);

Vùng type chỉ thị loại lỗi mức cao. Ví dụ : Type=0: giao thức hello bị lỗi ( OFPET_
HELLO_FAILED) , type = 7: yêu cầu thay đổi port bị lỗi (OFPET_PORT_MOD_FAILED)
Vùng code được hiểu tùy theo vùng type. Ví dụ : với type = 0 (OFPET_ HELLO_
FAILED) , thi vùng mã được định nghĩa như sau :
enum ofp_hello_failed_code {
OFPHFC_INCOMPATIBLE = 0, /* Không có phiên bản tương thích*/
OFPHFC_EPERM = 1, /* Không có quyền */
};
Trong đặc tả OpenFlow phiên bản 1.4 định nghĩa 18 kiểu lỗi và trong mỗi kiểu như
vậy lại có một số mã lỗi. Tổng cộng có 147 mã lỗi có thể bao trùm hầu hết các tính huống lỗi
xảy ra.
 Experimenter : bản tin này dùng trong hoạt động thử nghiệm và cấu trúc của nó
như sau :
struct ofp_experimenter_msg {
struct ofp_header header;
unit32_t experimenter /* nhận diện experimenter */
unit16_t exp_type;
unit8_t experimenter_data[0]; /* Dữ liệu bổ sung tùy ý tùy thuộc vào thử nghiệm */
};
OFP_ASSERT (sizeof (struct ofp_experimenter_msg) == 16);

Vùng experimenter dùng nhận diện hoạt động thử nghiệm, exp_type cho biết loại thử
nghiệm và vùng experimenter_data là dữ liệu tùy ý tùy thuộc vào thử nghiệm.

Bản tin này không kết hợp với một đối tường OpenFlow cụ thể nào, và như vậy có thể
được dùng tạo ra những API hoàn toàn mới và quản lý toàn bộ các đối tượng mới. Nếu một
chuyển mạch không hiểu một bản tin experimenter, nó phải gởi một bản tin báo lỗi OFPT_
ERROR với một mã lỗi OFPBRC_BAD_EXPERIMENTER và kiểu lỗi OFPET_BAD_
REQUEST

18
Phần 2 : Công cụ giả lập SDN và phân tích OpenFlow

Phần 2 : Công cụ giả lập SDN và phân tích OpenFlow

2.1 Mininet :
Mininet là một hệ thống dùng tạo nguyên mẫu cho các mạng lớn trong điều kiện tài
nguyên trên một laptop. Mininet sử dụng những đặc tính ảo hóa cấp hệ điều hành, gồm các
tiến trình và không gian tên mạng, cho phép nó giả lập lên đến hàng trăm node. Mininet tạo
điều kiện thuận lợi cho các nhà nghiên cứu trong lĩnh vực kết nối mạng có thể phát triển và
triển khai những ý tưởng, ví dụ một kiến trúc mạng mới, một giao thức di động, hoặc một đặc
tính bổ sung vào router. Mininet tạo ra một môi trường tạo nguyên mẫu của một mạng với
những đặc tính sau :
 Linh động: Các địa hình và chức năng mới dược định nghĩa trong phần mềm, dùng
những ngôn ngữ và hệ điều hành quen thuộc
 Triển khai : Việc triển khai một nguyên mẫu đúng về mặt chức năng trên các mạng
phần cứng và môi trường thử nghiệm sẽ không cần thay đổi mã hoặc cấu hình.
 Tương tác : Việc quản lý và vận hành mạng sẽ thực hiện như trong mạng thực, như
thể ta đang tương tác với mạng thực.
 Qui mô : Tạo nguyên mẫu cho các mạng lên đến hàng trăm hàng ngàn chuyển mạch
chỉ trên một laptop.
 Thực tế : Hành vi của nguyên mẫu là những hành vi thực với mức độ tin cây cao, ví
dụ những ứng dụng và chồng giao thức cỏ thể sử dụng được mà không có sự thay đổi
nào.
 Chia sẽ : những nguyên mẫu khép kín sẽ dễ dàng chia sẽ với các cộng tác viên.
Các môi trường tạo nguyên mẫu hiện nay có những mặt thuận lợi và không thuân lợi .
Các công cụ thử nhiệm mắc tiền vượt qua khả năng của các nhà nghiên cứu. Các bộ mô
phỏng, như ns2 hoặc Opnet, có thể hấp dẫn do chúng chạy trên một laptop, nhưng chúng
thiếu tính thực tế : mã tạo ra trong các bộ mô phỏng này không giống mã triển khai trên các
mạng thực, và chúng không có tương tác. Nếu nhìn sơ bộ, ta thấy mạng các máy ảo có vẽ hấp
dẫn. Một máy ảo dùng cho bộ chuyển mạch hoặc bộ định tuyến, và một máy ảo dùng cho
máy host, và các giao thức thực có thể dễ dàng kết nối chúng với nhau qua các giao tiếp ảo.
Tuy nhiên, máy ảo thì quá nặng nề, phí tổn bộ nhớ cho mỗi máy ảo sẽ làm giới hạn số lượng
các chuyển mạch và các host.
Mininet là một môi trường cục bộ cho phép chúng ta thực hiện nhanh chóng một
nguyên mẫu chính xác về mặt chức năng. Nó hỗ trợ tiến trình công việc này bằng cách sử
dụng sự ảo hóa đơn giản. Người dùng có thể thực hiện một đặc tính mạng mới hoặc toàn bộ
kiến trúc mạng mới, thử nó trên những cấu trúc liên kết mạng lớn với lưu lượng ứng dụng, và
sau đó triển khai mã giống chính xác và các kịch bản thử trên một mạng thực tế. Mininet
chạy tốt trên một laptop đơn nhờ vào khả năng của các đặc tính của Linux (các tiến trình và

19
Phần 2 : Công cụ giả lập SDN và phân tích OpenFlow

các cặp kết nối Ethenet ảo trong các namespace mạng) để triển khai các mạng với băng thông
hàng gigabit và hàng trăm node mạng . Toàn bộ mạng có thể đóng gói như một máy ảo, tạo
điều kiện cho người khác có thể tải về, chạy, khảo sát và thay đổi nó.
2.2 Tiến trình công việc trong Mininet :
Bằng cách kết hợp sự ảo hóa đơn giản với các giao diện dòng lệnh (CLI) và giao diện
ứng dụng (API) có thể mở rộng, Mininet cung cấp một môi trường xây dựng bản nguyên mẫu
để tạo, tương tác, tùy biến và chia sẽ một SDN, cũng như một lộ trình uyển chuyển cho việc
chạy trên phần cứng thực.
2.2.1 Tạo một mạng
Bước đầu tiên để tao một mạng ta sử dụng lệnh công cụ dòng lệnh mn. Ví dụ : lệnh
mn –switch ovsk –controller nox –topo \ tree ,depth=2 ,fanout=8 pingAll
Lệnh trên khởi tạo một mạng gồm các chuyển mạch openFlow. Các chuyển mạch
Open vSwitch được kết nối với nhau theo đia hình cây có chiều sâu là 2 và tỏa ra 8 nhánh,
nghĩa là gồm 9 chuyển mạch và 64 host, dưới sự điều khiển của bộ điều khiển NOX, theo sau
là lệnh pingAll để kiểm tra kết nối giữa mỗi cặp node. Để tạo mạng này, Mininet giả lập các
liên kết, các host, các chuyển mạch và các bộ điều khiển. Mininet sử dụng các cơ chế ảo hóa
đơn giản có sẵn bên trong hệ điều hành Linux, đó là các tiến trình chạy bên trong các
namespace mạng và các cặp Ethernet ảo (kết nối 2 cổng Ethenet).
Links : Một cặp Ethernet ảo (veth pair) hoạt động giống như một kết nối dây giữa 2
giao tiếp ảo; các gói gởi qua một giao tiếp được đưa đến một giao tiếp khác, và phẩn mềm
ứng dụng và hệ thống nhìn thấy mỗi giao tiếp như là một cổng Ethernet với đầy đủ chức
năng. Các cặp veth có thể được gắn vào các chuyển mạch ảo như là Linux bridge (mã thực
hiện một tập con của chuẩn IEEE 802.1d) hoặc một chuyển mạch OpenFlow phần mềm.
Hosts : Các namespace mạng là những container trạng thái mạng (phương pháp ảo
hóa cấp hệ điều hành linux). Chúng cung cấp cho các tiến trình (và nhóm các tiến trình)
quyền sở hữu riêng biệt các giao tiếp, các cổng và các bảng định tuyến (như ARP và IP). Ví
dụ, 2 web server trong 2 namespace mạng có thể đồng tồn tại trên một hệ thống, cả 2 đều có
thể lắng nghe ở cổng 80 trên các giao tiếp eth0 riêng.
Một host trong Mininet đơn giản là một tiến trình shell (vidụ bash) được đưa vào
namespace mạng riêng của nó với yêu cầu hệ thống riêng biệt. Mỗi host có riêng các giao tiếp
Ethernet ảo và một đường ống đến tiến trình Mininet cha (mn) thực hiện gởi các lệnh và giám
sát đầu ra.
Switches : Các chuyển mạch OpenFow bằng phần mểm cung cấp cơ chế phân phối
gói vể ý nghĩa giống như những chuyển mạch phần cứng cung cấp.
Controller : Các bộ điều khiển có thể đặt ở bất cứ nơi đâu trên mạng thực hoặc trên
mạng mô phỏng, miễn sao thiết bị chạy các chuyển mạch có kết nối mức IP với bộ điều
khiển. Đối với Mininet chạy trong một máy ảo, bộ điều khiển có thể chạy bên trong máy ảo
này, chạy trên máy host, hoặc trong một đám mây.

20
Phần 2 : Công cụ giả lập SDN và phân tích OpenFlow

Hình 2.1 : Minh họa các thành phần và kết nối trong một mạng 2 host được
tạo ra bởi Mininet
2.2.2 Tương tác với mạng :
Sau khi tạo mạng, ta có thể tương tác với nó để chạy các lệnh trên host, kiểm tra hoạt
động của chuyển mạch, và có thể tìm thấy lỗi và điều chỉnh các kết nối liên kết. Mininet có
một giao tiếp dòng lệnh CLI (Command Line Interface) cho phép các nhà phát triển điều
khiển và quản lý toàn mạng từ một console. Vì CLI nhận ra các tên node và cấu hình mạng
nên nó có thể tự động thay thế các địa chỉ IP bằng tên node. Ví dụ, lệnh CLI sau
Mininet> h2 ping h3
Nói với host h2 ping đến địa chỉ IP của host h3. Lệnh này được dẫn đến tiến trình
bash giả lập host h2, nó tạo ra một yêu cầu ICMP echo đi ra giao tiếp mạng eth0 của h2 và
vào nhân hệ điều hành thông qua cặp giao tiếp Ethernet ảo veth. Yêu cầu này được một
chuyển mạch trong namespace root xử lý, sau đó nó đi trở ra một cặp veth khác để tới một
host khác. Nếu gói cần chuyển qua nhiều chuyển mạch, nó sẽ ở lại trong nhân hệ điều hành
mà không có thêm các bản sao; trong trường hợp của một chuyển mạch user-space, gói sẽ
chịu nhiều sự chuyển tiếp user-space trên mỗi chặng. Bên cạnh hoạt động như một bộ đa hợp
đầu cuối cho các host, CLI cung cấp đa dạng các lệnh có sẵn và cũng có thể thực hiện các
biểu thức Python
2.2.3 Tùy chỉnh mạng:
Mininet đưa ra một giao diện lập trình ứng dụng Python để tạo ra các thí nghiệm, địa
hình mạng, và các loại node theo ý riêng của người sử dụng: chuyển mạch, bộ điều khiển,
host, …một vài dòng Python là đủ để định nghĩa một thử nghiệm tùy chỉnh có thể tạo ra một
mạng, thực thi các lệnh trên nhiều node, và hiện thị kết quả. Một kich bản ví dụ như sau :
From mininet.net import Mininet
From minninet.topolib import TreeTopo
Tree4 = TreeTopo (depth=2,fanout=2)
net = Mininet(Topo=tree4)
net.start()
21
Phần 2 : Công cụ giả lập SDN và phân tích OpenFlow

h1, h4 = net.hosts[0], net.hosts[3]

print h1.cmd(‘ping -c1 %s’ % h4.IP())
net,stop()
Đoạn script trên tạo một mạng nhỏ (4 host, 3 switch) và ping từ host này đến một
khác, trong khoản 4 giây.
Trong bản Mininet hiện đang phân phối có nhiều ưng dụng ví dụ, gồm những kịch
bản dạng văn bản và những ứng dụng đồ họa. Những giao diện lập trình ứng dụng Mininet sẽ
chứng tỏ sự hữu dụng của nó đối với thử nghiệm và thí nghiệm, kiểm tra quản ly mạng, tài
liệu hướng dẫn và những ứng dụng mà sẽ gây ngạc nhiên cho người dùng
2.2.4 Chia sẽ một mạng :
Mininet được phân phối như một máy ảo với những phụ thuộc được cài đặt sẵn, có
thể chạy trên những phần mềm giám sát máy ảo thông dụng như VMware, Xen và
VirtualBox. Máy ảo cung cấp một phương tiện thuận tiện cho việc phân phối một nguyên
mẫu được tạo ra trên Mininet. Khi một nguyên mẫu đã được phát triển, ảnh máy ảo có thể
được phân phối kèm theo Mininet để chạy trên những máy khác. Một máy ảo Mininet trọn bộ
và được nén khoản 800MB.
2.2.5 Chạy trên phần cứng:
Để xuất đến phần cứng cho lần thử đầu tiên, mọi thành phần giả lập trên Mininet phải
hoạt động giống như thành phần vật lý tương ứng của nó. Địa hình ảo phải giống với địa hình
vật lý; các cặp veth (cặp giao tiếp Ethernet ảo kết nối với nhau) phải được thay thế bởi kết nối
Ethernet mức vật lý. Các host được giả lập bởi các tiến trình nên được thay thế bởi các host
với ảnh hệ điều hành riêng của nó. Hơn nữa, mỗi chuyển mạch OpenFlow giả lập nên được
thay thế bởi một chuyển mạch vật lý được cấu hình kết nối với bộ điều khiển. Tuy nhiên, Bộ
điều khiển không cẩn phải thay đổi. Khi Mininet đang chạy, bộ điều khiển thấy một mạng vật
lý các chuyển mạch nhờ vào một giao tiếp có các ngữ nghĩa trạng thái được định nghĩa rõ
ràng. Vói những đối tượng tượng trưng cho các đường dữ liệu OpenFlow trên các chuyển
mạch vật lý và các server SSH trên các host vật lý, giao tiếp dòng lệnh CLI cho phép người
phát triển tương tác với mạng trong cùng một cách như trước đây với những kịch bản kiểm
tra không thay đổi.

22
Phần 2 : Công cụ giả lập SDN và phân tích OpenFlow

2.3 Phân tích OpenFlow trên Mininet

2.3.1 Đồ hình mạng

TCP/SSL Of

eth0
Controller socket Datapath
protocol

raw raw raw raw

socket socket socket socket

S1-eth1 S1-eth2 S1-eth3 S1-eth4

veth veth veth veth

pair pair pair pair

h1-eht0 h2-eht0 h3-eht0 h4-eht0

Host h1 Host h2 Host h3 Host h4

Hình 2-2 Đồ hình mạng gồm 1 switch và 4 host

Thông qua địa hình mạng đơn giản trên ta có thể thấy được hoạt động của OpenFlow ;
tạo luồng, phân tích các bản tin trao đổi giữa bộ điều khiển và datapath.
2.3.2 Các bước thực hiện và phân tích :
Bước 1 : Khởi tạo mạng trên và xem nội dung bảng luồng, tính năng của chuyển
mạch
mininet@mininet-vm:~$ sudo mn --topo single,4 --mac --switch ovsk --controller remote
*** Creating network
*** Adding controller
Unable to contact the remote controller at 127.0.0.1:6633
*** Adding hosts:
h1 h2 h3 h4
*** Adding switches:
s1
*** Adding links:
(h1, s1) (h2, s1) (h3, s1) (h4, s1)
*** Configuring hosts
h1 h2 h3 h4
*** Starting controller
c0
*** Starting 1 switches
s1 ...
*** Starting CLI:
mininet>

Với lệnh sudo mn ta đã khởi tạo một mạng gồm: một chuyển mạch Open vSwitch
được tạo ra dựa vào nhân của hệ điều hành (ovsk) trong một namespace riêng, bộ điều khiển
nằm bên ngoài máy ảo của switch và giao tiếp với switch thông qua port 127.0.0.1:6633. Tuy

23
Phần 2 : Công cụ giả lập SDN và phân tích OpenFlow

nhiên, hiện tại vẫn chưa kết nối với chuyển mạch, và 4 host h1, h2, h3 và h4. Ta có thể kiểm
tra xem các thành phần đã hoạt động, kết nối vật lý và mạng được thiết lập chưa :
mininet> net
h1 h1-eth0:s1-eth1
h2 h2-eth0:s1-eth2
h3 h3-eth0:s1-eth3
h4 h4-eth0:s1-eth4
s1 lo: s1-eth1:h1-eth0 s1-eth2:h2-eth0 s1-eth3:h3-eth0 s1-eth4:h4-eth0
c0
mininet> dump
<Host h1: h1-eth0:10.0.0.1 pid=2823>
<Host h2: h2-eth0:10.0.0.2 pid=2827>
<Host h3: h3-eth0:10.0.0.3 pid=2829>
<Host h4: h4-eth0:10.0.0.4 pid=2832>
<OVSSwitch s1: lo:127.0.0.1,s1-eth1:None,s1-eth2:None,s1-eth3:None,s1-eth4:None pid=2837>
<RemoteController c0: 127.0.0.1:6633 pid=2817>
mininet> links
h1-eth0<->s1-eth1 (OK OK)
h2-eth0<->s1-eth2 (OK OK)
h3-eth0<->s1-eth3 (OK OK)
h4-eth0<->s1-eth4 (OK OK)
mininet>
Dùng trình tiện ích ovs-ofctl để kiểm tra tính năng và bảng luồng của switch s1
mininet@mininet-vm:~$ sudo ovs-ofctl show s1
OFPT_FEATURES_REPLY (xid=0x2): dpid:0000000000000001
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST SET_NW_SRC
SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE
1(s1-eth1): addr:52:06:39:21:15:d1
config: 0
state: 0
current: 10GB-FD COPPER
speed: 10000 Mbps now, 0 Mbps max
2(s1-eth2): addr:b6:4b:92:08:86:e8
config: 0
state: 0
current: 10GB-FD COPPER
speed: 10000 Mbps now, 0 Mbps max
3(s1-eth3): addr:46:ab:e4:99:d0:c3
config: 0
state: 0
current: 10GB-FD COPPER
speed: 10000 Mbps now, 0 Mbps max
4(s1-eth4): addr:8a:6f:88:72:46:8e
config: 0
24
Phần 2 : Công cụ giả lập SDN và phân tích OpenFlow

state: 0
current: 10GB-FD COPPER
speed: 10000 Mbps now, 0 Mbps max
LOCAL(s1): addr:ea:8d:b9:9b:a8:4f
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
mininet@mininet-vm:~$

Bảng luồng chưa có một entry nào vì ta chưa khởi động một bộ điều khiển nào
mininet@mininet-vm:~$ sudo ovs-ofctl dump-flows s1
NXST_FLOW reply (xid=0x4):
mininet@mininet-vm:~$

Bước 2 : Kiểm tra kết nối giữa các host

mininet> h1 ping -c1 h3
PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
From 10.0.0.1 icmp_seq=1 Destination Host Unreachable
--- 10.0.0.3 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
mininet> h2 ping -c1 h4
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
From 10.0.0.2 icmp_seq=1 Destination Host Unreachable
--- 10.0.0.4 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
mininet>
Chưa có kết nối giữa các host vì trong bảng luồng không có một mục luồng nào cho
các kết nối này. Để tạo các kết nối này (h1-h3 và h2-h4) ta dùng trình tiện ích ovs-ofctl để tạo
các mục luồng tương ứng trong bảng luồng
mininet@mininet-vm:~$ sudo ovs-ofctl add-flow s1 in_port=1,actions=output:3
mininet@mininet-vm:~$ sudo ovs-ofctl add-flow s1 in_port=3,actions=output:1
mininet@mininet-vm:~$ sudo ovs-ofctl add-flow s1 in_port=2,actions=output:4
mininet@mininet-vm:~$ sudo ovs-ofctl add-flow s1 in_port=4,actions=output:2
mininet@mininet-vm:~$

Kiểm tra lại bảng luồng ta thấy 4 mục luồng đã được thêm vào bảng luồng tương
ứng với các luồng giữa port1-port 3 và port 2-port4
mininet@mininet-vm:~$ sudo ovs-ofctl dump-flows s1
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=547.885s, table=0, n_packets=15, n_bytes=1358, idle_age=500, in_port=3
actions=output:1
cookie=0x0, duration=566.31s, table=0, n_packets=15, n_bytes=1358, idle_age=500, in_port=1
actions=output:3
cookie=0x0, duration=409.62s, table=0, n_packets=13, n_bytes=1162, idle_age=382, in_port=4
actions=output:2
25
Phần 2 : Công cụ giả lập SDN và phân tích OpenFlow

cookie=0x0, duration=423.517s, table=0, n_packets=13, n_bytes=1162, idle_age=382, in_port=2

actions=output:4
mininet@mininet-vm:~$

Kiểm tra kết nối giữa h1-h3 và h2-h4 ta thấy đã có kết nối nhờ vào các mục luồng vừa
thiết lập

Hình 2-3 Dùng lệnh ping để kiểm tra tác động của các mục luồng
Bước 3 : Khởi tạo kết nối bộ điều khiển – bộ chuyển mạch
Chạy chương trình Wireshark để bắt các bản tin OpenFlow giữa chuyển mạch và bộ
điều khiển và thực hiện lệnh controller ptcp: (bộ điều khiển có sẵn trong gói mininet-VM).
Trên cửa sổ wireshark ta sẽ bắt được các bản tin OpenFlow trao đổi giữa bộ điều khiển ptcp
và chuyển mạch ovsk.

Hình 2-4 Bản tin Hello

Trong bước khởi tạo kết nối, bộ chuyển mạch và bộ điều khiển trao đổi các bản tin
Hello để thực hiện thỏa thuận phiên bản giao thức OpenFlow sử dụng giữa 2 thiết bị. Trong
các bản tin Hello, 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 trong 2 giá trị này. Trong trường hợp này, cả bộ điều khiển và bộ

26
Phần 2 : Công cụ giả lập SDN và phân tích OpenFlow

chuyển mạch đều dùng phiên bản 1. Vùng xid dùng nhận diện giao dịch có giá trị
1945240427
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 = 1 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 2-5 Bản tin OFPT_FEATURE_REQUEST

Hình 2-6 Bản tin OFPT_FEATURE_REPLY

27
Phần 2 : Công cụ giả lập SDN và phân tích OpenFlow

Hình 2-7 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.
Xid : số nhận diện giao dịch
Flags = 0 (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 : 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ệ
Bước 4 : 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 lệnh ping từ h1 đến h3
mininet> h1 ping -c1 h3
Trên wireshark ta sẽ bắt được một số bản tin :
 Packet_in : từ bộ chuyển mạch (cổng TCP 47973) đến bộ điều khiển (cổng TCP
6633) , 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à 98 và vùng data chứa frame ethernet
(đóng gói bản tin của giao thức ICMP - lệnh ping)

28
Phần 2 : Công cụ giả lập SDN và phân tích OpenFlow

Hình 2-8 Bản tin OFPT_PACKET_IN

 Packet_out : gởi từ bộ điều khiển (6633) đến chuyển mạch (47973), có buffer_id
giống buffer_id của gói packet_in (262), danh sách action chỉ gồm một hoạt động xuất ra port
65531

Hình 2-9 Bản tin OFPT_PACKET_OUT

 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. Luồng mới này 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à
29
Phần 2 : Công cụ giả lập SDN và phân tích OpenFlow

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=263 thì chuyển mạch phải lấy gói tương ứng trong bản
tin packet_in (có buffer_id=263) 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.

Hình 2-30 Bản tin OFPT_FLOW_MOD

Để kiểm tra tác động của bản tin này ta có thể khảo sát mục luồng mới này bằng lệnh
sau :
mininet@mininet-vm:~$ sudo ovs-ofctl dump-flows s1

30
 TỪ VIẾT TẮT
A
ACL Access Control List
API Application Programming Interfaces
ARP Address Resolution Protocol
C
CLI Command-Line Interface
D
DS Differentiated Service
E
ECN Explicit Congestion Notification
I
ICMP Internet Control Message Protocol
SCTP Stream Control Transmission Protocol
L
LAN Local Area Network
O
OF OpenFlow
ONF Open Networking Foundation
OSPF Open Shortest Path First
M
MAC Media Access Control
MPLS Multiprotocol Label Switching
N
NOS Network operating System
Q
QoS Quality of Service
R
RARP Reserve Address Resolution Protocol
S
SCTP Stream Control Transmission Protocol

31
SSL Secure Socket Layer
T
TCP Transmission Control Protocol
TLS Transport Layer Security
TTL Time To Live
U
UDP User Datagram protocol
V
VLAN Virtual Local Area Network

32
 TÀI LIỆU THAM KHẢO

[1] Jain-Quan Wang, Haijng Fu, Chang Cao, “ Software Defined Networking for
Telecom Operators: Architecture and Application“, 2013 8th International
Conference on Communications and Networking in China, 2013.
[2] Rajesh Kumar S. , “A definitive guide to Software Defined Networking
(SDN)“ Published by Rejesh Kumar at Smashwords“ , 2013.
[3] “OpenFlow Switch Specification version 1.4.0,” ONF, October 2013.
[4] S. Sezer, S. Scott-Hayward, P. K. Chouhan, B. Fraser, D. Lake, J. Finnegan,
N. Viljoen, Marc Miller, N. Rao, “ Are We Ready for SDN? Implementation
Challenges for Sofware-Defined Networks,“ IEEE Communications
Magazine, July 2013
[5] “Software Defined Networking : The New Norm for Networks,“ ONF White
Paper , April 2012.
[6] D. Kreutz, Fernando M. V. Ramos, P. Verrisimo, C. E. Rothenberg, S.
Azodolmolky, S.Uhlig, “ Software-Defined Networking: A Comprehensive
Survey,“ IEEE Communication Surveys & Tutorial, arXiv:1406.0440v3
[cs.NI], October 2014.
[7] Bob Lantz, Brandon Heller, Nick McKeown, “A network in a laptop _Rapid
prototyping for SDN,“ October 2010
[8] “OpenFlow Switch Specification”, ONF, October 2013
[9] http://mininet.org/

33