- sg16-avd - lists.packetizer.com

17 April Mobility Conf call notes
by Guram Paul-LPG019 17 Apr '00

17 Apr '00

Hello mob group Please find below the notes from today's conference call: 1. Representatives from AT&T, Intel, Nokia, Ericsson, Siemens, Motorola and Alcatel discussed MD-017 from Radhika Roy (AT&T) at the conf.call. The use of the word 'network' was clarified in that we shall use it in conjunction with addressing, i.e. 'network point of attachment'. Thus the figure 1 in MD-017 is to be modified to reflect this. The word 'home' in this figure is presently to be kept only for the GK and the Zone even though there was discussion to delete this word completely from the figure. The use of this word 'home' may be omitted from the figure altogether after more discussion later. This figure is to be incorporated in Annex H to show the 'intra-zone' communication scenario. The editor, will also consider to add some text to explain the boxes VLF,HLF and AuF, if these are also included in the new version of Annex H. Also from the email discussion and today's discussion the editor will incorporate text (as he sees fit) in appropriate sections of Annex H. The next version of the Annex will show all the new text added by the editor (with suitable revision marks), and indicate at the beginning of the Annex that the text with no revision marks is the only agreed text so far. This is to ensure that readers of the new version are not misled as to which parts of the annex are the agreed text and which are still for discussion. The editor, Jaakko Sundquist, will endeavour to produce this new version one week before the next conference call which is to be on Tuesday 9 May at the same time. 2. Steve Terrill (Ericsson) will enhance his last contribution MD-016 to explain the reasons behind his proposals. Also he will propose/discuss discovery mechanisms for the VLF. 3. Radhika Roy will produce a contribution to explain why it is necessary to include the word 'home' in the 'network point of attachment', i.e. explain the 'home network point of attachment'. 4. Paul Guram will consult Mr Okubo to see if a separate dedicated reflector can be started for the mobility group's use. 5. A number of contributions have not been discussed yet due to lack of time. From the material in these contributions, the contributors will make proposals to enhance/add/delete text when the editor submits the new version next time. This would be a better way to progress the work and also ensure that no-one's contribution is inadvertently discarded without discussion. Paul

1 0

[Robustness] Conference call for Apr 20
by Terry L Anderson 17 Apr '00

17 Apr '00

The next H.323 Robustness teleconference will be as below. NOTE THAT THIS IS LATER IN THE DAY THAN PREVIOUS CALLS Conference Date: 20-APR-2000 Conference Time: 11:00 AM Eastern US (EDT) 10:00 AM Central 09:00 AM Mountain 08:00 AM Pacific 15:00 UT or GMT Bridge Telephone Number: 630-979-0100 Conference Code: 386137 It would be helpful is those that plan to call in send email to tla(a)lucent.com (NOT TO THE SG16 REFLECTOR) so that we have sufficient ports reserved. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

1 0

Re: srcAlternatives and destAlternatives
by Francois Audet 17 Apr '00

17 Apr '00

Cool. You got a good memory... -----Original Message----- From: Paul E. Jones [mailto:paul.jones@ties.itu.ch] Sent: Monday, April 17, 2000 12:06 PM To: ITU-SG16; Audet, Francois [SC9:4K02:EXCH] Subject: Re: srcAlternatives and destAlternatives Francois, This came from a contribution made by VocalTec (AVC-1157) in February 1997. This was introduced as a means of providing some redundancy to the endpoint. Unfortunately, just as with the alternate gatekeeper fields that were added to V2, there was no procedural text to explain the usage of these fields. So for the moment, the usage is undefined. Paul

1 0

srcAlternatives and destAlternatives
by Francois Audet 17 Apr '00

17 Apr '00

Does anybody have a clue what the srcAlternatives and destAlternatives fields in the ARQ are supposed to be? I did a search on H.225.0 and H.323 and the only occurence of it is in H.225.0 where the fields are described to be "a sequence of prioritized source endpoint alternatives for srcInfo, srcCallSignalAddress, or rasAddress" and "a sequence of prioritized destination endpoint alternatives for destinationInfo or destCallSignalAddress". Not very explicit... ----- François Audet Tel:+1 408 565 5675 <mailto:audet@NortelNetworks.com> mailto:audet@NortelNetworks.com Nortel Networks Fax:+1 408 565 2375 <http://www.nortelnetworks.com/> http://www.NortelNetworks.com

2 1

Re: [H.323 Mobility:] Comments to various mails
by Roy, Radhika R, ALARC 17 Apr '00

17 Apr '00

Hi, Jaakko: Pl. my comments below: Thanks, Radhika > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@nokia.com] > Sent: Monday, April 17, 2000 10:34 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] Comments to various mails > > Hi Radhika, > > Comments embedded... > > > > > Hi, Jaakko: > > > > I am providing a very quick response because we will have the > > conf call > > within 45 minutes. > Same here... > > > Second, the H.323 mobility protocol proposed by AT&T, Alcatel > > or others do > > NOT tie to any topology. The topology shown has come into > > play to provide > > descriptions so that people can understand, and we can say > > all requirements > > are met no matter what the topoloy is. For example, your > > contribution and > > references figures - we need to see whether all toplopies can > > be satisfied > > using the SAME protocol. > > I did not claim that the contributions were tied to any topology. I was > simply questioning the need to define or use the terms: home/visited > network/zone. [Roy, Radhika R] There shall be ONLY reference to the network address [home/visiting/visited/target] because "network" itself does NOT mean anything clearly. It is an OPTION, not mandatory. The contributions explain that what the benefits are: 1. To hide network address as the mobile moves from one place to another if needed. For example, a mobile may communicate with the other party without revealing its present network point of attachment, while the other party may be assuming the mobile is still in its home network point of attachment. The mobile can keep its privacy. (Mobile also allows to keep privacy.) 2. In multimedia communications environment, it may allow, if needed, to treat different media differently. For example, audio and/or video may be directed to the mobile's present network point of attachment, while data may be sent to my home network point of attachment (for storage or other purposes). 3. A service provider may be able to DIFFERENTIATE services based on the home network point of attachment (because a service may be subscribed in mobile's home domain/zone with a certain agreement and mobile's home network point of attachment may provide one of the most IMPORTANT identities to accomplish this). 4. To Facilitate for keeping track of the mobile user's profile based on the home network point of attachment in addition to other parameters stored in the HLF/VLF by the service provider. 5. It may so happen that a mobile may reveal the network point of attachment (e.g., audio) while it may not reveal the network point of attachment for data because of security reason. As a result, the communications may happen like this: Real-time audio and video are coming directly between the calling parities while data can shared from mobile's home network point of attachment without revealing its address. 6. There can other benefits in keeping its "home" network point of attachment known as a reference point (similar "benefits" along the line "home administrative domain"). 7. In the same token, visiting/visited/target network point of attachment is useful to keep references in managing the mobility especially by the service providers. For example, it the target network point of attachment can be predicted or supplied by the mobile user at the time of registration, a service provider can make planning of the resources ahead of the time to provide services before the mobile can move in that zone/domain. With respect to home zone/GK, it is another reference from mobility management point of (similar "benefits" along the line "home administrative domain"). > > > > Third, no contribution (AT&T, Alcatel, or Ericsson) has > > suggested that HLF > > or VLF has to belong to a zone or by couple of zones or otherwise. > > This is exactly why I do not see any point in defining home/visited zone. > Or > if we do define them the home zone should be clearly defined in such a way > that it does not imply that the HLF is a part of the home zone, but home > zones are all the zones that belong to the Home Administrative Domain. [Roy, Radhika R] This is helpful from mobility management point of view because association is made via the GKs. Yes, you are right that home zone belongs to the home adm domain, but not ALL zones of a given adm domain are the mobile's home zone. There is only ONE zone is the mobile's home zone. This distinction is very helpful from mobility management point of view in H.323. Yes, I agree the home zone definition should NOT interfere with the definition of HLF. An HLF may contain the information of many one or many home zones of many mobile users of a given Adm domain. Now HLF is a database behind the GK that keeps the permanent information including mobile's home network point of attachment. > > > > I hope that you will NOT mis-interpret the intend of the main > > idea behind > > the contributions. > > I don't think so and I do think that we have some valuable contributions > for > this teleconference and they will certainly help the progress of the work. [Roy, Radhika R] I appreciate. I am sorry to see that I could not choose the right word. I take my comments off. > -Jaakko

1 0

Re: Should we Break H.323 Model for Mobility?
by Roy, Radhika R, ALARC 17 Apr '00

17 Apr '00

Hi, Steve: Excellent! HLF/VLF: Definitely, I agree that we need to clarify the roles of HLF, VLF, and GKs very clearly because this is the heart of the mobility solution. I guess that we have identified the functions of HLF and VLF. In my contributions, I have explained as follows: 1. Intra-domain: Populate the HLF database through registration [not statically, but dynamically] (although the HLF may not be needed to be used for mobility management). Call flows show how HLF is used. I left the VLF function untouched. However, VLF can be used, if needed, for managing the change in network point of attachments. 2. Intra-Domain/Inter-Domain: Both HLF and VLF are needed. Some call flows are there to explain the role of these entities. You are right that we may have to explain more about HLF and VLF. Is it possible to explain more via short contributions or emails so that we all can agree with you arguments? GK Discovery: A note to Laurent Thiebaut/Nicolas Tran: I understand from the conference call, you might be another efficient mechanism to discover the GK using the DNS method (I hope that the process would be dynamic). Can you please send us a contribution related to this so that we can compare between H.323's GRQ/GCF/GRJ, proposed (mine) MGA, and your proposed DNS method? I have provided explanation via contributions, emails, and conference call why MGA is better than GRQ/GCF/GRJ. We like to see your proposed method. Please note that we may make these three as a part of the H.323 standard. Let people implement whatever mechanism best for them. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Stephen Terrill [SMTP:stephen.terrill@ericsson.com] > Sent: Monday, April 17, 2000 1:01 PM > To: Roy, Radhika R, ALARC > Cc: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Should we Break H.323 Model for Mobility? > > Hi Rardhika, > > I agree that we need to register with the gatekeeper, however I extend > that to say, the gatekeeper could be at home. > > I think that we need to clarify the roles of the HLF, VLF, GKs etc before > we can move further forward. > > Regards, > > ..//steve > > "Roy, Radhika R, ALARC" wrote: > > > Hi, Steve: > > > > Your statement appears that you are agreeing with the registration with > the > > GK that is the basic foundation of H.323. (However, your contribution > does > > NOT clearly indicate this.) It is a very good news. > > > > Contributions are there what roles to be performed by the VLF, HLF, and > > home/visiting/visited/target GK/zone/domain. We like to see where you > differ > > and why, and your suggestions. > > > > Please also see my subsequent emails what we need to be done to extend > our > > model to be consistent with H.323 as well as how we can reconcile all > > contributions: AT&T, Alcatel, and Ericsson. > > > > Best regards, > > Radhika R. Roy > > AT&T > > > > -----Original Message----- > > From: Stephen Terrill [mailto:stephen.terrill@ericsson.com] > > Sent: Sunday, April 16, 2000 5:00 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Should we Break H.323 Model for Mobility? > > > > Hi Roy, > > > > I feel that this email places more assumptions into the role of the VLF, > > HLF, visited GK, and home GK than we have agreed upon. Certainly the > model > > that we have proposed hasn´t stopped registration with the gatekeeper. > > > > I think that we need to agree upon the roles of the particular entities > > befor embarking upon concluding that something breaks the H.323 model. > > > > Regards, > > > > ..//steve > > > > "Roy, Radhika R, ALARC" wrote: > > > > > Hi, Everyone: > > > > > > H.323 has some definite architectural notion such as terminal, GK, GW, > MCU > > > and(MC, MP). One of the fundamental corner stones is the GK. The H.323 > > > entities (e.g., terminals, GWs) register with the GK. A GK manages a > zone > > > with the information of all registered users along with other > functions > > > (e.g., bandwidth, resource management, etc). > > > > > > The "registration" with the GK is the fundamental corner stone of > H.323 > > > where an association is made by each user. That is, a GK becomes the > basic > > > source to have the information related to each user. > > > > > > H.323 mobility protocol MUST also follow the same H.323 architectural > > > concept. If this basic notion is not maintained, it breaks the basic > > > foundation of H.323. > > > > > > It appears that H.323 mobility likes to define additional databases > like > > > VLFs and HLFs that will store the information related to the mobile > users. > > > These databases are supposed to help the function of a GK in order to > > manage > > > the mobility related information. > > > > > > If people think that an H.323 will be able to register with a VLF > > directly, > > > does it not mean we are by-passing the basic foundation of H.323 > model? > > Does > > > it not opening the entirely a new set of problems in H.323? It will > create > > a > > > parallel architecture like GK in H.323 what is not needed at all > because > > > solutions have provided that are consistent with H.323 model and there > is > > no > > > need to do this. We probably have to do all over again what we have > done > > for > > > the GKs and BEs. We inviting unnecessary problems that are yet to > imagine > > > where we may end up with. Why do we need to do that if one can do this > > using > > > the consistent H.323 model of GK? > > > > > > In another situation, we have to go step-by-step. First intra-zone, > then > > > inter-zone, and last of all inter-domain. Contributions are there to > > address > > > those problems. > > > > > > The mobile users that move between cells, those cells are expected > > primarily > > > remain the control of a given GK (in some cases it may be two GKs). > These > > > scenarios mostly seem to be intra-zone and inter-zone and may involve > a > > > single service provider. Of course, there will also be the calls > between > > the > > > two adm domains of two service providers. > > > > > > More importantly, solutions are inter-dependent. That is, we cannot > > address > > > the problems of inter-zone without knowing the intra-zone. In the same > > > token, we cannot address the inter-domain problems without knowing the > > > inter-zone problem. Contributions are there. Let us proceed > accordingly. > > > > > > Last of all, I am reminding the mess that we have made in Annex G. Now > > > people are hungry to use the more powerful and efficient Annex G > messages > > > between the GKs. Contributions were brought to do this, but the > proposals > > > had been rejected by a very few. Who is suffering? > > > > > > Best regards, > > > Radhika R. Roy > > > AT&T >

