P4: Programming Protocol-Independent Packet Processors

ABSTRACT

P4 is a high-level language for programming protocol-independent packet processors. P4 works in conjunction with SDN control protocols like OpenFlow. In its current form, OpenFlow explicitly specifies protocol headers on which it operates. This set has grown from 12 to 41 fields in a few years, increasing the complexity of the specification while still not providing the flexibility to add new headers. In this paper we propose P4 as a strawman proposal for how OpenFlow should evolve in the future. We have three goals: (1) Reconfigurability in the field: Programmers should be able to change the way switches process packets once they are deployed. (2) Protocol independence: Switches should not be tied to any specific network protocols. (3) Target independence: Programmers should be able to describe packet-processing functionality independently of the specifics of the underlying hardware. As an example, we describe how to use P4 to configure a switch to add a new hierarchical label.

P4: Lập trình các bộ xử lý gói tin độc lập với giao thức

Pat Bosshart†, Dan Daly, Glen Gibb†, Martin Izzard†, Nick McKeown‡, Jennifer Rexford, Cole Schlesinger, Dan Talayco†, Amin Vahdat†, George Varghese§, David Walker* †Barefoot Networks Intel ‡Stanford University *Princeton University †Google §Microsoft Research

TÓM TẮT P4 là một ngôn ngữ lập trình cấp cao để lập trình các bộ xử lý gói tin độc lập với giao thức. P4 hoạt động kết hợp với các giao thức điều khiển SDN như OpenFlow. Ở dạng hiện tại, OpenFlow đặc tả rõ ràng các phần đầu giao thức mà nó vận hành trên đó. Tập hợp này đã tăng từ 12 lên 41 trường trong vài năm, làm tăng độ phức tạp của đặc tả trong khi vẫn không cung cấp tính linh hoạt để thêm các phần đầu mới. Trong bài báo này, chúng tôi đề xuất P4 như một đề xuất sơ bộ cho cách OpenFlow nên phát triển trong tương lai. Chúng tôi có ba mục tiêu: (1) Khả năng cấu hình lại trong thực địa: Các lập trình viên có thể thay đổi cách các chuyển mạch xử lý các gói tin sau khi chúng được triển khai. (2) Tính độc lập với giao thức: Các chuyển mạch không nên bị ràng buộc với bất kỳ giao thức mạng cụ thể nào. (3) Tính độc lập với mục tiêu: Các lập trình viên có thể mô tả chức năng xử lý gói tin một cách độc lập với các chi tiết của phần cứng bên dưới. Ví dụ, chúng tôi mô tả cách sử dụng P4 để cấu hình một chuyển mạch nhằm thêm một nhãn phân cấp mới.

1 INTRODUCTION

1 GIỚI THIỆU

Software-Defined Networking (SDN) gives operators programmatic control over their networks. In SDN, the control plane is physically separate from the forwarding plane, and one control plane controls multiple forwarding devices. While forwarding devices could be programmed in many ways, having a common, open, vendor-agnostic interface (like OpenFlow) enables a control plane to control forwarding devices from different hardware and software vendors.

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.

Table 1: Fields recognized by the OpenFlow standard

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

The OpenFlow interface started simple, with the abstraction of a single table of rules that could match packets on a dozen header fields (e.g., MAC addresses, IP addresses, protocol, TCP/UDP port numbers, etc.). Over the past five years, the specification has grown increasingly more complicated (see Table 1), with many more header fields and multiple stages of rule tables, to allow switches to expose more of their capabilities to the controller.

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.

The proliferation of new header fields shows no signs of stopping. For example, data-center network operators increasingly want to apply new forms of packet encapsulation (e.g., NVGRE, VXLAN, and STT), for which they resort to deploying software switches that are easier to extend with new functionality. Rather than repeatedly extending the OpenFlow specification, we argue that future switches should support flexible mechanisms for parsing packets and matching header fields, allowing controller applications to leverage these capabilities through a common, open interface (i.e., a new “OpenFlow 2.0” API). Such a general, extensible approach would be simpler, more elegant, and more future-proof than today’s OpenFlow 1.x standard.

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.

