⟦1bcf4b1db⟧

TextFile

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

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

\def\emph#1{\underline{#1}}

\font\xx=cmbx10
\font\yy=cmbx7
\font\sf=cmss10

\raggedright

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

\begin{document}

\title	{THE OSI CHALLENGE:\\ TRANSITION ASPECTS AND TACTICS}
\author	{Marshall T.~Rose\\ NYSERNet, Inc.}
\date	{October 25, 1989}
\maketitlepage


\f

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

\begin{description}
\item[PART I:]		MOTIVATION

\item[PART II:]		BACKGROUND

\item[PART III:]	PROTOCOL-BASED APPROACHES

\item[PART IV:]		SERVICE-BASED APPROACHES

\item[PART V:]		EXAMPLES
\end{description}
\end{bwslide}


\f

\begin{bwslide}
\part	{MOTIVATION}\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	{GROWTH OF TCP/IP}

\begin{nrtc}
\item	SALES OF TCP/IP-BASED TECHNOLOGY
    \begin{nrtc}
    \item	PARTICULARLY IN EUROPE
    \end{nrtc}
	CONTINUES TO GROW

\item	SEVERAL TECHNICAL AND MARKET ASPECTS CONTRIBUTE TO THIS PHENOMENA:
    \begin{nrtc}
    \item	SUPERIORITY OF TCP/IP IN LOWER-LAYER CONNECTIVITY

    \item	MATURITY OF TCP/IP PRODUCTS\\ (e.g., RANGE OF PLATFORMS)
    \end{nrtc}

\item	ALTHOUGH OSI WILL DOMINATE, IT DOESN'T YET

\item	HENCE, TCP/IP IS BECOMING MORE FIRMLY ENTRENCHED
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{FEAR AND LOATHING IN THE MARKET}

\begin{nrtc}
\item	F.U.D. IN THE MARKETPLACE:
\begin{quote}\em
``All marketing is fear, uncertainty, and doubt.''\\ \raggedleft
-- Einar Stefferud, Network Management Associates
\end{quote}

\item	WHAT THE VENDORS SAY:
\begin{quote}\em
``$\ldots$ protect your investment while assuring a path to an OSI
future.''\\ \raggedleft
-- Vendor A
\end{quote}
AND
\begin{quote}\em
``$\ldots$ plans for a smooth, painless guaranteed migration to OSI standards
as they are approved.''\\ \raggedleft
--Vendor B
\end{quote}
AND
\begin{quote}\em
``Once you've scrapped your existing production networks,
come to us for OSI.
It will be wonderful!''\\ \raggedleft
--Vendor C
\end{quote}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{THE SAD TRUTH}

\begin{quote}\em
``You can't win, and you can't quit, but you \underline{can} reduce the
pain.''\\ \raggedleft
-- Marshall Rose, NYSERNet, Inc.
\end{quote}
\end{bwslide}


\f

\begin{bwslide}
\part	{BACKGROUND}\bf

\begin{nrtc}
\item	CONCEPTS

\item	TERMINOLOGY

\item	HISTORY

\item	METRICS FOR COMPARISON
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{THE FUNDAMENTAL ASSUMPTION}

\begin{nrtc}
\item	TCP/IP IS HERE TODAY, WIDELY INSTALLED, AND USEFUL

\item	OSI WILL EVENTUALLY REPLACE TCP/IP AS THE OFF-THE-SHELF TECHNOLOGY FOR
	BUILDING INTEROPERABLE SYSTMS

\item	BOTH WILL BE SIMULTANEOUSLY WIDESPREAD FOR QUITE SOME TIME
    \begin{nrtc}
    \item	DURING WHICH OSI WILL GAIN DOMINANCE
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

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

\begin{nrtc}
\item	TRANSITION:
    \begin{nrtc}
    \item	TO MOVE FROM ONE PROTOCOL SUITE TO ANOTHER
    \end{nrtc}

\item	COEXISTENCE:
    \begin{nrtc}
    \item	TO LIVE TOGETHER WITHOUT HOSTILITY OR CONFLICT DESPITE
		DIFFERENCES
    \end{nrtc}

