Dear Alex, There are misunderstanding, so I would like to clarify them. Thanks.
> >> 2. route-over: basically, it should be the same as traditional IPv6 >> routing, except the gateway needs to work on >> compression/decompression of IP/UDP.. headers. > > I was not aware of that constraint. You seem to imply the 'route-over' > capability requires the use of Header Compression. I will have to check > the HC 6LoWPAN draft. > Oh, no. ROUTING mechanism WON"T require header compression/decompression. Routing will be included after IP/UDP, or where the routing protocol is designed in. I just gave you an example of 6lowpan network to communicate with non-6lowpan. Just what I want to say was you need decoding 6lowpan_header for the communication. It's not the routing role. >>> Will the 6LoWPAN router use longest-prefix match (as IP protocols >>> do) or exact-match (as some VLAN switch protocols do). >>> >> >> In route-over, every intermediate node which performs routing fucntions is >> called 6lowpan router. I didn't see a runing route-over >> solution for 6LoWPAN yet. In my opinion, it will use as IP protocols >> do. (I understand that's the concept of route-over. I think ROLL >> people may answer it more clearly) In mesh-under, generally, one IPv6 >> router exists in one 6lowpan. 6lowpan nodes in the lowpan will >> perform routing functions but not use IPv6 address. Whole 6lowpan is >> one IPv6 link, and the IPv6 router of 6lowpan will act as a normal >> IPv6 router to communicate with other IPv6 router outside of the >> 6lowpan, but the functionality for inside of 6lowpan routing would >> differ (not use IPv6 addresses). > > I wouldn't call the route-over 'routing' (or perform routing functions) > if it didn't use IP addresses. It's confusing. > Mesh-under doesn't use IP address. Route-over uses IP address. As I understand, Route-over for LoWPAN or LLNs is the same like other IP based routing. So far, mesh-under was widely-understood way to make a multi-hop connection in LoWPAN, and ROLL was born to make IP based routing for it. So it uses IP address for routing. >> [snip..] >>>>>> >>>>>> [R18] If the routing protocol functionality includes enabling >>>>>> IP multicast, then it may want to employ coordinator roles, >>>>>> if any, as relay points of group-targeting messages instead >>>>>> of using link-layer multicast (broadcast). >>>>> >>>>> link-layer multicast no broadcast. >>>> >>>> I don't know if 'link-layer multicast' is a proper term when >>>> 802.15.4 does not provide multicast. >>> >>> Maybe that's a requirement to put on 802.15.4 not on 6LoWPAN. >>> >>> I mean it would be difficult to revive the 'broadcast' concept back >>> into IPv6 documents, I suppose. >>> >> Yes, i also think that it's great if 802.15.4 supports link-layer >> multicast. As it does not, 6lowpan wants to avoid IP multicast which >> causes link broadcast as much as possible. I should think what else >> term can be used instead of broadcast if it is not acceptable >> termniology. > > Well, at IEEE 802 link-layer, broadcast means 'ff:ff:ff:ff:ff:ff' > address, whereas multicast means '33:33:0:0:0:X' address. Anything > different has too many meanings. > > I would actually appreciate a lot if this link-layer multicast > requirement went back to IEEE 802.15.4 instead of being addresses in an > IETF draft. It risks being specified for the sake of specifying it, but > implementations may simply go on and not use neither broadcast nor > multicast. > > Just some thoughts. > > Alex > 6lowpan is on 802.15.4, and IP multicast will go all nodes in the lowpan which is energy-expensive for lowpan nodes. Thus, i think such a restraint of all-nodes receiving packets is necessary to be considered when we design a solution for lowpan. And, in my opinion, this is well-agreed issue for 6lowpaners. (RFC 4944 also mentioned it) If we avoid to say broadcasting issue, can you help me to find how we contain such a requirement, based on IETF conventional way? :) Thank you much, -eunah _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
