Subject: draft-levy-megaco-mgdiscovery-01.txt,

From: Thomas LEVY <[email-masked]>
Date: Mon, 20 Nov 2000 14:53:02 +0100

All,

You will find enclosed the revision of the internet draft "Megaco/H.248
Media Gateway Resources Discovery".
It has been enhanced in accordance to comments received on the initial
version.
It also shortly raises the issue of the relationship between the draft
and the SDP-ng activities on Capability Description.

The impacted points in the document are :
-Addition from "7.4 Implementation considerations" and "8. Conclusion"
parts.
-Very minor editorial corrections.

Please let me know, if you have any comment,

Thomas,

Megaco Working Group                                             T.Levy
                                                           L-P.Anquetil
Internet Draft                                                  Alcatel
Document: draft-levy-megaco-mgdiscovery-01.txt            November 2000
Category: Informational

             Megaco/H.248 Media Gateway Resources Discovery

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   progress."
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

1. Abstract

   This document addresses the need for a Media Gateway Controller
   (MGC) to be informed from the media resources of its Media Gateways
   (MG) in the context of the Megaco/H.248 protocol. The draft
   discusses alternative solutions for an effective media gateway
   resources discovery mechanism.
   The document is provided as an informational draft for discussion
   within the Megaco Working Group.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [2].

3. Abbreviations

   MG: Media Gateway
   MGC: Media Gateway Controller
   SNMP: Simple Network Management Protocol
   SDP: Session Description Protocol

Levy, Anquetil     Informational - Expires May 2001                  1

                       Media Gateway Discovery          November 2000

4. Introduction

   Megaco/H.248 protocol [3] stands as a Media Gateway Control Protocol
   between MGC and MG. Each MG owns a limited amount of resources
   (hardware and software) potentially realizing media processing. As
   an MGC may control a set of MGs, an efficient control requires a
   precise knowledge (qualitatively and quantitatively) of the MG’s
   resources.

   The draft firstly justifies why Megaco/H.248 is the candidate for a
   media gateway resources discovery mechanism. It then compares
   alternative mechanisms to solve this issue.

5. Justifications

   The RFC 2805 [4] describes requirements for the Megaco/H.248
   protocol. Section 6.1 deals with Resource Status Management. A
   requirement of the protocol is to "Provide an MG Resource Discovery
   mechanism which must allow an MGC to discover what resources the MG
   has".

   A solution could rely on SNMP between MGC and MG to exchange
   resources values with MGC acting as a manager and MG acting as an
   agent. However, MGC requires a high availability protocol because of
   its link with call processing. As SNMP doesn’t fulfill this needs,
   Megaco/H.248 protocol must not require an MGC to implement an SNMP
   manager function in order to discover capabilities of an MG. Thus,
   resources discovery is not under the scope of SNMP.

6. Solution using ServiceChange command

   Megaco/H.248 protocol currently offers the ServiceChange command.
   This command allows a MG to notify a MGC that a Termination, group
   of Terminations or a whole MG has just been returned to service. The
   ServiceChangeProfile parameter specifies what features of the
   Megaco/H.248 protocol is implemented by the MG.

   This solution proposes to extend the meaning of the
   ServiceChangeProfile parameter in order to express the media
   functions supported by the MG. Thus, when it starts up, the MG
   announces its media functions with a ServiceChangeProfile value
   issued in a ServiceChange command.

   The main drawback of this solution is its lack of flexibility.
   A profile value must reflect each potential set of media functions
   possessed by a MG.

Levy, Anquetil     Informational - Expires May 2001                  2

                       Media Gateway Discovery          November 2000

   Furthermore, the failure of an hardware resource in an MG may cause
   the alteration of its media resources. This change should be
   reflected by a new profile value.

7. Solution using AuditValue command.

   Megaco/H.248 protocol currently offers the AuditValue commands. The
   command returns the current values of the properties, events,
   signals and statistics associated with terminations. The knowledge
   of terminations gives an external vision of the MG but it does not
   inform how a context of the MG is able to associate the
   terminations. The solution proposes to make use of the AuditValue
   command to discover the internal media functions of the MG.

7.1 Atomic model

   The solution relies on an atomic model of the media functions to be
   performed by the MG. It is based on the four logically separated
   basic functions:
   1. Modify the transport without modifying the media encoding
   (application part) (e.g. moving from PCMU/RTP to G711 mu-law/TDM).
   2. Modify the media encoding using the same transport (e.g. moving
   from PCMU/RTP to GSM/RTP).
   3. Mix media streams using the same transport and the same media
   encoding (e.g. mix three PCMA/RTP flows for conferencing purposes).
   4. Terminate (or initiate) a media stream (e.g. terminate PCMU/RTP
   acting as an Interactive Voice Response unit).

   The functions may be :
   . oneway or bothway for functions 1 and 2.
   . send, receive or bothway for function 4.

   Any context realized by the MG should result in a combination of the
   previous basic functions. For instance, a context associating a
   termination with a stream G723 over RTP and a termination with a
   PCMU over a TDM channel makes use of the transport modification and
   the encoding modification functions.

