Re: [5gangip] 5G and Slicing

Dirk Kutscher <Dirk.Kutscher@neclab.eu> Mon, 26 October 2015 14:28 UTC

Return-Path: <Dirk.Kutscher@neclab.eu>
X-Original-To: 5gangip@ietfa.amsl.com
Delivered-To: 5gangip@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A591B2F62 for <5gangip@ietfa.amsl.com>; Mon, 26 Oct 2015 07:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level:
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 nRF0bRSXS-Wa for <5gangip@ietfa.amsl.com>; Mon, 26 Oct 2015 07:28:12 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29FE01B2F53 for <5gangip@ietf.org>; Mon, 26 Oct 2015 07:28:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id A32C010ADD7; Mon, 26 Oct 2015 15:28:10 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si7PsXyL6DqD; Mon, 26 Oct 2015 15:28:10 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 7B94110ADD4; Mon, 26 Oct 2015 15:28:04 +0100 (CET)
Received: from PALLENE.office.hd ([169.254.1.18]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Mon, 26 Oct 2015 15:28:04 +0100
From: Dirk Kutscher <Dirk.Kutscher@neclab.eu>
To: "Dirk.von-Hugo@telekom.de" <Dirk.von-Hugo@telekom.de>, "Peter.AshwoodSmith@huawei.com" <Peter.AshwoodSmith@huawei.com>, "5gangip@ietf.org" <5gangip@ietf.org>
Thread-Topic: 5G and Slicing
Thread-Index: AdEKnYed7eXcqI1LSJ2yVaMYbwbATQAq8ucQAAZ8qZABIk/4kAACxANA
Date: Mon, 26 Oct 2015 14:28:04 +0000
Message-ID: <82AB329A76E2484D934BBCA77E9F5249A6748EA4@PALLENE.office.hd>
References: <7AE6A4247B044C4ABE0A5B6BF427F8E20AEF89B0@szxeml559-mbs.china.huawei.com> <05C81A773E48DD49B181B04BA21A342A33B17669FD@HE113484.emea1.cds.t-internal.com> <7AE6A4247B044C4ABE0A5B6BF427F8E20AEF9717@szxeml559-mbs.china.huawei.com> <05C81A773E48DD49B181B04BA21A342A33B1812D54@HE113484.emea1.cds.t-internal.com>
In-Reply-To: <05C81A773E48DD49B181B04BA21A342A33B1812D54@HE113484.emea1.cds.t-internal.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.7.0.204]
Content-Type: multipart/alternative; boundary="_000_82AB329A76E2484D934BBCA77E9F5249A6748EA4PALLENEofficehd_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/5gangip/71w7BAl4KAyyKfPI0t73b9nHobY>
Subject: Re: [5gangip] 5G and Slicing
X-BeenThere: 5gangip@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of implications of the upcoming 5th Generation \(fixed and\) Mobile communication systems on IP protocols." <5gangip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/5gangip>, <mailto:5gangip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/5gangip/>
List-Post: <mailto:5gangip@ietf.org>
List-Help: <mailto:5gangip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/5gangip>, <mailto:5gangip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Oct 2015 14:28:20 -0000

Dear all,

good discussion, and I agree to what has been said so far.

A comprehensive virtualization and programmability approach in 5G could enable new, more adequate technologies for accessing named data, in-network storage and object-level security.

Such an ICN layer could then again used for different service slices, for example IoT, real-time multimedia, web access.

One interesting question would be what assumptions should be made on the underlay and its service model. In other words: what would be the common denominator for forwarding abstractions.

Is that just L2 connectivity? Is it IPv6 as a pseudo L2?

It would be great if the underlay would not get into the way of ICN multipath and broadcast communication capabilities, i.e., it should at least be possible to run over virtualized link layers in the access.

BTW, there is a workshop at Waseda University on the Friday  before the IETF (i.e., this week) with a panel discussion that will touch upon some of those questions:
http://jp.greenicn.org/workshop.html

Best regards,
Dirk


From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of Dirk.von-Hugo@telekom.de
Sent: Montag, 26. Oktober 2015 14:04
To: Peter.AshwoodSmith@huawei.com; 5gangip@ietf.org
Subject: Re: [5gangip] 5G and Slicing

Dear Peter,
I very much agree with what you detailed below - thanks a lot for that. Presuming that your list was not meant to be exhaustive, I would just add (still not achieving thus completeness) inline below as denoted by Dh>:
What do you think?

Thanks and Best Regards
Dirk

