6 Focus on DOCSIS RFI

This section discusses open access provisioning techniques using DOCSIS RFI based cable modem systems. The arrangement of this section is based on the ISO networking layer, starting with the physical RF layer up through applications.

6.1 Open Access: Layer 1 — Physical

In the DOCSIS RFI world, the physical layer of the networking stack is provided using RF channels that operate within the RF spectral bandwidth of a cable television network. In the downstream direction (head end transmitter to subscriber receiver) the RF channels are compatible with existing analog modulated television channels. The high-speed data channels are digitally modulated, are 6 MHz wide, and have a raw data carry capacity of approximately 30 MBPS using 64 Quadrature Area Modulation (64 QAM) (with an option to use 40 MBPS using 256 QAM modulation in CATV plants that have a cleaner downstream noise environment).

A high-speed digital data channel uses the same digital modulation standard as used for digital television; i.e. MPEG encoding. However, the lower layer of MPEG, called the MPEG Transport Stream allows for the digital data to be typed; video has one type, DOCSIS data has another type. The amount of available downstream RF spectrum available to all services (analog video, digital video, data, and others) varies from system to system and cable operator to cable operator. There is no one standard configuration or topology that is followed.

In modern systems, we typically see new deployments and upgraded system support roughly 750 MHz to 860 MHz of downstream spectrum, which in turn is subdivided into 6 MHz television channels. Some cable plants are already at capacity for television distribution, leaving at most one channel available for digital data.In the best cases, one or two digital data channels can live in the roll off region at the high end of the plant's operating bandwidth. Digital data is less sensitive in the roll off and can provide viable service. However, there is precious little available room on at capacity plants. Some cable operators have many tens of MHz available in the downstream and could potentially support multiple downstream high-speed data RF channels. However, this ability is not universal.

In the upstream direction (subscriber transmitter to head-end receiver), the allocated spectrum is from 5 MHz to 42 MHz (sometimes less than 42 MHz). The selection of 5 to 42 MHz is fraught with many problems due to ingress noise impairments from outside of the cable plant. Unfortunately, this RF spectrum is dirty, noise-wise, and presents a somewhat arduous environment for digitally modulated signals. As such, a little less than 1/2 the band is mostly unusable (except on very clean cable plants), leaving about 15-18 MHz of spectrum for signals. Due to the inherent noise, the type of modulation used for upstream communications is less dense for robustness reasons. In addition, RF channels are smaller in spectral width.

In DOCSIS, the RF spectral width of an upstream data channel can be anywhere from 200 kHz to 3.2 MHz, depending on configuration. This configuration is done at deployment time.

A DOCSIS Version 1.0 and Version 1.1 channel will operate at approximately either 2.5 MBPS raw or 5.0 MBPS raw on most plants. In "cleaner" plants, the upstream capacity can be doubled per channel with a maximum of 10 MBPS in 3.2 MHz. Note that the available RF spectrum in cable plants is highly asymmetric, with potentially up to ten times more bandwidth in the downstream direction. This has the unfortunate effect of running out of upstream bandwidth for high-speed data services before exhausting potential downstream bandwidth for high-speed data channels. When a DOCSIS Cable Modem Termination System (CMTS) is installed in a head-end, one downstream channel is a configured, along with one or more upstream channel. Specific configurations, number of channels, and placement of RF channels is done at installation time.

Open access at Layer 1 means that for each service provider wanting access to the cable network, a separate CMTS and set of downstream and upstream RF channels must be allocated to that service provider. This approach does not work because:

1) There is insufficient RF bandwidth down-stream or upstream to create a single high-speed data service let alone multiple, for varying numbers of providers;

2) By FCC regulations cable operators must control (operate) and manage all RF transmitters attached to the cable plant so that the plant does not inadvertently radiate unwanted signals into the community. This means that all CMTS devices must be managed and operated by the cable operator. The CMTS design and requirements do not easily permit the CMTS's operation to be completely divorced from the service provider using the equipment.

Observation:

Open access at Layer 1 is not workable.

