JP2021019294A

JP2021019294A - 通信装置及び通信方法

Info

Publication number: JP2021019294A
Application number: JP2019134106A
Authority: JP
Inventors: 亮太木村; Ryota Kimura; 高野　裕昭; Hiroaki Takano; 裕昭高野; 啓文葛西; Takafumi Kasai; 亮澤井; Akira Sawai; 寺岡　文男; Fumio Teraoka; 文男寺岡
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2019-07-19
Filing date: 2019-07-19
Publication date: 2021-02-15
Also published as: EP4002774A4; EP4002774A1; US11743322B2; WO2021015021A1; US20220239726A1

Abstract

【課題】ネットワーク内でパケットを転送させるサービスにおいて利便性高く、サービス利用者が希望するパケットに、サービス利用者が希望する１つまたは複数の機能を作用させること。【解決手段】１又は複数のアプリケーションを実行するアプリケーションノードとして動作する通信装置であって、他の論理ノードとの間の通信を実行する通信部と、通信部による通信を制御する制御部とを備え、上記他の論理ノードは、上記アプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信において、上記送受信の経路中に上記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）が適用されるノードであり、制御部は、上記他の論理ノードへ向けて、上記１又は複数のアプリケーション機能が作用するアプリケーションメッセージの送受信のために、出版−購読型モデルに従うメッセージを通信部から送信させる。【選択図】図２

Description

本開示は、通信装置及び通信方法に関する。

ネットワーク事業者やサービス提供者の観点から、必要に応じてネットワーク内を転送されるパケットを元々のパケットの転送経路に含まれないサーバ機器へ転送し、サーバ機器上で動作するサービス機能（ＳＦ：Service Function）をパケットに作用させることをＳＦＣ（Service Function Chaining）と呼ぶ。ＳＦとしては、ＮＡＴ（Network Address Translation）、ロードバランサ（Load Balancer）、ＷＡＦ（Web Application Firewall）などが挙げられる。

非特許文献１には、ＳＦＣのアーキテクチャが記載されている。また特許文献１には、仮想化されたネットワークサービス機能の可用性を高めるため、装置やリンクの障害検知および障害復旧を自律分散的に行う方法が記載されている。

特開２０１６−０４６７３６号公報

J.Halpern and C.Pignataro. Service Function Chaining (SFC) Architecture, October 2015. RFC 7665.

しかしながら、ＳＦＣでは、ネットワーク事業者やサービス提供者の観点でＷＡＦやロードバランサなどのＳＦが用意されている。すなわち、ネットワーク事業者やサービス提供者の意向によりどのようなパケットをＳＦＣの対象とするかを決めているものである。

そこで、本開示では、ネットワーク内でパケットを転送させるサービスにおいて利便性高く、サービス利用者が希望するパケットに、サービス利用者が希望する１つまたは複数の機能を作用させることが可能な、新規かつ改良された通信装置及び通信方法を提案する。

本開示によれば、１又は複数のアプリケーションを実行するアプリケーションノードとして動作する通信装置であって、他の論理ノードとの間の通信を実行する通信部と、前記通信部による通信を制御する制御部とを備え、前記他の論理ノードは、前記アプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信において、前記送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）が適用されるノードであり、前記制御部は、前記他の論理ノードへ向けて、前記１又は複数のアプリケーション機能が作用するアプリケーションメッセージの送受信のために、出版−購読型モデルに従うメッセージを前記通信部から送信させる、通信装置が提供される。

また、本開示によれば、１又は複数のアプリケーションを実行するアプリケーションノードとの間の通信を実行する通信部と、前記アプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）を適用する制御部とを備える論理ノードとして動作し、前記制御部は、前記アプリケーションノードを送信元又は送信先とする前記アプリケーションメッセージに対し、前記アプリケーション機能を作用させる場合に、前記アプリケーションメッセージを構成する１又は複数のパケットをすべて前記通信部に受信させたうえで、前記アプリケーションメッセージを構成する１又は複数のパケット単位で前記アプリケーション機能を作用させる、通信装置が提供される。

また、本開示によれば、１又は複数のアプリケーションを実行するアプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信に関連して、アカウンティングノードとの間の通信を実行する通信部と、他の論理ノードを管理する制御部とを備える管理ノードとして動作し、前記他の論理ノードは、前記通信部による通信を制御し、且つ前記アプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）が適用される論理ノードであり、前記制御部は、前記アプリケーションノードを送信元又は送信先とする前記アプリケーションメッセージに対し、前記アプリケーション機能を作用させる場合に、当該アプリケーション機能を作用させるに際して使用した資源を表すパケットを生成して前記通信部から前記アカウンティングノードへ送信させる、通信装置が提供される。

また、本開示によれば、１又は複数のアプリケーションを実行するアプリケーションノードとして動作する通信装置であって、他の管理ノードとの間の通信を実行する通信部と、前記通信部による通信を制御する制御部とを備え、前記他の管理ノードは、自アプリケーションノード又は他のアプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）と前記ＡＦＣが適用される論理ノードとを管理するノードであり、前記制御部は、自アプリケーションノードが前記送受信の経路中に存在し且つ前記ＡＦＣが適用されるノードを、前記他の管理ノードを介して作成した作成者である場合に、前記アプリケーションメッセージの送信元または送信先となる前記他のアプリケーションノードに対し前記ＡＦＣが適用される論理ノードの利用権限を付与するパケットを生成して、前記通信部に送信させる、通信装置が提供される。

また、本開示によれば、１又は複数のアプリケーションを実行するアプリケーションノードとして動作する通信装置を用いた通信方法であって、他の論理ノードとの間の通信を実行することと、前記他の論理ノードとの間の通信を制御することとを含み、前記他の論理ノードは、前記アプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信において、前記送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）が適用されるノードであり、前記制御することは、前記他の論理ノードへ向けて、前記１又は複数のアプリケーション機能が作用するアプリケーションメッセージの送受信のために、出版−購読型モデルに従うメッセージを送信させる、通信方法が提供される。

また、本開示によれば、論理ノードして動作する通信装置を用いた通信方法であって、１又は複数のアプリケーションを実行するアプリケーションノードとの間の通信を実行することと、前記アプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）を適用することとを含み、前記適用することは、前記アプリケーションノードを送信元又は送信先とする前記アプリケーションメッセージに対し、前記アプリケーション機能を作用させる場合に、前記アプリケーションメッセージを構成する１又は複数のパケットをすべて受信させたうえで、前記アプリケーションメッセージを構成する１又は複数のパケット単位で前記アプリケーション機能を作用させる、通信方法が提供される。

また、本開示によれば、管理ノードとして動作する通信装置を用いた通信方法であって、１又は複数のアプリケーションを実行するアプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信に関連して、アカウンティングノードとの間の通信を実行することと、他の論理ノードを管理することとを含み、前記他の論理ノードは、前記アカウンティングノードとの間の通信を制御し、且つ前記アプリケーションノードを送信元又は送信先とする前記アプリケーションメッセージの送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）が適用される論理ノードであり、前記管理することは、前記アプリケーションノードを送信元又は送信先とする前記アプリケーションメッセージに対し、前記アプリケーション機能を作用させる場合に、当該アプリケーション機能を作用させるに際して使用した資源を表すパケットを生成して前記アカウンティングノードへ送信させる、通信方法が提供される。

また、本開示によれば、１又は複数のアプリケーションを実行するアプリケーションノードとして動作する通信装置を用いた通信方法であって、他の管理ノードとの間の通信を実行することと、前記他の管理ノードとの間の通信を制御することとを含み、前記他の管理ノードは、自アプリケーションノード又は他のアプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）と前記ＡＦＣが適用される論理ノードとを管理するノードであり、前記制御することは、自アプリケーションノードが前記送受信の経路中に存在し且つ前記ＡＦＣが適用されるノードを、前記他の管理ノードを介して作成した作成者である場合に、前記アプリケーションメッセージの送信元または送信先となる前記他のアプリケーションノードに対し前記ＡＦＣが適用される論理ノードの利用権限を付与するパケットを生成して、送信させる、通信方法が提供される。

非特許文献１に開示されているＳＦＣのアーキテクチャ例を示す説明図である。本開示の実施形態で提案するＡＦＣのアーキテクチャを示す説明図である。ＧａｔｅＤａｅｍｏｎの設置処理の処理手順を示す図である。ＧａｔｅＳｅｔｕｐＲｅｑｕｅｓｔパケットの構造例を示す図である。ＧａｔｅＳｅｔｕｐＲｅｓｐｏｎｓｅパケットの構造例を示す図である。ＧａｔｅＡＡＲｅｑｕｅｓｔパケットの構造例を示す図である。ＧａｔｅＡＡＲｅｓｐｏｎｓｅパケットの構造例を示す図である。ＤａｔａＰｏｒｔＮｏｔｉｆｉｃａｔｉｏｎパケットの構造例を示す図である。ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケット（ＧａｔｅＤａｅｍｏｎ１の設置）の構造例を示す図である。ＧａｔｅＤａｅｍｏｎ１とＧａｔｅＤａｅｍｏｎ２の設置後にＡＦＣＭａｎａｇｅｒが保持する各テーブルの構造例を示す図である。ＧａｔｅＤａｅｍｏｎ１の設置後にＧａｔｅＤａｅｍｏｎ１が保持するＩｎｇｒｅｓｓＴａｂｌｅの構造例を示す図である。ＧａｔｅＤａｅｍｏｎ２の設置後にＧａｔｅＤａｅｍｏｎ２が保持するＥｇｒｅｓｓＴａｂｌｅの構造例を示す図である。ＡＦの設置処理の処理手順を示す図である。ＡＦＳｅｔｕｐＲｅｑｕｅｓｔパケットの構造例を示す図である。ＡＦＳｅｔｕｐＲｅｓｐｏｎｓｅパケットの構造例を示す図である。ＡＦＡＡＲｅｑｕｅｓｔパケットの構造例を示す図である。ＡＦＡＡＲｅｓｐｏｎｓｅパケットの構造例を示す図である。ＡＦＩｎｖｏｋｅＲｅｑｕｅｓｔパケットの構造例を示す図である。ＡＦＩｎｖｏｋｅＲｅｓｐｏｎｓｅパケットの構造例を示す図である。ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケット（ＡＦ１の設置）の構造例を示す図である。ＡＦ１〜ＡＦ３の設置後にＡＦＣＭａｎａｇｅｒが保持する各テーブルの構造例を示す図である。ＡＦ１の設置後にＡＦＣＤａｅｍｏｎ１が保持するＡＦＣＴａｂｌｅの構造例を示す図である。ＡＦ２の設置後にＡＦＣＤａｅｍｏｎ２が保持するＡＦＣＴａｂｌｅの構造例を示す図である。ＡＦ３の設置後にＡＦＣＤａｅｍｏｎ３が保持するＡＦＣＴａｂｌｅの構造例を示す図である。ＡＦＣの設置処理の処理手順を示す図（その１）である。ＡＦＣの設置処理の処理手順を示す図（その２）である。ＡＦＣＳｅｔｕｐＲｅｑｕｅｓｔパケットの構造例を示す図である。ＡＦＣＳｅｔｕｐＲｅｓｐｏｎｓｅパケットの構造例を示す図である。ＣｏｎｎＥｓｔａｂＰＲｅｑｕｅｓｔパケットの構造例を示す図である。ＣｏｎｎＥｓｔａｂＰＲｅｓｐｏｎｓｅパケットの構造例を示す図である。ＣｏｎｎＥｓｔａｂＡＲｅｑｕｅｓｔパケットの構造例を示す図である。ＣｏｎｎＥｓｔａｂＡＲｅｓｐｏｎｓｅパケットの構造例を示す図である。ＳｅｔＣｏｎｄｉｔｉｏｎＲｅｑｕｅｓｔパケットの構造例を示す図である。ＳｅｔＣｏｎｄｉｔｉｏｎＲｅｓｐｏｎｓｅパケットの構造例を示す図である。ＳｅｔＳｅｓｓｉｏｎＫｅｙＲｅｑｕｅｓｔパケットの構造例を示す図である。ＳｅｔＳｅｓｓｉｏｎＫｅｙＲｅｓｐｏｎｓｅパケットの構造例を示す図である。ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケット（ＡＦＣ１の設置）の構造例を示す図である。ＡＦＣの設置後にＡＦＣＭａｎａｇｅｒが保持する各テーブルの構造例を示す図である。ＡＦＣの設置後にＧａｔｅＤａｅｍｏｎ１が保持するＩｎｇｒｅｓｓＴａｂｌｅの構造例を示す図である。ＡＦＣの設置後にＧａｔｅＤａｅｍｏｎ２が保持するＥｇｒｅｓｓＴａｂｌｅの構造例を示す図である。ＡＦＣの設置後にＡＦＣＤａｅｍｏｎ１が保持するＡＦＣＴａｂｌｅの構造例を示す図である。ＡＦＣの設置後にＡＦＣＤａｅｍｏｎ２が保持するＡＦＣＴａｂｌｅの構造例を示す図である。ＡＦＣの設置後にＡＦＣＤａｅｍｏｎ３が保持するＡＦＣＴａｂｌｅの構造例を示す図である。ＡＦＵｓｅｒへのＡＦＣ利用権限の付与処理の処理手順を示す図である。ＡＦＣＰｅｒｍｉｓｓｉｏｎＲｅｑｕｅｓｔパケットの構造例を示す図である。ＡＦＣＰｅｒｍｉｓｓｉｏｎＲｅｓｐｏｎｓｅパケットの構造例を示す図である。アプリケーションによるＡＦＣＳｅｓｓｉｏｎＫｅｙの取得処理の処理手順を示す図である。ＧｅｔＵｓｅｒＳｅｓｓｉｏｎＫｅｙＲｅｑｕｅｓｔパケットの構造例を示す図である。ＧｅｔＵｓｅｒＳｅｓｓｉｏｎＫｅｙＲｅｓｐｏｎｓｅパケットの構造例を示す図である。ＡＦＣＡＡＲｅｑｕｅｓｔパケットの構造例を示す図である。ＡＦＣＡＡＲｅｓｐｏｎｓｅパケットの構造例を示す図である。ＳｅｔＵｓｅｒＳｅｓｓｉｏｎＫｅｙＲｅｑｕｅｓｔパケットの構造例を示す図である。ＳｅｔＵｓｅｒＳｅｓｓｉｏｎＫｅｙＲｅｓｐｏｎｓｅパケットの構造例を示す図である。ＧｅｔＵｓｅｒＳｅｓｓｉｏｎＫｅｙ後にＧａｔｅＤａｅｍｏｎ１が保持するＩｎｇｒｅｓｓＴａｂｌｅの構造例を示す図である。ＧｅｔＵｓｅｒＳｅｓｓｉｏｎＫｅｙ後にＧａｔｅＤａｅｍｏｎ２が保持するＥｇｒｅｓｓＴａｂｌｅの構造例を示す図である。第１のデータ通信処理の処理手順を示す図である。Ａｐｐ１の接続後にＧａｔｅＤａｅｍｏｎ１が保持するＩｎｇｒｅｓｓＴａｂｌｅの構造例を示す図である。Ａｐｐ２の接続後にＧａｔｅＤａｅｍｏｎ２が保持するＥｇｒｅｓｓＴａｂｌｅの構造例を示す図である。ＳｕｂｓｃｒｉｂｅＲｅｑｕｅｓｔパケットの構造例を示す図である。ＳｕｂｓｃｒｉｂｅＲｅｓｐｏｎｓｅパケットの構造例を示す図である。ＰｕｂｌｉｓｈＲｅｑｕｅｓｔパケットの構造例を示す図である。ＰｕｂｌｉｓｈＲｅｓｐｏｎｓｅパケットの構造例を示す図である。ＧａｔｅＤａｅｍｏｎ１からＡＦＣＤａｅｍｏｎ１へ送信されるデータパケットの構造例を示す図である。ＡＦＣＤａｅｍｏｎ１からＡＦＣＤａｅｍｏｎ２へ送信されるデータパケットの構造例を示す図である。ＡＦＣＤａｅｍｏｎ２からＧａｔｅＤａｅｍｏｎ２へ送信されるデータパケットの構造例を示す図である。ＧａｔｅＤａｅｍｏｎ２からＡｐｐ２へ送信されるデータパケットの構造例を示す図である。ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケット（ＡＦ１のデータ通信）の構造例を示す図である。第２のデータ通信処理の処理手順を示す図である。ＨＴＴＰＲｅｑｕｅｓｔメッセージ（ＧＥＴ）の構造例を示す図である。ＨＴＴＰＲｅｑｕｅｓｔメッセージ（ＰＯＳＴ）の構造例を示す図である。ＨＴＴＰＲｅｓｐｏｎｓｅメッセージ（ＰＯＳＴ）の構造例を示す図である。ＨＴＴＰＲｅｓｐｏｎｓｅメッセージ（ＧＥＴ）の構造例を示す図である。ＡＦＣの削除処理の処理手順を示す図である。ＡＦＣＤｅｌｅｔｅＲｅｑｕｅｓｔパケットの構造例を示す図である。ＡＦＣＤｅｌｅｔｅＲｅｓｐｏｎｓｅパケットの構造例を示す図である。ＣｏｎｎｅｃｔｉｏｎＣｌｏｓｅＲｅｑｕｅｓｔパケットの構造例を示す図である。ＣｏｎｎｅｃｔｉｏｎＣｌｏｓｅＲｅｓｐｏｎｓｅパケットの構造例を示す図である。ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケット（ＡＦＣ１の削除）の構造例を示す図である。ＡＦの削除処理の処理手順を示す図である。ＡＦＤｅｌｅｔｅＲｅｑｕｅｓｔパケットの構造例を示す図である。ＡＦＤｅｌｅｔｅＲｅｓｐｏｎｓｅパケットの構造例を示す図である。ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケット（ＡＦ１の削除）の構造例を示す図である。ＧａｔｅＤａｅｍｏｎの削除処理の処理手順を示す図である。ＧａｔｅＤｅｌｅｔｅＲｅｑｕｅｓｔパケットの構造例を示す図である。ＧａｔｅＤｅｌｅｔｅＲｅｓｐｏｎｓｅパケットの構造例を示す図である。ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケット（ＧａｔｅＤａｅｍｏｎ１の削除）の構造例を示す図である。本開示の実施の形態に係る各ノードとして機能しうる通信装置の機能構成例を示す説明図である。

以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

なお、説明は以下の順序で行うものとする。
１．本開示の実施の形態
１．１．ＳＦＣのアーキテクチャ例
１．２．ＡＦＣの具体的説明
１．３．通信装置の機能構成例
２．まとめ

＜１．本開示の実施の形態＞
［１．１．ＳＦＣのアーキテクチャ例］
本開示の実施の形態について詳細に説明する前に、まずＳＦＣのアーキテクチャ例について説明する。図１は、非特許文献１に開示されているＳＦＣのアーキテクチャ例を示す説明図である。

図１のようなＳＦＣアーキテクチャにおいて、ＳＦＣが適用される範囲をＳＦＣ−ｅｎａｂｌｅｄＤｏｍａｉｎと呼ぶ。ＳＦＣ−ｅｎａｂｌｅｄＤｏｍａｉｎ内には、ｃｌａｓｓｉｆｉｅｒ、ＳＦＦ（service function forwarder）、ＳＦ（service function）、Ｓｅｒｖｅｒ（たとえば、ＷｅｂＳｅｒｖｅｒ）などが存在する。

図１において、ＩｎｔｅｒｎｅｔからＷｅｂＳｅｒｖｅｒにアクセスする場合を考える。ＩｎｔｅｒｎｅｔからＳＦＣ−ｅｎａｂｌｅｄＤｏｍａｉｎに入ったパケットは、まずｃｌａｓｓｉｆｉｅｒに到達する。ｃｌａｓｓｉｆｉｅｒはパケットのヘッダからこのパケットにどのＳＦを適用すべきかを判断し、その情報をＮＳＨ（Network Service Header）として当該パケットへ挿入し、その後パケットを中継する。たとえば、このパケットにはＳＦ１のみを適用する場合を想定する。

ＳＦＦ１は、このパケットを受信すると、ＮＳＨの内容からこのパケットにはＳＦ１を適用することを知り、このパケットをＳＦ１へ転送する。ＳＦ１は、このパケットを処理し、ＳＦＦ１へ返送する。また、ＳＦＦ１は、このパケットをＳＦＦ２へ転送する。この例では、ＳＦ１のみをパケットに適用するので、ＳＦＦ２からＳＦＦｎは単にこのパケットを中継し、最終的にこのパケットはＷｅｂＳｅｒｖｅｒへ到達する。

このようなアーキテクチャを有するＳＦＣでは、ネットワーク事業者やサービス提供者の観点でＷＡＦやロードバランサなどのＳＦが用意されている。すなわち、ネットワーク事業者やサービス提供者の意向によりどのようなパケットをＳＦＣの対象とするかを決めているものである。

これに対して、以下で説明するものは、ネットワーク内でパケットを転送させるサービスにおいて利便性高く、サービス利用者が希望するパケットに、サービス利用者が希望する１つまたは複数の機能を作用させるためのアーキテクチャである。本実施形態では、そのようなアーキテクチャのことを、ＡＦＣ（Application Function Chaining）と呼び、ＡＦＣアーキテクチャにおいて作用される機能のことを、ＡＦ（Application Function）と呼ぶ。

［１．２．ＡＦＣの具体的説明］
（ＡＦＣｆｏｒＥｄｇｅ／Ｆｏｇ／Ｃｌｏｕｄアーキテクチャ）
ＡＦＣでは、ＡＦの特徴やユーザが求める性能により、ＡＦを設置するノード（後述する「ＡＦＮｏｄｅ」に該当）を選択することができる。たとえば、ネットワークの周辺に設置されるサーバ（ＥｄｇｅＳｅｒｖｅｒ）は、計算能力は高くないがユーザの機器からの通信遅延が小さい。逆にデータセンターに設置されるサーバ（ＣｌｏｕｄＳｅｒｖｅｒ）は、計算能力は高いがユーザの機器からの通信遅延は大きい。また、ネットワーク内部に設置されるサーバ（ＦｏｇＳｅｒｖｅｒ）は、計算能力やユーザの機器からの通信遅延はＥｄｇｅＳｅｒｖｅｒとＣｌｏｕｄＳｅｒｖｅｒの中間の性質を有する。ＡＦＣでは、これらサーバを、ＡＦＮｏｄｅとして適宜選択することができる。また、ＳＦＣでは、図１に示したように、通信経路は直線形状しか実現できないが、ＡＦＣでは、直線形状の他に、分岐と合流がある形状も実現することができる。

以下、より具体的に説明する。図２は、本開示の実施形態で提案するＡＦＣのアーキテクチャを示す説明図である。

まず、ＡＦＣＵｓｅｒは、ＡＦＣの利用者であり、ＡＦＣを利用するアプリケーションであるＡＦＣＡｐｐを実行する。ＡＦＣＡｐｐが動作するノードをＡｐｐＮｏｄｅと呼ぶ。また、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、ＡＦＣＡｐｐの一種であり、ＡＦＣを設置したり削除したりする。図２では、ＡＦＣＵｓｅｒ０がＡＦＣＣｏｎｓｔｒｕｃｔｏｒを、ＡＦＣＵｓｅｒ１がＡＦＣＡｐｐ１を、ＡＦＣＵｓｅｒ２がＡＦＣＡｐｐ２を、それぞれ実行するものとする。なお、ＡＦＣＡｐｐが、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒを兼ねてもよい。

また、ＡＦＣが適用される領域をＡＦＣｄｏｍａｉｎと呼ぶ。ＡＦＣｄｏｍａｉｎには、ＡＦＣＭａｎａｇｅｒとＡＡＡ（Authentication, Authorization, and Accounting）Ｓｅｒｖｅｒが存在する。ＡＦＣＭａｎａｇｅｒは、ＡＦやＡＦＣなどの設置や削除を管理する。ＡＡＡＳｅｒｖｅｒは、ＡＦＣＵｓｅｒの認証、認可およびアカウンティングを行う。認証とは、ＡＦＣＵｓｅｒの真正性を検証する処理である。認可とは、ＡＦＣＵｓｅｒが特定の処理を行う権限を有しているかを検証する処理である。アカウンティングとは、ＡＦＣＵｓｅｒが計算資源をどの程度消費したかを記録する処理である。

ＡＦＣｄｏｍａｉｎの境界には、ＧａｔｅＮｏｄｅが配置される。ＧａｔｅＮｏｄｅには、ＧａｔｅＤａｅｍｏｎ−ｐと呼ばれるプロセスが動作している。なお、図２ではＧａｔｅＤａｅｍｏｎ−ｐの記載を省略している。ＧａｔｅＤａｅｍｏｎ−ｐは、ＡＦＣごとに子プロセスであるＧａｔｅＤａｅｍｏｎを生成し、ＡＦＣに関する処理はＧａｔｅＤａｅｍｏｎが行う。ＡＦＣＡｐｐからアプリケーションメッセージを受信するＧａｔｅＤａｅｍｏｎをＩｎｇｒｅｓｓとも呼ぶ。一方、ＡＦＣＡｐｐへアプリケーションメッセージを送信するＧａｔｅＤａｅｍｏｎをＥｇｒｅｓｓとも呼ぶ。１台のＧａｔｅＮｏｄｅ上で１つのＡＦＣに関するＩｎｇｒｅｓｓとＥｇｒｅｓｓの双方が動作してもよい。図２は、ＧａｔｅＤａｅｍｏｎ１はＩｎｇｒｅｓｓとして動作し、ＧａｔｅＤａｅｍｏｎ２はＥｇｒｅｓｓとして動作する例である。

また、ＡＦＣｄｏｍａｉｎ内でＡＦが動作するノードをＡＦＮｏｄｅと呼ぶ。ＡＦＮｏｄｅには、ＡＦＣＤａｅｍｏｎ−ｐと呼ばれるプロセスが動作している。なお、図２ではＡＦＣＤａｅｍｏｎ−ｐの記載を省略している。ＡＦの起動時に、ＡＦＣＤａｅｍｏｎ−ｐは子プロセスであるＡＦＣＤａｅｍｏｎを作成し、その後のＡＦＣに関する処理はＡＦＣＤａｅｍｏｎが行う。ＡＦＣＤａｅｍｏｎは、ＡＦの実行結果によって次にアプリケーションメッセージを送信するＡＦＣＤａｅｍｏｎを切り換えることができる。図２では、ＡＦＣＤａｅｍｏｎ１は、ＡＦ１の実行結果によってアプリケーションメッセージの送信先をＡＦＣＤａｅｍｏｎ２あるいはＡＦＣＤａｅｍｏｎ３へ切り換えることができる。

また、ＡＦＣＡｐｐによるＡＦＣ利用は、Ｐｕｂ／Ｓｕｂ（Ｐｕｂｌｉｓｈ／Ｓｕｂｓｃｒｉｂｅ）方式（いわゆる出版−購読型モデル）に基づく。送信側のＡＦＣＡｐｐは、利用するＡＦＣを指定してＰｕｂパケットによりアプリケーションメッセージをＩｎｇｒｅｓｓへ送信する。一方、受信側のＡＦＣＡｐｐは、利用するＡＦＣを指定してＳｕｂパケットによりＥｇｒｅｓｓからのアプリケーションメッセージの到着を待つ。図２は、ＡＦＣＡｐｐ１が送信側のＡＦＣＡｐｐであり、ＡＦＣＡｐｐ２が受信側のＡＦＣＡｐｐとなっている例である。１つのアプリケーションが送信側と受信側を兼ねてもよい。

なお、ＡＦＣＭａｎａｇｅｒとＡＡＡＳｅｒｖｅｒとの間には、常に制御用ＴＬＳ（Transport Layer Security）コネクションが確立されているものとする。ＡＦＣＣｏｎｓｔｒｕｃｔｏｒとＡＦＣＭａｎａｇｅｒとの間の制御用ＴＬＳコネクションは、必要なときに確立される。ＡＦＣが設置されると、ＡＦＣを構成するＩｎｇｒｅｓｓとＡＦＣＤａｅｍｏｎの間、２つのＡＦＣＤａｅｍｏｎの間、および、ＡＦＣＤａｅｍｏｎとＥｇｒｅｓｓの間にはデータ用ＴＬＳコネクションが確立される。また、ＡＦＣが存在する間、ＡＦＣＭａｎａｇｅｒとＡＦＣを構成するＩｎｇｒｅｓｓ、ＡＦＣＤａｅｍｏｎ、および、Ｅｇｒｅｓｓとの間には、それぞれ制御用ＴＬＳコネクションが確立される。以上のように、ＡＦＣに関する制御パケットやデータパケットは、ＴＬＳコネクションを利用して送信されるため、通信データの盗聴や改竄は起こらない。

本ＡＦＣアーキテクチャは、様々なネットワーク構成に適用されてもよい。たとえば、本ＡＦＣアーキテクチャがテレコムネットワーク（ｅ．ｇ．，Ｗ−ＣＤＭＡ（Wideband Code Division Multiple Access），ＬＴＥ（Long Term Evolution），ＮＲ（New Radio））に適用される場合、ＡＰＰＮｏｄｅはＵｓｅｒＥｑｕｉｐｍｅｎｔ（ＵＥ）であってもよい。ＡＦｎｏｄｅは３ＧＰＰに規定されたＡｐｐｌｉｃａｔｉｏｎＦｕｎｃｔｉｏｎＮｏｄｅと同一であってもよい。また、ＡＦＣｄｏｍａｉｎは、テレコムネットワークのコアネットワーク（ｅ．ｇ．，５ＧＣ，５ＧＳ）上に仮想的に構築されるネットワークスライスにより実現されてもよい。この場合、ＡＦＣｄｏｍａｉｎ内に仮想的に構築される各ノード（ｅ．ｇ．，ＡＦＮｏｄｅ，ＧａｔｅＮｏｄｅ）は、ネットワークスライスを構成するネットワークスライスインスタンスにより構築されてもよい。

（ＧａｔｅＤａｅｍｏｎの設置手順）
次に、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒがＧａｔｅＤａｅｍｏｎを設置する手順について、図３を用いて説明する。図３は、ＧａｔｅＤａｅｍｏｎの設置処理の処理手順を示す図である。なお、図３には、ＡＦＣＵｓｅｒ０がＡＦＣＣｏｎｓｔｒｕｃｔｏｒを実行し、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒがＧａｔｅＮｏｄｅ１上にＧａｔｅＤａｅｍｏｎ１をＩｎｇｒｅｓｓとして設置する手順を示している。ここで、ＡＦＣＵｓｅｒ０の識別子をＵＩＤ−ｕｓｒ０とする。また、ＡＦＣＵｓｅｒ０の認証情報をＣｒｅｄ−ｕｓｒ０とする。Ｃｒｅｄ−ｕｓｒ０の内容は、ＡＦＣＵｓｅｒ０のパスワードなどが考えられる。また、ＧａｔｅＮｏｄｅ１のＩＰアドレスをＩＰ−ｇｔｎ１とする。

まず、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、ＡＦＣＭａｎａｇｅｒとの間に制御用ＴＬＳコネクションを確立する（ステップＳ１０１）。ここで、ＡＦＣＭａｎａｇｅｒにおける制御用ＴＬＳコネクションのためのソケットをＣＳｏｃｋ−ｍｇｒ−ｇｔ１とする。

そして、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、図４に示すＧａｔｅＳｅｔｕｐＲｅｑｕｅｓｔパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ１０２）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＧａｔｅＳｅｔｕｐＲｅｑｕｅｓｔ」である。ＧａｔｅＴｙｐｅフィールドの値は「Ｉｎｇｒｅｓｓ」である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ０である。Ｃｒｅｄｅｎｔｉａｌフィールドの値はＣｒｅｄ−ｕｓｒ０である。ＩＰＡｄｄｒｅｓｓフィールドの値はＩＰ−ｇｔｎ１である。

ＡＦＣＭａｎａｇｅｒは、ＧａｔｅＳｅｔｕｐＲｅｑｕｅｓｔパケットを受信すると、図６に示すＧａｔｅＡＡＲｅｑｕｅｓｔパケットをＡＡＡＳｅｒｖｅｒへ送信する（ステップＳ１０３）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＧａｔｅＡＡＲｅｑｕｅｓｔ」である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ０である。Ｃｒｅｄｅｎｔｉａｌフィールドの値はＣｒｅｄ−ｕｓｒ０である。ＩＰＡｄｄｒｅｓｓフィールドの値はＩＰ−ｇｔｎ１である。

ＡＡＡＳｅｒｖｅｒは、ＧａｔｅＡＡＲｅｑｕｅｓｔパケットを受信すると、ＵｓｅｒＩＤフィールドとＣｒｅｄｅｎｔｉａｌフィールドの値を基にＡＦＣＵｓｅｒ０を認証する。さらに、ＡＡＡＳｅｒｖｅｒは、ＡＦＣＵｓｅｒ０がＧａｔｅＮｏｄｅ１にＧａｔｅＤａｅｍｏｎを設置する権限を有しているかを検証する。続いて、ＡＡＡＳｅｒｖｅｒは、図７に示すＧａｔｅＡＡＲｅｓｐｏｎｓｅパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ１０４）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＧａｔｅＡＡＲｅｓｐｏｎｓｅ」である。Ｓｔａｔｕｓフィールドの値は処理が正常であることを示す「ＯＫ」である。

そして、ＡＦＣＭａｎａｇｅｒは、ＧａｔｅＤａｅｍｏｎ１−ｐと間に制御用ＴＬＳコネクションの確立を開始し（ステップＳ１０５）、ＧａｔｅＤａｅｍｏｎ１−ｐは、子プロセスとしてＧａｔｅＤａｅｍｏｎ１を生成する（ステップＳ１０６）。

生成されたＧａｔｅＤａｅｍｏｎ１は、制御用ＴＬＳコネクション確立処理を続行し、結果としてＡＦＣＭａｎａｇｅｒとＧａｔｅＤａｅｍｏｎ１の間に制御用ＴＬＳコネクションが確立される（ステップＳ１０７）。ここで、ＡＦＣＭａｎａｇｅｒにおける制御用ＴＬＳコネクションのためのソケットをＣＳｏｃｋ−ｍｇｒ−ｇｔ１とする。

そして、ＧａｔｅＤａｅｍｏｎ１は、送信側のＡＦＣＡｐｐとの間に確立するデータ用ＴＬＳコネクションのためのポートとしてＤＰｔ−ｇｔ１−ａｐｐを割り当て、図８に示すＤａｔａＰｏｒｔＮｏｔｉｆｉｃａｔｉｏｎパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ１０８）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＤａｔａＰｏｒｔＮｏｔｉｆｉｃａｔｉｏｎ」である。ＤａｔａＰｏｒｔフィールドの値はＤＰｔ−ｇｔ１−ａｐｐである。

そして、ＡＦＣＭａｎａｇｅｒは、ＧａｔｅＡＡＲｅｓｐｏｎｓｅパケットを受信すると、ＧａｔｅＳｅｓｓｉｏｎＫｅｙとしてＳＫｅｙ−ｕｓｒ０−ｇｔ１を生成し、保存するとともに（ステップＳ１０９）、ＧａｔｅＤａｅｍｏｎ１に識別子としてＡＦＩＤ−ｇｔ１を付与する。続いて、ＡＦＣＭａｎａｇｅｒは、図９に示すＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケットをＡＡＡＳｅｒｖｅｒへ送信する（ステップＳ１１０）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ」である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ０である。Ｕｓａｇｅフィールドの値は、ＡＦのために使われる資源に関する情報を示す。本実施形態では、Ｕｓａｇｅフィールドの値は、資源の用途を示し、この例では、ＧａｔｅＤａｅｍｏｎを設置したことを示す「ＧａｔｅＳｅｔｕｐ」が設定される。ＡＦＩＤフィールドの値はＡＦＩＤ−ｇｔ１である。ＡＦＣＩＤフィールドの値は［ｎｕｌｌ］である。

ＡＡＡＳｅｒｖｅｒは、ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケットを受信すると、Ｕｓａｇｅフィールドの値を記録する（ステップＳ１１１）。記録されたＵｓａｇｅフィールドの値は、ＡＡＡＳｅｒｖｅｒによるＡＦＣＡｐｐのアカウンティング（課金）に使われ得る。

そして、ＡＦＣＭａｎａｇｅｒは、図５に示すＧａｔｅＳｅｔｕｐＲｅｓｐｏｎｓｅパケットをＡＦＣＣｏｎｓｔｒｕｃｔｏｒへ送信する（ステップＳ１１２）。各フィールドの値は以下のとおりである。Ｔｙｐｅフィールドの値は「ＧａｔｅＳｅｔｕｐＲｅｓｐｏｎｓｅ」である。Ｓｔａｔｕｓフィールドの値は処理が正常であることを示す「ＯＫ」である。ＡＦＩＤフィールドの値はＡＦＩＤ−ｇｔ１である。ＤａｔａＰｏｒｔフィールドの値はＤＰｔ−ｇｔ１−ａｐｐである。ＧａｔｅＳｅｓｓｉｏｎＫｅｙフィールドの値はＳＫｅｙ−ｕｓｒ０−ｇｔ１である。

そして、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、ＧａｔｅＳｅｔｕｐＲｅｓｐｏｎｓｅパケットを受信すると、ＳＫｅｙ−ｕｓｒ０−ｇｔ１を保存し（ステップＳ１１３）、ＡＦＣＭａｎａｇｅｒとの間の制御用ＴＬＳコネクションを解放する（ステップＳ１１４）。

以上の処理の結果、ＧａｔｅＳｅｓｓｉｏｎＫｅｙであるＳＫｅｙ−ｕｓｒ０−ｇｔ１はＡＦＣＣｏｎｓｔｒｕｃｔｏｒとＡＦＣＭａｎａｇｅｒの間で共有される。また、ＡＦＣＭａｎａｇｅｒとＧａｔｅＤａｅｍｏｎ１の間には制御用ＴＬＳコネクションが維持される。

次に、同様の手順で、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、ＧａｔｅＮｏｄｅ２上にＥｇｒｅｓｓとしてＧａｔｅＤａｅｍｏｎ２を設置する。ＡＦＣＭａｎａｇｅｒは、ＧａｔｅＤａｅｍｏｎ２に識別子としてＡＦＩＤ−ｇｔ２を付与する。その際、ＧａｔｅＳｅｔｕｐＲｅｑｕｅｓｔパケットのＧａｔｅＴｙｐｅフィールドの値は「Ｅｇｒｅｓｓ」になる。

その結果、ＧａｔｅＤａｅｍｏｎ２は、受信側のＡＦＣＡｐｐとの間に確立するデータ用ＴＬＳコネクションのためのポートとしてＤＰｔ−ｇｔ２−ａｐｐを割り当て、ＡＦＣＭａｎａｇｅｒとＧａｔｅＤａｅｍｏｎ２の間でＧａｔｅＳｅｓｓｉｏｎＫｅｙとしてＳＫｅｙ−ｕｓｒ０−ｇｔ２が共有される。また、ＡＦＣＭａｎａｇｅｒとＧａｔｅＤａｅｍｏｎ２の間には制御用ＴＬＳコネクションが維持される。ここで、ＡＦＣＭａｎａｇｅｒにおける制御用ＴＬＳコネクションのためのソケットをＣＳｏｃｋ−ｍｇｒ−ｇｔ２とする。

上記の処理の結果、ＡＦＣＭａｎａｇｅｒは、図１０に示す各テーブルを保持する。具体的に、ＡＦＣＭａｎａｇｅｒは、ＡＦＣＵｓｅｒごとにＵｓｅｒＴａｂｌｅを保持する。ＵｓｅｒＴａｂｌｅの各フィールドの値は以下のとおりである。ＰｔｒｔｏＮｅｘｔＵｓｅｒＴａｂｌｅフィールドの値は他のＵｓｅｒＴａｂｌｅを指すポインタである。この時点では値は［ｎｕｌｌ］である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ０である。ＰｔｒｔｏＧａｔｅＴａｂｌｅフィールドの値はＧａｔｅＴａｂｌｅを指すポインタである。ＰｔｒｔｏＡＦＴａｂｌｅフィールドの値はＡＦＴａｂｌｅを指すポインタである。この時点では値は［ｎｕｌｌ］である。ＰｔｒｔｏＡＦＣＴａｂｌｅフィールドの値はＡＦＣＴａｂｌｅを指すポインタである。この時点では値は［ｎｕｌｌ］である。

