The IP Over NBMA (ION) Archive

[gnelson@zynrgy.com (Gary A. Nelson)]

Juha,
Very interesting. I have been mulling over alternatives and began to
reconsider SMDS -- that is the "new SMDS" over ATM/AAL5 model. It could be
*adapted* to IP switching/routing by ripping out the 802.6 MAC packet and
substituting IP. What you are suggesting here appears to me to be very
similar to that. SMDS model looks for a First_Cell_of_Packet (a BOM in the
old AAL3/4 days), now done using AAL5 with a new VCI for each packet that
identifies all cells of the same packet. Then opens the "BOM_cell" payload
and routes based on E.164 address >> substitute IP address and we're in
business. ATM/IP/SITA switch must set up a local connection for all the
cells with the same VCI -- then drop connection -- effect is connectionless
routing. Can appropriate much of the SMDS over ATM/AAL5 work and get this
done quickly -- SITA is a fine name, BTW.

Gary Nelson

>hello folks,
>
>cisco's tag switching proposal inspired me to come up with the following
>(either competing or complimentary, i don't know) scheme to connect ip
>routers simply and efficiently through an atm network.  i say through
>instead of over, since the solution is based on the peer model, but may
>be it still fits to the charter of this wg.  i would like to thank yakov
>for his comments that have further simplified the scheme, but don't
>blame him if you don't like what i'm proposing.  in order to allow
>people to refer to this scheme with a name, for now i call it SITA
>(switching ip through atm).
>
>the problem
>-----------
>
>how to efficiently use an atm network to interconnect together a set of
>ip routers, such as the access/edge routers of an isp or the
>departmental routers of a campus.  the mechanism should scale to a
>couple of hundred routers and should support both unicast and multicast
>traffic.
>
>unicast solution
>----------------
>
>both the routers and the atm switches are configured to participate in
>ospf or par and belong to the same as.  communication with other as'es
>takes place via some of the border routers using bgp.  the routers know
>about all destinations (unless the external connectivity allows the use
>of default routes), but the atm switches in the middle need only to know
>how to reach the routers (acknowledgements to yakov about this).
>
>the vpi/vci tables of the atm switches are configured by ospf or par so
>that a router with router id x can be reached via vpi=y/vci=x, where y
>is the router id of any router participating in the system.
>
>now if a router y receives a unicast ip packet, whose destination
>according to its routing table is reached via router x, it sets
>vpi=y/vci=x for all cells generated from this packet and sends them to
>the atm switch that it is connected to.  the vpi is set to y in order to
>solve the problem of interleaving cells from different aal5 frames.
>
>scalability:  at most 4k routers.
>
>the remaining question is, how to map the four byte router id uniquely
>to the (smaller) vpi space. to this i don't have a general answer.  in
>case of ospf, one possibility would be to use the lower order bits of
>the router id and configure the router ids in such a way that these bits
>are unique.  for par we may design this in, since par work has not been
>completed yet.  a general solution might require a protocol to propagate
>the mappings among the participants.  suggestions are well come, since
>i'm not very familiar with ospf.
>
>multicast solution
>------------------
>
>both the routers and the atm switches are configured to participate in a
>multicast routing protocol that computes either a single spanning tree
>per multicast group or one spanning tree per each router per multicast
>group. i'm not going into the details of various multicast protocols,
>since i'm not familiar with them.
>
>the vpi/vci tables of the atm switches are configured by the multicast
>routing protocol so that the leaf routers of a multicast group x can be
>reached via vpi=y/vci=x, where y is the router id of any router
>participating in the system.  if a particular branch of the spanning
>tree is pruned, no cells are sent to such a branch.
>
>now if a router y receives a multicast ip packet whose destination
>multicast address is x, it sets vpi=y/vci=x for all cells generated from
>this packet and sends them to the atm switch it is connected to (unless
>the group is totally pruned).  the vpi is set to y in order to solve the
>problem of interleaving cells from different aal5 frames in case a
>single tree is used for the whole multicast group.
>
>scalability: at most 4k routers and at most 16k routers plus multicast
>groups.
>
>again the remaining question is, how to map the four byte multicast
>address uniquely to the (smaller) vci space. it is very unlikely that an
>algorithmic mapping could be found, so either the distribution of the
>mappings is built in into a multicast routing protocol or a separate
>protocol is introduced.  again suggestions are well come.
>
>advantages
>----------
>
>good enough scalability for most ip networks run by a single
>organization.  no need to use atm signalling protocols.  simultaneous
>use of the atm backbone for normal atm use is supported. efficient
>switching of both unicast and multicast packets.  solves the aal5 cell
>interleaving problem.  simple to implement.
>
>that is it. comments are, of course, appreciated.  if any vendors are
>willing to work with me on this, please let me know.
>
>-- juha

********************************
*                                                           *
*   Dr. Gary A. Nelson                            *
*     Zynrgy Group Inc                            *
*       20708 North Deerpath Road          *
*         Barrington, IL 60010-3787         *
*           +1 847 304 0000 vox                *
*              +1 847 304 1929 fax             *
*                 gnelson@zynrgy.com           *
*                                                            *
********************************