\item	MIGRATION:
    \begin{nrtc}
    \item	TO MOVE BACK AND FORTH, AS THE SEASONS CHANGE
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{MAPPINGS}

\begin{nrtc}
\item	TRANSITION AND COEXISTENCE CAN BE DESCRIBED BY THE MAPPINGS THEY
	REQUIRE

\item	SOME MAPPINGS ARE SIMPLE
    \begin{nrtc}
    \item	i.e., SYNTACTIC CHANGES
    \end{nrtc}

\item	SOME MAPPINGS ARE COMPLEX
    \begin{nrtc}
    \item	i.e., SEMANTIC CHANGES
    \end{nrtc}

\item	THE MORE COMPLEX THE MAPPING, THE GREATER THE LOSS OF INFORMATION OR
	INTENT
\end{nrtc}
\end{bwslide}


\f

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

\begin{nrtc}
\item	WE'LL FAVOR OSI TERMINOLOGY, BUT STILL NEED SOME INTERNET (TCP/IP)
	TERMINOLOGY

\item	TWO BASIC TERMS
    \begin{nrtc}
    \item	GATEWAY: GENERIC TO ANY LEVEL, COMPLEX

    \item	BRIDGE: GENERIC TO ANY LEVEL, SIMPLE
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{SERVICE SEMANTICS}

\begin{nrtc}
\item	STORE-AND-FORWARD
    \begin{nrtc}
    \item	SERVICE SEMANTICS CARRIED MULTI-HOP VIA FORWARDERS
    \end{nrtc}

\item	END-TO-END
    \begin{nrtc}
    \item	SERVICE SEMANTICS CARRIED FROM ORIGINATOR TO RECIPIENT

    \item	MAY BE SUPPORTED BY AN UNDERYLING STORE-AND-FORWARD SERVICE
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{SERVICE SEMANTICS (cont.)}

\vskip.5in
\diagram[p]{figureT-3}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{PROTOCOL SUITE}

\begin{nrtc}
\item	A COLLECTION OF SERVICES AND PROTOCOLS RELATED:
    \begin{nrtc}
    \item	ADMINISTRATIVELY, BY AN ORGANIZATION\\ (e.g., ISO/IEC); and,

    \item	PHILOSOPHICALLY, BY A REFERENCE MODEL\\ (e.g., the OSIRM)
    \end{nrtc}

\item	FOR OUR PURPOSES, THERE ARE ONLY TWO:
    \begin{nrtc}
    \item	THE OSI SUITE OF PROTOCOLS

    \item	THE INTERNET SUITE OF PROTOCOLS
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{APPLICATIONS}

\begin{nrtc}
\item	APPLICATION CLASS
    \begin{nrtc}
    \item	A SET OF APPLICATIONS RELATED TO A PARTICULAR ACTIVITY,
		e.g., FILE TRANSFER, IRREGARDLESS OF PROTOCOL SUITE
    \end{nrtc}

\item	APPLICATION INSTANCE
    \begin{nrtc}
    \item	A MEMBER OF AN APPLICATION CLASS SPECIFIC TO A PARTICULAR
		PROTOCOL SUITE, e.g., FTAM
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

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

\begin{nrtc}
\item	A VERY BRIEF INTRODUCTION TO THE TWO PROTOCOL SUITES

\item	WE'LL ATTEMPT TO TAKE A NON-PARTISAN VIEW (ha!)
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{INTERNET SUITE}

\begin{nrtc}
\item	SPONSORED BY THE U.S.~DoD
    \begin{nrtc}
    \item	GREW OUT OF EARLY (D)ARPA RESEARCH INTO SURVIVABLE NETWORKS
    \end{nrtc}
    BASIS FROM THE U.S.~DoD INTERNET ARCHITECTURE MODEL

\item	SPECIFIED IN ``REQUEST FOR COMMENTS'' SERIES (RFCs) AND
	U.S.~MILITARY STANDARDS (MILSTDs)

\item	CURRENT GENERATION PRIMARILY BASED ON
    \begin{nrtc}
    \item	CONNECTION-ORIENTED TRANSPORT SERVICE,
		PROVIDED BY THE TCP; AND,

    \item	CONNECTIONLESS-MODE NETWORK SERVICE,
		PROVIDED BY THE IP
    \end{nrtc}

