Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3626

Optimized Link State Routing Protocol (OLSR)

Pages: 75
Experimental
Errata
Part 3 of 3 – Pages 51 to 75
First   Prev   None

Top   ToC   RFC3626 - Page 51   prevText

12. Non OLSR Interfaces

A node MAY be equipped with multiple interfaces, some of which do not participate in the OLSR MANET. These non OLSR interfaces may be point to point connections to other singular hosts or may connect to separate networks. In order to provide connectivity from the OLSR MANET interface(s) to these non OLSR interface(s), a node SHOULD be able to inject external route information to the OLSR MANET. Injecting routing information from the OLSR MANET to non OLSR interfaces is outside the scope of this specification. It should be clear, however, that the routing information for the OLSR MANET can be extracted from the topology table (see section 4.4) or directly from the routing table of OLSR, and SHOULD be injected onto the non OLSR interfaces following whatever mechanism (routing protocol, static configuration etc.) is provided on these interfaces. An example of such a situation could be where a node is equipped with a fixed network (e.g., an Ethernet) connecting to a larger network as well as a wireless network interface running OLSR. Notice that this is a different case from that of "multiple interfaces", where all the interfaces are participating in the MANET through running the OLSR protocol. In order to provide this capability of injecting external routing information into an OLSR MANET, a node with such non-MANET interfaces periodically issues a Host and Network Association (HNA) message, containing sufficient information for the recipients to construct an appropriate routing table.
Top   ToC   RFC3626 - Page 52

12.1. HNA Message Format

The proposed format of an HNA-message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Netmask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Netmask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is sent as the data part of the general packet format with the "Message Type" set to HNA_MESSAGE, the TTL field set to 255 and Vtime set accordingly to the value of HNA_HOLD_TIME, as specified in section 18.3. Network Address The network address of the associated network Netmask The netmask, corresponding to the network address immediately above.

12.2. Host and Network Association Information Base

Each node maintains information concerning which nodes may act as "gateways" to associated hosts and networks by recording "association tuples" (A_gateway_addr, A_network_addr, A_netmask, A_time), where A_gateway_addr is the address of an OLSR interface of the gateway, A_network_addr and A_netmask specify the network address and netmask of a network, reachable through this gateway, and A_time specifies the time at which this tuple expires and hence *MUST* be removed. The set of all association tuples in a node is called the "association set". It should be noticed, that the HNA-message can be considered as a "generalized version" of the TC-message: the originator of both the HNA- and TC-messages announce "reachability" to some other host(s).
Top   ToC   RFC3626 - Page 53
   In the TC-message, no netmask is required, since all reachability is
   announced on a per-host basis.  In HNA-messages, announcing
   reachability to an address sequence through a network- and netmask
   address is typically preferred over announcing reachability to
   individual host addresses.

   An important difference between TC- and HNA-messages is, that a TC
   message may have a canceling effect on previous information (if the
   ANSN is incremented), whereas information in HNA-messages is removed
   only upon expiration.

12.3. HNA Message Generation

A node with associated hosts and/or networks SHOULD periodically generate a Host and Network Association (HNA) message, containing pairs of (network address, netmask) corresponding to the connected hosts and networks. HNA-messages SHOULD be transmitted periodically every HNA_INTERVAL. The Vtime is set accordingly to the value of HNA_HOLD_TIME, as specified in section 18.3. A node without any associated hosts and/or networks SHOULD NOT generate HNA-messages.

12.4. HNA Message Forwarding

Upon receiving a HNA message, and thus following the rules of section 3, in this version of the specification, the message MUST be forwarded according to section 3.4.

12.5. HNA Message Processing

In this section, the term "originator address" is used to designate the main address on the OLSR MANET of the node which originally issued the HNA-message. Upon processing a HNA-message, the "validity time" MUST be computed from the Vtime field of the message header (see section 3.3.2). The association base SHOULD then be updated as follows: 1 If the sender interface (NB: not originator) of this message is not in the symmetric 1-hop neighborhood of this node, the message MUST be discarded. 2 Otherwise, for each (network address, netmask) pair in the message:
Top   ToC   RFC3626 - Page 54
        2.1  if an entry in the association set already exists, where:

                  A_gateway_addr == originator address

                  A_network_addr == network address

                  A_netmask      == netmask

             then the holding time for that tuple MUST be set to:

                  A_time         =  current time + validity time


        2.2  otherwise, a new tuple MUST be recorded with:

                  A_gateway_addr =  originator address

                  A_network_addr =  network address

                  A_netmask      =  netmask

                  A_time         =  current time + validity time