また、ＡＦＣＭａｎａｇｅｒは、ＧａｔｅＤａｅｍｏｎごとにＧａｔｅＴａｂｌｅを保持する。１つ目のＧａｔｅＴａｂｌｅはＧａｔｅＤａｅｍｏｎ１のためのものであり、各フィールドの値は以下のとおりである。ＰｔｒｔｏＮｅｘｔＧａｔｅＴａｂｌｅフィールドの値は２つ目のＧａｔｅＴａｂｌｅを指すポインタである。ＩＰＡｄｄｒｅｓｓフィールドの値はＩＰ−ｇｔｎ１である。ＡＦＩＤフィールドの値はＡＦＩＤ−ｇｔ１である。ＣｏｎｔｒｏｌＳｏｃｋｅｔフィールドの値はＣＳｏｃｋ−ｍｇｒ−ｇｔ１である。ＧａｔｅＳｅｓｓｉｏｎＫｅｙフィールドの値はＳＫｅｙ−ｕｓｒ０−ｇｔ１である。ＤａｔａＰｏｒｔフィールドの値はＤＰｔ−ｇｔ１−ａｐｐである。

２つ目のＧａｔｅＴａｂｌｅはＧａｔｅＤａｅｍｏｎ２のためのものであり、各フィールドの値は以下のとおりである。ＰｔｒｔｏＮｅｘｔＧａｔｅＴａｂｌｅフィールドの値は［ｎｕｌｌ］である。ＩＰＡｄｄｒｅｓｓフィールドの値はＩＰ−ｇｔｎ２である。ＡＦＩＤフィールドの値はＡＦＩＤ−ｇｔ２である。ＣｏｎｔｒｏｌＳｏｃｋｅｔフィールドの値はＣＳｏｃｋ−ｍｇｒ−ｇｔ２である。ＧａｔｅＳｅｓｓｉｏｎＫｅｙフィールドの値はＳＫｅｙ−ｕｓｒ０−ｇｔ２である。ＤａｔａＰｏｒｔフィールドの値はＤＰｔ−ｇｔ２−ａｐｐである。

また、ＧａｔｅＤａｅｍｏｎ１の設置後に、ＧａｔｅＤａｅｍｏｎ１は、図１１に示すＩｎｇｒｅｓｓＴａｂｌｅを保持する。ＩｎｇｒｅｓｓＴａｂｌｅの各フィールドの値は以下のとおりである。ＡＦＣＳｅｓｓｉｏｎＫｅｙフィールドの値は未定義（［ｕｎｄｅｆ］）である。ＡｐｐＤａｔａＰｏｒｔフィールドの値はＤＰｔ−ｇｔ１−ａｐｐである。ＮｏｏｆＩｎｐｕｔＡｐｐｓフィールドの値は、このＧａｔｅＤａｅｍｏｎ１とデータ用ＴＬＳコネクションを確立しているアプリケーションの個数を示す。この時点では値は０である。このフィールドに続いてＮｏｏｆＩｎｐｕｔＡｐｐｓフィールドの値が示す個数分のＤａｔａＩｎｐｕｔＳｏｃｋｅｔフィールドが設けられるが、この時点ではまだ存在しない。ＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔフィールドの値は、次にアプリケーションメッセージを送信するソケットを示す。この時点では値は未定義（［ｕｎｄｅｆ］）である。

また、ＧａｔｅＤａｅｍｏｎ２の設置後に、ＧａｔｅＤａｅｍｏｎ２は、図１２に示すＥｇｒｅｓｓＴａｂｌｅを保持する。ＥｇｒｅｓｓＴａｂｌｅの各フィールドの値は以下のとおりである。ＡＦＣＳｅｓｓｉｏｎＫｅｙフィールドの値は未定義（［ｕｎｄｅｆ］）である。ＡｐｐＤａｔａＰｏｒｔフィールドの値はＤＰｔ−ｇｔ２−ａｐｐである。ＮｏｏｆＤａｔａＩｎｐｕｔＳｏｃｋｅｔｓフィールドの値は、ＡＦＣＤａｅｍｏｎからアプリケーションメッセージを受信するためのソケットの個数を示す。この時点では値は０である。このフィールドに続いてＮｏｏｆＤａｔａＩｎｐｕｔＳｏｃｋｅｔｓフィールドの値が示す個数分のＤａｔａＩｎｐｕｔＳｏｃｋｅｔフィールドが設けられるが、この時点ではまだ存在しない。ＮｏｏｆＯｕｔｐｕｔＡｐｐｓフィールドの値は、このＧａｔｅＤａｅｍｏｎ２との間にデータ用ＴＬＳコネクションを確立しているアプリケーションの個数を示す。この時点では値は０である。このフィールドに続いてＮｏｏｆＯｕｔｐｕｔＡｐｐｓフィールドの値が示す個数分のＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔフィールドが設けられるが、この時点ではまだ存在しない。

（ＡＦの設置手順）
次に、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒがＡＦを設置する手順について、図１３を用いて説明する。図１３は、ＡＦの設置処理の処理手順を示す図である。なお、図１３には、ＡＦＣＵｓｅｒ０が起動したＡＦＣＣｏｎｓｔｒｕｃｔｏｒがＡＦＮｏｄｅ１上にＡＦ１を設置する手順を示している。ここで、ＡＦＮｏｄｅ１のＩＰアドレスをＩＰ−ａｆｎ１とする。また、ＡＦ１の実行形ファイル名をＡＦＮａｍｅ−ａｆ１とする。また、ＡＦ１を起動する際のパラメータをＡＦＰａｒａｍ−ａｆ１とする。

まず、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、ＡＦＣＭａｎａｇｅｒとの間に制御用ＴＬＳコネクションを確立する（ステップＳ２０１）。

そして、ＡＦＣＵｓｅｒは、図１４に示すＡＦＳｅｔｕｐＲｅｑｕｅｓｔパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ２０２）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡＦＳｅｔｕｐＲｅｑｕｅｓｔ」である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ０である。Ｃｒｅｄｅｎｔｉａｌフィールドの値はＣｒｅｄ−ｕｓｒ０である。ＩＰＡｄｄｒｅｓｓフィールドの値はＩＰ−ａｆｎ１である。ＡＦＮａｍｅフィールドの値はＡＦＮａｍｅ−ａｆ１である。ＡＦＰａｒａｍｅｔｅｒフィールドの値はＡＦＰｒａｍ−ａｆ１である。

そして、ＡＦＣＭａｎａｇｅｒは、ＡＦＳｅｔｕｐＲｅｑｕｅｓｔパケットを受信すると、図１６に示すＡＦＡＡＲｅｑｕｅｓｔパケットをＡＡＡＳｅｒｖｅｒへ送信する（ステップＳ２０３）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡＦＡＡＲｅｑｕｅｓｔ」である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ０である。Ｃｒｅｄｅｎｔｉａｌフィールドの値はＣｒｅｄ−ｕｓｒ０である。ＩＰＡｄｄｒｅｓｓフィールドの値はＩＰ−ａｆｎ１である。ＡＦＮａｍｅフィールドの値はＡＦＮａｍｅ−ａｆ１である。

そして、ＡＡＡＳｅｒｖｅｒは、ＡＦＡＡＲｅｑｕｅｓｔパケットを受信すると、ＵｓｅｒＩＤフィールドとＣｒｅｄｅｎｔｉａｌフィールドの値を基にＡＦＣＵｓｅｒ０を認証し、ＡＦＣＵｓｅｒ０がＡＦＮｏｄｅ１においてＡＦ１を起動する権限を有しているかを検証する。続いて、ＡＡＡＳｅｒｖｅｒは、図１７に示すＡＦＡＡＲｅｓｐｏｎｓｅパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ２０４）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡＦＡＡＲｅｓｐｏｎｓｅ」である。Ｓｔａｔｕｓフィールドの値は認証認可の確認が正常であることを示す「ＯＫ」である。

そして、ＡＦＣＭａｎａｇｅｒは、ＡＦＣＤａｅｍｏｎ１−ｐとの間に制御用ＴＬＳコネクションの確立を開始し（ステップＳ２０５）、ＡＦＣＤａｅｍｏｎ１−ｐは、子プロセスとしてＡＦＣＤａｅｍｏｎ１を生成する（ステップＳ２０６）。

生成されたＡＦＣＤａｅｍｏｎ１は、制御用ＴＬＳコネクション確立処理を続行し、結果としてＡＦＣＭａｎａｇｅｒとＡＦＣＤａｅｍｏｎ１の間に制御用ＴＬＳコネクションが確立される（ステップＳ２０７）。ここで、ＡＦＣＭａｎａｇｅｒにおける制御用ＴＬＳコネクションのためのソケットをＣＳｏｃｋ−ｍｇｒ−ａｆ１とする。また、ＡＦＣＤａｅｍｏｎ１における制御用ＴＬＳコネクションのためのソケットをＣＳｏｃｋ−ａｆ１−ｍｇｒとする。

そして、ＡＦＣＭａｎａｇｅｒは、図１８に示すＡＦＩｎｖｏｋｅＲｅｑｕｅｓｔパケットをＡＦＣＤａｅｍｏｎ１へ送信する（ステップＳ２０８）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡＦＩｎｖｏｋｅＲｅｑｕｅｓｔ」である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ０である。ＡＦＮａｍｅフィールドの値はＡＦＮａｍｅ−ａｆ１である。ＡＦＰａｒａｍｅｔｅｒフィールドの値はＡＦＰｒａｍ−ａｆ１である。

ＡＦＣＤａｅｍｏｎ１は、ＡＦＩｎｖｏｋｅＲｅｑｕｅｓｔパケットを受信すると、ＡＦＰａｒａｍ−ａｆ１を指定してＡＦ１を起動する（ステップＳ２０９）。その際、ＡＦ１へのデータ入力ポートであるＰｔ−ａｆ１−ｉｎｐｕｔ、ＡＦ１からのデータ出力ポートであるＰｔ−ａｆ１−ｏｕｔｐｕｔ、および、ＡＦ１からの状態出力ポートであるＰｔ−ａｆ１−ｓｔａｔの３つのポートを生成する。

そして、ＡＦＣＤａｅｍｏｎ１は、図１９に示すＡＦＩｎｖｏｋｅＲｅｓｐｏｎｓｅパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ２１０）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡＦＩｎｖｏｋｅＲｅｓｐｏｎｓｅ」である。Ｓｔａｔｕｓフィールドの値は処理が正常であることを示す「ＯＫ」である。

ＡＦＣＭａｎａｇｅｒは、ＡＦＩｎｖｏｋｅＲｅｓｐｏｎｓｅパケットを受信すると、ＡＦ１に識別子としてＡＦＩＤ−ａｆ１を付与する。さらにＡＦＳｅｓｓｉｏｎＫｅｙとしてＳＫｅｙ−ｕｓｒ０−ａｆ１を生成し、保存する（ステップＳ２１１）。

そして、ＡＦＣＭａｎａｇｅｒは、図２０に示すＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケットをＡＡＡＳｅｒｖｅｒへ送信する（ステップＳ２１２）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ」である。ＡＦＣＩＤフィールドの値は［ｎｕｌｌ］である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ０である。ＩＰＡｄｄｒｅｓｓフィールドの値はＩＰ−ａｆｎ１である。ＡＦＩＤフィールドの値はＡＦＩＤ−ａｆ１である。Ｕｓａｇｅフィールドの値は、ＡＦ１を設置したことを表す「ＡＦＳｅｔｕｐ」である。

ＡＡＡＳｅｒｖｅｒは、ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケットを受信すると、Ｕｓａｇｅフィールドの値を記録する（ステップＳ２１３）。

そして、ＡＦＣＭａｎａｇｅｒは、図１５に示すＡＦＳｅｔｕｐＲｅｓｐｏｎｓｅパケットをＡＦＣＣｏｎｓｔｒｕｃｔｏｒへ送信する（ステップＳ２１４）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡＦＳｅｔｕｐＲｅｓｐｏｎｓｅ」である。Ｓｔａｔｕｓフィールドの値は処理が正常であることを示す「ＯＫ」である。ＡＦＩＤフィールドの値はＡＦＩＤ−ａｆ１である。ＡＦＳｅｓｓｉｏｎＫｅｙフィールドの値はＳＫｅｙ−ｕｓｒ０−ａｆ１である。

ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、ＡＦＳｅｔｕｐＲｅｓｐｏｎｓｅパケットを受信すると、ＳＫｅｙ−ｕｓｒ０−ａｆ１を保存し（ステップＳ２１５）、ＡＦＣＭａｎａｇｅｒとの間の制御用ＴＬＳコネクションを解放する（ステップＳ２１６）。

以上の処理の結果、ＡＦＳｅｓｓｉｏｎＫｅｙであるＳＫｅｙ−ｕｓｒ０−ａｆ１は、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒとＡＦＣＭａｎａｇｅｒとの間で共有される。また、ＡＦＣＭａｎａｇｅｒとＡＦＣＤａｅｍｏｎ１の間には制御用ＴＬＳコネクションが維持される。

次に、同様の手順で、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、ＡＦＮｏｄｅ２上にＡＦＣＤａｅｍｏｎ２を設置し、ＡＦＮｏｄｅ３上にＡＦＣＤａｅｍｏｎ３を設置する。ＡＦＣＭａｎａｇｅｒとＡＦＣＤａｅｍｏｎ２との間にはＡＦＳｅｓｓｉｏｎＫｅｙとしてＳＫｅｙ−ｕｓｒ０−ａｆ２が共有され、ＡＦＣＭａｎａｇｅｒとＡＦＣＤａｅｍｏｎ３との間にはＡＦＳｅｓｓｉｏｎＫｅｙとしてＳＫｅｙ−ｕｓｒ０−ａｆ３が共有される。

また、ＡＦＣＭａｎａｇｅｒとＡＦＣＤａｅｍｏｎ２との間には制御用ＴＬＳコネクションが維持される。ここで、ＡＦＣＭａｎａｇｅｒにおける制御用ＴＬＳコネクションのためのソケットをＣＳｏｃｋ−ｍｇｒ−ａｆ２とする。また、ＡＦＣＤａｅｍｏｎ２における制御用ＴＬＳコネクションのためのソケットをＣＳｏｃｋ−ａｆ２−ｍｇｒとする。

また、ＡＦＣＭａｎａｇｅｒとＡＦＣＤａｅｍｏｎ３との間には制御用ＴＬＳコネクションが維持される。ここで、ＡＦＣＭａｎａｇｅｒにおける制御用ＴＬＳコネクションのためのソケットをＣＳｏｃｋ−ｍｇｒ−ａｆ３とする。また、ＡＦＣＤａｅｍｏｎ３における制御用ＴＬＳコネクションのためのソケットをＣＳｏｃｋ−ａｆ３−ｍｇｒとする。

ＡＦ１〜ＡＦ３を設置した結果、ＡＦＣＭａｎａｇｅｒは、図２１に示す各テーブルを保持する。図１０に示したＵｓｅｒＴａｂｌｅのＰｔｒｔｏＡＦＴａｂｌｅフィールドの値はＡＦＴａｂｌｅを指すポインタとなり、３つのＡＦＴａｂｌｅが加わっている。１つ目のＡＦＴａｂｌｅは、ＡＦ１に関するものである。各フィールドの値は以下のとおりである。ＰｔｒｔｏＮｅｘｔＡＦＴａｂｌｅフィールドの値は、２つ目のＡＦＴａｂｌｅへのポインタである。ＩＰＡｄｄｒｅｓｓフィールドの値はＩＰ−ａｆｎ１である。ＡＦＩＤフィールドの値はＡＦＩＤ−ａｆ１である。ＣｏｎｔｒｏｌＳｏｃｋｅｔフィールドの値はＣＳｏｃｋ−ｍｇｒ−ａｆ１である。ＡＦＳｅｓｓｉｏｎＫｅｙフィールドの値はＳＫｅｙ−ｕｓｒ０−ａｆ１である。

２つ目のＡＦＴａｂｌｅは、ＡＦ２に関するものであり、３つ目のＡＦＴａｂｌｅはＡＦ３に関するものである。２つ目と３つ目のＡＦＴａｂｌｅについても各フィールドの値は同様であるが、３つ目のＡＦＴａｂｌｅのＰｔｒｔｏＮｅｘｔＡＦＴａｂｌｅフィールドの値は［ｎｕｌｌ］である。

また、ＡＦ１の設置後に、ＡＦＣＤａｅｍｏｎ１は、図２２に示すＡＦＣＴａｂｌｅを保持する。各フィールドの値は以下のとおりである。ＣｏｎｔｒｏｌＳｏｃｋｅｔフィールドの値はＣＳｏｃｋ−ａｆ１−ｍｇｒである。ＡＦＤａｔａＩｎｐｕｔＰｏｒｔフィールドの値はＰｔ−ａｆ１−ｉｎｐｕｔである。ＡＦＤａｔａＯｕｔｐｕｔＰｏｒｔフィールドの値はＰｔ−ａｆ１−ｏｕｔｐｕｔである。ＡＦＳｔａｔｕｓＰｏｒｔフィールドの値はＰｔ−ａｆ１−ｓｔａｔである。

ＮｏｏｆＤａｔａＩｎｐｕｔＳｏｃｋｅｔｓフィールドの値は、アプリケーションメッセージを受信するためにＧａｔｅＤａｅｍｏｎや他のＡＦＣＤａｅｍｏｎとの間に確立したデータ用ＴＬＳコネクションのためのソケットの個数を示す。この時点での値は０である。本フィールドの値が１以上の場合、本フィールドに続いて本フィールドの値が示す個数分のＤａｔａＩｎｐｕｔＳｏｃｋｅｔフィールドが続く。この時点では、ＤａｔａＩｎｐｕｔＳｏｃｋｅｔフィールドは存在しない。

ＮｏｏｆＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔｓフィールドの値は、アプリケーションメッセージを送信するために確立したデータ用ＴＬＳコネクションのためのソケットの個数を示す。この時点での値は０である。本フィールドの値が１以上の場合、本フィールドに続いて本フィールドの値が示す個数分のＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔフィールドが続く。この時点では、ＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔフィールドは存在しない。

Ｏｐｅｒａｔｏｒフィールドは、ＡＦＳｔａｔｕｓＰｏｒｔから得られたＡＦ１の返戻値に適用する演算子を示す。この時点での値は未定義（［ｕｎｄｅｆ］）である。Ｏｐｅｒａｎｄフィールドは、Ｏｐｅｒａｔｏｒフィールドが示す演算子に対するオペランドである。この時点での値は未定義（［ｕｎｄｅｆ］）である。

ＴｒｕｅＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔＩｎｄｅｘフィールドの値は、ＡＦ１の返戻値にＯｐｅｒａｔｏｒフィールドが示す演算子とＯｐｅｒａｎｄフィールドが示すオペランドを適用したとの値（判定値）が真であるときにアプリケーションメッセージを送信するＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔのインデクスを示す。この時点での値は未定義（［ｕｎｄｅｆ］）である。ＦａｌｓｅＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔＩｎｄｅｘフィールドの値は、判定値が偽であるときにアプリケーションメッセージを送信するＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔのインデクスを示す。この時点での値は未定義（［ｕｎｄｅｆ］）である。

また、ＡＦ２の設置後に、ＡＦＣＤａｅｍｏｎ２は、図２３に示したＡＦＣＴａｂｌｅを保持する。また、ＡＦ３の設置後に、ＡＦＣＤａｅｍｏｎ３は、図２４に示したＡＦＣＴａｂｌｅを保持する。これらＡＦＣＤａｅｍｏｎ２やＡＦＣＤａｅｍｏｎ３が保持するＡＦＣＴａｂｌｅの各フィールドの値は、ＡＦＣＤａｅｍｏｎ１が保持するＡＦＣＴａｂｌｅの各フィールドの値と同様である。

（ＡＦＣの設置手順）
次に、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒが、図２に示したＡＦＣを設置する手順について、図２５および図２６を用いて説明する。図２５は、ＡＦＣの設置処理の処理手順を示す図（その１）である。また、図２６は、ＡＦＣの設置処理の処理手順を示す図（その２）である。なお、図２５および図２６に示す処理手順で設置されるＡＦＣをＡＦＣ１と呼ぶこととする。

