10.1 Nokia Service Architecture and Building Blocks
Key Takeaways
Customer objects record ownership; forwarding isolation comes from correctly configured services and policies.
A SAP binds local access connectivity and encapsulation to a service.
An SDP selects transport toward a remote endpoint; local SDP and service IDs need not match across PEs.
The VC-ID and applicable pseudowire parameters must agree between endpoints.
MPLS VPN separation does not automatically provide encryption.
Choose the service before configuring transport
A Virtual Private Network (VPN) service supplies a customer's intended connectivity over shared provider infrastructure. In the current course, the important choices include point-to-point Ethernet, multipoint Ethernet, and private IP routing. Shared transport does not mean all customers share one forwarding table.
A VPN service also does not automatically encrypt packets. MPLS service separation provides forwarding isolation under the configured provider design. Cryptographic protection requires an appropriate separate mechanism when needed.
| Customer requirement | Suitable service model |
|---|---|
| Connect two Ethernet attachment points | VPWS/VLL, commonly Epipe |
| Extend a multipoint Ethernet LAN | VPLS |
| Connect routed private customer sites | VPRN |
| Provide routed access using the Base table | IES |
The service choice determines whether the PE bridges frames or routes IP packets. Transport then carries the selected service between provider endpoints.
Customer and service objects
A customer object records administrative ownership and can be referenced by several services. It does not itself provide a VRF or cryptographic boundary. Two services assigned different customer IDs still need correct SAP, label, route, and policy separation.
A service ID identifies a service locally on a router. MD-CLI commonly uses a service name as the configuration key and a separate numeric service-id leaf. Names and local IDs need not match across PEs merely because they belong to the same customer connection.
A pseudowire's Virtual Circuit ID (VC-ID) is a different identifier. The applicable VC parameters must agree between its endpoints. Local service IDs and local SDP IDs can differ. The labels advertised for each direction can also differ.
SAP: customer access
A Service Access Point (SAP) binds customer traffic to a local service using a port or LAG and an encapsulation match.
| Example | Meaning |
|---|---|
1/1/3 | Whole-port/null service delimitation |
1/1/3:100 | A dot1q-delimited SAP for VLAN 100 |
1/1/3:100.20 | A QinQ-delimited match using outer 100 and inner 20 |
lag-1:100 | VLAN 100 on a logical link aggregation group |
Null delimitation means the port identifies the service; it does not universally forbid tagged customer payloads. A SAP's encapsulation interpretation must agree with the physical port configuration. Wildcard and default SAPs have additional matching rules; inspect those rules rather than assuming every unmatched frame belongs to a particular customer.
SAPs can carry ingress and egress QoS and filtering policies. Those policies control treatment at the service boundary. They do not make shared infrastructure resources infinite or guarantee that one customer's congestion cannot affect shared links.
SDP: remote transport abstraction
A Service Distribution Point (SDP) identifies transport toward a remote service-router endpoint. Its local ID, far-end address, delivery type, and selected tunnel mechanism are separate from the customer SAP.
For MPLS delivery using LDP transport, the far-end PE's system address must have usable routed and labeled reachability. A route to the far end alone does not prove that the chosen tunnel is operational. Targeted-LDP service signaling is also different from the LDP transport bindings.
SDPs are directional local objects. A distributed service needs appropriate transport and service state in both directions. Several services can share an SDP toward the same far end, while using distinct bindings.
Build the supporting objects with MD-CLI
This independent example assumes the 7750 hardware is provisioned, the core network already supplies LDP transport to 10.10.10.2, and 1/1/3 is a separate customer access port. It does not reconfigure the core port used in earlier routing examples.
configure private
/configure service customer "LabCustomer" customer-id 10
/configure service customer "LabCustomer" description "Independent course lab"
/configure port 1/1/3 admin-state enable
/configure port 1/1/3 ethernet mode access
/configure port 1/1/3 ethernet encap-type dot1q
/configure service sdp 10 admin-state enable
/configure service sdp 10 delivery-type mpls
/configure service sdp 10 far-end ip-address 10.10.10.2
/configure service sdp 10 ldp true
compare
validate
commit
The customer exists for service references, the access port can delimit VLAN SAPs, and SDP 10 selects LDP-based transport toward the remote PE. This creates supporting objects; no customer service has yet been bound. The next lesson attaches an Epipe and a VPLS to these components.
Spoke and mesh bindings
A spoke-SDP binding supplies a point-to-point pseudowire attachment. Epipe uses this model for a distributed Ethernet connection. VPLS can also use spoke attachments in hierarchical designs.
A mesh-SDP binding participates in the conventional VPLS core mesh. Frames received from one mesh binding are not bridged onto another mesh binding in the same service. This split-horizon rule prevents repeated core-mesh bridging and requires appropriate direct logical connectivity between participating PEs.
“Direct” here means an end-to-end pseudowire relationship, not one physical core hop. The underlying LSP can cross many P routers. Access loops and redundant spoke connections still require their own prevention design.
Verify by dependency
Inspect show service service-using, show service sap-using, and the selected SDP's details. Check the customer-facing port, SAP match, service administrative state, binding state, transport tunnel, and signaled parameters.
Do not infer that an entire VPLS must be Down because one SAP is Down: other attachments may still function. Identify the particular failed forwarding path and its dependency. Likewise, an Up service summary is not proof that every attached customer can reach every destination.
For a configuration exercise, list the required objects before typing: customer, service, access port/SAP, remote transport, and service binding. For a VPRN using automatic tunnel resolution, the service can select transport without a manually bound SDP per remote route, as explained in the Layer 3 lesson.
Primary references
Nokia customer/service MD-CLI reference and MD-CLI SDP/Epipe example, checked October 20, 2026.
On a dot1q customer port, which SAP identifier selects VLAN 100?
1/1/1:0
1/1/1:*
1/1/1:100
1/1/1:100.*
What is the primary operational distinction between a Spoke-SDP and a Mesh-SDP when bound to a multipoint service in Nokia SR OS?
Mesh-SDPs automatically enforce the split-horizon forwarding rule prohibiting forwarding from one Mesh-SDP to another, whereas Spoke-SDPs do not enforce split-horizon restrictions against Mesh-SDPs
Spoke-SDPs only support GRE transport encapsulation, whereas Mesh-SDPs require RSVP-TE signaled MPLS LSPs
Spoke-SDPs require MAC learning to be disabled, whereas Mesh-SDPs require MAC learning to be enabled
Mesh-SDPs can only terminate on physical Ethernet interfaces, whereas Spoke-SDPs terminate on logical loopback interfaces
Which supporting objects are required for the illustrated distributed MPLS Epipe before its SAP and spoke binding can operate?
A GRE-only SDP and no customer
Only an OSPF area number
Only the same local service name on both PEs
A customer/service definition, correct access SAP/port, and usable transport toward the remote PE
Sections you finish are checked off in the contents.