Re: [mif-arch-dt] sections 4.3 and 4.4

[<[e-mail]>]

Hi,

Below is a revision for section 4.3 to address Ted's concern. Feel free to comment.

Br,
Pierrick and Juan-carlos

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 situation.  In current implementations, some nodes perform connectivity tests to address this issue, for instance by trying to reach a dedicated web server (e.g. connection managers may be able to address this problem [RFC 6419]). If the node can simultaneously use both the current and new PVDs, it can perform connectivity test and, only after validation of the new PVD, update its forwarding state. Connectivity tests are also required once the node is attached to a new valid PVD. Indeed, during the IP session, the end-to-end IP connectivity could be disrupted for various reasons (e.g. poor L2, IP QoS issue); hence an IP monitoring function is needed to check current IP connectivity and trigger PVD reselection if necessary.
 
Nevertheless, a connectivity test for PVD selection is sometimes not appropriate and should be complemented, or even replaced, by an educated PVD selection. For example, some nodes, especially mobile handsets, cannot use more than one PVD at the same time (even if multiple-PVD attachment is possible). In this case, the connectivity test is done after performing a routing update to the new PVD, and may lead to service interruption if the selected PVD turns out to provide limited IP connectivity. Here comes into play the educated PVD selection, where the idea is to make the node aware of the characteristics of the PVD, prior to attaching to the new PVD. This would avoid selecting a PVD with inappropriate features (e.g. authentication, low quality, etc.). The educated PVD selection could be realized leveraging some 3GPP and IEEE mechanisms, which would allow to expose some PVD characteristics to the node (e.g. 3GPP Access Network Discovery and Selection Function (ANDSF) [REF ANDSF], IEEE 802.11u/ANQP [REF 802.11u]). 


-----Message d'origine-----
De : Ted Lemon [mailto:[e-mail]] 
Envoyé : lundi 9 septembre 2013 15:41
À : SEITE Pierrick IMT/OLN
Cc : Zuniga, Juan Carlos; [e-mail]
Objet : Re: [mif-arch-dt] sections 4.3 and 4.4

On Sep 9, 2013, at 4:35 AM, [e-mail] wrote:
> Apparently, current text is not clear enough :-), we will revise it accordingly.

Thanks!   :)


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.