Lect12-13_MS_Networks.pptx

Computer Networking: A
Top-Down Approach
8th edition
Jim Kurose, Keith Ross
Pearson, 2020
Chapter 5
Network Layer:
Control Plane
A note on the use of these PowerPoint slides:
We’re making these slides freely available to all (faculty, students,
readers). They’re in PowerPoint form so you see the animations; and
can add, modify, and delete slides (including this one) and slide content
to suit your needs. They obviously represent a lot of work on our part.
In return for use, we only ask the following:
 If you use these slides (e.g., in a class) that you mention their
source (after all, we’d like people to use our book!)
 If you post any slides on a www site, that you note that they are
adapted from (or perhaps identical to) our slides, and note our
copyright of this material.
For a revision history, see the slide note for this page.
Thanks and enjoy! JFK/KWR
All material copyright 1996-2020
J.F Kurose and K.W. Ross, All Rights Reserved

Note to students
Network Layer: 5-2
 At the end of each section
• There will be review questions
 Be attentive and mentally present during class so that
• You can answer those questions

Network layer: “control plane” roadmap
 network management,
configuration
• SNMP
• NETCONF/YANG
 introduction
 routing protocols
 intra-ISP routing: OSPF
 routing among ISPs: BGP
 SDN control plane
 Internet Control Message
Protocol
Network Layer: 5-3

 Internet network layer: historically implemented via
distributed, per-router control approach:
• monolithic router contains switching hardware, runs proprietary
implementation of Internet standard protocols (IP, RIP, IS-IS, OSPF,
BGP) in proprietary router OS (e.g., Cisco IOS)
• different “middleboxes” for different network layer functions:
firewalls, load balancers, NAT boxes, ..
 ~2005: renewed interest in rethinking network control plane
Software defined networking (SDN)
Network Layer: 5-4

Per-router control plane
Individual routing algorithm components in each and every router
interact in the control plane to computer forwarding tables
Routing
Algorithm
data
plane
control
plane
1
2
0111
values in arriving
packet header
3
Network Layer: 4-5

Software-Defined Networking (SDN) control plane
Remote controller computes, installs forwarding tables in routers
data
plane
control
plane
Remote Controller
CA
CA CA CA CA
1
2
0111
3
values in arriving
packet header
Network Layer: 4-6

Why a logically centralized control plane?
 easier network management: avoid router misconfigurations,
greater flexibility of traffic flows
 table-based forwarding (recall OpenFlow API) allows
“programming” routers
• centralized “programming” easier: compute tables centrally and distribute
• distributed “programming” more difficult: compute tables as result of
distributed algorithm (protocol) implemented in each-and-every router
 open (non-proprietary) implementation of control plane
• foster innovation: let 1000 flowers bloom
Network Layer: 5-7

SDN analogy: mainframe to PC revolution
Network Layer: 5-8
Vertically integrated
Closed, proprietary
Slow innovation
Small industry
Specialized
Operating
System
Specialized
Hardware
Ap
p
Ap
p
Ap
p
Ap
p
Ap
p
Ap
p
Ap
p
Ap
p
Ap
p
Ap
p
App
Specialized
Applications
Horizontal
Open interfaces
Rapid innovation
Huge industry
Microprocessor
Open Interface
* Slide courtesy: N. McKeown
or or
Open Interface
Windows Linux MAC OS

2
2
1
3
1
1
2
5
3
5
v w
u z
y
x
Traffic engineering: difficult with traditional routing
Network Layer: 5-9
Q: what if network operator wants u-to-z traffic to flow along
uvwz, rather than uxyz?
A: need to re-define link weights so traffic routing algorithm
computes routes accordingly (or need a new routing algorithm)!
link weights are only control “knobs”: not much control!

2
2
1
3
1
1
2
5
3
5
v w
u z
y
x
Network Layer: 5-10
Q: what if network operator wants to split u-to-z
traffic along uvwz and uxyz (load balancing)?
A: can’t do it (or need a new routing algorithm)

