Traffic Engineering dựa trên QoS trong SDN

Chương 3: Nền tảng lý thuyết

Mạng điều khiển phần mềm (SDN) là một mô hình mới được đề xuất để thay
đổi cách mà các mạng hiện tại đang hoạt động. Nguyên tắc cơ bản của SDN
nằm ở việc tách rời các tầng điều khiển và chuyển tiếp của mạng; sau đó, một
bộ điều khiển SDN bên ngoài có thể động lực hóa các quy tắc vào các nút có
khả năng SDN. Dựa trên những quy tắc này, các nút có khả năng SDN thực hiện
kiểm tra, thay đổi và chuyển tiếp gói tin. Ngoài ra, các nút có khả năng SDN cơ
bản (có thể là các công tắc Open flow, OpenVswitch hoặc Bộ định tuyến ảo,
vv.) có thể kiểm tra và sửa đổi tiêu đề gói tin ở các cấp độ khác nhau của mô
hình giao thức, từ lớp 2 đến lớp ứng dụng.
Trong kiến trúc SDN, tầng điều khiển có thông minh mạng và tầng cơ sở hạ
tầng mạng và các tầng đó được kết nối thông qua các API. Do đó, những nhà
nghiên cứu và nhà phát triển có thể tập trung vào từng tầng của kiến trúc mà
không cần quan tâm đến các phức tạp của tầng khác. Tính năng chính của kiến
trúc SDN là tính lập trình được cho phép các nhà vận chuyển và doanh nghiệp
thích nghi với các yêu cầu kinh doanh đang thay đổi nhanh chóng một cách tự
động và linh hoạt hơn.
3.1 Kiến trúc tham chiếu SDN (SDN Reference Architecture)
Một SDN bao gồm ba tầng: tầng ứng dụng, tầng điều khiển và tầng dữ liệu. Giải
thích chi tiết về các tầng chính như sau:
Tầng dữ liệu (chuyển tiếp) (Data (forwarding) Plane): Theo cách tiếp cận từ
dưới lên, tầng dữ liệu là thiết bị chuyển tiếp được kết nối thông qua các phương
tiện có dây hoặc không dây. Mục đích của tầng dữ liệu là chuyển tiếp lưu lượng
mạng một cách hiệu quả nhất dựa trên một tập hợp quy tắc chuyển tiếp được chỉ
định bởi tầng điều khiển. Kiến trúc SDN loại bỏ thông minh chuyển tiếp từ phần
cứng mạng và chuyển các chức năng này vào tầng điều khiển. Một trong những
cách mà các công tắc OpenFlow truyền thống (tức tầng dữ liệu) cung cấp các
tính năng chuyển tiếp này là thông qua Ternary Content-Addressable Memory
(TCAM). Các yếu tố chuyển tiếp và bộ điều khiển SDN giao tiếp thông qua
giao diện southbound được gọi là OpenFlow. Hiện nay, giao thức OpenFlow
được sử dụng như một giao thức liên lạc southbound tiêu chuẩn được hỗ trợ bởi
một số nhà cung cấp bao gồm ONF.
Tầng điều khiển (Control Plane): Tầng điều khiển SDN, thường được gọi là bộ
điều khiển, là thành phần lập trình và quản lý các thiết bị chuyển tiếp thông qua
giao diện southbound. Tầng điều khiển chịu trách nhiệm đưa ra quyết định về
cách lưu lượng mạng sẽ được định tuyến thông qua mạng từ nút nguồn đến nút
đích dựa trên yêu cầu ứng dụng cuối người dùng và truyền các chính sách mạng
tính toán được đến tầng dữ liệu. Bộ điều khiển trở thành bộ não tập trung trong
mạng và hoạt động như một hệ điều hành mạng (NOS). Một bộ điều khiển SDN
dịch các yêu cầu ứng dụng khác nhau như nhu cầu QoS, ưu tiên lưu lượng, quản
lý băng thông, v.v. thành các quy tắc chuyển tiếp liên quan được truyền đến các
yếu tố chuyển tiếp mạng tầng dữ liệu. SDN trở thành khả thi để thao tác bảng
dòng lưu trong các yếu tố riêng lẻ trong thời gian thực dựa trên hiệu suất mạng
và yêu cầu dịch vụ bằng cách sử dụng tính linh hoạt mạng thông qua tầng điều
khiển. Tóm lại, bộ điều khiển cung cấp một cái nhìn rõ ràng và tập trung về
mạng cơ sở cung cấp một công cụ quản lý mạng mạnh mẽ để điều chỉnh hiệu
suất mạng. Ngoài ra, tầng điều khiển cung cấp trừu tượng mạng có thể được sử
dụng bởi các ứng dụng mạng để đạt được chức năng cấp cao trong mạng.
Lớp ứng dụng (Application Plane): bao gồm các ứng dụng quản lý mạng như
tường lửa, định tuyến và các ứng dụng khác để thực hiện các chính sách. Một
cái nhìn trừu tượng về mạng cơ bản được trình bày cho các ứng dụng thông qua
API northbound của bộ điều khiển. Mức độ trừu tượng có thể bao gồm các
thông số mạng như throughput, độ trễ và tính sẵn có (availability). Các ứng
dụng yêu cầu kết nối giữa các điểm cuối và sau khi dịch vụ mạng hoặc ứng
dụng liên lạc yêu cầu này cho bộ điều khiển SDN, nó cấu hình tương ứng các
yếu tố mạng riêng lẻ trong lớp mặt dữ liệu để chuyển tiếp lưu lượng hiệu quả.
Quản lý tập trung các yếu tố mạng cung cấp thêm đòn bẩy cho các quản trị viên,
cho phép họ cung cấp số liệu mạng quan trọng để thích nghi chất lượng dịch vụ
và tùy chỉnh định hình mạng khi cần thiết. Ví dụ, trong giai đoạn sử dụng mạng,
một số dịch vụ tốn băng thông như chuyển tệp lớn, phát trực tuyến video, v.v.
có thể được cân bằng tải trên các kênh được dành riêng. Trong các tình huống
khác, chẳng hạn như trong trường hợp khẩn cấp như báo động cháy, dịch vụ
như VoIP có thể kiểm soát mạng, tức là điện thoại ưu tiên hơn tất cả mọi thứ
khác. Hình 3.1 mô tả một sơ đồ đơn giản cho SDN.
3.2 Giao diện và giao thức Southbound (Southbound Interfaces and
Protocols)
Để cấu hình phần chuyển tiếp trong data plane, một SDN controller cần phải
liên lạc với các thiết bị chuyển tiếp. Họ sử dụng các giao diện Southbound để
giao tiếp. Có nhiều giao diện Southbound nổi tiếng, chẳng hạn như OpFlex,
POF, ForCES và OpenFlow. Giao thức Southbound hàng đầu hiện nay là
OpenFlow, được hỗ trợ bởi Cisco, HP, Juniper và IBM. Ngoài các giao diện
Southbound, còn có các giao thức Southbound như OVSDB và OF-CONFIG để
điều khiển hoạt động của các thiết bị chuyển tiếp (ví dụ như tunneling, tắt một
cổng mạng và quản lý hàng đợi). Trong phần này, chúng tôi review OpenFlow
và OVSDB, giao diện và giao thức Southbound được sử dụng trong nghiên cứu
của chúng tôi.
3.2.1 OpenFlow
Giao thức Southbound phổ biến nhất, OpenFlow, được thành lập tại Đại học
Stanford vào năm 2008, và hiện được quản lý bởi Tổ chức Mạng lưới Mở
(ONF) và trở thành chuẩn ngành. OpenFlow là giao thức truyền thông cho phép
bộ điều khiển SDN quản lý trực tiếp lớp mặt dữ liệu và cài đặt các quyết định
chuyển tiếp trên các thiết bị mạng. Bộ điều khiển có thể tạo, loại bỏ và cũng sửa
đổi các mục bảng luồng trong switch bằng giao thức này. Bộ điều khiển giao
tiếp với OpenFlow switch qua kênh bảo mật. Kênh bảo mật là một trong các
giao diện để thiết lập kết nối từ mỗi OpenFlow switch đến bộ điều khiển. Giao
diện này được sử dụng trong việc quản lý và điều tiết switch bởi bộ điều khiển,
thông báo về sự kiện qua switch và gửi các gói tin thông qua switch. Giao diện
này có thể khác nhau tùy thuộc vào cài đặt của OpenFlow switch. Tuy nhiên,
giao thức OpenFlow chuẩn được yêu cầu để gửi mỗi message qua kênh bảo mật.

