P4: Programming Protocol-Independent Packet Processors

1 GIỚI THIỆU

Mạng được định nghĩa bằng phần mềm (Software-Defined Networking, SDN) cung cấp cho các nhà vận hành khả năng điều khiển mạng của họ bằng chương trình. Trong SDN, mặt phẳng điều khiển được tách biệt về mặt vật lý khỏi mặt phẳng chuyển tiếp, và một mặt phẳng điều khiển điều khiển nhiều thiết bị chuyển tiếp. Mặc dù các thiết bị chuyển tiếp có thể được lập trình theo nhiều cách, việc có một giao diện chung, mở và không phụ thuộc nhà cung cấp (như OpenFlow) cho phép một mặt phẳng điều khiển điều khiển các thiết bị chuyển tiếp từ những nhà cung cấp phần cứng và phần mềm khác nhau.

Bảng 1: Các trường được tiêu chuẩn OpenFlow nhận diện

Giao diện OpenFlow ban đầu khá đơn giản, với sự trừu tượng hóa của một bảng duy nhất gồm các quy tắc có thể đối sánh các gói tin dựa trên một tá trường phần đầu (ví dụ: địa chỉ MAC, địa chỉ IP, giao thức, số cổng TCP/UDP, v.v.). Trong năm năm qua, đặc tả đã ngày càng trở nên phức tạp hơn (xem Bảng 1), với nhiều trường phần đầu hơn và nhiều giai đoạn bảng quy tắc, nhằm cho phép các chuyển mạch bộc lộ nhiều khả năng hơn của chúng cho bộ điều khiển.

Sự gia tăng các trường phần đầu mới không có dấu hiệu dừng lại. Ví dụ, các nhà vận hành mạng trung tâm dữ liệu ngày càng muốn áp dụng các dạng đóng gói gói tin mới (ví dụ: NVGRE, VXLAN và STT), khiến họ phải triển khai các chuyển mạch phần mềm dễ mở rộng hơn với chức năng mới. Thay vì liên tục mở rộng đặc tả OpenFlow, chúng tôi cho rằng các chuyển mạch trong tương lai nên hỗ trợ các cơ chế linh hoạt để phân tích cú pháp gói tin và đối sánh các trường phần đầu, cho phép các ứng dụng bộ điều khiển khai thác những khả năng này thông qua một giao diện chung, mở (tức là một API “OpenFlow 2.0” mới). Cách tiếp cận tổng quát, có khả năng mở rộng như vậy sẽ đơn giản hơn, thanh nhã hơn và có tính hướng tới tương lai hơn so với tiêu chuẩn OpenFlow 1.x hiện nay.

Hình.

Các thiết kế chip gần đây chứng minh rằng tính linh hoạt như vậy có thể đạt được trên các ASIC tùy biến ở tốc độ terabit [1][2][3]. Lập trình thế hệ chip chuyển mạch mới này hoàn toàn không dễ dàng. Mỗi chip có giao diện cấp thấp riêng, tương tự như lập trình microcode. Trong bài báo này, chúng tôi phác thảo thiết kế của một ngôn ngữ cấp cao hơn dành cho các Bộ xử lý Gói tin Độc lập với Giao thức (Programming Protocol-independent Packet Processors, P4). Hình 1 cho thấy mối quan hệ giữa P4—được sử dụng để cấu hình một chuyển mạch, chỉ dẫn cách các gói tin được xử lý—và các API hiện có (chẳng hạn như OpenFlow), vốn được thiết kế để điền các bảng chuyển tiếp trong các chuyển mạch có chức năng cố định. P4 nâng mức độ trừu tượng hóa của việc lập trình mạng, và có thể đóng vai trò là một giao diện tổng quát giữa bộ điều khiển và các chuyển mạch. Nói cách khác, chúng tôi cho rằng các thế hệ OpenFlow trong tương lai nên cho phép bộ điều khiển chỉ dẫn chuyển mạch cách vận hành, thay vì bị ràng buộc bởi một thiết kế chuyển mạch cố định. Thách thức then chốt là tìm ra một “điểm cân bằng” giữa nhu cầu về khả năng biểu đạt và tính dễ triển khai trên một phạm vi rộng các chuyển mạch phần cứng và phần mềm. Khi thiết kế P4, chúng tôi có ba mục tiêu chính: • Khả năng tái cấu hình. Bộ điều khiển phải có khả năng định nghĩa lại việc phân tích cú pháp và xử lý gói tin ngay tại hiện trường. • Tính độc lập với giao thức. Chuyển mạch không nên bị ràng buộc với các định dạng gói tin cụ thể. Thay vào đó, bộ điều khiển phải có khả năng đặc tả (i) một bộ phân tích cú pháp gói tin để trích xuất các trường phần đầu với những tên và kiểu cụ thể và (ii) một tập hợp các bảng đối sánh+hành động có kiểu, xử lý các phần đầu này. • Tính độc lập với đích. Cũng như một lập trình viên C không cần biết các đặc điểm cụ thể của CPU bên dưới, lập trình viên bộ điều khiển không cần biết chi tiết của chuyển mạch bên dưới. Thay vào đó, một trình biên dịch phải tính đến các khả năng của chuyển mạch khi chuyển một mô tả độc lập với đích (được viết bằng P4) thành một chương trình phụ thuộc đích (được sử dụng để cấu hình chuyển mạch). Bố cục của bài báo như sau. Trước tiên, chúng tôi giới thiệu một mô hình chuyển tiếp chuyển mạch trừu tượng. Tiếp theo, chúng tôi giải thích nhu cầu về một ngôn ngữ mới để mô tả việc xử lý gói tin độc lập với giao thức. Sau đó, chúng tôi trình bày một ví dụ minh họa đơn giản, trong đó một nhà vận hành mạng muốn hỗ trợ một trường phần đầu gói tin mới và xử lý các gói tin qua nhiều giai đoạn. Chúng tôi sử dụng ví dụ này để khảo sát cách chương trình P4 đặc tả các phần đầu, bộ phân tích cú pháp gói tin, nhiều bảng đối sánh+hành động và luồng điều khiển qua các bảng này. Cuối cùng, chúng tôi thảo luận cách một trình biên dịch có thể ánh xạ các chương trình P4 tới các chuyển mạch đích.

