3.1.1. Epipe services overview

An Epipe service is a Layer 2 point-to-point service where the customer data is encapsulated and transported across a service provider network. An Epipe service is completely transparent to the subscriber data and protocols. The 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.

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.

The following figure shows Epipe/VLL customer service.

Figure 15:  Epipe/VLL service 

3.1.2. Epipe with PBB

Note: Epipes with PBB are supported only on 7210 SAS-T operating in the network mode.

A PBB tunnel may be linked to an Epipe to a B-VPLS. MAC switching and learning is not required for the point-to-point service (all packets ingressing the SAP are PBB encapsulated and forwarded to the PBB tunnel to the backbone destination MAC address, and all the packets ingressing the B-VPLS destined for the ISID are PBB de-encapsulated and forwarded to the Epipe SAP).

A fully specified backbone destination address must be provisioned for each PBB Epipe instance to be used for each incoming frame on the related I-SAP. If the backbone destination address is not found in the B-VPLS FDB, packets may be flooded through the B-VPLSs

All B-VPLS constructs may be used, including B-VPLS resiliency and OAM. Not all generic Epipe commands are applicable when using a PBB tunnel.

3.1.3. Processing packets received with more than two tags on a QinQ SAP in Epipe service

Note: This section applies to all 7210 SAS platforms as described in this document, except those operating in access-uplink mode. The 7210 SAS platforms operating in access-uplink mode can process and forward packets with more than two tags. See Configuration notes for restrictions on the use of SAPs by platforms operating in access-uplink mode.

To forward packets with two or more tags using a QinQ SAP, an Epipe service type is available for use when 7210 SAS devices are operating in network mode. This service allows for configuration of a QinQ SAP as one endpoint and the following service entities as the other endpoint:

In the forward direction, the device will process the packet as follows:

In the reverse direction, the device will process the packet as follows:

Therefore, the device processes packets received with two or more tags using the MPLS SDP or a dot1q SAP while classifying on the QinQ SAP ingress using two tags.

3.1.4. Epipe operational state decoupling

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 handoff. 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 and 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:

3.2.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. The following figure shows the use of pseudowire redundancy to provide a scalable and resilient VLL service across multiple IGP areas in a provider network.

Figure 16:  VLL Resilience with pseudowire redundancy and switching 

In the network in the preceding figure, PE nodes act as leading nodes and pseudowire switching nodes act as followers 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 S-PE2 will affect the spoke-SDP cross-connect only when both directions of the pseudowire have been signaled and matched.

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. Pseudowire status messages received by a switching node are processed and 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 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.

3.2.2. Pseudowire switching behavior

In the network in Figure 16, PE nodes act as leading nodes and pseudowire switching nodes act as followers for the purpose of pseudowire signaling. A switching node must 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 includes 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 S-PE2 will affect the spoke-SDP cross-connect only when both directions of the pseudowire have been signaled and matched.

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:

3.2.2.1. Pseudowire switching TLV

The following figure shows the format of the pseudowire switching TLV.

Figure 17:  Pseudowire switching TLV format 

1. PW sw TLV Length
   This field specifies the total length of all the following pseudowire switching point TLV fields in octets.
2. Type
   This field encodes how the Value field is interpreted.
3. Length
   This field specifies the length of the Value field in octets.
4. Value
   The octet string of Length octets encodes information to be interpreted as specified by the Type field.

The format of the pseudowire switching point sub-TLVs is as follows:

1. pseudowire ID of last pseudowire segment traversed
   This sub-TLV type contains a pseudowire ID in the format of the pseudowire ID.
2. pseudowire switching point description string
   This is an optional description text string up to 80 characters.
3. IP address of pseudowire switching point
4. IPv4 or IPv6 address of pseudowire switching point
   This is an optional sub-TLV.
5. MH VCCV capability indication

3.2.3. Pseudowire redundancy

Pseudowire redundancy provides the ability to protect a pseudowire with a preprovisioned pseudowire and to switch traffic over to the secondary standby pseudowire in case of a SAP and/or network failure condition. Usually, 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 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:

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.2.3.1. VLL resilience with two destination PE nodes

