- sg16-avd - lists.packetizer.com

LogicalChannelRate Messages
by Aseem Agarwal 10 Nov '99

10 Nov '99

Hi A set of new signalling messages LogicalChannelRate have been introduced in H.245 version-5. There is no corresponding section in Annex C for any procedures/state machine/ timers, etc. associated with these messages. Kindly let me know if the associated procedures are a part of some appendix/ implementor's guide. thanks aseem(a)trillium.com

2 1

Canonical names
by Paul Long 09 Nov '99

09 Nov '99

I have found conflicting descriptions of canonical names. A.6.4.1/H.225.0v3 says, "The CNAME item should have the format 'user@host'...," and then goes on to talk about alternative forms. However, the cname field in RTPSession, which is referenced by the audio and video components of IRR's perCallInfo, is of type, PrintableString. But guess what? The "@" character is not valid for PrintableString! The problem occurs when an EP receives a properly formed canonical name (via an RTCP sender report) containing "@", e.g., "plong@wkstation3", and is subsequently required to disclose this name in an IRR. It currently has to modify the name before encoding it by, for example, replacing the "@" character with "-", as in "plong-wkstation3" or removing the user-name portion of the name, leaving just the host name, as in "wkstation3", but then it is not accurately reporting the canonical name. Anyone know how to fix this in H.225.0? Paul Long Smith Micro Software, Inc.

1 0

FYI only
by Edgar Martinez [1] 09 Nov '99

09 Nov '99

Dear All, Just to provided more information and some food for thought I have put the "3GPP Definitions" and "3GPP Terminology for Call Control". in http://people.itu.int/~emartine/temp/ Best Regards, -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/

2 1

Re: H323 mobility: Summary of discussion
by Roy, Radhika R, ALARC 08 Nov '99

08 Nov '99

Hi, Ed: Kindly see my reply. Best regards, Radhika > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > Sent: Monday, November 08, 1999 12:26 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H323 mobility: Summary of discussion > > Hi Radhika, > > "Roy, Radhika R, ALARC" wrote: > > > Hi, Ed and All: > > > > I understand your point. As I explained that contributions with solution > > have been provided based on "Home and Visited" solving the mobility > > problems. > > > > All members are welcomed to provide solutions based on their concepts. > If > > the alternate solutions are provided based on contributions we will > > definitely be able to see how solutions are provided based on alternate > > ideas or terminologies. Then, we will have wonderful opportunities to > > compare each idea or terminology without any confusion or ambiguity. > > Definitely we are waiting to make compromises if we collectively see > that it > > makes sense to do so when we see that there are better solutions > available > > based on alternative approaches. > > > > We are only in definition phase. These are the place holders. If the > > architectural solution that we will be agreeing with does not support > those > > definitions or terminologies we will definitely change these. There > should > > not be any doubt about this. I do not see why we should hold-off our > > discussions for these two terms. > > > As an Editor, I suggest that you can put a > > note that "some members have some objection to agree on these two terms, > but > > we will revisit these terms when we finalize our architectural > solution." > > > > Noted > > > > > We will have an architectural discussion in the upcoming conference > call. We > > have invited contributions with proposed solutions to have all ideas > clear > > so that we can move forward. > > > > > > > Finally, Ed - what we are looking for is the solution of the problem > (not > > adding or deleting some terminologies here and there). > > We have plenty to solutions, but weak definitions. > [Roy, Radhika R] If it is so, the logical step is to examine all solutions to understand them better and let us come back to make the definitions stronger once we agree on the solution. [Roy, Radhika R] The other alternative is to go on defining terms that may consist of both "strong" and "weak" definitions and let us move on to the solution area. Then we come back what we do about the "strong" and "weak" definitions because our goal is the solution. [Roy, Radhika R] The bottom line is: Let us move on to find the solution. > Thanks > > > > > > > Hope this email will clarify your concern. > > > > Best regards, > > Radhika > > > > > -----Original Message----- > > > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > > > Sent: Friday, November 05, 1999 6:31 PM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: H323 mobility: Summary of discussion > > > > > > To the Mobile Ad-hoc Colleges: > > > > > > What we have here is an opportunity to build a good > > > working relationship. But, it seems at this time, > > > we are in feeling out stage. Solutions and proposals > > > are being worked within companies and in > > > difference standards, which want to find a > > > place in the work we are doing but, I think > > > compromise is in order. > > > > > > The only thing I was suggesting in by email, > > > was that the word "Home and Visited" bother soon > > > of our colleges. So my suggestion was to persevere > > > the functions and compromise on the naming of the functions. > > > > > > By definition, whatever we put in the H.323 mobility > > > document will have to be in the > > > context of the H.323 framework baseline. > > > > > > Lets keep an open mind as we move forward, > > > Y peace. We all may learn something and discover > > > new things. If possible lets start looking on compromise > > > solutions that satisfies all involved. Once we limit our > > > scope it limits us from progressing towards the future. > > > > > > Best Regards, > > > Ed > > > > > > "Roy, Radhika R, ALARC" wrote: > > > > > > > Hi, Ed and All: > > > > > > > > I do not know whether you have seen my reply to Jaakko. I am > enclosing > > > it > > > > again. Please respond to my reply to provided Jaakko to prove your > > > > statement. > > > > > > > > I completely disagree with Ed. Please also see Marc Roelands's > comments > > > on > > > > LA. > > > > > > > > AT&T contribution has shown how H.323 mobility problem can be solved > > > using > > > > home/foreign GK (zone). > > > > > > > > I like to see the complete H.323 mobility problem that has been > solved > > > using > > > > the alternative approach as proposed by Nokia. I have NOT seen > Nokia's > > > > solution yet. Unless a complete solution is provided like AT&T's, I > am > > > NOT > > > > convinced how mobility problem can be solved in a better way. > > > > > > > > I also see that there is a need for HLF/VLF. No one against the > HLF/VLF > > > > function. AT&T proposal also has shown how HLF/VLF function is taken > > > > care-of. > > > > > > > > What I disagree with is this: A protocol should NOT be > implementation > > > > specific. For example, we do have a luxury to build one protocol for > > > > distributive GK (HLF/VLF) function, one protocol for centralized GK > > > > (HLF/VLF) function or one protocol for hybrid GK (HLF/HLF) function. > It > > > is > > > > against the fundamental concept of H.323. For example, the same > argument > > > can > > > > also be applied for the directory function. Similar may the case for > > > other > > > > functions as well. It is a complete break down of H.323 protocol and > > > > architecture. > > > > > > > > So, HLF/VLF is another function in H.323. HLF/VLF is NOT a "Holy > Grail" > > > for > > > > which we have to create a complete "DISCONTINUITY" in existing H.323 > > > > protocol and architecture. I like see to Nokia's alternate solution > to > > > > disprove this fear. > > > > > > > > Nokia has to bring a complete contribution providing solution like > > > AT&T's to > > > > prove their case. Otherwise, we cannot proceed with a concept that > has > > > not > > > > proved with a solution. > > > > > > > > The problem can be solved as follows: > > > > > > > > 1. Let Nokia provide a complete proposal solving the H.323 mobility > > > problem > > > > using heir alternative approach. What Nokia has provided is a high > level > > > > concept. They have NOT solved the problem yet. Let us see what the > > > complete > > > > solution is. If a solution is provided, we can then compare Nokia's > > > solution > > > > with that of AT&T's solution. Otherwise, their proposal is still > > > > HYPOTHETICAL. It is a concept, NOT a solution. > > > > > > > > 2. How can we agree on a concept without seeing its solution that > has > > > the > > > > potential to break down the fundamental architecture of existing > H.323 > > > > standard? > > > > > > > > 3. Let us solve H.323 mobility problem within the framework of > H.323. > > > > > > > > 4. Let us move on with contributions for the part that we can agree > on. > > > If > > > > Nokia brings a complete solution, we will definitely re-consider > their > > > case. > > > > > > > > 5. I agree with you that we also need to work for interworking > between > > > H.323 > > > > (IP) mobility and cellular-PSTN/ISDN network. > > > > > > > > Finally, Ed - you have made a statement, but it has to be proved > > > providing a > > > > solution. An alternative concept is there, but we have not seen its > > > solution > > > > yet. What is the problem to bring the alternate solution? Why do we > need > > > to > > > > wait for a concept that has NOT been substantiated with a solution > yet? > > > > > > > > Best regards, > > > > Radhika > > > > > > > > > -----Original Message----- > > > > > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > > > > > Sent: Thursday, November 04, 1999 9:47 AM > > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > > > Subject: Re: H323mobility: Summary of discussion > > > > > Importance: High > > > > > > > > > > I agreed with most of Jaakko comments and also > > > > > make vaild points, and will like to > > > > > add the following. > > > > > > > > > > I believe that the (Home) in Home Zone should be taken out. > > > > > What we are talking about is the User's Point of Attached in > > > > > any given Zone. The HLF is ready and Data base > > > > > which has the User's profile and the current user's location. > > > > > We can get a new name to HLF and call it the Location Profile > > > > > Register (LPR) or Location Profile Function (LPF). > > > > > > > > > > I also believe that the (Visited) in Visited Zone sould also > > > > > be taken out because again we are talking about > > > > > the Users current Point of Attachment in any given Zone. > > > > > The VLF has the means to update the > > > > > Location Profile Register (LPR) from > > > > > any given Zone. We can get a new name to VLF > > > > > call it the Location Update Register (LUR) or > > > > > Location Update Function (LUF). > > > > > > > > > > Now we can also support concepts of Zone ID's > > > > > such as Current Zone ID and Previous Zone ID. > > > > > > > > > > Finally, > > > > > > > > > > And I strongly agree with looking at the interworking > > > > > in parallel with H.323 mobility. The time we spent > > > > > now looking at interworking will be compensated in the > > > > > long run. I sure does working on ISUP, IN and Qsig, inetrworking > > > > > with H.323 would agree and we should learn from their experience. > > > > > And not leave it for a last minute add-on. > > > > > > > > > > Lets take the contribution as they come, if one wants to put in > > > > > interworking fine. If one wants to put in contributions only H.323 > > > > > mobility also fine. Both are in order and within our scope. > > > > > > > > > > The general strategy should focus on ensuring that the H.323 > > > > > Mobility and interworking options are enabled, rather than > spending > > > > > too much effort blocking alternative options (Our limited > resources > > > > > frankly don't allow this luxury). But there really is no > substitute > > > for > > > > > doing the work - preparing input papers and presenting them > > > > > to move things forward. > > > > > > > > > > Best Regards, > > > > > > > > > > Ed > > > > [Roy, Radhika R] Hi, Jaakko: > > > > > > > > Pl. see my reply provided below. > > > > > > > > Best regards, > > > > Radhika > > > > > > > > -----Original Message----- > > > > From: jaakko.sundquist(a)NOKIA.COM > > > [SMTP:jaakko.sundquist@NOKIA.COM] > > > > Sent: Tuesday, November 02, 1999 11:13 AM > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > > Subject: Re: H323mobility: meeting > > > > > > > > Once again, hi, Radhika, Ed + all > > > > > > > > See my comments below... > > > > > > > > Hi, Jaakko, Ed, and All: > > > > > > > > I hope that Jaakko will get this mail while > he > > > is in > > > > his > > > > office (Thanks > > > > Jaakko - you have reminded us the time > > > difference)! > > > > > > > > [Jaakko:] You caught me just in time. > > > > > > > > Please note the following: > > > > > > > > 1. Zone and domain are well defined in > H.323. > > > > [Jaakko:] Yes, they are defined. > > > > > > > > 2. We have to work for mobility solution in > a > > > way > > > > that fits > > > > very well that > > > > already exists in H.323. > > > > > > > > [Jaakko:] Agreed. > > > > > > > > 3. We can invent many things if we need to > solve > > > > mobility > > > > problems only when > > > > we think that those functions are NOT > covered in > > > > existing > > > > H.323 standard. > > > > > > > > [Jaakko:] Yes. > > > > > > > > 4. If mobility problems can be solved using > the > > > > concept of > > > > "zones" and > > > > "domains," I would assume that it would be a > big > > > > mile stone > > > > so far the > > > > continuity of H.323 is concerned. That is, > as Ed > > > > pointed > > > > out, H.323 mobility > > > > problem is NOT a rocket science. We have to > > > remember > > > > that we > > > > are working in > > > > the framework of already existing H.323 > standard > > > > architecture. We have to > > > > relate our solution in the context of > existing > > > H.323 > > > > standard. In other > > > > words, we CANNOT change the fundamental > concept > > > of > > > > existing > > > > H.323 standards > > > > just because we are addressing mobility. > > > > > > > > [Jaakko:] Yes, of course. I'm not arguing > > > against > > > > that. I > > > > guess you are referring to the Location Area discussion > here. > > > The LA > > > > concept > > > > is really merely a scaling issue, you could of course handle > > > paging > > > > (I'm > > > > assuming that we will need the paging procedure) based on > zones, > > > > i.e. page > > > > every NPoA in a zone when a call arrives, but this might be > > > quite > > > > limiting > > > > in some cases (the zone may be needlessly big or very > small). I > > > do > > > > not think > > > > that we need to change any fundamental concepts of H.323, if > we > > > > introduce > > > > the LA concept. > > > > [Roy, Radhika R] May be we can include LA when we see that > we > > > need > > > > to optimize a zone further. We may revisit this in the second step. > > > > > > > > 5. I do not understand what benefits we are > > > gaining > > > > adding > > > > more > > > > "terminologies" like "AREA {home, foreign, > etc}" > > > > while the > > > > "zone" and > > > > "domain" are already well defined in H.323. > My > > > > personal view > > > > is that we > > > > should FIRST try to solve H.323 mobility > > > problems > > > > within the > > > > context of > > > > "zone" and "domain" as far as practicable. I > > > would > > > > argue > > > > that zone and > > > > domain are good enough to serve this purpose > for > > > > now. (Pl. > > > > also see AT&T's > > > > and Motorola's contributions.) > > > > > > > > [Jaakko:] As I already said, I did not > intent to > > > > define the > > > > terms: home area and visited area. I was just trying to > > > illustrate > > > > the point > > > > I was making about not having the Home/visited zone terms > > > defined > > > > yet. > > > > [Roy, Radhika R] It is good point. Let us define these. > AT&T > > > > contributions have the detail definition for each term. > > > > > > > > 6. With respect to your comments that it > appears > > > > that every > > > > GK will have HLF > > > > and VLF function, I would say that every GK > will > > > > have the > > > > access to the HLF > > > > and VLF function. This capability for each > GK > > > has to > > > > be > > > > provided because of > > > > the fact that H.323 architecture is > GK-centric. > > > We > > > > do not > > > > have any choice > > > > because we are restricted by the H.323 > > > architecture. > > > > > > > > [Jaakko:] I did not argue against this. The > > > point is > > > > that if > > > > we identify a concept called the Home Zone, this already > implies > > > > that each > > > > User has only one zone, in which he/she/it is not a > "visiting > > > user". > > > > I think > > > > this would be really restricting. > > > > [Roy, Radhika R] As I mentioned that H.323 is the > GK-centric. A > > > > user may change his/her network point of point attachment, but it is > > > still > > > > the same (Home) GK. So, a given (home) GK, there has to be another > level > > > of > > > > granularity to address mobility in terms of network point of > attachment. > > > > Please see AT&T contribution how home and foreign network concept > have > > > > solved the problem. Similar is the case with Motorola's > contribution. > > > The > > > > bottom line is that home/foreign GK concept does NOT imply any > > > restriction > > > > to solve H.323 mobility. > > > > > > > > 6.1 With respect to your question whether > > > HLF/VLF > > > > can be > > > > distributive or > > > > centralized, having said (in item 5) that > every > > > GK > > > > should > > > > have access to HLF > > > > and VLF function, it is up to implementation > > > whether > > > > HLF and > > > > VLF function > > > > can be centralized or distributive. Please > see > > > AT&T > > > > contributions submitted > > > > in Red Bank how we can implement these > functions > > > in > > > > both > > > > distributive and > > > > centralized environment. > > > > > > > > [Jaakko:] This is actually quite much the > point > > > I > > > > was > > > > making. By defining the Home Zone we would in my mind > actually > > > be > > > > pointing > > > > to the centralized model. > > > > [Roy, Radhika R] By definition, there can as many GKs as > one > > > wish > > > > have in an H.323 system. So, by definition, the GK-centric H.323 > > > > architecture is distributive. By defining home/foreign GK, H.323 > > > mobility > > > > also becomes distributive up to the point that a basic H.323 system > > > allows > > > > us. So, we do not see any limitations. > > > > > > > > 6.2 In an analogy of this HLF/VLF function, > I > > > can > > > > bring > > > > another function - > > > > Directory services. For example, H.323 > assumes > > > that > > > > all the > > > > address (e.g., > > > > alias, transport, network) are kept by each > GK. > > > > H.323 does > > > > not answer how > > > > the address information is maintained by > each > > > GK. > > > > People are > > > > using LDAP > > > > directory server. The question is: whether > that > > > > directory > > > > service is > > > > distributive or centralized? I guess that it > can > > > be > > > > done in > > > > both ways > > > > depending on implementation. > > > > > > > > [Jaakko:] My point exactly. I would like > that > > > all > > > > GKs inside > > > > the same Administrative Domain would be able to access the > same > > > > HLF/VLF > > > > functionality. > > > > [Roy, Radhika R] As I pointed out, this an implementation > > > issue. I > > > > would argue that we should allow both options and let an implementor > > > choose > > > > as it is necessary. Please also see AT&T contributions how both > options > > > can > > > > be addressed. > > > > > > > > 6.3 In AT&T contribution, it is shown that > it > > > better > > > > to make > > > > VLF > > > > distributive (per GK) although HLF function > can > > > be > > > > made both > > > > distributive > > > > and centralized. Again, this is a matter of > > > > implementation. > > > > As mentioned in > > > > AT&T contribution, we also need to define a > kind > > > of > > > > backend > > > > protocol for VLF > > > > and HLF (something like similar to Siemens, > > > Nokia > > > > and > > > > Intel's contribution - > > > > TD-39: Security Services for Backend > Services > > > and > > > > Mobility > > > > in H.323). > > > > > > > > [Jaakko:] I would assume that you can > distribute > > > the > > > > HLF/VLF > > > > functionalities inside the Administrative Domain as you > like, > > > but > > > > distributing them between the Domains would be difficult. > > > Actually I > > > > think > > > > that the concept of Administrative Domain was introduced in > > > H.323 > > > > for this > > > > kind of reasons. > > > > [Roy, Radhika R] Again, H.323 system is GK-centric in a > given > > > > domain. For inter-domain, it is BE-centric. In a given domain, H.323 > > > > architecture has to be GK-centric. Once we solve intra-zone and > > > inter-zone > > > > (intra-domain) mobility, we can extend our experience for > inter-domain > > > > problem as well. Please also see AT&T contribution how these > problems > > > have > > > > been addressed. My replies to 6.1 and 6.2 are also good for this > case. > > > > > > > > 7. Again, I, personally, do not rule our to > > > > re-examine the > > > > benfit of "AREA" > > > > (e.g. location area [LA]) vs. "ZONE/DOMAIN" > > > concept. > > > > May be > > > > it is in the > > > > second step. > > > > > > > > [Jaakko:] I am just a bit afraid that if we > > > leave > > > > this kind > > > > of a major mobility related concept out of the first phase > > > thinking > > > > process, > > > > we will find it much more difficult to include the concept > in > > > the > > > > second > > > > phase (where I think we will need it). Furthermore, I'm not > > > > convinced that > > > > the LA concept would not be useful in the pure H.323 > approach > > > > either. > > > > [Roy, Radhika R] I think that it can be place holder for > now. I > > > > would request to bring more detail contributions proposing solutions > > > like > > > > AT&T and Motorola to prove the case better. Then, we can compare > both > > > > solutions. In AT&T contribution, I feel that the LA can be > accommodated > > > to > > > > optimize the zone further. So, I do not see that it is a problem to > > > > accommodate the LA concept if needed. I personally prefer that we > can > > > better > > > > address this in the second phase once we solve the problem for the > basic > > > > architecture. > > > > > > > > Hope that this email will clarify the things > > > better. > > > > > > > > [Jaakko:] I think the main thing is that we > got > > > the > > > > discussion going on again. I'm kind of tired already, and I > hope > > > > that I > > > > didn't mess things up too much in this mail. > > > > [Roy, Radhika R] Definitely, I also like that discussions > must > > > go > > > > on. We must be convinced that we have the best solution because it > has > > > the > > > > severe implications for all on-going mobility standard works > throughout > > > the > > > > world once we standardize H.323 mobility in SG16. > > > > > > > > Best regards, > > > > Radhika > > > > > > > > Same to you, > > > > Jaakko > > > > > -- > > > > > Edgar Martinez - Principal Staff Engineer > > > > > Email mailto:martinze@cig.mot.com > > > > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > > > > 1501 West Shure Drive, Arlington Hgts. IL 60004 > > > > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > > > > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > > > > > > -- > > > Edgar Martinez - Principal Staff Engineer > > > Email mailto:martinze@cig.mot.com > > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > > 1501 West Shure Drive, Arlington Hgts. IL 60004 > > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: H323 mobility: Summary of discussion
by Edgar Martinez [1] 08 Nov '99

08 Nov '99

