| Network Working Group | T. Clausen |
| Internet-Draft | LIX, Ecole Polytechnique |
| Updates: 5444 (if approved) | C. Dearlove |
| Intended status: Standards Track | BAE Systems AI Labs |
| Expires: December 25, 2015 | U. Herberg |
| H. Rogge | |
| June 23, 2015 |
Rules For Designing Protocols Using the RFC5444 Generalized Packet/Message Format
draft-ietf-manet-rfc5444-usage-00
This document updates the generalized MANET packet/message format, specified in RFC5444, by providing prescriptive guidelines for how protocols can use that packet/message format. In particular, these mandatory guidelines prohibit a number of uses of RFC5444 that have been suggested in various proposals, and which would have lead to interoperability problems, to impediment of protocol extension development, and to inability to use generic RFC5444 parsers.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 25, 2015.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
[RFC5444] specifies a generalized packet/message format, designed for use by MANET routing protocols. [RFC5498] mandates the use of this format by protocols operating over the manet IP protocol and port numbers whose allocation it requested.
Following experiences with [RFC3626] which attempted - but did not quite succeed in - providing a packet/message format accommodating for diverse protocol extensions, [RFC5444] was designed by the MANET working group as a common building block for use by both proactive and reactive MANET routing protocols.
Since the publication of [RFC5444] in 2009, several RFCs have been published, including [RFC5497], [RFC6130], [RFC6621], [RFC7181], [RFC7182], [RFC7183], and [RFC7188], which use the format of [RFC5444]. The ITU-T recommendation [G9903] also uses the format of [RFC5444] for encoding some of its control signals. In developing these specifications, experience with the use of [RFC5444] has been acquired, specifically with respect to how to write specifications using [RFC5444] so as to (i) enable the use of an efficient and generic parser for all protocols using [RFC5444], (ii) ensure "forward compatibility" of a protocol with future extensions, and (iii) enable the creation of efficient messages.
During the same time period, other suggestions have been made to use [RFC5444] in a manner that would lead to incompatibilities with generic RFC 5444 parsers, would inhibit the development of interoperable protocol extensions, or would potentially lead to inefficiencies. While these uses were not all explicitly prohibited by [RFC5444], they should be strongly discouraged. This document is intended to prohibit such uses, to present experiences from designing protocols using [RFC5444] and to provide these as guidelines (with their rationale) for future protocol designs using [RFC5444].
Among the characteristics, and design criteria, of the packet/message format of [RFC5444] are:
This document updates [RFC5444], and is intended for publication as a Proposed Standard (rather than as Informational) because it specifies and mandates constraints on the use of [RFC5444] which, if not followed, make desirable forms of generic parsers impossible, or make forms of extensions of those protocols impossible, or impedes on the ability to generate efficient messages.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This document uses the terminology and notation defined in [RFC5444], specifically the terms "Packet", "Packet Header", "Message", "Message Header", "Address", "Address Block", "TLV" and "TLV Block" are to be interpreted as described therein.
This document does not specify a protocol, but documents constraints on how to design protocols which are using the generic packet/message format defined in [RFC5444] which, if not followed, make desirable forms of generic parsers impossible, or make forms of extensions of those protocols impossible, or impedes on the ability to generate efficient (small) messages. The use of this format is mandated by [RFC5498] for all protocols running over the MANET protocol and port number, defined therein. Thus, the constraints in this document apply to all protocols running over the MANET protocol and port number.
Protocols need to transmit information from one instance implementing the protocol to another.
A protocol has the following choices as to where to put information for transmission:
The first case (a Packet TLV) can only be used when the information is to be carried one hop. It SHOULD only be used either where the information relates to the packet as a whole (for example packet integrity check values and timestamps, as specified in [RFC7182]) or if the information is of expected wider application than the single protocol. A protocol can also request that the packet header include packet sequence numbers, but does not control those numbers.
The second case (in a message of a type owned by another protocol) is only possible if the adding protocol is an extension to the owning protocol, for example OLSRv2 [RFC7181] is an extension of NHDP [RFC6130]. #### SEE COMMENTS IN SVN COMMIT MESSAGE AND ON LIST #### While this is not the most common case, protocols SHOULD be designed to enable this to be possible, and most rules in this document are to help facilitate that. An extension to [RFC5444], such as [RFC7182] is considered to be an extension to all protocols in this regard.
The third case is the normal case for a new protocol. Protocols MUST be conservative in the number of new message types that they require, as the total available number of allocatable message types is only 224. Protocol design SHOULD consider whether different functions can be implemented by differences in TLVs carried in the same message type, rather than using multiple message types. If a protocol's needs can be covered by use of the second case, then this SHOULD be considered.
TLV space, although greater than message space, SHOULD also be used efficiently. The full type of TLV occupies two octets, thus there are many more available TLVs. However, in some cases (currently LINK_METRIC from [RFC7181] and ICV and TIMESTAMP from [RFC7182] in the global TLV space) a full set of 256 TLVs is defined (but not necessarily allocated). Each message has a block of message specific TLV types (128 to 233, each with 256 type extensions), these SHOULD be used in preference to the common TLV types (0 to 127, each with 256 type extensions) when a TLV is message-specific.
A message contains a message header and a message body; note that the Message TLV block is considered as part of the latter. The message header contains information whose primary purpose is to decide whether to process the message, and whether to forward the message. [RFC7181] contains a general purpose process for doing that, albeit one presented as for use with MPR flooding. (Blind flooding can be handled similarly by assuming that all other routers are MPR selectors; it is not necessary in this case to differentiate between interfaces on which a message is received.)
Most protocol information is thus contained in the message body. A model of how such information may be viewed is described in the following section. To use that model, addresses (for example of neighboring or otherwise known routers) SHOULD be recorded in address blocks, not as data in TLVs. Recording addresses in TLV value fields both breaks the model of addresses as identities and associated information (attributes) and also inhibits address compression. However in some cases alternative addresses (e.g., HW addresses when the address block is recording IP addresses) MAY be carried as TLV values. Note that a message contains a Message Address Length (MAL) field that can be used to allow carrying alternative message sizes, but only one length of addresses in all address blocks can be used in a single message.
The [RFC5444] multiplexing process has to handle packet reception and message demultiplexing, and message transmission and packet multiplexing.
When a packet arrives, the following steps are required:
Packets are formed for transmission by:
The information in a message body, including Message TLVs and Address Block TLVs, can be considered to consist of:
Attributes are carried in TLVs. For Message TLVs the mapping from TLV to attribute is one to one. For Address Block TLVs the mapping from TLV to attribute is one to many, one TLV can carry attributes for multiple addresses, but only one attribute per address. Attributes for different addresses may be the same or different.
A TLV extended type may be (and this is RECOMMENDED whenever possible) defined so that there may only be one TLV of that extended type associated with the message (Message TLV) or any value of any address (Address TLV). Note that an address may appear more than once in a message, but the restriction on associating TLVs with addresses covers all copies of that address. It is RECOMMENDED that addresses are not repeated in a message.
It is not mandatory in [RFC5444] to associate an address with attributes using Address Block TLVs, information about an address could thus, in principle be carried using:
This specification, however, requires that those methods of carrying information MUST NOT be used for any protocol using [RFC5444]. Information about the meaning of an address MUST only be carried using Address Block TLVs.
In addition, rules for the extensibility of OLSRv2 and NHDP are described in [RFC7188]. This specification extends their applicability to other uses of [RFC5444].
The following points indicate the reasons for these rules, based on considerations of extensibility and efficiency.
A protocol MUST NOT assign any meaning to the presence, or absence, of an address, as this would prevent the addition of addresses with other meanings. For example consider NHDP's HELLO messages [RFC6130]. The basic function of a HELLO message is to indicate that an address is of a neighbor, using the LINK_STATUS and OTHER_NEIGHB TLVs. An extension to NHDP might decide to use the HELLO message to report that, for example, an address is one that could be used for a specialized purpose, but not for normal NHDP-based purposes. Such an example already exists (but within the basic specification, rather than as an extension) in the use of LOST values in the LINK_STATUS and OTHER_NEIGHB TLVs to report that an address is of a router known not to be a neighbor. A future example might be to list an address to be added to a "blacklist" of addresses not to be used. This would be indicated by a new TLV (or a new value of an existing TLV, see below). An unmodified extension to NHDP would ignore such addresses, as required, as it does not support that specialized purpose. If NHDP had been designed so that just the presence of an address indicated a neighbor, that extension would not have been possible.
This example can be taken further. NHDP must also not reject a HELLO message because it contains an unrecognized TLV. This also applies to unrecognized TLV values, where a TLV supports only a limited set of values. For example, the blacklisting described in the previous paragraph could be signaled not with a new TLV, but with a new value of a LINK_STATUS or OTHER_NEIGHB TLV (requiring an IANA allocation as described in [RFC7188]), as is already done in the LOST case.
Information may also be added to addresses recognized by the base protocol. For example OLSRv2 [RFC7181] is, among other things, an extension to NHDP. It adds information to addresses in an NHDP HELLO message using a LINK_METRIC TLV. A non-OLSRv2 implementation of NHDP (for example, to support SMF [RFC6621]) must still process the HELLO message, ignoring the LINK_METRIC TLVs.
This does not, however, mean that added information is completely ignored for purposes of the base protocol. Suppose that a faulty implementation of OLSRv2 (including NHDP) creates a HELLO message that assigns two different values of the same link metric to an address, something which is not permitted by [RFC7181]. A receiving OLSRv2-aware implementation of NHDP should reject such a message, even though a receiving OLSRv2-unaware implementation of NHDP will process it. This is because the OLSRv2-aware implementation has access to additional information, that the HELLO message is definitely invalid, and the message is best ignored, as it is unknown what other errors it may contain.
The restrictions on the use of address ordering and an address presence or absence in given address blocks for carrying information are for two reasons. First use of those prevents the approach to information representation described in Section 4.5. Second, it reduces the options available for message optimization described in Section 6.
A message (excluding the message header) can thus be represented by two, possibly multivalued, maps:
These maps (plus a representation of the message header) can be the basis for a generic representation of information in a message. Such maps can be created by parsing the message, or can be constructed using the protocol rules for creating a message, and later converted into the octet form of the message specified in [RFC5444].
While of course any implementation of software that represents software in the above form can specify an application programming interface (API) for that software, such an interface is not proposed here. First, a full API would be programming language specific. Second, even within the above framework, there are alternative approaches to such an interface. For example, and for illustrative purposes only, for the address mapping:
Additional differences in the interface may relate to, for example, the ordering of output lists.
In addition to not rejecting a message due to unknown TLVs or TLV values, a protocol MUST NOT fail to forward a message (by whatever means of message forwarding are appropriate to that protocol) due to the presence of such TLVs or TLV values, and MUST NOT remove such TLVs or values. Such behavior would have the consequences that:
The elements defined in [RFC5444] have structures that are managed by a number of flags fields:
Note that all of these flags are structural, they specify which elements are present or absent, or field lengths, or whether a field has one or multiple values in it.
In the current version of [RFC5444], indicated by version number 0 in the <version> field of the packet header, unused bits in these flags fields "are RESERVED and SHOULD each be cleared ('0') on transmission and SHOULD be ignored on reception.".
If a specification introduces new flags in one of the flags fields of a packet, message or Address Block, the following rules MUST be followed:
During the development of [RFC5444], and since publication hereof, some proposals have been made to use these RESERVED flags to specify behavior rather than structure, in particular message forwarding. These were, after due consideration, not accepted, for a number of reasons. These include that message forwarding, in particular, is protocol-specific. For example [RFC7181] forwards messages using its MPR (Multi-Point Relay) mechanism, rather than a "blind" flooding mechanism. The later addition of a 4 bit Message Address Length field later left no spare flags bits at the message level for such use.
The ability to organize addresses into different, or the same, address blocks, as well as to change the order of addresses within an address block, enables avoiding unnecessary repetition of information - and, consequently, generation of smaller messages.
Addresses in an address block can be compressed, and SHOULD be. While no algorithm for compression is given in [RFC5444], an efficient compression algorithm given a set of addresses, has to obey certain contraints.
The protocol using RFC5444 sets the constraints by defining the list of addresses and a list of addressblock TLV types and values for each of the addresses. A compression strategy has to decide two additional things which will have a major influence on the compression efficiency.
The order of addresses can be as simple as sorting the addresses, but if a lot of addresses have the same TLV types attached, it might be more useful to group the messages by sections with same or similar TLV types (e.g. RFC6130 HELLO messages with local interface addresses first and neighbor addresses later).
Compression of address blocks is obtained by considering addresses to consist of a Head, a Mid, and a Tail, where all addresses in an address block have the same Head and Tail, but different Mids. An additional compression is possible when the Tail consists of all zero-valued octets. Expected use cases are IPv4 and IPv6 addresses from within the same prefix and which therefore have a common Head, IPv4 subnets with a common zero-valued Tail, and IPv6 addresses with a common Tail representing an interface identifier as well as a possible common Head. Note that when, for example, IPv4 addresses have a common Head, their Tail will be empty. For example 192.0.2.1 and 192.0.2.2 would have a 3 octet Head, a 1 octet Mid, and a 0 octet Tail.
Address blocks with few similar addresses will save more bytes by using longer Head and Tails in the address block header. Address blocks with a lot of addresses will reduce the overhead created by the address block header and TLV headers for multivalue TLVs. The compression strategy will have to select the tradeof between these two optimizations that will lead to a minimal number of bytes.
The main opportunities for efficient messages when considering TLVs are Address Block TLVs, rather than Message TLVs.
An Address Block TLV provides attributes for one address or a contiguous (as stored in the address block) set of addresses (with a special case for when this is all addresses in an address block). When associated with more than one address, a TLV may be single-valued (associating the same attribute with each address) or multi-valued (associating a separate attribute with each address).
The simplest to implement approach is to use multi-valued TLVs that cover all affected addresses. However unless care is taken to order addresses appropriately, these affected addresses may not all be contiguous. Approaches to this are to:
If, for example, an address block contains five addresses, the first two and the last two requiring values assigned using a LINK_STATUS TLV, but the third does not, then this can be indicated using two TLVs. It is however more efficient to do this with a single multivalue LINK_STATUS TLV, assigning the third address the value UNSPECIFIED. This approach was specified in [RFC7188], and required for protocols that extend [RFC6130] and [RFC7181]. It is here RECOMMNDED that this approach is followed when defining any Address Block TLV that may be used by a protocol using [RFC5444].
It might be argued that this is not necessary in the example above, because the addresses can be reordered. However ordering addresses in such a way for all possible TLVs is not, in general, possible.
As indicated, the LINK_STATUS TLV, and some other TLVs that take single octet values (per address) has a value UNSPECIFIED defined, as the value 255, in [RFC7188]. A similar approach (and a similar value) is RECOMMENDED in any similar cases. Some other TLVs may need a different approach, as noted in [RFC7188], but implicitly permissible before then, the LINK_METRIC TLV has two octet values whose first four bits are flags indicating whether the metric value applies in four cases; if these are all zero then the metric value does not apply in this case, which is thus the equivalent of an UNSPECIFIED value.
There is scope for creating a protocol-independent optimizer for [RFC5444] messages that performs appropriate address re-organization (ordering and block separation) and TLV changes (of number, single- or multi- valuedness and use of unspecified values) to create more compact messages. The possible gain depends on the efficiency of the original message creation, and the specific details of the message. Note that while protocol-independent, this cannot be entirely TLV-independent, for example a LINK_METRIC TLV has a more complicated value structure than a LINK_STATUS TLV does if using unspecified values.
This document does not specify a protocol, but provides rules and recommendations for how to design protocols using [RFC5444]. This document does not introduce any new security considerations; protocols designed according to these guidelines and recommendations are subject to the security considerations detailed in [RFC5444]. In particular the applicability of the security framework for [RFC5444] specified in [RFC7182] is unchanged.
This document has no actions for IANA.
TBD
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. |
| [RFC5444] | Clausen, T., Dearlove, C., Dean, J. and C. Adjih, "Generalized MANET Packet/Message Format", RFC 5444, February 2009. |