Subject: RE: Control Association Problem

From: "Tom-PT Taylor" <[email-masked]>
Date: Sun, 1 Apr 2001 11:04:07 -0400

I think this makes sense.  It is consistent with the principle that you send
responses to the address from which the requests came.

> -----Original Message-----
> From: Kaul, Bharat [mailto:[email-masked]]
> Sent: Friday, March 30, 2001 9:37 PM
> To: [email-masked]'
> Subject: Control Association Problem
> 
> 
> Hi List, 
> 
> Some more confusion/problem on MG-MGC control association and 
> potential
> addition to Implementors guide.
> 
> Assume that transport is UDP and MID filled in the header is 
> IPV4 Address +
> Port and the transport address used for transmission of the message is
> different from as specified in MID ?
> 
> First, is it allowed/legal  ?
> 
> If yes, then should the entity receiving (ENT-RCV) the 
> message assume that
> the address information in MID is the transport address to be used for
> subsequent communication with entity that sent the message 
> (ENT-TX) ? Or
> should ENT-RCV use the transport address obtained from UDP on 
> receipt of the
> message for subsequent communication ?"
> 
> This is step one of the uncertainity. Here is step two :)
> 
> Additionally, assume MG sent a ServiceChange with method as 
> Restart for the
> Root Termination to the MGC and transport is UDP. The MID 
> filled by MG is
> IPV4 + port, the transport address used for transmission is 
> different that
> what is in MID and worse it fills a ServiceChange Address 
> with a different
> transport address information. In such a case, which transport address
> should the MGC use for subsequent communication with the MG.
> 
> The protocol is silent on all these aspects and if above 
> holds, I do see
> some inter-op issues here.
> 
> If above indeed are issues, here is what I suggest:
> 
> If MID is IPV4 address and the address is different from 
> source transport
> address used for transmission, source transport address 
> should be used for
> subsequent communication.
> 
> In case of ServiceChange scenario message described above, 
> the ServiceChange
> Address should take precedence.
> 
> 
> Comments/Pats/BrickBats ? ;)
> 
> - Bharat
> 
> 
> --------------------------------------------------------------
> --------------
> --------------
> Bharat Kaul                          Trillium Digital Systems Inc.
> mailto: [email-masked]    An Intel Company,
> Phone: 310 481 5515             12100 Wilshire Blvd, #1800,
> Fax    : 310 442 1162             Los Angeles, CA - 90025
> http://www.trillium.com
> 
> 
>

---

From: "jkr" <[email-masked]>
Date: Mon, 2 Apr 2001 10:33:09 +0530

So, theoriticaly  it allows some one to keep changing the transport address
for every command sent and practically puts off the need for
ServiceChangeAddress?

I think the guidance should be to 'set up the association using Service
Change Address' and 'use that association for subsequent comands'. This also
makes it closer to the behaviour when TCP is used.

I agree with not using MID header info for control association. MID in the
header can be treated as just an header for the quick look at the generator
(source) of the command and  not seriously looked in for association.

Reagrds,

- JK
  ( J K Ramachandra)
   IPGEN