Solaris Network Appliances

There's a lot of interest in using Solaris as a network
appliance of
sorts.  Over time I'd like to see the Appliances community
become
the first point of call for anyone interested in working in
that space.

To kick this off, I've put together a web page that brings
together a
lot of possible projects that might be relevant.  Over time
I'm hoping
that more of the blank squares will get filled in by people
in the
OpenSolaris community, either working alone or with people
at Sun,
in addition to internal Sun projects.

http://www.opensolaris.org/os/communi
ty/appliances/announcements/solnetapp/

If you're aware of other projects, internal or external,
that are relevant,
please let me know and I'll add whatever relevant
information I can.

Darren

_______________________________________________
appliances-discuss mailing list
appliances-discussopensolaris.org
http://mail.opensolaris.org/mailman/listinfo/appl
iances-discuss

Darren,

This is nice. I have a few comments:

- Proper credit needs to go to Sangeeta Misra who suggested
the creation 
of this list and collected the first set of data.

- "low-end" is not the right way to qualify
drivers here. I can imagine 
someone wanting to build an appliance that needs
"high-end" 10Gb NICs. 
So I'd suggest replacing this by "Network device
drivers".

- I don't think the "responsible" column is
really appropriate in the 
context of the OpenSolaris community. I'd suggest replacing
this column 
with a "Project" column pointing to the
appropriate OpenSolaris 
projects. It seems that the first column is listing the
technology areas 
rather than project names.

- Missing from the list is an entry for network resource
control, which 
is being tackled by Crossbow.

- Also missing from the list is IPsec.

Nicolas.

Darren Reed wrote:
> There's a lot of interest in using Solaris as a
network appliance of
> sorts.  Over time I'd like to see the Appliances
community become
> the first point of call for anyone interested in
working in that space.
> 
> To kick this off, I've put together a web page that
brings together a
> lot of possible projects that might be relevant.  Over
time I'm hoping
> that more of the blank squares will get filled in by
people in the
> OpenSolaris community, either working alone or with
people at Sun,
> in addition to internal Sun projects.
> 
> http://www.opensolaris.org/os/communi
ty/appliances/announcements/solnetapp/
> 
> If you're aware of other projects, internal or
external, that are relevant,
> please let me know and I'll add whatever relevant
information I can.
> 
> Darren
> 
> _______________________________________________
> appliances-discuss mailing list
> appliances-discussopensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/appl
iances-discuss

-- 
Nicolas Droux, Solaris Kernel Networking
Sun Microsystems, Inc. http://blogs.sun.com/droux


_______________________________________________
appliances-discuss mailing list
appliances-discussopensolaris.org
http://mail.opensolaris.org/mailman/listinfo/appl
iances-discuss

Nicolas Droux wrote:

> - "low-end" is not the right way to qualify
drivers here. I can 
> imagine someone wanting to build an appliance that
needs "high-end" 
> 10Gb NICs. So I'd suggest replacing this by
"Network device drivers".


I'm not convinced that someone building a high-end
appliance would use 
Solaris - custom silicon would appear, to me, to be the way
to go.

Our current problem area isn't high-end NICs that are 10Gb
capable, but 
cheaper 10/100 NICs that are found on existing motherboards.

That said, I'm not sure nemo is the right project for this
area as the 
driver-discuss forum is discussing ways to bring in more
drivers from 
open source development.

> - I don't think the "responsible" column
is really appropriate in the 
> context of the OpenSolaris community. I'd suggest
replacing this 
> column with a "Project" column pointing to
the appropriate OpenSolaris 
> projects. It seems that the first column is listing the
technology 
> areas rather than project names.


Well, in some cases it is just one person working on a
solution, so it 
seemed wrong to call it "project".  Maybe call
that column "Contact"?

> - Missing from the list is an entry for network
resource control, 
> which is being tackled by Crossbow.


I'm waiting to see what crossbow delivers here.  Network
resource 
control is a problem, I'm just not yet sure that crossbow
is the right 
solution in this space.

> - Also missing from the list is IPsec.


IPsec is already present in Solaris...if you were a vendor
building
a VPN router, what would you want from our IPsec besides
hardware
crypto support?

It may be that we need additional web content, mapping out
what people
need/want to build an appliance and what functionality
Solaris provides
to address that.

Darren

_______________________________________________
appliances-discuss mailing list
appliances-discussopensolaris.org
http://mail.opensolaris.org/mailman/listinfo/appl
iances-discuss

There are quite a few high-end network appliance devices
which  
currently use Linux. NeoPath and Acopia come to mind. By
high-end, I  
mean hefty price tags...

-Moazam

On May 17, 2006, at 6:53 PM, Darren Reed wrote:

> Nicolas Droux wrote:
>
>
> I'm not convinced that someone building a high-end
appliance would  
> use Solaris - custom silicon would appear, to me, to be
the way to go.

