Re: Network Stack Code Re-write (Possible motivations...?)
Martes G Wigglesworth wrote: A year, or two, ago, I found such information buried within the Juniper website; however, upon recent attempts at further investigation, both for learning about certifications, and subject matter for this topic, I am unable to locate said information. The historic Juniper blurbs were very informative. I am sure that the information is still available, however, I have not been successful in locating it. Maybe this link helps a little: http://www.juniper.net/solutions/literature/white_papers/200264.pdf Network Operating System Evolution JUNOS Software: Architectural Choices at the Forefront of Networking Juniper’s main operating system, JUNOS software, is an excellent illustration of this industry trend . The basis of the JUNOS software kernel comes from the FreeBSD UNIX OS, an open-source software system . The JUNOS software kernel and infrastructure have since been heavily modified to accommodate advanced and unique features such as state replication, nonstop active routing and in-service software upgrades, all of which do not exist in the donor operating system . Nevertheless, the JUNOS software tree can still be synchronized with the FreeBSD repository to pick the latest in system code, device drivers and development tool chains, which allows Juniper Networks engineers to concentrate on network-specific development . Best regards, O.K. -- Testi oma Interneti kiirust / Test Your Internet speed: http://speedtest.zzz.ee/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Network Stack Code Re-write (Possible motivations...?)
RW rwmailli...@googlemail.com writes: On Sat, 20 Dec 2008 17:54:24 -0500 Lowell Gilbert freebsd-questions-lo...@be-well.ilk.org wrote: However, commercial routers generally do not use their OS kernel this way -- it is far more common that the kernel does send and receive packets within its native IP stack. If I'm understanding you right, I'm surprised by that (the native part). It make any proprietary software less portable. You're also tying your code into third-party internals, which sounds like a maintenance problem. Yes, but I think that's a fairly small effect. The packet send/receive interface involved is generally pretty small, regardless of how you implement it. I would have thought that the likes of Cisco and Alcatel etc would would have reusable codebases that abstract the OS and minimize OS dependencies. That's always a goal, of course. Completely throwing out the protocol stacks in the OS kernel doesn't make most things more portable, though. There are a fair number of system parameters that are already implemented in OS kernels, and reinventing that wheel doesn't buy you anything. What's the advantage, don't routers usually lead OS's in terms of new protocol support? Protocol support per se is generally fairly independent from the OS in a hardware router; high level protocols are usually handled in userland, and low level protocols are mostly a hardware issue. -- Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Network Stack Code Re-write (Possible motivations...?)
Martes G Wigglesworth mar...@mgwigglesworth.com writes: Thanks again for further information on this topic. Where can I find more information this as a research topic. I am talking about Academic/PHD-level information or industry-level information. Academic and commercial information tend to be separate topics. The former is mostly found in peer-reviewed journals, like most academic publication. The latter is harder to get access to, but you can often find corporate white papers and so forth to give you some ideas. I can't think of anything more useful to say unless you have a more specific set of questions to investigate. If you're looking for more of an overview, the usual suspects (books by Comer, Stevens, Tanenbaum, etc.) will be a good start. -- Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Network Stack Code Re-write (Possible motivations...?)
Greetings List. If I am sending to the wrong list, then please let me know what would have been a more appropriate choice. I am attempting to research what is meant when, I saw that Juniper had re-written the network stack from the base freebsd network stack, to what is used in JUNOS. What exactly is meant by this? What is included in the network stack, when mentioned that it was completely re-written? I am a budding computer scientist, and would like to know where to start investigating how this would be done, and why they felt that the defacto network-centric OS for decades needed to be rewritten? Was this simply so they could rename the portions that they wrote as their own, in a business-savvy decision making process, or was it necessary from a technical standpoint? Any input would be appreciated, and if this question is too broad, then please point me in the right direction to make further inquiries. Thanks Respectfully, -- Martes G Wigglesworth mar...@mgwigglesworth.com M.G. Wigglesworth,LLC ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Network Stack Code Re-write (Possible motivations...?)
I am attempting to research what is meant when, I saw that Juniper had re-written the network stack from the base freebsd network stack, to what is used in JUNOS. What exactly is meant by this? What is included in the network stack, when mentioned that it was completely re-written? ask juniper what it means ;) anyway - in FreeBSD it's still original network stack not juniper one. I am a budding computer scientist, and would like to know where to start investigating how this would be done, and why they felt that the defacto network-centric OS for decades needed to be rewritten? because they wanted to ;) again - ask juniper about it. Probably because FreeBSD stack does not assume existence of any routing-dedicated hardware, while for sure in high end routers there are such things. maybe they do mixer software-hardware routing. anyway it seems strange i would rather use FreeBSD running computer as control plane for hardware router, that would fill routing tables in router's chips memory. Was this simply so they could rename the portions that they wrote as their own, in a business-savvy decision making process, or was it necessary from a technical standpoint? ones again - ask juniper! it's wrong place to ask why someone else wanted something else!!! FreeBSD is FREE, and - contrary to GNU communists licence, does not require to share any code derived from FreeBSD sources. There is nothing to prevent you to use FreeBSD code (except gnu parts) modified as you like, hidden or not as you like whereever you like. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Network Stack Code Re-write (Possible motivations...?)
Thank you very much for the intuitive commentary. Sorry for making the inquiry so specific to Juniper, however, I could not think of another source that would be a good example. I fully understand how the inquiries appeared, however, thanks for answering what you could. The inquiry was meant to be more general, so I apologize for making it seem Juniper specific. However, the intuitive list member response strikes again. Thanks alot for you input. I, as you, can't really figure out why they felt, years ago, that they needed to re-invent the wheel. Please give anymore insight if you have it. On Sat, 2008-12-20 at 11:32 -0500, Wojciech Puchar wrote: I am attempting to research what is meant when, I saw that Juniper had re-written the network stack from the base freebsd network stack, to what is used in JUNOS. What exactly is meant by this? What is included in the network stack, when mentioned that it was completely re-written? ask juniper what it means ;) anyway - in FreeBSD it's still original network stack not juniper one. I am a budding computer scientist, and would like to know where to start investigating how this would be done, and why they felt that the defacto network-centric OS for decades needed to be rewritten? because they wanted to ;) again - ask juniper about it. Probably because FreeBSD stack does not assume existence of any routing-dedicated hardware, while for sure in high end routers there are such things. maybe they do mixer software-hardware routing. anyway it seems strange i would rather use FreeBSD running computer as control plane for hardware router, that would fill routing tables in router's chips memory. Was this simply so they could rename the portions that they wrote as their own, in a business-savvy decision making process, or was it necessary from a technical standpoint? ones again - ask juniper! it's wrong place to ask why someone else wanted something else!!! FreeBSD is FREE, and - contrary to GNU communists licence, does not require to share any code derived from FreeBSD sources. There is nothing to prevent you to use FreeBSD code (except gnu parts) modified as you like, hidden or not as you like whereever you like. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Network Stack Code Re-write (Possible motivations...?)
Martes G Wigglesworth mar...@mgwigglesworth.com writes: I am attempting to research what is meant when, I saw that Juniper had re-written the network stack from the base freebsd network stack, to what is used in JUNOS. What exactly is meant by this? What is included in the network stack, when mentioned that it was completely re-written? I am a budding computer scientist, and would like to know where to start investigating how this would be done, and why they felt that the defacto network-centric OS for decades needed to be rewritten? Was this simply so they could rename the portions that they wrote as their own, in a business-savvy decision making process, or was it necessary from a technical standpoint? I work for a different router manufacturer, so I have little knowledge of Juniper internals, but I have had to worry about interoperability issues, so I've worked with Juniper gear for testing. Also, my general knowledge of similar issues on other routers is very likely to apply to the tradeoffs that Juniper made in choosing and developing its stack software. I very much doubt that marketing issues were a significant issue. Off-the-shelf OS networking has always fallen short of supporting high-end (or even, um, medium-end) hardware routing platforms. There is reason to hope that this is changing, but it has always been the case so far. As someone else already mentioned in this thread, supporting hardware offload for forwarding is a major issue. Core routers (or even provider-edge routers) depend on most of the packet forwarding being done in proprietary hardware. Operating system IP stacks don't support this very well; all of the routers I've worked on used the kernel IP stack only for packets going to and from the kernel itself, and used a different stack for what I call transit packets -- those that are only being forwarded by the local system. Another issue is router virtualization. Although FreeBSD has made some recent progress in supporting multiple IP instances, none of this capability was available when Juniper was deciding to base its operating system on FreeBSD. It is also important to note that having a rewritten IP stack doesn't mean that a system isn't using the original IP stack as well. A number of routers I've seen do this; they have thoroughly custom IP code for doing routing, but the local OS kernel in the router still uses the native stack for its own communications. I apologize if this message isn't clear; I was avoiding any information specific to the systems I currently work on, and I may have fuzzed things out a bit too much. Be well. -- Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Network Stack Code Re-write (Possible motivations...?)
Thank you very much for the intuitive commentary. Sorry for making the inquiry so specific to Juniper, however, I could not think of another source that would be a good example. I fully understand how the inquiries appeared, however, thanks for answering what you could. can't you simply ask some juniper employee? anyway - from where did you got that info about network stack being rewritten? I, as you, can't really figure out why they felt, years ago, that they needed to re-invent the wheel. once again - first ask WHAT EXACTLY FreeBSD is doing in their router? a) just preparing tables for router chips? - then FreeBSD's network stack is OK b) actually performing part of routing activity cooperating with ASIC's? if so - rewriting/modifying network stack was needed for sure. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Network Stack Code Re-write (Possible motivations...?)
I very much doubt that marketing issues were a significant issue. Off-the-shelf OS networking has always fallen short of supporting it wasn't made for that. As someone else already mentioned in this thread, supporting hardware offload for forwarding is a major issue. Core routers (or even provider-edge routers) depend on most of the packet forwarding being done in proprietary hardware. Operating system IP stacks don't support this very well; all of the routers I've worked on used the kernel IP stack only for packets going to and from the kernel itself, and used a different stack for what I call transit packets -- those that are only being forwarded by the local system. as higher speed routers are hardware - why OS has to do ANY work on routing? it's just there to prepare routing tables in format required for routing ASIC's and put them there! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Network Stack Code Re-write (Possible motivations...?)
Wojciech Puchar woj...@wojtek.tensor.gdynia.pl writes: I very much doubt that marketing issues were a significant issue. Off-the-shelf OS networking has always fallen short of supporting it wasn't made for that. It can be. I've written portable IP stacks intended for exactly this purpose. The routing tables are generally set up in userspace regardless, so it's not a big problem to send the same data to multiple stacks where each stack is supporting a different application. As someone else already mentioned in this thread, supporting hardware offload for forwarding is a major issue. Core routers (or even provider-edge routers) depend on most of the packet forwarding being done in proprietary hardware. Operating system IP stacks don't support this very well; all of the routers I've worked on used the kernel IP stack only for packets going to and from the kernel itself, and used a different stack for what I call transit packets -- those that are only being forwarded by the local system. as higher speed routers are hardware - why OS has to do ANY work on routing? it's just there to prepare routing tables in format required for routing ASIC's and put them there! Mostly, yes. But the system still has to be network manageable. That requires that it send and receive packets. Doing so requires using the same routing information that the forwarding engines are using to forward packets in the same address space. The kernel *does* still need to know routes to any of its destinations. Another possible implementation is, as you say, to have the kernel send everything out the same way and not know anything about the forwarding tables. This does, as the original poster said, imply that you're throwing out the capabilities of a stack that you built into your system from the ground up. -- Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Network Stack Code Re-write (Possible motivations...?)
I very much doubt that marketing issues were a significant issue. Off-the-shelf OS networking has always fallen short of supporting it wasn't made for that. It can be. I've written portable IP stacks intended for exactly this Of course it can. i just write that FreeBSD network stack WASN'T MADE for that. not if it can or not. routing ASIC's and put them there! Mostly, yes. But the system still has to be network manageable. That requires that it send and receive packets. Doing so requires using the same routing information that the forwarding engines are using to forward packets in the same address space. The kernel *does* still need to know routes to any of its destinations. but kernel doesn't forward much packets. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Network Stack Code Re-write (Possible motivations...?)
On Sat, 20 Dec 2008 13:35:35 -0500 Martes G Wigglesworth mar...@mgwigglesworth.com wrote: However, the intuitive list member response strikes again. Thanks alot for you input. I, as you, can't really figure out why they felt, years ago, that they needed to re-invent the wheel. Bear in mind that such companies may have a range of products, that range from something not unlike a pc with lots of interfaces up to something with multiple levels of embedded processors each running their own OSes. In the latter case you need a network stack that's largely OS independent, so it can spread itself across the (non-symmetric) processors. You may also need to be able to separate fast-path, slow-path and control path for high performance. Once you have done all that, you've left the native OS stacks unused, leaving them available for the user interface or in some cases communication between sub-systems. This separation is good on security grounds too, it's preferable not to have network management in-band. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Network Stack Code Re-write (Possible motivations...?)
A year, or two, ago, I found such information buried within the Juniper website; however, upon recent attempts at further investigation, both for learning about certifications, and subject matter for this topic, I am unable to locate said information. The historic Juniper blurbs were very informative. I am sure that the information is still available, however, I have not been successful in locating it. As for the suggested avenues of investigation, I have not had any coding or employment experience at that level of router development so I don't have the level of specific knowledge-base to make such an inquiry about said reference tables. I also do not have $10-$20K or more to purchase a Juniper router box, so there would not much real motivation to answer my inquiries if I were to be able to get into contact with a sales rep with enough knowledge of the system code to have information to give me. I am very much making an initial inquiry in attempting to get that level of experience, hence my inquiry to the list. I am simply trying to make my own inquiries about the general case, so as to gain knowledge of what routes to take to gain said coding/development experience via experimentation, etc... (Please excuse the pun.) Thanks for the input, though. On Sat, 2008-12-20 at 20:53 +0100, Wojciech Puchar wrote: Thank you very much for the intuitive commentary. Sorry for making the inquiry so specific to Juniper, however, I could not think of another source that would be a good example. I fully understand how the inquiries appeared, however, thanks for answering what you could. can't you simply ask some juniper employee? anyway - from where did you got that info about network stack being rewritten? I, as you, can't really figure out why they felt, years ago, that they needed to re-invent the wheel. once again - first ask WHAT EXACTLY FreeBSD is doing in their router? a) just preparing tables for router chips? - then FreeBSD's network stack is OK b) actually performing part of routing activity cooperating with ASIC's? if so - rewriting/modifying network stack was needed for sure. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Network Stack Code Re-write (Possible motivations...?)
Thanks again for further information on this topic. Where can I find more information this as a research topic. I am talking about Academic/PHD-level information or industry-level information. (I mean that I am looking at this from a knowledge-base expansion point of view, so don't filter out possible academic avenues because that is where I am mostly coming from in the first place.) Is this the realm where I would have to be one of those six-figure-income embedded programmers to really get my teeth into the subject, or what??? It is OK, you can be honest, hehehe... Thanks again for all the informative comments, list... On Sat, 2008-12-20 at 22:20 +, RW wrote: On Sat, 20 Dec 2008 13:35:35 -0500 Martes G Wigglesworth mar...@mgwigglesworth.com wrote: However, the intuitive list member response strikes again. Thanks alot for you input. I, as you, can't really figure out why they felt, years ago, that they needed to re-invent the wheel. Bear in mind that such companies may have a range of products, that range from something not unlike a pc with lots of interfaces up to something with multiple levels of embedded processors each running their own OSes. In the latter case you need a network stack that's largely OS independent, so it can spread itself across the (non-symmetric) processors. You may also need to be able to separate fast-path, slow-path and control path for high performance. Once you have done all that, you've left the native OS stacks unused, leaving them available for the user interface or in some cases communication between sub-systems. This separation is good on security grounds too, it's preferable not to have network management in-band. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Network Stack Code Re-write (Possible motivations...?)
Wojciech Puchar woj...@wojtek.tensor.gdynia.pl writes: I very much doubt that marketing issues were a significant issue. Off-the-shelf OS networking has always fallen short of supporting it wasn't made for that. It can be. I've written portable IP stacks intended for exactly this Of course it can. i just write that FreeBSD network stack WASN'T MADE for that. not if it can or not. I had deliberately worked around this topic because FreeBSD's routing table implementation has made considerable strides in virtualization lately (for which, as far as I know, the credit is almost entirely due to Julian Elischer), and this will probably turn out to make it more useful for commercial routers. So far, however, these changes are irrelevant to the historical question of Juniper's use of FreeBSD code. routing ASIC's and put them there! Mostly, yes. But the system still has to be network manageable. That requires that it send and receive packets. Doing so requires using the same routing information that the forwarding engines are using to forward packets in the same address space. The kernel *does* still need to know routes to any of its destinations. but kernel doesn't forward much packets. It may not not forward any, but your statement that all it does with IP is put data into ASICs is still generally incorrect. It generally does *send* and *receive* packets, and as such it needs routing information. It is possible to use a FreeBSD kernel without the IP stack (and this has been done on particularly deeply embedded processors). However, commercial routers generally do not use their OS kernel this way -- it is far more common that the kernel does send and receive packets within its native IP stack. That forwarding data is usually coordinated with the entity managing the routing data, although sometimes the management is done completely out-of-band, in which case the kernel's forwarding data need not have any connection with the data driven into the forwarding hardware. -- Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Network Stack Code Re-write (Possible motivations...?)
On Sat, 20 Dec 2008 17:54:24 -0500 Lowell Gilbert freebsd-questions-lo...@be-well.ilk.org wrote: However, commercial routers generally do not use their OS kernel this way -- it is far more common that the kernel does send and receive packets within its native IP stack. If I'm understanding you right, I'm surprised by that (the native part). It make any proprietary software less portable. You're also tying your code into third-party internals, which sounds like a maintenance problem. I would have thought that the likes of Cisco and Alcatel etc would would have reusable codebases that abstract the OS and minimize OS dependencies. What's the advantage, don't routers usually lead OS's in terms of new protocol support? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
