Introduction to Triple Play

Nokia’s Triple Play Service Delivery Architecture

This section discusses Nokia’s Triple Play Service Deliver Architecture (TPSDA) implementation.

Introduction to Triple Play

For more than a decade, telephony service providers have considered offering video services to residential customers. However, in the past it was not economically nor technically feasible to launch the implementation on a large scale.

Several technical trends and evolutions have propelled video delivery to the foreground, including:

  • technical improvements in areas like real-time MPEG encoding and compression

  • widespread deployment of High Speed Internet (HSI) over broadband access (ADSL and cable modems)

  • decreased cost of high-bandwidth infrastructure (typically Ethernet-based) as well as storing, converting, and delivering video content

  • increased competition between telephony and cable operators (this is partly because of changes in regulations)

Traditional cable operators began offering television services and later added Internet access and telephony to their offerings. Conversely, traditional telephony operators such as RBOCs, PTTs, have also added Internet access, and many are now in the process of also adding video delivery.

This bundling of video, voice, and data services to residential subscribers is now commonly known as Triple Play services. The video component always includes linear programming (broadcast television), but often also has a non-linear Video on Demand (VoD) component.

Blueprint for optimizing Triple Play Service infrastructures

Nokia's TPSDA allows network operators to progressively integrate their HSI, voice, and video services within a unified and homogeneous Ethernet-based aggregation network environment. The key benefits of the proposed service infrastructure include cost optimization, reduced risk, and accelerated time to market for new services.

At a high level, TPSDA implements:

  • Ethernet-based service architecture

    This architecture solves bandwidth bottlenecks and exponential capital expenditure and operating expenses issues in the second mile by leveraging the efficiency of this technology.

  • multiple distributed service edges

    This feature allows service providers to achieve faster times to market for new services while retaining the existing Broadband Remote Access Server (BRAS) and Point-to-Point Protocol over Ethernet (PPPoE) mode of operation for wholesale and retail HSI.

  • distributed multicasting functions in access and aggregation networks

    This feature enables service providers to optimize bandwidth and content delivery mechanisms, based on densities and penetration rates. It is also essential to subscriber and service scaling, and optimizes the bandwidth required in the aggregation network.

  • carrier video and Voice over Internet Protocol (VoIP) services using Dynamic Host Configuration Protocol (DHCP)

    This feature enables service providers to introduce plug-and-play services delivered through set-top boxes and VoIP devices, which are designed for use with the DHCP.

  • flexible deployment models

    The architecture allows data, video, and VoIP services to be rapidly rolled out without any lock-in to specific operational models. It allows service providers to maximize flexibility and minimize financial and technological risks by allowing all modes of operation, including:

    • copper (DSL/DSLAM) and fiber-based (FTTx) deployments in the first mile

    • single or multiple last mile circuits

    • bridged or routed home gateways

    • single or multiple IP address deployment models

Architectural foundations

With the SR OS, the architectural foundations of Nokia’s TPSDA is reinforced while its applicability is expanded to encompass many new deployment models and support Any Mode of Operation (AMO). Through these enhancements, TPSDA becomes more universally deployable and flexible in addressing the specifics of any provider’s network rollout.

Nokia has defined new terminologies that have been adopted industry-wide, including:

  • Broadband Service Access Node (BSAN)

  • Broadband Service Aggregator (BSA)

  • Broadband Service Router (BSR)

Triple Play Service Delivery Architecture depicts TPSDA’s centralized, integrated element, service, and subscriber management architecture.

Figure 1. Triple Play Service Delivery Architecture

Optimizing Triple Play service infrastructures

More than a branding exercise, new terminologies signal a significant shift from ‟best effort” and traditional DSLAMs, Ethernet switches and BRASs, in the sense that they capture a shift in required characteristics and capabilities for a new generation of service rollouts, including:

  • high-availability for non-stop service delivery (non-stop unicast and multicast routing, non-stop services, and so on)

  • multi-dimensional scale (such as the ability to scale performance, bandwidth, services, and subscribers concurrently)

  • Ethernet optimization (leading density, capacity, scaling, performance)

  • optimal system characteristics (optimal delay, jitter, and loss characteristics, and so on)

  • rich service capabilities with uncompromised performance

Nokia’s Triple Play Service Delivery Architecture (TPSDA) advocates the optimal distribution of service intelligence over the BSAN, BSA and BSR, instead of concentrating on fully centralized or decentralized BRAS models which artificially define arbitrary policy enforcement points in the network. With the SR OS, the optimized enforcement of subscriber policies across nodes or over a single node (as dictated by evolving traffic patterns), allows a more flexible, optimized, and cost-effective deployment of services in a network, guaranteeing high quality and reliable delivery of all services to the user. Nokia’s TPSDA entities are described in Nokia’s TPSDA.

Table 1. Nokia’s TPSDA
Entity Description

Subscriber Management

Centralized and fully integrated with element and services management across the infrastructure end-to-end solution (through the Nokia 5750 SSC).

Policy Enforcement

Optimally distributed, based on actual traffic patterns. Maximized flexibility, minimized risk of architectural lock-in. Optimized cost structure.

Support for ‟Any Mode of Operation”

With TPSDA, network economics, subscriber density, network topologies and subscriber viewership patterns define the optimal policy enforcement point for each policy type (security, QoS, multicasting, anti-spoofing, filtering, and so on). The SR OS capabilities allow service providers to support any mode of operation, including any combination of access methods, home gateway type, and policy enforcement point (BSAN, BSA or BSR or a combination of the three).

All of the SR OS and Nokia’s 5750 SSC’s subscriber policy enforcement and management capabilities described in this section build upon Nokia’s TPSDA extensive capabilities and provide key capabilities in the following areas:

  • operationalization of Triple Play Services (AAA, subscriber policy enforcement, and so on)

  • service assurance and control

  • non-stop video service delivery

Distributed service edges

The TPSDA architecture (Nokia’s Triple Play Service Delivery Architecture), is based on two major network elements optimized for their respective roles, the Broadband Service Aggregator (BSA) and the Broadband Service Router (BSR). An important characteristic of BSAs and BSRs is that they effectively form a distributed virtual node with the BSAs performing subscriber-specific functions where the various functions scale, and the BSRs providing the routing intelligence where it is most cost-effective.

