Reading Exercise Policy Signaling, Programming Network Elements Special Topic: Software Defined Networks Rudra Dutta Computer Science, NCSU

Policy, Management, Programming Policy – a reflection of arbitrary intent Typically arising from non-technology considerations Unlike settings/parameters (often optimizing efficiency or other operational considerations) Network management – process of enacting policy for network Through policy interface of box, if any Through settings interface of box (network-level policy) FCAPS “Programming” a network box Can only program capabilities box offers Programming the box versus programming the network Can program system (set network-level policy) by adjusting settings of components (coordinated configuration of box-level settings) Copyright Rudra Dutta, NCSU, Spring 2017

Network Management System Control Control Control Policy/Mgmt/Knowledge Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Copyright Rudra Dutta, NCSU, Spring 2017

Network Management System A coordinated system of tools, and related interfaces, that allows network managers/engineers to monitor and administer/manage/control individual network elements, to meet predefined network-level goals Much of the operation of network control is (must be) automated – usual/common cases Much of the rest requires human oversight/intervention – centralized at NOC Copyright Rudra Dutta, NCSU, Spring 2017

Management Cycle and Design Reactive Protocol Design Algorithm Design Near Real-Time Resource Design Capacity Mgmt, Netw Engg. Network Planning Copyright Rudra Dutta, NCSU, Spring 2017

NMS Information Flow NMS acts as a complicated algorithm Input information Network status, health of elements and components “Live” information about traffic, flows, demands Other operational information Gathered by devices monitoring self and peers  control signaling Processing Detect/predict performance, policy, stability problems Decide on configuration changes if any Output information Any operational changes to be enacted Device configuration changes to enact them “Re-program” network Copyright Rudra Dutta, NCSU, Spring 2017

Input and Output “Language” Language, protocol, standardization Sometimes premature First need “communication objectives” “What can be said by NE to NMS?” “What are measurable quantities pertaining to NE?” Varies between NE  exercise becomes one of meta-language (how to speak) “What can be said to NE by NMS?” “What does NE do, and what can it change about what it does?” Variable, but commonalities on the most frequent capabilities  forwarding decision  routing policy Copyright Rudra Dutta, NCSU, Spring 2017

SNMP (RFCs 1156, 1157) Each managed device runs an SNMP agent that reports status to NMS Bidirectional allowed in standard, but less in practice A device/NE may have multiple managed components, each with agent AgMo MIB (treated as usual by SNMP) Agent is intentionally designed to be minimal Runs on UDP Information from agents largely solicited (polls) and some unsolicited (traps) Request, response, and trap PDUs Chaining of request and response PDUs allows small PDU size to be used for much larger logical requests/responses Copyright Rudra Dutta, NCSU, Spring 2017

MIB Copyright Rudra Dutta, NCSU, Spring 2017

Measurement and Monitoring Measurement can be seen as a generalization of status Can provide information of device scope, but also of larger scope, e.g. path bottleneck bandwidth Broadens further the variety of information that can be sent Techniques needed for actual measurement, but these are embedded in devices (“how”) Must be able to communicate  need agreement on “language” Copyright Rudra Dutta, NCSU, Spring 2017

netflow Proprietary, but originally accepted by community Copyright Rudra Dutta, NCSU, Spring 2017

IPFIX (RFCs 7011, 7012) Copyright Rudra Dutta, NCSU, Spring 2017

perfSONAR Copyright Rudra Dutta, NCSU, Spring 2017

NE Capabilities What does an NE do? Necessary precursor to: In turn: “What aspects of it can be controlled?” In turn: “What vocabulary is necessary in a language (signaling protocol) to exercise that control?” Reverse approach: design language for most common capabilities and control Insist NEs should not do any more Insist NEs should use default settings Allow (assume) NEs will exercise own judgement in configuring extra capabilities Design separate management system for extra capabilities Hierarchical approach Design meta-language to allow NE to declare capabilities Hand over to appropriate management module Copyright Rudra Dutta, NCSU, Spring 2017

Forwarding Foremost choice: forwarding decision (interface) Further choices: To forward or not (special case) Buffering class, priority Scheduling class, specifications for each level of scheduler Treat as data plane or control plane Some routers participate in OSPF and some do not OSPF packets may have to traverse both Copyright Rudra Dutta, NCSU, Spring 2017

Header Space Which header(s) does an NE base its decision/operation on? Possibly single layer – DLC Multiple layer “Isolated components” view Cross-layer view Payload ?! Deep packet inspection Borderline of what potentially could be standardized – “wild west” of management Copyright Rudra Dutta, NCSU, Spring 2017

Passive versus Active Header space choices with active operation Passive NE operation Capability: forward (or not) Monitor: observe traffic, measure or conclude value of some metric Active NE operation Monitor: inject “probe” or “test” traffic, control signals  observe results Capability: transform traffic, generate (replicate or otherwise) traffic Opens up NE to completely arbitrary behavior (and management requirement) Header space choices with active operation Copyright Rudra Dutta, NCSU, Spring 2017

SFC (RFCs 7498, 7665) Copyright Rudra Dutta, NCSU, Spring 2017