Subject: Re: [Detnet] Gap Analysis for DetNet

From: "Shitanshu Shah (svshah)" <[email-masked]>
Date: Fri, 14 Nov 2014 08:52:25 +0000

Hi Pascal,

Very good summary! Please see inline ##svshah

> We found that we need to provide data models for:
>
> * the TSpec that describes the flow at the app/service layer
> * The state that must be installed in each Hop.
> * the path control information that is passed over the UNI interface
>
> This sort of object exist all over the place, usually without all the information that we require such as precise timing. > I’ m unclear which example we should be using for gap analysis and potential extensions. Ideas welcome!

##svshah, yeah, solution gap analysis is difficult until there is understanding on which approach. I wonder at this stage if we were to have further analysis then it would mean re-discussing/listing requirements which may also highlight similarities and differences between requirements from different use-cases.

For example (in the context of IP) -

Forwarding State (I am being careful and not calling it per flow or aggregate state)
—————————————————————————————————————

  *   6tisch is end to end IPv6 network and thus possibly a deterministic forwarding state in end to end IP nodes?
  *   AVB use-case has multiple L2 hopes connected with one or more L3 hops? And thus forwarding state in few middle hops assuming 802.1 standard has already a way to instantiate forwarding state in L2 hops?
  *   Other use case requirement?
  *   As you are highlighting Data model for the state to be installed (to be consistent

A Method for installing forwarding state
——————————————————

  *   It seems all the use-cases are open to guidance like controller methods you highlight above? Or is there any use-case that has to be limited to specific method?
  *   In case of 6tisch, controller to install forwarding state at L3
  *   In case of AVB, controller to install forwarding state for both L2 and L3? If so, L3 relevant model can be consistent for both the use-cases (again I am being careful not to call it per-flow state or aggregate state). Does L2 require different interface?

Any provisioning method
———————————

  *   Tspec to describe sender/receiver
  *   How to represent path to evaluate and how to represent path that gets pinned down

Please see further inline ##svshah below

>
> We also need to work on tagging in the packet for:
> * flow identification
> * time stamping
> * sequencing, for the purpose of replication and elimination
>
> For this, there is at least one proposal on the table, from Norm, of reusing MPLS tagging. We certainly need to work > with NVO3 and SFC to study the interaction and the orders of tags, between overlays, service chaining and DetNet.
>
> What do you think?

##svshah, I may be missing the purpose of overlay here. But I implicitly also notice that there is an inclination towards per flow state at each hop in the network.

I am really trying to understand what MUST requirement we boil down to for per-flow state requirement.. Let me describe in bit different angle what do I mean by that,

We have proven method with aggregate network state when it comes to rate guarantee. Taking standard voice/video applications, administrator of the network typically have good understanding of usage of the network and thus how much total bandwidth typically intermediate networking nodes would require to support scale of voice/video end-points. Networking nodes are provisioned with carefully defined aggregate bandwidth guarantee and end-points are admission controlled based on the networking capacity. With admission controlled flows (let’s keep elastic flows out of discussion for now), post admission control networking nodes do not need per-flow state or per-flow look-up given aggregate bandwidth pool has enough bandwidth for such traffic. Today this practice may be common between Edge and Core, typically separated via different administrative domains, but the concept can work well in general and thus same or different domains should not matter.

Coming back to Detnet use-cases, “controller” as listed with possible options below in your e-mail can already facilitate function of “admission control” as highlighted in the rate relevant example. Given good understanding of the application to be supported in the network, “controller” can build enough knowledge of starting point capacity to be provisioned in each networking nodes.  And admission control helps control end-points from over-running network capacity. Note that “controller” can also adapt to learning and can re-provision network capacity without affecting active deterministic flows.

Now, what described above does mean not supporting any arbitrary time scheduled slot services. But I can’t imagine how intserv either can support such. For example, if end-point “1" is interested in every 2nd slot of a specific networking node,  and if end-point “2” is interested in every 5th slot of a specific networking node. This arbitrary requirement can’t be supported. If request from “1” is already successful and active then request from “2” has to be denied, isn’t it? What that would mean is that deterministic requirement from end-points in one network would need to be in some fashion of harmony, isn’t it? And if indeed, they have to be in some sort of harmony, one should be able to provision appropriate aggregate deterministic parameters in the network.

Regards,
Shitanshu

From: "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 12, 2014 at 2:35 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Detnet] Gap Analysis for DetNet

My own 2 cents based on the DetNet BoF meeting:

We differentiated the need for:

1)      a blueprint of the big picture, at the level of the interaction models over a number of interfaces that we defined, and