_______________________________________________
appliances-discuss mailing list
appliances-discussopensolaris.org
http://mail.opensolaris.org/mailman/listinfo/appl
iances-discuss

On May 17, 2006, at 6:53 PM, Darren Reed wrote:

> Nicolas Droux wrote:
>
>> - "low-end" is not the right way to
qualify drivers here. I can  
>> imagine someone wanting to build an appliance that
needs "high- 
>> end" 10Gb NICs. So I'd suggest replacing
this by "Network device  
>> drivers".
>
>
> I'm not convinced that someone building a high-end
appliance would  
> use Solaris - custom silicon would appear, to me, to be
the way to go.
>
> Our current problem area isn't high-end NICs that are
10Gb capable,  
> but cheaper 10/100 NICs that are found on existing
motherboards.

Now you're restricting the scope to a narrow set of
appliances with a  
more specific set of requirements.

As this list applies to the appliance community at large, it
should  
also embrace high end appliances with different requirements
on  
performance.

>
> That said, I'm not sure nemo is the right project for
this area as  
> the driver-discuss forum is discussing ways to bring in
more  
> drivers from open source development.

It seems this should be split into two separate line items
then:

* The framework used by device drivers, which aims at
leveraging  
hardware capabilities, simplifying driver development, and
how it can  
be better benefit appliances, that's Nemo.

* The drivers availability and issues surrounding their
delivery into  
Solaris. That's what you seem to be talking about here.

>
>> - I don't think the "responsible"
column is really appropriate in  
>> the context of the OpenSolaris community. I'd
suggest replacing  
>> this column with a "Project" column
pointing to the appropriate  
>> OpenSolaris projects. It seems that the first
column is listing  
>> the technology areas rather than project names.
>
>
> Well, in some cases it is just one person working on a
solution, so  
> it seemed wrong to call it "project". 
Maybe call that column  
> "Contact"?

I never saw a rule stating that we can't use the term
"project" if  
only one person is working on a solution.

When they have corresponding OpenSolaris projects or
communities, the  
line items should point to these OpenSolaris projects or
communities,  
instead of specific engineers. The OpenSolaris projects and 

communities themselves lists projects leaders, pointer to
discussion  
groups, etc.

>
>
>> - Missing from the list is an entry for network
resource control,  
>> which is being tackled by Crossbow.
>
>
> I'm waiting to see what crossbow delivers here. 
Network resource  
> control is a problem, I'm just not yet sure that
crossbow is the  
> right solution in this space.

Crossbow is a project in active development which focuses on
network  
virtualization and network resource control. As such it
should be in  
the list so that we can improve the dialog between Crossbow
and the  
appliance community to exchange feedback, requirements, etc.

If you have questions about how we are going to do these
things, you  
are welcome to participate in our project discussions and
ask  
questions or sent us comments. But it's not up to you to
unilaterally  
decide whether or not the project should be in this list
because you  
have a preconceived opinion on the project.

>
>> - Also missing from the list is IPsec.
>
>
> IPsec is already present in Solaris...if you were a
vendor building
> a VPN router, what would you want from our IPsec
besides hardware
> crypto support?

There are functionalities which are currently implemented to
some  
extent in Solaris and could be improved to better benefit
appliances.  
Your list already includes such functional areas, I don't
see what's  
so special about IPsec that you want to keep it out. If
anything list  
a "IPsec improvements for VPN appliances" item.


>
> It may be that we need additional web content, mapping
out what people
> need/want to build an appliance and what functionality
Solaris  
> provides
> to address that.

That was one of the original goals of this list.

Nicolas.

>
> Darren
>

-- 
Nicolas Droux, Solaris Kernel Networking
Sun Microsystems, Inc. http://blogs.sun.com/droux



_______________________________________________
appliances-discuss mailing list
appliances-discussopensolaris.org
http://mail.opensolaris.org/mailman/listinfo/appl
iances-discuss

Darren Reed wrote:
> IPsec is already present in Solaris...if you were a
vendor building
> a VPN router, what would you want from our IPsec
besides hardware
> crypto support?

Which already exists for some hardware.

Which hardware crypto do you have in mind that we don't
have kernel 
drivers for ?


-- 
Darren J Moffat
_______________________________________________
appliances-discuss mailing list
appliances-discussopensolaris.org
http://mail.opensolaris.org/mailman/listinfo/appl
iances-discuss

Darren J Moffat wrote:

> Darren Reed wrote:
>
>> IPsec is already present in Solaris...if you were a
vendor building
>> a VPN router, what would you want from our IPsec
besides hardware
>> crypto support?
>
>
> Which already exists for some hardware.
>
> Which hardware crypto do you have in mind that we
don't have kernel 
> drivers for ?


Non-Sun hardware, e.g. this guy:
http://www.soekris
.com/vpn1201.htm

