Subject: [homenet] IEEE 1905.1 and 1905.1a

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 26 Mar 2015 22:28:25 +0000

I mentioned a couple of weeks ago that IEEE 1905.1 might be something interesting to look at to see if it might be a useful component of a holistic homenet solution. It can do PHY and MAC layer topology discovery and PHY-layer metrics, for all Ethernet MAC-based PHYs (including Wi-Fi, HomePlug, G.hn, MoCA, HomePNA, Ethernet, etc.). Some feedback I got was that not being able to read the spec without paying for it made it a non-starter. Which I completely agree with. I was talking to Pat Thaler, who knows a lot about IEEE, asking if there was some way to get the specs to homenet. She said that if the homenet chairs sent a liaison to IEEE asking for it, explaining there was interest in possibly referencing it, that IEEE might send over a copy that could be made available to homenet participants via a password-protected means.

So if there is interest, I'd be happy to volunteer to help make such a liaison happen (work with chairs, liaison officer, and advocate on the IEEE side). I don't see any downside in asking for it.
Barbara

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 26 Mar 2015 23:44:41 +0100 (CET)

> So if there is interest, I'd be happy to volunteer to help make such a liaison happen (work with chairs, liaison officer, and advocate on the IEEE side). I don't see any downside in asking for it.

I am interested in this and would appreciate if it could be done.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Mar 2015 11:59:05 +1300

On 27/03/2015 11:44, Mikael Abrahamsson wrote:
>> I mentioned a couple of weeks ago that IEEE 1905.1 might be something interesting to look at to see if it might be a useful
>> component of a holistic homenet solution. It can do PHY and MAC layer topology discovery and PHY-layer metrics, for all
>> Ethernet MAC-based PHYs (including Wi-Fi, HomePlug, G.hn, MoCA, HomePNA, Ethernet, etc.). Some feedback I got was that not
>> being able to read the spec without paying for it made it a non-starter. Which I completely agree with. I was talking to Pat
>> Thaler, who knows a lot about IEEE, asking if there was some way to get the specs to homenet. She said that if the homenet
>> chairs sent a liaison to IEEE asking for it, explaining there was interest in possibly referencing it, that IEEE might send
>> over a copy that could be made available to homenet participants via a password-protected means.
>>
>> So if there is interest, I'd be happy to volunteer to help make such a liaison happen (work with chairs, liaison officer, and
>> advocate on the IEEE side). I don't see any downside in asking for it.
> 

+1, and there might be other WGs with a legitmate interest, so it
would be good if the agreement was flexible.

    Brian

---

From: Hans Liu <[email-masked]>
Date: Fri, 27 Mar 2015 08:32:42 +0800

+1

I'm quite interested in.   It has been pushing hard by a couple chipset
vendors. In my understanding there are already 1905.1 products (currently
Wi-Fi + HomePlug + Ethernet) in the market.

Best regards,
Hans

On Fri, Mar 27, 2015 at 6:28 AM, STARK, BARBARA H <[email-masked]> wrote:

> I mentioned a couple of weeks ago that IEEE 1905.1 might be something
> interesting to look at to see if it might be a useful component of a
> holistic homenet solution. It can do PHY and MAC layer topology discovery
> and PHY-layer metrics, for all Ethernet MAC-based PHYs (including Wi-Fi,
> HomePlug, G.hn, MoCA, HomePNA, Ethernet, etc.). Some feedback I got was
> that not being able to read the spec without paying for it made it a
> non-starter. Which I completely agree with. I was talking to Pat Thaler,
> who knows a lot about IEEE, asking if there was some way to get the specs
> to homenet. She said that if the homenet chairs sent a liaison to IEEE
> asking for it, explaining there was interest in possibly referencing it,
> that IEEE might send over a copy that could be made available to homenet
> participants via a password-protected means.
>
> So if there is interest, I'd be happy to volunteer to help make such a
> liaison happen (work with chairs, liaison officer, and advocate on the IEEE
> side). I don't see any downside in asking for it.
> Barbara
>
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

