TR: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded

SAMOU Jean-claude FTRD/DAC/ISS jeanclaude.samou at RD.FRANCETELECOM.FR
Fri Sep 22 11:14:05 EDT 2000


Hi, Everyone:

Sorry for the disturbance. This is a re-transmission due to some mailing
errors.

-----Message d'origine-----
De: SAMOU Jean-claude FTRD/DAC/ISS
[mailto:jeanclaude.samou at RD.FRANCETELECOM.FR]
Date: mercredi 20 septembre 2000 18:01
À: ITU-SG16 at MAILBAG.INTEL.COM
Objet: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded


Hi, Everyone:

Sorry for not getting into the discussion earlier since I was out of station
for some time. I just logged into my PC and saw your interesting e-mail
discussion on mobility management protocols (in particular between the VLF
and HLF).

I would like to share here some concerns of Radhika Roy on this matter. As
he clearly points out, the HLF and VLF are only value-added functions which
are necessary for handling mobility of users. There is nothing specific in
VLF <-> HLF in terms of mobility with respect packet vs. circuit or
connection oriented vs connectionless, etc.

As you are probably aware of, the IMT-2000 group in ITU-T SG11 is currently
working on developing a common mobility management protocol which should
accomodate various users of different types of mobile systems (e.g. IS-41,
UMTS, etc). This is the well known FAMILY  concept in ITU-T SG11. SG16 and
SG11 had one joint meeting in the last Feb'00 in Geneva. During this
meeting, this mobility protocol work was briefly introduced by SG 11 and it
was recognized that the requirements & major concepts identified for
mobility in H.323 networks are very similar to those of IMT-2000 (since
IMT-2000 should also provide packet-based multi-media services), and a close
cooperation between these two groups is required on mobility and roaming
aspects for the benefits of H.323 and IMT-2000 systems. In addition, this
will allow the roaming of any users between different types of network (for
instance an H.323 user roaming into an IS-41 or UMTS network and
vice-versa). Therefore, I tend to disagree with Jaakko who says that
IMT-2000 is not defining (or intended for) packet-based networks. For
instance the concept of VLF and HLF are pretty much close to those of the
LMFv and LMFh in IMT-2000 (see ITU-T Rec. Q.1711) for the strict reason that
they are both server functions which handle mobility independently of the
transport networks. Then why not a common protocol for common mobility
requirements and functions? On the other hand, I agree that Extensions of
H.323 (e.g. H.225.0 [RAS, Q.931, Annex G]) need to be provided by Q.13/16
since they are very specific to the H.323 type of access.

Again, I would like to support Radhika in his analysis of trying to develop
a common solution that fits the need of any type of mobile users rather than
developing one VLF <-> HLF protocol for H.323, one VLF <-> HLF for H.321,
etc. Otherwise, it will be a BIG mess for network operators (as well for
manufacturers) and lead to have different protocols which may be
incompatible between themselves. This will also make the inter-networking
aspects very tough thereby preventing any global roaming of users.

FYI, I would also like to inform you that 3GPP has selected SIP for its
MULTIMEDIA stuff. In this case, how would it be possible to roam between a
3GPP network and H.323 network, and with other networks (not using
SIP)unless an inter-connecting pipe such as a common MM protocol (which
includes SIP mobility, H.323 mobility, IS-41 mobility, etc) is developed.

Therefore, I would suggest that we should rather work with a more global
picture of ITU (as supported by Radhika) than a narrow one limited to H.323
mobility only.

Let me be more positive now. I would really encourage SG16 and SG11 to
closely
cooperate together in order to develop this common protocol jointly for the
success of ITU. I believe that this step has already started at the joint
SG16-SG11 meeting in February 00. Why shoudn't this be continued?

Best regards,

Jean-Claude Samou, PhD
France Telecom R&D
38-40, rue du General Leclerc
92131 Issy les moulineaux
France

Tel: + 33 1 45 29 58 40
Fax: + 33 1 46 29 31 62




-----Message d'origine-----
De: Roy, Radhika R, ALCOO [mailto:rrroy at ATT.COM]
Date: mardi 19 septembre 2000 14:15
À: ITU-SG16 at MAILBAG.INTEL.COM
Objet: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded


Hi, Everyone:

Let me repeat it again:

We have applications H.323, H.321, etc. These are packet-based networks.
There are other protocols like H.324 etc, that are optimized for PSTN/ISDN
networks.

Now the application/middleware layer control protocol like H.245 is
applicable for all applications whether an application is sent over the
packet networks or circuit-switched networks.

