<?xml version="1.0" encoding="utf-8"?>
<!-- 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 https://xml2rfc.tools.ietf.org/ -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<!-- You want a table of contents -->
<?rfc symrefs="yes"?>
<!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?>
<!-- This sorts the references -->
<?rfc iprnotified="no" ?>
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>
<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-jiang-service-oriented-ip-03" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.44.0 -->
  <front>
    <title abbrev="Service Oriented IP">Service Oriented Internet Protocol</title>
    <seriesInfo name="Internet-Draft" value="draft-jiang-service-oriented-ip-023"/>
    <author fullname="Brian Carpenter" initials="B. E." surname="Carpenter">
      <organization abbrev="Univ. of Auckland">The University of Auckland</organization>
      <address>
        <postal>
          <street>School of Computer Science</street>
          <street>University of Auckland</street>
          <street>PB 92019</street>
          <city>Auckland</city>
          <region/>
          <code>1142</code>
          <country>New Zealand</country>
        </postal>
        <email>brian.e.carpenter@gmail.com</email>
      </address>
    </author>
    <author fullname="Sheng Jiang" initials="S." surname="Jiang">
      <organization>Huawei Technologies Co., Ltd</organization>
      <address>
        <postal>
          <street>Q14, Huawei Campus, No.156 Beiqing Road</street>
          <city>Hai-Dian District, Beijing, 100095</city>
          <country>P.R. China</country>
        </postal>
        <email>jiangsheng@huawei.com</email>
      </address>
    </author>
    <author fullname="Guangpeng Li" initials="G." surname="Li">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Q14, Huawei Campus</street>
          <street>No.156 Beiqing Road</street>
          <city>Hai-Dian District, Beijing</city>
          <code>100095</code>
          <country>P.R. China</country>
        </postal>
        <email>liguangpeng@huawei.com</email>
      </address>
    </author>
    <date day="15" month="May" year="2020"/>
    <abstract>
      <t> This document proposes a new, backwards-compatible, approach
      to packet forwarding, where the service required rather than the
      IP address required acts as the vector for routing packets at 
      the edge of the network. Deeper in the network, the mechanism
      can interface to conventional and future methods of service or
      application aware networking.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
      An important aspect of the Internet today is that it is no 
      longer a uniform space with uniform requirements. For both
      technical and economic reasons, we see an emerging trend of
      usage scenarios that are confined to some form of limited domain,
      and which inevitably lead to applications and protocols that are
      only suitable within a given scope <xref target="I-D.carpenter-limited-domains" format="default"/>.
      In particular, various techniques have emerged for packet treatments
      that are specific to a type of application or service.
      This trend collides immediately with two factors: the original
      design concept of an Internet with end to end IP transparency
      (such that any locally defined protocol running over IP is almost
      certain to escape the local network), and with the increasing
      presence of middleboxes. In this emerging context,
      where end to end IP service is no longer a safe assumption, and
      where there is increasing demand for specific services,
      this document proposes a new, backwards-compatible, approach
      to packet forwarding, where the service required rather
      than the IP address required acts as the vector for routing packets
      at the edge of the network, close to the host requiring a particular
      service or application. This form of service based packet
      forwarding is referred to as Service Oriented IP (SOIP).
      </t>
      <t>We propose an addition to the existing core function of the
      network, which is reachability over IPv6 or IPv4. Today, IP is
      focussed on reachability, using best effort forwarding both to
      find a route and to automatically share transmission resources
      in a simple and low-cost way. As a result, transport protocols
      such as TCP and UDP learn little or nothing about the network,
      beyond congestion or loss signals. Several ISPs may lie on the
      path between a user and a server, but they are largely ignorant
      about the services a user requires. Typical services could be
      streamed content, regular content, user posting, storage access,
      or calculation, but this list is not exclusive.</t>
      <t>Both service providers and users will benefit if a packet
      stream can be identified intrinsically as requiring a certain
      kind of service. This is particularly applicable for edge networks,
      such as those supported by 5G technology, where there
      is an emphasis on upper layer service provision.
      Whatever the business model - for example the
      ISP operates all types of service, or the ISP operates no user
      services at all and has contracts with specific service providers,
      or the ISP is agnostic about user services - SOIP will allow for
      optimised packet delivery. The ISP will have the choice to provide
      some or all services. The user will have the choice to use ISP
      services or bypass them. Traffic that leaves the domain where SOIP
      is in use will be perfectly normal IPv6 or IPv4 traffic, sent
      by an exit node acting as a proxy (not an IP-layer translator)
      for the user. Additionally, IPv6 and IPv4 will be modelled as
      services available to the user, thereby giving continuity of
      access to everything the user has today. This is a logical
      extension of a principle already adopted to model IPv4 as
      a service available via IPv6 <xref target="RFC8585" format="default"/>.</t>
      <t>As new service and application oriented features are
      deployed in the network, SOIP will provide a seamless
      interface to both existing and future mechanisms.
      Effectively it will make client hosts future-proof
      as the network evolves.</t>
    </section>
    <section anchor="solution" numbered="true" toc="default">
      <name>Proposed Solution</name>
      <t>NOTE: This is a preliminary draft expected to stimulate discussion,
    so many details are not yet defined.</t>
      <t>The approach is to make the service be the central
    component of the network, from the end user's point of view.
    Conceptually, the user's packets
    will be directed at a service, not at an IP host. The first
    hop SOIP router will either forward the packets to an
    upstream SOIP router, or immediately dispatch the session
    to a suitable service. At least one SOIP router in a domain
    must be capable of acting as a dispatcher.
    The dispatched traffic may either remain
    in SOIP format, or be transformed by a proxy mechanism into
    a conventional IP-based format. <xref target="dispatch-fig" format="default"/>
    gives an overview, and <xref target="continuity" format="default"/> and
    <xref target="interf" format="default"/> discuss this further.
      </t>
      <figure anchor="dispatch-fig">
        <artwork name="" type="" align="left" alt=""><![CDATA[
-----------         -----------
|End-user | <-----> |  SOIP   |
|  Host   |         | router  |
-----------         -----------
                         ^
                         |
                         v
   --------------   -----------    -----------------
   | SOIP-based |   | SOIP     |   | Unknown       |
   | services   |---| router + |---| future        |
   |            |   |dispatcher|   | services      |
   --------------   ------------   -----------------
                     |    |   |
   --------------    |    |   |    -----------------
   |Traditional |____/    |   \____|Segment Routing|
   |IP services |         |        |services       |
   --------------   ------------   -----------------
                    |   SDN    |
                    | services |
                    ------------ 
 ]]></artwork>
      </figure>
      <t>The service actions that the network can provide are
    abstracted into a number of classes called Service Action
    Types (SATs). While there needs to be flexibility and
    extensibility, the number of service action types will
    be limited. They will not be numerous like IP protocol
    numbers or well-known TCP or UDP port numbers. Along with
    the SAT, a source IPv6 address is used to identify the client
    system.  As will be seen below, the destination IPv6 address
    becomes optional. A consequence is that the IP header and
    some aspects of the protocol stack have to be redesigned.
    We will show below how this can be done without disturbing
    most of the running network. Another consequence is that
    the first step in processing a packet is to process the SAT,
    not the destination address (if there is one).</t>
      <t>Traditional reachability, when required, is provided
    by classical IPv6, or by IPv4 as-a-service.</t>
      <t>When an SOIP packet enters a router, it is classified at
    line speed according to the SAT. Routing to upstream SOIP routers
    will be based on the SAT, not on a destination IP address. Routing from
    a dispatcher may be based on the SAT if the service required
    is based on SOIP, or on a conventional IP address otherwise.
    A preliminary list of SATs is shown in <xref target="SAT-fig" format="default"/>, with brief descriptions:

      </t>
      <figure anchor="SAT-fig">
        <artwork name="" type="" align="left" alt=""><![CDATA[
------------------------------------------------------------------
| SATs             | Direction | Description                     |
|----------------------------------------------------------------|
| IPv4 reachability| Request   | IPv4 destination host           |
|                  |___________|                                 |
|                  | Response  | IPv4 source host                |
|----------------------------------------------------------------|
| IPv6 reachability| Request   | IPv6 destination host           |
|                  |___________|                                 |
|                  | Response  | IPv6 source host                |
|----------------------------------------------------------------|
| Discovery Service| Request   | Discover network services, e.g. |
|                  |___________| DNS, CDN. May map to IP Anycast |
|                  | Response  | Content ID, service ID.         |
|                  |           | Or "service not available" error|
|----------------------------------------------------------------|
| Multicast Service| Request   | Join multicast service for some |
|                  |___________| content, e.g. video stream      |
|                  | Response  | Multicast directory answers     |
|                  |           | request, provides m/c source.   |
|----------------------------------------------------------------|
| Computation      | Request   | Submit task to network, with    |
| Service          |           | computation type, task          |
|                  |___________| descriptor and requester ID     |
|                  | Response  | Computation resource ID, or     |
|                  |           | direct result of task.          |
|                  |           | Or "service not available" error|
|----------------------------------------------------------------|
| Storage Service  | Request   | Submit/retrieve data to/from    |
|                  |           | network storage, with data      |
|                  |___________| description and/or data ID      |
|                  | Response  | Storage locator, data ID.       |
|                  |           | Or "service not available" error|
|----------------------------------------------------------------|
| App Server       | Request   | To submit source code or deploy |
| Service          |           | package to application platform,|
|                  |___________| with necessary configurations.  |
|                  | Response  | Answer with service ID.         |
|                  |           | Or "service not available" error|
------------------------------------------------------------------
 ]]></artwork>
      </figure>
      <t>For each request there will be a corresponding response.
    The details remain to be worked out - probably a generic response
    message including the SAT. To allow multiple overlapping sessions,
    each request/response sequence should have a unique ID, which will
    be used by the SOIP dispatcher to match service responses to the appropriate
    user session.
    <!-- (similar to the Session ID in GRASP). -->
      </t>
      <t>For IPv6-only networks, is expected that IPv4 reachability
    will be provided by a solution such as 464XLAT. Also, no separate
    SAT is needed for IPv6 to IPv4 translation. For example,
    if a host requests IPv4 reachability but supplies an IPv6 address as
    its own locator, NAT64 <xref target="RFC6146" format="default"/> is implied.</t>
      <t>For the moment codes for the SATs are undefined,
    but they are assumed to be small integers.
    There are two possible approaches to the packet format. 
    One is to use a traditional Type-Length-Value (TLV) layout.
    Another is to use a more flexible encoding at the lowest
    level, taking advantage of some form of network processor
    in the routers. An obvious choice would be Concise Binary 
    Object Representation (CBOR) <xref target="RFC7049" format="default"/>, which combines flexibility
    with efficiency. In either case we could require that the first
    four bits of the wire format are a new IP version number other
    than 4 or 6. An alternative, at least for early experimentation,
    is to run SOIP over UDP and IPv6.</t>
      <t>Examples of both encoding choices are described below.
    In either case, the essential content of a packet header
    is as follows:
      </t>
      <ul spacing="normal">
        <li>The SAT code (small integer)</li>
        <li>Flag bits</li>
        <li>Traffic class (as for IPv6)</li>
        <li>Session Identifier  (so that sessions can be tracked regardless of IP address)</li>
        <li>Hop limit (small integer)</li>
        <li>User locator (IP address or identifier)</li>
        <li>Service data length (not needed in CBOR version)</li>
        <li>Service data (length depends on SAT)</li>
        <li>Payload length (not needed in CBOR version)</li>
        <li>Payload</li>
      </ul>
      <t>Experience with IPv4 options, and IPv6 extension headers
    and options, has shown that new ones are very hard to deploy 
    on an operational network, and that the ones defined during
    the initial design are not always useful. Therefore we propose
    that all options and extensions are defined as part of the
    service data and are not visible as part of the basic packet
    header, giving good flexibility.</t>
      <t>We propose to include the exact equivalent of the IPv6
    Traffic Class <xref target="RFC8200" format="default"/>,
    which can work exactly as for IPv6. 
    In contrast, one defect in the IPv6 flow label
    <xref target="RFC6437" format="default"/> is that it is
    different in the two directions of a flow. Instead we propose
    a session ID that is the same in both directions, which has
    various advantages by allowing immediate session identification.</t>
      <t>The flag bits provide useful indications to the routing system, if set:
      </t>
      <ul spacing="normal">
        <li>Mobile - set if the user system is mobile</li>
        <li>
          <t>Flow size (3 bits)
          </t>
          <ul spacing="normal">
            <li>000 means a single packet, no flow/congestion state needed</li>
            <li>other values TBD indicate type of flow/congestion state</li>
          </ul>
        </li>
        <li>Authenticated - set if packet authenticated (details TBD)</li>
        <li>Encrypted - set if encryption applied (details TBD)</li>
      </ul>
      <t>Note that fragmentation is not supported. Fragmentation, and
    the related mechanisms of MTU discovery, are a significant operational
    problem in the current Internet <xref target="I-D.ietf-intarea-frag-fragile" format="default"/>.
    We simply abolish this problem area
    in SOIP, which is designed for use in managed networks where a single size of
    maximum transmission unit (MTU) is available everywhere. An SOIP
    network will have a globally defined MTU. Of course, IPv4 and IPv6
    reachability services via the open Internet will have to support
    PMTUD and fragmentation as best they can, but this concerns the
    embedded IP packets, not the SOIP packets, and will be invisible locally.</t>
      <t><xref target="encoding" format="default"/> outlines possible TLV and CBOR encodings
    of the SOIP protocol.</t>
    </section>
    <section anchor="coex" numbered="true" toc="default">
      <name>Coexistence Issues</name>
      <t>SOIP is expected to coexist with IPv6; in a sense it is a low-level
    method of orchestrating IPv6 connections. We assume that each SOIP client host
    has at least one IPv6 address, and that SOIP routers will announce themselves
    using a suitable IPv6 Router Advertisement extension 
    <xref target="I-D.troan-6man-universal-ra-option" format="default"/>. Normally, the first-hop
    SOIP router will be the same as the IPv6 first-hop router.</t>
      <t>As a result of this, all standard management mechanisms such as NETCONF
    may be used without further specification. Also, when a data connection of any
    kind is established after a SOIP request/response exchange, all standard transport mechanisms
    are available over IPv6. As noted above, they are subject to the locally defined MTU
    as long as they remain within the SOIP domain.</t>
      <t>We do not define how SOIP would operate in an IPv4-only network.</t>
    </section>
    <section anchor="usage" numbered="true" toc="default">
      <name>Some Usage Examples</name>
      <ul spacing="normal">
        <li>
          <t>Storage request (upload content):
          </t>
          <ul spacing="normal">
            <li>Service data identifies storage requirement (temporary/permanent,  private/public, encryption, etc.)</li>
            <li>Payload identifies data (path/name.format, etc.)</li>
          </ul>
        </li>
        <li>
          <t>Storage request (download content):
          </t>
          <ul spacing="normal">
            <li>Service data identifies transmission requirement (streamed, block, etc. 
        and the specific transport protocol - UDP, TCP, QUIC, etc. - if needed)</li>
            <li>Payload identifies data (path/name.format, etc.)</li>
          </ul>
        </li>
        <li>
          <t>Computation request
          </t>
          <ul spacing="normal">
            <li>Service data identifies computing requirement</li>
            <li>Payload identifies computing application</li>
          </ul>
        </li>
        <li>
          <t>Reachability request
          </t>
          <ul spacing="normal">
            <li>Service data gives destination IP address (or DNS name)</li>
            <li>Indication of transport protocol required (details TBD)</li>
            <li>Indication of options or extension headers required (details TBD)</li>
          </ul>
        </li>
      </ul>
    </section>
    <section anchor="continuity" numbered="true" toc="default">
      <name>Continuity with the Existing Internet</name>
      <t>Continuity is provided in two ways:
      </t>
      <ol spacing="normal" type="1">
        <li>A user node can simply use IP completely in parallel with SOIP.
    The network stack in the user node will simply encode the IP packets
    as SOIP packets with the SAT for IP reachability, and a SOIP dispatcher
    will send and receive IP packets at the SOIP domain boundary.</li>
        <li>If a service in the SOIP domain needs service from elsewhere
    in the IP Internet to respond to a user request, it will use a
    similar dispatcher function to do so.This could also be described as a proxy 
    mechanism. (Of course, services in interconnected SOIP domains
    may talk to each other directly.)</li>
      </ol>
    </section>
    <section anchor="interf" numbered="true" toc="default">
      <name>Interface with Service and Application Domains</name>
      <t>Various techniques are emerging for service or application specific networking
    within operators' networks. An overview of the motivations is given in
    <xref target="I-D.li-apn6-problem-statement-usecases" format="default"/>, and specific
    techniques have been defined such as Network Service Headers <xref target="RFC8300" format="default"/>
    and Segment Routing <xref target="RFC8402" format="default"/>, as well as Software-Defined Networking in general
    <xref target="RFC7426" format="default"/>. A SOIP dispatcher that is aware of such techniques may
    convert SOIP traffic into one of these mechanisms, for example by encapsulation
    or proxying. Furthermore, the model is future-proof. The dispatcher could be
    upgraded to support unknown future service or application oriented
    networking mechanisms, without requiring changes to SOIP clients
    or routers.</t>
    </section>
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>It is intended that both authentication and encryption
      should be available for all SOIP packets. However, this requires
      further work, especially to determine whether existing mechanisms
      for key management can be used.</t>
      <t>Since clients are identified by an IPv6 address, existing layer 3
      privacy considerations for IPv6 addresses will apply to SOIP <xref target="RFC7721" format="default"/>.
      Upper layer privacy considerations will depend on the service concerned.</t>
    </section>
    <section anchor="iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document makes no request of the IANA.</t>
      <t/>
    </section>
    <!-- <section anchor="contr" title="Contributors">
      <t>X made important contributions to this document.
      </t>
    </section> -->

    <!-- <section anchor="ack" title="Acknowledgements">
      <t>Useful comments were received from
      
      </t>
    </section> -->
  </middle>
  <back>
    <!-- <references title="Normative References">

    </references> -->

    <!-- <references title="Informative References"> -->
    <references>
      <name>References</name>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7049.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8585.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7426.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7721.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6146.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6437.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-intarea-frag-fragile.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.carpenter-limited-domains.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.troan-6man-universal-ra-option.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.li-apn6-problem-statement-usecases.xml"/>
    </references>
    <section anchor="encoding" numbered="true" toc="default">
      <name>Possible TLV and CBOR Encodings</name>
      <section numbered="true" toc="default">
        <name>TLV Mapping</name>
        <t><xref target="TLV-fig" format="default"/> shows a possible type-length-value packet format.</t>
        <figure anchor="TLV-fig">
          <artwork name="" type="" align="left" alt=""><![CDATA[
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|R R R R|      SAT      |M F F F A E R R| Traffic Class |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Session Identifier  (32 bits)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Hop Limit   |                                               |
   +-+-+-+-+-+-+-+-+                                               +
   |                                                               |
   +                                                               +
   |              Client Locator / Identifier  (128 bits)          |
   +                                                               +
   |                                                               |
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               | SD length     |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +              Service Data (variable length)                   +
   ...                                                           ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Payload Length         |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|                               +
   |                                                               |
   +              Payload Data (variable length)                   +
   ...                                                           ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ]]></artwork>
        </figure>
        <t>Version - IP version number TBD (not needed over UDP)</t>
        <t>R - Reserved, must be zero (not needed over UDP)</t>
        <t>SAT - Service Action Type code</t>
        <t>M - Mobile flag</t>
        <t>FFF - Flow type flags