12.6. Routing Table Calculation

In addition to the routing table computation as described in section 10, the host and network association set MUST be added as follows: For each tuple in the association set, 1 If there is no entry in the routing table with: R_dest_addr == A_network_addr/A_netmask then a new routing entry is created. 2 If a new routing entry was created at the previous step, or else if there existed one with: R_dest_addr == A_network_addr/A_netmask R_dist > dist to A_gateway_addr of current association set tuple, then the routing entry is modified as follows: R_dest_addr = A_network_addr/A_netmask
Top   ToC   RFC3626 - Page 55
               R_next_addr     =  the next hop on the path
                                  from the node to A_gateway_addr

               R_dist          =  dist to A_gateway_addr

               R_next_addr and R_iface_addr MUST be set to the same
               values as the tuple from the routing set with R_dest_addr
               == A_gateway_addr.

12.7. Interoperability Considerations

Nodes, which do not implement support for non OLSR interfaces, can coexist in a network with nodes which do implement support for non OLSR interfaces: the generic packet format and message forwarding (section 3) ensures that HNA messages are correctly forwarded by all nodes. Nodes which implement support for non OLSR interfaces may thus transmit and process HNA messages according to this section. Nodes, which do not implement support for non OLSR interfaces can not take advantage of the functionality specified in this section, however they will forward HNA messages correctly, as specified in section 3.

13. Link Layer Notification

OLSR is designed not to impose or expect any specific information from the link layer. However, if information from the link-layer describing link breakage is available, a node MAY use this as described in this section. If link layer information describing connectivity to neighboring nodes is available (i.e., loss of connectivity such as through absence of a link layer acknowledgment), this information is used in addition to the information from the HELLO-messages to maintain the neighbor information base and the MPR selector set. Thus, upon receiving a link-layer notification that the link between a node and a neighbor interface is broken, the following actions are taken with respect to link sensing: Each link tuple in the local link set SHOULD, in addition to what is described in section 4.2, include a L_LOST_LINK_time field. L_LOST_LINK_time is a timer for declaring a link as lost when an established link becomes pending. (Notice, that this is a subset of what is recommended in section 14, thus link hysteresis and link layer notifications can coexist).
Top   ToC   RFC3626 - Page 56
   HELLO message generation should consider those new fields as follows:

     1    if L_LOST_LINK_time is not expired, the link is advertised
          with a link type of LOST_LINK.  In addition, it is not
          considered as a symmetric link in the updates of the
          associated neighbor tuple (see section 8.1).

     2    if the link to a neighboring symmetric or asymmetric interface
          is broken, the corresponding link tuple is modified:
          L_LOST_LINK_time and L_time are set to current time +
          NEIGHB_HOLD_TIME.

     3    this is considered as a link loss and the appropriate
          processing described in section 8.5 should be
          performed.

13.1. Interoperability Considerations

Link layer notifications provide, for a node, an additional criterion by which a node may determine if a link to a neighbor node is lost. Once a link is detected as lost, it is advertised, in accordance with the provisions described in the previous sections of this specification.

14. Link Hysteresis

Established links should be as reliable as possible to avoid data packet loss. This implies that link sensing should be robust against bursty loss or transient connectivity between nodes. Hence, to enhance the robustness of the link sensing mechanism, the following implementation recommendations SHOULD be considered.

14.1. Local Link Set

Each link tuple in the local link set SHOULD, in addition to what is described in section 4.2, include a L_link_pending field, a L_link_quality field, and a L_LOST_LINK_time field. L_link_pending is a boolean value specifying if the link is considered pending (i.e., the link is not considered established). L_link_quality is a dimensionless number between 0 and 1 describing the quality of the link. L_LOST_LINK_time is a timer for declaring a link as lost when an established link becomes pending.
Top   ToC   RFC3626 - Page 57

14.2. Hello Message Generation

