Configuring Sdp Bindings - Nokia 7302 Manual

Virtual Private LAN Service
5.8.7
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
and mesh SDPs (uni-directional tunnels) between ISAMs and MTUs.
214

Configuring SDP Bindings

27 displays an example of a distributed VPLS service configuration of spoke
3HH-11985-AAAA-TQZZA
FD 100/320Gbps NT and FX NT IHub Services Guide
Issue: 13