3. VLL Services
This chapter provides information about Virtual Leased Line (VLL) services and implementation notes.
3.1. Epipe
This section provides information about the Epipe service and implementation notes.
3.2. Epipe Service Overview
An Epipe service is a Layer 2 point-to-point service where the customer data is encapsulated and transported across a service provider's network. An Epipe service is completely transparent to the subscriber's data and protocols. The 7210 SAS Epipe service does not perform any MAC learning. A local Epipe service consists of two SAPs on the same node, whereas a distributed Epipe service consists of two SAPs on different nodes.
The following support is available on different platforms:
- The 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T support only local Epipe services. The 7210 SAS-D provide null, QinQ SAPs and dot1q SAPs to provide point-point Layer 2 local services.
- The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C support both local and distributed Epipe services. The platforms provide null, QinQ SAPs and dot1q SAPs to provide a point-point Layer 2 local and distributed service. The platforms support the use of MPLS tunnels for distributed services.
Each SAP configuration includes a specific port on which service traffic enters the 7210 SAS router from the customer side (also called the access side). Each port is configured with an encapsulation type. If a port is configured with an IEEE 802.1Q (referred to as dot1q) encapsulation, a unique encapsulation value (ID) must be specified.
Figure 16 shows a local Epipe (VLL) service using access or access-uplink ports on a 7210 SAS. Figure 17 shows a distributed Epipe (VLL) service using network ports on a 7210 SAS-K 2F6C4T or 7210 SAS-K 3SFP+ 8C.
Figure 16: Local Epipe/VLL Service Using Access or Access-uplink Ports on the 7210 SAS
Figure 17: Distributed Epipe/ VLL Service Using Network Ports on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
3.3. Epipe Oper State Decoupling on 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C
An Epipe service transitions to an operational state of down when only a single entity SAP or binding is active and the operational state of the mate is down or displays an equivalent state. The default behavior does not allow operators to validate the connectivity and measure performance metrics. With this feature an option is provided to allow operators to validate the connectivity and measure performance metrics of an Epipe service before the customer hand-off. The operator can also maintain performance and continuity measurement across their network regardless of the connectivity between the terminating node and the customer.
If the SAP between the operator and the customer enters a Oper Down state, the Epipe remains operationally up, so the results can continue to be collected uninterrupted. The operator receives applicable port or SAP alerts/alarms. This option is available only for the customer-facing SAP failures. If a network-facing SAP or spoke-SDP fails, the operational state of the Epipe service is set to down. That is, there is no option to hold the service in an UP state, if a network component fails.
The following functionality is supported:
- Configuration under SAP is required to change the default behavior of the Epipe service in response to the SAP failure.
- The user can create a SAP on a LAG where the LAG has no port members. In this case, the operator configures the “ignore-oper-state” on the SAP and the service remains operational. However, because no ports exist in the LAG member group, there is no extraction function that can be created. This feature protects against an established working configuration with full forwarding capabilities from failing to collect PM data. The user should shutdown their equipment and place the Epipe SAP in an operationally down state.
- The SAP connecting the provider equipment to the customer is configured to hold the Epipe service status UP when the customer-facing SAP enters any failed state. Only one SAP per Epipe is allowed to be configured.
- Any failure of the network entity (network SAP or SDP-binding) still causes the Epipe service to transition to operationally down.
- As the service remains operationally up, all bindings should remain operationally up and should be able to receive and transmit data. The PW status represents the failed SAP in the LDP status message, but this does not prevent the data from using the PW as a transport, in or out. This is the same as LDP status messaging.
- The SAP failure continues to trigger normal reactions, except the operational state of the service.
- ETH-CFM PM measurement tools (DMM/SLM) can be used with the Up MEP on the failed SAP to collect performance metric. Additionally, CFM troubleshooting tools and connectivity (LBM, LTM, AIS, CCM) can be used and will function regularly.
- ETH-CFM CCM processing and fault propagation does not change. Even when a SAP fails with the hold service UP configuration, CCM sets the interface status TLV to down.
- VPLS services remain operationally UP until the final entity in the service enters a failed operational state. There are no changes to VPLS services and the change is specific to Epipe.
3.4. Dynamic Multi-Segment Pseudowire Routing
 | Note: The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C can only be configured as a T-PE node and not as an S-PE node. |