From: AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com]
Sent: Dienstag, 20. Oktober 2015 21:04
To: von Hugo, Dirk; 5gangip@ietf.org<mailto:5gangip@ietf.org>
Subject: RE: 5G and Slicing

Hey Dirk,

In my mind a "slice" consists of an end to end set of sub-slices. Where a sub-slice is what you get when you virtualize one of the following:

UE
UE Os/processes
UE Antennas
Antennas

Dh> here I would add: antenna elements (as in massive MIMO)

Time/Frequency

Dh> here I would add: / code

mmWave or uWave fronthaul
DWDM fronthaul
TDM fronthaul
Packet fronthaul
DC fabric
DC servers
Server VM's
Server Containers
Server bare metal
Server acceleration hardware
Inter DC packet transport
Inter DC optical transport

In other words a slice has some subset of the UE, some subset of the spectrum, of the fronthaul, of the CRAN fabric etc. and is a 5G network in its own right. In fact a slice could run a 4G network end to end or even a 3G network end to end or even multiples of them using different bands I suppose.

The method of virtualizing each of the above is different but clearly ACTN/GMPLS etc would cover DWDM/TDM fronthaul and inter C-RAN optical transport virtualization while traditional MPLS-TE/SR covers packet fronthaul/backhaul/inter C-RAN virtualization. Vxlan covers DC fabric virtualization etc. Of course the various L2/L3VPN technologies all can provide virtualization depending on the network architecture chosen and the degree of isolation desired among the slices at the packet layer.

My point 4 - is aimed at what could you do within a slice that is not IPV6 or IPv4 based. It would seem to me that one possible candidate is Information Centric Networking which "could" run in its own slice without disturbing any of the IP based operations in other slices. By doing so it can also have its own Radio Access Technology possibly better suited to low power devices, i.e. one that does not require signaling to reserve radio resources.

So the way I see it the IETF/IRTF have three first areas of interest to 5G and slicing.

Virtualization technologies ( that they are already doing) for different network technologies in the end to end slice.
Applications that can run within a slice that are perhaps better suited to problem XXX.
Technologies that can be used to improve IP mobility and therefore useful within a 5G slice running IPV6.

Dh> I would replace IP mobility by more general IP connectivity including: mobility, (multi-(routing)) path selection, ...

Cheers,

Peter

From: Dirk.von-Hugo@telekom.de<mailto:Dirk.von-Hugo@telekom.de> [mailto:Dirk.von-Hugo@telekom.de]
Sent: Tuesday, October 20, 2015 11:46 AM
To: AshwoodsmithPeter; 5gangip@ietf.org<mailto:5gangip@ietf.org>
Subject: RE: 5G and Slicing

Dear Peter,
Thanks for pointing there. I agree with most ideas, especially that slicing is one of the major new issues in 5G - that may also refer to WG TEAS (Traffic Engineering Architecture and Signaling) and the concepts discussed there, especially with respect to drafts on ACTN (Abstraction and Control of TE Networks).
With respect to your 4th comment on 'non-ip ICN' (here: Information-Centric Networking?) my question would be:
- Do you mean non-IETF since ICNRG is an IRTF group (with drafts on IP isssues such as https://tools.ietf.org/html/draft-irtf-icnrg-challenges-02)?
- Or do you rather suggest to discuss also below-L3 naming issues for multi-path or heterogeneous RAN control?
My feeling is that the latter item would be slightly out of scope in an IP-related discussion, let alone that cross layer information from L2 could assist L3 decisions in finding best IP addresses for routing paths etc. ...
Or did I misunderstand you?
Thanks and Best Regards
Dirk

From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of AshwoodsmithPeter
Sent: Montag, 19. Oktober 2015 20:40
To: 5gangip@ietf.org<mailto:5gangip@ietf.org>
Subject: [5gangip] 5G and Slicing

Greetings, just noticed the creation of this mailing list, not sure how much discussion has already occurred but thought I would mention a couple of points briefly.

1 - the concept of network slicing for 5G (the end to end ability to create multiple logical 5G networks from a physical infrastructure) most likely is relevant to all the different VPN technologies standardized at the IETF.

2- This could include GMPLS/WSON related TDM/DWDM to chop up the optical/TDM layer, IP VPN's and all their flavors including VxLan etc. to slice at the packet layer and SDN/NFV for slicing of resources in the DC.

3-V6 and mobility within a slice for packet core behaviors.

4-new 'non ip' protocols like ICN within a slice for new applications with different RAT's.

Cheers,

Peter