The Nokia 7450 ESS and 7750 SR OS, respectively, provide the BSA and BSR functionalities in TPSDA. Both are managed as a single virtual node using Nokia's NSP NFM-P, which provides a unified interface for streamlined service and policy activation across the distributed elements of the TPSDA architecture, including VPLS, QoS, multicasting, security, filtering, and accounting.

Figure 2. Nokia’s Triple Play Service Delivery Architecture

Digital subscriber line access multiplexers (DSLAMs) or other access nodes are connected to Ethernet access ports on the BSA. Typically a single VLAN per subscriber is configured between the access node and the BSA. A VLAN per subscriber provides a persistent context against which per-subscriber policies (QoS, filtering, accounting) can be applied in the BSA.

Scaling of traffic and services is achieved by dividing the Layer 2 and Layer 3 functions between the BSA and BSR and by distributing key service delivery functions. BSAs are more distributed than BSRs, cost-effectively scaling per-subscriber policy enforcement.

The BSA is a high-capacity Ethernet-centric aggregation device that supports hundreds of gigabit Ethernet ports, tens of thousands of filter policies, and tens of thousands of queues. The BSA incorporates wire speed security, per-subscriber service queuing, scheduling, accounting, and filtering.

BSAs aggregate traffic for all services toward the BSR. The BSR terminates the Layer 2 access and routes over IP/MPLS (Multi-Protocol Label Switching) with support for a full set of MPLS and IP routing protocols, including multicast routing. The BSR supports hundreds of ports and sophisticated QoS for per-service and per-content or source differentiation.

The connectivity between BSAs and BSRs is a Layer 2 forwarding model shown in Nokia’s Triple Play Service Delivery Architecture above as a secure VPLS infrastructure. This refers to the fact that the BSA-BSR interconnections form a multipoint Ethernet network with security extensions to prevent unauthorized communication, denial of service, and theft of service. One of the advantages of using VPLS for this application is that VPLS instances can be automatically established over both ‛hub and spoke’ and ring topologies providing sub-50 ms resilience. Regardless of the fiber plant layout, VPLS enables a full mesh to be created between BSA and BSR nodes, ensuring efficient traffic distribution and resilience to node or fiber failure.

Other unique features of the BSA and BSR that contribute to this secure VPLS infrastructure are:

  • Using Residential Split Horizon Groups (RSHG), direct user-user bridging is automatically prohibited, without the need for address-specific ACLs.

  • RSHG combined with the ARP reply agent perform ARP and broadcast suppression to ensure that addressing information is restricted.

  • Protection against theft of service and denial of service is provided by MAC or IP filters automatically populated using DHCP snooping, and by MAC pinning.

  • Using the RADIUS interface, is possible to perform RADIUS authentication of users before allowing a DHCP discover to progress into the network.

Service differentiation, QoS enablement

Nokia's TPSDA approach provides a model based on call admission for video and VoIP, with the need to guarantee delay/jitter/loss characteristics when the service connection is accepted. The architecture also meets the different QoS needs of HSI, namely per-subscriber bandwidth controls, including shaping and policing functions that have little or no value for video and VoIP services. In conjunction with the architecture's support for content differentiation, this enables differentiated service pricing within HSI.

The distribution of QoS policy and enforcement across BSA and BSR allows the service provider to implement meaningful per-subscriber service level controls. Sophisticated and granular QoS in the BSA allows the service provider to deliver truly differentiated IP services based on the subscriber as well as on the content.

In the BSR to BSA downstream direction (Downstream QoS enablement), IP services rely on IP layer classification of traffic from the network to queue traffic appropriately toward the BSA. Under extreme loading (only expected to occur under network fault conditions), lower priority data services or HSI traffic are compromised to protect video and voice traffic. Classification of HSI traffic based on source network address or IEEE 802.1p marking allows the QoS information to be propagated to upstream or downstream nodes by network elements. See Downstream QoS enablement for the descriptions.

The BSR performs service distribution routing based on guarantees required to deliver the service and associated content instead of individual subscribers. The BSR only needs to classify content based on the required forwarding class for a specific BSA to ensure that each service's traffic receives the appropriate treatment toward the BSA.

Figure 3. Downstream QoS enablement
Table 2. Downstream QoS enablement
Key Description


Per-subscriber queuing and PIR/CIR policing/shaping for HSI. HSI service classified on source IP range.

Per-service prioritization for VoIP and video. VoIP is prioritized over video. Destination IP or DSCP classification. 802.1 marking for prioritization in the access and home.


VoIP and video queued and prioritized on per-VLAN QoS policy basis.

HSI content differentiation based on DSCP. Each queue may have individual CIR/PIR and shaping.

Optical overall subscriber rate limiting on VLAN (H-QoS).


For HSI, content differentiation queuing for gold, silver, or bronze based on DSCP classification. Optional overall subscriber rate limiting on VLAN.


Preferred content marked (DSCP) of trusted ingress points of IP network.

In the upstream direction (BSA to BSR, as shown in Upstream QoS enablement), traffic levels are substantially lower. Class-based queuing is used on the BSA network interface to ensure that video control traffic is propagated with a minimal and consistent delay, and that preferred data or HSI services receive better treatment for upstream/peering service traffic than the best effort Internet class of service.

Note: The IP edge is no longer burdened with enforcing per-subscriber policies for hundreds of thousands of users. This function is now distributed to the BSAs, and the per-subscriber policies can be implemented on the interfaces directly facing the access nodes.
Figure 4. Upstream QoS enablement

Upstream QoS enablement keys are described in Upstream QoS enablement.

Table 3. Upstream QoS enablement
Key Description


HSI: Per-subscriber queuing with PIR or CIR policy or shaping.


VoIP and Video: Shared queuing for prioritization of real-time traffic over HSI. Upstream video is negligible.


Per-subscriber QoS/Content classification for content differentiation.


Video and VoIP: Policy defines priority aggregate CIR and PIR.

HSI: QoS policy defines priority and aggregate CIR and PIR. Content differentiation based on ingress classification. DSCP is marked.

