RFC3684 日本語訳
3684 Topology Dissemination Based on Reverse-Path Forwarding (TBRPF).R. Ogier, F. Templin, M. Lewis. February 2004. (Format: TXT=107963 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Ogier
Request for Comments: 3684 SRI International
Category: Experimental F. Templin
Nokia
M. Lewis
SRI International
February 2004
Network Working Group R. Ogier Request for Comments: 3684 SRI International Category: Experimental F. Templin Nokia M. Lewis SRI International February 2004
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)
Status of this Memo
Status of this Memo
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Abstract
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a proactive, link-state routing protocol designed for mobile ad-hoc networks, which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree (providing paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification of Dijkstra's algorithm. To minimize overhead, each node reports only *part* of its source tree to neighbors. TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report additional topology information (up to the full topology), to provide improved robustness in highly mobile networks. TBRPF performs neighbor discovery using "differential" HELLO messages which report only *changes* in the status of neighbors. This results in HELLO messages that are much smaller than those of other link-state routing protocols such as OSPF.
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a proactive, link-state routing protocol designed for mobile ad-hoc networks, which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree (providing paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification of Dijkstra's algorithm. To minimize overhead, each node reports only *part* of its source tree to neighbors. TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report additional topology information (up to the full topology), to provide improved robustness in highly mobile networks. TBRPF performs neighbor discovery using "differential" HELLO messages which report only *changes* in the status of neighbors. This results in HELLO messages that are much smaller than those of other link-state routing protocols such as OSPF.
Ogier, et al. Experimental [Page 1] RFC 3684 TBRPF February 2004
Ogier, et al. Experimental [Page 1] RFC 3684 TBRPF February 2004
Table of Contents
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Applicability Section . . . . . . . . . . . . . . . . . . . . 5
5. TBRPF Overview. . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Overview of Neighbor Discovery . . . . . . . . . . . . 6
5.2. Overview of the Routing Module. .. . . . . . . . . . . 8
6. TBRPF Packets . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. TBRPF Packet Header. . . . . . . . . . . . . . . . . . 10
6.2. TBRPF Packet Body. . . . . . . . . . . . . . . . . . . 11
6.2.1. Padding Options (TYPE = 0 thru 1). . . . . . . 12
6.2.2. Messages (TYPE = 2 thru 10). . . . . . . . . . 13
7. TBRPF Neighbor Discovery. . . . . . . . . . . . . . . . . . . 13
7.1. HELLO Message Format . . . . . . . . . . . . . . . . . 13
7.2. Neighbor Table . . . . . . . . . . . . . . . . . . . . 14
7.3. Sending HELLO Messages . . . . . . . . . . . . . . . . 15
7.4. Processing a Received HELLO Message. . . . . . . . . . 16
7.5. Expiration of Timer nbr_life . . . . . . . . . . . . . 18
7.6. Link-Layer Failure Notification. . . . . . . . . . . . 18
7.7. Optional Link Metrics. . . . . . . . . . . . . . . . . 18
7.8. Configurable Parameters. . . . . . . . . . . . . . . . 19
8. TBRPF Routing Module. . . . . . . . . . . . . . . . . . . . . 19
8.1. Conceptual Data Structures . . . . . . . . . . . . . . 19
8.2. TOPOLOGY UPDATE Message Format . . . . . . . . . . . . 21
8.3. Interface, Host, and Network Prefix Association
Message Formats. . . . . . . . . . . . . . . . . . . . 23
8.4. TBRPF Routing Operation. . . . . . . . . . . . . . . . 24
8.4.1. Periodic Processing. . . . . . . . . . . . . . 24
8.4.2. Updating the Source Tree and Topology
Graph. . . . . . . . . . . . . . . . . . . . . 25
8.4.3. Updating the Routing Table . . . . . . . . . . 26
8.4.4. Updating the Reported Node Set . . . . . . . . 27
8.4.5. Generating Periodic Updates. . . . . . . . . . 29
8.4.6. Generating Differential Updates. . . . . . . . 29
8.4.7. Processing Topology Updates. . . . . . . . . . 30
8.4.8. Expiring Topology Information. . . . . . . . . 32
8.4.9. Optional Reporting of Redundant Topology
Information. . . . . . . . . . . . . . . . . . 32
8.4.10. Local Topology Changes . . . . . . . . . . . . 33
8.4.11. Generating Association Messages. . . . . . . . 34
8.4.12. Processing Association Messages. . . . . . . . 36
8.4.13. Non-Relay Operation. . . . . . . . . . . . . . 37
8.5. Configurable Parameters. . . . . . . . . . . . . . . . 38
9. TBRPF Flooding Mechanism. . . . . . . . . . . . . . . . . . . 38
10. Operation of TBRPF in Mobile Ad-Hoc Networks. . . . . . . . . 39
10.1. Data Link Layer Assumptions. . . . . . . . . . . . . . 39
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Applicability Section . . . . . . . . . . . . . . . . . . . . 5 5. TBRPF Overview. . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Overview of Neighbor Discovery . . . . . . . . . . . . 6 5.2. Overview of the Routing Module. .. . . . . . . . . . . 8 6. TBRPF Packets . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. TBRPF Packet Header. . . . . . . . . . . . . . . . . . 10 6.2. TBRPF Packet Body. . . . . . . . . . . . . . . . . . . 11 6.2.1. Padding Options (TYPE = 0 thru 1). . . . . . . 12 6.2.2. Messages (TYPE = 2 thru 10). . . . . . . . . . 13 7. TBRPF Neighbor Discovery. . . . . . . . . . . . . . . . . . . 13 7.1. HELLO Message Format . . . . . . . . . . . . . . . . . 13 7.2. Neighbor Table . . . . . . . . . . . . . . . . . . . . 14 7.3. Sending HELLO Messages . . . . . . . . . . . . . . . . 15 7.4. Processing a Received HELLO Message. . . . . . . . . . 16 7.5. Expiration of Timer nbr_life . . . . . . . . . . . . . 18 7.6. Link-Layer Failure Notification. . . . . . . . . . . . 18 7.7. Optional Link Metrics. . . . . . . . . . . . . . . . . 18 7.8. Configurable Parameters. . . . . . . . . . . . . . . . 19 8. TBRPF Routing Module. . . . . . . . . . . . . . . . . . . . . 19 8.1. Conceptual Data Structures . . . . . . . . . . . . . . 19 8.2. TOPOLOGY UPDATE Message Format . . . . . . . . . . . . 21 8.3. Interface, Host, and Network Prefix Association Message Formats. . . . . . . . . . . . . . . . . . . . 23 8.4. TBRPF Routing Operation. . . . . . . . . . . . . . . . 24 8.4.1. Periodic Processing. . . . . . . . . . . . . . 24 8.4.2. Updating the Source Tree and Topology Graph. . . . . . . . . . . . . . . . . . . . . 25 8.4.3. Updating the Routing Table . . . . . . . . . . 26 8.4.4. Updating the Reported Node Set . . . . . . . . 27 8.4.5. Generating Periodic Updates. . . . . . . . . . 29 8.4.6. Generating Differential Updates. . . . . . . . 29 8.4.7. Processing Topology Updates. . . . . . . . . . 30 8.4.8. Expiring Topology Information. . . . . . . . . 32 8.4.9. Optional Reporting of Redundant Topology Information. . . . . . . . . . . . . . . . . . 32 8.4.10. Local Topology Changes . . . . . . . . . . . . 33 8.4.11. Generating Association Messages. . . . . . . . 34 8.4.12. Processing Association Messages. . . . . . . . 36 8.4.13. Non-Relay Operation. . . . . . . . . . . . . . 37 8.5. Configurable Parameters. . . . . . . . . . . . . . . . 38 9. TBRPF Flooding Mechanism. . . . . . . . . . . . . . . . . . . 38 10. Operation of TBRPF in Mobile Ad-Hoc Networks. . . . . . . . . 39 10.1. Data Link Layer Assumptions. . . . . . . . . . . . . . 39
Ogier, et al. Experimental [Page 2] RFC 3684 TBRPF February 2004
Ogier, et al. Experimental [Page 2] RFC 3684 TBRPF February 2004
10.2. Network Layer Assumptions. . . . . . . . . . . . . . . 39
10.3. Optional Automatic Address Resolution. . . . . . . . . 40
10.4. Support for Multiple Interfaces and/or
Alias Addresses. . . . . . . . . . . . . . . . . . . . 40
10.5. Support for Network Prefixes . . . . . . . . . . . . . 40
10.6. Support for non-MANET Hosts. . . . . . . . . . . . . . 40
10.7. Internet Protocol Considerations . . . . . . . . . . . 41
10.7.1. IPv4 Operation . . . . . . . . . . . . . . . . 41
10.7.2. IPv6 Operation . . . . . . . . . . . . . . . . 41
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
12. Security Considerations . . . . . . . . . . . . . . . . . . . 42
13. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 42
14. References. . . . . . . . . . . . . . . . . . . . . . . . . . 42
14.1. Normative References . . . . . . . . . . . . . . . . . 42
14.2. Informative References . . . . . . . . . . . . . . . . 43
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 45
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 46
10.2. Network Layer Assumptions. . . . . . . . . . . . . . . 39 10.3. Optional Automatic Address Resolution. . . . . . . . . 40 10.4. Support for Multiple Interfaces and/or Alias Addresses. . . . . . . . . . . . . . . . . . . . 40 10.5. Support for Network Prefixes . . . . . . . . . . . . . 40 10.6. Support for non-MANET Hosts. . . . . . . . . . . . . . 40 10.7. Internet Protocol Considerations . . . . . . . . . . . 41 10.7.1. IPv4 Operation . . . . . . . . . . . . . . . . 41 10.7.2. IPv6 Operation . . . . . . . . . . . . . . . . 41 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 12. Security Considerations . . . . . . . . . . . . . . . . . . . 42 13. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 42 14. References. . . . . . . . . . . . . . . . . . . . . . . . . . 42 14.1. Normative References . . . . . . . . . . . . . . . . . 42 14.2. Informative References . . . . . . . . . . . . . . . . 43 Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 45 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 46
1. Introduction
1. Introduction
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a proactive, link-state routing protocol designed for mobile ad-hoc networks (MANETs), which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree (providing shortest paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification of Dijkstra's algorithm. To minimize overhead, each node reports only *part* of its source tree to neighbors.
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a proactive, link-state routing protocol designed for mobile ad-hoc networks (MANETs), which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree (providing shortest paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification of Dijkstra's algorithm. To minimize overhead, each node reports only *part* of its source tree to neighbors.
TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report addition topology information (up to the full topology), to provide improved robustness in highly mobile networks.
TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report addition topology information (up to the full topology), to provide improved robustness in highly mobile networks.
TBRPF performs neighbor discovery using "differential" HELLO messages which report only *changes* in the status of neighbors. This results in HELLO messages that are much smaller than those of other link- state routing protocols such as OSPF [6].
TBRPF performs neighbor discovery using "differential" HELLO messages which report only *changes* in the status of neighbors. This results in HELLO messages that are much smaller than those of other link- state routing protocols such as OSPF [6].
TBRPF consists of two modules: the neighbor discovery module and the routing module (which performs topology discovery and route computation). An overview of these modules is given in Section 5.
TBRPF consists of two modules: the neighbor discovery module and the routing module (which performs topology discovery and route computation). An overview of these modules is given in Section 5.
Ogier, et al. Experimental [Page 3] RFC 3684 TBRPF February 2004
Ogier, et al. Experimental [Page 3] RFC 3684 TBRPF February 2004
2. Requirements
2. Requirements
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", when they appear in this document, are to be interpreted as described in BCP 14, RFC 2119 [1].
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", when they appear in this document, are to be interpreted as described in BCP 14, RFC 2119 [1].
This document also makes use of internal conceptual variables to describe protocol behavior and external variables that an implementation must allow system administrators to change. The specific variable names, how their values change, and how their settings influence protocol behavior are provided to demonstrate protocol behavior. An implementation is not required to have them in the exact form described here, so long as its external behavior is consistent with that described in this document.
This document also makes use of internal conceptual variables to describe protocol behavior and external variables that an implementation must allow system administrators to change. The specific variable names, how their values change, and how their settings influence protocol behavior are provided to demonstrate protocol behavior. An implementation is not required to have them in the exact form described here, so long as its external behavior is consistent with that described in this document.
3. Terminology
3. Terminology
The following terms are used to describe TBRPF:
The following terms are used to describe TBRPF:
node
A router that implements TBRPF.
node A router that implements TBRPF.
router ID
Each node is identified by a unique 32-bit router ID (RID), which
for IPv4 is typically equal to the IP address of one of its
interfaces. The term "node u" denotes the node whose RID is equal
to u.
router ID Each node is identified by a unique 32-bit router ID (RID), which for IPv4 is typically equal to the IP address of one of its interfaces. The term "node u" denotes the node whose RID is equal to u.
interface
A node's attachment to a communication facility or medium through
which it can communicate with other nodes. A node can have
multiple interfaces. An interface can be wireless or wired, and
can be broadcast (e.g., Ethernet) or point-to-point. Each
interface is identified by its IP address. The term "interface I"
denotes the interface whose IP address is I.
interface A node's attachment to a communication facility or medium through which it can communicate with other nodes. A node can have multiple interfaces. An interface can be wireless or wired, and can be broadcast (e.g., Ethernet) or point-to-point. Each interface is identified by its IP address. The term "interface I" denotes the interface whose IP address is I.
link
A link is an ordered pair of interfaces (I,J) where I and J are on
two different nodes, and where interface I has recently received
packets sent from interface J. A link (i,j) from node i to node j
is said to exist if node i has an interface I and node j has an
interface J such that (I,J) is a link. Nodes i and j are called
the "tail" and "head" of the link, respectively.
link A link is an ordered pair of interfaces (I,J) where I and J are on two different nodes, and where interface I has recently received packets sent from interface J. A link (i,j) from node i to node j is said to exist if node i has an interface I and node j has an interface J such that (I,J) is a link. Nodes i and j are called the "tail" and "head" of the link, respectively.
bidirectional link
A link (I,J) such that interfaces I and J can both hear each
other. Also called a 2-way link.
bidirectional link A link (I,J) such that interfaces I and J can both hear each other. Also called a 2-way link.
Ogier, et al. Experimental [Page 4] RFC 3684 TBRPF February 2004
Ogier, et al. Experimental [Page 4] RFC 3684 TBRPF February 2004
neighbor node
A node j is said to be a neighbor of node i if node i can hear
node j on some interface. Node j is said to be a 2-way neighbor
if there is a bidirectional link between i and j.
neighbor node A node j is said to be a neighbor of node i if node i can hear node j on some interface. Node j is said to be a 2-way neighbor if there is a bidirectional link between i and j.
MANET interface
Any wireless interface such that two neighbor nodes on the
interface need not be neighbors of each other. MANET nodes
typically have at least one MANET interface, but this is not a
requirement.
MANET interface Any wireless interface such that two neighbor nodes on the interface need not be neighbors of each other. MANET nodes typically have at least one MANET interface, but this is not a requirement.
topology
The topology of the network is described by a graph G = (V, E),
where V is the set of nodes u and E is the set of links (u,v) in
the network.
topology The topology of the network is described by a graph G = (V, E), where V is the set of nodes u and E is the set of links (u,v) in the network.
source tree
The directed tree (denoted T) computed by each node that provides
shortest paths to all other reachable nodes.
source tree The directed tree (denoted T) computed by each node that provides shortest paths to all other reachable nodes.
topology update
A message that reports the state of one or more links.
topology update A message that reports the state of one or more links.
parent
The parent of node i for node u is the next node on the computed
shortest path from node i to node u.
parent The parent of node i for node u is the next node on the computed shortest path from node i to node u.
predecessor
The predecessor of a node v on the source tree is the node u such
that the link (u,v) is in the source tree.
predecessor The predecessor of a node v on the source tree is the node u such that the link (u,v) is in the source tree.
leaf node
A leaf node of the source tree is a node on the source tree that
is not the predecessor of any other node on the source tree.
leaf node A leaf node of the source tree is a node on the source tree that is not the predecessor of any other node on the source tree.
proactive routing protocol
A routing protocol in which each node maintains routes to all
reachable destinations at all times, whether or not there is
currently any need to deliver packets to those destinations. In
contrast, an "on-demand" routing protocol discovers and maintains
routes only when they are needed.
proactive routing protocol A routing protocol in which each node maintains routes to all reachable destinations at all times, whether or not there is currently any need to deliver packets to those destinations. In contrast, an "on-demand" routing protocol discovers and maintains routes only when they are needed.
4. Applicability Section
4. Applicability Section
TBRPF is a proactive routing protocol designed for mobile ad-hoc networks (MANETs). It can support networks with up to a few hundred nodes, and can be combined with hierarchical routing techniques to support much larger networks. Because it employs techniques to
TBRPF is a proactive routing protocol designed for mobile ad-hoc networks (MANETs). It can support networks with up to a few hundred nodes, and can be combined with hierarchical routing techniques to support much larger networks. Because it employs techniques to
Ogier, et al. Experimental [Page 5] RFC 3684 TBRPF February 2004
Ogier, et al. Experimental [Page 5] RFC 3684 TBRPF February 2004
greatly reduce control traffic, TBRPF can support much larger and denser networks than routing protocols based on the classical link- state algorithm (e.g., OSPF).
greatly reduce control traffic, TBRPF can support much larger and denser networks than routing protocols based on the classical link- state algorithm (e.g., OSPF).
The number of nodes that can be supported depends on several factors, including the MAC data rate, the rate of topology changes, and the network density (average number of neighbors). Simulations have been reported in which TBRPF has supported as many as 500 nodes. In simulations with 100 nodes and 20 traffic streams (sources), using IEEE 802.11 with a data rate of 2 Mbps, TBRPF was found to generate approximately 80-120 kb/s of routing control traffic for the scenarios considered, which compared favorably with other MANET routing protocols [7][8]. A proof of correctness for TBRPF can be found in references [8] and [9].
The number of nodes that can be supported depends on several factors, including the MAC data rate, the rate of topology changes, and the network density (average number of neighbors). Simulations have been reported in which TBRPF has supported as many as 500 nodes. In simulations with 100 nodes and 20 traffic streams (sources), using IEEE 802.11 with a data rate of 2 Mbps, TBRPF was found to generate approximately 80-120 kb/s of routing control traffic for the scenarios considered, which compared favorably with other MANET routing protocols [7][8]. A proof of correctness for TBRPF can be found in references [8] and [9].
5. TBRPF Overview
5. TBRPF Overview
TBRPF consists of two main modules: the neighbor discovery module, and the routing module (which performs topology discovery and route computation).
TBRPF consists of two main modules: the neighbor discovery module, and the routing module (which performs topology discovery and route computation).
5.1. Overview of Neighbor Discovery
5.1. Overview of Neighbor Discovery
The TBRPF Neighbor Discovery (TND) protocol allows each node i to quickly detect the neighbor nodes j such that a bidirectional link (I,J) exists between an interface I of node i and an interface J of node j. The protocol also quickly detects when a bidirectional link breaks or becomes unidirectional.
The TBRPF Neighbor Discovery (TND) protocol allows each node i to quickly detect the neighbor nodes j such that a bidirectional link (I,J) exists between an interface I of node i and an interface J of node j. The protocol also quickly detects when a bidirectional link breaks or becomes unidirectional.
The key feature of TND is that it uses "differential" HELLO messages which report only *changes* in the status of links. This results in HELLO messages that are much smaller than those of other link-state routing protocols such as OSPF, in which each HELLO message includes the IDs of *all* neighbors. As a result, HELLO messages can be sent more frequently, which allows faster detection of topology changes.
The key feature of TND is that it uses "differential" HELLO messages which report only *changes* in the status of links. This results in HELLO messages that are much smaller than those of other link-state routing protocols such as OSPF, in which each HELLO message includes the IDs of *all* neighbors. As a result, HELLO messages can be sent more frequently, which allows faster detection of topology changes.
TND is designed to be fully modular and independent of the routing module. TND performs ONLY neighbor sensing, i.e., it determines which nodes are (1-hop) neighbors. In particular, it does not discover 2-hop neighbors (which is handled by the routing module). As a result, TND can be used by other routing protocols, and TBRPF can use another neighbor discovery protocol in place of TND, e.g., one provided by the link layer.
TND is designed to be fully modular and independent of the routing module. TND performs ONLY neighbor sensing, i.e., it determines which nodes are (1-hop) neighbors. In particular, it does not discover 2-hop neighbors (which is handled by the routing module). As a result, TND can be used by other routing protocols, and TBRPF can use another neighbor discovery protocol in place of TND, e.g., one provided by the link layer.
Nodes with multiple interfaces run TND separately on each interface, similar to OSPF. Thus, a neighbor table is maintained for each local interface, and a HELLO sent on a particular interface contains only information regarding neighbors heard on that interface.
Nodes with multiple interfaces run TND separately on each interface, similar to OSPF. Thus, a neighbor table is maintained for each local interface, and a HELLO sent on a particular interface contains only information regarding neighbors heard on that interface.
Ogier, et al. Experimental [Page 6] RFC 3684 TBRPF February 2004
Ogier, et al. Experimental [Page 6] RFC 3684 TBRPF February 2004
We note that, in wireless networks, it is possible for a single interface I to receive packets from multiple interfaces J associated with the same neighbor node. This could happen, for example, if the neighbor uses a directional antenna with different interfaces representing different beams. For this reason, TBRPF includes neighbor interface addresses in HELLO messages, unlike OSPF, which includes only router IDs in HELLO packets.
We note that, in wireless networks, it is possible for a single interface I to receive packets from multiple interfaces J associated with the same neighbor node. This could happen, for example, if the neighbor uses a directional antenna with different interfaces representing different beams. For this reason, TBRPF includes neighbor interface addresses in HELLO messages, unlike OSPF, which includes only router IDs in HELLO packets.
Each TBRPF node maintains a neighbor table for each local interface I, which stores state information for each neighbor interface J heard on that interface, i.e., for each link (I,J) between interface I and a neighbor interface J. The status of each link can be 1-WAY, 2-WAY, or LOST. The neighbor table for interface I determines the contents of HELLO messages sent on interface I, and is updated based on HELLO messages received on interface I (and possibly on link-layer notifications).
Each TBRPF node maintains a neighbor table for each local interface I, which stores state information for each neighbor interface J heard on that interface, i.e., for each link (I,J) between interface I and a neighbor interface J. The status of each link can be 1-WAY, 2-WAY, or LOST. The neighbor table for interface I determines the contents of HELLO messages sent on interface I, and is updated based on HELLO messages received on interface I (and possibly on link-layer notifications).
Each TBRPF node sends (on each interface) at least one HELLO message per HELLO_INTERVAL. Each HELLO message contains three (possibly empty) lists of neighbor interface addresses (which are formatted as three message subtypes): NEIGHBOR REQUEST, NEIGHBOR REPLY, and NEIGHBOR LOST. Each HELLO message also contains the current HELLO sequence number (HSEQ), which is incremented with each transmitted HELLO.
Each TBRPF node sends (on each interface) at least one HELLO message per HELLO_INTERVAL. Each HELLO message contains three (possibly empty) lists of neighbor interface addresses (which are formatted as three message subtypes): NEIGHBOR REQUEST, NEIGHBOR REPLY, and NEIGHBOR LOST. Each HELLO message also contains the current HELLO sequence number (HSEQ), which is incremented with each transmitted HELLO.
In the following overview of the operation of TND, we assume that interface I belongs to node i, and interface J belongs to node j. When a node i changes the status of a link (I,J), it includes the neighbor interface address J in the appropriate list (NEIGHBOR REQUEST/REPLY/LOST) in at most NBR_HOLD_COUNT (typically 3) consecutive HELLOs sent on interface I. This ensures that node j will either receive one of these HELLOs on interface J, or will miss NBR_HOLD_COUNT HELLOs and thus declare the link (J,I) to be LOST. This technique makes it unnecessary for a node to include each 1-WAY or 2-WAY neighbor in HELLOs indefinitely, unlike OSPF.
In the following overview of the operation of TND, we assume that interface I belongs to node i, and interface J belongs to node j. When a node i changes the status of a link (I,J), it includes the neighbor interface address J in the appropriate list (NEIGHBOR REQUEST/REPLY/LOST) in at most NBR_HOLD_COUNT (typically 3) consecutive HELLOs sent on interface I. This ensures that node j will either receive one of these HELLOs on interface J, or will miss NBR_HOLD_COUNT HELLOs and thus declare the link (J,I) to be LOST. This technique makes it unnecessary for a node to include each 1-WAY or 2-WAY neighbor in HELLOs indefinitely, unlike OSPF.
To avoid establishing a link that is likely to be short lived (i.e., to employ hysteresis), node i must receive (on interface I) at least HELLO_ACQUIRE_COUNT (e.g., 2) of the last HELLO_ACQUIRE_WINDOW (e.g., 3) HELLOs sent from a neighbor interface J, before declaring the link (I,J) to be 1-WAY. When this happens, node i includes J in the NEIGHBOR REQUEST list in each of its next NBR_HOLD_COUNT HELLO messages sent on interface I, or until a NEIGHBOR REPLY message containing I is received on interface I from neighbor interface J.
To avoid establishing a link that is likely to be short lived (i.e., to employ hysteresis), node i must receive (on interface I) at least HELLO_ACQUIRE_COUNT (e.g., 2) of the last HELLO_ACQUIRE_WINDOW (e.g., 3) HELLOs sent from a neighbor interface J, before declaring the link (I,J) to be 1-WAY. When this happens, node i includes J in the NEIGHBOR REQUEST list in each of its next NBR_HOLD_COUNT HELLO messages sent on interface I, or until a NEIGHBOR REPLY message containing I is received on interface I from neighbor interface J.
If node j receives (on interface J) one of the HELLOs sent from interface I that contains J in the NEIGHBOR REQUEST list, then node j declares the link (J,I) to be 2-WAY (unless it is already 2-WAY), and
If node j receives (on interface J) one of the HELLOs sent from interface I that contains J in the NEIGHBOR REQUEST list, then node j declares the link (J,I) to be 2-WAY (unless it is already 2-WAY), and
Ogier, et al. Experimental [Page 7] RFC 3684 TBRPF February 2004
Ogier, et al. Experimental [Page 7] RFC 3684 TBRPF February 2004
includes I in the NEIGHBOR REPLY list in each of its next NBR_HOLD_COUNT HELLO messages sent on interface J. Upon receiving one of these HELLOs on interface I, node i declares the link (I,J) to be 2-WAY.
includes I in the NEIGHBOR REPLY list in each of its next NBR_HOLD_COUNT HELLO messages sent on interface J. Upon receiving one of these HELLOs on interface I, node i declares the link (I,J) to be 2-WAY.
If node i receives a HELLO on interface I, sent from neighbor interface J, whose HSEQ indicates that at least NBR_HOLD_COUNT HELLOs were missed, or if node i receives no HELLO on interface I sent from interface J within NBR_HOLD_TIME seconds, then node i changes the status of link (I,J) to LOST (unless it is already LOST), and includes J in the NEIGHBOR LOST list in each of its next NBR_HOLD_COUNT HELLO messages sent on interface I (unless the link changes status before these transmissions are complete). Node j will either receive one of these HELLOs on interface J or will miss NBR_HOLD_COUNT HELLOs; in either case, node j will declare the link (J,I) to be LOST. In this manner, both nodes will agree that the link between I and J is no longer bidirectional, even if node j can still hear HELLOs from node i.
If node i receives a HELLO on interface I, sent from neighbor interface J, whose HSEQ indicates that at least NBR_HOLD_COUNT HELLOs were missed, or if node i receives no HELLO on interface I sent from interface J within NBR_HOLD_TIME seconds, then node i changes the status of link (I,J) to LOST (unless it is already LOST), and includes J in the NEIGHBOR LOST list in each of its next NBR_HOLD_COUNT HELLO messages sent on interface I (unless the link changes status before these transmissions are complete). Node j will either receive one of these HELLOs on interface J or will miss NBR_HOLD_COUNT HELLOs; in either case, node j will declare the link (J,I) to be LOST. In this manner, both nodes will agree that the link between I and J is no longer bidirectional, even if node j can still hear HELLOs from node i.
Each node may maintain and update one or more link metrics for each link (I,J) from a local interface I to a neighbor interface J, representing the quality of the link. Such link metrics can be used as additional conditions for changing the status of a neighbor, based on the link metric going above or below some threshold. TBRPF also allows link metrics to be advertised in topology updates, and to be used for computing shortest paths.
Each node may maintain and update one or more link metrics for each link (I,J) from a local interface I to a neighbor interface J, representing the quality of the link. Such link metrics can be used as additional conditions for changing the status of a neighbor, based on the link metric going above or below some threshold. TBRPF also allows link metrics to be advertised in topology updates, and to be used for computing shortest paths.
5.2. Overview of the Routing Module
5.2. Overview of the Routing Module
Each node running TBRPF maintains a source tree, denoted T, which provides shortest paths to all reachable nodes. Each node computes and updates its source tree based on partial topology information stored in its topology table, using a modification of Dijkstra's algorithm. To minimize overhead, each node reports only part of its source tree to neighbors. The main idea behind the current version of TBRPF came from PTSP [10], another protocol in which each node reports only part of its source tree. (However, TBRPF differs from PTSP in several ways.) The current version of TBRPF should not be confused with its previous version [11], which is a full-topology routing protocol.
Each node running TBRPF maintains a source tree, denoted T, which provides shortest paths to all reachable nodes. Each node computes and updates its source tree based on partial topology information stored in its topology table, using a modification of Dijkstra's algorithm. To minimize overhead, each node reports only part of its source tree to neighbors. The main idea behind the current version of TBRPF came from PTSP [10], another protocol in which each node reports only part of its source tree. (However, TBRPF differs from PTSP in several ways.) The current version of TBRPF should not be confused with its previous version [11], which is a full-topology routing protocol.
The part of T that a node reports to neighbors is called the "reported subtree" and is denoted RT. Each node reports RT to neighbors in *periodic* topology updates (e.g., every 5 seconds), and reports changes (additions and deletions) to RT in more frequent *differential* updates (e.g., every 1 second). Periodic updates inform new neighbors of RT, and ensure that each neighbor eventually learns RT even if it does not receive all updates. Differential
The part of T that a node reports to neighbors is called the "reported subtree" and is denoted RT. Each node reports RT to neighbors in *periodic* topology updates (e.g., every 5 seconds), and reports changes (additions and deletions) to RT in more frequent *differential* updates (e.g., every 1 second). Periodic updates inform new neighbors of RT, and ensure that each neighbor eventually learns RT even if it does not receive all updates. Differential
Ogier, et al. Experimental [Page 8] RFC 3684 TBRPF February 2004
Ogier, et al. Experimental [Page 8] RFC 3684 TBRPF February 2004
updates ensure the fast propagation of each topology update to all nodes that are affected by the update. A received topology update is not forwarded, but *may* result in a change to RT, which will be reported in the next differential or periodic update. Whenever possible, topology updates are included in the same packet as a HELLO message, to minimize the number of control packets sent. TBRPF does not require reliable or sequenced delivery of messages, and does not use ACKs or NACKs.
updates ensure the fast propagation of each topology update to all nodes that are affected by the update. A received topology update is not forwarded, but *may* result in a change to RT, which will be reported in the next differential or periodic update. Whenever possible, topology updates are included in the same packet as a HELLO message, to minimize the number of control packets sent. TBRPF does not require reliable or sequenced delivery of messages, and does not use ACKs or NACKs.
TBRPF supports multiple interfaces, associated hosts, and network prefixes. Information regarding associated interfaces, hosts, and prefixes is disseminated efficiently in periodic and differential updates, similar to the dissemination of topology updates.
TBRPF supports multiple interfaces, associated hosts, and network prefixes. Information regarding associated interfaces, hosts, and prefixes is disseminated efficiently in periodic and differential updates, similar to the dissemination of topology updates.
The reported subtree RT consists of links (u,v) of T such that u is in the "reported node set" RN, which is computed as follows. Node i includes a neighbor j in RN if and only if node i determines that one of its neighbors may select i to be its next hop on its shortest path to j. To make this determination, node i computes the shortest paths, up to 2 hops, from each neighbor to each other neighbor, using only neighbors (or node i itself) as an intermediate node, and using relay priority (included in HELLO messages) and router ID to break ties. After a node determines which neighbors are in RN, each reachable node u is included in RN if and only if the next hop on the shortest path to u is in RN. A node also includes itself in RN. As a result, the reported subtree RT includes the subtrees of T that are rooted at neighbors in RN, and also includes all local links to neighbors.
The reported subtree RT consists of links (u,v) of T such that u is in the "reported node set" RN, which is computed as follows. Node i includes a neighbor j in RN if and only if node i determines that one of its neighbors may select i to be its next hop on its shortest path to j. To make this determination, node i computes the shortest paths, up to 2 hops, from each neighbor to each other neighbor, using only neighbors (or node i itself) as an intermediate node, and using relay priority (included in HELLO messages) and router ID to break ties. After a node determines which neighbors are in RN, each reachable node u is included in RN if and only if the next hop on the shortest path to u is in RN. A node also includes itself in RN. As a result, the reported subtree RT includes the subtrees of T that are rooted at neighbors in RN, and also includes all local links to neighbors.
We note that neighbors in RN are analogous to multipoint relay (MPR) selectors [12]. Thus, if node i selects neighbor j to be in RN, then node i effectively selects itself to be an MPR of node j. This is quite different from [12], in which a node does not select itself to be an MPR, but selects a subset of its neighbors to be MPRs.
We note that neighbors in RN are analogous to multipoint relay (MPR) selectors [12]. Thus, if node i selects neighbor j to be in RN, then node i effectively selects itself to be an MPR of node j. This is quite different from [12], in which a node does not select itself to be an MPR, but selects a subset of its neighbors to be MPRs.
A node with a larger relay priority reports a larger part of its source tree (on average), and is more likely to be selected as a next-hop relay by its neighbors. A node with relay priority equal to 0 is called a non-relay node, and never forwards packets originating from other nodes.
A node with a larger relay priority reports a larger part of its source tree (on average), and is more likely to be selected as a next-hop relay by its neighbors. A node with relay priority equal to 0 is called a non-relay node, and never forwards packets originating from other nodes.
TBRPF does not use sequence numbers for topology updates, thus reducing message overhead and avoiding wraparound problems. Instead, a technique similar to SPTA [13] is used in which, for each link (u,v) reported by one or more neighbors, only the next hop p(u) to u is believed regarding the state of the link. (However, in SPTA each node reports the full topology.) Using this technique, each node maintains a topology graph TG, consisting of links that are believed
TBRPF does not use sequence numbers for topology updates, thus reducing message overhead and avoiding wraparound problems. Instead, a technique similar to SPTA [13] is used in which, for each link (u,v) reported by one or more neighbors, only the next hop p(u) to u is believed regarding the state of the link. (However, in SPTA each node reports the full topology.) Using this technique, each node maintains a topology graph TG, consisting of links that are believed
Ogier, et al. Experimental [Page 9] RFC 3684 TBRPF February 2004
Ogier, et al. Experimental [Page 9] RFC 3684 TBRPF February 2004
to be up, and computes T as the shortest-path tree within TG. To allow immediate rerouting, the restriction that each link (u,v) in TG must be reported by p(u) is relaxed temporarily if p(u) changes to a neighbor that is not reporting the link.
to be up, and computes T as the shortest-path tree within TG. To allow immediate rerouting, the restriction that each link (u,v) in TG must be reported by p(u) is relaxed temporarily if p(u) changes to a neighbor that is not reporting the link.
Each node is required to report RT, but may report additional links, e.g., to provide increased robustness in highly mobile networks. More precisely, a node may maintain any subgraph H of TG that contains T, and report the reported subgraph RH, which consists of links (u,v) of H such that u is in RN. For example, H can equal TG, which would provide each node with the full network topology if this is done by all nodes. H can also be a biconnected subgraph that contains T, which would provide each node with two disjoint paths to each other node, if this is done by all nodes.
例えば非常に可動のネットワークに増加する丈夫さを提供するために追加リンクを報告するかもしれないのを除いて、各ノードが、RTを報告するのに必要です。 ノードが、より正確に、Tを含むTGのどんな部分グラフHも維持して、報告された部分グラフRHを報告するかもしれないので、uがRNにあります。(RHはHのリンク(u、v)から成ります)。 例えば、HはTGと等しいことができます。(すべてのノードでこれをするなら、TGは完全なネットワーク形態を各ノードに提供するでしょう)。 また、HがTを含むbiconnected部分グラフであるかもしれない、どれが各ノードに2を提供するだろうかが経路を互いにばらばらにならせます。ノードすべてのノードでこれをするなら。
TBRPF allows the option to include link metrics in topology updates, and to compute paths that are shortest with respect to the metric. This allows packets to be sent along paths that are higher quality than minimum-hop paths.
TBRPFはオプションにトポロジーアップデートにリンク測定基準を含んで、メートル法に関して最も短い経路を計算させます。 これは、パケットが最小のホップ経路より高い品質である経路に沿って送られるのを許容します。
TBRPF allows path optimality to be traded off in order to reduce the amount of control traffic in networks with a large diameter, where the degree of approximation is determined by the configurable parameter NON_TREE_PENALTY.
TBRPFは、大きい直径があるネットワークのコントロール交通の量を減少させるために経路の最適が交換されるのを許容します。そこでは、近似の度合いが構成可能なパラメタNON_TREE_PENALTYによって決定されます。
6. TBRPF Packets
6. TBRPFパケット
Nodes send TBRPF protocol data in contiguous units known as packets. Each packet includes a header, optional header extensions, and a body comprising one or more messages and padding options as needed. To facilitate efficient receiver processing, senders SHOULD insert padding options as necessary to align multi-octet words within the TBRPF packet on natural boundaries (i.e., modulo-8/4/2 addresses for 64/32/16-bit words, respectively). Receivers MUST be capable of processing multi-octet words whether or not aligned on natural boundaries. The following sections specify elements of the TBRPF packet in more detail.
ノードはパケットとして知られている隣接のユニットのプロトコルデータをTBRPFに送ります。 各パケットは1つ以上のメッセージを包括して、必要に応じてオプションを水増しするヘッダー、任意のヘッダー拡大、およびボディーを含んでいます。 効率的な受信機処理を容易にするなら、送付者SHOULDは、固有の境界(すなわち、それぞれ8/4/2が64/32/16ビットの単語のために記述する法)のTBRPFパケットの中でマルチ八重奏単語を並べるために必要に応じて詰め物オプションを挿入します。 固有の境界で並べられるか否かに関係なく、受信機は処理マルチ八重奏単語ができなければなりません。 以下のセクションはさらに詳細にTBRPFパケットの要素を指定します。
6.1. TBRPF Packet Header
6.1. TBRPFパケットのヘッダー
TBRPF packet headers are variable-length (minimum one octet). The format for the packet header is as follows:
TBRPFパケットのヘッダーは可変長です(最小の1つの八重奏)。 パケットのヘッダーのための形式は以下の通りです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers |L|I|R|R| Reserved | Header Extensions ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers|L|I|R|R| 予約されます。| ヘッダー拡大… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ogier, et al. Experimental [Page 10] RFC 3684 TBRPF February 2004
オジェ、他 [10ページ]実験的なRFC3684TBRPF2004年2月
Version (4 bits)
The TBRPF version number. This specification documents version 4
of the protocol.
TBRPFバージョンが付番するバージョン(4ビット)。 この仕様はプロトコルのバージョン4を記録します。
Flags (4 bits)
Two bits (L,I) specify which header extensions (if any) follow.
Two bits (R) are reserved for future use, and MUST be zero. Any
extensions specified by these bits MUST appear in the same order
as the bits (i.e., first L, then I) as follows:
旗(4ビット)2ビット(L、I)は、どのヘッダー拡大(もしあれば)が続くかを指定します。 2ビット(R)は、今後の使用のために予約されて、ゼロであるに違いありません。 これらのビットによって指定されたどんな拡大も以下のビット(次に、すなわち、最初に、L、I)として同次に現れなければなりません:
L - Length included
If the underlying delivery service provides a length field, the
sender MAY set L = '0' and omit the length extension. Otherwise,
the sender MUST set L = '1' and include a 16-bit unsigned integer
length immediately after any previous header field. The length
includes all header and data bytes and is written into the length
field in network byte order.
L--基本的なデリバリ・サービスが長さの野原を供給する長さの含まれているIf、送付者はL='0'を設定して、長さの拡大を省略するかもしれません。 さもなければ、送付者は、どんな前のヘッダーフィールド直後L='1'を設定して、16ビットの符号のない整数の長さを入れなければなりません。 長さは、すべてのヘッダーとデータ・バイトを含めて、ネットワークバイトオーダーで長さの分野に書かれています。
Receivers examine the L bit to determine whether the length field
is present. If L = '1', the receiver reads the length field to
determine the length of the TBRPF packet, including the TBRPF
packet header. Receivers discard any TBRPF packet if neither the
underlying delivery service nor the TBRPF packet header provide
packet length.
受信機は、長さの分野が存在しているかどうか決定するためにLビットを調べます。 L='1'であるなら、受信機はTBRPFパケットの長さを測定するために長さの分野を読みます、TBRPFパケットのヘッダーを含んでいて。 基本的なデリバリ・サービスもTBRPFパケットのヘッダーもパケット長を提供しないなら、受信機はどんなTBRPFパケットも捨てます。
I - Router ID (RID) included
If the underlying delivery service encodes the sender's RID, the
sender MAY set I = '0' and omit the RID field. Otherwise, the
sender MUST set I = '1' and include a 4-octet RID in network byte
order immediately after any previous header fields. The RID
option provides a mechanism for implicit network-level address
resolution. A receiver that detects a RID option SHOULD create a
binding between the RID and the source address that appears in the
network-level header.
私--ルータID基礎となる(RID)含まれているIfデリバリ・サービスが送付者のRIDをコード化して、送付者は、私='0'を設定して、RID分野を省略するかもしれません。 さもなければ、送付者は、どんな前のヘッダーフィールド直後私='1'を設定して、ネットワークバイトオーダーで4八重奏のRIDを入れなければなりません。 RIDオプションは暗黙のネットワークレベルアドレス解決にメカニズムを提供します。 SHOULDが結合を作成するRIDとソースが記述するネットワークレベルヘッダーに現れるRIDオプションを検出する受信機。
Reserved
Reserved for future use; MUST be zero.
今後の使用のための予約されたReserved。 ゼロにならなければならなくなってください。
6.2. TBRPF Packet Body
6.2. TBRPFパケットボディー
The TBRPF packet body consists of the concatenation of one or more TBRPF messages (and padding options where necessary). Messages and padding options within the TBRPF packet body are encoded using the following format:
TBRPFパケットボディーは1つ以上のTBRPFメッセージの連結から成ります(必要であるところでオプションを水増しして)。 メッセージとTBRPFパケットボディーの中でオプションを水増しするのは以下の形式を使用することでコード化されます:
+-+-+-+-+-+-+-+-+- - - - - |OPTIONS| TYPE | VALUE +-+-+-+-+-+-+-+-+- - - - -
+-+-+-+-+-+-+-+-+- - - - - |オプション| タイプ| 値+++++++++、-、--、--、--、-
Ogier, et al. Experimental [Page 11] RFC 3684 TBRPF February 2004
オジェ、他 [11ページ]実験的なRFC3684TBRPF2004年2月
OPTIONS (4 bits)
Four option bits that depend on TYPE.
TYPEに依存する4OPTIONS(4ビット)オプションビット。
TYPE (4 bits)
Identifier for message type or padding option.
メッセージタイプかオプションを水増しするためのTYPE(4ビット)識別子。
VALUE
Variable-length field. (Format and length depend on TYPE, as
described in the following sections.)
VALUE Variable-長さの分野。 (形式と長さを以下のセクションで説明されるようにTYPEに依存します。)
The sequence of elements MUST be processed strictly in the order they appear within the TBRPF packet body; a receiver must not, for example, scan through the packet body looking for a particular type of element prior to processing all preceding elements [2]. TBRPF packet elements include padding options and messages as described below.
それらがTBRPFパケットボディーの中で見えるオーダーで厳密に要素の系列を処理しなければなりません。 例えば、受信機は、すべての前の要素[2]を処理する前に特定のタイプの要素を探しながら、パケットボディーを通してスキャンされてはいけません。 TBRPFパケット要素は、以下で説明されるようにオプションとメッセージを水増しするのを含んでいます。
6.2.1. Padding Options (TYPE = 0 thru 1)
6.2.1. オプションを水増しします。(0〜TYPE=1)
Senders MAY insert two types of padding options where necessary, e.g., to satisfy alignment requirements for other elements [2]. Padding options may occur anywhere within the TBRPF packet body. The following two padding options are defined:
Sendersは例えば他の要素[2]のための整列要求を満たすために必要であるところでオプションを水増しする2つのタイプを挿入するかもしれません。 オプションを水増しするのはTBRPFパケットボディーの中でどこでも起こるかもしれません。 以下の2つの詰め物オプションが定義されます:
Pad1 option (TYPE = 0)
Pad1オプション(タイプ=0)
+-+-+-+-+-+-+-+-+ | 0 | 0 | +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ | 0 | 0 | +-+-+-+-+-+-+-+-+
The Pad1 option inserts one octet of padding into the TBRPF packet body; the VALUE field is omitted. If more than one octet of padding is required, the PadN option (described next) should be used, rather than multiple Pad1 options.
Pad1オプションはTBRPFパケットボディーにそっと歩く1つの八重奏を挿入します。 VALUE分野は省略されます。 詰め物の1つ以上の八重奏が必要であるなら、PadNオプション(次に、説明される)は複数のPad1オプションよりむしろ使用されるべきです。
PadN option (TYPE = 1)
PadNオプション(タイプ=1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - | 0 | 1 | LEN | Zero-valued Octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - -
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - | 0 | 1 | レン| 無貴重な八重奏+++++++++++++++++、-、--、--、--、--、--、--、--、--、--、-
The PadN option inserts two or more octets of padding into the TBRPF packet body. The first octet of the VALUE field contains an 8-bit unsigned integer length containing a value between 0 - 253 which specifies the number of zero-valued octets that immediately follow, yielding a maximum total of 255 padding octets.
PadNオプションはTBRPFパケットボディーにそっと歩く2つ以上の八重奏を挿入します。 VALUE分野の最初の八重奏はすぐに続く無評価された八重奏の数を指定する0--253の間に値を含む8ビットの符号のない整数の長さを含んでいます、八重奏を水増しする255の最大の合計をもたらして。
Ogier, et al. Experimental [Page 12] RFC 3684 TBRPF February 2004
オジェ、他 [12ページ]実験的なRFC3684TBRPF2004年2月
6.2.2. Messages (TYPE = 2 thru 10)
6.2.2. メッセージ(2〜TYPE=10)
Additional message types are described as they occur in the following sections. Senders encode messages as specified by the individual message formats. Receivers detect errors in message construction, e.g., messages with unrecognized types, messages with a non-integral number of elements, or with fewer elements than indicated, etc. In all cases, upon detecting an error, the receiver MUST discontinue processing the current TBRPF packet and discard any unprocessed elements.
彼らが以下のセクションに起こるとき、追加メッセージタイプは説明されます。 送付者は指定されるとしての個々のメッセージ・フォーマットによるメッセージをコード化します。 受信機はメッセージ構造における誤り、例えば、認識されていないタイプがあるメッセージ、非整数の要素、または示されるより少ない要素があるメッセージなどを検出します。 すべての場合では、誤りを検出するとき、受信機は、現在のTBRPFパケットを処理するのは使用をやめて、どんな未加工の要素も捨てなければなりません。
7. TBRPF Neighbor Discovery
7. TBRPF隣人発見
This section describes the TBRPF Neighbor Discovery (TND) protocol, which allows each node to quickly detect bidirectional links (I,J) between a local interface I and a neighbor interface J, and to quickly detect the loss of such links. The interface between TND and the routing module is defined by the neighbor table maintained by TND and the three procedures Link_Up(I,J), Link_Down(I,J), and Link_Change(I,J), which are called by TND to announce a new link, the loss of a link, and a change in the metric of a link, respectively.
このセクションはTBRPF Neighborディスカバリー(TND)プロトコルについて説明します。(それは、すぐに、局所界面Iと隣人インタフェースJとの双方向のリンク(I、J)を検出して、すぐにそのようなリンクの損失を検出するために各ノードを許容します)。 TNDとルーティングモジュールとのインタフェースはTNDによって維持された隣人テーブルによって定義されます、そして、Link_Up(I、J)、Link_Down(I、J)、新しいリンク、リンクの損失を発表するためにTNDによって呼ばれるLink_Change(I、J)、およびaがaのメートル法で変える3つの手順がそれぞれリンクされます。
7.1. HELLO Message Format
7.1. こんにちは、メッセージ・フォーマット
The HELLO message has the following three subtypes:
HELLOメッセージには、以下の3血液型亜型があります:
- NEIGHBOR REQUEST (TYPE = 2) - NEIGHBOR REPLY (TYPE = 3) - NEIGHBOR LOST (TYPE = 4)
- 隣人は、(タイプ=2)--隣人回答(=3をタイプする)--隣人が損をしたよう要求します。(タイプ=4)
Each HELLO subtype has the following format:
各HELLO subtypeには、以下の形式があります:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | TYPE | HSEQ | Pri | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interface Address (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interface Address (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interface Address (n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | タイプ| HSEQ| Pri| n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 隣人インターフェース・アドレス(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 隣人インターフェース・アドレス(2)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 隣人インターフェース・アドレス(n)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HSEQ (8 bits)
The HELLO sequence number.
HSEQ、(8ビット) HELLO一連番号。
Ogier, et al. Experimental [Page 13] RFC 3684 TBRPF February 2004
オジェ、他 [13ページ]実験的なRFC3684TBRPF2004年2月
Pri (4 bits)
This field indicates the sending node's relay priority, which is
an integer between 0 and 15. A node with a higher relay priority
is more likely to be selected as the next hop on a route. The
value 0 is reserved for non-relay nodes, i.e., nodes that should
never forward packets originating from other nodes. A router in
normal operation SHOULD have a relay priority equal to 7. A
router can change its relay priority dynamically, e.g., when its
power supply becomes critical.
Pri、(4ビット) この分野は送付ノードのリレー優先権を示します。(それは、0〜15の整数です)。 ルートの上では、より高いリレー優先度があるノードは次のホップとして、より選択されそうです。 値0はすなわち、非リレーノード、他のノードから発するパケットを決して進めるはずがないノードのために予約されます。 SHOULDがリレー優先に7と等しくさせる通常の操作におけるルータ。 例えば、電源が批判的になると、ルータはダイナミックにリレー優先権を変えることができます。
n (12 bits)
The number of 32-bit neighbor interface addresses in the message.
32ビットの隣人インタフェースの数がメッセージに記述するn(12ビット)。
A HELLO message is the concatenation of a NEIGHBOR REQUEST message, a NEIGHBOR REPLY message, and a NEIGHBOR LOST message, where each of the last two messages is omitted if its list of neighbor interface addresses is empty. Thus, a HELLO message always includes a (possibly empty) NEIGHBOR REQUEST.
HELLOメッセージはNEIGHBOR REQUESTメッセージ、NEIGHBOR REPLYメッセージ、およびNEIGHBOR LOSTメッセージの連結です。そこでは、隣人インターフェース・アドレスのリストが空であるなら、それぞれに関する最後の2つのメッセージが省略されます。 したがって、HELLOメッセージはいつも(ことによると空)のNEIGHBOR REQUESTを含んでいます。
7.2. Neighbor Table
7.2. 隣人テーブル
Each node maintains, for each of its local interfaces I, a neighbor table, which stores state information for each neighbor interface J from which HELLO messages have recently been received by interface I. The entry for neighbor interface J, in the neighbor table for I, contains the following variables:
各ノードは、それぞれの局所界面I、HELLOメッセージが最近インタフェースI.によって受け取られたそれぞれの隣人インタフェースJのための州の情報を格納する隣人テーブルのために隣人インタフェースJのためのエントリーがIのための隣人テーブルに以下の変数を含むと主張します:
nbr_rid(I,J) - The router ID of the node associated with neighbor
interface J.
nbr_は(I、J)を取り除きました--ノードのIDが隣人インタフェースJに関連づけたルータ。
nbr_status(I,J) - The current status of the link (I,J), which can
be LOST, 1-WAY, or 2-WAY.
nbr_状態(I、J)--リンク(I、J)の現在の状態。(それは、LOST、1-WAY、または2-WAYであるかもしれません)。
nbr_life(I,J) - The amount of time (in seconds) remaining before
nbr_status(I,J) must be changed to LOST if no further HELLO
message from interface J is received. Set to NBR_HOLD_TIME
whenever a HELLO is received on interface I from interface J.
nbr_人生(I、J)--どんな一層のHELLOもインタフェースJから通信しないならnbr_状態(I、J)がLOSTに変わらなければならない前に残っている時間(秒の)は受け取られています。 インタフェースIにインタフェースJからHELLOを受け取るときはいつも、NBR_HOLD_タイム誌にセットしてください。
nbr_hseq(I,J) - The value of HSEQ in the last HELLO message
received on interface I from interface J. Used to determine the
number of HELLOs that have been missed.
nbr_hseq(I、J)--いなくて寂しかったHELLOsの数を測定するためにインタフェースJ.UsedからのインタフェースIに受け取られた最後のHELLOメッセージのHSEQの値。
nbr_count(I,J) - The remaining number of times a NEIGHBOR REQUEST/
REPLY/LOST message containing J must be sent on interface I.
nbr_カウント(I、J)--インタフェースIでJを含むa NEIGHBOR REQUEST/REPLY/LOSTが通信させる回の残っている数を送らなければなりません。
hello_history(I,J) - A list of the sequence numbers of the last
HELLO_ACQUIRE_WINDOW HELLO messages received on interface I from
interface J.
こんにちは、_(I、J)--Aがリストアップする最後のHELLO_ACQUIRE_WINDOW HELLOメッセージの一連番号の歴史はインタフェースIでインタフェースJから受信されました。
Ogier, et al. Experimental [Page 14] RFC 3684 TBRPF February 2004
オジェ、他 [14ページ]実験的なRFC3684TBRPF2004年2月
nbr_metric(I,J) - An optional measure of the quality of the link
(I,J), represented by an integer between 1 and 255, where smaller
values indicate better quality. Defaults to 1 if not used.
nbr_メートル法、(I、J)--より小さい値が、より良質であるのを示す1〜255の整数によって表されたリンク(I、J)の品質の任意の基準。 使用されないなら、1をデフォルトとします。
nbr_pri(I,J) - The relay priority of the node associated with
interface J.
nbr_pri(I、J)--インタフェースJに関連しているノードのリレー優先権。
The entry for interface J in the neighbor table for interface I may be deleted if no HELLO has been received on interface I from interface J within the last 2*NBR_HOLD_TIME seconds. (It is kept while NEIGHBOR LOST messages containing J are being transmitted.) The absence of an entry for a given interface J is equivalent to an entry with nbr_status(I,J) = LOST and hello_history(I,J) = NULL.
最後の2*NBR_HOLD_タイム誌秒以内にインタフェースIにインタフェースJからHELLOを全く受け取っていないなら、インタフェースIへの隣人テーブルのインタフェースJのためのエントリーを削除するかもしれません。 (Jを含むNEIGHBOR LOSTメッセージが送られている間、それは保たれます。) 当然のことのインタフェースJのためのエントリーの欠如はこんにちは、nbr_状態(I、J)=LOSTと_歴史(I、J)=NULLによってエントリーに同等です。
The three possible values of nbr_status(I,J) have the following informal meanings (the exact meanings are defined by the protocol):
nbr_状態(I、J)の3つの可能な値には、以下の非公式の意味があります(正確な意味はプロトコルによって定義されます):
LOST
Interface I has not received a sufficient number of HELLO messages
recently from Interface J.
LOST Interface Iは最近、Interface Jから十分な数のHELLOメッセージを受け取っていません。
1-WAY
Interface I has received a sufficient number of HELLO messages
recently from Interface J, but the link is not 2-WAY.
1-WAY Interface Iは最近、Interface Jから十分な数のHELLOメッセージを受け取りましたが、リンクは2-WAYではありません。
2-WAY
Interfaces I and J have both received a sufficient number of HELLO
messages recently from each other.
2-WAY Interfaces私とJは最近、互いから十分な数のHELLOメッセージをともに受け取りました。
7.3. Sending HELLO Messages
7.3. 発信、こんにちは、メッセージ
Each node MUST send, on each local interface, at least one HELLO message per HELLO_INTERVAL. HELLO messages MAY be sent more frequently than this (e.g., for faster detection of topology changes). However, to avoid the possibility that HSEQ wraps around to the same number before a neighbor that stops receiving HELLO messages changes the status of the link to LOST, the time between two consecutive HELLO messages (sent on a given interface) MUST be greater than NBR_HOLD_TIME/128 second.
各ノードは各局所界面でHELLO_INTERVALあたり少なくとも1つのHELLOメッセージを送らなければなりません。 これ(例えば、トポロジー変化の、より速い検出のための)より頻繁にHELLOメッセージを送るかもしれません。 しかしながら、HELLOメッセージを受け取るのを止める隣人がLOSTへのリンクの状態を変える前にHSEQが同じ数に巻きつける可能性を避けるために、2つの連続したHELLOメッセージ(与えられたインタフェースを転送する)の間の時間はNBR_HOLD_タイム誌/128 2番目より大きくなければなりません。
To avoid synchronization of control messages, which can result in collisions, HELLO messages SHOULD NOT be transmitted at equal intervals. To achieve this, a node MAY choose the interval between consecutive HELLO messages to be HELLO_INTERVAL - jitter, where jitter is selected randomly from the interval [0, MAX_JITTER].
衝突、HELLOメッセージSHOULD NOTをもたらすことができるコントロールメッセージの同期を避けるには、等間隔で、伝えられてください。 これを達成するために、ノードはHELLO_INTERVALである連続したHELLOメッセージの間隔を選ぶかもしれません--ジター。(そこでは、ジターが間隔[0、マックス_JITTER]から手当たりしだいに選択されます)。
Ogier, et al. Experimental [Page 15] RFC 3684 TBRPF February 2004
オジェ、他 [15ページ]実験的なRFC3684TBRPF2004年2月
Each HELLO message always includes a NEIGHBOR REQUEST message, even if its list of neighbor addresses is empty. The NEIGHBOR REQUEST message includes the sequence number HSEQ, which is incremented by 1 (modulo 256) each time a HELLO is sent. The HELLO message also includes a NEIGHBOR REPLY message if its list of neighbor addresses is nonempty, and a NEIGHBOR LOST message if its list of neighbor addresses is nonempty. The contents of these three messages are determined by the following steps at node i for each interface I:
隣人アドレスのリストが空であっても、それぞれのHELLOメッセージはいつもNEIGHBOR REQUESTメッセージを含んでいます。 NEIGHBOR REQUESTメッセージは一連番号HSEQを含んでいます。(HSEQはHELLOを送るたびに1つ(法256)増加されます)。 また、HELLOメッセージは隣人アドレスのリストがnonemptyと、隣人のリストであるならアドレスがnonemptyであるというNEIGHBOR LOSTメッセージであるならNEIGHBOR REPLYメッセージを含んでいます。 これらの3つのメッセージの内容は以下のステップで決定して、それぞれのためのノードiでは、私が連結するということです:
1. For each interface J such that nbr_status(I,J) = LOST and
nbr_count(I,J) > 0, include J in the NEIGHBOR LOST message and
decrement nbr_count(I,J).
1. それぞれのインタフェースJあれほどそんなにnbrな_状態(I、J)=LOSTとnbr_カウント(I、J)>0に関しては、NEIGHBOR LOSTメッセージと減少nbr_カウント(I、J)でJを含めてください。
2. For each interface J such that nbr_status(I,J) = 1-WAY and
nbr_count(I,J) > 0, include J in the NEIGHBOR REQUEST message and
decrement nbr_count(I,J).
2. それぞれのインタフェースJあれほどそんなにnbrな_状態(I、J)=1-WAYとnbr_カウント(I、J)>0に関しては、NEIGHBOR REQUESTメッセージと減少nbr_カウント(I、J)でJを含めてください。
3. For each interface J such that nbr_status(I,J) = 2-WAY and
nbr_count(I,J) > 0, include J in the NEIGHBOR REPLY message and
decrement nbr_count(I,J).
3. それぞれのインタフェースJあれほどそんなにnbrな_状態(I、J)=2-WAYとnbr_カウント(I、J)>0に関しては、NEIGHBOR REPLYメッセージと減少nbr_カウント(I、J)でJを含めてください。
If a node restarts, so that all entries are removed from the neighbor table, then the node MUST ensure that (for each interface) at least one of the following two conditions is satisfied:
ノードが再開するので隣人テーブルからすべてのエントリーを取り除くなら、ノードは、少なくとも以下の2つの条件の(各インタフェースへの)1つが満足しているのを確実にしなければなりません:
1. The difference between the transmission times of the first HELLO
sent after restarting and the last HELLO sent before restarting is
at least 2*NBR_HOLD_TIME.
1. 最初のHELLOのトランスミッション倍の違いは再開した後に発信しました、そして、再開が少なくとも2*NBR_タイム誌にHOLD_なる前に最後のHELLOは発信しました。
2. Letting HSEQ_LAST denote the sequence number of the last HELLO
that was sent before restarting, the sequence number of the first
HELLO sent after restarting is set to HSEQ_LAST + NBR_HOLD_COUNT +
1 (modulo 256).
2. HSEQ_LASTに再開する前に送られた最後のHELLOの一連番号を指示させて、再開した後に送られた最初のHELLOの一連番号はHSEQ_LAST+NBR_HOLD_COUNT+1(法256)へのセットです。
Either of these conditions ensures that, if node i with interface I restarts, then each neighbor of node i that has a link (J,I) to interface I will set the status of the link to LOST.
これらの状態のどちらかが、次に、インタフェースIがあるノードiが再開するとaがIを連結するように(J、I)をリンクするノードiの各隣人がLOSTへのリンクの状態を設定するのを確実にします。
7.4. Processing a Received HELLO Message
7.4. aを処理するのが、こんにちはを受けた、メッセージ
When a node receives a HELLO message, it obtains the IP address of the sending interface from the IP header. If the TBRPF packet header of the received HELLO contains the RID option, then the RID of the sending node is obtained from the TBRPF packet header; otherwise it is equal to the IP address of the sending interface. If node i (with RID equal to i) receives a HELLO message on interface I, sent by node j (with RID equal to j) on interface J, with sequence number HSEQ and relay priority PRI, then node i performs the following steps:
ノードがHELLOメッセージを受け取るとき、それはIPヘッダーから送付インタフェースのIPアドレスを得ます。 容認されたHELLOのTBRPFパケットのヘッダーがRIDオプションを含むなら、TBRPFパケットのヘッダーから送付ノードのRIDを入手します。 さもなければ、それは送付インタフェースのIPアドレスと等しいです。 ノードi(iと等しいRIDと)がHELLOメッセージを受け取るなら、一連番号HSEQをもっているノードj(jと等しいRIDと)によってインタフェースJで送られた私とリレー優先権PRIは連結します、次に、ノードiは以下のステップを実行します:
Ogier, et al. Experimental [Page 16] RFC 3684 TBRPF February 2004
オジェ、他 [16ページ]実験的なRFC3684TBRPF2004年2月
1. If the neighbor table for interface I does not contain an entry
for interface J, create one with nbr_rid(I,J) = j, nbr_status(I,J)
= LOST (temporarily), nbr_count(I,J) = 0, and nbr_hseq(I,J) =
HSEQ.
1. インタフェースIへの隣人テーブルがインタフェースJのためのエントリーを含まないなら、nbr_が取り除かれている1(I、J)=j(nbr_状態(I、J)の=LOST(一時)、nbr_カウント(I、J)=0、およびnbr_hseq(I、J)=HSEQ)を作成してください。
2. Update hello_history(I,J) to reflect the received HELLO message.
If nbr_hseq(I,J) > HSEQ (due to wraparound), set nbr_hseq(I,J) =
nbr_hseq(I,J) - 256.
2. アップデート、こんにちは、_受信されたHELLOメッセージを反映する歴史(I、J)。 nbr_hseq(I、J)>HSEQ(巻きつけて着るドレスによる)であるなら、nbr_hseq(I、J)=nbr_hseq(I、J)を設定してください--256。
3. If nbr_status(I,J) = LOST and hello_history(I,J) indicates that
HELLO_ACQUIRE_COUNT of the last HELLO_ACQUIRE_WINDOW HELLO
messages from interface J have been received:
3. _nbr_状態(I、J)がLOSTと等しく、こんにちはなら、歴史(I、J)は、最後のHELLO_ACQUIRE_WINDOW HELLOのCOUNTがインタフェースJから通信させるHELLO_ACQUIRE_が受け取られたのを示します:
a. If interface I does not appear in the NEIGHBOR REQUEST list or
the NEIGHBOR REPLY list, set nbr_status(I,J) = 1-WAY and
nbr_count(I,J) = NBR_HOLD_COUNT.
a。 インタフェースIがNEIGHBOR REQUESTリストかNEIGHBOR REPLYリストに現れないなら、セットnbr_状態(I、J)の=1-WAYとnbr_は(I、J)=NBR_HOLD_COUNTを数えます。
b. Else, set nbr_status(I,J) = 2-WAY and nbr_count(I,J) =
NBR_HOLD_COUNT. Call Link_Up(I,J).
b。 ほかに、セットnbr_状態(I、J)の=2-WAYとnbr_は(I、J)=NBR_HOLD_COUNTを数えます。 リンク_を呼び出してください(I、J)。
4. Else, if nbr_status(I,J) = 1-WAY:
4. ほかの、そして、nbrな_状態(I、J)は1ウェイと等しいです:
a. If HSEQ - nbr_hseq(I,J) > NBR_HOLD_COUNT, then set
nbr_status(I,J) = LOST and nbr_count(I,J) = NBR_HOLD_COUNT.
a。 _HSEQ--_hseq(I、J)>NBR_HOLD_COUNTをnbrして、次に、nbr_状態を設定するのが(I、J)LOSTとnbrと等しいなら、(I、J)=NBR_HOLD_COUNTを数えてください。
b. Else, if interface I appears in the NEIGHBOR REQUEST list, set
nbr_status(I,J) = 2-WAY and nbr_count(I,J) = NBR_HOLD_COUNT.
Call Link_Up(I,J).
b。 ほかに、インタフェースIがNEIGHBOR REQUESTリストに現れるなら、セットnbr_状態(I、J)の=2-WAYとnbr_は(I、J)=NBR_HOLD_COUNTを数えます。 リンク_を呼び出してください(I、J)。
c. Else, if interface I appears in the NEIGHBOR REPLY list, set
nbr_status(I,J) = 2-WAY and nbr_count(I,J) = 0. Call
Link_Up(I,J).
c。 ほかに、インタフェースIがNEIGHBOR REPLYリストに現れるなら、セットnbr_状態(I、J)の=2-WAYとnbr_は(I、J)=0を数えます。 リンク_を呼び出してください(I、J)。
5. Else, if nbr_status(I,J) = 2-WAY:
5. ほかの、そして、nbrな_状態(I、J)は2ウェイと等しいです:
a. If interface I appears in the NEIGHBOR LOST list, set
nbr_status(I,J) = LOST and nbr_count(I,J) = 0. Call
Link_Down(I,J).
a。 インタフェースIがNEIGHBOR LOSTリストに現れるなら、セットnbr_状態(I、J)の=LOSTとnbr_は(I、J)=0を数えます。 リンク_を(I、J)に電話をしてください。
b. Else, if HSEQ - nbr_hseq(I,J) > NBR_HOLD_COUNT, set
nbr_status(I,J) = LOST and nbr_count(I,J) = NBR_HOLD_COUNT.
Call Link_Down(I,J).
b。 --HSEQであるならほかに、LOSTとnbr nbr_hseq(I、J)>NBR_HOLD_COUNT、セットnbr_状態(I、J)=_は(I、J)=NBR_HOLD_COUNTを数えます。 リンク_を(I、J)に電話をしてください。
c. Else, if interface I appears in the NEIGHBOR REQUEST list and
nbr_count(I,J) = 0, set nbr_count(I,J) = NBR_HOLD_COUNT.
c。 インタフェースIがNEIGHBOR REQUESTリストとnbr_カウント(I、J)=0に現れるなら、ほかに、nbr_カウント(I、J)=NBR_HOLD_COUNTを設定してください。
6. Set nbr_life(I,J) = NBR_HOLD_TIME, nbr_hseq(I,J) = HSEQ, and
nbr_pri(I,J) = PRI.
6. nbr_hseq(I、J)はHSEQと等しいです、そして、=NBR_保持_時間nbr_人生(I、J)を決めてください、そして、nbr_pri(I、J)はPRIと等しいです。
Ogier, et al. Experimental [Page 17] RFC 3684 TBRPF February 2004
オジェ、他 [17ページ]実験的なRFC3684TBRPF2004年2月
7.5. Expiration of Timer nbr_life
7.5. Timer nbr_人生の満了
Upon expiration of the timer nbr_life(I,J) in the neighbor table for interface I, node i performs the following step:
インタフェースIへの隣人テーブルのタイマのnbr_寿命(I、J)の満了に、ノードiは以下のステップを実行します:
If nbr_status(I,J) = 1-WAY or 2-WAY, set nbr_status(I,J) = LOST
and nbr_count(I,J) = NBR_HOLD_COUNT. Call Link_Down(I,J).
nbr_状態(I、J)が1-WAYか2-WAYと等しいなら、セットnbr_状態(I、J)の=LOSTとnbr_は(I、J)=NBR_HOLD_COUNTを数えます。 リンク_を(I、J)に電話をしてください。
7.6. Link-Layer Failure Notification
7.6. リンクレイヤ失敗通知
Some link-layer protocols (e.g., IEEE 802.11) provide a notification that the link to a particular neighbor has failed, e.g., after attempting a maximum number of retransmissions. If such an notification is provided by the link layer, then node i SHOULD perform the following step upon receipt of a link-layer failure notification for the link (I,J) from local interface I to neighbor interface J:
いくつかのリンク層プロトコル(例えば、IEEE802.11)が特定の隣人へのリンクが失敗したという通知を提供します、例えば、「再-トランスミッション」の最大数を試みた後に。 リンクレイヤのそばでそのような通知を提供するなら、ノードi SHOULDはリンク(I、J)のためのリンクレイヤ失敗通知を受け取り次第局所界面Iから隣人インタフェースJまで以下のステップを実行します:
If nbr_status(I,J) = 2-WAY, set nbr_status(I,J) = LOST and
nbr_count(I,J) = NBR_HOLD_COUNT. Call Link_Down(I,J).
nbr_状態(I、J)が2-WAYと等しいなら、セットnbr_状態(I、J)の=LOSTとnbr_は(I、J)=NBR_HOLD_COUNTを数えます。 リンク_を(I、J)に電話をしてください。
7.7. Optional Link Metrics
7.7. 任意のリンク測定基準
Each node MAY maintain and update one or more link metrics for each link (I,J), representing the quality of the link, e.g., signal strength, number of HELLOs received over some time interval, reliability, stability, bandwidth, etc. Each node MUST declare a neighbor to be LOST if either NBR_HOLD_COUNT HELLOs are missed or if no HELLO is received within NBR_HOLD_TIME seconds; however, a node MAY also declare a neighbor to be LOST based on a link metric being above or below some threshold. Each node MUST receive at least HELLO_ACQUIRE_COUNT of the last HELLO_ACQUIRE_WINDOW HELLOs from a neighbor before declaring the neighbor 1-WAY or 2-WAY; however, a node MAY require an additional condition based on a link metric being above or below some threshold, before declaring the neighbor 1-WAY or 2-WAY. This document does not specify any particular link metric, but an implementation of TBRPF that uses such metrics is considered to be compliant with this specification.
各ノードは、各リンク(I、J)あたり1つ以上のリンク測定基準を維持して、アップデートするかもしれません、リンクの品質、例えば、信号強度、いくつかの時間間隔にわたって受け取られたHELLOsの数、信頼性、安定性、帯域幅などを表して NBR_HOLD_COUNT HELLOsがいなくて寂しい、またはNBR_HOLD_タイム誌秒以内にHELLOを全く受け取らないなら、各ノードは、隣人がLOSTであると宣言しなければなりません。 しかしながら、また、ノードは、隣人がリンクにメートル法であることで基づく敷居の上、または、何らかの敷居の下にあるLOSTであると宣言するかもしれません。 各ノードは隣人が1-WAYか2-WAYであると宣言する前に、最後のHELLO_ACQUIRE_WINDOW HELLOsについて隣人から少なくともHELLO_ACQUIRE_COUNTを受けなければなりません。 しかしながら、ノードはリンクにメートル法であることで基づく敷居の上、または、何らかの敷居の下にある追加条件を必要とするかもしれません、隣人が1-WAYか2-WAYであると宣言する前に。 このドキュメントはメートル法でどんな特定のリンクも指定しませんが、そのような測定基準を使用するTBRPFの実現がこの仕様で言いなりになると考えられます。
The function Link_Change(I,J) is called to alert the routing module whenever nbr_metric(I,J) changes significantly. If the configurable parameter USE_METRICS is equal to 1, then the metrics nbr_metric(I,J) are used by the routing module for route computation, as described in Section 8.
_Changeがnbr_メートル法であるときはいつも、ルーティングモジュールを警告するために呼ばれる(I、J)機能Link(I、J)はかなり変化します。 構成可能なパラメタUSE_METRICSがnbr_が次に、1、測定基準とメートル法であることで等しいことであるなら、(I、J)は経路計算にルーティングモジュールで使用されます、セクション8で説明されるように。
Ogier, et al. Experimental [Page 18] RFC 3684 TBRPF February 2004
オジェ、他 [18ページ]実験的なRFC3684TBRPF2004年2月
7.8. Configurable Parameters
7.8. 構成可能なパラメタ
This section lists the parameters used by the neighbor discovery protocol, and their proposed default values. All nodes MUST be configured to have the same value for all of the following parameters.
このセクションは隣人発見プロトコルによって使用されるパラメタ、およびそれらの提案されたデフォルト値を記載します。 以下のパラメタのすべてのための同じ値を持つためにすべてのノードを構成しなければなりません。
Parameter Name Default Value
-------------- -------------
HELLO_INTERVAL 1 second
MAX_JITTER 0.1 second
NBR_HOLD_TIME 3 seconds
NBR_HOLD_COUNT 3
HELLO_ACQUIRE_COUNT 2
HELLO_ACQUIRE_WINDOW 3
パラメタ名前デフォルト値-------------- ------------- HELLO_INTERVAL1秒のマックス_JITTER0.1秒のNBR_HOLD_タイム誌3秒NBR_HOLD_COUNT3HELLO_ACQUIRE_COUNT2HELLO_ACQUIRE_WINDOW3
8. TBRPF Routing Module
8. TBRPFルート設定モジュール
This section describes the TBRPF routing module, which performs topology discovery and route computation.
このセクションはTBRPFルーティングモジュールを説明します。(それは、トポロジー発見と経路計算を実行します)。
8.1. Conceptual Data Structures
8.1. 概念的なデータ構造
In addition to the information required by the neighbor discovery protocol, each node running TBRPF maintains a topology table TT, which stores information for each known node and link in the network. Nodes are identified by their RIDs, i.e., node u is the node whose RID is u. The following information is stored in the topology table at node i for each node u and link (u,v):
隣人発見プロトコルによって必要とされた情報、走行TBRPFがトポロジーであると主張する各ノードに加えて、TTをテーブルの上に置いてください。(TTはネットワークに各知られているノードとリンクのための情報を格納します)。 ノードはそれらのRIDsによって特定されます、すなわち、ノードuはRIDがuであるノードです。 以下の情報はノードiにトポロジーテーブルに各ノードuとリンク(u、v)に格納されます:
T(u,v) - Equal to 1 if (u,v) is in node i's source tree T, and 0
otherwise. The previous source tree is also maintained as old_T.
T(u、v)--(u、v)によるそうでなければ、iによるノードでは、ソース木Tと、0であるということであるなら、1と等しいです。 また、前のソース木は古い_Tとして維持されます。
RN(u) - Equal to 1 if u is in node i's reported node set RN, and 0
otherwise. The previous reported node set is also maintained as
old_RN.
RN(u)--uがノードiにあるなら、1への同輩は、そうでなければ、ノードがRN、および0を設定したと報告しました。 また、前の報告されたノードセットは古い_RNとして維持されます。
RT(u,v) - Equal to 1 if (u,v) is in node i's reported subtree RT,
and 0 otherwise. Since RT is defined as the set of links (u,v) in
T such that u is in RN, this variable need not be maintained
explicitly.
RT(u、v)--そうでなければ、ノードiの報告された下位木RT、および0に(u、v)があるなら、1と等しいです。 以来RTがTでリンク(u、v)のセットと定義されるので、uがRNにあって、この変数は明らかに維持される必要はありません。
TG(u,v) - Equal to 1 if (u,v) is in node i's topology graph TG,
and 0 otherwise.
TG(u、v)--そうでなければ、ノードiのトポロジーグラフTG、および0に(u、v)があるなら、1と等しいです。
N - The set of 2-way neighbors of node i.
N--ノードiの2ウェイ隣人のセット。
Ogier, et al. Experimental [Page 19] RFC 3684 TBRPF February 2004
オジェ、他 [19ページ]実験的なRFC3684TBRPF2004年2月
r(u,v) - The list of neighbors that are reporting link (u,v) in
their reported subtree RT. The set of links (u,v) reported by
neighbor j is denoted RT_j.
r(u、v)--彼らの報告された下位木RTでリンク(u、v)を報告している隣人のリスト。 隣人jによって報告されたリンク(u、v)のセットは指示されたRT_jです。
r(u) - The list of neighbors that are reporting node u in their
reported node set RN.
r(u)--彼らの報告されたノードのノードuを報告している隣人のリストはRNを設定しました。
p(u) - The current parent for node u, equal to the next node on
the shortest path to u.
p(u)--uへの最短パスの次のノードと等しいノードuのための現在の親。
pred(u) - The node that is the predecessor of node u in the source
tree T. Equal to NULL if node u is not reachable.
pred(u)--ノードuが届かないならNULLへのソース木のT.Equalのノードuの前任者であるノード。
pred(j,u) - The node that is the predecessor of node u in the
subtree RT_j reported by neighbor j.
pred(j、u)--下位木RT_jにおけるノードuの前任者であるノードは隣人jで報告しました。
d(u) - The length of the shortest path to node u. If USE_METRICS
= 0, d(u) is the number of hops to node u.
d(u)--ノードuへの最短パスの長さ。 USE_METRICS=0であるなら、d(u)はノードuへのホップの数です。
reported(u,v) - Equal to 1 if link (u,v) in TG is reported by
p(u), and 0 otherwise.
(u、v)--そうでなければ、TGのリンク(u、v)がp(u)によって報告されるか、そして、0が1と等しいと報告しました。
tg_expire(u) - Expiration time for links (u,v) in TG.
tg_は(u)を吐き出します--TGのリンク(u、v)への満了時間。
rt_expire(j,u) - Expiration time for links (u,v) in RT_j.
rt_は(j、u)を吐き出します--RT_jのリンク(u、v)への満了時間。
nr_expire(u,v) - Expiration time for a link (u,v) in TG such that
reported(u,v) = 0. Such non-reported links can be used
temporarily during rerouting.
nr_は(u、v)を吐き出します--TGのリンク(u、v)に関して、報告したそのようなもの(u、v)が0と等しい満了時間。 コースを変更している間、一時そのような非報告されたリンクを使用できます。
metric(j,u,v) - The metric for link (u,v) reported by neighbor j.
メートル法、(j、u、v)--リンク(u、v)へのメートル法は隣人jで報告しました。
metric(u,v) - The metric for link (u,v) in TG. For a neighbor j,
metric(i,j) is the minimum of nbr_metric(I,J) over all 2-WAY links
(I,J) from i to j.
メートル法、(u、v)--TGのリンク(u、v)へのメートル法。 隣人jにとって、メートル法であることは(i、j)、2-WAY iからjへのすべてのリンク(I、J)の上のnbr_メートル法の最小限(I、J)です。
cost(u,v) - The cost for link (u,v), equal to metric(u,v) if
USE_METRICS = 1, and otherwise equal to 1.
(u、v)かかってください--1が等しく、そうでなければ、USE_METRICSは1と同輩と等しいなら(u、v)がメートル法(u、v)と等しいリンクへの費用。
local_if(j) - The address of the preferred local interface for
forwarding packets to neighbor j.
地方、--_(j)であるなら都合のよいローカルのアドレスは推進パケットのために隣人jに連結します。
nbr_if(j) - The address of the preferred interface of neighbor j.
nbr、--_(j)であるなら都合のよさのアドレスは隣人jに連結します。
Ogier, et al. Experimental [Page 20] RFC 3684 TBRPF February 2004
オジェ、他 [20ページ]実験的なRFC3684TBRPF2004年2月
The routing table consists of a list of tuples of the form (rt_dest, rt_next, rt_dist, rt_if_id), where rt_dest is the destination IP address or prefix, rt_next is the interface address of the next hop of the route, rt_dist is the length of the route, and rt_if_id is the ID of the local interface through which the next hop can be reached.
経路指定テーブルは、ルートがrt_destが送付先IPアドレスか接頭語である、rt_次がルートの次のホップのインターフェース・アドレスである、rt_distが長さである形式(__イドであるならdestに、rtに_次に、rtに_distに、rtに_をrtする)のtuplesのリストから成って、__イドが次のホップに達することができる局所界面のIDであるならrtに成ります。
Each node also maintains three tables that describe associated IP addresses or prefixes: the "interface table", which associates interface IP addresses with router IDs, the "host table", which associates host IP addresses with router IDs, and the "network prefix table", which associates network prefixes with router IDs.
また、各ノードは関連IPアドレスか接頭語について説明する3個のテーブルを維持します: 「インタフェーステーブル」、どの「ホストテーブル」、ホストIPがルータIDで演説する仲間、および「ネットワーク接頭語テーブル」(交際する)がルータIDで接頭語をネットワークでつなぐか。(それは、インタフェースIPアドレスをルータIDに関連づけます)。
The "interface table" consists of tuples of the form (if_addr, if_rid, if_expire), where if_addr is an interface IP address associated with the router with RID = if_rid, and if_expire is the time at which the tuple expires and MUST be removed. The interface table at a node does NOT contain an entry in which if_addr equals the node's own RID; thus, a node does not advertise its own RID as an associated interface.
「インタフェーステーブル」が形式(_addrであるなら、_排除しているなら、_であるなら期限が切れる)のtuplesから成って、_が期限が切れるなら、tupleが期限が切れる時であり、取り除かなければなりません。(_addrがインタフェースであるなら、そこでは、_排除しているなら、IPアドレスがRID=と共にルータと交際しました)。 ノードのインタフェーステーブルはaddrが_であるならノードの自身のRIDと等しいエントリーを含んでいません。 したがって、ノードは関連インタフェースとしてそれ自身のRIDの広告を出しません。
The "host table" consists of tuples of the form (h_addr, h_rid, h_expire), where h_addr is a host IP address associated with the router with RID = h_rid, and h_expire is the time at which the tuple expires and MUST be removed.
「ホストテーブル」は形式のtuplesから成って(h_addr、取り除かれたh_、h_は期限が切れます)、_が取り除いて、h_が吐き出すRID=hでルータに関連しているアドレスはh_addrがホストIPであることのtupleは期限が切れて、取り外さなければならない時です。
The "network prefix table" consists of tuples of the form (net_prefix, net_length, net_rid, net_expire), where net_prefix and net_length describe a network prefix associated with the router with RID = net_rid, and net_expire is the time at which the tuple expires and MUST be removed. A MANET may be configured as a "stub" network, in which case one or more gateway routers may announce a default prefix such that net_prefix = net_length = 0. Two copies of each table are kept: an "old" copy that was last reported to neighbors, and the current copy that is updated when association messages are received.
「ネットワーク接頭語テーブル」は形式のtuplesから成って(ネットの_接頭語、ネットの_の長さ、ネットの_排除していて、ネットの_は期限が切れます)、ネットの_接頭語とネットの_の長さがどこで排除していて、ネットの_が吐き出すネットのRID=_でルータに関連しているネットワーク接頭語について説明するかは、tupleは期限が切れて、取り外さなければならない時です。 マネはより多くのケース1ゲートウェイルータがそのようなネットの_のそのネットの_接頭語=長さにデフォルト接頭語を発表するかもしれない「スタッブ」ネットワーク=0として構成されるかもしれません。 それぞれのテーブルの写し2部は取っておかれます: 最後である「古い」コピーは隣人、および協会メッセージが受信されているときアップデートされる現在のコピーに報告しました。
8.2. TOPOLOGY UPDATE Message Format
8.2. トポロジーアップデートメッセージ・フォーマット
The TOPOLOGY UPDATE message has the two formats, depending on the size of the message. The normal format is as follows, and is used whenever n, NRL, and NRNL all do not exceed 255:
TOPOLOGY UPDATEメッセージには、メッセージのサイズによって、2つの形式があります。 正常な形式は、以下の通りであり、すべてがするn、NRL、およびNRNLが255を超えていないときはいつも、使用されています:
Ogier, et al. Experimental [Page 21] RFC 3684 TBRPF February 2004
オジェ、他 [21ページ]実験的なRFC3684TBRPF2004年2月
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|D|0|0| TYPE | n | NRL | NRNL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID of u | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID of v_1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID of v_n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | metric 1 | metric 2 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|D|0|0| タイプ| n| NRL| NRNL| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | uのルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v_1のルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | vのルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メートル法の1| メートル法の2| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The message body contains the n+1 router IDs for nodes u, v_1,...,v_n, which represent the links (u,v_1),..., (u,v_n). The first NRL of the v_k are reported leaf nodes, the next NRNL of the v_k are reported non-leaf nodes, and the last n - (NRL+NRNL) of the v_k are not reported (not in RN).
メッセージ本体は_1に対してノードuのためのn+1ルータIDを含んでいます…v…(それは、リンク(_1に対するu)を表します)。, (u、v。) v_kの次のNRNLは報告された非葉のノードと、最後のnです--v_kの最初のNRLが報告された葉のノードである、v_kの(NRL+NRNL)は報告されません(どんなRNでも、そうしません)。
The M bit indicates whether or not link metrics are included in the message. If M = 1, then a 1-octet metric is included for each of the links (u,v_1),..., (u,v_n), following the last router ID.
リンク測定基準がメッセージに含まれているか否かに関係なく、ビットが示すM。 Mが1、当時のaと1八重奏メートル法であることで等しい、それぞれのリンク(_1に対するu)に含められています…, (u、v), 最後のルータIDに従います。
The D bit indicates whether or not implicit deletion is used, and must be set to 1 if and only if IMPLICIT_DELETION = 1.
Dビットを暗黙の削除が使用されているかどうかを示して、1に設定しなければならない、IMPLICIT_DELETION=1だけです。
The TOPOLOGY UPDATE message has the following three subtypes:
TOPOLOGY UPDATEメッセージには、以下の3血液型亜型があります:
FULL (TYPE = 5)
A FULL update (FULL, n, NRL, NRNL, u, v_1,..., v_n) reports that
the links (u,v_1),..., (u,v_n) belong to the sending router's
reported subtree RT, and that RT contains no other links with tail
u.
FULL(TYPE=5)A FULLアップデート(FULL、n、NRL、NRNL、_1、…、vに対するu)がそれを報告する、リンク(_1に対するu)…, (u、v) 送付ルータの報告された下位木RTのものてください。そうすれば、そのRTはテールuとの他のリンクを全く含んでいません。
ADD (TYPE = 6)
An ADD update (ADD, n, NRL, NRNL, u, v_1,..., v_n) reports that
the links (u,v_1),..., (u,v_n) have been added to the sending
router's reported subtree RT.
ADD、(TYPE=6)ADDアップデート(ADD、n、NRL、NRNL、_1、…、vに対するu)がそれを報告する、リンク(_1に対するu)…, (u、v) 送付ルータの報告された下位木RTに加えられてください。
DELETE (TYPE = 7)
A DELETE update (DELETE, n, NRL, NRNL, u, v_1,..., v_n) reports
that the links (u,v_1),..., (u,v_n) have been deleted from the
sending router's reported subtree RT.
DELETE(TYPE=7)A DELETEアップデート(DELETE、n、NRL、NRNL、_1、…、vに対するu)がそれを報告する、リンク(_1に対するu)…, (u、v) 送付ルータの報告された下位木RTから、削除されてください、そうした。
Ogier, et al. Experimental [Page 22] RFC 3684 TBRPF February 2004
オジェ、他 [22ページ]実験的なRFC3684TBRPF2004年2月
If n, NRL, or NRNL is larger than 255, then the long format of the TOPOLOGY UPDATE message is used, in which the first 4 octets of the normal format are replaced by the following 8 octets:
n、NRL、またはNRNLが255より大きいなら、TOPOLOGY UPDATEメッセージの長い形式は使用されています、正常な形式の最初の4つの八重奏がどれであるかで以下の8つの八重奏に取り替えて:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|D|1|0| TYPE | 0 | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NRL | NRNL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|D|1|0| タイプ| 0 | n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NRL| NRNL| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.3. Interface, Host, and Network Prefix Association Message Formats
8.3. 接頭語協会メッセージ・フォーマットを連結して、接待して、ネットワークでつないでください。
The INTERFACE ASSOCIATION (TYPE = 8) and HOST ASSOCIATION (TYPE = 9) messages have the following format:
INTERFACE ASSOCIATION(TYPE=8)とHOST ASSOCIATION(TYPE=9)メッセージには、以下の形式があります:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ST | 0 | TYPE | Reserved | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |st| 0 | タイプ| 予約されます。| n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The message body contains the router ID of the originating node, and n IP addresses of interfaces (TYPE = 8) or hosts (TYPE = 9) that are associated with the router ID. The ST field is defined below.
メッセージ本体は由来しているノードのルータID、およびルータIDに関連しているインタフェース(TYPE=8)かホスト(TYPE=9)のn IPアドレスを含んでいます。 ST分野は以下で定義されます。
The NETWORK PREFIX ASSOCIATION message (TYPE = 10) has the following format:
NETWORK PREFIX ASSOCIATIONメッセージ(TYPE=10)には、以下の形式があります:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ST | 0 | TYPE | Reserved | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength | Prefix byte 1 | Prefix byte 2 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | PrefixLength | Prefix byte 1 | Prefix byte 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |st| 0 | タイプ| 予約されます。| n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength| 接頭語バイト1| 接頭語バイト2| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | PrefixLength| 接頭語バイト1| 接頭語バイト2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ogier, et al. Experimental [Page 23] RFC 3684 TBRPF February 2004
オジェ、他 [23ページ]実験的なRFC3684TBRPF2004年2月
The message body contains the router ID of the originating node, and n network prefixes, each specified by a 1-octet prefix length followed immediately by the prefix, using the minimum number of whole octets required. To minimize overhead, the prefix lengths and prefixes are NOT aligned along word boundaries.
メッセージ本体は由来しているノードのルータID、およびnネットワーク接頭語を含んでいます、とすぐ接頭語があとに続いた1八重奏の接頭語の長さに従って、それぞれが指定して、全体の八重奏の最小の数を使用するのが必要です。 オーバーヘッドを最小にするために、接頭語の長さと接頭語は語境界に沿って並べられません。
The INTERFACE ASSOCIATION, HOST ASSOCIATION, and NETWORK PREFIX ASSOCIATION messages each have the following three subtypes (similar to those for the TOPOLOGY UPDATE message):
INTERFACE ASSOCIATION、HOST ASSOCIATION、およびNETWORK PREFIX ASSOCIATIONメッセージには、それぞれ以下の3血液型亜型(TOPOLOGY UPDATEメッセージに、それらと同様の)があります:
FULL (ST = 0)
Indicates that this is a FULL update that includes all interface
addresses, host addresses, or network prefixes associated with the
given router ID.
FULL(ST=0)は、これが与えられたルータIDに関連しているすべてのインターフェース・アドレス、ホスト・アドレス、またはネットワーク接頭語を含んでいるFULLアップデートであることを示します。
ADD (ST = 1)
Indicates that the included IP addresses or network prefixes are
associated with the router ID, but may not include all such IP
addresses or network prefixes.
ADD(ST=1)は含まれているIPアドレスかネットワーク接頭語がルータIDに関連しているのを示しますが、そのようなすべてのIPアドレスかネットワーク接頭語を含まないかもしれません。
DELETE (ST = 2)
Indicates that the included IP addresses or network prefixes are
no longer associated with the router ID.
DELETE(ST=2)は、含まれているIPアドレスかネットワーク接頭語がもうルータIDに関連していないのを示します。
8.4. TBRPF Routing Operation
8.4. TBRPFルート設定操作
This section describes the operation of the TBRPF routing module. The operation is divided into the following subsections: periodic processing, updating the source tree and topology graph, updating the routing table, updating the reported node set, generating periodic updates, generating differential updates, processing topology updates, expiring topology information, optional reporting of redundant topology information, local topology changes, generating association messages, processing association messages, and non-relay operation. The operation is described in terms of procedures (e.g., Update_All), which may be executed periodically or in response to some event, and may be called by other procedures. In all procedures, node i is the node executing the procedure.
このセクションはTBRPFルーティングモジュールの操作について説明します。 操作は以下の小区分に分割されます: 周期的な処理、経路指定テーブルをアップデートして、ソース木とトポロジーグラフをアップデートして、報告されたノードをアップデートするのはセットしました、周期的なアップデートを発生させて、特異なアップデートを発生させて、処理トポロジーアップデート、トポロジー情報、余分なトポロジー情報の任意の報告を吐き出して、地方のトポロジー変化、協会メッセージ、処理協会メッセージ、および非リレー操作を発生させて。 操作は、手順(例えば、Update_All)で説明されて、他の手順で呼ばれるかもしれません。(手順は定期的かいくつかの出来事に対応して実行されるかもしれません)。 すべての手順で、ノードiは手順を実行するノードです。
8.4.1. Periodic Processing
8.4.1. 周期的な処理
Each node executes the procedure Update_All() periodically, at least once every DIFF_UPDATE_INTERVAL seconds, which is typically equal to HELLO_INTERVAL. This procedure is defined as follows:
各ノードは定期的に、少なくともかつてのあらゆるDIFF_UPDATE_INTERVALが後援する手順Update_All()を実行します。(All()はHELLO_INTERVALと通常等しいです)。 この手順は以下の通り定義されます:
Ogier, et al. Experimental [Page 24] RFC 3684 TBRPF February 2004
オジェ、他 [24ページ]実験的なRFC3684TBRPF2004年2月
Update_All()
1. For each interface I, create empty message list msg_list(I).
2. For each interface I, generate a HELLO message for
interface I and add it to msg_list(I).
3. Expire_Links().
4. Update_Source_Tree().
5. Update_Routing_Table().
6. If REPORT_FULL_TREE = 0, execute Update_RN(); otherwise (the
full source tree is reported) Update_RN_Simple().
7. If current_time >= next_periodic:
7.1. Generate_Periodic_Update().
7.2. Set next_periodic = current_time + PER_UPDATE_INTERVAL.
8. Else, Generate_Diff_Update().
9. Generate_Association_Messages().
10. For each interface I, send the msg_list(I) on interface I.
11. Set old_T = T and old_RN = RN.
_すべての()1をアップデートしてください。 各インタフェースIに関しては、空のメッセージリストmsg_リスト(I)を作成してください。 2. 各インタフェースIに関しては、インタフェースIへのHELLOメッセージを発生させてください、そして、msg_リスト(I)にそれを追加してください。 3. _リンク()を吐き出してください。 4. _ソース_木()をアップデートしてください。 5. _ルート設定_テーブル()をアップデートしてください。 6. REPORT_FULL_TREE=0であるなら、Update_RN()を実行してください。 さもなければ(完全なソース木は報告される)、_RN_Simple()をアップデートしてください。 7. 現在の_時間>が次の_と周期的に等しいなら: 7.1. _周期的な_アップデート()を発生させてください。 7.2. _次の_周期的な=電流_時間+PER UPDATE_INTERVALを設定してください。 8. ほかに、_デフ_アップデート()を発生させてください。 9. _協会_メッセージ()を発生させてください。 10. 各インタフェースIに関しては、msg_リスト(I)をインタフェースI.11に送ってください。 古い_T=Tと古い_Rn=Rnを設定してください。
8.4.2. Updating the Source Tree and Topology Graph
8.4.2. ソース木とトポロジーグラフをアップデートします。
The procedure Update_Source_Tree() is a variant of Dijkstra's algorithm, which is called periodically and in response to topology changes, to update the source tree T and the topology graph TG. This algorithm computes shortest paths subject to two link cost penalties. The penalty NON_REPORT_PENALTY is added to the cost of links (u,v) that are not currently reported by the parent p(u) so that, whenever possible, a link (u,v) is included in T only if it is currently reported by the parent. To allow immediate rerouting when p(u) changes, it may be necessary to temporarily use a link (u,v) that is not currently reported by the new parent. The penalty NON_TREE_PENALTY is added to the cost of links (u,v) that are not currently in T, to reduce the number of changes to T. When there exist multiple paths of equal cost to a given node, router ID is used to break ties.
手順Update_Source_Tree()はダイクストラのアルゴリズムの異形です。(それは、ソース木TとトポロジーグラフTGをアップデートするために定期的でトポロジー変化に対応して呼ばれます)。 このアルゴリズムは2つのリンク費用刑罰を条件として最短パスを計算します。 ペナルティNON_REPORT_PENALTYが現在親p(u)によって報告されないリンク(u、v)の費用に加えられるので、可能であるときはいつも、それが現在親によって報告される場合にだけ、リンク(u、v)はTに含まれています。 p(u)が変化するとき、即座のコースを変更することを許すために、一時現在新しい親によって報告されないリンク(u、v)を使用するのが必要であるかもしれません。 ペナルティNON_TREE_PENALTYは現在、Tにないリンク(u、v)の費用に加えられて、T.Whenへの変化の数を減少させるために、与えられたノードへの等しい費用の複数の経路が存在していて、ルータIDは結びつきを壊すのに使用されます。
The algorithm is defined as follows (where node i is the node executing the procedure):
アルゴリズムは以下の通り(ノードiが手順を実行するノードであるところ)定義されます:
Update_Source_Tree()
1. For each node v in TT, set d(v) = INFINITY, pred(v) = NULL,
old_p(v) = p(v), and p(v) = NULL.
_ソース_木()1をアップデートしてください。 TTの各ノードvに、d(v)=INFINITY、pred(v)=NULL、古い_p(v)=p(v)、およびp(v)=NULLを設定してください。
2. Set d(i) = 0, p(i) = i, pred(i) = i.
2. d(i)=0を設定してください、そして、p(i)はiと等しく、pred(i)はiと等しいです。
3. Set S = {i}. (S is the set of labeled nodes.)
3. セットSはiと等しいです。 (Sはラベルされたノードのセットです。)
4. For each node j in N, set d(j) = c(i,j), pred(j) = i,
and p(j) = j. (If USE_METRICS = 0, then all link costs
c(i,j) are 1.)
4. pred(j)はiと等しいです、そして、Nの各ノードjに、d(j)=c(i、j)を設定してください、そして、p(j)はjと等しいです。 (USE_METRICS=0であるなら、すべてのリンクコストc(i、j)が1です。)
Ogier, et al. Experimental [Page 25] RFC 3684 TBRPF February 2004
オジェ、他 [25ページ]実験的なRFC3684TBRPF2004年2月
5. While there exists an unlabeled node u in TT such that
d(u) < INFINITY:
5.1. Let u be an unlabeled node in TT with minimum d(u).
(A heap should be used to find u efficiently.)
5.2. Add u to S (u becomes labeled).
5.3. If p(u) is not equal to old_p(u) (parent has changed):
5.3.1. For each link (u,v) in TG with tail u, if
reported(u,v) = 1, set reported(u,v) = 0 and set
nr_expire(u,v) = current_time + PER_UPDATE_INTERVAL.
5.3.2. If p(u) is in r(u) (p(u) is reporting u):
5.3.2.1. Set tg_expire(u) = rt_expire(p(u),u).
5.3.2.2. If p(u) = u (u is a neighbor), remove all links
(u,v) with tail u from TG.
5.3.2.3. For each link (u,v) with p(u) in r(u,v):
5.3.2.3.1. Add (u,v) to TG and set reported(u,v) = 1.
5.3.2.3.2. Set metric(u,v) = metric(p(u),u,v).
If USE_METRICS=1, set c(u,v)=metric(u,v).
5.4. For each node v such that (u,v) is in TG:
5.4.1. If reported(u,v) = 0,
set cost = c(u,v) + NON_REPORT_PENALTY.
(This penalizes (u,v) if not reported by p(u).)
5.4.2. Else, if p(u) = u AND u is not in r(v),
set cost = c(u,v) + NON_REPORT_PENALTY.
(This penalizes (u,v) if u is a neighbor and is not
reporting v.)
5.4.3. If (u,v) is not in old_T and p(u) != u,
set cost = cost + NON_TREE_PENALTY.
5.4.4. If (d(u) + cost, u) is lexicographically less
than (d(v), pred(v)), set d(v) = d(u) + c(u,v),
pred(v) = u, and p(v) = p(u).
5. ラベルされていないノードuが中に存在する、TT、そのようなもの、そのd(u)<INFINITY: 5.1. uがTTの最小のd(u)があるラベルされていないノードであることをさせてください。 (山は効率的にuを見つけるのに使用されるべきです。) 5.2. Sにuを加えてください(uはラベルされるようになります)。 5.3. p(u)が古い_p(u)と等しくないなら(親は変化しました): 5.3.1. テールuがあるTGの各リンク(u、v)に関しては、報告された(u、v)=1であるなら、セットは、= 0とセットnr_が_=現在の_時間+PER UPDATE_INTERVALを吐き出す(u、v)と報告しました(u、v)。 5.3.2. p(u)がr(u)にあるなら(p(u)はuを報告しています): 5.3.2.1. セットtg_は(u) _が吐き出す=rt(p(u)、u)を吐き出します。 5.3.2.2. p(u)がuと等しいなら(uは隣人です)、TGからテールuとのすべてのリンク(u、v)を取り外してください。 5.3.2.3. それぞれに関しては、r(u、v)で(u、v)をp(u)にリンクしてください: 5.3.2.3.1. (u、v)をTGに加えてください、そして、報告された(u、v)=1を設定してください。 5.3.2.3.2. メートル法で(p(u)、u、v)メートル法(u、v)の=を設定してください。 USE_METRICS=1であるなら、メートル法で(u、v)c(u、v)=を設定してください。 5.4. 各ノード対そのようなものに関して、それ(u、v)はTGにいます: 5.4.1. 報告された(u、v)=0であるなら、+ 費用=c(u、v)NON_REPORT_PENALTYを設定してください。 (これは、p(u)で罰したか(u、v)、または報告しました。) 5.4.2. p(u)=uとuがr(v)にないなら、ほかに、+ 費用=c(u、v)NON_REPORT_PENALTYを設定してください。 (uが隣人であり、v.を報告していないなら、これは(u、v)を罰します) 5.4.3. (u、v)が古い_Tになくて、p(u)!がuと等しいなら、費用=費用+NON_TREE_PENALTYを設定してください。 5.4.4. (d(u)+費用、u)がそれほど辞書編集でない、(d(v)、pred(v))、セットd(v)はd(u)+c(u、v)と等しいです、pred(v)=u、p(v)はp(u)と等しいです。
6. Update the source tree T as follows:
6.1. Remove all links from T.
6.2. For each node u other than i such that pred(u) is not
NULL, add the link (pred(u), u) to T.
6. 以下のソース木Tをアップデートしてください: 6.1. T.6.2からすべてのリンクを取り外してください。 iを除いた各ノードuに関しては、pred(u)がNULLでないように、リンク(pred(u)、u)をTに加えてください。
8.4.3. Updating the Routing Table
8.4.3. 経路指定テーブルをアップデートします。
The routing table is updated following any change to the source tree or the association tables (interface table, host table, or network prefix table). The routing table is updated according to procedure Update_Routing_Table(), which is defined as follows:
ソース木か協会テーブル(インタフェーステーブル、ホストテーブル、またはネットワーク接頭語テーブル)へのどんな変化にも続いて、経路指定テーブルをアップデートします。 _手順Update_ルート設定Table()によると、経路指定テーブルをアップデートします(以下の通り定義されます):
Update_Routing_Table()
アップデート_ルート設定_テーブル()
1. Remove all tuples from the routing table.
1. 経路指定テーブルからすべてのtuplesを取り外してください。
Ogier, et al. Experimental [Page 26] RFC 3684 TBRPF February 2004
オジェ、他 [26ページ]実験的なRFC3684TBRPF2004年2月
2. For each node u in TT (other than this node) such that p(u) is
not NULL, add the tuple (rt_dest, rt_next, rt_dist, rt_if_id)
to the routing table, where:
rt_dest = u,
rt_if_id = local_if(p(u)),
rt_next = nbr_if(p(u)),
rt_dist = d(u).
2. TT(このノードを除いた)の各ノードuに関しては、p(u)がNULLでないように、tuple(__イドであるならdestに、rtに_次に、rtに_distに、rtに_をrtする)を経路指定テーブルに加えてください、どこ: rt_destがuと等しく、rtが__イドであるなら地方の_と等しい、(nbr p(u))、次のrt_=_、(p(u))、rt_distはd(u)と等しいです。
3. For each tuple (if_addr, if_rid, if_expire) in the interface
table, if a routing table entry (rt_dest, rt_next, rt_dist,
rt_if_id) exists such that rt_dest = if_rid, add the tuple
(if_addr, rt_next, rt_dist, rt_if_id) to the routing table.
3. インタフェーステーブルの各tuple(_addrであるなら、_排除しているなら、_であるなら期限が切れる)に関しては、経路指定テーブルエントリー(__イドであるならdestに、rtに_次に、rtに_distに、rtに_をrtする)が存在するなら、rt_destが_であるなら等しいそのようなものが取り除かれて、tuple(_addrであるなら、rt_次、rt_distは__イドであるならrtされる)を経路指定テーブルに加えてください。
4. For each tuple (h_addr, h_rid, h_expire) in the host table, if
there exists a routing table entry (rt_dest, rt_next, rt_dist,
rt_if_id) such that rt_dest = h_rid, add the tuple (h_addr,
rt_next, rt_dist, rt_if_id) to the routing table, unless an
entry already exists with the same value for h_addr and a
lexicographically smaller value for (rt_dist, rt_dest).
4. ホストテーブルの各tuple(addrに、h_が取り除いたh_、h_は期限が切れる)に関しては、そのようなhそのrt_dest=_が取り除いた経路指定テーブルエントリー(__イドであるならdestに、rtに_次に、rtに_distに、rtに_をrtする)が存在するなら、tuple(h_addr、rt_次、rt_distは__イドであるならrtされる)を経路指定テーブルに加えてください、エントリーがh_addrのための同じ値と(rt_dist、rt_dest)のための辞書編集により小さい値で既に存在していない場合。
5. For each tuple (net_prefix, net_length, net_rid, net_expire)
in the network prefix table, if there exists a routing table
entry (rt_dest, rt_next, rt_dist, rt_if_id) such that
rt_dest = net_rid, add the tuple (net_prefix/net_length,
rt_next, rt_dist, rt_if_id) to the routing table, unless an
entry already exists with the same value for
net_prefix/net_length and a lexicographically smaller value
for (rt_dist, rt_dest).
5. ネットワーク接頭語テーブルの各tuple(ネットの_接頭語、ネットの_の長さ、ネットの_排除していて、ネットの_は期限が切れる)に関しては、そのようなネットのそのrt_dest=_が取り除いた経路指定テーブルエントリー(__イドであるならdestに、rtに_次に、rtに_distに、rtに_をrtする)が存在するなら、tuple(ネットの_接頭語/ネットの_の長さ、rt_次、rt_distは__イドであるならrtされる)を経路指定テーブルに加えてください、エントリーがネットの_接頭語/ネットの_の長さのための同じ値と(rt_dist、rt_dest)のための辞書編集により小さい値で既に存在していない場合。
8.4.4. Updating the Reported Node Set
8.4.4. 報告されたノードをアップデートするのはセットしました。
Recall that the reported subtree RT is defined to be the set of links (u,v) in T such that u is in the reported node set RN. Each node updates its RN immediately before generating periodic or differential topology updates.
uが報告されたノードセットRNにあるように、報告された下位木RTがTのリンク(u、v)のセットになるように定義されたと思い出してください。 周期的であるか特異なトポロジーアップデートを発生させる直前各ノードはRNをアップデートします。
If REPORT_FULL_TREE = 1 (so that a node reports its entire source tree), then RN simply consists of all reachable nodes, i.e., all nodes u such that pred(u) is not NULL. The procedure that computes RN in this manner is called Update_RN_Simple(). The rest of this section describes how RN is computed assuming REPORT_FULL_TREE = 0.
REPORT_FULL_TREE=1である(ノードが全体のソース木を報告するように)なら、RNはすべての届いているノードから単に成ります、すなわちすべてのノードuによって、pred(u)はNULLではありません。 RNを計算する手順はこの様にUpdate_RN_Simple()と呼ばれます。 このセクションの残りはREPORT_FULL_がTREE=0であると仮定しながらRNがどう計算されるかを説明します。
A node first determines which of its neighbors belong to RN. Node i includes a neighbor j in RN if and only if node i determines that one of its neighbors may select i to be its next hop on its shortest path to j. To make this determination, node i computes the shortest paths, up to 2 hops, from each neighbor to each other neighbor, using only neighbors (or node i itself) as an intermediate node, and using
ノードは、最初に、隣人のどれがRNに属すかを決定します。 そして、ノードiがRNに隣人jを含んでいる、ノードiが、隣人のひとりが、iがjへの最短パスの次のホップであることを選択するかもしれないことを決定する場合にだけ。 この決断をするように、ノードiは最短パスを計算します、最大2つのホップ、各隣人から互いになりまでの隣人、中間的ノード、および使用としての隣人だけ(または、ノードi自体)を使用して
Ogier, et al. Experimental [Page 27] RFC 3684 TBRPF February 2004
オジェ、他 [27ページ]実験的なRFC3684TBRPF2004年2月
relay priority and router ID to break ties. If a link metric is used, then shortest paths are computed with respect to the link metric; otherwise min-hop paths are computed.
優先権とルータIDをリレーして、結びつきを壊してください。 リンクであるなら、メートル法であることは、中古の、そして、当時の最短パスがリンクに関してメートル法で計算されるということです。 さもなければ、分ホップ経路は計算されます。
After a node determines which neighbors are in RN, each node u (other than node i) in the topology table is included in RN if and only if the next hop p(u) to u is in RN. Equivalently, node u is included in RN if and only if u is in the subtree of T rooted at some neighbor j that is in RN. Thus, the reported subtree RT includes the subtrees of T that are rooted at neighbors in RN. Node i also includes itself in RN; thus RT also includes all local links (i,j) to neighbors j.
そして、どの隣人がRNにいるかを決定した後にトポロジーテーブルの各ノードu(ノードiを除いた)がRNに含まれている、uへの次のホップp(u)がRNにある場合にだけ。 同等に、ノードuがRNに含まれている、uである場合にだけ、Tの下位木がRNにいる隣人jに根づかせたコネはそうです。 したがって、報告された下位木RTはRNの隣人に根づくTの下位木を含んでいます。 また、ノードiはRNにそれ自体を含んでいます。 したがって、また、RTは隣人jへのすべての地方のリンク(i、j)を含んでいます。
The precise procedure for updating RN is defined as follows:
RNをアップデートするための正確な手順は以下の通り定義されます:
Update_RN()
1. Set RN = empty.
2. For each neighbor s in N such that s is in r(s), i.e.,
such that s is reporting itself:
(Initialize to run Dijkstra for source s, for 2 hops.)
2.1. For each node j in N+{i}, set dist(j) = INFINITY and
par(j) = NULL.
2.2. Set dist(s) = 0 and par(s) = s.
2.3. For each node j in N+{i} such that (s,j) is in TG:
2.3.1. Set dist(j) = metric(s,j), par(j) = j.
2.3.2. For each node k in N such that (j,k) is in TG:
2.3.2.1. Set cost = metric(j,k).
2.3.2.2. If (dist(j) + cost, nbr_pri(j), j)
is lexicographically less than
(dist(k), nbr_pri(par(k)), par(k)),
set dist(k) = dist(j) + cost and par(k) = j.
2.4. For each neighbor j in N, add j to RN if par(j) = i.
3. Add i to RN. (Node i is always in RN.)
4. For each node u in the topology table, add u to RN if p(u)
is in RN.
_Rn()1をアップデートしてください。 セットRN=は空になります。 2. Nの各隣人sにとって、sがr(s)にあって、すなわち、そのようなものがそのsであるようにものは報告自体です: (ソースs、2つのホップのためにダイクストラを走行に初期化してください。) 2.1. N+iの各ノードjに関しては、セットdist(j)はINFINITYと等しいです、そして、平価(j)はNULLと等しいです。 2.2. dist(s)=0と平価=sを設定してください。 2.3. N+iの各ノードj、(s、j)がTGにあるようなもの: 2.3.1. メートル法で(s、j)dist(j)=を設定してください、そして、平価(j)はjと等しいです。 2.3.2. Nの各ノードk、(j、k)がTGにあるようなもの: 2.3.2.1. メートル法で(j、k)費用=を設定してください。 2.3.2.2. dist(k)、nbr_はpriされます。(dist(j)+費用、nbr_pri(j)、j)がそれほど辞書編集でない、((平価(k))(平価(k)))はdist(k)=dist(j)+費用を設定して、平価(k)はjと等しいです。 2.4. Nの各隣人jに関しては、平価(j)がiと等しいなら、RNにjを加えてください。 3. RNにiを加えてください。 (ノードiがいつもRNにあります。) 4. トポロジーテーブルの各ノードuに関しては、p(u)がRNにあるなら、RNにuを加えてください。
In some cases it may be desirable to limit the radius (number of hops) that topology information is propagated. Since each TBRPF packet is sent only to immediate (1-hop) neighbors, this cannot be achieved by using a time-to-live field. Instead, the propagation of topology information can be limited to a radius of K hops by limiting RN (at all nodes) to include only nodes that are at most K-1 hops away. Assuming min-hop routing is used, so that d(u) is the number of hops to node u, this can be done by modifying Step 4 of Update_RN() as follows:
いくつかの場合、トポロジー情報が伝播されるのは、半径(ホップの数)を制限するのにおいて望ましいかもしれません。 (1ホップ)の即座の隣人だけにそれぞれのTBRPFパケットを送るので、生きる時間分野を使用することによって、これを達成できません。 代わりに、高々遠くのK-1ホップである唯一のノードを含むように、RN(すべてのノードの)を制限することによって、トポロジー情報の伝播をKホップの半径に制限できます。 分ホップルーティングが使用されているのでd(u)がノードuへのホップの数であると仮定する場合、以下のUpdate_RN()のStep4を変更することによって、これができます:
4. For each node u in the topology table, add u to RN if p(u)
is in RN and d(u) <= K-1.
4. トポロジーテーブルの各ノードuに関しては、p(u)がRNにあって、d(u)<がK-1と等しいなら、RNにuを加えてください。
Ogier, et al. Experimental [Page 28] RFC 3684 TBRPF February 2004
オジェ、他 [28ページ]実験的なRFC3684TBRPF2004年2月
8.4.5. Generating Periodic Updates
8.4.5. 周期的なアップデートを発生させます。
Every PER_UPDATE_INTERVAL seconds, each node generates and transmits, on all interfaces, a set of FULL TOPOLOGY UPDATE messages (one message for each node in RN that is not a leaf of T), which describes the reported subtree RT. Whenever possible, these messages are included in a single packet, in order to minimize the number of control packets transmitted.
INTERVALが後援するあらゆるPER_UPDATE_、各ノードはすべてのインタフェースで1セットのFULL TOPOLOGY UPDATEメッセージ(Tの葉でないRNの各ノードへのあるメッセージ)を発生して、送ります。(メッセージは報告された下位木RTについて説明します)。 可能であるときはいつも、これらのメッセージは、パケットが送ったコントロールの数を最小にするために単一のパケットに含まれています。
Each topology update message contains the router IDs for n+1 nodes u, v_1,...,v_n, which represent the n links (u,v_1),..., (u,v_n). The n head nodes v_1,..., v_n are divided into three lists in order to convey additional information and thus reduce the number of messages that must be generated. In particular, the first NRL head nodes are leaves of T, thus avoiding the need to generate separate topology update messages for leaf nodes u. Similarly, the last n-(NRL+NRNL) head nodes are not in RN, thus avoiding the need to generate separate topology update messages for nodes u that have been removed from RN.
それぞれのトポロジーアップデートメッセージは_1に対してn+1のノードuのためのルータIDを含んでいます…v…(それは、nリンク(_1に対するu)を表します)。, (u、v。) nは_1に対してノードの上に立ちます…, vは3つのリストに割られて、追加情報を伝えて、その結果、発生しなければならないメッセージの数を減少させます。 最初のNRLヘッドノードは特に、Tの葉です、その結果、葉のノードuへの別々のトポロジーアップデートメッセージを発生させる必要性を避けます。 同様に、最後のn(NRL+NRNL)ヘッドノードがRNにありません、その結果、RNから取り除かれたノードuへの別々のトポロジーアップデートメッセージを発生させる必要性を避けます。
Periodic update messages are generated according to procedure Generate_Periodic_Update(), defined as follows (where node i is the node executing the procedure):
周期的なアップデートメッセージは、以下の通り(ノードiが手順を実行するノードであるところ)発生して、手順Generate_Periodic_Update()によると、定義されています:
Generate_Periodic_Update()
For each node u in RN (including node i) that is not a leaf of T,
add the update (FULL, n, NRL, NRNL, u, v_1,..., v_n)
to msg_list(I) for each interface I, where:
Tの葉でないRN(ノードiを含んでいる)の各ノードuのために_Periodic_Update()を発生させてください、そして、各インタフェースIのために、アップデート(FULL、n、NRL、NRNL、_1、…、vに対するu)をmsg_リスト(I)に追加してください、どこ:
(a) v_1,..., v_n are the nodes v such that (u,v) is in T,
the first NRL of these are nodes in RN that are leaves of T,
the next NRNL of these are nodes in RN that are not leaves
of T, and the last n-(NRL+NRNL) of these are not in RN.
(a) _1に対して…, (u、v)がvがノードvであるので、Tにあります、そして、これらの最初のNRLはTの葉であるRNのノードです、そして、これらの次のNRNLはTの葉でないRNのノードです、そして、これらの最後のn(NRL+NRNL)はRNにありません。
(b) If USE_METRICS = 1, then the M (metrics) bit is set to 1 and
the link metrics metric(u,v_1),..., metric(u,v_n) are
included in the message.
(b) USE_METRICS=1であるなら、M(測定基準)ビットは1とリンク測定基準にメートル法で(_1に対するu)設定されます…, メートル法であることは、含まれているコネ(u、v)です。メッセージ。
8.4.6. Generating Differential Updates
8.4.6. 特異なアップデートを発生させます。
Every DIFF_UPDATE_INTERVAL seconds, if it is not time to generate a periodic update, and if RT has changed since the last time a topology update was generated, a set of TOPOLOGY UPDATE messages describing the changes to RT is generated and transmitted on all interfaces. These messages are constructed according to procedure Generate_Differential_Update(), defined as follows:
周期的なアップデートをもう発生させるべき時間でなく、トポロジーアップデートが最後の時間発生して以来RTが変化しているならINTERVALが後援するあらゆるDIFF_UPDATE_、変化をRTに説明する1セットのTOPOLOGY UPDATEメッセージが、すべてのインタフェースで発生して、送られます。 これらのメッセージは、以下の通り組み立てられて、手順Generate_Differential_Update()によると、定義されています:
Ogier, et al. Experimental [Page 29] RFC 3684 TBRPF February 2004
オジェ、他 [29ページ]実験的なRFC3684TBRPF2004年2月
Generate_Differential_Update()
For each node u in RN:
1. If u is not in old_RN (u was added to RN) and is not a leaf
of T, add the update (FULL, n, NRL, NRNL, u, v_1,..., v_n)
to msg_list(I) for each I, where:
(a) v_1,..., v_n, NRL, and NRNL are defined as above for
periodic updates.
(b) If USE_METRICS = 1, then the M (metrics) bit is set to 1
and the link metrics metric(u,v_1),..., metric(u,v_n)
are included in the message.
RNの各ノードuのために_Differential_Update()を発生させてください: 1. uが老人_RN(uはRNに加えられた)になくて、またTの葉でないなら、各Iのために、アップデート(FULL、n、NRL、NRNL、_1、…、vに対するu)をmsg_リスト(I)に追加してください、どこ: (a) _1に対して…, v、NRL、およびNRNLは周期的なアップデートのために同じくらい上で定義されます。 (b) USE_METRICS=1であるなら、M(測定基準)ビットは1とリンク測定基準にメートル法で(_1に対するu)設定されます…, メートル法であることは、含まれているコネ(u、v)です。メッセージ。
2. Else, if u is in old_RN and is not a leaf of T:
2.1. Let v_1,..., v_n be the nodes v such that (u,v) is in T
AND at least one of the following 3 conditions holds:
(a) (u,v) is not in old_T, or
(b) v is in old_RN but not in RN, or
(c) v is a leaf and is in RN but not in old_RN.
2.2. If this set of nodes is nonempty, add the update
(ADD, n, NRL, NRNL, u, v_1,..., v_n) to msg_list(I) for
each interface I, where:
(a) NRL and NRNL are defined as above.
(b) If USE_METRICS = 1, then the M (metrics) bit is
set to 1 and the link metrics metric(u,v_1),...,
metric(u,v_n) are included in the message.
2. ほかに、uが老人_RNにあって、aでないならTにページをめくらせてください: 2.1. v_1をさせてください…, v、(u、v)がTにあって、少なくとも以下の3つの条件の1つが持ちこたえるためのノードvになってください: (a) (u、v) (c) T、または(b)vは古い_に、古い_RNにありますが、RNにあるというわけではありませんし、vが葉であるということでなく、RNにありますが、古い_RNにあるというわけではありません。 2.2. このセットのノードがnonemptyであるなら、各インタフェースIのために、アップデート(ADD、n、NRL、NRNL、_1、…、vに対するu)をmsg_リスト(I)に追加してください、どこ: (a) NRLとNRNLは同じくらい上で定義されます。 (b) USE_METRICS=1であるなら、M(測定基準)ビットは1とリンク測定基準にメートル法で(_1に対するu)設定されます…, メートル法であることは、含まれているコネ(u、v)です。メッセージ。
3. If u is in old_RN:
3.1. Let v_1,..., v_n be the nodes v such that (u,v) is in
old_T but not in TG, and either IMPLICIT_DELETION = 0
or pred(v) is not in RN (or is NULL).
(If IMPLICIT_DELETION = 1 and pred(v) is in RN, then
the deletion of (u,v) is implied by an ADD update for
another link (w,v).)
3.2. If this set of nodes is nonempty, add the update
(DELETE, n, u, v_1,..., v_n) to msg_list(I) for each I.
3. uが古い_RNにあるなら: 3.1. v_1をさせてください…, v、(u、v)は古い_Tにありますが、TGにあるというわけではなくて、IMPLICIT_DELETION=0かpred(v)のどちらかはRN(または、NULLである)にないためのノードvになってください。 (1とpred(v)がいるIMPLICIT_DELETION=であるなら、RN、当時の(u、v)の削除は別のリンク(w、v)のためのADDアップデートで含意されます。) 3.2. このセットのノードがnonemptyであるなら、各Iのために、アップデート(DELETE、n、_1、…、vに対するu)をmsg_リスト(I)に追加してください。
8.4.7. Processing Topology Updates
8.4.7. 処理トポロジーアップデート
When a packet containing a list (msg_list) of TOPOLOGY UPDATE messages is received from node j, the list is processed according to the procedure Process_Updates(j, msg_list), defined as follows. In particular, this procedure updates TT, TG, and the reporting neighbor lists r(u) and r(u,v). If any link in T has been deleted from TG, then Update_Source_Tree() and Update_Routing_Table() are called to provide immediate rerouting.
ノードjからTOPOLOGY UPDATEメッセージのリスト(msg_リスト)を含むパケットを受け取るとき、(j、msg_リスト)が以下の通り定義した手順Process_Updatesによると、リストを処理します。 特に、この手順はTT、TG、および報告している隣人リストr(u)とr(u、v)をアップデートします。 _TのどんなリンクもTGから削除されて、次に、Update_Sourceがルート設定_Table()が即座のコースを変更することを提供するために呼ばれるTree()とUpdate_であるなら。
Process_Updates(j, msg_list)
1. For each update = (subtype, n, NRL, NRNL, u, v_1,..., v_n)
in msg_list:
_Updates(j、msg_リスト)1を処理してください。 各アップデート=のために、msg_の(「副-タイプ」、n、NRL、NRNL、_1、…、vに対するu)は記載します:
Ogier, et al. Experimental [Page 30] RFC 3684 TBRPF February 2004
オジェ、他 [30ページ]実験的なRFC3684TBRPF2004年2月
1.1. Create an entry for u in TT if it does not exist.
1.2. If subtype = FULL, Process_Full_Update(j, update).
1.3. If subtype = ADD, Process_Add_Update(j, update).
1.4. If subtype = DELETE, Process_Delete_Update(j, update).
2. If there exists any link in T that is not in TG:
2.1. Update_Source_Tree().
2.2. Update_Routing_Table().
1.1. 存在しないなら、TTでuのためのエントリーを作成してください。 1.2. 「副-タイプ」がFULLと等しいなら、Process_Full_Updateです(j、アップデート)。 1.3. 「副-タイプ」がADDと等しいなら、Process_Add_Updateです(j、アップデート)。 1.4. 「副-タイプ」がDELETEと等しいなら、Process_Delete_Updateです(j、アップデート)。 2. いずれか存在するなら、TGにないTでリンクしてください: 2.1. _ソース_木()をアップデートしてください。 2.2. _ルート設定_テーブル()をアップデートしてください。
Process_Full_Update(j, update)
1. Add j to r(u).
2. Set rt_expire(j,u) = current_time + TOP_HOLD_TIME.
3. For each link (u,v) s.t. j is in r(u,v):
3.1. Remove j from r(u,v).
3.2. If pred(j,v) = u, set pred(j,v) = NULL.
4. If j = p(u) OR p(u) = NULL:
4.1. Set tg_expire(u) = current_time + TOP_HOLD_TIME.
4.2. For each v s.t. (u,v) is in TG,
If reported(u,v) = 1, remove (u,v) from TG.
5. Process_Add_Update(j, update).
_Full_Update(j、アップデート)1を処理してください。 r(u)にjを加えてください。 2. セットrt_は(j、u)=電流_時間+TOP_HOLD_タイム誌を吐き出します。 3. 各リンク(u、v)に関しては、s.t.jがr(u、v)にあります: 3.1. r(u、v)からのjを取り除いてください。 3.2. pred(j、v)がuと等しいなら、pred(j、v)=NULLを設定してください。 4. jがp(u)と等しいなら、OR p(u)はNULLと等しいです: 4.1. セットtg_は(u) =電流_時間+TOP_HOLD_タイム誌を吐き出します。 4.2. それぞれのv s.tのために。 (u、v) TG(報告されたIf(u、v)=1)がTGから取り除く(u、v)コネはそうですか? 5. _Add_Update(j、アップデート)を処理してください。
Process_Add_Update(j, update)
For m = 1,..., n:
((u,v_m) is the mth link in update.)
1. Let v = v_m.
2. Create an entry for v in TT if it does not exist.
3. Add j to r(u,v).
4. If j = p(u) OR p(u) = NULL:
4.1. Add (u,v) to TG.
4.2. Set reported(u,v) = 1.
5. If the M (metrics) bit in update is 1:
5.1. Set metric(j,u,v) to the m-th metric in the update.
5.2. If j = p(u) OR p(u) = NULL:
5.2.1. Set metric(u,v) = metric(j,u,v).
5.2.2. If USE_METRICS = 1, set c(u,v) = metric(u,v).
6. If the D (implicit deletion) bit in update is 1:
6.1. Set w = pred(j,v).
6.2. If (w != NULL AND w != u):
6.2.1. Remove j from r(w,v).
6.2.2. If j = p(w), remove (w,v) from TG.
7. Set pred(j,v) = u. (Set new predecessor.)
8. If m <= NRL (v = v_m is a reported leaf):
8.1. Set leaf_update = (FULL, 0, 0, 0, v).
8.2. Process_Full_Update(j, leaf_update).
9. If m > NRL + NRNL (v = v_m is not reported by j):
9.1. Remove j from r(v).
9.2. Set rt_expire(j,v) = 0.
9.3. For each node w s.t. j is in r(v,w),
remove j from r(v,w).
_m=1のためのAdd_Update(j、アップデート)を処理してください…, n: ((_mに対するu)はアップデートでmthリンクです。) 1. v=対_mをさせてください。 2. 存在しないなら、TTでvのためのエントリーを作成してください。 3. r(u、v)にjを加えてください。 4. jがp(u)と等しいなら、OR p(u)はNULLと等しいです: 4.1. (u、v)をTGに加えてください。 4.2. 報告された(u、v)=1を設定してください。 5. アップデートにおけるM(測定基準)ビットが1であるなら: 5.1. メートル法で(j、u、v)セットしてください、m、-、アップデートでは、第メートル法です。 5.2. jがp(u)と等しいなら、OR p(u)はNULLと等しいです: 5.2.1. メートル法で(j、u、v)メートル法(u、v)の=を設定してください。 5.2.2. USE_METRICS=1であるなら、メートル法で(u、v)c(u、v)=を設定してください。 6. アップデートにおけるD(暗黙の削除)ビットが1であるなら: 6.1. セットwはpred(j、v)と等しいです。 6.2. (w!=NULL AND w!=u)であるなら: 6.2.1. r(w、v)からのjを取り除いてください。 6.2.2. jがp(w)と等しいなら、TGから(w、v)を取り除いてください。 7. pred(j、v)=uを設定してください。 (新しい前任者を設定してください。) 8. m<がNRLと等しいなら(v=対_mは報告された葉です): 8.1. 葉_アップデート=(FULL、0、0、0、v)を設定してください。 8.2. _Full_Update(j、葉の_アップデート)を処理してください。 9. m>NRL+NRNL(v=対_mはjによって報告されない)であるなら: 9.1. r(v)からのjを取り除いてください。 9.2. セットrt_は(j、v)=0を吐き出します。 9.3. 各ノードwに関しては、s.t.jがr(v、w)にあって、r(v、w)からのjを取り除いてください。
Ogier, et al. Experimental [Page 31] RFC 3684 TBRPF February 2004
オジェ、他 [31ページ]実験的なRFC3684TBRPF2004年2月
9.4. If j = p(v), then for each node w s.t. (v,w) is in TG
and reported(v,w) = 1, set reported(v,w) = 0 and set
nr_expire(v,w) = current_time + PER_UPDATE_INTERVAL.
9.4. jがそして、それぞれのノードw s.tのためにp(v)と等しいなら。 (v、w) _現在の_TGと報告された(v、w)=1、報告された(v、w)=0とセットnr_が吐き出すセット(v、w)=時間+ PER UPDATE_INTERVALに、あります。
Process_Delete_Update(j, update)
For m = 1,..., n:
((u,v_m) is the mth link in update.)
1. Let v = v_m.
2. Remove j from r(u,v).
3. If pred(j,v) = u, set pred(j,v) = NULL.
4. If j = p(u), remove (u,v) from TG.
_m=1のためのDelete_Update(j、アップデート)を処理してください…, n: ((_mに対するu)はアップデートでmthリンクです。) 1. v=対_mをさせてください。 2. r(u、v)からのjを取り除いてください。 3. pred(j、v)がuと等しいなら、pred(j、v)=NULLを設定してください。 4. jがp(u)と等しいなら、TGから(u、v)を取り除いてください。
8.4.8. Expiring Topology Information
8.4.8. トポロジー情報を吐き出します。
Each node periodically checks for outdated topology information based on the expiration timers tg_expire(u), rt_expire(j,u), and nr_expire(u,v), and removes any expired entries from TG and from the lists r(u) and r(u,v). This is done according to the following procedure Expire_Links(), which is called periodically just before the source tree is updated.
各ノードがタイマtg_が吐き出す満了に基づいて、(u)、rt_が期限が切れるという時代遅れのトポロジー情報(j、u)がないかどうか定期的にチェックして、nr_はTGとリストr(u)とr(u、v)から(u、v)を吐き出して、どんな満期のエントリーも取り除きます。 以下の手順Expire_リンクス()によると、これをします。(ソース木をアップデートするすぐ前に定期的に()を呼びます)。
Expire_Links()
For each node u in TT other than node i:
1. If tg_expire(u) < current_time, then for each v s.t.
(u,v) is in TG, remove (u,v) from TG.
2. Else, for each v s.t. (u,v) is in TG,
if reported(u,v) = 0 AND nr_expire(u,v) < current_time,
remove (u,v) from TG.
3. For each node j in r(u), if rt_expire(j,u) < current_time:
3.1. Remove j from r(u).
3.2. For each link (u,v) s.t. j is in r(u,v),
remove j from r(u,v).
ノードi以外のTTの各ノードuのために_リンクス()を吐き出してください: 1. _tgであるなら、s.tに対して(u)そして、それぞれのための<の現在の_時間を吐き出してください。 (u、v) TGでは、TGから(u、v)を取り除いてください。 2. それぞれのv s.tにおいてほかです。 (u、v) 報告された(u、v)=0とnr_が<の現在の_時間を吐き出すなら(u、v)TGが(u、v)を取り除くコネはTGですか? 3. _r(u)の各ノードjに関しては、rtであるなら、<の現在の_時間を吐き出してください(j、u): 3.1. r(u)からのjを取り除いてください。 3.2. 各リンク(u、v)に関しては、s.t.jがr(u、v)にあって、r(u、v)からのjを取り除いてください。
In addition, the following cleanup steps SHOULD be executed periodically to remove unnecessary entries from the topology table TT. A link (u,v) should be removed from TT if it is not in TG and not in old_T. A node u should be removed from TT if all of the following conditions hold: r(u) is empty, r(w,u) is empty for all w, and no link of TG has u as either the head or the tail.
さらに、以下のクリーンアップはSHOULDを踏みます。定期的に実行されて、トポロジーテーブルTTから不要なエントリーを取り除いてください。 それが古い_Tにあるのではなく、TGにないなら、リンク(u、v)はTTから取り外されるべきです。 以下の条件のすべてが成立するなら、ノードuはTTから取り除かれるべきです: r(u)は空です、そして、すべてのwに、r(w、u)は空です、そして、TGのどんなリンクにも、ヘッドかテールのどちらかとしてuがありません。
8.4.9. Optional Reporting of Redundant Topology Information
8.4.9. 余分なトポロジー情報の任意の報告
Each node is required to report its reported subtree RT to neighbors. However, each node (independently of the other nodes) MAY report additional links, e.g., to provide increased robustness in highly mobile networks. For example, a node may compute any subgraph H of TG that contains T, and may report the "reported subgraph" RH which consists of links (u,v) of H such that u is in RN. In this case,
各ノードが、報告された下位木RTを隣人に報告するのに必要です。 しかしながら、各ノード(他のノードの如何にかかわらず)は、例えば非常に可動のネットワークに増加する丈夫さを提供するために追加リンクを報告するかもしれません。 例えば、ノードがTを含むTGのどんな部分グラフHも計算して、Hのリンク(u、v)から成る「報告された部分グラフ」RHを報告するかもしれないので、uがRNにあります。 この場合
Ogier, et al. Experimental [Page 32] RFC 3684 TBRPF February 2004
オジェ、他 [32ページ]実験的なRFC3684TBRPF2004年2月
each periodic update describes RH instead of RT, and each differential update describes changes to RH. If this option is used, then the parameter IMPLICIT_DELETION MUST be set to 0, since the deletion of a link cannot be implied by the addition of another link if redundant topology information is reported.
それぞれの周期的なアップデートはRTの代わりにRHについて説明します、そして、それぞれの特異なアップデートは変化をRHに説明します。 このオプションが使用されているなら、パラメタIMPLICIT_DELETION MUSTが0に用意ができていて、余分なトポロジー情報が報告されるなら、別のものの追加でリンクの削除を含意できないので、リンクしてください。
8.4.10. Local Topology Changes
8.4.10. 地方のトポロジー変化
This section describes the procedures that are followed when the neighbor discovery module detects a new link, the loss of a link, or a change in the metric for a link.
このセクションは隣人発見モジュールが新しいリンク、リンクの損失、またはリンクへのメートル法における変化を検出すると従われている手順について説明します。
When a link (I,J) from a local interface I to a neighbor interface J is discovered via the neighbor discovery module, the procedure Link_Up(I,J) is executed, as defined below. Letting j be the neighbor node associated with interface J, Link_Up(I,J) adds j to N (if it does not already belong), updates the preferred local interface local_if(j) and neighbor interface nbr_if(j) so that the link from local_if(j) to nbr_if(j) has the minimum metric among all links from i to j, and updates metric(i,j) to be this minimum metric.
局所界面Iから隣人インタフェースJへのリンク(I、J)が隣人発見モジュールで発見されるとき、手順Link_Up(I、J)は実行されます、以下で定義されるように。 jがインタフェースJに関連している隣人ノードであることをさせて、Link_Up(I、J)がN(既に属しないなら)にjを加えて、_(j)と隣人が_(j)であるならnbrを連結するなら地方で都合のよい局所界面をアップデートするので、最小限が_(j)であるならすべて中でnbrへの(j)でメートル法になるなら、地方の_からのリンクはj、およびiからアップデートまでこれほど最小限メートル法であるためにメートル法で(i、j)リンクされます。
Link_Up(I,J)
1. Let j = nbr_rid(I,J).
2. If j is not in N:
2.1. Add j to N.
2.2. Add (i,j) to TG.
2.3. Set reported(i,j) = 1.
3. If nbr_metric(I,J) < metric(i,j), set local_if(j) = I,
nbr_if(j) = J, and metric(i,j) = nbr_metric(I,J).
4. If USE_METRICS = 1, set cost(i,j) = metric(i,j).
_上に(I、J)1をリンクしてください。 jを_が取り除いたnbr(I、J)との等しさにしてください。 2. jがNにないなら: 2.1. N.2.2にjを加えてください。 (i、j)をTGに加えてください。 2.3. 報告された(i、j)=1を設定してください。 3. _のメートル法(I、J)の<メートル法(i、j)の、そして、設定している地方のnbr_が(j)であるなら私と等しいなら、nbrは_(j)であるならJ、およびメートル法(i、j)の=nbr_とメートル法であることで等しいです(I、J)。 4. USE_METRICS=1であるなら、メートル法で(i、j)費用(i、j)=を設定してください。
When the loss of a link (I,J) from a local interface I to a neighbor interface J is detected via the neighbor discovery module, the procedure Link_Down(I,J) is executed, as defined below. Note that routes are updated immediately when a link is lost, and if the lost link is due to a link-layer failure notification, a differential topology update is sent immediately.
リンク(I、J)の局所界面Iから隣人インタフェースJまでの損失が隣人発見モジュールで検出されるとき、手順Link_Down(I、J)は実行されます、以下で定義されるように。 すぐリンクが無くなるとき、ルートをアップデートして、リンクレイヤ失敗通知、デフ装置のために無くなっているリンクがトポロジーであるならすぐにアップデートを送ることに注意してください。
Link_Down(I,J)
1. Let j = nbr_rid(I,J).
2. If there does not exist a link (K,L) from node i to
node j with nbr_status(K,L) = 2-WAY:
2.1. Remove j from N.
2.2. Remove (i,j) from TG.
3. If j is in N:
3.1. Let (K,L) be a link from i to j such that
nbr_metric(K,L) is the minimum metric among
all links from i to j.
_下に(I、J)1をリンクしてください。 jを_が取り除いたnbr(I、J)との等しさにしてください。 2. _nbrとのノードiからノードjへのリンク(K、L)が存在していないなら、状態(K、L)は2-WAYと等しいです: 2.1. N.2.2からのjを取り除いてください。 TGから取り外してください(i、j)。 3. jがNにあるなら: 3.1. iからjへのリンクがそのようなものであったなら貸されて(K、L)、そんなにnbr_メートル法であることは(K、L)、iからjへのすべてのリンクの中のメートル法の最小限です。
Ogier, et al. Experimental [Page 33] RFC 3684 TBRPF February 2004
オジェ、他 [33ページ]実験的なRFC3684TBRPF2004年2月
3.2. Set local_if(j) = K, nbr_if(j) = L, and
metric(i,j) = nbr_metric(K,L).
3.3. If USE_METRICS = 1, set cost(i,j) = metric(i,j).
5. Update_Source_Tree().
6. Update_Routing_Table().
7. If j is not in N and lost link is due to link-layer failure
notification:
7.1. If (REPORT_FULL_TREE = 0) Update_RN().
7.2. Else, Update_RN_Simple().
7.3. Set msg_list = empty.
7.4. Generate_Diff_Update().
7.5. Send msg_list on all interfaces.
7.6. Set old_T = T and old_RN = RN.
3.2. _(j)がKと等しいなら、地方でセットしてください、そして、nbrは_(j)であるならL、およびメートル法(i、j)の=nbr_とメートル法であることで等しいです(K、L)。 3.3. USE_METRICS=1であるなら、メートル法で(i、j)費用(i、j)=を設定してください。 5. _ソース_木()をアップデートしてください。 6. _ルート設定_テーブル()をアップデートしてください。 7. jがNになくて、無くなっているリンクが失敗通知をリンクで層にすることになっているなら: 7.1. (レポートの_の完全な_木=0)が_Rn()をアップデートするなら。 7.2. ほかに、_Rn_簡単な()をアップデートしてください。 7.3. 空の状態でmsg_リスト=を設定してください。 7.4. _デフ_アップデート()を発生させてください。 7.5. msg_リストをすべてのインタフェースに送ってください。 7.6. 古い_T=Tと古い_Rn=Rnを設定してください。
If the metric of a link (I,J) from a local interface I to a neighbor interface J changes via the neighbor discovery module, the following procedure Link_Change(I,J) is executed.
隣人発見モジュールを通した局所界面Iからa隣人インタフェースJ変化へのリンク(I、J)のメートル法であるなら、以下の手順Link_Change(I、J)は実行されます。
Link_Change(I,J)
1. Let j = nbr_rid(I,J).
2. Let (K,L) be a link from i to j such that
nbr_metric(K,L) is the minimum metric among
all links from i to j.
3. Set local_if(j) = K, nbr_if(j) = L, and
metric(i,j) = nbr_metric(K,L).
4. If USE_METRICS = 1, set cost(i,j) = metric(i,j).
_変化(I、J)1をリンクしてください。 jを_が取り除いたnbr(I、J)との等しさにしてください。 2. iからjへのリンクがそのようなものであったなら貸されて(K、L)、そんなにnbr_メートル法であることは(K、L)、iからjへのすべてのリンクの中のメートル法の最小限です。 3. _(j)がKと等しいなら、地方でセットしてください、そして、nbrは_(j)であるならL、およびメートル法(i、j)の=nbr_とメートル法であることで等しいです(K、L)。 4. USE_METRICS=1であるなら、メートル法で(i、j)費用(i、j)=を設定してください。
8.4.11. Generating Association Messages
8.4.11. 協会メッセージを発生させます。
This section describes the procedures used to generate INTERFACE ASSOCIATION, HOST ASSOCIATION, and NETWORK PREFIX ASSOCIATION messages. Addresses or prefixes in the interface table, host table, and network prefix table are reported to neighbors periodically every IA_INTERVAL, HA_INTERVAL, and NPA_INTERVAL seconds, respectively. In addition, differential changes to the tables are reported every DIFF_UPDATE_INTERVAL seconds if it is not time for a periodic update (similar to differential topology updates). Each node reports only addresses or prefixes that are associated with nodes in the reported node set RN; this ensures the efficient broadcast of all associated addresses and prefixes to all nodes in the network.
このセクションはINTERFACE ASSOCIATION、HOST ASSOCIATION、およびNETWORK PREFIX ASSOCIATIONメッセージを発生させるのに用いられた手順について説明します。 インタフェースが見送るコネ、ホストテーブル、およびネットワーク接頭語テーブルが報告されるアドレスか接頭語があらゆるアイオワ_INTERVAL、HA_INTERVAL、およびINTERVALがそれぞれ後援するNPA_を定期的に近所付き合いさせます。 さらに、テーブルへの特異な変化は報告されて、INTERVALがそれであるなら後援するあらゆるDIFF_UPDATE_が周期的なアップデート(微分位相幾何学アップデートと同様の)のための時間であるというわけではないということです。 各ノードは、報告されたノードのノードに関連しているアドレスか接頭語だけがRNを設定すると報告します。 これはすべての関連アドレスと接頭語の効率的な放送をネットワークにおけるすべてのノードに確実にします。
The generated messages are sent on each interface. Whenever possible, these messages are combined into the same packet, in order to minimize the number of control packets transmitted.
各インタフェースで発生しているメッセージを送ります。 可能であるときはいつも、これらのメッセージは、パケットが送ったコントロールの数を最小にするために同じパケットに結合されます。
Generate_Association_Messages() 1. Generate_Interface_Association_Messages(). 2. Generate_Host_Association_Messages().
_協会_メッセージ()1を発生させてください。 _インタフェース_協会_メッセージ()を発生させてください。 2. _ホスト_協会_メッセージ()を発生させてください。
Ogier, et al. Experimental [Page 34] RFC 3684 TBRPF February 2004
オジェ、他 [34ページ]実験的なRFC3684TBRPF2004年2月
3. Generate_Network_Prefix_Association_Messages().
3. _ネットワーク_接頭語_協会_メッセージ()を発生させてください。
Generate_Interface_Association_Messages()
1. If current_time > next_ia_time:
1.1. Set next_ia_time = current_time + IA_INTERVAL.
1.2. For each node u in RN:
1.2.1. Let addr_1,..., addr_n be the interface IP
addresses associated with RID u in the current
interface table.
1.2.2. If this list is nonempty, add the INTERFACE
ASSOCIATION message (FULL, n, u, addr_1,..., addr_n)
to msg_list(I) for each I.
_インタフェース_協会_メッセージ()1を発生させてください。 現在の_時間>であるなら次の_ia_時間の: 1.1. 次の_ia_時=に+ 現在の_時間アイオワ_INTERVALを設定してください。 1.2. RNの各ノードuのために: 1.2.1. addr_1をさせてください…, addrに現在のインタフェーステーブルでRID uに関連しているインタフェースIPアドレスになってください。 1.2.2. このリストがnonemptyであるなら、各Iのために、INTERFACE ASSOCIATIONメッセージ(FULL n、uの、そして、addrな_1、…はaddrする)をmsg_リスト(I)に追加してください。
2. Else, for each node u in RN:
2.1. Add the INTERFACE ASSOCIATION message (ADD, n, u,
addr_1,..., addr_n) to msg_list(I) for each I, where
addr_1,..., addr_n are the interface IP addresses that
are associated with RID u in the current interface table
but not in the old interface table.
2.2. Add the INTERFACE ASSOCIATION message (DELETE, n, u,
addr_1,..., addr_n) to msg_list(I) for each I, where
addr_1,..., addr_n are the interface IP addresses that
are associated with RID u in the old interface table
but not in the current interface table.
2. RNの各ノードuにおいてほか: 2.1. 各I、どこに_リスト(I)をmsgするか(ADD、n、u、addr_1、…、addr)が_1をaddrするというINTERFACE ASSOCIATIONメッセージを加えてください…, addrは現在のインタフェーステーブルでRID uに関連しているインタフェースIPアドレスですが、古いインタフェーステーブルのそのようなアドレスではありません。 2.2. 各I、どこに_リスト(I)をmsgするか(DELETE、n、u、addr_1、…、addr)が_1をaddrするというINTERFACE ASSOCIATIONメッセージを加えてください…, addrは古いインタフェーステーブルでRID uに関連しているインタフェースIPアドレスですが、現在のインタフェーステーブルのそのようなアドレスではありません。
Generate_Host_Association_Messages()
1. If current_time > next_ha_time:
1.1. Set next_ha_time = current_time + HA_INTERVAL.
1.2. For each node u in RN:
1.2.1. Let addr_1,..., addr_n be the host IP addresses
associated with RID u in the current host table.
1.2.2. If this list is nonempty, add the HOST ASSOCIATION
message (FULL, n, u, addr_1,..., addr_n) to
msg_list(I) for each I.
_ホスト_協会_メッセージ()1を発生させてください。 現在の_時間>次期の_である、ハ、_時間: 1.1. _+ ハ、現在の__時間=時間HA_INTERVAL次に設定されて。 1.2. RNの各ノードuのために: 1.2.1. addr_1をさせてください…, addrに現在のホストテーブルでRID uに関連しているホストIPアドレスになってください。 1.2.2. このリストがnonemptyであるなら、各Iのために、HOST ASSOCIATIONメッセージ(FULL n、uの、そして、addrな_1、…はaddrする)をmsg_リスト(I)に追加してください。
2. Else, for each node u in RN:
2.1. Add the HOST ASSOCIATION message (ADD, n, u,
addr_1,..., addr_n) to msg_list(I) for each I, where
addr_1,..., addr_n are the host IP addresses that
are associated with RID u in the current host table
but not in the old host table.
2.2. Add the HOST ASSOCIATION message (DELETE, n, u,
addr_1,..., addr_n) to msg_list(I) for each I, where
addr_1,..., addr_n are the host IP addresses that
are associated with RID u in the old host table
but not in the current host table.
2. RNの各ノードuにおいてほか: 2.1. 各I、どこに_リスト(I)をmsgするか(ADD、n、u、addr_1、…、addr)が_1をaddrするというHOST ASSOCIATIONメッセージを加えてください…, addrは現在のホストテーブルでRID uに関連しているホストIPアドレスですが、古いホストテーブルのそのようなアドレスではありません。 2.2. 各I、どこに_リスト(I)をmsgするか(DELETE、n、u、addr_1、…、addr)が_1をaddrするというHOST ASSOCIATIONメッセージを加えてください…, addrは古いホストテーブルでRID uに関連しているホストIPアドレスですが、現在のホストテーブルのそのようなアドレスではありません。
Ogier, et al. Experimental [Page 35] RFC 3684 TBRPF February 2004
オジェ、他 [35ページ]実験的なRFC3684TBRPF2004年2月
Generate_Network_Prefix_Association_Messages()
1. If current_time > next_npa_time:
1.1. Set next_npa_time = current_time + NPA_INTERVAL.
1.2. For each node u in RN:
1.2.1. Let length_1, prefix_1,..., length_n, prefix_n
be the network prefix lengths and prefixes associated
with RID u in the current network prefix table.
1.2.2. If this list is nonempty, add the NETWORK PREFIX
ASSOCIATION message (FULL, n, u, length_1, prefix_1,
..., length_n, prefix_n) to msg_list(I) for each I.
_ネットワーク_接頭語_協会_メッセージ()1を発生させてください。 現在の_時間>であるなら次の_npa_時間の: 1.1. 次の_npa_時=に+ 現在の_時間NPA_INTERVALを設定してください。 1.2. RNの各ノードuのために: 1.2.1. 長さ_1、接頭語_1をさせてください…, 長さ、接頭語、現在のネットワーク接頭語テーブルのRID uに関連づけられたネットワーク接頭語の長さと接頭語になってください。 1.2.2. このリストがnonemptyであるなら、各Iのために、NETWORK PREFIX ASSOCIATIONメッセージ(FULL、n、_1、…をu、長さ_1は前に置きます、長さ、接頭語)をmsg_リスト(I)に追加してください。
2. Else, for each node u in RN:
2.1. Add the NETWORK PREFIX ASSOCIATION message
(ADD, n, u, prefix_1,..., prefix_n) to msg_list(I) for
each I, where prefix_1,..., prefix_n are the network
prefixes that are associated with RID u in the current
prefix table but not in the old prefix table.
2. RNの各ノードuにおいてほか: 2.1. 各I、どこに_リスト(I)をmsgするか(ADD、n、u、接頭語_1、…、接頭語)が_1を前に置くというNETWORK PREFIX ASSOCIATIONメッセージを加えてください…, 接頭語は、現在の接頭語テーブルでRID uに関連しているネットワーク接頭語ですが、古い接頭語テーブルのそのような接頭語ではありません。
2.1. Add the NETWORK PREFIX ASSOCIATION message
(DELETE, n, u, prefix_1,..., prefix_n) to msg_list(I) for
each I, where prefix_1,..., prefix_n are the network
prefixes that are associated with RID u in the old prefix
table but not in the current prefix table.
2.1. 各I、どこに_リスト(I)をmsgするか(DELETE、n、u、接頭語_1、…、接頭語)が_1を前に置くというNETWORK PREFIX ASSOCIATIONメッセージを加えてください…, 接頭語は、古い接頭語テーブルでRID uに関連しているネットワーク接頭語ですが、現在の接頭語テーブルのそのような接頭語ではありません。
8.4.12. Processing Association Messages
8.4.12. 処理協会メッセージ
When an INTERFACE ASSOCIATION, HOST ASSOCIATION, or NETWORK PREFIX ASSOCIATION message is received from node j, the interface table, host table, or network prefix table, respectively, is updated as described in the following three procedures.
ノードjからINTERFACE ASSOCIATION、HOST ASSOCIATION、またはNETWORK PREFIX ASSOCIATIONメッセージを受け取るとき、以下の3つの手順で説明されるようにそれぞれインタフェーステーブル、ホストテーブル、またはネットワーク接頭語テーブルをアップデートします。
Process_Interface_Association_Messages(j, msg_list)
For each message (subtype, n, u, addr_1,..., addr_n) in msg_list
such that j = p(u):
1. If subtype = FULL, remove all entries with if_rid = u
from the interface table.
2. If subtype = FULL or ADD, then for m = 1,..., n,
add the tuple (if_addr, if_rid, if_expire) to the
interface table, where:
if_addr = addr_m,
if_rid = u,
if_expire = current_time + IA_HOLD_TIME.
3. If subtype = DELETE, then for m = 1,..., n,
remove the tuple (if_addr, if_rid, if_expire) from the
interface table, where if_addr = addr_m and if_rid = u.
jがp(u)と等しいように、_msg_の各メッセージ(「副-タイプ」、n、u、addr_1、…、addr)のためのAssociation_Messages(j、msg_リスト)が記載するInterface_を処理してください: 1. _がインタフェーステーブルから=uを取り除いたなら、=FULLを副タイプして、すべてのエントリーを取り除きます。 2. 「副-タイプ」がそして、m=1のためにFULLかADDと等しいなら…, n、tuple(_addrであるなら、_排除しているなら、_であるなら期限が切れる)をインタフェーステーブル、どこに加えてくださいか: __が=uを取り除いたならaddrが_であるならaddr_mと等しいなら、_=電流_時間+アイオワHOLD_タイム誌を吐き出してください。 3. 「副-タイプ」がそして、m=1のためにDELETEと等しいなら…, n、インタフェーステーブルからtuple(_addrであるなら、_排除しているなら、_であるなら期限が切れる)を取り外してください、そして、_であるなら=uを取り除いてください。(_であるなら、そこでは、addrがaddr_mと等しいです)。
Ogier, et al. Experimental [Page 36] RFC 3684 TBRPF February 2004
オジェ、他 [36ページ]実験的なRFC3684TBRPF2004年2月
Process_Host_Association_Messages(j, msg_list)
For each message (subtype, n, u, addr_1,..., addr_n) in msg_list
such that j = p(u):
1. If subtype = FULL, remove all entries with h_rid = u
from the host table.
2. If subtype = FULL or ADD, then for m = 1,..., n,
add the tuple (h_addr, h_rid, h_expire) to the
host table, where:
h_addr = addr_m,
h_rid = u,
h_expire = current_time + HA_HOLD_TIME.
3. If subtype = DELETE, then for m = 1,..., n,
remove the tuple (h_addr, h_rid, h_expire) from the
host table, where h_addr = addr_m and h_rid = u.
jがp(u)と等しいように、_msg_の各メッセージ(「副-タイプ」、n、u、addr_1、…、addr)のためのAssociation_Messages(j、msg_リスト)が記載するHost_を処理してください: 1. 「副-タイプ」がFULLと等しいなら、ホストテーブルからのh_が取り除かれているすべてのエントリー=uを取り除いてください。 2. 「副-タイプ」がそして、m=1のためにFULLかADDと等しいなら…, n、tuple(h_addr、取り除かれたh_、h_は期限が切れる)をホストテーブル、どこに加えてくださいか: h_addrはaddr_mと等しく、h_の排除している=u、h_は=電流_時間+HA_HOLD_タイム誌を吐き出します。 3. 「副-タイプ」がそして、m=1のためにDELETEと等しいなら…, n、ホストテーブルからtuple(h_addr、取り除かれたh_、h_は期限が切れる)を取り外してください。そこでは、h_addrがaddr_mとh_の排除している=uと等しいです。
Process_Network_Prefix_Association_Messages(j, msg_list)
For each message (subtype, n, u, length_1, prefix_1, ...,
length_n, prefix_n) in msg_list such that j = p(u):
1. If subtype = FULL, remove all entries with net_rid = u
from the prefix table.
2. If subtype = FULL or ADD, then for m = 1,..., n,
add the tuple (net_prefix, net_length, net_rid,
net_expire) to the network prefix table, where:
net_prefix = prefix_m,
net_length = length_m,
net_rid = u,
net_expire = current_time + NPA_HOLD_TIME.
3. If subtype = DELETE, then for m = 1,..., n,
remove the tuple (net_prefix, net_length, net_rid,
net_expire) from the network prefix table, where
net_prefix = prefix_m, net_length = length_m,
and net_rid = u.
jがp(u)と等しいように、_msg_の各メッセージ(「副-タイプ」、n(u、長さ_1)は_1、…、長さ、接頭語を前に置く)のためのAssociation_Messages(j、msg_リスト)が記載するNetwork_Prefix_を処理してください: 1. 「副-タイプ」がFULLと等しいなら、接頭語テーブルからのネットの_が取り除かれているすべてのエントリー=uを取り除いてください。 2. 「副-タイプ」がそして、m=1のためにFULLかADDと等しいなら…, n、tuple(ネットの_接頭語、ネットの_の長さ、ネットの_排除していて、ネットの_は期限が切れる)をネットワーク接頭語テーブル、どこに加えてくださいか: ネットの_接頭語は_接頭語_m、ネットの_が、=u、ネットの_が吐き出すのを取り除いた長さの_ネットの_の長さ=m=電流時間+NPA_HOLD_タイム誌と等しいです。 3. 「副-タイプ」がそして、m=1のためにDELETEと等しいなら…, n、ネットの_接頭語がネットの_の長さの_m、=長さ_m、およびネットの_が取り除く接頭語と等しいネットワーク接頭語テーブル=uからtuple(ネットの_接頭語、ネットの_の長さ、ネットの_排除していて、ネットの_は期限が切れる)を取り外してください。
8.4.13. Non-Relay Operation
8.4.13. 非リレー操作
Nodes with relay priority equal to zero are called non-relay nodes, and do not forward packets (of any type) that are received from other nodes. A non-relay node is implemented simply by not generating or transmitting any TOPOLOGY UPDATE messages. A non-relay node may report (in association messages) addresses or prefixes that are associated with itself, but not those associated with other nodes. HELLO messages must be transmitted in order to establish links with neighbor nodes. The following procedures can be omitted in non-relay nodes: Update_RN(), Generate_Periodic_Update(), and Generate_Diff_Update().
ゼロに合わせるために等しいリレー優先権があるノードは、非リレーノードと呼ばれて、他のノードから受け取られるパケット(どんなタイプのも)を進めません。 非リレーノードは、単に、どんなTOPOLOGY UPDATEメッセージも発生しないか、または送らないことによって、実行されます。 非リレーノードは、それらではなく、それ自体に関連しているアドレスか接頭語が他のノードに関連していると報告するかもしれません(協会メッセージで)。 隣人ノードとのリンクを設立するためにHELLOメッセージを送らなければなりません。 非リレーノードで以下の手順を省略できます: _Rn()をアップデートしてください、そして、_周期的な_アップデート()を発生させてください、そして、_デフ_アップデート()を発生させてください。
Ogier, et al. Experimental [Page 37] RFC 3684 TBRPF February 2004
オジェ、他 [37ページ]実験的なRFC3684TBRPF2004年2月
8.5. Configurable Parameters
8.5. 構成可能なパラメタ
This section lists the configurable parameters used by the routing module, and their proposed default values. All nodes MUST have the same value for all of the following parameters except REPORT_FULL_TREE and IMPLICIT_DELETION.
このセクションはルーティングモジュールで使用される構成可能なパラメタ、およびそれらの提案されたデフォルト値を記載します。 すべてのノードで、同じくらいはREPORT以外の以下のパラメタのすべてのために_FULL_TREEとIMPLICIT_DELETIONを評価しなければなりません。
Parameter Name Default Value
-------------- -------------
DIFF_UPDATE_INTERVAL 1 second
PER_UPDATE_INTERVAL 5 seconds
TOP_HOLD_TIME 15 seconds
NON_REPORT_PENALTY 1.01
NON_TREE_PENALTY 0.01
IA_INTERVAL 10 seconds
IA_HOLD_TIME 3 * IA_INTERVAL
HA_INTERVAL 10 seconds
HA_HOLD_TIME 3 * HA_INTERVAL
NPA_INTERVAL 10 seconds
NPA_HOLD_TIME 3 * NPA_INTERVAL
USE_METRICS 0
REPORT_FULL_TREE 0
IMPLICIT_DELETION 1
パラメタ名前デフォルト値-------------- ------------- _DIFF_UPDATE_INTERVAL1第2PER UPDATE_INTERVAL5秒TOP_HOLD_タイム誌15秒NON_REPORT、_PENALTY1.01、NON_TREE_PENALTY0.01アイオワ_INTERVAL10秒アイオワ_HOLD_タイム誌3*アイオワ_INTERVAL HA_INTERVAL10秒HA_HOLD_タイム誌3*HA_INTERVAL NPA_INTERVAL10秒NPA_HOLD_タイム誌3*NPA_INTERVAL USE_METRICS0REPORT_、FULL_TREE0IMPLICIT_DELETION1
9. TBRPF Flooding Mechanism
9. TBRPF氾濫メカニズム
This section describes a mechanism for the efficient best-effort flooding (or network-wide broadcast) of packets to all nodes of a connected ad-hoc network. This mechanism can be considered an optimization of the classical flooding algorithm in which each packet is transmitted by every node of the network. In TBRPF flooding, information provided by TBRPF is used to decide whether a given received flooded packet should be forwarded. As a result, each packet is transmitted by only a relatively small subset of nodes, thus consuming much less bandwidth than classical flooding.
このセクションはパケットの効率的なベストエフォート型氾濫(または、ネットワーク全体の放送)によって接続臨時のネットワークのすべてのノードにメカニズムについて説明します。 各パケットがネットワークのあらゆるノードによって伝えられる古典的な氾濫アルゴリズムの最適化であるとこのメカニズムを考えることができます。 TBRPF氾濫では、TBRPFによって提供された情報は、与えられた容認された水につかっているパケットが進められるべきであるかどうか決めるのに使用されます。 その結果、各パケットはノードの比較的小さい部分集合だけによって伝えられます、その結果、古典的な氾濫よりはるかに少ない帯域幅を消費します。
This document specifies that the flooding mechanism use the IPv4 multicast address 224.0.1.20 (currently assigned by IANA for "any private experiment"). Every node maintains a duplicate cache to keep track of which flooded packets have already been received. The duplicate cache contains, for each received flooded packet, the flooded packet identifier (FPI), which for IPv4 is composed of the source IP address, the IP identification, and the fragment offset values obtained from the IP header [14].
このドキュメントは、氾濫メカニズムがIPv4マルチキャストアドレス224.0.1.20(現在、「どんな個人的な実験」のためにIANAによって割り当てられる)を使用すると指定します。 あらゆるノードが動向をおさえる水につかっているパケットが既に受け取られた写しキャッシュを維持します。 写しキャッシュはそれぞれの容認された水につかっているパケットのために、水につかっているパケット識別子(FPI)を含んでいます。(IPv4のために、それは、オフセット値がIPヘッダー[14]から入手したソースIPアドレス、IP識別、および断片で構成されます)。
When a node receives a packet whose destination IP address is the flooding address (224.0.1.20), it checks its duplicate cache for an entry that matches the packet. If such an entry exists, the node
ノードが送付先IPアドレスが氾濫アドレスであるパケットを受ける、(224.0 .1 .20) それはパケットに合っているエントリーがないかどうか写しキャッシュをチェックします。 そのようなエントリーが存在しているならノード
Ogier, et al. Experimental [Page 38] RFC 3684 TBRPF February 2004
オジェ、他 [38ページ]実験的なRFC3684TBRPF2004年2月
silently discards the flooded packet since it has already been received. Otherwise, the node retransmits the packet on all interfaces (see the exception below) if and only if the following conditions hold:
既にそれを受け取ったので、静かに水につかっているパケットを捨てます。 さもなければ、ノードがすべてのインタフェースでパケットを再送する、(以下の例外を見てください)以下の条件は単に以下を保持します。
1. The TBRPF node associated with the source IP address of the packet
belongs to the set RN of reported nodes computed by TBRPF.
1. パケットのソースIPアドレスに関連しているTBRPFノードはTBRPFによって計算された報告されたノードのセットRNに属します。
2. When decremented, the 'ip_ttl' in the IPv4 packet header
(respectively, the 'hop_count' in the IPv6 packet header) is
greater than zero.
2. 減少すると、IPv4パケットのヘッダー(それぞれIPv6パケットのヘッダーの'ホップ_カウント')の'ip_ttl'はゼロ以上です。
If the packet is to be retransmitted, it is sent after a small random time interval in order to avoid collisions. If the interface on which the packet was received is not a MANET interface (see the Terminology section), then the packet should not be retransmitted on that interface.
パケットを再送するつもりであるなら、小さい無作為の時間間隔の後に衝突を避けるためにそれを送ります。 パケットが受け取られたインタフェースがマネインタフェース(Terminology部を見る)でないなら、そのインタフェースでパケットを再送するべきではありません。
10. Operation of TBRPF in Mobile Ad-Hoc Networks
10. モバイル臨時のネットワークにおける、TBRPFの操作
TBRPF is particularly well suited to MANETs consisting of mobile nodes with wireless network interfaces operating in peer-to-peer fashion over a multiple access communications channel. Although applicable across a much broader field of use, TBRPF is particularly well suited for supporting the standard DARPA Internet protocols [3][2]. In the following sections, we discuss practical considerations for the operation of TBRPF on MANETs.
TBRPFは特にワイヤレス・ネットワークインタフェースが複数のアクセスコミュニケーションチャンネルの上のピアツーピアファッションで作動している可動のノードから成るMANETsによく合っています。 使用のはるかに広い分野の向こう側に適切ですが、TBRPFは特に標準のDARPAインターネットプロトコル[3][2]を支持するのによく適しています。 以下のセクションで、私たちはMANETsにおけるTBRPFの操作のために実用的な問題について議論します。
10.1. Data Link Layer Assumptions
10.1. データ・リンク層仮定
We assume a MANET data link layer that supports broadcast, multicast and unicast addressing with best-effort (not guaranteed) delivery services between neighbors (i.e., a pair of nodes within operational communications range of one another). We further assume that each interface belonging to a node in the MANET is assigned a unicast data link layer address that is unique within the MANET's scope. While such uniqueness is not strictly guaranteed, the assumption of uniqueness is consistent with current practices for deployment of the Internet protocols on specific link layers. Methods for duplicate link layer address detection and deconfliction are beyond the scope of this document.
隣人(すなわち、操作上のコミュニケーション範囲のお互いの中の1組のノード)の間には、ベストエフォート型(保証されない)のデリバリ・サービスがある状態で、私たちはサポートが放送するマネデータ・リンク層、マルチキャスト、およびユニキャストアドレシングを仮定します。 私たちは、マネの範囲の中でユニークなユニキャストデータ・リンク層アドレスがマネでノードに属す各インタフェースに割り当てられるとさらに思います。 そのようなユニークさは厳密に保証されませんが、特定のリンクレイヤにおけるインターネットプロトコルの展開において、ユニークさの仮定は現在の実務と一致しています。 写しリンクレイヤアドレス検出のための方法と相互干渉排除はこのドキュメントの範囲を超えています。
10.2. Network Layer Assumptions
10.2. ネットワーク層仮定
MANETs are formed as collections of routers and non-routing nodes that use network layer addresses when calculating the MANET topology. We assume that each node has at least one data link layer interface (described above) and that each such interface is assigned a network
MANETsはルータとマネトポロジーについて計算するときネットワーク層アドレスを使用する非ルーティングノードの収集として形成されます。 私たちは、各ノードには少なくとも1つのデータ・リンク層インタフェース(上で、説明される)があって、そのような各インタフェースがネットワークに配属されると思います。
Ogier, et al. Experimental [Page 39] RFC 3684 TBRPF February 2004
オジェ、他 [39ページ]実験的なRFC3684TBRPF2004年2月
layer address that is unique within the MANET. (Methods for network layer address assignment and duplicate address detection are beyond the scope of this document.) We further assume that each node will select a unique Router ID (RID) for use in TBRPF protocol messages, whether or not the node acts as a MANET router. Finally, we assume that each MANET router supports the multi-hop relay paradigm at the network layer; i.e., each router provides an inter-node forwarding service via network layer host routes which reflect the current MANET topology as perceived by TBRPF.
マネの中でユニークなアドレスを層にしてください。 (ネットワーク層アドレス課題と写しアドレス検出のための方法はこのドキュメントの範囲を超えています。) 私たちは、各ノードがTBRPFプロトコルメッセージにおける使用のために、ユニークなRouter ID(RID)を選択するとさらに思います、ノードがマネルータとして機能するか否かに関係なく。 最終的に、私たちは、それぞれのマネルータがネットワーク層におけるマルチホップリレーパラダイムを支持すると思います。 すなわち、各ルータは、TBRPFによって知覚されるように現在のマネトポロジーを反映するネットワーク層ホストルートでサービスを進めながら、節間を提供します。
10.3. Optional Automatic Address Resolution
10.3. 任意の自動アドレス解決
TBRPF employs a proactive neighbor discovery protocol at the network layer that maintains bi-directional link state for neighboring nodes through the periodic transmission of messages. Since TBRPF neighbor discovery messages contain both the data link and network layer address of the sender, implementations MAY perform automatic network-to-data link layer address resolution for the nodes with which they form links. An implementation may use such a mechanism to avoid additional message overhead and potential for packet loss associated with on-demand address resolution mechanisms such as ARP [15] or IPv6 Neighbor Discovery [16]. Implementations MUST respond to on-demand address resolution requests in the normal manner.
TBRPFは隣接しているノードのためにメッセージの周期的な伝達で双方向のリンク状態を維持するネットワーク層で先を見越す隣人発見プロトコルを使います。 TBRPF隣人発見メッセージがデータ・リンクとネットワーク層送信者のアドレスの両方を含んでいるので、実現はそれらがリンクを形成するノードのためのネットワークからデータ・リンク層へのアドレス自動解決を実行するかもしれません。 実現は、ARP[15]かIPv6 Neighborディスカバリー[16]などの要求次第のアドレス解決メカニズムに関連しているパケット損失の追加メッセージオーバーヘッドと可能性を避けるのにそのようなメカニズムを使用するかもしれません。 実現は正常な方法による要求次第のアドレス解決要求に応じなければなりません。
10.4. Support for Multiple Interfaces and/or Alias Addresses
10.4. 複数のインタフェース、そして/または、別名アドレスのサポート
MANET nodes may comprise multiple interfaces; each with a unique network layer address. Additionally, MANET nodes may wish to publish alias addresses such as when multiple network layer addresses are assigned to the same interface or when the MANET node is serving as a Mobile IP [17] home agent. Multiple interfaces and alias addresses are advertised in INTERFACE ASSOCIATION messages, which bind each such address to the node's RID.
マネノードは複数のインタフェースを包括するかもしれません。 ユニークなネットワーク層アドレスがあるそれぞれ。 さらに、マネノードは複数のネットワーク層アドレスがいつ同じインタフェースに割り当てられるか、そして、またはマネノードがいつモバイルIP[17]家のエージェントとして勤めなどかなどの別名アドレスを発表したがっているかもしれません。 INTERFACE ASSOCIATIONメッセージに複数のインタフェースと別名アドレスの広告を出します。(メッセージはそのような各アドレスをノードのRIDに縛ります)。
10.5. Support for Network Prefixes
10.5. ネットワーク接頭語のサポート
MANET routers may advertise network prefixes which the router discovered via attached networks, external routes advertised by other protocols, or other means. Network prefixes are advertised in NETWORK PREFIX ASSOCIATION messages, which bind each such prefix to the node's RID.
マネルータはルータが付属ネットワークを通して発見したネットワーク接頭語、他のプロトコルによって広告に掲載された外部経路、または他の手段の広告を出すかもしれません。 NETWORK PREFIX ASSOCIATIONメッセージにネットワーク接頭語の広告を出します。(メッセージはそのような各接頭語をノードのRIDに縛ります)。
10.6. Support for non-MANET Hosts
10.6. 非マネホストのサポート
Non-MANET hosts may establish connections to MANET routers through on-demand mechanisms such as ARP or IPv6 Neighbor Discovery. Such connections do not constitute a MANET link and therefore are not reported in TBRPF topology updates. Non-MANET hosts are advertised
非マネホストはARPかIPv6 Neighborディスカバリーなどの要求次第のメカニズムを通してマネルータに関係を樹立するかもしれません。 そのような接続は、マネリンクを構成しないで、またしたがって、TBRPFトポロジーアップデートで報告されません。 非マネホストの広告を出します。
Ogier, et al. Experimental [Page 40] RFC 3684 TBRPF February 2004
オジェ、他 [40ページ]実験的なRFC3684TBRPF2004年2月
in HOST ASSOCIATION messages, which bind the IP address of each host to the node's RID.
HOST ASSOCIATIONメッセージで。(メッセージはノードのRIDのそれぞれのホストのIPアドレスを縛ります)。
10.7. Internet Protocol Considerations
10.7. インターネットプロトコル問題
TBRPF packets are communicated using UDP/IP. Port 712 has been assigned by IANA for exclusive use by TBRPF. Implementations in private networks MAY employ alternate data delivery services (i.e., raw IP or local data-link encapsulation). The selection of an alternate data delivery service MUST be consistent among all MANET routers in the private network. In all implementations, the data delivery service MUST provide a checksum facility.
TBRPFパケットは、UDP/IPを使用することで伝えられます。 ポート712はTBRPFによってIANAによって専用に割り当てられました。 私設のネットワークにおける実現は交互のデータデリバリ・サービス(すなわち、生のIPか地方のデータ・リンクカプセル化)を使うかもしれません。 交互のデータデリバリ・サービスの選択は私設のネットワークにおけるすべてのマネルータの中で一貫しているに違いありません。 すべての実現に、データデリバリ・サービスはチェックサム施設を提供しなければなりません。
The following sections specify the operation of TBRPF over UDP/IP.
以下のセクションはUDP/IPの上でTBRPFの操作を指定します。
10.7.1. IPv4 Operation
10.7.1. IPv4操作
When IPv4 is used, TBRPF nodes obey IPv4 host and router requirements [4][5]. TBRPF packets are sent to the multicast address 224.0.0.2 (All Routers) and thus reach all TBRPF routers within single-hop transmission range of the sender. TBRPF routers MUST NOT forward packets sent to this multicast address.
IPv4が使用されているとき、TBRPFノードはIPv4ホストとルータ要件[4][5]に従います。 TBRPFパケットは、マルチキャストアドレス224.0.0.2(すべてのRouters)に送られて、その結果、送付者の単一のホップトランスミッション範囲の中ですべてのTBRPFルータに達します。 TBRPFルータはこのマルチキャストアドレスに送られたパケットを進めてはいけません。
Since non-negligible packet loss due to link failure, interference, etc. can occur, implementations SHOULD avoid IPv4 fragmentation/ reassembly whenever possible, by splitting large TBRPF protocol packets into multiple smaller packets at the application layer. When fragmentation is unavoidable, senders SHOULD NOT send TBRPF packets that exceed the minimum reassembly buffer size ([4], section 3.3.2) for all receivers in the network.
失敗、干渉などをリンクすることにおける支払い満期の非取るにたらないパケット損失が起こることができるので、可能であるときはいつも、実装SHOULDはIPv4断片化/再アセンブリを避けます、大きいTBRPFプロトコルパケットを応用層の複数の、より小さいパケットに分けることによって。 断片化が避けられないときに、送付者SHOULD NOTはネットワークにおけるすべての受信機のために最小の再アセンブリバッファサイズ([4]、セクション3.3.2を)超えているパケットをTBRPFに送ります。
10.7.2. IPv6 Operation
10.7.2. IPv6操作
The specification of TBRPF for IPv6 is the same as for IPv4, except that 32-bit IPv4 addresses are replaced by 128-bit IPv6 addresses. However, to minimize overhead, router IDs remain at 32 bits, similar to OSPF for IPv6 [18].
IPv6のためのTBRPFの仕様はIPv4のように同じです、32ビットのIPv4アドレスを128ビットのIPv6アドレスに取り替えるのを除いて。 しかしながら、オーバーヘッドを最小にするために、ルータIDはIPv6[18]に、OSPFと同様の32ビットに残ります。
11. IANA Considerations
11. IANA問題
The IANA has assigned port number 712 for TBRPF.
IANAはTBRPFのポートNo.712を割り当てました。
The TBRPF flooding mechanism specified in this document uses the IPv4 multicast address 224.0.1.20, which is currently assigned by IANA for "any private experiment". In the event that this specification is advanced to standards track, a new multicast address assignment would be requested for this purpose.
本書では指定されたTBRPF氾濫メカニズムがIPv4マルチキャストアドレスを使用する、224.0、.1、.20、現在「どんな個人的な実験」のためにIANAによって割り当てられる。 この仕様が標準化過程に進められる場合、新しいマルチキャストアドレス課題はこのために要求されるでしょう。
Ogier, et al. Experimental [Page 41] RFC 3684 TBRPF February 2004
オジェ、他 [41ページ]実験的なRFC3684TBRPF2004年2月
12. Security Considerations
12. セキュリティ問題
Wireless networks are vulnerable to a variety of attacks, including denial-of-service attacks (e.g., flooding and jamming), man-in-the- middle attacks (e.g., interception, insertion, deletion, modification, replaying) and service theft. To counter such attacks, it is important to prevent the spoofing (impersonation) of TBRPF nodes, and to prevent unauthorized nodes from joining the network via neighbor discovery. To achieve this, TBRPF packets can be authenticated using the IP Authentication Header [19][20]. In addition, the Encapsulating Security Payload (ESP) header [21] can be used to provide confidentiality (encryption) of TBRPF packets.
ワイヤレス・ネットワークはさまざまな攻撃に被害を受け易いです、サービス不能攻撃(例えば、氾濫とジャム)を含んでいて、中の男性、-、-中央を攻撃して(例えば、妨害、挿入、削除、変更が再演されて)、窃盗を修理してください。 そのような攻撃に対抗するために、TBRPFノードのスプーフィング(ものまね)を防いで、隣人発見で権限のないノードがネットワークに加わるのを防ぐのは重要です。 これを達成するために、IP Authentication Header[19][20]を使用することでTBRPFパケットを認証できます。 さらに、TBRPFパケットの秘密性(暗号化)を提供するのにEncapsulating Security有効搭載量(超能力)ヘッダー[21]を使用できます。
The IETF SEcuring Neighbor Discovery (SEND) Working Group analyzes trust models and threats for ad hoc networks [22]. TBRPF can be extended in a straightforward manner to use SEND mechanisms, e.g., [23].
IETF SEcuring Neighborディスカバリー(SEND)作業部会は臨時のネットワーク[22]のために信頼モデルと脅威を分析します。 SENDメカニズム、例えば、[23]を使用するために正直な態度でTBRPFを広げることができます。
13. Acknowledgements
13. 承認
The authors would like to thank the Army Systems Engineering Office (ASEO) for funding part of this work.
作者はこの仕事の基金部分について陸軍Systems Engineeringオフィス(ASEO)に感謝したがっています。
The authors would like to thank several members of the MANET working group for many helpful comments and suggestions, including Thomas Clausen, Philippe Jacquet, and Joe Macker.
作者は多くの役に立つコメントと提案についてマネワーキンググループの数人のメンバーに感謝したがっています、トーマス・クロウセン、フィリップ・ジャケ、およびジョーMackerを含んでいて。
The authors would like to thank Bhargav Bellur for major contributions to the original (full-topology) version of TBRPF, Ambatipudi Sastry for his support and advice, and Julie S. Wong for developing a new implementation of TBRPF and suggesting several clarifications to the TBRPF Routing Operation section.
作者はTBRPF、彼のサポートとアドバイスを求めるAmbatipudi Sastry、およびTBRPFの新しい実装を開発して、TBRPFルート設定Operation部にいくつかの明確化を示すためのジュリーS.ウォンのオリジナル(完全なトポロジー)のバージョンへの主要な貢献についてBhargav Bellurに感謝したがっています。
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[2] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[3] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[3] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[4] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[4] ブレーデン、R.、エド、「インターネットホストのための要件--コミュニケーションは層にする」、STD3、RFC1122、10月1989日
Ogier, et al. Experimental [Page 42] RFC 3684 TBRPF February 2004
オジェ、他 [42ページ]実験的なRFC3684TBRPF2004年2月
[5] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[5] ベイカー、F.、エド、「IPバージョン4ルータのための要件」、RFC1812、6月1995日
14.2. Informative References
14.2. 有益な参照
[6] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[6]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[7] Ogier, R., Message in IETF email archive for MANET,
ftp://ftp.ietf.org/ietf-mail-archive/manet/2002-02.mail,
February 2002.
[7] オジェ、R.、マネ、 ftp://ftp.ietf.org/ietf-mail-archive/manet/2002-02.mail 、2002年2月のためのIETFメールアーカイブのMessage。
[8] Ogier, R., "Topology Dissemination Based on Reverse-Path
Forwarding (TBRPF): Correctness and Simulation Evaluation",
Technical Report, SRI International, October 2003.
[8] オジェ、「トポロジー普及は以下を進める(TBRPF)逆経路に基づいた」R. 「正当性とシミュレーション評価」、技術報告書、SRIインターナショナル、10月2003日
[9] Ogier, R., Message in IETF email archive for MANET,
ftp://ftp.ietf.org/ietf-mail-archive/manet/2002-03.mail, March
2002.
[9] オジェ、R.、マネ、 ftp://ftp.ietf.org/ietf-mail-archive/manet/2002-03.mail 、2002年3月のためのIETFメールアーカイブのMessage。
[10] Ogier, R., "Efficient Routing Protocols for Packet-Radio
Networks Based on Tree Sharing", Proc. Sixth IEEE Intl. Workshop
on Mobile Multimedia Communications (MOMUC'99), November 1999.
[10] オジェ、R.、「木の共有に基づいたパケット無線ネットワークに、効率的なルーティング・プロトコル」、Proc。 第6IEEE Intl。 1999'年11月のモバイルマルチメディアコミュニケーション(MOMUC'99)に関するワークショップ。
[11] Bellur, B. and R. Ogier, "A Reliable, Efficient Topology
Broadcast Protocol for Dynamic Networks", Proc. IEEE INFOCOM
'99, New York", March 1999.
[11]BellurとB.とR.オジェ、「信頼できて、ダイナミックなネットワークに、効率的なトポロジー放送プロトコル」、Proc。 「IEEE INFOCOM'99、ニューヨーク」は1999を'行進させます。
[12] Clausen, T. and P. Jacquet, Eds., "Optimized Link State Routing
Protocol (OLSR)", RFC 3626, October 2003.
[12] クローゼンとT.とP.ジャケ、Eds「最適化されたリンク州はプロトコル(OLSR)を発送すること」でのRFC3626、2003年10月。
[13] Bertsekas, D. and R. Gallager, "Data Networks", Prentice-Hall,
1987.
[13]BertsekasとD.とR.Gallager、「データ網」の、そして、新米のホールの1987。
[14] Perkins, C., Belding-Royer, E. and S. Das, "IP Flooding in Ad
Hoc Mobile Networks", Work in Progress, November 2001.
[14] 「臨時のモバイルネットワークでのIP氾濫」というパーキンス、C.、ベルディング-ロワイエー、E.、およびS.ダスは進歩、2001年11月に働いています。
[15] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet address
for transmission on Ethernet hardware", STD 37, RFC 826,
November 1982.
[15] プラマー、D.、「イーサネットアドレス決議は以下について議定書の中で述べます」。 「または、ネットワーク・プロトコルを変換するのは、イーサネットハードウェアの上でイーサネットがトランスミッションのためのアドレスであると48.bitに扱う」STD37、RFC826、1982年11月。
[16] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998.
[16]NartenとT.とNordmarkとE.とW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[17] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[17] パーキンス、C.、エド、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
Ogier, et al. Experimental [Page 43] RFC 3684 TBRPF February 2004
オジェ、他 [43ページ]実験的なRFC3684TBRPF2004年2月
[18] Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740,
December 1999.
[18]ColtunとR.とファーガソンとD.とJ.Moy、「IPv6"、RFC2740、1999年12月のためのOSPF。」
[19] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[19] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[20] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[20] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[21] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[21] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[22] Nikander, P., "IPv6 Neighbor Discovery Trust Models and
Threats", Work in Progress, April 2003.
[22] P.と、「IPv6隣人発見信頼モデルと脅威」というNikanderは進歩、2003年4月に働いています。
[23] Arkko, J., "SEcure Neighbor Discovery (SEND)", Work in Progress,
June 2003.
[23] J.、「安全な隣人発見(発信する)」というArkkoは進歩、2003年6月に働いています。
Ogier, et al. Experimental [Page 44] RFC 3684 TBRPF February 2004
オジェ、他 [44ページ]実験的なRFC3684TBRPF2004年2月
Authors' Addresses
作者のアドレス
Richard G. Ogier SRI International 333 Ravenswood Ave. Menlo Park, CA 94025 USA
リチャードG.オジェSRIインターナショナル333レーヴンズウッドAve。 メンローパーク、カリフォルニア94025米国
Phone: +1 650 859-4216 Fax: +1 650 859-4812 EMail: ogier@erg.sri.com
以下に電話をしてください。 +1 650 859-4216Fax: +1 650 859-4812 メールしてください: ogier@erg.sri.com
Fred L. Templin Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
フレッドL.テンプリンノキア313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
Phone: +1 650 625 2331 Fax: +1 650 625 2502 EMail: ftemplin@iprg.nokia.com
以下に電話をしてください。 +1 650 625、2331Fax: +1 2502年の650 625メール: ftemplin@iprg.nokia.com
Mark G. Lewis SRI International 333 Ravenswood Ave. Menlo Park, CA 94025 USA
G.ルイスSRIインターナショナル333レーヴンズウッドAveをマークしてください。 メンローパーク、カリフォルニア94025米国
Phone: +1 650 859-4302 Fax: +1 650 859-4812 EMail: lewis@erg.sri.com
以下に電話をしてください。 +1 650 859-4302Fax: +1 650 859-4812 メールしてください: lewis@erg.sri.com
Ogier, et al. Experimental [Page 45] RFC 3684 TBRPF February 2004
オジェ、他 [45ページ]実験的なRFC3684TBRPF2004年2月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Ogier, et al. Experimental [Page 46]
オジェ、他 実験的[46ページ]
一覧
スポンサーリンク
