Giao thức OpenFlow phiên bản 1.

1. Switch Components

Một SW có thể có nhiều flow table và chỉ có duy nhất một group table.

a. Flow table

OFSW hoạt động theo cơ chế match-and-act tức là khớp và hành động. Khi có một gói tin đi
vào SW sẽ check flow table đầu tiên, nếu có flow entry phù hợp, gói tin sẽ được match với flow
table đó và thực thi các instructions của entry đó lên gói tin. Instructions có thể là chuyển tiếp
gói tin đến flow table tiếp theo. Nếu không có instruction nào được áp dụng cho gói tin, thì điều
này được ngầm hiểu là gói tin đã kết thúc tiến trình của nó và nó sẽ không được gửi tới flow
table tiếp theo.

Các gói tin thông thường được gửi tới một cổng hoặc một interface. Nếu có một điều gì đó ở
phút chót cần phải làm với gói tin khi nó đang được gửi, thì những điều này được gán vào gói
tin dưới dạng action set.

Nếu gói tin không match với bất kỳ một entry nào trong flow table thì điều này gọi là table miss
và gói tin được chuyển tới table miss entry. Tại table miss entry, gói tin có thể được gửi tới
controller hoặc bị drop.

Mỗi flow entry sẽ chứa các trường dưới đây:

- Match Fields: được sử dụng để so khớp với gói tin. Nó bao gồm ingress port,
header và các thông tin của table trước
 - Priority: thứ tự ưu tiên của flow entry

- Counters: để cập nhật cho việc khớp các gói tin

- Instructions: để sửa đổi action set hoặc pipleline processing

- Timeouts: lượng thời gian rảnh tối đa được phép trước khi bị xoá bởi switch

- Cookie: được sử dụng với mục đích giao tiếp với controller. Là một giá trị được
cho bởi controller. Có thể được sử dụng bởi controller cho việc xoá luồng, sửa
luồng.

Quá trình matching gói tin:

b. Group table

Tại sao phải cần group table? Group table như tên của nó đã chỉ ra, Group – nhóm,
nó sẽ thực hiện xử lý gói tin dưới dạng một nhóm các flow entry.

Ví dụ: Có một gói tin cần gửi tới port 1, giả sử port 1 bị down và gói tin sẽ được
chuyển tiếp đến port 2. Tuy nhiên, trong các flow table lại đã lưu tất cả thông tin về
gói tin cho việc định tuyến tới port 1, và để chuyển gói tin tới port 2, chúng ta cần
phải sửa tất cả các flow table này. Việc này là không khả thi, thay vào đó ta sẽ gộp
các flow entry mà liên quan đến việc chuyển gói tin tới port 1 vào một nhóm đưa vào
group table. Port 2 cũng vậy. Group table nhận được gói tin muốn chuyển tới port 1
nhưng port 1 bị down, lập tức nó sẽ chuyển sang port 2. Các flow table sẽ không
cần chỉnh sửa sữa.

Group table chứa các group entry, mỗi group entry sẽ có các trườn sau đây:

- Group Identifier: là một số nguyên 32 bits định danh cho group

- Group type: xác định loại group (all, select, indirect, fast failover)

- Counters: được cập nhật khi có một tiến trình được xử lý bởi group

- Action buckets: Là một danh sách theo thứ tự của các action buckets, mỗi action
bucket chứa các action để thực thi và chứa các thông số liên quan đến việc xử lý gói
tin.

c. Meter table (bảng đồng hồ)

Thực hiện chức năng đo đạc tốc độ của các gói tin được chỉ định và điều khiển tốc
độ của các gói tin này.

d. Instructions

Mỗi flow entry sẽ có một tập các instructions được thực thi khi gói tin khớp với entry
đó. Các instructions sẽ thay đổi action set của gói tin hoặc tiến trình xử lý gói tin.

Một số các instructions buộc phải có trong một switch:

- Write-Actions action(s): Hợp nhất action(s) vào action hiện tại.

- Goto-Table next-table-id: Chuyển tiếp gói tin tới bảng luồng tiếp theo.

Ngoài ra còn các option lựa chọn thêm như:

