Re: [Marnew] [5gangip] [Stackevo-discuss] [gaia] 5G: It's the Network, Stupid

AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com> Tue, 22 December 2015 18:47 UTC

Return-Path: <Peter.AshwoodSmith@huawei.com>
X-Original-To: marnew@ietfa.amsl.com
Delivered-To: marnew@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314BF1A8A79; Tue, 22 Dec 2015 10:47:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
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 5qCG2MJWqfnh; Tue, 22 Dec 2015 10:47:55 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [58.251.152.64]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2161A8A6D; Tue, 22 Dec 2015 10:47:52 -0800 (PST)
Received: from 172.24.1.47 (EHLO szxeml427-hub.china.huawei.com) ([172.24.1.47]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBI46914; Wed, 23 Dec 2015 02:47:30 +0800 (CST)
Received: from szxeml559-mbs.china.huawei.com ([169.254.2.89]) by szxeml427-hub.china.huawei.com ([10.82.67.182]) with mapi id 14.03.0235.001; Wed, 23 Dec 2015 02:47:17 +0800
From: AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com>
To: Joe Touch <touch@isi.edu>, Dino Farinacci <farinacci@gmail.com>
Thread-Topic: [5gangip] [Stackevo-discuss] [gaia] 5G: It's the Network, Stupid
Thread-Index: AQHROW5WZcE4Jya+TkWrglMNHXDB+p7VnQoAgAGtUTeAAA3DMA==
Date: Tue, 22 Dec 2015 18:47:16 +0000
Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E20AF3BC87@szxeml559-mbs.china.huawei.com>
References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <CAEeTej+pHehyX7+qteogQcAkCcJKYhZoQKStuXGmAzWRj1_rXQ@mail.gmail.com> <F8355406-91C7-4B96-995C-1AD9D7997DC1@kcl.ac.uk> <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm> <56789156.2020704@isi.edu> <6EE22057-5EB9-4489-A50D-7B92DA2B96AF@gmail.com> <5679857D.9000602@isi.edu>
In-Reply-To: <5679857D.9000602@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.193.60.100]
Content-Type: multipart/alternative; boundary="_000_7AE6A4247B044C4ABE0A5B6BF427F8E20AF3BC87szxeml559mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56799AC4.0017, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.89, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: dd7428a927495eb80a217c113c229158
Archived-At: <http://mailarchive.ietf.org/arch/msg/marnew/r5fPugYQhjoxbBQ0sAHJeFz_Ld0>
X-Mailman-Approved-At: Tue, 22 Dec 2015 10:48:42 -0800
Cc: "icnrg@irtf.org" <icnrg@irtf.org>, gaia <gaia@irtf.org>, "stackevo-discuss@iab.org" <stackevo-discuss@iab.org>, "marnew@iab.org" <marnew@iab.org>, Linda Dunbar <linda.dunbar@huawei.com>, Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk>, "5gangip@ietf.org" <5gangip@ietf.org>, Nishanth Sastry <nishanth.sastry@kcl.ac.uk>, Dirk Kutscher <Dirk.Kutscher@neclab.eu>, "dtn-interest@irtf.org" <dtn-interest@irtf.org>
Subject: Re: [Marnew] [5gangip] [Stackevo-discuss] [gaia] 5G: It's the Network, Stupid
X-BeenThere: marnew@iab.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Managing Radio Networks in an Encrypted World <marnew.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/marnew>, <mailto:marnew-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/marnew/>
List-Post: <mailto:marnew@iab.org>
List-Help: <mailto:marnew-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/marnew>, <mailto:marnew-request@iab.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Dec 2015 18:47:58 -0000

Couple of comments from my perspective before disappearing for Xmas.



> Slices have the baggage that a process can belong to only one slice at a time.



Not always. A process which is implementing an air interface could in fact be implementing several slices in the same process. Or same core.


> Why does yet another term need to be defined for what has been traditionally called a multi-tenant VPN.



I believe a slice is much more than a VPN however VPN technologies are likely a component part of what a slice 'is'.



Here is a definition I have found helpful:



To define a slice we need to look at it from the perspective of both the end devices (1) and the network (2) so:



(1)   From the perspective of the end devices it's relatively simple. A slice is a way to group end devices that share common QOS/QOE and Administration/Geographic area etc.



(2)   From the perspective of the network a slice is much more complicated. Essentially a slice is a set of subsets of the all the network equipment that makes up the 5G network from Antennas through to core processing. Thus

Slice_i =   Subset of(All_Antennas)        U

            subset of(All_Fronthaul)       U

            Subset of(All CRAN fabric)     U

            Subset of(All CRAN processing) U

            Subset of(ALL Numerologies)    U

            Subset of(All DC fabric)       U

            Subset of(All DC processing)



Where of course Subset(X) can contain all or none of the elements in X.



So to bring up a slice we need to allocate antennas, configure the fronthaul to the CRAN fabric, allocate the CRAN fabric, allocate processing resources ( shared or unique in the CRAN), populate those processing resources with the code (Numerology) that implements the RAT, then we need to allocate packet backhaul bandwidth in the CRAN or DC fabric, then assign compute resources (shared or stand alone for the packet core processing).



>From this we can see that a multi tenant VPN can be used to implement a subset of a DC fabric and interconnect a subset of all DC processing. However there are a number of other areas of interest to the implementation of a slice that are well outside the scope of a VPN.



Note also that a slice can be isolated from another slice in time, space, frequency or statistically in each of those subsets and in particular the fronthaul and RAT require very hard boundaries between slices while as we get further towards packet processing the boundaries can be less ridgid.



Hence the need for a new term.



Peter