Altiplano A&A – Intents

and its development.

1 © 2019 Nokia
Our marketing story: The power of ’and’

Fixed and wireless A gig to and into home The network and the cloud

Copper
Coax
Fiber
Fixed Wireless

2 © 2019 Nokia
The complexity of ’and’?

How much does OSS need to be aware?

Altiplano

Copper
Coax
Fiber
Fixed Wireless

3 © 2019 Nokia
Models Altiplano Access Controller
Device model and the Abstract Model
High level of abstraction
Abstract Models
Altiplano Access Controller
(Intent Models)

Abstraction and Automation Intent Based

Automation

Networking

Aggregated device Deploy &

align Monitor and
provision troubleshoot
models

Network Virtualizer

Configuration sync State, fault,

performance

Device models
PNF

4 © 2019 Nokia High level of detail

Nokia Internal Use
Intent based networking
OSS

Altiplano

User services
• Foundation is intent based networking
Service infra • Intents hide access technology specifics:
Connectivity • Policy engine automates large scale changes /
troubleshooting actions without impacting the
Equipment config
OSS

Physical Equipment layer

Passive layer: fibers

5 © 2019 Nokia
Source and nature of interactions with the network

Minimal interactions, just enough, through robust

OSS abstract interfaces
• New subscriber
• New device

Access engineering
decisions
Altiplano • SW upgrade
Engine self-driven • Profile roll-out
interactions • Certificate change
• …

Network

6 © 2019 Nokia
What is the current situation ?

• We have a set of reference intents which are way too device

specific
• Example: there is no such thing as an ONU connection which is
realized over both ISAM FX and LS FX. The SNMP and NC/Y
intents share NOTHING today.
• So OSS needs to be aware on those details
• That means that the whole intent DB needs to be repopulated on
migration
• And that means significant OSS impact too
• The biggest issue is that fail to deliver on the promise with
our own reference intents already. We also set the wrong
example
• Note: our customers even expect an abstraction which
works over really different technologies: cable, fiber,
copper and even wireless!
7 © 2019 Nokia
Structuring intents layer by layer

Fully access
L2/L3 user services technology
independent
User services Infrastructure

L1 connections Service infra

Connectivity

Technology specific
Boxes + L1 ports but independent of
Equipment config
version / management
technology etc…
Physical Equipment layer

An empty landscape with some fibers, sites

Passive layer: fibers, sites

A single intent can cover multiple layers, but it is

8 © 2019 Nokia
important to be aware on what it covers!
Above the Red Line
L2 Infra: L2 Service:
- Service Name* - Service Name*
- Network Ports 1 N - Customer Name*
- Forwarding Mode - User Port
- S-VLAN - Service Profile
- C-VLAN - Equipment VLAN

Configures the Network side of left-most device managed by Configures everything from User Port device (right most) till
Altiplano. the User side of left-most device (handled by L2 Infra)

OLT
ONT
NT Forwarder LT Forwarder AP Fwd HoU Fwd
(vONU*)

Each of these device (from OLT to HoU) are created by device-family specific intent (Physical Equipment Layer) and they may have profiles already created by intents in
Equipment Configuration Layer.
L2 Infra and Service deals only with Forwarders and QoS.

9 © 2019 Nokia
What this means to Intent type development and the fwk?

1. Intent types to handle devices managed by AMS, NV, (NSP and others in future).
• Almost all layers have this requirement.
2. “label” will be used to specify ports.
• ONT / DPU / HoU – UNI ports labels will come from HW Type mappings.
• OLT ports – Dynamic: Device intent will be providing the mapping to labels.
• PON / DSL Ports as the card gets planned.
• NT ports – Static by HW type + Dynamic based on LAG configurations.
• SR ports – TBD
3. Intent types above the red line will have to
• Support different fingerprints
• Be modular to avoid code duplication
• Use JSON based abstraction models to derive values for their specific case.
10 © 2019 Nokia
1. Multi Manager Support
altiplano-intent-fwk.js

1. THE FWK to be used by ALL intent types from now on.

2. Netconf, SNMP, NSP specific FWKs are STILL Valid. BUT… those will be used in device-specific
context. altiplano-intent-fwk will call these FWK based on manager-type of the device being handled.
3. NO access technology specific fwks anymore.
4. All flavors of netconf-fwk will be dropped and replaced by a single altiplano-netconf-fwk.js
• We’ll start with altiplano-netconf-fwk having xml NS/module mapping of XPON, WPON devices.
• Eventually, AC will be aware of device-plugs (one day) and these should NOT be hard-coded into the FWK.
5. Similarly flavors of SNMP/AMS fwk are replaced by single altiplano-ams-fwk.js
6. MAJOR Change within these manager-specific FWK Scripts:
• Intent Object is the ONLY data member that gets instantiated per IBN call. ALL methods (functions)
implemented on prototype to reduce memory usage in runtime.
• RequestScope (Java ThreadLocal) holding a HashMap to share data across different pieces without polluting
function signatures.
11 © 2019 Nokia
 altiplano-intent-fwk.js

