Subject: Behaviour of Add Branch

From: "Richard Proctor" <[email-masked]>
Date: Fri, 5 May 2000 10:18:47 +0100

Hi,

At the MSF meeting in Paris, I presented an issue about the behavior of the Add
Branch Message, and a request that it is modified to control fan-in (Multi-point
to point) behaviour.  This should have been a
contribution, but I could not get access to the server before the meeting.

This change has been provisionally agreed, but I was asked to send it, and most
of the significant email discussions that took place just prior to the meeting.

Richard Proctor
Marconi

The "contribution":

(See attached file: Behaviour of Add Branch.doc)

Three email messages follow relating to earlier drafts of the document.

<===== First response from CPlane:- =======>

Please respond to [email-masked]

 To:      Richard Proctor/MAIN/MC1@MCMAIN                     
                                                              
 cc:      "Avri Doria (E-mail)" <[email-masked]>        

 Subject: more on your doc, from Jerry & Bala                 

We've discussed it and would be delighted to co-author if you believe our
support would be useful.

Regards

Simon

Reply-To: <[email-masked]>
From: "Jaroslaw Sydir" <[email-masked]>
Sender: <sydir>
To: <[email-masked]>
Cc: "Balaji Srinivasan (E-mail)" <[email-masked]>,   "Matt Peters (E-mail)"
<[email-masked]>
References: <[email-masked]>
Subject: Re: FW: Contribution?
Date: Thu, 27 Apr 2000 08:36:57 -0700
Organization: CPlane Inc.
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain;     charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
X-Accept-Language: en

If you invite him to submit his contribution, then we should co-author.

He is pointing out that in GSMP an erroneous add branch will cause a
multicast connection to be created where one was not intended. This is a
valid problem that we have dealt with in our abstract interface in
roughly the same way that he proposes.

He suggests adding a field to the AddBranch message to indicate if this
should be multicast or not. Its not clear whether he intends for this
field to be used on the initial AddBranch or on subsequent ones. Our
solution is to declare the intentions on the initial AddBranch because
multicast connections are placed into special forwarding tables on some
switches.

Matt, Bala, what do you guys think?

Jerry

From: "Balaji Srinivasan" <[email-masked]>
To: "Jaroslaw Sydir" <[email-masked]>
Cc: <[email-masked]>,  "Matt Peters (E-mail)" <[email-masked]>
Subject: Re: FW: Contribution?
Date: Thu, 27 Apr 2000 09:44:16 -0700
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain;     charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-Reply-To: <[email-masked]>

>
> He suggests adding a field to the AddBranch message to indicate if this
> should be multicast or not. Its not clear whether he intends for this
> field to be used on the initial AddBranch or on subsequent ones. Our
> solution is to declare the intentions on the initial AddBranch because
> multicast connections are placed into special forwarding tables on some
> switches.
>

I concur. This is what we have been trying to push for a long time.
balaji

<====Next significant message  =====>

Date: Fri, 28 Apr 2000 12:36:42 -0700
From: Jaroslaw Sydir <[email-masked]>
To: [email-masked]
Subject: MSF contribution
Cc: [email-masked], [email-masked], [email-masked]

Hi Richard.

Here are some more detailed comments. We had actually come up with a
more extensive set of cases. They cover all of the ones that you
enumerated except for the "replace" one. We believe that that one is
optional, as you can delete and add to accomplish the same thing. I
guess if the switch can do replace less disruptively, then it might make
sense. In any case its not a big deal either way.
Here are the cases that we use in our interface:

Unicast : This has to be a unicast connection. If either end is occupied
          then return an error
First Branch P2MP: This is a first branch of a Point to Multi Point
          connection. If there already is a connection occupying either
          end then return an error. If this particular label cannot
          accomodate a P2MP call then generate an error.
First Branch MP2P: This is a first branch of a Multi Point to Point
          connection. If there already is a connection occupying either
          end then return an error. If this particular label cannot
          accomodate a MP2P call then generate an error.
Additional Branches P2MP: This is an additional branch of a P2MP call.
If a
          branch does not already exist then generate an error.
Additional Branches MP2P: This is an additional branch of a MP2P call.
If a
          branch does not exist already then generate an error
First or Additional P2MP: This could be the first or additional branches
of a P2MP call.
First or Additional MP2P: This could be the first or additional branches
of a MP2P call.
Unknown: This could be a unicast connection, or first or additional
           branches of a P2MP or a MP2P call.

