August 1998 - sg16-avd - lists.packetizer.com

Re: Contribution (Inter-GK Communications)
by Tom-PT Taylor 20 Aug '98

20 Aug '98

The comments below convey one or two valid points, but are marred by failure to recognize that different functions within H.323 have different message routing requirements. The valid points are: - efficient handling of LRQs is tricky (but getting around that is what a good bit of the Annex G work is all about) - if a call crosses several administrative domains, each domain has to have a chance to authorize the use of the resources to be consumed by the call. My further comments are interspersed with those of Mr. Roy. Tom Taylor > -----Original Message----- > From: Roy, Radhika R, ALTEC [SMTP:rrroy@ATT.COM] > Sent: Thursday, August 20, 1998 12:35 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Contribution (Inter-GK Communications) > > Hi Everyone: > > Here are my comments on APC-1422 Hierarchical Model Based VideoServer's > Proposal: > > It is appreciable that Mr. Santo Wiaryman, VideoServer, presented an > addressing scheme that ranges from multiple zones to multiple domains. > The > basic idea of the addressing scheme related to the zone and the domain is > the core of the proposal, and is applicable in other situations as well no > matter whether the architectural model is hierarchical or > non-hierarchical. > The opportunities and problems that are presented are real. This > contribution has increased our understanding related to the addressing > scheme in the context of zones and domains. > > However, the addressing scheme has been applied using the model specified > in > APC-1422 that uses hierarchical architecture using the border GKs. In this > context, the following comments will reveal the fundamental aspects of the > model proposed in APC-1422 considering the insights that have provided by > this proposal: > > 1. It appears that a sort of routing scheme(s) needs to be used for > sending the addressing information from a source zone GK through a series > of > hierarchical border GKs up to the root border GK, and from the root border > GK through a series border GKs to the destination zone GK. > 2. No mechanism is proposed in the signaling messages to protect > against routing loops when the "abstraction" of routing is made between > the > source zone GK , a series of hierarchical border GKs, and the destination > zone GK. [Taylor, Tom [CAR:B318-I:EXCH]] First valid point: handling of LRQs or their functional equivalent is tricky. Your proposal to add time-to-live to LRQs seems to have been accepted. > 3. Is there any inter-GK protocol messages (e.g., resource > availability) needed between the zone GK and the border GK and between the > border GKs other than the zone messages considering the (networking) > configurations of the GKs? > 4. It appears that a root border GK needs to be defined. Who will > decide the root GK from which a hierarchy will be establsihed? Is it any > international organization like IANA? > 5. The path between the source and the destination GK is the > pre-specified hierarchical logical path, and may not be optimal between > the > source-destination GK. [Taylor, Tom [CAR:B318-I:EXCH]] Postulating such a path, it is used only to distribute addressing information. Call signaling and media packet routing do not need to follow the same path, and in fact most of the routing decisions are made at the transport rather than the application level. > 6. The signaling message only passes through the source and the > destination zone GK, and other hierarchical GKs. As a result, if a call is > established between the source-destination path, the call may have to pass > through many "intermediate zones" in addition to the source and > destination > zone. Consequently, the intermediate zone GKs will be completely unable to > play any roles. [Taylor, Tom [CAR:B318-I:EXCH]] There is a kernel of truth here, the second valid point I noted above. However, the RAS messages you list below are designed for communication between the endpoint and its Gatekeeper. There are other solutions to the authorization problem (e.g. use of RADIUS/DIAMETER) besides propagation of these messages. Moreover, authorization will not typically be done by the Gatekeeper itself, but by an authorization server which it consults. It will be more efficient fto communicate with the authorization server for each administrative domain directly wherever possible rather than invoke a chain of Gatekeepers to do it indirectly. > For example, bandwidth/QOS resources that are supposed to be > allocated in each zone by each GK between the source-destination path > before > placing the call cannot be done. The RAS messages such as ARQ/ACF/ARJ, > BRQ/BCJ/BRJ, URQ/UCF/URJ, DRQ/DCF/DRJ, RAI/RAC, and others may not be able > to play proper roles for all zones between the source-destination path > through which a call is established. > 7. Is there any solution provided by the model described in APC-1422 > if > the zone boundaries become logical instead of physical? [Taylor, Tom [CAR:B318-I:EXCH]] Not clear how a zone as defined in H.323 is anything but logical. > This simple example presented by VideoServer using the proposed APC-1422 > model can also lead to a very high-level comparison between the > hierarchical > and non-hierarchical model. The following table may provide a high-level > summary of comparison between the two models: > > Table 1: High Level Summary of Comparsion > > Description Hierarchical Model: APC-1422/Example VideoServer Proposal > Non-Hierarchical Model: AT&T's Proposal Remarks > > Routing between the GKs Routing is needed: > * Static routing through the pre-specified logical path > * No scope for path optimization > * No mechanism for avoiding loops Routing is needed: > * Dynamic routing between the source-destination GKs > * Path is optimized > * Mechanism is provided to avoid loops > * (Static routing can also be done if needed) Non-hierarchical > model appears to be much superior > ARQ/ACF/ARJ Bandwidth/QOS allocation cannot be confirmed because the > signaling message does not pass through all zones between the > source-destination path. Bandwidth/QOS allocation can be confirmed > because the signaling message passes through all zones between the > source-destination path Non-hierarchical model appears to be much superior > > BRQ/BCJ/BRJ Bandwidth/QOS change cannot be confirmed because the > signaling message does not pass through all zones between the > source-destination path. Bandwidth/QOS change can be confirmed > because the signaling message passes through all zones between the > source-destination path Non-hierarchical model appears to be much superior > > All RAS signaling messages that may have implications for all zones > between > the source-destination path of the call Signaling messages cannot pass > through the intermediate zones Signaling messages can pass through all > zones between the source-destination path Non-hierarchical model > appears to be much superior > Root-GK A root-GK needs to be defined (does it mean to have an > international > authority like IANA?) No need to define a root-GK Non-hierarchical > model appears to be much superior > Logical zone boundary Probably cannot be defined (may be limited to > physical zone boundaries only) Can be defined (in addition to physical > one) > Non-hierarchical model appears to be much superior > > > If you have any questions, please let me know. > > Thanks and regards, > > Radhika R. Roy > AT&T, USA > Tel: +1 732 949 8657 > Email: rrroy(a)att.com

