<?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="info" docName="draft-fu-panrg-path-selection-req-00"
     ipr="trust200902">
  <front>
    <title abbrev="draft-fu-panrg-path-selection-req-00">Requirements of
    applying path-aware networking for dynamic path selection</title>

    <author fullname="Yuexia Fu" initials="Y" surname="Fu">
      <organization>China Mobile</organization>

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

          <code>100053</code>

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

        <email>fuyuexia@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Peng Liu" initials="P" surname="Liu">
      <organization>China Mobile</organization>

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

          <code>100053</code>

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

        <email>liupengyjy@chinamobile.com</email>
      </address>
    </author>

    <date day="12" month="July" year="2021"/>

    <workgroup>PANRG</workgroup>

    <abstract>
      <t>Emerging new services have new business characteristics, different
      from traditional C/S business model, whose most traffic is downstream
      traffic, more and more new business with gradually increasing upstream
      traffic have appeared, such as short videos, live sales etc, . Due to
      the new traffic characteristics of these services, more requirements
      have been put forward for the choice of network paths. In addition,
      emerging services also put forward new requirements for computing. Only
      selecting the network path or the service node cannot meet the stringent
      requirements. The perception of network paths and path selection also
      need to consider the characteristics of the service, and further need to
      coordinate the state of the network side and the service node side. The
      application of path-aware networking can assist the terminal to better
      perceive the network status, and also combine the status of the service
      node to achieve on-demand, more fine-grained path selection.</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>In path-aware networking architecture, endpoints have the ability to
      select or influence the path through the network used by any given
      packet or flow. The network and transport layers explicitly expose
      information about the path or paths available from one endpoint to
      another, and to those endpoints and the applications running on them, so
      that they can make this selection [draft-irtf-panrg-questions-09]. This
      draft targets at the third question in [draft-irtf-panrg-questions-09]:
      how can endpoints select paths to use for traffic in a way that can be
      trusted by the network, the endpoints, and the applications using
      them?</t>

      <t>And this draft targets at the path selection use case of path-aware
      networking, and we both consider the scenario that a set of paths to the
      same destination and also the scenario that several destinations with
      several paths. According to [draft-irtf-panrg-path-properties-02],
      entities may select their paths to fulfill a specific goal, e.g.,
      related to security or performance, as an example of performance related
      path selection, an entity may prefer paths with performance properties
      that best match its traffic requirements. In this draft, we target at
      the services with various traffic requirements for upstream and
      downstream traffic and also with requirements to service endpoint
      Different types of services have different requirements to
      network&#65306;</t>

      <t>1. For transmission-intensive services, the amount of data
      transmitted is large, so the choice of network path affects the entire
      service larger.</t>

      <t>2. For computing-intensive services, the computing tasks of service
      endpoint are complex and the choice of endpoint affect the entire
      service is large</t>

      <t>3. And traditional transmission-intensive services tend to have a lot
      of downstream traffic, so they usually specify the downstream path.</t>

      <t>4. For transmission-intensive services with large upstream traffic,
      such as short video and live broadcast, the upstream path matters a lot
      so the perception and specification of upstream path is necessary to
      meet service requirements.</t>

      <t>So the terminal needs to be aware of both the status of the uplink
      path and the downlink path, and specify the uplink path and the downlink
      path based on service characteristics. What&rsquo;s more, for
      computing-intensive services, the terminal still needs to be aware of
      the status of service endpoint, and the path-aware networking also need
      to consider the status of endpoint when select network path.</t>
    </section>

    <section title="On-demand awareness on paths and path properties">
      <t>For services with different requirements, when path-aware networking
      is applied to realize path perception, it is necessary to dynamically
      determine the perceived target paths and target path attributes, such as
      perceiving the given upstream path or the given downstream path, and
      perceiving path latency or path bandwidth
      [draft-irtf-panrg-path-properties-02]. When user initiates a service
      request, path-aware networking needs to analyses service requirements
      related to path-awareness, including time sensitivity, traffic amount,
      and traffic characteristics etc, and decide to be aware of which set of
      paths and which path properties of them. So path-aware networking needs
      to specify the following information:</t>

      <t>1. Service requirements towards path-awareness</t>

      <t>2. Target paths to be perceived</t>

      <t>3. Target path properties to be perceived</t>

      <t>For example, when a service with large amount of uplink traffic and
      strict requirements on service latency is requested, path-aware
      networking assign a set of uplink paths which are to be perceived, and
      determine the target path property is path latency, and then specify the
      above mentioned upstream paths to user, and then user initiate uplink
      path detection packet towards given paths carrying target path
      properties , and then the network nodes along the path writes the
      required path properties information. With path-aware networking, the
      given paths and corresponding properties are obtained, and user can
      select optimal uplink path which meet service requirements.</t>
    </section>

    <section title=" Definition and application of path property weight ">
      <t>In path-aware network, instead of using single MED value, other
      properties such as Link Capacity or Link Usage could additionally be
      used to improve load balancing or performance
      [I-D.ietf-idr-performance-routing]. And more properties are required to
      be considered for new emerging services
      [draft-irtf-panrg-path-properties-02].</t>

      <t>The transmission of upstream traffic and downstream traffic, and also
      data processing by the service endpoint form a complete service process
      (face recognition, CLOUD A/VR, etc.). So the completion of the service
      needs to consider multi-dimensional factors.</t>

      <t>For path-aware networking, facing diverse service requirements and
      multi-dimensional path properties, to solve the problem of how to
      comprehensive select path considering service requirements, a new
      parameter needs to be introduced: path property weight values, which
      represent the weight of each path properties and are used to
      comprehensively define the perceived multi-dimensional path properties.
      And then the path-aware networking needs to specify the following
      information:</t>

      <t>1. Service requirements towards path-awareness</t>

      <t>2. Target paths to be perceived</t>

      <t>3. Target path properties to be perceived</t>

      <t>4. Path property weight values of target path properties</t>

      <t>For example, for requested services that require large uplink
      bandwidth, path-aware networking need to define larger uplink path
      bandwidth weight, and calculates the target "uplink path + downlink
      path" pair based on the given weight value.</t>
    </section>

    <section title="Service endpoint consideration in path-aware networking">
      <t>Many emerging services not only put forward new requirements for the
      network, but also put forward requirements for computing. For services
      such as AR/VR, the budgets for computing delay and network delay are
      almost equivalent [draft-liu-dyncast-ps-usecases-01] , therefore, when
      path-aware network perceives paths, designates path and selects paths,
      it also needs to consider the status of the service endpoint. And then
      the path-aware networking needs to specify the following
      information:</t>

      <t>1. Service requirements towards path-awareness, including service
      endpoint</t>

      <t>2. Target service endpoints and properties</t>

      <t>3. Target paths to be perceived corresponding to target service
      endpoints</t>

      <t>4. Target path properties to be perceived</t>

      <t>5. Path property weight values of target path properties including
      service endpoint</t>

      <t>And when the requested service is a computationally intensive
      service, the status of the service endpoint will have a greater impact
      in the entire process. Therefore, it is also necessary to select an
      optimal service endpoint to provide services. Path-aware networking
      needs to generate multiple target paths for multiple candidate service
      endpoints, and specify new path parameter weight values towards target
      path properties and target service endpoint status.</t>
    </section>

    <section title="Summary">
      <t>The dynamic path selection considering service requirements and
      service characteristics has become one of the current technical
      development directions. This draft analyzes the application of
      path-aware networking to achieve the on-demand path awareness and
      service endpoint awareness, and provides optimal path selection.</t>
    </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.I-D.irtf-panrg-questions"
?>

      <?rfc include="reference.I-D.irtf-panrg-path-properties-02"?>

      <?rfc include="reference.I-D.ietf-idr-performance-routing"?>

      <?rfc include="reference.I-D.liu-dyncast-ps-usecases"
?>

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

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>
    </references>
  </back>
</rfc>