Công trình liên quan. Năm 2011, Yadav và cộng sự [4] đề xuất một mô hình chuyển tiếp trừu tượng cho OpenFlow, nhưng ít chú trọng hơn đến trình biên dịch. Kangaroo [1] đưa ra khái niệm phân tích cú pháp có thể lập trình. Gần đây, Song [5] đề xuất cơ chế chuyển tiếp không phụ thuộc giao thức, chia sẻ mục tiêu độc lập với giao thức của chúng tôi, nhưng hướng nhiều hơn tới các bộ xử lý mạng. ONF đưa ra các mẫu định kiểu bảng để biểu đạt các khả năng đối sánh của chuyển mạch [6]. Các công trình gần đây về NOSIX [7] chia sẻ mục tiêu đặc tả linh hoạt các bảng đối sánh+hành động của chúng tôi, nhưng không xem xét tính độc lập với giao thức hoặc đề xuất một ngôn ngữ để đặc tả bộ phân tích cú pháp, các bảng và luồng điều khiển. Các công trình gần đây khác đề xuất một giao diện lập trình cho mặt phẳng dữ liệu nhằm giám sát, điều khiển tắc nghẽn và quản lý hàng đợi [8][9]. Bộ định tuyến mô-đun Click [10] hỗ trợ xử lý gói tin linh hoạt trong phần mềm, nhưng không ánh xạ các chương trình tới nhiều loại chuyển mạch phần cứng đích.

2 MÔ HÌNH CHUYỂN TIẾP TRỪU TƯỢNG

Trong mô hình trừu tượng của chúng tôi (Fig. 2), các chuyển mạch chuyển tiếp các gói tin thông qua một bộ phân tích cú pháp có thể lập trình, tiếp theo là nhiều giai đoạn match+action, được sắp xếp theo chuỗi, song song, hoặc kết hợp cả hai. Được suy ra từ OpenFlow, mô hình của chúng tôi đưa ra ba khái quát hóa. Thứ nhất, OpenFlow giả định một bộ phân tích cú pháp cố định, trong khi mô hình của chúng tôi hỗ trợ một bộ phân tích cú pháp có thể lập trình để cho phép định nghĩa các phần đầu mới. Thứ hai, OpenFlow giả định các giai đoạn match+action nằm theo chuỗi, trong khi trong mô hình của chúng tôi chúng có thể nằm song song hoặc theo chuỗi. Thứ ba, mô hình của chúng tôi giả định rằng các hành động được tạo thành từ các nguyên thủy không phụ thuộc giao thức được chuyển mạch hỗ trợ.

Mô hình trừu tượng của chúng tôi khái quát hóa cách các gói tin được xử lý trong các thiết bị chuyển tiếp khác nhau (ví dụ, các chuyển mạch Ethernet, các bộ định tuyến, các bộ cân bằng tải) và bởi các công nghệ khác nhau (ví dụ, các ASIC chuyển mạch chức năng cố định, các NPU, các chuyển mạch có thể cấu hình lại, các chuyển mạch phần mềm, các FPGA). Điều này cho phép chúng tôi xây dựng một ngôn ngữ chung (P4) để biểu diễn cách các gói tin được xử lý theo mô hình trừu tượng chung của chúng tôi. Do đó, các lập trình viên có thể tạo ra các chương trình không phụ thuộc mục tiêu mà một trình biên dịch có thể ánh xạ tới nhiều thiết bị chuyển tiếp khác nhau, từ các chuyển mạch phần mềm tương đối chậm đến các chuyển mạch dựa trên ASIC nhanh nhất.

Hình.

Mô hình chuyển tiếp được điều khiển bởi hai loại thao tác: Configure và Populate. Các thao tác Configure lập trình bộ phân tích cú pháp, thiết lập thứ tự của các giai đoạn match+action, và đặc tả các trường phần đầu được xử lý bởi mỗi giai đoạn. Cấu hình xác định các giao thức nào được hỗ trợ và cách chuyển mạch có thể xử lý các gói tin. Các thao tác Populate thêm (và loại bỏ) các mục nhập vào các bảng match+action đã được đặc tả trong quá trình cấu hình. Population xác định chính sách được áp dụng cho các gói tin tại bất kỳ thời điểm nào.