- Apply-Actions action(s): thực thi action(s) ngay lập tức mà không cần sự thay đổi
nào trong Action Set.

e. Action set:

Action set liên quan trực tiếp đến mỗi gói tin (chứa trong mỗi gói tin). Mặc định, ban
đầu set là rỗng. Flow entry có thể sửa đổi action-set sử dụng instruction Write-Action
action(s) hoặc Clear-Action. Action set được thực hiện giữa các flow tables. Khi
instruction set của một flow entry không chứa Go-to-next table thì tiến trình của gói
tin sẽ kết thúc và action set được thực thi ngay lập tức.
Các actions trong Action Set được thực thi theo thứ tự dưới đây:

- Copy TTL inwards: áp dụng các hành động sao chép TTL với gói tin

- Pop: áp dụng tất cả các thẻ pop với gói tin

- Push-MPLS: áp dụng hành động push thẻ MPLS với gói tin

- Push-PBB: áp dụng hành động push thẻ PBB với gói tin

- Copy TTL outwards: áp dụng hành động sao chép TTL bên ngoài gói tin

- Decrement TTL: Áp dụng hànhd động giảm TTL với gói tin

- Set: áp dụng tất cả các hành động set-field với gói tin (set-field xác định loại
field)

- Qos: áp dụng hành động QOS, ví dụ như set_queue với gói tin

- Group: nếu có một group action xác định, áp dụng các hành động của group
bucket(s) liên quan tới thứ tự đã được xác định trong list bucket đó.

- Output: Nếu không có group action được chỉ định, chuyển tiếp gói tin tới port
được chỉ định bởi output action

Lưu ý: Nếu có cả Group action và Ouput action thì gói tin sẽ được thực thi group
action. Nếu không có cả hai, thì gói tin sẽ bị drop.

f. Action list

Apply-Actions instruction và bản tin Packet-Out bao gồm trong action list.

Các hành động trong một action list được thực thi theo thứ tự xác định và nó được
thực thi ngay lập tức với gói tin.

Sau khi thực hiện xong action list trong câu lệnh Appy-Actions, quá trình xử lý sửa
đổi gói tin sẽ được tiếp thực hiện. Action set của gói tin sẽ không bị thay đổi bởi
action list.

Chú ý: Action list nằm trong Appy-Actions Instruction

g. Actions

SW không yêu cầu hỗ trợ tất cả các loại action, dưới đây là một số actions cần thiết

- Output: Chuyển gói tin tới 1 port (có thể là physical port, logical port hoặc
reserved port)

- Drop: Các gói tin không có output actions sẽ bị drop. Thực thi bởi một instruction
rỗng hoặc sau khi thực thi Clear-Actions Instruction
 - Group: Xử lý gói tin thông qua một nhóm cụ thể

2 OpenFlow Channel
OpenFlow Channel là giao diện kết nối mỗi OpenFlow Switch với một bộ điều khiển.
Thông qua giao diện này, bộ điều khiển cấu hình và quản lý switch, nhận các sự kiện từ Switch
và gửi các gói tin ra ngoài Switch.

2.1 Tổng quan về OpenFlow Protocol

OpenFlow Protocol hỗ trợ 3 loại bản tin: Controller-to-Switch, Asynchronous, và
Symmetric.

2.1.1 Controller-to-Switch

Bản tin Controller/Switch được khởi tạo bởi bộ điều khiển và có thể yêu cầu hoặc không
cần phản hồi từ Switch.

Features: Bộ điều khiển có thể yêu cầu các khả năng của Switch bằng cách gửi yêu
cầu tính năng; Switch phải phản hồi bằng một câu trả lời tính năng chỉ định các khả năng của
Switch.

Configuration: Bộ điều khiển có thể đặt và truy vấn các thông số cấu hình trong Switch.
Switch chỉ phản hồi một truy vấn từ bộ điều khiển.

Modify-State: Các bản tin Modify-State được gửi bởi bộ điều khiển để quản lý trạng thái
trên các Switch.

Read-State: Các bản tin Read-State được bộ điều khiển sử dụng để thu thập các thông
tin khác nhau từ Switch.

