Date: Wed, 24 Dec 2008 17:29:05 +0000 From: Bruce Simpson <bms@incunabulum.net> To: Robert Watson <rwatson@FreeBSD.org> Cc: Qing Li <qingli@freebsd.org>, Hartmut Brandt <hartmut.brandt@dlr.de>, freebsd-current@freebsd.org, "Li, Qing" <qing.li@bluecoat.com>, freebsd-net@freebsd.org Subject: Re: NATM hardware available Message-ID: <49527161.1070404@incunabulum.net> In-Reply-To: <495270AA.3010904@incunabulum.net> References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> <B583FBF374231F4A89607B4D08578A4302A8BCC4@bcs-mail03.internal.cacheflow.com> <495165D8.2070409@dlr.de> <495246C9.9090305@incunabulum.net> <alpine.BSF.1.10.0812241712520.69270@fledge.watson.org> <495270AA.3010904@incunabulum.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Simpson wrote: > Robert Watson wrote: >> ... >> Do we have any of the necessary software parts to do simulated ATM >> hardware similar to what if_tap does for Ethernet? Using the VIMAGE >> stuff and virtual ATM hardware might open up the door to a more >> accessible development and test environment. I did the NATM locking >> work essentially "blind" due to a lack of test environment locally, >> which seemed to work out, but a software test system would go a long >> way. > > Loopback would be possible, sure, but you are probably only going to > be able to simulate looped-back PVCs. > Fortunately, the ITU G.DMT mandated use of ATM for xDSL generally only > uses PVCs. P.S. You can probably cut corners for the job, by only marshaling the whole packet payloads for NATM across the loopback boundary. There is little point in simulating the 53 byte cell segmentation-and-reassembly unless you love masochism. Of course, NATM makes the job somewhat easier, by giving you some equivalent knobs -- stuff stashed in NATM socket state usually winds up in the cell headers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49527161.1070404>