Network Layer: 5-11
Q: what if w wants to route blue and red traffic differently from w to z?
A: can’t do it (with destination-based forwarding, and LS, DV routing)
2
2
1
3
1
1
2
5
3
5
v w
u z
y
x
We learned in Chapter 4 that generalized forwarding and SDN can
be used to achieve any routing desired

Software defined networking (SDN) –
Four key characteristics of an SDN architecture
Network Layer: 5-12
data
plane
control
plane
Remote Controller
CA
CA CA CA CA
1: generalized “flow-based”
forwarding (e.g., OpenFlow)
2. control, data
plane separation
3. control plane functions
external to data-plane
switches
…
routing
access
control
load
balance
4. programmable
control
applications

 Flow-based forwarding
• Packet forwarding by SDN-controlled switches can be based on any number of header field
values in the transport-layer, network-layer, or link-layer header
 Separation of data plane and control plane
• data plane consists of the network’s switches— relatively simple (but fast) devices that
execute the “match plus action” rules in their flow tables
• control plane consists of servers and software that determine and manage the switches’ flow
tables
 Network control functions: external to data-plane switches
• control plane consists of two components—an SDN controller (or network operating system)
and a set of network-control applications
• controller maintains accurate network state information (e.g., the state of remote links,
switches, and hosts); provides this information to the network control applications running in
the control plane; and provides the means through which these applications can monitor,
program, and control the underlying network devices
• Although the controller in next slide [Book Figure 5.14] is shown as a single central server, in
practice the controller is only logically centralized; it is typically implemented on several
servers that provide coordinated, scalable performance and high availability
Four Key characteristics of SDN architecture
Network Layer: 5-13

 A programmable network
• network is programmable through the network control applications running in the
control plane
• these applications represent the “brains” of the SDN control plane, using the APIs
provided by the SDN controller to specify and control the data plane in the network
devices.
 For example
• routing network-control application might determine the end-end paths between
sources and destinations (e.g., by executing Dijkstra’s algorithm using the node state
and link-state information maintained by the SDN controller)
• another network application might perform access control, that is, determine which
packets are to be blocked at a switch
• yet another application might have switches forward packets in a manner that
performs server load balancing
Four Key characteristics of SDN architecture
Network Layer: 5-14

Network Layer: 5-15
Data-plane switches:
 fast, simple, commodity switches
implementing generalized data-plane
forwarding (Section 4.4) in hardware
 flow (forwarding) table computed,
installed under controller supervision
 API for table-based switch control
(e.g., OpenFlow)
• defines what is controllable, what is not
 protocol for communicating with
controller (e.g., OpenFlow)
data
plane
control
plane
SDN Controller
(network operating system)
…
routing
access
control
load
balance
southbound API
northbound API
SDN-controlled switches
network-control applications

Network Layer: 5-16
SDN controller (network OS):
 maintain network state
information
 interacts with network control
applications “above” via
northbound API
 interacts with network switches
“below” via southbound API
 implemented as distributed system
for performance, scalability, fault-
tolerance, robustness
data
plane
control
plane
SDN Controller
…
routing
access
control
load
balance
southbound API
northbound API

Network Layer: 5-17
network-control apps:
 “brains” of control:
implement control functions
using lower-level services, API
provided by SDN controller
 unbundled: can be provided by
3rd party: distinct from routing
vendor, or SDN controller
data
plane
control
plane
SDN Controller
…
routing
access
control
load
balance
southbound API
northbound API

 SDN represents significant “unbundling” of network functionality
• data plane switches, SDN controllers, and network-control applications are separate entities
that may each be provided by different vendors and organizations
 This contrasts with the pre-SDN model in which
• switch/router (together with its embedded control plane software and protocol
implementations) was monolithic, vertically integrated, and sold by a single vendor
 This unbundling of network functionality in SDN can be compared with
• earlier evolution from mainframe computers (where hardware, system software, and
applications were provided by a single vendor) TO
• personal computers (with their separate hardware, operating systems, and applications)
 The unbundling of
• computing hardware, system software, and applications has led to a rich, open ecosystem
driven by innovation in all three of these areas
 One hope for SDN is that
