idnits 2.17.1 draft-petithuguenin-dispatch-rtp-pmtud-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2601 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: 'XEP-0166' is mentioned on line 98, but not defined == Outdated reference: A later version (-20) exists of draft-ietf-tram-stun-pmtud-05 ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH M. Petit-Huguenin 3 Internet-Draft Impedance Mismatch 4 Intended status: Standards Track G. Salgueiro 5 Expires: September 14, 2017 Cisco 6 March 13, 2017 8 Path MTU Discovery (PMTUD) for RTP/RTCP 9 draft-petithuguenin-dispatch-rtp-pmtud-00 11 Abstract 13 This document describes an implementation of the Path MTU Discovery 14 (PMTUD) protocol for RTP sessions. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 14, 2017. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Overview of Operations . . . . . . . . . . . . . . . . . . . 2 52 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 4. Probe Support Signaling . . . . . . . . . . . . . . . . . . . 3 54 5. Path MTU Discovery Using the Simple Probing Mechanism . . . . 3 55 6. Path MTU Discovery Using the Complete Probing Mechanism . . . 3 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 60 9.2. Informative References . . . . . . . . . . . . . . . . . 5 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 The Guidelines for Writers of RTP Payload Formats (RFC 2736,BCP 36 66 [RFC2736]) states in Section 4 that "[i]f a codec's frame size is 67 larger than the MTU, the payload format must not rely on IP 68 fragmentation." Similarly, RFC 3550 [RFC3550] states that "...only 69 the subset [of RR packets into one compound RTCP packet] that will 70 fit into one MTU SHOULD be included in each interval." 72 These statements can be extended to the Path MTU, as fragmentation 73 along the media path is no better than fragmentation on the first 74 link-layer. 76 RTP and RTCP [RFC3550] were not designed with a mechanism to discover 77 the Path MTU, so this document describes a way to add this capability 78 by using the PMTUD protocol defined in [I-D.ietf-tram-stun-pmtud]. 80 2. Overview of Operations 82 Multiplexing between RTP/RTCP packets and STUN packets is a well- 83 known technique used for example to discover the IP address of a NAT 84 [RFC5389] or to check connectivity [RFC5245]. 86 The PMTUD mechanism for RTP/RTCP uses either the Simple Probing 87 Mechanism described in Section 4.1 of [I-D.ietf-tram-stun-pmtud] or 88 the Complete Probing Mechanism described in Section 4.2. 90 3. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 4. Probe Support Signaling 98 Real-time media protocols (SIP [RFC3261], Jingle [XEP-0166]) that are 99 using the Offer/Answer protocol [RFC3264] signals their support of 100 this specification by the usage of an "a:x-pmtud" attribute in the 101 SDP. This attribute can be used at the session-level or at the 102 media-level. 104 An Offerer indicates the support of this specification by adding an 105 "a:x-pmtud" attribute in the SDP sent. An Answerer receiving an SDP 106 containing an "a:x-pmtud" attribute and supporting this specification 107 can immediately start probing for the PMTU, as described in 108 Section 5.2 of [I-D.ietf-tram-stun-pmtud]. Even if the SDP received 109 by an Answerer does not contain an "a:x-pmtud" attribute, an Answerer 110 supporting this specification MUST insert an "a:x-pmtud" attribute in 111 the SDP it will send. 113 Realtime media protocols that support ICE [RFC5245] (i.e. WebRTC, in 114 addition to the protocols listed above) MAY signal that a specific 115 candidate support for this specification differs from what is 116 declared at the session-level or media-level of the SDP by inserting 117 an extension attribute with values "pmtud on" or "pmtud off" in the 118 candidate line. 120 5. Path MTU Discovery Using the Simple Probing Mechanism 122 When initiating the Probe transactions, as described in Section 4.1 123 of [I-D.ietf-tram-stun-pmtud], the RTP/RTCP client MUST use the same 124 IP address and port destination that are used as the destination for 125 the RTP or RTCP packets. 127 The server side MUST be prepared to demultiplex the Probe Requests 128 from the RTP/RTCP packets and other STUN messages. 130 6. Path MTU Discovery Using the Complete Probing Mechanism 132 When sending the Probe Indications, the RTP/RTCP client MUST use the 133 same source IP address and port and same IP address and port 134 destination that are used for the RTP or RTCP packets. 136 Any STUN message sent along the RTP/RTCP packets, like ICE 137 connectivity checks, media keep-alive, or consent packets MUST be 138 used to populate the identifier list described in Section 4.2.3 of 139 [I-D.ietf-tram-stun-pmtud]. 141 For a STUN message, the identifier is made up of the first 12 bytes 142 of the Transaction ID. 144 For an RTP packet, the identifier is made up of the SSRC concatenated 145 with the Sequence Number, for a total of 12 bytes. 147 For an RTCP packet, the identifier is made up of the Reporter SSRC 148 concatenated with the last 4 bytes of the Extended Highest Sequence 149 Number Received, for a total of 12 bytes. 151 7. Security Considerations 153 TBD. 155 8. IANA Considerations 157 TBD 159 9. References 161 9.1. Normative References 163 [I-D.ietf-tram-stun-pmtud] 164 Petit-Huguenin, M. and G. Salgueiro, "Path MTU Discovery 165 Using Session Traversal Utilities for NAT (STUN)", draft- 166 ietf-tram-stun-pmtud-05 (work in progress), February 2017. 168 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 169 Requirement Levels", BCP 14, RFC 2119, 170 DOI 10.17487/RFC2119, March 1997, 171 . 173 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 174 with Session Description Protocol (SDP)", RFC 3264, 175 DOI 10.17487/RFC3264, June 2002, 176 . 178 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 179 Jacobson, "RTP: A Transport Protocol for Real-Time 180 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 181 July 2003, . 183 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 184 (ICE): A Protocol for Network Address Translator (NAT) 185 Traversal for Offer/Answer Protocols", RFC 5245, 186 DOI 10.17487/RFC5245, April 2010, 187 . 189 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 190 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 191 DOI 10.17487/RFC5389, October 2008, 192 . 194 9.2. Informative References 196 [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP 197 Payload Format Specifications", BCP 36, RFC 2736, 198 DOI 10.17487/RFC2736, December 1999, 199 . 201 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 202 A., Peterson, J., Sparks, R., Handley, M., and E. 203 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 204 DOI 10.17487/RFC3261, June 2002, 205 . 207 Authors' Addresses 209 Marc Petit-Huguenin 210 Impedance Mismatch 212 Email: marc@petit-huguenin.org 214 Gonzalo Salgueiro 215 Cisco Systems, Inc. 216 7200-12 Kit Creek Road 217 Research Triangle Park, NC 27709 218 United States 220 Email: gsalguei@cisco.com