WO2020085014A1

WO2020085014A1 - 通信装置、通信方法及びデータ構造

Info

Publication number: WO2020085014A1
Application number: PCT/JP2019/038811
Authority: WO
Inventors: 亮太木村; 高野　裕昭; 啓文葛西; 亮澤井; 寺岡　文男
Original assignee: ソニー株式会社
Priority date: 2018-10-25
Filing date: 2019-10-01
Publication date: 2020-04-30
Also published as: US12058116B2; CN112956163B; CN112956163A; US20210392123A1

Abstract

他のノードとの間の通信を実行する通信部と、前記通信部による通信を制御する制御部と、を備え、前記制御部は、送信元ノードが送信先ノードへ向けたパケットに、前記送信元ノードの後段に位置する自装置と、前記送信先ノードの前段に位置する目的ノードとの間の経路情報が少なくとも記述されたヘッダ情報を追加して、経路中に存在する他のノードへ向けて前記通信部に送出させる、通信装置が提供される。

Description

通信装置、通信方法及びデータ構造

　本開示は、通信装置、通信方法及びデータ構造に関する。

　ネットワーク事業者やサービス提供者の観点から、必要に応じてネットワーク内を転送されるパケットを元々のパケットの転送経路に含まれないサーバ機器に転送し、サーバ機器上で動作するサービス機能（Ｓｅｒｖｉｃｅ　Ｆｕｎｃｔｉｏｎ：ＳＦ）をパケットに作用させることをＳｅｒｖｉｃｅ　Ｆｕｎｃｔｉｏｎ　Ｃｈａｉｎｉｎｇ（ＳＦＣ）と呼ぶ。ＳＦとしては、Ｎｅｔｗｏｒｋ　Ａｄｄｒｅｓｓ　Ｔｒａｎｓｌａｔｉｏｎ（ＮＡＴ）、Ｌｏａｄ　Ｂａｌａｎｃｅｒ、Ｗｅｂ　Ａｐｐｌｉｃａｔｉｏｎ　Ｆｉｒｅｗａｌｌ（ＷＡＦ）などが挙げられる。

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

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

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

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

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

　本開示によれば、他のノードとの間の通信を実行する通信部と、前記通信部による通信を制御する制御部と、を備え、前記制御部は、送信元ノードが送信先ノードへ向けたパケットに、前記送信元ノードの後段に位置する自装置と、前記送信先ノードの前段に位置する目的ノードとの間の経路情報が少なくとも記述されたヘッダ情報を追加して、経路中に存在する他のノードへ向けて前記通信部に送出させる、通信装置が提供される。

　また本開示によれば、他のノードとの間の通信を実行する通信部と、前記通信部による通信を制御する制御部と、を備え、前記制御部は、送信元ノードが送信先ノードへ向けたパケットに付加された、前記送信元ノードの後段に位置する開始ノードから前記送信先ノードの前段に位置する自装置までの間の経路情報が少なくとも記述されたヘッダ情報を削除して前記通信部に送出させる、通信装置が提供される。

　また本開示によれば、他のノードとの間の通信を実行する通信部と、前記通信部による通信を制御する制御部と、を備え、前記制御部は、送信元ノードが送信先ノードへ向けたパケットに、前記送信元ノードの後段に位置する開始ノードから前記送信先ノードの前段に位置する目的ノードまでの間の経路情報が少なくとも記述されたヘッダ情報が付加されたデータを参照して次ノードを決定し、決定した前記次ノードへ向けて前記データを前記通信部に送出させる、通信装置が提供される。

　また本開示によれば、他のノードとの間の通信を実行する通信部と、前記通信部による通信を制御する制御部と、を備え、前記制御部は、開始ノードと目的ノードとの間の経路情報を生成し、前記開始ノードは、前記開始ノードと前記目的ノードとの間の経路情報が少なくとも記述されたヘッダ情報を追加するノードであり、前記目的ノードは、前記ヘッダ情報を削除するノードであり、前記開始ノードと前記目的ノードとの間の経路情報は、少なくとも、前記開始ノードと前記目的ノードとの間に存在する少なくとも一つの中継ノードとの通信に関する情報と、前記中継ノードに実行させる機能の情報と、前記中継ノードでの前記機能の実行結果に応じた処理の内容と、が記述される、通信装置が提供される。

　また本開示によれば、他のノードとの間の通信を実行することと、前記他のノードとの間の通信を制御することと、を備え、前記制御することは、送信元ノードが送信先ノードへ向けたパケットに、前記送信元ノードの後段に位置する開始ノードと、前記送信先ノードの前段に位置する目的ノードとの間の経路情報が少なくとも記述されたヘッダ情報を追加して経路中に存在する他のノードへ向けて送出させる、通信方法が提供される。

　また本開示によれば、他のノードとの間の通信を実行することと、前記他のノードとの間の通信を制御することと、を備え、前記制御することは、送信元ノードが送信先ノードへ向けたパケットに、前記送信元ノードの後段に位置する開始ノードと、前記送信先ノードの前段に位置する目的ノードとの間の経路情報が少なくとも記述されたヘッダ情報を削除して前記他のノードへ向けて送出させる、通信方法が提供される。

　また本開示によれば、他のノードとの間の通信を実行することと、前記他のノードとの間の通信を制御することと、を備え、前記制御することは、送信元ノードが送信先ノードへ向けたパケットに、前記送信元ノードの後段に位置する開始ノードから前記送信先ノードの前段に位置する目的ノードまでの間の経路情報が少なくとも記述されたヘッダ情報が付加されたデータを参照して次ノードを決定し、決定した前記次ノードへ向けて前記データを送出させる、通信方法が提供される。

　また本開示によれば、他のノードとの間の通信を実行する通信部と、前記通信部による通信を制御する制御部と、前記制御部は、送信元ノードが送信先ノードへ向けたパケットに、ヘッダ情報を追加して前記通信部に送出させる、通信装置で用いられ、前記ヘッダ情報として、開始ノードと目的ノードとの間の前記送信元ノードの後段に位置する開始ノードと、前記送信先ノードの前段に位置する目的ノードとの間の経路情報が少なくとも備える、データ構造が提供される。

ＳＦＣのアーキテクチャ例を示す説明図である。本開示の実施形態で提案するＡＦＣのアーキテクチャを示す説明図である。ＡＦＣデータパケットの構造を示す説明図である。ＡＦの設置におけるセキュリティ対策を示す説明図である。ＡＦＣの設置におけるセキュリティ対策を示す説明図である。データパケット転送におけるセキュリティ対策を示す説明図である。ＡＦＣの削除におけるセキュリティ対策を示す説明図である。ＡＦの削除におけるセキュリティ対策を示す説明図である。ＡＦ　Ｎｏｄｅ上にＡＦを設置する際の手順を示す説明図である。ＡＦ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケットの構造例を示す説明図である。ＡＦ　Ｓｅｔｕｐ　Ｒｅｓｐｏｎｓｅパケットの構造例を示す説明図である。ＡＡ　Ｒｅｑｕｅｓｔパケットの構造例を示す説明図である。ＡＡ　Ｒｅｓｐｏｎｓｅパケットの構造例を示す説明図である。ＡＦ　Ｉｎｖｏｋｅ　Ｒｅｑｕｅｓｔパケットの構造例を示す説明図である。ＡＦ　Ｉｎｖｏｋｅ　Ｒｅｓｐｏｎｓｅパケットの構造例を示す説明図である。Ｄａｅｍｏｎ　ＡＦ　Ｔａｂｌｅの構造例を示す説明図である。Ｍａｎａｇｅｒ　Ｕｓｅｒ　Ｔａｂｌｅ、Ｍａｎａｇｅｒ　ＡＦ　ＴａｂｌｅおよびＭａｎａｇｅｒ　ＡＦ　Ｎｏｄｅ　Ｔａｂｌｅの構造例を示す説明図である。Ｄａｅｍｏｎ　ＡＦ　Ｔａｂｌｅの構造例を示す説明図である。Ｄａｅｍｏｎ　ＡＦ　Ｔａｂｌｅの構造例を示す説明図である。ＡＦＣ　Ｍａｎａｇｅｒが保持するテーブルの構造例を示す説明図である。ＡＦＣ－１の設置手順を示す説明図である。ＡＦＣ－１のｐａｔｈを示す説明図である。ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケットの構造例を示す説明図である。ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｓｐｏｎｓｅパケットの構造例を示す説明図である。ＡＦＣ　Ｍａｎａｇｅｒが保持するテーブルの構造例を示す説明図である。ＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｑｕｅｓｔパケットの構造例を示す説明図である。ＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｓｐｏｎｓｅパケットの構造例を示す説明図である。ＡＦＣ　Ｉｎｇｒｅｓｓが保持するテーブルの構造例を示す説明図である。パケットの流れを示す説明図である。データパケットの構造例を示す説明図である。ＡＦＣ　データパケットの構造例を示す説明図である。Ｄａｅｍｏｎ　ＡＦＣ　Ｔａｂｌｅの構造例を示す説明図である。ＡＦＣデータパケットのヘッダの構造例を示す説明図である。ＡＦＣデータパケットのヘッダの構造例を示す説明図である。ＡＦＣ－２のｐａｔｈを示す説明図である。ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケットの構造例を示す説明図である。ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｓｐｏｎｓｅパケットの構造例を示す説明図である。ＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｑｕｅｓｔパケットの構造例を示す説明図である。ＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｓｐｏｎｓｅパケットの構造例を示す説明図である。ＡＦＣ　Ｍａｎａｇｅｒが保持するテーブルの構造例を示す説明図である。ＡＦＣ　Ｉｎｇｒｅｓｓが保持するテーブルの構造例を示す説明図である。データパケットの構造例を示す説明図である。ＡＦＣデータパケットのヘッダの構造例を示す説明図である。ＡＦＣデータパケットのヘッダの構造例を示す説明図である。ＡＦＣの削除について示す説明図である。ＡＦＣ　Ｄｅｌｅｔｅ　Ｒｅｑｕｅｓｔパケットの構造例を示す説明図である。ＡＦＣ　Ｄｅｌｅｔｅ　Ｒｅｓｐｏｎｓｅパケットの構造例を示す説明図である。ＡＦの削除について示す説明図である。ＡＦ　Ｄｅｌｅｔｅ　Ｒｅｑｕｅｓｔパケットの構造例を示す説明図である。ＡＦ　Ｄｅｌｅｔｅ　Ｒｅｓｐｏｎｓｅパケットの構造例を示す説明図である。ＡＦＣ　Ｍａｎａｇｅｒが保持するテーブルの構造例を示す説明図である。ＡＦＣ－３のｐａｔｈを示す説明図である。ＡＦ　Ｎｏｄｅが保持するテーブルの構造例を示す説明図である。ＡＦ　Ｎｏｄｅが保持するテーブルの構造例を示す説明図である。ＡＦ　Ｎｏｄｅが保持するテーブルの構造例を示す説明図である。ＡＦ　Ｎｏｄｅが保持するテーブルの構造例を示す説明図である。ＡＦＣ　Ｍａｎａｇｅｒが保持するテーブルの構造例を示す説明図である。ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケットの構造例を示す説明図である。ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｓｐｏｎｓｅパケットの構造例を示す説明図である。ＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｑｕｅｓｔパケットの構造例を示す説明図である。ＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｓｐｏｎｓｅパケットの構造例を示す説明図である。ＡＦＣ　Ｍａｎａｇｅｒが保持するテーブルの構造例を示す説明図である。ＡＦＣ　Ｉｎｇｒｅｓｓが保持するテーブルの構造例を示す説明図である。ＡＦＣ　ＩｎｇｒｅｓｓによるＡＦ　Ｎｏｄｅの負荷のモニタリングを示す説明図である。Ｌｏａｄ　Ｍｏｎｉｔｏｒｉｎｇ　Ｒｅｑｅｕｓｔパケットの構造例を示す説明図である。Ｌｏａｄ　Ｍｏｎｉｔｏｒｉｎｇ　Ｒｅｓｐｏｎｓｅパケットの構造例を示す説明図である。Ｉｎｇｒｅｓｓ　ＡＦ　Ｎｏｄｅ　Ｔａｂｌｅの構造例を示す説明図である。データパケットの構造例を示す説明図である。ＡＦＣデータパケットの構造例を示す説明図である。ＡＦＣデータパケットの構造例を示す説明図である。ＡＦＣデータパケットの構造例を示す説明図である。ＡＦＣでのパケット伝送例を示す説明図である。ＡＦＣ　Ｆｅｅｄｂａｃｋパケットの構造例を示す説明図である。ＡＦＣ　Ｉｎｇｒｅｓｓが保持するテーブルの構造例を示す説明図である。タイムアウトまでの時間の延長処理を示す説明図である。Ｔｉｍｅｏｕｔ　Ｅｘｔｅｎｓｉｏｎ　Ｒｅｑｕｅｓｔパケットの構造例を示す説明図である。Ｔｉｍｅｏｕｔ　Ｅｘｔｅｎｓｉｏｎ　Ｒｅｓｐｏｎｓｅパケットの構造例を示す説明図である。本開示の実施の形態に係る各ノードとして機能しうる通信装置１００の機能構成例を示す説明図である。

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

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

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

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

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

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

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

　これに対して、以下で説明するものは、ネットワーク内でパケットを転送させるサービスにおいて、サービス利用者が希望するパケットに、サービス利用者が希望する１つまたは複数の機能を作用させるためのアーキテクチャである。本実施形態では、そのようなアーキテクチャのことをＡｐｐｌｉｃａｔｉｏｎ　Ｆｕｎｃｔｉｏｎ　Ｃｈａｉｎｉｎｇ（ＡＦＣ）と称し、ＡＦＣアーキテクチャにおいて作用される機能のことをＡｐｐｌｉｃａｔｉｏｎ　Ｆｕｎｃｔｉｏｎ（ＡＦ）と称する。

　［１．２．ＡＦＣの具体的説明］
　図２は、本開示の実施形態で提案するＡＦＣのアーキテクチャを示す説明図である。ＡＦＣの設定が可能なネットワークワーク領域をＡＦＣ　ｄｏｍａｉｎと呼ぶ。ＡＦＣ　ｄｏｍａｉｎの境界にはＡＦＣ　ＩｎｇｒｅｓｓおよびＡＦＣ　Ｅｇｒｅｓｓと呼ぶノードが配置される。ＡＦＣ　ＩｎｇｒｅｓｓとはＡＦＣを適用するデータパケットに関してＡＦＣ　ｄｏｍａｉｎへの入口となるノードであり、ＡＦＣ　ＥｇｒｅｓｓとはＡＦＣ　ｄｏｍａｉｎの出口となるノードである。同一のノードがＡＦＣ　Ｉｎｇｒｅｓｓとして動作する場合もあれば、ＡＦＣ　Ｅｇｒｅｓｓとして動作する場合もある。携帯電話網のコアネットワークを例にとると、ｅＮＢ、Ｓ－ＧＷあるいはＰ－ＧＷがＡＦＣ　Ｉｎｇｒｅｓｓの役割を果たす場合も考えられる。図２ではＡＦＣ　ＩｎｇｒｅｓｓとＡＦＣ　Ｅｇｒｅｓｓはそれぞれ１台しか存在しないが、複数台存在してもよい。

　ＡＦＣ　ＩｎｇｒｅｓｓとＡＦＣ　Ｅｇｒｅｓｓは、データパケットの送受信に使用するポートと制御パケットを送受信するためのポートとしてそれぞれｗｅｌｌ－ｋｎｏｗｎポートを持つものとする。ＡＦＣ　ＭａｎａｇｅｒはＡＦＣ　ｄｏｍａｉｎ内におけるＡＦＣを管理するノードである。ＡＦＣ　ＵｓｅｒはＡＦＣ　ｄｏｍａｉｎ内にＡＦＣを設置するユーザである。ＡＡＡ　ＳｅｒｖｅｒはＡＦＣ　Ｕｓｅｒの認証認可を行うノードである。ＡＦＣ　ｄｏｍａｉｎ内には１台以上のＡＦ　Ｎｏｄｅが存在する。ＡＦ　ＮｏｄｅとはＡＦの実行が可能なノードである。

　ＡＦ　ＮｏｄｅにはＡＦＣ　Ｄａｅｍｏｎ－ｐと呼ぶデーモンプロセスが常に動作している。ＡＦＣ　Ｄａｅｍｏｎ－ｐは制御パケットを送受信するためのポートとしてｗｅｌｌ－ｋｎｏｗｎポートを持つものとする。図２ではＡＦＣ　Ｄａｅｍｏｎ－ｐの記載を省略している。ＡＦＣ　ＵｓｅｒがＡＦの起動を要求すると、ＡＦＣ　Ｄａｅｍｏｎ－ｐは子プロセスとしてＡＦＣ　Ｄａｅｍｏｎを起動し、その後はＡＦＣ　Ｄａｅｍｏｎが処理を行う。ＣＯＴＳ（Ｃｏｍｍｅｒｃｉａｌ　ｏｆｆ－ｔｈｅ－ｓｈｅｌｆ）　ｄｅｖｉｃｅとは既製品の通信デバイスであり、パラメータ等の設定変更は可能であるがソフトウェアの変更はできないことを想定する。ＳｅｒｖｅｒとはＣＯＴＳ　ｄｅｖｉｃｅの通信相手である。ＣＯＴＳ　ｄｅｖｉｃｅ上のアプリケーションはＳｅｒｖｅｒ上のアプリケーションと通信するものとする。

　ＣＯＴＳ　ｄｅｖｉｃｅからＳｅｒｖｅｒにデータを送信する場合、ＡＦＣ　Ｉｎｇｒｅｓｓは本開示の開始ノードの一例であり、ＡＦＣ　Ｅｇｒｅｓｓは本開示の目的ノードの一例である。またＣＯＴＳ　ｄｅｖｉｃｅは本開示の送信元ノードの一例であり、Ｓｅｒｖｅｒは本開示の送信先ノードの一例である。

　途中で分岐と合流があるＡＦＣや同一のＡＦを複数のＡＦ　Ｎｏｄｅに配置したＡＦＣ　では、データパケットが転送される経路はデータパケットごとに異なる場合がある。ＡＦＣ上で実際にデータパケットが転送される経路をＡＦＣパスと呼ぶこととする。

　（ＡＦＣ　ｆｏｒ　ＣＯＴＳ　ｄｅｖｉｃｅの動作概要）
　ＣＯＴＳ　ｄｅｖｉｃｅ上のアプリケーションとＳｅｒｖｅｒ上のアプリケーションとの通信にＡＦＣを適用する手順の概略は以下（１）～（８）の通りである。

　（１）ＡＦＣ　ＵｓｅｒはＡＦＣで使用する１つ以上のＡＦを希望するＡＦ　Ｎｏｄｅに設置する。この作業を　ＡＦ　Ｓｅｔｕｐと呼ぶ。

　（２）ＡＦＣ　Ｕｓｅｒは設置したＡＦを直線状あるいは分岐と合流がある形状に連結し、ＡＦＣを設置する。ＡＦＣの構成情報はＡＦＣ　Ｉｎｇｒｅｓｓが保持する。この作業をＡＦＣ　Ｓｅｔｕｐと呼ぶ。ＣＯＴＳ　ｄｅｖｉｃｅ上のアプリケーションが送信するデータパケットの中からＡＦＣを適用すべきデータパケットを選別するためには、いわゆる５タプル（始点ＩＰアドレス、終点ＩＰアドレス、プロトコル、始点ポート番号、終点ポート番号）を使用する。

　（３）ＣＯＴＳ　ｄｅｖｉｃｅ上のアプリケーションはＴＣＰ／ＩＰまたはＵＤＰ／ＩＰでデータパケットを送信する。このパケットを元データパケットと呼ぶ。元データパケットはＡＦＣ　Ｉｎｇｒｅｓｓに到達する。ＡＦＣ　Ｉｎｇｒｅｓｓは５タプルにより適用すべきＡＦＣを選別し、受信したデータパケットにＡＦＣを実現するためのＩＰヘッダ、ＵＤＰヘッダおよびＡＦＣヘッダを付加する。このパケットをＡＦＣデータパケットと呼ぶこととする。図３はＡＦＣデータパケットの構造を示す説明図である。以降、「ＩＰヘッダ」や「ＵＤＰヘッダ」は元データパケットに付加されたＩＰヘッダやＵＤＰヘッダを指すこととする。

　（４）ＡＦＣ　ＩｎｇｒｅｓｓはＡＦＣデータパケットを送信する。ＡＦＣデータパケットはＡＦＣを構成するＡＦ　Ｎｏｄｅを経由し、それぞれのＡＦ　Ｎｏｄｅで元データパケットにＡＦが適用される。そして最終的にＡＦＣデータパケットはＡＦＣ　Ｅｇｒｅｓｓに到達する。

　（５）ＡＦＣ　ＥｇｒｅｓｓはＡＦＣデータパケットからＩＰヘッダ、ＵＤＰヘッダおよびＡＦＣヘッダを削除して元データパケットを取り出し、取り出したパケットを送信する。

　（６）最終的に元データパケットはＳｅｒｖｅｒ上のアプリケーションに到達する。

　（７）ＡＦＣ　Ｕｓｅｒは不要になったＡＦＣを削除する。この動作をＡＦＣ　Ｄｅｌｅｔｅと呼ぶ。

　（８）ＡＦＣ　Ｕｓｅｒは不要になったＡＦを削除する。この動作をＡＦ　Ｄｅｌｅｔｅと呼ぶ。

　（制御パケットのフィールドの役割）
　本実施形態で使用する制御パケットには以下の１７種類がある。ＡＦ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケット、ＡＦ　Ｓｅｔｕｐ　Ｒｅｓｐｏｎｓｅパケット、ＡＡ　Ｒｅｑｕｅｓｔパケット、ＡＡ　Ｒｅｓｐｏｎｓｅパケット、ＡＦ　Ｉｎｖｏｋｅ　Ｒｅｑｕｅｓｔパケット、ＡＦ　Ｉｎｖｏｋｅ　Ｒｅｓｐｏｎｓｅパケット、ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケット、ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｓｐｏｎｓｅパケット、ＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｑｕｅｓｔパケット、ＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｓｐｏｎｓｅパケット、ＡＦＣ　Ｄｅｌｅｔｅ　Ｒｅｑｕｅｓｔパケット、ＡＦＣ　Ｄｅｌｅｔｅ　Ｒｅｓｐｏｎｓｅパケット、ＡＦ　Ｄｅｌｅｔｅ　Ｒｅｑｕｅｓｔパケット、ＡＦ　Ｄｅｌｅｔｅ　Ｒｅｓｐｏｎｓｅパケット、Ｌｏａｄ　Ｍｏｎｉｔｏｒｉｎｇ　Ｒｅｑｕｅｓｔパケット、Ｌｏａｄ　Ｍｏｎｉｔｏｒｉｎｇ　ＲｅｓｐｏｎｓｅパケットおよびＦｅｅｄｂａｃｋパケットである。

