Date: Tue, 27 Jul 1999 15:05:47 -0500 (CDT) From: Mark Tinguely <tinguely@plains.NoDak.edu> To: mike@sentex.net, rh@source.net Cc: atm@FreeBSD.ORG Subject: Re: NIC questions Message-ID: <199907272005.PAA27670@plains.NoDak.edu>
next in thread | raw e-mail | index | archive | help
our ATM code is in its infancy. the network stack and driver are in seperate modules, but are written for each other. each package was driven by different goals and funding. my pie in the sky observation is that we need to do is integrate the packages and choose the seperate the stacks per virtual circuit. ie VPI/VCI 0/40 is IP over ATM using HARP, 0/62 is native ATM using the WU stack, 0/35 is MPOA, 0/92 is PPP over ATM, 0/44 is RFC1483, etc. As best i can tell, it would be difficult to determine what the traffic type is automatically like ethernet does, because there are no equivalent to the ethernet type field in these protocols, though some sniffers figure it out by watching traffic...I think we would have to have a virtual circuit equivalent to "ifconfig" to set the protocol. enough rambling. on the wire: there are different line stack protocols for LANEv1, LANEv2 (with or without MPOA), PPP over AAL. even for RFC1483 SNAP/LLC has a routed and bridged modes. what you are trying to do: sounds like you are trying to make a edge device. edge devices differ for each protocol. FreeBSD does not have a LANE or MPOA stacks (though the Linux stack has a Berkeley-style copywrite, that may be hammered somewhere into our code seems possible). PC as software switches: the bad thing about using PC for small switches is that the cell interrupt rate to reconstruct PDUs would make you want to use the ATM card's Sequencer and Re-assembler (SAR). then you have to wait for the whole PDU to be constructed routed and then re-transmitted. new latencies and traffic shaping problems. you also have to be aware of the protocol that you are routing (which may not be a problem if you are moving only IPv4 around). home stations: another driving force for ATM in FreeBSD is xDSL services. DSL uses SNAP/LLC (which appears to be real easy addition) and/or PPP over ATM (a kernel-only implementation would be moderately easy). some vendors claim support for RFC2225 (was RFC1577) Classic IP over ATM and Native ATM, but IMO, these are could-a, should-a would-a marketing talk. these are all my opinions. --mark. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-atm" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907272005.PAA27670>