or do we support that chip?

Darren

_______________________________________________
appliances-discuss mailing list
appliances-discussopensolaris.org
http://mail.opensolaris.org/mailman/listinfo/appl
iances-discuss

Nicolas Droux wrote:

>
> On May 17, 2006, at 6:53 PM, Darren Reed wrote:
>
>> Nicolas Droux wrote:
>>
>>> - "low-end" is not the right way to
qualify drivers here. I can  
>>> imagine someone wanting to build an appliance
that needs "high- end" 
>>> 10Gb NICs. So I'd suggest replacing this by
"Network device  drivers".
>>
>>
>>
>> I'm not convinced that someone building a high-end
appliance would  
>> use Solaris - custom silicon would appear, to me,
to be the way to go.
>>
>> Our current problem area isn't high-end NICs that
are 10Gb capable,  
>> but cheaper 10/100 NICs that are found on existing
motherboards.
>
>
> Now you're restricting the scope to a narrow set of
appliances with a  
> more specific set of requirements.
>
> As this list applies to the appliance community at
large, it should  
> also embrace high end appliances with different
requirements on  
> performance.


If we get someone wanting to do that, I'd welcome it...but
realisticly, 
I just don't see that happening.  If you're developing a
device that is 
working at the cutting edge of networking technology
(10GbE), why would 
you choose an aged and over weight operating system to run
on it?  (Any 
Unix/Unix-like OS fits into that category, IMHO, so I'm not
being picky.)

>> That said, I'm not sure nemo is the right project
for this area as  
>> the driver-discuss forum is discussing ways to
bring in more  drivers 
>> from open source development.
>
>
> It seems this should be split into two separate line
items then:
>
> * The framework used by device drivers, which aims at
leveraging  
> hardware capabilities, simplifying driver development,
and how it can  
> be better benefit appliances, that's Nemo.
>
> * The drivers availability and issues surrounding their
delivery into  
> Solaris. That's what you seem to be talking about
here.


Yes, agreed, driver availability shouldn't be confused with
the framework.

>>> - I don't think the "responsible"
column is really appropriate in  
>>> the context of the OpenSolaris community. I'd
suggest replacing  
>>> this column with a "Project" column
pointing to the appropriate  
>>> OpenSolaris projects. It seems that the first
column is listing  the 
>>> technology areas rather than project names.
>>
>>
>>
>> Well, in some cases it is just one person working
on a solution, so  
>> it seemed wrong to call it "project". 
Maybe call that column  
>> "Contact"?
>
>
> I never saw a rule stating that we can't use the term
"project" if  
> only one person is working on a solution.
>
> When they have corresponding OpenSolaris projects or
communities, the  
> line items should point to these OpenSolaris projects
or communities,  
> instead of specific engineers. The OpenSolaris projects
and  
> communities themselves lists projects leaders, pointer
to discussion  
> groups, etc.


Where possible I've made the project into a link, itself,
pointing to 
relevant content on the opensolaris.org website, which
should fall 
within the relevant community.  Another link to the
community itself is 
not required.

The point of having the column titled
"Responsible" is to indicate that 
someone has been assigned to  looking into it.  Where
possible I've 
provided links to resources/people on opensolaris.org so
that interested 
parties have particular people they can follow up with, if
they're 
interested.  Just having a pointer to some community means
nothing - I 
could fill in lots of blanks that way and what benefit would
it have?  
Close to none.  There are also cases where the people
looking to make 
contact might prefer to have a more discreet and direct
contact, rather 
than being directed to do so through a public forum.

>>> - Missing from the list is an entry for network
resource control,  
>>> which is being tackled by Crossbow.
>>
>>
>>
>> I'm waiting to see what crossbow delivers here. 
Network resource  
>> control is a problem, I'm just not yet sure that
crossbow is the  
>> right solution in this space.
>
>
> Crossbow is a project in active development which
focuses on network  
> virtualization and network resource control. As such it
should be in  
> the list so that we can improve the dialog between
Crossbow and the  
> appliance community to exchange feedback, requirements,
etc.
>
> If you have questions about how we are going to do
these things, you  
> are welcome to participate in our project discussions
and ask  
> questions or sent us comments. But it's not up to you
to unilaterally  
> decide whether or not the project should be in this
list because you  
> have a preconceived opinion on the project.


Someone has to exercise editorial rights over the contents
and I'm not 
going to apologise for that. Otherwise it could become too
open ended 
and a bucket for just any project.  I'm looking for things
that are 
clearly and obviously relevant.

So far, nothing I've seen in either crossbow discussions or

presentations indicates to me that it is doing anything
relevant to 
appliances.  Again, this is my interpretation of what
Crossbow is doing 
and publishing.  The answers to some of my questions, from
Crossbow team 
members on internal lists, have only reinforced this view.

