idnits 2.17.1 draft-rosen-megaco-structures-and-encoding-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Ott' on line 179 looks like a reference -- Missing reference section? 'Kimchi' on line 179 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Brian Rosen 2 INTERNET DRAFT FORE Systems 3 June 25, 1999 Paul Sijben 4 Expires December 25, 1999 Lucent Technologies 5 Joerg Ott 6 Universitaet Bremen 8 Unifying MEGACO/H.GCP Structures and Encoding 10 Status of this document 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 To view the entire list of current Internet-Drafts, please check the 31 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 32 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 33 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 34 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 36 Abstract 38 The MEGACO/H.GCP draft protocol has several structures that are not com- 39 pletely defined, viz, how properties are described and grouped, the tem- 40 plate concept, the package concept, etc. There is also an extended 41 debate on the encoding of the protocol, and particularly, the encoding 42 of the command parameters. This contribution proposes a unified 43 approach to all of these issues. This Internet Draft was rushed to meet 44 the Oslo deadline. As such, it was not thoroughly reviewed, especially 45 to see that this ID conformed to its referenced fundamental ideas on 46 capabilities. 48 Internet draft Unifying MEGACO Structures and Encoding April 16, 1999 50 1. Introduction 52 In MEGACO/H.GCP, Terminations have Properties. The fundamental opera- 53 tion that is required is to set Properties to specific values. Each 54 Command (like Add) needs to be able to express Properties and values. 55 In some cases, values are not fully specified. Wildcards (any or 56 choose) have been proposed. One important requirement is that the list 57 of possible Properties needs to be extended, as new kinds of gateways 58 are designed. 60 To aid in making commands short, it has been suggested that we have Tem- 61 plates, which are named, and which specify a list of Properties and 62 values for those Properties. The template name could be substituted for 63 the individual properties and values. We observe that the representa- 64 tion of a Template is identical to the representation of the Properties 65 to a Command, that is, a list of Properties and their values. We also 66 observe that if a Template could substitute for a list of Properties and 67 values, by allowing a Template name in the list, complex Templates could 68 be constructed from simpler Templates. 70 The current MEGACO syntax groups Properties into Descriptors. Descrip- 71 tors are a group of related Properties. Descriptors are primarily a con- 72 venience, but they allow some Properties to be used twice; once for the 73 "local" side, and again for the "remote" side. 75 In addition to setting the value of a Property, MEGACO requires that the 76 MGC be able to discover what Properties a Termination has, and the 77 allowed values for those Properties (capabilities). Allowed values can 78 be stated as a choice from a list of allowed values or as min/max 79 values. 81 In practice, capability representation (that which is returned by Audit) 82 is more complex, because real MGs have more complex resource limita- 83 tions. The oft-cited example is a DSP that can do several things, but 84 not necessarily all combinations. For example, it might be able to han- 85 dle 24 lines of G.729a, but only 16 lines of G.726. In general, capa- 86 bility representation can be expressed as counted, nested 87 property/allowed value sets with and/or operations, for example codec= 88 {24 x G729.a or 16 x G.726}. 90 It is clear that describing such capabilities may be arbitrarily com- 91 plex. To reduce complexity, one might define variables representing sub- 92 trees of the complete capability sets, give each subtree a name and use 93 the name in higher level descriptions. Such a mechanism looks like a 94 Template. 96 In addition to Properties, Terminations may have Events and/or Signals 97 applied to them. Events and Signals have names. It has been proposed 99 Internet draft Unifying MEGACO Structures and Encoding April 16, 1999 101 that they have parameters, which could limit proliferation of Events or 102 Signals that have similar function, but some variation. An example is 103 the "ring" tone, which has many national variants. Signals and Events 104 have a grouping (Packages), and are listed in Descriptors in Commands. 105 Events and Signals must be auditable, like Properties. The Package con- 106 cept, which groups events and signals into a single definition when they 107 are related, is attractive to apply, in some way, to Properties. 109 Finally, expressing Properties and their values, Descriptors, Templates, 110 Capabilities, Events and Signals, etc, have to be encoded. SDP and 111 H.245-like syntax have been proposed, and it has been pointed out that 112 both would have to be enhanced to represent the expressive power of the 113 other, as well as to represent complex capabilities. 115 The encoding debate is fraught with "religion" stemming from the 116 representation of similar capabilities in the MGC - MGC protocols. If 117 you assume that you are using SIP, then you want the MEGACO/H.GCP proto- 118 col to use SDP, and if you are using H.323 for MGC-MGC, then you want to 119 use H.245. 121 All of this is preface to a proposal to unify and completely specify how 122 all of these various elements of MEGACO/H.GCP. 124 2. Proposal 126 2.1. Encoding using TLVs 128 We begin by proposing that a property, event, or signal be represented 129 by a Type/Length/Value structure (TLV). This is its encoding. It is 130 neither the text string representation of SDP, nor the ASN.1 BER syntax 131 of H.245. TLVs are a very common way to define a compact, but flexible 132 encoding of arbitrary parameters. 134 We propose that for MEGACO/H.GCP, Type and Length are two bytes each. 135 This means that a simple one byte Property encodes to 5 bytes, and a 30 136 character string encodes to 34 bytes. As is conventional, a zero in the 137 Length field causes the first 4 bytes of the Value to be treated as an 138 extended Length. 140 The Type is an IANA assigned value. Types have two subfields: Package 141 and Item. IANA maintains a single list of Package assignments, and a 142 list of Item assignments for each Package. Thus the name space of Item 143 is unique within a Package. Length and Value are what you expect, 144 Length in bytes and a byte string of the Value. A description of each 145 Item in the Package specifies the representation of the Value (number, 146 enumerated list, string, etc). For enumerated lists, IANA maintains a 147 list of enumerations for each Item in each Package that requires such. 148 We reserve one Package index for special Items. Besides the IANA 150 Internet draft Unifying MEGACO Structures and Encoding April 16, 1999 152 registered standard packages, vendors will have their own packages which 153 will allow vendor specific extensions, and we will reserve a Package 154 index for "Experimental". 156 The convention used when displaying a Type is "Package:Item". For exam- 157 ple, we might have an Type called "Audio:Codec" which is an Item called 158 "Codec" defined in the Package called "Audio". Packages are described 159 either in appendices to the MECAGO/H.GCP document, or in separate docu- 160 ments. 162 For each Item, two reserved values are usually defined for "all" and 163 "choose". Some item definitions may need to use different conventions. 165 For a list of TLVs, we encode the list as a TLV, with a special Item, 166 and a Value which is the concatenation of all the TLVs in the list. The 167 Length is the total length of all of the concatenated TLVs. 169 2.2. Events and Signals 171 Events and Signals are Items in Packages. The Value is the parameter to 172 the Event/Signal. If there is more than one parameter, then the Value 173 of the Item is a concatenated list of TLVs, each of which represents one 174 parameter. 176 2.3. Capabilities 178 To encode capabilities, we propose to have a TLV of Type "AND" and 179 another of Type "OR". [Ott] [Kimchi] The value is a concatenated list of 180 TLVs, Such a list could itself contain other AND/OR TLVs, of course. To 181 encode mix/max we have another Item ("MinMax"), and if anyone thinks we 182 need one, a "MinMaxIncrement". The first TLV in the Value of MinMax is 183 the Min, the second is the Max. To encode quantities, we propose a TLV 184 of Type QuantityOf. We will reserve a special item value to indicate 185 the capability of the entire package. 187 2.4. Example 189 The general encoding for the Codec Item for example would have an index 190 from the IANA assigned list of choices (representing G.711, G.726, ...). 191 To indicate a capability of G.711 or G.726, we would encode this as: 193 Internet draft Unifying MEGACO Structures and Encoding April 16, 1999 195 Type: Megaco:OR 196 Length: 10 (If Type and Length are 2 bytes each) 197 Value: 198 Type: Audio:Codec 199 Length: 1 200 Value: 1 (if IANA assigned index 1 to G.711) 202 Type Audio:Codec 203 Length: 1 204 Value: 2 (if IANA assigned index 2 to G.726) 206 2.5. Descriptors 208 A Descriptor is a concantenated list of TLVs. The use of these Descrip- 209 tors should be obvious. Underspecified properties may be encoded by use 210 of the AND, OR and MinMax TLVs as well as the "choose" and "all" Values. 212 2.6. Templates 214 For Templates, we propose to reserve a Package for use as a dynamic name 215 store (a Template). A unique Item would be allocated dynamically, and 216 it's value would be a concatenated list of TLVs (including nested AND/OR 217 TLVs, and other Template TLVs). When a TLV referencing the template was 218 encountered in a Descriptor, the current definition of the template 219 would be substituted for the Template TLV. 221 Internet draft Unifying MEGACO Structures and Encoding April 16, 1999 223 2.7. Summary 225 A Property, Event or Signal is encoded as a TLV 226 Properties, Events and Signals are defined in Packages, 227 The Type of a TLV consists of a Package and an Item, which 228 are IANA assigned indexes 229 A descriptor is a TLV whose Type is an Item in the Megaco 230 Package and whose Value is a concatenated list 231 of TLVs. 232 Complex descriptors may be created by use of AND 233 and Megaco:OR TLVs, the value of which is a 234 concatenated list of TLVs, any of which could be an 235 AND/OR TLV 236 Descriptors may express ranges by use of MinMax 237 and QuantityOf TLVs. 238 A Template is a prestored descriptor. A Template TLV may be used 239 wherever any other TLV may be used, and may contain TLVs 240 of Type Template, AND, OR, MinMax, etc. 241 A Capability is a Descriptor (Megaco:Capability) which 242 may have QuantityOf, AND, OR and MinMax TLVs. 243 Capabilities are normally what Audit returns. 245 3. References 247 * Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer, "MEGACO Protocol 248 ", draft-ietf-megaco-protocol-01.txt, April 1999. 250 * ITU-T, Draft Recommendation H.GCP (05/99), "GATEWAY CONTROL PROTO- 251 COL." 253 * Kimchi, "Issues with using SDP or SDP sequences for MEGACO Proto- 254 col", draft-kimchi-megaco-discuss-caps-00.txt, June 1999. 256 * Ott, Kutscher,"Capability description for group cooperation", 257 draft-ott-mmusic-cap-00.txt, June 1999. 259 4. Authors' Addresses 261 Brian Rosen 262 FORE Systems 263 1000 FORE Drive 264 Warrendale, PA 15086 265 Phone: +1 724 742 6826 266 EMail: brosen@eng.fore.com 268 Paul Sijben 269 Lucent Technologies 271 Internet draft Unifying MEGACO Structures and Encoding April 16, 1999 273 PO box 18 274 1270 AA Huizen 275 the Netherlands 276 Phone: +31 35 687 4774 277 Email: sijben@lucent.com 279 Joerg Ott 280 Universitaet Bremen, 281 TZI, MZH 5180 Bibliothekstr. 1 D-28359 282 Bremen Germany 283 Phone: +49 421 201-7028 0 284 Email: jo@tzi.org