Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-04.txt

From: Henning Rogge <[email-masked]>
Date: Tue, 2 Apr 2013 13:33:02 +0200

Hi Stan,

here is a first review of DLEP-04. I plan to start an implementation of 
this draft this month, so you will most likely get more comments during 
this.

> 3. Credits
>
>    DLEP includes an OPTIONAL credit-windowing scheme analogous to the
>    one documented in [RFC5578]. In this scheme, traffic between the
>    router and modem is treated as two unidirectional windows. This
>    document identifies these windows as the "Modem Receive Window", or
>    MRW, and the "Router Receive Window", or RRW.
>
>    If credits are used, they MUST be granted by the receiver on a given
>    window - that is, on the "Modem Receive Window" (MRW), the modem is
>    responsible for granting credits to the router, allowing it (the
>    router) to send data to the modem. Likewise, the router is
>    responsible for granting credits on the RRW, which allows the modem
>    to send data to the router.
>
>    DLEP expresses all credit data in number of octets. The total number
>    of credits on a window, and the increment to add to a grant, are
>    always expressed as a 64-bit unsigned quantity.
>
>    If used, credits are managed on a neighbor-specific basis; that is,
>    separate credit counts are maintained for each neighbor requiring the
>    service. Credits do not apply to the DLEP session that exists between
>    routers and modems.

Two questions...

first, we can have a credit window for multicast/broadcast too, right?

second, can you tell me the motivation for the Receiving Credit Window? 
I have not enough experience to argue for or against it, but it feels 
strange.

The transmission Credit Window is important to prevent a transmission 
queue on the modem increasing the delay by buffering outgoing packets of 
the router and to allow router based Quality of Service handling like 
prioritization.

But I am not sure what to do with the receiving window.

> 6. Normal Session Flow
>
>    At the start of a run, DLEP implementations (both router and modem)
>    initialize the communications path. In a UDP implementation, this
>    includes opening a socket and binding to the well-known port address
>    (TBD). Once the communications path is established, modem
>    implementations are free to issue a "Peer Discovery" message. The
>    Peer Discovery MAY be sent either to the multicast address allocated
>    for DLEP (TBD), or to a unicast address, obtained via a-priori
>    configuration.
>
>    Routers receiving a Peer Discovery message respond with a "Peer
>    Offer" signal to indicate readiness to participate in the DLEP
>
>
>
> Ratliff et al.         Expires September 26, 2013              [Page 10]
> 
> Internet-Draft                    DLEP                        March 2013
>
>
>    session. The receiver of a Peer Offer message responds with a "Peer
>    Offer ACK" message, completing discovery. While the Peer Discovery
>    message MAY be sent to the DLEP multicast address (TBD), the Peer
>    Offer, and all subsequent traffic, is sent to the unicast address
>    that originated the Peer Discovery. Once the Peer Offer signal is
>    acknowledged, both participants (router and modem) transition to the
>    "in session" state, creating a logical, stateful session between the
>    modem and the router. Subsequent DLEP signals are then processed
>    within the context of this router/modem session. In the UDP-based
>    implementation, traffic between DLEP modems and routers is correlated
>    using the UDP 4-tuple (Source Address, Source Port, Destination
>    Address, Destination Port). DLEP partners use these signals to build
>    their respective information bases regarding destinations that are
>    accessible via the modem, and link characteristics associated with
>    those destinations.

This sounds reasonable.

> 8. Generic DLEP Packet Definition
>
>    The Generic DLEP Packet consists of a sequence of TLVs. The first TLV
>    represents the signal being communicated (e.g., a "Neighbor Up", or a
>    "Peer Offer"). Subsequent TLVs contain the data items pertinent to
>    the signal (e.g., Maximum Data Rate, or Latency, etc).
>
>    The Generic DLEP Packet Definition contains the following fields:
>
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |Signal TLV Type | Length        | DLEP data items...           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       Signal               - One of the DLEP Signal TLV type values
>                              defined in this document.
>
>       Length               - The length of all of the DLEP data items
>                              associated with this signal.

