idnits 2.17.1 draft-krishnan-conex-destopt-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 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 (July 4, 2011) is 4674 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 151, but not defined == Unused Reference: 'CAM' is defined on line 156, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 163, but no explicit reference was found in the text == 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 (~~), 6 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: January 5, 2012 IKR University of Stuttgart 6 C. Ucendo 7 Telefonica 8 July 4, 2011 10 IPv6 Destination Option for Conex 11 draft-krishnan-conex-destopt-00 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 January 5, 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 . . . . . . . . . . . . . . . . . . . . 5 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 61 8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 Conex is a mechanism by which senders inform the network about the 67 congestion encountered by packets earlier in the same flow. This 68 document specifies an IPv6 destination option that can be used for 69 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 5. Acknowledgements 137 The authors would like to thank Marcelo Bagnulo, Bob Briscoe, Ingemar 138 Johansson, Joel Halpern and John Leslie for the discussions that led 139 to this document. 141 6. Security Considerations 143 This document does not bring up any new security issues. 145 7. IANA Considerations 147 This document defines a new IPv6 destination option for carrying 148 conex markings. IANA is requested to assign a new destination option 149 type in the Destination Options registry maintained at 150 http://www.iana.org/assignments/ipv6-parameters Conex 151 Destination Option [RFCXXXX] The act bits for this option need to be 152 10 and the chg bit needs to be 0. 154 8. Normative References 156 [CAM] Briscoe, B., "Congestion Exposure (ConEx) Concepts and 157 Abstract Mechanism", draft-ietf-conex-abstract-mech-01 158 (work in progress), March 2011. 160 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 161 Requirement Levels", BCP 14, RFC 2119, March 1997. 163 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 164 (IPv6) Specification", RFC 2460, December 1998. 166 Authors' Addresses 168 Suresh Krishnan 169 Ericsson 170 8400 Blvd Decarie 171 Town of Mount Royal, Quebec 172 Canada 174 Email: suresh.krishnan@ericsson.com 175 Mirja Kuehlewind 176 IKR University of Stuttgart 178 Email: mirja.kuehlewind@ikr.uni-stuttgart.de 180 Carlos Ralli Ucendo 181 Telefonica 183 Email: ralli@tid.es