April 2000 - sg16-avd - lists.packetizer.com

Re: [H.323 Mobility:] questions on MTD-016
by Jaakko Sundquist 13 Apr '00

13 Apr '00

Hi Stephen, I have a couple more questions. First, what exactly is the BG in your contribution? I know that there is such an element in GPRS and it is used in cases, when the visited PLMN always routes the packets of the visiting user to the user's home PLMN. I assume that this BG is supposed to serve a similar purpose, am I right? Second, based on the above mentioned purpose of the BGs and to the fact that in your contribution you state that the HLF selects a gatekeeper in the home network of the user to which the terminal/user will be registered, I assume that this model that you are proposing is only applicable for the "Virtual Home Environment" model (i.e. service execution in the home network). Am I right in this assumption, and if not, could you explain how this model could be used in the "Service Execution in the Visited Network" model? Furthermore, I would not use the terms home/visited network, because there are evidently differing views on what a network means. I suggest that we use the already defined terms Home/Visited Administrative Domain instead for the meaning of home/visited network that I think you're thinking of. -Jaakko > -----Original Message----- > From: EXT Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM] > Sent: 13. April 2000 14:42 > To: ITU-SG16(a)mailbag.cps.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. > > > > > > > 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. > > > > > > > 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. > > > > > > > Regards, > > vineet >

2 1

Re: [H.323 Mobility:] questions on MTD-016
by Gösta Linder (LME) 13 Apr '00

13 Apr '00

Steve, my full support/Gösta -----Original Message----- From: Stephen Terrill [mailto:stephen.terrill@ericsson.com] Sent: den 13 april 2000 13:42 To: ITU-SG16(a)mailbag.cps.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. > > > 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. > > > 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. > > > Regards, > vineet

1 0

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

13 Apr '00

Hi, Jaakko: I am just pointing out to your one of your comments only: "..what a "network" means..." The term "NETWORK/NETWORK ADDRESS" is well defined in H.323. Please see Rec. H.323. The entire Rec. has been described in the context of the network. More specifically, Sections 3, 6.4, 7.1, 7.1.1, and many others. In this context, please also "Section 7.1.1 - Network Address ." In fact a network can be any packet network: IP, ATM, etc. More importantly, H.323 is for "Packet-Based Networks (PBN)." Are you questioning the fundamental basis of H.323? Let us NOT create a debate that does not exit. In the same token, there can be home network address, visited network address, target network address, etc. Hope this helps. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@nokia.com] > Sent: Thursday, April 13, 2000 8:20 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] questions on MTD-016 > > Hi Stephen, > > I have a couple more questions. > > First, what exactly is the BG in your contribution? I know that there is > such an element in GPRS and it is used in cases, when the visited PLMN > always routes the packets of the visiting user to the user's home PLMN. I > assume that this BG is supposed to serve a similar purpose, am I right? > > Second, based on the above mentioned purpose of the BGs and to the fact > that > in your contribution you state that the HLF selects a gatekeeper in the > home > network of the user to which the terminal/user will be registered, I > assume > that this model that you are proposing is only applicable for the "Virtual > Home Environment" model (i.e. service execution in the home network). Am I > right in this assumption, and if not, could you explain how this model > could > be used in the "Service Execution in the Visited Network" model? > > Furthermore, I would not use the terms home/visited network, because there > are evidently differing views on what a network means. I suggest that we > use > the already defined terms Home/Visited Administrative Domain instead for > the > meaning of home/visited network that I think you're thinking of. > > -Jaakko > > > -----Original Message----- > > From: EXT Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM] > > Sent: 13. April 2000 14:42 > > To: ITU-SG16(a)mailbag.cps.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. > > > > > > > > > > > 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. > > > > > > > > > > > 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. > > > > > > > > > > > Regards, > > > vineet > >

1 0

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

13 Apr '00

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

2 1

unsubscribe
by Wang liping 12 Apr '00

12 Apr '00

unsubscribe

1 0

Q12-14/16 Rapporteur meeting after Osaka
by Sakae OKUBO 12 Apr '00

12 Apr '00

Dear Q12-14/16 experts, Rapporteurs have just thankfully received a confirmation from Mr. Vineet Kumar that Intel will host Q11, Q12-14, Q15 meetings in Portland during 21-25 August 2000. Please fill it in your agenda. 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

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

12 Apr '00

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: [Robustness] DDP Checkpointing (Part 2)
by Qiaobing Xie 12 Apr '00

12 Apr '00

