Internet Engineering Task Force Brian Rosen INTERNET DRAFT FORE Systems June 25, 1999 Paul Sijben Expires December 25, 1999 Lucent Technologies Joerg Ott Universitaet Bremen Unifying MEGACO/H.GCP Structures and Encoding Status of this document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 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. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract The MEGACO/H.GCP draft protocol has several structures that are not com- pletely defined, viz, how properties are described and grouped, the tem- plate concept, the package concept, etc. There is also an extended debate on the encoding of the protocol, and particularly, the encoding of the command parameters. This contribution proposes a unified approach to all of these issues. This Internet Draft was rushed to meet the Oslo deadline. As such, it was not thoroughly reviewed, especially to see that this ID conformed to its referenced fundamental ideas on capabilities. Rosen, Sijben, Ott [Page 1] Internet draft Unifying MEGACO Structures and Encoding April 16, 1999 1. Introduction In MEGACO/H.GCP, Terminations have Properties. The fundamental opera- tion that is required is to set Properties to specific values. Each Command (like Add) needs to be able to express Properties and values. In some cases, values are not fully specified. Wildcards (any or choose) have been proposed. One important requirement is that the list of possible Properties needs to be extended, as new kinds of gateways are designed. To aid in making commands short, it has been suggested that we have Tem- plates, which are named, and which specify a list of Properties and values for those Properties. The template name could be substituted for the individual properties and values. We observe that the representa- tion of a Template is identical to the representation of the Properties to a Command, that is, a list of Properties and their values. We also observe that if a Template could substitute for a list of Properties and values, by allowing a Template name in the list, complex Templates could be constructed from simpler Templates. The current MEGACO syntax groups Properties into Descriptors. Descrip- tors are a group of related Properties. Descriptors are primarily a con- venience, but they allow some Properties to be used twice; once for the "local" side, and again for the "remote" side. In addition to setting the value of a Property, MEGACO requires that the MGC be able to discover what Properties a Termination has, and the allowed values for those Properties (capabilities). Allowed values can be stated as a choice from a list of allowed values or as min/max values. In practice, capability representation (that which is returned by Audit) is more complex, because real MGs have more complex resource limita- tions. The oft-cited example is a DSP that can do several things, but not necessarily all combinations. For example, it might be able to han- dle 24 lines of G.729a, but only 16 lines of G.726. In general, capa- bility representation can be expressed as counted, nested property/allowed value sets with and/or operations, for example codec= {24 x G729.a or 16 x G.726}. It is clear that describing such capabilities may be arbitrarily com- plex. To reduce complexity, one might define variables representing sub- trees of the complete capability sets, give each subtree a name and use the name in higher level descriptions. Such a mechanism looks like a Template. In addition to Properties, Terminations may have Events and/or Signals applied to them. Events and Signals have names. It has been proposed Rosen, Sijben, Ott [Page 2] Internet draft Unifying MEGACO Structures and Encoding April 16, 1999 that they have parameters, which could limit proliferation of Events or Signals that have similar function, but some variation. An example is the "ring" tone, which has many national variants. Signals and Events have a grouping (Packages), and are listed in Descriptors in Commands. Events and Signals must be auditable, like Properties. The Package con- cept, which groups events and signals into a single definition when they are related, is attractive to apply, in some way, to Properties. Finally, expressing Properties and their values, Descriptors, Templates, Capabilities, Events and Signals, etc, have to be encoded. SDP and H.245-like syntax have been proposed, and it has been pointed out that both would have to be enhanced to represent the expressive power of the other, as well as to represent complex capabilities. The encoding debate is fraught with "religion" stemming from the representation of similar capabilities in the MGC - MGC protocols. If you assume that you are using SIP, then you want the MEGACO/H.GCP proto- col to use SDP, and if you are using H.323 for MGC-MGC, then you want to use H.245. All of this is preface to a proposal to unify and completely specify how all of these various elements of MEGACO/H.GCP. 2. Proposal 2.1. Encoding using TLVs We begin by proposing that a property, event, or signal be represented by a Type/Length/Value structure (TLV). This is its encoding. It is neither the text string representation of SDP, nor the ASN.1 BER syntax of H.245. TLVs are a very common way to define a compact, but flexible encoding of arbitrary parameters. We propose that for MEGACO/H.GCP, Type and Length are two bytes each. This means that a simple one byte Property encodes to 5 bytes, and a 30 character string encodes to 34 bytes. As is conventional, a zero in the Length field causes the first 4 bytes of the Value to be treated as an extended Length. The Type is an IANA assigned value. Types have two subfields: Package and Item. IANA maintains a single list of Package assignments, and a list of Item assignments for each Package. Thus the name space of Item is unique within a Package. Length and Value are what you expect, Length in bytes and a byte string of the Value. A description of each Item in the Package specifies the representation of the Value (number, enumerated list, string, etc). For enumerated lists, IANA maintains a list of enumerations for each Item in each Package that requires such. We reserve one Package index for special Items. Besides the IANA Rosen, Sijben, Ott [Page 3] Internet draft Unifying MEGACO Structures and Encoding April 16, 1999 registered standard packages, vendors will have their own packages which will allow vendor specific extensions, and we will reserve a Package index for "Experimental". The convention used when displaying a Type is "Package:Item". For exam- ple, we might have an Type called "Audio:Codec" which is an Item called "Codec" defined in the Package called "Audio". Packages are described either in appendices to the MECAGO/H.GCP document, or in separate docu- ments. For each Item, two reserved values are usually defined for "all" and "choose". Some item definitions may need to use different conventions. For a list of TLVs, we encode the list as a TLV, with a special Item, and a Value which is the concatenation of all the TLVs in the list. The Length is the total length of all of the concatenated TLVs. 2.2. Events and Signals Events and Signals are Items in Packages. The Value is the parameter to the Event/Signal. If there is more than one parameter, then the Value of the Item is a concatenated list of TLVs, each of which represents one parameter. 2.3. Capabilities To encode capabilities, we propose to have a TLV of Type "AND" and another of Type "OR". [Ott] [Kimchi] The value is a concatenated list of TLVs, Such a list could itself contain other AND/OR TLVs, of course. To encode mix/max we have another Item ("MinMax"), and if anyone thinks we need one, a "MinMaxIncrement". The first TLV in the Value of MinMax is the Min, the second is the Max. To encode quantities, we propose a TLV of Type QuantityOf. We will reserve a special item value to indicate the capability of the entire package. 2.4. Example The general encoding for the Codec Item for example would have an index from the IANA assigned list of choices (representing G.711, G.726, ...). To indicate a capability of G.711 or G.726, we would encode this as: Rosen, Sijben, Ott [Page 4] Internet draft Unifying MEGACO Structures and Encoding April 16, 1999 Type: Megaco:OR Length: 10 (If Type and Length are 2 bytes each) Value: Type: Audio:Codec Length: 1 Value: 1 (if IANA assigned index 1 to G.711) Type Audio:Codec Length: 1 Value: 2 (if IANA assigned index 2 to G.726) 2.5. Descriptors A Descriptor is a concantenated list of TLVs. The use of these Descrip- tors should be obvious. Underspecified properties may be encoded by use of the AND, OR and MinMax TLVs as well as the "choose" and "all" Values. 2.6. Templates For Templates, we propose to reserve a Package for use as a dynamic name store (a Template). A unique Item would be allocated dynamically, and it's value would be a concatenated list of TLVs (including nested AND/OR TLVs, and other Template TLVs). When a TLV referencing the template was encountered in a Descriptor, the current definition of the template would be substituted for the Template TLV. Rosen, Sijben, Ott [Page 5] Internet draft Unifying MEGACO Structures and Encoding April 16, 1999 2.7. Summary A Property, Event or Signal is encoded as a TLV Properties, Events and Signals are defined in Packages, The Type of a TLV consists of a Package and an Item, which are IANA assigned indexes A descriptor is a TLV whose Type is an Item in the Megaco Package and whose Value is a concatenated list of TLVs. Complex descriptors may be created by use of AND and Megaco:OR TLVs, the value of which is a concatenated list of TLVs, any of which could be an AND/OR TLV Descriptors may express ranges by use of MinMax and QuantityOf TLVs. A Template is a prestored descriptor. A Template TLV may be used wherever any other TLV may be used, and may contain TLVs of Type Template, AND, OR, MinMax, etc. A Capability is a Descriptor (Megaco:Capability) which may have QuantityOf, AND, OR and MinMax TLVs. Capabilities are normally what Audit returns. 3. References * Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer, "MEGACO Protocol ", draft-ietf-megaco-protocol-01.txt, April 1999. * ITU-T, Draft Recommendation H.GCP (05/99), "GATEWAY CONTROL PROTO- COL." * Kimchi, "Issues with using SDP or SDP sequences for MEGACO Proto- col", draft-kimchi-megaco-discuss-caps-00.txt, June 1999. * Ott, Kutscher,"Capability description for group cooperation", draft-ott-mmusic-cap-00.txt, June 1999. 4. Authors' Addresses Brian Rosen FORE Systems 1000 FORE Drive Warrendale, PA 15086 Phone: +1 724 742 6826 EMail: brosen@eng.fore.com Paul Sijben Lucent Technologies Rosen, Sijben, Ott [Page 6] Internet draft Unifying MEGACO Structures and Encoding April 16, 1999 PO box 18 1270 AA Huizen the Netherlands Phone: +31 35 687 4774 Email: sijben@lucent.com Joerg Ott Universitaet Bremen, TZI, MZH 5180 Bibliothekstr. 1 D-28359 Bremen Germany Phone: +49 421 201-7028 0 Email: jo@tzi.org Rosen, Sijben, Ott [Page 7]