6. Pseudowire Ports

6.1. In This Chapter

This chapter provides information about pseudowire ports (PW ports), process overview, and implementation notes.

Topics in this chapter include:

6.2. Overview

A PW port is primarily used to provide PW termination with the following characteristics:

  1. Provide access (SAP) based capabilities to a PW which has traditionally been a network port based concept within SR OS. For example, PW payload can be extracted onto a PW-port-based SAPs with granular queuing capabilities (queuing per SAP). This is in contrast with traditional PW termination on network ports where queuing is instantiated per physical port on egress or per MDA on ingress.
  1. Lookup dot1q and qinq VLAN tags underneath the PW labels and map the traffic to different services.
  1. Terminate subscriber traffic carried within the PW on a BNG. In this case PW-port-based SAPs are instantiated under a group interface with Enhanced Subscriber Management (ESM). In this case, PW-port based SAP is treated as any other regular SAP created directly on a physical port with full ESM capabilities.

Mapping between PWs and PW-ports is performed on one-to-one basis.

There are two modes in which PW-port can operate:

  1. A PW-port bound to a specific physical port (I/O port) — A successful mapping between the PW and PW-port requires that the PW terminates on the same physical port (I/O port) to which the PW-port is bound. In this mode of operation, PW-ports do not support re-routing of PWs between the I/O ports. For example, if a PW is rerouted to an alternate physical port due to a network failure, the PW-port will become non-operational.
  1. A PW-port independent of the physical port (I/O port) on which the PW is terminated. This capability relies on FPE functionality and hence the name FPE based PW-port. The benefit of such PW-port is that it can provide services in cases where traffic within PW is rerouted between I/O ports due to a network failure.

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:

    configure
        pw-port <id>
            encap-type {dot1q|qinq}

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.

6.3. PW-Port Bound to a Physical Port

In this mode of operation, the PW-port is bound to a specific physical port through an SDP binding context:

    configure
        service
             sdp 1 mpls create
                 far-end 10.10.10.10
                 ldp
                binding
                     port 1/1/1
                     pw-port 1 vc-id 11 create
                         egress
                         shaping inter-dest-id vport-1

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.

6.4. FPE-Based PW-Port

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:

  1. ESM over PW where MPLS/GRE based PW can be rerouted between I/O ports on an SR OS node without affecting ESM service
  1. Granular QoS per PW since the PW payload is terminated on an access based PW-port SAP 1679 ® ingress/egress queues are created per SAP (as opposed to per network port on egress and per MDA on network ingress)
  1. PW-SAP with MPLS resiliency, where the LSP used by the PW terminated on a PW Ports is protected using MPLS mechanisms such as FRR and could thus use any port on the system
  1. PW-port using LDP-over-RSVP tunnels
  1. A PW Port using a BGP VPWS

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:

  1. Separate service termination point from the SAPs which are tied to I/O ports.
  1. Distribute load from a single I/O port to multiple line cards based on S-Tag (traffic from each S-tag can be mapped to a separate PW associated with different PXCs residing on different line cards).

6.4.1. Cross-Connect Between the External PW and the FPE-Based PW-Port

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

Figure 182:  Multiplexing PWs over PXC-Based Internal Cross-Connect  

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 182 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:

  1. Terminating side of the cross-connect is closer to PW-ports (.b side)
  1. Transit side of the cross-connect is closer to I/O ports (.a side)

Since the creation of the cross-connect on FPE based PW-ports is highly automated through and FPE configurations, the SR OS system will:

  1. Assign PXC sub-ports .a to the transit side, and PXC sub-ports .b to the terminating side in case that a single PXC is used
Figure 183:  Assign PXC Sub Ports  
  1. Assign the xc-a LAG to the transit side, and the xc-b LAG to the terminating side if that a PXC based LAG is used.
Figure 184:  Assign the LAG  

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.

6.4.2. PXC-Based PW-Port — Building 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:

  1. Auto-setup of the internal transport tunnel over which the cross-connect is built
  2. Auto-setup of the internal PW, switching the external PW to the internal PW and terminating the PW on the FPE based PW-port
  3. Terminating the service on the PW-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 configure>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).