　制御パケットの各フィールドは以下の役割を持つ。Ｔｙｐｅフィールドはパケットのタイプを示す。パケットタイプは大きく分けて動作を要求するＲｅｑｕｅｓｔパケットと、Ｒｅｑｕｅｓｔパケットに対する応答パケットであるＲｅｓｐｏｎｓｅパケットとがある。Ｕｓｅｒ　ＩＤフィールドはＡＦＣ　Ｕｓｅｒの識別子を示す。Ｕｓｅｒ　ＣｒｅｄｅｎｔｉａｌはＡＦＣ　Ｕｓｅｒの認証認可のための情報を示す。認証認可のための情報とは、例えばユーザ名とパスワードである。ＡＦ　Ｎｏｄｅ　ＩＰ　ＡｄｄｒｅｓｓフィールドはＡＦ　ＮｏｄｅのＩＰアドレスを示す。本実施形態ではＡＦは実行形ファイルとしてＡＦ　Ｎｏｄｅに格納されていると仮定する。ＡＦ　Ｆｉｌｅ　ＮａｍｅフィールドはＡＦの実行形ファイル名を示す。ＡＦ　ＰａｒａｍｅｔｅｒｓフィールドはＡＦを起動する際のパラメータを示す。ＳｔａｔｕｓフィールドはＲｅｑｕｅｓｔパケットが示す処理要求に対する処理結果を示す。ＡＦ　ＩＤフィールドはＡＦの識別子を示す。ＡＦＣ　Ｄａｅｍｏｎ　Ｄａｔａ　Ｐｏｒｔフィールドは、ＡＦＣ　ＤａｅｍｏｎがＡＦＣデータパケットを送受信するためのポート番号を示す。ＡＦＣ　Ｄａｅｍｏｎ　Ｃｏｎｔｒｏｌ　Ｐｏｒｔフィールドは、ＡＦＣ　Ｄａｅｍｏｎが制御パケットを送受信するためのポート番号を示す。

　以下に示す５つのフィールドはＡＦＣを適用すべき元データパケットを選別するためのマッチフィールドである。Ｓｏｕｒｃｅ　ＩＰ　Ａｄｄｒｅｓｓフィールドは始点ＩＰアドレスを示す。Ｄｅｓｔｉｎａｔｉｏｎ　ＩＰ　Ａｄｄｒｅｓｓフィールドは終点ＩＰアドレスを示す。Ｐｒｏｔｏｃｏｌフィールドはトランスポート層プロトコルの種類を示す。Ｓｏｕｒｃｅ　Ｐｏｒｔフィールドは始点ポート番号を示す。Ｄｅｓｔｉｎａｔｉｏｎ　Ｐｏｒｔフィールドは終点ポート番号示す。

　Ｉｎｇｒｅｓｓ　ＩＰ　ＡｄｄｒｅｓｓフィールドはＡＦＣ　ＩｎｇｒｅｓｓのＩＰアドレスを示す。Ｅｇｒｅｓｓ　ＩＰ　ＡｄｄｒｅｓｓフィールドはＡＦＣ　ＥｇｒｅｓｓのＩＰアドレスを示す。Ｎｏ　ｏｆ　ＡＦｓフィールドはＡＦＣを構成するＡＦの個数を示す。

　ＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙフィールドは、ＡＦＣ　Ｕｓｅｒが設置したＡＦに関してＡＦＣ　Ｕｓｅｒ、ＡＦＣ　Ｍａｎａｇｅｒ、ＡＦＣ　ＩｎｇｒｅｓｓおよびＡＦＣ　ｄａｅｍｏｎが共有する鍵情報を示す。ＡＦ　ＣｅｒｔｉｆｉｃａｔｅフィールドはＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙから生成した証明書情報を示す。Ｎｅｘｔ　Ｉｎｄｅｘ　ＬｅｎｇｔｈフィールドはＮｅｘｔ　Ｉｎｄｅｘフィールドの長さを示す。Ｎｅｘｔ　Ｉｎｄｅｘフィールドは、ＡＦＣを構成するＡＦのうち次に適用すべきＡＦのインデックス（ＡＦＣ内での順番を表す番号であり、０から始まる）を示す。

　ＡＦＣ　Ｓｅｓｓｉｏｎ　Ｋｅｙフィールドは、ＡＦＣ　Ｕｓｅｒが設置したＡＦＣに関してＡＦＣ　Ｕｓｅｒ、ＡＦＣ　ＭａｎａｇｅｒおよびＡＦＣ　Ｉｎｇｒｅｓｓが共有する鍵情報を示す。ＡＦＣ　ＣｅｒｔｉｆｉｃａｔｅフィールドはＡＦＣ　Ｓｅｓｓｉｏｎ　Ｋｅｙから生成した証明書情報を示す。ＬｏａｄフィールドはＡＦ　Ｎｏｄｅの負荷を示す。Ｉｎ　ＴｉｍｅｓｔａｍｐフィールドはＡＦ　ＮｏｄｅがＡＦＣデータパケットを受信したときの時刻を示す。Ｏｕｔ　ＴｉｍｅｓｔａｍｐフィールドはＡＦ　ＮｏｄｅがＡＦＣデータパケットを送信したときの時刻を示す。Ｉｎｇｒｅｓｓ　Ｏｕｔ　ＴｉｍｅｓｔａｍｐフィールドはＡＦＣ　ＩｎｇｒｅｓｓがＡＦＣデータパケットを送信したときの時刻を示す。Ｅｇｒｅｓｓ　Ｉｎ　ＴｉｍｅｓｔａｍｐフィールドはＡＦＣ　ＥｇｒｅｓｓがＡＦＣデータパケットを受信したときの時刻を示す。

　（ＡＦＣヘッダのフィールドの役割）
　ＡＦＣにおけるデータパケットのヘッダは、ＩＰヘッダ、ＵＤＰヘッダおよびＡＦＣヘッダから構成される。本実施形態では、ＩＰヘッダに関しては始点ＩＰアドレス（Ｓｒｃ　ＩＰ）フィールドと終点ＩＰアドレス（Ｄｓｔ　ＩＰ）フィールドのみに着目する。ＵＤＰヘッダに関しては始点ポート（Ｓｒｃ　Ｐｏｒｔ）フィールドと終点ポート（Ｄｓｔ　Ｐｏｒｔ）フィールドのみに着目する。

　ＡＦＣヘッダは以下のフィールドからなる。ＡＦＣ　ＩＤフィールドはＡＦＣの識別子を示す。Ｓｅｑｕｅｎｃｅ　ＮｕｍｂｅｒフィールドはＡＦＣデータパケットのシーケンス番号を示す。シーケンス番号はＡＦＣごとに割り当てられる。Ｉｎｇｒｅｓｓ　Ｏｕｔ　ＴｉｍｅｓｔａｍｐフィールドはＡＦＣ　ＩｎｇｒｅｓｓがＡＦＣデータパケットを送信したときの時刻を示す。Ｆｌａｇｓフィールドにはさまざまなフラグが設定されることができる。本実施形態ではＦｅｅｄｂａｃｋフラグのみを定義する。Ｆｅｅｄｂａｃｋフラグが設定されたＡＦＣデータパケットをＡＦＣ　Ｅｇｒｅｓｓが受信した場合、ＡＦＣ　ＥｇｒｅｓｓはＡＦＣ　ＩｎｇｒｅｓｓにＡＦＣ　Ｆｅｅｄｂａｃｋパケットを送信する。Ｎｏ　ｏｆ　ＡＦｓフィールドはＡＦＣを構成するＡＦの個数を示す。ＡＦ　Ｉｎｄｅｘフィールドは次に適用するＡＦのインデックス（０から始まる）を示す。ＡＦ　Ｎｏｄｅ　ＩＰ　ＡｄｄｒｅｓｓフィールドはＡＦ　ＮｏｄｅのＩＰアドレスを示す。Ｄａｅｍｏｎ　Ｄａｔａ　Ｐｏｒｔフィールドは、ＡＦＣ　ＤａｅｍｏｎがＡＦＣデータパケットの送受信に使用するポート番号を示す。ＡＦ　ＩＤフィールドはＡＦの識別子を示す。ＡＦ　Ｃｅｒｔｉｆｉｃａｔｅフィールドは、ＡＦＣ　Ｕｓｅｒが設置したＡＦに関してＡＦＣ　ＵｓｅｒとＡＦＣ　Ｄａｅｍｏｎとの間で共有する鍵情報から生成した証明書情報を示す。Ｎｅｘｔ　Ｉｎｄｅｘ　ＬｅｎｇｔｈフィールドはＮｅｘｔ　Ｉｎｄｅｘフィールドの長さを示す。Ｎｅｘｔ　Ｉｎｄｅｘフィールドは次に適用するＡＦのインデックスを示す。このフィールドは「条件式：ＡＦのインデックス」という対からなる。Ｉｎ　ＴｉｍｅｓｔａｍｐフィールドはＡＦ　ＮｏｄｅがＡＦＣデータパケットを受信したときの時刻を示す。Ｏｕｔ　ＴｉｍｅｓｔａｍｐフィールドはＡＦ　ＮｏｄｅがＡＦＣデータパケットを送信したときの時刻を示す。Ｅｇｒｅｓｓ　ＩＰ　ＡｄｄｒｅｓｓはＡＦＣ　ＥｇｒｅｓｓのＩＰアドレスを示す。Ｅｇｒｅｓｓ　Ｄａｔａ　ＰｏｒｔフィールドはＡＦＣ　ＥｇｒｅｓｓがＡＦＣデータパケットを受信するためのポート番号を示す。

　（管理用テーブルのフィールドの役割）
　ＡＦＣ　Ｄａｅｍｏｎは、管理用テーブルとして、Ｄａｅｍｏｎ　ＡＦ　ＴａｂｌｅとＤａｅｍｏｎ　ＡＦＣ　Ｔａｂｌｅを保持する。ＡＦＣ　Ｍａｎａｇｅｒは、管理用テーブルとして、Ｍａｎａｇｅｒ　Ｕｓｅｒ　Ｔａｂｌｅ、Ｍａｎａｇｅｒ　ＡＦＣ　Ｔａｂｌｅ、Ｍａｎａｇｅｒ　ＡＦ　Ｔａｂｌｅ、Ｍａｎａｇｅｒ　ＡＦ　ＬｉｓｔおよびＭａｎａｇｅｒ　ＡＦ　Ｎｏｄｅ　Ｔａｂｌｅを保持する。ＡＦＣ　Ｉｎｇｒｅｓｓは、管理用テーブルとして、Ｉｎｇｒｅｓｓ　ＡＦＣ　Ｔａｂｌｅ、Ｉｎｇｒｅｓｓ　ＡＦ　Ｔａｂｌｅ、Ｉｎｇｒｅｓｓ　ＡＦ　Ｎｏｄｅ　Ｔａｂｌｅ、Ｉｎｇｒｅｓｓ　ＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　Ｔａｂｌｅ、Ｉｎｇｒｅｓｓ　ＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　ＥｎｔｒｙおよびＩｎｇｒｅｓｓ　ＡＦ　Ｎｏｄｅ　ＴＳ　Ｔａｂｌｅを保持する。

　管理用テーブルの各フィールドは以下の役割を持つ。ｐｔｒ　ｔｏ　ｎｅｘｔ　Ｕｓｅｒ　Ｔａｂｌｅフィールドは他のＵｓｅｒ　Ｔａｂｌｅを指すポインタを示す。ｐｔｒ　ｔｏ　ＡＦ　Ｔａｂｌｅフィールドは他のＡＦ　Ｔａｂｌｅを指すポインタを示す。ｐｔｒ　ｔｏ　ｎｅｘｔ　ＡＦ　Ｔａｂｌｅフィールドは他のＡＦ　Ｔａｂｌｅを指すポインタを示す。Ｕｓｅｒ　ＩＤフィールドはＡＦＣ　Ｕｓｅｒの識別子を示す。Ｔｉｍｅ　ｔｏ　ＬｉｖｅフィールドはＡＦＣ　Ｕｓｅｒに関連する設定情報がタイムアウトするまでの時間を示す。ＡＦ　ＩＤフィールドはＡＦの識別子を示す。ＡＦ　Ｉｎ　ＰｏｒｔフィールドはＡＦに元データパケットを入力する際に使用するポート番号を示す。ＡＦ　Ｏｕｔ　ＰｏｒｔフィールドはＡＦから処理済みの元データパケットを受け取る際に使用するポート番号を示す。ＡＦＣ　Ｓｅｓｓｉｏｎ　ＫｅｙはＡＦＣ　Ｕｓｅｒが設置したＡＦＣに関してＡＦＣ　ＵｓｅｒとＡＦＣ　Ｍａｎａｇｅｒとが共有する鍵情報を示す。ＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙフィールドは、ＡＦＣ　Ｕｓｅｒが設置したＡＦに関してＡＦＣ　Ｕｓｅｒ、ＡＦＣ　Ｍａｎａｇｅｒ、ＡＦＣ　ＩｎｇｒｅｓｓおよびＡＦＣ　ｄａｅｍｏｎが共有する鍵情報を示す。ＡＦ　Ｎｏｄｅ　ＩＰ　ＡｄｄｒｅｓｓフィールドはＡＦ　ＮｏｄｅのＩＰアドレスを示す。Ｄａｅｍｏｎ　Ｄａｔａ　ＰｏｒｔフィールドはＡＦＣ　ＤａｅｍｏｎがＡＦＣデータパケットの送受信に使用するポート番号を示す。Ｄａｅｍｏｎ　ＣｏｎｔｒｏｌＰｏｒｔフィールドはＡＦＣ　Ｄａｅｍｏｎが制御パケットの送受信に使用するポート番号を示す。Ｉｎｇｒｅｓｓ　ＩＰ　ＡｄｄｒｅｓｓフィールドはＡＦＣ　ＩｎｇｒｅｓｓのＩＰアドレスを示す。Ｅｇｒｅｓｓ　ＩＰ　ＡｄｄｒｅｓｓフィールドはＡＦＣ　ＥｇｒｅｓｓのＩＰアドレスを示す。Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒフィールドは直近に受信したＡＦＣデータパケットのシーケンス番号を示す。Ｎｅｘｔ　Ｉｎｄｅｘ　ＬｅｎｇｔｈフィールドはＮｅｘｔ　Ｉｎｄｅｘフィールドの長さを示す。Ｎｅｘｔ　Ｉｎｄｅｘフィールドは次に適用するＡＦのインデックスを示す。このフィールドは「条件式：ＡＦのインデックス」という対からなる。ＬｏａｄフィールドはＡＦ　Ｎｏｄｅの負荷を示す。ｐｔｒ　ｔｏ　Ｎｅｘｔ　ＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　Ｔａｂｌｅフィールドは他のＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　Ｔａｂｌｅを指すポインタを示す。ｐｔｒ　ｔｏ　ＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　ＥｎｔｒｙフィールドはＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　Ｅｎｔｒｙを指すポインタを示す。ＡＦＣ　Ｐａｔｈ　ＩＤフィールドはＡＦＣパスの識別子を示す。ｐｔｒ　ｔｏ　ｎｅｘｔ　ＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　Ｅｎｔｒｙフィールドは他のＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　Ｅｎｔｒｙを指すポインタを示す。ｐｔｒ　ｔｏ　ＡＦ　Ｎｏｄｅ　ＴＳ　ＴａｂｌｅフィールドはＡＦ　Ｎｏｄｅ　ＴＳ　Ｔａｂｌｅを指すポインタを示す。Ｉｎｇｒｅｓｓ　Ｏｕｔ　ＴｉｍｅｓｔａｍｐフィールドはＡＦＣ　ＩｎｇｒｅｓｓがＡＦＣデータパケットを送信したときの時刻を示す。Ｅｇｒｅｓｓ　Ｉｎ　ＴｉｍｅｓｔａｍｐフィールドはＡＦＣ　ＥｇｒｅｓｓがＡＦＣデータパケットを受信したときの時刻を示す。ｐｔｒ　ｔｏ　ｎｅｘｔ　ＡＦ　Ｎｏｄｅ　ＴＳ　Ｔａｂｌｅフィールドは他のＡＦ　Ｎｏｄｅ　ＴＳ　Ｔａｂｌｅへのポインタを示す。Ｉｎ　ＴｉｍｅｓｔａｍｐフィールドはＡＦ　ＮｏｄｅがＡＦＣデータパケットを受信したときの時刻を示す。Ｏｕｔ　ＴｉｍｅｓｔａｍｐフィールドはＡＦ　ＮｏｄｅがＡＦＣデータパケットを送信したときの時刻を示す。

　（セキュリティ対策）
　セキュリティを保つため、本実施形態では以下を仮定する。ＡＦＣ　ＭａｎａｇｅｒとＡＡＡ　ｓｅｒｖｅｒとの間にはＴＬＳ（Ｔｒａｎｓｐｏｒｔ　Ｌａｙｅｒ　Ｓｅｃｕｒｉｔｙ）のような安全な通信路があらかじめ設定されているとする。ＡＦＣ　Ｕｓｅｒ　とＡＦＣ　Ｍａｎａｇｅｒとの間、ＡＦＣ　ＭａｎａｇｅｒとＡＦＣ　Ｉｎｇｒｅｓｓとの間、ＡＦＣ　ＩｎｇｒｅｓｓとＡＦＣ　Ｅｇｒｅｓｓとの間およびＡＦＣ　ＭａｎａｇｅｒとＡＦ　Ｎｏｄｅとの間には必要に応じＴＬＳコネクションの確立が可能であるとする。また、ＣＯＴＳ　ｄｅｖｉｃｅにおけるパラメータ設定により、ＣＯＴＳ　ｄｅｖｉｃｅとＡＦＣ　Ｉｎｇｒｅｓｓとの間にはＷｉ－ＦｉにおけるＷＰＡ２（Ｗｉ－Ｆｉ　Ｐｒｏｔｅｃｔｅｄ　Ａｃｃｅｓｓ　２）のような認証方式による安全な通信路の確立が可能とする。

　図４は、ＡＦの設置におけるセキュリティ対策を示す説明図である。ＡＦＣ　ＵｓｅｒはＡＦＣ　Ｍａｎａｇｅｒとの間にＴＬＳコネクションを確立する（ステップＳ１０１）。ＡＦＣ　ＵｓｅｒがＡＦ　ＮｏｄｅでＡＦを設置する際には、ＡＦ　Ｕｓｅｒは認証認可情報（Ｕｓｅｒ　Ｃｒｅｄｅｎｔｉａｌ）を含むＡＦ設置要求パケット（ＡＦ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケット）をＡＦＣ　Ｍａｎａｇｅｒに送信する（ステップＳ１０２）。

　ＡＦＣ　ＭａｎａｇｅｒはＵｓｅｒ　Ｃｒｅｄｅｎｔｉａｌを含む認証認可要求パケット（ＡＡ　Ｒｅｑｕｅｓｔ　パケット）をＡＡＡサーバに送信する（ステップＳ１０３）。ＡＡＡ　ＳｅｒｖｅｒはＵｓｅｒ　Ｃｒｅｄｅｎｔｉａｌを検証し、ＡＦＣ　Ｕｓｅｒの認証認可を行う（ステップＳ１０４）。ＡＦＣ　Ｕｓｅｒの認証認可とは、ＡＦＣ　Ｕｓｅｒの真正性の検証と、ＡＦＣ　Ｕｓｅｒが特定のＡＦ　Ｎｏｄｅで特定のＡＦを設置し利用する権限を有するかの検証である。

　ＡＡＡ　Ｓｅｒｖｅｒは認証認可の結果をＡＦＣ　Ｍａｎａｇｅｒに返す（ステップＳ１０５）。認証認可が成功した場合、ＡＦＣ　ＭａｎａｇｅｒはＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙを生成する（ステップＳ１０６）。ＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙの生成方法はどのようなものでもよい。ＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙは、例えば任意の長さを有する乱数でもよい。

　続いて、ＡＦＣ　ＭａｎａｇｅｒはＡＦＣ　Ｄａｅｍｏｎとの間にＴＬＳコネクションを確立する（ステップＳ１０７）。ＡＦＣ　ＭａｎａｇｅｒはＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙを含むＡＦ起動要求パケット（ＡＦ　Ｉｎｖｏｋｅ　Ｒｅｑｕｅｓｔパケット）をＡＦＣ　Ｄａｅｍｏｎに送信する（ステップＳ１０８）。

　ＡＦＣ　Ｄａｅｍｏｎは指定されたＡＦを起動する（図４では省略）。そしてＡＦＣ　ＤａｅｍｏｎはＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙを保存することでＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙを共有する（ステップＳ１０９）。

　ＡＦＣ　ＤａｅｍｏｎはＡＦ起動の結果をＡＦＣ　Ｍａｎａｇｅｒに返す（ステップＳ１１０）。続いてＡＦＣ　ＭａｎａｇｅｒはＡＦＣ　Ｄａｅｍｏｎとの間のＴＬＳコネクションを切断する（ステップＳ１１１）。

　続いて、ＡＦＣ　ＭａｎａｇｅｒはＡＦ　Ｓｅｓｓｉｏｎ　ＫｅｙとＡＦ設置の結果を含むパケット（ＡＦ　Ｓｅｔｕｐ　Ｒｅｓｐｏｎｓｅパケット）をＡＦＣ　Ｕｓｅｒに返す（ステップＳ１１２）。ＡＦＣ　ＵｓｅｒはＡＦＣ　Ｍａｎａｇｅｒとの間のＴＬＳコネクションを切断する（ステップＳ１１３）。そして、ＡＦＣ　ＵｓｅｒはＡＦ　ＳｅｓｓｉｏｎＫｅｙを保存することでＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙを共有する（ステップＳ１１４）。

　以上のように権限のあるＡＦＣ　ＵｓｅｒのみがＡＦの設定や利用が可能である。ＡＦＣ　ＵｓｅｒがＡＦの設置や利用の権限を有することは、ＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙという情報としてＡＦＣ　Ｕｓｅｒ、ＡＦＣ　ＭａｎａｇｅｒおよびＡＦＣ　Ｄａｅｍｏｎ間で共有される。ＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙは設置したＡＦごとに生成される。

　（ＡＦＣの設置におけるセキュリティ対策）
　続いて、ＡＦＣの設置におけるセキュリティ対策を説明する。図５は、ＡＦＣの設置におけるセキュリティ対策を示す説明図である。

　図４に示す処理により、設置対象のＡＦＣを構成する全てのＡＦに関してＡＦＣ　ＵｓｅｒとＡＦＣ　ＭａｎａｇｅｒとはＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙを共有している（ステップＳ１２１）。

