| MIF | L. Geng |
| Internet-Draft | H. Deng |
| Intended status: Standards Track | China Mobile |
| Expires: April 18, 2016 | October 16, 2015 |
Use Cases for Multiple Provisioning Domain in Homenet
draft-geng-mif-homenet-mpvd-use-cases-00
This document describes the use cases of multiple provisioning domain (MPVD) in homenet. Although most residential networks nowadays are connected to a single ISP and normally subscribed to standard internet service, it is expected that much wider range of devices and services will become common in home networks. Homenet defines such home network topologies with increasing number of devices with the assumption that it requires minimum configuration by residential user. As described in the homenet architecture ([RFC7368]), multihoming and multi-service residential network will be more common in the near future. Nodes in such network may commonly have multiple interfaces or subscribe to multiple services. Potential types of PVD-aware nodes concerning interface and service specific provisioning domains are introduced in this document. Based on this, different MPVD configuration examples are given. These examples illustrate how PVD may be implemented in home network. PVDs provide independent provisioning domains for different interfaces and services, which enables robust and flexible network configuration for these networks.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2016.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
It is believed that future residential network will more commonly be multihomed, which potentially provides either resilience or more flexible services. At the same time, more internal routing and multiple subnets are expected to commonly exist in such networks. For example, customer may want independent subnets for private and guest usages. Homenet describes such future home network involving multiple routers and subnets ([RFC7368]).
Multihoming and the increasing number of subnets bring challenges on provisioning of the network. As stated in [RFC6418], such multihomed scenarios with nodes attached to multiple upstream networks may experience configuration conflicts, leading to a number of problems. To deal with these problem, draft-ietf-mif-mpvd-arch-10 provides a framework which introduces Provisioning Domain (PvD), which associates a certain interface and its related network configuration information. Hence, corresponding network configuration can be used when packets are delivered through a particular interface.
This document focuses on the MPvD use cases in residential network, particularly the IPV6-based homenet. Based on the homenet topology, use cases of MPvD in homenet are described for both singlehomed and multihomed network configurations.
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 RFC 2119 [RFC2119].
The terminology and abbreviations used in this document are defined in this section.
In the most common multihoming scenarios, the home network has multiple physical connections to the ISP networks. Section 3.2.2.2 and 3.2.2.3 in [RFC7368] give the topology examples of such homenet. In the examples, homenet hosts are connected to a single or multiple customer edge routers (CE router), the CE routers are then connected to separate ISP networks. For the particular topology with a single CE router given in Section 3.2.2.3 in [RFC7368], the CE router is a mif node since it has two interfaces connected to individual service provider routers. Given that the CE router is a PvD-aware node, it may have two PvDs provided by ISPs respectively.
Apart from the multihoming resulted from physical connections , PvDs in Homenet can also be used for service provisioning. For example, a host may subscribe one ISP for internet service, whilst subscribe to another ISP for Internet of Things (IoT) service given that the CE router have access to both ISPs. On the other hand, the host user may also subscribe to the same ISP for both services. In either case, PvDs can be used for customized network configurations purposes. This enables the service providers to provide independent and flexible provisioning for different services. Meanwhile, IoT service providers may also want to use independent PvDs to avoid the configuration conflicts between each other as stated in RFC6418.
A typical example of a PvD in home network is the one associating corresponding network configuration with an HNCP routers. These includes both CE router and interior router in Homenet. As described in ([RFC7368]), an CE router in homenet may have one or more external interfaces with ISPs and internal interfaces with interior routers. For external interfaces, the CE router can receive associated PvD information from corresponding ISPs. For interior interfaces, the interior router can receive PvD information from connected CE router or other interior routers.
Hosts in homenet are expected to be multihomed as well. Hence, PvD may also be used in such cases to associate different network configurations. In this case, the PvD information is received from the HNCP router a host is attached to, either a CE router or a interior router.
This section gives some examples of MPvD configurations in home network.
<----"Internet" PvD----------->
_____
+-------+ ( )
+--------+ | | ( ISP ) +------+
| PC +------+ +--------------------+ WWW |
+--------+ | HNCP | ( ) +------+
| CE | ( )
+--------+ |Router | ( ) +------+
| SETBOX +------+ +--------------------+ VOD |
+--------+ | | ( ) +------+
| | ( )
| <----"VOD" PvD--------------->
| | ( )
<------------------"VPN" PvD ------------------------->
+--------+ | | ( )
| +----+ | +--------+ | | ( ) +------+
| |VPN +---+ | | +--------------------+ VPN |
| +----+ | |Interior| | | ( ) +------+
| Host 3 | | HNCP +------+ | ( )
| +----+ | | Router | | | ( __) +------+
| |IoT +---+ | | +--------------------+ IoT |
| +----+ | +--------+ +-------+ (__ ) +------+
+--------+
<------------------"IoT" PvD-------------------------->
Figure 1
In this example, A homenet is connected with a single ISP as seen in Figure 1. Four different services are provided to this home network including Internet, VOD, VPN and IoT. There are 3 Hosts in this set-up. PC and setbox use "Internet" and "VoD" PvDs respectively and Host 3 uses both "VPN" and "IoT" PvD.
The four PVDs could be either implicit or explicit PvDs. Explicit PvDs should be initially assigned to HNCP CE router by ISP. And then forwarded to interior routers and host. Given that all PvDs are explicit in the case above, the "Internet" PvD is forwarded to PC and "VOD" PvD to SETBOX by the CE router, and the "VPN" and "IoT" PvDs are forwarded to interior HNCP router and then Host 3. The PvD_ID should be kept the same when the PvDs are forwarded. However, other associated network configuration (i.e. delegated prefixes) should be changed accordingly.
To be added
To be added
As defined in MIF, "PvD-aware node is a a node that supports the association of network configuration information into PvDs and the use of these PvDs to serve requests for network connections". In Homenet, the HNCP CE router, interior router and host are all PvD-aware nodes.
The HNCP CE router PvD-related functionality is define as follows:
The interior router PvD-related functionality is defined as follows:
The host PvD-related functionality is defined as follows:
PvD in homenet can be either single-family or dual-stack. For single-family PvD, the IPV4 and IPV6 configurations should be managed in separate PvDs with different PvD identities. For Dual-stack PvDs, IPV4 and IPV6 configurations can exist in the same PvD. In both cases, there can either be only one IPV4 PvD for each interface or multiple IPV4 PvDs with different default gateway addresses.
At the time this document was written, the conveying of PvD information was still under discussion in mif working group. Popular choices include DNS, DHCP and Route Advertisement. For PvD information provided from ISP to CE router and router to host, the approaches for PvD information delivery defined by mif may be directly used. For PvD information delivery within homenet between HNCP-enabled routers, HNCP-based approach need to be defined. The detail of how homenet could support the delivery of PvD information between routers is subjected to further discussions and will be addressed in a separate document.
The author would like to thank Ted Lemon, Mark Townsley, Markus Stenberg and Steven Barth for valuable discussions and contributions to this document.
This memo includes no request to IANA.
TBA
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC2629] | Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, DOI 10.17487/RFC2629, June 1999. |
| [RFC6418] | Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, DOI 10.17487/RFC6418, November 2011. |
| [RFC7368] | Chown, T., Arkko, J., Brandt, A., Troan, O. and J. Weil, "IPv6 Home Networking Architecture Principles", RFC 7368, DOI 10.17487/RFC7368, October 2014. |