5. Virtual Private LAN Service

This chapter provides information about Virtual Private LAN Service (VPLS), process overview, and implementation notes.

5.1. VPLS Service Overview

Virtual Private LAN Service (VPLS) is a class of virtual private network service that allows the connection of multiple sites in a single bridged domain over a provider-managed IP/MPLS network. The customer sites in a VPLS instance appear to be on the same LAN, regardless of their location. VPLS uses an Ethernet interface on the customer-facing (access) side which simplifies the LAN/WAN boundary and allows for rapid and flexible service provisioning.

VPLS provides a balance between point-to-point Frame Relay service and outsourced routed services. VPLS enables each customer to maintain control of their own routing strategies. All customer routers in the VPLS service are part of the same subnet (LAN) which simplifies the IP addressing plan, especially when compared to a mesh constructed from many separate point-to-point connections. The VPLS service management is simplified since the service is not aware of nor participates in the IP addressing and routing.

A VPLS service provides connectivity between two or more SAPs on one (considered a local service) or more (which is considered a distributed service) service routers. The connection appears to be a bridged domain to the customer sites so protocols, including routing protocols, can traverse the VPLS service.

Other VPLS advantages include:

VPLS is a transparent, protocol-independent service.
There is no Layer 2 protocol conversion between LAN and WAN technologies.
There is no need to design, manage, configure, and maintain separate WAN access equipment, therefore, eliminating the need to train personnel on WAN technologies such as Frame Relay.

The 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T do not support IP/MPLS uplinks and support only local VPLS service. These devices support provisioning of access SAPs or access-uplink SAPs to connect to the provider edge IP/MPLS routers, allowing users to provision an end-to-end VPLS VPN service using the concept of hierarchical VPLS.

The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C support IP/MPLS uplinks and support both local VPLS service and distributed VPLS service. This provides an option to use VPLS service configured on the node with spoke-SDPs to connect to the provider edge IP/MPLS routers or use access SAPs or access-uplink SAPs to connect to the provider edge IP/MPLS routers, allowing users to provision an end-to-end VPLS VPN service using the concept of hierarchical VPLS. The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C also support mesh SDPs for use in smaller network configurations.

5.1.1. VPLS Packet Walk-through for a Local service

This section provides an example of VPLS processing for a local VPLS service using QinQ access uplink SAPs to connect to the PE router. It is applicable to the 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C (7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C when using access uplink SAPs). It describes VPLS processing of a customer packet sent across the network from site-A connected to PE-Router-A through a 7210 SAS to site-C connected through 7210 SAS to PE-Router-C (Figure 55). This section does not describe the processing on the PE routers, but only on 7210 SAS routers.

Figure 55: VPLS Service Architecture

7210-A (Figure 56)
1. Service packets arriving at 7210-A are associated with a VPLS service instance based on the combination of the physical port and the IEEE 802.1Q tag (VLAN-ID) in the packet.
  Figure 56: Access Port Ingress Packet Format and Lookup
2. 7210-A learns the source MAC address in the packet and creates an entry in the FIB table that associates the MAC address to the service access point (SAP) on which it was received.
3. The destination MAC address in the packet is looked up in the FIB table for the VPLS instance. There are two possibilities: either the destination MAC address has already been learned (known MAC address) or the destination MAC address is not yet learned (unknown MAC address).
  Figure 57: Network Port Egress Packet Format and Flooding
  1. For a Known MAC Address (Figure 57):
    If the destination MAC address has already been learned by 7210 an existing entry in the FIB table identifies destination uplink QinQ SAP used for sending the packet toward the PE-Router-A.
    The customer packet is sent on this uplink SAP when the IEEE 802.1Q tag is stripped and the uplink SAP tag is added to the packet.
  2. For an Unknown MAC Address (Figure 57):
    If the destination MAC address has not been learned, 7210 will flood the packet to all the uplink SAPs participating in the service.
Core Router Switching
The PE router will encapsulate this packet in the appropriate MPLS header and transport it across the core network to the remote 7210-C.
7210-C (Figure 56)
1. 7210-C associates the packet with the VPLS instance based on the VLAN tags in the received packet.
2. 7210-C learns the source MAC address in the packet and creates an entry in the FIB table that associates the MAC address to the access uplink port on which the packet was received.
3. The destination MAC address in the packet is looked up in the FIB table for the VPLS instance. Again, there are two possibilities: either the destination MAC address has already been learned (known MAC address) or the destination MAC address has not been learned on the access side of 7210-C (unknown MAC address).
  1. If the destination MAC address has been learned by 7210-C, an existing entry in the FIB table identifies the local access port and the IEEE 802.1Q tag (if any) to be added before sending the packet to customer Location-C. The egress Q tag may be different from the ingress Q tag.
  2. If the destination MAC address has not been learned, 7210 will flood the packet to all the access SAPs participating in the service.

5.1.2. VPLS Packet Walk-through for a Distributed service

This section provides an example of VPLS processing for a local VPLS service using spoke-SDP/mesh-SDP as uplinks to connect to the PE routers. It is applicable to the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C when using spoke-SDP/mesh-SDP as uplinks to connect to the PE routers. It describes VPLS processing of a customer packet sent across the network from site-A connected to PE-Router-A through a 7210 SAS to site-C connected through 7210 SAS to PE-Router-C (Figure 58). This section does not describe the processing on the PE routers, but only on 7210 SAS routers.

Figure 58: VPLS Service Architecture

7210-A (Figure 59)
1. Service packets arriving at 7210-A are associated with a VPLS service instance based on the combination of the physical port and the IEEE 802.1Q tag (VLAN-ID) in the packet.
  Figure 59: Access Port Ingress Packet Format and Lookup
2. 7210-A learns the source MAC address in the packet and creates an entry in the FIB table that associates the MAC address to the service access point (SAP) on which it was received.
3. The destination MAC address in the packet is looked up in the FIB table for the VPLS in-stance. There are two possibilities: either the destination MAC address has already been learned (known MAC address) or the destination MAC address is not yet learned (unknown MAC address).
  1. For a Known MAC Address (Figure 59):
    If the destination MAC address has already been learned by 7210, an existing entry in the FIB table identifies the far-end PE-Router and the service VC-label (inner label) used before sending the packet to PE-Router-A.
    The customer packet is sent on this LSP when the IEEE 802.1Q tag is stripped and the service VC-label (inner label) and the transport label (outer label) are added to the packet.
  2. For a Unknown MAC Address (Figure 59):
    If the destination MAC address has not been learned, 7210 will flood the packet to all the spoke-SDPs participating in the service, as shown in Figure 60.
    Figure 60: Network Port Egress Packet Format and Flooding
Core Router Switching
The PE router will encapsulate this packet in the appropriate MPLS header and transport it across the core network to the remote 7210-C.
7210-C (Figure 59)
1. 7210-C associates the packet with the VPLS instance based on the VLAN tags in the received packet.
2. 7210-C learns the source MAC address in the packet and creates an entry in the FIB table that associates the MAC address to the spoke-SDP on which the packet was received.
3. The destination MAC address in the packet is looked up in the FIB table for the VPLS in-stance. Again, there are two possibilities: either the destination MAC address has already been learned (known MAC address) or the destination MAC address has not been learned on the access side of 7210-C (unknown MAC address).
  1. If the destination MAC address has been learned by 7210-C, an existing entry in the FIB table identifies the local access port and the IEEE 802.1Q tag (if any) to be added before sending the packet to customer Location-C. The egress Q tag may be different from the ingress Q tag.
  2. If the destination MAC address has not been learned, 7210 will flood the packet to all the access SAPs and possible other spoke-SDPs participating in the service.

5.2. VPLS Features

5.2.1. VPLS Enhancements on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T

The Nokia VPLS implementation includes several enhancements beyond basic VPN connectivity. The following VPLS features can be configured individually for each VPLS service instance:

Extensive MAC and IP filter support (up to Layer 4). Filters can be applied on a per SAP basis.
Forwarding Information Base (FIB) management features including:
1. Configurable FIB size limit
2. FIB size alarms
3. MAC learning disable
4. Discard unknown
5. Aging timers for learned MAC addresses.
Implementation of Spanning Tree Protocol (STP) parameters on a per VPLS and per SAP basis.
IGMP snooping on a per-SAP basis.

5.2.2. VPLS Enhancements on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The Nokia VPLS implementation includes several enhancements beyond basic VPN connectivity. The following VPLS features can be configured individually for each VPLS service instance:

Extensive MAC and IP filter support (up to Layer 4). Filters can be applied on a per SAP basis.
Forwarding Information Base (FIB) management features including:
1. Configurable FIB size limit
2. FIB size alarms
3. MAC learning disable
4. Discard unknown
5. Aging timers for learned MAC addresses
Implementation of Spanning Tree Protocol (STP) parameters on a per VPLS and per SAP basis.
IGMP snooping on a per-SAP and SDP basis.

5.2.3. VPLS over MPLS - supported on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The VPLS architecture proposed in draft-ietf-ppvpn-vpls-ldp-0x.txt specifies the use of provider equipment (PE) capable of learning, bridging, and replication on a per-VPLS basis. The PE routers that participate in the service are connected using MPLS Label Switched Path (LSP) tunnels in a full-mesh composed of mesh SDPs or based on an LSP hierarchy (Hierarchical VPLS (H-VPLS)) composed of mesh SDPs and spoke-SDPs. The 7210 SAS M supports only H-VPLS. Multiple VPLS services can be offered over the same set of LSP tunnels. Signaling specified in RFC 4905 is used to negotiate a set of ingress and egress VC labels on a per-service basis. The VC labels are used by the PE routers for de-multiplexing traffic arriving from different VPLS services over the same set of LSP tunnels.

VPLS/H-VPLS is provided over MPLS by:

Connecting 7210 SAS to bridging-capable provider edge (PE) routers through a mesh/spoke-SDP. The PE routers are connected using a full mesh of LSPs.
Negotiating per-service VC labels using draft-Martini encapsulation.
Replicating unknown and broadcast traffic in a service domain.
Enabling MAC learning over tunnel and access ports (see VPLS MAC Learning and Packet Forwarding).
Using a separate forwarding information base (FIB) per VPLS service.

5.2.4. VPLS over SAPs

7210 SAS-D and 7210 SAS-Dxp devices support QinQ SAPs or Dot1q SAPs that allows them to connect to upstream PE nodes providing IP/MPLS transport.

VPLS is provided over QinQ/Dot1q SAPs by:

Connecting bridging-capable 7210 SAS devices.
Replicating unknown and broadcast traffic in a service domain.
Enabling MAC learning over QinQ/Dot1q SAPs and access ports (see VPLS MAC Learning and Packet Forwarding).
Using a separate forwarding information base (FIB) per VPLS service.

5.2.5. VPLS MAC Learning and Packet Forwarding

The 7210 SAS edge devices perform the packet replication required for broadcast and multicast traffic across the bridged domain. MAC address learning is performed by the 7210 SAS device to reduce the amount of unknown destination MAC address flooding.

On the 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, the user can configure Layer 2 uplinks (i.e. Dot1q SAPs or QinQ SAPs) for uplink connectivity and access SAPs for customer connectivity as logical bridge ports in a VPLS service.

On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, the user can configure access SAPs for customer connectivity and mesh-sdp/spoke-sdp for uplink connectivity as logical bridge ports in a VPLS service.

