PLNOG14: Service orchestration in provider network, Tail-f - Przemysław Borek

Service orchestration in provider network – Tail-f

Przemysław Borek

Consulting Systems Engineer, GSP NMS/OSS

[email protected]

PLNOG 2015

2 © 2015 Cisco and/or its affiliates. All rights reserved. Cisco Public

Agenda

Introduction

Key Takeaways

Example: NSO in mobility

Cisco Network Services Orchestrator (NSO) enabled by Tail-f

NETCONF & YANG

Q & A


Introduction


The Operator Goals Complexity Hindering Opportunity

4

Service Agility

Months to Minutes

Revenue

Increase

¥ € £ $

OpEx/CapEx

Reduce


Today’s Service Fulfillment Solutions

Service Fulfillment

Order Management Inventory BSS/OSS

Ad-hoc Network Integration

•  Complexity barrier

•  Stovepipe adaptors •  Scripting

•  No portability •  No standardization


Programmability Issues

•  Manual, per-device configuration •  Slow and error prone

•  Lack of well defined network API •  Many sources of configuration

•  Change driven by individual network engineers

•  60-90% valid data

Order Management

Service Activation Inventory


Tail-f NCS Overview

Device Models Network Element Drivers

Device Manager

Service Manager

NSO Service Models

Networkwide CLI and Web UI REST, NETCONF, Java, etc.

Network Engineer

Management Applications

NETCONF, CLI, SNMP, REST, etc.

•  Logically centralized network services

•  Data models for data structures •  Structure representations of:

  Service instances   Network configuration and state

•  Mapping service operations to network configuration changes

•  Transactional integrity •  Multiprotocol support •  Multivendor support

Network Services Orchestrator enabled by Tail-f

7


Modular Architecture Mapping to ETSI NFV Framework

8

VMware 3rd Party SDN

VNF Manager

OSS/BSS Customer Facing

Services (CFS) Service Catalog

Cisco Network Services Orchestrator enabled by Tail-f

VNF Library (sample list)

SP’s Existing OSS/Catalog

OpenStack

CSR1kv CSR1kv CSR1kv NF F

3rd Party VNF ASAv ASAv ASAv

QvPC SI QvPC SI QvPC SI QvPC DI QvPC DI QvPC DI

Virtual Infra. Managers (VIM)

NFV Orchestrator

Resource Facing Services (RFS)

Service Lifecycle Management Service Provisioning

APIC Cisco Virtual Topology

Controller

(Compute and Storage VIMs)

3rd party VNFM

Cisco VNF Manager (ESC, CTCM)

REST/NETCONF/YANG

NFV Infra (NFVI)

(Network VIMs)

OVS/

3rd party

Virtual Topology Forwarder

http://www.etsi.org/technologies-clusters/technologies/nfv


NETCONF & YANG


NETCONF – A Protocol to Manipulate Configuration •  IETF network management protocol created on industry input

•  Distinction between configuration and state data

•  Multiple configuration data stores (candidate, running, startup)

•  Configuration change validations

•  Configuration change transactions

•  Selective data retrieval with filtering

•  Streaming and playback of event notifications

•  Extensible remote procedure call mechanism

Why you should care: NETCONF provides the fundamental programming features for comfortable and robust automation of network services

10


NETCONF By RFC

•  NETCONF 1.1 •  RFC 6241 – 1.1 Base NETCONF Protocol (1.0 defined in RFC 4741) •  RFC 6242 – NETCONF over SSH (1.0 transport defined in RFC 4742)

•  NETCONF Protocol Extensions •  RFC 5277 Notifications •  RFC 5717 Partial Locking •  RFC 6243 With defaults

•  Informational •  RFC 3535 Informational – Background and requirements •  RFC 6244 NETCONF + YANG Architectural Overview


The NETCONF Protocol

•  RPC based client (application) – server (network element) protocol •  Network-wide – a transaction can address multiple network elements in parallel •  Provides multiple operations for interacting with configuration and operational data

•  get-config •  get •  edit-config •  commit •  validate •  copy-config •  discard-changes •  delete-config •  lock •  unlock

•  Provides multiple configuration data stores (candidate, running, startup)


Comparing SNMP and NETCONF SNMP NETCONF

Data Models Defined in MIBs Defined in YANG modules (or XML schema documents)