1 0

Resend(ish) - BT InterGK proposal
by Pete Cordell 20 Aug '98

20 Aug '98

Dear All, This is basically a re-send of my earlier submission. I have added a field in the header section that identifies the provider of the information. This is so that agreements can be established with different providers to support a domain. I.e. BT could use either AT+T or MCI to provide its route into America. Individual corporations may also have their own preferred providers. Regulation would dictate that such customer options are required, but I am not sure whether the proposed method is the best way to do it! The document can be downloaded from: ftp://ftp.labs.bt.com/pub/BT-InterGK2.doc Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

1 0

Re: Comments on AT&T proposal
by Roy, Radhika R, ALTEC 20 Aug '98

20 Aug '98

Hi everyone: Mr. Olivier HERSENT is absolutely right. The roaming has been one of the important things that has been considered to build the generalized UNIVERSAL model that AT&T proposal foresees (although the proposal does not mention specifically for implementation in roaming environment). There are many other aspects such as BW/QOS, dynamic routing schemes, inter-GK management, and topology optimization have also been considered. I completely agree that there can be many ways how this model porposed by AT&T can be used once the basic "inter-zone" communications model that allows all H.323 signaling messages over every zone between the source-destination GK is established. The MOST important thing is that we, in ITU-T SG16, should build the H.323 inter-GK signaling scheme as UNIVERSAL as far as practicable because one can use those power of signaling schemes in so many ways to build the SERVICES that can almost be limitless. Thanks and regards, Radhika R. Roy AT&T, USA Tel: + 1 732 949 8657 Email: rrroy(a)att.com > ---------- > From: HERSENT Olivier > CNET/DSE/CAE[SMTP:olivier.hersent@CNET.FRANCETELECOM.FR] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Thursday, August 20, 1998 10:53 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Comments on AT&T proposal > > Hi everyone, > > Some time ago, we had some brainstorming on roaming with H.323. One of the > simplest ways to do it was that the roaming terminal would send the ARQ, > ... > to the visited network GK (discovered my broadcast/multicast). This GK > would > recognize from the calling party alias that the terminal si from an > external > administation having an agreement with the visited administration. > It would then forward the xRQs to the home gatekeeper of the terminal and > get the xCFs in reply. > > This has many benefits : > - The home GK knows where is the roaming teminal and can forward calls. > - Any policy implemented at the home gatekeeper (restricted phone usage, > etc > ...) is still enforced in any visited domain > - It is simple > > So roaming might be a good reason to forward xRQs ... just my FF.02. > > Best regards, > > Olivier HERSENT > > -- > France Telecom CNET > IP Telephony Technical Proj. Manager - TULIP > > ---------- > > De : Roy, Radhika R, ALTEC[SMTP:rrroy@ATT.COM] > > Répondre à : Mailing list for parties associated with ITU-T Study Group > > 16 > > Date : Wednesday, August 19, 1998 6:09 PM > > A : ITU-SG16(a)MAILBAG.INTEL.COM > > Objet : Re: Comments on AT&T proposal > > > > 2. We do not see how the following messages can be passed from > one > > GK to > > another: GRQ/GCF/GRJ, RRQ/RCF/RRJ, ARQ/ACF/ARJ, BRQ/BCF/BRJ. We > > do > > not > > see in the present H.323 model how or what benefit is there to > > gain > > by > > passing these messages. May be you can show us a scenario where > > this is > > utilized. In the current H.323 model, an endpoint only talks > RAS > > with > > the GK it is registered with. For example: > > * Endpoint A which is registered to GK1, sends an ARQ to GK1 to > > call > > B > > * If GK1 can not resolve B's address, it shall send LRQ, and not > > pass on > > the ARQ to the next GK. [Radhika: The proposed model is so > > flexible > > that a zone boundary can be physical or logical. This distributive model > > does not restrict that a H.323 entity has to register to a GK which has > > "geographical" or "physical" proximity. That is, the model is so > flexible > > that the zones can also be logical instead of maintaining a boundary > > constrained by the physical proximity. If we consider that the ARQ > message > > is sent by a H.323 entity to the GK. The first GK that receives the ARQ > > message may not have the authority to respond because the H.323 entity > may > > not be registered with this one. So, the ARQ message has to be passed to > > the > > next GK. (If the first receiving GK has the authority [i.e., the H.323 > > entity is registered with this GK] to respond, then the ARQ message need > > not > > to be passed anymore.) The GK that has the authority will respond to the > > ARQ > > message. Therefore, the GK that will respond to the ARQ message will > also > > be > > the serving GK. Now the serving GK may be the first GK, or the serving > GK > > may reside to a place where multiple transit GKs may be along the path > > between the calling and the serving GK. Moreover, the most important > point > > is that the ARQ message needs also to confirm the "bandwidth". In a > > multiple > > GK environment, the source-destination path may cover multiple zones, > and > > each zone will have its own GK. Therefore, the serving GK has to work > > cooperatively with all other GKs to confirm the fact that the bandwidth > in > > all zones along the source-destination is good enough to accept the call > > before sending the ACF message (also see Section 3.5 of the proposed > > contribution). It shows clearly the power of the distributive GK model > > proposed in the contribution in solving the complex problems in the > > context > > of large-scale network. Similarly, all other messages can also be > > explained > > why these messages need to be passed from one GK to another.] > > > > >