\item	MAJOR EMPHASIS ON CONNECTIVITY OF DIVERSE SUB-NETWORKS
    \begin{nrtc}
    \item	EXCELLENT RESEARCH CONTINUES, TO THIS DAY, ON THESE ISSUES
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{INTERNET SUITE (cont.)}

\begin{nrtc}
\item	SEVERAL PRODUCTION APPLICATIONS
    \begin{nrtc}
    \item	SIMPLE MAIL TRANSFER PROTOCOL (SMTP)

    \item	FILE TRANSFER PROTOCOL (FTP)

    \item	TELNET (VIRTUAL TERMINAL PROTOCOL)

    \item	DOMAIN NAME SYSTEM (DNS)
    \end{nrtc}
    ALL OF WHICH ARE RATHER SIMPLE

\item	APPLICATIONS CONTAIN THEIR OWN IMPLICIT SESSION AND PRESENTATION
	MECHANISMS

\item	NOT SURPRISING, CONSIDERING THAT THESE APPLICATIONS ARE ALL BASED ON
	15~YEAR OLD MODELS!
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{INTERNET PROTOCOLS}

\vskip.5in
\diagram[p]{figureT-4}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{OSI SUITE}

\begin{nrtc}
\item	SPONSORED BY THE INTERNATIONAL COMMUNITY
    \begin{nrtc}
    \item	IN PARTICULAR THE ISO
    \end{nrtc}
    BASIS FROM THE OSI REFERENCE MODEL (OSIRM)

\item	SPECIFIED IN ``STANDARDS'' (ISO/IEC)  AND RECOMMENDATIONS (CCITT)

\item	BASED ON
    \begin{nrtc}
    \item	CONNECTION-ORIENTED TRANSPORT SERVICE,
		PROVIDED BY ONE OF FIVE DIFFERENT TPs; DEPENDING ON

    \item	THE NETWORK SERVICE AVAILABLE (CONS or CLNS)
    \end{nrtc}

\item	DIFFICULT TO IDENTIFY THE ``MAJOR'' EMPHASIS
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{OSI SUITE (cont.)}

\begin{nrtc}
\item	SEVERAL INTERESTING APPLICATIONS
    \begin{nrtc}
    \item	MESSAGE HANDLING SYSTEMS (MHS)

    \item	FILE TRANSFER, ACCESS AND MANAGEMENT (FTAM)

    \item	VIRTUAL TERMINAL (VT)

    \item	DIRECTORY SERVICES (DS)
    \end{nrtc}

\item	APPLICATIONS EVOLVING QUITE HEAVILY OVER THE LAST FEW YEARS

\item	MUCH MORE AMBITIOUS THAN THEIR INTERNET COUNTERPARTS
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
%%%\ctitle	{OSI PROTOCOLS}

%%%\vskip.25in
\diagram[p]{figureT-5}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{A BRIEF COMPARISON}

\begin{nrtc}
\item	NOTE THAT CONCERNS DIFFER
    \begin{nrtc}
    \item	NETWORK USERS: APPLICATION-LEVEL FUNCTIONALITY

    \item	NETWORK ADMINISTRATORS: NETWORK AND TRANSPORT ISSUES
    \end{nrtc}

\item	FOR APPLICATIONS, ONCE IMPLEMENTED, THE OSI SUITE IS SUPERIOR

\item	FOR NETWORK/TRANSPORT ISSUES, AT PRESENT,
	THE INTERNET SUITE IS SUPERIOR
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part*	{METRICS FOR COMPARISON}\bf

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

\item	THE FOUR WE'LL FOCUS ON ARE ALL SUBJECTIVE;
    \begin{nrtc}
    \item	TECHNICAL SOLUTIONS DO NOT EXIST IN A VACUUM

    \item	THEY MUST BE EVALUATED IN THE CONTEXT OF A TARGET ENVIRONMENT
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{METRICS FOR COMPARISON (cont.)}

\begin{nrtc}
\item	PERFORMANCE:
    \begin{nrtc}
    \item	THROUGHPUT, LATENCY

    \item	EFFECT ON OTHER APPLICATIONS
    \end{nrtc}

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


\f

