RFC1006bis/ISO TP over IPv6 BOF (RFC1006)
Reported by Robert Watson/DEC
The RFC1006 BOF met on Wednesday, 19 July, at the 33rd IETF. The session
was chaired by Keith Sklower/Berkeley.
This BOF was the first on this subject and was attended by about 26
people. This session was originally intended to run on the MBONE but
due to room change this was not possible.
The mailing list for continuing discussion is tosi@lkg.dec.com. To join
the list, send a request to tosi-request@lkg.dec.com.
Agenda
o Agenda bash
o Purpose of this BOF
o Draft reviews
- Carpenter proposal: CLNP and TP4 over IPv6
- Pouffary proposal: TP2/TCP
o Discussions
- Other extensions/corrections to RFC 1006
o Becoming a working group
- Milestones
- Charter
Purpose of this BOF
This BOF is the result of input from the Transport Area Director on the
need to revise RFC 1006 for use over IPv6. Some minor changes have been
identified (e.g., removal of reference to IPv4) and so, whilst the
covers are off, are other changes needed?
Agenda Discussion
During the agenda discussion it was clear that there were two needs
which would be covered. The first would be to provide a solution for
running ISO Transports, especially ISO TP4 over IPv6, and the second
related to preserving and improving RFC 1006 for use over IPv6 and IPv4.
There is an installed base for RFC 1006.
Draft Reviews
The draft for OSI CLNP and TP over IPv6
(draft-carpenter-IPv6-osi-01.txt) was reviewed. It was noted that
despite the name of the draft, the text is very close to that provided
by Dave Katz/Cisco and Stephen Thomas/AT&T Tridom.
This draft describes two mechanisms, CLNP encapsulated in IPv6 which is
a CLNP tunnel over the IPv6 cloud, and ISO Transport Protocols over IPv6.
This second mechanism was described in the session as TP4 over IPv6.
A short summary of the two mechanisms described in the draft was given
to ensure that discussion of this and the following draft would take
account of the different approaches being described.
o CLNP in IPv6
The CLNP tunnel mechanism provides a virtual point-to-point link
over IPv6 where the IPv6 payload is simply a CLNP datagram (which
might actually be data or ES-IS, IDRP, etc.). There is no
restriction on the OSI addressing scheme, (it does not have to be
derived from US Gosip, etc.), no multicast simulation, and no
RFC 1070-like shim. With this scheme it would not be possible to
use IPv6 fragmentation especially if the destination is an anycast,
as fragments would not necessarily arrive all at the same host. It
is necessary to play safe and use CLNP segmentation.
o TP4 over IPv6
The TP4 over IPv6 mechanism simply provides an ISO Transport TPDU
over an IPv6 network, simulating the ISO Connectionless Network
Service. There are some Path MTU discovery considerations. ISO TP
must take advice from the lower layers when establishing a suitable
PDU size. If any ``ICMP too big'' messages are received during the
life of the connection, this information must be used by ISO
Transport to adjust the PDU size for new PDUs. Existing PDUs
cannot be re-packetized and therefore IPv6 fragmentation must be
used. It was noted that, unlike IPv4, there is no assurance in
IPv6 to purge stale packets, therefore the ISO Transport protocols
should handle PDU lifetime.
The draft, ``ISO Transport Class 2 Non-Use of Explicit Flow Control over
TCP RFC 1006 Extension'' (draft-pouffary-tcp-01.txt), was presented for
the first time.
This draft describes the small number of changes which are required
to the existing RFC 1006 mechanisms to allow upper-layer protocols
like DECnet, which require features not provided in RFC 1006, to
run over TCP. The missing features are independent of normal and
interrupt/expedited data channels and Synchronous Disconnect
mechanisms.
The goal of the draft is to minimise the number of changes to
RFC 1006 and ISO Transport (ISO 8073) protocols, whilst maximising
performance and protecting the installed base of RFC 1006 users. A
number of possible solutions were described and rejected as they
did not meet these goals.
The proposed solution, which suggests use of ISO TP2 with no flow
control (as opposed to ISO TP0 as in RFC 1006), does not require
any new TPDU formats, only changes in the rules for the use of
ISO TP2. The proposal is not specific to IPv4 or IPv6, as it
simply uses TCP and if TCP also runs over IPv6, then this mechanism
will work on both.
This mechanism makes use of splitting and recombining, in ISO TP2
(not TCP) to provide two channels between the same user thus
providing a mechanism to deliver interrupt or expedited data to the
remote user even when the primary channel is blocked by flow
control.
Note: This mechanism is not being used for sharing a single TCP
connection between multiple Transport connections. It was
suggested that a diagram would help understand the difference and
the mechanism being proposed here.
When the protocol was described the presenter noted that the
current draft does not fully describe the Synchronous Disconnect
mechanism. Optional data in the DR/DC is used to ensure data is
delivered to the user before the underlying connection is
destroyed. This will be added to the draft.
There are two implementations of this proposal, one on OpenVMS and
one on UNIX.
Discussion
General Comments
It was noted that not all the mechanisms above may be required. There
was a desire to reduce the number of solutions, and whilst there maybe a
preference for one mechanism or another, choosing just one might be
better than having too many.
From the perspective of application writers, minimizing changes to
RFC 1006 is important.
Discussion on CLNP tunneling through IPv6
Concern was expressed that there was a statement which said ``thou shall
not feed information from ICMP messages back into the CLNP world.'' For
example, the information contained in an ``ICMP too big'' message should
be used in the CLNP world. The current wording says that no attempted
is made to feedback ICMP data to the Error PDU in CLNP. At least this
does not say ``thou shall not.'' Whilst the user of the CLNP tunnel can
remain ignorant of the conditions outside the tunnel, the tunnel end
points should use information such as ICMP messages to define the
conditions at each end of the tunnel in the same way as they would for a
simply physical connection (i.e., MTU size).
Discussion on TP4 over IPv6
What is the purpose of TP4 over IPv6? What problem is it solving? It
was noted that RFC 1240 exists and describes CLTS over UDP. If we
imagine a CLNP to IPv6 exchange, then TP4 over IPv6 would be needed.
It was noted that it should not be that complex to implement. There is
an OSI implementation in the Berkeley UNIX kernel where TP4 is already
on IPv4 and CLNS and CONS, so it should not be that hard to add support
for IPv6. Whilst this is not well-used code, it would be a worthy
experiment to try this.
Is this a real difference between the behaviour of IPv4 and IPv6 with
respect to the TTL? Do routers really hold onto packets for long enough
to cause problems. What do CLNS routers do? IP routers treat TTL as a
hop count.
Discussion on RFC 1006 Extension
There was concern that the splitting and recombining would be difficult
to implement on UNIX due to the mechanisms used to handle incoming
connections. It was noted that there is already a UNIX implementation
and that there were solutions to the problems noted.
It was noted that the ISO standard requires that expedited data be
delivered no later than the next normal packet transmitted. A problem
with the current proposal is that if expedited data is sent on the
second TCP channel, it might in some circumstances be subject to delays
which allowed subsequent data on the normal channel to overtake it.
A solution for this was proposed, namely to transmit the same
expedited/interrupt data on both the normal and secondary channel. This
leads to the need to identify expedited data (sequence numbers) which is
not normal in ED TPDU when using ISO TP2 with no flow control. The
suggestion and its consequences were noted.
Why not just use TP4?
If TP4 was run over TCP, it would impact performance (flow control over
flow control) and would require much new code to be written by anyone
who has only so far implemented TP0. The use of TP2 with no flow
control ensures no conflict between the TCP and OSI TP flow-control
mechanisms. It also minimizes the new code that would have to be
written by existing RFC 1006 implementors who want to use these
extensions.
It was noted that this proposal recommends use of a separate TCP port
number.
One reason for this is to protect the existing installed base of
RFC 1006, in particular, the case where an ISO TP0 implementation has
failed to correctly handle class negotiation. Whilst all TP
implementations should be able to handle class negotiation, it is known
that some cannot. The goal is to protect the existing RFC 1006
installed based. Supporters of the existing RFC 1006 commented that
this was obviously sensible, but saw no reason why this extension and
any revised version of RFC 1006 should not share a port in the future.
It was noted that a ISO Transport connection set-up includes a
T-selector which is used to identify the application stack. Therefore
the T-Selector can be used to fan out connections to any number of
different application stacks.
For clarification, it was noted that the bits on the wire in this
extension are the same as defined for the ISO TP TPDU formats, and it is
only the rules on use of various ISO TP features which have been
changed.
In the discussion on use of a secondary TCP channel (through splitting
and recombination) for expedited/interrupt data, it was noted that:
(i) The secondary channel for expedited data is only used in one
direction and created when needed.
(ii) An additional channel may be used if expedited data was sent
in the other direction.
(iii) Use of expedited data was optional, and often not used in
both directions.
(iv) The normal channel is used for normal data in both directions.
A question was asked about why the Urgent Data message type was not used
for expedited data transmission. It was noted that there were issues
with the use of Urgent Data and that it was generally discouraged. The
Transport Area Director commented that RFC 1122 concluded that Urgent
Data should be avoided.
General Closing Comments
Does the ISO community want to take over the TP4 over IPv6 work? The
representative from ITU was asked to take the technical description of
what is being proposed back to SC6, and ensure that there is active
participation from ITU and ISO in this work area.
Do we need RFC 1006bis plus this extension? Do we need it right now for
IPv4?
It was felt that we need it because a number of small problems exist
with RFC 1006 and some are solved by the Pouffary proposal. Therefore
this is a good opportunity to make a new proposal. It was noted that
some vendors need the TP2 extensions now.
Discussions on Process
The Transport Area Director asked whether the drafts discussed here were
ready to go to Proposed Standard? Comments and a decision on making a
new working group on this topic would be provisional on this decision.
The transports are being pulled vertically by the applications and the
work requested of RFC 1006bis is aimed at trying to help a number of
applications to run over TCP and IPv6.
It was noted that the Pouffary proposal had first been submitted as a
draft and that the author was asked to delay this until the work could
be considered as part of the RFC 1006bis standardization process.
Should a working group be formed?
The Transport Area Director will have a second BOF in Dallas before
deciding if another working group would be formed and if it is fine to
have multiple standard documents defined by the work of this group.
The TP4 over IPv6 and RFC 1006bis + Pouffary proposals address the two
traditional worlds in OSI, which use connection-oriented and
connectionless network services. So based on this, it is logical to
have two solutions for these worlds in the longer term. The CLNP over
IPv6 proposal specifically addresses transition issues and is therefore
separate and needed during transition to IPv6.
The BOF decided to continue working on these three topics on mailing
lists, and to reach a consensus by Dallas. SC6 was encouraged to
participate, especially with respect to TP4 over IPv6.
Actions
Merger of RFC 1006bis and Pouffary
The advocates of RFC 1006bis and the Pouffary proposal agreed to work on
a common document (see below) which should address [ISO TP0 and TP2]
running over [TCP] running over [IPv4 and IPv6]. This work should also
take into account RFC 1278bis and RFC 1277bis.
CLNP in IPv6 Tunneling
It was agreed that there was little left to be done on the CLNP
tunneling proposal. This would be completed on the
nosi@sunroof.eng.sun.com mailing list and pushed for Last Call on the
list. This document should include CLNP over IPv4. It is also
suggested to include a paragraph on where to use the tunnel. This can
be copied from the tunneling draft.
There was discussion on whether this should be submitted as an
Experimental RFC or a Proposed Standard. It was decided that keeping it
Experimental would make it easier if it were decided to hand this work
over to ISO/ITU in the future.
Chairs Summary
The chair proposed to report the following to the Transport Area
Director:
o There is interest in pursuing TP4 over IPv6.
o There is interest in pursuing RFC 1006bis + Pouffary over
IPv4/IPv6.
o There is a need to complete the CLNP in IPv6 work.
o These pieces of work will be progressed as shown below.
o The CLNP in IPv6 proposal will be handled on the NOSI mailing list.
o The remaining work will be moved to a (new) mailing list (see
below).
o The group plans to finished this work before Dallas and have one
more BOF.
o It is not clear if additional work would be needed after Dallas.
o This BOF is explicitly encouraging ITU/ISO to participate.
The following documents will be worked:
(1) Document for: CLNP in IPv6
Mailing list: nosi@sunroof.eng.sun.com
Editor: Keith Sklower/Berkeley
(2) Document for: TP4 over IPv6
Mailing list: tosi@lkg.dec.com
Editor: Keith Sklower/Berkeley
(3) Document for: RFC1006bis + Pouffary Extensions (RFC1006quatre)
Mailing list: tosi@lkg.dec.com
Authors: A. Young/ISODE and Y. Pouffary/DEC