The BSA is capable of scheduling and queuing functions on a per-service, per-subscriber basis, in addition to performing wire-speed packet classification and filtering based on both Layer 2 and Layer 3 fields.

Each subscriber interface provides at least three dedicated queues. TPSDA makes it possible to configure these queues such that the forwarding classes defined for all services can all be mapped to one service VLAN upstream. In the BSA, assuming hundreds of subscribers per gigabit Ethernet interface, this translates to a thousand or more queues per port.

In addition to per-service rate limiting for HSI services, each subscriber's service traffic can be rate limited as an aggregate using a bundled service policy. This allows different subscribers to receive different service levels independently and simultaneously.

Distributed multicasting today's predominant video service is broadcast TV, and remains significant. As video services are introduced, it is sensible to optimize investments by matching resources to the service model relevant at the time. Consequently, the objective of the service infrastructure should be to incorporate sufficient flexibility to optimize for broadcast TV in the short term, yet scale to support a full unicast (VoD) model as video service offerings evolve.

Optimizing for broadcast TV means implementing multicast packet replication throughout the network. Multicast improves the efficiency of the network by reducing the bandwidth and fiber needed to deliver broadcast channels to the subscriber. A multicasting node can receive a single copy of a broadcast channel and replicate it to any downstream nodes that require it, substantially reducing the required network resources. This efficiency becomes increasingly important closer to the subscriber. Multicast should be performed at each or either of the access, aggregation, and video edge nodes.

Multicasting as close as possible to the subscriber has other benefits because it enables a large number of users to view the content concurrently. The challenges of video services are often encountered in the boundary cases, such as live sports events and breaking news, for which virtually all the subscribers may be watching just a few channels. These exceptional cases generally involve live content, which is true broadcast content. Multicasting throughout the network makes it possible to deliver content under these circumstances while simplifying the engineering of the network.

Efficient multicasting requires the distribution of functions throughout the access and the aggregation network to avoid overloading the network capacity with unnecessary traffic. TPSDA realizes efficient multicasting by implementing IGMP snooping in the access nodes, IGMP snooping in the BSA and multicast routing in the BSR (Distributed multicasting in Triple Play).

Figure 5. Distributed multicasting in Triple Play

Virtual MAC subnetting for VPLS

This feature allows, at the VPLS instance level, MAC subnetting, such as learning and switching based on a configurable number of bits from the source MAC address and from the destination MAC, respectively. This considerably reduces the VPLS FDB size.

MAC scalability involving MAC learning and switching based on the first x bits of a virtual MAC address is suitable in an environment where some MAC addresses can be aggregated based on a common first x bits, for example 28 out of 48. This can be deployed in a TPSDA environment where the VPLS is used for pure aggregation (there is no subscriber management) between the DSLAM and BRAS devices. The DSLAMs must be able to map customer MAC addresses to a pool of internal virtual MAC addresses where the first bits (28, for example) identify the DSLAM with the next 20 bits identifying the DSLAM slot, port number, and customer MAC station on that port. The VPLS instances in the PE distinguishes only between different DSLAMs connected to it. They need to learn and switch based only on the first 28 bits of the MAC address allowing scaling of the FDB size in the PE.

Figure 6. Subnetting topology

Subnetting topology displays a Layer 2 PE network (such as the ESS-Series) aggregating traffic from DSLAMs (Nokia) to BRAS devices. The VPLS service is running in the PEs directly connected to the DSLAMs (VPLS PE1) while the PEs connected to the BRAS devices are running a point-to-point Layer 2 service (Epipe).

Nokia DSLAMs have the capability to map every customer MAC to a service provider MAC using the virtual MAC addressing scheme depicted in VMAC subnetting topology.

Figure 7. VMAC subnetting topology

As the packet ingresses the DSLAM from the residential customer, the source MAC address (a customer MAC for one of its terminals or routers) is replaced by the DSLAM with a virtual MAC using the format depicted in VMAC subnetting topology.

  • The U/L bit is the seventh bit of the first byte and is used to determine whether the address is universally or locally administered. The U/L bit is set to 1 to indicate the address is locally administered.

  • The following bits are used to build the VMAC address: DSLAM ID bits 39 to 21, slot ID bits 20 to 15, port ID bits 14 to 6, and the customer station ID bits 5 to 0.

Based on this scheme, it is apparent that the VMACs from one DSLAM have bits 47 to 21 in common.

The VPLS instance in PE1 only learns the first part of the MAC (bits 47 to 21) and, as the packets arrive from the BRAS device, switches based only on these bits in the destination MAC address to differentiate between the connected DSLAMs. When the packet arrives at the DSLAM, the entire destination MAC is checked to determine the slot, port and which specific customer station the packet is destined. As the packet is sent to the customer, the DSLAM replaces the destination MAC address with the actual customer MAC corresponding to the customer station. The following are VPLS features not supported when the VMAC subnetting feature is enabled:

  • Blocked features (CLI consistency checked provided)

  • Residential Split Horizon Groups

  • BGP AD

  • TPSDA (subscriber management) features

  • PBB

  • VPLS OAM (MAC populate, MAC ping, MAC trace, CPE Ping)


Service types

The 7450 ESS and 7750 SR OS offers the following types of subscriber services which are described in more detail in the referenced chapters:

  • Virtual Leased Line (VLL) services

    • Ethernet pipe (Epipe)

      A Layer 2 point-to-point VLL service for Ethernet frames.

    • IP pipe (Ipipe)

      Provides IP connectivity between a host attached to a point-to-point access circuit (PPP) with routed IPv4 encapsulation and a host attached to an Ethernet interface.

  • Virtual Private LAN Service (VPLS)

    A Layer 2 multipoint-to-multipoint VPN. VPLS includes Hierarchical VPLS (H-VPLS) which is an enhancement of VPLS which extends Martini-style signaled or static virtual circuit labeling outside the fully meshed VPLS core.

  • Internet Enhanced Service (IES)

    A direct Internet access service where the customer is assigned an IP interface for Internet connectivity.

  • Virtual Private Routed Network (VPRN)

    Layer 3 IP multipoint-to-multipoint VPN service as defined in RFC 2547bis. VPRN is supported on the 7750 SR only.

Service policies

