State-Based Network Management Resource Allocation using Web Services

1. State-Based Network ManagementResource Allocation using Web Services John C. Hoag, Ph.D. Ohio University

2. SBNM • We have a habit of presuming the availability of infrastructure on our way to studying QoS, security, performance. • FCC data indicate that infrastructure reliability is actually decreasing (Snow). • Market is not forcing development of automation to re-provision substrates • Because layered architecture masks issue • Grand challenge in interoperability which was has been met in SONET, not in FR, ATM, MPLS. ICTSM13 November 19, 2005

3. Outline of Presentation • Review of origin of project: electric grid • Explication of TNM research/practice gap • Service Oriented Architecture Intro • Functionality of SBNM • Architecture of SBNM • Conclusions and future work • Project Resources ICTSM13 November 19, 2005

4. Brief Background • Assessment of US electric blackout, August 2003 revealed extensive state modeling of grid topology, flows, and security. • Paradigm for telecom network management (TNM) is divided between OSS/BSS administrative functions and standards-based fault monitoring, correlation, and diagnosis (cf. SNMP). • Hayes-Roth paper on Model Communication Networks at ICTSM12, introduced VIRT. • SBNM MILCOM2005 paper with W2COG ICTSM13 November 19, 2005

5. U.S. Electricity Transmission Grid as Example use of State • Context: local distribution monopolies, wholesale competitive generation • Regional transmission (grid) operator • Manages hourly market in bulk power • Optimize sales s.t. KCL, component outage-list • Incorrect to reason that any pairs of firms can transact without regard to location • Entities redraw topology and estimate flows • RTO may shed load, reject orders, control generation • Leading RTO has XML-RPC SOA • To publish operating data and to transact orders ICTSM13 November 19, 2005

6. Telecom Net ManagementCurrent Capabilities • SNMP v.2, v.3: trap, Get, Put, Next, Walk • Event driven or polled • Open and proprietary MIBs • Event correlation (filtering) available • Hierarchical - can manage element managers • Little topology capture, basically manual; no adaptation • Operational Support Systems • Preorder/Order, Provisioning, Inventory, Maintenance/Repair, Billing, Customer Information • TCA96 271 forced interoperability via EDI, user web ICTSM13 November 19, 2005

7. Service Oriented Architecture • Functional interoperability among applications • Browserless exchange of marked-up docs • XML tagging, RPC, SOAP • Common metadata, seeking shared ontologies per domain (cf. OASIS Consortium) • Tighter functional integration than mere interconnection, file sharing (including EDI), remoting including windowing, APIs • Usage: “to expose an interface as a service” ICTSM13 November 19, 2005

8. SBNM Functional View • Expand TNM in the following dimensions • Store applications requirements, location-referenced • Expose carrier/provider service inventory • Store state: resources provisioned for specific instance of geo-referenced app requirements • Capability to achieve and maintain state via • Terse interaction with telemetry layer • Service-level interactions with providers • These capabilities are not present in L3 and L1 suites from HP, Cisco, Lucent, etc., for WAN infrastructure. Can capability roll out for MPLS? ICTSM13 November 19, 2005

9. SBNM Context • Dedicated transport services, physical or logical circuits; to emphasize aggregated services initially, rather than subscribers • Point-to-point, end-to-end • Defies cross-layer independence (Clark) • “App-aware network” “Net-aware Apps” • Recognizes existing remedies at L4 (TCP), L3 (Routing), L2 (ARQ), L1 (protection). • Grand challenge: mobility; ad hoc groups ICTSM13 November 19, 2005

10. SBNM (Hoag) Requirements Demand Registry Subscription Registry, Provisioning SNMP / OSS Managers Inventory Registry NNM Telemetry SBNM Engine Subscriber to VIRT Engine Resource Re-Allocation SOA TNM Ontology initiated MCN (Hayes-Roth) Planning Toolset Plan Generator Information Registry Track Condition Monitor VIRT Engine Plan Updater SOA Ontology effort identified How SBNM & MCN Correspond ICTSM13 November 19, 2005

11. SBNM Architecture ICTSM13 November 19, 2005

12. SOA Interfaces in SBNM • Demand Side • SBNM subscribes to requests • SBNM advertises provisioned services • Supply Side • SBNM subscribes to provider inventory • SBNM transacts requests for resources [OVSA] • Condition Monitoring • SBNM subscribes to publication of topology-altering events [HPOV NNM, Nagios] ICTSM13 November 19, 2005

13. SBNM Relevance to NCOW • Through W2COG, a W3C for the grid • “Incubator” of Valued Information at the Right Time • SBNM design incorporates VIRT reasoning • Reference Architecture, code primitives • SBNM can contribute to practical mission threads • Navy ADNS IP WAN, NCO GCCS • Net Infrastructure dynamics can be an element of anticipated MCN / VIRT use case, to be funded. • SBNM project trajectory can accelerate due to presence of SNMP and OSS components ICTSM13 November 19, 2005

14. Conclusions and Future Work • Perceived requirement to integrate and add intelligence to TMN concept, especially for high-consequence environments. • Gap in practice, gap in “vision” to invest in, absent market forces and COTS orientation • Potential to piggyback development with emerging platforms and services. • Still a high cost threshold -- limiting SBNM to carriers/providers and enterprises with plant or physically not past the edge of network cloud. ICTSM13 November 19, 2005

15. SBNM Project Resources http://www.csm.ohiou.edu/sbnm • MILCOM, ICTSM papers and presentations • Annotated Bibliography • NCO, definitive NRC/NSF report empanled with Dr. Gavish • VIRT, Dr. Hayes-Roth, NPS Monterey • SBNM • Worldwide Consortium for the Grid, www.w2cog.org • Ontology development (Protégé): RDFs when avail. • Code Primitives (Nagios) • Dr. John Hoag, hoagj@ohiou.edu ICTSM13 November 19, 2005