HELLO message generation should consider those new fields as follows: 1 if L_LOST_LINK_time is not expired, the link is advertised with a link type of LOST_LINK. 2 otherwise, if L_LOST_LINK_time is expired and L_link_pending is set to "true", the link SHOULD NOT be advertised at all; 3 otherwise, if L_LOST_LINK_time is expired and L_link_pending is set to "false", the link is advertised as described previously in section 6. A node considers that it has a symmetric link for each link tuple where: 1 L_LOST_LINK_time is expired, AND 2 L_link_pending is "false", AND 3 L_SYM_time is not expired. This definition for "symmetric link" SHOULD be used in updating the associated neighbor tuple (see section 8.1) for computing the N_status of a neighbor node. This definition SHOULD thereby also be used as basis for the symmetric neighborhood when computing the MPR set, as well as for "the symmetric neighbors" in the first steps of the routing table calculation. Apart from the above, what has been described previously does not interfere with the advanced link sensing fields in the link tuples. The L_link_quality, L_link_pending and L_LOST_LINK_time fields are exclusively updated according to the present section. This section does not modify the function of any other fields in the link tuples.

14.3. Hysteresis Strategy

The link between a node and some of its neighbor interfaces might be "bad", i.e., from time to time let HELLOs pass through only to fade out immediately after. In this case, the neighbor information base would contain a bad link for at least "validity time". The following hysteresis strategy SHOULD be adopted to counter this situation. For each neighbor interface NI heard by interface I, the L_link_quality field of the corresponding Link Tuple determines the establishment of the link. The value of L_link_quality is compared to two thresholds HYST_THRESHOLD_HIGH, HYST_THRESHOLD_LOW, fixed
Top   ToC   RFC3626 - Page 58
   between 0 and 1 and such that HYST_THRESHOLD_HIGH >=
   HYST_THRESHOLD_LOW.

   The L_link_pending field is set according to the following:

     1    if L_link_quality > HYST_THRESHOLD_HIGH:

               L_link_pending   = false

               L_LOST_LINK_time = current time - 1 (expired)

     2    otherwise, if L_link_quality < HYST_THRESHOLD_LOW:

               L_link_pending   = true

               L_LOST_LINK_time = min (L_time, current time +
               NEIGHB_HOLD_TIME)

               (the link is then considered as lost according to section
               8.5 and this may produce a neighbor loss).

     3    otherwise, if HYST_THRESHOLD_LOW <= L_link_quality
                                           <= HYST_THRESHOLD_HIGH:

               L_link_pending and L_LOST_LINK_time remain unchanged.

   The condition for considering a link established is thus stricter
   than the condition for dropping a link.  Notice thus, that a link can
   be dropped based on either timer expiration (as described in section
   7) or on L_link_quality dropping below HYST_THRESHOLD_LOW.

   Also notice, that even if a link is not considered as established by
   the link hysteresis, the link tuples are still updated for each
   received HELLO message (as described in section 7).  Specifically,
   this implies that, regardless of whether or not the link hysteresis
   considers a link as "established", tuples in the link set do not
   expire except as determined by the L_time field of the link tuples.

   As a basic implementation requirement, an estimation of the link
   quality must be maintained and stored in the L_link_quality field.
   If some measure of the signal/noise level on a received message is
   available (e.g., as a link layer notification), then it can be used
   as estimation after normalization.

   If no signal/noise information or other link quality information is
   available from the link layer, an algorithm such as the following can
   be utilized (it is an exponentially smoothed moving average of the
   transmission success rate).  The algorithm is parameterized by a
Top   ToC   RFC3626 - Page 59
   scaling parameter HYST_SCALING which is a number fixed between 0 and
   1.  For each neighbor interface NI heard by interface I, the first
   time NI is heard by I, L_link_quality is set to HYST_SCALING
   (L_link_pending is set to true and L_LOST_LINK_time to current time -
   1).

   A tuple is updated according to two rules.  Every time an OLSR packet
   emitted by NI is received by I, the stability rule is applied:

          L_link_quality = (1-HYST_SCALING)*L_link_quality
                           + HYST_SCALING.

     When an OLSR packet emitted by NI is lost by I, the instability
     rule is applied:

          L_link_quality = (1-HYST_SCALING)*L_link_quality.

   The loss of OLSR packet is detected by tracking the missing Packet
   Sequence Numbers on a per interface basis and by "long period of
   silence" from a node.  A "long period of silence may be detected
   thus: if no OLSR packet has been received on interface I from
   interface NI during HELLO emission interval of interface NI (computed
   from the Htime field in the last HELLO message received from NI), a
   loss of an OLSR packet is detected.

14.4. Interoperability Considerations

Link hysteresis determines, for a node, the criteria at which a link to a neighbor node is accepted or rejected. Nodes in a network may have different criteria, according to the nature of the media over which they are communicating. Once a link is accepted, it is advertised, in accordance with the provisions described in the previous sections of this specification.

15. Redundant Topology Information