Packet-out: Các bản tin packet-out này được bộ điều khiển sử dụng để gửi các packets
ra khỏi một cổng được chỉ định trên switch, và để chuyển tiếp các gói tin nhận được qua các
bản tin Packet-in.

Barrier: Các bản tin yêu cầu/trả lời Barrier được bộ điều khiển sử dụng để đảm bảo các
bản tin phụ thuộc đã được đáp ứng hoặc để nhận thông báo về các hoạt động đã hoàn thành.

Role-Request: Bản tin Role-Request được bộ điều khiển sử dụng để đặt vai trò cho
OpenFlow Channel của nó, hoặc truy vấn vai trò đó.

Asynchronous-Configuration: Bản tin Asynchronous-Configuration được bộ điều

khiển sử dụng để đặt bộ lọc bổ sung trên các bản tin không đồng bộ mà nó muốn nhận trên
OpenFlow Channel của nó hoặc để truy vấn bộ lọc đó.

2.1.2 Asynchronous
 Các bản tin Asynchronous được gửi mà không có bộ điều khiển thu hút chúng từ một
Switch. Switchs gửi các bản tin Asynchronous đến bộ điều khiển để biểu thị một gói tin đến,
thay đổi trạng thái chuyển mạch, hoặc lỗi. Bốn loại bản tin Asynchronous chính được mô tả bên
dưới.

Packet-in: Chuyển quyền điều khiển một packet đến bộ điều khiển.

Flow-Removed: Thông báo cho bộ điều khiển về việc loại bỏ một flow entry khỏi flow
table.

Port-status: Thông báo cho bộ điều khiển về sự thay đổi trên một cổng.

Error: Switch có thể thông báo cho bộ điều khiển về các sự cố bằng cách sử dụng các
bản tin error.

2.1.3 Symmetric

Các bản tin Symmetric được gửi đi mà không cần thu hút, theo cả hai hướng.

Hello: Các bản tin Hello được trao đổi giữa switch và bộ điều khiển khi khởi động kết
nối.

Echo: Bản tin yêu cầu/trả lời bằng echo có thể được gửi từ Switch hoặc bộ điều khiển
và phải trả lại phản hồi echo.

Experimenter: Bản tin Experimenter cung cấp cách thức chuẩn cho các OpenFlow
switches để cung cấp chức năng bổ sung trong bản tin OpenFlow.

2.2 Message Handling

Hành vi xử lý bản tin OpenFlow được mô tả trong phần này được cung cấp trên kết nối
chính và kết nối phụ sử dụng phương tiện truyền tải đáng tin cậy, tuy nhiên nó không được hỗ
trợ trên các kết nối phụ sử dụng phương tiện truyền tải không đáng tin cậy.

Message Delivery: Bản tin đảm bảo được truyền, trừ khi OpenFlow Channel bị lỗi hoàn
toàn.

Message Processing: Switches phải xử lý đầy đủ mọi thông báo nhận được từ bộ điều
khiển, có thể tạo ra một phản hồi. Nếu một Switch không thể xử lý hoàn toàn một thông báo
nhận được từ một bộ điều khiển, nó phải gửi lại một thông báo lỗi.

Message Ordering: Thứ tự có thể được đảm bảo thông qua việc sử dụng các bản tin
Barrier.

2.3 OpenFlow Channel Connections

OpenFlow Channel được sử dụng để trao đổi thông điệp OpenFlow giữa OpenFlow
Switch và bộ điều khiển OpenFlow. Bộ điều khiển OpenFlow điển hình quản lý nhiều OpenFlow
Channel , mỗi Channel cho một OpenFlow switch khác nhau. Một OpenFlow Switch có thể có
một OpenFlow Channel cho một bộ điều khiển duy nhất, hoặc nhiều Channel để đảm bảo độ tin
cậy, mỗi Channel cho một bộ điều khiển khác nhau.
2.3.1 Connection Setup