1 0

Re: Should we Break H.323 Model for Mobility?
by Roy, Radhika R, ALARC 17 Apr '00

17 Apr '00

Hi, Steve: Your statement appears that you are agreeing with the registration with the GK that is the basic foundation of H.323. (However, your contribution does NOT clearly indicate this.) It is a very good news. Contributions are there what roles to be performed by the VLF, HLF, and home/visiting/visited/target GK/zone/domain. We like to see where you differ and why, and your suggestions. Please also see my subsequent emails what we need to be done to extend our model to be consistent with H.323 as well as how we can reconcile all contributions: AT&T, Alcatel, and Ericsson. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Stephen Terrill [mailto:stephen.terrill@ericsson.com] Sent: Sunday, April 16, 2000 5:00 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Should we Break H.323 Model for Mobility? Hi Roy, I feel that this email places more assumptions into the role of the VLF, HLF, visited GK, and home GK than we have agreed upon. Certainly the model that we have proposed hasn´t stopped registration with the gatekeeper. I think that we need to agree upon the roles of the particular entities befor embarking upon concluding that something breaks the H.323 model. Regards, ..//steve "Roy, Radhika R, ALARC" wrote: > Hi, Everyone: > > H.323 has some definite architectural notion such as terminal, GK, GW, MCU > and(MC, MP). One of the fundamental corner stones is the GK. The H.323 > entities (e.g., terminals, GWs) register with the GK. A GK manages a zone > with the information of all registered users along with other functions > (e.g., bandwidth, resource management, etc). > > The "registration" with the GK is the fundamental corner stone of H.323 > where an association is made by each user. That is, a GK becomes the basic > source to have the information related to each user. > > H.323 mobility protocol MUST also follow the same H.323 architectural > concept. If this basic notion is not maintained, it breaks the basic > foundation of H.323. > > It appears that H.323 mobility likes to define additional databases like > VLFs and HLFs that will store the information related to the mobile users. > These databases are supposed to help the function of a GK in order to manage > the mobility related information. > > If people think that an H.323 will be able to register with a VLF directly, > does it not mean we are by-passing the basic foundation of H.323 model? Does > it not opening the entirely a new set of problems in H.323? It will create a > parallel architecture like GK in H.323 what is not needed at all because > solutions have provided that are consistent with H.323 model and there is no > need to do this. We probably have to do all over again what we have done for > the GKs and BEs. We inviting unnecessary problems that are yet to imagine > where we may end up with. Why do we need to do that if one can do this using > the consistent H.323 model of GK? > > In another situation, we have to go step-by-step. First intra-zone, then > inter-zone, and last of all inter-domain. Contributions are there to address > those problems. > > The mobile users that move between cells, those cells are expected primarily > remain the control of a given GK (in some cases it may be two GKs). These > scenarios mostly seem to be intra-zone and inter-zone and may involve a > single service provider. Of course, there will also be the calls between the > two adm domains of two service providers. > > More importantly, solutions are inter-dependent. That is, we cannot address > the problems of inter-zone without knowing the intra-zone. In the same > token, we cannot address the inter-domain problems without knowing the > inter-zone problem. Contributions are there. Let us proceed accordingly. > > Last of all, I am reminding the mess that we have made in Annex G. Now > people are hungry to use the more powerful and efficient Annex G messages > between the GKs. Contributions were brought to do this, but the proposals > had been rejected by a very few. Who is suffering? > > Best regards, > Radhika R. Roy > AT&T

2 1

Re: [H.323 Mobility:] Comments to various mails
by Jaakko Sundquist 17 Apr '00

17 Apr '00

Hi Radhika, Comments embedded... > > Hi, Jaakko: > > I am providing a very quick response because we will have the > conf call > within 45 minutes. Same here... > Second, the H.323 mobility protocol proposed by AT&T, Alcatel > or others do > NOT tie to any topology. The topology shown has come into > play to provide > descriptions so that people can understand, and we can say > all requirements > are met no matter what the topoloy is. For example, your > contribution and > references figures - we need to see whether all toplopies can > be satisfied > using the SAME protocol. I did not claim that the contributions were tied to any topology. I was simply questioning the need to define or use the terms: home/visited network/zone. > > Third, no contribution (AT&T, Alcatel, or Ericsson) has > suggested that HLF > or VLF has to belong to a zone or by couple of zones or otherwise. This is exactly why I do not see any point in defining home/visited zone. Or if we do define them the home zone should be clearly defined in such a way that it does not imply that the HLF is a part of the home zone, but home zones are all the zones that belong to the Home Administrative Domain. > > I hope that you will NOT mis-interpret the intend of the main > idea behind > the contributions. I don't think so and I do think that we have some valuable contributions for this teleconference and they will certainly help the progress of the work. -Jaakko

2 1

Re: [H.323 Mobility:] Comments to various mails
by Roy, Radhika R, ALARC 17 Apr '00

17 Apr '00

Hi, Jaakko: I am providing a very quick response because we will have the conf call within 45 minutes. First, H.323 has the abstraction of network address (or point of attachment). So, all contributions of AT&T and other companies refer to that only. Second, the H.323 mobility protocol proposed by AT&T, Alcatel or others do NOT tie to any topology. The topology shown has come into play to provide descriptions so that people can understand, and we can say all requirements are met no matter what the topoloy is. For example, your contribution and references figures - we need to see whether all toplopies can be satisfied using the SAME protocol. Third, no contribution (AT&T, Alcatel, or Ericsson) has suggested that HLF or VLF has to belong to a zone or by couple of zones or otherwise. All contributions are saying that HLFs and VLFs are behind the GKs. I hope that you will NOT mis-interpret the intend of the main idea behind the contributions. Again, protocols defined is NOT dependent on any topology. The contribution shows how the protocol can satisfy when this is used in the context of any topology that people can think of so that nothing is missed from the protocol. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@nokia.com] > Sent: Monday, April 17, 2000 9:43 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [H.323 Mobility:] Comments to various mails > > Hi all, > > It certainly seems that we have some discussion going on in the reflector. > I > haven't read the mails since thursday and there really has been a flood of > them, so I'll try to gather all my comments in this message. > > Radhika, thanks to our discussions last week I have finally understood > your > intentions on a couple of issues. First the issue of home/visited network. > I > think I now understand what you mean when you say that a zone may include > more than one network (a part of the zone runs on IP and another part on > ATM > for instance), but I still fail to see, why we should define such > concepts, > the H.323 layer should not really be concerned what the underlying network > type is. Furthermore, you made the argument that since H.323 has defined > the > topology of the H.323 systems in terms of network address/zone/domain we > should also define home/visited network address/zone/domain. I do not > agree > on this. So far I have not seen any reason for defining any other of these > concepts than the already defined Home/Visited Administrative Domain. The > only important issue with these home/visited concepts in my mind is the > location of the HLF of the user and I would argue that the entity > administering some part of the network should also own the HLFs in that > part > of the network. Thus defining the Home Administrative Domain of a user as > the Domain that contains the HLF of the user makes sense, but since we are > not binding the HLF to any particilar zone or network we do not need to > define or use the terms home zone/network. > Secondly, I think I understand, albeit somewhat vaguely, now, what exactly > you are meaning with Intra-zone, Inter-zone and Inter-domain > communications. > The difficulty with these terms in the context of Annex H is, however, > that > traditionally these terms have been used in H.323 only when there is a > call > involved. In other words, we haven't talked about e.g. an Inter-zone > registration procedure previously in H.323. The problem when using (at > least) the terms Intra/Inter-zone with the Annex H work is that we have > not > made any assumptions about the relationships of the mobility functional > entities and zones, i.e. a VLF or a HLF is not defined to be a part of any > zone. Thus, when you are talking about Inter-zone or Inter-domain > communications for e.g. the terminal/user registration or location > updating > procedure, what exactly are you meaning? My guess is that the division > that > you are referring to, is based on the previous location of the User, i.e. > in > the same zone or another zone, am I correct? Anyway, I'm quite sure that > we > need to address all the issues that you are thinking of, but dividing the > work in steps defined by the Intra/Inter-zone/domain communications is not > the best approach in my opinion. > > Steve, I think that we need to clarify the issue of home/visited domain > execution of services, so that both of these models are understood by all > the members of the group. Maybe some co-work could be done by us? > > As for the discussion on "not breaking up the current H.323 model", I'll > just say that I share the opinion that all registrations, etc. should be > done via the gatekeeper in order to preserve the old H.323 model. I see no > point in doing the registration straight to the VLF. I'm not quite sure, > what Steve's contribution was all about in this respect, but we'll > probably > be discussing that in the teleconference. > > ------------------------------------------------ > Jaakko Sundquist * > +358 50 3598281 * Audere est Facere! > jaakko.sundquist(a)nokia.com * > ------------------------------------------------

1 0

[Robustness] Minutes and Next telecon is April 20, 11AM EST USA
by Maureen Stillman 17 Apr '00

17 Apr '00

Minutes of H.323 Robustness Teleconference - April 12, 2000 Prepared by Maureen Stillman, Nokia Next Teleconference: Scheduled for April 20, 2000 11AM EST USA hosted by Lucent Action items from 4/6/2000 teleconference: 1. Post meeting minutes to mailing list 2. Jorg Ott will provide failure scenarios for gatekeepers for the Robustness Framework document. 3. Review Terry Anderson's H.225 and H.245 state machine document. We need to begin to determine what state information should be kept and how it should be restored under different failure scenarios. 4. Review IETF's SCTP and DDP protocols. Randy Smith and Qiaobing Xie of Motorola will join us on 4/20 to answer questions about these protocols. Attending the 4/6/2000 teleconference: Maureen Stillman maureen.stillman(a)nokia.com Sasha Ruditsky sasha(a)tlv.radvision.com Paul Jones paul.jones(a)ties.itu.int Terry Anderson tla(a)lucent.com Rex Core, Lucent (please send e-mail address) Mohash and Tim of Trillium (please send e-mail address) Timothy Sipsey Timothy.Sipsey(a)Aspect.com Summary of Teleconference: Discussion of SCTP and DDP SCTP is about to become an RFC and can be referenced in the appropriate time frame for H.323v4, but DDP will not be ready in time to be referenced. An advantage of SCTP versus TCP: Using TCP, a socket on one end or another can fail. SCTP knows about alternate sockets and can perform fail over. Debate concerning Annex E and DDP: During this debate several issues/requirements were highlighted: 1) Endpoints need to incur a minimum amount of overhead in supporting robustness protocols 2) Amount of extra network traffic generated for robustness purposes must be minimized 3) We must support robustness procedures that include conference calls 4) We need to support restoring state information "in intermediate points" that is for gatekeepers, etc. We need to examine the overlap between DDP and Annex E. Should we use both or just one or the other? If we just use Annex E, then there is no concept of a pool of resources that can handle fail over. DDP also has a built in mechanism to store state and gives us a place to store check pointed state information. If we don't use this mechanism, then we have to invent one. We also need to reestablish state information at the intermediate points (i.e. at gatekeepers) as well in the event of a failure. DDP supports a mechanism for this. We need to have minimum complexity at the endpoints. There is a concern about the amount of overhead incurred at the endpoint to implement DDP. Randy Stewart will supply us with some numbers on the size of a representative DDP implementation. If we use Annex E as the transport, then we need to have end-to-end acknowledgements. We could use Annex E to guarantee delivery of the messages (hop by hop) and use DDP for resource pooling and fail over. Robustness protocols need to generate a minimum of network traffic to perform these functions. There is also a concern that robustness for conferencing be supported. For example, if an H.245 message is sent that establishes that the floor was transferred, then if this message gets lost, then the conference call has a problem. We are still debating the issues at this stage and need further discussion to come to some conclusion. -- maureen Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 IP Voice Networks Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman(a)nokia.com www.nokia.com

2 1

[H.323 Mobility:] Comments to various mails
by Jaakko Sundquist 17 Apr '00