In order to provide redundancy to topology information base, the advertised link set of a node MAY contain links to neighbor nodes which are not in MPR selector set of the node. The advertised link set MAY contain links to the whole neighbor set of the node. The minimal set of links that any node MUST advertise in its TC messages is the links to its MPR selectors. The advertised link set can be built according to the following rule based on a local parameter called TC_REDUNDANCY parameter.
Top   ToC   RFC3626 - Page 60

15.1. TC_REDUNDANCY Parameter

The parameter TC_REDUNDANCY specifies, for the local node, the amount of information that MAY be included in the TC messages. The parameter SHOULD be interpreted as follows: - if the TC_REDUNDANCY parameter of the node is 0, then the advertised link set of the node is limited to the MPR selector set (as described in section 8.3), - if the TC_REDUNDANCY parameter of the node is 1, then the advertised link set of the node is the union of its MPR set and its MPR selector set, - if the TC_REDUNDANCY parameter of the node is 2, then the advertised link set of the node is the full neighbor link set. A node with willingness equal to WILL_NEVER SHOULD have TC_REDUNDANCY also equal to zero.

15.2. Interoperability Considerations

A TC message is sent by a node in the network to declare a set of links, called advertised link set, which MUST include at least the links to all nodes of its MPR Selector set, i.e., the neighbors which have selected the sender node as a MPR. This is sufficient information to ensure that routes can be computed in accordance with section 10. The provisions in this section specifies how additional information may be declared, as specified through a TC_REDUNDANCY parameter. TC_REDUNDANCY = 0 implies that the information declared corresponds exactly to the MPR Selector set, identical to section 9. Other values of TC_REDUNDANCY specifies additional information to be declared, i.e., the contents of the MPR Selector set is always declared. Thus, nodes with different values of TC_REDUNDANCY may coexist in a network: control messages are carried by all nodes in accordance with section 3, and all nodes will receive at least the link-state information required to construct routes as described in section 10.

16. MPR Redundancy

MPR redundancy specifies the ability for a node to select redundant MPRs. Section 4.5 specifies that a node should select its MPR set to be as small as possible, in order to reduce protocol overhead. The criteria for selecting MPRs is, that all strict 2-hop nodes must be reachable through, at least, one MPR node. Redundancy of the MPR set
Top   ToC   RFC3626 - Page 61
   affects the overhead through affecting the amount of links being
   advertised, the amount of nodes advertising links and the efficiency
   of the MPR flooding mechanism.  On the other hand, redundancy in the
   MPR set ensures that reachability for a node is advertised by more
   nodes, thus additional links are diffused to the network.

   While, in general, a minimal MPR set provides the least overhead,
   there are situations in which overhead can be traded off for other
   benefits.  For example, a node may decide to increase its MPR
   coverage if it observes many changes in its neighbor information base
   caused by mobility, while otherwise keeping a low MPR coverage.

16.1. MPR_COVERAGE Parameter

The MPR coverage is defined by a single local parameter, MPR_COVERAGE, specifying by how many MPR nodes any strict 2-hop node should be covered. MPR_COVERAGE=1 specifies that the overhead of the protocol is kept at a minimum and causes the MPR selection to operate as described in section 8.3.1. MPR_COVERAGE=m ensures that, if possible, a node selects its MPR set such that all strict 2-hop nodes for an interface are reachable through at least m MPR nodes on that interface. MPR_COVERAGE can assume any integer value > 0. The heuristic MUST be applied per interface, I. The MPR set for a node is the union of the MPR sets found for each interface. Notice that MPR_COVERAGE can be tuned locally without affecting the consistency of the protocol. For example, nodes in a network may operate with different values of MPR_COVERAGE.

16.2. MPR Computation

Using MPR coverage, the MPR selection heuristics is extended from that described in the section 8.3.1 by one definition: Poorly covered node: A poorly covered node is a node in N2 which is covered by less than MPR_COVERAGE nodes in N. The proposed heuristic for selecting MPRs is then as follows: 1 Start with an MPR set made of all members of N with willingness equal to WILL_ALWAYS 2 Calculate D(y), where y is a member of N, for all nodes in N.
Top   ToC   RFC3626 - Page 62
     3    Select as MPRs those nodes in N which cover the poorly covered
          nodes in N2.  The nodes are then removed from N2 for the rest
          of the computation.

     4    While there exist nodes in N2 which are not covered by at
          least MPR_COVERAGE nodes in the MPR set:

          4.1  For each node in N, calculate the reachability, i.e.,
               the number of nodes in N2 which are not yet covered
               by at least MPR_COVERAGE nodes in the MPR set, and
               which are reachable through this 1-hop neighbor;

          4.2  Select as a MPR the node with highest willingness among
               the nodes in N with non-zero reachability.  In case of
               multiple choice select the node which provides
               reachability to the maximum number of nodes in N2.  In
               case of multiple nodes providing the same amount of
               reachability, select the node as MPR whose D(y) is
               greater.  Remove the nodes from N2 which are now covered
               by MPR_COVERAGE nodes in the MPR set.

     5    A node's MPR set is generated from the union of the MPR sets
          for each interface.  As an optimization, process each node, y,
          in the MPR set in increasing order of N_willingness.  If all
          nodes in N2 are still covered by at least MPR_COVERAGE nodes
          in the MPR set excluding node y, and if N_willingness of node
          y is smaller than WILL_ALWAYS, then node y MAY be removed from
          the MPR set.

   When the MPR set has been computed, all the corresponding main
   addresses are stored in the MPR Set.

16.3. Interoperability Considerations

The MPR set of a node MUST, according to section 8.3, be calculated by a node in such a way that it, through the neighbors in the MPR- set, can reach all symmetric strict 2-hop neighbors. This is achieved by the heuristics in this section, for all values of MPR_COVERAGE > 0. MPR_COVERAGE is a local parameter for each node. Setting this parameter affects only the amount of redundancy in part of the network. Notice that for MPR_COVERAGE=1, the heuristics in this section is identical to the heuristics specified in the section 8.3.1.
Top   ToC   RFC3626 - Page 63
   Nodes with different values of MPR_COVERAGE may coexist in a network:
   control messages are carried by all nodes in accordance with section
   3, and all nodes will receive at least the link-state information
   required to construct routes as described in sections 9 and 10.

17. IPv6 Considerations

All the operations and parameters described in this document used by OLSR for IP version 4 are the same as those used by OLSR for IP version 6. To operate with IP version 6, the only required change is to replace the IPv4 addresses with IPv6 address. The minimum packet and message sizes (under which there is rejection) should be adjusted accordingly, considering the greater size of IPv6 addresses.

18. Proposed Values for Constants

This section list the values for the constants used in the description of the protocol.

18.1. Setting emission intervals and holding times

The proposed constant for C is the following: C = 1/16 seconds (equal to 0.0625 seconds) C is a scaling factor for the "validity time" calculation ("Vtime" and "Htime" fields in message headers, see section 18.3). The "validity time" advertisement is designed such that nodes in a network may have different and individually tuneable emission intervals, while still interoperate fully. For protocol functioning and interoperability to work: - the advertised holding time MUST always be greater than the refresh interval of the advertised information. Moreover, it is recommended that the relation between the interval (from section 18.2), and the hold time is kept as specified in section 18.3, to allow for reasonable packet loss. - the constant C SHOULD be set to the suggested value. In order to achieve interoperability, C MUST be the same on all nodes. - the emission intervals (section 18.2), along with the advertised holding times (subject to the above constraints) MAY be selected on a per node basis. Note that the timer resolution of a given implementation might not be sufficient to wake up the system on precise refresh times or on precise expire times: the implementation SHOULD round up the
Top   ToC   RFC3626 - Page 64
   'validity time' ("Vtime" and "Htime" of packets) to compensate for
   coarser timer resolution, at least in the case where "validity time"
   could be shorter than the sum of emission interval and maximum
   expected timer error.

18.2. Emission Intervals

HELLO_INTERVAL = 2 seconds REFRESH_INTERVAL = 2 seconds TC_INTERVAL = 5 seconds MID_INTERVAL = TC_INTERVAL HNA_INTERVAL = TC_INTERVAL

18.3. Holding Time

NEIGHB_HOLD_TIME = 3 x REFRESH_INTERVAL TOP_HOLD_TIME = 3 x TC_INTERVAL DUP_HOLD_TIME = 30 seconds MID_HOLD_TIME = 3 x MID_INTERVAL HNA_HOLD_TIME = 3 x HNA_INTERVAL The Vtime in the message header (see section 3.3.2), and the Htime in the HELLO message (see section 6.1) are the fields which hold information about the above values in mantissa and exponent format (rounded up). In other words: value = C*(1+a/16)*2^b [in seconds] where a is the integer represented by the four highest bits of the field and b the integer represented by the four lowest bits of the field. Notice, that for the previous proposed value of C, (1/16 seconds), the values, in seconds, expressed by the formula above can be stored, without loss of precision, in binary fixed point or floating point numbers with at least 8 bits of fractional part. This corresponds with NTP time-stamps and single precision IEEE Standard 754 floating point numbers.
Top   ToC   RFC3626 - Page 65
   Given one of the above holding times, a way of computing the
   mantissa/exponent representation of a number T (of seconds) is the
   following:

     -    find the largest integer 'b' such that: T/C >= 2^b

     -    compute the expression 16*(T/(C*(2^b))-1), which may not be a
          integer, and round it up.  This results in the value for 'a'

     -    if 'a' is equal to 16: increment 'b' by one, and set 'a' to 0

     -    now, 'a' and 'b' should be integers between 0 and 15, and the
          field will be a byte holding the value a*16+b

   For instance, for values of 2 seconds, 6 seconds, 15 seconds, and 30
   seconds respectively, a and b would be: (a=0,b=5), (a=8,b=6),
   (a=14,b=7) and (a=14,b=8) respectively.

18.4. Message Types

HELLO_MESSAGE = 1 TC_MESSAGE = 2 MID_MESSAGE = 3 HNA_MESSAGE = 4

18.5. Link Types

UNSPEC_LINK = 0 ASYM_LINK = 1 SYM_LINK = 2 LOST_LINK = 3

18.6. Neighbor Types

NOT_NEIGH = 0 SYM_NEIGH = 1 MPR_NEIGH = 2
Top   ToC   RFC3626 - Page 66

18.7. Link Hysteresis

HYST_THRESHOLD_HIGH = 0.8 HYST_THRESHOLD_LOW = 0.3 HYST_SCALING = 0.5

18.8. Willingness

WILL_NEVER = 0 WILL_LOW = 1 WILL_DEFAULT = 3 WILL_HIGH = 6 WILL_ALWAYS = 7 The willingness of a node may be set to any integer value from 0 to 7, and specifies how willing a node is to be forwarding traffic on behalf of other nodes. Nodes will, by default, have a willingness WILL_DEFAULT. WILL_NEVER indicates a node which does not wish to carry traffic for other nodes, for example due to resource constraints (like being low on battery). WILL_ALWAYS indicates that a node always should be selected to carry traffic on behalf of other nodes, for example due to resource abundance (like permanent power supply, high capacity interfaces to other nodes). A node may dynamically change its willingness as its conditions change. One possible application would, for example, be for a node, connected to a permanent power supply and with fully charged batteries, to advertise a willingness of WILL_ALWAYS. Upon being disconnected from the permanent power supply (e.g., a PDA being taken out of its charging cradle), a willingness of WILL_DEFAULT is advertised. As battery capacity is drained, the willingness would be further reduced. First to the intermediate value between WILL_DEFAULT and WILL_LOW, then to WILL_LOW and finally to WILL_NEVER, when the battery capacity of the node does no longer support carrying foreign traffic.
Top   ToC   RFC3626 - Page 67

18.9. Misc. Constants

TC_REDUNDANCY = 0 MPR COVERAGE = 1 MAXJITTER = HELLO_INTERVAL / 4

19. Sequence Numbers

Sequence numbers are used in OLSR with the purpose of discarding "old" information, i.e., messages received out of order. However with a limited number of bits for representing sequence numbers, wrap-around (that the sequence number is incremented from the maximum possible value to zero) will occur. To prevent this from interfering with the operation of the protocol, the following MUST be observed. The term MAXVALUE designates in the following the largest possible value for a sequence number. The sequence number S1 is said to be "greater than" the sequence number S2 if: S1 > S2 AND S1 - S2 <= MAXVALUE/2 OR S2 > S1 AND S2 - S1 > MAXVALUE/2 Thus when comparing two messages, it is possible - even in the presence of wrap-around - to determine which message contains the most recent information.

20. Security Considerations

Currently, OLSR does not specify any special security measures. As a proactive routing protocol, OLSR makes a target for various attacks. The various possible vulnerabilities are discussed in this section.

20.1. Confidentiality

Being a proactive protocol, OLSR periodically diffuses topological information. Hence, if used in an unprotected wireless network, the network topology is revealed to anyone who listens to OLSR control messages.
Top   ToC   RFC3626 - Page 68
   In situations where the confidentiality of the network topology is of
   importance, regular cryptographic techniques such as exchange of OLSR
   control traffic messages encrypted by PGP [9] or encrypted by some
   shared secret key can be applied to ensure that control traffic can
   be read and interpreted by only those authorized to do so.

20.2. Integrity

In OLSR, each node is injecting topological information into the network through transmitting HELLO messages and, for some nodes, TC messages. If some nodes for some reason, malicious or malfunction, inject invalid control traffic, network integrity may be compromised. Therefore, message authentication is recommended. Different such situations may occur, for instance: 1 a node generates TC (or HNA) messages, advertising links to non-neighbor nodes: 2 a node generates TC (or HNA) messages, pretending to be another node, 3 a node generates HELLO messages, advertising non-neighbor nodes, 4 a node generates HELLO messages, pretending to be another node. 5 a node forwards altered control messages, 6 a node does not broadcast control messages, 7 a node does not select multipoint relays correctly. 8 a node forwards broadcast control messages unaltered, but does not forward unicast data traffic; 9 a node "replays" previously recorded control traffic from another node. Authentication of the originator node for control messages (for situation 2, 4 and 5) and on the individual links announced in the control messages (for situation 1 and 3) may be used as a countermeasure. However to prevent nodes from repeating old (and correctly authenticated) information (situation 9) temporal information is required, allowing a node to positively identify such delayed messages.
Top   ToC   RFC3626 - Page 69
   In general, digital signatures and other required security
   information may be transmitted as a separate OLSR message type,
   thereby allowing that "secured" and "unsecured" nodes can coexist in
   the same network, if desired.

   Specifically, the authenticity of entire OLSR control messages can be
   established through employing IPsec authentication headers, whereas
   authenticity of individual links (situation 1 and 3) require
   additional security information to be distributed.

   An important consideration is, that all control messages in OLSR are
   transmitted either to all nodes in the neighborhood (HELLO messages)
   or broadcast to all nodes in the network (e.g., TC messages).

   For example, a control message in OLSR is always a point-to-
   multipoint transmission.  It is therefore important that the
   authentication mechanism employed permits that any receiving node can
   validate the authenticity of a message.  As an analogy, given a block
   of text, signed by a PGP private key, then anyone with the
   corresponding public key can verify the authenticity of the text.

20.3. Interaction with External Routing Domains

OLSR does, through the HNA messages specified in section 12, provide a basic mechanism for injecting external routing information to the OLSR domain. Section 12 also specifies that routing information can be extracted from the topology table or the routing table of OLSR and, potentially, injected into an external domain if the routing protocol governing that domain permits. Other than as described in the section 20.2, when operating nodes, connecting OLSR to an external routing domain, care MUST be taken not to allow potentially insecure and un-trustworthy information to be injected from the OLSR domain to external routing domains. Care MUST be taken to validate the correctness of information prior to it being injected as to avoid polluting routing tables with invalid information. A recommended way of extending connectivity from an existing routing domain to an OLSR routed MANET is to assign an IP prefix (under the authority of the nodes/gateways connecting the MANET with the exiting routing domain) exclusively to the OLSR MANET area, and to configure the gateways statically to advertise routes to that IP sequence to nodes in the existing routing domain.
Top   ToC   RFC3626 - Page 70

20.4. Node Identity

OLSR does not make any assumption about node addresses, other than that each node is assumed to have a unique IP address.

21. Flow and congestion control

Due to its proactive nature, the OLSR protocol has a natural control over the flow of its control traffic. Nodes transmits control message at predetermined rates fixed by predefined refresh intervals. Furthermore the MPR optimization greatly saves on control overhead, and this is done on two sides. First, the packets that advertise the topology are much shorter since only MPR selectors may be advertised. Second, the cost of flooding this information is greatly reduced since only MPR nodes forward the broadcast packets. In dense networks, the reduction of control traffic can be of several orders of magnitude compared to routing protocols using classical flooding (such as OSPF) [10]. This feature naturally provides more bandwidth for useful data traffic and pushes further the frontier of congestion. Since the control traffic is continuous and periodic, it keeps more stable the quality of the links used in routing, where reactive protocols, with bursty floodings for route discoveries and repairs, may damage the link qualities for short times by causing numerous collisions on those links, possibly provoking route repair cascades. However, in certain OLSR options, some control messages may be intentionally sent in advance of their deadline(TC or Hello messages) in order to increase the reactiveness of the protocol against topology changes. This may cause a small, temporary and local increase of control traffic.

22. IANA Considerations