1 0

Re: H.225.0 Annex G conference call
by Roy, Radhika R, ALTEC 20 Aug '98

20 Aug '98

Kindly see a reply addressed to Mr. G. Freundlich's email. Regards, Radhika R. Roy > ---------- > From: Kumar, Vineet[SMTP:vineet.kumar@INTEL.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Wednesday, August 19, 1998 12:47 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.225.0 Annex G conference call > > My comments are embedded in the email below. > > vineet > > > -----Original Message----- > > From: Roy, Radhika R, ALTEC [SMTP:rrroy@ATT.COM] > > Sent: Wednesday, August 19, 1998 9:24 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: H.225.0 Annex G conference call > > > > Hi Everyone: > > > > I have few comments on the revised Annex G writeup. > > > > 1. The title is OK > > 2. The scope is not OK. As we talked last time that the scope should be > > extended to include the following: > > * Inter-Gatekeeper Communications within a Domain > > * Inter-Gatekeeper Communications Between (Administrative) > > Domains > [Kumar, Vineet] The scope was decided at the Yokosuka meeting and > further confirmed at he Cannes meeting. Most participants are comfortable > with it. It seems that you are the only one who wants to change the scope. > For companies that are implementing this Annex there is an urgent need to > move ahead and complete the work within the scope agreed at the previous > rapporteur meetings. One compromise might be to create an additional Annex > whose scope is Inter-Gatekeeper Communications within a Domain. I believe > that this compromise takes into account your point of view on the scope > and > should be acceptable to you. > > 3. APC-1385 provides outlines for the "Inter-Gatekeeper Communications > > within a Domain". The write-up of Annex G should be modified > accordingly. > [Kumar, Vineet] The specific diagrams in APC-1385 have been > modelled in the figures of Annex G. Additionally, there has been no > specific > examples of protocol limitations from Annex G/APC-1422 that would disallow > deployment of models described in APC-1385 > > 4. The items 2 and 3 had been discussed in the last conference call. Are > > we > > going through a circle again? > [Kumar, Vineet] Most of the participants do not agree with you on > items 2 and 3. So, in the interest of moving ahead the compromise I have > suggested in item 2 should be acceptable to you. > > 5. The comments on the remaining text of the document will be reviewed > > when > > the fundamental direction of Annex G is put along the line as pointed > out > > above. > [Kumar, Vineet] Comments should be reviewed based on the Editor > and > Group consensus, and not on the wishes of a specific individual. > > > Recent AT&T's proposed contribution has also been submitted to > complement > > the write-up in the area of "Inter-Gatekeeper Communications within a > > Domain". > > > > Thanks and regards, > > > > Radhika R. Roy > > AT&T > > Tel: +1 732 949 8657 > > Email: rrroy(a)att.com > > > > > ---------- > > > From: Glen Freundlich[SMTP:ggf@lucent.com] > > > Reply To: ggf(a)lucent.com > > > Sent: Tuesday, August 18, 1998 3:11 PM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: H.225.0 Annex G conference call > > > > > > <<File: diff0201.zip>> > > > There will be another conference call to discuss H.225.0 Annex G: > > > date: 20 August (Thursday) > > > time: 10:00am Mountain Time (9:00 Pacific, 12:00 Eastern, etc) > > > bridge number: +1 630-224-4444 > > > code: 911202 > > > duration: 1 hour > > > > > > Tentative agenda: > > > - next call 27 August > > > - review of Santo Wiryaman's proposal > > > - review of Pete Cordell's proposal > > > - review of Radhika Roy's proposal > > > > > > Notes from last call: > > > Most of the call was spent discussing an email from Radhika Roy. Some > of > > > the significant points are: > > > > > > - The Annex G title (Communication Between Administrative Domains) was > > > viewed as too restrictive. According to the Yokosuka meeting report, > > > Annex G is to focus on communication between administrative domains. > > > While some folks seem to believe that the currently proposed protocol > is > > > suitable for both inter-gatekeeper communication and communication > > > between administrative domains, others seem to believe that these are > 2 > > > distinct problems. > > > > > > - Annex G should address inter-gatekeeper communication and > > > communication between administrative domains separately. > > > > > > - The current direction of work does not seem to consider all possible > > > architectures (hierarchical, distributed, hybrid), or at least the > > > current Annex G does not adequately describe all possible > architectures. > > > In addition, no requirements appear to guide forming Annex G for each > of > > > these possible architectures. > > > > > > Mr. Roy has promised a proposal to address some of his concerns. > > > > > > Remember that this work will progress with proposals. > > > > > > For those who were on the last call, please correct me if I've missed > > > something. > > > > > > Glen > > > > > > > > > -- > > > Glen Freundlich ggf(a)lucent.com > > > Lucent Technologies office: +1 303 538 2899 > > > 11900 N. Pecos fax: +1 303 538 3907 > > > Westminster, Colorado 80234 USA > > > >