17 Apr '00

Hi all, It certainly seems that we have some discussion going on in the reflector. I haven't read the mails since thursday and there really has been a flood of them, so I'll try to gather all my comments in this message. Radhika, thanks to our discussions last week I have finally understood your intentions on a couple of issues. First the issue of home/visited network. I think I now understand what you mean when you say that a zone may include more than one network (a part of the zone runs on IP and another part on ATM for instance), but I still fail to see, why we should define such concepts, the H.323 layer should not really be concerned what the underlying network type is. Furthermore, you made the argument that since H.323 has defined the topology of the H.323 systems in terms of network address/zone/domain we should also define home/visited network address/zone/domain. I do not agree on this. So far I have not seen any reason for defining any other of these concepts than the already defined Home/Visited Administrative Domain. The only important issue with these home/visited concepts in my mind is the location of the HLF of the user and I would argue that the entity administering some part of the network should also own the HLFs in that part of the network. Thus defining the Home Administrative Domain of a user as the Domain that contains the HLF of the user makes sense, but since we are not binding the HLF to any particilar zone or network we do not need to define or use the terms home zone/network. Secondly, I think I understand, albeit somewhat vaguely, now, what exactly you are meaning with Intra-zone, Inter-zone and Inter-domain communications. The difficulty with these terms in the context of Annex H is, however, that traditionally these terms have been used in H.323 only when there is a call involved. In other words, we haven't talked about e.g. an Inter-zone registration procedure previously in H.323. The problem when using (at least) the terms Intra/Inter-zone with the Annex H work is that we have not made any assumptions about the relationships of the mobility functional entities and zones, i.e. a VLF or a HLF is not defined to be a part of any zone. Thus, when you are talking about Inter-zone or Inter-domain communications for e.g. the terminal/user registration or location updating procedure, what exactly are you meaning? My guess is that the division that you are referring to, is based on the previous location of the User, i.e. in the same zone or another zone, am I correct? Anyway, I'm quite sure that we need to address all the issues that you are thinking of, but dividing the work in steps defined by the Intra/Inter-zone/domain communications is not the best approach in my opinion. Steve, I think that we need to clarify the issue of home/visited domain execution of services, so that both of these models are understood by all the members of the group. Maybe some co-work could be done by us? As for the discussion on "not breaking up the current H.323 model", I'll just say that I share the opinion that all registrations, etc. should be done via the gatekeeper in order to preserve the old H.323 model. I see no point in doing the registration straight to the VLF. I'm not quite sure, what Steve's contribution was all about in this respect, but we'll probably be discussing that in the teleconference. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------

1 0

Re: Q12-14/16 Rapporteur meeting in Osaka
by Sakae OKUBO 16 Apr '00

16 Apr '00

Dear Mr. Reddy, >Please assign me an APC number for " H.246 Annex E white paper draft" APC-1757 has been allocated to your draft white contribution. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

unsubscribe
by Henry H. Wong 16 Apr '00

16 Apr '00

unsubscribe Best Regards, Henry H. Wong, Chairman CEO, SS8 Networks Inc. "SS8 is the signaling and service solutions for the Internet, just like SS7 for the PSTN" E-mail: Henry(a)SS8Networks.com Cellular #: (408) 234-6810 Worldwide Headquarters: Silicon Valley 2025 Gateway Place, Suite 318, San Jose, CA 95110 My Office: (408) 501-2108 Fax: (408) 501-2101 Main #: (408) 501-2100 Advanced R&D Center: Silicon Valley North 135 Michael Cowpland Drive, Suite 200, Kanata, Ontario, K2M 2E9, Canada My Office: (613) 592-3798 Fax: (613) 592-9634 Main #: (613) 592-8450 ***************************************************************************** This document, and any documents attached to this e-mail, contain information from SS8 Networks Inc., and are for the sole use of the above individual or entity. Such information may be privileged, confidential or exempt from disclosure under law. Any other dissemination, distribution or copying of this communication is strictly prohibited. Please notify us immediately by telephone if you are not the intended recipient and return the original message to us at the above address. We will reimburse your reasonable phone and postage expenses for doing so. *****************************************************************************

1 0

Comparison of Mobility Contributions and Combined Proposal that i s Consistent with H.323 Standard
by Roy, Radhika R, ALARC 16 Apr '00

16 Apr '00

Hi, Everyone: It is an attempt to streamline our discussions for the conference call (April 17) so that we can save time while I am my inputs. We have seen some contributions in solving the problems for intra-zone (AT&T), inter-zone/intra-domain (Alcatel, AT&T, and Ericsson [?]) and inter-domain (Alcatel and Ericsson) communications. Here are some high-level comments and proposed combined proposal related to those contributions: 1. Intra-Zone, 2. Inter-Zone/Intra-Doamin, and Inter-Domain. 1. INTRA-ZONE AT&T contribution (MD-017) deals with the intra-domain communication that describes: a. Mobile communications environments, b. Discovery, c. Registration, and d. Intra-Network Roaming. However, some aspects of Alcatel's contribution (MD-0XX) can be applicable for intra-zone communications as well. A. Mobile Communications Environment The highly cellular (wireless)-based mobile environment where 100s and 1000s of users entering and leaving a cell requires that the new discovery message like MGA (AT&T's contribution MD-017) is needed to discover the GK for signaling EFFICIENCY (while GRQ either multicast or non-multicast can be used in complimentary manner if the MGA message is not received within a certain period of time). It may be mentioned that mobile IP also uses the similar mechanism in the network layer for discovery. B. Discovery MGA message, which is appropriate in a highly mobile environment as stated in A, will discover the GK. The same discovery mechanism can be used for all cases: Intra-Zone, Inter-Zone, and Inter-Domain. Proposal to accept the New MGA Message for Discovery: · Let us accept the new MGA message for discovery (in combination with GRQ/GFC/GRJ message with multicast/non-multicast) that can be used for all cases: Intra-Zone, Inter-Zone, and Inter-Domain. C. Registration Like Rec. H.323 , this contribution is consistent with the fact that the association of the mobile entities has to be made with the GK through the GK. The same registration mechanism can be used for cases: Intra-Zone, Inter-Zone, and Inter-Domain. However, we believe that the HLF identities, like Alcatel's contribution (and VLF identities like Ericsson's to make their proposal consistent with the H.323 standard) contribution can also be passed during the registration process. The important point that I am making is that the HLF and VLF Ids, previously not known to the mobile, can be passed to the mobile by the GK during the registration confirmation (RCF). Proposal for the extended RRQ/RCF/RRJ: · The proposal is that we can combine AT&T, Alcatel, and Ericsson proposal together to create the new extended RRQ, RCF, and RRJ message that can be used, as indicated above, for the mobile environment in all cases: Intra-Zone, Inter-Zone, and Inter-Domain. 2. INTER-ZONE (INTRA-DOMAIN) Both AT&T (MD-018) and Alcatel (MD-0XX) address the inter-zone/intra-domain communications that are consistent with the H.323 standard. A. Discovery AT&T (MD-018) describes the discovery of the GK using the MGA message if the GK is not priori known. Proposal: · Let us accept the new MGA message as stated above for discovery in the highly mobile environment. B. Registration and Location Updates For registration, both AT&T (MD-017) and Alcatel (MD-0XX) contribution are in consistent with the H.323 standard because the association of the mobile entities are done via the GK. However, there some minor variations in these two proposals that seem to be complementary. For example, AT&T contribution describes that there are couple of possible ways for exchanging the mobility related information: Extension of LRQ or Creation of New Mobility Binding Messages for intra-domain (Extension of accessRequest Message or Creation of New Mobility Binding Messages for inter-domain). Ericsson's proposal shows that we need to extend the LRQ message. In addition, we can add HLF Ids as stated earlier (we can also reconcile Ericsson's proposal to pass the VLF Ids during the registration). It has to be clarified whether the pre-call setup messages like ARQ/ACF/ARJ messages to be extended or not. Although Alcatel's proposal shows only one registration scenario with one HLF architecture, it is also possible to have other scenarios as shown in AT&T's contribution using the SAME protocol. · Proposal for the extended RRQ/RCF/RRJ: The proposal is that we can combine AT&T, Alcatel, and Ericsson proposal together to create the new extended RRQ, RCF, and RRJ message that can be used, as indicated above, for the mobile environment in all cases: Intra-Zone, Inter-Zone, and Inter-Domain. · Proposal for Location Updates related to Mobility: The proposal is that we can combine AT&T and Ericsson proposal together to have all the mobility parameters for the mobile users in the signaling messages for intra-domain communications either creating new mobility binding messages or extending the LRQ/LCF/LRJ Messages (advantages and disadvantages of the two methods can seen in AT&T proposal). · Proposal for ARQ Message: We need to investigate whether the ARQ/ACF/ARJ messages to be extended. C. Call Establishment Once we decide about discovery, registration, and location update messages, the call establishment can be done in several ways. The call scenario shown in Alcatel's proposal is one of the reasonable ways to do this. AT&T may also like to explore the alternative call scenarios in the subsequent contributions as well so that we can discuss pros and cons for each. The most important conclusion seems to be that we do NOT need to create any new signaling messages for the call establishment. 3. INTER-DOMAIN Both Alcatel (MD-0XX) and Ericsson (MD-0XX) have contributions in this area. AT&T plans to bring new contributions in this area. However, it appears that Alcatel's contribution is consistent with the H.323 standard because it uses the pre-call setup messages (e.g., ARQ) in association with the GK (which is foundation of the H.323 standard). It is very important to note that Alcatel's proposal shows that the new locationQuery message is going through the BEs of two different administrative domains. In AT&T proposal (MD-018 and earlier contributions), it has been suggested that we need to investigate whether can extend the accessRequest message of H.225.0 Annex G because these message sets are very efficient. However, the mobility related parameters proposed in AT&T contributions (MD-017 and MD-018) should also be present. Ericsson's proposal appears that it is NOT associating itself with the GK for registration. It is rather by-passing the GK and is registering with the VLF directly. It seems to be that it is breaking the basic foundation of the H.323 standard. It is almost like creating a NEW protocol. Alcatel's proposal and discussions in AT&T's contributions reveal the fact that we do not need to break the foundation of the H.323 standard to extend H.323 to support mobility. I have also shown how Ericsson's proposal can be accommodates in the context of AT&T's and Alcatel's proposals for registration messages. · Proposal: · To accept the logical step to associate the information of the H.323 mobile users for registration via the GK as shown in AT&T's and Alcatel's proposals that conforms to the H.323 standard. · Decide whether we extend the accessRequest messages of create new messages for mobility management in H.225.0 Annex G. · To include all mobility related parameter as proposed in AT&T's, Alcatel's, and Ericsson's proposal. I like to see that other members also provide their comments. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com

1 0

Steps for Extensions for Mobility Consistent with H.323 Standard
by Roy, Radhika R, ALARC 16 Apr '00

16 Apr '00

Hi, Everyone: The stake for extensions of H.323 to support mobility is so great that people who are familiar with H.323 will be able to understand very easily. Many of those people may not be attending the H.323 Ad Hoc Mobility Group meetings, but they can foresee what I am talking about. 1. Association through Registration with the GK The registration of H.323 entities with the GK establishes the association such that all information related to terminals/users is passed to the GK. The GK becomes the ONLY source where the information related to the H.323 entities is available. It is very important to note that H.323 does NOT allow any other entities other than the GK to have the association with registration of the endpoints (e.g., terminals) through registration. This fundamental concept has allowed to define a zone that is managed by a GK. So, the zone has become the building block for H.323. Later on, we have defined domain that contains one or more zones. All other entities (e.g., BEs) collect this information from the GKs and transfer that information between the BEs in a more efficient way. Please note that even the BEs does NOT have the association with the endpoints (e.g., terminals). Therefore, the model for extensions of H.323 to support mobility MUST be consistent with Rec. H.323. 2. Intra-Zone and Inter-Zone Communications When the mobile users move between the cells, the mobility is primarily becomes intra-zone communications because many cells are expected to be controlled by a single GK. At best, two GKs may be involved when mobile users move between the cells. So, intra-zone solution need to be used for inter-zone communications. These solutions are complementary. So, we have to address the intra-zone communications first before we move to the inter-zone solution. Once we finish intra- and inter-zone communications, we will then move to inter-domain communications because inter-domain communications solution is dependent on the other two. 3. Inter-Domain Communications In some situations, two BEs of two administrative domains may be involved if mobile users move between the cells. H.225.0 Annex G defines inter-domain communication via BEs ONLY. This standard does NOT allow to communicate between the two administrative domains with any other entities other than the BEs. H.323 mobility solution MUST be consistent with Rec. H.225.0 Annex G. 4. Problems for Not Solving Problems Step-by-Step One bright example is H.225.0 Annex G. BEs are allowed to use the efficient message sets like accessRequest and others, while the GKs cannot. Even it cannot be used between the GK and the BE. The model is broken from end-to-end perspective. The future of H.323 seems to be very bleak because of this fundamental problem. Who is to blame? This has created a fundamental problem to make progress in H.323. Now people are trying to bring contributions to use those efficient Annex G message sets for intra-zone and inter-zone communications, but these contributions are not being accepted because of opposition by a very few. Do we want create the same problem for H.323 mobility by-passing the step-by-step method creating highly inconsistent solution? Best regards, Radhika R. Roy AT&T H.323 Ad Hoc Mobility Group