Như được mô tả trong Hình 3.2, một OpenFlow switch là một switch phần mềm
bao gồm một hoặc nhiều bảng luồng được sắp xếp theo pipeline, một bảng
nhóm thực hiện tìm kiếm và chuyển tiếp gói tin, và một kênh OpenFlow kết nối
đến một bộ điều khiển bên ngoài. Bảng luồng là một bảng tìm kiếm với các
trường khớp và hành động, được xử lý như một pipeline. Bảng luồng được xếp
chồng lên nhau chứa các luồng dữ liệu, được định nghĩa sau đó. Một luồng dữ
liệu sẽ khớp với bảng luồng đầu tiên, và có thể được chuyển tiếp đến một cổng
hoặc một bảng luồng khác. Đây là những gì chúng ta hiểu là "pipelined"; các
luật khớp luồng xảy ra theo thứ tự, giống như nước chảy qua ống.
Một luồng dữ liệu là một "chuỗi các gói tin được gửi từ một nguồn cụ thể đến
một đích unicast, anycast hoặc multicast mà nguồn mong muốn đánh dấu là một
luồng". Các phân loại luồng thường dựa trên 5-tuple gồm địa chỉ đích, địa chỉ
nguồn, giao thức, cổng đích, cổng nguồn. Lợi ích chính của định tuyến dựa trên
luồng dữ liệu là loại bỏ nhu cầu thực hiện tìm kiếm trong bảng định tuyến trên
cơ sở từng gói tin. Tìm kiếm tuyến đường có thể được thực hiện cho gói tin đầu
tiên trong một luồng, sau đó áp dụng chuyển đổi tương tự cho mỗi gói tin trong
chuỗi. Bảng luồng dễ dàng được triển khai trong phần cứng, và hầu hết các nhà
cung cấp hỗ trợ một số hình thức khớp luồng dữ liệu trên bộ nhớ trung gian tìm
kiếm ba chiều (ternary content-addressable memory - TCAMs) phần cứng hoặc
phần mềm.
Trong mô hình SDN, OpenFlow được sử dụng làm mặt phẳng dữ liệu xử lý các
hoạt động chuyển tiếp gói tin cho bộ điều khiển OpenFlow. Bảng dòng luồng
(flow table) được sử dụng để xử lý tìm kiếm và chuyển tiếp các gói tin. Như
được thể hiện trong Hình 3.3, một mục dòng luồng bao gồm các trường tiêu đề
(ví dụ, địa chỉ IP và cổng nguồn và đích) để xác định một luồng duy nhất, các
bộ đếm dùng để thu thập thống kê số lần sử dụng thành công của mục dòng
luồng, các cookie được sử dụng để chú thích bởi bộ điều khiển SDN, các thời
gian chờ để điều khiển thời gian duy trì của một mục dòng luồng trong bảng
dòng luồng, và độ ưu tiên giúp switch lựa chọn giữa các luồng khớp (nếu có).
Cuối cùng, các hành động xác định chính sách cho các gói tin khớp thành công.
Để làm rõ, khi một gói tin đến switch, switch bắt đầu tìm kiếm khớp và mục
dòng luồng khớp sẽ xác định hành động, ví dụ chuyển tiếp gói tin đến một cổng
cụ thể. Khi nhận được một gói tin, thiết bị chuyển tiếp quét các bảng dòng
luồng, bắt đầu từ bảng 0 (đó là bảng dòng luồng bắt buộc), để tìm kiếm các mục
dòng luồng khớp. Nếu không có match nào trong bảng luồng dòng 0, switch sẽ
bắt đầu tìm kiếm trong bảng luồng dòng 1 (nếu bảng luồng 1 tồn tại, số bảng
luồng được cấu hình bởi người dùng). Quá trình này sẽ tiếp tục cho đến khi tìm
thấy một match thành công. Trong trường hợp có nhiều match trong một bảng
luồng duy nhất, entry có độ ưu tiên cao hơn sẽ được chọn. Các thiết bị thực hiện
hành động (tức là chuyển tiếp gói tin đến một cổng cụ thể) được xác định trong
entry luồng. Cũng có một entry luồng đặc biệt được gọi là entry luồng thiếu
bảng với độ ưu tiên là 0, phù hợp với tất cả các gói tin. Entry này bắt lấy tất cả
các luồng không phù hợp. Entry này có thể điều khiển thiết bị để loại bỏ các gói
tin không xác định hoặc gửi chúng đến bộ điều khiển. Bộ điều khiển có thể cài
đặt một entry luồng mới trên các switch cho luồng hoặc có thể loại bỏ gói tin.
Hãy tưởng tượng rằng đây là một quy tắc if-then trong một bộ định tuyến L3
(lớp 3). Nếu khung khớp với bộ 5-tuple này, thì chúng ta áp dụng tập hành động
này. Một bộ định tuyến L3 là một bộ định tuyến thực hiện quyết định chuyển
tiếp dựa trên lưu lượng dữ liệu mạng L3. Gói tin L3 đến và được gửi đến bảng
dòng luồng nhập, được khớp với table-miss flow entry. Sau đó, flow entry này
sẽ chuyển tiếp gói tin đến bộ điều khiển để tìm đường đi. Bộ điều khiển tìm ra
next-hop thích hợp và giao diện mạng phù hợp, và đẩy một flow entry mới đến
OpenFlow switch cho gói tin này và chuyển tiếp nó ra khỏi giao diện mạng
thích hợp. Gói tin tiếp theo trong luồng đó sẽ khớp với flow entry mới được đẩy
xuống OpenFlow switch, sau đó áp dụng hành động đến gói tin, chuyển tiếp nó
ra khỏi cùng một giao diện mạng mà gói tin trước đó đã được gửi và áp dụng
cùng một hành động. Chỉ có gói tin đầu tiên trong một luồng mới làm cho việc
tìm đường đi, tăng tốc xử lý gói tin.
3.2.2 Bảng luồng dữ liệu OpenFlow (OpenFlow Flow Table)
Bảng luồng dữ liệu là một bảng tra cứu có các trường tương ứng và hành động
và được xử lý như pipeline. Khi khung dữ liệu vào cổng, nó được xử lý bởi
Bảng 0 bằng mục nhập luồng tương ứng có độ ưu tiên cao nhất. Mục nhập
luồng này sẽ chứa một tập hành động có thể xuất khung dữ liệu đến một cổng
cụ thể, áp dụng các hành động hoặc gửi khung dữ liệu đến một bảng khác.
Trong trường hợp bảng không tìm thấy tương ứng, khung dữ liệu sẽ bị bỏ qua
bởi switch. Bảng luồng dữ liệu bao gồm các trường sau. Hãy nhớ rằng một bộ
định tuyến luồng dữ liệu bao gồm một bảng tra cứu và một tập hành động; đây
là bảng tra cứu tìm kiếm trên các trường khác nhau trong tiêu đề gói tin.
Loại Mô tả
Match Fields Tiêu chí khớp cho các khung (frames). Bao gồm dữ
liệu header và thông tin metadata. Các trường khớp
được đặt trên bảng luồng (flow table) để xác định
gói tin mà một hành động sẽ được thực hiện. Điều
này bao gồm thông tin 5-tuple và một số tiêu chí bổ
sung khác cũng có thể được sử dụng.
Độ ưu tiên (Priority) Độ ưu tiên cho tiêu chí khớp. Các khớp xảy ra theo
thứ tự độ ưu tiên. Hữu ích cho việc định nghĩa các
mục ngoại lệ và các mục mặc định trong đường ống
bảng luồng.
Bộ đếm (Counters) Đếm số lượng khớp
Hướng dẫn Xác định những gì sẽ được thực hiện với khung sau
(Instructions) khi khớp; có một hoặc nhiều hướng dẫn này.
Thời gian chờ Xác định thời gian một luồng có thể tồn tại trong
(Timeouts) switch. Thời gian chờ mềm xác định bao lâu luồng
sống nếu không có khung khớp. Thời gian chờ
cứng xác định bao lâu luồng sống bất kể số lượng
khớp.
Cookie Trường được định nghĩa bởi controller. Không
được sử dụng trong xử lý gói tin nhưng hữu ích để
lọc thống kê luồng.
 Bảng 3.1: OpenFlow Flow Table Field