1 0

Re: (Second Try): Contribution (Inter-GK Communications)
by Roy, Radhika R, ALTEC 20 Aug '98

20 Aug '98

> Hi Everyone: > > Here are my comments on APC-1422 Hierarchical Model Based VideoServer's > Proposal: > > <<vs_com>> > > If you have any questions, please let me know. > > Thanks and regards, > > Radhika R. Roy > AT&T, USA > Tel: +1 732 949 8657 > Email: rrroy(a)att.com >

1 0

Re: H.225.0 Annex G conference call
by Roy, Radhika R, ALTEC 20 Aug '98

20 Aug '98

Hi Everyone: It is a complete surprise! Does the ITU-T SG16 mandates that there must NOT be any standards for the "Inter-Zone" Communications in a given domain for H.323? The inter-zone communications in a given domain was discussed in all conference calls. It ia an accepted fact that we do need a standard for the 'Inter-Zone" communications in a given domain. No opposition was raised by anyone. Mr. Wiryaman, VideoServer, made this point very clearly to all of us in support of APC-1385. In fact, Mr. Wiryaman later further clearified this in his email. No opposition was raised by anyone. Why do we participate in biweekly conference calls and send our emails and waste our time, if it is thought that we have to go in a cirlcle? In the last Cannes H.323 ITU-T SG16 meeting, it was completely realized that no work would go forward if the both inter-zone and inter-domain were NOT addressed. > In Yokosuka H.323 ITU-T SG16 meeting, the very narrow area of standard > development was opposed, and APC-1385 is a proof. No one has given a > mandate that the so-called hierarchical border-GK type concept that has a > very limited applicability will be the ONLY model that everyone of us has > to follow BLINDLY without questions. And Annex-G MUST always be written > accordingly as if it has become everybody's UNQUESTIONABLE holy mandate, > and ignore everything whatever is talked in the bi-weekly conference calls > and emails. > It is the time for moving forward! H.323 has become one the most important standards that ITU-T ever produced because of its universal use in transport indpendent (i.e., not tied to IP, ATM, FR, or other transport protocols) manner. In inter-GK communications, the same UNIVERSALITY is required, NOT to limit it by raising the so-called "brick walls" that create opprtunities for proprietary implementations. We have now clear choices: Do we want to stall the standard works that do NOT address both "inter-zone" and inter-domain" communications? Or, Do we want to move forward addressing the both "inter-zone" and inter-domain" communications? If we stall the standard works for the inter-GK communications, many people may loose interest in participating H.323 ITU-T SG16 meetings, and other forums and standard bodies will take those works. And it will NOT be in the best interst of the ITU-T members. (I do not know for sure whether all companies that participate in H.323 meetings are the members of ITU-T). Therefore, it is an appeal to all of us that we should develop our standards that become UNIVERSAL for all architectural models. Thanks and regards, Radhika R. Roy AT&T, USA Tel: +1 732 949 8657 Email: rrroy(a)att.com > ---------- > From: Glen Freundlich[SMTP:ggf@lucent.com] > Reply To: ggf(a)lucent.com > Sent: Wednesday, August 19, 1998 1:18 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.225.0 Annex G conference call > > Please see my responses editted in below. > > Regards, > Glen > > > Roy, Radhika R, ALTEC wrote: > > > > Hi Everyone: > > > > I have few comments on the revised Annex G writeup. > > > > 1. The title is OK > > 2. The scope is not OK. As we talked last time that the scope should be > > extended to include the following: > > * Inter-Gatekeeper Communications within a Domain > > * Inter-Gatekeeper Communications Between (Administrative) > > Domains > > Did we have consensus on that opinion? If so, I'll change the text and I > apologize for missing that. I remember saying that the stake I was > placing in the ground was that the protocol is the same for both of > these (and some text in the annex states that). Until we have something > that shows otherwise I see no reason to change the basic direction of > the annex. > > In Yokosuka we set the focus of Annex G to be communication between > administrative domains. If we start broadening the scope we run the risk > of delaying the annex. > > > > > 3. APC-1385 provides outlines for the "Inter-Gatekeeper Communications > > within a Domain". The write-up of Annex G should be modified > accordingly. > > 4. The items 2 and 3 had been discussed in the last conference call. Are > we > > going through a circle again? > > 5. The comments on the remaining text of the document will be reviewed > when > > the fundamental direction of Annex G is put along the line as pointed > out > > above. > > > > Recent AT&T's proposed contribution has also been submitted to > complement > > the write-up in the area of "Inter-Gatekeeper Communications within a > > Domain". > > > > Thanks and regards, > > > > Radhika R. Roy > > AT&T > > Tel: +1 732 949 8657 > > Email: rrroy(a)att.com > > > > -- > Glen Freundlich ggf(a)lucent.com > Lucent Technologies office: +1 303 538 2899 > 11900 N. Pecos fax: +1 303 538 3907 > Westminster, Colorado 80234 USA >

