Nokia VPLS: SAPs and SDPs

Domain 4 tests SAPs and SDPs: local customer attachment, remote service attachment, encapsulation, and binding rules in a Nokia VPLS.

SAP rules

• A SAP is the local service access point: port plus encapsulation, such as 1/1/1:100 for VLAN 100, a null SAP, or a QinQ SAP.
• The encapsulation must match the customer's tagging. A dot1q SAP expects the specified VLAN; a null SAP expects untagged or port-based traffic.
• A SAP is unique for its port and encapsulation. It carries ingress/egress filters, QoS, and accounting. Check admin and operational state.
• A SAP belongs to exactly one service instance.

SDP rules

• An SDP is a service distribution point that identifies a remote PE and transport tunnel. It is not itself a service; multiple VPLS instances can use the same SDP with different VC IDs.
• The SDP binding creates the pseudowire. The far-end address must be reachable, and the transport must be up.
• The SDP ID and VC ID are different: the former identifies the tunnel endpoint, the latter identifies the pseudowire/service binding.

Worked example

CE-A sends VLAN 100 tagged frames. On PE1, configure SAP 1/1/1:100 in VPLS 100. If the SAP is 1/1/1:200, the CE's VLAN 100 frames do not match the SAP encapsulation and are dropped or not admitted. On the remote side, VPLS 100 uses spoke-sdp 2:100; SDP 2 must point to PE2 and be reachable over LDP. The VC ID 100 identifies the binding. If SDP 2 is also used by VPLS 200, it needs a different VC ID for that service.

Traps

Confusing SDP ID with VC ID; creating duplicate SAP encapsulations on one port; pointing an SDP at the wrong far-end; and assuming an SDP is dedicated to one VPLS when it can be shared.