Subject: Virtual MGs and MID

From: Bharat Kaul <[email-masked]>
Date: Wed, 9 Aug 2000 11:29:23 -0700

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

---

From: John Segers <[email-masked]>
Date: Thu, 10 Aug 2000 13:15:00 +0200

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

--
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: Flemming Andreasen <[email-masked]>
Date: Fri, 11 Aug 2000 17:26:19 -0400

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

--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839

---

From: John Segers <[email-masked]>
Date: Mon, 14 Aug 2000 11:54:14 +0200

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

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 15 Aug 2000 00:59:50 -0400

> (virtual) MGs.  Is there a catch?

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

--
Flemming Andreasen
Cisco Systems

---

From: John Segers <[email-masked]>
Date: Wed, 16 Aug 2000 15:43:19 +0200

Flemming,

If we have communication with MG X on port Y, then I would say that mId
X:Y is equivalent to mId X if X by itself uniquely identifies the MG.

Thinking about it, I'm not sure that the port number to include in an
mId is the destination port.  mId is really supposed to identify the
source of the message, and we're proposing that it be a combination of
source IP address and destination port.

This issue definitely requires some clarifying text.

Cheers,

John