Virtual Private LAN Service
214
FD 100/320Gbps NT and FX NT IHub Services Guide
3HH-11985-AAAA-TQZZA Issue: 13
 
5.8.7 Configuring SDP Bindings
A spoke SDP is treated like the equivalent of a traditional bridge port where flooded 
traffic received on the spoke SDP is replicated on all other "ports" (other spoke and 
mesh SDPs or SAPs) and not transmitted on the port it was received (unless a split 
horizon group was defined on the spoke SDP).
A spoke SDP connects a VPLS service between two sites and, in its simplest form, 
could be a single tunnel LSP. A set of ingress and egress VC labels are exchanged 
for each VPLS service instance to be transported over this LSP. The PE routers at 
each end treat this as a virtual spoke connection for the VPLS service in the same 
way as the PE-MTU connections. This architecture minimizes the signaling overhead 
and avoids a full mesh of VCs and LSPs between the two metro networks.
A mesh SDP bound to a service is logically treated like a single bridge "port" for 
flooded traffic where flooded traffic received on any mesh SDP on the service is 
replicated to other "ports" (spoke SDPs and SAPs) and not transmitted on any mesh 
SDPs.
A VC-ID can be specified with the SDP-ID. The VC-ID is used instead of a label to 
identify a virtual circuit. The VC-ID is significant between peer SRs on the same 
hierarchical level. The value of a VC-ID is conceptually independent from the value 
of the label or any other datalink specific information of the VC.
Figure 27 displays an example of a distributed VPLS service configuration of spoke 
and mesh SDPs (uni-directional tunnels) between ISAMs and MTUs.