- sg16-avd - lists.packetizer.com

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

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

14 Apr '00

Radhika, I wasn't aware of any issues raised on my contribution. In the last conference call I just summarized my contribution; we never had time to go over it. But if you see any issues, please bring them up on this reflector. Did anyone else bring up issues on my contribution that I am not aware of ? vineet -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@att.com] Sent: Friday, April 14, 2000 9:25 AM To: Kumar, Vineet Cc: 'ITU-SG16(a)MAILBAG.INTEL.COM' Subject: RE: [H.323 Mobility:] questions on MTD-016 Hi, Vineet: Yes, you are right that multicast should NOT be the only way to discover the GK. That is why, I appreciate your approach to use DNS in combination with GRQ as proposed last time in your contribution. I hope that you will finalize your contribution resolving the remaining issues pointed out in your contribution. You are right that MGA's approach is also like mobile IP. Best regards, Radhika -----Original Message----- From: Kumar, Vineet [mailto:vineet.kumar@intel.com] Sent: Thursday, April 13, 2000 7:33 PM To: Roy, Radhika R, ALARC Cc: 'ITU-SG16(a)MAILBAG.INTEL.COM' Subject: RE: [H.323 Mobility:] questions on MTD-016 Radhika, We cannot assume the existence of multicast, so multicast cannot be the only mechanism for discovering the gk. The terminal will have to try various methods to discover the gk. These methods are: use of DNS, use of pre-configured or previously cached IP address of the gk, and finally the use of multicast. Regarding gk discovery through multicast, in H.323 the terminal initiates the process of finding its gk by sending GRQ on the multicast address. You are saying that this method will cause a lot of traffic if 100s or 1000s of terminals try to simultaneously discover their gks through this method. Your solution is to have the gks periodically send the MGA message which is used by terminals to obtain the addresses (plus other information)of the gks. This type of approach is, I believe, also used in Mobile IP. Seems like a reasonable approach assuming the MGA messages are properly scoped, and the discovery/registration messages between the user and the gk are authenticated and their integrity checked. Regards, vineet -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: Wednesday, April 12, 2000 3:09 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] questions on MTD-016 Vineet: I am just pointing out about only one point of yours: "H.323 already has mechanisms for discovering the gatekeeper. " Yes, it is true: GRQ is the mechanism that is used today in H.323. The time it was decided to use GRQ for discovering the GK, it was not envisioned for the highly mobile communications environments like cellular (wireless) network or a combination of cellular (wireless), wireless LAN, and/or wire-line network. The fundamental question is: Does the same GRQ mechanism make sense to use for the H.323 mobility architecture that we are considering now because of the heavy traffic generated (and associated problems) by the 100s, 1000s of mobile users that will access to a cell? AT&T's contributions MD-017 and MD-018 have addressed this question: Listening to the MGA (Mobility GK Advertise) message (GRQ message can only be sent if the MGA message is not received within the certain time interval). Like you, I also have the same questions 1, 2, and 3 to Steve. Best regards, Radhika > -----Original Message----- > From: Kumar, Vineet [SMTP:vineet.kumar@INTEL.COM] > Sent: Wednesday, April 12, 2000 5:17 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [H.323 Mobility:] questions on MTD-016 > > 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 ? > > 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 ? > > 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. > > Regards, > vineet

1 0

Re: [H.323 Mobility:] questions on MTD-016
by Reddy, Paul K 14 Apr '00

14 Apr '00

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

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

14 Apr '00

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

1 0

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

14 Apr '00

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, Vineet: Yes, you are right that multicast should NOT be the only way to discover the GK. That is why, I appreciate your approach to use DNS in combination with GRQ as proposed last time in your contribution. I hope that you will finalize your contribution resolving the remaining issues pointed out in your contribution. You are right that MGA's approach is also like mobile IP. Best regards, Radhika -----Original Message----- From: Kumar, Vineet [mailto:vineet.kumar@intel.com] Sent: Thursday, April 13, 2000 7:33 PM To: Roy, Radhika R, ALARC Cc: 'ITU-SG16(a)MAILBAG.INTEL.COM' Subject: RE: [H.323 Mobility:] questions on MTD-016 Radhika, We cannot assume the existence of multicast, so multicast cannot be the only mechanism for discovering the gk. The terminal will have to try various methods to discover the gk. These methods are: use of DNS, use of pre-configured or previously cached IP address of the gk, and finally the use of multicast. Regarding gk discovery through multicast, in H.323 the terminal initiates the process of finding its gk by sending GRQ on the multicast address. You are saying that this method will cause a lot of traffic if 100s or 1000s of terminals try to simultaneously discover their gks through this method. Your solution is to have the gks periodically send the MGA message which is used by terminals to obtain the addresses (plus other information)of the gks. This type of approach is, I believe, also used in Mobile IP. Seems like a reasonable approach assuming the MGA messages are properly scoped, and the discovery/registration messages between the user and the gk are authenticated and their integrity checked. Regards, vineet -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: Wednesday, April 12, 2000 3:09 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] questions on MTD-016 Vineet: I am just pointing out about only one point of yours: "H.323 already has mechanisms for discovering the gatekeeper. " Yes, it is true: GRQ is the mechanism that is used today in H.323. The time it was decided to use GRQ for discovering the GK, it was not envisioned for the highly mobile communications environments like cellular (wireless) network or a combination of cellular (wireless), wireless LAN, and/or wire-line network. The fundamental question is: Does the same GRQ mechanism make sense to use for the H.323 mobility architecture that we are considering now because of the heavy traffic generated (and associated problems) by the 100s, 1000s of mobile users that will access to a cell? AT&T's contributions MD-017 and MD-018 have addressed this question: Listening to the MGA (Mobility GK Advertise) message (GRQ message can only be sent if the MGA message is not received within the certain time interval). Like you, I also have the same questions 1, 2, and 3 to Steve. Best regards, Radhika > -----Original Message----- > From: Kumar, Vineet [SMTP:vineet.kumar@INTEL.COM] > Sent: Wednesday, April 12, 2000 5:17 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [H.323 Mobility:] questions on MTD-016 > > 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 ? > > 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 ? > > 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. > > Regards, > vineet

1 0