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

[Jouni Korhonen <[e-mail]>]

Tomorrow 8-9 would be ok?


-- 
Jouni Korhonen, Broadcom, Core Switching Group
[phone]



> On Mar 29, 2017, at 9:33 AM, Jiangyuanlong <[e-mail]> wrote:
> 
> 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]> 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
> 
> _______________________________________________
> Detnet-dp-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt