<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-li-teas-e2e-ietf-network-slicing-00"
     ipr="trust200902">
  <front>
    <title abbrev="E2E IETF Network Slicing">Framework for End-to-End IETF
    Network Slicing</title>

    <author fullname="Zhenbin Li" initials="Z." surname="Li">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Road</street>

          <city>Beijing</city>

          <code>100095</code>

          <country>China</country>
        </postal>

        <email>lizhenbin@huawei.com</email>
      </address>
    </author>

    <author fullname="Jie Dong" initials="J." surname="Dong">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Road</street>

          <city>Beijing</city>

          <code>100095</code>

          <country>China</country>
        </postal>

        <email>jie.dong@huawei.com</email>
      </address>
    </author>

    <date day="14" month="April" year="2021"/>

    <abstract>
      <t>Network slicing can be used to meet the connectivity and performance
      requirement of different services or customers in a shared network. An
      IETF network slice may span multiple network domains. In the context of
      5G, the 5G end-to-end network slices consist of three major types of
      network segments: Radio Access Network (RAN), Transport Network (TN) and
      Core Network (CN).</t>

      <t>In order to facilitate the mapping between network slices in
      different network segments and network domains, it is beneficial to
      carry the identifiers of the 5G end-to-end network slice, the
      multi-domain IETF network slice together with the intra-domain network
      slice identifier in the data packet.</t>

      <t>This document describes the framework of end-to-end IETF network
      slicing, and introduces the identifiers for 5G end-to-end network slice
      and the multi-domain IETF network slice in the data packet. The roles of
      the different identifiers in packet forwarding is also described. The
      network slice identifiers can be instantiated with different data
      planes.</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">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>The definition and the characteristics of IETF network slice are
      introduced in <xref
      target="I-D.ietf-teas-ietf-network-slice-definition"/>, and <xref
      target="I-D.ietf-teas-ietf-network-slice-framework"/> describes a
      general framework of IETF network slice.</t>

      <t><xref target="I-D.ietf-teas-enhanced-vpn"/> describes the framework
      and the candidate component technologies for providing enhanced VPN
      services, by utilizing an approach that is based on existing VPN and
      Traffic Engineering (TE) technologies and adds characteristics that
      specific services require above traditional VPNs. VPN+ can be built from
      a VPN overlay and an underlying Virtual Transport Network (VTN) which
      has a customized network topology and a set of dedicated or shared
      resources in the underlay network. Enhanced VPN (VPN+) can be used for
      the realization of IETF network slices.</t>

      <t><xref target="I-D.dong-teas-enhanced-vpn-vtn-scalability"/> describes
      the scalability considerations in the control plane and data plane to
      enable VPN+ services, and provide several suggestions to improve the
      scalability of VTN. In the control plane, It proposes the approach of
      decoupling the topology and resource attributes of VTN, so that multiple
      VTNs may share the same topology and the result of topology based path
      computation. In the data plane, it proposes to carry a VTN-ID of a
      network domain in the data packet to determine the set of resources
      reserved for the corresponding VTN.</t>

      <t>An IETF network slice may span multiple network domains. Further in
      the context of 5G, there can be end-to-end network slices which consists
      of three major types of network segments: Radio Access Network (RAN),
      Transport Network (TN) and Core Network (CN). In order to facilitate the
      mapping between network slices in different network segments and network
      domains, it may be beneficial to also carry the identifiers of the 5G
      end-to-end network slice, the multi-domain IETF network slice together
      with the intra-domain network slice identifier in the data packet.</t>

      <t>This document describes the scenarios of end-to-end network slicing,
      and the framework of network slice mapping between different network
      segments and network domains. Then multiple network slice related
      identifiers are defined to covers different network scopes. These
      network slice identifiers can be instantiated using different data
      planes, such as MPLS and IPv6.</t>
    </section>

    <section title="Framework">
      <t/>

      <figure>
        <artwork align="center"><![CDATA[

    /----\        /----\         /----\          /----\         /----\
   /      \     //      \\     //      \\      //      \\      /      \
  |  RAN   |---|   TN-1   |---|   TN-2   |----|   TN-3   |----|  Core  |
   \      /     \\      //     \\      //      \\      //      \      /
    \----/        \----/         \----/          \----/         \----/

    S-NSSAI
  o--------------------------------------------------------------------o
             IETF Network Slice (VPN+)
           o--------------------------------------------------o
                Global VTN
              o===========================================o
                Local VTN-1   Local VTN-2      Local VTN-3
              o************o o************o   o***********o

Figure 1. 5G end-to-end network slicing scenario
]]></artwork>
      </figure>

      <t/>

      <t>One typical scenario of 5G end-to-end network slicing is shown in
      figure 1. The 5G end-to-end network slice is identified by the S-NSSAI
      (Single Network Slice Selection Assistance Information). In the
      transport network segment, the 5G network slice is mapped to an IETF
      network slice, which is realized with a multi-domain VPN+ service. In
      the underlay network, the multi-domain VPN+ service is supported by a
      multi-domain VTN (Virtual Transport Network), which is comprised by
      multiple intra-domain VTNs in different domains. In each domain, a local
      VTN-ID is carried in the packet to identify the set of network resource
      reserved for the VTN in the corresponding domain.</t>

      <t>In order to concatenate multiple local VTNs into a multi-domain VTN,
      the global VTN-ID can be carried in the packet, which is used by the
      network domain border routers to map to the local VTN-IDs in each
      domain. And in order to facilitate the network slice mapping between
      RAN, Core network and transport network, the S-NSSAI may be carried in
      the packet sent to the transport network, which can be used by the
      transport network to map the 5G end-to-end network slice to the
      corresponding IETF network slice.</t>

      <t>According to the above end-to-end network slicing scenario, there can
      be three network slice related identifiers:</t>

      <t><list style="symbols">
          <t>Local VTN-ID: This is the VTN-ID as defined in <xref
          target="I-D.dong-teas-enhanced-vpn-vtn-scalability"/>. It is used by
          the network nodes in a network domain to determine the set of local
          network resources reserved for a VTN. It SHOULD be processed by each
          hop along the path in the domain.</t>

          <t>Global VTN-ID: This is the identifier which uniquely identifies a
          multi-domain VTN. In each network domain, the domain edge node maps
          the global VTN-ID to a local VTN-ID for packet forwarding.</t>

          <t>5G end-to-end network slice ID (S-NSSAI): This is the identifier
          of the 5G end-to-end network slice. When required, it can be used by
          the network nodes to provide traffic monitoring at the end-to-end
          network slice granularity.</t>
        </list> For the above network slice identifiers, the local VTN-ID is
      mandatory, the Global VTN-ID and the 5G S-NSSAI are optional. The
      existence of the Global VTN-ID depends on whether the VTN spans multiple
      network domains in the transport network. The existence of the 5G
      S-NSSAI depends on whether an IETF network slice is used as part of the
      5G end-to-end network slice.</t>
    </section>

    <section title="Requirements on E2E IETF Network Slicing">
      <t>This section lists the requirements on E2E IETF network slicing.</t>

      <section title="Data Plane">
        <t>To facilitate the mapping between 5G end-to-end network slice and
        IETF network slice, and the mapping between multi-domain IETF network
        slice and the intra-domain IETF network slice, different network slice
        related identifiers (e.g. S-NSSAI, Global VTN-ID, local VTN-ID) needs
        to be carried in the data packet.</t>
      </section>

      <section title="Management Plane/Control Plane">
        <t>For multi-domain IETF network slice, a centralized IETF network
        slice controller is responsible for the allocation of the Global
        VTN-ID and the Local VTN-ID, and the provisioning mapping relationship
        of the Global VTN-ID and the Local VTN-IDs to the network edge nodes
        in different network domains.</t>

        <t>For 5G end-to-end network slice, the edge node of transport network
        can derive the S-NSSAI from the packet sent by the RAN or Core
        network, and encapsulate it an outer packet header or tunnel
        information when traversing the transport network. The controller
        needs to be responsible for creating the mapping relationship and
        provisioning it to the edge nodes of the transport network.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>TBD</t>
    </section>
  </middle>

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

      <?rfc include='reference.I-D.ietf-teas-ietf-network-slice-definition'?>

      <reference anchor="I-D.ietf-teas-ietf-network-slice-framework"
                 target="https://tools.ietf.org/html/draft-ietf-teas-ietf-network-slice-framework">
        <front>
          <title>Framework for IETF Network Slices</title>

          <author fullname="Eric Gray (editor)" initials="E." surname="Gray">
            <organization>Ericsson</organization>
          </author>

          <author fullname="John Drake (editor)" initials="J." surname="Drake">
            <organization>Juniper Networks</organization>
          </author>

          <date day="8" month="March" year="2021"/>
        </front>
      </reference>

      <?rfc include='reference.I-D.ietf-teas-enhanced-vpn'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.dong-teas-enhanced-vpn-vtn-scalability'?>
    </references>
  </back>
</rfc>
