draft-ietf-manet-nhdp-olsrv2-tlv-extension-02.txt   draft-ietf-manet-nhdp-olsrv2-tlv-extension-03.txt 
Mobile Ad hoc Networking (MANET) C. Dearlove Mobile Ad hoc Networking (MANET) C. Dearlove
Internet-Draft BAE Systems ATC Internet-Draft BAE Systems ATC
Updates: RFC6130, OLSRv2 T. Clausen Updates: RFC6130, OLSRv2 T. Clausen
(if approved) LIX, Ecole Polytechnique (if approved) LIX, Ecole Polytechnique
Intended status: Standards Track February 13, 2014 Intended status: Standards Track February 24, 2014
Expires: August 17, 2014 Expires: August 28, 2014
Optimized Link State Routing Protocol version 2 (OLSRv2) and MANET Optimized Link State Routing Protocol version 2 (OLSRv2) and MANET
Neighborhood Discovery Protocol (NHDP) Extension TLVs Neighborhood Discovery Protocol (NHDP) Extension TLVs
draft-ietf-manet-nhdp-olsrv2-tlv-extension-02 draft-ietf-manet-nhdp-olsrv2-tlv-extension-03
Abstract Abstract
This specification describes extensions to definitions of TLVs used This specification describes extensions to definitions of TLVs used
by the Optimized Link State Routing Protocol version 2 (OLSRv2) and by the Optimized Link State Routing Protocol version 2 (OLSRv2) and
the MANET Neighborhood Discovery Protocol (NHDP), to increase their the MANET Neighborhood Discovery Protocol (NHDP), to increase their
abilities to accommodate protocol extensions. This document updates abilities to accommodate protocol extensions. This document updates
OLSRv2 and RFC6130. OLSRv2 and RFC6130.
Status of this Memo Status of this Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 17, 2014. This Internet-Draft will expire on August 28, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
4.3. Undefined TLV Values . . . . . . . . . . . . . . . . . . . 5 4.3. Undefined TLV Values . . . . . . . . . . . . . . . . . . . 5
4.3.1. NHDP TLVs: LOCAL_IF, LINK_STATUS and OTHER_NEIGHB . . 6 4.3.1. NHDP TLVs: LOCAL_IF, LINK_STATUS and OTHER_NEIGHB . . 6
4.3.2. OLSRv2 TLVs: MPR and NBR_ADDR_TYPE . . . . . . . . . . 6 4.3.2. OLSRv2 TLVs: MPR and NBR_ADDR_TYPE . . . . . . . . . . 6
4.3.3. Unspecified TLV Values . . . . . . . . . . . . . . . . 6 4.3.3. Unspecified TLV Values . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 7 5.1. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] and the The MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] and the
Optimized Link State Routing Protocol, version 2 (OLSRv2) [OLSRv2] Optimized Link State Routing Protocol, version 2 (OLSRv2) [OLSRv2]
are protocols for use in mobile ad hoc networks (MANETs) [RFC2501], are protocols for use in mobile ad hoc networks (MANETs) [RFC2501],
based on the Generalized Mobile Ad Hoc Network (MANET) Packet/Message based on the Generalized Mobile Ad Hoc Network (MANET) Packet/Message
Format [RFC5444]. Format [RFC5444].
This document updates [RFC6130] and [OLSRv2], specifically their use This document updates [RFC6130] and [OLSRv2], specifically their use
skipping to change at page 3, line 29 skipping to change at page 3, line 29
[OLSRv2] and [RFC6130] to consider some messages, which will not be [OLSRv2] and [RFC6130] to consider some messages, which will not be
created by implementations simply following those specifications, as created by implementations simply following those specifications, as
a reason to consider the message as "badly formed", and thus as a a reason to consider the message as "badly formed", and thus as a
reason to reject the message. This gives greater latitude to the reason to reject the message. This gives greater latitude to the
creation of extensions of these protocols, in particular extensions creation of extensions of these protocols, in particular extensions
that will interoperate with unextended implementations of those that will interoperate with unextended implementations of those
protocols. As part of that, it indicates how TLVs (Type-Length-Value protocols. As part of that, it indicates how TLVs (Type-Length-Value
elements) [RFC5444] with unexpected value fields must be handled, and elements) [RFC5444] with unexpected value fields must be handled, and
adds some additional options to those TLVs. adds some additional options to those TLVs.
Note that TLVs with unknown type or type extension are already
specified as to be ignored by [RFC6130] and [OLSRv2], and also are
not a reason to reject a message.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
Additionally, this document uses the terminology of [RFC5444], Additionally, this document uses the terminology of [RFC5444],
[RFC6130], and [OLSRv2]. [RFC6130], and [OLSRv2].
3. Applicability Statement 3. Applicability Statement
This document updates the specification of the protocols [OLSRv2] and This document updates the specification of the protocols [OLSRv2] and
[RFC6130]. As such it is applicable to all implementations of these [RFC6130].
protocols.
Specifically, this specification updates [RFC6130] and [OLSRv2] in Specifically, this specification updates [RFC6130] and [OLSRv2] in
the following way: the following way:
o Removes the latitude of rejecting a message with a TLV with a o Removes the latitude of rejecting a message with a TLV with a
known type, but with an unexpected TLV Value field, for the TLV known type, but with an unexpected TLV Value field, for the TLV
Types defined in [RFC6130] and [OLSRv2]. Types defined in [RFC6130] and [OLSRv2].
o Specifies the handling of a TLV Value field with unexpected o Specifies the handling of a TLV Value field with unexpected
length. length.
skipping to change at page 4, line 33 skipping to change at page 4, line 37
defined in [RFC6130]. defined in [RFC6130].
4. TLV Values 4. TLV Values
NHDP [RFC6130] and OLSRv2 [OLSRv2] define a number of TLVs within the NHDP [RFC6130] and OLSRv2 [OLSRv2] define a number of TLVs within the
framework of [RFC5444]. These TLVs define the meaning of only some framework of [RFC5444]. These TLVs define the meaning of only some
of the contents that can be found in a TLV Value field. This of the contents that can be found in a TLV Value field. This
limitation may be either only defining certain TLV Values, or limitation may be either only defining certain TLV Values, or
considering only some lengths of the TLV Value fields (or single considering only some lengths of the TLV Value fields (or single
value field in a multi value Address-Block TLV). This specification value field in a multi value Address-Block TLV). This specification
describes how NHDP [RFC6130] and OLSRv2 [OLSRv2] SHOULD handle TLVs describes how NHDP [RFC6130] and OLSRv2 [OLSRv2] are to handle TLVs
with other TLV Value fields. with other TLV Value fields.
4.1. Unrecognized TLV Values 4.1. Unrecognized TLV Values
NHDP and OLSRv2 specify that, in addition to well-defined reasons (in NHDP and OLSRv2 specify that, in addition to well-defined reasons (in
the respective protocol specifications), an implementation of these the respective protocol specifications), an implementation of these
protocols MAY recognize a message as "badly formed" and therefore protocols MAY recognize a message as "badly formed" and therefore
"invalid for processing" for other reasons (Section 12.1 of [RFC6130] "invalid for processing" for other reasons (Section 12.1 of [RFC6130]
and Section 16.3.1 of [OLSRv2]). These sections could be interpreted and Section 16.3.1 of [OLSRv2]). These sections could be interpreted
as allowing rejection of a message because a TLV Value field is as allowing rejection of a message because a TLV Value field is
unrecognized. This specification removes that latitude: unrecognized. This specification removes that latitude:
o An implementation MUST NOT reject a message because it contains o An implementation MUST NOT reject a message because it contains an
such a TLV. Instead, any unrecognised TLV Value field MUST be unrecognized TLV value. Instead, any unrecognised TLV Value field
processed or ignored by an unextended implementation of NHDP or MUST be processed or ignored by an unextended implementation of
OLSRv2, as described in the following sections. NHDP or OLSRv2, as described in the following sections.
It should be stressed that this is not a change to [RFC6130] or It should be stressed that this is not a change to [RFC6130] or
[OLSRv2], except with regard to not allowing this to be a reason for [OLSRv2], except with regard to not allowing this to be a reason for
rejection of a message. [RFC6130] or [OLSRv2] are specified in terms rejection of a message. [RFC6130] or [OLSRv2] are specified in terms
such as "if an address is associated with a value of LOST by a such as "if an address is associated with a value of LOST by a
LINK_STATUS TLV". Association with an unrecognized value has no LINK_STATUS TLV". Association with an unrecognized value has no
effect on any implementation strictly following such a specification. effect on any implementation strictly following such a specification.
4.2. TLV Value Lengths 4.2. TLV Value Lengths
The TLVs specified in [RFC6130] and [OLSRv2] may be either single- The TLVs specified in [RFC6130] and [OLSRv2] may be either single-
value or multi-value TLVs. In either case, the length of each item value or multi-value TLVs. In either case, the length of each item
skipping to change at page 6, line 7 skipping to change at page 6, line 10
TLVs specify meanings for only some TLV Values. This document TLVs specify meanings for only some TLV Values. This document
establishes IANA registries for these TLV Values, with initial establishes IANA registries for these TLV Values, with initial
registrations reflecting those used by [RFC6130] and [OLSRv2], and as registrations reflecting those used by [RFC6130] and [OLSRv2], and as
specified in Section 4.3.3. specified in Section 4.3.3.
There are different cases of TLV Values with different There are different cases of TLV Values with different
characteristics. These cases are considered in this section. characteristics. These cases are considered in this section.
4.3.1. NHDP TLVs: LOCAL_IF, LINK_STATUS and OTHER_NEIGHB 4.3.1. NHDP TLVs: LOCAL_IF, LINK_STATUS and OTHER_NEIGHB
For the Address-Block TLVs LOCAL_IF, LINK_STAUS and OTHER_NEIGHB For the Address-Block TLVs LOCAL_IF, LINK_STATUS and OTHER_NEIGHB
TLVs, defined in [RFC6130], only a limited number of values are TLVs, defined in [RFC6130], only a limited number of values are
specified for each. These are converted, by this specification, into specified for each. These are converted, by this specification, into
extensible registries with initial registrations for values defined extensible registries with initial registrations for values defined
and used by [RFC6130] - see Section 5. and used by [RFC6130] - see Section 5.
An implementation of [RFC6130], receiving a TLV with any TLV Value An implementation of [RFC6130], receiving a LOCAL_IF, LINK_STATUS, or
other than those values used in that specification, MUST ignore that OTHER_NEIGHB TLV with any TLV Value other than the values which are
TLV Value and any corresponding attribute association to the address. defined in [RFC6130] MUST ignore that TLV Value, as well as any
corresponding attribute association to the address.
4.3.2. OLSRv2 TLVs: MPR and NBR_ADDR_TYPE 4.3.2. OLSRv2 TLVs: MPR and NBR_ADDR_TYPE
The Address-Block TLVs MPR and NBR_ADDR_TYPE, defined in [OLSRv2], The Address-Block TLVs MPR and NBR_ADDR_TYPE, defined in [OLSRv2],
are similar to those defined in [RFC6130] in having only limited are similar to those defined in [RFC6130] in having only limited
values specified (1, 2 and 3): 1 and 2, represent presence of two values specified (1, 2 and 3): 1 and 2, represent presence of two
different attributes associated to an address, and 3 represents "both different attributes associated to an address, and 3 represents "both
1 and 2". 1 and 2".
These TLV Value fields, are by this specification, converted to bit These TLV Value fields, are by this specification, converted to bit
skipping to change at page 9, line 17 skipping to change at page 9, line 21
table "MPR Address Block TLV Type Extensions" (from Table 14 in table "MPR Address Block TLV Type Extensions" (from Table 14 in
[OLSRv2]) by a reference to this table. [OLSRv2]) by a reference to this table.
+-------+-------+----------+----------------------------------------+ +-------+-------+----------+----------------------------------------+
| Value | Value | Name | Description | | Value | Value | Name | Description |
| Bit | | | | | Bit | | | |
+-------+-------+----------+----------------------------------------+ +-------+-------+----------+----------------------------------------+
| 7 | 1 | FLOODING | The neighbor with that network address | | 7 | 1 | FLOODING | The neighbor with that network address |
| | | | has been selected as flooding MPR | | | | | has been selected as flooding MPR |
| 6 | 2 | ROUTING | The neighbor with that network address | | 6 | 2 | ROUTING | The neighbor with that network address |
| | | | has been selected as flooding MPR | | | | | has been selected as routing MPR |
| 0-5 | | | Unallocated: Expert Review | | 0-5 | | | Unallocated: Expert Review |
+-------+-------+----------+----------------------------------------+ +-------+-------+----------+----------------------------------------+
Table 4: MPR TLV Bit Values Table 4: MPR TLV Bit Values
Note that this registry maintains a bit field, and that the Note that this registry maintains a bit field, and that the
combination of the bits FLOODING + ROUTING being set (1) (which gives combination of the bits FLOODING + ROUTING being set (1) (which gives
a value of 3) is given the name FLOOD_ROUTE in [OLSRv2]. For all a value of 3) is given the name FLOOD_ROUTE in [OLSRv2]. For each
future allocations, the Expert Review MUST ensure that allocated bits bit in the field, a set bit (1) means that the address has the
MUST use the unset bit (0) to indicates no information, so that the designated property, while an unset bit (0) means that no information
case Value = 0 will always indicate that no information about this about the designated property is provided. For future allocations,
network address is provided. the Designated Expert has to ensure that this sense is preserved,
and, in particular, an unset bit MUST NOT be used to convey any
specific information about the designated property.
IANA is requested to create a registry associated with the Address IANA is requested to create a registry associated with the Address
Block TLV with name NBR_ADDR_TYPE (Type = 9, Type Extension = 0) Block TLV with name NBR_ADDR_TYPE (Type = 9, Type Extension = 0)
defined in [OLSRv2], specifying the meaning of its single values in defined in [OLSRv2], specifying the meaning of its single values in
terms of the values of each bit of the value, from bit 0 (most terms of the values of each bit of the value, from bit 0 (most
significant) to bit 7 (least significant). If multiple bits are set significant) to bit 7 (least significant). If multiple bits are set
then each applies. This replaces the Description column in the (not then each applies. This replaces the Description column in the (not
yet created) IANA table "NBR_ADDR_TYPE Address Block TLV Type yet created) IANA table "NBR_ADDR_TYPE Address Block TLV Type
Extensions" (from Table 15 in [OLSRv2]) by a reference to this table. Extensions" (from Table 15 in [OLSRv2]) by a reference to this table.
skipping to change at page 10, line 4 skipping to change at page 10, line 26
| Bit | | | | | Bit | | | |
+-------+-------+------------+--------------------------------------+ +-------+-------+------------+--------------------------------------+
| 7 | 1 | ORIGINATOR | The network address is an originator | | 7 | 1 | ORIGINATOR | The network address is an originator |
| | | | address reachable via the | | | | | address reachable via the |
| | | | originating router | | | | | originating router |
| 6 | 2 | ROUTABLE | The network address is a routable | | 6 | 2 | ROUTABLE | The network address is a routable |
| | | | address reachable via the | | | | | address reachable via the |
| | | | originating router | | | | | originating router |
| 0-5 | | | Unallocated: Expert Review | | 0-5 | | | Unallocated: Expert Review |
+-------+-------+------------+--------------------------------------+ +-------+-------+------------+--------------------------------------+
Table 5: NBR_ADDR_TYPE TLV Bit Values Table 5: NBR_ADDR_TYPE TLV Bit Values
Note that this registry maintains a bit field, and that the Note that this registry maintains a bit field, and that the
combination of the bits ORIGINATOR + ROUTABLE being set (1) (which combination of the bits ORIGINATOR + ROUTABLE being set (1) (which
gives a value of 3) is given the name ROUTABLE_ORIG in [OLSRv2]. For gives a value of 3) is given the name ROUTABLE_ORIG in [OLSRv2]. For
all future allocations, the Expert Review MUST ensure that allocated each bit in the field, a set bit (1) means that the address has the
bits MUST use the unset bit (0) to indicates no information, so that designated property, while an unset bit (0) means that no information
the case Value = 0 will always indicate that no information about about the designated property is provided. For future allocations,
this network address is provided. the Designated Expert has to ensure that this sense is preserved,
and, in particular, an unset bit MUST NOT be used to convey any
specific information about the designated property.
6. Security Considerations 6. Security Considerations
The presented updates to [RFC6130] and [OLSRv2]: The presented updates to [RFC6130] and [OLSRv2]:
o Create IANA registries for retaining TLV values for TLVs, already o Create IANA registries for retaining TLV values for TLVs, already
defined in the already published specifications of the two defined in the already published specifications of the two
protocols, and with initial registrations for the TLV values protocols, and with initial registrations for the TLV values
defined by these specifications. This does not give rise to any defined by these specifications. This does not give rise to any
additional security considerations. additional security considerations.
 End of changes. 15 change blocks. 
28 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/