As new Ethernet services are activated, UNI SAPs need to be configured and associated with the VLAN IDs (VPLS instances) auto-created using the procedures described in the previous sections. These UNI SAPs may be located in the same VLAN domain or over a PBB backbone. When UNI SAPs are located in different VLAN domains, an intermediate service translation point must be used at the PBB BEB, which maps the local VLAN ID through an I-VPLS SAP to a PBB ISID. This BEB SAP is playing the role of an end-station from an MVRP perspective for the local VLAN domain.
This section discusses how MVRP is used to activate service connectivity between a BEB SAP and a UNI SAP located on one of the switches in the local domain. A similar procedure is used in the case of UNI SAPs configured on two switches located in the same access domain. No end-station configuration is required on the PBB BEB if all the UNI SAPs in a service are located in the same VLAN domain.
The service connectivity instantiation through MVRP is shown in Figure 1.
In this example, the UNI and service translation SAPs are configured in the data VPLS represented by the gray circles. This instance and associated trunk SAPs were instantiated using the procedures described in the previous sections. The following configuration steps are involved:
on the BEB, an I-VPLS SAP must be configured toward the local switching domain – see yellow triangle facing downward
on the UNI facing the customer, a ‟customer” SAP is configured on the lower left switch – see yellow triangle facing upward
As soon as the first UNI SAP becomes active in the data VPLS on the ES, the associated VLAN value is advertised by MVRP throughout the related M-VPLS context. As soon as the second UNI SAP becomes available on a different switch, or in our example on the PBB BEB, the MVRP proceeds to advertise the associated VLAN value throughout the same M-VPLS. The trunks that experience MVRP declaration and registration in both directions become active, instantiating service connectivity as represented by the big and small yellow circles shown in the figure.
A hold-time parameter (config>service>vpls>mrp>mvrp>hold-time) is provided in the M-VPLS configuration to control when the end-station or last UNI SAP is considered active from an MVRP perspective. The hold-time controls the amount of MVRP advertisements generated on fast transitions of the end-station or UNI SAPs.
If the no hold-time setting is used, the following rules apply:
MVRP stops declaring the VLAN only when the last provisioned UNI SAP associated locally with the service is deleted.
MVRP starts declaring the VLAN as soon as the first provisioned SAP is created in the associated VPLS instance, regardless of the operational state of the SAP.
If a non-zero ‟hold-time” setting is used, the following rules apply:
When a SAP in down state is added, MVRP does not declare the associated VLAN attribute. The attribute is declared immediately when the SAP comes up.
When the SAP goes down, the MVRP waits until ‟hold-time” expiry before withdrawing the declaration.
For QinQ end-station SAPs, only no hold-time setting is allowed.
Only the following PBB Epipe and I-VPLS SAP types are eligible to activate MVRP declarations:
dot1q: for example, 1/1/2:100
qinq or qinq default: for example, 1/1/1:100.1 and respectively 1/1/1:100.*, respectively; the outer VLAN 100 is used as MVRP attribute as long as it belongs to the MVRP range configured for the port
null port and dot1q default cannot be used
Examples of steps required to activate service connectivity for VLAN 100 using MVRP follows.
In the data VPLS instance (VLAN 100) controlled by MVRP, on the QinQ switch, example:
config>service>vpls 100
— sap 9/1/1:10 //UNI sap using CVID 10 as service delimiter
— no shutdown
In I-VPLS on PBB BEB, example:
config>service>vpls 1000 i-vpls
— sap 8/1/2:100 //sap (using MVRP VLAN 100 on endstation port in M-VPLS
— no shutdown