[Sis-SCPS-INTEREST] Testing of SCPS-TP

Madza, Boniface Boniface.Madza at gdcanada.com
Wed Sep 14 11:55:06 EDT 2005 

Talking about TUN and TAP interfaces, does anybody know if there are
equivalent concepts 
in the MS Windows environment? How would one implement the "bridge mode"
for example, in a MS Windows environment?

-----Original Message-----
From: sis-scps-interest-bounces at mailman.ccsds.org
[mailto:sis-scps-interest-bounces at mailman.ccsds.org] On Behalf Of
Feighery,Patrick D.
Sent: Wednesday, September 14, 2005 8:46 AM
To: Marcin Jessa
Cc: sis-scps-interest at mailman.ccsds.org
Subject: RE: [Sis-SCPS-INTEREST] Testing of SCPS-TP

I've cut and pasted your comments/question versus putting them in-line.
It was hard for be to follow things.

	Pat


Comment/Question  #1
>>The first tests are looking very promising though.

I'm glad things are looking good for you.


Comment/Question #2
>>Is it possible to set up SCPS in bridged mode and make the gateways 
>>even more transparent ?
>>I tried playing with it but it seems like bridge and divert do not 
>>play together.
>>Could one maybe use ipf or pf instead of ipfw and divert ?
>>Or would that approach work on another O.S ?

Well under the linux operating system I use the TAP interface to make
SCPS into a bridge mode.  Therefore things like routing tables and every
arp caches are moot.  FreeBSD, as I understand it, also has a port of
the TAP interface. I spent some time (I'll admit not a lot of
time) trying to get the TAP interface under FreeBSD working, without
success.  I without much documentation I just could not get even a
simple tap program working. 

If someone has some info on how TAP and freeBSD work together, in my
copious spare time, I'll give it another try...


Comment/Question #3
>>What I am also trying to work out is if I can run SCPS as gateway on 
>>NetBSD.
>>Running ./configure --gateway=yes  gives me following message:
>>"The SCPS Gateway is only supported on the FreeBSD Operating System 
>>version 2.2.2 or greater or the Linux Operating system."

I know NetBSD, although I have not used it in probably 5+ years, is
similar to FreeBSD. If NetBSD contains a divert or the tun/tap interface
it probably should not be too hard to move it.  Are you familiar with
the tun/tap interface?


Comment/Question #4
>>Although the README file says:
>>"The SCPS lower layer software and the SCPS example applications have 
>>also been ported to NetBSD, Solaris 2.5 or higher, and IRIX 5.3."
>>What are those example applications ?

Well when the SCPS RI was originally developed, it was thought of a
stand along application, therefore in the apps directory you will see
some trivial application.  Honestly. Only ttcp works,  The other ones in
this directory are so trivial I have not updated them.  Also if you look
in the FP directory, there is an implementation of the SCPS FP protocol
written by ??Steve Sides??  The SCPS standards was originally meant for
DoD and NASA missions, however it was obviously that it had wide spread
applicability in the commercial satellite and wireless environment.  So
we developed the transparent transport layer version of the SCPS RI.  We
needed some way to pass packets from the kernel to application space and
bypass the standards in-kernel TCP processing.
I've work in the BSD environment for a long time so I was familiar with
those Oss.  At that Time FreeBSD 2.2 just came out containing divert
sockets.  This was exactly what I was looking for to the original
development of the SCPS gateway was done in FreeBSD.  With the
popularity of linux, I went searching for a way to duplicate the divert
functionality in linux.  The tun/tap interface provides the exact
functionality I needed.
 
 

Comment/Question #5
>>One more thing I am curious about is the hardware requirement for SCPS

>>gateways.
>>I want to try to make it work on small embedded devices with AMD Geod 
>>266MHZ CPU.
>>How much bw could device like that handle? Are there any 
>>benchmarks/test results for that avaliable ?

