Hi Pascal, I think our definition of 'mesh-under' is conflicting. What I mean by 'mesh-under' is that forwarding occurs below IP, that is, the Hop Limit does not get decremented by intermediate forwarding nodes. 'Route-over' on the other hand is simply IP routing - nodes forwarding datagrams also decrement the Hop Limit. As you state, the goal of BbR is to abstract one or more PANs to appear as a single IP link, possibly with the support of other link technologies.
Given this definition of 'mesh-under', would you agree that BbR is supporting mesh-under? -- Jonathan Hui Pascal Thubert (pthubert) wrote: > Hi Jonathan: > > The Backbone Router (BbR) draft makes no assumption that I am aware of > on whether there is or not more than one radio hop over a LoWPAN; both > cases are supported. Now I think it's fair to make a distinction between > radio hops over the LowPAN and hops over the backbone: > > - First, the backbone is not supposed to be of the same technology as > the LoWPAN. A backbone router is thus expected to expand the 6LoWPAN > compressed packets and reassemble the fragments. The backbone can a > simple ethernet cable, but it might as well be a mesh of tunnels over a > WAN. The packet might be delivered to an IPv6 node sitting on the > backbone, or be forwarded across a destination LoWPAN via another > backbone router. Because the destination LoWPAN might be different in > nature from the source LoWPAN, uncompressed IP is the esperanto over the > backbone. > > - Second, the routing protocol is somewhat different. The backbone > router uses proxy ND techniques to represent its field devices over the > link abstraction that is the backbone and make routing decision to > forward over the LoWPAN vs. over the backbone; and the types of routing > that sustains the backbone itself can be virtually anything from > spanning tree to BGP. > > The goal for this draft is to federate multiple small LoWPANs into one > larger IPv6 link over a backbone of any sort that is also part of the > link. The single link requirement matches the current applications that > I know of and enables a field device to move from one BrB to another one > on the same link while retaining transparently its address and active > connections. > > The backbone router is the router that enables that LoWPAN > interconnection, and proxy ND is the technique that is proposed to > achieve the goal above. Other techniques such as NETLMM/proxy MIP were > discussed but seemed overkill for the desired result and the constraints > of the LoWPAN. > > Pascal > >> -----Original Message----- >> From: Jonathan Hui [mailto:[EMAIL PROTECTED] >> Sent: mercredi 5 mars 2008 08:59 >> To: Pascal Thubert (pthubert) >> Cc: 6lowpan; [EMAIL PROTECTED]; Jay Werb >> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >> >> >> In your draft, you claim that 6LoWPAN nodes address each other and the >> backbone router using link-local addresses. If that occurs over > multiple >> radio hops, that sounds like mesh under to me... In other words, you > are >> assuming that an entire PAN functions as a single IP link (the IPv6 >> definition of a link). Am I missing something here? >> >> -- >> Jonathan Hui >> >> >> Pascal Thubert (pthubert) wrote: >>> Hi Jonathan: >>> >>> You are assuming explicitly that I am assuming implicitly... mesh >>> under... Hum. >>> >>> Please have a look at >>> > http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router >>> -00.txt and it should be apparent that I'm not. In particular the >>> backbone router is the device that will set and use the hop limit > bit. >>> So will all those interconnecting devices used in pseudowire, split >>> bridges, IP Mobility, etc... if they are deployed in this space. >>> >>> What I'm really assuming is a gateway or an edge server on the link. >>> It's there in most architectures that I know of at this point that's > why >>> I included it in the case we shoot for and saved 2 bits. Note that > when >>> the ULA and global addresses are used on top of link local, it makes >>> sense that we define a mechanism to compress them as well. But this > is >>> not what HC3 is about. >>> >>> The goal of my initial proposal is illustrative, to foster this very >>> discussion around the idea that we can shoot for a favorite case and >>> make an HC3 out of HC1 and HC2 for that case. Now, if we as a group >>> think that the GW assumption is not reasonable, then, fine, let us >>> affect 2 bits in HC3 to indicate whether the addresses are > compressed. >>> What do the others think? >>> >>> Pascal >>>> -----Original Message----- >>>> From: Jonathan Hui [mailto:[EMAIL PROTECTED] >>>> Sent: mardi 4 mars 2008 18:05 >>>> To: Pascal Thubert (pthubert) >>>> Cc: 6lowpan; [EMAIL PROTECTED]; Jay Werb >>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>> >>>> >>>> Hi Pascal, >>>> >>>> Thanks for sharing your thoughts. >>>> >>>> By assuming the first 5 bits in HC1 are '1', you're staking a claim >>> that >>>> mesh-under link-local communication within a PAN is going to be most >>>> common case and the one we've "shot for". If link-local is all we > focus >>>> on, then we are missing the point of IP. Frankly, I don't see much >>>> benefit of IP if communication is limited to the PAN. >>>> >>>> W.r.t mesh-under, there are efforts within the IETF that assume > 6LoWPAN >>>> nodes will communicate via route-over using routable addresses (e.g. >>>> ROLL). This brings us back to a broader topic of route-under vs. >>>> mesh-under. While both will probably exist for some time, it raises > the >>>> question of whether 6LoWPAN implementations can support one or do > they >>>> have to support both. >>>> >>>> W.r.t compressing Hop Limit, I don't quite understand why you're > using >>> a >>>> bit in HC3 to indicate where the message originated. If you're > assuming >>>> link-local communication, then messages shouldn't be forwarded > across >>>> links anyway. >>>> >>>> I do agree that there is work to do on compression and agree that > there >>>> are cases where HC1 and HC2 are not sufficient. This is why I've > been >>>> working, albeit slowly, on HC1g. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>>> Pascal Thubert (pthubert) wrote: >>>>> Dear 6LoWPANers, >>>>> >>>>> Though HC1 and HC2 provide us with the capability to express any >>>>> combination of compression, the most expected (or at least shot > for) >>>>> case does not lead to a better compression of the HC headers >>> themselves. >>>>> Seems that we could define an HC3 that would compress the pair of > HC1 >>>>> and HC2 for that best case. My proposal for doing this would be to: >>>>> >>>>> - define a new dispatch >>>>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and >>>>> transport >>>>> >>>>> - define HC3 itself to: >>>>> >>>>> - implicitly say that the first 5 bits of HC1 are all ones >>>>> - carry HC1 bits 5 and 6 (Next Header) >>>>> - replace HC2 so bit 7 of HC1 is useless >>>>> - provide transport specific bits such as those defined for >>>>> HC-UDP, >>>>> then again assuming a predefined best case if room is > missing >>>>> An example of what the HC3 octet could be: >>>>> >>>>> bits 0 1 2-3 >>>>> 4-7 >>>>> >>>>> > +------------------+-------------+-----------------+-------------------- >>>>> ---------------------+ >>>>> | reserved | reserved | Next Header | >>> transport >>>>> specific control bits | >>>>> >>>>> > +------------------+-------------+-----------------+-------------------- >>>>> ---------------------+ >>>>> >>>>> Next header: as defined in HC1, bits 5 and 6 >>>>> >>>>> transport specific control bits for UDP: >>>>> bit 4 echoes HC-UDP bit 0 on UDP source port >>>>> bit 5 echoes HC-UDP bit 1 on UDP destination port >>>>> bit 6 echoes HC-UDP bit 2 on UDP length >>>>> bit 7 is reserved >>>>> >>>>> What do you think? >>>>> >>>>> Pascal >>>>> _______________________________________________ >>>>> 6lowpan mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
