Network Management Protocols網路管理協定

To manipulate and automate on the data models supported on a network device, a network management protocol needs to be used between the application client (such as an SDN controller) and the network devices. Different devices support one or more protocols such as REST, NETCONF, RESTCONF, and gRPC through a corresponding programmable interface agent for these protocols—sometimes a native REST agent is used.

為了操控並自動化網路裝置支援的資料模型，用戶端應用程式（例如 SDN 控制器）與網路裝置之間需要使用網路管理協定。不同裝置透過對應的可程式化介面代理支援一種或多種協定，例如 REST、NETCONF、RESTCONF 及 gRPC，有時也會使用原生 REST 代理。

When a request from a client is received through a NETCONF, RESTCONF, or gRPC protocol, the corresponding programmable interface agent converts the request into an abstract message object that is distributed to the underlying model infrastructure. The appropriate model is selected and the request is passed to it for processing. The model infrastructure executes the request (read or write) on the device data store, returning the results to the originating agent for response transmission back to the requesting client.

當透過 NETCONF、RESTCONF 或 gRPC 協定收到用戶端請求時，對應的可程式化介面代理會將請求轉換為抽象訊息物件，並分派給底層模型基礎架構。系統會選擇適當的模型，將請求傳給該模型處理。模型基礎架構會在裝置的資料儲存區執行請求（讀取或寫入），並將結果回傳給原始代理，再傳送回應給發出請求的用戶端。

There is often a perception that REST is a complex topic to learn, but in reality, it is analogous to browsing a website with a web browser.

一般人常覺得 REST 是個複雜的主題，但實際上它就類似用網頁瀏覽器瀏覽網站一樣。

REST is an architectural style (rather than a protocol) for designing networked applications.

REST 是一種設計網路應用程式的架構風格（而非協定）。

In REST, a client sends a request for a resource using a URL, and the server responds by providing that resource. This is also known as a stateless client/server model and typically uses HTTP(S) to make calls (referred to as requests) between entities.

在 REST 中，用戶端使用 URL 傳送資源請求，伺服器則提供該資源作為回應。這也稱為無狀態的用戶端／伺服器模型，通常使用 HTTP(S) 在實體之間進行呼叫（稱為請求）。

Usually, you have to identify yourself to the REST resource by some form of authentication to ensure secure access to the network resource.

通常你必須透過某種形式的驗證向 REST 資源表明身分，以確保網路資源的存取安全。

REST supports create, read, update, and delete (CRUD) operations by using specific HTTP verbs. Create, retrieve, update, and delete refers to the four major functions that are implemented in database applications (including network devices). CRUD operations are how you can work with network APIs to create objects (for example, create loopback interfaces), retrieve objects (particular sections of config or operational data), update objects (perform a given change), or delete an object (remove a route, an IP address, and so on).

REST 透過特定的 HTTP 動詞支援建立、讀取、更新與刪除（CRUD）操作。建立、擷取、更新與刪除是資料庫應用程式（包含網路裝置）所實作的四項主要功能。CRUD 操作是你用來操作網路 API 的方式，可用來建立物件（例如建立回送介面）、擷取物件（設定或運作資料的特定部分）、更新物件（執行特定變更），或刪除物件（移除路由、IP 位址等）。

CRUD operations are used with the URL and payload. It is how the server (network device) knows what action to perform. With the REST API, your application passes a request for a certain type of data by specifying the URL path that models the data. Both the request and response are JSON or XML-formatted data. The following image shows an example of an URI address composition. The protocol used is HTTP.

CRUD 操作會搭配 URL 與承載資料使用，這是伺服器（網路裝置）用來判斷該執行何種動作的依據。使用 REST API 時，應用程式會透過指定描述資料模型的 URL 路徑來傳送特定類型資料的請求。請求與回應都是 JSON 或 XML 格式的資料。下圖顯示 URI 位址組成的範例，所使用的協定為 HTTP。

The most common HTTP verbs that are used by REST are GET, POST, PUT, PATCH, and DELETE. HTTP verbs are the methods that are used to perform some sort of action on a specific resource. Because HTTP is a standardized and ubiquitous protocol, the semantics are well known.

REST 最常使用的 HTTP 動詞是 GET、POST、PUT、PATCH 及 DELETE。HTTP 動詞是用來對特定資源執行某種動作的方法。由於 HTTP 是標準化且普及的協定，其語意已廣為人知。

GET is used to read or retrieve information from a resource and returns a representation of the data in JSON or XML. Because the GET method only reads data and does not change it, it is considered a "safe" method, which means there is no risk of data corruption.