Part 2: -Qiaobing Terry L Anderson wrote: ...snip... > It would seem preferable to either break up state information into a > number of subsets (to avoid resending large amounts each time) or to > only send differences. Since DDP gives reliable delivery to the other > members of the pool, perhaps only changes need be sent. Did your trials > solve this problem. Perhaps each call would be a separate subset. I think it's a good idea to define a checkpoint call record structure for each call that should contain the minimal information you need to recover the call. The call processing engine will checkpoint the call record at the proper time. You can for example to index the call record using call ref number. In general, what and when to checkpoint is solely an application decision. This is another big reason we left checkpointing out of DDP. > > One issue is how to solve reliable end-to-end delivery. SCTP would > guarantee delivery to other end of connection but the H.225 and H.245 > protocols may pass through intermediate nodes (e.g., routing GKs). If a > node fails after acknowledging the message but before sending it on, > end-to-end delivery fails and no live element knows. Either we need far If that message is crucial to the continuation of the call, the receiver of the message should probably checkpoint the info received before acking the sender. This way, if the receiver dies after acking the sender, the back-up of the receiver will still be able to get the info from the shared memory. In most cases, the back-up server knows it's taking over a failed peer, and will examine the recovered info from the share memory and decide what to do with the call. > end acknowledgement or backup elements must accept delivery > reponsibility once acknowledgement has been sent by its later failed > peer. DDP would guarantee delivery but the recipient would have to > checkpoint this message before acknowledgement to guarantee that a peer > taking over whould know that there was an outstanding message that it > must deliver and receive acknowledgement for. This mechanism would > require checkpoint after receipt of but before sending acknowledgement > of a message and again after receiving acknowledgement from its next > neighbor. Does this seem reasonable? It's reasonable. Again, which message/response needs to be checkpointed is REALLY an application decision which should be made case by case in each call scenario. In most cases, not every message in a call flow needs to be checkpointed since the call model itself usually have some error recovering mechanism built-in and it can recover by itself if the faulure hits at certain points of the call. > Unless the amount of data sent in > such checkpointing is kept very small this would seem to add too much > network activity to be acceptible. Always a good practice to minimize the checkpointed call record to only include critical information of the call. Also, the checkpointing traffic are localized to the server group. Proper network engineering can help a lot (eg, don't let the checkpointing traffic of a pair of heavy duty call servers run through a bottleneck router that is also handling signalling traffic).

1 0

Re: [Robustness] DDP Checkpointing
by Qiaobing Xie 12 Apr '00

12 Apr '00

See my comments below... (also see Randy's answer, mine is more from an architectural point of view) (Part 1: my mail server doesn't like long message for some reason :-) -Qiaobing Terry L Anderson wrote: > > Randy Stewart - > > You described a "checkpointing" mechanism for DDP during last week's > robustness call but it is not in the current DDP draft. However, you > have evidently thought about this some and stated (in private mail) that > you had built such mechanism on top of DDP using the SEND_TO_ALL > mechanism. How would you envision something like this being done to > synch state for a pool of H.323 entities? Would this be a application > level library that could be called from H.323 software at appropriate > checkpoint times? Could you describe this checkpointing idea in some > more detail? > We consider DDP covering only session-level fault tolerant data transfer, and therefore have left checkpointing out of DDP spec. We believe that the implementors should have full freedom to choose the most suitable checkpointing mechanism for their specific applications. Examples for checkpointing/replication mechnisms include: 1. Networked application servers on multiple hosts using one of the following replicating techniques: - IP multicast (cheap but unreliable) - DDP SEND_TO_ALL, a.k.a. groupcast (reliable, not very efficient in large group) - some Reliable Multicast protocol (still being worked on by IETF rmt WG, not sure whether they are considering "many-to-many" case though) - etc. 2. Multiple servers on the same host, using local shared memory IPC (Effective and efficient, but won't survive if the host crash, scaling problem too) 3. Servers on duplicated hardware cards on same platform (eg, cPCI box) with hardware-assist reflected memory (Very fast, not very scalable, a little expensive, won't survive platform crash.) 4. Shared network disk array (Cheap, but non-real time, disk array may become single-point-of-failure.) Internally at Motorola, we have prototyped a hybrid of 1 and 2 and created a networked (virture) shared memory using IP multicast. It works great :-)

1 0

[Robustness] DDP Checkpointing
by Terry L Anderson 12 Apr '00

12 Apr '00

Randy Stewart - You described a "checkpointing" mechanism for DDP during last week's robustness call but it is not in the current DDP draft. However, you have evidently thought about this some and stated (in private mail) that you had built such mechanism on top of DDP using the SEND_TO_ALL mechanism. How would you envision something like this being done to synch state for a pool of H.323 entities? Would this be a application level library that could be called from H.323 software at appropriate checkpoint times? Could you describe this checkpointing idea in some more detail? It would seem preferable to either break up state information into a number of subsets (to avoid resending large amounts each time) or to only send differences. Since DDP gives reliable delivery to the other members of the pool, perhaps only changes need be sent. Did your trials solve this problem. Perhaps each call would be a separate subset. One issue is how to solve reliable end-to-end delivery. SCTP would guarantee delivery to other end of connection but the H.225 and H.245 protocols may pass through intermediate nodes (e.g., routing GKs). If a node fails after acknowledging the message but before sending it on, end-to-end delivery fails and no live element knows. Either we need far end acknowledgement or backup elements must accept delivery reponsibility once acknowledgement has been sent by its later failed peer. DDP would guarantee delivery but the recipient would have to checkpoint this message before acknowledgement to guarantee that a peer taking over whould know that there was an outstanding message that it must deliver and receive acknowledgement for. This mechanism would require checkpoint after receipt of but before sending acknowledgement of a message and again after receiving acknowledgement from its next neighbor. Does this seem reasonable? Unless the amount of data sent in such checkpointing is kept very small this would seem to add too much network activity to be acceptible. -- ------------------------------------------------------------ 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

2 1