1 0

Re: Contribution (Inter-GK Communications)
by Roy, Radhika R, ALTEC 20 Aug '98

20 Aug '98

Hi Everyone: Here are my comments on APC-1422 Hierarchical Model Based VideoServer's Proposal: It is appreciable that Mr. Santo Wiaryman, VideoServer, presented an addressing scheme that ranges from multiple zones to multiple domains. The basic idea of the addressing scheme related to the zone and the domain is the core of the proposal, and is applicable in other situations as well no matter whether the architectural model is hierarchical or non-hierarchical. The opportunities and problems that are presented are real. This contribution has increased our understanding related to the addressing scheme in the context of zones and domains. However, the addressing scheme has been applied using the model specified in APC-1422 that uses hierarchical architecture using the border GKs. In this context, the following comments will reveal the fundamental aspects of the model proposed in APC-1422 considering the insights that have provided by this proposal: 1. It appears that a sort of routing scheme(s) needs to be used for sending the addressing information from a source zone GK through a series of hierarchical border GKs up to the root border GK, and from the root border GK through a series border GKs to the destination zone GK. 2. No mechanism is proposed in the signaling messages to protect against routing loops when the "abstraction" of routing is made between the source zone GK , a series of hierarchical border GKs, and the destination zone GK. 3. Is there any inter-GK protocol messages (e.g., resource availability) needed between the zone GK and the border GK and between the border GKs other than the zone messages considering the (networking) configurations of the GKs? 4. It appears that a root border GK needs to be defined. Who will decide the root GK from which a hierarchy will be establsihed? Is it any international organization like IANA? 5. The path between the source and the destination GK is the pre-specified hierarchical logical path, and may not be optimal between the source-destination GK. 6. The signaling message only passes through the source and the destination zone GK, and other hierarchical GKs. As a result, if a call is established between the source-destination path, the call may have to pass through many "intermediate zones" in addition to the source and destination zone. Consequently, the intermediate zone GKs will be completely unable to play any roles. For example, bandwidth/QOS resources that are supposed to be allocated in each zone by each GK between the source-destination path before placing the call cannot be done. The RAS messages such as ARQ/ACF/ARJ, BRQ/BCJ/BRJ, URQ/UCF/URJ, DRQ/DCF/DRJ, RAI/RAC, and others may not be able to play proper roles for all zones between the source-destination path through which a call is established. 7. Is there any solution provided by the model described in APC-1422 if the zone boundaries become logical instead of physical? This simple example presented by VideoServer using the proposed APC-1422 model can also lead to a very high-level comparison between the hierarchical and non-hierarchical model. The following table may provide a high-level summary of comparison between the two models: Table 1: High Level Summary of Comparsion Description Hierarchical Model: APC-1422/Example VideoServer Proposal Non-Hierarchical Model: AT&T's Proposal Remarks Routing between the GKs Routing is needed: * Static routing through the pre-specified logical path * No scope for path optimization * No mechanism for avoiding loops Routing is needed: * Dynamic routing between the source-destination GKs * Path is optimized * Mechanism is provided to avoid loops * (Static routing can also be done if needed) Non-hierarchical model appears to be much superior ARQ/ACF/ARJ Bandwidth/QOS allocation cannot be confirmed because the signaling message does not pass through all zones between the source-destination path. Bandwidth/QOS allocation can be confirmed because the signaling message passes through all zones between the source-destination path Non-hierarchical model appears to be much superior BRQ/BCJ/BRJ Bandwidth/QOS change cannot be confirmed because the signaling message does not pass through all zones between the source-destination path. Bandwidth/QOS change can be confirmed because the signaling message passes through all zones between the source-destination path Non-hierarchical model appears to be much superior All RAS signaling messages that may have implications for all zones between the source-destination path of the call Signaling messages cannot pass through the intermediate zones Signaling messages can pass through all zones between the source-destination path Non-hierarchical model appears to be much superior Root-GK A root-GK needs to be defined (does it mean to have an international authority like IANA?) No need to define a root-GK Non-hierarchical model appears to be much superior Logical zone boundary Probably cannot be defined (may be limited to physical zone boundaries only) Can be defined (in addition to physical one) Non-hierarchical model appears to be much superior If you have any questions, please let me know. Thanks and regards, Radhika R. Roy AT&T, USA Tel: +1 732 949 8657 Email: rrroy(a)att.com