3.2.3 Các loại tin nhắn OpenFlow (OpenFlow Messages Types)
Có ba loại chung của tin nhắn OpenFlow: tin nhắn điều khiển-tới-điều khiển,
bất đồng bộ và đối xứng. Bên điều khiển sử dụng các tin nhắn điều khiển-tới-
điều khiển để truy vấn thông tin từ, truyền gói tin tới hoặc cấu hình switch.
Thông thường, bên điều khiển khởi tạo tin nhắn điều khiển-tới-điều khiển với
hoặc không yêu cầu phản hồi từ switch. Ngược lại, các tin nhắn bất đồng bộ
được gửi mà không có yêu cầu từ bên điều khiển. Ví dụ về chúng là tin nhắn
packet-in, flow-removed, port-status và packet-out. Các tin nhắn đối xứng yêu
cầu phản hồi từ bên nhận. Ví dụ về chúng là tin nhắn hello, error, echo và
experimenter. OpenFlow xác định một đặc tả mà người dùng có thể sử dụng để
truyền thông với các switch OpenFlow, và công nghệ này sẽ được sử dụng trong
luận án này để cung cấp cơ chế để chèn luồng vào các switch này.
3.3 SDN Controller cho mặt phẳng điều khiển (SDN Controller for the
Control Plane)
Trong kiến trúc SDN, bộ điều khiển hoạt động như não của mạng và nó là nơi
chứa Mặt điều khiển như được miêu tả trong Hình 3.1. Bộ điều khiển là một
phần mềm đóng vai trò là trung tâm điều khiển tập trung giám sát mạng và qua
đó các ứng dụng có thể truy cập và quản lý mạng. Khi nói rằng bộ điều khiển là
trung tâm của mạng, điều này chỉ có ý nghĩa tập trung về mặt logic. Phần mềm
bộ điều khiển thường được triển khai trên một máy chủ có hiệu suất cao, nhưng
để phân phối tải hoặc đảm bảo tính khả dụng cao và sự bền vững, có thể có
nhiều máy chủ được kết nối với nhau theo các topo khác nhau.
Bộ điều khiển có trách nhiệm thực hiện các nhiệm vụ sau:
• Phát hiện thiết bị: bộ điều khiển quản lý việc phát hiện các switch và thiết bị
người dùng cuối và quản lý chúng.
• Theo dõi topologia mạng: bộ điều khiển khám phá các liên kết nối các thiết bị
trong mạng và duy trì một cái nhìn về các tài nguyên cơ bản.
• Quản lý luồng: bộ điều khiển duy trì một cơ sở dữ liệu phản ánh các mục
luồng được cấu hình trong các switch nó quản lý.
• Theo dõi thống kê: bộ điều khiển thu thập và lưu trữ các thống kê theo mức
luồng từ các switch.
Cần nhấn mạnh rằng bộ điều khiển không điều khiển mạng theo bất kỳ cách nào
và cũng không thay thế bất kỳ thiết bị mạng nào. Ngay cả chức năng chuyển
mạch hoặc định tuyến cơ bản cũng phải được cung cấp bởi các ứng dụng cụ thể
sử dụng bộ điều khiển để tiếp cận mạng. Giao tiếp với các thiết bị mạng được
thực hiện thông qua một southbound interface, trong đó Open SDN khuyến
khích sử dụng giao thức OpenFlow. Các giao diện này được sử dụng để cấu
hình và quản lý các switch và để nhận thông điệp từ chúng. Kết nối được thực
hiện thông qua một kênh an toàn và tùy thuộc vào cài đặt, có thể được mã hóa
hoặc không được mã hóa.
Ứng dụng giao tiếp với bộ điều khiển thông qua northbound interface. Qua giao
diện này, chúng lấy thông tin về mạng và gửi các yêu cầu của mình, trong khi
bộ điều khiển sử dụng nó để chia sẻ thông tin về các sự kiện xảy ra. Tùy thuộc
vào việc triển khai, giao diện có thể là cấp thấp, cung cấp truy cập thống nhất
vào từng thiết bị riêng lẻ, hoặc là cấp cao, trừu tượng hóa phần lớn lớp bên dưới
và đại diện cho mạng như một tổng thể. Hiện nay không có tiêu chuẩn cho
northbound interfacevà mỗi bộ điều khiển triển khai API riêng của mình - có thể
là Java API, Python API, REST API hoặc bất cứ cái gì khác. Thiếu tiêu chuẩn
northbound interface này hiện nay làm cho việc tạo các ứng dụng độc lập với bộ
điều khiển trở lên khó khăn.
3.4. Software Switch cho Data Plane
Bảng 3.2 tóm tắt các lệnh Software Switch mà được sử dụng để thử nghiệm
và phát triển dịch vụ mới.

Switch Ngôn ngữ sử Mô tả