Hi Radhika, "Roy, Radhika R, ALARC" wrote: > Hi, Ed and All: > > I understand your point. As I explained that contributions with solution > have been provided based on "Home and Visited" solving the mobility > problems. > > All members are welcomed to provide solutions based on their concepts. If > the alternate solutions are provided based on contributions we will > definitely be able to see how solutions are provided based on alternate > ideas or terminologies. Then, we will have wonderful opportunities to > compare each idea or terminology without any confusion or ambiguity. > Definitely we are waiting to make compromises if we collectively see that it > makes sense to do so when we see that there are better solutions available > based on alternative approaches. > > We are only in definition phase. These are the place holders. If the > architectural solution that we will be agreeing with does not support those > definitions or terminologies we will definitely change these. There should > not be any doubt about this. I do not see why we should hold-off our > discussions for these two terms. > As an Editor, I suggest that you can put a > note that "some members have some objection to agree on these two terms, but > we will revisit these terms when we finalize our architectural solution." > Noted > > We will have an architectural discussion in the upcoming conference call. We > have invited contributions with proposed solutions to have all ideas clear > so that we can move forward. > > > Finally, Ed - what we are looking for is the solution of the problem (not > adding or deleting some terminologies here and there). We have plenty to solutions, but weak definitions. Thanks > > > Hope this email will clarify your concern. > > Best regards, > Radhika > > > -----Original Message----- > > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > > Sent: Friday, November 05, 1999 6:31 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: H323 mobility: Summary of discussion > > > > To the Mobile Ad-hoc Colleges: > > > > What we have here is an opportunity to build a good > > working relationship. But, it seems at this time, > > we are in feeling out stage. Solutions and proposals > > are being worked within companies and in > > difference standards, which want to find a > > place in the work we are doing but, I think > > compromise is in order. > > > > The only thing I was suggesting in by email, > > was that the word "Home and Visited" bother soon > > of our colleges. So my suggestion was to persevere > > the functions and compromise on the naming of the functions. > > > > By definition, whatever we put in the H.323 mobility > > document will have to be in the > > context of the H.323 framework baseline. > > > > Lets keep an open mind as we move forward, > > Y peace. We all may learn something and discover > > new things. If possible lets start looking on compromise > > solutions that satisfies all involved. Once we limit our > > scope it limits us from progressing towards the future. > > > > Best Regards, > > Ed > > > > "Roy, Radhika R, ALARC" wrote: > > > > > Hi, Ed and All: > > > > > > I do not know whether you have seen my reply to Jaakko. I am enclosing > > it > > > again. Please respond to my reply to provided Jaakko to prove your > > > statement. > > > > > > I completely disagree with Ed. Please also see Marc Roelands's comments > > on > > > LA. > > > > > > AT&T contribution has shown how H.323 mobility problem can be solved > > using > > > home/foreign GK (zone). > > > > > > I like to see the complete H.323 mobility problem that has been solved > > using > > > the alternative approach as proposed by Nokia. I have NOT seen Nokia's > > > solution yet. Unless a complete solution is provided like AT&T's, I am > > NOT > > > convinced how mobility problem can be solved in a better way. > > > > > > I also see that there is a need for HLF/VLF. No one against the HLF/VLF > > > function. AT&T proposal also has shown how HLF/VLF function is taken > > > care-of. > > > > > > What I disagree with is this: A protocol should NOT be implementation > > > specific. For example, we do have a luxury to build one protocol for > > > distributive GK (HLF/VLF) function, one protocol for centralized GK > > > (HLF/VLF) function or one protocol for hybrid GK (HLF/HLF) function. It > > is > > > against the fundamental concept of H.323. For example, the same argument > > can > > > also be applied for the directory function. Similar may the case for > > other > > > functions as well. It is a complete break down of H.323 protocol and > > > architecture. > > > > > > So, HLF/VLF is another function in H.323. HLF/VLF is NOT a "Holy Grail" > > for > > > which we have to create a complete "DISCONTINUITY" in existing H.323 > > > protocol and architecture. I like see to Nokia's alternate solution to > > > disprove this fear. > > > > > > Nokia has to bring a complete contribution providing solution like > > AT&T's to > > > prove their case. Otherwise, we cannot proceed with a concept that has > > not > > > proved with a solution. > > > > > > The problem can be solved as follows: > > > > > > 1. Let Nokia provide a complete proposal solving the H.323 mobility > > problem > > > using heir alternative approach. What Nokia has provided is a high level > > > concept. They have NOT solved the problem yet. Let us see what the > > complete > > > solution is. If a solution is provided, we can then compare Nokia's > > solution > > > with that of AT&T's solution. Otherwise, their proposal is still > > > HYPOTHETICAL. It is a concept, NOT a solution. > > > > > > 2. How can we agree on a concept without seeing its solution that has > > the > > > potential to break down the fundamental architecture of existing H.323 > > > standard? > > > > > > 3. Let us solve H.323 mobility problem within the framework of H.323. > > > > > > 4. Let us move on with contributions for the part that we can agree on. > > If > > > Nokia brings a complete solution, we will definitely re-consider their > > case. > > > > > > 5. I agree with you that we also need to work for interworking between > > H.323 > > > (IP) mobility and cellular-PSTN/ISDN network. > > > > > > Finally, Ed - you have made a statement, but it has to be proved > > providing a > > > solution. An alternative concept is there, but we have not seen its > > solution > > > yet. What is the problem to bring the alternate solution? Why do we need > > to > > > wait for a concept that has NOT been substantiated with a solution yet? > > > > > > Best regards, > > > Radhika > > > > > > > -----Original Message----- > > > > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > > > > Sent: Thursday, November 04, 1999 9:47 AM > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > > Subject: Re: H323mobility: Summary of discussion > > > > Importance: High > > > > > > > > I agreed with most of Jaakko comments and also > > > > make vaild points, and will like to > > > > add the following. > > > > > > > > I believe that the (Home) in Home Zone should be taken out. > > > > What we are talking about is the User's Point of Attached in > > > > any given Zone. The HLF is ready and Data base > > > > which has the User's profile and the current user's location. > > > > We can get a new name to HLF and call it the Location Profile > > > > Register (LPR) or Location Profile Function (LPF). > > > > > > > > I also believe that the (Visited) in Visited Zone sould also > > > > be taken out because again we are talking about > > > > the Users current Point of Attachment in any given Zone. > > > > The VLF has the means to update the > > > > Location Profile Register (LPR) from > > > > any given Zone. We can get a new name to VLF > > > > call it the Location Update Register (LUR) or > > > > Location Update Function (LUF). > > > > > > > > Now we can also support concepts of Zone ID's > > > > such as Current Zone ID and Previous Zone ID. > > > > > > > > Finally, > > > > > > > > And I strongly agree with looking at the interworking > > > > in parallel with H.323 mobility. The time we spent > > > > now looking at interworking will be compensated in the > > > > long run. I sure does working on ISUP, IN and Qsig, inetrworking > > > > with H.323 would agree and we should learn from their experience. > > > > And not leave it for a last minute add-on. > > > > > > > > Lets take the contribution as they come, if one wants to put in > > > > interworking fine. If one wants to put in contributions only H.323 > > > > mobility also fine. Both are in order and within our scope. > > > > > > > > The general strategy should focus on ensuring that the H.323 > > > > Mobility and interworking options are enabled, rather than spending > > > > too much effort blocking alternative options (Our limited resources > > > > frankly don't allow this luxury). But there really is no substitute > > for > > > > doing the work - preparing input papers and presenting them > > > > to move things forward. > > > > > > > > Best Regards, > > > > > > > > Ed > > > [Roy, Radhika R] Hi, Jaakko: > > > > > > Pl. see my reply provided below. > > > > > > Best regards, > > > Radhika > > > > > > -----Original Message----- > > > From: jaakko.sundquist(a)NOKIA.COM > > [SMTP:jaakko.sundquist@NOKIA.COM] > > > Sent: Tuesday, November 02, 1999 11:13 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: H323mobility: meeting > > > > > > Once again, hi, Radhika, Ed + all > > > > > > See my comments below... > > > > > > Hi, Jaakko, Ed, and All: > > > > > > I hope that Jaakko will get this mail while he > > is in > > > his > > > office (Thanks > > > Jaakko - you have reminded us the time > > difference)! > > > > > > [Jaakko:] You caught me just in time. > > > > > > Please note the following: > > > > > > 1. Zone and domain are well defined in H.323. > > > [Jaakko:] Yes, they are defined. > > > > > > 2. We have to work for mobility solution in a > > way > > > that fits > > > very well that > > > already exists in H.323. > > > > > > [Jaakko:] Agreed. > > > > > > 3. We can invent many things if we need to solve > > > mobility > > > problems only when > > > we think that those functions are NOT covered in > > > existing > > > H.323 standard. > > > > > > [Jaakko:] Yes. > > > > > > 4. If mobility problems can be solved using the > > > concept of > > > "zones" and > > > "domains," I would assume that it would be a big > > > mile stone > > > so far the > > > continuity of H.323 is concerned. That is, as Ed > > > pointed > > > out, H.323 mobility > > > problem is NOT a rocket science. We have to > > remember > > > that we > > > are working in > > > the framework of already existing H.323 standard > > > architecture. We have to > > > relate our solution in the context of existing > > H.323 > > > standard. In other > > > words, we CANNOT change the fundamental concept > > of > > > existing > > > H.323 standards > > > just because we are addressing mobility. > > > > > > [Jaakko:] Yes, of course. I'm not arguing > > against > > > that. I > > > guess you are referring to the Location Area discussion here. > > The LA > > > concept > > > is really merely a scaling issue, you could of course handle > > paging > > > (I'm > > > assuming that we will need the paging procedure) based on zones, > > > i.e. page > > > every NPoA in a zone when a call arrives, but this might be > > quite > > > limiting > > > in some cases (the zone may be needlessly big or very small). I > > do > > > not think > > > that we need to change any fundamental concepts of H.323, if we > > > introduce > > > the LA concept. > > > [Roy, Radhika R] May be we can include LA when we see that we > > need > > > to optimize a zone further. We may revisit this in the second step. > > > > > > 5. I do not understand what benefits we are > > gaining > > > adding > > > more > > > "terminologies" like "AREA {home, foreign, etc}" > > > while the > > > "zone" and > > > "domain" are already well defined in H.323. My > > > personal view > > > is that we > > > should FIRST try to solve H.323 mobility > > problems > > > within the > > > context of > > > "zone" and "domain" as far as practicable. I > > would > > > argue > > > that zone and > > > domain are good enough to serve this purpose for > > > now. (Pl. > > > also see AT&T's > > > and Motorola's contributions.) > > > > > > [Jaakko:] As I already said, I did not intent to > > > define the > > > terms: home area and visited area. I was just trying to > > illustrate > > > the point > > > I was making about not having the Home/visited zone terms > > defined > > > yet. > > > [Roy, Radhika R] It is good point. Let us define these. AT&T > > > contributions have the detail definition for each term. > > > > > > 6. With respect to your comments that it appears > > > that every > > > GK will have HLF > > > and VLF function, I would say that every GK will > > > have the > > > access to the HLF > > > and VLF function. This capability for each GK > > has to > > > be > > > provided because of > > > the fact that H.323 architecture is GK-centric. > > We > > > do not > > > have any choice > > > because we are restricted by the H.323 > > architecture. > > > > > > [Jaakko:] I did not argue against this. The > > point is > > > that if > > > we identify a concept called the Home Zone, this already implies > > > that each > > > User has only one zone, in which he/she/it is not a "visiting > > user". > > > I think > > > this would be really restricting. > > > [Roy, Radhika R] As I mentioned that H.323 is the GK-centric. A > > > user may change his/her network point of point attachment, but it is > > still > > > the same (Home) GK. So, a given (home) GK, there has to be another level > > of > > > granularity to address mobility in terms of network point of attachment. > > > Please see AT&T contribution how home and foreign network concept have > > > solved the problem. Similar is the case with Motorola's contribution. > > The > > > bottom line is that home/foreign GK concept does NOT imply any > > restriction > > > to solve H.323 mobility. > > > > > > 6.1 With respect to your question whether > > HLF/VLF > > > can be > > > distributive or > > > centralized, having said (in item 5) that every > > GK > > > should > > > have access to HLF > > > and VLF function, it is up to implementation > > whether > > > HLF and > > > VLF function > > > can be centralized or distributive. Please see > > AT&T > > > contributions submitted > > > in Red Bank how we can implement these functions > > in > > > both > > > distributive and > > > centralized environment. > > > > > > [Jaakko:] This is actually quite much the point > > I > > > was > > > making. By defining the Home Zone we would in my mind actually > > be > > > pointing > > > to the centralized model. > > > [Roy, Radhika R] By definition, there can as many GKs as one > > wish > > > have in an H.323 system. So, by definition, the GK-centric H.323 > > > architecture is distributive. By defining home/foreign GK, H.323 > > mobility > > > also becomes distributive up to the point that a basic H.323 system > > allows > > > us. So, we do not see any limitations. > > > > > > 6.2 In an analogy of this HLF/VLF function, I > > can > > > bring > > > another function - > > > Directory services. For example, H.323 assumes > > that > > > all the > > > address (e.g., > > > alias, transport, network) are kept by each GK. > > > H.323 does > > > not answer how > > > the address information is maintained by each > > GK. > > > People are > > > using LDAP > > > directory server. The question is: whether that > > > directory > > > service is > > > distributive or centralized? I guess that it can > > be > > > done in > > > both ways > > > depending on implementation. > > > > > > [Jaakko:] My point exactly. I would like that > > all > > > GKs inside > > > the same Administrative Domain would be able to access the same > > > HLF/VLF > > > functionality. > > > [Roy, Radhika R] As I pointed out, this an implementation > > issue. I > > > would argue that we should allow both options and let an implementor > > choose > > > as it is necessary. Please also see AT&T contributions how both options > > can > > > be addressed. > > > > > > 6.3 In AT&T contribution, it is shown that it > > better > > > to make > > > VLF > > > distributive (per GK) although HLF function can > > be > > > made both > > > distributive > > > and centralized. Again, this is a matter of > > > implementation. > > > As mentioned in > > > AT&T contribution, we also need to define a kind > > of > > > backend > > > protocol for VLF > > > and HLF (something like similar to Siemens, > > Nokia > > > and > > > Intel's contribution - > > > TD-39: Security Services for Backend Services > > and > > > Mobility > > > in H.323). > > > > > > [Jaakko:] I would assume that you can distribute > > the > > > HLF/VLF > > > functionalities inside the Administrative Domain as you like, > > but > > > distributing them between the Domains would be difficult. > > Actually I > > > think > > > that the concept of Administrative Domain was introduced in > > H.323 > > > for this > > > kind of reasons. > > > [Roy, Radhika R] Again, H.323 system is GK-centric in a given > > > domain. For inter-domain, it is BE-centric. In a given domain, H.323 > > > architecture has to be GK-centric. Once we solve intra-zone and > > inter-zone > > > (intra-domain) mobility, we can extend our experience for inter-domain > > > problem as well. Please also see AT&T contribution how these problems > > have > > > been addressed. My replies to 6.1 and 6.2 are also good for this case. > > > > > > 7. Again, I, personally, do not rule our to > > > re-examine the > > > benfit of "AREA" > > > (e.g. location area [LA]) vs. "ZONE/DOMAIN" > > concept. > > > May be > > > it is in the > > > second step. > > > > > > [Jaakko:] I am just a bit afraid that if we > > leave > > > this kind > > > of a major mobility related concept out of the first phase > > thinking > > > process, > > > we will find it much more difficult to include the concept in > > the > > > second > > > phase (where I think we will need it). Furthermore, I'm not > > > convinced that > > > the LA concept would not be useful in the pure H.323 approach > > > either. > > > [Roy, Radhika R] I think that it can be place holder for now. I > > > would request to bring more detail contributions proposing solutions > > like > > > AT&T and Motorola to prove the case better. Then, we can compare both > > > solutions. In AT&T contribution, I feel that the LA can be accommodated > > to > > > optimize the zone further. So, I do not see that it is a problem to > > > accommodate the LA concept if needed. I personally prefer that we can > > better > > > address this in the second phase once we solve the problem for the basic > > > architecture. > > > > > > Hope that this email will clarify the things > > better. > > > > > > [Jaakko:] I think the main thing is that we got > > the > > > discussion going on again. I'm kind of tired already, and I hope > > > that I > > > didn't mess things up too much in this mail. > > > [Roy, Radhika R] Definitely, I also like that discussions must > > go > > > on. We must be convinced that we have the best solution because it has > > the > > > severe implications for all on-going mobility standard works throughout > > the > > > world once we standardize H.323 mobility in SG16. > > > > > > Best regards, > > > Radhika > > > > > > Same to you, > > > Jaakko > > > > -- > > > > Edgar Martinez - Principal Staff Engineer > > > > Email mailto:martinze@cig.mot.com > > > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > > > 1501 West Shure Drive, Arlington Hgts. IL 60004 > > > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > > > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > > > > -- > > Edgar Martinez - Principal Staff Engineer > > Email mailto:martinze@cig.mot.com > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > 1501 West Shure Drive, Arlington Hgts. IL 60004 > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: H323 mobility: Summary of discussion
by Roy, Radhika R, ALARC 08 Nov '99

08 Nov '99

