Optimized flooding for NHDP Dual Stack routers
draft-rogge-manet-nhdp-dualstack-optimization-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Henning Rogge | ||
| Last updated | 2014-07-28 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rogge-manet-nhdp-dualstack-optimization-00
MANET H. Rogge
Internet-Draft Fraunhofer FKIE
Intended status: Experimental July 28, 2014
Expires: January 29, 2015
Optimized flooding for NHDP Dual Stack routers
draft-rogge-manet-nhdp-dualstack-optimization-00
Abstract
This document specifies an optimization for the flooding of RFC5444
control traffic with NHDP.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 29, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Rogge Expires January 29, 2015 [Page 1]
Internet-Draft NHDP Dual Stack Optimization July 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
4. Dual Stack Optimization Rational . . . . . . . . . . . . . . 3
5. Dual Stack Optimization Functioning & Overview . . . . . . . 3
6. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Initial Values . . . . . . . . . . . . . . . . . . . . . 4
7. Packets and Messages . . . . . . . . . . . . . . . . . . . . 4
7.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4
7.3. NHDP message generation . . . . . . . . . . . . . . . . . 5
7.4. NHDP message processing . . . . . . . . . . . . . . . . . 5
7.5. Dualstack RFC5444 Message Aggregation . . . . . . . . . . 5
7.6. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.6.1. Message TLVs . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8.1. Expert Review: Evaluation Guidelines . . . . . . . . . . 6
8.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative References . . . . . . . . . . . . . . . . . . 7
11.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
While a lot of MANETs have been running as pure IPv4 networks in the
past, networks with both IPv4 and IPv6 support are much more
important today.
It is possible to run instances of OLSRv2 and NHDP on the same
router, but this introduces unnecessary overhead to the network.
This document describes a way to reduce the overhead of a Dual Stack
MANET while keeping backward compatibility to MANET routers without
this capability, including routers that run two separated instances
of the routing protocol for both IPv4 and IPv6.
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].
Rogge Expires January 29, 2015 [Page 2]
Internet-Draft NHDP Dual Stack Optimization July 2014
The terminology introduced in [RFC5444], [RFC7181] and [RFC6130],
including the terms "packet", "message" and "TLV" are to be
interpreted as described therein.
3. Applicability Statement
The Dual Stack optimization described in this document is applicable
for all combined IPv4 and IPv6 deployments of RFC5444 based routing
protocols that share a single combined implementation for both IP
address types.
This specification also requires [RFC6130] HELLO messages with an
unique originator address, e.g. as described in [RFC7181].
4. Dual Stack Optimization Rational
RFC5444 based routing protocols can aggregate messages in UDP packets
to reduce the number of media access and the overhead introduced by
IP and MAC header.
This specification allows routers to aggregate messages with
different address length (e.g. IPv4 and IPv6 based messages) in a
single UDP packet, which allows for a further reduction of media
access and overhead.
5. Dual Stack Optimization Functioning & Overview
This specification uses an additional TLV inside the IPv6 [RFC6130]
HELLO messages to signal the corresponding IPv4 originator address.
This allows the router to determine which neighbors are Dual Stack
capable and which IPv4/IPv6 originator address pair belongs to the
same neighbor router.
Whenever a [RFC5444] message with Hoplimit field larger than 1 is
created or forwarded, the router counts the number of IPv4-only,
IPv6-only and Dual Stack neighbors in its Link Set Tuples on each
interface. If the interface has at least one IPv4-only neighbor, all
IPv4 messages must be forwarded in IPv4 UDP packets. If the
interface has at least one IPv6-only neighbor, all IPv6 messages must
be forwarded in IPv6 UDP packets. Other messages can be forwarded in
any UDP packet, the protocol prefers IPv4 UDP packets because of the
lower header overhead.
Rogge Expires January 29, 2015 [Page 3]
Internet-Draft NHDP Dual Stack Optimization July 2014
6. Data Structures
This specification extends the Link Set Tuples of the Interface
Information Base, as defined in [RFC6130] section 7.1, by the
following additional elements for each link tuple when being used
with this metric:
L_Dual Stack_Originator is the originator address of the Dual Stack
partner node of the link.
This field is only used for IPv6 Link Set Tuples.
6.1. Initial Values
When generating a new tuple in the Link Set, as defined in [RFC6130]
section 12.5 bullet 3, the values of the elements specified in
Section 6 are set as follows:
o L_Dual Stack_Originator := UNDEFINED.
7. Packets and Messages
7.1. Definitions
For the purpose of this section, note the following definitions:
o IPv4ONLY(if): number of IPv4 Link Set Tuples for the interface
"if" that have no IPv6 Link Set Tuple for the same interface with
L_Dual Stack_Originator set to their IPv4 originator address.
o IPv6ONLY(if): number of IPv6 Link Set Tuples for the interface
"if" that have no IPv4 Link Set Tuple for the same interface with
the IPv4 originator address set to the L_Dual Stack_Originator
element.
o DUALSTACK(if): number of IPv6 Link Set Tuples for the interface
"if" that have a IPv4 Link Set Tuples for the same interface with
the IPv4 originator address set to the L_Dual Stack_Originator
element.
7.2. Requirements
This protocol requires the router to be able to receive and process
incoming [RFC5444] messages both with address length 4 and 16,
regardless of the IP address family of the UDP packet.
Rogge Expires January 29, 2015 [Page 4]
Internet-Draft NHDP Dual Stack Optimization July 2014
[RFC5444] messages that have no Hoplimit field or a Hoplimit field
with value 1, e.g. [RFC6130] HELLO messages are never sent in UDP
packets which don't match the address length of the message.
7.3. NHDP message generation
For each generated [RFC6130] HELLO message, the following steps have
to be followed:
1. Add a message TLV of type ADDRESS with type extension
ADDR_ORIGINATOR and length 4 to the HELLO message with the IPv4
originator address of the local node as the value.
7.4. NHDP message processing
For each incoming [RFC6130] HELLO message with an address length of
16 (IPv6), additional processing MUST be carried out after the packet
messages have been processed as specified in [RFC6130] and [RFC7181].
The router MUST update the Link Set Tuple corresponding to the
originator of the packet:
o If the message contains an ADDRESS TLV with type extension
ORIGINATOR and length 4:
* L_Dual Stack_Originator := tlvvalue.
o Otherwise:
* L_Dual Stack_Originator := UNDEFINED.
7.5. Dualstack RFC5444 Message Aggregation
For each [RFC5444] message with address length 4 (IPv4) that is ready
to be put into an UDP packet on the interface 'if', the following
steps need to be followed:
o If the message has no Hop Limit header field or Hop Limit == 1 or
DUALSTACK(if) == 0 or IPv4ONLY(if) != 0 or IPv6ONLY(if) == 0
* Put the message into an IPv4 packet.
Otherwise
* Put the message into an IPv6 packet.
Rogge Expires January 29, 2015 [Page 5]
Internet-Draft NHDP Dual Stack Optimization July 2014
For each [RFC5444] message with address length 16 (IPv6) that is
ready to be put into an UDP packet on the interface 'if', the
following steps need to be followed:
o If the message has no Hop Limit header field or Hop Limit == 1 or
DUALSTACK(if) == 0 or IPv6ONLY(if) != 0
* Put the message into an IPv6 packet.
Otherwise
* Put the message into an IPv4 packet.
7.6. TLVs
This specification defines one Message TLV.
Note that, following [RFC5444] and network byte order, bits in an
octet are numbered from 0 (most significant) to 7 (least
significant).
7.6.1. Message TLVs
The ADDRESS TLV is used in [RFC5444] messages to transport addresses
with a different address length than the message address block.
+---------+---------------------+---------------------------------+
| Type | Type Extension | Value |
+---------+---------------------+---------------------------------+
| ADDRESS | ADDR_ORIGINATOR (0) | Originator Address of a router. |
+---------+---------------------+---------------------------------+
Table 1: ADDRESS TLV Definition
8. IANA Considerations
This specification defines one Message TLV Type, which have been
allocated from the "Message TLV Types" registry of [RFC5444].
8.1. Expert Review: Evaluation Guidelines
For the registries where an Expert Review is required, the designated
expert SHOULD take the same general recommendations into
consideration as are specified by [RFC5444].
8.2. Message TLV Types
Rogge Expires January 29, 2015 [Page 6]
Internet-Draft NHDP Dual Stack Optimization July 2014
This specification defines one Message TLV Type, which has been
allocated from the "Message TLV Types" namespace defined in
[RFC5444]. IANA has made allocations in the 0-127 range for this
type. The new Type Extension registries have been created with
assignment as specified in Table 2.
+---------+------+-------------------+---------------+--------------+
| Name | Type | Type Extension | Description | Allocation |
| | | | | Policy |
+---------+------+-------------------+---------------+--------------+
| ADDRESS | TBD | ADDR_ORIGINATOR | Originator | |
| | | (0) | address of a | |
| | | | router. | |
| | | | | |
| ADDRESS | TBD | 1-255 | unassigned | Expert |
| | | | | Review |
+---------+------+-------------------+---------------+--------------+
Table 2: Message TLV Type Assignment: ADDRESS TLV
Type extensions indicated as Expert Review SHOULD be allocated as
described in [RFC5444], based on Expert Review as defined in
[RFC5226].
9. Security Considerations
The IPv6 [RFC6130] HELLO messages of a router might contain an IPv4
originator address that does belong to a different router, which
could lead to database inconsistencies. A router implementing this
specification might want to include consistency checks so that the
mapping between IPv4 and IPv6 Link Set Tuples is strictly one-to-one.
10. Acknowledgements
This effort/activity is supported by the European Community Framework
Program 7 within the Future Internet Research and Experimentation
Initiative (FIRE), Community Networks Testbed for the Future Internet
([CONFINE]), contract FP7-288535.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
Rogge Expires January 29, 2015 [Page 7]
Internet-Draft NHDP Dual Stack Optimization July 2014
[RFC5226] Nartan, T. and H. Alverstrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2119, BCP 14,
May 2008.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized Mobile Ad Hoc Network (MANET) Packet/Message
Format", RFC 5444, February 2009.
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011.
[RFC7181] Clausen, T., Jacquet, P., and C. Dearlove, "The Optimized
Link State Routing Protocol version 2", RFC 7181, March
2013.
11.2. Informative References
[CONFINE] Braem, B., Blondia, C., Barz, C., Rogge, H., Freitag, F.,
Navarro, L., Bonicioli, J., Papathanasiou, S., Escrich,
P., Vinas, R., Kaplan, A., Neumann, A., Balaguer, I.,
Tatum, B., and M. Matson, "A case for research with and on
community networks", July 2013,
<http://www.confine-project.eu>.
Author's Address
Henning Rogge
Fraunhofer FKIE
Fraunhofer Strasse 20
53343 Wachtberg
Germany
Phone: +49 228 9434 961
Email: henning.rogge@fkie.fraunhofer.de
URI: http://www.fkie.fraunhofer.de
Rogge Expires January 29, 2015 [Page 8]