　ＡＦＣ　ＵｓｅｒはＡＦＣ　Ｍａｎａｇｅｒとの間にＴＬＳコネクションを確立する（ステップＳ１２２）。続いて、ＡＦＣ　ＵｓｅｒはＡＦＣを構成する全てのＡＦに関するＡＦ　Ｃｅｒｔｉｆｉｃａｔｅを含むＡＦＣ設置要求パケット（ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケット）をＡＦＣＭａｎａｇｅｒに送信する（ステップＳ１２３）。ＡＦ　ＣｅｒｔｉｆｉｃａｔｅはＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙから生成する証明書情報である。ＡＦ　Ｃｅｒｔｉｆｉｃａｔｅの生成方法の例としては、ＡＦの識別子とＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙを連結したビット列にハッシュ関数を作用した結果のビット列とする、などの方法が考えられる。

　ＡＦＣ　ＭａｎａｇｅｒはＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔに含まれる全てのＡＦに関して、自身が保持するＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙを用いてＡＦ　Ｃｅｒｔｉｆｉｃａｔｅを検証する（ステップＳ１２４）。ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔに含まれる全てのＡＦに関してＡＦ　Ｃｅｒｔｉｆｉｃａｔｅの検証に成功すると、ＡＦＣ　ＭａｎａｇｅｒはＡＦＣ　Ｓｅｓｓｉｏｎ　Ｋｅｙを生成する（ステップＳ１２５）。ＡＦＣ　Ｓｅｓｓｉｏｎ　Ｋｅｙの生成方法はどのようなものでもよい。例えば、ＡＦＣ　Ｓｅｓｓｉｏｎ　Ｋｅｙは任意の長さの乱数でもよい。

　続いて、ＡＦＣ　ＭａｎａｇｅｒはＡＦＣ　Ｉｎｇｒｅｓｓとの間にＴＬＳコネクションを確立する（ステップＳ１２６）。そしてＡＦＣ　ＭａｎａｇｅｒはＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔに含まれる全てのＡＦに関するＡＦ　Ｓｅｓｓｉｏｎ　ＫｅｙとＡＦＣ　Ｓｅｓｓｉｏｎ　Ｋｅｙとを含むＡＦＣ設置要求パケット（ＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｑｕｅｓｔパケット）をＡＦＣ　Ｉｎｇｒｅｓｓに送信する（ステップＳ１２７）。

　ＡＦＣ　ＩｎｇｒｅｓｓはＡＦＣ　設置情報を保存（図５では省略）し、ＡＦＣを構成する全てのＡＦに関するＡＦ　Ｓｅｓｓｉｏｎ　ＫｅｙとＡＦＣ　Ｓｅｓｓｉｏｎ　Ｋｅｙを保存することでＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙを共有する（ステップＳ１２８）。

　続いて、ＡＦＣ　ＩｎｇｒｅｓｓはＡＦＣ設置処理の結果をＡＦＣ　Ｍａｎａｇｅｒに返す（ステップＳ１２９）。ＡＦＣ　ＭａｎａｇｅｒはＡＦＣ　Ｉｎｇｒｅｓｓとの間のＴＬＳコネクションを切断する（ステップＳ１３０）。

　ＡＦＣ　ＭａｎａｇｅｒはＡＦＣ設置処理の結果とＡＦＣ　Ｓｅｓｓｉｏｎ　Ｋｅｙを含むパケット（ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｓｐｏｎｓｅパケット）をＡＦＣ　Ｕｓｅｒに返す（ステップＳ１３１）。ＡＦＣ　ＵｓｅｒはＡＦＣ　Ｍａｎａｇｅｒとの間のＴＬＳコネクションを切断する（ステップＳ１３２）。そして、ＡＦＣ　ＵｓｅｒはＡＦＣ　Ｓｅｓｓｉｏｎ　Ｋｅｙを保存することでＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙを共有する（ステップＳ１３３）。

　以上のようにＡＦＣ　ＵｓｅｒがＡＦＣを設置する際、ＡＦＣ　Ｕｓｅｒの権限が確認される。ＡＦＣ　Ｓｅｓｓｉｏｎ　ＫｅｙはＡＦＣごとに生成され、ＡＦＣ　Ｕｓｅｒ、ＡＦＣ　ＭａｎａｇｅｒおよびＡＦＣ　Ｉｎｇｒｅｓｓ間で共有される。また、ＡＦ　Ｓｅｓｓｉｏｎ　ＫｅｙはＡＦＣ　Ｕｓｅｒ、ＡＦＣ　ＭａｎａｇｅｒおよびＡＦＣ　Ｄａｅｍｏｎに加え、ＡＦＣ　Ｉｎｇｒｅｓｓにも共有される。

　（データパケット転送におけるセキュリティ対策）
　続いて、データパケット転送におけるセキュリティ対策を説明する。図６は、データパケット転送におけるセキュリティ対策を示す説明図である。

　図４および図５に示す処理により、ＡＦＣを構成する各ＡＦに関するＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙは、ＡＦＣ　Ｕｓｅｒ、ＡＦＣ　ＤａｅｍｏｎおよびＡＦＣ　Ｉｎｇｒｅｓｓとの間で共有されている（ステップＳ１４１）。

　ＣＯＴＳ　ｄｅｖｉｃｅは元データパケットを送信する（ステップＳ１４２）。ＡＦＣ　Ｉｎｇｒｅｓｓは元データパケットを受信してＡＦＣ　データパケットを送信する際、ＡＦＣを構成する各ＡＦに関するＡＦ　Ｓｅｓｓｉｏｎ　ＫｅｙからＡＦ　Ｃｅｒｔｉｆｉｃａｔｅを生成してＡＦＣヘッダに含める（ステップＳ１４３）。ＡＦ　Ｃｅｒｔｉｆｉｃａｔｅの生成方法の例としては、シーケンス番号、ＡＦの識別子およびＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙを連結したビット列にハッシュ関数を作用した結果のビット列とする、などの方法が考えられる。

　続いてＡＦＣ　ＩｎｇｒｅｓｓはＡＦＣデータパケットをＡＦＣ　Ｄａｅｍｏｎに送信する（ステップＳ１４４）。ＡＦＣ　Ｄａｅｍｏｎは自身上で動作するＡＦに関するＡＦ　Ｃｅｒｔｉｆｉｃａｔｅを検証する（ステップＳ１４５）。検証に成功すると、ＡＦＣ　ＤａｅｍｏｎはＡＦＣデータパケットにＡＦを適用する（図６では省略）。ＡＦＣ　ＤａｅｍｏｎはＡＦＣデータパケットを次のＡＦＣ　Ｄａｅｍｏｎに転送する（ステップＳ１４６）。

　以降、ＡＦＣパスにおいて同様の処理が行われる。上述の処理により、不正なノードが不正なＡＦＣデータパケットを偽造してＡＦ　Ｎｏｄｅに送信しても、ＡＦＣ　Ｄａｅｍｏｎは不正なＡＦＣデータパケットであることを検知できる。ＡＦＣ　Ｉｎｇｒｅｓｓは元データパケットを受信してＡＦＣデータパケットを送信する際、パケットごとにシーケンス番号をインクリメントしてＡＦＣヘッダに含める。シーケンス番号はＡＦＣごとに割り当てられる。一方、ＡＦＣ　Ｄａｅｍｏｎは受信したＡＦＣデータパケットのシーケンス番号を記録している。従って、不正なノードが正当なＡＦＣデータパケットを盗聴して蓄え、あとから盗聴したパケットを送信（ｒｅｐｌａｙ　ａｔｔａｃｋ）しても、ＡＦＣ　Ｄａｅｍｏｎはｒｅｐｌａｙ　ａｔｔａｃｋであることを検知できる。上記のようにＡＦ　Ｃｅｒｔｉｆｉｃａｔｅを生成する際にシーケンス番号も利用していれば、偽造したシーケンス番号も検出できる。

　（ＡＦＣの削除におけるセキュリティ対策）
　続いて、ＡＦＣの削除におけるセキュリティ対策を説明する。図７は、ＡＦＣの削除におけるセキュリティ対策を示す説明図である。

　図５に示す処理により、ＡＦＣ　Ｕｓｅｒ、ＡＦＣ　ＭａｎａｇｅｒおよびＡＦＣ　Ｉｎｇｒｅｓｓは削除対象のＡＦＣに関するＡＦＣ　Ｓｅｓｓｉｏｎ　Ｋｅｙを共有している（ステップＳ１５１）。

　ＡＦＣ　ＵｓｅｒはＡＦＣ　Ｃｅｒｔｉｆｉｃａｔｅを含むＡＦＣ削除要求パケット（ＡＦＣ　Ｄｅｌｅｔｅ　Ｒｅｑｕｅｓｔパケット）をＡＦＣ　Ｍａｎａｇｅｒに送信する（ステップＳ１５２）。ＡＦＣ　Ｃｅｒｔｉｆｉｃａｔｅの生成方法の例としては、ＡＦＣの識別子とＡＦＣ　Ｓｅｓｓｉｏｎ　Ｋｅｙを連結したビット列にハッシュ関数を作用した結果のビット列とする、などの方法が考えられる。

　ＡＦＣ　ＭａｎａｇｅｒはＡＦＣ　Ｃｅｒｔｉｆｉｃａｔｅを検証し、ＡＦＣ　Ｕｓｅｒが対象となるＡＦＣに関する権限を有することを確認する（ステップＳ１５３）。続いてＡＦＣ　ＭａｎａｇｅｒはＡＦＣ　Ｄｅｌｅｔｅ　ＲｅｑｕｅｓｔパケットをＡＦＣ　Ｉｎｇｒｅｓｓに転送する（ステップＳ１５４）。

　ＡＦＣ　ＩｎｇｒｅｓｓはＡＦＣ　Ｃｅｒｔｉｆｉｃａｔｅを検証し（ステップＳ１５５）、ＡＦＣ　Ｕｓｅｒが対象となるＡＦＣに関する権限を有することを確認し、ＡＦＣの設定を削除（図７では省略）する。続いてＡＦＣ　Ｉｎｇｒｅｓｓは応答パケットをＡＦＣ　Ｍａｎａｇｅｒに返送する（ステップＳ１５６）。ＡＦＣ　Ｍａｎａｇｅｒは応答パケットをＡＦＣ　Ｕｓｅｒに転送する（ステップＳ１５７）。以上のように、権限を有するＡＦＣ　ＵｓｅｒのみがＡＦＣを削除することができる。

　（ＡＦの削除におけるセキュリティ対策）
　続いて、ＡＦの削除におけるセキュリティ対策を説明する。図８は、ＡＦの削除におけるセキュリティ対策を示す説明図である。

　図４に示す処理により、ＡＦＣ　Ｕｓｅｒ、ＡＦＣ　ＭａｎａｇｅｒおよびＡＦＣ　Ｄａｅｍｏｎは削除対象のＡＦに関するＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙを共有している（ステップＳ１６１）。

　ＡＦＣ　Ｕｓｅｒは削除対象のＡＦに関するＡＦ　Ｃｅｒｔｉｆｉｃａｔｅを含むＡＦ　削除要求パケット（ＡＦ　Ｄｅｌｅｔｅ　Ｒｅｑｕｅｓｔパケット）をＡＦＣ　Ｍａｎａｇｅｒに送信する（ステップＳ１６２）。ＡＦ　Ｃｅｒｔｉｆｉｃａｔｅの生成方法の例としては、ＡＦの識別子とＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙとを連結したビット列にハッシュ関数を作用した結果のビット列とする、などの方法が考えられる。

　ＡＦＣ　ＭａｎａｇｅｒはＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙを用いてＡＦ　Ｃｅｒｔｉｆｉｃａｔｅを検証し（ステップＳ１６３）、検証が成功すると関連する情報を削除する（図８では省略）。続いてＡＦＣ　ＭａｎａｇｅｒはＡＦ　Ｄｅｌｅｔｅ　ＲｅｑｕｅｓｔパケットをＡＦＣ　Ｄａｅｍｏｎに転送する（ステップＳ１６４）。

　ＡＦＣ　ＤａｅｍｏｎはＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙを用いてＡＦ　Ｃｅｒｔｉｆｉｃａｔｅを検証し（ステップＳ１６５）、検証が成功するとＡＦを削除し、関連する情報を削除する（図８では省略）。ＡＦＣ　Ｉｎｇｒｅｓｓは応答パケットをＡＦＣ　Ｍａｎａｇｅｒに返す（ステップＳ１６６）。ＡＦＣ　Ｍａｎａｇｅｒは応答パケットをＡＦＣ　Ｕｓｅｒに転送する（ステップＳ１６７）。以上のように、権限を有するＡＦＣ　ＵｓｅｒのみがＡＦを削除することができる。

　（ＡＦ　Ｎｏｄｅ－１でのＡＦ－１の設置）
　続いて、あるＡＦ　Ｎｏｄｅ（ＡＦ　Ｎｏｄｅ－１とする）でのＡＦ（ＡＦ－１）の設置について説明する。図９は、ＡＦＣ　Ｕｓｅｒ－１が　ＡＦ　Ｎｏｄｅ－１上にＡＦ－１を設置する際の手順を示す説明図である。ＡＦＣ　Ｕｓｅｒ－１の識別子をＵＳＲＩＤ－１とする。ＡＦＣ　Ｕｓｅｒ－１のｃｒｅｄｅｎｔｉａｌをＵＳＲＣｒｅｄ－ｕｓｒ１とする。ＡＦ－１の実行形ファイル名をＦＮａｍｅ－ａｆ１とする。ＡＦ－１を実行する際のパラメータをＰａｒａｍ－ａｆ１とする。ＡＦ　Ｎｏｄｅ－１のＩＰアドレスをＩＰ－ａｆｎ１とする。

　まずＡＦＣ　Ｕｓｅｒ－１はＡＦＣ　Ｍａｎａｇｅｒとの間にＴＬＳコネクションを確立する（ステップＳ１７１）。

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

　ＡＦＣ　ＭａｎａｇｅｒはＡＦ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケットを受信すると、図１２に示すＡＡ　ＲｅｑｕｅｓｔパケットをＡＡＡ　Ｓｅｒｖｅｒに送信する（ステップＳ１７３）。ＡＡ　Ｒｅｑｕｅｓｔパケットの各フィールドの値は以下の通りである。Ｔｙｐｅ　フィールドには「ＡＡ　Ｒｅｑｕｅｓｔ」が設定される。Ｕｓｅｒ　ＩＤフィールドにはＡＦ　Ｓｅｔｕｐ　ＲｅｑｕｅｓｔパケットのＵｓｅｒ　ＩＤフィールドの値であるＵＳＲＩＤ－１が設定される。Ｕｓｅｒ　ＣｒｅｄｅｎｔｉａｌフィールドにはＡＦ　Ｓｅｔｕｐ　ＲｅｑｕｅｓｔパケットのＵｓｅｒ　Ｃｒｅｄｅｎｔｉａｌフィールドの値であるＵＳＲＣｒｅｄ－ｕｓｒ１が設定される。ＡＦ　Ｎｏｄｅ　ＩＰ　ＡｄｄｒｅｓｓフィールドにはＡＦ　Ｓｅｔｕｐ　ＲｅｑｕｅｓｔパケットのＡＦ　Ｎｏｄｅ　ＩＰ　Ａｄｄｒｅｓｓフィールドの値であるＩＰ－ａｆｎ１が設定される。ＡＦ　Ｆｉｌｅ　ＮａｍｅフィールドにはＡＦ　Ｓｅｔｕｐ　ＲｅｑｕｅｓｔパケットのＡＦ　Ｆｉｌｅ　Ｎａｍｅフィールドの値であるＦＮａｍｅ－ａｆ１が設定される。

　ＡＡＡ　ＳｅｒｖｅｒはＡＡ　Ｒｅｑｕｅｓｔパケットを受信すると、Ｕｓｅｒ　Ｃｒｅｄｅｎｔｉａｌフィールドの値を用いてＵｓｅｒ－１がＡＦ　Ｎｏｄｅ－１においてＡＦ－１を起動する権限を有するかを確認する。確認に成功すると、ＡＡ　Ｓｅｒｖｅｒは図１３に示すＡＡ　ＲｅｓｐｏｎｓｅパケットをＡＦＣ　Ｍａｎａｇｅｒに送信する（ステップＳ１７４）。ＡＡ　Ｒｅｓｐｏｎｓｅパケットの各フィールドの値は以下の通りである。Ｔｙｐｅ　フィールドには「ＡＡ　Ｒｅｓｐｏｎｓｅ」が設定される。Ｓｔａｔｕｓフィールドには認証認可の成功を示す「ＯＫ」が設定される。Ｕｓｅｒ　ＩＤフィールドにはＡＡ　ＲｅｑｕｅｓｔパケットのＵｓｅｒ　ＩＤフィールドの値であるＵＳＲＩＤ－１が設定される。

　ＡＦＣ　ＭａｎａｇｅｒはＡＡ　Ｒｅｓｐｏｎｓｅパケットを受信すると、ＡＦ　Ｓｅｔｕｐ　ＲｅｑｕｅｓｔパケットのＡＦ　Ｎｏｄｅ　ＩＰアドレスフィールドからＡＦ　Ｎｏｄｅ－１のＩＰアドレスを知り、ＡＦ　Ｎｏｄｅ－１上のＡＦＣ　Ｄａｅｍｏｎ－１－ｐとの間でＴＬＳコネクション確立処理を開始する（ステップＳ１７５）。ＡＦＣ　Ｄａｅｍｏｎ－１－ｐはＴＬＳコネクション確立要求を受信すると子プロセスであるＡＦＣ　Ｄａｅｍｏｎ－１を生成する（ステップＳ１７６）。以降の処理はＡＦＣ　Ｄａｅｍｏｎ－１が行う。結果として、ＡＦＣ　ＭａｎａｇｅｒとＡＦＣ　Ｄａｅｍｏｎ－１の間にＴＬＳコネクションが確立する（ステップＳ１７７）。

　続いてＡＦＣ　Ｍａｎａｇｅｒは、ＡＦ－１に識別子としてＡＦＩＤ－１を割り当て、ＡＦ－１に関するセッションキーとしてＡＦＳＫｅｙ－ａｆ１を生成する。次にＡＦＣ　Ｍａｎａｇｅｒは図１４に示すＡＦ　Ｉｎｖｏｋｅ　ＲｅｑｕｅｓｔパケットをＡＦＣ　Ｄａｅｍｏｎ－１に送信する（ステップＳ１７８）。ＡＦ　Ｉｎｖｏｋｅ　Ｒｅｑｕｅｓｔパケットの各フィールドの値は以下の通りである。Ｔｙｐｅフィールドには「ＡＦ　Ｉｎｖｏｋｅ　Ｒｅｑｕｅｓｔ」が設定される。Ｕｓｅｒ　ＩＤフィールドにはＡＦ　Ｓｅｔｕｐ　ＲｅｑｕｅｓｔパケットのＵｓｅｒ　ＩＤフィールドの値であるＵＳＲＩＤ－１が設定される。ＡＦ　ＩＤフィールドにはＡＦＩＤ－１が設定される。ＡＦ　Ｓｅｓｓｉｏｎ　ＫｅｙフィールドにはＡＦＳＫｅｙ－ａｆ１が設定される。ＡＦ　Ｆｉｌｅ　ＮａｍｅフィールドにはＡＦ　Ｓｅｔｕｐ　ＲｅｑｕｅｓｔパケットのＡＦ　Ｆｉｌｅ　Ｎａｍｅフィールドの値であるＦＮａｍｅ－ａｆ１が設定される。ＡＦ　ＰａｒａｍｅｔｅｒｓフィールドにはＡＦ　Ｓｅｔｕｐ　ＲｅｑｕｅｓｔパケットのＡＦ　Ｐａｒａｍｅｔｅｒｓフィールドの値であるＰａｒａｍ－ａｆ１が設定される。

　ＡＦＣ　Ｄａｅｍｏｎ－１はＡＦ　Ｉｎｖｏｋｅ　Ｒｅｑｕｅｓｔパケットを受信すると、ＡＦ　Ｆｉｌｅ　Ｎａｍｅフィールドが指定する実行形ファイルを起動し、ＡＦ－１とする（ステップＳ１７９）。その際、ＡＦＣ　Ｄａｅｍｏｎ－１はＡＦ－１の標準入力と標準出力を自身のポートであるＩｎＰｔ－ａｆ１とＯｕｔＰｔ－ａｆ１にそれぞれ接続しておく。次にＡＦＣ　Ｄａｅｍｏｎ－１はＡＦＣデータパケットを送受信するためのポートとしてＤＰｔ－ａｆｃｄ１を生成し、制御パケットを送受信するためのポートとしてＣＰｔ－ａｆｃｄ１を生成する。

　次に　ＡＦＣ　Ｄａｅｍｏｎ－１は図１６に示すＤａｅｍｏｎ　ＡＦ　Ｔａｂｌｅを作成する。Ｄａｅｍｏｎ　ＡＦ　Ｔａｂｌｅの各フィールドの値は以下の通りである。ｐｔｒ　ｔｏ　ｎｅｘｔ　ＡＦ　Ｔａｂｌｅフィールドには［ｎｕｌｌ］が設定される。ＡＦ　ＩＤフィールドにはＡＦ　Ｉｎｖｏｋｅ　ＲｅｑｕｅｓｔパケットのＡＦ　ＩＤフィールドの値であるＡＦＩＤ－１が設定される。ＡＦ　Ｉｎ　ＰｏｒｔフィールドにはＩｎＰｔ－ａｆ１が設定される。ＡＦ　Ｏｕｔ　ＰｏｒｔフィールドにはＯｕｔＰｔ－ａｆ１が設定される。Ｕｓｅｒ　ＩＤフィールドにはＡＦ　Ｉｎｖｏｋｅ　ＲｅｑｕｅｓｔパケットのＵＳＥＲ　ＩＤフィールドの値であるＵＳＲＩＤ－１が設定される。ＡＦ　Ｓｅｓｓｉｏｎ　ＫｅｙフィールドにはＡＦ　Ｉｎｖｏｋｅ　ＲｅｑｕｅｓｔパケットのＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙフィールドの値であるＡＦＳＫｅｙ－ａｆ１が設定される。