Common to all 7450 ESS and 7750 SR connectivity services are policies that are assigned to the service. Policies are defined at a global level and then applied to a service on the router. Policies are used to define service enhancements. The types of policies that are common to all 7450 ESS and 7750 SR connectivity services are:

  • SAP Quality of Service (QoS) policies which allow for different classes of traffic within a service at SAP ingress and SAP egress.

    QoS ingress and egress policies determine the QoS characteristics for a SAP. A QoS policy applied to a SAP specifies the number of queues, queue characteristics (such as forwarding class, committed, and peak information rates, and so on) and the mapping of traffic to a forwarding class. A QoS policy must be created before it can be applied to a SAP. A single ingress and a single egress QoS policy can be associated with a SAP.

  • Filter policies allow selective blocking of traffic matching criteria from ingressing or egressing a SAP.

    Filter policies, also referred to as access control lists (ACLs), control the traffic allowed in or out of a SAP based on MAC or IP match criteria. Associating a filter policy on a SAP is optional. Filter policies are identified by a unique filter policy ID. A filter policy must be created before it can be applied to a SAP. A single ingress and single egress filter policy can be associated with a SAP.

  • Scheduler policies define the hierarchy and operating parameters for virtual schedulers. Schedulers are divided into groups based on the tier each scheduler is created under. A tier is used to give structure to the schedulers within a policy and define rules for parent scheduler associations.

  • Accounting policies define how to count the traffic usage for a service for billing purposes.

    The 7450 ESS and 7750 SR OS provide a comprehensive set of service-related counters. Accounting data can be collected on a per-service, per-forwarding class basis, which enables network operators to accurately measure network usage and bill each customer for each individual service using any of a number of different billing models.

Nokia service model


In the 7450 ESS and 7750 SR service model, the service edge routers are deployed at the provider edge. Services are provisioned on the routers and transported across an IP as well as an IP and MPLS provider core network in encapsulation tunnels created using Generic Router Encapsulation (GRE) or MPLS Label Switched Paths (LSPs).

The service model uses logical service entities to construct a service. The logical service entities are designed to provide a uniform, service-centric configuration, management, and billing model for service provisioning. Some benefits of this service-centric design include:

  • Many services can be bound to a single customer.

  • Many services can be bound to a single tunnel.

  • Tunnel configurations are independent of the services they carry.

  • Changes are made to a single logical entity instead of multiple ports on multiple devices. It is easier to change one tunnel instead of several services.

  • The operational integrity of a logical entity (such as a service tunnel and service end points) can be verified instead of dozens of individual services improving management scaling and performance.

  • A failure in the network core can be correlated to specific subscribers and services.

  • QoS policies, filter policies, and accounting policies are applied to each service instead of correlating parameters and statistics from ports to customers to services.

Service provisioning uses logical entities to provision a service where additional properties can be configured for bandwidth provisioning, QoS, security filtering, accounting or billing to the appropriate entity.


The terms customers and subscribers are used synonymously. The most basic required entity is the customer ID value which is assigned when the customer account is created. To provision a service, a customer ID must be associated with the service at the time of service creation.

Service Access Points

Each subscriber service type is configured with at least one service access point (SAP). A SAP identifies the customer interface point for a service on a Nokia 7450 ESS or 7750 SR OS (Service Access Point (SAP)). The SAP configuration requires that slot, MDA, and port and channel (7750 SR) information be specified. The slot, MDA, and port and channel parameters must be configured before provisioning a service (see the Cards, MDAs, and Ports section of the 7450 ESS, 7750 SR, 7950 XRS, and VSR Interface Configuration Guide).

A SAP is a local entity to the 7450 ESS and 7750 SR and is uniquely identified by:

  • the physical Ethernet port or SONET/SDH port or TDM channel (7750 SR)

  • the encapsulation type

  • the encapsulation identifier (ID)

Depending on the encapsulation, a physical port or channel can have more than one SAP associated with it. SAPs can only be created on ports or channels designated as ‟access” in the physical port configuration. SAPs cannot be created on ports designated as core-facing ‟network” ports as these ports have a different set of features enabled in software.

Figure 9. Service Access Point (SAP)

SAP encapsulation types and identifiers

The encapsulation type is an access property of a service Ethernet port or SONET/SDH or TDM channel (the TDM channel applies to the 7750 SR). The appropriate encapsulation type for the port or channel depends on the requirements to support multiple services on a single port and channel on the associated SAP and the capabilities of the downstream equipment connected to the port or channel. For example, a port can be tagged with IEEE 802.1Q (referred to as dot1q) encapsulation in which each individual tag can be identified with a service. A SAP is created on a specific port or channel by identifying the service with a specific encapsulation ID.

Ethernet encapsulations

The following lists encapsulation service options on Ethernet ports:

  • Null

    Supports a single service on the port. For example, where a single customer with a single service customer edge (CE) device is attached to the port. The encapsulation ID is always 0 (zero).

  • Dot1q

    Supports multiple services for one customer or services for multiple customers (Multiple SAPs on a single port or channel). For example, the port is connected to a multi-tenant unit (MTU) device with multiple downstream customers. The encapsulation ID used to distinguish an individual service is the VLAN ID in the IEEE 802.1Q header.

  • Q-in-Q

    The q-in-q encapsulation type adds an IEEE 802.1Q tag to the 802.1Q tagged packets entering the network to expand the VLAN space by tagging tagged packets, producing a double tagged frame.

    Note: The SAP can be defined with a wildcard for the inner label. (for example, ‟100:*”). In this situation all packets with an outer label of 100 are treated as belonging to the SAP. If, on the same physical link there is also a SAP defined with a q-in-q encap of 100:1, then traffic with the 100:1 encapsulation goes to that SAP and all other traffic with 100 as the first label goes to the SAP with the 100:* definition.

In the dot1q and q-in-q options, traffic encapsulated with tags for which there is no definition are discarded.

Figure 10. Multiple SAPs on a single port or channel

SAP considerations

