idnits 2.17.00 (12 Aug 2021) /tmp/idnits23829/draft-zamfir-tsvwg-flow-metadata-rsvp-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 09, 2013) is 3231 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) ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) == Outdated reference: A later version (-01) exists of draft-choukir-tsvwg-flow-metadata-encoding-00 == Outdated reference: A later version (-02) exists of draft-eckert-intarea-flow-metadata-framework-00 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Eckert, Ed. 3 Internet-Draft A. Zamfir 4 Intended status: Standards Track A. Choukir 5 Expires: January 10, 2014 Cisco 6 July 09, 2013 8 Flow Metadata Signaling with RSVP 9 draft-zamfir-tsvwg-flow-metadata-rsvp-00 11 Abstract 13 This specification proposes RSVP protocol extensions for signaling 14 flow metadata attributes. 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 January 10, 2014. 33 Copyright Notice 35 Copyright (c) 2013 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 52 2. Flow Metadata Object . . . . . . . . . . . . . . . . . . . . 2 53 2.1. FLOW_METADATA Class . . . . . . . . . . . . . . . . . . . 3 54 2.1.1. Basic IPFIX FLOW_METADATA Object . . . . . . . . . . 3 55 2.1.2. Enhanced Protocol Independent FLOW_METADATA Object . 3 56 2.2. Semantic of carrying the Metadata Object . . . . . . . . 3 57 2.3. Processing by a Non-Metadata Capable RSVP Router . . . . 4 58 2.4. Processing by a Metadata Capable RSVP Router . . . . . . 4 59 3. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Normative References . . . . . . . . . . . . . . . . . . 5 61 3.2. Informative References . . . . . . . . . . . . . . . . . 5 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 Flow Metadata attributes are information elements (attributes) that 67 identify flow characteristics, such as the type of media carried by 68 application flows (e.g. video), the service class, the application 69 that originated the flow, and others. The description of the Flow 70 Metadata technology and some of the attribute definitions can be 71 found in [I-D.eckert-intarea-flow-metadata-framework]. The flow 72 attributes can be signaled over the flow path and inspected by 73 intermediate network nodes for the purpose of applying differentiated 74 flow treatment or collect network analytics. This specification 75 proposes the use of RSVP as signaling protocol to carry the Flow 76 Metadata using a new RSVP object. Two C-Type values are proposed for 77 this object to allow for two possible encodings. 79 1.1. Requirements Language 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [RFC2119]. 85 2. Flow Metadata Object 87 This specification proposes a new RSVP object with Class-Num from the 88 0x11bbbbbb range. To support informational metadata attribute 89 processing on the path to the receiver, the sender inserts the 90 Metadata object into an IPv4 or IPv6 Path message (i.e. Path messages 91 with SESSION Class = 1 and SENDER_TEMPLATE Class = 11). The Metadata 92 object SHOULD appear only once in the message. 94 The object definition is given in Section 2.1 while the details of 95 processing are covered in Section 2.2 97 2.1. FLOW_METADATA Class 99 FLOW_METADATA Class = 234 101 Two encodings are defined, both of which carry the same IPFIX 102 registered attributes as defined in 103 [I-D.eckert-intarea-flow-metadata-framework]. The first encoding 104 (Basic IPFIX FLOW_METADATA) has less flexibility and lower encoding 105 efficiency. This version of the encoding is refrenced here for 106 legacy reasons. It does not suport a range of options that the 107 second one does, including the signaling of sender and receiver 108 attributes, security elements, distinction of originator of the 109 attributes and ease of extensibility. 111 2.1.1. Basic IPFIX FLOW_METADATA Object 113 Basic IPFIX FLOW_METADATA Object: Class = 234, C-Type = 1 115 o The metadata attributes are encoded in IPFIX format, as described 116 in [RFC5101], with the following restrictions when creating the 117 object: 119 * Options Template Record MUST NOT be present 121 * One and only one Template Record MUST be present 123 * One and only one Data Record MUST be included 125 o An intermediate node that supports this specification SHOULD 126 ignore any Options Template Record. It SHOULD only decode and 127 process the first occurring Template and Data Records. 129 2.1.2. Enhanced Protocol Independent FLOW_METADATA Object 131 Enhanced Protocol Independent FLOW_METADATA Object: Class = 234, 132 C-Type = 2 134 o The contents and encoding rules for this object are specified in 135 [I-D.eckert-intarea-flow-metadata-framework] and 136 [I-D.choukir-tsvwg-flow-metadata-encoding]. 138 2.2. Semantic of carrying the Metadata Object 140 The Metadata Object included in the Path message carries attributes 141 from the sender of the flow towards the receiver. In some cases, 142 e.g. if the sender does not support the generation and signaling of 143 Metadata attribute, these attributes may be inserted by a proxy along 144 the path of the flow. Metadata RSVP nodes on path may modify the 145 metadata attributes for purpose of influencing policy toward the 146 receiver. 148 The node that originates Metadata information in a Path message may 149 do so for the sole purpose of signaling Metadata information. In 150 this case, the SENDER_TSPEC objects fields (as defined by [RFC2210]) 151 should be set to 0: 153 o Token Bucket Rate [r] 155 o Token Bucket Size [b] 157 o Peak Data Rate [p] 159 o Minimum Policed Unit [m] 161 If the Metadata object is inserted in a Path message used for IntServ 162 service [[RFC2210]] reservation requests, then all the rules of RSVP 163 reservation request apply and in addition any actions driven purely 164 by the metadata attributes may equally take place. 166 While the Metadata Object may be included in a Resv message, the 167 specific processing rules for this option is left for followup 168 documents or future versions of this specification. 170 2.3. Processing by a Non-Metadata Capable RSVP Router 172 As described in [RFC2205], a node that does not understand the 173 Metadata object, should ignore but forward it, unexamined and 174 unmodified. When received in Path or Resv messages, it should be 175 saved with the corresponding state and forwarded in any refresh 176 message resulting from that state. 178 2.4. Processing by a Metadata Capable RSVP Router 180 The Metadata object may be inserted by the data flow initiating 181 endpoint or network nodes along the path. The means by which an 182 implementation determines the content of the Metadata object is 183 outside the scope of this document. 185 Intermediate nodes that support this specification, decode the Flow 186 Metadata information as indicated by the C-Type field only when 187 received in Path message. Depending on the attributes, local 188 configuration and policies, the node may take some actions. The 189 Metadata attribute semantics are described in 190 [I-D.eckert-intarea-flow-metadata-framework]. The received Flow 191 Metadata object is stored against the Path state. When a subsequent 192 Path message is received with a modified Metadata object, the 193 intermediate node determines the attributes that have been removed, 194 modified and/or added by comparing the old and new objects, and takes 195 appropriate actions. 197 As a result of these actions, an intermediate node may add new 198 attributes to the Metadata object received in the Path message and 199 signal them downstream. It can also modify some of the attributes 200 present in the Flow Metadata object. RSVP does not have any 201 transport protocol specific restrictions and the exact set of 202 attributes that can be inserted and modified by intermediate nodes is 203 described in [I-D.eckert-intarea-flow-metadata-framework]. Depending 204 on local policies, an intermediate node may also remove some of the 205 attributes received in the Metadata object of a Path message before 206 forwarding downstream. 208 An intermediate node that receives a Resv message with a Metadata 209 Object SHOULD store the object against the state and forward it 210 unexamined and unmodified. 212 3. References 214 3.1. Normative References 216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 217 Requirement Levels", BCP 14, RFC 2119, March 1997. 219 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 220 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 221 Functional Specification", RFC 2205, September 1997. 223 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 224 Services", RFC 2210, September 1997. 226 [RFC5101] Claise, B., "Specification of the IP Flow Information 227 Export (IPFIX) Protocol for the Exchange of IP Traffic 228 Flow Information", RFC 5101, January 2008. 230 3.2. Informative References 232 [I-D.choukir-tsvwg-flow-metadata-encoding] 233 Eckert, T., Zamfir, A., Choukir, A., and C. Eckel, 234 "Protocol Independent Encoding for Signaling Flow 235 Characteristics", draft-choukir-tsvwg-flow-metadata- 236 encoding-00 (work in progress), July 2013. 238 [I-D.eckert-intarea-flow-metadata-framework] 239 Eckert, T., Penno, R., Choukir, A., and C. Eckel, "A 240 Framework for Signaling Flow Characteristics between 241 Applications and the Network", draft-eckert-intarea-flow- 242 metadata-framework-00 (work in progress), July 2013. 244 Authors' Addresses 246 Toerless Eckert (editor) 247 Cisco Systems, Inc. 248 San Jose 249 US 251 Email: eckert@cisco.com 253 Anca Zamfir 254 Cisco Systems, Inc. 255 EPFL, Quartier de l'Innovation 256 Ecublens, Vaud 1015 257 Switzerland 259 Email: ancaz@cisco.com 261 Amine Choukir 262 Cisco Systems, Inc. 263 EPFL, Quartier de l'Innovation 264 Ecublens, Vaud 1015 265 CH 267 Phone: +41 78 75 98 561 268 Email: amchouki@cisco.com