サービスアダプタ仕様¶

構造¶

SMFv2対応サービスアダプタの構造を、以下の図で模式的に表します。

この図は、SMFv2対応サービスアダプタとして必要なコンポーネントとその関連を表しています。

libarmsは、ARMSプロトコルを実装したライブラリで、SMFv2対応動作のうち、中心的な役割を占めます。内部的にはpullを行い、コンフィグを取得するためのBoot Agentと、RSからのpushを受け付けるためのRemote Operation Agentに分類されます。 libarmsは、あらかじめDistribution IDや認証キー、証明書といった情報を登録する必要があります。また、設定の反映や回線の接続操作等はコールバック関数を呼び出すことによって実現されます。呼び出される部分は上図ではConfig Manager, Layer2 Managerとして定義されています。この部分はサービスアダプタ固有の実装となります。

サービスアダプタは起動処理の過程で、"Initial-Config", "Location-Config", "Service-Config"という3つのコンフィグを使い分けます。 Initial-ConfigはLSに接続するために用いるコンフィグ、Location-ConfigはRSに接続するために用いるコンフィグ、 Service-Configは最終的にサービスアダプタの動作に用いるためのコンフィグです。

Monitoring Agent(Heartbeat)は、サービスアダプタから定期的にHeartbeatサーバに対してHeartbeatパケットを投げるための機能を持ちます。これにより、サービスアダプタの死活状態をサーバ側で判定することができるようになります。 Monitoring Agentは、本書にて定義されているHeartbeatパケットのプロトコル仕様を元に、ハードウェアベンダで独自に作成する必要があります。

以下の節では、各コンポーネントで利用されるDistribution IDの定義やARMSプロトコル、Heartbeatプロトコルの仕様について解説します。

Distribution ID¶

ここでは、SMFv2システムで個々のサービスアダプタの識別子として用いられる、Distribution IDについて解説します。

Distribution IDの定義¶

Distribution IDは、サービスアダプタを識別するために用いられる、128bitのユニークなIDです。 128bitの値は、以下のようにいくつかのフィールドに分けて定義されています。

VERSION
SMFv2システムのバージョン情報を識別する、2octetの整数です。 IIJが値を決定します。
VENDOR CODE
サービスアダプタのハードウェアベンダを識別する、4octetの整数です。IIJが値を決定します。
SA TYPE
サービスアダプタのモデルを識別する、2octetの整数です。IIJが値を決定します。
SA CODE
サービスアダプタを識別する、8octetの整数です。ハードウェアベンダが自由に値を決めることができます。

Distribution IDの表記¶

Distribution IDは、16進数表記で表現され、2octet毎にハイフン(-)で区切って表記されます。また、16進数のアルファベットは大文字で表記します。

表記例は以下の通りです。

0001-0000-0000-0000-0000-0123-4567-89AC
0001-0000-0000-0000-FFFF-FFFF-FFFF-FFFF

Distribution IDの発行と管理¶

Distribution IDは、ハードウェアベンダがIIJに申請することによって取得することができます。取得したDistribution IDは、同時にLocation Server(LS)にも登録されます。

ARMSプロトコル¶

ここでは、ARMSプロトコルについて解説します。

ARMSプロトコルとは¶

ARMSプロトコルは、SMFv2における各種通信を効率良く、かつ安全に行うために独自に開発されたプロトコルです。このプロトコルには以下のような特徴があります。

XMLをベースとしている
プロトコルで使用されるメッセージは、原則としてすべてXMLで表現されます。よって、XMLを解釈することのできる、良く使われたライブラリで簡単に実装することができます。また、下位レイヤのプロトコルとしてはXMLテキストを送受信できるプロトコルであれば何でも使うことができます。例えばHTTPSやSSHといったプロトコルが該当します。
セキュリティ
ARMSプロトコルそのものにはパケットを暗号化したり認証を行う仕組みは規定されていません。これらは全て下位レイヤのプロトコルで実現することになります。これにより、良く知られた、実績のあるセキュリティ技術を簡単に流用することができます。
SMFv2の機能をメッセージで表現
SMFv2で実現される各種オペレーション(Pull, Push等)を、それぞれ「メッセージ」という形で統一的に規定しています。 ARMSプロトコル上で行われる通信は常に何らかのメッセージが付加されており、これは1-wayもしくは2-wayでARMS clientとARMS Proxyとの間で交換されます。
機種に依存するオペレーションを抽象的なメッセージで定義
再起動に必要なコマンドや、ステータスを取得するためのコマンドはSAによってまちまちです。これらのオペレーションをSAの機種ごとに個別に実装するのは非常に手間がかかりますが、ARMSプロトコルはこれらのオペレーションを抽象的なメッセージで定義しています。このため、RSではSAの機種に依存することなく同一のオペレーションを全て同一のメッセージで実行することができます。
リソースの浪費を防ぐための考慮
ARMSプロトコル上で行われる通信は、極力ネットワークやSAのリソースを浪費しないように設計されています。このため、ハードウェアリソースに乏しいSAや、低速なネットワーク環境においても導入しやすいプロトコルとなっています。

