Pseudowire signaling details

The pseudowire is set up using the following NLRI fields:

This BGP update is telling the other PEs that accept the RT: reach me (VE-ID = x), use a pseudowire label of LB + VE-ID – VBO using the BGP NLRI for which VBO =< local VE-ID < VBO + VBS.

Following is an example of how this algorithm works, assuming PE1 has VE-ID 7 configured:

  1. PE1 allocates a label block of eight consecutive labels available, starting with LB = 1000.

  2. PE1 starts sending a BGP update with pseudowire information of VBO = 1, VBS = 8, LB = 1000 in the NLRI.

  3. This pseudowire information is accepted by all participating PEs with VE-IDs from 1 to 8.

  4. Each of the receiving PEs uses the pseudowire label = LB + VE-ID - VBO to send traffic back to the originator PE. For example, VE-ID 2 uses pseudowire label 1001.

Assuming that VE-ID = 10 is configured in another PE4, the following procedure applies:

  1. PE4 sends a BGP update with the new VE-ID in the network that is received by all the other participating PEs, including PE1.

  2. Upon reception, PE1 generates another label block of 8 labels for the VBO = 9. For example, the initial PE creates new pseudowire signaling information of VBO = 9, VBS = 8, LB = 3000, and insert it in a new NLRI and BGP update that is sent in the network.

  3. This new NLRI is used by the VE-IDs from 9 to 16 to establish pseudowires back to the originator PE1. For example, PE4 with VE-ID 10 uses pseudowire label 3001 to send VPLS traffic back to PE1.

  4. The PEs owning the set of VE-IDs from 1 to 8 ignore this NLRI.

In addition to the pseudowire label information, the "Layer2 Info Extended Community" attribute must be included in the BGP update for BGP VPLS to signal the attributes of all the pseudowires that converge toward the originator VPLS PE.

The format is as follows.

Figure: Layer-2 information extended community

The meaning of the fields are as follows:

Figure: Control flag bit vector format shows the detailed format for the control flags bit vector.

Figure: Control flag bit vector format

The following bits in the control flags are defined as follows:

S
sequenced delivery of frames that must or must not be used when sending VPLS packets to this PE, depending on whether S is 1 or 0, respectively
C
a Control word that must or must not be present when sending VPLS packets to this PE, depending on whether C is 1 or 0, respectively. By default, Nokia implementation uses value 0
MBZ
Must Be Zero bits, set to zero when sending and ignored when receiving
D
indicates the status of the whole VPLS instance (VSI); D = 0 if Admin and Operational status are up, D = 1 otherwise

Following are the events that set the D-bit to 1 to indicate VSI down status in the BGP update message sent out from a PE:

The following events do not set the D-bit to 1:

The adv-service-mtu command can be used to override the MTU value used in BGP signaling to the far-end of the pseudowire. This value is also used to validate the value signaled by the far-end PE unless ignore-l2vpn-mtu-mismatch is also configured.

If the ignore-l2vpn-mtu-mismatch command is configured, the router does not check the value of the "Layer 2 MTU" in the "Layer2 Info Extended Community" received in a BGP update message against the local service MTU, or against the MTU value signaled by this router. The router brings up the BGP-VPLS service regardless of any MTU mismatch.