[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Internet Draft                            M. StJohns (@Home Network)
IPCDN Working Group                         Expires: 1 February 1998
draft-ietf-ipcdn-tor-00.txt


            IP Over Cable Data Networks - Terms of Reference


STATUS OF THIS MEMO

     This document is an Internet-Draft.  Internet Drafts are work-
     ing documents of the Internet Engineering Task Force (IETF),
     its areas, and its working Groups. Note that other groups may
     also distribute working documents as Internet Drafts.

     Internet-Drafts draft documents are valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time. It is inappropriate to use Internet-
     Drafts as reference material or to cite them other than as
     "work in progress."

     To learn the current status of any Internet-Draft, please
     check the "1id-abstracts.txt" listing contained in the
     Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
     nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
     ds.internic.net (US East Coast), or ftp.isi.edu (US West
     Coast).

INTRODUCTION

This document describes a number of possible architectures and design
considerations for an IP-over-Cable data system.  It sets the basic
framework for discussion and creation of the document set described in
the charter for the working group.

Distribution of this memo is unlimited.

1.  Glossary

HFC            Hybrid fiber-coax. Older CATV systems were provisioned
               using only coaxial cable.  Modern systems use fiber tran-
               sport from the head end to an optical node located in
               neighborhood to reduce system noise.  Coax runs from the
               node to the subscriber. The fiber plant is generally a
               "star" configuration with all optical node fibers ter-
               minating at a headend.  The coax part of the system is
               generally a trunk and branch configuration.




M. StJohns                                                      [Page 1]


INTERNET-DRAFT  IPCDN Terms of Reference              28 July 97


Upstream       The set of frequencies used to send data from a sub-
               scriber to the headend.

Downstream     The set of frequencies used to send data from a headend
               to a subscriber.

Subsplit       A frequency allocation plan where 5-42 MHz is used for
               upstream data and 50+MHz is used for downstream data.

Midsplit       A frequency allocation plan where 5-108 MHz is used for
               upstream data and 178+ is used for downstream data.

Cable Modem    Any device which modulates and demodulates digital data
               onto a CATV plant.

Headend        Central distribution point for a CATV system.  Video sig-
               nals are received here from satellite (either co-located
               or remoted), frequency converted to the appropriate chan-
               nels, combined with locally originate signals, and
               rebroadcast onto the HFC plant. For a CATV data system,
               the headend is the typical place to link between the HFC
               system and any external data networks.

Distribution HubA smaller or remote headend distribution point for a
               CATV system.  Video signals are received here from
               another site (headend), and redistributed.  Sometimes a
               small number of locally originated signals are added.
               Such signals might be city information channels, HFC
               cable modem signals or the like.

Optical Node   A device used to convert broadband RF (radio frequency,
               e.g. television signals) to/from a fiber optic signal.

Fiber Node     Also "Node".  An optical node located in the outside
               plant distribution system which terminates the fiber
               based downstream signal as an electrical signal onto a
               coaxial RF cable.  Each fiber node is defined to support
               a certain service area, either defined by number of homes
               passed, or total amplifier cascade (# of active amplif-
               iers in the longest line from the node to the end of the
               line.)

Trunk Line     A CATV "backbone" coaxial cable.  This runs from an Opti-
               cal Node and through a specific neighborhood or serving
               area.

Branch Line    Also "Feeder Cable". A coax cable which runs from a trunk
               line to a subscriber drop point.



M. StJohns                                                      [Page 2]


INTERNET-DRAFT  IPCDN Terms of Reference              28 July 97


Tap            A passive device which divides the signal between the
               trunk or feeder lines and splits the signal into ports
               for subscriber drop access.

Drop           A subscriber access point.  From the tap to the home and
               the actual coax connection and wiring in the subscribers
               home.

Amplifier      Amplifiers are used on coaxial segments of a CATV plant
               to restore signal levels lost due to attenuation through
               distance.  Unfortunately amplifiers amplify noise as well
               as signal.

Channel        A specific frequency allocation and bandwidth. Downstream
               channels used for television in the US are 6MHz wide
               (NTSC).  International systems such as PAL and SECAM use
               8Mhz wide channels.

CATV           Originally Community Antenna Television.  Now used to
               refer to any cable (coax/fiber) based system provision of
               television services.

Homes Passed   The number of homes or offices potentially servicable by
               a cable system either on a per node or per system basis.

Telephony ReturnA variant of a cable data system where the return path
               from the subscriber cable modem goes via a dialup (or
               ISDN) connection instead of over an upstream channel.

2.  CATV Data System Discussion

In some sense, data over cable has its origins in the packet radio sys-
tems developed in the 1970s.  They both use a broadcast RF paradigm, and
they both impose a particular protocol data discipline over RF channels.
However a CATV system allows some improvements not available in an
over-the-air system.  Specifically, a CATV system can reuse frequencies
by subdividing the plant into separate regions or nodes.  Each node can
carry the same signals, can carry a completely disjoint set of signals
or can carry a mix of common signals and disjoint signals.  This is
especially important when considering the use of a CATV system for data.

Modern HFC cable systems are designed around a 500-2500 homes passed per
node figure of merit.  From the view point of a data system, all of
those homes share the same bandwidth pool allocated for data on that
node.  One of the simplest (but expensive) ways of increasing the per
home bandwidth available is to build smaller nodes or to split existing
nodes.




M. StJohns                                                      [Page 3]


INTERNET-DRAFT  IPCDN Terms of Reference              28 July 97


Any cable data system is provisioned over the same plant as the common
video services and must coexist with them gracefully.  In addition,
cable data systems may need to coexist with other services such as
broadcast audio, video game channels and possibly even digital
telephony.

In any event, there seems to be almost as many approaches to providing
data over cable as there are manufacturers of cable modem systems.  The
author has (somewhat arbitrarily) divided these into four categories:
Bridged, Routed, Switched and Router-with-lots-of-virtual-interfaces.

2.1.  Bridged

A bridged system acts as a layer 2 (MAC) forwarding system.  The systems
typically present to the subscriber a standard layer 2 interface such as
Ethernet V2 or 802.3 and then emulate that type of LAN over the cable
system.  IP awareness may be present in either or both of the subscriber
or head end cable modems, but is typically used only for management
(e.g. SNMP or software upgrades).

2.2.  Routed

Each of the cable modems in this type of system is fully IP aware and
provides at least basic IP forwarding and routing functionality. The
author knows of no implementations of this type of system.

2.3.  Switched

Each cable modem in this type of system is at the end of a virtual cir-
cuit imposed over the cable RF plant running back to the head end cable
modem.  Connections among cable modems and between the cable head end
and cable modems can logically treated as being switched.  The systems
typically present a standard layer 2 interface to the subscriber and
function more or less as would an ethernet V2 or 802.3 switch.

2.4.  Router-with-lots-of-virtual-interfaces.

Cable modem systems of this configuration functionally look like a sin-
gle router with lots of ports.  Each subscriber cable modem is treated
as an individual port.  A virtual circuit discipline is imposed over the
cable data transmission between the head end cable modem and the sub-
scriber cable modem.  From an external point of view, each subscriber
cable modem is logical part of the head end cable modem/router.

3.  Internet Protocol Service Interface

Its difficult to say anything specific about the IP interface to an HFC
cable modem system due to the range of possible approaches to the



M. StJohns                                                      [Page 4]


INTERNET-DRAFT  IPCDN Terms of Reference              28 July 97


system.  For the purposes of this document, assume that the cable modem
system has at least the functionality of a common LAN technology such as
an Ethernet or Token Ring.  Where this is not or may not be true, the
document will try to identify and suggest alternatives to achieve
equivalent functionality.

3.1.  IP Service Requirements

Any data system has to provide some minimum functionalities if it wishes
to pass IP traffic: It must be able to deliver traffic on a reasonably
reliable (best effort) basis.  It must provide for at least unicast
delivery of traffic.  It must provide a mechanism for mapping system
specific addresses (MAC addresses) to specific IP addresses (table,
algorithmic, ARP...).  With these minimums, the system may pass IP
traffic.

But is this sufficient for an IP subnet today?  Probably not.  Some
additional requirements and enhancements are: It should provide a broad-
cast and multicast capability at the MAC layer.  It should provide a
Quality of Service capability (e.g. RSVP support).  It should provide
control over who may and may not send traffic on the system.

3.1.1.  General

Cable data systems (CDS) are ideally suited to provide broadcast
delivery of traffic.  They may also provide simple multicast services
relatively easily.  Ideally, pruning of multicast streams should ori-
ginate down at the subscriber cable modem and flow back up through the
head end gear into the IP multicast system.   MAC level provisioning of
multicast services should map cleanly to IP multicast.  See the discus-
sion below.

Providing quality of service control for a CDS is a much more complex
problem.  Reduced to simple terms, a CDS is an N path (channel) packet
radio system where N is 1 or more.  QOS could be provided by time divi-
sion multiplexing, time reservation, channel reservation, space division
(e.g. separate plant), or cell or frame relay techniques, all imposed
over the RF data transmission discipline.  For the purposes of this
document, a CDS QOS system should provide at least the ability to
guarantee bandwidth for some number of identified streams and the abil-
ity to map those guarantees against the RSVP protocol.

In a typical LAN, control of who can and cannot access the system is
generally controlled by physical access to the system.  In a CDS, since
physical access to the system is present in locations where access to
the data service is not permitted (not subscribed), access control must
be provided as part of the functionality of the modem/head end systems.
Control of this access should be possible through normal network



M. StJohns                                                      [Page 5]


INTERNET-DRAFT  IPCDN Terms of Reference              28 July 97


management tools such as SNMP and should be fairly resistant to sub-
scriber fraud and manipulation.

One other consideration not normal to most LAN technologies is sub-
scriber privacy and protection.  Instead of a homogeneous community of
hosts all belonging to a single company following a single set of poli-
cies, a CDS serves a diverse, possibly non-benign set of subscribers who
may need to be protected from each other.

3.1.2.  Routing & Tunneling

A CDS may be looked at as either a transit or non-transit network.  In
the transit model, the subscribers may be end-systems (hosts) or routers
with the routers connecting to other systems.  In the non-transit model,
only end-systems are supported and no routing traffic need transit the
CDS.

A CDS may also have a pure or mixed addressing model.  In a pure system,
all addresses on the CDS (or at least on the portion of a CDS confined
to a single node) come from the same contiguous block of addresses.  In
the mixed model, more than one set of disjoint addresses may be over-
layed onto the CDS, either for flexibility or for scaling. In certain
other circumstances, private organizations may wish to export blocks of
addresses to a CDS for use by their telecommuters.

A CDS should be prepared to support both the transit and non-transit
models of connectivity, but should provide mechanisms for the CDS opera-
tor to deny its subscribers on a selective basis the ability to connect
other networks for transit.  For addressing, a CDS must be able to sup-
port at least the pure addressing system, to include all normal IP con-
siderations such as CIDR. A CDS should be able to support the mixed
addressing model, especially as an aid to growth and renumbering.

3.1.3.  Filtering

In a typical intranet, a corporation may provide filters to isolate
engineering traffic from the finance department traffic.  Very rarely
does a company need to or even want to isolate one engineer's host from
another's located mere feet away.  Unfortunately, in a CDS the
equivalent may be required: to isolate one subscriber from another.

A CDS must provide sufficient hooks and knobs so that one subscriber may
be isolated from another or from the system as a whole and so that one
subscriber may not adversely affect the operation of the CDS.  In addi-
tion, a CDS must be prepared to filter out address and routing related
traffic such as ARP, and must also provide the ability to filter
unwanted protocols (e.g. NETBEUI, Appletalk) both at he IP and at the
MAC layer.



M. StJohns                                                      [Page 6]


INTERNET-DRAFT  IPCDN Terms of Reference              28 July 97


3.2.  Multicast Service Requirements

Having an underlying broadcast medium, a CATV data system has at least
the basis for providing IP multicast services.  A CATV data system must
at least emulate multicast through the provision of broadcast service.
Any CATV data system should provide isolation of multicast streams at
least down to a specific node and ideally down to a specific cable
modem.  As the concept of premium services over multicast takes hold
(e.g. sports tickers, etc), secure isolation of multicast streams down
to specific cable modems will be required.  Ideally, a CDS will provide
an interface to permit a management system to control multicast traffic
offered or sourced from a subscriber.

3.3.  Management Interface Requirements

CATV data system management can be split in to two pieces:  that dealing
with the RF portion of the system, and that dealing with the digital
portion of the system.  The management of the RF portion of the system
would not generally be a matter for this document or the IETF, but the
addition of cable modems to the system gives the cable operator an
opportunity to more closely monitor plant health.

As is the case with any other IP capable device or system, the cable
modem system must provide appropriate SNMP interfaces for the management
of at least the digital portion of the system.  The cable modem system
should also provide access to management variables appropriate to the RF
portion of the system to include bandwidth management, noise, signal
strength and error characteristics.

4.  Security Considerations

4.1.  CATV System Management

The monitoring and control of the RF portion of the plant, when done
through or with the assistance of Cable Modem systems must provide at
least the level of protection available as if the cable modem systems
did not exist.  In other words, introduction of a data service should
not create problems in securing other systems on the cable and should
not create path for denial of service attacks.

Monitoring and management of Cable Modem assets is a problem due to the
open (broadcast) nature of the cable system.  The normal SNMP community
(clear text password) string based authentication mechanism is not in
itself secure enough for use within the system.  Cable Modem systems
must either provide cryptographic privacy within the system for the pro-
tection of such strings, or provide a cryptographically enabled version
of SNMP as the management client within the modem.




M. StJohns                                                      [Page 7]


INTERNET-DRAFT  IPCDN Terms of Reference              28 July 97


4.2.  Privacy

CATV systems are primarily broadcast systems.  This means that with the
right equipment, anyone can eavesdrop on any traffic sent by or to any-
one on the same segment of cable.  A CATV system which provides one or
two way data capabilities should provide a means for protecting the data
at least on the cable plant.  Digital encryption of such data appears to
provide adequate protection for general privacy requirements assuming a
robust enough encryption algorithm.

Other alternative requirements may include the implementation of IPSEC
protocols within the modem to provide an end to end private channel
between the subscriber and a destination host.  Such implementations may
be required if the cable plant is to be used for other than IP home sub-
scriber use (e.g. telecommuting).

5.  Advanced Requirements


5.1.  Multi-ISP (Internet Service Provider)

Various laws and regulations on the books in the United States today
require equal access from a subscriber telephone to all long-distance
networks.  At the current time, the same is generally not true (in the
US) for other services such as IP or for services provided over the
cable infrastructure.  But, globally, the trend appears to be towards
open access through whatever communication media is available.

Given this trend, one requirement on future systems will almost cer-
tainly be to provide subscriber access through the CDS to multiple ISPs.
The simplest implementation of this would permit multiple ISPs on the
cable plant, but only permit the subscriber to be associated with one of
them at a time.  The second, more complex, and unfortunately more prob-
able to be required implementation is to permit the subscriber to be
associated with multiple ISPs with the specific ISP association changing
dynamically.  E.g.  Dad signs on and is serviced by an ISP paid for by
his company.  Mom and kids sign on and they are serviced by a residen-
tial, family oriented ISP.  The last and most complex implementation
would have a single cable modem servicing multiple ISPs simultaneously.

A CDS should provide the mechanism to at least permit a subscriber to
specify and use any of a number of IP dialtone providers (ISPs) on a
fairly static basis.  It should allow the subscriber to change ISPs as a
service change - e.g. requiring cable operator intervention and some
non-immediate timeframe such as 24 hours. It may allow the subscriber to
use multiple ISPs dynamically, in a non-simultaneous manner.  It may
allow the subscriber to use multiple ISPs simultaneously.




M. StJohns                                                      [Page 8]


INTERNET-DRAFT  IPCDN Terms of Reference              28 July 97


If a CDS provides a multi-ISP capability, it must do so in a secure
manner.  Specifically, it must prevent subscribers from using ISPs for
which they are not subscribed to.  It must prevent L2 traffic from one
ISPs subscriber pool from "leaking" into another ISPs virtual network.
It must permit the various ISPs appropriate access to manage their sub-
scribers.

In the future, it is the author's belief that most of the above
"shoulds" and "mays" will become "musts" as various legislative and
regulatory actions take place.  It may be in the best interest of a CDS
developer to add the hooks to provide these services earlier rather than
later.

A. Bibliography

     These locations were current as of 28 July 1997.  Neither
     802.14 nor MCNS have completed and released for publication
     their complete suite of documents.  This list will be updated
     as the documents are finalized and formally published.

MCNS Released specifications:  This site has the publicly released ver-
sions of specifications and standards for cable data systems.  MCNS
(Multimedia Cable Network System) Partners Ltd is a partnership of a
number of large cable companies founded with the specific goal of creat-
ing and releasing standards for cable modems.

     Index of publications:
     http://www.cablemodem.com/public/pubtech.htm

IEEE 802.14 specifications:  IEEE 802.14 is the international standards
group charged with developing standards for cable modems.

     802.14 Requirements document (rev. 2):
     https://www.walkingdog.com/catv/94-002.pdf

















M. StJohns                                                      [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/