Internet Engineering Task Force S. Vallamkonda
Internet-Draft F5 Networks
Intended status: Informational D. Dolson
Expires: July 31, 2016 Sandvine
January 28, 2016

Information Model for SFC Metadata
draft-vallamkonda-sfc-metadata-model-00

Abstract

Various types of metadata are applicable to Service Function Chaining (SFC). A Service Function (SF) needs information about all metadata passing through it. The metadata could be used to convey preprocessing information about the packet by other nodes and an SF can attach post processing information as deemed necessary.

The purpose of this document is to rigorously define the classes of metadata and provide a vocabulary and information model for metadata.

Each item of metadata refers to a subject, examples of which are IP endpoint, flow or individual packet.

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 July 31, 2016.

Copyright Notice

Copyright (c) 2016 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

Service Function Chaining (SFC) is a technology for directing network traffic via specified network elements.

SFC is described in detail in the SFC architecture document SFC architecture document [RFC7665], and is not repeated here. The Network Service Header is described in document [sfc-nsh]

The metadata as specified[sfc-nsh] provides a mechanism for additional information exchange between nodes along the service path. However, there is no framework for either metadata syntax or semantics. The lack of metadata format standardization consequently introduces interoperability concerns and ambiguity between Classifier and SF nodes in Service Function Chains.

1.1. Scope

This document describes requirements and approaches for metadata in SFC networks. The control plane can convey the information to SFFs data plane elements. Also this documents identifies different network elements in service network for metadata exchange, Service Node Metadata Format [SNMF].

This document does not make any assumptions on specific implementation and/or deployments. In particular this document covers different types of network devices. The document does not make any assumption on specific actions or protocols that SFFs and SFs operate on. It also does not modify or create any protocol header extensions to [sfc-nsh]. This document just addresses the void of metadata definitions and specifications for SFFs and SFs in a Service Function Chain. It is out of scope of this document to discuss policies or stateful enforcement schemes. The metadata is only in context of SFC-aware elements is discussed.

2. 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].

3. The Need for a Metadata Model

The SFC architecture calls for metadata to be included with packets sent between elements of a service chain.

Several types of Service Functions inject packets into data streams. Examples include routers creating ICMP messages, or firewalls creating TCP reset packets. The question that naturally arises is what metadata should be attached to such packets. This question cannot be answered without knowing what each type of metadata means. Further without this, there is ambiguity on limitations and restrictions for services offered by the service nodes in the service path.

Metadata could be self-describing or there could be control-plane descriptions of metadata encoding in the form of a metadata dictionary (or a combination thereof). In either case, there needs to be a language for describing the meaning of metadata context vocabulary.

This document provides the language for describing metadata, as required by service functions using the metadata and also for service functions forwarding the metadata.

4. Groups of Metadata

The Metadata definition can be defined as Attribute-Value pairs. The AV pairs can be classified into generic classes as below. Additionally, Vendor specific AV pairs can be defined in a vendor dictionary which can be uploaded to controller as needed.

Vendor-specific attributes can be defined as:

 
          VENDOR-DEF           vendor_name      vendor_id
             VENDOR-ATTRIBUTE  attribute-name   attribute_ID    syntax_type  (DEFAULT, LENGTH, etc) flags
               ATTRIBUTE-VALUE attribute-name   value_name      value_number_associated
      

Assumptions:

Example:

 
         VENDOR-DEF	TEST-CORP		(IANA assigned Vendor id)
             VENDOR-ATTRIBUTE	service-name	1	string
			ATTRIBUTE-VALUE	service-name	"Hello"
      

The Packet on wire would look as:

 
     +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
     |      Type        |       Length     |            Vendor-Id                  |
     +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
     |  Vendor-Attribute-Type  |  Vendor-Attribute-Length | Vendor-Attribute-Value |
     +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
     
     Type:  Enumeration: 1 - Generic, 2 - Vendor attribute.
     Length: total length of VSA.
     Vendor-Id: IANA assigned number.
     Vendor-Attribute-Type: Identifier (Unique as assigned by) Vendor space.
     Vendor-Attribute-Length: Length of this Attribute.
     Vendor-Attribute-Value: Value of this Attribute.  
 
    