6.2 Open Access: Layer 2 — Data Link / Media Access Control Protocol

Layer 2 is called the Data Link layer and supports a variety of data link protocols: Ethernet and the DOCSIS MAC are in this layer 1.

In DOCSIS RFI Version 1.0 this layer provides an Ethernet-frame-based access protocol, mediated by the DOCSIS MAC. In comparison, in DSL services, ATM also lives at this layer between the CMTS and all the cable modems is that of a single large Ethernet based LAN (a switched/bridged large Ethernet address space supporting a single broadcast domain).

The bandwidth management practice of DOCSIS Version 1.0 systems is that of a best effort system. There is little to no bandwidth allocation management, except by vendor initiative. There is no real QoS management to differentiate services: e.g. packet data from packet voice.

DOCSIS Version 1.1 adds several important elements which can be used as foundations for open access (although open access did not drive their existence): packet classification, QoS support, multiple queues/services per cable modem, better support for multicast, and recognition of IEEE 802.1/p frame tagging: Virtual LAN (VLAN) tag and a priority tag.

DOCSIS V1.1 efforts are focused on supporting packet voice with packet data services. DOCSIS Version 1.0 provides for an ATM cell as a MAC data packet type. However, neither V1.0 or V1.1 make use of ATM cells nor are there any requirements presented in the specifications beyond support the packet type flag. The DOCSIS RFI was not designed to support ATM service classes; combinations of bandwidth manager and QoS control (delay, jitter, cell loss). In addition, there is no support for any services over ATM, for example, Ethernet or Point-to-Point Protocol (PPP) over ATM. The use of the ATM packet type and the limited support was left for a placeholder for the future. There is no apparent support by any vendor for ATM.

Review of the ideal open access requirements and their support by the DOCSIS RFI specification:

• R1: Provider Selection: Multiplexing through the Layer 2 space would allow multiple service providers access via shared downstream and upstream data channels. The multiplexing ability at Layer 2 is limited and can only be accomplished using the IEEE 802.1p VLAN tagging or by exploiting the enhanced multiplexing of ATM. DOCSIS Version 1.1 recognizes the IEEE 802.1p tagging, but omits any specifications or requirements for support the VLAN operations in the cable modem or the CMTS. To date, there has been some interest in exploiting only the priority tag field that is part of IEEE 802.1p to aid in packet classification and QoS support. Therefore, initial DOCSIS V1.1 cable modems will not support VLAN tag processing as a standard. VLAN tagging support would allow an Ethernet frame to be tagged and switched accordingly. This has exploitation potential of creating either a VLAN per service provider, with all common cable modems sharing the same tag, or for creating an ATM virtual circuit equivalent in the Ethernet frame allowing cable modems to directly/receive frames from a single provider. Note that the IEEE 802.1p VLAN tagging support up to 2048 values, which presents aggregation, scaling, pro-visioning, and labeling challenges when put into practical use. Efficient processing of Ethernet frame tagging may require hardware enhancements for acceptable packet throughput performance. Leveraging DOCSIS ATM cell transport support would remedy the multiplexing scale issue to be equivalent with DSL multiplexing capability. As mentioned, there are no requirements in DOCSIS for any services over ATM transport, leaving it vendor dependent at this time.
  
  
• R2: Multiple Providers: The DOCSIS architecture is a single provider service at Layer 2. With IEEE 802.1p extensions, it would be possible to extend to multiple service providers, but that would likely exhaust the VLAN tagging space quickly. Leveraging DOCSIS ATM cell transport support would remedy this but again, there is no requirements support in DOCSIS for any services over the ATM transport, leaving it vendor dependent at this time.
  
  
• R3: Ability to Provide: The DOCSIS CMTS would need to be able to provision and switch based on a Layer 2 tag between its WAN interface and all the cable modems the CMTS supports (1K to 3K cable modems). Service providers could be connected to individual subscriber cable modems or connected to groups of cable modems within the limits of the IEEE 802.1p tagging. However, given the 2K VLAN tag identifier space, the service providers equipment would need to be collocated near a CMTS if the number of subscribers for that provider gets large. An ATM based approached provides more multiplexing address space and would allow service providers to be connected with individual subscribers in just about any configuration. There have been no requirements for CMTS's to support tagging or ATM for service provider separation.
  
  
• R4 through R7: Bandwidth Allocation, Quality of Service, Subscriber Containment, and Provider Containment: The additional facilities in DOCSIS Version 1.1 support these needs from a Layer 2 protocol and management standpoint. Actual support would vary with different vendor implementations.
  
  
• R8: Link Privacy: DOCSIS supports link encryption.
  
  
• R9: Content Preservation: In DOCSIS RFI V1.0 and V1.1, Ethernet frames (Layer 2 packets) are not altered by the DOCSIS MAC in exchanges between the cable modem and the CMTS. If the cable modem or the CMTS embody a Layer 3 IP routing facility (or similar facility) based on vendor value added the Ethernet frames exchanged will be altered or discarded but the Ethernet data, the user data contained within the Ethernet packet is not altered. This data is typically an IP packet. These operations are normal for Ethernet switches and IP routers. The subscriber data contained within the IP packet is unaltered, however the IP packet header may undergo expected changes as per IP standards and standards for routers and gateways. With the Layer 2 Ethernet tagging approach, IEEE 802.1p allows for Ethernet headers to be extended with tagging information. The operation of inserting, altering, or removing a tag would change the subscribers Ethernet packet, but would do so according to standards. With a Layer 2 ATM approach, the Ethernet packet could be exchanged unaltered between the subscribers cable modem and the service provider. Note that there are many variations of approaches for Layer 2 multiplexing, some of which would preserve the subscriber's Layer 2 packet completely, others that would modify the packet according to defined standards and procedures. In either scenario with Layer 2 processing, the subscriber's IP packet would remain unaltered.

