Subject: Re: Virtual MGs and MID

From: Bharat Kaul <[email-masked]>
Date: Mon, 14 Aug 2000 15:26:00 -0700

there are a few things which need to be addressed.

ISSUE 1:
----------

Flemming mentioned that "port" in MID indicates where the commands should be
sent. However, my understanding is different and is given below.

If MG needs to indicate to MGC where to send the commands, it will include a
ServiceChange Address in its ServiceChange message and thereby indicates to
MGC where to send the commands. And this is possible only for UDP transport.
For TCP transport, MGC uses the same connection as established by the MG.

MGC can also instruct MG to send commands to a particular port by
Redirection.

So at this point, I myself don't understand what "PORT" in MID signifies.
Clarifications are appreciated.

ISSUE 2:
----------

MID in standards for IPV4 network is IPAddress [optional port]. So
possibility is that in some messages from a entity port is present and in
some it is not.

In examples shown in the standard (Appendix A), the MG1 is not using
consistent MID i.e. in one case it doesn't use "port" in MID and other times
it does. From MGC point of view, how does one ensure that it is the same MG
?

By the same token, what stops any MG from using the UDP port of transmission
as port number in MID.

This leads to a problem that at MGC side that MID for a single MG can vary
(as examples show) and in case of virtual MG using UDP transport, there is
no way poor MGC can distinguish between them.

ISSUE 3:
----------

In case of TCP transport, how does one distinguish between a single MG
establishing multiple connections to the MGC and virtual MGs establishing
TCP connections. Note that at the time of establishing TCP Connection, MGC
has no way of knowing which case it is handling ? Can anyone shed some light
in this area too ?

- Thanks
  Bharat

-----Original Message-----
From: John Segers [mailto:[email-masked]]
Sent: Monday, August 14, 2000 2:54 AM
To: [email-masked]
Subject: Re: Virtual MGs and MID

Flemming,

I think that I'm missing the point.

Here's how I understood it to work.  MGs and MGCs alike include an MId
in messages they send, including port number when necessary, thus making
MId unique if different ports are used for communication with different
(virtual) MGs.  Is there a catch?

Cheers,

John

Flemming Andreasen wrote:
>
> I'm not so sure it's that simple. The port number the MG indicates is for
> receiving messages, not sending. Furthermore, I thought mId would be
unique
> thereby enabling the MGC to detect duplicate transactions by looking at
the
> combination of mId and TransactionId (as specified in D.1.1). If that's
not the
> case, we have another problem.
>
> -- Flemming
>
> John Segers wrote:
>
> > Bharat,
> >
> > Only the IP address of the virtual MGs would be the same; they can be
> > distinguished by port number.
> >
> > This scheme works by virtue of the fact that (virtual) MGs initiate the
> > registration procedure and can inform the MGC of the port number they
> > want to use in the first message (servicechange).
> >
> > Cheers,
> >
> > John
> >
> > Bharat Kaul wrote:
> > >
> > > I need a clarification regarding use of MID in virtual MG case.
> > >
> > > First consider a case where virtual MGs are controlled by the same MGC
(i.e.
> > > in commands from MGC the MID is constant to all these MGs) and the
transport
> > > used is UDP. How do we identify the virtual MG in a PHYSICAL MG to
which the
> > > command from the MGC is destined to ?
> > >
> > > Secondly, on MGC side for UDP transport, can all these MGs use the
same MID
> > > (like www.example.net) ? If yes, then we have the same identification
> > > problem on MGC side too ?  I am not clear about the MID that a virtual
MG
> > > should fill in its messages to MGC to identify itself uniquely i.e.
how are
> > > MID's for a virtual MG and non-virtual MG different while sending
messages
> > > to the MGC ?
> > >
> > > Clarifications are appreciated.
> > >
> > > - Thanks
> > >   Bharat
> > >
> > >
----------------------------------------------------------------------------
> > > -------
> > > Bharat Kaul;                                 Trillium Digital Systems
Inc.
> > > mailto:[email-masked]    12100 Wilshire Blvd,
> > > Phone: +1-310-442-9222         Los Angeles, CA - 90025.
> > > Fax:     +1-310-442-1162           http://www.trillium.com
> >
> > --
> > John Segers                                  email: [email-masked]
> > Lucent Technologies                                        Room HE 303
> > Dept. Forward Looking Work                      phone: +31 35 687 4724
> > P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
>
> --
> Flemming Andreasen                Phone: +1 732 452 1667
> Cisco Systems                     Fax:   +1 240 359 5839

--
John Segers                                  email: [email-masked]
Lucent Technologies                                        Room HE 303
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 16 Aug 2000 08:41:25 -0500

My own views below.

> From: Bharat Kaul [mailto:[email-masked]]
> Sent: Monday, August 14, 2000 6:26 PM
> To: [email-masked]
[PTT]
Responses must be sent back to where requests came from.  For IP transport,
the source is presumably derived from the IP header.  The primary function
of the MID is therefore to provide a logical MG identifier which serves as a
handle to the control session context.

> For TCP transport, MGC uses the same connection as
[PTT]
For TCP transport, I would think that a new ServiceChangeAddress would
indicate that the MGC should establish a TCP connection to the new address.
It's not clear in general why an MG would do this, but perhaps as part of a
failover strategy it might do so.