Với mục đích của bài báo này, chúng tôi giả định rằng cấu hình và population là hai pha riêng biệt. Cụ thể, chuyển mạch không cần xử lý các gói tin trong quá trình cấu hình. Tuy nhiên, chúng tôi kỳ vọng các triển khai sẽ cho phép xử lý gói tin trong quá trình tái cấu hình một phần hoặc toàn bộ, cho phép nâng cấp mà không có thời gian ngừng hoạt động. Mô hình của chúng tôi chủ ý cho phép và khuyến khích việc tái cấu hình không làm gián đoạn chuyển tiếp.

Rõ ràng, pha cấu hình có ít ý nghĩa trong các chuyển mạch ASIC chức năng cố định; đối với loại chuyển mạch này, công việc của trình biên dịch chỉ đơn giản là kiểm tra xem chip có thể hỗ trợ chương trình P4 hay không. Thay vào đó, mục tiêu của chúng tôi là nắm bắt xu hướng chung hướng tới các đường ống xử lý gói tin có thể cấu hình lại nhanh, như được mô tả trong [2][3].

Các gói tin đến trước tiên được xử lý bởi bộ phân tích cú pháp. Phần thân gói tin được giả định là được đệm riêng và không khả dụng cho việc so khớp. Bộ phân tích cú pháp nhận dạng và trích xuất các trường từ phần đầu, do đó xác định các giao thức được chuyển mạch hỗ trợ. Mô hình không đưa ra giả định nào về ý nghĩa của các phần đầu giao thức, chỉ rằng biểu diễn đã được phân tích cú pháp định nghĩa một tập hợp các trường mà trên đó việc so khớp và các hành động hoạt động.

Các trường phần đầu được trích xuất sau đó được chuyển tới các bảng match+action. Các bảng match+action được chia giữa ingress và egress. Trong khi cả hai có thể sửa đổi phần đầu gói tin, ingress match+action xác định (các) cổng egress và xác định hàng đợi mà gói tin được đặt vào. Dựa trên xử lý ingress, gói tin có thể được chuyển tiếp, sao chép (cho multicast, span, hoặc tới mặt phẳng điều khiển), loại bỏ, hoặc kích hoạt điều khiển luồng. Egress match+action thực hiện các sửa đổi theo từng thực thể đối với phần đầu gói tin – ví dụ, đối với các bản sao multicast. Các bảng hành động (counters, policers, v.v.) có thể được liên kết với một luồng để theo dõi trạng thái từ frame này tới frame khác.

Các gói tin có thể mang thêm thông tin giữa các giai đoạn, được gọi là metadata, được xử lý giống hệt như các trường phần đầu gói tin. Một số ví dụ về metadata bao gồm cổng ingress, đích truyền và hàng đợi, một dấu thời gian có thể được sử dụng cho việc lập lịch gói tin, và dữ liệu được truyền từ bảng này sang bảng khác không liên quan đến việc thay đổi biểu diễn đã được phân tích cú pháp của gói tin như một định danh mạng ảo.

Các cơ chế xếp hàng được xử lý theo cùng cách như OpenFlow hiện tại: một hành động ánh xạ một gói tin tới một hàng đợi, được cấu hình để nhận một cơ chế dịch vụ cụ thể. Cơ chế dịch vụ (ví dụ, minimum rate, DRR) được chọn như một phần của cấu hình chuyển mạch.

Mặc dù nằm ngoài phạm vi của bài báo này, các nguyên thủy hành động có thể được thêm vào để cho phép lập trình viên triển khai các giao thức điều khiển tắc nghẽn mới hoặc hiện có. Ví dụ, chuyển mạch có thể được lập trình để thiết lập bit ECN dựa trên các điều kiện mới, hoặc nó có thể triển khai một cơ chế điều khiển tắc nghẽn độc quyền sử dụng các bảng match+action.

3 MỘT NGÔN NGỮ LẬP TRÌNH

Chúng tôi sử dụng mô hình chuyển tiếp trừu tượng để định nghĩa một ngôn ngữ biểu diễn cách một chuyển mạch được cấu hình và cách các gói tin được xử lý. Mục tiêu chính của bài báo này là đề xuất ngôn ngữ lập trình P4. Tuy nhiên, chúng tôi nhận thấy rằng có thể có nhiều ngôn ngữ, và chúng có khả năng sẽ chia sẻ các đặc điểm chung mà chúng tôi mô tả ở đây. Ví dụ, ngôn ngữ cần có một cách để biểu diễn cách bộ phân tích cú pháp được lập trình để bộ phân tích cú pháp biết những định dạng gói tin nào cần mong đợi; do đó một lập trình viên cần một cách để khai báo những kiểu phần đầu nào có thể tồn tại. Ví dụ, lập trình viên có thể đặc tả định dạng của phần đầu IPv4 và những phần đầu nào có thể theo sau phần đầu IP một cách hợp lệ. Điều này thúc đẩy việc định nghĩa phân tích cú pháp trong P4 bằng cách khai báo các kiểu phần đầu hợp lệ. Tương tự, lập trình viên cần biểu diễn cách các phần đầu gói tin được xử lý. Ví dụ, các trường TTL phải được giảm và kiểm tra, các phần đầu đường hầm mới có thể cần được thêm vào, và các tổng kiểm tra có thể cần được tính toán. Điều này thúc đẩy việc P4 sử dụng một chương trình luồng điều khiển mệnh lệnh để mô tả việc xử lý trường phần đầu bằng cách sử dụng các kiểu phần đầu đã khai báo và một tập hợp nguyên thủy các hành động.

