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

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Wed, 06 September 2017 06:16 UTC

Return-Path: <cjbc@it.uc3m.es>
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 E0A7C132358 for <detnet@ietfa.amsl.com>; Tue, 5 Sep 2017 23:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com
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 2XPMl2Gs63mW for <detnet@ietfa.amsl.com>; Tue, 5 Sep 2017 23:16:36 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9050D1241F3 for <detnet@ietf.org>; Tue, 5 Sep 2017 23:16:35 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id u26so26814291wma.0 for <detnet@ietf.org>; Tue, 05 Sep 2017 23:16:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=4DHz4sZ/O1+bP8/RHU3g2lpB7HPIZeZHN84AX11O23o=; b=07F4kUUPSI+lqbx9Ij/dWjBRG75dOw7uaM+PZT3J9sFmHdFxLjEBzWh1PCg303dqte dAooxpRuLdsqP5qqqitAf+G6sAzqs5cWkH/5TQBpp5KwoML4YkWEf7krll09lttMeumx n1ok30xT0uf2DeACxAJW9vNhkxXPtG2HnAeQOPB9ZCtj1NN9kk/l3qlTnIqLzGJk8cqA g2MdrEyUd8WOe2nt82r4QCY3SF44kBDtt0daClchoQv0Zd6vK0SOcb+7AAxYmLOMHFIK gz/71z9J0f98pCzWgMB2BWGqyz2tQ7LJWsePKgIGNA2svLfnEVb4oRR7GCCmivj3c86v YsqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:reply-to:to:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=4DHz4sZ/O1+bP8/RHU3g2lpB7HPIZeZHN84AX11O23o=; b=fphAlCjUR69Ro9gATXNIGp2vtZVFiiQ9q8FoLgUIXLhE/nFFUHMns+UU+dgUYumh0d H9N2thgXNyq/OOsF+bHI/6OO8qsUXw296Pcy8ejXNOtPjewCIu4k7lzrw7Rq9uO5Xm6Z XBhDOWnJ061stO6ACna1Tyy0WIf8OCbLDPNtyPH4fbPuQSBBH+0PpLi/J5zGbXTI+ZcW upFExj450xUpiN7N6TQH1XLRJ0OCpsN09DaDJAzdHWQigdZRnJfAzXcEG0FMQBasiX6E FmamD9f+gf398zssS2wlBDWQTioF6wUBg9ddAmkKgQZArdr5lYOwnF8JfQBmJMsIeu/l bwtQ==
X-Gm-Message-State: AHPjjUj3hv98TOsc6E9JfctwhxuWnQ3ODsPpxmmEgj4c0q6dB0AuNWgn NF/K9UjFBqdpOHtV+6Q=
X-Google-Smtp-Source: ADKCNb6xufLf9tJvQzrmgXdOYLgMIpQbwYoWigsyXk8pcCT1oKTEXMccFzGUvP2kHkmxOHe8o4MWQQ==
X-Received: by 10.80.176.225 with SMTP id j88mr5086396edd.95.1504678593868; Tue, 05 Sep 2017 23:16:33 -0700 (PDT)
Received: from acorde ([2001:720:410:1010:d681:d7ff:fe28:350b]) by smtp.gmail.com with ESMTPSA id e12sm956039edm.85.2017.09.05.23.16.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 05 Sep 2017 23:16:33 -0700 (PDT)
Message-ID: <1504678592.3471.1.camel@it.uc3m.es>
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
Reply-To: cjbc@it.uc3m.es
To: "Grossman, Ethan A." <eagros@dolby.com>, DetNet WG <detnet@ietf.org>
Date: Wed, 06 Sep 2017 08:16:32 +0200
In-Reply-To: <3cfcf1aa86bc42b99a1bc25abea5860d@DLB-XCHPW03.dolby.net>
References: <f58e48fbb58d4aca80dc53212361e793@DLB-XCHPW03.dolby.net> <1503836646.3473.9.camel@it.uc3m.es> <3cfcf1aa86bc42b99a1bc25abea5860d@DLB-XCHPW03.dolby.net>
Organization: Universidad Carlos III de Madrid
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.22.6-1
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/y_9lk_1Udpo5PoYMhaE_1pQGUJE>
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:16:39 -0000

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