H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6

[Jaakko Sundquist]

I guess you mean that you agree with all 4 points, not just the fourth
point, right (i.e. I guess there's a typo)?

-Jaakko

p.s. I didn't want to send this to the list...

> -----Original Message-----
> From: EXT Reddy, Paul K [mailto:paul.k.reddy at INTEL.COM]
> Sent: 07. September 2000 1:41
> To: ITU-SG16 at mailbag.cps.intel.com
> Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier -
> Mandate of
> Q. 13/1 6
>
>
> Hi Everyone,
>
> I agree with Mr. Jaakko Sundquist, Editor of H.323 Annex H,
> who made 4 point in this email.
>
> regards,
> Paul Reddy
> Editor of H.246 Annex E.1, Annex E.2
>
> Paul K. Reddy
> Roaming Services Capability Manager
> Mobile Data Services Area of Opportunity
> Applications and Services Lab
> Intel's Architecture Labs
> Intel Corporation
> Office Phone# +1 (503)-264-9896
> Mobile Phone# +1 (503)-807-9564
> Email: paul.k.reddy at intel.com
>
>
>
> -----Original Message-----
> From: Roy, Radhika R, ALCOO [mailto:rrroy at ATT.COM]
> Sent: Wednesday, September 06, 2000 9:33 AM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier -
> Mandate of
> Q. 13/1 6
>
>
> Hi, Everyone (including all Rapporteurs and WP 2 Chairman):
>
> Again, it is interesting to see how a very narrow view can
> create serious
> problems not only for a simple Annex, but also for the whole
> question, for
> the whole study group, and for all other study groups of the ITU-T.
>
> Time and again, it has been said that let us work within the
> mandate of
> Q.13/16 first and contributions had been made to clarify those points.
> Everything has been ignored just because few folks want to do
> something
> almost working like a close group without seeing the BIG
> picture of all
> questions of all SGs of the ITU-T. In fact, some joint
> meetings were also
> initiated between SG16 and SG11 to see how the HLFs, VLFs,
> and AuFs related
> protocols are being addressed elsewhere.
>
> Still, they are pushing the same thing just because few folks
> brought some
> contributions. Objections were put via contributions, emails,
> and verbal
> discussions. Even there is not a single editorial note in the document
> related to those things.
>
> A simple example will reveal the fact. We have discussed that
> there are
> serious problems to use GRQ messages to discover the GKs in mobile
> environment. Many contributions, emails, and verbal
> explanations have been
> provided. If you look into the present H.323 Annex H
> write-up, you will see
> that, as if, GRQ is the "Nirvana" for discovering the GK in mobile
> environment. Not a single word has been used even as an editorial note
> whether some members have raised the questions that there are
> problems need
> to be addressed for GRQs. The way the GRQ section has been
> written, it is a
> generic one and is nothing do with mobility. Rather, it suits
> to be added in
> the base H.323 spec. Many more examples can be given for each
> technical
> issue.
>
> This Annex has NOT done its first important task how to
> extend the H.323
> signaling messages (RAS, Q.931, Annex G) to solve the
> mobility problems for
> the H.323 entities (Terminals, GKs, BEs, GWs). In fact, it is
> the mandate of
> Q.13/16. Contributions are there, but everything has been ignored.
>
> Rather, Annex H has focused in some areas for which it has NOT got the
> mandate: Communications between VLFs <-> HLFs, VLFs <-> AuFs,
> HLF <-> AuFs,
> etc. These work items are not the charter of Q.13./16 alone.
> These are the
> areas for the joint work with all other questions of all SGs
> that deal with
> mobility. (In another example, even if H.320, H.321, or H.324
> wants to be
> used by mobile users, they can also use HLFs, VLFs, AuFs,
> etc. Similarly,
> all other mobile applications of all other SGs can also use
> these HLFs,
> VLFs, AuFs, etc. Take the case of AuF, it can also be used by
> the fixed
> user. There is nothing fency about this.)
>
> (More importantly, these additional entities have raised
> serious concerns:
> How does a GK/BE play a role in the overall process while
> "wild" suggestions
> have been made to use the Annex G protocol as well? It has created a
> "dangerous" mechanism to "by-pass" the very need of GKs/BEs.
> In fact, some
> members have boasted that they even do not see any need to go
> via GKs or BEs
> anymore so far mobility is concerned. As if, a "bomb " is
> about to be placed
> to break the very foundation of H.323 in the name of
> extending of H.323 for
> mobility.)
>
> More can be written for each technical issue, if needed. If
> one likes to see
> some of those points, please see the contributions that were
> submitted in
> the last Q.13/16 Portland meeting.
>
> Again, I am repeating the proposal for H.323 Annex H:
>
> 1. First, finish the extension of the existing H.323 base
> specs, and H.225.0
> (RAS, Q.931, Annex G)to support mobility among the H.323 entities:
> Terminals, GKs, BEs, and GWs. (see the contributions that are
> being made so
> far).
>
> 2. Second, develop a clear mandate whether the backend
> protocols like VLF
> <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of
> Q.13/16 only, or
> these protocols need to be worked with other SGs. (see the
> contributions
> that are being made so far).
>
> 3. Third, any protocols that re being used between VLF <->
> HLF, VLF <-> AuF,
> HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or
> its extension
> because these are separate protocols and serve completely
> different purposes
> although may useful properties (e.g., hopcount, etc.) of the Annex G
> protocol can be used for these protocols.
>
> It is very important to note that only item 1 is within the charter of
> Q.13/16 (H.323). All other items need to be addressed in the
> light of all
> mobility works of all questions of all SGs of the ITU by the
> working party
> chair and others.
>
> (My personal view is this: Let H.323 Annex H be scoped for
> item 1 only for
> now as a first step. It will also take a good amount of time
> to finish it.
> People are waiting to see that this happens first.
>
> To include other items, it may take a long time to have
> stable texts working
> with all SGs. This will then constitue the second step.)
>
> Best regards,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Jaakko Sundquist [mailto:jaakko.sundquist at NOKIA.COM]
> Sent: Wednesday, September 06, 2000 8:08 AM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier -
> Mandate of
> Q. 13/1 6
>
>
> Mr. Roy & other parties interested in H.323 Annex H,
>
> I found your posting addressing such general level issues
> that I think it is
> better to write a whole new mail as a response instead of
> responding to your
> claims and comments point by point...
>
> First of all you question the mandate of Annex H and its
> relation to the
> H.323 protocols. I find it very odd that you, without any
> real arguments to
> support for it, restrict the H.323 recommendations and thus
> also Annex H to
> handle ONLY the H.323 entities that have been defined prior
> to Annex H. The
> first real work that we got done for Annex H was to identify the
> functionalities that were (are) needed for Mobility
> Management and that were
> missing from H.323. This is how we (in an ad hoc meeting in
> Red Bank, in
> which you yourself was also present) came up with the four new H.323
> (functional) entities: HLF, VLF, AuF and IWF. Thus we have
> defined NEW H.323
> entities that were NOT present prior to Annex H. If it is
> illegal for us to
> define new H.323 entities (as you seem to claim), I can't see
> how the Border
> Element ever got defined, since it was not defined prior to
> the H.225 Annex
> G.
>
> Second, you seem to have defined the HLF, VLF and AuF as
> back-end services.
> This is NOT how I see them. I see back-end services as
> services that are NOT
> defined in the H.323 series recommendations, but that may be used by
> gatekeepers. In other words, back-end services or the
> functionalities they
> provide do NOT have any real definition in H.323, nor is it illegal to
> define new entities to H.323 that provide same kind of
> functionalities that
> could be achieved by using some back-end service. The
> back-end services that
> are used in some implementations of the H.323 system can
> undoubtedly be used
> for similar purposes as the new functional entities of Annex
> H are, but this
> does not make the new entities back-end services.
> Furthermore, the whole
> point (or mandate) of Annex H is to make recommendations that
> allow for
> different manufacturer's equipment to be used in different
> parts of the
> (mobility enhanced) H.323 system and still allow the
> users/terminals to move
> around in the network. Thus, in my opinion, it is one of the
> most important
> issues of Annex H to define, how the HLF, VLF and AuF
> communicate with each
> other. By just stating that they are back-end services we
> would in essence
> NOT define this, since back-end services are NOT defined in H.323.
>
> Third, the protocol(s) that are used between the HLF, VLF and
> AuF are still
> and open issue. The reason, why the H.225 Annex G protocol is
> used in the
> present draft is that it is the only protocol that has been seriously
> mentioned for this purpose. (Not only by the editor, but in various
> contributions as well, although the editor takes full
> responsibility of the
> current text in the draft.) It has been identified that the
> H.225 Annex H
> protocol already has the functionality for locating a User
> with a certain
> aliasAddress. Really roughly said, this functionality is "half" of the
> functionality that is needed for Mobility Management, the
> other half being
> the location updating procedures (which are not really
> addressed by the
> protocol yet). This is why the protocol is being considered
> for the Annex H
> usage. However, I would really like to see contributions
> suggesting other
> (preferably existing) protocols as well. Intel's contribution
> APC-1902, was
> the first one of this kind. These contributions should, however, state
> clearly how the suggested protocols should be used, if there is any
> ambiguity. I.e. just stating: "Use Mobile IP" is not enough
> (I'm not trying
> to refer to the APC-1902 with this comment), but information
> flows for the
> needed Mobility Management procedures should be presented
> (these include at
> least the location updating procedures, call establishment
> procedures, call
> termination procedures and unregistration procedures).
>
> Fourth, the needed enhancements of the RAS, Q.931, etc.
> protocols will be
> provided by finishing the information flows on chapter 10. I
> admit that not
> much of this has yet been done, but on the other hand, at
> least so far I
> have found that there is not too much that has to be done
> with respect to
> these protocols. (There will probably be certain message
> fields that will be
> mandatory for Mobile Terminals that are optional in H.323
> normally, etc.,
> but I don't see a need for too many new message fields or messages.)
>
> Last, but not least, we a really in a hurry, if we want to
> get the Annex H
> determined in November. This is why I suggest that the
> interested parties
> provide the contributions describing the usage of other
> protocols as the
> Mobility Management protocols of Annex H as soon as possible.
> Also it would
> be very nice, if these contributions were made modeling the
> chapter 10 of
> the current draft, so that incorporating them to the annex
> would be as fast
> as possible.
>
> I'm still a bit in the middle of the process of digesting the
> information I
> have gotten about the Annex H work in Portland, but I'll try
> to send a mail
> summarizing (what I think is) our current situation later this week
> (probably on Friday). I will also make a "cleaner" version of
> the TD-42a as
> the "starting point" for our interim work before Geneva (this
> new draft will
> not contain any other than editorial changes compared to TD-42a).
>
> ------------------------------------------------
> 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