Chúng tôi có thể sử dụng một ngôn ngữ như Click [10], ngôn ngữ xây dựng các chuyển mạch từ các mô-đun được tạo thành từ C++ tùy ý. Click có khả năng biểu diễn cực kỳ cao, và rất phù hợp để biểu diễn cách các gói tin được xử lý trong nhân của một CPU. Nhưng nó bị ràng buộc không đủ chặt chẽ đối với nhu cầu của chúng tôi—chúng tôi cần một ngôn ngữ phản chiếu các đường ống phân tích cú pháp-khớp-hành động trong phần cứng chuyên dụng. Ngoài ra, Click không được thiết kế cho kiến trúc bộ điều khiển-chuyển mạch và do đó không cho phép lập trình viên mô tả các bảng khớp+hành động được điền động bởi các quy tắc có kiểu rõ ràng. Cuối cùng, Click khiến việc suy luận các phụ thuộc ràng buộc thực thi song song trở nên khó khăn—như chúng tôi sẽ thảo luận sau đây.

Một ngôn ngữ xử lý gói tin phải cho phép lập trình viên biểu diễn (ngầm hoặc tường minh) bất kỳ phụ thuộc tuần tự nào giữa các trường phần đầu. Các phụ thuộc xác định những bảng nào có thể được thực thi song song. Ví dụ, thực thi tuần tự là cần thiết đối với một bảng định tuyến IP và một bảng ARP do phụ thuộc dữ liệu giữa chúng. Các phụ thuộc có thể được xác định bằng cách phân tích Đồ thị Phụ thuộc Bảng (TDG); các đồ thị này mô tả các đầu vào trường, hành động và luồng điều khiển giữa các bảng. Hình 3 cho thấy một ví dụ về đồ thị phụ thuộc bảng cho một chuyển mạch L2/L3. Các nút TDG ánh xạ trực tiếp tới các bảng khớp+hành động, và một phân tích phụ thuộc xác định vị trí mà mỗi bảng có thể nằm trong đường ống. Đáng tiếc là TDG không dễ dàng được tiếp cận đối với hầu hết lập trình viên; lập trình viên có xu hướng suy nghĩ về các thuật toán xử lý gói tin bằng cách sử dụng các cấu trúc mệnh lệnh thay vì các đồ thị.

Hình.

Điều này dẫn chúng tôi tới việc đề xuất một quy trình biên dịch hai bước. Ở mức cao nhất, lập trình viên biểu diễn các chương trình xử lý gói tin bằng một ngôn ngữ mệnh lệnh biểu diễn luồng điều khiển (P4); bên dưới mức này, một trình biên dịch dịch biểu diễn P4 thành các TDG để tạo thuận lợi cho phân tích phụ thuộc, sau đó ánh xạ TDG tới một mục tiêu chuyển mạch cụ thể. P4 được thiết kế để giúp việc dịch một chương trình P4 thành một TDG trở nên dễ dàng. Tóm lại, P4 có thể được xem là điểm cân bằng giữa tính tổng quát của Click (khiến việc suy luận phụ thuộc và ánh xạ tới phần cứng trở nên khó khăn) và tính không linh hoạt của OpenFlow 1.0 (khiến không thể cấu hình lại việc xử lý giao thức).

4 P4 NGÔN NGỮ QUA VÍ DỤ

Chúng tôi khám phá P4 bằng cách xem xét một ví dụ đơn giản một cách chi tiết. Nhiều triển khai mạng phân biệt giữa biên và lõi; các máy chủ cuối được kết nối trực tiếp với các thiết bị biên, và các thiết bị này lại được kết nối với nhau thông qua một lõi băng thông cao. Các giao thức hoàn chỉnh đã được thiết kế để hỗ trợ kiến trúc này (chẳng hạn như MPLS [11] và PortLand [12]), chủ yếu nhằm đơn giản hóa việc chuyển tiếp trong lõi.

Xét một ví dụ triển khai mạng L2 với các chuyển mạch top-of-rack (ToR) ở biên được kết nối bởi một lõi hai tầng. Chúng tôi giả sử số lượng máy chủ cuối đang tăng lên và các bảng L2 lõi đang bị tràn. MPLS là một lựa chọn để đơn giản hóa lõi, nhưng việc triển khai một giao thức phân phối nhãn với nhiều thẻ là một nhiệm vụ khó khăn. PortLand có vẻ thú vị nhưng yêu cầu viết lại các địa chỉ MAC, có khả năng làm hỏng các công cụ gỡ lỗi mạng hiện có, và yêu cầu các tác nhân mới phản hồi các yêu cầu ARP.