So basically this requires 3 bits in the message somewhere. 4 bits are
preferable just in case we want to add more behaviour later.

If you like these suggestions, please list Balaji Srinivasan and Matt
Peters from CPlane as co-authors.

Have fun in Paris...

Jerry Sydir

<==== My Reply to that message =====>

Date: Fri, 28 Apr 2000 21:52:15 +0100 (BST)
From: Richard Proctor <[email-masked]>
To: Jaroslaw Sydir <[email-masked]>
Subject: Re: MSF contribution

On Fri 28 Apr, Jaroslaw Sydir wrote:
> Hi Richard.
>
> Here are some more detailed comments. We had actually come up with a
> more extensive set of cases. They cover all of the ones that you
> enumerated except for the "replace" one. We believe that that one is
> optional, as you can delete and add to accomplish the same thing. I
> guess if the switch can do replace less disruptively, then it might make
> sense. In any case its not a big deal either way.
> Here are the cases that we use in our interface:
>

The "replace" is the option I do want.  The rationale is to enable
a complete emulation of 64K voice switches, without changing the
higher layer applications.

In this particular application any connection could be multicast, but
fan in is never permitted.  The higher layer application knows that
sending a new request splats the existing one, and expects this behavior.

>
> Unicast : This has to be a unicast connection. If either end is occupied
>           then return an error
> First Branch P2MP: This is a first branch of a Point to Multi Point
>           connection. If there already is a connection occupying either
>           end then return an error. If this particular label cannot
>           accomodate a P2MP call then generate an error.
> First Branch MP2P: This is a first branch of a Multi Point to Point
>           connection. If there already is a connection occupying either
>           end then return an error. If this particular label cannot
>           accomodate a MP2P call then generate an error.
> Additional Branches P2MP: This is an additional branch of a P2MP call.
> If a
>           branch does not already exist then generate an error.
> Additional Branches MP2P: This is an additional branch of a MP2P call.
> If a
>           branch does not exist already then generate an error
> First or Additional P2MP: This could be the first or additional branches
> of a P2MP call.
> First or Additional MP2P: This could be the first or additional branches
> of a MP2P call.
> Unknown: This could be a unicast connection, or first or additional
>            branches of a P2MP or a MP2P call.
>
> So basically this requires 3 bits in the message somewhere. 4 bits are
> preferable just in case we want to add more behaviour later.

This takes the basic idea I had further, I dont object to it, but as a list
it is incomplete.

I think the P2MP and MP2P may need treating separately.

The P2MP needs to allow for "May or May not be P2MP", but add it anyway
(as the current GSMP allows).

It must allow for the "replace" behavior.

Going through them in more detail:

>
> Unicast : This has to be a unicast connection. If either end is occupied
>           then return an error

May need a replace rather than an error as an additional option.

> First Branch P2MP: This is a first branch of a Point to Multi Point
>           connection. If there already is a connection occupying either
>           end then return an error. If this particular label cannot
>           accomodate a P2MP call then generate an error.

Might need a replace rather than an error as an additional option.

> First Branch MP2P: This is a first branch of a Multi Point to Point
>           connection. If there already is a connection occupying either
>           end then return an error. If this particular label cannot
>           accomodate a MP2P call then generate an error.

Might need a replace rather than an error as an additional option.

> Additional Branches P2MP: This is an additional branch of a P2MP call.
> If a branch does not already exist then generate an error.

Probably OK.

> Additional Branches MP2P: This is an additional branch of a MP2P call.
> If a branch does not exist already then generate an error

Probably OK.

> First or Additional P2MP: This could be the first or additional branches
> of a P2MP call.

What happens if the destination is busy?  Error or Replace?  This sounds like
two options.

> First or Additional MP2P: This could be the first or additional branches
> of a MP2P call.

Probably OK.

> Unknown: This could be a unicast connection, or first or additional
>            branches of a P2MP or a MP2P call.

Needs separate Unknown P2MP and Unknown MP2P states.

>
> So basically this requires 3 bits in the message somewhere. 4 bits are
> preferable just in case we want to add more behaviour later.

Think how this relates to the M flag.  Also think about the 2 directions of
a bi-directional connection.  What is the state of either end?
If we go this way it could get rather messy...  I was just worried about the
MP2P case.

>
> If you like these suggestions, please list Balaji Srinivasan and Matt
> Peters from CPlane as co-authors.

I am not able to get a contribution number from the MSF server so it
is likely to be an on the day contribution anyway now.

> Have fun in Paris...

Paris next week, San Francisco the following week...

--

[email-masked]