< draft-anipko-mif-mpvd-arch-03.txt   draft-anipko-mif-mpvd-arch-04.txt >
MIF Working Group D. Anipko MIF Working Group D. Anipko
Internet-Draft Microsoft Corporation Internet-Draft Microsoft Corporation
Intended status: Informational September 22, 2013 Intended status: Informational October 18, 2013
Expires: March 24, 2014 Expires: April 19, 2014
Multiple Provisioning Domain Architecture Multiple Provisioning Domain Architecture
draft-anipko-mif-mpvd-arch-03 draft-anipko-mif-mpvd-arch-04
Abstract Abstract
This document is a product of the work of MIF architecture design This document is a product of the work of MIF architecture design
team. It outlines a solution framework for some of the issues, team. It outlines a solution framework for some of the issues,
experienced by nodes that can be attached to multiple networks. The experienced by nodes that can be attached to multiple networks. The
framework defines the notion of a Provisioning Domain (PVD) - a framework defines the notion of a Provisioning Domain (PVD) - a
consistent set of network configuration information, and PVD-aware consistent set of network configuration information, and PVD-aware
nodes - nodes which learn PVDs from the attached network(s) and/or nodes - nodes which learn PVDs from the attached network(s) and/or
other sources and manage and use multiple PVDs for connectivity other sources and manage and use multiple PVDs for connectivity
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 24, 2014. This Internet-Draft will expire on April 19, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/ Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 26 skipping to change at page 2, line 26
2.5. Relationship to dual-stack networks . . . . . . . . . . . 6 2.5. Relationship to dual-stack networks . . . . . . . . . . . 6
2.6. Elements of PVD . . . . . . . . . . . . . . . . . . . . . 7 2.6. Elements of PVD . . . . . . . . . . . . . . . . . . . . . 7
3. Example network configurations and number of PVDs . . . . . . 7 3. Example network configurations and number of PVDs . . . . . . 7
4. Reference model of PVD-aware node . . . . . . . . . . . . . . 7 4. Reference model of PVD-aware node . . . . . . . . . . . . . . 7
4.1. Constructions and maintenance of separate PVDs . . . . . . 7 4.1. Constructions and maintenance of separate PVDs . . . . . . 7
4.2. Consistent use of PVDs for network connections . . . . . . 7 4.2. Consistent use of PVDs for network connections . . . . . . 7
4.2.1. Name resolution . . . . . . . . . . . . . . . . . . . 7 4.2.1. Name resolution . . . . . . . . . . . . . . . . . . . 7
4.2.2. Next-hop and source address selection . . . . . . . . 8 4.2.2. Next-hop and source address selection . . . . . . . . 8
4.3. Connectivity tests . . . . . . . . . . . . . . . . . . . . 9 4.3. Connectivity tests . . . . . . . . . . . . . . . . . . . . 9
4.4. Relationship to interface management and connection manager 9 4.4. Relationship to interface management and connection manager 9
5. PVD support in APIs . . . . . . . . . . . . . . . . . . . . . 9 5. PVD support in APIs . . . . . . . . . . . . . . . . . . . . . 10
5.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. PVD-aware nodes trust to PVDs . . . . . . . . . . . . . . . . 10 6. PVD-aware nodes trust to PVDs . . . . . . . . . . . . . . . . 11
6.1. Untrusted PVDs . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Untrusted PVDs . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Trusted PVDs . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Trusted PVDs . . . . . . . . . . . . . . . . . . . . . . . 11
6.2.1. Authenticated PVDs . . . . . . . . . . . . . . . . . . 11 6.2.1. Authenticated PVDs . . . . . . . . . . . . . . . . . . 11
6.2.2. PVDs trusted by attachment . . . . . . . . . . . . . . 11 6.2.2. PVDs trusted by attachment . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
skipping to change at page 9, line 48 skipping to change at page 10, line 4
There may be cases where a connectivity test for PVD selection may be There may be cases where a connectivity test for PVD selection may be
not appropriate and should be complemented, or replaced, by PVD not appropriate and should be complemented, or replaced, by PVD
selection based on other factors. This could be realized e.g., by selection based on other factors. This could be realized e.g., by
leveraging some 3GPP and IEEE mechanisms, which would allow to expose leveraging some 3GPP and IEEE mechanisms, which would allow to expose
some PVD characteristics to the node (e.g. 3GPP Access Network some PVD characteristics to the node (e.g. 3GPP Access Network
Discovery and Selection Function (ANDSF) [REF ANDSF], IEEE 802.11u/ Discovery and Selection Function (ANDSF) [REF ANDSF], IEEE 802.11u/
ANQP [REF 802.11u]). ANQP [REF 802.11u]).
4.4. Relationship to interface management and connection managers 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 in
environments with multiple interfaces and multiple sets of network
configurations. These mechanisms or applications are commonly known
as connection managers [RFC6419].
Connection managers sometimes rely on policy servers to allow the
node, connected to multiple networks, perform the network 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 rarely address the network selection
problems in a comprehensive manner. With proprietary solutions, it
is 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.
5. PVD support in APIs 5. PVD support in APIs
In all cases changes in available PVDs must be somehow exposed, In all cases changes in available PVDs must be somehow exposed,
appropriately for each of the approaches. appropriately for each of the approaches.
5.1. Basic 5.1. Basic
Applications are not PVD-aware in any manner, and only submit Applications are not PVD-aware in any manner, and only submit
connection requests. The node performs PVD selection implicitly, connection requests. The node performs PVD selection implicitly,
without any otherwise applications participation, and based purely on without any otherwise applications participation, and based purely on
node-specific administrative policies and/or choices made by the user node-specific administrative policies and/or choices made by the user
in a user interface provided by the operating environment, not by the in a user interface provided by the operating environment, not by the
application. application.
As an example, such PVD selection can be done at the name service As an example, such PVD selection can be done at the name service
lookup step, by using the relevant configuration elements, such as lookup step, by using the relevant configuration elements, such as
e.g., those described in [RFC6731]. As another example, the PVD e.g., those described in [RFC6731]. As another example, the PVD
 End of changes. 8 change blocks. 
9 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/