Contribution (Inter-GK Communications)

Roy, Radhika R, ALTEC rrroy at ATT.COM
Thu Aug 20 17:19:24 EDT 1998


My comments are enclosed.

Thanks and regards,

Radhika R. Roy
AT&T

> ----------
> From:         Tom-PT Taylor[SMTP:Tom-PT.Taylor.taylor at NT.COM]
> Reply To:     Mailing list for parties associated with ITU-T Study Group
> 16
> Sent:         Thursday, August 20, 1998 2:16 PM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      Re: Contribution (Inter-GK Communications)
>
> 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) [Radhika: It depends what kind
> of solutions we are looking for. If one has to get around that, something
> will be lost in the pocess. So, there can be different kinds of solutions.
> One model can get around that, while the other one should not. We need to
> work for all options.]
>  - 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.
> [Radhika: Yes, you are right. Now the question is where the resource
> information resides. At zone level, the resource information resides at
> the GK level.Therefore, to abstract the resource information for all
> zones, all zones need to be involved. One way of doing is that we can use
> the "inter-zone" model as proposed in AT&T contribution. For adm part, the
> zone level info can abstracted to the domain. The bottom line is that a GK
> of a given zne is the repository for all information in H.323. How to
> abstract is is a different matter.]
>
> My further comments are interspersed with those of Mr. Roy.
>
> Tom Taylor
>
> > -----Original Message-----
> > From: Roy, Radhika R, ALTEC [SMTP:rrroy at ATT.COM]
> > Sent: Thursday, August 20, 1998 12:35 AM
> > To:   ITU-SG16 at 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. [Radhika: TTL is not sufficient. I
> guess that 'pathValue' parameter has been proposed to get around that
> problem. The question is whether or not the model proposed in APC-1422
> should be kept in a "limited environment" so that more flexible models
> need to be evolved later for both hierarchical and non-hierarchical
> model.]
>
> > 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.
> [Radhika: My discusssion has been limited to the RAS signaling messages
> only (not the media path) because the GKs will be handling the mandatory
> RAS signaling messages. So, the signaling messages will always follow the
> per-defined hierarchical logical path between the GKs. The routing
> decision between the GKs will be made at the GK level, whereas the rotuing
> decison btween the two GKs (e.g., there may be many routers/switches
> between the two GKs) will be made at the network 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.[Radhika: Please note that H.323 also envisions there may be
> multiple GKs between the endpoints. Now the communications in multiple-GK
> environment have not been addressed adequately. That is why, we are
> working so deligently to solve the inter-GK communications problems. The
> authorization level can be made abstracted from each zone-GK level to the
> administrative level as well if needed for intra-domain communications,
> and/or there can be a central adm server for the domain as you have
> envisioned. It depends how an architecture is created. Again, in H.323,
> all information resides in the GK level.]
>
> > 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. [Radhika: Logical zone boundary means that
> physical boundaries of the H.323 entities may be the same (may even the
> same network and the same physical space), but the H.323 entities may
> belong to different GKs. An analogy can be shown in the case of "Virtual
> LAN" and other model.]
>
> > 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 at att.com
>



More information about the sg16-avd mailing list