Khi kết nối OpenFlow lần đầu tiên được thiết lập, mỗi bên của kết nối phải gửi ngay một
thông báo OFPT_HELLO. Nếu phiên bản được hỗ trợ bởi người nhận, thì kết nối sẽ tiếp tục.
Nếu không, người nhận phải trả lời bằng thông báo OFPT_ERROR với trường loại
OFPET_HELLO_FAILED, trường mã OFPHFC_COMPATIBLE và tùy chọn một chuỗi ASCII
giải thích tình huống trong dữ liệu, sau đó chấm dứt kết nối.

2.3.2 Connection Interruption

Trong trường hợp Switch mất liên lạc với tất cả bộ điều khiển, do hết thời gian chờ bản
tin yêu cầu echo, hết thời gian chờ phiên TLS hoặc các ngắt kết nối khác, công tắc sẽ ngay lập
tức chuyển sang “fail secure mode” hoặc “fail standalone mode”.

2.3.3 Encryption

Switch và bộ điều khiển xác thực lẫn nhau bằng cách trao đổi các chứng chỉ được xác
nhận bởi một site-specific private key. Mỗi Switch phải được người dùng định cấu hình với một
chứng chỉ để xác thực bộ điều khiển (controller certificate) và chứng chỉ còn lại để xác thực bộ
điều khiển (switch certificate).

2.3.4 Multiple Controllers

Switch có thể thiết lập giao tiếp với một bộ điều khiển duy nhất hoặc có thể thiết lập giao
tiếp với nhiều bộ điều khiển. Việc có nhiều bộ điều khiển giúp cải thiện độ tin cậy, vì công tắc có
thể tiếp tục hoạt động ở chế độ OpenFlow nếu một bộ điều khiển hoặc kết nối bộ điều khiển
không thành công. Việc chuyển giao giữa các bộ điều khiển hoàn toàn do bộ điều khiển tự quản
lý, cho phép khôi phục nhanh chóng từ lỗi và cũng như cân bằng tải bộ điều khiển.

Khi hoạt động OpenFlow được bắt đầu, Switch phải kết nối với tất cả các bộ điều khiển
mà nó được cấu hình và cố gắng duy trì kết nối với tất cả các bộ điều khiển đồng thời.

Vai trò mặc định của bộ điều khiển là OFPCR_ROLE_EQUAL. Trong vai trò này, bộ
điều khiển có toàn quyền truy cập vào Switch và bình đẳng với các bộ điều khiển khác có cùng
vai trò.

Bộ điều khiển có thể yêu cầu thay đổi vai trò của nó thành OFPCR_ROLE_SLAVE.
Trong vai trò này, bộ điều khiển chỉ có quyền truy cập read-only vào Switch.

Bộ điều khiển có thể yêu cầu thay đổi vai trò của nó thành OFPCR_ROLE_MASTER.
Vai trò này tương tự như OFPCR_ROLE_EQUAL và có toàn quyền truy cập vào Switch , sự
khác biệt là Switch đảm bảo nó là bộ điều khiển duy nhất trong vai trò này.

Một Switch có thể được kết nối đồng thời với nhiều bộ điều khiển ở trạng thái Equal,
nhiều bộ điều khiển ở trạng thái Slave và nhiều nhất một bộ điều khiển ở trạng thái Master. Mỗi
bộ điều khiển có thể giao tiếp vai trò của nó với Switch thông qua bản tin
OFPT_ROLE_REQUEST và Switch phải nhớ vai trò của mỗi kết nối bộ điều khiển. Bộ điều
khiển có thể thay đổi vai trò bất cứ lúc nào.

Để phát hiện các bản tin không theo thứ tự trong quá trình chuyển đổi master/slave ,
thông báo OFPT_ROLE_REQUEST chứa trường số thứ tự 64-bit, generation_id, có tác dụng
xác định một given mastership view. Đoạn mã giả sau đây mô tả hành vi của Switch khi làm
việc với generation_id:

2.3.5 Auxiliary Connections

OpenFlow Channel có 1 kết nối chính duy nhất giữa OpenFlow switch và bộ điều khiển
và nhiều kết nối phụ khác. Các kết nối phụ được tạo bởi OpenFlow Switch và rất hữu ích để cải
thiện hiệu suất xử lý của Switch và khai thác tính song song của hầu hết các triển khai của
Switch.

2.4 Flow Table Modification Messages

