home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / catnip / tuba-tpix-minutes-93nov.txt < prev   
Text File  |  1994-02-19  |  7KB  |  184 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by Mark Knopper/Merit
  6.  
  7. Minutes of the Joint Session of the TUBA and TPIX Working Groups
  8.  
  9. The two groups met jointly during the second scheduled TUBA session,
  10. primarily to discuss the CATNIP proposal.  Several other TUBA items
  11. remained to be discussed after the first meeting.
  12.  
  13. Ross Callon began by introducing his ideas on CLNP header compression
  14. and flow setup, in relation to the CATNIP ideas.  A compressed header
  15. would include a ``handle'' consisting of destination and source
  16. addresses, and quality of service; a data unit identifier; and
  17. time-to-live.  This would be compressed into 8 bytes or less.  The
  18. handle is similar to a ``source route.''
  19.  
  20. Rob Ullman presented the CATNIP paper.  The CATNIP protocol can be mixed
  21. together on a datalink with IPv4, IPX, and CLNP.
  22.  
  23.  
  24.  
  25.    o The header includes:  a 4-bit field set to 7 to identify the
  26.      protocol; a set of flags (DAO destination address omitted, SAO
  27.      source address omitted, RFD report fragmentation done, and MRO
  28.      mandatory router option); the Header size (1 byte, in words); time
  29.      to live (2 bytes); FCI forward cache identifier (RhandleS);
  30.      datagram length (32 bits); transport protocol (16 bits); checksum;
  31.      destination and source addresses; and options.
  32.  
  33.    o The MRO bit set to zero means routers do not have to look at
  34.      options.  The header can be 1020 bytes long, which allows long
  35.      source route lists, etc.
  36.  
  37.    o With CATNIP, the NSEL would not have to be used for protocol ID, as
  38.      there is a 16-bit transport protocol field.
  39.  
  40.    o Network layer addresses are NSAPs, with AFI, IDI and DSP.
  41.  
  42.    o Internet Addresses would have a length of 7, and include a specific
  43.      AFI to be assigned to Internet, and an Administrative Domain
  44.      (2-byte code) currently set to 0.0.
  45.  
  46.    o IPX Addresses can be carried by CATNIP, using another AFI (to be
  47.      assigned also).  The length of the address field for IPX would be
  48.      13, and the address field will contain the IPX network number, a
  49.      4-byte network identifier followed by a MAC address (IEEE 802
  50.      6-byte value or other identifier).
  51.  
  52.    o ISO has offered to do the assignment of the Internet AFI.
  53.      Discussion:  it could be 39, with Internet having its own ICD.
  54.  
  55.    o IPX network identifiers can now be acquired from Novell.  Novell
  56.      should acquire an ICD and live under AFI 47.
  57.  
  58.    o Use of FCI may include:  flow setup, ICMP feedback, routing
  59.      protocol, multicast tree setup, RSVP, SDRP, etc.
  60.  
  61.  
  62.  
  63. Abbreviated summary of discussion:
  64.  
  65.  
  66.  
  67.    o OSI routing protocols can be used for CATNIP without changes.
  68.  
  69.    o NSAPs allow multiple address and routing plans.
  70.  
  71.    o Flow setup can be done at the data link layer, and could be
  72.      demultiplexed before the network layer, therefore FCI is not needed
  73.      in this case.
  74.  
  75.    o Why is there no explicit TOS field?  Suggestion:  issue ICMP to
  76.      turn on TOS for particular cache value, routers store with handle.
  77.  
  78.    o Ross Callon expanded on his earlier comments:  What CATNIP is doing
  79.      is defining a new protocol that lends itself to compression.  Ross
  80.      came up with the same approach when trying to come up with a
  81.      solution to compression.  His approach had 8-bit TTL, no transport
  82.      protocol field, moved things around for alignment, used different
  83.      FCI handle size, had data unit ID, datagram length smaller, and
  84.      total 3 x 32 bit fields.  If left in checksum, can omit destination
  85.      in some cases.
  86.  
  87.    o FCI is used by a host if the host is participating in reservation
  88.      process.  The host may want to check if different FCI or zero comes
  89.      in, in case of preferred FCI not being chosen (e.g.).  But normally
  90.      the host is just going to set FCI to zero and ignore the field.
  91.  
  92.    o What is the advantage of carrying IPv4 in CATNIP rather than in a
  93.      multiprotocol environment fashion?  It is easier to administer
  94.      networks based on one protocol, and also easier for router vendors
  95.      to optimize one protocol more than others.
  96.  
  97.    o Compression is address omission.  This is no more than 60%
  98.      compression, or in average cases 50% only.  Compression is for slow
  99.      links (tradeoff with CPU), or for address removal to allow CPU
  100.      saving in router hops.  The CDPD (cellular digital packet data)
  101.      CLNP compression algorithm gets down to 6-8 bytes.
  102.  
  103.  
  104.  
  105.  
  106. TUBA Transition Plan (Dave Piscitello)
  107.  
  108. Dave worked with Tracy Mallory and Jim Bound to develop an outline of a
  109. transition plan.
  110.  
  111. A transcript of Dave's slides follows:
  112.  
  113.  
  114.    o ``techniques''
  115.       -  dual stack:  systems encouraged to be dual during transition
  116.       -  encapsulation:
  117.           * IPv4 in CLNP (EIN) and CLNP in IPv4 (EON)
  118.       -  translation
  119.           * mapping CLNP ito IPv4 and reverse (tricky)
  120.    o end systems
  121.       -  principles behind dual stack operation, use of nameservice
  122.    o management
  123.       -  guidelines for SNMP operation, SMI extension, MIBs
  124.       -  ``Tools'' operation (ping, traceroute, tracedump, tcpdump)
  125.       -  other tools?
  126.       -  dynamic configuration
  127.       -  registry tools for routing
  128.       -  compression/CATNIP
  129.    o nameservice infrastructure, changes to DNS
  130.    o multicast groups of IPv4 and TUBA hosts
  131.    o applications requiring a change, description/resolution
  132.       -  ftp, 822mail, boot/discovery protocols, X, NFS/RPC, ``r''
  133.          protocols
  134.    o APIs (sklower email, DEC idea, etc.)
  135.    o NSAPA allocation
  136.    o security
  137.    o timeframe/timeline
  138.  
  139.  
  140. This outline was well received as a good start to a transition plan
  141. paper.  Some of the points included in the transcript were comments
  142. added from the attendees.  It was also suggested that the transition
  143. plan paper be very clear about where changes are need to hosts as
  144. distinguished from routers.
  145.  
  146.  
  147. ISO Liaison (Peter Ford)
  148.  
  149. Peter gave an overview of the current status of the liaison between ISOC
  150. and ISO.
  151.  
  152. Vint Cerf and Jack Houldsworth had discussions at the last IETF. ISOC
  153. recently forwarded two letters to ISO---these are Internet-Drafts.  Also
  154. there is an Internet-Draft, ``Liaison between Internet and other
  155. Standardization Agencies,'' by Christian Huitema on this topic.
  156.  
  157. For TUBA, the issue is change control.  Lyman Chapin is working on
  158. document distribution.  RFC 1310 bis contains language about ceding all
  159. copyright control to IETF from ISO. Document review and comments are
  160. encouraged.  The document can be found in the Internet-Drafts directory.
  161. One issue is how can the IETF take documents from other standards bodies
  162. into the Internet Standards process?
  163.  
  164. Concerning the Memorandum of Understanding between ISO and ISOC, Peter
  165. felt that convergence in the network layer should be suggested.  Also
  166. there should be an address change control for the base network protocol
  167. document.  The SC6 contribution is in line with this.
  168.  
  169. Peter Furniss is a SC21 member.  Both groups claim to be more open than
  170. the other.  ISO did not understand how IETF/ISOC process works and comes
  171. to consensus.  Scott Bradner pointed out that RFC 1310 is a description
  172. of our process and can be used to help communicate to other groups.
  173.  
  174. It was discussed that either ISO can retain change control and IETF can
  175. have official liaison to ISO; or the IETF can take a clone of CLNP and
  176. diverge (with report back to ISO).
  177.  
  178.  
  179. CLNP Routing in Europe (Alex Reijnierse)
  180.  
  181. Alex presented a connectivity diagram of the CLNP Internet from the
  182. European (Europanet) perspective.
  183.  
  184.