idnits 2.17.1 draft-ietf-megaco-h248h-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 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. ** The abstract seems to contain references ([4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 8686 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? '4' on line 46 looks like a reference -- Missing reference section? '2' on line 42 looks like a reference -- Missing reference section? '3' on line 148 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 6 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-h248h-00.txt July 2000 4 Category: Standards Track 6 H.248 Annex H (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 H, 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 SCTP [4]. 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. Overview 45 Megaco protocol messages may be transmitted over the Simple Control 46 Transmission Protocol (SCTP) [4]. 48 Heidermark Standards Track - Expires January 2001 1 49 The implementation may take advantage of the following services 50 provided by SCTP: 51 . Datagram-based transport 52 . Reliable delivery --- As a reliable transport protocol, SCTP 53 provides recovery mechanisms for transmission loss and 54 duplicate packet receipt. This simplifies the design of 55 application level repetition and timer control. 56 . Ordered and unordered reliable message delivery --- Settable on 57 a per-message basis by the application, SCTP allows high 58 priority transactions be sent through unordered delivery for 59 possible expedited treatment. 60 . Stream capability --- SCTP can provide up to 65536 61 unidirectional streams in each direction of an MGC-MG 62 association. SCTP transmits messages and processes received 63 messages in one stream independent to the order or status of 64 messages in any other streams. The application may effectively 65 avoid head-of-line blocking by transmitting unrelated 66 transactions on different streams . 67 . Protection against _SYN_ attacks --- The encryption cookie 68 mechanism built into the SCTP provides protection against the 69 equivalent of TCP _SYN_ attacks on a MG or MGC node 70 . Network congestion management --- SCTP provides effective means 71 for detecting and handling network congestion. 72 . Redundant path management --- It may become strongly desirable 73 for a large MG to have fault resilient network-level 74 connectivity towards an MGC. SCTP supports multi-homed IP 75 nodes for redundant path deployment. SCTP provides reachability 76 monitoring, fast switch-over/fail-over, and potentially load 77 balancing over redundant paths. 79 In a transaction-oriented protocol like Megaco/H.248, there are 80 still ways for transaction requests or responses to be lost, e.g., 81 caused by entity/component failure. As such, it is recommended that 82 entities using SCTP transport implement application level timers for 83 each request. 85 4. Providing the At-Most-Once functionality 87 SCTP is designed to recover from transport losses or duplications, 88 but loss of a transaction request or its reply may nonetheless be 89 noted in real implementations. In the absence of a timely response, 90 Megaco/H.248 may repeat commands. Most Megaco/H.248 commands are not 91 idempotent. The state of the MG would become unpredictable if, for 92 example, Add commands were executed several times. 94 To guard against such losses, it is recommended that entities follow 95 the procedures in Megaco/H.248 Annex D.1.1. with the exception LONG- 96 TIMER or the use of the TransactionResponseAck parameter, which 97 shall not be used. 99 Heidermark Standards Track - Expires January 2000 2 100 5. Transaction identifiers and three way handshake 102 5.1 Transaction identifiers 104 Megaco/H.248 Section D.1.2.1 is recommended to be followed. 106 5.2 Three way handshake 108 It is not applicable. 110 6. Computing retransmission timers 112 With reliable non-duplicate delivery guaranteed by SCTP, application 113 level timers are only used to guard against entity/component 114 failure. Therefore, only simple timer mechanisms are required. 115 Exponential back-off algorithms shall not be necessary. The first 116 retransmission of a request can occur after a short interval. If 117 additional retransmissions are required a longer time interval is 118 recommended between the retransmissions. 120 7. Provisional responses 122 The basic procedures in section 8.2.3 of this document apply. 124 8. Ordering of commands 126 SCTP provides both ordered and unordered reliable delivery, settable 127 on a per-transaction basis. Therefore, Megaco/H.248 can take 128 advantage of the ordered capability of SCTP. High priority 129 transactions can get expedited treatment by properly using unordered 130 delivery. No special procedures are therefore required. 132 9. Stream independence 134 SCTP can provide up to 65536 unidirectional streams in each 135 direction of an MGC-MG association. SCTP transmits messages and 136 processes received messages in one stream independent to the order 137 or status of messages in any other streams. Megaco/H.248 may avoid 138 head-of-line blocking by transmitting unrelated transactions on 139 different streams. Reliability is still provided. Ordering of 140 messages is available per-stream. 142 It is recommended that transactions related to one context are 143 transported over the same stream. 145 10. Security Considerations 147 Security considerations regarding media gateway control are 148 discussed in section 10 of [3]. 150 Heidermark Standards Track - Expires January 2000 3 151 11. References 153 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 154 9, RFC 2026, October 1996. 156 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 157 Levels", BCP 14, RFC 2119, March 1997. 159 3 ITU-T Recommendation H.248, "Gateway Control Protocol", Geneva, 160 June 2000. Also to appear as RFC xxxx (currently draft-ietf- 161 megaco-merged-01.txt). 163 4 R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. 164 Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxon, "Stream Control 165 Transmission Protocol", draft-ietf-sigtran-sctp-11.txt, Internet 166 Engineering Task Force, 6 July 2000. 168 6. Authors' Addresses 170 Alf Heidermark (editor) 171 Ericsson 172 Tel:+46 87273894 173 E-mail: alf.heidermark@uab.ericsson.se 175 Heidermark Standards Track - Expires January 2000 4