7.2 Extension Description

   The extension introduces MediaResources and MediaFunctions
   descriptors. General knowledge of the descriptors semantics provides
   interoperability between MG and MGC. An MGC issues an AuditValue
   command with a MediaResources Descriptor as parameter to an MG which
   answers with its available media resources in the value of the
   descriptor.

7.2.1 MediaFunctions Descriptor

Levy, Anquetil     Informational - Expires May 2001                  3

                       Media Gateway Discovery          November 2000

   The Media Functions descriptor defines a set of identical functions
   such as those detailed in section 7.1. The descriptor includes the
   following properties:

   . FunctionID
   . Type
   . Cardinality
   . Description
   . Condition
   . Direction

   The FunctionID identifies the MediaFunctions.

   The possible values for the Type property are:
   Transportmodification, Encodingmodification, Mixstream and
   Terminatestream.

   The Cardinality value defines the number of identical functions that
   may be realized by the MG.

   The Description value describes the core of the function. The syntax
   of this value is not completely defined in this version of the
   draft. In general, the value shall be a string with the input value
   followed by the output value (if any) separated by a "-" character.
   The input and output value may be multiple: "|" character separates
   alternative values, "*" character describes a factorization, "/"
   describes an ordered succession.
   For Transportmodification, the input and output values define the
   transport protocol before and after the modification. "/" character
   is used to separate multiple successive protocol layer. It begins
   with the upper layer and terminates with the lower specified layer.
   For Encodingmodification, the input and output values describe the
   media format before and after the modification. For audio media, it
   means the audio format. Eventual additional encoding parameters such
   as the sampling rate  may be added after a "/" character.
   For Mixstream, the input and output values describe the media
   encoding before and after the mixing. An integer value followed by
   "*" character is used to express the maximum number of input streams
   that may be mixed.
   For Terminatestream, the input value describes the media encoding
   getting in or out the MG.

   The Condition value defines the necessary conditions to realize the
   function. For Transportmodification, it describes the media encoding
   required for the modification. As for the other functions, it
   describes the transport protocol required for the modification. The
   Condition may have the ALL value.

   The Direction property can have the following values : Bothway,
   Oneway, Send, Receive.
   Bothway means that the transformation is bi-directional and
   symmetrical.

Levy, Anquetil     Informational - Expires May 2001                  4

                       Media Gateway Discovery          November 2000

   Oneway means that the modification only operates from input stream
   to output stream.
   Send and receive are only for Terminatestream type function. It
   means that the function initiates (and respectively ends) the media
   stream.

   It is noted that properties corresponding to other transformation
   (such as echo cancellation) should be added to the descriptor
   through packages.

7.2.2 MediaRessources Descriptor

   The Media Resources descriptor groups MediaFunctions which forms the
   simultaneous media resources of an MG.

7.2.3 Audit Descriptor

   The Audit Descriptor specifies the list of descriptors to be
   returned by the reply. In addition to possible items defined in [3],
   MediaResources is provided in order to audit the media resources of
   an MG.

7.3 Call Flow Example

   This example illustrates the uses of the presented mechanism to
   discover the media resources of a Media Gateway. We assume that a
   Media Gateway Controller (MGC1)  controls a Media Gateway (MG1). The
   registration of MG1 is not shown with these call flows but it is
   supposed that it has been previously performed.

   1. The MGC1 decides to audit the MG1 media resources. It issues an
   AuditValue command to MG1
   From MGC1 to MG1:
   MEGACO/1 MGC1
     Transaction = 10001 {
       Context = Null { AuditValue = Root {
         Audit{MediaResources }
       } }
     }

   2. The MG1 replies. In this example, MG1 is able to handle 16
   simultaneous bi-directional transport modifications from RTP to TDM
   with any media encoding AND to handle 8 simultaneous bi-directional
   media encoding conversions from PCMU to G723 or GSM using RTP
   transport.
   From MG1 to MGC1:
   MEGACO/1 MG1
     Reply = 10001 {
       Context = Null { AuditValue = Root {
         MediaResources {

Levy, Anquetil     Informational - Expires May 2001                  5

                       Media Gateway Discovery          November 2000

           MediaFunctions = 1 {
             Type = Transportmodification,
             Cardinality = 16,
             Description = RTP/UDP/IPv4 - TDM,
             Condition = *,
             Direction = Bothway
           },
           MediaFunctions = 2 {
             Type = Encodingmodification,
             Cardinality = 8,
             Description = PCMU-G723|GSM,
             Condition = RTP,
             Direction = Bothway
           }
         }
       } }
     }

