⟦ad2cc231b⟧

TextFile

% -*- LaTeX -*-		(really SLiTeX)

\documentstyle[blackandwhite,landscape,oval,pagenumbers,small]{NRslides}

\font\xx=cmbx10
\font\yy=cmbx7

\raggedright

\input trademark
\let\tradeNAMfont=\relax
\let\tradeORGfont=\relax

\begin{document}

\title	{RECENT DEVELOPMENTS WITH OSI}
\author	{Marshall T.~Rose\\ The Wollongong Group, Inc.}
\date	{May 23, 1988}
\maketitlepage


\f

\begin{bwslide}
\part*	{AGENDA}\bf

\begin{description}
\item[PART I:]		OSI: MOTIVATION AND STATUS REPORT

\item[PART II:]		STRATEGIES FOR TRANSITION/COEXISTENCE 

\item[PART III:]	THE ISO DEVELOPMENT ENVIRONMENT
\end{description}
\end{bwslide}


\f

\begin{bwslide}
\part	{OSI: MOTIVATION AND STATUS REPORT}

\begin{nrtc}
\item	THE STATUS QUO

\item	THE UPPER-LAYER ARCHITECTURE

\item	THE LOWER-LAYER ARCHITECTURE
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part*	{THE STATUS QUO}\bf

\begin{nrtc}
\item	OSI STANDARDS AND VENDOR AGREEMENTS ARE FINALLY REACHING STABLE STATUS

\item	THE GOSIP WILL PROVIDE THE INITIAL DEMAND FOR OSI IN THE U.S.

\item	HOWEVER, THE TECHNOLOGY STILL REQUIRES REFINEMENT AND TUNING
    \begin{nrtc}
    \item	CURRENT OSI OFFERINGS ARE REALLY CLOSER TO EXPERIMENTS THAN TO
		PRODUCTS

    \item	MOST ARE ALSO SPECIFIC TO MAP/TOP
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{GOSIP}

\begin{nrtc}
\item	A (SOON-TO-BE) FEDERAL INFORMATION PROCESSING STANDARD

\item	PROPOSED TO ENABLE USERS TO SPECIFY AND PROCURE
	\begin{nrtc}
	\item	INTEROPERABLE

	\item	MULTI-VENDOR

	\item	OFF-THE-SHELF
	\end{nrtc}
	COMPUTER COMMUNICATIONS PRODUCTS

\item	THE \dod/:
    \begin{nrtc}
    \item	IS ADOPTING GOSIP AS A CO-STANDARD WITH TCP/IP

    \item	INTENDS (IN APPROX.~TWO YEARS) TO SPECIFY GOSIP AS THE 
		\underline{ONLY} STANDARD FOR NON-PROPRIETARY, INTEROPERABLE
		COMPUTER COMMUNICATIONS
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{NORTHROP RESEARCH AND\\ TECHNOLOGY CENTER:\\ JANUARY, 1986}

\begin{nrtc}
\item	THE AUTOMATION SCIENCES LABORATORY WAS INTERESTED IN SOLVING CERTAIN
	PROBLEMS IN THE FACTORY AUTOMATION AREA

\item	AN ``AFTER-HOURS'' PROJECT WAS STARTED TO LOOK INTO THE APPLICABILITY
	OF MIXING OSI AND TCP/IP TECHNOLOGIES
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{(OBLIGATORY SLIDE SHOWING)\\ THE 7--LAYER STACK}

\vskip.5in
\diagram[p]{figure1}
\end{bwslide}


\f

\begin{bwslide}
\part*	{THE UPPER-LAYER ARCHITECTURE}\bf

\begin{nrtc}
\item	THE UPPER LAYERS OF OSI APPEARED TO BE A RICH PLAYGROUND

\item	WE WANTED TO SEE HOW USEFUL THE UPPER LAYERS REALLY WERE
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{THE UPPER-LAYER ARCHITECTURE (cont.)}

\begin{nrtc}
\item	BY ``UPPER-LAYER'' WE MEAN EVERYTHING ABOVE TRANSPORT:
    \begin{nrtc}
    \item	THE APPLICATION-SPECIFICS OF HOW THE NETWORK IS USED
    \end{nrtc}

\item	UNLIKE OTHER ARCHITECTURES, THE SAME UPPER-LAYERS ARE USED
	REGARDLESS OF THE APPLICATION

\item	WHAT DIFFERS IS THE ACTUAL FUNCTIONALITY USED BY THE APPLICATION
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{THE UPPER-LAYER ARCHITECTURE (cont.)}

\vskip.15in
\diagram[p]{figure2}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{THE OSI APPLICATION LAYER}

\begin{nrtc}
\item	MANY STANDARD SERVICE ELEMENTS
    \begin{nrtc}
    \item	ASSOCIATION CONTROL

    \item	REMOTE OPERATIONS

    \item	RELIABLE TRANSFER

    \item	COMMITMENT, CONCURRENCY AND RECOVERY

    \item	DIRECTORY SERVICES
    \end{nrtc}

\item	ABSTRACT SYNTAX NOTATION ONE (ASN.1)
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{APPLICATION USE OF UPPER-LAYER SERVICES}

