CURRENT_MEETING_REPORT_ Reported by Mark Knopper/Merit Minutes of the Joint Session of the TUBA and TPIX Working Groups The two groups met jointly during the second scheduled TUBA session, primarily to discuss the CATNIP proposal. Several other TUBA items remained to be discussed after the first meeting. Ross Callon began by introducing his ideas on CLNP header compression and flow setup, in relation to the CATNIP ideas. A compressed header would include a ``handle'' consisting of destination and source addresses, and quality of service; a data unit identifier; and time-to-live. This would be compressed into 8 bytes or less. The handle is similar to a ``source route.'' Rob Ullman presented the CATNIP paper. The CATNIP protocol can be mixed together on a datalink with IPv4, IPX, and CLNP. o The header includes: a 4-bit field set to 7 to identify the protocol; a set of flags (DAO destination address omitted, SAO source address omitted, RFD report fragmentation done, and MRO mandatory router option); the Header size (1 byte, in words); time to live (2 bytes); FCI forward cache identifier (RhandleS); datagram length (32 bits); transport protocol (16 bits); checksum; destination and source addresses; and options. o The MRO bit set to zero means routers do not have to look at options. The header can be 1020 bytes long, which allows long source route lists, etc. o With CATNIP, the NSEL would not have to be used for protocol ID, as there is a 16-bit transport protocol field. o Network layer addresses are NSAPs, with AFI, IDI and DSP. o Internet Addresses would have a length of 7, and include a specific AFI to be assigned to Internet, and an Administrative Domain (2-byte code) currently set to 0.0. o IPX Addresses can be carried by CATNIP, using another AFI (to be assigned also). The length of the address field for IPX would be 13, and the address field will contain the IPX network number, a 4-byte network identifier followed by a MAC address (IEEE 802 6-byte value or other identifier). o ISO has offered to do the assignment of the Internet AFI. Discussion: it could be 39, with Internet having its own ICD. o IPX network identifiers can now be acquired from Novell. Novell should acquire an ICD and live under AFI 47. o Use of FCI may include: flow setup, ICMP feedback, routing protocol, multicast tree setup, RSVP, SDRP, etc. Abbreviated summary of discussion: o OSI routing protocols can be used for CATNIP without changes. o NSAPs allow multiple address and routing plans. o Flow setup can be done at the data link layer, and could be demultiplexed before the network layer, therefore FCI is not needed in this case. o Why is there no explicit TOS field? Suggestion: issue ICMP to turn on TOS for particular cache value, routers store with handle. o Ross Callon expanded on his earlier comments: What CATNIP is doing is defining a new protocol that lends itself to compression. Ross came up with the same approach when trying to come up with a solution to compression. His approach had 8-bit TTL, no transport protocol field, moved things around for alignment, used different FCI handle size, had data unit ID, datagram length smaller, and total 3 x 32 bit fields. If left in checksum, can omit destination in some cases. o FCI is used by a host if the host is participating in reservation process. The host may want to check if different FCI or zero comes in, in case of preferred FCI not being chosen (e.g.). But normally the host is just going to set FCI to zero and ignore the field. o What is the advantage of carrying IPv4 in CATNIP rather than in a multiprotocol environment fashion? It is easier to administer networks based on one protocol, and also easier for router vendors to optimize one protocol more than others. o Compression is address omission. This is no more than 60% compression, or in average cases 50% only. Compression is for slow links (tradeoff with CPU), or for address removal to allow CPU saving in router hops. The CDPD (cellular digital packet data) CLNP compression algorithm gets down to 6-8 bytes. TUBA Transition Plan (Dave Piscitello) Dave worked with Tracy Mallory and Jim Bound to develop an outline of a transition plan. A transcript of Dave's slides follows: o ``techniques'' - dual stack: systems encouraged to be dual during transition - encapsulation: * IPv4 in CLNP (EIN) and CLNP in IPv4 (EON) - translation * mapping CLNP ito IPv4 and reverse (tricky) o end systems - principles behind dual stack operation, use of nameservice o management - guidelines for SNMP operation, SMI extension, MIBs - ``Tools'' operation (ping, traceroute, tracedump, tcpdump) - other tools? - dynamic configuration - registry tools for routing - compression/CATNIP o nameservice infrastructure, changes to DNS o multicast groups of IPv4 and TUBA hosts o applications requiring a change, description/resolution - ftp, 822mail, boot/discovery protocols, X, NFS/RPC, ``r'' protocols o APIs (sklower email, DEC idea, etc.) o NSAPA allocation o security o timeframe/timeline This outline was well received as a good start to a transition plan paper. Some of the points included in the transcript were comments added from the attendees. It was also suggested that the transition plan paper be very clear about where changes are need to hosts as distinguished from routers. ISO Liaison (Peter Ford) Peter gave an overview of the current status of the liaison between ISOC and ISO. Vint Cerf and Jack Houldsworth had discussions at the last IETF. ISOC recently forwarded two letters to ISO---these are Internet-Drafts. Also there is an Internet-Draft, ``Liaison between Internet and other Standardization Agencies,'' by Christian Huitema on this topic. For TUBA, the issue is change control. Lyman Chapin is working on document distribution. RFC 1310 bis contains language about ceding all copyright control to IETF from ISO. Document review and comments are encouraged. The document can be found in the Internet-Drafts directory. One issue is how can the IETF take documents from other standards bodies into the Internet Standards process? Concerning the Memorandum of Understanding between ISO and ISOC, Peter felt that convergence in the network layer should be suggested. Also there should be an address change control for the base network protocol document. The SC6 contribution is in line with this. Peter Furniss is a SC21 member. Both groups claim to be more open than the other. ISO did not understand how IETF/ISOC process works and comes to consensus. Scott Bradner pointed out that RFC 1310 is a description of our process and can be used to help communicate to other groups. It was discussed that either ISO can retain change control and IETF can have official liaison to ISO; or the IETF can take a clone of CLNP and diverge (with report back to ISO). CLNP Routing in Europe (Alex Reijnierse) Alex presented a connectivity diagram of the CLNP Internet from the European (Europanet) perspective.