AS I WOULD RECOMMEND
7730 Service Interconnect Router.
The Nokia 7730 Service Interconnect Router (SXR) family provides next-generation IP access, aggregation and edge platforms that make it easy to deliver secure, assured and sustainable IP networking services.
Designed for communications service providers (CSPs) and mission-critical enterprises, 7730 SXR platforms can help you boost performance and capability in advanced IP access and aggregation networks. In distributed IP edge locations, they can help you more efficiently meet the demand driven by broadband investments and evolving cloud network architectures. For mission critical services, the 7730 SXR brings a new level of deterministic performance and resiliency to the furthest reaches of your network.
The Nokia 7730 Service Interconnect Router (SXR) family provides next-generation IP access, aggregation and edge platforms that make it easy to deliver secure, assured and sustainable IP networking services.
Designed for communications service providers (CSPs) and mission-critical enterprises, 7730 SXR platforms can help you boost performance and capability in advanced IP access and aggregation networks. In distributed IP edge locations, they can help you more efficiently meet the demand driven by broadband investments and evolving cloud network architectures. For mission critical services, the 7730 SXR brings a new level of deterministic performance and resiliency to the furthest reaches of your network.
Enjoy the benefits of advanced routing silicon
At the heart of the 7730 SXR is the Nokia FPcx network processing unit (NPU). In-house designed and fully programmable, the FPcx brings the values of our high-performance and feature-rich FP silicon into a compact and extensible package.
With network security features such as in-line filtering for DDoS mitigation and advanced line-rate encryption, you can rest assured you will have the tools to protect your network and the services running on top of it. A unique multi-core cluster design opens up new ways to streamline software upgrades without network downtime. Advanced QoS, queueing and a hierarchical memory design ensure that your IP packets will get where they need to go when they are supposed to get there.
With a fully programmable NPU, you can accommodate new services and standards as they emerge without having to rebuild your network.
At the heart of the 7730 SXR is the Nokia FPcx network processing unit (NPU). In-house designed and fully programmable, the FPcx brings the values of our high-performance and feature-rich FP silicon into a compact and extensible package.
With network security features such as in-line filtering for DDoS mitigation and advanced line-rate encryption, you can rest assured you will have the tools to protect your network and the services running on top of it. A unique multi-core cluster design opens up new ways to streamline software upgrades without network downtime. Advanced QoS, queueing and a hierarchical memory design ensure that your IP packets will get where they need to go when they are supposed to get there.
With a fully programmable NPU, you can accommodate new services and standards as they emerge without having to rebuild your network.
Unlock a new era of NetOps with SR Linux on the 7730 SXR
As networks become more complex, network automation becomes an increasingly critical approach to streamlining network operations. 7730 SXR platforms are built for automation from the ground up, leveraging the Nokia SR Linux network operating system (NOS), which embraces cloud-native design principles, and the Nokia Network Services Platform (NSP) automation suite.
Benefit from automation at scale with a modular model-driven architecture, telemetry at unprecedented granularity and unified service automation and network optimization across IP, MPLS, Ethernet and optical transport layers.
Enjoy resilient networking and hitless per-application software upgrades enabled by the microservices-based, state-efficient design of SR Linux.
Be ready for the future with the unmatched extensibility of SR Linux, enabled by its open design and application development platform.
As networks become more complex, network automation becomes an increasingly critical approach to streamlining network operations. 7730 SXR platforms are built for automation from the ground up, leveraging the Nokia SR Linux network operating system (NOS), which embraces cloud-native design principles, and the Nokia Network Services Platform (NSP) automation suite.
Benefit from automation at scale with a modular model-driven architecture, telemetry at unprecedented granularity and unified service automation and network optimization across IP, MPLS, Ethernet and optical transport layers.
Enjoy resilient networking and hitless per-application software upgrades enabled by the microservices-based, state-efficient design of SR Linux.
Be ready for the future with the unmatched extensibility of SR Linux, enabled by its open design and application development platform.
Add efficiency into your IP network design
With four fixed form-factor and two modular platform variants, and support for high-density interface speeds ranging from 1GE to 400GE, you are sure to find the right 7730 SXR platform to efficiently meet your IP access, aggregation or small edge needs.
With four fixed form-factor and two modular platform variants, and support for high-density interface speeds ranging from 1GE to 400GE, you are sure to find the right 7730 SXR platform to efficiently meet your IP access, aggregation or small edge needs.
Introducing the Nokia 7730 SXR, raise the Xpectations of your IP networks
Nokia FPcx routing silicon
How NetOps raises your Xpectations for IP Network operations with Nokia
7730 SXR benefits and features
Assured and efficient performance
- Deliver assured IP services with a network processor design that supports deterministic performance, 7-level hierarchical QoS and 256K queues.
- Ensure consistent service levels across your network with a robust and reliable NOS that leverages field-hardened SR OS protocol stacks and IP networking applications.
- Drive energy efficiency through right-sized platforms, support for SFP-DD optics and 112G SerDes technology.
- Deliver assured IP services with a network processor design that supports deterministic performance, 7-level hierarchical QoS and 256K queues.
- Ensure consistent service levels across your network with a robust and reliable NOS that leverages field-hardened SR OS protocol stacks and IP networking applications.
- Drive energy efficiency through right-sized platforms, support for SFP-DD optics and 112G SerDes technology.
Extensive capabilities
- Deliver more IP services and visibility with superior scalability for counters, services, tunnels, queues, policers and tables.
- Enhance IP network security with in-line support for DDoS mitigation.
- Secure IP services through MACsec/ANYsec line-rate encryption with no impact on performance.
- Deliver more IP services and visibility with superior scalability for counters, services, tunnels, queues, policers and tables.
- Enhance IP network security with in-line support for DDoS mitigation.
- Secure IP services through MACsec/ANYsec line-rate encryption with no impact on performance.
Advanced timing and synchronization
- Meet stringent synchronization demands with highly accurate timing enabled by integrated dual-band Global Navigation Satellite System (GNSS) receivers.
- Support time-sensitive packet transport and fronthaul networks with a Class C-based Telecom Boundary Clock.
- Meet stringent synchronization demands with highly accurate timing enabled by integrated dual-band Global Navigation Satellite System (GNSS) receivers.
- Support time-sensitive packet transport and fronthaul networks with a Class C-based Telecom Boundary Clock.
Right-size scale for efficient network designs
- Bring more capability to the furthest reaches of your IP network with platforms that support 3.6 Tb/s to 5.6 Tb/s of system capacity.
- Support interface speeds from 1GE to 400GE with comprehensive breakout capabilities.
- Introduce coherent routing applications with platforms that support digital coherent optics (DCOs).
- Bring more capability to the furthest reaches of your IP network with platforms that support 3.6 Tb/s to 5.6 Tb/s of system capacity.
- Support interface speeds from 1GE to 400GE with comprehensive breakout capabilities.
- Introduce coherent routing applications with platforms that support digital coherent optics (DCOs).
NetOps building blocks
- Streamline IP network operations with a Linux-based NOS that supports cloud-native design approaches with a modular, microservices, state-sharing architecture.
- Customize your network with our NetOps Development Kit (NDK) and programmable Python-based CLI.
- Streamline IP network operations with a Linux-based NOS that supports cloud-native design approaches with a modular, microservices, state-sharing architecture.
- Customize your network with our NetOps Development Kit (NDK) and programmable Python-based CLI.
Built for automation at scale
- Automate IP network operations at scale with model-driven management, full YANG coverage and comprehensive telemetry with granular counters on all key metrics.
- Leverage unmatched traffic control and optimization, network and service assurance, and transport and service provisioning with the Network Services Platform (NSP).
- Automate IP network operations at scale with model-driven management, full YANG coverage and comprehensive telemetry with granular counters on all key metrics.
- Leverage unmatched traffic control and optimization, network and service assurance, and transport and service provisioning with the Network Services Platform (NSP).
Solution components
FPcx
SR Linux
Network Services Platform
Resources
Application notes
Blogs
Brochures
Solution Sheet
White papers
Related solutions and products
Coherent Routing
IP Anyhaul
7750 Service Router
Deepfield Defender
Network Services Platform
-----------------------
Now About BNG AND VBNG
There is no such difference in BNG and vBNG , it’s depends on how you implementing . Here only the platform for vBNG (virtualized devices going to be used) is changed and some of the CLI’s . when i was working i have not seen so much differences .
---------
© 2020 SCTE•ISBE and NCTA. All rights reserved. 1
A Virtual Broadband Network Gateway (vBNG)
Approach for Cable Operators in a Distributed Access
Environment
A Technical Paper prepared for SCTE•ISBE by
Jason Combs
Principal Architect
Comcast
1800 Arch St Philadelphia, PA 19103
609-706-9190
jason_combs@cable.comcast.com
© 2020 SCTE•ISBE and NCTA. All rights reserved. 2
Table of Contents
Title Page Number
1. Introduction.......................................................................................................................................... 3
2. The challenges of today’s access network ......................................................................................... 3
3. A method of network abstraction......................................................................................................... 5
3.1. Service Activation Layer......................................................................................................... 6
3.2. The virtual Broadband Network Gateway structure ............................................................... 8
4. Advantages of an NFV and SDN approach compared to a traditional BNG ...................................... 9
5. Conclusion......................................................................................................................................... 10
Abbreviations .............................................................................................................................................. 10
Bibliography & References.......................................................................................................................... 11
List of Figures
Title Page Number
Figure 1 – Evolution of the Access Network ................................................................................................. 4
Figure 2 – Functional components of this network abstraction..................................................................... 6
Figure 3 – Interfaces and functions of the Service Activation Layer............................................................. 7
Figure 4 – vBNG structure (OLT example) ................................................................................................... 8
List of Tables
Title Page Number
NO TABLE OF FIGURES ENTRIES FOUND.
© 2020 SCTE•ISBE and NCTA. All rights reserved. 3
1. Introduction
For as long as the Multiple System Operator (MSO) community has built and operated networks, we have
been looking for better ways to segment it, and to optimize the work needed to update and maintain it. In
addition, serious efforts emerged over the last several years to add other access media to the mix, such as
passive optical networks (PONs) and wireless technologies. Among these efforts is network function
virtualization (NFV) and software defined networking (SDN), which have captured the attention of the
MSOs and of the networking world at large. How does the MSO community take advantage of these
concepts to fulfill both today’s needs as well as the desire for an easier, quicker deployment of access
network technology going forward into the future? In this paper, we will explore:
• Challenges faced by MSOs in deploying new types of access technologies alongside the
current (virtual/”v”) CMTS
• A method for abstracting service activation to allow for common control of dissimilar access
technologies
• A flexible virtual broadband network gateway (vBNG) structure that matches MSO service
formats to operate non-DOCSIS access technologies (e.g. PON)
• Advantages of this NFV and SDN approach compared to a traditional hardware BNG
2. The challenges of today’s access network
The traditional cable operator’s access network is centered around the DOCSIS technology that we all
know and love. The business support systems (BSS) and the operations support systems (OSS) that are
employed are equally centered around supporting the protocols defined by the DOCSIS protocols.
CableLabs and we, as a community, have done an excellent job of extending those systems to support our
business needs, as our customers and the Internet as a whole evolved from basic data services into voice,
IP video, and commercial services.
The focus on a single technology with a single provisioning and operating model led to development of
Cable Modem Termination Systems (CMTS) and Optical Line Terminators (OLT) that are fully
integrated, as shown in the blue and orange boxes in Figure 1. These systems are typically developed by a
single vendor to support all of the service, routing, reporting, and physical functions. The Distributed
Access Architecture (DAA) separated the physical generation of the signal, but otherwise remained as
integrated as the original CMTS systems. Likewise, the virtual CMTS (vCMTS) has given us a peek into
the future by allowing the CMTS functions to live in a server environment, with all of the technology
used to accomplish that, but still retains the unified structure seen in prior iterations of the CMTS.
© 2020 SCTE•ISBE and NCTA. All rights reserved. 4
Figure 1 – Evolution of the Access Network
The challenge with this integrated structure begins to clearly show itself once we consider providing our
services through other access technologies. The expansion into other access technologies is happening for
a number of reasons including demand for multi dwelling unit solutions, changes in physical construction
costs, and the desire to compete in the Wi-Fi and wireless arenas. Although more distinctly seen now,
these issues have been lurking in the shadows all along. The DOCSIS service, provisioning, and
operational models do not mesh well when combined with the wireless, fiber, and ethernet technologies
that allow us to expand our network in non-traditional directions. On the other side of the coin, the BSS
and OSS systems that have grown up in reaction to the DOCSIS architecture force us to attempt to have
other access technologies mimic that architecture to avoid major back office changes. The following
paragraphs provide a brief synopsis of five admittedly intertwined priorities that are difficult to achieve
with the current structure.
• Swift integration of new access technologies. Beyond the need to develop a technology for our
physical network, new technologies typically also come with a full system design and integration.
All of these system components require time to develop, and often duplicate the same functions
from other systems. Most introductions of new vendors cause us to start this cycle again,
representing a high barrier to entry and ultimately fewer options for technology partners.
• Consistent services provisioning. It is cumbersome to develop and maintain separate BSS
systems, in whole or in part, for every technology that we deploy. The problem is a compounding
one. It is a massive effort to deploy new authentication and service definition systems, and once
they exist, they are difficult to maintain while assuring that service definitions remain aligned
© 2020 SCTE•ISBE and NCTA. All rights reserved. 5
with the existing DOCSIS systems. The way around this problem is to create a translation system,
such as the virtual cable modem introduced by DOCSIS Provisioning of EPON (DPoE). This,
too, needs to be maintained and updated with the latest changes, and can easily fall behind.
Workaround remedies add time to any process and represent custom work for the MSO
community.
• Service consistency. DOCSIS provides a robust set of service features, which are implemented in
its service flows with extensive classifiers, subscriber management filters, and frame accounting
with Simple Network Management Protocol (SNMP) and IP detail records (IPDR). Other access
technologies have similarly robust features that are simply different from what we typically use.
Aligning these methods can cause hardware and feature control issues that limit our choices. The
worst-case scenario is the network could look and act differently for one customer than it does for
another.
• Testing velocity. Swift testing is an inherent challenge with any additional development. What
exacerbates it is the unnecessary replication of the same function within multiple systems. Rather
than testing the unique functions, much time is spent retesting different implementations of the
same function.
• Operational model differences. With different systems come different interpretations of
specifications and different interface models. This is aggravated by specifications created by
organizations with very different goals, that apply to other access technologies. They also create
additional work, to translate from one system to another.
3. A method of network abstraction
There is no simple or fast solution to the challenges stated in the previous section. A new system
organizational abstraction is needed to make significant progress in resolving these issues. The existing
system needs to be broken into distinct components that can evolve in isolation from each other. In kind,
these components need to be linked by extensible application programming interfaces (APIs) that can be
modified to meet the needs of the future. With this isolation and extensibility, we remove the need to
replicate functions that are common to all of the access technologies and give ourselves the flexibility to
integrate any technology quickly. Figure 2 below represents the proposed network abstraction.
© 2020 SCTE•ISBE and NCTA. All rights reserved. 6
Figure 2 – Functional components of this network abstraction
This architecture focuses on three major areas of providing services through a scaled access system:
The billing and provisioning systems manage the customer entitlements and interactions with us as cable
operators. It is necessary to break away from the tight DOCSIS integration that our back-office systems
are built on. Much of the goal of this architecture is to enable that transition. The change itself is a
massive amount of work that is not directly addressed within this paper.
The service activation layer receives the entitlements from the BSS and creates the detailed service
description for a particular customer device.
The vBNG implements the service description provided by the service activation layer and manages the
moment by moment experience of the customer. This layer can be broken down further, which we will
explore in the following sections. We can add a fourth area to this list of three areas to include the
operations and data gathering systems. This has been explored by prior papers in detail, for example, in
the SCTE paper “The Future of Operations: Building a Data-Driven Strategy” [1] and will not be
explored here.
3.1. Service Activation Layer
The service activation layer exists to create a means of defining the customer’s access network services
that is abstracted away from both the BSS system and the access technologies that those services ride on.
There are several aspects to this component that are necessary to be able to provide this function as
illustrated in Figure 3.
© 2020 SCTE•ISBE and NCTA. All rights reserved. 7
Figure 3 – Interfaces and functions of the Service Activation Layer
• Service Entitlement flexibility. Many access networks, such as DOCSIS, use a bottom up
provisioning methodology where the end device requests service. However, there are examples of
top down access networks, such as commercial ethernet and residential ethernet, where the end
device does not include this capability. It is important to have an API that allows for both
methods of entitlement and configuration.
• Unified Access Service Descriptors. These descriptors are imagined to be in the form of a YANG
data model to communicate the services to the vBNG deterministically. They would be formed
via a configuration generator that takes the access device type and model along with the
customer’s entitlements into account. With a common vBNG data plane and a desire to have
consistent services, it is imagined that the YANG model for the customer’s services would be
largely common between access types. The Virtual Provisioning Interfaces Technical Report [2]
produced by CableLabs has defined a YANG model that may be a good fit for this language.
• Access/Customer Premise specific configuration modifiers. While the majority of the service
definitions will be common, there will certainly be access-specific configurations that would be
of interest. For example, a PON system may want to be able to configure optical parameters that
do not apply to other access technologies. Access-specific extensions of the universal YANG
model would cover this case.
• Database of activated services. With millions of devices in our networks, it is often difficult to
have a definitive knowledge of the exact service configuration the customer device is operating
upon when a problem is discovered. The service activation layer should record the exact
configuration given for each device to aid in troubleshooting and to add traceability.
• Push/Pull of configuration. In the same vein as supporting both bottom up and top down
provisioning, this is the mechanism for providing the YANG model configuration to the vBNG.
This also enables the ability to change customer device configuration dynamically.
© 2020 SCTE•ISBE and NCTA. All rights reserved. 8
Introducing the service activation layer gives us several capabilities and advantages that help us overcome
the problems defined earlier in this paper.
• It abstracts billing and provisioning away from the configuration of the network.
• It presents a consistent service provisioning mechanism for all access networks and all
services running through them.
• It brings consistency to service definitions across all access technologies, making their
implementation also consistent, within the vBNG
• It eases the application of dynamic services to existing devices and allows for modification of
existing services.
3.2. The virtual Broadband Network Gateway structure
Many of the issues discussed here can be resolved with a proper vBNG implementation. There are a
number of options, in terms of how the vBNG can be laid out, and which components are included. Let us
start with a description of the basic components in this method.
Figure 4 – vBNG structure (OLT example)
Access controller. This sets up the access network itself and the services that flow through it. To
accomplish this task there are several steps that are necessary. A service configuration interpreter
translates the YANG model produced by the service activation layer into access-specific configurations
used by the vSubscriber data construct. The access manager, displayed as an “OLT” or “ONU Manager”
in the diagram, is responsible for configuring all remote access components. A service control API then
sends the necessary configuration information to the data forwarder, which is where components common
to all access networks are configured.
© 2020 SCTE•ISBE and NCTA. All rights reserved. 9
Data forwarder. This provides frame processing and basic subscriber services. Certain functions can be
enabled or disabled, such as a traffic manager, for access networks that do not have a built-in means of
doing so. On a per customer basis, features like subscriber management filtering and DSCP rewrite can
be enabled or disabled based on the services defined via the service activation layer. To aid in effective
use of network and processor resources, the data forwarder can be implemented as a single unit or can be
separated out for greater flexibility. The first logical separation is the network control, which includes the
functions necessary to connect to the MSO network as well as typical services such as DHCP relay,
routing protocols, and legal intercept controls. The upstream data plane is the next separation and
provides data forwarding services from the customer into the network. Upstream traffic typically has a
lower volume expectation. Finally, the downstream data plane provides data forwarding services from the
network to the customer. In this case, all access networks would utilize the traffic manager function to
shape traffic going downstream. Downstream traffic typically has a higher volume expectation.
These components give us several advantages, no matter how they are laid out in a virtualized system.
• The data forwarder includes common code for all access networks. This is a major facilitator of
service consistency, as all customers are served by the same implementation for many of
functions provided. From a development perspective this allows us to develop once but use the
code many times. Adding new routing protocols, for example, only requires the single
implementation to be tested. There is also no need to test the common code extensively when a
new access network is developed.
• The Service control API is well defined between the access controller and the data forwarder.
This allows for easy and unambiguous integration with new access controllers.
• New development for a new access technology is primarily limited to the access specific
functionality such as the access controller, the remote access element, and interoperability with
in-home equipment.
4. Advantages of an NFV and SDN approach compared to a traditional
BNG
The traditional BNG is the staple of many telecommunication companies’ network and has proven to be a
solid solution for their access needs. So, why not use the same thing? The answer lies in flexibility. Just
as with traditional CMTS deployments, a network operator must choose and size the BNG appropriately
for both their current and future needs. Inevitably, when the network capacity or business needs surpass
that BNG’s capabilities, the operator must upgrade or add more BNGs -- or worse, do both.
Flexibility and reuse are where NFV and SDN shine. This is exemplified by allowing the system to
expand functionality naturally into new access networks, while also allowing each of the components to
continue to evolve -- to remain the best they can be, without requiring that the entire system be recreated.
In terms of capacity, the system relies on generic processing hardware to do its job.
The first advantage with this approach is the ability to directly add capacity by adding more compute
power, without touching the rest of the system. Secondly, when using generic hardware, the system can
be laid out in different ways to fit the most effective technology, in terms of cost and efficiency.
There are several ways in which these components can be laid out in a virtualized system to optimize the
available technology.
© 2020 SCTE•ISBE and NCTA. All rights reserved. 10
The first decision for optimization is whether one instance of the vBNG will handle one service group or
many service groups. A single service group vBNG gives you the greatest control and isolation at the
expense of more wasted processing cycles, while a multiple service group vBNG gives you more efficient
processor utilization at the expense of more complex control and isolation.
The other area of opportunity is whether and how to separate the components of the vBNG to more
efficiently assign processing resources. Separating the access controller from the data forwarder is
attractive as the access controller and the data forwarder have very different functional and service
assurance metrics. This separation would allow for a considerable amount of processor utilization
optimization. Perhaps this would give us the ability to have the access controller live higher up in the
cloud. Another way to optimize the component separation is to divide the upstream and downstream data
planes. This would allow us to take advantage of inherent differences in upstream and downstream
utilization. The upstream data plane has significantly less usage, even with symmetric access
technologies, and can be multiplexed more effectively, while the downstream data plane has significantly
more usage and needs more network and processor resources to be assigned.
Details of these approaches are a subject of considerable discussion in and of themselves. Intel has
published an architectural study that dives deep into the factors of these decisions [3] that may be
interesting to the reader of this paper.
5. Conclusion
The protocols defined in the DOCSIS specifications have led us down a path that has centered our back
office and access networks around those protocols. This has been very good to us, but it is time to
integrate other access technologies into our portfolios. The NFV and SDN evolution gives us an
opportunity to refactor the way that we build and run our networks to support both the network of today
and the multi-technology network of tomorrow.
In light of this goal, this paper has described an access network abstraction which defines a clear
demarcation of system functions between the BSS and OSS, service activation, and network access. This
architecture should allow us to:
• Deploy new technology quickly.
• Provision access networks in a unified way.
• Have consistent services.
• Minimize testing.
• Enjoy one operational model.
• Evolve each component of our network without interfering with the others.
We must not only produce a network that solves the problems that we can foresee, but one that allows us
to continue to adapt well into the future.
Abbreviations
vBNG virtual broadband network gateway
MSO multiple system operator
NFV network function virtualization
SDN software defined networking
PON passive optical network
© 2020 SCTE•ISBE and NCTA. All rights reserved. 11
CMTS cable modem termination system
vCMTS virtual cable modem termination system
DOCSIS data over cable service interface specification
BSS business support system
OSS operational support system
DAA distributed access architecture
DPoE DOCSIS provisioning of EPON
vCM virtual cable modem
ENET ethernet
RPHY remote PHY
ROLT remote optical line terminator
SNMP simple network management protocol
IPDR IP data records
API application programming interface
YANG yet another next generation
OLT optical line terminator
ONU optical network unit
DSCP differentiated services code point
rSwitch Remote Switch or field deployed switch
SCTE Society of Cable Telecommunications Engineers
Bibliography & References
[1] SCTE paper “The Future of Operations: Building a Data-Driven Strategy”
[2] Virtual Provisioning Interfaces Technical Report - CableLabs
[3] https://www.intel.com/content/dam/www/public/us/en/documents/platform-briefs/broadbandnetwork-gateway-architecture-study.pdf
There is no such difference in BNG and vBNG , it’s depends on how you implementing . Here only the platform for vBNG (virtualized devices going to be used) is changed and some of the CLI’s . when i was working i have not seen so much differences .
---------
© 2020 SCTE•ISBE and NCTA. All rights reserved. 1
A Virtual Broadband Network Gateway (vBNG)
Approach for Cable Operators in a Distributed Access
Environment
A Technical Paper prepared for SCTE•ISBE by
Jason Combs
Principal Architect
Comcast
1800 Arch St Philadelphia, PA 19103
609-706-9190
jason_combs@cable.comcast.com
© 2020 SCTE•ISBE and NCTA. All rights reserved. 2
Table of Contents
Title Page Number
1. Introduction.......................................................................................................................................... 3
2. The challenges of today’s access network ......................................................................................... 3
3. A method of network abstraction......................................................................................................... 5
3.1. Service Activation Layer......................................................................................................... 6
3.2. The virtual Broadband Network Gateway structure ............................................................... 8
4. Advantages of an NFV and SDN approach compared to a traditional BNG ...................................... 9
5. Conclusion......................................................................................................................................... 10
Abbreviations .............................................................................................................................................. 10
Bibliography & References.......................................................................................................................... 11
List of Figures
Title Page Number
Figure 1 – Evolution of the Access Network ................................................................................................. 4
Figure 2 – Functional components of this network abstraction..................................................................... 6
Figure 3 – Interfaces and functions of the Service Activation Layer............................................................. 7
Figure 4 – vBNG structure (OLT example) ................................................................................................... 8
List of Tables
Title Page Number
NO TABLE OF FIGURES ENTRIES FOUND.
© 2020 SCTE•ISBE and NCTA. All rights reserved. 3
1. Introduction
For as long as the Multiple System Operator (MSO) community has built and operated networks, we have
been looking for better ways to segment it, and to optimize the work needed to update and maintain it. In
addition, serious efforts emerged over the last several years to add other access media to the mix, such as
passive optical networks (PONs) and wireless technologies. Among these efforts is network function
virtualization (NFV) and software defined networking (SDN), which have captured the attention of the
MSOs and of the networking world at large. How does the MSO community take advantage of these
concepts to fulfill both today’s needs as well as the desire for an easier, quicker deployment of access
network technology going forward into the future? In this paper, we will explore:
• Challenges faced by MSOs in deploying new types of access technologies alongside the
current (virtual/”v”) CMTS
• A method for abstracting service activation to allow for common control of dissimilar access
technologies
• A flexible virtual broadband network gateway (vBNG) structure that matches MSO service
formats to operate non-DOCSIS access technologies (e.g. PON)
• Advantages of this NFV and SDN approach compared to a traditional hardware BNG
2. The challenges of today’s access network
The traditional cable operator’s access network is centered around the DOCSIS technology that we all
know and love. The business support systems (BSS) and the operations support systems (OSS) that are
employed are equally centered around supporting the protocols defined by the DOCSIS protocols.
CableLabs and we, as a community, have done an excellent job of extending those systems to support our
business needs, as our customers and the Internet as a whole evolved from basic data services into voice,
IP video, and commercial services.
The focus on a single technology with a single provisioning and operating model led to development of
Cable Modem Termination Systems (CMTS) and Optical Line Terminators (OLT) that are fully
integrated, as shown in the blue and orange boxes in Figure 1. These systems are typically developed by a
single vendor to support all of the service, routing, reporting, and physical functions. The Distributed
Access Architecture (DAA) separated the physical generation of the signal, but otherwise remained as
integrated as the original CMTS systems. Likewise, the virtual CMTS (vCMTS) has given us a peek into
the future by allowing the CMTS functions to live in a server environment, with all of the technology
used to accomplish that, but still retains the unified structure seen in prior iterations of the CMTS.
© 2020 SCTE•ISBE and NCTA. All rights reserved. 4
Figure 1 – Evolution of the Access Network
The challenge with this integrated structure begins to clearly show itself once we consider providing our
services through other access technologies. The expansion into other access technologies is happening for
a number of reasons including demand for multi dwelling unit solutions, changes in physical construction
costs, and the desire to compete in the Wi-Fi and wireless arenas. Although more distinctly seen now,
these issues have been lurking in the shadows all along. The DOCSIS service, provisioning, and
operational models do not mesh well when combined with the wireless, fiber, and ethernet technologies
that allow us to expand our network in non-traditional directions. On the other side of the coin, the BSS
and OSS systems that have grown up in reaction to the DOCSIS architecture force us to attempt to have
other access technologies mimic that architecture to avoid major back office changes. The following
paragraphs provide a brief synopsis of five admittedly intertwined priorities that are difficult to achieve
with the current structure.
• Swift integration of new access technologies. Beyond the need to develop a technology for our
physical network, new technologies typically also come with a full system design and integration.
All of these system components require time to develop, and often duplicate the same functions
from other systems. Most introductions of new vendors cause us to start this cycle again,
representing a high barrier to entry and ultimately fewer options for technology partners.
• Consistent services provisioning. It is cumbersome to develop and maintain separate BSS
systems, in whole or in part, for every technology that we deploy. The problem is a compounding
one. It is a massive effort to deploy new authentication and service definition systems, and once
they exist, they are difficult to maintain while assuring that service definitions remain aligned
© 2020 SCTE•ISBE and NCTA. All rights reserved. 5
with the existing DOCSIS systems. The way around this problem is to create a translation system,
such as the virtual cable modem introduced by DOCSIS Provisioning of EPON (DPoE). This,
too, needs to be maintained and updated with the latest changes, and can easily fall behind.
Workaround remedies add time to any process and represent custom work for the MSO
community.
• Service consistency. DOCSIS provides a robust set of service features, which are implemented in
its service flows with extensive classifiers, subscriber management filters, and frame accounting
with Simple Network Management Protocol (SNMP) and IP detail records (IPDR). Other access
technologies have similarly robust features that are simply different from what we typically use.
Aligning these methods can cause hardware and feature control issues that limit our choices. The
worst-case scenario is the network could look and act differently for one customer than it does for
another.
• Testing velocity. Swift testing is an inherent challenge with any additional development. What
exacerbates it is the unnecessary replication of the same function within multiple systems. Rather
than testing the unique functions, much time is spent retesting different implementations of the
same function.
• Operational model differences. With different systems come different interpretations of
specifications and different interface models. This is aggravated by specifications created by
organizations with very different goals, that apply to other access technologies. They also create
additional work, to translate from one system to another.
3. A method of network abstraction
There is no simple or fast solution to the challenges stated in the previous section. A new system
organizational abstraction is needed to make significant progress in resolving these issues. The existing
system needs to be broken into distinct components that can evolve in isolation from each other. In kind,
these components need to be linked by extensible application programming interfaces (APIs) that can be
modified to meet the needs of the future. With this isolation and extensibility, we remove the need to
replicate functions that are common to all of the access technologies and give ourselves the flexibility to
integrate any technology quickly. Figure 2 below represents the proposed network abstraction.
© 2020 SCTE•ISBE and NCTA. All rights reserved. 6
Figure 2 – Functional components of this network abstraction
This architecture focuses on three major areas of providing services through a scaled access system:
The billing and provisioning systems manage the customer entitlements and interactions with us as cable
operators. It is necessary to break away from the tight DOCSIS integration that our back-office systems
are built on. Much of the goal of this architecture is to enable that transition. The change itself is a
massive amount of work that is not directly addressed within this paper.
The service activation layer receives the entitlements from the BSS and creates the detailed service
description for a particular customer device.
The vBNG implements the service description provided by the service activation layer and manages the
moment by moment experience of the customer. This layer can be broken down further, which we will
explore in the following sections. We can add a fourth area to this list of three areas to include the
operations and data gathering systems. This has been explored by prior papers in detail, for example, in
the SCTE paper “The Future of Operations: Building a Data-Driven Strategy” [1] and will not be
explored here.
3.1. Service Activation Layer
The service activation layer exists to create a means of defining the customer’s access network services
that is abstracted away from both the BSS system and the access technologies that those services ride on.
There are several aspects to this component that are necessary to be able to provide this function as
illustrated in Figure 3.
© 2020 SCTE•ISBE and NCTA. All rights reserved. 7
Figure 3 – Interfaces and functions of the Service Activation Layer
• Service Entitlement flexibility. Many access networks, such as DOCSIS, use a bottom up
provisioning methodology where the end device requests service. However, there are examples of
top down access networks, such as commercial ethernet and residential ethernet, where the end
device does not include this capability. It is important to have an API that allows for both
methods of entitlement and configuration.
• Unified Access Service Descriptors. These descriptors are imagined to be in the form of a YANG
data model to communicate the services to the vBNG deterministically. They would be formed
via a configuration generator that takes the access device type and model along with the
customer’s entitlements into account. With a common vBNG data plane and a desire to have
consistent services, it is imagined that the YANG model for the customer’s services would be
largely common between access types. The Virtual Provisioning Interfaces Technical Report [2]
produced by CableLabs has defined a YANG model that may be a good fit for this language.
• Access/Customer Premise specific configuration modifiers. While the majority of the service
definitions will be common, there will certainly be access-specific configurations that would be
of interest. For example, a PON system may want to be able to configure optical parameters that
do not apply to other access technologies. Access-specific extensions of the universal YANG
model would cover this case.
• Database of activated services. With millions of devices in our networks, it is often difficult to
have a definitive knowledge of the exact service configuration the customer device is operating
upon when a problem is discovered. The service activation layer should record the exact
configuration given for each device to aid in troubleshooting and to add traceability.
• Push/Pull of configuration. In the same vein as supporting both bottom up and top down
provisioning, this is the mechanism for providing the YANG model configuration to the vBNG.
This also enables the ability to change customer device configuration dynamically.
© 2020 SCTE•ISBE and NCTA. All rights reserved. 8
Introducing the service activation layer gives us several capabilities and advantages that help us overcome
the problems defined earlier in this paper.
• It abstracts billing and provisioning away from the configuration of the network.
• It presents a consistent service provisioning mechanism for all access networks and all
services running through them.
• It brings consistency to service definitions across all access technologies, making their
implementation also consistent, within the vBNG
• It eases the application of dynamic services to existing devices and allows for modification of
existing services.
3.2. The virtual Broadband Network Gateway structure
Many of the issues discussed here can be resolved with a proper vBNG implementation. There are a
number of options, in terms of how the vBNG can be laid out, and which components are included. Let us
start with a description of the basic components in this method.
Figure 4 – vBNG structure (OLT example)
Access controller. This sets up the access network itself and the services that flow through it. To
accomplish this task there are several steps that are necessary. A service configuration interpreter
translates the YANG model produced by the service activation layer into access-specific configurations
used by the vSubscriber data construct. The access manager, displayed as an “OLT” or “ONU Manager”
in the diagram, is responsible for configuring all remote access components. A service control API then
sends the necessary configuration information to the data forwarder, which is where components common
to all access networks are configured.
© 2020 SCTE•ISBE and NCTA. All rights reserved. 9
Data forwarder. This provides frame processing and basic subscriber services. Certain functions can be
enabled or disabled, such as a traffic manager, for access networks that do not have a built-in means of
doing so. On a per customer basis, features like subscriber management filtering and DSCP rewrite can
be enabled or disabled based on the services defined via the service activation layer. To aid in effective
use of network and processor resources, the data forwarder can be implemented as a single unit or can be
separated out for greater flexibility. The first logical separation is the network control, which includes the
functions necessary to connect to the MSO network as well as typical services such as DHCP relay,
routing protocols, and legal intercept controls. The upstream data plane is the next separation and
provides data forwarding services from the customer into the network. Upstream traffic typically has a
lower volume expectation. Finally, the downstream data plane provides data forwarding services from the
network to the customer. In this case, all access networks would utilize the traffic manager function to
shape traffic going downstream. Downstream traffic typically has a higher volume expectation.
These components give us several advantages, no matter how they are laid out in a virtualized system.
• The data forwarder includes common code for all access networks. This is a major facilitator of
service consistency, as all customers are served by the same implementation for many of
functions provided. From a development perspective this allows us to develop once but use the
code many times. Adding new routing protocols, for example, only requires the single
implementation to be tested. There is also no need to test the common code extensively when a
new access network is developed.
• The Service control API is well defined between the access controller and the data forwarder.
This allows for easy and unambiguous integration with new access controllers.
• New development for a new access technology is primarily limited to the access specific
functionality such as the access controller, the remote access element, and interoperability with
in-home equipment.
4. Advantages of an NFV and SDN approach compared to a traditional
BNG
The traditional BNG is the staple of many telecommunication companies’ network and has proven to be a
solid solution for their access needs. So, why not use the same thing? The answer lies in flexibility. Just
as with traditional CMTS deployments, a network operator must choose and size the BNG appropriately
for both their current and future needs. Inevitably, when the network capacity or business needs surpass
that BNG’s capabilities, the operator must upgrade or add more BNGs -- or worse, do both.
Flexibility and reuse are where NFV and SDN shine. This is exemplified by allowing the system to
expand functionality naturally into new access networks, while also allowing each of the components to
continue to evolve -- to remain the best they can be, without requiring that the entire system be recreated.
In terms of capacity, the system relies on generic processing hardware to do its job.
The first advantage with this approach is the ability to directly add capacity by adding more compute
power, without touching the rest of the system. Secondly, when using generic hardware, the system can
be laid out in different ways to fit the most effective technology, in terms of cost and efficiency.
There are several ways in which these components can be laid out in a virtualized system to optimize the
available technology.
© 2020 SCTE•ISBE and NCTA. All rights reserved. 10
The first decision for optimization is whether one instance of the vBNG will handle one service group or
many service groups. A single service group vBNG gives you the greatest control and isolation at the
expense of more wasted processing cycles, while a multiple service group vBNG gives you more efficient
processor utilization at the expense of more complex control and isolation.
The other area of opportunity is whether and how to separate the components of the vBNG to more
efficiently assign processing resources. Separating the access controller from the data forwarder is
attractive as the access controller and the data forwarder have very different functional and service
assurance metrics. This separation would allow for a considerable amount of processor utilization
optimization. Perhaps this would give us the ability to have the access controller live higher up in the
cloud. Another way to optimize the component separation is to divide the upstream and downstream data
planes. This would allow us to take advantage of inherent differences in upstream and downstream
utilization. The upstream data plane has significantly less usage, even with symmetric access
technologies, and can be multiplexed more effectively, while the downstream data plane has significantly
more usage and needs more network and processor resources to be assigned.
Details of these approaches are a subject of considerable discussion in and of themselves. Intel has
published an architectural study that dives deep into the factors of these decisions [3] that may be
interesting to the reader of this paper.
5. Conclusion
The protocols defined in the DOCSIS specifications have led us down a path that has centered our back
office and access networks around those protocols. This has been very good to us, but it is time to
integrate other access technologies into our portfolios. The NFV and SDN evolution gives us an
opportunity to refactor the way that we build and run our networks to support both the network of today
and the multi-technology network of tomorrow.
In light of this goal, this paper has described an access network abstraction which defines a clear
demarcation of system functions between the BSS and OSS, service activation, and network access. This
architecture should allow us to:
• Deploy new technology quickly.
• Provision access networks in a unified way.
• Have consistent services.
• Minimize testing.
• Enjoy one operational model.
• Evolve each component of our network without interfering with the others.
We must not only produce a network that solves the problems that we can foresee, but one that allows us
to continue to adapt well into the future.
Abbreviations
vBNG virtual broadband network gateway
MSO multiple system operator
NFV network function virtualization
SDN software defined networking
PON passive optical network
© 2020 SCTE•ISBE and NCTA. All rights reserved. 11
CMTS cable modem termination system
vCMTS virtual cable modem termination system
DOCSIS data over cable service interface specification
BSS business support system
OSS operational support system
DAA distributed access architecture
DPoE DOCSIS provisioning of EPON
vCM virtual cable modem
ENET ethernet
RPHY remote PHY
ROLT remote optical line terminator
SNMP simple network management protocol
IPDR IP data records
API application programming interface
YANG yet another next generation
OLT optical line terminator
ONU optical network unit
DSCP differentiated services code point
rSwitch Remote Switch or field deployed switch
SCTE Society of Cable Telecommunications Engineers
Bibliography & References
[1] SCTE paper “The Future of Operations: Building a Data-Driven Strategy”
[2] Virtual Provisioning Interfaces Technical Report - CableLabs
[3] https://www.intel.com/content/dam/www/public/us/en/documents/platform-briefs/broadbandnetwork-gateway-architecture-study.pdf