• it will continue to drive and enable such rich innovation
SDN – Unbundling of network functionality
Network Layer: 5-18

 SDN control plane divides broadly into two components
• SDN controller and the SDN network-control applications
 Many SDN controllers have been developed since
• earliest SDN controller [Book Reference Gude 2008]
• see [Book Reference Kreutz 2015] for an extremely thorough survey
 A controller’s functionality can be broadly organized into three layers
• communication layer
• network-wide state-management layer
• interface to network control application layer
 Next slide (Figure 5.15) provides
• detailed view of a generic SDN controller
The SDN Control Plane: SDN Controller and
SDN Network-control Applications
Network Layer: 5-19

Components of SDN controller
Network Layer: 5-20
Network-wide distributed, robust state management
Communication to/from controlled devices
Link-state info switch info
host info
statistics flow tables
…
…
OpenFlow SNMP
…
network
graph intent
RESTful
API
…
Interface, abstractions for network control apps
SDN
controller
routing access
control
load
balance
communication layer:
communicate between SDN
controller and controlled
switches
network-wide state
management layer: state of
networks links, switches,
services: a distributed database
interface to network control
apps layer: abstractions API
Discussion on these layers in next few slides

 Communication layer communicating between
• SDN controller and controlled network devices
 To control the operation of a remote SDN-enabled switch, host, or other device
• protocol is needed to transfer information between the controller and that device
 In addition, a device must be able to
• communicate locally-observed events to the controller
• E.g., a message indicating that an attached link has gone up or down, that a device has just
joined the network, or a heartbeat indicating that a device is up and operational
 Communication between controller and controlled devices cross to be known as
• controller’s “southbound” interface
 In next few slides, we’ll study OpenFlow – A specific protocol that provides this
communication functionality
• OpenFlow is implemented in most, if not all, SDN controllers
SDN Controller – Communication layer
Network Layer: 5-21

 The ultimate control decisions made by the SDN control plane, for
example
• configuring flow tables in all switches to achieve the desired end-end forwarding
• to implement load balancing or
• to implement a particular firewalling capability
 This require that controller have upto-date information about
• state of the networks’ hosts, links, switches, and other SDN-controlled devices
 Since the ultimate aim of the control plane is
• to determine flow tables for the various controlled devices
• a controller might also maintain a copy of these flow tables
 These pieces of information all constitute
• examples of the network-wide “state” maintained by the SDN controller
SDN Controller – Network-wide state-management
layer
Network Layer: 5-22

 The controller interacts with network-control applications through
• its “northbound” interface
 This API allows network-control applications to
• read/write network state and flow tables within the state-management layer
 Applications can register to be notified when
• state-change events occur, so that
• they can take actions in response to network event notifications sent from
SDN-controlled devices
 Different types of APIs may be provided
• Later we’ll study that two popular SDN controllers communicate with their
applications using a REST (request-response interface)
SDN Controller – Interface to the network-control
application layer
Network Layer: 5-23

 It is noted several times that an SDN controller can be considered to be “logically
centralized,” that is,
• controller may be viewed externally as a single, monolithic service
 However, these services and the databases used to hold state information are
implemented in practice by
• distributed set of servers for fault tolerance, high availability, or for performance reasons
 Modern controllers such as Open-Daylight and Open Network operating System
(ONOS) have placed considerable emphasis on
• architecting a logically centralized but
• physically distributed controller platform that provides scalable services and high availability
• We’ll cover an example of controller operation later
 First, however, let’s examine the OpenFlow protocol in next slide
• protocol used for communication between an SDN controller and a controlled device
More on SDN Controllers
Network Layer: 5-24

OpenFlow protocol
Network Layer: 5-25
 operates between controller, switch
 TCP used to exchange messages
• optional encryption
 three classes of OpenFlow messages:
• controller-to-switch
• asynchronous (switch to controller)
• symmetric (misc.)
 distinct from OpenFlow API
• API used to specify generalized
forwarding actions
OpenFlow Controller