Figure.

Hình.

Recent chip designs demonstrate that such flexibility can be achieved in custom ASICs at terabit speeds [1][2][3]. Programming this new generation of switch chips is far from easy. Each chip has its own low-level interface, akin to microcode programming. In this paper, we sketch the design of a higher-level language for Programming Protocol-independent Packet Processors (P4). Figure 1 shows the relationship between P4—used to configure a switch, telling it how packets are to be processed—and existing APIs (such as OpenFlow) that are designed to populate the forwarding tables in fixed function switches. P4 raises the level of abstraction for programming the network, and can serve as a general interface between the controller and the switches. That is, we believe that future generations of OpenFlow should allow the controller to tell the switch how to operate, rather than be constrained by a fixed switch design. The key challenge is to find a “sweet spot” that balances the need for expressiveness with the ease of implementation across a wide range of hardware and software switches. In designing P4, we have three main goals: • Reconfigurability. The controller should be able to redefine the packet parsing and processing in the field. • Protocol independence. The switch should not be tied to specific packet formats. Instead, the controller should be able to specify (i) a packet parser for extracting header fields with particular names and types and (ii) a collection of typed match+action tables that process these headers. • Target independence. Just as a C programmer does not need to know the specifics of the underlying CPU, the controller programmer should not need to know the details of the underlying switch. Instead, a compiler should take the switch’s capabilities into account when turning a target-independent description (written in P4) into a target-dependent program (used to configure the switch). The outline of the paper is as follows. We begin by introducing an abstract switch forwarding model. Next, we explain the need for a new language to describe protocol-independent packet processing. We then present a simple motivating example where a network operator wants to support a new packet-header field and process packets in multiple stages. We use this to explore how the P4 program specifies headers, the packet parser, the multiple match+action tables, and the control flow through these tables. Finally, we discuss how a compiler can map P4 programs to target switches.

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.

Related work. In 2011, Yadav et al. [4] proposed an abstract forwarding model for OpenFlow, but with less emphasis on a compiler. Kangaroo [1] introduced the notion of programmable parsing. Recently, Song [5] proposed protocol-oblivious forwarding which shares our goal of protocol independence, but is targeted more towards network processors. The ONF introduced table typing patterns to express the matching capabilities of switches [6]. Recent work on NOSIX [7] shares our goal of flexible specification of match+action tables, but does not consider protocol-independence or propose a language for specifying the parser, tables, and control flow. Other recent work proposes a programmatic interface to the data plane for monitoring, congestion control, and queue management [8][9]. The Click modular router [10] supports flexible packet processing in software, but does not map programs to a variety of target hardware switches.

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 ABSTRACT FORWARDING MODEL

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

In our abstract model (Fig. 2), switches forward packets via a programmable parser followed by multiple stages of match+action, arranged in series, parallel, or a combination of both. Derived from OpenFlow, our model makes three generalizations. First, OpenFlow assumes a fixed parser, whereas our model supports a programmable parser to allow new headers to be defined. Second, OpenFlow assumes the match+action stages are in series, whereas in our model they can be in parallel or in series. Third, our model assumes that actions are composed from protocol-independent primitives supported by the switch.

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ợ.

Our abstract model generalizes how packets are processed in different forwarding devices (e.g., Ethernet switches, routers, load-balancers) and by different technologies (e.g., fixed-function switch ASICs, NPUs, reconfigurable switches, software switches, FPGAs). This allows us to devise a common language (P4) to represent how packets are processed in terms of our common abstract model. Hence, programmers can create target-independent programs that a compiler can map to a variety of different forwarding devices, ranging from relatively slow software switches to the fastest ASIC-based switches.

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.

Figure.

Hình.

