JP2009525708A - プロトコルリンクレイヤ - Google Patents
プロトコルリンクレイヤ Download PDFInfo
- Publication number
- JP2009525708A JP2009525708A JP2008553515A JP2008553515A JP2009525708A JP 2009525708 A JP2009525708 A JP 2009525708A JP 2008553515 A JP2008553515 A JP 2008553515A JP 2008553515 A JP2008553515 A JP 2008553515A JP 2009525708 A JP2009525708 A JP 2009525708A
- Authority
- JP
- Japan
- Prior art keywords
- node
- link
- packet
- layer
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/325—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the network layer [OSI layer 3], e.g. X.25
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
- H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
リンクはソフトウェア抽象化であり、このソフトウェア抽象化は、２つのＣｏＣｏノードの間の直接的な接続手段を表わす。リンクレイヤは、隣接するＣｏＣｏデバイスの存在を検出し、そしてこれらのデバイスへのリンクを設定する。プロトコル抽象化レイヤは、ネットワークインターフェースに到着するデータフレームを、ＣｏＣｏプロトコルスィートによって使用されるパケットオブジェクトに変換する。
Description
関連出願の相互参照
本出願は、２００６年２月１日出願の「プロトコルリンクレイヤ」と題する米国仮特許出願第６０／７６３，９５９号の利益を主張し、そして２００６年２月１日出願の「プロトコル回線レイヤ」と題する米国仮特許出願第６０／７６３，９７７号、及び２００６年２月１日出願の「ＣＳＭＡ方式伝送媒体における輻輳管理及び遅延予測」と題する米国仮特許出願第６０／７６４，０１３号に関連する。
本出願は、２００６年２月１日出願の「プロトコルリンクレイヤ」と題する米国仮特許出願第６０／７６３，９５９号の利益を主張し、そして２００６年２月１日出願の「プロトコル回線レイヤ」と題する米国仮特許出願第６０／７６３，９７７号、及び２００６年２月１日出願の「ＣＳＭＡ方式伝送媒体における輻輳管理及び遅延予測」と題する米国仮特許出願第６０／７６４，０１３号に関連する。
コンピュータをネットワーク化することによりデータをコンピュータ間で数十年間に亘って授受してきている。一つの重要なネットワークであるインターネットは、通信チャネルで相互接続される非常に多くのコンピュータ及びコンピュータネットワークを含む。インターネットは、電子商取引、電子メールのような情報交換、情報の抽出及び調査の実施などを含む種々の理由により使用される。多くの規格が、情報をインターネット経由で授受するために設定され、規格として、電子メール、ゴーファー（Ｇｏｐｈｅｒ），及びワールドワイドウェブ（ＷＷＷ）を挙げることができる。ＷＷＷサービスによって、サーバコンピュータシステム（すなわち、ウェブサーバまたはウェブサイト）は情報をグラフィカルなウェブページの形でリモートクライアントコンピュータシステムに送信することができる。従って、リモートクライアントコンピュータシステムはウェブページを表示することができる。ＷＷＷの各リソース（例えば、コンピュータまたはウェブページ）は、ユニフォームリソースロケータ（ＵＲＬ）によって一意に特定することができる。特定のウェブページを閲覧するために、クライアントコンピュータシステムは、当該ウェブページに対応するＵＲＬをリクエスト（例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）リクエスト）として指定する。リクエストは、ウェブページをサポートするウェブサーバに転送される。当該ウェブサーバがリクエストを受信すると、サーバはリクエストされたウェブページをクライアントコンピュータシステムに送信する。クライアントコンピュータシステムが当該ウェブページを受信すると、クライアントコンピュータシステムは通常、ブラウザを使用してウェブページを表示する。ブラウザは通常、ウェブページをリクエストし、そして表示する特定用途向けプログラムである。
現在、ウェブページは多くの場合、ハイパーテキストマークアップ言語（ＨＴＭＬ）を使用して記述される。ＨＴＭＬには一連の標準のタグが使用され、これらのタグは、ウェブページを表示する方法について記述する。ユーザがリクエストをブラウザに対して行なってウェブページを表示させる場合、ブラウザはリクエストをサーバコンピュータシステムに送信し、サーバコンピュータシステムに、ウェブページを記述するＨＴＭＬドキュメントをクライアントコンピュータシステムに転送させる。リクエストされたＨＴＭＬドキュメントをクライアントコンピュータシステムが受信すると、ブラウザは、ＨＴＭＬドキュメントに記述されたウェブページを表示する。ＨＴＭＬドキュメントは種々のタグを含み、これらのタグで、テキスト、グラフィックス、コントロール、及び他の機能の表示を制御する。ＨＴＭＬドキュメントには、当該サーバコンピュータシステムで、または他のサーバコンピュータシステムで利用することができる他のウェブページのＵＲＬが含まれる。
拡張可能マークアップ言語（ＸＭＬ）及びワイヤレスアクセスプロトコル（ＷＡＰ）のような新規のプロトコルが存在する。ＸＭＬはＨＴＭＬよりも高いフレキシビリティを持つ。ＷＡＰは種々の機能の中でもとりわけ、ウェブページを、携帯電話機及び携帯型コンピュータ（例えばＰＤＡ）のような携帯型無線機器で閲覧する機能を実現する。これらのプロトコルの全てが、情報を人々に種々のデータ処理装置を介して提供する手段を容易にするように機能する。データをデータ処理装置の間で授受する多くの他のプロトコル及び手段が継続的に開発されることにより、情報の授受が更に容易になる。
リンクコンセプト
リンクはソフトウェア抽象化であり、このソフトウェア抽象化は、２つのＣｏＣｏノードの間の直接的な接続手段を表わす。リンクレイヤの基本タスクは、隣接するＣｏＣｏデバイスの存在を検出し、そしてこれらのデバイスへのリンクを設定することである。
リンクはソフトウェア抽象化であり、このソフトウェア抽象化は、２つのＣｏＣｏノードの間の直接的な接続手段を表わす。リンクレイヤの基本タスクは、隣接するＣｏＣｏデバイスの存在を検出し、そしてこれらのデバイスへのリンクを設定することである。
リンクレイヤプロトコル動作に関する記述
リンク設定では、従来の３ウェイハンドシェークプロトコル（“ｈｅｌｌｏ，”，“ｈｅｌｌｏ−ａｃｋ，”，及び“ｆｉｎａｌ−ａｃｋ，”を含むパケット；［ＩＳＩ］を参照）に変更を加えたプロトコルを用いる。リンク設定では、符号化方式の合意を行ない、そしてデフィー・ヘルマン（Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ）キー交換を実行することにより、リンク経由で送信される全ての通信を暗号化チェックサム［Ｓ］によって検証することができる。これにより、識別情報の一貫性が確保される。すなわち、或るノードは、リンク経由で受信する全てのパケットが、当該ノードが当該リンクを設定したときの相手方のノードから送信されたパケットであることについて保証される。
リンク設定では、従来の３ウェイハンドシェークプロトコル（“ｈｅｌｌｏ，”，“ｈｅｌｌｏ−ａｃｋ，”，及び“ｆｉｎａｌ−ａｃｋ，”を含むパケット；［ＩＳＩ］を参照）に変更を加えたプロトコルを用いる。リンク設定では、符号化方式の合意を行ない、そしてデフィー・ヘルマン（Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ）キー交換を実行することにより、リンク経由で送信される全ての通信を暗号化チェックサム［Ｓ］によって検証することができる。これにより、識別情報の一貫性が確保される。すなわち、或るノードは、リンク経由で受信する全てのパケットが、当該ノードが当該リンクを設定したときの相手方のノードから送信されたパケットであることについて保証される。
一旦、リンクが設定されると、リンクレイヤでは次の処理が行なわれる。
・パケットをネットワークインターフェースレイヤと、当該レイヤよりも上位のプロトコルレイヤ（ルーティングレイヤ及び回線レイヤ）との間で授受する。
・サービス品質（ＱｏＳ）統計をモニタリングし、そしてこれらのサービス品質統計を上位のプロトコルレイヤにレポートする。
・マルチキャストを、単一ネットワークインターフェース経由の冗長なパケット送信を抑圧することによりサポートする。
・パケットサイズがネットワークインターフェースの最大送信単位（ＭＴＵ）を超える場合にフラグメンテーションを実行する。
・無効リンクを閉鎖して、システムリソースを新規のリンクリクエストに開放する。
・パケットをネットワークインターフェースレイヤと、当該レイヤよりも上位のプロトコルレイヤ（ルーティングレイヤ及び回線レイヤ）との間で授受する。
・サービス品質（ＱｏＳ）統計をモニタリングし、そしてこれらのサービス品質統計を上位のプロトコルレイヤにレポートする。
・マルチキャストを、単一ネットワークインターフェース経由の冗長なパケット送信を抑圧することによりサポートする。
・パケットサイズがネットワークインターフェースの最大送信単位（ＭＴＵ）を超える場合にフラグメンテーションを実行する。
・無効リンクを閉鎖して、システムリソースを新規のリンクリクエストに開放する。
他のプロトコルレイヤとの関連におけるリンクレイヤ
図１は、ＣｏＣｏプロトコルスィートの他のレイヤに対するリンクレイヤの関係を示している。ＣｏＣｏプロトコルスィートレイヤは、図１の暗い背景に記された斜体文字で示される。
図１は、ＣｏＣｏプロトコルスィートの他のレイヤに対するリンクレイヤの関係を示している。ＣｏＣｏプロトコルスィートレイヤは、図１の暗い背景に記された斜体文字で示される。
ルーティングレイヤ、回線レイヤ、及びネーミングシステムレイヤに関する更なる詳細は、［ＢＬＭＳ］，［ＢＭＶ］，及び［ＢＥＬＭ］にそれぞれ記載されている。ネットワークインターフェースレイヤは、イーサネットカードのような物理ネットワークデバイスに対応したオペレーティングシステムのデバイスドライバである。
リンクレイヤのコンポーネント
図２は、ＣｏＣｏプロトコルスィートにおける種々のレイヤの関係を示すブロック図である。リンクレイヤはネットワークインターフェースレイヤに接続され、そして次のコンポーネントにより構成される。
・ネットワークインターフェースに到着する着信データフレームを、ＣｏＣｏプロトコルスィートによって使用されるパケットオブジェクトに変換するプロトコル抽象化レイヤ（ＰＡＬ）。
・隣接ノードをつなぐリンクをＣｏＣｏネットワークにおいて設定するリンク設定サブレイヤ。
・データを設定リンクで転送するリンクデータサブレイヤ。
・リンク品質をモニタリングするＱｏＳハンドラー。
図２は、ＣｏＣｏプロトコルスィートにおける種々のレイヤの関係を示すブロック図である。リンクレイヤはネットワークインターフェースレイヤに接続され、そして次のコンポーネントにより構成される。
・ネットワークインターフェースに到着する着信データフレームを、ＣｏＣｏプロトコルスィートによって使用されるパケットオブジェクトに変換するプロトコル抽象化レイヤ（ＰＡＬ）。
・隣接ノードをつなぐリンクをＣｏＣｏネットワークにおいて設定するリンク設定サブレイヤ。
・データを設定リンクで転送するリンクデータサブレイヤ。
・リンク品質をモニタリングするＱｏＳハンドラー。
図３は、プロトコルのインターフェースを含むリンクレイヤプロトコルの更なる詳細を示している。図３の矢印は、インターフェースの一部である関数コールを表わす。レイヤＡからレイヤＢに向かう矢印は、レイヤＢにおけるプロシージャまたは関数がレイヤＡから呼び出されることを示す。矢印の尾の部分の円は、或る値をコーラに返す機能を示す。
リンクレイヤインターフェース
リンクレイヤインターフェースは次の関数を提供し、これらの関数をルーティングレイヤ及び回線レイヤが使用してリンクの有無を判断し、そしてパケットをリンク経由で送信し、かつ受信する。
リンクレイヤインターフェースは次の関数を提供し、これらの関数をルーティングレイヤ及び回線レイヤが使用してリンクの有無を判断し、そしてパケットをリンク経由で送信し、かつ受信する。
ＬｉｎｋＵｐ（ｌｉｎｋ）
リンクレイヤはＬｉｎｋＵｐ（ｌｉｎｋ）を呼び出して、回線レイヤ及びルーティングレイヤにリンクが開放されたことを通知する。
リンクレイヤはＬｉｎｋＵｐ（ｌｉｎｋ）を呼び出して、回線レイヤ及びルーティングレイヤにリンクが開放されたことを通知する。
ＬｉｎｋＤｏｗｎ（ｌｉｎｋ）
リンクレイヤはＬｉｎｋＤｏｗｎ（ｌｉｎｋ）を呼び出して、回線レイヤ及びルーティングレイヤにリンクが閉鎖されたことを通知する。
リンクレイヤはＬｉｎｋＤｏｗｎ（ｌｉｎｋ）を呼び出して、回線レイヤ及びルーティングレイヤにリンクが閉鎖されたことを通知する。
Ｒｅｃｅｉｖｅ（ｐａｃｋｅｔ， ｌｉｎｋ）
リンクレイヤはＲｅｃｅｉｖｅ（ｐａｃｋｅｔ， ｌｉｎｋ）を呼び出して、回線レイヤ及びルーティングレイヤに、パケットがリンク経由で到着したことを通知する。
リンクレイヤはＲｅｃｅｉｖｅ（ｐａｃｋｅｔ， ｌｉｎｋ）を呼び出して、回線レイヤ及びルーティングレイヤに、パケットがリンク経由で到着したことを通知する。
Ｓｅｎｄ（ｐａｃｋｅｔ， ｌｉｎｋ）
回線レイヤまたはルーティングレイヤはＳｅｎｄ（ｐａｃｋｅｔ， ｌｉｎｋ）を呼び出して、パケットをリンク経由で送信させる。
回線レイヤまたはルーティングレイヤはＳｅｎｄ（ｐａｃｋｅｔ， ｌｉｎｋ）を呼び出して、パケットをリンク経由で送信させる。
ＧｅｔＱｏＳ（ｌｉｎｋ）
回線レイヤまたはルーティングレイヤはＧｅｔＱｏＳ（ｌｉｎｋ）を呼び出して、所定のリンクに関連するＱｏＳ指標を取得させる。
回線レイヤまたはルーティングレイヤはＧｅｔＱｏＳ（ｌｉｎｋ）を呼び出して、所定のリンクに関連するＱｏＳ指標を取得させる。
リンクレイヤのパケットタイプ
ＰＡＬで着信データフレームを解析した後、当該レイヤはネットワークインターフェースヘッダを廃棄する。残っているデータはリンク設定パケットまたはリンクデータパケットのいずれかである。
・リンク設定パケット：リンク設定パケットは、リンクを設定するために必要な情報を含む。リンク設定パケットのパケットヘッダはリンク設定パケット全体である。リンク設定パケットには別のデータ部分が無い。リンク設定パケットはリンクレイヤ内でのみ使用される。
・リンクデータパケット：実際のユーザデータ（及び、上位のプロトコルレイヤに関連する全てのデータ）の他に、リンクデータパケットはデータパケット確認応答、データパケットフラグメンテーション、及び暗号化チェックサムをハンドリングする更に別のフィールドを含む。リンクデータパケットはルーティングレイヤ及び回線レイヤに転送される。
ＰＡＬで着信データフレームを解析した後、当該レイヤはネットワークインターフェースヘッダを廃棄する。残っているデータはリンク設定パケットまたはリンクデータパケットのいずれかである。
・リンク設定パケット：リンク設定パケットは、リンクを設定するために必要な情報を含む。リンク設定パケットのパケットヘッダはリンク設定パケット全体である。リンク設定パケットには別のデータ部分が無い。リンク設定パケットはリンクレイヤ内でのみ使用される。
・リンクデータパケット：実際のユーザデータ（及び、上位のプロトコルレイヤに関連する全てのデータ）の他に、リンクデータパケットはデータパケット確認応答、データパケットフラグメンテーション、及び暗号化チェックサムをハンドリングする更に別のフィールドを含む。リンクデータパケットはルーティングレイヤ及び回線レイヤに転送される。
プロトコル抽象化レイヤ
リンクレイヤのプロトコル抽象化レイヤ（ＰＡＬ）で、（イーサネットインターフェースまたは衛星インターフェースのような）ネットワークインターフェースに到着する着信データフレームを解析し、当該データを使用してＣｏＣｏヘッダ及びアドレス変換テーブルを作成し、次にネットワークインターフェースデータフレームのヘッダを廃棄する。ネットワークインターフェースヘッダが廃棄された後、残っているデータはリンク設定パケットまたはリンクデータパケットのいずれかである。リンクレイヤでこれらのパケットを分析し、そしてリンク設定パケットをリンク設定サブレイヤに、そしてリンクデータパケットをリンクデータサブレイヤに送信する。
リンクレイヤのプロトコル抽象化レイヤ（ＰＡＬ）で、（イーサネットインターフェースまたは衛星インターフェースのような）ネットワークインターフェースに到着する着信データフレームを解析し、当該データを使用してＣｏＣｏヘッダ及びアドレス変換テーブルを作成し、次にネットワークインターフェースデータフレームのヘッダを廃棄する。ネットワークインターフェースヘッダが廃棄された後、残っているデータはリンク設定パケットまたはリンクデータパケットのいずれかである。リンクレイヤでこれらのパケットを分析し、そしてリンク設定パケットをリンク設定サブレイヤに、そしてリンクデータパケットをリンクデータサブレイヤに送信する。
要約すると、ＰＡＬでは、
・データフレームをネットワークデバイスまたはネットワーク接続から取得する。
・関連情報を（通常、イーサネットカードのようなネットワークデバイスのデバイスドライバである）ネットワークインターフェースレイヤから取り出して格納したＣｏＣｏヘッダ及びアドレス変換テーブルを作成する。
・ネットワークインターフェースレイヤヘッダを削除し、そして廃棄する。
・変更済みパケットをリンク設定サブレイヤまたはリンクデータサブレイヤのいずれかに渡す。
・データフレームをネットワークデバイスまたはネットワーク接続から取得する。
・関連情報を（通常、イーサネットカードのようなネットワークデバイスのデバイスドライバである）ネットワークインターフェースレイヤから取り出して格納したＣｏＣｏヘッダ及びアドレス変換テーブルを作成する。
・ネットワークインターフェースレイヤヘッダを削除し、そして廃棄する。
・変更済みパケットをリンク設定サブレイヤまたはリンクデータサブレイヤのいずれかに渡す。
ＣｏＣｏヘッダ及びアドレス変換テーブル
ＣｏＣｏヘッダ及びアドレス変換テーブルは、ネットワークインターフェースレイヤのヘッダの代わりに用いられる。ＰＡＬでは、ＣｏＣｏヘッダ及びアドレス変換テーブルを、パケットをネットワークインターフェースから受信した後に作成する。フレームがいずれかの物理ネットワークインターフェースから到着すると、ＰＡＬでフレームヘッダを読み取って、ＣｏＣｏヘッダを構成し、そしてエントリを当該レイヤのアドレス変換テーブルに追加する。
ＣｏＣｏヘッダ及びアドレス変換テーブルは、ネットワークインターフェースレイヤのヘッダの代わりに用いられる。ＰＡＬでは、ＣｏＣｏヘッダ及びアドレス変換テーブルを、パケットをネットワークインターフェースから受信した後に作成する。フレームがいずれかの物理ネットワークインターフェースから到着すると、ＰＡＬでフレームヘッダを読み取って、ＣｏＣｏヘッダを構成し、そしてエントリを当該レイヤのアドレス変換テーブルに追加する。
アドレス変換テーブルはメモリにのみ格納され、そしてＰＡＬでのみ使用される。ＰＡＬで送信元アドレスをフレームヘッダから抽出し、そして当該アドレスを送信元ノードのユニバーサルノード識別子（ＵＮＩ）に関連付けて、関連付けをアドレス変換テーブルに保存する。アドレス変換テーブルはノードが使用する物理トランスポートの各タイプに対応して作成される。従って、ＵＮＩはＣｏＣｏプロトコル全体で使用される。アドレス変換テーブルは、データがネットワークインターフェースレイヤに送信される場合にのみ必要になる（ＵＮＩに関する更なる情報については［ＢＬＭＳ］を参照されたい）。
ＣｏＣｏヘッダのフォーマットは一定である−フォーマットは、パケットがどのタイプのインターフェースに到着するかどうかに関係なく同じである。ＣｏＣｏヘッダはメモリに格納され、そして上位のプロトコルレイヤで利用することができる。ヘッダの構造を図４に示すが、各フィールドのビットサイズは括弧内に与えられる。
タイプフィールドには、ＣｏＣｏヘッダに続くパケットのタイプ−リンク設定パケットまたはリンクデータパケットのいずれか−が記述される。暗号化フィールドには、パケットが暗号化されているかどうかが記述される。暗号化は、リンクが設定された後になるまで行なわれることがないので、全てのリンク設定パケットが暗号化されていない。全てのブロードキャストパケットも、複数のノードによって解読されることになるメッセージを暗号化することが難しいので暗号化されていない。パケットサイズフィールドは、ＣｏＣｏヘッダに続くパケット全体のバイトサイズである。
ＣｏＣｏノードは更に、ＣｏＣｏヘッダを物理ネットワークインターフェース経由で送信して、パケット完全性のチェック手段として機能する。ＰＡＬでＣｏＣｏヘッダを普通の方法で作成した後、結果として得られるＣｏＣｏヘッダは有線送信されているＣｏＣｏヘッダと比較チェックされる。これらのＣｏＣｏヘッダが一致しない場合、パケットは廃棄される。
ＰＡＬがサポートするトランスポート
ＰＡＬは、多数のネットワークインターフェースフォーマットをサポートし、ネットワークインターフェースフォーマットとして以下のフォーマットを挙げることができる。
・イーサネット（ＩＥＥＥ ８０２．３）
・トークンリング（ＩＥＥＥ ８０２．５）
・Ｗｉ−Ｆｉ（ＩＥＥＥ ８０２．１１）
・同期光ネットワーク（ＳＯＮＥＴ）
・非同期転送モード（ＡＴＭ）
・衛星
他のトランスポート技術では、前に列挙したネットワークインターフェースフォーマットを使用するので、リンクレイヤも以下のフォーマットをサポートする。
・インターネットプロトコル（ＩＰ）
・転送制御プロトコル（ＴＣＰ）
・ユーザデータグラムプロトコル（ＵＤＰ）
・移動体通信用グローバルシステム（ＧＳＭ）及び符号分割多重接続（ＣＤＭＡ）
・携帯デジタルパケットデータ（ＣＤＰＤ），汎用パケット無線サービス（ＧＰＲＳ）、及び１ＸＲＴＴ
ＰＡＬは、当該レイヤがモジュールにより構成されるので、他のフォーマットをサポートするように容易に拡張することができる。
ＰＡＬは、多数のネットワークインターフェースフォーマットをサポートし、ネットワークインターフェースフォーマットとして以下のフォーマットを挙げることができる。
・イーサネット（ＩＥＥＥ ８０２．３）
・トークンリング（ＩＥＥＥ ８０２．５）
・Ｗｉ−Ｆｉ（ＩＥＥＥ ８０２．１１）
・同期光ネットワーク（ＳＯＮＥＴ）
・非同期転送モード（ＡＴＭ）
・衛星
他のトランスポート技術では、前に列挙したネットワークインターフェースフォーマットを使用するので、リンクレイヤも以下のフォーマットをサポートする。
・インターネットプロトコル（ＩＰ）
・転送制御プロトコル（ＴＣＰ）
・ユーザデータグラムプロトコル（ＵＤＰ）
・移動体通信用グローバルシステム（ＧＳＭ）及び符号分割多重接続（ＣＤＭＡ）
・携帯デジタルパケットデータ（ＣＤＰＤ），汎用パケット無線サービス（ＧＰＲＳ）、及び１ＸＲＴＴ
ＰＡＬは、当該レイヤがモジュールにより構成されるので、他のフォーマットをサポートするように容易に拡張することができる。
リンク設定サブレイヤ
リンク設定サブレイヤは以下の機能を実行する。：
・他のノードの存在を認識し、そして認識を維持する。
・通信範囲内のノードへのリンクを設定する。
・各リンクに用いられるデフィー・ヘルマンキーを生成する。
・各リンクに適用される符号化方式を実装する。
・ワークトークンを計算し、そして検証してサービス拒否攻撃を防止する。
・各リンクの往復時間をモニタリングする。
・リンクが無効になる時点を判断し、そしてリンクを閉鎖する。
リンク設定サブレイヤは以下の機能を実行する。：
・他のノードの存在を認識し、そして認識を維持する。
・通信範囲内のノードへのリンクを設定する。
・各リンクに用いられるデフィー・ヘルマンキーを生成する。
・各リンクに適用される符号化方式を実装する。
・ワークトークンを計算し、そして検証してサービス拒否攻撃を防止する。
・各リンクの往復時間をモニタリングする。
・リンクが無効になる時点を判断し、そしてリンクを閉鎖する。
リンク設定サブレイヤは、反復する２フェーズプロセスをノードに関して使用して情報を授受することにより前述の機能を実現する。
リンク設定パケット
リンク設定サブレイヤは、図５に示すような、リンク設定パケットと表記される単一のパケットフォーマットを利用する。
リンク設定パケット
リンク設定サブレイヤは、図５に示すような、リンク設定パケットと表記される単一のパケットフォーマットを利用する。
リンク設定パケットは、ノードが当該ノードの存在、及び識別情報を他のノードに通告し、そして同時に他のノードに、当該ノードがこのような通告を他のノードから受信したことを通知する機構を実現する。従って、或る状況では、リンク設定パケットはハローパケットとして機能し、そして他の状況では、リンク設定パケットは確認応答またはａｃｋパケットとして機能する。
ノードをネットワーク上で動的に追加し、そして削除する操作を容易にするために、各ノードはリンク設定パケットを所定の期間でブロードキャストする。この構成によって、リンク設定パケットを、同じパケットの中のハロー及び確認応答の両方として機能させることもできる。この所定の期間はハローインターバルと呼ばれ、そして通常１秒である。確認応答は発信ハローパケットに相乗りさせる。各ノードは、ａｃｋ−ｓｅｔと表記されるノード群のセットを維持し、当該ノード群のセットから約５〜１０秒であるａｃｋ−ｉｎｔｅｒｖａｌと表記される所与の期間内にハロー受信する。
ａｃｋ−ｉｎｔｅｒｖａｌはリンクタイムアウトパラメータである。ノードＡがハローパケットをノードＢからａｃｋ−ｉｎｔｅｒｖａｌよりも長い期間の間に全く受信することがない場合、ノードＡはノードＢをノードＡのａｃｋ−ｓｅｔから削除し、そしてこの時点以降、ノードＡの発信ハローメッセージでノードＢに確認応答を送信することはない。
セキュリティ攻撃によってパケットフラッドが発生する現象を防止するために、各ノードは、全てのリンク設定パケットに含めるワークトークンを計算する。ワークトークンはワークトークン有効期間（ＷＴＶＩ）と呼ばれる期間中に有効であり、ワークトークン有効期間は通常、ハローインターバルよりも長いが確認応答区間よりも短い時間長である。ワークトークンの有効期間が満了すると（ワークトークン有効期間ＷＴＶＩに従って）、ノードは、新規のワークトークンを当該ノードの次のリンク設定パケットを送出する前に計算する必要がある。 リンクレイヤで使用する第４期間がデフィー・ヘルマンキャッシュインターバル（ＤＨＣＩ）であり、このキャッシュインターバルはワークトークン有効期間ＷＴＶＩよりも長くする必要があり、かつ確認応答区間よりも長くする必要もある。ＤＨＣＩは、ノードＡがノードＢと通信するために使用するデフィー・へルマンキーのキャッシュバージョンを保持する時間長である。デフィー・へルマンキーの計算には多くのリソースが必要となるので、ノードＢがノードＡへのリンクを再設定しようとする場合には、リンクが中断された後でもキーのキャッシュバージョンを保持しておくことは有用である。ノードＡがリンク設定パケットをノードＢからＤＨＣＩ内に受信しない場合、ノードＡはそのキーのキャッシュコピーを消去する。
リンク設定パケット−セクションによって分離され−図５に示され、破線は繰り返すことができるパケットのセクションを示し、そしてカッコ内の数字は各フィールドのビットサイズを示す。
リンク設定パケットは次のセクションを含む。
・リンク設定フィールド
・１セットの応答確認及び関連フィールド（ａｃｋ−ｓｅｔ）
・サポートされる符号化方式のリスト
・ノードの公開キー
リンク設定パケットのリンク設定セクション
図６に示すリンク設定パケットの初期固定長部分は次のフィールドにより構成される。
・リンク設定フィールド
・１セットの応答確認及び関連フィールド（ａｃｋ−ｓｅｔ）
・サポートされる符号化方式のリスト
・ノードの公開キー
リンク設定パケットのリンク設定セクション
図６に示すリンク設定パケットの初期固定長部分は次のフィールドにより構成される。
ワークトークン（１２８）：「ワークトークン」と題する節で記載されるワークトークン検証に使用されるランダム番号。ワークトークンによって、サービス拒否攻撃を防止し易くなる。ワークトークンは、ワークトークン有効期間によって決まる時間長に亘ってのみ有効であり、その後、新規のワークトークンを計算する必要がある。
ＴｉｍｅＳｔａｍｐ（６４）：ワークトークンを計算した時刻（ｕｓｔｉｍｅデータフォーマットを使用する）。このフィールドは、ハローインターバルごとではなく、ワークトークン有効期間ごとに更新される。
ＵＮＩ（６４）：このＣｏＣｏノードを固有に特定するユニバーサルノード識別子（ＵＮＩ）。このＵＮＩは、未登録のＵＮＩである。更に詳しい情報については［ＢＬＭＳ］を参照されたい。
ＨｅｌｌｏＮｕｍ（３２）：このＣｏＣｏノードが送信するリンク設定パケットごとにインクリメントするシーケンス番号。リンク設定パケットは、ハローインターバルと呼ばれる一定の期間でブロードキャストされる。
ＮｕｍＡｃｋｓ（１６）：このパケットに相乗りさせる確認応答の数。
ＮｕｍＥｎｃｏｄｉｎｇｓ（１６）：送信側ＣｏＣｏノードがサポートする符号化方式の数。
ＮｕｍＥｎｃｏｄｉｎｇｓ（１６）：送信側ＣｏＣｏノードがサポートする符号化方式の数。
リンク設定パケットの確認応答セクション
図７は、或る実施形態におけるリンク設定パケットの確認応答セクションを示すブロック図である。
図７は、或る実施形態におけるリンク設定パケットの確認応答セクションを示すブロック図である。
この一連のフィールドは、別のＣｏＣｏノードからのリンク設定パケットの受信の確認応答を含む。これらの確認応答をリンク設定パケットのリンク設定セクションに相乗りさせる。単一のリンク設定パケットに幾つかの確認応答を含めることができ、各確認応答によって、異なるＣｏＣｏノードからのリンク設定パケットの受信を確認応答する。一つのリンク設定パケットに含める確認応答の数は、リンク設定セクションのＮｕｍＡｃｋｓフィールドによって与えられる（図６参照）。各確認応答は以下の一連のフィールドにより構成される。
Ｎｏｄｅ Ａｃｋｅｄ（６４）：確認応答の送信先のノードのユニバーサルノード識別子（ＵＮＩ）。
ＨｅｌｌｏＮｕｍ Ｌａｓｔ Ｈｅａｒｄ（３２）：確認応答の送信先のノードから受信する最終パケットのＨｅｌｌｏＮｕｍ。
ＨｅｌｌｏＮｕｍ Ｌａｓｔ Ｈｅａｒｄ（３２）：確認応答の送信先のノードから受信する最終パケットのＨｅｌｌｏＮｕｍ。
Ｈｏｌｄ Ｔｉｍｅ（３２）：確認応答の送信先のノードからの最終パケットの到着からの経過時間：図１０を参照。
Ａｃｋ Ｓｉｇｎａｔｕｒｅ（６４）：このＣｏＣｏノードと、確認応答されるパケットのＣｏＣｏノードとの間で合意されたデフィー・ヘルマンキーのハッシュであり、このハッシュは、ａｃｋｓになりすます操作を防止するために使用される。使用されるハッシュ関数は、以下の「符号化方式及びセキュリティ」と題する節で説明される該当するノードペアによって合意される。
Ａｃｋ Ｓｉｇｎａｔｕｒｅ（６４）：このＣｏＣｏノードと、確認応答されるパケットのＣｏＣｏノードとの間で合意されたデフィー・ヘルマンキーのハッシュであり、このハッシュは、ａｃｋｓになりすます操作を防止するために使用される。使用されるハッシュ関数は、以下の「符号化方式及びセキュリティ」と題する節で説明される該当するノードペアによって合意される。
リンク設定パケットの符号化セクション
図８は、リンク設定パケットの符号化セクションを示すブロック図である。このセクションは一連の符号化方式フィールドを含み、一つの符号化方式フィールドが、送信元ノードがサポートする暗号化方式／ハッシュ化方式の各ペアに対応する。リンク設定パケットの符号化方式フィールドの数はリンク設定セクションのＮｕｍＥｎｃｏｄｉｎｇｓフィールドによって与えられる（図６参照）。各符号化方式フィールドは以下のサブフィールドにより構成される：
Ｅｎｃｒｙｐｔｉｏｎ（４）：暗号化方式に対応する４ビット識別子であり、この暗号化方式は、暗号化方式に関連するハッシュ化方式と一緒に符号化方式ペアとして使用される。現在サポートされている暗号化方式はＲＣ４，ＤＥＳ，３ＤＥＳ，Ｂｌｏｗｆｉｓｈ，及びＡＥＳである。
図８は、リンク設定パケットの符号化セクションを示すブロック図である。このセクションは一連の符号化方式フィールドを含み、一つの符号化方式フィールドが、送信元ノードがサポートする暗号化方式／ハッシュ化方式の各ペアに対応する。リンク設定パケットの符号化方式フィールドの数はリンク設定セクションのＮｕｍＥｎｃｏｄｉｎｇｓフィールドによって与えられる（図６参照）。各符号化方式フィールドは以下のサブフィールドにより構成される：
Ｅｎｃｒｙｐｔｉｏｎ（４）：暗号化方式に対応する４ビット識別子であり、この暗号化方式は、暗号化方式に関連するハッシュ化方式と一緒に符号化方式ペアとして使用される。現在サポートされている暗号化方式はＲＣ４，ＤＥＳ，３ＤＥＳ，Ｂｌｏｗｆｉｓｈ，及びＡＥＳである。
Ｈａｓｈ（４）：ハッシュ化方式に対応する４ビット識別子であり、このハッシュ化方式は、ハッシュ化方式に関連する符号化方式と一緒に符号化方式ペアとして使用される。現在サポートされているハッシュ化方式はＭＤ５、ＳＨＡ１，及びＲＩＰＥＭＤである。
Ｒｅｓｅｒｖｅ（８）：将来時点での使用のために確保される。
リンク設定パケットの公開キーセクション
図９は、リンク設定パケットの公開キーセクションを示すブロック図である。
リンク設定パケットの公開キーセクション
図９は、リンク設定パケットの公開キーセクションを示すブロック図である。
ＰｕｂｌｉｃＫｅｙ Ｓｉｚｅ（１６）：Ｐｕｂｌｉｃ Ｋｅｙフィールドのバイトサイズである。
Ｐｕｂｌｉｃ Ｋｅｙ（可変；普通、５１２）：Ｄｉｆｆｌｅ−Ｈｅｌｌｍａｎキー交換に使用される公開キー；「符号化方式及びセキュリティ」と題する節を参照。
Ｐｕｂｌｉｃ Ｋｅｙ（可変；普通、５１２）：Ｄｉｆｆｌｅ−Ｈｅｌｌｍａｎキー交換に使用される公開キー；「符号化方式及びセキュリティ」と題する節を参照。
往復時間及び受信品質の導出
図１０は、往復時間及び受信品質を導出する方法を示すフロー図である。
リンク設定サブレイヤによって各ノードは、
・全ての他のノードに関するノード間往復時間
・他のノードからの信号の品質
・他のノードが検出する当該各ノード自体の信号の品質
の項目を導出することができる。
図１０は、往復時間及び受信品質を導出する方法を示すフロー図である。
リンク設定サブレイヤによって各ノードは、
・全ての他のノードに関するノード間往復時間
・他のノードからの信号の品質
・他のノードが検出する当該各ノード自体の信号の品質
の項目を導出することができる。
ノードＡがノードＢとの間の往復時間を計算する場合、ノードＡは、ノードＡが設定パケットをノードＢに送信する時刻と、ノードＡがリンク設定パケットを、設定の確認応答を送信する（ｈｅｌｌｏ−ｎｕｍの値が同じであることをチェックする）ノードＢから受信する時刻との間に経過した時間に注目し、次に該当する確認応答に生じるホールド時間を減算する。
往復時間の計算の他に、リンク設定レイヤは信号品質を、当該レイヤが送信するリンク設定パケットの内、後の時点で確認応答されるリンク設定パケットの割合に基づいて求めることができる。例えば、ノードＢがノードＡから、番号１，２，３，４，．．．が付されたハローパケットを受信する場合、ノードＢは、ノードＢが強い信号をノードＡから受信していることを認識する。これとは異なり、ノードＢがノードＡから、番号４，９，１５，２３，．．．が付されたハローパケットを受信する場合、ノードＢは、ノードＡからの信号が相対的に弱いことを認識する。同様に、ノードＡが確認応答をノードＢから受信し、そしてノードＡが受信するハローパケットのシーケンス番号の間隔が長くなってしまう（例えば、５，１１，１７，２１，．．．）場合、ノードＡは、ノードＢからの信号が弱い、ノードＡからノードＢへの信号が弱い、または両方の信号ともに弱いことを認識する。
符号化方式及びセキュリティ
リンクレイヤの符号化方式及びセキュリティでは、ノード間のデフィー・ヘルマンキー交換だけでなく、ワークトークンの交換を利用して、サービス拒否攻撃を防止する。
リンクレイヤの符号化方式及びセキュリティでは、ノード間のデフィー・ヘルマンキー交換だけでなく、ワークトークンの交換を利用して、サービス拒否攻撃を防止する。
ワークトークン
不良ノードはサービス拒否攻撃をネットワークに対して次のようにして仕掛けることができる。
・不良ノードの通信範囲内のノードにリンク設定リクエストをフラッディングする。
・多数の偽ノードが存在するように見せかける。
不良ノードはサービス拒否攻撃をネットワークに対して次のようにして仕掛けることができる。
・不良ノードの通信範囲内のノードにリンク設定リクエストをフラッディングする。
・多数の偽ノードが存在するように見せかける。
これらのアクションは攻撃を構成する。なぜならば、リンク設定リクエストを受信するノードは、多くのリソースを消費する（４００ＭＨｚで動作するＸＳｃａｌｅプロセッサでは約１ミリ秒を消費する）デフィー・ヘルマンキー交換計算を実行する必要があるからである。多数の悪意のある設定リクエストが発信されている状況では、正当なノードからのリンク設定リクエストは全て、タイムアウトによって遅延する、または拒否される。
従って、リンク設定プロトコルは、ワークトークンと呼ばれる機構を使用して、リンクを設定しようとしているノードに、リソースを大量に消費する計算を強制的に実行させる。これにより、このようなサービス拒否攻撃が攻撃者にとってはコストが更に高く付くようになり、攻撃者の計算リソースによって変わるが、攻撃の確率を低くするか、または攻撃を全て防止する。
これらの事項が考慮されるので、ワークトークンの有効化がデフィー・へルマン計算の前に行なわれる。ワークトークンが無効化される場合、ノードは時間を、ワークトークンの検証よりもずっと高いコストを要する計算であるデフィー・へルマンキーの計算のために割く必要はない。
ノードＡがリンク設定パケットをノードＢに送信することができるようになる前に、ノードＡは、ノードＡがノードＡのリンク設定パケットのワークトークンフィールドに格納する有効なワークトークンＷを計算する必要がある（図６参照）。
タイムスタンプＴもリンク設定パケットに含める（図６参照）。リンク設定パケットを受信すると、ノードＢはタイムスタンプを使用してワークトークンの有効期間が満了になった（従って無効になる）かどうかを判断する。
ワークトークンアルゴリズム
以下のワークトークンアルゴリズムでは、関数ｈは、全てのＣｏＣｏノードが使用するプロトコルソースコード内に設定されるグローバルハッシュ関数である。関数ｈの出力は関数の範囲[０，ＭＡＸ]に収まるように一様に分散させる。
以下のワークトークンアルゴリズムでは、関数ｈは、全てのＣｏＣｏノードが使用するプロトコルソースコード内に設定されるグローバルハッシュ関数である。関数ｈの出力は関数の範囲[０，ＭＡＸ]に収まるように一様に分散させる。
以下のアルゴリズムのステップ３．ｂにおける値ｒは、ＭＡＸよりも小さくなるように選択される。この値ｒはネットワークプロビジョニングの時点で設定され、そして特に、このプロトコルのセキュリティと効率とのトレードオフを調整する手段として展開されるように選択することができる。このような操作を行なうのは、ステップ３．ｂがＭＡＸ／ｒの予測繰り返し数で確率論的に成功するからであり、成功するのは、関数ｈの出力が、関数の範囲に収まるように一様に分散しているからである。
以下のアルゴリズムにおいて使用される表記（Ｚ，Ｙ）は、Ｚ及びＹの２値表示の文字列連結を示す。
ワークトークン計算
ノードＡは、ノードＡが送出する全てのリンク設定パケットに有効なワークトークンが格納されていることを確認する必要がある。現在時刻と、ノードＡが送信した最も直近のパケットのタイムスタンプとの時間差がワークトークン有効期間よりも短い場合、ノードＡは最も直近のパケットを再送信する。時間差がワークトークン有効期間よりも短くはない場合、既に送信されているワークトークンはこの時点では無効であり、そしてワークトークンを、以下のステップを実行することにより再計算する必要がある。
１．ノードＡはノードＡ自体を、ノードＡのリンク設定パケットのＵＮＩフィールド（図６参照）をノードＡの名前Ｎに設定することにより確認する。
２．ノードＡはリンク設定パケットのＴｉｍｅＳｔａｍｐフィールドを現在時刻Ｔに設定する、
３．ノードＡは次に、
ａ．１２８ビットランダム番号Ｘを選択する。
ワークトークン計算
ノードＡは、ノードＡが送出する全てのリンク設定パケットに有効なワークトークンが格納されていることを確認する必要がある。現在時刻と、ノードＡが送信した最も直近のパケットのタイムスタンプとの時間差がワークトークン有効期間よりも短い場合、ノードＡは最も直近のパケットを再送信する。時間差がワークトークン有効期間よりも短くはない場合、既に送信されているワークトークンはこの時点では無効であり、そしてワークトークンを、以下のステップを実行することにより再計算する必要がある。
１．ノードＡはノードＡ自体を、ノードＡのリンク設定パケットのＵＮＩフィールド（図６参照）をノードＡの名前Ｎに設定することにより確認する。
２．ノードＡはリンク設定パケットのＴｉｍｅＳｔａｍｐフィールドを現在時刻Ｔに設定する、
３．ノードＡは次に、
ａ．１２８ビットランダム番号Ｘを選択する。
ｂ．テストしてｃ＝ｈ（Ｘ，Ｔ，Ｎ，Ｘ）＜ｒ．（コンマは連結演算を表わす）であるかどうかを調査する。
ｃ．ステップ３．ａ及び３．ｂを、結果として得られるｃが実際にｒよりも小さくなるようなＸをノードＡが見付け出すまで繰り返す。
４．ノードＡはノードＡのリンク設定パケットのワークトークンフィールドをワークトークンＷに設定し、ワークトークンＷは、ステップ３．ｃを完了させるために使用されたＸの成功値である。
ｃ．ステップ３．ａ及び３．ｂを、結果として得られるｃが実際にｒよりも小さくなるようなＸをノードＡが見付け出すまで繰り返す。
４．ノードＡはノードＡのリンク設定パケットのワークトークンフィールドをワークトークンＷに設定し、ワークトークンＷは、ステップ３．ｃを完了させるために使用されたＸの成功値である。
新規の有効なワークトークンがこの時点で計算されると、ノードＡは、Ｗ，Ｔ，及びＮの値を、パケットのリンク設定セクションの適切なフィールドに格納するリンク設定パケットを送出する。
１．１．１．１．１ ワークトークン検証
ノードＢがリンク設定パケットをノードＡから受信すると、ノードＢは、ノードＡへのリンク設定を継続する前にワークトークンが有効であることを検証する必要がある。ワークトークンの検証は、デフィー・へルマンキーの計算よりもずっと速く行なわれるのでオーバーヘッドが小さくなる。なぜならば、リンク設定パケットの全てが有効なワークトークンを含む訳ではなく、かつリソースがこれらのパケットのデフィー・へルマンキーの計算に消費されることがないからである。更に、無効なワークトークンを含む全てのリンク設定パケットを、更に処理することなく無視することにより、プロトコルは、当該プロトコルが使用するパケットの数を減らし、従ってプロトコルによって発生するトラフィックオーバーヘッド全体も小さくなる。障害を更に処理することなく無視することにより、攻撃に対する露出を減らすこともできる。なぜならば、プロトコルによるアクティビティが少なくなると、アクティビティを利用する機会が少なくなるからである。
ノードＢがリンク設定パケットをノードＡから受信すると、ノードＢは、ノードＡへのリンク設定を継続する前にワークトークンが有効であることを検証する必要がある。ワークトークンの検証は、デフィー・へルマンキーの計算よりもずっと速く行なわれるのでオーバーヘッドが小さくなる。なぜならば、リンク設定パケットの全てが有効なワークトークンを含む訳ではなく、かつリソースがこれらのパケットのデフィー・へルマンキーの計算に消費されることがないからである。更に、無効なワークトークンを含む全てのリンク設定パケットを、更に処理することなく無視することにより、プロトコルは、当該プロトコルが使用するパケットの数を減らし、従ってプロトコルによって発生するトラフィックオーバーヘッド全体も小さくなる。障害を更に処理することなく無視することにより、攻撃に対する露出を減らすこともできる。なぜならば、プロトコルによるアクティビティが少なくなると、アクティビティを利用する機会が少なくなるからである。
各ノードＢは、ノードＢが有効なリンク設定リクエストを受信した受信先の各ノードＡに関して前に計算したデフィー・へルマンキーのキャッシュを維持する。これにより、ノードＢは確実に、ノードＡに対するノードＢによる確認応答が紛失する場合に、デフィー・へルマンキーを再計算しなくても済むようになる。キャッシュされたキーを使用して、直近に廃棄されたリンクを迅速に再設定することもできる。ノードＢは最終的に、ノードＡに関してノードＢでキャッシュされたキーを、ノードＢがリンク設定パケットをノードＡから、デフィー・へルマンキャッシュインターバルよりも長い期間に亘って受信することがない場合に破棄する。
ノードＡからのリンク設定パケットに含まれるワークトークンが有効であることを検証するために、ノードＢは以下の項目を実行する：
１．ノードＢはＷ，Ｔ，及びＮを、ノードＢがノードＡから受信したリンク設定パケットのワークトークンフィールド，タイムスタンプフィールド，及びＵＮＩフィールドからそれぞれ抽出する；図６参照。
２．ノードＢは、ワークトークンの有効期間が満了になったかどうかについて、リンク設定パケットのタイムスタンプＴ、現在時刻、及びワークトークン有効期間に基づいてチェックする。
１．ノードＢはＷ，Ｔ，及びＮを、ノードＢがノードＡから受信したリンク設定パケットのワークトークンフィールド，タイムスタンプフィールド，及びＵＮＩフィールドからそれぞれ抽出する；図６参照。
２．ノードＢは、ワークトークンの有効期間が満了になったかどうかについて、リンク設定パケットのタイムスタンプＴ、現在時刻、及びワークトークン有効期間に基づいてチェックする。
ａ．ワークトークンの有効期間が満了になった場合、ノードＢはリンク設定リクエストを、ノードＡがパケットフラッド攻撃またはリプライ攻撃を、Ｗ及びＴの前の有効値を使用することにより試みる可能性があるので無視する。
ｂ．ワークトークンの有効期間が満了になっていない場合、ノードＢは検証プロセスを継続する。
３．ノードＢは、ノードＡからのキャッシュされたデフィー・へルマンキーを有しているかどうかについてチェックする。
３．ノードＢは、ノードＡからのキャッシュされたデフィー・へルマンキーを有しているかどうかについてチェックする。
ａ．ノードＡに対応するキャッシュされたキーが存在する場合、ノードＢはノードＡに、ノードＢが送出する次のリンク設定パケットで確認応答を返し、Ａｃｋ署名フィールド（図７参照）を、ノードＢのキャッシュのハッシュキーに設定する。
ｂ．ノードＡに対応するキャッシュされたキーが存在しない場合、ノードＢは検証プロセスを継続する。
４．ノードＢはｖ＝ｈ（Ｗ，Ｔ，Ｎ，Ｗ）を計算する（コンマは連結演算を表わす）。ｖの値は、ワークトークン計算（前に説明した）のステップ３．ｂにおいて計算されたｃの成功値と同じとなる必要があるので、ｖはｒよりも小さくなければならない。
４．ノードＢはｖ＝ｈ（Ｗ，Ｔ，Ｎ，Ｗ）を計算する（コンマは連結演算を表わす）。ｖの値は、ワークトークン計算（前に説明した）のステップ３．ｂにおいて計算されたｃの成功値と同じとなる必要があるので、ｖはｒよりも小さくなければならない。
ａ．ｖ≧ｒの場合、ノードＢはリンク設定リクエストを、ノードＡが有効なワークトークンを送信しておらず、従って不良ノードである可能性があるので無視する。
ｂ．ｖ＜ｒの場合、ノードＡが有効なワークトークンを送信しているので、ノードＢはリンク設定プロセスを継続する。
ｂ．ｖ＜ｒの場合、ノードＡが有効なワークトークンを送信しているので、ノードＢはリンク設定プロセスを継続する。
有効なワークトークンが検証されると、ノードＢは、ノードＢがノードＡから受信したリンク設定パケットに対して確認応答を返すことによりリンク設定プロセスを継続する状態になる。
リンク設定リクエストに対する確認応答
ノードＡが有効なワークトークンを送信したことを検証した後、ノードＢはリンク設定を継続する。ノードＢが、ノードＡとの間のノードＢのリンクに関するデフィー・へルマンキーのキャッシュ値を既に有しているということがない場合（ワークトークン検証アルゴリズムのステップ３を参照）、ノードＢは以下のステップを実行する。
１．ノードＢは、ノードＡとの間のノードＢのリンクに関するデフィー・へルマンキーを計算する。更なる情報に関しては、「デフィー・へルマンキー交換」と題する節を参照されたい。
２．ノードＢはデフィー・へルマンキーを、ノードＡを識別するＵＮＩに関連付けてキャッシュする。ノードＡは定期的に、ノードＡのリンク設定ハローパケットをブロードキャストし、そしてノードＢは、ノードＢがノードＡから受信する各ハローに対して確認応答を返すので、デフィー・へルマンキーのキャッシュバージョンを維持することが有用となる。
３．ノードＢは、暗号化関数／ハッシュ化関数ペアをリンクに関して作成する。更なる情報に関しては、「設定リンクの暗号化及びハッシュ化」と題する節を参照されたい。
４．ノードＢはノードＡに対して、ノードＢがブロードキャストする次のリンク設定パケットで確認応答を返して、Ａｃｋ署名フィールド（図７参照）を、ノードＢが計算したハッシュ化デフィー・へルマンキーに設定する。これにより、ノードＡは確認応答の認証を迅速に行なうことができ、これにより、不良ノードが、なりすましたＡｃｋを送信する現象を防止することができ、なりすました応答は、未使用リンクを開放されたままの状態とし、そして性能を悪化させるように作用する、というのは、不要な確認応答の全てをノードＡが、ノードＡのリンク設定パケットに含める必要があることになるからである。
ノードＡが有効なワークトークンを送信したことを検証した後、ノードＢはリンク設定を継続する。ノードＢが、ノードＡとの間のノードＢのリンクに関するデフィー・へルマンキーのキャッシュ値を既に有しているということがない場合（ワークトークン検証アルゴリズムのステップ３を参照）、ノードＢは以下のステップを実行する。
１．ノードＢは、ノードＡとの間のノードＢのリンクに関するデフィー・へルマンキーを計算する。更なる情報に関しては、「デフィー・へルマンキー交換」と題する節を参照されたい。
２．ノードＢはデフィー・へルマンキーを、ノードＡを識別するＵＮＩに関連付けてキャッシュする。ノードＡは定期的に、ノードＡのリンク設定ハローパケットをブロードキャストし、そしてノードＢは、ノードＢがノードＡから受信する各ハローに対して確認応答を返すので、デフィー・へルマンキーのキャッシュバージョンを維持することが有用となる。
３．ノードＢは、暗号化関数／ハッシュ化関数ペアをリンクに関して作成する。更なる情報に関しては、「設定リンクの暗号化及びハッシュ化」と題する節を参照されたい。
４．ノードＢはノードＡに対して、ノードＢがブロードキャストする次のリンク設定パケットで確認応答を返して、Ａｃｋ署名フィールド（図７参照）を、ノードＢが計算したハッシュ化デフィー・へルマンキーに設定する。これにより、ノードＡは確認応答の認証を迅速に行なうことができ、これにより、不良ノードが、なりすましたＡｃｋを送信する現象を防止することができ、なりすました応答は、未使用リンクを開放されたままの状態とし、そして性能を悪化させるように作用する、というのは、不要な確認応答の全てをノードＡが、ノードＡのリンク設定パケットに含める必要があることになるからである。
デフィー・へルマンキー交換
デフィー・へルマンキー交換は、リンクレイヤのセキュリティ及び符号化のための一つの構成要素であるので、この節では、プロセスを簡単に概括する。
デフィー・へルマンキー交換は、リンクレイヤのセキュリティ及び符号化のための一つの構成要素であるので、この節では、プロセスを簡単に概括する。
ノードＡ及びＢは素数ｐ、及びｐを法とする原始元ｇを共有する（値ｐ及びｇは各デバイスにプロビジョニング時に供給され、そして公開することができる）。ノードＡは秘密キーαを選択する。ノードＢは秘密キーβを選択する（α及びβはそれぞれ１〜ｐ−１の範囲の値である）。ＣｏＣｏノードには秘密キーをプロビジョニング時に供給することができる、またはＣｏＣｏノードは秘密キーをスタートアップ時に、幾つかの標準的な方法のいずれかによって選択することができる（［Ｓ］の「キーの生成」と題する節を参照）。２つのノードの間で交換されるキーは以下のようにして計算される。
１．ノードＡはノードＢに、ノードＡの公開キーを送信する−値ＰＡ＝ｇα（ノードＡからノードＢへのリンク設定ハローパケットで公開キーフィールドに格納して送信される；図９参照）
２．ノードＢはノードＡに、ノードＢの公開キーを送信する−値ＰＢ＝ｇβ（ノードＢからノードＡへのリンク設定ハローパケットに乗せ、公開キーフィールドに格納して送信される；図９参照）
３．ノードＡは、（ＰＢ）α＝（ｇβ）αを計算する。
４．ノードＢは、（ＰＡ）β＝（ｇα）βを計算する。
５．ステップ３及び４から得られるこれらの２つの値は同じであるので、この同じ値はｋＤＨ（ＡＢ）と表記することができる、または前後関係が理解できる場合には単にｋと表記することができる。この値はノードＡ及びＢの両方に認識され、かつ他のどのノードにも認識されることがない。なぜならば、αをｇαから導出する操作は計算上、実行不可能である（［Ｓ］を参照）。従って、ノードＡ及びＢはαを、ノードＡとＢとの間のリンクで送信される全てのデータに関してこれらのノードが使用することになる暗号化方法の秘密キーとして使用することができる（「設定リンクの暗号化及びハッシュ化」と題する節を参照されたい）。
１．ノードＡはノードＢに、ノードＡの公開キーを送信する−値ＰＡ＝ｇα（ノードＡからノードＢへのリンク設定ハローパケットで公開キーフィールドに格納して送信される；図９参照）
２．ノードＢはノードＡに、ノードＢの公開キーを送信する−値ＰＢ＝ｇβ（ノードＢからノードＡへのリンク設定ハローパケットに乗せ、公開キーフィールドに格納して送信される；図９参照）
３．ノードＡは、（ＰＢ）α＝（ｇβ）αを計算する。
４．ノードＢは、（ＰＡ）β＝（ｇα）βを計算する。
５．ステップ３及び４から得られるこれらの２つの値は同じであるので、この同じ値はｋＤＨ（ＡＢ）と表記することができる、または前後関係が理解できる場合には単にｋと表記することができる。この値はノードＡ及びＢの両方に認識され、かつ他のどのノードにも認識されることがない。なぜならば、αをｇαから導出する操作は計算上、実行不可能である（［Ｓ］を参照）。従って、ノードＡ及びＢはαを、ノードＡとＢとの間のリンクで送信される全てのデータに関してこれらのノードが使用することになる暗号化方法の秘密キーとして使用することができる（「設定リンクの暗号化及びハッシュ化」と題する節を参照されたい）。
デフィー・へルマンキー交換後の識別情報の継続性
リンク設定パケット及びデフィー・へルマンキーをノードＡとＢとの間で交換した後、各ノードは、他方のノードが有効な秘密キーを持っていたはずであることを認識する。次に、キーＫＤＨ（ＡＢ）が、このリンクが使用されるセッション全体を通じて使用されるので、一旦セッションが始まると介入者攻撃が行なわれることがない。いずれの介入者攻撃も、リンク設定の前に仕掛けられているはずであり、リンクの寿命の間は継続して行なわれるはずである。デフィー・へルマンキー交換によって、識別情報の継続性が保証される；すなわち、一旦、或るノードが通信を或るリンクで開始すると、同じノードとの通信が、リンクセッションの期間の間は保証される。
リンク設定パケット及びデフィー・へルマンキーをノードＡとＢとの間で交換した後、各ノードは、他方のノードが有効な秘密キーを持っていたはずであることを認識する。次に、キーＫＤＨ（ＡＢ）が、このリンクが使用されるセッション全体を通じて使用されるので、一旦セッションが始まると介入者攻撃が行なわれることがない。いずれの介入者攻撃も、リンク設定の前に仕掛けられているはずであり、リンクの寿命の間は継続して行なわれるはずである。デフィー・へルマンキー交換によって、識別情報の継続性が保証される；すなわち、一旦、或るノードが通信を或るリンクで開始すると、同じノードとの通信が、リンクセッションの期間の間は保証される。
設定リンクの暗号化及びハッシュ化
各ノードは、当該ノードがサポートする符号化方式の番号付きリストを維持する。リスト中の各符号化方式は、ハッシュ化関数とペアリングされる暗号化方式を表わす。或るノードがリンク設定パケットを送信する場合、当該ノードは、このリストに現われる符号化方式をパケットの符号化セクションに格納する（図５及び図８を参照）。符号化方式はリンク設定パケットに、これらの符号化方式が当該ノードの番号付きリストに現われる順番と同じ順番で現われる。
各ノードは、当該ノードがサポートする符号化方式の番号付きリストを維持する。リスト中の各符号化方式は、ハッシュ化関数とペアリングされる暗号化方式を表わす。或るノードがリンク設定パケットを送信する場合、当該ノードは、このリストに現われる符号化方式をパケットの符号化セクションに格納する（図５及び図８を参照）。符号化方式はリンク設定パケットに、これらの符号化方式が当該ノードの番号付きリストに現われる順番と同じ順番で現われる。
ノードＡがリンク設定（ハロー）パケットをノードＢに送信し、そしてノードＢがリンク設定確認応答パケットをノードＡに送信した後、ノードＡ及びＢはそれぞれ、ペアリングされ、他方のノードがサポートし、そしてノードの意思に従って順番付けされた暗号化方式及びハッシュ関数のリストを有する。ノードＡ及びＢはそれぞれ、以下のステップを実行して、これらの符号化方式の内のいずれの符号化方式を新規に設定されたＡ−Ｂリンクで使用すべきかについて判断する。
１．ノードＡまたはノードＢのいずれの符号化器が優先されるかを判断する（以下の節を参照）。
２．優先される符号化器のリストの中で最も優先度が高く、かつ他のノードのリストにも現われる符号化方式を選択する。一致する符号化方式が見つからない場合、通信が、暗号化されていないこのリンクで行なわれる。（セキュリティ要件によって、データを暗号化されていないリンクで送信してはならない場合、データ送信に使用される回線に、暗号化されていないリンクを決して含めてはならない；更なる情報については［ＢＭＶ］を参照されたい）。
１．ノードＡまたはノードＢのいずれの符号化器が優先されるかを判断する（以下の節を参照）。
２．優先される符号化器のリストの中で最も優先度が高く、かつ他のノードのリストにも現われる符号化方式を選択する。一致する符号化方式が見つからない場合、通信が、暗号化されていないこのリンクで行なわれる。（セキュリティ要件によって、データを暗号化されていないリンクで送信してはならない場合、データ送信に使用される回線に、暗号化されていないリンクを決して含めてはならない；更なる情報については［ＢＭＶ］を参照されたい）。
このリンク符号化方式選択アルゴリズムでは、各参加ノードが単一のパケットのみを受信することが要求されるので、このアルゴリズムは非常に効率的である。
優先される符号化器を決定するアルゴリズム
このアルゴリズムは決定論的プロセスであり、このプロセスによって、ノードＡ及びＢの両方が結果について合意することにより結論を出す。ノードＡ及びＢはこのアルゴリズムを、（ＰＡ−ＰＢ）をｐで割ったときの余り、及び（ＰＢ−ＰＡ）をｐで割ったときの余りを比較することにより実行する。前者の方が大きい場合、ノードＡの符号化器が優先され；後者の方が大きい場合、ノードＢの符号化器が優先される。この場合、ＰＡ及びＰＢは、それぞれノードＡ及びＢのデフィー・へルマン公開キーであり、そしてｐは法となる素数であり、この素数を使用してデフィー・へルマン計算を行なう。このアルゴリズムは決定論的であるので、ノードＡ及びＢの両方が、優先される同じ符号化器を計算により求めることに注目されたい。
優先される符号化器を決定するアルゴリズム
このアルゴリズムは決定論的プロセスであり、このプロセスによって、ノードＡ及びＢの両方が結果について合意することにより結論を出す。ノードＡ及びＢはこのアルゴリズムを、（ＰＡ−ＰＢ）をｐで割ったときの余り、及び（ＰＢ−ＰＡ）をｐで割ったときの余りを比較することにより実行する。前者の方が大きい場合、ノードＡの符号化器が優先され；後者の方が大きい場合、ノードＢの符号化器が優先される。この場合、ＰＡ及びＰＢは、それぞれノードＡ及びＢのデフィー・へルマン公開キーであり、そしてｐは法となる素数であり、この素数を使用してデフィー・へルマン計算を行なう。このアルゴリズムは決定論的であるので、ノードＡ及びＢの両方が、優先される同じ符号化器を計算により求めることに注目されたい。
リンクステート
図１１は利用可能なリンクステートを示すステート図である。
それぞれのノードがリンクステートテーブルを保持し、リンクステートテーブルは、それぞれのノードが受信を行なった受信先の各ノードに対応するエントリを含み、エントリは次の項目を含む：
・当該ノードと通信するために使用されるデフィー・へルマンキー（「符号化方式及びセキュリティ」と題する節を参照）。
・それぞれのノードが当該ノードから受信した最後のｈｅｌｌｏ−ｎｕｍ。
・それぞれのノードが当該ノードから受信した最後の確認応答に含まれるｈｅｌｌｏ−ｎｕｍ。
図１１は利用可能なリンクステートを示すステート図である。
それぞれのノードがリンクステートテーブルを保持し、リンクステートテーブルは、それぞれのノードが受信を行なった受信先の各ノードに対応するエントリを含み、エントリは次の項目を含む：
・当該ノードと通信するために使用されるデフィー・へルマンキー（「符号化方式及びセキュリティ」と題する節を参照）。
・それぞれのノードが当該ノードから受信した最後のｈｅｌｌｏ−ｎｕｍ。
・それぞれのノードが当該ノードから受信した最後の確認応答に含まれるｈｅｌｌｏ−ｎｕｍ。
それぞれのノードは、それぞれのノードが受信した受信先の各ノードに関してステートマシンを維持する。ノードＡのステートマシンは、ノードＢとの間のノードＡのリンクのステートを管理し、そしてＡ−Ｂリンクステートマシンと呼ばれる。ノードＡのＡ−Ｂリンクステートマシンは、４つのステートの内の一つのステートになることができる（図１１参照）：
・Ｂｌａｎｋ：ノードＡはノードＢに気付いていない。
・０−ｗａｙ：ノードＡはノードＢに気付いているが、リンク設定ハローをノードＢから受信していない（ノードＡはノードＢを認識するが、ノードＡはノードＢからの受信を行なっていない）。
・１−ｗａｙ：ノードＡはリンク設定ハローをノードＢから受信しているが、確認応答をノードＢから受信していない（ノードＡはノードＢからの受信を行なっているが、ノードＡは、ノードＢがノードＡからの受信を行なっているかどうかを認識していない）。
・２−ｗａｙ：ノードＡはリンク設定ハローをノードＢから受信しており、更に確認応答をノードＢから受信している（ノードＡはノードＢからの受信を行ない、そしてノードＡは、ノードＢもノードＡからの受信を行なっていることを認識している）。
・Ｂｌａｎｋ：ノードＡはノードＢに気付いていない。
・０−ｗａｙ：ノードＡはノードＢに気付いているが、リンク設定ハローをノードＢから受信していない（ノードＡはノードＢを認識するが、ノードＡはノードＢからの受信を行なっていない）。
・１−ｗａｙ：ノードＡはリンク設定ハローをノードＢから受信しているが、確認応答をノードＢから受信していない（ノードＡはノードＢからの受信を行なっているが、ノードＡは、ノードＢがノードＡからの受信を行なっているかどうかを認識していない）。
・２−ｗａｙ：ノードＡはリンク設定ハローをノードＢから受信しており、更に確認応答をノードＢから受信している（ノードＡはノードＢからの受信を行ない、そしてノードＡは、ノードＢもノードＡからの受信を行なっていることを認識している）。
ノードＡはリンク設定データパケットをノードＢに、Ａ−Ｂリンクステートマシンがステート２−ｗａｙになっているときにのみ送信する。
ＭをノードＡのＡ−Ｂリンクステートマシンとする。ステートマシンＭは、以下の６つの態様の内の一つの態様で遷移することができる。
１．Ｍがステートｂｌａｎｋまたは０−ｗａｙであり、かつノードＡがリンク設定ハローパケットをノードＢから受信する場合、次のようになる。
・Ｍは、
・ステート１−ｗａｙ：ノードＢからのリンク設定パケットがノードＡに対する確認応答を含まない場合、
・ステート２−ｗａｙ：ノードＢからのリンク設定パケットが更に、ノードＡに対する確認応答を含む場合（この状態は、例えばノードＡがノードＢとの間のリンク設定を開始した場合に生じる）、
のステートの内の一つのステートに移行する。
・ノードＡ：
・ワークトークンを有効にする、
・暗号化／ハッシュ化関数ペアをリンクに関して作成する、
・デフィー・へルマンキーを計算し、そしてキャッシュする（キーが既にキャッシュされていることがない場合）、
・ノードＢを、ノードＢの確認応答リストに追加する、
２．Ｍがステート１−ｗａｙであり、かつノードＡがノードＡ自体に関するリンク設定確認応答をノードＢから受信する場合、次のようになる。
・Ｍはステート２−ｗａｙに移行する。
３．Ｍがステート２−ｗａｙであり、かつノードＡがノードＡ自体に関するリンク設定確認応答をノードＢから、確認応答インターバルよりも長い期間に亘って受信しない場合、次のようになる。
・Ｍはステート１−ｗａｙに移行する。
４．Ｍがステート１−ｗａｙまたは２−ｗａｙであり、かつノードＡがリンク設定ハローをノードＢから、確認応答インターバルよりも長い期間に亘って受信しない場合、次のようになる。
・Ｍはステート０−ｗａｙに移行する。
・ノードＡはノードＢを、ノードＡの確認応答リストから削除する。
５．Ｍがステート０−ｗａｙであり、かつノードＡのデフィー・へルマンキャッシュインターバルが満了すると、次のようになる。
・Ｍはステートｂｌａｎｋに移行する。
・ノードＡはノードＢに対応するデフィー・へルマンキーをノードＡのキャッシュから削除する。
６．全てのステートにおいて、ノードＡはハローインターバルごとに、（増分された）ｈｅｌｌｏ−ｎｕｍ、タイムスタンプ、及びワークトークンを含むリンク設定パケットと、そして最後の確認応答インターバルにノードＡが受信を行なった受信先の各ノードに対する確認応答と、を送信する（確認応答はノードＡのリンクステートテーブルにエントリを有する）。
ＭをノードＡのＡ−Ｂリンクステートマシンとする。ステートマシンＭは、以下の６つの態様の内の一つの態様で遷移することができる。
１．Ｍがステートｂｌａｎｋまたは０−ｗａｙであり、かつノードＡがリンク設定ハローパケットをノードＢから受信する場合、次のようになる。
・Ｍは、
・ステート１−ｗａｙ：ノードＢからのリンク設定パケットがノードＡに対する確認応答を含まない場合、
・ステート２−ｗａｙ：ノードＢからのリンク設定パケットが更に、ノードＡに対する確認応答を含む場合（この状態は、例えばノードＡがノードＢとの間のリンク設定を開始した場合に生じる）、
のステートの内の一つのステートに移行する。
・ノードＡ：
・ワークトークンを有効にする、
・暗号化／ハッシュ化関数ペアをリンクに関して作成する、
・デフィー・へルマンキーを計算し、そしてキャッシュする（キーが既にキャッシュされていることがない場合）、
・ノードＢを、ノードＢの確認応答リストに追加する、
２．Ｍがステート１−ｗａｙであり、かつノードＡがノードＡ自体に関するリンク設定確認応答をノードＢから受信する場合、次のようになる。
・Ｍはステート２−ｗａｙに移行する。
３．Ｍがステート２−ｗａｙであり、かつノードＡがノードＡ自体に関するリンク設定確認応答をノードＢから、確認応答インターバルよりも長い期間に亘って受信しない場合、次のようになる。
・Ｍはステート１−ｗａｙに移行する。
４．Ｍがステート１−ｗａｙまたは２−ｗａｙであり、かつノードＡがリンク設定ハローをノードＢから、確認応答インターバルよりも長い期間に亘って受信しない場合、次のようになる。
・Ｍはステート０−ｗａｙに移行する。
・ノードＡはノードＢを、ノードＡの確認応答リストから削除する。
５．Ｍがステート０−ｗａｙであり、かつノードＡのデフィー・へルマンキャッシュインターバルが満了すると、次のようになる。
・Ｍはステートｂｌａｎｋに移行する。
・ノードＡはノードＢに対応するデフィー・へルマンキーをノードＡのキャッシュから削除する。
６．全てのステートにおいて、ノードＡはハローインターバルごとに、（増分された）ｈｅｌｌｏ−ｎｕｍ、タイムスタンプ、及びワークトークンを含むリンク設定パケットと、そして最後の確認応答インターバルにノードＡが受信を行なった受信先の各ノードに対する確認応答と、を送信する（確認応答はノードＡのリンクステートテーブルにエントリを有する）。
リンクデータサブレイヤ
リンクデータサブレイヤは、データをノードから次々に設定リンクを経由して取得し、データフローを管理し、遅延及び往復時間のようなＱｏＳ測定値をモニタリングし、そして圧縮及びフラグメンテーションを実行する役割を担う。
リンクデータサブレイヤは、データをノードから次々に設定リンクを経由して取得し、データフローを管理し、遅延及び往復時間のようなＱｏＳ測定値をモニタリングし、そして圧縮及びフラグメンテーションを実行する役割を担う。
上位レイヤのパケットタイプ
リンク設定パケットではないパケットは必ずリンクレイヤで、上位プロトコルレイヤ宛てのデータとして処理され、ＣｏＣｏプロトコルでは、これらの上位プロトコルレイヤは、ルーティングレイヤ、回線レイヤ、及びネーミングシステムレイヤを含む。
・クラスタリングパケットは、クラスター、多くの効率的なルーティングを可能にするＣｏＣｏノードへの再帰的分解に関連する情報を含む（［ＢＬＭＳ］を参照）。
・広告パケットは、ノードに到達するためのコストに関する情報を含む（［ＢＬＭＳ］を参照）。
・回線制御パケットは、専用のエンドツーエンド通信経路である回線の設定及び維持に関する情報を含む（［ＢＭＶ］を参照）。
リンク設定パケットではないパケットは必ずリンクレイヤで、上位プロトコルレイヤ宛てのデータとして処理され、ＣｏＣｏプロトコルでは、これらの上位プロトコルレイヤは、ルーティングレイヤ、回線レイヤ、及びネーミングシステムレイヤを含む。
・クラスタリングパケットは、クラスター、多くの効率的なルーティングを可能にするＣｏＣｏノードへの再帰的分解に関連する情報を含む（［ＢＬＭＳ］を参照）。
・広告パケットは、ノードに到達するためのコストに関する情報を含む（［ＢＬＭＳ］を参照）。
・回線制御パケットは、専用のエンドツーエンド通信経路である回線の設定及び維持に関する情報を含む（［ＢＭＶ］を参照）。
リンクデータパケット
リンク設定パケットとは異なり、リンクデータパケットはユーザデータを含む。データの長さは、パケットヘッダ中では規定されない。なぜならば、全てのパケット長は、プロトコル抽象化レイヤで作られたＣｏＣｏヘッダに含まれるからである（図４参照）。各データパケットのＣｏＣｏヘッダはノードのメモリに格納されるので、当該ヘッダには、パケットデータを使用することになる上位レベルプロトコルが容易にアクセスすることができる。
リンク設定パケットとは異なり、リンクデータパケットはユーザデータを含む。データの長さは、パケットヘッダ中では規定されない。なぜならば、全てのパケット長は、プロトコル抽象化レイヤで作られたＣｏＣｏヘッダに含まれるからである（図４参照）。各データパケットのＣｏＣｏヘッダはノードのメモリに格納されるので、当該ヘッダには、パケットデータを使用することになる上位レベルプロトコルが容易にアクセスすることができる。
データパケットをノードの間で送信することができる前に、リンクをノードＡとノードＢとの間に設定する必要がある。従って、ノードＡ及びＢはリンク設定パケットを授受し、そしてこれらのノードのリンクに固有のデフィー・へルマンキーｋＤＨ（ＡＢ）を計算することになる（「デフィー・へルマンキー交換」と題する節を参照）。ノードＡ及びＢは更に、Ａ−Ｂリンクに固有のハッシュ関数ｈＡＢ、及び暗号化方式ｅＡＢについて合意することになる（「設定リンクの暗号化及びハッシュ化」を参照）。
データパケットコンテンツ全体が関数ｅＡＢで暗号化される。“ｎｏｎｅ”が暗号化方式の内の一つの暗号化方式であるので、ノードＡ及びＢが共に“ｎｏｎｅ”を暗号化方式として合意した場合、ノードＡ及びＢの各ノードは、送信時に暗号化を試みず、かつ受信時に解読を試みないことを認識する。
リンクデータパケット−セクションによって分離され−図１２に示され、破線は繰り返すことができるパケットのセクションを示し、そして括弧内の数字はフィールドサイズをビット単位で示している。
リンクデータパケットは以下のセクションを含む。
・データパケットをマルチキャストするときに使用されるフィールド
・データパケットのセキュアチェックサムとして利用される署名
・各データパケットに固有の情報
・パケットをフラグメント化する必要がある場合にデータを再構成することができるようなフラグメンテーション情報
・受信したデータパケットに対する一連の確認応答
・確認応答されるパケットの平均ホールド時間
・上位プロトコルレイヤで処理されることになる、またはネットワークインターフェースレイヤに送信されることになる実際のデータ。
・データパケットをマルチキャストするときに使用されるフィールド
・データパケットのセキュアチェックサムとして利用される署名
・各データパケットに固有の情報
・パケットをフラグメント化する必要がある場合にデータを再構成することができるようなフラグメンテーション情報
・受信したデータパケットに対する一連の確認応答
・確認応答されるパケットの平均ホールド時間
・上位プロトコルレイヤで処理されることになる、またはネットワークインターフェースレイヤに送信されることになる実際のデータ。
リンクデータパケットのマルチキャストセクション
図１３は、マルチキャスト処理を示すブロック図である。リンクレイヤプロトコルはマルチキャストをサポートする。マルチキャストをサポートすることによって、単一の送信元から複数の送信先に送信されるデータの送信を冗長にならないように行なうことができ、これは、送信元から送信先に達するリンクがインターフェースを共有する場合に、データパケットのコピーが一つだけ、ブロードキャストインターフェースを経由して送信されることを意味する。例えば、ノードＡが図１３に示すように、ノードＢ及びＣに達するリンクを同じ無線インターフェースを使用して持っていると仮定する。同じパケットをノードＢ及びＣの両方に送信するために、ノードＡはパケットを、インターフェースを経由して１回だけブロードキャストする。
図１３は、マルチキャスト処理を示すブロック図である。リンクレイヤプロトコルはマルチキャストをサポートする。マルチキャストをサポートすることによって、単一の送信元から複数の送信先に送信されるデータの送信を冗長にならないように行なうことができ、これは、送信元から送信先に達するリンクがインターフェースを共有する場合に、データパケットのコピーが一つだけ、ブロードキャストインターフェースを経由して送信されることを意味する。例えば、ノードＡが図１３に示すように、ノードＢ及びＣに達するリンクを同じ無線インターフェースを使用して持っていると仮定する。同じパケットをノードＢ及びＣの両方に送信するために、ノードＡはパケットを、インターフェースを経由して１回だけブロードキャストする。
多くの受信側が同じブロードキャストリンクを共有する状態でメッセージをマルチキャストする場合、マルチキャストをサポートすることは、帯域利用率が大幅に低下することを意味する。しかしながら、マルチキャストの受信側は異なるデフィー・へルマンキーを使用して、送信元ノードに達する受信側のリンク上でデータを暗号化するので、マルチキャストデータパケットは暗号化されない。図１４は、リンクデータパケットのマルチキャストセクションを示している；このセクションはユニキャストデータパケットには設けられない。
送信先セットを使用してマルチキャスト効率を高める
図１４は、リンクデータパケットの送信先セットセクションを示すブロック図である。マルチキャストパケットを送信する前に、或るノードは、どのノードがブロードキャストデータの所望の受信側であるかを特定する必要がある。所望の各受信側に関して、当該或るノードは署名を計算し、そして発信パケットに追加する（「リンクデータパケットの署名セクション」を参照）。更に、ブロードキャスト送信ノードは、２４ビットのハッシュ値を所望の受信側のＵＮＩの連結に基づいて生成する。このハッシュ値をリンクデータパケットのＤｅｓｔＳｅｔＨａｓｈフィールドに織り込む（図１４参照）。ＤｅｓｔＳｅｔＨａｓｈ値は、ブロードキャストパケットを受信するノード群が、これらのノードが所望の受信側の内のいずれかの受信側であるかどうかを判断するための迅速な手段となる。
図１４は、リンクデータパケットの送信先セットセクションを示すブロック図である。マルチキャストパケットを送信する前に、或るノードは、どのノードがブロードキャストデータの所望の受信側であるかを特定する必要がある。所望の各受信側に関して、当該或るノードは署名を計算し、そして発信パケットに追加する（「リンクデータパケットの署名セクション」を参照）。更に、ブロードキャスト送信ノードは、２４ビットのハッシュ値を所望の受信側のＵＮＩの連結に基づいて生成する。このハッシュ値をリンクデータパケットのＤｅｓｔＳｅｔＨａｓｈフィールドに織り込む（図１４参照）。ＤｅｓｔＳｅｔＨａｓｈ値は、ブロードキャストパケットを受信するノード群が、これらのノードが所望の受信側の内のいずれかの受信側であるかどうかを判断するための迅速な手段となる。
或るノードがブロードキャストパケットを受信すると、当該ノードは、受信パケットのＤｅｓｔＳｅｔＨａｓｈフィールドを、既に受信しているＤｅｓｔＳｅｔＨａｓｈ値のテーブルと比較する。テーブルでは、ＤｅｓｔＳｅｔＨａｓｈを、パケットに格納されて送信される一連の署名の中の当該ノードの署名の位置と相互参照する。ノードが所望の受信側ではない場合、署名位置は当該ＤｅｓｔＳｅｔＨａｓｈ値に関して０となり、そしてノードはパケットを廃棄することができる。
受信パケットのＤｅｓｔＳｅｔＨａｓｈフィールドがテーブルに含まれない場合、ノードは、当該ノードの署名をパケットに関して計算し（「リンクデータパケットの署名セクション」を参照）、そして当該ノードの署名を、パケットに付加される複数の署名（これらの署名は所望の受信側を示す）の各署名と比較する。ノードが一致することを確認する場合、当該ノードはＤｅｓｔＳｅｔＨａｓｈ値及び署名位置を既知のＤｅｓｔＳｅｔＨａｓｈ値から成る当該ノードのテーブルに加える。署名の一致が確認されない場合、ＤｅｓｔＳｅｔＨａｓｈ値をテーブルに、署名位置を０とすることにより加え、当該ノードが、このＤｅｓｔＳｅｔＨａｓｈを格納するブロードキャストパケットの所望の受信側の内の一つの受信側ではないことを表示する。次に、ノードは当該パケットを廃棄する。
署名はパケット完全性のチェックサムとしても機能するので、不完全なデータを含むパケットは、データが完全な場合の該当する同じパケットとは異なる署名を有することになる。このような不完全なパケットが、所望の受信側に新規のＤｅｓｔＳｅｔＨａｓｈ値を含む形で到着した場合、所望の受信側は一致する署名を全く確認することができないので、このＤｅｓｔＳｅｔＨａｓｈ値が、このノード（パケットを受信したノード）が所望の受信ノードではないことを示していると間違って結論付けることになる。従って、このノードは、このＤｅｓｔＳｅｔＨａｓｈ値を有し、かつこの時点以降に到着する全てのブロードキャストパケットを間違って無視してしまう。この現象は、ネットワークインターフェースレベルの一部であるメディアアクセスコントロール（ＭＡＣ）レベルで行なわれるチェックサムを利用して、パケットの完全性を確保することにより回避することができる。
リンクデータパケットのマルチキャストセクションに含まれるフィールド
ＮｕｍＳｉｇｓ（８）：パケットに組み込まれる署名の数。この数は、１〜２５５の範囲である。個別の署名は、マルチキャストデータパケットの所望の各受信側に関して生成される（「リンクデータパケットの署名セクション」を参照）。このフィールドはマルチキャストデータパケットにのみ含まれる。当該フィールドはユニキャストデータパケットには含まれない。
ＮｕｍＳｉｇｓ（８）：パケットに組み込まれる署名の数。この数は、１〜２５５の範囲である。個別の署名は、マルチキャストデータパケットの所望の各受信側に関して生成される（「リンクデータパケットの署名セクション」を参照）。このフィールドはマルチキャストデータパケットにのみ含まれる。当該フィールドはユニキャストデータパケットには含まれない。
ＤｅｓｔＳｅｔＨａｓｈ（２４）：一連の所望の送信先ノードのハッシュ値に基づいて計算される一意の値を含む。このフィールドはマルチキャストデータパケットにのみ含まれる。当該フィールドはユニキャストデータパケットには含まれない。
リンクデータパケットの署名セクション
リンクデータパケットの署名セクションは、パケットデータのセキュアチェックサムとして機能し、更にデータ送信側の認証に利用される。データパケットの送信側であるノードＡは、データのハッシュ値、及び受信側に使用されるデフィー・へルマンキー−ｈ（ｋ，Ｄ，ｋ）−を計算し、そしてハッシュ値及びキーをリンクデータパケットヘッダのＳｉｇフィールドに格納する。ノードＢがパケットを受信すると、当該ノードはハッシュ関数ｈを文字列ｋ，Ｄ，ｋに適用し、そして結果がＳｉｇフィールドの内容に一致することを検証する。２つが一致する場合、ノードＢは、到着したデータが破損していない確率が高い（ｈ（ｋ，Ｄ，ｋ）がチェックサムとして表示されるので）ことを認識し、そして当該ノードは更に、（ノードＡのみがｋの値を認識しているので）データがノードＡから到着しているはずであることを認識する。
リンクデータパケットの署名セクションは、パケットデータのセキュアチェックサムとして機能し、更にデータ送信側の認証に利用される。データパケットの送信側であるノードＡは、データのハッシュ値、及び受信側に使用されるデフィー・へルマンキー−ｈ（ｋ，Ｄ，ｋ）−を計算し、そしてハッシュ値及びキーをリンクデータパケットヘッダのＳｉｇフィールドに格納する。ノードＢがパケットを受信すると、当該ノードはハッシュ関数ｈを文字列ｋ，Ｄ，ｋに適用し、そして結果がＳｉｇフィールドの内容に一致することを検証する。２つが一致する場合、ノードＢは、到着したデータが破損していない確率が高い（ｈ（ｋ，Ｄ，ｋ）がチェックサムとして表示されるので）ことを認識し、そして当該ノードは更に、（ノードＡのみがｋの値を認識しているので）データがノードＡから到着しているはずであることを認識する。
ハッシュ値の折り返し
図１５は、ハッシュ値を折り返す方法を示すブロック図である。標準のハッシュ関数の出力−−例えば、ＭＤ−５−−は、１２８ビットハッシュ値である。このハッシュ値を、折り返しと呼ばれるプロセスによって折り返して３２ビットの値にする。１２８ビットハッシュ値ｈ１２８を３２ビットの値ｈ３２に折り返すために、排他的論理和演算子をビットごとに、ｈ１２８の４つの３２ビットの部分文字列に適用する。更に正確には：
図１５は、ハッシュ値を折り返す方法を示すブロック図である。標準のハッシュ関数の出力−−例えば、ＭＤ−５−−は、１２８ビットハッシュ値である。このハッシュ値を、折り返しと呼ばれるプロセスによって折り返して３２ビットの値にする。１２８ビットハッシュ値ｈ１２８を３２ビットの値ｈ３２に折り返すために、排他的論理和演算子をビットごとに、ｈ１２８の４つの３２ビットの部分文字列に適用する。更に正確には：
この様子を更に図式的に見るために、ｈ１２８が図１５の最上部に示す文字列であると仮定する。図１５の４つの３２ビットの文字列の積層構造として示される４つの３２ビットの部分文字列を並べ直すことにより、単一の３２ビットハッシュ値を、各コラムに含まれる４ビットをビットごとに排他的論理和演算した結果として取得することができる。ｈ１２８における２９６個の異なるハッシュ値を折り返してｈ３２における単一のハッシュ値とするが、ｈ３２の２３２個の異なるハッシュ値は、単純にハッシュ値を推定することによって或るノードになりすますという操作を困難にするように作用する。
リンクデータパケットの署名セクションに含まれるフィールド
図１６は、データリンクパケットの署名フィールドセクションを示すブロック図である。Ｓｉｇ（３２）はデータのセキュアチェックサムとして機能し、そしてデータ送信側の認証を行なう。ノードＡはこのフィールドを、３２ビット折り返し文字列ｈ（ｋ，Ｄ，ｋ）に設定し、この場合、ｈは合意したハッシュ関数であり、ｋはリンクのデフィー・へルマンキーであり、そしてＤはパケットの内、パケットヘッダの後に続くデータを表わす。これに関連して、コンマは連結演算子を表わす。ユニキャストデータパケットはＳｉｇフィールドを一つだけ持つのに対して、マルチキャストデータパケットは複数のＳｉｇフィールドを有することができ、この場合、署名の実際の数は、パケットのマルチキャストセクションに含まれるＮｕｍＳｉｇｓフィールドによって与えられる（図１４参照）。
図１６は、データリンクパケットの署名フィールドセクションを示すブロック図である。Ｓｉｇ（３２）はデータのセキュアチェックサムとして機能し、そしてデータ送信側の認証を行なう。ノードＡはこのフィールドを、３２ビット折り返し文字列ｈ（ｋ，Ｄ，ｋ）に設定し、この場合、ｈは合意したハッシュ関数であり、ｋはリンクのデフィー・へルマンキーであり、そしてＤはパケットの内、パケットヘッダの後に続くデータを表わす。これに関連して、コンマは連結演算子を表わす。ユニキャストデータパケットはＳｉｇフィールドを一つだけ持つのに対して、マルチキャストデータパケットは複数のＳｉｇフィールドを有することができ、この場合、署名の実際の数は、パケットのマルチキャストセクションに含まれるＮｕｍＳｉｇｓフィールドによって与えられる（図１４参照）。
リンクデータパケットのパケット情報セクション
一旦、ノードＡ及びＢが互いにリンクを設定すると、ノードＡからＢに送信される複数のパケットに、Ｐａｃｋｅｔ ＩＤ（ＰＩＤ）を連番（０，１，２．．．）で付加する。同じようにして、ノードＢからＡに送信される複数のパケットにも、当該パケット固有のＰＩＤに対応する別の順番を使用して、番号を連番で付加する。
一旦、ノードＡ及びＢが互いにリンクを設定すると、ノードＡからＢに送信される複数のパケットに、Ｐａｃｋｅｔ ＩＤ（ＰＩＤ）を連番（０，１，２．．．）で付加する。同じようにして、ノードＢからＡに送信される複数のパケットにも、当該パケット固有のＰＩＤに対応する別の順番を使用して、番号を連番で付加する。
リプライ攻撃からの保護を確実に行なうために、リンクレイヤは、ＨｉｇｈｅｓｔＰＩＤよりも小さいＰＩＤ、またはＨｉｇｈｅｓｔＰＩＤ＋ＲａｎｇｅＰＩＤよりも大きいＰＩＤで到着するパケットを廃棄し、この場合、ＨｉｇｈｅｓｔＰＩＤは、これまでに全てのリンクデータパケットに含まれて受信されたＰＩＤの最大値であり、そしてＲａｎｇｅＰＩＤの代表的な定数値は１０００である。いずれの実施形態においても、適切な調整を行なって「ラップアラウンド（循環）」を処理する、すなわち全てが１のビットパターンを持つＰＩＤから、全てが０のビットパターンを持つＰＩＤへの円滑な移行を可能にする必要がある。ＰＩＤが符号無しの３２ビット整数フィールドであり、数値処理が２３２を法として行なわれるので、この操作が必要である。
リンクデータパケットのパケット情報セクションに含まれるフィールド
図１７は、リンクデータパケットのパケット情報セクションを示すブロック図である。ＰＩＤ（３２）：リンクの寿命に亘って送信される各パケットごとに（リンクに関して、方向に関して）順にインクリメントする整数。
図１７は、リンクデータパケットのパケット情報セクションを示すブロック図である。ＰＩＤ（３２）：リンクの寿命に亘って送信される各パケットごとに（リンクに関して、方向に関して）順にインクリメントする整数。
ＮｕｍＡｃｋｓ（８）：この（発信）パケットに含まれる、着信パケットに対する確認応答の数。更なる情報については、「リンクデータパケットの確認応答セクション」を参照されたい。
ＴｏＳ（２）：リンク経由で渡されるデータに対応するサービスのタイプを指定する。現在サポートされているＴｏＳタイプは表１に示される。
Ｔｙｐｅ（８）：表２に示すように、パケットに含まれるデータのタイプを記述する。このフィールドは、パケットが確認応答のみを含む場合に０に設定される。それ以外の場合、このフィールドは、上位のプロトコルレイヤのために利用することができる。
ＡｃｋＣｏｍ（１）：確認応答の圧縮が行なわれる場合に１に設定され、これは、確認応答が３２ビット長ではなく８ビット長であることを意味する。それ以外の場合、０に設定される。更なる情報については、「リンクデータパケットの確認応答セクション」を参照されたい。
Ｒｅｓ（６）：将来時点で使用するために確保される。
リンクデータパケットのフラグメンテーションセクション
図１８は、リンクデータパケットのフラグメンテーションセクションを示すブロック図である。
リンクデータパケットのフラグメンテーションセクション
図１８は、リンクデータパケットのフラグメンテーションセクションを示すブロック図である。
リンクレイヤプロトコルは、リンクデータパケットフラグメンテーションと呼ばれるプロセスをサポートする。リンクレイヤがパケットを回線レイヤ及びルーティングレイヤから受信すると、パケットはネットワークインターフェースレイヤには大き過ぎてハンドリングすることができない。この現象が生じるのは、ハードウェアに関連する最大送信単位（ＭＴＵ）制限があるためである。この場合、リンクレイヤは、当該レイヤで受信するパケットを小さいパケット群に、これらのパケットをネットワークインターフェースに送信する前にフラグメント化する。同様に、リンクレイヤがこのようなフラグメント化パケットを受信すると、当該リンクレイヤはこれらのパケットを元のパケット構造に、これらのパケットをルーティングレイヤ及び回線レイヤに渡す前にフォーマットし直す。ＭＴＵは、下位のネットワークトランスポート技術がサポートすることができる最大パケットサイズであり、イーサネット、衛星、ＷｉＦｉ，及び無線搬送のような異なる技術に応じて変化する。
相対的に上位の単一パケット−回線レイヤパケットのような−フラグメントを含む全てのパケットが同じＰＩＤを含む。受信側ノードはこのＰＩＤに対する確認応答を、フラグメントの全てを受信した後にのみ送信する。
各データパケットフラグメントは、相対的に上位のパケット内における当該フラグメントの位置を表わすオフセットを含む。これらのオフセットは、最後のフラグメントを示すビットとともに、受信側によるフラグメントの再組立てを可能にするように作用する。
パケット情報セクションのＦｒａｇフィールド（図１７参照）は、現在のデータパケットが大規模なデータブロックのフラグメントであるかどうかを表わす。パケットフラグメンテーションに関連する残りのフィールドを図１８に示す。
リンクデータパケットのフラグメンテーションセクションに含まれるフィールド
ＬａｓｔＦｒａｇ（１）：パケットが一連のフラグメントの最後のフラグメントを含む場合に１に設定する。それ以外の場合、０に設定する。
ＬａｓｔＦｒａｇ（１）：パケットが一連のフラグメントの最後のフラグメントを含む場合に１に設定する。それ以外の場合、０に設定する。
Ｆｒａｇｍｅｎｔａｔｉｏｎ Ｏｆｆｓｅｔ（３１）：元のデータパケットの先頭からのこのフラグメントのオフセットをバイト数で指定するバイトオフセットに設定する。
リンクデータパケットの確認応答セクション
リンクレイヤはパケットを、着信パケットに対する−所与の制限値を最大とする、時間制限内及び空間制限内のできる限り多くの着信パケットに対する−確認応答を発信パケットに乗せるシステムを使用することにより承認する。発信パケットを送信する状態になっている場合、リンクレイヤは、利用可能な確認応答を乗せる。確認応答を利用することができるが、発信する状態になっているパケットが無い場合、リンクレイヤは、２つのイベントの内の一方のイベントを待機する必要がある。
・所与の制限時間が経過した
・所与の数の確認応答が蓄積される
どのステートが生じるかどうかに関係なく、リンクレイヤは、どの有効データストリームにも関連しない空パケットを生成し、待機中の確認応答を乗せ、そしてパケットを送信する。
リンクデータパケットの確認応答セクション
リンクレイヤはパケットを、着信パケットに対する−所与の制限値を最大とする、時間制限内及び空間制限内のできる限り多くの着信パケットに対する−確認応答を発信パケットに乗せるシステムを使用することにより承認する。発信パケットを送信する状態になっている場合、リンクレイヤは、利用可能な確認応答を乗せる。確認応答を利用することができるが、発信する状態になっているパケットが無い場合、リンクレイヤは、２つのイベントの内の一方のイベントを待機する必要がある。
・所与の制限時間が経過した
・所与の数の確認応答が蓄積される
どのステートが生じるかどうかに関係なく、リンクレイヤは、どの有効データストリームにも関連しない空パケットを生成し、待機中の確認応答を乗せ、そしてパケットを送信する。
確認応答の圧縮を使用する（パケット情報セクションのＡｃｋＣｏｍフィールドをセットすることにより；図１７参照）場合、確認応答されるパケットのＰＩＤの中の８個の最下位ビットのみが使用される。送信側ノードが、当該ノードが送信した２５６個の直近のパケットに含まれるパケットに対するａｃｋを受信する限り、ノードは、どのパケットが確認応答されているかについて高い精度で判断することができる。
リンクデータパケットの確認応答セクションに含まれるフィールド
図１９は、リンクデータパケットの確認応答セクションに含まれるフィールドを示すブロック図である。Ａｃｋ（８または３２）：確認応答される受信着信パケットのＰＩＤを含む。フィールドのサイズは８ビットまたは３２ビットであり、いずれのビットになるかは、パケット情報セクション（図１７参照）に含まれるＡｃｋＣｏｍフィールドの値によって変わる。表示されるＡｃｋフィールドの数値は、ＮｕｍＡｃｋｓフィールド（このフィールドもパケット情報セクションに含まれる）によって与えられる。
Ａｖｅｒａｇｅ Ｈｏｌｄ Ｔｉｍｅ（３２）：このパケットで確認応答される複数のパケットの各パケットのホールド時間の平均値を含む。このフィールドは、サービス品質を測定するために使用される。
図１９は、リンクデータパケットの確認応答セクションに含まれるフィールドを示すブロック図である。Ａｃｋ（８または３２）：確認応答される受信着信パケットのＰＩＤを含む。フィールドのサイズは８ビットまたは３２ビットであり、いずれのビットになるかは、パケット情報セクション（図１７参照）に含まれるＡｃｋＣｏｍフィールドの値によって変わる。表示されるＡｃｋフィールドの数値は、ＮｕｍＡｃｋｓフィールド（このフィールドもパケット情報セクションに含まれる）によって与えられる。
Ａｖｅｒａｇｅ Ｈｏｌｄ Ｔｉｍｅ（３２）：このパケットで確認応答される複数のパケットの各パケットのホールド時間の平均値を含む。このフィールドは、サービス品質を測定するために使用される。
マルチキャストをユニキャストから区別する
概要が以下の疑似コードに示されるプロシージャＯｎＲｅｃｅｉｖｅＤａｔａＰａｃｋｅｔ（）は、リンクレイヤが、ユニキャストパケットをマルチキャストデータパケットから区別する方法を記述する。この処理はＰＡＬで行なわれる。送信側がマルチキャストを行なおうとしている場合、送信側は、一連の所望の受信側によって導出される値ＤｅｓｔＳｅｔＨａｓｈを計算する（ＤｅｓｔＳｅｔＨａｓｈ値に関する更に詳しい情報については、「リンクデータパケットのマルチキャストセクション」を参照されたい）。パケットを物理的に受信する各ノードは、当該ノードが送信側の所望の受信側の内の一つの受信側であるかどうかを、パケットヘッダに含まれる署名を調査することにより判断することができるが、ＤｅｓｔＳｅｔＨａｓｈ値は、ローカルノードが所望の受信側であるかどうかを、パケットヘッダに含まれる署名のリストを全てを必ず調査しなければならないという必要を無くすことにより、更に迅速に判断する手段となる。
概要が以下の疑似コードに示されるプロシージャＯｎＲｅｃｅｉｖｅＤａｔａＰａｃｋｅｔ（）は、リンクレイヤが、ユニキャストパケットをマルチキャストデータパケットから区別する方法を記述する。この処理はＰＡＬで行なわれる。送信側がマルチキャストを行なおうとしている場合、送信側は、一連の所望の受信側によって導出される値ＤｅｓｔＳｅｔＨａｓｈを計算する（ＤｅｓｔＳｅｔＨａｓｈ値に関する更に詳しい情報については、「リンクデータパケットのマルチキャストセクション」を参照されたい）。パケットを物理的に受信する各ノードは、当該ノードが送信側の所望の受信側の内の一つの受信側であるかどうかを、パケットヘッダに含まれる署名を調査することにより判断することができるが、ＤｅｓｔＳｅｔＨａｓｈ値は、ローカルノードが所望の受信側であるかどうかを、パケットヘッダに含まれる署名のリストを全てを必ず調査しなければならないという必要を無くすことにより、更に迅速に判断する手段となる。
プロシージャＯｎＲｅｃｅｉｖｅＤａｔａＰａｃｋｅｔ（）では、変数ＤｅｓｔＳｅｔＴａｂｌｅは、ＤｅｓｔＳｅｔＨａｓｈの値をインデックスとして付与されたアレイである。各エントリは符号無しの整数値を含む。ローカルノードは、ＤｅｓｔＳｅｔＴａｂｌｅ［ＤｅｓｔＳｅｔＨａｓｈ］が非ゼロである場合に、ＤｅｓｔＳｅｔＨａｓｈの状態であり、この場合、ＤｅｓｔＳｅｔＴａｂｌｅ［ＤｅｓｔＳｅｔＨａｓｈ］の値は、ローカルノードの署名に一致する必要がある署名の位置（データパケットヘッダに付加された一連の署名の中の）を示す。ＤｅｓｔＳｅｔＴａｂｌｅ［ＤｅｓｔＳｅｔＨａｓｈ］の値がゼロである場合、ローカルノードは所望の受信側ではなく、当該ノードはパケットを廃棄する必要がある。
ＤｅｓｔＳｅｔＴａｂｌｅ［ＤｅｓｔＳｅｔＨａｓｈ］の値は、ローカルノードが、値ＤｅｓｔＳｅｔＨａｓｈをパケットのＤｅｓｔＳｅｔＨａｓｈフィールドに含むパケットを受信した後にのみ定義される。ローカルノードが当該パケットを受信する前では、ＤｅｓｔＳｅｔＴａｂｌｅ［ＤｅｓｔＳｅｔＨａｓｈ］は定義されない。送信側が、異なる一連の所望の送信先を持つパケットをブロードキャストする場合、送信側はＤｅｓｔＳｅｔＨａｓｈの新規の値を、送信側が送信するデータパケットのＤｅｓｔＳｅｔＨａｓｈフィールドに関して計算する。ローカルノードが、新規のＤｅｓｔＳｅｔＨａｓｈ値を含むマルチキャストパケットを受信する場合、当該ノードは、当該ノードの署名を計算し、そしてパケットヘッダに含まれる複数の署名の中から一致する署名を調査する。一致を示す署名の位置をＤｅｓｔＳｅｔＴａｂｌｅ［ＤｅｓｔＳｅｔＨａｓｈ］に格納する。署名が一致しない場合には、ＤｅｓｔＳｅｔＴａｂｌｅ［ＤｅｓｔＳｅｔＨａｓｈ］がゼロに設定され、そしてパケットが廃棄される。
リンクレイヤは、データをリンクで送信するコストをモニタリングする。幾つかの一般的なコスト指標は、帯域、遅延、ジッタ、信頼性、輻輳、及び実際の金銭費用（例えば、ネットワークでは衛星リンクの使用をリースすることができる）を含む。回線レイヤはこのデータを使用して、ユーザが指定するＱｏＳ要件を満たす回線を設定する。
ｇｅｔＱｏＳ（）
ｇｅｔＱｏＳ（）関数は一連のＱｏＳ指標を返す。返される指標は、特定の実施形態に限定される。
ｇｅｔＱｏＳ（）関数は一連のＱｏＳ指標を返す。返される指標は、特定の実施形態に限定される。
パケット配信
パケットは上位プロトコルレイヤに、ＲｅｃｅｉｖｅＰａｃｋｅｔ（図３参照）に対する呼び出しを行なうことにより配信される。パケットが、テストパケットまたは広告に設定された当該パケットのＴｙｐｅフィールドを持つ場合（表２、及び「リンクデータパケットのパケット情報セクション」と題する節を参照）、リンクデータレイヤは、ルーティングレイヤのＲｅｃｅｉｖｅＰａｃｋｅｔを呼び出す。パケットが、複数の回線関連パケットタイプ（表２参照）の内の一つの回線関連パケットタイプに設定されたタイプフィールドを持つ場合、リンクデータレイヤは、回線レイヤのＲｅｃｅｉｖｅＰａｃｋｅｔを呼び出す。
パケットは上位プロトコルレイヤに、ＲｅｃｅｉｖｅＰａｃｋｅｔ（図３参照）に対する呼び出しを行なうことにより配信される。パケットが、テストパケットまたは広告に設定された当該パケットのＴｙｐｅフィールドを持つ場合（表２、及び「リンクデータパケットのパケット情報セクション」と題する節を参照）、リンクデータレイヤは、ルーティングレイヤのＲｅｃｅｉｖｅＰａｃｋｅｔを呼び出す。パケットが、複数の回線関連パケットタイプ（表２参照）の内の一つの回線関連パケットタイプに設定されたタイプフィールドを持つ場合、リンクデータレイヤは、回線レイヤのＲｅｃｅｉｖｅＰａｃｋｅｔを呼び出す。
結論
リンクレイヤプロトコルは、複数のＣｏＣｏノードペアの間の直接的接続手段であるリンクを生成し、そして管理する。リンクレイヤは、隣接するＣｏＣｏデバイスの存在を検出し、そしてこれらのデバイスに達するリンクを設定する。リンク設定では、符号化方式の交渉及びデフィー・へルマンキー交換を行なって、リンク経由で送信される全ての通信の安全を確保することができるようにする。
リンクレイヤプロトコルは、複数のＣｏＣｏノードペアの間の直接的接続手段であるリンクを生成し、そして管理する。リンクレイヤは、隣接するＣｏＣｏデバイスの存在を検出し、そしてこれらのデバイスに達するリンクを設定する。リンク設定では、符号化方式の交渉及びデフィー・へルマンキー交換を行なって、リンク経由で送信される全ての通信の安全を確保することができるようにする。
一旦、リンクが設定されると、リンクレイヤは、パケットの受け渡しをネットワークインターフェースレイヤと上位のプロトコルレイヤとの間で行ない、サービス品質（ＱｏＳ）統計をモニタリングし、これらの統計を上位のプロトコルレイヤにレポートすることができる。リンクレイヤは、マルチキャストを、単一のネットワークインターフェースを経由する冗長なパケット転送を抑制することによりサポートし、パケットサイズがネットワークインターフェースの最大送信単位（ＭＴＵ）を超える場合にフラグメンテーションを実行し、無効リンクを閉鎖して、システムリソースを新規のリンクリクエストのために解放する。
リンクレイヤは、デフィー・へルマンキー交換、及びワークトークン計算を使用して、ＴＣＰ及びＩＰには組み込まれていないセキュリティのレベルを実現する。このプロトコルは、移動体ネットワーク技術及びアドホックネットワーク技術のために特に設計され、そしてこの目的に対応するＴＣＰ／ＩＰよりも優れる。
以下の項目が可能になる。
１．リンクを、スケーラブルかつ動的な性質を有する異機種環境通信ネットワークにおいて設定する方法。
２．他のネットワークノードの存在を通信ネットワークにおいて検出する方法。
３．他のネットワークノードを含むリンクの安全を確保する方法。ノードＡ及びＢが、一つのリンクによって接続される２つのネットワークノードである場合、ノードＡがパケットをノードＢに送信すると、ノードＢは、ノードＡだけが当該パケットを送信することができることを保証され、そしてノードＡは、ノードＢだけが当該パケットを読み取ることができることを保証される。
４．介入者攻撃を防止する方法。一旦、リンクが２つのノードＡとＢとの間に設定されると、不良ノードは、当該ノード自体をノードＡとＢとの間に介在させ、そしてノードＡ及びＢの各々に対して他方のノードになりすますということはできなくなる。従って、ＣｏＣｏネットワークは、所謂介入者攻撃を防止する。
５．サービス拒否攻撃を防止する方法。ネットワークを偽パケットで溢れさせようと試みるノードは必ず、膨大な計算リソースを利用せざるを得なくなる。従って、ＣｏＣｏネットワークは、所謂サービス拒否攻撃を防止する。
６．リンク品質を通信ネットワークにおいてモニタリングする方法。
７．測定リンク品質を使用して、指定ＱｏＳ要件を満たす回線を通信ネットワークにおいて設定する方法。
８．一様なアドレス（一様なネットワーク識別子）をネットワークノードに、異機種環境通信ネットワークにおいて割り当てる方法。
９．ノード群が適切なセキュリティ機構についてリンク設定中に交渉する方法。
１０．マルチキャストを、単一のネットワークインターフェースを経由する冗長なパケット転送を抑制することによりサポートする方法。
１１．リンクを閉鎖する必要がある時点を検出する方法。
１．リンクを、スケーラブルかつ動的な性質を有する異機種環境通信ネットワークにおいて設定する方法。
２．他のネットワークノードの存在を通信ネットワークにおいて検出する方法。
３．他のネットワークノードを含むリンクの安全を確保する方法。ノードＡ及びＢが、一つのリンクによって接続される２つのネットワークノードである場合、ノードＡがパケットをノードＢに送信すると、ノードＢは、ノードＡだけが当該パケットを送信することができることを保証され、そしてノードＡは、ノードＢだけが当該パケットを読み取ることができることを保証される。
４．介入者攻撃を防止する方法。一旦、リンクが２つのノードＡとＢとの間に設定されると、不良ノードは、当該ノード自体をノードＡとＢとの間に介在させ、そしてノードＡ及びＢの各々に対して他方のノードになりすますということはできなくなる。従って、ＣｏＣｏネットワークは、所謂介入者攻撃を防止する。
５．サービス拒否攻撃を防止する方法。ネットワークを偽パケットで溢れさせようと試みるノードは必ず、膨大な計算リソースを利用せざるを得なくなる。従って、ＣｏＣｏネットワークは、所謂サービス拒否攻撃を防止する。
６．リンク品質を通信ネットワークにおいてモニタリングする方法。
７．測定リンク品質を使用して、指定ＱｏＳ要件を満たす回線を通信ネットワークにおいて設定する方法。
８．一様なアドレス（一様なネットワーク識別子）をネットワークノードに、異機種環境通信ネットワークにおいて割り当てる方法。
９．ノード群が適切なセキュリティ機構についてリンク設定中に交渉する方法。
１０．マルチキャストを、単一のネットワークインターフェースを経由する冗長なパケット転送を抑制することによりサポートする方法。
１１．リンクを閉鎖する必要がある時点を検出する方法。
関連するセマンティックのコンセプト
・リンク
・帯域
・遅延
・暗号化
・デフィー・へルマンキー合意
・ユニバーサルノード識別子
・プロトコル抽象化レイヤ
・サービス拒否攻撃の防止
・介入者攻撃の防止
・リンク設定パケット
・往復時間の計算
・確認応答
・マルチキャスト処理
・ユニキャスト処理
・リンクステートマシン
これまでの記述から、本発明の特定の実施形態について本明細書において説明して例示を行なってきたが、種々の変更を本発明の技術思想及び技術範囲から逸脱しない限り加え得ることを理解できるであろう。従って、本発明は、添付の請求項によって規定される以外には制限されない。
・リンク
・帯域
・遅延
・暗号化
・デフィー・へルマンキー合意
・ユニバーサルノード識別子
・プロトコル抽象化レイヤ
・サービス拒否攻撃の防止
・介入者攻撃の防止
・リンク設定パケット
・往復時間の計算
・確認応答
・マルチキャスト処理
・ユニキャスト処理
・リンクステートマシン
これまでの記述から、本発明の特定の実施形態について本明細書において説明して例示を行なってきたが、種々の変更を本発明の技術思想及び技術範囲から逸脱しない限り加え得ることを理解できるであろう。従って、本発明は、添付の請求項によって規定される以外には制限されない。
Claims (3)
- スケーラブルかつ動的である異機種環境通信ネットワークにおいてリンクを設定するシステムであって、
（ａ）データを互いに送信および受信することができる通信デバイスの集合体を有する通信ネットワークと、
（ｂ）複数タイプのネットワークデバイス、及び複数タイプの通信リンクの集合体を有し、かつ異なるタイプ及び製造業者のデバイスを含むハイブリッドネットワークである異機種環境通信ネットワークと、
（ｃ）フレームをネットワークインターフェースレイヤで送受信し、データを回線／ルーティングレイヤで送受信するプロトコル抽象化レイヤと
を備え、前記プロトコル抽象化レイヤは、リンク設定レイヤコンポーネント、サービス品質ハンドラーコンポーネント、及びリンクデータレイヤコンポーネントを有する、システム。 - 前記プロトコル抽象化レイヤは、ネットワークデバイスからデータフレームを受信し、ＣｏＣｏヘッダ及びアドレス変換テーブルを作成し、ネットワークインターフェースレイヤヘッダを削除し、前記ＣｏＣｏヘッダを有する変更済みパケットをサブレイヤに送信する、請求項１記載のシステム。
- 前記作成したＣｏＣｏヘッダ及びアドレス変換テーブルには、ネットワークインターフェースレイヤからの情報を格納する、請求項２記載のシステム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US76395906P | 2006-02-01 | 2006-02-01 | |
| PCT/US2007/061487 WO2007090196A2 (en) | 2006-02-01 | 2007-02-01 | Protocol link layer |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2009525708A true JP2009525708A (ja) | 2009-07-09 |
Family
ID=38328165
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008553515A Withdrawn JP2009525708A (ja) | 2006-02-01 | 2007-02-01 | プロトコルリンクレイヤ |
Country Status (7)
| Country | Link |
|---|---|
| US (4) | US20100002721A1 (ja) |
| EP (1) | EP1985047A2 (ja) |
| JP (1) | JP2009525708A (ja) |
| CN (1) | CN101411105A (ja) |
| CA (1) | CA2641253A1 (ja) |
| IL (1) | IL193162A0 (ja) |
| WO (1) | WO2007090196A2 (ja) |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20100112151A (ko) * | 2008-01-10 | 2010-10-18 | 스미토모덴코 네트웍스 가부시키가이샤 | 네트워크 카드 및 정보 처리 장치 |
| CN102246156A (zh) * | 2008-10-14 | 2011-11-16 | 惠普开发有限公司 | 在网络系统中管理事件流量 |
| JP5707171B2 (ja) | 2011-02-25 | 2015-04-22 | 任天堂株式会社 | 通信制御装置、通信制御プログラム、通信制御方法、および、情報処理システム |
| JP5728249B2 (ja) | 2011-02-25 | 2015-06-03 | 任天堂株式会社 | 情報処理システム、情報処理装置、情報処理プログラム、および、情報処理方法 |
| EP2500872A1 (fr) * | 2011-03-08 | 2012-09-19 | Openways Sas | Procédé sécurisé de commande d'ouverture de dispositifs de serrure par un objet communicant de type téléphone portable |
| US8971213B1 (en) * | 2011-10-20 | 2015-03-03 | Cisco Technology, Inc. | Partial association identifier computation in wireless networks |
| CN102420764B (zh) * | 2011-12-08 | 2015-02-25 | 北京星网锐捷网络技术有限公司 | 一种链路建立方法及设备 |
| CN103428690B (zh) * | 2012-05-23 | 2016-09-07 | 华为技术有限公司 | 无线局域网络的安全建立方法及系统、设备 |
| EP2747348A1 (en) | 2012-12-20 | 2014-06-25 | Thomson Licensing | Apparatus adapted for connecting a home network with a service provider network |
| CN103414603B (zh) * | 2013-07-31 | 2016-08-10 | 清华大学 | 基于Hash折叠方法的Ipv6深度包检测方法 |
| KR102280286B1 (ko) * | 2014-09-04 | 2021-07-22 | 삼성전자주식회사 | 마스터 노드 및 마스터 노드의 동작 방법 |
| US10057765B2 (en) * | 2014-09-04 | 2018-08-21 | Samsung Electronics Co., Ltd. | Master node and operation method of the master node |
| US20160085975A1 (en) * | 2014-09-18 | 2016-03-24 | Safenet, Inc. | Constrained Information Transfer |
| US10326590B2 (en) * | 2014-11-11 | 2019-06-18 | Intel Corporation | Technologies for trusted device on-boarding |
| US9660768B2 (en) * | 2015-01-26 | 2017-05-23 | Link Labs, Inc. | Dense acknowledgement broadcast/multicast |
| US10498832B2 (en) * | 2017-07-11 | 2019-12-03 | Oracle International Corporation | Link-training auto-negotiation protocol with three-way handshake |
Family Cites Families (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5511122A (en) | 1994-06-03 | 1996-04-23 | The United States Of America As Represented By The Secretary Of The Navy | Intermediate network authentication |
| US7512799B1 (en) * | 1999-03-05 | 2009-03-31 | Getthere Inc. | System and method for accessing a remote server from an intranet with a single sign-on |
| US6584466B1 (en) * | 1999-04-07 | 2003-06-24 | Critical Path, Inc. | Internet document management system and methods |
| US7278017B2 (en) | 2000-06-07 | 2007-10-02 | Anoto Ab | Method and device for secure wireless transmission of information |
| US6947431B1 (en) * | 2000-08-23 | 2005-09-20 | Radio Ip Software Inc. | Wireless data communications with header suppression and reconstruction |
| US7173927B2 (en) * | 2000-12-18 | 2007-02-06 | Raza Microelectronics, Inc. | Hybrid network to carry synchronous and asynchronous traffic over symmetric and asymmetric links |
| JP3757933B2 (ja) * | 2002-11-28 | 2006-03-22 | ソニー株式会社 | 通信装置 |
| US7451217B2 (en) * | 2002-12-19 | 2008-11-11 | International Business Machines Corporation | Method and system for peer-to-peer authorization |
| US9331990B2 (en) * | 2003-12-22 | 2016-05-03 | Assa Abloy Ab | Trusted and unsupervised digital certificate generation using a security token |
| US20050235140A1 (en) * | 2004-03-11 | 2005-10-20 | Hui Chi-Kwong | System and method for secure preservation and long term archival of electronic documents |
| US7720864B1 (en) * | 2004-03-25 | 2010-05-18 | Symantec Operating Corporation | Expiration of access tokens for quiescing a distributed system |
| US7870201B2 (en) * | 2004-12-03 | 2011-01-11 | Clairmail Inc. | Apparatus for executing an application function using a mail link and methods therefor |
| US7844674B2 (en) * | 2004-12-03 | 2010-11-30 | Clairmail Inc. | Architecture for general purpose trusted personal access system and methods therefor |
| US7870202B2 (en) * | 2004-12-03 | 2011-01-11 | Clairmail Inc. | Apparatus for executing an application function using a smart card and methods therefor |
| US7529191B2 (en) * | 2005-02-18 | 2009-05-05 | Broadcom Corporation | Programmable metering behavior based on table lookup |
| US7577096B2 (en) * | 2005-02-18 | 2009-08-18 | Broadcom Corporation | Timestamp metering and rollover protection in a network device |
| US20070174630A1 (en) * | 2005-02-21 | 2007-07-26 | Marvin Shannon | System and Method of Mobile Anti-Pharming and Improving Two Factor Usage |
| US8566462B2 (en) * | 2005-05-12 | 2013-10-22 | Digital River, Inc. | Methods of controlling access to network content referenced within structured documents |
| US20060274695A1 (en) * | 2005-06-03 | 2006-12-07 | Nokia Corporation | System and method for effectuating a connection to a network |
| US7930736B2 (en) * | 2006-01-13 | 2011-04-19 | Google, Inc. | Providing selective access to a web site |
-
2007
- 2007-02-01 WO PCT/US2007/061487 patent/WO2007090196A2/en active Application Filing
- 2007-02-01 JP JP2008553515A patent/JP2009525708A/ja not_active Withdrawn
- 2007-02-01 EP EP07762868A patent/EP1985047A2/en not_active Withdrawn
- 2007-02-01 CN CNA2007800109534A patent/CN101411105A/zh active Pending
- 2007-02-01 US US12/278,145 patent/US20100002721A1/en not_active Abandoned
- 2007-02-01 CA CA002641253A patent/CA2641253A1/en not_active Abandoned
-
2008
- 2008-07-31 IL IL193162A patent/IL193162A0/en unknown
-
2012
- 2012-02-16 US US13/398,751 patent/US8248964B2/en active Active
- 2012-08-16 US US13/587,661 patent/US8861393B2/en active Active
-
2014
- 2014-10-13 US US14/512,690 patent/US9641492B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US9641492B2 (en) | 2017-05-02 |
| US8248964B2 (en) | 2012-08-21 |
| EP1985047A2 (en) | 2008-10-29 |
| IL193162A0 (en) | 2009-02-11 |
| US8861393B2 (en) | 2014-10-14 |
| CA2641253A1 (en) | 2007-08-09 |
| US20100002721A1 (en) | 2010-01-07 |
| WO2007090196A2 (en) | 2007-08-09 |
| WO2007090196A3 (en) | 2007-12-27 |
| US20120151069A1 (en) | 2012-06-14 |
| CN101411105A (zh) | 2009-04-15 |
| US20130051401A1 (en) | 2013-02-28 |
| US20150100790A1 (en) | 2015-04-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9641492B2 (en) | Protocol link layer | |
| Kumar et al. | Implementation and analysis of QUIC for MQTT | |
| US7502860B1 (en) | Method and apparatus for client-side flow control in a transport protocol | |
| US8224976B2 (en) | Using a server's capability profile to establish a connection | |
| TWI677222B (zh) | 應用於伺服器負載均衡中的連接建立方法及裝置 | |
| US7921282B1 (en) | Using SYN-ACK cookies within a TCP/IP protocol | |
| US10355961B2 (en) | Network traffic capture analysis | |
| Lu et al. | Delay/disruption tolerant network and its application in military communications | |
| Thornburgh | Adobe's Secure Real-Time Media Flow Protocol | |
| WO2011029357A1 (zh) | 认证通信流量的方法、通信系统和防护装置 | |
| Simpson | TCP cookie transactions (TCPCT) | |
| Seggelmann et al. | SSH over SCTP—Optimizing a multi-channel protocol by adapting it to SCTP | |
| Bernardo et al. | A conceptual approach against next generation security threats: Securing a high speed network protocol-UDT | |
| Custura et al. | Reducing the acknowledgement frequency in IETF QUIC | |
| Smyslov | Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation | |
| CN115242353B (zh) | 用于更新无线网格网络中重传次数的方法和设备 | |
| Jerschow et al. | Secure client puzzles based on random beacons | |
| CN117978374A (zh) | 一种安全路由发现方法和系统 | |
| Thornburgh | RFC 7016: Adobe's Secure Real-Time Media Flow Protocol | |
| Simpson | RFC 6013: TCP Cookie Transactions (TCPCT) | |
| KR101333153B1 (ko) | ＴＬＳ 복호화 기능을 포함하는 ＶｏＩＰ 보안장비 | |
| Choudhari et al. | Performance Evaluation of SCTP-Sec: A Secure SCTP Mechanism | |
| Choudhari et al. | SCTP-Sec: A secure Transmission Control Protocol | |
| JP2007174293A (ja) | 通信装置 | |
| Smyslov | RFC 7383: Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20100201 |
|
| A072 | Dismissal of procedure [no reply to invitation to correct request for examination] |
Free format text: JAPANESE INTERMEDIATE CODE: A073 Effective date: 20110628 |
|
| A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20110705 |