まず、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、ＡＦＣＭａｎａｇｅｒとの間に制御用ＴＬＳコネクションを確立する（ステップＳ３０１）。

ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、図２７に示すＡＦＣＳｅｔｕｐＲｅｑｕｅｓｔパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ３０２）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡＦＣＳｅｔｕｐＲｅｑｕｅｓｔ」である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ０である。続く２つのフィールドはＩｎｇｒｅｓｓとなるＧａｔｅＤａｅｍｏｎ１に関するものである。ＡＦＩＤフィールドの値はＡＦＩＤ−ｇｔ１である。Ｃｅｒｔｉｆｉｃａｔｅフィールドの値はＣｅｒｔ−ｕｓｒ０−ｇｔ１である。Ｃｅｒｔ−ｕｓｒ０−ｇｔ１の作成方法としては、本パケットにＳＫｅｙ−ｕｓｒ０−ｇｔ１を付加したものをハッシュ関数にかけた結果とすることなどが考えられる。

ＮｏｏｆＡＦｓフィールドの値はＡＦＣを構成するＡＦの数を示す。この例では値は３である。続く２つのフィールドはＡＦ１に関するものである。ＡＦＩＤフィールドの値はＡＦＩＤ−ａｆ１である。Ｃｅｒｔｉｆｉｃａｔｅフィールドの値はＣｅｒｔ−ｕｓｒ０−ａｆ１である。Ｃｅｒｔ−ｕｓｒ０−ａｆ１の作成方法としては、本パケットにＳＫｅｙ−ｕｓｒ０−ａｆ１を付加したものをハッシュ関数にかけた結果とすることなどが考えられる。続く２つのフィールドはＡＦ２に関するものであり、さらに続く２つのフィールドはＡＦ３に関するものである。

ＮｏｏｆＥｇｒｅｓｓｅｓフィールドの値は、ＥｇｒｅｓｓとなるＧａｔｅＤａｅｍｏｎの数を示す。この例では値は１である。続く２つのフィールドはＥｇｒｅｓｓとなるＧａｔｅＤａｅｍｏｎ２に関するものである。ＡＦＩＤフィールドの値はＡＦＩＤ−ｇｔ２である。Ｃｅｒｔｉｆｉｃａｔｅフィールドの値はＣｅｒｔ−ｕｓｒ０−ｇｔ２である。Ｃｅｒｔ−ｕｓｒ０−ｇｔ２の作成方法としては、本パケットにＳＫｅｙ−ｕｓｒ０−ｇｔ２を付加したものをハッシュ関数にかけた結果とすることなどが考えられる。

ＮｏｏｆＣｏｎｎｅｃｔｉｏｎｓフィールドの値は、ＡＦＣを構成するデータ用ＴＬＳコネクションの数を示す。この例では値は５である（ＧａｔｅＤａｅｍｏｎ１とＡＦＣＤａｅｍｏｎ１との間、ＡＦＣＤａｅｍｏｎ１とＡＦＣＤａｅｍｏｎ２との間、ＡＦＣＤａｅｍｏｎ１とＡＦＣＤａｅｍｏｎ３との間、ＡＦＣＤａｅｍｏｎ３とＡＦＣＤａｅｍｏｎ２との間、および、ＡＦＣＤａｅｍｏｎ２とＧａｔｅＤａｅｍｏｎ２との間）。続く２つのフィールドは１つ目のデータ用ＴＬＳコネクションに関するものである。ＳｒｃＡＦＩｎｄｅｘフィールドの値は、データ用ＴＬＳコネクションの確立を能動的に行うＡＦＣＤａｅｍｏｎあるいはＧａｔｅＤａｅｍｏｎのインデクスを示す。ＤｓｔＡＦＩｎｄｅｘフィールドの値は、データ用ＴＬＳコネクションの確立を受動的に行うＡＦＣＤａｅｍｏｎあるいはＧａｔｅＤａｅｍｏｎのインデクスを示す。この例ではＳｒｃＤａｅｍｏｎＩｎｄｅｘフィールドの値は０であり、これはＧａｔｅＤａｅｍｏｎ１を示す。ＤｓｔＤａｅｍｏｎＩｎｄｅｘフィールドの値は１であり、これはＡＦＣＤａｅｍｏｎ１を示す。以下、４組の２つのフィールドの組が４つのデータ用ＴＬＳコネクションを示す。

ＮｏｏｆＣｏｎｄｉｔｉｏｎｓフィールドの値は、ＡＦの返戻値によってＡＦＣが分岐する場合の条件の個数を示す。この例では値は１である（ＡＦＣＤａｅｍｏｎ１における分岐）。続く５つのフィールドは、１つの条件に関するものである。ＡＦＩｎｄｅｘフィールドの値は、この条件を設定するＡＦのインデクスである。この例では値は１であり、これはＡＦ１を示す。Ｏｐｅｒａｔｏｒフィールドの値は、ＡＦの返戻値に適用する演算子を示す。この例ではＯＰ−ａｆ１である。Ｏｐｅｒａｎｄフィールドの値は、上記の演算子のオペランドを示す。この例ではＯｐｄ−ａｆ１である。ＴｒｕｅＣｏｎｎＩｎｄｅｘフィールドの値は、上記の演算の結果が真の場合にアプリケーションメッセージを送信するデータ用ＴＬＳコネクションのインデクスである。この例では値は１（ＡＦ１からＡＦ２へのデータ用ＴＬＳコネクション）である。ＦａｌｓｅＣｏｎｎＩｎｄｅｘフィールドの値は、上記の演算の結果が偽の場合にアプリケーションメッセージを送信するデータ用ＴＬＳコネクションのインデクスである。この例では値は２（ＡＦ１からＡＦ３へのデータ用ＴＬＳコネクション）である。

ＡＦＣＭａｎａｇｅｒは、ＡＦＣＳｅｔｕｐＲｅｑｕｅｓｔパケットを受信すると、ＡＦＣＳｅｔｕｐＲｅｑｕｅｓｔパケットに含まれる５組のＡＦＩＤフィールドの値とＣｅｒｔｉｆｉｃａｔｅフィールドの値の対に基づき、ＡＦＣＵｓｅｒ０がＧａｔｅＤａｅｍｏｎ１、ＡＦ１、ＡＦ２、ＡＦ３およびＧａｔｅＤａｅｍｏｎ２を利用する権限を有することを検証する。続いて、ＡＦＣＭａｎａｇｅｒは、ＡＦＣＳｅｔｕｐＲｅｑｕｅｓｔパケットが示す５つのデータ用ＴＬＳコネクションを確立する。１つ目のコネクション（ＧａｔｅＤａｅｍｏｎ１とＡＦＣＤａｅｍｏｎ１との間）を確立するため、ＡＦＣＭａｎａｇｅｒは図２９に示すＣｏｎｎＥｓｔａｂＰＲｅｑｕｅｓｔパケットをＡＦＣＤａｅｍｏｎ１へ送信する（ステップＳ３０３）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＣｏｎｎＥｓｔａｂＰＲｅｑｕｅｓｔ」である。

そして、ＡＦＣＤａｅｍｏｎ１は、ＣｏｎｎＥｓｔａｂＰＲｅｑｕｅｓｔパケットを受信すると、データ用ＴＬＳコネクションを受動的に確立するためのポートであるＤＰｔ−ａｆ１−ｇｔ１を生成する。続いて、ＡＦＣＤａｅｍｏｎ１は、図３０に示すＣｏｎｎＥｓｔａｂＰＲｅｓｐｏｎｓｅパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ３０４）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＣｏｎｎＥｓｔａｂＰＲｅｓｐｏｎｓｅ」である。Ｓｔａｔｕｓフィールドの値は処理が正常であることを示す「ＯＫ」である。ＤａｔａＰｏｒｔフィールドの値はＤＰｔ−ａｆ１−ｇｔ１である。

ＡＦＣＭａｎａｇｅｒは、ＣｏｎｎＥｓｔａｂＰＲｅｓｐｏｎｓｅパケットを受信すると、図３１に示すＣｏｎｎＥｓｔａｂＡＲｅｑｅｕｓｔパケットをＧａｔｅＤａｅｍｏｎ１へ送信する（ステップＳ３０５）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＣｏｎｎＥｓｔａｂＡＲｅｑｕｅｓｔ」である。ＩＰＡｄｄｒｅｓｓフィールドの値はＩＰ−ａｆｎ１である。ＤａｔａＰｏｒｔフィールドの値はＤＰｔ−ａｆ１−ｇｔ１である。

ＧａｔｅＤａｅｍｏｎ１は、ＣｏｎｎＥｓｔａｂＡＲｅｑｕｅｓｔパケットを受信すると、ＡＦＣＤａｅｍｏｎ１のデータ用ポートであるＤＰｔ−ａｆ１−ｇｔ１との間にデータ用ＴＬＳコネクションを確立する（ステップＳ３０６）。ここで、ＧａｔｅＤａｅｍｏｎ１におけるデータ用ＴＬＳコネクションのためのポートをＤＰｔ−ｇｔ１−ａｆ１とする。また、ＧａｔｅＤａｅｍｏｎ１におけるデータ用ＴＬＳコネクションのためのソケットをＤＳｏｃｋ−ｇｔ１−ａｆ１とする。また、ＡＦＣＤａｅｍｏｎ１におけるデータ用ＴＬＳコネクションのためのソケットをＤＳｏｃｋ−ａｆ１−ｇｔ１とする。

そして、ＧａｔｅＤａｅｍｏｎ１は、図３２に示すＣｏｎｎＥｓｔａｂＡＲｅｓｐｏｎｓｅパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ３０７）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＣｏｎｎＥｓｔａｂＡＲｅｓｐｏｎｓｅ」である。Ｓｔａｔｕｓフィールドの値は処理が正常であることを示す「ＯＫ」である。ＤａｔａＳｏｃｋｅｔフィールドの値はＤＳｏｃｋ−ｇｔ１−ａｆ１である。

なお、ＡＦＣＤａｅｍｏｎ１とＡＦＣＤａｅｍｏｎ２の間、ＡＦＣＤａｅｍｏｎ１とＡＦＣＤａｅｍｏｎ３の間、ＡＦＣＤａｅｍｏｎ３とＡＦＣＤａｅｍｏｎ２の間、および、ＡＦＣＤａｅｍｏｎ２とＧａｔｅＤａｅｍｏｎ２の間のデータ用ＴＬＳコネクションも、上記のステップＳ３０３〜Ｓ３０７と同様にして確立する（ステップＳ３０８）。

ここで、ＡＦＣＤａｅｍｏｎ１とＡＦＣＤａｅｍｏｎ２の間のデータ用ＴＬＳコネクションにおいて、ＡＦＣＤａｅｍｏｎ１におけるポートをＤＰｔ−ａｆ１−ａｆ２とし、ソケットをＤＳｏｃｋ−ａｆ１−ａｆ２とする。また、ＡＦＣＤａｅｍｏｎ２におけるポートをＤＰｔ−ａｆ２−ａｆ１とし、ソケットをＤＳｏｃｋ−ａｆ２−ａｆ１とする。

また、ＡＦＣＤａｅｍｏｎ１とＡＦＣＤａｅｍｏｎ３の間のデータ用ＴＬＳコネクションにおいて、ＡＦＣＤａｅｍｏｎ１におけるポートをＤＰｔ−ａｆ１−ａｆ３とし、ソケットをＤＳｏｃｋ−ａｆ１−ａｆ３とする。また、ＡＦＣＤａｅｍｏｎ３におけるポートをＤＰｔ−ａｆ３−ａｆ１とし、ソケットをＤＳｏｃｋ−ａｆ３−ａｆ１とする。

また、ＡＦＣＤａｅｍｏｎ３とＡＦＣＤａｅｍｏｎ２の間のデータ用ＴＬＳコネクションにおいて、ＡＦＣＤａｅｍｏｎ３におけるポートをＤＰｔ−ａｆ３−ａｆ２とし、ソケットをＤＳｏｃｋ−ａｆ３−ａｆ２とする。また、ＡＦＣＤａｅｍｏｎ２におけるポートをＤＰｔ−ａｆ２−ａｆ３とし、ソケットをＤＳｏｃｋ−ａｆ２−ａｆ３とする。

また、ＡＦＣＤａｅｍｏｎ２とＧａｔｅＤａｅｍｏｎ２の間のデータ用ＴＬＳコネクションにおいて、ＡＦＣＤａｅｍｏｎ２におけるポートをＤＰｔ−ａｆ２−ｇｔ２とし、ソケットをＤＳｏｃｋ−ａｆ２−ｇｔ２とする。また、ＧａｔｅＤａｅｍｏｎ２におけるポートをＤＰｔ−ｇｔ２−ａｆ２とし、ソケットをＤＳｏｃｋ−ｇｔ２−ａｆ２とする。

ＡＦＣＭａｎａｇｅｒは、各ＡＦＣＤａｅｍｏｎおよび各ＧａｔｅＤｅａｍｏｎにおけるデータ用ＴＬＳコネクションのためのソケットを知る。

続いて、ＡＦＣＭａｎａｇｅｒは、図３３に示すＳｅｔＣｏｎｄｉｔｉｏｎＲｅｑｕｅｓｔパケットをＡＦＣＤａｅｍｏｎ１へ送信する（ステップＳ３０９）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＳｅｔＣｏｎｄｉｔｉｏｎＲｅｑｕｅｓｔ」である。Ｏｐｅｒａｔｏｒフィールドの値はＯｐ−ａｆ１である。Ｏｐｅｒａｎｄフィールドの値はＯｐｄ−ａｆ１である。ＴｒｕｅＤａｔａＳｏｃｋｅｔフィールドの値はＤＳｏｃｋ−ａｆ１−ａｆ２である。ＦａｌｓｅＤａｔａＳｏｃｋｅｔフィールドの値はＤＳｏｃｋ−ａｆ１−ａｆ３である。

そして、ＡＦＣＤａｅｍｏｎ１は、ＳｅｔＣｏｎｄｉｔｉｏｎＲｅｑｕｅｓｔパケットを受信すると、Ｏｐｅｒａｔｏｒフィールドの値、Ｏｐｅｒａｎｄフィールドの値、ＴｒｕｅＤａｔａＳｏｃｋｅｔフィールドの値、および、ＦａｌｓｅＤａｔａＳｏｃｋｅｔフィールドの値を自身のＡＦＣＴａｂｌｅへ格納する。続いて、ＡＦＣＤａｅｍｏｎ１は、図３４に示すＳｅｔＣｏｎｄｉｔｉｏｎＲｅｓｐｏｎｓｅパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ３１０）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＳｅｔＣｏｎｄｉｔｉｏｎＲｅｓｐｏｎｓｅ」である。Ｓｔａｔｕｓフィールドの値は処理が正常であることを示す「ＯＫ」である。

そして、ＡＦＣＭａｎａｇｅｒは、ＳｅｔＣｏｎｄｉｔｉｏｎＲｅｓｐｏｎｓｅパケットを受信すると、ＡＦＣＳｅｓｓｉｏｎＫｅｙとしてＳＫｅｙ−ｕｓｒ０−ａｆｃ１を生成し、保存するとともに（ステップＳ３１１）、図３５に示すＳｅｔＳｅｓｓｉｏｎＫｅｙＲｅｑｕｅｓｔパケットをＧａｔｅＤａｅｍｏｎ１へ送信する（ステップＳ３１２）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＳｅｔＳｅｓｓｉｏｎＫｅｙＲｅｑｕｅｓｔ」である。ＡＦＣＳｅｓｓｉｏｎＫｅｙフィールドの値はＳＫｅｙ−ｕｓｒ０−ａｆｃ１である。

そして、ＧａｔｅＤａｅｍｏｎ１は、ＳｅｔＳｅｓｓｉｏｎＫｅｙＲｅｑｕｅｓｔパケットを受信すると、ＡＦＣＳｅｓｓｉｏｎＫｅｙフィールドの値を自身のＡＦＣＴａｂｌｅへ保存するとともに（ステップＳ３１３）、図３６に示すＳｅｔＳｅｓｓｉｏｎＫｅｙＲｅｓｐｏｎｓｅパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ３１４）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＳｅｔＳｅｓｓｉｏｎＫｅｙＲｅｓｐｏｎｓｅ」である。Ｓｔａｔｕｓフィールドの値は処理が正常であることを示す「ＯＫ」である。

そして、ＡＦＣＭａｎａｇｅｒは、ＳｅｔＳｅｓｓｉｏｎＫｅｙＲｅｓｐｏｎｓｅパケットを受信すると、図３７に示すＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケットをＡＡＡＳｅｒｖｅｒへ送信する（ステップＳ３１５）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ」である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ０である。Ｕｓａｇｅフィールドの値はＡＦＣの設置を示す「ＡＦＣＳｅｔｕｐ」である。ＡＦＩＤフィールドの値は［ｎｕｌｌ］である。ＡＦＣＩＤフィールドの値はＡＦＣＩＤ−ａｆｃ１である。

ＡＡＡＳｅｒｖｅｒは、ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケットを受信すると、Ｕｓａｇｅフィールドの値を記録する（ステップＳ３１６）。

また、ＡＦＣＭａｎａｇｅｒは、ＳｅｔＳｅｓｓｉｏｎＫｅｙＲｅｓｐｏｎｓｅパケットを受信すると、図２８に示すＡＦＣＳｅｔｕｐＲｅｓｐｏｎｓｅパケットをＡＦＣＣｏｎｓｔｒｕｃｔｏｒへ送信する（ステップＳ３１７）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡＦＣＳｅｔｕｐＲｅｓｐｏｎｓｅ」である。ＡＦＣＩＤフィールドの値はＡＦＣＩＤ−ａｆｃ１である。Ｓｔａｔｕｓフィールドの値は処理が正常であることを示す「ＯＫ」である。ＤａｔａＰｏｒｔフィールドの値はＤＰｔ−ｇｔ１−ａｐｐである。ＡＦＣＳｅｓｓｉｏｎＫｅｙフィールドの値はＳＫｅｙ−ｕｓｒ０−ａｆｃ１である。

そして、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、ＡＦＣＳｅｔｕｐＲｅｓｐｏｎｓｅパケットを受信すると、ＡＦＣＳｅｓｓｉｏｎＫｅｙフィールドの値を保存し（ステップＳ３１８）、ＡＦＣＭａｎａｇｅｒとの間の制御用ＴＬＳコネクションを解放する（ステップＳ３１９）。

以上の処理によりＡＦＣ１を設置した結果、ＡＦＣＭａｎａｇｅｒは、図３８に示す各テーブルを保持する。図２１に示したテーブルに対し、ここでは、ＡＦＣＴａｂｌｅが加わっており、ＵｓｅｒＴａｂｌｅのＰｔｒｔｏＡＦＣＴａｂｌｅフィールドの値は、ＡＦＣＴａｂｌｅを指すポインタとなる。ＡＦＣＴａｂｌｅの各フィールドの値は以下のとおりである。ＰｔｒｔｏＮｅｘｔＡＦＣＴａｂｌｅフィールドの値は［ｎｕｌｌ］である。ＡＦＣＩＤフィールドの値はＡＦＣＩＤ−ａｆｃ１である。ＡＦＣＳｅｓｓｉｏｎＫｅｙフィールドの値はＳＫｅｙ−ｕｓｒ０−ａｆｃ１である。ＮｏｏｆＡＦｓフィールドの値は５である。これは、このＡＦＣに含まれるＡＦの数である３に、ＧａｔｅＤａｅｍｏｎの数である２を加えたものである。続く５つのフィールドはＧａｔｅＤａｅｍｏｎあるいはＡＦの識別子を示す。

また、ＡＦＣ１の設置後に、ＧａｔｅＤａｅｍｏｎ１は、図３９に示すＩｎｇｒｅｓｓＴａｂｌｅを保持する。図１１に示したＧａｔｅＴａｂｌｅに対し、ここでは、ＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔフィールドの値がＤＳｏｃｋ−ｇｔ１−ａｆ１となる。このソケットは、ＧａｔｅＤａｅｍｏｎ１がＡＦＣＤａｅｍｏｎ１へアプリケーションメッセージを送信するためのものである。

