idnits 2.17.1 draft-ietf-manet-packetbb-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1135. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1112. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1119. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1125. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 27, 2006) is 6634 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) ** Downref: Normative reference to an Experimental RFC: RFC 3626 (ref. '2') ** Obsolete normative reference: RFC 3513 (ref. '3') (Obsoleted by RFC 4291) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networking (MANET) T. Clausen 3 Internet-Draft LIX, Ecole Polytechnique, France 4 Expires: August 31, 2006 C. Dearlove 5 BAE Systems Advanced Technology 6 Centre 7 J. Dean 8 Naval Research Laboratory 9 February 27, 2006 11 Generalized MANET Packet/Message Format 12 draft-ietf-manet-packetbb-00 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 31, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This document describes a generalized multi-message packet format 46 which may be used by mobile ad hoc network routing and other 47 protocols. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 54 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 55 5. Signaling Framework . . . . . . . . . . . . . . . . . . . . . 7 56 5.1 Packet Format . . . . . . . . . . . . . . . . . . . . . . 7 57 5.1.1 Padding . . . . . . . . . . . . . . . . . . . . . . . 8 58 5.2 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 5.2.1 Address Blocks . . . . . . . . . . . . . . . . . . . . 11 60 5.2.2 TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 5.2.3 Constraints . . . . . . . . . . . . . . . . . . . . . 14 62 5.3 Message Content Fragmentation . . . . . . . . . . . . . . 14 63 6. TLV specification . . . . . . . . . . . . . . . . . . . . . . 16 64 6.1 Message TLV Specification . . . . . . . . . . . . . . . . 16 65 6.2 Address Block TLV Specification . . . . . . . . . . . . . 16 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 70 A. Packet and Message Layout . . . . . . . . . . . . . . . . . . 21 71 A.1 General Packet Format . . . . . . . . . . . . . . . . . . 21 72 B. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 73 C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 74 Intellectual Property and Copyright Statements . . . . . . . . 31 76 1. Introduction 78 Signaling in a mobile ad hoc network routing protocol consists, 79 mainly, of stating IP addresses and attributes associated to such IP 80 addresses. Since this is a task common to many such protocols, this 81 specification presents a generalized signaling framework, which may 82 be employed both by mobile ad hoc network routing protocols and other 83 protocols with similar signaling requirements. 85 The framework consists of a specification of: 87 o a mechanism whereby new message types can be specified and 88 (regardless of type, whether known or unknown) can still be 89 correctly parsed and forwarded; 91 o a generalized multi-message packet format, in which the header 92 information contains the necessary information to allow single and 93 multi-hop diffusion in MANETs, whilst also permitting unicast and 94 multicast use of the format; 96 o a mechanism whereby addresses can be represented in a compact way 97 (address compression); 99 o an extensibility mechanism whereby arbitrary attributes, through 100 TLVs (type-length-value triplets), can be included and associated 101 with a message, an address or a set of addresses, while being 102 correctly parseable by a generic message parser. 104 An important design criterion behind this specification is to allow 105 development of easy parsing logic, even in the face of a flexible 106 format. This implies that, given an incoming control message, a 107 single parser is able to process the message independent of type and 108 present, to a protocol using this specification, an abstraction of 109 addresses with associated attributes directly. The information 110 contained in the message header furthermore allows the recipient node 111 to recognize duplicates and make appropriate forwarding decisions. 112 Additionally, the signaling framework in this specification is 113 developed with the objective of minimizing the complexity of this 114 parser by providing a straight-forward message layout. 116 2. Terminology 118 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC2119 [1]. 122 Additionally, this document uses the following terminology: 124 Address - an address of the same type and length as the source IP 125 address in the IP datagram carrying the packet. 127 TLV - Type-Length-Value structure. This is a generic way in which an 128 attribute can be represented and correctly parsed, without knowing 129 the content, or understanding the type of the attribute by the 130 parser. This allows internal extensibility, i.e. for a protocol 131 extension to add arbitrary attributes within a control message. 133 ? - zero or one occurrences of the preceding element. 135 * - zero or more occurrences of the preceding element. 137 + - one or more occurrences of the preceding element. 139 3. Applicability Statement 141 This specification describes a generic multi-message packet format, 142 for carrying MANET routing protocol signals. The specification has 143 been developed from that used by OLSR [2]. 145 The specification is designed specifically with IP (IPv4/IPv6) in 146 mind. All addresses within a control message are assumed to be of 147 the same size, deduced from IP. In the case of mixed IPv6 and IPv4 148 addresses, IPv4 addresses are carried in IPv6 as specified in [3]. 150 The multi-message package format in this specification is 151 characterized by lending itself to low-complexity parsing logic, as 152 well as to an efficient parsing for low-capacity routers. The header 153 information in each message suffices to allow for each message to be 154 forwarded (if required) and delivered correctly with regards to the 155 message's delivery semantics, without parsing and inspecting the 156 message body. 158 The specification accommodates two types of extensibility: "external 159 extensibility", whereby new message types can be specified and 160 (regardless of type) still be correctly forwarded and parsed using 161 the simple parsing logic, and "internal extensibility", whereby new 162 attributes can be included in existing message types while these can 163 still be correctly forwarded and parsed using the simple parsing 164 logic. 166 4. Protocol Overview and Functioning 168 This specification does not describe a protocol. It describes a 169 packet format, which MAY be used by any mobile ad hoc network routing 170 or other protocol. 172 5. Signaling Framework 174 This section provides abstract descriptions of message and packet 175 formats. 177 5.1 Packet Format 179 Messages are carried in a general packet format, allowing 180 piggybacking of several independent messages in a single packet 181 transmission. 183 The packet format conforms to the following specification: 185 = ? 186 {*}+ 188 where is defined in Section 5.2, and with 189 conforming to the following specification: 191 is an 8 bit field with all bits cleared ('0'). The use 192 of is detailed in Section 5.1.1. 194 The is defined thus: 196 = 197 198 200 with the elements of conforming to the following 201 specification: 203 is an 8 bit field with all bits cleared ('0'). This field 204 serves to identify if the first 32 bits of a packet constitutes a 205 packet header or not. 207 is an 8 bit field with all bits cleared ('0'). This field 208 MAY be used for future extensions. 210 is a 16 bit field, which specifies a packet 211 sequence number. If used, a separate packet sequence number MUST 212 be maintained for each transmitting interface. Each packet 213 sequence number MUST be incremented by one each time a packet, as 214 defined in this document and which includes the packet sequence 215 number, is transmitted over this interface. 217 Note that since the message type zero is reserved (see Section 7), 218 the presence or absence of a packet header can be determined by 219 inspecting the first octet of the packet. 221 5.1.1 Padding 223 The message specification in Section 5.2 ensures that a message 224 consists of an integral number of octets, with all defined 225 syntactical entities (, , etc.) 226 being octet-aligned. Messages (and, hence, also the , if any), can be 32 bit aligned by adding the appropriate 228 number of s, as specified above. 230 The number of s required to achieve 32 bit alignment of a 231 message is calculated as the smallest number which when added to 232 produces a multiple of 4. 234 A recipient node needs not know if padding is included: the first 235 octet of a message (see Section 5.2) cannot be zero. Thus if after 236 processing a message a recipient reads an octet with all bits cleared 237 ('0'), this read octet is padding. 239 Thus, the does not include padding. The padding after a 240 message may be freely changed when a message is forwarded without 241 affecting the message. 243 5.2 Messages 245 Information is carried through "messages". Messages may contain: 247 o zero or more TLVs, associated with the whole message; 249 o a set of addresses about which the originating node wishes to 250 convey information. These addresses may be divided into one or 251 more address blocks. Each address SHALL appear only once in a 252 message with the same prefix length; 254 o each address block is followed by zero or more TLVs, explained 255 with more details in Section 5.2.2, which convey information about 256 the addresses in that address block. 258 A message also contains a message header, which can be parsed without 259 examining the remainder of the packet, and which contains information 260 sufficient to allow the recipient to: 262 o recognize duplicate messages; 264 o determine considerations for forwarding; 266 o manage controlled-scope diffusion of messages. 268 Message content MAY (e.g. due to size limitations) be fragmented. 270 Each fragment is transmitted such that it makes up a syntactically 271 correct message (i.e. all headers are set as if each fragment is a 272 message in its own right, and each message contains all necessary 273 message TLVs). Content fragmentation is detailed in Section 5.3. 275 A message has the following general layout: 277 = 278 279 {}* 281 = 282 283 284 286 = ? 287 ? 288 ? 289 ? 291 = 292 * 294 The elements of are included according to the flags 295 in as described below. 297 The elements used above conform to the following specification: 299 is a 16 bit field, which contains the total length (in 300 octets) of the immediately following TLV(s). If no TLV follows, 301 this field contains zero; 303 is a TLV, providing information regarding the entire message or 304 the address block which it follows. TLVs are specified in 305 Section 5.2.2; 307 is a block of addresses, with which the originator of 308 the message has a special relationship, specific to the protocol. 309 Address blocks are specified in Section 5.2.1; 311 is an 8 bit field, which specifies the type of message. A 312 type with all bits cleared ('0') MUST NOT be used. The most 313 significant bit is allocated with the following semantics: 315 bit 7 is the "user" bit. Types with this bit unset are defined in 316 this specification or can be allocated via standards action. 317 Types with this bit set are reserved for private/local use. 319 is an 8 bit field, which specifies the interpretation 320 of the remainder of the message header and the processing which 321 can be undertaken only parsing the message header: 323 bit 0 (LSB) indicates, if cleared ('0') that the elements 324 and in the be included, as specified in the above. If set ('1'), a 326 reduced header which does not include and 327 is used; this reduced header does not provide 328 provisions for duplicate suppression; 330 bit 1 indicates, if cleared ('0') that the elements and 331 in the be included, as specified 332 in the above. If set ('1'), a reduced header which does not 333 include the elements from the is used; this reduced header does not provide provisions 335 for scope-delimited forwarding; 337 bit 2 indicates, if cleared ('0'), that the message sequence 338 number in the message is type-independent. If set ('1'), the 339 message sequence number contained in the message is type 340 dependent, i.e. the source of the message maintains a sequence 341 number separately for the type indicated in the field; 342 this bit SHALL be cleared ('0') if there is no message sequence 343 number, i.e. if bit 0 is set; 345 bit 3 indicates, if cleared ('0') that the message, if of a 346 message type unknown to the recipient, SHOULD be considered for 347 forwarding. If set ('1'), the message, if of a message type 348 unknown to the recipient, MUST NOT be considered for 349 forwarding; 351 bits 4-7 (MSB) are RESERVED and SHALL each be cleared ('0') to be 352 in conformance with this version of the specification. 354 is a 16 bit field, which specifies the size of the and the following , counted in octets; 357 is the address of an interface of the node, 358 which originated the message. Each node SHOULD select one 359 interface address and MUST utilize this address consistently as 360 "originator address" for all messages it generates (note that this 361 is distinct from the IP source address); 363 is an 8 bit field, which contains the maximum number of hops a 364 message will be transmitted. Before a message is retransmitted, 365 the Time To Live MUST be decremented by 1. When a node receives a 366 message with a Time To Live equal to 0 or 1, the message MUST NOT 367 be retransmitted under any circumstances. Normally, a node will 368 not receive a message with a TTL of zero (note that this is 369 distinct from the IP TTL); 371 is an 8 bit field, which contains the number of hops a 372 message has traveled. Before a message is retransmitted, the hop 373 count MUST be incremented by 1. Initially, this is set to '0' by 374 the originator of the message; 376 is a 16 bit field, which contains a unique number, 377 generated by the originator node. The originator-address, msg- 378 seq-number and, if bit 4 in the field is set, the 379 of a message serves to uniquely identify the message in the 380 network (allowing, among other things, duplicate elimination). 382 5.2.1 Address Blocks 384 An address block represents a set of addresses in a compact and 385 simple form. Assuming that an address can be specified as a sequence 386 of bits of the form 'head:tail', then an address block is a set of 387 addresses sharing the same 'head' and having different 'tails'. 388 Specifically, an address block conforms to the following 389 specification: 391 = 392 393 394 + 396 with the elements defined thus: 398 is the number of "common leftmost octets" in a set of 399 addresses, where 0 <= head-length <= the length of the address in 400 octets; 402 is the longest sequence of leftmost octets which the addresses 403 in the address block have in common; 405 is the number of addresses represented in the address 406 block, which MUST NOT be zero. It is equal to the number of tails 407 following (except when equals the address length, 408 when no tails are required); 410 is the sequence of octets which, when concatenated to the 411 head, makes up a single, complete, unique address. The length of 412 is thus the length of an address, in octets, minus . This may be zero. 415 This representation aims at providing a flexible, yet compact, way of 416 representing sets of addresses. 418 5.2.2 TLVs 420 A TLV is a carrier of information, relative to a message or to 421 addresses in an address block. 423 A TLV associated with an address block specifies some attribute(s), 424 which associate with address(es) in the address-block. In order to 425 provide the largest amount of flexibility to benefit from address 426 aggregation as described in Section 5.2.1, a TLV associated to an 427 address block can apply to: 429 o a single address in the address block; 431 o all addresses in the address block; 433 o any continuous sequence of addresses in the address block. 435 All TLVs conforms to the following specification: 437 = 438 439 ? 440 ? 441 ? 442 ? 444 where the elements are defined thus: 446 is an 8 bit field, which specifies the type of the TLV. The 447 most significant bit is allocated with the following semantics: 449 bit 7 is the "user" bit. Types with this bit unset are defined in 450 this specification or can be allocated via standards action. 451 Types with this bit set are reserved for private/local use. 453 is an 8 bit field which specifies the semantics of 454 the TLV according to the following: 456 bit 0 (novalue): if cleared ('0') contains and 457 elements. TLVs with this bit set ('1') contains no or 458 elements - the TLV type carries all the information 459 needed. 461 bit 1 (extended): if cleared ('0'), the size of the length field 462 is 8 bits. If set ('1'), the size of the length field is 16 463 bits. This bit MUST be unset if the novalue bit is set. 465 bit 2 (noindex): if cleared ('0'), the and elements are included. If set ('1'), the 467 and elements are not included. This bit MUST be 468 set for message TLVs. If this bit is set for address block 469 TLVs, the TLV applies to all addresses in the address block. 471 bit 3 (multivalue): if cleared ('0'), the TLV includes a single 472 value which applies to all addresses described by 473 and . If set ('1'), the TLV includes separate 474 values for each of the addresses indicated by and 475 . This bit MUST be unset for message TLVs or if 476 the novalue bit is set. 478 bits 4-7 are RESERVED and SHALL each be cleared ('0'). 480 is omitted if the novalue bit is set, otherwise it is an 8 481 bit or 16 bit field, according to whether the extended bit is 482 unset or set, respectively. If present this field specifies the 483 length, counted in octets, of the data contained in . If 484 the multivalue bit is set, MUST be an integral multiple 485 of (-+1); 487 is omitted if the noindex bit is set. Otherwise it is 488 an 8 bit field. For a TLV associated with an address block, it 489 specifies the index of the first address in the address block 490 (starting at zero), for which this TLV applies, and is considered 491 to be zero if omitted; 493 is omitted if the noindex bit is set. Otherwise it is 494 an 8 bit field. For a TLV associated with an address block, it 495 specifies the index of the last address in the address block 496 (starting at zero) for which this TLV applies, and is considered 497 to be one less than the number of addresses in the address block 498 if omitted; 500 is omitted if the novalue bit is set. Otherwise it contains 501 a payload, of the length specified in , which is to be 502 processed according to the specification indexed by the 503 field. If this is a TLV for an address block and the multivalue 504 bit is set, this field is divided into (-+1) equal-sized fields which are applied, in order, to each 506 address described by and . 508 5.2.3 Constraints 510 o An address SHALL NOT appear more than once in the same message 511 with the same prefix length (an address without a PREFIX-LENGTH 512 TLV is considered to have a prefix length equal to the address 513 length); 515 o Two or more TLVs of the same type SHALL NOT apply to the same 516 address with the same prefix length; 518 o TLVs in the same SHALL be sorted in ascending TLV type 519 order; 521 o TLVs of the same type associated with the same SHALL 522 be sorted in ascending order; 524 5.3 Message Content Fragmentation 526 A message may be larger than is desirable to include, with the 527 packet, message and other headers (UDP, IP), in a MAC frame. In this 528 case the message SHOULD be fragmented. Only the originator of a 529 message may decide to fragment a message. When a message is 530 fragmented it MUST be assigned a content sequence number by the 531 originator. Two messages with the same originator and of the same 532 type with different message bodies SHALL NOT be assigned the same 533 content sequence number. Two messages with the same originator and 534 of the same type with the same message body MAY be assigned the same 535 content sequence number, in which case they MUST be fragmented 536 identically. 538 A fragment of a message may have one of two forms: 540 o the fragment is a "partially or wholly self-contained message" and 541 may, thus, be parsed and processed immediately by the recipient. 542 Additional processing MAY be necessary when all fragments are 543 received; 545 o the fragment is not a "partially or wholly self-contained message" 546 and may, thus, not be parsed and processed until all fragments of 547 the message have been received. 549 Regardless of type, each fragment MUST be a complete message, i.e. 551 MUST contain syntactically correct address blocks and TLVs. 552 Furthermore, all fragments of a given message MUST be of the same 553 type. 555 If a message is fragmented, each fragment MUST contain the following 556 TLVs: 558 o a message TLV with type FRAGMENTATION, specifying the number of 559 fragments, the fragment number (counting from zero) and if the 560 fragment is a partially or wholly self-contained message; 562 o a message TLV with type CONTENT-SEQ-NUMBER, specifying the content 563 sequence number associated with the information in the fragment 564 (note that the CONTENT-SEQ-NUMBER TLV may be useful also outside 565 of fragmentation). 567 Since fragmentation (see Section 6.1) is defined to be TLV type zero, 568 it can be determined if a message is fragmented by inspecting the 569 first octet of the message body (i.e. the first octet after the 570 message header). 572 A message SHOULD NOT be sent with a message TLV with type 573 FRAGMENTATION indicating "fragment zero of one". 575 6. TLV specification 577 This document specifies two message TLVs, which are required in the 578 case of message fragmentation, and two address block TLVs. The 579 address block TLVs are included to allow a standardized way of 580 representing network addresses in control messages. 582 6.1 Message TLV Specification 584 Message TLV specification overview 586 +----------------------+--------+--------+--------------------------+ 587 | Name | Type | Length | Value | 588 +----------------------+--------+--------+--------------------------+ 589 | FRAGMENTATION | 0 | 24 | See Table 2 below. | 590 | | | bits | | 591 | | | | | 592 | CONTENT-SEQ-NUMBER | 1 | 16 | A sequence number, | 593 | | | bits | associated with the | 594 | | | | content of the message | 595 +----------------------+--------+--------+--------------------------+ 597 Table 1 599 The fragmentation TLV contains the following fields in the following 600 order: 602 +--------------+----------------------------------------------------+ 603 | Field Width | Value | 604 +--------------+----------------------------------------------------+ 605 | 8 bits | Number of fragments | 606 | | | 607 | 8 bits | Fragment number | 608 | | | 609 | 8 bits | A bit vector, where: bit 0 indicates, if cleared | 610 | | ('0') that the message TLV is a partially or | 611 | | wholly self-contained message. If set ('1'), the | 612 | | message TLV is not a partially or wholly | 613 | | self-contained message. Bits 1-7 are RESERVED and | 614 | | SHALL each be cleared ('0'). | 615 +--------------+----------------------------------------------------+ 617 Table 2 619 6.2 Address Block TLV Specification 621 The following address block TLVs are provided for general use, and 622 are included in this specification since they complement the address 623 representation by providing a way of representing a network address 624 in a message. 626 Address block TLV specification overview 628 +----------------------+--------+--------+--------------------------+ 629 | Name | Type | Length | Value | 630 +----------------------+--------+--------+--------------------------+ 631 | PREFIX-LENGTH | 0 | 8 bits | Indicates that the | 632 | | | | address is a network | 633 | | | | address, rather than a | 634 | | | | host address. The value | 635 | | | | is the length of the | 636 | | | | netmask/prefix. | 637 +----------------------+--------+--------+--------------------------+ 639 Table 3 641 7. IANA Considerations 643 The message format in this specification defines a message "type" 644 field, as well as two TLV types for message TLVs and address block 645 TLVs respectively. 647 A new registry for message types must be created with initial 648 assignments as specified in Table 4. 650 A new registry for message TLV types must be created with initial 651 assignments as specified in Table 5. 653 A new registry for address block TLV types must be created with 654 initial assignments as specified in Table 6. 656 Assigned message Types 658 +--------------------+--------+-------------------------------------+ 659 | Mnemonic | Value | Description | 660 +--------------------+--------+-------------------------------------+ 661 | RESERVED | 0 | Signals that the following 24 bits | 662 | | | are a packet header, rather than a | 663 | | | message header | 664 | | | | 665 | OLSRv1-HELLO | 1 | Reserved for compatibility with | 666 | | | OLSRv1 [2] | 667 | | | | 668 | OLSRv1-TC | 2 | Reserved for compatibility with | 669 | | | OLSRv1 [2] | 670 | | | | 671 | OLSRv1-MID | 3 | Reserved for compatibility with | 672 | | | OLSRv1 [2] | 673 | | | | 674 | OLSRv1-HNA | 4 | Reserved for compatibility with | 675 | | | OLSRv1 [2] | 676 +--------------------+--------+-------------------------------------+ 678 Table 4 680 Assigned message TLV Types 682 +--------------------+--------+-------------------------------------+ 683 | Mnemonic | Value | Description | 684 +--------------------+--------+-------------------------------------+ 685 | Fragmentation | 0 | Specifies behavior in case of | 686 | | | content fragmentation | 687 | | | | 688 | Content Sequence | 1 | A sequence number, associated with | 689 | Number | | the content of the message | 690 +--------------------+--------+-------------------------------------+ 692 Table 5 694 Assigned address block TLV Types 696 +--------------------+--------+-------------------------------------+ 697 | Mnemonic | Value | Description | 698 +--------------------+--------+-------------------------------------+ 699 | PREFIX-LENGTH | 0 | Indicates that associated addresses | 700 | | | are network addresses, with given | 701 | | | prefix length | 702 +--------------------+--------+-------------------------------------+ 704 Table 6 706 8. Security Considerations 708 This document does currently not specify security considerations. 710 9. References 712 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 713 Levels", RFC 2119, BCP 14, March 1997. 715 [2] Clausen, T., "The Optimized Link State Routing Protocol", 716 RFC 3626, October 2003. 718 [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 719 Addressing Architecture", RFC 3513, April 2003. 721 Authors' Addresses 723 Thomas Heide Clausen 724 LIX, Ecole Polytechnique, France 726 Phone: +33 6 6058 9349 727 Email: T.Clausen@computer.org 728 URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ 730 Christopher M. Dearlove 731 BAE Systems Advanced Technology Centre 733 Phone: +44 1245 242194 734 Email: chris.dearlove@baesystems.com 736 Justin W. Dean 737 Naval Research Laboratory 739 Phone: +1 202 767 3397 740 Email: jdean@itd.nrl.navy.mil 741 URI: http://pf.itd.nrl.navy.mil/ 743 Appendix A. Packet and Message Layout 745 This section specifies the translation from the abstract descriptions 746 of packets employed in the protocol specification, and the bit-layout 747 packets actually exchanged between the nodes. 749 Appendix A.1 General Packet Format 751 The basic layout of a packet is as follows (omitting IP and UDP 752 headers), either 754 0 1 2 3 755 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 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 |0 0 0 0 0 0 0 0| Reserved | Packet Sequence Number | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | | 760 | Message | 761 | | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | | 764 : ... : 765 | | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | | 768 | Message | 769 | | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 or 773 0 1 2 3 774 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 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | | 777 | Message | 778 | | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | | 781 : ... : 782 | | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | | 785 | Message | 786 | | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 Note that in the former case the Reserved octet will be zero, whilst 790 in the latter case the first octet will not be zero. 792 The basic layout of a message may be one of the following four 793 options. The U bit is used to indicate whether if this message is of 794 unknown type whether it is forwarded (unset) or discarded (set). The 795 N bit is used to indicate whether the message sequence number is 796 type-dependent (set) or type-independent (unset). The reserved bits 797 marked Resv will also be zero. 799 0 1 2 3 800 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 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Message Type | Resv |U|N|0|0| Message Size | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Originator Address | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Time To Live | Hop Count | Message Sequence Number | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | | 809 | Message Body + Padding | 810 | | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 or 814 0 1 2 3 815 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 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Message Type | Resv |U|N|0|1| Message Size | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Time To Live | Hop Count | | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 821 | | 822 | Message Body + Padding | 823 | | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 or 828 0 1 2 3 829 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 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Message Type | Resv |U|N|1|0| Message Size | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Originator Address | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Message Sequence Number | | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 837 | | 838 | Message Body + Padding | 839 | | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 or 844 0 1 2 3 845 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 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Message Type | Resv |U|N|1|1| Message Size | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | | 850 | Message Body + Padding | 851 | | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 The basic layout of a message body, plus padding, is as follows 855 0 1 2 3 856 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 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | | 859 | Message TLV Block +-+-+-+-+-+-+-+-+ 860 | | | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 862 | | 863 | Address Block | 864 | | 865 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | | | 867 +-+-+-+-+-+-+-+-+ | 868 | | 869 | Address TLV Block | 870 | | 871 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | | | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 874 | | 875 : ... : 876 | | 877 | +-+-+-+-+-+-+-+-+ 878 | | | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 880 | | 881 | Address Block | 882 | | 883 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | | | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 886 | | 887 | Address TLV Block | 888 | | 889 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 The final padding to a 32 bit boundary is optional, and is not 894 included in the message length. 896 The basic layout of an address block is as follows. Note that the 897 length of each tail is equal to the address length minus the head 898 length. (Tail length may be zero if, and only if, the head length 899 equals the address length.) 900 0 1 2 3 901 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 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Head Length | Head | Number Tails | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Tail | | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 907 | | 908 : ... : 909 | | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Tail | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 The basic layout of a TLV block (message TLV block or address TLV 915 block) is as follows 917 0 1 2 3 918 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 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Length | | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 922 | | 923 | TLV +-+-+-+-+-+-+-+-+ 924 | | | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 926 | | 927 : ... : 928 | | 929 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | | | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV +-+-+-+-+-+-+-+-+ 932 | | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 The basic layout of a TLV may be one of the following six options. 936 Note that a message TLV may only be one of the last three options. M 937 denotes the multivalue bit when it may be cleared or set. The 938 reserved bits marked Resv will also be zero. 940 0 1 2 3 941 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 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | Type | Resv |M|0|0|0| Length | Index Start | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | Index Stop | | 946 +-+-+-+-+-+-+-+-+ | 947 | Value | 948 | | 949 | | 950 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | | 952 +-+-+-+-+-+-+-+-+ 954 or 956 0 1 2 3 957 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 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Type | Resv |0|0|0|1| Index Start | Index Stop | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 or 964 0 1 2 3 965 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 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Type | Resv |M|0|1|0| Length | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Index Start | Index Stop | | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 971 | | 972 | Value | 973 | | 974 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | | 976 +-+-+-+-+-+-+-+-+ 978 or 979 0 1 2 3 980 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 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Type | Resv |M|1|0|0| Length | | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 984 | | 985 | Value | 986 | | 987 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | | 989 +-+-+-+-+-+-+-+-+ 991 or 993 0 1 2 3 994 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 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | Type | Resv |0|1|0|1| 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 or 1001 0 1 2 3 1002 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 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | Type | Resv |M|1|1|0| Length | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | | 1007 | Value | 1008 | | 1009 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | | 1011 +-+-+-+-+-+-+-+-+ 1013 An example packet, with header and containing a single message, is as 1014 follows. The message has a message TLV block of length 7 octets 1015 (excluding the length iself) containing a single TLV (non-extended 1016 value length 4) and then two address blocks each with a following TLV 1017 block. The first address block contains 4 addresses (head length 3) 1018 and is followed by an empty TLV block (length 0, excluding the length 1019 itself). The second address block contains 3 addresses (head length 1020 2) and is followed by a TLV block of length 13 octets (excluding the 1021 length itself) containing two TLVs. The first of these TLVs has the 1022 noindex and multivalue bits of its semantics set and has three values 1023 (equal to the number of addresses) of two octets each, totalling to 1024 its (unextended) value length of 6 octets. The second of these TLVs 1025 has the novalue bit of its semantics set and hence has no length or 1026 value fields (it does have index fields). There are three final 1027 padding octets which are not included in the message length of 57 1028 octets. The addresses used in this example are IPv4 addresses 1029 (length four octets). 1031 0 1 2 3 1032 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 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 |0 0 0 0 0 0 0 0| Reserved | Packet Sequence Number | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Message Type | Resv |U|N|0|0|0 0 0 0 0 0 0 0 0 0 1 1 1 0 0 1| 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | Originator Address | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | Time to Live | Hop Count | Message Sequence Number | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| TLV Type | Resv |0|1|0|0| 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 |0 0 0 0 0 1 0 0| Value | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | Value (cont) |0 0 0 0 0 0 1 1| Head | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | Head (cont) |0 0 0 0 0 1 0 0| Tail | Tail | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | Tail | Tail |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 |0 0 0 0 0 0 1 0| Head |0 0 0 0 0 0 1 1| 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | Tail | Tail | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | Tail |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1| 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | TLV Type | Resv |1|1|0|0|0 0 0 0 0 1 1 0| Value0 | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | Value0 (cont) | Value1 | Value2 | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | Value2 (cont) | TLV Type | Resv |0|0|0|1| Index Start | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | Index Stop |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 Appendix B. Contributors 1069 This specification is the result of the joint efforts of the 1070 following contributers from the OLSRv2 Design Team -- listed 1071 alphabetically. 1073 o Cedric Adjih, INRIA, France, 1075 o Emmanuel Baccelli, INRIA, France, 1077 o Thomas Heide Clausen, PCRI, France, 1079 o Justin W. Dean, NRL, USA 1081 o Christopher Dearlove, BAE Systems, UK, 1082 1084 o Satoh Hiroki, Hitachi SDL, Japan, 1086 o Philippe Jacquet, INRIA, France, 1088 o Monden Kazuya, Hitachi SDL, Japan, 1090 Appendix C. Acknowledgements 1092 The authors would like to acknowledge the team behind OLSRv1, as 1093 specified in RFC3626, including Anis Laouiti, Pascale Minet, Laurent 1094 Viennot (all at INRIA, France), and Amir Qayuum (Center for Advanced 1095 Research in Engineering, Pakistan) for their contributions. 1097 The authors would like to gratefully acknowledge the following people 1098 for intense technical discussions, early reviews and comments on the 1099 specification and its components: Joe Macker (NRL), Alan Cullen 1100 (BAE Systems), Ian Chakeres (Boeing), Charlie E. Perkins (Nokia), 1101 Andreas Schjonhaug, and the entire IETF MANET working group. 1103 Intellectual Property Statement 1105 The IETF takes no position regarding the validity or scope of any 1106 Intellectual Property Rights or other rights that might be claimed to 1107 pertain to the implementation or use of the technology described in 1108 this document or the extent to which any license under such rights 1109 might or might not be available; nor does it represent that it has 1110 made any independent effort to identify any such rights. Information 1111 on the procedures with respect to rights in RFC documents can be 1112 found in BCP 78 and BCP 79. 1114 Copies of IPR disclosures made to the IETF Secretariat and any 1115 assurances of licenses to be made available, or the result of an 1116 attempt made to obtain a general license or permission for the use of 1117 such proprietary rights by implementers or users of this 1118 specification can be obtained from the IETF on-line IPR repository at 1119 http://www.ietf.org/ipr. 1121 The IETF invites any interested party to bring to its attention any 1122 copyrights, patents or patent applications, or other proprietary 1123 rights that may cover technology that may be required to implement 1124 this standard. Please address the information to the IETF at 1125 ietf-ipr@ietf.org. 1127 Disclaimer of Validity 1129 This document and the information contained herein are provided on an 1130 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1131 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1132 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1133 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1134 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1135 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1137 Copyright Statement 1139 Copyright (C) The Internet Society (2006). This document is subject 1140 to the rights, licenses and restrictions contained in BCP 78, and 1141 except as set forth therein, the authors retain all their rights. 1143 Acknowledgment 1145 Funding for the RFC Editor function is currently provided by the 1146 Internet Society.