Subject: [Ieprep] Yet another scenario

From: RJ Atkinson <[email-masked]>
Date: Fri, 13 Dec 2002 09:21:27 -0500

Here is some discussion of a specific deployment strategy that relates
to the situation where one has authorised access to a cable modem
and the CATV firm associated with that cable modem deployment has signed
suitable agreements.  I think it requires some unreasonable assumptions
(for today), so I'll try to sort my assumptions into 2 buckets.  I'm
certain that there are other issues and assumptions, so this won't be
a sufficient discussion...

Reasonable Assumptions:
	- NCS (or whoever) and CATV firm that owns the HFC and the cable 
routers
	  that are deployed have signed some agreements.
	- End-user (e.g. owner of cable modem) that is customer of the CATV 
firm
	  agrees to let their link get used.

Unreasonable Assumptions:
	- DOCSIS 1.1 (or later) is widely deployed, so is present in the 
scenario,
		both in the cable router and in the cable modem -- and the equipment
		has been configured to enable the 1.1 feature set  [This might happen
	  	in future, but is not generally true today.]
	- The emergency site has power and the entire path of HFC to the 
emergency
	  site has power (e.g. for lasers and RF amps) and is undamaged, the
	  headend is undamaged, and an IP path exists from the cable modem to 
the
	  destination.  Also, the CATV firm's DOCSIS provisioning system (and 
any
	  related necessary servers) are up and fully operational.
	- The CATV firm's DOCSIS provisioning system supports configuration of 
all
	  DOCSIS 1.1 parameters on a modem-by-modem basis. [Today, I'm not 
aware of
	  any that do this.  Probably fixable by applying lots of money to the 
issue.]
	- The CATV firm has built a user-login web page that permits a user to 
login,
	  authenticate themselves, and request improved QoS.  Conceptually 
this might
	  tie back to the CATV firm's list of customers who paid more for 
their service
	  in order to be able to request QoS, to some magic list from the 
government,
	  or other such lists of users and their permissions.

Background:
	- With DOCSIS cable modems, there is a shared downstream.  In typical 
deployments,
	  64QAM modulation is used on a 6 MHz carrier.  Allowing for overhead, 
this
	  means about 27 Mbps of aggregate (shared) downstream capacity is 
available.
	- With DOCSIS cable modems, there are typically N upstreams (for N 
usually
	  in the range of 4 to 8) for each downstream.  These are normally 
space-division
	  multiplexed, so only one upstream is typically useable by a given 
cable modem.
	- In typical HFC plant in North America [1], one can only use QPSK 
modulation.
	  Normal upstream channel width is 1.5 MHz.  This yields about 1.5 
Mbps of
	  aggregate (shared) upstream capacity.
	- A typical DOCSIS cable modem has one RJ-45 10baseT Ethernet jack and 
one
	  RF interface.
	- DOCSIS 1.0 (and later) includes support for upstream and downstream 
rate-limits
	  on a per-modem basis.  In the better CM implementations, this is 
traffic-shaped.
	  In the lowest-cost implementations, clipping harmful to TCP goodput 
occurs.
	- DOCSIS 1.1 includes support for link-layer QoS (on a per-modem 
basis) that
	  is designed to support voice services ("PacketCable").
	- Depending on the HFC topology, HFC build parameters, and whatnot, 
there
	  might typically be hundreds of cable modems physically connected to 
a single
	  DOCSIS upstream.  Operational experience to date is that most of 
those CMs
	  are sending no user traffic most of the time.  Even during peak hours
	  (e.g. 4pm-9pm local time), a large percentage of them are idle at any
	  given moment in time.  Similarly, there might typically be hundreds 
to
	  a couple thousand modems connected to a single downstream.
	- In the DOCSIS standard, the operator of the cable router (CMTS) has 
total
	  control over the configuration of each individual cable modem.  The 
end user
	  does not have the ability to change QoS parameters or rate-limits or
	  what have you.

Concept of Operations:
	- The authorised emergency worker (with permission of whoever's cable 
modem
	  it is), connects a device with a web browser to the Ethernet.
	- Using that web browser, the worker types in a URL for the CATV firm's
	  magic QoS-enabling web page.   S/he then logs into the web page using
	  whichever method was pre-arranged (I'm guessing all this needs to be 
on
	  a wallet-sized card because its a lot to remember).  At that point, 
the
	  person requests that that particular cable modem be granted improved
	  service quality.  Improved service quality might mean removing an 
upstream
	  and/or downstream rate limit, enabling some of the DOCSIS 1.1 
features
	  designed to improve voice service quality, or something else 
entirely.
	- At this point the authorised emergency worker (with permission of 
whoever's
	  cable modem it is), connects their VoIP phone to the Cable modem.
	- From here, they'll need a SIP server that knows who they are, there 
will
	  need to be paths from there to the SIP server and paths from there 
to whichever
	  on-net destinations (PSTN gateway or whatever else) they want to 
reach,
	  and so forth.

Issues:
	- It is expensive and challenging to build a good DOCSIS provisioning 
system.
	  Most of the ones that exist today only support DOCSIS 1.0.  I'm 
personally
	  unaware of any that support configuration of all of the DOCSIS 1.1 
features.
	- A CATV firm might choose not to overprovision the links between the 
cable
	  router and the Tier-1 ISP uplink.  Because it is cheaper to 
overprovision
	  those links (CATV firms already have their own dark fibre in place), 
most
	  CATV firms overprovision from the cable router on out to the global 
Internet
	  today.  In short, this is a potential issue, but probably not a big 
issue,
	  because overprovisioning is common and congestion is normally 
limited to
	  the actual DOCSIS link.
	- For a DOCSIS provisioning system to be fully running, lots of pieces 
have
	  to all be working properly and have consistent configurations.  To 
boot,
	  a DOCSIS cable modem needs to talk with a DHCP server, a TFTP server,
	  a Time-of-Day server (not NTP alas), the cable router, and so forth.

Conclusion:
	For some kinds of IP networks, it might be practical and worthwhile to 
work
	with the related firms and how to use link-specific QoS mechanisms to 
support
	IEprep services.

	In particular, DOCSIS-based IP networks have broad (though not 
universal)
	coverage and about 75% of deployed cable modems connects to one of a
	relatively small number of firms.  This means that NCS (or whoever) 
might
	be able to gain a fair amount of geographic coverage with a relatively
	smaller number of contracts than for DSL, T1, or T3 end links.

Notes:

1:	In the Netherlands, typical HFC quality is MUCH higher than in North 
America
	or Australia, so they might actually be able to use 16QAM modulation 
on the
	upstream and thereby gain that much more link capacity.  I'm not well 
informed
	about typical HFC quality in Japan or other places.

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep