2.7.6 Media Gateway Control (megaco)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 04-Jun-99


Tom Taylor <taylor@nortelnetworks.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion:megaco@standards.nortelnetworks.com
To Subscribe: listserv@standards.nortelnetworks.com
In Body: subscribe megaco first_name last_name
Archive: http://standards.nortelnetworks.com/archives/megaco.html

Description of Working Group:

The working group will develop an informational RFC detailing the architecture and requirements for controlling Media Gateways from external control elements such as a Media Gateway Controller. A media gateway is a network element that provides conversion between the information carried on telephone circuits and data packets carried over the Internet or over other IP networks. This work will be done in consultation with other IETF working groups looking at similar issues. The working group will also ensure that good information conduits exist with groups in other standards groups with expertise in the relevant PSTN technology. Other IETF working groups include PINT, IPTEL and SIGTRAN. In addition the working group will ensure that reasonable liaisons exist with similar activities in other standards bodies such as the ITU-T and ETSI.

This working group will also define standards track protocol(s) for controlling media gateways from external control elements such as a media gateway controller.

Examples of media gateways are:

* Trunking gateways that interface between the telephone network and a Voice over IP network. Such gateways typically manage a large number of digital virtual circuits. * Access gateways that provide traditional analog or Primary Rate (PRI) line interfaces to a Voice over IP network. * Network Access Servers that can attach a "modem" to a telephone circuit and provide data access to the Internet.

This working group assumes a separation of call control so the call control "intelligence" is outside the media gateways and handled by a media gateway controller. This group will NOT work on media gateway controller to media gateway controller protocols, nor on media gateway to media gateway protocols.

The working group will ensure that the security issues relating to the use of the standards track protocol in hostile environments are fully understood and that the protocol will will include security mechanisms to protect against attacks on the protocol and to ensure confidentiality where needed.

Planned output:

* Architecture & Requirements informational RFC

* Standards Track RFC for the protocol between a media gateway controller and a media gateway.

* Standards Track RFC for the MG and MC MIBs

* Informational RFC for application programming interface for the MC to MG protocol

Goals and Milestones:

Jan 99


Submit Initial draft of architecture and requirements document

Feb 99


Initial draft of protocol between MC and MG

Apr 99


Submit architecture and requirements document to IESG

Apr 99


Updated draft of protocol between MC and MG

Apr 99


Initial draft of MG and MC MIBs

Apr 99


Initial draft of Application Programming Interface (API) for the protocol between the MC and the MG

Jul 99


Submit protocol(s) between MC and MG to IESG for publication as RFCs

Jul 99


Submit RFC MIBs for MC and MG to IESG for publication as RFCs

Jul 99


Submit API for the protocol to the IESG for publication as an RFC

Aug 99


Close Working Group


No Request For Comments

Current Meeting Report

MEGACO 45th IETF Oslo - Thursday, July 14, 1999

Chair: Tom Taylor taylor@nortelnetworks.com
Reported by Matt Holdrege holdrege@lucent.com

226 people signed the blue sheet.

The agenda (file taylor.pdf, charts 1-3), was accepted.

Tom gave the design team report (file taylor.pdf, chart 4 ). There was no time for questions or comments.

The design team agreed to split audit into two commands, status discovery and capability discovery.

The MGC must support both SDP and SG16-determined encoding of H.245. An MG may support either and this reserves the possibility of migration to a new syntax.

There was a political impasse on encoding. Tom decided for text by flipping a coin. The issue is relative value of development speed versus performance. Note that this conclusion was reached at a second meeting which did not include the whole design team.

Paul Sijben (sijben@lucent.com) led a discussion on Capabilities requirements (file sijben.pdf), essentially in support of the I-D by Rosen et al. Capabilities must be protocol agnostic and bearer (transport) agnostic.

Capabilities must be able to express simultaneous and mutually exclusive capabilities. SDP in its original form is unable to do so, while H.245 is overly complex. Christian Huitema (huitema@research.telcordia.com) pointed out that he had demonstrated how to overcome this perceived deficiency of SDP.

Paul explained that the Template concept is like a macro.

He proposed that we use flexible tags that can be registered with IANA for all properties. We already use such tags for signals and events and private properties. One of those tags could be an EmbeddedSDP tag. In this way, the native way of encoding descriptors in the protocols is coherent but if you want to implement SDP or H.245 in the MG you can.