\vskip.5in
\diagram[p]{figure3}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{APPLICATION SERVICE ELEMENTS}

\begin{nrtc}
\item	A USEFUL MECHANISM FOR DIVIDING RESPONSIBILITY OF THE ``TOTAL''
	APPLICATION PROTOCOL

\item	PROMOTES ``REUSE'' OF APPLICATION LAYER FACILITIES
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{ABSTRACT SYNTAX NOTATION ONE (ASN.1)}

\begin{nrtc}
\item	UNIVERSAL LANGUAGE TO DESCRIBE DATA WITH STRONG TYPING

\item	(TOO) RICH, EXTENSIBLE SYNTAX

\item	USEFUL FOR SPECIFICATION OF NEW PROTOCOLS
    \begin{nrtc}
    \item	``CLEAR-TO-READ'' SPECIFICATIONS (ha!)

    \item	NOT TIED TO MACHINE-ORIENTED STRUCTURES AND RESTRICTIONS
    \end{nrtc}

\item	REPRESENTATION CURRENTLY USED BY ALL OSI APPLICATIONS
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{EXAMPLE:\\ FTAM USE OF LOWER-LAYER SERVICES}

\vskip.5in
\diagram[p]{figure4}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{ONLY ONE LITTLE PROBLEM$\ldots$}

\begin{nrtc}
\item	HOW TO RUN THE OSI UPPER-LAYERS IN A TCP/IP-BASED NETWORK?

\item	A SOLUTION IS OFFERED BY LAYERING
    \begin{nrtc}
    \item	THE OSI TRANSPORT \underline{SERVICE} IS VERY SIMPLE

    \item	CAN WE PROVIDE AN EMULATION OF THAT SERVICE USING TCP?
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{SERVICE EMULATOR AT TRANSPORT}

\vskip.5in
\diagram[p]{figure5}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{THE OSI TRANSPORT SERVICE}

\begin{nrtc}
\item	ALTHOUGH THE SERVICE IS VERY SIMPLE, THERE ARE ACTUALLY FIVE DIFFERENT
	ISO PROTOCOLS WHICH CAN BE USED (TP0$\ldots$TP4)

\item	PROTOCOLS CAN BE DIVIDED INTO TWO CLASSES, BASED ON THE UNDERLYING
	NETWORK SERVICE
    \begin{nrtc}
    \item	A CONNECTION-ORIENTED NETWORK SERVICE (CONS), e.g., X.25

    \item	A CONNECTIONLESS-MODE NETWORK SERVICE (CLNS), e.g., CLNP
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{OSI TRANSPORT SERVICES\\ ON TOP OF THE DoD TCP}

\begin{nrtc}
\item	IDEA: TAKE THE SIMPLEST PROTOCOL (TP0) AND DEFINE A MAPPING ONTO
	THE DoD TCP

\item{}	[RFC983], PUBLISHED IN APRIL OF 1986, WAS OUR FIRST ATTEMPT AT THIS

\item	TWO VERSIONS AND 13 MONTHS LATER, [RFC1006] GOT IT RIGHT, TELLING
	``HOW TO SPEAK TP0 OVER THE TCP''

\item	NOTE: THIS APPROACH IS NOT UNIQUE TO TCP/IP-BASED NETWORKS!
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{OSI TRANSPORT SERVICES\\ ON TOP OF THE DoD TCP (cont.)}

\vskip.25in
\diagram[p]{figure6}
\end{bwslide}


\f

\begin{bwslide}
\part*	{LOWER LAYER INFRASTRUCTURE}\bf

\begin{nrtc}
\item	THE LOWER LAYERS ARE EVERYTHING AT TRANSPORT AND BELOW

\item	THE LOWER LAYERS ARE VERY SIMILAR TO OTHER ARCHITECTURES IN USE
	TODAY, e.g., TCP/IP, XNS

\item	HOWEVER, DUE TO CULTURE CLASH, TWO DIFFERENT SCHEMES FOR END-TO-END
	SERVICE ARE POSSIBLE

\item	ATTEMPTING TO ``HARMONIZE'' THESE APPROACHES LED TO ONE OF THE UGLIEST
	STANDARDS (THE IONL) EVER WRITTEN!
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{LOWER LAYER INFRASTRUCTURE}

\vskip.5in
\diagram[p]{figure18}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{SOME TRANSPORT CONCERNS}

\begin{nrtc}
\item	ONLY RECENTLY HAVE PERFORMANCE ISSUES IN TP4--LIKE PROTOCOLS BECOME
	WELL UNDERSTOOD (e.g., SLOW START IN THE TCP)

\item	THE TP4 SPECIFICATION IS VERY NAIVE IN MANY OF THE ALGORITHMS THAT IT
	USES

\item	THIS CAN LEAD TO SLUGGISH PERFORMANCE ON LANS (ALREADY OBSERVED)
	AND CONGESTION COLLAPSE IN INTERNETS (WIDELY PREDICTED)

\item	SOLUTION: IMPLEMENT TCP-ISH ALGORITHMS IN TP4

\item	OTHER COMPLAINTS: CHECKSUM IS TOO SLOW TO DO IN SOFTWARE, BUT PROTOCOL
	IS TOO COMPLICATED TO DO IN HARDWARE!
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part*	{CONCLUSIONS}\bf

