SAP NetWeaverBW with SAP BusinessObjects Web Intelligence 4.0 using the new SAP BExdirect access
Program Access 4.0 / A4 and the Role of the Community...Access 4.0 is the Design of a new access...
Transcript of Program Access 4.0 / A4 and the Role of the Community...Access 4.0 is the Design of a new access...
Program Access 4.0 / A4and the Role of the CommunityAccess 4.0 TeamPresenters: Manuel Paul, Bjoern Nagel
Access 4.0 is the Design of a new access platform with tight coupling to a cost model
2
e.g. located in the CO
FTTH/xPON
FTTB/G.Fast
FTTC/xDSL
4G / 5GAccess 4.0
Design
Cost Case
…
A4-PoD1)
1) Access 4.0 Point of delivery: production of broadband IP
BackboneIP
• Cost model developed from day one
• Strong interworking between architecture / design and Cost modelling
• Comprehensive application of Design-to-costmethods
Gigabit ready Technology Cost model
production of Gigabit IP
Hybrid
Access 4.0 / A4 – Scope & Objectives
3
BackboneB/OSS
Spine-Switch Spine-Switch
Leaf /ToR Service Edge
Local Management
Control x86
WDM
Control x86 Control x86
GPON LT
GPON LT
GPON LT
GPON LT
GPON LT
GPON LT
XGS-PON LT
XGS-PON LT
WDM
GPON LT
GPON LT
GPON LT
XGS-PON LT
XGS-PON LT
Leaf /ToRService Edge
Leaf /ToR Service Edge
Central EMS
x 900
x 1
GPON LT
ONT
DPU
Scope of Access 4.0
Extensive D2C project for FTTH/B
Everything monitored in a comprehensive Cost Model
Design and engineering using bare metal / OCP hardware, lots of open-source software as well as merchant silicon
Application of data center principles, leaf/spine fabric, CI/CD, …
Clean IT architecture (Las Vegas principle)
Objectives of Access 4.0
Save CapEx and OpEx
Reduce vendor lock; bring in new players
Drive automation
Time-to-Market for services (keep business logic SW in house)
Increase flexibility for capacity mgmt, change-over, migration, …
Platform Compatibility Framework with standard set of APIs avoids hardware lock-in provides compatibility to apps/features
through common protocol and data model for forwarding provides compatibility of management tools and practices
Anything south of the dotted line to be provided by hardware vendor
Design paradigm: Control plane / user plane splitno fragmentation, please…
4
Forwarding Plane
Control Plane
CP/UP Mediation LayerDrivers
D1 D2 D4D3
D1 D2 D4D3
App1 App2 App3Fixed / mobile or converged control applications (usually on x86)
Programmable hardware on bare metal(Differentiate through performance & exposed feature sets)
VOLTHA: Successful instantiation of The key Design Principles
5
Open hardware
Bare metal switch platform, carrying …
… programmable switching & PON chipsets
… a PC board (for drivers, services)
Modular, based on carrier requirements
e.g. specified at Open Compute Project
Customize like a PC
Transparent regarding technology and cost
Open software
Open driver & application platform, building on VOLTHA
Modular, scalable
Standard interfaces & protocols
Mediates towards SDN Control
Integrates vendors’ drivers
Reduced testing & integration efforts, community-driven
*picture sources: EdgeCore Networks, opencord.org
Hardware Design: Motivation & Design Guidelines
66
Motivation for OCP Specification Design guidelines
Eco system for white box PON devices leaves room for
improvement !
Few devices from few vendors – with little telco experience
Carriers want at least two suppliers – need more choice !
DT wishes to foster the community & there was a need for more participation …
Last but not least :
We hope to instigate other contributions to create competition, innovation and better economics ...
After some great joint efforts with partners the spec went through the administrative process and is published now!
Reuse existing work to allow for quick implementation
Use mainstream merchant silicon & COTS (Commercial Off The Shelf) components
Comply to relevant standards
Allow & promote the use of open source software
Aim for state of the art performance at optimum total
cost of ownership
Create something that „the world“ needs !
Design choices and details :
Specification selects a first straight forward solution, derive from what works for XGS-PON :
Well known merchant silicon combination from Broadcom (Maple/Qumran) with off the shelf driver software (BAL) to be integrated into open source VOLTHA framework.
32 and 64 port variants : good fit to chip granularity, uplink capacity and Central Office size (as number of subscribers)
Redundant AC/DC PSUs (hot swappable, 110-230VAC, 50-60Hz autoranging & 48VDC), high efficiency
Flexible Uplinks :
2x100G as QSFP28 to allows in-rack AOC/DAC
plus 8x10/25G SFP28 cages or (C)WDM transceivers for longer reach and WDM for fiber saving
Telco environment implies a long life span – 10 years is typical
The control SW & interface is evolving rapidly - Our spec explicitely embraces this fact !
Dt olt specification at ocp
7
Programmable hardware: a4 switching fabric
8
What has changed …
SDN was never only about central flow / path management … it also is about programmability
It might not have worked at the beginning as planned but now…
There is programmable silicon
ASICs, NPUs, Smart NICs, ….
Powerful SDKs for proprietary chipsets
Open, domain-specific languages like P4/P4 Runtime
Application inside access 4.0
Programming the FIB into silicon on the backplane
Distributed routing control plane
Programming a service edge into merchant silicon
programmed the data path for PPPoE termination
Enhanced debugging features
abstract to have a common control API independent on hardware used below
Open components in access 4.0 prototype
9
Hardware
XGS PON OLT + ONT
Bare metal switches
x86 Servers
Software
Open Network Linux
Ubuntu Linux
Kafka
Kubernetes , Docker + lxc container, KVM
Device abstraction via vOLT-HA and ONOS
Service Edge on Tofino (PPPoE, CP and UP)
POD Life Cycle Manager (LCM)
POD Control Plane (PPA, “Weiche”)
POD EMS, Grafana
green color code: open source / open spec
magenta color code: DT development, possibly to be open sourced
black color code: DT specific or vendor proprietary
10
POD API Definition Hardware Specs
Service Edge API Device Drivers
Overall System Design
*logos are courtesy of the respective organizations
Looking forward to Extend Collaboration with the community
Summary
A4 turned two in summer.What has been achieved for ftth/b and What’s next?
12
1 Real code running FTTH/B@A4
Multiple PPPoE sessions All based on bare metal + open source
(K8s, vOLTHA) Focus on automation (ONT bring-up,
ZTP / capacity- and change mgmt. etc.)
2 Feasibility Study finalized and Cost Model developed
Document shared with 30+ experts within DT
Assumptions and technology in Cost Model documented; Cost Case is green
3 Collaboration / Community
OCP spec for OLT submitted ONF-Community event June 2018 Code contribution for vOLTHA Alignment with other Operators
4 RfQ for Co-Dev Partnership FTTH/B@A4
RfQ issued in June, finalized end of October Objective: find a partner who shares
vision and wants to productize the A4 design
Thank you13