When configuring a SAP, consider the following:

  • A SAP is a local entity and only locally unique to a specific device. The same SAP ID value can be used on another 7450 ESS or 7750 SR.

  • There are no default SAPs. All SAPs must be created.

  • The default administrative state for a SAP at creation time is administratively enabled.

  • When a SAP is deleted, all configuration parameters for the SAP is also deleted. For Internet Ethernet Service (IES), the IP interface must be shut down before the SAP on that interface may be removed.

  • A SAP is owned by and associated with the service in which it is created in each 7450 ESS or 7750 SR.

  • A port or channel with a dot1q or BCP-dot1q encapsulation type means the traffic for the SAP is identified based on a specific IEEE 802.1Q VLAN ID value. The VLAN ID is stripped off at SAP ingress and the appropriate VLAN ID placed on at SAP egress. As a result, VLAN IDs only have local significance, so the VLAN IDs for the SAPs for a service need not be the same at each SAP.

  • If a port or channel is administratively shut down, all SAPs on that port or channel are operationally out of service.

  • A SAP cannot be deleted until it has been administratively disabled (shut down).

  • Each SAP can be configured with only the following:

    • ingress or egress filter policy

    • ingress or egress QoS policy

    • accounting policy

    • ingress or egress scheduler policy

Service Distribution Points (SDPs)

A Service Distribution Point (SDP) acts as a logical way to direct traffic from one 7450 ESS or 7750 SR to another 7450 ESS or 7750 SR through a unidirectional (one-way) service tunnel. The SDP terminates at the far-end router which directs packets to the correct service egress SAPs on that device. A distributed service consists of a configuration with at least one SAP on a local node, one SAP on a remote node, and an SDP binding the service to the service tunnel.

An SDP has the following characteristics:

  • An SDP is locally unique to a participating 7450 ESS or 7750 SR. The same SDP ID can appear on other 7450 ESS or 7750 SR OS.

  • An SDP uses the system IP address to identify the far-end 7450 ESS or 7750 SR edge router.

  • An SDP is not specific to any one service or any type of service. After an SDP is created, services are bound to the SDP. An SDP can also have more than one service type associated with it.

  • All services mapped to an SDP use the same transport encapsulation type defined for the SDP (either GRE or MPLS).

  • An SDP is a management entity. Even though the SDP configuration and the services carried within are independent, they are related objects. Operations on the SDP affect all the services associated with the SDP. For example, the operational and administrative state of an SDP controls the state of services bound to the SDP.

An SDP from the local device to a far-end 7450 ESS or 7750 SR requires a return path SDP from the far-end router back to the local router. Each device must have an SDP defined for every remote router to which it wants to provide service. SDPs must be created first, before a distributed service can be configured.

SDP binding

To configure a distributed service from ALA-A to ALA-B, the SDP ID (4) (A GRE SDP pointing from ALA-A to ALA-B) must be specified in the service creation process to ‟bind” the service to the tunnel (the SDP). Otherwise, service traffic is not directed to a far-end point and the far-end 7450 ESS and 7750 SR device cannot participate in the service (there is no service).

Figure 11. A GRE SDP pointing from ALA-A to ALA-B

Spoke and mesh SDPs

When an SDP is bound to a service, it is bound as either a spoke SDP or a mesh SDP. The type of SDP indicates how flooded traffic is transmitted.

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.

All mesh SDPs bound to a service are 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.

SDP encapsulation types

The Nokia service model uses encapsulation tunnels through the core to interconnect 7450 ESS and 7750 SR service edge routers. An SDP is a logical way of referencing the entrance to an encapsulation tunnel.

The following encapsulation types are supported:

  • Layer 2 within Generic Routing Encapsulation (GRE)

  • Layer 2 within RSVP signaled, loose hop non-reserved MPLS LSP

  • Layer 2 within RSVP signaled, strict hop non-reserved MPLS LSP

  • Layer 2 within RSVP-TE signaled, bandwidth reserved MPLS LSP


GRE encapsulated tunnels have very low overhead and are best used for Best-Effort class of service. Packets within the GRE tunnel follow the Interior Gateway Protocol (IGP) shortest path from edge to edge. If a failure occurs within the service core network, the tunnel only converges as quickly as the IGP itself. If Equal Cost Multi-Path (ECMP) routing is used in the core, many loss-of-service failures can be minimized to sub-second timeframes.


Multi-Protocol Label Switching (MPLS) encapsulation has the following characteristics:

  • LSPs (label switched paths) are used through the network, for example, primary, secondary, loose hop, and so on These paths define how traffic traverses the network from point A to B. If a path is down, depending on the configuration parameters, another path is substituted.

    Paths can be manually defined or a constraint-based routing protocol (such as OSPF-TE or CSPF) can be used to determine the best path with specific constraints.

  • The 7450 ESS and 7750 SR OS support both signaled and non-signaled LSPs through the network.

  • Non-signaled paths are defined at each hop through the network.

  • Signaled paths are communicated via protocol from end to end using Resource Reservation Protocol (RSVP).

    Because services are carried in encapsulation tunnels and an SDP is an entrance to the tunnel, an SDP has an implicit Maximum Transmission Unit (MTU) value. The MTU for the service tunnel can affect and interact with the MTU supported on the physical port where the SAP is defined.

SDP keepalives

SDP keepalives are a way of actively monitoring the SDP operational state using periodic Nokia SDP Ping Echo Request and Echo Reply messages. Nokia SDP Ping is a part of Nokia’s suite of Service Diagnostics built on a Nokia service-level OA&M protocol. When SDP Ping is used in the SDP keepalive application, the SDP Echo Request and Echo Reply messages are a mechanism for exchanging far-end SDP status.

Configuring SDP keepalives on a specific SDP is optional. SDP keepalives for a particular SDP have the following configurable parameters:

  • AdminUp or AdminDown State

  • Hello Time

  • Message Length

  • Max Drop Count

  • Hold Down Time

SDP keepalive Echo Request messages are only sent when the SDP is completely configured and administratively up and SDP keepalives is administratively up. If the SDP is administratively down, keepalives for the SDP are disabled.

SDP keepalive Echo Request messages are sent out periodically based on the configured Hello Time. An optional Message Length for the Echo Request can be configured. If Max Drop Count Echo Request messages do not receive an Echo Reply, the SDP is immediately brought operationally down.

If a keepalive response is received that indicates an error condition, the SDP is immediately brought operationally down.