Each 7210 SAS maintains a Forwarding Information Base (FIB) for each VPLS service instance and learned MAC addresses are populated in the FIB table of the service. All traffic is switched based on MAC addresses using QinQ SAPs created on access uplink ports Unknown destination packets (for example, the destination MAC address has not been learned) are forwarded on all SAPs for that service until the target station responds and the MAC address is learned by the 7210 SAS associated with that service.

5.2.5.1. IGMP Snooping on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T

In Layer 2 switches, multicast traffic is treated like an unknown MAC address or broadcast frame, which causes the incoming frame to be flooded out (broadcast) on every port within a VLAN. Although this is acceptable behavior for unknowns and broadcast frames, this flooded multicast traffic may result in wasted bandwidth on network segments and end stations, as IP multicast hosts can join and be interested in only specific multicast groups.

IGMP snooping entails using information in Layer 3 protocol headers of multicast control messages to determine the processing at Layer 2. By doing so, an IGMP snooping switch provides the benefit of conserving bandwidth on those segments of the network in which no node has expressed interest in receiving packets addressed to the group address.

IGMP snooping can be enabled in the context of VPLS services. The IGMP snooping feature allows for optimization of the multicast data flow to only the SAPs members of the group. The system builds a database of group members per service by listening to IGMP queries and reports from each SAP:

When the switch receives an IGMP report from a host for a multicast group, the switch adds the host port number to the forwarding table entry.
When it receives an IGMP leave message from a host, it removes the host port from the table entry, if no other group members are present. It also deletes entries if it does not receive periodic IGMP membership reports from the multicast clients.

The following are IGMP snooping features:

IGMP v1, v2, and v3 are supported (RFC 1112, Host Extensions for IP Multicasting, and RFC 2236, Internet Group Management Protocol, Version 2).
IGMP snooping can be enabled and disabled on individual VPLS service instances.
IGMP snooping can be configured on individual SAPs that are part of a VPLS service. When IGMP snooping is enabled on a VPLS service, all its contained SAPs automatically have snooping enabled.
Fast leave terminates the multicast session immediately, rather than using the standard group-specific query to check if other group members are present on the network.
SAPs can be statically configured as multicast router ports. This allows the operator to control the set of ports to which IGMP membership reports are forwarded.
Static multicast group membership on a per SAP basis can be configured.
The maximum number of multicast groups (static and dynamic) that a SAP can join can be configured. An event is generated when the limit is reached.
The maximum number of multicast groups (static and dynamic) that a VPLS instance simultaneously supports can be configured.
Proxy summarization of IGMP messages reduces the number of IGMP messages processed by upstream devices in the network.
IGMP filtering allows a subscriber to a service or the provider to block, receive, or transmit permission (or both) to individual hosts or a range of hosts.
The following types of filters can be defined:
1. Filter group membership that report from a host or range of hosts. This filtering is performed by importing an appropriately-defined routing policy into the SAP.
2. Filters that prevent a host from transmitting multicast streams into the network. The operator can define a data-plane filter (ACL) that drops all multicast traffic, and apply this filter to a SAP.

5.2.5.2. IGMP Snooping on 7210 SAS-K 2F6C4Tand 7210 SAS-K 3SFP+ 8C

IGMP snooping can be enabled in the context of VPLS services. The IGMP snooping feature allows for optimization of the multicast data flow to only those SAPs and SDPs that are members of the group. The system builds a database of group members per service by listening to IGMP queries and reports from each SAP and SDP:

When the switch receives an IGMP report from a host for a multicast group, the switch adds the host port number to the forwarding table entry.
When it receives an IGMP leave message from a host, it removes the host port from the table entry, if no other group members are present. It also deletes entries if it does not receive periodic IGMP membership reports from the multicast clients.

The following are IGMP snooping features:

IGMP v1, v2, and v3 are supported (RFC 1112, Host Extensions for IP Multicasting, and RFC 2236, Internet Group Management Protocol, Version 2). On 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, IGMP v1, v2, v3 is supported with both with L2 uplinks and MPLS uplinks.
IGMP snooping can be enabled and disabled on individual VPLS service instances.
IGMP snooping can be configured on individual SAPs and SDPs that are part of a VPLS service. When IGMP snooping is enabled on a VPLS service, all its contained SAPs and SDPs automatically have snooping enabled.
Fast leave terminates the multicast session immediately, rather than using the standard group-specific query to check if other group members are present on the network.
SDPs and SAPs can be statically configured as multicast router ports. This allows the operator to control the set of ports to which IGMP membership reports are forwarded.
Static multicast group membership on a per SAP and SDP basis can be configured.
The maximum number of multicast groups (static and dynamic) that a SAP and SDP can join can be configured. An event is generated when the limit is reached.
The maximum number of multicast groups (static and dynamic) that a VPLS instance simultaneously supports can be configured.
Proxy summarization of IGMP messages reduces the number of IGMP messages processed by upstream devices in the network.
IGMP filtering allows a subscriber to a service or the provider to block, receive, or transmit permission (or both) to individual hosts or a range of hosts. The following types of filters can be defined:
1. Filter group membership that report from a particular host or range of hosts. This filtering is performed by importing an appropriately-defined routing policy into the SAP and SDP.
2. Filters that prevent a host from transmitting multicast streams into the network. The operator can define a data-plane filter (ACL) that drops all multicast traffic, and apply this filter to a SAP and SDP.

5.2.5.3. Multicast VLAN Registration (MVR) support

Multicast VPLS Registration (MVR) is a bandwidth optimization method for multicast in a broadband services network. MVR allows a subscriber on a port to subscribe and unsubscribe to a multicast stream on one or more network-wide multicast VPLS instances.

MVR assumes that subscribers join and leave multicast streams by sending IGMP join and leave messages. The IGMP leave and join message are sent inside the VPLS to which the subscriber port is assigned. The multicast VPLS is shared in the network while the subscribers remain in separate VPLS services. Using MVR, users on different VPLS cannot exchange any information between them, but still multicast services are provided.

On the MVR VPLS, IGMP snooping must be enabled. On the user VPLS, IGMP snooping and MVR work independently. If IGMP snooping and MVR are both enabled, MVR reacts only to join and leave messages from multicast groups configured under MVR. Join and leave messages from all other multicast groups are managed by IGMP snooping in the local VPLS. This way, potentially several MVR VPLS instances could be configured, each with its own set of multicast channels.

MVR by proxy — In some situations, the multicast traffic should not be copied from the MVR VPLS to the SAP on which the IGMP message was received (standard MVR behavior) but to another SAP. This is called MVR by proxy.

Note:

In Figure 61, the reference to SDP is only applicable to the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

Figure 61: MVR and MVR by Proxy

5.2.5.3.1. Configuration Guidelines for MVR

In a MVR configuration, the svc-sap-type of the VPLS service that is the source, known as 'mvr vpls service' and the svc-sap-type of the VPLS service that is the sink, known as 'user vpls service' should match.

5.2.6. L2 Forwarding Table Management

The following sections describe VPLS features related to management of the Forwarding Information Base (FIB).

5.2.6.1. FIB Size on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T

The following MAC table management features are required for each instance of a SAP within a particular VPLS service instance:

MAC FIB size limits — Allows users to specify the maximum number of MAC FIB entries learned locally for a SAP. If the configured limit is reached, then no new addresses will be learned from the SAP until at least one FIB entry is aged out or cleared.
1. When the limit is reached on a SAP, packets with unknown source MAC addresses are still forwarded (this default behavior can be changed by configuration). By default, if the destination MAC address is known, it is forwarded based on the FIB, and if the destination MAC address is unknown, it will be flooded. Alternatively, if discard unknown is enabled at the VPLS service level, unknown destination MAC addresses are discarded.
2. The log event SAP MAC limit reached is generated when the limit is reached. When the condition is cleared, the log event SAP MAC Limit Reached Condition Cleared is generated.
3. Disable learning at the VPLS service level allows users to disable the dynamic learning function on the service. Disable learning is not supported at the SAP level.
4. Disable aging allows users to turn off aging for learned MAC addresses on a SAP of a VPLS service instance.

5.2.6.2. FIB Size on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The following MAC table management features are required for each instance of a SAP or spoke-SDP within a VPLS service instance:

MAC FIB size limits - Allows users to specify the maximum number of MAC FIB entries learned locally for a SAP or remotely for a spoke-SDP. If the configured limit is reached, then no new addresses will be learned from the SAP and spoke-SDP until at least one FIB entry is aged out or cleared.
1. When the limit is reached on a SAP and spoke-SDP, packets with unknown source MAC addresses are still forwarded (this default behavior can be changed by configuration). By default, if the destination MAC address is known, it is forwarded based on the FIB, and if the destination MAC address is unknown, it will be flooded. Alternatively, if discard unknown is enabled at the VPLS service level, unknown destination MAC addresses are discarded.
2. The log event SAP/SDP MAC limit reached is generated when the limit is reached. When the condition is cleared, the log event SAP/SDP MAC Limit Reached Condition Cleared is generated.
3. Disable learning at the VPLS service level allows users to disable the dynamic learning function on the service. Disable learning is not supported at the SAP level and spoke-SDP level.
4. Disable aging allows users to turn off aging for learned MAC addresses on a SAP and spoke-SDP of a VPLS service instance.

5.2.6.3. FIB Size Alarms

The size of the VPLS FIB can be configured with a low watermark and a high watermark, expressed as a percentage of the total FIB size limit. If the actual FIB size grows above the configured high watermark percentage, an alarm is generated. If the FIB size falls below the configured low watermark percentage, the alarm is cleared by the system.

5.2.6.4. Local Aging Timers on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T

Like a Layer 2 switch, learned MACs within a VPLS instance can be aged out if no packets are sourced from the MAC address for a specified period of time (the aging time). The age timer for the VPLS instance specifies the aging time for locally learned MAC addresses.

The aging mechanism is considered a low priority process. In most situations, the aging out of MAC addresses can happen in within tens of seconds beyond the age time. To minimize overhead, local MAC addresses on a LAG port, in some circumstances, can take up to two times their respective age timer to be aged out.

5.2.6.5. Local and Remote Aging Timers on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Like a Layer 2 switch, learned MACs within a VPLS instance can be aged out if no packets are sourced from the MAC address for a specified time-period (the aging time). In each VPLS service instance, there are independent aging timers for locally learned MAC and remotely learned MAC entries in the forwarding database (FIB). A local MAC address is a MAC address associated with a SAP because it ingressed on a SAP. A remote MAC address is a MAC address received by an SDP from another router for the VPLS instance. The local-age timer for the VPLS instance specifies the aging time for locally learned MAC addresses, and the remote-age timer specifies the aging time for remotely learned MAC addresses.

In general, the remote-age timer is set to a longer period than the local-age timer to reduce the amount of flooding required for destination unknown MAC addresses. The aging mechanism is considered a low priority process. In most situations, the aging out of MAC addresses can happen in within tens of seconds beyond the age time. To minimize overhead, local MAC addresses on a LAG port and remote MAC addresses, in some circumstances, can take up to two times their respective age timer to be aged out.

5.2.6.6. Disable MAC Aging

The MAC aging timers can be disabled which will prevent any learned MAC entries from being aged out of the FIB. When aging is disabled, it is still possible to manually delete or flush learned MAC entries. Aging can be disabled for learned MAC addresses on a SAP of a VPLS service instance.

5.2.6.7. Disable MAC Learning

When MAC learning is disabled for a service, new source MAC addresses are not entered in the VPLS FIB. MAC learning can be disabled for services.

