idnits 2.17.1 draft-ietf-conex-destopt-01.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 30, 2011) is 4559 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: 'RFCXXXX' is mentioned on line 194, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-conex-abstract-mech-01 ** Downref: Normative reference to an Informational draft: draft-ietf-conex-abstract-mech (ref. 'CAM') ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 conex Working Group S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Standards Track M. Kuehlewind 5 Expires: May 2, 2012 IKR University of Stuttgart 6 C. Ucendo 7 Telefonica 8 October 30, 2011 10 IPv6 Destination Option for Conex 11 draft-ietf-conex-destopt-01 13 Abstract 15 Conex is a mechanism by which senders inform the network about the 16 congestion encountered by packets earlier in the same flow. This 17 document specifies an IPv6 destination option that is capable of 18 carrying conex markings in IPv6 datagrams. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 2, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions used in this document . . . . . . . . . . . . . . . 3 56 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Conex Destination Option (CDO) . . . . . . . . . . . . . . . . 4 58 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 Conex [CAM] is a mechanism by which senders inform the network about 67 the congestion encountered by packets earlier in the same flow. This 68 document specifies an IPv6 destination option [RFC2460] that can be 69 used for performing conex markings in IPv6 datagrams. 71 2. Conventions used in this document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 3. Background 79 The Conex working group came up with a list of requirements that had 80 to be met by any marking mechanism. It then considered several 81 alternative mechanisms and evaluated their suitability for conex 82 marking. There were no mechanisms found that were completely 83 suitable, but the only mechanism that came close to meeting the 84 requirements was IPv6 destination options. The analysis of the 85 different alternatives can be found in [draft-krishnan-conex-ipv6]. 87 4. Conex Destination Option (CDO) 89 The Conex Destination Option (CDO) is a destination option that can 90 be included in IPv6 datagrams that are sent by conex-aware senders in 91 order to inform conex-aware nodes on the path about the CDO has an 92 alignment requirement of (none). 94 0 1 2 3 95 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | Option Type | Option Length | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 |X|L|E|C| Reserved | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 Figure 1: Conex Destination Option Layout 104 Option Type 106 8-bit identifier of the type of option. The option identifier 107 for the conex destination option will be allocated by the IANA. 109 Option Length 111 8-bit unsigned integer. The length of the option (excluding 112 the Option Type and Option Length fields). This field MUST be 113 set to the value 4. 115 X Bit 116 When this bit is set, the transport sender is using ConEx with 117 this packet. If it is reset, the sender is not using ConEx. 119 L Bit 121 When this bit is set, the transport sender has experienced a loss. 122 If it is reset, the sender has not experienced a loss. 124 E Bit 126 When this bit is set, the transport sender has experienced 127 ECN-signaled congestion. If it is reset, the sender has not 128 experienced ECN-signaled congestion. 130 C Bit 132 When this bit is set, the transport sender is building up 133 congestion credit. Otherwise it is not. 135 All packets of a ConEx-capable connection MUST carry the CDO. 137 If the X bit is the zero all other three bits MUST be zero as well. 138 If the X bit is zero that means that the connection is ConEx-capable 139 but this packet SHOULD NOT be accounted to determine ConEx 140 information in an audit function. This can be the case for e.g. pure 141 control packets not carrying any user data. As an example in TCP 142 pure ACKs are usually not ECN-capable and TCP does not have an 143 mechanism to announce the lost of a pure ACK to the sender. Thus 144 congestion information about the ACKs are not available at the 145 sender. An audit function MUST be aware of this possibility and 146 SHOULD ensure that not a large amount of data is sent as not-ConEx 147 capable with a ConEx capable connection. 149 If the X bit is set, all three other bit (L, E, C) MAY be set. When 150 ever one if this bits is set, the number of bytes carried by this IP 151 packet (incl. IP header) SHOULD be accounted when determining 152 congestion or credit information. In IPv6 the length ca easily be 153 calculated by the value given in the Payload Length header field 154 (payload length + option space) plus a fixed value of 40 Bytes for 155 the IP header itself. 157 In principle all of these three bits (L, E, C) MAY be set in the same 158 packet. In this case the packet size MUST be accounted more than 159 once for each respective ConEx information counter. In practice loss 160 and ECN marks can not occur at the same time, so there should usually 161 be a way to signal the respective ConEx information in different 162 packets. In many cases if congestion occurs the sender will not sent 163 additional credit bit, but if e.g. a sender assumes losses because of 164 an audit function or needs to maintain a certain sending rate to make 165 an application layer service work, the occurrence of credit bits (c) 166 in parallel to congestion exposure bit (L, E) is reasonable. 168 If a network node extracts the ConEx information from a connection, 169 this node is usually supposed to hold this information byte-wise, 170 e.g. comparing the total number of bytes sent with the number of 171 bytes sent with ConEx congestion mark (L, E) to determine the current 172 whole path congestion level. When equally sized packets can be 173 assumed accounting the number of packets (and comparing the total 174 number to marked once) should deliver the same result. But a network 175 node MUST be aware that this estimation can be quite wrong and thus 176 is not reliable if e.g. different sized packed are send. 178 5. Acknowledgements 180 The authors would like to thank Marcelo Bagnulo, Bob Briscoe, Ingemar 181 Johansson, Joel Halpern and John Leslie for the discussions that led 182 to this document. 184 6. Security Considerations 186 This document does not bring up any new security issues. 188 7. IANA Considerations 190 This document defines a new IPv6 destination option for carrying 191 conex markings. IANA is requested to assign a new destination option 192 type in the Destination Options registry maintained at 193 http://www.iana.org/assignments/ipv6-parameters Conex 194 Destination Option [RFCXXXX] The act bits for this option need to be 195 10 and the chg bit needs to be 0. 197 8. Normative References 199 [CAM] Briscoe, B., "Congestion Exposure (ConEx) Concepts and 200 Abstract Mechanism", draft-ietf-conex-abstract-mech-01 201 (work in progress), March 2011. 203 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 204 Requirement Levels", BCP 14, RFC 2119, March 1997. 206 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 207 (IPv6) Specification", RFC 2460, December 1998. 209 Authors' Addresses 211 Suresh Krishnan 212 Ericsson 213 8400 Blvd Decarie 214 Town of Mount Royal, Quebec 215 Canada 217 Email: suresh.krishnan@ericsson.com 219 Mirja Kuehlewind 220 IKR University of Stuttgart 222 Email: mirja.kuehlewind@ikr.uni-stuttgart.de 223 Carlos Ralli Ucendo 224 Telefonica 226 Email: ralli@tid.es