In presentations at virtualization conferences, and in our discussions with operators and service providers, there remains a lot of confusion surrounding the terms ‘thick’ and ‘thin’ as they relate to customer premises equipment (CPE). This is because the terms are used interchangeably, to describe different market segments, the density of network functions as well as the nature of the CPE itself.
The roots of ‘thick’ and ‘thin’ comes from the term ‘thin client’; a popular reference to a lightweight computer or terminal that depends heavily on a server or server farm to deliver data processing and application support. This contrasts with the PC, which performs these roles independently, and was somewhat disparagingly referred to as a ‘fat client’, or, more neutrally, as a ‘thick client’.
This heritage is important as we look to provide a taxonomy of CPEs, which will hopefully aid our understanding of their respective roles in the delivery of virtualized network services.
Generically, CPE or ‘customer premises equipment’ refers to the equipment provided by a service provider that is then installed with its customers. Historically, CPE referred mainly to the supply of telephony equipment, but today the term encompasses a whole range of operator supplied equipment including routers, switches, voice gateways, set-top boxes as well as home networking adapters.
Thick CPE refers typically to a router or switch that provides network functions at the customer premises. There are now three main types:
- White-box CPE where the network functions are fully virtualized in software hosted on common off-the-shelf hardware, usually an X-86 appliance. These fully virtualized network functions are called VNFs (virtual network functions).
- Classical CPE, where the network functions are embedded in the networking appliance. Also called a monolithic appliance by the creators of software-defined networking, there is no external abstraction from the hardware components that support it. The network functions within this box are physical and thus called PNFs (physical network functions).
- Grey-box CPE, which is a mix of the two: some network functions are virtualized and fully abstracted from the hardware; others are not and remain PNFs (physical network functions), limiting flexibility.
The PNFs within a classical CPE or grey-box CPE are preferably managed in the same way as VNFs, i.e. with NETCONF, so as to facilitate the move to virtualization, nonetheless, the terms themselves don’t imply this.
Thin CPE refers to a router or switch that has little or no network functions. The problem occurs with what is implied by ‘little’. Here we can usefully draw on the original ‘thin client’ definition, which says that it provides the minimal set of functions required to operate as a terminal or client, i.e. a graphical user interface (GUI), like a web browser, together with associated access agents to enable the device to operate in a Cloud environment and support of its hardware capabilities: USB, keyboard, mouse, speakers, microphones, etc.
A thin CPE is similarly defined, it provides the minimal set of network connectivity functions for operating across a WAN: Ethernet/DSL ports, link management if resiliency is required, tunnelling mechanisms to transport data traffic, service assurance to monitor the performance of the CPE’s connectivity services.
Add anything else and the thin CPE starts to ‘thicken’. Examples include traffic generation, LAN management functions or WAN optimization functions.
Today’s evolving CPE market, driven particularly by the advent of network virtualization, has space for all of these different shades of CPE, and specialist vendors like OneAccess will supply what makes sense for the customer, in terms of economics, ease of service delivery and the customer’s chosen migration path to virtualization. Practically, this means the development of CPEs with joint CLI/NETCONF support, white-box CPEs that are both open (avoiding here the compromises of a grey-box) and fully abstracted in software, together with thin CPEs.
As always in a fragmenting marketplace, stakeholders are challenged to establish consistent terminology when describing emerging deployment models. The sooner we can establish industry-wide clarity in CPE architecture, the easier life will become for us all.
