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]