5.2.6.8. Unknown MAC Discard

Unknown MAC discard is a feature which discards all packets ingressing the service where the destination MAC address is not in the FIB. The normal behavior is to flood these packets to all end points in the service.

Unknown MAC discard can be used with the disable MAC learning and disable MAC aging options to create a fixed set of MAC addresses allowed to ingress and traverse the service.

5.2.6.9. VPLS and Rate Limiting

Traffic that is usually flooded throughout the VPLS can be rate limited on SAP ingress using service ingress QoS policies. In a service ingress QoS policy, individual meters can be defined per forwarding class to provide rate-limiting/policing of broadcast traffic, MAC multicast traffic and unknown destination MAC traffic.

Note:

On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, the option is available to use either service ingress queues with rate shapers or meters to limit different traffic types.

5.2.6.10. MAC Move

The MAC move feature is useful to protect against undetected loops in a VPLS topology, as well as the presence of duplicate MACs in a VPLS service.

If two clients in the VPLS have the same MAC address, the VPLS will experience a high relearn rate for the MAC.

When MAC move is enabled, the 7210 SAS-D, 7210 SAS-Dxp, or 7210 SAS-K 2F1C2T shut down the SAP and create an alarm event when the threshold is exceeded.

When MAC move is enabled, the 7210 SAS-K 2F6C4T or 7210 SAS-K 3SFP+ 8C shut down the SAP or spoke-SDP and create an alarm event when the threshold is exceeded.

5.2.6.11. Split Horizon SAP Groups

Note:

Split Horizon group per service is only supported on the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C.
Port-based split horizon groups are only supported on the 7210 SAS-D and 7210 SAS-Dxp.

In many applications, the split-horizon group concept involving a group of SAPs is useful to prevent direct customer-to-customer traffic exchange (without the traffic being sent to the head-end service nodes). This extension is referred to as a split horizon SAP group. Traffic arriving on a SAP or a spoke-SDP within a split horizon group will not be forwarded to other SAPs configured in the same split horizon group, but will be forwarded to other SAPs, which are not part of the split horizon group.

5.2.6.11.1. Split Horizon SAP Groups and Split Horizon Spoke-SDP Groups on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Within the context of VPLS services, a loop-free topology inside a fully meshed VPLS core is achieved by applying a split-horizon forwarding concept. The packets received from a mesh SDP are never forwarded to other mesh SDPs within the same service. The advantage of this approach is that no protocol is required to detect loops within the VPLS core network.

In applications, such as residential aggregation, it is useful to extend this split-horizon concept also to groups of SAPs and/or spoke-SDPs. This extension is referred to as a split horizon SAP group/spoke-SDP group. Traffic arriving on a SAP or a spoke-SDP within a split horizon group will not be forwarded to other SAPs and spoke-SDPs configured in the same split horizon group, but will be forwarded to other SAPs/spoke-SDPs, which are not part of the split horizon group.

5.2.7. VPLS and Spanning Tree Protocol

The 7210 SAS VPLS service provides a bridged or switched Ethernet Layer 2 network. Equipment connected to SAPs forward Ethernet packets into the VPLS service. The 7210 SAS participating in the service learns where the customer MAC addresses reside, on ingress SAPs.

Unknown destinations, broadcasts, and multicasts are flooded to all other SAPs in the service. If SAPs are connected, either through misconfiguration or for redundancy purposes, loops can form and flooded packets can keep flowing through the network. The Nokia implementation of the Spanning Tree Protocol (STP) is designed to remove these loops from the VPLS topology. This is done by putting one or several SAPs in the discarding state.

The Nokia implementation of the Spanning Tree Protocol (STP) incorporates some modifications to make the operational characteristics of VPLS more effective.

The STP instance parameters allow the balancing between resiliency and speed of convergence extremes. Modifying parameters can affect the behavior. For information about command usage, descriptions, and CLI syntax, see Configuring a VPLS Service with CLI.

5.2.7.1. Spanning Tree Operating Modes

Per VPLS instance, a preferred STP variant can be configured. The STP variants supported are:

rstp — Rapid Spanning Tree Protocol (RSTP) compliant with IEEE 802.1D-2004 - default mode
dot1w — Compliant with IEEE 802.1w
comp-dot1w — Operation as in RSTP but backwards compatible with IEEE 802.1w (this mode allows interoperability with some MTU types)
mstp — Compliant with the Multiple Spanning Tree Protocol specified in IEEE 802.1Q-REV/D5.0-09/2005. This mode of operation is only supported in an mVPLS.

While the 7210 SAS initially uses the mode configured for the VPLS, it will dynamically fall back (on a per-SAP basis) to STP (IEEE 802.1D-1998) based on the detection of a BPDU of a different format. A trap or log entry is generated for every change in spanning tree variant.

Some older 802.1W compliant RSTP implementations may have problems with some of the features added in the 802.1D-2004 standard. Inter-working with these older systems is improved with the comp-dot1w mode. The differences between the RSTP mode and the comp-dot1w mode are:

The RSTP mode implements the improved convergence over shared media feature, for example, RSTP will transition from discarding to forwarding in 4 seconds when operating over shared media. The comp-dot1w mode does not implement this 802.1D-2004 improvement and transitions conform to 802.1w in 30 seconds (both modes implement fast convergence over point-to-point links).
In the RSTP mode, the transmitted BPDUs contain the port's designated priority vector (DPV) (conforms to 802.1D-2004). Older implementations may be confused by the DPV in a BPDU and may fail to recognize an agreement BPDU correctly. This would result in a slow transition to a forwarding state (30 seconds). For this reason, in the comp-dot1w mode, these BPDUs contain the port's port priority vector (conforms to 802.1w).

The 7210 SAS supports one BDPU encapsulation formats, and can dynamically switch between the following supported formats (on a per-SAP basis):

IEEE 802.1D STP
Cisco PVST

5.2.7.2. Multiple Spanning Tree

The Multiple Spanning Tree Protocol (MSTP) extends the concept of the IEEE 802.1w Rapid Spanning Tree Protocol (RSTP) by allowing grouping and associating VLANs to Multiple Spanning Tree Instances (MSTI). Each MSTI can have its own topology, which provides architecture enabling load balancing by providing multiple forwarding paths. At the same time, the number of STP instances running in the network is significantly reduced as compared to Per VLAN STP (PVST) mode of operation. Network fault tolerance is also improved because a failure in one instance (forwarding path) does not affect other instances.

The 7210 SAS implementation of Management VPLS (mVPLS) is used to group different VPLS instances under single RSTP instance. Introducing MSTP into the mVPLS allows the following:

Inter-operation with traditional Layer 2 switches in access network.
Provides an effective solution for dual homing of many business Layer 2 VPNs into a provider network.

5.2.7.2.1. Redundancy Access to VPLS

The GigE MAN portion of the network is implemented with traditional switches. Using MSTP running on individual switches facilitates redundancy in this part of the network. To provide dual homing of all VPLS services accessing from this part of the network, the VPLS PEs must participate in MSTP.

This can be achieved by the following:

Configuring mVPLS on VPLS-PEs (only PEs directly connected to GigE MAN network).
Assign different managed-vlan ranges to different MSTP instances.

Typically, the mVPLS would have SAPs with null encapsulations (to receive, send, and transmit MSTP BPDUs) and a mesh SDP to interconnect a pair of VPLS PEs.

Different access scenarios are displayed in Figure 62 as example network diagrams dually connected to the PBB PEs:

Access Type A — Source devices connected by null or Dot1q SAPs
Access Type B — One QinQ switch connected by QinQ/801ad SAPs
Access Type C — Two or more ES devices connected by QinQ/802.1ad SAPs
Figure 62: Access Resiliency

The following mechanisms are supported for the VPLS:

STP/RSTP can be used for all access types
M-VPLS with MSTP can be used as is just for access Type A. MSTP is required for access type B and C.
LAG and MC-LAG can be used for access Type A and B.

5.2.7.3. MSTP for QinQ SAPs

MSTP runs in a MVPLS context and can control SAPs from source VPLS instances. QinQ SAPs are supported. The outer tag is considered by MSTP as part of VLAN range control.

5.2.7.3.1. MSTP General Principles

MSTP represents modification of RSTP that allows the grouping of different VLANs into multiple MSTIs. To enable different devices to participate in MSTIs, they must be consistently configured. A collection of interconnected devices that have the same MST configuration (region-name, revision and VLAN-to-instance assignment) comprises an MST region.

There is no limit to the number of regions in the network, but every region can support a maximum of 16 MSTIs. Instance 0 is a special instance for a region, known as the Internal Spanning Tree (IST) instance. All other instances are numbered from 1 to 4094. IST is the only spanning-tree instance that sends and receives BPDUs (typically BPDUs are untagged). All other spanning-tree instance information is included in MSTP records (M-records), which are encapsulated within MSTP BPDUs. This means that single BPDU carries information for multiple MSTI which reduces overhead of the protocol.

Any given MSTI is local to an MSTP region and completely independent from an MSTI in other MST regions. Two redundantly connected MST regions will use only a single path for all traffic flows (no load balancing between MST regions or between MST and SST region).

Traditional Layer 2 switches running MSTP protocol assign all VLANs to the IST instance per default. The operator may then “re-assign” individual VLANs to a specific MSTI by configuring per VLAN assignment. This means that a SR-Series PE can be considered as the part of the same MST region only if the VLAN assignment to IST and MSTIs is identical to the one of Layer 2 switches in access network.

5.2.7.3.2. MSTP in the 7210 SAS Platform

The 7210 SAS platform uses a concept of mVPLS to group different SAPs under a single STP instance. The VLAN range covering SAPs to be managed by a specific mVPLS is declared under a specific mVPLS SAP definition. MSTP mode-of-operation is only supported in an mVPLS.

When running MSTP, by default, all VLANs are mapped to the CIST. On the VPLS level VLANs can be assigned to specific MSTIs. When running RSTP, the operator must explicitly indicate, per SAP, which VLANs are managed by that SAP.

5.2.7.4. Enhancements to the Spanning Tree Protocol in MPLS-based VPLS Service (7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C Only)

To interconnect 7210 SAS devices (PE devices) across the backbone, service tunnels (SDPs) are used. These service tunnels are shared among multiple VPLS instances. The Nokia implementation of the Spanning Tree Protocol (STP) incorporates some enhancements to make the operational characteristics of VPLS more effective. The implementation of STP on the router is modified to guarantee that service tunnels will not be blocked in any circumstance without imposing artificial restrictions on the placement of the root bridge within the network. The modifications introduced are fully compliant with the 802.1D-2004 STP specification.

When running MSTP, spoke-SDPs cannot be configured. Also, ensure that all bridges connected by mesh SDPs are in the same region. If not, the mesh will be prevented from becoming active (trap is generated).

To achieve this, all mesh SDPs are dynamically configured as either root ports or designated ports. The PE devices participating in each VPLS mesh determine (using the root path cost learned as part of the normal protocol exchange) which of the 7210 SAS devices is closest to the root of the network. This PE device is internally designated as the primary bridge for the VPLS mesh. Because of this, all network ports on the primary bridges are assigned the designated port role and therefore remain in the forwarding state.

The second part of the solution ensures that the remaining PE devices participating in the STP instance see the SDP ports as a lower cost path to the root rather than a path that is external to the mesh. Internal to the PE nodes participating in the mesh, the SDPs are treated as zero cost paths toward the primary bridge. As a consequence, the path through the mesh are seen as lower cost than any alternative and the PE node will designate the network port as the root port. This ensures that network ports always remain in forwarding state.

