Subject: Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 10 Jan 2000 21:43:29 -0500

This is a timely intervention.  Before sending the requirements off to the
IESG I wanted to do one last check of the archives.  I found a great deal of
responsiveness to Matt's concerns, but not complete capitulation.  I think
the proof of the wisdom of these requirements will be found in the packages
which emerge to meet them.  In any event we aren't going to be held up in
the way Matt feared.  I am therefore going to send the requirements document
in to the IESG as it stands.

What follows is totally optional reading, but might make sense out of past
debates.

Fundamentally, I think we are all agreed (including Matt) that Megaco must
work within the following logical control architectures:

(1) NAS connects directly to AAA

>              +-------+        +-------+
>   Signaling  |       |        |       |
>   -----------+  MGC  +        |  AAA  |
>              |       |        | server|
>              +---+---+        +--+----+
>                  | Megaco       /
>                  |             /
>              +---+---+        /
>              |       |   AAA /
>              |  NAS  +------/
>              |       |
>              +-------+
>

(2) MGC proxies AAA

>              +-------+        +-------+
>   Signaling  |       |  AAA   |       |
>   -----------+  MGC  +--------|  AAA  |
>              |       |        | server|
>              +-+-+---+        +--+----+
>          Megaco| |AAA
>                | |
>              +-+-+---+
>              |       |
>              |  NAS  |
>              |       |
>              +-------+
>

The first case places the requirement on Megaco to be able to transport
anything which could be received in or derived from call signalling which is
needed for NAS operation, in addition to local policy.  The second case is
the same as the first case if the NAS initiates the AAA transaction.

The second case introduces novel elements if the MGC is the one to initiate
the query to the AAA server.  There are two possibilities, both of which
have their challenges:

(1) The response leg of the AAA transaction is passed through to the NAS
using an existing AAA protocol.  In this case Megaco has to have the means
to tell the NAS that this information is coming, and to allow the NAS to
correlate it with the related Megaco transactions.  The correlating
information clearly depends on the particular AAA protocol being used, so we
can look forward to separate packages corresponding to the respective
protocols.  Goutam has suggested, I believe, the alternative that
correlation is achieved by proximity, by tunneling the AAA protocol within
the confines of a Megaco command.

(2) The response leg of the AAA transaction is translated to a Megaco
equivalent.  This leads to the bottomless swamp of protocol duplication Matt
warns about, except that it may not be necessary to pass everything in the
AAA response down to the NAS.  Some information may go no further than the
MGC.  This approach seems to be implicit in some of the requirements Nancy
has defended.

