YANG-Pushの進化：draft-ietf-netconf-notification-messages と メッセージブローカー統合

Tech

{ “protocol”: “YANG Notification Messages / MQTT Transport”, “status”: “Internet-Draft (draft-ietf-netconf-notification-messages-24 / draft-ietf-netconf-yang-notifications-mqtt-04)”, “layer”: “Application / Presentation”, “keywords”: [“YANG-Push”, “Message Broker”, “MQTT”, “Telemetry”, “RFC 8639”] } 本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

YANG-Pushの進化：draft-ietf-netconf-notification-messages と メッセージブローカー統合

【背景と設計目標】

従来の1対1通信から、メッセージブローカーを介した多対多のパブリッシュ・サブスクライブ型テレメトリへの移行を実現する。

NETCONF/RESTCONF（RFC 6241/8040）による個別管理の限界を突破するため、RFC 8639 (Subscription to YANG Notifications) を拡張し、KafkaやMQTT等のメッセージブローカーとの親和性を高める「共通通知カプセル化」と「ブローカー転送」を定義します。

【通信シーケンスと動作】

メッセージブローカー（例: MQTT）を介したYANG通知の配信シーケンスを以下に示します。パブリッシャー（ネットワーク機器）は直接レシーバーを知る必要がなく、トピックベースで配信を抽象化します。

sequenceDiagram
    participant "P as Publisher (Network Device)"
    participant "B as Message Broker (MQTT/Kafka)"
    participant "R as Receiver (Collector/NMS)"

    Note over P, R: Setup phase (Config or Dynamic Subscription)
    R ->> B: SUBSCRIBE (Topic: /ietf-notif/interfaces/...)
    P ->> B: CONNECT / ESTABLISH

    Note over P: Event Triggered or Periodic
    P ->> B: PUBLISH (YANG Notification Message)
    B -->> P: PUBACK (Quality of Service dependent)

    Note over B: Message Routing
    B ->> R: FORWARD (YANG Notification Message)
    Note over R: Decode Header & Process YANG Payload

【データ構造 / パケットフォーマット】

draft-ietf-netconf-notification-messages で規定される共通メッセージフォーマットの論理構造です。バイナリエンコーディング（CBOR等）またはテキストエンコーディング（JSON/XML）のいずれでも、以下のヘッダー情報を共有します。

+-----------------------------------------------------------------------+
|  Common Message Header (Logical Structure)                            |
+-----------------+-------------------+---------------------------------+
| Field Name      | Type / Length     | Description                     |
+-----------------+-------------------+---------------------------------+
| version         | uint8             | Version of the format (e.g. 1)  |
| message-id      | uint32            | Unique ID for tracking/dedup    |
| observation-time| timestamp         | Time event occurred (PTP/NTP)   |
| subscription-id | uint32            | ID defined in RFC 8639/8641     |
| message-priority| uint8             | 0 (Low) to 7 (High)             |
+-----------------+-------------------+---------------------------------+
|  Payload Section                                                      |
+-----------------------------------------------------------------------+
| encoding        | enum              | CBOR, JSON, XML, etc.           |
| data-model-inst | path              | YANG path to the notification   |
| payload-content | opaque            | Encoded YANG data               |
+-----------------------------------------------------------------------+

【技術的な特徴と比較】

従来のNETCONF/RESTCONFベースのPush配信と、新しいメッセージブローカー統合モデルの比較です。

特徴項目 NETCONF-Push (RFC 8641) Message Broker Push (Draft)
接続形態 P2P (Point-to-Point) N:M (Broker-mediated)
トランスポート SSH / HTTP/2 (TLS) MQTT / Kafka / UDP
スケーラビリティ 低（機器毎にSession維持が必要） 高（ブローカーがファンアウトを担当）
疎結合性 密（送信元が宛先IPを保持） 疎（トピックによる抽象化）
オーバーヘッド 高 (Keep-alive/Persistent) 低 (MQTT等の軽量ヘッダー)

  • HOL Blockingの解消: メッセージブローカー統合により、特定のレシーバーの遅延がパブリッシャー（機器）に直接影響しなくなります。

  • マルチプロトコル対応: 共通ヘッダーの導入により、トランスポートがMQTTであってもKafkaであっても、中身のYANGデータを共通のロジックで解析可能です。

【セキュリティ考慮事項】

  1. トランスポート層の保護: MQTT統合（draft-ietf-netconf-yang-notifications-mqtt）では、TLS 1.2/1.3の使用を必須（MUST）としており、ブローカーとの相互認証を推奨しています。

  2. 認可制御の委譲: NETCONFではNACM（RFC 8341）で制御しますが、ブローカー経由では「どのトピックにPublish/Subscribeできるか」の権限管理をブローカー側のACLと同期させる必要があります。

  3. 完全性と機密性: ブローカーが信頼境界の外にある場合、Payloadレベルでの暗号化（Object Security）の検討が必要になるケースがあります。

【まとめと実装への影響】

ネットワークエンジニアおよび開発者は、以下の3点に留意して設計・実装を進める必要があります。

  1. 「セッション管理」から「トピック管理」へのマインドセット移行: 機器のIPアドレスを管理するのではなく、どのデータがどのトピック（例: ietf-notif/status/interface）に流れるかを設計する重要性が増します。

  2. エンコーディングの選定（CBOR vs JSON）: 高頻度のテレメトリでは、共通ヘッダーをCBORでバイナリ化することで帯域を節約しつつ、YANGのセマンティクスを維持する構成が主流になります。

  3. 既存のコレクタ（受信機）のアップデート: RFC 8639直結のレシーバーは、新しい「Notification Message」の共通ヘッダーを解釈するラッパー層の実装が必要になります。これにより、異機種混在環境でのテレメトリ統合が容易になります。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました