CURRENT_MEETING_REPORT_ Reported by Vladimir Sukonnik/Process Software Corporation Minutes of the TP/IX Working Group (TPIX) First Session Agenda o AD assignment plan o Transit network policy Status of the TP/IX Proposal The session started with Vladimir Sukonnik's short presentation on the status of TP/IX and RAP projects. RAP version 1 has been released as a commercial product by Process Software Corporation. The work has begun on implementing TP/IX in future releases of the product. Two Experimental RFCs have been published describing RAP and TP/IX, thus setting the stage for vendor prototype implementation. Vladimir has also outlined the main features of TP/IX and how they compare to other IPng proposals. Transit Network Selection Robert Ullmann described the Transit Network Selection Internet-Draft. The document outlines an approach to allow network users to select the carrier the same way the telephone customers in the US can select a long-distance provider. The idea is that the border router managed by the customer must be able to acquire knowledge in real time of the availability and costs of the transit networks, and be able to select one for each datagram forwarded to the external router. Administrative Domain Assignment Plan Robert presented an idea on how to assign Administrative Domain numbers for the version 7 Internet. The objective is to use a very small amount of space in the numbering system, while providing the necessary distribution of authority. AD numbers are assigned out of the same numbering plan as version 4 network numbers. This helps prevent confusion when the first part of an IPv7 8-byte address is erroneously used as an IPv4 address. It also may be useful in routing ADs with existing routing protocols. The AD 192.0.0 is assigned to the present version 4 numbering plan. This AD has a specific plan for assignment within it: 1 o The first 24 bits are the AD (192.0.0). o The next 8 to 24 bits are a network number, each assigned to a specific organization. o The remaining 16 to 40 bits are assigned to subnets and hosts by authority reserved to a specific organization. Transition Tim Dixon asked Robert and Vladimir to elaborate on the transition plan for TP/IX. As noted in RFC 1475, it is possible to provide a mostly-transparent bridge between IPv7 and IPv4. Most of the translation should consist of copying various fields, verifying fixed values in the datagram being translated, and setting fixed values in the datagram being produced. The objective of the conversion is to be able to upgrade systems, both hosts and routers, in whatever order desired by the owners. Organizations must be able to upgrade any given system without reconfiguration or modification of any other system; IPv4 hosts must also be able to interoperate essentially forever. Future Plans Robert was asked to elaborate on the future plans for TP/IX: o RAP version 1 is done and shipping. o Prototype TP/IX is planned to be shipped in the next release of the software. o Design is ready for vendor prototype. Second Session Agenda o TCP large window/performance options o Record Marking option In the second day of the working group meeting, Robert described the TCP version 7 options Internet-Draft. By enlarging the TCP window and sequence number fields to 64 bits, we can avoid the problem that TCP v4 is having now. Mainly, the wrap-around time with the current TCP version is relatively short for fast networks. Selective Acknowledgement Option There is a new option to allow the receiver to indicate that some block of data, not ``connected'' to the left (start) edge of the TCP window, has been received. This option will allow unnecessary retransmissions 2 to be avaided. Only lost segments will be retransmitted, not the whole window. This option is useful on connections with large RTTs and large bandwidths. Timestamp Option There is a new option to accurately measure the round-trip delay of the network path being used for a TCP connection. It contains a timestamp value selected by the sending TCP, and a copy of the most recently-received timestamp from the other TCP. Record Mark Option This option indicates the boundary of an application record. The record mark is constructed by the TCP service interface at the sender, and passed to the receiver's service interface. It is not used directly by the TCP, except that the TCP may use record marks as hints for where segments might be divided for maximum performance. Large Port Number Field Another proposal is to increase the TCP/UDP port number fields to 32 bits. The current version is suffering from ``port burn-out.'' The current field size of 16 bits will max out at 16K connections in four minutes. Port numbers are divided into several ranges: 0 Reserved 1-32767 Internet registered (well-known) protocols 32768-98303 Reserved to allow TCPv7-TCPv4 conversion 98304 up Dynamic assignment Attendees Frederik Andersen fha@dde.dk Anders Baardsgaad anders@cc.uit.no Fred Baker fbaker@acc.com Jim Bound bound@zk3.dec.com Thomas Cordetti tomc@digibd.com Al Costanzo al@akc.com Geert Jan de Groot geertj@ica.philips.nl Tim Dixon dixon@rare.nl 3 Kurt Dobbins dobbins@ctron.com Kjeld Borch Egevang kbe@craycom.dk Eric Fleischman ericf@act.boeing.com Phil Irey pirey@relay.nswc.navy.mil William Simpson Bill.Simpson@um.cc.umich.edu Vladimir Sukonnik sukonnik@process.com Robert Ullmann ariel@world.std.com 4