Return to tsaptalk.tex CVS log

Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / tsaptalk

Annotation of 43BSDReno/contrib/isode-beta/doc/tsaptalk/tsaptalk.tex, revision 1.1

1.1     ! root        1: % Use LaTeX to process this file
        !             2: 
        !             3: \documentstyle[11pt]{article}
        !             4: 
        !             5: \begin{document}
        !             6: 
        !             7: \title{A MODEST PROPOSAL}
        !             8: \author{Dwight E. Cass\\
        !             9:         Automation Sciences Laboratory\\
        !            10:         Northrop Research and Technology Center}
        !            11: \date{May 15, 1986}
        !            12: \maketitle
        !            13: 
        !            14: \begin{quote}\em
        !            15: This is a transcript of the talk presented to the MAP/TOP Users' Group Meeting
        !            16: on May 15, 1986 in Seattle, Washington.
        !            17: \end{quote}
        !            18: 
        !            19: \bigskip
        !            20: 
        !            21: I am going to limit my comments today to one particular project which is
        !            22: going on at the Corporate Research and Technology Center.  That is not to
        !            23: say that Northrop is not doing other MAP and TOP related projects.  There
        !            24: are a number of other opportunities currently being explored, including
        !            25: an RFI which was recently released by our Aircraft Division looking to
        !            26: vendor support headed to MAP and TOP.
        !            27: 
        !            28: At the Research Center, we are looking towards long range solutions to
        !            29: Northrop, which is an aerospace vendor.  We have a number of unique problems
        !            30: which General Motors doesn't directly address.
        !            31: 
        !            32: We have identified two specific problems that we are trying to address.  The
        !            33: first problem is a lack of application protocols.  This lack has been
        !            34: identified and is being addressed within the MAP and TOP community but is
        !            35: not being addressed quickly enough.  The biggest problem that we have seen
        !            36: is that history has shown that the application level protocol development
        !            37: takes as long or significantly longer than the lower level protocols.
        !            38: 
        !            39: The second problem that we have seen is that currently we do not have MAP
        !            40: and TOP for all the machines we have throughout the corporation.  One of
        !            41: the biggest problems we have is with IBM right now.  Over 50\% of the
        !            42: machines that we have in house are IBM equipment.  It is not adequate
        !            43: to put Series Ones talking to SNA.  ({\em Applause\/})  Our customers
        !            44: are the Department of Defense.  He wants us to talk electronically, TODAY!
        !            45: He is not willing to wait.
        !            46: 
        !            47: The cause of these problems --- first, MAP/TOP, while unbelievably
        !            48: successfully is still very very young.  There is quite a bit more work
        !            49: to be done.  All the work that is going on right now that the standards
        !            50: committees are developing must be embodied.  We have to continue this
        !            51: level of effort.  But, Northrop has its requirements NOW!  We need to
        !            52: be able to communicate with the participants electronically.  We need to
        !            53: have factory and division-wide networking installed and operational in
        !            54: the '88 to '89 timeframe.  We cannot consider continuing to make large
        !            55: investments in SNA.  And it is simply not acceptable for Northrop to
        !            56: shutdown its factory for a large period of time to replace existing
        !            57: equipment and throw it out.  Finally, any solution that we take, if we
        !            58: choose to do something other than a pure MAP/TOP solution must be
        !            59: consistent with the directions of this body.
        !            60: 
        !            61: Two observations to be made at this point.  The first is that many of
        !            62: these problems have been solved in the past, though definitely in
        !            63: different environments.  There are several other proprietary and research
        !            64: based protocol suites, which address many of these problems.  The second
        !            65: observation is that MAP/TOP is a highly layered protocol, and indeed is
        !            66: a subset of ISO.  As a matter of fact, it is a walk-through the tree
        !            67: of the ISO protocols.  The key here is that layered protocols allow mixing
        !            68: and matching of layers as necessary.  We are trying to emphasize here
        !            69: services provided by each layer, not necessarily the implementation
        !            70: of those services at the low level.  So the question that we have to ask is,
        !            71: How does Northrop get communications now that would be consistent with
        !            72: MAP/TOP and that would communicate electronically with the DoD?
        !            73: 
        !            74: Now, we have to look to the DoD for the solution, and the solution seems
        !            75: to be TCP/IP.  This is a protocol suite installed in 1980 on the ARPAnet
        !            76: worldwide internet.  It has been mandated for use for all DoD
        !            77: internetworking.  It has a high emphasis on reliability and security.
        !            78: It supplies currently virtual terminal service, electronic mail, file
        !            79: transfer services, and a number of other less advertised capabilities.
        !            80: It has wide, wide vendor support.  I can go out today and buy TCP for
        !            81: every machine that I have in house, off the shelf, install it easily,
        !            82: and specifically, I can buy TCP/IP for every piece of IBM hardware that I
        !            83: have.
        !            84: 
        !            85: TCP/IP specifically supports a very robust transport service, as documented
        !            86: in the National Research Council report comparing TCP/IP to ISO, the
        !            87: functionality of these two protocols are pretty much identical.  The other
        !            88: observation here is that TCP/IP, due to it's vendor support and it's
        !            89: openness, has been implemented in board level products.  This allows us
        !            90: to place TCP/IP in existing pieces of hardware that are fully loaded,
        !            91: without making major impacts on the CPU capabilities that we have in house.
        !            92: 
        !            93: So, how do we construct this solution and stay with where MAP/TOP is going?
        !            94: The only solution seems to be complementary coexistence.  We need the
        !            95: best of both worlds.  This will give us the opportunity to run today,
        !            96: to run tomorrow, and by the time that the Department of Defense has met
        !            97: ISO, we'll be already there.  It is important to emphasize that Northrop
        !            98: is looking for an evolutionary migration path to its communications problems.
        !            99: It is not willing to accept throwing away and starting again.
        !           100: 
        !           101: If you are going to talk about coexistence, you are going to have to decide
        !           102: where you are going to join the two protocols.  Several places come to
        !           103: mind.  One of the earliest proposals was to join at the IP layer.  To do
        !           104: this, of course, would require that we implement a full TP4.  It didn't
        !           105: seem practical, and it didn't seem to be cost effective, besides the fact
        !           106: that it prohibits us from using board level products.  We looked at
        !           107: implementing at the Session layer, but the problem is that above Transport,
        !           108: we start dealing with the problems of the symmetric ISO model versus the
        !           109: client/server ARPA model.  The only obvious point was at the Transport
        !           110: Service Access Point.  This gave us the capability of using the robust
        !           111: TCP transport service while still allowing MAP freedom to do whatever
        !           112: was necessary at the higher layers, isolating the applications from 
        !           113: the reality of whatever they were running.
        !           114: 
        !           115: Where are we headed today?  At the Research Center we published a
        !           116: proposed Transfer Service Access Point.  We then implemented this proposal
        !           117: on a Berkeley 4.2 UNIX system, and have since published this proposal
        !           118: within the ARPA internet community as RFC983.  RFC983 fully describes
        !           119: a TP4/TSAP implementation on top of TCP.  Everything except for, of course,
        !           120: quality of service is supported within the implementation, because as you
        !           121: know, quality of service is not defined yet.  For addressing we have to take
        !           122: TCP/IP-based addressing, however we would be more than happy to start dealing
        !           123: with the addressing issue as the Standards Committees do, and currently
        !           124: we have an implicit maximum TSDU size of 65 Kbytes, but that will be
        !           125: relaxed in the next version.  I do have with me today, copies of the RFC
        !           126: and I can get a hold of the source code for you.  This is all public
        !           127: domain work.  You are all welcome to take it and if you need, work with it.
        !           128: 
        !           129: Our next step.  What we need next is to put an implementation of Session, FTAM,
        !           130: and CASE on this TSAP.  One of the important things here is we can go
        !           131: off and write it, but it would invalidate any hopes of compatibility between
        !           132: MAP and what we're doing.  As such, we must find a version of Session, FTAM
        !           133: and CASE intended for a functional MAP system --- hopefully public domain,
        !           134: so we can distribute it to the ARPA internet community.  The other thing
        !           135: that we will be doing is implementing this RFC on the other machines
        !           136: currently within Northrop.
        !           137: 
        !           138: As a migration strategy to ISO, RFC983 is not planned solely as a migration,
        !           139: but could easily form the backbone for a full migration plan.  What we are
        !           140: hoping to do is to fully track what the Department of Defense does over the
        !           141: next several years to yet bring us to ISO when our customers have.
        !           142: 
        !           143: In summary, what we think we found is the best of all worlds.  We can talk
        !           144: to our customer today with such a capability.  We can install and perform
        !           145: research, today.  We can develop MAP/TOP applications, today.  We can migrate
        !           146: to ISO as our customer does.  We solved the security problem for our
        !           147: communications, and reaped the benefit of all the researchers within the
        !           148: Department of Defense internet community.
        !           149: 
        !           150: Thank you very much.  ({\em Applause\/})
        !           151: 
        !           152: \end{document}

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.