home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ipcdn / ipcdn-minutes-96dec.txt < prev   
Text File  |  1997-01-30  |  12KB  |  286 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3.  
  4. I've added some text, primarily to answer some of the questions asked
  5. the first day - my text appears in brackets [] after the questions. 
  6.  
  7. ================================================================
  8. Notes from ipcdn WG meetings 9-10 Dec 1996
  9.  
  10. Reported by Ken Calvert and Stuart Cheshire
  11.  
  12. Abbreviations:
  13.  CDN = Cable Data Network
  14.  HE = Head End
  15.  CM = Cable Modem
  16.  CP = Customer Premises
  17.  
  18. Monday 9 Dec 1996, 10-11:30 a.m.
  19.  
  20. Masuma Ahmed went over the WG objectives and deliverables.  The
  21. initial objectives of the working group are to specify operations for
  22. IP over CDNs, and to describe the architecture and needed support for
  23. services. Deliverables include:
  24.  
  25.     Architecture RFC -- framework, terminology, interfaces
  26.     IP over CATV RFC -- deal with CATV-specific issues, including
  27.           spectrum/bandwidth management, framing & encapsulation, security.
  28.     CATV network requirements RFC
  29.       [Note: IESG has forbidden the use of the term
  30.       "requirements" in titles of RFCs, so this should be a
  31.           "recommendations" RFC.]
  32.     MIBS -- generic "data over cable", RF management.
  33.  
  34.  
  35. 1. Mike St Johns discussed new "IP Over Cable Data Networks"
  36. architecture Internet Draft.  His major point was that there are so
  37. many different current, planned and possible approaches that
  38. specifying a common architecture.  The group is (not yet) specifically
  39. specifically addressing "IP over 802.14", or "IP over MCNS", but the
  40. architecture needs to work for all of them.
  41.  
  42. Discussion continued with descriptions of current Cable modem
  43. implementations: Emulating a full broadcast Ethernet, emulating
  44. thousands of point-to- point links, or emulating a switched Ethernet
  45. with thousands of ports.
  46.  
  47. Other points were brought up and discussed:
  48.  
  49. Cable TV is inherently broadcast, which can cause probems.  The group
  50. noted that this brings security problems into sharper focus than
  51. dial-up modems do. How can we achieve appropriate security at a price
  52. point appropriate to the Cable TV industry?
  53.  
  54. Cable TV providers usually want to sell Web browsing to the
  55. masses. How can (should) they deal with home users setting
  56. up their own Web server and monopolizing the upstream
  57. channel? (Like how they deal with home users who plug their
  58. CB radios into the cable jack?)
  59.  
  60. Questions from the audience:
  61.  
  62. Should the system carry transit traffic?
  63.  
  64. Should cryptography capabilities also be used to limit
  65. access to only legitimate paying subscribers?
  66.  
  67. Masuma Ahmed: Is switched Ethernet is the same as ATM
  68. circuit switching with connection set-up/tear-down etc.? [I
  69. think this shows how hard we need to work to bridge the gulf
  70. between our two communities.]
  71.  
  72. How many houses in typical system? Can be broken down to a
  73. fairly fine-grained level; about 500 houses per system.
  74.  
  75.  
  76. 2. Mark Laubach described the current state of 802.14 standard effort.
  77. They are currently in the "consensus-building" phase, with many
  78. decisions already made.  Ballot is expected 7/97, which would imply IEEE
  79. standard in 7/98.  802.14 will have a single MAC layer with multiply
  80. PHY layers under it, and will support the standard 802 LLC service.
  81. It is designed to be compatible with ATM service. In particular, ATM
  82. cell transport is mandatory in CM and HE, while support for transport of
  83. variable-length packets is optional in both.  Issues still to be
  84. addressed include security, bridging, and VLANs.
  85.  
  86. The 802.14 specification consists has the following properties:
  87. 5-40MHz upstream channel;50-550/750MHz downstream channel; 64 QAM on
  88. downstream channel (about 27Mb/s after FEC);QPSK / 16QUAM for the upstream 
  89. channels.
  90.  
  91.  
  92. 3. Michelle Kuska of TCI described the Multimedia Cable Network
  93. System (MCNS) effort, which is defining i/f's internal and external to
  94. CDN systems.  They are in the "third phase", have just released
  95. security and RF documents.  [MCNS docs are at www.cablemodem.com.]
  96.  
  97. 4. Masuma Ahmed discussed the IP over CATV draft that was put out in
  98. early October, before the WG really got going.  That document raised
  99. a good deal of discussion about topics such as ARP and what
  100. constitutes a LIS when topological "neighbors" on the cable cannot
  101. communicate directly with each other, either because the link-layer
  102. protocol doesn't support it or because of security restrictions
  103. enforced by the respective CDMs.
  104.  
  105. Eventually it was agreed that the architecture document needed to be
  106. in place to provide a framework for more detailed discussions of the
  107. IP over CATV draft.
  108.  
  109. Discussion:  
  110.  
  111. 1) Needs to support guaranteed IP service as well as best-
  112. effort.  [Best effort is contention e.g. CSMA/CD while guaranteed
  113. might be CBR cell based protocols.]
  114.  
  115. 2) Needs to support dynamic and static address assignment?
  116. [Generally, yes - both models work, but scales are different.  Static
  117. works if you either have a very small system or you *never* expect to
  118. have to renumber.]
  119.  
  120. 3) Needs to support different tiers of IP service: e.g.
  121. different types of Web site?  [This is almost more of a commercial
  122. issue than a protocol issue, but valid nonetheless.  Basically, the
  123. model of paying more for more or better service for public internet
  124. service is hard when the system is as open as a cable system is.  So
  125. issue is to ensure knobs exist at each entry point (cable modem) to
  126. tune for appropriate dollar value.]
  127.  
  128. 4) What about IP Multicast and Broadcast?
  129. [Requirement exists for both, but concept of "premium" multicast
  130. services has crept in which means support for these in system has to
  131. allow system manager greater access to what content streams can and
  132. can't get through.]
  133.  
  134. 5) Question about whether IBM owns (or has applied for) patent
  135. on certain uses of DHCP?  [Chair recieved email from IBM employee
  136. indicating that certain uses of DHCP might be covered by patent.
  137. Point is noted for further investigation before standards
  138. submission. ] 
  139.  
  140. 6) Question from the audience: Hosts in the same LIS (Logical
  141. IP Subnet) communicate with each other via router. Hosts
  142. cannot communicate directly. Then in what sense is it a
  143. subnet? Certainly not in the sense of "a set of mutually
  144. reachable IP hosts".  [Substantial discussion on this topic without
  145. identifiable closure.  This is tied up in the n-version model of how
  146. you might implement IP over cable - see above].
  147.  
  148. Discussion continued into ARP issues peculiar to a cable data system: 
  149.  
  150. Router does not use ARP; it captures mappings from observing
  151. DHCP packets. (What if the router crashes and loses this
  152. state?)
  153.  
  154. When hosts talk to router it uses ARP to find router's address. (Why?
  155. If host can only talk to router, why does it need to address the
  156. destination? Why is it not just like a point-to-point link?)
  157.  
  158. Concensus seems to be that ARP over the coax is not necessary. Of
  159. course the Cable/Ethernet bridge in the user's home may need to
  160. generate proxy ARP replies on the Ethernet interface, because hosts on
  161. the Ethernet most likely will be running unmodified networking
  162. software that doesn't know about the concept of an Ethernet subnet
  163. where the hosts can't talk to each other. [Wouldn't it be more
  164. straightforward to just use switched Ethernet techniques to provide an
  165. Ethernet where the hosts *can* talk to each other? That way they could
  166. also do AppleTalk, IPX, etc. as well as just IP, if they wanted to.]
  167.  
  168.  
  169. Tuesday 10 December (9-11:30)
  170.  
  171. Mike St Johns led more discussion of architecture document.
  172. Salient points included:
  173.  
  174. -- Document should not assume Ethernet as the level-2 interace to the
  175.    subscriber.  Some CDMs will have a card that plugs directly into a PC.
  176. -- Architecture should accomodate the possibility of a home network,
  177.    not just a single PC.
  178. -- It was pointed out that dial-up IP service evolved in a somewhat
  179.    haphazard way, and now nobody is very happy.  Goal should be to avoid
  180.    hacking things together to get it to work. (Example: passing DNS
  181.    configuration to subscriber in a PPP/IPCP msg.)
  182. -- There is a possibility of multiple providers on a single network --
  183.    not necessarily multiple wires, but multiple service providers.
  184. -- There should be a caveat in the document that what the user "sees"
  185.    may be different from what's going on underneath. [Why?]  [Chair's
  186.    note:  what the customer might see may look like a slightly peculiar
  187.    ethernet - what may be happening on the cable is probably much more
  188.    complex and may bear little resemblence to what happens on an ethernet
  189.    coax.
  190. -- Possibility of hybrid paths, of which "telco return" (upstream via
  191.    dialup) is one example.
  192. -- We should not be influenced too much by existing implementations.
  193. -- Traditional "corporate" configuration methods are not adequate,
  194.    e.g. relying on MAC address only.
  195. -- Fraud possibilities are a concern.
  196. -- [How] should providers offer tunneling services? E.g. some orgs
  197.    want to import part of their corporate address space into a local
  198.    office via CDN.
  199. -- Is there any reason the thing at the HE should look like anything
  200.    other than a plain old router [to subscribers]?
  201. -- What about QoS if the i/f is Ethernet?
  202. -- Link-level service should/must be separated out from IP service?
  203.  
  204. Goal (per MSJ): at the end of the process, mfrs can look at
  205. the document and say "I can provide this IP service".
  206.  
  207. It was proposed that we needed some pictures to hang concepts on.
  208. Mike Patrick volunteered to draw.  He proposed the following as a
  209. starting point:
  210.  
  211.                         Customer Premises
  212.                                |---|
  213.       -  -  -  -  -  -  -            |-----|  |-|PC |
  214.        ----- |                       | CDM |--| |---|
  215.      | | R |-|            |               |-----|  |
  216.        ----- |                           /          | |---|
  217.      |  |    | |------|    |             /          |-|PC |
  218.                 |-|CDM-TS|--------------------------      |---|
  219.      |       | |------|    |    \                    ^
  220.             LAN                  \|---|             |
  221.      - - - - - - - - -  -      |CDM|...         Shared-media LAN
  222.          Head End              |---|
  223.  
  224.  
  225. It was noted that the routing function might be combined with the
  226. CDM-terminating system in a single box at the head end (dotted line
  227. above) or indeed that the routing function might extend all the way to
  228. the CDM itself, but the consensus seemed to be that none of these
  229. should make any difference to the way subscriber's "PC" boxes "see"
  230. the IP network.
  231.  
  232. Then someone (John Pickens?) offered a more generic architectural view:
  233.  
  234.   --------------                                   --------------
  235.  | \   fwding / |                                | \   fwding / |
  236.  |  \  fnct  /  |                                |  \  fnct  /  |
  237.  |   \      /   |                                |   \      /   |
  238.  |    \    /    |<- E.g., 802.14,                |    \    /    |
  239.  |     \  /     |   MCNS, SCTE,                  |     \  /     |
  240.  |      \/      |   DAVIC,...                    |Cable \/      |
  241.  |      || Cable|                                |MAC   ||         |
  242.  |      || MAC  |                                |      ||      |
  243.  |______||______|                                |______||______|
  244.      |        |           Cable medium              |         |
  245.  HE|_|        |_____________________________________|          |___| subscr.
  246. i/f|                                     | i/f
  247.  
  248.  
  249. Attributes when Forwarding Function is Router (IP)
  250.  
  251. - Forwarding
  252. - Routes
  253. - Multicast
  254. - QoS
  255. - Filtering
  256. - Segmentation
  257.  
  258. Attributes when Forwarding Function is Bridge (802.1D/P/Q) 
  259.  
  260. - Forwarding
  261. - Learning
  262. - Multicast
  263. - QoS
  264. - Filtering
  265. - VLAN
  266.  
  267. Attributes of HFC MAC/Link
  268.  
  269. - unicast and multicast downstream
  270. - unicast upstream
  271. - fixed (ATM) framing with AAL5 for variable framing*
  272. - variable framing with code point for ATM*
  273. - VLAN*
  274. - Encryption*
  275. - QoS*
  276.  
  277.   * not all technologies
  278.  
  279. There was consensus in the room that these pictures provide a
  280. reasonable starting point.
  281.  
  282.  
  283. Action items to the chair include getting the current version of the
  284. the architecture document posted as an Internet Draft.  
  285.  
  286.