The forwarding model is controlled by two types of operations: Configure and Populate. Configure operations program the parser, set the order of match+action stages, and specify the header fields processed by each stage. Configuration determines which protocols are supported and how the switch may process packets. Populate operations add (and remove) entries to the match+action tables that were specified during configuration. Population determines the policy applied to packets at any given time.

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.

For the purposes of this paper, we assume that configuration and population are two distinct phases. In particular, the switch need not process packets during configuration. However, we expect implementations will allow packet processing during partial or full reconfiguration enabling upgrades with no downtime. Our model deliberately allows for, and encourages, reconfiguration that does not interrupt forwarding.

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.

Clearly, the configuration phase has little meaning in fixed-function ASIC switches; for this type of switch, the compiler’s job is to simply check if the chip can support the P4 program. Instead, our goal is to capture the general trend towards fast reconfigurable packet-processing pipelines, as described in [2][3].

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].

Arriving packets are first handled by the parser. The packet body is assumed to be buffered separately, and unavailable for matching. The parser recognizes and extracts fields from the header, and thus defines the protocols supported by the switch. The model makes no assumptions about the meaning of protocol headers, only that the parsed representation defines a collection of fields on which matching and actions operate.

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.

The extracted header fields are then passed to the match+action tables. The match+action tables are divided between ingress and egress. While both may modify the packet header, ingress match+action determines the egress port(s) and determines the queue into which the packet is placed. Based on ingress processing, the packet may be forwarded, replicated (for multicast, span, or to the control plane), dropped, or trigger flow control. Egress match+action performs per-instance modifications to the packet header – e.g., for multicast copies. Action tables (counters, policers, etc.) can be associated with a flow to track frame-to-frame state.

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.

Packets can carry additional information between stages, called metadata, which is treated identically to packet header fields. Some examples of metadata include the ingress port, the transmit destination and queue, a timestamp that can be used for packet scheduling, and data passed from table-to-table that does not involve changing the parsed representation of the packet such as a virtual network identifier.

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.

Queueing disciplines are handled in the same way as the current OpenFlow: an action maps a packet to a queue, which is configured to receive a particular service discipline. The service discipline (e.g., minimum rate, DRR) is chosen as part of the switch configuration.

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.

Although beyond the scope of this paper, action primitives can be added to allow the programmer to implement new or existing congestion control protocols. For example, the switch might be programmed to set the ECN bit based on novel conditions, or it might implement a proprietary congestion control mechanism using match+action tables.

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 A PROGRAMMING LANGUAGE

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

We use the abstract forwarding model to define a language to express how a switch is to be configured and how packets are to be processed. This paper’s main goal is to propose the P4 programming language. However, we recognize that many languages are possible, and they will likely share the common characteristics we describe here. For example, the language needs a way to express how the parser is programmed so that the parser knows what packet formats to expect; hence a programmer needs a way to declare what header types are possible. As an example, the programmer could specify the format of an IPv4 header and what headers may legally follow the IP header. This motivates defining parsing in P4 by declaring legal header types. Similarly, the programmer needs to express how packet headers are to be processed. For example, TTL fields must be decremented and tested, new tunnel headers may need to be added, and checksums may need to be computed. This motivates P4’s use of an imperative control flow program to describe header field processing using the declared header types and a primitive set of actions.

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.

We could use a language such as Click [10], which builds switches from modules composed of arbitrary C++. Click is extremely expressive, and very suitable for expressing how packets are processed in the kernel of a CPU. But it is insufficiently constrained for our needs—we need a language that mirrors the parse-match-action pipelines in dedicated hardware. In addition, Click is not designed for a controller-switch architecture and hence does not allow programmers to describe match+action tables that are dynamically populated by well-typed rules. Finally, Click makes it difficult to infer dependencies that constrain parallel execution—as we now discuss.

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.

