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 7, 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.

Table of Contents

• 1. Introduction
• 1.1. Requirements Language
• 2. Flow Metadata Object
• 2.1. FLOW_METADATA Class
• 2.1.1. Basic IPFIX FLOW_METADATA Object
• 2.1.2. Enhanced Protocol Independent FLOW_METADATA Object
• 2.2. Semantic of carrying the Metadata Object
• 2.3. Processing by a Non-Metadata Capable RSVP Router
• 2.4. Processing by a Metadata Capable RSVP Router
• 3. Security considerations
• 4. References
• 4.1. Normative References
• 4.2. Informative References
• Authors' Addresses

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

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

• 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
• 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

• 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 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:

• Token Bucket Rate [r]
• Token Bucket Size [b]
• Peak Data Rate [p]
• 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 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. Security considerations

RSVP message security is described in [RFC2747]and provides message integrity and host-based authentication using the INTEGRITY object. In addition, user-based authentication is available as described in [RFC3182] using the AUTH_DATA policy element. Confidentiality is not provided by [RFC2747]. There are some environments (e.g. enterprise, single administrative domain scope) where signaling metadata in clear is acceptable. The legacy encoding should be limited to these environments. When leaving such environments and forwarding to untrusted or unsecured networks, edge egress nodes should remove the metadata that is confidential in nature. If metadata confidentiality is required, IPSEC encapsulation should be considered. RSVP, however, uses special processing of signaling messages that complicates IPsec protection. More details can be found in [RFC4230] section 5.6.

4. References

4.1. Normative References

4.2. Informative References

Authors' Addresses