Re: [Detnet-dp-dt] Flow-ID vs. scalability (further thoughts to dinner discussion)

[Jiangyuanlong <[e-mail]>]

I am available for both time slots.
Cheers,
Yuanlong

From: Detnet-dp-dt [mailto:[e-mail]] On Behalf Of Lou Berger
Sent: Thursday, March 30, 2017 12:20 AM
To: Balázs Varga A; [e-mail]
Subject: Re: [Detnet-dp-dt] Flow-ID vs. scalability (further thoughts to dinner discussion)


Great idea.  I can get a room assigned. How about 2pm today or first thing tomorrow -8 or 9?

Lou

On March 29, 2017 10:43:32 AM Balázs Varga A <[e-mail]<mailto:[e-mail]>> wrote:
Hi All,
I have some thoughts below regarding the Flow-ID discussion at yesterday dinner.
Could we gain that we are at the same location and have a side meeting
today (afternoon or evening) or tomorrow (afternoon)?
Cheers
Bala’zs

My interpretation on the Flow-ID and its scalability. Please comment.
Let’s list the end-systems together with their used encapsulation.
Starting with how it works with a TSN host and a TSN domain:
- TSN (L2) host: host is not IP aware, flow is directly encapsulated in Ethernet.
A StreamID is used constructed by “src-MAC + UniqueID” as per IEEE:
“The StreamID includes the following subcomponents:
- A 48-bit MAC Address associated with the Talker sourcing the
stream to the bridged network.
- A 16-bit unsigned integer value, Unique ID, used to distinguish
among multiple streams sourced by the same Talker.”
The UniqeID is not traveling with the Ethernet frame, but the multicast dst-MAC
can be used to find out the UniqueID. So the uniqueness of StreamID achieved,
it includes the source identification and scales well.

We can do something similarly for IP hosts and a DetNet domain:
- DetNet aware IP host: flow is encapsulated in “PW over IP”. Seq.num and
Flow-ID added by the host. So if we would like to have an analogy with TSN, the
flow can be unambiguously identified by the “src-IP + Flow-ID”. That would scale
and is similar to TSN.

However the difference is that in case of TSN we have just a single forwarding
paradigm: Ethernet bridging. The src-MAC and dst-MAC are visible for all
intermediate bridges, so the flow can be identified without any difficulties.

In the “dp-sol-draft” we have defined the Flow-ID somewhat different to avoid
DPI (i.e., checking src/dst MAC/IP addresses) during transport to recognize the flows.
The Flow-ID is placed in the PW encapsulation header, so easy to find it and use it
whatever DetNet domain (IP or MPLS) you are crossing.

In case of DetNet we have two forwarding paradigm: (i) IP routing and (ii) MPLS
switching. Therefore checking the “src-IP + Flow-ID” is somewhat more complicated
for intermediate nodes. For example, in case of MPLS the “src-IP” is in the
encapsulation payload, so we need DPI.
Furthermore if we interconnect TSN End-systems over DetNet there is no “src-IP”.
So we have solved the difficulties with “src-IP” by defining the “Flow-ID” as to be
unique with all the concerns regarding scalability.

So what could be a better approach if we intend to solve scalability. We need two IDs.
(1) one identifying the source of the flow and (2) an other one to distinguish multiple
flows sent by the same source. For the second one we already have the Flow-ID.
What could be selected for the first one?
- src-MAC: not visible in many cases (e.g., source behind a routed domain, etc.)
- src-IP: may not present (e.g., in case of TSN host)
- PW-label: it is always present.
- new field: to be defined in the encapsulation
Making the PW-label source specific and constant during transport sounds similar as
segment routing, however here we have to allocate label space for hosts and not
per network nodes. So it may hurt scalability again.

What about the new field? And we do not have to define a pretty new one just
extend and add structure to the already defined “DetNet flow identity word”.
- 16 bit Flow-ID: distinguish flows per source (same size as for TSN ! )
- 46 bit Src-ID: distinguish the source
- 1 bit: direction bit
- 1 bit: reserved
So we are adding 64 bit instead of 32 in order to ensure scalability …
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |r|D|                           46 bit src identity             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      src identity cont.       |     16 bit flow identity      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In the src-ID you can map a unique ID for sources. Some possible examples:
- L2 host: src-MAC without BC-bit and Local-administration-bit (48-2=46 bits)
- L3 (IPv4) host: src-IP address + zeros to fill up the field
- L3 (IPv6) host: IPv6 host have 128 bit src-IP, so we may need a preconfigured
ID for the IPv6 host used for DetNet purposes.

Thanks if You have read so far …

Note: For the scenario with DetNet unaware IP host(s): host sends flow needing
DetNet treatment. First DA-T-PE has to create the PW encapsulation (adding
seq.num and Flow-ID). It is a task of the DA-T-PE to create the field values as
specified above.


_______________________________________________
Detnet-dp-dt mailing list
[e-mail]<mailto:Detnet-dp-dt%40ietf.org>
https://www.ietf.org/mailman/listinfo/detnet-dp-dt