A combination of the preceding features ensure that network ports are never blocked and maintain interoperability with bridges external to the mesh running STP instances.

5.2.7.4.1. L2PT Termination

L2PT is used to transparently transport protocol data units (PDUs) of Layer 2 protocols such as STP, CDP, DTP, VTP, PAGP, and UDLD. This allows running these protocols between customer CPEs without involving backbone infrastructure.

The 7210 SAS routers allow transparent tunneling of PDUs across the VPLS core. However, in some network designs, the VPLS PE is connected to CPEs through a legacy Layer 2 network, rather than having direct connections. In such environments termination of tunnels through such infrastructure is required.

L2PT tunnels protocol PDUs by overwriting MAC destination addresses at the ingress of the tunnel to a proprietary MAC address such as 01-00-0c-cd-cd-d0. At the egress of the tunnel, this MAC address is then overwritten back to MAC address of the respective Layer 2 protocol.

The 7210 SAS nodes support L2PT termination for STP BPDUs. More specifically:

At ingress of every SAP which is configured as L2PT termination, all PDUs with a MAC destination address, 01-00-0c-cd-cd-d0 will be intercepted and their MAC destination address will be overwritten to MAC destination address used for the corresponding protocol. The type of protocol can be derived from LLC and SNAP encapsulation.
In egress direction, PDUs of the corresponding protocol received on all VPLS ports will be intercepted and L2PT encapsulation will be performed for SAPs configured as L2PT termination points. Because of the implementation reasons, PDU interception and redirection to CPM can be performed only at ingress. Therefore, to comply with the preceding requirement, as soon as at least 1 port of a specific VPLS service is configured as L2PT termination port, redirection of PDUs to CPM will be set on all other ports (SAPs) of the VPLS service.

L2PT termination can be enabled only if STP is disabled in a context of the specific VPLS service.

5.2.7.4.2. BPDU Translation

VPLS networks are typically used to interconnect different customer sites using different access technologies such as Ethernet and bridged-encapsulated ATM PVCs. Typically, different Layer 2 devices can support different types of STP and even if they are from the same vendor. In some cases, it is necessary to provide BPDU translation to provide an inter-operable e2e solution.

To address these network designs, BPDU format translation is supported on 7210 SAS devices. If enabled on a specific SAP, the system will intercept all BPDUs destined to that interface and perform required format translation such as STP-to-PVST or vice versa.

Similarly, BPDU interception and redirection to the CPM is performed only at ingress meaning that as soon as at least 1 port within a specific VPLS service has BPDU translation enabled, all BPDUs received on any of the VPLS ports will be redirected to the CPM.

