<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-sfc-nsh-broadband-allocation-01"
     ipr="trust200902">
  <front>
    <title abbrev="NSH Broadband Context Allocation">NSH Context Header
    Allocation for Broadband</title>

    <author fullname="Jeffrey Napper" initials="J." surname="Napper">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <email>jenapper@cisco.com</email>
      </address>
    </author>

    <author fullname="Surendra Kumar" initials="S." surname="Kumar">
      <organization>Individual Contributor</organization>

      <address>
        <email>surendra.stds@gmail.com</email>
      </address>
    </author>

    <author fullname="Praveen Muley" initials="P." surname="Muley">
      <organization>Nokia</organization>

      <address>
        <email>praveen.muley@nokia.com</email>
      </address>
    </author>

    <author fullname="Wim Hendericks" initials="W." surname="Hendericks">
      <organization>Nokia</organization>

      <address>
        <email>Wim.Henderickx@nokia.com</email>
      </address>
    </author>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>Orange</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <date day="19" month="June" year="2018" />

    <workgroup>Service Function Chaining</workgroup>

    <abstract>
      <t>This document provides a recommended allocation of Network Service
      Header (NSH) context headers within the broadband service provider
      network context. Both fixed and mobile deployments are considered.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119"></xref>.</t>
    </note>
  </front>

  <middle>
    <section anchor="sec_intro" title="Introduction">
      <t>Service Function Chaining (SFC) <xref target="RFC7665"></xref>
      provides a mechanism for network traffic to be steered through an
      ordered list of Service Functions (SFs). Furthermore, SFC allows to
      share metadata among involved SFC data functional elements (classifiers
      and SFs). Particularly, the Network Service Header (NSH, <xref
      target="RFC8300"></xref>) provides support for carrying shared metadata
      either using a fixed context header or as optional TLVs.</t>

      <t>This document describes a recommended default allocation scheme for
      the fixed-length context header used for SFC within fixed and mobile
      broadband service provider networks. Also, the document defines
      companion TLV types when MD Type 0x02 is used. The use cases describing
      the need for metadata in these deployment contexts are described in
      <xref target="I-D.ietf-sfc-use-case-mobility"></xref>.</t>

      <t>This document does not address control plane considerations. The
      reader may refer to <xref
      target="I-D.ietf-sfc-control-plane"></xref>.</t>
    </section>

    <section anchor="sec_language" title="Terminology">
      <t>This document makes use of the terms as defined in <xref
      target="RFC7498"></xref>, <xref target="RFC7665"></xref>, and <xref
      target="RFC8300"></xref>.</t>
    </section>

    <section anchor="sec_nsh"
             title="Network Service Header (NSH) Context Headers: A Reminder">
      <t>The NSH is composed of a 4-byte base header (BH1), a 4-byte service
      path header (SH1), and a fixed 16-byte context header in the case of MD
      Type 0x01 or optional TLVs in the case of MD Type 0x02 <xref
      target="RFC8300"></xref>.</t>

      <t><xref target="fig_nsh_header_md1"></xref> shows the format of the MD
      Type 0x01 NSH header.</t>

      <figure anchor="fig_nsh_header_md1"
              title="Network Service Header (MD Type 0x01)">
        <artwork><![CDATA[
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ver|O|U|    TTL    |   Length  |U|U|U|U|MD Type| Next Protocol | BH1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Service Path Identifier              | Service Index | SH1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                             Fixed                             |
   +                         Context Header                        +
   |                           (16 Bytes)                          |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>

      <t></t>

      <t><xref target="fig_nsh_header_md2"></xref> shows the MD Type 0x02 NSH
      header format.</t>

      <figure anchor="fig_nsh_header_md2"
              title="Network Service Header (MD Type 0x02)">
        <artwork><![CDATA[    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ver|O|U|    TTL    |   Length  |U|U|U|U|MD Type| Next Protocol | BH1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Service Path Identifier              | Service Index | SH1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~              Variable Length Context Headers  (opt.)          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
    </section>

    <section anchor="sec_alloc"
             title="Recommended Context Allocation For Broadband">
      <t>The following header allocations provide information to support
      service function chaining in a service provider network, for example as
      described for mobility in <xref
      target="I-D.ietf-sfc-use-case-mobility"></xref>.</t>

      <t>The set of metadata headers can be delivered to SFs that can use the
      metadata within to enforce service policy, communicate between service
      functions, provide subscriber information, and other functionality.
      Several of the headers are typed allowing for different metadata to be
      provided to different SFs or even to the same SF but on different
      packets within a flow.</t>

      <t>Which metadata are sent to which SFs is decided in the SFC control
      plane and is thus out of the scope of this document.</t>

      <section anchor="type01_allocation"
               title="MD Type 0x01 Allocation Specifics">
        <t><xref target="fig_mobility_context"></xref> provides a high-level
        description of the fields in the recommended allocation of the fixed
        sixteen byte context header for a broadband context. Each four byte
        word in the sixteen byte context header is referred to as CH1, CH2,
        CH3, and CH4, respectively.</t>

        <figure anchor="fig_mobility_context" title="NSH Context Allocation">
          <artwork><![CDATA[    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | R | Sub | Tag |                 Context ID                    | CH1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sub/Endpoint ID                         ~ CH2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                   Sub/Endpoint ID (cont.)                     | CH3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Service Information                        | CH4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t>The intended use for each of the context header fields is as
        follows: <list style="hanging">
            <t hangText="R:">MUST be set to zero upon origination, and they
            MUST be ignored and preserved unmodified by other NSH supporting
            elements.</t>

            <t hangText="Sub:">Sub/Endpoint ID type field. These bits
            determine the type of the 64-bit Sub/Endpoint ID field that spans
            CH2 and CH3. <list style="hanging">
                <t hangText="000:">The 64-bit Sub/Endpoint ID field is an
                opaque field that can be used or ignored by SFs as determined
                by the control plane.</t>

                <t hangText="001:">The Sub/Endpoint ID field contains an IMSI
                <xref target="itu-e-164"></xref>.</t>

                <t hangText="010:">The Sub/Endpoint ID field contains an
                MSISDN (8-15 digit) <xref target="itu-e-164"></xref>.</t>

                <t hangText="011:">The Sub/Endpoint ID field contains a 64-bit
                identifier that can be used to group flows (e.g., in
                Machine-to-Machine (M2M) contexts).</t>

                <t hangText="100:">The Sub/Endpoint IP field contains a
                wireline subscriber ID in CH2, and CH3 contains the line
                identifier.</t>

                <t hangText="101-111:">Reserved.</t>
              </list></t>

            <t hangText="Tag:">Indicates the type of the Service Information
            field in CH4. The following values are defined: <list
                style="hanging">
                <t hangText="000:">If the Tag field is not set, the Service
                Information field in CH4 is an opaque field that can be used
                or ignored by SFs as determined by the control plane.</t>

                <t hangText="001:">The Service Information field in CH4
                contains information related to the Access Network (AN) for
                the subscriber. This is shown in <xref
                target="fig_ran_tag"></xref> for a 3GPP Radio Access Network
                (RAN). <vspace blankLines="1" />Note that these values should
                correspond to those that can be obtained for the flow from the
                corresponding 3GPP PCRF (Policy and Charging Rules Function)
                component using Diameter as described in <xref
                target="TS.29.230"></xref>. <figure anchor="fig_ran_tag"
                    title="Service Information RAN Allocation">
                    <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CAN |    QoS/DSCP   | Con |          App Id         |  Rsvd   | CH4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ]]></artwork>
                  </figure> <list style="hanging">
                    <!-- ToS-Traffic-Class AVP (Diameter AVP code 1014): 16 bits -->

                    <t hangText="CAN:">IP-CAN-Type for IP Connectivity Access
                    Network (Diameter AVP code 1027).</t>

                    <t hangText="QoS:">QoS-Class-Identifier AVP (Diameter AVP
                    code 1028) or Differentiated Services Code Point (DSCP)
                    marking as described in <xref
                    target="RFC2474"></xref>.</t>

                    <!-- t hangText="RAT"> - RAT-Type (Diameter AVP code 1032).</t -->

                    <!-- t hangText="U"> - QoS-Upgrade AVP (Diameter AVP code 1030).</t -->

                    <t hangText="Con:">Access congestion level. An Access
                    Congestion level '000' means an unknown/undefined
                    congestion level. An Access Congestion level '001' means
                    no congestion. For other values of Access Congestion
                    level, a higher value indicates a higher level of
                    congestion.</t>

                    <t hangText="App Id:">Application ID describing the flow
                    type. Allocation of IDs is done using the control plane
                    and is out of the scope of this document.</t>

                    <t hangText="Rsvd:">Reserved.</t>
                  </list></t>

                <t hangText="010-111:">Reserved.</t>
              </list></t>

            <t hangText="Context ID:">The Context ID field allows the
            Sub/Endpoint ID field to be scoped. For example, the Context ID
            field may contain the incoming VRF, VxLAN VNID, VLAN, or a policy
            identifier within which the Sub/Endpoint ID field is defined.</t>

            <t hangText="Sub/Endpoint ID:">64-bit length Subscriber/Endpoint
            identifier (e.g., IMSI, MSISDN, or implementation-specific
            Endpoint ID) of the corresponding subscriber/machine/application
            for the flow.</t>

            <t hangText="Service Information:">The Service Information field
            is a unique identifier that can carry metadata specific to the
            flow or subscriber identified in the Sub/Endpoint ID field.</t>
          </list></t>
      </section>

      <section title="MD Type 0x02 Allocation Specifics">
        <t><xref target="fig_tlv"></xref> depictes the format of the
        recommended allocation of the variable length headers for a mobility
        context.</t>

        <figure anchor="fig_tlv" title="TLV Allocation">
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     TLV Class = 3GPP          |C|    Type     |U|U|U|   Len   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Data ...
+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t></t>

        <t>The intended use of the header is for TLVs associated with 3GPP
        Radio Access Networks as described in <xref
        target="TS.29.230"></xref>. This TLV can be used by 3GPP to extend the
        metadata as per use cases. Having this TLV helps to carry more
        information that does not fit within the MD Type 0x01.</t>

        <t>The Len field carries the total length. Type = 0x01 is reserved. If
        set to 0x01, the TLV carries the 4 context headers as defined in <xref
        target="type01_allocation"></xref>.</t>
      </section>
    </section>

    <section anchor="sec_context"
             title="Context Allocation and Control Plane Considerations">
      <t>This document describes an allocation scheme for both the fixed
      context header (MD Type#1) and optional TLV headers (MD Type#2) in the
      context of broadband service providers. This allocation of headers
      should be considered as a guideline and may vary depending on the use
      case.</t>

      <t>The control plane aspects of specifying and distributing the
      allocation scheme among different SFs within the Service Function
      Chaining environment to guarantee consistent semantics for the metadata
      is beyond the scope of this document.</t>
    </section>

    <section title="Security Considerations">
      <t>This specification relies on NSH to share metadata among SFC data
      plane elements. Security-related consideration discussed in <xref
      target="RFC8300"></xref> MUST be followed.</t>

      <t>The recommended header allocation in this document includes sensitive
      information that MUST NOT be revealed outside an SFC-enabled domain.
      Those considerations are already discussed in <xref
      target="RFC8300"></xref>. NSH allows by design to remove any NSH data
      before existing an SFC-enabled domain.</t>

      <t>Furthermore, means to prevent that illegitimate nodes insert spoofed
      data MUST be supported. As a reminder, the NSH specification assumes
      ingress boundary nodes strip any NSH data that may be present in a
      packet. Misbehaving nodes from within an SFC-enabled domain may alter
      the content of the NSH data. Such treats are discussed in <xref
      target="RFC8300"></xref>. This document does not introduce new treats
      compared to those discussed in <xref target="RFC8300"></xref>.</t>
    </section>

    <section title="IANA Considerations">
      <t>This document requests IANA to assign a TLV class for 3GPP to be used
      for its use cases.</t>
    </section>

    <section title="Acknowledgments">
      <t>The authors would like to thank Jim Guichard for his assistance
      structuring the document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.7665'?>

      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.8300'?>
    </references>

    <references title="Informative References">
      <!--
            <reference anchor='TS.23.203'>
                <front>
                    <title>Policy and charging control architecture</title>

                    <author fullname='3GPP' />

                    <date month='December' year='2013' />
                </front>

                <seriesInfo name='3GPP TS' value='23.203 12.3.0' />
                <format type='HTML' target='http://www.3gpp.org/DynaReport/23203.htm' />
            </reference>
-->

      <reference anchor="TS.29.230">
        <front>
          <title>Diameter applications; 3GPP specific codes and
          identifiers</title>

          <author fullname="3GPP"></author>

          <date month="July" year="2017" />
        </front>

        <seriesInfo name="3GPP TS" value="29.230 14.5.0" />

        <format target="http://www.3gpp.org/DynaReport/29230.htm" type="HTML" />
      </reference>

      <!--
            <reference anchor='kumar-sfc-offloads'>
                <front>
                    <title>Service Function Simple Offloads</title>
                    <author initials='S.' surname='Kumar'/>
                    <author initials='J.' surname='Guichard'/>
                    <author initials='P.' surname='Quinn'/>
                    <author initials='J.' surname='Halpern'/>
                    <date month='March' year='2016' />
                </front>
                <seriesInfo name='I-D' value='draft-kumar-sfc-offloads-02 (work in progress)' />
            </reference>
-->

      <!--
            <reference anchor='guichard-sfc-nsh-dc-allocation'>
                <front>
                    <title>Network Service Header (NSH) Context Header Allocation (Data Center)</title>
                    <author surname='Guichard' initials='J.'/>
                    <author surname='Smith' initials='M.'/>
                    <author surname='Kumar' initials='S.'/>
                    <author surname='Majee' initials='S.'/>
                    <author surname='Agarwal' initials='P.'/>
                    <author surname='Glavin' initials='K.'/>
                    <author surname='Laribi' initials='Y.'/>
                    <date month='June' year='2015' />
                </front>
                <seriesInfo name='I-D' value='draft-guichard-sfc-nsh-dc-allocation-02 (work in progress)' />
            </reference>
-->

      <reference anchor="itu-e-164">
        <front>
          <title>The international public telecommunication numbering
          plan</title>

          <author fullname="Telecommunication Standardization Sector Of ITU"></author>

          <date month="November" year="2010" />
        </front>

        <seriesInfo name="ITU-T" value="E.164" />
      </reference>

      <?rfc include='reference.RFC.2474'?>

      <?rfc include='reference.RFC.7498'?>

      <?rfc include='reference.I-D.ietf-sfc-use-case-mobility'?>

      <?rfc include='reference.I-D.ietf-sfc-control-plane'?>
    </references>
  </back>
</rfc>
