PP1: To smart collaboration between the applications and the network

Lisa Dusseault <lisa@osafoundation.org> Mon, 07 January 2008 22:21 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC0LU-0000M3-Io; Mon, 07 Jan 2008 17:21:24 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JC0LT-0000LV-GN for discuss-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 17:21:23 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC0LT-0000LM-6a for discuss@apps.ietf.org; Mon, 07 Jan 2008 17:21:23 -0500
Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC0LR-0001wS-48 for discuss@apps.ietf.org; Mon, 07 Jan 2008 17:21:23 -0500
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DF01714229B for <discuss@apps.ietf.org>; Mon, 7 Jan 2008 14:21:22 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmR5U+VO4li9 for <discuss@apps.ietf.org>; Mon, 7 Jan 2008 14:21:18 -0800 (PST)
Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 42BE0142207 for <discuss@apps.ietf.org>; Mon, 7 Jan 2008 14:21:18 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v752.3)
To: Apps Discuss <discuss@apps.ietf.org>
Message-Id: <A8E5235A-5611-4E05-B09F-0A7E2D2E0569@osafoundation.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-2-246458101
From: Lisa Dusseault <lisa@osafoundation.org>
Subject: PP1: To smart collaboration between the applications and the network
Date: Mon, 7 Jan 2008 14:21:13 -0800
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

This is the first in the position papers for February's workshop I'm  
forwarding from attendees.  I'll be posting them with PP# for easy  
search and threading. -- L
---
PP1

To smart collaboration between the applications and the network

Ray Atarashi (IIJ)

1. Motivation

I have proposed the importance of collaboration between applications  
and the network. From the application point of view, we 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.

 From the network point of view, it is useful for operation software  
to know the application behavior. If they can know the requirements  
of the application, it may be possible to prepare the responded  
environment. I expect that NETCONF can be an interface to achieve the  
collaboration. That's because I'm working at NETCONF WG.

When we develop an application common architecture, we should think  
about both the application and the network. It may be useful to  
organize how each function should be defined and implemented at which  
layer.

On the other hand, though NETCONF is defined based on XML, they don't  
take advantage of the XML-related technologies. We need advice from  
APP Area to use application technologies, such as SOAP, SASL, ACL,  
version control, etc.

2. Problems

One of the reasons that 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.

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,
- Application service model
- Network function model
These kinds of models may be higher level concept than API.
  As a application user for the NETCONF, we need a guideline to use  
and combine the application technologies and protocols. The  
requirement examples that we select the application technologies are;
- easy to implement, related tools are provided,
- easy to maintenance,
- enough security functions,
- easy to extend,
- etc..

3. Proposal

  To discuss the common architecture, we need to clarify the related  
technologies, protocol, and so on. To discuss collaboration, we can  
start to talk about use cases to use network resources from an  
application. It can be helpful to clarify where the interfaces are  
needed.