I would suggest increasing the length field to 2 octets. 256 bytes might 
be not enough if someone deals with lots of metrics. The other option 
might be to leave the length problem to the transport protocol and 
assume DLEP can detect the length without putting it into its content 
(by looking at the length of the UDP packet for example).

We also need to add the sequence number field here (also 2 octets?). We 
might also need sequence number fields/TLVs for each ACK message, 
otherwise we should mention that the modem/radio and the router must use 
"stop and wait" to transmit packets to each other.

> 9. DLEP Data Items
>
>    As mentioned earlier, DLEP protocol messages are transported as a
>    collection of TLVs. The first TLV present in a DLEP message MUST be
>    one of the Signal TLVs, documented in section [INSERT REFERENCE
>    HERE]. The signals are followed by one or more data items, indicating
>    the specific changes that need to be instantiated in the receiver's
>    information base.

Missing reference.

> 9.10  Expected Forwarding Time
>
>    The Expected Forwarding Time (EFT) TLV is is an OPTIONAL data item.
>    If supported, it MAY be used in Neighbor Up, Neighbor Update, Peer
>    Discovery, and Peer Update messages to indicate the typical latency
>    between the arrival of a given packet at the transmitting device and
>    the reception of the packet at the other end of the link. EFT
>    combines transmission time, idle time, waiting time, freezing time,
>    and queuing time to the degree that those values are meaningful to a
>    given transmission medium.
>
>    The Expected Forwarding Time TLV contains the following fields:
>
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |TLV Type =TBD  |Length = 4     |           EFT (ms)            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |            EFT (ms)           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    TLV Type    -  TBD
>
>    Length      -  4
>
>    EFT         -  A 32-bit unsigned number, representing the expected
>                   forwarding time, in milliseconds, on the link.
>
>
> 9.11  Latency
>
>    The Latency TLV is an OPTIONAL data item. If supported, it is used in
>    Neighbor Up, Neighbor Update, Peer Discovery, Peer Update, Link
>    Characteristics Request, and Link Characteristics ACK messages to
>    indicate the amount of latency on the link, or in the case of the
>    Link Characteristics Request, to indicate the maximum latency
>    required on the link.
>
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |TLV Type =TBD  |Length = 2     |        Latency (ms)           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    TLV Type    -  TBD
>
>    Length      -  2

Why can the EFT by much longer than the Latency? It might make sense to 
give both fields a 4 octet value

> 9.12  Resources (Receive)
>
>    The Receive Resources TLV is an OPTIONAL data item. If supported, it
>    is used in Neighbor Up, Neighbor Update, Peer Discovery, Peer Update,
>    and Link Characteristics ACK messages to indicate a percentage (0-
>    100) amount of resources (e.g. battery power), committed to receiving
>    data, remaining on the originating peer.

> 9.13  Resources (Transmit)
>
>    The Transmit Resources TLV is an OPTIONAL data item. If supported, it
>    is used in Neighbor Up, Neighbor Update, Peer Discovery, Peer Update,
>    and Link Characteristics ACK messages to indicate a percentage (0-
>    100) amount of resources (e.g. battery power), committed to
>    transmitting data, remaining on the originating peer.

I think most devices will only have a single "resource" value for the 
whole device... how do we signal this, just putting both resource TLVs 
into the message with the same value?

> 9.16  Status
>
>    The Status TLV is sent as part of an acknowledgement message, from
>    either the modem or the router, to indicate the success or failure of
>    a given request.
>
>    The Status TLV contains the following fields:
>
>     0                   1                   2
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |TLV Type =TBD  |Length = 1     |     Code      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    TLV Type         - TBD
>
>    Length           - 1
>
>    Termination Code - 0 = Success, Non-zero = Failure. Specific values
>
>
>
> Ratliff et al.         Expires September 26, 2013              [Page 24]
> 
> Internet-Draft                    DLEP                        March 2013
>
>
>                           of a non-zero termination code depend on the
>                           operation requested (e.g. Neighbor Up,
>                           Neighbor Down, etc).

Do we need an IANA registry for this values? I don't think the document 
specified even a single failure value.

> 9.17  Heartbeat Interval/Threshold

...