\begin{nrtc}
\item	THE GOSIP IS PROVIDING THE INITIAL DEMAND FOR OSI IN THE U.S.

\item	ENOUGH AREAS HAVE BEEN STANDARDIZED TO DEPLOY EXPERIMENTAL SYSTEMS

\item	STILL NEED LOTS OF OPERATIONAL EXPERIENCE BEFORE HIGH-QUALITY
	PRODUCTS CAN BE BUILT
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part	{STRATEGIES FOR TRANSITION/COEXISTENCE}\bf

\begin{nrtc}
\item	THERE ARE MANY TCP/IP NETWORKS TODAY; THERE WILL BE MORE TOMORROW

\item	BY THE TIME OSI BECOMES A WORTHWHILE OPERATIONAL ALTERNATIVE,
	THERE WILL BE MANY MORE TCP/IP NETWORKS THAN THERE ARE TODAY!

\item	PROBLEM: HOW TO PROTECT INSTALLED BASE?

\item	PROBLEM: HOW TO TRANSITION GRACEFULLY?
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{METRICS FOR COMPARISON}

\begin{nrtc}
\item	CAN JUDGE A TRANSITION/COEXISTENCE SCHEME USING DIFFERENT
	CRITERIA

\item	HERE ARE A FEW
    \begin{nrtc}
    \item	PERFORMANCE:
	\begin{nrtc}
	\item	THROUGHPUT

	\item	RESPONSE
	\end{nrtc}

    \item	FLEXIBILITY:
	\begin{nrtc}
	\item	RANGE OF APPLICABILITY
	\end{nrtc}

    \item	TRANSPARENCY:
	\begin{nrtc}
	\item	USAGE CONTINUITY

	\item	SEAMLESS USER INTERFACE
	\end{nrtc}

    \item	PERVASIVENESS:
	\begin{nrtc}
	\item	MANAGEABILITY
	\end{nrtc}
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{FOUR CANDIDATES}

\begin{nrtc}
\item	PROTOCOL-BASED APPROACHES
    \begin{nrtc}
    \item	DUAL STACK

    \item	APPLICATION GATEWAYS
    \end{nrtc}

\item	SERVICE-BASED APPROACHES
    \begin{nrtc}
    \item	TRANSPORT-SERVICE BRIDGES

    \item	NETWORK TUNNELS
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part*	{DUAL STACK}\bf

\begin{nrtc}
\item	PUT BOTH PROTOCOL SUITES IN ALL HOSTS

\item	NICE WORK, IF YOU CAN GET IT
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{DUAL STACK (cont.)}

\vskip.5in
\diagram[p]{figure16}
\end{bwslide}


\begin{bwslide}
\ctitle	{SCORECARD}

\begin{nrtc}
\item	PERFORMANCE: NO DEGRADATION

\item	FLEXIBILITY: NOT REALLY; HAVE TO ADD EACH APPLICATION TO EACH HOST

\item	TRANSPARENCY:
    \begin{nrtc}
    \item	ASSUMING REMOTE SYSTEM SUPPORTS AT LEAST ONE OF THE PROTOCOL
		STACKS, THEN HIGH TRANSPARENCY BY USING COMMON SERVICE
		INTERFACE
    \end{nrtc}

\item	PERVASIVENESS:
    \begin{nrtc}
    \item	BOTH END- AND INTERMEDIATE-SYSTEMS MUST RUN BOTH PROTOCOLS

    \item	INTRODUCES ADMINISTRATIVE PROBLEMS AS THERE ARE NOW TWO
		LOGICAL NETWORKS
	\begin{nrtc}
	\item	MANAGEMENT OF BOTH \underline{PLUS} CONTENTION BETWEEN THEM
	\end{nrtc}
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part*	{APPLICATION GATEWAYS}\bf

\begin{nrtc}
\item	A WELL-KNOWN, BUT LITTLE-UNDERSTOOD TECHNOLOGY
    \begin{nrtc}
    \item	USED IN MESSAGE HANDLING QUITE A BIT\\
		(AND MOST ARE QUITE TERRIBLE) 

    \item	NOT REALLY USED OTHERWISE    
    \end{nrtc}

\item	THERE ARE TWO TYPES OF A-GWY's:
    \begin{nrtc}
    \item	SAME APPLICATION PROTOCOL,\\
		BUT DIFFERENT UNDERLYING LAYERS

    \item	DIFFERENT APPLICATION PROTOCOLS,\\
		UNDERLYING LAYERS UNIMPORTANT
    \end{nrtc}

\item	WE'LL CONSIDER ONLY THE LATTER TYPE
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{APPLICATION GATEWAYS (cont.)}

\vskip.5in
\diagram[p]{figure7}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{SCORECARD}

\begin{nrtc}
\item	PERFORMANCE: USUALLY POOR, BUT ACCEPTABLE FOR STORE-AND-FORWARD
	APPLICATIONS
    \begin{nrtc}
    \item	TYPICALLY ALSO INTRODUCES ADDITIONAL NETWORK TRAFFIC
    \end{nrtc}

\item	FLEXIBILITY: NONE; EACH A-GWY IS A SPECIAL-PURPOSE SOFTWARE BOX

\item	TRANSPARENCY: 
    \begin{nrtc}
    \item	TO SERVICE: OFTEN LOSES SIGNIFICANT FUNCTIONALITY

    \item	TO USERS: POSSIBLE, BUT NOT LIKELY (e.g., IN AN FTAM/FTP A-GWY,
		USERS EMBED HOSTNAMES IN FILENAMES)
    \end{nrtc}

\item	PERVASIVENESS:
    \begin{nrtc}
    \item	REQUIRES NO END-SYSTEM MODIFICATION

    \item	MAY INTRODUCE ADMINISTRATIVE PROBLEMS
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part*	{A NEW APPROACH}\bf

\begin{nrtc}
\item	PREDICTION: BY THE TIME OSI IS A WORTHWHILE ALTERNATIVE,
	TCP/IP-BASED NETWORKS WILL ALREADY OFFER A MIX OF SERVICES:
    \begin{nrtc}
    \item	SUCH AS FTAM AND MHS, IN ADDITION TO FTP AND SMTP
    \end{nrtc}

\item	OBVIOUSLY, ONE METHOD OF DOING THIS IS TO USE THE [RFC1006] APPROACH
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{OBSERVATION}

\begin{nrtc}
\item	GIVEN THE ABOVE ASSUMPTION, IT SHOULD BE NOTED THAT:
    \begin{nrtc}
    \item	THE TWO COMMUNITIES WILL BE USING THE SAME APPLICATIONS (OSI),
		AND

    \item	ONLY THE UNDERLYING ``TS-STACK'' WILL DIFFER BETWEEN THE TWO:
	\begin{nrtc}
	\item	IN THE OSI COMMUNITY: TP4/CLNP/$\ldots$

	\item	IN THE TCP COMMUNITY: [RFC1006]/TCP/IP/$\ldots$
	\end{nrtc}
    \end{nrtc}

\item	THIS LEADS US TO POSTULATE AN INTERESTING COEXISTENCE
	STRATEGY:
    \begin{nrtc}
    \item	LET'S RUN OSI APPLICATIONS BETWEEN THE TWO COMMUNITIES
    \end{nrtc}

\item	IN A SENSE, THIS IS A HYBRID OF THE TWO PREVIOUS APPROACHES,
	INTENDED TO MINIMIZE THE DISADVANTAGES OF EACH
    \begin{nrtc}
	\item	SAME APPLICATION PROTOCOL,\\
		BUT DIFFERENT UNDERYLING LAYERS
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{TRANSPORT-SERVICE BRIDGES}

\begin{nrtc}
\item	INTRODUCE A TRANSPORT ENTITY CALLED THE ``TS-BRIDGE''

\item	THE TS-BRIDGE ``COPIES'' SERVICE PRIMITIVES FROM ONE COMMUNITY TO THE
	OTHER, e.g.:
    \begin{nrtc}
    \item	UPON RECEIVING A T-CONNECT.INDICATION PRIMITIVE FROM ONE
		TS-STACK,

    \item	IT ISSUES A T-CONNECT.REQUEST PRIMITIVE TO THE OTHER TS-STACK
    \end{nrtc}

\item	POTENTIAL PROBLEMS:
    \begin{nrtc}
    \item	THE TS-BRIDGE MAINTAINS STATE AS TO THE EXISTING CONNECTIONS

    \item	TWO CHECKSUMS, AND NEITHER REALLY END-TO-END
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{TRANSPORT-SERVICE BRIDGES (cont.)}

\vskip.5in
\diagram[p]{figure8}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{TRANSPARENT USE OF TS-BRIDGES}

\begin{nrtc}
\item	BY JUDICIOUS USE OF DIRECTORY SERVICES, SELECTION OF THE
	TS-BRIDGE CAN BE MADE TRANSPARENT ON BOTH ENDPOINTS

\item	CONSIDER A ``TYPICAL'' PRESENTATION ADDRESS:
\[\begin{tabular}{ll}
network address:&	CLNP 470005001700$\ldots$5301\\
transport selector:&	1\\
session selector:&	``FTAM''\\
presentation selector:&	null
\end{tabular}\]

\item	A SLIGHTLY DIFFERENT ENTRY IS RETURNED FOR HOSTS IN THE
	OPPOSITE COMMUNITY:
\[\begin{tabular}{ll}
network address:&	ts-bridge's network address\\
transport selector:&	\begin{tabular}[t]{ll}
			network address:&
				CLNP 47 $\ldots$\\
			transport selector:&	 1
			\end{tabular}\\
session selector:&	``FTAM''\\
presentation selector:&	null
\end{tabular}\]
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{ANOTHER PROBLEM SOLVED:\\ ISO CONS versus CLNS}

\begin{nrtc}
\item	IN GENERAL, THE TS-BRIDGE SHOWS HOW TO PERFORM
	``IMPEDENCE MATCHING'' BETWEEN TWO PROTOCOLS WHICH OFFER THE
	SAME SERVICE INTERFACE, e.g., OUR USE IS:
    \begin{nrtc}
    \item	PROTOCOLS: TP4/CLNP AND TP0/TCP

    \item	SERVICE: OSI TRANSPORT SERVICE
    \end{nrtc}

