Re: [Detnet] L2/L3 model?

On 11/17/14 11:23 AM, Pat Thaler wrote:
> Hi Erik,
>
> One of the L2/L3 use cases is in industrial networks.
>
> In a typical industrial use case, there would be:
> Dedicated control networks (i.e. the network for machine or a group of machines with an L2 network connecting the controllers, sensors and actuators connected to
> A supervisory control network (a L2 network or mixed L2 and L3 depending on the size of the plant)  by L3 forwarding devices connected to
> An Enterprise network (e.g. a data center - probably multiple L3 subnets with L2 forwarding within the subnets)
>
> The tightest timing requirements would be in the dedicated control networks, but time synchronization and some scheduled traffic would extend up the to the supervisory control network and perhaps the Enterprise network.
>
> You might look at slides 11 and 12 of this IEEE 802 tutorial for a couple of figures relevant to this use case.
> http://www.ieee802.org/802_tutorials/2013-07/Winkel_00_0713_DMLT_SG_Tutorial_v04.pdf
>
> The type of path in the arbitrary use case would fit here.

If the enterprise network and supervisory control network are both 
bridged LANs, then there might be a multi-hop L3 topology with L2 hops 
in between. However, the supervisory control network to the control 
networks might be a single L3 hop, in which case the topology would be a 
lot simpler.
>
> If one has an L3 PCE that sees the L3 topology, it would need an accurate view of the L2 cost (i.e. latency) of the L3 hops to choose a good path and an interface to something in L2 (perhaps the L2 PCE) to create a reservation for scheduled traffic through the L2 forwarders for an L3 hop.
To do a good job of allocating resources, I think the L3 PCE would also 
need to have an accurate (but abstract) view of what L2 resources are 
available between different attachment points to that L2 network. I 
think there are cases where a separate L3 and L2 PCE would do suboptimal 
allocation and at high load might need backtracking (L3 PCE might think 
L2 has resources between A and B, but when asking the L2 PCE it might 
turn out that the actual L2 topology doesn't have those resources.)

I don't know if there is a way one can have an architecture which can 
support different degrees of accuracy, and start working on the design 
of the simple cases (and later add support for more L2 visibility and 
optimality across L3+L2.)

Regards,
    Erik

> Regards,
> Pat
>
> -----Original Message-----
> From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Erik Nordmark
> Sent: Monday, November 17, 2014 10:11 AM
> To: detnet@ietf.org
> Subject: [Detnet] L2/L3 model?
>
>
> After the BoF I realized there was one thing we didn't talk about which
> is what combined L2 and L3 topologies that folks have in mind.
> It is true that from a packet forwarding perspective both L2 and L3 have
> queues and clocks, but the interaction with the control plane and the
> approach might be different for different forms of combinations.
>
> First of all we have 6TISCH which is an L3-only network.
>
> But in combined L2/L3 networks we could have at least
>    - interconnecting L2 islands using L3
>    - arbitrary topologies with mixtures of L2 and L3 forwarding devices
>
> A suggestion (at the mike during the BoF) was to consider pseudo-wires.
> That might make sense when interconnecting L2 islands.
> But with arbitrary topologies one could end with with a path that as a
> mixture of bridges and routers e.g.
>
>        Sender - B1 - B2 - R1 - B3 - B4 - B5 - R2 - R3 - Listener
>
> Are there use cases that result in such topologies/paths?
>
> Would one need one controller which is aware of both the L2 and L3
> devices and can pick paths (with resources) that include both?
> (Typically we separate the layers thus we might have a PCE which sees
> the L3 topology but not the L2 devices in between the routers.)
>
> I think it would be good to explore the combined L2/L3 use cases and
> models in more detail.
>
>      Erik
>
> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet
>