🦊

ETSI NFV SOL013の歩き方

2021/12/13に公開

仮想化

本ドキュメントは通信業界アドベントカレンダー 2021 の13日目の記事として執筆したものです。

その他の記事はQiitaのアドベントカレンダーページからどうぞ！

ETSI GS NFV

ETSI GS NFVはETSI(欧州電気通信標準化機構/エッツィと発音します)で策定されているネットワーク仮想化(NFV)の標準化文章です。

通信関係の標準化団体としてはLTEやIMSや5Gなどで3GPPが有名ですが、3GPPが地域によらない世界的な標準化団体ですが、
ETSIに関してはヨーロッパ、ユーロ圏内向けの電気通信関係の標準化団体です（日本国内で言うところのTTC等）。
しかしながら、ヨーロッパの標準化団体ではありますが、ETSI NFVの標準化策定には各国のオペレータ、ベンダが参加し議論が行われており、
ヨーロッパ、ユーロ内だけではなく、通信業界全体で利用されています。

近年ではゼロタッチオペレーションを目指しているZSMやエッジコンピューティングで有名なMECなどもETSIで策定されています。

ETSI GS NFV-SOL 013
Specification of common aspects for RESTful NFV MANO APIs

ETSI GS NFV-SOL 003はGS(Group Specification)と呼ばれるスペックを定めた標準化文書です。

SOL(ソルと発音します)はSolution WGの文書であり、 Protocols and Data Models を定めています。
実装する際に使用するファンクション間でやり取りをするファイルやAPIのデータモデルや手順などを定めています。

そのため、SOLの文書は実装や商用開発、運用において頻繁に参照することになります。

ETSI NFV-SOL 013 は Ve-Vnfm(SOL002)やOr-Vnfm(SOL003)、Os-Ma-Nfvo(SOL005)などで規定されているNFV MANOのコンポーネントである NFVO(NFV-Orchestrator)やVNFM(VNF Manager)の間の参照点で使用するRESTful Web APIの仕様のうち、RESTful Web APIとして一般的な仕様、たとえばエラー応答やフィルタリングのクエリー、認証方式、アクセストークン発行方法などを定めた標準化文書です。

SOL002/SOL003/SOL005等の文書からは、これらの事項についてSOL013を参照するようにという形で引用されているケースが多々あるとともに、NFVOやVNFMの振る舞いを理解する上においてはこれらの標準をある程度理解しておく必要が出てきます。

SOL013に記述されていること

上述の通り、ETSI NFV-SOL 013 は Ve-Vnfm(SOL002)やOr-Vnfm(SOL003)、Os-Ma-Nfvo(SOL005)などで規定されているNFV MANOのコンポーネントである NFVO(NFV-Orchestrator)やVNFM(VNF Manager)の間の参照点で使用するRESTful Web APIの仕様のうち、RESTful Web APIとして一般的な仕様、たとえばエラー応答やフィルタリングのクエリー、認証方式、アクセストークン発行方法などが記載されています。

対応するIFAドキュメント

ETSI NFV-SOL は ETSI NFV-IFA(アイファと発音します) と呼ばれる同じETSI NFV内の別WG(Interfaces and Architecture WG)で策定された標準化文書をさらに参照・準拠しています。IFAにおいてはNFVのファンクションが持つべき機能であったり、ファンクション内で保持すべき情報、あるいはファンクション間でやり取りすべき情報のモデルを定義しており、SOLではそれを実際のデータモデルにマッピングします。

SOL001/SOL003の解説では対応するドキュメントがありましたが、このSOL013にはそれらの直接的に対応するドキュメントはありません。

これはSOL013が、IFAで定められた機能要件等を具体化したものというよりも、SOL002/SOL003/SOL005といったRESTFul Web APIの共通的な機能を各々のドキュメントで定義するのではなく統一的に定義するという、仕様策定上の効率性などを求めた結果策定された文書であるからと言えます。

ドキュメントの置き場所

(ETSI内のリンクをたどって一体この場所にどのようにしてたどり着くのかは私は知りませんが、)パブリッシュ済みのドキュメントは以下から参照することができます。

バージョン

ETSI NFVにおいても 3GPP 等と同じくバージョンやリリースの概念が取り入れられています。

バージョンの差異によりNFVソリューションが持つAPIやデータ構造が異なることがあります。
そのため、自分自身が利用しているVNFMやNFVOといったNFVソリューションがどのバージョンをサポートしているのかを理解しておく必要があります。

2021年12月現在の最新版は2021年7月にリリースされた 3.5.1 です。

文書の構成

1-3章までの項目は全NFV標準化ドキュメントで変わりません。
1章にはスコープを、2章には参照すべき他の標準化文章等を、3章には用語や略称、記号等を記載します。

RESTful Web APIの雑多な部分を記載した標準化文書ですので、2章の参照すべき標準化文章にはHTTP系のIETFのRFCが並んでいることはSOL013の大きな特徴とも言えます。

4章以降、Annexより前までが基本的にはメインコンテンツになります。この4章以降のメインコンテンツの構成は標準化文書により構成は大きく異なります。

SOL013での4章以降の各章の概要は以下の通りです。