1 0

Re: [H.323 Mobility:] questions on MTD-016
by Roy, Radhika R, ALARC 16 Apr '00

16 Apr '00

Hi, Steve: I guess that you did not get my point exactly. It is NOT exactly where the "service" to be executed. It is user's choice whether certain things to could be perfumed as their choices (for example not to reveal addresses while NOT moving - for example mobile IP permits) etc. Now where the service to be permitted, we may have another debate. There should be flexibility: Home Domain vs Foreign Domain and other criteria. As I explained earlier, what is meant by network in H.323. Please see the email sent in response to Jaakko's. I would be pleases to explain in terms of home/foreign (visiting/visited/target) domain/zone/network address. For the role of the GK in H.323 is clear. There is no ambiguity. Please see my email that will be sent very shortly. Please also see email that will be shortly how we can reconcile all contributions together describing the role of GKs, HLFs, and VLFs: AT&T, Alcatel and yours (Ericsson). Best regards, Radhika R. Roy AT&T -----Original Message----- From: Stephen Terrill [mailto:stephen.terrill@ericsson.com] Sent: Sunday, April 16, 2000 5:11 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] questions on MTD-016 Hi Roy, I still don´t understand why it is a "users" choice where the "services" are executed - I would have thought that this would be networks choice - and the means for doing that is what we are now discussing. Can you please clarify why a user "MAY" which to decieded this. One thing that is now clear is that there are different expectations of the roles of the gatekeepers, VLFs, HLFs etc expressed amongst the participants of the list - and this has to be clarified. Regards, ..//steve "Roy, Radhika R, ALARC" wrote: > Hi, Steve: > > In H.323, GKs are the communication entities thorough which registration and > other services are obtained by users while VLFs and HLFs are used ad > databases to store the information that are appropriate related to the > mobility management. > > In H.323, a user is always associated with a GK through registration, and a > GK manages a zone where all its H.323 registered users reside. In addition, > a GK also manages resources of the zone. > > Please also see the mobility management information flows in AT&T > contributions MD-017 and MD-018 how the GK is involved to resolve > information via VLF and HLF. > > A mobile user MAY like to differentiate between a home GK and a foreign GK > (security and many other reasons). It is an OPTION, not mandatory. > > Hope this clarifies your questions. > > Best regards, > Radhika > > -----Original Message----- > From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM] > Sent: Friday, April 14, 2000 8:02 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] questions on MTD-016 > > Hi Roy, > > Can you please clarify why the gatekeeper selected for the services is a > "user" issue? > > Regards, > > ..//steve > > "Roy, Radhika R, ALARC" wrote: > > > Hi, Vineet and Steve: > > > > I like to add couple of points with respects to your emails as follows: > > > > HLF: > > > > It is interesting to note that there appears to be an "implicit" > assumption > > that there is only one HLF in a domain (no matter what happens in the > > future). > > > > Let us NOT make our protocol "hard-wired" like this. > > > > The protocol should be flexible enough to accommodate one or multiple HLFs > > in a domain. > > > > If one wants to choose one HLF per domain, it MUST be left as an > > implementation issue, NOT a protocol issue. > > > > Home GK: > > > > In the same token, if one wants to declare a GK as its home GK, this > option > > MUST be provided to a user. It is a choice that MUST be given to a user. > If > > anyone does NOT like this option, they MAY not use it. > > > > Home Network/Network Address: > > > > In the same token, if anyone wants to declare a network address as its > home > > network, this option MUST also be provided. > > > > GK Discovery: > > > > The "old" inefficient GRQ discovery mechanisms may not be the only OPTION > to > > discover the GK. in a highly mobile cellular environment. An alternative > > mechanism, like MGA message can be listened to discover the GK as well. > > > > Best regards, > > Radhika R. Roy > > > > > -----Original Message----- > > > From: Kumar, Vineet [SMTP:vineet.kumar@INTEL.COM] > > > Sent: Thursday, April 13, 2000 4:34 PM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: [H.323 Mobility:] questions on MTD-016 > > > > > > Steve, > > > > > > Thanks for your reply. My comments are embedded in the email below. > > > > > > vineet > > > > > > -----Original Message----- > > > From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM] > > > Sent: Thursday, April 13, 2000 4:42 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: [H.323 Mobility:] questions on MTD-016 > > > > > > > > > Hi, > > > > > > I shall try to answer some of these questions below. > > > > > > Regards, > > > > > > ..//steve > > > > > > > > > > > > "Kumar, Vineet" wrote: > > > > > > > Stephen, > > > > > > > > I have a couple of questions on your contribution MTD-016. These are: > > > > > > > > 1. H.323 already has mechanisms for discovering the gatekeeper. Are > you > > > suggesting in your contribution that the terminal should discover the > VLF > > > instead of the visiting gatekeeper ? Or, are you assuming that the VLF > is > > > integrated in the visiting gatekeeper ? > > > > > > This can be discussed - I was of the opionion that we should discover > the > > > VLF and send the registration to the home environment after that. > > > However, > > > we haven´t agreed on the role of the VLF, and visited gatekeeper, home > > > gatekeerp and HLF - when we come to agree on what these are, my proposal > > > may > > > change. > > > > > > <vineet:begin> Yes, this could be discussed in the conference call. My > > > suggestion is to reinvent as less as possible. Since we are adding > > > Mobility > > > to H.323, we should just fill in the gaps that are missing. > > > <vineet:end> > > > > > > > > > > > > 2. In H.323, authentication of the terminal and the gatekeeper is done > > > at > > > the time of discovery. In fact, in H.323 all messages between the > terminal > > > and the gatekeeper can be authenticated and the message integrity > > > preserved. > > > In your contribution, authentication is done at the time of > registration. > > > Why is this preferable to what is already in H.323 ? > > > > > > I would be interested to understand which gatekeeper you were > considering > > > should do the authentication. I would assume that the real > authentication > > > would have to be done at home - as such it would be necessary to find > the > > > visited network services, and then register/authenticate at home. > > > > > > <vineet:begin> I agree with your model but my preference is to preserve > > > the > > > way H.323 works today in that the authentication of both the user (not > > > terminal) and the gatekeeper (doesn't matter whether the gk is visisted > or > > > home) can be done at the time of discovery. The protocol between the > > > terminal and the gk does not change regardless of whether it is the home > > > gk > > > or the visited gk. The terminal sends its hashed password or certificate > > > in > > > the cryptotoken field of the GRQ message. The visisted gk tunnels the > > > entire > > > message to the terminal's Home Administrative Domain for authentication > > > and > > > authorization. There may be an Authentication Function in the Home > > > Administrative Domain that authenticates its users. If the user is > > > successfully authenticated by the Home Administrative Domain then a new > > > temporary password is assigned by the Home Administrative Domain to the > > > terminal and the visited gk in GCF for use during that session. This > > > exchange is explained in detail in the contribution I made for the last > > > conference call. I can't find the MD #. Does anyone know the MD # ? > > > <vineet:end> > > > > > > > > > > > > 3. What is the reason for the information flow from the HLF to the > home > > > gatekeeper, and from the home gatekeeperr to the HLF ? I don't think we > > > can > > > assume that there is only one home gatekeeper that the terminal may be > > > using. In fact, the home gatekeeper may not have any information about > the > > > user. > > > > > > I certainly don´t assume that there is only one home gatekeeper. I > assume > > > that there will be a number of home gatekeepers, but perhaps only one > (or > > > few) HLFs. In this case, we need an function to select the gatekeeper > > > that > > > the user is going to camp on - and this may depend on load, subscriber > > > profile, policy - or a lot of things. > > > > > > <vineet:begin> I guess I will have to understand the model that you have > > > in > > > mind regarding the use of a home gk on which the terminal camps on. In > my > > > model the HLF will send all pertinent information about its user to the > > > VLF. > > > The home gk is not needed. > > > <vineet:end> > > > > > > > > > > > > Regards, > > > > vineet

1 0

Re: [H.323 Mobility:] questions on MTD-016
by Roy, Radhika R, ALARC 16 Apr '00

16 Apr '00

Hi, Steve: In H.323, GKs are the communication entities thorough which registration and other services are obtained by users while VLFs and HLFs are used ad databases to store the information that are appropriate related to the mobility management. In H.323, a user is always associated with a GK through registration, and a GK manages a zone where all its H.323 registered users reside. In addition, a GK also manages resources of the zone. Please also see the mobility management information flows in AT&T contributions MD-017 and MD-018 how the GK is involved to resolve information via VLF and HLF. A mobile user MAY like to differentiate between a home GK and a foreign GK (security and many other reasons). It is an OPTION, not mandatory. Hope this clarifies your questions. Best regards, Radhika -----Original Message----- From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM] Sent: Friday, April 14, 2000 8:02 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] questions on MTD-016 Hi Roy, Can you please clarify why the gatekeeper selected for the services is a "user" issue? Regards, ..//steve "Roy, Radhika R, ALARC" wrote: > Hi, Vineet and Steve: > > I like to add couple of points with respects to your emails as follows: > > HLF: > > It is interesting to note that there appears to be an "implicit" assumption > that there is only one HLF in a domain (no matter what happens in the > future). > > Let us NOT make our protocol "hard-wired" like this. > > The protocol should be flexible enough to accommodate one or multiple HLFs > in a domain. > > If one wants to choose one HLF per domain, it MUST be left as an > implementation issue, NOT a protocol issue. > > Home GK: > > In the same token, if one wants to declare a GK as its home GK, this option > MUST be provided to a user. It is a choice that MUST be given to a user. If > anyone does NOT like this option, they MAY not use it. > > Home Network/Network Address: > > In the same token, if anyone wants to declare a network address as its home > network, this option MUST also be provided. > > GK Discovery: > > The "old" inefficient GRQ discovery mechanisms may not be the only OPTION to > discover the GK. in a highly mobile cellular environment. An alternative > mechanism, like MGA message can be listened to discover the GK as well. > > Best regards, > Radhika R. Roy > > > -----Original Message----- > > From: Kumar, Vineet [SMTP:vineet.kumar@INTEL.COM] > > Sent: Thursday, April 13, 2000 4:34 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: [H.323 Mobility:] questions on MTD-016 > > > > Steve, > > > > Thanks for your reply. My comments are embedded in the email below. > > > > vineet > > > > -----Original Message----- > > From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM] > > Sent: Thursday, April 13, 2000 4:42 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: [H.323 Mobility:] questions on MTD-016 > > > > > > Hi, > > > > I shall try to answer some of these questions below. > > > > Regards, > > > > ..//steve > > > > > > > > "Kumar, Vineet" wrote: > > > > > Stephen, > > > > > > I have a couple of questions on your contribution MTD-016. These are: > > > > > > 1. H.323 already has mechanisms for discovering the gatekeeper. Are you > > suggesting in your contribution that the terminal should discover the VLF > > instead of the visiting gatekeeper ? Or, are you assuming that the VLF is > > integrated in the visiting gatekeeper ? > > > > This can be discussed - I was of the opionion that we should discover the > > VLF and send the registration to the home environment after that. > > However, > > we haven´t agreed on the role of the VLF, and visited gatekeeper, home > > gatekeerp and HLF - when we come to agree on what these are, my proposal > > may > > change. > > > > <vineet:begin> Yes, this could be discussed in the conference call. My > > suggestion is to reinvent as less as possible. Since we are adding > > Mobility > > to H.323, we should just fill in the gaps that are missing. > > <vineet:end> > > > > > > > > > 2. In H.323, authentication of the terminal and the gatekeeper is done > > at > > the time of discovery. In fact, in H.323 all messages between the terminal > > and the gatekeeper can be authenticated and the message integrity > > preserved. > > In your contribution, authentication is done at the time of registration. > > Why is this preferable to what is already in H.323 ? > > > > I would be interested to understand which gatekeeper you were considering > > should do the authentication. I would assume that the real authentication > > would have to be done at home - as such it would be necessary to find the > > visited network services, and then register/authenticate at home. > > > > <vineet:begin> I agree with your model but my preference is to preserve > > the > > way H.323 works today in that the authentication of both the user (not > > terminal) and the gatekeeper (doesn't matter whether the gk is visisted or > > home) can be done at the time of discovery. The protocol between the > > terminal and the gk does not change regardless of whether it is the home > > gk > > or the visited gk. The terminal sends its hashed password or certificate > > in > > the cryptotoken field of the GRQ message. The visisted gk tunnels the > > entire > > message to the terminal's Home Administrative Domain for authentication > > and > > authorization. There may be an Authentication Function in the Home > > Administrative Domain that authenticates its users. If the user is > > successfully authenticated by the Home Administrative Domain then a new > > temporary password is assigned by the Home Administrative Domain to the > > terminal and the visited gk in GCF for use during that session. This > > exchange is explained in detail in the contribution I made for the last > > conference call. I can't find the MD #. Does anyone know the MD # ? > > <vineet:end> > > > > > > > > > 3. What is the reason for the information flow from the HLF to the home > > gatekeeper, and from the home gatekeeperr to the HLF ? I don't think we > > can > > assume that there is only one home gatekeeper that the terminal may be > > using. In fact, the home gatekeeper may not have any information about the > > user. > > > > I certainly don´t assume that there is only one home gatekeeper. I assume > > that there will be a number of home gatekeepers, but perhaps only one (or > > few) HLFs. In this case, we need an function to select the gatekeeper > > that > > the user is going to camp on - and this may depend on load, subscriber > > profile, policy - or a lot of things. > > > > <vineet:begin> I guess I will have to understand the model that you have > > in > > mind regarding the use of a home gk on which the terminal camps on. In my > > model the HLF will send all pertinent information about its user to the > > VLF. > > The home gk is not needed. > > <vineet:end> > > > > > > > > > Regards, > > > vineet