dụng
Open vSwitch C/Python Ngăn xếp OpenFlow được sử dụng
như một Switch ảo và được chuyển
sang nhiều nền tảng phần cứng
Ofsoftswitch1 C/C++ Thực hiện chuyển đổi phần mềm
3 không gian người dùng
Bảng 3.2. OpenFlow Software Switches phổ biến
3.4.1. Open vSwitch
OpenFlow có thể được triển khai ở cấp độ phần mềm hoặc cấp độ phần
cứng trên các thiết bị chuyển tiếp trong data plane. Cụ thể hơn, nhiều nhà
cung cấp mạng nổi tiếng như Cisco, Juniper, IBM và HP, hỗ trợ OpenFlow,
bằng sản phẩm chuyên dụng hoặc chạy một Openflow software switch trên
các switches của họ. Open vSwitch là một trong những software switches
được triển khai để hỗ trợ OpenFlow, có thể được cài đặt để kích hoạt
OpenFlow. Open vSwitch là một software switch đa lớp nhằm hoạt động
như một switch ảo. Open vSwitch hỗ trợ tất cả các phiên bản OpenFlow từ
1.0 đến 1.5 cũng như GRE tunneling, hàng đợi, v.v. Cốt lõi của Open
vSwitch là daemon chuyển đổi (ovs-vswitchd). Daemon này theo dõi các
truy vấn thống kê và quản lý luồng nội bộ trên switch, đồng thời xử lý giao
tiếp với các thiết bị và dịch vụ bên ngoài. Để quản lý và cấu hình, song song
với khả năng kết nối với Openflow controller , có thể cấu hình và điều khiển
Open vSwitch thông qua ovs-vsctl và ovs-ofctl. Ovs-vsctl là công cụ dòng
lệnh để định cấu hình ovs vswitchd bằng cách cung cấp giao diện cho cơ sở
dữ liệu cấu hình của nó, trong khi ovs-ofctl là công cụ dòng lệnh để giám
sát và quản trị Open vSwitch. Hơn nữa, màn hình ovsdb là một công cụ để
xem các Flow Table và databases của Open vSwitch. Như được minh họa
trong Hình 3.4, ovsdb-server dựa vào giao thức Quản lý OVS để giao tiếp
với database Open vSwitch từ xa ( databases được duy trì bởi Open vSwitch
để lưu trữ thông tin của nó). Không giống như các flow entries trong switch
cấu hình OVSDB được giữ nguyên ngay cả sau khi Switch khởi động lại.

Hình 3.4. Hình 3.4 Kiến trúc Open vSwitch đơn giản
3.4.2. OfSoftSwitch (CPqD)
OfSoftSwitch13 (CPqD) là một switch khác được sử dụng rộng rãi trong
cộng đồng nghiên cứu. Đây là một switch thử nghiệm được phân nhánh từ
triển khai SoftSwitch của Ericsson Traffic Lab 1.1 với những thay đổi trong
forwarding plane để hỗ trợ OF1.3. Ofsoftswitch13 đang chạy trong không
gian người dùng và nó cũng hỗ trợ nhiều phiên bản OpenFlow.
Ofsoftswitch13 hỗ trợ nhiều tính năng OpenFlow nhưng gần đây nó đã gặp
phải một số vấn đề về khả năng tương thích với các phiên bản Linux mới
nhất (Ubuntu 14.0 trở lên) và hỗ trợ nhà phát triển cũng bị đình trệ. Nó được
đi kèm với các công cụ sau để kiểm soát và quản lý mặt phẳng dữ liệu:
+ OfDatapath: Triển khai switch
+ OfLib: Một thư viện để chuyển đổi sang/từ OF1.3 wire formats.
+ DPCTL: Công cụ điều khiển để cấu hình switch
+ OfProtocol: Kênh giao tiếp an toàn với Controller
Tất cả điều này làm cho nó trở thành một sự thay thế hoàn toàn cho OVS.
Tuy nhiên, các tác giả của switch cho biết như sau: “Mặc dù thực tế là
 switch vẫn phổ biến đối với những nhà phát triển đang cố gắng thực hiện
các thay đổi của riêng mình đối với OpenFlow, hỗ trợ hiện đang dựa trên
“best-effort”. Hiện tại, có rất nhiều lời phàn nàn về hiệu suất giảm sút, các
tính năng bị hỏng và các vấn đề cài đặt.”. Switch vẫn có một trong những
hỗ trợ tốt nhất cho các tính năng OF1.3 trong số các soft-switch hiện có, đặc
biệt là các tính năng tùy chọn như meter tables v.v., khiến nó trở thành một
lựa chọn hấp dẫn để bắt tay vào sử dụng. Ngoài ra, soft switch hỗ trợ tiện
ích quản lý có tên là Data Path Control (Dpctl), để điều khiển trực tiếp
Openflow switch bao gồm thêm và xóa luồng, thống kê chuyển đổi truy vấn
và sửa đổi cấu hình Flow Table.
3.5. Loại bỏ luồng và trục xuất
Có thể xóa các luồng khỏi Controller bằng 3 cách: : theo yêu cầu của
controller,hết hạn hoặc thông qua cơ chế loại bỏ switch. Cơ chế hết hạn của
Flow switch xác định thời gian chờ quá lâu và thời gian chờ không hoạt
động. Thời gian chờ không hoạt động gây ra trục xuất khi và chỉ khi không
có frames nào được nhìn thấy trong khoảng thời gian đó. Thời gian chờ quá
lâu gây ra việc trục xuất bất kể có được nhìn thấy hay chưa. Controller cũng
có thể gửi thông báo DELETE gây ra việc loại bỏ luồng. Cơ chế loại bỏ
Flow Switch cho phép switch loại bỏ các luồng để lấy lại tài nguyên. Sau
khi xóa, một thông báo FLOW REM có thể được gửi tùy chọn nếu cờ
SEND FLOW REM được đặt trong flow entry. Thông báo này được sử
dụng để thông báo cho Controller luồng đã bị loại bỏ để Controller có thể
giữ số liệu thống kê hoặc đưa ra quyết định dựa trên thông tin này.
3.6. Tóm tắt chương
Chương này đã xem xét chi tiết các công nghệ SDN. Các giao diện truyền
thông Northbound và Southbound cho phép một số giao thức chính được sử
dụng trong SDN Framework Các giao thức như OpenFlow trên Southbound
và API RESTful trên giao diện Northbound controller đã được áp dụng
đáng kể trong cả nghiên cứu học thuật và công nghiệp. Ngoài các giao thức
truyền thông, những năm gần đây cũng chứng kiến sự phát triển của một số
nền tảng controller quan trọng nhằm thúc đẩy mô hình SDN và mang lại sự
đa dạng kỹ thuật đáng kể cho các nhà nghiên cứu và nhà khai thác để thử
nghiệm và khám phá.

Chương 4. End-to-end QoS