Bản tin sửa đổi Flow Table có thể có các loại sau:

2.5 Group Table Modification Messages

Bản tin sửa đổi Group Table có thể có các loại sau:
2.6 Meter Modification Messages
Bản tin sửa đổi Meter có thể có các loại sau:

A.4. Asynchronous Messages

1) Packet-In Message

Khi các gói được nhận bởi DataPath và chuyển quyền điều khiển một packet đến bộ điều khiển

Ta sử dụng OFPT_PACKET_IN message:

+ Buffer_ID là một phần giá trị được sử dụng bởi DataPath để xác định một buffered packet. Khi
một gói được đệm, một số byte từ bản tin sẽ được bao gồm trong phần dữ liệu của tin nhắn ->
xác nhận mục đích truyền -> thiết lập luồng. Nếu gói không được đệm - vì không có bộ đệm có
sẵn, hoặc do được yêu cầu rõ ràng qua Ofpcml_no_buffer - Toàn bộ gói được bao gồm trong
phần dữ liệu và BUFFER_ID là OFP_NO_BUFFER
Switches mà có sử dụng bộ đệm sẽ được hiển thị, dung lượng đệm có sẵn và thời gian trước khi
bộ đệm có thể được sử dụng lại. Mỗi swich xử lý 1 buffered packet_in message, ngăn chặn bộ
đệm sử dụng lại cho đến khi nó được xử lý bởi bộ điều khiển hoặc một khoảng thời gian (được
chỉ định trong tài liệu) đã được thông qua

- The Data field chứa gói tin hoặc một phần của gói nếu gói được đệm.

- The reason field: mang 1 số giá trị dưới

- The cookie field chứa cookie của các luồng vào của gói được gửi đến bộ điều khiển. Trường
này phải được đặt thành -1 nếu 1 cookie không thể liên kết với 1 luồng cụ thể

- The match field: cho biết the packet’s headers and context bao gồm bất kỳ thay đổi nào được áp
dụng cho các gói trong xử lý trước đó

Khi một gói được nhận trên một cổng logic bằng một cổng vật lý, OFPXMT_OFB_IN_PORT là
cổng của cổng logic và OFPXMT_OFB_IN_PHY_PORT là cổng của cổng vật lý

Cổng được tham chiếu bởi OFPXMT_OFB_IN_PORT phải là cổng được sử dụng để kết hợp các
luồng vào và luôn có sẵn để xử lý Openflow. OFPXMT_OFB_IN_PHY_PORT không cần phải
có sẵn để Matching hoặc xử lý OpenFlow.

2) Flow Removed Message

Nếu bộ điều khiển đã được yêu cầu được thông báo khi hết thời gian nhập flow entries hoặc bị
xóa khỏi bảng, datapath làm điều này với tin nhắn OFPT_FLOW_REMOVED:
- The match, cookie, and priority fields giống như các trường được sử dụng trong the flow mod
request

- The reason field:

- The duration_sec và duration_nsec fields (A.3.5.2)

- The idle_timeout và hard_timeout fields được sao chép trực tiếp từ the Flow mod được tạo ra từ
cổng vào

=> Với 3 trường trên, ta xác định được thời gian mà the flow entry hoạt động và lượng thời gian
mà the flow entry nhận được lưu lượng truy cập.

-The packet_count and byte_count biểu thị số lượng gói và byte được liên kết với flow entry đó.

3) Port Status Message

Khi các cổng được thêm vào, sửa đổi và xóa khỏi DataPath, bộ điều khiển cần được thông báo
bằng OFPT_PORT_STATUS message.
Trạng thái có thể là một trong các giá trị sau:

4) Error Message

Switch có thể thông báo cho bộ điều khiển về các sự cố bằng cách sử dụng các bản tin
OFPT_ERROR_MSG

Các loại lỗi hiện được xác định là:

A.5. Symmetric Messages

1) Hello

Các bản tin Hello được trao đổi giữa switch và bộ điều khiển khi khởi động kết nối

Tin nhắn OFPT_HELLO không có dạng, nó chỉ bao gồm một tiêu đề OpenFlow, để thực hiện,
phải chuẩn bị để nhận được một tin nhắn hello bao gồm một dạng, bỏ qua nội dung của nó, để
cho phép sau này mở rộng.