\begin{bwslide}
\ctitle	{METRICS FOR COMPARISON (cont.)}

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

    \item	SEAMLESS USER INTERFACE
    \end{nrtc}

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


\f

\begin{bwslide}
\ctitle	{SEVERAL CANDIDATES}

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

    \item	APPLICATION GATEWAYS

    \item	TRANSPORT GATEWAYS
    \end{nrtc}

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

    \item	NETWORK TUNNELS
    \end{nrtc}

\item	NONE OF THESE TECHNIQUES ARE SPECIFIC TO THE PROBLEM OF
    \begin{nrtc}
    \item	INTERNET $\mapsto$ OSI
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part	{PROTOCOL-BASED APPROACHES}\bf

\begin{nrtc}
\item	THE ``STANDARD'' METHODS USED TO INTERCONNECT DIFFERENT
	PROTOCOL STACKS

\item	THESE EMPHASIZE THE PROTOCOLS IN EACH STACK

\item	HENCE THEY REINFORCE THE BOUNDARIES BETWEEN TCP/IP AND OSI
\end{nrtc}
\end{bwslide}


\f

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

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

\item	WORKS WELL, IF YOU CAN CHANGE EVERYTHING ON THE NETWORK
\begin{quote}\em
``Nice work, if you can get it.''\\ \raggedleft
-- Groucho Marx, Monkey Business, Paramount Pictures (1931)
\end{quote}
\end{nrtc}
\end{bwslide}


\f

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

\vskip.5in
\diagram[p]{figureT-1}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{TALKING TO UNI-STACK HOSTS}

\begin{nrtc}
\item	QUESTION: HOW TO DECIDE WHICH APPLICATION INSTANCE,
    \begin{nrtc}
    \item	APPL-$\alpha$ OR APPL-$\gamma$,
    \end{nrtc}
	TO USE?

\item	TWO ANSWERS:
    \begin{nrtc}
    \item	DEPEND ON THE USER TO KNOW AND INVOKE THE RIGHT PROGRAM

    \item	DEVELOP A GENERIC APPLICATION WHICH SUPPORTS BOTH CLASSES
    \end{nrtc}

\item	IN THE LATTER CASE, NEED AN UP-TO-DATE DIRECTORY TO DO THIS RELIABLY
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{GENERIC APPLICATION INSTANCE}

\vskip.5in
\diagram[p]{figureT-6}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{AN IMPLEMENTATION OF DUAL-STACK}

\begin{nrtc}
\item	ENVIRONMENT: \unix/~SVR3 (STREAMS)

\item	ACCESS TO LOWER-LAYER PROTOCOLS VIA TRANSPORT LAYER INTERFACE (TLI)

\item	NOTE THAT ALTHOUGH TLI PROVIDES A UNIFORM INTERFACE,
	IT DOES NOT PROVIDE A UNIFORM SERVICE:
    \begin{nrtc}
    \item	PACKET- vs. STREAM-ORIENTATION

    \item	GRACEFUL RELEASE

    \item	EXPEDITED vs. URGENT DATA

    \item	ADDRESSING
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{GENERIC APPLICATION INSTANCE}

\vskip.5in
\diagram[p]{figureT-11}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{SCORECARD}

\begin{nrtc}
\item	PERFORMANCE: NO DEGRADATION

\item	FLEXIBILITY: GOOD

\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	AMENABILITY:
    \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
    \end{nrtc}

\item	MOST ARE QUITE TERRIBLE
\begin{quote}\em
``Sometimes when you try to turn an apple into an orange you get back a
lemon.''\\ \raggedleft
-- Michael Padlipsky, The Elements of Networking Style (1985)
\end{quote}
\end{nrtc}
\end{bwslide}


\f

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

\vskip.5in
\diagram[p]{figureT-2}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{IMPERFECT MAPPINGS}

\begin{nrtc}
\item	BECAUSE THEY ARE AT THE HIGHEST LAYER IN THE STACK,
	APPLICATION GATEWAYS TEND TO PERFORM SEMANTIC MAPPINGS

\item	THESE ARE ACCOMPANIED BY A LOSS OF INFORMATION