Data Modeling Language Structure of Management Information (SMI)

YANG (and XML schema)

Management Operations SNMP NETCONF

RPC Encapsulation Basic Encoding Rules (BER) XML

Transport Protocol UDP TCP (reliable transport)


What is YANG? •  YANG is a modeling language defined in RFC 6020 •  Used by NETCONF to define the objects and data in requests and

replies

•  Analogous to XML schema and SMI for SNMP (but more powerful)

•  Models configuration, operational, and RPC data

•  Provides semantics to better define NETCONF data •  Constraints (i.e., “MUSTs”) •  Reusable structures •  Built-in and derived types

•  YANG is extensible and modular

•  YANG modules are for NETCONF what MIBs are for SNMP


YANG – A Data Modeling Language for Networking •  Human readable, and easy to learn representation

•  Hierarchical configuration data models

•  Reusable types and groupings (structured types)

•  Extensibility through augmentation mechanisms

•  Supports definition of operations (RPCs) and notification

•  Formal constraints for configuration validation

•  Data modularity through modules and sub-modules

•  Well defined versioning rules

15


Cisco Network Services Orchestrator (NSO) enabled by Tail-f


Cisco Orchestration Implementation •  Tail-f NCS is a proven “horizontal” orchestrator and used in many

deployments providing service agility and automated operations http://www.tail-f.com/deutsche-telekom-selects-tail-f-as-provider-of-software-defined-networking-sdn-in-terastream-project/ http://www.att.com/gen/press-room?pid=25274&cdvn=news&newsarticleid=37439

•  Cisco Network Services Orchestrator (NSO) enabled by Tail-f is a platform addressing hybrid networks – NFV application life cycle – Physical and virtual networks – Service activation (of resource facing services) – Multi-vendor


NSO Main Features

NSO

18

* Patent No.: US 8,533,303 B2

•  In-memory storage of configuration states for all services and all devices

•  Model-based architecture

•  Transactional guarantees

•  FastMap* algorithm for service-layer CRUD operations

•  Reactive FastMap*

* Patent No.: US 8,533,303 B2

Multi-vendor physical/virtual L2, L3, L4-L7 network


19

YANG data models for

§  Network services

§  Network topology

§  Network devices

YANG data models drive

§  Northbound APIs

§  User interfaces

§  Southbound command sequence

Benefits: §  Can be used for all types of services

and all types of networks

NSO Main Feature 1: Model-Based Architecture

NSO


Service Models

Device Models

OSS/BSS


20

Transactional guarantees:

§  Help ensure fail-safe operations (automated handling of exceptions)

§  Keep accurate copy of network configuration state in NSO at all times

Benefits: §  Automation can be based on

accurate real-time view of service and network state

§  Much higher degree of automation possible

Transactional Integrity

NSO Main Feature 2: Transactional Guarantees

NSO


OSS/BSS


21

NSO

Multi-vendor L2, L3, L4-L7 network

FastMap:

§  Only the CREATE operation needs to be specified

§  UPDATE, DELETE and REDEPLOY operations are automatically generated and compute minimal change set needed

Benefits: §  Reduces service implementation code

by two orders of magnitude

§  Supports modifications of services at runtime

FastMap*

* Patent No.: US 8,533,303 B2

CREATE SERVICE UPDATE SERVICE DELETE SERVICE

REDEPLOY SERVICE

NSO Main Feature 3: FastMap* Algorithm


22

Multi-vendor L2, L3, L4-L7 network

Benefits: One algorithm supporting:

§  Provisioning

§  Orchestration

§  Elasticity

§  VM / VNF mobility

§  Self-healing network

FastMap*

CREATE SERVICE UPDATE SERVICE DELETE SERVICE

Changed network state triggers service redeploy

REDEPLOY SERVICE

NSO Main Feature 4: Reactive FastMap*

NSO

* Patent No.: US 8,533,303 B2


NSO Architecture Overview

Service Manager

Network Engineer

NETCONF REST CLI Web UI JSON RPC JAVA

OSS/BSS

NSO

AAA Core Engine

Network Element Drivers

Mapping Logic

Fast Map

Device Manager Notification Receiver Alarm Manager

Service Models

Package Manager

Script API

Device Models

Developer API

Mapping Templates


Current Vendor Support Vendor Device/Platform

