Re: Layering, to allow alternative protocols between particular hops

[Martin W Sachs <mwsachs@us.ibm.com>]

I neglected to include the list on the following.

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************
---------------------- Forwarded by Martin W Sachs/Watson/IBM on 09/16/2001
06:04 PM ---------------------------

Martin W Sachs
09/16/2001 06:02 PM

To:   "Dan Weinreb" <dlw@exceloncorp.com>
cc:
From: Martin W Sachs/Watson/IBM@IBMUS
Subject:  Re: Layering, to allow alternative protocols between particular
      hops  (Document link: Martin W. Sachs)

Dan,

A few comments below.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Dan Weinreb <dlw@exceloncorp.com> on 09/15/2001 04:22:46 AM

Please respond to "Dan Weinreb" <dlw@exceloncorp.com>

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   ebxml-msg@lists.oasis-open.org
Subject:  Layering, to allow alternative protocols between particular hops



   Date: Fri, 14 Sep 2001 10:19:28 -0400
   From: "Martin W Sachs" <mwsachs@us.ibm.com>

Let me address your points in a different order than the order in which
you presented them.

   Also, as the Arpanet evolved (into the Internet),

OK, I promise, no more Arpanet.  From now on I'll use Internet analogies.

                                   everything in the cloud
   speaks IP.  There is no free-for-all choosing of unique protocols
between
   different nodes.

Sure there is: you have to keep in mind the layers of the protocol
stack.

MWS:  I was referring specifically to the IP layer.  The last I knew,
IETF recognizes only one protocol at this layer (albeit with a few
versions being used).

A TCP implementation is a software module running at layer 4
(ISO OSI terminology).  It runs the TCP algorithms and finally calls
into layer 3.  The layer-4-to-layer-3 API specifies that layer 4
passes an Internet Protocol packet, which specifies a destination in
the form of a 32-bit Internet address, and layer 3 promises to make an
effort to deliver the packet.  The software module running at layer 3
now has, precisely, a free-for-all choosing of unique protocols at
layer 2.  It might decide, for example, to use Ethernet, or it might
decide to use token ring.

Now, there seems to be lack of universal agreement about whether we're
trying to put together the kind of architecture in which there can be
an A-B-C-D link in which B talks to C using some protocol that we
didn't define.  I think the mail of the last few days shows that some
people think this is within our charter and some have not thought of
it as being in our charter.  Somewhere along the line, I would think
that a decision has to be made about this.  For purposes of exploring
the former alternative I will assume that this is what we're trying to
do.

MWS: If we continue to work on trying to incorporate non-ebXML protocols
into ebXML-MS, it will never end.  We should make it out of scope at least
for V1.1.  I have covered this in recent postings.

If we're trying to do this, I think it's cleanest to adopt a layered
approach analogous to the Internet example.  In this analogy,
hop-to-hop communication is analogous to ISO layer 2.  Each hop-to-hop
link can make its own choice about whether to use one or another layer
2 protocol.  And note that there would be nothing special about the
*first* hop!

MWS:  We need the layering but we are firmly inside one layer. The layers
below us are the responsibility of other standards bodies and in any case
are below us.  The layers above are, for our purposes, application code. I
know
of no analogy to dealing with multiple protocols at our layer.  I don't
believe
TCP does it and I certainly don't believe that Ethernet does it.

   Re:  "Is there some special rule about hops to which the endspoints are
   parties, that makes those hops different from IM-to-IM hops?"

   Of course, there is such a rule.  If A and D want to communicate via
ebXML,
   each one has to be using an ebXML interface (MSH) and therefore both A
and
   D have to use ebXML to get to their adjacent intermediaries.

I've tried, above, to explain why I think that in a clean
architecture, if B and C are allowed to pick an appropriate protocol,
then A and B should be treated exactly the same way.

MWS:  See my earlier comment about "virtual" ebXML nodes that might contain
hidden hops that use other protocols. Those hops are outside our scope.

If B and C can pick their own protocol, then we need to split the
concept of "protocol" as we've been using it into two layers.  The
higher layer is the "protocol" by which A talks to D (analogous to
layer 3, the Internet Protocol).  The lower level are the protocols by
which A talks to B or B talks to C (analogous to layer 2, which ISO
calls the Data Link layer).

MWS:  If we split the MS layer into two, we still have only ebXML.  The
basic message exchange function is in the lower layer and the reliable
messaging function is in the upper layer.

Having done that, we clearly want to define the higher layer.  It's
also completely clear that we want to define the official API between
the higher layer and the lower layer.  Do we want to specify any
particular lower layer protocol?  You (Marty) said earlier that B
should be allowed to talk to C however it wants to, including using
protocols that were not defined by the ebXML MS group.

MWS:  Yes.  We can't stop it but the alternative protocols are still
outside OUR scope.

 So, B and C
have a menu of alternatives, some of which are not from us.  Do we
want to provide one of those alternatives, or do we want to consider
that to not be in our charter and say that *all* of them are not from
us?  I suspect the former, but as I mentioned earlier, there doesn't
seem to be unanimity about our charter here.

MWS:  Non-ebXML protocols are outside our scope.  We have gone through
weeks of discussion of the problems with dealing with them in an
ebXML network.

   Re: "far clearer to portray ebXML as two protocol layers".  We have that
   right now, one is defined by the MS spec and the other is defined by the
   BPSS spec.  I don't think that there is much inside the MSH that can be
   split into to layers that may be in different boxes.

By my reckoning, the BPSS spec is more like layer 4.  If you want to
count the BPSS as a layer, then I'm saying that we need to have
*three* layers instead of two, if we want a clean implementation that
lets B and C pick their own protocol.

One of the main reasons for using layering in protocol designs is to
control sharing: what is common and what is not common.  On the
Internet, we all do TCP and IP in common, but we can pick and choose
among Ethernet, token ring, and whatever Data Link implementations are
being used over the backbone fibre nets these days.  In your model of
multi-top ebXML, we all adopt a common concept of how A and D talk to
each other, and yet we are free to allow B and C to pick their own way
to talk to each other.

MWS:  Yes - we can't stop B and C from doing something different from
ebXML-MS but we can encapsulate that in a "virtual" ebXML node which
contains the foreign protocol inside it and then forget about it.