Subject: Re: About creating contextID and terimnationID

From: Sandeep Gautam <[email-masked]>
Date: Tue, 5 Sep 2000 19:09:32 +0530

Hi List!
Sorry to be late on the subject, but my doubts:-

Why shouldnt partially specified names be allowed for ephemeral terminations.
The assumption is that for ephemeral terminations there is only one pool from
which all ephemeral terminations can be created. But suppose that I have two
ethernet ports- one of them is on a wan with normal IP nos and the other is
connected to my LAN and has local IP nos. on its subnet. Now I think it makes
sense for the MGC to tell MG as to which IP ports to use for creating the
ephemeral termination. For eg just l;ike TRUNK1/xxx for physical terminations,
we can have RTP_IP1/xxx for requesting that the ephemeral be created on that
particular IP and port no. combination. Of course we can specify the IP
addresses in Local and Remote descriptors, but this can also be one way.

Again I may have two network connections. One of them assures me a QOS based on
some transport/network layer QOS protocols. MGC can use a naming schema to
partially specify on which network the ephemeral termination be created.
Cant we have pools of RTP ehemeral termination ids( not yet created, but
potential) and let the MGC specify as to from which pool the MG should create
the ephemeral termination?

Again I am not sure but if we use ephemeral terminations to make ATM aal2
connections, maybe we might have pools there also.

Regards,
Sandeep Gautam

Christian Groves <[email-masked]> on 08/31/2000 05:52:32 AM

Please respond to Christian Groves <[email-masked]>

To:   [email-masked]
cc:    (bcc: Sandeep Gautam/HSS)

Subject:  Re: About creating contextID and terimnationID

G'Day Brian,

I think this seems like a resolution to the issue. Do you think this is
something for the implementor's guide? If so can you suggest some text?

Cheers, Christian

"Rosen, Brian" wrote:
>
> Okay, I believe that the MG instantiates all terminations,
> and when it instantiates them, it names them.  For physical
> terminations, this is done at boot time.  For ephemeral
> terminations, it is done when it is requested, via an Add.
>
> I think that in all cases, the MGC specifies CHOOSE for
> an ephemeral, and the MG obliges by creating the termination,
> and creating an ID.  I think this is best because then
> the MG uniformly creates names, and the MGC uniformly
> uses the names the MG defines.
>
> I think that there is no advantage in allowing the MGC to
> create a terminationId for ephemerals, and there is
> substantial simplicity to the MG to always be the
> creator of terminationIds and ContextIds.
>
> Brian
>
> > -----Original Message-----
> > From: John Segers [mailto:[email-masked]]
> > Sent: Wednesday, August 30, 2000 9:00 AM
> > To: [email-masked]
> > Subject: Re: About creating contextID and terimnationID
> >
> >
> > Brian,
> >
> > You seem to distinguish between creating and specifying Ids,
> > but I don't
> > understand the distinction.  Can you elaborate?
> >
> > I agree with your text for physical terminations, but I'm not sure it
> > isn't valid to have the MGC use a specific Id to create an ephemeral
> > termination.
> >
> > John
> >
> > "Rosen, Brian" wrote:
> > >
> > > Hmmm
> > >
> > > The original question was "who creates Ids".  I believe
> > it's always the
> > > MG that creates Ids.  For example, the MGC can never specify the
> > > TerminationId in an Add for an ephemeral.  Clearly, the MGC never
> > > specifies the ContextId for a previously non-existing Context.
> > >
> > > Your issue seems to be who specifies Ids.
> > >         For physical terminations, I agree that the MGC can
> > specify one,
> > >                 or it can specify CHOOSE, in which case the MG will
> > >                 pick one
> > >         For ephemeral terminations, I believe the MG always
> > specifies one,
> > >                 so that the MGC must always specify CHOOSE.
> > >
> > > We could clear up the language you cite to make this clearer.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: John Segers [mailto:[email-masked]]
> > > > Sent: Wednesday, August 30, 2000 8:26 AM
> > > > To: [email-masked]
> > > > Subject: Re: About creating contextID and terimnationID
> > > >
> > > >
> > > > Brian,
> > > >
> > > > It just so happens that I looked at section 7.2.1 (Add)
> > and found the
> > > > following text:
> > > >
> > > > > The TerminationID specifies the termination to be added to
> > > > the Context.
> > > > > The Termination is either created, or taken from the
> > null Context.
> > > > > For an existing Termination, the TerminationID would be
> > specific.
> > > > > For a Termination that does not yet exist, the TerminationID is
> > > > > specified as CHOOSE  in the command. The new
> > TerminationID will be
> > > > > returned.
> > > >
> > > > This text is not particularly clear, but seems to say
> > that specific
> > > > physical Terminations are designated in Add commands, while
> > > > CHOOSE must
> > > > be used for ephemerals.
> > > >
> > > > In my opinion we shouldn't have this restriction in the
> > protocol: in
> > > > some situations you may want to have the MG select a termination
> > > > (outgoing circuit within a trunk), in some you have to specify the
> > > > termination (access GW with subscriber lines).
> > > >
> > > > It may make sense to have profiles impose such restrictions.
> > > >
> > > > Cheers,
> > > >
> > > > John
> > > >
> > > > Brian Rosen wrote:
> > > > > No, the MG creates Contexts, and their IDs, as well as all
> > > > TerminationIds (both
> > > > > physical and ephemeral).  It is not possible for the MGC to
> > > > create contextIds or
> > > > > terminationIds.
> > > > >
> > > > > Brian
> > > >
> > > >
> > > >
> > > > --
> > > > John Segers                                  email:
> > [email-masked]
> > > > Lucent Technologies
> >  Room HE 303
> > > > Dept. Forward Looking Work                      phone:
> > +31 35 687 4724
> > > > P.O. Box 18, 1270 AA  Huizen                      fax:
> > +31 35 687 5954
> > > >
> >
> > --
> > John Segers                                  email: [email-masked]
> > Lucent Technologies                                        Room HE 303
> > Dept. Forward Looking Work                      phone: +31 35 687 4724
> > P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
> >