Internet DRAFT - draft-vallamkonda-sfc-metadata-model
draft-vallamkonda-sfc-metadata-model
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
Vallamkonda & Dolson Expires July 31, 2016 [Page 1]
Internet-Draft Information Model for SFC Metadata January 2016
(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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. The Need for a Metadata Model . . . . . . . . . . . . . . . . 3
4. Groups of Metadata . . . . . . . . . . . . . . . . . . . . . 4
5. Classes of Metadata . . . . . . . . . . . . . . . . . . . . . 5
5.1. Routing Domain . . . . . . . . . . . . . . . . . . . . . 5
5.2. Traffic Policy Indication . . . . . . . . . . . . . . . . 6
5.3. IP Endpoint Property . . . . . . . . . . . . . . . . . . 6
5.4. Flow Classification . . . . . . . . . . . . . . . . . . . 6
6. Metadata Yang Model . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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] [1]
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.
Vallamkonda & Dolson Expires July 31, 2016 [Page 2]
Internet-Draft Information Model for SFC Metadata January 2016
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] [2]. 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.
Vallamkonda & Dolson Expires July 31, 2016 [Page 3]
Internet-Draft Information Model for SFC Metadata January 2016
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:
o IAB maintains registered vendors already.
o The upper case above are keywords.
o Other features as encrypt and other options can be enhanced as
needed.
o Types can leverage industry standard as INT32, UINT32, etc. or
vendor specific.
o Flags: can have attribute restrictions/hints as: return type only,
multivalued etc.
o The 'value_number_associated' can be obtained from relevant
documents for service.
Example:
VENDOR-DEF TEST-CORP (IANA assigned Vendor id)
VENDOR-ATTRIBUTE service-name 1 string
ATTRIBUTE-VALUE service-name "Hello"
Vallamkonda & Dolson Expires July 31, 2016 [Page 4]
Internet-Draft Information Model for SFC Metadata January 2016
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.
Vallamkonda & Dolson Expires July 31, 2016 [Page 5]
Internet-Draft Information Model for SFC Metadata January 2016
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
The yang model for service path and node is defined as: Yang Model
for Service Chaining [3]
typedef sfc-metadata-vendor-name {
type string;
Vallamkonda & Dolson Expires July 31, 2016 [Page 6]
Internet-Draft Information Model for SFC Metadata January 2016
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;
Vallamkonda & Dolson Expires July 31, 2016 [Page 7]
Internet-Draft Information Model for SFC Metadata January 2016
}
7. Acknowledgements
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
The metadata for [sfc-nsh] [4], 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", draft-quinn-sfc-nsh-07 (work in
progress), 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,
<http://www.rfc-editor.org/info/rfc2119>.
10.2. Informative References
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<http://www.rfc-editor.org/info/rfc7665>.
10.3. URIs
[1] https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/
[2] https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/
[3] https://tools.ietf.org/html/draft-penno-sfc-yang-14
[4] https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/
Vallamkonda & Dolson Expires July 31, 2016 [Page 8]
Internet-Draft Information Model for SFC Metadata January 2016
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
Vallamkonda & Dolson Expires July 31, 2016 [Page 9]
