Hi Jonathan: I see what you're saying and you are certainly correct from that perspective.
You got me quite confused because there's that other mail to Zach when you associate mesh-under with a mesh header, and that definition is actually way closer to mine. A mesh is a radio topology and mesh-under is about routing at L2 on that topology. Note that proxy-ND is still ND, in other words it is a layer 3 operation, not a 'below IP' thing. Proxy-ND is a L3 tool that enables to merge the link local addressing spaces of 2 links into a single, larger one. And the backbone router is a real L3 gateway, that terminates a Layer 2 network to route packets onto another one. For the rest I see what you're saying and I'm certainly willing to modify HC3 to satisfy the routing over case you're talking about; I made a step in another thread; let's see how it goes: I'd wish to hear other opinions. Pascal >-----Original Message----- >From: Jonathan Hui [mailto:[EMAIL PROTECTED] >Sent: mercredi 5 mars 2008 17:26 >To: Pascal Thubert (pthubert) >Cc: 6lowpan; [EMAIL PROTECTED]; Jay Werb >Subject: Re: Mesh Under vs. ND proxy > > >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