(FFF = 000 for single-packet flows; other values for longer flows)</t>
        <t>A - Authentication flag</t>
        <t>E - Privacy (encryption) flag</t>
        <t>Traffic class, exactly as for IPv6</t>
        <t>Session identifier, 32-bit pseudo random number</t>
        <t>Client Locator / Identifier - globally unique IPv6 address</t>
      </section>
      <section numbered="true" toc="default">
        <name>CBOR Mapping</name>
        <t>The packet consists of a CBOR byte string preceded by a single byte (<xref target="byte-fig" format="default"/>).
  For example, for version 7, this byte would be 0x70. This byte is not decoded as CBOR, and is not needed over UDP.</t>
        <figure anchor="byte-fig">
          <artwork name="" type="" align="left" alt=""><![CDATA[
   +-+-+-+-+-+-+-+-+
   |Version|R R R R|
   +-+-+-+-+-+-+-+-+
  ]]></artwork>
        </figure>
        <t> The CBOR bytes then obey the
CDDL <xref target="RFC8610" format="default"/> specification in <xref target="cddl-fig" format="default"/>.</t>
        <figure anchor="cddl-fig">
          <artwork name="" type="" align="left" alt=""><![CDATA[
sat-packet = [sat, flags, traffic-class, session-id, hop-limit,
              source, service-data, ?payload]   

sat = 0..255
flags = bytes .size 1
traffic-class = 0..255
session-id = 0..4294967295 ;up to 32 bits
hop-limit = 0..255
client = ipv6-address
service-data = any
payload = any

ipv6-address = bytes .size 16
]]></artwork>
        </figure>
        <t>The syntax of the various service-data formats can be defined in
