o Jitter These are detailed in the following sections. Different MANET interfaces (on the same or on different routers) MAY employ different interface parameter values and MAY change their interface parameter values dynamically, subject to the constraints given in this section. A particular case is where all MANET interfaces on all MANET routers within a given MANET employ the same set of interface parameter values. RFC5148]. HELLO_MIN_INTERVAL: The minimum interval between transmission of two successive HELLO messages on this MANET interface. (This minimum interval MAY be modified by jitter, as defined in [RFC5148].) REFRESH_INTERVAL: The maximum interval between advertisements, in a HELLO message on this MANET interface, of each 1-hop neighbor network address and its status. In all intervals of length REFRESH_INTERVAL, a router MUST include each 1-hop neighbor network address and its status in at least one HELLO message on this MANET interface. (This may be in the same or in different HELLO messages.)
REFRESH_INTERVAL thus represents the frequency at which a piece of information, as received in HELLO messages, can be expected to be refreshed. Thus, the REFRESH_INTERVAL is used as a basis for determining when such information expires in receiving routers (see Section 5.3.2). HELLO_INTERVAL represents the frequency of HELLO message emissions. Logically, HELLO_INTERVAL cannot be greater than the REFRESH_INTERVAL; otherwise, information cannot be refreshed in a timely manner. HELLO messages can, however, be sent with a higher frequency. A possible use for sending HELLO messages at such a higher frequency includes sending partial HELLO messages (e.g., accommodating constraints on packet sizes from the underlying medium) refreshing only part of the information in each HELLO message. Another use is for a router to send "empty HELLO messages", advertising its own presence frequently in smaller HELLO messages (e.g., in case HELLO message exchange success rates are used for link quality estimation, or to enable rapid detection by new routers in the neighborhood) in between HELLO messages refreshing neighbor information in other routers. The following constraints apply to these interface parameters: o HELLO_INTERVAL > 0 o HELLO_MIN_INTERVAL >= 0 o HELLO_INTERVAL >= HELLO_MIN_INTERVAL o REFRESH_INTERVAL >= HELLO_INTERVAL o If an INTERVAL_TIME Message TLV as defined in [RFC5497] is included in a HELLO message, then HELLO_INTERVAL MUST be representable as described in [RFC5497]. If REFRESH_INTERVAL > HELLO_INTERVAL, then a router may distribute its neighbor advertisements between HELLO messages in any manner, subject to the constraints above. In the absence of any changes to the local neighborhood, a router will send a HELLO message on a MANET interface after an (possibly jittered) interval of length HELLO_INTERVAL. For a router to employ this protocol in a purely responsive manner on a MANET interface, i.e., for the router to only send HELLO messages on that MANET interface as a response to external events, HELLO_INTERVAL (and hence also REFRESH_INTERVAL) SHOULD be set sufficiently large, i.e., such that a responsive HELLO message is always expected with a shorter period than this value.
If a router has more than one MANET interface, then, even if the router configures different values of HELLO_INTERVAL on each MANET interface, the router SHOULD configure the same value of HELLO_MIN_INTERVAL on all MANET interfaces on which responsive HELLO messages may be sent. (This ensures that changes observed on one MANET interface are reported on other MANET interfaces, so that 1-hop neighbors connected to the latter can maintain up-to-date 2-hop neighborhood information.) RFC5497].
Section 14): HYST_ACCEPT: The link quality threshold at or above which a link becomes usable, if it was not already so. HYST_REJECT: The link quality threshold below which a link becomes unusable, if it was not already so. INITIAL_QUALITY: The initial quality of a newly identified link. INITIAL_PENDING: If true, then a newly identified link is considered pending, and is not usable until the link quality has reached or exceeded the HYST_ACCEPT threshold. The following constraints apply to these interface parameters: o 0 <= HYST_REJECT <= HYST_ACCEPT <= 1 o 0 <= INITIAL_QUALITY <= 1. o If link quality is not updated, then INITIAL_QUALITY >= HYST_ACCEPT. o If INITIAL_QUALITY >= HYST_ACCEPT, then INITIAL_PENDING := false. o If INITIAL_QUALITY < HYST_REJECT, then INITIAL_PENDING := true. RFC5148], is used, then these parameters are as follows: HP_MAXJITTER: Represents the value of MAXJITTER used in [RFC5148] for periodically generated HELLO messages on this MANET interface. HT_MAXJITTER: Represents the value of MAXJITTER used in [RFC5148] for externally triggered HELLO messages on this MANET interface. For constraints on these interface parameters, see [RFC5148].
REFRESH_INTERVAL o If the REFRESH_INTERVAL for a MANET interface increases, then the content of subsequent HELLO messages must be organized such that the specification of the old value of REFRESH_INTERVAL is satisfied for a further period equal to the old value of REFRESH_INTERVAL. o If the REFRESH_INTERVAL for a MANET interface decreases, then it MAY be necessary to reschedule HELLO message generation on that MANET interface, in order for the specification of REFRESH_INTERVAL is satisfied from the time of change. HYST_ACCEPT and HYST_REJECT o If HYST_ACCEPT or HYST_REJECT changes, then the appropriate actions for link quality change, as specified in Section 14.3, MUST be taken. L_HOLD_TIME o If L_HOLD_TIME changes, then the expiry times of all relevant Link Tuples MUST be changed. N_HOLD_TIME o If N_HOLD_TIME changes, then the expiry times of all relevant Lost Neighbor Tuples MUST be changed. HP_MAXJITTER o If HP_MAXJITTER changes, then the periodic HELLO message schedule on this MANET interface MAY be changed. HT_MAXJITTER o If HT_MAXJITTER changes, then externally triggered HELLO messages on this MANET interface MAY be rescheduled. RFC5497].
network addresses MAY be specific to that interface, or MAY in some circumstances be used by more than one interface as specified below. The Local Information Base is not modified by signaling. If a router's interface configuration changes, then the Local Information Base MUST reflect these changes. This MAY also result in signaling to advertise these changes. It is not necessary to include all addresses of an interface in the Local Information Base, and hence in HELLO messages. However, any address that may be the source address of an IP datagram sent from that interface MUST be included (and at least one address MUST be included). A protocol using this specification MAY add additional requirements to these, e.g., that any address that may be the destination address of an IP datagram is also included. The addresses assigned to an interface are "owned" by the router, and MUST NOT be used by any other router as an interface address. If an address has a prefix length and represents a range of addresses, this applies to all addresses in that range (i.e., such ranges MUST NOT overlap). The addresses assigned to different interfaces on the same router MUST be distinct (hence, network address ranges MUST NOT overlap) except that: o The same address MAY be assigned to any number of non-MANET interfaces as well as to one (or more if the following condition also applies) MANET interface. o The same address MAY be assigned to two (or more if each pair satisfies this condition) MANET interfaces if those two MANET interfaces cannot communicate to, from, or one to and one from any other MANET interface of another router.
I_manet is a boolean flag, describing if this interface is a MANET interface. Local Interface Tuples are removed from the Local Interface Set only when the routers' interface configuration changes, subject to Section 9, i.e., they are not subject to timer-based expiration.
Section 18.5. The Value PENDING is never used in a HELLO message, it is only used locally by a router, and any Value distinct from LOST, SYMMETRIC, and HEARD may be used. L_status is defined by: 1. If L_pending = true, then L_status := PENDING; 2. otherwise, if L_lost = true, then L_status := LOST;
3. otherwise, if L_SYM_time is not expired, then L_status := SYMMETRIC; 4. otherwise, if L_HEARD_time is not expired, then L_status := HEARD; 5. otherwise, L_status := LOST.
where: N_neighbor_addr_list is an unordered list of the network addresses of a 1-hop neighbor; N_symmetric is a boolean flag, describing if this is a symmetric 1-hop neighbor. Neighbor Tuples are removed from the Neighbor Set only when corresponding Link Tuples expire from the routers' Link Set, i.e., Neighbor Tuples are not directly subject to timer-based expiration. Section 13, then those changes MUST be applied immediately, unless noted otherwise below. A router MAY transmit HELLO messages in response to these changes. Section 9.3 MUST be taken for each network address of this added interface. A HELLO message MAY be sent on all MANET interfaces, it SHOULD be sent on the new interface if it is a
MANET interface. If using scheduled messages, then a message schedule MUST be established on the new MANET interface.
1. Remove any Removed Interface Address Tuple whose IR_local_iface_addr is the added network address. 2. Remove any Neighbor Tuples whose N_neighbor_addr_list contains a network address that overlaps the added network address. 3. Remove any Link Tuples, in any Link Set, for which either: o L_neighbor_iface_addr_list contains any network address in the N_neighbor_addr_list of any removed Neighbor Tuple; OR o L_neighbor_iface_addr_list contains a network address that overlaps the added network address. Apply Section 13.2 but not Section 13.3. 4. Remove any Lost Neighbor Tuples whose NL_neighbor_addr overlaps the added network address. 5. Remove any 2-Hop Tuples whose N2_2hop_addr overlaps the added network address. After adding the network address and making these changes, a HELLO message MAY be sent on all MANET interfaces. These changes, other than to the appropriate I_local_iface_addr_list, are made in order to maintain consistency of the Information Bases. Specifically, these changes remove any record of any use of this network address by routers in the 1-hop neighborhood or in the symmetric 2-hop neighborhood of this router. Section 9.2. 3. Otherwise: 1. Remove the removed address from this I_local_iface_addr_list.
2. If the removed address is not in the I_local_iface_addr_list of any other Local Interface Tuple, then create a Removed Interface Address Tuple with: o IR_local_iface_addr := removed address; o IR_time := current time + I_HOLD_TIME. After removing the network address and making these changes, a HELLO message MAY be sent on all MANET interfaces. RFC5444], which is used with the following considerations: o This protocol specifies one Message Type, the HELLO message. o A HELLO message MAY use any combination of Message Header options specified in [RFC5444]. o HELLO messages MUST NOT be forwarded, i.e., a <msg-hop-limit>, if present, MUST have the value 1. o HELLO messages MAY be included in multi-message packets as specified in [RFC5444]. o Received HELLO messages MUST be parsed in accordance with [RFC5444]. A HELLO message that is not in conformance with [RFC5444] MUST be discarded without being processed. A HELLO message can also be discarded without being processed for other reasons, see Section 12.1. o This protocol specifies three Address Block TLVs. It also uses two Message TLVs defined in [RFC5497]. These five TLV Types are all defined only with Type Extension = 0. TLVs of other types, and of these types but without Type Extension = 0, are ignored by this protocol. All references in this specification to, for example, an Address Block TLV with Type = LINK_STATUS, are to be considered as referring to an Address Block TLV with Type = LINK_STATUS and Type Extension = 0. RFC5497], representing H_HOLD_TIME for the transmitting MANET interface.
The options included in [RFC5497] for representing zero and infinite times MUST NOT be used. A HELLO message transmitted due to a periodic timer SHOULD contain, and otherwise (i.e., transmitted for any other reason, in particular in response to any Information Base changes) MAY contain: o Exactly one INTERVAL_TIME Message TLV as specified in [RFC5497], representing HELLO_INTERVAL for the transmitting MANET interface. The options included in [RFC5497] for representing zero and infinite times MUST NOT be used. A HELLO message MAY contain: o Other Message TLVs. o One or more Address Blocks, each with an associated Address Block TLV Block, which MAY contain other Address Block TLVs. RFC5444]), and included in the Address Blocks in all generated HELLO messages, with the following permitted exception: o If the MANET interface on which the HELLO message is to be sent has a single address with maximum prefix length (i.e., /32 for IPv4, /128 for IPv6), then that address MAY be omitted from being included in any Address Block, provided that this address is included as the sending address of the IP datagram in which the HELLO message is included. All network addresses of the router's interfaces included in any Address Block(s) MUST be associated with an Address Block TLV with Type = LOCAL_IF, as defined in Table 1. +----------+---------+----------------------------------------------+ | Name | Value | Description | | | Length | | +----------+---------+----------------------------------------------+ | LOCAL_IF | 1 octet | Specifies that the network address is | | | | associated with the MANET interface on which | | | | the message was sent (THIS_IF) or another | | | | interface of the sending router (OTHER_IF). | +----------+---------+----------------------------------------------+ Table 1: LOCAL_IF TLV Definition
Address Blocks MAY contain current or recently lost 1-hop neighbors' network addresses, represented as address objects (see [RFC5444]), each of which is associated with one or both Address Block TLVs as described in Table 2. +--------------+---------+------------------------------------------+ | Name | Value | Description | | | Length | | +--------------+---------+------------------------------------------+ | LINK_STATUS | 1 octet | Specifies the status of the link from | | | | the indicated network address and to the | | | | MANET interface over which the HELLO | | | | message is transmitted (LOST, SYMMETRIC, | | | | or HEARD). | | OTHER_NEIGHB | 1 octet | Specifies that the network address is | | | | (SYMMETRIC) or was (LOST) of a MANET | | | | interface of a symmetric 1-hop neighbor | | | | of the router transmitting the HELLO | | | | message. | +--------------+---------+------------------------------------------+ Table 2: LINK_STATUS and OTHER_NEIGHB TLV Definition An Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC or Value = LOST also performs the function of an Address Block TLV with Type = OTHER_NEIGHB and the same Value. Including the latter associated with the same address object is discouraged for efficiency reasons. If an Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC is combined with an Address Block TLV with Type = OTHER_NEIGHB and Value = LOST associated with the same address object, then the latter MUST be ignored and SHOULD NOT be included. See Appendix A. Other network addresses MAY be represented as address objects (see [RFC5444]) and included in Address Blocks, but MUST NOT be associated with any of the Address Block TLVs specified in this specification.
If transmitting periodic HELLO messages, then, following a HELLO message transmission on a MANET interface, another HELLO message MUST be transmitted on the same MANET interface after an interval not greater than HELLO_INTERVAL. Two successive HELLO message transmissions on the same MANET interface MUST be separated by at least HELLO_MIN_INTERVAL, except as noted in Section 11.2.1. RFC5444]), except that: o If the interface on which the HELLO message is to be sent has a single address with maximum prefix length (i.e., /32 for IPv4, /128 for IPv6), then that address MAY be omitted, provided that this address is included as the sending address of the IP datagram in which the HELLO message is included. All such included address objects MUST be associated with an Address Block TLV with Type := LOCAL_IF and Value according to the following: o If the address object represents a network address of the sending MANET interface, then Value := THIS_IF. o Otherwise, Value := OTHER_IF. If such a network address is included in more than one I_local_iface_addr_list, then, for efficiency reasons, it is encouraged that the corresponding address object is associated with only one Value using an Address Block TLV with Type := LOCAL_IF; this MUST be Value := THIS_IF if the address object represents a network address of the sending MANET interface. The following network addresses of current or former 1-hop neighbors MAY be represented as address objects (see [RFC5444]) and included in any HELLO message, respecting the parameter REFRESH_INTERVAL for each association for that MANET interface, and according to the following: o Network addresses of MANET interfaces of 1-hop neighbors from the Link Set of the Interface Information Base for this MANET interface (i.e., from an L_neighbor_iface_addr_list), other than those from Link Tuples with L_status = PENDING.
o Other network addresses of symmetric 1-hop neighbors from the Neighbor Set of this router's Neighbor Information Base (i.e., from an N_neighbor_addr_list). o Network addresses of MANET interfaces of previously symmetric or heard 1-hop neighbors connected on this MANET interface from the Link Set of the Interface Information Base for this MANET interface (i.e., from an L_neighbor_iface_addr_list with L_status = LOST). o Other network addresses of previously symmetric 1-hop neighbors from the Lost Neighbor Set of this router's Neighbor Information Base (i.e., from an NL_neighbor_addr). Each such address object (see [RFC5444]) MUST be associated with one or more appropriate Address Block TLVs. Specifically: 1. For each address object (henceforth linked address) that represents a network address contained in an L_neighbor_iface_addr_list of a Link Tuple in the Link Set for this MANET interface, for which L_status != PENDING, include the linked address with an associated Address Block TLV with: o Type := LINK_STATUS; AND o Value := L_status. 2. For each address object (henceforth neighbor address) that represents a network address contained in an N_neighbor_addr_list in a Neighbor Tuple with N_symmetric = true and that has not already been included with an associated Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC, include the neighbor network address with an associated Address Block TLV with: o Type := OTHER_NEIGHB; AND o Value := SYMMETRIC. 3. For each Lost Neighbor Tuple whose NL_neighbor_addr (henceforth lost address) has not already been represented as an address object and included, include lost address with an associated Address Block TLV with: o Type := OTHER_NEIGHB; AND o Value := LOST.
If any such network addresses have been added to these Information Bases since the last HELLO message was sent on this MANET interface, or if their status (as indicated by these TLVs and the Values they associate with that network address) have changed since that network address was last reported on this MANET interface, then that network address, and the indicated TLVs, SHOULD be included in the HELLO message. If the address object (see [RFC5444]) representing a network address of a 1-hop neighbor is specified with more than one associated Address Block TLV, then these Address Block TLVs MAY be independently included or excluded from each HELLO message. Each such Address Block TLV MUST be included associated with the address object representation of that network address in a HELLO message sent on that MANET interface in every interval of length equal to that MANET interface's parameter REFRESH_INTERVAL. Address Block TLVs associated with the same address object included in the same HELLO message MAY be applied to the same or different copies of that address object. An implementation of this protocol MAY limit the information included in each HELLO message, for example, to accommodate smaller MTU sizes. HELLO messages remain constrained by the above requirements, in particular, that all local interface information MUST be included in all HELLO messages, and that all neighbor information MUST be sent within each interval of length REFRESH_INTERVAL. This neighbor information MAY, however, be sent in the same or in different HELLO messages. RFC5444]. RFC5148]. Internally triggered message generation (such as due to a change in local interfaces) MAY be treated as if externally generated message generation or MAY be not jittered. HELLO messages MUST NOT be forwarded, and thus message forwarding jitter does not apply to HELLO messages.
Each form of jitter described in [RFC5148] requires a parameter MAXJITTER. These interface parameters may be dynamic and are specified by: o For periodic message generation: HP_MAXJITTER. o For externally triggered message generation: HT_MAXJITTER. When HELLO message generation is delayed in order that a HELLO message is not sent within HELLO_MIN_INTERVAL of the previous HELLO message on the same MANET interface, then HELLO_MIN_INTERVAL SHOULD be reduced by jitter, with maximum reduction HP_MAXJITTER, as described in [RFC5148]. In this case, HP_MAXJITTER MUST NOT be greater than HELLO_MIN_INTERVAL.