<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="info" docName="draft-atarashi-netappmodel-02" ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title>The Model for Net and App Interaction</title>

    <author fullname="Ray S. Aatarashi" initials="R.A." surname="Atarashi">
      <organization>Internet Initiative Japan Inc.</organization>

      <address>
        <postal>
          <street>Jinbocho-Mitsui Buld., 1-105 Kanda Jinbo-cho,</street>

          <city>Chiyoda-ku</city>

          <region>Tokyo</region>

          <code>101-0051</code>

          <country>Japan</country>
        </postal>

        <phone>+81 3 5205 6464</phone>

        <email>ray@iijlab.net</email>
      </address>
    </author>

    <author fullname="Megumi Ninomiya" initials="M.N." surname="Ninomiya">
      <organization>Internet Initiative Japan Inc.</organization>

      <address>
        <postal>
          <street>Jinbocho-Mitsui Buld., 1-105 Kanda Jinbo-cho,</street>

          <city>Chiyoda-ku</city>

          <region>Tokyo</region>

          <code>101-0051</code>

          <country>Japan</country>
        </postal>

        <phone>+81 3 5205 6464</phone>

        <email>ninomiya@iij.ad.jp</email>
      </address>
    </author>

    <date></date>

    <abstract>
      <t>This document describes the model for application and network
      interaction in reaction to Application Area Architecture Workshop held
      on February 11 and 12, 2008. There is not completed mechanism for
      collaboration between application and network yet even though a solution
      is required. The model proposed in this document is designed without a
      layer violation.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document describes the model for application and network
      interaction in reaction to Application Area Architecture Workshop held
      on February 11 and 12, 2008. There is not completed mechanism for
      collaboration between application and network yet even though a solution
      is required. The model proposed in this document is designed without a
      layer violation.</t>

      <section title="Motivation">
        <t>From the application point of view, application users want to use
        network resources (ex. bandwidth, response time) and new network
        functions (ex. QoS, VLAN) flexibly. Applications and services have
        requirements for network behavior depending on the functions provided
        by the application. For example, a streaming service requires high
        bandwidth and low delay network, database transactions need no
        packet-loss network but don't need high bandwidth. <vspace />From the
        network point of view, it is useful for operation to know the
        application behavior. If they can know the requirement from
        application, it may be possible to prepare the responded environment.
        It was impossible to change the configurations on demand, but NETCONF
        can be change the configuration flexibly. <vspace />Now, it is ready
        to design the application common architecture, because the components
        are all together.</t>
      </section>

      <section title="Problems">
        <t>One of the reasons that the collaboration is difficult is that we
        don't share a common architecture and terminology. There is a gap
        between application requirements and network functions. Application
        requirements and behavior are defined by service level, but network
        functions are implemented by routing and low level configurations.
        When we have a requirement for network behavior, we have to configure
        routers using CLI (Command Line Interface). It is hard because we have
        to master router configuration. And it is impossible that
        configuration changes automatically and frequently. <vspace />We need
        an interface to collaborate between the applications and the network.
        IMO, the interface is defined not API-like function, but also
        model-like description. For example, <list>
            <t>- Application service model</t>

            <t>- Network function model</t>
          </list>These kinds of models may be higher level concept than API.
        As a application user for the NETCONF, the guideline is need to use
        and combine the application technologies and protocols.</t>
      </section>

      <section title="Requirements notation">
        <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>
      </section>
    </section>

    <section title="Adding Building Block">
      <t>At the Application Area Architecture Workshop, we agreed to add the
      application *semantic* layer which is really what users are interested
      in, and this is different even from the application *protocol* layer.
      For example, "jabber" is in the Semantic Layer, "xmpp" is in the
      Protocol Layer.</t>

      <t><vspace /></t>

      <figure>
        <artwork><![CDATA[     Layer              examples

+-----------------+    +----------+
| Semantic Layer  |    | jabber   |
+-----------------+    +----------+
| Protocol Layer  |    |  xmpp    |
+-----------------+    +----------+
| Transport Layer |    | TCP/SCTP |
+-----------------+    +----------+
| Internet Layer  |    | IP/IPv6  |
+-----------------+    +----------+
| Datalink Layer  |    | VLAN     |
+-----------------+    +----------+
| Physical Layer  |    | Ethernet |
+-----------------+    +----------+]]></artwork>
      </figure>
    </section>

    <section title="Network and Application Interaction">
      <t>In order to implement to interact with application and network,
      *Management function* is needed outside the layer. Each layer is managed
      by the management function. The requirements from the Semantic Layer are
      conveyed to the management function to implement in the other layer. For
      example, a "closed network" is requested from the application, an VLAN
      is implemented in the Datalink Layer.</t>

      <t><vspace /></t>

      <figure>
        <artwork><![CDATA[+-----------------+    +------------+
| Semantic Layer  |<-->|            |
+-----------------+    |            |
| Protocol Layer  |<-->|            |
+-----------------+    |            |
| Transport Layer |<-->|            |
+-----------------+    | management |
| Internet Layer  |<-->|            |
+-----------------+    |            |
| Datalink Layer  |<-->|            |
+-----------------+    |            |
| Physical Layer  |<-->|            |
+-----------------+    +------------+]]></artwork>
      </figure>

      <t><vspace /></t>

      <t>Management function consists of Management Block and APIs to
      collaborate with each layer and application, network devices. Management
      block is application or management scenario suite. Applications make
      requirement to Management Block through the API, Network devices are
      configured by Management Block through the API.</t>

      <t><vspace /></t>

      <figure>
        <artwork><![CDATA[+-----------------+    +---+-------------+---+
| Semantic Layer  |<-->|   |             |   |
+-----------------+    |   |             |   |requirements
| Protocol Layer  |<-->|   |             |   |<-----> Applications
+-----------------+    |   |             |   |
| Transport Layer |<-->| A |             | A |
+-----------------+    | P |  Management | P |configuration
| Internet Layer  |<-->| I |   Block     | I |<-----> Network Devices
+-----------------+    |   |             |   |
| Datalink Layer  |<-->|   |             |   |
+-----------------+    |   |             |   |
| Physical Layer  |<-->|   |             |   |
+-----------------+    +---+-------------+---+]]></artwork>
      </figure>

      <t><vspace />The Management block consists of scenarios that is a
      sequence of procedure in order to implement the requirements. The
      implementation depend on the scenario rely on the network and system
      environments.</t>

      <t>It is important to define "data model" for primitive network
      functions in corresponding to requirements. These requirements are
      composed based on the function data model. The network devices are
      configured when scenario involved the network devices and resources.</t>
    </section>

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

  <back>
    <references title="Normative References">
      &rfc2119;
    </references>
  </back>
</rfc>