2. Mobile Convergence Laboratory
NETCONF
‣ The Network Configuration Protocol(NETCONF) is a network management protocol
developed and standardized by the IETF.
‣ NETCONF provides mechanisms to install, manipulate, and delete the configuration of
network devices.
‣ Its operations are realized on top of a simple Remote Procedure Call (RPC) layer.
‣ The NETCONF protocol uses an Extensible Markup Language (XML) based data encoding
for configuration data as well as the protocol messages.
‣ The protocol messages are exchanged on top of a secure transport protocol.
Mobile Convergence Laboratory
4. Mobile Convergence LaboratoryMobile Convergence Laboratory
‣ the Simple Network Management Protocol (SNMP) proved to be a very popular network
management protocol.
‣ Operators were primarily using proprietary CLI to configure their devices. In addition, many
equipment vendors did not provide the option to completely configure their devices via
SNMP.
‣ Juniper Networks has been using an XML-based network management approach.
‣ The first version of the base NETCONF protocol was published as RFC 4741 in December
2006.
NETCONF(Cont’d)
5. Mobile Convergence LaboratoryMobile Convergence Laboratory
‣ NETCONF is a session-based network management protocol, which uses XML-encoded
remote procedure calls (RPCs) and configuration data to manage network devices.
‣ The mandatory transport protocol for NETCONF is SSH.
‣ The default TCP port assigned for this mapping is 830.
‣ A NETCONF server implementation must listen for connections to the ‘netconf’ subsystem
on this port.
‣ NETCONF supports the Simple Object Access Protocol (SOAP), the Blocks Extensible
Exchange Protocol (BEEP), and Transport Layer Security Protocol (TLS).
Base Protocol
7. Mobile Convergence Laboratory
YANG
‣YANG is a data modeling language for the definition of data sent over the NETCONF
network configuration protocol.
‣The name is an acronym for “Yet Another Next Generation”.
‣The data modeling language can be used to model both configuration data as well as state
data of network elements.
‣The language being protocol independent can then be converted into any encoding format,
e.g. XML or JSON, that the network configuration protocol supports.
‣YANG is a modular language representing data structures in an XML tree format.
‣YANG data models can use XPATH expressions to define constraints on the elements of a
YANG data model.
Mobile Convergence Laboratory
8. Mobile Convergence Laboratory
RESTCONF
‣ The NETCONF protocol defines configuration datastores and a set of Create, Retrieve,
Update, Delete (CRUD) operations that can be used to access these datastores.
‣ The YANG language defines the syntax and semantics of datastore content, operational
data, protocol operations, and event notifications.
‣ RESTCONF uses HTTP operations to provide CRUD operations on a NETCONF datastore
containing YANG defined data.
‣ An HTTP-based management protocol does not need to mirror the functionality of the
NETCONF protocol.
‣ RESTCONF is not intended to replace NETCONF, but rather provide an additional simplified
interface that follows REST principles and is compatible with a resource-oriented device
abstraction.
Mobile Convergence Laboratory
9. Mobile Convergence Laboratory
gRPC
‣gRPC is a modern open source ugh performance RPC framework that can run in any
environments.
‣Google has been using a single general-purpose RPC infrastructure called Stubby to
connect the large number of micro services running within and across our data centers for
over a decade.
‣Stubby has many great features.
‣However, it’s not based on an standard and is too tightly coupled to our internal
infrastructure to be considered suitable for public release.
‣With the advent of SPDY, HTTP/2, and QUIC, many of these same features have appeared
in public standards, tougher with other features that Stubby does not provide.
‣It became clear that it was time to rework Stubby to take advantage of this standardization
and to extend its applicability to mobile, IoT, and Cloud use-cases.
Mobile Convergence Laboratory
10. Mobile Convergence Laboratory
gRPC - Principles & Requirements
‣Services not Objects, Messages not References - Promote the microservices design philosophy of
coarse-grained message exchange between systems while avoiding the pitfalls of distributed objects and
the fallacies of ignoring the network.
‣Coverage & Simplicity - The stack should be available on every popular development platform and easy for
someone to build for their platform of choice. It should be viable on CPU & memory limited devices.
‣Free & Open - Make the fundamental features free for all to use. Release all artifacts as open-source efforts
with licensing that should facilitate and not impede adoption.
‣Interoperability & Reach - The wire-protocol must be capable of surviving traversal over common internet
infrastructure.
‣General Purpose & Performant - The stack should be applicable to a broad class of use-cases while
sacrificing little in performance when compared to a use-case specific stack.
‣Layered - Key facets of the stack must be able to evolve independently. A revision to the wire-format should
not disrupt application layer bindings.
‣Payload Agnostic - Different services need to use different message types and encodings such as protocol
buffers, JSON, XML, and Thrift; the protocol and implementations must allow for this. Similarly the need for
payload compression varies by use-case and payload type: the protocol should allow for pluggable
compression mechanisms.
Mobile Convergence Laboratory
11. Mobile Convergence Laboratory
gRPC - Principles & Requirements
‣Streaming - Storage systems rely on streaming and flow-control to express large data-sets. Other services,
like voice-to-text or stock-tickers, rely on streaming to represent temporally related message sequences.
‣Blocking & Non-Blocking - Support both asynchronous and synchronous processing of the sequence of
messages exchanged by a client and server. This is critical for scaling and handling streams on certain
platforms.
‣Cancellation & Timeout - Operations can be expensive and long-lived - cancellation allows servers to
reclaim resources when clients are well-behaved. When a causal-chain of work is tracked, cancellation can
cascade. A client may indicate a timeout for a call, which allows services to tune their behavior to the needs
of the client.
‣Lameducking - Servers must be allowed to gracefully shut-down by rejecting new requests while continuing
to process in-flight ones.
‣Flow-Control - Computing power and network capacity are often unbalanced between client & server. Flow
control allows for better buffer management as well as providing protection from DOS by an overly active
peer.
Mobile Convergence Laboratory
12. Mobile Convergence Laboratory
gRPC - Principles & Requirements
‣Pluggable - A wire protocol is only part of a functioning API infrastructure. Large distributed systems need
security, health-checking, load-balancing and failover, monitoring, tracing, logging, and so on.
Implementations should provide extensions points to allow for plugging in these features and, where useful,
default implementations.
‣Extensions as APIs - Extensions that require collaboration among services should favor using APIs rather
than protocol extensions where possible. Extensions of this type could include health-checking, service
introspection, load monitoring, and load-balancing assignment.
‣Metadata Exchange - Common cross-cutting concerns like authentication or tracing rely on the exchange of
data that is not part of the declared interface of a service. Deployments rely on their ability to evolve these
features at a different rate to the individual APIs exposed by services.
‣Standardized Status Codes - Clients typically respond to errors returned by API calls in a limited number of
ways. The status code namespace should be constrained to make these error handling decisions clearer. If
richer domain-specific status is needed the metadata exchange mechanism can be used to provide that.
Mobile Convergence Laboratory