\item	THIS IS SUSPICIOUSLY SIMILAR TO THE ISO TP4/CLNS vs. TP0/CONS PROBLEM:
    \begin{nrtc}
    \item	PROTOCOLS: TP4/CLNP AND TP0/X.25

    \item	SERVICE: OSI TRANSPORT SERVICE
    \end{nrtc}

\item	THE TS-BRIDGE WILL ALSO WORK IN THIS ENVIRONMENT WITHOUT
	MEANINGFUL LOSS OF GENERALITY:
    \begin{nrtc}
    \item	EXPEDITED DATA IS NEGOTIATED AWAY, AND

    \item	INITIAL USER DATA RESULTS IN DISCONNECT
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{AN IMPLEMENTATION OF THE TS-BRIDGE}

\begin{nrtc}
\item	USING ISODE, WOLLONGONG HAS IMPLEMENTED A TS-BRIDGE

\item	AT UNIFORUM IN FEBRUARY, 1987, THE
    \begin{nrtc}
    \item	TP4/CLNP to TP0/TCP
    \end{nrtc}
    ``IMPEDENCE MATCHING'' WAS DEMONSTRATED

\item	CURRENTLY, ALL THREE TS-STACKS
    \begin{nrtc}
    \item	TP4/CLNP, TP0/X.25, TP0/TCP
    \end{nrtc}
    ARE BEING BRIDGED (ON A SINGLE HOST) AT WOLLONGONG
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{SCORECARD}

\begin{nrtc}
\item	PERFORMANCE: FAIR; WHEN TS-BRIDGE IS MADE INTO A KERNEL-RESIDENT
	STREAMS MODULE IT SHOULD IMPROVE DRAMATICALLY

\item	FLEXIBILITY: HIGH; INDEPENDENT OF ANY APPLICATION

\item	TRANSPARENCY: TOTAL

\item	PERVASIVENESS:
    \begin{nrtc}
    \item	END-SYSTEMS MUST RUN ``NEW'' PROTOCOLS

    \item	MAY INTRODUCE ADMINISTRATIVE PROBLEMS (WHICH SHOULD BE SOLVED
		DYNAMICALLY BY DIRECTORY SERVICES)
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part*	{NETWORK TUNNELS}\bf

\begin{nrtc}
\item	IDEA: ENCAPSULATE CLNP INSIDE OF IP, TREATING IP AS SIMPLY A DATA LINK
	PROTOCOL

\item	NS-TUNNEL PERFORMS AS A ROUTER, REMOVING ONE DATA LINK HEADER AND
	ADDING ANOTHER

\item	REQUIRES COMMON HIGHER-LEVEL PROTOCOLS (TRANSPORT AND ABOVE) ON BOTH
	END-SYSTEMS, BUT DOES NOT REQUIRE ALL INTERVENTING ROUTERS TO USE THE
	SAME NETWORK PROTOCOL
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{NETWORK TUNNELS (cont.)}

\vskip.5in
\diagram[p]{figure17}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{INTERESTING FEATURES}

\begin{nrtc}
\item	NO STATE MAINTAINED BY NS-TUNNEL

\item	A TRUE END-TO-END CHECKSUM

\item	THE TCP END-SYSTEM IMPLEMENTATION CHOICES ARE SIMILAR TO NETBIOS OVER
	TCP [RFC1001/1002]
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{SCORECARD}

\begin{nrtc}
\item	PERFORMANCE: NO WORSE THAN TYPICAL CLNP-ROUTER (AND PROBABLY A LOT
	BETTER TOO!)

\item	FLEXIBILITY: HIGH (INDEPENDENT OF ANY APPLICATION)

\item	TRANSPARENCY: TOTAL

\item	PERVASIVENESS: SOME END-SYSTEMS MUST RUN BOTH TRANSPORT PROTOCOLS
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part*	{CONCLUSIONS}\bf

\begin{nrtc}
\item	TCP/IP-BASED NETWORKS WILL OFFER OSI-STYLE SERVICES

\item	COEXISTENCE IN THE SHORT TERM:
    \begin{nrtc}
    \item	TS-BRIDGE MINIMIZES SOFTWARE INVESTMENT
    \end{nrtc}

\item	COEXISTENCE IN THE LONG TERM:
    \begin{nrtc}
    \item	NS-TUNNEL MAXIMIZES PERFORMANCE
    \end{nrtc}

\item	IF/WHEN THERE ARE NO MORE TCP/IP-BASED NETWORKS, THEN THE
	COEXISTANCE PERIOD IS OVER, AND TRANSITION IS A NON-ISSUE!
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part	{THE ISO DEVELOPMENT ENVIRONMENT}\bf

\begin{nrtc}
\item	CURRENT DISTRIBUTION

\item	WHERE IN USE

\item	THE APPLICATIONS COOKBOOK

\item	THE OSI-POSIX PROJECT
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{WHAT IS ISODE?}

\begin{nrtc}
\item	THE ISO DEVELOPMENT ENVIRONMENT

\item	AN OPENLY AVAILABLE IMPLEMENATION OF THE UPPER LAYERS OF OSI?

\item	A BASIS FOR THE TRANSITION TO OSI?

\item	AN EXERCISE IN MEGA-CODING?