Do I have any bench marks available?  Unfortunately not.  But when we
initially developed SCPS, our lab consisted of 300 MHz towers with 32K
of memory.  The really answer it depends on the capacity of the WAN
network and the number of simultaneous TCP connects SCPS needs to
support.

Just to summarize the memory needs.  We allocate memory for the
transport buffers in 32K block and each tcp connection requires at a
minimum 4 blocks.  Each TCP connection from a host requires two
transport connection in the gateway (LAN side and WAN side) and each
connection contains a transmit and receiver buffer.  Therefore a single
tcp connection from a host requires 128KB.  Since FTP actually has a
control and data connection a single ftp connection requires 1/4 Meg of
memory from the gateway.

Obviously the higher the bandwidth the more connection that can be
supported.  I'm guessing that anything under 10 Mbps would work without
problem. 100 Mbps will probably have problems.  Just as an aside, if you
have a 2 Mbps link and have to support 100 active connections then each
connection would only get 20 Kbps.  


================================================


>>-----Original Message-----
>>From: Marcin Jessa [mailto:lists at yazzy.org]
>>Sent: Tuesday, September 13, 2005 8:45 AM
>>To: Feighery,Patrick D.
>>Cc: sis-scps-interest at mailman.ccsds.org
>>Subject: Re: [Sis-SCPS-INTEREST] Testing of SCPS-TP
>>
>>On Thu, 8 Sep 2005 12:30:37 -0400
>>"Feighery,Patrick D." <feighery at mitre.org> wrote:
>>
>>>  See comment in-line
>>> 
>>> 
>>> >>-----Original Message-----
>>> >>From: sis-scps-interest-bounces at mailman.ccsds.org
>>> >>[mailto:sis-scps-interest-bounces at mailman.ccsds.org] On Behalf Of 
>>> >>Marcin Jessa
>>> >>Sent: Thursday, September 08, 2005 2:28 AM
>>> >>To: sis-scps-interest
>>> >>Subject: [Sis-SCPS-INTEREST] Testing of SCPS-TP
>>> >>
>>> >>Hi guys.
>>> >>
>>> >>I am trying to set up a test enviroment for SCSP-TP to test it's 
>>> >>performance.
>>> >>I managed to cleanly compile SCPS on both FreeBSD 6.0 and 7.0
>>> >>(CURRENT)
>>> >>with a few minor patches and set up an emulator of a satellite 
>>> >>link using FreeBSD with DUMMYNET.
>>> >>The computer running emulator has two nics set in bridge mode 
>>> >>without assigned IP's adding latency, limiting bandwidht and 
>>> >>simuling lossy link with random packet loss on the traffic going 
>>> >>through the bridge.
>>> >>Being very happy I found www.scps.org and feeling I am failry 
>>> >>familiar with TCP/IP I propably underestimated the amount of new 
>>> >>things I need to learn to understand the mechanism of SCPS.
>>> >>>From what I understand, to successfully finish my setup I
>>> >>need to connect two computers to the bridge of my satellite link 
>>> >>emulator and make them act as transparent SCPS gateways.
>>> >>Which I did creating rfile and running the compiled gateway binary

>>> >>on both the machines.
>>> 
>>> Yes, so far so good.
>>> 
>>> >>Both can ping one another across the bridge and the satellite 
>>> >>emulator works as expected.
>>> 
>>> Yes and note that SCPS compiled for FreeBSD intercepts TCP
>>packets, all
>>> other packets are not touched by the divert rule and are
>>not proxied.
>>> 
>>>  
>>> >>The gateway binary creates divert rules (in addition to allow
>>> >>rules) which can be veryfied as existing/correct with ipfw show. 
>>> >>TCP traffic is diverted to scps:
>>> >>10006 divert 53000 tcp from any to any via fxp1 setup in
>>> >>10007 divert 53001 tcp from any to any via fxp0 setup in
>>> >>10008 divert 52000 tcp from any to any in via fxp1
>>> >>10008 divert 52000 tcp from any to any in via fxp0
>>> >>10008 divert 52000 scps from any to any in via fxp1
>>> >>10008 divert 52000 scps from any to any in via fxp0
>>> >>
>>> 
>>> In looking at this fxp0 is probably your LAN side interface
>>and fxp0 is
>>> probably your WAN side interface.
>>> 
>>> >>After that I connected additional computers to the second inteface