Hi, Ed and All: I understand your point. As I explained that contributions with solution have been provided based on "Home and Visited" solving the mobility problems. All members are welcomed to provide solutions based on their concepts. If the alternate solutions are provided based on contributions we will definitely be able to see how solutions are provided based on alternate ideas or terminologies. Then, we will have wonderful opportunities to compare each idea or terminology without any confusion or ambiguity. Definitely we are waiting to make compromises if we collectively see that it makes sense to do so when we see that there are better solutions available based on alternative approaches. We are only in definition phase. These are the place holders. If the architectural solution that we will be agreeing with does not support those definitions or terminologies we will definitely change these. There should not be any doubt about this. I do not see why we should hold-off our discussions for these two terms. As an Editor, I suggest that you can put a note that "some members have some objection to agree on these two terms, but we will revisit these terms when we finalize our architectural solution." We will have an architectural discussion in the upcoming conference call. We have invited contributions with proposed solutions to have all ideas clear so that we can move forward. Finally, Ed - what we are looking for is the solution of the problem (not adding or deleting some terminologies here and there). Hope this email will clarify your concern. Best regards, Radhika > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > Sent: Friday, November 05, 1999 6:31 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H323 mobility: Summary of discussion > > To the Mobile Ad-hoc Colleges: > > What we have here is an opportunity to build a good > working relationship. But, it seems at this time, > we are in feeling out stage. Solutions and proposals > are being worked within companies and in > difference standards, which want to find a > place in the work we are doing but, I think > compromise is in order. > > The only thing I was suggesting in by email, > was that the word "Home and Visited" bother soon > of our colleges. So my suggestion was to persevere > the functions and compromise on the naming of the functions. > > By definition, whatever we put in the H.323 mobility > document will have to be in the > context of the H.323 framework baseline. > > Lets keep an open mind as we move forward, > Y peace. We all may learn something and discover > new things. If possible lets start looking on compromise > solutions that satisfies all involved. Once we limit our > scope it limits us from progressing towards the future. > > Best Regards, > Ed > > "Roy, Radhika R, ALARC" wrote: > > > Hi, Ed and All: > > > > I do not know whether you have seen my reply to Jaakko. I am enclosing > it > > again. Please respond to my reply to provided Jaakko to prove your > > statement. > > > > I completely disagree with Ed. Please also see Marc Roelands's comments > on > > LA. > > > > AT&T contribution has shown how H.323 mobility problem can be solved > using > > home/foreign GK (zone). > > > > I like to see the complete H.323 mobility problem that has been solved > using > > the alternative approach as proposed by Nokia. I have NOT seen Nokia's > > solution yet. Unless a complete solution is provided like AT&T's, I am > NOT > > convinced how mobility problem can be solved in a better way. > > > > I also see that there is a need for HLF/VLF. No one against the HLF/VLF > > function. AT&T proposal also has shown how HLF/VLF function is taken > > care-of. > > > > What I disagree with is this: A protocol should NOT be implementation > > specific. For example, we do have a luxury to build one protocol for > > distributive GK (HLF/VLF) function, one protocol for centralized GK > > (HLF/VLF) function or one protocol for hybrid GK (HLF/HLF) function. It > is > > against the fundamental concept of H.323. For example, the same argument > can > > also be applied for the directory function. Similar may the case for > other > > functions as well. It is a complete break down of H.323 protocol and > > architecture. > > > > So, HLF/VLF is another function in H.323. HLF/VLF is NOT a "Holy Grail" > for > > which we have to create a complete "DISCONTINUITY" in existing H.323 > > protocol and architecture. I like see to Nokia's alternate solution to > > disprove this fear. > > > > Nokia has to bring a complete contribution providing solution like > AT&T's to > > prove their case. Otherwise, we cannot proceed with a concept that has > not > > proved with a solution. > > > > The problem can be solved as follows: > > > > 1. Let Nokia provide a complete proposal solving the H.323 mobility > problem > > using heir alternative approach. What Nokia has provided is a high level > > concept. They have NOT solved the problem yet. Let us see what the > complete > > solution is. If a solution is provided, we can then compare Nokia's > solution > > with that of AT&T's solution. Otherwise, their proposal is still > > HYPOTHETICAL. It is a concept, NOT a solution. > > > > 2. How can we agree on a concept without seeing its solution that has > the > > potential to break down the fundamental architecture of existing H.323 > > standard? > > > > 3. Let us solve H.323 mobility problem within the framework of H.323. > > > > 4. Let us move on with contributions for the part that we can agree on. > If > > Nokia brings a complete solution, we will definitely re-consider their > case. > > > > 5. I agree with you that we also need to work for interworking between > H.323 > > (IP) mobility and cellular-PSTN/ISDN network. > > > > Finally, Ed - you have made a statement, but it has to be proved > providing a > > solution. An alternative concept is there, but we have not seen its > solution > > yet. What is the problem to bring the alternate solution? Why do we need > to > > wait for a concept that has NOT been substantiated with a solution yet? > > > > Best regards, > > Radhika > > > > > -----Original Message----- > > > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > > > Sent: Thursday, November 04, 1999 9:47 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: H323mobility: Summary of discussion > > > Importance: High > > > > > > I agreed with most of Jaakko comments and also > > > make vaild points, and will like to > > > add the following. > > > > > > I believe that the (Home) in Home Zone should be taken out. > > > What we are talking about is the User's Point of Attached in > > > any given Zone. The HLF is ready and Data base > > > which has the User's profile and the current user's location. > > > We can get a new name to HLF and call it the Location Profile > > > Register (LPR) or Location Profile Function (LPF). > > > > > > I also believe that the (Visited) in Visited Zone sould also > > > be taken out because again we are talking about > > > the Users current Point of Attachment in any given Zone. > > > The VLF has the means to update the > > > Location Profile Register (LPR) from > > > any given Zone. We can get a new name to VLF > > > call it the Location Update Register (LUR) or > > > Location Update Function (LUF). > > > > > > Now we can also support concepts of Zone ID's > > > such as Current Zone ID and Previous Zone ID. > > > > > > Finally, > > > > > > And I strongly agree with looking at the interworking > > > in parallel with H.323 mobility. The time we spent > > > now looking at interworking will be compensated in the > > > long run. I sure does working on ISUP, IN and Qsig, inetrworking > > > with H.323 would agree and we should learn from their experience. > > > And not leave it for a last minute add-on. > > > > > > Lets take the contribution as they come, if one wants to put in > > > interworking fine. If one wants to put in contributions only H.323 > > > mobility also fine. Both are in order and within our scope. > > > > > > The general strategy should focus on ensuring that the H.323 > > > Mobility and interworking options are enabled, rather than spending > > > too much effort blocking alternative options (Our limited resources > > > frankly don't allow this luxury). But there really is no substitute > for > > > doing the work - preparing input papers and presenting them > > > to move things forward. > > > > > > Best Regards, > > > > > > Ed > > [Roy, Radhika R] Hi, Jaakko: > > > > Pl. see my reply provided below. > > > > Best regards, > > Radhika > > > > -----Original Message----- > > From: jaakko.sundquist(a)NOKIA.COM > [SMTP:jaakko.sundquist@NOKIA.COM] > > Sent: Tuesday, November 02, 1999 11:13 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: H323mobility: meeting > > > > Once again, hi, Radhika, Ed + all > > > > See my comments below... > > > > Hi, Jaakko, Ed, and All: > > > > I hope that Jaakko will get this mail while he > is in > > his > > office (Thanks > > Jaakko - you have reminded us the time > difference)! > > > > [Jaakko:] You caught me just in time. > > > > Please note the following: > > > > 1. Zone and domain are well defined in H.323. > > [Jaakko:] Yes, they are defined. > > > > 2. We have to work for mobility solution in a > way > > that fits > > very well that > > already exists in H.323. > > > > [Jaakko:] Agreed. > > > > 3. We can invent many things if we need to solve > > mobility > > problems only when > > we think that those functions are NOT covered in > > existing > > H.323 standard. > > > > [Jaakko:] Yes. > > > > 4. If mobility problems can be solved using the > > concept of > > "zones" and > > "domains," I would assume that it would be a big > > mile stone > > so far the > > continuity of H.323 is concerned. That is, as Ed > > pointed > > out, H.323 mobility > > problem is NOT a rocket science. We have to > remember > > that we > > are working in > > the framework of already existing H.323 standard > > architecture. We have to > > relate our solution in the context of existing > H.323 > > standard. In other > > words, we CANNOT change the fundamental concept > of > > existing > > H.323 standards > > just because we are addressing mobility. > > > > [Jaakko:] Yes, of course. I'm not arguing > against > > that. I > > guess you are referring to the Location Area discussion here. > The LA > > concept > > is really merely a scaling issue, you could of course handle > paging > > (I'm > > assuming that we will need the paging procedure) based on zones, > > i.e. page > > every NPoA in a zone when a call arrives, but this might be > quite > > limiting > > in some cases (the zone may be needlessly big or very small). I > do > > not think > > that we need to change any fundamental concepts of H.323, if we > > introduce > > the LA concept. > > [Roy, Radhika R] May be we can include LA when we see that we > need > > to optimize a zone further. We may revisit this in the second step. > > > > 5. I do not understand what benefits we are > gaining > > adding > > more > > "terminologies" like "AREA {home, foreign, etc}" > > while the > > "zone" and > > "domain" are already well defined in H.323. My > > personal view > > is that we > > should FIRST try to solve H.323 mobility > problems > > within the > > context of > > "zone" and "domain" as far as practicable. I > would > > argue > > that zone and > > domain are good enough to serve this purpose for > > now. (Pl. > > also see AT&T's > > and Motorola's contributions.) > > > > [Jaakko:] As I already said, I did not intent to > > define the > > terms: home area and visited area. I was just trying to > illustrate > > the point > > I was making about not having the Home/visited zone terms > defined > > yet. > > [Roy, Radhika R] It is good point. Let us define these. AT&T > > contributions have the detail definition for each term. > > > > 6. With respect to your comments that it appears > > that every > > GK will have HLF > > and VLF function, I would say that every GK will > > have the > > access to the HLF > > and VLF function. This capability for each GK > has to > > be > > provided because of > > the fact that H.323 architecture is GK-centric. > We > > do not > > have any choice > > because we are restricted by the H.323 > architecture. > > > > [Jaakko:] I did not argue against this. The > point is > > that if > > we identify a concept called the Home Zone, this already implies > > that each > > User has only one zone, in which he/she/it is not a "visiting > user". > > I think > > this would be really restricting. > > [Roy, Radhika R] As I mentioned that H.323 is the GK-centric. A > > user may change his/her network point of point attachment, but it is > still > > the same (Home) GK. So, a given (home) GK, there has to be another level > of > > granularity to address mobility in terms of network point of attachment. > > Please see AT&T contribution how home and foreign network concept have > > solved the problem. Similar is the case with Motorola's contribution. > The > > bottom line is that home/foreign GK concept does NOT imply any > restriction > > to solve H.323 mobility. > > > > 6.1 With respect to your question whether > HLF/VLF > > can be > > distributive or > > centralized, having said (in item 5) that every > GK > > should > > have access to HLF > > and VLF function, it is up to implementation > whether > > HLF and > > VLF function > > can be centralized or distributive. Please see > AT&T > > contributions submitted > > in Red Bank how we can implement these functions > in > > both > > distributive and > > centralized environment. > > > > [Jaakko:] This is actually quite much the point > I > > was > > making. By defining the Home Zone we would in my mind actually > be > > pointing > > to the centralized model. > > [Roy, Radhika R] By definition, there can as many GKs as one > wish > > have in an H.323 system. So, by definition, the GK-centric H.323 > > architecture is distributive. By defining home/foreign GK, H.323 > mobility > > also becomes distributive up to the point that a basic H.323 system > allows > > us. So, we do not see any limitations. > > > > 6.2 In an analogy of this HLF/VLF function, I > can > > bring > > another function - > > Directory services. For example, H.323 assumes > that > > all the > > address (e.g., > > alias, transport, network) are kept by each GK. > > H.323 does > > not answer how > > the address information is maintained by each > GK. > > People are > > using LDAP > > directory server. The question is: whether that > > directory > > service is > > distributive or centralized? I guess that it can > be > > done in > > both ways > > depending on implementation. > > > > [Jaakko:] My point exactly. I would like that > all > > GKs inside > > the same Administrative Domain would be able to access the same > > HLF/VLF > > functionality. > > [Roy, Radhika R] As I pointed out, this an implementation > issue. I > > would argue that we should allow both options and let an implementor > choose > > as it is necessary. Please also see AT&T contributions how both options > can > > be addressed. > > > > 6.3 In AT&T contribution, it is shown that it > better > > to make > > VLF > > distributive (per GK) although HLF function can > be > > made both > > distributive > > and centralized. Again, this is a matter of > > implementation. > > As mentioned in > > AT&T contribution, we also need to define a kind > of > > backend > > protocol for VLF > > and HLF (something like similar to Siemens, > Nokia > > and > > Intel's contribution - > > TD-39: Security Services for Backend Services > and > > Mobility > > in H.323). > > > > [Jaakko:] I would assume that you can distribute > the > > HLF/VLF > > functionalities inside the Administrative Domain as you like, > but > > distributing them between the Domains would be difficult. > Actually I > > think > > that the concept of Administrative Domain was introduced in > H.323 > > for this > > kind of reasons. > > [Roy, Radhika R] Again, H.323 system is GK-centric in a given > > domain. For inter-domain, it is BE-centric. In a given domain, H.323 > > architecture has to be GK-centric. Once we solve intra-zone and > inter-zone > > (intra-domain) mobility, we can extend our experience for inter-domain > > problem as well. Please also see AT&T contribution how these problems > have > > been addressed. My replies to 6.1 and 6.2 are also good for this case. > > > > 7. Again, I, personally, do not rule our to > > re-examine the > > benfit of "AREA" > > (e.g. location area [LA]) vs. "ZONE/DOMAIN" > concept. > > May be > > it is in the > > second step. > > > > [Jaakko:] I am just a bit afraid that if we > leave > > this kind > > of a major mobility related concept out of the first phase > thinking > > process, > > we will find it much more difficult to include the concept in > the > > second > > phase (where I think we will need it). Furthermore, I'm not > > convinced that > > the LA concept would not be useful in the pure H.323 approach > > either. > > [Roy, Radhika R] I think that it can be place holder for now. I > > would request to bring more detail contributions proposing solutions > like > > AT&T and Motorola to prove the case better. Then, we can compare both > > solutions. In AT&T contribution, I feel that the LA can be accommodated > to > > optimize the zone further. So, I do not see that it is a problem to > > accommodate the LA concept if needed. I personally prefer that we can > better > > address this in the second phase once we solve the problem for the basic > > architecture. > > > > Hope that this email will clarify the things > better. > > > > [Jaakko:] I think the main thing is that we got > the > > discussion going on again. I'm kind of tired already, and I hope > > that I > > didn't mess things up too much in this mail. > > [Roy, Radhika R] Definitely, I also like that discussions must > go > > on. We must be convinced that we have the best solution because it has > the > > severe implications for all on-going mobility standard works throughout > the > > world once we standardize H.323 mobility in SG16. > > > > Best regards, > > Radhika > > > > Same to you, > > Jaakko > > > -- > > > Edgar Martinez - Principal Staff Engineer > > > Email mailto:martinze@cig.mot.com > > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > > 1501 West Shure Drive, Arlington Hgts. IL 60004 > > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re-send: [Robustness] Call Clearing related
by Orit Levin 07 Nov '99

07 Nov '99

I am re-sending my previous message upon getting an indication about network problems. Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com -----Original Message----- From: Orit Levin <orit(a)radvision.com> To: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com> Date: Friday, November 05, 1999 5:09 PM Subject: Re: [Robustness] Call Clearing related >Hello Paul, Tzvi and all others! > >Yes, once again I am "in complete agreement with his proposal in Red Bank to >strike the text in the current version that allows for the closure of the >call signaling channel". This point of view is alignment with (a) in my >previous mail. Just to add to it: If we decide to keep in the Standard the >possibility to signal an intentional closure of Q.931 logical connection by >dropping its TCP connection, we make the future Recovery procedures much >more complicated. And I ask everybody on this list: Who knows about H.323 >existing commercial implementations that intentionally close Q.931 TCP >connection and expect the Call to be kept by the other side? Based on >RADVision's internal resources and being participants in all >interoperability events, we don't know of any! > >In regards to (b): >Tzvi! To recover from a GK crash (for all types of calls) should be one of >the first topics of Robustness Work. There is no question about it!!! My >point (b) was that in order to achieve the solution, the "passive" behavior >of EP (a sort of implying in the Standard today) would not >help. Additional new procedures have to be added to H.323 in the context of >Robustness work. Today's Endpoints don't support these future procedures, >therefore their passive behavior (or T.O.) will not solve the problem even >if the other side supports the new Robustness Procedures. > >Why passive behavior /T.O. doesn't help: > >(1) When an application (such as H.323) gets a notification from TCP >layer about the failure of specific TCP connection (port+IP), the connection >is already closed by the TCP layer. The only way to revive Q.931 connection >is to LISTEN for a NEW incoming connection, accept it and somehow (such as >by callID) to logically attach the new TCP connection to the old Call. If it >had been the only problem in the puzzle (which is not: see (2) below) >technically it could have been defined, but it is NOT today. (This is >definitely a job for our Robustness group.) Therefore NO H.323v1-3 compliant >EP implements such a procedure! > >(2) The more difficult problem is that upon TCP channel failure, the TPKT >connection above gets out of synch. It means that the application layer >doesn't know automatically what part of information got lost. In this case, >in order to synchronize H.323 Call state between the two sides, application >level handshake must be introduced. This is also definitely a job for our >Robustness group. > >Cheers, >Orit Levin >RADVision Inc. >575 Corporate Drive Suite 420 >Mahwah, NJ 07430 >Tel: 1 201 529 4300 (230) >Fax: 1 201 529 3516 >www.radvision.com >orit(a)radvision.com > >

1 0

None
by ITU-SG16＠MAILBAG.CPS.INTEL.COM 07 Nov '99

07 Nov '99

NOTICE -- NOTICE -- NOTICE -- NOTICE -- NOTICE -- NOTICE -- NOTICE This email could not be delivered. Please resend to try again. NOTICE -- NOTICE -- NOTICE -- NOTICE -- NOTICE -- NOTICE -- NOTICE Received: from mx10.netvision.net.il ([194.90.1.52]) by 199.203.164.18 (Norton AntiVirus for Internet Email Gateways 1.0) ; Sun, 07 Nov 1999 06:45:30 0000 (GMT) Received: from mailbag.cps.intel.com (mailbag.cps.intel.com [192.102.199.72]) by mx10.netvision.net.il (8.9.3/8.9.3) with ESMTP id AAA14583 for <roni_e(a)ACCORD.CO.IL>; Sat, 6 Nov 1999 00:10:18 +0200 (IST) Received: from mailbag.intel.com (mailbag.cps.intel.com [192.102.199.72]) by mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id OAA29715; Fri, 5 Nov 1999 14:10:48 -0800 (PST) Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 170771 for ITU-SG16(a)MAILBAG.INTEL.COM; Fri, 5 Nov 1999 14:10:48 -0800 Received: from hvmta01-stg.us.psimail.psi.net ([38.202.36.29]) by mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id OAA29711 for <ITU-SG16(a)mailbag.cps.intel.com>; Fri, 5 Nov 1999 14:10:47 -0800 (PST) Received: from software_1 ([38.150.216.23]) by hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <19991105220816.QQGV4501.hvmta01-stg@software_1> for <ITU-SG16(a)mailbag.cps.intel.com>; Fri, 5 Nov 1999 17:08:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Message-ID: <00e801bf27da$6f1d2cc0$17d89626(a)software_1.radvision.com> Date: Fri, 5 Nov 1999 17:09:30 -0500 Reply-To: Orit Levin <orit(a)radvision.com> Sender: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> From: Orit Levin <orit(a)radvision.com> Subject: Re: [Robustness] Call Clearing related Comments: To: ITU-SG16(a)mailbag.cps.intel.com To: ITU-SG16(a)mailbag.cps.intel.com Hello Paul, Tzvi and all others! Yes, once again I am "in complete agreement with his proposal in Red Bank to strike the text in the current version that allows for the closure of the call signaling channel". This point of view is alignment with (a) in my previous mail. Just to add to it: If we decide to keep in the Standard the possibility to signal an intentional closure of Q.931 logical connection by dropping its TCP connection, we make the future Recovery procedures much more complicated. And I ask everybody on this list: Who knows about H.323 existing commercial implementations that intentionally close Q.931 TCP connection and expect the Call to be kept by the other side? Based on RADVision's internal resources and being participants in all interoperability events, we don't know of any! In regards to (b): Tzvi! To recover from a GK crash (for all types of calls) should be one of the first topics of Robustness Work. There is no question about it!!! My point (b) was that in order to achieve the solution, the "passive" behavior of EP (a sort of implying in the Standard today) would not help. Additional new procedures have to be added to H.323 in the context of Robustness work. Today's Endpoints don't support these future procedures, therefore their passive behavior (or T.O.) will not solve the problem even if the other side supports the new Robustness Procedures. Why passive behavior /T.O. doesn't help: (1) When an application (such as H.323) gets a notification from TCP layer about the failure of specific TCP connection (port+IP), the connection is already closed by the TCP layer. The only way to revive Q.931 connection is to LISTEN for a NEW incoming connection, accept it and somehow (such as by callID) to logically attach the new TCP connection to the old Call. If it had been the only problem in the puzzle (which is not: see (2) below) technically it could have been defined, but it is NOT today. (This is definitely a job for our Robustness group.) Therefore NO H.323v1-3 compliant EP implements such a procedure! (2) The more difficult problem is that upon TCP channel failure, the TPKT connection above gets out of synch. It means that the application layer doesn't know automatically what part of information got lost. In this case, in order to synchronize H.323 Call state between the two sides, application level handshake must be introduced. This is also definitely a job for our Robustness group. Cheers, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com

1 0

Re: H323 mobility: Summary of discussion
by Edgar Martinez [1] 05 Nov '99

05 Nov '99

