Subject: [rbridge] Forwarding inside rbridge cloud

From: zinin at psg.com (Alex Zinin)
Date: Thu, 3 Mar 2005 15:43:59 -0800

Radia-

 draft-perlman-rbridge-02 says:

> 4. Handling non-IP packets
...
>    Therefore, the first RBridge (and only the Designated RBridge on the
>    source's link) encapsulates the packet with an encapsulation header. 
>    The specified next RBridge, R2, will look up the layer 2 destination 
>    in the inner header to determine the forwarding direction.  Then R2 
>    will replace the layer 2 source and destination addresses in the 
>    outer header with R2 as source and next Rbridge as destination, 
>    decrement the TTL, and forward the packet.  If R2 is the Designated

 Is hop-by-hop lookup on the original destination MAC inside the rbridge cloud
 essential? Would it be possible for the first rbridge to encapsulate the
 original frame setting the destination MAC address to the egress rbridge
 in the cloud, so that rbridges inside the cloud only had to maintain forwarding
 information about edge rbridges, rather than all end stations?

-- 
Alex
http://www.psg.com/~zinin

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Thu, 03 Mar 2005 16:06:37 -0800

The reason I think it's a good idea to do hop-by-hop forwarding (i.e., 
specify next
hop rather than destination RBridge) is that then there is no 
duplication of packets.
If all you specify is final RBridge, and you forward the packet onto a 
shared medium,
it is possible that multiple RBridges will think they should forward the 
packet.

Radia

---

From: zinin at psg.com (Alex Zinin)
Date: Thu, 3 Mar 2005 16:16:28 -0800

Radia,

  I must be confused about the number of headers a frame is wrapped around in
  then. The text talks about the original packet (which I assume is the original
  Ether frame, or is it the L3 packet?), the forwarding header, and the
  encapsulating header. How many headers is there when an original frame is put
  on a link inside the rbridge cloud?

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Thu, 03 Mar 2005 16:48:52 -0800

Alex Zinin wrote:

Radia,

************************
Let's say source S emits a packet onto the cloud for target node D (also 
on the cloud).
S and D are addresses on the cloud. RBridges want to forward the packet
in such a way that the RBridges are
invisible to D (D will assume that S is a direct neighbor).

So exactly the bits that S transmits will get delivered to D (other than 
the possible
functionality of RBridging dissimilar links to trick S and D on 
dissimilar links into thinking
they are neighbors, but let's not complicate things here.)

If there was an MPLS infrastructure inside the cloud between RBridges, 
with MPLS paths
set up between all pairs of RBridges, then the first RBridge could add 
an MPLS header
onto what S transmitted, which would be removed by the exit MPLS 
RBridge. Again,
D should not know that anything funny happened in between the time when S
transmitted the packet and D received it.

However, if the cloud consists of Ethernet links, and let's say that S 
and D are IP nodes,
then the original packet as transmitted by S will look like:

Ethernet header: source=S, destination=D, Ethertype=something
IP header: who knows, S and D might be IP routers and the source and 
destination might
be distant nodes
layer 4 headers, etc.: who knows

Let's call that "pkt". The RBridges don't change that at all.
What the RBridges would add while forwarding the packet is:

outer Ethernet header: source=transmitting RBridge, dest=next hop 
RBridge, Ethertype=NEW
encapsulation addiitonal field: TTL

So the packet will have one EXTRA Ethernet header, plus an extra byte 
for TTL.

Hope that answers the question.

Radia

---

From: zinin at psg.com (Alex Zinin)
Date: Thu, 3 Mar 2005 16:57:17 -0800

Radia,

...

> Let's call that "pkt". The RBridges don't change that at all.

Oh, can we call this "frame", and what's inside it "packet", please :)
This would make it much easier for me.

> encapsulation addiitonal field: TTL

OK. Got it now. I assumed there would be an "rbridge" header and the whole
package would be then be put in a link-local frame.

Thanks.

Alex

---

From: margaret at thingmagic.com (Margaret Wasserman)
Date: Fri, 4 Mar 2005 06:44:51 -0500

>package would be then be put in a link-local frame.

This more or less matches what Radia is saying, I think...  The 
rbridge header just happens to be very small.

You have a full Ethernet packet.  You add the rbridge header to the 
beginning (the TTL field), then you encapsulate the resulting packet 
(rbridge header + original packet) into an Ethernet frame.  The 
Ethertype is set to <TBD> (a new value that identifies this as an 
rbridge packet), and that indicates that the next header is an 
rbridge header.

One thing that I am not sure about, though, is that we can get away 
with such a short rbridge header.  At minimum, I would expect it to 
also include an ethertype for the original packet (IPv4, ARP, 
IPv6...).

Margaret

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Fri, 04 Mar 2005 10:36:33 -0800

The ethertype for the original frame is still in the original frame. The 
outer ethernet
header is *additional* information. Unlike something like IPsec's ESP or 
AH header,
which displaces the "protocol type"/"next header" field in
the IP header. Here we aren't displacing
anything.

Radia

Margaret Wasserman wrote:

> also include an ethertype for the original packet (IPv4, ARP, IPv6...).
>
> Margaret

---

From: margaret at thingmagic.com (Margaret Wasserman)
Date: Fri, 4 Mar 2005 14:12:03 -0500

Right.  Sorry...

So, the assumption is that the next header (after the rbridge 
'header") will always be an Ethernet header?  Wasn't there a desire 
to rbridge across IEEE and non-IEEE media?

Margaret

At 10:36 AM -0800 3/4/05, Radia Perlman wrote:
>The ethertype for the original frame is still in the original frame. 
>The outer ethernet
>header is *additional* information. Unlike something like IPsec's 
>ESP or AH header,
>>  One thing that I am not sure about, though, is that we can get 
>>away with such a short rbridge header.  At minimum, I would expect 
>>it to also include an ethertype for the original packet (IPv4, ARP, 
>>IPv6...).
>>
>>  Margaret

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Fri, 04 Mar 2005 11:22:29 -0800

The inside packet will be whatever the source transmitted. So if the source
is on Fiberchannel, or Infiniband, or IEEE, that's what it would look like.

An interesting issue is whether we should RBridge across dissimilar links,
to fool an Infiniband node into thinking it is neighbors with, say, an 
Ethernet node.

I'm sure it will be possible with some link types, and impossible with 
others.
I don't know enough about the various link types to know which ones 
would be hard.

Radia

Margaret Wasserman wrote:

> 'header") will always be an Ethernet header?  Wasn't there a desire to 
> rbridge across IEEE and non-IEEE media?
>
> Margaret
>
>> header is *additional* information. Unlike something like IPsec's ESP 
>> or AH header,

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 10 Mar 2005 19:39:07 -0800

The only thing not mentioned, IMO, is a VERSION field ;-)

As Radia (and others) point out, all the data that is duplicate can be 
ignored.

I'd hate to have to back-calculate that for half a byte.

Joe

Radia Perlman wrote:
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050310/e3bd5815/signature.bin