　次にＡＦＣ　Ｄａｅｍｏｎ－１は図１５に示すＡＦ　Ｉｎｖｏｋｅ　ＲｅｓｐｏｎｓｅパケットをＡＦＣ　Ｍａｎａｇｅｒに送信する（ステップＳ１８０）。ＡＦ　Ｉｎｖｏｋｅ　Ｒｅｓｐｏｎｓｅパケットの各フィールドの値は以下の通りある。Ｔｙｐｅフィールドには「ＡＦ　Ｉｎｖｏｋｅ　Ｒｅｓｐｏｎｓｅ」が設定される。Ｓｔａｔｕｓフィールドには処理の成功を示す「ＯＫ」が設定される。Ｕｓｅｒ　ＩＤフィールドにはＡＦ　Ｉｎｖｏｋｅ　ＲｅｑｕｅｓｔパケットのＵｓｅｒ　ＩＤフィールドの値であるＵＳＲＩＤ－１が設定される。ＡＦ　ＩＤフィールドにはＡＦ　Ｉｎｖｏｋｅ　ＲｅｑｕｅｓｔパケットのＡＦ　ＩＤフィールドの値であるＡＦＩＤ－１が設定される。ＡＦＣ　Ｄａｅｍｏｎ　Ｄａｔａ　ＰｏｒｔフィールドにはＤＰｔ－ａｆｃｄ１が設定される。ＡＦＣ　Ｄａｅｍｏｎ　Ｄａｔａ　ＰｏｒｔフィールドにはＣＰｔ－ａｆｃｄ１が設定される。

　ＡＦＣ　ＭａｎａｇｅｒはＡＦ　Ｉｎｖｏｋｅ　Ｒｅｓｐｏｎｓｅパケットを受信すると、図１７に示すＭａｎａｇｅｒ　Ｕｓｅｒ　Ｔａｂｌｅ、Ｍａｎａｇｅｒ　ＡＦ　ＴａｂｌｅおよびＭａｎａｇｅｒ　ＡＦ　Ｎｏｄｅ　Ｔａｂｌｅを作成する。

　Ｍａｎａｇｅｒ　Ｕｓｅｒ　Ｔａｂｌｅの各フィールドの値は以下の通りである。ｐｔｒ　ｔｏ　ｎｅｘｔ　Ｕｓｅｒ　Ｔａｂｌｅには［ｎｕｌｌ］が設定される。Ｕｓｅｒ　ＩＤフィールドにはＡＦ　Ｓｅｔｕｐ　ＲｅｑｕｅｓｔパケットのＵｓｅｒ　ＩＤフィールドの値であるＵＳＲＩＤ－１が設定される。Ｔｉｍｅ　ｔｏ　Ｌｉｖｅフィールドには、ＡＦＣ　Ｕｓｅｒ－１の設定情報がタイムアウトするまでの時間であるＴＴＬ－ｕｓｒ１が設定される。ｐｔｒ　ｔｏ　ＡＦ　ＴａｂｌｅフィールドにはＡＦ　Ｔａｂｌｅを指すポインタが設定される。ｐｔｒ　ｔｏ　ＡＦＣ　Ｔａｂｌｅフィールドには［ｎｕｌｌ］が設定される。

　Ｍａｎａｇｅｒ　ＡＦ　Ｔａｂｌｅの各フィールドの値は以下の通りである。ｐｔｒ　ｔｏ　ｎｅｘｔ　ＡＦ　Ｔａｂｌｅには［ｎｕｌｌ］が設定される。ＡＦ　ＩＤフィールドにはＡＦＩＤ－１が設定される。ＡＦ　Ｓｅｓｓｉｏｎ　ＫｅｙフィールドにはＡＦＳＫｅｙ－ａｆ１が設定される。ｐｔｒ　ｔｏ　ＡＦ　Ｎｏｄｅ　ＴａｂｌｅフィールドにはＭａｎａｇｅｒ　ＡＦ　Ｎｏｄｅ　Ｔａｂｌｅを指すポインタが設定される。

　Ｍａｎａｇｅｒ　ＡＦ　Ｎｏｄｅ　Ｔａｂｌｅの各フィールドの値は以下の通りである。ｐｔｒ　ｔｏ　ｎｅｘｔ　ＡＦ　Ｎｏｄｅ　Ｔａｂｌｅには［ｎｕｌｌ］が設定される。ＡＦ　Ｎｏｄｅ　ＩＰ　ＡｄｄｒｅｓｓフィールドにはＡＦ　Ｓｅｔｕｐ　ＲｅｑｕｅｓｔパケットのＡＦ　Ｎｏｄｅ　ＩＰ　Ａｄｄｒｅｓｓフィールドの値であるＩＰ－ａｆｎ１が設定される。Ｄａｅｍｏｎ　Ｄａｔａ　ＰｏｒｔフィールドにはＡＦ　Ｉｎｖｏｋｅ　ＲｅｓｐｏｎｓｅパケットのＤａｅｍｏｎ　Ｄａｔａ　Ｐｏｒｔフィールドの値であるＤＰｔ－ａｆｃｄ１が設定される。Ｄａｅｍｏｎ　Ｃｏｎｔｒｏｌ　ＰｏｒｔフィールドにはＡＦ　Ｉｎｖｏｋｅ　ＲｅｓｐｏｎｓｅパケットのＤａｅｍｏｎ　Ｃｏｎｔｒｏｌ　Ｐｏｒｔフィールドの値であるＣＰｔ－ａｆｃｄ１が設定される。

　ＡＦＣ　ＭａｎａｇｅｒはＡＦ　Ｉｎｖｏｋｅ　Ｒｅｓｐｏｎｓｅパケットを受信すると、ＡＦＣ　Ｄａｅｍｏｎ－１とのＴＬＳコネクションを切断する（ステップＳ１８１）。

　続いてＡＦＣ　Ｍａｎａｇｅｒは図１１に示すＡＦ　Ｓｅｔｕｐ　ＲｅｓｐｏｎｓｅパケットをＡＦＣ　Ｕｓｅｒ－１に送信する（ステップＳ１８２）。ＡＦ　Ｓｅｔｕｐ　Ｒｅｓｐｏｎｓｅパケットの各フィールドの値は以下の通りである。Ｔｙｐｅフィールドには「ＡＦ　Ｓｅｔｕｐ　Ｒｅｓｐｏｎｓｅ」が設定される。Ｓｔａｔｕｓフィールドには処理の成功を示す「ＯＫ」が設定される。Ｕｓｅｒ　ＩＤフィールドにはＡＦ　Ｓｅｔｕｐ　ＲｅｑｕｅｓｔパケットのＵｓｅｒ　ＩＤフィールドの値であるＵＳＲＩＤ－１が設定される。ＡＦ　ＩＤフィールドにはＡＦ　Ｉｎｖｏｋｅ　ＲｅｓｐｏｎｓｅパケットのＡＦ　ＩＤフィールドの値であるＡＦＩＤ－１が設定される。ＡＦ　Ｓｅｓｓｉｏｎ　ＫｅｙフィールドにはＡＦＳＫｅｙ－ａｆ１が設定される。

　ＡＦＣ　Ｕｓｅｒ－１はＡＦ　Ｓｅｔｕｐ　Ｒｅｓｐｏｎｓｅパケット受信すると、ＡＦＣＭａｎａｇｅｒとの間のＴＬＳコネクションを切断する（ステップＳ１８３）。

　（ＡＦ　Ｎｏｄｅ－２へのＡＦ－２の設置およびＡＦ　Ｎｏｄｅ－３へのＡＦ－３の設置）
　次に上記と同様の手順でＡＦＣ　Ｕｓｅｒ－１はＡＦ　Ｎｏｄｅ－２にＡＦ－２を設置し、ＡＦ　Ｎｏｄｅ－３にＡＦ－３を設置したとする。ＡＦ－２の実行形ファイル名をＦＮａｍｅ－ａｆ２とする。ＡＦ－２を実行する際のパラメータをＰａｒａｍ－ａｆ２とする。ＡＦ－２の識別子としてＡＦＩＤ－２が割り当てられたとする。ＡＦ　Ｎｏｄｅ－２のＩＰアドレスをＩＰ－ａｆｎ２とする。ＡＦ　Ｎｏｄｅ－２で動作するＡＦＣ　ＤａｅｍｏｎをＡＦＣ　Ｄａｅｍｏｎ－２とする。ＡＦＣ　Ｄａｅｍｏｎ－２がＡＦ－２とデータのやり取りをするポートとしてＩｎＰｔ－ａｆ２とＯｕｔＰｔ－ａｆ２とが割り当てられたとする。ＡＦ－２のためのＡＦ　Ｓｅｓｓｉｏｎ　ＫｅｙとしてＡＦＳＫｅｙ－ａｆ２が生成されたとする。ＡＦ－３の実行形ファイル名をＦＮａｍｅ－ａｆ３とする。ＡＦ－３を実行する際のパラメータをＰａｒａｍ－ａｆ３とする。ＡＦ－３の識別子としてＡＦＩＤ－３が割り当てられたとする。ＡＦ　Ｎｏｄｅ－３のＩＰアドレスをＩＰ－ａｆｎ３とする。ＡＦ　Ｎｏｄｅ－３で動作するＡＦＣ　ＤａｅｍｏｎをＡＦＣ　Ｄａｅｍｏｎ－３とする。ＡＦＣ　Ｄａｅｍｏｎ－３がＡＦ－３とデータのやり取りをするポートとしてＩｎＰｔ－ａｆ３とＯｕｔＰｔ－ａｆ３とが割り当てられたとする。ＡＦ－３のためのＡＦ　Ｓｅｓｓｉｏｎ　ＫｅｙとしてＡＦＳＫｅｙ－ａｆ３が生成されたとする。

　すると、ＡＦＣ　Ｎｏｄｅ－２上のＡＦＣ　Ｄａｅｍｏｎ－２とＡＦＣ　Ｎｏｄｅ－３上のＡＦＣ　Ｄａｅｍｏｎ－３とはそれぞれ図１８と図１９に示すＤａｅｍｏｎ　ＡＦ　Ｔａｂｌｅを保持する。またＡＦＣ　Ｍａｎａｇｅｒは図２０に示すテーブルを保持する。図１７に示すテーブルに対して図２０はＡＦ－２のためのＭａｎａｇｅｒ　ＡＦ　Ｔａｂｌｅ、ＡＦ－３のためのＭａｎａｇｅｒ　ＡＦ　Ｔａｂｌｅ、ＡＦ　Ｎｏｄｅ－２のためのＭａｎａｇｅｒ　ＡＦ　Ｎｏｄｅ　ＴａｂｌｅおよびＡＦ　Ｎｏｄｅ－３のためのＭａｎａｇｅｒ　ＡＦ　Ｎｏｄｅ　Ｔａｂｌｅが加わっている。

　（直線状のＡＦＣの設置：ＡＦＣ－１）
　ＡＦＣ　Ｕｓｅｒ－１はこの時点でＡＦ－１、ＡＦ－２およびＡＦ－３を設置済みである。ＣＯＴＳ　ｄｅｖｉｃｅが通信するＳｅｒｖｅｒのＩＰ　アドレスをＩＰ－ｓｖｒとし、Ｓｅｒｖｅｒ上のアプリケーションが使用するポート番号をＰｔ－ｓｖｒとする。ＡＦＣ　ＩｎｇｒｅｓｓのＩＰアドレスをＩＰ－ｉｎｇｒｅｓｓとする。ＡＦＣ　ＥｇｒｅｓｓのＩＰアドレスをＩＰ－ｅｇｒｅｓｓとする。ＡＦＣ　Ｕｓｅｒ－１は、終点ＩＰアドレスがＩＰ－ｓｖｒでありかつ終点ポート番号がＰｔ－ｓｖｒであるデータパケットに、ＡＦ１→ＡＦ３という直線状のＡＦＣ（ＡＦＣ－１と呼ぶ）を適用したいとする。図２１は、ＡＦＣ－１の設置手順を示す説明図である。図２２は、ＡＦＣ－１のｐａｔｈを示す説明図である。

　ＡＦＣ　Ｕｓｅｒ－１は、ＡＦＣ　Ｍａｎａｇｅｒとの間にＴＬＳコネクションを確立する（ステップＳ１９１）。

　ＡＦＣ　Ｕｓｅｒ－１は、図２３に示すＡＦＣ　Ｓｅｔｕｐ　ＲｅｑｕｅｓｔパケットをＡＦＣ　Ｍａｎａｇｅｒに送信する（ステップＳ１９２）。ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケットの各フィールドの値は以下の通りである。Ｔｙｐｅフィールドには「ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔ」が設定される。Ｕｓｅｒ　ＩＤ　フィールドにはＵＳＲＩＤ－１が設定される。これに続く５つのフィールドは、ＡＦＣを適用する元データパケットを識別するためのマッチフィールドである。元データパケットの対応するフィールドの値がこのマッチフィールドの値と全て一致した場合、その元データパケットにはＡＦＣが適用される。Ｓｏｕｒｃｅ　ＩＰ　Ａｄｄｒｅｓｓフィールドの値は［ａｎｙ］であるため、元データパケットの始点ＩＰアドレスの値はどのような場合でも条件を満足する。Ｄｅｓｔｉｎａｔｉｏｎ　ＩＰ　Ａｄｄｒｅｓｓフィールドの値はＩＰ－ｓｖｒであるため、元データパケットの終点ＩＰアドレスの値がＩＰ－ｓｖｒの場合のみ条件を満足する。Ｓｏｕｒｃｅ　Ｐｏｒｔフィールドの値は［ａｎｙ］であるため、元データパケットの始点ポート番号はどのような場合でも条件を満足する。Ｄｅｓｔｉｎａｔｉｏｎ　Ｐｏｒｔフィールドの値はＰｔ－ｓｖｒであるため、元データパケットの終点ポート番号がＰｔ－ｓｖｒの場合のみ条件を満足する。Ｐｒｏｔｏｃｏｌフィールドの値はＵＤＰであるため、データパケットのトランスポート層プロトコルがＵＤＰの場合のみ条件を満足する。次に、Ｉｎｇｒｅｓｓ　ＩＰ　ＡｄｄｒｅｓｓフィールドにはＡＦＣ　ＩｎｇｒｅｓｓのＩＰアドレスであるＩＰ－ｉｎｇｒｅｓｓ　が設定される。Ｅｇｒｅｓｓ　ＩＰ　ＡｄｄｒｅｓｓフィールドにはＡＦＣ　ＥｇｒｅｓｓのＩＰアドレスであるＩＰ－ｅｇｒｅｓｓが設定される。Ｎｏ　ｏｆ　ＡＦｓフィールドにはＡＦＣを構成するＡＦの個数である２が設定される。これに続く４つのフィールドはＡＦ－１に関する情報を含む。ＡＦ　ＩＤフィールドにはＡＦＩＤ－１が設定される。ＡＦ　ＣｅｒｔｉｆｉｃａｔｅフィールドにはＡＦＳｋｅｙ－ａｆ１を用いて生成した証明書情報であるＡＦＣｅｒｔ－ａｆ１が設定される。Ｎｅｘｔ　Ｉｎｄｅｘ　ＬｅｎｇｔｈフィールドにはＮｅｘｔ　Ｉｎｄｅｘフィールドの長さを示すＣｏｎｄＬｅｎ－１が設定される。Ｎｅｘｔ　Ｉｎｄｅｘフィールドには、ＡＦ－１の実行結果がどのような場合でも次はＩｎｄｅｘが１であるＡＦ（ＡＦ－３）であることを示す。これに続く以下の４つのフィールドはＡＦ－３に関する情報を含む。ＡＦ　ＩＤフィールドにはＡＦＩＤ－３が設定される。ＡＦ　ＣｅｒｔｉｆｉｃａｔｅフィールドにはＡＦＳＫｅｙ－ａｆ３を用いて生成した証明書情報であるＡＦＣｅｒｔ－ａｆ３が設定される。Ｎｅｘｔ　Ｉｎｄｅｘ　ＬｅｎｇｔｈフィールドにはＮｅｘｔ　Ｉｎｄｅｘフィールドの長さを示すＣｏｎｄＬｅｎ－３が設定される。Ｎｅｘｔ　Ｉｎｄｅｘフィールドの値はＡＦ－３の実行結果がどのような場合でも次はＩｎｄｅｘが２であるＡＦであることを示す。この値はＮｏ　ｏｆ　ＡＦｓフィールドの値と等しいので、Ｉｎｄｅｘが２はＡＦＣ　Ｅｇｒｅｓｓを指すことになる。

　ＡＦＣ　ＭａｎａｇｅｒはＡＦＣ　Ｕｓｅｒ－１からＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケットを受信すると、ＡＦ－１に関するＡＦ　Ｃｅｒｔｉｆｉｃａｔｅフィールドの値とＡＦ－３に関するＡＦ　Ｃｅｒｔｉｆｉｃａｔｅフィールドの値とから、ＡＦＣ　Ｕｓｅｒ－１がＡＦ－１とＡＦ－３を利用する権限を有していることを確認する。次にＡＦＣ　Ｍａｎａｇｅｒはこれから設置するＡＦＣ（ＡＦＣ－１）に識別子としてＡＦＣＩＤ－１を割り当てる。またＡＦＣ　ＭａｎａｇｅｒはＡＦＣ－１に関してＡＦＣ　Ｕｓｅｒ－１と共有する鍵情報であるＡＦＣＳＫｅｙ－ａｆｃ１を生成する。

　次にＡＦＣ　Ｍａｎａｇｅｒは図２５に示すテーブルを保持する。これは図２０に示したものに、Ｍａｎａｇｅｒ　ＡＦＣ　ＴａｂｌｅとＭａｎａｇｅｒ　ＡＦ　Ｌｉｓｔとが加わったものである。Ｍａｎａｇｅｒ　ＡＦＣ　Ｔａｂｌｅの各フィールドの値は以下の通りである。ｐｔｒ　ｔｏ　ｎｅｘｔ　ＡＦＣ　Ｔａｂｌｅフィールドには［ｎｕｌｌ］が設定される。ＡＦＣ　ＩＤフィールドにはＡＦＣＩＤ－１が設定される。Ｉｎｇｒｅｓｓ　ＩＰ　ＡｄｄｒｅｓｓフィールドにはＩＰ－ｉｎｇｒｅｓｓが設定される。ＡＦＣ　Ｓｅｓｓｉｏｎ　ＫｅｙフィールドにはＡＦＣＳＫｅｙ－ａｆｃ１が設定される。ｐｔｒ　ｔｏ　ＡＦ　ＬｉｓｔフィールドにはＭａｎａｇｅｒ　ＡＦ　Ｌｉｓｔへのポインタが設定される。Ｍａｎａｇｅｒ　ＡＦ　Ｌｉｓｔの各フィールドの値は以下の通りである。Ｎｏ　ｏｆ　ＡＦｓフィールの値は、ＡＦＣ　Ｓｅｔｕｐ　ＲｅｑｕｅｓｔパケットのＮｏ　ｏｆ　ＡＦｓフィールドの値である２が設定される。続いて、ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケットの２つのＡＦ　ＩＤフィールドの値であるＡＦＩＤ－１とＡＦＩＤ－３を以降の２つのフィールドに設定する。

　次にＡＦＣ　ＭａｎａｇｅｒはＡＦＣ　Ｉｎｇｒｅｓｓとの間にＴＬＳコネクションを確立する（ステップＳ１９３）。

　次にＡＦＣ　Ｍａｎａｇｅｒは、図２６に示すＡＦＣ　Ｉｎｓｔａｌｌ　ＲｅｑｕｅｓｔパケットをＡＦＣ　Ｉｎｇｒｅｓｓに送信する（ステップＳ１９４）。ＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｑｕｅｓｔパケットの各フィールドの値は以下の通りである。Ｔｙｐｅフィールドには「ＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｑｕｅｓｔ」が設定される。Ｕｓｅｒ　ＩＤフィールドにはＡＦＣ　Ｓｅｔｕｐ　ＲｅｑｕｅｓｔパケットのＵｓｅｒ　ＩＤフィールドの値であるＵＳＲＩＤ－１が設定される。ＡＦＣ　ＩＤフィールドにはＡＦＣＩＤ－１が設定される。ＡＦＣ　Ｓｅｓｓｉｏｎ　ＫｅｙフィールドにはＡＦＣＳＫｅｙ－ａｆｃ１が設定される。これに続く５個のフィールドは、ＡＦＣを適用するデータパケットを識別するためのマッチフィールドである。ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケットの対応するフィールドの値をこれらのフィールドに設定する。Ｉｎｇｒｅｓｓ　ＩＰ　ＡｄｄｒｅｓｓフィールドにはＩＰ－ｉｎｇｒｅｓｓが設定される。Ｅｇｒｅｓｓ　ＩＰ　ＡｄｄｒｅｓｓフィールドにはＩＰ－ｅｇｒｅｓｓが設定される。Ｎｏ　ｏｆ　ＡＦｓフィールドにはＡＦＣ　Ｓｅｔｕｐ　ＲｅｑｕｅｓｔパケットのＮｏ　ｏｆ　ＡＦｓフィールドの値である２が設定される。これに続く８個のフィールドはＡＦ－１に関する情報である。ＡＦ　ＩＤフィールドにはＡＦＩＤ－１が設定される。ＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙフィールドには、図２０に示したテーブルのうち、ＡＦ－１に関するＭａｎａｇｅｒ　ＡＦ　ＴａｂｌｅのＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙフィールドの値であるＡＦＳＫｅｙ－ａｆ１が設定される。Ｎｅｘｔ　Ｉｎｄｅｘ　Ｌｅｎｇｔｈフィールドの値とＮｅｘｔ　Ｉｎｄｅｘフィールドの値は、受信したＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケットの対応するフィールドの値が設定される。Ｎｏ　ｏｆ　ＡＦ　ＮｏｄｅｓフィールドはＡＦ－１を設置したＡＦ　Ｎｏｄｅの個数を表す。この例では１が設定される。ＡＦ　Ｎｏｄｅ　ＩＰ　Ａｄｄｒｅｓｓフィールドには、図２０に示したテーブルのうち、ＡＦ－１に関するＭａｎａｇｅｒ　ＡＦ　Ｎｏｄｅ　ＴａｂｌｅのＡＦ　Ｎｏｄｅ　ＩＰ　Ａｄｄｒｅｓｓフィールドの値であるＩＰ－ａｆｎ１が設定される。ＡＦＣ　Ｄａｅｍｏｎ　Ｄａｔａ　Ｐｏｒｔフィールドには、図２０に示したテーブルのうち、ＡＦ－１に関するＭａｎａｇｅｒ　ＡＦ　Ｎｏｄｅ　ＴａｂｌｅのＤａｅｍｏｎ　Ｄａｔａ　Ｐｏｒｔフィールドの値であるＤＰｔ－ａｆｃｄ１が設定される。ＡＦＣ　Ｄａｅｍｏｎ　Ｃｏｎｔｒｏｌ　Ｐｏｒｔフィールドには、図２０に示したテーブルのうち、ＡＦ－１に関するＭａｎａｇｅｒ　ＡＦ　Ｎｏｄｅ　ＴａｂｌｅのＤａｅｍｏｎ　Ｃｏｎｔｒｏｌ　Ｐｏｒｔフィールドの値であるＣＰｔ－ａｆｃｄ１が設定される。これに続く８個のフィールドはＡＦ－３に関する情報である。これらのフィールドにはＡＦ－１に関する情報と同様に設定される。