A packet processing language must allow the programmer to express (implicitly or explicitly) any serial dependencies between header fields. Dependencies determine which tables can be executed in parallel. For example, sequential execution is required for an IP routing table and an ARP table due to the data dependency between them. Dependencies can be identified by analyzing Table Dependency Graphs (TDGs); these graphs describe the field inputs, actions, and control flow between tables. Figure 3 shows an example table dependency graph for an L2/L3 switch. TDG nodes map directly to match+action tables, and a dependency analysis identifies where each table may reside in the pipeline. Unfortunately TDGs are not readily accessible to most programmers; programmers tend to think of packet processing algorithms using imperative constructs rather than graphs.

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ị.

Figure.

Hình.

This leads us to propose a two-step compilation process. At the highest level, programmers express packet processing programs using an imperative language representing the control flow (P4); below this, a compiler translates the P4 representation to TDGs to facilitate dependency analysis, and then maps the TDG to a specific switch target. P4 is designed to make it easy to translate a P4 program into a TDG. In summary, P4 can be considered to be a sweet spot between the generality of say Click (that makes it difficult to infer dependencies and map to hardware) and the inflexibility of OpenFlow 1.0 (that makes it impossible to reconfigure protocol processing).

Đ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 LANGUAGE BY EXAMPLE

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

We explore P4 by examining a simple example in-depth. Many network deployments differentiate between an edge and a core; end-hosts are directly connected to edge devices, which are in turn interconnected by a high-bandwidth core. Entire protocols have been designed to support this architecture (such as MPLS [11] and PortLand [12]), aimed primarily at simplifying forwarding in the core.

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.

Consider an example L2 network deployment with top-of-rack (ToR) switches at the edge connected by a two-tier core. We will assume the number of end-hosts is growing and the core L2 tables are overflowing. MPLS is an option to simplify the core, but implementing a label distribution protocol with multiple tags is a daunting task. PortLand looks interesting but requires rewriting MAC addresses—possibly breaking existing network debugging tools—and requires new agents to respond to ARP requests.

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 lets us express a custom solution with minimal changes to the network architecture. We call our toy example mTag: it combines the hierarchical routing of PortLand with simple MPLS-like tags. The routes through the core are encoded by a 32-bit tag composed of four single-byte fields. The 32-bit tag can carry a “source route” or a destination locator (like PortLand’s Pseudo MAC). Each core switch need only examine one byte of the tag and switch on that information. In our example, the tag is added by the first ToR switch, although it could also be added by the end-host NIC.

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.

The mTag example is intentionally very simple to focus our attention on the P4 language. The P4 program for an entire switch would be many times more complex in practice.

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 P4 Concepts

4.1 Các khái niệm P4

A P4 program contains definitions of the following key components: • Headers: A header definition describes the sequence and structure of a series of fields. It includes specification of field widths and constraints on field values. • Parsers: A parser definition specifies how to identify headers and valid header sequences within packets. • Tables: Match+action tables are the mechanism for performing packet processing. The P4 program defines the fields on which a table may match and the actions it may execute. • Actions: P4 supports construction of complex actions from simpler protocol-independent primitives. These complex actions are available within match+action tables. • Control Programs: The control program determines the order of match+action tables that are applied to a packet. A simple imperative program describe the flow of control between match+action tables. Next, we show how each of these components contributes to the definition of an idealized mTag processor in 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 Header Formats

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

A design begins with the specification of header formats. Several domain-specific languages have been proposed for this [13, 14, 15]; P4 borrows a number of ideas from them. In general, each header is specified by declaring an ordered list of field names together with their widths. Optional field annotations allow constraints on value ranges or maximum lengths for variable-sized fields. For example, standard Ethernet and VLAN headers are specified as follows:

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:

The mTag header can be added without altering existing declarations. The field names indicate that the core has two layers of aggregation. Each core switch is programmed with rules to examine one of these bytes determined by its location in the hierarchy and the direction of travel (up or down).

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).

4.3 The Packet Parser

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