\item	SOMETIMES THE LOSS IS ONLY ANNOYING
    \begin{nrtc}
    \item	e.g., ``FUNNY LOOKING'' MAIL ADDRESSES
    \end{nrtc}

\item	SOMETIMES THE LOSS IS CATASTROPHIC
    \begin{nrtc}
    \item	e.g., ROUTING LOOPS
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{AN IMPLEMENATION OF APPLICATION-GATEWAY}

\begin{nrtc}
\item	TWO KINDS OF IMPLEMENATIONS

\item	STAGING (TRUE STORE-AND-FORWARD):
    \begin{nrtc}
    \item	TOP-LEVEL PROTOCOL TRANSACTIONS ARE GROUPED AT THE GATEWAY

    \item	REQUIRES LOCAL STORAGE, BUT MAY PERMIT BETTER MAPPINGS
    \end{nrtc}

\item	IN-SITU (VIRTUAL END-TO-END):
    \begin{nrtc}
    \item	NO PROTOCOL TRANSACTIONS ARE GROUPED

    \item	MAPPINGS ARE ``ON THE FLY''\\ (AND PERHAPS LESS PRECISE)

    \item	END-TO-END RESPONSE IS FASTER
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{INVOKING THE GATEWAY}

\vskip1.5in
\begin{verbatim}
% ftp file-gateway
Name (file-gateway:asterix): obelix@osi-host
Password:
\end{verbatim}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{A STAGING IMPLEMENTATION}

\vskip.5in
\diagram[p]{figureT-12}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{AN IN-SITU IMPLEMENTATION}

\vskip.5in
\diagram[p]{figureT-13}
\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	AMENABILITY:
    \begin{nrtc}
    \item	REQUIRES NO END-SYSTEM MODIFICATION

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


\f

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

\begin{nrtc}
\item	IDEA: GATEWAY AT THE TRANSPORT LAYER SO AS TO AVOID NEEDING
	MULTIPLE APPLICATION GATEWAYS
\begin{quote}\em
``We could do it, but it would be wrong.''\\ \raggedleft
-- Richard Nixon, The Watergate Tapes (1974)
\end{quote}

\item	ALTHOUGH THE OSI (TP4) AND INTERNET (TCP) TRANSPORT PROTOCOLS DIFFER,
	THE SERVICE IS QUITE SIMILAR

\item	HENCE, IT IS TECHNICALLY FEASIBLE TO PERFORM THE MAPPINGS
    \begin{nrtc}
    \item	(ALTHOUGH IT'S A LOT OF HARD WORK)
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

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

\vskip.5in
\diagram[p]{figureT-14}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{THE OBVIOUS QUESTION}

\begin{nrtc}
\item	WHAT APPLICATION DO YOU RUN WHEN USING THIS?
    \begin{nrtc}
    \item	CAN'T RUN INTERNET APPLICATIONS IN THE OSI NETWORK,
		SINCE THE TRANSPORT GATEWAY YIELDS OSI TRANSPORT SEMANTICS

    \item	CAN'T RUN OSI APPLICATIONS IN THE INTERNET NETWORK,
		SINCE THE TRANSPORT GATEWAY YIELDS INTERNET TRANSPORT SEMANTICS
    \end{nrtc}

\item	THIS APPROACH FAILS BECAUSE IT PRESENTS DIFFERENT SERVICE SEMANTICS
	IN EACH NETWORK
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part	{SERVICE-BASED APPROACHES}\bf

\begin{nrtc}
\item	BY THE TIME OSI-BASED NETWORKS ARE TRULY WIDESPREAD,
	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	IN OTHER WORDS, PERHAPS THE TRANSITION TO OSI BEGINS WITH NEW
	APPLICATIONS ON HOSTS AND NO CHANGES TO THE NETWORK
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{WOULD THIS REALLY HAPPEN?}

\begin{nrtc}
\item	RECALL THAT USERS ARE INTERESTED IN \underline{SERVICES} NOT
	\underline{PROTOCOLS}

\item	THE OSI APPLICATIONS ARE MUCH RICHER THAN THEIR INTERNET COUNTERPARTS

\item	IN CONTRAST, AT THE LOWER-LAYERS THE INTERNET SUITE ``WORKS BETTER''
    \begin{nrtc}
    \item	AS SUCH, IT IS UNLIKELY TO BE REPLACED BY THE OSI LOWER-LAYERS
		FOR QUITE SOME TIME
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{OBSERVATION}

\begin{nrtc}
\item	GIVEN THE ABOVE ASSUMPTION, IT SHOULD BE NOTED THAT:
    \begin{nrtc}
    \item	WE HAVE TWO COMMUNITIES 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, END-TO-END, BETWEEN THE TWO
    \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}