7.4 Implementation considerations

   An audit of the available media resources of an MG should be
   performed by the MGC, immediately after the MG has restarted. The
   MGC detects the restart, because it receives a ServiceChange command
   with ServiceChangeMethod corresponding to "Restart". After this
   audit, the MGC is able to control the resources of the MG in order
   to realize media connections.

   Under normal utilization, at any time, the MGC may ask the MG to
   return its available media resources. However, due to
   synchronization problems, some MG may fail in computing available
   resources, while resources are being allocated. In case of failure,
   the MG reports a "502-Not ready" error code.

   Therefore, it is highly recommended, that once knowing the initial
   media resources of the MG, the MGC performs its own accountancy of
   the available resources of the MG. Thus, the MGC does not need to
   audit the available resources anymore, until the MG stops.

8. Conclusion

   Experiment demonstrates, that it is an error to oppose the 2
   previously described solutions. While the ServiceChangeProfile
   allows to get the high level characteristics of a MG, the
   MediaResources descriptor gives precise knowledge of its media
   resources. Thus, authors are convinced of the interest of both
   solutions.

   Furthermore, SDP-ng initiative [5] aims at developing a successor of
   SDP [6] allowing to describe capabilities of a system. Therefore,

Levy, Anquetil     Informational - Expires May 2001                  6

                       Media Gateway Discovery          November 2000

   future works would carry on integrating the MediaResources and
   MediaDescription descriptor into SDP-ng.

9. Security Considerations

   Already covered by [3]. No specific extension needed for the
   proposed solutions.

10. References

   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

   3  ITU-T Recommendation H.248, "Gateway Control Protocol", Geneva,
      June 2000. See also RFC 2885, August 2000.

   4  Greene, Ramalho, Rosen, "Media Gateway Control Protocol
      Architecture and Requirements", RFC 2805, April 1999.

   5  Kutscher, Ott, Bormann, "Requirements for Session Description and
      Capability Negotiation", draft-kutscher-mmusic-sdpng-req-00.txt,
      July 2000.

   6  Handley, Jacobson, "SDP: Session Description Protocol", RFC 2327,
      April 1998.

11. Author's Addresses

   Thomas Levy
   Alcatel
   Route de Nozay
   91461 Marcoussis
   France
   Phone: + 33 (0)1 69 63 41 02
   Email: [email-masked]

   Laurent-Philippe Anquetil
   Alcatel
   Route de Nozay
   91461 Marcoussis
   France
   Phone: + 33 (0)1 69 63 17 03
   Email: [email-masked]

Levy, Anquetil     Informational - Expires May 2001                  7

                       Media Gateway Discovery          November 2000

Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into

Levy, Anquetil     Informational - Expires May 2001                  8

---

From: Christian Groves <[email-masked]>
Date: Wed, 22 Nov 2000 19:12:56 +1100

Hello Thomas,

Finally have have had a chance to read the draft and have a think about
it.

I have a fundamental question to this draft. Does the MGC really need
such indepth knowledge of the internal capabilities of the MG? Megaco I
believe was intended to be agonostic with regards to the internals of an
MG. I'm also not sure that a mechanism to discover this needs to be
highly available. Once the internals of a MG have been found they don't
typically change configuration frequently. Thus I feel a SNMP interface
would be appropriate as its something not happening all the time, only
during maintenance procedures.

Cheers, Christian

Thomas LEVY wrote:
>   ------------------------------------------------------------------------
>

---

From: Thomas LEVY <[email-masked]>
Date: Wed, 22 Nov 2000 13:28:48 +0100

Hello Christian,

-Concerning the need for a MGC to know the internal capabilities of the MG:
Let's consider this basic example:
Imagine a MGC controlling 100 heterogeneous MGs. Only 1 MG is able to perform
encoding modification from PCMU to GSM payload type upon ephemeral terminations.
When the MGC will  need to realize this media function, it should "allocate" a
Megaco Context in the corresponding MG.
If the MGC doesn't have the knowledge, it could potentially attempt (without
success) to ADD  Terminations in a new context for 99 MGs, before getting the
right MG.
What a waste!!!

-Concerning the best way to get the available internal
capabilities(Management:SNMP or High Availability:Megaco):
In any the cases, the MGC needs to know the internal capabilities of a MG on
start up. This could be done through Management interface.
But, those available internal capabilities evolves due to :
    -normal consumption of  resources
    -"on fly" configuration changes (faillure/recovery of an hardware/software
resources)
Thus, I am convinced that a high availability mechanism is needed for internal
capabilities discovery.

Thomas,

---

From: Christian Groves <[email-masked]>
Date: Fri, 24 Nov 2000 01:46:59 +1100

G'Day Tomas,