2 1

Should we Break H.323 Model for Mobility?
by Roy, Radhika R, ALARC 16 Apr '00

16 Apr '00

Hi, Everyone: H.323 has some definite architectural notion such as terminal, GK, GW, MCU and(MC, MP). One of the fundamental corner stones is the GK. The H.323 entities (e.g., terminals, GWs) register with the GK. A GK manages a zone with the information of all registered users along with other functions (e.g., bandwidth, resource management, etc). The "registration" with the GK is the fundamental corner stone of H.323 where an association is made by each user. That is, a GK becomes the basic source to have the information related to each user. H.323 mobility protocol MUST also follow the same H.323 architectural concept. If this basic notion is not maintained, it breaks the basic foundation of H.323. It appears that H.323 mobility likes to define additional databases like VLFs and HLFs that will store the information related to the mobile users. These databases are supposed to help the function of a GK in order to manage the mobility related information. If people think that an H.323 will be able to register with a VLF directly, does it not mean we are by-passing the basic foundation of H.323 model? Does it not opening the entirely a new set of problems in H.323? It will create a parallel architecture like GK in H.323 what is not needed at all because solutions have provided that are consistent with H.323 model and there is no need to do this. We probably have to do all over again what we have done for the GKs and BEs. We inviting unnecessary problems that are yet to imagine where we may end up with. Why do we need to do that if one can do this using the consistent H.323 model of GK? In another situation, we have to go step-by-step. First intra-zone, then inter-zone, and last of all inter-domain. Contributions are there to address those problems. The mobile users that move between cells, those cells are expected primarily remain the control of a given GK (in some cases it may be two GKs). These scenarios mostly seem to be intra-zone and inter-zone and may involve a single service provider. Of course, there will also be the calls between the two adm domains of two service providers. More importantly, solutions are inter-dependent. That is, we cannot address the problems of inter-zone without knowing the intra-zone. In the same token, we cannot address the inter-domain problems without knowing the inter-zone problem. Contributions are there. Let us proceed accordingly. Last of all, I am reminding the mess that we have made in Annex G. Now people are hungry to use the more powerful and efficient Annex G messages between the GKs. Contributions were brought to do this, but the proposals had been rejected by a very few. Who is suffering? Best regards, Radhika R. Roy AT&T

2 1

Re: Should we Break H.323 Model for Mobility?
by Tom-PT Taylor 15 Apr '00

15 Apr '00

Nothing in H.323 prevents the GK from consulting other functional entities when necessary to track the location of a user. I have been following the discussion from afar, but my impression is that (1) it is proposed to distinguish a domain-specific Location Function in support of user mobility and (2) the work on mobility is partly about how the GK interacts with this function. It makes sense that the technology of mobile communications -- really just a transport issue from the point of view of H.323 -- should be treated separately from the technology of multipoint multimedia communications, which is what H.323 was designed for. Moreover, the architectural distinction is useful to avoid undue restriction of the possible business models -- the mobility service provider may well be different from the multimedia communications service provider. > -----Original Message----- > From: Roy, Radhika R, ALARC [SMTP:rrroy@ATT.COM] > Sent: Friday, April 14, 2000 10:48 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Should we Break H.323 Model for Mobility? > > Hi, Everyone: > > H.323 has some definite architectural notion such as terminal, GK, GW, MCU > and(MC, MP). One of the fundamental corner stones is the GK. The H.323 > entities (e.g., terminals, GWs) register with the GK. A GK manages a zone > with the information of all registered users along with other functions > (e.g., bandwidth, resource management, etc). > > The "registration" with the GK is the fundamental corner stone of H.323 > where an association is made by each user. That is, a GK becomes the basic > source to have the information related to each user. > > H.323 mobility protocol MUST also follow the same H.323 architectural > concept. If this basic notion is not maintained, it breaks the basic > foundation of H.323. > > It appears that H.323 mobility likes to define additional databases like > VLFs and HLFs that will store the information related to the mobile users. > These databases are supposed to help the function of a GK in order to > manage > the mobility related information. > > If people think that an H.323 will be able to register with a VLF > directly, > does it not mean we are by-passing the basic foundation of H.323 model? > Does > it not opening the entirely a new set of problems in H.323? It will create > a > parallel architecture like GK in H.323 what is not needed at all because > solutions have provided that are consistent with H.323 model and there is > no > need to do this. We probably have to do all over again what we have done > for > the GKs and BEs. We inviting unnecessary problems that are yet to imagine > where we may end up with. Why do we need to do that if one can do this > using > the consistent H.323 model of GK? > > In another situation, we have to go step-by-step. First intra-zone, then > inter-zone, and last of all inter-domain. Contributions are there to > address > those problems. > > The mobile users that move between cells, those cells are expected > primarily > remain the control of a given GK (in some cases it may be two GKs). These > scenarios mostly seem to be intra-zone and inter-zone and may involve a > single service provider. Of course, there will also be the calls between > the > two adm domains of two service providers. > > More importantly, solutions are inter-dependent. That is, we cannot > address > the problems of inter-zone without knowing the intra-zone. In the same > token, we cannot address the inter-domain problems without knowing the > inter-zone problem. Contributions are there. Let us proceed accordingly. > > Last of all, I am reminding the mess that we have made in Annex G. Now > people are hungry to use the more powerful and efficient Annex G messages > between the GKs. Contributions were brought to do this, but the proposals > had been rejected by a very few. Who is suffering? > > Best regards, > Radhika R. Roy > AT&T

1 0

H.323 Mob: Apr 17 bridge info
by Senthil Sengodan 14 Apr '00

14 Apr '00

Folks, The following is the conference call bridge details for the upcoming H.323 mobility ad-hoc group call. As has been done for the previous calls, the conference bridge is hosted/sponsored by IMTC to help expedite the H.323 mobility work. Date: Monday, April 17, 2000 Time: 8:00 AM to 10:30 AM (Pacific Standard Time (PST)) Conference call Bridge # +1 (712)-257-2485 Passcode = 1637895 - Senthil

1 0

Re: [H.323 Mobility:] questions on MTD-016
by Roy, Radhika R, ALARC 14 Apr '00

14 Apr '00

Hi, Vineet: I hope that you are right. The fundamental issue is: Does that HLF of the home administrative domain is priori known to the visiting/visited administrative domain? If it is priori known, then people can directly access to it and no mechanism would be placed in the protocol to find that HLF. We call it static mode. If it is not known, the mechanism in the protocol would be there to find that HLF dynamically. We call it dynamic mode. It is very critical to understand how a simple assumption changes the protocol fundamentally. Hope this will clarify. Best regards, Radhika -----Original Message----- From: Kumar, Vineet [mailto:vineet.kumar@INTEL.COM] Sent: Friday, April 14, 2000 2:23 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] questions on MTD-016 Seems to me that we are saying the same thing but in a different way: There may be one or more HLF entities in the Home Administrative Domain but from the Visited Administrative Domain's point-of-view there is one HLF entity. We have beaten this horse to death, so, I hope, we can move on to other issues. vineet -----Original Message----- From: Gösta Linder (LME) [mailto:Gosta.Linder@LME.ERICSSON.SE] Sent: Friday, April 14, 2000 12:02 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] questions on MTD-016 Hi, comment on single or multiple HLFs; To be able to define protocol relates HLF we have to have a common understanding of the HLF role versus served/visited networks. In H323 Annex H we have the following related definitions; - on HLF; "This functional entity is a database in charge of the management of mobile subscribers. A H.323 Domain may contain one or several HLFs: it depends on the number of mobile subscribers, on the capacity of the equipment and on the organisation of the network." - on VLF; "The VLF contains also the information needed to handle the calls initiated or received by the H.323 MTs registered in its data base (for some supplementary services the VLF may have to obtain additional information from the HLF) the following elements are included: ...." I would then add that principles for adding HLF entities at the Home admin domain (for capacity or redundancy or any other reason) should be totally transparent to the served/visited domains and subject for Home Domain to reorganise his network according his own needs without reflecting any needs to reconfigure served/visited domain behaviour nor any data of the external domains. This means that seen from served/visited domains there is just one HLF entity (clustered or not) to communicate with. I would welcome a discussion to have a common understanding of the principles to be used according to above, to be able to understand needed call flows and related messages. Reagards /Gösta Linder -----Original Message----- From: Kumar, Vineet [mailto:vineet.kumar@INTEL.COM] Sent: den 14 april 2000 01:58 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323 Mobility:] questions on MTD-016 Radhika, I have two comments which are embedded in your email below. vineet -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: Thursday, April 13, 2000 2:03 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] questions on MTD-016 Hi, Vineet and Steve: I like to add couple of points with respects to your emails as follows: HLF: It is interesting to note that there appears to be an "implicit" assumption that there is only one HLF in a domain (no matter what happens in the future). <vineet:begin> I would agree that there should not be any such assumption. I don't believe anyone is making such an assumption. <vineet:end> Let us NOT make our protocol "hard-wired" like this. The protocol should be flexible enough to accommodate one or multiple HLFs in a domain. If one wants to choose one HLF per domain, it MUST be left as an implementation issue, NOT a protocol issue. Home GK: In the same token, if one wants to declare a GK as its home GK, this option MUST be provided to a user. It is a choice that MUST be given to a user. If anyone does NOT like this option, they MAY not use it. Home Network/Network Address: In the same token, if anyone wants to declare a network address as its home network, this option MUST also be provided. <vineet:begin> Can you please elaborate on the above statement, especially on "declare a network address as its home network". Also, I am not sure about the value of using a term like "home network" instead of "home administrative domain". The term "home administrative domain" is already defined in H.323 Annex H and is understood by all participants ? <vineet:end> GK Discovery: The "old" inefficient GRQ discovery mechanisms may not be the only OPTION to discover the GK. in a highly mobile cellular environment. An alternative mechanism, like MGA message can be listened to discover the GK as well. Best regards, Radhika R. Roy > -----Original Message----- > From: Kumar, Vineet [SMTP:vineet.kumar@INTEL.COM] > Sent: Thursday, April 13, 2000 4:34 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] questions on MTD-016 > > Steve, > > Thanks for your reply. My comments are embedded in the email below. > > vineet > > -----Original Message----- > From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM] > Sent: Thursday, April 13, 2000 4:42 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] questions on MTD-016 > > > Hi, > > I shall try to answer some of these questions below. > > Regards, > > ..//steve > > > > "Kumar, Vineet" wrote: > > > Stephen, > > > > I have a couple of questions on your contribution MTD-016. These are: > > > > 1. H.323 already has mechanisms for discovering the gatekeeper. Are you > suggesting in your contribution that the terminal should discover the VLF > instead of the visiting gatekeeper ? Or, are you assuming that the VLF is > integrated in the visiting gatekeeper ? > > This can be discussed - I was of the opionion that we should discover the > VLF and send the registration to the home environment after that. > However, > we haven´t agreed on the role of the VLF, and visited gatekeeper, home > gatekeerp and HLF - when we come to agree on what these are, my proposal > may > change. > > <vineet:begin> Yes, this could be discussed in the conference call. My > suggestion is to reinvent as less as possible. Since we are adding > Mobility > to H.323, we should just fill in the gaps that are missing. > <vineet:end> > > > > > > 2. In H.323, authentication of the terminal and the gatekeeper is done > at > the time of discovery. In fact, in H.323 all messages between the terminal > and the gatekeeper can be authenticated and the message integrity > preserved. > In your contribution, authentication is done at the time of registration. > Why is this preferable to what is already in H.323 ? > > I would be interested to understand which gatekeeper you were considering > should do the authentication. I would assume that the real authentication > would have to be done at home - as such it would be necessary to find the > visited network services, and then register/authenticate at home. > > <vineet:begin> I agree with your model but my preference is to preserve > the > way H.323 works today in that the authentication of both the user (not > terminal) and the gatekeeper (doesn't matter whether the gk is visisted or > home) can be done at the time of discovery. The protocol between the > terminal and the gk does not change regardless of whether it is the home > gk > or the visited gk. The terminal sends its hashed password or certificate > in > the cryptotoken field of the GRQ message. The visisted gk tunnels the > entire > message to the terminal's Home Administrative Domain for authentication > and > authorization. There may be an Authentication Function in the Home > Administrative Domain that authenticates its users. If the user is > successfully authenticated by the Home Administrative Domain then a new > temporary password is assigned by the Home Administrative Domain to the > terminal and the visited gk in GCF for use during that session. This > exchange is explained in detail in the contribution I made for the last > conference call. I can't find the MD #. Does anyone know the MD # ? > <vineet:end> > > > > > > 3. What is the reason for the information flow from the HLF to the home > gatekeeper, and from the home gatekeeperr to the HLF ? I don't think we > can > assume that there is only one home gatekeeper that the terminal may be > using. In fact, the home gatekeeper may not have any information about the > user. > > I certainly don´t assume that there is only one home gatekeeper. I assume > that there will be a number of home gatekeepers, but perhaps only one (or > few) HLFs. In this case, we need an function to select the gatekeeper > that > the user is going to camp on - and this may depend on load, subscriber > profile, policy - or a lot of things. > > <vineet:begin> I guess I will have to understand the model that you have > in > mind regarding the use of a home gk on which the terminal camps on. In my > model the HLF will send all pertinent information about its user to the > VLF. > The home gk is not needed. > <vineet:end> > > > > > > Regards, > > vineet