　ＡＦＣ　ＩｎｇｒｅｓｓはＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｑｕｅｓｔパケットを受信すると、図２８に示すＩｎｇｒｅｓｓ　ＡＦＣ　Ｔａｂｌｅ、Ｉｎｇｒｅｓｓ　ＡＦ　ＴａｂｌｅおよびＩｎｇｒｅｓｓ　ＡＦ　Ｎｏｄｅ　Ｔａｂｌｅを保持する。Ｉｎｇｒｅｓｓ　ＡＦＣ　ＴａｂｌｅはＡＦＣごとに割り当てられる。ｐｔｒ　ｔｏ　ｎｅｘｔ　ＡＦＣ　Ｔａｂｌｅフィールドには［ｎｕｌｌ］が設定される。ＡＦＣ　ＩＤフィールドからＡＦＣ　Ｓｅｓｓｉｏｎ　ＫｅｙフィールドにはＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｑｕｅｓｔパケットの対応するフィールドの値が設定される。Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒフィールドには初期値として０が設定される。ｐｔｒ　ｔｏ　ＡＦ　Ｔａｂｌｅフィールドには、ＡＦＣを構成する最初のＡＦに関するＩｎｇｒｅｓｓ　ＡＦ　Ｔａｂｌｅへのポインタが設定される。Ｉｎｇｒｅｓｓ　ＡＦ　ＴａｂｌｅはＡＦごとに割り当てられる。この例ではＡＦ－１とＡＦ－３にそれぞれＩｎｇｒｅｓｓ　ＡＦ　Ｔａｂｌｅが割り当てられる。Ｉｎｇｒｅｓｓ　ＡＦ　Ｔａｂｌｅの各フィールドの値は以下のとおりである。ＡＦ－１のＩｎｇｒｅｓｓ　ＡＦ　Ｔａｂｌｅのｐｔｒ　ｔｏ　ｎｅｘｔ　ＡＦ　ＴａｂｌｅフィールドにはＡＦ－３のＩｎｇｒｅｓｓ　ＡＦ　Ｔａｂｌｅを指すポインタが設定される。ＡＦ－３のＩｎｇｒｅｓｓ　ＡＦ　Ｔａｂｌｅのｐｔｒ　ｔｏ　ｎｅｘｔ　ＡＦ　Ｔａｂｌｅフィールドには［ｎｕｌｌ］が設定される。ＡＦ　ＩＤフィールドからＮｅｘｔ　ＩｎｄｅｘフィールドにはＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｑｕｅｓｔパケットの対応するフィールドの値が設定される。Ｉｎｇｒｅｓｓ　ＡＦ　Ｎｏｄｅ　ＴａｂｌｅはＡＦ　Ｎｏｄｅごとに割り当てられる。この例ではＡＦ　Ｎｏｄｅ－１とＡＦ　Ｎｏｄｅ－３にそれぞれＩｎｇｒｅｓｓ　ＡＦ　Ｎｏｄｅ　Ｔａｂｌｅが割り当てられる。各フィールドの値は以下の通りである。ｐｔｒ　ｔｏ　ｎｅｘｔ　ＡＦ　Ｎｏｄｅ　Ｔａｂｌｅフィールドには［ｎｕｌｌ］が設定される。ＡＦ　Ｎｏｄｅ　ＩＰ　ＡｄｄｒｅｓｓフィールドからＤａｅｍｏｎ　Ｃｏｎｔｒｏｌ　ＰｏｒｔフィールドにはＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｑｕｅｓｔパケットの対応するフィールドの値が設定される。Ｌｏａｄフィールドの値はこの時点では不定（［ｕｎｄｅｆ］）である。

　次にＡＦＣ　Ｉｎｇｒｅｓｓは、図２７に示すＡＦＣ　Ｉｎｓｔａｌｌ　ＲｅｓｐｏｎｓｅパケットをＡＦＣ　Ｍａｎａｇｅｒに送信する（ステップＳ１９５）。ＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｓｐｏｎｓｅパケットの各フィールドの値は以下の通りである。Ｔｙｐｅフィールドには「ＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｓｐｏｎｓｅ」が設定される。Ｓｔａｔｕｓフィールドには処理の成功を示す「ＯＫ」が設定される。Ｕｓｅｒ　ＩＤフィールドには、ＡＦＣ　Ｉｎｓｔａｌｌ　ＲｅｑｕｅｓｔパケットのＵｓｅｒ　ＩＤフィールドの値であるＵＳＲＩＤ－１が設定される。ＡＦＣ　ＩＤフィールドには、ＡＦＣ　Ｉｎｓｔａｌｌ　ＲｅｑｕｅｓｔパケットのＡＦＣ　ＩＤフィールドの値であるＡＦＣＩＤ－１が設定される。

　ＡＦＣ　Ｍａｎａｇｅｒは、ＡＦ　Ｉｎｓｔａｌｌ　Ｒｅｓｐｏｎｓｅパケットを受信すると、ＡＦＣ　Ｉｎｇｒｅｓｓとの間のＴＬＳコネクションを切断する（ステップＳ１９６）。

　次にＡＦＣ　Ｍａｎａｇｅｒは、図２４に示すＡＦＣ　Ｓｅｔｕｐ　ＲｅｓｐｏｎｓｅパケットをＡＦＣ　Ｕｓｅｒ－１に送信する（ステップＳ１９７）。ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｓｐｏｎｓｅパケットの各フィールドの値は以下の通りである。Ｔｙｐｅフィールドには「ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｓｐｏｎｓｅ」が設定される。Ｓｔａｔｕｓフィールドには処理の成功を示す「ＯＫ」が設定される。Ｕｓｅｒ　ＩＤフィールドには、ＡＦＣ　Ｓｅｔｕｐ　ＲｅｑｕｅｓｔパケットのＵｓｅｒ　ＩＤフィールドの値であるＵＳＲＩＤ－１が設定される。ＡＦＣ　ＩＤフィールドには、ＡＦＣ　Ｓｅｔｕｐ　ＲｅｑｕｅｓｔパケットのＡＦＣ　ＩＤフィールドの値であるＡＦＣＩＤ－１が設定される。ＡＦＣ　Ｓｅｓｓｉｏｎ　ＫｅｙフィールドにはＡＦＣＳＫｅｙ－ａｆｃ１が設定される。

　ＡＦＣ　Ｕｓｅｒ－１はＡＦＣ　ＭａｎａｇｅｒからＡＦＣ　Ｓｅｔｕｐ　Ｒｅｓｐｏｎｓｅパケットを受信すると、ＡＦＣ　Ｍａｎａｇｅｒとの間のＴＬＳコネクションを切断する（ステップＳ１９８）。

　（データパケットへのＡＦＣ－１の適用）
　次に、図２２においてＣＯＴＳ　ｄｅｖｉｃｅ上のアプリケーションが図３０に示す元データパケットをＳｅｒｖｅｒ上のアプリケーションに送信したとする。図２９は、ＣＯＴＳ　ｄｅｖｉｃｅ上のアプリケーションが図３０に示す元データパケットをＳｅｒｖｅｒ上のアプリケーションに送信する際の、パケットの流れを示す説明図である。ＣＯＴＳ　ｄｅｖｉｃｅのＩＰアドレスはＩＰ－ｃｏｔｓであり、ＣＯＴＳ　ｄｅｖｉｃｅ上のアプリケーションが使用するポート番号はＰｔ－ｃｏｔｓであるとする。ＳｅｒｖｅｒのＩＰアドレスはＩＰ－ｓｖｒであり、Ｓｅｒｖｅｒ上のアプリケーションが使用するポート番号はＰｔ－ｓｖｒであるとする。図３０において、ＩＰヘッダには始点ＩＰアドレスフィールドと終点ＩＰアドレスフィールドのみを示し、ＵＤＰヘッダには始点ポートフィールドと終点ポートフィールドのみを示す。

　まず、ＣＯＴＳ　ｄｅｖｉｃｅ上のアプリケーションが元データパケットを送信する（ステップＳ２０１）。

　ＡＦＣ　ＩｎｇｒｅｓｓはＣＯＴＳ　ｄｅｖｉｃｅ上のアプリケーションから送信された元データパケットを受信すると、図２８に示すＩｎｇｒｅｓｓ　ＡＦＣ　Ｔａｂｌｅのマッチフィールドの値と受信したデータパケットのフィールドを比較する。その結果、この元データパケットはＡＦＣ　ＩＤフィールドの値がＡＦＣＩＤ－１であるＩｎｇｒｅｓｓ　ＡＦＣ　Ｔａｂｌｅとマッチすることが分かるので、ＡＦＣ　Ｉｎｇｒｅｓｓは図３１に示すように元データパケットの先頭にＩＰヘッダ、ＵＤＰヘッダおよびＡＦＣヘッダを付加し、ＡＦＣ　データパケットを生成する。ＩＰヘッダでは、Ｓｒｃ　ＩＰフィールドにはＡＦＣ　ＩｎｇｒｅｓｓのＩＰアドレスであるＩＰ－ｉｎｇｒｅｓｓが設定される。Ｄｓｔ　ＩＰフィールドには、図２８に示す左下のＩｎｇｒｅｓｓ　ＡＦ　Ｎｏｄｅ　ＴａｂｌｅのＡＦ　Ｎｏｄｅ　ＩＰ　Ａｄｄｒｅｓｓフィールドの値であるＩＰ－ａｆｎ１が設定される。ＵＤＰヘッダでは、Ｓｒｃ　ＰｏｒｔフィールドにはＡＦＣ　Ｉｎｇｒｅｓｓのデータパケット用ポート番号であるＤＰｔ－ｉｎｇｒｅｓｓが設定される。Ｄｓｔ　Ｐｏｒｔフィールドには、図２８に示す左下のＩｎｇｒｅｓｓ　ＡＦ　Ｎｏｄｅ　ＴａｂｌｅのＤａｅｍｏｎ　Ｄａｔａ　Ｐｏｒｔフィールドの値であるＤＰｔ－ａｆｃｄ１が設定される。ＡＦＣヘッダの各フィールドの値は、図２８に示すテーブルを参照し、以下のように設定される。ＡＦＣ　ＩＤフィールドにはＩｎｇｒｅｓｓ　ＡＦＣ　ＴａｂｌｅのＡＦＣ　ＩＤフィールドの値であるＡＦＣＩＤ－１が設定される。Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒフィールドには、Ｉｎｇｒｅｓｓ　ＡＦＣ　ＴａｂｌｅのＳｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒフィールドの値が設定されるとともに、Ｉｎｇｒｅｓｓ　ＡＦＣ　ＴａｂｌｅのＳｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒフィールドの値がインクリメントされる。Ｉｎｇｒｅｓｓ　Ｏｕｔ　Ｔｉｍｅｓｔａｍｐフィールドには、ＡＦＣ　ＩｎｇｒｅｓｓがＡＦＣデータパケットを送信するときの時刻が設定される。Ｎｏ　ｏｆ　ＡＦｓフィールドにはＩｎｇｒｅｓｓ　ＡＦＣ　ＴａｂｌｅのＮｏ　ｏｆ　ＡＦｓフィールドの値である２が設定される。ＡＦ　Ｉｎｄｅｘフィールドには０が設定される。これに続く８個のフィールドはＡＦ－１に関するものである。ＡＦ　Ｎｏｄｅ　ＩＰ　ＡｄｄｒｅｓｓフィールドとＡＦＣ　Ｄａｅｍｏｎ　Ｄａｔａ　ＰｏｒｔフィールドにはＩｎｇｒｅｓｓ　ＡＦ　Ｎｏｄｅ　Ｔａｂｌｅの対応するフィールドの値が設定される。ＡＦ　ＩＤフィールド、Ｎｅｘｔ　Ｉｎｄｅｘ　ＬｅｎｇｔｈフィールドおよびＮｅｘｔ　ＩｎｄｅｘフィールドにはＩｎｇｒｅｓｓ　ＡＦ　Ｔａｂｌｅの対応するフィールドの値が設定される。ＡＦ　Ｃｅｒｔｉｆｉｃａｔｅフィールドには、Ｉｎｇｒｅｓｓ　ＡＦ　ＴａｂｌｅのＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙフィールドを用いて生成したＡＦ　Ｃｅｒｔｉｆｉｃａｔｅが設定される。Ｉｎ　ＴｉｍｅｓｔａｍｐフィールドとＯｕｔ　Ｔｉｍｅｓｔａｍｐフィールドの値は未定（［ｕｎｄｅｆ］）である。ＡＦ－２に関するフィールドの値も同様に設定される。上記のＡＦＣデータパケットはＩＰヘッダの終点アドレスとＵＤＰヘッダの終点ポート番号に従いＡＦＣ　Ｄａｅｍｏｎ－１に到達する（ステップＳ２０２）。

　ＡＦＣヘッダのＡＦ　Ｉｎｄｅｘフィールドの値が０であるので、ＡＦＣ　Ｄａｅｍｏｎ－１は、識別子がＡＦＩＤ－１であるＡＦ（ＡＦ－１）を、受信したＡＦＣデータパケットに含まれる元データパケットに適用することを認識する。ＡＦＣ　Ｄａｅｍｏｎ－１は、図１６に示すＡＦ　ＴａｂｌｅのＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙフィールドの値を用いてＡＦ　ｃｅｒｔｉｆｉｃａｔｅを計算し、この値とＡＦＣヘッダのＡＦ　Ｃｅｒｔｉｆｉｃａｔｅフィールドの値を比較する。両者が一致すれば、このデータパケットはＡＦＣを適用すべき正規のパケットであることが確認できる。ＡＦＣ　Ｄａｅｍｏｎ－１は、ＡＦＣを適用すべき正規のパケットであることを認識すると、ＡＦ－１を呼び出す。

　次にＡＦＣ　Ｄａｅｍｏｎ－１は、Ｄａｅｍｏｎ　ＡＦＣ　Ｔａｂｌｅを検索するが、この時点ではＡＦＣ　Ｄａｅｍｏｎ－１はＤａｅｍｏｎ　ＡＦＣ　Ｔａｂｌｅを保持していない。そこでＡＦＣ　Ｄａｅｍｏｎ－１は、図３２に示すＤａｅｍｏｎ　ＡＦＣ　Ｔａｂｌｅを作成する。各フィールドの値は以下の通りである。ｐｔｒ　ｔｏ　ｎｅｘｔ　ＡＦＣ　Ｔａｂｌｅフィールドには［ｎｕｌｌ］が設定される。ＡＦＣ　ＩＤフィールドにはＡＦＣ　ヘッダのＡＦＣ　ＩＤフィールドの値であるＡＦＣＩＤ－１が設定される。Ｓｅｑｕｅｎｃｅ　ＮｕｍｂｅｒフィールドにはＡＦＣヘッダのＳｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒフィールドの値であるＳｅｑ－ａｆｃ１が設定される。もし既にＡＦＣヘッダのＡＦＣ　ＩＤフィールドの値が示すＡＦＣに関するＤａｅｍｏｎ　ＡＦＣ　Ｔａｂｌｅが存在し、ＡＦＣヘッダのＳｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒフィールドの値がＤａｅｍｏｎ　ＡＦＣ　ＴａｂｌｅのＳｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒフィールドの値と等しいか小さい場合、受信したＡＦＣ　データパケットはｒｅｐｌａｙ　ａｔｔａｃｋによるものであると判断し、ＡＦＣ　Ｄａｅｍｏｎ－１は受信したＡＦＣデータパケットを破棄する。

　次にＡＦＣ　Ｄａｅｍｏｎ－１は図１６に示すＤａｅｍｏｎ　ＡＦ　ＴａｂｌｅのＡＦ　Ｉｎ　Ｐｏｒｔフィールドが示すポートから、受信した元データパケットを、呼び出したＡＦ－１に入力する（ステップＳ２０３）。次にＡＦＣ　Ｄａｅｍｏｎ－１はＤａｅｍｏｎ　ＡＦ　ＴａｂｌｅのＡＦ　Ｏｕｔ　Ｐｏｒｔフィールドが示すポートからＡＦ－１が処理した元データパケットを受け取る。ＡＦＣヘッダのＮｅｘｔ　Ｉｎｄｅｘフィールドの値は、ＡＦ－１の実行結果によらず次のＡＦのＩｎｄｅｘは１（ＡＦ－３）と指定しているので、ＡＦＣ　Ｄａｅｍｏｎ－１は次のＡＦがＡＦ－３であることを知る。ＡＦＣ　Ｄａｅｍｏｎ－１はＡＦＣヘッダのＡＦ－３に関するフィールドを参照し、ＡＦＣヘッダのＡＦ－３に関するＡＦ　Ｎｏｄｅ　ＩＰ　Ａｄｄｒｅｓｓフィールドの値であるＩＰ－ａｆｎ３をＩＰヘッダのＤｓｔ　ＩＰフィールドに設定する。またＡＦＣ　Ｄａｅｍｏｎ－１はＡＦＣヘッダのＡＦ－３に関するＡＦＣ　Ｄａｅｍｏｎ　Ｄａｔａ　Ｐｏｒｔフィールドの値であるＤＰｔ－ａｆｃｄ３をＵＤＰヘッダのＤｓｔ　Ｐｏｒｔフィールドに設定する。さらにＡＦＣ　Ｄａｅｍｏｎ－１はＡＦ　Ｉｎｄｅｘフィールドの値をインクリメントする。結果としてＡＦＣデータパケットのヘッダは図３３に示すものになる。

　次にＡＦＣ　Ｄａｅｍｏｎ－１はこのＡＦＣデータパケットを送信する（ステップＳ２０４）。その際、ＡＦＣ　Ｄａｅｍｏｎ－１はＡＦＣヘッダのＡＦ－１に関するＩｎ　ＴｉｍｅｓｔａｍｐフィールドにＡＦＣデータパケットを受信したときの時刻を設定し、Ｏｕｔ　ＴｉｍｅｓｔａｍｐフィールドにＡＦＣデータパケットを送信するときの時刻を設定する。このＡＦＣデータパケットはＩＰヘッダの終点アドレスとＵＤＰヘッダの終点ポート番号に従い、ＡＦＣ　Ｄａｅｍｏｎ－３に到達する。

　ＡＦＣデータパケットのＡＦＣヘッダのＡＦ　Ｉｎｄｅｘフィールドの値が１であるので、ＡＦＣ　Ｄａｅｍｏｎ－３は識別子がＡＦＩＤ－３であるＡＦ（ＡＦ－３）を、受信したＡＦＣデータパケットに含まれる元データパケットに適用することを認識する。ＡＦＣ　Ｄａｅｍｏｎ－３はＡＦＣ　Ｄａｅｍｏｎ－１と同様にＡＦＣデータパケットが正規のものであり、ｒｅｐｌａｙ　ａｔｔａｃｋのものでないことを確認し、その後ＡＦ－３を呼び出し、元データパケットにＡＦ－３を適用する（ステップＳ２０５）。ＡＦＣヘッダのＡＦ－３に関するＮｅｘｔ　Ｉｎｄｅｘフィールドの値はＡＦ－３の実行結果によらず次のＡＦのＩｎｄｅｘは２であると指定している。この値はＡＦＣヘッダのＮｏ　ｏｆ　ＡＦｓフィールドの値と等しいので、次のノードはＡＦＣ　Ｅｇｒｅｓｓであることが分かる。そこでＡＦＣ　Ｄａｅｍｏｎ－３はＡＦＣヘッダのＡＦＣ　Ｅｇｒｅｓｓ　ＩＰ　Ａｄｄｒｅｓｓフィールドの値をＩＰヘッダのＤｓｔ　ＩＰフィールドに設定し、ＡＦＣ　Ｅｇｒｅｓｓのデータパケット用のｗｅｌｌ－ｋｎｏｗｎポートであるＤＰｔ－ｅｇｒｅｓｓをＵＤＰヘッダのＤｓｔ　Ｐｏｒｔフィールドに設定する。さらにＡＦＣ　Ｄａｅｍｏｎ－３はＡＦ　Ｉｎｄｅｘフィールドの値をインクリメントする。結果としてＡＦＣデータパケットのヘッダは図３４に示すものになる。

　ＡＦＣ　Ｄａｅｍｏｎ－３はこのＡＦＣデータパケットを送信する（ステップＳ２０６）。その際、ＡＦＣ　Ｄａｅｍｏｎ－３はＡＦＣヘッダのＡＦ－３に関するＩｎ　ＴｉｍｅｓｔａｍｐフィールドにＡＦＣデータパケットを受信したときの時刻を設定し、Ｏｕｔ　ＴｉｍｅｓｔａｍｐフィールドにＡＦＣデータパケットを送信するときの時刻を設定する。このＡＦＣデータパケットはＩＰヘッダの終点アドレスとＵＤＰヘッダの終点ポート番号に従い、ＡＦＣ　Ｅｇｒｅｓｓに到達する。

　ＡＦＣ　Ｅｇｒｅｓｓは受信したＡＦＣデータパケットから図３０に示す元データパケットを取り出し、アプリケーションに転送する（ステップＳ２０７）。元データパケットはＩＰヘッダの終点アドレスとＵＤＰヘッダの終点ポート番号に従い、Ｓｅｒｖｅｒ上のアプリケーションに到達する。

　（分岐と合流のあるＡＦＣの設定：ＡＦＣ－２）
　次に、ＡＦ－１での実行結果によってＡＦ－１から直接ＡＦ－３に進むというＡＦＣ　ｐａｔｈとＡＦ－１からＡＦ－２を経てＡＦ－３に進むというＡＦＣ　ｐａｔｈに分岐するＡＦＣ（ＡＦＣ－２と呼ぶ）を設定する場合を考える。

　図３５は、ＡＦＣ－２のｐａｔｈを示す説明図である。ＡＦＣ　Ｕｓｅｒ－１は図２１に示す手順と同様に図３６に示すＡＦＣ　Ｓｅｔｕｐ　ＲｅｑｕｅｓｔパケットをＡＦＣ　Ｍａｎａｇｅｒに送信する。ＡＦＣ　ＭａｎａｇｅｒはＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケットを受信すると、図３８に示すＡＦＣ　Ｉｎｓｔａｌｌ　ＲｅｑｕｅｓｔパケットをＡＦＣ　Ｉｎｇｒｅｓｓ　に送信する。ＡＦＣ　ＩｎｇｒｅｓｓはＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｑｕｅｓｔパケットを受信すると、図３９に示すＡＦＣ　Ｉｎｓｔａｌｌ　ＲｅｓｐｏｎｓｅパケットをＡＦＣ　Ｍａｎａｇｅｒに送信する。

