All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jay Vosburgh <fubar@us.ibm.com>
To: Gustavo Pimentel <gustavo.pimentel@efacec.com>
Cc: Veaceslav Falico <vfalico@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: Bonding
Date: Tue, 11 Feb 2014 09:55:35 -0800	[thread overview]
Message-ID: <27459.1392141335@death.nxdomain> (raw)
In-Reply-To: <8532C3BD1ECBC64BA47CE43AFED6D38EC37E5B04@S103.efacec.pt>

Gustavo Pimentel <gustavo.pimentel@efacec.com> wrote:

>Hi Veaceslav,
>
>It's quite different from broadcast mode, each frame sent through the slaves has attached a Redundancy Control Trailer also known as RCT (this trailer is compose by a LAN identifier, sequence number, a LSDU size and a PRP suffix).
>Also the equipment with PRP capability has to send periodically a supervision frame to both similar LANs. Each device on the network has to keep track of receive sequence numbers received, if the received a sequence number for instance from LAN A of specific device and it doesn't exist on internal table, the device should accept the frame and update the internal table. When receiving the same sequence number from the LAN B, the device should discard it, providing zero downtime redundancy.
>
>I can supply you information about this redundancy protocol, if you like. This type of network redundancy is now being large deployed on electrical power stations (like thermal and hydro) and transmission power stations instead of teaming / bonding that depends on RSTP for redundancy.

	Are you aware that there is already an implementation of HSR
(High-availability Seamless Redundancy) in the linux kernel?  I believe
HSR and PRP are defined by the same standard (IEC 62439-3), and are
similar enough to interoperate to some degree.  Perhaps PRP would be
better implemented as a variant within the existing net/hsr/ framework.

	-J


>> -----Original Message-----
>> From: Veaceslav Falico [mailto:vfalico@redhat.com]
>> Sent: terça-feira, 11 de Fevereiro de 2014 14:16
>> To: Gustavo Pimentel
>> Cc: netdev@vger.kernel.org
>> Subject: Re: Bonding
>> 
>> On Tue, Feb 11, 2014 at 01:53:32PM +0000, Gustavo Pimentel wrote:
>> >Hi,
>> 
>> Hi Gustavo,
>> 
>> >
>> >I'm writing you because because I'm have implemented a new mode (PRP Parallel
>> Redundancy Protocol) for bonding kernel driver. This new mode is quite simple, I
>> don't know if you have heard about PRP, but it's a new standard that allows to
>> overcome any single network failure without affecting the data transmission. The
>> general idea resides on having two separate LAN (A & B) very similar and
>> transmitting the almost the same frame through both LANs and the end device
>> should accept one frame and discard the other according to a known mechanism.
>> 
>> Isn't that the current 'broadcast' mode, where every packet is transmitted over all
>> the slaves? After quick googling/reading I don't see any difference there, though I
>> might have missed something.
>> 
>> >
>> >I have implemented this new mode on bonding driver, but I have some
>> difficulties:
>> >. Writing linux driver is quite new for me. I don't' know if exists guide lines for
>> driver coding.
>> 
>> You can find everything under Documentation/, but without the code I can't tell you
>> exact documents. CodingStyle and SubmittingPatches might be the first ones.
>> 
>> Also, try CC-ing relevant people for more feedback, specifically bonding
>> maintainers.
>> 
>> >. I don't know how to submit the code to be include on kernel repository.
>> >. Maybe another pair of eyes could find help to improve the writing code for this
>> mode.
>> 
>> Try sending an RFC when net-next opens.
>> 
>> >
>> >I think my driver code is 99% complete. I'm currently testing with 3 equipments (1
>> pc + 1 embedded device running both my modify bonding driver) and a third party
>> equipment called RedBox.
>> >
>> >Would you be interested in participating / helping this project?
>> >
>> >With my best regards,
>> >
>> >Gustavo Gama da Rocha Pimentel
>> >Power Systems Automation / Innovation & Development Efacec Engenharia e
>> >Sistemas, S.A.
>> >Phone: +351229403391
>> >Disclaimer

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

  reply	other threads:[~2014-02-11 17:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-11 13:53 Bonding Gustavo Pimentel
2014-02-11 14:15 ` Bonding Veaceslav Falico
2014-02-11 17:15   ` Bonding Gustavo Pimentel
2014-02-11 17:55     ` Jay Vosburgh [this message]
2014-02-11 18:22       ` Bonding Gustavo Pimentel
  -- strict thread matches above, loose matches on Subject: below --
2011-03-03  5:49 bonding David Miller
2011-03-03 11:45 ` bonding Neil Horman
2011-03-03 16:04   ` bonding Andy Gospodarek
2011-03-03 17:24     ` bonding Jay Vosburgh
2011-03-03 20:30       ` bonding David Miller
2011-03-03 20:43         ` bonding Jay Vosburgh
2011-03-03 21:12           ` bonding Andy Gospodarek
2011-03-03 21:29             ` bonding David Miller
2011-03-03 20:59       ` bonding Andy Gospodarek
2011-03-03 13:46 ` bonding Ben Hutchings
2011-03-03 16:31   ` bonding Stephen Hemminger
2011-03-03 16:52     ` bonding Eric Dumazet
2009-09-16  8:44 bonding David Miller
2009-09-16 15:02 ` bonding Jay Vosburgh
2000-11-29 21:24 Bonding Mike A. Harris
2000-11-30  9:16 ` Bonding Willy Tarreau
2000-11-30 20:45   ` Bonding Rainer Clasen
2000-12-01 17:42     ` Bonding Thomas Davis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=27459.1392141335@death.nxdomain \
    --to=fubar@us.ibm.com \
    --cc=gustavo.pimentel@efacec.com \
    --cc=netdev@vger.kernel.org \
    --cc=vfalico@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.