A lightweight OSS/BSS architecture Moving up the value chain in operations Afrodite Sevasti 6th Service and Technology Forum Paris, 3-4th November 2015
Wish list • A lightweight OSS/BSS architecture – Basic principles – Technologies, best practices and standards • The architecture in action: L2 VPN provisioning • Demo • Conclusions 2
• Core partner in pan-EU e-Infrastructures: GÉANT, EGI, PRACE, EUDAT and global collaborations (CHAIN-REDS) • Delivery of an extensive portfolio of advanced ICT services to institutions and end-users • Technology-oriented community building & wide scale dissemination activities • Consulting/infrastructure/service operations for the public sector 4
L1 – L2 VPN on demand – L1 optical trails (OTN) on demand • High Performance Computing – National HPC Infrastructure – HPC services • Middleware – Digital Certificate Services – AAI and federated AAI (eduGAIN) • Security – CSIRT/CERT services – Coordination of incident handling with national authorities – Firewall on demand – Flow-based monitoring as a Service – SIEM as a Service – IDS/IPS as a Service • IaaS/Cloud computing – VM and cloud services – Virtual Machines service (ViMa) – Virtual private servers on demand – ~okeanos cloud services – VMs on demand – Storage services • Applications – HD Video Conferencing (more than 15K meetings held) – epresence – Live Streaming (~27.000 subscribers) – e-Voting (ZEUS) – Adacemic IDs
– Direct access to individuals – Multiple levels of customer relations within institutions • NOCs and service managers • *-as-a-Service – VPN as a Service – Server as a Service – Firewall as a Service – Flow monitoring as a Service – ... • Composite services/service bundling • Rapid uptake of services 6
Order management Orchestration Composable services Service assurance SLA management Re-usability of OSS capabilities User analysis and retention Reduced system integration efforts Targeted marketing Accounting Integration with other SPs and e- Infras ?
is changing to… Ticket X affects services Y, Z Resource X is generating event/alarm Y Elastic service X requests Y virtual servers Quality performance data for resource X is required Service X is unreachable, which is the root cause?
C silo Service D silo OSS ecosystem: infrastructure services ECI Lightsoft SPACE Monit oring Service-specific support systems Stats Provisioning Provisio ning Self-service Monitoring Service CRM Self- service Provisioning Moni- toring Vendor –specific provisioning system/ API Provi- sioning Self- service Self- service SLA mgmt Business support
and service oriented • Isolate operations from business services • Standards’ based A coherent data model (‘vocabulary’) Reusable APIs Orchestration – Multi-domain, multi-tenant services – Service bundles Consistency in inter-module communication – Reliable, ‘any-to-any’ One-stop shop for services 11 Manage services on top of resources Consolidate processes & systems
No data translation between systems • Low integration costs • Well-designed integration interfaces Common/standard information model (SID) • Using a single interface infrastructure • Applying the same patterns across multiple technologies • Supported by several NMS, OSS components in the market Multi-Technology Operations Systems Interface (MTOSI) • Service Management & Operations • Resource Management & Operations Business Process Framework (eTOM) • Enterprise Service Bus Common Communications Vehicle • Orchestration middleware Workflow Engine Data modelling Interfaces Processes Communication Orchestration Frameworx
NetworkTroubleTicket entity Comments Mandatory in RFC PARTNER_ID Partner[i].Organization.PartyId Partner[i].InteractionRole="Owner" The unique ID of the TT source partner Y ORIGINAL_ID EntityIdentifier.OriginalId The TT ID that was assigned by the party Y TT_ID EntityIdentifier.Id The unique ID of the TT Y TT_TITLE Title The title of the TT Y TT_SHORT_DESCRIPTION ShortDescription The short description of the trouble Y TT_TYPE TroubleTicketType The type of the TT Y TT_STATUS TroubleTicketState The TT status Y TT_SOURCE Source The source of the ticket TT_IMPACT_ASSESSMENT ImpactAssessment The impact of the incident/maintenance Y TT_OPEN_DATETIME InteractionDate Date and time when the TT was opened Y TT_CLOSE_DATETIME InteractionDateComplete Date and time when the TT was closed Y TT_LAST_UPDATE_TIME LastUpdateDateTime Last date and time when the TT was updated Y START_DATETIME MaintenancePeriod.StartDateTime Date and time that the incident/maintenance started Y END_DATETIME MaintenancePeriod.EndDateTime Date and time when the incident/maintenance ended Y LOCATION TroubleTicketItem.Service.ServiceAccessPoint/G eographicAddress The location (Point of Presence (POP) site, city, etc.) of the incident/maintenance NETWORK_LINK_CIRCUIT TroubleTicketItem.Service.EntityIdentifier.Id Network line related to the incident END_LINE_LOCATION_A TroubleTicketItem.Service.ServiceAccessPoint/G eographicAddress A-end of the link END_LINE_LOCATION_B TroubleTicketItem.Service.ServiceAccessPoint/G eographicAddress B-end of the link
systems – Resource Trouble Management: Communication of alarms – Managed Resource Inventory: Communication of inventory information – Resource Provisioning: Creating, modifying, and deleting network resources – Resource Performance Management: Resource performance monitoring and control (e.g. threshold crossing alerts) • Service Management & Operations between systems – Service Configuration & Activation interfaces – Manage Service Inventory, supporting bulk inventory retrieval (with filters) between 18 Source: https://www.tmforum.org/mtosi/
applications/systems • Mediation services • Standardization – Unifies data encapsulation and transportation syntaxes under TMF notation • Reliability: Fault tolerance, load balancing and high availability • Stateless: Embedding the state of the message into the message itself 20 Middleware Service Bus OSS BSS
can access any service provider - from any platform • Loose Coupling: Mediation between a service provider and a service consumer • Location Transparency • Easily use more than one type of communication protocol (although current implementation is built around the concept of asynchronous web services). • Message routing: Forking and aggregating message flows, static/deterministic routing, content-based routing, rules-based routing, policy-based routing etc. • Message Exchange Patterns: synchronous request/response, asynchronous request/response etc. • Message Throttling • Performance: Stateless & lightweight. • Support for Event Driven Architecture • Monitoring, Auditing and Logging of all service producer/consumer interactions and their messages. • Java framework: standard enterprise integration patterns in a few lines of code. • With a concise but sophisticated DSL, snap integration logic into your app • Supports over 80 common transports such as HTTP, REST, JMS, and Web Services 21
issue tracking support systems – Feasibility, fulfillment, monitoring orders – Orchestration of actions to fulfill • Order data validation-enrichment • Orchestration plan – Managing sequence and dependencies • Invokes fulfillment systems • Order state owner – Tracks order’s state and history – Make information available to other systems 22
offers to be fulfilled as part of an order – Create, Update, Delete • Order item bundling – e.g. a group of Teleconferencing sessions to deliver a Teleconference service • Dependencies • Multiple instances 23
concept of a state machine – backed by Alfresco • Lightweight database model and multi-database support • Robust REST API • Standard BPMN2.0 • Visual modeling • Auto-versioning 24
• Self-service, requests and incidents Service Operations • Business rules e.g. for escalation • Incident-to-configuration-item correlation • Event management SLA definition and management • Service and support level agreements • User-driven verification Service dependencies, bundling, chaining Knowledge management Service inventory – configuration management Service-oriented reporting
Simplified TMF resource/infrastructure operations Self- service Service A Self-service Service B Self-service Service C CRM Service Management Simplified TMF service operations OSS layer BSS layer A Vendor management system/ API Service-specific support systems Provisioning A Resource monitoring services Resource inventory services Moni- toring C Provi- sioning C Provi-sioning B Middleware Service Bus Service Bus
GRNET S.A. is required to deliver on-demand L2 VPNs to its end users in coordination with campus NOCs 28 IP Network Client Data Center B Data Center A Carrier Network Access Network MPLS MPLS MPLS MPLS MPLS MPLS MPLS CPE CPE IP MPLS IP MPLS Client Client Client
.1q, any .1q) – Permission to rewrite VLAN IDs – Use of a existing port or provisioning of a new one – MTU size – VLAN id • Challenges – Multi-party provisioning – Seamless experience to the user – Integration with established operational processes – Reliable provisioning at the OSS layer – Reconciliation of service design parameters 29 End-user or campus NOC requests a L2 VPN between a local site and a remote end-user site or campus
Core Simplified TMF L2VPN resource order L2 VPN Inventory Middleware Service Bus Service Bus Monitoring service L2 VPN service monitoring L2 VPN Self-Service Portal Simplified TMF L2VPN service order CRM User request Service Management Platform (one-stop-shop) Service SLA mgmt AAI Connector Service - configurations
VPN Inventory Middleware Service Bus Service Bus Monitoring service L2 VPN Self-Service Portal Simplified TMF L2VPN service order CRM User request Service Management Platform (one-stop-shop) Service SLA mgmt AAI Connector Service - configurations L2 VPN service monitoring L2 VPN Support Systems: 10k ft view
set of RESTful interfaces + websocket-based notifications – Custom SSP frontend • Requires implementation effort • Common APIs though – Backend built as a set of four projects: models, utilities, generic SSP, VPN module • One can reuse the first three, build a new service- specific module as needed • OSS: L2 VPN Provisioning module – Split in two: • Provisioning core reusing models & utilities from the respective SSP projects • Thin connector invoking Juniper's py-junos-eznc – Configuration via two-phase-commit • Load configs to ensure correctness • Commit on every device 35
services, developing product-specific ones Isolate operations from business services Service vs. resource provisioning Standards’ based Processes (e.g. order management) and models Coherent data model Simplified TMF SID Reusable APIs Shared models and operations (base, order, service, resource) Orchestration Inter-system workflows, manual tasks Consistency in inter-module communication Service Bus One-stop shop for services Service management platform at the BSS layer
Inventory Middleware Service Bus Service Bus Lightpath Self- Service Portal Simplified TMF Lightpath service order CRM User request Service Management Platform (one-stop-shop) Service SLA mgmt AAI ECI LightSoft NMS Lightpath service Adaptor
jacobtomlinson
aki_iinuma
bkeepers
reverentgeek
carmenintech
aleyda
tammielis
szymonslowik
nonsquared
minecr
matthewcrist