P4 assumes the underlying switch can implement a state machine that traverses packet headers from start to finish, extracting field values as it goes. The extracted field values are sent to the match+action tables for processing.

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 describes this state machine directly as the set of transitions from one header to the next. Each transition may be triggered by values in the current header. For example, we describe the mTag state machine as follows.

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.

Parsing starts in the start state and proceeds until an explicit stop state is reached or an unhandled case is encountered (which may be marked as an error). Upon reaching a state for a new header, the state machine extracts the header using its specification and proceeds to identify its next transition. The extracted headers are forwarded to match+action processing in the back-half of the switch pipeline.

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.

The parser for $mTag$ is very simple: it has only four states. Parsers in real networks require many more states; for example, the parser defined by Gibb et. al. [16, Figure 3(e)] expands to over one hundred states.

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 Table Specification

4.4 Đặc tả bảng

Next, the programmer describes how the defined header fields are to be matched in the match+action stages (e.g., should they be exact matches, ranges, or wildcards?) and what actions should be performed when a match occurs.

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.

In our simple $mTag$ example, the edge switch matches on the L2 destination and VLAN ID, and selects an $mTag$ to add to the header. The programmer defines a table to match on these fields and apply an action to add the $mTag$ header (see below). The reads attribute declares which fields to match, qualified by the match type (exact, ternary, etc). The actions attribute lists the possible actions which may be applied to a packet by the table. Actions are explained in the following section. The max_size attribute specifies how many entries the table should support.

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ợ.

The table specification allows a compiler to decide how much memory it needs, and the memory type (e.g., TCAM or SRAM) to implement the table.

Đặ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 {

Để đầ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).

For completeness and for later discussion, we present brief definitions of other tables that are referenced by the Control Program (\S4.6).

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

4.5 Action Specifications

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.)

P4 defines a collection of primitive actions from which more complicated actions are built. Each P4 program declares a set of action functions that are composed of action primitives; these action functions simplify table specification and population. P4 assumes parallel execution of primitives within an action function. (Switches incapable of parallel execution may emulate the semantics.)

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

The add_mTag action referred to above is implemented as follows:

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.

If an action needs parameters (e.g., the up1 value for the mTag), it is supplied from the match table at runtime.

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.

In this example, the switch inserts the mTag after the VLAN tag, copies the VLAN tag’s ethertype into the mTag to indicate what follows, and sets the VLAN tag’s ethertype to 0xaaaa to signal mTag. Not shown are the inverse action specification that strips an mTag from a packet and the table to apply this action in edge switches.

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ả.

P4’s primitive actions include: • set_field: Set a specific field in a header to a value. Masked sets are supported. • copy_field: Copy one field to another. • add_header: Set a specific header instance (and all its fields) as valid. • remove_header: Delete (“pop”) a header (and all its fields) from a packet. • increment: Increment or decrement the value in a field. • checksum: Calculate a checksum over some set of header fields (e.g., an IPv4 checksum). We expect most switch implementations will restrict action processing to permit only header modifications that are consistent with the specified packet format.

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

4.6 The Control Program

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.

Once tables and actions are defined, the only remaining task is to specify the flow of control from one table to the next. Control flow is specified as a program via a collection of functions, conditionals, and table references.

Hình.

Figure.

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.

Figure 4 shows a graphical representation of the desired control flow for the mTag implementation on edge switches. After parsing, the source_check table verifies consistency between the received packet and the ingress port. For example, mTags should only be seen on ports connected to core switches. The source_check also strips mTags from the packet, recording whether the packet had an mTag in metadata. Tables later in the pipeline may match on this metadata to avoid retagging the packet.

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.

The local_switching table is then executed. If this table “misses,” it indicates that the packet is not destined for a locally connected host. In that case, the mTag_table (defined above) is applied to the packet. Both local and core forwarding control can be processed by the egress_check table which handles the case of an unknown destination by sending a notification up the SDN control stack.

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

The imperative representation of this packet processing pipeline is as follows:

Nothing here.

5 COMPILED A P4 PROGRAM

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