• Instantiated with a single JSON input.

• Two call back methods to be implemented by
intent type designer
• getDevicesInvolved
• Should return an Array where the elements can be of
type “string” or “object” (DeviceInfo)
• getIntentObjectFor
• Should return the IntentObject JSON that can be used
to instantiate manager-specific FWKs.
• IBN Intent type contract functions MUST be
defined in script-content.js and SYNC/AUDIT
alone can be delegated to FWK.
• Validate, State Retrieval, Suggest to be
implemented by specific intent-types.
• We will get some utility functions to help here. But, to
be delegated from script-content.js explicitly.
12 © 2019 Nokia
2. How labels going to impact intent type development?

L2 Service Intent Instance

UNI: MyONT:LAN-1

1. Perhaps, we would need some FWK support to

1. Get the Device Name generate/maintain labels for dynamic port addition.

2. Is it an ONT?
L2 Service Code

ONT Intent Instance

4. Use the device port id & configure

ONT Intent Type

HW Types JSON
3. Fetch device port that LAN-1
label points to.

13 © 2019 Nokia
3. Fingerprints

ONT
• Both Infra and Service Intent types
OLT Fiber access from OLT.
(vONU*) should be capable of handling multiple
fingerprints.
Copper access from iSAM directly.
• Infra – Limited to OLT, DPU and AP
iSAM for now. SR will get added in future.
• Service – Things that are possible
Copper access with Fiber Uplink. within FN – but not all possibilities.
OLT
ONT
DPU
• We support select type of network
(vONU*) topologies and forwarding modes.
• We will expand on what is covered as we
WiGig access with Fiber Uplink. mature.
ONT
OLT AP HoU
(vONU*)
• So, FWK Requirements are:
• It should support smooth evolution.
SR OLT…. • Easy to code/maintain
• Easy to customize/extend
14 © 2019 Nokia
Design of L2 Infra/Service

L2 Infra/Service
Fingerprint A (fingerprint.js)
- Name
- Detection Logic Service Profile 1:
Service Profile (getDevicesInvolved)
Names - Configuration composition Copper:
(getIntentObject)
AIR/CIR/EIR or Profile Name
- Service Profile Detailing
Forwarding Mode
(service-profile.json)

Fiber:
AIR/CIR/EIR

iSAM vVPLS NT Configuration iSAM ONT UNI – XC – Reusable Configuration

Inputs: A, B, C, D S+C Blocks…..
Inputs: A, B, C, D
handler.js handler.js

Service creates and reuse objects created by other service intents. Upon delete, shared objects shouldn’t
FTL Files FTL Files be deleted.

Garbage Collection designing work in progress…

15 © 2019 Nokia
Shared Objects and Garbage Collection

• Service intents create all necessary objects to deliver service. Means, some objects (like LT SAP
shared among subscribers) cannot be deleted when the subscriber/intent gets deleted.
• Shared objects is not new problem. Last user getting deleted can cleanup. BUT… it’ll need every
intent creating/deleting such shared objects to be synchronized. Can’t really scale.
• Solution: Service Intents don’t delete shared objects, but a Garbage Collection process will
cleanup unused objects.
• Questions:
• GC pause time directly proportional to service provisioning “down” time. How to reduce the GC pause time?
• AC core doesn’t know anything about Device model objects and their relationships. How to involve intent-types in GC
process?
• Proposal:
• See attached sequence:

shared-obj-gc.png

16 © 2019 Nokia
DEMO……

17 © 2019 Nokia
TODO / Next Steps

• altiplano-intent-fwk.js to remember devices and delete removed devices (capability exists in

netconf-fwk alone – move it out)
• altiplano-intent-fwk.js to support multiple intentObject for single device (example fingerprint: NW
Port on SR and UNI on ONT – OLT both sides should be configured).
• Move all utility functions (should be really stateless and NOT depend on intentObject JSON) to a
new utility-functions.js to share across FWKs.
• Shared Objects and Garbage Collection
• ONT intent type (iSAM) in POC now uses XtraInfo ALONE to identify ont. It will have to match
by Serial number.
• AMS FWK is not fully refactored to have prototypes.
• NSP FWK to be refactored.

18 © 2019 Nokia