The following sections describe the end-to-end solution with BGP PW-routing, assuming appropriate platforms are used for various functions.
Dynamic Multi-Segment Pseudowire (MS-PW) routing enables a complete MS-PW to be established, while only requiring per-pseudowire configuration on the T-PEs. No per-pseudowire configuration is required on the S-PEs. End-to-end signaling of the MS-PW is achieved using T-LDP, while multi-protocol BGP is used to advertise the T-PEs, allowing dynamic routing of the MS-PW through the intervening network of S-PEs. Dynamic MS-PWs are described in IETF draft-ietf-pwe3-dynamic-ms-pw-13.txt.
Figure 18 shows the operation of dynamic MS-PWs.
Figure 18: Dynamic MS-PW Operation
The FEC 129 AII Type 2 structure depicted in Figure 19 is used to identify each individual pseudowire endpoint.
Figure 19: MS-PW Addressing Using FEC129 AII Type 2
A 4-byte global ID followed by a 4-byte prefix and a 4-byte attachment circuit ID are used to provide for hierarchical, independent allocation of addresses on a per service provider network basis. The first 8 bytes (global ID + prefix) may be used to identify each individual T-PE or S-PE as a loopback Layer 2 address.
This new AII type is mapped into the MS-PW BGP NLRI (a new BGP AFI of Layer 2 VPN, and SAFI for network layer reachability information for dynamic MS-PWs. As soon as a new T- PE is configured with a local prefix address of global id:prefix, pseudowire routing will proceed to advertise this new address to all the other T- PEs and S-PEs in the network, as shown in Figure 20.
Figure 20: Advertisement of PE Addresses by PW Routing
In step 1, a new T-PE (T-PE2) is configured with a local prefix.
Next, in steps 2 to 5, MP-BGP will use the NLRI for the MS-PW routing SAFI to advertise the location of the new T-PE to all the other PEs in the network. Alternatively, static routes may be configured on a per T-PE/S-PE basis to accommodate non-BGP PEs in the solution.
As a result, pseudowire routing tables for all the S-PEs and remote T-PEs are populated with the next hop to be used to reach T-PE2.
VLL services can then be established, as shown in Figure 21.
Figure 21: Signaling of Dynamic MS-PWs Using T-LDP
In step 1 and 1', the T-PEs are configured with the local and remote endpoint information, Source AII (SAII), Target AII (TAII). On the 7210 SAS, the AIIs are locally configured for each spoke-SDP, according to the model shown in Figure 22. Therefore, the 7210 SAS provides for a flexible mapping of AII to SAP. That is, the values used for the AII are through local configuration, and it is the context of the spoke-SDP that binds it to a specific SAP.
Figure 22: Mapping of AII to SAP
Before T-LDP signaling starts, the two T-PEs determine an active and passive relationship using the highest AII (comparing the configured SAII and TAII) or the configured precedence. Next, the active T-PE (in the IETF draft this is referred to as the source T-PE or ST-PE) checks the PW routing table to determine the next signaling hop for the configured TAII, using the longest match between the TAII and the entries in the PW routing table.
This signaling hop is then used to choose the T-LDP session to the chosen next-hop S-PE. Signaling proceeds through each subsequent S-PE using similar matching procedures to determine the next signaling hop. Otherwise, if a subsequent S-PE does not support dynamic MS-PW routing, and therefore uses a statically configured PW segment, the signaling of individual segments follows the procedures already implemented in the PW switching feature.
| Note: BGP can install a PW AII route in the PW routing table with ECMP next hops. However, when LDP needs to signal a PW with matching TAII, it will choose only one next hop from the available ECMP next hops. PW routing supports up to four ECMP paths for each destination. |
The signaling of the forward path ends when the PE matches the TAII in the label mapping message with the SAII of a spoke-SDP bound to a local SAP. The signaling in the reverse direction can now be initiated, which follows the entries installed in the forward path. The PW routing tables are not consulted for the reverse path. This ensures that the reverse direction of the PW follows exactly the same set of S-PEs as the forward direction.
This solution can be used in either a MAN-WAN environment or in an inter-AS/inter-provider environment, as shown in Figure 23.
Figure 23: VLL Using Dynamic MS-PWs, Inter-AS Scenario
| Note: Data plane forwarding at the S-PEs uses pseudowire service label switching, as per the pseudowire switching feature. |
3.4.1. MS-PW Routing — Pseudowire Routing
| Note: The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C can only be configured as a T-PE node and not as an S-PE node. |
The following sections describe the end-to-end solution with BGP PW-routing, assuming appropriate platforms are used for various functions.
Each S-PE and T-PE has a pseudowire routing table that contains a reference to the T-LDP session to use to signal to a set of next-hop S-PEs to reach a specific T-PE (or the T-PE if that is the next hop). For VLLs, this table contains aggregated AII Type 2 FECs and may be populated with routes that are learned through MP-BGP or that are statically configured.
MP-BGP is used to automatically distribute T-PE prefixes using the new MS-PW NLRI, or static routes can be used. The MS-PW NLRI is composed of a length, an 8-byte RD, a 4-byte global ID, a 4-byte local prefix, and (optionally) a 4-byte AC ID. Support for the MS-PW address family is configured in CLI under config>router>bgp>family ms-pw.
MS-PW routing parameters are configured in the config>service>pw-routing context.
To enable support for dynamic MS-PWs on a 7210 SAS node to be used as a T-PE or S-PE, a single, globally unique, S-PE ID, known as the S-PE address, is first configured under config>service>pw-routing on each 7210 SAS to be used as a T-PE or S-PE. The S-PE address has the format global-id:prefix. It is not possible to configure any local prefixes used for pseudowire routing or to configure spoke-SDPs using dynamic MS-PWs at a T-PE unless an S-PE address has already been configured. The S-PE address is used as the address of a node used to populate the switching point TLV in the LDP label mapping message and the pseudowire status notification sent for faults at an S-PE.
Each T-PE is also be configured with the following parameters:
- Global ID — This is a 4-byte identifier that uniquely identifies an operator or the local network.
- Local prefix — One or more local (Layer 2) prefixes (up to a maximum of 16), which are formatted in the style of a 4-octet IPv4 address. A local prefix identifies a T-PE or S-PE in the PW routing domain.
- For each local prefix, at least one 8-byte route distinguisher (RD) can be configured. It is also possible to configure an optional BGP community attribute.
For each local prefix, BGP then advertises each global-id:prefix and unique RD and community pseudowire using the MS-PW NLRI, based on the aggregated FEC129 AII Type 2 and the Layer 2 VPN/PW routing AFI/SAFI 25/6, to each T-PE/S-PE that is a T-LDP neighbor, subject to local BGP policies.
The dynamic advertisement of each of these pseudowire routes is enabled for each prefix and RD, using the advertise-bgp command.
An export policy is also required to export MS-PW routes in MP-BGP. This can be done using a default policy, such as the following:
However, the preceding would export all routes. Nokia recommends enabling filtering per-family, as follows:
The following command is then added in the config>router>bgp context:
The local-preference parameter for iBGP and BGP communities can be configured under such a policy.
3.4.1.1. MS-PW Routing — Static Routing
In addition to support for BGP routing, static MS-PW routes may also be configured using the config>services>pw-routing>static-route command. Each static route comprises the target T-PE global ID and prefix, and the IP address of the T-LDP session to the next-hop S-PE or T-PE that should be used.
If a static route is set to 0, this represents the default route. If a static route exists to a specific T-PE, this is used in preference to any BGP route that may exist.
3.4.1.2. MS-PW Routing — Explicit Paths
A set of default explicit routes to a remote T-PE or S-PE prefix may be configured on a T-PE under config>services>pw-routing using the path name command. Explicit paths are used to populate the explicit route TLV used by MS-PW T-LDP signaling. Only strict (fully qualified) explicit paths are supported.
| Note: It is possible to configure explicit paths independently of the configuration of BGP or static routing. |
3.4.2. MS-PW Routing — Configuring VLLs Using Dynamic MS-PWs
One or more spoke-SDPs may be configured for distributed Epipe VLL services. Dynamic MS-PWs use FEC129 (also known as the Generalized ID FEC) with Attachment Individual Identifier (AII) Type 2 to identify the pseudowire, as opposed to FEC128 (also known as the PW ID FEC) used for traditional single segment pseudowires and for pseudowire switching. FEC129 spoke-SDPs are configured under the spoke-sdp-fec command in the CLI.
FEC129 AII Type 2 uses a Source Attachment Individual Identifier (SAII) and a Target Attachment Individual Identifier (TAII) to identify the end of a pseudowire at the T-PE. The SAII identifies the local end, while the TAII identifies the remote end. The SAII and TAII are each structured as follows:
- Global ID — A 4-byte identifier that uniquely identifies an operator or the local network.
- Prefix — A 4-byte prefix, which should correspond to one of the local prefixes assigned under pw-routing.
- AC ID — A 4-byte identifier for this end of the pseudowire. This should be locally unique within the scope of the global-id:prefix.
3.4.2.1. MS-PW Routing — Active/Passive T-PE Selection
Dynamic MS-PWs use single-sided signaling procedures with double-sided configuration; a fully qualified FEC must be configured at both endpoints. That is, one T-PE (the source T-PE: ST-PE) of the MS-PW initiates signaling for the MS-PW, while the other end (the terminating T-PE: TT-PE) passively waits for the label mapping message from the far-end. The TT-PE only responds with a label mapping message to set up the opposite direction of the MS-PW when it receives the label mapping from the ST-PE. By default, the 7210 SAS will determine which T-PE is the ST-PE (the active T-PE) and which is the TT-PE (the passive T-PE) automatically, based on comparing the SAII with the TAII as unsigned integers. The T-PE with SAII>TAII assumes the active role. However, it is possible to override this behavior using the signaling {master | auto} command under the spoke-sdp-fec. If master is selected at a specific T-PE, it will assume the active role. If a T-PE is at the endpoint of a spoke-SDP that is bound to an VLL SAP, and single-sided autoconfiguration is used, that endpoint is always passive. Therefore, signaling master should only be used when it is known that the far end will assume a passive behavior.
3.4.2.2. MS-PW Routing — Automatic Endpoint Configuration
Automatic endpoint configuration allows the configuration of an endpoint without specifying the TAII associated with that spoke-sdp-fec. It allows a single-sided provisioning model where an incoming label mapping message with a TAII that matches the SAII of that spoke-SDP can be automatically bound to that endpoint. This is useful in scenarios where a service provider needs to separate service configuration from the service activation phase.
Automatic endpoint configuration is supported required for Epipe VLL spoke-sdp-fec endpoints bound to a VLL SAP. It is configured using the spoke-sdp-fec>auto-config command, and excludes the TAII from the configuration. When autoconfiguration is used, the node assumes passive behavior from a point of view of T-LDP signaling. Therefore, the far-end T-PE must be configured for signaling master for that spoke-sdp-fec.
3.4.2.3. MS-PW Routing — Selecting a Path for an MS-PW
Path selection for signaling occurs in the outbound direction (ST-PE to TT-PE) for an MS-PW. In the TT-PE to ST-PE direction, a label mapping message follows the reverse of the path of the outgoing label mapping.
A node can use explicit paths, static routes, or BGP routes to select the next hop S-PE or T-PE. The order of preference used in selecting these routes is:
- explicit path
- static route
- BGP route
To use an explicit path for an MS-PW, an explicit path must have been configured in the config>services>pw-routing>path path-name context. The user must then configure the corresponding path path-name under the spoke-sdp-fec context.
If an explicit path name is not configured, the TT-PE or S-PE will perform a longest match lookup for a route (static if it exists, and BGP if not) to the next-hop S-PE or T-PE to reach the TAII.
Pseudowire routing chooses the MS-PW path in terms of the sequence of S-PEs to use to reach a specific T-PE. It does not select the SDP to use on each hop, which is instead determined at signaling time. When a label mapping is sent for a specific pseudowire segment, an LDP SDP will be used to reach the next-hop S-PE/T-PE if such an SDP exists. If not, and an RFC 3107 labeled BGP SDP is available, then that will be used. Otherwise, the label mapping will fail and a label release will be sent.
3.4.2.4. MS-PW Routing — Pseudowire Templates
Dynamic MS-PWs support the use of the pseudowire template for specifying generic pseudowire parameters at the T-PE. The pseudowire template to use is configured in the spoke-sdp-fec>pw-template-bind policy-id context. Dynamic MS-PWs do not support the provisioned SDPs specified in the pseudowire template.
3.4.3. MS-PW Routing — Pseudowire Redundancy
Pseudowire redundancy is supported on dynamic MS-PWs used for VLLs. It is configured in a similar manner to pseudowire redundancy on VLLs using FEC128, whereby each spoke-sdp FEC within an endpoint is configured with a unique SAII/TAII.
Figure 24 shows the use of pseudowire redundancy.
Figure 24: Pseudowire Redundancy
The following is a summary of the key points to consider in using pseudowire redundancy with dynamic MS-PWs:
- Each MS-PW in the redundant set must have a unique SAII/TAII set and is signaled separately. The primary pseudowire is configured in the spoke-sdp-fec>primary context.
- Each MS-PW in the redundant set should use a diverse path (from the point of view of the S-PEs traversed) from every other MS-PW in that set, if path diversity is possible in a specific network topology. There are a number of possible ways to achieve this:
- Configure an explicit path for each MS-PW.
- Allow BGP routing to automatically determine diverse paths using BGP policies applied to different local prefixes assigned to the primary and standby MS-PWs.
- Provide path diversity for each primary pseudowire through the use of a BGP RD.
If the primary MS-PW fails, fail-over to a standby MS-PW, as per the normal pseudowire redundancy procedures. A configurable retry timer for the failed primary MS-PW is then started. When the timer expires, attempt to reestablish the primary MS-PW using its original path, up to a maximum number of attempts as per the retry count parameter. The T-PE may then optionally revert back to the primary MS-PW on successful reestablishment.
| Note: Since the SDP ID is determined dynamically at signaling time, it cannot be used as a tie breaker to choose the primary MS-PW between multiple MS-PWs of the same precedence. The user should therefore explicitly configure the precedence values to determine which MS-PW is active in the final selection. |
3.4.4. MS-PW Routing — VCCV OAM for Dynamic MS-PWs
The primary difference between dynamic MS-PWs and those using FEC128 is support for FEC129 AII type 2. As in PW switching, VCCV on dynamic MS-PWs requires the use of the VCCV control word on the pseudowire. Both the vccv-ping and vccv-trace commands support dynamic MS-PWs.
3.4.5. MS-PW Routing — VCCV-Ping on Dynamic MS-PWs
VCCV-ping supports the use of FEC129 AII type 2 in the target FEC stack of the ping echo request message. The FEC to use in the echo request message is derived in one of two ways: either the user can explicitly specify the SAII and TAII to use, or the user can specify only the spoke-sdp-fec-id of the MS-PW in the vccv-ping command.
If the SAII:TAII is entered by the user in the vccv-ping command, those values are used for the vccv-ping echo request. However, their order is reversed before being sent, so that they match the order for the downstream FEC element for an S-PE, or the locally configured SAII:TAII for a remote T-PE of that MS-PW.
| Note: If SAII:TAII is entered in addition to the spoke-sdp-fec-id, the system will verify the entered values against the values stored in the context for that spoke-sdp-fec-id. The use of spoke-sdp-fec-id in vccv-ping is only applicable at T-PE nodes, because it is not configured for a specific MS-PW at S-PE nodes. |
If the SAII:TAII is not entered by the user, and if a switching point TLV was received in the initial label mapping message for the reverse direction of the MS-PW (with respect to the sending PE), the SAII:TAII to use in the target FEC stack of the vccv-ping echo request message is derived by parsing that TLV, based on the user-specified TTL (or a TTL of 255 if none is specified). In this case, the order of the SAII:TAII in the switching point TLV is maintained for the vccv-ping echo request message.
If no pseudowire switching point TLV was received, the SAII:TAII values to use for the vccv-ping echo request are derived from the MS-PW context, but their order is reversed before being sent, so that they match the order for the downstream FEC element for an S-PE, or the locally configured SAII:TAII for a remote T-PE of that MS-PW.
3.4.6. MS-PW Routing — VCCV-Trace on Dynamic MS-PWs
The 7210 SAS supports the MS-PW path trace mode of operation for VCCV-trace, as per pseudowire switching, but using FEC129 AII type 2. As in the case of VCCV-ping, the SAII:TAII used in the vccv-trace echo request message sent from the T-PE or S-PE, from which the vccv-trace command is executed, is specified by the user or derived from the context of the MS-PW.
| Note: The use of spoke-sdp-fec-id in vccv-trace is only applicable at T-PE nodes, because it is not configured for a specific MS-PW at S-PE nodes. |
3.4.7. MS-PW Routing — Example Dynamic MS-PW Configuration
This section presents an example of how to configure dynamic MS-PWs for a VLL service between a set of 7210 SAS nodes. The network consists of two 7210 SAS T-PEs and two 7210 playing the role of S-PEs, as shown in Figure 25. Each 7210 peers with its neighbor using LDP and BGP.
Figure 25: Dynamic MS-PW Example
The example uses BGP to route dynamic MS-PWs and T-LDP to signal them. Therefore, each node must be configured to support the MS-PW address family under BGP, and BGP and LDP peerings must be established between the T-PEs. The appropriate BGP export policies must also be configured.
Finally, pseudowire routing must be configured on each node. This includes an S-PE address for every participating node, and one or more local prefixes on the T-PEs. MS-PW paths and static routes may also be configured.
When this routing and signaling infrastructure is established, spoke-sdp-fecs can be configured on each of the T-PEs.
3.5. PW Redundancy — Master-Slave Operation
| Note: 7210 SAS devices support only the standby-signaling-master option. The 7210 SAS does not support the CLI command standby-signaling-slave. In the following description, reference to the standby-signaling-slave command is only used to describe the solution. The 7210 SAS can be used only where standby-signaling-master is used in the following example. |
This section describes master-slave pseudowire redundancy. This redundancy adds the ability for the remote peer to react to the pseudowire standby status notification, even if only one spoke-SDP terminates on the VLL endpoint on the remote peer, by blocking the transmit (Tx) direction of a VLL spoke-SDP when the far-end PE signals standby. This solution enables the blocking of the Tx direction of a VLL spoke-SDP at both master and slave endpoints when standby is signaled by the master endpoint. This satisfies a majority of deployments where bidirectional blocking of the forwarding on a standby spoke-SDP is required.
Figure 26 shows the operation of master-slave pseudowire redundancy. In this scenario, an Epipe service is provided between CE1 and CE2. CE2 is dual-homed to PE2 and PE3, and therefore PE1 is dual-homed to PE2 and PE3 using Epipe spoke-SDPs. The objective of this feature is to ensure that only one pseudowire is used for forwarding in both directions by PE1, PE2, and PE3, in the absence of a native dual homing protocol between CE2 and PE2/PE3, such as MC-LAG. In normal operating conditions (the SAPs on PE2 and PE3 toward CE2 are both up and there are no defects on the ACs to CE2), PE2 and PE3 cannot choose which spoke-SDP to forward on based on the status of the AC redundancy protocol.
Figure 26: Master-Slave Pseudowire Redundancy
Master-slave pseudowire redundancy adds the ability for the remote peer to react to the pseudowire standby status notification, even if only one spoke-SDP terminates on the VLL endpoint on the remote peer. When the CLI command standby-signaling-slave is enabled at the spoke-SDP or explicit endpoint level in PE2 and PE3, any spoke-SDP for which the remote peer signals PW FWD standby will be blocked in the transmit direction.
This is achieved as follows. The standby-signaling-master state is activated on the VLL endpoint in PE1. In this case, a spoke-SDP is blocked in the transmit direction at this master endpoint if it is either in operDown state, or it has lower precedence than the highest precedence spoke-SDP, or the specific peer PE signals one of the following pseudowire status bits:
- Pseudowire not forwarding (0x01)
- SAP (ingress) receive fault (0x02)
- SAP (egress) transmit fault (0x04)
- SDP binding (ingress) receive fault (0x08)
- SDP binding (egress) transmit fault (0x10)
That the specific spoke-SDP has been blocked will be signaled to the LDP peer through the pseudowire status bit (PW FWD standby (0x20)). This will prevent traffic being sent over this spoke-SDP by the remote peer, but only in case that remote peer supports and reacts to pseudowire status notification. Previously, this applied only if the spoke-SDP terminated on an IES, VPRN, or VPLS. However, if standby-signaling-slave is enabled at the remote VLL endpoint then the Tx direction of the spoke-SDP will also be blocked, according to the rules in PW Redundancy — Operation of Master-Slave Pseudowire Redundancy with Existing Scenarios.
| Note: Although master-slave operation provides bidirectional blocking of a standby spoke-SDP during steady-state conditions, it is possible that the Tx directions of more than one slave endpoint can be active for transient periods during a fail-over operation. This is due to slave endpoints transitioning a spoke-SDP from standby to active receiving and/or processing a pseudowire preferential forwarding status message before those transitioning a spoke-SDP to standby. |
This transient condition is most likely when a forced switch-over is performed, or the relative preferences of the spoke-SDPs are changed, or the active spoke-SDP is shutdown at the master endpoint. During this period, loops of unknown traffic may be observed. Fail-overs due to common network faults that can occur during normal operation, a failure of connectivity on the path of the spoke-SDP or the SAP, would not result in such loops in the data path.
3.5.1. PW Redundancy — Operation of Master-Slave Pseudowire Redundancy with Existing Scenarios
This section describes how master-slave pseudowire redundancy could operate.
3.5.1.1. PW Redundancy — VLL Resilience
Figure 27 shows a VLL resilience path example. An sample configuration follows.
Figure 27: VLL Resilience Path
| Note: A revert-time value of zero (default) means that the VLL path will be switched back to the primary immediately after it comes back up. |
PE3
3.5.2. VLL Resilience for a Switched Pseudowire Path
Figure 28 shows the use of both pseudowire redundancy and pseudowire switching to provide a resilient VLL service across multiple IGP areas in a provider network.
Figure 28: VLL Resilience with PW Redundancy and PW Switching
Pseudowire switching is a method for scaling a large network of VLL or VPLS services by removing the need for a full mesh of T-LDP sessions between the PE nodes as the number of these nodes grows over time.
As in the application in VLL Resilience with Two Destination PE Nodes, the T-PE1 node switches the path of a VLL to a secondary standby pseudowire, in the case of a network-side failure causing the VLL binding status to be down or if T-PE2 notified it that the remote SAP went down. This application requires that pseudowire status notification messages generated by either a T-PE node or a S-PE node be processed and relayed by the S-PE nodes.
| Note: It is possible that the secondary pseudowire path terminates on the same target PE as the primary; for example, T-PE2. This provides protection against network-side failures, but not against a remote SAP failure. |
When the target destination PE for the primary and secondary pseudowires is the same, T-PE1 will not switch the VLL path onto the secondary pseudowire upon receipt of a pseudowire status notification indicating that the remote SAP is down. This occurs because the status notification is sent over both the primary and secondary pseudowires. However, the status notification on the primary pseudowire may arrive earlier than the one on the secondary pseudowire due to the differential delay between the paths. This will cause T-PE1 to switch the path of the VLL to the secondary standby pseudowire and remain there until the status notification is cleared. At that time, the VLL path is switched back to the primary pseudowire due to the revertive behavior operation. The path will not switch back to a secondary path when it comes up, even if it has a higher precedence than the currently active secondary path.
3.5.2.1. PW Redundancy — VLL Resilience for a Switched PW Path
| Note: The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C can only be configured as a T-PE node and not as an S-PE node. VC-switching is not supported on the 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C. |
Figure 29 shows a VLL resilience for a switched pseudowire path example. A sample configuration follows.
Figure 29: VLL Resilience with Pseudowire Switching
Configuration
S-PE1
VC switching indicates a VC cross-connect so that the service manager does not signal the VC label mapping immediately, but will put this into passive mode.
3.5.3. Access Node Resilience Using MC-LAG and Pseudowire Redundancy
Figure 30 shows the use of both Multi-Chassis Link Aggregation (MC-LAG) in the access network and pseudowire redundancy in the core network to provide a resilient end-to-end VLL service to the customers.
Figure 30: Access Node Resilience Using MC-LAG and PW Redundancy
In this application, a pseudowire status bit of active or standby indicates the status of the SAP in the MC-LAG instance in the 7210 SAS aggregation node. All spoke-SDPs are of secondary type and there is no use of a primary pseudowire type in this mode of operation.
Node A is in the active state according to its local MC-LAG instance, and therefore advertises active status notification messages to both its peer pseudowire nodes; for example, nodes C and D. Node D performs the same operation. Node B is in the standby state according to the status of the SAP in its local MC-LAG instance, and therefore advertises standby status notification messages to both nodes C and D. Node C performs the same operation.
The 7210 SAS node selects a pseudowire as the active path for forwarding packets when both the local pseudowire status and the received remote pseudowire status indicate active status. However, a 7210 SAS device in standby status according to the SAP in its local MC-LAG instance is capable of processing packets for a VLL service received over any of the pseudowires that are up. This is to avoid black holing of user traffic during transitions.
The 7210 SAS standby node forwards these packets to the active node via the Inter-Chassis Backup (ICB) pseudowire for this VLL service. An ICB is a spoke-SDP used by an MC-LAG node to back up an MC-LAG SAP during transitions. The same ICB can also be used by the peer MC-LAG node to protect against network failures causing the active pseudowire to go down.
| Note: At configuration time, the user specifies a precedence parameter for each of the pseudowires that are part of the redundancy set as described in the application. A 7210 SAS node uses this to select which pseudowire to forward packet to in case both pseudowires show active/active for the local/remote status during transitions. |
Only VLL service of type Epipe is supported in this application. Also, ICB spoke-SDP can only be added to the SAP side of the VLL cross-connect if the SAP is configured on an MC-LAG instance.
3.5.4. VLAN Range for SAPs (or Dot1q Range SAPs) in an Epipe Service
The 7210 SAS VLAN ranges (or dot1q range SAPs) provide a mechanism to group a range of VLAN IDs as a single service entity. This allows the operator to provide the service treatment (forwarding, ACL, QoS, accounting, and others) to the group of VLAN IDs as a whole.
| Note:
|
3.5.4.1. Processing Behavior for Dot1q Range SAPs in Access-uplink Mode on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T
The access SAPs that specify VLAN range values using connection profile (also known as dot1q range SAPs) are allowed in Epipe service and in VPLS service. For more information about functionality supported, see VLAN Range SAPs Feature Support and Restrictions. The system allows only one range SAP in an Epipe service, and it fails any attempt to configure more than one. Range SAPs can only be configured on access ports. The other endpoint in the Epipe service has to be a Q.* SAP in access-uplink mode. The processing and forwarding behavior for packets received on range SAPs are listed as follows:
- No VLAN tags are removed/stripped on ingress of an access dot1q SAP configured to use VLAN ranges. A single tag (Q1) is added to the frame when it is forwarded out of the Q1.* access-uplink SAP.
- When a packet is received on the access-uplink Q1.* SAP, the outermost tag is removed and the packet is forwarded out of the access dot1q range SAP. The system does not check if the inner VLAN tag matches the VLANs IDs (both range and individual values specified in the connection profile) of the dot1q access SAPs configured in the service.
- The dot1q range SAP can be supported in a service with svc-sap-type set to dot1q-range.
3.5.4.2. VLAN Range SAPs Feature Support and Restrictions
The feature support and restrictions of VLAN range SAPs are the following.
- The access SAPs that specify VLAN range values (using the connection profile) are only allowed in an Epipe service. The system allows only one range SAP in an Epipe service, and fails any attempt to configure more than one. Range SAPs can only be configured on access ports.
- On 7210 SAS-D and 7210 SAS-Dxp, the dot1q range SAP can only be configured in a service with svc-sap-type set to dot1q-range.
- On 7210 SAS-K 2F1C2T, the dot1q range SAP can only be configured in a service with svc-sap-type set to dot1q-range.
- The access SAPs using VLAN range values are only allowed for ports or a LAGs configured for dot1q encapsulation.
- A connection profile is used to specify either range of VLAN IDs or individual VLANs to be grouped together in a single SAP.
- On 7210 SAS-D and 7210 SAS-Dxp, dot1q default SAP and dot1q range SAP is not allowed to be configured on the same access port. That is, they are mutually exclusive. This restriction does not apply to 7210 SAS-K 2F1C2T.
- Multiple connection-profiles can be used per port or LAG if the VLAN value specified by each of them does not overlap. The number of VLAN ranges available per port/LAG is limited. The available number must be shared among all the SAPs on the port/LAG.
- The connection profile associated with a SAP cannot be modified. To modify a connection profile, it must be removed from all SAPs using it.
- ACL support – Filter policies are supported on SAP ingress. IP criteria and MAC criteria-based filter policy is available for use with access SAPs. For more information about ACL on range SAPs, refer to the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Router Configuration Guide.
- On 7210 SAS-K 2F1C2T, the outermost VLAN tag and Inner VLAN tag matches are supported for both ingress/egress ACL and ingress QoS classification.
- On 7210 SAS-D and 7210 SAS-Dxp, access SAP egress filters are not supported for SAPs configured in a dot1q-range service.This restriction does not apply to 7210 SAS-K 2F1C2T.
- On 7210 SAS-D and 7210 SAS-Dxp, access-uplink SAP egress filters are not supported for SAPs configured in a dot1q-range service. This restriction does not apply to 7210 SAS-K 2F1C2T.
- QoS on 7210 SAS-D and 7210 SAS-Dxp, Ingress classification, metering with hierarchical metering support for SAP ingress is available.
- SAP ingress classification criteria that is available for use with VLAN range SAPs is similar to that available for other SAPs supported in an Epipe service. Dot1p-based ingress classification uses the dot1p bits in the outermost VLAN tag for matching.
- QoS on 7210 SAS-K 2F1C2T- Ingress classification, queuing with hierarchical shaping support for SAP ingress is available.
- SAP ingress classification criteria that is available for use with VLAN range SAPs is similar to that available for other SAPs supported in an Epipe service. Dot1p-based ingress classification uses the dot1p bits in the outermost VLAN tag for matching.
- The amount of hardware resources (such as CAM entries used for matching in QoS classification and ACL matching, meters used in SAP ingress policy, and others), consumed by a single range SAP, are equivalent to the amount of resources consumed by a single SAP that specifies a single VLAN ID for service identification. That is, the hardware can match a range of VLAN values, and therefore uses X resources for a SAP using a VLAN range, instead of X * n, where n is the number of VLANs specified in the range and X is the amount of QoS or ACL resources needed.
- Ingress accounting support is like the support available for other SAPs in an Epipe service. The count of packets or octets received from individual VLANs configured in the connection profile is not available. No support for Egress SAP statistics and accounting is available.
- Mirroring is supported.
3.5.4.3. Processing Behavior for Dot1q Range SAPs on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
The access SAPs that specify VLAN range values (using the connection profile) are only allowed in an Epipe service. The system allows only one range SAP in an Epipe service, and fails any attempt to configure more than one. Range SAPs can only be configured on access ports. The other endpoint in the Epipe service has to be a Q.* access SAP or a Q.* access-uplink SAP or a spoke-SDP (PW) in network mode.
The spoke-SDP processing and forwarding behavior for packets received on range SAPs are as follows:
- No VLAN tags are removed/stripped on ingress of the access dot1q SAPs using VLAN range connection profile.
- When the other endpoint in the service is configured to be an Q1.* access SAP or a Q1.* access-uplink SAP, the 7210 adds another tag to the packet and forwards it out of that SAP. If the other endpoint in the service is configured to be a spoke-SDP whose VS type is set to vc-ether, the 7210 SAS adds the appropriate MPLS PW and LSP encapsulations and forwards it out of the SDP.
- In the reverse direction, when the other endpoint is a Q1.* access SAP or a Q1.* access-uplink SAP and a packet is received on it, the 7210 SAS removes the outermost VLAN tag and forwards the packet out of the access dot1q SAP using VLAN ranges. When the other endpoint is a spoke-SDP (whose VC type is set to vc-ether), the 7210 SAS removes the MPLS PW and LSP encapsulation and forwards the packet out of the access dot1q SAP using VLAN ranges. The system does not check if the VLAN in the packet matches the VLAN IDs of the dot1q access SAPs configured in the service. That is, when forwarding the traffic out of the range SAPs, the outermost VLAN tag value is not matched against the range configuration.
3.5.4.3.1. VLAN Range SAPs Feature Support and Restrictions on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
- The access SAPs that specifies VLAN range values (using connection profile) is only allowed in Epipe service. The system allows only one range SAP in an Epipe service. It will fail any attempt to configure more than one range SAP in an Epipe service. Range SAP can be configured only on access ports.
- The dot1q range sap can be configured only in a service with svc-sap-type set to dot1q-range.
- The access SAPs using VLAN range values are only allowed for dot1q encapsulation port.
- A connection profile is used to specify either range of VLAN IDs or individual VLANs to be grouped together in a single SAP.
- The dot1q default SAP and dot1q range SAP can co-exist on the same access port.
- Multiple connection profiles can be used per port or LAG as long as the VLAN value specified by each of them does not overlap. The number of VLAN ranges match resources available per port/LAG is limited. The available number must be shared among all the dot1q range SAPs configured on the port/LAG.
- The connection profile associated with a SAP cannot be modified. To modify a connection profile, it must be removed from all SAPs using it.
- ACL support – Filter policies are supported on SAP ingress and SAP egress. Only MAC criteria-based filter policy is available for use with access SAPs. For more information about ACL on range SAPs, refer to the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Router Configuration Guide.
- The outermost VLAN tag and Inner VLAN tag matches are supported for both ingress/egress ACL and ingress QoS classification.
- SDP egress and ingress filter are not supported.
- QoS – Ingress classification, queuing with hierarchical shaping support for SAP ingress.
- SAP ingress classification criteria that is available for use with VLAN range SAPs is like that available for other SAPs supported in an Epipe service. Dot1p-based ingress classification uses the dot1p bits in the outermost VLAN tag for matching. On access egress, dot1p received from the SDP (on a network port) from another access port is preserved.
- The amount of hardware resources (such as CAM entries used for matching in QoS classification and ACL matching, meters used in SAP ingress policy, and others), consumed by a single range SAP, are equivalent to the amount of resources consumed by a single SAP that specifies a single VLAN ID for service identification. That is, the hardware can match a range of VLAN values, and therefore uses X resources for a SAP using a VLAN range, instead of X * n, where n is the number of VLANs specified in the range and X is the amount of QoS or ACL resources needed.
- Ingress accounting support is like the support available for other SAPs in an Epipe service. The count of packets or octets received from individual VLANs configured in the connection profile is not available. No support for Egress SAP statistics and accounting is available.
- Mirroring is supported.
- Service resiliency mechanisms, such as Epipe PW redundancy, are supported.
3.5.5. Epipe Pseudowire Switching on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
| Note: The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C can only be configured as T-PE nodes and not as S-PE nodes. In this section, references to S-PE nodes refer to other products in the Nokia IP product family that support S-PE functionality. |
The pseudowire switching feature provides the user with the ability to create a VLL service by cross-connecting two spoke-SDPs. This feature allows the scaling of VLL and VPLS services in a large network in which the otherwise full mesh of PE devices would require thousands of Targeted LDP (T-LDP) sessions per PE node.
Services with one SAP and one spoke-SDP are created on the PE; however, the target destination of the SDP is the pseudowire switching node instead of the remote PE. In addition, the user configures a VLL service on the pseudowire switching node using the two SDPs.
The pseudowire switching node (that is, S-PE node) acts in a passive role with respect to signaling of the pseudowires. It waits until one or both PEs (that is, T-PEs) sends the label mapping message before relaying it to the other PE. This is because it needs to pass the interface parameters of each PE to the other.
A pseudowire switching point TLV is inserted by the switching pseudowire to record its system address when relaying the label mapping message. This TLV is useful in a few situations:
- It allows for troubleshooting of the path of the pseudowire, especially if multiple pseudowire switching points exist between the two PEs.
- It helps in loop detection of the T-LDP signaling messages where a switching point would receive back a label mapping message it had already relayed.
- It is inserted in pseudowire status notification messages when they are sent end-to-end or from a pseudowire switching node toward a destination PE.
Pseudowire OAM is supported for the manual switching pseudowires and allows the pseudowire switching node to relay end-to-end pseudowire status notification messages between the two PEs. The pseudowire switching node can generate a pseudowire status and send it to one or both PEs by including its system address in the pseudowire switching point TLV. This allows a PE to identify the origin of the pseudowire status notification message.
In the following example, the user configures a regular Epipe VLL service PE1 and PE2 (acting as T-PE nodes). These services each consist of a SAP and a spoke-SDP. However, the target destination of the SDP is not the remote PE but the pseudowire switching node. In addition, the user configures an Epipe VLL service on the pseudowire switching node using the two SDPs.
Configuration examples can be found in “Configuring Two VLL Paths Terminating on T-PE2”.
3.5.5.1. Pseudowire Switching with Protection
Pseudowire switching scales VLL and VPLS services over a multi-area network by removing the need for a full mesh of targeted LDP sessions between PE nodes. This illustrates the use of pseudowire redundancy to provide a scalable and resilient VLL service across multiple IGP areas in a provider network.
In the network in Figure 31, PE nodes act as masters and pseudowire switching nodes act as slaves for the purpose of pseudowire signaling. A switching node will need to pass the SAP interface parameters of each PE to the other. T-PE1 sends a label mapping message for the Layer 2 FEC to the peer pseudowire switching node; for example, S-PE1.
It will include the SAP interface parameters, such as MTU, in the label mapping message. S-PE1 checks the FEC against the local information and if a match exists, it appends the optional pseudowire switching point TLV to the FEC TLV in which it records its system address. T-PE1 then relays the label mapping message to S-PE2. S-PE2 performs similar operations and forwards a label mapping message to T-PE2.
The same procedures are followed for the label mapping message in the reverse direction; for example, from T-PE2 to T-PE1. S-PE1 and SPE2 will affect the spoke-SDP cross-connect only when both directions of the pseudowire have been signaled and matched.
Figure 31: VLL Resilience with Pseudowire Redundancy and Switching
The pseudowire switching TLV is useful in a few situations. First, it allows for troubleshooting of the path of the pseudowire especially if multiple pseudowire switching points exist between the two T-PE nodes. Second, it helps in loop detection of the T-LDP signaling messages where a switching point receives back a label mapping message it already relayed. Finally, it can be inserted in pseudowire status messages when they are sent from a pseudowire switching node toward a destination PE.
Pseudowire status messages can be generated by the T-PE nodes and/or the S-PE nodes. Pseudowire status messages received by a switching node are processed, then passed on to the next-hop. An S-PE node appends the optional pseudowire switching TLV, with its system address added to it, to the FEC in the pseudowire status notification message, only if it originated the message or the message was received with the TLV in it. Otherwise, the message was originated by a TPE node and the S-PE should process and pass the message without changes except for the VCID value in the FEC TLV.
3.5.5.2. Pseudowire Switching Behavior
In the network in Figure 31, PE nodes act as masters and pseudowire switching nodes act as slaves for the purpose of pseudowire signaling. A switching node will need to pass the SAP interface parameters of each PE to the other. T-PE1 sends a label mapping message for the Layer 2 FEC to the peer pseudowire switching node; for example, S-PE1.
It will include the SAP interface parameters, such as MTU, in the label mapping message. S-PE1 checks the FEC against the local information and if a match exists, it appends the optional pseudowire switching point TLV to the FEC TLV in which it records its system address. TPE1 then relays the label mapping message to S-PE2. S-PE2 performs similar operations and forwards a label mapping message to T-PE2.
The same procedures are followed for the label mapping message in the reverse direction; for example, from T-PE2 to T-PE1. S-PE1 and S-PE2 will affect the spoke-SDP cross-connect only when both directions of the pseudowire have been signaled and matched.
Pseudowire status notification messages can be generated by the T-PE nodes and/ or the S-PE nodes. Pseudowire status notification messages received by a switching node are processed, then passed on to the next hop. An S-PE node appends the optional pseudowire switching TLV, with its system address added to it, to the FEC in the pseudowire status notification message only if it originated the message or the message was received with the TLV in it. Otherwise, it means the message was originated by a T-PE node and the S-PE should process and pass the message without changes except for the VC ID value in the FEC TLV.
The merging of the received T-LDP status notification message and the local status for the spoke-SDPs from the service manager at a PE complies with the following rules:
- When the local status for both spoke-SDPs is up, the S-PE passes any received SAP or SDP-binding generated status notification message unchanged; for example, the status notification TLV is unchanged but the VC ID in the FEC TLV is set to the value of the pseudowire segment to the next hop.
- When the local operational status for any of the spoke-SDPs is down, the S-PE always sends SDP-binding down status bits, regardless of whether the received status bits from the remote node indicated SAP up/down or SDP-binding up/down.
3.5.5.2.1. Pseudowire Switching TLV
Figure 32 shows the format of the pseudowire switching TLV.
Figure 32: Pseudowire Switching TLV
PW sw TLV Length - Specifies the total length of all the following pseudowire switching point TLV fields in octets
Type - Encodes how the value field is to be interpreted.
Length - Specifies the length of the value field in octets.
Value - Octet string of length octets that encodes information to be interpreted as specified by the type field.
3.5.5.2.1.1. Pseudowire Switching Point Sub-TLVs
The following are details specific to pseudowire switching point sub-TLVs:
- Pseudowire ID of last pseudowire segment traversed - This sub-TLV type contains a pseudowire ID in the format of the pseudowire ID
- Pseudowire switching point description string - An optional description string of text up to 80 characters.
- IP address of pseudowire switching point.
The IP V4 or V6 address of the pseudowire switching point. This is an optional sub TLV.
- MH VCCV capability indication
3.5.5.3. Pseudowire Redundancy
Pseudowire redundancy provides the ability to protect a pseudowire with a preprovisioned secondary standby pseudowire and to switch traffic over to the secondary standby pseudowire in case of a SAP and/or network failure condition. Pseudowires are redundant due to the SDP redundancy mechanism. For example, if the SDP is an RSVP LSP and is protected by a secondary standby path and/or by Fast Reroute (FRR) paths, the pseudowire is also protected. However, there are a couple of applications in which SDP redundancy does not protect the end-to-end pseudowire path:
- There are two different destination PE nodes for the same VLL service. The main use case is the provision of dual-homing of a CPE or access node to two PE nodes located in different POPs. The other use case is the provision of a pair of active and standby BRAS nodes, or active and standby links to the same BRAS node, to provide service resiliency to broadband service subscribers.
- The pseudowire path is switched in the middle of the network and the pseudowire switching node fails.
Pseudowire and VPLS link redundancy extends link-level resiliency for pseudowires and VPLS to protect critical network paths against physical link or node failures. These innovations enable the virtualization of redundant paths across the metro or core IP network to provide seamless and transparent fail-over for point-to-point and multi-point connections and services. When deployed with multi-chassis LAG, the path for return traffic is maintained through the pseudowire or VPLS switchover, which enables carriers to deliver “always on” services across their IP/MPLS networks.
3.5.6. VLL Service Resilience with Pseudowire on 7210 SAS-K 3SFP+ 8C
The following sections describe VLL resilience.
3.5.6.1. VLL Resilience with Two Destination PE Nodes
Figure 33 shows the application of pseudowire redundancy to provide Ethernet VLL service resilience for broadband service subscribers accessing the broadband service on the service provider BRAS.
Figure 33: VLL Resilience
If the Ethernet SAP on PE2 fails, PE2 notifies PE1 of the failure by either withdrawing the primary pseudowire label it advertised or by sending a pseudowire status notification with the code set to indicate a SAP defect. PE1 will receive it and will immediately switch its local SAP to forward over the secondary standby spoke-SDP. To avoid black holing of in-flight packets during the switching of the path, PE1 will accept packets received from PE2 on the primary pseudowire while transmitting over the backup pseudowire. However, in other applications such as those described in Access Node Resilience Using MC-LAG and Pseudowire Redundancy, it will be important to minimize service outage to end users.
When the SAP on PE2 is restored, PE2 updates the new status of the SAP by sending a new label mapping message for the same pseudowire FEC or by sending a pseudowire status notification message indicating that the SAP is back up. PE1 then starts a timer and reverts back to the primary at the expiry of the timer. By default, the timer is set to 0, which means PE1 reverts immediately. A special value of the timer (infinity) will mean that PE1 should never revert back to the primary pseudowire.
The behavior of the pseudowire redundancy feature is the same if PE1 detects or is notified of a network failure that brought the spoke-SDP operational status to down. The following are the events that will cause PE1 to trigger a switchover to the secondary standby pseudowire:
- LDP peer (remote PE) node withdrew the pseudowire label.
- T-LDP peer signaled a FEC status indicating a pseudowire failure or a remote SAP failure.
- T-LDP session to the peer node times out.
- SDP binding and VLL service went down as a result of a network failure condition, such as the SDP to peer node going operationally down.
The SDP type for the primary and secondary pseudowires need not be the same. That is, the user can protect a RSVP-TE based spoke-SDP with a LDP one. This provides the ability to route the path of the two pseudowires over different areas of the network. All VLL service types, for example, Apipe, Epipe, Fpipe, and Ipipe are supported on the 7750 SR.
The 7210 SAS routers support the ability to configure multiple secondary standby pseudowire paths. For example, PE1 uses the value of the configurable precedence parameter associated with each spoke-SDP to select the next available pseudowire path after the failure of the current active pseudowire (whether it is the primary or one of the secondary pseudowires). However, the revertive operation always switches the path of the VLL back to the primary pseudowire. There is no revertive operation between secondary paths, meaning that the path of the VLL will not be switched back to a secondary pseudowire of higher precedence when the latter comes back up again.
The 7210 SAS routers support the ability for a user-initiated manual switchover of the VLL path to the primary or any of the secondary be supported to divert user traffic in case of a planned outage, such as in node upgrade procedures.
On the 7210 SAS, this application is supported with Epipe Service.
3.5.6.1.1. VLL Resilience — Master-Slave Operation
Master-Slave pseudowire redundancy is described in this section. It adds the ability for the remote peer to react to the pseudowire standby status notification, even if only one spoke-SDP terminates on the VLL endpoint on the remote peer, by blocking the transmit (Tx) direction of a VLL spoke-SDP when the far-end PE signals standby. This solution enables the blocking of the Tx direction of a VLL spoke-SDP at both master and slave endpoints when standby is signaled by the master endpoint. This approach satisfies a majority of deployments where bidirectional blocking of the forwarding on a standby spoke-SDP is required.
Figure 34 shows the operation of master-slave pseudowire redundancy. In this scenario, an Epipe service is provided between CE1 and CE2. CE2 is dual-homed to PE2 and PE3, and therefore PE1 is dual-homed to PE2 and PE3 using Epipe spoke-SDPs. The objectives of this feature is to ensure that only one pseudowire is used for forwarding in both directions by PE1, PE2 and PE3 in the absence of a native dual homing protocol between CE2 and PE2/PE3, such as MC-LAG. In normal operating conditions (the SAPs on PE2 and PE3 toward CE2 are both up and there are no defects on the ACs to CE2), PE2 and PE3 cannot choose which spoke-SDP to forward on based on the status of the AC redundancy protocol.
Figure 34: Master-Slave Pseudowire Redundancy
Master-slave pseudowire redundancy adds the ability for the remote peer to react to the pseudowire standby status notification, even if only one spoke-SDP terminates on the VLL endpoint on the remote peer. When the CLI command standby-signaling-slave is enabled at the spoke-SDP or explicit endpoint level in PE2 and PE3, then any spoke-SDP for which the remote peer signals PW FWD Standby will be blocked in the transmit direction.
This is achieved as follows. The standby-signaling-master state is activated on the VLL endpoint in PE1. In this case, a spoke-SDP is blocked in the transmit direction at this master endpoint if it is either in operDown state, or it has lower precedence than the highest precedence spoke-SDP, or the specific peer PE signals one of the following pseudowire status bits:
- Pseudowire not forwarding (0x01)
- SAP (ingress) receive fault (0x02)
- SAP (egress) transmit fault (0x04)
- SDP binding (ingress) receive fault (0x08)
- SDP binding (egress) transmit fault (0x10)
The fact that the specific spoke-SDP has been blocked will be signaled to LDP peer through the pseudowire status bit (PW FWD Standby (0x20)). This will prevent traffic being sent over this spoke-SDP by the remote peer, but obviously only in case that remote peer supports and reacts to pseudowire status notification. Previously, this applied only if the spoke-SDP terminates on an IES, VPRN or VPLS. However, if standby-signaling-slave is enabled at the remote VLL endpoint then the Tx direction of the spoke-SDP will also be blocked, according to the rules in VLL Resilience — Operation of Master-Slave Pseudowire Redundancy with Existing Scenarios.
| Note: Although master-slave operation provides bidirectional blocking of a standby spoke-SDP during steady-state conditions, it is possible that the Tx directions of more than one slave endpoint can be active for transient periods during a fail-over operation. This is due to slave endpoints transitioning a spoke-SDP from standby to active receiving and/or processing a pseudowire preferential forwarding status message before those transitioning a spoke-SDP to standby. This transient condition is most likely when a forced switch-over is performed, or the relative preferences of the spoke-SDPs is changed, or the active spoke-SDP is shutdown at the master endpoint. During this period, loops of unknown traffic may be observed. Fail-overs due to common network faults that can occur during normal operation, a failure of connectivity on the path of the spoke-SDP or the SAP, would not result in such loops in the data path. |
3.5.6.2. VLL Resilience — Operation of Master-Slave Pseudowire Redundancy with Existing Scenarios
This section describes how master-slave pseudowire redundancy could operate.
Figure 35 shows a VLL resilience path example. An sample configuration follows.
Figure 35: VLL Resilience
| Note: A revert-time value of zero (default) means that the VLL path will be switched back to the primary immediately after it comes back up. |
PE3
3.5.6.3. VLL Resilience for a Switched Pseudowire Path
Figure 36 displays VLL resilience for a switched pseudowire path example. A sample configuration follows.
Figure 36: VLL Resilience with Pseudowire Switching
VC switching indicates a VC cross-connect so that the service manager does not signal the VC label mapping immediately but will put S-PE-1 into passive mode, as follows:
3.5.6.4. VLL Resilience — Pseudowire Redundancy Service Models
This section describes the various pseudowire redundancy scenarios as well as the algorithm used to select the active transmit object in a VLL endpoint.
The redundant VLL service model is described in the following section, Pseudowire Redundancy — Redundant VLL Service Model.
3.5.6.4.1. Pseudowire Redundancy — Redundant VLL Service Model
To implement pseudowire redundancy, a VLL service accommodates more than a single object on the SAP side and on the spoke-SDP side. Figure 37 shows the model for a redundant VLL service based on the concept of endpoints.
Figure 37: Redundant VLL Endpoint Objects
A VLL service supports, by default, two implicit endpoints managed internally by the system. Each endpoint can only have one object: a SAP or a spoke-SDP.
To add more objects, up to two explicitly named endpoints may be created per VLL service. The endpoint name is locally significant to the VLL service. They are referred to as endpoint X and endpoint Y shown in Figure 37.
Figure 37 is just an example and the Y endpoint can also have a SAP and/or an ICB spoke-SDP. The following describes the four types of endpoint objects supported and the rules used when associating them with an endpoint of a VLL service:
- SAP — There can only be a maximum of one SAP per VLL endpoint.
- Primary spoke-SDP — The VLL service always uses this pseudowire and only switches to a secondary pseudowire when it is down. The VLL service switches the path to the primary pseudowire when it is back up. The user can configure a timer to delay reverting back to primary or to never revert. There can only be a maximum of one primary spoke-SDP per VLL endpoint.
- Secondary spoke-SDP — There can be a maximum of four secondary spoke-SDPs per endpoint. The user can configure the precedence of a secondary pseudowire to indicate the order in which a secondary pseudowire is activated.
- Inter-Chassis Backup (ICB) spoke-SDP — This is a special pseudowire used for MC-LAG and pseudowire redundancy application. Forwarding between ICBs is blocked on the same node. The user has to explicitly indicate that the spoke-SDP is an ICB at creation time. There are a few scenarios, as follows, where the user can configure the spoke-SDP as an ICB or as a regular spoke-SDP on a specific node. The CLI for those cases will indicate both options.
A VLL service endpoint can only use one active object to transmit at any specific time, but can receive from all endpoint objects.
An explicitly named endpoint can have a maximum of one SAP and one ICB. When a SAP is added to the endpoint, only one more object of type ICB spoke-SDP is allowed. The ICB spoke-SDP cannot be added to the endpoint if the SAP is not part of an MC-LAG instance. A SAP that is not part of an MC-LAG instance cannot be added to an endpoint that already has an ICB spoke-SDP.
An explicitly named endpoint, which does not have a SAP object, can have a maximum of four spoke-SDPs and can include any of the following:
- a single primary spoke-SDP
- one or many secondary spoke-SDPs with precedence
- a single ICB spoke-SDP
3.5.6.4.2. Pseudowire Redundancy — T-LDP Status Notification Handling Rules
Using Figure 37 as a reference, the following are the rules for generating, processing, and merging T-LDP status notifications in VLL service with endpoints.
| Note: Any allowed combination of objects as specified in Pseudowire Redundancy — Redundant VLL Service Model can be used on endpoints X and Y. |
The following sections refer to the specific combination objects in Figure 37 as an example to describe the more general rules.
3.5.6.5. Processing Endpoint SAP Active/Standby Status Bits
The advertised admin forwarding status of active/standby reflects the status of the local LAG SAP in the MC-LAG application. If the SAP is not part of an MC-LAG instance, the forwarding status of active is always advertised.
When the SAP in endpoint X is part of an MC-LAG instance, a node must send the T-LDP forwarding status bit of “SAP active/standby” over all Y endpoint spoke-SDPs, except the ICB spoke-SDP, whenever this status changes. The status bit sent over the ICB is always zero (active by default).
When the SAP in endpoint X is not part of an MC-LAG instance, the forwarding status sent over all Y endpoint spoke-SDPs should always be set to zero (active by default).
3.5.6.6. Processing and Merging
Endpoint X is operationally up if at least one of its objects is operationally up. It is down if all its objects are operationally down.
If the SAP in endpoint X transitions locally to the down state, or receives a SAP down notification by SAP-specific OAM signal, the node must send T-LDP SAP down status bits on the Y endpoint ICB spoke-SDP only.
| Note: Ethernet SAP does not support SAP OAM protocol. All other SAP types cannot exist on the same endpoint as an ICB spoke-SDP since a non-Ethernet SAP cannot be part of an MC-LAG instance. |
If the ICB spoke-SDP in endpoint X transitions locally to the down state, the node must send T-LDP SDP-binding down status bits on this spoke-SDP.
If the ICB spoke-SDP in endpoint X receives T-LDP SDP-binding down status bits or pseudowire not forwarding status bits, the node saves this status and takes no further action. The saved status is used for selecting the active transmit endpoint object.
If all objects in endpoint X have any of the following happen, the node must send status bits of SAP down over all Y endpoint spoke-SDPs, including the ICB:
- transition locally to down state
- receive a SAP down notification by remote T-LDP status bits
- receive a SAP down notification by SAP-specific OAM signal
- receive status bits of SDP-binding down
- receive status bits of pseudowire not forwarding
Endpoint Y is operationally up if at least one of its objects is operationally up. It is down if all its objects are operationally down.
If a spoke-SDP in endpoint Y, including the ICB spoke-SDP, transitions locally to down state, the node must send T-LDP SDP-binding down status bits on this spoke-SDP.
If a spoke-SDP in endpoint Y, including the ICB spoke-SDP, receive any of the following, the node saves this status and takes no further action:
- T-LDP SAP down status bits
- T-LDP SDP-binding down status bits
- status bits of pseudowire not forwarding
The saved status is used for selecting the active transmit endpoint object.
If all objects in endpoint Y, except the ICB spoke-SDP, have any of the following happen, the node must send status bits of SDP-binding down over the X endpoint ICB spoke-SDP only:
- transition locally to down state
- receive T-LDP SAP down status bits
- receive T-LDP SDP-binding down status bits
- receive status bits of pseudowire not forwarding
If all objects in endpoint Y have any of the following happen, the node must send status bits of SDP-binding down over the X endpoint ICB spoke-SDP, and must send a SAP down notification on the X endpoint SAP by the SAP-specific OAM signal, if applicable:
- transition locally to down state
- receive T-LDP SAP down status bits
- receive T-LDP SDP-binding down status bits
- receive status bits of pseudowire not forwarding
An Ethernet SAP does not support signaling status notifications.
3.5.7. MPLS Entropy Label and Hash Label
MPLS entropy label (RFC 6790) and the Flow Aware Transport label (known as the hash label) (RFC 6391) allow LSR nodes in a network to load-balance labeled packets in a much more granular fashion than allowed by hashing on the standard label stack. For more information, refer to the 7210 SAS-K 2F6C4T, K 3SFP+ 8C MPLS Guide.
The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C do not support MPLS entropy label or hash label.
3.6. VLL Service Considerations
This section describes various general service features and any special capabilities or considerations as they relate to VLL services.
3.6.1. SDPs
The most basic SDPs must have the following:
- locally unique SDP identification (ID) number
- system IP address of the originating and far-end routers
- SDP encapsulation type, MPLS
3.6.2. SAP Encapsulations
The Epipe service is designed to carry Ethernet frame payloads, so it can provide connectivity between any two SAPs that pass Ethernet frames. The following SAP encapsulations are supported on the Epipe service:
- Ethernet null
- Ethernet dot1q
- QinQ
| Note: While different encapsulation types can be used, encapsulation mismatch can occur if the encapsulation behavior is not understood by connecting devices and they are unable to send and receive the expected traffic. For example, if the encapsulation type on one side of the Epipe is dot1q and the other is null, tagged traffic received on the null SAP will potentially be double tagged when it is transmitted out of the dot1q SAP. |
3.6.3. QoS Policies
On the 7210 SAS-D and 7210 SAS-Dxp, when applied to 7210 SAS device Epipe services, service ingress QoS policies only create the unicast meters defined in the policy. The multi-point meters are not created on the service. Egress QoS policies function as with other services where the class-based queues per port are available.
On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, when applied to 7210 SAS device Epipe services, service ingress QoS policies only create the unicast queues defined in the policy. The multi-point queues are not created on the service. Service egress QoS policies function as with other services where the class-based queues are created as defined in the policy.
| Note:
|
3.6.4. Filter Policies
The 7210 SAS Epipe services can have a single filter policy associated on both ingress and egress. Both MAC and IP filter policies can be used on Epipe services.
3.6.5. MAC Resources
Epipe services are point-to-point Layer 2 VPNs capable of carrying any Ethernet payloads. Although an Epipe is a Layer 2 service, the Epipe implementation does not perform any MAC learning on the service, so Epipe services do not consume any MAC hardware resources.