2)      the model for the data that has to be exchanged or stored in the devices as part of the execution of the protocols.

I’m happy to say that we did not get a knee jerk like the IEEE is imposing its design on IETF or something like that.

OTOH, there were still reactions that we have to overcome.

1)      People did not necessarily figure that Norm and I were talking about the same problem.

2)      This may relate to some lack of common terminology, e.g. what’s a flow?

3)      Also, people were saying that (from arguably a broad perspective) all this has been done or is being done somewhere. Metro Ethernet Forum was mentioned and I’m unsure how much overlap we have there. And then work are PCE and CCAMP was discussed.

The final words (of wisdom) from the A-D is that we need a gap analysis.

Interaction model

In that gap analysis we need to differentiate work that needs to be done in a new WG (quiet clearly the blueprint and then some new data models) from what should be done in other WGs (typically extensions of existing protocols such as PCEP or stuff over foo).

The arch blueprint we seem to agree upon is based on a controller model and looks like this:

Interactions happen over a Northbound interface with the app/service layer, over a Southbound interface for the Network Interface, and over a UNI interface between the user NICs and the network elements.

Questions in the UNI interface:
* Whether we can live without one is one question
* The interaction is also TBD:
   - From the network to user NIC, it could be as simple as a periodic list of established paths, or we could add async info on state change, per-flow tick, etc…
   - The other way, it could be async readiness to receive on the Listener side.

Questions on the SB I/F:
* Interaction between the Sender or an operator and the PCE are certainly in scope.
* Interactions between applications will probably depend on applications and we should stay away from there.
* Finally, whether the Receiver side should interact with the PCE and what that interaction should be is in scope but left to be determined at this point.

Questions on the NB I/F
* Interaction between the network and the controller for the purpose of gathering capabilities, topology and metrics is required. Apparently there is work at MEF for a data model. Classical PCE gets information by passively listening to IS-IS or similar.
* Whether interaction between the Controller and the NIC is useful is TND
* From there we proposed 2 abstract approaches for the blueprint, and either we agree on one asap, or we need to provide a gap analysis for both:

“CCAMP” approach.

This is the case where the controller injects the flow information at one end point with some kind of source route path and associated state. A control packet flows to the other end of the path, provisioning on the way.

It was mentioned that the CCAMP WG is looking at (rechartering for?) work that would be useful to implement this approach.

“PCE” approach
-------------------
This is the case where the controller injects the flow information to all nodes on the way individually. It is unclear whether the controller needs also talk to the end point.

In this case, there is probably work that we can leverage from the PCE WG.

Data models

We found that we need to provide data models for:

* the TSpec that describes the flow at the app/service layer
* The state that must be installed in each Hop.
* the path control information that is passed over the UNI interface

This sort of object exist all over the place, usually without all the information that we require such as precise timing. I’ m unclear which example we should be using for gap analysis and potential extensions. Ideas welcome!

We also need to work on tagging in the packet for:
* flow identification
* time stamping
* sequencing, for the purpose of replication and elimination

For this, there is at least one proposal on the table, from Norm, of reusing MPLS tagging. We certainly need to work with NVO3 and SFC to study the interaction and the orders of tags, between overlays, service chaining and DetNet.

What do you think?

Pascal