GET 用於讀取或擷取資源的資訊，並以 JSON 或 XML 傳回資料的表示形式。由於 GET 方法只讀取資料而不會變更資料，因此被視為「安全」方法，代表不會有資料損毀的風險。

POST, on the other hand, creates new resources, which means it is not considered a "safe" method.

POST 則是用來建立新資源，因此不被視為「安全」方法。

PUT is normally used to update or replace an already existing resource. It is called "PUT-ing" to a resource and involves sending a request with the updated representation of the original resource.

PUT 通常用來更新或取代已存在的資源，稱為對資源進行「PUT」操作，做法是傳送包含原始資源更新後表示形式的請求。

PATCH is similar in some ways to PUT in that PATCH modifies the capabilities of a resource. The difference between PUT and PATCH is that PATCH sends a request containing only the changes to the resource and not a complete updated resource.

PATCH 在某些方面與 PUT 類似，都是修改資源的內容。PUT 與 PATCH 的差異在於，PATCH 傳送的請求只包含對資源的變更部分，而非完整的更新後資源。

DELETE simply deletes a resource that is identified by a URI.

DELETE 單純刪除以 URI 識別的資源。

When an HTTP method is used, there is a specific response code returned. For example, upon successful deletion of a resource using DELETE, the client will receive a 200 message signifying that the request succeeded.

使用 HTTP 方法時，會傳回特定的回應碼。例如，成功使用 DELETE 刪除資源後，用戶端會收到代表請求成功的 200 訊息。

HTTP response codes were developed by the IETF and therefore easy to look up online or on their website, ietf.org. These codes are useful in troubleshooting because they provide specific information regarding the error on the client side or server side. For example, if a client receives a 400 response from a server, you can conclude that there is a syntax problem in the request.

HTTP 回應碼由 IETF 制定，因此很容易在網路上或其官網 ietf.org 查詢。這些回應碼在疑難排解時非常有用，因為它們能提供有關用戶端或伺服器端錯誤的具體資訊。例如，若用戶端收到伺服器回傳的 400 回應，就可以判斷請求中存在語法問題。

In the tables below, you can see some of the most common HTTP response codes.

下表列出一些最常見的 HTTP 回應碼。

NETCONF is an IETF standard transport protocol for communicating with network devices, retrieving operational data and both setting and reading configuration data. Operational data includes interface statistics, memory utilization, errors, and so on. The configuration data refers to how particular interfaces, routing protocols, and other features are enabled and provisioned. NETCONF purely defines how to communicate with the devices.

NETCONF 是 IETF 制定的標準傳輸協定，用於與網路裝置通訊、擷取運作資料，以及設定與讀取設定資料。運作資料包含介面統計資訊、記憶體使用率、錯誤等。設定資料則是指特定介面、路由協定及其他功能如何被啟用與佈建。NETCONF 純粹定義如何與裝置通訊。

NETCONF uses an XML management interface for configuration data and protocol messages. The protocol messages are exchanged on top of a secure transport protocol such as SSH or TLS. NETCONF is session-oriented and stateful—it is worth pointing out as other APIs such as native REST and RESTCONF are stateless.

NETCONF 使用 XML 管理介面來處理設定資料與協定訊息，協定訊息會透過安全傳輸協定（例如 SSH 或 TLS）交換。NETCONF 是以工作階段為導向且具狀態的，值得注意的是，其他 API（例如原生 REST 及 RESTCONF）則是無狀態的。

NETCONF is fairly sophisticated and it uses an RPC paradigm to facilitate communication between the client (for example, an NMS server or an open source script) and the server. NETCONF supports device transaction, which means that when you make an API call configuring multiple objects and one fails, the entire transaction fails,and you do not end up with a partial configuration. NETCONF is fairly sophisticated—it is not simple CRUD processing.

NETCONF 相當複雜，它使用 RPC 範式來促成用戶端（例如 NMS 伺服器或開源指令碼）與伺服器之間的通訊。NETCONF 支援裝置交易，這表示當你透過一次 API 呼叫設定多個物件而其中一個失敗時，整個交易都會失敗，不會出現部分設定的情形。NETCONF 相當複雜，不只是簡單的 CRUD 處理。

NETCONF encodes messages, operations, and content in XML, which is intended to be machine and human-readable.

NETCONF 以 XML 編碼訊息、操作與內容，目的是讓機器與人類都能閱讀。

