Subject: Re: new ID draft-bouwen-megaco-isdn-00.txt

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 14 Mar 2000 08:45:27 -0500

I've read through this I-D.  It contains a wealth of information
and ideas.  I haven't seen you announce it on SIGTRAN, I believe
you should, although since I copied this message to SIGTRAN,
I seem to have done this for you :)

If you propose this as a Megaco work item, I would suggest that
most of the options be eliminated, leaving exactly one way to
handle ISDN.  I believe that any of the "carry Q.931 in Megaco"
ideas are not appropriate - SCTP is of not much more complexity than
TCP, and residential gateways should not have any difficulty in
having to implement SCTP.

Some other comments:
1. I have always been in favor of naming conventions.  This one
has the "ISDNterm" prefix.  I find it completely useless.
I don't think there is any advantage in having a naming convention
for the trunk name, other than some kind of length limit and possible
character set limit.  The useful part is to name the B/D channels.

2. I'd be interested in the SIGTRAN groups opinion of how Q.921
Management is best accomplished.  I rather doubt they would see it
as a Megaco issue.  Yet I have not seen these issues raised, and
agree that there must be a way to do it.

3. I did like the association between SCTP session management
and MEGACO control association management.  I agree that we need
this documented, and think you have a good starting point.

4. I have pondered whether the MGC ought to command the MG to
establish SCTP associations for D channels, or whether the MG
ought to just know it should do so and do it.  You have given
me more info to think about here.  The D channel packet data
problem is one I was dimly aware of, but had not really thought
through.

5. I think an ISDN package will be required, and the audit
capabilities you describe seem useful.  I might want to rework
how you are reporting them.  This raises an issue I should know,
but proclaim my ignorance for all to see: how does the PSTN assign
a D channel, that is, who knows which channels are D channels, and
how are they assigned?  By provisioning, by convention, by
inspection of bit patterns?.  I'm most used to convention, but
probably that is just the user side.

6. I think we should decide which end gets provisioned with things
like Interface Identifier or Associated D-channel.  I'd prefer this
be an MGC thing, with the MG being told what to do if it has to be.
You seem to assume it's the MG that is provisioned, and need to
let the MGC know.  This deserves discussion.

7. The layer 1 stuff is needed.  Again I look for comments from
the SIGTRAN folks - is this really something handled by
Megaco?  The coupling to ServiceChange is interesting, and I
suspect useful to document.

8. I do think events are appropriate for Performance Grading.
Similar events exist for other QoS problems.

9. Section 9.4 contains the gem of a new thread - on line
provisioning changes, and how systems react.  Again, I see this
as something the OSS tells the MGC, not the MG, but others may
have different opinions.

Brian
------------
Brian Rosen, Principal Engineer
Marconi (Formerly FORE Systems)
1000 FORE Drive, Warrendale, PA 15086
(724) 742-6826  mailto:[email-masked]

> -----Original Message-----
> From: Bart Van Doorselaer [mailto:[email-masked]]
> Sent: Tuesday, March 14, 2000 3:42 AM
> To: [email-masked]
> Subject: FYI: new ID draft-bouwen-megaco-isdn-00.txt
>
>
> "Issues for Megaco - Sigtran Interworking in ISDN Access
> Gateways ", Jan
> Bouwen, Bart Van Doorselaer, Miek Dekeyser, 03/13/2000. (71198 bytes)
>
> http://www.ietf.org/internet-drafts/draft-bouwen-megaco-isdn-00.txt
>
> This document introduces the concept of an ISDN access gateway in the
> context of Megaco/H.248 and Sigtran protocols. For these ISDN access
> gateways, the ISDN B channels may be controlled by the Media Gateway
> Controller using megaco/H.248 while the User-to-Network signaling
> running over the D channels may be relayed to the Media Gateway
> Controller using either megaco/H.248 or the Sigtran
> protocols. The main
> issues involved are:
> * Megaco/H.248 and Sigtran protocols may interwork in
> different ways in
> ISDN access gateways, leaving room for non - interoperable solutions;
> * Megaco needs additional packages in order to support ISDN
> terminations
> in the ISDN access gateway;
> * A data service may be offered to ISDN users via the ISDN D- channel,
> introducing the need to introduce a NAS package for the D-channel.
> This document addresses these issues, proposes and explains different
> solutions and suggests best practice guideline for megaco / sigtran
> interworking in ISDN access gateways.
>
>
> Enjoy the reading.
>
>
> --
>                                               ____________________
> Bart Van Doorselaer                           \                  /
> _______________________________________________\                /____
>                                                 \              /
> Research Engineer                                \  ALCATEL   /
> DN2                                          Network Strategy Group
> Tel   : +32 3 240 86 41                      Francis Wellesplein  1
> Fax   : +32 3 240 99 32                     B-2018 Antwerpen Belgium
> _____________________________________________________\    /__________
> mailto:[email-masked]                 \  /
>                                                        \/
>