Re: [Detnet] DetNet Use Cases additions - Deadline 10Sep17

"Grossman, Ethan A." <eagros@dolby.com> Wed, 06 September 2017 06:19 UTC

Return-Path: <prvs=2422affaf5=eagros@dolby.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A135D126E7A for <detnet@ietfa.amsl.com>; Tue, 5 Sep 2017 23:19:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5U3hWQgGj32N for <detnet@ietfa.amsl.com>; Tue, 5 Sep 2017 23:19:42 -0700 (PDT)
Received: from mx0a-000fd501.pphosted.com (mx0b-000fd501.pphosted.com [67.231.152.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 999501241F3 for <detnet@ietf.org>; Tue, 5 Sep 2017 23:19:42 -0700 (PDT)
Received: from pps.filterd (m0000695.ppops.net [127.0.0.1]) by mx0b-000fd501.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v866IJhG026868; Tue, 5 Sep 2017 23:19:40 -0700
Received: from dlb-xchpw04.dolby.net (dcd-outbound.dolby.com [67.216.187.124]) by mx0b-000fd501.pphosted.com with ESMTP id 2ctbjwr0b5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 05 Sep 2017 23:19:40 -0700
Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW04.dolby.net (10.233.7.4) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 5 Sep 2017 23:19:38 -0700
Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1210.000; Tue, 5 Sep 2017 23:19:38 -0700
From: "Grossman, Ethan A." <eagros@dolby.com>
To: DetNet WG <detnet@ietf.org>, "cjbc@it.uc3m.es" <cjbc@it.uc3m.es>
Thread-Topic: [Detnet] DetNet Use Cases additions - Deadline 10Sep17
Thread-Index: AdMVRJPusQTOh1kOSRWyujOndyXvgwKJXiIAAc700gAAGx7pAP//ivnI
Date: Wed, 06 Sep 2017 06:19:38 +0000
Message-ID: <1504678773428.27411@dolby.com>
References: <f58e48fbb58d4aca80dc53212361e793@DLB-XCHPW03.dolby.net> <1503836646.3473.9.camel@it.uc3m.es> <3cfcf1aa86bc42b99a1bc25abea5860d@DLB-XCHPW03.dolby.net>, <1504678592.3471.1.camel@it.uc3m.es>
In-Reply-To: <1504678592.3471.1.camel@it.uc3m.es>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.233.7.60]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-06_02:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/rTqmZxEGKGEgt06SRKXGIY-o_7I>
Subject: Re: [Detnet] DetNet Use Cases additions - Deadline 10Sep17
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Sep 2017 06:19:45 -0000

Thanks Carlos. I will add the new text as stated, unless I hear otherwise from the list. 
Ethan.
________________________________________
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
Sent: Tuesday, September 5, 2017 11:16 PM
To: Grossman, Ethan A.; DetNet WG
Subject: Re: [Detnet] DetNet Use Cases additions - Deadline 10Sep17

Hi Ethan,

Sure. Here it is. The text was already discussed in the mailing list.

-·-8-<-·-
Please find below the changes that have
been discussed on the mailing list. I think the following represent the
consensus on the input to be added to the use cases document (we took
-11 version).

----
6.1.1.  Network Architecture

OLD:

Figure 10 illustrates a typical 3GPP-defined cellular network
architecture, which includes "Fronthaul" and "Midhaul" network
segments.  The "Fronthaul" is the network connecting base stations
(baseband processing units) to the remote radio heads (antennas).
The "Midhaul" is the network inter-connecting base stations (or small
cell sites).

NEW:

Figure 10 illustrates a typical 3GPP-defined cellular network
architecture, which includes "Fronthaul", "Midhaul" and "Backhaul"
network segments.  The "Fronthaul" is the network connecting base
stations (baseband processing units) to the remote radio heads
(antennas).  The "Midhaul" is the network inter-connecting base
stations (or small cell sites).  The "Backhaul" is the network or
links connecting the radio base station sites to the network
controller/gateway sites (i.e. the core of the 3GPP cellular
network).
----
6.1.3.  Time Synchronization Constraints

[...]

OLD:

In cellular networks from the LTE radio era onward, phase
synchronization is needed in addition to frequency synchronization
([TS36300], [TS23401]).

NEW:

In cellular networks from the LTE radio era onward, phase
synchronization is needed in addition to frequency synchronization
([TS36300],
[TS23401]).

Time constraints are also important due to its impact on packet loss.
If a packet is delivered too late, then the packet may be dropped by
the host.
----

----
6.1.4.  Transport Loss Constraints

[...]

OLD:

For packetized Fronthaul and Midhaul connections packet loss may be
caused by BER, congestion, or network failure scenarios.  Current
tools for elminating packet loss for Fronthaul and Midhaul networks
have serious challenges, for example retransmitting lost packets and/
or using forward error correction (FEC) to circumvent bit errors is
practically impossible due to the additional delay incurred.  Using
redundant streams for better guarantees for delivery is also
practically impossible in many cases due to high bandwidth
requirements of Fronthaul and Midhaul networks.  Protection switching
is also a candidate but current technologies for the path switch are
too slow to avoid reset of mobile interfaces.

NEW:

For packetized Fronthaul and Midhaul connections packet loss may be
caused by BER, congestion, or network failure scenarios.  Different
fronthaul functional splits are being considered by 3GPP, requiring
strict frame loss ratio (FLR) guarantees. As one example, lower layers
splits require FLR to be less than 10E-7 for data traffic and less than
10E-6 for C&M.  Current tools for eliminating packet loss for
Fronthaul and Midhaul networks have serious challenges, for example
retransmitting lost packets and/or using forward error correction
(FEC) to circumvent bit errors is practically impossible due to the
additional delay incurred.  Using redundant streams for better
guarantees for delivery is also practically impossible in many cases
due to high bandwidth requirements of Fronthaul and Midhaul networks.
Protection switching is also a candidate but current technologies for
the path switch are too slow to avoid reset of mobile interfaces.
----

----
6.3.  Cellular Radio Networks Future

[...]

OLD:

o  All form of xHaul networks will need some form of DetNet
   solutions.  For example with the advent of 5G some Backhaul
   traffic will also have DetNet requirements (e.g. traffic belonging
   to time-critical 5G applications).

NEW:

o  All form of xHaul networks will need some form of DetNet
   solutions.  For example with the advent of 5G some Backhaul
   traffic will also have DetNet requirements (e.g. traffic belonging
   to time-critical 5G applications).

o  Different splits of the functionality run on the base stations
   and the on-site units could co-exist on the same Fronthaul and
   Backhaul network.
----

----
6.4.  Cellular Radio Networks Asks

[...]

OLD:

A standard for data plane transport specification which is:

o  Unified among all xHauls (meaning that different flows with
   diverse DetNet requirements can coexist in the same network and
   traverse the same nodes without interfering with each other)

o  Deployed in a highly deterministic network environment

NEW:

A standard for data plane transport specification which is:

o  Unified among all xHauls (meaning that different flows with
   diverse DetNet requirements can coexist in the same network and
   traverse the same nodes without interfering with each other)

o  Deployed in a highly deterministic network environment

o  Capable of supporting multiple functional splits simultaneously,
   including existing Backhaul and CPRI Fronthaul and new modes as
   defined for example in 3GPP.

o  Slicing and Multi-tenancy-capable, supporting: isolating traffic
   (guaranteed QoS) and separating traffic (privacy).

o  Compatible with existing security and synchronization mechanisms,
   such as IEEE1588, IEEE802.1AS.

o  Capable of transporting both in-band and out-band control traffic
   (OAM info, ...).

o  Deployable over multiple data link technologies (e.g., IEEE 802.3,
   mmWave, etc.).
----

Thanks,

Carlos
-·-8-<-·-

On Wed, 2017-09-06 at 00:21 +0000, Grossman, Ethan A. wrote:
> Hello Carlos,
> If you would please resend the text to the list I would appreciate
> it. That will ensure that we are all looking at the latest version,
> and remind everyone on the list to please review it for technical
> correctness.
> Thanks,
> Ethan.
>
> -----Original Message-----
> From: Carlos Jesús Bernardos Cano [mailto:cjbc@it.uc3m.es] 
> Sent: Sunday, August 27, 2017 5:24 AM
> To: Grossman, Ethan A. <eagros@dolby.com>; DetNet WG <detnet@ietf.org
> >
> Subject: Re: [Detnet] DetNet Use Cases additions - Deadline 10Sep17
>
> Hi Ethan,
>
> We also provided text (discussed on the mailing list and agreed)
> regarding crosshaul for the cellular radio use case. I sent you an e-
> mail on April, 3rd. If you want I can resend it to you.
>
> Thanks!
>
> Carlos
>
> On Mon, 2017-08-14 at 21:31 +0000, Grossman, Ethan A. wrote:
> > Hi Folks,
> > The DetNet Use Cases draft 12 will expire in October, i.e. before
> > IETF
> > 100, so I plan to have an update before then. According to my
> > notes,
> > there are five items to address, which I enumerate below. If you
> > are
> > one of the people mentioned below, please reply to indicate your
> > current suggestion for new text for the draft.
> >
> > I expect such text to be in a form consistent with the existing
> > use
> > cases, however it could be plain text or a Word doc, i.e. it
> > doesn’t
> > have to be in XML.
> >
> > In several of the cases we have had some email exchanges regarding
> > text wording – it is possible that I already have the latest text,
> > but
> > I would like for you to send me what you understand to be the
> > latest,
> > to make sure we are in sync.
> >
> > Diego Duovne: Mining Industry use case.
> > Maik Seewald: “Comments on section: 3.1.1.2 Intra-Substation
> > Process
> > Bus Communications” and “for IEC 61850 installations only part 9-3
> > applies:”
> > Hassan Halabian: 5G Packet Fronthaul
> > Daniel Huang: Blockchain use case
> > Xavier Vilajosana: Wind Farm use case
> >
> > If anyone else has any suggestions or comments, or if I somehow
> > lost
> > track of your request and didn’t list it below, please reply.
> >
> > Please send your replies for each of these potential additions by
> > September 10, 2017 so that I have time to review and integrate.
> >
> > Thanks,
> > Ethan.
> >
> >  _______________________________________________
> > detnet mailing list
> > detnet@ietf.org
> > https://www.ietf.org/mailman/listinfo/detnet