idnits 2.17.00 (12 Aug 2021) /tmp/idnits16744/draft-ietf-manet-rfc5444-usage-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5444, updated by this document, for RFC5378 checks: 2006-03-01) -- 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 (July 18, 2017) is 1761 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Clausen 3 Internet-Draft Ecole Polytechnique 4 Updates: 5444 (if approved) C. Dearlove 5 Intended status: Standards Track BAE Systems 6 Expires: January 19, 2018 U. Herberg 8 H. Rogge 9 Fraunhofer FKIE 10 July 18, 2017 12 Rules for Designing Protocols Using the RFC 5444 Generalized Packet/ 13 Message Format 14 draft-ietf-manet-rfc5444-usage-07 16 Abstract 18 RFC 5444 specifies a generalized MANET packet/message format and 19 describes an intended use for multiplexed MANET routing protocol 20 messages that is mandated to use on the port or protocol specified by 21 RFC 5498. This document updates RFC 5444 by providing rules and 22 recommendations for how the multiplexer operates and how protocols 23 can use the packet/message format. In particular, the mandatory 24 rules prohibit a number of uses that have been suggested in various 25 proposals, and which would have led to interoperability problems, to 26 the impediment of protocol extension development, and to an inability 27 to use optional generic parsers. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 19, 2018. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. History and Purpose . . . . . . . . . . . . . . . . . . . 3 65 1.2. RFC 5444 Features . . . . . . . . . . . . . . . . . . . . 3 66 1.2.1. Packet/Message Format . . . . . . . . . . . . . . . . 4 67 1.2.2. Multiplexing and Demultiplexing . . . . . . . . . . . 6 68 1.3. Status of This Document . . . . . . . . . . . . . . . . . 7 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 71 4. Information Transmission . . . . . . . . . . . . . . . . . . . 8 72 4.1. Where to Record Information . . . . . . . . . . . . . . . 8 73 4.2. Message and TLV Type Allocation . . . . . . . . . . . . . 9 74 4.3. Message Recognition . . . . . . . . . . . . . . . . . . . 9 75 4.4. Message Multiplexing and Packets . . . . . . . . . . . . . 10 76 4.4.1. Packet Transmission . . . . . . . . . . . . . . . . . 10 77 4.4.2. Packet Reception . . . . . . . . . . . . . . . . . . . 12 78 4.5. Messages, Addresses and Attributes . . . . . . . . . . . . 13 79 4.6. Addresses Require Attributes . . . . . . . . . . . . . . . 14 80 4.7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 4.8. Message Integrity . . . . . . . . . . . . . . . . . . . . 17 82 5. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 6. Message Efficiency . . . . . . . . . . . . . . . . . . . . . . 19 84 6.1. Address Block Compression . . . . . . . . . . . . . . . . 19 85 6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 6.3. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 21 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 89 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 91 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 92 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 93 Appendix A. Information Representation . . . . . . . . . . . . . 25 94 Appendix B. Automation . . . . . . . . . . . . . . . . . . . . . 26 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 97 1. Introduction 99 [RFC5444] specifies a generalized packet/message format, designed for 100 use by MANET routing protocols. 102 [RFC5444] was designed following experiences with [RFC3626], which 103 attempted to provide a packet/message format accommodating for 104 diverse protocol extensions but did not fully succeed. [RFC5444] was 105 designed as a common building block for use by both proactive and 106 reactive MANET routing protocols. 108 [RFC5498] mandates the use of this packet/message format and of the 109 packet multiplexing process described in an Appendix to [RFC5444] by 110 protocols operating over the manet IP protocol and port numbers that 111 were allocated by [RFC5498]. 113 1.1. History and Purpose 115 Since the publication of [RFC5444] in 2009, several RFCs have been 116 published, including [RFC5497], [RFC6130], [RFC6621], [RFC7181], 117 [RFC7182], [RFC7183], [RFC7188], [RFC7631], and [RFC7722], that use 118 the format of [RFC5444]. The ITU-T recommendation [G9903] also uses 119 the format of [RFC5444] for encoding some of its control signals. In 120 developing these specifications, experience with the use of [RFC5444] 121 has been acquired, specifically with respect to how to write 122 specifications using [RFC5444] so as to ensure forward compatibility 123 of a protocol with future extensions, to enable the creation of 124 efficient messages, and to enable the use of an efficient and generic 125 parser for all protocols using [RFC5444]. 127 During the same time period, other suggestions have been made to use 128 [RFC5444] in a manner that would inhibit the development of 129 interoperable protocol extensions, that would potentially lead to 130 inefficiencies, or that would lead to incompatibilities with generic 131 parsers for [RFC5444]. While these uses were not all explicitly 132 prohibited by [RFC5444], they are strongly discouraged. This 133 document is intended to prohibit such uses, to present experiences 134 from designing protocols using [RFC5444], and to provide these as 135 guidelines (with their rationale) for future protocol designs using 136 [RFC5444]. 138 1.2. RFC 5444 Features 140 [RFC5444] performs two main functions: 142 o It defines a packet/message format for use by MANET routing 143 protocols. As far as [RFC5444] is concerned, it is up to each 144 protocol that uses it to implement the required message parsing 145 and formation. It is natural, especially when implementing more 146 than one such protocol, to implement these processes using 147 protocol-independent packet/message creation and parsing 148 procedures, however this is not required by [RFC5444]. Some 149 comments in this document might be particularly applicable to such 150 a case, but all that is required is that the messages passed to 151 and from protocols are correctly formatted, and that packets 152 containing those messages are correctly formatted as described in 153 the following point. 155 o It specifies, in its Appendix A combined with the intended usage 156 in its Appendix B, a multiplexing and demultiplexing process 157 whereby an entity that can be referred to as the "RFC 5444 158 multiplexer" (in this document simply as the multiplexer, or the 159 demultiplexer when performing that function) manages packets that 160 travel a single (logical) hop, and that contain messages that are 161 owned by individual protocols. A packet can contain messages from 162 more than one protocol. This process is mandated for use on the 163 manet UDP port and IP protocol (alternative means for the 164 transport of packets) by [RFC5498]. The multiplexer is 165 responsible for creating packets and for parsing packet headers, 166 extracting messages, and passing them to the appropriate protocol 167 according to their type (the first octet in the message). 169 1.2.1. Packet/Message Format 171 Among the characteristics and design objectives of the packet/message 172 format of [RFC5444] are: 174 o It is designed for carrying MANET routing protocol control 175 signals. 177 o It defines a packet as a Packet Header with a set of Packet TLVs 178 (Type-Length-Value structures), followed by a set of messages. 179 Each message has a well-defined structure consisting of a Message 180 Header (designed for making processing and forwarding decisions) 181 followed by a set of Message TLVs, and a set of (address, type, 182 value) associations using Address Blocks and their Address Block 183 TLVs. The [RFC5444] packet/message format then enables the use of 184 simple and generic parsing logic for Packet Headers, Message 185 Headers, and message content. 187 A packet can include messages from different protocols, such as 188 [RFC6130] and [RFC7181], in a single transmission. This was 189 observed in [RFC3626] to be beneficial, especially in wireless 190 networks where media contention can be significant. 192 o Its packets are designed to travel between two neighboring 193 interfaces, which will result in a single decrement of the IPv4 194 TTL or IPv6 hop limit. The Packet Header and any Packet TLVs can 195 thus convey information relevant to that link (for example, the 196 Packet Sequence Number can be used to count transmission successes 197 across that link). Packets are designed to be constructed for a 198 single hop transmission; a packet transmission following a 199 successful packet reception is by design a new packet that can 200 include all, some, or none of the received messages, plus possibly 201 additional messages either received in separate packets or 202 generated locally at that router. Messages can thus travel more 203 than one hop and are designed to carry end-to-end protocol 204 signals. 206 o It supports "internal extensibility" using TLVs; an extension can 207 add information to an existing message without that information 208 rendering the message unparseable or unusable by a router that 209 does not support the extension. An extension is typically of the 210 protocol that created the message to be extended, for example 211 [RFC7181] adds information to the HELLO messages created by 212 [RFC6130]. However an extension can also be independent of the 213 protocol, for example [RFC7182] can add ICV (Integrity Check 214 Value) and timestamp information to any message (or to a packet, 215 thus extending the [RFC5444] multiplexer). 217 Information, in the form of TLVs, can be added to the message as a 218 whole, such as the [RFC7182] integrity information, or can be 219 associated with specific addresses in the message, such as the MPR 220 selection and link metric information added to HELLO messages by 221 [RFC7181]. An extension can also add addresses to a message. 223 o It uses address aggregation into compact Address Blocks by 224 exploiting commonalities between addresses. In many deployments, 225 addresses (IPv4 and IPv6) used on interfaces share a common prefix 226 that need not be repeated. Using IPv6, several addresses (of the 227 same interface) might have common interface identifiers that need 228 not be repeated. 230 o It sets up common namespaces, formats, and data structures for use 231 by different protocols, where common parsing logic can be used. 232 For example, [RFC5497] defines a generic TLV format for 233 representing time information (such as interval time or validity 234 time). 236 o It contains a minimal Message Header (a maximum of five elements: 237 type, originator, sequence number, hop count, and hop limit) that 238 permit decisions whether to locally process a message or forward a 239 message (thus enabling MANET-wide flooding of a message) without 240 processing the body of the message. 242 1.2.2. Multiplexing and Demultiplexing 244 The multiplexer (and demultiplexer) is defined in Appendix A of 245 [RFC5444]. Its purpose is to allow multiple protocols to share the 246 same IP protocol or UDP port. That sharing was made necessary by the 247 separation of [RFC6130] from [RFC7181] as separate protocols, and by 248 the allocation of a single IP protocol and UDP port to all MANET 249 protocols, including those protocols, following [RFC5498], which 250 states that "All interoperable protocols running on these well-known 251 IANA allocations MUST conform to [RFC5444]. [RFC5444] provides a 252 common format that enables one or more protocols to share the IANA 253 allocations defined in this document unambiguously.". The 254 multiplexer is the mechanism in [RFC5444] that enables that sharing. 256 The primary purposes of the multiplexer are to: 258 o Accept messages from MANET protocols, which also indicate over 259 which interface(s) the messages are to be sent, and to which 260 destination address. The latter can be a unicast address or the 261 "LL-MANET-Routers" link local multicast address defined in 262 [RFC5498]. 264 o Collect messages, possibly from multiple protocols, for the same 265 interface and destination, into packets to be sent one logical 266 hop, and to send packets using the manet UDP port or IP protocol 267 defined in [RFC5498]. 269 o Extract messages from received packets, and pass them to their 270 owning protocols. 272 The multiplexer's relationship is with the protocols that own the 273 corresponding Message Types. Where those protocols have their own 274 relationships, for example as extensions, this is the responsibility 275 of the protocols. For example OLSRv2 [RFC7181] extends the HELLO 276 messages created by NHDP [RFC6130]. However the multiplexer will 277 deliver HELLO messages to NHDP and will expect to receive HELLO 278 messages from NHDP, the relationship between NHDP and OLSRv2 is 279 between those two protocols. 281 The multiplexer is also responsible for the Packet Header, including 282 any Packet Sequence Number and Packet TLVs. It can accept some 283 additional instructions from protocols, can pass additional 284 information to protocols, and will follow some additional rules; see 285 Section 4.4. 287 1.3. Status of This Document 289 This document updates [RFC5444], and is intended for publication as a 290 Proposed Standard (rather than as Informational) because it specifies 291 and mandates constraints on the use of [RFC5444] that, if not 292 followed, make forms of extensions of those protocols impossible, 293 impede the ability to generate efficient messages, or make desirable 294 forms of generic parsers impossible. 296 Each use of [RFC2119] key words (see Section 2) can be considered as 297 an update to [RFC5444]. In most cases these codify obvious best 298 practice, or constrain the use of [RFC5444] in the circumstances 299 where this specification is applicable (see Section 3). In a few 300 circumstances, operation of [RFC5444] is modified. These are all 301 circumstances that do not occur in its main current uses, in 302 particular by [RFC6130] and [RFC7181] (that might already include the 303 requirement, in particular through [RFC7181]). That such modifying 304 cases are an update to [RFC5444] is explicitly indicated in this 305 specification. 307 2. Terminology 309 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 310 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 311 "OPTIONAL" in this document are to be interpreted as described in 312 [RFC2119]. 314 Use of those key words applies in some cases directly to use of 315 [RFC5444] and applies to existing protocols using it, and applies in 316 some cases to future protocols that use or update [RFC5444] or update 317 existing protocols using it. 319 This document uses the terminology and notation defined in [RFC5444], 320 in particular the terms "packet", "Packet Header", "message", 321 "Message Header", "address", "Address Block", "TLV", and "TLV Block" 322 are to be interpreted as described therein. 324 Additionally, this document uses the following terminology: 326 Full Type (of TLV) - As per [RFC5444], the 16-bit combination of the 327 TLV Type and Type Extension is given the symbolic name , but is not assigned the term "Full Type", which is 329 however assigned by this document as standard terminology. 331 Owning Protocol - As per [RFC5444], for each Message Type, a 332 protocol -- unless specified otherwise, the one making the IANA 333 reservation for that Message Type -- is designated as the "owning 334 protocol" of that Message Type. The (de)multiplexer inspects the 335 Message Type of each received message, and delivers each message 336 to its corresponding "owning protocol". 338 3. Applicability Statement 340 This document does not specify a protocol, but documents constraints 341 on how to design protocols that use the generic packet/message format 342 defined in [RFC5444] that, if not followed, makes forms of extensions 343 of those protocols impossible, impedes the ability to generate 344 efficient (small) messages, or makes desirable forms of generic 345 parsers impossible. The use of the [RFC5444] format is mandated by 346 [RFC5498] for all protocols running over the manet protocol and port, 347 defined therein. Thus, the constraints in this document apply to all 348 protocols running over the manet protocol and port. The constraints 349 are strongly recommended for other uses of [RFC5444]. 351 4. Information Transmission 353 Protocols need to transmit information from one instance implementing 354 the protocol to another. 356 4.1. Where to Record Information 358 A protocol has the following choices as to where to put information 359 for transmission: 361 o In a TLV to be added to the Packet Header. 363 o In a message of a type owned by another protocol. 365 o In a message of a type owned by the protocol. 367 The first case (a Packet TLV) can only be used when the information 368 is to be carried one hop. It SHOULD only be used either where the 369 information relates to the packet as a whole (for example packet 370 integrity check values and timestamps, as specified in [RFC7182]) or 371 if the information is of expected wider application than a single 372 protocol. A protocol can also request that the Packet Header include 373 Packet Sequence Numbers, but does not control those numbers. 375 The second case (in a message of a type owned by another protocol) is 376 only possible if the adding protocol is an extension to the owning 377 protocol; for example OLSRv2 [RFC7181] is an extension of NHDP 378 [RFC6130]. 380 The third case is the normal case for a new protocol. 382 A protocol extension can either be simply an update of the protocol 383 (the third case) or be a new protocol that also updates another 384 protocol (the second case). An example of the latter is that OLSRv2 385 [RFC7181] is a protocol that also extends the HELLO message owned by 386 NHDP [RFC6130]; it thus is an example of both the second and third 387 cases (the latter using the OLSRv2 owned TC message). An extension 388 to [RFC5444], such as [RFC7182], is considered to be an extension to 389 all protocols. Protocols SHOULD be designed to enable extension by 390 any of these means to be possible, and some of the rules in this 391 document (in particular in Section 4.6 and Section 4.8) are to help 392 facilitate that. 394 4.2. Message and TLV Type Allocation 396 Protocols SHOULD be conservative in the number of new Message Types 397 that they require, as the total available number of allocatable 398 Message Types is only 224. Protocol design SHOULD consider whether 399 different functions can be implemented by differences in TLVs carried 400 in the same Message Type, rather than using multiple Message Types. 402 The TLV Type space, although greater than the Message Type space, 403 SHOULD also be used efficiently. The Full Type of a TLV occupies two 404 octets, thus there are many more available TLV Full Types than there 405 are Message Types. However, in some cases (currently LINK_METRIC 406 from [RFC7181] and ICV and TIMESTAMP from [RFC7182], all in the 407 global TLV type space) a TLV Type with a complete set of 256 TLV Full 408 Types is defined (but not necessarily allocated). 410 Each Message Type has an associated block of Message-Type-specific 411 TLV Types (128 to 233, each of with 256 type extensions), both for 412 Address Block TLV Types and Message TLV Types. TLV Types from within 413 these blocks SHOULD be used in preference to the Message-Type- 414 independent Message TLV Types (0 to 127, each with 256 type 415 extensions) when a TLV is specific to a message. 417 The Expert Review guidelines in [RFC5444] are accordingly updated as 418 described in Section 8. 420 4.3. Message Recognition 422 A message contains a Message Header and a Message Body; note that the 423 Message TLV Block is considered as part of the latter. The Message 424 Header contains information whose primary purpose is to decide 425 whether to process the message and whether to forward the message. 427 A protocol might need to recognize whether a message, especially a 428 flooded message, is one that it has previously received, for example 429 to determine whether to process and/or forward it, or to discard it. 430 A message can be recognized as one that has been previously seen if 431 it contains sufficient information in its Message Header. A message 432 MUST be so recognized by the combination of all three of its Message 433 Type, Originator Address, and Message Sequence Number. The inclusion 434 of Message Type allows each protocol to manage its own Message 435 Sequence Numbers, and also allows for the possibility that different 436 Message Types can have greatly differing transmission rates. As an 437 example of such use, [RFC7181] contains a general purpose process for 438 managing processing and forwarding decisions, albeit one presented as 439 for use with MPR flooding. (Blind flooding can be handled similarly 440 by assuming that all other routers are MPR selectors; it is not 441 necessary in this case to differentiate between interfaces on which a 442 message is received.) 444 Most protocol information is thus contained in the Message Body. A 445 model of how such information can be viewed is described in 446 Section 4.5 and Section 4.6. To use that model, addresses (for 447 example of neighboring or otherwise known routers) SHOULD be recorded 448 in Address Blocks, not as data in TLVs. Recording addresses in TLV 449 Value fields both breaks the model of addresses as identities and 450 associated information (attributes) and also inhibits address 451 compression. However in some cases alternative addresses (e.g., 452 hardware addresses when the Address Block is recording IP addresses) 453 can be carried as TLV Values. Note that a message contains a Message 454 Address Length field that can be used to allow carrying alternative 455 message sizes, but only one length of addresses can be used in a 456 single message, in all Address Blocks and the Originator Address, and 457 is established by the router and protocol generating the message. 459 4.4. Message Multiplexing and Packets 461 The multiplexer has to handle message multiplexing into packets and 462 their transmission, and packet reception and demultiplexing into 463 messages. The multiplexer and the protocols that use it are subject 464 to the following rules. 466 4.4.1. Packet Transmission 468 Packets are formed for transmission by: 470 o Outgoing messages are created by their owning protocol and MAY be 471 modified by any extending protocols if the owning protocol permits 472 this. Messages MAY also be forwarded by their owning protocol. 474 It is strongly RECOMMENDED that messages are not modified in the 475 latter case, other than updates to their hop count and hop limit 476 fields, as described in Section 7.1.1 of [RFC5444]. Note that 477 this includes having an identical octet representation, including 478 not allowing a different TLV representation of the same 479 information. This is because it enables end-to-end authentication 480 that ignores (zeros) those two fields (only), as is done by for 481 the Message TLV ICV (Integrity Check Value) calculations in 482 [RFC7182]. Protocols MUST document their behavior with regard to 483 modifiability of messages. 485 o Outgoing messages are then sent to the multiplexer. The owning 486 protocol MUST indicate which interface(s) the messages are to be 487 sent on and their destination address. Note that packets travel 488 one hop; the destination is therefore either a link local 489 multicast address, if the packet is being multicast, or the 490 address of the neighbor interface to which the packet is sent. 492 o The owning protocol MAY request that messages are kept together in 493 a packet; the multiplexer SHOULD respect this request if at all 494 possible. The multiplexer SHOULD combine messages that are sent 495 on the same interface in a packet, whether from the same or 496 different protocols, provided that in so doing the multiplexer 497 does not cause an IP packet to exceed the current MTU (Maximum 498 Transmission Unit). Note that the multiplexer cannot fragment 499 messages; creating suitable sized messages that will not cause the 500 MTU to be exceeded if sent in a single message packet is the 501 responsibility of the protocol generating the message. If a 502 larger message is created then only IP fragmentation is available 503 to allow the packet to be sent, and this is generally considered 504 undesirable, especially when transmission can be unreliable. 506 o The multiplexer MAY delay messages in order to assemble more 507 efficient packets. It MUST respect any constraints on such delays 508 requested by the protocol if it is practical to do so. 510 o If requested by a protocol, the multiplexer MUST, and otherwise 511 MAY, include a Packet Sequence Number in the packet. Such a 512 request MUST be respected as long as the protocol is active. Note 513 that the errata to [RFC5444] indicates that the Packet Sequence 514 Number SHOULD be specific to the interface on which the packet is 515 sent. This specification updates [RFC5444] by requiring that this 516 sequence number MUST be specific to that interface and also that 517 separate sequence numbers MUST be maintained for each destination 518 to which packets are sent with included Packet Sequence Numbers. 519 Addition of Packet Sequence Numbers MUST be consistent, i.e., for 520 each interface and destination the Packet Sequence Number MUST be 521 added to all packets or to none. 523 o An extension to the multiplexer MAY add TLVs to the packet. It 524 MAY also add TLVs to the messages, in which case it is considered 525 as also extended the corresponding protocols. For example 526 [RFC7182] can be used by the multiplexer to add Packet TLVs or 527 Message TLVs, or by the protocol to add Message TLVs. 529 4.4.2. Packet Reception 531 When a packet is received, the following steps are performed by the 532 demultiplexer and by protocols: 534 o The Packet Header and the organization into the messages that it 535 contains MUST be verified by the demultiplexer. 537 o The packet and/or the messages it contains MAY also be verified by 538 an extension to the demultiplexer, such as [RFC7182]. 540 o Each message MUST be sent to its owning protocol, or discarded if 541 the Message Type is not recognized. The demultiplexer MUST also 542 make the Packet Header, and the source and destination addresses 543 in the IP datagram that included the packet, available to the 544 protocol. 546 o The demultiplexer MUST remove any Message TLVs that were added by 547 an extension to the multiplexer. The message MUST be passed on to 548 the protocol exactly as received from (another instance of) the 549 protocol. This is in part an implementation detail. For example 550 an implementation of the multiplexer and of [RFC7182] could add a 551 Message TLV either in the multiplexer or in the protocol, and on 552 reception remove it in the same place. An implementation MUST 553 ensure that the message passed to a protocol is as it would be 554 passed from that protocol by the same implementation, i.e., that 555 the combined implementation on a router is self-consistent, and 556 that messages included in packets by the multiplexer are 557 independent of this implementation detail. 559 o The owning protocol MUST verify each message for correctness; it 560 MUST allow any extending protocol(s) to also contribute to this 561 verification. 563 o The owning protocol MUST process each message. In some cases, 564 which will be defined in the protocol specification, this 565 processing will determine that the message will be ignored. 566 Except in the latter case, the owning protocol MUST also allow any 567 extending protocols to process the message. 569 o The owning protocol MUST manage the hop count and/or hop limit in 570 the message. It is RECOMMENDED that these are handled as 571 described in Appendix B of [RFC5444]; they MUST be so handled if 572 using hop count dependent TLVs such as those defined in [RFC5497]. 574 4.4.2.1. Other Information 576 In addition to the messages between the multiplexer and the protocols 577 in each direction, the following additional information, summarized 578 from other sections in this specification, can be exchanged. 580 o The packet source and destination addresses MUST be sent from 581 (de)multiplexer to protocol. 583 o The Packet Header, including packet sequence number, MUST be sent 584 from (de)multiplexer to protocol if present. (An implementation 585 MAY choose to only do so, or only report the packet sequence 586 number, on request.) 588 o A protocol MAY require that all outgoing packets contain a packet 589 sequence number. 591 o The interface over which a message is to be sent and its 592 destination address MUST be sent from protocol to multiplexer. 593 The destination address MAY be a multicast address, in particular 594 the LL-MANET-Routers link-local multicast address defined in 595 [RFC5498]. 597 o A request to keep messages together in one packet MAY be sent from 598 protocol to multiplexer. 600 o A requested maximum message delay MAY be sent from protocol to 601 multiplexer. 603 The protocol SHOULD also be aware of the MTU that will apply to its 604 messages, if this is available. 606 4.5. Messages, Addresses and Attributes 608 The information in a Message Body, including Message TLVs and Address 609 Block TLVs, can be considered to consist of: 611 o Attributes of the message, each attribute consisting of a Full 612 Type, a length, and a Value (of that length). 614 o A set of addresses, carried in one or more Address Blocks. 616 o Attributes of each address, each attribute consisting of a Full 617 Type, a length, and a Value (of that length). 619 Attributes are carried in TLVs. For Message TLVs the mapping from 620 TLV to attribute is one to one. For Address Block TLVs the mapping 621 from TLV to attribute is one to many: one TLV can carry attributes 622 for multiple addresses, but only one attribute per address. 623 Attributes for different addresses can be the same or different. 625 [RFC5444] requires that when a TLV Full Type is defined, then it MUST 626 also be defined how to handle the cases of multiple TLVs of the same 627 type applying to the same information element - i.e., when more than 628 one Packet TLV of the same TLV Full Type is included in the same 629 Packet Header, when more than one Message TLV of the same TLV Full 630 Type is included in the same Message TLV Block, or when more than one 631 Address Block TLV of the same TLV Full Type applies to the same value 632 of any address. It is RECOMMEMDED that when defining a new TLV Full 633 Type that a rule of the following form is adopted. 635 o If used, there MUST only be only one TLV of that Full Type 636 associated with the packet(Packet TLV), message (Message TLV), or 637 any value of any address (Address Block TLV). 639 Note that this applies to address values; an address can appear more 640 than once in a message, but the restriction on associating TLVs with 641 addresses covers all copies of that address. It is RECOMMENDED that 642 addresses are not repeated in a message. 644 A conceptual way to view this information is described in Appendix A. 646 4.6. Addresses Require Attributes 648 It is not mandatory in [RFC5444] to associate an address with 649 attributes using Address Block TLVs. Information about an address 650 could thus, in principle, be carried using: 652 o The simple presence of an address. 654 o The ordering of addresses in an Address Block. 656 o The use of different meanings for different Address Blocks. 658 This specification, however, requires that those methods of carrying 659 information MUST NOT be used for any protocol using [RFC5444]. 660 Information about the meaning of an address MUST only be carried 661 using Address Block TLVs. 663 In addition, rules for the extensibility of OLSRv2 and NHDP are 664 described in [RFC7188]. This specification extends their 665 applicability to other uses of [RFC5444]. 667 These rules are: 669 o A protocol MUST NOT assign any meaning to the presence or absence 670 of an address (either in a Message or in a given Address Block in 671 a Message), to the ordering of addresses in an Address Block, or 672 to the division of addresses among Address Blocks. 674 o A protocol MUST NOT reject a message based on the inclusion of a 675 TLV of an unrecognized type. The protocol MUST ignore any such 676 TLVs when processing the message. The protocol MUST NOT remove or 677 change any such TLVs if the message is to be forwarded unchanged. 679 o A protocol MUST NOT reject a message based on the inclusion of an 680 unrecognized Value in a TLV of a recognized type. The protocol 681 MUST ignore any such Values when processing the message, but MUST 682 NOT ignore recognized Values in such a TLV. The protocol MUST NOT 683 remove or change any such TLVs if the message is to be forwarded 684 unchanged. 686 o Similar restrictions to the two preceding points apply to the 687 demultiplexer, which also MUST NOT reject a packet based on an 688 unrecognized message; although it will reject any such messages, 689 it MUST deliver any other messages in the packet to their owning 690 protocols. 692 The following points indicate the reasons for these rules, based on 693 considerations of extensibility and efficiency. 695 Assigning a meaning to the presence, absence or location, of an 696 address would reduce the extensibility of the protocol, prevent the 697 approach to information representation described in Appendix A, and 698 reduce the options available for message optimization described in 699 Section 6. 701 To consider how the simple presence of an address conveying 702 information would have restricted the development of an extension, 703 two examples, one actual (included in the base specification, but 704 which could have been added later) and one hypothetical, are 705 considered. 707 The basic function of NHDP's HELLO messages [RFC6130] is to indicate 708 that addresses are of neighbors, using the LINK_STATUS and 709 OTHER_NEIGHB TLVs. (The message can also indicate the router's own 710 addresses, which could also serve as a further example.) 712 An extension to NHDP might decide to use the HELLO message to report 713 that an address is one that could be used for a specialized purpose 714 rather than for normal NHDP-based purposes. Such an example already 715 exists in the use of LOST Values in the LINK_STATUS and OTHER_NEIGHB 716 TLVs to report that an address is of a router known not to be a 717 neighbor. 719 A future example could be to indicate that an address is to be added 720 to a "blacklist" of addresses not to be used. This would use a new 721 TLV (or a new Value of an existing TLV, see below). Assuming that no 722 other TLVs are attached to such blacklisted addresses, then an 723 unmodified extension to NHDP would ignore those addresses, as 724 required. (If however, for example, a LINK_STATUS or OTHER_NEIGHB 725 TLV with Value LOST were also attached to that address, then the 726 receiving router would process that address for that TLV.) If NHDP 727 had been designed so that just the presence of an address indicated a 728 neighbor, this blacklist extension would not be possible. 730 Rejecting a message because it contains an unrecognized TLV Type or 731 an unrecognized TLV Value reduces the extensibility of the protocol. 733 For example, OLSRv2 [RFC7181] is, among other things, an extension to 734 NHDP. It adds information to addresses in an NHDP HELLO message 735 using a LINK_METRIC TLV. A non-OLSRv2 implementation of NHDP, for 736 example to support Simplified Multicast Flooding (SMF) [RFC6621], 737 will still process the HELLO message, ignoring the LINK_METRIC TLVs. 739 Also, the blacklisting described in the example above could be 740 signaled not with a new TLV, but with a new Value of a LINK_STATUS or 741 OTHER_NEIGHB TLV (requiring an IANA allocation as described in 742 [RFC7188]), as is already done in the LOST case. 744 The creation of Multi-Topology OLSRv2 (MT-OLSRv2) [RFC7722], as an 745 extension to OLSRv2 that can interoperate with unextended instances 746 of OLSRv2, would not have been possible without these restrictions, 747 which were applied to NHDP and OLSRv2 by [RFC7181]. 749 These restrictions do not, however, mean that added information is 750 completely ignored for purposes of the base protocol. Suppose that a 751 faulty implementation of OLSRv2 (including NHDP) creates a HELLO 752 message that assigns two different values of the same link metric to 753 an address, something that is not permitted by [RFC7181]. A 754 receiving OLSRv2-aware implementation of NHDP will reject such a 755 message, even though a receiving OLSRv2-unaware implementation of 756 NHDP will process it. This is because the OLSRv2-aware 757 implementation has access to additional information, that the HELLO 758 message is definitely invalid and the message is best ignored, as it 759 is unknown what other errors it might contain. 761 4.7. TLVs 763 Within a message, the attributes are represented by TLVs. 764 Particularly for Address Block TLVs, different TLVs can represent the 765 same information. For example, using the LINK_STATUS TLV defined in 766 [RFC6130], if some addresses have Value SYMMETRIC and some have Value 767 HEARD, arranged in that order, then this information can be 768 represented using two single value TLVs or one multivalue TLV. The 769 latter can be used even if the addresses are not so ordered. 771 A protocol MAY use any representation of information using TLVs that 772 convey the required information. A protocol SHOULD use an efficient 773 representation, but this is a quality of implementation issue. A 774 protocol MUST recognize any permitted representation of the 775 information; even if it chooses to (for example) only use multivalue 776 TLVs, it MUST recognize single value TLVs (and vice versa). 778 A protocol defining new TLVs MUST respect the naming and 779 organizational rules in [RFC7631]. It SHOULD follow the guidance in 780 [RFC7188], in particular see Section 6.3. (This specification does 781 not however relax the application of [RFC7188] where it is mandated.) 783 4.8. Message Integrity 785 In addition to not rejecting a message due to unknown TLVs or TLV 786 Values, a protocol MUST NOT reject a message based on the inclusion 787 of a TLV of an unrecognized type. The protocol MUST ignore any such 788 TLVs when processing the message. The protocol MUST NOT remove or 789 change any such TLVs if the message is to be forwarded unchanged. 790 Such behavior would have the consequences that: 792 o It might disrupt the operation of an extension of which it is 793 unaware. Note that it is the responsibility of a protocol 794 extension to handle interoperation with unextended instances of 795 the protocol. For example OLSRv2 [RFC7181] adds an MPR_WILLING 796 TLV to HELLO messages (created by NHDP, [RFC6130], of which it is 797 in part an extension) to recognize this case (and for other 798 reasons). 800 o It would prevent the operation of end-to-end message 801 authentication using [RFC7182] or any similar mechanism. The use 802 of immutable (apart from hop count and/or hop limit) messages by a 803 protocol is strongly RECOMMENDED for that reason. 805 5. Structure 807 This section concerns the properties of the format defined in 808 [RFC5444] itself, rather than the properties of protocols using it. 810 The elements defined in [RFC5444] have structures that are managed by 811 a number of flags fields: 813 o Packet flags field (4 bits, 2 used) that manages the contents of 814 the Packet Header. 816 o Message flags field (4 bits, 4 used) that manages the contents of 817 the Message Header. 819 o Address Block flags field (8 bits, 4 used) that manages the 820 contents of an Address Block. 822 o TLV flags field (8 bits, 5 used) that manages the contents of a 823 TLV. 825 Note that all of these flags are structural; they specify which 826 elements are present or absent, field lengths, or whether a field has 827 one or multiple values in it. 829 In the current version of [RFC5444], indicated by version number 0 in 830 the field of the Packet Header, unused bits in these flags 831 fields are stated as "are RESERVED and SHOULD each be cleared ('0') 832 on transmission and SHOULD be ignored on reception". For the 833 avoidance of any compatibility issues, for version number 0 this is 834 updated to "MUST each be cleared ('0') on transmission and MUST be 835 ignored on reception". 837 If a specification updating [RFC5444] introduces new flags in one of 838 the flags fields of a packet, Address Block or TLV (there being no 839 unused flags in the message flags field), the following rules MUST be 840 followed: 842 o The version number contained in the field of the Packet 843 Header MUST NOT be 0. 845 o The new flag(s) MUST indicate the structure of the corresponding 846 packet, Address Block, or TLV. They MUST NOT be used to indicate 847 any other semantics, such as message forwarding behavior. 849 An update that would be incompatible with the current specification 850 of [RFC5444] SHOULD NOT be created unless there is a pressing reason 851 for it that cannot be satisfied using the current specification 852 (e.g., by use of a suitable Message TLV or Address Block TLV). 854 During the development of [RFC5444], and since publication thereof, 855 some proposals have been made to use these RESERVED flags to specify 856 behavior rather than structure, in particular message forwarding. 857 These proposals were, after due consideration, not accepted for a 858 number of reasons. These reasons include that message forwarding, in 859 particular, is protocol-specific; for example [RFC7181] forwards 860 messages using its MPR (Multi-Point Relay) mechanism rather than a 861 "blind" flooding mechanism. (These proposals were made during the 862 development of [RFC5444] when there were still unused message flags. 863 Later addition of a 4-bit Message Address Length field later left no 864 unused message flags, but other flags fields still have unused 865 flags.) 867 6. Message Efficiency 869 The ability to organize addresses into the same or different Address 870 Blocks and to change the order of addresses within an Address Block, 871 and the flexibility of the TLV specification, enables avoiding 872 unnecessary repetition of information, and consequently can generate 873 smaller messages. No algorithms for address organization or 874 compression or for TLV usage are given in [RFC5444]; any algorithms 875 that leave the information content unchanged MAY be used when 876 generating a message. See also Appendix B. 878 6.1. Address Block Compression 880 [RFC5444] allows the addresses in an Address Block to be compressed. 881 A protocol generating a message SHOULD compress addresses as much as 882 it can. 884 Addresses in an Address Block consist of a Head, a Mid, and a Tail, 885 where all addresses in an Address Block have the same Head and Tail, 886 but different Mids. Each has a length that is greater than or equal 887 to zero, the sum of the lengths being the address length. (The Mid 888 length is deduced from this relationship.) Compression is possible 889 when the Head and/or the Tail have non-zero length. An additional 890 compression is possible when the Tail consists of all zero-valued 891 octets. Expected use cases are IPv4 and IPv6 addresses from within 892 the same prefix and which therefore have a common Head, IPv4 subnets 893 with a common zero-valued Tail, and IPv6 addresses with a common Tail 894 representing an interface identifier, as well as having a possible 895 common Head. Note that when, for example, IPv4 addresses have a 896 common Head, their Tail will usually have length zero. 898 For example: 900 o The IPv4 addresses 192.0.2.1 and 192.0.2.2 would, for greatest 901 efficiency, have a 3 octet Head, a 1 octet Mid, and a 0 octet 902 Tail. 904 o The IPv6 addresses 2001:DB8:prefix1:interface and 2001:DB8: 905 prefix2:interface that use the same interface identifier but 906 completely different prefixes (except as noted) would, for 907 greatest efficiency, have a 4 octet head, a 4 octet Mid, and an 8 908 octet Tail. (They could have a larger Head and/or Tail and a 909 smaller Mid if the prefixes have any octets in common.) 911 Putting addresses into a message efficiently also has to consider: 913 o The split of the addresses into Address Blocks. 915 o The order of the addresses within the Address Blocks. 917 This split and/or ordering is for efficiency only; it does not 918 provide any information. The split of the addresses affects both the 919 address compression and the TLV efficiency (see Section 6.2); the 920 order of the addresses within an Address Block affects only the TLV 921 efficiency. However using more Address Blocks than is needed can 922 increase the message size due to the overhead of each Address Block 923 and the following TLV Block, and/or if additional TLVs are now 924 required. 926 The order of addresses can be as simple as sorting the addresses, but 927 if many addresses have the same TLV Types attached, it might be more 928 useful to put these addresses together, either within the same 929 Address Block as other addresses or in a separate Address Block. A 930 separate Address Block might also improve address compression, for 931 example if more than one address form is used (such as from 932 independent subnets). An example of the possible use of address 933 ordering is a HELLO message from [RFC6130] that could be generated 934 with local interface addresses first and neighbor addresses later. 935 These could be in separate Address Blocks. 937 6.2. TLVs 939 The main opportunities for creating more efficient messages when 940 considering TLVs are in Address Block TLVs rather than Message TLVs. 941 The approaches described here apply to each Address Block. 943 An Address Block TLV provides attributes for one address or a 944 contiguous (as stored in the Address Block) set of addresses (with a 945 special case for when this is all addresses in the Address Block). 946 When associated with more than one address, a TLV can be single value 947 (associating the same attribute with each address) or multivalue 948 (associating a separate attribute with each address). 950 The simplest to implement approach is to use multivalue TLVs that 951 cover all affected addresses. However unless care is taken to order 952 addresses appropriately, these affected addresses might not all be 953 contiguous. Approaches to this are to: 955 o Reorder the addresses. It is, for example, possible (though not 956 straightforward, and beyond the scope of this document to describe 957 exactly how) to order all addresses in HELLO message as specified 958 in [RFC6130] so that all TLVs used only cover contiguous 959 addresses. This is even possible if the MPR TLV specified in 960 OLSRv2 [RFC7181] is added; but it is not possible, in general, if 961 the LINK_METRIC TLV specified in OLSRv2 [RFC7181] is also added. 963 o Allow the TLV to span over addresses that do not need the 964 corresponding attribute, using a Value that indicates no 965 information; see Section 6.3. 967 o Use more than one TLV. Note that this can be efficient when the 968 TLVs thus become single value TLVs. In a typical case where a 969 LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with 970 enough addresses, sorted appropriately, two single value TLVs can 971 be more efficient than one multivalue TLV. If only one Value is 972 involved, such as NHDP in a steady state with LINK_STATUS equal to 973 SYMMETRIC in all cases, then one single value TLV SHOULD always be 974 used. 976 6.3. TLV Values 978 If, for example, an Address Block contains five addresses, the first 979 two and the last two requiring Values assigned using a LINK_STATUS 980 TLV, but the third does not, then this can be indicated using two 981 TLVs. It is however more efficient to do this with one multivalue 982 LINK_STATUS TLV, assigning the third address the Value UNSPECIFIED. 983 In general, use of UNSPECIFIED Values allows use of fewer TLVs and 984 thus often an efficiency gain; however a long run of consecutive 985 UNSPECIFIED Values (more than the overhead of a TLV) can make more 986 TLVs more efficient. 988 Some other TLVs might need a different approach. As noted in 989 [RFC7188], but implicitly permissible before then, the LINK_METRIC 990 TLV, defined in [RFC7181], has two octet Values whose first four bits 991 are flags indicating whether the metric applies in four cases; if 992 these are all zero then the metric does not apply in this case, which 993 is thus the equivalent of an UNSPECIFIED Value. 995 [RFC7188] requires that protocols that extend [RFC6130] and [RFC7181] 996 allow unspecified values in TLVs where applicable; it is here 997 RECOMMENDED that all protocols follow that advice. In particular it 998 is RECOMMENDED that when defining an Address Block TLV with discrete 999 Values that an UNSPECIFIED Value is defined with the same value 1000 (255); and that a modified approach is used where possible for other 1001 Address Block TLVs, for example as is done for a LINK_METRIC TLV 1002 (though not necessarily using that exact approach). 1004 It might be argued that provision of an unspecified value (of any 1005 form) to allow an Address Block TLV to cover unaffected addresses is 1006 not always necessary because addresses can be reordered to avoid 1007 this. However ordering addresses to avoid this for all TLVs that 1008 might be used is not, in general, possible. 1010 In addition, [RFC7188] recommends that if a TLV Value (per address 1011 for an Address Block TLV) has a single-length that does not match the 1012 defined length for that TLV Type, then the following rules are 1013 adopted: 1015 o If the received single-length is greater than the expected single- 1016 length, then the excess octets MUST be ignored. 1018 o If the received single-length is less than the expected single- 1019 length, then the absent octets MUST be considered to have all bits 1020 cleared (0). 1022 This specification RECOMMENDEDS a similar rule for all protocols 1023 defining new TLVs. 1025 7. Security Considerations 1027 This document does not specify a protocol, but provides rules and 1028 recommendations for how to design protocols using [RFC5444], whose 1029 security considerations apply. 1031 If the recommendation in Section 4.4.1 that messages are not modified 1032 (except for hop count and hop limit) when forwarded is followed, then 1033 the security framework for [RFC5444] specified in [RFC7182] can be 1034 used in full. If that recommendation is not followed, then the 1035 Packet TLVs from [RFC7182] can be used, but the Message TLVs from 1036 [RFC7182] cannot be used as intended. 1038 In either case, a protocol using [RFC5444] MUST document whether it 1039 is using [RFC7182] and if so, how. 1041 8. IANA Considerations 1043 The Expert Review guidelines in [RFC5444] are updated to include the 1044 general requirement that: 1046 o The Designated Expert will consider the limited TLV and, 1047 especially, Message Type space in considering whether a requested 1048 allocation is allowed, and whether a more efficient allocation 1049 than that requested is possible. 1051 9. Acknowledgments 1053 The authors thank Cedric Adjih (INRIA) and Justin Dean (NRL) for 1054 their contributions as authors of RFC 5444. 1056 10. References 1058 10.1. Normative References 1060 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1061 Requirement Levels", RFC 2119, BCP 14, March 1997. 1063 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 1064 "Generalized MANET Packet/Message Format", RFC 5444, 1065 February 2009. 1067 [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network 1068 (MANET) Protocols", RFC 5498, March 2009. 1070 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 1071 Check Value and Timestamp TLV Definitions for Mobile Ad 1072 Hoc Networks (MANETs)", RFC 7182, April 2014. 1074 [RFC7631] Dearlove, C. and T. Clausen, "TLV Naming in the MANET 1075 Generalized Packet/Message Format", RFC 7631, 1076 January 2015. 1078 10.2. Informative References 1080 [G9903] "ITU-T G.9903: Narrow-band orthogonal frequency division 1081 multiplexing power line communication transceivers for G3- 1082 PLC networks", May 2013. 1084 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 1085 Routing Protocol", RFC 3626, October 2003. 1087 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 1088 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 1089 March 2009. 1091 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 1092 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 1093 RFC 6130, April 2011. 1095 [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, 1096 May 2012. 1098 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 1099 "The Optimized Link State Routing Protocol version 2", 1100 RFC 7181, April 2014. 1102 [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity 1103 Protection for the Neighborhood Discovery Protocol (NHDP) 1104 and Optimized Link State Routing Protocol Version 2 1105 (OLSRv2)", RFC 7183, April 2014. 1107 [RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing 1108 Protocol version 2 (OLSRv2) and MANET Neighborhood 1109 Discovery Protocol (NHDP) Extension TLVs", RFC 7188, 1110 April 2014. 1112 [RFC7722] Dearlove, C. and T. Clausen, "Multi-Topology Extension for 1113 the Optimized Link State Routing Protocol Version 2 1114 (OLSRv2)", RFC 7722, December 2015. 1116 Appendix A. Information Representation 1118 This section describes a conceptual way to consider the information 1119 in a message. It can be used as the basis of an approach to parsing 1120 a message from the information that it contains and to creating a 1121 message from the information that it is to contain. However there is 1122 no requirement that a protocol does so. This approach can be used 1123 either to inform a protocol design, or by a protocol (or generic 1124 parser) implementer. 1126 A message (excluding the Message Header) can be represented by two, 1127 possibly multivalued, maps: 1129 o Message: (Full Type) -> (length, Value) 1131 o Address: (address, Full Type) -> (length, Value) 1133 These maps (plus a representation of the Message Header) can be the 1134 basis for a generic representation of information in a message. Such 1135 maps can be created by parsing the message, or can be constructed 1136 using the protocol rules for creating a message and later converted 1137 into the octet form of the message specified in [RFC5444]. 1139 While of course any implementation of software that represents 1140 software in the above form can specify an application programming 1141 interface (API) for that software, such an interface is not proposed 1142 here. First, a full API would be programming language specific. 1143 Second, even within the above framework, there are alternative 1144 approaches to such an interface. For example, and for illustrative 1145 purposes only, for the address mapping: 1147 o Input: address and Full Type. Output: list of (length, Value) 1148 pairs. Note that for most Full Types it will be known in advance 1149 that this list will have length zero or one. The list of 1150 addresses that can be used as inputs with non-empty output would 1151 need to be provided as a separate output. 1153 o Input: Full Type. Output: list of (address, length, Value) 1154 triples. As this list length can be significant, a possible 1155 output will be of one or two iterators that will allow iterating 1156 through that list. (One iterator that can detect the end of list, 1157 or a pair of iterators specifying a range.) 1159 Additional differences in the interface might relate to, for example, 1160 the ordering of output lists. 1162 Appendix B. Automation 1164 There is scope for creating a protocol-independent optimizer for 1165 [RFC5444] messages that performs appropriate address re-organization 1166 (ordering and Address Block separation) and TLV changes (of number, 1167 single- or multi- valuedness, and use of unspecified values) to 1168 create more compact messages. The possible gain depends on the 1169 efficiency of the original message creation and the specific details 1170 of the message. Note that this process cannot be TLV Type 1171 independent; for example a LINK_METRIC TLV has a more complicated 1172 Value structure than a LINK_STATUS TLV does if using UNSPECIFIED 1173 Values. 1175 Such a protocol-independent optimizer MAY be used by the router 1176 generating a message, but MUST NOT be used on a message that is 1177 forwarded unchanged by a router. 1179 Authors' Addresses 1181 Thomas Clausen 1182 Ecole Polytechnique 1183 91128 Palaiseau Cedex, 1184 France 1186 Phone: +33-6-6058-9349 1187 Email: T.Clausen@computer.org 1188 URI: http://www.thomasclausen.org 1189 Christopher Dearlove 1190 BAE Systems Applied Intelligence Laboratories 1191 West Hanningfield Road 1192 Great Baddow, Chelmsford 1193 United Kingdom 1195 Email: chris.dearlove@baesystems.com 1196 URI: http://www.baesystems.com 1198 Ulrich Herberg 1200 Email: ulrich@herberg.name 1201 URI: http://www.herberg.name 1203 Henning Rogge 1204 Fraunhofer FKIE 1205 Fraunhofer Strasse 20 1206 53343 Wachtberg 1207 Germany 1209 Email: henning.rogge@fkie.fraunhofer.de