BPDU translation involves all encapsulation actions that the data path would perform for a specific outgoing port (such as adding VLAN tags depending on the outer SAP and adding or removing all the required VLAN information in a BPDU payload.

This feature can be enabled on a SAP only if STP is disabled in the context of the specific VPLS service.

5.2.7.4.3. L2PT and BPDU Translation

Cisco Discovery Protocol (CDP), Digital Trunking Protocol (DTP), Port Aggregation Protocol (PAgP), Uni-directional Link Detection (UDLD), Virtual Trunk Protocol (VTP), STP (Spanning Tree Protocol) and PVST (per-VLAN Spanning Tree protocol) are supported on the 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C.

The existing L2PT limitations apply.

The protocols apply only to VPLS.
The protocols are mutually exclusive with running STP on the same VPLS as soon as one SAP has L2PT/BPDU translation enabled.
Forwarding occurs on the CPM and uses CPU processing cycles.

5.2.8. VPLS Access Redundancy

Note:

On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, the mechanisms discussed in this section are applicable when access ports or access-uplink ports are used as uplinks.

One application of hierarchical VPLS is to use 7210 SAS nodes with access ports or access-uplink ports as uplinks, which serve as Ethernet links to the closest PE node.

The following are several mechanisms to resolve a loop in an access network where 7210 SAS devices are used.

STP-based access, with or without mVPLS
Ethernet APS using G.8032
Non-STP-based access using mechanisms such as active/standby links and MC-LAG on the PE

5.2.8.1. STP-Based Redundant Access to VPLS

Figure 63: Dual Homed 7210 SAS-D Acting as MTU-s in Two-Tier Hierarchy H-VPLS

In configuration shown in Figure 63, STP is activated on the MTU and two PEs to resolve a potential loop.

In this configuration, the scope of STP domain is limited to MTU and PEs, while any topology change needs to be propagated in the whole VPLS domain. When TCN (topology change notification) is received with in the VPLS domain all MACs learned on SAPs are flushed except the SAP on which TCN was received.

5.2.9. VPLS Redundancy on 7210 SAS-K 2F6C4Tand 7210 SAS-K 3SFP+ 8C using MPLS uplinks

The VPLS standard (RFC 4762, Virtual Private LAN Services Using LDP Signaling) includes provisions for hierarchical VPLS, using point-to-point spoke-SDPs. Two applications have been identified for spoke-SDPs:

To connect to Multi-Tenant Units (MTUs) to PEs in a metro area network;
To interconnect the VPLS nodes of two networks.

In both applications, the spoke-SDPs serve to improve the scalability of VPLS. While node redundancy is implicit in non-hierarchical VPLS services (using a full mesh of SDPs between PEs), node redundancy for spoke-SDPs needs to be provided separately. In VPLS services, only two spoke-SDPs are allowed in an endpoint.

The 7210 SAS routers have implemented special features for improving the resilience of hierarchical VPLS instances, in both MTU and inter-metro applications.

5.2.9.1. Spoke-SDP Redundancy on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

When two or more meshed VPLS instances are interconnected by redundant spoke-SDPs (as shown in Figure 64), a loop in the topology results. To remove such a loop from the topology, Spanning Tree Protocol (STP) can be run over the SDPs (links) which form the loop, such that one of the SDPs is blocked. As running STP in each VPLS in this topology is not efficient, the node includes functionality which can associate several VPLSes to a single STP instance running over the redundant-SDPs. Node redundancy is therefore achieved by running STP in one VPLS, and applying the conclusions of this STP to the other VPLS services. The VPLS instance running STP is referred to as the “management VPLS” or mVPLS.

In the case of a failure of the active node, STP on the management VPLS in the standby node will change the link states from disabled to active. The standby node will then broadcast a MAC flush LDP control message in each of the protected VPLS instances, so that the address of the newly active node can be relearned by all PEs in the VPLS.

It is possible to configure two management VPLS services, where both VPLS services have different active spokes (this is achieved by changing the path-cost in STP). By associating different user VPLSes with the two management VPLS services, load balancing across the spokes can be achieved.

Figure 64: H-VPLS with spoke redundancy

5.2.9.2. Spoke-SDP Based Redundant Access on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

This feature provides the ability to have a node deployed as MTUs (Multi-Tenant Unit Switches) multi-homed for VPLS to multiple routers deployed as PEs without requiring the use of mVPLS.

In the configuration example displayed in Figure 64, the MTUs have spoke-SDPs to two PEs devices. One is designated as the primary and one as the secondary spoke-SDP. This is based on a precedence value associated with each spoke. If the primary and secondary spoke-SDPs have the same precedence value, the spoke-SDP with lower ID functions as the primary SDP.

The secondary spoke is in a blocking state (both on receive and transmit) if the primary spoke is available. When the primary spoke becomes unavailable (due to link failure, PEs failure, etc.), the MTU immediately switches traffic to the backup spoke and starts receiving/sending traffic to/from the standby spoke. Optional revertive operation (with configurable switch-back delay) is applicable only when one of the spokes is configured with precedence of primary. If not, this action does not take place. Forced manual switchover is also supported.

To speed up the convergence time during a switchover, MAC flush is configured. The MTUs generates a MAC flush message over the newly unblocked spoke when a spoke change occurs. As a result, the PEs receiving the MAC flush will flush all MACs associated with the impacted VPLS service instance and forward the MAC flush to the other PEs in the VPLS network if “propagate-mac-flush” is enabled.

5.2.9.3. Inter-Domain VPLS Resiliency Using Multi-Chassis Endpoints on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Note:

MC-EP is not supported on the 7210 SAS. This section provides an example of how 7210 SAS devices can be used as MTU devices in an MC-EP solution. In this solution, the 7750 SR routers provide the MC-EP functionality.

Inter-domain VPLS refers to a VPLS deployment where sites may be in different domains. An example of inter-domain deployment can be where different Metro domains are interconnected over a Wide Area Network (Metro1-WAN-Metro2) or where sites are in different autonomous systems (AS1-ASBRs-AS2).

Multi-chassis endpoint (MC-EP) provides an alternate solution that does not require RSTP at the gateway VPLS PEs while still using pseudo wires to interconnect the VPLS instances located in the two domains.

MC-EP expands the single chassis endpoint based on active-standby pseudo wires for VPLS shown in Figure 65. In the solution depicted by the Figure 65, 7210 devices are used as MTUs.

Figure 65: H-VPLS Resiliency based on AS Pseudowires

The active-standby Pseudowires solution is appropriate for the scenario when only one VPLS PE (MTU-s) needs to be dual-homed to two core PEs (PE1 and PE2).

5.2.10. VPLS Access Redundancy When Using MPLS Uplinks on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

A second application of hierarchical VPLS is using MTUs that are MPLS-enabled which must have spoke-SDPs to the closest PE node. To protect against failure of the PE node, an MTU can be dual-homed.

The following are several mechanisms to resolve a loop in an access network where 7210s are used.

STP-based access, with or without mVPLS
Ethernet APS using G.8032

5.2.10.1. STP-Based Redundant Access to VPLS Using PWs on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Figure 66: Dual Homed MTUs in Two-Tier Hierarchy H-VPLS

In configuration shown in Figure 66, STP is activated on the MTU and two PEs to resolve a potential loop. To remove such a loop from the topology, Spanning Tree Protocol (STP) can be run over the SDPs (links) which form the loop such that one of the SDPs is blocked. Running STP in every VPLS in this topology is not efficient as the node includes functionality which can associate a number of VPLSes to a single STP instance running over the redundant SDPs.

Node redundancy is therefore achieved by running STP in one VPLS. Therefore, this applies the conclusions of this STP to the other VPLS services.

The VPLS instance running STP is referred to as the “management VPLS” or mVPLS. In the case of a failure of the active node, STP on the management VPLS in the standby node will change the link states from disabled to active. The standby node will then broadcast a MAC flush LDP control message in each of the protected VPLS instances, so that the address of the newly active node can be relearned by all PEs in the VPLS. It is possible to configure two management VPLS services, where both VPLS services have different active spokes (this is achieved by changing the path-cost in STP). By associating different user VPLSes with the two management VPLS services, load balancing across the spokes can be achieved.

In this configuration, the scope of STP domain is limited to MTU and PEs, while any topology change needs to be propagated in the whole VPLS domain.

This is done by using “MAC-flush” messages defined by RFC 4762, Virtual Private LAN Services Using LDP Signaling. In the case where STP acts as a loop resolution mechanism, every Topology Change Notification (TCN) received in a context of STP instance is translated into an LDP-MAC address withdrawal message (also referred to as a MAC-flush message) requesting to clear all FDB entries except the ones learned from the originating PE. Such messages are sent to all PE peers connected through SDPs (mesh and spoke) in the context of VPLS services managed by the specific STP instance.

5.2.10.2. Redundant Access to VPLS Without STP and Using MPLS Uplinks on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The Nokia implementation also alternative methods for providing a redundant access to Layer 2 services, such as MC-LAG. Also in this case, the topology change event needs to be propagated into VPLS topology to provide fast convergence.

Figure 64 shows a dual-homed connection to VPLS service (PE-A, PE-B, PE-C, PE-D) and operation in case of link failure (between PE-C and L2-B). Upon detection of a link failure PE-C will send MAC-Address-Withdraw messages, which will indicate to all LDP peers that they should flush all MAC addresses learned from PE-C. This will lead that to a broadcasting of packets addressing affected hosts and relearning process in case an alternative route exists.

Note that the message described here is different from the message described in previous section and in RFC 4762, Virtual Private LAN Services Using LDP Signaling. The difference is in the interpretation and action performed in the receiving PE. Per the standard definition, upon receipt of a MAC withdraw message, all MAC addresses, except the ones learned from the source PE, are flushed.

This section specifies that all MAC addresses learned from the source are flushed. This message has been implemented as an LDP address message with vendor-specific type, length, value (TLV), and is called the flush-mine message.

The advantage of this approach (as compared to RSTP based methods) is that only MAC-affected addresses are flushed and not the full forwarding database. While this method does not provide a mechanism to secure alternative loop-free topology, the convergence time is dependent on the speed of the specific CE device will open alternative link (L2-B switch) as well as on the speed PE routers will flush their FDB.

In addition, this mechanism is effective only if PE and CE are directly connected (no hub or bridge) as it reacts to physical failure of the link.

5.2.10.3. MAC Flush Message Processing in VPLS Services With MPLS Uplinks on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The previous sections described operation principle of several redundancy mechanisms available in context of VPLS service. All of them rely on MAC flush message as a tool to propagate topology change in a context of the specific VPLS. This section aims to summarize basic rules for generation and processing of these messages.

As described on respective sections, the 7210 SAS supports two types of MAC flush message, flush-all-but-mine and flush-mine. The main difference between these messages is the type of action they signal. Flush-all-but-mine requests clearing of all FDB entries learned from all other LDP peers except the originating PE. This type is also defined by RFC 4762 as an LDP MAC address withdrawal with an empty MAC address list.

Flush-all-mine message requests clearing all FDB entries learned from originating PE. This means that this message has exactly other effect then flush-all-but-mine message. This type is not included in RFC 4762 definition and it is implemented using vendor specific TLV.

The advantages and disadvantages of the individual types should be apparent from examples in the previous section. The description here focuses on summarizing actions taken on reception and conditions individual messages are generated.

Upon reception of MAC flush messages (regardless the type) SR-Series PE will take following actions:

Clears FDB entries of all indicated VPLS services conforming the definition.
Propagates the message (preserving the type) to all LDP peers, if “propagate-mac-flush” flag is enabled at corresponding VPLS level.

The flush-mine message is generated under following conditions:

The flush-mine message is received from LDP peer and “propagate-mac-flush” flag is enabled. The message is sent to all LDP peers in the context of VPLS service it was received.
The flush-mine message is generated when on a SAP or SDP transition from operationally up to an operationally down state and send-flush-on-failure flag is enabled in the context of the specific VPLS service. The message is sent to all LDP peers connected in the context of the specific VPLS service. Note, that enabling “send-flush-on-failure” the flag is blocked in VPLS service managed by mVPLS. This is to prevent both messages being sent at the same time.

5.2.10.4. Dual Homing to a VPLS Service on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Figure 67: Dual Homed CE Connection to VPLS

Figure 67 shows a dual-homed connection to VPLS service (PE-A, PE-B, PE-C, PE-D) and operation in case of link failure (between PE-C and L2-B). Upon detection of a link failure PE-C will send MAC-Address-Withdraw messages, which will indicate to all LDP peers that they should flush all MAC addresses learned from PE-C. This will lead that to a broadcasting of packets addressing affected hosts and relearning process in case an alternative route exists.

Note that the message described here is different from the message described in draft-ietf-l2vpnvpls-ldp-xx.txt, Virtual Private LAN Services over MPLS. The difference is in the interpretation and action performed in the receiving PE. According the draft definition, upon receipt of a MAC withdraw message, all MAC addresses, except the ones learned from the source PE, are flushed. This section specifies that all MAC addresses learned from the source are flushed. This message has been implemented as an LDP address message with vendor-specific type, length, value (TLV), and is called the flush-all-from-ME message.

The draft definition message is currently used in management VPLS which is using RSTP for recovering from failures in Layer 2 topologies. The mechanism described in this document represent an alternative solution.

The advantage of this approach (as compared to RSTP based methods) is that only MAC-affected addresses are flushed and not the full forwarding database. While this method does not provide a mechanism to secure alternative loop-free topology, the convergence time is dependent on the speed of the specific CE device will open alternative link (L2-B switch in Figure 67) as well as on the speed PE routers will flush their FDB.

In addition, this mechanism is effective only if PE and CE are directly connected (no hub or bridge) as it reacts to physical failure of the link.

5.2.11. VPLS Service Considerations

This section describes various 7210 SAS service features and any special capabilities or considerations as they relate to VPLS services.

5.2.11.1. SAP Encapsulations

VPLS services are designed to carry Ethernet frame payloads, so it can provide connectivity between any SAPs that pass Ethernet frames. The following SAP encapsulations are supported on the VPLS service on an access port:

Ethernet null (Supported on all platforms)
Ethernet Dot1q (Supported on all platforms)
Ethernet QinQ (Supported on 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C)

The following encapsulations are supported on an access-uplink port:

Ethernet QinQ (Supported on all platforms)

5.2.11.2. VLAN Processing

The SAP encapsulation definition on Ethernet ingress ports defines which VLAN tags are used to determine the service that the packet belongs:

Null encapsulation defined on ingress — Any VLAN tags are ignored and the packet goes to a default service for the SAP.
Dot1q encapsulation defined on ingress — Only first VLAN tag is considered.
QinQ encapsulation defined on ingress— Both VLAN tags are considered.
Note that the SAP can be defined with a wild-card for the inner label (for example, “100.*”). In this situation all packets with an outer label of 100 will be treated as belonging to the SAP. If, on the same physical link, there is also a SAP defined with a QinQ encapsulation of 100.1, then traffic with 100.1 will go to that SAP and all other traffic with 100 as the first label will go to the SAP with the *100.* definition.

In situations 2 and 3, traffic encapsulated with tags for which there is no definition are discarded.

5.3. BGP-AD VPLS

5.3.1. BGP-AD and Target LDP (T-LDP) Interaction on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Note:

This feature is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

BGP is responsible for discovering the location of VSIs that share the same VPLS membership. LDP protocol is responsible for setting up the pseudowire infrastructure between the related VSIs by exchanging service specific labels between them.

When the local VPLS information is provisioned in the local PE, the related PEs participating in the same VPLS are identified through BGP AD exchanges. A list of far-end PEs is generated and triggers the creation, if required, of the necessary T-LDP sessions to these PEs and the exchange of the service specific VPN labels. The steps for the BGP AD discovery process and LDP session establishment and label exchange are shown in Figure 68.

Figure 68: BGP-AD and T-LDP Interaction

Key:

Establish I-BGP connectivity RR.
Configure VPN (10) on edge node (PE3).
Announce VPN to RR using BGP-AD.
Send membership update to each client of the cluster.
LDP exchange or inbound FEC filtering (IFF) of non-match or VPLS down.
Configure VPN (10) on edge node (PE2).
Announce VPN to RR using BGP-AD.
Send membership update to each client of the cluster.
LDP exchange or inbound FEC filtering (IFF) of non-match or VPLS down.
Complete LDP bidirectional pseudowire establishment FEC 129.

5.3.2. BGP-AD VPLS - SDP Usage

Service Access Points (SAP) are linked to transport tunnels using Service Distribution Points (SDP). The service architecture of the 7210 platform allows services to be abstracted from the transport network.

MPLS transport tunnels are signaled using the Resource Reservation Protocol (RSVP-TE) or by the Label Distribution Protocol (LDP). The capability to automatically create an SDP only exists for LDP based transport tunnels. Using a manually provisioned SDP is available for both RSVP-TE and LDP transport tunnels. See the 7210 SAS-K 2F6C4T, K 3SFP+ 8C MPLS Guidefor more information about MPLS, LDP, and RSVP.

5.3.3. BGP-AD VPLS - Automatic Creation of SDPs

When BGP AD is used for LDP VPLS and LDP is used as the transport tunnel there is no requirement to manually create an SDP. The LDP SDP can be automatically instantiated using the information advertised by BGP AD. This simplifies the configuration on the service node.

Enabling LDP on the IP interfaces connecting all nodes between the ingress and the egress, builds transport tunnels based on the best IGP path. LDP bindings are automatically built and stored in the hardware. These entries contain an MPLS label pointing to the best next hop along the best path toward the destination.

When two endpoints need to connect and no SDP exists, a new SDP will automatically be constructed. New services added between two endpoints that already have an automatically created SDP will be immediately used. No new SDP will be constructed.

The far-end information is gleaned from the BGP next hop information in the NLRI. When services are withdrawn with a BGP_Unreach_NLRI, the automatically established SDP will remain up as long as at least one service is connected between those endpoints. An automatically created SDP will be removed and the resources released when the only or last service is removed.

5.3.4. BGP-AD VPLS - Manually Provisioned SDP

The carrier is required to manually provision the SDP if they create transport tunnels using RSVP-TE. Operators have the option to choose a manually configured SDP, if they use LDP as the tunnel signaling protocol. The functionality is the same regardless of the signaling protocol.

Creating a BGP-AD enabled VPLS service on an ingress node with the manually provisioned SDP option causes the Tunnel Manager to search for an existing SDP that connects to the far-end PE. The far-end IP information is gleaned from the BGP next hop information in the NLRI. If a single SDP exists to that PE, it is used. If no SDP is established between the two endpoints, the service remains down until a manually configured SDP becomes active.

When multiple SDPs exist between two endpoints, the tunnel manager selects the appropriate SDP. The algorithm preferred SDPs with the best (lower) metric. Should there be multiple SDPs with equal metrics, the operational state of the SDPs with the best metric is considered. If the operational state is the same, the SDP with the higher sdp-id is used. If an SDP with a preferred metric is found with an operational state that is not active, the tunnel manager flags it as ineligible and restarts the algorithm.

5.3.5. BGP-AD VPLS - Automatic Instantiation of Pseudowires (SDP Bindings)

The choice of manual or auto provisioned SDPs has limited impact on the amount of required provisioning. Most of the savings are achieved through the automatic instantiation of the pseudowire infrastructure (SDP bindings). This is achieved for every auto-discovered VSIs through the use of the pseudowire template concept. Each VPLS service that uses BGP AD contains the “pw-template-binding” option defining specific Layer 2 VPN parameters. This command references a “pw-template” which defines the pseudowire parameters. The same “pwtemplate” may be referenced by multiple VPLS services. As a result, changes to these pseudowire templates have to be treated with great care as they may impact many customers at once.

The Nokia implementation provides for safe handling of pseudowire templates. Changes to the pseudowire templates are not automatically propagated. Tools are provided to evaluate and distribute the changes. The following command is used to distribute changes to a “pw-template” at the service level to one or all services that use that template.

PERs-4# tools perform service id 300 eval-pw-template 1 allow-service-impact

If the service ID is omitted, then all services are updated. The type of change made to the “pwtemplate” influences how the service is impacted.

Adding or removing a split-horizon-group will cause the router to destroy the original object and recreate using the new value.
Changing parameters in the vc-type {ether | vlan} command requires LDP to re-signal the labels.

5.3.6. BGP-AD VPLS - Mixing Statically Configured and Auto-Discovered Pseudowires in a VPLS service

The services implementation allows for manually provisioned and auto-discovered pseudowire (SDP bindings) to co-exist in the same VPLS instance (for example, both FEC128 and FEC 129 are supported). This allows for gradual introduction of auto discovery into an existing VPLS deployment.

As FEC 128 and 129 represent different addressing schemes, it is important to make sure that only one is used at any point in time between the same two VPLS instances. Otherwise, both pseudowires may become active causing a loop that might adversely impact the correct functioning of the service. It is recommended that FEC128 pseudowire be disabled as soon as the FEC129 addressing scheme is introduced in a portion of the network. Alternatively, RSTP may be used during the migration as a safety mechanism to provide additional protection against operational errors.

5.3.7. BGP-AD VPLS - Resiliency Schemes

The use of BGP-AD on the network side, or in the backbone, does not affect the different resiliency schemes Nokia has developed in the access network. This means that both Multi-Chassis Link Aggregation (MC-LAG) and Management-VPLS (M-VPLS) can still be used.

BGP-AD may co-exist with Hierarchical-VPLS (H-VPLS) resiliency schemes (for example, dual homed MTU-s devices to different PE-rs nodes) using existing methods (M-VPLS and statically configured Active or Standby pseudowire endpoint).

If provisioned SDPs are used by BGP AD, M-VPLS may be employed to provide loop avoidance. However, it is currently not possible to auto-discover active or standby pseudowires and to instantiate the related endpoint.

5.4. Routed VPLS

Routed VPLS (R-VPLS) allows a VPLS instance to be associated with an IES IP interface on the 7210 SAS-D, 7210 SAS-Dxp, or 7210 SAS-K 2F1C2T. IPv4 addressing and forwarding is supported on the 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T platforms. IPv6 addressing and forwarding is supported on the 7210 SAS-Dxp platform.

Routed VPLS (R-VPLS) allows a VPLS instance to be associated with an IES or VPRN IP interface on the 7210 SAS-K 2F6C4T or 7210 SAS-K 3SFP+ 8C. Only IPv4 addressing and forwarding is supported on these platforms.

Within an R-VPLS service, traffic with a destination MAC matching that of the associated IP interface is routed based on the IP forwarding table; all other traffic is forwarded based on the VPLS forwarding table.

On the 7210 SAS-D and 7210 SAS-K 2F1C2T, R-VPLS service can be associated with an IPv4 interface and supports only static routing. It is primarily designed for use of in-band management of the node. It allows for inband management of the 7210 SAS nodes in a ring deployment using a single IPv4 subnet, reducing the number of IP subnets needed.

On the 7210 SAS-Dxp, R-VPLS service can be associated with an IPv4 or IPv6 interface and supports only static routing. It is primarily designed for use of in-band management of the node. It allows for inband management of the 7210 SAS nodes in a ring deployment using a single IPv4 or IPv6 subnet, reducing the number of IP subnets needed.

On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, R-VPLS service can be associated with an IPv4 interface and supports static routing and other routing protocols. It can be used to provide a service to the customer or for inband management of the node.

5.4.1. IES or VPRN IP Interface Binding

A standard IP interface within an existing IES or VPRN service context may be bound to a service name. A VPLS service only supports binding for a single IP interface.

While an IP interface may only be bound to a single VPLS service, the routing context containing the IP interface (IES or VPRN) may have other IP interfaces bound to other VPLS service contexts.

5.4.2. Assigning a Service Name to a VPLS Service

When a service name is applied to any service context, the name and service ID association is registered with the system. A service name cannot be assigned to more than one service ID. Special consideration is given to a service name that is assigned to a VPLS service that has the “configure>service>vpls>allow-ip-int-binding” command is enabled. If a name is applied to the VPLS service while the flag is set, the system scans the existing IES or VPRN services for an IP interface bound to the specified service name. If an IP interface is found, the IP interface is attached to the VPLS service associated with the name. Only one interface can be bound to the specified name.

If the allow-ip-int-binding command is not enabled on the VPLS service, the system does not attempt to resolve the VPLS service name to an IP interface. As soon as the allow-ip-int-binding flag is configured on the VPLS, the corresponding IP interface is adhered and become operational up. There is no need to toggle the shutdown or no shutdown command.

If an IP interface is not currently bound to the service name used by the VPLS service, no action is taken at the time of the service name assignment.

5.4.3. Service Binding Requirements

If the defined service name is created on the system, the system checks to ensure that the service type is VPLS. If the created service type is VPLS, the IP interface is eligible to enter the operationally upstate.

Note:

On the 7210 SAS-K 2F6C4T, 7210 SAS-K 2F1C2T, and 7210 SAS-K 3SFP+ 8C, use the R-VPLS tag in the creation of the VPLS service, otherwise the service cannot be bound to an IP interface. This is not required on the 7210 SAS-D and 7210 SAS-Dxp.

5.4.3.1. Bound Service Name Assignment

If a bound service name is assigned to a service within the system, the system first checks to ensure the service type is VPLS. Secondly the system ensures that the service is not already bound to another IP interface through the service name. If the service type is not VPLS or the service is already bound to another IP interface through the service ID, the service name assignment fails.

A single VPLS instance cannot be bound to two separate IP interfaces.

5.4.3.2. Binding a Service Name to an IP Interface

An IP interface within an IES or VPRN service context may be bound to a service name at any time. Only one interface can be bound to a service. When an IP interface is bound to a service name and the IP interface is administratively up, the system scans for a VPLS service context using the name and takes the following actions:

If the name is not currently in use by a service, the IP interface is placed in an operationally down: Non-existent service name or inappropriate service type state.
If the name is currently in use by a non-VPLS service or the wrong type of VPLS service, the IP interface is placed in the operationally down: Non-existent service name or inappropriate service type state.
If the name is currently in use by a VPLS service without the allow-ip-int-binding flag set, the IP interface is placed in the operationally down: VPLS service allow-ip-int-binding flag not set state. There is no need to toggle the shutdown or no shutdown command.
If the name is currently in use by a valid VPLS service and the allow-ip-int-binding flag is set, the IP interface is eligible to be placed in the operationally up state depending on other operational criteria being met.

5.4.3.3. IP Interface Attached VPLS Service Constraints

When a VPLS service has been bound to an IP interface through its service name, the service name assigned to the service cannot be removed or changed unless the IP interface is first unbound from the VPLS service name.

A VPLS service that is currently attached to an IP interface cannot be deleted from the system unless the IP interface is unbound from the VPLS service name.

The allow-ip-int-binding flag within an IP interface attached VPLS service cannot be reset. The IP interface must first be unbound from the VPLS service name to reset the flag.

5.4.3.4. IP Interface and VPLS Operational State Coordination

When the IP interface is successfully attached to a VPLS service, the operational state of the IP interface is dependent upon the operational state of the VPLS service.

The VPLS service remains down until at least one virtual port (that is, SAP) is operational.

5.4.3.5. IP Interface MTU and Fragmentation on 7210 SAS-D and 7210 SAS-Dxp

In 7210 SAS-D Access-Uplink mode and 7210 SAS-Dxp Access-Uplink mode, VPLS service MTU is not supported. The user must ensure that the port MTU is configured appropriately so that the largest packet traversing through any of the SAPs (virtual ports) of the VPLS service can be forwarded out of any of the SAPs. VPLS services do not support fragmentation and can discard packets larger than the configured port MTU.

When an IP interface is associated with a VPLS service, the IP-MTU is based on either the administrative value configured for the IP interface or an operational value derived from port MTU of all the SAPs configured in the service. The port MTU excluding the Layer 2 Header and tags for all the ports which have SAPs configured in this VPLS service are considered and the minimum value among those are computed (which is called computed MTU). The operational value of the IP interface is set as follows:

If the configured (administrative) value of IP MTU is greater than the computed MTU, then the operational IP MTU is set to the computed MTU.
If the configured (administrative) value of IP MTU is lesser than or equal to the computed MTU, then operational IP MTU is set to the configured (administrative) value of IP MTU.

5.4.3.6. IP Interface MTU and Fragmentation on 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8CC

The VPLS service is affected by two MTU values, port MTUs and the VPLS service MTU. The MTU on each physical port defines the largest Layer 2 packet (including all DLC headers) that may be transmitted out a port. The VPLS has a service level MTU that defines the largest packet supported by the service. The service MTU does not include the local encapsulation overhead for each port (QinQ, Dot1Q, TopQ or SDP service delineation fields and headers) but does include the remainder of the packet. As SAPs are created in the system, the SAPs cannot become operational unless the configured port MTU minus the SAP service delineation overhead is greater than or equal to the configured VPLS service MTU. Therefore, an operational SAP is ensured to support the largest packet traversing the VPLS service. The service delineation overhead on each Layer 2 packet is removed before forwarding into a VPLS service.

VPLS services do not support fragmentation and must discard any Layer 2 packet larger than the service MTU after the service delineation overhead is removed.

If the configured (administrative) IP-MTU is configured for a value greater than the normalized IP-MTU, based on the VPLS service-MTU, then the operational IP-MTU is reset to equal the normalized IP-MTU value (VPLS service MTU – 14 bytes).
If the configured (administrative) IP-MTU is configured for a value less than or equal to the normalized IP-MTU, based on the VPLS service-MTU, then the operational IP-MTU is set to equal the configured (administrative) IP-MTU value.

5.4.4. ARP and VPLS FIB Interactions

Two address-oriented table entries are used when routing into a VPLS service. On the routing side, an ARP entry is used to determine the destination MAC address used by an IP next-hop. In the case where the destination IP address in the routed packet is a host on the local subnet represented by the VPLS instance, the destination IP address is used as the next-hop IP address in the ARP cache lookup. If the destination IP address is in a remote subnet that is reached by another router attached to the VPLS service, the routing lookup returns the local IP address on the VPLS service of the remote router is returned. If the next-hop is not currently in the ARP cache, the system generates an ARP request to determine the destination MAC address associated with the next-hop IP address. IP routing to all destination hosts associated with the next-hop IP address stops until the ARP cache is populated with an entry for the next-hop. The dynamically populated ARP entries age out according to the ARP aging timer.

Note:

Static ARP is only supported on the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C.

The second address table entry that affects VPLS routed packets is the MAC destination lookup in the VPLS service context. The MAC associated with the ARP table entry for the IP next-hop may or may not currently be populated in the VPLS Layer 2 FIB table. While the destination MAC is unknown (not populated in the VPLS FIB), the system is flooded with all packets destined to that MAC (routed or bridged) to all SAPs within the VPLS service context. When the MAC is known (populated in the VPLS FIB), all packets destined to the MAC (routed or bridged) is targeted to the specific SAP where the MAC has been learned. As with ARP entries, static MAC entries may be created in the VPLS FIB. Dynamically learned MAC addresses can age out or be flushed from the VPLS FIB while static MAC entries always remain associated with a specific virtual port. Dynamic MACs may also be relearned on another VPLS SAP than the current SAP in the FIB. In this case, the system automatically moves the MAC FIB entry to the new VPLS SAP.

Note:

On the 7210 SAS-D and 7210 SAS-Dxp, whenever a MAC entry is removed from the VPLS FIB (either explicitly by the user or due to MAC aging or mac-move), ARP entries which match this MAC address is removed from the ARP cache. Though the VPLS FIB entries are not removed, an ARP entry ages out and is removed from the ARP cache. This restriction does not apply to the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.
On the 7210 SAS-D and 7210 SAS-Dxp, if the VPLS FIB limit is reached and we are no longer able to learn new MAC address, ARP will also not be learnt. This restriction does not apply to the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

5.4.5. Specific ARP Cache Behavior

In typical routing behavior, the system uses the IP route table to select the egress interface, an ARP entry is used forward the packet to the appropriate Ethernet MAC. With routed VPLS, the egress IP interface may be represented by multiple egress (VPLS service SAPs).

Table 43 describes how the ARP cache and MAC FIB entry states interact.

Table 43: Routing Behavior in R-VPLS and Interaction ARP Cache and MAC FIB

ARP Cache Entry	MAC FIB Entry	Routing or System behavior
ARP Cache Miss (No Entry)	Known or Unknown	Triggers a request to control plane ARP processing module, to send out an ARP request, out of all the SAPs. (also known as virtual ports) of the VPLS instance.
ARP Cache Hit	Known	Forward to specific VPLS virtual port or SAP.
ARP Cache Hit	Unknown	This behavior cannot typically happen on the 7210 SAS-D and 7210 SAS-Dxp, as when an L2 entry is removed from the FDB, the matching MAC address is also removed from the ARP cache. On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, the packet is sent out of all the SAPs of the VPLS instance.

5.4.5.1. The allow-ip-int-binding VPLS Flag

The allow-ip-int-binding flag on a VPLS service context is used to inform the system that the VPLS service is enabled for routing support. The system uses the setting of the flag as a key to determine what type of ports the VPLS service may span.

The system also uses the flag state to define which VPLS features are configurable on the VPLS service to prevent enabling a feature that is not supported when routing support is enabled.

5.4.6. SAPs Only Supported on Standard Ethernet Ports

The allow-ip-int-binding flag is set (routing support enabled) on a VPLS service. SAPs within the service can be created on standard Ethernet ports.

5.4.6.1. LAG Port Membership Constraints

If a LAG has a non-supported port type as a member, a SAP for the routing-enabled VPLS service cannot be created on the LAG. When one or more routing enabled VPLS SAPs are associated with a LAG, a non-supported Ethernet port type cannot be added to the LAG membership.

5.4.6.2. VPLS Feature Support and Restrictions

When the allow-ip-int-binding flag is set on a VPLS service, the following features cannot be enabled (The flag also cannot be enabled while any of these features are applied to the VPLS service). The following restrictions apply to both network mode and access-uplink mode unless called out separately:

On the 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, spoke or mesh SDP bindings cannot be configured.
On the 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, the VPLS service type cannot be M-VPLS.
On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, the VPLS Service type must be 'r-vpls' and any other VPLS service is not allowed.
MVR from Routed VPLS and to another SAP is not supported.
Default QinQ SAPs is not supported in R-VPLS service.
The “allow-ip-int-binding” command cannot be used in a VPLS service acting as the G.8032 control instance.
IPv4 filters (ingress and egress) can be used with the R-VPLS SAPs. Additionally, IP ingress override filters are supported which affects the behavior of the IP filters attached to the R-VPLS SAPs. Please see the following for more information about use of ingress override filters.
MAC filters (ingress and egress) are not supported for use with R-VPLS SAPs.
VPLS IP interface is not allowed in a R-VPLS service. The converse also holds.
On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, during creation of the VPLS service the keyword 'rvpls' must be used. It lets the software know that this is a VPLS service to which an IP interface will be associated.
On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, the VPLS service can be configured either access SAP or Access-Uplink SAPs.
On the 7210 SAS-D and 7210 SAS-Dxp, VPLS service can use the following 'svc-sap-type' values: any, dot1q-preserve and null-star. Only specific SAP combinations are allowed for a specific svc-sap-type, except that default QinQ SAPs cannot be used in a R-VPLS service. The allowed SAP combinations are similar to that available in a plain VPLS service and is as specified in the preceding table in the services Chapter (with the exception noted before).
On 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, VPLS service can use the following 'svc-sap-type' values: any. Only specific SAP combinations are allowed for a specific svc-sap-type, except that default QinQ SAPs cannot be used in a R-VPLS service. The allowed SAP combinations are similar to that available in a plain VPLS service and is as specified in the preceding table in the services Chapter (with the exception noted before).
G.8032 or mVPLS/STP based protection mechanism can be used with R-VPLS service. A separate G.8032 control instance or a separate mVPLS/STP instance needs to be used and the R-VPLS SAPs needs to be associated with these control instances such that the R-VPLS SAP's forwarding state is driven by the control instance protocols.
IP multicast is not supported in the R-VPLS service.
On the 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, DHCP snooping is not supported for the SAPs configured in the routed VPLS service. Instead, DHCP relay can be enabled on the IES service associated with the routed VPLS service.
In the saved configuration file, for the R-VPLS service, the R-VPLS service instance appears twice, once for service creation and once with all the other configuration parameters. This is required to resolve references to the R-VPLS service and to execute the configuration without any errors.

5.4.7. VPLS SAP Ingress IP Filter Override on 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

When an IP Interface is attached to a VPLS service context, the VPLS SAP provisioned IP filter for ingress routed packets may be optionally overridden to provide special ingress filtering for routed packets. This allows different filtering for routed packets and non-routed packets. The filter override is defined on the IP interface bound to the VPLS service name. A separate override filter may be specified for IPv4 packet types.

If a filter for a specific packet type (IPv4) is not overridden, the SAP specified filter is applied to the packet (if defined).

Table 44 and Table 45 list ACL Lookup behavior with and without Ingress Override filter attached to an IES interface in a R-VPLS service:

Table 44: ACL Lookup Behavior with Ingress Override Filter Attached to an IES Interface in an R-VPLS Service

Type of traffic	SAP Ingress IPv4 Filter	SAP Egress IPv4 Filter	Ingress Override IPv4 Filter
Destination MAC != IES IP interface MAC	Yes	Yes	No
Destination MAC = IES IP interface MAC and Destination IP on same subnet as IES interface	No	No	Yes
Destination Mac = IES IP interface mac and destination IP not on same subnet as IES IP interface and route to destination IP does not exist	No	No	No for 7210 SAS-D and 7210 SAS-Dxp devices Yes for 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C devices
Destination Mac = IES IP interface mac and destination IP not on same subnet as IES IP interface and route to destination IP exists	No	No	Yes
Destination MAC = IES IP interface MAC and IP TTL = 1	No	No	No for 7210 SAS-D and 7210 SAS-Dxp devices Yes for 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C devices
Destination MAC = IES IP interface MAC and IPv4 packet with Options	No	No	No for 7210 SAS-D and 7210 SAS-Dxp devices Yes for 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C devices
Destination MAC = IES IP interface MAC and IPv4 Multicast packet	No	No	No for 7210 SAS-D and 7210 SAS-Dxp devices Yes for 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C devices

Table 45: ACL Lookup Behavior Without Ingress Override Filter Attached to an IES Interface in a R-VPLS Service

Type of traffic	SAP Ingress IPv4 Filter	SAP Egress IPv4 Filter
Destination MAC != IES IP interface MAC	Yes	Yes
Destination MAC = IES IP interface MAC and Destination IP on same subnet as IES IP interface	Yes	No
Destination Mac = IES IP interface mac and destination IP not on same subnet as IES IP interface and route to destination IP does not exist	No for 7210 SAS-D and 7210 SAS-Dxp devices Yes for 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C devices	No
Destination Mac = IES IP interface MAC and destination IP not on same subnet as IES IP interface and route to destination IP exists	Yes	No
Destination MAC = IES IP interface MAC and IP TTL = 1	No for 7210 SAS-D and 7210 SAS-Dxp devices Yes for 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C devices	No
Destination MAC = IES IP interface MAC and IPv4 packet with Options	No for 7210 SAS-D and 7210 SAS-Dxp devices Yes for 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C devices	No
Destination MAC = IES IP interface MAC and IPv4 Multicast packet	No for 7210 SAS-D and 7210 SAS-Dxp devices Yes for 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C devices	No

5.4.7.1. QoS Support for VPLS SAPs and IP interface

SAP ingress classification (IPv4 and MAC criteria) is supported for SAPs configured in the service. SAP ingress policies cannot be associated with IES IP interface.
On the 7210 SAS-D and 7210 SAS-Dxp, egress port based queuing and shaping are available. It is shared among all the SAPs on the port.
On the 7210 SAS-D and 7210 SAS-Dxp, port-based egress marking is supported for both routed packets and bridged packets. The existing access egress QoS policy can be used for Dot1p marking and DSCP marking.
On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, per-SAP egress queuing, shaping and scheduling is available. Per SAP egress Dot1p marking is supported for both routed packet and bridged packets.
On the7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, IES IP interface bound to routed VPLS services, IES IP interface on access SAPs and IES IP interface on Access-Uplink SAPs are designed for use with inband management of the node. Consequently, they share a common set of queues for CPU bound management traffic. All CPU bound traffic is policed to predefined rates before being queued into CPU queues for application processing. The system uses meters per application or a set of applications. It does not allocate meters per IP interface. The possibility of CPU overloading has been reduced by use of these mechanisms. Users must use appropriate security policies either on the node or in the network to ensure that this does not happen.

5.4.7.2. Routing Related Protocols on 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Routed VPLS is supported only in the base routing instance on the 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T. It is supported in both the base routing instance and VPRN services on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C. Only IPv4 addressing support is available for IES interfaces associated with Routed VPLS service. Table 46 lists the support available for routing protocols on IP interfaces bound to a VPLS service for different platforms.

Table 46: Routing Protocols on IPv4 Interfaces Bound to a VPLS Service

Protocol	7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T	7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
Static routing	Supported	Supported
BGP	Not Supported	Not Supported
OSPF	Not Supported	Supported
IS-IS	Not Supported	Supported
BFD	Not Supported	Not Supported
VRRP	Not Supported	Supported
ARP and Proxy-Arp	ARP is supported	Both are supported
DHCP Relay 1	Supported	Supported

Note:

DHCP relay can be configured for the IES interface associated with the Routed VPLS service. DHCP snooping cannot be configured on the VPLS SAPs in the routed VPLS Service.

5.4.7.3. Spanning Tree and Split Horizon

The R-VPLS context supports all spanning tree capabilities that a non R-VPLS service supports. Service-based SHGs are not supported in an R-VPLS service.

5.4.8. R-VPLS Support and Caveats

Routed VPLS supported functionality and restrictions for both access-uplink and network mode is listed as follows. The following is applicable to both the modes, unless called out explicitly.

On the 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T, Routed VPLS can be bound to only IES IP interface. It cannot be bound to VPRN IP interface.
On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, routed VPLS can be bound to IES or VPRN IP interface.
On the 7210 SAS-D, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, only IPv4 addressing and forwarding is supported with Routed VPLS services. IPv6 addressing and forwarding is not supported.
The 7210 SAS-Dxp supports both IPv4 and IPv6 addressing and forwarding with R-VPLS services.
On the 7210 SAS-D and 7210 SAS-Dxp, static ARP cannot be configured with an IES IP interface associated with an R-VPLS, though static MAC can be configured in an R-VPLS service.
On the 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T, only static routes are supported. No dynamic routing protocols are supported.
On the 7210 SAS-D and 7210 SAS-Dxp, whenever a VPLS FIB entry is removed either due to user action, aging or mac-move, the corresponding ARP entry whose MAC address matches that of the MAC in the FIB is removed from the ARP cache.
On the 7210 SAS-D and 7210 SAS-Dxp, multiple SAPs configured on the same port cannot be part of the same R-VPLS Service. A single service can only be configured with a single SAP on a specific port. This restriction does not apply to the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C. On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, multiple SAPs configured on the same port can be part of the same service.
The 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C support service MTU configuration for R-VPLS.
On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, service-based SHGs are not supported in an R-VPLS service.

5.5. Epipe Emulation Using Dot1q VLAN Range SAP in VPLS with G.8032

Note:

This feature is only supported on the 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C operating in access-uplink mode.

On the node where the service originates, in addition to the access dot1q range SAP, the service needs to be configured with access-uplink SAPs on the two G.8032 ring ports. G.8032 mechanism is used to for breaking the loop in the ring and VPLS service protection. The intermediate nodes on the ring needs to use VPLS service with access-uplink SAPs on the ring ports and use the same G.8032 instance for protection, as one is used for service protection on the originating node.

Figure 69 shows how two business offices, served by an operator are connected in a ring network deployment using dot1q range SAPs and a VPLS service with G.8032 for protection.

Figure 69: Epipe Emulation in a ring using VPLS with G.8032

The following are the requirements to provide for an Epipe service connectivity between two business sites:

Transport all the VLANs used by the internal enterprise network of the businesses.
Support high availability for the service between the business sites by protecting against failure of the links or nodes in the ring.

To achieve connectivity between two business sites in access-uplink/L2 mode is to configure SAPs for each of the individual VLANs used in the enterprise network in a VPLS service and use G.8032 for protection. The number of VLANs that was supported is limited by the number of SAPs supported on the platform.

The 7210 SAS platforms, currently support the use of Dot1q range SAPs with only Epipe services in either network/MPLS mode or access-uplink/L2 mode. Dot1q range SAPs allows operators to transport a range of VLANs by providing similar service treatment (service treatment refers to forwarding decision along with encapsulation used, QoS and ACL processing, accounting, etc.) to all the VLANs configured in the range. It simplifies service configuration and allows operators to scale the number of VLANs that can be handled by the node. This took care of the need to support hundreds of VLANs using a single SAP or a small number of SAPs. When MPLS the mode is deployed in ring topology, operators have the option of using different redundancy mechanisms such as FRR, primary/secondary LSPs, Active/Standby PWs, to improve Epipe service availability. No such option is available to protect Epipe service in L2 mode when deployed in a ring topology. Additionally many operators prefer G.8032 based ring protection mechanism, since a single control instance on the ring can potentially protect all the VPLS services on the ring.

This feature allows operators to deploy Epipe services in a ring topology when using L2 mode, by emulating an Epipe service using a VPLS service with G.8032 protection and at the same time provides the benefits of using dot1q range SAPs. The user should ensure that the VPLS service is a point-to-point service. This is achieved by configuring a VPLS service with an access dot1q range SAP used at the customer hand-off on one node in the ring and an access dot1q range SAP in a customer hand-off of a VPLS service on another node (that is, at the other end of the Epipe), such that there are only two endpoints for the service in the network.

5.5.1. Epipe Emulation using Dot1q VLAN Range SAP in VPLS with G.8032 — Configuration Guidelines and Restrictions

The VPLS service with dot1-range SAPs use svc-sap-type of dot1q-range and supports limited functionality in comparison to a normal VPLS service, The following paragraph provide more details of the feature functionality, configuration guidelines and restrictions:

The user can define access dot1q range SAPs, which specifies a group of VLANs which receive similar service treatment, that is, forwarding behavior, SAP ingress QoS treatment and SAP (behavior like that available in Epipe service) and allows it to be configured in a VPLS service.
1. On the node, where the service originates, in addition to the access dot1q range SAP, the service should be configured with Q1.* SAPs on the two G.8032 ring ports. The access or access-uplink Q1.*SAPs can be used, but the access-uplink SAPs are recommended for use.The user cannot configure any other SAPs in the same VPLS service.
2. There is no special configuration required on intermediate nodes, that is, the ring nodes which do not terminate or originate the service. The nodes should be configured for providing transit VPLS service and the VPLS service must use the same G.8032 instance for protection as is used by the service on originating and terminating node.
3. The Epipe service on 7210, currently does not check if the inner tag received on a Q1.* SAP is within the range of the configured VLANs. VPLS service too has the same behavior.
Support for SAP Ingress QoS, Ingress and Egress ACLs, accounting, and other services, for dot1q range SAP configured in a VPLS service matches the support available in Epipe service.
G.8032 mechanism is used for loop detection in ring network and service protection. A separate VPLS service representing the G.8032 control instance must be configured and the state should be associated with this service.
1. Use of dot1q range SAPs to provide service on the interconnection node, in a G.8032 major-ring/sub-ring deployment, when using the virtual channel, is not supported. This restriction is not applicable when the interconnection node in a G.8032 major-ring/sub-ring is configured without a virtual channel.
mVPLS/xSTP support is available for use with Q1.* SAP on the ring ports to break the loop. This is a add-on to the G.8032 support.
Broadcast, Unknown Unicast and Multicast (BUM) traffic is flooded in the service.
Learning is enabled on the service by default, to avoid the need to flood the service traffic out of one of the ring ports, after network MAC addresses are learnt. The user has an option to disable learning per service. Learning enable/disable per SAP is not supported.
MAC limiting is available per service. MAC limiting per SAP is not supported.
CFM OAM is supported. The support for UP MEPs on the dot1q range SAP in the service to be used for fault management and performance management using the CFM/Y.1731 OAM tools is available.
1. On 7210 SAS-D and 7210 SAS-Dxp, only UP MEP is allowed to be configured only on the dot1q VLAN range SAPs. CFM/Y.1731 tools can be used for trouble shooting and performance measurements. User must pick a VLAN value from the range of VLANs configured for the dot1-range SAP using the config>eth-cfm>domain>association>bridge-identifier VLAN command and enable the use of using the CLI command primary-vlan-enable under the MEP CLI context. It is used as the VLAN tag in the packet header for all the CFM/Y.1731 messages sent out in the context of the UP MEP. This is not supported on 7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T.
2. Down MEPs and MIPs are not allowed to be configured.
3. Fault propagation is not supported with UP MEPs for dot1q range SAP in access-uplink mode.
CFM support is not available for SAPs on the ring ports.
IGMP snooping and MVR is not supported.

5. Virtual Private LAN Service

5.1. VPLS Service Overview

5.1.1. VPLS Packet Walk-through for a Local service

Figure 55: VPLS Service Architecture

Figure 56: Access Port Ingress Packet Format and Lookup

Figure 57: Network Port Egress Packet Format and Flooding

5.1.2. VPLS Packet Walk-through for a Distributed service

Figure 58: VPLS Service Architecture

Figure 59: Access Port Ingress Packet Format and Lookup

Figure 60: Network Port Egress Packet Format and Flooding

5.2. VPLS Features

5.2.1. VPLS Enhancements on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T

5.2.2. VPLS Enhancements on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

5.2.3. VPLS over MPLS - supported on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

5.2.4. VPLS over SAPs

5.2.5. VPLS MAC Learning and Packet Forwarding

5.2.5.1. IGMP Snooping on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T

5.2.5.2. IGMP Snooping on 7210 SAS-K 2F6C4Tand 7210 SAS-K 3SFP+ 8C

5.2.5.3. Multicast VLAN Registration (MVR) support

Figure 61: MVR and MVR by Proxy

5.2.5.3.1. Configuration Guidelines for MVR

5.2.6. L2 Forwarding Table Management

5.2.6.1. FIB Size on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T

5.2.6.2. FIB Size on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

5.2.6.3. FIB Size Alarms

5.2.6.4. Local Aging Timers on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T

5.2.6.5. Local and Remote Aging Timers on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

5.2.6.6. Disable MAC Aging

5.2.6.7. Disable MAC Learning

5.2.6.8. Unknown MAC Discard

5.2.6.9. VPLS and Rate Limiting

5.2.6.10. MAC Move

5.2.6.11. Split Horizon SAP Groups

5.2.6.11.1. Split Horizon SAP Groups and Split Horizon Spoke-SDP Groups on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

5.2.7. VPLS and Spanning Tree Protocol

5.2.7.1. Spanning Tree Operating Modes

5.2.7.2. Multiple Spanning Tree

5.2.7.2.1. Redundancy Access to VPLS

Figure 62: Access Resiliency

5.2.7.3. MSTP for QinQ SAPs

5.2.7.3.1. MSTP General Principles

5.2.7.3.2. MSTP in the 7210 SAS Platform

5.2.7.4. Enhancements to the Spanning Tree Protocol in MPLS-based VPLS Service (7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C Only)

5.2.7.4.1. L2PT Termination

5.2.7.4.2. BPDU Translation

5.2.7.4.3. L2PT and BPDU Translation

5.2.8. VPLS Access Redundancy

5.2.8.1. STP-Based Redundant Access to VPLS

Figure 63: Dual Homed 7210 SAS-D Acting as MTU-s in Two-Tier Hierarchy H-VPLS

5.2.9. VPLS Redundancy on 7210 SAS-K 2F6C4Tand 7210 SAS-K 3SFP+ 8C using MPLS uplinks

5.2.9.1. Spoke-SDP Redundancy on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Figure 64: H-VPLS with spoke redundancy

5.2.9.2. Spoke-SDP Based Redundant Access on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

5.2.9.3. Inter-Domain VPLS Resiliency Using Multi-Chassis Endpoints on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Figure 65: H-VPLS Resiliency based on AS Pseudowires

5.2.10. VPLS Access Redundancy When Using MPLS Uplinks on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

5.2.10.1. STP-Based Redundant Access to VPLS Using PWs on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Figure 66: Dual Homed MTUs in Two-Tier Hierarchy H-VPLS

5.2.10.2. Redundant Access to VPLS Without STP and Using MPLS Uplinks on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

5.2.10.3. MAC Flush Message Processing in VPLS Services With MPLS Uplinks on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

5.2.10.4. Dual Homing to a VPLS Service on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Figure 67: Dual Homed CE Connection to VPLS

5.2.11. VPLS Service Considerations

5.2.11.1. SAP Encapsulations

5.2.11.2. VLAN Processing

5.3. BGP-AD VPLS

5.3.1. BGP-AD and Target LDP (T-LDP) Interaction on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Figure 68: BGP-AD and T-LDP Interaction

5.3.2. BGP-AD VPLS - SDP Usage

5.3.3. BGP-AD VPLS - Automatic Creation of SDPs

5.3.4. BGP-AD VPLS - Manually Provisioned SDP

5.3.5. BGP-AD VPLS - Automatic Instantiation of Pseudowires (SDP Bindings)

5.3.6. BGP-AD VPLS - Mixing Statically Configured and Auto-Discovered Pseudowires in a VPLS service

5.3.7. BGP-AD VPLS - Resiliency Schemes

5.4. Routed VPLS

5.4.1. IES or VPRN IP Interface Binding

5.4.2. Assigning a Service Name to a VPLS Service

5.4.3. Service Binding Requirements

5.4.3.1. Bound Service Name Assignment

5.4.3.2. Binding a Service Name to an IP Interface