Certain applications in the SR OS require extra traffic processing in the forwarding plane. Such additional traffic processing is facilitated by an internal cross-connect that uses PXC ports (described in the Port Cross-Connect). Application-specific use of the cross-connect is built on the common premise that the traffic must be steered from the input ports to the PXC ports where the traffic can be looped for additional processing in the forwarding plane. To shield the user from the intricacies involved when configuring application-specific cross-connect attributes, a CLI construct referred to as Forwarding Path Extensions (FPE) simplifies provisioning of various applications which rely on PXC functionality. The following are examples of applications that rely on PXC and FPE:
-
anchored PW-ports where PW payload termination in Layer 3 services is disjointed from I/O ports in the system
-
VXLAN termination on non-system IPv4 addresses and VXLAN IPv6 underlay
-
origination or termination of a service with an SRv6 tunnel
-
GTP-U tunnel termination for Fixed Wireless Access (FWA)
Application-specific uses of PXC ports and FPEs are described in the respective service guides which may include, but are not limited to the 7450 ESS, 7750 SR, and VSR Triple Play Service Delivery Architecture Guide and 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide.
The FPE configuration provides information to the SR OS node necessary to associate the application with the PXC (paired PXC sub-ports, multipath PXC sub-ports, or PXC based LAG IDs). Consequently, the SR OS node sets up the internal logic using PXC as required by the application.
An example of FPE provisioning in classic and MD-CLI are provided in Figure: FPE – classic CLI provisioning steps and Figure: FPE – MD-CLI provisioning steps.
-
The first three steps in the classic CLI example are applicable to PXC port provisioning. In MD-CLI, the user must explicitly create sub-ports as described in Port Cross-Connect.
-
Association between the application and the PXC is performed in steps 4 and 5. These applications require internal configuration of SDPs and their IDs are allocated from the user configurable range. To prevent conflict between the user-provisioned SDP IDs and internally configured SDP IDs in FPE case, a range of SDP IDs that are used by FPE is reserved by the sdp-id-range commands under config>fwd-path-ext.
-
Application-specific configuration is performed in step 6, partially by the user and partially by the system. This is described in the application-specific user guides.
After the PXC sub-port or LAG is associated with an FPE object, the user cannot use CLI to create IP interfaces manually and SAPs under these PXC sub-ports or LAGs. Only the SR OS system is allowed to reference these PXC sub-ports or LAGs in internal IP interfaces and SAPs, as required by each application.
The user can modify PXC sub-port and LAG parameters (QoS, LAG profiles, and so on). To remove PXC sub-ports or LAGs from the FPE object, they must not be associated with an application.
Multipath FPE
Some applications require load balancing over multiple PXC ports or LAGs of PXC ports; for example, the subscriber management application has limited forwarding and QoS resources per line card. To optimize resource usage, Nokia recommends load-balance sessions over multiple line cards. However, the subscriber-management application cannot use a LAG of PXCs for load balancing because a LAG reserves subscriber-management resources on each line card that has LAG members. To solve this issue, use the configure fwd-path-ext fpe multi-path command to configure an FPE with multiple paths, each of which can be a PXC port or a LAG of PXC ports.
Support for multipath FPEs is application specific.