1 0

Re: [H.323 Mobility:] questions on MTD-016
by Roy, Radhika R, ALARC 14 Apr '00

14 Apr '00

Vineet: In H.323, we call domain and zone. So, we define home/foreign [visiting/target/visited] domain/zone. Also in H.323, there is network/network address. So, we define home/foreign [visiting/target/visited] network/network address. Clearly, home domain -> home zone -> home network/network address. Similarly, foreign [visiting/target/visited] domain -> foreign [visiting/target/visited] zone ->foreign [visiting/target/visited] network/network address. This is the logical relationship. For all IP scenario, we just assuming that it is possible to keep IP address "fixed" as its home network address. For example, mobile IP is doing this. Again, it is an OPTION, not mandatory. But it is very critical and useful OPTION for the mobile users if one likes to use it. The whole mobile IP's foundation has been built on this OPTION. Hope this will further clarify this. Best regards, Radhika PS: By the way, I do not have issue with respect to your DNS option to discover the GK. I just pointed out that there are some questions that you left unanswered (with question mark) in your contribution. -----Original Message----- From: Kumar, Vineet [mailto:vineet.kumar@intel.com] Sent: Friday, April 14, 2000 2:08 PM To: Roy, Radhika R, ALARC Cc: 'ITU-SG16(a)MAILBAG.INTEL.COM' Subject: RE: [H.323 Mobility:] questions on MTD-016 Radhika, I must admit that I am slow in understanding the concepts behind the user having an option to pick either the network address of the "home administrative domain" or the "visited administrative domain". Since we are working on the all IP scenario, I will restrict our discussion to that. Could you be talking about the static and dynamic IP addresses ? vineet -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@att.com] Sent: Friday, April 14, 2000 9:55 AM To: Kumar, Vineet Cc: 'ITU-SG16(a)MAILBAG.INTEL.COM' Subject: RE: [H.323 Mobility:] questions on MTD-016 Hi, Vineet: I guess that we are in agreement. I have just elaborate the justification of keeping the "home network address" (as opposed to "home network") in addition to the home administrative domain. Please see my answer below. Best regards, Radhika -----Original Message----- From: Kumar, Vineet [mailto:vineet.kumar@intel.com] Sent: Thursday, April 13, 2000 7:58 PM To: Roy, Radhika R, ALARC Cc: 'ITU-SG16(a)MAILBAG.INTEL.COM' Subject: RE: [H.323 Mobility:] questions on MTD-016 Radhika, I have two comments which are embedded in your email below. vineet -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: Thursday, April 13, 2000 2:03 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] questions on MTD-016 Hi, Vineet and Steve: I like to add couple of points with respects to your emails as follows: HLF: It is interesting to note that there appears to be an "implicit" assumption that there is only one HLF in a domain (no matter what happens in the future). <vineet:begin> I would agree that there should not be any such assumption. I don't believe anyone is making such an assumption. <vineet:end> <Radhika: begin> If it is, we are in full agreement. This will make the protocol flexible. The protocol itself and the mobility management information flows will reveal the fact whether we are complying with this requirement or not. We will examine our contributions in the light of this requirement. <Radhika: end> Let us NOT make our protocol "hard-wired" like this. The protocol should be flexible enough to accommodate one or multiple HLFs in a domain. If one wants to choose one HLF per domain, it MUST be left as an implementation issue, NOT a protocol issue. Home GK: In the same token, if one wants to declare a GK as its home GK, this option MUST be provided to a user. It is a choice that MUST be given to a user. If anyone does NOT like this option, they MAY not use it. Home Network/Network Address: In the same token, if anyone wants to declare a network address as its home network, this option MUST also be provided. <vineet:begin> Can you please elaborate on the above statement, especially on "declare a network address as its home network". Also, I am not sure about the value of using a term like "home network" instead of "home administrative domain". The term "home administrative domain" is already defined in H.323 Annex H and is understood by all participants ? <vineet:end> <Radhika: begin> As I explained in my earlier mail what the terms "network" and "network address" mean in the context of H.323. An H.323 entity in a network does NOT mean anything unless it is associated with a network address. So, the main idea behind this is: A user may have the OPTION to choose to have its "home network address." A valid question is: Why does a user want to do this? I would point to mobile IP. There can be a lot of benefits from the mobile user's point of view. A mobile user may like to keep the "foreign network address" "HIDE" while he/she moves from one place to another. It is an OPTION, not mandatory. If needed, people may like to implement the entire mobile IP solution at the network layer while using the H.323 mobility solution in the application layer. These two solutions will complement each other. In addition, we like to use the term "home administrative domain." Both "home network address" and "home administrative domain" are required. <Radhika: end> GK Discovery: The "old" inefficient GRQ discovery mechanisms may not be the only OPTION to discover the GK. in a highly mobile cellular environment. An alternative mechanism, like MGA message can be listened to discover the GK as well. Best regards, Radhika R. Roy > -----Original Message----- > From: Kumar, Vineet [SMTP:vineet.kumar@INTEL.COM] > Sent: Thursday, April 13, 2000 4:34 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] questions on MTD-016 > > Steve, > > Thanks for your reply. My comments are embedded in the email below. > > vineet > > -----Original Message----- > From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM] > Sent: Thursday, April 13, 2000 4:42 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] questions on MTD-016 > > > Hi, > > I shall try to answer some of these questions below. > > Regards, > > ..//steve > > > > "Kumar, Vineet" wrote: > > > Stephen, > > > > I have a couple of questions on your contribution MTD-016. These are: > > > > 1. H.323 already has mechanisms for discovering the gatekeeper. Are you > suggesting in your contribution that the terminal should discover the VLF > instead of the visiting gatekeeper ? Or, are you assuming that the VLF is > integrated in the visiting gatekeeper ? > > This can be discussed - I was of the opionion that we should discover the > VLF and send the registration to the home environment after that. > However, > we haven´t agreed on the role of the VLF, and visited gatekeeper, home > gatekeerp and HLF - when we come to agree on what these are, my proposal > may > change. > > <vineet:begin> Yes, this could be discussed in the conference call. My > suggestion is to reinvent as less as possible. Since we are adding > Mobility > to H.323, we should just fill in the gaps that are missing. > <vineet:end> > > > > > > 2. In H.323, authentication of the terminal and the gatekeeper is done > at > the time of discovery. In fact, in H.323 all messages between the terminal > and the gatekeeper can be authenticated and the message integrity > preserved. > In your contribution, authentication is done at the time of registration. > Why is this preferable to what is already in H.323 ? > > I would be interested to understand which gatekeeper you were considering > should do the authentication. I would assume that the real authentication > would have to be done at home - as such it would be necessary to find the > visited network services, and then register/authenticate at home. > > <vineet:begin> I agree with your model but my preference is to preserve > the > way H.323 works today in that the authentication of both the user (not > terminal) and the gatekeeper (doesn't matter whether the gk is visisted or > home) can be done at the time of discovery. The protocol between the > terminal and the gk does not change regardless of whether it is the home > gk > or the visited gk. The terminal sends its hashed password or certificate > in > the cryptotoken field of the GRQ message. The visisted gk tunnels the > entire > message to the terminal's Home Administrative Domain for authentication > and > authorization. There may be an Authentication Function in the Home > Administrative Domain that authenticates its users. If the user is > successfully authenticated by the Home Administrative Domain then a new > temporary password is assigned by the Home Administrative Domain to the > terminal and the visited gk in GCF for use during that session. This > exchange is explained in detail in the contribution I made for the last > conference call. I can't find the MD #. Does anyone know the MD # ? > <vineet:end> > > > > > > 3. What is the reason for the information flow from the HLF to the home > gatekeeper, and from the home gatekeeperr to the HLF ? I don't think we > can > assume that there is only one home gatekeeper that the terminal may be > using. In fact, the home gatekeeper may not have any information about the > user. > > I certainly don´t assume that there is only one home gatekeeper. I assume > that there will be a number of home gatekeepers, but perhaps only one (or > few) HLFs. In this case, we need an function to select the gatekeeper > that > the user is going to camp on - and this may depend on load, subscriber > profile, policy - or a lot of things. > > <vineet:begin> I guess I will have to understand the model that you have > in > mind regarding the use of a home gk on which the terminal camps on. In my > model the HLF will send all pertinent information about its user to the > VLF. > The home gk is not needed. > <vineet:end> > > > > > > Regards, > > vineet

1 0

Re: [H.323 Mobility:] questions on MTD-016
by Kumar, Vineet 14 Apr '00

14 Apr '00

