Re: [Detnet] Crosshaul input for consideration in draft-ietf-detnet-use-cases

Balázs Varga A <balazs.a.varga@ericsson.com> Fri, 10 March 2017 08:18 UTC

Return-Path: <balazs.a.varga@ericsson.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 84697129405 for <detnet@ietfa.amsl.com>; Fri, 10 Mar 2017 00:18:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 4XkinXWA7jqO for <detnet@ietfa.amsl.com>; Fri, 10 Mar 2017 00:18:52 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 D81501293D9 for <detnet@ietf.org>; Fri, 10 Mar 2017 00:18:51 -0800 (PST)
X-AuditID: c1b4fb25-a57ff70000004cad-f8-58c26167558e
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id B1.5C.19629.76162C85; Fri, 10 Mar 2017 09:18:50 +0100 (CET)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.48) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 10 Mar 2017 09:18:46 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1yncscazQSs71JgMG80c4FxTZyatOMUm4w7xWYDS5b4=; b=Hz6i5PBUw8ry9ezY+Ls15azsoTXAb+XT3SpJN/p5abRht8VYelFWM68mPco7zKXckLhaYAMnzLgXGF5FXmhf/1WN7ZruWwuRZuF5Zqyj+Gd/MVCAw7zsJ9KOF4y3E2szAtOfEzLGrnNf9/ajV1vuzAVKPsY+blF4yCfyaI55bsE=
Received: from DBXPR07MB128.eurprd07.prod.outlook.com (10.242.138.156) by DBXPR07MB127.eurprd07.prod.outlook.com (10.242.138.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Fri, 10 Mar 2017 08:18:45 +0000
Received: from DBXPR07MB128.eurprd07.prod.outlook.com ([169.254.3.89]) by DBXPR07MB128.eurprd07.prod.outlook.com ([169.254.3.89]) with mapi id 15.01.0947.022; Fri, 10 Mar 2017 08:18:45 +0000
From: Balázs Varga A <balazs.a.varga@ericsson.com>
To: "cjbc@it.uc3m.es" <cjbc@it.uc3m.es>, "detnet@ietf.org" <detnet@ietf.org>
Thread-Topic: Crosshaul input for consideration in draft-ietf-detnet-use-cases
Thread-Index: AQHSmUiyTcmsrSIoPk64yyRd7I7rzqGNslGw
Date: Fri, 10 Mar 2017 08:18:44 +0000
Message-ID: <DBXPR07MB1284151BAFCE57D0670290DAC200@DBXPR07MB128.eurprd07.prod.outlook.com>
References: <1489108912.5107.27.camel@it.uc3m.es>
In-Reply-To: <1489108912.5107.27.camel@it.uc3m.es>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: it.uc3m.es; dkim=none (message not signed) header.d=none;it.uc3m.es; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [91.82.100.59]
x-microsoft-exchange-diagnostics: 1; DBXPR07MB127; 7:ZFsEdvIgRlWjQ5tPrHq+06SewJzuc81F420lW2nVzPIW6Ed6Jakn1aPX/Aup/cN530oQVEeV6/azJ2BYaAWLuMWM93vAU+DDQVt+EH9QufA+Pl9HXHi+Hnz/Oq2I0BWgc3Iwri9SXf2ziQ3ypLjxKVL9CwdCn0i1SycnPfQfHASI4UMT6FaSPKKMYnFPteD1ywln27Gj1rGQQyGsdQu/49UVF6ZRKg8wHWYwBbppj4nPL6K0kXfhVSKwme+HIHt3aI7Q0yr1Cdgu98/iWtInGs1AQmVEiclVBzlfbCbZC7RTK+Y3SW3gHjQgZFPUhVGRiqTTfKPsTj3QxMF9nyUtCA==
x-ms-office365-filtering-correlation-id: 209ef376-c0ef-4715-38bb-08d4678e11ff
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DBXPR07MB127;
x-microsoft-antispam-prvs: <DBXPR07MB1273E33BF9719000F74EE44AC200@DBXPR07MB127.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(131327999870524)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:DBXPR07MB127; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB127;
x-forefront-prvs: 02426D11FE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(13464003)(377454003)(102836003)(3846002)(790700001)(6116002)(54356999)(6306002)(6506006)(2501003)(54896002)(99286003)(50986999)(9326002)(55016002)(2900100001)(9686003)(76176999)(8676002)(25786008)(4326008)(33656002)(8936002)(85182001)(81166006)(189998001)(230783001)(6436002)(74316002)(7736002)(106116001)(85202003)(53936002)(5660300001)(53546006)(3660700001)(38730400002)(2906002)(86362001)(3280700002)(122556002)(7696004)(2950100002)(66066001)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB127; H:DBXPR07MB128.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DBXPR07MB1284151BAFCE57D0670290DAC200DBXPR07MB128eurprd_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2017 08:18:44.8698 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB127
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRmVeSWpSXmKPExsUyM2K7gW5W4qEIgwuhFq07NjFZ/P40m8Xi xM+tjA7MHkuW/GTy+HZ9I6vHl8uf2QKYo7hsUlJzMstSi/TtErgyttw/zlRwoImp4v+v5YwN jHd+M3YxcnJICJhIrP30j6WLkYtDSGAdo0T/5H5mCOcEo8Th2V8ZQRwWgV5mia0911khMlOZ JK7PfQbVc4hR4vmspUwgw9gEXCR2bJrDCmKLCPhI/Fz8EGwJs0C8xOQTXWA1wgK+Et9fvYGq 8ZPo7t7ABmEbSdxuWANWzyKgKnF0Ris7iM0rECXx+PMpZhBbSMBQYvqDs2A2J1B9z2+I+YwC YhLfT61hgtglLnHryXwmiOcEJJbsOc8MYYtKvHz8D+wDRoF+Rom1HcdYIRIKEpsWvGcHSUgI dDNL/PjfC5TgAHJ8Ja7d9oGo8ZFYcuwhNMQyJabs+Q7VmyvR8OcfVO8MJonJd75C9cpITH4Q AxFvYpV4cPcdM8T3UhJ3r3QyQtgyEi/u7GWdwKgxC8nhEHa+xM/1vxhngQNAUOLkzCcss4DG MgtoSqzfpQ9RoigxpfshO4StIdE6Zy47svgCRvZVjKLFqcVJuelGxnqpRZnJxcX5eXp5qSWb GIFp6eCW36o7GC+/cTzEKMDBqMTD+yH3YIQQa2JZcWUuMEo5mJVEeEv1DkUI8aYkVlalFuXH F5XmpBYfYpTmYFES5zVbeT9cSCA9sSQ1OzW1ILUIJsvEwSnVwJjE5Kfa6drSc/9v/dndG5+2 eJuFfVTlbi/PWDDnqIfTRfNn6/fPCN6t4aUsuzU7WX3OB0mNVybBhQH+9Y+2Ldq9/Y5RZe7i DBfnKTlijS/tC2US3Hrs0lbe/vW6+uYq78aOPTP7ZqypZskSPreoL1D7dFFyS9r+VVmf1gne tVGYxXywdeatO0osxRmJhlrMRcWJAKh7nzZHAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/1IgmSMkxE1sM2uYA4IwKHutszlQ>
Cc: "draft-ietf-detnet-use-cases@tools.ietf.org" <draft-ietf-detnet-use-cases@tools.ietf.org>
Subject: Re: [Detnet] Crosshaul input for consideration in draft-ietf-detnet-use-cases
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 10 Mar 2017 08:18:54 -0000

Hi Carlos,



Some comments and a question for clarification:



6.1.4.  Transport Loss Constraints

> Some fronthaul functional splits considered by 3GPP require the frame loss ratio (FLR)

> to be less than 10E-7 for data traffic and less than 10E-6 for C&M.

Functional split is still under heavy discussion in 3GPP. These numbers are not defined by 3GPP

and may be dependent on discussion results. So I think including them in the use-case draft

may causes confusions.



6.3.  Cellular Radio Networks Future

> o  Different splits of the functionality run on the base stations

>    (baseband processing units) and the remote radio heads (antennae)

>    could co-exist on the same Fronthaul and Backhaul network.

I see a terminology issue here mainly due to the fact that future splits and the resulting

network elements are not (yet) defined. Baseband processing units and antenna refers

to legacy technologies, which does not require DetNet and are out-of-scope.



6.4.  Cellular Radio Networks Asks

> new proposed bullets …

Do You propose to extend this section with general requirements of the Cellular

Radio Networks? This section focuses on “data plane transport”. I have concerns on

some items of your list and have found some of them not relevant from DetNet

perspective.



Cheers

Bala’zs





-----Original Message-----
From: Carlos Jesús Bernardos Cano [mailto:cjbc@it.uc3m.es]
Sent: Friday, March 10, 2017 2:22 AM
To: detnet@ietf.org
Cc: draft-ietf-detnet-use-cases@tools.ietf.org
Subject: Crosshaul input for consideration in draft-ietf-detnet-use-cases



Hi,



In Seoul we presented draft-bernardos-detnet-crosshaul-requirements-

00.txt as potential input to be considered for "Section 6. Cellular radio" of draft-ietf-detnet-use-cases. The group agreed that contributions from us were welcome to complement/fix the text in the use cases document.



We have taken -11 version and tried to propose specific changes to the document. Please find them below for discussion.



----

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 synchronizatio n 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.  Some fronthaul functional splits considered by 3GPP require the frame loss ratio (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

   (baseband processing units) and the remote radio heads (antennae)

   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.).

----



Comments are welcome,



Thanks,



Carlos