To the Mobile Ad-hoc Colleges: What we have here is an opportunity to build a good working relationship. But, it seems at this time, we are in feeling out stage. Solutions and proposals are being worked within companies and in difference standards, which want to find a place in the work we are doing but, I think compromise is in order. The only thing I was suggesting in by email, was that the word "Home and Visited" bother soon of our colleges. So my suggestion was to persevere the functions and compromise on the naming of the functions. By definition, whatever we put in the H.323 mobility document will have to be in the context of the H.323 framework baseline. Lets keep an open mind as we move forward, Y peace. We all may learn something and discover new things. If possible lets start looking on compromise solutions that satisfies all involved. Once we limit our scope it limits us from progressing towards the future. Best Regards, Ed "Roy, Radhika R, ALARC" wrote: > Hi, Ed and All: > > I do not know whether you have seen my reply to Jaakko. I am enclosing it > again. Please respond to my reply to provided Jaakko to prove your > statement. > > I completely disagree with Ed. Please also see Marc Roelands's comments on > LA. > > AT&T contribution has shown how H.323 mobility problem can be solved using > home/foreign GK (zone). > > I like to see the complete H.323 mobility problem that has been solved using > the alternative approach as proposed by Nokia. I have NOT seen Nokia's > solution yet. Unless a complete solution is provided like AT&T's, I am NOT > convinced how mobility problem can be solved in a better way. > > I also see that there is a need for HLF/VLF. No one against the HLF/VLF > function. AT&T proposal also has shown how HLF/VLF function is taken > care-of. > > What I disagree with is this: A protocol should NOT be implementation > specific. For example, we do have a luxury to build one protocol for > distributive GK (HLF/VLF) function, one protocol for centralized GK > (HLF/VLF) function or one protocol for hybrid GK (HLF/HLF) function. It is > against the fundamental concept of H.323. For example, the same argument can > also be applied for the directory function. Similar may the case for other > functions as well. It is a complete break down of H.323 protocol and > architecture. > > So, HLF/VLF is another function in H.323. HLF/VLF is NOT a "Holy Grail" for > which we have to create a complete "DISCONTINUITY" in existing H.323 > protocol and architecture. I like see to Nokia's alternate solution to > disprove this fear. > > Nokia has to bring a complete contribution providing solution like AT&T's to > prove their case. Otherwise, we cannot proceed with a concept that has not > proved with a solution. > > The problem can be solved as follows: > > 1. Let Nokia provide a complete proposal solving the H.323 mobility problem > using heir alternative approach. What Nokia has provided is a high level > concept. They have NOT solved the problem yet. Let us see what the complete > solution is. If a solution is provided, we can then compare Nokia's solution > with that of AT&T's solution. Otherwise, their proposal is still > HYPOTHETICAL. It is a concept, NOT a solution. > > 2. How can we agree on a concept without seeing its solution that has the > potential to break down the fundamental architecture of existing H.323 > standard? > > 3. Let us solve H.323 mobility problem within the framework of H.323. > > 4. Let us move on with contributions for the part that we can agree on. If > Nokia brings a complete solution, we will definitely re-consider their case. > > 5. I agree with you that we also need to work for interworking between H.323 > (IP) mobility and cellular-PSTN/ISDN network. > > Finally, Ed - you have made a statement, but it has to be proved providing a > solution. An alternative concept is there, but we have not seen its solution > yet. What is the problem to bring the alternate solution? Why do we need to > wait for a concept that has NOT been substantiated with a solution yet? > > Best regards, > Radhika > > > -----Original Message----- > > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > > Sent: Thursday, November 04, 1999 9:47 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: H323mobility: Summary of discussion > > Importance: High > > > > I agreed with most of Jaakko comments and also > > make vaild points, and will like to > > add the following. > > > > I believe that the (Home) in Home Zone should be taken out. > > What we are talking about is the User's Point of Attached in > > any given Zone. The HLF is ready and Data base > > which has the User's profile and the current user's location. > > We can get a new name to HLF and call it the Location Profile > > Register (LPR) or Location Profile Function (LPF). > > > > I also believe that the (Visited) in Visited Zone sould also > > be taken out because again we are talking about > > the Users current Point of Attachment in any given Zone. > > The VLF has the means to update the > > Location Profile Register (LPR) from > > any given Zone. We can get a new name to VLF > > call it the Location Update Register (LUR) or > > Location Update Function (LUF). > > > > Now we can also support concepts of Zone ID's > > such as Current Zone ID and Previous Zone ID. > > > > Finally, > > > > And I strongly agree with looking at the interworking > > in parallel with H.323 mobility. The time we spent > > now looking at interworking will be compensated in the > > long run. I sure does working on ISUP, IN and Qsig, inetrworking > > with H.323 would agree and we should learn from their experience. > > And not leave it for a last minute add-on. > > > > Lets take the contribution as they come, if one wants to put in > > interworking fine. If one wants to put in contributions only H.323 > > mobility also fine. Both are in order and within our scope. > > > > The general strategy should focus on ensuring that the H.323 > > Mobility and interworking options are enabled, rather than spending > > too much effort blocking alternative options (Our limited resources > > frankly don't allow this luxury). But there really is no substitute for > > doing the work - preparing input papers and presenting them > > to move things forward. > > > > Best Regards, > > > > Ed > [Roy, Radhika R] Hi, Jaakko: > > Pl. see my reply provided below. > > Best regards, > Radhika > > -----Original Message----- > From: jaakko.sundquist(a)NOKIA.COM [SMTP:jaakko.sundquist@NOKIA.COM] > Sent: Tuesday, November 02, 1999 11:13 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H323mobility: meeting > > Once again, hi, Radhika, Ed + all > > See my comments below... > > Hi, Jaakko, Ed, and All: > > I hope that Jaakko will get this mail while he is in > his > office (Thanks > Jaakko - you have reminded us the time difference)! > > [Jaakko:] You caught me just in time. > > Please note the following: > > 1. Zone and domain are well defined in H.323. > [Jaakko:] Yes, they are defined. > > 2. We have to work for mobility solution in a way > that fits > very well that > already exists in H.323. > > [Jaakko:] Agreed. > > 3. We can invent many things if we need to solve > mobility > problems only when > we think that those functions are NOT covered in > existing > H.323 standard. > > [Jaakko:] Yes. > > 4. If mobility problems can be solved using the > concept of > "zones" and > "domains," I would assume that it would be a big > mile stone > so far the > continuity of H.323 is concerned. That is, as Ed > pointed > out, H.323 mobility > problem is NOT a rocket science. We have to remember > that we > are working in > the framework of already existing H.323 standard > architecture. We have to > relate our solution in the context of existing H.323 > standard. In other > words, we CANNOT change the fundamental concept of > existing > H.323 standards > just because we are addressing mobility. > > [Jaakko:] Yes, of course. I'm not arguing against > that. I > guess you are referring to the Location Area discussion here. The LA > concept > is really merely a scaling issue, you could of course handle paging > (I'm > assuming that we will need the paging procedure) based on zones, > i.e. page > every NPoA in a zone when a call arrives, but this might be quite > limiting > in some cases (the zone may be needlessly big or very small). I do > not think > that we need to change any fundamental concepts of H.323, if we > introduce > the LA concept. > [Roy, Radhika R] May be we can include LA when we see that we need > to optimize a zone further. We may revisit this in the second step. > > 5. I do not understand what benefits we are gaining > adding > more > "terminologies" like "AREA {home, foreign, etc}" > while the > "zone" and > "domain" are already well defined in H.323. My > personal view > is that we > should FIRST try to solve H.323 mobility problems > within the > context of > "zone" and "domain" as far as practicable. I would > argue > that zone and > domain are good enough to serve this purpose for > now. (Pl. > also see AT&T's > and Motorola's contributions.) > > [Jaakko:] As I already said, I did not intent to > define the > terms: home area and visited area. I was just trying to illustrate > the point > I was making about not having the Home/visited zone terms defined > yet. > [Roy, Radhika R] It is good point. Let us define these. AT&T > contributions have the detail definition for each term. > > 6. With respect to your comments that it appears > that every > GK will have HLF > and VLF function, I would say that every GK will > have the > access to the HLF > and VLF function. This capability for each GK has to > be > provided because of > the fact that H.323 architecture is GK-centric. We > do not > have any choice > because we are restricted by the H.323 architecture. > > [Jaakko:] I did not argue against this. The point is > that if > we identify a concept called the Home Zone, this already implies > that each > User has only one zone, in which he/she/it is not a "visiting user". > I think > this would be really restricting. > [Roy, Radhika R] As I mentioned that H.323 is the GK-centric. A > user may change his/her network point of point attachment, but it is still > the same (Home) GK. So, a given (home) GK, there has to be another level of > granularity to address mobility in terms of network point of attachment. > Please see AT&T contribution how home and foreign network concept have > solved the problem. Similar is the case with Motorola's contribution. The > bottom line is that home/foreign GK concept does NOT imply any restriction > to solve H.323 mobility. > > 6.1 With respect to your question whether HLF/VLF > can be > distributive or > centralized, having said (in item 5) that every GK > should > have access to HLF > and VLF function, it is up to implementation whether > HLF and > VLF function > can be centralized or distributive. Please see AT&T > contributions submitted > in Red Bank how we can implement these functions in > both > distributive and > centralized environment. > > [Jaakko:] This is actually quite much the point I > was > making. By defining the Home Zone we would in my mind actually be > pointing > to the centralized model. > [Roy, Radhika R] By definition, there can as many GKs as one wish > have in an H.323 system. So, by definition, the GK-centric H.323 > architecture is distributive. By defining home/foreign GK, H.323 mobility > also becomes distributive up to the point that a basic H.323 system allows > us. So, we do not see any limitations. > > 6.2 In an analogy of this HLF/VLF function, I can > bring > another function - > Directory services. For example, H.323 assumes that > all the > address (e.g., > alias, transport, network) are kept by each GK. > H.323 does > not answer how > the address information is maintained by each GK. > People are > using LDAP > directory server. The question is: whether that > directory > service is > distributive or centralized? I guess that it can be > done in > both ways > depending on implementation. > > [Jaakko:] My point exactly. I would like that all > GKs inside > the same Administrative Domain would be able to access the same > HLF/VLF > functionality. > [Roy, Radhika R] As I pointed out, this an implementation issue. I > would argue that we should allow both options and let an implementor choose > as it is necessary. Please also see AT&T contributions how both options can > be addressed. > > 6.3 In AT&T contribution, it is shown that it better > to make > VLF > distributive (per GK) although HLF function can be > made both > distributive > and centralized. Again, this is a matter of > implementation. > As mentioned in > AT&T contribution, we also need to define a kind of > backend > protocol for VLF > and HLF (something like similar to Siemens, Nokia > and > Intel's contribution - > TD-39: Security Services for Backend Services and > Mobility > in H.323). > > [Jaakko:] I would assume that you can distribute the > HLF/VLF > functionalities inside the Administrative Domain as you like, but > distributing them between the Domains would be difficult. Actually I > think > that the concept of Administrative Domain was introduced in H.323 > for this > kind of reasons. > [Roy, Radhika R] Again, H.323 system is GK-centric in a given > domain. For inter-domain, it is BE-centric. In a given domain, H.323 > architecture has to be GK-centric. Once we solve intra-zone and inter-zone > (intra-domain) mobility, we can extend our experience for inter-domain > problem as well. Please also see AT&T contribution how these problems have > been addressed. My replies to 6.1 and 6.2 are also good for this case. > > 7. Again, I, personally, do not rule our to > re-examine the > benfit of "AREA" > (e.g. location area [LA]) vs. "ZONE/DOMAIN" concept. > May be > it is in the > second step. > > [Jaakko:] I am just a bit afraid that if we leave > this kind > of a major mobility related concept out of the first phase thinking > process, > we will find it much more difficult to include the concept in the > second > phase (where I think we will need it). Furthermore, I'm not > convinced that > the LA concept would not be useful in the pure H.323 approach > either. > [Roy, Radhika R] I think that it can be place holder for now. I > would request to bring more detail contributions proposing solutions like > AT&T and Motorola to prove the case better. Then, we can compare both > solutions. In AT&T contribution, I feel that the LA can be accommodated to > optimize the zone further. So, I do not see that it is a problem to > accommodate the LA concept if needed. I personally prefer that we can better > address this in the second phase once we solve the problem for the basic > architecture. > > Hope that this email will clarify the things better. > > [Jaakko:] I think the main thing is that we got the > discussion going on again. I'm kind of tired already, and I hope > that I > didn't mess things up too much in this mail. > [Roy, Radhika R] Definitely, I also like that discussions must go > on. We must be convinced that we have the best solution because it has the > severe implications for all on-going mobility standard works throughout the > world once we standardize H.323 mobility in SG16. > > Best regards, > Radhika > > Same to you, > Jaakko > > -- > > Edgar Martinez - Principal Staff Engineer > > Email mailto:martinze@cig.mot.com > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > 1501 West Shure Drive, Arlington Hgts. IL 60004 > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: H323 mobility: Summary of discussion
by Roy, Radhika R, ALARC 05 Nov '99

05 Nov '99

Hi, Barry and All: I am trying to understand what actually Barry's statement means: "I was to make H.323 work within the context of a mobile terminal and/or user, and also allow for service mobility." Is not the case both AT&T and Nokia's proposal are considering? Both proposals consider mobility in the context of H.323 mobility. The problems that need to be solved for the call scenarios as follows: 1. H.323 mobile terminal to H.323 mobile Terminal and vice versa 2. H.323 mobile terminal to H.323 fixed terminal and vice versa For interworking between H.323 (IP) network and cellular-PSTN/ISDN (APMS, ANSI-41, GSM): 3. Non-H.323 mobile terminal (cellular-PSTN/ISDN) to mobile H.323 (IP) terminal and vice versa 4.Non-H.323 mobile terminal (cellular-PSTN/ISDN) to fixed H.323 (IP) terminal and vice versa Both Nokia and AT&T proposals are addressing this problem. There is no disagreement. AT&T's proposal has provided a solution. Nokia's proposal is still in the conceptual phase. When Nokia's proposal provides a solution, it will be compared with the AT&T solution. Motorola's proposal is also along this line of the above four items. All we need to do is to compare solutions. For Motorola and AT&T, it is easy to do. In fact, I have a proposal to Ed. We can do this very easily. I am sure if all of you agree, we find a common solution through comparing these two solutions. Now we are waiting to see Nokia's complete solution. If Nokia's complete solution is presented, we also compare 3 solutions, and we can find a common solution. If other companies provide complete solutions, we can also compare all solutions together. >From my point of view, a complete process is under way. What is the problem then? All we need to see the proposals with complete solutions (not philosophical or conceptual statements). Please also see my reply to Tom Taylor. Hope that you can also bring proposals with solutions. Please do not worry about scope too much. Please see how Intel's proposal has created another appendix in mobility. If you think that you have some ideas with solutions like Intel, please provide to us. We will provide full attention to it. Hope that this email will clarify your concern too. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Barry Aronson [SMTP:baronson@ieee.org] > Sent: Friday, November 05, 1999 4:15 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H323 mobility: Summary of discussion > > All, > > I agree with Tom. We seem to be headed for designing an entire mobile > network within H.323 -- definitely a case of the tail wagging the dog. If > this was the desire, extending existing mobile networks (AMPS, GSM, etc.) > to > include H.323 terminals would be simpler. That is, of course, unless you > wanted the terminals to be independent of the physical network from the > network layer on up. H.323 could do this if there was an underlying packet > based network -- probably IP. Using IP as a common network layer for both > wireless and wired terminals is of course all the rage these days. Given > that universal wireless terminals are been worked as part of IMT-2000 (and > 3GPP, 3GPP-2, etc.), wouldn't it make sense to define the Annex H issues > being debated in the appropriate network groups? > > Maybe I misunderstood, but I thought in Santiago the purpose of Annex H > and > I was to make H.323 work within the context of a mobile terminal and/or > user, and also allow for service mobility. I don't think any of what is > being discussed for Annex H is necessary to achieve this. > > Barry > > -----Original Message----- > From: Mailing list for parties associated with ITU-T Study Group 16 > [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of Tom-PT Taylor > Sent: Friday, November 05, 1999 11:17 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H323 mobility: Summary of discussion > > > I think a basic point in this discussion is that mobility is "bigger than" > H.323 and already has well-established architectural underpinnings. It's > all very well to talk about an H.323 solution which we could then adapt, > but > we would more likely end up with an H.323-only solution as a result. The > concern then would be whether vendors saw sufficient opportunity in > building > to this market, compared with the general market for mobility products.

1 0

Re: [Robustness] Call Clearing related
by Orit Levin 05 Nov '99

05 Nov '99

Hello Paul, Tzvi and all others! Yes, once again I am "in complete agreement with his proposal in Red Bank to strike the text in the current version that allows for the closure of the call signaling channel". This point of view is alignment with (a) in my previous mail. Just to add to it: If we decide to keep in the Standard the possibility to signal an intentional closure of Q.931 logical connection by dropping its TCP connection, we make the future Recovery procedures much more complicated. And I ask everybody on this list: Who knows about H.323 existing commercial implementations that intentionally close Q.931 TCP connection and expect the Call to be kept by the other side? Based on RADVision's internal resources and being participants in all interoperability events, we don't know of any! In regards to (b): Tzvi! To recover from a GK crash (for all types of calls) should be one of the first topics of Robustness Work. There is no question about it!!! My point (b) was that in order to achieve the solution, the "passive" behavior of EP (a sort of implying in the Standard today) would not help. Additional new procedures have to be added to H.323 in the context of Robustness work. Today's Endpoints don't support these future procedures, therefore their passive behavior (or T.O.) will not solve the problem even if the other side supports the new Robustness Procedures. Why passive behavior /T.O. doesn't help: (1) When an application (such as H.323) gets a notification from TCP layer about the failure of specific TCP connection (port+IP), the connection is already closed by the TCP layer. The only way to revive Q.931 connection is to LISTEN for a NEW incoming connection, accept it and somehow (such as by callID) to logically attach the new TCP connection to the old Call. If it had been the only problem in the puzzle (which is not: see (2) below) technically it could have been defined, but it is NOT today. (This is definitely a job for our Robustness group.) Therefore NO H.323v1-3 compliant EP implements such a procedure! (2) The more difficult problem is that upon TCP channel failure, the TPKT connection above gets out of synch. It means that the application layer doesn't know automatically what part of information got lost. In this case, in order to synchronize H.323 Call state between the two sides, application level handshake must be introduced. This is also definitely a job for our Robustness group. Cheers, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com

1 0

Re: H323 mobility: Summary of discussion
by Tom-PT Taylor 05 Nov '99

05 Nov '99

I think a basic point in this discussion is that mobility is "bigger than" H.323 and already has well-established architectural underpinnings. It's all very well to talk about an H.323 solution which we could then adapt, but we would more likely end up with an H.323-only solution as a result. The concern then would be whether vendors saw sufficient opportunity in building to this market, compared with the general market for mobility products.

2 1

Re: H323 mobility: Summary of discussion
by Roy, Radhika R, ALARC 05 Nov '99

05 Nov '99

Hi, Tom and All: You might be right. That is why, we need to bring contributions that provide solutions. AT&T has proposed a solution. I think that other companies will also do the same to make the things clear from the conceptual phase to the solution phase. For example, Nortel can also bring contributions along the line that you are envisioning. In the last meeting, Intel brought an interesting proposal too. I guess that Intel might have a product similar to their proposal. That is why, we are discussing whether a separate annex may be good to address that limited scope. We also welcome that any vendors that have products solving mobility in the context of H.323 should bring contributions. Let us see the proposed solutions. It is very difficult to debate in the conceptual phase. That is, the first priority is to bring solutions on the table instead of debating each other in the conceptual phase. My personal feeling is that H.323 has not developed the backend services protocol yet. Once we understand this, we can separate the problems into two parts: 1. The protocol among the H.323 entities (e.g., Terminals, GKs, MCUs, GWs), and 2. The protocol between the H.323 entities and the backend servers. So, there are two step process in H.323 for protocol development. At present, the existing H.323 standard has defined the first protocol only (i.e., protocol among H.323 entities). I see that TD-39 (Security Support for Backend Services and Mobility in H.323) shows a very clever way to define RADIUS as the backend protocol between the GK and BES for security even for mobile users. Similarly, LDAP can also be used as the backend services protocol between the GK and the directory server. So, there are many alternatives to do that. AT&T proposal also recognizes this problem. As a result, the backend protocol between the GK and the HLF/VLF has not yet been defined. We might use any existing protocols between the GK and the HLF/VLF in a similar way what has been proposed in TD-39. Personally, I do not see a problem. By the way, what is HLF/VLF anyway? Is not the user profiles with some alias addresses and some other user defined parameters? What is special about this that we have break the fundamental architecture and protocol of H.323? Hope this email will clarify some of your concerns. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Tom-PT Taylor [SMTP:taylor@NORTELNETWORKS.COM] > Sent: Friday, November 05, 1999 11:17 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H323 mobility: Summary of discussion > > I think a basic point in this discussion is that mobility is "bigger than" > H.323 and already has well-established architectural underpinnings. It's > all very well to talk about an H.323 solution which we could then adapt, > but we would more likely end up with an H.323-only solution as a result. > The concern then would be whether vendors saw sufficient opportunity in > building to this market, compared with the general market for mobility > products. >

1 0

Re: H323 mobility: Summary of discussion
by Roy, Radhika R, ALARC 05 Nov '99

05 Nov '99