\part*	{TRANSPORT-SERVICE BRIDGES}\bf

\begin{nrtc}
\item	INTRODUCE A TRANSPORT ENTITY CALLED THE ``TS-BRIDGE''
\begin{quote}\em
``Users are interested in services, not protocols.''\\ \raggedleft
-- Marshall Rose, NYSERNet, Inc.
\end{quote}

\item	ALTHOUGH MANY DIFFERENT TS-STACKS EXIST,
	THEY ALL PROVIDE THE SAME TRANSPORT SERVICE

\item	SO, IT IS STRAIGHT-FORWARD TO BUILD A BOX THAT:
    \begin{nrtc}
    \item	KNOWS NOTHING ABOUT TRANSPORT PROTOCOLS, BUT

    \item	KNOWS HOW TO USE THE RELATIVELY SIMPLE OSI TRANSPORT SERVICE
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

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

\begin{nrtc}
\item	THE TS-BRIDGE ``COPIES'' SERVICE PRIMITIVES FROM ONE TS-STACK 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}
\end{nrtc}
\end{bwslide}


\f

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

\vskip.5in
\diagram[p]{figureT-9}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{CONS vs. CLNS CONNECTIVITY}

\vskip.5in
\diagram[p]{figureT-19}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{USE OF THE TS-BRIDGE (cont.)}

\begin{nrtc}
\item	ENCODE THE NETWORK ADDRESS AND TRANSPORT SELECTOR AS AN OCTET STRING,
	CALL THIS THE NEW TRANSPORT SELECTOR

\item	USE THE NETWORK ADDRESS OF THE TS-BRIDGE FOR THE REMAINING STEPS

\item	WHEN TS-BRIDGE RECEIVES CONNECTION,
	IT SIMPLY DECODES TRANSPORT SELECTOR TO FIND ADDRESS OF
	DESTINATION END-SYSTEM
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{TS-BRIDGE ADDRESSING}

\vskip.5in
\diagram[p]{figureT-20}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{THE TS-BRIDGE AND THE OSI MODEL}

\begin{nrtc}
\item	THE TS-BRIDGE IS A LEVEL-FOUR ROUTER

\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

    \item	\underline{MAY} THWART SOPHISTICATED BACK-PRESSURE TECHNIQUES
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

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

\begin{nrtc}
\item	FIRST DEMONSTRATION IN FEBRUARY, 1988
    \begin{nrtc}
    \item	TP4/CLNP to RFC1006/TCP
    \end{nrtc}

\item	ANOTHER IMPLEMENTATION IN EUROPE IS HANDLING
    \begin{nrtc}
    \item	TP0/X.25 to RFC1006/TCP
    \end{nrtc}
\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	AMENABILITY:
    \begin{nrtc}
    \item	TCP END-SYSTEMS MUST RUN ``NEW'' PROTOCOLS
	\begin{nrtc}
	\item	BUT, NO MODIFICATIONS REQUIRED TO END-SYSTEM KERNELS
	\end{nrtc}

    \item	MAY INTRODUCE ADMINISTRATIVE PROBLEMS
    \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
\begin{quote}\em
``Encapsulation complies with the layering concept, but violates the notion
of absolute levels.''\\ \raggedleft
-- Danny Cohen and Jon Postel, ``The ISO Reference Model and Other Protocol
Architectures'' (1983)
\end{quote}

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

\item	METHOD SPECIFIED IN [RFC1070]

\item	ADDRESS MAPPINGS SPECIFIED IN [RFC1069] 
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{TUNNELING}

\vskip.5in
\diagram[p]{figureT-18}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{NETWORK TUNNELS}

\vskip.5in
\diagram[p]{figureT-10}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{INTERESTING FEATURES}

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

