idnits 2.17.1 draft-ietf-manet-packetbb-01.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1543. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1550. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1556. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 (June 19, 2006) is 6520 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) ** Obsolete normative reference: RFC 3513 (ref. '2') (Obsoleted by RFC 4291) Summary: 4 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: December 21, 2006 C. Dearlove 5 BAE Systems Advanced Technology 6 Centre 7 J. Dean 8 Naval Research Laboratory 9 C. Adjih 10 INRIA Rocquencourt 11 June 19, 2006 13 Generalized MANET Packet/Message Format 14 draft-ietf-manet-packetbb-01 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on December 21, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). 45 Abstract 47 This document describes a generalized multi-message packet format 48 which may be used by mobile ad hoc network routing and other 49 protocols. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 56 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 57 5. Signaling Framework . . . . . . . . . . . . . . . . . . . . . 7 58 5.1. Packet Format . . . . . . . . . . . . . . . . . . . . . . 7 59 5.1.1. Padding . . . . . . . . . . . . . . . . . . . . . . . 8 60 5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 5.2.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 12 62 5.3. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 14 63 5.3.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 5.3.2. Constraints . . . . . . . . . . . . . . . . . . . . . 17 65 5.4. Message Content Fragmentation . . . . . . . . . . . . . . 17 66 6. TLV specification . . . . . . . . . . . . . . . . . . . . . . 20 67 6.1. Message TLV Specification . . . . . . . . . . . . . . . . 20 68 6.2. Address Block TLV Specification . . . . . . . . . . . . . 21 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 74 Appendix A. Packet and Message Layout . . . . . . . . . . . . . 26 75 Appendix A.1. General Packet Format . . . . . . . . . . . . . . . 26 76 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 38 77 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 39 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 79 Intellectual Property and Copyright Statements . . . . . . . . . . 41 81 1. Introduction 83 Signaling in a mobile ad hoc network routing protocol consists, 84 mainly, of stating IP addresses and attributes associated to such IP 85 addresses. Since this is a task common to many such protocols, this 86 specification presents a generalized signaling framework, which may 87 be employed both by mobile ad hoc network routing protocols and other 88 protocols with similar signaling requirements. 90 The framework consists of a specification of: 92 o a mechanism whereby message types can be specified and (regardless 93 of type, whether known or unknown) can be correctly parsed and 94 forwarded; 96 o a generalized multi-message packet format, allowing multiple 97 messages to be contained within a single transmission; 99 o a message format, composed of a message header and a message body, 100 with the message header containing *all* necessary information to 101 allow a node to make forwarding and processing decisions without 102 resorting to inspecting the message body. The message header 103 information permits single- and multi-hop diffusion whilst 104 supporting scope controlled multicast and unicast use of the 105 format; 107 o a message body structure, encouraging uniform message parsing, 108 regardless of message body content; 110 o a mechanism whereby addresses can be represented in a compact way 111 (address compression); 113 o an extensibility mechanism whereby arbitrary attributes, through 114 TLVs (type-length-value triplets), can be included and associated 115 with a message, an address or a set of addresses, while being 116 correctly parseable by a generic message parser. 118 An important design criterion behind this specification is to allow 119 development of easy parsing logic, even in the face of a flexible 120 format. This implies that, given an incoming control message, a 121 single parser is able to process the message independent of type and 122 present, to a protocol using this specification, an abstraction of 123 addresses with associated attributes directly. The information 124 contained in the message header furthermore allows the recipient node 125 to recognize duplicates and make appropriate forwarding decisions. 126 Additionally, the signaling framework in this specification is 127 developed with the objective of minimizing the complexity of this 128 parser by providing a straightforward message layout. 130 2. Terminology 132 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC2119 [1]. 136 Additionally, this document uses the following terminology: 138 Address - an address of the same type and length as the source IP 139 address in the IP datagram carrying the packet. 141 TLV - Type-Length-Value structure. This is a generic way in which an 142 attribute can be represented and correctly parsed, without knowing 143 the content, or understanding the type of the attribute by the 144 parser. This allows internal extensibility, i.e. for a protocol 145 extension to add arbitrary attributes within a control message. 147 ? - zero or one occurrences of the preceding element. 149 * - zero or more occurrences of the preceding element. 151 + - one or more occurrences of the preceding element. 153 - An element specified in the parsing of a packet, message or 154 other entity. If is an 8 or 16 bit field then is also 155 used to represent the value of that field. 157 bar - A variable, usually obtained through calculations based on the 158 value(s) of field(s). Variables are introduced in the 159 specification solely as a means to clarify the description. 161 address-length - A variable whose value is the length of an address 162 in octets, i.e. it is 4 if using IPv4, or 16 if using IPv6. 164 3. Applicability Statement 166 This specification describes a generic multi-message packet format, 167 for carrying MANET routing protocol signals. The specification has 168 been developed from that used by OLSR [3]. 170 The specification is designed specifically with IP (IPv4/IPv6) in 171 mind. All addresses within a control message are assumed to be of 172 the same size, deduced from IP. In the case of mixed IPv6 and IPv4 173 addresses, IPv4 addresses are carried in IPv6 as specified in [2]. 175 The packets defined by this specification may use any transport 176 protocol appropriate to the protocol using this specification. When 177 the diffusion mechanism enabled by this specification is employed, 178 UDP may be most appropriate. 180 The multi-message package format in this specification is 181 characterized by lending itself to low-complexity parsing logic, as 182 well as to an efficient parsing for low-capacity routers. The header 183 information in each message suffices to allow for each message to be 184 forwarded (if required) and delivered correctly with regards to the 185 message's delivery semantics, without parsing and inspecting the 186 message body. 188 The specification accommodates two types of extensibility: "external 189 extensibility", whereby new message types can be specified and 190 (regardless of type) still be correctly forwarded and parsed using 191 the simple parsing logic, and "internal extensibility", whereby new 192 attributes can be included in existing message types while these can 193 still be correctly forwarded and parsed using the simple parsing 194 logic. 196 4. Protocol Overview and Functioning 198 This specification does not describe a protocol. It describes a 199 packet format, which MAY be used by any mobile ad hoc network routing 200 or other protocol. 202 5. Signaling Framework 204 This section provides abstract descriptions of message and packet 205 formats. 207 5.1. Packet Format 209 Messages are carried in a general packet format, allowing 210 piggybacking of several independent messages in a single packet 211 transmission. 213 The packet format conforms to the following specification: 215 = {*}? 216 {*}* 218 where is defined in Section 5.2, and with 219 conforming to the following specification: 221 is an 8 bit field with all bits cleared ('0'). The use 222 of is detailed in Section 5.1.1. 224 is defined by: 226 = 227 228 ? 229 ? 231 with the elements of conforming to the following 232 specification: 234 is an 8 bit field with all bits cleared ('0'). This field 235 serves to identify if the packet starts with a packet header. 237 is an 8 bit field, which specifies the composition 238 of the packet header: 240 bit 0 (pseqnum) indicates, if cleared ('0'), that the packet 241 header contains a . If set ('1'), the 242 packet header does not include a . 244 bit 1 (ptlv) indicates, if cleared ('0'), that the packet header 245 does not include a TLV block. If set ('1'), the packet header 246 includes a TLV block. 248 bits 2-7 are reserved, and SHOULD each be cleared ('0'). 250 is omitted if the pseqnum bit is set ('1'), 251 otherwise it is a 16 bit field, which specifies a packet sequence 252 number. If used, a separate packet sequence number MUST be 253 maintained for each transmitting interface. Each packet sequence 254 number MUST be incremented by one each time a packet, as defined 255 in this document and which includes the packet sequence number, is 256 transmitted over this interface. 258 is omitted if the ptlv bit is cleared ('0'), otherwise it 259 is a TLV block as specified in Section 5.3. 261 Note that since the message type zero is reserved (see Section 7), 262 the presence or absence of a packet header can be determined by 263 inspecting the first octet of the packet. 265 5.1.1. Padding 267 Packet headers and messages can be padded to ensure 32 bit alignment 268 of each message contained within the packet. 270 5.1.1.1. Packet Header Padding 272 The packet header specification in Section 5.1 ensures that a packet 273 header consists of an integral number of octets, with all defined 274 syntactical entities (, , , ) being octet-aligned. 277 The first in a packet can be 32 bit aligned by adding the 278 appropriate number of s subsequent to the . 280 The number of s required to achieve this 32 bit alignment 281 is calculated as the smallest number which, when added to the size of 282 the packet header (if any) and the size of the (if any) and the size of the fixed part of the header 284 (the and fields, which are each one octet 285 long) produces an integer multiple of 4. 287 If the contains a and no , (i.e. if both the pseqnum and ptlv bits are cleared) then 289 there SHOULD NOT be any subsequent to the , since then the has length exactly 4 octets 291 and the first is then already 32 bit aligned. 293 There is no need to indicate if padding is included subsequent to the 294 packet header: the first octet of a message (see Section 5.2 cannot 295 be zero. Thus, if after processing the packet header a recipient 296 reads an octet with all bits cleared ('0'), this read octet is 297 padding. 299 5.1.1.2. Message Padding 301 The message specification in Section 5.2 ensures that a message 302 consists of an integral number of octets, with all defined 303 syntactical entities (, , etc.) 304 being octet-aligned. 306 The first message can be 32 bit aligned by using packet header 307 padding, as described in Section 5.1.1.1. Subsequent messages (and, 308 hence, also the , if any), can be 32 bit aligned 309 by adding the appropriate number of s subsequent to each 310 message. (When added to the last message this instead ensures that 311 the overall packet is a multiple of 32 bits in length.) 313 The number of s required to achieve 32 bit alignment of 314 the end of message (and hence the start of the next, if any), 315 assuming that the start of the message is 32 bit aligned, is 316 calculated as the smallest number which when added to 317 produces a multiple of 4. 319 There is no need to indicate if padding is included subsequent to a 320 message: the first octet of a message (see Section 5.2) cannot be 321 zero. Thus if after processing a message a recipient reads any 322 octets with all bits cleared ('0'), these read octets are padding. 323 The does not include padding. 325 The padding after a message may be freely changed when a message is 326 forwarded without affecting the message. 328 5.2. Messages 330 Information is carried through "messages". Messages may contain: 332 o zero or more TLVs, associated with the whole message; 334 o a set of addresses about which the originating node wishes to 335 convey information. These addresses MAY be divided into one or 336 more address blocks; 338 o zero or more TLVs following each address block. These are 339 explained in more detail in Section 5.3.1 and convey information 340 about the addresses in that address block. 342 A message also contains a message header, which can be parsed without 343 examining the remainder of the packet, and which contains information 344 sufficient to allow the recipient to: 346 o recognize duplicate messages; 348 o determine considerations for forwarding; 350 o manage controlled-scope diffusion of messages. 352 Message content MAY (e.g. due to size limitations) be fragmented. 353 Each fragment is transmitted such that it makes up a syntactically 354 correct message (i.e. all headers are set as if each fragment is a 355 message in its own right, and each message contains all necessary 356 message TLVs). Content fragmentation is detailed in Section 5.4. 358 A message has the following general layout: 360 = 361 362 {}* 364 = 365 366 367 369 = ? 370 ? 371 ? 372 ? 374 The elements of are included according to the flags 375 in as described below. 377 The elements used above conform to the following specification: 379 is as specified in Section 5.3 381 is a block of addresses, with which the originator of 382 the message has a special relationship, specific to the protocol 383 using this specification. Address blocks are specified in 384 Section 5.2.1; 386 is an 8 bit field, which specifies the type of message. A 387 type with all bits cleared ('0') MUST NOT be used. The two most 388 significant bits are allocated with the following semantics: 390 bit 7 (msg-user): message types with this bit cleared ('0') are 391 defined in this specification or can be allocated via standards 392 action. Message types with this bit set ('1') are reserved for 393 private/local use. 395 bit 6 (msg-protocol): for message types with the msg-user bit 396 cleared ('0'), this bit specifies, if cleared ('0'), that the 397 message type is protocol independent, i.e. is not specific to 398 any one protocol, or, if set ('1'), that the message type is 399 specific to the protocol for which it is defined. 401 is an 8 bit field, which specifies the interpretation 402 of the remainder of the message header and the processing which 403 can be undertaken only parsing the message header: 405 bit 0 (noorig): indicates, if cleared ('0') that the elements 406 and in the be included, as specified in the above. If set ('1'), a 408 reduced header which does not include and 409 is used; this reduced header does not provide 410 provisions for duplicate suppression; 412 bit 1 (nohops): indicates, if cleared ('0') that the elements 413 and in the be 414 included, as specified in the above. If set ('1'), a reduced 415 header which does not include the elements from the is used; this reduced header 417 does not provide provisions for scope-delimited forwarding; 419 bit 2 (typedep): indicates, if cleared ('0'), that the message 420 sequence number in the message is type-independent. If set 421 ('1'), the message sequence number contained in the message is 422 type dependent, i.e. the source of the message maintains a 423 sequence number separately for the type indicated in the field; this bit SHALL be cleared ('0') if there is no 425 message sequence number, i.e. if the noorig bit is set; 427 bits 3-7: are RESERVED and SHALL each be cleared ('0') to be in 428 conformance with this version of the specification. 430 is a 16 bit field, which specifies the size of the and the following , counted in octets; 433 is the address of an interface of the node, 434 which originated the message. Its length is equal to address- 435 length octets. Each node SHOULD select one of its interface 436 addresses as its "originator address" and MUST utilize this 437 address consistently as the in all messages 438 it generates which include this field. Note that the originator 439 address is distinct from the IP source address, and that the same 440 originator address MUST be used regardless of which interface a 441 message is transmitted on. Also note that if a message is 442 retransmitted the originator address MUST NOT be changed; 444 is an 8 bit field, which contains the maximum number of 445 hops a message will be transmitted. Before a message is 446 retransmitted, the hop-limit MUST be decremented by 1. When a 447 node receives a message with a hop-limit equal to 0 or 1, the 448 message MUST NOT be retransmitted under any circumstances. 449 Normally, a node will not receive a message with a hop-limit of 0 450 (note that this hop-limit is distinct from the IPv6 hop-limit); 452 is an 8 bit field, which contains the number of hops a 453 message has traveled. Before a message is retransmitted, the hop- 454 count MUST be incremented by 1. Initially, this hop-count SHOULD 455 be set to 0 by the originator of the message; 457 is a 16 bit field, which contains a unique number, 458 generated by the originator node. The originator-address, msg- 459 seq-number and, if the typedep bit in the field is 460 set, the of a message serves to uniquely identify the 461 message in the network (allowing, among other things, duplicate 462 elimination). 464 5.2.1. Address Blocks 466 An address block represents a set of addresses in a compact and 467 simple form. Assuming that an address can be specified as a sequence 468 of bits of the form 'head:mid:tail', then an address block is a set 469 of addresses sharing the same 'head' and 'tail' and having different 470 'mids'. (The case where the 'tail' is empty is treated specially, as 471 is the case where the 'tail' consists of zero-valued octets, the 472 latter is particularly appropriate when used with a TLV indicating a 473 prefix length, see Section 6.2.) 475 Specifically, an address block conforms to the following 476 specification: 478 = 479 480 ? 481 ? 482 ? 483 * 485 with the elements defined thus: 487 is an 8 bit field containing the number of addresses 488 represented in the address block, which MUST NOT be zero. It is 489 equal to the number of s following (except when, as defined 490 below, mid-length == 0 and no s are required); 492 is an 8 bit field, where: 494 bits 0-6: contain the length of the , if any. The 495 corresponding variable head-length is calculated by: 497 head-length = & 127 499 bit 7 (notail): indicates, if cleared ('0'), that the address 500 block contains a (see below), if set ('1') that no 501 is included; 503 is omitted if head-length == 0, otherwise it is a field of 504 head-length octets which contains the leftmost octets which the 505 addresses in the block have in common (it SHOULD contain the 506 longest such sequence); 508 is omitted if the notail bit is set ('1'), otherwise it 509 is an 8 bit field, where: 511 bits 0-6: contain the length of the , if any, or the 512 equivalent number of zero-valued tail octets. The 513 corresponding variable tail-length is calculated by: 515 tail-length = & 127 517 bit 7 (zerotail): indicates, if cleared ('0'), that a (see 518 below) is included, if set ('1') that no is included, 519 and that the tail-length rightmost octets of each address in 520 the block are zero-valued; 522 If the is omitted then tail-length = 0. 524 is omitted if tail-length == 0 or the zerotail bit is set 525 ('1'), otherwise it is a field of length tail-length octets which 526 contains the rightmost octets which the addresses in the block 527 have in common (it SHOULD contain the longest such sequence in 528 this case); 530 If tail-length != 0 and the zerotail bit is set ('1') then all the 531 addresses in the block have tail-length zero-valued rightmost 532 octets (tail-length SHOULD be the largest such number in this 533 case); 535 mid-length is a variable, calculated by: 537 mid-length = address-length - head-length - tail-length 539 mid-length MUST be non-negative. 541 is omitted if mid-length == 0 (in which case all addresses in 542 the block are the same), otherwise each is a field of length 543 mid-length octets, representing the 'mid' of the corresponding 544 address in the address block. 546 This representation aims at providing a flexible, yet compact, way of 547 representing sets of addresses. 549 5.3. TLVs and TLV Blocks 551 A TLV block has the following general layout: 553 = 554 * 556 with the elements defined thus: 558 is a 16 bit field, which contains the total length (in 559 octets) of the immediately following TLV(s). It does not include 560 its own length, thus if no TLVs follow, this field contains zero; 562 is a TLV, providing information regarding the entire packet or 563 message or the address block which it follows. TLVs are specified 564 in Section 5.3.1; 566 5.3.1. TLVs 568 A TLV is a carrier of information, relative to a packet, to a message 569 or to addresses in an address block. 571 A TLV associated with an address block specifies some attribute(s), 572 which are associated with address(es) in the address-block. In order 573 to provide the largest amount of flexibility to benefit from address 574 aggregation as described in Section 5.2.1, a TLV associated to an 575 address block can apply to: 577 o all addresses in the address block; 579 o any continuous sequence of addresses in the address block; 581 o a single address in the address block. 583 All TLVs conform to the following specification: 585 = 586 587 ? 588 ? 589 ? 590 ? 592 where the elements are defined thus: 594 is an 8 bit field, which specifies the type of the TLV. 595 The two most significant bits are allocated with the following 596 semantics: 598 bit 7 (tlv-user): TLV types with this bit cleared ('0') are 599 defined in this specification or can be allocated via standards 600 action. TLV types with this bit set ('1') are reserved for 601 private/local use. 603 bit 6 (msg-protocol): for TLV types with the tlv-user bit cleared 604 ('0'), this bit specifies, if cleared ('0'), that the TLV type 605 is protocol independent, i.e. is not specific to any one 606 protocol, or, if set ('1'), that the TLV type is specific to 607 the protocol for which it is defined. 609 is an 8 bit field which specifies the semantics of 610 the TLV according to the following: 612 bit 0 (novalue): if cleared ('0') contains and 613 elements. TLVs with this bit set ('1') contains no or 614 elements - the TLV type carries all the information 615 needed. 617 bit 1 (extended): if cleared ('0'), the size of the length field 618 is 8 bits. If set ('1'), the size of the length field is 16 619 bits. This bit MUST be cleared ('0') if the novalue bit is set 620 ('1'). 622 bit 2 (noindex): if cleared ('0'), the and elements are included. If set ('1'), the 624 and elements are not included. This bit MUST be 625 set for packet or message TLVs. If this bit is set ('1') for 626 address block TLVs, the TLV applies to all addresses in the 627 address block. 629 bit 3 (multivalue): if cleared ('0'), the TLV includes a single 630 value which applies to all addresses described by 631 and . If set ('1'), the TLV includes separate 632 values for each of the addresses indicated by and 633 . This bit MUST be cleared ('0') for packet or 634 message TLVs or if the novalue bit is set ('1'). 636 bits 4-7: are RESERVED and SHALL each be cleared ('0'). 638 is omitted if the noindex bit is set ('1'), otherwise 639 it is an 8 bit field. In the former case, the variable index- 640 start is defined by: 642 index-start = 644 in the latter case, the variable index-start is defined by: 646 index-start = 0 648 If this TLV is associated with an address block then index-start 649 specifies the index of the first address in the address block 650 (starting at zero) for which this TLV applies; 652 is omitted if the noindex bit is set ('1'), otherwise it 653 is an 8 bit field. In the former case, the variable index-stop is 654 defined by: 656 index-stop = 658 in the latter case, for a TLV associated with an address block 659 with addresses the variable index-stop is defined by: 661 index-stop = - 1 663 otherwise (a TLV associated with a packet or a message) the 664 variable index-stop is defined by: 666 index-stop = 0 668 If this TLV is associated with an address block then index-stop 669 specifies the index of the last address in the address block 670 (starting at zero) for which this TLV applies. 672 number-values is a variable, defined by 673 number-values = - + 1 675 If this TLV is associated with an address block then number-values 676 is the number of addresses in that block to which this TLV 677 applies, otherwise it is 1. 679 is omitted if the novalue bit is set ('1'), otherwise it is 680 an 8 bit or 16 bit field, according to whether the extended bit is 681 cleared ('0') or set ('1'), respectively. If present this field 682 specifies the length, counted in octets, of the data contained in 683 . If the multivalue bit is set ('1') then MUST be 684 an integral multiple of number-values and the variable single- 685 length is defined by 687 single-length = / number-values 689 otherwise, if the multivalue bit is cleared ('0'), the variable 690 single-length is defined by 692 single-length = 694 is omitted if the novalue bit is set ('1'), Otherwise it is a 695 field of length octets. If the multivalue bit is cleared 696 ('0') then this field is associated with the packet, message or 697 the relevant addresses (from index-start to index-stop) in the 698 address block with which this TLV is associated, as appropriate. 699 If the multivalue bit is set ('1') then this field is divided 700 equally into number-values fields, each of length single-length 701 octets and these are associated, in order, to the relevant 702 addresses (from index-start to index-stop) in the address block 703 with which this TLV is associated. The association is interpreted 704 according to the field. 706 5.3.2. Constraints 708 TLVs in the same SHALL be sorted in ascending TLV type 709 order. 711 Two or more TLVs of the same type associated with the same SHALL NOT both cover any index (address). 714 TLVs of the same type associated with the same SHALL be 715 sorted in ascending order. 717 5.4. Message Content Fragmentation 719 A message may be larger than is desirable to include, with the 720 packet, message and other headers (transport, IP), in a MAC frame. 722 In this case the message SHOULD be fragmented. Only the originator 723 of a message may decide to fragment a message. When a message is 724 fragmented it MUST be assigned a content sequence number by the 725 originator. A content sequence number may also be assigned for 726 reasons other than fragmentation. 728 A content sequence number may be specific to the type of the message 729 or not. If the content sequence number is to be used for 730 fragmentation then this is indicated as specified in Section 6.1. 732 Two messages with the same originator and, when the content sequence 733 number is type-specific, with the same type, with different message 734 bodies SHALL NOT be assigned the same content sequence number. Two 735 messages with the same originator and the same message body MAY be 736 assigned the same content sequence number, with the same type- 737 dependence, in which case they MUST be fragmented identically. 739 A fragment of a message may have one of two forms: 741 o the fragment is a "partially or wholly self-contained message" and 742 may, thus, be parsed and processed immediately by the recipient. 743 Additional processing MAY be necessary when all fragments are 744 received; 746 o the fragment is not a "partially or wholly self-contained message" 747 and may, thus, not be processed until all fragments of the message 748 have been received. 750 Regardless of under which of the above forms a message is fragmented, 751 each fragment MUST be a complete message as defined in this 752 specification, i.e. MUST contain syntactically correct address 753 blocks and TLVs. Furthermore, all fragments of a given message MUST 754 be of the same type, and have the same fragmentation semantics, see 755 Section 6.1. 757 If a message is fragmented, each fragment MUST contain the following 758 TLVs, defined in Section 6.1: 760 o a message TLV with type FRAGMENTATION, specifying the number of 761 fragments, the fragment number (counting from zero), if the 762 fragment is a partially or wholly self-contained message, and if 763 the CONTENT-SEQ-NUMBER generated by the originator of the 764 fragmented message is specific to the type of the fragmented 765 message or not; 767 o a message TLV with type CONTENT-SEQ-NUMBER, specifying the content 768 sequence number associated with the information in the fragment. 770 If the content sequence number included in the CONTENT-SEQ-NUMBER TLV 771 of a message is specific to the type of the message then the 772 originating node MUST maintain a content sequence number for that 773 message type and MUST increment it when it originates a new message 774 of that type, but not of any other type. A node MAY maintain such 775 type-specific content sequence numbers for any number of types. 777 If the content sequence number included in the CONTENT-SEQ-NUMBER TLV 778 of a message is not specific to the type of the message then the 779 originating node MUST maintain a single content sequence number for 780 those message type for which a content sequence number is required, 781 but for which the node does not maintain a type-specific content 782 sequence number. The node MUST increment this single content 783 sequence number when it originates a new message of any relevant 784 type, but not of any other types (either those for which a content 785 sequence number is not appropriate, or for which a type-specific 786 content sequence number is maintained.) 788 Since FRAGMENTATION is defined to be TLV type zero (see Section 6.1), 789 it can be determined if a message is fragmented by inspecting the 790 first three octets of the message body (the first three octets after 791 the message header): 793 o if the first two octets (the message TLV block length) are both 794 zero then the message is not a fragment; 796 o otherwise if the third octet (the first message TLV type) is zero 797 then the message is a fragment; 799 o otherwise the message is not a fragment. 801 A message SHOULD NOT be sent with a message TLV with type 802 FRAGMENTATION indicating "fragment zero of one". 804 6. TLV specification 806 This document specifies two message TLVs, which are required in the 807 case of message fragmentation, and one address block TLV. The 808 address block TLV is included to allow a standardized way of 809 representing network addresses, with a prefix length, in control 810 messages. 812 6.1. Message TLV Specification 814 Message TLV Specification Overview 816 +----------------------+------+--------+----------------------------+ 817 | Name | Type | Length | Value | 818 +----------------------+------+--------+----------------------------+ 819 | FRAGMENTATION | 0 | 24 | See Table 2 below. | 820 | | | bits | | 821 | | | | | 822 | CONT_SEQ_NUM | 1 | 16 | A sequence number, | 823 | | | bits | associated with the | 824 | | | | content of the message | 825 +----------------------+------+--------+----------------------------+ 827 Table 1 829 The fragmentation TLV contains the following fields in the following 830 order: 832 FRAGMENTATION TLV Value Specification Overview 834 +-------------+----------------------------------------------------+ 835 | Field Width | Value | 836 +-------------+----------------------------------------------------+ 837 | 8 bits | Number of fragments | 838 | | | 839 | 8 bits | Fragment number | 840 | | | 841 | 8 bits | Fragmentation semantics bit vector. | 842 +-------------+----------------------------------------------------+ 844 Table 2 846 The bits in the fragmentation semantics bit vector are defined as 847 follows: 849 bit 0 (notselfcont): indicates, if cleared ('0') that the message TLV 850 is a partially or wholly self-contained message, or if set ('1') 851 that the message TLV is not a partially or wholly self-contained 852 message. 854 bit 1 (typedepseq): indicates, if cleared ('0') that the originator 855 maintains a single sequence number for fragmented messages of 856 types including the type of this message, and that this is 857 included in the CONTENT-SEQ-NUMBER TLV. If set ('1'), the 858 originator node maintains a separate sequence number for the type 859 of this message, and that the sequence number in the CONTENT-SEQ- 860 NUMBER TLV is the sequence number corresponding to the type of 861 this message. 863 bits 2-7: are RESERVED and SHALL each be cleared ('0'). 865 6.2. Address Block TLV Specification 867 The following address block TLV is provided for general use, and is 868 included in this specification since it complements the address 869 representation by providing a way of representing a network address 870 in a message. 872 Address Block TLV Specification Overview 874 +----------------------+------+--------+----------------------------+ 875 | Name | Type | Length | Value | 876 +----------------------+------+--------+----------------------------+ 877 | PREFIX_LENGTH | 0 | 8 bits | Indicates that the address | 878 | | | | is a network address, | 879 | | | | rather than a host | 880 | | | | address. The value is the | 881 | | | | length of the | 882 | | | | netmask/prefix. | 883 +----------------------+------+--------+----------------------------+ 885 Table 3 887 An address in an address block without an associated PREFIX_LENGTH 888 TLV may be considered to have a prefix length equal to the address 889 length (in bits). 891 7. IANA Considerations 893 The message format in this specification defines a message "type" 894 field, as well as two TLV types for message TLVs and address block 895 TLVs respectively. 897 A new registry for message types must be created with initial 898 assignments as specified in Table 4. 900 A new registry for packet TLV types must be created, with no initial 901 assignments. 903 A new registry for message TLV types must be created with initial 904 assignments as specified in Table 5. 906 A new registry for address block TLV types must be created with 907 initial assignments as specified in Table 6. 909 Assigned Message Types 911 +--------------------+-------+--------------------------------------+ 912 | Mnemonic | Value | Description | 913 +--------------------+-------+--------------------------------------+ 914 | RESERVED | 0 | At start of packet signals that what | 915 | | | follows is a packet header, rather | 916 | | | than a message header, and to allow | 917 | | | packet header and message padding | 918 | | | with zero octets | 919 | | | | 920 | RESERVED | 1 | | 921 | | | | 922 | RESERVED | 2 | | 923 | | | | 924 | RESERVED | 3 | | 925 | | | | 926 | RESERVED | 4 | | 927 +--------------------+-------+--------------------------------------+ 929 Table 4 931 Message types 1 to 4 are reserved because they are used by OLSRv1 [3] 932 which uses a compatible packet/message header format. 934 Assigned Message TLV Types 936 +--------------------+-------+--------------------------------------+ 937 | Mnemonic | Value | Description | 938 +--------------------+-------+--------------------------------------+ 939 | FRAGMENTATION | 0 | Specifies behavior in case of | 940 | | | content fragmentation | 941 | | | | 942 | CONT_SEQ_NUM | 1 | A sequence number, associated with | 943 | | | the content of the message | 944 +--------------------+-------+--------------------------------------+ 946 Table 5 948 Assigned Address Block TLV Types 950 +--------------------+-------+--------------------------------------+ 951 | Mnemonic | Value | Description | 952 +--------------------+-------+--------------------------------------+ 953 | PREFIX_LENGTH | 0 | Indicates that associated addresses | 954 | | | are network addresses, with given | 955 | | | prefix length | 956 +--------------------+-------+--------------------------------------+ 958 Table 6 960 8. Security Considerations 962 Packets are designed to be transmitted only one hop, and not 963 forwarded. Thus, hop-by-hop packet level security MAY be 964 implemented, between nodes with an existing security association, 965 through including suitable packet TLV(s) containing a cryptographic 966 signature to the packet. Since packets are received as transmitted, 967 signatures can be calculated based on the entire packet content 968 (including message and packet headers), or on parts thereof as 969 appropriate. 971 The messages contained in a packet are available at each hop, and 972 MAY, according to the information in the message header, and the 973 protocol employing this specification, be forwarded and/or processed. 974 If a message is to be forwarded, the and 975 fields in the message header, if present, SHOULD be modified. All 976 other message header fields, and the message body, MAY, depending on 977 the protocol employing this specification, be left intact. 979 Such a protocol (using immutable messages, other than the indicated 980 fields) using this message format MAY, between nodes with an existing 981 security association, implement end-to-end message security by 982 including suitable message TLV(s) containing a cryptographic 983 signature to the message. This signature can be calculated based on 984 the entire message, including the message header, with the provision 985 that the and fields MUST, if present, both be 986 set to zero ('0') for both calculation and verification of the 987 signature. 989 9. References 991 9.1. Normative References 993 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 994 Levels", RFC 2119, BCP 14, March 1997. 996 [2] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 997 Addressing Architecture", RFC 3513, April 2003. 999 9.2. Informative References 1001 [3] Clausen, T. and P. Jacquet, "The Optimized Link State Routing 1002 Protocol", RFC 3626, October 2003. 1004 Appendix A. Packet and Message Layout 1006 This section specifies the translation from the abstract descriptions 1007 of packets employed in the protocol specification, and the bit-layout 1008 packets actually exchanged between the nodes. 1010 Appendix A.1. General Packet Format 1012 The basic layout of a packet (excluding transport and IP headers) 1013 SHALL be one of the following five options. 1015 0 1 2 3 1016 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 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 |0 0 0 0 0 0 0 0| Reserved |0|0| Packet Sequence Number | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | | 1021 | Message + Padding | 1022 | | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | | 1025 : ... : 1026 | | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | | 1029 | Message + Padding | 1030 | | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 or 1034 0 1 2 3 1035 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 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 |0 0 0 0 0 0 0 0| Reserved |0|1| Padding | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | | 1040 | Message + Padding | 1041 | | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | | 1044 : ... : 1045 | | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | | 1048 | Message + Padding | 1049 | | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 or 1054 0 1 2 3 1055 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 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 |0 0 0 0 0 0 0 0| Reserved |1|0| Packet Sequence Number | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | | 1060 | Packet TLV Block | 1061 | | 1062 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | | Padding | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | | 1066 | Message + Padding | 1067 | | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | | 1070 : ... : 1071 | | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | | 1074 | Message + Padding | 1075 | | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 or 1079 0 1 2 3 1080 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 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 |0 0 0 0 0 0 0 0| Reserved |1|1| | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1084 | | 1085 | Packet TLV Block | 1086 | | 1087 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 | | Padding | 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 | | 1091 | Message + Padding | 1092 | | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | | 1095 : ... : 1096 | | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | | 1099 | Message + Padding | 1100 | | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 or 1105 0 1 2 3 1106 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 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | | 1109 | Message + Padding | 1110 | | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | | 1113 : ... : 1114 | | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | | 1117 | Message + Padding | 1118 | | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 Note that in the first four cases the Reserved bits SHOULD be zero, 1122 whilst in the last case the first octet MUST NOT be zero (this is 1123 used to recognise this case). In all cases where they are present, 1124 the octets indicated as Padding are optional and MAY be omitted. If 1125 not omitted they SHOULD be used to pad to a 32 bit boundary and MUST 1126 all be zero. 1128 The basic layout of a message, plus padding, SHALL be one of the 1129 following four options. 1131 0 1 2 3 1132 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 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 | Message Type | Resv |N|0|0| Message Size | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | Originator Address | 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | Hop Limit | Hop Count | Message Sequence Number | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | | 1141 | Message Body | 1142 | | 1143 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | | Padding | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 or 1149 0 1 2 3 1150 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 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | Message Type | Resv |N|0|1| Message Size | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 | Hop Limit | Hop Count | | 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1156 | | 1157 | Message Body | 1158 | | 1159 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | | Padding | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 or 1164 0 1 2 3 1165 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 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 | Message Type | Resv |N|1|0| Message Size | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 | Originator Address | 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 | Message Sequence Number | | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1173 | | 1174 | Message Body | 1175 | | 1176 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | | Padding | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 or 1182 0 1 2 3 1183 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 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | Message Type | Resv |N|1|1| Message Size | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | | 1188 | Message Body | 1189 | | 1190 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | | Padding | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 The reserved bits marked Resv SHOULD be zero. The N bit is set ('1') 1195 if the message sequence number is type-dependent, or cleared ('0') if 1196 the message sequence number is type-independent. The octets 1197 indicated as Padding are optional and MAY be omitted. If not omitted 1198 they SHOULD be used to pad to a 32 bit boundary and MUST all be zero; 1199 they are not included in the message size. 1201 The basic layout of a message body SHALL be as follows. 1203 0 1 2 3 1204 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 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | | 1207 | Message TLV Block | 1208 | +-+-+-+-+-+-+-+-+ 1209 | | | 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1211 | | 1212 | Address Block | 1213 | | 1214 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | | | 1216 +-+-+-+-+-+-+-+-+ | 1217 | Address TLV Block | 1218 | | 1219 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | | | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1222 | | 1223 : ... : 1224 | | 1225 | +-+-+-+-+-+-+-+-+ 1226 | | | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1228 | | 1229 | Address Block | 1230 | | 1231 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | | | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1234 | | 1235 | Address TLV Block | 1236 | | 1237 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 | | 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 The basic layout of an address block SHALL be one of the following 1242 three options. 1244 0 1 2 3 1245 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 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | Number Addrs |0| Head Length | Head | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | Mid | | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1251 | | 1252 : ... : 1253 | | 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 | Mid | 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 or 1260 0 1 2 3 1261 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 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Number Addrs |1| Head Length | Head |0| Tail Length | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | Tail | Mid | | 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1267 | | 1268 : ... : 1269 | | 1270 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 | | Mid | 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 or 1275 0 1 2 3 1276 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 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 | Number Addrs |1| Head Length | Head |1| Tail Length | 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 | Mid | | 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1282 | | 1283 : ... : 1284 | | 1285 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 | | Mid | 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 The length of each Mid section is equal to the address length minus 1290 the Head Length and the Tail Length. In the first case there is no 1291 Tail section, the Mid sections are actually tail sections. In the 1292 third case the tail section is not included, it is all octets zero. 1294 The basic layout of a TLV block (packet TLV block, message TLV block 1295 or address TLV block) SHALL be as follows. 1297 0 1 2 3 1298 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 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 | Length | | 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1302 | | 1303 | TLV | 1304 | +-+-+-+-+-+-+-+-+ 1305 | | | 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1307 | | 1308 : ... : 1309 | | 1310 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 | | | 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1313 | | 1314 | TLV | 1315 | +-+-+-+-+-+-+-+-+ 1316 | | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 The Length is of the TLV block contents, it does not include itself 1320 (hence if there are no TLVs then Length is zero). 1322 The basic layout of a TLV SHALL be one of the following six options. 1323 A packet TLV or message TLV SHALL be one of the last three options 1324 only. 1326 0 1 2 3 1327 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 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 | Type | Resv |M|0|0|0| Index Start | Index Stop | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | Length | | 1332 +-+-+-+-+-+-+-+-+ | 1333 | Value | 1334 | | 1335 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 | | 1337 +-+-+-+-+-+-+-+-+ 1339 or 1341 0 1 2 3 1342 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 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | Type | Resv |0|0|0|1| Index Start | Index Stop | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 or 1348 0 1 2 3 1349 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 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 | Type | Resv |M|0|1|0| Index Start | Index Stop | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 | Length | | 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1355 | | 1356 | | 1357 | Value | 1358 | | 1359 | | 1360 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 | | 1362 +-+-+-+-+-+-+-+-+ 1364 or 1366 0 1 2 3 1367 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 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 | Type | Resv |M|1|0|0| Length | | 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1371 | | 1372 | Value | 1373 | | 1374 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | | 1376 +-+-+-+-+-+-+-+-+ 1378 or 1380 0 1 2 3 1381 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 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 | Type | Resv |0|1|0|1| 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 or 1387 0 1 2 3 1388 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 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | Type | Resv |M|1|1|0| Length | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | | 1393 | | 1394 | Value | 1395 | | 1396 | | 1397 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | | 1399 +-+-+-+-+-+-+-+-+ 1401 M denotes the multivalue bit in those cases when it may be set ('1') 1402 or cleared ('0'). In the cases where it MUST be cleared ('0') it is 1403 shown thus; it MUST also be cleared ('0') in a packet TLV or message 1404 TLV.) The reserved bits marked Resv SHOULD also be zero. 1406 An example packet, using IPv4 addresses (length four octets) is 1407 shown. This packet has a header, with a packet sequence number but 1408 no packet TLV block, and contains a single unfragmented message. The 1409 message has a complete message header, a message TLV block of content 1410 length 9 octets containing a single TLV (with the noindex bit of its 1411 semantics set and value length 6 octets) and then two address blocks 1412 each with a following TLV block. The first address block contains 3 1413 addresses (head length 2 octets, no tail, hence mid length two 1414 octets) and is followed by a TLV block of content length 9 octets 1415 containing two TLVs. The first of these TLVs has the noindex bit of 1416 its semantics set and has a single value of length 2 octets, which 1417 applies to all of the addresses in the preceding address block. The 1418 second of these TLVs has the novalue bit of its semantics set and 1419 hence has no length or value fields (it does have index fields, which 1420 indicate which of the addresses this TLV applies to). The second 1421 address block contains 2 addresses (head length 0 octets, hence no 1422 head octets, tail length 2 octets, zero-valued tail not included, 1423 hence mid length two octets) and is followed by a TLV block of 1424 content length 5 octets. This TLV block contains a single TLV of 1425 type PREFIX_LENGTH which has the multivalue and no index bits of its 1426 semantics set and a value field length of 2 octets, indicating two 1427 values each of one octet length. There are two final padding octets 1428 which are not included in the message length of 62 octets. 1430 0 1 2 3 1431 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 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 |0 0 0 0 0 0 0 0| Reserved |0|0| Packet Sequence Number | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 | Message Type | Resv |N|0|0|0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 0| 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 | Originator Address | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 | Hop Limit | Hop Count | Message Sequence Number | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| TLV Type | Resv |0|1|0|0| 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 |0 0 0 0 0 1 1 0| Value | 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 | Value (cont) |0 0 0 0 0 0 1 1| 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 |0 0 0 0 0 0 1 0| Head | Mid | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Mid (cont) | Mid | Mid | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | Mid (cont) |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| TLV Type | 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | Resv |0|1|0|0|0 0 0 0 0 0 1 0| Value | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 | TLV Type | Resv |0|0|0|1| Index Start | Index Stop | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 |0 0 0 0 0 0 1 0|1 0 0 0 0 0 0 0|1 0 0 0 0 0 1 0| Mid | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 | Mid (cont) | Mid |0 0 0 0 0 0 0 0| 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 |0 0 0 0 0 1 0 1| PREFIX_LENGTH | Resv |1|1|0|0|0 0 0 0 0 0 1 0| 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | Value0 | Value1 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 Appendix B. Contributors 1468 This specification is the result of the joint efforts of the 1469 following contributers from the OLSRv2 Design Team -- listed 1470 alphabetically. 1472 o Cedric Adjih, INRIA, France, 1474 o Emmanuel Baccelli, Hitachi Labs Europe, France, 1475 1477 o Thomas Heide Clausen, LIX, Ecole Polytechnique, France, 1478 1480 o Justin W. Dean, NRL, USA 1482 o Christopher Dearlove, BAE Systems, UK, 1483 1485 o Satoh Hiroki, Hitachi SDL, Japan, 1487 o Philippe Jacquet, INRIA, France, 1489 o Monden Kazuya, Hitachi SDL, Japan, 1491 Appendix C. Acknowledgements 1493 The authors would like to acknowledge the team behind OLSRv1, as 1494 specified in RFC3626, including Anis Laouiti, Pascale Minet, Laurent 1495 Viennot (all at INRIA, France), and Amir Qayuum (Center for Advanced 1496 Research in Engineering, Pakistan) for their contributions. 1498 The authors would like to gratefully acknowledge the following people 1499 for intense technical discussions, early reviews and comments on the 1500 specification and its components: Joe Macker (NRL), Alan Cullen (BAE 1501 Systems), Ian Chakeres (Boeing), Charlie E. Perkins (Nokia), Andreas 1502 Schjonhaug (LIX), Florent Brunneau (LIX), and the entire IETF MANET 1503 working group. 1505 Authors' Addresses 1507 Thomas Heide Clausen 1508 LIX, Ecole Polytechnique, France 1510 Phone: +33 6 6058 9349 1511 Email: T.Clausen@computer.org 1512 URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ 1514 Christopher M. Dearlove 1515 BAE Systems Advanced Technology Centre 1517 Phone: +44 1245 242194 1518 Email: chris.dearlove@baesystems.com 1519 URI: http://www.baesystems.com/ocs/sharedservices/atc/ 1521 Justin W. Dean 1522 Naval Research Laboratory 1524 Phone: +1 202 767 3397 1525 Email: jdean@itd.nrl.navy.mil 1526 URI: http://pf.itd.nrl.navy.mil/ 1528 Cedric Adjih 1529 INRIA Rocquencourt 1531 Phone: +33 1 3963 5215 1532 Email: Cedric.Adjih@inria.fr 1534 Intellectual Property Statement 1536 The IETF takes no position regarding the validity or scope of any 1537 Intellectual Property Rights or other rights that might be claimed to 1538 pertain to the implementation or use of the technology described in 1539 this document or the extent to which any license under such rights 1540 might or might not be available; nor does it represent that it has 1541 made any independent effort to identify any such rights. Information 1542 on the procedures with respect to rights in RFC documents can be 1543 found in BCP 78 and BCP 79. 1545 Copies of IPR disclosures made to the IETF Secretariat and any 1546 assurances of licenses to be made available, or the result of an 1547 attempt made to obtain a general license or permission for the use of 1548 such proprietary rights by implementers or users of this 1549 specification can be obtained from the IETF on-line IPR repository at 1550 http://www.ietf.org/ipr. 1552 The IETF invites any interested party to bring to its attention any 1553 copyrights, patents or patent applications, or other proprietary 1554 rights that may cover technology that may be required to implement 1555 this standard. Please address the information to the IETF at 1556 ietf-ipr@ietf.org. 1558 Disclaimer of Validity 1560 This document and the information contained herein are provided on an 1561 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1562 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1563 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1564 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1565 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1566 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1568 Copyright Statement 1570 Copyright (C) The Internet Society (2006). This document is subject 1571 to the rights, licenses and restrictions contained in BCP 78, and 1572 except as set forth therein, the authors retain all their rights. 1574 Acknowledgment 1576 Funding for the RFC Editor function is currently provided by the 1577 Internet Society.