> -----Original Message----- > From: Roy, Radhika R, ALARC > Sent: Friday, November 05, 1999 9:12 AM > To: 'Mailing list for parties associated with ITU-T Study Group 16' > Subject: RE: H323 mobility: Summary of discussion > > Hi, Ed and All: > > I do not know whether you have seen my reply to Jaakko. I am enclosing it > again. Please respond to my reply provided Jaakko to prove your statement. > > I completely disagree with Ed. Please also see Marc Roelands's comments on > LA. > > AT&T contribution has shown how H.323 mobility problem can be solved using > home/foreign GK (zone). > > I like to see the complete H.323 mobility problem that has been solved > using the alternative approach as proposed by Nokia. I have NOT seen > Nokia's solution yet. Unless a complete solution is provided like AT&T's, > I am NOT convinced how mobility problem can be solved in a better way. > > I also see that there is a need for HLF/VLF. No one against the HLF/VLF > function. AT&T proposal also has shown how HLF/VLF function is taken > care-of. > > What I disagree with is this: A protocol should NOT be implementation > specific. For example, we do have a luxury to build one protocol for > distributive GK (HLF/VLF) function, one protocol for centralized GK > (HLF/VLF) function or one protocol for hybrid GK (HLF/HLF) function. It is > against the fundamental concept of H.323. For example, the same argument > can also be applied for the directory function. Similar may the case for > other functions as well. It is a complete break down of H.323 protocol and > architecture. > > So, HLF/VLF is another function in H.323. HLF/VLF is NOT a "Holy Grail" > for which we have to create a complete "DISCONTINUITY" in existing H.323 > protocol and architecture. I like see to Nokia's alternate solution to > disprove this fear. > > Nokia has to bring a complete contribution providing solution like AT&T's > to prove their case. Otherwise, we cannot proceed with a concept that has > not proved with a solution. > > The problem can be solved as follows: > > 1. Let Nokia provide a complete proposal solving the H.323 mobility > problem using heir alternative approach. What Nokia has provided is a high > level concept. They have NOT solved the problem yet. Let us see what the > complete solution is. If a solution is provided, we can then compare > Nokia's solution with that of AT&T's solution. Otherwise, their proposal > is still HYPOTHETICAL. It is a concept, NOT a solution. > > 2. How can we agree on a concept without seeing its solution that has the > potential to break down the fundamental architecture of existing H.323 > standard? > > 3. Let us solve H.323 mobility problem within the framework of H.323. > > 4. Let us move on with contributions for the part that we can agree on. If > Nokia brings a complete solution, we will definitely re-consider their > case. > > 5. I agree with you that we also need to work for interworking between > H.323 (IP) mobility and cellular-PSTN/ISDN network. > > Finally, Ed - you have made a statement, but it has to be proved providing > a solution. An alternative concept is there, but we have not seen its > solution yet. What is the problem to bring the alternate solution? Why do > we need to wait for a concept that has NOT been substantiated with a > solution yet? > > Best regards, > Radhika > > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > Sent: Thursday, November 04, 1999 9:47 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H323mobility: Summary of discussion > Importance: High > > I agreed with most of Jaakko comments and also > make vaild points, and will like to > add the following. > > I believe that the (Home) in Home Zone should be taken out. > What we are talking about is the User's Point of Attached in > any given Zone. The HLF is ready and Data base > which has the User's profile and the current user's location. > We can get a new name to HLF and call it the Location Profile > Register (LPR) or Location Profile Function (LPF). > > I also believe that the (Visited) in Visited Zone sould also > be taken out because again we are talking about > the Users current Point of Attachment in any given Zone. > The VLF has the means to update the > Location Profile Register (LPR) from > any given Zone. We can get a new name to VLF > call it the Location Update Register (LUR) or > Location Update Function (LUF). > > Now we can also support concepts of Zone ID's > such as Current Zone ID and Previous Zone ID. > > Finally, > > And I strongly agree with looking at the interworking > in parallel with H.323 mobility. The time we spent > now looking at interworking will be compensated in the > long run. I sure does working on ISUP, IN and Qsig, inetrworking > with H.323 would agree and we should learn from their experience. > And not leave it for a last minute add-on. > > Lets take the contribution as they come, if one wants to put in > interworking fine. If one wants to put in contributions only H.323 > mobility also fine. Both are in order and within our scope. > > The general strategy should focus on ensuring that the H.323 > Mobility and interworking options are enabled, rather than spending > too much effort blocking alternative options (Our limited resources > frankly don't allow this luxury). But there really is no substitute > for > doing the work - preparing input papers and presenting them > to move things forward. > > Best Regards, > > Ed > Hi, Jaakko: Pl see my reply enclosed below. Best regards, Radhika -----Original Message----- From: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] Sent: Thursday, November 04, 1999 8:48 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: H323mobility: Summary of discussion Hi, Radhika et al, It seems that I did not make all my points so clear in my last message (as I said I was pretty tired when I wrote it). Also the discussion between me and Radhika (& Ed) seems to be getting out of hand. [Roy, Radhika R] Please be happy to take your time. There is no hurry. We have a great responsibility to have the best standard that people can ever collectively think of. So, please provide your best thoughts even if you think that you should need to take rest. Thus I'll try to summarize the points in the discussion and include my views in this message. As I see it, we have been discussing about three basic issues: - The architectural placement of the HLF and VLF functionalities. The discussion also has included (or actually it started from) the question whether the terms: Home Zone and Visited Zone, with respective identifiers should be defined or not. - The two-step approach of first specifying the pure H.323 Mobility and as a second step the issues related to PLMN interworking. The discussion has been on whether (at least some of the) PLMN interworking issues should be considered while working on the pure H.323 Mobility. - The concept of the Location Area (LA). Whether we need that concept or not and if we need it, should it be considered already in the first step (see the above point). I'll address all these points below. THE PLACEMENT OF HLF/VLF AND THE HOME/VISITED ZONE DISCUSSION I think we both/all agree on one thing: The HLF and the VLF must be defined in the standard in such a way that it is possible for multiple GKs to access the same HLF/VLF. This allows for an approach in which the HLF/VLF is distributed among many GKs while simultaneously allowing the HLF/VLF to be associated with only a single GK, if this kind of a centralized design is desired. [Roy, Radhika R] I agree on your first point. To associate HLF/VLF with only a "single" GK is an implementation issue. It is NOT a protocol issue. Here we are mixing between mobility protocol vs. implementation. Let me explain. In H.323, the protocol is GK-centric. So, the mobility protocol should be developed to abide by this fundamental principle. That is, the mobility protocol characteristics should be such that it will not impose any restriction to obtain a service per GK basis. In fact, what you are asking is this: If the HLF/VLF function is associated with a "single" GK, what happens to the mobility protocol. How does the H.323 mobility protocol allow us to have this service. This is a valid question. How do we achieve this goal? Let me answer your question: We will build the protocol in such a way that will NOT restrict this particular implementation. [Roy, Radhika R] To me (as well as to others as well I guess), HLF/VLF is another function that resides behind a GK (similar to functions address and other information). I do NOT see that there is a need to develop a backend protocol between the GK and HLF/VLF right now. In the same token, H.323 has not yet defined the backend protocol between the GK and the directory server. If needed, it may be in the next stage of standardization. However, contributions may be brought to drive this work anytime. [Roy, Radhika R] In fact you might also see AT&T contributions submitted during the development of inter-domain protocol (H.225.0 Annex G). We have shown that the GK architecture can be distributive, centralized (hierarchical), and/or hybrid. Your proposal to associate HLF/VLF with a single GK will create a centralized (hierarchical) GK architectural model. However, H.323 mobility protocol should be robust enough to take care-of all GK architectural models: distributive, centralized (hierarchical), and/or hybrid. [Roy, Radhika R] I guess that I have answered your question. The thing that we disagree on is: I do NOT want to define the terms Home Zone and Visited Zone (or similar) yet. I did not seem to make that clear in my last message. The reasons why I do not want to define this kind of terms, at least yet, are as follows. [Roy, Radhika R] As it mentioned that H.323 is GK-centric. A GK control a zone. To track mobility problem, there should be a point of reference. To make point of reference that is consistent with the H.323 existing architecture, we need to use it without breaking the fundamental concept of H.323. We have to maintain the continuity of the existing H.323 architecture. If we can solve problems with the framework of existing H.323 architecture, why do we need to confuse by creating new terminolgies? I like to see a complete proposal solving all mobility problems (as AT&T and Motorola contributions) justifying the need for creation of new terminolgies as you are proposing. Nokia's contribution proposes some ideas in a high-level manner. What is needed, like AT&T and Motorola contributions, provide a complete solution first. Then, we will compare all solutions together. Otherwise, it is still hypothetical to accept you arguments. The term Home Zone leads in my mind to a definition in which every User is associated with one and only one zone as the User's "Home". I.e. the HLF containing the permanent information about the User can be accessed through the GK of the Home Zone and no other GK. Now, I do not think, Radhika, that this is what you intended, but if we talk about a Home Zone, this is the kind of thing that first comes to my mind. [Roy, Radhika R] Again, in H.323, a use has to register with a GK. It is a MUST. However, a user can also choose some alternate GKs. It is an OPTION. This is the fundamental architectural concept of H.323. We have to start solving our mobility problems based on this foundation. Home GK/Zone concept is based on this foundation to have a reference to start with in order to solve mobility problems. If we can solve H.323 mobility problems based on the basic foundation what already exists in H.323, why do need to invent new terminologies? As I mentioned earlier, like any other functions in H.323, HLF is also another function is obtained by users via the GK. Please note very carefully as I also mentioned in my earlier email: Like address information (e.g., alias, transport/network addresses, etc), HLF function is also obtained via the GK. Now to track the mobility problem, there needs to be a reference point in the context of H.323 architecture. To solve this problem, it is found that it is a better choice to associate a use with a "home" GK because a user, as H.323 requires, must register with a GK. (Please note that there can also be a backend server behind the GK to provide the HLF service. This is another level of standardization. As I explained, similar to the directory service, H.323 also does not need to define this backend protocol right now. However, contributions are welcomed in this area as well.) I currently have the idea that you meant that each User may have multiple Home Zones, is that right, Radhika? If that is the case, I do not fully understand why we would need the concept of the Home Zone at all (but maybe I'm just missing something). [Roy, Radhika R] Again, we have to look into the existing H.323 standard. What does it say? Does it not require that a use must register with a GK? However, there can also be alternate GKs. Using the same basic foundation of H.323, it is logical that a user will register with a GK. To track the mobility, it is a logical choice to have reference point. This GK is designated with a GK known as the home GK. Per existing H.323 standard, a user can also have alternate GKs as an order of priority. In the same token, a user is also free to declare alternate home GKs as an order of priority. AT&T contribution has provided a complete solution how extension of RAS messages will take care-of this problem automatically. In this context, this approach of mobility is perfectly consistent with exiting H.323 standard. The important thing in all these Home/Visited concepts is: how to identify and access the HLF of a certain User and by accessing the HLF, update all the relevant information in the HLF and in the VLFs. [Roy, Radhika R] Not necessarily. HLF/VLF is one of the functions. HLF/VLF may have user profiles in terms of personal IDs and other functions. Personal IDs are nothing but some new alias addresses. So, an extension in "H.323 alias address" will take care-of personal IDs. Similarly, other functions of user profiles can be taken care of with similar extensions. More importantly, home/foreign zone concept helps to solve H.323 mobility problems when users move from one place to another in reference to the H.323 architectural entities (e.g., zones, transport address [TCPs/UDPs: call control, media control, RAS signaling], network addresses [e.g., IP, ATM], domains, etc.). No one should underestimate what the mobility in the context of H.323 means. There are fundamental differences between the so called traditional "plain Vanilla" mobility defining in HLF/VLF in the circuit switching world and the H.323 mobility. Please see AT&T contribution how the complex H.323 mobility problem has been solved simply through extension of RAS messages and some new messages. Please all see Motorola's contribution in this context. If there are multiple Home Zones for a User, all the GKs of these zones can be used to access the HLF of the User, i.e. the HLF is identified by the Home Zone identifier (if this is not the case, what is the purpose of the Home Zone). Now, how is it determined, which GK should be Used in this case? The User must always give some "pointer" with which the HLF can be identified when the User enters a zone (or LA, if we use them). In this case the Home Zone ID would be that identifier. If always one of these Home Zones is given as the access point to the HLF, this leads to a highly centralized model with this one single zone and its GK as the central point. If, on the other hand, any of these zones can be given, how is this zone picked, randomly? Furthermore, how does a GK of a User's Home Zone know that it is in fact a "Home GK" for that User, if the User gives some other Home Zone ID than the one of the Home Zone where he is located? [Roy, Radhika R] Please see my above answer how this complex mobility problems are solved very beautifully in terms of primary GK and alternate GKs in the context of existing H.323 standards. We do NOT need to invent any new terminologies (e.g., location area [LA] or others). Please see AT&T contribution how the complete solution has been provided right within the context of existing H.323 standard. In this context, Motorola's contribution can also been seen. All the above reasons, in my opinion, lead to the fact that the HLF must be identified with an identifier that is NOT related to any single zone or GK. This is why I proposed the concept of Home Domain (I use the concept of an Administrative Domain because, as Radhika mentioned, it is already defined in H.323) in my contribution to the Red Bank meeting (APC-1659). In this case the Home Domain would identify the HLF of a User and thus the GKs in the Home Domain could identify that they are in fact a part of the Home Domain and the HLF to which they have access, is the HLF of the User. If the User would be located in some other (Visited) Domain, his HLF could be identified by the Home Domain (thus this model would be BE centric. The Administrative Domain is, of course, not the only alternative to group the zones, which form the "Home" of a User together, I just used it, because it is already defined. We could also define a HLF Identifier which is not related to a Domain, but the GKs of the zones forming the User's "Home" would recognize if the HLF to which they have access is the correct HLF based on this identifier. [Roy, Radhika R] Both AT&T and Motorola's contributions provide solutions without inventing new terminologies. If needed, as pointed out earlier, we like to see a complete contribution from Nokia that solves all mobility problems using the new terminologies as it is done in AT&T and Motorola's contribution. Otherwise, it is still a very high-level concept such as home/foreign domains. My fear is that it may break the fundamental architectural concept of the existing H.323 standard. So, far I have NOT seen any reason to believe why the solution provided by AT&T complementing the existing H.323 architecture should be modified. I also see that Motorola's contribution is also providing the mobility solution within the framework of existing H.323 architecture. Before, we deviate from the fundamental concept of H.323 architecture, we like to see a complete contribution from Nokia similar to AT&T's. Only then, we will be able to see the merit of Nokia's proposed architectural concept. THE TWO-STEP APPROACH DISCUSSION The two-step approach, as I understand it, means that we will first work on a pure end-to-end H.323 Mobility solution and after that has been done we will define the interworking with legacy (and future) mobile networks. Although I do agree that in general this is a good order to do these two things, I would like to see some general interworking aspects taken into consideration in the first phase. One example of these may be the Location Area concept. I do not want to go into details of the interworking issues in the first step, but I'm afraid that if we do not think about the interworking at all in the first step, we will end up defining some functionalities in two different ways, one being the result of the first step and the other an addition to this as the result of the second step when the solution of the first step is not capable of handling some general interworking procedure, for example. I hope, I made my point clear despite the above text being somewhat rambling... THE LOCATION AREA DISCUSSION This is actually an example of the problem I have with the "strict" two-step approach. Radhika is proposing that we try to solve the mobility in the first step without the LA concept. I think it would be very beneficial, if we at least consider it already in the first step. Furthermore, I am quite sure we will need the concept in the second step, or else we will end up with a very badly scalable system. As I said in my earlier message, the LA concept will help to make the H.323 mobile systems more easily scalable, the price for this is, of course, the increased complexity that the LAs bring to the system. To express shortly, what a LA is for: it is a grouping of NPoAs that are geographically located close to each other. A zone also consists of NPoAs, but these NPoAs can actually be geographically far from each other. In other words, a zone is a set of NPoAs that are grouped together for administrative purposes, not because they are close to each other (which they need not be). When we are dealing with wireless mobile terminals, this grouping based on the geographical location becomes important and thus my opinion is that we should consider the LA concept already in the first phase. [Roy, Radhika R] The network point of attachment has been taken care-of. As I told before, a complete contribution has to be provided how LA concept will be useful to solve the mobility problem. AT&T has provided a complete solution providing architecture, signaling messages, call control, mobility management, and ASN.1 of RAS signaling messages. The contribution has shown how mobility problem is solved in the context of existing H.323 architectural concept. Nokia has to do the same to understand the merit that H.323 mobility problem cannot be solved as it is shown AT&T's contribution without using LA, home/foreign domain concepts as proposed by Nokia. Motorola's contribution can also be seen for this purpose. - Jaakko Sundquist ------------------------------------------------------- In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole, and that means comfort. ------------------------------------------------------- > > [Roy, Radhika R] Hi, Jaakko: > > Pl. see my reply provided below. > > Best regards, > Radhika > > -----Original Message----- > From: jaakko.sundquist(a)NOKIA.COM [SMTP:jaakko.sundquist@NOKIA.COM] > Sent: Tuesday, November 02, 1999 11:13 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H323mobility: meeting > > Once again, hi, Radhika, Ed + all > > See my comments below... > > Hi, Jaakko, Ed, and All: > > I hope that Jaakko will get this mail while he is in > his > office (Thanks > Jaakko - you have reminded us the time difference)! > > [Jaakko:] You caught me just in time. > > > Please note the following: > > 1. Zone and domain are well defined in H.323. > [Jaakko:] Yes, they are defined. > > 2. We have to work for mobility solution in a way > that fits > very well that > already exists in H.323. > > [Jaakko:] Agreed. > > 3. We can invent many things if we need to solve > mobility > problems only when > we think that those functions are NOT covered in > existing > H.323 standard. > > [Jaakko:] Yes. > > 4. If mobility problems can be solved using the > concept of > "zones" and > "domains," I would assume that it would be a big > mile stone > so far the > continuity of H.323 is concerned. That is, as Ed > pointed > out, H.323 mobility > problem is NOT a rocket science. We have to remember > that we > are working in > the framework of already existing H.323 standard > architecture. We have to > relate our solution in the context of existing H.323 > standard. In other > words, we CANNOT change the fundamental concept of > existing > H.323 standards > just because we are addressing mobility. > > [Jaakko:] Yes, of course. I'm not arguing against > that. I > guess you are referring to the Location Area discussion here. The LA > concept > is really merely a scaling issue, you could of course handle paging > (I'm > assuming that we will need the paging procedure) based on zones, > i.e. page > every NPoA in a zone when a call arrives, but this might be quite > limiting > in some cases (the zone may be needlessly big or very small). I do > not think > that we need to change any fundamental concepts of H.323, if we > introduce > the LA concept. > [Roy, Radhika R] May be we can include LA when we see that we need > to optimize a zone further. We may revisit this in the second step. > > 5. I do not understand what benefits we are gaining > adding > more > "terminologies" like "AREA {home, foreign, etc}" > while the > "zone" and > "domain" are already well defined in H.323. My > personal view > is that we > should FIRST try to solve H.323 mobility problems > within the > context of > "zone" and "domain" as far as practicable. I would > argue > that zone and > domain are good enough to serve this purpose for > now. (Pl. > also see AT&T's > and Motorola's contributions.) > > [Jaakko:] As I already said, I did not intent to > define the > terms: home area and visited area. I was just trying to illustrate > the point > I was making about not having the Home/visited zone terms defined > yet. > [Roy, Radhika R] It is good point. Let us define these. AT&T > contributions have the detail definition for each term. > > 6. With respect to your comments that it appears > that every > GK will have HLF > and VLF function, I would say that every GK will > have the > access to the HLF > and VLF function. This capability for each GK has to > be > provided because of > the fact that H.323 architecture is GK-centric. We > do not > have any choice > because we are restricted by the H.323 architecture. > > [Jaakko:] I did not argue against this. The point is > that if > we identify a concept called the Home Zone, this already implies > that each > User has only one zone, in which he/she/it is not a "visiting user". > I think > this would be really restricting. > [Roy, Radhika R] As I mentioned that H.323 is the GK-centric. A > user may change his/her network point of point attachment, but it is still > the same (Home) GK. So, a given (home) GK, there has to be another level > of granularity to address mobility in terms of network point of > attachment. Please see AT&T contribution how home and foreign network > concept have solved the problem. Similar is the case with Motorola's > contribution. The bottom line is that home/foreign GK concept does NOT > imply any restriction to solve H.323 mobility. > > 6.1 With respect to your question whether HLF/VLF > can be > distributive or > centralized, having said (in item 5) that every GK > should > have access to HLF > and VLF function, it is up to implementation whether > HLF and > VLF function > can be centralized or distributive. Please see AT&T > contributions submitted > in Red Bank how we can implement these functions in > both > distributive and > centralized environment. > > [Jaakko:] This is actually quite much the point I > was > making. By defining the Home Zone we would in my mind actually be > pointing > to the centralized model. > [Roy, Radhika R] By definition, there can as many GKs as one wish > have in an H.323 system. So, by definition, the GK-centric H.323 > architecture is distributive. By defining home/foreign GK, H.323 mobility > also becomes distributive up to the point that a basic H.323 system allows > us. So, we do not see any limitations. > > 6.2 In an analogy of this HLF/VLF function, I can > bring > another function - > Directory services. For example, H.323 assumes that > all the > address (e.g., > alias, transport, network) are kept by each GK. > H.323 does > not answer how > the address information is maintained by each GK. > People are > using LDAP > directory server. The question is: whether that > directory > service is > distributive or centralized? I guess that it can be > done in > both ways > depending on implementation. > > [Jaakko:] My point exactly. I would like that all > GKs inside > the same Administrative Domain would be able to access the same > HLF/VLF > functionality. > [Roy, Radhika R] As I pointed out, this an implementation issue. I > would argue that we should allow both options and let an implementor > choose as it is necessary. Please also see AT&T contributions how both > options can be addressed. > > 6.3 In AT&T contribution, it is shown that it better > to make > VLF > distributive (per GK) although HLF function can be > made both > distributive > and centralized. Again, this is a matter of > implementation. > As mentioned in > AT&T contribution, we also need to define a kind of > backend > protocol for VLF > and HLF (something like similar to Siemens, Nokia > and > Intel's contribution - > TD-39: Security Services for Backend Services and > Mobility > in H.323). > > [Jaakko:] I would assume that you can distribute the > HLF/VLF > functionalities inside the Administrative Domain as you like, but > distributing them between the Domains would be difficult. Actually I > think > that the concept of Administrative Domain was introduced in H.323 > for this > kind of reasons. > [Roy, Radhika R] Again, H.323 system is GK-centric in a given > domain. For inter-domain, it is BE-centric. In a given domain, H.323 > architecture has to be GK-centric. Once we solve intra-zone and inter-zone > (intra-domain) mobility, we can extend our experience for inter-domain > problem as well. Please also see AT&T contribution how these problems have > been addressed. My replies to 6.1 and 6.2 are also good for this case. > > 7. Again, I, personally, do not rule our to > re-examine the > benfit of "AREA" > (e.g. location area [LA]) vs. "ZONE/DOMAIN" concept. > May be > it is in the > second step. > > [Jaakko:] I am just a bit afraid that if we leave > this kind > of a major mobility related concept out of the first phase thinking > process, > we will find it much more difficult to include the concept in the > second > phase (where I think we will need it). Furthermore, I'm not > convinced that > the LA concept would not be useful in the pure H.323 approach > either. > [Roy, Radhika R] I think that it can be place holder for now. I > would request to bring more detail contributions proposing solutions like > AT&T and Motorola to prove the case better. Then, we can compare both > solutions. In AT&T contribution, I feel that the LA can be accommodated to > optimize the zone further. So, I do not see that it is a problem to > accommodate the LA concept if needed. I personally prefer that we can > better address this in the second phase once we solve the problem for the > basic architecture. > > Hope that this email will clarify the things better. > > [Jaakko:] I think the main thing is that we got the > discussion going on again. I'm kind of tired already, and I hope > that I > didn't mess things up too much in this mail. > [Roy, Radhika R] Definitely, I also like that discussions must go > on. We must be convinced that we have the best solution because it has the > severe implications for all on-going mobility standard works throughout > the world once we standardize H.323 mobility in SG16. > > Best regards, > Radhika > > Same to you, > Jaakko > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: H323 mobility: Summary of discussion
by Roy, Radhika R, ALARC 05 Nov '99

05 Nov '99

Hi, Ed and All: I do not know whether you have seen my reply to Jaakko. I am enclosing it again. Please respond to my reply to provided Jaakko to prove your statement. I completely disagree with Ed. Please also see Marc Roelands's comments on LA. AT&T contribution has shown how H.323 mobility problem can be solved using home/foreign GK (zone). I like to see the complete H.323 mobility problem that has been solved using the alternative approach as proposed by Nokia. I have NOT seen Nokia's solution yet. Unless a complete solution is provided like AT&T's, I am NOT convinced how mobility problem can be solved in a better way. I also see that there is a need for HLF/VLF. No one against the HLF/VLF function. AT&T proposal also has shown how HLF/VLF function is taken care-of. What I disagree with is this: A protocol should NOT be implementation specific. For example, we do have a luxury to build one protocol for distributive GK (HLF/VLF) function, one protocol for centralized GK (HLF/VLF) function or one protocol for hybrid GK (HLF/HLF) function. It is against the fundamental concept of H.323. For example, the same argument can also be applied for the directory function. Similar may the case for other functions as well. It is a complete break down of H.323 protocol and architecture. So, HLF/VLF is another function in H.323. HLF/VLF is NOT a "Holy Grail" for which we have to create a complete "DISCONTINUITY" in existing H.323 protocol and architecture. I like see to Nokia's alternate solution to disprove this fear. Nokia has to bring a complete contribution providing solution like AT&T's to prove their case. Otherwise, we cannot proceed with a concept that has not proved with a solution. The problem can be solved as follows: 1. Let Nokia provide a complete proposal solving the H.323 mobility problem using heir alternative approach. What Nokia has provided is a high level concept. They have NOT solved the problem yet. Let us see what the complete solution is. If a solution is provided, we can then compare Nokia's solution with that of AT&T's solution. Otherwise, their proposal is still HYPOTHETICAL. It is a concept, NOT a solution. 2. How can we agree on a concept without seeing its solution that has the potential to break down the fundamental architecture of existing H.323 standard? 3. Let us solve H.323 mobility problem within the framework of H.323. 4. Let us move on with contributions for the part that we can agree on. If Nokia brings a complete solution, we will definitely re-consider their case. 5. I agree with you that we also need to work for interworking between H.323 (IP) mobility and cellular-PSTN/ISDN network. Finally, Ed - you have made a statement, but it has to be proved providing a solution. An alternative concept is there, but we have not seen its solution yet. What is the problem to bring the alternate solution? Why do we need to wait for a concept that has NOT been substantiated with a solution yet? Best regards, Radhika > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > Sent: Thursday, November 04, 1999 9:47 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H323mobility: Summary of discussion > Importance: High > > I agreed with most of Jaakko comments and also > make vaild points, and will like to > add the following. > > I believe that the (Home) in Home Zone should be taken out. > What we are talking about is the User's Point of Attached in > any given Zone. The HLF is ready and Data base > which has the User's profile and the current user's location. > We can get a new name to HLF and call it the Location Profile > Register (LPR) or Location Profile Function (LPF). > > I also believe that the (Visited) in Visited Zone sould also > be taken out because again we are talking about > the Users current Point of Attachment in any given Zone. > The VLF has the means to update the > Location Profile Register (LPR) from > any given Zone. We can get a new name to VLF > call it the Location Update Register (LUR) or > Location Update Function (LUF). > > Now we can also support concepts of Zone ID's > such as Current Zone ID and Previous Zone ID. > > Finally, > > And I strongly agree with looking at the interworking > in parallel with H.323 mobility. The time we spent > now looking at interworking will be compensated in the > long run. I sure does working on ISUP, IN and Qsig, inetrworking > with H.323 would agree and we should learn from their experience. > And not leave it for a last minute add-on. > > Lets take the contribution as they come, if one wants to put in > interworking fine. If one wants to put in contributions only H.323 > mobility also fine. Both are in order and within our scope. > > The general strategy should focus on ensuring that the H.323 > Mobility and interworking options are enabled, rather than spending > too much effort blocking alternative options (Our limited resources > frankly don't allow this luxury). But there really is no substitute for > doing the work - preparing input papers and presenting them > to move things forward. > > Best Regards, > > Ed [Roy, Radhika R] Hi, Jaakko: Pl. see my reply provided below. Best regards, Radhika -----Original Message----- From: jaakko.sundquist(a)NOKIA.COM [SMTP:jaakko.sundquist@NOKIA.COM] Sent: Tuesday, November 02, 1999 11:13 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H323mobility: meeting Once again, hi, Radhika, Ed + all See my comments below... Hi, Jaakko, Ed, and All: I hope that Jaakko will get this mail while he is in his office (Thanks Jaakko - you have reminded us the time difference)! [Jaakko:] You caught me just in time. Please note the following: 1. Zone and domain are well defined in H.323. [Jaakko:] Yes, they are defined. 2. We have to work for mobility solution in a way that fits very well that already exists in H.323. [Jaakko:] Agreed. 3. We can invent many things if we need to solve mobility problems only when we think that those functions are NOT covered in existing H.323 standard. [Jaakko:] Yes. 4. If mobility problems can be solved using the concept of "zones" and "domains," I would assume that it would be a big mile stone so far the continuity of H.323 is concerned. That is, as Ed pointed out, H.323 mobility problem is NOT a rocket science. We have to remember that we are working in the framework of already existing H.323 standard architecture. We have to relate our solution in the context of existing H.323 standard. In other words, we CANNOT change the fundamental concept of existing H.323 standards just because we are addressing mobility. [Jaakko:] Yes, of course. I'm not arguing against that. I guess you are referring to the Location Area discussion here. The LA concept is really merely a scaling issue, you could of course handle paging (I'm assuming that we will need the paging procedure) based on zones, i.e. page every NPoA in a zone when a call arrives, but this might be quite limiting in some cases (the zone may be needlessly big or very small). I do not think that we need to change any fundamental concepts of H.323, if we introduce the LA concept. [Roy, Radhika R] May be we can include LA when we see that we need to optimize a zone further. We may revisit this in the second step. 5. I do not understand what benefits we are gaining adding more "terminologies" like "AREA {home, foreign, etc}" while the "zone" and "domain" are already well defined in H.323. My personal view is that we should FIRST try to solve H.323 mobility problems within the context of "zone" and "domain" as far as practicable. I would argue that zone and domain are good enough to serve this purpose for now. (Pl. also see AT&T's and Motorola's contributions.) [Jaakko:] As I already said, I did not intent to define the terms: home area and visited area. I was just trying to illustrate the point I was making about not having the Home/visited zone terms defined yet. [Roy, Radhika R] It is good point. Let us define these. AT&T contributions have the detail definition for each term. 6. With respect to your comments that it appears that every GK will have HLF and VLF function, I would say that every GK will have the access to the HLF and VLF function. This capability for each GK has to be provided because of the fact that H.323 architecture is GK-centric. We do not have any choice because we are restricted by the H.323 architecture. [Jaakko:] I did not argue against this. The point is that if we identify a concept called the Home Zone, this already implies that each User has only one zone, in which he/she/it is not a "visiting user". I think this would be really restricting. [Roy, Radhika R] As I mentioned that H.323 is the GK-centric. A user may change his/her network point of point attachment, but it is still the same (Home) GK. So, a given (home) GK, there has to be another level of granularity to address mobility in terms of network point of attachment. Please see AT&T contribution how home and foreign network concept have solved the problem. Similar is the case with Motorola's contribution. The bottom line is that home/foreign GK concept does NOT imply any restriction to solve H.323 mobility. 6.1 With respect to your question whether HLF/VLF can be distributive or centralized, having said (in item 5) that every GK should have access to HLF and VLF function, it is up to implementation whether HLF and VLF function can be centralized or distributive. Please see AT&T contributions submitted in Red Bank how we can implement these functions in both distributive and centralized environment. [Jaakko:] This is actually quite much the point I was making. By defining the Home Zone we would in my mind actually be pointing to the centralized model. [Roy, Radhika R] By definition, there can as many GKs as one wish have in an H.323 system. So, by definition, the GK-centric H.323 architecture is distributive. By defining home/foreign GK, H.323 mobility also becomes distributive up to the point that a basic H.323 system allows us. So, we do not see any limitations. 6.2 In an analogy of this HLF/VLF function, I can bring another function - Directory services. For example, H.323 assumes that all the address (e.g., alias, transport, network) are kept by each GK. H.323 does not answer how the address information is maintained by each GK. People are using LDAP directory server. The question is: whether that directory service is distributive or centralized? I guess that it can be done in both ways depending on implementation. [Jaakko:] My point exactly. I would like that all GKs inside the same Administrative Domain would be able to access the same HLF/VLF functionality. [Roy, Radhika R] As I pointed out, this an implementation issue. I would argue that we should allow both options and let an implementor choose as it is necessary. Please also see AT&T contributions how both options can be addressed. 6.3 In AT&T contribution, it is shown that it better to make VLF distributive (per GK) although HLF function can be made both distributive and centralized. Again, this is a matter of implementation. As mentioned in AT&T contribution, we also need to define a kind of backend protocol for VLF and HLF (something like similar to Siemens, Nokia and Intel's contribution - TD-39: Security Services for Backend Services and Mobility in H.323). [Jaakko:] I would assume that you can distribute the HLF/VLF functionalities inside the Administrative Domain as you like, but distributing them between the Domains would be difficult. Actually I think that the concept of Administrative Domain was introduced in H.323 for this kind of reasons. [Roy, Radhika R] Again, H.323 system is GK-centric in a given domain. For inter-domain, it is BE-centric. In a given domain, H.323 architecture has to be GK-centric. Once we solve intra-zone and inter-zone (intra-domain) mobility, we can extend our experience for inter-domain problem as well. Please also see AT&T contribution how these problems have been addressed. My replies to 6.1 and 6.2 are also good for this case. 7. Again, I, personally, do not rule our to re-examine the benfit of "AREA" (e.g. location area [LA]) vs. "ZONE/DOMAIN" concept. May be it is in the second step. [Jaakko:] I am just a bit afraid that if we leave this kind of a major mobility related concept out of the first phase thinking process, we will find it much more difficult to include the concept in the second phase (where I think we will need it). Furthermore, I'm not convinced that the LA concept would not be useful in the pure H.323 approach either. [Roy, Radhika R] I think that it can be place holder for now. I would request to bring more detail contributions proposing solutions like AT&T and Motorola to prove the case better. Then, we can compare both solutions. In AT&T contribution, I feel that the LA can be accommodated to optimize the zone further. So, I do not see that it is a problem to accommodate the LA concept if needed. I personally prefer that we can better address this in the second phase once we solve the problem for the basic architecture. Hope that this email will clarify the things better. [Jaakko:] I think the main thing is that we got the discussion going on again. I'm kind of tired already, and I hope that I didn't mess things up too much in this mail. [Roy, Radhika R] Definitely, I also like that discussions must go on. We must be convinced that we have the best solution because it has the severe implications for all on-going mobility standard works throughout the world once we standardize H.323 mobility in SG16. Best regards, Radhika Same to you, Jaakko > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: H323mobility: Summary of discussion
by Roy, Radhika R, ALARC 05 Nov '99

05 Nov '99

Hi, Marc: You are right. Best regards, Radhika > -----Original Message----- > From: Roelands Marc [SMTP:Marc.Roelands@SIEMENS.ATEA.BE] > Sent: Friday, November 05, 1999 5:36 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H323mobility: Summary of discussion > > Hi Jaakko, > > Just a small remark on your location area argumentation: > "what a LA is for: it is a grouping of NPoAs that are geographically > located > close to each other" assumes that NPoAs are restricted to a single > geographical point of attachment, which, as I understood it, was not the > definition we aggreed on. The NPoA in practice will be the IP address, > which cannot a priori be restricted to a single geographical area > (remember > the Mobile IP discussion...). > > Regards, > Marc > > -----Original Message----- > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > Sent: Thursday, November 04, 1999 14:48 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H323mobility: Summary of discussion > > > Hi, Radhika et al, > > It seems that I did not make all my points so clear in my last message (as > I > said I was pretty tired when I wrote it). Also the discussion between me > and > Radhika (& Ed) seems to be getting out of hand. Thus I'll try to summarize > the points in the discussion and include my views in this message. > > As I see it, we have been discussing about three basic issues: > - The architectural placement of the HLF and VLF functionalities. The > discussion also has included (or actually it started from) the question > whether the terms: Home Zone and Visited Zone, with respective identifiers > should be defined or not. > - The two-step approach of first specifying the pure H.323 Mobility and as > a > second step the issues related to PLMN interworking. The discussion has > been > on whether (at least some of the) PLMN interworking issues should be > considered while working on the pure H.323 Mobility. > - The concept of the Location Area (LA). Whether we need that concept or > not > and if we need it, should it be considered already in the first step (see > the above point). > > I'll address all these points below. > > THE PLACEMENT OF HLF/VLF AND THE HOME/VISITED ZONE DISCUSSION > > I think we both/all agree on one thing: > The HLF and the VLF must be defined in the standard in such a way that it > is > possible for multiple GKs to access the same HLF/VLF. This allows for an > approach in which the HLF/VLF is distributed among many GKs while > simultaneously allowing the HLF/VLF to be associated with only a single > GK, > if this kind of a centralized design is desired. > > The thing that we disagree on is: I do NOT want to define the terms Home > Zone and Visited Zone (or similar) yet. I did not seem to make that clear > in > my last message. The reasons why I do not want to define this kind of > terms, > at least yet, are as follows. > > The term Home Zone leads in my mind to a definition in which every User is > associated with one and only one zone as the User's "Home". I.e. the HLF > containing the permanent information about the User can be accessed > through > the GK of the Home Zone and no other GK. Now, I do not think, Radhika, > that > this is what you intended, but if we talk about a Home Zone, this is the > kind of thing that first comes to my mind. > I currently have the idea that you meant that each User may have multiple > Home Zones, is that right, Radhika? If that is the case, I do not fully > understand why we would need the concept of the Home Zone at all (but > maybe > I'm just missing something). > The important thing in all these Home/Visited concepts is: how to identify > and access the HLF of a certain User and by accessing the HLF, update all > the relevant information in the HLF and in the VLFs. If there are multiple > Home Zones for a User, all the GKs of these zones can be used to access > the > HLF of the User, i.e. the HLF is identified by the Home Zone identifier > (if > this is not the case, what is the purpose of the Home Zone). Now, how is > it > determined, which GK should be Used in this case? The User must always > give > some "pointer" with which the HLF can be identified when the User enters a > zone (or LA, if we use them). In this case the Home Zone ID would be that > identifier. If always one of these Home Zones is given as the access point > to the HLF, this leads to a highly centralized model with this one single > zone and its GK as the central point. If, on the other hand, any of these > zones can be given, how is this zone picked, randomly? Furthermore, how > does > a GK of a User's Home Zone know that it is in fact a "Home GK" for that > User, if the User gives some other Home Zone ID than the one of the Home > Zone where he is located? > All the above reasons, in my opinion, lead to the fact that the HLF must > be > identified with an identifier that is NOT related to any single zone or > GK. > This is why I proposed the concept of Home Domain (I use the concept of an > Administrative Domain because, as Radhika mentioned, it is already defined > in H.323) in my contribution to the Red Bank meeting (APC-1659). In this > case the Home Domain would identify the HLF of a User and thus the GKs in > the Home Domain could identify that they are in fact a part of the Home > Domain and the HLF to which they have access, is the HLF of the User. If > the > User would be located in some other (Visited) Domain, his HLF could be > identified by the Home Domain (thus this model would be BE centric. > The Administrative Domain is, of course, not the only alternative to group > the zones, which form the "Home" of a User together, I just used it, > because > it is already defined. We could also define a HLF Identifier which is not > related to a Domain, but the GKs of the zones forming the User's "Home" > would recognize if the HLF to which they have access is the correct HLF > based on this identifier. > > THE TWO-STEP APPROACH DISCUSSION > > The two-step approach, as I understand it, means that we will first work > on > a pure end-to-end H.323 Mobility solution and after that has been done we > will define the interworking with legacy (and future) mobile networks. > Although I do agree that in general this is a good order to do these two > things, I would like to see some general interworking aspects taken into > consideration in the first phase. One example of these may be the Location > Area concept. I do not want to go into details of the interworking issues > in > the first step, but I'm afraid that if we do not think about the > interworking at all in the first step, we will end up defining some > functionalities in two different ways, one being the result of the first > step and the other an addition to this as the result of the second step > when > the solution of the first step is not capable of handling some general > interworking procedure, for example. > > I hope, I made my point clear despite the above text being somewhat > rambling... > > THE LOCATION AREA DISCUSSION > > This is actually an example of the problem I have with the "strict" > two-step > approach. Radhika is proposing that we try to solve the mobility in the > first step without the LA concept. I think it would be very beneficial, if > we at least consider it already in the first step. Furthermore, I am quite > sure we will need the concept in the second step, or else we will end up > with a very badly scalable system. > As I said in my earlier message, the LA concept will help to make the > H.323 > mobile systems more easily scalable, the price for this is, of course, the > increased complexity that the LAs bring to the system. To express shortly, > what a LA is for: it is a grouping of NPoAs that are geographically > located > close to each other. A zone also consists of NPoAs, but these NPoAs can > actually be geographically far from each other. In other words, a zone is > a > set of NPoAs that are grouped together for administrative purposes, not > because they are close to each other (which they need not be). When we are > dealing with wireless mobile terminals, this grouping based on the > geographical location becomes important and thus my opinion is that we > should consider the LA concept already in the first phase. > > - Jaakko Sundquist > ------------------------------------------------------- > In a hole in the ground there lived a hobbit. > Not a nasty, dirty, wet hole, filled with the ends of > worms and an oozy smell, nor yet a dry, bare, > sandy hole with nothing in it to sit down on or to eat: > it was a hobbit-hole, and that means comfort. > -------------------------------------------------------

