Hi, Paul:
You are right that I am proposing the generic protocol only for item 1 (not for items 2 and 3).
This has been the main thrust of all my contributions over the years. People may not have enough time to go through all of my contributions/proposals in detail. It is a win-win situation for all of us.
If anyone has any concerns, I will always be available to explain in depth.
I appreciate your support.
Best regards, Radhika
+1 732 420 1580 rrroy@att.com
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Wednesday, December 26, 2001 11:46 PM To: Roy, Radhika R, ALCTA; Vivek Bhargava; Klaghofer Karl ICN EN HC ID 14; Horvath Ernst Siemens AT; Paul K'; BOUGANT Francois FTRD/DAC/ISS; Miner Gleason; Euchner Martin ICN M SR 3 Cc: Vivek Bhargava; Orit Levin Subject: Re: New draft of H.MMS.1
Radhika,
As you know, I've not been able to be present at all of the mobility meetings, but I thought that you had championed the idea of having a generic protocol for at least (2) below, rather than using Annex G-- I suppose I didn't pay enough attention.
So, your proposing that only (1) be new and generic, while the others be realized by extending the existing protocols. I'd agree with that approach.
Paul
----- Original Message ----- From: "Roy, Radhika R, ALCTA" rrroy@att.com To: "Vivek Bhargava" vbhargava@cisco.com; "Paul E. Jones" paulej@packetizer.com; "Klaghofer Karl ICN EN HC ID 14" Karl.Klaghofer@icn.siemens.de; "Horvath Ernst Siemens AT" ernst.horvath@siemens.at; "Paul K'" paul.k.reddy@intel.com; "BOUGANT Francois FTRD/DAC/ISS" francois.bougant@rd.francetelecom.com; "Miner Gleason" mgleason@cisco.com; "Euchner Martin ICN M SR 3" Martin.Euchner@icn.siemens.de Cc: "Vivek Bhargava" vbharga@cisco.com; "Orit Levin" orit@radvision.com Sent: Wednesday, December 26, 2001 10:41 AM Subject: RE: New draft of H.MMS.1
Hi, Paul, Vivek, and All:
Let me clarify again as follows:
- We are developing a new protocol where no protocol exists and the same
can used by all applications to solve the mobility related problems. For example, no protocol exits among BE/AMFE, VLF, HLF, and AuF. Here where we are defining a new "generic" protocol. This is not specific to the H.323 protocol. (Whether VLF, HLF, and AuF will be colocated with the BE/AMFE is a matter of implementation.)
- We have the H.225.0 Annex G protocol that allows us to communicate
among the H.323 BEs. This is specific to H.323. All we need to do is to extend this protocol to serve our purposes. (An analogy can be provided. It should be done in a way what Paul Reddy has done for H.xxx Annex E.)
- We have the H.225.0 (RAS + Q.931) protocol that is used among the H.323
Terminals, GKs, and GWs. This is specific to H.323. All we need to do is to extend this protocol to serve our purposes. (An analogy can be provided. It should be done in a way what Paul Reddy has done for H.xxx Annex E.)
The questions that I have to you all: Why do you want to develop a generic
protocol (if it is not H.323 specific) for items 2 and 3? If you want to do so, how do you definite the generic functional entities like terminals, GKs, BEs, GWs, etc? (Please also note that H.324 and H.310 do not have the concept of functional entities like GKs.)
My assumption has been that the same (items 2 and 3) can also be done for
H.324, H.310, or other protocol while all protocols can use the same "generic" protocol as developed in item 1.
Please also note that if we develop a "generic" protocol for items 2 and 3
instead of being making protocol-specific extension, we will force each protocol (H.323, H.324, H.310, etc.) to use the DUPLICATE sets of protocols (protocol specific + generic) among all its functional entities. Is it nor wastage of resources?
I like to see more discussion on this.
Best regards,
Radhika R. Roy rrroy@att.com
-----Original Message----- From: Vivek Bhargava [mailto:vbhargava@cisco.com] Sent: Monday, December 24, 2001 9:10 PM To: Paul E. Jones; Roy, Radhika R, ALCTA; Klaghofer Karl ICN EN HC ID 14; Horvath Ernst Siemens AT; Paul K'; BOUGANT Francois FTRD/DAC/ISS; Miner Gleason; Euchner Martin ICN M SR 3 Cc: Vivek Bhargava; Orit Levin Subject: Re: New draft of H.MMS.1
I think a new protocol will be inevitable if the VLF and HLF functions are separated from the BE. If it is always assumed to be co-located with the
BE
then H.225 AnnexG can be extended to cover those.
Vivek.
----- Original Message ----- From: "Paul E. Jones" paulej@packetizer.com To: "Roy, Radhika R, ALCTA" rrroy@att.com; "Klaghofer Karl ICN EN HC ID 14" Karl.Klaghofer@icn.siemens.de; "Horvath Ernst Siemens AT" ernst.horvath@siemens.at; "Paul K'" paul.k.reddy@intel.com; "BOUGANT Francois FTRD/DAC/ISS" francois.bougant@rd.francetelecom.com; "Miner Gleason" mgleason@cisco.com; "Euchner Martin ICN M SR 3" Martin.Euchner@icn.siemens.de Cc: "Vivek Bhargava" vbharga@cisco.com; "Orit Levin"
Sent: Sunday, December 23, 2001 9:48 PM Subject: Re: New draft of H.MMS.1
Radhika,
Now I'm terribly confused... I thought you wanted us to develop a
generic
mobility protocol (or set of protocols) that were not explicitly tied to H.323. In this message, you're proposing that we simply extend the H.323-based protocols. Did I miss something?
Paul
----- Original Message ----- From: "Roy, Radhika R, ALCTA" rrroy@att.com To: "Klaghofer Karl ICN EN HC ID 14" Karl.Klaghofer@icn.siemens.de;
"Paul
E. Jones" paulej@packetizer.com; "Horvath Ernst Siemens AT" ernst.horvath@siemens.at; "Paul K'" paul.k.reddy@intel.com; "BOUGANT Francois FTRD/DAC/ISS" francois.bougant@rd.francetelecom.com; "Miner Gleason" mgleason@cisco.com; "Euchner Martin ICN M SR 3" Martin.Euchner@icn.siemens.de Cc: "Vivek Bhargava" vbharga@cisco.com; "Orit Levin"
Sent: Saturday, December 22, 2001 11:59 AM Subject: RE: New draft of H.MMS.1
Hi, Paul and All:
I think that Karl's approach is opening up a big debate what has been
going on for many years and, some AT&T contributions made over the years
can
also be looked into. Other contributions including Intel's can also be looked into in this area.
What Paul has suggested is the DHCP-based "Discovery" of the GK. It is
in
generic sense, not so much specific about the mobile or non-mobile environment. I would consider Paul's suggestion has a different flavor
and
let us continue discussion along this line what is used in the generic Internet.
With respect H.22x, I have few questions. I do not know whether we
really
want to have a separate protocol to achieve the objectives. In the last conference call, we have seen that the objective this protocol is NOT
clear
because we have a protocol that is used among the BEs that is known as H.225.0 Annex G. We have also a protocol that is used among the GKs and
it
is known as H.225.0 RAS. So, why do we need a separate protocol like
H.22x
that to be used among the BEs? It will create more confusions.
So, the proposal is as follows:
- H.225.0 RAS and Q.931 is used among the GKs and no new protocol
will
be
developed that will be used among the GKs. Rather the same H.225.0 RAS
and
Q.931 protocol needs to be extended to serve the purposes for both non-mobile and mobile cases. (If we do not follow this fundamental
concept
of the protocol development, we will create more confusions.) Some contributions are already there (made over the years).
- H.225.0 Annex G is used among the BEs and no new protocol will be
developed that will be used among the BEs. Rather the same H.225.0 Annex
G
protocol needs to be extended to serve the purposes for both non-mobile
and
mobile cases. (If we do not follow this fundamental concept of the
protocol
development, we will create more confusions.)
Comments on H.22x:
- We have seen the contributions on H.22x and we discussed this in
the
last conference call. We have seen that this does not justify that we
need
to develop a separate NEW protocol. Rather the same objectives can be achieved extending H.225.0 Annex G in its address parameters. Only
couple
of
more alias addresses are needed to be added in H.225.0 Annex G.
- For security, we have seen that it needs to be global one. That is,
the
whole security model needs to address both mobile and non-mobile
situations
equally along with all other message sets other than AccessRequest.
- We have NOT seen a single justification why we need separate
protocols
like H.22x among the GKs or BEs while we have exiting protocols?
I like to see technical justifications why we need a separate
protocols
like H.22x among the BEs or GKs.
Best regards,
Radhika R. Roy rrroy@att.com
-----Original Message----- From: Klaghofer Karl ICN EN HC ID 14 [mailto:Karl.Klaghofer@icn.siemens.de] Sent: Tuesday, December 18, 2001 3:10 AM To: Roy, Radhika R, ALCTA; Paul E. Jones; Horvath Ernst Siemens AT;
Paul
K'; BOUGANT Francois FTRD/DAC/ISS; Miner Gleason; Euchner Martin ICN M SR 3 Cc: Vivek Bhargava; Orit Levin Subject: AW: New draft of H.MMS.1
Hi to all,
Another way of locating a GK which should be covered by the standard - especially for User Mobility - is that the RRQ is first sent to the GK
that
served this endpoint previously (last serving GK). This GK then
determines
typically based on User ID and Password entered by the mobile user
which
GK
to serve the mobile user (home gk). H.323 Alternate GK procedures are
then
used to redirect registration to the home gk, if required.
This works for Mobility within an administrative domain, where it is
anyway
easier to let the home gk serve the mobile user.
This also works for inter-domain communication with the difference
that
the
mobile user is not redirected to the home gk but served by the visited
gk.
Of course the visited gk has to find out the home domain to tell the
new
location update via H.22x.
Regards, Karl
-----Ursprüngliche Nachricht----- Von: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] Gesendet am: Dienstag, 18. Dezember 2001 02:04 An: Paul E. Jones; Horvath Ernst Siemens AT; Paul K'; BOUGANT Francois FTRD/DAC/ISS; Miner Gleason; Euchner Martin ICN M SR 3 Cc: Klaghofer Karl ICN EN HC ID 14; Vivek Bhargava; Orit Levin Betreff: RE: New draft of H.MMS.1
Hi, Paul:
I think that you have made a good point. Let us see whether the use of
DHCP
will have any problems.
Comments on Paul's proposal are highly welcomed.
Best regards, Radhika
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Sunday, December 16, 2001 9:34 PM To: Horvath Ernst; 'Paul K''; 'BOUGANT Francois FTRD/DAC/ISS'; 'Miner Gleason'; Roy, Radhika R, ALCTA; EUCHNER MARTIN Cc: KLAGHOFER KARL; Vivek Bhargava; Orit Levin Subject: Re: New draft of H.MMS.1
In the area where we describe GK discovery, I'd really like to see us
expand
on the use of DHCP. As you know, DHCP can provide a device with all
sorts
of parameters, from the domain name of the network, to DNS servers, to
its
IP addresses, to default gateways, etc. It would be nice to see if we
could
somehow signal what the GK (or list of GKs) should be for any H.323
device.
Failing that, we could propose that endpoints try to locate a GK by
looking
for an SRV record for "_h323_gk_". The endpoint could send an RRQ to
that
device and that device could send an RRJ with a list of alternate GKs
if
it
wishes to redirect the GK to a specific GK for registration.
One thing I would prefer not to use are the TXT records. We're
proposing
to
use SRV records in Annex O for resolving H.323 URLs. I'd like to
stick
with
the SRV for registration if DHCP assignment is not an option. The description of SRV records and TXT records in H.225.0 is in an
informative
section of H.225.0 that, in my opinion, we should consider removing
from
the
Recommendation... does it give us any value at this point?
Paul
----- Original Message ----- From: "Horvath Ernst" ernst.horvath@siemens.at To: "'Paul K''" paul.k.reddy@intel.com; "'BOUGANT Francois
FTRD/DAC/ISS'"
francois.bougant@rd.francetelecom.com; "'Miner Gleason'" mgleason@cisco.com; "'ALCOO''" rrroy@ATT.COM; "EUCHNER MARTIN" Martin.Euchner@icn.siemens.de Cc: "KLAGHOFER KARL" Karl.Klaghofer@icn.siemens.de; "'Paul E.
Jones'"
paulej@PACKETIZER.COM Sent: Friday, December 14, 2001 8:06 AM Subject: New draft of H.MMS.1
Dear mobility experts,
sorry for sending such a large file by mail, but the picturetel
server
keeps
refusing me.
Attached is an updated draft as input to next week's phone
conference.
It
obsoletes AVD-2139rev1 from the last conference call. Revision marks
in
this
document are against the original AVD-2139, not against
AVD-2139rev1.
Regards, Ernst