Subject: Re: Receiving ATM SETUP message at the MG

From: [email-masked]
Date: Sun, 28 Nov 1999 21:01:02 +0100

Brian and Thomas,
Introducing H248 within the BICC context is something we are all waiting for but unfortunately I don't believe the interface betwwen the CSF and the BCF could be megaco...I have the impression that megaco should take place somewhere between the CSF + part
of BCF-N and the interworking unit.
Because ATM is a connection oriented protocol, the interworking unit need some feedback from the BCF-N to allocate a VPI/VCI to a connection. this cannot be done through the CSF but at the same time only the CSF has a knowledge of an incoming call and the
circuit attached to it.
What is your feeling??? Would think having megaco between the CSf and the BCF-N is straigthforward?
Ameneh
Alcatel
[email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 29 Nov 1999 13:59:44 -0500

> This question was raised by the work currently going on in
> ITU-T on Q.BICC
> (I'm sure you've heard of it). As you probably know, the
> first release of
> BICC (which should be determined in 2 weeks) supports only
> ATM at what ITU-T
> calls "BCF" (i.e. MG in Megaco parlance). They also have
> defined a BNC-ID
> used to correlate between the Q.BICC messages used for Call
> Setup and the
> ATM Signalling messages used for Connection Setup. The BNC-ID
> is included in
> ATM SETUP messages and supposedly used for correlation upon
> reception of the
> SETUP.
Yep, I know all about Q.BICC.  I believe it will be Megaco that
is used between an entity implementing decomposed ISNs.  The
unfortunate differences in functional splits between MG/MGC and
BCF/CSF will be ignored by the market.  Megaco can do the job,
and is upward compatible for further development.  I think the
market will beat down any attempt to create alternatives that are
different for no good reason.

> Looking at the BICC Call Flows, and anticipating the fact we
> will want to
> use Megaco/H.248 between CSF and BCF (MGC/MG), I am wondering
> what an MG is
> supposed to do when it receives an ATM SETUP message :
> Is it supposed to reply with a CONNECT, and create an ATM
> termination by
> itself? In that case, in what context is this ATM termination
> put? Is a new
> context automatically created on reception of the SETUP
> message or is the
> ATM termination put in the NULL context, while the MG waits
> for instructions
> from the MGC?
A package will have to be created that exactly defines what happens.
There is an Internet Draft from Nortel with some ideas on the subject.
Generally, the MGC will either ask the MG for a BNC-ID, or give it one
it makes up.  I'd expect a context will be created in advance, the BNC-ID
will be known by the MG, and when the SetUp arrives, it will inform the
MGC by a Notify.  In a forward call flow, the MG getting the SETUP will
know the AESA of the originating MG, but in both cases, it will use the
BNC-ID.

> In the case of BICC backward call setup flows, the MG which
> receives the ATM
> SETUP message already contains the "Context" where this ATM
> termination
> should be put. Unfortunately, the only way the MG could know where to
> include the ATM Termination would be by using the BNC-ID
> included in the
> SETUP message... Is that something an MG should be able to do
> (considering
> it knows the different BNC-IDs it may receive), or should
> such correlation
> work only be done by an MGC?
> Thanks in advance for your help.
I think the MG will match the BNC-ID to know which context is being
referred to.  The only problem for backward is that the MG won't be
given any address nformation before the context is created, and the
setup arrives.  All the rest of the Remote descriptor is known in advance,
since BICC does not depend on capability negotiation, but rather
provisioning.  Therefore, the MGC can set up an ephemeral termination
to expect the SETUP in advance, ommitting only the AESA or VPI/VCI.

Brian

---

From: Selvam Rengasami <[email-masked]>
Date: Tue, 30 Nov 1999 11:12:37 -0500

Christian or Brian,

Two questions regarding BICC interworking:

1.  Where can we get a copy of this Nortel proposal regarding the BNC-ID

2.  I am proceeding with the assumption that in general the BNC-ID is different
from the Ephemeral Termination ID for the corresponding ATM connection.

Can you provide clarification on these two points.

Thank you.

-Selvam Rengasami

Telcordia Technologies
Tel:  +1 732 758 5260

Christian Groves <[email-masked]> on 11/30/99 09:39:33 AM

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

To:   [email-masked]
cc:    (bcc: Selvam Rengasami/Telcordia)
Subject:  Re: Receiving ATM SETUP message at the MG

G'Day all,

I believe that Megaco fits the BICC architecture with no problem. A new
package will of course have to specified. The Nortel proposal of BNC-ID
is just one example of a binding reference. There may be more
appropriate methods.

This use of H248 with BICC has been raised to ITU SG11 and is being
considered.

Regards, Christian

"Rosen, Brian" wrote:
>
> I agree that with the current definition of the split in functions between
> CSF and BCF that Megaco doesn't quite fit.  However, we plan to make MGs
> and MGCs that use Megaco and BICC, ignoring the unfortunate differences
> in definitions.
>
> There is a proposal from Nortel on how to implement the BNC-ID.  I think
> the issue is very straightforward.
>
> Brian
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]
> > Sent: Sunday, November 28, 1999 3:01 PM
> > To: [email-masked]
> > Subject: Re: Receiving ATM SETUP message at the MG
> >
> >
> > Brian and Thomas,
> > Introducing H248 within the BICC context is something we are
> > all waiting for but unfortunately I don't believe the
> > interface betwwen the CSF and the BCF could be megaco...I
> > have the impression that megaco should take place somewhere
> > between the CSF + part
> > Because ATM is a connection oriented protocol, the
> > interworking unit need some feedback from the BCF-N to
> > allocate a VPI/VCI to a connection. this cannot be done
> > through the CSF but at the same time only the CSF has a
> > knowledge of an incoming call and the
> > circuit attached to it.