P4 cho phép chúng tôi biểu diễn một giải pháp tùy chỉnh với những thay đổi tối thiểu đối với kiến trúc mạng. Chúng tôi gọi ví dụ đồ chơi của mình là mTag: nó kết hợp định tuyến phân cấp của PortLand với các thẻ đơn giản giống MPLS. Các tuyến đường qua lõi được mã hóa bằng một thẻ 32-bit gồm bốn trường một byte. Thẻ 32-bit có thể mang một “tuyến nguồn” hoặc một bộ định vị đích (giống như Pseudo MAC của PortLand). Mỗi chuyển mạch lõi chỉ cần kiểm tra một byte của thẻ và chuyển mạch dựa trên thông tin đó. Trong ví dụ của chúng tôi, thẻ được thêm bởi chuyển mạch ToR đầu tiên, mặc dù nó cũng có thể được thêm bởi NIC của máy chủ cuối.

Ví dụ mTag được cố ý làm rất đơn giản để tập trung sự chú ý của chúng tôi vào ngôn ngữ lập trình P4. Chương trình P4 cho toàn bộ một chuyển mạch trong thực tế sẽ phức tạp hơn nhiều lần.

4.1 Các khái niệm P4

Một chương trình P4 chứa các định nghĩa của các thành phần chính sau: • Phần đầu: Một định nghĩa phần đầu mô tả chuỗi và cấu trúc của một chuỗi các trường. Nó bao gồm đặc tả về độ rộng trường và các ràng buộc đối với giá trị trường. • Bộ phân tích cú pháp: Một định nghĩa bộ phân tích cú pháp đặc tả cách xác định các phần đầu và các chuỗi phần đầu hợp lệ bên trong các gói tin. • Bảng: Các bảng so khớp+hành động là cơ chế để thực hiện xử lý gói tin. Chương trình P4 định nghĩa các trường mà một bảng có thể so khớp và các hành động mà nó có thể thực thi. • Hành động: P4 hỗ trợ xây dựng các hành động phức tạp từ các nguyên thủy đơn giản độc lập với giao thức. Các hành động phức tạp này có sẵn bên trong các bảng so khớp+hành động. • Chương trình điều khiển: Chương trình điều khiển xác định thứ tự của các bảng so khớp+hành động được áp dụng cho một gói tin. Một chương trình mệnh lệnh đơn giản mô tả luồng điều khiển giữa các bảng so khớp+hành động. Tiếp theo, chúng tôi chỉ ra cách mỗi thành phần này đóng góp vào việc định nghĩa một bộ xử lý mTag lý tưởng hóa trong P4.

4.2 Các định dạng phần đầu

Một thiết kế bắt đầu với đặc tả của các định dạng phần đầu. Một số ngôn ngữ dành riêng cho miền đã được đề xuất cho việc này [13, 14, 15]; P4 mượn một số ý tưởng từ chúng. Nói chung, mỗi phần đầu được đặc tả bằng cách khai báo một danh sách có thứ tự các tên trường cùng với độ rộng của chúng. Các chú thích trường tùy chọn cho phép các ràng buộc về khoảng giá trị hoặc độ dài tối đa cho các trường có kích thước thay đổi. Ví dụ, các phần đầu Ethernet và VLAN chuẩn được đặc tả như sau:

            
              header ethernet {
    fields {
        dst_addr : 48; // width in bits
        src_addr : 48;
        ethertype : 16;
    }
}

header vlan {
    fields {
        pcp : 3;
        cfi : 1;
        vid : 12;
        ethertype : 16;
    }
}
            
          

Phần đầu mTag có thể được thêm vào mà không thay đổi các khai báo hiện có. Các tên trường chỉ ra rằng lõi có hai lớp tập hợp. Mỗi chuyển mạch lõi được lập trình với các quy tắc để kiểm tra một trong các byte này được xác định bởi vị trí của nó trong phân cấp và hướng di chuyển (lên hoặc xuống).

            
              header mTag {
    fields {
        up1 : 8;
        up2 : 8;
        down1 : 8;
        down2 : 8;
        ethertype : 16;
    }
}
            
          

4.3 Bộ phân tích cú pháp gói tin

P4 giả định rằng chuyển mạch bên dưới có thể triển khai một máy trạng thái duyệt qua các phần đầu gói tin từ đầu đến cuối, trích xuất các giá trị trường khi nó thực hiện. Các giá trị trường được trích xuất được gửi đến các bảng so khớp+hành động để xử lý.

P4 mô tả trực tiếp máy trạng thái này dưới dạng tập hợp các chuyển tiếp từ một phần đầu sang phần đầu tiếp theo. Mỗi chuyển tiếp có thể được kích hoạt bởi các giá trị trong phần đầu hiện tại. Ví dụ, chúng tôi mô tả máy trạng thái mTag như sau.

            
              parser start{
ethernet;
}

parser ethernet {
    switch(ethertype) {
        case 0x8100: vlan;
        case 0x9100: vlan;
        case 0x800: ipv4;
        // Other cases
    }
}

parser vlan {
    switch(ethertype) {
        case 0xaaaa: mTag;
        case 0x800: ipv4;
        // Other cases
    }
}

parser mTag {
    switch(ethertype) {
        case 0x800: ipv4;
        // Other cases
    }
}
            
          