OpenFlow: controller-to-switch messages
Network Layer: 5-26
Key controller-to-switch messages
 features: controller queries switch
features, switch replies
 configure: controller queries/sets
switch configuration parameters
 modify-state: add, delete, modify flow
entries in the OpenFlow tables
 packet-out: controller can send this
packet out of specific switch port
OpenFlow Controller

OpenFlow: switch-to-controller messages
Network Layer: 5-27
Key switch-to-controller messages
 packet-in: transfer packet (and its
control) to controller. See packet-out
message from controller
 flow-removed: flow table entry deleted
at switch
 port status: inform controller of a
change on a port.
Fortunately, network operators don’t “program” switches by creating/sending
OpenFlow messages directly. Instead use higher-level abstraction at controller
OpenFlow Controller

SDN: control/data plane interaction example
Network Layer: 5-28
host info
…
…
OpenFlow SNMP
…
network
graph intent
RESTful
API
…
Dijkstra’s link-state
routing
s1
s2
s3
s4
S1, experiencing link failure uses
OpenFlow port status message to
notify controller
1
SDN controller receives OpenFlow
message, updates link status info
2
Dijkstra’s routing algorithm
application has previously registered
to be called when ever link status
changes. It is called.
3
Dijkstra’s routing algorithm
access network graph info, link
state info in controller, computes
new routes
4
1
2
3
4

SDN: control/data plane interaction example
Network Layer: 5-29
host info
…
…
OpenFlow SNMP
…
network
graph intent
RESTful
API
…
Dijkstra’s link-state
routing
s1
s2
s3
s4
link state routing app interacts
with flow-table-computation
component in SDN controller,
which computes new flow tables
needed
5
controller uses OpenFlow to
install new tables in switches
that need updating
6
5
1
2
3
4

OpenDaylight (ODL) controller
Network Layer: 5-30
Network Orchestrations and Applications
Southbound API
Service Abstraction
Layer (SAL)
config. and
operational data
store
REST/RESTCONF/NETCONF APIs
messaging
OpenFlow NETCONF SNMP OVSDB …
Northbound API
Traffic
Engineering …
Firewalling Load Balancing
Basic Network Functions
Enhanced
Services
…
… Forwarding
rules mgr.
AAA
Host
Tracker
Stats
mgr.
Switch
mgr.
Topology
processing
Service Abstraction Layer:
 interconnects internal,
external applications
and services

ONOS controller
Network Layer: 5-31
Network Applications
Southbound API
Northbound API
Traffic
Engineering …
Firewalling Load Balancing
southbound
abstractions,
protocols
OpenFlow Netconf OVSDB
device link host flow packet
northbound
abstractions,
protocols
REST API Intent
ONOS
distributed
core
statistics
devices
hosts
links
paths flow rules topology
 control apps separate
from controller
 intent framework: high-
level specification of
service: what rather
than how
 considerable emphasis
on distributed core:
service reliability,
replication performance
scaling

 hardening the control plane: dependable, reliable, performance-
scalable, secure distributed system
• robustness to failures: leverage strong theory of reliable distributed
system for control plane
• dependability, security: “baked in” from day one?
 networks, protocols meeting mission-specific requirements
• e.g., real-time, ultra-reliable, ultra-secure
 Internet-scaling: beyond a single AS
 SDN critical in 5G cellular networks
SDN: selected challenges
Network Layer: 5-32

 SDN-computed versus router-computer forwarding tables:
• just one example of logically-centralized-computed versus protocol
computed
 one could imagine SDN-computed congestion control:
• controller sets sender rates based on router-reported (to
controller) congestion levels
SDN and the future of traditional network protocols
Network Layer: 5-33
How will implementation of
network functionality (SDN
versus protocols) evolve?

 The communication layer is responsible for the communication between the SDN
controller and those controlled network devices, via a protocol such as OpenFlow
• an SDN controller controls operation of a remote SDN-enabled switch, host, or other devices, and
• device communicates locally-observed events (e.g., message indicating a link failure) to controller
 The network-wide state-management layer provides controller