The following figure 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 18:  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.

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:

1. T-LDP peer (remote PE) node withdrew the pseudowire label.
2. T-LDP peer signaled a FEC status indicating a pseudowire failure or a remote SAP failure.
3. T-LDP session to the peer node times out.
4. 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 7210 SAS routers support the ability to configure multiple secondary standby pseudowire paths. For example, PE1 uses the value of the user-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.

3.2.4. Dynamic multi-segment pseudowire routing

Note: T-PE functionality is supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode. S-PE functionality is only supported on 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE. 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.

The following figure shows the operation of dynamic MS-PWs.

Figure 19:  Dynamic MS-PW operation 

The FEC 129 Attachment Individual Identifier (AII) type 2 structure shown in the following figure is used to identify each individual pseudowire endpoint.

Figure 20:  MS-PW addressing using FEC 129 aII Type 2 

A four-byte global ID followed by a four-byte prefix and a four-byte attachment circuit ID are used to provide for hierarchical, independent allocation of addresses on a per service provider network basis. The first eight 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 L2VPN, 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 the following figure.

Figure 21:  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 the following figure.

Figure 22:  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 the following figure. 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 23:  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 the following figure.

Figure 24:  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.2.4.3. 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.

The following figure shows the use of pseudowire redundancy.

Figure 25:  Pseudowire redundancy 

The following is a summary of the key points to consider in using pseudowire redundancy with dynamic MS-PWs:

1. 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.
2. 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:
   1. Configure an explicit path for each MS-PW.
   2. Allow BGP routing to automatically determine diverse paths using BGP policies applied to different local prefixes assigned to the primary and standby MS-PWs.
   3. Provide path diversity for each primary pseudowire through the use of a BGP route distinguisher.

If the primary MS-PW fails, it fails-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, it attempts 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 that 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.2.4.5. 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.

If the SAII:TAII to use in the target FEC stack of the VCCV-ping message 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.

Note that the use of spoke-sdp-fec-id in vccv-ping is only applicable at T-PE nodes, since it is not configured for a specific MS-PW at S-PE nodes.

3.2.4.6. 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, since it is not configured for a specific MS-PW at S-PE nodes

3.2.5. Example dynamic MS-PW configuration

The following figure shows how to configure dynamic MS-PWs for a VLL service between a set of 7210 SAS nodes. The network consists of two 7210 T-PEs and two 7210 SAS nodes in the role of S-PEs. Each 7210 SAS peers with its neighbor using LDP and BGP.

Figure 26:  Dynamic MS-PW example 

This 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/S-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.

The following is a sample configuration for T-PE1.

The following is a sample configuration for T-PE2.

The following is a sample configuration for S-PE1.

The following is a sample configuration for S-PE2.

3.3.1. Operation of master-slave pseudowire redundancy with existing scenarios

This section describes how master-slave pseudowire redundancy could operate.

3.3.1.1. VLL resilience path

The following figure shows a VLL resilience path example. An sample configuration follows.

Figure 28:  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.

The following is a sample configuration for PE1.

configure service epipe 1

     endpoint X

     exit

     endpoint Y

     revert-time 0

     standby-signaling-master

     exit

     sap 1/1/1:100 endpoint X

     spoke-sdp 1:100 endpoint Y 

precedence primary

     spoke-sdp 2:200 endpoint Y 

precedence 1

The following is a sample configuration for PE2.

configure service epipe 1

     endpoint X

     exit

     sap 2/2/2:200 endpoint X

     spoke-sdp 1:100 

          standby-signaling-slave

 

The following is a sample configuration for PE3.

configure service epipe 1

     endpoint X

     exit

     sap 3/3/3:300 endpoint X

     spoke-sdp 2:200 

          standby-signaling-slave

3.3.2. VLL resilience for a switched PW path

Note: T-PE functionality is supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode. S-PE functionality is only supported on 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE.

The following figure shows VLL resilience for a switched pseudowire path example. A sample configuration follows.

