Introduction to Triple Play

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.

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.

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.

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.

Upstream QoS enablement keys are described in Upstream QoS enablement.

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).

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.

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.

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)

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.

The following lists encapsulation service options on Ethernet ports:

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

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

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).

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.

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

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.

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.

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.

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.