Seems to me that we are saying the same thing but in a different way: There may be one or more HLF entities in the Home Administrative Domain but from the Visited Administrative Domain's point-of-view there is one HLF entity. We have beaten this horse to death, so, I hope, we can move on to other issues. vineet -----Original Message----- From: Gösta Linder (LME) [mailto:Gosta.Linder@LME.ERICSSON.SE] Sent: Friday, April 14, 2000 12:02 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] questions on MTD-016 Hi, comment on single or multiple HLFs; To be able to define protocol relates HLF we have to have a common understanding of the HLF role versus served/visited networks. In H323 Annex H we have the following related definitions; - on HLF; "This functional entity is a database in charge of the management of mobile subscribers. A H.323 Domain may contain one or several HLFs: it depends on the number of mobile subscribers, on the capacity of the equipment and on the organisation of the network." - on VLF; "The VLF contains also the information needed to handle the calls initiated or received by the H.323 MTs registered in its data base (for some supplementary services the VLF may have to obtain additional information from the HLF) the following elements are included: ...." I would then add that principles for adding HLF entities at the Home admin domain (for capacity or redundancy or any other reason) should be totally transparent to the served/visited domains and subject for Home Domain to reorganise his network according his own needs without reflecting any needs to reconfigure served/visited domain behaviour nor any data of the external domains. This means that seen from served/visited domains there is just one HLF entity (clustered or not) to communicate with. I would welcome a discussion to have a common understanding of the principles to be used according to above, to be able to understand needed call flows and related messages. Reagards /Gösta Linder -----Original Message----- From: Kumar, Vineet [mailto:vineet.kumar@INTEL.COM] Sent: den 14 april 2000 01:58 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323 Mobility:] questions on MTD-016 Radhika, I have two comments which are embedded in your email below. vineet -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: Thursday, April 13, 2000 2:03 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] questions on MTD-016 Hi, Vineet and Steve: I like to add couple of points with respects to your emails as follows: HLF: It is interesting to note that there appears to be an "implicit" assumption that there is only one HLF in a domain (no matter what happens in the future). <vineet:begin> I would agree that there should not be any such assumption. I don't believe anyone is making such an assumption. <vineet:end> Let us NOT make our protocol "hard-wired" like this. The protocol should be flexible enough to accommodate one or multiple HLFs in a domain. If one wants to choose one HLF per domain, it MUST be left as an implementation issue, NOT a protocol issue. Home GK: In the same token, if one wants to declare a GK as its home GK, this option MUST be provided to a user. It is a choice that MUST be given to a user. If anyone does NOT like this option, they MAY not use it. Home Network/Network Address: In the same token, if anyone wants to declare a network address as its home network, this option MUST also be provided. <vineet:begin> Can you please elaborate on the above statement, especially on "declare a network address as its home network". Also, I am not sure about the value of using a term like "home network" instead of "home administrative domain". The term "home administrative domain" is already defined in H.323 Annex H and is understood by all participants ? <vineet:end> GK Discovery: The "old" inefficient GRQ discovery mechanisms may not be the only OPTION to discover the GK. in a highly mobile cellular environment. An alternative mechanism, like MGA message can be listened to discover the GK as well. Best regards, Radhika R. Roy > -----Original Message----- > From: Kumar, Vineet [SMTP:vineet.kumar@INTEL.COM] > Sent: Thursday, April 13, 2000 4:34 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] questions on MTD-016 > > Steve, > > Thanks for your reply. My comments are embedded in the email below. > > vineet > > -----Original Message----- > From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM] > Sent: Thursday, April 13, 2000 4:42 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] questions on MTD-016 > > > Hi, > > I shall try to answer some of these questions below. > > Regards, > > ..//steve > > > > "Kumar, Vineet" wrote: > > > Stephen, > > > > I have a couple of questions on your contribution MTD-016. These are: > > > > 1. H.323 already has mechanisms for discovering the gatekeeper. Are you > suggesting in your contribution that the terminal should discover the VLF > instead of the visiting gatekeeper ? Or, are you assuming that the VLF is > integrated in the visiting gatekeeper ? > > This can be discussed - I was of the opionion that we should discover the > VLF and send the registration to the home environment after that. > However, > we havenŽt agreed on the role of the VLF, and visited gatekeeper, home > gatekeerp and HLF - when we come to agree on what these are, my proposal > may > change. > > <vineet:begin> Yes, this could be discussed in the conference call. My > suggestion is to reinvent as less as possible. Since we are adding > Mobility > to H.323, we should just fill in the gaps that are missing. > <vineet:end> > > > > > > 2. In H.323, authentication of the terminal and the gatekeeper is done > at > the time of discovery. In fact, in H.323 all messages between the terminal > and the gatekeeper can be authenticated and the message integrity > preserved. > In your contribution, authentication is done at the time of registration. > Why is this preferable to what is already in H.323 ? > > I would be interested to understand which gatekeeper you were considering > should do the authentication. I would assume that the real authentication > would have to be done at home - as such it would be necessary to find the > visited network services, and then register/authenticate at home. > > <vineet:begin> I agree with your model but my preference is to preserve > the > way H.323 works today in that the authentication of both the user (not > terminal) and the gatekeeper (doesn't matter whether the gk is visisted or > home) can be done at the time of discovery. The protocol between the > terminal and the gk does not change regardless of whether it is the home > gk > or the visited gk. The terminal sends its hashed password or certificate > in > the cryptotoken field of the GRQ message. The visisted gk tunnels the > entire > message to the terminal's Home Administrative Domain for authentication > and > authorization. There may be an Authentication Function in the Home > Administrative Domain that authenticates its users. If the user is > successfully authenticated by the Home Administrative Domain then a new > temporary password is assigned by the Home Administrative Domain to the > terminal and the visited gk in GCF for use during that session. This > exchange is explained in detail in the contribution I made for the last > conference call. I can't find the MD #. Does anyone know the MD # ? > <vineet:end> > > > > > > 3. What is the reason for the information flow from the HLF to the home > gatekeeper, and from the home gatekeeperr to the HLF ? I don't think we > can > assume that there is only one home gatekeeper that the terminal may be > using. In fact, the home gatekeeper may not have any information about the > user. > > I certainly donŽt assume that there is only one home gatekeeper. I assume > that there will be a number of home gatekeepers, but perhaps only one (or > few) HLFs. In this case, we need an function to select the gatekeeper > that > the user is going to camp on - and this may depend on load, subscriber > profile, policy - or a lot of things. > > <vineet:begin> I guess I will have to understand the model that you have > in > mind regarding the use of a home gk on which the terminal camps on. In my > model the HLF will send all pertinent information about its user to the > VLF. > The home gk is not needed. > <vineet:end> > > > > > > Regards, > > vineet

1 0

Re: [H.323 Mobility:] questions on MTD-016
by Kumar, Vineet 14 Apr '00

14 Apr '00

Radhika, I must admit that I am slow in understanding the concepts behind the user having an option to pick either the network address of the "home administrative domain" or the "visited administrative domain". Since we are working on the all IP scenario, I will restrict our discussion to that. Could you be talking about the static and dynamic IP addresses ? vineet -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@att.com] Sent: Friday, April 14, 2000 9:55 AM To: Kumar, Vineet Cc: 'ITU-SG16(a)MAILBAG.INTEL.COM' Subject: RE: [H.323 Mobility:] questions on MTD-016 Hi, Vineet: I guess that we are in agreement. I have just elaborate the justification of keeping the "home network address" (as opposed to "home network") in addition to the home administrative domain. Please see my answer below. Best regards, Radhika -----Original Message----- From: Kumar, Vineet [mailto:vineet.kumar@intel.com] Sent: Thursday, April 13, 2000 7:58 PM To: Roy, Radhika R, ALARC Cc: 'ITU-SG16(a)MAILBAG.INTEL.COM' Subject: RE: [H.323 Mobility:] questions on MTD-016 Radhika, I have two comments which are embedded in your email below. vineet -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: Thursday, April 13, 2000 2:03 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] questions on MTD-016 Hi, Vineet and Steve: I like to add couple of points with respects to your emails as follows: HLF: It is interesting to note that there appears to be an "implicit" assumption that there is only one HLF in a domain (no matter what happens in the future). <vineet:begin> I would agree that there should not be any such assumption. I don't believe anyone is making such an assumption. <vineet:end> <Radhika: begin> If it is, we are in full agreement. This will make the protocol flexible. The protocol itself and the mobility management information flows will reveal the fact whether we are complying with this requirement or not. We will examine our contributions in the light of this requirement. <Radhika: end> Let us NOT make our protocol "hard-wired" like this. The protocol should be flexible enough to accommodate one or multiple HLFs in a domain. If one wants to choose one HLF per domain, it MUST be left as an implementation issue, NOT a protocol issue. Home GK: In the same token, if one wants to declare a GK as its home GK, this option MUST be provided to a user. It is a choice that MUST be given to a user. If anyone does NOT like this option, they MAY not use it. Home Network/Network Address: In the same token, if anyone wants to declare a network address as its home network, this option MUST also be provided. <vineet:begin> Can you please elaborate on the above statement, especially on "declare a network address as its home network". Also, I am not sure about the value of using a term like "home network" instead of "home administrative domain". The term "home administrative domain" is already defined in H.323 Annex H and is understood by all participants ? <vineet:end> <Radhika: begin> As I explained in my earlier mail what the terms "network" and "network address" mean in the context of H.323. An H.323 entity in a network does NOT mean anything unless it is associated with a network address. So, the main idea behind this is: A user may have the OPTION to choose to have its "home network address." A valid question is: Why does a user want to do this? I would point to mobile IP. There can be a lot of benefits from the mobile user's point of view. A mobile user may like to keep the "foreign network address" "HIDE" while he/she moves from one place to another. It is an OPTION, not mandatory. If needed, people may like to implement the entire mobile IP solution at the network layer while using the H.323 mobility solution in the application layer. These two solutions will complement each other. In addition, we like to use the term "home administrative domain." Both "home network address" and "home administrative domain" are required. <Radhika: end> GK Discovery: The "old" inefficient GRQ discovery mechanisms may not be the only OPTION to discover the GK. in a highly mobile cellular environment. An alternative mechanism, like MGA message can be listened to discover the GK as well. Best regards, Radhika R. Roy > -----Original Message----- > From: Kumar, Vineet [SMTP:vineet.kumar@INTEL.COM] > Sent: Thursday, April 13, 2000 4:34 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] questions on MTD-016 > > Steve, > > Thanks for your reply. My comments are embedded in the email below. > > vineet > > -----Original Message----- > From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM] > Sent: Thursday, April 13, 2000 4:42 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] questions on MTD-016 > > > Hi, > > I shall try to answer some of these questions below. > > Regards, > > ..//steve > > > > "Kumar, Vineet" wrote: > > > Stephen, > > > > I have a couple of questions on your contribution MTD-016. These are: > > > > 1. H.323 already has mechanisms for discovering the gatekeeper. Are you > suggesting in your contribution that the terminal should discover the VLF > instead of the visiting gatekeeper ? Or, are you assuming that the VLF is > integrated in the visiting gatekeeper ? > > This can be discussed - I was of the opionion that we should discover the > VLF and send the registration to the home environment after that. > However, > we havenŽt agreed on the role of the VLF, and visited gatekeeper, home > gatekeerp and HLF - when we come to agree on what these are, my proposal > may > change. > > <vineet:begin> Yes, this could be discussed in the conference call. My > suggestion is to reinvent as less as possible. Since we are adding > Mobility > to H.323, we should just fill in the gaps that are missing. > <vineet:end> > > > > > > 2. In H.323, authentication of the terminal and the gatekeeper is done > at > the time of discovery. In fact, in H.323 all messages between the terminal > and the gatekeeper can be authenticated and the message integrity > preserved. > In your contribution, authentication is done at the time of registration. > Why is this preferable to what is already in H.323 ? > > I would be interested to understand which gatekeeper you were considering > should do the authentication. I would assume that the real authentication > would have to be done at home - as such it would be necessary to find the > visited network services, and then register/authenticate at home. > > <vineet:begin> I agree with your model but my preference is to preserve > the > way H.323 works today in that the authentication of both the user (not > terminal) and the gatekeeper (doesn't matter whether the gk is visisted or > home) can be done at the time of discovery. The protocol between the > terminal and the gk does not change regardless of whether it is the home > gk > or the visited gk. The terminal sends its hashed password or certificate > in > the cryptotoken field of the GRQ message. The visisted gk tunnels the > entire > message to the terminal's Home Administrative Domain for authentication > and > authorization. There may be an Authentication Function in the Home > Administrative Domain that authenticates its users. If the user is > successfully authenticated by the Home Administrative Domain then a new > temporary password is assigned by the Home Administrative Domain to the > terminal and the visited gk in GCF for use during that session. This > exchange is explained in detail in the contribution I made for the last > conference call. I can't find the MD #. Does anyone know the MD # ? > <vineet:end> > > > > > > 3. What is the reason for the information flow from the HLF to the home > gatekeeper, and from the home gatekeeperr to the HLF ? I don't think we > can > assume that there is only one home gatekeeper that the terminal may be > using. In fact, the home gatekeeper may not have any information about the > user. > > I certainly donŽt assume that there is only one home gatekeeper. I assume > that there will be a number of home gatekeepers, but perhaps only one (or > few) HLFs. In this case, we need an function to select the gatekeeper > that > the user is going to camp on - and this may depend on load, subscriber > profile, policy - or a lot of things. > > <vineet:begin> I guess I will have to understand the model that you have > in > mind regarding the use of a home gk on which the terminal camps on. In my > model the HLF will send all pertinent information about its user to the > VLF. > The home gk is not needed. > <vineet:end> > > > > > > Regards, > > vineet

1 0

Re: [H.323 Mobility:] questions on MTD-016
by Roy, Radhika R, ALARC 14 Apr '00

14 Apr '00