> -----Original Message-----
> From: Goutam Shaw [SMTP:[email-masked]]
> Sent: Monday, January 10, 2000 6:11 PM
> To:   [email-masked]
> Subject:      Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt
>
> Nancy, I'm sorry for the delayed reply. I thought we had put this matter
> to rest once and for all after we had the conf. call that was attended by
> Nancy, Myself, Matt and I think Gunner.
> According to my opinion what we have in the requirements is not AAA. These
> are configuration parameters that are call specific and have to be
> conveyed to the MG before the call is terminated and SHOULD NOT AND CANNOT
> BE dealt by a AAA server. The parameter should help determine how the call
> is supposed to be treated and has nothing to with "AAA".
> I would like to keep section d (of draft-ietf-megaco-reqs-10.txt)  as it
> is, that relates to the ability to configure the call adaptation rate. For
> example, for a given call a service provider might want to restrict the
> call to 28.8 kbps based on the call specific policy information.
>
> As Tom has mentioned we don't need a unanimous decision all we need is a
> consensus and I believe we have it (unless I hear any major objection from
> the mailing list which I haven't heard in the past on this topic).
>
> Regards,
> ..Goutam.
>
> Nancy-M Greene wrote:
>
>
>
>       Matt,
>       Megaco/H.248 is a device control protocol. It is true that for NAS,
> we allow the MG itself to contact the AAA server. Yet, there will be
> implementations that would have the MGC contact the AAA server. The
> requirements in this section allow for the development of a NAS package IN
> THE FUTURE, that would allow the information returned from the AAA server
> to be passed down to the MG. How this package would be written is NOT
> specified in this requirements document.
>
>       As for your comment that ALL your comments regarding the NAS section
> have been ignored, this is simply not true! Your comments have been
> discussed several times on the mailing list. As editor, I have tried to
> come up with compromise text again and again, and every time, you come
> back saying I haven't yet succeeded in satisfying your wishes.
>
>       Perhaps it is time for the chair to step in and see if we have rough
> consensus on the requirements document or not.
>
>       Your comment on 11.2.1 D is correct. 11.2.1 D will be removed from
> the requirements document.
>
>       Also, I don't understand your comment that the requirements document
> should change, based on recent discussions of the protocol. We did update
> the requirements document based on discussion at the Washington meeting.
> Tom is planning to put out a companion I-D that maps the Megaco/H.248
> protocol against the requirements document.
>
>       Nancy
>
> --------------------------------------------------------------------------
>
>       Nancy M. Greene
>       Internet & Service Provider Networks, Nortel Networks
>       T:514-271-7221 (internal:ESN853-1077) E:[email-masked]
>
>               ----------
>       From:   Matt Holdrege[SMTP:[email-masked]]
>       Sent:   Thursday, December 23, 1999 12:00 PM
>       To:     [email-masked]
>       Subject:        Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt
>
>               It's sad to see that all my comments regarding the NAS
> section have been
>       ignored again. So let's go through them one more time and I'll try
> to put
>       more detail into my comments.
>
>               At a high level, NAS requirements should be set by the NAS
> requirements
>       working group. That's where the experts are. Also, it's easy to see
> that
>       there are NO specific NAS requirements for MEGACO. For the basic
> purposes
>       of MEGACO, a NAS is no different than a VoIP gateway. I can see how
> you may
>       want to do some special things with special packages, but nothing in
> the
>       base protocol needs to be NAS specific.
>
>               So let's go through the NAS requirements step by step...
>
>               A. Callback. This is all that's listed. There are many
> aspects to callback
>       which are covered by RADIUS and are a part of the new AAA
> requirements. If
>       all you can list is callback, you should remove this requirement and
> leave
>       it up to AAA where it belongs.
>
>               B. Modem types. This is also handled by RADIUS and AAA. The
> MG contacts the
>       AAA server to instruct it on which modem to use. Remember that the
> MGC and
>       MG are not necessarily in the same management domain. But the MG
> DOES trust
>       it's AAA server. So that is where the information must come from and
> it
>       works best if it is transmitted directly. If you introduce a proxy,
> you
>       introduce a lot of difficulties. The AAA WG is trying to deal with
> the
>       difficulties of proxy and we shouldn't jump ahead of them.
>
>               C. D. E. F. These requirements can and should be covered by
> a single
>       sentence. The Protocol must be able to support Q.931 IE's. F already
> kind
>       of says this. Please be succint and less tutorial. Q.931 IE's are a
> basic
>       requirement of all MG's. Not just NAS's.
>
>                >g.   Ability for the MGC to direct the NAS to connect to a
> specific tun-
>        >     nel, for example to an LNS, or to an AAA server.
>
>               There are a multitude of tunnel types on the Internet. L2TP,
> IPsec, IPinIP,
>       IPSRA, RSIP, GRE, PPTP, ATMP, etc. These tunnel types are not all
> the same.
>       They are handled in different IETF working groups that have defined
> their
>       operation and their setup. The MEGACO WG should not be dictating how
>
>       tunnels get set up. Working groups such as L2TPEXT have defined
> RADIUS to
>       setup their tunnels.
>
>               H. This is already covered in the VoIP section. Reproducing
> requirements is
>       just adding confusion.
>
>               You mention that wiretapping has been removed, yet it is
> still in 11.2.1 D.
>       Whether the MEGACO protocol allows wiretap or not, I don't think we
> want
>       this specific requirement in an RFC. This was discussed at the
> Washington
>       plenary.
>
>               Lastly, I think this document should go through a more
> lengthy last call
>       since we are in the holiday time. We've gone into detail at the last
> two
>       meetings on the protocol itself and this requirements document
> doesn't
>       accurately reflect that.
>
>               At 09:41 AM 12/10/99 -0500, Tom-PT Taylor wrote:
>
>               >I propose WG Last Call based on this document, with the
> expiry two weeks
>       >hence (24 December).
>       >
>       >Changes from the previous version are as follows:
>       >
>       >- removed reqt 5.6 c) Support general test capabilities, for
> example
>       >loopbacks through the MG to test DSP operation.
>       >It was agreed that inward loopbacks are outside the scope of the
> protocol
>       >- they are not part of call control, so would be handled by some
> other
>       >maintenance protocol. Thus the above requirement is deleted.
>       >
>       >- reqt 5.7 a) - changed word call to connection
>       >
>       >- table in section 11 - removed  wiretap
>       >
>       >- reqt 11.1.3.1 a) rewording of 2nd bullet  on addressing - didn't
> mean
>       >wildcarding, meant instead allowing the gateway to choose (part of)
> the
>       >identifier
>       >
>       >The references need to be completed still, and there may be an
> editor's
>       >note or two that should still come out.
>       >-----Original Message-----  From:   [email-masked]
>       >[SMTP:[email-masked]]  Sent:   Friday, December 10, 1999
> 8:08
>       >AM  To:     [email-masked]  Subject:
> I-D
>       >ACTION:draft-ietf-megaco-reqs-09.txt
>       >
>       >A New Internet-Draft is available from the on-line Internet-Drafts
>       >directories.  This draft is a work item of the Media Gateway
> Control
>       >Working Group of the IETF.
>       >
>       >         Title           : Media Gateway control protocol
> architecture
>       > and                            requirements          Author(s)
> : N.
>       > Greene,  M. Ramalho,  B. Rosen          Filename        :
>       > draft-ietf-megaco-reqs-09.txt          Pages           :
>       > 45          Date            : 09-Dec-99
>       >
>       >TThis document describes protocol requirements for the Media
> Gateway
>       >control protocol between a Media Gateway Controller and a Media
> Gateway. A
>       >URL for this Internet-Draft
>       >is:
>       ><
> <http://www.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt>>
> <http://w>
>       >ww.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt
>       >
>       >Internet-Drafts are also available by anonymous FTP. Login with the
>
>       >username  "anonymous" and a password of your e-mail address. After
> logging
>       >in,  type "cd internet-drafts" and then          "get
>       >draft-ietf-megaco-reqs-09.txt".
>       >
>       >A list of Internet-Drafts directories can be found
>       >in  < <http://www.ietf.org/shadow.html>>
> <http://www.ietf.org/shadow.html>  or
>       >< <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>>
> <ftp://ftp.ietf.org/ietf/1shadow->
>       >sites.txt
>       >
>       >Internet-Drafts can also be obtained by e-mail.
>       >
>       >Send a message to:          [email-masked].  In the body
>       >type:          "FILE
> /internet-drafts/draft-ietf-megaco-reqs-09.txt".
>       >
>       >NOTE:   The mail server at ietf.org can return the document
>       >in          MIME-encoded form by using the "mpack" utility.  To use
>
>       >this          feature, insert the command "ENCODING mime" before
> the
>       >"FILE"          command.  To decode the response(s), you will need
>       >"munpack" or          a MIME-compliant mail reader.  Different
>       >MIME-compliant mail readers          exhibit different behavior,
>       >especially when dealing with          "multipart" MIME messages
> (i.e.
>       >documents which have been split          up into multiple
> messages), so
>       >check your local documentation on          how to manipulate these
> messages.
>       >
>       >Below is the data which will enable a MIME compliant mail
>       >reader  implementation to automatically retrieve the ASCII version
> of
>       >the  Internet-Draft. << Message:  >>
>  << File: Card for Goutam Shaw >>