• R10: Provider Address Management: For Layer 2 Ethernet addresses, the standards dictate that the vendor build a MAC hardware address into each Ethernet controller. Service providers do not manage or administrate Layer 2 Ethernet addresses. Internet Protocols have been designed for vendor assignment of Layer 2 Ethernet addresses. ATM addresses, e.g. Virtual Path Identifiers (VPI's) and Virtual Circuit Identifiers (VCI's) are managed over each segment of the ATM path; e.g. between ATM switches. ATM addressing does not require that a service provider be in control of all VPI/VCI assignments between it and the subscriber - only that there is an end-to-end connection established between subscriber and provider.
  
  
• R11: Provider Subscriber Management: There are no provisions in the DOCSIS architecture for the cable modem Layer 2 service to be managed by anyone other than the single ISP.
  
  
• R12: IP Dial Tone Service: IP dial tone is independent of Layer 2 service.

Observations:

• DOCSIS Version 1.0 cable modems do not provide sufficient support for ideal open access provisioning at Layer 2.
• DOCSIS Version 1.1 does provide additional support that can be exploited for ideal open access at Layer 2 provided that the specification is expanded and enhanced. It is not clear that Layer 2 Ethernet tagging solutions would scale as needed to support numerous service providers and numerous subscribers. ATM cell transport is the most flexible method, as demonstrated by DSL services. However, while ATM cell transport is provided in DOCSIS, there is no support for ATM networking, defined services, nor are there specifications and requirements at this time for its use. In addition, DOCSIS was not optimized for ATM networking. The issues at the CMTS are unexplored at this time. Without specification support, specific functions would be vendor dependent.
• DOCSIS Version 1.1 modems deployed prior to open access support may need to be replaced; i.e. they may not be simply software upgrade-able to an open access modem
• It would be possible for an open access Ethernet tag processing CMTS to simultaneously sup-port open access enabled and non-open access modems. The caveat being that the non-enabled modems could continue to interoperate only with the incumbent Layer 2 provider.

6.3 Open Access: Layer 3 — Network: Internet Protocol Techniques

