The SDN Policy Offload reference pipeline includes a robust list of functions and services to jumpstart your development and accelerate your path to production deployments by including ready to deploy libraries. The following is a list of services ready-to-deploy. You can move to production with the included ready to deploy libraries and customize the other stages in the pipeline.
- Routing (LPM and Priority-Based Route Lookup).
-
The current configuration can support up to 4 million routes. There can be different memory pools for different scales. For example:
-
M route table with 1K routes
-
N route table with 4M routes.
-
- Routing using longest prefix matching (LPM) is implemented as a P4 program running on the P4-DMA pipeline of the DPU. Libraries and binaries required for this routing functionality are packaged as part of the SSDK tarball.
- Route lookups in the P4DMA data path.
- APIs are exposed to programmers to use route-table config objects and APIs to initialize, create, delete, and update.
- Multi-tenancy: A Table ID is added to the LPM routing table
implementation allowing the lookup to be achieved by the key:
table-idand DIP prefix/SIP prefix. The Table ID in this case can be interpreted as the VRF. You can define the Table ID. An example is using the VID in the VxLAN header as the Table ID. - Supports both IPv4 and IPv6 based route tables.
-
- SDN/Security Policy
-
There can be different memory pools for different rules or policy scales. The number of policies attached per anchor can be between 1 to 6. The maximum rules per anchor can be up to 24K. For example:
-
M policies with 4K rules and a maximum of 1K src IP prefixes, 1K dst IP prefixes.
-
N policies with 4K rules and maximum of 256K src IP prefixes, 256K dst IP prefixes.
-
- Once the policy is created and programmed, it can be attached or detached to an anchor point, which could be VRF/Network depending on the deployment. Security-policy evaluation is skipped if policy is not attached to any anchor.
- Rule priority is supported.
- Bi-directional policy enforcement (Ingress and Egress). A unique policy can be applied in each direction.
- Incremental rule add/delete.
- Policy lookups in the P4-DMA data path.
- APIs are exposed to programmers to use route-table config objects and APIs to initialize, create, delete, and update.
- Supports both IPv4 and IPv6 based policies.
- Flow logging is not included in the reference pipeline but can be added.
-
- Hardware Assisted Flow Aging
- Performed as a hardware assist for flow aging where the P4 pipeline can notify the dp-app or any control plane application using the well defined APIs of the expired sessions so that the application can take appropriate actions to delete the corresponding flow entries from the P4 flow table.
- Scanners: P4+ programs that scan the entire depth of a session table to detect expired flows.
- Pollers: Pollers are specific threads on the dp-app that poll a dedicated poller queue. A poller queue is a queue that receives expiry map bitmaps from a scanner program.
- Idle Aging: Currently, two types of inactivity timeout configurations are supported: stateless and stateful.
- Connection Track Aging is implemented for TCP connections only. P4
pipeline tracks TCP state and per flow TCP state is maintained in session tracking table
along with last seen sequence and ack numbers. TCP state transitions tracked are: 
- INIT
- SYN_SENT
- ESTABLISHED (post 3 way handshake)
- FIN1_RECEIVED
- FIN2_RECEIVED
- RST
- CLOSED
- Closed Session (A/B copy): Once the connection track program detects that the connection is closed, the closed session bitmaps are managed as A and B copy for synchronizing the update between P4 and P4+ programs.
- Show/Debug commands.
- Testing Tool: Flow Creation: send a packet with a SCAPI script.