> > Does it need to be a routing protocol? Just to throw another possible > > protocol into the mix being tossed around (like we don't have enough), > > I don't think current protocols used by ISPs or enterprises fits our plug&play > requirements. Also, there is a lot more wireless in homes. That doesn't mean > we cannot build on current protocols.
??? Huh? IEEE 1905.1 is being pushed by the likes of Broadcom, Qualcomm, MStar Semiconductor. They've suggested they want to have it in their Wi-Fi, MoCA, HomePlug, and Ethernet products, that are targeted at the CE industry. The certification is being offered by HomePlug Alliance. While Orange and AT&T have expressed an interest (because helping customers with their home networking issues is a huge customer care cost), I wouldn't call a "protocol used by ISPs". And enterprises?! I don't think so. Enterprises are definitely *not* the target audience. > > I'd like to suggest that a non-routing protocol be considered for topology > discovery and sharing of link metrics. Specifically, IEEE 1905.1a could help > with > this. It can provide L1 and L2 topology info with link metrics, and identify > intervening bridges that support LLDP for IEEE 802.1 bridge discovery. I > wouldn't want individual devices all doing their own 1905 topology discovery - > - that's too chatty. But if the all the homenet routers did, and then > advertised > a "service" (DNS-SD) that provided a link to a router-provider HTML page > with the topology and metric info the router can discover provided in a > standardized XML or JSON syntax, then everything who can discover that > service (on each router) would have access to this info. Applications could > also make use of this info to do intelligent source address selection in a > multi- > WAN-interface network, because routers could report on the speed of their > WAN connections, as well. > > My thoughts are as follows: sub-IP mechanisms provide usable metrics. > Somewhere, near to L3 routing, this information is translated to a > dimensionless cost metric for each link, where a link is a sub-IP path between > two routers. Cost is not symmetric, cost A->B can differ from B->A. It is the > routing protocol to distribute this information in the routing domain. I don't understand your point here, and whether you're trying to calculate the cost of running a L7 (application) protocol, or the relative cost of using different routes? Note that all protocols used to supply info to routing configuration applications are operating at the application layer (L7). HNCP is a L7 protocol. IEEE 1905.1 is a L7 protocol. As are IS-IS, and HTTP. The question is "what information does a router's routing configuration application need to properly configure routing behavior?" Once you figure out the info you need, then you can figure out the various options for getting that info to the router. It's not always necessary to multicast or broadcast all the information all over the place. Sometimes it's enough (and more efficient) to broadcast the existence (and where to get) the information, and then just let routers (or other devices) who want the info to go and ask for the info (unicast). If info changes, you can broadcast a message saying something changed, an d then let interested devices query to find out what the change was. You could even stick a "for more info" TLV in HNCP that supplies the URL of a router's info-providing web page. Barbara _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