1 0

Re: H323mobility: Summary of discussion
by sgkim 05 Nov '99

05 Nov '99

안녕하세요. 김상길입니다. 수정할 내용은 없습니다. '구룹' -> '그룹'으로 변경하였습니다. 감사합니다. -----원본 메시지----- 보낸 사람: Roelands Marc <Marc.Roelands(a)SIEMENS.ATEA.BE> 받는 사람: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com> 날짜: 1999년 11월 5일 금요일 오후 7:48 제목: Re: H323mobility: Summary of discussion >Hi Jaakko, > >Just a small remark on your location area argumentation: >"what a LA is for: it is a grouping of NPoAs that are geographically located >close to each other" assumes that NPoAs are restricted to a single >geographical point of attachment, which, as I understood it, was not the >definition we aggreed on. The NPoA in practice will be the IP address, >which cannot a priori be restricted to a single geographical area (remember >the Mobile IP discussion...). > >Regards, >Marc > >-----Original Message----- >From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] >Sent: Thursday, November 04, 1999 14:48 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: H323mobility: Summary of discussion > > >Hi, Radhika et al, > >It seems that I did not make all my points so clear in my last message (as I >said I was pretty tired when I wrote it). Also the discussion between me and >Radhika (& Ed) seems to be getting out of hand. Thus I'll try to summarize >the points in the discussion and include my views in this message. > >As I see it, we have been discussing about three basic issues: >- The architectural placement of the HLF and VLF functionalities. The >discussion also has included (or actually it started from) the question >whether the terms: Home Zone and Visited Zone, with respective identifiers >should be defined or not. >- The two-step approach of first specifying the pure H.323 Mobility and as a >second step the issues related to PLMN interworking. The discussion has been >on whether (at least some of the) PLMN interworking issues should be >considered while working on the pure H.323 Mobility. >- The concept of the Location Area (LA). Whether we need that concept or not >and if we need it, should it be considered already in the first step (see >the above point). > >I'll address all these points below. > >THE PLACEMENT OF HLF/VLF AND THE HOME/VISITED ZONE DISCUSSION > >I think we both/all agree on one thing: >The HLF and the VLF must be defined in the standard in such a way that it is >possible for multiple GKs to access the same HLF/VLF. This allows for an >approach in which the HLF/VLF is distributed among many GKs while >simultaneously allowing the HLF/VLF to be associated with only a single GK, >if this kind of a centralized design is desired. > >The thing that we disagree on is: I do NOT want to define the terms Home >Zone and Visited Zone (or similar) yet. I did not seem to make that clear in >my last message. The reasons why I do not want to define this kind of terms, >at least yet, are as follows. > >The term Home Zone leads in my mind to a definition in which every User is >associated with one and only one zone as the User's "Home". I.e. the HLF >containing the permanent information about the User can be accessed through >the GK of the Home Zone and no other GK. Now, I do not think, Radhika, that >this is what you intended, but if we talk about a Home Zone, this is the >kind of thing that first comes to my mind. >I currently have the idea that you meant that each User may have multiple >Home Zones, is that right, Radhika? If that is the case, I do not fully >understand why we would need the concept of the Home Zone at all (but maybe >I'm just missing something). >The important thing in all these Home/Visited concepts is: how to identify >and access the HLF of a certain User and by accessing the HLF, update all >the relevant information in the HLF and in the VLFs. If there are multiple >Home Zones for a User, all the GKs of these zones can be used to access the >HLF of the User, i.e. the HLF is identified by the Home Zone identifier (if >this is not the case, what is the purpose of the Home Zone). Now, how is it >determined, which GK should be Used in this case? The User must always give >some "pointer" with which the HLF can be identified when the User enters a >zone (or LA, if we use them). In this case the Home Zone ID would be that >identifier. If always one of these Home Zones is given as the access point >to the HLF, this leads to a highly centralized model with this one single >zone and its GK as the central point. If, on the other hand, any of these >zones can be given, how is this zone picked, randomly? Furthermore, how does >a GK of a User's Home Zone know that it is in fact a "Home GK" for that >User, if the User gives some other Home Zone ID than the one of the Home >Zone where he is located? >All the above reasons, in my opinion, lead to the fact that the HLF must be >identified with an identifier that is NOT related to any single zone or GK. >This is why I proposed the concept of Home Domain (I use the concept of an >Administrative Domain because, as Radhika mentioned, it is already defined >in H.323) in my contribution to the Red Bank meeting (APC-1659). In this >case the Home Domain would identify the HLF of a User and thus the GKs in >the Home Domain could identify that they are in fact a part of the Home >Domain and the HLF to which they have access, is the HLF of the User. If the >User would be located in some other (Visited) Domain, his HLF could be >identified by the Home Domain (thus this model would be BE centric. >The Administrative Domain is, of course, not the only alternative to group >the zones, which form the "Home" of a User together, I just used it, because >it is already defined. We could also define a HLF Identifier which is not >related to a Domain, but the GKs of the zones forming the User's "Home" >would recognize if the HLF to which they have access is the correct HLF >based on this identifier. > >THE TWO-STEP APPROACH DISCUSSION > >The two-step approach, as I understand it, means that we will first work on >a pure end-to-end H.323 Mobility solution and after that has been done we >will define the interworking with legacy (and future) mobile networks. >Although I do agree that in general this is a good order to do these two >things, I would like to see some general interworking aspects taken into >consideration in the first phase. One example of these may be the Location >Area concept. I do not want to go into details of the interworking issues in >the first step, but I'm afraid that if we do not think about the >interworking at all in the first step, we will end up defining some >functionalities in two different ways, one being the result of the first >step and the other an addition to this as the result of the second step when >the solution of the first step is not capable of handling some general >interworking procedure, for example. > >I hope, I made my point clear despite the above text being somewhat >rambling... > >THE LOCATION AREA DISCUSSION > >This is actually an example of the problem I have with the "strict" two-step >approach. Radhika is proposing that we try to solve the mobility in the >first step without the LA concept. I think it would be very beneficial, if >we at least consider it already in the first step. Furthermore, I am quite >sure we will need the concept in the second step, or else we will end up >with a very badly scalable system. >As I said in my earlier message, the LA concept will help to make the H.323 >mobile systems more easily scalable, the price for this is, of course, the >increased complexity that the LAs bring to the system. To express shortly, >what a LA is for: it is a grouping of NPoAs that are geographically located >close to each other. A zone also consists of NPoAs, but these NPoAs can >actually be geographically far from each other. In other words, a zone is a >set of NPoAs that are grouped together for administrative purposes, not >because they are close to each other (which they need not be). When we are >dealing with wireless mobile terminals, this grouping based on the >geographical location becomes important and thus my opinion is that we >should consider the LA concept already in the first phase. > >- Jaakko Sundquist >------------------------------------------------------- > In a hole in the ground there lived a hobbit. > Not a nasty, dirty, wet hole, filled with the ends of > worms and an oozy smell, nor yet a dry, bare, >sandy hole with nothing in it to sit down on or to eat: > it was a hobbit-hole, and that means comfort. >------------------------------------------------------- >

