idnits 2.17.1 draft-ietf-megaco-msf-reqs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 145: '...g variants (e.g.NSAP & E.164) SHALL be...' RFC 2119 keyword, line 148: '...ct: The protocol SHALL allow ATM tran...' RFC 2119 keyword, line 152: '...is, the Protocol SHOULD allow all nece...' RFC 2119 keyword, line 193: '...pt: The Protocol SHALL allow for unamb...' RFC 2119 keyword, line 196: '...pt: The Protocol SHALL allow the AAL2 ...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 172 has weird spacing: '...ptation for c...' == Line 276 has weird spacing: '...request and n...' -- 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) No issues found here. Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MEGACO Working Group Matt Holdrege (Liaison) 2 Internet Draft Multiservice Switching Forum 3 April 1999 Media Control Group 5 Multiservice Switching Forum requirements input to MEGACO 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC2026. 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "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 Copyright Notice 32 Copyright (C) The Internet Society (1999). All Rights Reserved. 34 Abstract 36 This document serves as input into the IETF MEGACO requirements 37 process. It includes requirements as input by MSF members and 38 refined by the MSF Media Control group. 40 Disclaimer: 42 This is a representation of the preliminary requirements generated 43 by the Multiservice Switching Forum/Media Control Working Group. 44 This document has been approved by the Working Group for liaison 45 distribution to the IETF. However, this document in no way binds any 46 of the member organizations to the ideas presented. It should also 47 be noted that this work is incomplete and a draft. It is being 48 submitted now to meet the MEGACO WG timelines. The MSF will revisit 49 this work in the future and may add, change or delete its 50 requirements. 52 Introduction 54 I-D MSF requirements input to MEGACO April 1999 56 The Multiservice Switching Forum (http://www.msforum.org) has the 57 following mission: 59 (1) an architecture that separates the control and user/data plane 60 aspects of an ATM-capable Multiservice Switching System and 61 establishes a framework which can be easily extended to support new 62 user/data plane and control functions. 64 (2) a set of open intra-switch interfaces and promote implementation 65 agreements for these interfaces that allow service providers to 66 deploy ATM-capable Multiservice Switching Systems composed of best- 67 of-breed components from multiple vendors. 69 These requirements are for narrow-band call control over packet/cell 70 networks. In the future, other multimedia requirements may be 71 defined. These requirements address connection establishment and 72 tear-down, together with such parameters associated with those calls 73 to be used for call accounting, call QoS monitoring etc. Furthermore 74 these requirements address such management information as to allow a 75 Media Gateway Controller to identify available resources. These are 76 not stand-alone requirements, but instead addititive to draft-ietf- 77 megaco-reqs-01.txt 79 It is assumed that the protocol that these requirements address will 80 not be a general purpose management protocol. 82 Connectivity Requirements 84 Connect: The Protocol shall support requests for multi-media 85 connections from circuit to packet for IP and vice versa 87 Connect: The Protocol shall support requests for multi-media 88 connections from circuit to packet for ATM and vice versa. 90 Connect: The Protocol shall support requests for multi-media 91 connections from circuit to packet for FR and vice versa. 93 Connect: The Protocol shall support requests for connections of 94 circuit to circuit. 96 Connect: The Protocol shall support requests for multi-media 97 connections from all packet to packet combinations for IP, ATM and 98 FR 100 Connect: The protocol shall allow the specification of bearer plane 101 on a call by call basis since a MG may support more than one bearer 102 plane e.g Frame Relay, IP, etc. 104 Connect: The Protocol shall allow for the de-coupling of 105 creation/deletion of the narrow-band connection from the 106 creation/deletion of the underlying VCC. 108 Connect: The Protocol shall allow connections to be added/removed 109 to/from a call during the call. 111 I-D MSF requirements input to MEGACO April 1999 113 Connect: The protocol shall allow for efficient disconnection of all 114 connections associated with a physical port or VCC. As an example, 115 this could aggregate disconnections across a broadband circuit which 116 experienced a physical error. 118 The narrow-band connection established using this Protocol, may be 119 carried over a VCC, which may be a: 120 * PVC or SPVC, 121 * an SVC established on demand, either by the MGC itself or by a 122 broker acting on its behalf or 123 * an SVC originated as required by the local MG, or by the 124 remote end to the local MG through UNI or PNNI signalling. 126 Connect: The protocol shall be able to refer to an existing VCC as 127 The physical interface + Virtual Path Identifier (VPI) + Virtual 128 Circuit Identifier (VCI). 130 Where the VCC is locally established (SVCs signalled by the Gateway 131 through UNI or PNNI signalling or similar), the VCC must be 132 indirectly referred to in terms which are of significance to both 133 ends of the VCC. i.e. a global name or the ATM address of the ATM 134 devices at each end of the VCC. However, it is possible/ probable 135 that there may be several VCCs between a given pair of ATM devices. 136 Therefore the ATM address pair must be further resolved by a VCC 137 identifier unambiguous within the context of the ATM address pair. 139 Connect: The Protocol shall be able to refer to a VCC as the Remote 140 GW ATM End System Address + VCCI. 142 Connect: The Protocol shall allow the VCCI to be selected by the MG 143 or imposed on the MG. 145 Connect: All ATM addressing variants (e.g.NSAP & E.164) SHALL be 146 supported within the Protocol. 148 Connect: The protocol SHALL allow ATM transport parameters and 149 Quality of Service parameters to be passed to the MG. 151 Connect: Where a VCC is required to be established on a per narrow- 152 band call basis, the Protocol SHOULD allow all necessary information 153 to be passed in 1 message. 155 Connect: The protocol shall allow for the MG to report cause codes 156 for success or failure of the lower layer connection setup. 158 Connect: The protocol shall allow for the MG to report cause codes 159 for abnormal failure of lower layer connections e.g. TDM circuit 160 failure, ATM VCC failure. 162 Connect: The protocol shall allow for the MG to report Usage 163 Parameter Control (UPC) events. 165 Adaptation 167 I-D MSF requirements input to MEGACO April 1999 169 The Protocol shall allow the possible adaptations of an ATM capable 170 Gateway: 172 Adapt: The protocol shall allow for Media adaptation for circuit to 173 ATM connections (e.g. analog loop to G.729/AAL2/ATM) 175 Adapt: The protocol shall allow for Media trans-adaptation for 176 packet-to-ATM or ATM-ATM connections (e.g. G.723/RTP/UDP/IP to 177 G.726/AAL2/ATM) 179 Adapt: The protocol shall allow for ATM trans-adaptation only (no 180 media adaptation) e.g. for switching voice streams between IP and 181 AAL2/ATM or between AAL2/ATM links. 183 Adapt: The protocol shall allow AAL parameters to be passed to the 184 MG. 186 AAL2 In AAL2 multiple narrow-band calls may be mapped to a single 187 VCC. These calls are differentiated within each VCC by a AAL2 188 channel identifier. An AAL2 connection may span more than 1 VCC and 189 transit AAL2 switching devices. ATMF standards are working on an 190 end-to-end AAL2 connection identifier as part of the AAL2 signalling 191 set. 193 Adapt: The Protocol SHALL allow for unambiguous binding of a narrow 194 band call to an AAL2 connection identifier within the specified VCC. 196 Adapt: The Protocol SHALL allow the AAL2 connection identifier to be 197 selected by the MG or imposed on the MG 199 Adapt: The Protocol SHOULD allow AAL2 channel identifier (cid) 200 instead of AAL2 connection identifier 202 Adapt: The protocol shall allow for the AAL2 voice profile to be 203 imposed or negotiated before the start of the connection. AAL2 204 allows for variable length packets and varying packet rates, with 205 multiple codecs possible within a given profile. Thus a given call 206 may upgrade or downgrade the codec within the lifetime of the call. 207 Idle channels may generate zero bandwidth. Thus an AAL2 VCC may vary 208 in bandwidth and possibly exceed its contract. Congestion controls 209 within a gateway may react to congestion by modifying codec 210 rates/types. 212 Adapt: The Protocol shall allow for the MGC to instruct the MG of 213 how individual narrow-band calls behave under congestion. 215 AAL5 We have no contribution on this point. 217 Reporting 219 Report: The protocol shall allow for the MGC to gain accounting 220 capabilities from the MG via polling or registration. 222 Accounting information may be passed via the control protocol, or by 224 I-D MSF requirements input to MEGACO April 1999 226 some other means. The Protocol should specify what is included and 227 when it is reported. 229 Report: The Protocol shall allow for the following accounting 230 parameters to be transported from the MG to the MGC: 231 Bandwidth/QoS requested and received 232 Absolute time of connection startup and teardown 233 Types of resources used such as echo cancellers, codecs, 234 receivers, silence suppression, etc. and the duration of utilization 235 of these resources 236 Packet/Cell count including dropped packets/cells during phase. 238 Report: The Protocol shall allow for any accounting parameters shall 239 be passed to the MGC as required by the MGC. This may include: 241 At the end of a call 242 When polled by the MGC 243 At time intervals as specified by the MGC 244 At unit usage thresholds as specified by the MGC 246 Report: The protocol SHOULD allow any end-of-call statistics to show 247 loss/restoration of underlying VCC within the calls duration, 248 together with duration of loss. 250 Report: The protocol SHOULD allow notification, as requested by MGC, 251 of any congestion avoidance actionstaken by the MG. 253 ATM VCCs may be considered as resources under the control of the 254 MGC. Report: The Protocol shall allow for ATM VCCs to be audited by 255 the MGC. 257 Report: The Protocol shall allow for changes in status of ATM VCCs 258 to be notified as requested by the MGC. 260 Report: The protocol shall allow the MGC to query the resource & 261 endpoint availability. Resources may include VCC's, & DSP's. VCCs 262 may be up or down. Endpoints may be connection-free, connected or 263 unavailable. 265 Functionality: 267 Function: The protocol shall allow a command precedence to allow 268 priority messages to supercede non-priority messages. 270 Function: The protocol shall allow an MGC to reserve a bearer, and 271 specify a route for it through the network. 273 Report: The protocol shall allow for the MG to detect and notify as 274 required events in the audio stream. e.g., voice/silence detection. 276 Report: The protocol shall allow the request and notification of 277 mid-call trigger events. 279 Function: The protocol shall transport audio normalization levels as 281 I-D MSF requirements input to MEGACO April 1999 283 a setup parameter. E.g conference bridging. 285 Function: The protocol call setup shall allow for a priority marking 286 to flag a given connection as having a higher priority. 288 Function: The protocol shall allow user configurable 289 extensions/profiles/attributes. 291 Function: The Protocol shall allow the recovery or redistribution of 292 traffic without call/packet loss. 294 Quality of Service: 296 QoS: The protocol shall allow the MGC to specify QoS thresholds, and 297 the MG to notify the MGC of threshold crossing events.. 299 QoS: The protocol shall allow the MGC to modify QoS parameters after 300 the connection is established. 302 Author's Address 304 Matt Holdrege 305 Ascend Communications 306 1701 Harbor Bay Parkway 307 Alameda, CA 94502 USA 308 matt@ascend.com