>    The Heartbeat Interval/Threshold TLV contains the following fields:
>
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |TLV Type =TBD  |Length = 1     | Interval      |  Threshold    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    TLV Type         - TBD
>
>    Length           - 1

Length = 2

> 9.21  Credit Request
>
>    The Credit Request TLV is an OPTIONAL TLV. If credits are supported,
>    the Credit Request TLV MAY be sent from either DLEP participant, via
>    a Neighbor Update signal, to indicate the desire for the partner to
>    grant additional credits in order for data transfer to proceed on the
>    session. If the corresponding Neighbor Up message for this session
>    did NOT contain a Credit Window Status TLV, indicating that credits
>    are to be used on the session, then the Credit Request TLV MUST be
>    rejected by the receiver via a Neighbor Update ACK message.
>
>    The Credit Request TLV contains the following fields:
>
>     0                   1                   2
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |TLV Type =TBD  |Length = 0     | Reserved, MUST|
>    |               |               | be set to 0   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    TLV Type     - TBD
>
>
>
>
> Ratliff et al.         Expires September 26, 2013              [Page 28]
>
> Internet-Draft                    DLEP                        March 2013
>
>
>    Length       - 0

Alternative A: Length = 1

>    Reserved     - This field is currently unused and MUST be set to 0.

Alternative B: drop this unused field

> 10. DLEP Protocol Messages
>
>    DLEP messages are encoded as a string of Type-Length-Value (TLV)
>    constructs. The first TLV in a DLEP message MUST be a valid DLEP
>    signal, as defined in section 11.1 of this document. The second TLV
>    MUST be the Identification data item, defined in section 10.1
>    Following those two TLVs are 0 or more TLVs, representing the data
>    items that are appropriate for the signal. The layout of a DLEP
>    message is thus:
>
>     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 Signal   |DLEP Message   |Identification |Identification |
>    | Type value    |length (9 +    |TLV Type       |TLV length     |
>    | (value TBD)   |optional TLVs) |(TBD)          |(8)            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                            Router ID                          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                            Modem ID                           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Start of optional DLEP        |
>    | TLVs...                       |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    All DLEP messages (signals) begin with this structure. Therefore, in
>    the following descriptions of specific messages, this header
>    structure is assumed, and will not be replicated.

The DLEP Identification TLV has been dropped from this draft, so it 
should be dropped from the protocol message description too.

In fact, the whole chapter 10 could be dropped, we already described it 
in chapter 8. Chapter 10.1 could become 8.1 (maybe).

> 12. Peer Offer Message
>
>    The Peer Offer Message is sent by a DLEP router in response to a Peer
>    Discovery Message. Upon receipt, and processing, of a Peer Offer
>    message, the modem MUST respond with a Peer Offer ACK message,
>    completing the discovery phase of DLEP. Both DLEP participants
>    (router and modem) would then enter an "in session" state. Any
>    subsequent Discovery messages sent or received on this session MUST
>    be considered an error, and the session MUST be terminated as if a
>    Peer Termination Message had been received.
>
>    The Peer Offer message MUST be sent to the unicast address of the
>    originator of Peer Discovery, regardless of whether the discovery was
>    received on the DLEP multicast address (TBD) or on a unicast
>    address.
>
>    To construct a Peer Offer message, the initial TLV type value is set
>    to DLEP_PEER_OFFER (value TBD). The signal TLV is then followed by
>    any OPTIONAL Data Item TLVs the implementation supports:
>
>    Optional Data Item TLVs:
>
>               - DLEP Version
>               - Peer Type
>               - IPv4 Address
>               - IPv6 Address
>               - Status
>               - Heartbeat Interval
>               - Heartbeat Threshold
>               - Link Characteristics ACK Timer

What happens if the Modem/Radio receives a Peer Offer Message with a 
Status with value not equals 0? I am not sure about the semantics here.

> 13. Peer Offer ACK Message
>
>    The Peer Offer ACK message acknowledges receipt of a Peer Offer
>    message, and completes the router/modem session establishment for
>    DLEP. The Peer Offer ACK message MUST be sent to unicast address of
>    the originator of a Peer Offer message. The Peer Offer ACK message
>    MUST contain an OPTIONAL Status data item, indicating success or
>    failure of the attempt to establish a router/modem session.