1 0

Re: H323mobility: Summary of discussion
by Roelands Marc 05 Nov '99

05 Nov '99

Hi Jaakko, Just a small remark on your location area argumentation: "what a LA is for: it is a grouping of NPoAs that are geographically located close to each other" assumes that NPoAs are restricted to a single geographical point of attachment, which, as I understood it, was not the definition we aggreed on. The NPoA in practice will be the IP address, which cannot a priori be restricted to a single geographical area (remember the Mobile IP discussion...). Regards, Marc -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: Thursday, November 04, 1999 14:48 To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: H323mobility: Summary of discussion Hi, Radhika et al, It seems that I did not make all my points so clear in my last message (as I said I was pretty tired when I wrote it). Also the discussion between me and Radhika (& Ed) seems to be getting out of hand. Thus I'll try to summarize the points in the discussion and include my views in this message. As I see it, we have been discussing about three basic issues: - The architectural placement of the HLF and VLF functionalities. The discussion also has included (or actually it started from) the question whether the terms: Home Zone and Visited Zone, with respective identifiers should be defined or not. - The two-step approach of first specifying the pure H.323 Mobility and as a second step the issues related to PLMN interworking. The discussion has been on whether (at least some of the) PLMN interworking issues should be considered while working on the pure H.323 Mobility. - The concept of the Location Area (LA). Whether we need that concept or not and if we need it, should it be considered already in the first step (see the above point). I'll address all these points below. THE PLACEMENT OF HLF/VLF AND THE HOME/VISITED ZONE DISCUSSION I think we both/all agree on one thing: The HLF and the VLF must be defined in the standard in such a way that it is possible for multiple GKs to access the same HLF/VLF. This allows for an approach in which the HLF/VLF is distributed among many GKs while simultaneously allowing the HLF/VLF to be associated with only a single GK, if this kind of a centralized design is desired. The thing that we disagree on is: I do NOT want to define the terms Home Zone and Visited Zone (or similar) yet. I did not seem to make that clear in my last message. The reasons why I do not want to define this kind of terms, at least yet, are as follows. The term Home Zone leads in my mind to a definition in which every User is associated with one and only one zone as the User's "Home". I.e. the HLF containing the permanent information about the User can be accessed through the GK of the Home Zone and no other GK. Now, I do not think, Radhika, that this is what you intended, but if we talk about a Home Zone, this is the kind of thing that first comes to my mind. I currently have the idea that you meant that each User may have multiple Home Zones, is that right, Radhika? If that is the case, I do not fully understand why we would need the concept of the Home Zone at all (but maybe I'm just missing something). The important thing in all these Home/Visited concepts is: how to identify and access the HLF of a certain User and by accessing the HLF, update all the relevant information in the HLF and in the VLFs. If there are multiple Home Zones for a User, all the GKs of these zones can be used to access the HLF of the User, i.e. the HLF is identified by the Home Zone identifier (if this is not the case, what is the purpose of the Home Zone). Now, how is it determined, which GK should be Used in this case? The User must always give some "pointer" with which the HLF can be identified when the User enters a zone (or LA, if we use them). In this case the Home Zone ID would be that identifier. If always one of these Home Zones is given as the access point to the HLF, this leads to a highly centralized model with this one single zone and its GK as the central point. If, on the other hand, any of these zones can be given, how is this zone picked, randomly? Furthermore, how does a GK of a User's Home Zone know that it is in fact a "Home GK" for that User, if the User gives some other Home Zone ID than the one of the Home Zone where he is located? All the above reasons, in my opinion, lead to the fact that the HLF must be identified with an identifier that is NOT related to any single zone or GK. This is why I proposed the concept of Home Domain (I use the concept of an Administrative Domain because, as Radhika mentioned, it is already defined in H.323) in my contribution to the Red Bank meeting (APC-1659). In this case the Home Domain would identify the HLF of a User and thus the GKs in the Home Domain could identify that they are in fact a part of the Home Domain and the HLF to which they have access, is the HLF of the User. If the User would be located in some other (Visited) Domain, his HLF could be identified by the Home Domain (thus this model would be BE centric. The Administrative Domain is, of course, not the only alternative to group the zones, which form the "Home" of a User together, I just used it, because it is already defined. We could also define a HLF Identifier which is not related to a Domain, but the GKs of the zones forming the User's "Home" would recognize if the HLF to which they have access is the correct HLF based on this identifier. THE TWO-STEP APPROACH DISCUSSION The two-step approach, as I understand it, means that we will first work on a pure end-to-end H.323 Mobility solution and after that has been done we will define the interworking with legacy (and future) mobile networks. Although I do agree that in general this is a good order to do these two things, I would like to see some general interworking aspects taken into consideration in the first phase. One example of these may be the Location Area concept. I do not want to go into details of the interworking issues in the first step, but I'm afraid that if we do not think about the interworking at all in the first step, we will end up defining some functionalities in two different ways, one being the result of the first step and the other an addition to this as the result of the second step when the solution of the first step is not capable of handling some general interworking procedure, for example. I hope, I made my point clear despite the above text being somewhat rambling... THE LOCATION AREA DISCUSSION This is actually an example of the problem I have with the "strict" two-step approach. Radhika is proposing that we try to solve the mobility in the first step without the LA concept. I think it would be very beneficial, if we at least consider it already in the first step. Furthermore, I am quite sure we will need the concept in the second step, or else we will end up with a very badly scalable system. As I said in my earlier message, the LA concept will help to make the H.323 mobile systems more easily scalable, the price for this is, of course, the increased complexity that the LAs bring to the system. To express shortly, what a LA is for: it is a grouping of NPoAs that are geographically located close to each other. A zone also consists of NPoAs, but these NPoAs can actually be geographically far from each other. In other words, a zone is a set of NPoAs that are grouped together for administrative purposes, not because they are close to each other (which they need not be). When we are dealing with wireless mobile terminals, this grouping based on the geographical location becomes important and thus my opinion is that we should consider the LA concept already in the first phase. - Jaakko Sundquist ------------------------------------------------------- In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole, and that means comfort. -------------------------------------------------------

1 0

[Robustness] Call Clearing related
by Orit Levin 05 Nov '99

05 Nov '99