Figure 29:  VLL resilience with pseudowire switching 

The following is a sample configuration of T-PE1.

The following is a sample configuration of T-PE2.

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. The following is a sample configuration of S-PE1.

3.3.3. Access mode resilience Using MC-LAG and pseudowire redundancy

The following figure 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 that 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 a MC-LAG instance.

3.3.4. VLL resilience for a switched pseudowire path

The following figure 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 31:  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 for a switched pseudowire path, 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 usually 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.4.1. 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. The following figure shows the model for a redundant VLL service based on the concept of endpoints.

Figure 32:  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 as shown in the preceding figure.

The preceding figure is only 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:

A VLL service endpoint can only use one active object to transmit at a 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 a MC-LAG instance. A SAP that is not part of a 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:

3.4.2. T-LDP status notification handling rules

Using Figure 32 as a reference, the following are the rules for generating, processing, and merging T-LDP status notifications in VLL service with endpoints. Note that any allowed combination of objects as specified in Redundant VLL service model can be used on endpoints “X” and “Y”. The following sections refer to the specific combination objects in Figure 32 as an example to describe the more general rules.

3.4.2.2. 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: The Ethernet SAP does not support the SAP OAM protocol. All other SAP types cannot exist on the same endpoint as an ICB spoke-SDP because 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:

1. transition locally to down state
2. receive a SAP down notification by remote T-LDP status bits or by SAP-specific OAM signal
3. receive status bits of SDP-binding down
4. 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:

1. T-LDP SAP down status bits
2. T-LDP SDP-binding down status bits
3. 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:

1. transition locally to down state
2. receive T-LDP SAP down status bits
3. receive T-LDP SDP-binding down status bits
4. 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 the 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:

1. transition locally to down state
2. receive T-LDP SAP down status bits
3. receive T-LDP SDP-binding down status bits
4. receive status bits of pseudowire not forwarding

An Ethernet SAP does not support signaling status notifications.

3.5.1. SDPs

An SDP used for MPLS-TP supports the configuration of an MPLS-TP identifier as the far-end address, as an alternative to an IP address. MPLS-TP node identifiers are used if MPLS-TP tunnels are used. IP addresses are used if IP/MPLS LSPs are used by the SDP, or MPLS-TP tunnels identified by IPv4 source or destination addresses.

The following syntax shows the MPLS-TP options:

The far-end node-id <ip-address> global-id <global-id> command is used to associate an SDP far end with an MPLS-TP tunnel whose far-end address is an MPLS-TP node ID. If the SDP is associated with an RSVP-TE LSP, the far end must be a routable IPv4 address.

The system accepts the node-id being entered in either 4-octet IP address format <a.b.c.d> or unsigned integer format.

The SDP far end refers to an MPLS-TP node-id or global-id only if:

An LSP will only be allowed to be configured if the far-end info matches the LSP far-end info (whether MPLS-TP or RSVP):

Signaling TLDP or BGP is blocked if:

The following commands are blocked if a far-end node-id or global-id is configured:

3.5.2. VLL spoke-SDP configuration

The 7210 SAS-T can only be a T-PE. MPLS-TP OAM related commands are applicable to spoke-SDPs configured under all services supported by MPLS-TP pseudowires. All commands and functions that are applicable to spoke-SDPs in the current implementation are supported, except for those that explicitly depend on an LDP session on the SDP or as described in this section. Likewise, all existing functions on a specific service SAP are supported if the spoke-SDPs that it are matched to is MPLS-TP.

The following describes how to configure MPLS-TP on an Epipe VLL. However, similar configuration applies to other VLL types.

A spoke-SDP bound to an SDP with the mpls-tp keyword cannot be no shutdown unless the ingress label, the egress label, the control word, and the PW path ID are configured, as follows:

The pw-path-id context is used to configure the end-to-end identifiers for a MS-PW. These may not coincide with those for the local node if the configuration is at an S-PE. The SAII and TAII are consistent with the source and destination of a label mapping message for a signaled PW.

