enabling the adoption of key cloud native principles · 2018-12-18 · amf mme ausf mme bsf policy...

Copyright © 2018, Oracle and/or its affiliates. All rights reserved. |

Enabling the adoption of key cloud native principles

Todd SpragginsStrategy DirectorOracle CommunicationsDecember 11, 2018


DevOps Continuous Delivery

2

Microservices

Cloud Native Core Concepts

Not my problem

Separate tools, varied incentives,

opaque process

Shared responsibility

Common incentives, tools, process

and culture

Release once every 6 months

More Bugs in production

Release early and often

Higher Quality of Code

Tightly coupled components

Slow deployment cycles waiting on

integrated tests teams

Loosely coupled components

Automated deploy without waiting on

individual components

Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 3

Cloud Native Operational PrinciplesSystem

Immutability

Automate Everything

Disposability

Externalized Configuration

Logs as Event Streams

Constant Telemetry

Delegated Governance

Indepenent Lifecycles

• Everything is code (software and configuration)• No manual configuration or customization is allowed• All changes applied through CI/CD pipeline

Benefits:• Easier to implement principle of least privilege• Effective intrusion detection


Cloud Native Operational Principles

System Immutability

Automate Everything

Disposability



Constant Telemetry



• All aspects of build, test, verification, deployment, etc. are automated

• Includes activities such as backup, recovery, password/key rotation, etc.

Benefits:• Remove the human element• Rapid repairs



System Immutability

Automate Everything

Disposability



Constant Telemetry



• All services are transient and treated as short lived• Services can be spun up and down quickly without

service interruption

Benefits:• Regular repaving (redeployment)• Faster recovery from failure



System Immutability

Automate Everything

Disposability



Constant Telemetry



• No configuration embedded in software images• Configuration includes passwords and credentials,

location of backing stores, etc.

Benefits:• Development / Production parity• Versioned configuration



System Immutability

Automate Everything

Disposability

Externalized ConfigurationLogs as Event

Streams

Constant Telemetry



• All logs are treated as a stream of time ordered events and stored in a centralized log collector

• Everything needed to debug or diagnose any functional, operational, or security issue must be in logs or metrics data

Benefits:• Threat monitoring (aggregated and time

ordered holistic view)• Forensics (historical view of events)• Diagnostics (events can be correlated)



System Immutability

Automate Everything

Disposability



Constant Telemetry



• Teams delivering a service are responsible for operating the service

• Some shared aspects of the environment are still centrally managed (networking, identity management of infrastructure)

• Governance enforced through checks in Continuous Delivery pipelines

Benefits:• Business agility Compliance enforcement • Feedback loop



System Immutability

Automate Everything

Disposability



Constant Telemetry



• Each microservice is independently upgradeable, scalable, deployable, etc.

Benefits:• Support other cloud native principles• Minimize the amount of change in the system at one time

Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | Confidential 10

Cloud Native LandscapeA

pp

Def

init

ion

&

Dev

elo

pm

ent

Orc

hes

trat

ion

&

Man

agem

ent

Ru

nti

me

Pro

visi

on

ing

Clo

ud

Database & Warehouse Streaming & Messaging Application Definition &Image Build

CI/CD

Scheduling & Orchestration

Coordination & Service Discovery

Service Mesh

Cloud Native Storage Container Runtime Cloud Native Networking

Automation & Configuration Container Registry Key ManagementSecurity &Compliance

Public Private

Observability & Analysis

Monitoring

Logging

Tracing

Not Prescriptive, Rather in Support of 12 Factor Application:I. CodebaseII. DependenciesIII. ConfigurationIV. Backing ServicesV. Build, Release, RunVI. Stateless ProcessesVII. Port BindingVIII.ConcurrencyIX. DisposabilityX. Dev/Prod ParityXI. LogsXII. Admin Processes

RPC Service Proxy API Gateway


• The 5G architecture is service-based

• Focus is on loosely coupled services as opposed to tightly coupled functions and point to point interfaces

• HTTP/2 as service based application layer protocol

• Native control and user plane separation

• The 5G network will no longer be a “one-size-fits-all” network - slicing

• Unified data management framework

• Expanded and unified policy framework

• Expanded network exposure functionality

5G system architecture 5G system architecture

Control plane

5G network function 4G predecessor

AMF MME

AUSF MME

BSF Policy DRA

CHF OCS+OFCS

NEF SCEF

PCF PCRF + ANDSF

SEPP DEA

SMF SGW-C/PGW-C

UDM HSS

UDR UDR/SPR

UPF SGW-U/PGW-U

11

UE gNB UPF DN

SEPP

SMSF NSSF NEF PCF UDMNRF CHF

NWDAF EIR BSF AMF SMFAUSF UDR UDSF

AF

NEW


NEF

Service Exposure Framework

Measurement & Reporting Framework

NWDAF

12

An Abstract View of the Service Based Aspects of 5G

NSSF

Service Discovery & Coordination Framework

NRF

Legacy NF(i.e.HSS etc.)

SBA NF(i.e. UDM)

