Internet Engineering Task Force T. Eckert, Ed. Internet-Draft A. Zamfir Intended status: Standards Track A. Choukir Expires: January 10, 2014 Cisco July 09, 2013 Flow Metadata Signaling with RSVP draft-zamfir-tsvwg-flow-metadata-rsvp-00 Abstract This specification proposes RSVP protocol extensions for signaling flow metadata attributes. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 10, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Eckert, et al. Expires January 10, 2014 [Page 1] Internet-Draft FMD-RSVP July 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Flow Metadata Object . . . . . . . . . . . . . . . . . . . . 2 2.1. FLOW_METADATA Class . . . . . . . . . . . . . . . . . . . 3 2.1.1. Basic IPFIX FLOW_METADATA Object . . . . . . . . . . 3 2.1.2. Enhanced Protocol Independent FLOW_METADATA Object . 3 2.2. Semantic of carrying the Metadata Object . . . . . . . . 3 2.3. Processing by a Non-Metadata Capable RSVP Router . . . . 4 2.4. Processing by a Metadata Capable RSVP Router . . . . . . 4 3. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Normative References . . . . . . . . . . . . . . . . . . 5 3.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Flow Metadata attributes are information elements (attributes) that identify flow characteristics, such as the type of media carried by application flows (e.g. video), the service class, the application that originated the flow, and others. The description of the Flow Metadata technology and some of the attribute definitions can be found in [I-D.eckert-intarea-flow-metadata-framework]. The flow attributes can be signaled over the flow path and inspected by intermediate network nodes for the purpose of applying differentiated flow treatment or collect network analytics. This specification proposes the use of RSVP as signaling protocol to carry the Flow Metadata using a new RSVP object. Two C-Type values are proposed for this object to allow for two possible encodings. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Flow Metadata Object This specification proposes a new RSVP object with Class-Num from the 0x11bbbbbb range. To support informational metadata attribute processing on the path to the receiver, the sender inserts the Metadata object into an IPv4 or IPv6 Path message (i.e. Path messages with SESSION Class = 1 and SENDER_TEMPLATE Class = 11). The Metadata object SHOULD appear only once in the message. The object definition is given in Section 2.1 while the details of processing are covered in Section 2.2 Eckert, et al. Expires January 10, 2014 [Page 2] Internet-Draft FMD-RSVP July 2013 2.1. FLOW_METADATA Class FLOW_METADATA Class = 234 Two encodings are defined, both of which carry the same IPFIX registered attributes as defined in [I-D.eckert-intarea-flow-metadata-framework]. The first encoding (Basic IPFIX FLOW_METADATA) has less flexibility and lower encoding efficiency. This version of the encoding is refrenced here for legacy reasons. It does not suport a range of options that the second one does, including the signaling of sender and receiver attributes, security elements, distinction of originator of the attributes and ease of extensibility. 2.1.1. Basic IPFIX FLOW_METADATA Object Basic IPFIX FLOW_METADATA Object: Class = 234, C-Type = 1 o The metadata attributes are encoded in IPFIX format, as described in [RFC5101], with the following restrictions when creating the object: * Options Template Record MUST NOT be present * One and only one Template Record MUST be present * One and only one Data Record MUST be included o An intermediate node that supports this specification SHOULD ignore any Options Template Record. It SHOULD only decode and process the first occurring Template and Data Records. 2.1.2. Enhanced Protocol Independent FLOW_METADATA Object Enhanced Protocol Independent FLOW_METADATA Object: Class = 234, C-Type = 2 o The contents and encoding rules for this object are specified in [I-D.eckert-intarea-flow-metadata-framework] and [I-D.choukir-tsvwg-flow-metadata-encoding]. 2.2. Semantic of carrying the Metadata Object The Metadata Object included in the Path message carries attributes from the sender of the flow towards the receiver. In some cases, e.g. if the sender does not support the generation and signaling of Metadata attribute, these attributes may be inserted by a proxy along the path of the flow. Metadata RSVP nodes on path may modify the Eckert, et al. Expires January 10, 2014 [Page 3] Internet-Draft FMD-RSVP July 2013 metadata attributes for purpose of influencing policy toward the receiver. The node that originates Metadata information in a Path message may do so for the sole purpose of signaling Metadata information. In this case, the SENDER_TSPEC objects fields (as defined by [RFC2210]) should be set to 0: o Token Bucket Rate [r] o Token Bucket Size [b] o Peak Data Rate [p] o Minimum Policed Unit [m] If the Metadata object is inserted in a Path message used for IntServ service [[RFC2210]] reservation requests, then all the rules of RSVP reservation request apply and in addition any actions driven purely by the metadata attributes may equally take place. While the Metadata Object may be included in a Resv message, the specific processing rules for this option is left for followup documents or future versions of this specification. 2.3. Processing by a Non-Metadata Capable RSVP Router As described in [RFC2205], a node that does not understand the Metadata object, should ignore but forward it, unexamined and unmodified. When received in Path or Resv messages, it should be saved with the corresponding state and forwarded in any refresh message resulting from that state. 2.4. Processing by a Metadata Capable RSVP Router The Metadata object may be inserted by the data flow initiating endpoint or network nodes along the path. The means by which an implementation determines the content of the Metadata object is outside the scope of this document. Intermediate nodes that support this specification, decode the Flow Metadata information as indicated by the C-Type field only when received in Path message. Depending on the attributes, local configuration and policies, the node may take some actions. The Metadata attribute semantics are described in [I-D.eckert-intarea-flow-metadata-framework]. The received Flow Metadata object is stored against the Path state. When a subsequent Path message is received with a modified Metadata object, the Eckert, et al. Expires January 10, 2014 [Page 4] Internet-Draft FMD-RSVP July 2013 intermediate node determines the attributes that have been removed, modified and/or added by comparing the old and new objects, and takes appropriate actions. As a result of these actions, an intermediate node may add new attributes to the Metadata object received in the Path message and signal them downstream. It can also modify some of the attributes present in the Flow Metadata object. RSVP does not have any transport protocol specific restrictions and the exact set of attributes that can be inserted and modified by intermediate nodes is described in [I-D.eckert-intarea-flow-metadata-framework]. Depending on local policies, an intermediate node may also remove some of the attributes received in the Metadata object of a Path message before forwarding downstream. An intermediate node that receives a Resv message with a Metadata Object SHOULD store the object against the state and forward it unexamined and unmodified. 3. References 3.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. 3.2. Informative References [I-D.choukir-tsvwg-flow-metadata-encoding] Eckert, T., Zamfir, A., Choukir, A., and C. Eckel, "Protocol Independent Encoding for Signaling Flow Characteristics", draft-choukir-tsvwg-flow-metadata- encoding-00 (work in progress), July 2013. [I-D.eckert-intarea-flow-metadata-framework] Eckert, T., Penno, R., Choukir, A., and C. Eckel, "A Framework for Signaling Flow Characteristics between Eckert, et al. Expires January 10, 2014 [Page 5] Internet-Draft FMD-RSVP July 2013 Applications and the Network", draft-eckert-intarea-flow- metadata-framework-00 (work in progress), July 2013. Authors' Addresses Toerless Eckert (editor) Cisco Systems, Inc. San Jose US Email: eckert@cisco.com Anca Zamfir Cisco Systems, Inc. EPFL, Quartier de l'Innovation Ecublens, Vaud 1015 Switzerland Email: ancaz@cisco.com Amine Choukir Cisco Systems, Inc. EPFL, Quartier de l'Innovation Ecublens, Vaud 1015 CH Phone: +41 78 75 98 561 Email: amchouki@cisco.com Eckert, et al. Expires January 10, 2014 [Page 6]