Layer 3 is the called the Networking Layer and supports the Internet Protocol (IP) and the Address Resolution Protocol (ARP). The DOCSIS RFI system has been optimized for the transport of IP packets. DOCSIS is principally a Layer 1 and Layer 2 service. The specifications call for rich assortment of Ethernet, IP, TCP and UDP packet filtering, making the DOCSIS cable modem aware of Layer 3 and Layer 4 packets. In DOCSIS RFI V1.0, these filters are used principally to provision a given cable modem for packet access rights into the network. DOCSIS RFI V1.1 adds additional filtering, including packet classification filters that are essential for QoS sup-port. The cable operator and/or service provider control these filters in each cable modem.

In other words, a DOCSIS RFI V1.0 and V1.1 cable modem is a Layer 2 switched Ethernet service with Layer 3 and Layer 4 packet filtering awareness. The specification stops here. However, different vendors will augment their cable modem's functionality with one or more Layer 3 services, such as IP routing, specialized routing, tunneling, Virtual Private Networking (VPN), Point to Point Protocol (PPP), and applications services, such as Voice over IP (VoIP).

Recall that the DOCSIS RFI creates a switched Ethernet service supporting a single Ethernet segment at Layer 2 and essentially a single large IP subnetwork at Layer 3 with a single provider administrating IP addresses. There are no facilities in the specifications for providing open access provisioning; i.e. multiple Ethernet segments, multiple IP subnetworks, or multiple address administration. There are Layer 3 open access solutions that have varying degrees of meeting the ideal requirements. Some of these solutions are already being used by a few operators to provide open access support.

There are two general classes of Layer 3 solutions: specialized IP routing (forwarding) and tunneling. Specialized IP routing encompasses known techniques such as source-address based routing, proxy ARP, and others. For source-addressed based routing, the cable operator administrates IP addresses for subscriber's home computing equipment, but also maintains special source based routes for each subscriber, routing packets to/from their assigned home IP address(es) to their designated ISP. Additional home IP address assignments (e.g. for multiple personal computers) are taken from the same service provider address space. A large IP address space is subnetworked into smaller sized IP address space allocations, where each allocation is dedicated to a specific ISP. Backend routing in the service provider's network routes packets from the home to the ISP via the source address, rather than the traditional destination address.

Supporting source-addressed based routing in the DOCSIS CMTS and the cable modem is transparent if their vendor has provided a Layer 2 service only - the CMTS doesn't see Layer 3 routing. In general, Layer 3 routing techniques are essentially transparent to Layer 2 devices, even with sophisticated DOCSIS packet filtering. If the CMTS or cable modem support any Layer 3 routing intelligence however, then that vendor's products must be either source-addressed base routing aware as shipped, or must be upgraded to be aware. This may or may not involve a hardware upgrade and/or replacement. DOCSIS QoS for subscriber services/applications is possible; QoS can still be achieved over the CATV network. In the cable operator's backend network, QoS is determined by vendor support in the varying equipment. Any vendor support for specialized routing is outside the scope of the current DOCSIS specifications.

Note that for specialized routing, the cable operator had to design and select appropriate IP routing technology that supports their deployment model. Currently deployed backend technology may not directly support specialized routing for open access. In addition, supporting multiple service providers via the same cable modem is problematic for specialized routing techniques, as the cable modem must support multiple IP subnetworks; usually they support one IP subnetwork.

It is technically possible to implement support for multiple IP subnetworks in the cable modem, if so required by an updated specification. Proxy ARP, or proxy Address Resolution Protocol, can be used by either the cable modem, CMTS, and/or head end router to preferentially re-route IP packets to a preferred router port (provider) based on Ethernet MAC address, IP source or destination address, or other mechanisms. The effect would be to transparently steer IP and ARP implementations to support semi-intelligent service provider provisioning. Support for this type of provisioning support could impact the cable modem, CMTS, or vendor head end router, dependent on vendor implementation. For example, a cable modem with IP router functionality may be more effected than a cable modem Ethernet bridge. It is not clear that these mechanisms can provide differentiated services for QoS or multiple service providers provisioning in the cable modem. More study is needed in this area to explore capabilities.