Please see my answers below marked [CHG]

Cheers, Christian

> success) to ADD  Terminations in a new context for 99 MGs, before getting the
[CHG] Seems to me that the MGC would audit these MGs at start up to get
a picture of what they do. If 99 MGs say PCMU only and the 100th it
comes back and gives GSM, PCMU that you choose that one.

> Thus, I am convinced that a high availability mechanism is needed for internal
[CHG] Normal consumption of resources should be handled by some sort of
congestion indication mechanism. It should be up to the MG to monitor
its own resources. The MGC shouldn't have to worry about resource
allocation in the MG as the MG might have its own schema. The new
H248AnnexN proposes a load control mechanism.
With regards to "on fly" configuration changes this is why we have
ServiceChange "Capability Change" see annex L. It indicates when
something has changed. The MGC can then audit to see the change.

---

From: Paul Hollis <[email-masked]>
Date: Fri, 24 Nov 2000 08:28:55 +1100

Hi Thomas/Christian,

I thought that if a MG supports terminations for PCMU and terminations for GSM then
it should also support the encoding/decoding between them.

If there are only limited resources to do such encoding/decoding, then this would
have to be found out via rejection of commands with error codes. Otherwise I guess
you would have to audit every time before trying to use a MG to check its got enough

resources or the MG could send the ServiceChange or an event when all of a
particular resource is used. You would then need a ServiceChange or event to tell
when the resource is available again. Sounds pretty much like congestion control,
which I guess is on the agenda for the new work anyway.

Regards Paul.

---

From: Thomas LEVY <[email-masked]>
Date: Fri, 24 Nov 2000 13:20:07 +0100

Christian,

See my answers below marked [THL]

> comes back and gives GSM, PCMU that you choose that one.

[THL] The previous example was not the best one to justify my ideas.
But, I don't think that the current audit command provide you all information, you
could need.

For ephemeral terminations (let's consider RTP streams), providing alternative codecs
(for inst: GSM, PCMU, PCMA, G729) doesn't inform about whole the media capacities:
1)-It doesn't mean that all the encoding combinations for the codec are supported  by
the MG. (It can support encoding modification from PCMU to GSM and  from PCMA to G729
but not from GSM to G729 (or PCMA to PCMU).
2)-It doesn't tell you if the MG is able to mix several (more than 2) RTP streams (for
conferencing purpose)
3)-It doesn't tell the cardinality (number of available media resources for
encoding/mixing...) of the MG.

> H248AnnexN proposes a load control mechanism.

[THL] Sorry, but I can't get: "H248_Annex_L and H248_annex_n_draft" on ftp site from
Pictel, could you please give the new URL.
However, I am not sure to follow you concerning the "congestion indication mechanism".

With "normal consumption of  resources", I was meaning that the cardinality of the
available media ressources of a MG may evolve due to the normal use of the MG. Thus,
the MGC may requires to "realign" its view of the MG by auditing the MediaResources.

> something has changed. The MGC can then audit to see the change.

[THL] I agree for the ServiceChange "Capability Change" to indicate that something has
changed..
But still the same pb to get the new capabilities with audit.

---

From: Thomas LEVY <[email-masked]>
Date: Fri, 24 Nov 2000 14:04:21 +0100

Paul,

> it should also support the encoding/decoding between them.

[THL] On my opinion: When an MG owns several heterogeneous terminations, it does not
automatically means that it is able to perform ALL the combinations of terminations
associations (encoding or decoding) within a context.

> particular resource is used.

[THL] I agree that having a ServiceChange to inform that some kind of resources is not
available anymore, provides a best solution in terms of congestion than auditing each
time you need to perform a media transformation.
But, how does the MGC knows what is unavailable the media resources (in case of several
functions performed by the MG)? I think, there is something missing if you use the audit
such as it is.

The draft "megaco-mgdiscovery" proposes (see part 7)  to:
-to provide a "quantitative" knowledge of the media resources with the audit command. It
could allow the MGC to know that the MG named mg1 will be able to perform only 16 media
encoding from PCMA to GSM.
-to provide a better "qualitative" knowledge of the media resources. It could allow the
MGC to know that the MG named mg1 will be able to perform media encoding only from PCMA
to GSM but not for other audio codec type.

> You would then need a ServiceChange or event to tell

[THL] Yes, it could be interresting to talk specifically about Congestion Control during
next meeting.
Hope, we will talk about the "megaco-mgdiscovery" draft as well ;-)

---

From: Thomas LEVY <[email-masked]>
Date: Fri, 24 Nov 2000 17:43:42 +0100

Hi  Christian,

I finally got the H248_annexN draft!!
I think that in case of congestion, the use of an audit of the MediaRessources descriptor
is complementary with the reception of an event indicating a congestion in the MG.

Thomas,