2) Echo Request

Bản tin yêu cầu bằng echo có thể được gửi từ Switch hoặc bộ điều khiển và phải trả lại phản
hồi echo

Một thông báo yêu cầu echo bao gồm một tiêu đề OpenFlow cộng với một trường dữ liệu có độ
dài tùy ý. Trường dữ liệu có thể là một dấu thời gian thông báo để kiểm tra độ trễ, nhiều độ dài
khác nhau để đo băng thông

3) Echo Reply

Bản tin trả lời bằng echo có thể được gửi từ Switch hoặc bộ điều khiển và phải trả lại phản hồi
echo

Một tin nhắn trả lời echo bao gồm tiêu đề OpenFlow cộng với trường dữ liệu chưa được xác
định của bản tin yêu cầu echo

4) Experimenter
Bản tin Experimenter cung cấp cách thức chuẩn cho các OpenFlow switches để cung cấp chức
năng bổ sung trong bản tin OpenFlow
B Release Note

Ghi chú những thay đổi trong giao thức OpenFlow qua nhiều phiên bản

B.11 OpenFlow phiên bản 1.3

B.11.1 Đàm phán khả năng của bộ tái cấu trúc

Các phiên bản trước của đặc tả OpenFlow bao gồm biểu hiện hạn chế về các khả năng của
switch OpenFlow. OpenFlow 1.3 bao gồm một khuôn khổ linh hoạt hơn để thể hiện các khả năng
(EXT-123). Thay đổi chính là cải thiện về khả năng của bảng. Những khả năng đó đã được di
chuyển ra khỏi cấu trúc thống kê bảng trong thông báo request/reply của chính nó và được mã
hóa bằng cách sử dụng linh hoạt định dạng TLV. Điều này cho phép bổ sung các khả năng của
bảng tiếp theo, khả năng nhập luồng bỏ sót bảng và năng lực của người thử nghiệm.

Các thay đổi khác bao gồm đổi tên khung 'thống kê' thành khung 'nhiều phần' để phản ánh thực
tế là nó hiện được sử dụng cho cả số liệu thống kê và khả năng, và việc chuyển các mô tả cổng
thành thông báo nhiều phần để cho phép hỗ trợ nhiều cổng hơn.

Danh sách các tính năng

• Đổi tên khung 'thống kê' thành khung 'nhiều phần'.

• Bật yêu cầu 'nhiều phần'

• Di chuyển mô tả danh sách cổng sang yêu cầu/trả lời nhiều phần của riêng nó.

• Di chuyển các khả năng của bảng thành yêu cầu / trả lời nhiều phần của riêng nó.

• Tạo cấu trúc thuộc tính linh hoạt để thể hiện các khả năng của bảng.

• Cho phép thể hiện khả năng của người thử nghiệm.

• Thêm khả năng cho các mục nhập dòng bỏ sót bảng.

• Thêm các khả năng của bảng tiếp theo (tức là goto)

B.11.3 Hỗ trợ xử lý IPv6 Header

Thêm khả năng đối sánh sự hiện diện của các tiêu đề tiện ích mở rộng IPv6 phổ biến và một số
điều kiện bất thường trong các tiêu đề mở rộng IPv6 (EXT-38). Trường tiêu đề giả OXM mới
OXM_OF_IPV6_EXTHDR cho phép phù hợp với các điều kiện sau:

• Có extension Hop-by-hop IPv6 header.

• Có extension IPv6 header của bộ định tuyến.

• Có extension IPv6 header phân mảnh.

• Có các tùy chọn đích Các tiêu đề mở rộng IPv6.

• Có tiêu đề tiện ích mở rộng IPv6 xác thực.

• Có tiêu đề tiện ích mở rộng IPv6 Payload bảo mật được mã hóa.

• Không có tiêu đề mở rộng IPv6 của Header Tiếp theo.

• Tiêu đề tiện ích mở rộng IPv6 không theo thứ tự ưu tiên.

• Gặp phải tiêu đề tiện ích mở rộng IPv6 không mong muốn.