If that changes, with time, I'm happy to update things
then.

>>> - Also missing from the list is IPsec.
>>
>>
>>
>> IPsec is already present in Solaris...if you were a
vendor building
>> a VPN router, what would you want from our IPsec
besides hardware
>> crypto support?
>
>
> There are functionalities which are currently
implemented to some  
> extent in Solaris and could be improved to better
benefit appliances.  
> Your list already includes such functional areas, I
don't see what's  
> so special about IPsec that you want to keep it out. If
anything list  
> a "IPsec improvements for VPN appliances"
item.


What I was trying to do was apply some common sense and
include items 
that were relevant or where we had functional gaps, not just
include 
anything/everything that might be related or is happening in

networking.  Maybe my mental picture differs to that of
others.

If there isn't a clear cut reason to include something, and
I'm lacking 
that clarity with IPsec after reviewing what they're
currently doing and 
have proposed, then I can't see why it should be there.

Darren

_______________________________________________
appliances-discuss mailing list
appliances-discussopensolaris.org
http://mail.opensolaris.org/mailman/listinfo/appl
iances-discuss

On May 18, 2006, at 3:10 PM, Darren Reed wrote:
> Where possible I've made the project into a link,
itself, pointing  
> to relevant content on the opensolaris.org website,
which should  
> fall within the relevant community.  Another link to
the community  
> itself is not required.
>
> The point of having the column titled
"Responsible" is to indicate  
> that someone has been assigned to  looking into it. 
Where possible  
> I've provided links to resources/people on
opensolaris.org so that  
> interested parties have particular people they can
follow up with,  
> if they're interested.  Just having a pointer to some
community  
> means nothing - I could fill in lots of blanks that way
and what  
> benefit would it have?  Close to none.  There are also
cases where  
> the people looking to make contact might prefer to have
a more  
> discreet and direct contact, rather than being directed
to do so  
> through a public forum.

That "someone" assignment when I look at the
list reflects the  
current assignment of Sun resources, which changes with time
and can  
reflect Sun's internal organization. If there's a project
assigned  
for the line item I don't see the need for adding names to
the entry  
as well. Each project already lists its leaders.

> So far, nothing I've seen in either crossbow
discussions or  
> presentations indicates to me that it is doing anything
relevant to  
> appliances.  Again, this is my interpretation of what
Crossbow is  
> doing and publishing.  The answers to some of my
questions, from  
> Crossbow team members on internal lists, have only
reinforced this  
> view.
>
> If that changes, with time, I'm happy to update things
then.

We had an offline discussion earlier today at the end of
which you  
agreed with the value of Crossbow for appliances, and that
it would  
be appropriate for it to be listed there. In general we need
to  
increase the Crossbow documentation efforts to clarify the
use cases  
of Crossbow for applications such as these.

> What I was trying to do was apply some common sense and
include  
> items that were relevant or where we had functional
gaps, not just  
> include anything/everything that might be related or is
happening  
> in networking.  Maybe my mental picture differs to that
of others.
> If there isn't a clear cut reason to include
something, and I'm  
> lacking that clarity with IPsec after reviewing what
they're  
> currently doing and have proposed, then I can't see
why it should  
> be there.

I see that you've added the IPsec tunnel interoperability,
thanks.  
(BTW, it's not being addressed by Clearview.) There are
other reasons  
why IPsec should be listed here: not only for providing
protection  
for the traffic to/from the appliance, but also in the
context of VPN  
appliances and the features needed there (authentication,
IKEv2, etc)

More generally, I think it still makes sense to list related
 
technologies that are related to the appliance space, even
if they  
are considered feature complete and integrated. There are  
improvements that can be made to the existing implementation
(e.g. IP  
forwarding performance), and it can also be a good
repository for  
someone building an appliance and looking for pointers to
existing  
features.

Nicolas.

-- 
Nicolas Droux, Solaris Kernel Networking
Sun Microsystems, Inc. http://blogs.sun.com/droux



_______________________________________________
appliances-discuss mailing list
appliances-discussopensolaris.org
http://mail.opensolaris.org/mailman/listinfo/appl
iances-discuss

Darren Reed wrote:
> Non-Sun hardware, e.g. this guy:
> http://www.soekris
.com/vpn1201.htm
> 
> or do we support that chip?

We don't yet support that chip.  We have been talking with
Hifn about 
various chipsets but things have stalled at the moment due
to licensing 
issues (it is on my todo list to get things restarted with
them).

I believe we can port the *BSD driver for that chip and I
think we even 
have a sample card from Hifn with that chip on it.  Maybe
Soekris would 
like to help us do the port of the *BSD driver.


-- 
Darren J Moffat
_______________________________________________
appliances-discuss mailing list
appliances-discussopensolaris.org
http://mail.opensolaris.org/mailman/listinfo/appl
iances-discuss