-- 
Instead of following the fashion, we lead it through.

---

From: Dave Taht <[email-masked]>
Date: Thu, 26 Mar 2015 20:35:27 -0700

up until this moment I had never heard of

http://en.wikipedia.org/wiki/IEEE_1905

this spec, and it does sound useful.

+10 on more open access to it. +100 on anyone working on open source code
for it.

I would certainly like closer relationships between the IEEE and IETF one
day, perhaps even a truly joint (as opposed to back to back) conference.
For far too long members of these two orgs have been going to different
parties, and many, many cross layer issues have arisen due to this.

In my own case I had hoped (in dropping ietf) to be able to attend more
IEEE 802.11 wg meetings - but I would really prefer to stay home and code
for a while.

I would be very supportive of someone(s) taking on the tasks of better
grokking wifi and other non-ethernet media across both orgs both in the
context of homenet and in aqm.

PS While I have a good grip on cable media layers, I am lacking such on
gpon...

---

From: Philippe Klein <[email-masked]>
Date: Fri, 27 Mar 2015 05:36:20 +0000

IEEE 1905.1 is a protocol that has been designed (I was one of the initial designer)for building a topology data base of the hybrid home network for diagnostic purpose (despite the initial claim in the PAR) and  not a  protocol for dynamic purpose (for example as it’s the message traffic was  intended to be low , the protocol did not took in account the traffic overhead and the multiplication of messages the protocol could create.

A stronger approach will be to consider combining the Layer 3 routing protocol with the L2 IEEE 802.1Qca which provide SPB on multiple paths (editor: [email-masked]<mailto:[email-masked]>). 802.1Qca will allow to optimize the bandwidth by allowing to use the *whole* topology of the home network in a loopfree manner (a simple RSTP might result in using only a subset of the topology).

Additionally 802.1Qca could use the *same* IS-IS database that the one used by the L3 protocol and an optional  distributed model in which one centralized computation path element CPE could remotely populate the (L2) forwarding table of CP (passive node that do not compute paths)  thru LSPs:  the same IS-IS protocol will benefit to both L3 and L2 and this is a big advantage adding any protocol on low end CE nodes that have limited resources is always a challenge and often a roadblock to successful acceptance and deployment.

802.1Qca is not agnostic to IS-IS and any protocol that could populate the topology database will be fine too.

There is a group of people that are active in both  IETF and IEEE 802 that are ready to discuss this approach to create a long needed coherent L3 & L2 stack.
Sincerely
/Philippe

Philippe Klein, PhD |Technical Director, Broadband Technology Group
Broadcom Corporation | Golan House, P.O.Box 273, Airport City, 70100 Israel
(M) +972 54 313 4500 | [email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>

From: homenet [mailto:[email-masked]] On Behalf Of Dave Taht
Sent: Friday, March 27, 2015 6:35 AM
To: Hans Liu
Cc: HOMENET Working Group; STARK, BARBARA H; Claire Cheng; [email-masked]
Subject: Re: [homenet] IEEE 1905.1 and 1905.1a

this spec, and it does sound useful.
+10 on more open access to it. +100 on anyone working on open source code for it.
I would certainly like closer relationships between the IEEE and IETF one day, perhaps even a truly joint (as opposed to back to back) conference. For far too long members of these two orgs have been going to different parties, and many, many cross layer issues have arisen due to this.
In my own case I had hoped (in dropping ietf) to be able to attend more IEEE 802.11 wg meetings - but I would really prefer to stay home and code for a while.

I would be very supportive of someone(s) taking on the tasks of better grokking wifi and other non-ethernet media across both orgs both in the context of homenet and in aqm.
PS While I have a good grip on cable media layers, I am lacking such on gpon...

---

From: Randy Turner <[email-masked]>
Date: Fri, 27 Mar 2015 01:21:36 -0500

Is there a typo or paste error below? The text reads :
"...and an optional distributed model in which a centralized...(snip)"

Is it centralized or distributed?

Randy

> On Mar 27, 2015, at 12:36 AM, Philippe Klein <[email-masked]> wrote:
> 
> A stronger approach will be to consider combining the Layer 3 routing protocol with the L2 IEEE 802.1Qca which provide SPB on multiple paths (editor: [email-masked]). 802.1Qca will allow to optimize the bandwidth by allowing to use the *whole* topology of the home network in a loopfree manner (a simple RSTP might result in using only a subset of the topology).
>  
> (M) +972 54 313 4500 | [email-masked]
>  
>  
>  
>  
>

---

From: Philippe Klein <[email-masked]>
Date: Fri, 27 Mar 2015 06:25:19 +0000

Sorry. Typo ☺. I meant a split model in which a  single CPE control multiple distributed CPs….
/Ph

From: Randy Turner [mailto:[email-masked]]
Sent: Friday, March 27, 2015 9:22 AM
To: Philippe Klein
Cc: Dave Taht; Hans Liu; HOMENET Working Group; STARK, BARBARA H; Claire Cheng; [email-masked]
Subject: Re: [homenet] IEEE 1905.1 and 1905.1a

Randy

On Mar 27, 2015, at 12:36 AM, Philippe Klein <[email-masked]<mailto:[email-masked]>> wrote:
IEEE 1905.1 is a protocol that has been designed (I was one of the initial designer)for building a topology data base of the hybrid home network for diagnostic purpose (despite the initial claim in the PAR) and  not a  protocol for dynamic purpose (for example as it’s the message traffic was  intended to be low , the protocol did not took in account the traffic overhead and the multiplication of messages the protocol could create.

From: homenet [mailto:[email-masked]] On Behalf Of Dave Taht
Sent: Friday, March 27, 2015 6:35 AM
To: Hans Liu
Cc: HOMENET Working Group; STARK, BARBARA H; Claire Cheng; [email-masked]<mailto:[email-masked]>
Subject: Re: [homenet] IEEE 1905.1 and 1905.1a

[email-masked]<mailto:[email-masked]>

---

From: Philippe Klein <[email-masked]>
Date: Fri, 27 Mar 2015 10:03:48 +0000

Allow me to elaborate.

The whole hybrid home network that include Ethernet, coax, power-line and in the near future bridgeable wireless  links (see the 802.11ak draft) could be modeled as a collection of Ethernet P2P wires and pseudo P2P wires interconnected by L2 bridges.

These bridges could be “dumb”  and controlled by a single control plane aware of the whole network topology using  (IETF defined) constraint-based path computation to  service L3 with L2 paths that comply with the constrains (BW, Delay,….) provided by the L3 protocols.

This architecture will allow the deployment of zero configuration interconnection nodes into the home that full cover the home thru hybrid multi hops.
A  Wi-Fi  “light” AP could for example be connected any underlying technologies that reach a given location in the home (such Ethernet then coax then PLC or bridgeable wireless link…)
/Ph

From: homenet [mailto:[email-masked]] On Behalf Of Philippe Klein
Sent: Friday, March 27, 2015 9:25 AM
To: Randy Turner
Cc: Hans Liu; Dave Taht; Claire Cheng; STARK, BARBARA H; HOMENET Working Group; [email-masked]
Subject: Re: [homenet] IEEE 1905.1 and 1905.1a

From: Randy Turner [mailto:[email-masked]]
Sent: Friday, March 27, 2015 9:22 AM
To: Philippe Klein
Cc: Dave Taht; Hans Liu; HOMENET Working Group; STARK, BARBARA H; Claire Cheng; [email-masked]<mailto:[email-masked]>
Subject: Re: [homenet] IEEE 1905.1 and 1905.1a

Randy

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 27 Mar 2015 13:01:44 +0100

> A stronger approach will be to consider combining the Layer 3 routing
> protocol with the L2 IEEE 802.1Qca which provide SPB on multiple paths
> (editor: [email-masked]).

Sorry if dumb question -- but since Qca appears to depend on SPB, could
you please clarify what is the relationship between SPB and TRILL?  What
happens in an unadministered network if you randomly mix STP, SPB and
TRILL?

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 27 Mar 2015 23:06:17 +0000

It does sound like there may be multiple IEEE solutions that might be considered as potentially helpful to homenet scenarios.

Just as information to those unfamiliar with IEEE:
1905 is an "entity" based IEEE group (i.e., companies are members, not individuals) that is very distinct from 802 (which, like IETF, is individual-based), and had little interaction with 802. 1905 set its own meeting schedule that had nothing to do with 802. We were fortunate to have Philippe participate in 1905, as someone who was also participating in 802. IEEE-SA (which IETF has a liaison officer for) oversees all the groups.

I think Philippe brings up some interesting points that we should be able to discuss more once people can see the specs.

A use case I wanted to explore is where homenet router 1 has an Ethernet port connected to an Ethernet to powerline adaptor; elsewhere in the home is a powerline to Wi-Fi brick (pure AP, no routing), and then homenet router 2 has a Wi-Fi to Ethernet adaptor plugged in to  its Ethernet port. The 2 routers each think they are using Ethernet to communicate with each other. If we consider algorithms like in Appendix A of RFC 6126 (babel), where it's suggested that different cost computations be used for wireless and wired, the routers 1 and 2  would use a "wired" cost computation, because they think they are using Ethernet. But since there's a wireless link between the 2 routers, maybe the wireless cost computation would be more appropriate. If only they knew.

In a homenet environment, if the xNCP and routing protocol messages are being received with regularity between routers 1 and 2, there is no reason to expect topology changes have occurred between routers 1 and 2. So a "dynamic" topology discovery mechanism may be overkill. A less chatty (more static) protocol may be sufficient. 

In any case, my main thinking is "if information from 1905 happens to exist in a homenet, it may be useful to describe how to make use of it". I think its main usefulness would be as info into various internal algorithms. Not as competition to xNCP or routing protocols. The main algorithms I think it could inform would be the routing protocol cost algorithm and potentially host application source address selection algorithms. But it's not necessary to any of this, and I definitely don't want to suggest a dependency on it. Just better algorithmic behavior with info than without.
Barbara

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 28 Mar 2015 14:57:04 +0100

> A use case I wanted to explore is where homenet router 1 has an Ethernet
> port connected to an Ethernet to powerline adaptor; elsewhere in the home
> is a powerline to Wi-Fi brick (pure AP, no routing), and then homenet
> router 2 has a Wi-Fi to Ethernet adaptor plugged in to its Ethernet
> port.
      eth         powerline         wifi          eth
 HR1 ----- switch +++++++++ switch ...... switch ----- HR2

> The 2 routers each think they are using Ethernet to communicate with
> each other. If we consider algorithms like in Appendix A of RFC 6126
> (babel), where it's suggested that different cost computations be used
> for wireless and wired, the routers 1 and 2 would use a "wired" cost
> computation,

Yes.  Babel would absolutely love to have a library that provides one bit
of information about each interface: "this is an Ethernet, don't bother
doing anything smart" or "be careful, this is something weird, disable
split horizon, perform link quality estimation, and assume worst-case
radio interference".

(Right now, we ask the kernel, and have a simple taxonomy of
wired/wireless/bridged.  We'll get it wrong if there's a switch in the
way, of course.)

Of course, we would be able to use more information than that -- the
slowest Phy rate on the link and the exact set of radio frequencies being
used come to mind --, but we'd be perfectly happy with just the one bit
described above.

-- Juliusz