A10 Networks ACOS (AX Series AXSoftAX (VM))

Accedian MetroNID (AMN-1000-TE)

Adtran Total Access 924e (2nd Gen)

Adva FSP150CC-825, FSP150CCf-815

Affirmed Networks Acuitas EMS

Alcatel-Lucent SR OS (7210, 7705, 7450, 7750) SAM 5620

Allied Telesis CentreCOM x210

Arista EOS (DCS 7150-series)

Avaya VSP 9000-, SR 8000- and ERS 4000-series

Brocade MLXe-4, Vyatta Plus

CableLabs CCAP

Ciena ESM, ASOS (5150, 5140)

Cisco ASA-OS ASAv IOS C3500, 2800-, 7000-, ASR900-, ME3K-, Catalyst 2900-, Catalyst 3750-E-, Catalyst 4500-, ISR 800-Series IOS XE ASR1001, CSR1000V IOS XR ASR9K-series, IOS-XRv

Vendor Device/Platform

Cisco NX-OS 1000, 3000, 5000, 6000, 7000, 9000 series, 1000v PNR PNR >= 8.1 QPS QPS 7.0.0.5 StarOS ASR 5K Series UCS UCS 2.2.1

Clavister cOS Core

Dell Force10 FTOS (S4810)

Ericsson EFN324C, Redback SE

F5 Networks BIG-IP FW, LB, LTM 1600, LTM VM

Fortinet FortiOS (Fortigate 3240C, 200B-BDL, VM02)

H3C Comware (S5800)

Huawei Quidway S3300

Infinera DTNX

Juniper Junos (MX, SRX, etc.) Contrail

NEC iPASOLINK 400

Nominum DCS

Openswitch OVSDB (shell command)

Vendor Device/Platform

Overture 1400, ISG2200, ISG5000, ISG5100, ISG5500, ISG6000

Palo Alto Networks

PAN-OS (PAN-PA-2020, PAN-PA-3050, PAN-VM-200)

Pulsecom SuperG

Quagga BGP

Riverbed Steelhead CXA 1555-B010, Virtual Steelhead VCX-1555-M

Sonus SBC 5x00


Example: NSO in mobility


Mobility Solution Stack

X86 X86 Hardware (NFVI)

IaaS (VIM)

VNF Orchestration & IaaS Abstraction (VNFM)

X86 X86 X86

End to End Service Orchestration (NFVO) Cisco NSO

+ Mobility Function Pack

Cisco Telco Cloud Manager (CTCM)

VMware OpenStack

Cisco QvPC SI

Cisco QvPC DI


Instantiate QvPC-DI Full Instance

Request for new QvPC-DI

VNFM build out QvPC-DI VM systems

QvPC CF system

QvPC SF system

VM’s Built and ports configured

All VM types are started

VNFM Pings CF to see if it is up

SF VM systems netboot from CF

Admin User (OSS) NSO CTCM VIM (VMware/

OpenStack)

Delivers config profile, for QvPC instantiation

VNFM Compares VM inventory with CF’s list

SF VM systems booted, notify CF

System initialization status reported back to user

CF’s start booting

StarOS CLI available

CF’s detect system boot complete and apply 0 day config

NSO validates QvPC specific data from the QvPC VNF descriptor files: •  Number of SF’s, chassis

name, admin password, etc. •  Checks for resources and

reserves them accordingly

Request validation and resource checking and

reservation


Key Takeaways


Integrated End-To-End Orchestration

VNF1 VNF2 VNF1

EMS EMS EMS

EMS

BSS/OSS

NFV INFRASTRUCTURE (Compute, Storage, Network)

EMS EMS EMS

Network Domain Controllers

DC WAN CPE

Cisco Network Services Orchestrator enabled by Tail-f

VNF Manager(s)

Virtualized Infrastructure Manager(s)

VNF3

DC VTS, ODL, APIC

WAN WAE

CPE Meraki

VM Life-cycle AND

Service Activation

Virtual AND

Physical

ESC, CTCM, & 3rd Party

OpenStack, VMware

VNF2


Useful links

Education:

http://www.tail-f.com/education/

Documentation:

http://www.tail-f.com/network-control-system/


Q & A

Internet

PLNOG14: Service orchestration in provider network, Tail-f - Przemysław Borek