The control-channel-status command enables static PW status signaling. This is valid for any spoke-SDP where signaling none is configured on the SDP (for example, where T-LDP signaling is not in use). The refresh timer is specified in seconds, from 10 to 65535, with a default of 0 (off). This value can only be changed if control-channel-status is shutdown.

Commands that rely on PW status signaling are allowed if control-channel-status is configured for a spoke-SDP bound to an SDP with signaling off, but the system will use control channel status signaling rather than T-LDP status signaling. The ability to configure control channel status signaling on a specific spoke-SDP is determined by the credit-based algorithm described in Credit-based algorithm. The control-channel-status configuration for a particular PW only counts against the credit-based algorithm if it is in a no shutdown state and has a non-zero refresh timer.

Note: Shutdown of a service will cause the static PW status bits for the corresponding PW to be set.

The spoke-SDP is held down unless the pw-path-id is complete.

The system accepts the node-id of the pw-path-id SAII or TAII being entered in either 4-octet IP address format <a.b.c.d> or unsigned integer format.

The control-word must be enabled to use MPLS-TP on a spoke-SDP.

The pw-path-id is only configurable if all of the following is true:

In the vc-switching case, if configured on a mate spoke-SDP, the TAII of the spoke-SDP must match the SAII of its mate, and SAII of spoke-SDP has to match the TAII of its mate.

A control-channel-status no shutdown is only allowed if all of the following is true:

The hash-label option is only configurable if SDP far-end is not the node-id or global-id.

The control channel status request mechanism is enabled when the request-timer timer parameter is non-zero. When enabled, this overrides the normal RFC-compliant refresh timer behavior. The refresh timer value in the status packet defined in RFC 6478 is always set to zero.

The refresh timer in the sending node is taken from the request timer. The two mechanisms are not compatible with each other. One node sends a request timer while the other is configured for a refresh timer. In a specific node, the request timer can only be configured with both acknowledgment and refresh timers disabled.

When configured, the following procedures are used instead of the RFC 6478 procedures when a PW status changes.

Use the following syntax to configure control channel status requests:

3.5.3. Credit-based algorithm

To constrain the CPU resources consumed processing control channel status messages, the system should implement a credit-based mechanism. If a user enables control channel status on a PW[n], a certain number of credits (c_n) are consumed from a CPM-wide pool of max_credit credits. The number of credits consumed is inversely proportional to the configured refresh timer (the first three messages at 1 s intervals do not count against the credit). If the current_credit <= 0, the control channel status signaling cannot be configured on a PW (but the PW can still be configured, and no shutdown).

The following is an example algorithm:

If refresh timer > 0, c_n = 65535 / refresh_timer

Else c_n = 0.

For n=1, current_credit[n] = max_credits – c_n

Else current_credit [n] = current_credit [n-1] – c_n

By default, if a PE with a non-zero refresh timer configured does not receive control channel status refresh messages for 3.5 times the specified timer value, the PE will time out and assume a PW status of zero. A proprietary optional extension to the [RFC6478] protocol should be implemented to enable a node to resolve such a stale PW status condition by requesting the status from the far-end node in certain cases.

3.6.1. Processing behavior for SAPs using VLAN ranges in access-uplink mode

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 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.* SAP in access-uplink mode. The processing and forwarding behavior for packets received on range SAPs are listed as follows:

3.6.2. VLAN range SAPs feature support and restrictions

The following restrictions apply to VLAN range SAPs:

3.6.3. Processing behavior for SAPs using VLAN ranges in network operating mode

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 spoke-SDP (PW) in network mode.

The spoke-SDP processing and forwarding behavior for packets received on range SAPs are as follows:

ACLs, QoS, hardware, accounting, and mirroring are supported as follows:

3.7.1. SDPs

The most basic SDPs must have the following:

3.7.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:

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.7.3. QoS policies

The following QoS policies can be applied to an Epipe service:

3.7.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.7.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 7210 SAS Epipe implementation does not perform any MAC learning on the service, so Epipe services do not consume any MAC hardware resources.