>>> >>of the gateways and from that point I am not quite sure what to 
>>> >>do.
>>> 
>>> Well first remember that SCPS is not a routing protocol so
>>you need to
>>> enable ip_forwarding and have a routing table entry (either
>>static or
>>> dynamic) to route the traffic through the gateway.
>>
>>Thanks, I ofcourse forgot to run sysctl net.inet.ip.forwarding=1. 
>>No wonder I could not make routing work properly.
>>The first tests are looking very promicing though.
>>
>>> After this assuming you have a machine on each gateway's LAN side 
>>> interface, then you should be able to FTP, telnet, http,
>>etc from one
>>> machine to the other.  First I would ping from end machine to end 
>>> machine to make sure the routing/forwarding is all set up properly.
>>> 
>>> >>I guess running natd on the gateways for the networks behind them 
>>> >>or bridging the interfaces on the gateways is not what I am 
>>> >>suppose to do.
>>> 
>>> Correct, NAT is not used at all.  The gateways are
>>transparent and the
>>> only IP addresses seen should be those of the end systems
>>themselves.
>>
>>Is it possible to set up SCPS in bridged mode and make the gateways 
>>even more transparent ?
>>I tried playing with it but it seems like bridge and divert do not 
>>play together.
>>Could one maybe use ipf or pf instead of ipfw and divert ?
>>Or would that approach work on another O.S ?
>>
>>> >>Should I set up OSPF on the gateways to make the networks behind 
>>> >>them talk to one another ?
>>> 
>>> Essentially yes.  I would just have static routes on the
>>gateway boxes
>>> 
>>> >>Could someone be so kind and provide me with aditional steps to 
>>> >>finish my testing?
>>> 
>>> >>I am also wondering if the gateway binary can run as daemon ?
>>> 
>>> Unfortunately not.
>>> 
>>> >>And what does this mean? (I get that error running all the other 
>>> >>scps_* apps in the app/ directory):
>>> >>./scps_ttcp -r -s -H 192.168.2.8
>>> >>UNRECOVERABLE ERROR opening AAA .
>>> >>ERROR: MTU ioctl call on interface  returned -1
>>> 
>>> This is simple side affect on the way the SCPS code was
>>packaged.  If
>>> you configure the code as a gateway then the only binary
>>that makes is
>>> 'gateway'.  Even though the other in the apps directory compile,
the
>>> are worthless.  Conversely if you configure the scps code as a
stand
>>> alone stack 'scps_ttcp' binary is valid while gateway is moot.
>>> 
>>> Hope this helps and makes sense.  If not, let's try and work it
out.
>>
>>What I am also trying to work out is if I can run SCPS as gateway on 
>>NetBSD.
>>Running ./configure --gateway=yes  gives me following message:
>>"The SCPS Gateway is only supported on the FreeBSD Operating System 
>>version 2.2.2 or greater or the Linux Operating system."
>>
>>Although the README file says:
>>"The SCPS lower layer software and the SCPS example applications have 
>>also been ported to NetBSD, Solaris 2.5 or higher, and IRIX 5.3."
>>What are those example applications ?
>>
>>One more thing I am curious about is the hardware requirement for SCPS

>>gateways.
>>I want to try to make it work on small embedded devices with AMD Geod 
>>266MHZ CPU.
>>How much bw could device like that handle? Are there any 
>>benchmarks/test results for that avaliable ?
>>
>>
>>Cheers,
>>Marcin
>>

_______________________________________________
Sis-SCPS-INTEREST mailing list
Sis-SCPS-INTEREST at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-scps-interest

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. 
Thank you.

More information about the Sis-SCPS-INTEREST mailing list