After a response is received that indicates the error has cleared and the Hold Down Time interval has expired, the SDP is eligible to be put into the operationally up state. If no other condition prevents the operational change, the SDP enters the operational state.

Epipe service overview

An Epipe service is Nokia’s implementations of an Ethernet VLL based on the IETF Martini Drafts (draft-martini-l2circuit-trans-mpls-08.txt and draft-martini-l2circuit-encapmpls-04.txt) and the IETF Ethernet Pseudowire Draft (draft-so-pwe3-ethernet-00.txt).

An Epipe service is a Layer 2 point-to-point service where the customer data is encapsulated and transported across a service provider’s IP or MPLS network. An Epipe service is completely transparent to the subscriber’s data and protocols. The 7450 ESS and 7750 SR Epipe service does not perform any MAC learning. A local Epipe service consists of two SAPs on the same node, whereas a distributed Epipe service consists of two SAPs on different nodes. SDPs are not used in local Epipe services.

Each SAP configuration includes a specific port or channel (applies to the 7750 SR) on which service traffic enters the router from the customer side (also called the access side). Each port is configured with an encapsulation type. If a port is configured with an IEEE 802.1Q (referred to as dot1q) encapsulation, then a unique encapsulation value (ID) must be specified.

The Epipe/VLL service is shown in Epipe and VLL services .

Figure 12. Epipe and VLL services

VPLS service overview

Virtual Private LAN Service (VPLS) as described in Internet Draft draft-ietf-ppvpn-vpls-ldp-01.txt, is a class of virtual private network service that allows the connection of multiple sites in a single bridged domain over a provider-managed IP/MPLS network. The customer sites in a VPLS instance appear to be on the same LAN, regardless of their location. VPLS uses an Ethernet interface on the customer-facing (access) side which simplifies the LAN/WAN boundary and allows for rapid and flexible service provisioning.

VPLS enables each customer to maintain control of their own routing strategies. All customer routers in the VPLS service are part of the same subnet (LAN) which simplifies the IP addressing plan, especially when compared to a mesh constructed from many separate point-to-point connections. The VPLS service management is simplified because the service is not aware of nor participates in the IP addressing and routing.

A VPLS service provides connectivity between two or more SAPs on one (which is considered a local service) or more (which is considered a distributed service) routers. The connection appears to be a bridged domain to the customer sites so protocols, including routing protocols, can traverse the VPLS service.

Other VPLS advantages include:

  • VPLS is a transparent, protocol-independent service.

  • There is no Layer 2 protocol conversion between LAN and WAN technologies.

  • There is no need to design, manage, configure, and maintain separate WAN access equipment, therefore, eliminating the need to train personnel on WAN technologies.

For details on VPLS, including a packet walkthrough, see VPLS section in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide.

Split horizon SAP groups and split horizon spoke SDP groups

Within the context of VPLS services, a loop-free topology within a fully meshed VPLS core is achieved by applying split-horizon forwarding concept that packets received from a mesh SDP are never forwarded to other mesh SDPs within the same service. The advantage of this approach is that no protocol is required to detect loops within the VPLS core network.

In applications such as DSL aggregation, it is useful to extend this split-horizon concept also to groups of SAPs and spoke SDPs. This extension is referred to as a split horizon SAP group or residential bridging.

Traffic arriving on a SAP or a spoke SDP within a split horizon group is not copied to other SAPs and spoke SDPs in the same split horizon group (but is copied to SAPs or spoke SDPs in other split horizon groups if these exist within the same VPLS).

Residential split horizon groups

To improve the scalability of a SAP-per-subscriber model in the broadband services aggregator (BSA), the 7450 ESS and 7750 SR support a variant of split horizon groups called residential split horizon groups (RSHG).

A RSHG is a group of split horizon group SAPs with following limitations:

  • Downstream broadcast traffic is not allowed.

  • Downstream multicast traffic is allowed when IGMP snooping is configured in the VPLS.

  • STP is not supported.

Spoke SDPs can also be members of a RSHG VPLS. The downstream multicast traffic restriction does not apply to spoke SDPs.

IES service overview

Internet Enhanced Service (IES) is a routed connectivity service where the subscriber communicates with an IP router interface to send and receive Internet traffic. An IES has one or more logical IP routing interfaces each with a SAP which acts as the access point to the subscriber’s network. IES allow customer-facing IP interfaces to participate in the same routing instance used for service network core routing connectivity. IES services require that the IP addressing scheme used by the subscriber be unique between other provider addressing schemes and potentially the entire Internet.

While IES is part of the routing domain, the usable IP address space may be limited. This allows a portion of the service provider address space to be reserved for service IP provisioning, and be administered by a separate but subordinate address authority.

IP interfaces defined within the context of an IES service must have a SAP associated as the access point to the subscriber network, as shown in Internet Enhanced Service . Multiple IES services are created to segregate subscriber-owned IP interfaces.

Figure 13. Internet Enhanced Service

The IES service provides Internet connectivity. Other features include:

  • Multiple IES services are created to separate customer-owned IP interfaces.

  • More than one IES service can be created for a single customer ID.

  • More than one IP interface can be created within a single IES service ID. All IP interfaces created within an IES service ID belong to the same customer.

IP interface

IES customer IP interfaces can be configured with most of the same options found on the core IP interfaces. The advanced configuration options supported are:

  • VRRP (for IES services with more than one IP interface)

  • Cflowd (supported on the 7750 SR only)

  • secondary IP addresses

  • ICMP options

Configuration options found on core IP interfaces not supported on IES IP interfaces are:

  • unnumbered interfaces

  • NTP broadcast receipt

VPRN service overview

Virtual Private Routed Network (VPRN) services are supported on the 7750 SR only.

RFC2547bis is an extension to the original RFC 2547, which details a method of distributing routing information and forwarding data to provide a Layer 3 Virtual Private Network (VPN) service to end customers.

Each Virtual Private Routed Network (VPRN) consists of a set of customer sites connected to one or more PE routers. Each associated PE router maintains a separate IP forwarding table for each VPRN. Additionally, the PE routers exchange the routing information configured or learned from all customer sites via MP-BGP peering. Each route exchanged via the MP-BGP protocol includes a Route Distinguisher (RD), which identifies the VPRN association.