Pullオペレーション¶

ARMSプロトコルで設定の取得が行われるまでの流れを解説します。

ARMSプロトコルを用いて起動するよう設定されたサービスアダプタは、まずLSに接続するための初期化処理を行います。
LSは、サービスアダプタから到達可能な広域ネットワークに1台だけ存在するサーバですが、起動直後のサービスアダプタは広域ネットワークに接続するための手段がありません。そのため、サービスアダプタ内にあらかじめ保存されているInitial-Configを用いて、広域ネットワークに接続するための処理を行います。具体的には、PPPoEのコネクションを確立したり、DHCPサーバからアドレスを取得するといった動作になります。
広域ネットワークに接続する準備が整ったら、LSに対して「RS探索リクエスト」を送信します。
これをARMSプロトコルでは"rs-solicitation"と定義しています。このリクエストメッセージには、自身のDistribution IDが含まれています。
LSは、rs-solicitation requestを受信すると、Distribution IDに対応したRSへの接続設定をデータベースから検索し、その結果を"rs-solicitation response"として返します。
この結果には、もし対応する接続設定が見つかった場合にはその内容が含まれます。具体的には
- RSのURL
- RSに接続するための機種依存設定(PPPoEのアカウント/パスワード等)
などが含まれます。サービスアダプタは、これをLocation-Configとして保存します。
Location-Configを取得すると、この設定にもとづいて再度SAの初期化処理が行われます。
RSに対して「コンフィグ探索リクエスト」を送信します。
これをARMSプロトコルでは"config-solicitation request"と定義しています。このリクエストメッセージには、自身のDistribution IDが含まれています。
RSは、config-solicitation requestを受信すると、Distribution IDに対応した設定をデータベースから検索し、
その結果を"config-solicitation response"として返します。この結果には、もし対応する設定が見つかった場合にはその内容が含まれます。具体的には
- サービスアダプタの設定(Service-Config)。最終的に動作するSAの機種依存設定です。
- 監視サーバアドレスと監視設定。HeartbeatサーバのアドレスやHeartbeatパケットの送信間隔などの情報です。
- 必要なモジュールの情報。Add-Onフレームワークに対応したSAを用いる場合に、該当SAで必要となるモジュールのリストです。
などが含まれます。サービスアダプタは、これをService-Configとして保存します。
最終的に動作する機種依存設定の取得に成功すると、これを用いて最終初期化処理を行います。これでPullオペレーションは完了となります。

Pushオペレーション¶

ARMSプロトコルでRSからサービスアダプタに対してPushが行われる流れを解説します。

サービスアダプタでPushオペレーションを実行する準備ができた段階で、RSに対して"push-ready request"メッセージを送信します。これは、RSからサービスアダプタへのPushオペレーションを確実に実行するために行われます。このメッセージには、
- Distribution ID
- SAが取得したIPアドレス
といった情報が含まれます。 IPアドレスの値は、RSがPushを行う宛先アドレスとして使用されます。従って、サービスアダプタのIPアドレスが変更されるたびに"push-ready request"メッセージが通知されることになります。
RSで"push-ready request"メッセージの受信に成功すると、その結果を"push-ready response"として返します。

ユーザからの指示等により、RSからサービスアダプタに対してPushオペレーションが発行されます。このオペレーション発行は、その内容に応じていくつかのメッセージが個別に定義されています。代表的なものは以下の通りです。

メッセージ名

オペレーションの内容

read-status

ステータス情報の取得

configure

設定の反映

read-storage

設定の取得

reboot

再起動

ping

