Internet DRAFT - draft-rogge-stateless-rfc5444-dlep
draft-rogge-stateless-rfc5444-dlep
Mobile Ad-hoc Networks H. Rogge
Internet-Draft Fraunhofer FKIE
Intended status: Informational November 5, 2012
Expires: May 9, 2013
Stateless RFC5444-based Dynamic Link Exchange Protocol (DLEP)
draft-rogge-stateless-rfc5444-dlep-00
Abstract
This document provides material for the discussion in the MANET WG
about the Dynamic Link Exchange Protocol (DLEP). This document
reflects the authors' thoughts about how a stateless DLEP protocol
compliant with RFC5444 could look like.
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 May 9, 2013.
Copyright Notice
Copyright (c) 2012 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 May 9, 2013 [Page 1]
Internet-Draft Stateless RFC5444-DLEP November 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7
4.1. Routers and Radios . . . . . . . . . . . . . . . . . . . . 7
4.2. Information Base Overview . . . . . . . . . . . . . . . . 8
4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 9
4.3.1. Automatic Radio Interface Discovery . . . . . . . . . 10
4.3.2. Setup Radio . . . . . . . . . . . . . . . . . . . . . 10
4.3.3. Interface Updates . . . . . . . . . . . . . . . . . . 10
4.3.4. Local Destinations . . . . . . . . . . . . . . . . . . 11
4.3.5. Neighbor Updates . . . . . . . . . . . . . . . . . . . 11
5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 12
5.1. Port Number and Multicast Address . . . . . . . . . . . . 12
5.2. DLEP-Radio Parameters . . . . . . . . . . . . . . . . . . 12
5.3. DLEP-Router Parameters . . . . . . . . . . . . . . . . . . 13
6. Local Radio Information Base . . . . . . . . . . . . . . . . . 15
6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 15
6.2. Interface Neighbor Set . . . . . . . . . . . . . . . . . . 15
6.3. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 16
6.4. Interface Data Set . . . . . . . . . . . . . . . . . . . . 16
6.5. Neighbor Data Set . . . . . . . . . . . . . . . . . . . . 17
7. Configuration Information Base . . . . . . . . . . . . . . . . 18
7.1. Interface Configuration Set . . . . . . . . . . . . . . . 18
7.2. Local Destination Set . . . . . . . . . . . . . . . . . . 18
8. Local Router Information Base . . . . . . . . . . . . . . . . 20
8.1. Radio Interface Configuration Set . . . . . . . . . . . . 20
8.2. Destination Configuration Set . . . . . . . . . . . . . . 20
9. Network Information Base . . . . . . . . . . . . . . . . . . . 22
9.1. Discovered Interface Set . . . . . . . . . . . . . . . . . 22
9.2. Network Local Destination Set . . . . . . . . . . . . . . 22
9.3. Network Interface Data Set . . . . . . . . . . . . . . . . 23
9.4. Network Neighbor Set . . . . . . . . . . . . . . . . . . . 24
9.5. Network Neighbor Data Set . . . . . . . . . . . . . . . . 24
10. Local Radio Information Base Changes . . . . . . . . . . . . . 26
10.1. New Radio Interface Neighbor . . . . . . . . . . . . . . . 26
10.2. Lost Radio Interface Neighbor . . . . . . . . . . . . . . 27
10.3. Radio Interface Status . . . . . . . . . . . . . . . . . . 28
11. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 29
11.1. DLEP Messages . . . . . . . . . . . . . . . . . . . . . . 29
11.1.1. DLEP Message Orders . . . . . . . . . . . . . . . . . 30
11.2. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 30
11.3. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 31
12. Interface Update Order . . . . . . . . . . . . . . . . . . . . 36
12.1. Interface Update Order Generation . . . . . . . . . . . . 36
12.2. Interface Update Order Processing . . . . . . . . . . . . 37
Rogge Expires May 9, 2013 [Page 2]
Internet-Draft Stateless RFC5444-DLEP November 2012
13. Local Destination Order . . . . . . . . . . . . . . . . . . . 39
13.1. Local Destination Order Generation . . . . . . . . . . . . 39
13.2. Local Destination Order Processing . . . . . . . . . . . . 40
14. Neighbor Update Order . . . . . . . . . . . . . . . . . . . . 42
14.1. Neighbor Update Order Generation . . . . . . . . . . . . . 42
14.2. Neighbor Update Order Discarding . . . . . . . . . . . . . 44
14.3. Neighbor Update Order Processing . . . . . . . . . . . . . 44
15. Setup Radio Order . . . . . . . . . . . . . . . . . . . . . . 46
15.1. Setup Radio Order Generation . . . . . . . . . . . . . . . 46
15.2. Setup Radio Order Processing . . . . . . . . . . . . . . . 47
16. Setup Destination Order . . . . . . . . . . . . . . . . . . . 48
16.1. Setup Destination Order Generation . . . . . . . . . . . . 48
16.2. Setup Destination Order Processing . . . . . . . . . . . . 49
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
17.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 51
17.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 51
17.3. Message-Type-Specific TLV Type Registries . . . . . . . . 51
17.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 52
17.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 52
18. Further work . . . . . . . . . . . . . . . . . . . . . . . . . 53
19. Security Considerations . . . . . . . . . . . . . . . . . . . 54
20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
20.1. Normative References . . . . . . . . . . . . . . . . . . . 55
20.2. Informative References . . . . . . . . . . . . . . . . . . 55
Appendix A. RFC5444-DLEP Message Examples . . . . . . . . . . . . 56
A.1. Interface Update Order Example . . . . . . . . . . . . . . 56
A.2. Neighbor Update Order Example . . . . . . . . . . . . . . 59
A.3. Setup Radio Order Example . . . . . . . . . . . . . . . . 61
A.4. Setup Destination Order . . . . . . . . . . . . . . . . . 62
A.5. Local Destination Order Example . . . . . . . . . . . . . 65
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 66
Rogge Expires May 9, 2013 [Page 3]
Internet-Draft Stateless RFC5444-DLEP November 2012
1. Introduction
This document is not intented to go forward on its own, but provides
input for the discussion in the MANET WG about DLEP, in particular
for (1) allowing to use preexisting RFC5444 parsers and generators
with DLEP, and (2) to simplify the protocol by proposing a
"stateless" protocol specification of DLEP. It is the opinion of the
author of this document that delivering this input for the discussion
may help to clarify some proposals that have been made on the MANET
mailing list.
Dynamic Link Exchange Protocol (DLEP, as defined in [dlep02]) is a
proposal for a cross-layer protocol between a layer-2 entity like a
radio and a layer-3 router to transport layer-2 metric, statistic and
status data from the radio to the router. In addition, it allows the
router to control and configure aspects of the radio, such as radio
status, channel or link speed.
DLEP does not communicate via radio links, it is only used locally.
Therefore DLEP does not need to focus on payload efficiency as other
protocols of the MANET working group.
A DLEP-capable radio works as a transparent bridge for the data-
plane. DLEP is used to transport meta-information like link metrics,
detected neighbors and configuration options between radio and router
via a separate control plane.
This document does not discuss the Link Characteristic configuration
and Credit Granting parts of [dlep02], it rather concentrates on a
[RFC5444] compatible packet format, so a standard compliant generic
parser/generator code can be used for this.
Instead of copying the functionality of the [dlep02] state machine
and session handling, this document tries to reproduce the
functionality with a stateless design similar to the mechanisms in
[RFC6130] and [olsrv2].
If this aproach is adopted by the Working Group, parts of this
document could be folded back into the draft-ietf-manet-dlep.
Rogge Expires May 9, 2013 [Page 4]
Internet-Draft Stateless RFC5444-DLEP November 2012
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].
The terminology introduced in [RFC5444] and [RFC5497], including the
terms "packet", "message", "Address Block", "TLV Block","TLV",
"address", "address prefix", and "address object" are to be
interpreted as described therein.
Additionally, this document uses the following terminology and
notational conventions:
Order - This specification uses a single [RFC5444] Message Type to
transmit several different kinds of information. The Order of the
Message specifies the type of information that is contained in the
Message.
DLEP-router - a router which runs DLEP, also called Server in
[dlep02].
DLEP-radio - a radio (or modem) which runs DLEP with one or more
external layer-2 interfaces (e.g. WLAN interfaces). It also has
a connection to attach a DLEP-router. A DLEP-radio is also called
Client in [dlep02].
Radio Interface - an external interface of a DLEP-radio.
Radio Interface ID - an unique 6 octet identifier for an radio
interface of a DLEP-radio has. A DLEP-radio MAY use MAC-addresses
as interface IDs. There MAY be special IDs for defining the
receiving part of a multicast or broadcast transmission.
Destination - A MAC-address of a device attached a DLEP-radio that
can be reached through the radio interface of the DLEP-radio.
This can be a unicast, multicast or broadcast MAC.
Neighbor - A Destination that can be reached through a remote radio
interface.
Network - In the context of this document, a network is a group of
layer-2 radio devices talking to each other.
Rogge Expires May 9, 2013 [Page 5]
Internet-Draft Stateless RFC5444-DLEP November 2012
3. Assumptions
This protocol keeps most assumptions as defined in [dlep02].
[dlep02] and this specification assume that participating DLEP-radios
appear to the DLEP-routers as a transparent bridge - specifically,
the assumption is that the destination MAC address for data-plane
traffic in any frame emitted by the DLEP-router should be the MAC
address of the next-hop router or end-device, and not the MAC address
of any of the intervening devices (like DLEP-radios).
[dlep02] and this specification assume that security on the protocol
(e.g. authentication of DLEP-radio/router, encryption of data- and/or
control-plane traffic) is dealt with by the underlying transport
mechanism for the [RFC5444] packets. As an alternative this
specification would suggest using the signature support for [RFC5444]
itself (as defined in [RFC6622]).
[dlep02] and this specification assume that the DLEP-radios will be
only connected to a single DLEP-router, not multiple devices. It
might be investigate if this assumption can be relaxed later.
This specification assumes that the DLEP-radio is capable to
determine the Radio Interface IDs of the other side of the radio
communication from the Ethernet destination MAC-address of packets
incoming from the local DLEP-router. It also assumes that a DLEP-
radio is capable to determine the source MAC-address of packets
incoming through the DLEP-radios interface.
This specification assumes that the control-plane of the DLEP-radio,
which is used by this protocol, is separated by the data-plane from
each other by some mechanism. Protocol traffic between DLEP-router
and DLEP-radio will not interfere with data forwarded by the radio.
Rogge Expires May 9, 2013 [Page 6]
Internet-Draft Stateless RFC5444-DLEP November 2012
4. Protocol Overview and Functioning
The objectives of this protocol are for each DLEP-radio to:
o Announce its presence to the attached DLEP-router.
o Provide each DLEP-router with Neighbor information present in its
radio.
o Provide each DLEP-router with network metrics and statistics.
o Provide each DLEP-router with Neighbor radio link metrics and
statistics.
The objectives of this protocol are for each DLEP-router to:
o Automatically discover the presence of DLEP-radio interfaces in
the local network.
o Get a list of all known Neighbors of each DLEP-radio interface.
o Get a list of network metrics and statistics.
o Get a list of Neighbor metrics and statistics.
o Being able to configure the radios local interface.
4.1. Routers and Radios
This specification describes two different kinds of protocol
instances, DLEP-radios and DLEP-routers.
Rogge Expires May 9, 2013 [Page 7]
Internet-Draft Stateless RFC5444-DLEP November 2012
+--------+
^ | DLEP |
| | router |
| +--------+
DLEP |
| +--------+
| | DLEP |
V | radio |
+--------+
|
|
------------
/ \
+--------+ +-------+ | | +-------+ +--------+
| DLEP | | DLEP | | Radio | | DLEP | | DLEP |
| router |-----| radio |--| |--| radio |-----| router |
+--------+ +-------+ | Network | +-------+ +--------+
| |
<==== DLEP ====> \ / <==== DLEP ====>
------------
Example of a radio network with three DLEP-radios and -routers.
Figure 1
DLEP-radios are typically data-link layer forwarding devices. These
devices are connected to a local router via a short distance and high
speed link, often an Ethernet connection. They contain enough
resources to provide extra services to the router, and they are often
embedded computer systems on their own.
DLEP-radios should split the connection between radio and router into
separate control- and data-planes, to be able to bridge the data-
plane directly to a radio interface without being influenced by the
protocol traffic between DLEP-radio and the DLEP-router on the
control-plane.
DLEP-routers can detect and configure DLEP-radios via the described
protocol. The router can use the protocol to gather interface and
Neighbor information and access link-layer metrics and statistics in
a hardware independent way, even with the radio hardware not built
into the router.
4.2. Information Base Overview
Both DLEP-radio and DLEP-router maintain the protocol state using
Information Bases, described in the following section. Each
Information Base consists of a number of Protocol Sets. Each
Rogge Expires May 9, 2013 [Page 8]
Internet-Draft Stateless RFC5444-DLEP November 2012
Protocol Set contains a number of Protocol Tuples.
An implementation of this protocol may maintain this information in
the indicated form, or in any other organization that offers access
to this information. In particular, note that it is not necessary to
remove Protocol Tuples from Protocol Sets at the exact time
indicated, only to behave as if the Protocol Tuples were removed at
that time.
The Local Radio Information Base is maintained in the DLEP-radio and
included in Interface Update and Neighbor Update Orders to the DLEP-
router. Information in the Network Information Base on the DLEP-
router is determined by received Interface Update and Neighbor Update
Orders from the DLEP-radio. Such information has a limited duration
in which it is considered valid. This duration is determined from
the VALIDITY_TIME TLV in the Order in which the information is
received, which in turn is set by the DLEP-radio that originated the
Order, using its corresponding DLEP-radio parameter
INTERFACE_UPDATE_HOLD_TIME and NEIGHBOR_UPDATE_HOLD_TIME.
The Local Router Information Base is maintained in the DLEP-router
and included in Setup Radio and Setup Destination Orders to the DLEP-
radio. Information in the Configuration Information Base on the
DLEP-radio originates from Setup Radio and Setup Destination Orders
from the DLEP-router. Such information has a limited duration in
which it is considered valid. This duration is determined from the
VALIDITY_TIME TLV in the both Orders in which the information is
received, which in turn is set by the DLEP-router that originated the
Orders, using its corresponding DLEP-router parameter
SETUP_RADIO_HOLD_TIME and SETUP_DESTINATION_HOLD_TIME.
Information in the Configuration Information Base on the DLEP-radio
is included in the Local Destination Order to the DLEP-router. Such
information has a limited duration in which it is considered valid.
This duration is determined from the VALIDITY_TIME TLV in the Local
Destination Order in which the information is received, which in turn
is set by the DLEP-router that originated the Local Destination
Order, using its corresponding DLEP-radio parameter
LOCAL_DESTINATION_HOLD_TIME.
4.3. Signaling Overview
This protocol contains a signaling mechanism for maintaining the
Configuration Information Base and the Network Information Base.
Rogge Expires May 9, 2013 [Page 9]
Internet-Draft Stateless RFC5444-DLEP November 2012
4.3.1. Automatic Radio Interface Discovery
As in [dlep02], this specification contains an automatic discovery
mechanism, that allows a DLEP-router to detect the presence of one or
multiple DLEP-radio interfaces.
To enable the DLEP-router to do this, this specification uses a
single Order, the Interface Update Order.
This Order combines the Peer Discovery, Peer Offer, Peer Update
(ACK), Peer Termination (ACK), and Heartbeat messages of [dlep02].
Because of a validity time based mechanism, this obsoletes the
internal state machine of [dlep02].
For the content of the Interface Update Order, see Section 4.3.3
4.3.2. Setup Radio
This specification allows the DLEP-router to configure DLEP-radio
interface settings. In this document, there are two Orders to
configure the DLEP-radio, the Setup Radio Order and the Setup
Destination Order.
The Setup Radio Order allows the DLEP-router to set the status of the
DLEP-radio interface to UP or DOWN.
The Setup Destination Order adds a local Destination to a DLEP-radio
interface, with IP-prefixes attached to this Destination (if known).
This data is used by some radios to transport the MAC-address and IP
prefixes of their attached Destinations to each other within the
layer-2 protocol, to avoid an Address Resolution Protocol (ARP)
exchange over the radio.
4.3.3. Interface Updates
DLEP-radios transmit a list of its interfaces and data about the
interface's status, description and network metrics and statistics
with the Interface Update Order.
The Order contains the Radio Interface ID that is described in the
Order, the status of the interface (up or down) and an optional
textual description of this radios interface (e.g. Company XYZ
Software Defined Radio ABC line 1). It also contains interface
specific metrics and statistics.
This data will be sent by DLEP-radios in regular intervals, at least
once every INTERFACE_UPDATE_INTERVAL.
Rogge Expires May 9, 2013 [Page 10]
Internet-Draft Stateless RFC5444-DLEP November 2012
4.3.4. Local Destinations
DLEP-radios transmit the currently configured Destination of the
local router back to the router to acknowledge the configuration with
the Local Destination Order.
The Order contains the MAC-address of the locally configured
Destination, the its local Radio Interface ID and the IP-prefixes of
the Destination (if known).
This data will be sent by DLEP-radios in Local Destination Orders in
regular intervals, at least once every LOCAL_DESTINATION_INTERVAL.
4.3.5. Neighbor Updates
Modern IP-capable radios are able to collect lots of PHY- and link-
layer data about their connections to other radios in range and the
Destinations behind them.
The Neighbor Update Order contains the known configuration (MAC- and
IP-addresses), status and attributes (e.g. link statistics and
metrics) of a radio connection between the local DLEP-radio interface
and a Neighbor.
This data will be sent by DLEP-radios in Neighbor Update Orders in
regular intervals, at least once every NEIGHBOR_UPDATE_INTERVAL.
Rogge Expires May 9, 2013 [Page 11]
Internet-Draft Stateless RFC5444-DLEP November 2012
5. Protocol Parameters
5.1. Port Number and Multicast Address
While [dlep02] is likely to be designed to be transport independent,
DLEP over UDP will be a common use case, so DLEP MUST specify a
default UDP port number and a Linklocal Multicast address to be used.
If an existing port and Multicast address can be reused or not is out
of scope for this specification.
5.2. DLEP-Radio Parameters
There are several parameters that MUST be set on a DLEP-radio.
INTERFACE_UPDATE_INTERVAL:
The maximum time between the transmission of two successive
Interface Update Orders for the same DLEP-radio interface,
possibly modified by jitter as specified in [RFC5148].
LOCAL_DESTINATION_INTERVAL:
The maximum time between the transmission of two successive Local
Destination Orders for the same DLEP-radio interface, possibly
modified by jitter as specified in [RFC5148].
NEIGHBOR_UPDATE_INTERVAL:
The maximum time between the transmission of two successive
Neighbor Update Orders for the same DLEP-radio interface, possibly
modified by jitter as specified in [RFC5148].
INTERFACE_UPDATE_HOLD_TIME:
Used as the Value in the VALIDITY_TIME Message TLV included in all
Interface Update Orders. It is then used by the DLEP-router
receiving such an Order to indicate the validity of the
information taken from that Order and recorded in the receiving
DLEP-router's Network Information Base.
LOCAL_DESTINATION_HOLD_TIME:
Used as the Value in the VALIDITY_TIME Message TLV included in all
Local Destination Orders. It is then used by the DLEP-router
receiving such an Order to indicate the validity of the
information taken from that Order and recorded in the receiving
DLEP-router's Network Information Base.
Rogge Expires May 9, 2013 [Page 12]
Internet-Draft Stateless RFC5444-DLEP November 2012
NEIGHBOR_UPDATE_HOLD_TIME:
Used as the Value in the VALIDITY_TIME Message TLV included in all
Neighbor Update Orders. It is then used by the DLEP-router
receiving such an Order to indicate the validity of the
information taken from that Order and recorded in the receiving
DLEP-router's Network Information Base.
DEFAULT_INTERFACE_STATE:
Defines the default status of the interfaces of a DLEP-radio. It
MUST be UP or DOWN.
The following constraints apply to these DLEP-radio parameters:
o INTERFACE_UPDATE_INTERVAL > 0
o LOCAL_DESTINATION_INTERVAL > 0
o NEIGHBOR_UPDATE_INTERVAL > 0
o INTERFACE_UPDATE_HOLD_TIME > INTERFACE_UPDATE_INTERVAL
o LOCAL_DESTINATION_HOLD_TIME > LOCAL_DESTINATION_INTERVAL
o NEIGHBOR_UPDATE_HOLD_TIME > NEIGHBOR_UPDATE_INTERVAL
5.3. DLEP-Router Parameters
There are several parameters that MUST be set on a DLEP-router.
SETUP_RADIO_INTERVAL:
The maximum time between the transmission of two successive Setup
Radio Orders, possibly modified by jitter as specified in
[RFC5148].
SETUP_LOCAL_DESTINATION_INTERVAL:
The maximum time between the transmission of two successive Setup
Destination Orders, possibly modified by jitter as specified in
[RFC5148].
SETUP_RADIO_HOLD_TIME:
Used as the Value in the VALIDITY_TIME Message TLV included in all
Setup Radio Orders. It is then used by the DLEP-radio receiving
such an Order to indicate the validity of the information taken
Rogge Expires May 9, 2013 [Page 13]
Internet-Draft Stateless RFC5444-DLEP November 2012
from that Order and recorded in the receiving DLEP-radio's
Information Bases.
SETUP_LOCAL_DESTINATION_HOLD_TIME:
Used as the Value in the VALIDITY_TIME Message TLV included in all
Setup Destination Orders. It is then used by the DLEP-radio
receiving such an Order to indicate the validity of the
information taken from that Order and recorded in the receiving
DLEP-radio's Information Bases.
The following constraints apply to these DLEP-router parameters:
o SETUP_RADIO_INTERVAL > 0.
o SETUP_RADIO_HOLD_TIME > SETUP_RADIO_INTERVAL.
o SETUP_LOCAL_DESTINATION_INTERVAL > 0.
o SETUP_LOCAL_DESTINATION_HOLD_TIME >
SETUP_LOCAL_DESTINATION_INTERVAL.
Rogge Expires May 9, 2013 [Page 14]
Internet-Draft Stateless RFC5444-DLEP November 2012
6. Local Radio Information Base
The DLEP-radio maintains a Local Radio Information Base that records
a list of locally defined or collected data about the DLEP-radio's
interfaces and its connected neighbors.
The Local Radio Information Base is not modified by signaling. If a
DLEP-radio's interface configuration changes, then the Local Radio
Information Base MUST reflect these changes. This MAY also result in
signaling to advertise these changes.
6.1. Local Interface Set
A DLEP-radio's Local Interface Set records the existing local
interfaces, their default status and their description. It consists
of Local Interface Tuples, one per existing local interface:
(LI_radio_interface_id, LI_default_status, LI_description)
where:
LI_radio_interface_id is the Radio Interface ID of the local radio
interface.
LI_default_status is the default status of the radio interface if
not configured by the DLEP-router.
LI_description is a textual description of the radio interface
with a maximum of 80 octets without ending zero byte. It MAY be
NONE.
LI_radio_interface_id is the unique key of this set, there MUST NOT
be two tuples with the same unique key in the set.
6.2. Interface Neighbor Set
A DLEP-radios's Interface Neighbor Set records the known other DLEP-
radios in communication range and the addresses of the neighbors
reachable through this radios. It consists of Interface Neighbor
Tuples, one per known neighbor of a local interface:
(IN_radio_interface_id, IN_neighbor_interface_id, IN_mac_address,
IN_ipv4_prefixes, IN_ipv6_prefixes)
where:
IN_radio_interface_id is a six octet unique Radio Interface ID of
the local interface for this neighbor.
Rogge Expires May 9, 2013 [Page 15]
Internet-Draft Stateless RFC5444-DLEP November 2012
IN_neighbor_interface_id is a Radio Interface ID of the neighbors
DLEP-radio's interface, it MAY be NONE (or a special ID) for a
broadcast or multicast neighbor.
IN_mac_address is the six octet MAC address of the neighbor.
IN_ipv4_prefixes is a list of known IPv4 prefixes of this
neighbor. It MAY be empty.
IN_ipv6_prefixes is a list of known IPv6 prefixes of this
neighbor. It MAY be empty.
(IN_radio_interface_id, IN_neighbor_interface_id, IN_mac_address) is
the unique key of this set, there MUST NOT be two tuples with the
same unique key in the set.
6.3. Lost Neighbor Set
When a radio interface's neighbor becomes unreachable, a DLEP-radio's
Lost Neighbor Set records this for at least
INTERFACE_UPDATE_HOLD_TIME. It consists of Lost Neighbor Tuples, one
per lost neighbor of a local radio interface:
(LN_radio_interface_id, LN_neighbor_interface_id, LN_mac_address)
where:
LN_radio_interface_id is a six octet unique Radio Interface ID of
the local interface for the lost neighbor.
LN_neighbor_interface_id is a six octet unique Radio Interface ID
of the lost neighbors DLEP-radio's interface, it MAY be NONE for a
broadcast or multicast neighbor.
LN_mac_address is the six octet MAC address of the lost neighbor.
There MUST NOT be two tuples with the same data in the set.
6.4. Interface Data Set
A DLEP-radio's Interface Data Set records attributes (e.g. statistics
or metrics) of its local radio interfaces and their attached
networks. It consists of Interface Data Tuples:
(ID_radio_interface_id, ID_data_type, ID_data_value)
where:
Rogge Expires May 9, 2013 [Page 16]
Internet-Draft Stateless RFC5444-DLEP November 2012
ID_radio_interface_id is a Radio Interface ID of a local radio
interface.
ID_data_type is the type of data stored. It MUST be an extension
type of the NETWORK_DATA Address TLV.
ID_data_value is the data corresponding to this tuple's key. Its
format is defined in the NETWORK_DATA Address TLV values.
(ID_radio_interface_id, ID_data_type) is the unique key of this set,
there MUST NOT be two tuples with the same unique key in the set.
6.5. Neighbor Data Set
A DLEP-radio's Neighbor Data Set records attributes (e.g. statistics
or metrics) of a connection to a Neighbor. It consists of Neighbor
Data Tuples:
(ND_radio_interface_id, ND_neighbor_interface_id, ND_mac_address,
ND_data_type, ND_data_value)
where:
ND_radio_interface_id is a Radio Interface ID of the local
interface for this neighbor.
ND_neighbor_interface_id is a Radio Interface ID of the neighbors
DLEP-radio's interface, it MAY be NONE for a broadcast or
multicast neighbor.
ND_mac_address is the six octet MAC address of the neighbor.
ND_data_type is the type of data stored. It MUST be an extension
type of the NEIGHBOR_DATA Address TLV.
ND_data_value is the data corresponding to this tuples key. Its
format is defined in the NEIGHBOR_DATA Address TLV values.
(ND_radio_interface_id, ND_neighbor_interface_id, ND_mac_address,
ND_data_type) is the unique key of this set, there MUST NOT be two
tuples with the same unique key in the set.
Rogge Expires May 9, 2013 [Page 17]
Internet-Draft Stateless RFC5444-DLEP November 2012
7. Configuration Information Base
The DLEP-radio maintains a Configuration Information Base that
records the configuration settings of the DLEP-router for each
interface.
The Configuration Information Base is modified by Setup Radio and
Setup Destination Orders from the DLEP-router. If a Configuration
Information Base changes, then the local configuration of the
interface MUST reflect this change. This MAY also result in
signaling to advertise these changes.
7.1. Interface Configuration Set
A DLEP-radio's Interface Configuration Set records the status of the
local DLEP-radio interfaces as configured by the DLEP-router. It
consists of Interface Configuration Tuples, one for each local
interface:
(IC_radio_interface_id, IC_radio_status, IC_time)
where:
IC_radio_interface_id is a Radio Interface ID of a local radio
interface.
IC_radio_status is the status of the local radio interface. It
MUST be "up" or "down".
IC_time is the time when this tuple MUST be removed.
IC_radio_interface_id is the unique key of this set, there MUST NOT
be two tuples with the same unique key in the set.
7.2. Local Destination Set
A DLEP-radio's Local Destination Set records the known local
destinations of local radio interfaces set by the connected DLEP-
router. It consists of Local Destination Tuples:
(LD_radio_interface_id, LD_mac_address, LD_ipv4_prefixes,
LD_ipv6_prefixes, LD_time)
where:
LD_radio_interface_id is a Radio Interface ID of a local radio
interface.
Rogge Expires May 9, 2013 [Page 18]
Internet-Draft Stateless RFC5444-DLEP November 2012
LD_mac_address is the MAC address of the Destination.
LD_ipv4_prefixes is a list of IPv4 prefixes of the Destination.
It MAY be empty.
LD_ipv6_prefixes is a list of IPv6 prefixes of the Destination.
It MAY be empty.
LD_time is the time when this tuple MUST be removed.
(LD_radio_interface_id, LD_mac_address) is the unique key of this
set, there MUST NOT be two tuples with the same unique key in the
set.
Rogge Expires May 9, 2013 [Page 19]
Internet-Draft Stateless RFC5444-DLEP November 2012
8. Local Router Information Base
The DLEP-router maintains a Local Router Information Base that
records the radio interface status and the local Destinations for a
DLEP-radio.
The Local Router Information Base is not modified by signaling. If a
DLEP-router's configuration changes, then the Local Router
Information Base MUST reflect these changes. This MAY also result in
signaling to advertise these changes.
8.1. Radio Interface Configuration Set
A DLEP-router's Radio Interface Configuration Set records the radio
interface status, up or down, to be configured on a DLEP-radio. It
consists of Radio Interface Configuration Tuples, up to one for each
DLEP-radio interface connected to the DLEP-router:
(RIC_radio_interface_id, RIC_status)
where:
RIC_radio_interface_id is the Radio Interface ID of an attached
DLEP-radio.
RIC_status is the desired status of the DLEP-radio interface.
MUST be UP or DOWN.
RIC_radio_interface_id is the unique key of this set, there MUST NOT
be two tuples with the same unique key in the set.
8.2. Destination Configuration Set
A DLEP-router's Destination Configuration Set records the local
Destinations to be configured on a DLEP-radio interface. It consists
of Destination Configuration Tuples, up to one for each Destination
of a DLEP-radio interface connected to the DLEP-router:
(DC_radio_interface_id, DC_mac_address, DC_ipv4_prefixes,
DC_ipv6_prefixes)
where:
DC_radio_interface_id is the Radio Interface ID of an attached
DLEP-radio interface.
DC_mac_address is the MAC-address of Destination for the DLEP-
radio interface.
Rogge Expires May 9, 2013 [Page 20]
Internet-Draft Stateless RFC5444-DLEP November 2012
DC_ipv4_prefixes is a list of IPv4 prefixes of Destination for the
DLEP-radio interface. MAY be empty.
DC_ipv6_prefixes is a list of IPv6 prefixes of Destination for the
DLEP-radio interface. MAY be empty.
(DC_radio_interface_id, DC_mac_address) is the unique key of this
set, there MUST NOT be two tuples with the same unique key in the
set.
Rogge Expires May 9, 2013 [Page 21]
Internet-Draft Stateless RFC5444-DLEP November 2012
9. Network Information Base
A DLEP-router maintains a Network Information Base that records all
collected information transmitted by the attached DLEP-radios. This
consists both of information about the settings of the local
interfaces of the DLEP-radios, metrics and statistics about the
network attached to the local interfaces and metrics and statistics
about neighbors.
The Network Information Base is modified by Interface Update, Local
Destination, and Neighbor Update Orders from the DLEP-radio. If the
Network Information Base changes, this MAY trigger changes in the
DLEP-router.
9.1. Discovered Interface Set
A DLEP-router's Discovered Interface Set records the attached Radio
Interface IDs, the status and description of the DLEP-radio
interfaces. It consists of Discovered Interface Tuples, one for each
discovered DLEP-radio interface:
(DI_radio_interface_id, DI_radio_status, DI_description, DI_time)
where:
DI_radio_interface_id is the Radio Interface ID of the discovered
DLEP-radio interface.
DI_radio_status is the current status of the interface. MUST be
UP or DOWN.
DI_description is a textual description of the radio interface of
up to 80 characters without zero byte ending.
DI_time is the time when this tuple MUST be removed.
DI_radio_interface_id is the unique key of this set, there MUST NOT
be two tuples with the same unique key in the set.
9.2. Network Local Destination Set
A DLEP-router's Network Local Destination Set records the DLEP-radio
interface's configured local Destinations. It consists of Network
Local Destination Tuples, one for each DLEP-radio interface's local
Destination:
(NLD_radio_interface_id, NLD_mac_address, NLD_ipv4_prefixes,
NLD_ipv6_prefixes, NLD_time)
Rogge Expires May 9, 2013 [Page 22]
Internet-Draft Stateless RFC5444-DLEP November 2012
where:
NLD_radio_interface_id is the Radio Interface ID of the local
Destination's radio interface.
NLD_mac_address is the six octet MAC-address of the local
Destination.
NLD_ipv4_prefixes is a list of IPv4 prefixes configured for the
local Destination, MAY be empty.
NLD_ipv6_prefixes is a list of IPv6 prefixes configured for the
local Destination, MAY be empty.
NLD_time is the time when this tuple MUST be removed.
(NLD_radio_interface_id, NLD_mac_address) is the unique key of this
set, there MUST NOT be two tuples with the same unique key in the
set.
9.3. Network Interface Data Set
A DLEP-router's Network Interface Data Set records a list of
attributes known about a DLEP-radio's interface (e.g. interface
statistics and radio attributes). It consists of Network Interface
Data Tuples:
(NID_radio_interface_id, NID_data_type, NID_data_value, NID_time)
where:
NID_radio_interface_id is the Radio Interface ID of the DLEP-
radio's interface.
NID_data_type is the type of data stored. It MUST be an extension
type of the NETWORK_DATA Address TLV.
NID_data_value is the data corresponding to this tuples key. Its
format is defined in the NETWORK_DATA Address TLV values.
NID_time is the time when this tuple MUST be removed.
(NID_radio_interface_id, NID_data_type) is the unique key of this
set, there MUST NOT be two tuples with the same unique key in the
set.
Rogge Expires May 9, 2013 [Page 23]
Internet-Draft Stateless RFC5444-DLEP November 2012
9.4. Network Neighbor Set
A DLEP-router's Network Neighbor Set records the known configuration
and status of each neighbor of a DLEP-radio interface. It consists
of Network Neighbor Tuples, one for each neighbor or a radio
interface:
(NN_radio_interface_id, NN_neighbor_interface_id, NN_mac_address,
NN_status, NN_ipv4_prefixes, NN_ipv6_prefixes, NN_time)
where:
NN_radio_interface_id is the Radio Interface ID of the DLEP-radio
interface.
NN_neighbor_interface_id is the Radio Interface ID of the
neighbors DLEP-radio interface.
NN_mac_address is the MAC-address of the neighbor.
NN_status is the status of the neighbors radio interface. MUST be
UP or DOWN.
NN_ipv4_prefixes is a list of IPv4 prefixes of the neighbor. MAY
be EMPTY.
NN_ipv6_prefixes is a list of IPv6 prefixes of the neighbor. MAY
be EMPTY.
(NN_radio_interface_id, NN_neighbor_interface_id, NN_mac_address) is
the unique key of this set, there MUST NOT be two tuples with the
same unique key in the set.
9.5. Network Neighbor Data Set
A DLEP-router's Network Neighbor Data Set records a list of
attributes known about a DLEP-radio interface's neighbor (e.g. link
statistics and metrics). It consists of Network Neighbor Data
Tuples:
(NND_radio_interface_id, NND_neighbor_interface_id,
NND_mac_address, NND_data_type, NND_data_value, NND_time)
where:
NND_radio_interface_id is the Radio Interface ID of the DLEP-radio
interface.
Rogge Expires May 9, 2013 [Page 24]
Internet-Draft Stateless RFC5444-DLEP November 2012
NND_neighbor_interface_id is the Radio Interface ID of the
neighbors DLEP-radio interface.
NND_mac_address is the MAC-address of the neighbor.
NND_data_type is the type of data stored. It MUST be an extension
type of the NEIGHBOR_DATA Address TLV.
NND_data_value is the data corresponding to this tuples key. Its
format is defined in the NEIGHBOR_DATA Address TLV values.
NND_time is the time when this tuple MUST be removed.
(NND_radio_interface_id, NND_neighbor_interface_id, NND_mac_address,
NND_data_type) is the unique key of this set, there MUST NOT be two
tuples with the same unique key in the set.
Rogge Expires May 9, 2013 [Page 25]
Internet-Draft Stateless RFC5444-DLEP November 2012
10. Local Radio Information Base Changes
The Local Radio Information Base MUST be updated in response to
changes in the DLEP-radio's local interface configuration.
A DLEP-radio MAY transmit Interface Update and Neighbor Update Orders
in response to these changes.
10.1. New Radio Interface Neighbor
If a new Neighbor is discovered on a DLEP-radio interface, this MUST
result in changes to the Local Radio Information Base
Define
o neighbor_local_interface_id := the local Radio Interface ID of the
former neighbor.
o neighbor_remote_interface_id := the Radio Interface ID of the
neighbors DLEP-radio interface, MAY be NONE or a special ID for
multicast and broadcast Neighbors.
o neighbor_mac_address := the MAC-address of the neighbor.
o neighbor_ipv4_prefixes := the list of known IPv4 prefixes of the
neighbor.
o neighbor_ipv6_prefixes := the list of known IPv6 prefixes of the
neighbor.
Then change the information base as follows:
1. Remove all Lost Neighbor Tuple with:
* LN_radio_interface_id = neighbor_local_interface_id AND
* LN_neighbor_interface_id = neighbor_remote_interface_id AND
* LN_mac_address = neighbor_mac_address.
2. Add an Interface Neighbor Tuple with:
* IN_radio_interface_id := neighbor_local_interface_id.
* IN_neighbor_interface_id := neighbor_remote_interface_id.
* IN_mac_address := neighbor_mac_address.
Rogge Expires May 9, 2013 [Page 26]
Internet-Draft Stateless RFC5444-DLEP November 2012
* IN_ipv4_prefixes := neighbor_ipv4_prefixes.
* IN_ipv6_prefixes := neighbor_ipv6_prefixes.
The change MAY also trigger a Neighbor Update Order.
10.2. Lost Radio Interface Neighbor
If an existing neighbor is lost on a DLEP-radio interface, this MUST
result in change of the Local Radio Information Base.
Define
o neighbor_local_interface_id := the local Radio Interface ID of the
former neighbor.
o neighbor_remote_interface_id := the Radio Interface ID of the
former neighbor's radio interface.
o neighbor_mac_address := the MAC-address of the neighbor.
Then change the information base as follows:
1. Remove an existing Interface Neighbor Tuple with:
* IN_radio_interface_id = neighbor_local_interface_id AND
* IN_neighbor_interface_id = neighbor_remote_interface_id AND
* IN_mac_address = neighbor_mac_address.
2. Remove all Neighbor Data Tuples with:
* ND_radio_interface_id = neighbor_local_interface_id AND
* ND_neighbor_interface_id = neighbor_remote_interface_id AND
* ND_mac_address = neighbor_mac_address.
3. Add a Lost Neighbor Tuple with:
* LN_radio_interface_id := NI_radio_interface_id.
* LN_neighbor_interface_id := NI_neighbor_interface_id.
* LN_mac_address := NI_mac_address.
Rogge Expires May 9, 2013 [Page 27]
Internet-Draft Stateless RFC5444-DLEP November 2012
* LN_time := current + NEIGHBOR_UPDATE_HOLD_TIME.
The change MAY also trigger an Interface Update Order.
10.3. Radio Interface Status
The DLEP-radio interface status is determined by two sources, the
default radio interface status and the status configured by a DLEP-
router. Determine the actual status as follows:
Define radio_interface_id as the ID of the radio interface which
status will be determined.
If there is an Interface Configuration Tuple with
o IC_radio_interface_id = radio_interface_id,
set the radio status to IC_radio_status.
Otherwise, find the Local Interface Tuple with
o LI_radio_interface_id = radio_interface_id
and set the radio interface status to LI_default_status.
Rogge Expires May 9, 2013 [Page 28]
Internet-Draft Stateless RFC5444-DLEP November 2012
11. Packets and Messages
The packet and message format used by this protocol is defined in
[RFC5444], which is used with the following considerations:
o This protocol specifies one Message Type, the DLEP message.
o A DLEP message MAY use any combination of Message Header options
specified in [RFC5444].
o DLEP messages MUST NOT be forwarded, i.e., a <msg-hop-limit>, if
present, MUST have the value 1.
o DLEP messages MAY be included in multi-message packets as
specified in [RFC5444].
o Received DLEP messages MUST be parsed in accordance with
[RFC5444]. A DLEP message that is not in conformance with
[RFC5444] MUST be discarded without being processed.
o This protocol specifies five new Address Block TLVs and one new
Message TLV.
o This protocol uses one Message TLVs defined in [RFC5497], the
VALIDITY_TIME TLV.
This specified protocol defines and owns the DLEP Message Type (see
Section 17). Thus, as specified in [RFC5444] this protocol generates
and transmits all DLEP messages, receives all DLEP messages and is
responsible for determining whether and how each DLEP message is to
be processed.
11.1. DLEP Messages
A DLEP Message MUST contain:
o An address length of 6, meaning msg-addr-length (as defined in
[RFC5444]) must be 5.
o Exactly one Message TLV with Type = VALIDITY_TIME as defined in
[RFC5497].
o Exactly one Message TLV with Type = ORDER.
Each Address in a DLEP message MUST:
o have zero or one TLV with Type = ADD_ADDRESS and the same
Extension Type.
Rogge Expires May 9, 2013 [Page 29]
Internet-Draft Stateless RFC5444-DLEP November 2012
o have zero or one TLV with Type = NETWORK_DATA and the same
Extension Type.
o have zero or one TLV with Type = NEIGHBOR_DATA and the same
Extension Type.
o have zero or one TLV with Type = DESCRIPTION.
DLEP Messages that do not obey this rules MUST be discarded without
further processing.
A DLEP 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.
11.1.1. DLEP Message Orders
This protocol uses several messages with different semantics.
Instead of allocating a Message-Type for each of them, this
specification use the ORDER Message TLV to define an extension type
for the single Message-Type it uses. (see Table 2)
11.2. Message TLVs
The ORDER Message TLV MUST be used in all DLEP Messages. A message
MUST NOT contain more than one ORDER TLV.
+-------+--------+--------------------------------------------------+
| Type | Value | Value |
| | Length | |
+-------+--------+--------------------------------------------------+
| ORDER | 1 | Specifies the ORDER of a DLEP Message, which in |
| | | turn defines the context for the rest of the |
| | | Message. |
+-------+--------+--------------------------------------------------+
Table 1: ORDER TLV definition
There are five types of ORDER defined in this document.
Rogge Expires May 9, 2013 [Page 30]
Internet-Draft Stateless RFC5444-DLEP November 2012
+-------------------+-------------+---------------------------------+
| ORDER value | Originator | Description |
+-------------------+-------------+---------------------------------+
| INTERFACE_UPDATE | DLEP-radio | Updates the data of one or more |
| | | radio interfaces. |
| | | |
| LOCAL_DESTINATION | DLEP-radio | Publishes the locally set |
| | | Destinations of the radio |
| | | interface. |
| | | |
| NEIGHBOR_UPDATE | DLEP-radio | Updates the data of one or more |
| | | neighbors of a radio interface. |
| | | |
| SETUP_RADIO | DLEP-router | Configures a the interface |
| | | settings of one or more radio |
| | | interfaces. |
| | | |
| SETUP_DESTINATION | DLEP-router | Adds local Destinations to one |
| | | or more DLEP-radio interfaces. |
+-------------------+-------------+---------------------------------+
Table 2: Types of ORDERs in DLEP Messages
11.3. Address Block TLVs
The RADIOIF_STATUS TLV is used in all three Orders. An Address of a
DLEP Message MUST NOT contain more than one RADIOIF_STATUS TLV.
+----------------+------------+-------------------------------------+
| Type | Value | Value |
| | Length | |
+----------------+------------+-------------------------------------+
| RADIOIF_STATUS | 1 | Specifies that the interface is UP |
| | | or DOWN. |
+----------------+------------+-------------------------------------+
Table 3: RADIOIF_STATUS TLV definition
The DESCRIPTION TLV is used in the in the Interface Update Order. An
Address of an Interface Update Order MUST NOT contain more than one
DESCRIPTION TLV.
Rogge Expires May 9, 2013 [Page 31]
Internet-Draft Stateless RFC5444-DLEP November 2012
+-------------+--------+--------------------------------------------+
| Type | Value | Value |
| | Length | |
+-------------+--------+--------------------------------------------+
| DESCRIPTION | 1-80 | Specifies a human readable ASCII |
| | | identifier for a DLEP-radio interface |
| | | without added zero byte. |
+-------------+--------+--------------------------------------------+
Table 4: DESCRIPTION TLV definition
The ADD_ADDRESS TLV is used in the Local Destination, the Neighbor
Update and the Setup Destination Order. An Address of a DLEP Message
MUST NOT contain multiple ADD_ADDRESS TLVs with the same Extension
Types.
+-------------+-------------+--------+------------------------------+
| Type | Ext-Type | Value | Value |
| | | Length | |
+-------------+-------------+--------+------------------------------+
| ADD_ADDRESS | MAC | x*6 | A list of MAC-addresses |
| | | octets | attached to the address |
| | | | object. |
| | | | |
| ADD_ADDRESS | IPV4_PREFIX | x*5 | A list of IPv4 prefixes |
| | | octets | attached to the address |
| | | | object. Every IPv4 address |
| | | | is followed by a one octet |
| | | | prefix length (0-32) in the |
| | | | list. |
| | | | |
| ADD_ADDRESS | IPV6_PREFIX | x*17 | A list of IPv6 prefixes |
| | | octets | attached to the address |
| | | | object. Every IPv4 address |
| | | | is followed by a one octet |
| | | | prefix length (0-128) in the |
| | | | list. |
+-------------+-------------+--------+------------------------------+
Table 5: ADD_ADDRESS TLV definition
The NETWORK_DATA TLV is used in the Interface Update Order. An
Interface Update Order Address MUST NOT contain more than one
NETWORK_DATA TLV with the same Type Extension.
Rogge Expires May 9, 2013 [Page 32]
Internet-Draft Stateless RFC5444-DLEP November 2012
+--------------+-----------------+--------+-------------------------+
| Type | Ext-Type | Value | Value |
| | | Length | |
+--------------+-----------------+--------+-------------------------+
| NETWORK_DATA | NETWORK_ID | 1-16 | Binary identifier of a |
| | | | radio network (e.g. |
| | | | BSSID). |
| | | | |
| NETWORK_DATA | NETWORK_DESCR | 1-80 | ASCII identifier of a |
| | | | radio network without |
| | | | added zero byte (e.g. |
| | | | SSID) |
| | | | |
| NETWORK_DATA | SUPPORTED_RATES | x*8 | Array of supported data |
| | | | rates of the network an |
| | | | interface is attached |
| | | | to as an array of 8 |
| | | | octet unsigned integers |
| | | | in bit/s. |
| | | | |
| NETWORK_DATA | RESOURCES | 2 | The first octet |
| | | | contains an estimate of |
| | | | the resources left, |
| | | | between 0 (no resources |
| | | | left) and 100 (all |
| | | | resources left). The |
| | | | second octet is 0 if |
| | | | the radio has limited |
| | | | resources or 1 if the |
| | | | resources are unlimited |
| | | | and/or the resources |
| | | | are currently being |
| | | | recharged by an |
| | | | external source. |
| | | | |
| NETWORK_DATA | LAST_ACTIVE | 4 | Time since the last |
| | | | data was sent or |
| | | | received over a radio |
| | | | interface as an |
| | | | unsigned integer in |
| | | | milliseconds. |
| | | | |
| NETWORK_DATA | FREQUENCY | 8 | Mid frequency of a |
| | | | radio interface channel |
| | | | as an unsigned integer |
| | | | in Hertz. |
| | | | |
Rogge Expires May 9, 2013 [Page 33]
Internet-Draft Stateless RFC5444-DLEP November 2012
| NETWORK_DATA | BANDWIDTH | 8 | Amount of spectrum |
| | | | (frequency range) of a |
| | | | radio interface channel |
| | | | as an unsigned integer |
| | | | in Hertz. |
+--------------+-----------------+--------+-------------------------+
Table 6: NETWORK_DATA TLV definition
The NEIGHBOR_DATA TLV is used in the Neighbor Update Order. An
Network Update Order Address MUST NOT contain more than one
NEIGHBOR_DATA TLV with the same Type Extension.
+---------------+------------------+--------+-----------------------+
| Type | Ext-Type | Value | Value |
| | | Length | |
+---------------+------------------+--------+-----------------------+
| NEIGHBOR_DATA | RELATIVE_LQ | 1 | Estimate of the |
| | | | quality of a link |
| | | | between 0 (worst) and |
| | | | 100 (best). |
| | | | |
| NEIGHBOR_DATA | MAXIMUM_DATARATE | 8+8 | Maximum possible link |
| | | | speed as 8 octet |
| | | | unsigned integer in |
| | | | bits/s. First value |
| | | | is receiving speed, |
| | | | second is |
| | | | transmitting speed. |
| | | | |
| NEIGHBOR_DATA | CURRENT_DATARATE | 8+8 | Current link speed as |
| | | | 8 octet unsigned |
| | | | integer in bits/s. |
| | | | First value is |
| | | | receiving speed, |
| | | | second is |
| | | | transmitting speed. |
| | | | |
| NEIGHBOR_DATA | TRAFFIC | 8+8 | Number of bytes |
| | | | exchanged with a |
| | | | neighbor since link |
| | | | went up as 8 octet |
| | | | unsigned integer in |
| | | | bytes. First value is |
| | | | received bytes, |
| | | | second is transmitted |
| | | | bytes. |
| | | | |
Rogge Expires May 9, 2013 [Page 34]
Internet-Draft Stateless RFC5444-DLEP November 2012
| NEIGHBOR_DATA | PACKETS | 8+8 | Number of IP packets |
| | | | exchanged with a |
| | | | neighbor since link |
| | | | went up as 8 octet |
| | | | unsigned integer in |
| | | | bytes. First value is |
| | | | received packets, |
| | | | second is transmitted |
| | | | packets. |
| | | | |
| NEIGHBOR_DATA | FRAMES | 8+8 | Number of link-layer |
| | | | frames exchanged with |
| | | | a neighbor since link |
| | | | went up as 8 octet |
| | | | unsigned integer in |
| | | | bytes. First value is |
| | | | received frames, |
| | | | second is transmitted |
| | | | frames. |
| | | | |
| NEIGHBOR_DATA | TX_RETRIES | 8 | Number of link-layer |
| | | | retransmissions of |
| | | | the same IP packet |
| | | | since link went up as |
| | | | unsigned integer. |
| | | | |
| NEIGHBOR_DATA | TX_FAILS | 8 | Number of permanent |
| | | | link-layer |
| | | | transmission failures |
| | | | of an IP packet since |
| | | | the link went up as |
| | | | unsigned integer. |
| | | | |
| NEIGHBOR_DATA | LAST_ACTIVE | 4 | Time since the last |
| | | | data was exchanged as |
| | | | an unsigned integer |
| | | | in milliseconds. |
+---------------+------------------+--------+-----------------------+
Table 7: NEIGHBOR_DATA TLV definition
Rogge Expires May 9, 2013 [Page 35]
Internet-Draft Stateless RFC5444-DLEP November 2012
12. Interface Update Order
The Interface Update Order is sent by DLEP-radios in regular
intervals, at least once every INTERFACE_UPDATE_INTERVAL.
An Interface Update Order contains the description, status and
attributes (e.g. interface metrics and statistics) of one or more
DLEP-radio interfaces. This allows the DLEP-router to receive the
whole data generated from the radio about each interface of the DLEP-
radio in an atomic way.
The Interface Update Order MUST be generated by the DLEP-radio
periodically. While it is allowed to split the Interface Updates for
multiple DLEP-radio interfaces into more than one Interface Update
Order, each Local Interface Tuple MUST be sent once in an Interface
Update Order within INTERFACE_UPDATE_INTERVAL.
The Interface Update Order includes a list of Radio Interface IDs as
address objects.
For each address, the Interface Update Order MUST contain the
RADIOIF_STATUS Address TLV, which specifies if the radio interface is
up or down.
For each address, it MAY contain one DESCRIPTION TLV with a textual
description of the radio interface.
For each address, it MAY contain one NETWORK_DATA Address TLV for
each Extension-Type, which will specify the known statistics and
metrics of the radio interface.
12.1. Interface Update Order Generation
Each DLEP-radio MUST generate Interface Update Orders according to
the specification in this section.
Define interface_set as a subset of the Local Interface Set, which
MUST contain at least one Local Interface Tuple.
Each Interface Update Order MUST contain the following additional
elements:
o A Message TLV with Type := ORDER and Value := INTERFACE_UPDATE.
o A Message TLV with Type := VALIDITY_TIME (as specified in
[RFC5497]) with Value := INTERFACE_UPDATE_HOLD_TIME (encoded as
specified in [RFC5497]).
Rogge Expires May 9, 2013 [Page 36]
Internet-Draft Stateless RFC5444-DLEP November 2012
o For each Local Interface Tuple in interface_set, add
LI_radio_interface_id as an address object (as defined in
[RFC5444]) and apply the following steps:
1. If LI_description is not NONE, add an Address TLV with Type :=
DESCRIPTION and Value := LI_description.
2. Add an Address TLV with Type := RADIOIF_STATUS. If there is
an Interface Configuration Tuple with IC_radio_interface_id =
LI_radio_interface_id, set Value := IC_radio_status.
Otherwise, set Value := LI_default_status.
3. For each Interface Data Tuple with ID_radio_interface_id =
LI_radio_interface_id, add an Address TLV with Type :=
NETWORK_DATA, Extension Type := ID_data_type and Value :=
ID_data_value.
12.2. Interface Update Order Processing
An Interface Update Order is processed on the DLEP-router as follows:
1. Define validity_time as the Value of the Message TLV with Type =
VALIDITY_TIME.
2. For each address object interface_id that has an Address TLV with
Type = RADIOIF_STATUS,
1. Define interface_status as the Value of the Address TLV with
Type = RADIOIF_STATUS.
2. If there is a Discovered Interface Tuple with
DI_radio_interface_id = interface_id, remove it (there should
be a maximum of one such tuples).
3. Add a Discovered Interface Tuple with:
+ DI_radio_interface_id := interface_id.
+ DI_radio_status := interface_status.
+ DI_description := EMPTY.
+ DI_time := current_time + validity_time.
4. If there is an Address TLV with Type = DESCRIPTION, set
DI_description := TLV-Value.
Rogge Expires May 9, 2013 [Page 37]
Internet-Draft Stateless RFC5444-DLEP November 2012
5. Remove all Network Interface Data Tuples with
NID_radio_interface_id = interface_id.
6. For each Address TLV with Type = NETWORK_DATA, add a Network
Interface Data Tuple with:
+ NID_radio_interface_id := interface_id.
+ NID_data_type := TLV Extension Type.
+ NID_data_value := TLV Value.
+ NID_time := current_time + validity_time.
Rogge Expires May 9, 2013 [Page 38]
Internet-Draft Stateless RFC5444-DLEP November 2012
13. Local Destination Order
If the Local Destination Set is not empty, the Local Destination
Order MUST be sent by DLEP-radios in regular intervals, at least once
every LOCAL_DESTINATION_INTERVAL.
A Local Destination Order contains the IP-prefixes of a DLEP-radio
interface's locally configured Destination. This allows the DLEP-
router to check the configuration of the DLEP-radio interfaces.
While it is allowed to split the Local Destination Order for multiple
destinations into more than one Local Destination Order, each Local
Destination Tuple must be contained once in a Local Destination Order
within LOCAL_DESTINATION_INTERVAL.
The Local Destination Order includes a list of local Destination MAC-
addresses as address objects.
For each address, the Local Destination Order MUST contain one
ADD_ADDRESS Address TLV of Extension-Type := MAC with a single
address. This specifies the Radio Interface ID of the local
Destination.
For each address, it MAY contain one ADD_ADDRESS Address TLV of
Extension-Type := IPV4_PREFIX with one or more prefix. This
specifies the IP-prefixes of the local Destination.
For each address, it MAY contain one ADD_ADDRESS Address TLV of
Extension-Type := IPV6_PREFIX with one or more prefix. This
specifies the IP-prefixes of the local Destination.
13.1. Local Destination Order Generation
Each DLEP-radio MUST generate Local Destination Orders according to
the specification in this section.
Define destination_set a subset of the Local Destination Set, which
MUST contain at least one Local Destination Tuple.
Each Local Destination Order MUST contain the following additional
elements:
o A Message TLV with Type := ORDER and Value := LOCAL_DESTINATION.
o A Message TLV with Type := VALIDITY_TIME (as specified in
[RFC5497]) with Value := LOCAL_DESTINATION_HOLD_TIME (encoded as
specified in [RFC5497]).
Rogge Expires May 9, 2013 [Page 39]
Internet-Draft Stateless RFC5444-DLEP November 2012
o For each Local Destination Tuple in destination_set, add
LD_mac_address as an address object (as defined in [RFC5444]) and
apply the following steps:
1. Add an Address TLV with Type := ADD_ADDRESS, Extension Type :=
MAC and Value := LD_radio_interface_id.
2. If LD_ipv4_prefixes is not empty, add an Address TLV with Type
:= ADD_ADDRESS, Extension Type := IPV4_PREFIX and Value :=
LD_ipv4_prefixes.
3. If LD_ipv6_prefixes is not empty, add an Address TLV with Type
:= ADD_ADDRESS, Extension Type := IPV6_PREFIX and Value :=
LD_ipv6_prefixes.
13.2. Local Destination Order Processing
A Local Destination Order is processed in the DLEP-router as follows:
1. Define validity_time as the Value of the Message TLV with Type =
VALIDITY_TIME.
2. For each address object destination_mac that has an Address TLV
with Type = ADD_ADDRESS and Extension Type = MAC,
1. Define interface_id as the Value of the Address TLV with Type
= ADD_ADDRESS and Extension Type = MAC.
2. If there is a Network Local Destination Tuple with
NLD_radio_interface_id = interface_id and NLD_mac_address =
destination_mac, remove it (there should be a maximum of one
such tuples).
3. Add a Network Local Destination Tuple with:
+ NLD_radio_interface_id := interface_id.
+ NLD_mac_address := destination_mac.
+ NLD_ipv4_prefixes := EMPTY.
+ NLD_ipv6_prefixes := EMPTY.
+ NLD_time := current_time + validity_time.
4. If there is an Address TLV with Type = ADD_ADDRESS and
Extension Type = IPV4_PREFIX, set NLD_ipv4_prefixes:= TLV-
Value.
Rogge Expires May 9, 2013 [Page 40]
Internet-Draft Stateless RFC5444-DLEP November 2012
5. If there is an Address TLV with Type = ADD_ADDRESS and
Extension Type = IPV6_PREFIX, set NLD_ipv6_prefixes:= TLV-
Value.
Rogge Expires May 9, 2013 [Page 41]
Internet-Draft Stateless RFC5444-DLEP November 2012
14. Neighbor Update Order
If either the Interface Neighbor Set or the Lost Neighbor Set are not
empty, the Neighbor Update Order MUST be sent by DLEP-radios in
regular intervals, at least once every NEIGHBOR_UPDATE_INTERVAL.
A Neighbor Update Order contains the prefixes, status, and attributes
(e.g. radio metrics and statistics) of one or more Neighbors of a
single DLEP-radio interface. This allows the DLEP-router to receive
the whole data about each Neighbor of the DLEP-radio interface in an
atomic way.
While it is allowed to split the Neighbor Update Order for multiple
Neighbors into more than one Neighbor Update Order, each Neighbor
Interface Tuple and Lost Neighbor Tuple must be contained once in an
Neighbor Update Order within NEIGHBOR_UPDATE_INTERVAL.
The Neighbor Update Order includes the Radio Interface ID of the
local radio interface as the originator address.
The Neighbor Update Order includes a list of Neighbor MAC-addresses
as address objects.
For each address, the Neighbor Update Order MUST contain the
RADIOIF_STATUS Address TLV, which specifies if the neighbors radio
interface is UP or DOWN.
For each address, it MAY contain one ADD_ADDRESS Address TLV of
Extension-Type := MAC with a single address. This specifies the
neighbor's Radio Interface ID.
For each address, it MAY contain one ADD_ADDRESS Address TLV of
Extension-Type := IPV4_PREFIX with one or more prefix. This
specifies the IP-prefixes of the neighbor.
For each address, it MAY contain one ADD_ADDRESS Address TLV of
Extension-Type := IPV6_PREFIX with one or more prefix. This
specifies the IP-prefixes of the neighbor.
For each address, it MAY contain one NETWORK_DATA Address TLV for
each Extension-Type, which will specify the known statistics and
metrics of the neighbor.
14.1. Neighbor Update Order Generation
Each DLEP-radio MUST generate Neighbor Update Orders according to the
specification in this section, each for a single DLEP-radio
interface, which means for a single Local Interface Tuple.
Rogge Expires May 9, 2013 [Page 42]
Internet-Draft Stateless RFC5444-DLEP November 2012
Define neighbor_set a subset of the Interface Neighbor Set with all
tuples IN_radio_interface_id = LI_radio_interface_id.
Define lost_neighbor_set a subset of the Lost Neighbor Set with all
tuples LN_radio_interface_id = LI_radio_interface_id.
neighbor_set and lost_neighbor_set MUST NOT be both empty.
Each Neighbor Update Order MUST contain the following additional
elements:
o LI_radio_interface_id as the originator address.
o A Message TLV with Type := ORDER and Value := NEIGHBOR_UPDATE.
o A Message TLV with Type := VALIDITY_TIME (as specified in
[RFC5497]) with Value := NEIGHBOR_UPDATE_HOLD_TIME (encoded as
specified in [RFC5497]).
o For each Interface Neighbor Tuple in neighbor_set, add
IN_mac_address as an address object (as defined in [RFC5444]) and
apply the following steps:
1. Add an Address TLV with Type := RADIOIF_STATUS and Value :=
UP.
2. If IN_neighbor_interface_id != NONE, add an Address TLV with
Type := ADD_ADDRESS, Type Extension := MAC and Value :=
IN_neighbor_interface_id.
3. If IN_ipv4_prefixes is not EMPTY, add an Address TLV with Type
:= ADD_ADDRESS, Type Extension := IPV4_PREFIX and Value :=
IN_ipv4_prefixes.
4. If IN_ipv6_prefixes is not EMPTY, add an Address TLV with Type
:= ADD_ADDRESS, Type Extension := IPV6_PREFIX and Value :=
IN_ipv6_prefixes.
o For each Lost Neighbor Tuple in lost_neighbor_set, add
LN_mac_address as an address object and apply the following steps:
1. Add an Address TLV with Type := RADIOIF_STATUS and Value :=
DOWN.
2. If LN_neighbor_interface_id != NONE, add an Address TLV with
Type := ADD_ADDRESS, Type Extension := MAC and Value :=
LN_neighbor_interface_id.
Rogge Expires May 9, 2013 [Page 43]
Internet-Draft Stateless RFC5444-DLEP November 2012
14.2. Neighbor Update Order Discarding
If a Neighbor Update Order has no Originator Address, it MUST be
dropped without further processing.
14.3. Neighbor Update Order Processing
A Neighbor Update Order is processed as follows:
1. Define interface_id as the Originator Address of the Neighbor
Update Order.
2. Define validity_time as the Value of the Message TLV with Type =
VALIDITY_TIME.
3. For each address object neighbor_mac that has an Address TLV with
Type = RADIOIF_STATUS:
1. Define neighbor_status as the Value of the Address TLV with
Type = RADIOIF_STATUS.
2. If there is an Address TLV with Type = ADD_ADDRESS and
Extension Type = MAC, define neighbor_radio_id as the Value
of the Address TLV. If not, define neighbor_radio_id as
NONE.
3. If there is a Network Neighbor Tuple with
NN_radio_interface_id = interface_id AND
NN_neighbor_interface_id = neighbor_radio_id AND
NN_mac_address = neighbor_mac, remove it (there should be a
maximum of one).
4. Add a Network Neighbor Tuple with:
+ NN_radio_interface_id := interface_id.
+ NN_neighbor_interface_id := neighbor_radio_id.
+ NN_status := neighbor_status.
+ NN_mac_address := neighbor_mac.
+ NN_ipv4_prefixes := EMPTY.
+ NN_ipv6_prefixes := EMPTY.
+ NN_time := current_time + validity_time.
Rogge Expires May 9, 2013 [Page 44]
Internet-Draft Stateless RFC5444-DLEP November 2012
5. If there is an Address TLV with Type = ADD_ADDRESS and
Extension Type = IPV4_PREFIX, set NN_ipv4_prefixes := TLV-
Value.
6. If there is an Address TLV with Type = ADD_ADDRESS and
Extension Type = IPV6_PREFIX, set NN_ipv6_prefixes := TLV-
Value.
7. Remove all Network Neighbor Data Tuples with
NND_radio_interface_id = interface_id AND
NND_neighbor_interface_id = neighbor_radio_id AND
NND_mac_address = neighbor_mac.
8. For each Address TLV with Type = NEIGHBOR_DATA, add a Network
Neighbor Data Tuple with:
+ NND_radio_interface_id := interface_id.
+ NND_neighbor_interface_id = neighbor_radio_id.
+ NND_mac_address := neighbor_mac.
+ NND_data_type := TLV Extension Type.
+ NND_data_value := TLV Value.
+ NND_time := current_time + validity_time.
Rogge Expires May 9, 2013 [Page 45]
Internet-Draft Stateless RFC5444-DLEP November 2012
15. Setup Radio Order
If the Radio Interface Configuration Set is not empty, the Setup
Radio Order MUST be sent by DLEP-routers in regular intervals, at
least once every SETUP_RADIO_INTERVAL.
A Setup Radio Order contains the status of DLEP-radio interfaces to
be configured.
While it is allowed to split the Setup Radio Order for multiple radio
interfaces into more than one Setup Radio Order, each Radio Interface
Configuration Tuple must be contained once in a Setup Radio Order
within SETUP_RADIO_INTERVAL.
The Setup Radio Order includes a list of Radio Interface ID's as
address objects.
For each address, the Setup Radio Order MUST contain one
RADIOIF_STATUS Address TLV to specify the radio interface status.
15.1. Setup Radio Order Generation
Each DLEP-router MUST generate Setup Radio Orders according to the
specification in this section.
Define interface_set a subset of the Radio Interface Configuration
Set, which MUST contain at least one Radio Interface Configuration
Tuple.
Each Setup Radio Order MUST contain the following additional
elements:
o A Message TLV with Type := ORDER and Value := SETUP_RADIO.
o A Message TLV with Type := VALIDITY_TIME (as specified in
[RFC5497]) with Value := SETUP_RADIO_HOLD_TIME (encoded as
specified in [RFC5497]).
o For each Radio Interface Configuration Tuple in interface_set, add
RIC_radio_interface_id as an address object (as defined in
[RFC5444]) and apply the following steps:
1. Add an Address TLV with Type := RADIOIF_STATUS and Value :=
RIC_status.
Rogge Expires May 9, 2013 [Page 46]
Internet-Draft Stateless RFC5444-DLEP November 2012
15.2. Setup Radio Order Processing
A Setup Radio is processed in the DLEP-router as follows:
1. Define validity_time as the Value of the Message TLV with Type =
VALIDITY_TIME.
2. For each address object interface_id that has an Address TLV with
Type = RADIOIF_STATUS,
1. Define interface_status as the Value of the Address TLV with
Type = RADIOIF_STATUS.
2. If there is an Interface Configuration Tuple with
IC_radio_interface_id = interface_id, remove it (there should
be a maximum of one such tuples).
3. Add an Interface Configuration Tuple with:
+ IC_radio_interface_id := interface_id.
+ IC_radio_status := interface_status.
+ IC_time := current_time + validity_time.
Rogge Expires May 9, 2013 [Page 47]
Internet-Draft Stateless RFC5444-DLEP November 2012
16. Setup Destination Order
If the Destination Configuration Set is not empty, the Setup
Destination Order MUST be sent by DLEP-routers in regular intervals,
at least once every SETUP_DESTINATION_INTERVAL.
A Setup Destination Order contains the IP-prefixes and Radio
Interface ID of the local Destinations to be configured on a DLEP-
radio interface.
While it is allowed to split the Setup Destination Order for multiple
destinations into more than one Setup Destination Order, each
Destination Configuration Tuple MUST be contained once in a Setup
Destination Order within SETUP_DESTINATION_INTERVAL.
The Setup Destination Order includes a list of to be configured local
Destination MAC-addresses as address objects.
For each address, the Setup Destination Order MUST contain one
ADD_ADDRESS Address TLV of Extension-Type := MAC with a single
address. This specifies the Radio Interface ID of the local
Destination.
For each address, it MAY contain one ADD_ADDRESS Address TLV of
Extension-Type := IPV4_PREFIX with one or more prefix. This
specifies the IP-prefixes of the local Destination.
For each address, it MAY contain one ADD_ADDRESS Address TLV of
Extension-Type := IPV6_PREFIX with one or more prefix. This
specifies the IP-prefixes of the local Destination.
16.1. Setup Destination Order Generation
Each DLEP-router MUST generate Setup Destination Orders according to
the specification in this section.
Define destination_set a subset of the Destination Configuration Set,
which MUST contain at least one Destination Configuration Tuple.
Each Setup Destination Order MUST contain the following additional
elements:
o A Message TLV with Type := ORDER and Value := SETUP_DESTINATION.
o A Message TLV with Type := VALIDITY_TIME (as specified in
[RFC5497]) with Value := SETUP_DESTINATION_HOLD_TIME (encoded as
specified in [RFC5497]).
Rogge Expires May 9, 2013 [Page 48]
Internet-Draft Stateless RFC5444-DLEP November 2012
o For each Destination Configuration Tuple in destination_set, add
DC_mac_address as an address object (as defined in [RFC5444]) and
apply the following steps:
1. Add an Address TLV with Type := ADD_ADDRESS, Extension Type :=
MAC and Value := DC_radio_interface_id.
2. If DC_ipv4_prefixes is not empty, add an Address TLV with Type
:= ADD_ADDRESS, Extension Type := IPV4_PREFIX and Value :=
DC_ipv4_prefixes.
3. If DC_ipv6_prefixes is not empty, add an Address TLV with Type
:= ADD_ADDRESS, Extension Type := IPV6_PREFIX and Value :=
DC_ipv6_prefixes.
16.2. Setup Destination Order Processing
A Setup Destination Order is processed in the DLEP-radio as follows:
1. Define validity_time as the Value of the Message TLV with Type =
VALIDITY_TIME.
2. For each address object destination_mac that has an Address TLV
with Type = ADD_ADDRESS and Extension Type = MAC,
1. Define interface_id as the Value of the Address TLV with Type
= ADD_ADDRESS and Extension Type = MAC.
2. If there is a Local Destination Tuple with
LD_radio_interface_id = interface_id and LD_mac_address =
destination_mac, remove it (there should be a maximum of one
tuple).
3. Add a Local Destination Tuple with:
+ LD_radio_interface_id := interface_id.
+ LD_mac_address := destination_mac.
+ LD_ipv4_prefixes := EMPTY.
+ LD_ipv6_prefixes := EMPTY.
+ LD_time := current_time + validity_time.
4. If there is an Address TLV with Type = ADD_ADDRESS and
Extension Type = IPV4_PREFIX, set LD_ipv4_prefixes:= TLV-
Value.
Rogge Expires May 9, 2013 [Page 49]
Internet-Draft Stateless RFC5444-DLEP November 2012
5. If there is an Address TLV with Type = ADD_ADDRESS and
Extension Type = IPV6_PREFIX, set LD_ipv6_prefixes:= TLV-
Value.
Rogge Expires May 9, 2013 [Page 50]
Internet-Draft Stateless RFC5444-DLEP November 2012
17. IANA Considerations
This specification defines one Message Type, which MUST be allocated
from the "Message Types" repository of [RFC5444], 1 Message TLV
Types, which MUST be allocated from the "Message TLV Types"
repository of [RFC5444], and 5 Address Block TLV Types, which MUST be
allocated from the "Address Block TLV Types" repository of [RFC5444].
17.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].
17.2. Message Types
This specification defines one Message Type, to be allocated from the
0-223 range of the "Message Types" namespace defined in [RFC5444], as
specified in Table 8.
+------+--------------------------------------+
| Type | Description |
+------+--------------------------------------+
| TBD1 | DLEP: Dynamic link exchange protocol |
+------+--------------------------------------+
Table 8: Message type assignment.
17.3. Message-Type-Specific TLV Type Registries
IANA is requested to create a registry for Message-Type-specific
Message TLVs for DLEP messages, in accordance with Section 6.2.1 of
[RFC5444], and with initial assignments and allocation policies as
specified in Table 9.
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 128-223 | Unassigned | Expert Review |
+---------+-------------+-------------------+
Table 9: DLEP Message-Type-specific Message TLV Type
IANA is requested to create a registry for Message-Type-specific
Address Block TLVs for DLEP messages, in accordance with Section
6.2.1 of [RFC5444], and with initial assignments and allocation
policies as specified in Table 10.
Rogge Expires May 9, 2013 [Page 51]
Internet-Draft Stateless RFC5444-DLEP November 2012
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 128-223 | Unassigned | Expert Review |
+---------+-------------+-------------------+
Table 10: DLEP Message-Type-specific Address Block TLV Types
17.4. Message TLV Types
TODO: allocate ORDER (message specific?)
17.5. Address Block TLV Types
TODO: allocate RADIOIF_STATUS (message specific?)
TODO: allocate DESCRIPTION (message specific?)
TODO: allocate ADD_ADDRESS (message specific?)
TODO: allocate NETWORK_DATA (message specific?)
TODO: allocate NEIGHBOR_DATA (message specific?)
Rogge Expires May 9, 2013 [Page 52]
Internet-Draft Stateless RFC5444-DLEP November 2012
18. Further work
There are two aspects of [dlep02] that have not been part of this
document:
o Configuration of the radio channel.
o Managing of traffic credit tokens.
The author of this documents has the opinion that there is also
demand for a discussion on the following questions:
o What is the exact difference between Latency and Expected-
Forwarding-Delay and how shall both of them be defined?
o What are the full consequences of multicast MAC-addresses as
destinations?
o Is it possible to allow multiple devices (DLEP-routers and end-
devices) connected with an Ethernet Switch to a DLEP-radio?
Rogge Expires May 9, 2013 [Page 53]
Internet-Draft Stateless RFC5444-DLEP November 2012
19. Security Considerations
Currently, this protocol does not specify any special security
measures.
Rogge Expires May 9, 2013 [Page 54]
Internet-Draft Stateless RFC5444-DLEP November 2012
20. References
20.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
Considerations in Mobile Ad Hoc Networks (MANETs)",
RFC 5148, February 2008.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized Mobile Ad Hoc Network (MANET) Packet/Message
Format", RFC 5444, February 2009.
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value
Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
March 2009.
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011.
[RFC6622] Clausen, T. and U. Herberg, "Integrity Check Value and
Timestamp TLV Definitions for Mobile Ad Hoc Networks
(MANETs)", RFC 6622, July 2012.
20.2. Informative References
[dlep02] Ratliff, S., Berry, B., Harrison, G., Jury, S., and D.
Satterwhite, "Dynamic Link Exchange Protocol (DLEP)",
draft-ietf-manet-dlep-02 (work in progress),
February 2012.
[olsrv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol version 2",
draft-ietf-manet-olsrv2-15 (work in progress),
September 2009.
Rogge Expires May 9, 2013 [Page 55]
Internet-Draft Stateless RFC5444-DLEP November 2012
Appendix A. RFC5444-DLEP Message Examples
DLEP messages are instances of [RFC5444] messages, and this protocol
supports any combination of message header options and address
encodings, enabled by [RFC5444] that convey the required information.
As a consequence, there is no single way to represent how all DLEP
messages look.
A.1. Interface Update Order Example
The Interface Update Order is used by DLEP-radios to announce their
radio interfaces. The status of the interface, an optional
description and a number of optional network based attributes can be
attached to each radio interface.
In the following example that is depicted in Figure 2, we see a
simple Interface Update Order of a DLEP-radio with a single interface
which is up and there are no further attributes set.
The DLEP message's four bit Message Flags (MF) field has value 0,
indicating that no optional message header fields are present. Its
four bit Message Address Length (MAL) field has value 5, indicating
addresses in the message have a length of six octets, here being
Radio Interface IDs. The overall message length is 28 octets.
The message contains a Message TLV Block with content length 8 octets
containing two Message TLVs, of types VALIDITY_TIME and ORDER. Each
uses a Message TLV with Flags octet (MTLVF) value 16, indicating that
each has a Value, and each has a Value Length of 1 octet. The Value
included in the first TLV is a time code (as defined in [RFC5497])
representing the parameters INTERFACE_UPDATE_HOLD_TIME. The Value
included in the second TLV is a Order ID, respectively
INTERFACE_UPDATE (see Section 11.2).
The message has a single Address Block containing one address. The
Address Block Flags octet (ABF) value 0 indicates an no address Head,
no address Tail, and no address prefixes. The Address Block is
followed by the full Radio Interface ID.
The following Address Block TLV Block (content length 4 octets)
includes one Address Block TLV. The TLV is a RADIOIF_STATUS Address
Block TLV with Flags octet (ATLVF) value 16, which indicates that a
single address, with index 0 (implicit) belongs to an interface with
the status UP (the one octet Value UP indicates this).
Rogge Expires May 9, 2013 [Page 56]
Internet-Draft Stateless RFC5444-DLEP November 2012
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLEP | MF=0 | MAL=5 | Message Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message TLV Block Length = 8 | VALIDITY_TIME | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Time) | ORDER | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | INTERF.UPD. | Num Addrs = 1 | ABF = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIID 1 Byte 1 | RIID 1 Byte 2 | RIID 1 Byte 3 | RIID 1 Byte 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIID 1 Byte 5 | RIID 1 Byte 6 | Address TLV Block Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RADIOIF_STATUS| ATLVF = 16 | Value Len = 1 | VALUE (UP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example of a simple Interface Update Order.
Figure 2
The second example (see Figure 3) is a more complex Interface Update
Order of a DLEP-radio with two interface (first up, second down),
each with a 4 character description (both different) and the
supported data-rate (both have the same data rate). The two Radio
Interface IDs have the common header HEAD_1/HEAD_2/HEAD_3.
The DLEP message's four bit Message Flags (MF) field has value 0,
indicating that no optional message header fields are present. Its
four bit Message Address Length (MAL) field has value 5, indicating
addresses in the message have a length of six octets, here being
Radio Interface IDs. The overall message length is 56 octets.
The message contains a Message TLV Block with content length 8 octets
containing two Message TLVs, of types VALIDITY_TIME and ORDER. Each
uses a Message TLV with Flags octet (MTLVF) value 16, indicating that
each has a Value, and each has a Value Length of 1 octet. The Value
included in the first TLV is a time code (as defined in [RFC5497])
representing the parameters INTERFACE_UPDATE_HOLD_TIME. The Value
included in the second TLV is a Order ID, respectively
INTERFACE_UPDATE (see Section 11.2).
The message has a single Address Block containing two address. The
Address Block Flags octet (ABF) value 128, indicates an address Head,
but no address Tail and Prefixes. The Head Length of 3 octets
indicates address Mid sections of 3 octets each.
Rogge Expires May 9, 2013 [Page 57]
Internet-Draft Stateless RFC5444-DLEP November 2012
The following Address Block TLV Block (content length 28 octets)
includes three Address Block TLVs. The first TLV is a RADIOIF_STATUS
Address Block TLV with Flags octet (ATLVF) value 20, which indicates
that it contains a value for each of the addresses (UP/DOWN). The
second TLV is a DESCRIPTION Address Block TLV with Flags octet
(ATLVF) value 20 too, and a four byte value with the descriptions for
each address. The last TLV is a NETWORK_DATA TLV with Flags octet
(ATLVF) value 144, which indicates an TLV extension type and a single
value for both addresses.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLEP | MF=0 | MAL=5 | Message Length = 56 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message TLV Block Length = 8 | VALIDITY_TIME | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Time) | ORDER | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | INTERF.UPD. | Num Addrs = 2 | ABF = 128 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head L. = 3 | HEAD 1 | HEAD 2 | HEAD 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIID 1 Byte 4 | RIID 1 Byte 5 | RIID 1 Byte 6 | RIID 2 Byte 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIID 2 Byte 5 | RIID 2 Byte 6 | Address TLV Block Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RADIOIF_STATUS| ATLVF = 20 | Value Len = 2 | VALUE (UP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VALUE (DOWN) | DESCRIPTION | ATLVF = 20 | Value Len = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Description Interface 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Description Interface 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NETWORK_DATA | ATLVF = 144 | SUPP. RATES | Value Len = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Supported Data Rate Part 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Supported Data Rate Part 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example of a simple Interface Update Order.
Figure 3
Rogge Expires May 9, 2013 [Page 58]
Internet-Draft Stateless RFC5444-DLEP November 2012
A.2. Neighbor Update Order Example
The Neighbor Update Order is used by DLEP-radios to announce
neighbors of their radio interfaces. The status of the neighbor, the
neighbors IP addresses and a number of metrics and statistics can be
attached to each neighbor.
In the following example that is depicted in Figure 4, we see a
Neiggbor Update Order of a DLEP-radio with a four neighbors, three of
them up and one down. All of them have their radio interface_id, the
three active neighbors have a relative link quality and the second
neighbor also has an IP address set. The four Neighbor MAC-addresses
have the common header HEAD_1/HEAD_2/HEAD_3.
The DLEP message's four bit Message Flags (MF) field has value 128,
indicating that an originator address message header field is
present. Its four bit Message Address Length (MAL) field has value
5, indicating addresses in the message have a length of six octets,
here being MAC-addresses. The overall message length is 83 octets.
The message contains a Message TLV Block with content length 8 octets
containing two Message TLVs, of types VALIDITY_TIME and ORDER. Each
uses a Message TLV with Flags octet (MTLVF) value 16, indicating that
each has a Value, and each has a Value Length of 1 octet. The Value
included in the first TLV is a time code (as defined in [RFC5497])
representing the parameters NEIGHBOR_UPDATE_HOLD_TIME. The Value
included in the second TLV is a Order ID, respectively
NEIGHBOR_UPDATE (see Section 11.2).
The message has a single Address Block containing three addresses.
The Address Block Flags octet (ABF) value 128 indicates an address
Head, but no address Tail and prefixes. The Head Length of 3 octets
indicates address Mid sections of 3 octets each.
The following Address Block TLV Block (content length 42 octets)
includes three Address Block TLVs. The first TLV is a RADIOIF_STATUS
Address Block TLV with Flags octet (ATLVF) value 20, which indicates
that each address has a value of its own (two times UP, once DOWN).
The second TLV is an ADD_ADDRESS Address Block TLV with Flags octet
(ATLVF) value 148, which indicates a TLV Type Extension (MAC) and a
value of its own. Its followed by three neighbor Radio Interface
IDs, each six octets. The third TLV is a NEIGHBOR_DATA Address Block
TLV with Flag octet (ATLVF) value 180, which indicates a TLV Type
Extension (RELATIVE_LQ) and a value for each of the first two
addresses. The last TLV is an ADD_ADDRESS Address Block TLV with
Flags octet (ATLVF) 208, which indicates a TLV Type Extension
(IPV4_PREFIX) for a the second address.
Rogge Expires May 9, 2013 [Page 59]
Internet-Draft Stateless RFC5444-DLEP November 2012
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLEP | MF=128| MAL=5 | Message Length = 83 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Radio Interface ID Part 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local R. Interface ID Part 2 | Message TLV Block Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VALIDITY_TIME | MTLVF = 16 | Value Len = 1 | Value (Time) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ORDER | MTLVF = 16 | Value Len = 1 | NEIGHB.UPD. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Addrs = 3 | ABF = 128 | Head L. = 3 | HEAD 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HEAD 2 | HEAD 3 | MAC 1 Byte 4 | MAC 1 Byte 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC 1 Byte 6 | MAC 2 Byte 4 | MAC 2 Byte 5 | MAC 2 Byte 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC 3 Byte 4 | MAC 3 Byte 5 | MAC 3 Byte 6 | Address TLV - |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block L. = 42 | RADIOIF_STATUS| MTLVF = 20 | Value Len = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VALUE (UP) | VALUE (UP) | VALUE (DOWN) | ADD_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATLVF = 148 | MAC | Value L. = 18 | N1 RIID B.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| N1 RIID B.2 | N1 RIID B.3 | N1 RIID B.4 | N1 RIID B.5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| N1 RIID B.6 | N2 RIID B.1 | N2 RIID B.2 | N2 RIID B.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| N2 RIID B.4 | N2 RIID B.5 | N2 RIID B.6 | N3 RIID B.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| N3 RIID B.2 | N3 RIID B.3 | N3 RIID B.4 | N3 RIID B.5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| N3 RIID B.6 | NEIGHBOR_DATA | ATLVF = 180 | RELATIVE_LQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| index-start=0 | index-end=1 | Value Len = 2 | REL_LQ 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| REL_LQ 2 | ADD_ADDRESS | ATLVF = 208 | IPV4_PREFIX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| index-start=1 | Value Len = 5 | IPaddr Byte 1 | IPaddr Byte 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPaddr Byte 3 | IPaddr Byte 4 | IPaddr Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example of an Neighbor Update Order.
Rogge Expires May 9, 2013 [Page 60]
Internet-Draft Stateless RFC5444-DLEP November 2012
Figure 4
A.3. Setup Radio Order Example
The Setup Router Order is used by DLEP-routers to set the status of
the DLEP-radios interfaces.
In the following example that is depicted in Figure 5, we see a Setup
Router Order for a DLEP-radio with two interfaces. Both of them are
configured to status UP.
The DLEP message's four bit Message Flags (MF) field has value 0,
indicating that no optional message header fields are present. Its
four bit Message Address Length (MAL) field has value 5, indicating
addresses in the message have a length of six octets, here being
Radio Interface IDs. The overall message length is 32 octets.
The message contains a Message TLV Block with content length 8 octets
containing two Message TLVs, of types VALIDITY_TIME and ORDER. Each
uses a Message TLV with Flags octet (MTLVF) value 16, indicating that
each has a Value, and each has a Value Length of 1 octet. The Value
included in the first TLV is a time code (as defined in [RFC5497])
representing the parameters SETUP_RADIO_HOLD_TIME. The Value
included in the second TLV is a Order ID, respectively SETUP_RADIO
(see Section 11.2).
The message has a single Address Block containing two addresses. The
Address Block Flags octet (ABF) value 128 indicates an address Head,
but no address Tail and prefixes. The Head Length of 3 octets
indicates address Mid sections of 3 octets each.
The following Address Block TLV Block (content length 4 octets)
includes one Address Block TLV. The TLV is a RADIOIF_STATUS Address
Block TLV with Flags octet (ATLVF) value 16, which indicates the same
value (UP) for both addresses.
Rogge Expires May 9, 2013 [Page 61]
Internet-Draft Stateless RFC5444-DLEP November 2012
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLEP | MF=0 | MAL=5 | Message Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message TLV Block Length = 8 | VALIDITY_TIME | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Time) | ORDER | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | SETUP_RADIO | Num Addrs = 2 | ABF = 128 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head L. = 3 | HEAD 1 | HEAD 2 | HEAD 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIID 1 Byte 4 | RIID 1 Byte 5 | RIID 1 Byte 6 | RIID 2 Byte 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIID 2 Byte 5 | RIID 2 Byte 6 | Address TLV Block Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RADIOIF_STATUS| ATLVF = 16 | Value Len = 1 | VALUE (UP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example of an Setup Router Order.
Figure 5
A.4. Setup Destination Order
The Setup Destination Order is used by DLEP-routers to set its local
IP addresses for a destinationon the DLEP-radios interfaces.
In the following example that is depicted in Figure 6, we see a Setup
Destination Order for a DLEP-radio with one interfaces. The router
configures a single MAC-address with one IPv4 address and two IPv6
addresses for this interface.
The DLEP message's four bit Message Flags (MF) field has value 0,
indicating that no optional message header fields are present. Its
four bit Message Address Length (MAL) field has value 5, indicating
addresses in the message have a length of six octets, here being MAC
addresses. The overall message length is 81 octets.
The message contains a Message TLV Block with content length 8 octets
containing two Message TLVs, of types VALIDITY_TIME and ORDER. Each
uses a Message TLV with Flags octet (MTLVF) value 16, indicating that
each has a Value, and each has a Value Length of 1 octet. The Value
included in the first TLV is a time code (as defined in [RFC5497])
representing the parameters SETUP_DESTINATION_HOLD_TIME. The Value
included in the second TLV is a Order ID, respectively
SETUP_DESTINATION (see Section 11.2).
Rogge Expires May 9, 2013 [Page 62]
Internet-Draft Stateless RFC5444-DLEP November 2012
The message has a single Address Block containing one addresses. The
Address Block Flags octet (ABF) value 0 indicates an no address Head,
no address Tail, and no address prefixes. The Address Block is
followed by the full MAC-address of the Destination.
The following Address Block TLV Block (content length 57 octets)
includes three Address Block TLV. All TLVs are ADD_ADDRESS Address
Block TLVs with Flags octet (ATLVF) value 144, which indicates a TLV
Type Extension and a value. The first TLV (IPV4_PREFIX Type
Extension) contains a single IPv4 address with prefix, the second one
(IPV6_PREFIX Type Extension) contains two IPv6 addresses with prefix.
Rogge Expires May 9, 2013 [Page 63]
Internet-Draft Stateless RFC5444-DLEP November 2012
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLEP | MF=0 | MAL=5 | Message Length = 81 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message TLV Block Length = 8 | VALIDITY_TIME | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Time) | ORDER | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | SETUP_DEST. | Num Addrs = 1 | ABF = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC 1 Byte 1 | MAC 1 Byte 2 | MAC 1 Byte 3 | MAC 1 Byte 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC 1 Byte 5 | MAC 1 Byte 6 | Address TLV Block Length = 57 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ADD_ADDRESS | ATLVF = 144 | MAC | Value Len = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIID Byte 1 | RIID Byte 2 | RIID Byte 3 | RIID Byte 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIID Byte 5 | RIID Byte 6 | ADD_ADDRESS | ATLVF = 144 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV4_PREFIX | Value Len = 5 | IPv4 Byte 1 | IPv4 Byte 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Byte 1 | IPv4 Byte 1 | Prefix (32) | ADD_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATLVF = 144 | IPV6_PREFIX | Value L. = 34 | IPv6 1 Byte 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 1 Byte 2 | IPv6 1 Byte 3 | IPv6 1 Byte 4 | IPv6 1 Byte 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 1 Byte 6 | IPv6 1 Byte 7 | IPv6 1 Byte 8 | IPv6 1 Byte 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 1 B. 10 | IPv6 1 B. 11 | IPv6 1 B. 12 | IPv6 1 B. 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 1 B. 14 | IPv6 1 B. 15 | IPv6 1 B. 16 | IPV6 1 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 2 Byte 1 | IPv6 2 Byte 2 | IPv6 2 Byte 3 | IPv6 2 Byte 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 2 Byte 5 | IPv6 2 Byte 6 | IPv6 2 Byte 7 | IPv6 2 Byte 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 2 Byte 9 | IPv6 2 B. 10 | IPv6 2 B. 11 | IPv6 2 B. 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 2 B. 13 | IPv6 2 B. 14 | IPv6 2 B. 15 | IPv6 2 B. 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 2 Prefix |
+-+-+-+-+-+-+-+-+
Example of an Setup Destination Order.
Rogge Expires May 9, 2013 [Page 64]
Internet-Draft Stateless RFC5444-DLEP November 2012
Figure 6
A.5. Local Destination Order Example
The Local Destination Order looks exactly like the Setup Destination
Order, only that it is sent from the DLEP-radio to the DLEP-router.
Rogge Expires May 9, 2013 [Page 65]
Internet-Draft Stateless RFC5444-DLEP November 2012
Author's Address
Henning Rogge
Fraunhofer FKIE
Neuenahrer Strasse 20
Wachtberg 53343
Germany
Phone: +49 228 9435-961
Email: henning.rogge@fkie.fraunhofer.de
URI: http://fkie.fraunhofer.de/
Rogge Expires May 9, 2013 [Page 66]