For a network to implement our P4 program, we need a compiler to map the target-independent description onto the target switch’s specific hardware or software platform. Doing so involves allocating the target’s resources and generating appropriate configuration for the device.

Để 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 Compiling Packet Parsers

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

For devices with programmable parsers, the compiler translates the parser description into a parsing state machine, while for fixed parsers, the compiler merely verifies that the parser description is consistent with the target’s parser. Details of generating a state machine and state table entries can be found in [16].

Đố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 shows state table entries for the vlan and mTag sections of the parser (§4.3). Each entry specifies the current state, the field value to match, and the next state. Other columns are omitted for brevity.

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: Parser state table entries for the mTag example.

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 Compiling Control Programs

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

The imperative control-flow representation in §4.6 is a convenient way to specify the logical forwarding behavior of a switch, but does not explicitly call out dependencies between tables or opportunities for concurrency. We therefore employ a compiler to analyze the control program to identify dependencies and look for opportunities to process header fields in parallel. Finally, the compiler generates the target configuration for the switch. There are many potential targets: for example, a software switch [17], a multicore software switch [18], an NPU [19], a fixed function switch [20], or a reconfigurable match table (RMT) pipeline [2].

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].

As discussed in §3 the compiler follows a two-stage compilation process. It first converts the P4 control program into an intermediate table dependency graph representation which it analyzes to determine dependencies between tables. A target-specific back-end then maps this graph onto the switch’s specific resources.

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.

We briefly examine how the mTag example would be implemented in different kinds of switches:

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:

Software switches: A software switch provides complete flexibility: the table count, table configuration, and parsing are under software control. The compiler directly maps the mTag table graph to switch tables. The compiler uses table type information to constrain table widths, heights, and matching criterion (e.g., exact, prefix, or wildcard) of each table. The compiler might also optimize ternary or prefix matching with software data structures.

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.

Hardware switches with RAM and TCAM: A compiler can configure hashing to perform efficient exact-matching using RAM, for the mTag_table in edge switches. In contrast, the core mTag forwarding table that matches on a subset of tag bits would be mapped to TCAM.

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.

Switches supporting parallel tables: The compiler can detect data dependencies and arrange tables in parallel or in series. In the mTag example, the tables local_switching and mTag_table can execute in parallel up to the execution of the action of setting an mTag.

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.

Switches that apply actions at the end of the pipeline: For switches with action processing only at the end of a pipeline, the compiler can tell intermediate stages to generate metadata that is used to perform the final writes. In the mTag example, whether the mTag is added or removed could be represented in metadata.

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.

Switches with a few tables: The compiler can map a large number of P4 tables to a smaller number of physical tables. In the mTag example, the local switching could be combined with the mTag table. When the controller installs new rules at runtime, the compiler’s rule translator can “compose” the rules in the two P4 tables to generate the rules for the single physical table.

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 CONCLUSION

6 KẾT LUẬN

The promise of SDN is that a single control plane can directly control a whole network of switches. OpenFlow supports this goal by providing a single, vendor-agnostic API. However, today’s OpenFlow targets fixed-function switches that recognize a pre-determined set of header fields and that process packets using a small set of predefined actions. The control plane cannot express how packets should be processed to best meet the needs of control applications.

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.

We propose a step towards more flexible switches whose functionality is specified—and may be changed—in the field. The programmer decides how the forwarding plane processes packets without worrying about implementation details. A compiler transforms an imperative program into a table dependency graph that can be mapped to many specific target switches, including optimized hardware implementations.

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.

We emphasize that this is only a first step, designed as a straw-man proposal for OpenFlow 2.0 to contribute to the debate. In this proposal, several aspects of a switch remain undefined (e.g., congestion-control primitives, queuing disciplines, traffic monitoring). However, we believe the approach of having a configuration language—and compilers that generate low-level configurations for specific targets—will lead to future switches that provide greater flexibility, and unlock the potential of software defined networks.

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.