This chapter provides information about pseudowire ports (PW ports), process overview, and implementation notes.
Topics in this chapter include:
A PW port is primarily used to provide PW termination with the following characteristics:
Mapping between PWs and PW-ports is performed on one-to-one basis.
There are two modes in which PW-port can operate:
Once the PW-port is created, the mapping between the PW-port and PW will depend on the mode of operation and application.
PW-port creation:
Similar to any other Ethernet-based port, the PW-port supports two encapsulation types, dot1q and qinq. Ether-type on a PW-port is not configurable and it is set to a fixed value of 0x8100 for dot1q and qinq encapsulation.
In this mode of operation, the PW-port is bound to a specific physical port through an SDP binding context:
In this example, pw-port 1 is bound to a physical port 1/1/1.This PW-port is mapped to the PW with vc-id 11 under the sdp 1 which must be terminated on port 1/1/1.A PW-port is shaped by a virtual port scheduler (Vport) construct named vport-1 configured under port 1/1/1.SAPs created under such PW-port can be terminated in ESM, Layer 3 IES/VPRN interface or in an Epipe.
The FPE based PW-port is primarily used to extract a PW payload onto an access based PW-port SAP, independent of the network I/O ports. FPE uses Port Cross-Connect (PXC) ports and provides an anchoring point for PW-port, independent of I/O ports, the term anchored PW-port can be interchangeably used with the term FPE based PW-port.The following are examples of applications which rely on FPE based PW-port:
Although the primary role of FPE based PW-port is to terminate an external PW, in certain cases PW-port can be used to terminate traffic from regular SAP on I/O ports. This can be used to:
PW payload delivery from the I/O ports to the FPE based PW-port (and SAP) is facilitated via an internal cross-connect which is built on top of PXC sub-ports. Such cross-connect allows for mapping between PWs and PW-ports even in cases where PW payloads have overlapping VLANS. This concept is shown in Figure 190.
Parameters associated with the PXC sub-ports or PXC based LAGs (QoS, lag-profiles, etc.) are accessible/configurable via CLI. For example, the operator may apply an egress port-scheduler on sub-port pxc-1.b in Figure 190 in order to manage the sum of the bandwidth from associated PW-ports (PW-ports 1 and 2). To avoid confusion during configuration of PXC sub-ports /LAGs, a clear definition of reference points on the cross-connect created via FPE is required:
Since the creation of the cross-connect on FPE based PW-ports is highly automated through and FPE configurations, the SR OS system will:
Note that xc-a and xc-b can be associated with any PXC based LAG ID. For example, the following path configuration is allowed: xc-a with lag-id 100 (which includes pxc sub-ports pxc-2.a and pxc-3.b) and xc-b with lag-id 101 (which includes pxc sub-ports pxc-3.a and pxc-2.b). Regardless of the pxc sub-ports that are assigned to respective LAGs, the xc-a side of the path is used as the transit side of the cross-connect, while the xc-b side of the path is used as the termination side of the cross-connect.
From a logical perspective, the internal cross-connect that maps the external PW to a PW-port is implemented as a switched Epipe service (vc-switching). This switched Epipe service switches an external PW to the internal PW that is terminated on a FPE based PW-port. In this fashion, the PW-port becomes independent of the I/O ports. Assuming that PXC and PW-port are already configured in the system, the following are the three main configuration steps required to terminate the payload carried over external PW on the PW-port SAP:
The status of the internally built constructs can be examines via various show commands (for example show service id <epipe-id> 1 sdp). The internal SDP id is allocated from the user space. To avoid conflict between the user provisioned SDP ids and the system provisioned SDP ids, a range of SDP ids that will be used for internal consumption must be reserved in advance. This is accomplished via the sdp-id-range commands under the config>fwd-path-ext hierarchy.
Configuration steps necessary to build PW-port based cross-connect over PXC are shown in the following diagrams (a single PXC is used in this example).
The fpe command instructs the SR OS system to build an LSP tunnel over the PXC. This tunnel is used to multiplex PW traffic to respective PW-ports. Each external PW is switched to an internal PW (on top of this tunnel) and its payload is off-loaded to a respective PW-port.
Once the fpe is configured (refer to Forwarding Path Extensions section in the Interface Configuration Guide), the SR OS system will automatically configure steps 1, 2 and 3 in Figure 193. The objects created in steps 1, 2 and 3 can be seen via show commands. However, they are not visible to the operator in the configure branch of CLI.
The significance of the pw-port command under the fpe is to inform the system about the kind of cross-connect that needs to be built over PXC – in this case this cross-connect is PW-port specific. Applications other than PW-port may require different functionality over PXCs and this will be reflected by a different command under the fpe CLI hierarchy (for example vxlan-termination command instead of pw-port).
Note: the IP addresses setup on internal interfaces on PXC sub-ports are Martian IP addresses and they are shown in CLI as fpe_<id>.a and fpe_<id>.b.
Mapping between the external PW and the FPE based PW-port is performed via an Epipe of type vc-switching. The user configurable Epipe (id 5 in this example) will aid in setting up steps 4, 5 and 6 in Figure 194:
At this stage, the external PW is mapped to the pw-port 1, as shown in Figure 194. The spoke-sdp 17000:1 and the binding under SDP 17001 (spoke-sdp 17001:100001) created in steps 4 and 5 (Figure 194) can be seen via show commands. However, they are not visible to the operator in the configure branch of CLI.
In the final step, PW-port SAP is applied to a service (Figure 195).
Note that the stitching service in this context is an Epipe service in a non-vc-switching mode for EVPN:
QoS fundamentals for the case where multiple PWs are multiplexed over a single cross-connect are shown in Figure 196.
Egress QoS may be applied on both sides of the cross-connect (PXC sub-ports .a and .b) to control congestion on the cross-connect itself. This can be accomplished via an Egress Port Scheduler (EPS) applied to each sub-port.
EPS applied to pxc-1.a (transit side) will manage congestion on the cross-connect for traffic coming from the external PWs. A single set of queues will be shared by all PWs utilizing this cross-connect in this direction.
EPS applied to the pxc-1.b (terminating side) will be used to manage congestion on the cross-connect for traffic going towards the PWs (leaving the SR OS node). A set of queues will be dedicated to each PW-port SAP.
QoS on PXC sub-ports is described in the PXC section of the Interface Configuration Guide.
The internal cross-connect utilized by FPE based PW-port is relying on an MPLS tunnel built over internal network interfaces configured on PXCs. Those internal network interfaces are using a default network policy 1 for egress traffic classification, remarking and marking purposes. Since the PXC cross-connect is MPLS based, the EXP bits in newly added MPLS header will be marked according to the default network policy (for brevity reasons, only the relevant parts of the network policy are shown here).
As seen in this excerpt from the default network egress policy, the forwarding classes AF and L1 marks the EXP bits with the same values. This renders the forwarding classes AF and L1 set on one side of PXC, indistinguishable from each other on the other side of the PXC. This effectively reduces the number of forwarding classes from 8 to 7 in deployment scenarios where the QoS treatment of traffic depends on preservation of forwarding classes across PXC. In other words, in such scenarios, one of the forwarding classes AF or L1 should not be used.
An FPE-based PW-port is associated with an internal spoke SDP as described in PXC-Based PW-Port — Building the Cross-Connect and FPE-Based PW-port Operational Stateh. Statistics for the number of forwarded/dropped packets/octets per direction on a PW-port are therefore maintained per this internal spoke SDP. Octets field counts octets in customer frame (including customer’s Ethernet header with VLAN tags). The following command is used to display PW-port statistics along with the status of the internal spoke SDP associated with the PW-Port:
Intra-chassis redundancy models rely on PXC based LAG. PXC based LAG can contain multiple PXCs on the same line card (port redundancy) or PXCs across different line cards (port and card level redundancy).FPE based PW-ports also provide network level redundancy where MPLS/IP can be rerouted to a different I/O ports (due to network failure) without interruption of service.