また、ＡＦＣ１の設置後に、ＧａｔｅＤａｅｍｏｎ２は、図４０に示すＥｇｒｅｓｓＴａｂｌｅを保持する。図１２に示したＧａｔｅＴａｂｌｅに対し、ここでは、ＮｏｏｆＤａｔａＩｎｐｕｔＳｏｃｋｅｔｓフィールドの値が１となっており、ＤａｔａＩｎｐｕｔＳｏｃｋｅｔフィールドが１つ加わり、その値はＤＳｏｃｋ−ｇｔ２−ａｆ２となっている。このソケットは、ＧａｔｅＤａｅｍｏｎ２がＡＦＣＤａｅｍｏｎ２からアプリケーションメッセージを受信するためのものである。

また、ＡＦＣ１の設置後に、ＡＦＣＤａｅｍｏｎ１は、図４１に示すＡＦＣＴａｂｌｅを保持する。図２２に示したＡＦＣＴａｂｌｅに対し、ここでは、ＮｏｏｆＤａｔａＩｎｐｕｔＳｏｃｋｅｔｓフィールドの値が１になっており、ＤａｔａＩｎｐｕｔＳｏｃｋｅｔフィールドが１つ加わり、その値はＤＳｏｃｋ−ａｆ１−ｇｔ１となっている。また、ＮｏｏｆＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔｓフィールドの値が２になっており、ＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔフィールドが２つ加わり、その値はそれぞれＤＳｏｃｋ−ａｆ１−ａｆ２およびＤＳｏｃｋ−ａｆ１−ａｆ３となっている。さらに、Ｏｐｅｒａｔｏｒフィールドの値がＯｐ−ａｆ１に、Ｏｐｅｒａｎｄフィールドの値がＯｐｄ−ａｆ１に、ＴｒｕｅＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔＩｎｄｅｘフィールドの値が０に、ＦａｌｓｅＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔＩｎｄｅｘフィールドの値が１になっている。

また、ＡＦＣ１の設置後に、ＡＦＣＤａｅｍｏｎ２は、図４２に示すＡＦＣＴａｂｌｅを保持する。図２３に示したＡＦＣＴａｂｌｅに対し、ここでは、ＮｏｏｆＤａｔａＩｎｐｕｔＳｏｃｋｅｔｓフィールドの値が２になっており、ＤａｔａＩｎｐｕｔＳｏｃｋｅｔフィールドが２つ加わり、その値はそれぞれＤＳｏｃｋ−ａｆ２−ａｆ１およびＤＳｏｃｋ−ａｆ２−ａｆ３となっている。また、ＮｏｏｆＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔｓフィールドの値が１になっており、ＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔフィールドが１つ加わり、その値はＤＳｏｃｋ−ａｆ２−ｇｔ２となっている。さらに、ＴｒｕｅＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔＩｎｄｅｘフィールドの値が０になっている。

また、ＡＦＣ１の設置後に、ＡＦＣＤａｅｍｏｎ３は、図４３に示すＡＦＣＴａｂｌｅを保持する。図２４に示したＡＦＣＴａｂｌｅに対し、ここで、ＮｏｏｆＤａｔａＩｎｐｕｔＳｏｃｋｅｔｓフィールドの値が１になっており、ＤａｔａＩｎｐｕｔＳｏｃｋｅｔフィールドが１つ加わり、その値はＤＳｏｃｋ−ａｆ３−ａｆ１となっている。また、ＮｏｏｆＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔｓフィールドの値が１になっており、ＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔフィールドが１つ加わり、その値はＤＳｏｃｋ−ａｆ３−ａｆ２となっている。さらに、ＴｒｕｅＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔＩｎｄｅｘフィールドの値が０になっている。

（ＡＦＣ利用権限の付与手順）
次に、ＡＦＣ利用権限の付与処理の処理手順について、図４４を用いて説明する。図４４は、ＡＦＵｓｅｒへのＡＦＣ利用権限の付与処理の処理手順を示す図である。かかる処理は、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒが、上記の手順で設置したＡＦＣ１の利用権限をＡＦＣＵｓｅｒ１へ付与することをＡＡＡＳｅｒｖｅｒへ登録する処理である。

まず、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、ＡＦＣＭａｎａｇｅｒとの間に制御用ＴＬＳコネクションを確立する（ステップＳ４０１）。

そして、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、図４５に示すＡＦＣＰｅｒｍｉｓｓｉｏｎＲｅｑｕｅｓｔパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ４０２）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡＦＣＰｅｒｍｉｓｓｉｏｎＲｅｑｕｅｓｔ」である。ＡＦＣＩＤフィールドの値はＡＦＣＩＤ−ａｆｃ１である。ＣｏｎｓｔｒｕｃｔｏｒＩＤフィールドの値はＵＩＤ−ｕｓｒ０である。Ｃｅｒｔｉｆｉｃａｔｅフィールドの値はＣｅｒｔ−ｕｓｒ０−ａｆｃ１である。Ｃｅｒｔ−ｕｓｒ０−ａｆｃ１の作成方法としては、本パケットにＳＫｅｙ−ｕｓｒ０−ａｆｃ１を付加したものをハッシュ関数にかけた結果とすることなどが考えられる。ＮｏｏｆＵｓｅｒＩＤｓフィールドの値は１である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ１である。

ＡＦＣＭａｎａｇｅｒは、ＦＣＰｅｒｍｉｓｓｉｏｎＲｅｑｕｅｓｔパケットを受信すると、ＡＦＣＩＤフィールドの値、ＣｏｎｓｔｒｕｃｔｏｒＩＤフィールドの値、および、Ｃｅｒｔｉｆｉｃａｔｅフィールドの値から、ＣｏｎｓｔｒｕｃｔｏｒＩＤフィールドの値が示すＡＦＵｓｅｒ（ＡＦＵｓｅｒ０）が、ＡＦＣＩＤフィールドが示すＡＦＣ（ＡＦＣ１）の作成者であることを検証する。続いて、ＣｏｎｓｔｒｕｃｔｏｒＩＤフィールドの値が示すＡＦＵｓｅｒ（ＡＦＵｓｅｒ０）が、ＡＦＣＩＤフィールドが示すＡＦＣ（ＡＦＣ１）の作成者であると判定された場合に、ＡＦＣＭａｎａｇｅｒは、ＡＦＣＰｅｒｍｉｓｓｉｏｎＲｅｑｕｅｓｔパケットをＡＡＡＳｅｒｖｅｒへ転送する（ステップＳ４０３）。

ＡＡＡＳｅｒｖｅｒは、ＡＦＣＰｅｒｍｉｓｓｉｏｎＲｅｑｕｅｓｔパケットを受信すると、ＵｓｅｒＩＤフィールドが示すＡＦＣＵｓｅｒ（ＡＦＣＵｓｅｒ１）に、ＡＦＣＩＤフィールドが示すＡＦＣ（ＡＦＣ１）の利用権限を与える。続いて、ＡＡＡＳｅｒｖｅｒは、図４６に示すＡＦＣＰｅｒｍｉｓｓｉｏｎＲｅｓｐｏｎｓｅパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ４０４）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡＦＣＰｅｒｍｉｓｓｉｏｎＲｅｓｐｏｎｓｅ」である。Ｓｔａｔｕｓフィールドの値は処理が正常であることを示す「ＯＫ」である。

ＡＦＣＭａｎａｇｅｒは、ＡＦＣＰｅｒｍｉｓｓｉｏｎＲｅｓｐｏｎｓｅパケットを受信すると、これをＡＦＣＣｏｎｓｔｒｕｃｔｏｒへ転送する（ステップＳ４０５）。

ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、ＡＦＣＰｅｒｍｉｓｓｉｏｎＲｅｓｐｏｎｓｅパケットを受信すると、ＡＦＣＭａｎａｇｅｒとの間の制御用ＴＬＳコネクションを解放する（ステップＳ４０６）。なお、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、上記と同様の手順で、ＡＦＣＵｓｅｒ２にもＡＦＣ１の使用権を付与する。

（アプリケーションによるＡＦＣＳｅｓｓｉｏｎＫｅｙの取得手順）
次に、アプリケーションによるＡＦＣＳｅｓｓｉｏｎＫｅｙの取得処理の処理手順について、図４７を用いて説明する。図４７は、アプリケーションによるＡＦＣＳｅｓｓｉｏｎＫｅｙの取得処理の処理手順を示す図である。

まず、Ａｐｐ１は、ＡＦＣＭａｎａｇｅｒとの間に制御用ＴＬＳコネクションを確立する（ステップＳ５０１）。

そして、Ａｐｐ１は、図４８に示すＧｅｔＵｓｅｒＳｅｓｓｉｏｎＫｅｙＲｅｑｕｅｓｔパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ５０２）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＧｅｔＵｓｅｒＳｅｓｓｉｏｎＫｅｙＲｅｑｕｅｓｔ」である。ＡＦＣＩＤフィールドの値はＡＦＣＩＤ−ａｆｃ１である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ１である。Ｃｒｅｄｅｎｔｉａｌフィールドの値はＣｒｅｄ−ｕｓｒ１である。Ｃｒｅｄ−ｕｓｅｒ１の内容は、ＡＦＣＵｓｅｒ１のパスワードなどが考えられる。

ＡＦＣＭａｎａｇｅｒは、ＧｅｔＵｓｅｒＳｅｓｓｉｏｎＫｅｙＲｅｑｕｅｓｔパケットを受信すると、図５０に示すＡＦＣＡＡＲｅｑｕｅｓｔパケットをＡＡＡＳｅｒｖｅｒへ送信する（ステップＳ５０３）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡＦＣＡＡＲｅｑｕｅｓｔ」である。ＡＦＣＩＤフィールドの値はＡＦＣＩＤ−ａｆｃ１である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ１である。Ｃｒｅｄｅｎｔｉａｌフィールドの値はＣｒｅｄ−ｕｓｒ１である。

ＡＡＡＳｅｒｖｅｒは、ＡＦＣＡＡＲｅｑｕｅｓｔパケットを受信すると、ＡＦＣＩＤフィールドの値、ＵｓｅｒＩＤフィールドの値、および、Ｃｒｅｄｅｎｔｉａｌフィールドの値により、ＵｓｅｒＩＤフィールドが示すＡＦＣユーザ（ＡＦＣＵｓｅｒ１）が、ＡＦＣＩＤフィールドが示すＡＦＣ（ＡＦＣ１）を利用する権限を有することを検証する。続いて、ＵｓｅｒＩＤフィールドが示すＡＦＣユーザ（ＡＦＣＵｓｅｒ１）が、ＡＦＣＩＤフィールドが示すＡＦＣ（ＡＦＣ１）を利用する権限を有すると判定された場合に、ＡＡＡＳｅｒｖｅｒは、図５１に示すＡＦＣＡＡＲｅｓｐｏｎｓｅパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ５０４）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡＦＣＡＡＲｅｓｐｏｎｓｅ」である。Ｓｔａｔｕｓフィールドの値は処理が正常であることを示す「ＯＫ」である。

そして、ＡＦＣＭａｎａｇｅｒは、ＡＦＣＡＡＲｅｓｐｏｎｓｅパケットを受信すると、ＵｓｅｒＳｅｓｓｉｏｎＫｅｙとしてＳＫｅｙ−ｕｓｒ１−ａｆｃ１を生成するとともに（ステップＳ５０５）、図５２に示すＳｅｔＵｓｅｒＳｅｓｓｉｏｎＫｅｙＲｅｑｕｅｓｔパケットをＧａｔｅＤａｅｍｏｎ１へ送信する（ステップＳ５０６）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＳｅｔＵｓｅｒＳｅｓｓｉｏｎＫｅｙＲｅｑｕｅｓｔ」である。ＡＦＣＩＤフィールドの値はＡＦＣＩＤ−ａｆｃ１である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ１である。ＵｓｅｒＳｅｓｓｉｏｎＫｅｙフィールドの値はＳＫｅｙ−ｕｓｒ１−ａｆｃ１である。

ＧａｔｅＤａｅｍｏｎ１は、ＳｅｔＵｓｅｒＳｅｓｓｉｏｎＫｅｙＲｅｑｕｅｓｔパケットを受信すると、ＵｓｅｒＳｅｓｓｉｏｎＫｅｙフィールドの値（ＳＫｅｙ−ｕｓｒ１−ａｆｃ１）を保存するとともに（ステップＳ５０７）、図５３に示すＳｅｔＵｓｅｒＳｅｓｓｉｏｎＫｅｙＲｅｓｐｏｎｓｅパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ５０８）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＳｅｔＵｓｅｒＳｅｓｓｉｏｎＫｅｙＲｅｓｐｏｎｓｅ」である。Ｓｔａｔｕｓフィールドの値は処理が正常であることを示す「ＯＫ」である。

そして、ＡＦＣＭａｎａｇｅｒは、ＳｅｔＵｓｅｒＳｅｓｓｉｏｎＫｅｙＲｅｓｐｏｎｓｅパケットを受信すると、図４９に示すＧｅｔＵｓｅｒＳｅｓｓｉｏｎＫｅｙＲｅｓｐｏｎｓｅパケットをＡｐｐ１へ送信する（ステップＳ５０９）。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＧｅｔＵｓｅｒＳｅｓｓｉｏｎＫｅｙＲｅｓｐｏｎｓｅ」である。Ｓｔａｔｕｓフィールドの値は処理が正常であることを示す「ＯＫ」である。ＵｓｅｒＳｅｓｓｉｏｎＫｅｙフィールドの値はＳＫｅｙ−ｕｓｒ１−ａｆｃ１である。ＤａｔａＰｏｒｔフィールドの値はＤＰｔ−ｇｔ１−ａｐｐである。ＩＰＡｄｄｒｅｓｓフィールドの値はＩＰ−ｇｔｎ１である。

そして、Ａｐｐ１は、ＧｅｔＵｓｅｒＳｅｓｓｉｏｎＫｅｙＲｅｓｐｏｎｓｅパケットを受信すると、ＵｓｅｒＳｅｓｓｉｏｎＫｅｙフィールドの値（ＳＫｅｙ−ｕｓｒ１−ａｆｃ１）、ＤａｔａＰｏｒｔフィールドの値（ＤＰｔ−ｇｔ１−ａｐｐ）、および、ＩＰＡｄｄｒｅｓｓフィールドの値（ＩＰ−ｇｔｎ１）を保存し（ステップＳ５１０）、ＡＦＣＭａｎａｇｅｒとの間の制御用ＴＬＳコネクションを解放する（ステップＳ５１１）。

この処理の結果、ＧａｔｅＤａｅｍｏｎ１は、図５４に示すＩｎｇｒｅｓｓＴａｂｌｅを保持する。図３９に示したＩｎｇｒｅｓｓＴａｂｌｅに対し、ここでは、ＮｏｏｆＩｎｐｕｔＡｐｐｓフィールドの値が１になっており、ＵｓｅｒＩＤフィールド、ＵｓｅｒＳｅｓｓｉｏｎＫｅｙフィールド、および、ＤａｔａＩｎｐｕｔＳｏｃｋｅｔフィールドが加わっている。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ１である。ＵｓｅｒＳｅｓｓｉｏｎＫｅｙフィールドの値はＳＫｅｙ−ｕｓｒ１−ａｆｃ１である。ＤａｔａＩｎｐｕｔＳｏｃｋｅｔフィールドの値は、この時点では不定（［ｕｎｄｅｆ］）である。

なお、Ａｐｐ２も同様の処理を行う。その結果、ＧａｔｅＤａｅｍｏｎ２は、図５５に示すＥｇｒｅｓｓＴａｂｌｅを保持する。図４０に示したＥｇｒｅｓｓＴａｂｌｅに対し、ここでは、ＮｏｏｆＯｕｔｐｕｔＡｐｐｓフィールドの値が１になっており、ＵｓｅｒＩＤフィールド、ＵｓｅｒＳｅｓｓｉｏｎＫｅｙフィールド、および、ＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔフィールドが加わっている。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ２である。ＵｓｅｒＳｅｓｓｉｏｎＫｅｙフィールドの値はＳＫｅｙ−ｕｓｒ２−ａｆｃ１である。ＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔフィールドの値は、この時点では不定（［ｕｎｄｅｆ］）である。

（第１のデータ通信手順）
次に、ＡＦＣでの第１のデータ通信処理の処理手順について、図５６を用いて説明する。図５６は、第１のデータ通信処理の処理手順を示す図である。図２に示したＡＦＣアーキテクチャでは、ＡＦ１において次段のＡＦがＡＦ２とＡＦ３に分岐するが、図５６の例ではＡＦ２が選択されるものとする。

Ａｐｐ１は、アプリケーションメッセージをＧａｔｅＤａｅｍｏｎ１へ送信する。アプリケーションメッセージは、ＡＦ１で処理され、続いてＡＦ２で処理される。Ａｐｐ２は、アプリケーションメッセージをＧａｔｅＤａｅｍｏｎ２から受信する。

ここで、ＡｐｐＮｏｄｅ１のＩＰアドレスをＩＰ−ａｐｐｎ１とする。また、ＡＦＣＡｐｐ１がデータ通信のために使用するポートをＤＰｔ−ａｐｐ１とする。また、ＡｐｐＮｏｄｅ２のＩＰアドレスをＩＰ−ａｐｐｎ２とする。また、ＡＦＣＡｐｐ２がデータ通信のために使用するポートをＤＰｔ−ａｐｐ２とする。

まず、Ａｐｐ２は、ＧａｔｅＤａｅｍｏｎ２との間にデータ用ＴＬＳコネクションを確立する（ステップＳ６０１）。ここで、ＧａｔｅＤａｅｍｏｎ２におけるデータ用ＴＬＳコネクションのためのポートをＤＰｔ−ｇｔ２−ａｐｐ２とし、ソケットをＤＳｏｃｋ−ｇｔ２−ａｐｐ２とする。その結果、ＧａｔｅＤａｅｍｏｎ２は、図５８に示すＥｇｒｅｓｓＴａｂｌｅを保持する。図５５に示したＥｇｒｅｓｓＴａｂｌｅに対し、ここでは、ＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔフィールドの値がＤＳｏｃｋ−ｇｔ２−ａｐｐ２となる。

そして、Ａｐｐ２は、ＡＦＣからデータを受信するため、図５９に示すＳｕｂｓｃｒｉｂｅＲｅｑｕｅｓｔパケットをＧａｔｅＤａｅｍｏｎ２へ送信する（ステップＳ６０２）。ＳｕｂｓｃｒｉｂｅＲｅｑｕｅｓｔパケットはＩＰヘッダ、ＴＣＰヘッダ、および、Ｐｕｂ／Ｓｕｂヘッダから構成される。Ｐｕｂ／Ｓｕｂヘッダにおいて、ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＳｕｂｓｃｒｉｂｅＲｅｑｕｅｓｔ」である。ＡＦＣＩＤフィールドの値はＡＦＣＩＤ−ａｆｃ１である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ２である。Ｃｅｒｔｉｆｉｃａｔｅフィールドの値はＣｅｒｔ−ｕｓｒ２−ａｆｃ１である。Ｃｅｒｔ−ｕｓｒ２−ａｆｃ１の作成方法としては、本パケットにＳＫｅｙ−ｕｓｒ２−ａｆｃ１を付加したものをハッシュ関数にかけた結果とすることなどが考えられる。

ＴＣＰヘッダに関しては始点ポートフィールド（ＳｒｃＰｏｒｔ）と終点ポートフィールド（ＤｓｔＰｏｒｔ）のみを示す。ＳｒｃＰｏｒｔフィールドの値は、Ａｐｐ２がデータ用ＴＬＳコネクションのために使用するポートであるＤＰｔ−ａｐｐ２である。ＤｓｔＰｏｒｔフィールドの値はＤＰｔ−ｇｔ２−ａｐｐ２である。

ＩＰヘッダに関しては始点アドレスフィールド（ＳｒｃＩＰ）と終点アドレスフィールド（ＤｓｔＩＰ）のみを示す。ＳｒｃＩＰフィールドの値は、ＡｐｐＮｏｄｅ２のＩＰアドレスであるＩＰ−ａｐｐｎ２である。ＤｓｔＩＰフィールドの値はＩＰ−ｇｔｎ２である。