B.11.4 Trên mỗi đồng hồ đo lưu lượng

Thêm hỗ trợ cho đồng hồ đo trên mỗi lưu lượng (EXT-14). Đồng hồ đo trên lưu lượng có thể
được gắn vào các đầu vào lưu lượng và có thể đo và kiểm soát tốc độ gói tin. Một trong những
ứng dụng chính của đồng hồ đo trên lưu lượng là để xếp hạng các gói giới hạn được gửi cho bộ
điều khiển. Tính năng đồng hồ đo trên mỗi lưu lượng dựa trên khung đồng hồ linh hoạt mới, bao
gồm khả năng mô tả các máy đo phức tạp thông qua việc sử dụng nhiều dải đo sáng, thống kê
và khả năng đo sáng. Hiện tại, chỉ có các đồng hồ đo giới hạn tốc độ đơn giản được xác định
trong khuôn khổ này. Hỗ trợ cho các máy đo nhận biết màu sắc, hỗ trợ hoạt động kiểu Diff-Serv
và được tích hợp chặt chẽ trong đường ống, đã bị hoãn lại sau phóng thích.

• Khung đồng hồ linh hoạt dựa trên đồng hồ đo trên lưu lượng và dải đồng hồ.

• Thống kê đồng hồ, bao gồm thống kê trên mỗi băng tần.

• Cho phép gắn đồng hồ một cách linh hoạt vào các flow entries.
• Hỗ trợ giới hạn tốc độ đơn giản (gói tin thả xuống).

B.11.5 Lọc sự kiện mỗi kết nối

Phiên bản trước của thông số kỹ thuật đã giới thiệu khả năng cho một công tắc kết nối với nhiều
bộ điều khiển để chịu lỗi và cân bằng tải. Lọc sự kiện trên mỗi kết nối cải thiện hỗ trợ đa bộ điều
khiển bằng cách cho phép mỗi bộ điều khiển lọc các sự kiện từ công tắc mà nó không muốn
(EXT-120).

Một bộ thông báo OpenFlow mới cho phép bộ điều khiển định cấu hình bộ lọc sự kiện trên kết
nối của chính nó với switch. Tin nhắn không đồng bộ có thể được lọc theo loại và lý do. Bộ lọc
sự kiện này đi kèm ngoài các cơ chế hiện có khác cho phép hoặc tắt thông báo không đồng bộ,
ví dụ: Có thể định cấu hình việc tạo ra các sự kiện bị loại bỏ theo luồng trên mỗi luồng. Mỗi bộ
điều khiển có thể có một bộ lọc riêng biệt cho vai trò nô lệ và vai trò chủ / bình đẳng.

• Thêm bộ lọc tin nhắn không đồng bộ cho mỗi kết nối bộ điều khiển.

• Thông báo điều khiển để thiết lập / lấy bộ lọc thông báo không đồng bộ.

• Đặt giá trị bộ lọc mặc định để phù hợp với hành vi OpenFlow 1.2.

• Xóa cờ cấu hình OFPC_INVALID_TTL_TO_CONTROLLER.

B.11.6 Kết nối phụ trợ

Trong phiên bản trước của thông số kỹ thuật, kênh giữa công tắc và bộ điều khiển là độc quyền
được tạo bằng một kết nối TCP duy nhất, không cho phép khai thác tính song song có sẵn trong
hầu hết các thiết bị chuyển mạch triển khai. OpenFlow 1.3 cho phép một công tắc tạo các kết
nối phụ để bổ sung cho chính kết nối giữa công tắc và bộ điều khiển (EXT-114). Các kết nối phụ
trợ chủ yếu hữu ích để thực hiện các bản tin gói vào và gói ra.

• Bật công tắc để tạo kết nối phụ với bộ điều khiển.

• Ủy quyền rằng kết nối phụ không thể tồn tại khi kết nối chính không còn hoạt động.

• Thêm id phụ vào giao thức để phân biệt loại kết nối.

• Kích hoạt kết nối phụ qua UDP và DTLS.

B.11.7 MPLS BoS khớp

