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(a)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(a)att.com>
To: "Vivek Bhargava" <vbhargava(a)cisco.com>; "Paul E. Jones"
<paulej(a)packetizer.com>; "Klaghofer Karl ICN EN HC ID 14"
<Karl.Klaghofer(a)icn.siemens.de>; "Horvath Ernst Siemens AT"
<ernst.horvath(a)siemens.at>; "Paul K'" <paul.k.reddy(a)intel.com>; "BOUGANT
Francois FTRD/DAC/ISS" <francois.bougant(a)rd.francetelecom.com>; "Miner
Gleason" <mgleason(a)cisco.com>; "Euchner Martin ICN M SR 3"
<Martin.Euchner(a)icn.siemens.de>
Cc: "Vivek Bhargava" <vbharga(a)cisco.com>; "Orit Levin" <orit(a)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:
>
> 1. 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.)
>
> 2. 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.)
>
> 3. 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(a)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(a)packetizer.com>
> To: "Roy, Radhika R, ALCTA" <rrroy(a)att.com>; "Klaghofer Karl ICN EN HC ID
> 14" <Karl.Klaghofer(a)icn.siemens.de>; "Horvath Ernst Siemens AT"
> <ernst.horvath(a)siemens.at>; "Paul K'" <paul.k.reddy(a)intel.com>; "BOUGANT
> Francois FTRD/DAC/ISS" <francois.bougant(a)rd.francetelecom.com>; "Miner
> Gleason" <mgleason(a)cisco.com>; "Euchner Martin ICN M SR 3"
> <Martin.Euchner(a)icn.siemens.de>
> Cc: "Vivek Bhargava" <vbharga(a)cisco.com>; "Orit Levin"
<orit(a)radvision.com>
> 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(a)att.com>
> > To: "Klaghofer Karl ICN EN HC ID 14" <Karl.Klaghofer(a)icn.siemens.de>;
> "Paul
> > E. Jones" <paulej(a)packetizer.com>; "Horvath Ernst Siemens AT"
> > <ernst.horvath(a)siemens.at>; "Paul K'" <paul.k.reddy(a)intel.com>; "BOUGANT
> > Francois FTRD/DAC/ISS" <francois.bougant(a)rd.francetelecom.com>; "Miner
> > Gleason" <mgleason(a)cisco.com>; "Euchner Martin ICN M SR 3"
> > <Martin.Euchner(a)icn.siemens.de>
> > Cc: "Vivek Bhargava" <vbharga(a)cisco.com>; "Orit Levin"
> <orit(a)radvision.com>
> > 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:
> > >
> > > 1. 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).
> > >
> > > 2. 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:
> > >
> > > 1. 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.
> > >
> > > 2. 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.
> > >
> > > 3. 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(a)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(a)siemens.at>
> > > To: "'Paul K''" <paul.k.reddy(a)intel.com>; "'BOUGANT Francois
> > FTRD/DAC/ISS'"
> > > <francois.bougant(a)rd.francetelecom.com>; "'Miner Gleason'"
> > > <mgleason(a)cisco.com>; "'ALCOO''" <rrroy(a)ATT.COM>; "EUCHNER MARTIN"
> > > <Martin.Euchner(a)icn.siemens.de>
> > > Cc: "KLAGHOFER KARL" <Karl.Klaghofer(a)icn.siemens.de>; "'Paul E.
Jones'"
> > > <paulej(a)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
> > > >
> > > >
> > >
> >
>