Việc phân tích cú pháp bắt đầu ở trạng thái bắt đầu và tiếp tục cho đến khi đạt tới một trạng thái dừng tường minh hoặc gặp một trường hợp chưa được xử lý (có thể được đánh dấu là một lỗi). Khi đạt tới một trạng thái dành cho một phần đầu mới, máy trạng thái trích xuất phần đầu bằng cách sử dụng đặc tả của nó và tiếp tục xác định chuyển tiếp tiếp theo. Các phần đầu được trích xuất được chuyển tiếp đến xử lý so khớp+hành động ở phần sau của đường ống chuyển mạch.

Bộ phân tích cú pháp cho $mTag$ rất đơn giản: nó chỉ có bốn trạng thái. Các bộ phân tích cú pháp trong các mạng thực tế yêu cầu nhiều trạng thái hơn; ví dụ, bộ phân tích cú pháp được định nghĩa bởi Gibb et. al. [16, Figure 3(e)] mở rộng đến hơn một trăm trạng thái.

4.4 Đặc tả bảng

Tiếp theo, lập trình viên mô tả cách các trường phần đầu đã định nghĩa được so khớp trong các giai đoạn so khớp+hành động (ví dụ, chúng có nên là các so khớp chính xác, các khoảng, hay các ký tự đại diện?) và những hành động nào nên được thực hiện khi một so khớp xảy ra.

Trong ví dụ $mTag$ đơn giản của chúng tôi, chuyển mạch biên khớp với đích L2 và VLAN ID, đồng thời chọn một $mTag$ để thêm vào phần đầu. Lập trình viên định nghĩa một bảng để khớp trên các trường này và áp dụng một hành động để thêm phần đầu $mTag$ (xem bên dưới). Thuộc tính reads khai báo các trường cần khớp, được xác định kèm theo kiểu khớp (exact, ternary, v.v.). Thuộc tính actions liệt kê các hành động khả dĩ có thể được áp dụng cho một gói tin bởi bảng. Các hành động được giải thích trong phần tiếp theo. Thuộc tính max_size chỉ định số mục nhập mà bảng cần hỗ trợ.

Đặc tả bảng cho phép trình biên dịch quyết định lượng bộ nhớ cần thiết và kiểu bộ nhớ (ví dụ: TCAM hoặc SRAM) để triển khai bảng.

            
              table mTag_table {
reads {
        ethernet.dst_addr : exact;
        vlan.vid : exact;
    }
    actions {
        // At runtime, entries are programmed with params
        // for the mTag action. See below.
        add_mTag;
    }
    max_size : 20000;
}
            
          

Để đầy đủ và phục vụ thảo luận sau này, chúng tôi trình bày các định nghĩa ngắn gọn về những bảng khác được tham chiếu bởi Chương trình điều khiển (\S4.6).

            
              table source_check {
    // Verify mtag only on ports to the core
    reads {
        mtag : valid; // Was mtag parsed?
        metadata.ingress_port : exact;
    }
    actions { // Each table entry specifies *one* action
        // If inappropriate mTag, send to CPU
        fault_to_cpu;
// If mtag found, strip and record in metadata
        strip_mtag;
// Otherwise, allow the packet to continue
        pass;
    }
    max_size : 64; // One rule per port
}

table local_switching {
    // Reads destination and checks if local
    // If miss occurs, goto mtag table.
}

table egress_check {
    // Verify egress is resolved
    // Do not retag packets received with tag
    // Reads egress and whether packet was mTagged
}
            
          

4.5 Đặc tả hành động

P4 định nghĩa một tập hợp các hành động nguyên thủy từ đó các hành động phức tạp hơn được xây dựng. Mỗi chương trình P4 khai báo một tập hợp các hàm hành động được tạo thành từ các hành động nguyên thủy; các hàm hành động này đơn giản hóa đặc tả và việc nạp dữ liệu cho bảng. P4 giả định thực thi song song các hành động nguyên thủy bên trong một hàm hành động. (Các chuyển mạch không có khả năng thực thi song song có thể mô phỏng ngữ nghĩa này.)

Hành động add_mTag được đề cập ở trên được triển khai như sau:

            
              action add_mTag(up1, up2, down1, down2, egr_spec) {
    add_header(mTag);
    // Copy VLAN ethertype to mTag
    copy_field(mTag.ethertype, vlan.ethertype);
// Set VLAN’s ethertype to signal mTag
set_field(vlan.ethertype, 0xaaaa);
set_field(mTag.up1, up1);
set_field(mTag.up2, up2);
set_field(mTag.down1, down1);
set_field(mTag.down2, down2);
// Set the destination egress port as well
set_field(metadata.egress_spec, egr_spec);
}
            
          

Nếu một hành động cần các tham số (ví dụ, giá trị up1 cho mTag), nó được cung cấp từ bảng khớp tại thời gian chạy.

Trong ví dụ này, chuyển mạch chèn mTag sau thẻ VLAN, sao chép ethertype của thẻ VLAN vào mTag để chỉ ra nội dung tiếp theo, và đặt ethertype của thẻ VLAN thành 0xaaaa để báo hiệu mTag. Không được trình bày là đặc tả hành động nghịch đảo để loại bỏ một mTag khỏi một gói tin và bảng để áp dụng hành động này trong các chuyển mạch biên.

