[mif-arch-dt] sections 4.3 and 4.4

"Zuniga, Juan Carlos" <JuanCarlos.Zuniga@InterDigital.com> Fri, 06 September 2013 11:10 UTC

Return-Path: <JuanCarlos.Zuniga@InterDigital.com>
X-Original-To: mif-arch-dt@ietfa.amsl.com
Delivered-To: mif-arch-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E85811E8282 for <mif-arch-dt@ietfa.amsl.com>; Fri, 6 Sep 2013 04:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.598
X-Spam-Level:
X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WT-+kZDU6osP for <mif-arch-dt@ietfa.amsl.com>; Fri, 6 Sep 2013 04:10:32 -0700 (PDT)
Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9872011E80E6 for <mif-arch-dt@ietf.org>; Fri, 6 Sep 2013 04:10:32 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Sep 2013 07:10:31 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CEAAF1.B38B692E"
Date: Fri, 06 Sep 2013 07:10:30 -0400
Message-ID: <D60519DB022FFA48974A25955FFEC08C054A3B51@SAM.InterDigital.com>
In-Reply-To: <COL125-W16BB859A16CE25C980383AB1340@phx.gbl>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [mif-arch-dt] sections 4.3 and 4.4
Thread-Index: Ac6kinvcJ6sWQAGbQ7qFjnsMydg1KAGYwBQg
References: <Prayer.1.3.5.1308010729000.16712@hermes-2.csi.cam.ac.uk> <COL125-W16BB859A16CE25C980383AB1340@phx.gbl>
From: "Zuniga, Juan Carlos" <JuanCarlos.Zuniga@InterDigital.com>
To: mif-arch-dt@ietf.org
X-OriginalArrivalTime: 06 Sep 2013 11:10:31.0877 (UTC) FILETIME=[B3AF3F50:01CEAAF1]
Cc: pierrick.seite@orange.com
Subject: [mif-arch-dt] sections 4.3 and 4.4
X-BeenThere: mif-arch-dt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: MIF Architecture Design Team mailing list <mif-arch-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif-arch-dt>, <mailto:mif-arch-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif-arch-dt>
List-Post: <mailto:mif-arch-dt@ietf.org>
List-Help: <mailto:mif-arch-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif-arch-dt>, <mailto:mif-arch-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Sep 2013 11:10:38 -0000

Hi all,

 

As mentioned before, Pierrick and I would like to suggest some text for
sections 4.3 and 4.4.

 

Comments are welcome.

 

Best regards,

 

Juan Carlos & Pierrick

 

4.3.  Connectivity tests

 

Although some provisioning domains appear to be valid candidates for PVD
selection (e.g. good L2 quality, consistent connection parameters,
etc.), they may provide limited or no connectivity to the desired
network or the Internet. For example, some PVDs provide L3 connectivity
but require the node to authenticate through a web portal to get full
access to the Internet. If the PVD-aware node knows the PVD, it can
perform authentication operations; otherwise, the node may stay with a
limited network connectivity without full knowledge about this.  Hence,
once the node is attached to a PVD, it should check IP connectivity and
trigger PVD reselection if need be. Also, once the node is attached to a
new valid PVD, the end-to-end IP connectivity could be disrupted. A
mechanism is thus needed to check current connectivity and trigger PVD
reselection if necessary.

 

Usually, the node can perform these tests by trying to reach a dedicated
web server (e.g. connection managers may be able to address this problem
[RFC 6419]). A better solution would be to make the node aware of the
characteristics of the PVD in order to make the appropriate selection.
This could be realized leveraging some 3GPP and IEEE mechanisms, which
allow to expose some of PVD characteristics to the node (e.g. 3GPP
Access Network Discovery and Selection Function (ANDSF) [REF ANDSF],
IEEE 802.11u/ANQP [REF 802.11u]). 

 

 

 

4.4.Relationship to interface management and connection managers

 

Current devices such as mobile handsets make use of proprietary
mechanisms and custom applications to manage connectivity with multiple
interfaces and multiple PVDs. These mechanisms or applications are
commonly known as connection managers [RFC 6419]. 

 

Connection managers sometimes rely on policy servers to allow the
PVD-aware node making the PVD selection. They can also make use of
routing guidance from the network (e.g. 3GPP ANDSF [REF ANDSF]).
Although connection managers solve some connectivity problems, they
seldom address the PVD selection in a comprehensive manner. Moreover,
even with proprietary solutions, it is very challenging to present a
coherent behaviour to the end user of the device, as different platforms
present different behaviours even when connected to the same network,
with the same type of interface, and for the same purpose. 

 

 

 

From: mif-arch-dt-bounces@ietf.org [mailto:mif-arch-dt-bounces@ietf.org]
On Behalf Of Hui Deng
Sent: Thursday, August 29, 2013 3:36 AM
To: mif-arch-dt@ietf.org
Subject: [mif-arch-dt] Restart the teleconf

 

Hello all,
 
We plan to restart our regular biweek teleconf from the September 9th
(Monday) same time
will send out teleconf invitation next week (one week before the
teleconf)
 
Thanks a lot for your attendance.
Best regards,
 
-Hui