6.4.2.1. Building the Internal Transport Tunnel

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

Figure 185:  Building the Internal LSP over PXCs 

6.4.2.2. Mapping the External PW to the PW-Port

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 186:

  1. An internal PW is automatically added to the user configured Epipe 5
  2. A bind is created between the internal PW and the PW-port attached to PXC.
  3. External PW is switched to the internal PW.

At this stage, the external PW is mapped to the pw-port 1, as shown in Figure 186. The spoke-sdp 17000:1 and the binding under SDP 17001 (spoke-sdp 17001:100001) created in steps 4 and 5 (Figure 186) can be seen via show commands. However, they are not visible to the operator in the configure branch of CLI.

Figure 186:  Mapping Between the External PW and the PXC Based PW-Port 

6.4.2.3. Terminating the Service on PW-SAP

In the final step, PW-port SAP is applied to a service (Figure 187).

Figure 187:  Service Termination on PW-SAP 

6.4.3. Operational State of the PXC Based PW-Port

PW-ports do not have an operational state. However, a PW-port will be bound to an internal spoke SDP that does have an operation state. The following command will create an internal spoke SDP and bind the PW-port:

configure
        service epipe <epipe-id> customer <cust-id> [vc-switching] create
            pw-port <pw-port-id> fpe <fpe-id>

This internal spoke SDP can be administratively shutdown via the following command:

 configure
        service epipe <epipe-id> customer <cust-id> [vc-switching] create
            pw-port <pw-port-id> fpe <fpe-id>
                shutdown

Although the PW-port does not have an operational state, SAPs created on a PW-port will react to the operation states of the underlying spoke SDP. For example, if the internal spoke SDP is administratively shutdown, the PW-SAP will transition into shutdown state as well.

6.4.4. QoS

QoS fundamentals for the case where multiple PWs are multiplexed over a single cross-connect are shown in Figure 188.

Figure 188:  QoS on FPE-Based PW-Port 

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.

6.4.4.1.  Preservation of Forwarding Class Across PXC

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

*A:node-1>config>qos>network# info detail 
----------------------------------------------
            description "Default network QoS policy."
            scope template
            egress
                fc af                    
                    lsp-exp-in-profile 3
                    lsp-exp-out-profile 2                    
                exit
                fc be                    
                    lsp-exp-in-profile 0
                    lsp-exp-out-profile 0 
                exit
                fc ef  
                    lsp-exp-in-profile 5
                    lsp-exp-out-profile 5 
                exit
                fc h1 
                    lsp-exp-in-profile 6
                    lsp-exp-out-profile 6
                exit
                fc h2
                    lsp-exp-in-profile 4
                    lsp-exp-out-profile 4 
                exit
                fc l1
                    lsp-exp-in-profile 3
                    lsp-exp-out-profile 2 
                exit
                fc l2
                    lsp-exp-in-profile 1
                    lsp-exp-out-profile 1
                exit
                fc nc
                    lsp-exp-in-profile 7
                    lsp-exp-out-profile 7
                exit
            exit
----------------------------------------------

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.

6.4.5. Statistics on the FPE based PW-Port

An FPE-based PW-port is associated with an internal spoke SDP as described in PXC-Based PW-Port — Building the Cross-Connect and Operational State of the PXC Based PW-Porth. 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:

*A:Dut-B# show pw-port 3 statistics
===============================================================================
Service Destination Point (Sdp Id 17000 Pw-Port 3)
===============================================================================
SDP Binding port     : pxc-1.b
VC-Id                : 100003                Admin Status       : up
Encap                : dot1q                 Oper Status        : up
VC Type              : ether
Admin Ingress label  : 262135                Admin Egress label : 262136
Oper Flags           : (Not Specified)
Monitor Oper-Group   : (Not Specified)
Statistics            :
I. Fwd. Pkts.        : 12000                 I. Dro. Pkts.      : 0
I. Fwd. Octs.        : 720000                I. Dro. Octs.      : 0
E. Fwd. Pkts.        : 12000                 E. Fwd. Octets     : 720000
===============================================================================

6.4.6. Intra-Chassis Redundancy Models for PXC Based 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.