The service provider uses BGP to exchange the routes of a particular VPN among the PE routers that are attached to that VPN. This is done in a way which ensures that routes from different VPNs remain distinct and separate, even if two VPNs have an overlapping address space. The PE routers distribute routes from other CE routers in that VPN to the CE routers in a particular VPN. Because the CE routers do not peer with each other there is no overlay visible to the VPN's routing algorithm.

When BGP distributes a VPN route, it also distributes an MPLS label for that route. On a SR-Series, a single label is assigned to all routes in a VPN.

Before a customer data packet travels across the service provider's backbone, it is encapsulated with the MPLS label that corresponds, in the customer's VPN, to the route which best matches the packet's destination address. The MPLS packet is further encapsulated with either another MPLS label or GRE tunnel header, so that it gets tunneled across the backbone to the correct PE router. Each route exchanged by the MP-BGP protocol includes a route distinguisher (RD), which identifies the VPRN association. Thus, the backbone core routers do not need to know the VPN routes.

Deploying and provisioning services

The service model provides a logical and uniform way of constructing connectivity services. The basic steps for deploying and provisioning services can be broken down into three phases.

Phase 1: Core network construction

Before the services are provisioned, the following tasks should be completed:

  • Build the IP or IP/MPLS core network.

  • Configure routing protocols.

  • Configure MPLS LSPs (if MPLS is used).

  • Construct the core SDP service tunnel mesh for the services.

Phase 2: Service administration

Perform preliminary policy and SDP configurations to control traffic flow, operator access, and to manage fault conditions and alarm messages, the following tasks should be completed:

  • Configure group and user access privileges.

  • Build templates for QoS, filter, and accounting policies needed to support the core services.

Phase 3: Service provisioning

  • Provision customer account information.

  • If necessary, build any customer-specific QoS, filter or accounting policies.

  • Provision the customer services on the 7750 SR or 7450 ESS service edge routers by defining SAPs, binding policies to the SAPs, and then binding the service to appropriate SDPs as necessary.

Configuration notes

This section describes service configuration restrictions.


Service provisioning tasks can be logically separated into two main functional areas, core tasks and subscriber tasks and are typically performed before provisioning a subscriber service.

Core tasks include the following:

  • Create customer accounts.

  • Create template QoS, filter, scheduler, and accounting policies.

  • Create LSPs.

  • Create SDPs.

Subscriber services tasks include the following:

  • Create VLL, VPLS, IES, or VPRN services (VPRN is supported on the 7750 SR only).

  • Configure interfaces (where required) and SAPs.

  • Bind SDPs.

  • Create exclusive QoS and filter policies.

Configuring Triple Play services with CLI

This section provides information to configure Residential Broadband Aggregation services using the command line interface. It is assumed that the reader is familiar with basic configuration of VPLS, IES and VPRN services (VPRN is supported on the 7750 SR only).

Configuring VPLS RSHG

To configure a group of SAPs in a VPLS service as a RSHG, add the residential-group parameter when creating the split horizon group. Traffic arriving on a SAP within an RSHG is not copied to other SAPs in the same split horizon group.

Note: The split horizon group must be created before it can be applied.

The following example displays a VPLS configuration with split horizon enabled:

*A:ALA-48>config>service>vpls# info
            split-horizon-group "DSL-group2" residential-group create
                description "split horizon group for DSL - no broadcast supported"
            sap 2/1/4:100 split-horizon-group "DSL-group2" create
                description "SAP in RSHG"
            sap 2/1/4:200 split-horizon-group "DSL-group2" create
                description "another SAP in the RSHG"
            no shutdown

Configuring static hosts

In order for the static host to be operational, forwarding traffic bidirectional, the MAC address of the host must be learned or configured. Learning the MAC of the static host is different for IPv4 or IPv6.

If an IPv4 static host MAC is not specified:

  • The system learns respective MAC address dynamically from ARP packets (arp-request or gratuitous-arp) generated by the host with the specified IP address.

  • On a VPLS service, this can occur if arp-reply-agent function is enabled on a specific SAP. On Layer 3 services, such as IES or VPRN, the ARP packets are always examined so no further conditions are applicable.

If an IPv6 static host MAC is not specified the system learns the MAC address depending on the type of host configured such as: IPv6 prefix host or IPv6 address host.

  • A SAP can be specified as a single-MAC and it implies that there is only a single device attached to the SAP. It changes the MAC learning behavior on the SAP for IPv6 host only. Firstly, all IPv6 hosts shares the same learned MAC. Secondly, the MAC address is learned from the host’s router solicits and neighbor discoveries.

  • For static host with an address, upon shutdown, a RS for the clients IPv6 address is sent toward the host and the MAC is learned upon the RA reply.

  • For static host with an address, SHCV sends the RS, and the MAC is learned from the RA.
  • For static host with an address, the OAM command can trigger a RS and the MAC is learned from the RA.

  • For static host with either a prefix or an address, linking the IPv6 host to an IPv4 host copies the IPv4 host MAC address to the IPv6 host and vice versa.

The learned MAC address is handled as a MAC address of static host with explicitly defined mac-address. Meaning:

  • The MAC address is not aged by the mac-aging or any other aging timers.

  • The MAC address is not moved to a new SAP as a consequence of relearning event. A relearning event is a learning request for the same MAC address which comes from a new SAP.

  • The MAC address is not flushed from FDB because of a SAP failure or STP flush messages.

Every time the specified static-host uses a different MAC address in its ARP request, the dynamic MAC learning process is performed. The old MAC address is overwritten by a new MAC address.

The learned MAC address is not made persistent (a static host is not a part of the persistency file). A service discontinuity of such a host could be proportional to its arp-cache timeout.

