RE: RFC1006 extension ISO Transport Class 2 Non-use of Explicit Flow Control over TCP
Yanick <pouffary@taec.enet.dec.com> Tue, 09 May 1995 12:45 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03212; 9 May 95 8:45 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03208; 9 May 95 8:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05047; 9 May 95 8:45 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03201; 9 May 95 8:45 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03197; 9 May 95 8:45 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa05042; 9 May 95 8:45 EDT
Received: from inet-gw-1.pa.dec.com by venera.isi.edu (5.65c/5.61+local-21) id <AA18152>; Tue, 9 May 1995 05:46:11 -0700
Received: from vbormc.vbo.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA17909; Tue, 9 May 95 05:36:25 -0700
Received: by vbormc.vbo.dec.com; id AA22585; Tue, 9 May 95 13:56:11 +0200
Message-Id: <9505091156.AA22585@vbormc.vbo.dec.com>
Received: from taec.enet; by vbormc.enet; Tue, 9 May 95 14:25:09 MET DST
Date: Tue, 09 May 1995 14:25:09 -0000
X-Orig-Sender: iesg-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Yanick <pouffary@taec.enet.dec.com>
To: harald.t.alvestrand@uninett.no
Cc: mankin@isi.edu, postel@isi.edu, iesg@isi.edu, dan@netrix.enet.dec.com, bound@xirtlu.enet.dec.com, pouffary@taec.enet.dec.com
Apparently-To: iesg@ISI.EDU, postel@ISI.EDU, mankin@ISI.EDU, harald.t.alvestrand@uninett.no
Subject: RE: RFC1006 extension ISO Transport Class 2 Non-use of Explicit Flow Control over TCP
Hi Harald, I have included all the mail we have exchanged so far on the Informational RFC - ISO Transport Class 2 Non-use of Explicit Flow Control over TCP - RFC1006 Extension. I have done this so that Allison Mankin, Jon Postel, Dan Harrington and Jim Bound can follow the conversation. You described the following scenario in your last mail: #- Send ED TPDU over Expedited channel #- Send DT TPDU over Normal channel #- IP packet loss hits the ED TPDU, causing delay #- DT TPDU over Normal channel is delivered ahead of ED TPDU, which is # illegal according to ISO We discussed at great length this scenario. And we also thougth that EA was the way to "absolutly guaranty" ED delivery ahead of DT. BUT having EA also meant that ED needed to carry sequence number and that flow control needed to be enabled (at least on the Expedited data virtual channels). We decided to keep/make the extension as straightforward as possible and as close to ISO 8073 and RFC1006 philosophy as possible. Also what we really needed is separate virtual data channels for Normal and Expedited and that Expedited data channel not be blocked by a congested normal data channel. One other (and real) goal was also the "ease of implementation" of this extension for all existing RFC1006 implementation. So what I propose is that I add a paragraph clarifying the above. #Apparently there are other IETF members that have voiced problems with the #document, but since I am not a member of any mailing list where this has #been discussed, I don't know if the current document has been changed to #reflect any of these comments. I am not aware of any other "voiced problems". Can you please be clearer? Let me know and best regards, Yanick From: VBORMC::"Harald.T.Alvestrand@uninett.no" "MAIL-11 Daemon" 4-MAY-1995 11:24:38.68 To: Yanick <taec::pouffary> CC: iesg@isi.edu Subj: Re: Submission Informational RFC Yanick, thanks for your prompt response. I am sorry that I start technical discussions so late in the game, but I in fact did not discover the internet-draft at all - my usual line of work is applications, and my interest in this topic is because of ancient history (I did a thesis work on OSI transport over IP back in 1984!) The expedited problem is not quite as simple - the problem is the sequence of events: - Send ED TPDU over Expedited channel - Send DT TPDU over Normal channel - IP packet loss hits the ED TPDU, causing delay - DT TPDU over Normal channel is delivered ahead of ED TPDU, which is illegal according to ISO In order to prevent this from happening, one has to stop sending DT TPDUs until the ED TPDU is delivered, which means that you need an EA TPDU to discover that it is in fact delivered, so that you can start sending DT TPDUs again. Apparently there are other IETF members that have voiced problems with the document, but since I am not a member of any mailing list where this has been discussed, I don't know if the current document has been changed to reflect any of these comments. harald A % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by vbormc.vbo.dec.com; id AA14922; Thu, 4 May 95 11:13:55 +0200 % Received: from domen.uninett.no by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA32325; Thu, 4 May 1995 02:20:39 -070 % Received: from dale.uninett.no by domen.uninett.no with SMTP (PP) id <20715-0@domen.uninett.no>; Thu, 4 May 1995 11:15:21 +020 % Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.9) with ESMTP id FAA07702; Thu, 4 May 1995 05:15:16 -04 % Message-Id: <199505040915.FAA07702@dale.uninett.no> % X-Mailer: exmh version 1.5.3 12/28/94 % From: Harald.T.Alvestrand@uninett.no % To: Yanick <taec::pouffary> % Cc: iesg@isi.edu % Subject: Re: Submission Informational RFC % In-Reply-To: Your message of "Wed, 03 May 1995 16:00:22 +0700." <9505031350.AA27263@vbormc.vbo.dec.com> % Mime-Version: 1.0 % Content-Type: text/plain; charset="us-ascii" % Date: Thu, 04 May 1995 11:15:16 +0200 % Sender: hta@dale.uninett.no From: TAEC::POUFFARY "Yanick" 3-MAY-1995 16:10:38.26 To: VBORMC::"Harald.T.Alvestrand@uninett.no" CC: VBORMC::"iesg@isi.edu",POUFFARY Subj: Re: Submission Informational RFC Hi Harald, Thanks for your input. I just came in the office today (I am on vacation till next tuesday). I want to briefly answer your questions now. We can discuss more when I come back from vacation May 9th. ##1) Has the port 399 been officially assigned, or is it a "grab"? Yes it has on 19-NOV-1994. See the mail below +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From: VBORMC::"jkrey@ISI.EDU" 19-NOV-1994 01:16:13.90 To: taec::pouffary CC: iana@ISI.EDU Subj: Re: Request for Well-known TCP port number assignment Yanick, We have assigned port number 399 to ISO-TSAP Class 2, with you as the point of contact. Joyce +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ #2) I would *much* prefer that the document start out with "this is the # documentation for how DECNET/OSI works over TCP/IP". Well we could but really this extension is very generic. ISO transport identify its user by transport service access point ID (TSAP-ID). #- Expedited follows an idea that Marshall used for an # *earlier* RFC1006 version, but abandoned; there is no guarantee that # the expedited PDU does not arrive *later* than normal data sent at # the same time, and this is required by the ISO protocol To guaranty delivery of interrupt data the second channel is not torn down until the normal data channel is. The need is to have separate virtual data channels. Interrupt Data transmission cannot be blocked by a congested Normal data channel. #- Multiplexing is recommended against, but not forbidden; this combined # with no explicit flow control means that multiplexing can happen # and will lead to some *fun* reactions on congestion This is why we don't recommended for performance reason to do multiplexing. But if one want to do it one can always do it. #- The idea that one can tell from the TPDUs whether this is RFC1006 # or this new protocol is simply wrong, unless one watches every # packet from session establishment onwards That is not true. Connect-request identify the class and the end-user TSAP-ID. Once the connection is established no one needs to monitor it. #- There is no description on what to do if someone suggests that we # negotiate down to class 0 on establishment; is this allowed? This is not allowed. Class negotiation is done according to ISO 8073 rules. When using TP0 over TCP/IP there is only class 0 can be negotiated. When using TP2-No-Flow-Control over TCP/IP no other class can be negotiated. This is because 0 is not an alternate of 2 unless it is explicitly specified in the connect request TPDU. #All in all, I feel very good about DEC wanting to document its protocol, #but I don't like the present submission very much. #Would it be appropriate to suggest that he publish it as an Internet-draft, #so that other people can take a look at it to ensure clarity before it #is published as Informational? It was published for six months. Sorry if you missed it. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Internet-Draft is available from the on-line Internet-Drafts directories. Title : ISO Transport Service over TCP RFC1006 extension Author(s) : Y. Pouffary Filename : draft-pouffary-tcp-00.txt Pages : 10 Date : 10/25/1994 Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-pouffary-tcp-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-pouffary-tcp-00.txt". +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Looking forward to more cooperation. Best regards Yanick From: VBORMC::"Harald.T.Alvestrand@uninett.no" "MAIL-11 Daemon" 3-MAY-1995 10:49:42.62 To: postel@isi.edu CC: iesg@isi.edu, taec::pouffary Subj: Re: Submission Informational RFC Jon, 1) Has the port 399 been officially assigned, or is it a "grab"? 2) I would *much* prefer that the document start out with "this is the documentation for how DECNET/OSI works over TCP/IP". There are a number of problems with the protocol described, including: - Expedited follows an idea that Marshall used for an *earlier* RFC1006 version, but abandoned; there is no guarantee that the expedited PDU does not arrive *later* than normal data sent at the same time, and this is required by the ISO protocol - Multiplexing is recommended against, but not forbidden; this combined with no explicit flow control means that multiplexing can happen and will lead to some *fun* reactions on congestion - The idea that one can tell from the TPDUs whether this is RFC1006 or this new protocol is simply wrong, unless one watches every packet from session establishment onwards - There is no description on what to do if someone suggests that we negotiate down to class 0 on establishment; is this allowed? All in all, I feel very good about DEC wanting to document its protocol, but I don't like the present submission very much. Would it be appropriate to suggest that he publish it as an Internet-draft, so that other people can take a look at it to ensure clarity before it is published as Informational? Harald A % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by vbormc.vbo.dec.com; id AA13229; Wed, 3 May 95 10:39:04 +0200 % Received: from domen.uninett.no by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA17837; Wed, 3 May 1995 01:45:49 -070 % Received: from dale.uninett.no by domen.uninett.no with SMTP (PP) id <09196-0@domen.uninett.no>; Wed, 3 May 1995 10:38:47 +020 % Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.9) with ESMTP id PAA03117; Mon, 1 May 1995 15:10:08 -04 % Message-Id: <199505011910.PAA03117@dale.uninett.no> % From: Harald.T.Alvestrand@uninett.no % To: postel@isi.edu % Cc: iesg@isi.edu, taec::pouffary % Subject: Re: Submission Informational RFC % In-Reply-To: Your message of "Fri, 28 Apr 1995 11:18:51 PDT." <199504281818.AA09355@zen.isi.edu> % Mime-Version: 1.0 % Content-Type: text/plain; charset="us-ascii" % Content-Id: <3114.799355407.1@dale.uninett.no> % Date: Mon, 01 May 1995 15:10:08 -0400 % Sender: hta@dale.uninett.no From: VBORMC::"postel@ISI.EDU" 28-APR-1995 20:28:46.59 To: iesg@ISI.EDU CC: taec::pouffary Subj: Submission Informational RFC Hi. The RFC Editor has received this independent submission of a document to be published as an informational RFC. However, the subject matter seems to cover a topic close to the IETFs heart and so the RFC Editor is asking the IESG to consider reviewing this document. If the IESG does not raise any objections in two weeks this will be published as a informational RFC. The two week time out ends 10-May-95. --jon. ----- Begin Included Message ----- From pouffary@taec.enet.dec.com Fri Apr 28 09:20:23 1995 Date: Fri, 28 Apr 95 18:05:12 MET DST From: Yanick <pouffary@taec.enet.dec.com> To: rfc-editor@ISI.EDU Cc: pouffary@taec.enet.dec.com Subject: Submission Informational RFC Request for Comments Yanick Pouffary April 1995 ISO Transport Class 2 Non-use of Explicit Flow Control over TCP RFC1006 extension Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Table of Contents Status of this Memo.............................................1 1. Introduction - General recommendations.......................2 2. The protocol.................................................3 2.1 TCP service as a Network Service - The Primitives...........3 2.2 Connection Establishment....................................4 2.3 Data Transfer...............................................5 2.4 Connection Release..........................................5 3. Packet Format................................................6 4. DIGITAL DECnet over TCP/IP...................................7 Acknowledgements................................................8 References......................................................8 Author' Address.................................................8 Y. Pouffary [Page 1] RFC ISO Transport Class 2 Non-use of Explicit April 1995 Flow Control over TCP - RFC1006 Extension 1. Introduction - General recommendations This document is an extension to RFC1006, a standard for the Internet community. The document does not duplicate the protocol definitions contained in RFC1006 and in International Standard ISO 8073. It supplements that information with the description of how to implement ISO Transport Class 2 Non-use of Explicit Flow Control on top of TCP. The document should be used in conjunction with the RFC1006 and ISO 8073. The RFC1006 standard defines how to implement ISO 8073 Transport Class 0 on top of TCP. This memo defines how to implement ISO 8073 Transport Class 2 Non-use of Explicit Flow Control on top of TCP. Like ISO Transport Class 0, Class 2 Non-use of Explicit Flow Control provides basic connection with minimal overhead. A Transport protocol class is selected for a particular Transport connection based upon the characteristics of the lower layers and the requirements of the upper layer. Use of class 2 Non-use of Explicit Flow Control is suitable when the use of separate virtual data channels for normal and expedited Data are desirable or when an explicit disconnection of the Transport connection is desirable. Hosts which choose to implement this extension are expected to listen on a well-known TCP port number 399. It is recommended that the well-known RFC1006 TCP port 102 not be used. This recommendation is done to minimise impact to an existing RFC1006 implementation. The memo also describes the use of this extension within the DIGITAL Network Architecture (DNA). Y. Pouffary [Page 2] RFC ISO Transport Class 2 Non-use of Explicit April 1995 Flow Control over TCP - RFC1006 Extension 2. The protocol The protocol specified by this memo is fundamentally equivalent to the protocol ISO 8073 Transport Class 2 Non-use of Explicit Flow Control, with the following extensions: - Expedited Data service is supported. - Splitting and Recombining may be used for Expedited Data transmission. - The Network Service used is provided by TCP. The ISO 8073 Transport protocol Class 2 allows Multiplexing. It is recommended that this capability not be use for performance reasons. The ISO 8073 Transport protocol exchanges information between peers in discrete units of information called transport protocol data units (TPDUs). The protocol defined in this memo encapsulates these TPDUs in discrete units called TPKTs. The structure of these TPKTs and their relationship to TPDUs are discussed in the next sections. 2.1 TCP service as a Network Service - The Primitives The mapping between the TCP service primitives and the service primitives expected by ISO 8073 Transport when operation over Connection-oriented network service is straightforward. Note: The following description of the mapping is a repeat from the RFC1006 standard. network service TCP --------------- --- CONNECTION ESTABLISHMENT N-CONNECT.REQUEST open completes N-CONNECT.INDICATION listen (PASSIVE open) finishes N-CONNECT.RESPONSE listen completes N-CONNECT.CONFIRMATION open (ACTIVE open) finishes DATA TRANSFER N-DATA.REQUEST send data Y. Pouffary [Page 3] RFC ISO Transport Class 2 Non-use of Explicit April 1995 Flow Control over TCP - RFC1006 Extension N-DATA.INDICATION data ready followed by read data CONNECTION RELEASE N-DISCONNECT.REQUEST close N-DISCONNECT.INDICATION connection closes or errors Mapping parameters between the TCP service and the network service is also straightforward: network service TCP --------------- --- CONNECTION ESTABLISHMENT Called address server's IP address (4 octets) Calling address client's IP address (4 octets) all others ignored DATA TRANSFER NS-user data (NSDU) data CONNECTION RELEASE all parameters ignored 2.2 Connection Establishment The principles used in connection establishment are based upon those described in ISO 8073, with the following extensions. - Connection Request and Connection Confirmation TPDUs may negotiate the use of Expedited Data transfer using the negotiation mechanism specified in ISO 8073. - Connection Request and Connection Confirmation TPDUs must not negotiate the Use of Explicit Flow Control. To perform an N-CONNECT.REQUEST action, the TS-peer performs an active open to the desired IP address using a well know TCP port 399. Y. Pouffary [Page 4] RFC ISO Transport Class 2 Non-use of Explicit April 1995 Flow Control over TCP - RFC1006 Extension When the TCP signals either success or failure, this results in an N-CONNECT.INDICATION action. To await an N-CONNECT.INDICATION event, a server listens on a well know TCP port 399. When a client successfully connects to this port, the event occurs and an implicit N-CONNECT.RESPONSE action is performed. 2.3 Data Transfer The elements of procedure used during transfer are based upon those presented in ISO 8073, with the two following extensions. - Expedited Data may be supported (if negotiated during connection establishment). In Non-Use of Explicit Flow Control Expedited Data require no Expedited Data Acknowledgement. - Splitting and Recombining may be used for Expedited Data transmission. The procedure of Splitting and Recombining allows a transport connection to make use of multiple TCP connections. TCP connections created for Splitting purposes should also use the primitives described in 2.1. It is recommended to only create a second TCP connection for Expedited Data when transmission of Expedited Data is requested. Expedited Data must only be sent over an outgoing TCP connection. This second TCP connection must not be shared among transport connections and must remain established until the transport connection is terminated, at which time it must be closed. To perform an N-DATA.REQUEST action, the TS-peer constructs the desired TPKT and uses the TCP send data primitive. To trigger an N-DATA.INDICATION action, the TCP indicates that data is ready and a TPKT is read using the TCP read data primitive. 2.4 Connection Release The elements of procedure used during a connection release are identical to those presented in ISO 8073. Y. Pouffary [Page 5] RFC ISO Transport Class 2 Non-use of Explicit April 1995 Flow Control over TCP - RFC1006 Extension Disconnect Request and Disconnect Confirmation TPDUs are exchanged. Upon receipt of a Disconnect Confirmation TPDU a N-DISCONNECT.REQUEST action is performed to simply close the TCP connection. If the TCP connection has been closed or has failed, this generates an N-DISCONNECT.INDICATION event. 3. Packet Format A fundamental difference between TCP and the network service expected by ISO transport is that TCP manages a continuous stream of octets, with no explicit boundaries. The protocol described in RFC1006 uses a simple packetization scheme in order to delimit TPDUs. Each packet, termed a TPKT, consists of two parts: a packet-header and a TPDU. We use the same scheme described in RFC1006 for this extension. There is no need to change the version number. The ISO transport TPDU sufficiently describes the transport protocol class being used. The format of the packet-header described below is a repeat from RFC1006. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | vrsn | reserved | packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: vrsn 8 bits This field is always 3 for the version of the protocol described in this memo. packet length 16 bits (min=7, max=65535) The packet length is the length of the entire packet in octets, including packet-header. The format of the ISO transport TPDU is defined in ISO 8073. Y. Pouffary [Page 6] RFC ISO Transport Class 2 Non-use of Explicit April 1995 Flow Control over TCP - RFC1006 Extension 4. DIGITAL DECnet over TCP/IP DECnet over TCP/IP is implemented using the DECnet Session Control layer over this RFC1006 extension protocol. The informational RFC defined in this document provides the Transport Service functionality required by DECnet Applications while operating over TCP/IP. The next paragraph is a brief summary of the role of the DECnet Session Control Layer. For further details, refer to the DIGITAL DNA Session Control Layer Specification. The DECnet Session Control Layer makes a Transport Service available to End Users of a network. This layer is concerned with system- dependent functions related to creating, maintaining, and destroying Transport Connections. Separate virtual data channels, known as "Normal" and "Expedited", are provided to End Users. DECnet Session Control must be guaranteed independence of these channels by the Transport Layer. Expedited Data transmission cannot be blocked by a congested normal data channel. DECnet Session Control requires that all data in transit be delivered before initiating the release of the Transport Connection. DECnet, DNA, and the DIGITAL logo are trademarks of Digital Equipment Corporation. Y. Pouffary [Page 7] RFC ISO Transport Class 2 Non-use of Explicit April 1995 Flow Control over TCP - RFC1006 Extension Acknowledgements Bill Duane, Jim Bound, David Sullivan, Mike Dyer, Matt Thomas, Dan Harrington and many other members of the DECnet engineering team. References [ISO8072] ISO. "International Standard 8072. Information Processing Systems -- Open Systems Interconnection: Transport Service Definition." [ISO8073] ISO. "International Standard 8073. Information Processing Systems -- Open Systems Interconnection: Transport Protocol Specification." [ISO8327] ISO. "International Standard 8327. Information Processing Systems -- Open Systems Interconnection: Session Protocol Specification." [RFC791] Internet Protocol. Request for Comments 791 (MILSTD 1777) [RFC793] Transmission Control Protocol. Request for Comments 793 (MILSTD 1778) [RFC1006] ISO Transport Services on Top of the TCP. Request for Comments 1006 Author' Address Yanick Pouffary End Systems Networking Phone: +33 92-95-62-85 Digital Equipment Corporation Fax: +33 92-95-62-32 Centre Technique (Europe) Email: pouffary@taec.enet.dec.com B.P. 027 950 Routes des colles 06901 Sophia antipolis, France Y. Pouffary [Page 8] ----- End Included Message ----- % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by vbormc.vbo.dec.com; id AA08060; Fri, 28 Apr 95 20:19:00 +0200 % Received: from venera.isi.edu by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA20059; Fri, 28 Apr 1995 11:22:40 -070 % Received: from zen.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id <AA20419>; Fri, 28 Apr 1995 11:18:33 -070 % Date: Fri, 28 Apr 1995 11:18:51 -0700 % From: postel@ISI.EDU % Posted-Date: Fri, 28 Apr 1995 11:18:51 -0700 % Message-Id: <199504281818.AA09355@zen.isi.edu> % Received: by zen.isi.edu (5.65c/4.0.3-4) id <AA09355>; Fri, 28 Apr 1995 11:18:51 -070 % To: iesg@ISI.EDU % Subject: Submission Informational RFC % Cc: taec::pouffary
- RE: RFC1006 extension ISO Transport Class 2 Non-u… Yanick
- Re: RFC1006 extension ISO Transport Class 2 Non-u… Harald.T.Alvestrand