　ＡＦＣ　ＭａｎａｇｅｒはＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｓｐｏｎｓｅパケットを受信すると、図３７に示すＡＦＣ　Ｓｅｔｕｐ　ＲｅｓｐｏｎｓｅパケットをＡＦＣ　Ｕｓｅｒ－１に送信する。

　以上の処理の結果、ＡＦＣ　Ｍａｎａｇｅｒは図４０に示すテーブルを保持する。図５　と比較すると、図４０にはＡＦＣ－２に関するＭａｎａｇｅｒ　ＡＦＣ　Ｔａｂｌｅとａｎａｇｅｒ　ＡＦ　ＬＩｓｔ　が追加されている。また、ＡＦＣ　Ｉｎｇｒｅｓｓは図４１に示すテーブルを保持する。図２８と比較すると、図４１にはＡＦＣ－２に関するＩｎｇｒｅｓｓ　ＡＦＣ　ＴａｂｌｅとＡＦＣ－２を構成するＡＦ（ＡＦ－１、ＡＦ－２、ＡＦ－３）に関するＩｎｇｒｅｓｓ　ＡＦ　ＴａｂｌｅおよびＩｎｇｒｅｓｓ　ＡＦ　Ｎｏｄｅ　Ｔａｂｌｅが追加されている。

　（分岐と合流のあるＡＦＣでのデータ転送）
　次に、図３５で示した分岐と合流のあるＡＦＣにおいて、ＣＯＴＳ　ｄｅｖｉｃｅ上のアプリケーションが図４２に示す元データパケットをＳｅｒｖｅｒ上のアプリケーションに送信したとする。

　ＣＯＴＳ　ｄｅｖｉｃｅのＩＰアドレスはＩＰ－ｃｏｔｓであり、ＣＯＴＳ　ｄｅｖｉｃｅ上のアプリケーションが使用するポート番号はＰｔ－ｃｏｔｓであるとする。ＳｅｒｖｅｒのＩＰアドレスはＩＰ－ｓｖｒ２であり、Ｓｅｒｖｅｒ上のアプリケーションが使用するポート番号はＰｔ－ｓｖｒ２であるとする。

　図４２において、ＩＰヘッダには始点ＩＰアドレスフィールドと終点ＩＰアドレスフィールドのみを示し、ＵＤＰヘッダには始点ポートフィールドと終点ポートフィールドのみを示す。

　この元データパケットがＡＦＣ　Ｉｎｇｒｅｓｓに到達すると、ＡＦＣ　Ｉｎｇｒｅｓｓは図４１に示すＩｎｇｒｅｓｓ　ＡＦＣ　Ｔａｂｌｅのマッチフィールドの値と受信した元データパケットのフィールドを比較する。その結果、この元データパケットはＡＦＣ　ＩＤフィールドの値がＡＦＣＩＤ－２であるＩｎｇｒｅｓｓ　ＡＦＣ　Ｔａｂｌｅとマッチすることが分かるので、ＡＦＣ　Ｉｎｇｒｅｓｓは図４３に示すように元データパケットの先頭にＩＰヘッダ、ＵＤＰヘッダおよびＡＦＣヘッダを付加する。これらのヘッダの各フィールドの値は、上述の（データパケットへのＡＦＣ－１の適用）で述べた手順と同様にして設定する。上記のデータパケットはＩＰヘッダの終点アドレスとＵＤＰヘッダの終点ポート番号に従い、ＡＦＣ　Ｄａｅｍｏｎ－１に到達する。上述の（データパケットへのＡＦＣ－１の適用）で述べた手順と同様にＡＦＣ　Ｄａｅｍｏｎ－１は元データパケットをＡＦ－１に入力し、出力データを得る。出力結果が条件式Ｃｏｎｄ－１を満足する場合は、次のＡＦのＩｎｄｅｘは２（ＡＦ－３）となる。その結果、上述の（データパケットへのＡＦＣ－１の適用）で述べた手順と同様にして図４４に示したヘッダを生成する。

　次にＡＦＣ　Ｄａｅｍｏｎ－１はこのパケットを送信する。このパケットはＩＰヘッダの終点アドレスとＵＤＰヘッダの終点ポート番号に従い、ＡＦＣ　Ｄａｅｍｏｎ－３に到達する。ＡＦＣ　Ｄａｅｍｏｎ－３は元データパケットにＡＦ－３を適用する。一方、ＡＦ－１の出力結果が条件式Ｃｏｎｄ－１を満足しない場合は次のＡＦのＩｎｄｅｘは１（ＡＦ－２）となる。以降、ＡＦＣ　Ｄａｅｍｏｎ－２は元データパケットにＡＦ－２を適用し、続いてＡＦＣＤａｅｍｏｎ－３は元データパケットにＡＦ－３を適用する。

　いずれの場合もＡＦＣデータパケットはＡＦＣ　Ｅｇｒｅｓｓに到達し、最終的に元データパケットはＳｅｒｖｅｒ上のアプリケーションに到達する。

　（ＡＦＣの削除）
　上記のようにＡＦＣ　Ｕｓｅｒ－１がＡＦＣ－１とＡＦＣ－２を設定後、ＡＦＣ－２を削除する手順を説明する。図４５はＡＦＣの削除について示す説明図である。

　まず、ＡＦＣ　Ｕｓｅｒ－１はＡＦＣ　Ｍａｎａｇｅｒとの間にＴＬＳセッションを確立する（ステップＳ２１１）。

　続いてＡＦＣ　Ｕｓｅｒ－１は図４６に示すＡＦＣ　Ｄｅｌｅｔｅ　ＲｅｑｕｅｓｔパケットをＡＦＣ　Ｍａｎａｇｅｒに送信する（ステップＳ２１２）。ＡＦＣ　Ｄｅｌｅｔｅ　Ｒｅｑｕｅｓｔメッセージの各フィールドの値は以下のとおりである。Ｔｙｐｅフィールドには「ＡＦＣ　Ｄｅｌｅｔｅ　Ｒｅｑｕｅｓｔ」を設定する。Ｕｓｅｒ　ＩＤフィールドにはＵＳＲＩＤ－１を設定する。ＡＦＣ　ＩＤフィールドにはＡＦＣＩＤ－２を設定する。ＡＦＣ　Ｃｅｒｔｉｆｉｃａｔｅフィールドには、図３７に示すＡＦＣ　Ｓｅｔｕｐ　Ｒｅｓｐｏｎｓｅパケットの受信によって得られたＡＦＣＳＫｅｙ－ａｆｃ２を用いて生成した証明書情報であるＡＦＣＣｅｒｔ－ａｆｃ２を設定する。

　ＡＦＣ　ＭａｎａｇｅｒはＡＦＣ　Ｄｅｌｅｔｅ　Ｒｅｑｕｅｓｔパケットを受信すると、図４０に示すＭａｎａｇｅｒ　ＡＦＣ　ＴａｂｌｅからＡＦＣ　ＩｎｇｒｅｓｓのＩＰアドレスを知り、ＡＦＣ　Ｉｎｇｒｅｓｓとの間にＴＬＳコネクションを確立する（ステップＳ２１３）。

　次にＡＦＣ　Ｍａｎａｇｅｒは、受信したＡＦＣ　Ｄｅｌｅｔｅ　ＲｅｑｕｅｓｔパケットをＡＦＣ　Ｉｎｇｒｅｓｓに転送する（ステップＳ２１４）。

　ＡＦＣ　ＩｎｇｒｅｓｓはＡＦＣ　Ｄｅｌｅｔｅ　Ｒｅｑｕｅｓｔパケットを受信すると、図４１に示すテーブルからＡＦＣ－２に関するテーブルを削除する。結果としてＡＦＣ　Ｉｎｇｒｅｓｓは図２８に示すテーブルを保持する。

　次にＡＦＣ　Ｉｎｇｒｅｓｓは、図４７に示すＡＦＣ　Ｄｅｌｅｔｅ　ＲｅｓｐｏｎｓｅパケットをＡＦＣ　Ｍａｎａｇｅｒに送信する（ステップＳ２１５）。ＡＦＣ　Ｄｅｌｅｔｅ　Ｒｅｓｐｏｎｓｅパケットの各フィールドの値は以下の通りである。Ｔｙｐｅフィールドには「ＡＦＣ　Ｄｅｌｅｔｅ　Ｒｅｓｐｏｎｓｅ」が設定される。Ｓｔａｔｕｓフィールドには処理の成功を示す「ＯＫ」が設定される。Ｕｓｅｒ　ＩＤフィールドには、ＡＦＣ　Ｄｅｌｅｔｅ　ＲｅｑｕｅｓｔパケットのＵｓｅｒ　ＩＤフィールドの値であるＵＳＲＩＤ－１が設定される。ＡＦＣ　ＩＤフィールドには、ＡＦＣ　Ｄｅｌｅｔｅ　ＲｅｑｕｅｓｔパケットのＡＦＣ　ＩＤフィールドの値であるＡＦＣＩＤ－２が設定される。

　ＡＦＣ　ＭａｎａｇｅｒはＡＦＣ　Ｄｅｌｅｔｅ　Ｒｅｓｐｏｎｓｅパケットを受信すると、図４０に示すテーブルからＡＦＣ－２に関するテーブルを削除する。結果としてＡＦＣ　Ｍａｎａｇｅｒは図２５に示すテーブルを保持する。

　次にＡＦＣ　ＭａｎａｇｅｒはＡＦＣ　Ｉｎｇｒｅｓｓとの間のＴＬＳコネクションを切断する（ステップＳ２１６）。

　次にＡＦＣ　Ｍａｎａｇｅｒは受信したＡＦＣ　Ｄｅｌｅｔｅ　ＲｅｓｐｏｎｓｅパケットをＡＦＣ　Ｕｓｅｒ－１に転送する（ステップＳ２１７）。

　ＡＦＣ　Ｕｓｅｒ－１はＡＦＣ　Ｄｅｌｅｔｅ　Ｒｅｓｐｏｎｓｅパケットを受信すると、ＡＦＣ　Ｍａｎａｇｅｒとの間のＴＬＳコネクションを切断する（ステップＳ２１８）。

　（ＡＦの削除）
　続いて、上述のようにＡＦＣ　Ｕｓｅｒ－１がＡＦＣ－２を削除したあと、ＡＦＣ　Ｕｓｅｒ－１がＡＦ－２を削除する手順を説明する。図４８は、ＡＦの削除について示す説明図である。

　まずＡＦＣ　Ｕｓｅｒ－１はＡＦＣ　Ｍａｎａｇｅｒとの間にＴＬＳコネクションを確立する（ステップＳ２２１）。

　続いて、ＡＦＣ　Ｕｓｅｒ－１は図４９に示すＡＦ　Ｄｅｌｅｔｅ　ＲｅｑｕｅｓｔパケットをＡＦＣ　Ｍａｎａｇｅｒに送信する（ステップＳ２２２）。ＡＦ　Ｄｅｌｅｔｅ　Ｒｅｑｕｅｓｔパケットの各フィールドの値は以下のとおりである。Ｔｙｐｅフィールドには「ＡＦ　Ｄｅｌｅｔｅ　Ｒｅｑｕｅｓｔ」が設定される。Ｕｓｅｒ　ＩＤフィールドにはＵＳＲＩＤ－１が設定される。ＡＦ　ＩＤフィールドにはＡＦＩＤ－２が設定される。ＡＦ　Ｃｅｒｔｉｆｉｃａｔｅフィールドには、ＡＦ－２の設定の際に受信したＡＦ　Ｓｅｔｕｐ　Ｒｅｓｐｏｎｓｅパケットにより得られたＡＦＳＫｅｙ－ａｆ２を用いて生成した証明書情報であるＡＦＣｅｒｔ－ａｆ２が設定される。

　ＡＦＣ　ＭａｎａｇｅｒはＡＦ　Ｄｅｌｅｔｅ　Ｒｅｑｕｅｓｔパケットを受信すると、図２５に示すＭａｎａｇｅｒ　ＡＦ　ＬｉｓｔにＡＦＩＤ－２が含まれていないことを確認する。次にＡＦＣ　Ｍａｎａｇｅｒは、Ｍａｎａｇｅｒ　ＡＦ　Ｎｏｄｅ　ＴａｂｌｅからＡＦＣ　Ｄａｅｍｏｎ－２のＩＰアドレスを知り、ＡＦＣ　Ｄａｅｍｏｎ－２との間にＴＬＳコネクションを確立する（ステップＳ２２３）。

　次にＡＦＣ　Ｍａｎａｇｅｒは受信したＡＦ　Ｄｅｌｅｔｅ　ＲｅｑｕｅｓｔパケットをＡＦＣ　Ｄａｅｍｏｎ－２に転送する（ステップＳ２２４）。

　ＡＦＣ　Ｄａｅｍｏｎ－２はＡＦ　Ｄｅｌｅｔｅパケットを受信すると、ＡＦ－２の実行を停止する（ステップＳ２２５）。

　次にＡＦＣ　Ｄａｅｍｏｎ－２は図５０に示すＡＦ　Ｄｅｌｅｔｅ　ＲｅｓｐｏｎｓｅパケットをＡＦＣ　Ｍａｎａｇｅｒに送信する（ステップＳ２２６）。ＡＦ　Ｄｅｌｅｔｅ　Ｒｅｓｐｏｎｓｅパケットの各フィールドの値は以下の通りである。Ｔｙｐｅフィールドには「ＡＦ　Ｄｅｌｅｔｅ　Ｒｅｓｐｏｎｓｅ」が設定される。Ｓｔａｔｕｓフィールドには処理の成功を示す「ＯＫ」が設定される。Ｕｓｅｒ　ＩＤフィールドにはＡＦ　Ｄｅｌｅｔｅ　ＲｅｑｕｅｓｔのＵｓｅｒ　ＩＤフィールドの値であるＵＳＲＩＤ－１が設定される。ＡＦ　ＩＤフィールドにはＡＦ　Ｄｅｌｅｔｅ　ＲｅｑｕｅｓｔのＡＦ　ＩＤフィールドの値であるＡＦＩＤ－２が設定される。

　ＡＦＣ　ＭａｎａｇｅｒはＡＦ　Ｄｅｌｅｔｅ　Ｒｅｓｐｏｎｓｅパケットを受信すると、ＡＦＣ　Ｄａｅｍｏｎ－２との間のＴＬＳコネクションを切断する（ステップＳ２２７）。この結果、ＡＦＣ　Ｄａｅｍｏｎ－２上で動作中のＡＦは存在しなくなるので、ＡＦＣ　Ｄａｅｍｏｎ－２も実行を終了する。一方、ＡＦＣ　Ｍａｎａｇｅｒは図２５に示すテーブルからＡＦ－２に関するテーブルを削除する。その結果、ＡＦＣ　Ｍａｎａｇｅｒは図５１に示すテーブルを保持する。

　次にＡＦＣ　Ｍａｎａｇｅｒは受信したＡＦ　Ｄｅｌｅｔｅ　ＲｅｓｐｏｎｓｅパケットをＡＦＣ　Ｕｓｅｒ－１に転送する（ステップＳ２２８）。

　ＡＦＣ　Ｕｓｅｒ－１はＡＦＣ　Ｄｅｌｅｔｅ　Ｒｅｓｐｏｎｓｅパケットを受信すると、ＡＦＣ　Ｍａｎａｇｅｒとの間のＴＬＳコネクションを切断する（ステップＳ２２９）。

　（同一のＡＦを複数のＡＦ　Ｎｏｄｅで起動）
　その後、ＡＦＣ　Ｕｓｅｒ－１はＡＦＣ－１、ＡＦ－２およびＡＦ－１を削除したとする。次にＡＦＣ　Ｕｓｅｒ－１は図９と同様の手順でＡＦ－４をＡＦ　Ｎｏｄｅ－４－１とＡＦ　Ｎｏｄｅ－４－２に設置したとする。その結果、ＡＦＣ　Ｕｓｅｒ－１はＡＦ－４の識別子としてＡＦＩＤ－４が割り当てられたことを知り、ＡＦ　Ｓｅｓｓｉｏｎ　ＫｅｙとしてＡＦＳＫｅｙ－ａｆ４を得る。

　さらにＡＦＣ　Ｕｓｅｒ－１はＡＦ－５をＡＦ　Ｎｏｄｅ－５－１とＡＦ　Ｎｏｄｅ－５－２に設置したとする。その結果、ＡＦＣ　Ｕｓｅｒ－１はＡＦ－５の識別子としてＡＦＩＤ－５が割り当てられたことを知り、ＡＦ　Ｓｅｓｓｉｏｎ　ＫｅｙとしてＡＦＳＫｅｙ－ａｆ５を得る。またＡＦ　Ｎｏｄｅ－４－１、ＡＦ　Ｎｏｄｅ－４－２、ＡＦ　Ｎｏｄｅ－５－１、およびＡＦ　Ｎｏｄｅ－５－２は図５３～図５６に示すテーブルをそれぞれ保持し、ＡＦＣ　Ｍａｎａｇｅｒは図５７に示すテーブルを保持する。図５７に示すように、２つのＭａｎａｇｅｒ　ＡＦ　Ｔａｂｌｅがそれぞれ２つのＭａｎａｇｅｒ　ＡＦ　Ｎｏｄｅ　Ｔａｂｌｅからなるリストを持つことが分かる。この４つのＭａｎａｇｅｒ　ＡＦ　Ｎｏｄｅ　Ｔａｂｌｅは、それぞれＡＦ　Ｎｏｄｅ－４－１、ＡＦ　Ｎｏｄｅ－４－２、ＡＦ　Ｎｏｄｅ－５－１およびＡＦ　Ｎｏｄｅ－５－２に対応する。

　（ＡＦＣ－３の設定）
　次に、ＡＦＣ　Ｕｓｅｒ－１は図２１と同様の手順でＡＦ－４とＡＦ－５から構成されるＡＦＣ（ＡＦＣ－３と呼ぶ）を設定するものとする。図５２は、ＡＦＣ－３のｐａｔｈを示す説明図である。また図５８は、ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケットを示す説明図である。ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケットの各フィールドの値は以下の通りである。Ｔｙｐｅフィールドには「ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔ」が設定される。Ｕｓｅｒ　ＩＤフィールドにはＵＳＲＩＤ－１が設定される。これに続く５つのフィールドは、ＡＦＣを適用するデータパケットを識別するためのマッチフィールドである。Ｓｏｕｒｃｅ　ＩＰ　Ａｄｄｒｅｓｓフィールドの値は［ａｎｙ］である。Ｄｅｓｔｉｎａｔｉｏｎ　ＩＰ　Ａｄｄｒｅｓｓフィールドの値はＩＰ－ｓｖｒ３である。Ｓｏｕｒｃｅ　Ｐｏｒｔフィールドの値は［ａｎｙ］である。Ｄｅｓｔｉｎａｔｉｏｎ　Ｐｏｒｔフィールドの値はＰｔ－ｓｖｒ３である。Ｐｒｏｔｏｃｏｌフィールドの値はＵＤＰである。Ｉｎｇｒｅｓｓ　ＩＰ　ＡｄｄｒｅｓｓフィールドにはＡＦＣ　ＩｎｇｒｅｓｓのＩＰアドレスであるＩＰ－ｉｎｇｒｅｓｓが設定される。Ｅｇｒｅｓｓ　ＩＰ　ＡｄｄｒｅｓｓフィールドにはＡＦＣ　ＥｇｒｅｓｓのＩＰアドレスであるＩＰ－ｅｇｒｅｓｓが設定される。次に、Ｎｏ　ｏｆ　ＡＦｓフィールドにはＡＦＣを構成するＡＦの個数である２が設定される。これに続く４つのフィールドはＡＦ－４に関する情報を含む。ＡＦ　ＩＤフィールドにはＡＦＩＤ－４が設定される。ＡＦ　ＣｅｒｔｉｆｉｃａｔｅフィールドにはＡＦＳＫｅｙ－ａｆ４を用いて生成した証明書情報であるＡＦＣｅｒｔ－ａｆ４が設定される。Ｎｅｘｔ　Ｉｎｄｅｘ　ＬｅｎｇｔｈフィールドにはＮｅｘｔ　Ｉｎｄｅｘフィールドの長さを示すＣｏｎｄＬｅｎ－４が設定される。Ｎｅｘｔ　Ｉｎｄｅｘフィールドには、ＡＦ－４の実行結果がどのような場合でも次はＩｎｄｅｘが１であるＡＦ（ＡＦ－５）であることが示される。これに続く４つのフィールドはＡＦ－５に関する情報を含む。ＡＦ　ＩＤフィールドにはＡＦＩＤ－５が設定される。ＡＦ　ＣｅｒｔｉｆｉｃａｔｅフィールドにはＡＦＳＫｅｙ－ａｆ５を用いて生成した証明書情報であるＡＦＣｅｒｔ－ａｆ５が設定される。Ｎｅｘｔ　Ｉｎｄｅｘ　ＬｅｎｇｔｈフィールドにはＮｅｘｔ　Ｉｎｄｅｘフィールドの長さを示すＣｏｎｄＬｅｎ－５が設定される。Ｎｅｘｔ　Ｉｎｄｅｘフィールドには、ＡＦ－５の実行結果がどのような場合でも次はＩｎｄｅｘが２であるＡＦ（ＡＦ　Ｅｇｒｅｓｓ）であることが示される。ＡＦＣ　ＭａｎａｇｅｒはＡＦＣ－３に識別子としてＡＦＣＩＤ－３を割り当てる。

