Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Advanced Forwarding Interface (AFI) Overview

 

The advanced forwarding interface (AFI) provides you with the ability to programmatically affect the actions taken in a part of the packet forwarding engine. AFI uses a number of elements, which are described herein, to provide a protected area within the forwarding ASIC called a sandbox. Between the sandbox’s input and output ports, you can define nodes that perform various operations on the packets that enter the sandbox. The nodes are class objects that have access to all of the packet forwarding engine functions that are published through the AFI API. This allows for many different decisions to be made regarding what to do with matching packets.

Note

In AFI 1.0, not all packet forwarding engine functions are available as AFI APIs. The primary purpose of this release is to familiarize you with the concepts and capabilities of AFI, not necessarily to allow the creation of fully deployable products based on AFI.

Forwarding Path

The forwarding path or forwarding path graph is an abstraction of the sequence of operations undertaken by the packet forwarding engine when processing a packet. In AFI, the forwarding path is the collection of nodes between the input and output ports in the sandbox. By chaining different node types together to form different paths, you can effectively alter the decisions that the packet forwarding engine would otherwise make. Figure 1 shows a representation of a forwarding path within the packet forwarding engine.

Figure 1: Forwarding Path
Forwarding Path

Sandbox

The sandbox is essentially a walled off area within the packet forwarding engine. The collection of nodes within the sandbox forms a path within the packet forwarding engine that can be controlled programmatically. The sandbox is allocated using configuration statements in Junos OS that provide it with a name, one of three sizes, and at least one set of input and output ports. As the names imply, the input and output ports are where network traffic enters and exits the sandbox respectively. A sandbox is referenced by a text-based name.

Figure 2 shows a representation of a simple sandbox with input and output ports and a counter between input port, port0, and output port, port2.

Figure 2: Sandbox Input and Output Ports
Sandbox Input and Output Ports

Figure 3 shows a more complex sandbox along with its relationship to internal sandbox elements and to outside elements in the packet forwarding engine.

Figure 3: Sandbox Elements
Sandbox Elements

Supported sandbox operations include interfaces for accessing and managing sandbox state (AFTSandbox), inserting nodes (AFTInsert), and removing nodes (AFTRemove).

Port

Ports come in two types: input and output. Each port, regardless of type, gets a name and an association with an interface on the vMX through CLI configuration statements. AFI ports are associated with interfaces on the vMX. Input ports are the entry point into the sandbox. Output ports are the exit points out of the sandbox. Ports are assigned to a sandbox in input/output pairs. A sandbox must have at least one pair of ports, but can have more pairs. Figure 2 shows a simple sandbox with multiple input and output port pairs.

AFI Release 1.0 supports the ability to manage both input and output ports using the classes AftInputPort and AftOutputPort.

Client

You can write an AFI client using the published AFI APIs. AFI clients are developed to achieve specific forwarding path functionality. The connection between client and server is provided and managed by the AFI transport.

The client can also send packets to or receive packets from the forwarding ASIC. An example would be an OSPF control packet. Packets sent in this manner are said to be on the hostpath. The class AftPacket is supplied in AFI Release 1.0 as the way to construct or parse a packet that is sent or received on the hostpath.

Server

The AFI server works in conjunction with the AFI client. The server is the AFI element that implements the operations prescribed by the client. In AFI 1.0 Release, the classes AftEncap and AftDecap are provided for encapsulating and de-encapsulating packets that are sent on the data path.

Node

A node can be thought of like a stepping-stone along a path in the physical world. In AFI, each node represents an operation that can be performed on the packet while it is in the controlled part of the forwarding path. See Figure 3. Combining nodes in different ways allows different forwarding outcomes to be realized. Examples of nodes in AFI are tables, trees, lookups, and conditionals. All nodes have a 64-bit token assigned to them that identifies that node within its sandbox.

All nodes are derived from a common base class called AftNode. Supported nodes in AFI 1.0 Release include discard, lookup, counter, and list.

Key

The two-part tuple of a field and data is called a key. AFI uses specific field and data pairs for describing an individual match condition. For example, a node operation might lookup the input interface for a packet. The metadata field meta.ifinput becomes the field portion of the key and the information returned from the lookup becomes the data. Thus, the key for this type of node operation might look like meta.ifinput:ifd.151

Field

Fields are the basic descriptors that refer to any variable used by a node. Each field is defined by a string. For example, a field can refer to a field in a packet like packet.ip4.ttl, packet.ip6.daddr, or packet.mpls.label. Fields are also used to refer to any metadata used during a lookup like meta.ifinput, meta.nhid, or meta.ifoutput. A field is also one part of a two-part tuple called a key. Figure 4 shows how the fields of a TCP packet header could be used as fields in AFI.

Figure 4: TCP Packet Header Fields
TCP Packet Header Fields

Data

In AFI, data refers to the different types of data that is returned from the node operations. Things like IPv4 addresses, Ethernet addresses, address prefixes, and scalars are all considered data in AFI.

In AFI Release 1.0, there is support for the base object class, AftData, as well as object classes for integers, byte-array prefixes, IPv4 addresses, MAC addresses, and MPLS labels.

Entry

An entry is the individual match in a lookup node such as tree, table, hash, and so on. It is the individual match element for a container. An entry is a tuple of three values:

  • a token value that describes the container that the entry exists in, such as a tree

  • a unique, variable length, key value for the entry

  • a token that points to the next node to go to when a lookup matches on the entry’s key value

Each entry in a table or an indexed list is represented by an AftEntry object class. In AFI Release 1.0, there are object classes that refer to entries and classes that delete referenced entries.

Release History Table
Release
Description
In AFI 1.0, not all packet forwarding engine functions are available as AFI APIs. The primary purpose of this release is to familiarize you with the concepts and capabilities of AFI, not necessarily to allow the creation of fully deployable products based on AFI.
Supported sandbox operations include interfaces for accessing and managing sandbox state (AFTSandbox), inserting nodes (AFTInsert), and removing nodes (AFTRemove).
AFI Release 1.0 supports the ability to manage both input and output ports using the classes AftInputPort and AftOutputPort.
The class AftPacket is supplied in AFI Release 1.0 as the way to construct or parse a packet that is sent or received on the hostpath.
In AFI 1.0 Release, the classes AftEncap and AftDecap are provided for encapsulating and de-encapsulating packets that are sent on the data path.
Supported nodes in AFI 1.0 Release include discard, lookup, counter, and list.
In AFI Release 1.0, there is support for the base object class, AftData, as well as object classes for integers, byte-array prefixes, IPv4 addresses, MAC addresses, and MPLS labels.
In AFI Release 1.0, there are object classes that refer to entries and classes that delete referenced entries.