Hello all! I completely agree that after multiplexing of H.323 calls is possible over the same TCP connection, we have to speak (and upgrade the H.323 specification) explicitly using separate terms: Q.931 logical Connection, H.245 logical Connection and the their TCP channel(s) below. Any better names are welcomed. I would vote for H.323v4 to strike out the old text and rewrite the rules using "new" explicit terminology. I understand that part of this rules are going to be based on the new Robustness work. This is why this Robustness work is so urgent and part of it should be done for H.323v4 i.e. for Feb. 00. So... as a part of this Robustness work and using this new terminology, I would like to start from cleaning up "relatively" simple issues. According to current state of the standard, it is not explicitly mandated to clean H.323 Call if its Q.931 TCP connection is reported to be lost from any reason. There are two reasons being claimed against complete closure of the Call in this situation: (a) May be the other side (or the GK) intentionally closed the Q.931 logical Connection and its corresponding TCP channel in order to free up its internal resources, but still wants the H.245 logical Connection and the Call to stay in place. (b) May be it is a real TCP connection failure, but future Robustness Specification will define a way to recover from TCP connection failure without dropping the Call. As a result, in practice upon TCP connection failure (which may be a part of other side failure) H.323 calls are being hanging up without local resources freeing so essential for H.323 users (and networks)!!! I think that considering (a) and (b) as a general case is a mistake. I will try to explain myself below: (a) If we look in Implementers Guide V.1 (see the attachment) text (which has been lost on its way to V.2), the problem was identified long ago. It was recommended to keep the Q.931 logical Connection open. My question is: Do we know about any commercial H.323v1-v3 implementations that intentionally close Q.931 TCP channel but still expect the Call to be maintained? I suggest to find the practical answer and then debate how to keep these implementations happy. (b) If the case is a real TCP connection failure, the future possible way to recover is adding application (i.e. H.323) layer means (i.e. messages/parameters) and procedures to open an alternate TCP connection between the parties and associate it to the previous Q.931 logical connection. Therefore if one of the parties is of H.323v1-3, there is no way in the future to find a remedy for such a Call. The bottom line: If one of the parties in H.323 call doesn't support RobustnessV.1 and Q.931 TCP connection failure has been reported from TCP layer, the call shall be cleared and resources freed. Any comments? Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com -----Original Message----- From: Paul E. Jones <paul.jones(a)TIES.ITU.INT> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: Tuesday, November 02, 1999 11:44 PM Subject: Re: [Robustness] Re: Call Clearing related >Chris, > >> A technical question on the second paragraph of your mail: how do >endpoints >> KNOW that they're connected directly rather than through a gatekeeper, in >order >> to decide whether they can (under the current system) drop the >call-signalling >> channel? > >First of all... sorry for the delayed response. I am a bit behind :-) > >I, too, noticed this funny little sentence in the standard. In theory, the >GK would signal that the call is being routed, but that may not necessarily >be the case. > >I believe it is clear that we must address this issue. I would like to >strike the text as I proposed. I also believe it might be wise to add a >paragraph to V4 noting that V3 and older terminals may close the call >signaling channel, along the lines of your e-mail. > >Another issue we have at hand is that of "what is a call signaling channel?" >There used to be a one to one mapping between TCP connections and call >signaling channels. This is not the case any longer-- one may have multiple >calls over the same call signaling channel and one may not even use TCP. > >Making this distinction will be important for the robustness work being >started, as the "logical" connection (the call signaling channel) and the >"physical" connection (the TCP or UDP connection) must be referred to >independently. (I'm quite open to new terms for here...). It is important >to recognize whether an endpoint has closed the call signaling channel (as >we understand it today) or if the physical connection has failed. Since we >do not signal that we are going to close the call signaling channel today-- >we just close the socket-- it makes this problem more difficult. > >Paul

2 1

unsubscribe
by Cheng-Yao Ni 05 Nov '99

05 Nov '99

cynie(a)dcs.ccl.itri.org.tw -------------------------------------------- Sam Ni Senior Member of Technical Staff TIBCO Software Inc. Taiwan 16F-2, No. 295 Sec. 2 Kuang Fu Rd., Hsinchu, Taiwan, R.O.C. Tel: +886-3-5728842 ext. 210 Fax: +886-3-5714059 GSM: +886-930817613

1 0

Re: H323 mobility: Summary of discussion
by Roy, Radhika R, ALARC 04 Nov '99

04 Nov '99

Hi, Jaakko: Pl see my reply enclosed below. Best regards, Radhika > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] > Sent: Thursday, November 04, 1999 8:48 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H323mobility: Summary of discussion > > Hi, Radhika et al, > > It seems that I did not make all my points so clear in my last message (as > I > said I was pretty tired when I wrote it). Also the discussion between me > and > Radhika (& Ed) seems to be getting out of hand. [Roy, Radhika R] Please be happy to take your time. There is no hurry. We have a great responsibility to have the best standard that people can ever collectively think of. So, please provide your best thoughts even if you think that you should need to take rest. > Thus I'll try to summarize > the points in the discussion and include my views in this message. > > As I see it, we have been discussing about three basic issues: > - The architectural placement of the HLF and VLF functionalities. The > discussion also has included (or actually it started from) the question > whether the terms: Home Zone and Visited Zone, with respective identifiers > should be defined or not. > - The two-step approach of first specifying the pure H.323 Mobility and as > a > second step the issues related to PLMN interworking. The discussion has > been > on whether (at least some of the) PLMN interworking issues should be > considered while working on the pure H.323 Mobility. > - The concept of the Location Area (LA). Whether we need that concept or > not > and if we need it, should it be considered already in the first step (see > the above point). > > I'll address all these points below. > > THE PLACEMENT OF HLF/VLF AND THE HOME/VISITED ZONE DISCUSSION > > I think we both/all agree on one thing: > The HLF and the VLF must be defined in the standard in such a way that it > is > possible for multiple GKs to access the same HLF/VLF. This allows for an > approach in which the HLF/VLF is distributed among many GKs while > simultaneously allowing the HLF/VLF to be associated with only a single > GK, > if this kind of a centralized design is desired. [Roy, Radhika R] I agree on your first point. To associate HLF/VLF with only a "single" GK is an implementation issue. It is NOT a protocol issue. Here we are mixing between mobility protocol vs. implementation. Let me explain. In H.323, the protocol is GK-centric. So, the mobility protocol should be developed to abide by this fundamental principle. That is, the mobility protocol characteristics should be such that it will not impose any restriction to obtain a service per GK basis. In fact, what you are asking is this: If the HLF/VLF function is associated with a "single" GK, what happens to the mobility protocol. How does the H.323 mobility protocol allow us to have this service. This is a valid question. How do we achieve this goal? Let me answer your question: We will build the protocol in such a way that will NOT restrict this particular implementation. [Roy, Radhika R] To me (as well as to others as well I guess), HLF/VLF is another function that resides behind a GK (similar to functions address and other information). I do NOT see that there is a need to develop a backend protocol between the GK and HLF/VLF right now. In the same token, H.323 has not yet defined the backend protocol between the GK and the directory server. If needed, it may be in the next stage of standardization. However, contributions may be brought to drive this work anytime. [Roy, Radhika R] In fact you might also see AT&T contributions submitted during the development of inter-domain protocol (H.225.0 Annex G). We have shown that the GK architecture can be distributive, centralized (hierarchical), and/or hybrid. Your proposal to associate HLF/VLF with a single GK will create a centralized (hierarchical) GK architectural model. However, H.323 mobility protocol should be robust enough to take care-of all GK architectural models: distributive, centralized (hierarchical), and/or hybrid. [Roy, Radhika R] I guess that I have answered your question. > The thing that we disagree on is: I do NOT want to define the terms Home > Zone and Visited Zone (or similar) yet. I did not seem to make that clear > in > my last message. The reasons why I do not want to define this kind of > terms, > at least yet, are as follows. [Roy, Radhika R] As it mentioned that H.323 is GK-centric. A GK control a zone. To track mobility problem, there should be a point of reference. To make point of reference that is consistent with the H.323 existing architecture, we need to use it without breaking the fundamental concept of H.323. We have to maintain the continuity of the existing H.323 architecture. If we can solve problems with the framework of existing H.323 architecture, why do we need to confuse by creating new terminolgies? I like to see a complete proposal solving all mobility problems (as AT&T and Motorola contributions) justifying the need for creation of new terminolgies as you are proposing. Nokia's contribution proposes some ideas in a high-level manner. What is needed, like AT&T and Motorola contributions, provide a complete solution first. Then, we will compare all solutions together. Otherwise, it is still hypothetical to accept you arguments. > The term Home Zone leads in my mind to a definition in which every User is > associated with one and only one zone as the User's "Home". I.e. the HLF > containing the permanent information about the User can be accessed > through > the GK of the Home Zone and no other GK. Now, I do not think, Radhika, > that > this is what you intended, but if we talk about a Home Zone, this is the > kind of thing that first comes to my mind. [Roy, Radhika R] Again, in H.323, a use has to register with a GK. It is a MUST. However, a user can also choose some alternate GKs. It is an OPTION. This is the fundamental architectural concept of H.323. We have to start solving our mobility problems based on this foundation. Home GK/Zone concept is based on this foundation to have a reference to start with in order to solve mobility problems. If we can solve H.323 mobility problems based on the basic foundation what already exists in H.323, why do need to invent new terminologies? As I mentioned earlier, like any other functions in H.323, HLF is also another function is obtained by users via the GK. Please note very carefully as I also mentioned in my earlier email: Like address information (e.g., alias, transport/network addresses, etc), HLF function is also obtained via the GK. Now to track the mobility problem, there needs to be a reference point in the context of H.323 architecture. To solve this problem, it is found that it is a better choice to associate a use with a "home" GK because a user, as H.323 requires, must register with a GK. (Please note that there can also be a backend server behind the GK to provide the HLF service. This is another level of standardization. As I explained, similar to the directory service, H.323 also does not need to define this backend protocol right now. However, contributions are welcomed in this area as well.) > I currently have the idea that you meant that each User may have multiple > Home Zones, is that right, Radhika? If that is the case, I do not fully > understand why we would need the concept of the Home Zone at all (but > maybe > I'm just missing something). [Roy, Radhika R] Again, we have to look into the existing H.323 standard. What does it say? Does it not require that a use must register with a GK? However, there can also be alternate GKs. Using the same basic foundation of H.323, it is logical that a user will register with a GK. To track the mobility, it is a logical choice to have reference point. This GK is designated with a GK known as the home GK. Per existing H.323 standard, a user can also have alternate GKs as an order of priority. In the same token, a user is also free to declare alternate home GKs as an order of priority. AT&T contribution has provided a complete solution how extension of RAS messages will take care-of this problem automatically. In this context, this approach of mobility is perfectly consistent with exiting H.323 standard. > The important thing in all these Home/Visited concepts is: how to identify > and access the HLF of a certain User and by accessing the HLF, update all > the relevant information in the HLF and in the VLFs. [Roy, Radhika R] Not necessarily. HLF/VLF is one of the functions. HLF/VLF may have user profiles in terms of personal IDs and other functions. Personal IDs are nothing but some new alias addresses. So, an extension in "H.323 alias address" will take care-of personal IDs. Similarly, other functions of user profiles can be taken care of with similar extensions. More importantly, home/foreign zone concept helps to solve H.323 mobility problems when users move from one place to another in reference to the H.323 architectural entities (e.g., zones, transport address [TCPs/UDPs: call control, media control, RAS signaling], network addresses [e.g., IP, ATM], domains, etc.). No one should underestimate what the mobility in the context of H.323 means. There are fundamental differences between the so called traditional "plain Vanilla" mobility defining in HLF/VLF in the circuit switching world and the H.323 mobility. Please see AT&T contribution how the complex H.323 mobility problem has been solved simply through extension of RAS messages and some new messages. Please all see Motorola's contribution in this context. > If there are multiple > Home Zones for a User, all the GKs of these zones can be used to access > the > HLF of the User, i.e. the HLF is identified by the Home Zone identifier > (if > this is not the case, what is the purpose of the Home Zone). Now, how is > it > determined, which GK should be Used in this case? The User must always > give > some "pointer" with which the HLF can be identified when the User enters a > zone (or LA, if we use them). In this case the Home Zone ID would be that > identifier. If always one of these Home Zones is given as the access point > to the HLF, this leads to a highly centralized model with this one single > zone and its GK as the central point. If, on the other hand, any of these > zones can be given, how is this zone picked, randomly? Furthermore, how > does > a GK of a User's Home Zone know that it is in fact a "Home GK" for that > User, if the User gives some other Home Zone ID than the one of the Home > Zone where he is located? [Roy, Radhika R] Please see my above answer how this complex mobility problems are solved very beautifully in terms of primary GK and alternate GKs in the context of existing H.323 standards. We do NOT need to invent any new terminologies (e.g., location area [LA] or others). Please see AT&T contribution how the complete solution has been provided right within the context of existing H.323 standard. In this context, Motorola's contribution can also been seen. > All the above reasons, in my opinion, lead to the fact that the HLF must > be > identified with an identifier that is NOT related to any single zone or > GK. > This is why I proposed the concept of Home Domain (I use the concept of an > Administrative Domain because, as Radhika mentioned, it is already defined > in H.323) in my contribution to the Red Bank meeting (APC-1659). In this > case the Home Domain would identify the HLF of a User and thus the GKs in > the Home Domain could identify that they are in fact a part of the Home > Domain and the HLF to which they have access, is the HLF of the User. If > the > User would be located in some other (Visited) Domain, his HLF could be > identified by the Home Domain (thus this model would be BE centric. > The Administrative Domain is, of course, not the only alternative to group > the zones, which form the "Home" of a User together, I just used it, > because > it is already defined. We could also define a HLF Identifier which is not > related to a Domain, but the GKs of the zones forming the User's "Home" > would recognize if the HLF to which they have access is the correct HLF > based on this identifier. [Roy, Radhika R] Both AT&T and Motorola's contributions provide solutions without inventing new terminologies. If needed, as pointed out earlier, we like to see a complete contribution from Nokia that solves all mobility problems using the new terminologies as it is done in AT&T and Motorola's contribution. Otherwise, it is still a very high-level concept such as home/foreign domains. My fear is that it may break the fundamental architectural concept of the existing H.323 standard. So, far I have NOT seen any reason to believe why the solution provided by AT&T complementing the existing H.323 architecture should be modified. I also see that Motorola's contribution is also providing the mobility solution within the framework of existing H.323 architecture. Before, we deviate from the fundamental concept of H.323 architecture, we like to see a complete contribution from Nokia similar to AT&T's. Only then, we will be able to see the merit of Nokia's proposed architectural concept. > THE TWO-STEP APPROACH DISCUSSION > > The two-step approach, as I understand it, means that we will first work > on > a pure end-to-end H.323 Mobility solution and after that has been done we > will define the interworking with legacy (and future) mobile networks. > Although I do agree that in general this is a good order to do these two > things, I would like to see some general interworking aspects taken into > consideration in the first phase. One example of these may be the Location > Area concept. I do not want to go into details of the interworking issues > in > the first step, but I'm afraid that if we do not think about the > interworking at all in the first step, we will end up defining some > functionalities in two different ways, one being the result of the first > step and the other an addition to this as the result of the second step > when > the solution of the first step is not capable of handling some general > interworking procedure, for example. > > I hope, I made my point clear despite the above text being somewhat > rambling... > > THE LOCATION AREA DISCUSSION > > This is actually an example of the problem I have with the "strict" > two-step > approach. Radhika is proposing that we try to solve the mobility in the > first step without the LA concept. I think it would be very beneficial, if > we at least consider it already in the first step. Furthermore, I am quite > sure we will need the concept in the second step, or else we will end up > with a very badly scalable system. > As I said in my earlier message, the LA concept will help to make the > H.323 > mobile systems more easily scalable, the price for this is, of course, the > increased complexity that the LAs bring to the system. To express shortly, > what a LA is for: it is a grouping of NPoAs that are geographically > located > close to each other. A zone also consists of NPoAs, but these NPoAs can > actually be geographically far from each other. In other words, a zone is > a > set of NPoAs that are grouped together for administrative purposes, not > because they are close to each other (which they need not be). When we are > dealing with wireless mobile terminals, this grouping based on the > geographical location becomes important and thus my opinion is that we > should consider the LA concept already in the first phase. [Roy, Radhika R] The network point of attachment has been taken care-of. As I told before, a complete contribution has to be provided how LA concept will be useful to solve the mobility problem. AT&T has provided a complete solution providing architecture, signaling messages, call control, mobility management, and ASN.1 of RAS signaling messages. The contribution has shown how mobility problem is solved in the context of existing H.323 architectural concept. Nokia has to do the same to understand the merit that H.323 mobility problem cannot be solved as it is shown AT&T's contribution without using LA, home/foreign domain concepts as proposed by Nokia. Motorola's contribution can also be seen for this purpose. > - Jaakko Sundquist > ------------------------------------------------------- > In a hole in the ground there lived a hobbit. > Not a nasty, dirty, wet hole, filled with the ends of > worms and an oozy smell, nor yet a dry, bare, > sandy hole with nothing in it to sit down on or to eat: > it was a hobbit-hole, and that means comfort. > -------------------------------------------------------

1 0

Re: H323mobility: Summary of discussion
by Edgar Martinez [1] 04 Nov '99

04 Nov '99

I agreed with most of Jaakko comments and also make vaild points, and will like to add the following. I believe that the (Home) in Home Zone should be taken out. What we are talking about is the User's Point of Attached in any given Zone. The HLF is ready and Data base which has the User's profile and the current user's location. We can get a new name to HLF and call it the Location Profile Register (LPR) or Location Profile Function (LPF). I also believe that the (Visited) in Visited Zone sould also be taken out because again we are talking about the Users current Point of Attachment in any given Zone. The VLF has the means to update the Location Profile Register (LPR) from any given Zone. We can get a new name to VLF call it the Location Update Register (LUR) or Location Update Function (LUF). Now we can also support concepts of Zone ID's such as Current Zone ID and Previous Zone ID. Finally, And I strongly agree with looking at the interworking in parallel with H.323 mobility. The time we spent now looking at interworking will be compensated in the long run. I sure does working on ISUP, IN and Qsig, inetrworking with H.323 would agree and we should learn from their experience. And not leave it for a last minute add-on. Lets take the contribution as they come, if one wants to put in interworking fine. If one wants to put in contributions only H.323 mobility also fine. Both are in order and within our scope. The general strategy should focus on ensuring that the H.323 Mobility and interworking options are enabled, rather than spending too much effort blocking alternative options (Our limited resources frankly don't allow this luxury). But there really is no substitute for doing the work - preparing input papers and presenting them to move things forward. Best Regards, Ed Jaakko Sundquist wrote: > Hi, Radhika et al, > > It seems that I did not make all my points so clear in my last message (as I > said I was pretty tired when I wrote it). Also the discussion between me and > Radhika (& Ed) seems to be getting out of hand. Thus I'll try to summarize > the points in the discussion and include my views in this message. > > As I see it, we have been discussing about three basic issues: > - The architectural placement of the HLF and VLF functionalities. The > discussion also has included (or actually it started from) the question > whether the terms: Home Zone and Visited Zone, with respective identifiers > should be defined or not. > - The two-step approach of first specifying the pure H.323 Mobility and as a > second step the issues related to PLMN interworking. The discussion has been > on whether (at least some of the) PLMN interworking issues should be > considered while working on the pure H.323 Mobility. > - The concept of the Location Area (LA). Whether we need that concept or not > and if we need it, should it be considered already in the first step (see > the above point). > > I'll address all these points below. > > THE PLACEMENT OF HLF/VLF AND THE HOME/VISITED ZONE DISCUSSION > > I think we both/all agree on one thing: > The HLF and the VLF must be defined in the standard in such a way that it is > possible for multiple GKs to access the same HLF/VLF. This allows for an > approach in which the HLF/VLF is distributed among many GKs while > simultaneously allowing the HLF/VLF to be associated with only a single GK, > if this kind of a centralized design is desired. > > The thing that we disagree on is: I do NOT want to define the terms Home > Zone and Visited Zone (or similar) yet. I did not seem to make that clear in > my last message. The reasons why I do not want to define this kind of terms, > at least yet, are as follows. > > The term Home Zone leads in my mind to a definition in which every User is > associated with one and only one zone as the User's "Home". I.e. the HLF > containing the permanent information about the User can be accessed through > the GK of the Home Zone and no other GK. Now, I do not think, Radhika, that > this is what you intended, but if we talk about a Home Zone, this is the > kind of thing that first comes to my mind. > I currently have the idea that you meant that each User may have multiple > Home Zones, is that right, Radhika? If that is the case, I do not fully > understand why we would need the concept of the Home Zone at all (but maybe > I'm just missing something). > The important thing in all these Home/Visited concepts is: how to identify > and access the HLF of a certain User and by accessing the HLF, update all > the relevant information in the HLF and in the VLFs. If there are multiple > Home Zones for a User, all the GKs of these zones can be used to access the > HLF of the User, i.e. the HLF is identified by the Home Zone identifier (if > this is not the case, what is the purpose of the Home Zone). Now, how is it > determined, which GK should be Used in this case? The User must always give > some "pointer" with which the HLF can be identified when the User enters a > zone (or LA, if we use them). In this case the Home Zone ID would be that > identifier. If always one of these Home Zones is given as the access point > to the HLF, this leads to a highly centralized model with this one single > zone and its GK as the central point. If, on the other hand, any of these > zones can be given, how is this zone picked, randomly? Furthermore, how does > a GK of a User's Home Zone know that it is in fact a "Home GK" for that > User, if the User gives some other Home Zone ID than the one of the Home > Zone where he is located? > All the above reasons, in my opinion, lead to the fact that the HLF must be > identified with an identifier that is NOT related to any single zone or GK. > This is why I proposed the concept of Home Domain (I use the concept of an > Administrative Domain because, as Radhika mentioned, it is already defined > in H.323) in my contribution to the Red Bank meeting (APC-1659). In this > case the Home Domain would identify the HLF of a User and thus the GKs in > the Home Domain could identify that they are in fact a part of the Home > Domain and the HLF to which they have access, is the HLF of the User. If the > User would be located in some other (Visited) Domain, his HLF could be > identified by the Home Domain (thus this model would be BE centric. > The Administrative Domain is, of course, not the only alternative to group > the zones, which form the "Home" of a User together, I just used it, because > it is already defined. We could also define a HLF Identifier which is not > related to a Domain, but the GKs of the zones forming the User's "Home" > would recognize if the HLF to which they have access is the correct HLF > based on this identifier. > > THE TWO-STEP APPROACH DISCUSSION > > The two-step approach, as I understand it, means that we will first work on > a pure end-to-end H.323 Mobility solution and after that has been done we > will define the interworking with legacy (and future) mobile networks. > Although I do agree that in general this is a good order to do these two > things, I would like to see some general interworking aspects taken into > consideration in the first phase. One example of these may be the Location > Area concept. I do not want to go into details of the interworking issues in > the first step, but I'm afraid that if we do not think about the > interworking at all in the first step, we will end up defining some > functionalities in two different ways, one being the result of the first > step and the other an addition to this as the result of the second step when > the solution of the first step is not capable of handling some general > interworking procedure, for example. > > I hope, I made my point clear despite the above text being somewhat > rambling... > > THE LOCATION AREA DISCUSSION > > This is actually an example of the problem I have with the "strict" two-step > approach. Radhika is proposing that we try to solve the mobility in the > first step without the LA concept. I think it would be very beneficial, if > we at least consider it already in the first step. Furthermore, I am quite > sure we will need the concept in the second step, or else we will end up > with a very badly scalable system. > As I said in my earlier message, the LA concept will help to make the H.323 > mobile systems more easily scalable, the price for this is, of course, the > increased complexity that the LAs bring to the system. To express shortly, > what a LA is for: it is a grouping of NPoAs that are geographically located > close to each other. A zone also consists of NPoAs, but these NPoAs can > actually be geographically far from each other. In other words, a zone is a > set of NPoAs that are grouped together for administrative purposes, not > because they are close to each other (which they need not be). When we are > dealing with wireless mobile terminals, this grouping based on the > geographical location becomes important and thus my opinion is that we > should consider the LA concept already in the first phase. > > - Jaakko Sundquist > ------------------------------------------------------- > In a hole in the ground there lived a hobbit. > Not a nasty, dirty, wet hole, filled with the ends of > worms and an oozy smell, nor yet a dry, bare, > sandy hole with nothing in it to sit down on or to eat: > it was a hobbit-hole, and that means comfort. > ------------------------------------------------------- -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

H323mobility: Summary of discussion
by Jaakko Sundquist 04 Nov '99

04 Nov '99

Hi, Radhika et al, It seems that I did not make all my points so clear in my last message (as I said I was pretty tired when I wrote it). Also the discussion between me and Radhika (& Ed) seems to be getting out of hand. Thus I'll try to summarize the points in the discussion and include my views in this message. As I see it, we have been discussing about three basic issues: - The architectural placement of the HLF and VLF functionalities. The discussion also has included (or actually it started from) the question whether the terms: Home Zone and Visited Zone, with respective identifiers should be defined or not. - The two-step approach of first specifying the pure H.323 Mobility and as a second step the issues related to PLMN interworking. The discussion has been on whether (at least some of the) PLMN interworking issues should be considered while working on the pure H.323 Mobility. - The concept of the Location Area (LA). Whether we need that concept or not and if we need it, should it be considered already in the first step (see the above point). I'll address all these points below. THE PLACEMENT OF HLF/VLF AND THE HOME/VISITED ZONE DISCUSSION I think we both/all agree on one thing: The HLF and the VLF must be defined in the standard in such a way that it is possible for multiple GKs to access the same HLF/VLF. This allows for an approach in which the HLF/VLF is distributed among many GKs while simultaneously allowing the HLF/VLF to be associated with only a single GK, if this kind of a centralized design is desired. The thing that we disagree on is: I do NOT want to define the terms Home Zone and Visited Zone (or similar) yet. I did not seem to make that clear in my last message. The reasons why I do not want to define this kind of terms, at least yet, are as follows. The term Home Zone leads in my mind to a definition in which every User is associated with one and only one zone as the User's "Home". I.e. the HLF containing the permanent information about the User can be accessed through the GK of the Home Zone and no other GK. Now, I do not think, Radhika, that this is what you intended, but if we talk about a Home Zone, this is the kind of thing that first comes to my mind. I currently have the idea that you meant that each User may have multiple Home Zones, is that right, Radhika? If that is the case, I do not fully understand why we would need the concept of the Home Zone at all (but maybe I'm just missing something). The important thing in all these Home/Visited concepts is: how to identify and access the HLF of a certain User and by accessing the HLF, update all the relevant information in the HLF and in the VLFs. If there are multiple Home Zones for a User, all the GKs of these zones can be used to access the HLF of the User, i.e. the HLF is identified by the Home Zone identifier (if this is not the case, what is the purpose of the Home Zone). Now, how is it determined, which GK should be Used in this case? The User must always give some "pointer" with which the HLF can be identified when the User enters a zone (or LA, if we use them). In this case the Home Zone ID would be that identifier. If always one of these Home Zones is given as the access point to the HLF, this leads to a highly centralized model with this one single zone and its GK as the central point. If, on the other hand, any of these zones can be given, how is this zone picked, randomly? Furthermore, how does a GK of a User's Home Zone know that it is in fact a "Home GK" for that User, if the User gives some other Home Zone ID than the one of the Home Zone where he is located? All the above reasons, in my opinion, lead to the fact that the HLF must be identified with an identifier that is NOT related to any single zone or GK. This is why I proposed the concept of Home Domain (I use the concept of an Administrative Domain because, as Radhika mentioned, it is already defined in H.323) in my contribution to the Red Bank meeting (APC-1659). In this case the Home Domain would identify the HLF of a User and thus the GKs in the Home Domain could identify that they are in fact a part of the Home Domain and the HLF to which they have access, is the HLF of the User. If the User would be located in some other (Visited) Domain, his HLF could be identified by the Home Domain (thus this model would be BE centric. The Administrative Domain is, of course, not the only alternative to group the zones, which form the "Home" of a User together, I just used it, because it is already defined. We could also define a HLF Identifier which is not related to a Domain, but the GKs of the zones forming the User's "Home" would recognize if the HLF to which they have access is the correct HLF based on this identifier. THE TWO-STEP APPROACH DISCUSSION The two-step approach, as I understand it, means that we will first work on a pure end-to-end H.323 Mobility solution and after that has been done we will define the interworking with legacy (and future) mobile networks. Although I do agree that in general this is a good order to do these two things, I would like to see some general interworking aspects taken into consideration in the first phase. One example of these may be the Location Area concept. I do not want to go into details of the interworking issues in the first step, but I'm afraid that if we do not think about the interworking at all in the first step, we will end up defining some functionalities in two different ways, one being the result of the first step and the other an addition to this as the result of the second step when the solution of the first step is not capable of handling some general interworking procedure, for example. I hope, I made my point clear despite the above text being somewhat rambling... THE LOCATION AREA DISCUSSION This is actually an example of the problem I have with the "strict" two-step approach. Radhika is proposing that we try to solve the mobility in the first step without the LA concept. I think it would be very beneficial, if we at least consider it already in the first step. Furthermore, I am quite sure we will need the concept in the second step, or else we will end up with a very badly scalable system. As I said in my earlier message, the LA concept will help to make the H.323 mobile systems more easily scalable, the price for this is, of course, the increased complexity that the LAs bring to the system. To express shortly, what a LA is for: it is a grouping of NPoAs that are geographically located close to each other. A zone also consists of NPoAs, but these NPoAs can actually be geographically far from each other. In other words, a zone is a set of NPoAs that are grouped together for administrative purposes, not because they are close to each other (which they need not be). When we are dealing with wireless mobile terminals, this grouping based on the geographical location becomes important and thus my opinion is that we should consider the LA concept already in the first phase. - Jaakko Sundquist ------------------------------------------------------- In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole, and that means comfort. -------------------------------------------------------

1 0

Re: [Robustness] Call Clearing related
by Tzvi Kasten 04 Nov '99

04 Nov '99

Orit, In an event of a restart/crash in a Gatekeeper using gatekeeper routed signaling, I would assume that the preferred behavior of the system would be that existing stable calls will not drop. The Gatekeeper as it recovers will learn about the existing calls by its internal data and by sending IRQ's to the endpoints and then restore the Q.931 and H.245 connections. This will reduce the impact of such an event compared to dropping all the calls. If I understand you suggestion correctly it seems to me that this would be moving toward dropping all the calls. Please correct me if I am wrong. Thanks Tzvi Kasten Networking Infrastructures Group Manager Research & Development VCON Ltd. Tel: 09-9590020 ( 972-9-959-0020) Email: zvik(a)vcon.co.il http://www.vcon.com > -----Original Message----- > From: Orit Levin [SMTP:orit@radvision.com] > Sent: Thursday, November 04, 1999 6:30 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: [Robustness] Call Clearing related > > eSafe Protect Gateway (tm) has scanned this mail for viruses, vandals and > suspicious attachments and has found it to be CLEAN. > > File: ImpGuideV1.zip (54,781 bytes) > Encoding: Base64 > Result: Archive is clean. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Hello all! > I completely agree that after multiplexing of H.323 calls is possible > over the same TCP connection, we have to speak (and upgrade the H.323 > specification) explicitly using separate terms: Q.931 logical Connection, > H.245 logical Connection and the their TCP channel(s) below. Any better > names are welcomed. > I would vote for H.323v4 to strike out the old text and rewrite the > rules using "new" explicit terminology. I understand that part of this > rules > are going to be based on the new Robustness work. This is why this > Robustness work is so urgent and part of it should be done for H.323v4 > i.e. > for Feb. 00. > So... as a part of this Robustness work and using this new > terminology, > I would like to start from cleaning up "relatively" simple issues. > According > to current state of the standard, it is not explicitly mandated to clean > H.323 Call if its Q.931 TCP connection is reported to be lost from any > reason. There are two reasons being claimed against complete closure of > the > Call in this situation: > (a) May be the other side (or the GK) intentionally closed the Q.931 > logical Connection and its corresponding TCP channel in order to free up > its > internal resources, but still wants the H.245 logical Connection and the > Call to stay in place. > (b) May be it is a real TCP connection failure, but future Robustness > Specification will define a way to recover from TCP connection failure > without dropping the Call. > > As a result, in practice upon TCP connection failure (which may be a part > of > other side failure) H.323 calls are being hanging up without local > resources freeing so essential for H.323 users (and networks)!!! > > I think that considering (a) and (b) as a general case is a mistake. I > will > try to explain myself below: > > (a) If we look in Implementers Guide V.1 (see the attachment) text > (which > has been lost on its way to V.2), the problem was identified long ago. It > was recommended to keep the Q.931 logical Connection open. My question is: > Do we know about any commercial H.323v1-v3 implementations that > intentionally close Q.931 TCP channel but still expect the Call to be > maintained? I suggest to find the practical answer and then debate how to > keep these implementations happy. > > (b) If the case is a real TCP connection failure, the future possible > way > to recover is adding application (i.e. H.323) layer means (i.e. > messages/parameters) and procedures to open an alternate TCP connection > between the parties and associate it to the previous Q.931 logical > connection. Therefore if one of the parties is of H.323v1-3, there is no > way > in the future to find a remedy for such a Call. > > The bottom line: > If one of the parties in H.323 call doesn't support RobustnessV.1 and > Q.931 > TCP connection failure has been reported from TCP layer, the call shall be > cleared and resources freed. > > Any comments? > Orit Levin > RADVision Inc. > 575 Corporate Drive Suite 420 > Mahwah, NJ 07430 > Tel: 1 201 529 4300 (230) > Fax: 1 201 529 3516 > www.radvision.com > orit(a)radvision.com > -----Original Message----- > From: Paul E. Jones <paul.jones(a)TIES.ITU.INT> > To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> > Date: Tuesday, November 02, 1999 11:44 PM > Subject: Re: [Robustness] Re: Call Clearing related > > > >Chris, > > > >> A technical question on the second paragraph of your mail: how do > >endpoints > >> KNOW that they're connected directly rather than through a gatekeeper, > in > >order > >> to decide whether they can (under the current system) drop the > >call-signalling > >> channel? > > > >First of all... sorry for the delayed response. I am a bit behind :-) > > > >I, too, noticed this funny little sentence in the standard. In theory, > the > >GK would signal that the call is being routed, but that may not > necessarily > >be the case. > > > >I believe it is clear that we must address this issue. I would like to > >strike the text as I proposed. I also believe it might be wise to add a > >paragraph to V4 noting that V3 and older terminals may close the call > >signaling channel, along the lines of your e-mail. > > > >Another issue we have at hand is that of "what is a call signaling > channel?" > >There used to be a one to one mapping between TCP connections and call > >signaling channels. This is not the case any longer-- one may have > multiple > >calls over the same call signaling channel and one may not even use TCP. > > > >Making this distinction will be important for the robustness work being > >started, as the "logical" connection (the call signaling channel) and the > >"physical" connection (the TCP or UDP connection) must be referred to > >independently. (I'm quite open to new terms for here...). It is > important > >to recognize whether an endpoint has closed the call signaling channel > (as > >we understand it today) or if the physical connection has failed. Since > we > >do not signal that we are going to close the call signaling channel > today-- > >we just close the socket-- it makes this problem more difficult. > > > >Paul << File: ImpGuideV1.zip >>

1 0

H.323 v3 text
by Sakae OKUBO 04 Nov '99

04 Nov '99

Dear Mr. Jones, PJ> The h323v3_decided_991022.zip file replaces the 990930 version of PJ> H323v3. It contains one correction we made in Red Bank to H.323v3 PJ> where we removed the text relating to "empty fast start elements". PJ> This file should represent what the ITU will publish. Please be advised that h323v3_decided_991022.zip has replaced the relevant files in /9909_Gen directory. Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0