\item	A PLAYGROUND FOR ``THE PIED-PIPER OF OSI''?
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part*	{CURRENT DISTRIBUTION}\bf

\begin{nrtc}
\item	STATUS: OPENLY AVAILABLE UNDER AN IMPLICIT ``HOLD HARMLESS'' CLAUSE

\item	CURRENT RELEASE: 3.0
    \begin{nrtc}
    \item	AVAILABLE OCTOBER 15, 1987
    \end{nrtc}

\item	CURRENT DISTRIBUTION: 3.6(BETA)
    \begin{nrtc}
    \item	AVAILABLE APRIL 15, 1988
    \end{nrtc}

\item	DISTRIBUTION EITHER VIA POSTAL MAIL OR ARPAnet FTP
    \begin{nrtc}
    \item	SOURCE: \~{}6MB

    \item	DOC: 4~VOLUME USER'S MANUAL (\~{}600~PAGES)

    \item	DISTRIBUTION SITES: US, UK, AND AU

    \item	PRICE: \~{}200~US DOLLARS
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{LANGUAGES AND OPERATING SYSTEMS}

\begin{nrtc}
\item	CODED ENTIRELY IN C FOR \unix/
    \begin{nrtc}
    \item	REQUIRES NO KERNEL MODIFICATIONS    
    \end{nrtc}

\item	KNOWN PORTS FOR BERKELEY \unix/ (4.2 and 4.3):
    \begin{nrtc}
    \item	VAXen, SUNs, Pyramids, RTs, etc.
    \end{nrtc}

\item	KNOWN PORTS FOR AT\&T \unix/ (SVR2 and SVR3):
    \begin{nrtc}
    \item	SGI, 3Bs, 386s, RT (AIX)
    \end{nrtc}

\item	MS-DOS (CURRENTLY CLIENT SIDE ONLY)
    \begin{nrtc}
    \item	PORT DONE BY HP IN THE UK

    \item	DON'T KNOW STATUS OF CODE
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{APPLICATION ARCHITECTURE}

\begin{nrtc}
\item	A (NEARLY) COMPLETE IMPLEMENTATION OF THE UPPER LAYERS

\item	CURRENTLY DIS LEVEL
    \begin{nrtc}
    \item	IN PROCESS OF BEING UPGRADED TO IS
    \end{nrtc}

\item	ALIGNED WITH THE U.S.~GOSIP
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{THE APPLICATION ENVIRONMENT}

\vskip.5in
\diagram[p]{figure9}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{AN ALTERNATE ENVIRONMENT:\\ MHS ARCHITECTURE (c.~1984)}

\vskip.5in
\diagram[p]{figure10}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{APPLICATIONS}

\begin{nrtc}
\item	FILE TRANSFER, ACCESS AND MANAGEMENT (FTAM)

\item	ISODE MISCELLANY SERVICE
    \begin{nrtc}
    \item	e.g., FINGER, QUOTE-OF-THE-DAY, etc.
    \end{nrtc}

\item	PLUS NUMEROUS ``DEMO'' PROGRAMS
    \begin{nrtc}
    \item	e.g., IMAGE SERVICE, PASSWORD LOOKUP, etc.
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{THE TRANSPORT SWITCH}

\begin{nrtc}
\item	DECIDES WHICH TS-STACK TO USE FOR A CONNECTION

\item	FOR TP0:
    \begin{nrtc}
    \item	TCP (SOCKETS)

    \item	X.25 (SEVERAL INTERFACES, MOSTLY SOCKETS)
    \end{nrtc}

\item	FOR TP4:
    \begin{nrtc}
    \item	TWG's PROPRIETARY WIN/ISO (TLI)

    \item	SunLink OSI (EVENT SOCKETS)
    \end{nrtc}

\item	EXPERIENCE SHOWS IT IS FAIRLY EASY TO ADD A NEW TS-STACK TO THE SWITCH
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part*	{WHERE IN USE}\bf

\begin{nrtc}
\item	HARD TO TELL HOW MANY COPIES ARE IN USE (DUE TO AVAILABILITY VIA
	ARPAnet FTP)

\item	AT LAST COUNT, ABOUT 350~DIFFERENT SITES USING ISODE

\item	IN ADDITION TO SITES IN NORTH AMERICA:
    \begin{nrtc}
    \item	WESTERN EUROPE

    \item	MIDDLE EAST (ISRAEL)

    \item	SOUTH PACIFIC (AUSTRALIA)

    \item	ASIA (SOUTH KOREA, JAPAN)
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{PROJECTS}

\begin{nrtc}
\item	THREE PILOT PROJECTS IN OSI INFRASTRUCTURE IN EUROPE
    \begin{nrtc}
    \item	A NATIONAL PROJECT IN THE UK

    \item	A NATIONAL PROJECT IN WEST GERMANY (DFN)

    \item	A PROJECT FOR RARE (THE EUROPEAN ACADEMIC COMMUNITY)
    \end{nrtc}

\item	IN USE BY DIFFERENT CONFORMANCE TESTING ORGANIZATIONS
    \begin{nrtc}
    \item	THE CORPORATION FOR OPEN SYSTEMS IN THE US

    \item	THE NATIONAL COMPUTER CENTRE IN THE UK
    \end{nrtc}