　図６０は、ＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｑｕｅｓｔパケットを示す説明図である。ＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｑｕｅｓｔパケットの各フィールドの値は以下の通りである。Ｔｙｐｅフィールドには「ＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｑｕｅｓｔ」が設定される。Ｕｓｅｒ　ＩＤフィールドからＮｏ　ｏｆ　ＡＦｓフィールドにはＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケットの対応するフィールドの値が設定される。これに続く１１個のフィールドはＡＦ－４に関するものである。ＡＦ　ＩＤ　フィールドには、ＡＦＣ　Ｓｅｔｕｐ　ＲｅｑｕｅｓｔパケットのＡＦ　ＩＤフィールドの値であるＡＦＩＤ－４を設定する。ＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙフィールドには、図５７に示すＭａｎａｇｅｒ　ＡＦ　ＴａｂｌｅのＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙフィールドの値であるＡＦＳＫｅｙ－ａｆ４が設定される。Ｎｅｘｔ　Ｉｎｄｅｘ　ＬｅｎｇｔｈフィールドとＮｅｘｔ　Ｉｎｄｅｘフィールドには、ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケットの対応するフィールドの値が設定される。図５７に示すＭａｎａｇｅｒ　ＡＦ　Ｔａｂｌｅは２つのＭａｎａｇｅｒ　ＡＦ　Ｎｏｄｅ　Ｔａｂｌｅを持つので、Ｎｏ　ｏｆ　ＡＦ　Ｎｏｄｅｓフィールドには２が設定される。これに続く３つのフィールドはＡＦ　Ｎｏｄｅ－４－１のためのものである。ＡＦ　Ｎｏｄｅ　ＩＰ　Ａｄｄｒｅｓｓフィールド、ＡＦＣ　Ｄａｅｍｏｎ　Ｄａｔａ　ＰｏｒｔフィールドおよびＡＦＣ　Ｄａｅｍｏｎ　Ｃｏｎｔｒｏｌ　Ｐｏｒｔフィールドには、図５７に示すＭａｎａｇｅｒ　ＡＦ　Ｎｏｄｅ　Ｔａｂｌｅの対応するフィールドの値が設定される。これに続く３つのフィールドはＡＦ　Ｎｏｄｅ－４－２のためのものである。各フィールドはＡＦ　Ｎｏｄｅ－４－１のためのフィールドと同様に設定される。これに続く１１個のフィールドはＡＦ－５に関するものである。これらのフィールドは、ＡＦ－４のためのフィールドと同様に設定される。図６１は、上記のＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｑｕｅｓｔパケットに対応するＡＦＣ　Ｉｎｓｔａｌｌ　Ｒｅｓｐｏｎｓｅパケットを示す説明図である。また図５９は、上記のＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケットに対応するＡＦＣ　Ｓｅｔｕｐ　Ｒｅｓｐｏｎｓｅパケットを示す説明図である。

　以上の処理の結果、ＡＦＣ　Ｍａｎａｇｅｒは図６２に示すテーブルを保持する。図６２に示すように、２つのＭａｎａｇｅｒ　ＡＦ　Ｔａｂｌｅが、それぞれ２つのＭａｎａｇｅｒ　ＡＦ　Ｎｏｄｅ　Ｔａｂｌｅからなるリストを持つ。一方、ＡＦＣ　Ｉｎｇｒｅｓｓは図６３に示すテーブルを保持する。図６３に示すように、２つのＩｎｇｒｅｓｓ　ＡＦ　Ｔａｂｌｅがそれぞれ２つのＩｎｇｒｅｓｓ　ＡＦ　Ｎｏｄｅ　Ｔａｂｌｅからなるリストを持つ。

　（ＡＦ　Ｎｏｄｅの負荷のモニタリング）
　上記のようにＡＦ　Ｎｏｄｅが設定されることで、ＡＦＣ　Ｉｎｇｒｅｓｓは、ＡＦ－４が動作するＡＦ　Ｎｏｄｅが２つあり、ＡＦ－５が動作するＡＦ　Ｎｏｄｅも２つあることを認識するので、それぞれのＡＦ　Ｎｏｄｅの負荷をモニタリングする。図６４は、ＡＦＣ　ＩｎｇｒｅｓｓによるＡＦ　Ｎｏｄｅの負荷のモニタリングを示す説明図である。

　ＡＦＣ　Ｉｎｇｒｅｓｓは、図６５に示すＬｏａｄ　Ｍｏｎｉｔｏｒｉｎｇ　ＲｅｑｅｕｓｔパケットをＡＦ　Ｎｏｄｅ－４－１に送信する（ステップＳ２３１）。Ｌｏａｄ　Ｍｏｎｉｔｏｒｉｎｇ　ＲｅｑｕｅｓｔパケットのＴｙｐｅフィールドには「Ｌｏａｄ　Ｍｏｎｉｔｏｒｉｎｇ　Ｒｅｑｕｅｓｔ」が設定される。

　ＡＦＣ　Ｄａｅｍｏｎ－４－１はＬｏａｄ　Ｍｏｎｉｔｏｒｉｎｇ　Ｒｅｑｕｅｓｔパケットを受信すると、図６６に示すＬｏａｄ　Ｍｏｎｉｔｏｒｉｎｇ　ＲｅｓｐｏｎｓｅパケットをＡＦＣ　Ｉｎｇｒｅｓｓに送信する（ステップＳ２３２）。Ｌｏａｄ　Ｍｏｎｉｔｏｒｉｎｇ　Ｒｅｓｐｏｎｓｅパケットの各フィールドの値は以下の通りである。Ｔｙｐｅフィールドには「Ｌｏａｄ　Ｍｏｎｉｔｏｒｉｎｇ　Ｒｅｓｐｏｎｓｅ」が設定される。Ｓｔａｔｕｓフィールドには処理の成功を示す「ＯＫ」が設定される。ＬｏａｄフィールドにはＡＦ　Ｎｏｄｅ－４－１の負荷の度合いを示す数値であるＬＤ－４－１が設定される。

　続いてＡＦＣ　ＩｎｇｒｅｓｓはＡＦ　Ｎｏｄｅ－４－２、ＡＦ　Ｎｏｄｅ－５－１およびＡＦ　Ｎｏｄｅ－５－２に対しても上記と同様の処理を行う（ステップＳ２３３、Ｓ２３５、Ｓ２３７）。ＡＦ　Ｎｏｄｅ－４－２、ＡＦ　Ｎｏｄｅ－５－１およびＡＦ　Ｎｏｄｅ－５－２はＡＦ　Ｎｏｄｅ－４－１と同様の処理を行う（ステップＳ２３４、Ｓ２３６、Ｓ２３８）。ＡＦＣ　ＩｎｇｒｅｓｓはＬｏａｄ　Ｍｏｎｉｔｏｒｉｎｇ　Ｒｅｓｐｏｎｓｅを受信すると、図６７に示したように、Ｌｏａｄフィールドの値をＩｎｇｒｅｓｓ　ＡＦ　Ｎｏｄｅ　ＴａｂｌｅのＬｏａｄフィールドに設定する。

　ＡＦＣ　Ｉｎｇｒｅｓｓは、定期的に上記の処理を繰り返す。これによりＡＦＣ　Ｉｎｇｒｅｓｓは、それぞれのＡＦ　Ｎｏｄｅの負荷を定期的に取得し、負荷の情報をアップデートすることができる。ここで、モニタリングされる負荷として、例えば、それぞれのＡＦ　ＮｏｄｅのＣＰＵ使用率、メモリ使用率、記憶媒体使用率、温度、実行中のＡＦ数、ネットワークインターフェースの使用率、ネットワークインターフェースのデータスループット、ネットワークインターフェースのパケット破棄量、ネットワークインターフェースのトラフィック量などが挙げられる。ネットワークインターフェースに関連する負荷は、送信および受信を区別してモニタリングをしてもよく、ＡＦ　Ｎｏｄｅが複数のネットワークインターフェースを持つ場合には、ネットワークインターフェース毎に区別してモニタリングをしてもよい。また、Ｌｏａｄ　Ｍｏｎｉｔｏｒｉｎｇ　ＲｅｑｕｅｓｔパケットまたはＬｏａｄ　Ｍｏｎｉｔｏｒｉｎｇ　Ｒｅｓｐｏｎｓｅパケットのフィールドは、複数の負荷の項目について設定されてもよい。

　（ＡＦＣ－３でのパケット転送（負荷によるＡＦ　Ｎｏｄｅの選択））
　次に、図５２においてＣＯＴＳ　ｄｅｖｉｃｅ上のアプリケーションが、図６８に示す元データパケットをＳｅｒｖｅｒ上のアプリケーションに送信したとする。ＣＯＴＳ　ｄｅｖｉｃｅのＩＰアドレスはＩＰ－ｃｏｔｓであり、ＣＯＴＳ　ｄｅｖｉｃｅ上のアプリケーションが使用するポート番号はＰｔ－ｃｏｔｓであるとする。ＳｅｒｖｅｒのＩＰアドレスはＩＰ－ｓｖｒ３であり、Ｓｅｒｖｅｒ上のアプリケーションが使用するポート番号はＰｔ－ｓｖｒ３であるとする。図６８に示した元データパケットにおいて、ＩＰヘッダには始点ＩＰアドレスフィールドと終点ＩＰアドレスフィールドのみを示し、ＵＤＰヘッダには始点ポートフィールドと終点ポートフィールドのみを示す。

　この元データパケットがＡＦＣ　Ｉｎｇｒｅｓｓに到達すると、ＡＦＣ　Ｉｎｇｒｅｓｓは図６７に示す　Ｉｎｇｒｅｓｓ　ＡＦＣ　Ｔａｂｌｅのマッチフィールドの値と受信したデータパケットのフィールドを比較する。その結果、この元データパケットはＡＦＣ　ＩＤフィールドの値がＡＦＣＩＤ－３であるＩｎｇｒｅｓｓ　ＡＦＣ　Ｔａｂｌｅとマッチすることが分かるので、ＡＦＣ　Ｉｎｇｒｅｓｓは図６９に示すように元データパケットの先頭にＩＰヘッダ、ＵＤＰヘッダおよびＡＦＣヘッダを付加し、ＡＦＣデータパケットを生成する。ＩＰヘッダでは、Ｓｒｃ　ＩＰフィールドにはＡＦＣ　ＩｎｇｒｅｓｓのＩＰアドレスであるＩＰ－ｉｎｇｒｅｓｓが設定される。図６７に示すＡＦ－４に関する２つのＩｎｇｒｅｓｓ　ＡＦ　Ｎｏｄｅ　ＴａｂｌｅのＬｏａｄフィールドの値についてＬＤ－４－１はＬＤ－４－２よりも小さい数値とする。すなわち、ＡＦ　Ｎｏｄｅ－４－１の負荷はＡＦ　Ｎｏｄｅ－４－２の負荷よりも低いとする。同様にＡＦ　Ｎｏｄｅ－５－１の負荷はＡＦ　Ｎｏｄｅ－５－２の負荷よりも低いとする。そこでＡＦＣ　Ｉｎｇｒｅｓｓは、ＡＦ－４のＡＦ　ＮｏｄｅとしてはＡＦ　Ｎｏｄｅ－４－１を選択し、ＡＦ－５のＡＦ　ＮｏｄｅとしてはＡＦ　Ｎｏｄｅ－５－１を選択する。ＩＰヘッダのＤｓｔ　ＩＰフィールドにはＡＦ　Ｎｏｄｅ－４－１のＩＰアドレスであるＩＰ－ａｆｎ４－１が設定される。ＵＤＰヘッダでは、Ｓｒｃ　ＰｏｒｔフィールドにはＡＦＣ　Ｉｎｇｒｅｓｓのデータパケット用ポート番号であるＤＰｔ－ｉｎｇｒｅｓｓが設定される。Ｄｓｔ　ＰｏｒｔフィールドにはＡＦＣ　Ｄａｅｍｏｎ－４－１のＡＦＣデータパケット送受信用ポート番号であるＤＰｔ－ａｆｃｄ４－１が設定される。ＡＦＣヘッダの各フィールドの値は、（データパケットへのＡＦＣ－１の適用）で述べた手順と同様にして設定される。

　上記のＡＦＣデータパケットはＩＰヘッダの終点アドレスとＵＤＰヘッダの終点ポート番号にしたがい、ＡＦＣ　Ｄａｅｍｏｎ－４－１に到達する。ＡＦＣ　Ｄａｅｍｏｎ－４－１は（データパケットへのＡＦＣ－１の適用）で述べた手順と同様に元データパケットにＡＦ－４を適用し、出力データを得る。ＡＦＣ　Ｄａｅｍｏｎ－４－１は図７０に示すヘッダを生成し、このパケットを送信する。上記のＡＦＣデータパケットはＩＰヘッダの終点アドレスとＵＤＰヘッダの終点ポート番号に従い、ＡＦＣ　Ｄａｅｍｏｎ－５－１に到達する。ＡＦＣ　Ｄａｅｍｏｎ－５－１は（データパケットへのＡＦＣ－１の適用）で述べた手順と同様に元データパケットにＡＦ－５を適用し、出力データを得る。ＡＦＣ　Ｄａｅｍｏｎ－５－１は図７１に示すヘッダを生成し、このパケットを送信する。上記のＡＦＣデータパケットはＩＰヘッダの終点アドレスとＵＤＰヘッダの終点ポート番号に従いＡＦＣ　Ｅｇｒｅｓｓに到達する。ＡＦＣ　Ｅｇｒｅｓｓは受信したＡＦＣデータパケットから元データパケットを取り出し、この元データパケットをＳｅｖｅｒに送信する。

　（ＡＦＣ－３でのパケット転送（ラウンドロビン、ランダム））
　上記の例では、ＣＯＴＳ　ｄｅｖｉｃｅ上のアプリケーションが送信した元データパケットがＡＦＣ　Ｉｎｇｒｅｓｓに到着した際、ＡＦＣ　Ｉｎｇｒｅｓｓは各ＡＦ　Ｎｏｄｅの負荷に基づいてＡＦＣを構成するＡＦ　Ｎｏｄｅを選択している。他の方法としては、ラウンドロビンでＡＦ　Ｎｏｄｅを選択する方法も考えられる。この例では（ＡＦ　Ｎｏｄｅ－４－１，ＡＦ　Ｎｏｄｅ－５－１）、（ＡＦ　Ｎｏｄｅ－４－１，ＡＦ　Ｎｏｄｅ－５－２）、（ＡＦ　Ｎｏｄｅ－４－２，ＡＦ　Ｎｏｄｅ－５－１）および（ＡＦ　Ｎｏｄｅ－４－２，ＡＦ　Ｎｏｄｅ－５－２）という４つの組み合わせがある。ラウンドロビンとは、この４つの組み合わせを順次使用するという方法である。またこの４つの組み合わせをランダムに選択する方法も用いられて良い。

　（ＡＦＣ－３でのパケット転送（ＡＦＣ　ＥｇｒｅｓｓからＡＦＣ　Ｉｎｇｒｅｓｓへのフィードバック））
　ＣＯＴＳ　ｄｅｖｉｃｅ上のアプリケーションが送信した元データパケットがＡＦＣ　Ｉｎｇｒｅｓｓに到着した際、ＡＦＣ　ＩｎｇｒｅｓｓはＡＦＣ－３としてＡＦ　Ｎｏｄｅ－４－１上のＡＦ－４とＡＦ　Ｎｏｄｅ－５－１上のＡＦ－５を選択し、ＡＦＣヘッダのＦｌａｇｓフィールドにＦｅｅｄｂａｃｋフラグを設定したとする。するとパケットは図７２のステップＳ２４１～Ｓ２４７のように、ＣＯＴＳ　ｄｅｖｉｃｅ上のアプリケーションからＳｅｒｖｅｒ上のアプリケーションへ転送されていく。

　ＡＦＣヘッダのＦｌａｇｓフィールドにＦｅｅｄｂａｃｋフラグが設定されているので、ＡＦＣ　ＥｇｒｅｓｓはＡＦＣ　Ｉｎｇｒｅｓｓとの間にＴＬＳコネクションを確立し（ステップＳ２４８）、図７３に示すＡＦＣ　ＦｅｅｄｂａｃｋパケットをＡＦＣ　Ｉｎｇｒｅｓｓに送信し（ステップＳ２４９）、最後にＡＦＣ　Ｉｎｇｒｅｓｓとの間のＴＬＳコネクションを切断する（ステップＳ２５０）。ＡＦＣ　Ｆｅｅｄｂａｃｋパケットの各フィールドの値は以下のとおりである。Ｔｙｐｅフィールドの値は「ＡＦＣ　Ｆｅｅｄｂａｃｋ」である。ＡＦＣ　ＩＤフィールドの値はＡＦＣＩＤ－３である。Ｎｏ　ｏｆ　ＡＦｓフィールドの値は２である。これに続く４つのフィールドはＡＦ　Ｎｏｄｅ－４－１に関するものである。ＡＦ　ＩＤフィールドの値はＡＦＩＤ－４である。ＡＦ　Ｎｏｄｅ　ＩＰ　Ａｄｄｒｅｓｓの値はＩＰ－ａｆｎ４－１である。Ｉｎ　ＴｉｍｅｓｔａｍｐフィールドとＯｕｔ　Ｔｉｍｅｓｔａｍｐフィールドには、受信したＡＦＣデータパケットのＡＦＣヘッダの対応するＡＦのＩｎ　ＴｉｍｅｓｔａｍｐフィールドとＯｕｔ　Ｔｉｍｅｓｔａｍｐフィールドとの値をそれぞれ設定する。続く４つのフィールドはＡＦ　Ｎｏｄｅ－５－１に関するものであり、上記と同様に設定される。Ｉｎｇｒｅｓｓ　Ｏｕｔ　Ｔｉｍｅｓｔａｍｐフィールドには、受信したＡＦＣデータパケットの対応するフィールドの値が設定される。Ｅｇｒｅｓｓ　Ｉｎ　Ｔｉｍｅｓｔａｍｐフィールドには、ＡＦＣ　ＥｇｒｅｓｓがＡＦＣデータパケットを受信したときの時刻が設定される。

　ＡＦＣ　ＩｎｇｒｅｓｓはＡＦＣ　Ｆｅｅｄｂａｃｋパケットを受信すると、図７４に示すテーブルを保持する。

　Ｉｎｇｒｅｓｓ　ＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　Ｔａｂｌｅの各フィールドの値は以下の通りである。ＡＦＣ　ＩＤフィールドの値はＡＦＣＩＤ－３である。Ｎｏ　ｏｆ　ＡＦｓフィールドの値は２である。ｐｔｒ　ｔｏ　ＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　Ｅｎｔｒｙフィールドの値は、Ｉｎｇｒｅｓｓ　ＡＦＣ　Ｐａｔｈ　ｌｉｓｔ　Ｅｎｔｒｙへのポインタである。Ｉｎｇｒｅｓｓ　Ｏｕｔ　Ｔｉｍｅｓｔａｍｐフィールドの値は、ＡＦＣ　Ｆｅｅｄｂａｃｋパケットの対応するフィールドの値であるＴＳｏｕｔ－ｉｎｇｒｅｓｓである。Ｅｇｒｅｓｓ　Ｉｎ　Ｔｉｍｅｓｔａｍｐフィールドの値は、ＡＦＣ　Ｆｅｅｄｂａｃｋパケットの対応するフィールドの値であるＴＳｉｎ－ｅｇｒｅｓｓである。ｐｔｒ　ｔｏ　Ｎｅｘｔ　ＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　Ｔａｂｌｅの値は［ｎｕｌｌ］である。

　Ｉｎｇｒｅｓｓ　ＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　Ｅｎｔｒｙの各フィールドの値は以下の通りである。ＡＦＣ　ＩｎｇｒｅｓｓはＡＦＣ　Ｆｅｅｄｂａｃｋパケットの対象となったＡＦＣパスの識別子としてＡＦＣＰＩＤ－ａｆｃ３－１を割当て、これをＡＦＣ　Ｐａｔｈ　ＩＤフィールドに格納する。ｐｔｒ　ｔｏ　ＡＦ　Ｎｏｄｅ　ＴＳ　Ｔａｂｌｅの値は、Ｉｎｇｒｅｓｓ　ＡＦ　Ｎｏｄｅ　ＴＳ　Ｔａｂｌｅへのポインタである。ｐｔｒ　ｔｏ　Ｎｅｘｔ　ＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　Ｅｎｔｒｙの値は［ｎｕｌｌ］である。ＡＦＣ　ＩｎｇｒｅｓｓがＡＦＣ－３に関する別のＡＦＣパスに関するＡＦＣ　Ｆｅｅｄｂａｃｋパケットを受信すると、新たにＩｎｇｒｅｓｓ　ＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　Ｅｎｔｒｙを作成し、このＩｎｇｒｅｓｓ　ＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　Ｅｎｔｒｙへのポインタを上記のｐｔｒ　ｔｏ　Ｎｅｘｔ　ＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　Ｅｎｔｒｙに格納する。

　２つあるＩｎｇｒｅｓｓ　ＡＦＣ　Ｎｏｄｅ　ＴＳ　Ｔａｂｌｅのうち左側のものはＡＦ　Ｎｏｄｅ－４－１に関するものであり、右側のものはＡＦＮｏｄｅ－５－１に関するものである。

　ＡＦ　Ｎｏｄｅ－４－１に関するＩｎｇｒｅｓｓ　ＡＦ　Ｎｏｄｅ　ＴＳ　Ｔａｂｌｅの各フィールドの値は以下の通りである。ｐｔｒ　ｔｏ　Ｎｅｘｔ　ＡＦ　Ｎｏｄｅ　ＴＳ　Ｔａｂｌｅフィールドの値は、ＡＦ　Ｎｏｄｅ－５－１に関するＡＦ　Ｎｏｄｅ　ＴＳ　Ｔａｂｌｅへのポインタである。ＡＦ　ＩＤフィールドの値はＡＦＩＤ－４である。ＡＦ　Ｎｏｄｅ　ＩＰ　Ａｄｄｒｅｓｓフィールドの値はＡＦ　Ｎｏｄｅ－４－１のＩＰアドレスであるＩＰ－ａｆｎ４－１である。Ｉｎ　Ｔｉｍｅｓｔａｍｐフィールドの値は、ＡＦＣ　Ｆｅｅｄｂａｃｋパケットの対応するＩｎ　Ｔｉｍｅｓｔａｍｐフィールドの値であるＴＳｉｎ－ａｆｎ４－１である。Ｏｕｔ　Ｔｉｍｅｓｔａｍｐフィールドの値は、ＡＦＣ　Ｆｅｅｄｂａｃｋパケットの対応するＯｕｔ　Ｔｉｍｅｓｔａｍｐフィールドの値であるＴＳｏｕｔ－ａｆｎ４－１である。

　ＡＦ　Ｎｏｄｅ－５－１に関するＩｎｇｒｅｓｓ　ＡＦ　Ｎｏｄｅ　ＴＳ　Ｔａｂｌｅの各フィールドの値は以下の通りである。ｐｔｒ　ｔｏ　Ｎｅｘｔ　ＡＦ　Ｎｏｄｅ　ＴＳ　Ｔａｂｌｅフィールドの値は［ｎｕｌｌ］である。ＡＦ　ＩＤフィールドの値はＡＦＩＤ－５である。ＡＦ　Ｎｏｄｅ　ＩＰ　Ａｄｄｒｅｓｓフィールドの値はＡＦ　Ｎｏｄｅ－５－１のＩＰアドレスであるＩＰ－ａｆｎ５－１である。Ｉｎ　Ｔｉｍｅｓｔａｍｐフィールドの値は、ＡＦＣ　Ｆｅｅｄｂａｃｋパケットの対応するＩｎ　Ｔｉｍｅｓｔａｍｐフィールドの値であるＴＳｉｎ－ａｆｎ５－１である。Ｏｕｔ　Ｔｉｍｅｓｔａｍｐフィールドの値は、ＡＦＣ　Ｆｅｅｄｂａｃｋパケットの対応するＯｕｔ　Ｔｉｍｅｓｔａｍｐフィールドの値であるＴＳｏｕｔ－ａｆｎ５－１である。