4章にはURIの構成やサポートすべきヘッダに関する記載があります。
5章はAPIのレスポンスに対する振る舞いを定義しています。APIでデータを条件を絞ってフィルタして取得する方法や、レスポンスに含むデータを絞り込む方法、巨大なレスポンスがある場合の振る舞いなどを規定しています。
6章はエラーハンドリング、エラーの通知に関する仕様が規定されています。エラー応答時のデータ構造とエラーレスポンスコードの仕様が定められています。
7章はSOL002/SOL003/SOL005内から引用されるこれらのSOL共通のデータ構造の仕様を定めています。
8章はAPIの認証方式を定めています。ETSI-NFV では認証方式はOAuth2を採用しておりそれについての説明や解説がされている。
9章はAPIバージョンの決め方や互換性について、またバージョンを取得するAPIの定義などがされています。

通常Annex以降にはExampleや参考となる情報が記載されています。SOL013では変更履歴が記載されています。最後にHistoryという章もありますが、Historyはリリース内でのPublishの履歴が記載されており、こちらのAnnexのChange Historyでは過去のリリース2からの詳細な変更履歴が記載されています。

フィルターや結果の出力のAPIの振る舞いについて

RESTful APIのリストAPIなどでは結果が膨大になったり、あるいは条件に合致するような検索を行いたい場合なども多いと思います。"RESTful API"としてはこれらのやり方が明確に定まっているわけではありません。そのため、必ずしも実装されている訳でもありませんし、やり方もAPI固有で用意されることになります。

ETSI NFV においてもこれらのフィルターや結果が膨大であった場合の振る舞いはNFV-MANO（NFVO/VNFM/VIM）をマルチベンダで構成する上において相互接続性のために重要となっています。これらの仕様がSOL013の中でも5章に記載されています。

この中からいくつか（特にTackerで実装されているものを中心に）紹介します。

フィルタ動作

フィルタの動作については 5.2 に記載されています。これらのフィルタの例はドキュメント上に以下のように記載されています。

このように filter というURLパラメータに対して (eq,AttiributeName,AttirbuteValue) というような形でリクエストを送ることで属性値に一致する結果のみを取得することができると定義されています。

実際に、OpenStack Tackerにおいても vnflcm や vnf_package のAPIにおいてこれらのフィルタの形で実装されています。

巨大なAPIレスポンスに対する振る舞い

たとえば表示すべきレコードが多い場合や、一つのデータ構造が大きいデータ構造を有する場合など、APIレスポンスが巨大になる場合があります。
特にSOL002/SOL003/SOL005等で記載のされているリスト表示のAPIはリスト表示であっても、リソースの表示であっても同じデータ構造をリスト構造で返すのか、あるいは単体で返すのかの違いしかありません。

リスト表示APIのレスポンスの定義

単体表示APIのレスポンスの定義

10や20といったVNFの数であればさほど問題にはならないかもしれませんが、VNFMが大きなものとなり、管理するVNFが増えた場合など、大量のデータを返そうと思いDBに大量にアクセスしたり、レスポンスボディの組立てのためにメモリを大量に使用したりとなってしまう可能性もあります。

そういったケースを想定しレスポンスのサイズが規定（サーバ側の実装次第）の大量のデータがある場合の想定動作をETSI NFVでは次の二パターン用意されています。

フィルター等をしてされた数量を下回るように促すエラー応答(5.4.2.2)
ページングして応答(5.4.2.3)

エラー応答に対しては後段のエラー応答のフォーマットに乗っ取り、400 Bad Reqeustを返しProblem Detailに記載するようにということを定義しています。

ページ応答に対してはRFC8288に従ってLINKヘッダーフィールドに対して次ページを返すようにということを規定されています。また、その際にnextpage_opaque_markerを付与することを求めています。この値はAPI提供者（たとえば NFVO->VNFMのAPIリクエストに対してはVNFM）が設定する任意の値であり、API提供者がどのページを次に返す必要があるのかを識別するために付与するパラメータとして定義されています。

エラー応答フォーマットの統一化

エラー応答についてもETSI NFVの中でエラー応答のフォーマットが統一化されています。これらも相互接続時にエラー応答を見てハンドルするときのためなどを想定されているかと思われます。

むすび

簡単ではありますが、ざっとSOL013で記載されていることと、フィルタ処理やレスポンスの振る舞いなど、APIの動きについて意外と知っておいた方がいい情報というところで記載してみました。

しかしながら、SOL013で書いてるような処理は実のところあまりきちんと実装されてているというわけでもなさそうなのが正直なところです。実際Tackerでも一部実装されていますが、エラー応答のフォーマットなどはどちらかと言うとOpenStackの流儀に乗っ取っていますし、API認証もOAuth2.0ではなくKeystoneを利用しています。その他の実装でも私が見てきた中では、実装されていたりされていなかったりというのが正直見えている状況です。

とはいえ、何か困ったことがあったときによりどこになるのが標準文書です。こんなところ書いてあったというのを思い出せたり覚えていたりすると違います。SOL013はあまり目立っている仕様ではありませんが上記の通りAPIの振る舞いについて決めている重要な仕様書です。よかったら一読してみることもおススメです。

非常にニッチな領域で、私もNFVスペシャリストというわけではありません。
間違いがあればコメント欄にご指摘下さい。

Have a nice NFV life :)