[要約] RFC 6621は、単純化されたマルチキャスト転送に関する標準仕様であり、マルチキャストトラフィックの効率的な転送を目指しています。このRFCの目的は、ネットワークのパフォーマンスを向上させ、リソースの効率化を図ることです。
Internet Engineering Task Force (IETF) J. Macker, Ed.
Request for Comments: 6621 NRL
Category: Experimental May 2012
ISSN: 2070-1721
Simplified Multicast Forwarding
簡素化されたマルチキャスト転送
Abstract
概要
This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic Internet Protocol (IP) multicast forwarding suitable for limited wireless mesh and mobile ad hoc network (MANET) use. It is mainly applicable in situations where efficient flooding represents an acceptable engineering design trade-off. It defines techniques for multicast duplicate packet detection (DPD), to be applied in the forwarding process, for both IPv4 and IPv6 protocol use. This document also specifies optional mechanisms for using reduced relay sets to achieve more efficient multicast data distribution within a mesh topology as compared to Classic Flooding. Interactions with other protocols, such as use of information provided by concurrently running unicast routing protocols or interaction with other multicast protocols, as well as multiple deployment approaches are also described. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the appendices. Basic issues relating to the operation of multicast MANET border routers are discussed, but ongoing work remains in this area and is beyond the scope of this document.
このドキュメントでは、限られたワイヤレスメッシュおよびモバイルアドホックネットワーク（MANET）の使用に適した基本的なインターネットプロトコル（IP）マルチキャスト転送を提供する簡易マルチキャスト転送（SMF）メカニズムについて説明します。これは主に、効率的な洪水が許容できる工学設計のトレードオフを表す状況で適用されます。 IPv4とIPv6の両方のプロトコルを使用するために、転送プロセスで適用されるマルチキャスト重複パケット検出（DPD）の手法を定義します。このドキュメントでは、クラシックフラッディングと比較して、メッシュトポロジ内でより効率的なマルチキャストデータ配信を実現するために、削減されたリレーセットを使用するためのオプションのメカニズムについても説明しています。同時に実行されるユニキャストルーティングプロトコルによって提供される情報の使用や他のマルチキャストプロトコルとの相互作用など、他のプロトコルとの相互作用、および複数の展開アプローチについても説明します。リレーの削減セットを選択するための分散アルゴリズムと関連する説明は、付録に記載されています。マルチキャストMANETボーダールーターの操作に関連する基本的な問題について説明しますが、進行中の作業はこの領域に残っており、このドキュメントの範囲を超えています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6621.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6621で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していないIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction and Scope ..........................................4
2. Terminology .....................................................4
3. Applicability Statement .........................................5
4. Overview and Functioning ........................................6
5. SMF Packet Processing and Forwarding ............................8
6. SMF Duplicate Packet Detection .................................10
6.1. IPv6 Duplicate Packet Detection ...........................11
6.1.1. IPv6 SMF_DPD Option Header .........................12
6.1.2. IPv6 Identification-Based DPD ......................14
6.1.3. IPv6 Hash-Based DPD ................................16
6.2. IPv4 Duplicate Packet Detection ...........................17
6.2.1. IPv4 Identification-Based DPD ......................18
6.2.2. IPv4 Hash-Based DPD ................................19
7. Relay Set Selection ............................................20
7.1. Non-Reduced Relay Set Forwarding ..........................20
7.2. Reduced Relay Set Forwarding ..............................20
8. SMF Neighborhood Discovery Requirements ........................23
8.1. SMF Relay Algorithm TLV Types .............................24
8.1.1. SMF Message TLV Type ...............................24
8.1.2. SMF Address Block TLV Type .........................25
9. SMF Border Gateway Considerations ..............................26
9.1. Forwarded Multicast Groups ................................27
9.2. Multicast Group Scoping ...................................28
9.3. Interface with Exterior Multicast Routing Protocols .......29
9.4. Multiple Border Routers ...................................29
10. Security Considerations .......................................31
11. IANA Considerations ...........................................32
11.1. IPv6 SMF_DPD Header Extension Option Type ................33
11.2. TaggerId Types (TidTy) ...................................33
11.3. Well-Known Multicast Address .............................34
11.4. SMF TLVs .................................................34
11.4.1. Expert Review for Created Type Extension
Registries ........................................34
11.4.2. SMF Message TLV Type (SMF_TYPE) ...................34
11.4.3. SMF Address Block TLV Type (SMF_NBR_TYPE) .........35
11.4.4. SMF Relay Algorithm ID Registry ...................35
12. Acknowledgments ...............................................36
13. References ....................................................37
13.1. Normative References .....................................37
13.2. Informative References ...................................38
Appendix A. Essential Connecting Dominating Set (E-CDS)
Algorithm ............................................40
A.1. E-CDS Relay Set Selection Overview ........................40
A.2. E-CDS Forwarding Rules ....................................41
A.3. E-CDS Neighborhood Discovery Requirements .................41
A.4. E-CDS Selection Algorithm .................................44
Appendix B. Source-Based Multipoint Relay (S-MPR) Algorithm ......46
B.1. S-MPR Relay Set Selection Overview ........................46
B.2. S-MPR Forwarding Rules ....................................47
B.3. S-MPR Neighborhood Discovery Requirements .................48
B.4. S-MPR Selection Algorithm .................................50
Appendix C. Multipoint Relay Connected Dominating Set
(MPR-CDS) Algorithm ..................................52
C.1. MPR-CDS Relay Set Selection Overview ......................52
C.2. MPR-CDS Forwarding Rules ..................................53
C.3. MPR-CDS Neighborhood Discovery Requirements ...............53
C.4. MPR-CDS Selection Algorithm ...............................54
Unicast routing protocols, designed for MANET and wireless mesh use, often apply distributed algorithms to flood routing control plane messages within a MANET routing domain. For example, algorithms specified within [RFC3626] and [RFC3684] provide distributed methods of dynamically electing reduced relay sets that attempt to efficiently flood routing control messages while maintaining a connected set under dynamic topological conditions.
MANETおよびワイヤレスメッシュの使用向けに設計されたユニキャストルーティングプロトコルは、多くの場合、分散アルゴリズムを適用して、MANETルーティングドメイン内のルーティングコントロールプレーンメッセージをフラッディングします。たとえば、[RFC3626]と[RFC3684]で指定されたアルゴリズムは、動的トポロジ条件の下で接続セットを維持しながらルーティング制御メッセージを効率的にフラッディングしようとする、削減されたリレーセットを動的に選択する分散方式を提供します。
Simplified Multicast Forwarding (SMF) extends the efficient flooding concept to the data forwarding plane, providing an appropriate multicast forwarding capability for use cases where localized, efficient flooding is considered an effective design approach. The baseline design is intended to provide a basic, best-effort multicast forwarding capability that is constrained to operate within a single MANET routing domain.
Simplified Multicast Forwarding（SMF）は、効率的なフラッディングの概念をデータ転送プレーンに拡張し、ローカライズされた効率的なフラッディングが効果的な設計アプローチであると考えられるユースケースに適切なマルチキャスト転送機能を提供します。ベースライン設計は、単一のMANETルーティングドメイン内で動作するように制限された、基本的なベストエフォートのマルチキャスト転送機能を提供することを目的としています。
An SMF routing domain is an instance of an SMF routing protocol with common policies, under a single network administration authority. The main design goals of this document are to:
SMFルーティングドメインは、単一のネットワーク管理権限の下で、共通のポリシーを持つSMFルーティングプロトコルのインスタンスです。このドキュメントの主な設計目標は次のとおりです。
o adapt efficient relay sets in MANET environments [RFC2501], and
o MANET環境で効率的なリレーセットを適合させる[RFC2501]、および
o define the needed IPv4 and IPv6 multicast duplicate packet detection (DPD) mechanisms to support multi-hop packet forwarding.
o マルチホップパケット転送をサポートするために必要なIPv4およびIPv6マルチキャスト重複パケット検出（DPD）メカニズムを定義します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
The terms introduced in [RFC5444], including "packet", "message", "TLV Block", "TLV", and "address", are to be interpreted as described therein.
[パケット]、[メッセージ]、[TLVブロック]、[TLV]、および[アドレス]を含む[RFC5444]で導入された用語は、その中で説明されているように解釈されます。
The following abbreviations are used throughout this document:
このドキュメントでは、次の略語を使用しています。
+--------------+----------------------------------------------------+
| Abbreviation | Definition |
+--------------+----------------------------------------------------+
| MANET | Mobile Ad Hoc Network |
| SMF | Simplified Multicast Forwarding |
| CF | Classic Flooding |
| CDS | Connected Dominating Set |
| MPR | Multipoint Relay |
| S-MPR | Source-based MPR |
| MPR-CDS | MPR-based CDS |
| E-CDS | Essential CDS |
| NHDP | Neighborhood Discovery Protocol |
| DPD | Duplicate Packet Detection |
| I-DPD | Identification-based DPD |
| H-DPD | Hash-based DPD |
| HAV | Hash assist value |
| FIB | Forwarding Information Base |
| TLV | type-length-value encoding |
| DoS | Denial of Service |
| SMF Router | A MANET Router implementing the protocol specified |
| | in this document |
| SMF Routing | A MANET Routing Domain wherein the protocol |
| Domain | specified in this document is operating |
+--------------+----------------------------------------------------+
Within dynamic wireless routing topologies, maintaining traditional forwarding trees to support a multicast routing protocol is often not as effective as in wired networks due to the reduced reliability and increased dynamics of mesh topologies [MGL04][GM99]. A basic packet forwarding service reaching all connected routers running the SMF protocol within a MANET routing domain may provide a useful group communication paradigm for various classes of applications, for example, multimedia streaming, interactive group-based messaging and applications, peer-to-peer middleware multicasting, and multi-hop mobile discovery or registration services. SMF is likely only appropriate for deployment in limited dynamic MANET routing domains (further defined as administratively scoped multicast forwarding domains in Section 9.2) so that the flooding process can be contained.
動的ワイヤレスルーティングトポロジ内では、従来の転送ツリーを維持してマルチキャストルーティングプロトコルをサポートすることは、メッシュトポロジ[MGL04] [GM99]の信頼性の低下とダイナミクスの増加により、有線ネットワークほど効果的ではありません。 MANETルーティングドメイン内でSMFプロトコルを実行しているすべての接続されたルーターに到達する基本的なパケット転送サービスは、マルチメディアストリーミング、インタラクティブなグループベースのメッセージングとアプリケーション、ピアツーピアなど、さまざまなクラスのアプリケーションに役立つグループ通信パラダイムを提供しますミドルウェアマルチキャスト、およびマルチホップモバイル検出または登録サービス。 SMFは、フラッディングプロセスを封じ込めるために、限定された動的MANETルーティングドメイン（セクション9.2で管理スコープのマルチキャスト転送ドメインとしてさらに定義）での展開にのみ適している可能性があります。
A design goal is that hosts may also participate in multicast traffic transmission and reception with standard IP network-layer semantics (e.g., special or unnecessary encapsulation of IP packets should be avoided in this case). SMF deployments are able to connect and interoperate with existing standard multicast protocols operating within more conventional Internet infrastructures. To this end, a multicast border router or proxy mechanism MUST be used when deployed alongside more fixed-infrastructure IP multicast routing such Protocol Independent Multicast (PIM) variants [RFC3973][RFC4601]. Experimental SMF implementations and deployments have demonstrated gateway functionality at MANET border routers operating with existing external IP multicast routing protocols [CDHM07][DHS08][DHG09]. SMF may be extended or combined with other mechanisms to provide increased reliability and group-specific filtering; the details for this are out of the scope of this document.
設計目標は、ホストが標準のIPネットワークレイヤーセマンティクスでマルチキャストトラフィックの送受信に参加することです（この場合、IPパケットの特別な、または不必要なカプセル化は避ける必要があります）。 SMFデプロイメントは、より従来型のインターネットインフラストラクチャ内で動作する既存の標準マルチキャストプロトコルに接続して相互運用できます。この目的のために、プロトコル境界独立型マルチキャスト（PIM）バリアント[RFC3973] [RFC4601]などのより固定インフラストラクチャのIPマルチキャストルーティングと共に展開する場合は、マルチキャスト境界ルーターまたはプロキシメカニズムを使用する必要があります。実験的なSMFの実装と展開は、既存の外部IPマルチキャストルーティングプロトコル[CDHM07] [DHS08] [DHG09]で動作するMANET境界ルーターでのゲートウェイ機能を実証しています。 SMFを拡張するか、他のメカニズムと組み合わせて、信頼性とグループ固有のフィルタリングを向上させることができます。この詳細はこのドキュメントの範囲外です。
This document does not presently support forwarding of packets with directed broadcast addresses as a destination [RFC2644].
このドキュメントは現在、宛先として指定されたブロードキャストアドレスを持つパケットの転送をサポートしていません[RFC2644]。
Figure 1 provides an overview of the logical SMF router architecture,
consisting of "Neighborhood Discovery", "Relay Set Selection", and
"Forwarding Process" components. Typically, relay set selection (or
self-election) occurs based on dynamic input from a neighborhood
discovery process. SMF supports the case where neighborhood
discovery and/or relay set selection information is obtained from a
coexistent process (e.g., a lower-layer mechanism or a unicast
routing protocol using relay sets). In some algorithm designs, the
forwarding decision for a packet can also depend on previous hop or
incoming interface information. The asterisks (*) in Figure 1 mark
the primitives and relationships needed by relay set algorithms
requiring previous-hop packet-forwarding knowledge.
______________ _____________
| | | |
| Neighborhood | | Relay Set |
| Discovery |------------->| Selection |
| | neighbor | |
|______________| info |_____________|
\ /
\ /
neighbor\ /forwarding
info* \ ____________ / status
\ | | /
`-->| Forwarding |<--'
| Process |
~~~~~~~~~~~~~~~~~>|____________|~~~~~~~~~~~~~~~~~>
incoming packet, forwarded packets
interface id*, and
previous hop*
Figure 1: SMF Router Architecture
図1：SMFルーターのアーキテクチャー
Certain IP multicast packets, defined in Sections 9.2 and 5, are "non-forwardable". These multicast packets MUST be ignored by the SMF forwarding engine. The SMF forwarding engine MAY also work with policies and management interfaces to allow additional filtering control over which multicast packets are considered for potential SMF forwarding. This interface would allow more refined dynamic forwarding control once such techniques are matured for MANET operation. At present, further discussion of dynamic control is left to future work.
セクション9.2および5で定義されている特定のIPマルチキャストパケットは「転送不可」です。これらのマルチキャストパケットは、SMF転送エンジンによって無視される必要があります。 SMF転送エンジンは、ポリシーおよび管理インターフェースと連携して、SMF転送の可能性があると見なされるマルチキャストパケットに対する追加のフィルタリング制御を許可する場合があります。このインターフェースは、MANETオペレーションのためにそのような技術が成熟すると、より洗練された動的転送制御を可能にします。現在、動的制御のさらなる議論は将来の作業に委ねられています。
Interoperable SMF implementations MUST use compatible DPD approaches and be able to process the header options defined in this document for IPv6 operation.
相互運用可能なSMF実装は、互換性のあるDPDアプローチを使用し、このドキュメントでIPv6オペレーション用に定義されたヘッダーオプションを処理できる必要があります。
Classic Flooding (CF) is defined as the simplest case of SMF multicast forwarding. With CF, all SMF routers forward each received multicast packet exactly once. In this case, the need for any relay set selection or neighborhood topology information is eliminated, at the expense of additional network overhead incurred from unnecessary packet retransmissions. With CF, the SMF DPD functionality is still required. While SMF supports CF as a mode of operation, the use of more efficient relay set modes is RECOMMENDED in order to reduce contention and congestion caused by unnecessary packet retransmissions [NTSC99].
Classic Flooding（CF）は、SMFマルチキャスト転送の最も単純なケースとして定義されています。 CFでは、すべてのSMFルーターが受信した各マルチキャストパケットを1回だけ転送します。この場合、不要なパケットの再送信によって発生する追加のネットワークオーバーヘッドを犠牲にして、リレーセットの選択や近隣トポロジ情報の必要性がなくなります。 CFでは、SMF DPD機能が引き続き必要です。 SMFは動作モードとしてCFをサポートしますが、不要なパケットの再送信による競合と輻輳を減らすために、より効率的なリレーセットモードの使用を推奨します[NTSC99]。
An efficient reduced relay set is constructed by selecting and updating, as needed, a subset of all possible routers in a MANET routing domain to act as SMF forwarders. Known distributed relay set selection algorithms have demonstrated the ability to provide and maintain a dynamic connected set for forwarding multicast IP packets [MDC04]. A few such relay set selection algorithms are described in the appendices of this document, and the basic designs borrow directly from previously documented IETF work. SMF relay set configuration is extensible, and additional relay set algorithms beyond those specified here can be accommodated in future work.
効率的な削減されたリレーセットは、SMFフォワーダーとして機能するMANETルーティングドメイン内のすべての可能なルーターのサブセットを必要に応じて選択および更新することによって構築されます。既知の分散リレーセット選択アルゴリズムは、マルチキャストIPパケットを転送するための動的接続セットを提供および維持する機能を実証しています[MDC04]。このようなリレーセット選択アルゴリズムのいくつかは、このドキュメントの付録に記載されており、基本的な設計は以前にドキュメント化されたIETFの作業から直接借用しています。 SMFリレーセット構成は拡張可能であり、ここで指定されたものを超える追加のリレーセットアルゴリズムは、将来の作業に対応できます。
Determining and maintaining an optimized set of relays generally requires dynamic neighborhood topology information. Neighborhood topology discovery functions MAY be provided by a MANET unicast routing protocol or by using the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130], operating concurrently with SMF. This specification also allows alternative lower-layer interfaces (e.g., radio router interfaces) to provide the necessary neighborhood information to aid in supporting more effective relay set selection. An SMF implementation SHOULD provide the ability for multicast forwarding state to be dynamically managed per operating network interface. The relay state maintenance options and interactions are outlined in Section 7. This document states specific requirements
最適化されたリレーのセットを決定して維持するには、通常、動的な近隣トポロジ情報が必要です。近傍トポロジー発見機能は、MANETユニキャストルーティングプロトコルによって、またはSMFと同時に動作するMANET近傍発見プロトコル（NHDP）[RFC6130]を使用して提供される場合があります。この仕様により、代替の下位層インターフェイス（無線ルーターインターフェイスなど）が必要な近隣情報を提供して、より効果的なリレーセットの選択をサポートできるようになります。 SMF実装は、動作中のネットワークインターフェイスごとに動的に管理されるマルチキャスト転送状態の機能を提供する必要があります（SHOULD）。リレー状態のメンテナンスオプションと相互作用については、セクション7で概説しています。このドキュメントでは、特定の要件について説明します
for neighborhood discovery with respect to the forwarding process and the relay set selection algorithms described herein. For determining dynamic relay sets in the absence of other control protocols, SMF relies on NHDP to assist in IP-layer 2-hop neighborhood discovery and maintenance for relay set selection. "SMF_TYPE" and "SMF_NBR_TYPE" Message and Address Block TLV structures (per [RFC5444]) are defined by this document for use with NHDP to carry SMF-specific information. It is RECOMMENDED that all routers performing SMF operation in conjunction with NHDP include these TLV types in any NHDP HELLO messages generated. This capability allows for routers participating in SMF to be explicitly identified along with their respective dynamic relay set algorithm configuration.
本明細書に記載されている転送プロセスおよびリレーセット選択アルゴリズムに関する近隣発見のため。他の制御プロトコルがない場合に動的リレーセットを決定するために、SMFはリレーセット選択のためのIPレイヤー2ホップネイバーディスカバリーの発見と保守を支援するためにNHDPに依存しています。 「SMF_TYPE」および「SMF_NBR_TYPE」メッセージおよびアドレスブロックTLV構造（[RFC5444]ごと）は、SMF固有の情報を伝えるためにNHDPで使用するために、このドキュメントで定義されています。 NHDPと組み合わせてSMF操作を実行するすべてのルーターが、生成されるすべてのNHDP HELLOメッセージにこれらのTLVタイプを含めることをお勧めします。この機能により、SMFに参加しているルーターを、それぞれの動的リレーセットアルゴリズム構成とともに明示的に識別することができます。
The SMF packet processing and forwarding actions are conducted with the following packet handling activities:
SMFパケット処理および転送アクションは、次のパケット処理アクティビティで実行されます。
1. Processing of outbound, locally generated multicast packets.
1. ローカルに生成された発信マルチキャストパケットの処理。
2. Reception and processing of inbound packets on specific network interfaces.
2. 特定のネットワークインターフェイスでの受信パケットの受信と処理。
The purpose of intercepting outbound, locally generated multicast packets is to apply any added packet marking needed to satisfy the DPD requirements so that proper forwarding may be conducted. Note that for some system configurations, the interception of outbound packets for this purpose is not necessary.
ローカルで生成されたアウトバウンドマルチキャストパケットを傍受する目的は、DPD要件を満たすために必要な追加のパケットマーキングを適用して、適切な転送を実行できるようにすることです。一部のシステム構成では、この目的で送信パケットを傍受する必要がないことに注意してください。
Inbound multicast packets are received by the SMF implementation and processed for possible forwarding. SMF implementations MUST be capable of forwarding IP multicast packets with destination addresses that are not router-local and link-local for IPv6, as defined in [RFC4291], and that are not within the local network control block as defined by [RFC5771].
インバウンドマルチキャストパケットは、SMF実装によって受信され、可能な転送のために処理されます。 SMF実装は、[RFC4291]で定義されているように、ルーターローカルでもIPv6のリンクローカルでもない、[RFC5771]で定義されているローカルネットワーク制御ブロック内にない宛先アドレスを持つIPマルチキャストパケットを転送できる必要があります。
This will support generic multi-hop multicast application needs or distribute designated multicast traffic ingressing the SMF routing domain via border routers. The multicast addresses to be forwarded should be maintained by an a priori list or a dynamic forwarding information base (FIB) that MAY interact with future MANET dynamic group membership extensions or management functions.
これは、一般的なマルチホップマルチキャストアプリケーションのニーズをサポートするか、境界ルーター経由でSMFルーティングドメインに入る指定のマルチキャストトラフィックを配信します。転送されるマルチキャストアドレスは、将来のMANET動的グループメンバーシップ拡張または管理機能と相互作用する可能性があるアプリオリリストまたは動的転送情報ベース（FIB）によって維持される必要があります。
The SL-MANET-ROUTERS multicast group is defined to contain all routers within an SMF routing domain, so that packets transmitted to the multicast address associated with the group will be attempted to be delivered to all connected routers running SMF. Due to the mobile nature of a MANET, routers running SMF may not be topologically connected at particular times. For IPv6, SL-MANET-ROUTERS is specified to be "site-local". Minimally, SMF MUST forward, as instructed by the relay set selection algorithm, unique (non-duplicate) packets received for SL-MANET-ROUTERS when the Time to Live (TTL) / hop limit or hop limit value in the IP header is greater than 1. SMF MUST forward all additional global-scope multicast addresses specified within the dynamic FIB or configured list as well. In all cases, the following rules MUST be observed for SMF multicast forwarding:
SL-MANET-ROUTERSマルチキャストグループは、SMFルーティングドメイン内のすべてのルーターを含むように定義されているため、グループに関連付けられたマルチキャストアドレスに送信されたパケットは、SMFを実行している接続されたすべてのルーターに配信されます。 MANETのモバイル性により、SMFを実行しているルーターは、特定の時間にトポロジ的に接続されない場合があります。 IPv6の場合、SL-MANET-ROUTERSは「サイトローカル」に指定されます。最小で、SMFは、リレーセット選択アルゴリズムの指示に従って、IPヘッダーの存続可能時間（TTL）/ホップ制限またはホップ制限値が大きい場合にSL-MANET-ROUTERSに対して受信した一意の（重複しない）パケットを転送する必要があります。 SMFは、動的FIBまたは構成済みリスト内で指定されているすべての追加のグローバルスコープマルチキャストアドレスも転送する必要があります。すべての場合において、SMFマルチキャスト転送では、以下の規則を遵守する必要があります。
1. Any IP packets not addressed to an IP multicast address MUST NOT be forwarded by the SMF forwarding engine.
1. IPマルチキャストアドレスにアドレス指定されていないIPパケットは、SMF転送エンジンによって転送されてはなりません（MUST NOT）。
2. IP multicast packets with TTL/hop limit <= 1 MUST NOT be forwarded.
2. TTL /ホップ制限が1以下のIPマルチキャストパケットは転送してはなりません（MUST NOT）。
3. Link local IP multicast packets MUST NOT be forwarded.
3. リンクローカルIPマルチキャストパケットは転送してはなりません。
4. Incoming IP multicast packets with an IP source address matching one of those of the local SMF router interface(s) MUST NOT be forwarded.
4. ローカルSMFルーターインターフェースのいずれかと一致するIP送信元アドレスを持つ着信IPマルチキャストパケットは、転送してはなりません（MUST NOT）。
5. Received frames with the Media Access Control (MAC) source address matching any MAC address of the router's interfaces MUST NOT be forwarded.
5. メディアアクセスコントロール（MAC）送信元アドレスがルーターのインターフェイスのMACアドレスと一致する受信フレームは転送してはなりません（MUST NOT）。
6. Received packets for which SMF cannot reasonably ensure temporal DPD uniqueness MUST NOT be forwarded.
6. SMFが一時的なDPDの一意性を合理的に保証できない受信パケットは転送してはなりません（MUST NOT）。
7. Prior to being forwarded, the TTL/hop limit of the forwarded packet MUST be decremented by one.
7. 転送される前に、転送されたパケットのTTL /ホップ制限は1だけ減らされなければなりません（MUST）。
Note that rule #4 is important because over some types of wireless interfaces, the originating SMF router may receive retransmissions of its own packets when they are forwarded by adjacent routers. This rule avoids unnecessary retransmission of locally generated packets even when other forwarding decision rules would apply.
ルール4は重要です。ワイヤレスインターフェイスのタイプによっては、発信元のSMFルーターが隣接ルーターによって転送されるときに、独自のパケットの再送信を受信する場合があるためです。このルールは、他の転送決定ルールが適用される場合でも、ローカルで生成されたパケットの不要な再送信を回避します。
An additional processing rule also needs to be considered based upon a potential security threat. As discussed in Section 10, there is a potential DoS attack that can be conducted by remotely "previewing" (e.g., via a directional receive antenna) packets that an SMF router would be forwarding and conducting a "pre-play" attack by transmitting the packet before the SMF router would otherwise receive it, but with a reduced TTL/hop limit field value. This form of attack can cause an SMF router to create a DPD entry that would block the proper forwarding of the valid packet (with correct TTL/hop limit) through the SMF routing domain. A RECOMMENDED approach to prevent this attack, when it is a concern, would be to cache temporal packet TTL/hop limit values along with the per-packet DPD state (hash value(s) and/or identifier as described in Section 6). Then, if a subsequent matching (with respect to DPD) packet arrives with a larger TTL/hop limit value than the packet that was previously forwarded, SMF should forward the new packet and update the TTL/hop limit value cached with corresponding DPD state to the new, larger TTL/hop limit value. There may be temporal cases where SMF would unnecessarily forward some duplicate packets using this approach, but those cases are expected to be minimal and acceptable when compared with the potential threat of denied service.
潜在的なセキュリティの脅威に基づいて、追加の処理ルールも検討する必要があります。セクション10で説明したように、SMFルーターが転送して「プレプレイ」攻撃を行うパケットをリモートで「プレビュー」（たとえば、指向性受信アンテナを介して）することにより、DoS攻撃を行う可能性があります。それ以外の場合はSMFルーターがパケットを受信する前にパケットを送信しますが、TTL /ホップ制限フィールドの値は小さくなります。この形式の攻撃により、SMFルーターがDPDエントリを作成し、SMFルーティングドメインを介した有効なパケット（正しいTTL /ホップ制限）の適切な転送をブロックする可能性があります。この攻撃を防ぐために推奨されるアプローチは、懸念がある場合は、一時的なパケットのTTL /ホップ制限値をパケットごとのDPD状態（セクション6で説明したハッシュ値や識別子）とともにキャッシュすることです。次に、（DPDに関して）後続の一致するパケットが、以前に転送されたパケットよりも大きいTTL /ホップ制限値で到着した場合、SMFは新しいパケットを転送し、対応するDPD状態でキャッシュされたTTL /ホップ制限値を新しい、より大きなTTL /ホップ制限値。 SMFがこのアプローチを使用して一部の重複パケットを不必要に転送する一時的なケースがあるかもしれませんが、これらのケースは、サービス拒否の潜在的な脅威と比較した場合、最小限で許容できると予想されます。
Once the SMF multicast forwarding rules have been applied, an SMF implementation MUST make a forwarding decision dependent upon the relay set selection algorithm in use. If the SMF implementation is using Classic Flooding (CF), the forwarding decision is implicit once DPD uniqueness is determined. Otherwise, a forwarding decision depends upon the current interface-specific relay set state. The descriptions of the relay set selection algorithms in the appendices to this document specify the respective heuristics for multicast packet forwarding and specific DPD or other processing required to achieve correct SMF behavior in each case. For example, one class of forwarding is based upon relay set selection status and the packet's previous hop, while other classes designate the local SMF router as a forwarder for all neighboring routers.
SMFマルチキャスト転送ルールが適用されると、SMF実装は、使用中のリレーセット選択アルゴリズムに応じて転送を決定する必要があります。 SMF実装がクラシックフラッディング（CF）を使用している場合、DPDの一意性が決定されると、転送の決定は暗黙的に行われます。それ以外の場合、転送の決定は、現在のインターフェイス固有のリレーセットの状態によって異なります。このドキュメントの付録にあるリレーセット選択アルゴリズムの説明では、マルチキャストパケット転送のそれぞれのヒューリスティックと、それぞれの場合に正しいSMF動作を実現するために必要な特定のDPDまたはその他の処理を指定しています。たとえば、転送の1つのクラスは、リレーセットの選択ステータスとパケットの以前のホップに基づいていますが、他のクラスは、ローカルSMFルーターをすべての隣接ルーターのフォワーダーとして指定します。
Duplicate packet detection (DPD) is often a requirement in MANET or wireless mesh packet forwarding mechanisms because packets may be transmitted out via the same physical interface as the one over which they were received. Routers may also receive multiple copies of the same packets from different neighbors or interfaces. SMF operation requires DPD, and implementations MUST provide mechanisms to detect and reduce the likelihood of forwarding duplicate multicast packets using temporal packet identification. It is RECOMMENDED this be implemented by keeping a history of recently processed multicast packets for comparison with incoming packets. A DPD packet cache history SHOULD be kept long enough so as to span the maximum network traversal lifetime, MAX_PACKET_LIFETIME, of multicast packets being forwarded within an SMF routing domain. The DPD mechanism SHOULD avoid keeping unnecessary state for packet flows such as those that are locally generated or link-local destinations that would not be considered for forwarding, as presented in Section 5.
パケットは、パケットが受信されたのと同じ物理インターフェースを介して送信される可能性があるため、重複パケット検出（DPD）は、多くの場合MANETまたはワイヤレスメッシュパケット転送メカニズムの要件です。ルーターは、異なるネイバーまたはインターフェイスから同じパケットの複数のコピーを受信することもあります。 SMF操作にはDPDが必要であり、実装は、一時的なパケット識別を使用して重複マルチキャストパケットを転送する可能性を検出して削減するメカニズムを提供する必要があります。着信パケットと比較するために、最近処理されたマルチキャストパケットの履歴を保持することにより、これを実装することをお勧めします。 DPDパケットキャッシュ履歴は、SMFルーティングドメイン内で転送されるマルチキャストパケットの最大ネットワークトラバーサルライフタイム（MAX_PACKET_LIFETIME）に及ぶように十分長く維持する必要があります（SHOULD）。セクション5に示すように、DPDメカニズムは、ローカルで生成されたパケットフローや、転送とは見なされないリンクローカルの宛先など、パケットフローの不要な状態を維持しないようにする必要があります（SHOULD）。
For both IPv4 and IPv6, this document describes two basic multicast duplicate packet detection mechanisms: header content identification-based (I-DPD) and hash-based (H-DPD) duplicate packet detection.
このドキュメントでは、IPv4とIPv6の両方について、2つの基本的なマルチキャスト重複パケット検出メカニズムについて説明します。ヘッダーコンテンツ識別ベース（I-DPD）とハッシュベース（H-DPD）の重複パケット検出です。
I-DPD is a mechanism using specific packet headers, and option headers in the case of IPv6, in combination with flow state to estimate the temporal uniqueness of a packet. H-DPD uses hashing over header fields and payload of a multicast packet to provide an estimation of temporal uniqueness.
I-DPDは、特定のパケットヘッダー、およびIPv6の場合はオプションヘッダーをフロー状態と組み合わせて使用して、パケットの一時的な一意性を推定するメカニズムです。 H-DPDは、マルチキャストパケットのヘッダーフィールドとペイロードに対するハッシュを使用して、時間的な一意性の推定を提供します。
Trade-offs of the two approaches to DPD merit different considerations dependent upon the specific SMF deployment scenario.
DPDに対する2つのアプローチのトレードオフは、特定のSMF配備シナリオに応じて異なる考慮事項に値します。
Because of the potential addition of a hop-by-hop option header with IPv6, all SMF routers in the same SMF deployments MUST be configured so as to use a common mechanism and DPD algorithm. The main difference between IPv4 and IPv6 SMF DPD specifications is the avoidance of any additional header options for IPv4.
IPv6ではホップバイホップオプションヘッダーが追加される可能性があるため、同じSMF展開内のすべてのSMFルーターは、共通のメカニズムとDPDアルゴリズムを使用するように構成する必要があります。 IPv4とIPv6のSMF DPD仕様の主な違いは、IPv4の追加のヘッダーオプションが省略されていることです。
For each network interface, SMF implementations MUST maintain DPD packet state as needed to support the forwarding heuristics of the relay set algorithm used. In general, this involves keeping track of previously forwarded packets so that duplicates are not forwarded, but some relay techniques have additional considerations, such as those discussed in Appendix B.2.
各ネットワークインターフェイスでは、SMF実装は、使用されるリレーセットアルゴリズムの転送ヒューリスティックをサポートするために、必要に応じてDPDパケット状態を維持する必要があります。一般に、これには以前に転送されたパケットを追跡して重複が転送されないようにすることが含まれますが、一部のリレー手法には、付録B.2で説明されているような追加の考慮事項があります。
Additional details of I-DPD and H-DPD processing and maintenance for different classes of packets are described in the following subsections.
さまざまなクラスのパケットのI-DPDおよびH-DPD処理とメンテナンスの詳細については、次のサブセクションで説明します。
This section describes the mechanisms and options for SMF IPv6 DPD. The base IPv6 packet header does not provide an explicit packet identification header field that can be exploited for I-DPD. The following options are therefore described to support IPv6 DPD:
このセクションでは、SMF IPv6 DPDのメカニズムとオプションについて説明します。基本IPv6パケットヘッダーは、I-DPDに利用できる明示的なパケット識別ヘッダーフィールドを提供しません。したがって、IPv6 DPDをサポートするために以下のオプションが説明されています。
1. a hop-by-hop SMF_DPD option header, defined in this document (Section 6.1.1),
1. このドキュメントで定義されているホップバイホップのSMF_DPDオプションヘッダー（セクション6.1.1）、
2. the use of IPv6 fragment header fields for I-DPD, if one is present (Section 6.1.2),
2. I-DPDのIPv6フラグメントヘッダーフィールドの使用（存在する場合）（セクション6.1.2）
3. the use of IPsec sequencing for I-DPD when a non-fragmented, IPsec header is detected (Section 6.1.2), and
3. 断片化されていないIPsecヘッダーが検出された場合のI-DPDのIPsecシーケンスの使用（セクション6.1.2）、および
4. an H-DPD approach assisted, as needed, by the SMF_DPD option header (Section 6.1.3).
4. H-DPDアプローチは、必要に応じて、SMF_DPDオプションヘッダーによって支援されます（セクション6.1.3）。
SMF MUST provide a DPD marking module that can insert the hop-by-hop IPv6 header option, defined in Section 6.1.1. This module MUST be invoked after any source-based fragmentation that may occur with IPv6, so as to ensure that all fragments are suitably marked. SMF IPv6 DPD is presently specified to allow either a packet hash or header identification method for DPD. An SMF implementation MUST be configured to operate either in I-DPD or H-DPD mode and perform the corresponding tasks, outlined in Sections 6.1.2 and 6.1.3.
SMFは、セクション6.1.1で定義されているホップバイホップIPv6ヘッダーオプションを挿入できるDPDマーキングモジュールを提供する必要があります。このモジュールは、すべてのフラグメントが適切にマークされるようにするために、IPv6で発生する可能性のあるソースベースの断片化の後に呼び出す必要があります。 SMF IPv6 DPDは現在、DPDのパケットハッシュまたはヘッダー識別方法を許可するように指定されています。 SMF実装は、セクション6.1.2および6.1.3で概説されているI-DPDモードまたはH-DPDモードのいずれかで動作し、対応するタスクを実行するように構成する必要があります。
This section defines an IPv6 Hop-by-Hop Option [RFC2460], SMF_DPD, to serve the purpose of unique packet identification for IPv6 I-DPD. Additionally, the SMF_DPD option header provides a mechanism to guarantee non-collision of hash values for different packets when H-DPD is used.
このセクションでは、IPv6 I-DPDの一意のパケット識別の目的に役立つIPv6ホップバイホップオプション[RFC2460]、SMF_DPDを定義します。さらに、SMF_DPDオプションヘッダーは、H-DPDが使用されている場合に、異なるパケットのハッシュ値の非衝突を保証するメカニズムを提供します。
If this is the only hop-by-hop option present, the optional TaggerId field (see below) is not included, and the size of the DPD packet identifier (sequence number) or hash token is 24 bits or less, this will result in the addition of 8 bytes to the IPv6 packet header including the "Next Header", "Header Extension Length", SMF_DPD option fields, and padding.
これが唯一のホップバイホップオプションであり、オプションのTaggerIdフィールド（下記を参照）が含まれておらず、DPDパケット識別子（シーケンス番号）またはハッシュトークンのサイズが24ビット以下の場合、これにより、 「Next Header」、「Header Extension Length」、SMF_DPDオプションフィールド、およびパディングを含むIPv6パケットヘッダーへの8バイトの追加。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... |0|0|0| 01000 | Opt. Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H| DPD Identifier Option Fields or Hash Assist Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPv6 SMF_DPD Hop-by-Hop Option Header
図2：IPv6 SMF_DPDホップバイホップオプションヘッダー
"Option Type" = 00001000. The highest order three bits are 000 because this specification requires that routers not recognizing this option type skip over this option and continue processing the header and that the option must not change en route [RFC2460].
「オプションタイプ」=00001000。この仕様では、このオプションタイプを認識しないルータがこのオプションをスキップしてヘッダーの処理を続行し、オプションが途中で変更されないようにする必要があるため、最上位の3ビットは000です[RFC2460]。
"Opt. Data Len" = Length of option content (i.e., 1 + (<IdType> ? (<IdLen> + 1): 0) + Length(DPD ID)).
"Opt。Data Len" =オプションコンテンツの長さ（つまり、1 +（<IdType>？（<IdLen> + 1）：0）+ Length（DPD ID））。
"H-bit" = a hash indicator bit value identifying DPD marking type. 0 == sequence-based approach with optional TaggerId and a tuple-based sequence number. 1 == indicates a hash assist value (HAV) field follows to aid in avoiding hash-based DPD collisions.
「Hビット」= DPDマーキングタイプを識別するハッシュインジケータビット値。 0 ==オプションのTaggerIdとタプルベースのシーケンス番号を使用したシーケンスベースのアプローチ。 1 ==は、ハッシュベースのDPD衝突を回避するために役立つ、ハッシュアシスト値（HAV）フィールドが続くことを示します。
When the "H-bit" is cleared (zero value), the SMF_DPD format to support I-DPD operation is specified as shown in Figure 3 and defines the extension header in accordance with [RFC2460].
「Hビット」がクリアされると（ゼロ値）、I-DPD操作をサポートするSMF_DPDフォーマットが図3に示されているように指定され、[RFC2460]に従って拡張ヘッダーを定義します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... |0|0|0| 01000 | Opt. Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|TidTy| TidLen| TaggerId (optional) ... |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv6 SMF_DPD Option Header in I-DPD mode
図3：I-DPDモードのIPv6 SMF_DPDオプションヘッダー
"TidTy" = a 3-bit field indicating the presence and type of the optional TaggerId field.
"TidTy" =オプションのTaggerIdフィールドの存在とタイプを示す3ビットのフィールド。
"TidLen" = a 4-bit field indicating the length (in octets) of the following TaggerId field.
"TidLen" =次のTaggerIdフィールドの長さ（オクテット単位）を示す4ビットのフィールド。
"TaggerId" = a field, is used to differentiate multiple ingressing border gateways that may commonly apply the SMF_DPD option header to packets from a particular source. Table 1 lists the TaggerId types used in this document:
"TaggerId" =フィールドは、SMF_DPDオプションヘッダーを特定のソースからのパケットに一般的に適用する可能性がある複数の入力ボーダーゲートウェイを区別するために使用されます。表1は、このドキュメントで使用されているTaggerIdタイプの一覧です。
+---------+---------------------------------------------------------+
| Name | Purpose |
+---------+---------------------------------------------------------+
| NULL | Indicates no TaggerId field is present. "TidLen" MUST |
| | also be set to ZERO. |
| DEFAULT | A TaggerId of non-specific context is present. "TidLen |
| | + 1" defines the length of the TaggerId field in bytes. |
| IPv4 | A TaggerId representing an IPv4 address is present. The |
| | "TidLen" MUST be set to 3. |
| IPv6 | A TaggerId representing an IPv6 address is present. The |
| | "TidLen" MUST be set to 15. |
+---------+---------------------------------------------------------+
Table 1: TaggerId Types
表1：TaggerIdタイプ
This format allows a quick check of the "TidTy" field to determine if a TaggerId field is present. If "TidTy" is NULL, then the length of the DPD packet <Identifier> field corresponds to (<Opt. Data Len> - 1). If the <TidTy> is non-NULL, then the length of the TaggerId field is equal to (<TidLen> - 1), and the remainder of the option data comprises the DPD packet <Identifier> field. When the TaggerId field is present, the <Identifier> field can be considered a unique packet identifier in the context of the <TaggerId:srcAddr:dstAddr> tuple. When the TaggerId field is not present, then it is assumed that the source applied the SMF_DPD option and the <Identifier> can be considered unique in the context of the IPv6 packet header <srcAddr:dstAddr> tuple. IPv6 I-DPD operation details are in Section 6.1.2.
この形式では、「TidTy」フィールドをすばやくチェックして、TaggerIdフィールドが存在するかどうかを確認できます。 「TidTy」がNULLの場合、DPDパケットの<Identifier>フィールドの長さは（<Opt。Data Len>-1）に対応します。 <TidTy>がNULL以外の場合、TaggerIdフィールドの長さは（<TidLen>-1）に等しく、オプションデータの残りの部分はDPDパケットの<Identifier>フィールドで構成されます。 TaggerIdフィールドが存在する場合、<Identifier>フィールドは、<TaggerId：srcAddr：dstAddr>タプルのコンテキストで一意のパケット識別子と見なすことができます。 TaggerIdフィールドが存在しない場合、SMF_DPDオプションを適用したソースと<Identifier>は、IPv6パケットヘッダー<srcAddr：dstAddr>タプルのコンテキストで一意と見なすことができると想定されます。 IPv6 I-DPD動作の詳細は、セクション6.1.2にあります。
When the "H-bit" in the SMF_DPD option data is set, the data content value is interpreted as a hash assist value (HAV) used to facilitate H-DPD operation. In this case, the source or ingressing gateways apply the SMF_DPD with an HAV only when required to differentiate the hash value of a new packet with respect to hash values in the DPD cache. This situation can be detected locally on the router by running the hash algorithm and checking the DPD cache, prior to ingressing a previously unmarked packet or a locally sourced packet. This helps to guarantee the uniqueness of generated hash values when H-DPD is used. Additionally, this avoids the added overhead of applying the SMF_DPD option header to every packet. For many hash algorithms, it is expected that only sparse use of the SMF_DPD option may be required. The format of the SMF_DPD option header for H-DPD operation is given in Figure 4.
SMF_DPDオプションデータの「Hビット」が設定されている場合、データコンテンツ値は、H-DPD操作を容易にするために使用されるハッシュアシスト値（HAV）として解釈されます。この場合、ソースまたは入力ゲートウェイは、DPDキャッシュ内のハッシュ値に関して新しいパケットのハッシュ値を区別する必要がある場合にのみ、HAVを使用してSMF_DPDを適用します。この状況は、以前にマークされていないパケットまたはローカルで送信されたパケットを入力する前に、ハッシュアルゴリズムを実行してDPDキャッシュをチェックすることにより、ルーターでローカルに検出できます。これは、H-DPDが使用されるときに生成されたハッシュ値の一意性を保証するのに役立ちます。さらに、これにより、SMF_DPDオプションヘッダーをすべてのパケットに適用するという追加のオーバーヘッドが回避されます。多くのハッシュアルゴリズムでは、SMF_DPDオプションのスパース使用のみが必要になることが予想されます。 H-DPD操作のSMF_DPDオプションヘッダーのフォーマットを図4に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... |0|0|0| OptType | Opt. Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Hash Assist Value (HAV) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv6 SMF_DPD Option Header in H-DPD Mode
図4：H-DPDモードのIPv6 SMF_DPDオプションヘッダー
The SMF_DPD option should be applied with an HAV to produce a unique hash digest for packets within the context of the IPv6 packet header <srcAddr>. The size of the HAV field is implied by "Opt. Data Len". The appropriate size of the field depends upon the collision properties of the specific hash algorithm used. More details on IPv6 H-DPD operation are provided in Section 6.1.3.
IPv6パケットヘッダー<srcAddr>のコンテキスト内でパケットの一意のハッシュダイジェストを生成するには、SMV_DPDオプションをHAVと共に適用する必要があります。 HAVフィールドのサイズは、「Opt。Data Len」によって暗示されます。フィールドの適切なサイズは、使用される特定のハッシュアルゴリズムの衝突プロパティによって異なります。 IPv6 H-DPD動作の詳細については、セクション6.1.3を参照してください。
Table 2 summarizes the IPv6 I-DPD processing and forwarding decision approach. Within the table, '*' indicates an ignore field condition.
表2は、IPv6 I-DPD処理および転送決定アプローチをまとめたものです。テーブル内で、「*」はフィールド無視条件を示します。
+-------------+-----------+-----------+-----------------------------+
| IPv6 | IPv6 | IPv6 | SMF IPv6 I-DPD Mode Action |
| Fragment | IPsec | I-DPD | |
| Header | Header | Header | |
+-------------+-----------+-----------+-----------------------------+
| Present | * | Not | Use Fragment Header I-DPD |
| | | Present | Check and Process for |
| | | | Forwarding |
| Not Present | Present | Not | Use IPsec Header I-DPD |
| | | Present | Check and Process for |
| | | | Forwarding |
| Present | * | Present | Invalid; do not forward. |
| Not Present | Present | Present | Invalid; do not forward. |
| Not Present | Not | Not | Add I-DPD Header, and |
| | Present | Present | Process for Forwarding |
| Not Present | Not | Present | Use I-DPD Header Check and |
| | Present | | Process for Forwarding |
+-------------+-----------+-----------+-----------------------------+
Table 2: IPv6 I-DPD Processing Rules
表2：IPv6 I-DPD処理ルール
1. If a received IPv6 multicast packet is an IPv6 fragment, SMF MUST use the fragment extension header fields for packet identification. This identifier can be considered unique in the context of the <srcAddr:dstAddr> of the IP packet.
1. 受信したIPv6マルチキャストパケットがIPv6フラグメントの場合、SMFはパケット識別のためにフラグメント拡張ヘッダーフィールドを使用する必要があります。この識別子は、IPパケットの<srcAddr：dstAddr>のコンテキストで一意と見なすことができます。
2. If the packet is an unfragmented IPv6 IPsec packet, SMF MUST use IPsec fields for packet identification. The IPsec header <sequence> field can be considered a unique identifier in the context of the <IPsecType:srcAddr:dstAddr:SPI> where "IPsecType" is either Authentication Header (AH) or Encapsulating Security Payload (ESP) [RFC4302].
2. パケットがフラグメント化されていないIPv6 IPsecパケットである場合、SMFはパケット識別にIPsecフィールドを使用する必要があります。 IPsecヘッダーの<sequence>フィールドは、<IPsecType：srcAddr：dstAddr：SPI>のコンテキストで一意の識別子と見なすことができます。「IPsecType」は、認証ヘッダー（AH）またはカプセル化セキュリティペイロード（ESP）[RFC4302]のいずれかです。
3. For unfragmented, non-IPsec IPv6 packets, the use of the SMF_DPD option header is necessary to support I-DPD operation. The SMF_DPD option header is applied in the context of the <srcAddr> of the IP packet. Hosts or ingressing SMF gateways are responsible for applying this option to support DPD. Table 3 summarizes these packet identification types:
3. フラグメント化されていない非IPsec IPv6パケットの場合、SMF_DPDオプションヘッダーを使用してI-DPD操作をサポートする必要があります。 SMF_DPDオプションヘッダーは、IPパケットの<srcAddr>のコンテキストで適用されます。ホストまたは入力SMFゲートウェイは、DPDをサポートするためにこのオプションを適用する必要があります。表3に、これらのパケット識別タイプを要約します。
+-----------+---------------------------------+---------------------+
| IPv6 | Packet DPD ID Context | Packet DPD ID |
| Packet | | |
| Type | | |
+-----------+---------------------------------+---------------------+
| Fragment | <srcAddr:dstAddr> | <fragmentOffset:id> |
| IPsec | <IPsecType:srcAddr:dstAddr:SPI> | <sequence> |
| Packet | | |
| Regular | <[TaggerId:]srcAddr:dstAddr> | <SMF_DPD option |
| Packet | | header id> |
+-----------+---------------------------------+---------------------+
Table 3: IPv6 I-DPD Packet Identification Types
表3：IPv6 I-DPDパケット識別タイプ
"IPsecType" is either Authentication Header (AH) or Encapsulating Security Payload (ESP).
「IPsecType」は、認証ヘッダー（AH）またはカプセル化セキュリティペイロード（ESP）のいずれかです。
The "TaggerId" is an optional field of the IPv6 SMF_DPD option header.
「TaggerId」は、IPv6 SMF_DPDオプションヘッダーのオプションフィールドです。
A default hash-based DPD approach (H-DPD) for use by SMF is specified as follows. An SHA-1 [RFC3174] hash of the non-mutable header fields, options fields, and data content of the IPv6 multicast packet is used to produce a 160-bit digest. The approach for calculating this hash value SHOULD follow the same guidelines described for calculating the Integrity Check Value (ICV) described in [RFC4302] with respect to non-mutable fields. This approach should have a reasonably low probability of digest collision when packet headers and content are varying. SHA-1 is being applied in SMF only to provide a low probability of collision and is not being used for cryptographic or authentication purposes. A history of the packet hash values SHOULD be maintained within the context of the IPv6 packet header <srcAddr>. SMF ingress points (i.e., source hosts or gateways) use this history to confirm that new packets are unique with respect to their hash value. The hash assist value (HAV) field described in Section 6.1.1 is provided as a differentiating field when a digest collision would otherwise occur. Note that the HAV is an immutable option field, and SMF MUST process any included HAV values (see Section 6.1.1) in its hash calculation.
SMFで使用するデフォルトのハッシュベースのDPDアプローチ（H-DPD）は、次のように指定されます。 IPv6マルチキャストパケットの非可変ヘッダーフィールド、オプションフィールド、およびデータコンテンツのSHA-1 [RFC3174]ハッシュは、160ビットのダイジェストを生成するために使用されます。このハッシュ値を計算するアプローチは、[RFC4302]で説明されている変更不可のフィールドに関して整合性チェック値（ICV）を計算するために説明されているのと同じガイドラインに従う必要があります。このアプローチでは、パケットヘッダーとコンテンツが変化するときに、ダイジェストの衝突の確率がかなり低くなるはずです。 SHA-1は、衝突の可能性を低くするためにのみSMFに適用されており、暗号化または認証の目的には使用されていません。パケットハッシュ値の履歴は、IPv6パケットヘッダー<srcAddr>のコンテキスト内で維持する必要があります（SHOULD）。 SMF入力ポイント（つまり、ソースホストまたはゲートウェイ）は、この履歴を使用して、新しいパケットがハッシュ値に関して一意であることを確認します。セクション6.1.1で説明されているハッシュアシスト値（HAV）フィールドは、ダイジェストの衝突が発生した場合に区別フィールドとして提供されます。 HAVは不変のオプションフィールドであり、SMFはハッシュ計算に含まれるHAV値（セクション6.1.1を参照）を処理する必要があることに注意してください。
If a packet results in a digest collision (i.e., by checking the H-DPD digest history) within the DPD cache kept by SMF forwarders, the packet SHOULD be silently dropped. If a digest collision is detected at an SMF ingress point, the H-DPD option header is constructed with a randomly generated HAV. An HAV is recalculated as needed to produce a non-colliding hash value prior to forwarding.
パケットがSMFフォワーダーによって保持されているDPDキャッシュ内でダイジェストの衝突を引き起こした場合（つまり、H-DPDダイジェストの履歴を確認した場合）、パケットは通知なく破棄される必要があります（SHOULD）。 SMF入力ポイントでダイジェストの衝突が検出された場合、H-DPDオプションヘッダーはランダムに生成されたHAVで構築されます。 HAVは、転送前に衝突しないハッシュ値を生成するために必要に応じて再計算されます。
The multicast packet is then forwarded with the added IPv6 SMF_DPD option header. A common hash approach MUST be used by SMF routers for the applied HAV to consistently avoid hash collision and thus inadvertent packet drops.
マルチキャストパケットは、追加されたIPv6 SMF_DPDオプションヘッダーとともに転送されます。適用されるHAVでハッシュの衝突を避け、それにより不注意なパケットドロップを回避するために、SMFルーターは一般的なハッシュアプローチを使用する必要があります。
The SHA-1 indexing and IPv6 HAV approaches are specified at present for consistency and robustness to suit experimental uses. Future approaches and experimentation may discover design trade-offs in hash robustness and efficiency worth considering. Enhancements MAY include reducing the maximum payload length that is processed, determining shorter indexes, or applying more efficient hashing algorithms. Use of the HAV functionality may allow for application of "lighter-weight" hashing techniques that might not have been initially considered otherwise due to poor collision properties. Such techniques could reduce packet-processing overhead and memory requirements.
SHA-1インデックス作成とIPv6 HAVアプローチは、実験的使用に適合するための一貫性と堅牢性のために現在指定されています。将来のアプローチと実験は、検討する価値のあるハッシュの堅牢性と効率における設計のトレードオフを発見するかもしれません。拡張には、処理される最大ペイロード長の削減、より短いインデックスの決定、またはより効率的なハッシュアルゴリズムの適用が含まれる場合があります。 HAV機能を使用すると、衝突プロパティが不十分なために最初は考慮されていなかった「より軽量な」ハッシュ技術を適用できる場合があります。このような技術により、パケット処理のオーバーヘッドとメモリ要件を削減できます。
This section describes the mechanisms and options for IPv4 DPD. The following areas are described to support IPv4 DPD:
このセクションでは、IPv4 DPDのメカニズムとオプションについて説明します。 IPv4 DPDをサポートするために、次の領域が説明されています。
1. the use of IPv4 fragment header fields for I-DPD when they exist (Section 6.2.1),
1. I-DPDが存在する場合のIPv4フラグメントヘッダーフィールドの使用（セクション6.2.1）、
2. the use of IPsec sequencing for I-DPD when a non-fragmented IPv4 IPsec packet is detected (Section 6.2.1), and
2. 断片化されていないIPv4 IPsecパケットが検出されたときのI-DPDのIPsecシーケンスの使用（セクション6.2.1）、および
3. an H-DPD approach(Section 6.2.2) when neither of the above cases can be applied.
3. 上記のいずれのケースも適用できない場合のH-DPDアプローチ（セクション6.2.2）。
Although the IPv4 datagram has a 16-bit Identification (ID) field as specified in [RFC0791], it cannot be relied upon for DPD purposes due to common computer operating system implementation practices and the reasons described in the updated specification of the IPv4 ID Field [IPV4-ID-UPDATE]. An SMF IPv4 DPD marking option like the IPv6 SMF_DPD option header is not specified since IPv4 header options are not as tractable for hosts as they are for IPv6. However, when IPsec is applied or IPv4 packets have been fragmented, the I-DPD approach can be applied reliably using the corresponding packet identifier fields described in Section 6.2.1. For the general IPv4 case (non-IPsec and non-fragmented packets), the H-DPD approach of Section 6.2.2 is RECOMMENDED.
[RFC0791]で指定されているように、IPv4データグラムには16ビットの識別（ID）フィールドがありますが、一般的なコンピューターオペレーティングシステムの実装方法と、IPv4 IDフィールドの更新された仕様で説明されている理由により、DPDの目的に依存することはできません[IPV4-ID-UPDATE]。 IPv6 SMF_DPDオプションヘッダーのようなSMF IPv4 DPDマーキングオプションは指定されていません。これは、IPv4ヘッダーオプションは、IPv6のホストほど扱いにくいためです。ただし、IPsecが適用されている場合、またはIPv4パケットがフラグメント化されている場合、セクション6.2.1で説明されている対応するパケット識別子フィールドを使用して、I-DPDアプローチを確実に適用できます。一般的なIPv4ケース（非IPsecおよび非フラグメントパケット）の場合、セクション6.2.2のH-DPDアプローチが推奨されます。
Since IPv4 SMF does not specify an option header, the interoperability constraints are looser than in the IPv6 version, and forwarders may operate with mixed H-DPD and I-DPD modes as long as they consistently perform the appropriate DPD routines outlined in the following sections. However, it is RECOMMENDED that a deployment be configured with a common mode for operational consistency.
IPv4 SMFはオプションヘッダーを指定しないため、相互運用性の制約はIPv6バージョンよりも緩やかであり、フォワーダーは、以下のセクションで説明する適切なDPDルーチンを一貫して実行する限り、H-DPDとI-DPDの混合モードで動作できます。 。ただし、運用の一貫性を保つために、共通モードで展開を構成することをお勧めします。
Table 4 summarizes the IPv4 I-DPD processing approach once a packet has passed the basic forwardable criteria described in Section 5. To summarize, for IPv4, I-DPD is applicable only for packets that have been fragmented or have IPsec applied. In Table 4, '*' indicates an ignore field condition. DF, MF, and Fragment offset correspond to related fields and flags defined in [RFC0791].
表4は、セクション5で説明した基本的な転送可能基準をパケットが通過した後のIPv4 I-DPD処理アプローチをまとめたものです。要約すると、IPv4の場合、I-DPDはフラグメント化されたパケットまたはIPsecが適用されたパケットにのみ適用できます。表4で、「*」はフィールド無視条件を示しています。 DF、MF、およびフラグメントのオフセットは、[RFC0791]で定義されている関連フィールドおよびフラグに対応しています。
+------+------+----------+---------+--------------------------------+
| DF | MF | Fragment | IPsec | IPv4 I-DPD Action |
| flag | flag | offset | | |
+------+------+----------+---------+--------------------------------+
| 1 | 1 | * | * | Invalid; do not forward. |
| 1 | 0 | nonzero | * | Invalid; do not forward. |
| * | 0 | zero | not | Use H-DPD check instead |
| | | | Present | |
| * | 0 | zero | Present | IPsec enhanced Tuple I-DPD |
| | | | | Check and Process for |
| | | | | Forwarding |
| 0 | 0 | nonzero | * | Extended Fragment Offset Tuple |
| | | | | I-DPD Check and Process for |
| | | | | Forwarding |
| 0 | 1 | zero or | * | Extended Fragment Offset Tuple |
| | | nonzero | | I-DPD Check and Process for |
| | | | | Forwarding |
+------+------+----------+---------+--------------------------------+
Table 4: IPv4 I-DPD Processing Rules
表4：IPv4 I-DPD処理ルール
For performance reasons, IPv4 network fragmentation and reassembly of multicast packets within wireless MANET networks should be minimized, yet SMF provides the forwarding of fragments when they occur. If the IPv4 multicast packet is a fragment, SMF MUST use the fragmentation header fields for packet identification. This identification can be considered temporally unique in the context of the <protocol:srcAddr: dstAddr> of the IPv4 packet. If the packet is an unfragmented IPv4 IPsec packet, SMF MUST use IPsec fields for packet identification. The IPsec header <sequence> field can be considered a unique identifier in the context of the <IPsecType:srcAddr:dstAddr:SPI> where "IPsecType" is either AH or ESP [RFC4302]. Table 5 summarizes these packet identification types:
パフォーマンス上の理由から、ワイヤレスMANETネットワーク内のマルチキャストパケットのIPv4ネットワークの断片化と再構成は最小限に抑える必要がありますが、SMFはフラグメントが発生したときにフラグメントの転送を提供します。 IPv4マルチキャストパケットがフラグメントである場合、SMFはパケット識別にフラグメンテーションヘッダーフィールドを使用する必要があります。この識別は、IPv4パケットの<protocol：srcAddr：dstAddr>のコンテキストで一時的に一意であると見なすことができます。パケットが断片化されていないIPv4 IPsecパケットである場合、SMFはパケットの識別にIPsecフィールドを使用する必要があります。 IPsecヘッダーの<sequence>フィールドは、<IPsecType：srcAddr：dstAddr：SPI>のコンテキストで一意の識別子と見なすことができます。「IPsecType」はAHまたはESP [RFC4302]です。表5に、これらのパケット識別タイプを要約します。
+-----------+---------------------------------+---------------------+
| IPv4 | Packet Identification Context | Packet Identifier |
| Packet | | |
| Type | | |
+-----------+---------------------------------+---------------------+
| Fragment | <protocol:srcAddr:dstAddr> | <fragmentOffset:id> |
| IPsec | <IPsecType:srcAddr:dstAddr:SPI> | <sequence> |
| Packet | | |
+-----------+---------------------------------+---------------------+
Table 5: IPv4 I-DPD Packet Identification Types
表5：IPv4 I-DPDパケット識別タイプ
"IPsecType" is either Authentication Header (AH) or Encapsulating Security Payload (ESP).
「IPsecType」は、認証ヘッダー（AH）またはカプセル化セキュリティペイロード（ESP）のいずれかです。
The hashing technique here is similar to that specified for IPv6 in Section 6.1.3, but the H-DPD header option with HAV is not considered. To ensure consistent IPv4 H-DPD operation among SMF routers, a default hashing approach is specified. A common DPD hashing algorithm for an SMF routing area is RECOMMENDED because colliding hash values for different packets result in "false positive" duplicate packet detection, and there is small probability that valid packets may be dropped based on the hashing technique used. Since the "hash assist value" approach is not available for IPv4, use of a common hashing approach minimizes the probability of hash collision packet drops over multiple hops of forwarding.
ここでのハッシュ手法は、セクション6.1.3でIPv6に指定されたものと似ていますが、HAVを使用したH-DPDヘッダーオプションは考慮されていません。 SMFルーター間でIPv4 H-DPD動作の一貫性を確保するために、デフォルトのハッシュアプローチが指定されています。 SMFルーティングエリアの一般的なDPDハッシュアルゴリズムは推奨されます。これは、異なるパケットのハッシュ値が衝突すると「偽陽性」の重複パケットが検出され、使用されているハッシュ手法に基づいて有効なパケットがドロップされる可能性が低いためです。 「ハッシュアシスト値」アプローチはIPv4では使用できないため、一般的なハッシュアプローチを使用すると、転送の複数のホップでハッシュ衝突パケットがドロップする確率が最小限に抑えられます。
SMF MUST perform a SHA-1 [RFC3174] hash of the immutable header fields, option fields, and data content of the IPv4 multicast packet resulting in a 160-bit digest. The approach for calculating the hash value SHOULD follow the same guidelines described for calculating the Integrity Check Value (ICV) described in [RFC4302] with respect to non-mutable fields. A history of the packet hash values SHOULD be maintained in the context of <protocol:srcAddr:dstAddr>. The context for IPv4 is more specific than that of IPv6 since the SMF_DPD HAV cannot be employed to mitigate hash collisions. A RECOMMENDED implementation detail for IPv4 H-DPD is to concatenate the 16-bit IPv4 ID value with the computed hash value as an extended DPD hash value that may provide reduced hash collisions in the cases where the IPv4 ID field is being set by host operating systems or gateways.
SMFは、不変のヘッダーフィールド、オプションフィールド、およびIPv4マルチキャストパケットのデータコンテンツのSHA-1 [RFC3174]ハッシュを実行して、160ビットのダイジェストを生成する必要があります。ハッシュ値を計算するためのアプローチは、[RFC4302]で説明されている変更不可のフィールドに関して整合性チェック値（ICV）を計算するために説明されているのと同じガイドラインに従う必要があります。パケットハッシュ値の履歴は、<protocol：srcAddr：dstAddr>のコンテキストで維持する必要があります（SHOULD）。 SMF_DPD HAVを使用してハッシュの衝突を緩和できないため、IPv4のコンテキストはIPv6のコンテキストよりも具体的です。 IPv4 H-DPDの推奨される実装の詳細は、16ビットIPv4 ID値を、計算されたハッシュ値と拡張DPDハッシュ値として連結し、ホストの操作によってIPv4 IDフィールドが設定されている場合にハッシュの衝突を減らすことができます。システムまたはゲートウェイ。
When this approach is taken, the use of the supplemental "internal hash" technique as described in Section 10 is RECOMMENDED as a security measure.
このアプローチを採用する場合は、セキュリティ対策として、セクション10で説明されている補足的な「内部ハッシュ」手法の使用をお勧めします。
The SHA-1 hash is specified at present for consistency and robustness. Future approaches and experimentation may discover design trade-offs in hash robustness and efficiency worth considering for future revisions of SMF. This MAY include reducing the packet payload length that is processed, determining shorter indexes, or applying a more efficient hashing algorithm.
SHA-1ハッシュは、一貫性と堅牢性のために現在指定されています。将来のアプローチと実験により、SMFの将来の改訂を検討する価値のあるハッシュの堅牢性と効率における設計上のトレードオフが見つかる可能性があります。これには、処理されるパケットペイロード長の短縮、より短いインデックスの決定、またはより効率的なハッシュアルゴリズムの適用が含まれる場合があります。
SMF is flexible in its support of different reduced relay set mechanisms for efficient flooding, the constraints imposed herein being detailed in this section.
SMFは、効率的なフラッディングのためのさまざまな削減されたリレーセットメカニズムを柔軟にサポートします。
SMF implementations MUST support CF as a basic forwarding mechanism when reduced relay set information is not available or not selected for operation. In CF mode, each router transmits a packet once that has passed the SMF forwarding rules. The DPD techniques described in Section 6 are critical to proper operation and prevention of duplicate packet retransmissions by the same relays.
SMF実装は、削減されたリレーセット情報が利用できないか、操作用に選択されていない場合、基本的な転送メカニズムとしてCFをサポートする必要があります。 CFモードでは、各ルーターは、SMF転送ルールを通過したパケットを送信します。セクション6で説明されているDPD技術は、適切な操作と、同じリレーによる重複パケット再送信の防止に不可欠です。
MANET reduced relay sets are often achieved by distributed algorithms that can dynamically calculate a topological connected dominating set (CDS).
MANETの削減されたリレーセットは、トポロジ的に接続された支配セット（CDS）を動的に計算できる分散アルゴリズムによって実現されることがよくあります。
A goal of SMF is to apply reduced relay sets for more efficient multicast dissemination within dynamic topologies. To accomplish this, an SMF implementation MUST support the ability to modify its multicast packet forwarding rules based upon relay set state received dynamically during operation. In this way, SMF operates effectively as neighbor adjacencies or multicast forwarding policies within the topology change.
SMFの目標は、動的トポロジー内でより効率的なマルチキャスト配布のために、削減されたリレーセットを適用することです。これを達成するには、SMF実装は、動作中に動的に受信されたリレーセットの状態に基づいてマルチキャストパケット転送ルールを変更する機能をサポートする必要があります。このようにして、SMFはトポロジー変更内のネイバー隣接またはマルチキャスト転送ポリシーとして効果的に動作します。
In early SMF experimental prototyping, the relay set information was derived from coexistent unicast routing control plane traffic flooding processes [MDC04]. From this experience, extra pruning considerations were sometimes required when utilizing a relay set from a separate routing protocol process. As an example, relay sets formed for the unicast control plane flooding MAY include additional redundancy that may not be desired for multicast forwarding use (e.g., biconnected relay set).
初期のSMF実験プロトタイピングでは、リレーセット情報は、共存するユニキャストルーティングコントロールプレーントラフィックフラッディングプロセス[MDC04]から導き出されました。この経験から、別のルーティングプロトコルプロセスからのリレーセットを利用する場合、追加のプルーニングに関する考慮事項が必要になる場合がありました。例として、ユニキャストコントロールプレーンフラッディング用に形成されたリレーセットには、マルチキャスト転送の使用には望ましくない可能性がある追加の冗長性が含まれる場合があります（たとえば、バイコネクトリレーセット）。
Here is a recommended criteria list for SMF relay set selection algorithm candidates:
SMFリレーセット選択アルゴリズム候補の推奨基準リストは次のとおりです。
1. Robustness to topological dynamics and mobility
1. トポロジーダイナミクスとモビリティに対する堅牢性
2. Localized election or coordination of any relay sets
2. リレーセットのローカライズされた選択または調整
3. Reasonable minimization of CDS relay set size given the above constraints
3. 上記の制約を前提としたCDSリレーセットサイズの合理的な最小化
4. Heuristic support for preference or election metrics
4. 選好または選挙の指標に対するヒューリスティックなサポート
Some relay set algorithms meeting these criteria are described in the appendices of this document. Additional relay set selection algorithms may be specified in separate specifications in the future. Each appendix subsection in this document can serve as a template for specifying additional relay algorithms.
これらの基準を満たすいくつかのリレーセットアルゴリズムは、このドキュメントの付録に記載されています。追加のリレーセット選択アルゴリズムは、将来、別の仕様で指定される可能性があります。このドキュメントの各付録のサブセクションは、追加のリレーアルゴリズムを指定するためのテンプレートとして使用できます。
Figure 5 depicts an information flow diagram of possible relay set control options. The SMF Relay Set State represents the information base that is used by SMF in the forwarding decision process. The diagram demonstrates that the SMF Relay Set State may be determined by three fundamentally different methods:
図5は、可能なリレーセット制御オプションの情報フロー図を示しています。 SMFリレーセット状態は、SMFが転送決定プロセスで使用する情報ベースを表します。この図は、SMFリレーセットの状態が3つの根本的に異なる方法で決定されることを示しています。
o Independent operation with NHDP [RFC6130] input providing dynamic network neighborhood adjacency information, used by a particular relay set selection algorithm.
o NHDP [RFC6130]入力を使用した独立した動作は、特定のリレーセット選択アルゴリズムで使用される動的なネットワーク隣接情報を提供します。
o Slave operation with an existing unicast MANET routing protocol, capable of providing CDS election information for use by SMF.
o 既存のユニキャストMANETルーティングプロトコルを使用したスレーブ操作。SMFで使用するCDS選定情報を提供できます。
o Cross-layer operation that may involve L2 triggers or information describing neighbors or links.
o L2トリガーまたはネイバーまたはリンクを説明する情報を含む可能性のあるクロスレイヤー操作。
Other heuristics to influence and control election can come from network management or other interfaces as shown on the right of Figure 5. CF mode simplifies the control and does not require other input but relies solely on DPD.
図5の右側に示すように、選出に影響を与えて制御する他のヒューリスティックは、ネットワーク管理または他のインターフェイスから取得できます。CFモードは制御を簡素化し、他の入力を必要とせず、DPDのみに依存します。
Possible L2 Trigger/Information
|
|
______________ ______v_____ __________________
| MANET | | | | |
| Neighborhood | | Relay Set | | Other Heuristics |
| Discovery |----------->| Selection |<------|(Preference, etc.)|
| Protocol | neighbor | Algorithm | | Net Management |
|______________| info |____________| |__________________|
\ /
\ /
neighbor\ / Dynamic Relay
info* \ ____________ / Set Status
\ | SMF | / (State, {neighbor info})
`-->| Relay Set |<--'
| State |
-->|____________|
/
/
______________
| Coexistent |
| MANET |
| Unicast |
| Process |
|______________|
Figure 5: SMF Reduced Relay Set Information Flow
図5：SMF削減リレーセットの情報フロー
Following is further discussion of the three styles of SMF operation with reduced relay sets as illustrated in Figure 5:
以下は、図5に示すように、リレーセットを削減したSMF操作の3つのスタイルの詳細な説明です。
1. Independent operation: In this case, SMF operates independently from any unicast routing protocols. To support reduced relay sets, SMF MUST perform its own relay set selection using information gathered from signaling. It is RECOMMENDED that an associated NHDP process be used for this signaling. NHDP messaging SHOULD be appended with additional [RFC5444] type-length-value (TLV) content as to support SMF-specific requirements as discussed in [RFC6130] and to support specific relay set operation as described in the appendices of this document or future specifications. Unicast routing protocols may coexist, even using the same NHDP process, but signaling that supports reduced relay set selection for SMF is independent of these protocols.
1. 独立した動作：この場合、SMFはユニキャストルーティングプロトコルから独立して動作します。リレーセットの削減をサポートするには、SMFは、シグナリングから収集した情報を使用して、独自のリレーセット選択を実行する必要があります。このシグナリングには、関連するNHDPプロセスを使用することをお勧めします。 [RFC6130]で説明されているSMF固有の要件をサポートし、このドキュメントの付録または将来の仕様で説明されている特定のリレーセット操作をサポートするには、NHDPメッセージングに[RFC5444] type-length-value（TLV）コンテンツを追加する必要があります（SHOULD）。 。ユニキャストルーティングプロトコルは、同じNHDPプロセスを使用しても共存できますが、SMFのリレーセット選択の削減をサポートするシグナリングは、これらのプロトコルから独立しています。
2. Operation with CDS-aware unicast routing protocol: In this case, a coexistent unicast routing protocol provides dynamic relay set state based upon its own control plane CDS or neighborhood discovery information.
2. CDS対応のユニキャストルーティングプロトコルによる操作：この場合、共存するユニキャストルーティングプロトコルは、独自のコントロールプレーンCDSまたは近隣探索情報に基づいて動的なリレーセットの状態を提供します。
3. Cross-layer operation: In this case, SMF operates using neighborhood status and triggers from a cross-layer information base for dynamic relay set selection and maintenance (e.g., lower-link layer).
3. クロスレイヤー操作：この場合、SMFは近隣ステータスを使用して動作し、ダイナミックリレーセットの選択とメンテナンス（下位リンクレイヤーなど）のためのクロスレイヤー情報ベースからトリガーします。
This section defines the requirements for use of the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] to support SMF operation. Note that basic CF forwarding requires no neighborhood topology knowledge since in this configured mode, every SMF router relays all traffic. Supporting more reduced SMF relay set operation requires the discovery and maintenance of dynamic neighborhood topology information. NHDP can be used to provide this necessary information; however, there are SMF-specific requirements for NHDP use. This is the case for both "independent" SMF operation where NHDP is being used specifically to support SMF or when one NHDP instance is used for both SMF and a coexistent MANET unicast routing protocol.
このセクションでは、SMF操作をサポートするためにMANET近隣探索プロトコル（NHDP）[RFC6130]を使用するための要件を定義します。この構成モードでは、すべてのSMFルーターがすべてのトラフィックを中継するため、基本的なCF転送には近隣トポロジの知識は必要ありません。さらに削減されたSMFリレーセット操作をサポートするには、動的な近隣トポロジ情報の検出とメンテナンスが必要です。 NHDPは、この必要な情報を提供するために使用できます。ただし、NHDPの使用にはSMF固有の要件があります。これは、NHDPが特にSMFをサポートするために使用されている「独立した」SMF操作、または1つのNHDPインスタンスがSMFと共存するMANETユニキャストルーティングプロトコルの両方に使用されている場合の両方に当てはまります。
NHDP HELLO messages and the resultant neighborhood information base are described separately within the NHDP specification. To summarize, NHDP provides the following basic functions:
NHDP HELLOメッセージと結果の近隣情報ベースは、NHDP仕様内で個別に説明されています。要約すると、NHDPは次の基本機能を提供します。
1. 1-hop neighbor link sensing and bidirectionality checks of neighbor links,
1. 1ホップのネイバーリンクセンシングとネイバーリンクの双方向性チェック
2. 2-hop neighborhood discovery including collection of 2-hop neighbors and connectivity information,
2. 2ホップのネイバー探索と接続情報を含む2ホップのネイバー探索
3. Collection and maintenance of the above information across multiple interfaces, and
3. 複数のインターフェースにわたる上記の情報の収集と保守、および
4. A method for signaling SMF information throughout the 2-hop neighborhood through the use of TLV extensions.
4. TLV拡張を使用して、2ホップの近隣全体にSMF情報をシグナリングする方法。
Appendices A-C of this document describe CDS-based relay set selection algorithms that can achieve efficient SMF operation, even in dynamic, mobile networks and each of the algorithms has been initially experimented with in a working SMF prototype [MDDA07]. When using these algorithms in conjunction with NHDP, a method verifying neighbor SMF operation is required in order to ensure correct relay set selection. NHDP, along with SMF operation verification, provides the necessary information required by these algorithms to conduct relay set selection. Verification of SMF operation may be done administratively or through the use of the SMF relay algorithms TLVs defined in the following subsections. Use of the SMF relay algorithm TLVs is RECOMMENDED when using NHDP for SMF neighborhood discovery.
このドキュメントの付録AからCは、動的なモバイルネットワークでも効率的なSMF動作を実現できるCDSベースのリレーセット選択アルゴリズムについて説明しており、各アルゴリズムは最初は実際のSMFプロトタイプ[MDDA07]で実験されています。これらのアルゴリズムをNHDPと組み合わせて使用する場合、リレーセットを正しく選択するには、ネイバーSMFの動作を確認する方法が必要です。 NHDPは、SMF動作検証とともに、リレーセットの選択を行うためにこれらのアルゴリズムに必要な情報を提供します。 SMF動作の検証は、管理上、または次のサブセクションで定義されているSMFリレーアルゴリズムTLVを使用して行うことができます。 SMF近隣探索にNHDPを使用する場合は、SMFリレーアルゴリズムTLVの使用をお勧めします。
Section 8.1 specifies SMF-specific TLV types, supporting general SMF operation or supporting the algorithms described in the appendices. The appendices describing several relay set algorithms also specify any additional requirements for use with NHDP and reference the applicable TLV types as needed.
セクション8.1は、SMF固有のTLVタイプを指定し、一般的なSMF操作をサポートするか、付録に記載されているアルゴリズムをサポートします。いくつかのリレーセットアルゴリズムを説明する付録では、NHDPで使用するための追加要件も指定し、必要に応じて該当するTLVタイプを参照しています。
This section specifies TLV types to be used within NHDP messages to identify the CDS relay set selection algorithm(s) in use. Two TLV types are defined: one Message TLV type and one Address Block TLV type.
このセクションでは、NHDPメッセージ内で使用されるTLVタイプを指定して、使用中のCDSリレーセット選択アルゴリズムを識別します。 2つのTLVタイプが定義されています。1つはメッセージTLVタイプで、もう1つはアドレスブロックTLVタイプです。
The Message TLV type denoted SMF_TYPE is used to identify the existence of an SMF instance operating in conjunction with NHDP. This Message TLV type makes use of the extended type field as defined by [RFC5444] to convey the CDS relay set selection algorithm currently in use by the SMF message originator. When NHDP is used to support SMF operation, the SMF_TYPE TLV, containing the extended type field with the appropriate value, SHOULD be included in NHDP_HELLO messages (HELLO messages as defined in [RFC6130]). This allows SMF routers to learn when neighbors are configured to use NHDP for information exchange including algorithm type and related algorithm information. This information can be used to take action, such as ignoring neighbor information using incompatible algorithms. It is possible that SMF neighbors MAY be configured differently and still operate cooperatively, but these cases will vary dependent upon the algorithm types designated.
SMF_TYPEで示されるメッセージTLVタイプは、NHDPと連動して動作するSMFインスタンスの存在を識別するために使用されます。このメッセージTLVタイプは、[RFC5444]で定義されている拡張タイプフィールドを利用して、SMFメッセージ発信者が現在使用しているCDSリレーセット選択アルゴリズムを伝達します。 NHDPを使用してSMF操作をサポートする場合、SMF_TYPE TLVは、適切な値を持つ拡張タイプフィールドを含み、NHDP_HELLOメッセージ（[RFC6130]で定義されているHELLOメッセージ）に含まれる必要があります（SHOULD）。これにより、SMFルーターは、ネイバーがNHDPを使用してアルゴリズムタイプや関連するアルゴリズム情報を含む情報交換に使用されるように設定されていることを学習できます。この情報は、互換性のないアルゴリズムを使用してネイバー情報を無視するなどのアクションを実行するために使用できます。 SMFネイバーが異なるように構成されていても、協調的に動作する可能性がありますが、これらのケースは、指定されたアルゴリズムタイプによって異なります。
This document defines a Message TLV type as specified in Table 6 conforming to [RFC5444]. The TLV extended type field is used to contain the sender's "Relay Algorithm Type". The interpretation of the "value" content of these TLVs is defined per "Relay Algorithm Type" and may contain algorithm-specific information.
このドキュメントは、[RFC5444]に準拠する表6で指定されているメッセージTLVタイプを定義します。 TLV拡張タイプフィールドは、送信者の「リレーアルゴリズムタイプ」を含めるために使用されます。これらのTLVの「値」コンテンツの解釈は、「リレーアルゴリズムタイプ」ごとに定義され、アルゴリズム固有の情報が含まれる場合があります。
+---------------+----------------+--------------------+
| | TLV Syntax | Field Values |
+---------------+----------------+--------------------+
| type | <tlv-type> | SMF_TYPE |
| extended type | <tlv-type-ext> | <relayAlgorithmId> |
| length | <length> | variable |
| value | <value> | variable |
+---------------+----------------+--------------------+
Table 6: SMF Type Message TLV
表6：SMFタイプメッセージTLV
In Table 6, <relayAlgorithmId> is an 8-bit field containing a number 0-255 representing the "Relay Algorithm Type" of the originator address of the corresponding NHDP message.
表6の<relayAlgorithmId>は、対応するNHDPメッセージの発信元アドレスの「リレーアルゴリズムタイプ」を表す0〜255の数字を含む8ビットのフィールドです。
Values for the <relayAlgorithmId> are defined in Table 7. The table provides value assignments, future IANA assignment spaces, and an experimental space. The experimental space use MUST NOT assume uniqueness; thus, it SHOULD NOT be used for general interoperable deployment prior to official IANA assignment.
<relayAlgorithmId>の値は、表7で定義されています。この表は、値の割り当て、将来のIANA割り当てスペース、および実験スペースを提供します。実験的な空間の使用は、一意性を仮定してはなりません。したがって、公式のIANA割り当ての前の一般的な相互運用可能な展開には使用しないでください。
+-------------+--------------------+--------------------------------+
| Type Value | Extended Type | Algorithm |
| | Value | |
+-------------+--------------------+--------------------------------+
| SMF_TYPE | 0 | CF |
| SMF_TYPE | 1 | S-MPR |
| SMF_TYPE | 2 | E-CDS |
| SMF_TYPE | 3 | MPR-CDS |
| SMF_TYPE | 4-127 | Future Assignment STD action |
| SMF_TYPE | 128-239 | No STD action required |
| SMF_TYPE | 240-255 | Experimental Space |
+-------------+--------------------+--------------------------------+
Table 7: SMF Relay Algorithm Type Values
表7：SMFリレーアルゴリズムタイプの値
Acceptable <length> and <value> fields of an SMF_TYPE TLV are dependent on the extended type value (i.e., relay algorithm type). The appropriate algorithm type, as conveyed in the <tlv-type-ext> field, defines the meaning and format of its TLV <value> field. For the algorithms defined by this document, see the appropriate appendix for the <value> field format.
SMF_TYPE TLVの受け入れ可能な<length>および<value>フィールドは、拡張タイプ値（つまり、リレーアルゴリズムタイプ）に依存します。 <tlv-type-ext>フィールドで伝達される適切なアルゴリズムタイプは、そのTLV <value>フィールドの意味と形式を定義します。このドキュメントで定義されているアルゴリズムについては、<value>フィールド形式の適切な付録を参照してください。
An Address Block TLV type, denoted SMF_NBR_TYPE (i.e., SMF neighbor relay algorithm) is specified in Table 8. This TLV enables CDS relay algorithm operation and configuration to be shared among 2-hop neighborhoods. Some relay algorithms require 2-hop neighbor configuration in order to correctly select relay sets. It is also useful when mixed relay algorithm operation is possible. Some examples of mixed use are outlined in the appendices.
SMF_NBR_TYPE（つまり、SMFネイバーリレーアルゴリズム）で表されるアドレスブロックTLVタイプを表8に示します。このTLVにより、CDSリレーアルゴリズムの動作と構成を2ホップの近隣間で共有できます。一部のリレーアルゴリズムでは、リレーセットを正しく選択するために2ホップのネイバー設定が必要です。また、混合リレーアルゴリズム操作が可能な場合にも役立ちます。付録では、混合使用のいくつかの例について概説しています。
The message SMF_TYPE TLV and Address Block SMF_NBR_TYPE TLV types share a common format.
メッセージSMF_TYPE TLVおよびアドレスブロックSMF_NBR_TYPE TLVタイプは、共通の形式を共有します。
+---------------+----------------+--------------------+
| | TLV syntax | Field Values |
+---------------+----------------+--------------------+
| type | <tlv-type> | SMF_NBR_TYPE |
| extended type | <tlv-type-ext> | <relayAlgorithmId> |
| length | <length> | variable |
| value | <value> | variable |
+---------------+----------------+--------------------+
Table 8: SMF Type Address Block TLV
表8：SMFタイプアドレスブロックTLV
<relayAlgorithmId> in Table 8 is an 8-bit unsigned integer field containing a number 0-255 representing the "Relay Algorithm Type" value that corresponds to any associated address in the address block. Note that "Relay Algorithm Type" values for 2-hop neighbors can be conveyed in a single TLV or multiple value TLVs as described in [RFC5444]. It is expected that SMF routers using NHDP construct address blocks with SMF_NBR_TYPE TLVs to advertise "Relay Algorithm Type" and to advertise neighbor algorithm values received in SMF_TYPE TLVs from those neighbors.
表8の<relayAlgorithmId>は、アドレスブロック内の関連付けられたアドレスに対応する「Relay Algorithm Type」値を表す0〜255の数値を含む8ビットの符号なし整数フィールドです。 [RFC5444]で説明されているように、2ホップネイバーの「Relay Algorithm Type」値は、単一のTLVまたは複数の値のTLVで伝達できることに注意してください。 NHDPを使用するSMFルーターは、SMF_NBR_TYPE TLVを使用してアドレスブロックを構築し、「リレーアルゴリズムタイプ」をアドバタイズし、SMF_TYPE TLVでそれらのネイバーから受信したネイバーアルゴリズム値をアドバタイズすることが期待されます。
Again, values for the <relayAlgorithmId> are defined in Table 7.
ここでも、<relayAlgorithmId>の値は表7で定義されています。
The interpretation of the "value" field of SMF_NBR_TYPE TLVs is defined per "Relay Algorithm Type" and may contain algorithm-specific information. See the appropriate appendix for definitions of value fields for the algorithms defined by this document.
SMF_NBR_TYPE TLVの「値」フィールドの解釈は「リレーアルゴリズムタイプ」ごとに定義され、アルゴリズム固有の情報が含まれる場合があります。このドキュメントで定義されているアルゴリズムの値フィールドの定義については、適切な付録を参照してください。
It is expected that SMF will be used to provide simple forwarding of multicast traffic within a MANET or mesh routing topology. A border router gateway approach should be used to allow interconnection of SMF routing domains with networks using other multicast routing protocols, such as PIM. It is important to note that there are many scenario-specific issues that should be addressed when discussing border multicast routers. At the present time, experimental deployments of SMF and PIM border router approaches have been demonstrated [DHS08]. Some of the functionality border routers may need to address includes the following: 1. Determination of which multicast group traffic transits the border router whether entering or exiting the attached SMF routing domain.
SMFは、MANETまたはメッシュルーティングトポロジ内でマルチキャストトラフィックの単純な転送を提供するために使用されることが期待されています。 SIMルーティングドメインとPIMなどの他のマルチキャストルーティングプロトコルを使用するネットワークとの相互接続を可能にするには、境界ルーターゲートウェイアプローチを使用する必要があります。ボーダーマルチキャストルーターについて説明する場合は、シナリオ固有の問題に対処する必要があることに注意してください。現時点では、SMFおよびPIM境界ルーターアプローチの実験的な展開が実証されています[DHS08]。ボーダールーターが対処する必要のある機能には、次のようなものがあります。1.接続されたSMFルーティングドメインに出入りするかどうかにかかわらず、どのマルチキャストグループトラフィックがボーダールーターを通過するかの決定。
2. Enforcement of TTL/hop limit threshold or other scoping policies.
2. TTL /ホップ制限しきい値またはその他のスコープポリシーの実施。
3. Any marking or labeling to enable DPD on ingressing packets.
3. 入力パケットでDPDを有効にするためのマーキングまたはラベル付け。
4. Interface with exterior multicast routing protocols.
4. 外部マルチキャストルーティングプロトコルとのインターフェイス。
5. Possible operation with multiple border routers (presently beyond the scope of this document).
5. 複数の境界ルーターで可能な操作（現在、このドキュメントの範囲外）。
6. Provisions for participating non-SMF devices (routers or hosts).
6. 参加している非SMFデバイス（ルーターまたはホスト）の規定。
Each of these areas is discussed in more detail in the following subsections. Note the behavior of SMF border routers is the same as that of non-border SMF routers when forwarding packets on interfaces within the SMF routing domain. Packets that are passed outbound to interfaces operating fixed-infrastructure multicast routing protocols SHOULD be evaluated for duplicate packet status since present standard multicast forwarding mechanisms do not usually perform this function.
これらの各領域については、次のサブセクションで詳しく説明します。 SMFルーティングドメイン内のインターフェースでパケットを転送するときのSMF境界ルーターの動作は、非境界SMFルーターの動作と同じです。現在の標準のマルチキャスト転送メカニズムは通常この機能を実行しないため、固定インフラストラクチャマルチキャストルーティングプロトコルを実行するインターフェイスに送信されるパケットは、重複パケットステータスについて評価する必要があります（SHOULD）。
Mechanisms for dynamically determining groups for forwarding into a MANET SMF routing domain is an evolving technology area. Ideally, only traffic for which there is active group membership should be injected into the SMF domain. This can be accomplished by providing an IPv4 Internet Group Membership Protocol (IGMP) or IPv6 Multicast Listener Discovery (MLD) proxy protocol so that MANET SMF routers can inform attached border routers (and hence multicast networks) of their current group membership status. For specific systems and services, it may be possible to statically configure group membership joins in border routers, but it is RECOMMENDED that some form of IGMP/MLD proxy or other explicit, dynamic control of membership be provided. Specification of such an IGMP/MLD proxy protocol is beyond the scope of this document.
MANET SMFルーティングドメインに転送するグループを動的に決定するメカニズムは、進化しているテクノロジー領域です。理想的には、アクティブなグループメンバーシップがあるトラフィックのみをSMFドメインに注入する必要があります。これは、IPv4インターネットグループメンバーシッププロトコル（IGMP）またはIPv6マルチキャストリスナー探索（MLD）プロキシプロトコルを提供することで実現できます。これにより、MANET SMFルーターは、接続された境界ルーター（およびマルチキャストネットワーク）に現在のグループメンバーシップステータスを通知できます。特定のシステムとサービスでは、境界ルーターでグループメンバーシップの参加を静的に構成することが可能ですが、何らかの形式のIGMP / MLDプロキシまたはメンバーシップのその他の明示的で動的な制御を提供することをお勧めします。そのようなIGMP / MLDプロキシプロトコルの仕様は、このドキュメントの範囲外です。
For outbound traffic, SMF border routers perform duplicate packet detection and forward non-duplicate traffic that meets TTL/hop limit and scoping criteria to interfaces external to the SMF routing domain. Appropriate IP multicast routing (e.g., PIM-based solutions) on those interfaces can make further forwarding decisions with respect to the multicast packet. Note that the presence of multiple border routers associated with a MANET routing domain raises additional issues. This is further discussed in Section 9.4 but further work is expected to be needed here.
アウトバウンドトラフィックの場合、SMF境界ルーターは重複パケット検出を実行し、TTL /ホップ制限とスコープ基準を満たす非重複トラフィックをSMFルーティングドメインの外部のインターフェースに転送します。これらのインターフェース上の適切なIPマルチキャストルーティング（PIMベースのソリューションなど）は、マルチキャストパケットに関してさらに転送を決定できます。 MANETルーティングドメインに関連付けられた複数の境界ルーターが存在すると、追加の問題が発生することに注意してください。これについてはセクション9.4で詳しく説明しますが、ここではさらに作業が必要になると予想されます。
Multicast scoping is used by network administrators to control the network routing domains reachable by multicast packets. This is usually done by configuring external interfaces of border routers in the border of a routing domain to not forward multicast packets that must be kept within the SMF routing domain. This is commonly done based on TTL/hop limit of messages or by using administratively scoped group addresses. These schemes are known respectively as:
マルチキャストスコープは、ネットワーク管理者がマルチキャストパケットで到達可能なネットワークルーティングドメインを制御するために使用されます。これは通常、SMFルーティングドメイン内に保持する必要があるマルチキャストパケットを転送しないように、ルーティングドメインの境界にあるボーダールーターの外部インターフェイスを構成することによって行われます。これは通常、メッセージのTTL /ホップ制限に基づいて、または管理用スコープのグループアドレスを使用して行われます。これらのスキームは、それぞれ次のように知られています。
1. TTL scoping.
1. TTLスコープ。
2. Administrative scoping.
2. 管理スコーピング。
For IPv4, network administrators can configure border routers with the appropriate TTL/hop limit thresholds or administratively scoped multicast groups for the router interfaces as with any traditional multicast router. However, for the case of TTL/hop limit scoping, it SHOULD be taken into account that the packet could traverse multiple hops within the MANET SMF routing domain before reaching the border router. Thus, TTL thresholds SHOULD be selected carefully.
IPv4の場合、ネットワーク管理者は、従来のマルチキャストルーターと同様に、適切なTTL /ホップ制限しきい値またはルーターインターフェイスの管理スコープマルチキャストグループで境界ルーターを構成できます。ただし、TTL /ホップ制限スコーピングの場合、パケットが境界ルーターに到達する前にMANET SMFルーティングドメイン内の複数のホップを通過できることを考慮に入れるべきです（SHOULD）。したがって、TTLしきい値は慎重に選択する必要があります。
For IPv6, multicast address spaces include information about the scope of the group. Thus, border routers of an SMF routing domain know if they must forward a packet based on the IPv6 multicast group address. For the case of IPv6, it is RECOMMENDED that a MANET SMF routing domain be designated a site-scoped multicast domain. Thus, all IPv6 site-scoped multicast packets in the range FF05::/16 SHOULD be kept within the MANET SMF routing domain by border routers. IPv6 packets in any other wider range scopes (i.e., FF08::/16, FF0B::/16, and FF0E::16) MAY traverse border routers unless other restrictions different from the scope applies.
IPv6の場合、マルチキャストアドレススペースには、グループのスコープに関する情報が含まれています。したがって、SMFルーティングドメインの境界ルーターは、IPv6マルチキャストグループアドレスに基づいてパケットを転送する必要があるかどうかを認識しています。 IPv6の場合、MANET SMFルーティングドメインをサイトスコープのマルチキャストドメインとして指定することをお勧めします。したがって、FF05 :: / 16の範囲にあるすべてのIPv6サイトスコープのマルチキャストパケットは、境界ルーターによってMANET SMFルーティングドメイン内に保持される必要があります（SHOULD）。他のより広い範囲のスコープ（つまり、FF08 :: / 16、FF0B :: / 16、およびFF0E :: 16）のIPv6パケットは、スコープとは異なる他の制限が適用されない限り、境界ルーターを通過できます（MAY）。
Given that scoping of multicast packets is performed at the border routers and given that existing scoping mechanisms are not designed to work with mobile routers, it is assumed that non-border routers running SMF will not stop forwarding multicast data packets of an appropriate site scoping. That is, it is assumed that an SMF routing domain is a site-scoped multicast area.
マルチキャストパケットのスコープが境界ルーターで実行され、既存のスコープメカニズムがモバイルルーターで動作するように設計されていない場合、SMFを実行している非境界ルーターは、適切なサイトスコープのマルチキャストデータパケットの転送を停止しないと想定されます。つまり、SMFルーティングドメインはサイトスコープのマルチキャストエリアであると想定されます。
The traditional operation of multicast routing protocols is tightly integrated with the group membership function. Leaf routers are configured to periodically gather group membership information, while intermediate routers conspire to create multicast trees connecting routers with directly connected multicast sources and routers with active multicast receivers. In the concrete case of SMF, border routers can be considered leaf routers. Mechanisms for multicast sources and receivers to interoperate with border routers over the multi-hop MANET SMF routing domain as if they were directly connected to the router need to be defined. The following issues need to be addressed:
マルチキャストルーティングプロトコルの従来の動作は、グループメンバーシップ機能と緊密に統合されています。リーフルーターは、グループメンバーシップ情報を定期的に収集するように構成されていますが、中間ルーターは、直接接続されたマルチキャストソースを持つルーターとアクティブなマルチキャストレシーバーを持つルーターを接続するマルチキャストツリーを作成しようとしています。 SMFの具体的なケースでは、境界ルーターはリーフルーターと見なすことができます。マルチキャスト送信元と受信者がマルチホップMANET SMFルーティングドメインを介して境界ルーターと相互運用するためのメカニズムを、ルーターに直接接続されているかのように定義する必要があります。次の問題に対処する必要があります。
1. A mechanism by which border routers gather membership information
1. 境界ルーターがメンバーシップ情報を収集するメカニズム
2. A mechanism by which multicast sources are known by the border router
2. マルチキャストソースが境界ルータによって認識されるメカニズム
3. A mechanism for exchange of exterior routing protocol messages across the SMF routing domain if the SMF routing domain is to provide transit connectivity for multicast traffic.
3. SMFルーティングドメインがマルチキャストトラフィックに中継接続を提供する場合に、SMFルーティングドメイン全体で外部ルーティングプロトコルメッセージを交換するためのメカニズム。
It is beyond the scope of this document to address implementation solutions to these issues. As described in Section 9.1, IGMP/MLD proxy mechanisms can address some of these issues. Similarly, exterior routing protocol messages could be tunneled or conveyed across an SMF routing domain but doing this robustly in a distributed wireless environment likely requires additional considerations outside the scope of this document.
これらの問題の実装ソリューションに対処することは、このドキュメントの範囲を超えています。セクション9.1で説明したように、IGMP / MLDプロキシメカニズムはこれらの問題のいくつかに対処できます。同様に、外部ルーティングプロトコルメッセージはSMFルーティングドメイン全体でトンネリングまたは伝達できますが、分散ワイヤレス環境でこれを確実に行うには、このドキュメントの範囲外の追加の考慮事項が必要になる可能性があります。
The need for the border router to receive traffic from recognized multicast sources within the SMF routing domain is important to achieve interoperability with some existing routing protocols. For instance, PIM-S requires routers with locally attached multicast sources to register them to the Rendezvous Point (RP) so that routers can join the multicast tree. In addition, if those sources are not advertised to other autonomous systems (ASes) using Multicast Source Discovery Protocol (MSDP), receivers in those external networks are not able to join the multicast tree for that source.
境界ルーターがSMFルーティングドメイン内の認識されたマルチキャストソースからトラフィックを受信する必要性は、既存のルーティングプロトコルとの相互運用性を実現するために重要です。たとえば、PIM-Sでは、ルーターがマルチキャストツリーに参加できるように、ローカルに接続されたマルチキャストソースを持つルーターをRendezvous Point（RP）に登録する必要があります。さらに、これらのソースがMulticast Source Discovery Protocol（MSDP）を使用して他の自律システム（AS）にアドバタイズされない場合、それらの外部ネットワークの受信者はそのソースのマルチキャストツリーに参加できません。
An SMF routing domain might be deployed with multiple participating routers having connectivity to external, fixed-infrastructure networks. Allowing multiple routers to forward multicast traffic to/ from the SMF routing domain can be beneficial since it can increase reliability and provide better service. For example, if the SMF routing domain were to fragment with different SMF routers maintaining connectivity to different border routers, multicast service could still continue successfully. But, the case of multiple border routers connecting an SMF routing domain to external networks presents several challenges for SMF:
SMFルーティングドメインは、外部の固定インフラストラクチャネットワークへの接続を持つ複数の参加ルーターと共に展開される場合があります。複数のルーターがSMFルーティングドメインとの間でマルチキャストトラフィックを転送できるようにすると、信頼性が向上し、より良いサービスを提供できるため、有益です。たとえば、SMFルーティングドメインが異なるボーダールーターへの接続を維持する異なるSMFルーターでフラグメント化する場合でも、マルチキャストサービスは引き続き正常に続行できます。ただし、SMFルーティングドメインを外部ネットワークに接続する複数の境界ルーターの場合、SMFにはいくつかの課題があります。
1. Handling duplicate unmarked IPv4 or IPv6 (without IPsec encapsulation or DPD option) packets possibly injected by multiple border routers.
1. マークされていない重複したIPv4またはIPv6（IPsecカプセル化またはDPDオプションなし）パケットの処理。複数の境界ルーターによって挿入された可能性があります。
2. Handling of duplicate traffic injected by multiple border routers by source-based relay algorithms.
2. ソースベースのリレーアルゴリズムによる、複数の境界ルーターによって挿入された重複トラフィックの処理。
3. Determining which border router(s) will forward outbound multicast traffic.
3. 送信マルチキャストトラフィックを転送する境界ルーターを決定します。
4. Additional challenges with interfaces to exterior multicast routing protocols.
4. 外部マルチキャストルーティングプロトコルへのインターフェイスに関する追加の課題。
When multiple border routers are present, they may be alternatively (due to route changes) or simultaneously injecting common traffic into the SMF routing domain that has not been previously marked for IPv6 SMF_DPD. Different border routers would not be able to implicitly synchronize sequencing of injected traffic since they may not receive exactly the same messages due to packet losses. For IPv6 I-DPD operation, the optional TaggerId field described for the SMF_DPD option header can be used to mitigate this issue. When multiple border routers are injecting a flow into an SMF routing domain, there are two forwarding policies that SMF routers running I-DPD may implement:
複数の境界ルーターが存在する場合、それらは代わりに（ルートの変更により）、または以前にIPv6 SMF_DPDのマークが付けられていないSMFルーティングドメインに共通のトラフィックを同時に注入する可能性があります。異なるボーダールーターは、パケットの損失が原因でまったく同じメッセージを受信しない可能性があるため、注入されたトラフィックのシーケンスを暗黙的に同期できません。 IPv6 I-DPD操作の場合、SMF_DPDオプションヘッダーで説明されているオプションのTaggerIdフィールドを使用して、この問題を軽減できます。複数の境界ルーターがSMFルーティングドメインにフローを挿入している場合、I-DPDを実行しているSMFルーターが実装できる転送ポリシーは2つあります。
1. Redundantly forward the multicast flows (identified by <srcAddr: dstAddr>) from each border router, performing DPD processing on a <TaggerID:dstAddr> or <TaggerID:srcAddr:dstAddr> basis, or
1. 各境界ルーターからマルチキャストフロー（<srcAddr：dstAddr>で識別される）を冗長転送し、<TaggerID：dstAddr>または<TaggerID：srcAddr：dstAddr>ベースでDPD処理を実行する、または
2. Use some basis to select the flow of one tagger (border router) over the others and forward packets for applicable flows (identified by <sourceAddress:dstAddr>) only for the selected TaggerId until timeout or some other criteria to favor another tagger occurs.
2. いくつかの基準を使用して、1つのタガー（ボーダールーター）のフローを他のタガーに選択し、選択したTaggerIdに対してのみ、該当するフロー（<sourceAddress：dstAddr>で識別される）のパケットを、タイムアウトまたは別のタガーが優先される他の基準が発生するまで転送します。
It is RECOMMENDED that the first approach be used in the case of I-DPD operation. Additional specification may be required to describe an interoperable forwarding policy based on this second option. Note that the implementation of the second option requires that per-flow (i.e., <srcAddr::dstAddr>) state be maintained for the selected TaggerId.
I-DPD操作の場合は、最初のアプローチを使用することをお勧めします。この2番目のオプションに基づいて相互運用可能な転送ポリシーを説明するには、追加の仕様が必要になる場合があります。 2番目のオプションの実装では、選択したTaggerIdに対してフローごと（つまり、<srcAddr :: dstAddr>）の状態を維持する必要があることに注意してください。
The deployment of H-DPD operation may alleviate DPD resolution when ingressing traffic comes from multiple border routers. Non-colliding hash indexes (those not requiring the H-DPD options header in IPv6) should be resolved effectively.
H-DPD動作の導入により、入力トラフィックが複数の境界ルータから来る場合のDPD解決が軽減される場合があります。衝突しないハッシュインデックス（IPv6のH-DPDオプションヘッダーを必要としないもの）は効果的に解決する必要があります。
Gratuitous use of option headers can cause problems in routers. Other IP routers external to an SMF routing domain that might receive forwarded multicast SHOULD ignore SMF-specific IPv6 header options when encountered. The header option types are encoded appropriately to allow for this behavior.
オプションヘッダーを不当に使用すると、ルーターで問題が発生する可能性があります。転送されたマルチキャストを受信する可能性のあるSMFルーティングドメインの外部にある他のIPルーターは、遭遇したときにSMF固有のIPv6ヘッダーオプションを無視する必要があります（SHOULD）。ヘッダーオプションタイプは、この動作を可能にするために適切にエンコードされます。
This section briefly discusses several SMF denial-of-service (DoS) attack scenarios and provides some initial recommended mitigation strategies.
このセクションでは、いくつかのSMFサービス拒否（DoS）攻撃シナリオについて簡単に説明し、推奨される最初の軽減戦略をいくつか示します。
A potential denial-of-service attack against SMF forwarding is possible when a malicious router has a form of wormhole access to non-adjacent parts of a network topology. In the wireless ad hoc case, a directional antenna is one way to provide such a wormhole physically. If such a router can preview forwarded packets in a non-adjacent part of the network and forward modified versions to another part of the network, it can perform the following attack. The malicious router could reduce the TTL/hop limit or hop limit of the packet and transmit it to the SMF router causing it to forward the packet with a limited TTL/hop limit (or even drop it) and make a DPD entry that could block or limit the subsequent forwarding of later-arriving valid packets with correct TTL/hop limit values. This would be a relatively low-cost, high-payoff attack that would be hard to detect and thus attractive to potential attackers. An approach of caching TTL/hop limit information with DPD state and taking appropriate forwarding actions is identified in Section 5 to mitigate this form of attack.
SMF転送に対する潜在的なサービス拒否攻撃は、悪意のあるルーターがネットワークトポロジの隣接していない部分へのワームホールアクセスの形式を持っている場合に可能です。無線アドホックの場合、指向性アンテナは、このようなワームホールを物理的に提供する1つの方法です。そのようなルーターがネットワークの隣接していない部分で転送されたパケットをプレビューし、変更されたバージョンをネットワークの別の部分に転送できる場合、次の攻撃を実行できます。悪意のあるルーターは、パケットのTTL /ホップ制限またはホップ制限を低減し、SMFルーターに送信して、制限されたTTL /ホップ制限でパケットを転送（またはドロップ）し、ブロックするDPDエントリを作成する可能性があります。または、正しいTTL /ホップ制限値を使用して、後で到着する有効なパケットのその後の転送を制限します。これは比較的低コストで高収益の攻撃であり、検出が難しく、潜在的な攻撃者にとって魅力的です。 DPD状態でTTL /ホップ制限情報をキャッシュし、適切な転送アクションを実行するアプローチは、この形式の攻撃を軽減するためにセクション5で特定されています。
Sequence-based packet identifiers are predictable and thus provide an opportunity for a DoS attack against forwarding. Forwarding protocols that use DPD techniques, such as SMF, may be vulnerable to DoS attacks based on spoofing packets with apparently valid packet identifier fields. In wireless environments, where SMF will most likely be used, the opportunity for such attacks may be more prevalent than in wired networks. In the case of IPv4 packets, fragmented IP packets, or packets with IPsec headers applied, the DPD "identifier portions" of potential future packets that might be forwarded is highly predictable and easily subject to DoS attacks against forwarding. A RECOMMENDED technique to counter this concern is for SMF implementations to generate an "internal" hash value that is concatenated with the explicit I-DPD packet identifier to form a unique identifier that is a function of the packet content as well as the visible identifier. SMF implementations could seed their hash generation with a random value to make it unlikely that an external observer could guess how to spoof packets used in a denial-of-service attack against forwarding. Since the hash computation and state is kept completely internal to SMF routers, the cryptographic properties of this hashing would not need to be extensive and thus possibly of low complexity. Experimental implementations may determine that even a lightweight hash of only portions of packets may suffice to serve this purpose.
シーケンスベースのパケット識別子は予測可能であるため、転送に対するDoS攻撃の機会を提供します。 SMFなどのDPD技術を使用する転送プロトコルは、明らかに有効なパケット識別子フィールドを持つパケットのスプーフィングに基づくDoS攻撃に対して脆弱である可能性があります。 SMFが使用される可能性が最も高い無線環境では、このような攻撃の機会は有線ネットワークよりも一般的です。 IPv4パケット、断片化されたIPパケット、またはIPsecヘッダーが適用されたパケットの場合、転送される可能性のある将来のパケットのDPD「識別子部分」は非常に予測可能であり、転送に対するDoS攻撃を受けやすくなります。この問題に対処するための推奨手法は、SMF実装が「内部」ハッシュ値を生成し、明示的なI-DPDパケット識別子と連結して、パケットコンテンツと可視識別子の関数である一意の識別子を形成することです。 SMF実装は、ハッシュ生成にランダムな値をシードして、外部のオブザーバーが転送に対するサービス拒否攻撃で使用されるパケットを偽装する方法を推測できないようにすることができます。ハッシュの計算と状態は完全にSMFルーターの内部に保持されるため、このハッシュの暗号化プロパティは広範囲である必要はなく、したがって複雑さが低い可能性があります。実験的な実装では、パケットの一部のみの軽量ハッシュでさえ、この目的を果たすのに十分であると判断する場合があります。
While H-DPD is not as readily susceptible to this form of DoS attack, it is possible that a sophisticated adversary could use side information to construct spoofing packets to mislead forwarders using a well-known hash algorithm. Thus, similarly, a separate "internal" hash value could be concatenated with the well-known hash value to alleviate this security concern.
H-DPDはこの形式のDoS攻撃にそれほど敏感ではありませんが、高度な攻撃者がサイド情報を使用して、よく知られたハッシュアルゴリズムを使用してフォワーダーを欺くスプーフィングパケットを構築する可能性があります。したがって、同様に、別個の「内部」ハッシュ値を既知のハッシュ値と連結して、このセキュリティ上の懸念を軽減することができます。
The support of forwarding IPsec packets without further modification for both IPv4 and IPv6 is supported by this specification.
この仕様では、IPv4とIPv6の両方をさらに変更せずにIPsecパケットを転送するサポートがサポートされています。
Authentication mechanisms to identify the source of IPv6 option headers should be considered to reduce vulnerability to a variety of attacks.
IPv6オプションヘッダーのソースを識別する認証メカニズムは、さまざまな攻撃に対する脆弱性を減らすために検討する必要があります。
Furthermore, when the MANET Neighborhood Discovery Protocol [RFC6130] is used, the security considerations described in [RFC6130] also apply.
さらに、MANET Neighborhood Discovery Protocol [RFC6130]が使用される場合、[RFC6130]で説明されているセキュリティの考慮事項も適用されます。
This document defines one IPv6 Hop-by-Hop Option, a type for which has been allocated from the IPv6 "Destination Options and Hop-by-Hop Options" registry of [RFC2780].
このドキュメントでは、1つのIPv6ホップバイホップオプションを定義しています。このタイプは、[RFC2780]のIPv6「宛先オプションとホップバイホップオプション」レジストリから割り当てられています。
This document creates one registry called "TaggerId Types" for recording TaggerId types, (TidTy), as a sub-registry in the "IPv6 Parameters" registry.
このドキュメントは、TaggerIdタイプ（TidTy）を記録するための「TaggerIdタイプ」と呼ばれる1つのレジストリーを、「IPv6パラメーター」レジストリーのサブレジストリーとして作成します。
This document registers one well-known multicast address from each of the IPv4 and IPv6 multicast address spaces.
このドキュメントは、IPv4およびIPv6マルチキャストアドレススペースのそれぞれから1つの既知のマルチキャストアドレスを登録します。
This document defines one Message TLV, a type for which has been allocated from the "Message TLV Types" registry of [RFC5444].
このドキュメントは、[RFC5444]の「メッセージTLVタイプ」レジストリから割り当てられたタイプの1つのメッセージTLVを定義します。
Finally, this document defines one Address Block TLV, a type for which has been allocated from the "Address Block TLV Types" registry of [RFC5444].
最後に、このドキュメントでは、[RFC5444]の「アドレスブロックTLVタイプ」レジストリから割り当てられた1つのアドレスブロックTLVを定義しています。
IANA has allocated an IPv6 Option Type from the IPv6 "Destination Options and Hop-by-Hop Options" registry of [RFC2780], as specified in Table 9.
IANAは、[RFC2780]のIPv6 "宛先オプションとホップバイホップオプション"レジストリから、表9で指定されているIPv6オプションタイプを割り当てました。
+-----------+-------------------------+-------------+---------------+
| Hex Value | Binary Value | Description | Reference |
| | act | chg | rest | | |
+-----------+-------------------------+-------------+---------------+
| 8 | 00 | 0 | 01000 | SMF_DPD | This Document |
+-----------+-------------------------+-------------+---------------+
Table 9: IPv6 Option Type Allocation
表9：IPv6オプションタイプの割り当て
A portion of the option data content in the SMF_DPD is the Tagger Identifier Type (TidTy), which provides a context for the optionally included TaggerId.
SMF_DPDのオプションデータコンテンツの一部は、オプションで含まれるTaggerIdのコンテキストを提供するTagger Identifier Type（TidTy）です。
IANA has created a registry for recording TaggerId Types (TidTy), with initial assignments and allocation policies, as specified in Table 10.
IANAは、TaggerIdタイプ（TidTy）を記録するためのレジストリを作成し、表10に指定されているように、初期割り当てと割り当てポリシーを使用します。
+------+----------+------------------------------------+------------+
| Type | Mnemonic | Description | Reference |
+------+----------+------------------------------------+------------+
| 0 | NULL | No TaggerId field is present | This |
| | | | document |
| 1 | DEFAULT | A TaggerId of non-specific context | This |
| | | is present | document |
| 2 | IPv4 | A TaggerId representing an IPv4 | This |
| | | address is present | document |
| 3 | IPv6 | A TaggerId representing an IPv6 | This |
| | | address is present | document |
| 4-7 | | Unassigned | |
+------+----------+------------------------------------+------------+
Table 10: TaggerId Types
表10：TaggerIdタイプ
For allocation of unassigned values 4-7, IETF Review [RFC5226] is required.
割り当てられていない値4〜7の割り当てには、IETFレビュー[RFC5226]が必要です。
IANA has allocated an IPv4 multicast address "SL-MANET-ROUTERS" (224.0.1.186) from the "Internetwork Control Block (224.0.1.0- 224.0.1.255 (224.0.1/24))" sub-registry of the "IPv4 Multicast Address" registry.
IANAは、「Internetwork Control Block（224.0.1.0- 224.0.1.255（224.0.1 / 24））」サブレジストリから「IPv4 Multicast」のIPv4マルチキャストアドレス「SL-MANET-ROUTERS」（224.0.1.186）を割り当てましたアドレス」レジストリ。
IANA has allocated an IPv6 multicast address "SL-MANET-ROUTERS" from the "Site-Local Scope Multicast Addresses" sub-sub-registry of the "Fixed Scope Multicast Addresses" sub-registry of the "INTERNET PROTOCOL VERSION 6 MULTICAST ADDRESSES" registry.
IANAは、「インターネットプロトコルバージョン6マルチキャストアドレス」の「固定スコープマルチキャストアドレス」サブレジストリの「サイトローカルスコープマルチキャストアドレス」サブサブレジストリからIPv6マルチキャストアドレス「SL-MANET-ROUTERS」を割り当てましたレジストリ。
Creation of Address Block TLV Types and Message TLV Types in registries of [RFC5444], and hence in the HELLO-message-specific registries of [RFC6130], entails creation of corresponding Type Extension registries for each such type. For such Type Extension registries, where an Expert Review is required, the designated expert SHOULD take the same general recommendations into consideration as those specified by [RFC5444].
[RFC5444]のレジストリでの、したがって[RFC6130]のHELLOメッセージ固有のレジストリでのアドレスブロックTLVタイプとメッセージTLVタイプの作成は、そのような各タイプに対応するタイプ拡張レジストリの作成を伴います。専門家によるレビューが必要なそのようなタイプ拡張レジストリの場合、指定された専門家は、[RFC5444]で指定されているものと同じ一般的な推奨事項を考慮する必要があります（SHOULD）。
This document defines one Message TLV Type, "SMF_TYPE", which has been allocated from the "HELLO Message-Type-specific Message TLV Types" registry, defined in [RFC6130].
このドキュメントでは、[RFC6130]で定義されている「HELLOメッセージタイプ固有のメッセージTLVタイプ」レジストリから割り当てられた1つのメッセージTLVタイプ「SMF_TYPE」を定義しています。
This created a new Type Extension registry, with initial assignments as specified in Table 11.
これにより、表11で指定されている初期割り当てを使用して、新しいType Extensionレジストリが作成されました。
+----------+------+-----------+--------------------+----------------+
| Name | Type | Type | Description | Allocation |
| | | Extension | | Policy |
+----------+------+-----------+--------------------+----------------+
| SMF_TYPE | 128 | 0-255 | Specifies relay | Section 11.4.4 |
| | | | algorithm | |
| | | | supported by the | |
| | | | SMF router, | |
| | | | originating the | |
| | | | HELLO message, | |
| | | | according to | |
| | | | Section 11.4.4. | |
+----------+------+-----------+--------------------+----------------+
Table 11: SMF_TYPE Message TLV Type Extension Registry
表11：SMF_TYPEメッセージTLVタイプ拡張レジストリ
This document defines one Address Block TLV Type, "SMF_NBR_TYPE", which has been allocated from the "HELLO Message-Type-specific Address Block TLV Types" registry, defined in [RFC6130].
このドキュメントでは、[RFC6130]で定義されている「HELLOメッセージタイプ固有のアドレスブロックTLVタイプ」レジストリから割り当てられた1つのアドレスブロックTLVタイプ「SMF_NBR_TYPE」を定義しています。
This has created a new Type Extension registry, with initial assignments as specified in Table 12.
これにより、表12で指定されている初期割り当てを使用して、新しいタイプ拡張レジストリが作成されました。
+--------------+--------+-----------+-----------------+-------------+
| Name | Type | Type | Description | Allocation |
| | | Extension | | Policy |
+--------------+--------+-----------+-----------------+-------------+
| SMF_NBR_TYPE | 128 | 0-255 | Specifies relay | Section |
| | | | algorithm | 11.4.4 |
| | | | supported by | |
| | | | the SMF router | |
| | | | corresponding | |
| | | | to the | |
| | | | advertised | |
| | | | address, | |
| | | | according to | |
| | | | Section 11.4.4. | |
+--------------+--------+-----------+-----------------+-------------+
Table 12: SMF_NBR_TYPE Address Block TLV Type Extension Registry
表12：SMF_NBR_TYPEアドレスブロックTLVタイプ拡張レジストリ
Types for the Type Extension Registries for the SMF_TYPE Message TLV and the SMF_NBR_TYPE Address Block TLV are unified in this single SMF Relay Algorithm ID Registry, defined in this section.
SMF_TYPEメッセージTLVおよびSMF_NBR_TYPEアドレスブロックTLVのタイプ拡張レジストリのタイプは、このセクションで定義されているこの単一のSMFリレーアルゴリズムIDレジストリに統合されています。
IANA has created a registry for recording Relay Algorithm Identifiers, with initial assignments and allocation policies as specified in Table 13.
IANAは、リレーアルゴリズム識別子を記録するためのレジストリを作成しました。初期割り当てと割り当てポリシーは、表13で指定されています。
+---------+---------+-------------+-------------------+
| Value | Name | Description | Allocation Policy |
+---------+---------+-------------+-------------------+
| 0 | CF | Section 4 | |
| 1 | S-MPR | Appendix B | |
| 2 | E-CDS | Appendix A | |
| 3 | MPR-CDS | Appendix C | |
| 4-127 | | Unassigned | Expert Review |
| 128-255 | | Unassigned | Experimental Use |
+---------+---------+-------------+-------------------+
Table 13: Relay Set Algorithm Type Values
表13：リレーセットアルゴリズムタイプの値
A specification requesting an allocation from the 4-127 range from the SMF Relay Algorithm ID Registry MUST specify the interpretation of the <value> field (if any).
SMFリレーアルゴリズムIDレジストリの4〜127の範囲からの割り当てを要求する仕様では、<値>フィールドの解釈（ある場合）を指定する必要があります。
Many of the concepts and mechanisms used and adopted by SMF resulted over several years of discussion and related work within the MANET working group since the late 1990s. There are obviously many contributors to past discussions and related draft documents within the working group that have influenced the development of SMF concepts, and they deserve acknowledgment. In particular, this document is largely a direct product of the earlier SMF design team within the IETF MANET working group and borrows text and implementation ideas from the related individuals and activities. Some of the direct contributors who have been involved in design, content editing, prototype implementation, major commenting, and core discussions are listed below in alphabetical order. We appreciate all the input and feedback from the many community members and early implementation users we have heard from that are not on this list as well.
SMFによって使用および採用された概念とメカニズムの多くは、1990年代後半以降、MANETワーキンググループ内で数年にわたる議論と関連作業をもたらしました。 SMFコンセプトの開発に影響を与えたワーキンググループ内の過去のディスカッションおよび関連するドラフトドキュメントへの貢献者は明らかに多く、それらは認められるに値します。特に、このドキュメントは、主にIETF MANETワーキンググループ内の初期のSMF設計チームの直接の製品であり、関連する個人や活動からテキストと実装のアイデアを借用しています。デザイン、コンテンツの編集、プロトタイプの実装、主要なコメント、およびコアディスカッションに関与した直接の貢献者の一部を、アルファベット順に以下に示します。多くのコミュニティメンバーからのすべての入力とフィードバック、およびこのリストに載っていない、初期の実装ユーザーからのフィードバックも歓迎します。
Brian Adamson Teco Boot Ian Chakeres Thomas Clausen Justin Dean Brian Haberman Ulrich Herberg Charles Perkins Pedro Ruiz Fred Templin Maoyu Wang
ブライアンアダムソンテコブーツイアンチャケレストーマスクラウセンジャスティンディーンブライアンハーバーマンウルリッヒヘルバーグチャールズパーキンスペドロルイスフレッドテンプリンマオユワン
[MPR-CDS] Adjih, C., Jacquet, P., and L. Viennot, "Computing Connected Dominating Sets with Multipoint Relays", Ad Hoc and Sensor Wireless Networks, January 2005.
[MPR-CDS] Adjih、C.、Jacquet、P。、およびL. Viennot、「Computing Connected Dominated Sets with Multipoint Relays」、Ad Hoc and Sensor Wireless Networks、2005年1月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999.
[RFC2644] Senie、D。、「Changing the Default for Directed Broadcasts in Routers」、BCP 34、RFC 2644、1999年8月。
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[RFC2780] Bradner、S。およびV. Paxson、「IANA Allocation Allocation Guidelines for Values in the Internet Protocol and Related Headers」、BCP 37、RFC 2780、2000年3月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174] Eastlake、D。およびP. Jones、「US Secure Hash Algorithm 1（SHA1）」、RFC 3174、2001年9月。
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
[RFC3626] Clausen、T。およびP. Jacquet、「Optimized Link State Routing Protocol（OLSR）」、RFC 3626、2003年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009.
[RFC5444] Clausen、T.、Dearlove、C.、Dean、J。、およびC. Adjih、「Generalized Mobile Ad Hoc Network（MANET）Packet / Message Format」、RFC 5444、2009年2月。
[RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding", RFC 5614, August 2009.
[RFC5614] Ogier、R。およびP. Spagnolo、「モバイル接続アドホックネットワーク（MANET）のOSPFの拡張を使用して接続された支配セット（CDS）フラッディング」、RFC 5614、2009年8月。
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, March 2010.
[RFC5771]綿、M。、ベゴダ、L。、およびD.マイヤー、「IPv4マルチキャストアドレス割り当てのIANAガイドライン」、BCP 51、RFC 5771、2010年3月。
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011.
[RFC6130] Clausen、T.、Dearlove、C。、およびJ. Dean、「Mobile Ad Hoc Network（MANET）Neighborhood Discovery Protocol（NHDP）」、RFC 6130、2011年4月。
[CDHM07] Chakeres, I., Danilov, C., Henderson, T., and J. Macker, "Connecting MANET Multicast", IEEE MILCOM 2007 Proceedings, 2007.
[CDHM07] Chakeres、I.、Danilov、C.、Henderson、T。、およびJ. Macker、「Connecting MANET Multicast」、IEEE MILCOM 2007 Proceedings、2007。
[DHG09] Danilov, C., Henderson, T., Goff, T., Kim, J., Macker, J., Weston, J., Neogi, N., Ortiz, A., and D. Uhlig, "Experiment and field demonstration of a 802.11-based ground-UAV mobile ad-hoc network", Proceedings of the 28th IEEE conference on Military Communications, 2009.
[DHG09] Danilov、C.、Henderson、T.、Goff、T.、Kim、J.、Macker、J.、Weston、J.、Neogi、N.、Ortiz、A。、およびD. Uhlig、「実験802.11ベースの地上UAVモバイルアドホックネットワークのフィールドデモンストレーション」、軍事通信に関する第28回IEEE会議の議事録、2009年。
[DHS08] Danilov, C., Henderson, T., Spagnolo, T., Goff, T., and J. Kim, "MANET Multicast with Multiple Gateways", IEEE MILCOM 2008 Proceedings, 2008.
[DHS08] Danilov、C.、Henderson、T.、Spagnolo、T.、Goff、T。、およびJ. Kim、「複数のゲートウェイを備えたMANETマルチキャスト」、IEEE MILCOM 2008 Proceedings、2008年。
[GM99] Garcia-Luna-Aceves, JJ. and E. Madruga, "The Core-Assisted Mesh Protocol", Selected Areas in Communications, IEEE Journal, Volume 17, Issue 8, August 1999.
[GM99] Garcia-Luna-Aceves、JJ。 E. Madruga、「Core-Assisted Mesh Protocol」、Selected Areas in Communications、IEEE Journal、Volume 17、Issue 8、1999年8月。
[IPV4-ID-UPDATE] Touch, J., "Updated Specification of the IPv4 ID Field", Work in Progress, September 2011.
[IPV4-ID-UPDATE] Touch、J。、「更新されたIPv4 IDフィールドの仕様」、作業中、2011年9月。
[JLMV02] Jacquet, P., Laouiti, V., Minet, P., and L. Viennot, "Performance of Multipoint Relaying in Ad Hoc Mobile Routing Protocols", Networking , 2002.
[JLMV02] Jacquet、P.、Laouiti、V.、Minet、P。、およびL. Viennot、「アドホックモバイルルーティングプロトコルにおけるマルチポイントリレーのパフォーマンス」、ネットワーキング、2002年。
[MDC04] Macker, J., Dean, J., and W. Chao, "Simplified Multicast Forwarding in Mobile Ad hoc Networks", IEEE MILCOM 2004 Proceedings, 2004.
[MDC04] Macker、J.、Dean、J。、およびW. Chao、「Simplified Multicast Forwarding in Mobile Ad hoc Networks」、IEEE MILCOM 2004 Proceedings、2004。
[MDDA07] Macker, J., Downard, I., Dean, J., and R. Adamson, "Evaluation of Distributed Cover Set Algorithms in Mobile Ad hoc Network for Simplified Multicast Forwarding", ACM SIGMOBILE Mobile Computing and Communications Review, Volume 11, Issue 3, July 2007.
[MDDA07] Macker、J.、Downard、I.、Dean、J。、およびR. Adamson、「モバイルアドホックネットワークにおける分散型カバーセットアルゴリズムの評価」、ACM SIGMOBILEモバイルコンピューティングおよび通信レビュー、ボリューム11、3、2007年7月。
[MGL04] Mohapatra, P., Gui, C., and J. Li, "Group Communications in Mobile Ad hoc Networks", IEEE Computer, Vol. 37, No. 2, February 2004.
[MGL04] Mohapatra、P.、Gui、C。、およびJ. Li、「モバイルアドホックネットワークにおけるグループ通信」、IEEE Computer、Vol。 37、No。2、2004年2月。
[NTSC99] Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast Storm Problem in a Mobile Ad Hoc Network", Proceedings of ACM Mobicom 99, 1999.
[NTSC99] Ni、S.、Tseng、Y.、Chen、Y。、およびJ. Sheu、「モバイルアドホックネットワークにおけるブロードキャストストームの問題」、ACM Mobicom 99の議事録、1999。
[RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999.
[RFC2501] Corson、M.およびJ. Macker、「モバイルアドホックネットワーキング（MANET）：ルーティングプロトコルのパフォーマンスの問題と評価に関する考慮事項」、RFC 2501、1999年1月。
[RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)", RFC 3684, February 2004.
[RFC3684] Ogier、R.、Templin、F。、およびM. Lewis、「Topology Dissemination Based on Reverse-Path Forwarding（TBRPF）」、RFC 3684、2004年2月。
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[RFC3973] Adams、A.、Nicholas、J。、およびW. Siadak、「Protocol Independent Multicast-Dense Mode（PIM-DM）：Protocol Specification（Revised）」、RFC 3973、2005年1月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）」、RFC 4601、2006年8月。
Appendix A. Essential Connecting Dominating Set (E-CDS) Algorithm
付録A. Essential接続支配セット（E-CDS）アルゴリズム
The "Essential Connected Dominating Set" (E-CDS) algorithm [RFC5614] forms a single CDS mesh for the SMF operating region. It allows routers to use 2-hop neighborhood topology information to dynamically perform relay self-election to form a CDS. Its packet-forwarding rules are not dependent upon previous hop knowledge. Additionally, E-CDS SMF forwarders can be easily mixed without problems with CF SMF forwarders, even those not participating in NHDP. Another benefit is that packets opportunistically received from non-symmetric neighbors may be forwarded without compromising flooding efficiency or correctness. Furthermore, multicast sources not participating in NHDP may freely inject their traffic, and any neighboring E-CDS relays will properly forward the traffic. The E-CDS-based relay set selection algorithm is based upon [RFC5614]. E-CDS was originally discussed in the context of forming partial adjacencies and efficient flooding for MANET OSPF extensions work, and the core algorithm is applied here for SMF.
「エッセンシャルコネクテッドドミネーティングセット」（E-CDS）アルゴリズム[RFC5614]は、SMF動作領域の単一のCDSメッシュを形成します。これにより、ルーターは2ホップの近隣トポロジ情報を使用して動的にリレーの自己選択を実行し、CDSを形成できます。そのパケット転送ルールは、以前のホップの知識に依存していません。さらに、E-CDS SMFフォワーダーは、NHDPに参加していない場合でも、CF SMFフォワーダーに問題なく簡単に混在させることができます。別の利点は、非対称のネイバーから日和見的に受信されたパケットが、フラッディングの効率や正確性を損なうことなく転送される可能性があることです。さらに、NHDPに参加していないマルチキャストソースはトラフィックを自由に注入でき、隣接するE-CDSリレーはトラフィックを適切に転送します。 E-CDSベースのリレーセット選択アルゴリズムは、[RFC5614]に基づいています。 E-CDSは当初、MANET OSPF拡張機能の部分的な隣接関係と効率的なフラッディングを形成するコンテキストで議論され、コアアルゴリズムはここでSMFに適用されます。
It is RECOMMENDED that the SMF_TYPE:E-CDS Message TLV be included in NHDP_HELLO messages that are generated by routers conducting E-CDS SMF operation. It is also RECOMMENDED that the SMF_NBR_TYPE:E-CDS Address Block TLV be used to advertise neighbor routers that are also conducting E-CDS SMF operation.
SMF_TYPE：E-CDSメッセージTLVは、E-CDS SMF操作を実行するルーターによって生成されるNHDP_HELLOメッセージに含めることをお勧めします。また、SMF_NBR_TYPE：E-CDSアドレスブロックTLVを使用して、E-CDS SMF操作も実行しているネイバールータをアドバタイズすることも推奨されます。
The E-CDS relay set selection requires 2-hop neighborhood information collected through NHDP or another process. Relay routers, in E-CDS SMF selection, are "self-elected" using a Router Identifier (Router ID) and an optional nodal metric, referred to here as Router Priority for all 1-hop and 2-hop neighbors. To ensure proper relay set self-election, the Router ID and Router Priority MUST be consistent among participating routers. It is RECOMMENDED that NHDP be used to share Router ID and Router Priority through the use of SMF_TYPE:E-CDS TLVs as described in this appendix. The Router ID is a logical identification that MUST be consistent across interoperating SMF neighborhoods, and it is RECOMMENDED to be chosen as the numerically largest address contained in a router's "Neighbor Address List" as defined in NHDP. The E-CDS self-election process can be summarized as follows:
E-CDSリレーセットの選択には、NHDPまたは別のプロセスを通じて収集された2ホップの近隣情報が必要です。 E-CDS SMF選択のリレールーターは、ルーター識別子（ルーターID）とオプションのノードメトリックを使用して「自己選択」されます。ここでは、すべての1ホップおよび2ホップネイバーのルータープライオリティと呼びます。適切なリレーセットの自己選択を保証するには、参加するルーター間でルーターIDとルーター優先度を一致させる必要があります。この付録で説明するように、SMF_TYPE：E-CDS TLVを使用してルーターIDとルーター優先度を共有するためにNHDPを使用することをお勧めします。ルーターIDは、相互運用するSMF近隣全体で一貫している必要がある論理識別であり、NHDPで定義されているルーターの「近隣アドレスリスト」に含まれる数値的に最大のアドレスとして選択することをお勧めします。 E-CDSの自己選択プロセスは、次のように要約できます。
1. If an SMF router has a higher ordinal (Router Priority, Router ID) than all of its symmetric neighbors, it elects itself to act as a forwarder for all received multicast packets.
1. SMFルーターがすべての対称ネイバーよりも序数（ルータープライオリティ、ルーターID）が高い場合、SMFルーターは、受信したすべてのマルチキャストパケットのフォワーダーとして機能することを選択します。
2. Else, if there does not exist a path from the neighbor with largest (Router Priority, Router ID) to any other neighbor, via neighbors with larger values of (Router Priority, Router ID), then it elects itself to the relay set.
2. それ以外の場合、（ルータープライオリティ、ルーターID）の値が最も大きいネイバーを経由して、（ルータープライオリティ、ルーターID）が最大のネイバーから他のネイバーへのパスが存在しない場合、それ自体がリレーセットに選択されます。
The basic form of E-CDS described and applied within this specification does not provide for redundant relay set selection (e.g., bi-connected), but such capability is supported by the basic E-CDS design.
この仕様で説明および適用されているE-CDSの基本形式は、冗長リレーセットの選択（たとえば、バイコネクト）を提供していませんが、そのような機能は基本的なE-CDS設計でサポートされています。
With E-CDS, any SMF router that has selected itself as a relay performs DPD and forwards all non-duplicative multicast traffic allowed by the present forwarding policy. Packet previous-hop knowledge is not needed for forwarding decisions when using E-CDS.
E-CDSを使用すると、自身をリレーとして選択したSMFルーターがDPDを実行し、現在の転送ポリシーで許可されているすべての非重複マルチキャストトラフィックを転送します。 E-CDSを使用する場合、転送の決定にパケットの前ホップの知識は必要ありません。
1. Upon packet reception, DPD is performed. Note E-CDS requires a single duplicate table for the set of interfaces associated with the relay set selection.
1. パケット受信時に、DPDが実行されます。 （注）E-CDSでは、リレーセットの選択に関連付けられたインターフェイスのセットに対して、1つの重複したテーブルが必要です。
2. If the packet is a duplicate, no further action is taken.
2. パケットが重複している場合、それ以上のアクションは行われません。
3. If the packet is non-duplicative:
3. パケットが重複していない場合：
A. A DPD entry is made for the packet identifier.
A.パケット識別子に対してDPDエントリが作成されます。
B. The packet is forwarded out to all interfaces associated with the relay set selection.
B.パケットは、リレーセットの選択に関連するすべてのインターフェイスに転送されます。
As previously mentioned, even packets sourced (or relayed) by routers not participating in NHDP and/or the E-CDS relay set selection may be forwarded by E-CDS forwarders without problem. A particular deployment MAY choose to not forward packets from previous hop routers that have been not explicitly identified via NHDP or other means as operating as part of a different relay set algorithm (e.g., S-MPR) to allow coexistent deployments to operate correctly. Also, E-CDS relay set selection may be configured to be influenced by statically configured CF relays that are identified via NHDP or other means.
前述のように、NHDPおよび/またはE-CDSリレーセットの選択に参加していないルーターによってソース（またはリレー）されたパケットでさえ、E-CDSフォワーダーによって問題なく転送できます。特定の展開では、共存する展開が正しく動作するように、別のリレーセットアルゴリズム（S-MPRなど）の一部として動作しているとNHDPまたはその他の手段で明示的に識別されていない、以前のホップルーターからのパケットを転送しないことを選択できます（MAY）。また、E-CDSリレーセットの選択は、NHDPまたは他の手段で識別される静的に構成されたCFリレーの影響を受けるように構成できます。
It is possible to perform E-CDS relay set selection without modification of NHDP, basing the self-election process exclusively on the "Neighbor Address List" of participating SMF routers, for example, by setting the Router Priority to a default value and selecting the Router ID as the numerically largest address contained in the "Neighbor Address List". However, steps MUST be taken to ensure that all NHDP-enabled routers not using SMF_TYPE:E-CDS full type Message TLVs are, in fact, running SMF E-CDS with the same methods for selecting Router Priority and Router ID; otherwise, incorrect forwarding may occur. Note that SMF routers with higher Router Priority values will be favored as relays over routers with lower Router Priority. Thus, preferred relays MAY be administratively configured to be selected when possible. Additionally, other metrics (e.g., nodal degree, energy capacity, etc.) may also be taken into account in constructing a Router Priority value. When using Router Priority with multiple interfaces, all interfaces on a router MUST use and advertise a common Router Priority value. A router's Router Priority value may be administratively or algorithmically selected. The method of selection does not need to be the same among different routers.
NHDPを変更せずにE-CDSリレーセット選択を実行できます。たとえば、ルーターの優先順位をデフォルト値に設定し、ルーターの優先順位を選択することで、自己選択プロセスを参加SMFルーターの「近隣アドレスリスト」のみに基づいて行うことができます。 「ネイバーアドレスリスト」に含まれる数値的に最大のアドレスとしてのルーターID。ただし、SMF_TYPE：E-CDSフルタイプメッセージTLVを使用していないすべてのNHDP対応ルーターが、実際にはルーター優先度とルーターIDを選択するための同じ方法でSMF E-CDSを実行していることを確認するための手順を実行する必要があります。そうしないと、不正な転送が発生する可能性があります。ルーター優先度の値が高いSMFルーターは、ルーター優先度の低いルーターを経由するリレーとして優先されることに注意してください。したがって、優先されるリレーは、可能な場合に選択されるように管理上設定される場合があります。さらに、ルーターの優先度の値を作成する際に、他のメトリック（節の次数、エネルギー容量など）も考慮に入れることができます。複数のインターフェースでルーター優先度を使用する場合、ルーター上のすべてのインターフェースは、共通のルーター優先度値を使用して通知する必要があります。ルーターのルーター優先度の値は、管理上またはアルゴリズムによって選択できます。選択方法は、異なるルーター間で同じである必要はありません。
E-CDS relay set selection may be configured to be influenced by statically configured CF relays that are identified via NHDP or other means. Nodes advertising CF through NHDP may be considered E-CDS SMF routers with maximal Router Priority.
E-CDSリレーセットの選択は、NHDPまたはその他の手段で識別される静的に構成されたCFリレーの影響を受けるように構成できます。 NHDPを介してCFをアドバタイズするノードは、最大のルーター優先度を持つE-CDS SMFルーターと見なすことができます。
To share a router's Router Priority with its 1-hop neighbors, the SMF_TYPE:E-CDS Message TLV's <value> field is defined as shown in Table 14.
ルータのルータプライオリティを1ホップネイバーと共有するために、SMF_TYPE：E-CDSメッセージTLVの<値>フィールドが表14に示すように定義されています。
+----------------+---------+-----------------+
| Length (bytes) | Value | Router Priority |
+----------------+---------+-----------------+
| 0 | N/A | 64 |
| 1 | <value> | 0-127 |
+----------------+---------+-----------------+
Table 14: E-CDS Message TLV Values
表14：E-CDSメッセージのTLV値
Where <value> is a one-octet-long bit field that is defined as:
ここで、<value>は次のように定義される1オクテット長のビットフィールドです。
bit 0: the leftmost bit is reserved and SHOULD be set to 0.
ビット0：左端のビットは予約されており、0に設定する必要があります。
bits 1-7: contain the unsigned Router Priority value, 0-127, which is associated with the "Neighbor Address List".
ビット1〜7：「ネイバーアドレスリスト」に関連付けられている、符号なしのルータプライオリティ値0〜127が含まれています。
Combinations of value field lengths and values other than specified here are NOT permitted and SHOULD be ignored. Figure 6 shows an example SMF_TYPE:E-CDS Message TLV.
値フィールドの長さとここで指定された以外の値の組み合わせは許可されず、無視する必要があります。図6は、SMF_TYPE：E-CDSメッセージTLVの例を示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | SMF_TYPE |1|0|0|1|0|0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| E-CDS |0|0|0|0|0|0|0|1|R| priority | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: E-CDS Message TLV Example
図6：E-CDSメッセージTLVの例
To convey Router Priority values among 2-hop neighborhoods, the SMF_NBR_TYPE:E-CDS Address Block TLV's <value> field is used. Multi-index and multivalue TLV layouts as defined in [RFC5444] are supported. SMF_NBR_TYPE:E-CDS value fields are defined thus:
2ホップネイバーフッド間でルータープライオリティ値を伝達するために、SMF_NBR_TYPE：E-CDSアドレスブロックTLVの<値>フィールドが使用されます。 [RFC5444]で定義されているマルチインデックスおよびマルチバリューTLVレイアウトがサポートされています。 SMF_NBR_TYPE：E-CDS値フィールドは次のように定義されています。
+---------------+--------+----------+-------------------------------+
| Length(bytes) | # Addr | Value | Router Priority |
+---------------+--------+----------+-------------------------------+
| 0 | Any | N/A | 64 |
| 1 | Any | <value> | <value> is for all addresses |
| N | N | <value>* | Each address gets its own |
| | | | <value> |
+---------------+--------+----------+-------------------------------+
Table 15: E-CDS Address Block TLV Values
表15：E-CDSアドレスブロックTLV値
Where <value> is a one-byte bit field that is defined as:
<値>は、次のように定義される1バイトのビットフィールドです。
bit 0: the leftmost bit is reserved and SHOULD be set to 0.
ビット0：左端のビットは予約されており、0に設定する必要があります。
bits 1-7: contain the unsigned Router Priority value, 0-127, which is associated with the appropriate address(es).
ビット1〜7：署名されていないルーター優先度の値0〜127が含まれ、適切なアドレスに関連付けられています。
Combinations of value field lengths and # of addresses other than specified here are NOT permitted and SHOULD be ignored. A default technique of using nodal degree (i.e., count of 1-hop neighbors) is RECOMMENDED for the value field of these TLV types. Below are two example SMF_NBR_TYPE:E-CDS Address Block TLVs.
値フィールドの長さとここで指定された以外のアドレスの数の組み合わせは許可されず、無視する必要があります。これらのTLVタイプの値フィールドには、ノード次数（つまり、1ホップのネイバーの数）を使用するデフォルトの手法が推奨されます。以下は、SMF_NBR_TYPE：E-CDSアドレスブロックTLVの2つの例です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | SMF_NBR_TYPE |1|0|0|1|0|0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| E-CDS |0|0|0|0|0|0|0|1|R| priority | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: E-CDS Address Block TLV Example 1
図7：E-CDSアドレスブロックTLVの例1
The single value example TLV, depicted in Figure 7, specifies that
all address(es) contained in the address block are running SMF using
the E-CDS algorithm and all address(es) share the value field and
therefore the same Router Priority.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | SMF_NBR_TYPE |1|0|1|1|0|1| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| E-CDS | index-start | index-end | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| priority0 |R| priority1 | ... |R| priorityN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: E-CDS Address Block TLV Example 2
図8：E-CDSアドレスブロックTLVの例2
The example multivalued TLV, depicted in Figure 8, specifies that address(es) contained in the address block from index-start to index-end inclusive are running SMF using the E-CDS algorithm. Each address is associated with its own value byte and therefore its own Router Priority.
図8に示す多値TLVの例では、index-startからindex-endまでのアドレスブロックに含まれるアドレスが、E-CDSアルゴリズムを使用してSMFを実行していることを指定しています。各アドレスは、独自の値バイトに関連付けられているため、独自のルーター優先度に関連付けられています。
This section describes an algorithm for E-CDS relay selection (self-election). The algorithm described uses 2-hop information. Note that it is possible to extend this algorithm to use k-hop information with added computational complexity and mechanisms for sharing k-hop topology information that are not described in this document or within the NHDP specification. It should also be noted that this algorithm does not impose the hop limit bound described in [RFC5614] when performing the path search that is used for relay selection. However, the algorithm below could be easily augmented to accommodate this additional criterion. It is not expected that the hop limit bound will provide significant benefit to the algorithm defined in this appendix.
このセクションでは、E-CDSリレー選択（自己選択）のアルゴリズムについて説明します。説明されているアルゴリズムは2ホップ情報を使用します。このアルゴリズムを拡張して、計算の複雑さを追加したkホップ情報と、このドキュメントまたはNHDP仕様に記載されていないkホップトポロジ情報を共有するメカニズムを使用することができます。また、このアルゴリズムは、リレー選択に使用されるパス検索を実行するときに、[RFC5614]で説明されているホップ制限の境界を課さないことにも注意してください。ただし、以下のアルゴリズムは、この追加の基準に対応するために簡単に拡張できます。ホップ制限の範囲がこの付録で定義されているアルゴリズムに大きな利益をもたらすとは考えられていません。
The tuple of Router Priority and Router ID is used in E-CDS relay set selection. Precedence is given to the Router Priority portion, and the Router ID value is used as a tiebreaker. The evaluation of this tuple is referred to as "RtrPri(n)" in the description below where "n" references a specific router. Note that it is possible that the Router Priority portion may be optional and the evaluation of "RtrPri()" be solely based upon the unique Router ID. Since there MUST NOT be any duplicate Router ID values among SMF routers, a comparison of "RtrPri(n)" between any two routers will always be an inequality. The use of nodal degree for calculating Router Priority is RECOMMENDED as default, and the largest IP address in the
ルーター優先度とルーターIDのタプルは、E-CDSリレーセットの選択で使用されます。優先順位はルーターの優先順位部分に与えられ、ルーターID値はタイブレーカーとして使用されます。このタプルの評価は、以下の説明では「RtrPri（n）」と呼ばれ、「n」は特定のルーターを参照します。ルーター優先度の部分はオプションであり、「RtrPri()」の評価は一意のルーターIDのみに基づく可能性があることに注意してください。 SMFルーター間で重複するルーターID値があってはならないため、2つのルーター間の「RtrPri（n）」の比較は常に不等式になります。ルーターの優先度を計算するためのノードの次数の使用は、デフォルトとして推奨され、最大のIPアドレスが
"Neighbor Address List" as advertised by NHDP MUST be used as the Router ID. NHDP provides all interface addresses throughout the 2-hop neighborhood through HELLO messages, so explicitly conveying a Router ID is not necessary. The following steps describe a basic algorithm for conducting E-CDS relay selection for a router "n0":
NHDPによってアドバタイズされる「ネイバーアドレスリスト」は、ルーターIDとして使用する必要があります。 NHDPは、HELLOメッセージを介して2ホップ近隣全体のすべてのインターフェイスアドレスを提供するため、ルーターIDを明示的に伝達する必要はありません。次の手順は、ルーター「n0」のE-CDSリレー選択を行うための基本的なアルゴリズムを示しています。
1. Initialize the set "N1" with tuples ("Router Priority", "Router ID", "Neighbor Address List") for each 1-hop neighbor of "n0".
1. 「n0」の1ホップネイバーごとに、タプル（「ルータープライオリティ」、「ルーターID」、「ネイバーアドレスリスト」）でセット「N1」を初期化します。
2. If "N1" has less than 2 tuples, then "n0" does not elect itself as a relay, and no further steps are taken.
2. 「N1」のタプルが2未満の場合、「n0」はそれ自体をリレーとして選択せず、それ以上のステップは実行されません。
3. Initialize the set "N2" with tuples ("Router Priority", "Router ID", "2-hop address") for each "2-hop address" of "n0", where "2-hop address" is defined in NHDP.
3. 「n0」の「2ホップアドレス」ごとにタプル（「ルータープライオリティ」、「ルーターID」、「2ホップアドレス」）でセット「N2」を初期化します。「2ホップアドレス」はNHDPで定義されています。
4. If "RtrPri(n0)" is greater than that of all tuples in the union of "N1" and "N2", then "n0" selects itself as a relay, and no further steps are taken.
4. 「RtrPri（n0）」が「N1」と「N2」の和集合内のすべてのタプルのタプルよりも大きい場合、「n0」はそれ自体をリレーとして選択し、それ以上のステップは実行されません。
5. Initialize all tuples in the union of "N1" and "N2" as "unvisited".
5. 「N1」と「N2」の和集合のすべてのタプルを「unvisited」として初期化します。
6. Find the tuple "n1_Max" that has the largest "RtrPri()" of all tuples in "N1".
6. 「N1」内のすべてのタプルの中で最大の「RtrPri()」を持つタプル「n1_Max」を見つけます。
7. Initialize queue "Q" to contain "n1_Max", marking "n1_Max" as "visited".
7. キュー「Q」を初期化して「n1_Max」を含め、「n1_Max」を「訪問済み」としてマークします。
8. While router queue "Q" is not empty, remove router "x" from the head of "Q", and for each 1-hop neighbor "n" of router "x" (excluding "n0") that is not marked "visited".
8. ルーターキュー "Q"は空ではありませんが、 "Q"の先頭からルーター "x"を削除し、 "visited"とマークされていないルーター "x"（ "n0"を除く）の1ホップネイバー "n"ごとに」
A. Mark router "n" as "visited".
A.ルータ「n」を「訪問済み」としてマークします。
B. If "RtrPri(n)" is greater than "RtrPri(n0)", append "n" to "Q".
B.「RtrPri（n）」が「RtrPri（n0）」より大きい場合は、「Q」に「n」を追加します。
9. If any tuple in "N1" remains "unvisited", then "n0" selects itself as a relay. Otherwise, "n0" does not act as a relay.
9. 「N1」のタプルが「未訪問」のままである場合、「n0」はそれ自体をリレーとして選択します。それ以外の場合、「n0」はリレーとして機能しません。
Note these steps are re-evaluated upon neighborhood status changes. Steps 5 through 8 of this procedure describe an approach to a path search. The purpose of this path search is to determine if paths exist from the 1-hop neighbor with maximum "RtrPri()" to all other 1-hop neighbors without traversing an intermediate router with a "RtrPri()" value less than "RtrPri(n0)". These steps comprise a breadth-first traversal that evaluates only paths that meet that criteria. If all 1-hop neighbors of "n0" are "visited" during this traversal, then the path search has succeeded, and router "n0" does not need to provide relay. It can be assumed that other routers will provide relay operation to ensure SMF connectivity.
これらの手順は、近隣のステータスが変更されると再評価されることに注意してください。この手順のステップ5〜8は、パス検索へのアプローチを説明しています。このパス検索の目的は、「RtrPri()」値が「RtrPri（」未満の中間ルーターを経由せずに、最大「RtrPri()」の1ホップネイバーから他のすべての1ホップネイバーへのパスが存在するかどうかを判断することですn0） "。これらのステップは、その条件を満たすパスのみを評価する幅優先トラバーサルで構成されます。このトラバーサル中に「n0」のすべての1ホップネイバーが「visited」であれば、パス検索は成功しており、ルーター「n0」はリレーを提供する必要はありません。他のルーターがリレー操作を提供してSMF接続を確実にすることが想定されます。
It is possible to extend this algorithm to consider neighboring SMF routers that are known to be statically configured for CF (always relaying). The modification to the above algorithm is to process such routers as having a maximum possible Router Priority value. It is expected that routers configured for CF and participating in NHDP would indicate this with use of the SMF_TYPE:CF and SMF_NBR_TYPE:CF TLV types in their NHDP_HELLO message and address blocks, respectively.
このアルゴリズムを拡張して、CFに対して静的に構成されていることがわかっている（常にリレーする）隣接するSMFルーターを考慮することができます。上記のアルゴリズムの変更は、可能な最大のルーター優先度値を持つルーターを処理することです。 CF用に構成され、NHDPに参加しているルーターは、NHDP_HELLOメッセージおよびアドレスブロックでそれぞれSMF_TYPE：CFおよびSMF_NBR_TYPE：CF TLVタイプを使用してこれを示すことが予想されます。
Appendix B. Source-Based Multipoint Relay (S-MPR) Algorithm
付録B.ソースベースのマルチポイントリレー（S-MPR）アルゴリズム
The source-based multipoint relay (S-MPR) set selection algorithm enables individual routers, using 2-hop topology information, to select relays from their set of neighboring routers. Relays are selected so that forwarding to the router's complete 2-hop neighbor set is covered. This distributed relay set selection technique has been shown to approximate a minimal connected dominating set (MCDS) in [JLMV02]. Individual routers must collect 2-hop neighborhood information from neighbors, determine an appropriate current relay set, and inform selected neighbors of their relay status. Note that since each router picks its neighboring relays independently, S-MPR forwarders depend upon previous hop information (e.g., source MAC address) to operate correctly. The Optimized Link State Routing (OLSR) protocol has used this algorithm and protocol for relay of link state updates and other control information [RFC3626], and it has been demonstrated operationally in dynamic network environments.
ソースベースのマルチポイントリレー（S-MPR）セット選択アルゴリズムにより、2ホップのトポロジ情報を使用して、個々のルーターが隣接ルーターのセットからリレーを選択できるようになります。リレーは、ルーターの完全な2ホップネイバーセットへの転送がカバーされるように選択されます。この分散リレーセット選択手法は、[JLMV02]で最小接続支配セット（MCDS）に近似することが示されています。個々のルーターは、ネイバーから2ホップのネイバーフッド情報を収集し、適切な現在のリレーセットを決定し、選択したネイバーにリレーステータスを通知する必要があります。各ルーターは隣接するリレーを個別に選択するため、S-MPRフォワーダーは以前のホップ情報（ソースMACアドレスなど）に依存して正しく動作することに注意してください。最適化されたリンク状態ルーティング（OLSR）プロトコルは、このアルゴリズムとプロトコルをリンク状態の更新とその他の制御情報[RFC3626]の中継に使用し、動的ネットワーク環境で動作することが実証されています。
It is RECOMMENDED that the SMF_TYPE:S-MPR Message TLV be included in NHDP_HELLO messages that are generated by routers conducting S-MPR SMF operation. It is also RECOMMENDED that the SMF_NBR_TYPE:S-MPR Address Block TLV be used to specify which neighbor routers are conducting S-MPR SMF operation.
SMF_TYPE：S-MPRメッセージTLVは、S-MPR SMF操作を実行するルーターによって生成されるNHDP_HELLOメッセージに含めることをお勧めします。また、SMF_NBR_TYPE：S-MPRアドレスブロックTLVを使用して、どの隣接ルーターがS-MPR SMF操作を実行しているかを指定することをお勧めします。
The S-MPR algorithm uses bi-directional 1-hop and 2-hop neighborhood information collected via NHDP to select, from a router's 1-hop neighbors, a set of relays that will cover the router's entire 2-hop neighbor set upon forwarding. The algorithm described uses a "greedy" heuristic of first picking the 1-hop neighbor who will cover the most 2-hop neighbors. Then, excluding those 2-hop neighbors that have been covered, additional relays from its 1-hop neighbor set are iteratively selected until the entire 2-hop neighborhood is covered. Note that 1-hop neighbors also identified as 2-hop neighbors are considered as 1-hop neighbors only.
S-MPRアルゴリズムは、NHDPを介して収集された双方向の1ホップおよび2ホップの近隣情報を使用して、ルーターの1ホップネイバーから、転送時にルーターの2ホップネイバーセット全体をカバーするリレーのセットを選択します。説明されているアルゴリズムは、最も多くの2ホップのネイバーをカバーする1ホップのネイバーを最初に選択する「貪欲な」ヒューリスティックを使用します。次に、カバーされた2ホップのネイバーを除外して、その1ホップのネイバーセットからの追加のリレーが、2ホップのネイバー全体がカバーされるまで繰り返し選択されます。 2ホップネイバーとしても識別される1ホップネイバーは、1ホップネイバーだけと見なされることに注意してください。
NHDP HELLO messages supporting S-MPR forwarding operation SHOULD use the TLVs defined in Section 8.1 using the S-MPR extended type. The value field of an Address Block TLV that has a full type value of SMF_NBR_TYPE:S-MPR is defined in Table 17 such that signaling of MPR selections to 1-hop neighbors is possible. The value field of a message block TLV that has a full type value of SMF_TYPE:S-MPR is defined in Table 16 such that signaling of Router Priority (described as "WILLINGNESS" in [RFC3626]) to 1-hop neighbors is possible. It is important to note that S-MPR forwarding is dependent upon the previous hop of an incoming packet. An S-MPR router MUST forward packets only for neighbors that have explicitly selected it as a multipoint relay (i.e., its "selectors"). There are also some additional requirements for duplicate packet detection to support S-MPR SMF operation that are described below.
S-MPR転送操作をサポートするNHDP HELLOメッセージは、S-MPR拡張タイプを使用してセクション8.1で定義されたTLVを使用する必要があります（SHOULD）。 SMF_NBR_TYPE：S-MPRの完全なタイプ値を持つアドレスブロックTLVの値フィールドは、1ホップのネイバーへのMPR選択のシグナリングが可能になるように、表17で定義されています。 SMF_TYPE：S-MPRの完全なタイプ値を持つメッセージブロックTLVの値フィールドは、表16で定義されており、1ホップのネイバーへのルーター優先度（[RFC3626]の「WILLINGNESS」と記述）のシグナリングが可能です。 S-MPR転送は、着信パケットの前のホップに依存することに注意することが重要です。 S-MPRルーターは、マルチポイントリレーとして明示的に選択したネイバー（つまり、その「セレクター」）に対してのみパケットを転送する必要があります。 S-MPR SMF操作をサポートするための重複パケット検出には、以下に説明する追加の要件もあります。
For multiple interface operation, MPR selection SHOULD be conducted on a per-interface basis. However, it is possible to economize MPR selection among multiple interfaces by selecting common MPRs to the extent possible.
複数のインターフェース操作の場合、MPR選択はインターフェースごとに行う必要があります（SHOULD）。ただし、可能な限り共通のMPRを選択することにより、複数のインターフェイス間でのMPR選択を節約することができます。
An S-MPR SMF router MUST only forward packets for neighbors that have explicitly selected it as an MPR. The source-based forwarding technique also stipulates some additional duplicate packet detection operations. For multiple network interfaces, independent DPD state MUST be maintained for each separate interface. The following provides the procedure for S-MPR packet forwarding given the arrival of a packet on a given interface, denoted <srcIface>. There are three possible actions, depending upon the previous-hop transmitter:
S-MPR SMFルーターは、MPRとして明示的に選択したネイバーにのみパケットを転送する必要があります。送信元ベースの転送手法では、追加の重複パケット検出操作もいくつか規定されています。複数のネットワークインターフェースの場合、個別のインターフェースごとに独立したDPD状態を維持する必要があります。以下は、<srcIface>で示される特定のインターフェイスにパケットが到着した場合のS-MPRパケット転送の手順を示しています。前のホップのトランスミッタに応じて、3つの可能なアクションがあります。
1. If the previous-hop transmitter has selected the current router as an MPR,
1. 前のホップの送信機が現在のルーターをMPRとして選択した場合、
A. The packet identifier is checked against the DPD state for each possible outbound interface, including the <srcIface>.
A.パケットIDは、<srcIface>を含む、可能な各送信インターフェイスのDPD状態に対してチェックされます。
B. If the packet is not a duplicate for an outbound interface, the packet is forwarded on that interface and a DPD entry is made for the given packet identifier for the interface.
B.パケットがアウトバウンドインターフェイスで重複していない場合、パケットはそのインターフェイスで転送され、インターフェイスの指定されたパケット識別子に対してDPDエントリが作成されます。
C. If the packet is a duplicate, no action is taken for that interface.
C.パケットが重複している場合、そのインターフェイスに対してアクションは実行されません。
2. Else, if the previous-hop transmitter is a 1-hop symmetric neighbor, a DPD entry is added for that packet for the <srcIface>, but the packet is not forwarded.
2. それ以外の場合、前のホップのトランスミッタが1ホップの対称ネイバーの場合、<srcIface>のそのパケットのDPDエントリが追加されますが、パケットは転送されません。
3. Otherwise, no action is taken.
3. それ以外の場合、アクションは実行されません。
Action number two in the list above is non-intuitive but important to ensure correctness of S-MPR SMF operation. The selection of source-based relays does not result in a common set among neighboring routers, so relays MUST mark, in their DPD state, packets received from non-selector, symmetric, 1-hop neighbors (for a given interface) and not forward subsequent duplicates of that packet if received on that interface. Deviation here can result in unnecessary, repeated packet forwarding throughout the network or incomplete flooding.
上記のリストのアクション番号2は直感的ではありませんが、S-MPR SMF操作の正確性を保証するために重要です。ソースベースのリレーを選択しても、隣接ルーター間で共通のセットが生成されないため、リレーは、DPD状態で、非セレクターの対称1ホップネイバーから受信したパケットを（指定されたインターフェースに対して）マークし、転送しないようにする必要がありますそのインターフェイスで受信された場合、そのパケットの後続の複製。ここでの逸脱は、ネットワーク全体で不必要な繰り返しパケット転送や不完全なフラッディングを引き起こす可能性があります。
Nodes not participating in neighborhood discovery and relay set selection will not be able to source multicast packets into the area and have SMF forward them, unlike E-CDS or MPR-CDS where forwarding may occur dependent on topology. Correct S-MPR relay behavior will occur with the introduction of repeaters (non-NHDP/SMF participants that relay multicast packets using duplicate detection and CF), but the repeaters will not efficiently contribute to S-MPR forwarding as these routers will not be identified as neighbors (symmetric or otherwise) in the S-MPR forwarding process. NHDP/SMF participants MUST NOT forward packets that are not selected by the algorithm, as this can disrupt network-wide S-MPR flooding, resulting in incomplete or inefficient flooding. The result is that non-S-MPR SMF routers will be unable to source multicast packets and have them forwarded by other S-MPR SMF routers.
近隣探索およびリレーセット選択に参加していないノードは、トポロジに応じて転送が行われるE-CDSまたはMPR-CDSとは異なり、マルチキャストパケットをエリアに送信してSMFに転送させることができません。リピーター（重複検出とCFを使用してマルチキャストパケットをリレーする非NHDP / SMF参加者）を導入すると、正しいS-MPRリレー動作が発生しますが、これらのルーターは識別されないため、リピーターはS-MPR転送に効率的に貢献しません。 S-MPR転送プロセスのネイバー（対称またはその他）として。 NHDP / SMF参加者は、アルゴリズムによって選択されていないパケットを転送してはなりません。これは、ネットワーク全体のS-MPRフラッディングを混乱させ、不完全または非効率的なフラッディングを引き起こす可能性があるためです。その結果、非S-MPR SMFルーターはマルチキャストパケットを送信できず、他のS-MPR SMFルーターによって転送されるようになります。
Nodes may optionally signal a Router Priority value to their 1-hop neighbors by using the SMF_TYPE:S-MPR message block TLV value field. If the value field is omitted, a default Router Priority value of 64 is to be assumed. This is summarized here:
ノードは、SMF_TYPE：S-MPRメッセージブロックTLV値フィールドを使用して、ルータープライオリティ値を1ホップネイバーにオプションで通知できます。値フィールドが省略されている場合、デフォルトのルーター優先順位値64が想定されます。これはここに要約されています：
+---------------+---------+-----------------+
| Length(bytes) | Value | Router Priority |
+---------------+---------+-----------------+
| 0 | N/A | 64 |
| 1 | <value> | 0-127 |
+---------------+---------+-----------------+
Table 16: S-MPR Message TLV Values
表16：S-MPRメッセージのTLV値
Where <value> is a one-octet-long bit field defined as:
ここで、<値>は次のように定義される1オクテット長のビットフィールドです
bit 0: the leftmost bit is reserved and SHOULD be set to 0.
ビット0：左端のビットは予約されており、0に設定する必要があります。
bits 1-7: contain the Router Priority value, 0-127, which is associated with the "Neighbor Address List".
ビット1〜7：ルータープライオリティ値0〜127が含まれます。これは、「近隣アドレスリスト」に関連付けられています。
Router Priority values for S-MPR are interpreted in the same fashion as "WILLINGNESS" ([RFC3626]), with the value 0 indicating a router will NEVER forward and value 127 indicating a router will ALWAYS forward. Values 1-126 indicate how likely a S-MPR SMF router will be selected as an MPR by a neighboring SMF router, with higher values increasing the likelihood. Combinations of value field lengths and values other than those specified here are NOT permitted and SHOULD be ignored. Below is an example SMF_TYPE:S-MPR Message TLV.
S-MPRのルーター優先度の値は「WILLINGNESS」（[RFC3626]）と同じように解釈され、値0はルーターが転送しないことを示し、値127は常に転送することを示します。値1から126は、S-MPR SMFルーターが近隣のSMFルーターによってMPRとして選択される可能性を示します。値が大きいほど、可能性が高くなります。値フィールドの長さとここで指定された以外の値の組み合わせは許可されず、無視する必要があります。以下は、SMF_TYPE：S-MPRメッセージTLVの例です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | SMF_TYPE |1|0|0|1|0|0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S-MPR |0|0|0|0|0|0|0|1|R| priority | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: S-MPR Message TLV Example
図9：S-MPRメッセージTLVの例
S-MPR election operation requires 2-hop neighbor knowledge as provided by NHDP [RFC6130] or from external sources. MPRs are dynamically selected by each router, and selections MUST be advertised and dynamically updated within NHDP or an equivalent protocol or mechanism. For NHDP use, the SMF_NBR_TYPE:S-MPR Address Block TLV value field is defined as such:
S-MPR選定操作には、NHDP [RFC6130]または外部ソースから提供される2ホップのネイバー知識が必要です。 MPRは各ルーターによって動的に選択され、NHDPまたは同等のプロトコルまたはメカニズム内で選択をアドバタイズおよび動的に更新する必要があります。 NHDPを使用する場合、SMF_NBR_TYPE：S-MPRアドレスブロックTLV値フィールドは次のように定義されます。
+---------------+--------+----------+-------------------------------+
| Length(bytes) | # Addr | Value | Meaning |
+---------------+--------+----------+-------------------------------+
| 0 | Any | N/A | NOT MPRs |
| 1 | Any | <value> | <value> is for all addresses |
| N | N | <value>* | Each address gets its own |
| | | | <value> |
+---------------+--------+----------+-------------------------------+
Table 17: S-MPR Address Block TLV Values
表17：S-MPRアドレスブロックTLV値
Where <value>, if present, is a one-octet bit field defined as:
ここで、<value>は、存在する場合、次のように定義された1オクテットのビットフィールドです。
bit 0: The leftmost bit is the M bit that, when set, indicates MPR selection of the relevant interface, represented by the associated address(es), by the originator router of the NHDP HELLO message. When unset, it indicates the originator router of the NHDP HELLO message has not selected the relevant interfaces, represented by the associated address(es), as its MPR.
ビット0：左端のビットはMビットであり、設定されている場合、NHDP HELLOメッセージの発信元ルーターによる、関連するアドレスで表される、関連するインターフェイスのMPR選択を示します。設定されていない場合、NHDP HELLOメッセージの発信元ルーターが、関連するアドレスで表される関連インターフェースをMPRとして選択していないことを示します。
bits 1-7: These bits are reserved and SHOULD be set to 0.
ビット1〜7：これらのビットは予約されており、0に設定する必要があります。
Combinations of value field lengths and number of addresses other than specified here are NOT permitted and SHOULD be ignored. All bits, excepting the leftmost bit, are RESERVED and SHOULD be set to 0.
ここで指定されている以外の値フィールド長とアドレス数の組み合わせは許可されず、無視する必要があります。左端のビットを除くすべてのビットは予約済みであり、0に設定する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | SMF_NBR_TYPE |1|1|0|1|0|0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S-MPR | start-index |0|0|0|0|0|0|0|1|M| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: S-MPR Address Block TLV Example
図10：S-MPRアドレスブロックTLVの例
The single index TLV example, depicted in Figure 10, indicates that the address specified by the <start-index> field is running SMF using S-MPR and has been selected by the originator of the NHDP HELLO message as an MPR forwarder if the M bit is set. Multivalued TLVs may also be used to specify MPR selection status of multiple addresses using only one TLV. See Figure 8 for a similar example on how this may be done.
図10に示されている単一インデックスTLVの例は、<start-index>フィールドで指定されたアドレスがS-MPRを使用してSMFを実行しており、NHDP HELLOメッセージの発信者がMの場合にMPRフォワーダーとして選択したことを示しています。ビットが設定されています。複数値のTLVを使用して、1つのTLVのみを使用する複数のアドレスのMPR選択ステータスを指定することもできます。これを行う方法の同様の例については、図8を参照してください。
This section describes a basic algorithm for the S-MPR selection process. Note that the selection is with respect to a specific interface of the router performing selection, and other router interfaces referenced are reachable from this reference router interface. This is consistent with the S-MPR forwarding rules described above. When multiple interfaces per router are used, it is possible to enhance the overall selection process across multiple interfaces such that common routers are selected as MPRs for each interface to avoid unnecessary inefficiencies in flooding. The following steps describe a basic algorithm for conducting S-MPR selection for a router interface "n0": 1. Initialize the set "MPR" to empty.
このセクションでは、S-MPR選択プロセスの基本的なアルゴリズムについて説明します。選択は、選択を実行しているルーターの特定のインターフェイスを基準としているため、参照されている他のルーターインターフェイスには、この参照ルーターインターフェイスから到達できることに注意してください。これは、上記のS-MPR転送ルールと一致しています。ルーターごとに複数のインターフェイスを使用する場合、共通のルーターが各インターフェイスのMPRとして選択されるように、複数のインターフェイスにまたがる全体的な選択プロセスを強化して、フラッディングの不必要な非効率性を回避できます。次の手順は、ルータインターフェイス「n0」のS-MPR選択を行うための基本的なアルゴリズムを示しています。1.セット「MPR」を空に初期化します。
2. Initialize the set "N1" to include all 1-hop neighbors of "n0".
2. セット「N1」を初期化して、「n0」のすべての1ホップネイバーを含めます。
3. Initialize the set "N2" to include all 2-hop neighbors, excluding "n0" and any routers in "N1". Nodes that are only reachable via "N1" routers with router priority values of NEVER are also excluded.
3. セット「N2」を初期化して、「n0」と「N1」内のルーターを除くすべての2ホップネイバーを含めます。ルーター優先度の値がNEVERである「N1」ルーター経由でのみ到達可能なノードも除外されます。
4. For each interface "y" in "N1", initialize a set "N2(y)" to include any interfaces in "N2" that are 1-hop neighbors of "y".
4. 「N1」の各インターフェース「y」について、セット「N2（y）」を初期化して、「y」の1ホップの隣接ノードである「N2」のインターフェースをすべて含めます。
5. For each interface "x" in "N1" with a router priority value of "ALWAYS" (or using the CF relay algorithm), select "x" as an MPR:
5. ルータプライオリティ値が「ALWAYS」である（またはCFリレーアルゴリズムを使用する）「N1」の各インターフェイス「x」について、MPRとして「x」を選択します。
A. Add "x" to the set "MPR" and remove "x" from "N1".
A.セット「MPR」に「x」を追加し、「N1」から「x」を削除します。
B. For each interface "z" in "N2(x)", remove "z" from "N2".
B.「N2（x）」の各インターフェース「z」について、「N2」から「z」を削除します。
C. For each interface "y" in "N1", remove any interfaces in "N2(x)" from "N2(y)".
C.「N1」の各インターフェース「y」について、「N2（x）」のインターフェースを「N2（y）」から削除します。
6. For each interface "z" in "N2", initialize the set "N1(z)" to include any interfaces in "N1" that are 1-hop neighbors of "z".
6. 「N2」の各インターフェース「z」について、セット「N1（z）」を初期化して、「z」の1ホップのネイバーである「N1」のインターフェースをすべて含めます。
7. For each interface "x" in "N2" where "N1(x)" has only one member, select "x" as an MPR:
7. 「N1（x）」にメンバーが1つしかない「N2」の各インターフェース「x」について、「x」をMPRとして選択します。
A. Add "x" to the set "MPR" and remove "x" from "N1".
A.セット「MPR」に「x」を追加し、「N1」から「x」を削除します。
B. For each interface "z" in "N2(x)", remove "z" from "N2" and delete "N1(z)".
B.「N2（x）」の各インターフェース「z」について、「N2」から「z」を削除し、「N1（z）」を削除します。
C. For each interface "y" in "N1", remove any interfaces in "N2(x)" from "N2(y)".
C.「N1」の各インターフェース「y」について、「N2（x）」のインターフェースを「N2（y）」から削除します。
8. While "N2" is not empty, select the interface "x" in "N1" with the largest router priority that has the number of members in "N_2(x)" as an MPR:
8. 「N2」は空ではありませんが、「N_2（x）」のメンバー数を持つ最大のルーター優先度を持つ「N1」のインターフェース「x」をMPRとして選択します。
A. Add "x" to the set "MPR" and remove "x" from "N1".
A.セット「MPR」に「x」を追加し、「N1」から「x」を削除します。
B. For each interface "z" in "N2(x)", remove "z" from "N2".
B.「N2（x）」の各インターフェース「z」について、「N2」から「z」を削除します。
C. For each interface "y" in "N1", remove any interfaces in "N2(x)" from "N2(y)".
C.「N1」の各インターフェース「y」について、「N2（x）」のインターフェースを「N2（y）」から削除します。
After the set of routers "MPR" is selected, router "n_0" must signal its selections to its neighbors. With NHDP, this is done by using the MPR Address Block TLV to mark selected neighbor addresses in NHDP_HELLO messages. Neighbors MUST record their MPR selection status and the previous hop address (e.g., link or MAC layer) of the selector. Note these steps are re-evaluated upon neighborhood status changes.
ルーターのセット "MPR"が選択された後、ルーター "n_0"はその選択を近隣に通知する必要があります。 NHDPでは、これはMPRアドレスブロックTLVを使用して、NHDP_HELLOメッセージで選択されたネイバーアドレスをマークすることによって行われます。ネイバーは、MPR選択ステータスとセレクターの前のホップアドレス（リンクやMACレイヤーなど）を記録する必要があります。これらの手順は、近隣のステータスが変更されると再評価されることに注意してください。
Appendix C. Multipoint Relay Connected Dominating Set (MPR-CDS) Algorithm
付録C.マルチポイントリレー接続支配セット（MPR-CDS）アルゴリズム
The MPR-CDS algorithm is an extension to the basic S-MPR election algorithm that results in a shared (non-source-specific) SMF CDS. Thus, its forwarding rules are not dependent upon previous hop information, similar to E-CDS. An overview of the MPR-CDS selection algorithm is provided in [MPR-CDS].
MPR-CDSアルゴリズムは、共有（ソース固有ではない）SMF CDSを生成する基本的なS-MPR選定アルゴリズムの拡張です。したがって、その転送ルールは、E-CDSと同様に、以前のホップ情報に依存しません。 MPR-CDS選択アルゴリズムの概要は、[MPR-CDS]で提供されています。
It is RECOMMENDED that the SMF_TYPE Message TLV be included in NHDP_HELLO messages that are generated by routers conducting MPR-CDS SMF operation.
MPR-CDS SMF操作を実行するルーターによって生成されるNHDP_HELLOメッセージにSMF_TYPEメッセージTLVを含めることをお勧めします。
The MPR-CDS relay set selection process is based upon the MPR selection process of the S-MPR algorithm with the added refinement of a distributed technique for subsequently down-selecting to a common reduced, shared relay set. A router ordering (or "prioritization") metric is used as part of this down-selection process; like the E-CDS algorithm, this metric can be based upon router address(es) or some other unique router identifier (e.g., Router ID based on largest address contained within the "Neighbor Address List") as well as an additional Router Priority measure, if desired. The process for MPR-CDS relay selection is as follows:
MPR-CDSリレーセット選択プロセスは、S-MPRアルゴリズムのMPR選択プロセスに基づいており、共通の縮小された共有リレーセットに後でダウン選択するための分散技術の改良が追加されています。ルーターの順序付け（または「優先順位付け」）メトリックは、このダウン選択プロセスの一部として使用されます。 E-CDSアルゴリズムと同様に、このメトリックは、ルーターアドレスまたはその他の一意のルーター識別子（たとえば、「隣接アドレスリスト」に含まれる最大アドレスに基づくルーターID）と、追加のルータープライオリティメジャーに基づくことができます。 、必要に応じて。 MPR-CDSリレー選択のプロセスは次のとおりです。
1. First, MPR selection per the S-MPR algorithm is conducted, with selectors informing their MPRs (via NHDP) of their selection.
1. 最初に、S-MPRアルゴリズムによるMPR選択が行われ、セレクターが（NHDPを介して）MPRに選択を通知します。
2. Then, the following rules are used on a distributed basis by selected routers to possibly deselect themselves and thus jointly establish a common set of shared SMF relays:
2. 次に、次のルールが選択されたルーターによって分散ベースで使用され、それらの選択を解除して、共有SMFリレーの共通セットを共同で確立します。
A. If a selected router has a larger "RtrPri()" than all of its 1-hop symmetric neighbors, then it acts as a relay for all multicast traffic, regardless of the previous hop.
A.選択したルータの1ホップ対称ネイバーのすべてよりも「RtrPri()」が大きい場合、前のホップに関係なく、すべてのマルチキャストトラフィックのリレーとして機能します。
B. Else, if the 1-hop symmetric neighbor with the largest "RtrPri()" value has selected the router, then it also acts as a relay for all multicast traffic, regardless of the previous hop.
B.それ以外の場合、最大の「RtrPri()」値を持つ1ホップの対称ネイバーがルータを選択した場合、前のホップに関係なく、すべてのマルチキャストトラフィックのリレーとしても機能します。
C. Otherwise, it deselects itself as a relay and does not forward any traffic unless changes occur that require re-evaluation of the above steps.
C.それ以外の場合は、それ自体をリレーとして選択解除し、上記の手順の再評価を必要とする変更が発生しない限り、トラフィックを転送しません。
This technique shares many of the desirable properties of the E-CDS technique with regards to compatibility with multicast sources not participating in NHDP and the opportunity for statically configured CF routers to be present, regardless of their participation in NHDP.
この技術は、NHDPに参加していないマルチキャストソースとの互換性、およびNHDPへの参加に関係なく、静的に構成されたCFルーターが存在する機会に関して、E-CDS技術の望ましい特性の多くを共有します。
The forwarding rules for MPR-CDS are similar to those for E-CDS. Any SMF router that has selected itself as a relay performs DPD and forwards all non-duplicative multicast traffic allowed by the present forwarding policy. Packet previous hop knowledge is not needed for forwarding decisions when using MPR-CDS.
MPR-CDSの転送ルールは、E-CDSの転送ルールと同様です。自身をリレーとして選択したSMFルーターは、DPDを実行し、現在の転送ポリシーで許可されているすべての非重複マルチキャストトラフィックを転送します。 MPR-CDSを使用する場合、転送の決定にパケットの以前のホップの知識は必要ありません。
1. Upon packet reception, DPD is performed. Note that MPR-CDS requires one duplicate table for the set of interfaces associated with the relay set selection.
1. パケット受信時に、DPDが実行されます。 MPR-CDSでは、リレーセットの選択に関連付けられたインターフェイスのセットに対して1つの重複したテーブルが必要であることに注意してください。
2. If the packet is a duplicate, no further action is taken.
2. パケットが重複している場合、それ以上のアクションは行われません。
3. If the packet is non-duplicative:
3. パケットが重複していない場合：
A. A DPD entry is added for the packet identifier
A.パケット識別子にDPDエントリが追加されます
B. The packet is forwarded out to all interfaces associated with the relay set selection.
B.パケットは、リレーセットの選択に関連するすべてのインターフェイスに転送されます。
As previously mentioned, even packets sourced (or relayed) by routers not participating in NHDP and/or the MPR-CDS relay set selection may be forwarded by MPR-CDS forwarders without problem. A particular deployment MAY choose to not forward packets from sources or relays that have been explicitly identified via NHDP or other means as operating as part of a different relay set algorithm (e.g., S-MPR) to allow coexistent deployments to operate correctly.
前述のように、NHDPおよび/またはMPR-CDSリレーセットの選択に参加していないルーターがソース（またはリレー）のパケットであっても、問題なくMPR-CDSフォワーダーで転送できます。特定の展開では、NHDPまたは他の手段を介して明示的に識別されたソースまたはリレーからのパケットを、異なるリレーセットアルゴリズム（S-MPRなど）の一部として動作しているとして転送しないことで、共存する展開が正しく動作するようにすることができます。
The neighborhood discovery requirements for MPR-CDS have commonality with both the S-MPR and E-CDS algorithms. MPR-CDS selection operation requires 2-hop neighbor knowledge as provided by NHDP
MPR-CDSの近隣探索要件は、S-MPRおよびE-CDSアルゴリズムの両方と共通しています。 MPR-CDS選択操作には、NHDPによって提供される2ホップのネイバー知識が必要です
[RFC6130] or from external sources. Unlike S-MPR operation, there is no need for associating link-layer address information with 1-hop neighbors since MPR-CDS forwarding is independent of the previous hop similar to E-CDS forwarding.
[RFC6130]または外部ソースから。 S-MPR動作とは異なり、MPR-CDS転送はE-CDS転送と同様に前のホップから独立しているため、リンク層アドレス情報を1ホップのネイバーに関連付ける必要はありません。
To advertise an optional Router Priority value or "WILLINGNESS", an originating router may use the Message TLV of type SMF_TYPE:MPR-CDS, which shares a common <value> format with both SMF_TYPE:E-CDS (Table 14) and SMF_TYPE:S-MPR (Table 16).
オプションのルータープライオリティ値または「WILLINGNESS」をアドバタイズするために、発信元ルーターは、SMF_TYPE：E-CDS（表14）とSMF_TYPEの両方と共通の<値>形式を共有するタイプSMF_TYPE：MPR-CDSのメッセージTLVを使用できます。 S-MPR（表16）。
MPR-CDS only requires 1-hop knowledge of Router Priority for correct operation. In the S-MPR phase of MPR-CDS selection, MPRs are dynamically determined by each router, and selections MUST be advertised and dynamically updated using NHDP or an equivalent protocol or mechanism. The <value> field of the SMF_NBR_TYPE:MPR-CDS type TLV shares a common format with SMF_NBR_TYPE:S-MPR (Table 17) to convey MPR selection.
MPR-CDSが正しく動作するには、ルータープライオリティの1ホップの知識のみが必要です。 MPR-CDS選択のS-MPRフェーズでは、MPRは各ルーターによって動的に決定され、NHDPまたは同等のプロトコルまたはメカニズムを使用して、選択をアドバタイズおよび動的に更新する必要があります。 SMF_NBR_TYPE：MPR-CDSタイプTLVの<値>フィールドは、MPR選択を伝達するためにSMF_NBR_TYPE：S-MPR（表17）と共通の形式を共有します。
This section describes an algorithm for the MPR-CDS selection process. Note that the selection described is with respect to a specific interface of the router performing selection, and other router interfaces referenced are reachable from this reference router interface. An ordered tuple of Router Priority and Router ID is used in MPR-CDS relay set selection. The Router ID value should be set to the largest advertised address of a given router; this information is provided to one-hop neighbors via NHDP by default. Precedence is given to the Router Priority portion, and the Router ID value is used as a tiebreaker. The evaluation of this tuple is referred to as "RtrPri(n)" in the description below where "n" references a specific router. Note that it is possible that the Router Priority portion may be optional and the evaluation of "RtrPri()" be solely based upon the unique Router ID. Since there MUST NOT be any duplicate address values among SMF routers, a comparison of "RtrPri(n)" between any two routers will always be an inequality. The following steps, repeated upon any changes detected within the 1-hop and 2-hop neighborhood, describe a basic algorithm for conducting MPR-CDS selection for a router interface "n0":
このセクションでは、MPR-CDS選択プロセスのアルゴリズムについて説明します。ここで説明する選択は、選択を実行するルーターの特定のインターフェイスに関するものであり、参照される他のルーターインターフェイスには、この参照ルーターインターフェイスから到達できることに注意してください。ルーター優先順位とルーターIDの順序付けられたタプルは、MPR-CDSリレーセットの選択で使用されます。ルーターID値は、特定のルーターのアドバタイズされた最大のアドレスに設定する必要があります。この情報は、デフォルトでNHDPを介して1ホップのネイバーに提供されます。優先順位はルーターの優先順位部分に与えられ、ルーターID値はタイブレーカーとして使用されます。このタプルの評価は、以下の説明では「RtrPri（n）」と呼ばれ、「n」は特定のルーターを参照します。ルーター優先度の部分はオプションであり、「RtrPri()」の評価は一意のルーターIDのみに基づく可能性があることに注意してください。 SMFルーター間で重複するアドレス値があってはならないため、2つのルーター間の「RtrPri（n）」の比較は常に不等式になります。 1ホップおよび2ホップの近傍内で検出された変更に対して繰り返される次の手順は、ルーターインターフェイス「n0」のMPR-CDS選択を行うための基本的なアルゴリズムを示しています。
1. Perform steps 1-8 of Appendix B.4 to select MPRs from the set of 1-hop neighbors of "n0" and notify/update neighbors of selections.
1. 付録B.4の手順1〜8を実行して、「n0」の1ホップネイバーのセットからMPRを選択し、ネイバーに選択を通知/更新します。
2. Upon being selected as an MPR (or any change in the set of routers selecting "n0" as an MPR): A. If no neighbors have selected "n0" as an MPR, "n0" does not act as a relay, and no further steps are taken until a change in neighborhood topology or selection status occurs.
2. MPR（またはMPRとして「n0」を選択する一連のルーターの変更）として選択された場合：A.「n0」がMPRとして選択されたネイバーがない場合、「n0」はリレーとして機能しません。近隣トポロジまたは選択ステータスが変更されるまで、それ以上の手順は実行されません。
B. Determine the router "n1_max" that has the maximum "RtrPri()" of all 1-hop neighbors.
B.すべての1ホップネイバーの最大「RtrPri()」を持つルータ「n1_max」を決定します。
C. If "RtrPri(n0)" is greater than "RtrPri(n1_max)", then "n0" selects itself as a relay for all multicast packets.
C.「RtrPri（n0）」が「RtrPri（n1_max）」より大きい場合、「n0」はすべてのマルチキャストパケットのリレーとして自分自身を選択します。
D. Else, if "n1_max" has selected "n0" as an MPR, then "0" selects itself as a relay for all multicast packets.
D.それ以外の場合、「n1_max」がMPRとして「n0」を選択した場合、「0」はすべてのマルチキャストパケットのリレーとして自分自身を選択します。
E. Otherwise, "n0" does not act as a relay.
E.それ以外の場合、「n0」はリレーとして機能しません。
It is possible to extend this algorithm to consider neighboring SMF routers that are known to be statically configured for CF (always relaying). The modification to the above algorithm is to process such routers as having a maximum possible Router Priority value. This is the same as the case for participating routers that have been configured with a S-MPR "WILLINGNESS" value of "WILL_ALWAYS". It is expected that routers configured for CF and participating in NHDP would indicate their status with use of the SMF_TYPE TLV type in their NHDP_HELLO message TLV block. It is important to note, however, that CF routers will not select MPR routers and therefore cannot guarantee connectedness.
このアルゴリズムを拡張して、CFに対して静的に構成されていることがわかっている（常にリレーする）隣接するSMFルーターを考慮することができます。上記のアルゴリズムの変更は、可能な最大のルーター優先度値を持つルーターを処理することです。これは、S-MPRの「WILLINGNESS」値が「WILL_ALWAYS」に設定されている参加ルーターの場合と同じです。 CF用に構成され、NHDPに参加しているルーターは、NHDP_HELLOメッセージTLVブロックでSMF_TYPE TLVタイプを使用して、そのステータスを示すことが期待されます。ただし、CFルーターはMPRルーターを選択しないため、接続を保証できないことに注意してください。
Author's Address
著者のアドレス
Joseph Macker (editor) NRL Washington, DC 20375 USA
Joseph Macker（編集者）NRLワシントンDC 20375米国
EMail: macker@itd.nrl.navy.mil