Subject: MMP Bundle Discovery Protocol

From: Gary Scott Malkin <[email-masked]>
Date: Wed, 4 Feb 1998 11:15:00 -0500

The latest I-D has been out for a couple of weeks now.  Does
anyone have any comments?  If anyone is interested in doing
interoperability testing, please let me know.

-- 

Gary Malkin                                          Cheap, Fast, Good
(978) 916-4237                                       Pick two!

---

From: [email-masked]
Date: Wed, 4 Feb 1998 16:06:03 -0500

[email-masked] on 02/04/98 11:15:00 AM

To:   [email-masked]
cc:    (bcc: Scott Reeve/Shiva Corporation)
Subject:  MMP Bundle Discovery Protocol

>anyone have any comments?
>
>--
>

        1) Is it necessary to define/limit a particular tunneling protocol
to use?
             Perhaps the tunneling protocol itself is beyond the scope of
MMP.

        2) For the purposes of clarity, I want to make sure that I
understand
             Random IDs.  Let me know if I have anything wrong:

           - A Random ID is unique to a bundle.  I.e. when the decision is
made to
             start MMP on a call, a random number is calculated.

           - Subsequent/different bundles require a new random number
calculation.

           - When a bundle re-trasmits a Query it must stick to the same
Random ID
             that went out in the first Query.

        3) If a node has sent out its ROBUSTNESS Queries, and realizes
            that it doesn't have the lowest Random ID, then it must wait
            until it hears a Response.

           How long should it wait for a Response?
           E.g: two nodes could be sending with quite different ROBUSTNESS
and/or
           QUERY_INTERVAL values, so one node could give up trying to be
the bundle
           head, but has no idea how long the other node may still be
trying.

           What if it never gets a Response?  This probably means that the
NAS that had
           the lowest Random ID just went down.  Should the node then
determine the next lowest
           Random ID?

       4) Is it necessary to limit MMP activity to broadcast or a defined
multicast address?
            If it were left fully configurable, any implementation could
send to any address that
            they wanted, even unicast, conceivably.  (many 'multicast
applications' fold down
            to unicast if that's what the user wants)

           Scott Reeve
           [email-masked]

---

From: [email-masked]
Date: Wed, 4 Feb 1998 16:35:22 -0500

Let's try that again.

To:   [email-masked]

>Gary Malkin                                          Cheap, Fast, Good

1) Is it necessary to define/limit a particular
tunneling protocol to use?
Perhaps the tunneling protocol itself is
beyond the scope of MMP.

2) For the purposes of clarity, I want to make
sure that I understand Random IDs.
Let me know if I have anything wrong:

- A Random ID is unique to a bundle.  I.e. when
the decision is made to start MMP on a call, a
random number is calculated.

- Subsequent/different bundles require a new
random number calculation.

- When a bundle re-trasmits a Query it must stick
to the same Random ID that went out in the first Query.

3) If a node has sent out its ROBUSTNESS Queries,
and realizes that it doesn't have the lowest Random ID,
then it must wait until it hears a Response.

How long should it wait for a Response?
E.g: two nodes could be sending with quite different
ROBUSTNESS and/or QUERY_INTERVAL values, so
one node could give up trying to be the bundle head, but
has no idea how long the other node may still be trying.

What if it never gets a Response?  This probably means
that the NAS that had the lowest Random ID just went down.
Should the node then determine the next lowest Random ID?

4) Is it necessary to limit MMP activity to broadcast or a defined
multicast address?  If it were left fully configurable, any
implementation could send to any address that they wanted,
even unicast, conceivably.  (many 'multicast applications' fold
down to unicast if that's what the user wants)

 Scott Reeve
 [email-masked]