Internet DRAFT - draft-zamfir-tsvwg-flow-metadata-rsvp

draft-zamfir-tsvwg-flow-metadata-rsvp







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]