Note that at this time, there are existence proofs of specialized routing being used to provide access from a subscriber to a single ISP of their choice.

Knology is exploiting source-address based routing techniques (and likely other supplemental techniques) to connect subscribers with either Mindspring or other ISP's. Sufficient details on the Knology solution were not obtained in time for completing this white paper, however, the system operates with specialized routers at the head end and possibly with customized software in the cable modems. It is believed their source-addressed based routing approach can be wrapped around any cable modem system to produce a workable, but less than the ideal, open access provisioning system. Their solution may be transportable to other cable operators. Tunneling, as used in this paper, is a mechanism to tunnel IP packets through another protocol such as IP, PPP 1, Point-to-Point Tunneling Protocol (PPTP), Layer 2 Tunneling Protocol (L2TP), or IP Security (IPSEC) for Virtual Private Networking (VPN) support. With the general form of tunneling, the IP address of the end of the tunnel within the DOCSIS cable modem is administrated by the cable service provider, while the IP addresses that flow through the tunnel are administrated by the service provider. This model assumes that for each service, the cable modem would create a tunnel between itself and a remote access server maintained by the service provider. This tunnel would run transparently through the CMTS and any intervening routing and switching equipment until reaching the service provider. The cable modem would be aware of what IP addresses assigned should be moved through which tunnel. Technically, it is possible for a single cable modem to support multiple tunnel endpoints by leveraging an extension of its DOCSIS packet classification filters. This also allows voice traffic to be segregated into a different tunnel than other QoS traffic, for example. There are several different tunneling protocols, each with their own distinctions. Tunneling has the one undesirable effect of forcing all tunneled packets to have the same QoS, requiring different tunnels to be established for different QoS needs even if the end points of the tunnels are to the same service provider. DOCSIS does not specify any requirements for tunneling in the cable modem, leaving everything to vendor value added support.

The best implementation would be for the cable modem to be the endpoint of the tunnels because the cable modem has direct knowledge of QoS requirements and packet classifications to support QoS. In addition, tunneling itself and tunneling with encryption require more processing power in the cable modem than with the base DOCSIS system suggesting that the cable modem would have to be replaced to support multiple service provider provisioning via tunnels.

Use of VPN technology is becoming increasingly more popular for telecommuting scenarios as a work at home employee can benefit from high-speed access over to Internet to their corporate VPN firewall. In these cases, corporate MIS departments manage the any security configurations (cryptographic keys, logins, passwords) and local IP address assignments. If exploited beyond corporate telecommuting, VPN and/or other cryptographic authorization techniques can be used for access to service providers. This enhanced level of exploitation would require software and hardware processing beyond that of the DOCSIS specification. Note at this time that VPN facilities are often being deployed with software in the personal computing equipment or via specialized appliances that are placed between the subscriber computing equipment and the cable modem. It is nature in the future for external VPN support to migrate into the broadband access mediation device, e.g. the cable modem.

At this time, there is no mandatory or suggested implementation of a Layer 3 IP signaling protocol that could be used to communicate with the DOCSIS system. Hence, QoS interaction between the DOCSIS system elements (CMTS and cable modem) and other routers in the network is, at best, left up to individual vendors. The other CableLabs' project PacketCable is focusing on packet voice and video over cable data systems, with specific focus on DOCSIS RFI Version 1.1 implementations. The PacketCable effort is driving for QoS signaling protocols for use in voice call set up and tear down. It is possible; this can be exploited in the future for Layer 3 open access provisioning implementations. There is also the belief that some vendors will be implementing the IETF Reservation Protocol (RSVP) in their CMTS, allowing QoS signaling exchanges with other RSVP aware routers. It is too soon to tell precisely where all the efforts are headed however; there will be some signaling protocol available in the future to interconnect the CMTS with the backend network in a meaningful QoS manner. Note that requirements for signaling will likely emerge first from a PacketCable specification requirement and not directly from a future DOCSIS RFI requirement.

Reviewing Layer 3 Service Provider Provisioning against the ideals:

