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

[Lou Berger <[e-mail]>]

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]> 
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]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>