Brian Rosen - brosen@ENG.FORE.COM led a talk on the protocol syntax, presenting a set of ABNF based on the decision to use text. This syntax included the optional use of Authentication Headers at the application level when IPSEC is unavailable. The Chair pointed out that we had received advice from the Security Area directorate that IPSEC work-arounds like this are undesirable. After Brian Rosen argued that the available real-time operating systems for small MGs do not yet implement IPSEC, Scott Bradner declared himself convinced that we had a legitimate reason to use the application-level AH. The AD said that the WG must think about the security issues. But we shouldn't blindly use IPsec.

Matt Holdrege said that this isn't fair to the vendors who did the right thing by supporting IPsec. Christian proposed a compromise. Since gaining IPsec support for larger the OS's is relatively easier, the rough consensus is that MGC's MUST support IPsec, but MG's may choose to support the alternate authentication scheme.

Again, SDP and H.245 must be extended to support Frame Relay and other features.

We have been fairly careful to provide X- extensions for experimental features.

It was questioned when we will see a proposal for H.245 media descriptor and media capability descriptor encoding? Tom said that the upcoming SG16 Berlin meeting would handle that and perhaps would use TLV. There will always be a small standardization lag between what MEGACO does and what SG16 does.

It was questioned whether we should use domain names or some other identifier for MGs and MGCs. The suggestion was it could be a string for a FQDN or a decimal address.

It was noted that the MSF requirements for sending statistics to the MGC are not included in Brian's proposal and should be.

Fernando Cuervo (cuervo@nortelnetworks.com) led a talk on transport for MEGACO. He pointed out that the proposed solutions fell into two classes. TCP, SIGTRAN, and TUDP all assume that transport reliability and congestion avoidance are handled in a separate layer. Application-layer framing (ALF) differs in kind from these other proposals because it requires the application to address these issues.

Application level timers and their relation to transport timers were discussed with no resolution although it was noted that we will always need application level timers.

Randy Stewart (rstewar1@email.mot.com talked on MDTP. The SIGTRAN design team is working on improving MDTP and reducing the amount of code. TUDP and MDTP are very similar.

TUDP has timers to back off during congestion. It was noted that MDTP uses more commands to handle congestion management than TCP.

For the fanout issue, it was noted that each proposal (TCP, TUDP or MDTP) should be able to properly handle many thousands of connections.

It was noted that TUDP and MDTP should be able to handle diff-serv while TCP already has this feature.

One choice for transport must be mandatory as per the AD. The others could be options.

Congestion should not be in transport, it should be pushed down into the network. You should be able to tell your transport manager when you can send data. The application gets to choose millisecond by millisecond what to send.

There should be much tighter coupling between transport and application.

By a series of hum polls, the meeting determined a rough consensus that the MGC must support both TCP and ALF, but the MG may support either or both. The MG determines the choice of transport in any specific association, because it is always the initiator of that association. MDTP and TUDP were not considered in this decision process, because it was framed in terms of explicit transport layer versus ALF and the list had already agreed that TCP had to be one of the alternatives.

The next section of the meeting was on packages. The Chair presented an inventory of the packages which have been proposed to Megaco in draft-ietf-megaco-protocol-01.txt, draft-ietf-megaco-R2package-00.txt, and draft-ietf-megaco-ipphone-00.txt (file taylor.pdf, charts 5-6).

Mike Kallas (mkallas@nortelnetworks.com) presented a proposal for a package documentation format (file kallas.pdf).

We must set up a procedure with IANA to define codepoints. Packages will be one such item that needs to be registered. Packages should be defined as informational RFC's. SG16 will likely take a subset of these RFC's and publish them as annexes of H.248. Mike Kallas and Christian Huitema are tasked with drafting the IANA Considerations section for this purpose.

We are looking for volunteers as editors to put together the actual package documents. One of these documents should provide a "starter kit" of commonly used packages, which would be incorporated by reference into the protocol document. Package is described by a document and consists of a set of termination properties, events, and signals and their properties. The MG can be audited to determine what packages it supports and the ranges of values it supports for the properties.

Someone questioned whether response codes should be package specific.

The final moments of the meeting dealt with the work plan going forward for the requirements and protocol documents (file taylor.pdf, chart 8). We will have last call for the requirements after the SG16 meeting.

SG16 must have a complete H.248 spec for ballot done by the beginning of October [actually mid-November]. Corrections can be added up to February 2000. WG Last Call should probably happen as soon as the protocol and basic package documents are considered to be stable -- perhaps in late August. The question to be resolved is whether we have IETF last call after WG last call is complete or after H.248 has been approved. We must also decide which packages are to be included in the "starter kit" document.


None received.