\item	ENDORSED BY THE NSF (DNCRI)
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part*	{THE APPLICATIONS COOKBOOK}\bf

\begin{nrtc}
\item	TOOLS TO FACILITATE DEVELOPMENT OF APPLICATIONS ARE CRITICAL

\item	IDEA IS TO DEVELOP TOOLS TO AUTOMATE USE OF OSI REMOTE OPERATIONS
	SERVICE AS A GENERAL REMOTE PROCEDURE CALL FACILITY

\item	ECMA TR/31: REMOTE OPERATIONS -- CONCEPTS, NOTATION AND
	CONNECTION-ORIENTED MAPPINGS (SECTIONS 1--4)
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{REMOTE OPERATIONS SERVICE (ROS)}

\begin{nrtc}
\item	STANDARDIZED MECHANISM FOR SPECIFYING TRANSACTIONS

\item	EMPLOYS POWER OF ASN.1

\item	USED IN MANY INTERESTING OSI APPLICATIONS
    \begin{nrtc}
    \item	MESSAGE HANDLING SYSTEMS

    \item	DIRECTORY SERVICES

    \item	NETWORK MANAGEMENT

    \item	REMOTE DATABASE ACCESS
    \end{nrtc}

\item	CURRENTLY CONNECTION-ORIENTED, BUT CONNECTIONLESS-MODE IS UNDER STUDY
\end{nrtc}
\end{bwslide}

\f

\begin{bwslide}
\ctitle	{GENERAL ORGANIZATION}

\begin{nrtc}
\item	AT COMPILE-TIME:
    \begin{nrtc}
    \item	USE RO-SPECIFICATION TO GENERATE SUPPORT FACILITIES
    \end{nrtc}

\item	AT RUN-TIME:
    \begin{nrtc}
    \item	USE DIRECTORY SERVICES TO LOCATE/REGISTER NETWORK SERVICES

    \item	USE ASSOCIATION CONTROL TO BIND/UNBIND APPLICATIONS

    \item	USE REMOTE OPERATIONS TO INVOKE TRANSACTIONS
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{STATIC (COMPILE-TIME) ORGANIZATION}

\vskip.15in
\diagram[p]{figure11}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{DYNAMIC (RUN-TIME) ORGANIZATION}

\vskip.15in
\diagram[p]{figure12}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{CURRENT STATUS}

\begin{nrtc}
\item	STATIC AND DYNAMIC FACILITIES
    \begin{nrtc}
    \item	ALL TOOLS/LIBRARIES ARE DEVELOPED AND MOST RECENT UPGRADES
		HAVE NEARLY COMPLETED BETA TESTING

    \item	``REAL'' (DYNAMIC) DIRECTORY SERVICES IS CURRENTLY TOO
		IMMATURE (BUT NOT FOR LONG!)
    \end{nrtc}

\item	AN ``APPLICATIONS COOKBOOK'' WAS WRITTEN AS VOLUME~4 OF THE USER'S
	MANUAL
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part*	{OSI-POSIX PROJECT}\bf

\begin{nrtc}
\item	IF WE BELIEVE THAT:
    \begin{nrtc}
    \item	OSI/ISO WILL EVENTUALLY DOMINATE COMPUTER COMMUNICATIONS, AND

    \item	THE U.S.~GOVERNMENT OSI PROFILE WILL BE THE INITIAL SET OF
		GUIDELINES FOR OSI PROCUREMENT
    \end{nrtc}

\item	WHAT CAN WE DO TO ACCELERATE THE PROCESS?

\item	NOTE: AFTER THE ENTERPRISE EVENT, MAP/TOP MAY DROP FROM 
	MAINSTREAM OSI
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{GOSIP (REFRESHER)}

\begin{nrtc}
\item	A (SOON-TO-BE) FEDERAL INFORMATION PROCESSING STANDARD

\item	PROPOSED TO ENABLE USERS TO SPECIFY AND PROCURE
	\begin{nrtc}
	\item	INTEROPERABLE

	\item	MULTI-VENDOR

	\item	OFF-THE-SHELF
	\end{nrtc}
	COMPUTER COMMUNICATIONS PRODUCTS

\item	THE \dod/:
    \begin{nrtc}
    \item	IS ADOPTING GOSIP AS A CO-STANDARD WITH TCP/IP

    \item	INTENDS (IN APPROX.~TWO YEARS) TO SPECIFY GOSIP AS THE 
		\underline{ONLY} STANDARD FOR NON-PROPRIETARY, INTEROPERABLE
		COMPUTER COMMUNICATIONS
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{A DIGRESSION:\\ OPERATING SYSTEMS}

\begin{nrtc}
\item	LET US SUPPOSE THAT THE \unix/ FAMILY WILL DOMINATE OPERATING SYSTEMS

\item	THE EMERGING IEEE \unix/-BASED PORTABLE OPERATING SYSTEM
	STANDARD (POSIX) WILL PROBABLY BE THE BASELINE FOR THESE SYSTEMS

\item	A FIPS IS UNDER DEVELOPMENT TO BE THE INITIAL SET OF GUIDELINES FOR
	PROCUREMENT OF OPERATING SYSTEMS FOR USERS
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{POSIX}

