<?xml version="1.0" encoding="US-ASCII"?>
<!-- This is built from a template for a generic Internet Draft. Suggestions for
     improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com 
     This can be converted using the Web service at http://xml.resource.org/ -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- You want a table of contents -->
<!-- Use symbolic labels for references -->
<!-- This sorts the references -->
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<?rfc sortrefs="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<rfc category="info" docName="draft-zheng-panrg-path-properties-istn-00"
     ipr="trust200902">
  <front>
    <title abbrev="Network Working Group">Required path properties for
    applying path aware networking in integrated space-terrestrial
    networks</title>

    <author fullname="Shaowen Zheng" initials="S." surname="Zheng">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100053</code>

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

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

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

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100053</code>

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

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

    <author fullname="Danyang Chen" initials="Z." surname="Chen">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100053</code>

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

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

    <!---->

    <date day="22" month="February" year="2021"/>

    <area>Networking</area>

    <workgroup>Path Aware Networking Research Group</workgroup>

    <keyword>panrg; integrated space-terrestrial networks;</keyword>

    <abstract>
      <t>Integrated space-terrestrial networks are heterogeneous networks with
      various path characteristic, and usually belong to different
      administrative domains. Therefore integrated space-terrestrial networks
      can be seen as a use case of path-aware networking. This memo introduces
      requirements on path properties when applying path-aware-network in
      integrated space-terrestrial networks. </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"/>.</t>
    </note>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>In the integrated space-terrestrial networks, endpoint is capable to
      access space networks, mobile networks, and fixed networks. These
      heterogeneous networks have essential difference on characteristics and
      come from different service providers, which makes it difficult to carry
      out unified management and control. Furthermore, different with ground
      networks, the quality of links in space is fluctuating, the network
      topology changes dynamically, and the resources of space node is
      limited. It is necessary to come out a system to release the burden of
      networks(especially space nodes with limited resource) and leaving the
      complex function to endpoint. In other words, the path-aware network may
      help to cope with the dynamics of this kind of network.</t>

      <t>According to the definition of <xref target="RFC5136"/>, a path is a
      series of links that connect a series of nodes from the source node to
      destination. The properties of path can be seen from the overall point
      of view, or decomposed into node properties and link properties.
      Corresponding granular path awareness can be performed in the basis of
      the capability of the endpoint and/or the required quality of service.
      This memo will describe the required path properties from different
      granularity in integrated space-terrestrial networks.</t>
    </section>

    <section title="Terminology and Abbreviation">
      <t>Integrated space-terrestrial Networks(ISTN): A network system that
      comprehensively utilizes a variety of communication network technologies
      including space networks and terrestrial networks to achieve global
      coverage. The integrated system includes ground segment and space
      segment. The ground segment includes terrestrial network nodes such as
      ground stations, terminals, servers controllers and terrestrial links
      such as cable, fiber. Space segment includes space node such as
      satellites and space links such as laser and radio.</t>
    </section>

    <section title="Path properties" toc="default">
      <t>The path properties describe the overall properties of the whole path
      from an end-to-end perspective.</t>

      <t>Space and ground networks share some common properties, but due to
      the essential differences between the space network and the terrestrial
      network on characteristics such as mobility, link stability, resources
      etc., some additional properties are required to support path selection
      at the endpoint.</t>

      <t>Common path properties</t>

      <t>1. Properties in path properties<xref
      target="I-D.irtf-panrg-path-properties"/>,such as one way delay and one
      way packet loss.</t>

      <t>Additional path properties in space</t>

      <t>1.Available time: path available time; due to the topological
      dynamics of the space link, the path in the world-ground integrated
      network is not always available. Therefore, it is necessary to set an
      available time for each path;</t>
    </section>

    <section title="Fine granular properties" toc="default">
      <t>In addition to the fluctuating latency, and bandwidth, the complex
      space environment will lead to unpredictable wireless link
      disconnection.The mobility of space nodes will lead to periodic dynamic
      topology change. Therefore, the performance of the path changes more
      frequently, and the fine granular properties can help the integrated
      space-terrestrial networks to quickly locate unpredictable faults and
      find the optimal alternative link instead of discarding the entire path.
      For example, path properties can be decomposed into node properties and
      link properties.</t>

      <section title="node properties">
        <t>Common properties of nodes</t>

        <t>1.Node computing resources: computing resources available on ground
        nodes/space nodes. When the available computing resource is less, it
        indicates that the node is heavy-loaded, and the path that contains
        the node should be avoided when selecting a path.</t>

        <t>2.Node storage resources: available storage resources of ground
        nodes/space nodes.</t>

        <t>Additional node properties in space</t>

        <t>1.Node power: This is actually the most important property of
        space, because the energy of satellite in space comes from solar
        panels, which make the node energy fluctuating with time. If the power
        of the satellite node is not sufficient to support additional
        computing/communication functions, the satellite node is not
        available; it can be simply set to 0/1 to indicate whether the node
        supports additional computing/communication functions.</t>

        <t>2.Available interfaces of the node. The interface that can be used
        to establish a link, it may contain a set of information indicating
        the direction of interface and available next hop. This property can
        be use to derive the topology information. The specific link status is
        excluded and needs to query the link properties described below.</t>

        <t>3.The future available interfaces of the node. The movement of
        satellite nodes is periodic. Periodicity can be used to predict the
        topology in the future to help make routing decisions. This property
        can be sent in different manners, depending on the mechanism the
        system used to deal with the network mobility. This property can be
        sent in each time slot if the system use snapshot. Or to reduce the
        interaction cost, event triggered property notification can be used,
        that is the notification only executes when the available interfaces
        changes due to unexpected event.</t>
      </section>

      <section title="Link properties">
        <t>Common link properties</t>

        <t>1.Propagation delay:When a data packet propagates from the source
        node to the destination node, the time required for the transmission
        from the beginning to the end of the link is the propagation delay.
        Data packets are propagated at the propagation rate of the link, and
        its rate depends on the physical medium of the link. The propagation
        delay is equal to the ratio of the distance between the nodes and the
        propagation rate. As the distance between the nodes changes as space
        node moves, the delay changes as well.</t>

        <t>2.Link media: the link media can be laser/cable/radio etc., and the
        different media can have different priority and cost, which should be
        used to do the path selection decision.</t>

        <t>3.Quality of link: This property can be indicated by bit error rate
        or packet loss rate, depending on the network system.</t>

        <t>Additional link properties in space</t>

        <t>1. Available time: When the nodes at both ends of a link are
        constantly moving relative to each other, the link may be unavailable
        because the nodes move out of mutual visible area. Therefore, it is
        necessary to know the available time of the link.</t>

        <t>2. Link status: different from bit error rate, this property
        indicates the state of link, for example, when the link is temporarily
        unavailable due to space environment, it can be set in leave and; when
        the link is unavailable due to mobility, it can be set to down . The
        link state information may not come from space node itself but from
        ground measurement and control station.</t>
      </section>
    </section>

    <section title="Summary">
      <t>Integrated space-terrestrial Networks can take advantage of the PAN
      and can be seen as a typical use cases. When PAN is introduced into
      ISTN, it will have some different requirements on the path properties,
      and this memo study the first question in <xref
      target="I-D.irtf-panrg-questions"/> by list and explain some potential
      path properties.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>It should be noticed that under the Integrated space-terrestrial
      Networks background, the topology information comes from different
      operators, they may not willing to expose their network information to
      other operators or other 3rd parties, so it is crucial to find a way to
      supply the information to end user while not expose to others.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document has no requests to IANA.</t>
    </section>
  </middle>

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

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

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

      <?rfc include="reference.I-D.draft-irtf-panrg-questions-08"?>
    </references>
  </back>
</rfc>