Quality of Service (QoS) trong SDN là một lĩnh vực đang được nghiên cứu và
ngày càng được cộng đồng nghiên cứu quan tâm. Không có định nghĩa tiêu
chuẩn hoặc chính thức về QoS. Tuy nhiên, có một số định nghĩa ở cấp độ giao
tiếp mà khái niệm này bắt nguồn để mô tả các đặc tính kỹ thuật nhất định của
việc truyền dữ liệu. Trong chương này, khái niệm truyền thống về QoS ở cấp độ
mạng được giới thiệu và một số công trình nghiên cứu thú vị được tóm tắt trong
lĩnh vực QoS trong SDN. Hơn nữa, phân loại các ứng dụng và yêu cầu QoS của
chúng được trình bày trong chương này
4.1. QoS
Quality of Service (QoS) là khả năng đáp ứng yêu cầu của lưu lượng truy
cập cụ thể. Rất nhiều ứng dụng mạng ngày nay yêu cầu đảm bảo QoS nhất
định. Ví dụ: một ứng dụng như truyền phát video yêu cầu độ trễ nhỏ nhưng
giao tiếp dữ liệu yêu cầu tỷ lệ mất packet ít hơn do nó ít nhạy cảm với độ trễ
hơn. Việc không đáp ứng tiêu chuẩn này có thể làm giảm chất lượng trải
nghiệm.
Các mạng dựa trên Standard Internet Protocol (IP) cung cấp các dịch vụ
mạng dựa trên mô hình phân phối “best-effort”. Không có đảm bảo về băng
thông hoặc độ trễ trong mô hình phân phối “best-effort” vì mô hình này cung
cấp dịch vụ phân phối point-to-point để phân phối dữ liệu tới đích của họ
càng sớm càng tốt. Sự đảm bảo cao nhất mà mạng cung cấp là phân phối dữ
liệu đáng tin cậy bằng cách sử dụng các giao thức, chẳng hạn như TCP. Mặc
dù điều này có thể chấp nhận được đối với các ứng dụng truyền thống như
Telnet và FTP, nhưng điều này là không đủ đối với các ứng dụng yêu cầu
đảm bảo tính kịp thời.
Tăng băng thông là một giải pháp phổ biến để đáp ứng đầy đủ các ứng dụng
thời gian thực như VoIP, nhưng nó vẫn không đủ để vượt qua hiện tượng
giật hình trong các đợt bùng nổ lưu lượng. Các dịch vụ IP phải được bổ sung
để cung cấp một số mức chất lượng thích hợp cho các ứng dụng thời gian
thực. Thông thường, điều này đòi hỏi phải mở rộng phần mềm mạng để cung
cấp một mức chất lượng nhất định trong khả năng mất packet, rung và trễ.
Đó chính xác là những gì mà các giao thức Quality of Service (QoS) được
thiết kế để thực hiện. Mặc dù QoS cung cấp khả năng quản lý băng thông
nhưng nó không thể tạo ra băng thông. Quản trị viên mạng có thể định cấu
hình QoS đúng cách và được sử dụng hiệu quả hơn để đáp ứng nhiều yêu
cầu ứng dụng. Mục tiêu chính của QoS là cung cấp một số mức độ dự đoán
và kiểm soát ngoài dịch vụ “best-effort” của IP hiện tại.
4.2. Ứng dụng QoS
Tại thời điểm hiện tại, khái niệm chính về QoS mở rộng từ cấp độ giao tiếp
cho đến cấp độ ứng dụng, để ánh xạ các yêu cầu ứng dụng QoS thành các
tham số QoS cấp thấp. Cho đến nay, QoS đã được chỉ định dưới dạng tài
nguyên hệ thống (CPU, sử dụng bộ nhớ) hoặc tài nguyên mạng (băng thông,
độ trễ) và cơ sở hạ tầng mạng đã được triển khai để hỗ trợ QoS thời gian
thực và độ trễ được kiểm soát từ đầu đến cuối.
4.3. Cung cấp QoS trong mạng truyền thống
Cung cấp QoS qua Internet là cần thiết để đảm bảo hiệu suất cao cho các ứng
dụng khác nhau. Có hai cách tiếp cận chính để hỗ trợ QoS vào mạng dựa
trên IP:
+ Dự trữ tài nguyên: Dự trữ tài nguyên là một trong những cách tiếp cận để
cung cấp đảm bảo QoS từ đầu đến cuối trên mỗi luồng bằng cách phân bổ tài
nguyên băng thông mạng để đảm bảo QoS cho một luồng cụ thể (ví dụ:
phiên truyền phát video). Theo yêu cầu QoS của ứng dụng, tài nguyên mạng
được phân bổ và tuân theo chính sách quản lý băng thông.
+ Ưu tiên: Ưu tiên là một trong những cách tiếp cận để phân loại lưu lượng
mạng và phân bổ tài nguyên mạng theo tiêu chí chính sách quản lý băng
thông. Để kích hoạt QoS, các phần tử mạng dành ưu tiên cho các phân loại
được xác định là có nhiều yêu cầu khắt khe hơn.
Ngay cả các ứng dụng khác nhau chạy trên cùng một hệ thống phân loại
cũng có thể có các yêu cầu QoS khác nhau với các giá trị tham số khác nhau.
Hơn nữa, một số tham số QoS này có thể phụ thuộc vào thời gian nhưng có
thể không độc lập lẫn nhau. Có một số giao thức và thuật toán QoS khác
nhau để đáp ứng nhu cầu về các loại QoS khác nhau này:
+ ReSerVation Protocol (RSVP): RSVP là một giao thức tầng vận chuyển có
thể cung cấp tín hiệu để cho phép đặt trước tài nguyên mạng. Bằng cách sử
dụng RSVP, người nhận bắt đầu đặt trước tài nguyên mạng bằng cách gửi tin
nhắn và lượng đặt trước đảm bảo thỏa mãn các ràng buộc về băng thông,
thời gian và kích thước bộ đệm. Dọc theo đường dẫn đã chọn đến người gửi,
đặt trước được thiết lập ở trạng thái mềm và đặt các tài nguyên cần thiết sang
một bên. Trạng thái mềm được người nhận làm mới định kỳ nếu không nó sẽ
hết thời gian hủy đặt trước. RSVP thường được sử dụng trên cơ sở mỗi
luồng và cũng được sử dụng để dự trữ tài nguyên cho các tập hợp.
+ Differentiated Services (DiffServ): DiffServ được phát triển để cung cấp
một cách đơn giản và thô sơ để phân loại và ưu tiên các tập hợp luồng lưu
lượng mạng. Ở bước đầu tiên, DiffServ phân loại tất cả các luồng thành một
số lớp giới hạn và xác định một “hành vi per-hop” khác nhau cho mỗi lớp.
Để xác định các hành vi per-hop, phải mất 6 bit từ vùng Type-of-Service
(TOS) trong IP Header. Sau đó, một hồ sơ lưu lượng truy cập nhất định được
tạo bởi khách hàng và trả nó cho nhà cung cấp mạng. Các gói khách hàng
được đánh dấu bởi các Edge Routers. Khi các gói đến Core Router, Core
Router sẽ biết phải làm gì bằng cách xem mã 6-bit hành vi per-hop từ IP
Header.
+ Multi-Protocol Labeling Switching (MPLS): MPLS là công nghệ chuyển
tiếp dữ liệu cung cấp khả năng quản lý băng thông cho các tập hợp luồng
thông qua điều khiển định tuyến mạng theo nhãn trong Packet Headers.
+ Subnet Bandwidth Management (SBM): SBM là sơ đồ báo hiệu cho phép
phân loại và ưu tiên ở lớp Data Link (Lớp 2) trên các mạng IEEE 802 được
chia sẻ.
4.4. Cung cấp QoS trong SDN
Dù cho tính hiệu quả của QoS-guarantee do IntServ và DiffServ cung cấp,
đảm bảo QoS vẫn là một thách thức trên quy mô lớn. Thách thức này về cơ
bản khái niệm hóa để quản lý tài nguyên và kiểm soát lưu lượng truy cập.
Kiến trúc Internet hiện tại dựa trên các giao thức mạng phân loại chạy trên
các phần tử mạng (ví dụ: Switches và Routers). Việc sử dụng các giao thức
phân loại và điều phối các thay đổi trong các mạng thông thường vẫn cực kỳ
phức tạp để cấu hình và lập chính sách trên phần cứng mạng cơ bản nhằm
kích hoạt nhiều dịch vụ từ định tuyến và chuyển mạch lưu lượng. Việc duy
trì trạng thái của một số thiết bị mạng và cập nhật chính sách trở nên khó
khăn hơn khi các chính sách ngày càng tinh vi được triển khai thông qua một
tập hợp các lệnh cấu hình cấp thấp có giới hạn trên phần cứng mạng thông
thường. Do đó, các cấu hình sai thường xuyên như điều kiện lưu lượng thay
đổi đòi hỏi phải can thiệp thủ công nhiều lần để cấu hình lại mạng, tuy nhiên,
các công cụ có sẵn có thể không đủ tinh vi để cung cấp đủ mức độ chi tiết và
tự động hóa nhằm đạt được cấu hình tối ưu.
4.5. Hỗ trợ QoS trong các phiên bản OpenFlow khác nhau
OpenFlow đã hỗ trợ khái niệm QoS ngay từ đầu. Tuy nhiên, sự hỗ trợ đã bị
hạn chế. Khi các phiên bản mới của OpenFlow xuất hiện trong nhiều năm,
mỗi bản phát hành mới của OpenFlow đều mang đến các tính năng mới hoặc
cập nhật các tính năng hiện có. Trong tiểu mục này, chúng tôi tóm tắt những
gì thay đổi từng đặc tả OpenFlow được thực hiện liên quan đến các tính năng
QoS. Các phiên bản đầu tiên của OpenFlow OF1.0 - OF1.1 được hỗ trợ hàng
đợi với tỷ lệ tối thiểu. OF1.2+ bắt đầu hỗ trợ hàng đợi với cả tỷ lệ tối thiểu
và tối đa. Hàng đợi OpenFlow có sự hỗ trợ rộng rãi trên diện rộng. Hầu hết
các triển khai chuyển đổi phần mềm phổ biến (ví dụ: OVS và CPqD
OfSoftSwitch) và nhiều nhà cung cấp phần cứng (ví dụ: HP 2920 và Pica8 P-
3290) đều hỗ trợ hàng đợi OpenFlow.
 Openflow Tính năng cụ thể