\item	A TRUE END-TO-END CHECKSUM
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{POTENTIAL PROBLEMS}

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

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


\f

\begin{bwslide}
\ctitle	{AN IMPLEMENATION OF AN NS-TUNNEL}

\begin{nrtc}
\item	HAVEN'T SEE ANY YET
    \begin{nrtc}
    \item	BUT WILL BE IN 4.4BSD UNIX
    \end{nrtc}

\item	NEED A LOT OF CLNP-BASED NETWORKS BEFORE THIS IS OF USE

\item	SO THIS WILL HAPPEN AT THE END OF THE TRANSITION PERIOD
\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	AMENABILITY: TCP END-SYSTEMS MUST RUN BOTH TRANSPORT PROTOCOLS
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part	{EXAMPLES}\bf

\begin{nrtc}
\item	U.S.~DoD OSI IMPLEMENTATION PLAN

\item	GENERIC EXAMPLE

\item	CONCLUSIONS
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\part*	{U.S.~DoD OSI\\ IMPLEMENTATION PLAN}\bf

\begin{nrtc}
\item	IMPLEMENT CAPABILITY TO USE OSI IN DoD INTERNETWORK ENVIRONMENT
    \begin{nrtc}
    \item	OSI-POSIX PROJECT
    \end{nrtc}

\item	PROVIDE THE CAPABILITY FOR U.S.~DoD AND OSI PROTOCOLS TO INTEROPERATE
    \begin{nrtc}
    \item	FTAM-FTP GATEWAY

    \item	MHS-SMTP GATEWAY
    \end{nrtc}
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{OSI-POSIX PROJECT}

\begin{nrtc}
\item	GOAL: ACCELLERATE THE UBIQUITY OF OSI

\item	APPROACH: OPENLY AVAILABLE, COMPLETE OSI IMPLEMENTATION FOR NEXT MAJOR
	RELEASE OF BERKELEY \unix/

\item	FOR MORE DETAILS:
\begin{quote}
OSI PROTOCOLS WITHIN AN OPENLY AVAILABLE, POSIX-CONFORMANT, BERKELEY UNIX
ENVIRONMENT
\end{quote}
APPEARING IN ConneXions, OCTOBER, 1988
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\diagram[p]{figureT-15}
\end{bwslide}


\f

\begin{bwslide}
\diagram[p]{figureT-16}
\end{bwslide}


\f

\begin{bwslide}
\part*	{GENERIC EXAMPLE}\bf

\begin{nrtc}
\item	TWO PRONGS:
    \begin{nrtc}
    \item	FAVOR USE OF OSI APPLICATIONS OVER TCP ON LAN MESH

    \item	LOCATE APPLICATION GATEWAYS AND A TS-BRIDGE ON ALL NODES
		WITH WAN ATTACHMENETS
    \end{nrtc}

\item	AWAIT OSI LOWER-LAYERS TO BECOME COMPETITIVE
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{GENERIC EXAMPLE (cont.)}

\begin{nrtc}
\item	EACH ATTACHMENT LOCUS SHOULD SUPPORT COEXISTENCE SERVICES

\item	IF RESOURCES PERMIT, SELECT ONE OTHER SYSTEM TO SUPPORT THESE
	SERVICES FOR USE BY LOCAL UNI-STACK HOSTS

\item	THIS ``COVERS ALL BASES'' BY HANDLING ALL POSSIBLE OSI COMBINATIONS
	WITH A BIT OF EXTRA REDUNDANCY

\item	MIGHT REQUIRE A BIT OF SOPHISTICATED USE FROM THE DIRECTORY
\end{nrtc}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{A LAN OF MANY COLORS}

\vskip.5in
\diagram[p]{figureT-17}
\end{bwslide}


\f

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

\begin{quote}\em
``Optimality differs according to context.''\\ \raggedleft
-- Michael Padlipsky, The Elements of Networking Style (1985)
\end{quote}
\end{bwslide}


\f

\begin{bwslide}
\ctitle	{CONCLUSIONS (cont.)}

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

\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 AND ROBUSTNESS
    \end{nrtc}

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

\end{document}
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦1bcf4b1db⟧ TextFile

Derivation

TextFile