ＧａｔｅＤａｅｍｏｎ２は、ＳｕｂｓｃｒｉｂｅＲｅｑｕｅｓｔパケットのＡＦＣＩＤフィールド、ＵｓｅｒＩＤフィールド、および、Ｃｅｒｔｉｆｉｃａｔｅフィールドの値から、Ａｐｐ２がＡＦＣを利用する権限を有することを検証し、図６０に示すＳｕｂｓｃｒｉｂｅＲｅｓｐｏｎｓｅパケットをＡｐｐ２へ送信する（ステップＳ６０３）。各フィールドの値は以下のとおりである。ＳｒｃＩＰフィールドとＤｓｔＩＰフィールドの値およびＳｒｃＰｏｒｔフィールドとＤｓｔＳｏｒｔフィールドの値はＳｕｂｓｃｒｉｂｅＲｅｑｕｅｓｔパケットと入れ替わっている。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＳｕｂｓｃｒｉｂｅＲｅｓｐｏｎｓｅ」である。Ｓｔａｔｕｓフィールドの値は処理が正常であることを示す「ＯＫ」である。

また、Ａｐｐ１は、ＧａｔｅＤａｅｍｏｎ１との間にデータ用ＴＬＳコネクションを確立する（ステップＳ６０４）。ここで、ＧａｔｅＤａｅｍｏｎ１におけるデータ用ＴＬＳコネクションのためのポートをＤＰｔ−ｇｔ１−ａｐｐ１とし、ソケットをＤＳｏｃｋ−ｇｔ１−ａｐｐ１とする。その結果、ＧａｔｅＤａｅｍｏｎ１は、図５７に示すＧａｔｅＴａｂｌｅを保持する。図５４に示したＧａｔｅＴａｂｌｅに対し、ここでは、ＤａｔａＩｎｐｕｔＳｏｃｋｅｔフィールドの値がＤＳｏｃｋ−ｇｔ１−ａｐｐ１となっている。このソケットは、ＧａｔｅＤａｅｍｏｎ１がＡｐｐ１からアプリケーションメッセージを受信するためのものである。

そして、Ａｐｐ１は、アプリケーションメッセージを送信するため、図６１に示すＰｕｂｌｉｓｈＲｅｑｕｅｓｔパケットをＧａｔｅＤａｅｍｏｎ１へ送信する（ステップＳ６０５）。アプリケーションメッセージにはＰｕｂ／Ｓｕｂヘッダが付加され、さらにＴＣＰヘッダとＩＰヘッダが付加される。この例ではアプリケーションメッセージ長が長く、２つのＴＣＰ／ＩＰパケットを要するものとする。

Ｐｕｂ／Ｓｕｂヘッダにおいて、ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＰｕｂｌｉｓｈＲｅｑｕｅｓｔ」である。ＡＦＣＩＤフィールドの値はＡＦＣＩＤ−ａｆｃ１である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ１である。Ｃｅｒｔｉｆｉｃａｔｅフィールドの値はＣｅｒｔ−ｕｓｒ１−ａｆｃ１である。Ｃｅｒｔ−ｕｓｒ１−ａｆｃ１の作成方法としては、本パケットにＳＫｅｙ−ｕｓｒ１−ａｆｃ１を付加したものをハッシュ関数にかけた結果とすることなどが考えられる。ＭｅｓｓａｇｅＬｅｎｇｔｈフィールドの値はアプリケーションメッセージの長さであるＬｅｎ−ａｐｐ１である。

ＴＣＰヘッダに関しては始点ポートフィールド（ＳｒｃＰｏｒｔ）と終点ポートフィールド（ＤｓｔＰｏｒｔ）のみを示す。ＳｒｃＰｏｒｔフィールドの値は、Ａｐｐ１がデータ用ＴＬＳコネクションのために使用するポートであるＤＰｔ−ａｐｐ１である。ＤｓｔＰｏｒｔフィールドの値はＤＰｔ−ｇ１−ａｐｐ１である。

ＩＰヘッダに関しては始点アドレスフィールド（ＳｒｃＩＰ）と終点アドレスフィールド（ＤｓｔＩＰ）のみを示す。ＳｒｃＩＰフィールドの値はＡｐｐＮｏｄｅ１のＩＰアドレスであるＩＰ−ａｐｐｎ１である。ＤｓｔＩＰフィールドの値はＩＰ−ｇｔｎ１である。２つ目のパケットのＩＰヘッダとＴＣＰヘッダの値は１つ目と同じである。

ＧａｔｅＤａｅｍｏｎ１は、ＰｕｂｌｉｓｈＲｅｑｕｅｓｔパケットを受信すると、ＰｕｂｌｉｓｈＲｅｑｕｅｓｔパケットのＡＦＣＩＤフィールド、ＵｓｅｒＩＤフィールド、および、Ｃｅｒｔｉｆｉｃａｔｅフィールドの値から、Ａｐｐ１がＡＦＣを利用する権限を有することを検証し、図６２に示すＰｕｂｌｉｓｈＲｅｓｐｏｎｓｅパケットをＡｐｐ１へ送信する（ステップＳ６０６）。

Ｐｕｂ／Ｓｕｂヘッダにおいて、ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＰｕｂｌｉｓｈＲｅｓｐｏｎｓｅ」である。ＡＦＣＩＤフィールドの値はＡＦＣＩＤ−ａｆｃ１である。Ｓｔａｔｕｓフィールドの値は処理が正常であることを示す「ＯＫ」である。

ＩＰヘッダとＴＣＰヘッダにおいては、ＳｒｃＩＰフィールドとＤｓｔＩＰフィールドの値およびＳｒｃＰｏｒｔフィールドとＤｓｔＳｏｒｔフィールドの値がＰｕｂｌｉｓｈＲｅｑｕｅｓｔパケットと入れ替わっている。

そして、ＧａｔｅＤａｅｍｏｎ１は、図６３に示すデータパケットをＡＦＣＤａｅｍｏｎ１へ送信する（ステップＳ６０７）。アプリケーションメッセージにＡＦＣヘッダが付加され、さらにＴＣＰヘッダとＩＰヘッダが付加される。この例ではアプリケーションメッセージ長が長く、２つのＴＣＰ／ＩＰパケットを要するものとする。ＡＦＣヘッダにおいて、ＭｅｓｓａｇｅＬｅｎｇｔｈフィールドの値はＬｅｎ−ａｐｐ１である。

ＴＣＰヘッダにおいて、ＳｒｃＰｏｒｔフィールドの値はＤＰｔ−ｇｔ１−ａｆ１であり、ＤｓｔＰｏｒｔフィールドの値はＤＰｔ−ａｆ１−ｇｔ１である。ＩＰヘッダにおいて、ＳｒｃＩＰフィールドの値はＩＰ−ｇｔｎ１であり、ＤｓｔＩＰフィールドの値はＩＰ−ａｆｎ１である。２つ目のパケットのＩＰヘッダおよびＴＣＰヘッダの各フィールドの値は１つ目のパケットと同じである。

ＡＦＣＤａｅｍｏｎ１は、アプリケーションメッセージをすべて受信すると、Ｐｔ−ａｆ１−ｉｎｐｕｔというポートを介してアプリケーションメッセージをＡＦ１へ入力する（ステップＳ６０８）。

そして、ＡＦＣＤａｅｍｏｎ１は、Ｐｔ−ａｆ１−ｏｕｔｐｕｔというポートを介してＡＦ１からアプリケーションメッセージを受信するとともに、Ｐｔ−ａｆ１−ｓｔａｔというポートを介してＡＦ１の終了状態値を得る（ステップＳ６０９）。

ＡＦ１の処理により、アプリケーションメッセージサイズはＬｅｎ−ａｐｐ１−ａｆ１に変化するものとする。ＡＦＣＤａｅｍｏｎ１は、ＡＦ１の終了状態値に、図４１のＯｐｅｒａｔｏｒフィールドが示すＯｐ−１という演算子と、Ｏｐｅｒａｎｄフィールドが示すＯｐｄ−１というオペランドを作用させ、真偽値を得る。この例では真偽値は真であるとする。図４１に示したＡＦＣＴａｂｌｅのＴｒｕｅＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔフィールドの値は０であるので、データパケットを送信する際にはＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔＩｎｄｅｘが０であるＤＳｏｃｋ−ａｆ１−ａｆ２を使用する。

そして、ＡＦＣＤａｅｍｏｎ１は、図６７に示すＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ６１０）。ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケットの各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ」である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ１である。Ｕｓａｇｅフィールドの値は、ＡＦのために使われる資源に関する情報を示す。本実施形態では、Ｕｓａｇｅフィールドの値は、ＡＦ１の実行において使用した資源量を表すＵｓｇ−ｕｓｒ１−ａｆ１である。資源量としては、ＡＦ１に入力したアプリケーションメッセージサイズ、ＡＦ１の実行時間などが考えられる。ＡＦＩＤフィールドの値はＡＦＩＤ−ａｆ１である。ＡＦＣＩＤフィールドの値はＡＦＣＩＤ−ａｆｃ１である。また、ＡＦＣＭａｎａｇｅｒは、ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケットを受信すると、これをＡＡＡＳｅｒｖｅｒへ転送する。

ＡＡＡＳｅｒｖｅｒは、ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケットを受信すると、Ｕｓａｇｅフィールドの値を記録する（ステップＳ６１１）。記録されたＵｓａｇｅフィールドの値は、ＡＡＡＳｅｒｖｅｒによるＡＦＣＡｐｐのアカウンティング（課金）に使われ得る。

また、ＡＦＣＤａｅｍｏｎ１は、図６４に示すデータパケットをＡＦＣＤａｅｍｏｎ２へ送信する（ステップＳ６１２）。ＡＦＣヘッダにおいて、ＡｐｐＭｅｓｓａｇｅＬｅｎｇｔｈフィールドの値はＬｅｎ−ａｐｐ１−ａｆ１である。ＴＣＰヘッダにおいて、ＳｒｃＰｏｒｔフィールドの値はＤＰｔ−ａｆ１−ａｆ２であり、ＤｓｔＰｏｒｔフィールドの値はＤＰｔ−ａｆ２−ａｆ１である。ＩＰヘッダにおいて、ＳｒｃＩＰフィールドの値はＩＰ−ａｆｎ１であり、ＤｓｔＩＰフィールドの値はＩＰ−ａｆｎ２である。２つ目のパケットのＩＰヘッダおよびＴＣＰヘッダの各フィールドの値は１つ目のパケットと同じである。

ＡＦＣＤａｅｍｏｎ２は、アプリケーションメッセージをすべて受信すると、Ｐｔ−ａｆ２−ｉｎｐｕｔというポートを介してアプリケーションメッセージをＡＦ２へ入力する（ステップＳ６１３）。

そして、ＡＦＣＤａｅｍｏｎ２は、Ｐｔ−ａｆ２−ｏｕｔｐｕｔというポートを介してＡＦ２からアプリケーションメッセージを受信する（ステップＳ６１４）。

ＡＦ２の処理により、アプリケーションメッセージサイズはＬｅｎ−ａｐｐ１−ａｆ２に変化するものとする。図４２に示したＡＦＣＴａｂｌｅのＯｐｅｒａｔｏｒフィールドの値は［ｎｕｌｌ］であり、ＴｒｕｅＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔフィールドの値は０であるので、データパケットを送信する際にはＤａｔａＯｕｔｐｕｔＳｏｃｋｅｔＩｎｄｅｘが０であるＤＳｏｃｋ−ａｆ１−ａｆ２を使用する。

そして、ＡＦＣＤａｅｍｏｎ２は、ステップＳ６１０と同様にＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ６１５）。ＡＦＣＭａｎａｇｅｒは、ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケットを受信すると、これをＡＡＡＳｅｒｖｅｒへ転送する。

ＡＡＡＳｅｒｖｅｒは、ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケットを受信すると、Ｕｓａｇｅフィールドの値を記録する（ステップＳ６１６）。

また、ＡＦＣＤａｅｍｏｎ２は、図６５に示すデータパケットをＧａｔｅＤａｅｍｏｎ２へ送信する（ステップＳ６１７）。ＡＦＣヘッダにおいて、ＭｅｓｓａｇｅＬｅｎｇｔｈフィールドの値はＬｅｎ−ａｐｐ１−ａｆ２である。ＴＣＰヘッダにおいて、ＳｒｃＰｏｒｔフィールドの値はＤＰｔ−ａｆ２−ｇｔ２であり、ＤｓｔＰｏｒｔフィールドの値はＤＰｔ−ｇｔ２−ａｆ２である。ＩＰヘッダにおいて、ＳｒｃＩＰフィールドの値はＩＰ−ａｆｎ２であり、ＤｓｔＩＰフィールドの値はＩＰ−ｇｔｎ２である。２つ目のパケットのＩＰヘッダおよびＴＣＰヘッダの各フィールドの値は１つ目のパケットと同じである。

そして、ＧａｔｅＤａｅｍｏｎ２は、データパケットを受信する。ＧａｔｅＤａｅｍｏｎ２は、ステップＳ６０２でＡｐｐ２からＡＦＣ１に関するＳｕｂｓｃｒｉｂｅＲｅｑｕｅｓｔを受信しているので、これに基づいて図６６に示すＳｕｂｓｃｒｉｂｅＮｏｔｉｆｉｃａｔｉｏｎパケットをＡｐｐ２へ送信する（ステップＳ６１８）。

Ｐｕｂ／Ｓｕｂヘッダにおいて、ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＳｕｂｓｃｒｉｂｅＮｏｔｉｆｉｃａｔｉｏｎ」である。ＡＦＣＩＤフィールドの値はＡＦＣＩＤ−ａｆｃ１である。ＭｅｓｓａｇｅＬｅｎｇｔｈフィールドの値はＬｅｎ−ａｐｐ１−ａｆ２である。ＴＣＰヘッダにおいて、ＳｒｃＰｏｒｔフィールドの値はＤＰｔ−ｇｔ２−ａｐｐ２であり、ＤｓｔＰｏｒｔフィールドの値はＤＰｔ−ａｐｐ２である。ＩＰヘッダにおいて、ＳｒｃＩＰフィールドの値はＩＰ−ｇｔｎ２であり、ＤｓｔＩＰフィールドの値はＩＰ−ａｐｐｎ２である。２つ目のパケットのＩＰヘッダおよびＴＣＰヘッダの各フィールドの値は１つ目のパケットと同じである。

そして、Ａｐｐ２は、ＳｕｂｓｃｒｉｂｅＮｏｔｉｆｉｃａｔｉｏｎパケットを受信すると、ＧａｔｅＤａｅｍｏｎ２との間のデータ用ＴＬＳコネクションを解放する（ステップＳ６１９）。また、Ａｐｐ１は、ＧａｔｅＤａｅｍｏｎ１との間のデータ用ＴＬＳコネクションを解放する（ステップＳ６２０）。

（第２のデータ通信手順）
次に、ＡＦＣでの第２のデータ通信処理の処理手順について、図６８を用いて説明する。図６８は、第２のデータ通信処理の処理手順を示す図である。かかる処理手順は、図５６を用いて説明した第１のデータ通信処理に対し、以下の２つの点が異なる。

１つ目は、図５６では、Ａｐｐ１はＰｕｂｌｉｓｈＲｅｑｕｅｓｔパケットによりアプリケーションメッセージをＧａｔｅＤａｅｍｏｎ１へ送信しているが、図６８では、Ａｐｐ１はＨＴＴＰ（Hypertext Transfer Protocol）通信のＨＴＴＰＲｅｑｕｅｓｔメッセージ（ＰＯＳＴ）によりアプリケーションメッセージをＧａｔｅＤａｅｍｏｎ１へ送信している点である。

２つ目は、図５６では、Ａｐｐ２は、ＳｕｂｓｃｒｉｂｅＲｅｑｕｅｓｔパケットによりアプリケーションメッセージ受信要求をＧａｔｅＤａｅｍｏｎ２へ送信し、ＳｕｂｓｃｒｉｂｅＮｏｔｉｆｉｃａｔｉｏｎパケットによりアプリケーションメッセージを受信しているが、図６８では、Ａｐｐ２は、ＨＴＴＰＲｅｑｕｅｓｔメッセージ（ＧＥＴ）によりアプリケーションメッセージ受信要求をＧａｔｅＤａｅｍｏｎ２へ送信し、ＨＴＴＰＲｅｓｐｏｎｓｅメッセージによりアプリケーションメッセージを受信している点である。

まず、ステップＳ７０１は、図５６におけるステップＳ６０１と同様である。そして、Ａｐｐ２は、ＡＦＣからデータを受信するため、図６９に示すＨＴＴＰＲｅｑｕｅｓｔメッセージをＧａｔｅＤａｅｍｏｎ２へ送信する（ステップＳ７０２）。なお、図６９ではＩＰヘッダとＴＣＰヘッダを省略している。

ＨＴＴＰＲｅｑｕｅｓｔメッセージのメソッドフィールドの値は「ＧＥＴ」である。ＵＲＬフィールドの値は「／ＡＦＣ」である。ヘッダラインの１行目はＡＦＣＩＤを示している。ヘッダラインの２行目はＵｓｅｒＩＤを示している。ヘッダラインの３行目はＣｅｒｔｉｆｉｃａｔｅを示している。Ｃｅｒｔｉｆｉｃａｔｅの作成方法は図５６のステップＳ６０２と同等である。

そして、ステップＳ７０３は、図５６におけるステップＳ６０４と同様である。そして、Ａｐｐ１は、アプリケーションメッセージを送信するため、図７０に示すＰＯＳＴＲｅｑｕｅｓｔメッセージをＧａｔｅＤａｅｍｏｎ１へ送信する（ステップＳ７０４）。なお、図７０ではＩＰヘッダとＴＣＰヘッダを省略している。

ＨＴＴＰＲｅｑｕｅｓｔメッセージのメソッドフィールドの値は「ＰＯＳＴ」である。ＵＲＬフィールドの値は「／ＡＦＣ」である。ヘッダラインの１行目はＡＦＣＩＤを示している。ヘッダラインの２行目はＵｓｅｒＩＤを示している。ヘッダラインの３行目はＣｅｒｔｉｆｉｃａｔｅを示している。Ｃｅｒｔｉｆｉｃａｔｅの作成方法は図５６のステップＳ６０５と同等である。ヘッダラインの４行目はアプリケーションメッセージサイズを示している。ｅｎｔｉｔｙｂｏｄｙフィールドにはアプリケーションメッセージが格納される。アプリケーションメッセージサイズが大きく１つのパケットに収まらない場合は、複数のパケットで送信される。

ＧａｔｅＤａｅｍｏｎ１は、ＨＴＴＰＲｅｑｕｅｓｔメッセージのヘッダラインにより、ＵｓｅｒＩＤフィールドおよびＣｅｒｔｉｆｉｃａｔｅフィールドの値からＡｐｐ１がＡＦＣを利用する権限を有することを検証し、図７１に示すＨＴＴＰＲｅｓｐｏｎｓｅメッセージをＡｐｐ１へ送信する（ステップＳ７０５）。ＨＴＴＰＲｅｓｐｏｎｓｅメッセージのｓｔａｔｕｓｃｏｄｅフィールドの値は「２００」であり、ｐｈｒａｓｅフィールドの値は「ＯＫ」である。

そして、ステップＳ７０６は、図５６に示したステップＳ６０７〜Ｓ６１７と同様である。そして、ＧａｔｅＤａｅｍｏｎ２は、図７２に示すＨＴＴＰＲｅｓｐｏｎｓｅメッセージをＡｐｐ２へ送信する（ステップＳ７０７）。ＨＴＴＰＲｅｓｐｏｎｓｅメッセージのｓｔａｔｕｓｃｏｄｅフィールドの値は「２００」であり、ｐｈｒａｓｅフィールドの値は「ＯＫ」である。ヘッダラインの１行目はＡＦＣＩＤを示している。ヘッダラインの２行目はアプリケーションメッセージサイズを示している。ｅｎｔｉｔｙｂｏｄｙフィールドにはアプリケーションメッセージが格納される。アプリケーションメッセージサイズが大きく１つのパケットに収まらない場合は、複数のパケットで送信される。

そして、Ａｐｐ２は、ＨＴＴＰＲｅｓｐｏｎｓｅメッセージを受信すると、ＧａｔｅＤａｅｍｏｎ２との間のデータ用ＴＬＳコネクションを解放する（ステップＳ７０８）。また、Ａｐｐ１は、ＧａｔｅＤａｅｍｏｎ１との間のデータ用ＴＬＳコネクションを解放する（ステップＳ７０９）。