1.0 Enqueue action, thuộc tính tốc độ tối thiểu cho hàng đợi và
các trường tiêu đề mới
1.1 Kiểm soát nhiều hơn đối với VLA và MPLS
1.2 Thuộc tính tốc độ tối đa cho hàng đợi và hàng đợi truy vấn
của Controller từ các Switches
1.3 Giới thiệu meter table, giới hạn tỷ lệ và tính năng giám sát
tỷ lệ
1.4 Giới thiệu một số tính năng giám sát
1.5 Thay thế meter action thành meter instruction
Bảng 1. Các tính năng liên quan đến QoS trong các phiên bản OpenFlow
khác nhau

OF1.3 đã giới thiệu khái niệm meter tables để đạt được QoS chi tiết hơn
trong các mạng OpenFlow. Trong khi các hàng đợi kiểm soát tốc độ đầu ra
của lưu lượng, các meter tables có thể được sử dụng để theo dõi tốc độ của
lưu lượng trước khi xuất. Nói cách khác, hàng đợi kiểm soát tốc độ đi ra và
meter table có thể được sử dụng để kiểm soát tốc độ đi vào của lưu lượng
truy cập. Điều này làm cho hàng đợi và meter table bổ sung cho nhau.
OpenFlow Switches cũng có khả năng đọc và ghi các bit Type of Service
(ToS) trong IP Header . Nó là một trường có thể được sử dụng để khớp với
một Packet trong một flow entry. Tất cả các tính năng này cùng nhau cho
phép quản trị viên mạng triển khai QoS trong mạng của họ. Bảng 1 sau đây
tóm tắt các tính năng liên quan đến QoS trong các phiên bản OpenFlow.
4.5.1. Hàng đợi
Như đã đề cập trước đó, giao thức OpenFlow đã mô tả hàng đợi giới hạn tốc
độ tối thiểu trong OF1.0 và hàng đợi giới hạn tốc độ tối thiểu và tối đa trong
OF1.2. Theo đặc tả OpenFlow, OpenFlow sử dụng hàng đợi trên các
Switches nhưng không xử lý việc quản lý hàng đợi trên nó. Việc quản lý
hàng đợi trên switch diễn ra bên ngoài giao thức OF và bản thân giao thức
OF chỉ có thể truy vấn số liệu thống kê hàng đợi từ switch. Có hai giao thức
để cung cấp tác vụ quản lý hàng đợi (tạo, xóa và thay đổi) trong các
Switches hỗ trợ OpenFlow: OF-Config và OVSDB. Bên cạnh đó, có một
hàng đợi tiêu chuẩn quản lí được cung cấp bởi bất kỳ OpenFlow Controller
nào.
 4.5.2. OVSDB