• R1: Service Provide Selection: Both source-address based and tunneling mechanisms provide a method of allowing the subscriber to be connected to a service provider of their choice. DOCSIS does not specify either mechanism.
• R2: Multiple Providers: With the current DOCSIS specification, source-addressed based routing appears to suited to provisioning to a single service provider. Software and hardware enhancements would likely be needed to support multiple service providers via a single cable modem. Tunneling could support multiple providers and ability to differentiate/route different services to difference providers; e.g. packet voice to a voice provider, Internet access to an ISP. Tunneling must be done via vendor software or hardware cable modem extensions or external box(es).
• R3: Ability to Provide: Source-address based routing must be done in conjunction with cable operator and/or service provider administrating IP addresses for the cable network. Tunneling approaches without QoS support are independent of cable data IP address administration. QoS aware tunneling must be done in conjunction with the cable operator, CMTS, and cable modem management. Technically, either solution is workable to different degrees of meeting the ideal.
• R4: Bandwidth Allocation: This feature falls out directly when dynamic QoS and signaling are universally supported and coupled to the DOCSIS Layer 2 facilities. Before that time, any bandwidth allocation support, dynamic or static, will need to come from vendor value added implementations.
• R5: Quality of Service: Without QoS signaling, Layer 3 approaches require static QoS provisioning of the CMTS and/or cable modem as required and as provided for by individual vendors. At some point in the future, QoS signaling will be available for IP and will likely be implemented in CMTS and/or cable modems as a requirement for PacketCable packet voice services. At that time, QoS signaling support would be in place for open access provisioning. In some cases, different vendors may have provided sufficient management and control capability to allow some QoS to be statically provisioned.
• R6: Subscriber Containment: Relies directly on DOCSIS RFI Layer 2 facilities and the CMTS's ability to manage cable modem bandwidth appropriately for a subscriber's access to the network.
• R7: Provider Containment: At Layer 3, either the CMTS will need to be upgraded both with software and possible new hardware to manage downstream and/or upstream bandwidth per service provider. In absence or in addition to CMTS functionality, provider containment would be per-formed where the service provider connects with the cable operator's backend network.
• R8: Link Encryption: Not an issue at Layer 3; except to mention that Layer 3 packets will be transparently encrypted on a per cable modem basis over the DOCSIS RF channels.
• R9: Content Preservation: Specialized routing technique will alter the headers of IP packets that traverse the cable operators network between the cable modem and the service provider. Tunneling approaches preserve the IP packet header that was placed into the tunnel at the cable modem. When open access is provided at Layer 2, subscriber data contained within the IP packet is unaltered, however the IP packet header may undergo expected changes as per IP standards and standards for routers and gateways.
• R10: Provider Address Management: Specialized routing techniques require that the cable operator and the ISP managing the CMTS and cable modems control the IP address space for cable modems and subscriber's personal computer equipment. For tunneling techniques, the subscriber side tunnel endpoint address is in a space administrated by cable operator and/or associated cable ISP, the actually addresses that flow through the tunnel are management by the service provider to which the tunnel is connected on the backend side of the network.
• R11: Provider Subscriber Management: There are no provisions in the DOCSIS architecture for the cable modem Layer 3 service to be managed by anyone other than the single ISP.
• R12: IP Dial Tone Service: There are no provisions in the DOCSIS RFI specifications for altering IP packets in general. However, QoS requirements and packet classification at the CMTS and cable modem may require that certain fields of the IP header might be altered due to results of certain packet classification rules and subsequent processing.

Observations:

• DOCSIS RFI specifications at Layer 3 do not support ideal open access, due to the single provider architecture of the DOCSIS system and Layer 3 and Layer 2.
• DOCSIS RFI V1.1 does provide facilities that can be exploited for ideal open access solutions however, additional design work and requirements must be developed for ideal open access to be supported by the DOCSIS standard.
• There are specialized routing and tunneling techniques that support workable, but less than ideal open access solutions. These techniques could be exploited further, for more workable solutions however; additional enhancements are needed at Layer 2 for ideal open access.

Back to index