Subject: [Manet-dt] More Discussion on DYMO using Common Packet Format

From: Ian Chakeres <[email-masked]>
Date: Sun, 22 Jan 2006 14:33:36 -0800

I'm trying to write a new DYMO ID using the common packet format but  
there is a lot to change. I'm going to post a few portions here and I  
would like your feedback.

==================================
3.2.1. Generic Packet and Message Structure

All DYMO messages MUST conform to the generic message format as  
described in draft-clausen-olsrv2-fmt-00.txt.

        <packet> = <packet-header>?
                   {<message><pad-octet>*}+

        <packet-header> = <zero>
                          <reserved>
                          <packet-seq-number>

       <message>         = <msg-header>
                            <tlv-block>
                            {<addr-block><tlv-block>}*

        <msg-header>      = <type>
                            <msg-semantics>
                            <msg-size>
                            <msg-header-info>?

        <msg-header-info> = <originator-address>
                            <ttl>
                            <hop-count>
                            <msg-seq-number>

        <tlv-block>       = <tlv-length>
                            <tlv>*

       <address-block> = <head-length>
                          <head>
                          <num-tails>
                          <tail>+
       <tlv> = <type>
                <length>
                <index-start>
                <index-stop>
                <value>

=================================

3.2.2. Routing Message (RM)

RM conform to the generic message structure.
RM is a message with msg-type TBD.

msg-semantics
RM MUST contain I-bit
RM MUST contain A-bit
RM MUST contain S-bit

msg-tlvs
RM MUST contain 1 and only 1 msg tlv of TTL

add-blocks
RM MUST contain 1 and only 1 address marked as Originator
if the message is unicast (the IPDestinationAddress is a unicast  
address), RM MUST contain 1 and only 1 address marked as Target

add-tlv
RM MUST contain an Originator SeqNum
RM SHOULD contain an Originator HopCnt (OrigHopCnt). If OrigHopCnt is  
not included, it is assumed to be zero (unknown)
RM SHOULD contain an Target Last Known SeqNum (TargetSeqNum) if  
unicast. If TargetSeqNum is not included in the message it is assumed  
to be zero (unknown)
RM SHOULD contain an Target Last Known HopCnt (TargetHopCnt) if  
unicast. If TargetHopCnt is not included in the message it is assumed  
to be zero (unknown)

==================================

3.2.3. Route Error (RERR)

RERR must confirm to the generic message structure
RERR is a message with msg-type TBD.

msg-semantics
RERR MUST contain I-bit

msg-tlvs
RERR MUST contain 1 and only 1 msg tlv of TTL

add-blocks
RERR MUST contain 1 or more addresses marked as unreachable
RERR MAY contain an 1 and only 1 address marked a Originator
RERR MUST contain an 1 and only 1 address marked a Target if unicast  
IPDestinationAddress
RERR MAY contain an 1 and only 1 address marked a Target if  
IPDestinationAddress is not a unicast address

add-tlvs
RERR SHOULD contain SeqNum for each unreachable node. If the SeqNum  
is not included in the message it is assumed to be zero (unknown)
RERR SHOULD contain the Last Known HopCnt for each unreachable node.  
If the HopCnt is not included in the message it is assumed to be zero  
(unknown)
RERR MAY contain an Originator SeqNum. If the SeqNum is not included  
in the message it is assumed to be zero (unknown)
RERR MAY contain an Originator HopCnt. If the HopCnt is not included  
in the message it is assumed to be zero (unknown)
RERR MAY contain an Target Last Known SeqNum. If the SeqNum is not  
included in the message it is assumed to be zero (unknown)
RERR MAY contain an Target Last Known HopCnt. If the HopCnt is not  
included in the message it is assumed to be zero (unknown)

==================================

6. IANA Considerations

DYMO defines several message-types and tlv-types. A new registry will  
be created for the values for the various type fields, and the  
following values will be assigned:

message-type Value

-------------------------------- -----

Routing Message (RM) 1

Route Error (RERR) 2

message-tlv Value

-------------------------------- -----

TTL TBD

address-tlv Value

-------------------------------- -----

DYMO Sequence Number (multivalue) TBD

Hop Count (multivalue) TBD

Gateway TBD

Originator TBD

Target TBD

_______________________________________________
Manet-dt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet-dt

---

From: "Luke Klein-Berndt" <[email-masked]>
Date: Mon, 23 Jan 2006 15:04:03 -0500

It is all starting to come together. And of course I have some stupid
clarifying questions.
- Shouldn't there be a TLV for the Target address? The TLV would reference
the address in the address block. I wasn't sure if this was assumed or it is
handled differently.

- Would the originator address be specified in the originator field of the
message or would it be in the address block.

- Why only limit it to one target address for multicast/MANETcast messages?
It could be interesting to specify multiple address that you would like ACKs
from when they receive the message. Sort of a Sloppy Multicast QoS. 

- To determine multicast or unicast it would not be based solely upon the
address type. If there are more than one target addresses or a
multicast/MANETcast address then MANETcast. If there is a single unicast
target address then unicast.

- Do we want a Message TLV to signify MANETcast or multicast? It could be an
optional Multicast TLV that would fall back on Multicast when needed.

I like how this is coming along though!

-Luke

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ian Chakeres
Sent: Sunday, January 22, 2006 5:34 PM
To: [email-masked]
Subject: [Manet-dt] More Discussion on DYMO using Common Packet Format

        <packet-header> = <zero>
                          <reserved>
                          <packet-seq-number>

       <message>         = <msg-header>
                            <tlv-block>

        <msg-header>      = <type>
                            <msg-semantics>
                            <msg-size>
                            <msg-header-info>?

msg-semantics
RM MUST contain I-bit
RM MUST contain A-bit
RM MUST contain S-bit

msg-tlvs

add-blocks

add-tlv

msg-semantics
RERR MUST contain I-bit

msg-tlvs

add-blocks

add-tlvs

6. IANA Considerations

message-type Value

Routing Message (RM) 1

Route Error (RERR) 2

message-tlv Value

TTL TBD

address-tlv Value

Gateway TBD

Originator TBD

Target TBD

---

From: Ian Chakeres <[email-masked]>
Date: Mon, 23 Jan 2006 13:28:56 -0800

I have a Target add-tlv. It appears some of my CR were lost in the cut
and past or in the emailing process.

"""

"""

I'll try to clear this up. Perhaps the formatting is bad too. It
should say there is one address in an address block for the
Orig/Target. Then in the add-tlv section it should say one of each
must be marked appropriately.

I think the originator would be in the address block. Otherwise, you
cannot compress it or add additional information like prefix.

I think having multple Target or a multicast Target complicates
things, but I would be open to including it if people feel it is
useful and interesting. My suggestion would be to handle the simple
case first, then we can deal with adding some more complexity later.

Can you please explain your idea about a "Multicast" msg-tlv? I don't
understand.

Ian