---

From: "Rasin, Mark (M.) [SMTPPART:LOD:Telrad]" <[email-masked]>
Date: Tue, 11 Jan 2000 10:05:56 +0200

Is it possible to have the following logical control architecture as well?

                               |
              +-------+                  +-------+
   Signaling  |       |        |         |       |
   -----------+  MGC  +                  |  AAA  |
              |       |        |         | server|
              +---+---+                  +---+---+
                  | Megaco     |             | AAA
                  |                          |
              +---+---+        |         +---+---+
              |       |  L2TP            |       |
              |  NAS  +--------|---------+  LNS  |
              | (LAC) |                  |       |
              +-------+        |         +-------+

                PSTN           |           ISP

   If yes, is it supposed to support it by the same NAS package or
a separate LAC package will be required?

--
=========================================================================
 Mark Rasin, Senior S/W Engineer       Telrad Networks, Nortel SBU
 e-mail: [email-masked]       P.O.Box 50 Lod 71100, Israel
 Voice: +972.8.913.4084 ESN/828-4084   Fax: +972.8.913.4914 ESN/828-4914
=========================================================================

>>>>> "Tom" == Tom-PT Taylor <[email-masked]> writes:

    Tom> This is a timely intervention.  Before sending the requirements off to the
    Tom> IESG I wanted to do one last check of the archives.  I found a great deal of
    Tom> responsiveness to Matt's concerns, but not complete capitulation.  I think
    Tom> the proof of the wisdom of these requirements will be found in the packages
    Tom> which emerge to meet them.  In any event we aren't going to be held up in
    Tom> the way Matt feared.  I am therefore going to send the requirements document
    Tom> in to the IESG as it stands.

    Tom> What follows is totally optional reading, but might make sense out of past
    Tom> debates.

    Tom> Fundamentally, I think we are all agreed (including Matt) that Megaco must
    Tom> work within the following logical control architectures:

    Tom> (1) NAS connects directly to AAA

    Tom> (2) MGC proxies AAA

    Tom> The first case places the requirement on Megaco to be able to transport
    Tom> anything which could be received in or derived from call signalling which is
    Tom> needed for NAS operation, in addition to local policy.  The second case is
    Tom> the same as the first case if the NAS initiates the AAA transaction.

    Tom> The second case introduces novel elements if the MGC is the one to initiate
    Tom> the query to the AAA server.  There are two possibilities, both of which
    Tom> have their challenges:

    Tom> (1) The response leg of the AAA transaction is passed through to the NAS
    Tom> using an existing AAA protocol.  In this case Megaco has to have the means
    Tom> to tell the NAS that this information is coming, and to allow the NAS to
    Tom> correlate it with the related Megaco transactions.  The correlating
    Tom> information clearly depends on the particular AAA protocol being used, so we
    Tom> can look forward to separate packages corresponding to the respective
    Tom> protocols.  Goutam has suggested, I believe, the alternative that
    Tom> correlation is achieved by proximity, by tunneling the AAA protocol within
    Tom> the confines of a Megaco command.

    Tom> (2) The response leg of the AAA transaction is translated to a Megaco
    Tom> equivalent.  This leads to the bottomless swamp of protocol duplication Matt
    Tom> warns about, except that it may not be necessary to pass everything in the
    Tom> AAA response down to the NAS.  Some information may go no further than the
    Tom> MGC.  This approach seems to be implicit in some of the requirements Nancy
    Tom> has defended.