SBA NF(i.e. SPR)

SBA NF(i.e. UDSF)

Decomposed Services

BSF

UDR


APIGateway



Trace

13

An Uncanny Resemblance to the Cloud Native Landscape

ServiceRegistry


LegacyApplication

Micro-Service

Micro-Service

Micro-Service

Decomposed Services

Monitor

Log

Key Value Store

DNS


SBA Does Come with Some Challenges

• Routing - Load Balancing/Alternate Routing

• Deficiencies in Congestion Control and Overload Protection

• Risk in introducing new capabilities and upgrades

• Visibility of the overall health of the network

• Limited support for traffic prioritization

• Complexity and Scale to NFs exposed to other NFs - Authorization

• Interoperability with 3G/4G networks

• Large number of TCP connections

• HTTP/2 - Unproven in Telecom Signaling

14


Challenge – Routing and Load Balancing

• Vendor specific routing/load balancing implementation

– No uniform load management results in unpredictable traffic behavior

– False negatives: An NF may think it’s not “internally” loaded but is in effect not behaving as well as other NFs of similar load.

• Latency in load information conveyance– Delays routing rule/policy update potentially cause

cascading failure

15

5G consumer

NF business

Logic

SBAComm.

NRF

Periodic

Producer 5G NF

Producer 5G NF

Producer 5G NF

Load Balancing / routing logic is implemented as part

of the consumer – could potentially be vendor

specifics

NRF relays load information to

consumer


Challenge - Congestion / NF failure

• Congestion control in 3GPP R15 is not adequate

– Consumers may interpret it differently and take different actions

– Misbehaving or rogue NFs can flood the network

• Congestion handling is not 5G aware– No mechanisms to identify and route high priority

application traffic while rejecting low priority traffic

• Cascading failure due to NF Degradation

– Lot more messages in flight before the consumers detect that the provider has failed

5G consumer

NF business

Logic

SBAComm.

Producer

503/429

congested


Challenge – Upgrades and Maintenance

• Introducing new features into the network has always been a high risk activity

– Highly coordinated, Maintenance Windows & Time consuming

– Upgrade failures & Back out issues

• Need mechanisms in the 5G SBA to facilitate Blue-Green deployments & Canary Releases

– Reduces risk by introducing the newer features to a small set of users

– Exposing more users to a newer version of the service over time.

– Ability to stage two releases at a time and switch between them quickly and gracefully if desired

17

NF

NF

NF

NF

NF

NF

NF

NF

SBA

NF NF

SBA


Challenge – Visibility into the core

• Operation requires network visibility

– KPIs regarding success rates, timeouts, latency rates, failures are essential

• 5G SBA based on distributed architecture principles

– Makes it difficult to assess the general health of the network

– Debugging in the event of a failure much harder

Confidential – Oracle Restricted 18

NF

NF

NF

NF

NF

NF

NF

NF

SBA


APIGateway



Trace

19

Addressing Challenges with Service Mesh & Service Proxy

ServiceRegistry


Monitor

Log

Key Value Store

DNS

Proxy

Micro-Service

Proxy

Proxy

Micro-Service

Micro-Service

Service Mesh

Load BalancingTraffic PoliciesService DiscoveryObservabilityHealth CheckingRoutingSecurity


Introducing the Service Framework Support Function for 5G

20

ServiceBusiness Logic



Service Adaptor

Svc. Reg. Mgmt.

Overload Control Load Balancing

Discovery Mgmt.

More Services

Authorization Mgmt.

NRFBusiness Logic

SBI SBISBI

SBI

• Common service for handling communication between services

• Offloads inter-service communication concerns from application logic

• Enables uniform visibility and control of inter-service communication flows

• Has capabilities such as: circuit-breaking, latency-aware load-balancing, eventually-consistent service discovery, transaction retries, and transaction deadlines

• Provides both point-wise resilience and service-wise resilience

• Specific to 5G– Supporting routing based on information in the body of HTTP

messages: user identities (e.g. SUPI, GPSI), DNN, supported features, etc.

– Message prioritization:• Requires understanding of new custom HTTP header (3gpp-Sbi-Message-Priority)

• In certain cases, being able to inspect HTTP message bodies, e.g. reservationPriority, mpsIdentifier, etc. is needed

– Mediation capabilities require modifications of message bodies


eSBA with the Service Framework Support Function

21

Key conclusions about routing via the SFSF and ability to perform service discovery via it have been agreed as way forward into the Rel-16 normative phase.

Solution Four (section 6.4) as submitted by Oracle and Verizon with support of AT&T, DT, KDDI, NTT, China Mobile, Cisco, Ericsson and others covers: • High level description

• Roaming architecture

• Network slicing aspects

• Services and illustrated Procedures

• Service Registration/Update/Deregistration

• Service Discovery

• Service Request/Response

• Impacts on existing Services and Interfaces

• Evaluation of the Solution


Q&A


Safe Harbor Statement

The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

23

enabling the adoption of key cloud native principles · 2018-12-18 · amf mme ausf mme bsf policy...

Documents