the slice thing is pretty much
what you get from VLANs +
a higher level thing, what we had on planetlab for compute resource -
first off ,you want to partition the net into a large number of virtual private partitions
then within those partitions, maybe, implement soem custom/specialist services (multicast,
firewalls, load balancers etc -- c.f. NAAS:-)
see
https://www.ericsson.com/spotlight/cloud/blog/2015/02/17/5g-network-slices/
I think putting SDN within a slice makes sense - using SDN to manage slices (of which there
could be more than there are users) doesn't make sense to me because a) the mechanisms for
dividing resources go right down to the physical layer (indeed also interact with other tricks
like cooperative relaying, mimo, coding etc)...so a) they better work independent of other
higher level services and b) other higher level things (including SDN) depend on them working
- a circular dependency would be a bad idea, n'est ce pas?
> I'm not sufficiently familiar with the " 5G network slicing solution" to
> talk to john's point; honestly, I think the implementatin strategy is
> just that, but its still hard graft and sometimes heroic engineering - no
> matter how people slide it.
>
> just observing the note about SDN tending to centralization
>
> Id' always considered it an error to consider that SDN must be
> centralised or semi-centralised or ...
>
> While most of the pictures of such structures indicate this, they
> actually tell a lie; most any (SDN) switch has a local processor etc etc,
> practically (from my own experience) SDN is about API definitions being
> open, extensible, and useful; thus, there is the ability to get into the
> control-plane data-plane interface - and in recent times we have seen the
> control plane - API plane (north bound interfaces in SDN nomenclature)
> have been where every Tom, Dick and Harriet have rerolled their own bad
> form of centralization etc.
>
> The open/extensible/useable/useful API between controller and switch
> fabric (where I spend most of my care) does not preclude
> decentralization, nor does it preclude sensible 'core infrastructure'
> designs - it is only that so many of the first instance of (recent) SDN
> work seemed to also proclaim they had discovered (Ha!) the advantage of
> centralised administration as well.
>
> I'd also suggest and wonder if there is a burden for each of these
> northbound API people (it might be 5g it might be 'funky new CDN' it
> might be 'some resiliance thingo') is they don't have much awareness of
> each others efforts and successes. Of course, building upon solid past
> success rather than rolling-your-own, gets fewer, so-called, Hot
> publications..... better stop there before my fingers are burnt.
>
>
> My thoughts of this second.
>
> cheers,
> Andrew.
>
>
>
> > On 5 Mar 2017, at 13:01, Jon Crowcroft <[log in to unmask]>
> wrote:
> >
> >> I'm dubious about 5G network slicing solutions. Why make it a story
> about
> >> SDN and NFV? A solution in search of a problem?
> >
> > John
> >
> > indeed - the scale and resilience requirements for such a crucial
> dimension of the
> > service argue strngly against semi-centralised solutions - i know of
> one massive data center
> > failure which was down to the SDN controller&vlan management, and that
> was a much simpler (and
> > localized) problem, which still needed very complex manual access to
> get the system up again.
> >
> > the idea that we'd predicate a core critical infrastructure like 5G on
> the same design mistake
> > is daft. - I suppose we could replicate the SDN controllers to every
> cell tower and then run
> > some state machine replica management algorithm, but why not just run
> some decentralised
> > dice&slice scheme in the first place...? what it would look like is
> actually an interesting
> > problem - another bad idea (I've seen in the IETF) is something based
> on BGP:)
> >
> > j.
>
>
|