idnits 2.17.1 draft-ietf-manet-term-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 185: '...home address, it SHOULD select and use...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (17 November 1998) is 9292 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '9' on line 184 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. E. Perkins 3 INTERNET DRAFT Sun Microsystems 4 17 November 1998 6 Mobile Ad Hoc Networking Terminology 7 draft-ietf-manet-term-01.txt 9 Status of This Memo 11 This document is a submission by the Mobile Ad Hoc Networking Working 12 Group of the Internet Engineering Task Force (IETF). Comments should 13 be submitted to the manet@itd.nrl.navy.mil mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at 24 any time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To view the entire list of current Internet-Drafts, please check 28 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 29 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 30 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 31 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 33 Abstract 35 This document presents conventional definitions for many terms to be 36 used during the discussion of various algorithms for enabling ad hoc 37 networks of mobile computers, particularly over wireless media. 39 1. Introduction 41 This document presents conventional definitions for many terms to be 42 used during the discussion of various algorithms for enabling ad hoc 43 networks of mobile computers, particularly over wireless media. With 44 commonly agreed definitions, it is expected that protocol designers 45 will be able to discuss more clearly the advantages and disadvantages 46 of their algorithms. 48 2. Definitions for Mobile Ad Hoc Network Terms 50 asymmetric link 52 A link with transmission characteristics which are different 53 depending upon the relative position or design characteristics 54 of the transmitter and the receiver of data on the link. For 55 instance, the range of one transmitter may be much higher than 56 the range of another transmitter on the same medium. 58 bandwidth 60 The total capacity of a link to carry information (typically 61 bits). 63 bandwidth utilization 65 The actual amount of information delivered over a link, 66 expressed as a percent of the available bandwidth on that link. 68 base station 70 A centralized node coordinating the channel access of a 71 population of mobile nodes within its transmission range. 73 beacon 75 A control message issued by a node (especially, a base station) 76 informing all the other nodes in its neighborhood of the 77 continuing presence of the node, possibly along with additional 78 status information. 80 channel 82 A subdivision of the physical medium allowing possibly shared 83 independent uses of the medium. Channels may be made available 84 by subdividing the medium into distinct time slots, or distinct 85 spectral bands, or decorrelated coding sequences. 87 channel access protocol 89 A protocol for mediating access to, and possibly allocation 90 of, the various channels available within the physical 91 communications medium. Nodes participating in the channel 92 access protocol can communicate only when they have uncontested 93 access to the medium, so that there will be no interference. 95 cluster 97 A group of nodes located within close physical proximity, 98 typically all within range of one another, which can be 99 grouped together for the purpose of limiting the production and 100 propogation of routing information. 102 cluster head 104 A cluster head is a node (often elected in the cluster 105 formation process) that has complete knowledge about group 106 membership and link state information in the cluster. Each 107 cluster should have one and only one cluster head. 109 cluster member 111 All nodes within a cluster EXCEPT the cluster head are called 112 members of that cluster. 114 communications medium 116 A communication channel such as free space, cable or fiber 117 through which data can be transmitted 119 communications technology 121 The means employed by two nodes to transfer data 123 control message 125 Information passed between two or more network nodes for 126 maintaining protocol state which is not associated to any 127 specific application. 129 convergence 131 The process of approaching a state of equilibrium in which all 132 nodes in the network agree on a consistent collection of state 133 about the topology of the network, and in which no further 134 control messages are needed to establish the consistency of the 135 network topology. 137 convergence time 139 The time which is required for a network to reach convergence 140 after an event (typically, the movement of a mobile node) which 141 changes the network topology. 143 distance vector 145 A style of routing protocol in which, for each desired 146 destination, a node maintains information about the distance 147 to that destination, and a vector (next hop) towards that 148 destination. 150 fairness 152 A property of channel access protocols whereby a medium is 153 made fairly equal to all eligible nodes on the link. Fairness 154 does not strictly imply equality, especially in cases where 155 nodes are given link access according to unequal priority or 156 classification. 158 flooding 160 The process of delivering data or control messages to every 161 node within the ad hoc network. 163 forwarding node 165 A node within an ad hoc network which performs the function of 166 forwarding datagrams from one of its neighbors to another. 168 goodput 170 The total bandwidth used, less the volume of control messages 171 and protocol overhead from the data packets. 173 hidden-terminal problem 175 The problem whereby a transmitting node can fail in its attempt 176 to transmit data because of destructive interference which is 177 only detectable at the receiving node, not the transmitting 178 node. 180 home address 182 An IP address that is assigned for an extended period of time 183 to a mobile node. It remains unchanged regardless of where 184 the node is attached to the Internet [9]. If a node has more 185 than one home address, it SHOULD select and use a single home 186 address when participating in the ad hoc network. 188 host 190 Any node that is not a router. 192 interface 194 A node's attachment to a link. 196 interface index 198 An 8-bit quantity which uniquely identifies an interface among 199 a given node's interfaces. 201 laydown 203 The relative physical location of the nodes within the ad hoc 204 network. 206 link 208 A communication facility or physical medium that can sustain 209 data communications between multiple network nodes, such as an 210 Ethernet (simple or bridged). A link is the layer immediately 211 below IP. 213 link-layer address 215 A link-layer identifier for an interface, such as IEEE 802 216 addresses on Ethernet links. 218 link state 220 A style of routing protocol in which every node within the 221 network is expected to maintain information about every link 222 within the network topology. 224 link-level acknowledgement 226 A protocol strategy, typically employed over wireless 227 media, requiring neighbors to acknowledge receipt of packets 228 (typically unicast only) from the transmitter. Such strategies 229 aim to avoid packet loss or delay resulting from lack of, or 230 unwanted characteristics of, higher level protocols. 232 local broadcast 234 The delivery of data to every node on a link (i.e., within 235 range of the transmitter). 237 loop-free 239 A property of routing protocols whereby the path taken by a 240 data packet from source to destination never transits the same 241 intermediate node twice before arrival at the destination. 243 MAC-layer address 245 An address (sometimes called the link address) associated with 246 the link interface of a node on a physical link. 248 mobility factor 250 The relative frequency of node movement, compared to the 251 convergence time of the routing protocols used in the ad hoc 252 network. 254 mobility security association 256 A collection of security contexts, between a pair of routers, 257 which may be applied to protocol messages exchanged between 258 them. 260 neighbor 262 a "neighbor" is any other node to which data may be propagated 263 directly over the communications medium without relying the 264 assistance of any other forwarding node 266 neighborhood 268 All the nodes which can receive data on the same link from one 269 node whenever it transmits data. 271 next hop 273 A neighbor which has been designated to forward packets along 274 the way to a particular destination. 276 node 278 A device that implements IP. 280 packet 282 An IP header plus payload. 284 pathloss 286 A reduction in signal strength caused by traversing the 287 physical medium constituting the link. 289 pathloss matrix 291 A matrix of coefficients describing the pathloss between any 292 two nodes in an ad hoc network. When the links are asymmetric, 293 the matrix is also asymmetric. 295 payload 297 The actual data within a packet, not including network protocol 298 headers which were not inserted by an application. 300 prefix 302 A bit string that consists of some number of initial bits of an 303 address. 305 route table 307 The table where ad hoc nodes keep routing (including next hop) 308 information for various destinations. 310 route entry 312 An entry for a specific destination (unicast or multicast) in 313 the route table. 315 route establishment 317 The process of setting up a route between a source and a 318 destination. 320 route activation 322 The process of putting a route into use after it has been set 323 up. 325 router 327 A node that forwards IP packets not explicitly addressed to 328 itself. 330 scalability 332 Wide applicability of a protocol to large as well as small 333 populations of nodes participating in the protocol. 335 scenario 337 The tuple 338 characterizing a class of ad hoc networks. 340 security context 342 A security context between two routers defines the manner in 343 which two routers choose to mutually authentication each other, 344 and indicates an authentication algorithm and mode. 346 Security Parameter Index (SPI) 348 An index identifying a security context between a pair of 349 routers among the contexts possible in the mobility security 350 association. 352 signal strength 354 The detectable power of the signal carrying the data bits, as 355 seen by the receiver of the signal. 357 source route 359 A source route from node A to node B is an ordered list of home 360 addresses, starting with the home address of node A and ending 361 with the home address of the node B. Between A and B, the 362 source route includes an ordered list of all the intermediate 363 hops between A and B, as well as the interface index of the 364 interface through which the packet should be transmitted to 365 reach the next hop. 367 spatial re-use 369 Simultaneous use of channels with identical or close physical 370 characteristics, but located spatially far enough apart to 371 avoid interference (i.e., co-channel interference) 373 system-wide broadcast 375 Same as flooding, but used in contrast to local broadcast. 377 throughput 379 The amount of data from a source to a destination processed 380 by the protocol for which throughput is to be measured for 381 instance, IP, TCP, or the MAC protocol. 383 topology 385 A network can be viewed abstractly as a "graph" whose 386 "topology" at any point in time is defined by set of "points" 387 connected by "edges." 389 triggered update 391 An unsolicited route update transmitted by an router along a 392 path to a destination. 394 Chair's Address 396 The working group can be contacted via the current chairs: 398 M. Scott Corson Joseph Macker 399 Institute for Systems Research Information Technology Division 400 University of Maryland Naval Research Laboratory 401 College Park, MD 20742 Washington, DC 20375 403 Phone: +1-301-405-6630 +1-202-767-2001 404 E-mail: corson@isr.umd.edu macker@itd.nrl.navy.mil 406 Author's Address 408 Questions about this memo can be directed to: 410 Charles E. Perkins 411 Advanced Network Development 412 Sun Microsystems Laboratories 413 901 San Antonio Rd. 414 Palo Alto, CA 94303 415 +1-650-786-6464 416 +1-650-786-6445 417 charles.perkins@sun.com