OF-Config và OVSDB là hai giao thức Southbound để điều khiển hoạt động
của các thiết bị chuyển tiếp ngoài các quyết định chuyển tiếp. Cụ thể,
OVSDB quản lý các hoạt động chuyển mạch như tạo đường hầm, chuyển đổi
trạng thái cổng, cấu hình hàng đợi và quản lý QoS. OVSDB sử dụng nhiều
bảng để quản lý Open vSwitch. Các bảng này bao gồm bảng luồng, bảng
cổng, bảng NetFlow và các bảng khác. Tương tự, nó duy trì các bảng cho
QoS và Hàng đợi. Trong khi hầu hết các bảng khác là bảng gốc của lược đồ
OVSDB, nghĩa là bảng và các mục nhập của nó sẽ không tự động bị xóa nếu
không thể truy cập được. Do đó, QoS và các bảng đợi tồn tại và có thể được
thay đổi độc lập, cho dù chúng có được tham chiếu bởi một cổng hay không.
Bảng cổng có liên quan đến bảng QoS và bảng giao diện. Mối quan hệ với
bảng giao diện là bắt buộc, nghĩa là mỗi cổng phải được liên kết với một
giao diện. Tuy nhiên, mối quan hệ với QoS là tùy chọn. Một cổng có thể tồn
tại mà không có cài đặt QoS kèm theo. Một cổng có thể có một bảng QoS có
thể có nhiều hàng đợi được gán cho nó.
Khi QoS và hàng đợi đã được thiết lập trên một Switch các luồng có thể
được chuyển hướng đến một hàng đợi cụ thể bằng cách sử dụng hành động
thiết lập hàng đợi của OpenFlow. Hành động này sẽ chuyển tiếp các luồng
phù hợp với tiêu chí phù hợp vào hàng đợi được đề cập. Nếu có nhiều hơn
một luồng đi qua Switch cùng một lúc, tốc độ tổng hợp của các luồng sẽ
được kiểm soát ở đầu ra theo tốc độ tối thiểu và tốc độ tối đa được xác định
bởi hàng đợi. Chúng ta hãy tìm hiểu sâu hơn một chút về cách hàng đợi được
triển khai trong giao thức OpenFlow và OVS.
Đặc tả OpenFlow nêu các thuộc tính sau về hàng đợi:
+ Tốc độ tối thiểu: Tốc độ dữ liệu tối thiểu được đảm bảo cho một hàng đợi.
Dung lượng được chia sẻ theo tỷ lệ dựa trên tỷ lệ tối thiểu của mỗi hàng đợi.
Khi tốc độ tối thiểu được đặt, Switch sẽ ưu tiên hàng đợi để đạt được tốc độ
tối thiểu đã nêu. Nếu có nhiều hơn một hàng đợi trong một cổng, với tổng
tốc độ tối thiểu cao hơn dung lượng của liên kết, tốc độ của tất cả các hàng
đợi đó sẽ bị phạt.
+ Tốc độ tối đa: Tốc độ dữ liệu tối đa có thể được phép cho một hàng đợi.
Nếu tốc độ thực tế của các luồng lớn hơn tốc độ tối đa của hàng đợi đã nêu,
thì Switch sẽ trì hoãn các Packets hoặc loại bỏ chúng để đáp ứng tốc độ tối
đa.
Mặc dù các thông số kỹ thuật của OpenFlow đề cập đến các nguyên tắc này
cho các Switch tương thích với OpenFlow, nhưng việc triển khai Switch để
nhận ra các tính năng này là tùy thuộc vào quá trình triển khai. Open
vSwitch, dựa trên Linux, sử dụng chương trình Traffic Control(TC) của
Linux để triển khai hàng đợi.
4.5.3. Kiểm soát lưu lượng Linux
Kiểm soát lưu lượng Linux (TC) là một tiện ích Linux được sử dụng để định
cấu hình kiểm soát lưu lượng trong Linux Kernel. TC có thể được sử dụng
để đạt được những điều sau trong Linux Kernel:
+ Định hình lưu lượng: Nó có thể được sử dụng để định hình tốc độ truyền
của lưu lượng đi qua máy chủ Linux hoặc bất kỳ thiết bị nào khác. Nó cũng
có thể làm dịu bất kỳ sự bùng nổ lưu lượng truy cập nào để có trạng thái
mạng tốt hơn
+ Lập lịch trình: Bằng cách lập lịch trình các Packets, có thể đạt được trạng
thái mạng tốt hơn trong quá trình truyền số lượng lớn. Sắp xếp lại và lập lịch
các Packets cũng có thể được gọi là sắp xếp thứ tự ưu tiên, đây là một hiện
tượng được chấp nhận rộng rãi trong QoS.
+ Chính sách: Một số chính sách mạng có thể được triển khai trong TC.
Chính sách này xảy ra khi xâm nhập.
+ Dropping: Lưu lượng truy cập vượt quá băng thông đã xác định cũng có
thể bị drop khi vào hoặc ra, dựa trên mức sử dụng.
TC sử dụng ba loại đối tượng để đạt được điều này: Quy luật hàng đợi
(Qdisc), các lớp và bộ lọc. Bất cứ khi nào kernel cần gửi bất kỳ lưu lượng
truy cập nào đến một giao diện, nó sẽ đưa lưu lượng vào một qdisc. Sau đó
qdisc sẽ gửi đến giao diện sau. Một qdisc đơn giản là một hàng đợi FIFO
đơn giản. Các lớp và bộ lọc được sử dụng để triển khai các nguyên tắc xếp
hàng tinh vi hơn như các nguyên tắc xếp hàng có lớp và không có lớp. Trong
OVS, có hai nguyên tắc xếp hàng phân loại, đó là Hierarchical Token Bucket
(HTB) và Hierarchical Fair Service Curve (HFSC). Cả hai nguyên tắc xếp
hàng này đều cho phép Nguyên tắc xếp hàng theo thứ bậc và mượn băng
thông. Do đó, HTB sẽ được sử dụng trong luận án này để quản lý hàng đợi.
4.5.4. Hierarchical Token Bucket (HTB)
Nói chung, Hierarchical Token Bucket (HTB) là một nguyên tắc xếp hàng
nhằm mục đích thay thế cho Class-Based Queuing (CBQ), một tiêu chuẩn
trong các triển khai TC cũ hơn. Để cho phép kiểm soát chi tiết băng thông
gửi đi trên một liên kết nhất định, HTB sử dụng các khái niệm về nhóm mã
thông báo đa cấp. Trong thuật toán HTB, mã thông báo được tạo ở tốc độ cố
định và được lưu trữ trong bộ chứa dung lượng cố định. Nếu có một mã
thông báo có sẵn trong nhóm, các Packets có thể được xếp hàng hoặc gửi
đến một cổng đầu ra. Trong một Instance HTB, có thể tồn tại nhiều lớp.

Hình 1. Hệ thống phân cấp lớp HTB mẫu

Hình 1 minh họa một hệ thống phân cấp HTB đơn giản để giải quyết vấn đề
sau:
“Hai khách hàng A và B được kết nối internet qua cùng một đường truyền.
Chúng ta cần phân bổ 40Kbps và 60 Kbps cho A và B tương ứng. Vì băng
thông cần được chia nhỏ thành 30Kbps cho WWW và 10Kbps cho các ứng
dụng khác. Mọi băng thông không sử dụng nên được chia sẻ giữa hai khách
hàng.”
Trong ví dụ này, 40Kbps được chỉ định cho A. Nếu mức sử dụng băng thông
của A cho WWW nhỏ hơn băng thông được phân bổ, băng thông không sử
dụng sẽ được sử dụng cho lưu lượng khác nếu được yêu cầu. Tổng số WWW
của A và lưu lượng truy cập khác sẽ không vượt quá 40Kb/giây. Nếu A yêu
cầu tổng cộng ít hơn 40 kbps, thì phần vượt quá sẽ được trao cho B. Tuy
nhiên, chỉ có hai mức phân cấp có thể được sử dụng trong triển khai Hàng
đợi OpenFlow vì một lớp con của một gốc không thể có bất kỳ lớp con nào.
Các thuộc tính quan trọng chung của các lớp HTB như sau:
_ Rate: Đó là tỷ lệ được đảm bảo tối đa cho lớp này và lớp con của nó. Nó
tương đương với Committed Information Rate (CIR).
_ Ceil rate: Đó là tốc độ tối đa mà lớp này được phép gửi.
_ Priority: Nó xác định mức độ ưu tiên của lớp trong đó lớp có mức độ ưu
tiên cao hơn (độ ưu tiên 0 có mức độ ưu tiên cao nhất) được cung cấp băng
thông nhàn rỗi trước. Ưu tiên này không được ảnh hưởng đến tỷ lệ được đảm
bảo của các lớp khác.
Trong OVS, lệnh ovs-vsctl được sử dụng để tạo hàng đợi. Lệnh này tạo một
mục trong OVSDB và sau đó triển khai nó trong Switch bằng Linux TC.
Một ví dụ về tạo QoS và hàng đợi trong cổng OVS được hiển thị bên dưới:

Hình 2. Ví dụ triển khai hàng đợi