（ＡＦＣの削除手順）
次に、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒがＡＦＣを削除する手順について、図７３を用いて説明する。図７３は、ＡＦＣの削除処理の処理手順を示す図である。なお、図７３には、ＡＦＣ１を削除する場合について示している。

まず、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、ＡＦＣＭａｎａｇｅｒとの間に制御用ＴＬＳコネクションを確立する（ステップＳ８０１）。

そして、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、図７４に示すＡＦＣＤｅｌｅｔｅＲｅｑｕｅｓｔパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ８０２）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡＦＣＤｅｌｅｔｅＲｅｑｕｅｓｔ」である。ＡＦＣＩＤフィールドの値はＡＦＣＩＤ−ａｆｃ１である。Ｃｅｒｔｉｆｉｃａｔｅフィールドの値はＣｅｒｔ−ｕｓｒ０−ａｆｃ１である。Ｃｅｒｔ−ｕｓｒ０−ａｆｃ１の作成方法としては、本パケットにＳＫｅｙ−ｕｓｒ０−ａｆｃ１を付加したものをハッシュ関数にかけた結果とすることなどが考えられる。

そして、ＡＦＣＭａｎａｇｅｒは、ＡＦＣＤｅｌｅｔｅＲｅｑｕｅｓｔパケットを受信すると、ＵｓｅｒＩＤフィールドの値、ＡＦＣＩＤフィールドの値、および、Ｃｅｒｔｉｆｉｃａｔｅフィールドの値により、ＵｓｅｒＩＤフィールドが示すＡＦＣユーザ（ＡＦＣＵｓｅｒ０）がＡＦＣＩＤフィールドが示すＡＦＣ（ＡＦＣ１）を削除する権限を有することを検証する。続いて、ＡＦＣＤａｅｍｏｎは、図７６に示すＣｏｎｎｅｃｔｉｏｎＣｌｏｓｅＲｅｑｕｅｓｔパケットを、ＧａｔｅＤａｅｍｏｎ２、ＡＦＣＤａｅｍｏｎ２、ＡＦＣＤａｅｍｏｎ３、ＡＦＣＤａｅｍｏｎ１およびＧａｔｅＤａｅｍｏｎ１へ送信する（ステップＳ８０３）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＣｏｎｎｅｃｔｉｏｎＣｌｏｓｅＲｅｑｕｅｓｔ」である。

そして、ＣｏｎｎｅｃｔｉｏｎＣｌｏｓｅＲｅｑｕｅｓｔパケットを受信したＧａｔｅＤａｅｍｏｎ２、ＡＦＣＤａｅｍｏｎ２、ＡＦＣＤａｅｍｏｎ３、ＡＦＣＤａｅｍｏｎ１およびＧａｔｅＤａｅｍｏｎ１は、ＡＦＣ１のためのデータ用ＴＬＳコネクションを解放する（ステップＳ８０４）。

続いて、ＧａｔｅＤａｅｍｏｎ２、ＡＦＣＤａｅｍｏｎ２、ＡＦＣＤａｅｍｏｎ３、ＡＦＣＤａｅｍｏｎ１およびＧａｔｅＤａｅｍｏｎ１は、それぞれ図７７に示すＣｏｎｎｅｃｔｉｏｎＣｌｏｓｅＲｅｓｐｏｎｓｅパケットをＡＦＣＤａｅｍｏｎへ送信する（ステップＳ８０５）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＣｏｎｎｅｃｔｉｏｎＣｌｏｓｅＲｅｓｐｏｎｓｅ」である。Ｓｔａｔｕｓフィールドの値は処理が正常であることを示す「ＯＫ」である。

そして、ＡＦＣＭａｎａｇｅｒは、図７８に示すＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケットをＡＡＡＳｅｒｖｅｒへ送信する（ステップＳ８０６）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ」である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ０である。Ｕｓａｇｅフィールドの値は、ＡＦＣの削除を示す「ＤｅｌｅｔｅＡＦＣ」である。ＡＦＩＤフィールドの値は［ｎｕｌｌ］である。ＡＦＣＩＤフィールドの値はＡＦＣＩＤ−ａｆｃ１である。

ＡＡＡＳｅｒｖｅｒは、ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケットを受信すると、Ｕｓａｇｅフィールドの値を記録する（ステップＳ８０７）。

そして、ＡＦＣＭａｎａｇｅｒは、図７５に示すＡＦＣＤｅｌｅｔｅＲｅｓｐｏｎｓｅパケットをＡＦＣＣｏｎｓｔｒｕｃｔｏｒへ送信する（ステップＳ８０８）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡＦＣＤｅｌｅｔｅＲｅｓｐｏｎｓｅ」である。Ｓｔａｔｕｓフィールドの値は処理が正常であることを示す「ＯＫ」である。

そして、ＡＦＣＣｏｎｓｔｒｕｔｏｒは、ＡＦＣＭａｎａｇｅｒとの間の制御用ＴＬＳコネクションを解放する（ステップＳ８０９）。

（ＡＦの削除手順）
次に、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒがＡＦを削除する手順について、図７９を用いて説明する。図７９は、ＡＦの削除処理の処理手順を示す図である。なお、図７９には、ＡＦ１を削除する場合について示している。

まず、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、ＡＦＣＭａｎａｇｅｒとの間に制御用ＴＬＳコネクションを確立する（ステップＳ９０１）。

そして、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、図８０に示すＡＦＤｅｌｅｔｅＲｅｑｕｅｓｔパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ９０２）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡＦＤｅｌｅｔｅＲｅｑｕｅｓｔ」である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ０である。ＡＦＩＤィールドの値はＡＦＩＤ−ａｆ１である。Ｃｅｒｔｉｆｉｃａｔｅフィールドの値はＣｅｒｔ−ｕｓｒ０−ａｆ１である。Ｃｅｒｔ−ｕｓｒ０−ａｆ１の作成方法としては、本パケットにＳＫｅｙ−ｕｓｒ０−ａｆ１を付加したものをハッシュ関数にかけた結果とすることなどが考えられる。

そして、ＡＦＣＭａｎａｇｅｒは、ＡＦＤｅｌｅｔｅＲｅｑｕｅｓｔパケットを受信すると、ＵｓｅｒＩＤフィールドの値、ＡＦＩＤフィールドの値、および、Ｃｅｒｔｉｆｉｃａｔｅフィールドの値により、ＵｓｅｒＩＤフィールドが示すＡＦＣユーザ（ＡＦＣＵｓｅｒ０）が、ＡＦＩＤフィールドが示すＡＦ（ＡＦ１）を削除する権限を有することを検証する。続いて、ＡＦＣＭａｎａｇｅｒは、ＡＦＤｅｌｅｔｅＲｅｑｕｅｓｔパケットをＡＦＣＤａｅｍｏｎ１へ転送する（ステップＳ９０３）。

そして、ＡＦＣＤａｅｍｏｎ１は、ＡＦＤｅｌｅｔｅＲｅｑｕｅｓｔパケットを受信するとＡＦ１の動作を停止させる（ステップＳ９０４）。

続いて、ＡＦＣＤａｅｍｏｎ１は、図８１に示すＡＦＤｅｌｅｔｅＲｅｓｐｏｎｓｅパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ９０５）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡＦＤｅｌｅｔｅＲｅｓｐｏｎｓｅ」である。Ｓｔａｔｕｓフィールドの値は処理が正常であることを示す「ＯＫ」である。

そして、ＡＦＣＭａｎａｇｅｒは、ＡＦＤｅｌｅｔｅＲｅｓｐｏｎｓｅパケットを受信すると、ＡＦＣＤａｅｍｏｎ１との間の制御用ＴＬＳコネクションを解放し（ステップＳ９０６）、ＡＦＣＤａｅｍｏｎ１は動作を停止する（ステップＳ９０７）。

続いて、ＡＦＣＭａｎａｇｅｒは、図８２に示すＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケットをＡＡＡＳｅｒｖｅｒへ送信する（ステップＳ９０８）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ」である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ０である。Ｕｓａｇｅフィールドの値は、ＡＦの削除を示す「ＤｅｌｅｔｅＡＦ」である。ＡＦＩＤフィールドの値はＡＦＩＤ−ａｆ１である。ＡＦＣＩＤフィールドの値は［ｎｕｌｌ］である。

ＡＡＡＳｅｒｖｅｒは、ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケットを受信すると、Ｕｓａｇｅフィールドの値を記録する（ステップＳ９０９）。

そして、ＡＦＣＭａｎａｇｅｒは、ＡＦＤｅｌｅｔｅＲｅｓｐｏｎｓｅパケットをＡＦＣＣｏｎｓｔｒｕｃｔｏｒへ転送し（ステップＳ９１０）、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、ＡＦＣＭａｎａｇｅｒとの間の制御用ＴＬＳコネクションを解放する（ステップＳ９１１）。

なお、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒがＡＦ２やＡＦ３を削除する場合は、上記と同様の手順を行う。

（ＧａｔｅＤａｅｍｏｎの削除手順）
次に、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒがＧａｔｅＤａｅｍｏｎを削除する手順について、図８３を用いて説明する。図８３は、ＧａｔｅＤａｅｍｏｎの削除処理の処理手順を示す図である。なお、図８３には、ＧａｔｅＤａｅｍｏｎ１を削除する場合について示している。

まず、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、ＡＦＣＭａｎａｇｅｒとの間に制御用ＴＬＳコネクションを確立する（ステップＳ１００１）。

そして、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、図８４に示すＧａｔｅＤｅｌｅｔｅＲｅｑｕｅｓｔパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ１００２）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＧａｔｅＤｅｌｅｔｅＲｅｑｕｅｓｔ」である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ０である。ＡＦＩＤフィールドの値はＡＦＩＤ−ｇｔ１である。Ｃｅｒｔｉｃａｔｅフィールドの値はＣｅｒｔ−ｕｓｒ０−ｇｔ１である。Ｃｅｒｔ−ｕｓｒ０−ｇｔ１の作成方法としては、本パケットにＳＫｅｙ−ｕｓｒ０−ｇｔ１を付加したものをハッシュ関数にかけた結果とすることなどが考えられる。

そして、ＡＦＣＭａｎａｇｅｒは、ＧａｔｅＤｅｌｅｔｅＲｅｑｕｅｓｔパケットを受信すると、ＵｓｅｒＩＤフィールドの値、ＡＦＩＤフィールドの値、および、Ｃｅｒｔｉｆｉｃａｔｅフィールドの値により、ＵｓｅｒＩＤフィールドが示すＡＦＣユーザ（ＡＦＣＵｓｅｒ０）がＡＦＩＤフィールドが示すＧａｔｅＤａｅｍｏｎ（ＧａｔｅＤａｅｍｏｎ１）を削除する権限を有することを検証する。続いて、ＡＦＣＭａｎａｇｅｒは、ＧａｔｅＤｅｌｅｔｅＲｅｑｕｅｓｔパケットをＧａｔｅＤａｅｍｏｎ１へ転送する（ステップＳ１００３）。

ＧａｔｅＤａｅｍｏｎ１は、ＧａｔｅＤｅｌｅｔｅＲｅｑｕｅｓｔパケットを受信すると、図８５に示すＧａｔｅＤｅｌｅｔｅＲｅｓｐｏｎｓｅパケットをＡＦＣＭａｎａｇｅｒへ送信する（ステップＳ１００４）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＧａｔｅＤｅｌｅｔｅＲｅｓｐｏｎｓｅ」である。Ｓｔａｔｕｓフィールドの値は処理が正常であることを示す「ＯＫ」である。

そして、ＡＦＣＭａｎａｇｅｒは、ＧａｔｅＤｅｌｅｔｅＲｅｓｐｏｎｓｅパケットを受信すると、ＧａｔｅＤａｅｍｏｎ１との間の制御用ＴＬＳコネクションを解放し（ステップＳ１００５）、ＧａｔｅＤａｅｍｏｎ１は動作を停止する（ステップＳ１００６）。

続いて、ＡＦＣＭａｎａｇｅｒは、図８６に示すＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケットをＡＡＡＳｅｒｖｅｒへ送信する（ステップＳ１００７）。各フィールドの値は以下のとおりである。ＰａｃｋｅｔＴｙｐｅフィールドの値は「ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎ」である。ＵｓｅｒＩＤフィールドの値はＵＩＤ−ｕｓｒ０である。Ｕｓａｇｅフィールドの値は、ＧａｔｅＤａｅｍｏｎの削除を示す「ＤｅｌｅｔｅＧａｔｅ」である。ＡＦＩＤフィールドの値はＡＦＩＤ−ｇｔ１である。ＡＦＣＩＤフィールドの値は［ｎｕｌｌ］である。

ＡＡＡＳｅｒｖｅｒは、ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケットを受信すると、Ｕｓａｇｅフィールドの値を記録する（ステップＳ１００８）。

そして、ＡＦＣＭａｎａｇｅｒは、ＧａｔｅＤｅｌｅｔｅＲｅｓｐｏｎｓｅパケットをＡＦＣＣｏｎｓｔｒｕｃｔｏｒへ転送し（ステップＳ１００９）、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒは、ＡＦＣＭａｎａｇｅｒとの間の制御用ＴＬＳコネクションを解放する（ステップＳ１０１０）。

なお、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒがＧａｔｅＤａｅｍｏｎ２を削除する場合は、上記と同様の手順を行う。

以上、本開示の実施の形態について説明した。続いて、本開示の実施の形態に係る各アプリケーションやノードとして機能しうる通信装置の機能構成例を説明する。

［１．３．通信装置の機能構成例］
図８７は、本開示の実施の形態に係る各ノードとして機能しうる通信装置１００の機能構成例を示す説明図である。図８７に示した通信装置１００は、通信部１１０、記憶部１２０および制御部１３０を含んで構成される。

通信部１１０は、ノード間の通信を実行する。ノード間の通信は有線であっても良く、無線であっても良い。通信部１１０からは、上述してきたパケットやメッセージが、制御部１３０の制御の基で他のノードとの間で、所定のポートより送信および所定のポートで受信される。

記憶部１２０は、上述してきたＡＦＣのアーキテクチャで用いられる各種情報やプログラムを記憶する。たとえば、記憶部１２０は、上述してきた各種テーブルを記憶する。記憶部１２０は、各種メモリ、ＨＤＤ等で構成されうる。

制御部１３０は、たとえばＣＰＵ（Central Processing Unit）等のプロセッサで構成され、上述してきたＡＦＣのアーキテクチャに基づく処理を実行する。たとえば、制御部１３０は、アプリケーション間のメッセージングにおける、ＧａｔｅＤａｅｍｏｎ、ＡＦおよびＡＦＣの設置、ＡＦＣ利用権限の付与、ＡＦＣＳｅｓｓｉｏｎＫｅｙの取得、データ通信、ＡＦＣ、ＡＦおよびＧａｔｅＤａｅｍｏｎの削除、等を実行する。

＜２．まとめ＞
以上説明したように本開示の実施の形態によれば、ネットワーク内でパケットを転送させるサービスにおいて利便性高く、サービス利用者が希望するパケットに、サービス利用者が希望する１つまたは複数の機能を作用させることが可能な通信装置が提供される。

本明細書の各装置が実行する処理における各ステップは、必ずしもシーケンス図またはフローチャートとして記載された順序に沿って時系列に処理する必要はない。たとえば、各装置が実行する処理における各ステップは、フローチャートとして記載した順序と異なる順序で処理されても、並列的に処理されてもよい。

また、各装置に内蔵されるＣＰＵ、ＲＯＭ（Read Only Memory）およびＲＡＭ（Randam Access Memory）などのハードウェアを、上述した各装置の構成と同等の機能を発揮させるためのコンピュータプログラムも作成可能である。また、該コンピュータプログラムを記憶させた記憶媒体も提供されることが可能である。また、機能ブロック図で示したそれぞれの機能ブロックをハードウェアで構成することで、一連の処理をハードウェアで実現することもできる。

以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

（効果）
上述してきたように、本開示に係る通信装置１００は、１又は複数のＡＦＣＡｐｐ（「アプリケーション」の一例に相当）を実行するＡｐｐＮｏｄｅ（アプリケーションノード）として動作する通信装置であって、通信部１１０と、制御部１３０とを備える。通信部１１０は、他の論理ノードとの間の通信を実行する。制御部１３０は、通信部１１０による通信を制御する。また、上記他の論理ノードは、ＡｐｐＮｏｄｅを送信元又は送信先とするアプリケーションメッセージの送受信において、上記送受信の経路中に上記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣが適用されるノードである。また、制御部１３０は、上記他の論理ノードへ向けて、上記１又は複数のアプリケーション機能が作用するアプリケーションメッセージの送受信のために、出版−購読型モデルに従うメッセージを通信部１１０から送信させる。

これにより、通信装置１００は、ＡＦＣＡｐｐ間におけるアプリケーションメッセージの送受信につき、ネットワーク内でパケットを転送させるサービスにおいて利便性高く、サービス利用者が希望するパケットに、サービス利用者が希望する１つまたは複数の機能を作用させることができる。たとえば、通信装置１００は、出版−購読型モデルを用いることにより、スケーラビリティがよく、動的なネットワーク環境を提供することが可能となる。

また、制御部１３０は、上記ＡｐｐＮｏｄｅにおいて上記アプリケーションメッセージの送信元となるＡＦＣＡｐｐが動作する場合に、上記ＡｐｐＮｏｄｅの後段に位置する上記他の論理ノード（たとえば、ＧａｔｅＮｏｄｅ１）に対し、出版要求パケット（たとえば、ＰｕｂｌｉｓｈＲｅｑｕｅｓｔパケット）により通信部１１０に上記メッセージを送信させ、上記ＡｐｐＮｏｄｅにおいて上記アプリケーションメッセージの送信先となるＡＦＣＡｐｐが動作する場合に、上記ＡｐｐＮｏｄｅの前段に位置する上記他の論理ノード（たとえば、ＧａｔｅＮｏｄｅ２）から、購読要求パケット（たとえば、ＳｕｂｓｃｒｉｂｅＲｅｑｕｅｓｔパケット）により通信部１１０に上記メッセージを受信させる。

これにより、通信装置１００は、たとえばＡｐｐＮｏｄｅ１側とＡｐｐＮｏｄｅ２側の結合度を低くさせ、スケーラビリティがよく、動的なネットワーク環境を提供することが可能となる。

また、制御部１３０は、上記ＡｐｐＮｏｄｅにおいて上記アプリケーションメッセージの送信元となるＡＦＣＡｐｐが動作する場合に、上記ＡｐｐＮｏｄｅの後段に位置する上記他の論理ノード（たとえば、ＧａｔｅＮｏｄｅ１）に対し、ＨＴＴＰ通信におけるＰＯＳＴメソッドを用いて上記アプリケーションメッセージを通信部１１０から送信させ、上記ＡｐｐＮｏｄｅにおいて上記アプリケーションメッセージの送信先となるＡＦＣＡｐｐが動作する場合に、上記ＡｐｐＮｏｄｅの前段に位置する上記他の論理ノード（たとえば、ＧａｔｅＮｏｄｅ２）から、ＨＴＴＰ通信におけるＧＥＴメソッドを用いて上記メッセージを通信部１１０から受信させる。

これにより、通信装置１００は、ＡｐｐＮｏｄｅ１側とＡｐｐＮｏｄｅ２側の結合度を低くさせ、スケーラビリティがよく、動的なネットワーク環境を提供することが可能となる。また、ＨＴＴＰ通信を用いることにより、レスポンス性の向上に資することができる。

また、本開示に係る通信装置１００は、通信部１１０と、制御部１３０とを備える論理ノード（たとえば、ＧａｔｅＤａｅｍｏｎやＡＦＮｏｄｅ）として動作する。通信部１１０は、１又は複数のＡＦＣＡｐｐを実行するＡｐｐＮｏｄｅとの間の通信を実行する。制御部１３０は、上記ＡｐｐＮｏｄｅを送信元又は送信先とするアプリケーションメッセージの送受信の経路中に上記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣを適用する。また、制御部１３０は、上記ＡｐｐＮｏｄｅを送信元又は送信先とする上記アプリケーションメッセージに対し、上記アプリケーション機能を作用させる場合に、上記アプリケーションメッセージを構成する１又は複数のパケットをすべて通信部１１０に受信させたうえで、上記アプリケーションメッセージを構成する１又は複数のパケット単位で上記アプリケーション機能を作用させる。