\begin{nrtc}
\item	CURRENTLY POSIX SPECIFIES ONLY THE \unix/ KERNEL INTERFACE
    \begin{nrtc}
    \item	INFLUENCED MOSTLY BY AT\&T \unix/ (SVID) WITH SOME BERKELEY
		ENHANCEMENTS
    \end{nrtc}

\item	WORK IS UNDERWAY ON A SHELL AND TOOLS STANDARD

\item	A STANDARD INTERFACE FOR NETWORKING IS NOTABLY MISSING
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{A MODEST OBSERVATION}

\begin{nrtc}
\item	TCP/IP BECAME WIDESPREAD AFTER IT WAS INCLUDED IN BERKELEY \unix/

\item	QUESTIONS:
    \begin{nrtc}
    \item	CAN WE PUT A REFERENCE VERSION OF THE OSI PROTOCOLS INTO
		BERKELEY \unix/?

    \item	CAN WE MAKE BERKELEY \unix/ POSIX COMPLIANT?

    \item	CAN WE EXTEND POSIX TO DEFINE AN INTERFACE TO NETWORK SERVICES?

    \item	CAN WE MAKE THE WORK OPENLY AVAILABLE AND HAVE IT READY FOR
		4.4\bsd/~\unix/?
    \end{nrtc}

\item	ANSWER: YES

\item	THIS SHOULD RESULT IN ACCELERATING THE UBIQUITY OF OSI
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{EXPLANATION}

\begin{nrtc}
\item	A LARGE NUMBER OF THE PIECES ARE ALREADY OPENLY AVAILABLE

\item	SO, THE WORK CONSISTS MAINLY OF:
    \begin{nrtc}
    \item	FILLING IN THE GAPS

    \item	INTEGRATING THE COMPONENTS

    \item	TESTING THE SYSTEM\\ (INTEROPERABILITY AND CONFORMANCE)
    \end{nrtc}

\item	THIS MODEST AMOUNT OF WORK SHOULD RESULT IN ACCELERATING THE UBIQUITY
	OF OSI
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{APPROACH:\\ OSI PROTOCOLS}

\begin{nrtc}
\item	AN IMPLEMENTATION OF THE OSI UPPER-LAYERS (ISODE) IS ALREADY AVAILABLE

\item	OTHER ORGANIZATIONS HAVE DEVELOPED OR PLAN TO DEVELOP:
    \begin{nrtc}
    \item	THE LOWER LAYERS

    \item	SOME OSI APPLICATIONS
    \end{nrtc}

\item	MOST STANDARDS HAVE PROGRESSED FROM DRAFT (DIS) TO FINAL (IS) STATUS
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\diagram[p]{figure13}
\end{bwslide}


\f

\begin{bwslide}
\diagram[p]{figure14}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{THE WORK PLAN}

\begin{nrtc}
\item	UPGRADE ISODE AND OTHER OSI APPLICATIONS TO FINAL (IS) STATUS

\item	INTEGRATE OTHER OSI APPLICATIONS INTO ISODE

\item	PERFORM INTEROPERABILITY TESTING ON OSInet

\item	PERFORM CONFORMANCE TESTING WITH COS
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{APPROACH:\\ POSIX COMPLIANCE}

\begin{nrtc}
\item	MINOR WORK TO MODIFY THE BERKELEY \unix/ KERNEL TO SUPPORT THE POSIX
	STANDARD

\item	PERFORM CONFORMANCE TESTING WITH NBS

\item	ISODE AND OSI APPLICATIONS WILL BE CONVERTED TO USE THE POSIX
	INTERFACE AS APPLICABLE
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{APPROACH:\\ POSIX NETWORK SERVICE}

\begin{nrtc}
\item	A /usr/group COMMITTEE WAS FORMED OVER A YEAR AGO

\item	U.C.~BERKELEY (AND FRIENDS) WILL EXAMINE THE OUTPUT OF THIS
	GROUP AND EITHER:
    \begin{nrtc}
    \item	ADOPT THIS INTERFACE (IF ACCEPTED BY THE POSIX COMMITTEE), OR

    \item	SUBMIT A NEW DRAFT PROPOSAL TO THE POSIX COMMITTEE
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{SCHEDULE}

\begin{nrtc}
\item	WOULD YOU BELIEVE 18~CALENDAR-MONTHS?

\item	ACTUALLY 120~MAN-MONTHS%
	\footnote{You may have read Brooks' {\em The Mythical Man-Month}.}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part*	{SUMMARY}\bf

\begin{nrtc}
\item	ISODE PROVIDES A RICH ENVIRONMENT FOR BUILDING OSI APPLICATIONS
	(AND STUDYING THE UPPER LAYERS OF OSI)

\item	ISODE IS THE FOUNDATION OF A PROJECT TO MAKE OSI UBIQUITOUS WHICH
    \begin{nrtc}
    \item	USES 4.4\bsd/~\unix/ AS A PLATFORM, AND

    \item	OFFERS A COMPLETE REFERENCE IMPLEMENTATION IN THE PUBLIC DOMAIN
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\end{document}
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦ad2cc231b⟧ TextFile

Derivation

TextFile
