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

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

"""
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

"""

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

On 1/23/06, Luke Klein-Berndt <kleinb@nist.gov> wrote:
> 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: manet-dt-bounces@ietf.org [mailto:manet-dt-bounces@ietf.org] On Behalf
> Of Ian Chakeres
> Sent: Sunday, January 22, 2006 5:34 PM
> To: manet-dt@ietf.org
> Subject: [Manet-dt] More Discussion on DYMO using Common Packet Format
>
> 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
> Manet-dt@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet-dt
>
>
>
>

_______________________________________________
Manet-dt mailing list
Manet-dt@ietf.org
https://www1.ietf.org/mailman/listinfo/manet-dt