idnits 2.17.1 draft-atarashi-dscp-policy-00.txt: 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 2001) is 8229 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) == Unused Reference: '1' is defined on line 175, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 178, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 184, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 188, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 192, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 195, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 2998 (ref. '7') Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Atarashi 3 Internet-Draft Communications Research Laboratory 4 Expires: April 1, 2002 F. Baker 5 Cisco Systems 6 October 2001 8 Reflexive DSCP Policy 9 draft-atarashi-dscp-policy-00 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 1, 2002. 34 Copyright Notice 36 Copyright (C) The Internet Society (2001). All Rights Reserved. 38 Abstract 40 In reviewing the specific use of the Differentiated Services 41 Architecture for supporting the Internet Emergency Preparedness 42 System, we found what we believe is a general issue. This is that 43 even though a client or peer can connect to a server or peer with a 44 predictable DSCP value, the response does not have a predictable DSCP 45 value. We consider the issues, and recommend an approach to 46 application policy regarding the DSCP. 48 1. Introduction 50 In reviewing the specific use of the Differentiated Services 51 Architecture for supporting the Internet Emergency Preparedness 52 System, we found what we believe is a general issue. This is that 53 even though a client or peer can connect to a server or peer with a 54 predictable DSCP value, the response does not have a predictable DSCP 55 value. We consider the issues, and recommend an approach to 56 application policy regarding the DSCP. 58 As such, we will make specific recommendations for all applications. 59 In doing so, we will use the language described in RFC 2119 [3]. The 60 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC 2119 [3]. 64 1.1 Problem Statement 66 Figure 1 presents a connection being placed between two applications 67 across a differentiated services network. 69 . . . . . . . . . . . . 70 . . . . . . 71 . Client . . . . Server . 72 . /----------/ . . /------------/ . . /---------------/. 73 . Router -----/----- Router Router ----/----- Router . 74 . . . . . . 75 . . . . . . 76 . . . . . . . . . . . . 78 Figure 1: Connection across a network 80 A behavior aggregate originated in part by a certain client toward a 81 given server in a remote network may have certain application 82 requirements, such as requiring service appropriate to an ERP 83 application, video stream, or voice. One application may use 84 different aggregates for different purposes, and therefore have 85 different requirements. So the application may not be able to tell, 86 a priori, with what DSCP it should use or respond. 88 In addition, DSCPs have local significance in the Differentiated 89 Services Architecture. It is possible and perhaps likely that a 90 behavior aggregate might use different code points in different 91 networks. 93 2. Policy recommendations 95 We consider that there are a number of possible approaches to this 96 issue. The simplest, which we fear is currently standard in 97 Differentiated Services hosts, is to simply select a default value, 98 such as "always make TCP applications use AF11". For some 99 applications, such as voice (EF), this approach is appropriate, but 100 for many it is not. 102 2.1 Default DSCP policy in a responder 104 When a system accepts sessions initiated from another system, and 105 there is no specific local policy, the responder SHOULD use the same 106 DSCP Group as its request. Thus, if a TCP SYN arrives using any of 107 AF11, AF12, or AF13, the TCP SYN-ACK and subsequent messages SHOULD 108 use AF11 as the DSCP. When in doubt as to the set of DSCP code 109 points comprising a DSCP Group, it SHOULD respond with exactly the 110 same DSCP. 112 There has been interest of late in changing the quality of service 113 behavior for different portions of the same session, such as on a 114 per-URL basis. The requester could initiate this. Thus, if the DSCP 115 received on one TCP segment differs from the TCP used on a prior TCP 116 segment in a session, the new DSCP SHOULD be reflected unless local 117 policy prevents this. 119 One way to implement this requires the receiving transport (TCP, 120 SCTP, etc) to save the received DSCP and use an API to determine the 121 correct responding DSCP from a configuration file. The configuration 122 file lists the 64 possible DSCP values and the correct response. In 123 most cases, the two SHOULD be the same, but the twelve AFxy code 124 points map to AFx1. Local policy MAY update this mapping. 126 2.2 Application-directed DSCP policy 128 The originator of a session, which is to say the application that 129 opens it, SHOULD normally select the DSCP value used. This, of 130 course, needs to be consistent with local network policy, and may be 131 dictated entirely by that policy. 133 The application would do this through an API, ideally one that maps 134 the application to a DSCP value through local administrative policy. 135 Thus, the API could set the DSCP for signaling of voice calls to a 136 specific value, such as AF31. It would be better, though, if the API 137 were to set it to a key word such as "VoiceSignaling" or 138 "DatabaseAccess", and enable the network administration to interpret 139 the key word to an appropriate code point. One way to implement this 140 would be for the API code to look the key word up in a file or an 141 LDAP Policy. 143 It is possible for the responding application to use this same API. 144 For example, separate policies might apply to database records of one 145 type and database records of another type, something that only the 146 database access application could determine. It is also possible for 147 the application exchange to communicate a desired DSCP, and the 148 responding application to use the API accordingly. In such a case, 149 the application exchange MUST specify the key word rather than the 150 specific DSCP, as it cannot know the applicable policy in the 151 responder's network. 153 3. Security Considerations 155 This document discusses policy, and describes a recommended default 156 policy, for the use of a Differentiated Services Code Point by 157 transports and applications. If implemented as described, it should 158 ask the network to do nothing that the network has not already 159 allowed. If that is the case, no new security issues should arise 160 from the use of such a policy. 162 It is possible, however, for the policy to be applied incorrectly, or 163 for another policy to be applied, which would be incorrect in the 164 network. In that case, a policy issue exists which the network must 165 detect, assess, and deal with. This is a known security issue in any 166 network dependent on policy-directed behavior. 168 4. Acknowledgements 170 The authors would like to thank Hiroyuki Ohno, Toshio Shimojo, 171 Shigeru Miyake and Yoshifumi Atarashi for their suggestions. 173 References 175 [1] "International Emergency Preparedness Scheme", ITU E.106, March 176 2000. 178 [2] "Service Description for an International Emergency Multimedia 179 Service (Draft)", ITU-T F.706, August 2001. 181 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 182 Levels", BCP 14, RFC 2119, March 1997. 184 [4] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of 185 the Differentiated Services Field (DS Field) in the IPv4 and 186 IPv6 Headers", RFC 2474, December 1998. 188 [5] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. 189 Weiss, "An Architecture for Differentiated Services", RFC 2475, 190 December 1998. 192 [6] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured 193 Forwarding PHB Group", RFC 2597, June 1999. 195 [7] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, 196 M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A 197 Framework for Integrated Services Operation over Diffserv 198 Networks", RFC 2998, November 2000. 200 Authors' Addresses 202 Rei S. Atarashi 203 Communications Research Laboratory 204 4-2-1 Nukui-Kitamachi 205 Koganei, Tokyo 184-8795 206 JP 208 Phone: +81-42-327-6243 209 Fax: +81-42-327-9041 210 EMail: ray@crl.go.jp 211 Fred Baker 212 Cisco Systems 213 1121 Via Del Rey 214 Santa Barbara, CA 93117 215 US 217 Phone: +1-408-526-4257 218 Fax: +1-413-473-2403 219 EMail: fred@cisco.com 221 Full Copyright Statement 223 Copyright (C) The Internet Society (2001). All Rights Reserved. 225 This document and translations of it may be copied and furnished to 226 others, and derivative works that comment on or otherwise explain it 227 or assist in its implementation may be prepared, copied, published 228 and distributed, in whole or in part, without restriction of any 229 kind, provided that the above copyright notice and this paragraph are 230 included on all such copies and derivative works. However, this 231 document itself may not be modified in any way, such as by removing 232 the copyright notice or references to the Internet Society or other 233 Internet organizations, except as needed for the purpose of 234 developing Internet standards in which case the procedures for 235 copyrights defined in the Internet Standards process must be 236 followed, or as required to translate it into languages other than 237 English. 239 The limited permissions granted above are perpetual and will not be 240 revoked by the Internet Society or its successors or assigns. 242 This document and the information contained herein is provided on an 243 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 244 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 245 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 246 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 247 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 249 Acknowledgement 251 Funding for the RFC Editor function is currently provided by the 252 Internet Society.