ICMP Echo を用いた疎通確認

指示されたオペレーションに従い、サービスアダプタ内で処理が実行されます。
実行した結果をRSに通知します。なお、処理の実行と結果通知は、オペレーション発行のトランザクションとは非同期に実行されるため、 RSがSAの処理完了を待ち続ける必要はありません。

コンフィグモデル¶

サービスアダプタ内に保持されるコンフィグの種類と動作について解説します。

Initial-Config¶

最初にLSに対してPullを行うために用いるコンフィグを、Initial-Configと呼びます。このコンフィグは、IIJから暗号化形式のファイルとして提供されます。コンフィグに定義されている内容は

LSのURL
匿名PPPoEアカウント
LS接続のリトライ回数、インターバル

といった内容です。この内容はlibarmsの内部で処理され、LSアクセスの際に自動的に利用されます。実際の設定値は以下のようになっています。

項目	設定値	備考
LSのURL	非公開	IIJ で運用するサーバ
匿名PPPoEアカウント	非公開	PPPoE環境で匿名アカウントが必要な場合に利用される
LS接続リトライ回数	1500回
LS接続インターバル	60秒

Location-Config¶

LSから取得し、RSへのPullを行うために用いるコンフィグを、Location-Configと呼びます。このコンフィグは、LSシステムで用意されるWebUIを用いて設定を行います。 Location-Configで提供される情報は、以下の通りです。

RSのURL
RS接続リトライ回数
RS接続インターバル
RS-Info
- RSへアクセスするための回線情報
- RSの証明書を検証するためのRootCA証明書

このうち、RS-Info(回線情報と、RootCA証明書)は、LSシステム上に以下の書式で記述する必要があります。

--------------------------------
line-<line_type> {
 <回線パラメータ>
};

rs-certificate {
 <証明書情報(PEM)>
};
--------------------------------

回線情報は、以下の3種類のうちのいずれか1つとなります。

PPPoE

line-pppoe {
  ifindex <n>;
  account <account>;
  password <password>;
};

DHCP

line-dhcp {
  ifindex <n>;
};

モバイル

line-mobile {
  ifindex <n>;
  cid <cid>;
  apn <apn>;
  pdp-Type <type>;
  telno <telno>;
  ipaddress <ipaddress>;
  account <account>;
  password <password>;
};

静的IPアドレス割当

line-static {
  ifindex <n>;
  ipaddress <ipaddress>;
};

ifindexはSAのインタフェースを識別するために利用します。これはSAの機種依存部にそのまま渡され、libarmsは内容には関与しません。範囲は機種ごとのintで表現可能な範囲です。

accountおよびpasswordはPPPoEのアカウント情報となる表示可能文字列です。最長で36文字まで設定可能です。ただし";"は利用できません。

モバイルにおいて、cid, apn, pdp-typeは3G端末における接続のための情報となる表示可能文字列です。 pdp-typeについては"ip"あるいは"ppp"のいずれかを指定します。 telnoは接続先電話番号です。モバイル端末のタイプによって、 cid, apn, pdp-typeとtelnoは使い分けができ、不要なパラメータについては指定行を省略できます。

モバイルおよび静的IPアドレスにおけるipaddressは、直接IPアドレスの割当が可能となる際に指定するIPアドレス文字列です。不要な場合については指定行を省略できます。

Service-Config¶

libarmsがRSに接続して取得し、最終的にSAに反映される設定情報となるコンフィグを、Service-Configと呼びます。 libarmsは、Service-Configの内容には一切関知せず、コンフィグ反映コールバック関数でSAに反映するだけです。 Service-Configの内容は機種依存となるため、特に定められた書式はありません。

認証フレームワーク¶

SMFv2では、ARMSプロトコルを用いて通信を行う際、通信の機密保持と改ざん防止のため、証明書ベースの認証および暗号化を行っています。以下、SMFv2の認証フレームワークの詳細について解説します。

概観図¶

認証フレームワークの概観図は、以下のようになります。

トランスポート層は、HTTP/TLSを用います。
サーバ認証には証明書を用いています。
クライアントの認証にはHTTP認証(basic認証)を用います。

認証局¶

証明書を発行する認証局は、目的に応じて以下が用意されます。

