Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03130; 1 Feb 94 9:18 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03126; 1 Feb 94 9:18 EST Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa06275; 1 Feb 94 9:18 EST Received: from noc-gw.lanl.gov by mailhost.lanl.gov (8.6.4/1.2) id HAA18010; Tue, 1 Feb 1994 07:17:15 -0700 Received: from localhost by noc-gw.lanl.gov (8.6.4/SMI-4.1) id HAA03425; Tue, 1 Feb 1994 07:17:52 -0700 Received: from mailhost.lanl.gov by noc-gw.lanl.gov (8.6.4/SMI-4.1) id HAA03422; Tue, 1 Feb 1994 07:17:49 -0700 Received: from heifetz.msen.com by mailhost.lanl.gov (8.6.4/1.2) id HAA17982; Tue, 1 Feb 1994 07:16:47 -0700 Received: from one.one.com by heifetz.msen.com with smtp (Smail3.1.28.1 #12) id m0pRLwv-000Zc4C; Tue, 1 Feb 94 09:19 EST Received: by one.one.com (/\==/\ Smail3.1.24.1 #24.5) id ; Tue, 1 Feb 94 08:53 EST Message-Id: Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jeff Learman Subject: Service/protocol selection To: iso , tuba , sc6wg4 , Lower Layers SIG , Directory Services SIG Date: Tue, 1 Feb 1994 08:53:25 -0500 (EST) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1824 ISO, TUBA, SC6WG4, and NIST LLSIG and DSSIG group members: How should network services (CONS vs. CLNS) be selected for an outgoing transport connection? Is there a standard or convention for indicating in the Directory the services and protocols to be used when establishing communications with an entity? Or is this unnecessary? For this discussion, I am calling a specific selection of services and protocols a "mode". For example, ISO COTS/CLNS is a mode; ISO COTS/CONS is another mode. Is a system required to have a different NSAP for each mode? I don't find any text in any ISO specs that state this explicitly. Is it somehow implied or implicitly preferred? If such a restriction is adopted, the local configuration of "which local NSAP uses which mode" could be made known to the Transport provider, and the proper mode to use for a given connection request would be implied by the source NSAP. Unfortunately, the Transport service user is left guessing which source NSAP to use for a connection to an NSAP discovered in the DIR. If such a restriction is not adopted, additional information must be passed in the connection request primitive, along with the source and destination NSAPs. (Note: this information does not map onto the QOS parameters that are defined in the transport service spec, ISO 8072.) Should additional implementors' agreements or amendments to ISO specs be considered? Thanks for your consideration. Jeff -------------------------------------------------------------------- Jeff Learman Internet: jjl@one.com Open Networks Engineering, Inc Voice: (313)-996-9900 777 E. Eisenhower Pkwy, #650 FAX: (313)-996-9908 Ann Arbor, MI 48108 USA --------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04004; 1 Feb 94 10:01 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04000; 1 Feb 94 10:01 EST Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa07492; 1 Feb 94 10:01 EST Received: from noc-gw.lanl.gov by mailhost.lanl.gov (8.6.4/1.2) id IAA19456; Tue, 1 Feb 1994 08:00:31 -0700 Received: from localhost by noc-gw.lanl.gov (8.6.4/SMI-4.1) id IAA03575; Tue, 1 Feb 1994 08:01:21 -0700 Received: from mailhost.lanl.gov by noc-gw.lanl.gov (8.6.4/SMI-4.1) id IAA03572; Tue, 1 Feb 1994 08:01:20 -0700 Received: from BBN.COM by mailhost.lanl.gov (8.6.4/1.2) id IAA19446; Tue, 1 Feb 1994 08:00:19 -0700 Message-Id: <199402011500.IAA19446@mailhost.lanl.gov> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Day Subject: Re: Service/protocol selection To: jjl@one.com Cc: dssig@nist.gov, iso@nic.ddn.mil, oiw-llsig@osi.ncsl.nist.gov, sc6wg4@ntd.comsat.com, tuba@lanl.gov In-Reply-To: Date: Tue, 1 Feb 94 10:02:09 EST Mail-System-Version: Jeff, > >ISO, TUBA, SC6WG4, and NIST LLSIG and DSSIG group members: > >How should network services (CONS vs. CLNS) be selected for an outgoing >transport connection? > The theory is that the lower layer services is chosen based on the QoS required by the user and the QoS available from the Network layer and the optimization of the cost by the transport layer. In other words, if transport determines that TP4 and CLNS are the cheapest it attempts to use that; if it determines that X.25 is available but flaky and it needs TP4 to ensure QoS it does that; if it determines that X.25 is available and providing pretty reliable service, it might try TP2 or less; if it determines that X.25 connections are cheap (or it doesn't care about the expense) and the X.25 is pretty reliable, it might do TP1, etc. >Is there a standard or convention for indicating in the Directory the >services and protocols to be used when establishing communications >with an entity? Or is this unnecessary? > Unnecessary, strictly speaking. >For this discussion, I am calling a specific selection of services and >protocols a "mode". For example, ISO COTS/CLNS is a mode; ISO COTS/CONS >is another mode. > >Is a system required to have a different NSAP for each mode? I don't >find any text in any ISO specs that state this explicitly. Is it >somehow implied or implicitly preferred? > One can, but the service and protocol assume that both modes may be available at a single NSAP. SAPs are not tightly bound to protocols. >If such a restriction is adopted, the local configuration of "which >local NSAP uses which mode" could be made known to the Transport >provider, and the proper mode to use for a given connection request >would be implied by the source NSAP. Unfortunately, the Transport >service user is left guessing which source NSAP to use for a connection >to an NSAP discovered in the DIR. > >If such a restriction is not adopted, additional information must be >passed in the connection request primitive, along with the source and >destination NSAPs. (Note: this information does not map onto the QOS >parameters that are defined in the transport service spec, ISO 8072.) > No new information is required, but you do need to code it right. The information does map to QoS, but not in the way you are thinking about it. > >Should additional implementors' agreements or amendments to ISO specs >be considered? > Don't see any need, personnally. Take care John   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02481; 2 Feb 94 7:26 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02477; 2 Feb 94 7:26 EST Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa00928; 2 Feb 94 7:26 EST Received: from noc-gw.lanl.gov by mailhost.lanl.gov (8.6.4/1.2) id FAA11115; Wed, 2 Feb 1994 05:25:31 -0700 Received: from localhost by noc-gw.lanl.gov (8.6.4/SMI-4.1) id FAA10237; Wed, 2 Feb 1994 05:25:55 -0700 Received: from mailhost.lanl.gov by noc-gw.lanl.gov (8.6.4/SMI-4.1) id FAA10234; Wed, 2 Feb 1994 05:25:54 -0700 Received: from concorde.inria.fr by mailhost.lanl.gov (8.6.4/1.2) id FAA11105; Wed, 2 Feb 1994 05:24:50 -0700 Received: from givry.inria.fr by concorde.inria.fr; Wed, 2 Feb 1994 13:25:34 +0100 Received: by givry.inria.fr; Wed, 2 Feb 1994 13:25:33 +0100 Message-Id: <199402021225.AA19736@givry.inria.fr> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Francis Dupont To: Richard Colella Cc: wiget@chx400.switch.ch, colella@nist.gov, noop@merit.edu, tuba@lanl.gov, wg-llt-clns@rare.nl Subject: Re: Revision on RFC1237, Guidelines for NSAP allocation In-Reply-To: Your message of Sun, 30 Jan 1994 15:38:26 EST. <9401302038.AA09698@emu.ncsl.nist.gov> Date: Wed, 02 Feb 1994 13:25:17 +0100 X-Orig-Sender: Francis.Dupont@inria.fr X-Charset: ASCII X-Char-Esc: 29 In your previous mail you wrote: I believe we still need the allocation authority (or a designated point of contact who can direct people to one). These days for IP, the IANA, the Internic and RIPE all act as points of contact, with service providers as primary allocation authorities (i.e., to end users). We need to identify a similar set of organizations for CLNP in Europe. => Here is the official answer for France (prefix 39.250f) : Association Francaise de Normalisation -- AFNOR Service S.T.I.A. Tour Europe - Cedex 07 92049 Paris La Defense FRANCE Tel: +33 1 49 91 55 55 Telex: AFNOR 611 974 F Fax: +33 1 42 91 56 56 Minitel: 3616 AFNOR Reference: NF Z 60 000 (enregistrement des noms d'organisation dans le contexte de l'OSI) (with NSAP address format : 39.250f.oooo.oo ... , oooooo = 3 octet organization number) Contact: Ms Marie-Claire Franon, +33 1 42 91 57 06 (ask for a registration form) Price: - number : 3500 F - number+name : 4500 F - fee : 800 F / year (not yet :-) Francis.Dupont@inria.fr PS: we plan to register RENATER (French national research network) as an OSI organisation and to home everybody under its prefix. PPS: we'll put these infos in the RIPE DB ASAP.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13304; 2 Feb 94 15:00 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13300; 2 Feb 94 15:00 EST Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa12549; 2 Feb 94 15:00 EST Received: from noc-gw.lanl.gov by mailhost.lanl.gov (8.6.4/1.2) id MAA12469; Wed, 2 Feb 1994 12:58:16 -0700 Received: from localhost by noc-gw.lanl.gov (8.6.4/SMI-4.1) id MAA13171; Wed, 2 Feb 1994 12:58:55 -0700 Received: from mailhost.lanl.gov by noc-gw.lanl.gov (8.6.4/SMI-4.1) id MAA13167; Wed, 2 Feb 1994 12:58:49 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: tozz@hpindch.cup.hp.com Received: from hp.com by mailhost.lanl.gov (8.6.4/1.2) id MAA12428; Wed, 2 Feb 1994 12:57:45 -0700 Received: from hpindtz.cup.hp.com by hp.com with SMTP (1.36.108.7/15.5+IOS 3.13) id AA02627; Wed, 2 Feb 1994 11:58:45 -0800 Received: by hpindch.cup.hp.com with SMTP (1.37.109.4/15.5+IOS 3.20+cup+OMrelay) id AA01046; Wed, 2 Feb 94 11:58:19 -0800 Message-Id: <9402021958.AA01046@hpindch.cup.hp.com> To: John Day Cc: jjl@one.com, dssig@nist.gov, iso@nic.ddn.mil, oiw-llsig@osi.ncsl.nist.gov, sc6wg4@ntd.comsat.com, tuba@lanl.gov, tozz@hpindch.cup.hp.com, Gerard_Yvraut@hp6300.desk.hp.com Subject: Re: Service/protocol selection In-Reply-To: Your message of "Tue, 01 Feb 94 10:02:09 EST." <9402011457.AA20889@surya.ntd.comsat.com> Date: Wed, 02 Feb 94 11:58:18 -0800 >Jeff, >> >>ISO, TUBA, SC6WG4, and NIST LLSIG and DSSIG group members: >> >>How should network services (CONS vs. CLNS) be selected for an outgoing >>transport connection? >> >The theory is that the lower layer services is chosen based on the QoS >required by the user and the QoS available from the Network layer and >the optimization of the cost by the transport layer. In other words, if >transport determines that TP4 and CLNS are the cheapest it attempts to >use that; if it determines that X.25 is available but flaky and it needs >TP4 to ensure QoS it does that; if it determines that X.25 is available >and providing pretty reliable service, it might try TP2 or less; if it >determines that X.25 connections are cheap (or it doesn't care about the >expense) and the X.25 is pretty reliable, it might do TP1, etc. Yes, but that is "in theory" only. Notice that all the example algorithms described above are "in theory"; there is currently no standard that tells a Transport/Network OSI implementor how to provide this deliberation function in such a way that it is predictable, reliable, and interoperable with all OSI implementations. Also, I am not aware of reasonable (i.e. comercially available for consumption in the real world) implementations of Network and Subnetwork layer functions which allow an accurate enough assessment of Subnetwork QOS so that a transport entity can take advantage of this in its deliberations. For instance, most OSI stacks that I am aware of don't have the ability to detect that a link has gone down and inform the RIB of this fact so that routes can be invalidated. That's pretty basic QOS information even though it is not a specific QOS-encoded parameter in CLNP or CONS. Also, in the above example, you have the Transport Protocol making a determination of which "mode" (to use the term from the original poster) to use on a connection request. What if this "mode" fails, but another "mode" would succeed. There is no mechanism (including TP4) which allows for a retry of a connection request with a possible modification of QOS negotions parameters (at least not from my reading). Let's take a very specific example. Consider System A who wishes to connect to System B. System B is reachable via either a CONS-based network or over a CLNS/802.3 network. Furthermore, let's say that System A is not listening on the all-IS multicast address, so it is not caching End System Hellos. Now, let's assume that the QOS information in the T-Connect allows the transport protocol to use either TP4/CLNS or TP[4,2]/CONS. Let's also assume (and I think this is a VERY VALID assumption) that the owner of these systems would prefer that System A use the cheapest method possible, although if the cheapest method is unavailable, any valid method is okay. AND let us assume that the Transport/Network layer can make an accurate determination of which path is the cheapest (in this example, 802.3 is the cheapest). Now, in the above scenario if one were to examine system A's routing table they would find: 1) an entry for the reachability information for System B over CONS 2) NO reachability information for System B over CLNS If System A were to make a choice about which path to take, either it will make the expensive choice, or it will try the cheap choice first. If it tries the cheap choice first, it had to have done so without knowledge that it would work. This implies that it would try the cheap choice first in cases where it would not work (i.e. assume system C exists that is only reachable over a CONS network) and in order for System A to be of any use, another mechanism must be in place (such as a retry) so that the CONS path gets tried. Now I see two possibilities: the intelligence for deliberating the correct path is embedded within the stack, OR, the intelligence for deliberating the correct method is coded into the user application, EVERY user application! Which one is correct? From you discussion above, it would seem to suggest that you believe that the intelligence should be embedded in the stack. I agree. Think about the difficulties in requiring user applications to provide algorithms to try different paths. Even more importantly, consider the difficulty in supplying the correct information to the user in a format that allows them to make correct decions. Is this a hole in the spec? It seems like a transport protocol which will be capable of handling robust QOS requirements (like we would like ISO transport to be someday) should include QOS deliberation and negotiation in its protocol state machine, not be left as a "local matter" or for "further study" (the two phrases which show up in an ISO spec which gurantee IOP problems). >>Is a system required to have a different NSAP for each mode? I don't >>find any text in any ISO specs that state this explicitly. Is it >>somehow implied or implicitly preferred? >> >One can, but the service and protocol assume that both modes may be >available at a single NSAP. SAPs are not tightly bound to protocols. I am a bit confused about what it means topologically to have the same NSAP value for both CONS and CLNS. Granted, an NSAP identifies a NS-user not a NS-service, or NS-entity. However, consider the preferred encoding of and NSAP for use with ISO 10589 (Intra-domain IS-IS). In this format an NSAP contains an Area ID. Now I could understand an ES where its networks-serviced-by-CONS and its networks-serviced-by-CLNS might be in the same routing domain (but event this gets fuzzy when applied to the definition of routing domain and 10747), but I sure cannot get my teeth around a CONS-based network and a CLNS-based network in the same Area. Doesn't this have some drastic implications about routing protocols, network protocols,etc? So it seems that even though conceptually, the intent of an NSAP was that no distinction be made between NSAPs in the CONS world and NSAPs in the CLNS world, it appears that procedurally, the ISO commitees are not moving in this direction. >>If such a restriction is adopted, the local configuration of "which >>local NSAP uses which mode" could be made known to the Transport >>provider, and the proper mode to use for a given connection request >>would be implied by the source NSAP. Unfortunately, the Transport >>service user is left guessing which source NSAP to use for a connection >>to an NSAP discovered in the DIR. Maybe the way to solve this is to lift the Transport service user from having to make this decision at all. Let's look at another example: Consider a programmer writing a trasnport application that can work over CONS or CLNS equally. This user doesn't care WHICH network layer is being used for each connection, he just cares that the bits get over the "wire" like they are supposed to. What if this programmer could write his application to bind to just the Transport Selector (or alternatively the Transport Selector and all-local-NSAPs). Now, any inbound connection request will be propogated to the user's program irregardless of which network it came in on. For outbound, the calling NSAP is chosen based on the reachability information for the destination NSAP. This could be done in several ways: 1) Each interface to a subnetwork could be given a "primary" or "default" NSAP value. This NSAP doesn't have to be unique for each subnetwork. 2) Each NSAP is given a CONS or CLNS preference. Then the outgoing subnetwork is obtained from the reachability information and the subnetworks type is used to decide which NSAP to use. There are probably other method as well. >>If such a restriction is not adopted, additional information must be >>passed in the connection request primitive, along with the source and >>destination NSAPs. (Note: this information does not map onto the QOS >>parameters that are defined in the transport service spec, ISO 8072.) >> >No new information is required, but you do need to code it right. The >information does map to QoS, but not in the way you are thinking about it. What way is that? I am curious as well to know how this maps to existing QOS. Could you give us some real-life examples of how this might work? >> >>Should additional implementors' agreements or amendments to ISO specs >>be considered? >> >Don't see any need, personnally. Actually, I do see a need, and this is why. Today QOS is not mature enough to allow implementors to use it in a robust manner to provide the type of deliberation which they will utimately desire it to provide. Also, vendors' and Netowork Carriers' do not provide the correct information necessary to make QOS judgements about QOS even if it were able to be encoded by implementors. Therefore, it seems that a body such as OIW would be an ideal place to specify implementors agreements on how to perform such deliberation in lieu of well established and supported procedures in place by ISO and vendors. Part of this deliberation might be making recommendations on separate NSAP spaces for CONS and CLNS, and a migration path to unify them once QOS is mature enough to perform the actions that are not performable today. If we want the OSI protocol suite to evolve, it has to have a commercial foundation. This means it has to be in the economic interest of implementors to use it. My contention is that Implementors agreements bridge the gap between "theoretical" and actual, giving implementors a path towards using the concepts that we are creating. Bob Tausworthe Hewlett Packard 19420 Homestead rd Cupertino, Ca 95118 (408) 447-2873 tozz@cup.hp.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13781; 2 Feb 94 15:18 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13776; 2 Feb 94 15:18 EST Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa13007; 2 Feb 94 15:18 EST Received: from noc-gw.lanl.gov by mailhost.lanl.gov (8.6.4/1.2) id NAA13405; Wed, 2 Feb 1994 13:17:10 -0700 Received: from localhost by noc-gw.lanl.gov (8.6.4/SMI-4.1) id NAA13372; Wed, 2 Feb 1994 13:17:56 -0700 Received: from mailhost.lanl.gov by noc-gw.lanl.gov (8.6.4/SMI-4.1) id NAA13369; Wed, 2 Feb 1994 13:17:55 -0700 Received: from vangogh.CS.Berkeley.EDU by mailhost.lanl.gov (8.6.4/1.2) id NAA13366; Wed, 2 Feb 1994 13:16:55 -0700 Received: from localhost (sklower@localhost) by vangogh.CS.Berkeley.EDU (8.6.6.Beta0/8.6.5.Beta12) id MAA05844 for tuba@lanl.gov; Wed, 2 Feb 1994 12:17:31 -0800 Date: Wed, 2 Feb 1994 12:17:31 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Sklower Message-Id: <199402022017.MAA05844@vangogh.CS.Berkeley.EDU> To: tuba@lanl.gov Subject: practical interim solution for CONS/CLNS distinction While not necessarily being the best, or the right thing to do, the BSD/OSI code base uses the routing table. It looks up the destination, and examines a protocol-specific flag which means "Try CONS first". (We were forced to do something because my german friends were implementing X.25 over ethernet).   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09654; 3 Feb 94 11:44 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09650; 3 Feb 94 11:44 EST Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa12168; 3 Feb 94 11:44 EST Received: from noc-gw.lanl.gov by mailhost.lanl.gov (8.6.4/1.2) id JAA10657; Thu, 3 Feb 1994 09:42:50 -0700 Received: from localhost by noc-gw.lanl.gov (8.6.4/SMI-4.1) id JAA20811; Thu, 3 Feb 1994 09:43:13 -0700 Received: from mailhost.lanl.gov by noc-gw.lanl.gov (8.6.4/SMI-4.1) id JAA20808; Thu, 3 Feb 1994 09:43:11 -0700 Received: from BBN.COM by mailhost.lanl.gov (8.6.4/1.2) id JAA10618; Thu, 3 Feb 1994 09:42:09 -0700 Message-Id: <199402031642.JAA10618@mailhost.lanl.gov> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Day Subject: Re: Service/protocol selection To: tozz@hpindch.cup.hp.com Cc: Day@bbn.com, dssig@nist.gov, Gerard_Yvraut@hp6300.desk.hp.com, iso@nic.ddn.mil, jjl@one.com, oiw-llsig@osi.ncsl.nist.gov, sc6wg4@ntd.comsat.com, tuba@lanl.gov In-Reply-To: <9402021958.AA01046@hpindch.cup.hp.com> Date: Thu, 3 Feb 94 11:32:42 EST Mail-System-Version: Bob >>The theory is that the lower layer services is chosen based on the >>QoS >>required by the user and the QoS available from the Network layer and >>the optimization of the cost by the transport layer. > >Yes, but that is "in theory" only. Notice that all the example algorithms >described above are "in theory"; there is currently no standard that tells >a Transport/Network OSI implementor how to provide this deliberation function >in such a way that it is predictable, reliable, and interoperable with all >OSI implementations. Standards! Do you always have to have someone tell you how to do it? You don't need any standards. How many times do we have to say that standards are not design specifications? All aspects of the implementation and how it is used in a host are not going to be in the protocol spec. There is no need to pass QoS in transport protocol. The tranport layer may ask for something but that doesn't mean that the network will *provide* it. Transport must *observe* what the network actually provides on connections it opens to/from various places and base its decisions on that, regardless of what it asked for. (I know you are going to ask, what do I do when I have never opened a connection to a particular host? Do what any good engineer does, make an educated guess based on the data you have and then collect more data and refine your estimate.) QoS is always relative to the requestor. The QoS seen by anyone else is totally meaningless. Just because some other host got a certain level of service doesn't mean you will. So it doesn't matter what parameters someone else chooses, choose your own, collect information and use it, to make a decision. This can be an entirely local matter. It might be nice if everyone agreed, but it isn't necessary to do it in product and doesn't need to be in TP4. You don't need to wait for someone else to tell you what to do. >Also, I am not aware of reasonable (i.e. comercially >available for consumption in the real world) implementations of >Network and Subnetwork layer functions which allow an accurate enough >assessment of Subnetwork QOS so that a transport entity can take advantage >of this in its deliberations. Does HP always wait for there to be commerically available product before providing a feature? What an odd way to make money! >For instance, most OSI stacks that I am aware >of don't have the ability to detect that a link has gone down and inform >the RIB of this fact so that routes can be invalidated. That's pretty basic >QOS information even though it is not a specific QOS-encoded parameter in >CLNP or CONS. > The error conditions to detect it are in the protocols and the capability to make use of it is clearly in the purview of a competent implementation. Again, nothing more is required in the standards. If the implementations don't do it then there are bad implementations out there. >Also, in the above example, you have the Transport Protocol making a >determination of which "mode" (to use the term from the original poster) >to use on a connection request. What if this "mode" fails, but another "mode" >would succeed. There is no mechanism (including TP4) which allows for a >retry of a connection request with a possible modification of QOS negotions >parameters (at least not from my reading). > Once again, it is not prohibited by the standard and it is entirely local matter, i.e. it does not violate the sequencing rules of the protocol exchange, so there is no reason why you can't implement it that way. No mechanism is required in TP4 protocol spec. Now clearly a mechanism IS required in the TP4 implementation spec and how sophisticated you want to get depends on the implementor. >Now I see two possibilities: the intelligence for deliberating the correct >path is embedded within the stack, OR, the intelligence for deliberating >the correct method is coded into the user application, EVERY user application! > >Which one is correct? From you discussion above, it would seem to suggest that >you believe that the intelligence should be embedded in the stack. I agree. >Think about the difficulties in requiring user applications to provide >algorithms to try different paths. Even more importantly, consider the >difficulty in supplying the correct information to the user in a format >that allows them to make correct decions. > >Is this a hole in the spec? It seems like a transport protocol which will >be capable of handling robust QOS requirements (like we would like ISO >transport to be someday) should include QOS deliberation and negotiation in >its protocol state machine, not be left as a "local matter" or for "further >study" (the two phrases which show up in an ISO spec which gurantee IOP >problems). > It is not a hole in the spec. It is a local matter. I reiterate, you may ask the network layer for certain QoS (and that would require a standard). But it doesn't mean you are going to get it. Even with QoS standardized a lot of this will still be local. >>>Is a system required to have a different NSAP for each mode? I don't >>>find any text in any ISO specs that state this explicitly. Is it >>>somehow implied or implicitly preferred? >>> >>One can, but the service and protocol assume that both modes may be >>available at a single NSAP. SAPs are not tightly bound to protocols. > >I am a bit confused about what it means topologically to have the same >NSAP value for both CONS and CLNS. Granted, an NSAP identifies a NS-user >not a NS-service, or NS-entity. However, consider the preferred encoding >of and NSAP for use with ISO 10589 (Intra-domain IS-IS). In this format >an NSAP contains an Area ID. Now I could understand an ES where its >networks-serviced-by-CONS and its networks-serviced-by-CLNS might be in >the same routing domain (but event this gets fuzzy when applied to the >definition of routing domain and 10747), but I sure cannot get my teeth >around a CONS-based network and a CLNS-based network in the same Area. >Doesn't this have some drastic implications about routing protocols, >network protocols,etc? > Not really, Routing protocols for CO and CL are basically the same. The only difference with CO is you make routing decisions much less often. Essentially a connection is a very long packet. >So it seems that even though conceptually, the intent of an NSAP was that >no distinction be made between NSAPs in the CONS world and NSAPs in the >CLNS world, it appears that procedurally, the ISO commitees are not moving >in this direction. > No, they aren't. As near as I can tell they are already there. >>>If such a restriction is adopted, the local configuration of "which >>>local NSAP uses which mode" could be made known to the Transport >>>provider, and the proper mode to use for a given connection request >>>would be implied by the source NSAP. Unfortunately, the Transport >>>service user is left guessing which source NSAP to use for a connection >>>to an NSAP discovered in the DIR. > Not at all. >Maybe the way to solve this is to lift the Transport service user from >having to make this decision at all. Let's look at another example: Consider >a programmer writing a trasnport application that can work over CONS or >CLNS equally. This user doesn't care WHICH network layer is being used >for each connection, he just cares that the bits get over the "wire" like >they are supposed to. What if this programmer could write his application >to bind to just the Transport Selector (or alternatively the Transport >Selector and all-local-NSAPs). What do you mean "if he could" The user better be able to build his application so that it isn't bound to a particular T-Sel or T-Addr; otherwise, you have a pretty lousy API. >Now, any inbound connection request will >be propogated to the user's program irregardless of which network it >came in on. This is the way it is supposed to work. The reason for AE-Titles and T-sels and all is so that it doesn't matter what network it came in on. >For outbound, the calling NSAP is chosen based on the reachability >information for the destination NSAP. This could be done in several ways: > > 1) Each interface to a subnetwork could be given a "primary" > or "default" NSAP value. This NSAP doesn't have to be unique > for each subnetwork. > > 2) Each NSAP is given a CONS or CLNS preference. Then the > outgoing subnetwork is obtained from the reachability > information and the subnetworks type is used to decide > which NSAP to use. > I don't understand at all what your point here is. >There are probably other method as well. > >>>If such a restriction is not adopted, additional information must be >>>passed in the connection request primitive, along with the source and >>>destination NSAPs. (Note: this information does not map onto the QOS >>>parameters that are defined in the transport service spec, ISO 8072.) >>> >>No new information is required, but you do need to code it right. The >>information does map to QoS, but not in the way you are thinking about it. > >What way is that? I am curious as well to know how this maps to existing QOS. >Could you give us some real-life examples of how this might work? > Does this mean that HP is going to contract me to do their design for them? I look forward to the request. >>> >>>Should additional implementors' agreements or amendments to ISO specs >>>be considered? >>> >>Don't see any need, personnally. > >Actually, I do see a need, and this is why. Today QOS is not mature enough >to allow implementors to use it in a robust manner to provide the type of >deliberation which they will utimately desire it to provide. Also, vendors' >and Netowork Carriers' do not provide the correct information necessary to >make QOS judgements about QOS even if it were able to be encoded by >implementors. > You can't put the blame on network carriers as much as I wish you could. The host and transport can observe all of the information they need to make the decision and any way if you think you can trust the network to give you accurate numbers of how well they are providing you service, then you need to talk to people who run real networks. No one believes the quality numbers they are provided and compares them against their own. >If we want the OSI protocol suite to evolve, it has to have a commercial >foundation. This means it has to be in the economic interest of implementors >to use it. My contention is that Implementors agreements bridge the >gap between "theoretical" and actual, giving implementors a path towards >using the concepts that we are creating. Everyone complains that ISO doesn't implement first. That is not strictly true. ISO is based on a capitalist model of technology development that assumes that there is competitive advantage to the implementations. Therefore implementations are therefore done by the those who have the potential to profit from this. Standards are the minimal agreements required for interworking that don't give away all of those competitive advantages in the implementation. The Internet protocols on the other hand are based on a welfare model that believes that the implementation is communal property and should be paid for by the government. Apparently so does HP. Doing this is straightforward engineering. There is no black magic or even anything really deep. All it requires is some thought and considered implementation. Take care John   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08516; 4 Feb 94 9:45 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08512; 4 Feb 94 9:45 EST Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa07819; 4 Feb 94 9:45 EST Received: from noc-gw.lanl.gov by mailhost.lanl.gov (8.6.4/1.2) id HAA07585; Fri, 4 Feb 1994 07:44:14 -0700 Received: from localhost by noc-gw.lanl.gov (8.6.4/SMI-4.1) id HAA27040; Fri, 4 Feb 1994 07:44:51 -0700 Received: from mailhost.lanl.gov by noc-gw.lanl.gov (8.6.4/SMI-4.1) id HAA27037; Fri, 4 Feb 1994 07:44:45 -0700 Received: from emu.ncsl.nist.gov by mailhost.lanl.gov (8.6.4/1.2) id HAA07493; Fri, 4 Feb 1994 07:43:40 -0700 Received: by emu.ncsl.nist.gov (4.1/NIST(rbj/dougm)) id AA13908; Fri, 4 Feb 94 09:51:47 EST Date: Fri, 4 Feb 94 09:51:47 EST Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9402041451.AA13908@emu.ncsl.nist.gov> To: wk04464@worldlink.com Subject: Request Guidelines for NSAP allocation to move to Draft Standard Cc: colella@nist.gov, noop@merit.edu, tuba@lanl.gov Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: colella@nist.gov Reply-To: colella@nist.gov Dave, Since you're one of the former ADs for the no-longer extant OSI Area, I believe this is in your bailywick as a left-over item. I'm requesting that I-D draft-ietf-osinsap-allocation-01.txt, "Guidelines for OSI NSAP Allocation in the Internet," be advanced from its current status as a Proposed Standard (as RFC1237) and published as a Draft Standard RFC. Below is some relevant information on the state of the document. --Richard ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Status of "Guidelines for OSI NSAP Allocation in the Internet" Abstract -------- CLNP is currently being deployed in the Internet. This is useful to support OSI and DECnet(tm) traffic. In addition, CLNP can be used to support TCP- and UDP-based applications as described in RFC 1347 [17]. Required as part of the CLNP infrastructure are guidelines for network service access point (NSAP) address assignment. This paper provides guidelines for allocating NSAP addresses in the Inter- net. The guidelines provided in this paper have been the basis for initial deployment of CLNP in the Internet, and have proven very valuable both as an aid to scaling of CLNP routing, and for address adminis- tration. Changes between RFC1237 and the I-D ----------------------------------- The I-D has been updated with: - input from RARE on the RARE NSAP format, - information about how IDRP interacts with the allocation scheme (note that it does not change the allocation scheme), and, - less of an emphasis on a hierarchical set of service providers and more as a mesh of providers (this is primarily cosmetic). Implementation Audit Trail -------------------------- Vendors that have CLNP and associated routing protocols that implement NSAPs according to the Guidelines include: 3com cisco DEC HP IBM Proteon Sun Wellfleet Organizations that have used the Guidelines as the basis for allocations include: AlterNet BARRNet ESNet Europanet Nearnet NSFNet NSI SESQUINET/Texas SURANet US Department of Defense Registration Authority WG Review and Consensus ----------------------- This document has been in active use for over two years. A recent request to interested working groups (NOOP and TUBA) resulted in no objection to it moving forward. Optional Functionality ---------------------- There is no optional functionality.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19243; 4 Feb 94 14:32 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19238; 4 Feb 94 14:32 EST Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa16207; 4 Feb 94 14:32 EST Received: from noc-gw.lanl.gov by mailhost.lanl.gov (8.6.4/1.2) id MAA29631; Fri, 4 Feb 1994 12:31:06 -0700 Received: from localhost by noc-gw.lanl.gov (8.6.4/SMI-4.1) id MAA29701; Fri, 4 Feb 1994 12:31:44 -0700 Received: from mailhost.lanl.gov by noc-gw.lanl.gov (8.6.4/SMI-4.1) id MAA29698; Fri, 4 Feb 1994 12:31:43 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by mailhost.lanl.gov (8.6.4/1.2) id MAA29604; Fri, 4 Feb 1994 12:30:42 -0700 Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA08976; Fri, 4 Feb 94 11:22:57 -0800 Received: by xirtlu.zk3.dec.com; id AA21689; Fri, 4 Feb 1994 14:22:38 -0500 Message-Id: <9402041922.AA21689@xirtlu.zk3.dec.com> To: Day@bbn.com Cc: tozz@hpindch.cup.hp.com, tuba@lanl.gov Subject: Re: Service/protocol selection In-Reply-To: Your message of "Thu, 03 Feb 94 11:32:42 EST." <199402031642.JAA10618@mailhost.lanl.gov> Date: Fri, 04 Feb 94 14:22:32 -0500 X-Mts: smtp John, Just a few generic clarity comments/questions on your mail to Bob. I am going to separate what you responded to with ----'s and then go back to our normal response semantics. As this is the TUBA list my responses are for TCP/IP infrastructure suite and not the OSI suite, so I am responding with TCP / UDP in mind. p.s. I only sent this to you and bob as one of these lists is causing me to hang to long when sending mail. So if you want to forward be my guest, I will cc tuba too. cc: tozz@hpindch.cup.hp.com, dssig@nist.gov, Gerard_Yvraut@hp6300.desk.hp.com, iso@nic.ddn.mil, jjl@one.com, oiw-llsig@osi.ncsl.nist.gov, sc6wg4@ntd.comsat.com, tuba@Lanl.GOV, thanks /jim ---------------------------------------- Bob >>The theory is that the lower layer services is chosen based on the >>QoS >>required by the user and the QoS available from the Network layer and >>the optimization of the cost by the transport layer. > >Yes, but that is "in theory" only. Notice that all the example algorithms >described above are "in theory"; there is currently no standard that tells >a Transport/Network OSI implementor how to provide this deliberation function >in such a way that it is predictable, reliable, and interoperable with all >OSI implementations. ---------------------------------------- >Standards! Do you always have to have someone tell you how to do it? >You don't need any standards. How many times do we have to say that >standards are not design specifications? All aspects of the >implementation and how it is used in a host are not going to be in the >protocol spec. They are not design specifications but they are and must be interoperability specifications. Customers rely on that fact so they can purchase systems from multiple vendors so they will plug and play. >There is no need to pass QoS in transport protocol. The tranport layer >may ask for something but that doesn't mean that the network will >*provide* it. Transport must *observe* what the network actually >provides on connections it opens to/from various places and base its >decisions on that, regardless of what it asked for. (I know you are >going to ask, what do I do when I have never opened a connection to a >particular host? Do what any good engineer does, make an educated guess >based on the data you have and then collect more data and refine your >estimate.) QoS is always relative to the requestor. The QoS seen by >anyone else is totally meaningless. Just because some other host got a >certain level of service doesn't mean you will. So it doesn't matter >what parameters someone else chooses, choose your own, collect >information and use it, to make a decision. This can be an entirely >local matter. It might be nice if everyone agreed, but it isn't >necessary to do it in product and doesn't need to be in TP4. You don't >need to wait for someone else to tell you what to do. I think applications will want to be able to take advantage of QoS like features in the network. I don't believe applications should leave all these decisions up to their network provider? Is that what your saying. This is a key technical belief point for IPng? ---------------------------------------------------------- >Also, I am not aware of reasonable (i.e. comercially >available for consumption in the real world) implementations of >Network and Subnetwork layer functions which allow an accurate enough >assessment of Subnetwork QOS so that a transport entity can take advantage >of this in its deliberations. -------------------------------------------------------- >Does HP always wait for there to be commerically available product >before providing a feature? What an odd way to make money! When any vendor builds network management applications for the market today they will reach the greatest profit return if they can manage all systems on the customers network. If all vendors are operating under the same set of specs then the engineering costs are reduced to design, analyze, and cdoe the implementation. This result is better time to market for the market place and less cost. This is IMHO one of the reasons the TCP/IP suite is so successful as a business and market. By not defining the Subnetwork QoS or other such parameters it is very difficult to predict interoperability and debugging times. From a math perspective its very dificult to solve differential equations without using parametric equations. The parametric equations are not standard but they are based on a set of rules. Once you have an equation that solves the problem it can be put into a computer as static storage in the code or a macro. Then all engineers can use that function. In the market the parametric equations are our TCP/IP specifications. We need those specifications to reach the Open Systems networking market to attain the maximum functionality in a multivendor environment. --------------------------------------- >For instance, most OSI stacks that I am aware >of don't have the ability to detect that a link has gone down and inform >the RIB of this fact so that routes can be invalidated. That's pretty basic >QOS information even though it is not a specific QOS-encoded parameter in >CLNP or CONS. > ----------------------------------- >The error conditions to detect it are in the protocols and the >capability to make use of it is clearly in the purview of a competent >implementation. Again, nothing more is required in the standards. If >the implementations don't do it then there are bad implementations out >there. I simply agree with Bob based on my diatribe above. Most of the rest of this was very OSI Transport centric (which we are not changing in TUBA) and thats OK but I do believe for IPng its critical that we not leave all the hard stuff up to implementations and define specs for pieces like those discussed in this mail exchange. /jim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13626; 7 Feb 94 11:35 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13621; 7 Feb 94 11:35 EST Received: from [128.165.5.12] by CNRI.Reston.VA.US id aa19598; 7 Feb 94 11:35 EST Received: from noc-gw.lanl.gov by mailhost.lanl.gov (8.6.4/1.2) id JAA25741; Mon, 7 Feb 1994 09:33:36 -0700 Received: from localhost by noc-gw.lanl.gov (8.6.4/SMI-4.1) id JAA08922; Mon, 7 Feb 1994 09:33:57 -0700 Received: from mailhost.lanl.gov by noc-gw.lanl.gov (8.6.4/SMI-4.1) id JAA08919; Mon, 7 Feb 1994 09:33:56 -0700 Received: from lobster.wellfleet.com by mailhost.lanl.gov (8.6.4/1.2) id JAA25676; Mon, 7 Feb 1994 09:32:54 -0700 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA04455; Mon, 7 Feb 94 11:18:13 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA03237; Mon, 7 Feb 94 11:28:03 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA20562; Mon, 7 Feb 94 11:38:26 EST Date: Mon, 7 Feb 94 11:38:26 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ross Callon Message-Id: <9402071638.AA20562@cabernet.wellfleet> To: Day@bbn.com Subject: Re: Service/protocol selection Cc: tuba@lanl.gov I must confess that I don't understand how a discussion of OSI Connection-Oriented versus Connectionless service selection has anything at all to do with Tuba. Tuba is a transition method, which has become associated with the proposed use of CLNP as IPng. However, Tuba has nothing at all to do with Connection-Oriented OSI network service, nor with OSI upper layers. Thus I think that this discussion is at best mis-placed, and may be confusing to some people. Ross   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17856; 7 Feb 94 13:33 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17852; 7 Feb 94 13:33 EST Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa22272; 7 Feb 94 13:33 EST Received: from noc-gw.lanl.gov by mailhost.lanl.gov (8.6.4/1.2) id LAA10739; Mon, 7 Feb 1994 11:31:43 -0700 Received: from localhost by noc-gw.lanl.gov (8.6.4/SMI-4.1) id LAA10783; Mon, 7 Feb 1994 11:32:32 -0700 Received: from mailhost.lanl.gov by noc-gw.lanl.gov (8.6.4/SMI-4.1) id LAA10780; Mon, 7 Feb 1994 11:32:31 -0700 Received: from vangogh.CS.Berkeley.EDU by mailhost.lanl.gov (8.6.4/1.2) id LAA10724; Mon, 7 Feb 1994 11:31:29 -0700 Received: from localhost (sklower@localhost) by vangogh.CS.Berkeley.EDU (8.6.6.Beta0/8.6.5.Beta12) id KAA17540 for tuba@lanl.gov; Mon, 7 Feb 1994 10:32:14 -0800 Date: Mon, 7 Feb 1994 10:32:14 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Sklower Message-Id: <199402071832.KAA17540@vangogh.CS.Berkeley.EDU> To: tuba@lanl.gov Subject: BSD tuba code now publically available. I am very, very happy to announce that upon reading the enclosed press release I called up one of the guardians of the Hen-House who has given me permission to make publically available certain very limited portions of the Berkeley 4.4 release, which has now been blessed by lawyers as not containing USL propriatery code nor intellectual property. I do not suggest that this code will drop in unchanged anywhere, or that it is necessarily free of bugs. But you may find it helpful in implementing TCP over CLNP in some other context. You may obtain the tuba "care package" via anonymous ftp from vangogh.cs.berkeley.edu:~ftp/pub/kls/tuba.tar.Z Now, here comes the tedious marketing message - >From bostic@vangogh.CS.Berkeley.EDU Sun Feb 6 19:20:02 1994 Received: from python.bostic.com (python.BOSTIC.COM [198.3.132.1]) by vangogh.CS.Berkeley.EDU (8.6.6.Beta0/8.6.5.Beta12) with ESMTP id TAA07138; Sun, 6 Feb 1994 19:19:29 -0800 Received: from localhost by python.bostic.com (8.6.4/2.6) id WAA10239; Sun, 6 Feb 1994 22:13:34 -0500 Date: Sun, 6 Feb 1994 22:13:34 -0500 From: bostic@vangogh.CS.Berkeley.EDU (Keith Bostic) Message-Id: <199402070313.WAA10239@python.bostic.com> To: /tmp/emailannounce@python.bostic.com Subject: UCB/USL lawsuit settled Status: R FOR IMMEDIATE RELEASE UNIX System Laboratories, Inc. and the University of California, Berkeley have announced they have reached an agreement resolving their disputes. The settlement clears the way for the University to release a new, unencumbered version of the Berkeley 4.4 BSD operating system software, to be called 4.4 BSD-Lite. Ray Noorda, Chairman of Novell, Inc., which recently acquired USL, called the settlement an "excellent example of what can be accomplished by cooperation between the business and academic communities." Mr. Noorda stated that "the settlement permits the University to accomplish its goals but preserves USL's legitimate interest in protecting its intellectual property." David Hodges, Dean of the College of Engineering at University of California, Berkeley, said that the settlement "once again allows the University to resume its leading role of providing computer software technology transfer to industry. By providing wide distribution of 4.4 BSD-Lite with minimal restrictions on its use, the University will continue to be the focal point for both software research in and commercial development of truly open systems." The University of California was one of the earliest licensees of UNIX operating system software, origi- nally developed at AT&T's Bell Laboratories. In the 1980s, Berkeley's Computer Systems Research Group issued a series of "Berkeley Software Distributions" containing modifications to the UNIX software. However, because of licensing restrictions, public access to the source code for many of those modifications has been limited to firms holding licenses from USL, which acquired the rights to the UNIX system from AT&T. In July 1991, the University issued the "Second Networking Release," also known as Net2, which was intended to make available to the public those portions of the Berkeley Software Distributions which were not subject to license restrictions. However, USL brought a lawsuit against the University, claiming that portions of the release contained restricted material. The University denied USL's claims. It also brought a separate action against USL alleging that USL had violated the terms of its Berkeley Software Distribution, also known as BSD, license agreements by failing to give the University credit for certain material in the UNIX release. Over the past several months, attorneys and computer scientists representing the University and USL have worked together in an effort to reach a compromise on their disputes. The result of these efforts will be a new, unencumbered version of the latest Berkeley Software Distribution called 4.4 BSD-Lite which will retain virtually all of the functionality of the Second Networking Release along with a number of enhancements from the University's latest 4.4 BSD release. The settlement restricts further use and distri- bution of certain files in the Second Networking Release and requires that certain files in 4.4 BSD-Lite include a USL copyright notice. In addition to providing several enhancements, the new 4.4 BSD-Lite Release will replace most of the restricted files and incorporates all the agreed-upon modifications and notices. Thus, 4.4 BSD-Lite will not require a license from nor payment of royalties to USL. The University strongly recommends that 4.4 BSD-Lite be substi- tuted for Net2. Although it has denied the University's claims, USL has also agreed to affix the University's copyright notice to certain files distributed with future releases of the UNIX system and to give credit to the University for material derived from BSD releases which have been included in the UNIX system. Copies of the source code for 4.4 BSD-Lite may be obtained from the University at nominal cost. Source code copies and further information on 4.4 BSD-Lite and the restrictions on Net2 may be obtained from the Computer Systems Research Group at (510) 642-7780. Information may also be obtained from USL's licensing offices at 1-800-828-UNIX.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19784; 17 Feb 94 18:49 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19777; 17 Feb 94 18:49 EST Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa22539; 17 Feb 94 18:49 EST Received: from noc-gw.lanl.gov by mailhost.lanl.gov (8.6.4/1.2) id QAA20885; Thu, 17 Feb 1994 16:47:35 -0700 Received: from localhost by noc-gw.lanl.gov (8.6.4/SMI-4.1) id QAA06885; Thu, 17 Feb 1994 16:48:08 -0700 Received: from mailhost.lanl.gov by noc-gw.lanl.gov (8.6.4/SMI-4.1) id QAA06882; Thu, 17 Feb 1994 16:48:07 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: shin@hodaka.mfd.cs.fujitsu.co.jp Received: from fwide.fujitsu.co.jp by mailhost.lanl.gov (8.6.4/1.2) id QAA20854; Thu, 17 Feb 1994 16:47:01 -0700 Received: from fdm.fujitsu.co.jp by fwide.fujitsu.co.jp (4.1/6.4J.6-MX1.1) id AA26929; Fri, 18 Feb 94 08:48:02 JST Received: from [133.161.1.84] by fdm.fujitsu.co.jp (5.65/6.4J.6) id AA25591; Fri, 18 Feb 94 08:47:55 +0900 Received: from hodaka.mfd.cs.fujitsu.co.jp by mfdgw.mfd.cs.fujitsu.co.jp (5.67+1.6W[+alpha]/6.4J[+CSMX]) id AA01517; Fri, 18 Feb 94 08:47:53 JST Received: from shin (shin.ARPA) by hodaka.mfd.cs.fujitsu.co.jp (4.12/6.4J.5) id AA16467; Fri, 18 Feb 94 08:48:43 JST Date: Fri, 18 Feb 94 08:48:43 JST Message-Id: <9402172348.AA16467@hodaka.mfd.cs.fujitsu.co.jp> To: tuba <@cs.ucl.ac.uk:tuba@lanl.gov.idmr>, rolc@network.com Subject: test X-Mailer: Harada's PC/M [v1.5] This is test message to check if my mail address is registered in list, because it has changed. I informed the administrater of it, but no reply has returned. Sorry for bothering everyone. Please ignore this message. -- Yoshinobu Inoue Architecture Department Network Division Open Systems Group Fujitsu Limited   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11426; 22 Feb 94 15:01 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11422; 22 Feb 94 15:01 EST Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa14646; 22 Feb 94 15:01 EST Received: from noc-gw.lanl.gov by mailhost.lanl.gov (8.6.4/1.2) id MAA19692; Tue, 22 Feb 1994 12:59:37 -0700 Received: from localhost by noc-gw.lanl.gov (8.6.4/SMI-4.1) id MAA03358; Tue, 22 Feb 1994 12:59:53 -0700 Received: from mailhost.lanl.gov by noc-gw.lanl.gov (8.6.4/SMI-4.1) id MAA03355; Tue, 22 Feb 1994 12:59:46 -0700 Received: from SMCVAX.SMCVT.EDU by mailhost.lanl.gov (8.6.4/1.2) id MAA19590; Tue, 22 Feb 1994 12:58:41 -0700 Received: from SMCVAX.SMCVT.EDU by SMCVAX.SMCVT.EDU (PMDF #3520 ) id <01H96UHXRQ4G8Y56CP@SMCVAX.SMCVT.EDU>; Tue, 22 Feb 1994 14:46:30 EST Date: 22 Feb 1994 14:46:29 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Gary C. Kessler, +1 802-655-8633" Subject: 19th LCN: Deadline approaching for paper submission... To: atm@hpl.hp.com, comp.dcom.cell-relay@indiana.edu, cellular@dfv.rwth-aachen.de, confctrl@isi.edu, fc-ip-ext@think.com, fddi-sync@merit.edu, frftc@nsco.network.com, hippi@think.com, isdn@list.prime.com, repeater%sunoco@relay.nswc.navy.mil, rolc@network.com, smdstc@nsco.network.com, smds-users@nas.nasa.gov, snmp2@thumper.bellcore.com, snmp-wg@ns.psi.net, st@ibminet.awdpa.ibm.com, tcp-ip@nic.ddn.mil, tuba@lanl.gov, wireless@tandem.com Message-id: <01H96UHXRQ4I8Y56CP@SMCVAX.SMCVT.EDU> Organization: Saint Michael's College X-VMS-To: @[.LCN]LCNLIST MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi everyone. Just a reminder that the deadline is approaching for submission of papers to the 19th Annual Conference on Local Computer Networks. Papers will be accepted up until 28 March. Please contact me at the address below if you'd like a(nother) Call for Papers. Thanks! /gary c. kessler Program Chair, 19th LCN Hill Associates 17 Roosevelt Highway Colchester, VT 05446 +1 802-655-8633 +1 802-655-7974 kumquat@smcvax.smcvt.edu