OLSR defines a "Message Type" field for control messages. A new registry has been created for the values for this Message Type field, and the following values assigned: Message Type Value -------------------- ----- HELLO_MESSAGE 1 TC_MESSAGE 2 MID_MESSAGE 3 HNA_MESSAGE 4 Future values in the range 5-127 of the Message Type can be allocated using standards action [7]. Additionally, values in the range 128-255 are reserved for private/local use.
Top   ToC   RFC3626 - Page 71

23. Acknowledgments

The authors would like to thank Joseph Macker <macker@itd.nrl.navy.mil> and his team, including Justin Dean <jdean@itd.nrl.navy.mil>, for their valuable suggestions on the advanced neighbor sensing mechanism and other various aspects of the protocol, including careful review of the protocol specification. The authors would also like to thank Christopher Dearlove <chris.dearlove@baesystems.com> for valuable input on the MPR selection heuristics and for careful reviews of the protocol specification.

24. Contributors

During the development of this specification, the following list of people contributed. The contributors are listed alphabetically. Cedric Adjih Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France Phone: +33 1 3963 5215 EMail: Cedric.Adjih@inria.fr Thomas Heide Clausen Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France Phone: +33 1 3963 5133 EMail: T.Clausen@computer.org Philippe Jacquet Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France Phone: +33 1 3963 5263 EMail: Philippe.Jacquet@inria.fr
Top   ToC   RFC3626 - Page 72
   Anis Laouiti
   Project HIPERCOM
   INRIA Rocquencourt, BP 105
   78153 Le Chesnay Cedex, France

   Phone: +33 1 3963 5088
   EMail: Anis.Laouiti@inria.fr


   Pascale Minet
   Project HIPERCOM
   INRIA Rocquencourt, BP 105
   78153 Le Chesnay Cedex, France

   Phone: +33 1 3963 5233
   EMail: Pascale.Minet@inria.fr


   Paul Muhlethaler
   Project HIPERCOM
   INRIA Rocquencourt, BP 105
   78153 Le Chesnay Cedex, France

   Phone: +33 1 3963 5278
   EMail: Paul.Muhlethaler@inria.fr


   Amir Qayyum
   Center for Advanced Research in Engineering Pvt. Ltd.
   19 Ataturk Avenue
   Islamabad, Pakistan

   Phone: +92-51-2874115
   EMail: amir@carepvtltd.com


   Laurent Viennot
   Project HIPERCOM
   INRIA Rocquencourt, BP 105
   78153 Le Chesnay Cedex, France

   Phone: +33 1 3963 5225
   EMail: Laurent.Viennot@inria.fr
Top   ToC   RFC3626 - Page 73

25. References

25.1. Normative References

[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [7] T. Clausen, P. Jacquet, A. Laouiti, P. Muhlethaler, A. Qayyum and L. Viennot. Optimized Link State Routing Protocol. IEEE INMIC Pakistan 2001.

25.2. Informative References

[1] P. Jacquet, P. Minet, P. Muhlethaler, N. Rivierre. Increasing reliability in cable free radio LANs: Low level forwarding in HIPERLAN. Wireless Personal Communications, 1996. [2] A. Qayyum, L. Viennot, A. Laouiti. Multipoint relaying: An efficient technique for flooding in mobile wireless networks. 35th Annual Hawaii International Conference on System Sciences (HICSS'2001). [3] ETSI STC-RES10 Committee. Radio equipment and systems: HIPERLAN type 1, functional specifications ETS 300-652, ETSI, June 1996. [4] P. Jacquet and L. Viennot, Overhead in Mobile Ad-hoc Network Protocols, INRIA research report RR-3965, 2000. [6] T. Clausen, G. Hansen, L. Christensen and G. Behrmann. The Optimized Link State Routing Protocol, Evaluation through Experiments and Simulation. IEEE Symposium on "Wireless Personal Mobile Communications", September 2001. [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [9] Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, August 1996. [10] P. Jacquet, A. Laouiti, P. Minet, L. Viennot. Performance analysis of OLSR multipoint relay flooding in two ad hoc wireless network models, INRIA research report RR-4260, 2001.
Top   ToC   RFC3626 - Page 74

26. Authors' Addresses

Thomas Heide Clausen Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France Phone: +33 1 3963 5133 EMail: T.Clausen@computer.org Philippe Jacquet, Project HIPERCOM, INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France Phone: +33 1 3963 5263, EMail: Philippe.Jacquet@inria.fr
Top   ToC   RFC3626 - Page 75

27. Full Copyright Statement

Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.