LS CA: LS-SA間の認証に用いる証明書(LS証明書)を発行します。この認証局は、IIJが運用しているものです。
RS CA: RS-SA間の認証に用いる証明書(RS証明書、SA証明書)を発行します。 RS上で動作し、RS事業者が運用を行います。

認証情報¶

認証は、X.509証明書およびパスワードを利用します。

LS CA証明書

LS CAが発行する自己署名証明書です。

有効期限は30年です。

CNは"ARMS Root CA"と定義されています。

LS証明書

サービスアダプタがLSを認証するための証明書です。

LS CAが発行します。

CNは"Location Server"から始まる文字列となります。

RS CA証明書

RS CAの自己署名証明書です。

有効期限は任意に定めることができます。ただし、稼働中のSA証明書を更新する仕組みは無いため、1年以上を推奨します。

CNはRS事業者の持つDNS名とします。(例: "rs-ca.seil.jp")

RS証明書

サービスアダプタがRSを認証するための証明書です。

RS CAが発行します。

サーバが複数台存在する場合、全サーバで共通の証明書を用います。

CNはRS事業者のの持つDNS名とします。(例: "rs.seil.jp")

SA証明書

サービスアダプタが主張するDistribution IDが正当なものであることをRSに証明するための証明書です。

Distribution ID毎に、RS CAが発行します。

CNは"distid=<distid>"の形式となります。(例:"distid=0001-0000-0000-0000-0000-1234-5678-ffff")

LS-SAキー

サービスアダプタがLSに主張するDistribution IDが正当であることを証明するためのパスワードです。

サービスアダプタとLSがそれぞれ共通のパスワードを保持します。

個々の機器に個別のパスワードを設定するか、あるいは共通のパスワードを用いても構いません。

長さは最大64バイトのoctet stringです(可変長)。

許可される文字はASCIIコードの0x21〜0x7eまでの文字列です。

RS-SAキー

サービスアダプタがRSに主張するDistribution IDが正当であることを証明するためのパスワードです。

サービスアダプタとRSがそれぞれ共通のパスワードを保持します。

LSからrs-solicitationメッセージの応答として、RS-SAキーが渡されます。

個々の機器に個別のパスワードを設定するか、あるいは共通のパスワードを用いても構いません。

長さは最大64バイトのoctet stringです(可変長)。

許可される文字はASCIIコードの0x21〜0x7eまでの文字列です。

認証情報の保持¶

LSでの認証情報

LSでは、以下の認証情報を保持しています。

LS CA証明書、LS CA 秘密鍵、LS証明書、LS秘密鍵
RS毎のRS CA証明書
SA毎のLS-SAキーとRS-SAキー

RSでの認証情報

RSでは、以下の認証情報を保持しています。

RS CA証明書、RS CA秘密鍵、RS証明書、RS秘密鍵
サービスアダプタ毎のRS-SAキーとSA証明書、SA秘密鍵

サービスアダプタの認証情報

サービスアダプタの内部では、以下の認証情報を保持しています。

LS CA証明書、LS-SAキー

認証処理手順¶

ARMSメッセージの送信時に行われる認証の詳細は以下の通りです。

サービスアダプタがLSにARMSプロトコルでメッセージを送信する

サービスアダプタはLSにHTTP/TLSで接続します。

LSはLS証明書をサービスアダプタに提示します。

サービスアダプタはLS CA証明書を利用してLS証明書を検証し、CNが"Location Server"から始まる文字列であることを確認します。

サービスアダプタは認証鍵にLS-SAキーを用い、HTTP認証(Basic/Digest)ヘッダを送信します。

LSは自身の保持するLS-SAキーを用いてHTTP認証ヘッダを検証します。

サービスアダプタがRSにARMSプロトコルでメッセージを送信する

サービスアダプタはRSにHTTP/TLSで接続します。

RSはRS証明書をサービスアダプタに提示します。

サービスアダプタはRS CA証明書を利用してRS証明書を検証し、rs-solicitationで得たCNと同一であることを確認します。

サービスアダプタは認証鍵にRS-SAキーを用い、HTTP認証(Basic/Digest) ヘッダを送信します。

RSは自身の保持するRS-SAキーを用いてHTTP認証ヘッダを検証します。

RSがサービスアダプタにARMSプロトコルでメッセージを送信する

RSはサービスアダプタにHTTP/TLSで接続します。

サービスアダプタはSA証明書をRSに提示します。

