idnits 2.17.1 draft-ietf-manet-imep-spec-00.txt: -(420): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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-25) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 2 instances of lines with non-ascii characters in the document. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 234 has weird spacing: '...nnected to a...' == Line 366 has weird spacing: '...al link consi...' == Line 544 has weird spacing: '...several fixed...' == Line 545 has weird spacing: '...ollowed by a...' == Line 546 has weird spacing: '... 32-bit word ...' == (7 more instances...) -- 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 (November 26, 1997) is 9647 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) == Outdated reference: A later version (-01) exists of draft-ietf-manet-term-00 -- Possible downref: Normative reference to a draft: ref. '1' Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft M.S. Corson 3 Expiration: May 26, 1997 University of Maryland 4 V. Park 5 Naval Research Laboratory 6 November 26, 1997 8 An Internet MANET Encapsulation Protocol (IMEP) Specification 9 draft-ietf-manet-imep-spec-00.txt 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Distribution of this memo is unlimited. 31 Abstract 33 This memo describes a multipurpose network-layer protocol---named the 34 Internet MANET Encapsulation Protocol (IMEP)---designed to support 35 the operation of many routing algorithms or other upper layer 36 protocols intended for use in Mobile Ad hoc Networks (MANET). The 37 protocol incorporates mechanisms for supporting link status sensing, 38 control message aggregation and encapsulation, broadcast reliability, 39 network-layer address resolution and provides hooks for interrouter 40 security authentication procedures. The IMEP also puts forth a 41 framework or architecture for MANET router and interface 42 identification and addressing. 44 The present specification is high-level and incomplete, giving only a 45 behavioral protocol description and proposed packet format. This 46 version of this draft is intended primarily to acquaint readers with 47 the concept of the protocol. A subsequent revision will detail the 48 protocol's mechanisms and data structures. 50 1. Introduction 52 The primary purpose of the Internet MANET Encapsulation Protocol 53 (IMEP) is to improve overall network performance by reducing the 54 "number" of network control message broadcasts through encapsulation 55 and aggregation of multiple MANET control messages (e.g. routing 56 protocol packets, acknowledgements, link status sensing messages, 57 network-level address resolution, etc.) into larger IMEP messages. 58 Usage of the IMEP is desirable because per-message, multiple access 59 delay in contention-based schemes such as CSMA/CA, IEEE 802.11, FAMA 60 etc. is significant, and thus favors the use of fewer, larger 61 messages. It would also be useful in reservation-based, time-slotted 62 access schemes where smaller packets must be aggregated into 63 appropriately-sized IP packets for transmission in a given time slot. 64 Upper layer protocols *other than routing* may make use of this 65 encapsulation functionality for the same purpose. 67 Its secondary purpose concerns the commonality of certain 68 functionality in many network-level routing algorithms. Many 69 algorithms intended for use in a MANET will require common 70 functionality such as link status sensing, security authentication 71 with adjacent routers, broadcast reliability of network control 72 messages, etc. This common functionality can be extracted from these 73 individual protocols and put into a unified, generic protocol useful 74 to all. MANET routing algorithms would also benefit from a common 75 approach to router and interface identification and addressing, and 76 this protocol provides a framework for unifying the protocols under a 77 common architecture. 79 The IMEP will run at the network layer (see Figure 1), and will be an 80 adjunct to whichever network routing protocol is using it. Routing 81 control packets will be encapsulated in IMEP messages, which will be 82 further encapsulated into IP packets. 84 +------+ +-----+ +-----+ +-----+ 85 |Telnet| | FTP | | TFTP| ... | ... | 86 +------+ +-----+ +-----+ +-----+ +---------+ 87 | | | | | Routing | 88 +-----+ +-----+ +-----+ +---------+ 89 | TCP | | UDP | ... | ... | | 90 +-----+ +-----+ +-----+ +---------+ 91 | | | | IMEP | 92 +----------------------------------------+ +---------+ 93 | Internet Protocol & ICMP & IGMP & IMEP | | 94 +----------------------------------------+ +---------+ 95 | | IP | 96 +---------------------------+ +---------+ 97 | Local Network Protocol | 98 +---------------------------+ 100 Protocol Relationships Encapsulation 102 Figure 1 104 2.0 Terminology 106 This section provides definitions for the terminology used throughout 107 this document. Many of these definitions may be replaced by or 108 merged with those of the MANET working group's terminology draft [1] 109 now under development. 111 MANET router or router: 112 A device---identified by a "unique Router ID" (RID)---that exe- 113 cutes a MANET routing protocol and, under the direction of 114 which, forwards IP packets. It may have multiple interfaces, 115 each identified by an IP address. Associated with each inter- 116 face is a physical-layer communication device. These devices 117 may employ wireless or hardwired communications, and a router 118 may simultaneously employ devices of differing technologies. 119 For example, a MANET router may have four interfaces with 120 differing communications technologies: two hardwired (Ethernet 121 and FDDI) and two wireless (spread spectrum and impulse radio). 123 medium: 124 A communication channel such as free space, cable or fiber 125 through which connections are established. 127 communications technology: 128 The means employed by two devices to transfer information 129 between them. 131 connection: 133 A physical-layer connection---which may be through a wired or 134 wireless medium---between a device attached to an interface of 135 one MANET router and a device utilizing the same communications 136 technology attached to an interface on another MANET router. 137 From the perspective of a given router, a connection is a 138 (interface, adjacency) pair. 140 link: 141 A "logical connection" consisting of the logical *union* of one 142 or more connections between two MANET routers. Thus a link may 143 consist of a heterogeneous combination of connections through 144 differing media using different communications technologies. 146 neighbor: 147 From the perspective of a given MANET router, a "neighbor" is 148 any other router to which it is connected by a link. 150 adjacency: 151 The name given to an "interface on a neighboring router". 153 topology: 154 A network can be viewed abstractly as a "graph" whose "topology" 155 at any point in time is defined by set of "points" connected by 156 "edges". (This term comes from the branch of mathematics bear- 157 ing the same name that is concerned with those properties of 158 geometric configurations (such as point sets) which are unal- 159 tered by elastic deformations (such as stretching) that are 160 homeomorphisms.) 162 physical-layer topology: 163 A topology consisting of connections (the edges) through the 164 *same* communications medium between devices (the points) com- 165 municating using the *same* communications technology. Multi- 166 ple physical-layer topologies may exist for a given medium and 167 communications technology if adaptive or proactive power con- 168 trol, or other physical-layer mechanisms are employed. 170 network-layer topology: 171 A topology consisting of links (the edges) between MANET routers 172 (the points) which is used as the basis for MANET routing. Since 173 "links" are the logical union of physical-layer "connections", 174 it follows that the "network-layer topology" is the logical 175 union of the various "physical-layer topologies". 177 IP routing fabric: 178 The heterogeneous mixture of communications media and technolo- 179 gies through which IP packets are forwarded whose topology is 180 defined by the network-layer topology. 182 3.0 Protocol Overview 184 The mechanisms contained in the IMEP are: 186 Link/Connection Status Sensing 188 Control Message Aggregation 190 Broadcast Reliability 192 Network-layer Address Resolution 194 Security Authentication 196 3.1 Link/Connection Status Sensing 198 3.1.1 Definition of Link/Connection Status 200 Many routing protocols require accurate knowledge of the status of 201 links/connections between neighboring routers. "Link status" in the 202 IP routing fabric is determined from the union of the status of 203 physical-layer "connections" between interfaces. 205 The relationship of interfaces, adjacencies, connections and links is 206 depicted in Figure 2 from the perspective of router i. Router i has 207 two interfaces f1 and f2, each of which has a physical-layer connec- 208 tion with multiple interfaces attached to other routers---these 209 interfaces are referred to as adjacencies from router i's perspective 210 and are numbered with c's. In this figure, there are two connections 211 (f1,c1) and (f2,c2), the logical union of which composes the logical 212 link (i,k) between routers i and k. 214 +----------+ 215 | Router i | 216 +----------+ 217 +--------------+ +--------------+ 218 | Interface f1 | | Interface f2 | 219 +--------------+ +--------------+ 220 | | 221 | | 222 | | 223 | | 224 | | 225 | | 226 +--------------+ +--------------+ 227 | Adjacency c1 | | Adjacency c2 | 228 +--------------+ +--------------+ 229 +----------+ 230 | Router k | 231 +----------+ 233 Figure 2: Shown from router i's perspective, interfaces f1 and f2 are 234 connected to adjacencies c1 and c2 via connections (f1,c1) and 235 (f1,c2)---the union of which forms link (i,k). 237 The status of an connection may be INcoming or OUTgoing (either of 238 which meaning it is unidirectional) or BIdirectional. A unidirec- 239 tional link is composed from one or more similarly-directed, uni- 240 directional connections. A BIdirectional link may be composed from 241 the union of one or more bidirectional connections, or two or more 242 oppositely-directed, unidirectional connections, or some combination 243 thereof. A link which is present (i.e. which has a non-null status, 244 and is either uni or bidirectional), is referred to as "UP". A link 245 which is not present (i.e. which has a null status) is referred to as 246 "DOWN". 248 The IMEP may be configured to run in the following "connection notif- 249 ication" modes: 251 BI-directional: 252 This mode requires that physical-layer connectivity between two 253 interfaces be established in *both* IN and OUT directions before 254 an connection is considered *present* and the upper layer rout- 255 ing protocol is subsequently notified. 257 UNI-directional: 258 This mode requires that physical-layer connectivity between two 259 interfaces need only be established in one direction (IN or OUT) 260 before an connection is considered present and the upper layer 261 routing protocol is subsequently notified. 263 As determined by the connection notification mode, the upper layer 264 routing protocol is notified whenever there is a change (addition, 265 modification, deletion) in the status of an interface's connections. 266 This notification is implemented via a callback functions defined in 267 the MANET routing policy/IMEP interface (more on this later) 269 3.1.2 Link/Connection Status Sensing Packet Exchange Mechanism 271 The IMEP uses a combination of BEACON and HELLO packets (and other 272 packets to be described shortly) to ascertain connection (and 273 indirectly link) status. On initialization, an interface under the 274 control of IMEP broadcasts (the format of a BEACON packet is speci- 275 fied in section 4.0) to all adjacencies; i.e. interfaces that are 276 only one hop away such as those on the same Ethernet subnet, or those 277 within wireless transmission range of the broadcasting interface. 278 (Note: Usage of the term "broadcast" here means to transmit a *sin- 279 gle* copy of a packet to *all* interfaces reachable over one hop. As 280 is the convention with other Internet routing protocols, this is done 281 using IP multicast. An IP multicast address "ALL_IMEP_ROUTERS" will 282 be reserved, and all MANET router interfaces will be configured to 283 listen for this address.) a BEACON packet The purpose of a BEACON 284 packet is to alert any adjacencies of the existence and identity of 285 the broadcasting interface; an interface's identity is its IP 286 address. The interface must ensure that a BEACON packet (or other 287 "equivalent" packet, more on this later) is transmitted at least once 288 every BEACON_PERIOD (BP) time units; i.e. no more than BP time units 289 may pass between subsequent transmissions of a BEACON (or "BEACON- 290 equivalent") packet. 292 Reception of a BEACON at an interface implies either reconfirmation 293 or creation of "IN" (read "INcoming") status of a connection at that 294 interface, depending on whether or not the connection already exists, 295 respectively. Thus, BEACONs serve to tell a receiving interface that 296 "someone else is out there." Once present, the status remains for 297 MAX_BEACON_TIME (MBT) time units, at which time it expires (i.e. 298 times out) if no subsequent BEACONs have been received; i.e. the link 299 is declared DOWN and is removed from the data structures. Creation 300 or loss of IN status may require notification of the upper level 301 routing protocol, depending on whether or not the logical link status 302 to which this connection is associated has been affected. 304 HELLO (or "HELLO-equivalent") packets are used to respond to BEACONs. 305 The purpose of a HELLO packet is to let a "BEACONing" node know that 306 someone hears its BEACON. A HELLO packet contains the identity (i.e. 307 IP interface) of the interface broadcasting the HELLO and the iden- 308 tity of the BEACONing interface to which it is responding. A HELLO 309 packet is generated immediately in response to a BEACON reception, 310 and is placed in the "Awaiting Broadcast" (AB) buffer (more on the 311 functioning of this buffer later). Subsequently, as long as the 312 interface is considered UP (i.e. IN or BI), a HELLO packet must be 313 generated at least once every BP time units; i.e. no more than BP 314 time units may pass between subsequent generations of a HELLO packet. 316 Reception of a HELLO at an interface implies either reconfirmation or 317 creation of "BIdirectional" status of an connection at that inter- 318 face, depending on whether or not the connection already exists, 319 respectively. This is because reception of HELLO packet confirms 320 that someone hears this interface (i.e. that is has OUTgoing status), 321 and simultaneously confirms that it itself can receive them and, 322 hence, also has INcoming status for that connection. 324 HELLO packets may be broadcast in one of two "Hello" modes: 326 Single Interface (SI): 327 An interface only sends HELLOs in response to BEACONs it 328 receives. This is the standard mode which permits efficient 329 link-layer detection of IN and BI connections. It also permits 330 "network-layer detection" (by a routing protocol) of BIdirec- 331 tional links composed of oppositely-directed, unidirectional 332 links on the same or differing routers. 334 Multiple Interface (MI): 335 An interface sends HELLOs in response to BEACONs it receives, 336 and it also sends HELLOS in response to the BEACONs received by 337 *all* other interfaces attached to its router. This mode is 338 necessary to permit "link-layer detection" of BIdirectional 339 links composed of oppositely-directed, unidirectional connec- 340 tions between neighboring routers. Note that only by using this 341 Hello mode can an interface determine that it itself has "OUTgo- 342 ing" status without also having "INcoming" and, hence, BIdirec- 343 tional status. 345 To make this clear, consider Figure 3. 347 +----------+ 348 | Router i | 349 +----------+ 350 +--------------+ +--------------+ 351 | Interface f1 | | Interface f2 | 352 +--------------+ +--------------+ 353 | IN ^ 354 | | 355 | | 356 | | 357 | | 358 IN V | 359 +--------------+ +--------------+ 360 | Adjacency c1 | | Adjacency c2 | 361 +--------------+ +--------------+ 362 +----------+ 363 | Router k | 364 +----------+ 366 Figure 3: A bidirectional link consisting of two oppositely- 367 directed connections. 369 Assume that SI Hello mode is being used, and the wireless direc- 370 tional connectivity is as shown. From router i's perspective, 371 it can only receive over interface f2, and thus classifies con- 372 nection (f2,c2) as IN. It is unaware that its BEACON packets 373 being broadcast from interface f1 are being received at inter- 374 face c1 on router k. However, if MI mode is used, then router k 375 will advertise the reception of BEACON packers from f1 at c1 376 over connection (f2,c2) thereby informing router i that connec- 377 tion (f1,c1) should be classified as OUT. Of course, the 378 reverse but same is true from router k�s perspective. 380 The additional functionality provided by the MI mode comes at 381 the cost of broadcasting a HELLO out *every* interface instead 382 of only the interface over which the corresponding BEACON was 383 received. This creates more HELLO overhead. For a given net- 384 work, this cost must be balanced against the frequency of 385 occurrence of the situation depicted in figure 3. 387 3.2 Control Message Aggregation 389 MANET routing protocols exchange control information in the form of 390 routing control messages or "objects". To minimize the number of 391 channel accesses generated by routing control traffic, the IMEP 392 aggregates and encapsulates these objects into larger "IMEP object 393 blocks". The objects are treated as "opaque" objects by the IMEP 394 protocol; i.e. IMEP is not aware of the contents of the objects, only 395 of the protocol "type" of the object block (necessary for protocol 396 demultiplexing at a receiver) and the length of each object. These 397 object blocks are contained in yet larger "IMEP messages" which are 398 passed to the IP layer for encapsulation and forwarding. 400 3.3 Broadcast Reliability 402 IMEP supports reliable and unreliable delivery of opaque protocol 403 objects, where reliable delivery is also guaranteed to be delivery 404 "in order" of transmission. IMEP uses a "point-to-multipoint selec- 405 tive repeat" algorithm to guarantee broadcast or multicast reliabil- 406 ity and ordered delivery. This approach eliminates unnecessary 407 retransmissions of the type commonly associated with "go back n" 408 algorithms, and is in keeping with the greater IMEP goal of minimiz- 409 ing the number of required channel accesses. 411 To support reliability, each object block is given a SEQUENCE number, 412 and is broadcast with that number and with a set of its intended 413 receivers referred to as its "response list". When broadcast, a copy 414 of the object block and its associated response list (i.e. the set of 415 neighbors that are required to acknowledge this block) are stored. A 416 retransmission timer is set to RETRANS_PERIOD (RP) time units which, 417 upon expiration, will cause the object to be rebroadcast to any 418 neighbors which have not acknowledged the object (this causes the 419 retransmission timer to be set again to RP). The time the packet was 420 initially broadcast is also stored. If the object�s response list is 421 not empty (i.e it has not been acknowledged by some adjacencies) 422 after MAX_RETRANS_TIME (MRT) time units, the connections to those 423 adjacencies are declared DOWN. 425 Acknowledgements (ACKs) are sent in response to object block recep- 426 tions when (i) reliable delivery is indicated and (ii) when the 427 receiver is contained in the response list. Once a node has ACKed a 428 given block, it will be removed from the block's response list so 429 that it will not be required to ACK any future retransmissions. 431 3.4 Network-level Address Resolution 433 IMEP puts forth a framework or architecture for MANET router and 434 interface identification and addressing. IMEP operates simultane- 435 ously on two different topological levels: the "logical network" 436 topology level---which is concerned with interrouter connectivity--- 437 and the "physical" topology level---which is concerned with interface 438 connectivity. Router IDs (RID) identify routers in the logical 439 topology, and IP addresses identify interfaces in the physical topol- 440 ogy. There may be *multiple* IP addresses associated with a given 441 RID. 443 The purpose of the Network-level Address Resolution Protocol (NARP) 444 incorporated within IMEP is to dynamically discover the mapping 445 between RIDs and IP addresses when necessary. This is envisioned 446 typically only to occur when a new connection is discovered, as it is 447 necessary to be able to associate an interface (an IP address) with a 448 router (an RID). 450 +----------+ 451 | Router | RID 452 +----------+ 453 | | 454 +--------------+ +--------------+ 455 | Interface | | Interface | IP Address 456 +--------------+ +--------------+ 457 | | 458 +--------------+ +--------------+ 459 | Phys Device | | Phys Device | MAC Address 460 +--------------+ +--------------+ 462 Figure 4: RIDs, IP and MAC addresses 464 While it is true that---as currently defined---RIDs are not 465 "addresses" in the strict sense, they do uniquely identify a router 466 for purposes of internal routing computations and somewhat resemble a 467 logical "router address". Thus, the IP address-to-RID mapping is 468 similar in spirit to IP address-to-MAC address mapping performed by 469 the present ARP protocol. Each mapping simply associates an IP 470 address with another identifier as shown in Figure 4. As with ARP, a 471 "reverse" mapping is also defined as the Reverse Network-level 472 Address Resolution Protocol (RNARP). The two mappings are shown in 473 Figure 5. 475 ARP: IP --> MAC RARP: MAC --> IP 477 NARP: IP --> RID RNARP: RID --> IP 479 Figure 5: ARP/RARP and NARP/RNARP 481 When necessary, NARP/RNARP packets are generated, aggregated with 482 other network control traffic and reliably broadcast within the 483 object block of a IMEP message. However, unlike other control 484 traffic, the NARP/RNARP objects are not opaque with respect to IMEP 485 as they are generated and consumed by the IMEP protocol. 487 3.5 Security Authentication 489 It is expected that the IMEP protocol will include hooks for security 490 authentication in a fashion similar to that already performed by OSPF 491 and other routing protocols. This will include, among others, an 492 authentication type field in the IMEP message header. 494 3.6 BEACON and HELLO "Equivalency" 496 As stated earlier, BEACON and HELLO packets are necessary for ascer- 497 taining current connection status. From the perspective of a given 498 router, BEACONs announce the presence of a broadcasting interface, 499 and HELLOs simultaneously announce the presence of an adjacency and 500 that the adjacency can receive from the broadcasting interface. How- 501 ever, it should be clear that the same information can be gleaned 502 from other IMEP packets. Specifically, OBJect block transmissions 503 (which may contain routing, NARP/RNARP and/or security objects) sig- 504 nal the presence of a broadcasting interface and are, in this sense, 505 "equivalent" to BEACON packets. Similarly, ACKnowledgements both 506 announce the presence of an adjacency and, through the process of 507 acknowledgement, confirm that the adjacency recently received from 508 the broadcasting interface. Thus, in this sense, ACKs are equivalent 509 to HELLOs. The equivalency is depicted in the Figure 6. 511 BEACON--> 512 OBJ --> 513 +----------+ +-------------+ +-------------+ 514 | Router i |-| Interface f | - - - - | Adjacency c | 515 +----------+ +-------------+ +-------------+ 516 <-- HELLO 517 <-- ACK 519 Figure 6: BEACON and HELLO Equivalency 520 Transmission or reception of a BEACON or HELLO equivalent packet 521 affects the link status sensing timers as would transmission or 522 reception of a BEACON or HELLO, respectively. Thus, during periods 523 of heavy data, it is expected that BEACONs and HELLOs will rarely be 524 transmitted as their respective "equivalent" packets will serve their 525 role in link status sensing. During periods of light or no traffic, 526 BEACONs or HELLOs will be transmitted as necessary to satisfy the 527 aforementioned timing requirements. 529 3.7 Connection Failure Detection 531 It should be noted here that there are two events that can signal 532 connection failure: expiration of the MRT timer or expiration of the 533 BPT timer. Thus the CONN_DEAD_TIME (CDT) value---the time at which a 534 connection, once UP (i.e. IN, OUT/BI), will be declared DOWN if its 535 UP status is not confirmed---is CDT = min(MBT,MRT). Note that 536 separate timers are used to monitor IN and OUT connection status. 537 Thus, a connection may lose its OUT status while still retaining IN 538 status and vice versa. Obviously, a connection satisfying both IN 539 and OUT timing requirements is marked at BI. 541 4.0 Protocol Message Format 543 The following describes the message format of the proposed protocol. 544 An IMEP message format consists of several fixed, mandatory fields 545 followed by a self-formatting byte stream. The stream is aligned 546 along "byte" boundaries---not 32-bit word boundaries---to save 547 transmission overhead at the cost of extra processing at a router. 548 An IMEP message typically contains at least one of several optional 549 blocks. A message containing no blocks is a BEACON message. 551 ::= 552 [Ack Block] 553 [Hello Block] 554 [Object Block] 556 The fixed field formats are: 558 31 24 23 16 15 8 7 0 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 1 | (a) | (b) | (c) | Opt. blocks... 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 (a) IMEP_VERSION (4-bit unsigned integer): 564 This field specifies the protocol version number, which may 565 range from 0-15. The initial protocol version number is zero. 567 (b) BLOCK_FLAGS (4-bit bitmask): 568 This field contains single-bit flags, each of which specifies 569 the presence (flag = 1) or absence (flag = 0) of a block. All 570 bits set equal to zero indicates that this is a BEACON packet--a 571 packet intended only to announce the existence of this interface 572 (whose IP address is contained in the IP header) to any poten- 573 tial adjacencies. 575 bit 27: Ack block flag 577 bit 26: Hello block flag 579 bit 25: Object block flag 581 bit 24: unused 583 (c) IMEP_LENGTH (16-bit unsigned integer): 584 This field specifies the total length of an IMEP message 585 (measured in bytes) which must lie in the following range: 587 3 < IMEP_LENGTH <= MAX_IMEP_LENGTH <= 65535 589 The ACK Block format is: 591 ::= 593 ::= | 594 596 NUM_ACKS (8-bit unsigned integer): 597 This field indicates the length of the Ack List which may range 598 from 0-255. 600 The ACK format is: 601 31 24 23 16 15 8 7 0 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 1 ...self-formatting bytestream contents | (a) | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 2 | (b) Ack'ed IP Interface Address | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 (a) SEQUENCE (8-bit unsigned integer): 609 Indicates the sequence number of the protocol object block 610 being ack'ed, which may range from 0-255. 612 (b) ACKIPADDR (32-bit unsigned integer): 613 IP interface address of the interface which originally sent 614 the protocol object block that is being acknowledged. 616 The Hello Block format is: 618 ::= 620 ::= | 621 623 NUM_HELLOS (8-bit unsigned integer): 624 This field indicates the length of the Hello List which may 625 range from 0-255. 627 HELLO (32-bit unsigned integer): 629 This field contains the IPv4 address of the interface being 630 "hello'ed". 632 The Object Block format consists of a set of fixed fields followed by 633 an Object List and an optional Response List: 635 ::= 636 637 [ ] 639 ::= | 640 642 ::= 644 ::= | 645 647 The fixed fields format is: 649 31 24 23 16 15 8 7 0 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 1 | (a) | (b) | (c) | (d) | Object List... 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 (a) SEQUENCE (8-bit unsigned integer): 655 A sequence counter uniquely indicating the Object Block ID 656 within a sender's transmission queue, ranging from 0-255. This 657 value may rollover, but for the envisioned applications, the 8- 658 bit value should be large enough so that no two Object Blocks in 659 the retransmission queue ever have the same SEQUENCE number. 661 (b) PROTOCOL_TYPE (4-bit unsigned integer): 662 This field indicates the protocol responsible for the opaque 663 objects in the object block--necessary for demultiplexing the 664 Object Block at a receiver. The field may range from 0-15. 666 value 0: reserved 668 value 1: NARP/RNARP 670 value 2: TORA 672 values 3-15: unassigned 674 (c) NUM_OBJECTS (7-bit unsigned integer): 675 This field indicates the length (i.e. number of objects) of the 676 Object List contained in the Object Block, which may range from 677 0-127. 679 (d) NUM_RESPONSES (5-bit unsigned integer): 680 This field indicates the length (i.e. number of responses) of 681 the Response List contained in the Object Block, which may range 682 from 0-31. The value 0 indicates unreliable delivery is desired, 683 and that no interfaces need respond. The value 31 indicates 684 BROADCAST, and that ALL receiving interfaces should respond. In 685 both cases, the Response List is omitted. 687 The OBJECT format is: 689 31 24 23 16 15 8 7 0 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 1 |0|OBJECT_LENGTH| OBJECT_DATA... 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 or 696 31 24 23 16 15 8 7 0 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 1 |1| OBJECT_LENGTH | OBJECT_DATA... 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 LENGTH_FLAG (1-bit field, bit 31 in format figures): 703 0: indicates 7-bit OBJECT_LENGTH 705 1: indicates 15-bit OBJECT_LENGTH 707 OBJECT_LENGTH (7 or 15-bit unsigned integer): 708 May range from 0-127 or 0-32767 as required indicating the 709 length of the OBJECT_DATA in bytes. 711 OBJECT_DATA: 712 Opaque bytestream of data of length OBJECT_LENGTH. 714 NARP/RNARP Packet Format (> 10 bytes): 716 31 24 23 16 15 8 7 0 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 1 ...self-formatting bytestream | (a) | (b) | (c) | (d) | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 2 | (e) Sender IP Interface Address | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 3 | (f) Target IP Interface Address | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | (g) Sender Router Identifier... 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 ...(h) Target Router Identifier... 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 Both NARP and RNARP packets share the same format which is similar 730 but not identical to traditional link-layer ARP/RARP packets: 732 (b) VERSION (4-bit unsigned integer): 733 This field specifies the version number of the NARP/RNARP 734 protocol. The current version maps 32-bit IPv4 addresses. A 735 future version would be required to map 128-bit IPv6 addresses. 737 0 (IPv4) 739 1 (IPv6) 741 2-15 (unused) 743 (b) PROTOCOL_TYPE (8-bit unsigned integer): 744 This field specifies the network-layer routing protocol type 745 being mapped. 747 (c) PROTOCOL_LENGTH (4-bit unsigned integer): 748 This field specifies length of the protocol Router IDentifier 749 (RID) in bytes. 751 (d) FRAME_TYPE (4-bit unsigned integer): 752 Indicates whether packet is a NARP or RNARP, and whether it is a 753 request or reply. 755 0x00 (NARP Request) 757 0x01 (NARP Reply) 759 0x02 (RNARP Request) 760 0x03 (RNARP Reply) 762 (e) SENDER_INTERFACE_ADDR (32-bit unsigned integer): 763 IP interface address of the sender of the NARP/RNARP message. 765 (f) TARGET_INTERFACE_ADDR (32-bit unsigned integer): 766 IP interface address of the target of the NARP/RNARP message. 768 (g) SENDER_ROUTER_ADDR (length specfied in (c): 769 Router identifier of the sender of the NARP/RNARP message. 771 (h) TARGET_ROUTER_ADDR (length specfied in (c): 772 Router identifier of the target of the NARP/RNARP message. 774 5. Summary 776 The preceding gives only a high-level protocol description, specify- 777 ing what is to be exchanged and, generally, why. Details on how the 778 protocol is to be implemented will be given in a subsequent version 779 of this draft. 781 6. References 783 [1] C. Perkins, "Mobile Ad Hoc Networking Terminology," draft-ietf- 784 manet-term-00.txt, October 1997. 786 Authors' Addresses: 788 M. Scott Corson 789 Institute for Systems Research 790 A.V. Williams Building (115) 791 University of Maryland 792 College Park, MD 20742 793 (301) 405-6630 794 corson@isr.umd.edu 796 Vincent Park 797 Information Technology Division 798 Code 5540 799 Naval Research Laboratory 800 Washington, DC 20375 801 (202) 767-5098 802 vpark@itd.nrl.navy.mil