Similarly, application/middleware layer VLF <-> HLF and other protocols are
nothing do with packet vs. circuit-switched networks. It MUST be a common
protocol. There is nothing specific in VLF <-> HLF with respect packet vs.
circuit or connection oriented vs connectionless. People are trying to
create confusions for fulfilling a VERY narrow objectives ignoring the BIG
picture of the ITU.

Even for the sake of argument, if we consider the applications only for the
packet-switched networks, then we MUST develop the generic protocols like
VLF <-> HLF and others that can be used by all protocols like H.323, H.321,
etc. that are used by the packet-switched networks.

The same argument is true for QOS, billing, authentication, directory, etc,
and others.

Let us not confuse things.

Let us take another case: RSVP, DiffServ, etc. are the network layer QOS
protocol. These network layer QOS services can be used by any applications
(e.g., H.323, SIP, etc.) over the IP network.

That is why, we MUST not develop one VLF <-> HLF protocol for H.323, one VLF
<-> HLF protocol for H.321, and another VLF <-> HLF protocol for H.324, etc.
It is a mess and defeats the fundamental purpose for creating of COMMON
standards by the ITU.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Jaakko Sundquist [mailto:jaakko.sundquist at nokia.com]
Sent: Monday, September 18, 2000 7:34 AM
To: ITU-SG16 at mailbag.cps.intel.com
Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded


Hi Radhika, Paul & others

Shortly, my understanding is that IMT-2000 is not defining protocols
suitable (or intended for) packet-based networks, i.e. H.323 Systems on top
of e.g. IP, but they concentrate on more general level definitions.
While I do think that we need to consider IMT-2000 as well as other 3G
standardization bodies (I would argue that 3GPP is the dominant one at the
moment) and use as much of the specifications available as possible, I still
think that we need to make our own specifications for H.323. Even if we just
re-use some existing protocols, the usage of these needs to be clearly
specified in the context of H.323.

-Jaakko

