idnits 2.17.1 draft-ietf-megaco-h248i-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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.) -- The document date (July 2000) is 8687 days in the past. Is this intentional? 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? '1' on line 12 looks like a reference -- Missing reference section? '2' on line 42 looks like a reference -- Missing reference section? '3' on line 209 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Media Gateway Control (Megaco) Alf Heidermark 2 Internet Draft Ericsson 3 Document: draft-ietf-megaco-h248i-00.txt July 2000 4 Category: Standards Track 6 H.248 Annex I (Pre-Decision White Document) 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [1]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. Internet-Drafts are draft documents valid for a maximum of 17 six months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- Drafts 19 as reference material or to cite them other than as "work in 20 progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 1. Abstract 28 This document reproduces the content of the ITU-T Study Group 16 29 White Document draft of H.248 Annex I, which is scheduled for 30 decision in Geneva in November 2000. H.248 Annex H describes 31 procedures for transport of the Megaco protocol over ATM. 33 This document is submitted for IETF comment prior to ITU-T decision, 34 in accordance with procedures currently being negotiated between 35 ITU-T Study Group and ISOC on behalf of the IETF. 37 2. Conventions used in this document 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 41 this document are to be interpreted as described in RFC-2119 [2]. 43 3. Transport over MTP 3B/N-SAL/AAL5 45 Megaco/H.248 protocol messages may be transmitted over an SS 7 46 network. Service indicator value 14 shall be used. These protocol 47 messages is using the services of MTP 3 B as described in 48 recommendation Q.2210. 50 Heidermark Standards Track - Expires January 2001 1 51 In a transaction-oriented protocol there are still ways for 52 transaction requests or responses to be lost. As such it is 53 recommended that entities using MTP 3 B transport implement 54 application timers for each TransactionRequest. 56 3.1 Providing At-Most-Once Functionality 58 Messages, being carried over MTP3B, may be subject to losses. In the 59 absence of a timely response, commands are repeated. Most commands 60 are not idempotent. The state of the MG would become unpredictable 61 if, for example, Add commands were executed several times.The 62 transmission procedures shall thus provide an "At-Most-Once" 63 functionality. 65 To guard against such losses, it is recommended that entities follow 66 the procedures in Megaco/H.248 Section D.1.1 with the exception of 67 the use of LONG-TIMER and TransactionResponseAck parameter, which 68 shall not be used. 70 3.2 Transaction identifiers and three way handshake 72 3.2.1 Transaction identifiers 74 Megaco/H.248 Section D.1.2.1 is recommended to be followed. 76 3.2.2 Three way handshake 78 It is not applicable. 80 3.3 Computing retransmission timers 82 With reliable delivery, as MTP 3B provides, the incidence of loss of 83 a transaction request or reply is expected to be very low. 84 Therefore, only simple timer mechanisms are required. E.g The first 85 retransmission of a request can occur after a short interval. If 86 additional retransmissions are required a longer time interval is 87 recommended between the retransmissions. 89 3.4 Provisional responses 91 The basic procedures in Megaco/H.248 section 8.2.3 apply. 93 3.5 Ordering of commands 95 MTP 3B provides ordered delivery of transactions therefore no 96 special procedures are required. 98 4. Transport using SSCOP 100 Protocol messages described in this document may be transmitted via 101 SSCOP links. These protocol messages are using the services of SSCOP 102 as described in recommendation Q.2110. 104 Heidermark Standards Track - Expires January 2000 2 105 In a transaction-oriented protocol there are still ways for 106 transaction requests or responses to be lost. As such, it is 107 recommended that entities using SSCOP transport implement 108 application timers for each request and response. 110 4.1 Providing the At-Most-Once functionality 112 Messages, being carried over SSCOP, are not subject to transport 113 losses, but loss of a transaction request or its reply may none-the- 114 less be noted in real implementations. In the absence of a timely 115 response, commands are repeated. Most commands are not idempotent. 116 The state of the MG would become unpredictable if, for example, Add 117 commands were executed several times. 119 To guard against such losses, it is recommended that entities follow 120 the procedures in Megaco/H.248 Section D.1.1. 122 4.2 Transaction identifiers and three way handshake 124 4.2.1 Transaction identifiers 126 Megaco/H.248 Section D.1.2.1 applies. 128 4.2.2 Three way handshake 130 It is possible that transaction replies may be lost even with a 131 reliable delivery protocol such as SSCOP. Entities, using SSCOP 132 shall follow the procedures in Megaco/H.248 Section D.1.2.1. 134 4.3 Computing retransmission timers 136 With reliable delivery, the incidence of loss of a transaction 137 request or reply is expected to be very low. Therefore, only simple 138 timer mechanisms are required. 140 4.4 Provisional responses 142 The basic procedure of Megaco/H.248 Section 8.2.3 applies. 143 Entities that receive a Transaction Pending shall switch to a longer 144 repetition timer for that transaction. Entities shall retain 145 Transactions and replies until they are confirmed. The procedure of 146 Megaco/H.248 Section D.2.4 should be followed, but simple timer 147 values should be sufficient. 149 4.5 Ordering of commands 151 SSCOP provided ordered delivery of transactions. No special 152 procedures are required. 154 Heidermark Standards Track - Expires January 2000 3 155 5. Transport using TYPE 5 AAL with ALF 157 Protocol messages defined in this document may be transmitted via 158 type 5 AAL links. These messages are using the services of Type 5 159 AAL as described in recommendation I.361. 161 In a transaction-oriented protocol there are still ways for 162 transaction requests or responses to be lost. As such, it is 163 recommended that entities using type 5 AAL transport implement 164 application level timers for each request and each response, similar 165 to those specified for application level framing over UDP. 167 5.1 Providing the At-Most-Once functionality 169 Messages, being carried over Type 5 AAL, may be subject to losses. 170 In the absence of a timely response, commands are repeated. Most 171 commands are not idempotent. The state of the MG would become 172 unpredictable if, for example, Add commands were executed several 173 times. The transmission procedures shall thus provide an "At-Most- 174 Once" functionality. 176 To guard against such losses, it is recommended that entities follow 177 the procedures in Megaco/H.248 Section D.1.1. 179 5.2 Transaction identifiers and three way handshake 181 5.2.1 Transaction identifiers 183 Megaco/H.248 Section D.1.2.1 applies. 185 5.2.2 Three way handshake 187 When Type 5 AAL is used as transport the entities shall follow the 188 procedures in Megaco/H.248 Section D.1.2.2. 190 5.3 Computing retransmission timers 192 When Type 5 AAL is used as transport the entities shall provide the 193 same type of calculation as described in Megaco/H.248 Section D.1.3. 195 5.4 Provisional responses 197 When Type 5 AAL is used as transport the entities shall follow the 198 procedures in Megaco/H.248 Section D.1.4. 200 5.5 Ordering of commands 202 When Type 5 AAL is used as transport the entities shall follow the 203 procedures in Megaco/H.248 Section 9.1. 205 Heidermark Standards Track - Expires January 2000 4 206 6. Security Considerations 208 Security considerations regarding media gateway control are 209 discussed in section 10 of [3]. 211 7. References 213 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 214 9, RFC 2026, October 1996. 216 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 217 Levels", BCP 14, RFC 2119, March 1997. 219 3 ITU-T Recommendation H.248, "Gateway Control Protocol", Geneva, 220 June 2000. Also to appear as RFC xxxx (currently draft-ietf- 221 megaco-merged-01.txt). 223 4 ITU-T Recommendation Q.2110. 225 5 ITU-T Recommendation Q.2210. 227 6 ITU-T Recommendation I.361. 229 6. Authors' Addresses 231 Alf Heidermark (editor) 232 Ericsson 233 Tel:+46 87273894 234 E-mail: alf.heidermark@uab.ericsson.se 236 Heidermark Standards Track - Expires January 2000 5