Hình 2 cho thấy cách tạo ví dụ về QoS và hàng đợi trong cổng eth1 của
Switch s1. Nó được hiển thị dưới dạng các mục mới trong Queue table và
QoS table trong OVSDB. Sau đó, OVSDB đặt mối quan hệ giữa mục nhập
QoS mới được tạo và mục nhập eth1 trong Port table. Do đó, eth1 phải hoạt
động theo các quy tắc được nêu trong QoS này. Switch gọi ứng dụng TC
trong quá trình này để tạo qdisc và các lớp trong nền.
4.5.5. Meter Table
Meter table là một tính năng mới được giới thiệu trong giao thức OpenFlow
trong OF1.3. Không giống như các hàng đợi được sử dụng để kiểm soát tốc
độ đầu ra, các Meter Table được sử dụng để theo dõi tốc độ đầu vào của các
luồng. Meter Table chứa các mục Meter entries, xác định meter đo lưu
lượng, Meters được liên kết với các luồng hơn là các cổng. Flow entries có
thể chỉ định meter trong hướng dẫn của nó, meter kiểm soát tốc độ tổng hợp
của tất cả các Flow entries liên quan đến nó. Meters đo lưu lượng cho phép
OpenFlow triển khai các kỹ thuật QoS khác nhau, chẳng hạn như giới hạn
tốc độ. Nó có thể được kết hợp với hàng đợi trên mỗi cổng để triển khai các
khung QoS phức tạp như DiffServ.
Mỗi luồng được gắn vào một meter được yêu cầu phải đi qua meter và Meter
bands trước khi nó được chuyển tiếp. Meter đo tốc độ của từng dòng chảy đi
qua, đưa ra các tùy chọn để áp đặt các hoạt động dựa trên tốc độ với sự trợ
giúp của Meters Bands.
Một luồng không bắt buộc phải gắn vào meter entry, nhà phát triển phải chỉ
định dòng nào hoặc loại dòng chảy nào sẽ được gắn vào và đi qua meter.
Một dòng chảy cũng có thể đi qua nhiều meters. Nó không thể được gắn vào
nhiều meters cùng một lúc, nhưng nó có thể được sử dụng liên tiếp. Điều này
được thực hiện thông qua các meter entries khác nhau trong các flow table
khác nhau.
Một meter table entry bao gồm các thành phần sau:
_ Meter Identifier: Đây là mã định danh số nguyên không dấu 32 bit được
các luồng sử dụng để xác định duy nhất meter entry mà nó thuộc về.
_ Meter Bands: Đây là meter đo tốc độ của từng luồng đi kèm, nhưng chính
meter bands giữ các hướng dẫn và thực hiện các hoạt động dựa trên tốc độ
đo được của các luồng. Mỗi Meter Bands chứa các hướng dẫn để xử lý các
Packets liên quan về những việc cần làm khi một luồng đạt đến tốc độ đã
đặt. Meter bands áp dụng các hành động khi tốc độ dòng chảy lớn hơn tốc độ
cài đặt của Meter.
_ Counters (bộ đếm) : Đây là một bộ đếm đơn giản được cập nhật mỗi khi
một Packets được xử lý bởi một Meter. Nó chủ yếu dành cho mục đích thống
kê.
Một Meter có thể xác định nhiều Meter Bands, mặc dù chỉ có 1 meter band
duy nhất có thể được áp dụng mỗi khi một Packet đi qua một meter. Trong
trường hợp một Meter có nhiều meter bands được xác định, chỉ meter band
có tốc độ cài đặt cao nhất nhưng vẫn thấp hơn tốc độ dòng chảy đo được
hiện tại mới được áp dụng. Trong trường hợp tốc độ dòng chảy thấp hơn bất
kỳ tốc độ của meter band đã được cấu hình, sẽ không có hành động nào được
áp dụng.
Có hai loại băng tần để xác định cách một Packet sẽ được xử lý; đó là băng
tần drop và dscp remark. Các băng tần ảnh hưởng đến lưu lượng truy cập
vượt quá tốc độ đã xác định. Băng tần drop sẽ loại bỏ các gói vượt quá tốc
độ được chỉ định trong tốc độ của băng tần. Nó có thể được sử dụng để xác
định một băng tần giới hạn tốc độ. Mặt khác, băng tần DSCP remark được sử
dụng để tăng quyền ưu tiên loại bỏ trường DSCP trong tiêu đề IP. Nó có thể
được sử dụng để thực hiện DiffServ.
4.6. QoS trong SDN Controllers
Một số OpenFlow Controllers cung cấp các công cụ và nền tảng bổ sung để
giúp người dùng cấu hình hàng đợi. . Ở đây, bốn OpenFlow Controllers
nguồn mở nổi tiếng được mô tả cùng với đánh giá về hỗ trợ QoS của chúng.
+ Floodlight, được duy trì bởi Big Switch Networks, là SDN Controller mã
nguồn mở nổi tiếng bằng ngôn ngữ lập trình Java. Đối với cấu hình và quản
lý hàng đợi, mô-đun QoS được xây dựng dựa trên Floodlight dưới dạng mô-
đun cộng đồng, tận dụng hỗ trợ hàng đợi OpenFlow 1.0. Một mô-đun khác
được phát triển là QueuePusher. Nó kiểm soát việc quản lý và cấu hình hàng
đợi bằng cách sử dụng API Floodlight.
+ Ryu là SDN Controller dựa trên thành phần được triển khai bằng ngôn ngữ
lập trình Python. Một trong những ưu điểm chính của Ryu, không giống như
nhiều SDN Controller khác , là nó hỗ trợ tất cả các phiên bản OpenFlow từ
1.0 đến 1.5. Ngoài ra, do thiết kế dựa trên thành phần và hỗ trợ phiên bản
OpenFlow đầy đủ, nó thường được sử dụng để tạo nguyên mẫu nhanh của
mô-đun SDN. Ryu cung cấp API để định cấu hình và quản lý hàng đợi trong
Open vSwitch bằng OVSDB.
+ OpenDaylight (ODL) là một dự án mã nguồn mở hợp tác của Linux
Foundation với mục tiêu quảng bá SDN. Nhiều SDN Controller độc quyền
như bộ điều khiển Brocade SDN dựa trên ODL. Tương tự như Ryu, ODL
cũng có plugin OVSDB giúp người dùng cấu hình và quản lý hàng đợi.
+ Open Network Operating System (ONOS) là một dự án nguồn mở cộng
đồng do Linux Foundation tổ chức với mục tiêu tạo ra một hệ điều hành
SDN có khả năng mở rộng cao, khả dụng cao và hiệu năng cao. Hiện tại,
ONOS hỗ trợ metering trong OpenFlow. Tuy nhiên, không giống như các
SDN Controller đã nói ở trên, hỗ trợ QoS của ONOS còn thiếu nhiều tính
năng và chưa hoàn thiện đầy đủ.
Bảng 2 sau đây tóm tắt các tính năng liên quan đến QoS trong OpenFlow
Controller

Bảng 2. Các tính năng liên quan đến QoS trong các OpenFlow Controller
khác nhau
Trong thử nghiệm, Ryu Controller được chọn, chủ yếu là do kiến trúc dựa
trên thành phần của nó, Northbound API mạnh mẽ và tài liệu tuyệt vời về
QoS.
4.7. Tóm tắt chương
Phần này đã trình bày khái niệm về QoS bao gồm nguồn gốc và tiến trình.
Người ta biết rằng có thể sử dụng nhiều loại kỹ thuật khác nhau để triển khai
các hệ thống QoS trong SDN, nhiều thách thức khác nhau mà cộng đồng
SDN phải đối mặt và các giải pháp khả thi được đề xuất cho một số vấn đề
cấp bách nhất.
Sự xuất hiện của các dịch vụ mạng khác nhau được thực hiện bởi Internet,
cạnh tranh tài nguyên mạng và hầu hết trong số đó yêu cầu đảm bảo hiệu
suất QoS. Rất khó để cung cấp các dịch vụ mạng mới nổi một cách linh hoạt
và đáp ứng lượng nhu cầu khổng lồ với hiệu suất tốt hơn trong mạng hiện
tại. Để giải quyết những vấn đề này, các sơ đồ kỹ thuật lưu lượng cần xem
xét sự kết hợp của các ứng dụng người dùng và các yêu cầu về hiệu suất mà
người dùng cuối có thể gặp phải do cải tiến dịch vụ riêng lẻ.
SDN nhằm mục đích giải quyết vấn đề về tính linh hoạt trong kiến trúc
internet ngày nay và cung cấp cách tiếp cận dựa trên phần mềm để các kỹ
thuật và giao thức mới phát triển mạnh trong hệ sinh thái của nó. Ưu điểm
lớn nhất của SDN là việc thích ứng với nó dễ dàng hơn và tránh xa thiết lập
internet “cứng nhắc” hiện có. Tuy nhiên, để SDN thay thế kiến trúc hiện tại
của mạng trong thế giới thực, nó cần cung cấp khả năng kiểm soát rất chi tiết
cho quản trị viên mạng để kiểm soát chất lượng dịch vụ cùng với một số cải
tiến khác.