Hi, Paul and All: Please see my comments that I sent in response to Gosta's comments. There are some agreements, but there are fundamental dis-agreements the way it has been used from protocol point of view. It is very dangerous to "hard-wire" a protocol that views one HLF (or clustered multiple HLFs). If some one wants to implement that way, it may be left as one of the choices. But it should not be the only MANDATORY options when we build our protocol. It should be rather be ONE of the HLFs (out of many). I am also enclosing a copy of my earlier email (if someone missed it). Best regards, Radhika R. Roy AT&T -----Original Message----- From: Roy, Radhika R, ALARC Sent: Friday, April 14, 2000 1:27 PM To: 'Gösta Linder (LME)'; ITU-SG16(a)MAILBAG.INTEL.COM Subject: RE: [H.323 Mobility:] questions on MTD-016 Hi, Gösta: I appreciate the clarifications that you have provided: There can be one or more HLFs in a domain and the H.323 mobile protocol should be transparent to this. I fully agree with you. However, I have to draw the attention to your following statement: "This means that seen from served/visited domains there is just one HLF entity (clustered or not) to communicate with." My assumption is that only ONE of the HLFs (out of many because only one of the HLFs is serving)will be queried to provide the service or answer. A GK will be able to have an OPTION to choose which HLF to go to. Our H.323 mobility protocol should be flexible enough to provide this OPTION. Please note that I am using a GK to go to the HLF, not to by-pass it (I also like to go via GK to VLF, and then via VLF to HLF). Please note that the protocol should be flexible enough to provide all those OPTIONs. That is why, I have mentioned in another email that our H.323 mobility protocol should not be "hard-wired" assuming a single HLF (one or more clustered together) as if everyone priori knows what that HLF entity is. We should be careful from protocol point of view. Let me make it clear by modifying your statement as follows: "This means from served/visited domains there is only ONE of the HLFs that will provide the service." Hope this will further clarify. Best regards, Radhika R. Roy -----Original Message----- From: Gösta Linder (LME) [mailto:Gosta.Linder@LME.ERICSSON.SE] Sent: Friday, April 14, 2000 3:02 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] questions on MTD-016 Hi, comment on single or multiple HLFs; To be able to define protocol relates HLF we have to have a common understanding of the HLF role versus served/visited networks. In H323 Annex H we have the following related definitions; - on HLF; "This functional entity is a database in charge of the management of mobile subscribers. A H.323 Domain may contain one or several HLFs: it depends on the number of mobile subscribers, on the capacity of the equipment and on the organisation of the network." - on VLF; "The VLF contains also the information needed to handle the calls initiated or received by the H.323 MTs registered in its data base (for some supplementary services the VLF may have to obtain additional information from the HLF) the following elements are included: ...." I would then add that principles for adding HLF entities at the Home admin domain (for capacity or redundancy or any other reason) should be totally transparent to the served/visited domains and subject for Home Domain to reorganise his network according his own needs without reflecting any needs to reconfigure served/visited domain behaviour nor any data of the external domains. This means that seen from served/visited domains there is just one HLF entity (clustered or not) to communicate with. I would welcome a discussion to have a common understanding of the principles to be used according to above, to be able to understand needed call flows and related messages. Reagards /Gösta Linder -----Original Message----- From: Kumar, Vineet [mailto:vineet.kumar@INTEL.COM] Sent: den 14 april 2000 01:58 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323 Mobility:] questions on MTD-016 Radhika, I have two comments which are embedded in your email below. vineet -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: Thursday, April 13, 2000 2:03 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] questions on MTD-016 Hi, Vineet and Steve: I like to add couple of points with respects to your emails as follows: HLF: It is interesting to note that there appears to be an "implicit" assumption that there is only one HLF in a domain (no matter what happens in the future). <vineet:begin> I would agree that there should not be any such assumption. I don't believe anyone is making such an assumption. <vineet:end> Let us NOT make our protocol "hard-wired" like this. The protocol should be flexible enough to accommodate one or multiple HLFs in a domain. If one wants to choose one HLF per domain, it MUST be left as an implementation issue, NOT a protocol issue. Home GK: In the same token, if one wants to declare a GK as its home GK, this option MUST be provided to a user. It is a choice that MUST be given to a user. If anyone does NOT like this option, they MAY not use it. Home Network/Network Address: In the same token, if anyone wants to declare a network address as its home network, this option MUST also be provided. <vineet:begin> Can you please elaborate on the above statement, especially on "declare a network address as its home network". Also, I am not sure about the value of using a term like "home network" instead of "home administrative domain". The term "home administrative domain" is already defined in H.323 Annex H and is understood by all participants ? <vineet:end> GK Discovery: The "old" inefficient GRQ discovery mechanisms may not be the only OPTION to discover the GK. in a highly mobile cellular environment. An alternative mechanism, like MGA message can be listened to discover the GK as well. Best regards, Radhika R. Roy > -----Original Message----- > From: Kumar, Vineet [SMTP:vineet.kumar@INTEL.COM] > Sent: Thursday, April 13, 2000 4:34 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] questions on MTD-016 > > Steve, > > Thanks for your reply. My comments are embedded in the email below. > > vineet > > -----Original Message----- > From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM] > Sent: Thursday, April 13, 2000 4:42 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] questions on MTD-016 > > > Hi, > > I shall try to answer some of these questions below. > > Regards, > > ..//steve > > > > "Kumar, Vineet" wrote: > > > Stephen, > > > > I have a couple of questions on your contribution MTD-016. These are: > > > > 1. H.323 already has mechanisms for discovering the gatekeeper. Are you > suggesting in your contribution that the terminal should discover the VLF > instead of the visiting gatekeeper ? Or, are you assuming that the VLF is > integrated in the visiting gatekeeper ? > > This can be discussed - I was of the opionion that we should discover the > VLF and send the registration to the home environment after that. > However, > we haven´t agreed on the role of the VLF, and visited gatekeeper, home > gatekeerp and HLF - when we come to agree on what these are, my proposal > may > change. > > <vineet:begin> Yes, this could be discussed in the conference call. My > suggestion is to reinvent as less as possible. Since we are adding > Mobility > to H.323, we should just fill in the gaps that are missing. > <vineet:end> > > > > > > 2. In H.323, authentication of the terminal and the gatekeeper is done > at > the time of discovery. In fact, in H.323 all messages between the terminal > and the gatekeeper can be authenticated and the message integrity > preserved. > In your contribution, authentication is done at the time of registration. > Why is this preferable to what is already in H.323 ? > > I would be interested to understand which gatekeeper you were considering > should do the authentication. I would assume that the real authentication > would have to be done at home - as such it would be necessary to find the > visited network services, and then register/authenticate at home. > > <vineet:begin> I agree with your model but my preference is to preserve > the > way H.323 works today in that the authentication of both the user (not > terminal) and the gatekeeper (doesn't matter whether the gk is visisted or > home) can be done at the time of discovery. The protocol between the > terminal and the gk does not change regardless of whether it is the home > gk > or the visited gk. The terminal sends its hashed password or certificate > in > the cryptotoken field of the GRQ message. The visisted gk tunnels the > entire > message to the terminal's Home Administrative Domain for authentication > and > authorization. There may be an Authentication Function in the Home > Administrative Domain that authenticates its users. If the user is > successfully authenticated by the Home Administrative Domain then a new > temporary password is assigned by the Home Administrative Domain to the > terminal and the visited gk in GCF for use during that session. This > exchange is explained in detail in the contribution I made for the last > conference call. I can't find the MD #. Does anyone know the MD # ? > <vineet:end> > > > > > > 3. What is the reason for the information flow from the HLF to the home > gatekeeper, and from the home gatekeeperr to the HLF ? I don't think we > can > assume that there is only one home gatekeeper that the terminal may be > using. In fact, the home gatekeeper may not have any information about the > user. > > I certainly don´t assume that there is only one home gatekeeper. I assume > that there will be a number of home gatekeepers, but perhaps only one (or > few) HLFs. In this case, we need an function to select the gatekeeper > that > the user is going to camp on - and this may depend on load, subscriber > profile, policy - or a lot of things. > > <vineet:begin> I guess I will have to understand the model that you have > in > mind regarding the use of a home gk on which the terminal camps on. In my > model the HLF will send all pertinent information about its user to the > VLF. > The home gk is not needed. > <vineet:end> > > > > > > Regards, > > vineet -----Original Message----- From: Reddy, Paul K [mailto:paul.k.reddy@INTEL.COM] Sent: Friday, April 14, 2000 1:31 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] questions on MTD-016 Hi H.323 Mobility group, I totally agree with Mr.Gosta Linder's comments on HLF and VLF principles, that is exactly my understanding. regards, Paul Paul K. Reddy Intel Corporation Mailto:paul.k.reddy@intel.com Office Phone: +1.503.264.9896 Mobile Phone:+1.503.807.9564 -----Original Message----- From: Gösta Linder (LME) [mailto:Gosta.Linder@LME.ERICSSON.SE] Sent: Friday, April 14, 2000 12:02 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] questions on MTD-016 Hi, comment on single or multiple HLFs; To be able to define protocol relates HLF we have to have a common understanding of the HLF role versus served/visited networks. In H323 Annex H we have the following related definitions; - on HLF; "This functional entity is a database in charge of the management of mobile subscribers. A H.323 Domain may contain one or several HLFs: it depends on the number of mobile subscribers, on the capacity of the equipment and on the organisation of the network." - on VLF; "The VLF contains also the information needed to handle the calls initiated or received by the H.323 MTs registered in its data base (for some supplementary services the VLF may have to obtain additional information from the HLF) the following elements are included: ...." I would then add that principles for adding HLF entities at the Home admin domain (for capacity or redundancy or any other reason) should be totally transparent to the served/visited domains and subject for Home Domain to reorganise his network according his own needs without reflecting any needs to reconfigure served/visited domain behaviour nor any data of the external domains. This means that seen from served/visited domains there is just one HLF entity (clustered or not) to communicate with. I would welcome a discussion to have a common understanding of the principles to be used according to above, to be able to understand needed call flows and related messages. Reagards /Gösta Linder -----Original Message----- From: Kumar, Vineet [mailto:vineet.kumar@INTEL.COM] Sent: den 14 april 2000 01:58 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323 Mobility:] questions on MTD-016 Radhika, I have two comments which are embedded in your email below. vineet -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: Thursday, April 13, 2000 2:03 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] questions on MTD-016 Hi, Vineet and Steve: I like to add couple of points with respects to your emails as follows: HLF: It is interesting to note that there appears to be an "implicit" assumption that there is only one HLF in a domain (no matter what happens in the future). <vineet:begin> I would agree that there should not be any such assumption. I don't believe anyone is making such an assumption. <vineet:end> Let us NOT make our protocol "hard-wired" like this. The protocol should be flexible enough to accommodate one or multiple HLFs in a domain. If one wants to choose one HLF per domain, it MUST be left as an implementation issue, NOT a protocol issue. Home GK: In the same token, if one wants to declare a GK as its home GK, this option MUST be provided to a user. It is a choice that MUST be given to a user. If anyone does NOT like this option, they MAY not use it. Home Network/Network Address: In the same token, if anyone wants to declare a network address as its home network, this option MUST also be provided. <vineet:begin> Can you please elaborate on the above statement, especially on "declare a network address as its home network". Also, I am not sure about the value of using a term like "home network" instead of "home administrative domain". The term "home administrative domain" is already defined in H.323 Annex H and is understood by all participants ? <vineet:end> GK Discovery: The "old" inefficient GRQ discovery mechanisms may not be the only OPTION to discover the GK. in a highly mobile cellular environment. An alternative mechanism, like MGA message can be listened to discover the GK as well. Best regards, Radhika R. Roy > -----Original Message----- > From: Kumar, Vineet [SMTP:vineet.kumar@INTEL.COM] > Sent: Thursday, April 13, 2000 4:34 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] questions on MTD-016 > > Steve, > > Thanks for your reply. My comments are embedded in the email below. > > vineet > > -----Original Message----- > From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM] > Sent: Thursday, April 13, 2000 4:42 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] questions on MTD-016 > > > Hi, > > I shall try to answer some of these questions below. > > Regards, > > ..//steve > > > > "Kumar, Vineet" wrote: > > > Stephen, > > > > I have a couple of questions on your contribution MTD-016. These are: > > > > 1. H.323 already has mechanisms for discovering the gatekeeper. Are you > suggesting in your contribution that the terminal should discover the VLF > instead of the visiting gatekeeper ? Or, are you assuming that the VLF is > integrated in the visiting gatekeeper ? > > This can be discussed - I was of the opionion that we should discover the > VLF and send the registration to the home environment after that. > However, > we haven´t agreed on the role of the VLF, and visited gatekeeper, home > gatekeerp and HLF - when we come to agree on what these are, my proposal > may > change. > > <vineet:begin> Yes, this could be discussed in the conference call. My > suggestion is to reinvent as less as possible. Since we are adding > Mobility > to H.323, we should just fill in the gaps that are missing. > <vineet:end> > > > > > > 2. In H.323, authentication of the terminal and the gatekeeper is done > at > the time of discovery. In fact, in H.323 all messages between the terminal > and the gatekeeper can be authenticated and the message integrity > preserved. > In your contribution, authentication is done at the time of registration. > Why is this preferable to what is already in H.323 ? > > I would be interested to understand which gatekeeper you were considering > should do the authentication. I would assume that the real authentication > would have to be done at home - as such it would be necessary to find the > visited network services, and then register/authenticate at home. > > <vineet:begin> I agree with your model but my preference is to preserve > the > way H.323 works today in that the authentication of both the user (not > terminal) and the gatekeeper (doesn't matter whether the gk is visisted or > home) can be done at the time of discovery. The protocol between the > terminal and the gk does not change regardless of whether it is the home > gk > or the visited gk. The terminal sends its hashed password or certificate > in > the cryptotoken field of the GRQ message. The visisted gk tunnels the > entire > message to the terminal's Home Administrative Domain for authentication > and > authorization. There may be an Authentication Function in the Home > Administrative Domain that authenticates its users. If the user is > successfully authenticated by the Home Administrative Domain then a new > temporary password is assigned by the Home Administrative Domain to the > terminal and the visited gk in GCF for use during that session. This > exchange is explained in detail in the contribution I made for the last > conference call. I can't find the MD #. Does anyone know the MD # ? > <vineet:end> > > > > > > 3. What is the reason for the information flow from the HLF to the home > gatekeeper, and from the home gatekeeperr to the HLF ? I don't think we > can > assume that there is only one home gatekeeper that the terminal may be > using. In fact, the home gatekeeper may not have any information about the > user. > > I certainly don´t assume that there is only one home gatekeeper. I assume > that there will be a number of home gatekeepers, but perhaps only one (or > few) HLFs. In this case, we need an function to select the gatekeeper > that > the user is going to camp on - and this may depend on load, subscriber > profile, policy - or a lot of things. > > <vineet:begin> I guess I will have to understand the model that you have > in > mind regarding the use of a home gk on which the terminal camps on. In my > model the HLF will send all pertinent information about its user to the > VLF. > The home gk is not needed. > <vineet:end> > > > > > > Regards, > > vineet

1 0