[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

Network Working Group                                              Z. Li
Internet-Draft                                                   S. Peng
Intended status: Standards Track                     Huawei Technologies
Expires: September 12, 2019                               March 11, 2019


          Consideration of IPv6 Encapsulation for SFC and IFIT
                     draft-li-6man-ipv6-sfc-ifit-00

Abstract

   Service Function Chaining (SFC) and In-situ Flow Information
   Telemetry (IFIT) are important path services along with the packets.
   In order to support these services, several encapsulations have been
   defined.  The document analyzes the problems of these encapsulations
   in the IPv6 scenario and proposes the possible optimized
   encapsulation for IPv6.

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

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 https://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 September 12, 2019.

Copyright Notice

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



Li & Peng              Expires September 12, 2019               [Page 1]


Internet-Draft              IPv6 SFC and IFIT                 March 2019


   (https://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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Design Consideration  . . . . . . . . . . . . . . . . . . . .   3
     4.1.  Service Options . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  IPv6 Metadata Header  . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Service Function Chaining (SFC) [RFC7665] and In-situ Flow
   Information Telemetry (IFIT) [I-D.song-opsawg-ifit-framework] are
   important path services along with the packets.  In order to support
   these services, several encapsulations have been defined.  Network
   Service Header (NSH) is defined in [RFC8300] as the encapsulation for
   SFC.  For IFIT encapsulations, In-situ OAM (iOAM) Header is defined
   in [I-D.ietf-ippm-ioam-data] and Postcard-Based Telemetry (PBT)
   Header is defined in [I-D.song-ippm-postcard-based-telemetry].
   Inband Flow Analyzer (IFA) is also defined in [I-D.kumar-ippm-ifa] to
   record flow specific information from an end station and/or switches
   across a network.  In the application scenario of IPv6, these
   encapsulations propose challenges for the data plane.  The document
   analyzes the problems and proposes the possible optimized
   encapsulation for IPv6.

2.  Terminology

   SFC: Service Function Chaining

   IFIT: In-situ Flow Information Telemetry

   IOAM: In-situ OAM




Li & Peng              Expires September 12, 2019               [Page 2]


Internet-Draft              IPv6 SFC and IFIT                 March 2019


   PBT: Postcard-Based Telemetry

   IFA: Inband Flow Analyzer

   SRH: Segment Routing Header

3.  Problem Statement

   The problems posed by the current encapsulations for SFC and IFIT in
   the application scenarios of IPv6 and SRv6 include:

   1.  According to the encapsulation order recommended in [RFC8200], if
   the IOAM is encapsulated in the IPv6 Hop-by-Hop options header, in
   the trace mode of IOAM as the number of nodes traversed by the IPv6
   packets increases, the recorded IOAM information will increase
   accordingly.  This will increase the length of the Hop-by-Hop options
   header and cause increasing difficulties in reading the following
   Segment Routing Extension Header (SRH)
   [I-D.ietf-6man-segment-routing-header] and thereby reduce the
   forwarding performance of the data plane greatly.

   2.  With the introduction of SRv6 network programming
   [I-D.filsfils-spring-srv6-network-programming], the path services
   along with the IPv6 packets can be processed at all the IPv6 network
   nodes or only at the SRv6 enabled network nodes along the path.  It
   is necessary to distinguish the encapsulations for the specific path
   service which should be processed by the IPv6 path or the SRv6 path.

   3.  Both NSH and IOAM need the Metadata field to record metadata
   information.  However currently these metadata has to be recorded
   separately which may generate redundant metadata information or
   increase the cost of process.

   4.  There is unnecessary inconsistency in the current encapsulations
   for IOAM, IFA and PBT in the IPv6 scenario.  Especially it seems
   unnecessary to define a new specific IPv6 header for IFA, i.e. IFA
   header.

   5.  [I-D.guichard-spring-nsh-sr] is proposed for the solution to
   encapsulate NSH in SRv6 to support SFC.  But the encapsulation is not
   defined yet.

4.  Design Consideration

   To solve the problems stated above, in the application scenarios of
   IPv6 and SRv6, the encapsulations of SFC and IFIT can be optimized
   with the following design considerations:




Li & Peng              Expires September 12, 2019               [Page 3]


Internet-Draft              IPv6 SFC and IFIT                 March 2019


   o  To separate the SFC/IFIT path service into two parts, i.e.
      instruction and recording parts.  The instruction part (normally
      with fixed length) can be placed in the front IPv6 extension
      headers including Hop-by-Hop options header, Destination options
      header, Routing header, etc. while the recording part can be
      placed in the back IPv6 extension headers such as being placed
      after IPv6 Routing Header.  In this way the path service
      instruction in the IPv6 extension headers can be fixed as much as
      possible to facilitate hardware process to keep forwarding
      performance while the SFC/IFIT metadata recording part is placed
      afterwards which enables to stop recording when too much recording
      information has to be carried to reach the limitation of hardware
      process.

   o  To define SFC/IFIT path service instructions as IPv6 options
      uniformly whichs can be placed either in the Hop-by-hop options
      which indicates the path service processed by all IPv6 enabled
      nodes along the path or in the SRH option TLVs which indicates the
      path service processed only by the SRv6 nodes along the SRv6 path
      indicated by the Segment List in the SRH.

   o  To define a unified IPv6 metadata header which can be used as a
      container to record the service metadata of SFC, IFIT and other
      possible path services.

   According to the above design optimization consideration, in the
   application scenarios of IPv6 and SRv6 the encapsulations for SFC and
   IFIT can be defined as below.

4.1.  Service Options

   1.  NSH Service Option

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ver|O|U|    TTL    |   Length  |U|U|U|U|MD Type| Next Protocol |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Service Path Identifier              | Service Index |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 1. IPv6 Options with NSH instructions

   Option Type: TBD

   Opt Data Len: 8 octets.



Li & Peng              Expires September 12, 2019               [Page 4]


Internet-Draft              IPv6 SFC and IFIT                 March 2019


   Other fields: refer to [RFC8300].

   2.  IOAM Service Option

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Namespace-ID           |NodeLen  | Flags | RemainingLen|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               IOAM-Trace-Type                 |  Reserved     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 2. IPv6 Options with IOAM instructions

   Option Type: TBD

   Opt Data Len: 8 octets.

   Other fields: refer to [I-D.ietf-ippm-ioam-data].

   3.  PBT Service Option

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Header   |  TIH Length   |   Reserved    |   Hop Count   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Flow ID                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Flow ID                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Sequence Number                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Data Set ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 3. IPv6 Options with PBT instructions

   Option Type: TBD

   Opt Data Len: 20 octets.

   Other fields: refer to [I-D.song-ippm-postcard-based-telemetry].




Li & Peng              Expires September 12, 2019               [Page 5]


Internet-Draft              IPv6 SFC and IFIT                 March 2019


   4.  IFA Service Option

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ver=2.0|  GNS  |NextHdr = IP_xx|R|R|R|M|T|I|T|C|   Max Length  |
   |       |       |               | | | |F|S| |A| |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Figure 4. IPv6 Options with IFA instructions

   Option Type: TBD

   Opt Data Len: 4 octets.

   Other fields: refer to [I-D.kumar-ippm-ifa].

   These options can be put in the IPv6 Hop-by-Hop Options Header or SRH
   TLV.

4.2.  IPv6 Metadata Header

   IPv6 Metadata Header is defined as a new type of IPv6 extension
   header shown in Figure 5.  The metadata is the information recorded
   by each hop for specific path services, The length of the metadata is
   variable.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |  Hdr Ext Len  |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                     Metadata Stack (Variable)                 .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Figure 5. Metadata Header













Li & Peng              Expires September 12, 2019               [Page 6]


Internet-Draft              IPv6 SFC and IFIT                 March 2019


      Next Header         8-bit selector. Identifies the type of header
                          immediately following the IPv6 metadata
                          header.

      Hdr Ext Len         8-bit unsigned integer. Length of the
                          IPv6 metadata header in 8-octet units,
                          not including the first 8 octets.

      Metadata Stack      Variable-length field, of length such that the
                          complete IPv6 metadata header is an
                          integer multiple of 8 octets long. Contains
                          one or more type of path service metadata.

   For specific path service, i.e. SFC/IOAM, the corresponding metadata
   is defined as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Service Type  |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   |                    Metadata (variable)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Figure 6. Service Metadata

      Service Type        8-bit selector. Identifies the type of
                          Service Metadata.

      Length              16-bit unsigned integer. Length of the
                          Service metadata in 8-octet units,
                          not including the first 8 octets.

      Metadata            Variable-length field, of length such that the
                          complete IPv6 metadata header is an
                          integer multiple of 8 octets long.


5.  IANA Considerations

   TBD.

6.  Security Considerations

   TBD.






Li & Peng              Expires September 12, 2019               [Page 7]


Internet-Draft              IPv6 SFC and IFIT                 March 2019


7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

7.2.  Informative References

   [I-D.filsfils-spring-srv6-network-programming]
              Filsfils, C., Camarillo, P., Leddy, J.,
              daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
              Network Programming", draft-filsfils-spring-srv6-network-
              programming-07 (work in progress), February 2019.

   [I-D.guichard-spring-nsh-sr]
              Guichard, J., Song, H., Tantsura, J., Halpern, J.,
              Henderickx, W., and M. Boucadair, "NSH and Segment Routing
              Integration for Service Function Chaining (SFC)", draft-
              guichard-spring-nsh-sr-00 (work in progress), September
              2018.

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
              d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
              (SRH)", draft-ietf-6man-segment-routing-header-16 (work in
              progress), February 2019.

   [I-D.ietf-ippm-ioam-data]
              Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
              Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
              P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,
              "Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
              data-05 (work in progress), March 2019.

   [I-D.kumar-ippm-ifa]
              Kumar, J., Anubolu, S., Lemon, J., Manur, R., Holbrook,
              H., Ghanwani, A., Cai, D., Ou, H., and L. Yizhou, "Inband
              Flow Analyzer", draft-kumar-ippm-ifa-01 (work in
              progress), February 2019.

   [I-D.song-ippm-postcard-based-telemetry]
              Song, H., Zhou, T., Li, Z., and J. Shin, "Postcard-based
              In-band Flow Data Telemetry", draft-song-ippm-postcard-
              based-telemetry-02 (work in progress), March 2019.




Li & Peng              Expires September 12, 2019               [Page 8]


Internet-Draft              IPv6 SFC and IFIT                 March 2019


   [I-D.song-opsawg-ifit-framework]
              Song, H., Li, Z., Zhou, T., Li, Z., and J. Shin, "In-situ
              Flow Information Telemetry Framework", draft-song-opsawg-
              ifit-framework-01 (work in progress), March 2019.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/info/rfc7665>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
              "Network Service Header (NSH)", RFC 8300,
              DOI 10.17487/RFC8300, January 2018,
              <https://www.rfc-editor.org/info/rfc8300>.

Authors' Addresses

   Zhenbin Li
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: lizhenbin@huawei.com


   Shuping Peng
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: pengshuping@huawei.com













Li & Peng              Expires September 12, 2019               [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/