　この例ではＡＦＣ－３には４つのＡＦＣパスがあるので、ＡＦＣ　ＩｎｇｒｅｓｓはそれぞれのＡＦＣパスに関するＡＦＣ　Ｆｅｅｄｂａｃｋパケットを受信すると、対応するＩｎｇｒｅｓｓ　ＡＦ　Ｎｏｄｅ　ＴＳ　Ｔａｂｌｅを更新する。ＡＦＣ　ＩｎｇｒｅｓｓがＣＯＴＳ　ｄｅｖｉｃｅのアプリケーションからＡＦＣ－３を適用する元データパケットを受信したとき、ＡＦＣ　ＩｎｇｒｅｓｓはＩｎｇｒｅｓｓ　ＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　Ｔａｂｌｅを参照し、ＡＦＣパスを選択してもよい。例えば、ＡＦＣパス全体の通信時間を考慮することができる。あるいは、ＡＦの処理時間のみを考慮することもできる。また、各ノード間の通信時間のみを考慮することもできる。さらに、特定のＡＦの処理時間と特定のノード間の通信時間を組み合わせることもできる。

　（タイムアウトと、タイムアウトの延長要求）
　ＡＦＣ　Ｍａｎａｇｅｒは一定間隔（例えば１分間隔）でＭａｎａｇｅｒ　Ｕｓｅｒ　ＴａｂｌｅのＴｉｍｅ　ｔｏ　Ｌｉｖｅフィールドの値をデクリメントする。デクリメントした結果、Ｔｉｍｅ　ｔｏ　Ｌｉｖｅフィールドの値が０（タイムアウト）になると、該当するＡＦＣ　Ｕｓｅｒに関する全てのテーブルを消去する。上述の状態の場合、ＡＦＣ　Ｕｓｅｒ－１に関するＭａｎａｇｅｒ　Ｕｓｅｒ　ＴａｂｌｅのＴＴＬ－ｕｓｒ１フィールドの値が０になると、ＡＦＣ　ＭａｎａｇｅｒはＡＦＣ　Ｕｓｅｒ－１に関するすべてのテーブルを消去する。

　ＡＦＣ　Ｕｓｅｒ－１は、タイムアウトまでの時間を延長することができる。図７５は、ＡＦＣ　Ｕｓｅｒ－１によるタイムアウトまでの時間の延長処理を示す説明図である。

　まずＡＦＣ　Ｕｓｅｒ－１はＡＦＣ　Ｍａｎａｇｅｒとの間にＴＬＳコネクションを確立する（ステップＳ２５１）。

　続いてＡＦＣ　Ｕｓｅｒ－１は図７６に示すＴｉｍｅｏｕｔ　Ｅｘｔｅｎｓｉｏｎ　ＲｅｑｕｅｓｔパケットをＡＦＣ　Ｍａｎａｇｅｒに送信する（ステップＳ２５２）。Ｔｉｍｅｏｕｔ　Ｅｘｔｅｎｓｉｏｎ　Ｒｅｑｕｅｓｔパケットの各フィールドの値は以下の通りである。Ｔｙｐｅフィールドには「Ｔｉｍｅｏｕｔ　Ｅｘｔｅｎｓｉｏｎ　Ｒｅｑｕｅｓｔ」が設定される。Ｕｓｅｒ　ＩＤフィールドにはＵＳＲＩＤ－１が設定される。ＡＦ　ＩＤフィールドには、ＡＦＣ　Ｕｓｅｒ－１がこの時点において設置済であるＡＦから１つを選択し、その識別子が設定される。この例ではＡＦＩＤ－４である。ＡＦ　Ｃｅｒｔｉｆｉｃａｔｅフィールドには、ＡＦＳＫｅｙ－ａｆ４を用いて生成した証明書情報であるＡＦＣｅｒｔ－ａｆ４が設定される。Ｔｉｍｅ　ｔｏ　Ｌｉｖｅフィールドには、希望する新しいタイムアウト値であるＴＴＬ－ｕｓｒ１－２が設定される。

　ＡＦＣ　ＭａｎａｇｅｒはＴｉｍｅｏｕｔ　Ｅｘｔｅｎｓｉｏｎ　Ｒｅｑｕｅｓｔパケットを受信すると、ＡＦ　Ｃｅｒｔｉｆｉｃａｔｅフィールドの値を検証する。ＡＦＣ　Ｍａｎａｇｅｒは、検証に成功するとＴｉｍｅ　ｔｏ　Ｌｉｖｅフィールドの値を確認し、許可できる新しいアイムアウト値であるＴＴＬ－ｕｓｒ１－３を決定する。次にＡＦＣ　Ｍａｎａｇｅｒは図７７に示すＴｉｍｅｏｕｔ　Ｅｘｔｅｎｓｉｏｎ　ＲｅｓｐｏｎｓｅパケットをＡＦＣ　Ｕｓｅｒ－１に送信する（ステップＳ２５３）。Ｔｉｍｅｏｕｔ　Ｅｘｔｅｎｓｉｏｎ　Ｒｅｓｐｏｎｓｅパケットの各フィールドの値は以下の通りである。Ｔｙｐｅフィールドには「Ｔｉｍｅｏｕｔ　Ｅｘｔｅｎｓｉｏｎ　Ｒｅｓｐｏｎｓｅ」が設定される。Ｓｔａｔｕｓフィールドには処理の成功を示す「ＯＫ」が設定される。Ｕｓｅｒ　ＩＤフィールドには、Ｔｉｍｅｏｕｔ　Ｅｘｔｅｎｓｉｏｎ　ＲｅｑｕｅｓｔパケットのＵｓｅｒ　ＩＤフィールドの値であるＵＳＲＩＤ－１が設定される。Ｔｉｍｅ　ｔｏ　Ｌｉｖｅフィールドには許可できる新しいアイムアウト値であるＴＴＬ－ｕｓｒ１－３が設定される。

　ＡＦＣ　Ｕｓｅｒ－１はＴｉｍｅｏｕｔ　Ｅｘｔｅｎｓｉｏｎ　Ｒｅｓｐｏｎｓｅパケットを受信するとＡＦＣ　Ｍａｎａｇｅｒとの間のＴＬＳコネクションを切断する（ステップＳ２５４）。

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

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

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

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

　制御部１３０は、例えばＣＰＵ等のプロセッサで構成され、上述してきたＡＦＣのアーキテクチャに基づく処理を実行する。例えば、制御部１３０は、目的のノードとの間の経路の設定、目的のノードとの間の通信処理、ＡＦノードの追加、変更、削除等が発生した際の処理、ＡＦＣ－ｄａｅｍｏｎの起動、ＡＦの機能の実行、等を実行する。すなわち、制御部１３０は、ＡＦＣ　ＩｎｇｒｅｓｓからＡＦＣ　Ｅｇｒｅｓｓの間の経路に変更が生じた場合は、新たにＡＦを設定するためのメッセージを生成する。この変更としては、例えばＡＦＣ　ＩｎｇｒｅｓｓからＡＦＣ　Ｅｇｒｅｓｓとの間で経路を分岐させる場合の変更であってもよい。またこの変更としては、例えばＡＦＣ　ＩｎｇｒｅｓｓからＡＦＣ　Ｅｇｒｅｓｓとの間でＡＦノードを削除する場合の変更で有ってもよい。また制御部１３０は、自装置がＡＦＣ　Ｉｎｇｒｅｓｓであれば、ＣＯＴＳ　ｄｅｖｉｃｅから送られたパケットにＡＦＣヘッダを付与し、自装置がＡＦＣ　Ｅｇｒｅｓｓであれば、ＡＦＣヘッダが付与されたパケットからＡＦＣヘッダ削除する処理を実行する。

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

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

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

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

　また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。

　例えば、ＡＦＣ　ＩｎｇｒｅｓｓがＡＦＣパスの最初のＡＦ　Ｎｏｄｅを兼ねていても良い。すなわち、ＡＦＣ　Ｉｎｇｒｅｓｓと、ＡＦＣパスの経路上の最初のＡＦ　Ｎｏｄｅが、物理的または論理的に同一の通信装置として構成されてもよい。この場合には、例えば、この通信装置がパケットを受信した際に、まずＡＦＣ　ｉｎｇｒｅｓｓの動作として、ＡＦＣ　ＩｎｇｒｅｓｓとＡＦＣ　Ｅｇｒｅｓｓの間の経路情報が記述されたヘッダ情報をパケットに追加した後に、ＡＦ　Ｎｏｄｅとしての動作を実行する。ＡＦＣ　ＩｎｇｒｅｓｓとＡＦＣ　Ｎｏｄｅが同一の通信装置として構成される場合、ＡＦＣ　Ｉｎｇｒｅｓｓの動作の一部が省略されてもよい。例えば、ＡＦＣ　Ｉｎｇｒｅｓｓとして他のノードへパケットを送出する動作を省略して、ＡＦ　Ｎｏｄｅとしての動作に移ってもよい。また、ＡＦＣ　ＩｎｇｒｅｓｓとＡＦＣ　Ｎｏｄｅが同一の通信装置として構成される場合、ＡＦ　Ｎｏｄｅの動作の一部が省略されてもよい。

　また例えば、ＡＦＣ　Ｅｇｒｅｓｓと、経路上の最後のＡＦ　Ｎｏｄｅが、物理的または論理的に同一の通信装置として構成されてもよい。この場合には、例えば、この通信装置がパケットを受信した際に、まずＡＦ　Ｎｏｄｅとしての動作を実行した後に、ＡＦＣ　Ｅｇｒｅｓｓの動作として、ＡＦＣ　ＩｎｇｒｅｓｓとＡＦＣ　Ｅｇｒｅｓｓの間の経路情報が記述されたヘッダ情報をパケットから削除する。ＡＦＣ　ＥｇｒｅｓｓとＡＦＣ　Ｎｏｄｅが同一の通信装置として構成される場合、ＡＦＣ　Ｅｇｒｅｓｓの動作の一部が省略されてもよい。例えば、ＡＦ　Ｎｏｄｅとして他のノードへパケットを送出する動作を省略して、ＡＦＣ　Ｅｇｒｅｓｓとしての動作に移ってもよい。また、ＡＦＣ　ＥｇｒｅｓｓとＡＦＣ　Ｎｏｄｅが同一の通信装置として構成される場合、ＡＦ　Ｎｏｄｅの動作の一部が省略されてもよい。

　なお、以下のような構成も本開示の技術的範囲に属する。
（１）
　他のノードとの間の通信を実行する通信部と、
　前記通信部による通信を制御する制御部と、
を備え、
　前記制御部は、送信元ノードが送信先ノードへ向けたパケットに、前記送信元ノードの後段に位置する自装置と、前記送信先ノードの前段に位置する目的ノードとの間の経路情報が少なくとも記述されたヘッダ情報を追加して、経路中に存在する他のノードへ向けて前記通信部に送出させる、通信装置。
（２）
　自装置と前記目的ノードとの間の経路情報には、少なくとも、前記目的ノードとの間に存在する少なくとも一つの中継ノードとの通信に関する情報と、前記中継ノードに実行させる機能の情報と、前記中継ノードでの前記機能の実行結果に応じた処理の内容と、が記述される、前記（１）に記載の通信装置。
（３）
　前記処理の内容は、前記中継ノードの次のノードの選択である、前記（２）に記載の通信装置。
（４）
　自装置と前記目的ノードとの間の経路情報には、さらに、前記中継ノードでの証明書情報が記述される、前記（２）または（３）に記載の通信装置。
（５）
　前記制御部は、複数の前記中継ノードの負荷の情報に基づいて、複数の前記中継ノードの中から一の前記中継ノードを選択する、前記（２）～（４）のいずれかに記載の通信装置。
（６）
　他のノードとの間の通信を実行する通信部と、
　前記通信部による通信を制御する制御部と、
を備え、
　前記制御部は、送信元ノードが送信先ノードへ向けたパケットに付加された、前記送信元ノードの後段に位置する開始ノードから前記送信先ノードの前段に位置する自装置までの間の経路情報が少なくとも記述されたヘッダ情報を削除して前記通信部に送出させる、通信装置。
（７）
　前記開始ノードから自装置までの間の経路情報には、少なくとも、自装置までの間に存在する少なくとも一つの中継ノードとの通信に関する情報と、前記中継ノードに実行させる機能の情報と、前記中継ノードでの前記機能の実行結果に応じた処理の内容と、が記述される、前記（６）に記載の通信装置。
（８）
　他のノードとの間の通信を実行する通信部と、
　前記通信部による通信を制御する制御部と、
を備え、
　前記制御部は、送信元ノードが送信先ノードへ向けたパケットに、前記送信元ノードの後段に位置する開始ノードから前記送信先ノードの前段に位置する目的ノードまでの間の経路情報が少なくとも記述されたヘッダ情報が付加されたデータを参照して次ノードを決定し、決定した前記次ノードへ向けて前記データを前記通信部に送出させる、通信装置。
（９）
　前記開始ノードと前記目的ノードとの間の経路情報には、少なくとも、前記開始ノードと前記目的ノードとの間に存在する少なくとも一つの中継ノードとの通信に関する情報と、前記中継ノードに実行させる機能の情報と、前記中継ノードでの前記機能の実行結果に応じた処理の内容と、が記述される、前記（８）に記載の通信装置。
（１０）
　前記処理の内容は、前記中継ノードの次のノードの選択である、前記（９）に記載の通信装置。
（１１）
　前記開始ノードと前記目的ノードとの間の経路情報には、さらに、前記中継ノードでの証明書情報が記述される、前記（９）または（１０）に記載の通信装置。
（１２）
　前記制御部は、複数の前記中継ノードの負荷の情報に基づいて、複数の前記中継ノードの中から一の前記中継ノードを選択する、前記（９）～（１１）のいずれかに記載の通信装置。
（１３）
　他のノードとの間の通信を実行する通信部と、
　前記通信部による通信を制御する制御部と、
を備え、
　前記制御部は、開始ノードと目的ノードとの間の経路情報を生成し、
　前記開始ノードは、前記開始ノードと前記目的ノードとの間の経路情報が少なくとも記述されたヘッダ情報を追加するノードであり、
　前記目的ノードは、前記ヘッダ情報を削除するノードであり、
　前記開始ノードと前記目的ノードとの間の経路情報は、少なくとも、前記開始ノードと前記目的ノードとの間に存在する少なくとも一つの中継ノードとの通信に関する情報と、前記中継ノードに実行させる機能の情報と、前記中継ノードでの前記機能の実行結果に応じた処理の内容と、が記述される、通信装置。
（１４）
　前記処理の内容は、前記中継ノードの次のノードの選択である、前記（１３）に記載の通信装置。
（１５）
　前記開始ノードと前記目的ノードとの間の経路情報は、さらに、前記中継ノードでの証明書情報が記述される、前記（１３）または（１４）に記載の通信装置。
（１６）
　他のノードとの間の通信を実行することと、
　前記他のノードとの間の通信を制御することと、
を備え、
　前記制御することは、送信元ノードが送信先ノードへ向けたパケットに、前記送信元ノードの後段に位置する開始ノードと、前記送信先ノードの前段に位置する目的ノードとの間の経路情報が少なくとも記述されたヘッダ情報を追加して経路中に存在する他のノードへ向けて送出させる、通信方法。
（１７）
　他のノードとの間の通信を実行することと、
　前記他のノードとの間の通信を制御することと、
を備え、
　前記制御することは、送信元ノードが送信先ノードへ向けたパケットに、前記送信元ノードの後段に位置する開始ノードと、前記送信先ノードの前段に位置する目的ノードとの間の経路情報が少なくとも記述されたヘッダ情報を削除して前記他のノードへ向けて送出させる、通信方法。
（１８）
　他のノードとの間の通信を実行することと、
　前記他のノードとの間の通信を制御することと、
を備え、
　前記制御することは、送信元ノードが送信先ノードへ向けたパケットに、前記送信元ノードの後段に位置する開始ノードから前記送信先ノードの前段に位置する目的ノードまでの間の経路情報が少なくとも記述されたヘッダ情報が付加されたデータを参照して次ノードを決定し、決定した前記次ノードへ向けて前記データを送出させる、通信方法。
（１９）
　他のノードとの間の通信を実行する通信部と、
　前記通信部による通信を制御する制御部と、
　前記制御部は、送信元ノードが送信先ノードへ向けたパケットに、ヘッダ情報を追加して前記通信部に送出させる、通信装置で用いられ、
　前記ヘッダ情報として、開始ノードと目的ノードとの間の前記送信元ノードの後段に位置する開始ノードと、前記送信先ノードの前段に位置する目的ノードとの間の経路情報が少なくとも備える、データ構造。

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

Claims

　他のノードとの間の通信を実行する通信部と、
　前記通信部による通信を制御する制御部と、
を備え、
　前記制御部は、送信元ノードが送信先ノードへ向けたパケットに、前記送信元ノードの後段に位置する自装置と、前記送信先ノードの前段に位置する目的ノードとの間の経路情報が少なくとも記述されたヘッダ情報を追加して、経路中に存在する他のノードへ向けて前記通信部に送出させる、通信装置。
　自装置と前記目的ノードとの間の経路情報には、少なくとも、前記目的ノードとの間に存在する少なくとも一つの中継ノードとの通信に関する情報と、前記中継ノードに実行させる機能の情報と、前記中継ノードでの前記機能の実行結果に応じた処理の内容と、が記述される、請求項１に記載の通信装置。
　前記処理の内容は、前記中継ノードの次のノードの選択である、請求項２に記載の通信装置。
　自装置と前記目的ノードとの間の経路情報には、さらに、前記中継ノードでの証明書情報が記述される、請求項２に記載の通信装置。
　前記制御部は、複数の前記中継ノードの負荷の情報に基づいて、複数の前記中継ノードの中から一の前記中継ノードを選択する、請求項２に記載の通信装置。
　他のノードとの間の通信を実行する通信部と、
　前記通信部による通信を制御する制御部と、
を備え、
　前記制御部は、送信元ノードが送信先ノードへ向けたパケットに付加された、前記送信元ノードの後段に位置する開始ノードから前記送信先ノードの前段に位置する自装置までの間の経路情報が少なくとも記述されたヘッダ情報を削除して前記通信部に送出させる、通信装置。
　前記開始ノードから自装置までの間の経路情報には、少なくとも、自装置までの間に存在する少なくとも一つの中継ノードとの通信に関する情報と、前記中継ノードに実行させる機能の情報と、前記中継ノードでの前記機能の実行結果に応じた処理の内容と、が記述される、請求項６に記載の通信装置。
　他のノードとの間の通信を実行する通信部と、
　前記通信部による通信を制御する制御部と、
を備え、
　前記制御部は、送信元ノードが送信先ノードへ向けたパケットに、前記送信元ノードの後段に位置する開始ノードから前記送信先ノードの前段に位置する目的ノードまでの間の経路情報が少なくとも記述されたヘッダ情報が付加されたデータを参照して次ノードを決定し、決定した前記次ノードへ向けて前記データを前記通信部に送出させる、通信装置。
　前記開始ノードと前記目的ノードとの間の経路情報には、少なくとも、前記開始ノードと前記目的ノードとの間に存在する少なくとも一つの中継ノードとの通信に関する情報と、前記中継ノードに実行させる機能の情報と、前記中継ノードでの前記機能の実行結果に応じた処理の内容と、が記述される、請求項８に記載の通信装置。
　前記処理の内容は、前記中継ノードの次のノードの選択である、請求項９に記載の通信装置。
　前記開始ノードと前記目的ノードとの間の経路情報には、さらに、前記中継ノードでの証明書情報が記述される、請求項９に記載の通信装置。
　前記制御部は、複数の前記中継ノードの負荷の情報に基づいて、複数の前記中継ノードの中から一の前記中継ノードを選択する、請求項９に記載の通信装置。
　他のノードとの間の通信を実行する通信部と、
　前記通信部による通信を制御する制御部と、
を備え、
　前記制御部は、開始ノードと目的ノードとの間の経路情報を生成し、
　前記開始ノードは、前記開始ノードと前記目的ノードとの間の経路情報が少なくとも記述されたヘッダ情報を追加するノードであり、
　前記目的ノードは、前記ヘッダ情報を削除するノードであり、
　前記開始ノードと前記目的ノードとの間の経路情報は、少なくとも、前記開始ノードと前記目的ノードとの間に存在する少なくとも一つの中継ノードとの通信に関する情報と、前記中継ノードに実行させる機能の情報と、前記中継ノードでの前記機能の実行結果に応じた処理の内容と、が記述される、通信装置。
　前記処理の内容は、前記中継ノードの次のノードの選択である、請求項１３に記載の通信装置。
　前記開始ノードと前記目的ノードとの間の経路情報は、さらに、前記中継ノードでの証明書情報が記述される、請求項１３に記載の通信装置。
　他のノードとの間の通信を実行することと、
　前記他のノードとの間の通信を制御することと、
を備え、
　前記制御することは、送信元ノードが送信先ノードへ向けたパケットに、前記送信元ノードの後段に位置する開始ノードと、前記送信先ノードの前段に位置する目的ノードとの間の経路情報が少なくとも記述されたヘッダ情報を追加して経路中に存在する他のノードへ向けて送出させる、通信方法。
　他のノードとの間の通信を実行することと、
　前記他のノードとの間の通信を制御することと、
を備え、
　前記制御することは、送信元ノードが送信先ノードへ向けたパケットに、前記送信元ノードの後段に位置する開始ノードと、前記送信先ノードの前段に位置する目的ノードとの間の経路情報が少なくとも記述されたヘッダ情報を削除して前記他のノードへ向けて送出させる、通信方法。
　他のノードとの間の通信を実行することと、
　前記他のノードとの間の通信を制御することと、
を備え、
　前記制御することは、送信元ノードが送信先ノードへ向けたパケットに、前記送信元ノードの後段に位置する開始ノードから前記送信先ノードの前段に位置する目的ノードまでの間の経路情報が少なくとも記述されたヘッダ情報が付加されたデータを参照して次ノードを決定し、決定した前記次ノードへ向けて前記データを送出させる、通信方法。
　他のノードとの間の通信を実行する通信部と、
　前記通信部による通信を制御する制御部と、
　前記制御部は、送信元ノードが送信先ノードへ向けたパケットに、ヘッダ情報を追加して前記通信部に送出させる、通信装置で用いられ、
　前記ヘッダ情報として、開始ノードと目的ノードとの間の前記送信元ノードの後段に位置する開始ノードと、前記送信先ノードの前段に位置する目的ノードとの間の経路情報が少なくとも備える、データ構造。