Trường OXM mới OXM_OF_MPLS_BOS đã được thêm vào để khớp với bit Bottom of Stack (BoS)
từ MPLS tiêu đề (EXT-85). Bit BoS cho biết liệu tiêu đề miếng đệm MPLS khác có thuộc trọng tải
của MPLS hiện tại hay không gói và đối sánh với bit này có thể giúp phân biệt trường hợp nhãn
MPLS được sử dụng lại ở các mức Đóng gói MPLS.

B.11.8 Provider Backbone Bridging tagging

Thêm hỗ trợ để gắn thẻ gói tin bằng cách sử dụng đóng gói Cầu nối đường trục nhà cung cấp
(PBB) (EXT-105). Cái này hỗ trợ cho phép OpenFlow hỗ trợ triển khai mạng khác nhau dựa trên
PBB, chẳng hạn như PBB thông thường và PBB-TE.

• Thao tác đẩy và bật để thêm tiêu đề PBB làm thẻ.

• Trường OXM mới để khớp I-SID cho tiêu đề PBB.

B.11.9 Làm lại thứ tự tag

Trong phiên bản trước, thứ tự cuối cùng của các thẻ trong một gói được chỉ định tĩnh. Vì ví dụ,
một tiêu đề MPLS shim luôn được chèn vào sau tất cả các thẻ VLAN trong gói. OpenFlow 1.3
loại bỏ hạn chế này, thứ tự cuối cùng của các thẻ trong một gói được quyết định bởi thứ tự của
các hoạt động gắn thẻ, mỗi thao tác gắn thẻ sẽ thêm thẻ của nó ở vị trí ngoài cùng (EXT-121).

• Loại bỏ thứ tự đã xác định của các thẻ trong gói khỏi thông số kỹ thuật.

• Các thẻ luôn được thêm ở vị trí ngoài cùng.

• Danh sách hành động có thể thêm các thẻ theo thứ tự tùy ý.

• Thứ tự thẻ được xác định trước để gắn thẻ trong bộ hành động.

B.11.10 Siêu dữ liệu Tunnel-ID

Việc trừu tượng hóa cổng logic cho phép OpenFlow hỗ trợ nhiều loại đóng gói. ID đường hầm
siêu dữ liệu OXM_OF_TUNNEL_ID là trường OXM mới hiển thị siêu dữ liệu đường ống OpenFlow
được liên kết với cổng logic, phổ biến nhất là trường phân kênh từ tiêu đề đóng gói (EXT-107).
Ví dụ: nếu cổng logic thực hiện đóng gói GRE, thì trường tunnel-id sẽ ánh xạ tới Trường khóa
GRE từ tiêu đề GRE. Sau khi giải mã, OpenFlow sẽ có thể khớp với khóa GRE trong trường đối
sánh đường hầm-id. Tương tự, bằng cách đặt đường hầm-id, OpenFlow sẽ có thể đặt GRE khóa
trong một gói được đóng gói.

B.11.11 Cookie trong packet-in

Một trường cookie đã được thêm vào thông báo gói tin (EXT-7). Trường này lấy giá trị của nó từ
luồng gửi gói tin đến bộ điều khiển. Nếu gói không được gửi bởi một luồng, trường này được đặt
thành 0xffffffffffffffff.

Cookie trong gói vào cho phép bộ điều khiển phân loại gói vào hiệu quả hơn, thay vì so với việc
phải đối sánh gói với bảng lưu lượng đầy đủ.

B.11.12 Thời lượng cho số liệu thống kê

Trường thời lượng đã được thêm vào hầu hết các thống kê, bao gồm thống kê cổng, thống kê
nhóm, thống kê hàng đợi và thống kê đồng hồ (EXT-102). Trường thời lượng cho phép tính toán
chính xác hơn tốc độ gói và byte từ các quầy có trong các số liệu thống kê đó.

B.11.13 Bộ đếm luồng theo yêu cầu

Cờ luồng mod luồng mới đã được thêm vào để vô hiệu hóa bộ đếm gói và byte trên cơ sở mỗi
luồng. Vô hiệu hóa như vậy bộ đếm có thể cải thiện hiệu suất xử lý luồng trong công tắc