RSはRS CA証明書を利用してSA証明書を検証し、接続しようとしているサービスアダプタのDistribution IDがCNに書き込まれていることを確認します。

RSは認証鍵にRS-SAキーを用い、HTTP認証(Basic/Digest)ヘッダを送信します。

サービスアダプタは自身の保持するRS-SAキーを用いてHTTP認証ヘッダを検証します。

Heartbeatプロトコル¶

SMFv2システムでは、サービスアダプタの監視を行うために独自のHeartbeatプロトコルを定義しています。本節では、Heartbeatによる監視のメカニズムとプロトコルの定義について解説します。

Heartbeat監視のアーキテクチャ¶

Heartbeatを用いた監視を行う際の概要図を以下に示します。

サービスアダプタからのHeartbeatパケット送信: サービスアダプタからは、後述するプロトコル仕様に従って定期的にHeartbeatパケットが送信されます。このパケットにはオプション情報としてインタフェースのトラフィック情報やCPU利用率、メモリ利用率などの情報を含めることができます。 Heartbeatパケットの送信には、IPv4とIPv6のどちらも利用可能です。
Heartbeatサーバでの死活判定: Heartbeatサーバは、受信したHeartbeatパケットの履歴を元に、サービスアダプタが現在正常に動作しているかどうかを判定します。判定ロジックは設定によって変更することができますが、通常は連続してHeartbeatパケットが届いている間は接続中であると見なし、連続して複数回Heartbeatパケットが届かなかったと判断すると接続断とみなします。 SA が Heartbeat パケットの送信にIPv4とIPv6の両方を使用している場合、IPv4とIPv6のどちらかでHeartbeatパケットを受信できれば Heartbeatパケットが届いていると判断します。
HeartbeatサーバからRSへのup/down通知: HeartbeatサーバがUP→DOWN、DOWN→UPのように状態の変化を検出すると、それをRSにイベントとして送信します。これを元に、RSでは接続状況の変化を取得することができます。また、もし指定がある場合には特定のメールアドレスに対してメールを送信することもできます。
リソースグラフCGIの提供: Heartbeatパケットにオプション情報が含まれている場合、これをHeartbeatサーバ上のWebサーバでグラフ情報として表示することができます。

プロトコル仕様¶

Heartbeatは、UDPを使用します。ポート番号は任意の値を用いて構いません。

パケットフォーマット¶

