netconf, restconf, grpc_basic

netconf, restconf, grpc_basic

• 1.
  Mobile Convergence Laboratory 안계완(GyewanAn) danielahn@khu.ac.kr 세미나 Mobile Convergence Laboratory
• 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
• 3.
  Mobile Convergence Laboratory NETCONF(Cont’d) MobileConvergence Laboratory
• 4.
  Mobile Convergence LaboratoryMobileConvergence 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 LaboratoryMobileConvergence 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
• 6.
  Mobile Convergence LaboratoryMobileConvergence Laboratory
• 7.
  Mobile Convergence Laboratory YANG ‣YANGis 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 ‣gRPCis 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
• 13.
  Mobile Convergence LaboratoryMobileConvergence Laboratory
• 14.
  Mobile Convergence LaboratoryMobileConvergence Laboratory SNMP NETCONF RESTCONF gRPC Standard IETF IETF IETF - Resources OIDs Paths URLs protobuf Data Models Defined in MIBs YANG Core Models - - Data Modeling Language SMI YANG Undefined C++, Java, Python, Go, Ruby, … Management Operations SNMP NETCONF HTTP operations Custom Encoding BER XML XML, JSON, … Binary Transport Stack UDP SSH TCP SSL HTTP TCP -