Các hành động nguyên thủy của P4 bao gồm: • set_field: Đặt một trường cụ thể trong một phần đầu thành một giá trị. Các phép đặt có mặt nạ được hỗ trợ. • copy_field: Sao chép một trường sang một trường khác. • add_header: Đặt một thể hiện phần đầu cụ thể (và tất cả các trường của nó) là hợp lệ. • remove_header: Xóa (“pop”) một phần đầu (và tất cả các trường của nó) khỏi một gói tin. • increment: Tăng hoặc giảm giá trị trong một trường. • checksum: Tính toán checksum trên một tập hợp các trường phần đầu nào đó (ví dụ, checksum IPv4). Chúng tôi kỳ vọng rằng hầu hết các triển khai chuyển mạch sẽ hạn chế xử lý hành động để chỉ cho phép các sửa đổi phần đầu nhất quán với định dạng gói tin được đặc tả.

4.6 Chương trình điều khiển

Một khi các bảng và hành động được định nghĩa, nhiệm vụ còn lại duy nhất là đặc tả luồng điều khiển từ một bảng đến bảng tiếp theo. Luồng điều khiển được đặc tả như một chương trình thông qua một tập hợp các hàm, điều kiện và tham chiếu bảng.

Hình.

Hình 4 cho thấy biểu diễn đồ họa của luồng điều khiển mong muốn cho việc triển khai mTag trên các chuyển mạch biên. Sau khi phân tích cú pháp, bảng source_check xác minh tính nhất quán giữa gói tin nhận được và cổng vào. Ví dụ, các mTag chỉ nên xuất hiện trên các cổng được kết nối với các chuyển mạch lõi. source_check cũng loại bỏ các mTag khỏi gói tin, ghi lại liệu gói tin có một mTag trong metadata hay không. Các bảng sau đó trong đường ống có thể khớp trên metadata này để tránh gắn thẻ lại gói tin.

Bảng local_switching sau đó được thực thi. Nếu bảng này “misses,” điều đó chỉ ra rằng gói tin không được gửi đến một máy chủ được kết nối cục bộ. Trong trường hợp đó, mTag_table (được định nghĩa ở trên) được áp dụng cho gói tin. Cả điều khiển chuyển tiếp cục bộ và lõi có thể được xử lý bởi bảng egress_check, bảng này xử lý trường hợp đích không xác định bằng cách gửi một thông báo lên ngăn xếp điều khiển SDN.

Biểu diễn mệnh lệnh của đường ống xử lý gói tin này như sau:

            
              control main() {
    // Verify mTag state and port are consistent
    table(source_check);
// If no error from source_check, continue
    if (!defined(metadata.ingress_error)) {
        // Attempt to switch to end hosts
        table(local_switching);
if (!defined(metadata.egress_spec)) {
            // Not a known local host; try mtagging
            table(mTag_table);
        }
// Check for unknown egress state or bad retagging with mTag.
        table(egress_check);
    }
}
            
          

5 BIÊN DỊCH MỘT CHƯƠNG TRÌNH P4

Để một mạng triển khai chương trình P4 của chúng tôi, cần có một trình biên dịch để ánh xạ mô tả độc lập với mục tiêu lên nền tảng phần cứng hoặc phần mềm cụ thể của chuyển mạch mục tiêu. Việc này bao gồm cấp phát các tài nguyên của mục tiêu và tạo cấu hình thích hợp cho thiết bị.

5.1 Biên dịch các bộ phân tích cú pháp gói tin

Đối với các thiết bị có bộ phân tích cú pháp có thể lập trình, trình biên dịch dịch mô tả bộ phân tích cú pháp thành một máy trạng thái phân tích cú pháp, trong khi đối với các bộ phân tích cú pháp cố định, trình biên dịch chỉ xác minh rằng mô tả bộ phân tích cú pháp nhất quán với bộ phân tích cú pháp của mục tiêu. Chi tiết về việc tạo máy trạng thái và các mục nhập bảng trạng thái có thể được tìm thấy trong [16].

Table 2 hiển thị các mục nhập bảng trạng thái cho các phần vlan và mTag của bộ phân tích cú pháp (§4.3). Mỗi mục nhập chỉ định trạng thái hiện tại, giá trị trường cần so khớp và trạng thái tiếp theo. Các cột khác được bỏ qua để ngắn gọn.

Table 2: Các mục nhập bảng trạng thái của bộ phân tích cú pháp cho ví dụ mTag.

5.2 Biên dịch các chương trình điều khiển

Biểu diễn luồng điều khiển bắt buộc trong §4.6 là một cách thuận tiện để đặc tả hành vi chuyển tiếp logic của một chuyển mạch, nhưng không chỉ rõ các phụ thuộc giữa các bảng hoặc các cơ hội cho tính đồng thời. Do đó, chúng tôi sử dụng một trình biên dịch để phân tích chương trình điều khiển nhằm xác định các phụ thuộc và tìm kiếm các cơ hội xử lý các trường phần đầu song song. Cuối cùng, trình biên dịch tạo cấu hình mục tiêu cho chuyển mạch. Có nhiều mục tiêu tiềm năng: ví dụ, một chuyển mạch phần mềm [17], một chuyển mạch phần mềm đa lõi [18], một NPU [19], một chuyển mạch chức năng cố định [20], hoặc một đường ống bảng so khớp có thể cấu hình lại (RMT) [2].