• up-to-date information about network’s hosts, links, switches, and other SDN-controlled devices
• A controller also maintains a copy of the flow tables of the various controlled devices
 The network-control application layer represents the brain of SDN control plane. The
applications at this layer use
• APIs provided by a SDN controller to specify and control the data plane in the network devices
• For example, a routing network-control application might determine the end-end paths between
sources and destinations
• Another network application might perform access control
Selected Review Question
Network Layer: 5-34
 Describe the main role of the communication layer, the network-wide
state management layer, and the network-control application layer in an
SDN controller.

 Answer: Following is a list of types of messages flow across a SDN
controller’s southbound from the controller to the controlled devices
Configuration: This message allows the controller to query and set a switch’s
configuration parameters
Modify-state: This message is used by a controller to add/delete or modify entries in
the switch’s flow table, and to set switch port properties
Read-state: This message is used by a controller to collect statistics and counter
values from the switch’s flow table and ports
Send-packet: This message is used by the controller to send a specific packet out of a
specified port at the controlled switch
 The recipient of these messages is a controlled packet switch
Network Layer: 5-35
 What types of messages flow across an SDN controller's northbound and southbound APls? Who
is the recipient of these messages sent from the controller across the southbound interface, and
who sends messages to the controller across the northbound interface?

 Answer: Two types of messages from a controlled device to a controller:
• Flow-removed message: Its purpose is to inform controller that a flow table entry
has been removed
• for example, by a timeout or as the result of a received modify-state message
• Port-status message: Its purpose is to inform the controller of a change in port status
 Two types of messages from a controller to a controlled device:
• Modify-state: The purpose is to add/delete or modify entries in the switch’s flow
table, and to set switch port properties
• Read-state: The purpose is to collect statistics and counter values from the switch’s
flow table and ports
Network Layer: 5-36
 Describe the purpose of two types of OpenFlow messages (of your choosing) that are sent from
a controlled device to the controller. Describe the purpose of two types of Openflow messages
(of your choosing) that are send from the controller to a controlled device.

 What is the purpose of the service abstraction layer in the OpenDaylight
SDN controller?
Network Layer: 5-37
 Answer: The service abstraction layer:
 Allows Internal network service applications to
• communicate with each other
 Allows controller components and applications to
• invoke each other’s services and
• subscribe to events they generate
 Provides a uniform abstract interface to
• specific underlying communications protocols in communication layer, including
OpenFlow and SNMP

configuration
• SNMP
• NETCONF/YANG
 introduction
Protocol
Network Layer: 5-38

ICMP: internet control message protocol
Network Layer: 4-39
 used by hosts and routers to
communicate network-level
information
• error reporting: unreachable host,
network, port, protocol
• echo request/reply (used by ping)
 network-layer “above” IP:
• ICMP messages carried in IP
datagrams
 ICMP message: type, code plus
first 8 bytes of IP datagram causing
error
Type Code description
0 0 echo reply (ping)
3 0 dest. network unreachable
3 1 dest host unreachable
3 2 dest protocol unreachable
3 3 dest port unreachable
3 6 dest network unknown
3 7 dest host unknown
4 0 source quench (congestion
control - not used)
8 0 echo request (ping)
9 0 route advertisement
10 0 router discovery
11 0 TTL expired
12 0 bad IP header

Traceroute and ICMP
Network Layer: 4-40
 when ICMP message arrives at source: record RTTs
stopping criteria:
 UDP segment eventually
arrives at destination host
 destination returns ICMP
“port unreachable”
message (type 3, code 3)
 source stops
3 probes
3 probes
3 probes
 source sends sets of UDP segments to
destination
• 1st set has TTL =1, 2nd set has TTL=2, etc.
 datagram in nth set arrives to nth router:
• router discards datagram and sends source
ICMP message (type 11, code 0)
• ICMP message possibly includes name of
router & IP address

 What two types of ICMP messages are received at the sending host
executing the Traceroute program in last slide?
Selected Review Questions
Network Layer: 4-41
 Answer: ICMP warning message