これにより、通信装置１００は、ＡＦＣＡｐｐ間におけるアプリケーションメッセージの送受信につき、ネットワーク内でパケットを転送させるサービスにおいて利便性高く、サービス利用者が希望するパケットに、サービス利用者が希望する１つまたは複数の機能を作用させることができる。たとえば、通信装置１００は、アプリケーションメッセージを構成する１又は複数のパケット単位で、すなわち逐次パケットごとでなくアプリケーションメッセージごとにＡＦによる処理を実行させるため、処理負荷の低減に資することができる。

また、本開示に係る通信装置１００は、通信部１１０と、制御部１３０とを備える管理ノード（たとえば、ＡＦＣＭａｎａｇｅｒ）として動作する。通信部１１０は、１又は複数のＡＦＣＡｐｐを実行するＡｐｐＮｏｄｅを送信元又は送信先とするアプリケーションメッセージの送受信に関連して、アカウンティングノードとの間の通信を実行する。制御部１３０は、他の論理ノードを管理する。また、上記他の論理ノードは、通信部１１０による通信を制御し、且つ上記ＡｐｐＮｏｄｅを送信元又は送信先とする上記アプリケーションメッセージの送受信の経路中に上記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣが適用される論理ノードであり、たとえば、ＧａｔｅＮｏｄｅやＡＦＮｏｄｅである。また、制御部１３０は、上記ＡｐｐＮｏｄｅを送信元又は送信先とする上記アプリケーションメッセージに対し、上記アプリケーション機能を作用させる場合に、当該アプリケーション機能を作用させるに際して使用した資源を表すパケット（たとえば、ＡｃｃｏｕｎｔｉｎｇＮｏｔｉｆｉｃａｔｉｏｎパケット）を生成して通信部１１０から上記アカウンティングノードへ送信させる。

これにより、通信装置１００は、ＡＦＣＡｐｐ間におけるアプリケーションメッセージの送受信につき、ネットワーク内でパケットを転送させるサービスにおいて利便性高く、サービス利用者が希望するパケットに、サービス利用者が希望する１つまたは複数の機能を作用させることができる。たとえば、通信装置１００は、アプリケーションメッセージの送受信に関し、利用者に対するアプリケーション機能ごとの課金管理等を可能にすることができる。

また、制御部１３０は、上記送信元又は送信先となる上記ＡｐｐＮｏｄｅにおいて動作するＡＦＣＡｐｐの利用者のアカウンティングを実行する上記アカウンティングノードとして動作するＡＡＡＳｅｒｖｅｒ（「サーバ装置」の一例に相当）へ向けて、上記アプリケーション機能を作用させるに際して使用した資源を表すパケットを通信部１１０に送信させる。

これにより、通信装置１００は、ＡＡＡＳｅｒｖｅｒに一括してＡＦＣにおけるアカウンティングを行わせることができる。

また、上記パケットが表す資源は、上記アプリケーション機能を作用させるに際して使用した資源の用途、および、使用した資源の量のうち少なくとも１つを示す。上記資源の用途は、制御部１３０によって管理される上記ＡＦＣが適用される１又は複数の論理ノードのうち少なくとも１つが設定される。言い換えれば、たとえばＧａｔｅＤａｅｍｏｎや、ＡＦ、ＡＦＣ等がそれぞれ設置されたことを示す「ＧａｔｅＳｅｔｕｐ」や、「ＡＦＳｅｔｕｐ」、「ＡＦＣＳｅｔｕｐ」等が設定される。また、上記資源の量は、上記アプリケーションメッセージのサイズおよび上記アプリケーション機能の実行時間の少なくともいずれかを含む。

これにより、通信装置１００は、資源の用途や、使用した資源の量などを含めたＡＦＣにおける計算資源の管理を、たとえばＡＡＡＳｅｒｖｅｒに一括して行わせることができる。

また、本開示に係る通信装置１００は、１又は複数のＡＦＣＡｐｐを実行するＡｐｐＮｏｄｅとして動作する通信装置（たとえば、ＡＦＣＣｏｎｓｔｒｕｃｔｏｒ）であって、通信部１１０と、制御部１３０とを備える。通信部１１０は、他の管理ノードとの間の通信を実行する。制御部１３０は、通信部１１０による通信を制御する。また、上記他の管理ノードは、自アプリケーションノード又は他のアプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信の経路中に上記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣとかかるＡＦＣが適用される論理ノードとを管理するノードである。また、制御部１３０は、自アプリケーションノードが上記送受信の経路中に存在し且つＡＦＣが適用されるノードを、上記他の管理ノードを介して作成した作成者である場合に、上記アプリケーションメッセージの送信元または送信先となるＡｐｐＮｏｄｅに対しＡＦＣが適用される論理ノードの利用権限を付与するパケット（たとえば、ＡＦＣＰｅｒｍｉｓｓｉｏｎＲｅｑｕｅｓｔパケット）を生成して、通信部１１０に送信させる。

これにより、通信装置１００は、Ａｐｐ間におけるアプリケーションメッセージの送受信につき、ネットワーク内でパケットを転送させるサービスにおいて利便性高く、サービス利用者が希望するパケットに、サービス利用者が希望する１つまたは複数の機能を作用させることができる。たとえば、通信装置１００は、Ａｐｐ間のアプリケーションメッセージの送受信において適宜、動的に利用権限を付与することで、セキュリティの強化に資することができる。

なお、本明細書に記載された効果はあくまで例示であって限定されるものでは無く、また他の効果があってもよい。

なお、本技術は以下のような構成も取ることができる。
（１）
１又は複数のアプリケーションを実行するアプリケーションノードとして動作する通信装置であって、
他の論理ノードとの間の通信を実行する通信部と、
前記通信部による通信を制御する制御部と
を備え、
前記他の論理ノードは、前記アプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信において、前記送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）が適用されるノードであり、
前記制御部は、
前記他の論理ノードへ向けて、前記１又は複数のアプリケーション機能が作用するアプリケーションメッセージの送受信のために、出版−購読型モデルに従うメッセージを前記通信部から送信させる、通信装置。
（２）
前記制御部は、
前記アプリケーションノードにおいて前記アプリケーションメッセージの送信元となるアプリケーションが動作する場合に、前記アプリケーションノードの後段に位置する前記他の論理ノードに対し、出版要求パケットにより前記通信部に前記メッセージを送信させ、
前記アプリケーションノードにおいて前記アプリケーションメッセージの送信先となるアプリケーションが動作する場合に、前記アプリケーションノードの前段に位置する前記他の論理ノードから、購読要求パケットにより前記通信部に前記メッセージを受信させる、前記（１）に記載の通信装置。
（３）
前記制御部は、
前記アプリケーションノードにおいて前記アプリケーションメッセージの送信元となるアプリケーションが動作する場合に、前記アプリケーションノードの後段に位置する前記他の論理ノードに対し、ＨＴＴＰ（Hypertext Transfer Protocol）通信におけるＰＯＳＴメソッドを用いて前記アプリケーションメッセージを前記通信部から送信させ、
前記アプリケーションノードにおいて前記アプリケーションメッセージの送信先となるアプリケーションが動作する場合に、前記アプリケーションノードの前段に位置する前記他の論理ノードから、ＨＴＴＰ通信におけるＧＥＴメソッドを用いて前記メッセージを前記通信部から受信させる、前記（１）に記載の通信装置。
（４）
１又は複数のアプリケーションを実行するアプリケーションノードとの間の通信を実行する通信部と、
前記アプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）を適用する制御部と
を備える論理ノードとして動作し、
前記制御部は、
前記アプリケーションノードを送信元又は送信先とする前記アプリケーションメッセージに対し、前記アプリケーション機能を作用させる場合に、前記アプリケーションメッセージを構成する１又は複数のパケットをすべて前記通信部に受信させたうえで、前記アプリケーションメッセージを構成する１又は複数のパケット単位で前記アプリケーション機能を作用させる、通信装置。
（５）
１又は複数のアプリケーションを実行するアプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信に関連して、アカウンティングノードとの間の通信を実行する通信部と、
他の論理ノードを管理する制御部と
を備える管理ノードとして動作し、
前記他の論理ノードは、前記通信部による通信を制御し、且つ前記アプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）が適用される論理ノードであり、
前記制御部は、
前記アプリケーションノードを送信元又は送信先とする前記アプリケーションメッセージに対し、前記アプリケーション機能を作用させる場合に、当該アプリケーション機能を作用させるに際して使用した資源を表すパケットを生成して前記通信部から前記アカウンティングノードへ送信させる、通信装置。
（６）
前記制御部は、
前記送信元又は送信先となる前記アプリケーションノードにおいて動作するアプリケーションの利用者のアカウンティングを実行する前記アカウンティングノードとして動作するサーバ装置へ向けて、前記アプリケーション機能を作用させるに際して使用した資源を表すパケットを前記通信部に送信させる、前記（５）に記載の通信装置。
（７）
前記パケットが表す資源は、
前記アプリケーション機能を作用させるに際して使用した資源の用途、および、使用した資源の量のうち少なくとも１つを示し、
前記資源の用途は、前記制御部によって管理されている前記ＡＦＣが適用される１又は複数の論理ノードのうち少なくとも１つが設定され、
前記資源の量は、前記アプリケーションメッセージのサイズおよび前記アプリケーション機能の実行時間の少なくともいずれかを含む、前記（５）または（６）に記載の通信装置。
（８）
１又は複数のアプリケーションを実行するアプリケーションノードとして動作する通信装置であって、
他の管理ノードとの間の通信を実行する通信部と、
前記通信部による通信を制御する制御部と
を備え、
前記他の管理ノードは、自アプリケーションノード又は他のアプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）と前記ＡＦＣが適用される論理ノードとを管理するノードであり、
前記制御部は、
自アプリケーションノードが前記送受信の経路中に存在し且つ前記ＡＦＣが適用されるノードを、前記他の管理ノードを介して作成した作成者である場合に、前記アプリケーションメッセージの送信元または送信先となる前記他のアプリケーションノードに対し前記ＡＦＣが適用される論理ノードの利用権限を付与するパケットを生成して、前記通信部に送信させる、通信装置。
（９）
１又は複数のアプリケーションを実行するアプリケーションノードとして動作する通信装置を用いた通信方法であって、
他の論理ノードとの間の通信を実行することと、
前記他の論理ノードとの間の通信を制御することと
を含み、
前記他の論理ノードは、前記アプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信において、前記送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）が適用されるノードであり、
前記制御することは、
前記他の論理ノードへ向けて、前記１又は複数のアプリケーション機能が作用するアプリケーションメッセージの送受信のために、出版−購読型モデルに従うメッセージを送信させる、通信方法。
（１０）
論理ノードして動作する通信装置を用いた通信方法であって、
１又は複数のアプリケーションを実行するアプリケーションノードとの間の通信を実行することと、
前記アプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）を適用することと
を含み、
前記適用することは、
前記アプリケーションノードを送信元又は送信先とする前記アプリケーションメッセージに対し、前記アプリケーション機能を作用させる場合に、前記アプリケーションメッセージを構成する１又は複数のパケットをすべて受信させたうえで、前記アプリケーションメッセージを構成する１又は複数のパケット単位で前記アプリケーション機能を作用させる、通信方法。
（１１）
管理ノードとして動作する通信装置を用いた通信方法であって、
１又は複数のアプリケーションを実行するアプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信に関連して、アカウンティングノードとの間の通信を実行することと、
他の論理ノードを管理することと
を含み、
前記他の論理ノードは、前記アカウンティングノードとの間の通信を制御し、且つ前記アプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）が適用される論理ノードであり、
前記管理することは、
前記アプリケーションノードを送信元又は送信先とする前記アプリケーションメッセージに対し、前記アプリケーション機能を作用させる場合に、当該アプリケーション機能を作用させるに際して使用した資源を表すパケットを生成して前記アカウンティングノードへ送信させる、通信方法。
（１２）
１又は複数のアプリケーションを実行するアプリケーションノードとして動作する通信装置を用いた通信方法であって、
他の管理ノードとの間の通信を実行することと、
前記他の管理ノードとの間の通信を制御することと
を含み、
前記他の管理ノードは、自アプリケーションノード又は他のアプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）と前記ＡＦＣが適用される論理ノードとを管理するノードであり、
前記制御することは、
自アプリケーションノードが前記送受信の経路中に存在し且つ前記ＡＦＣが適用されるノードを、前記他の管理ノードを介して作成した作成者である場合に、前記アプリケーションメッセージの送信元または送信先となる前記他のアプリケーションノードに対し前記ＡＦＣが適用される論理ノードの利用権限を付与するパケットを生成して、送信させる、通信方法。

１００通信装置
１１０通信部
１２０記憶部
１３０制御部

Claims

１又は複数のアプリケーションを実行するアプリケーションノードとして動作する通信装置であって、
他の論理ノードとの間の通信を実行する通信部と、
前記通信部による通信を制御する制御部と
を備え、
前記他の論理ノードは、前記アプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信において、前記送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）が適用されるノードであり、
前記制御部は、
前記他の論理ノードへ向けて、前記１又は複数のアプリケーション機能が作用するアプリケーションメッセージの送受信のために、出版−購読型モデルに従うメッセージを前記通信部から送信させる、通信装置。
前記制御部は、
前記アプリケーションノードにおいて前記アプリケーションメッセージの送信元となるアプリケーションが動作する場合に、前記アプリケーションノードの後段に位置する前記他の論理ノードに対し、出版要求パケットにより前記通信部に前記メッセージを送信させ、
前記アプリケーションノードにおいて前記アプリケーションメッセージの送信先となるアプリケーションが動作する場合に、前記アプリケーションノードの前段に位置する前記他の論理ノードから、購読要求パケットにより前記通信部に前記メッセージを受信させる、請求項１に記載の通信装置。
前記制御部は、
前記アプリケーションノードにおいて前記アプリケーションメッセージの送信元となるアプリケーションが動作する場合に、前記アプリケーションノードの後段に位置する前記他の論理ノードに対し、ＨＴＴＰ（Hypertext Transfer Protocol）通信におけるＰＯＳＴメソッドを用いて前記アプリケーションメッセージを前記通信部から送信させ、
前記アプリケーションノードにおいて前記アプリケーションメッセージの送信先となるアプリケーションが動作する場合に、前記アプリケーションノードの前段に位置する前記他の論理ノードから、ＨＴＴＰ通信におけるＧＥＴメソッドを用いて前記メッセージを前記通信部から受信させる、請求項１に記載の通信装置。
１又は複数のアプリケーションを実行するアプリケーションノードとの間の通信を実行する通信部と、
前記アプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）を適用する制御部と
を備える論理ノードとして動作し、
前記制御部は、
前記アプリケーションノードを送信元又は送信先とする前記アプリケーションメッセージに対し、前記アプリケーション機能を作用させる場合に、前記アプリケーションメッセージを構成する１又は複数のパケットをすべて前記通信部に受信させたうえで、前記アプリケーションメッセージを構成する１又は複数のパケット単位で前記アプリケーション機能を作用させる、通信装置。
１又は複数のアプリケーションを実行するアプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信に関連して、アカウンティングノードとの間の通信を実行する通信部と、
他の論理ノードを管理する制御部と
を備える管理ノードとして動作し、
前記他の論理ノードは、前記通信部による通信を制御し、且つ前記アプリケーションノードを送信元又は送信先とする前記アプリケーションメッセージの送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）が適用される論理ノードであり、
前記制御部は、
前記アプリケーションノードを送信元又は送信先とする前記アプリケーションメッセージに対し、前記アプリケーション機能を作用させる場合に、当該アプリケーション機能を作用させるに際して使用した資源を表すパケットを生成して前記通信部から前記アカウンティングノードへ送信させる、通信装置。
前記制御部は、
前記送信元又は送信先となる前記アプリケーションノードにおいて動作するアプリケーションの利用者のアカウンティングを実行する前記アカウンティングノードとして動作するサーバ装置へ向けて、前記アプリケーション機能を作用させるに際して使用した資源を表すパケットを前記通信部に送信させる、請求項５に記載の通信装置。
前記パケットが表す資源は、
前記アプリケーション機能を作用させるに際して使用した資源の用途、および、使用した資源の量のうち少なくとも１つを示し、
前記資源の用途は、前記制御部によって管理されている前記ＡＦＣが適用される１又は複数の論理ノードのうち少なくとも１つが設定され、
前記資源の量は、前記アプリケーションメッセージのサイズおよび前記アプリケーション機能の実行時間の少なくともいずれかを含む、請求項５または６に記載の通信装置。
１又は複数のアプリケーションを実行するアプリケーションノードとして動作する通信装置であって、
他の管理ノードとの間の通信を実行する通信部と、
前記通信部による通信を制御する制御部と
を備え、
前記他の管理ノードは、自アプリケーションノード又は他のアプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）と前記ＡＦＣが適用される論理ノードとを管理するノードであり、
前記制御部は、
自アプリケーションノードが前記送受信の経路中に存在し且つ前記ＡＦＣが適用されるノードを、前記他の管理ノードを介して作成した作成者である場合に、前記アプリケーションメッセージの送信元または送信先となる前記他のアプリケーションノードに対し前記ＡＦＣが適用される論理ノードの利用権限を付与するパケットを生成して、前記通信部に送信させる、通信装置。
１又は複数のアプリケーションを実行するアプリケーションノードとして動作する通信装置を用いた通信方法であって、
他の論理ノードとの間の通信を実行することと、
前記他の論理ノードとの間の通信を制御することと
を含み、
前記他の論理ノードは、前記アプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信において、前記送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）が適用されるノードであり、
前記制御することは、
前記他の論理ノードへ向けて、前記１又は複数のアプリケーション機能が作用するアプリケーションメッセージの送受信のために、出版−購読型モデルに従うメッセージを送信させる、通信方法。
論理ノードして動作する通信装置を用いた通信方法であって、
１又は複数のアプリケーションを実行するアプリケーションノードとの間の通信を実行することと、
前記アプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）を適用することと
を含み、
前記適用することは、
前記アプリケーションノードを送信元又は送信先とする前記アプリケーションメッセージに対し、前記アプリケーション機能を作用させる場合に、前記アプリケーションメッセージを構成する１又は複数のパケットをすべて受信させたうえで、前記アプリケーションメッセージを構成する１又は複数のパケット単位で前記アプリケーション機能を作用させる、通信方法。
管理ノードとして動作する通信装置を用いた通信方法であって、
１又は複数のアプリケーションを実行するアプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信に関連して、アカウンティングノードとの間の通信を実行することと、
他の論理ノードを管理することと
を含み、
前記他の論理ノードは、前記アカウンティングノードとの間の通信を制御し、且つ前記アプリケーションノードを送信元又は送信先とする前記アプリケーションメッセージの送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）が適用される論理ノードであり、
前記管理することは、
前記アプリケーションノードを送信元又は送信先とする前記アプリケーションメッセージに対し、前記アプリケーション機能を作用させる場合に、当該アプリケーション機能を作用させるに際して使用した資源を表すパケットを生成して前記アカウンティングノードへ送信させる、通信方法。
１又は複数のアプリケーションを実行するアプリケーションノードとして動作する通信装置を用いた通信方法であって、
他の管理ノードとの間の通信を実行することと、
前記他の管理ノードとの間の通信を制御することと
を含み、
前記他の管理ノードは、自アプリケーションノード又は他のアプリケーションノードを送信元又は送信先とするアプリケーションメッセージの送受信の経路中に前記アプリケーションメッセージに対して１又は複数のアプリケーション機能が作用するＡＦＣ（Application Function Chaining）と前記ＡＦＣが適用される論理ノードとを管理するノードであり、
前記制御することは、
自アプリケーションノードが前記送受信の経路中に存在し且つ前記ＡＦＣが適用されるノードを、前記他の管理ノードを介して作成した作成者である場合に、前記アプリケーションメッセージの送信元または送信先となる前記他のアプリケーションノードに対し前記ＡＦＣが適用される論理ノードの利用権限を付与するパケットを生成して、送信させる、通信方法。