One document matched: draft-penno-sfc-appid-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-penno-sfc-appid-05" ipr="trust200902">
<front>
<title abbrev="SFC Traceroute">Using Application Identification in
Services Function Chaining Metadata</title>
<author fullname="Reinaldo Penno" initials="R." surname="Penno">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Dr</street>
<code>CA</code>
<city>San Jose</city>
<country>USA</country>
</postal>
<email>repenno@cisco.com</email>
</address>
</author>
<author fullname="Benoit Claise" initials="B." surname="Claise">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>De Kleetlaan 6a b1</street>
<city>1831 Diegem</city>
<country>Belgium</country>
</postal>
<email>bclaise@cisco.com</email>
</address>
</author>
<author fullname="Carlos Pignataro" initials="C.M."
surname="Pignataro">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7200-12 Kit Creek Road</street>
<city>Research Triangle Park</city> <region>NC</region> <code>27709-4987</code>
<country>USA</country>
</postal>
<email>cpignata@cisco.com</email>
</address>
</author>
<author fullname="Christophe Fontaine" initials="C." surname="Fontaine">
<organization>Qosmos</organization>
<address>
<postal>
<street>8 rue Bernard Buffer</street>
<city>Paris</city>
<region/>
<code/>
<country>France</country>
</postal>
<phone/>
<facsimile/>
<email>christophe.fontaine@qosmos.com</email>
<uri/>
</address>
</author>
<date />
<area>O&M</area>
<workgroup>SFC Netmod</workgroup>
<keyword>SFC</keyword>
<keyword>Chaining</keyword>
<keyword>Function</keyword>
<abstract>
<t>This document defines the use of a structured application information
in the service function chaining metadata, and specifies a YANG model
for the configuration of the application registry.</t>
<t>
The consumers of application information are Service Functions that
apply policy and provide application statistics based on the metadata
contained in the packet.
</t>
</abstract>
</front>
<middle>
<section title="Open Issues">
<t><list style="numbers">
<t>Relationship of this YANG module and draft-penno-sfc-yang</t>
<t>Any reasons why those attributes are not modeled as boolean:
P2P-technology, tunnel-technology, encrypted?</t>
<t>The connection between the YANG Model in this document and <xref
target="I-D.penno-sfc-yang"/> must be explained</t>
</list></t>
</section>
<section title="Introduction">
<t>
As described in the Service Function Architecture
<xref target="RFC7665"/>, Service Functions are provide specific treatment for
packets and are part of the end-to-end delivery of services.
Many of these network services include application-specific functions,
treatments, and optimizations.
</t>
<t>
The SFC Encapsulation, Network Service Header (NSH), therefore needs to provide with
dynamic, flexible, and easily methods to bind service policy to granular
traffic information, which includes application information.
This is achieved by the ability to carry metadata along the service function path,
which is derived from various sources. (e.g., orchestration systems, DPI Classification,
etc.)
The consumers of this application information are Service Functions that
apply policy and provide application statistics based on this metadata
contained in the packet.
</t>
<t>
This document concerns itself with defining structured application information
in the service function chaining metadata.
</t>
<t>The "Cisco Systems Export of Application Information in IP Flow
Information Export (IPFIX) <xref target="RFC6759"/> specifies an
extension to the IPFIX information model <xref target="RFC7012"/> to
export application information. This IPFIX information element is
registered as the identifier 95 in the IPFIX registry <xref
target="IANA-IPFIX"/>. Applications could be identified at different OSI
layers, from layer 2 to layer 7. For example, the Link Layer
Distribution Protocol <xref target="LLDP"/> can be identified in layer
2, ICMP can be identified in layer 3 [IANA-PROTO], HTTP can be
identified in layer 4 [IANA-PORTS], and Webex can be identified in layer
7. However, the layer 7 application registry values are out of scope of
<xref target="RFC6759"/></t>
<t>This document purposes the use of IPFIX <xref target="RFC7011"/>
application information to be carried in the NSH MD-Type 1 context metadata
<xref target="I-D.ietf-sfc-nsh"/>. Optionally, encoding for NSH MD-Type 2
is provided with the Application ID TLV <xref target="I-D.quinn-sfc-nsh-tlv"/>.
The information in the metadata will be provided by an orchestration system
or the result of
packet processing done by a firewall, Intrusion Protection Service (IPS), Deep
Packet Inspection (DPI), amongst others. These are defined as providers of
application information.</t>
<section title="Terminology">
<t>The reader should be familiar with the terms contained in the following documents:
<list style="symbols">
<t>Section 1.4 of the "Service Function Chaining (SFC) Architecture" <xref
target="RFC7665"/></t>
<t>Section 2.1 of the "Network Service Header" <xref
target="I-D.ietf-sfc-nsh"/></t>
<t> The "Generic Protocol Extension for VXLAN" <xref target="I-D.ietf-nvo3-vxlan-gpe"/></t>
<t>Sections 3 and 3.1 of "Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)" <xref target="RFC6759"/></t>
</list></t>
</section>
<section anchor="sec.tree-symbols" title="Tree Diagrams" toc="default">
<t>A simplified graphical representation of the data model is used in
this document. The meaning of the symbols in these diagrams is as
follows:</t>
<t>The meaning of the symbols in these diagrams is as follows: <list
style="symbols">
<t>Brackets "[" and "]" enclose list keys.</t>
<t>Curly braces "{" and "}" contain names of optional features
that make the corresponding node conditional.</t>
<t>Abbreviations before data node names: "rw" means configuration
(read-write), "ro" state data (read-only), "-x" RPC operations,
and "-n" notifications.</t>
<t>Symbols after data node names: "?" means an optional node, "!"
a container with presence, and "*" denotes a "list" or
"leaf-list".</t>
<t>Parentheses enclose choice and case nodes, and case nodes are
also marked with a colon (":").</t>
<t>Ellipsis ("...") stands for contents of subtrees that are not
shown.</t>
</list></t>
</section>
</section>
<section title="Application Information Structure">
<t>The application information data structure can be seen
in <xref target="fig-app-id" />. It was
extracted and adapted from <xref target="RFC6759"/>.</t>
<t><figure anchor="fig-app-id"
title="Application Identification Data Format">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Class. Eng. ID| Zero-valued upper-bits ... Selector ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>
<xref target="table-class" /> displays the currently allocated
Classification Engine IDs, including their name and value,
as well as their corresponding Selector ID default length.
</t>
<texttable anchor="table-class" title="Existing Classification Engine IDs" style="all">
<ttcol align='center'>Classification Engine ID Value</ttcol>
<ttcol align='center'>Classification Engine ID Name</ttcol>
<ttcol align='center'>Selector ID default length (in octets)</ttcol>
<c>1</c> <c>IANA-L3</c> <c>1</c>
<c>2</c> <c>PANA-L3</c> <c>1</c>
<c>3</c> <c>IANA-L4</c> <c>2</c>
<c>4</c> <c>PANA-L4</c> <c>2</c>
<c>6</c> <c>USER-Defined</c> <c>3</c>
<c>12</c> <c>PANA-L2</c> <c>5</c>
<c>13</c> <c>PANA-L7</c> <c>3</c>
<c>18</c> <c>ETHERTYPE</c> <c>2</c>
<c>19</c> <c>LLC</c> <c>1</c>
<c>20</c> <c>PANA-L7-PEN</c> <c>3 (*)</c>
</texttable>
<t>
Where:
<list style="empty">
<t>"PANA = Proprietary Assigned Number Authority". In other words, an
enterprise specific version of IANA for internal IDs.</t>
<t>PEN = Private Enterprise Number</t>
<t> (*) There are an extra 4 bytes for the PEN. However, the PEN is not
considered part of the Selector ID.</t>
</list>
</t>
<t>
Section 6 of <xref target="RFC6759"/> provides various illustrative examples of
the encoding for different applications.
</t>
</section>
<section title="Application Information Yang Model">
<t/>
<section title="Module Structure">
<t/>
<t><figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
module: ietf-ipfix-application-information
+--rw class-id-dictionary
| +--rw class-id* [name]
| +--rw id? uint8
| +--rw name string
| +--rw description? string
+--rw application-id-dictionary
+--rw application-id* [application-name]
+--rw class-id -> /class-id-dictionary/class-id/id
+--rw pen uint32
+--rw selector-id uint32
+--rw application-name string
+--rw application-description? string
+--rw application-category-name? string
+--rw application-sub-category-name? string
+--rw application-group-name? string
]]></artwork>
</figure></t>
</section>
<section title="Application Information Configuration Module">
<t/>
<t><figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
<CODE BEGINS> file "ietf-ipfix-application-information@2015-04-28.yang"
module ietf-ipfix-application-information {
yang-version 1;
namespace "urn:ietf:params:xml:ns:yang:"
+ "ietf-ipfix-application-information";
prefix ipfix-app-info;
organization
"IETF SFC (Service Function Chaining) Working Group";
contact
"Editor: Christophe Fontaine
christophe.fontaine@qosmos.com
Editor: Reinaldo Penno
rapenno@gmail.com";
description
"This module contains a collection of YANG definitions for
the configuration of application ids.
Copyright (c) 2015 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).";
revision 2015-04-28 {
description "Initial revision";
reference
"draft-penno-sfc-appid : Using Application Identification in
Services Function Chaining Metadata";
}
/*
* Typedefs
*/
typedef application-id-ref {
type leafref {
path "/ipfix-app-info:application-id-dictionary/"
+ "ipfix-app-info:application-id/ipfix-app-info"
+ ":application-name";
}
description "This type is used by data models that need
to reference an application-id";
}
typedef classification-engine-id {
type enumeration {
enum "IANA-L3" {
value 1;
description
"IANA-L3";
}
enum "PANA-L3" {
value 2;
description
"PANA-L3";
}
enum "IANA-L4" {
value 3;
description
"IANA-L4";
}
enum "PANA-L4" {
value 4;
description
"PANA-L4";
}
enum "USER-Defined" {
value 6;
description
"USER-Defined";
}
enum "PANA-L2" {
value 12;
description
"PANA-L2";
}
enum "PANA-L7" {
value 13;
description
"PANA-L7";
}
enum "ETHERTYPE" {
value 18;
description
"ETHERTYPE";
}
enum "LLC" {
value 19;
description
"LLC";
}
enum "PANA-L7-PEN" {
value 20;
description
"PANA-L7-PEN";
}
}
description
"The definitions for Classification engine ID names.";
reference
"RFC 6759: Cisco Systems Export of Application Information
in IP Flow Information Export (IPFIX)";
}
/*
* Configuration data nodes
*/
container class-id-dictionary {
description "Dictionary for classification ids";
list class-id {
key "name";
unique "id";
leaf id {
type uint8;
description "Classification identifier";
}
leaf name {
type string;
description "classification Engine name";
}
leaf description {
type string;
description "Description of the class-id";
}
description "A list of all classification ids";
}
}
container application-id-dictionary {
description "Dictionary for application ids";
list application-id {
key "application-name";
unique "class-id pen selector-id";
leaf class-id {
type leafref {
path "/ipfix-app-info:class-id-dictionary/"
+ "ipfix-app-info:class-id/ipfix-app-info:id";
}
mandatory true;
description "Application Name";
}
leaf pen {
type uint32;
mandatory true;
description "Private Entreprise Number, only relevant
when used with appropriate class-id.
Set to 0 when not used.";
}
leaf selector-id {
type uint32 {
range "0..16777216";
}
mandatory true;
description "Selector identifier";
}
leaf application-name {
type string;
mandatory true;
description "The name of the application";
}
leaf application-description {
type string;
description "The description of the application";
}
leaf application-category-name {
type string;
description "An attribute that provides a first-
level categorization for each
Application ID. Examples include
browsing, email, file-sharing,
gaming, instant messaging, voice-
and-video, etc.
The category attribute is encoded by
the application-category-name
Information Element";
}
leaf application-sub-category-name {
type string;
description "An attribute that provides a second-
level categorization for each
Application ID. Examples include
backup-systems, client-server,
database, routing-protocol, etc.
The sub-category attribute is
encoded by the
application-sub-category-name
Information Element";
}
leaf application-group-name {
type string;
description "An attribute that groups multiple
Application IDs that belong to the
same networking application. For
example, the ftp-group contains
ftp-data (port 20), ftp (port 20),
ni-ftp (port 47), sftp (port 115),
bftp (port 152), ftp-agent(port
574), ftps-data (port 989). The
application-group attribute is
encoded by the application-group-name
Information Element";
}
description "A list of all applications";
}
}
}
<CODE ENDS>]]></artwork>
</figure></t>
</section>
</section>
<section title="Service Function Chaining Metadata">
<t>When a Deep Packet Inspection (DPI), Firewall or any other Service
Function (SF) that can identify applications want to convey this
knowledge to other SFs it encoded in the format discussed earlier and
add to the context metadata.
</t><t>
As defined in <xref target="I-D.ietf-sfc-nsh"/>, there are two
formats for the NSH Metadata, or the portion of the
NSH header beyond the mandatory Base Hader and
Service Path Header: MD-Type 1 and MD-Type 2.
</t><t>
The Application Identification data structure (see <xref target="fig-app-id" />)
can be carried both in MD-Type 1 and MD-Type 2. This document specifies
the encoding within NSH MD-Type 1 (see <xref target="ex" />), and
encoding for NSH MD-Type 2
is provided with the Application ID TLV <xref target="I-D.quinn-sfc-nsh-tlv"/>.
</t><t>
The Example in <xref target="ex" /> shows the encoding of the SNMP
application using MD-Type 1.</t>
<t><figure anchor="ex"
title="Example of Metadata Including the SNMP Application Identification">
<artwork align="center"
><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 0 | 161 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Shared Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Platform Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Shared Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>In this example, the Classification Engine IDs of 3 indicates "IANA-L4", and 161 is the
well-known port number for SNMP (with its upper bits zero-valued).</t>
<t>Other Services Functions that need application information associated
with a packet or flow can look at this metadata
(encoded in either MD-Type 1 or MD-Type 2) and easily find out its
value.</t>
</section>
<section title="Relationship to existing YANG Modules">
<t><xref target="RFC6728"/> specifies a data model for the IP Flow
Information Export (IPFIX) and Packet Sampling (PSAMP) protocols. It is
for configuring and monitoring Selection Processes, Caches, Exporting
Processes, and Collecting Processes of IPFIX- and PSAMP-compliant
Monitoring Devices using the Network Configuration Protocol (NETCONF).
The data model is defined using UML (Unified Modeling Language) class
diagrams and formally specified using YANG.</t>
<t>The YANG model is this document allows the configuration of the
application id IPFIX information elements (ieId), which in turn, may be
used in a template definition (TemplateId).</t>
<t><xref target="I-D.penno-sfc-yang"/> To be done</t>
</section>
<section title="Expected Usage">
<t>Devices or controllers will download the <xref target="ETHERTYPE"/>,
<xref target="IANA-PROTO"/> and <xref target="IANA-PORTS"/> from the
appropriate URIs. However, the configuration of the applications is
required for applications not registered in an industry-wide agreed-upon
registry. In this case, the Proprietary Assigned Number Authority (PANA)
registries (PANA-L2, PANA-L3, PANA-L4, PANA-L7), or the User-Defined
registry, must be used to identify new application.</t>
<t>Furthermore, the following attributes are statically assigned per
Application ID, and needs to be configured: category, sub-category,
application-group.</t>
</section>
<section title="IANA Considerations">
<t>TBD</t>
</section>
<section title="Security Considerations">
<t>
TODO: Update with privacy and security considerations, as requested in Prague IETF93.
</t>
</section>
<section title="Acknowledgements">
<t>
The authors wish to thank Kengo Naito for a thorough review and insightful comments.
</t>
</section>
<section title="Changes">
<t/>
</section>
</middle>
<back>
<references title="Informative References">
<reference anchor="LLDP" target="LLDP">
<front>
<title>Std 802.1AB-2005, "Standard for Local and metropolitan area
networks - Station and Media Access Control Connectivity Discovery",
IEEE Std 802.1AB-2005</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2005"/>
</front>
</reference>
<reference anchor="IANA-IPFIX"
target="http://www.iana.org/assignments/ipfix/">
<front>
<title>"IP Flow Information Export (IPFIX) Entities"</title>
<author>
<organization>IANA</organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="ETHERTYPE"
target="http://standards.ieee.org/develop/regauth/thertype/eth.txt">
<front>
<title>ETHERTYPE</title>
<author>
<organization/>
</author>
<date year="1984"/>
</front>
</reference>
<reference anchor="IANA-PORTS"
target="http://www.iana.org/assignments/port-numbers">
<front>
<title>IANA-L4</title>
<author>
<organization>IANA</organization>
</author>
<date year="1984"/>
</front>
</reference>
<reference anchor="IANA-PROTO"
target="http://www.iana.org/assignments/protocol-numbers">
<front>
<title>IANA-L3</title>
<author>
<organization>IANA</organization>
</author>
<date year="1984"/>
</front>
</reference>
<?rfc include="reference.RFC.6728"?>
<?rfc include="reference.RFC.6759"?>
<?rfc include="reference.RFC.7011"?>
<?rfc include="reference.RFC.7012"?>
<?rfc include="reference.I-D.penno-sfc-yang"?>
<?rfc include="reference.I-D.ietf-sfc-nsh"?>
<?rfc include="reference.I-D.quinn-sfc-nsh-tlv"?>
<?rfc include="reference.RFC.7665"?>
<?rfc include="reference.I-D.ietf-nvo3-vxlan-gpe"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:40:07 |