separate documents for each SAT value.</t>
        <t>We assume that routers capable of handling a CBOR-based layer 3
protocol will exist, and will use some form of programmable
network processor rather than traditional ASIC or FPGA designs.
This allows great flexibility and software-friendly extensibility,
especially of the service data formats. Further investigation is
needed whether this is realistic.</t>
      </section>
    </section>
    
    <section anchor="changes" numbered="true" toc="default">
      <name>Change log [RFC Editor: Please remove]</name>
      <ul>
      <li><t>draft-jiang-service-oriented-ip-00, 2019-05-07:</t>
       <ul><li>Initial version</li></ul></li>
       
      <li><t>draft-jiang-service-oriented-ip-01, 2019-06-21:</t>
       <ul><li>Editorial corrections</li></ul></li>
       
      <li><t>draft-jiang-service-oriented-ip-02, 2019-10-29:</t>
       <ul><li>Added overview diagram</li>
       <li>Added discussion of dispatcher function</li>
       <li>Clarifications and editorial corrections</li></ul></li>
       
      <li><t>draft-jiang-service-oriented-ip-03, 2020-05-15:</t>
       <ul><li>Editorial corrections</li>
       <li>Converted to xml2rfc v3</li></ul></li>
       
      </ul>
      
    </section>
  </back>
</rfc>