The following interactions are described:

  • antispoof (all services)

    If a static IP-only host is configured on a specific SAP, then anti-spoof types, IP, NH MAC, and IP MAC are supported. Static hosts for which the MAC address is not known does not have an anti-spoof entry. It is added only after the corresponding MAC has been learned. As a consequence, all traffic generated by the host before the MAC is learned are dropped.

  • MAC-linking (IES and VPRN service only)

    The MAC address can be learned from either the IPv4 or IPv6 host. When learned it is copied over to the host of the other address family.

  • single-MAC (IES and VPRN service only)

    This specifies that there is only one single subscriber (MAC) on the SAP and any ICMP6 message from the SAP can be assumed to be the subscriber MAC address. This does not apply to IPv4 host.

  • Enhanced Subscriber Management (all services)

    ESM is supported in a combination with a static ip-only host. It is assumed that ip-mac antispoofing is enabled. The resources (queues, and so on) are allocated at the time such a host is configured, although they are effectively used only after anti-spoof entry has been installed.

  • multi-chassis redundancy

    The dynamic MAC address learning event is not synchronized in MCS. When an IP-only static host is configured on both chassis of a redundant BNG pair, MAC learning needs to be triggered on each router independently.

  • mac-pinning (for VPLS services only)

    The dynamically learned MAC address of the static-host is considered as a static-mac and is not affected by the no mac-pinning command.

  • arp-reply-agent (VPLS services only)

    It is possible to the enable arp-reply-agent on a SAP where the static host has ip-only configured. In addition to the regular arp-reply-agent functionality (the reply to all arp-requests targeting the specified host's IP address) learning of the host's MAC address is performed. As long as no MAC address have been learned no ARP replies on behalf of such host should be expected. Enabling of arp-reply-agent is optional for SAP with ip-only static hosts.

BNG learning IP-only static host’s MAC address

Before an IP-only static host can forward or receive traffic, the MAC of the host must be learned by the BNG. The learned MAC is used to fill in the anti-spoof entry for the static host. Methods to learn IP-only static host MAC addresses summarizes the different methods that the BNG could use to learn the IP only static host MAC address.

Table 4. Methods to learn IP-only static host MAC addresses
Number of hosts on SAP IPv4 static host IPv6 numbered static host IPv6 prefix only host (unnumbered) DS host


Host’s ARP



Data packet


Auto populate RS and NS MAC

GUA based NS

Triggered SHCV

Data packet


Auto populate RS and NS MAC

GUA based NS

Data packet


With IPv6 static host MAC (if available) and mechanisms listed for IPv4 static host

IPv6 numbered host:

With IPv4 static host MAC (if available) and mechanisms listed for IPv6 numbered static host

IPv6 prefix only host:

With IPv4 static host MAC (if available) and mechanism listed for IPv6 prefix only host


Host’s ARP

Triggered SHCV

Data packet


GUA based NS


Data packet


GUA based NS

Data packet


Through IPv6 static host MAC (if available) and mechanism listed for IPv4 static host

IPv6 numbered host:

With IPv4 static host MAC (if available) and mechanism listed for IPv6 numbered static host

With prefix only host:

Via IPv4 static host MAC (if available) and mechanism listed for IPv6 prefix only host

IP-only static hosts without a MAC address are put into a ‟non-forwarding” state and are not able to send or receive traffic. The BNG must populate the MAC address using the methods described in the table above to put the host into a ‟forwarding” state. If the IPv4 static host sends an ARP, then the IPv4 address along with Ethernet header source MAC can populate the IP-only host MAC address. For IPv6, the subscriber must send in a NS using the GUA to allow the BNG to resolve the MAC address. If the IP-only host is an IPv6 prefix, NS using the GUA can also resolve the static host MAC address, provided that the GUA is within the subnet of the prefix. n IPv6 prefix host can only have one MAC association, multiple bridged hosts using a single IPv6 prefix is not supported. To support multiple bridge hosts on a SAP, individual /128 host must be configured along with enabling ipoe-bridge-mode.

Static host learning the IPv6 default gateway address

Static hosts also need to resolve the default gateway and MAC to forward traffic. Static hosts can learn the BNG MAC using the following methods.

  • If the static host can use the BNG link-local as the default gateway, then the exchange of router solicit and advertisement should be able to populate the default route for the static host.

  • If the static host can use the BNG link-local as the default gateway but only through neighbor solicit, the BNG responds to NS only if the source address is the GUA of the host.

  • If the static host can only use a GUA as the default gateway, then the subscriber interface must be configured with an IPv6 address instead of a prefix.

A host’s RS or NS messages may use link-local as the source address. The host’s link-local addresses are unknown to the BNG, because the BNG only knows static hosts by their GUA. By default, unknown host’s RS or NS messages are dropped. Therefore, static hosts cannot resolve their default gateway or MAC address. There are two different methods to enable the BNG to respond to static host’s RS or NS messages. The first solution is to declare the SAP as a single-mac. When a SAP is configured as a ‟single-mac”, it is declaring that only a single host is expected on the SAP and any RS or NS sent by the host automatically populates the MAC table. The BNG in return also responds to the static host’s RS or NS. The second solution is for cases where multiple hosts are on the SAP. The RS or NS may not provide enough information to populate the subscriber host’s MAC because the source IP are link-local addresses. The BNG anti-spoof only replies to known hosts RS or NS; therefore, these static hosts’ RS or NS are dropped. The group interface has a configuration option to auto-reply to any RS or NS, which allows the static host to resolve their default gateway or route. Afterwards, the static host can send traffic to the BNG, which the BNG can use for MAC learning. To use data packets for MAC learning, the BNG has a ‟data-trigger” learning option for static hosts.

Configuring static hosts on an VPLS SAP

The following example displays a static host on a VPLS SAP configuration:

*A:ALA-48>config>service# info
vpls 800 customer 6001 create
    description "VPLS with residential split horizon for DSL"
    sap 1/2/7:100 split-horizon-group "DSL-group2" create
        description "SAP for RSHG"
        static-host ip
    no shutdown
Configuring static hosts on an IES SAP

The following displays a static host on an IES SAP:

*A:ALA-49>config>service>ies>sub-if>grp-if# info
    sap 7/1/5 create
    description "IES with static host"
        static-host ip create
        static-host ip 2001::1/128 create
        static-host ip 2001:1::/64 create
Configuring static hosts on a VPRN SAP

The following displays a static host on a VPRN SAP:

*A:ALA-49>config>service>vprn>sub-if>grp-if# info
    description "VPRN service with static host"
    sap 7/1/5 create
        description "IES with static host"
        static-host ip create
        static-host ip 2001::1/128 create
        static-host ip 2001:1::/64 create