The dictionary files can be imported and/or exported by Controller as needed. Further, the dictionary files can have versions, which can be detected by service nodes. The service nodes compatibility matrix is monitored and maintained by control plane on Controller. Thus the Controller would have knowledge of service node capability and limitations to update SFFs with dictionary attributes accordingly.

The Vendor-id would be used as 'TLV Class' as specified in [draft-quinn-sfc-nsh] and Vendor-attribute would be 'Type'. The Attribute-value would be 'Variable Metadata' and Attribute-length would be 'Len' of TLV in metadata.

5. Classes of Metadata

The above framework provides ability for service nodes to exchange metadata in global language rather than a native local format.

5.1. Routing Domain

A Routing Domain metadata type indicates the specific private network for the packet. Neither traffic nor information may cross between domains. The domain must be used to discriminate between overlapping private IPv4.

Metadata of this type is generally attached by the classifier. In general this type of metadata must not be removed or modified by SFs (except in the case when the intention is to route traffic between domains).

Injected packets must include this type of metadata, to indicate the routing domain the packet is being injected into.

5.2. Traffic Policy Indication

A metadata type indicates a class of treatment for a customer traffic.

May be attached by the classifier or another SF in the chain.

Class values are assigned and administered by the operator.

Not required on every packet. If missing, a default policy can be applied.

The most recent value can be cached for the customer IP address; injected packets can use the cached value.

5.3. IP Endpoint Property

A metadata type indicates a property of an IP endpoint of either the source or destination IP address in the encapsulated conversation.

As examples, the metadata could indicate a user's class of service, that the endpoint is flagged as the subject of an attack or may indicate the account number to charge the user's traffic.

Injected packets may clone this type of metadata from other packets having the same IP endpoint, for packets in the same direction.

5.4. Flow Classification

A metadata type indicates a flow classification.

As examples, the metadata could indicate a DPI classification result or whether the flow has been selected for differentiated service.

May be attached by the classifier or another SF in the chain. May be overwritten by SFs along the chain.

This type of metadata is a property of the session 5-tuple. Injected packets may clone this property from other packets of the flow, for packets in the same direction.

6. Metadata Yang Model

     typedef sfc-metadata-vendor-name {
         type           string;
         description    "Name of the Vendor"
     }

     typedef sfc-metadata-vendor-number {
         type           integer;
         description    "IANA assigned number for the vendor"
     }

     typedef sfc-metadata-attribute-type {
         type           string;
         description    "Attribute Type for the attribute"
     }

     typedef sfc-metadata-attribute-name {
         type           attribute-name;
         description    "Attribute Names of the Attribute"
     }

     typedef sfc-metadata-attribute-number {
         type           integer;
         description    "Attribute Number for the attribute "
     }

     typedef sfc-metadata-attribute-flags {
         type           bits;
         description    "Attribute flags for the attribute"
     }

     leaf-list  sfc-vendor-metadata-attribute {
        leaf   attribute {
             type attribute-number;
             type attribute-type;
             type attribute-length;
             bits attribute-flags; 
             description "
        }
     }

     container service-vendor-metadata { 
        description
		"Service node metadata associated for service node"
        type sfc-metadata-vendor-name;
        type sfc-metadata-vendor-number;
     }

     grouping vendor-attribute-info {
        type service-vendor-metadata;
        type sfc-vendor-metadata-attribute;
     }
        
    

The yang model for service path and node is defined as: Yang Model for Service Chaining

7. Acknowledgements

8. IANA Considerations

This memo includes no request to IANA.

9. Security Considerations

The metadata for [sfc-nsh], same considerations are applicable.

10. References

10.1. Normative References

[I-D.quinn-sfc-nsh] Quinn, P., Guichard, J., Surendra, S., Smith, M., Henderickx, W., Nadeau, T., Agarwal, P., Manur, R., Chauhan, A., Halpern, J., Majee, S., Elzur, U., Melman, D., Garg, P., McConnell, B., Wright, C. and K. Kevin, "Network Service Header", Internet-Draft draft-quinn-sfc-nsh-07, February 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

10.2. Informative References

[RFC7665] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015.

Authors' Addresses

Sunil Vallamkonda F5 Networks 3545 N. 1st Street San Jose, CA 95134 USA Phone: +1 408 274 4820 EMail: sunilvk@f5.com
David Dolson Sandvine 408 Albert Street Waterloo, ON N2L 3V3 Canada Phone: +1 519 880 2400 EMail: ddolson@sandvine.com