Cable Architecture — 42
White Paper
Designing for the Microsoft® Windows® Operating Systems
Cable Architecture
Microsoft Technology for the Broadband Cable Industry — Draft Version: August 1999
Note: Microsoft is actively seeking feedback on the architecture for the Microsoft® Windows 2000 and Windows 98 operating systems as presented in this document. For comments or questions, please email:
This is a revision of a white paper first published at WinHEC 99.
Disclaimer and Copyright
Microsoft Disclaimer and Copyright: This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft Corporation may have patents or pending patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. The furnishing of this document does not give you any license to the patents, trademarks, copyrights, or other intellectual property rights except as expressly provided in any written license agreement from Microsoft Corporation.
Microsoft does not make any representation or warranty regarding specifications in this document or any product or item developed based on these specifications. Microsoft disclaims all express and implied warranties, including but not limited to the implied warranties or merchantability, fitness for a particular purpose and freedom from infringement. Without limiting the generality of the foregoing, Microsoft does not make any warranty of any kind that any item developed based on these specifications, or any portion of a specification, will not infringe any copyright, patent, trade secret or other intellectual property right of any person or entity in any country. It is your responsibility to seek licenses for such intellectual property rights where appropriate. Microsoft shall not be liable for any damages arising out of or in connection with the use of these specifications, including liability for lost profit, business interruption, or any other damages whatsoever. Some states do not allow the exclusion or limitation of liability or consequential or incidental damages; the above limitation may not apply to you.
Microsoft , DirectX, MSDOS, Win32, Windows, and Windows NT are registered trademarks of Microsoft Corporation. Other product and company names mentioned herein may be the trademarks of their respective owners.
© 1999 Microsoft Corporation. All rights reserved.
Contents
Introduction 3
Reference Model 4
Entities 4
Network Topology 4
Supporting DOCSIS Networks 7
DOCSIS Standard 7
DOCSIS Architecture 7
Cable Modem Initialization Process 8
DOCSIS Server Components in Windows 2000 9
Other Networking Services in Windows 2000 10
Provisioning of Data Services over Cable 10
Existing Provisioning System 11
Basic Self-Provisioning Process 12
Self-Provisioning and the OEM 14
User Logon Architecture for Cable Networks 24
PPTP/IP over Cable 24
PPTP Overview 24
Creating User Sessions Using PPTP in Cable Networks 25
Home Networking - Internet Connection Sharing 26
Authentication, Encryption, and Filtering of PPTP Sessions 30
Supporting Open Access 31
Telecommuting 32
Infrastructure Services in Windows 2000 33
Load Balancing and Clustering 33
Directory Services 39
Remote NDIS 43
Quality of Service 45
QoS Overview 45
Windows 2000 QoS Components 50
Windows 98 QoS Components 52
For More Information 53
Acronyms 53
Introduction
This document describes the work being done at Microsoft to define an end-to-end architecture for data services over cable networks. Using this architecture, Microsoft will provide the network platforms and applications needed to deliver data, voice, and video services over IP-enabled cable networks.
The next wave of transformation in residential Internet access will be broadband access using technologies such as cable modem and xDSL. Broadband access will provide the bandwidth needed to deliver services such as video on demand, virtual private networking, and voice services. To provide broadband access, network service providers will need to upgrade their network infrastructure, first to enable high-speed access and second to add quality-of-service in their networks and provide fine-grained resource management.
Customers, in large numbers, will demand easier access, “always on” connections, and single login to multiple online products and emerging applications not in existence today. The infrastructure deployed today must enable the services of tomorrow. The delivery of these services will require integrated solutions.
Network operators will also need integrated solutions that cover all the pieces of the puzzle from the backbone network down to the customer premise. They must have solutions that inherently interconnect each service being offered, and allow for new standards as they evolve.
The cable architecture presented in this white paper is designed to focus on several key objectives:
· End–to-end: The lack of integrated solutions built upon an end-to-end network architecture has hindered the deployment of broadband services. Most solutions have been built using equipment and technologies from individual equipment providers, focused on separate portions of the service. Network operators currently must contend with different standards, administration interfaces, and topologies. This piecemeal approach raises the cost of deployment, operation, and management of broadband access. The goal of the Microsoft cable architecture for data services is to tackle the end-to-end problem space and offer solutions across the board.
· Customer focused: The architecture must provide cable providers the platform for value added services and must offer end users a plug-and –play, user friendly and value-rich environment.
· Standard-based: The solutions presented in this paper are based on standards defined by the IP community (IETF, IEEE, ITU) and by the cable community (DOCSIS).
· Adaptable: Microsoft will update the end-to-end architecture as existing standards evolve and new standards are defined.
The white paper is divided into several sections:
· “Reference Model” describes the reference model the architecture is based on.
· “Supporting DOCSIS Networks” presents an overview of DOCSIS and describes how Microsoft supports this standard.
· “Provisioning of Data Services over Cable” explains how OEMs can leverage the ISP signup infrastructure in the new generation of Windows 98 clients to help users sign up for broadband cable ISP services.
· “User Logon Architecture for Cable Networks” defines a logon mechanism for cable networks.
· “Infrastructure Services in Windows 2000” presents several key networking components of the Microsoft Windows 2000 operating system, and their applicability to cable networks.
· “Quality of Service” describes Microsoft Quality of Service components and their use in cable networks.
Reference Model
This section describes the reference model used to define the architecture presented in this white paper.
Entities
In the U.S., cable companies (referred to as MSOs in this paper) offer data services over cable directly. However, the networking components are actually provided by two different entities: the MSO and the ISP.
The MSO provides access to the end user and controls the cable plant. It deploys and manages the physical infrastructure that composes the last mile. Providing the capital and knowledge needed to upgrade the cable plant for two-way traffic is one of the main tasks of the MSO. The MSO is also the main entity the customers interface with for service provisioning and customer service.
The ISP, on the other hand, provides the knowledge base and capital investment required to create a nationwide IP network capable of delivering IP-based services to the end users. The two best-known U.S. ISPs focused on supporting the cable industry are @Home and RoadRunner.
From a networking point of view, data-over-cable networks throughout the world share many common characteristics. However, the business and marketing models governing the services may differ greatly. In the U.S., there is a 1:1 relationship between the ISP and the MSO. In Singapore, the government has opened the market to multiple ISPs but basic cable services are provided by a single MSO. Thus in Singapore, the MSO:ISP relationship is 1:n.
Network Topology
Cable networks supporting IP-based data services can be divided into multiple tiers. Depending on the deployment, the overall network can consist of a two or three-tiered architecture. This document describes the components making up a three-tiered architecture.
National Network. The nationwide network consists of a set of regions, typically grouped by state (see Figure 3). Each region is composed of the cities in which MSOs are offering data services over cable. Within each region, one city hosts a RDC (Regional Data Center). Traffic between all other cities and the national backbone is aggregated through the RDC. In most cases, the RDC will also provide connectivity to the Internet through dedicated links to one or more ISPs.
Regional Network. Cities within a region are linked to each other through a combination of fiber rings and point-to-point links (see Figure 4).
Distribution Network. Distribution hubs, one of which is a super-hub and the rest of which are basic hubs serve Service areas within a city.
Most of the distribution hubs are basic hubs (see Figure 1). They contain one or more CMTS (Cable Modem Termination System) and either a switch or a router with redundant connections to the super hub to provide a more reliable design.
Figure 1. Basic Distribution Hub
The super-hub aggregates traffic from all the hubs when the end destination is outside the city limits. Some of the control plane components located in the RDC are typically distributed to each city’s super hub (see Figure 2).
Figure 2. Super Hub
Regional Data Center. The Regional Data Center (RDC, see Figure 4) aggregates the traffic from all the cities in the region, provides connectivity to the Internet and to the national backbone, and contains most of the server farms. Most RDCs include a set of servers and databases running the applications offered by the service provider (mail, web hosting, news, chat, streaming media, etc.). They also host servers needed for Internet connectivity and management (DNS, proxy, caching, SNMP, billing, etc.).
Figure 3: Nationwide ISP Network
Figure 4. Regional Data Center
Supporting DOCSIS Networks
DOCSIS Standard
DOCSIS (Data Over Cable Service Interface Specifications) is a set of technical documents written by the cable community to standardize the architecture for IP-based services over cable networks. DOCSIS was initiated by CableLabs, and has since been approved by ANSI (American National Standards Institute) and by the ITU (International Telecommunications Union).
Version 1.0 of the standard concentrates on defining the MAC and IP layer components required for a Cable Modem (CM) to initialize with its Cable Modem Termination System (CMTS) and focuses mostly on best effort services and class of service (CoS) differentiation. Version 1.1 of the standard adds support for Quality of Service (QoS) at the MAC layer between the CM and the CMTS. Version 1.0-compliant CMs and CMTSs are being deployed today. Devices compliant with Version 1.1 are expected to be deployed mid to end 1999.
DOCSIS Architecture
Figure 5: End-to-End Protocol Stacks
The DOCSIS architecture model is quite simple. The PC generates IP over Ethernet packets. The CM acts as a bridge and forwards the Ethernet frames to the network. DOCSIS specifies a new MAC layer from the CM to the CMTS in the upstream direction. The Ethernet frame is encapsulated by the CM in a DOCSIS MAC frame and sent to the CMTS. The CMTS can be either a router or a bridge. In either case, the CMTS de-encapsulates the Ethernet frame and forwards it upstream.
Any communication between two homes must pass though the CMTS. Thus, an Ethernet LAN is created between all the homes connected to the same CMTS. Refer to Figure 5 for an illustration of the protocol stacks. In order to enable privacy on each connection to a home, DOCSIS defines a security mechanism called baseline privacy (BPI). BPI specifies a way to encrypt the data from the CM to the CMTS. DOCSIS 1.1 will include a revised version of BPI. BPI+ adds authentication of the CM to the CMTS and vice versa.
One of the main components of DOCSIS is its definition of a standard mechanism to boot up a CM without user intervention (refer to next section, “Cable Modem Initialization Process,” for more details). Although DOCSIS officially supports host-based modems, most of the work up to now has been done with external modems in mind. DOCSIS doesn’t define how clients attached to the CM should boot and be configured.
Cable Modem Initialization Process
Since the boot process used by the CM influences several design decisions made in the architecture presented in this white paper, this review of DOCSIS concludes with an explanation of how the CM boots up.
The relationship between a CM and its CMTS is a master-slave relationship. The CMTS controls the bandwidth allocation on the upstream channel. The CMTS sends on the downstream channel bandwidth allocation messages called Upstream Bandwidth Allocation maps (referred to as MAPs) which define how the time units (mini-slots) on the upstream channel must be used.
A MAP can segment the time interval into slots dedicated to a CM, contention time slots any CM can use to send data, or slots used for the CMs to transmit control messages back to the CMTS. The connection between the CM and the CMTS is called a SID (service ID). In DOCSIS 1.0, the CM has one SID that is created during initialization. In v1.1, a CM may have multiple SIDs. Each SID can have a specific QoS and can be created at any time, either by the CM or by the CMTS.
DOCSIS defines an eight-step initialization process:
1. Scan for downstream channel and establish synchronization with the CMTS: The CM scans the downstream frequency band for a valid 6-MHz channel. Upon finding one, it synchronizes the QAM (Quadrature Amplitude Modulation) symbol timing, the FEC (Forward Error Control) framing, and the MPEG (Moving Picture Experts Group) packetization. The CM is synchronized on the downstream channel when it can recognize SYNC (Synchronization) MAC management message from the CMTS.
2. Obtain upstream channel transmission parameters: After synchronization, the CM waits for a UCD (Upstream Channel Descriptor) message from the CMTS. The UCDs describe the channel characteristics of the upstream channels. The CM must wait until it receives a UCD for a channel it can use. When received, it extracts the upstream parameters and waits for a SYNC message from the CMTS. The SYNC will be used to obtain the timing reference for the channel. The CM waits for a MAP that describes the time allocation on the upstream channel it selected. When it finds one with some time dedicated to maintenance, the CM starts the ranging process.