Heartbeatのパケットフォーマットは、以下に定義されるTLVパラメータを組みわることで構成されます。

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Type  （2byte)                                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Length (2byte)                                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Value  (個々のタイプの定義に従う）...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Typeは、各TLVパラメータ毎に定義される値が用いられます。 Lengthは、Valueの長さが入ります。ValueはTypeで定義されている実際の値が入ります。

パラメータに関する注意点は、以下の通りです。 - 必須パラメータは、一つのメッセージの中で一つだけ含めるなければいけません。 - オプションパラメータは、一つのメッセージの中に複数含めることができます。 - Type が未知の値の場合、そのパラメータは無視されます。 - その他、たとえば TLV の Length が packet サイズより大きいサイズのパラメータを含んでいた場合などのその他不正なパケットは破棄されます。

パラメータ定義¶

Message Digest (必須パラメータ)¶

改ざんチェックのための情報です。HMAC-SHA1を用いて、メッセージ全体のMessage Digestを計算して格納します。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Message Digest ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                ... (20 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 1
Length: 20

Message Digest は、以下の式を用いて計算します:

Message Digest = HMAC_SHA1 (secret_key, message全体)

message はパケット全体が対象となり、事前に HMAC SHA1 パラメータのData の値自体は全て 0 でパディングしておかなければなりません。このパラメータは必ずメッセージの先頭にある必要があります。

Distribution ID (必須パラメータ)¶

Distribution IDを格納します。このパラメータは、必ずHMAC SHA1(0x0001)の後にある必要があります。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Distribution ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 17
Length: 16

CPU Usage (オプションパラメータ)¶

CPU利用率の値です。送信間隔間のCPU利用率の加算平均値が格納されます。

 0                   1                   2
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  CPU Index                    |  CPU Load     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 51
Length: 3

CPU Indexには、サービスアダプタ内で一意に識別されるCPUのインデックス番号を格納します。

CPU Usage description (オプションパラメータ)¶

CPU利用率の詳細な値です。送信間隔間のCPU利用率の加算平均値が格納されます。 CPU Load にCPU全体の利用率を格納します。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  CPU Index                    |  idle         |  interrupt    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  user         |  system       |  other        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 52
Length: 7

CPU Indexには、サービスアダプタ内で一意に識別されるCPUのインデックス番号を格納します。 idle, interrupt, user, system, other にCPU利用率の内訳を指定します。

Memory (オプションパラメータ)¶

使用メモリ容量と空きメモリ容量を格納します。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Memory Index                  |  Used Memory (byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |  Free Memory (byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 53
Length: 18

Memory Indexには、サービスアダプタ内で一意に識別されるメモリのインデックス番号を格納します。 Used Memoryには使用中のメモリ量を格納します。Free Memoryには未使用のメモリ量を格納します。

Disk (オプションパラメータ)¶

Diskの使用容量とDiskの空き容量を格納します。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disk Index                    |  Used Disk (byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |  Free Disk (byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 55
Length: 18

Disk Indexには、サービスアダプタ内で一意に識別されるディスクのインデックス番号を格納します。 Used Diskには使用中のディスク容量を格納します。Free Diskには未使用のディスク容量を格納します。

Traffic Rate(オプションパラメータ)¶

インタフェース毎のトラフィックレートを格納します。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Interface Index      |  IN/Octet (byte/sec)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |  OUT/Octet (byte/sec)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |  IN/Packet (packet/sec)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |  OUT/Packet (packet/sec)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |  IN/Error Packet (packet/sec)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |  OUT/Error Packet (packet/sec)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 57
Length: 50

Interface Indexには、サービスアダプタ内で一意に識別されるインタフェースのインデックス番号を格納します。 IN/Octetには入力オクテット数、OUT/Octetには出力オクテット数、IN/Packetには入力パケット数、OUT/Packetには出力パケット数を格納します。 IN/Error Packetにはエラーと判定された入力パケット数、OUT/ErrorPacketにはエラーと判定された出力パケット数を格納します。

ここでのオクテット数、パケット数はそれぞれ Heartbeat 送信間隔におけるbyte/sec, packet/sec の平均値となります。送信間隔の間にカウントされたバイト数、パケット数を送信間隔で割った値としてください。

電波受信レベル (オプションパラメータ)¶

モバイル端末の電波受信レベルの情報を格納します。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Mobile Interface Index     |  Additional   |  Signal       |
|                               |  Information  |  Level (Max)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Signal       |  Signal       |
|  Level(Min)   |Level (Average)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 44
Length: 6

Mobile Interface Index にはモバイル端末インタフェースのインデックス番号を格納します。 Additional Information にはモバイル端末の状態を表す付加情報 (0 = 正常、1 = 圏外、2 = 電波受信レベル取得不可、3 = デバイス無し、4 = 内部エラー)を格納します。 Signal Level (Max)には送信間隔間の電波受信レベルの最大値を格納します。 Signal Level (Min)には送信間隔間の電波受信レベルの最小値を格納します。 Signal Level (Average) には送信間隔間の電波受信レベルの平均値を格納します。

電波受信レベルの値はパーセンテージで表します。(0% から 100%) 圏外、デバイス無しといった電波受信レベルの値を取得できない状態の場合、電波受信レベルは 0% とします。

セキュリティに関する補足¶

Heartbeatパケットのセキュリティに関する注意点を補足します。

改ざん防止: HeartbeatパケットではMessage Digestを用いて改ざん防止のチェックを行います。これにより、 Heartbeatサーバは不正なHeartbeatパケットを検出することが可能となっています。
盗聴: HeartbeatパケットはUDPで送信され、暗号化はされていません。このため、パケットの中身を第三者に盗聴される可能性があります。盗聴を防ぐ場合、下位プロトコルで実現可能な暗号化技術(IPsec)等を用いる必要があります。
replay attack: Heartbeat packetを複製された場合は、これを防ぐことができません。このため、第三者によってDOWNとなっているサービスアダプタをUPと判定させることや、誤ったグラフを表示される可能性があります。
詐称: Message Digestに用いるsecret keyは、サーバ単位で共通の値が用いられます。このため、同一のサーバを利用するサービスアダプタが悪意を持ち、異なるDistribution IDを詐称したHeartbeatパケットを送信することができます。