> no way poor MGC can distinguish between them.
[PTT]
If I am correct in my view that the MId serves as a logical identifier, it
must be consistent throughout the same control session.
> ISSUE 3:
[PTT]
Again, if I am correct in my interpretation of MId, it identifies the
logical MG, so the MGC can distinguish the two cases by comparing MIds.  It
could also do so by noting which terminations each control connection
supports.

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 16 Aug 2000 08:43:36 -0500

I'd say that an MID without port is different from an MId with port.  The
MId is a logical handle to identify the originator of the message.

> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Tuesday, August 15, 2000 1:00 AM
> I thought the port number was only used for ServiceChange and
> indicated the
> destination port to use subsequently. I assume the port
> number you refer to would
> still be the destination port number (which is simply part of
> the identifier now), not
> the source port number. If that's the case, I guess you're
> right (although it strikes
> me that having divided the name of an MG/MGC into a local and
> network part independent
> of transport would seem better)
>
> Related question then:    Assume we communicate with MG X on
> port Y. Is a mId with X
> as the domainname and Y as the portnumber the same as mId X
> without a portnumber ?
>
>
> -- Flemming
>
> >
> >
> > Cheers,
> >
> > John
> >
> > > receiving messages, not sending. Furthermore, I thought
> mId would be unique
> > > thereby enabling the MGC to detect duplicate transactions
> by looking at the
> > > combination of mId and TransactionId (as specified in
> D.1.1). If that's not the
> > > > > First consider a case where virtual MGs are
> controlled by the same MGC (i.e.
> > > > > in commands from MGC the MID is constant to all these
> MGs) and the transport
> > > > > used is UDP. How do we identify the virtual MG in a
> PHYSICAL MG to which the
> > > > > Secondly, on MGC side for UDP transport, can all
> these MGs use the same MID
> > > > > problem on MGC side too ?  I am not clear about the
> MID that a virtual MG
> > > > > should fill in its messages to MGC to identify itself
> uniquely i.e. how are
> > > > > MID's for a virtual MG and non-virtual MG different
> while sending messages
> > > > > to the MGC ?
> > > > >
> > > > > Bharat Kaul;                                 Trillium
> Digital Systems Inc.
> Flemming Andreasen
> Cisco Systems

---

From: Bharat Kaul <[email-masked]>
Date: Wed, 16 Aug 2000 10:58:52 -0700

Hi Tom,

   I believe in previous discussions on the mailing list and the philosophy
of the protocol that MG always initiates conversation, MG providing
ServiceChangeAddress for TCP transport had been ruled out. Providing
ServiceChangeAddress for TCP transport implies MGC initiates connection or
in other words MG has to have TCP Servers. References for above discussions
are give at the end of this email.

Is this the current understanding of the protocol ? If yes, I think we
should add a line or two in errata which clarifies some of the questions
asked with respect to TCP transport and ServiceChange. Atleast pooling the
references given below, it does seem like a nice thing to do :)

On a side note, if MG is so particular about the port where it wants MGC to
send commands to it, the MG might as well use the same port for establishing
the TCP connection to the MGC and do away with ServiceChange address and
still adhere to "MG Initiates" philosophy.

Secondly, I agree with you that the MID should be consistent across a
control session. However, the example in Appendix A where MG1 is sending
commands is not consistent with this idea. So may be in our errata we should
fix that and additionally have a line or two in standards or errata which
says, " The MID is constant for the duration of a control session".

- Bharat

REFERENCES

Mail on Oct 6, 1999 with subject as "TCP as transport".
Mail on May 30, 2000 with subject as "TCP transport /ServiceChange Command"
Mail on June 27, 2000 with subject as "MG Service Change w.r.t. TCP as
transport"
Mail on July 6, 2000  with subject as "MG Service Change w.r.t. TCP as
transport"

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Wednesday, August 16, 2000 6:41 AM
To: 'Bharat Kaul'; [email-masked]
Subject: RE: Virtual MGs and MID

My own views below.

> From: Bharat Kaul [ mailto:[email-masked]
<mailto:[email-masked]> ]
[PTT]

[PTT]

[PTT]

[PTT]

> From: John Segers [ mailto:[email-masked] <mailto:[email-masked]>
]
> by looking at
> D.1.1). If that's
> MGs) and the
> PHYSICAL MG to
> uniquely i.e.
> while sending
> Digital Systems
> > > > mailto:[email-masked] <mailto:[email-masked]>     12100
Wilshire Blvd,
> > > > Fax:     +1-310-442-1162           http://www.trillium.com
<http://www.trillium.com>

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 17 Aug 2000 14:29:29 -0500

There is a distinction between the conversation at the application level and
the connection at transport level.  If the MG provides an alternate address
in ServiceChangeAddress, it is not telling the MGC to initiate a new session
at that alternate address, merely that that is where the current
conversation should be continued.  Remeber, the MG is controlling this --
the MGC is not imposing on it the requirement to be a TCP server.

-----Original Message-----
From: Bharat Kaul [mailto:[email-masked]]
Sent: Wednesday, August 16, 2000 1:59 PM
To: Taylor, Tom-PT [NORSE:B901:EXCH]; [email-masked]
Cc: Bharat Kaul
Subject: RE: Virtual MGs and MID

Hi Tom,

[PTT] Yes, that is what I would expect.

- Bharat

REFERENCES

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Wednesday, August 16, 2000 6:41 AM
To: 'Bharat Kaul'; [email-masked]
Subject: RE: Virtual MGs and MID

My own views below.

[PTT]

[PTT]

[PTT]

[PTT]

]
Wilshire Blvd,