• TTL expired (type 11 code 0) and
• destination port unreachable ICMP message (type 3 code 3)

configuration
• SNMP
• NETCONF/YANG
 introduction
Protocol
Network Layer: 5-42

 autonomous systems (aka “network”): 1000s of interacting
hardware/software components
 other complex systems requiring monitoring, configuration,
control:
• jet airplane, nuclear power plant, others?
What is network management?
Network Layer: 5-43
"Network management includes the deployment, integration
and coordination of the hardware, software, and human
elements to monitor, test, poll, configure, analyze, evaluate,
and control the network and element resources to meet the
real-time, operational performance, and Quality of Service
requirements at a reasonable cost."

Components of network management
Network Layer: 5-44
managed device
managed device
managed device
managed device
managed device
agent data
agent data
agent data
agent data
agent data
managing
server/controller
data
Managing server:
application, typically
with network
managers (humans) in
the loop
Managed device:
equipment with manageable,
configurable hardware,
software components
Data: device “state”
configuration data,
operational data,
device statistics
Network
management
protocol: used by
managing server to query,
configure, manage device;
used by devices to inform
managing server of data,
events.

Network operator approaches to management
Network Layer: 5-45
managed device
managed device
managed device
managed device
managed device
agent data
agent data
agent data
agent data
agent data
managing
server/controller
data
CLI (Command Line Interface)
• operator issues (types, scripts) direct to
individual devices (e.g., vis ssh)
SNMP/MIB
• operator queries/sets devices data (MIB:
management information base) using
Simple Network Management Protocol
(SNMP)
NETCONF/YANG
• more abstract, network-wide, holistic
• emphasis on multi-device configuration
management.
• YANG: data modeling language
• NETCONF: communicate YANG-compatible
actions/data to/from/among remote devices

SNMP protocol
Network Layer: 5-46
managed device
agent data
managing
server/controller
data
request
response trap message
Two ways to convey MIB info, commands:
request/response mode
managed device
agent data
managing
server/controller
data
trap mode

SNMP protocol: message types
Network Layer: 5-47
GetRequest
GetNextRequest
GetBulkRequest
manager-to-agent: “get me data”
(data instance, next data in list,
block of data).
Message type Function
SetRequest manager-to-agent: set MIB value
Response Agent-to-manager: value, response
to Request
Trap Agent-to-manager: inform manager
of exceptional event

SNMP protocol: message formats
Network Layer: 5-48
….
PDU
type
(0-3)
Request
ID
Error
Status
(0-5)
Error
Index
Name Value Name Value
Get/set header Variables to get/set
SNMP PDU
message types 0-3
….
PDU
type
4
Enterprise Agent
Addr
Trap
Type
(0-7)
Specific
code
Time
stamp
Name Value
Trap header Trap info
message type 4

 managed device’s operational (and some configuration) data
 gathered into device MIB module
• 400 MIB modules defined in RFC’s; many more vendor-specific MIBs
SNMP: Management Information Base (MIB)
Network Layer: 5-49
Object ID Name Type Comments
1.3.6.1.2.1.7.1 UDPInDatagrams 32-bit counter total # datagrams delivered
1.3.6.1.2.1.7.2 UDPNoPorts 32-bit counter # undeliverable datagrams (no application at port)
1.3.6.1.2.1.7.3 UDInErrors 32-bit counter # undeliverable datagrams (all other reasons)
1.3.6.1.2.1.7.4 UDPOutDatagrams 32-bit counter total # datagrams sent
1.3.6.1.2.1.7.5 udpTable SEQUENCE one entry for each port currently in use
agent data
 Structure of Management Information (SMI): data definition language
 example MIB variables for UDP protocol:

 goal: actively manage/configure devices network-wide
 operates between managing server and managed network devices
• actions: retrieve, set, modify, activate configurations
• atomic-commit actions over multiple devices
• query operational data and statistics
• subscribe to notifications from devices
 remote procedure call (RPC) paradigm
• NETCONF protocol messages encoded in XML
• exchanged over secure, reliable transport (e.g., TLS) protocol
NETCONF overview
Network Layer: 5-50