> -----Original Message-----
> From: EXT Roy, Radhika R, ALCOO [mailto:rrroy at att.com]
> Sent: 17. September 2000 3:48
> To: ITU-SG16 at mailbag.cps.intel.com
> Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H
> draft uploaded
>
>
> Hi, Paul:
>
> I am glad that you have asked this question.
>
> HLF and VLF are value-added functions, and these server functions are
> necessary for any mobile users. IMT-2000 is working to develop these
> protocols. SG16 and SG11 had one joint meeting in the last
> Feb'00 in Geneva.
> These protocols are VLF <-> HLF and others.
>
> All we (Q.13/16) need to do: An interface with the VLF by the
> H.323 GK.
>
> (An analogy can also given: H.245 is a common set of control
> protocol that
> is being used by H.323, H.324, and other applications.)
>
> If there are one or more functions are needed for any reasons that are
> specific to H.323, people can always augment that particular
> protocol. This
> is a fact of life.
>
> The same is also true for QoS, authentication, accounting,
> billing, and
> others.
>
> More importantly, IMT-2000 is dedicated for mobility.
>
> Our (Q.13/16) primary task is to extend the H.323 protocol
> for supporting
> mobility (as explained many times) is as follows:
>
> Part 1: Within the scope of Q.13/16: Extension of H.323
> (e.g., H.225.0 [RAS,
> Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs.
> (Contributions
> are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.)
>
> If we do NOT this part 1, we are NOT doing our primary job because the
> solution will NOT fly. We are rather "building a castle in the air."
>
> Best regards,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej at PACKETIZER.COM]
> Sent: Saturday, September 16, 2000 2:45 PM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H
> draft uploaded
>
>
> Radhika, et al,
>
> I have to confess that I have had no time to really follow
> the Annex H work,
> but I do have a question to toss out here:
>
> Why do you consider the VLF or HLF functions outside the
> scope of Q13/16?  I
> assume that these functions are IP-based (or at least used
> with the same
> call signaling transport as the H.323 system) and integrate
> with the H.323
> functions.
>
> You stated below that these functions are common for all
> mobile systems.  I
> will not argue that point, but will a common solution be the most
> appropriate for H.323 systems?  I would guess that trying to
> introduce a
> generic mechanism may or may not be the best solution for H.323.
>
> I'd like to hear counter arguments to yours.  Apparently
> others felt that
> these functions were necessary for H.323 systems and should be defined
> within the H.323 framework.
>
> Paul
>
> ----- Original Message -----
> From: "Roy, Radhika R, ALCOO" <rrroy at ATT.COM>
> To: <ITU-SG16 at mailbag.cps.intel.com>
> Sent: Friday, September 15, 2000 10:25 AM
> Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H
> draft uploaded
>
>
> > Hi, Everyone:
> >
> > The document MD-106 (H.323 Annex H) submitted by the editor remains
> > basically same from the fundamentally point of view. So,
> the comments
> > provided on the September 8 email (copy enclosed) remains
> the same as
> stated
> > earlier. The comments can be summarized as follows:
> >
> > The Annex should be divided into two parts:
> >
> > Part 1: Within the scope of Q.13/16: Extension of H.323
> (e.g., H.225.0
> [RAS,
> > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs.
> (Contributions
> > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.)
> >
> > Part 2: Outside the scope of Q.13/16: Back-end services related to
> Mobility
> > (or value-added services related mobility) containing VLF and HLF.
> >
> > So, it can be seen clearly that MD-106 (H.323 Annex H)
> submitted by the
> > editor does not contain the basic part 1 which is within
> the scope of
> > Q.13/16 (it rather contains part 2 which is outside the
> scope of Q.13/16).
> >
> > Best regards,
> > Radhika R. Roy
> > AT&T
> > +1 732 420 1580
> >
> >
> > -----Original Message-----
> > From: Roy, Radhika R, ALCOO
> > Sent: Friday, September 08, 2000 10:23 AM
> > To: ITU-SG16 at MAILBAG.INTEL.COM
> > Subject: Re: [H.323 Mobility:] H.323 Annex H status check
> >
> > Hi, Everyone:
> >
> > The draft does not contain the basic part: Extensions of
> H.323 (e.g.,
> > H.225.0 messages). Contributions are there (e.g., D.354 of
> SG16 Feb'00,
> > Geneva - reproduced as TD-31 in Portland [August 21-15, 2000]). GRQ
> messages
> > need to be removed to the base spec of H.323 because there
> is nothing
> > specific to be done with mobility. If it is used in the context of
> mobility,
> > the issues related to mobile need to be pointed out so that
> contributions
> > can be brought to address those issues. Contributions are
> there to note
> the
> > issues.
> >
> > The another suggestion is to make two parts of the Annex: 1. Basic
> extension
> > of H.323 (H.225.0, H.245: Terminals, GKs/BEs, GWs) and 2. Back-end
> services
> > related to Mobility (or value-added services related
> mobility)containing
> VLF
> > and HLF.
> >
> > Part 2 clearly does not have to be specific to H.323. It is
> a general
> > service related to mobility. Every application that needs
> mobility may
> like
> > to use these services. This will be addressed in the light
> of the all
> mobile
> > applications of all questions of all SGs of the ITU-T. So, it is
> > out-of-scope of Q.13/16 because Q.13/16 alone cannot makes
> this decision.
> >
> > Please note that Security (AuF) is also needed for the
> fixed users. So,
> this
> > is a generic service that needs to be developed for both
> fixed and mobile
> > users. So, it also belongs to the base H.323 spec. That is, any
> > specification related to AuF should be moved to the base
> H.323 spec as
> well
> > because it belong to both and the standard should be developed
> accordingly.
> >
> > For rapid determination, I would suggest to address part 1
> only in the
> first
> > phase.
> >
> > More specific technical comments will be given for each
> point once the
> > primary objectives are clarified.
> >
> > Best regards,
> >
> > Radhika R. Roy
> > AT&T
> >
> >
> > -----Original Message-----
> > From: Jaakko Sundquist [mailto:jaakko.sundquist at NOKIA.COM]
> > Sent: Thursday, September 14, 2000 7:28 AM
> > To: ITU-SG16 at MAILBAG.INTEL.COM
> > Subject: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
> >
> >
> > Hi all,
> >
> > I have uploaded MD-106 to URL:
> >
> ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-10
6_H323AnnexHDr
> aft.zip .
> The document is a cleaned up version of TD-42 of the Portland meeting  and
> contains only editorial changes(as the template used in the draft document
> so far was, for some reason, a total mess).
> The only "exeption" to this is the following correction. Section 8.1 of
> TD-42 included the text: "Reference points A and B are out of the scope of
> this Annex.", which has been removed and instead section 8.3 now includes
> the text: "Reference points B, C and D are out of the scope of this Annex
> (Hinter is included but only as an option in case that utilization of
> reference point A is not practical).".
> The reason for this change is that the text in TD-42 is, as I understand
> from Mr. Rissanen's comments, a typo and should have mentioned reference
> points B and C instead of A and B.
>
> ------------------------------------------------
> Jaakko Sundquist           *
> +358 50 3598281            * Audere est Facere!
> jaakko.sundquist at nokia.com *
> ------------------------------------------------
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com



More information about the sg16-avd mailing list