Minutes of the RFC1006bis/ISO TP over IPv6 BOF (RFC100)
Reported by Robert Watson, DEC
The "RFC1006bis/ISO TP over IPv6" BOF met on Friday 8th December
1995 at the 34th IETF held in Dallas.
The session was chaired by Keith Sklower, Berkeley.
This BOF was the second on this subject and was attended by about 15
people.
Agenda
o Status of CLNP Tunnel over IPv6
o Status of TP4 over IPv6 work
o Review of ITOT draft (Pouffary & Young)
Status of CLNP Tunnel over IPv6
The chairman reported that CLNP tunneling specification will be
included in the IPv6 Tunnel specification from the IPNG Working
Group.
No further work on this item will be done in the BOF.
Status of TP4 over IPv6 work
The chairman reported that, as it is not clear who will be
implementing this, the TP4 over IPv6 will be published as is, and
moved to Experimental RFC status.
Action: Keith Sklower/Berkeley.
Review of ITOT draft (Pouffary & Young)
Yanick Pouffary introduced ITOT by explaining that this is the
abbreviation being given to the ISO Transport over TCP/IP
specification. A short summary of the draft was given (see slides)
highlighting the enhancement since RFC1006.
Transport Class 0 is a direct replacement for the functions of RFC1006,
and is suitable for all current users of this standard.
Transport Class 2 is being proposed for use by application stacks, some
of which may not be running over OSI Session, and which require
additional features, such as independence of Normal and Expedited
data and graceful Transport disconnect.
Graceful Disconnect
A concern was raised as to whether graceful disconnect could be
achieved at the transport level by sending a Disconnect-Request
following the last Data. It was pointed that this draft allows for both
"Abort" and "Graceful" disconnect, and that the draft details how the
Disconnect-Request should be handled in each case.
The support for "Graceful" disconnect is needed to allow the
applicability of this draft to be extended to applications running over
upper layer stacks other than OSI Session.
Address Representation
The draft includes a section on Address representation. The
applicability of including this text in the draft was discussed.
After some discussion, and based on the view that it was generally
unhelpful to reproduce large sections of one specification in another, it
was decided the section in this draft about Network Address Encoding
will be reduced.
It will include only specific details of the differences between an ITOT
NSAPA and one for IPv6. The definition for NSAPA in IPv6 is
described in the "IPV6 Addresses inside an NSAPA" experimental
RFC. In practice the only difference between the two is the
specification of an N-Selector in the ITOT draft. For the other details,
the above experiemental RFC will be cross-referenced.
Use of X.500
The ITOT draft also contains a section on use of X.500 and interpretation
of access points. It was the concensus of the BOF that these sections
should be removed to a separate draft which ITOT will cross reference.
Discussion of Open Issues in ITOT Draft
Protocol Version Number: The rational for maintaining protocol version
V3 is given in detail in the draft. No
objections have been raised on the
mailing list, and after some
discussion in this BOF it was agreed
that this was the best solution, and
meets the needs for interoperability
with older RFC1006
implementations, and does not
prevent correct class negotiation.
Example: In the case where an
application specifically requires the
services of Class 2, and due to lack of
support for Class 2 or failure to
negotiate correctly at the responder,
a Connect-Confirm for Class 0 is
received, then the source should
handle this response as defined in
the ISO spec.
The option of using different port numbers to identify old and new
implementations was rejected as it would break any old RFC1006 users
who have chosen not to use Well-Known port 102.
US GOSIP TSAP Format: It was agreed that as US GOSIP is no
longer relevent. The reference in
RFC1006 to use of US Gosip complient
TSAPs should be dropped from ITOT.
After some investigation, no
implementation has been found
which required this condition.
Multiplexing: There was a concensus that due
to performance concerns, Multiplexing
of multiple ISO Transport connections
over a single TCP connection should
not be allowed.
This will be explicitly stated in the ITOT draft.
Expedited data: The history of this issue, as
raised at the last IETF and further
discussed on the mailing list was
given.
A possible solution (resulting from some pre-BOF discussions) was
presented. This solution (based on a mechanism borrowed from the ISO
TP4 specification), allows expedited data to be Acked, when request
using the "Request for an ACK" bit.
This solution has been detailed on the mailing list and appeared to
meet all the concerns in this area.
A new issue, relating to the splitting and recombining of the normal and
expedited data channels in process-context UNIX implementations was
discussed.
UNIX Kernel implementations have no problem to allow expedited
data channels to be established at any time during the life of a
connection and associated with the existing 'Normal' channel. With
UNIX process context implementations this would not be possible due to
difficulties in associating the new 'Expedited' channel with the
existing 'Normal' channel.
A solution was proposed and discussed.
In essense, this solution ensures that a second channel, to be used for
expedited data, is established from the responder back to the initiator
of an ITOT connection, before the responder confirms the initial
connection request. This second channel would be maintained
throughout the life of the connection and would be used for expediated
data in both directions.
This proposal will be written up and sent to the list for discussion.
Note: Following the formal close of the BOF, a further short discussion
on this issue took place which will also be passed onto the list. The
discussion was to clarify whether there was a need to always establish
the second connection at set-up time when expedited data is requested,
or only that the initiator should be prepared for this eventuality. In
the latter case, it would depend on the responder implementation to
decided if it had to set up the expediated data channel at call setup
time, or could support this being done later.
Conclusion
The Chairman requested details of what existing implementations use
expedited data and independence of channels. It was noted that
DECnet file copy makes use of this mechanism to carry interrupt data,
and that DECnet is one of the application stacks, not based on OSI
Session, which runs over RFC1859 and would plan to use ITOT once
defined.
Yanick Pouffary will revise the ITOT draft in accordance with the
comments in this BOF and will detail the proposed solution for the new
issues raised.
There will be further discussion on the mailing list and every effort
will be made to reach consensus by the end of January 1996. At that
stage the decision on whether to form a working group or finalise the
draft would be made in time for the next IETF meeting.
