Network Working Group                                        B. Sarikaya
Internet-Draft                                                    Huawei
Intended status: Informational                              M. Boucadair
Expires: May 1, 2017                                              Orange
                                                             D. von Hugo
                                         Telekom Innovation Laboratories
                                                        October 28, 2016

          Service Function Chaining Metadata Type 1 and Type 2


   With the definition of service function chain data plane protocol
   there comes the need to define the context data needed in the service
   function chain use cases.  This document gives an account of all
   context data defined so far as Network Service Header metadata Type 1
   and Type 2 context headers.  Next, the document discusses the various
   options that can be taken in standardizing service function chain

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

   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 May 1, 2017.

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
   ( in effect on the date of
   publication of this document.  Please review these documents

Sarikaya, et al.           Expires May 1, 2017                  [Page 1]

Internet-Draft                TLVs  in SFC                  October 2016

   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
   2.  Context Metadata Definitions  . . . . . . . . . . . . . . . .   2
   3.  Processing Metadata Type 1 and Type 2 . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Network Service Header (NSH) [I-D.ietf-sfc-nsh] is the Service
   Function Chaining (SFC) data plane protocol.  The SFC architecture is
   defined in [RFC7665].

   NSH has the function of carrying context data in the form of context
   header.  NSH metadata Type 1 is composed of a 4-byte base header,
   4-byte service path header.  It contains four mandatory Context
   Headers, 4-byte each.  For additional metadata that needs to be
   carried, NSH metadata type 2 is defined.  Type 2 metadata is composed
   of a 4-byte base header carrying Type value of 0x02, 4-byte service
   path header followed by variable length context headers in the form
   of type-length-value or TLV.

   Many context headers were proposed by many documents.  In this
   document we survey existing drafts that propose new context metadata
   and then discuss different options that can be taken to standardize
   this work.

   The reader should be familiar with the terms defined in [RFC7665] and

2.  Context Metadata Definitions

   [I-D.quinn-sfc-nsh-tlv] defines NSH metadata Type 2 TLVs such as
   forwarding context, subscriber/user info, tenant, application ID,
   content type, ingress network information, flow ID, source and/or
   destination groups, universal resource identifier (URI).

Sarikaya, et al.           Expires May 1, 2017                  [Page 2]

Internet-Draft                TLVs  in SFC                  October 2016

   Some of these TLVs are defined in other documents, like App ID,
   Context ID in [I-D.napper-sfc-nsh-broadband-allocation].  Also for
   Application ID, even though the document references
   [I-D.penno-sfc-appid], [I-D.penno-sfc-appid] seems to mean
   Classification Engine ID and Selector ID for the Application ID.

   The purpose of [I-D.quinn-sfc-nsh-tlv]  is to document syntactic
   structure of the TLVs.  No other additional information about the
   metadata processing is within the scope of this document.  The
   document mentions no use cases in which the TLVs defined are needed.
   An implementer will need to refer to other documents to understand
   the exact behavior for handling those contexts.

   [I-D.napper-sfc-nsh-broadband-allocation]  supports use cases in

   This document defines meta data Type 1 with endpoint ID, e.g. for
   IMSI or MSISDN or wireline subscriber ID with 64-bit length.  It also
   defines ServiceTag to identify that the Service Information field
   contains information related to the Access Network (AN) for the
   subscriber.  Service information could contain IP-CAN type, QoS
   class, congestion level, etc. for a 3GPP Radio Access Network (RAN).
   Context ID field allows the subscriber/endpoint ID field to be
   scoped.  Context ID contains the incoming VRF, VxLAN VNID, VLAN, or
   policy identifier within which the Subscriber/Endpoint ID field is

   In addition, the document defines a meta data Type 2 TLV to be
   associated with 3GPP registry.  The intent here is to offer this TLV
   for the use of 3GPP to extend the meta data to meet the needs of 3GPP
   use cases.  However, it was not stated if 3GPP requested such an

   [] addresses the use cases for network
   security defined in [].

   It defines a recommended security context allocation as a meta data
   Type 1 TLV.  It is intended to define session ID, tenant ID,
   destination/ source class for the logical classification of the
   destination/ source of the traffic, destination/ source score which
   contains security classification results for communicating immediate
   actions and accumulated verdicts to downstream Service Functions.

   [] also mentions that the security
   context allocation, although defined as Type 1, it may also form a
   MD-Type 2 metadata TLV, possibly implying that the sizes of data such
   as session/ tenant ID, etc.  may need to become longer.  As a result,
   they may need to become variable length data as in Type 2 meta data

Sarikaya, et al.           Expires May 1, 2017                  [Page 3]

Internet-Draft                TLVs  in SFC                  October 2016

   TLVs.  This document defines network security allocation specifics,
   basically explaining the semantics of the metadata they define in the

   [I-D.sarikaya-sfc-hostid-serviceheader] addresses use cases that
   require revealing host and/ or subscriber related information to
   upstream SFs as well as extreme low latency service and ultra-high
   reliability applications use cases.

   From the analysed use cases, there comes the need to come up with
   definition of host, subscriber, slice identifier and service
   identifier SFC meta data Type 2 TLVs.  Apart from defining these
   TLVs, the document gives details of post processing in various nodes
   such as ingress/egress border nodes, SFC-aware Service Functions and
   Proxies.  Such post processing is defined as normative behavior.
   Since host and subscriber identifiers may reveal private information
   about the host and/or the subscriber, the document also defines
   normative behavior needed to protect the privacy of the hosts and
   subscribers in an operator network.

   [I-D.sarikaya-sfc-hostid-serviceheader] is unique among the documents
   discussed in this document because it defines the post processing
   normative behavior related to the host and subscriber identifier meta
   data Type 2 TLVs.  Also the use cases are defined in the same
   document not as a separate document as in the other cases.

   [I-D.penno-sfc-packet] addresses the problem of sending packets in
   the reverse direction to the source of the current in-process packet/
   flow.  It defines SF Reverse Packet Request as Type 1 metadata TLV.
   This is defined as Version 1 (as opposed to Version 0 of NSH MD-type
   1 in [I-D.ietf-sfc-nsh]) with OAM Protocol replacing the next
   protocol field and with Reverse Packet Request added to the end of
   mandatory context header octets for SFC as an additional 4-octet for

   This document also proposes 5 new metadata on service-path
   invariants, service-path default, bidirectional clonable,
   unidirectional clonable and service-function-mastered metadata.
   Their structure specifics are not specified.

   [I-D.penno-sfc-packet] gives a detailed explaination of the use of
   the metadata defined, all the semantic information, pre and post
   processing details at various nodes.

   [I-D.meng-sfc-nsh-broadband-allocation] defines Type 1 metadata
   called Broadband Context Allocation support service function chaining
   in a broadband service provider network.  It defines Source Node,
   Source Interface, User and VLAN IDs.

Sarikaya, et al.           Expires May 1, 2017                  [Page 4]

Internet-Draft                TLVs  in SFC                  October 2016

   [I-D.vallamkonda-sfc-metadata-model] does not define any Type 1 or
   Type 2 meta data TLVs, viewing such meta data as conveying
   preprocessing information about the packet, this document attempts to
   formally defines the post processing information.  To that end, it
   defines a vocabulary and information model for metadata.  The
   document gives metadata information model example definitions for
   routing domain, IP endpoint, flow and traffic policy indication.

3.  Processing Metadata Type 1 and Type 2

   Some options are discussed below for processing NSH TLVs:

   1.  List the structure of meta data in one single document as a
       registry.  The document is not supposed to contain any post
       processing information.  [I-D.quinn-sfc-nsh-tlv] attempts this
       choice for some Type 2 TLVs.  Currently there is no such document
       for Type 1 TLVs.  Note that in the case of keeping a registry
       document, it is not clear how the post processing behavior
       (normative or optional) will be specified for the TLVs.  One
       option is to keep such information in separate document.  If such
       a strategy is adopted then the advantages obtained from
       documenting all TLVs in one document disappears because the
       implementers would need to consult many documents instead of only

   2.  All documents defining new meta data Type 1 and Type 2 TLVs are
       treated individually for standardization.  This approach has the
       advantage of keeping all meta data Type 1 and Type 2 TLVs in
       separate and dedicated documents together with all the
       information that the implementers may need.  This could be a
       strong positive especially if we consider the fact that the meta
       data are being defined for very many use cases and scenarios.  It
       is unlikely that one implementer would need to implement a large
       number of these TLVs, thereby defeating the need for combining
       them in a single document.

   3.  Together with choice 1 above, while combining all TLVs in one
       document, it could be possible to keep post processing
       information related to the meta data can be considered
       individually for standardization.

   4.  Together with choice 2 above, Type 1 TLVs can combined in one
       document but all Type 2 TLVs can be considered individually in
       separate dedicated documents.

   A document intended to keep a registry of all TLVs can be an
   informational document.  Companion documents defining semantics of

Sarikaya, et al.           Expires May 1, 2017                  [Page 5]

Internet-Draft                TLVs  in SFC                  October 2016

   Type 1 and Type 2 metadata needs to be standard track in order to
   take the recommendations on processing the data into effect.

   Another issue is the importance of Type 1 metadata and Type 2
   metadata.  It seems to be difficult to argue that Type 1 metadata is
   more important.  The metadata defined in
   []  is a good example as it can be
   defined either as Type 1 or Type 2.  The same considerations could
   possible be made for other documents.

   It is recommended that the metadata defined be given serious
   consideration as to the merit of the use case that needs the metadata
   to the Service Function Chaining rather than syntactic considerations
   of Type 1 or Type 2.

4.  IANA Considerations


5.  Security Considerations

   This document does not introduce any security issues.

6.  Acknowledgements


7.  References

7.1.  Normative References

              Quinn, P. and U. Elzur, "Network Service Header", draft-
              ietf-sfc-nsh-10 (work in progress), September 2016.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

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

Sarikaya, et al.           Expires May 1, 2017                  [Page 6]

Internet-Draft                TLVs  in SFC                  October 2016

7.2.  Informative References

              Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and
              J. Uttaro, "Service Function Chaining Use Cases in Mobile
              Networks", draft-ietf-sfc-use-case-mobility-07 (work in
              progress), October 2016.

              Will, W., Li, H., Huang, O., Boucadair, M., Leymann, N.,
              Qiao, F., Qiong, Q., Pham, C., Huang, C., Zhu, J., and P.
              He, "Service Function Chaining (SFC) General Use Cases",
              draft-liu-sfc-use-cases-08 (work in progress), September

              Meng, W. and C. Wang, "NSH Context Header - Broadband",
              draft-meng-sfc-nsh-broadband-allocation-01 (work in
              progress), May 2016.

              Napper, J., Surendra, S., Muley, P., and W. Henderickx,
              "NSH Context Header Allocation -- Broadband", draft-
              napper-sfc-nsh-broadband-allocation-01 (work in progress),
              October 2016.

              Penno, R., Claise, B., Pignataro, C., and C. Fontaine,
              "Using Application Identification in Services Function
              Chaining Metadata", draft-penno-sfc-appid-05 (work in
              progress), August 2016.

              Penno, R., Pignataro, C., Yen, C., Wang, E., Leung, K.,
              and D. Dolson, "Packet Generation in Service Function
              Chains", draft-penno-sfc-packet-03 (work in progress),
              April 2016.

              Quinn, P., Elzur, U., Majee, S., and J. Halpern, "Network
              Service Header TLVs", draft-quinn-sfc-nsh-tlv-02 (work in
              progress), October 2016.

              Boucadair, M., Hugo, D., and B. Sarikaya, "Service
              Function Chaining Service, Subscriber and Host
              Identification Use Cases and Metadata", draft-sarikaya-
              sfc-hostid-serviceheader-03 (work in progress), July 2016.

Sarikaya, et al.           Expires May 1, 2017                  [Page 7]

Internet-Draft                TLVs  in SFC                  October 2016

    , s., Dunbar, L., and D. Dolson, "A
              Framework for SFC Metadata", draft-vallamkonda-sfc-
              metadata-model-01 (work in progress), July 2016.

              Wang, E., Leung, K., Felix, J., and J. Iyer, "Service
              Function Chaining Use Cases for Network Security", draft-
              wang-sfc-ns-use-cases-02 (work in progress), October 2016.

              Wang, E. and K. Leung, "Network Service Header (NSH)
              Context Header Allocation (Network Security)", draft-wang-
              sfc-nsh-ns-allocation-01 (work in progress), October 2016.

Authors' Addresses

   Behcet Sarikaya
   5340 Legacy Dr.
   Plano, TX  75024


   Mohamed Boucadair
   Rennes 3500, France


   Dirk von Hugo
   Telekom Innovation Laboratories
   Deutsche-Telekom-Allee 7
   D-64295 Darmstadt


Sarikaya, et al.           Expires May 1, 2017                  [Page 8]