diff options
Diffstat (limited to 'doc/rfc/rfc5497.txt')
| -rw-r--r-- | doc/rfc/rfc5497.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc5497.txt b/doc/rfc/rfc5497.txt new file mode 100644 index 0000000..4f531a7 --- /dev/null +++ b/doc/rfc/rfc5497.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group T. Clausen +Request for Comments: 5497 LIX, Ecole Polytechnique +Category: Standards Track C. Dearlove + BAE Systems ATC + March 2009 + + + Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 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 in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Abstract + + This document describes a general and flexible TLV (type-length-value + structure) for representing time-values, such as an interval or a + duration, using the generalized Mobile Ad hoc NETwork (MANET) packet/ + message format. It defines two Message TLVs and two Address Block + TLVs for representing validity and interval times for MANET routing + protocols. + + + +Clausen & Dearlove Standards Track [Page 1] + +RFC 5497 Time TLV March 2009 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Motivation and Rationale . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 + 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 + 5. Representing Time . . . . . . . . . . . . . . . . . . . . . . 6 + 6. General Time TLV Structure . . . . . . . . . . . . . . . . . . 7 + 6.1. Single-Value Time TLVs . . . . . . . . . . . . . . . . . . 8 + 6.2. Multi-Value Time TLVs . . . . . . . . . . . . . . . . . . 9 + 7. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7.1. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 10 + 7.2. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 10 + 8. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 10 + 8.1. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 10 + 8.2. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 11 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 9.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 11 + 9.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 12 + 9.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 12 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 + + + + + + + + + + + + + + + + + + + + + + + + + +Clausen & Dearlove Standards Track [Page 2] + +RFC 5497 Time TLV March 2009 + + +1. Introduction + + The generalized packet/message format [RFC5444] specifies a signaling + format that MANET routing protocols can employ for exchanging + protocol information. This format presents the ability to express + and associate attributes to packets, messages, or addresses, by way + of a general TLV (type-length-value) mechanism. + + This document specifies a general Time TLV structure, which can be + used by any MANET routing protocol that needs to express either + single time-values or a set of time-values with each time-value + associated with a range of hop counts, as provided by the Message + Header of [RFC5444]. This allows a receiving node to determine a + single time-value if either it knows its hop count from the + originator node or the Time TLV specifies a single time-value. + + A time-value is, in this context, not an "absolute point in time", + but rather an interval or a duration. An instance of a Time TLV can, + therefore, express an interval or a duration such as "10 seconds". + + This document also specifies two Message TLV Types, which use the TLV + structure proposed. These TLV Types are INTERVAL_TIME and + VALIDITY_TIME, specifying, respectively, the maximum time before + another message of the same type as this message from the same + originator should be received, and the duration for which the + information in this message is valid after receipt. Note that, if + both are present, then the latter will usually be greater than the + former in order to allow for possible message loss. + + This document also specifies two Address Block TLV Types, which use + the TLV structure proposed. These TLV Types are INTERVAL_TIME and + VALIDITY_TIME, defined equivalently to the two Message TLVs with the + same names. + +1.1. Motivation and Rationale + + The Time TLV structure, specified in this document, is intended to be + used as a component in a MANET routing protocol, e.g., to indicate + the expected spacing between successive transmissions of a given + Message Type, by including a Time TLV in transmitted messages. + + Some MANET routing protocols may employ very short spacing for some + messages and very long spacing for others, or may change the message + transmission rate according to observed behavior. For example, if a + network is observed at some point in time to exhibit a highly dynamic + topology, a very short (sub-second) message spacing could be + appropriate, whereas if the network later is observed to stabilize, + multi-hour message spacing may become appropriate. Different MANET + + + +Clausen & Dearlove Standards Track [Page 3] + +RFC 5497 Time TLV March 2009 + + + routing protocols and different deployments of MANET routing + protocols may have different granularity requirements and bounds on + shortest and longest spacing between successive message + transmissions. + + In addition, MANET routing protocol deployments typically use + bandwidth-limited wireless network interfaces, and therefore prefer + to trade off computational complexity for a saving in the number of + bits transmitted. This is practical in this case, because the + intended usages of Time TLVs, including the specified examples of + message interval time and information validity time, do not require + high-precision values of time. + + The Time TLV structure, specified in this document, caters to these + characteristics by: + + o encoding time-values, such as an interval or a duration, in an + 8-bit field; while + + o allowing these time-values to range from "very small" (e.g., + 1/1024 second) to "very long" (e.g., 45 days); and + + o allowing a MANET routing protocol, or a deployment, to + parameterize this (e.g., to attain finer granularity at the + expense of a lower upper bound) through a single parameter, C. + + The parameter C must be the same for all MANET routers in the same + deployment. + + The TLV mechanism as specified in [RFC5444] allows associating a + "value" to either a packet, a message, or to addresses. The data + structure for doing so -- the TLV -- is identical in each of the + three cases; however, the TLV's position in a received packet allows + determining if that TLV is a "Packet TLV" (it appears in the Packet + Header, before any messages), a "Message TLV" (it appears in the TLV + Block immediately following a Message Header), or an "Address Block + TLV" (it appears in the TLV Block immediately following an Address + Block). + + While TLVs may be structurally identical, that which they express may + be different. This is determined from the kind (packet, message, or + Address Block) and type of the TLV. For example, one TLV might + associate a lifetime to an address, another a content sequence number + to a message, and another a cryptographic signature to a packet. For + this reason, [RFC5444] specifies separate registries for Packet TLV + Types, Message TLV Types, and Address Block TLV Types, and it does + not specify any structure in the TLV Value field. + + + + +Clausen & Dearlove Standards Track [Page 4] + +RFC 5497 Time TLV March 2009 + + + The TLVs defined in this document express, essentially, that "this + information will be refreshed within X seconds" and that "this + information is valid for X seconds after being received", each + allowing the "X seconds" to be specified as a function of the number + of hops from the originator of the information. This document + specifies a general format allowing expressing and encoding this as + the value field of a TLV. This representation uses a compact (8-bit) + representation of time, as message size is an issue in many MANETs, + and the offered precision and range is appropriate for MANET routing + protocols. + + A TLV of this format may be used for packets, messages, or addresses. + For example, a proactive MANET routing protocol periodically + reporting link-state information could include a TLV of this format + as a Message TLV. This may indicate a different periodicity in + different scopes (possibly frequently up to a few hops, less + frequently beyond that) because some messages may be sent with + limited scope, as specified in [RFC5444]. A reactive MANET routing + protocol could include a TLV of this format as an Address Block TLV + for reporting the lifetime of routes to individual addresses. + + In addition to defining the general format as outlined above, this + document requests IANA assignments for INTERVAL_TIME and + VALIDITY_TIME TLVs. These IANA assignments are requested in this + document in order to avoid interdependencies between otherwise + unrelated MANET protocols and in order to not exhaust the TLV Type + spaces by having different protocols request types for essentially + identical data structures. Only Message TLVs and Address Block TLVs + are requested, as these are those for which a need has been + demonstrated. + +2. Terminology + + 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]. + + Additionally, this document uses terminology from [RFC5444], and + introduces the following terminology: + + hop count - the number of hops from the message originator to the + message recipient. This is defined to equal the <msg-hop-count> + field in the <msg-header> element defined in [RFC5444], if + present, after it is incremented on reception. If the <msg-hop- + count> field is not present, or in a Packet TLV, then hop count is + defined to equal 255. + + + + +Clausen & Dearlove Standards Track [Page 5] + +RFC 5497 Time TLV March 2009 + + + time-value - a time, measured in seconds. + + time-code - an 8-bit field, representing a time-value. + +3. Applicability Statement + + The TLV structure described in this document is applicable whenever a + single time-value, or a time-value that varies with the number of + hops from the originator of a message, is required in a protocol + using the generalized MANET packet/message format [RFC5444]. + + Examples of time-values that may be included in a protocol message + are: + + o The maximum time interval until the next message of the same type + is to be generated by the message's originator node. + + o The validity time of the information with which the time-value is + associated. + + Either of these may vary with the hop count between the originating + and receiving nodes, e.g., if messages of the same type are sent with + different hop limits as defined in [RFC5444]. + + Parts of this document have been generalized from material in the + proactive MANET routing protocol OLSR (Optimized Link State Routing + Protocol) [RFC3626]. + +4. Protocol Overview and Functioning + + This document does not specify a protocol nor does it mandate + specific node or protocol behavior. Rather, it outlines mechanisms + for encoding time-values using the TLV mechanism of [RFC5444]. + +5. Representing Time + + This document specifies a TLV structure in which time-values are each + represented in an 8-bit time-code, one or more of which may be used + in a TLV's <value> field. Of these 8 bits, the least significant 3 + bits represent the mantissa (a), and the most significant 5 bits + represent the exponent (b), so that: + + o time-value := (1 + a/8) * 2^b * C + + o time-code := 8 * b + a + + + + + + +Clausen & Dearlove Standards Track [Page 6] + +RFC 5497 Time TLV March 2009 + + + All nodes in the MANET MUST use the same value of the constant C, + which will be specified in seconds, hence so will be all time-values. + C MUST be greater than 0 seconds. Note that ascending values of the + time-code represent ascending time-values; time-values may thus be + compared by comparison of time-codes. + + An algorithm for computing the time-code representing the smallest + representable time-value not less than the time-value t is: + + 1. find the largest integer b such that t/C >= 2^b; + + 2. set a := 8 * (t / (C * 2^b) - 1), rounded up to the nearest + integer; + + 3. if a = 8, then set b := b + 1 and set a := 0; + + 4. if 0 <= a <= 7, and 0 <= b <= 31, then the required time-value + can be represented by the time-code 8 * b + a, otherwise it + cannot. + + The minimum time-value that can be represented in this manner is C. + The maximum time-value that can be represented in this manner is 15 * + 2^28 * C, or about 4.0 * 10^9 * C. If, for example, C = 1/1024 + second, then this is about 45 days. + + A protocol using this time representation MUST define the value of C. + A protocol using this specification MAY specify that the all-bits + zero time-value (0) represents a time-value of zero and/or that the + all-bits one time-value (255) represents an indefinitely large time- + value. + +6. General Time TLV Structure + + The following data structure allows the representation of a single + time-value, or of a default time-value plus pairs of (time-values, + hop counts) for when hop-count-dependent time-values are required. + The time-values are represented as time-codes as defined in + Section 5. This <time-data> data structure is specified, using the + regular expression syntax of [RFC5444], by: + + <time-data> = (<time-code><hop-count>)*<time-code> + + where: + + <time-code> is an 8-bit unsigned integer field containing a time- + code as defined in Section 5. + + + + + +Clausen & Dearlove Standards Track [Page 7] + +RFC 5497 Time TLV March 2009 + + + <hop-count> is an 8-bit unsigned integer field specifying a hop + count from the message originator. + + A <time-data> structure thus consists of an odd number of octets; + with a repetition factor of n for the (time, hop count) pairs in the + regular expression syntax, it contains 2n+1 octets. On reception, n + is determined from the length. + + A <time-data> field may be thus represented by: + + <t_1><d_1><t_2><d_2> ... <t_i><d_i> ... <t_n><d_n><t_default> + + <d_1>, ... <d_n>, if present, MUST be a strictly increasing sequence, + with <d_n> < 255. Then, at the receiving node's hop count from the + originator node, the time-value indicated is that represented by the + time-code: + + o <t_1>, if n > 0 and hop count <= <d_1>; + + o <t_i+1>, if n > 1 and <d_i> < hop count <= <d_i+1> for some i such + that 1 <= i < n; + + o <t_default> otherwise, i.e. if n = 0 or hop count > <d_n>. + + If included in a message without a <msg-hop-count> field in its + Message Header, or in a Packet TLV, then the form of this data + structure with a single time-code in <time-data> (i.e., n = 0) SHOULD + be used. + +6.1. Single-Value Time TLVs + + The purpose of a single value Time TLV is to allow a single time- + value to be determined by a node receiving an entity containing the + Time TLV, based on its hop count from the entity's originator. The + Time TLV may contain information that allows that time-value to be a + function of the hop count; thus, different receiving nodes may + determine different time-values. + + A single-value Time TLV may be a Packet TLV, a Message TLV, or an + Address Block TLV. + + A Time TLV that has the tismultivalue flag cleared ('0') in its <tlv- + flags> field, as defined in [RFC5444], contains a single <time-data>, + as defined above, in its <value> field. For such a Time TLV: + + o The <length> field in the TLV MUST contain the value 2n+1, with n + being the number of (time-value, hop count) pairs in the Time TLV. + + + + +Clausen & Dearlove Standards Track [Page 8] + +RFC 5497 Time TLV March 2009 + + + o The number of (time-value, hop count) pairs MUST be identified by + inspecting the <length> field in the TLV. The number of such + pairs, n, is: + + * n := (<length> - 1) / 2 + + This MUST be an integer value. + +6.2. Multi-Value Time TLVs + + The purpose of a multi-value Time TLV is to associate a set of <time- + data> structures to an identically sized set of addresses, as + described in [RFC5444]. For each of these <time-data> structures, a + single time-value can be determined by a node receiving an entity + containing the Time TLV, based on its hop count from the entity's + originator. The Time TLV may contain information that allows that + time-value to be a function of the hop count, and thus different + receiving nodes may determine different time-values. + + Multi-value Time TLVs MUST be Address Block TLVs. A multi-value Time + TLV MUST NOT be a Packet TLV or Message TLV. + + A Time TLV that has the tismultivalue flag set ('1') in its <tlv- + flags> field, as defined in [RFC5444], contains a sequence of <time- + data> structures, as defined above, in its <value> field. For such a + Time TLV: + + o The <length> field in the TLV MUST contain the value m * (2n+1), + with n being the number of (time-value, hop count) pairs in the + Time TLV, and m being number-values as defined in [RFC5444]. + + o The number of <time-data> structures included in the <value> field + is equal to number-values as defined in [RFC5444]. + + o The number of (time-value, hop count) pairs in each <time-data> + structure MUST be the same, and MUST be identified by inspecting + the <length> field in the TLV and using number-values as defined + in [RFC5444]. The number of such pairs in each <time-data> + structure, n, is: + + * n := ((<length> / number-values) - 1) / 2 + + This MUST be an integer value. The lists of hop count values MAY + be different. + + + + + + + +Clausen & Dearlove Standards Track [Page 9] + +RFC 5497 Time TLV March 2009 + + +7. Message TLVs + + Two Message TLVs are defined, for signaling message interval + (INTERVAL_TIME) and message validity time (VALIDITY_TIME). + +7.1. INTERVAL_TIME TLV + + An INTERVAL_TIME TLV is a Message TLV that defines the maximum time + before another message of the same type as this message from the same + originator should be received. This interval time MAY be specified + to depend on the hop count from the originator. (This is appropriate + if messages are sent with different hop limits so that receiving + nodes at greater hop counts have an increased interval time.) + + A message MUST NOT include more than one INTERVAL_TIME TLV. + + An INTERVAL_TIME TLV is an example of a Time TLV specified as in + Section 5. + +7.2. VALIDITY_TIME TLV + + A VALIDITY_TIME TLV is a Message TLV that defines the validity time + of the information carried in the message in which the TLV is + contained. After this time, the receiving node MUST consider the + message content to no longer be valid (unless repeated in a later + message). The validity time of a message MAY be specified to depend + on the hop count from its originator. (This is appropriate if + messages are sent with different hop limits so that receiving nodes + at greater hop counts receive information less frequently and must + treat is as valid for longer.) + + A message MUST NOT include more than one VALIDITY_TIME TLV. + + A VALIDITY_TIME TLV is an example of a Time TLV specified as in + Section 5. + +8. Address Block TLVs + + Two Address Block TLVs are defined, for signaling address + advertisement interval (INTERVAL_TIME) and address validity time + (VALIDITY_TIME). + +8.1. INTERVAL_TIME TLV + + An INTERVAL_TIME TLV is an Address Block TLV that defines the maximum + time before this address from the same originator should be received + again. This interval time MAY be specified to depend on the hop + count from the originator. (This is appropriate if addresses are + + + +Clausen & Dearlove Standards Track [Page 10] + +RFC 5497 Time TLV March 2009 + + + contained in messages sent with different hop limits so that + receiving nodes at greater hop counts have an increased interval + time.) + + A protocol using this TLV and the same named Message TLV MUST specify + how to interpret the case when both are present (typically, that the + former overrides the latter for those addresses that are covered by + the former). + + An INTERVAL_TIME TLV is an example of a Time TLV specified as in + Section 5. + +8.2. VALIDITY_TIME TLV + + A VALIDITY_TIME TLV is an Address Block TLV that defines the validity + time of the addresses to which the TLV is associated. After this + time, the receiving node MUST consider the addresses to no longer be + valid (unless these are repeated in a later message). The validity + time of an address MAY be specified to depend on the hop count from + its originator. (This is appropriate if addresses are contained in + messages sent with different hop limits so that receiving nodes at + greater hop counts receive information less frequently and must treat + is as valid for longer.) + + A protocol using this TLV and the same named Message TLV MUST specify + how to interpret the case when both are present (typically, that the + former overrides the latter for those addresses that are covered by + the former). + + A VALIDITY_TIME TLV is an example of a Time TLV specified as in + Section 5. + +9. IANA Considerations + + This specification defines two Message TLV Types, which have been + allocated from the "Assigned Message TLV Types" repository of + [RFC5444] as specified in Table 1, and two Address Block TLV Types, + which have been allocated from the "Assigned Address Block TLV Types" + repository of [RFC5444] as specified in Table 2. + + IANA has assigned the same numerical value to the Message TLV Type + and Address Block TLV Type with the same name. + +9.1. Expert Review: Evaluation Guidelines + + For the registries for TLV Type Extensions where an Expert Review is + required, the designated expert SHOULD take the same general + recommendations into consideration as are specified by [RFC5444]. + + + +Clausen & Dearlove Standards Track [Page 11] + +RFC 5497 Time TLV March 2009 + + +9.2. Message TLV Types + + +---------------+------+-----------+--------------------------------+ + | Name | Type | Type | Description | + | | | Extension | | + +---------------+------+-----------+--------------------------------+ + | INTERVAL_TIME | 0 | 0 | The maximum time before | + | | | | another message of the same | + | | | | type as this message from the | + | | | | same originator should be | + | | | | received | + | Unassigned | 0 | 1-223 | Expert Review | + | | | 224-255 | Experimental Use | + | VALIDITY_TIME | 1 | 0 | The time from receipt of the | + | | | | message during which the | + | | | | information contained in the | + | | | | message is to be considered | + | | | | valid | + | Unassigned | 1 | 1-223 | Expert Review | + | | | 224-255 | Experimental Use | + +---------------+------+-----------+--------------------------------+ + + Table 1 + +9.3. Address Block TLV Types + + +---------------+------+-----------+--------------------------------+ + | Name | Type | Type | Description | + | | | extension | | + +---------------+------+-----------+--------------------------------+ + | INTERVAL_TIME | 0 | 0 | The maximum time before | + | | | | another message of the same | + | | | | type as this message from the | + | | | | same originator and containing | + | | | | this address should be | + | | | | received | + | Unassigned | 0 | 1-223 | Expert Review | + | | | 224-255 | Experimental Use | + | VALIDITY_TIME | 1 | 0 | The time from receipt of the | + | | | | address during which the | + | | | | information regarding this | + | | | | address is to be considered | + | | | | valid | + | Unassigned | 0 | 1-223 | Expert Review | + | | | 224-255 | Experimental Use | + +---------------+------+-----------+--------------------------------+ + + Table 2 + + + +Clausen & Dearlove Standards Track [Page 12] + +RFC 5497 Time TLV March 2009 + + +10. Security Considerations + + This document specifies how to add data structures (TLVs) that + provide timing information to packets and messages specified using + [RFC5444]. In particular, information validity durations and + reporting intervals may be added. + + The general security threats that apply are those general to + [RFC5444] and described therein, problems of integrity and + confidentiality. With regard to the former, modification of a Time + TLV can cause information to have an invalid validity time, or + expected interval time. This may cause incorrect protocol + performance. Modification or addition of timed information can add + to a protocol's workload (especially if a short validity time is + specified) and storage requirements (especially if a long validity + time is specified). + + To counter these threats, the security suggestions in [RFC5444], for + the use of authentication and encryption, are appropriate. + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, + "Generalized Mobile Ad Hoc Network (MANET) Packet/Message + Format", RFC 5444, February 2009. + +11.2. Informative References + + [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State + Routing Protocol", RFC 3626, October 2003. + + + + + + + + + + + + + + + + +Clausen & Dearlove Standards Track [Page 13] + +RFC 5497 Time TLV March 2009 + + +Appendix A. Acknowledgements + + The authors would like to thank Brian Adamson and Justin Dean (both + NRL) and Ian Chakeres (Motorola) for their contributions, and Alan + Cullen (BAE Systems) and Jari Arkko (Ericsson, Finland) for their + careful reviews of this specification. + +Authors' Addresses + + Thomas Heide Clausen + LIX, Ecole Polytechnique, France + + Phone: +33 6 6058 9349 + EMail: T.Clausen@computer.org + URI: http://www.ThomasClausen.org/ + + + Christopher Dearlove + BAE Systems Advanced Technology Centre + + Phone: +44 1245 242194 + EMail: chris.dearlove@baesystems.com + URI: http://www.baesystems.com/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Clausen & Dearlove Standards Track [Page 14] + |