"MUST contain a Status data item."

The OPTIONAL should be removed, it contradicts the MUST.

>    To construct a Peer Offer ACK message, the initial TLV type value is
>    set to DLEP_PEER_OFFER_ACK (value TBD). Mandatory data item TLV's are
>    placed into the packet next:
>
>    Mandatory Data Item TLVs:
>              - Status
>
>    Note that there are NO OPTIONAL data item TLVs specified for this

I assume that a "Status value = 1" Peer Offer Ack will mean the 
Modem/Radio rejects the Routers Peer Offer, right?

>
> Ratliff et al.         Expires September 26, 2013              [Page 31]
> 
> Internet-Draft                    DLEP                        March 2013
>
>
>    message.
>
> 14. Peer Update Message
>
>    The Peer Update message is an OPTIONAL message, sent by a DLEP peer
>    to indicate local Layer 3 address changes, or for metric changes on a
>    modem-wide basis. For example, addition of an IPv4 address to the
>    router would prompt a Peer Update message to its attached DLEP
>    modems. Also, a modem that changes its Maximum Data Rate for all
>    destinations MAY reflect that change via a Peer Update Message to its
>    attached router(s).
>
>    Concerning Layer 3 addresses, if the modem is capable of
>    understanding and forwarding this information (via proprietary
>    mechanisms), the address update would prompt any remote DLEP modems
>    (DLEP-enabled modems in a remote node) to issue a "Neighbor Update"
>    message to their local routers with the new (or deleted) addresses.
>    Modems that do not track Layer 3 addresses SHOULD silently parse and
>    ignore the Peer Update Message. Modems that track Layer 3 addresses
>    MUST acknowledge the Peer Update with a Peer Update ACK message.
>    Routers receiving a Peer Update with metric changes MUST apply the
>    new metric to all neighbors (remote nodes) accessible via the modem.
>    Supporting implementations are free to employ heuristics to
>    retransmit Peer Update messages. The sending of Peer Update Messages
>    for Layer 3 address changes SHOULD cease when a either participant
>    (router or modem) determines that the other implementation does NOT
>    support Layer 3 address tracking.

Can we split this message into two?

I think the semantics of the Routers Peer Update and the Modems/Radios 
Peer Update is quite different.

> 15. Peer Update ACK Message
>
>    Optional Data Item TLVs:
>              - Status

> 16. Peer Termination Message
>
>    Optional Data Item TLVs:
>              - Status
>
> 17. Peer Termination ACK Message
>    Optional Data Item TLVs:
>              - Status

I assume that the receiver of this three messages is allowed to ignore 
the value of the Status TLV?

 > 19. Neighbor Up ACK Message
 >
 >    Optional Data Item TLVs:
 >               - Credit Window Status

No optional Status TLV for this one?

> 21. Neighbor Down ACK Message
>
>    A DLEP participant sends the Neighbor Down ACK Message to indicate
>    whether a received Neighbor Down Message was successfully processed.
>    If successfully processed, the sender of the ACK MUST have removed
>    all entries in the information base that pertain to the referenced
>    neighbor. As with the Neighbor Down message, there are NO OPTIONAL
>    Data Item TLVs defined for the Neighbor Down ACK message.
>
>    To construct a Neighbor Down message, the initial TLV type value is
>    set to DLEP_NEIGHBOR_DOWN_ACK (value TBD). The mandatory data item
>    TLVs follow:
>
>       - MAC Address Data item
>       - Status data item

Status data item should be optional?

> 25. Link Characteristics ACK Message
 >
>    After placing the mandatory data item TLV into the packet, the
>    implementation would place any supported OPTIONAL data item TLVs.
>    Possible OPTIONAL data item TLVs are:
>
>    Current Data Rate  -  If present, this value represents the requested
>                          data rate in bits per second (bps).
>
>    Latency            -  If present, this value represents the NEW
>                          maximum latency (or unchanged, if the request
>                          is denied), expressed in milliseconds, on the
>                          link.

No optional Status TLV for this one?

Thats all for now...

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de