NETCONF utilizes multiple configuration data stores (including candidate, running, and startup). This is one of the most unique attributes of NETCONF, though a device does not have to implement this feature to "support" the protocol. NETCONF utilizes a candidate configuration, which is simply a configuration with all proposed changes applied in an uncommitted state. It is the equivalent of entering CLI commands and having them not take effect right away. You would then "commit" all the changes as a single transaction. Once committed, you would see them in the running configuration.

NETCONF 使用多個設定資料儲存區（包含候選、執行中及啟動設定）。這是 NETCONF 最獨特的屬性之一，不過裝置不一定要實作此功能才算「支援」該協定。NETCONF 使用候選設定，也就是套用所有建議變更但尚未提交的設定。這就相當於輸入 CLI 指令但不立即生效，等你之後將所有變更以單一交易方式「提交」。一旦提交後，你就會在執行中設定裡看到這些變更。

The example shows different NETCONF data stores:

此範例顯示不同的 NETCONF 資料儲存區：

Once you understand REST and NETCONF on their own, RESTCONF becomes much easier to digest. RESTCONF, in simplest terms, adds a REST API to NETCONF. YANG models are used as when you use RESTCONF, and the URLs, HTTP verbs, and Request bodies are automatically generated from the associated YANG model. Unlike NETCONF, RESTCONF supports both XML and JSON.

一旦你分別了解 REST 與 NETCONF，理解 RESTCONF 就會容易得多。簡單來說，RESTCONF 是為 NETCONF 加上一個 REST API。使用 RESTCONF 時同樣使用 YANG 模型，URL、HTTP 動詞及請求主體都是根據相關聯的 YANG 模型自動產生。與 NETCONF 不同，RESTCONF 同時支援 XML 與 JSON。

Remember that RESTCONF is just using REST principles and therefore uses HTTP verbs appropriately. The one key operation to take note of is the use of the PUT operation. The PUT operation has the ability to replace entire sections of configuration that is based on what you send. It is analogous to declarative network configuration. For example, if you PATCH one static route, it will add the route. If you PUT the route, you will end up with just one route configured.

請記住，RESTCONF 只是應用 REST 原則，因此會適當地使用 HTTP 動詞。其中一個需要特別注意的關鍵操作是 PUT 操作的使用。PUT 操作能夠依你傳送的內容取代整個區段的設定，這類似於宣告式的網路設定。例如，如果你對某條靜態路由使用 PATCH，會新增該路由；如果你使用 PUT，最終就只會設定該一條路由。

RESTCONF is not intended to replace NETCONF, but rather to provide an HTTP interface that follows REST principles and is compatible with the NETCONF data store model.

RESTCONF 的目的不是取代 NETCONF，而是提供一個遵循 REST 原則且與 NETCONF 資料儲存區模型相容的 HTTP 介面。

RESTCONF provides a simplified interface that follows REST-like principles running on top of HTTP or HTTPS transport, making RESTCONF an attractive choice for application developers.

RESTCONF 提供簡化的介面，遵循類似 REST 的原則並運作於 HTTP 或 HTTPS 傳輸之上，使 RESTCONF 成為應用程式開發人員青睞的選擇。

gRPC is an open-source RPC framework that provides simple client development. It is based on Protocol Buffers (Protobuf), which is an open source binary serialization protocol. gRPC provides a flexible, efficient, high-performance automated mechanism for serializing structured data, like XML, but is smaller and simpler to use. This makes it especially useful in model-driven telemetry.

gRPC 是一種開放原始碼的 RPC 框架，可簡化用戶端開發。它基於 Protocol Buffers（Protobuf），這是一種開放原始碼的二進位序列化協定。gRPC 提供靈活、高效且高效能的自動化機制，用於序列化結構化資料（如 XML），但體積更小、使用更簡便，因此在模型驅動遙測方面特別有用。

The user needs to define the structure by defining protocol buffer message types in .proto files. Each protocol buffer message is a small logical record of information, containing a series of name-value pairs. The structure of the data is defined by YANG models. gRPC encodes requests and responses in binary. gRPC is extensible to other content types along with Protobuf. The Protobuf binary data object in gRPC is transported over HTTP/2.

使用者需要在 .proto 檔案中定義 Protocol Buffer 訊息類型來定義結構。每個 Protocol Buffer 訊息都是一筆小型的邏輯資訊記錄，包含一系列名稱與值的配對。資料結構由 YANG 模型定義。gRPC 以二進位方式編碼請求與回應。除了 Protobuf 外，gRPC 也可延伸支援其他內容類型。gRPC 中的 Protobuf 二進位資料物件是透過 HTTP/2 傳輸的。