1 0

Diameter update
by Nancy-M Greene 19 Aug '98

19 Aug '98

For anyone attending the IETF meeting next week that is interested in learning more about Diameter: There will be a presentation of Diameter at the Chicago IETF meeting during the AAA BOF, on Friday, August 28th at 9:00am. Why is this of interest to SG16? The Diameter framework could be a candidate for the protocol used in GK to GK communication. The status of Diameter within the IETF should be clearer by the end of next week (i.e. after the IETF meeting in Chicago). I'll update this group at that time. Nancy -------------------------------------------------------------------------- Nancy Greene (internally Nancy-M Greene) PDN standards, Nortel T:613-763-9789 (internally ESN393-9789) E:ngreene@nortel.com

1 0

Re: Other mailing lists?
by Mark Duckworth 19 Aug '98

19 Aug '98

Venu, Yes, there is a separate mailing list for Q3/SG16, the T.120 group. The list is t120-interest(a)imtc.org. To subscribe to this list, just send an email message to majordomo(a)imtc.org in the message body simply write "subscribe imtc-t120 (email address)" To unsubscribe yourself from the list, send an email message to majordomo(a)imtc.org in the message body simply write "unsubscribe imtc-t120 (email address)" Mark Venu Madhav Kailasa <kvm(a)TRILLIUM.COM> on 08/19/98 02:20:13 PM Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)MAILBAG.INTEL.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM cc: (bcc: Mark Duckworth/PicTel) Subject: Other mailing lists? Hi, Are there any other mailing lists, other than this one, where SG16 work is discussed? Any info is appreciated. Thanks, Venu

1 0

Other mailing lists?
by Venu Madhav Kailasa 19 Aug '98

19 Aug '98

Hi, Are there any other mailing lists, other than this one, where SG16 work is discussed? Any info is appreciated. Thanks, Venu

1 0