NETCONF initialization, exchange, close
Network Layer: 5-51
Session initiation,
capabilities exchange: <hello>
Session close: <close-session>
<rpc>
<rpc-reply>
<rpc>
<rpc-reply>
<rpc>
<rpc-reply>
<notification>
…
…
…
…
…
…
…
…
…
managing
server/controller
data
agent data

Selected NETCONF Operations
Network Layer: 5-52
NETCONF Operation Description
<get-config> Retrieve all or part of a given configuration. A device may have multiple
configurations.
<get> Retrieve all or part of both configuration state and operational state data.
<edit-config> Change specified (possibly running) configuration at managed device.
Managed device <rpc-reply> contains <ok> or <rpcerror> with rollback.
<lock>, <unlock> Lock (unlock) configuration datastore at managed device (to lock out
NETCONF, SNMP, or CLIs commands from other sources).
<create-subscription>, Enable event notification subscription from managed device
<notification>

Sample NETCONF RPC message
Network Layer: 5-53
note message id
change the running configuration
change MTU of Ethernet 0/0 interface to 1500
change a configuration

 data modeling language used to specify
structure, syntax, semantics of
NETCONF network management data
• built-in data types, like SMI
 XML document describing device,
capabilities can be generated from
YANG description
 can express constraints among data that
must be satisfied by a valid NETCONF
configuration
• ensure NETCONF configurations satisfy
correctness, consistency constraints
YANG
Network Layer: 5-54
agent data
managing
server/controller
data
NETCONF RPC message
<edit-config>
YANG-generated XML
</edit-config> YANG
generated

Network layer: Summary
Network Layer: 5-55
we’ve learned a lot!
 approaches to network control plane
• per-router control (traditional)
• logically centralized control (software defined networking)
 traditional routing algorithms
• implementation in Internet: OSPF , BGP
 SDN controllers
• implementation in practice: ODL, ONOS
 Internet Control Message Protocol
 network management
next stop: link layer!

Network layer, control plane: Done!
configuration
• SNMP
• NETCONF/YANG
introduction
 link state
 distance vector
Protocol
Network Layer: 5-56

 Define the following terms in the context of SNMP: managing server, managed
device, network management agent and MIB.
Network Layer: 4-57
 Managing server is an application, typically with a human in the loop, running in a centralized network
management station in a network operation center
• controls the collection, processing, analysis, and/or display of network management information
• actions are initiated in a managing server to control network behavior and
• network administrator uses a managing server to interact with the network’s devices
 Managed device is piece of network equipment (including software) that resides on managed network
• A managed device might be a host, router, switch, middlebox, modem, thermometer, or other
network-connected device
 Network management agent is process running in a managed device that communicates with managing
server, taking
• local actions at the managed device under the command and control of the managing server
 Management Information Base (MIB) collects the information associated with those managed objects
in a managed network
• A MIB object might be a counter, such as the number of IP datagrams discarded at a router due to
errors in an IP datagram header, or
• number of UDP segments received at a host, or the status information such as whether a particular
device is functioning correctly

 What are the purposes of the SNMP GetRequest and SetRequest
messages?
Network Layer: 5-58
 GetRequest
• message sent from a managing server to an agent to request the value of one
or more MIB objects at the agent’s managed device
 SetRequest
• message used by a managing server to set the value of one or more MIB
objects in a managed device

 What is the purpose of the SNMP trap message?
Network Layer: 5-59
 A SNMP trap message generated as
• response to an event happened on a managed device for which the device’s
managing server requires notification
 It is used for
• notifying a managing server of an exceptional situation
• e.g., a link interface going up or down, that has resulted in changes to MIB
object values

END OF LECTURE
Network Layer: 5-60

Lect12-13_MS_Networks.pptx

Recommended

Recommended

More Related Content

Similar to Lect12-13_MS_Networks.pptx

Similar to Lect12-13_MS_Networks.pptx (20)

Recently uploaded

Recently uploaded (20)

Lect12-13_MS_Networks.pptx

Editor's Notes