Như đã thảo luận trong §3, trình biên dịch tuân theo một quy trình biên dịch hai giai đoạn. Đầu tiên, nó chuyển đổi chương trình điều khiển P4 thành một biểu diễn đồ thị phụ thuộc bảng trung gian, sau đó phân tích biểu diễn này để xác định các phụ thuộc giữa các bảng. Một phần cuối dành riêng cho mục tiêu sau đó ánh xạ đồ thị này lên các tài nguyên cụ thể của chuyển mạch.

Chúng tôi xem xét ngắn gọn cách ví dụ mTag sẽ được triển khai trong các loại chuyển mạch khác nhau:

Chuyển mạch phần mềm: Một chuyển mạch phần mềm cung cấp tính linh hoạt hoàn toàn: số lượng bảng, cấu hình bảng và phân tích cú pháp đều nằm dưới sự điều khiển của phần mềm. Trình biên dịch ánh xạ trực tiếp đồ thị bảng mTag tới các bảng chuyển mạch. Trình biên dịch sử dụng thông tin kiểu bảng để giới hạn độ rộng, chiều cao bảng và tiêu chí so khớp (ví dụ: chính xác, tiền tố hoặc ký tự đại diện) của mỗi bảng. Trình biên dịch cũng có thể tối ưu hóa so khớp tam phân hoặc so khớp tiền tố bằng các cấu trúc dữ liệu phần mềm.

Các chuyển mạch phần cứng với RAM và TCAM: Một trình biên dịch có thể cấu hình băm để thực hiện so khớp chính xác hiệu quả bằng RAM cho mTag_table trong các chuyển mạch biên. Ngược lại, bảng chuyển tiếp mTag lõi so khớp trên một tập con các bit thẻ sẽ được ánh xạ tới TCAM.

Các chuyển mạch hỗ trợ các bảng song song: Trình biên dịch có thể phát hiện các phụ thuộc dữ liệu và sắp xếp các bảng song song hoặc nối tiếp. Trong ví dụ mTag, các bảng local_switching và mTag_table có thể thực thi song song cho đến khi thực thi hành động thiết lập một mTag.

Các chuyển mạch áp dụng hành động ở cuối đường ống: Đối với các chuyển mạch chỉ xử lý hành động ở cuối một đường ống, trình biên dịch có thể yêu cầu các giai đoạn trung gian tạo metadata được sử dụng để thực hiện các ghi cuối cùng. Trong ví dụ mTag, việc mTag được thêm vào hay loại bỏ có thể được biểu diễn trong metadata.

Các chuyển mạch có ít bảng: Trình biên dịch có thể ánh xạ một số lượng lớn các bảng P4 tới một số lượng nhỏ hơn các bảng vật lý. Trong ví dụ mTag, chuyển mạch cục bộ có thể được kết hợp với bảng mTag. Khi bộ điều khiển cài đặt các quy tắc mới trong thời gian chạy, bộ dịch quy tắc của trình biên dịch có thể “compose” các quy tắc trong hai bảng P4 để tạo ra các quy tắc cho một bảng vật lý duy nhất.

6 KẾT LUẬN

Lời hứa của SDN là một mặt phẳng điều khiển duy nhất có thể trực tiếp điều khiển toàn bộ một mạng các chuyển mạch. OpenFlow hỗ trợ mục tiêu này bằng cách cung cấp một API duy nhất, không phụ thuộc nhà cung cấp. Tuy nhiên, OpenFlow ngày nay hướng tới các chuyển mạch có chức năng cố định, nhận biết một tập các trường phần đầu được xác định trước và xử lý các gói tin bằng một tập nhỏ các hành động được định nghĩa trước. Mặt phẳng điều khiển không thể biểu đạt cách các gói tin nên được xử lý để đáp ứng tốt nhất nhu cầu của các ứng dụng điều khiển.

Chúng tôi đề xuất một bước tiến hướng tới các chuyển mạch linh hoạt hơn, trong đó chức năng được đặc tả — và có thể được thay đổi — trong quá trình triển khai. Lập trình viên quyết định cách mặt phẳng chuyển tiếp xử lý các gói tin mà không cần lo lắng về các chi tiết triển khai. Một trình biên dịch chuyển đổi một chương trình mệnh lệnh thành một đồ thị phụ thuộc bảng có thể được ánh xạ tới nhiều chuyển mạch đích cụ thể, bao gồm cả các triển khai phần cứng được tối ưu hóa.

Chúng tôi nhấn mạnh rằng đây chỉ là bước đầu tiên, được thiết kế như một đề xuất sơ bộ cho OpenFlow 2.0 nhằm đóng góp vào cuộc tranh luận. Trong đề xuất này, một số khía cạnh của một chuyển mạch vẫn chưa được xác định (ví dụ, các nguyên thủy điều khiển tắc nghẽn, các chính sách xếp hàng, giám sát lưu lượng). Tuy nhiên, chúng tôi tin rằng cách tiếp cận sử dụng một ngôn ngữ cấu hình — và các trình biên dịch tạo ra các cấu hình mức thấp cho các đích cụ thể — sẽ dẫn tới các chuyển mạch trong tương lai cung cấp tính linh hoạt cao hơn, đồng thời khai phá tiềm năng của các mạng được định nghĩa bằng phần mềm.