wdiff draft-geng-homenet-mpvd-use-cases-01.txt draft-geng-homenet-mpvd-use-cases-02.txt

Homenet Working Group L. Geng
Internet-Draft H. Deng
Intended status: Standards Track China Mobile
Expires: January 4, April 18, 2016 July 3, October 16, 2015

Use Cases for Multiple Provisioning Domain in Homenet
draft-geng-homenet-mpvd-use-cases-01
draft-geng-homenet-mpvd-use-cases-02

Abstract

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.

Status of This Memo

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 January 4, April 18, 2016.

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.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Homenet with Multiple PvDs . . . . . . . . . . . . . . . . . 3
3.1. PvD associating an interface
4. Examples of MPvD Configurations in homenet . . Home Network . . . . . . . 4
3.2. PvD associating a service in homenet .
4.1. Single CE Router Connected to Single ISP with interior
router . . . . . . . . . 4
3.3. PvD for hybrid purposes in home network . . . . . . . . . 5
4. Examples of MPvD Configurations in Home Network . . . . . . . 5
4.1. Homenet 4
4.2. Two CE Routers Connected to a Single ISP . . . . . . . . . . two ISPs with Shared Subnets 6
4.3. One CE Routers Connected to two ISPs with Shared Subnets 6
5. PvD-aware node in homenet . . 5
4.2. Multihomed Homenet . . . . . . . . . . . . . . . . 6
6. IPv4 compatibility . . . 7
5. PvD-aware node in homenet . . . . . . . . . . . . . . . . . . 8
6. 7
7. Conveying PvD information . . . . . . . . . . . . . . . . . . 8
7. 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. 8
11.2. Informative References . . . . . . . . . . . . . . . . . 9 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 8

1. Introduction

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.

1.1. Requirements Language

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].

2. Terminology and Abbreviations

The terminology and abbreviations used in this document are defined
in this section.

o ISP: Internet Service Provider. A traditional network operator
who provides internet access to customers.

o VSP: Virtual Service Provider. An service provider who typically
provides over-the-top services including but not limited to
Internet of Things services (IoT).

3. Homenet with Multiple PvDs

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 a single PvD as it is connected to only one ISP and an
additional PvD if connected to both. two PvDs provided by ISPs respectively.

Apart from the multihoming resulted from physical connections to
different ISPs, the future residential network may , PvDs
in Homenet can also logically
connected to multiple Over-the-top service providers(i.e. IoT
service providers), who do not directly provide internet access be used for service to customers. provisioning. For example, one customer a
host may subscribe to a
traditional service one ISP for basic internet service, whilst subscribe to other providers
another ISP for Internet of Things service. The latter are
likely (IoT) service given that the CE
router have access to be VSPs as defined in Section 2 of this document, who are
not bounded both ISPs. On the other hand, the host user
may also subscribe to any of the ISPs providing basic access service same ISP for the
residential network. both services. In this either
case, a particular VSP may also use PvDs can be used for customized network configurations
purposes. This enables the VSPs service providers to provide independent
and flexible provisioning between on
its subscriber's network for different services. Meanwhile, VSPs IoT
service providers may also want to use independent PvDs to avoid the
configuration conflicts between each other as stated in RFC6418.

The following sections outline differenct types of PvD in homenet.

3.1. PvD associating an interface in homenet

One

A typical example of a PvD in home network is the one associating
an interface with
corresponding network configuration. configuration with an HNCP routers. These
includes both CE router and interior router in Homenet. As described
in ([RFC7368]), a multihomed an CE router in homnet connects with multiple
ISPs. It homenet may have several different uplink one or more external
interfaces (i.e. PON with ISPs and
LTE). ISP can use PvDs to associate its network configurations internal interfaces with
specific uplink interface interior routers.
For external interfaces, the CE router provides to its subscriber. can receive associated PvD
information can be delivered by ISP through the from corresponding
uplink interface of the CE router.

Another scenario is when the ISPs. For interior routers and hosts in homenet
have multiple uplink interfaces(i.e. LAN, WIFI, Zigbee). Depending
on the actual network implementation, PvDs for these interfaces can
be either configured by ISPs or VSPs. Since these devices connect
with the internet through interfaces, the CE
interior router within homnnet, mechanism
needs to be defined for PvD information delivery within homenet.

3.2. PvD associating a service in homenet

This type of PvD is useful in homenet when a provisioning domain is
needed for a specific service that a homenet user subscribe to.
Unlike the PvD associating an interface in homenet, this PvD
associates the network configuration with a service. The service can
be provided by any ISP or VSP that is available to the user.

In homenet, ISPs and VSPs can use this PvD for service-specific
provisioning in CE routers, interior routers and hosts. Service
providers could decide the number of PvDs they offer depending on the
services a user subscribes to. This enables complete dependency
between the provisioning of different services provided by either
same or different sources.

A good example of a device in homenet that may use such receive PvD is a IoT
box provided by VSP. This box may be information from connected to a CE router as an
interior router as demonstrated in section 3.2.2.1 of [RFC7368], or
integrated with the CE router
or the host in some circumstances.

Since some services may need provisioning domain in multiple devices other interior routers.

Hosts in homenet(i.e. Both IoT service gateway and host need homenet are expected to be
provisioned), PvDs associated with the same service in different
devices should ideally be managed by a single provider. multihomed as well. Hence,
necessary collaboration can be taken care of by the VSP/ISP.

3.3. PvD for hybrid purposes in home network

The coexistence of multiple interfaces and services is possible when
a device
may also be used in homenet is both multihomed with more than one ISPs and
subscribed to multiple services. Assuming that a service provider
has access such cases to associate different network
configurations. In this case, the interface of the device on which its service PvD information is
provided, a provisioning domain associating both received from
the service and
corresponding interface can be used for HNCP router a simpler set-up. For
example, instead of separately maintaining host is attached to, either a WIFI interface PvD and
an IoT service PvD, an VSP can merge the information of these to PvD
and only use CE router or a single PvD for hybrid provisioning. It is always
preferred that PvD for hybrid provisioning is used when possible,
since it offers better network configuration flexibility for service
provider and enables seamless coordination between interface and the
service runs on it.
interior router.

4. Examples of MPvD Configurations in Home Network

This section gives some examples of MPvD configurations in home
network.

4.1. Homenet Single CE Router Connected to a Single ISP with interior router
<----"Internet" PvD of ISP----> PvD----------->
_____
+--------+
+-------+ ( )
|Internet+---+ + +------( ISP )
+--------+ | | | ( ISP )
<------"IoT1" PvD of VSP1-------------->
+--------+ +------+
| PC +------+ +--------------------+ WWW |
+--------+ | HNCP | ( ) +------+
| IoT1 +---|--+ CE | ( )------+ VSP1 | )
+--------+ | | |Router | ( ) +------+
<------"IoT2" PvD of VSP2-------------->
+--------+
| SETBOX +------+ +--------------------+ VOD |
+--------+ | | ( ) +------+
| IoT2 +---+ + | ( )---+ VSP2 )
|
+--------+ <----"VOD" PvD--------------->
| | ( ) +------+
<------------"IoT3"
<------------------"VPN" PvD of VSP3------------------>
+----+ ------------------------->
+--------+ | HNCP | ( ) +------+
|IoT3+-+ +
| +----+ | +--------+ | Home | ( ) +------+
| |VPN +---+ | | +--------------------+ VPN |
| +----+ | |Interior| |Gateway| | | ( ) +------+
| Host 3 | |
|-+ HNCP +------+ | ( )------+ VSP3 )
| +----+ | | Router | | | ( __) +------+
| |
|IoT4+-+ + | |IoT +---+ | | (___ ) +--------------------+ IoT |
| +----+ | +--------+ +-------+ (__ ) +------+

<------------"IoT4" PvD of VSP3------------------>
+--------+
<------------------"IoT" PvD-------------------------->

Figure 1

In this example, A homenet home gateway (CE router) is singlehomed connected with a single ISP as seen in
Figure 1. In this scenario, basic internet service is
provided by this ISP, IoT Four different services are provided by 3 different VSPs.
Multiple PvDs are created for the CE router for the purpose of
service provisioning. The home gateway, connected with multiple
service providers, receives basic internet PvD information from the
connected ISP, IoT1 PvD information from VSP1 and IoT2 PvD
information from VSP2.

Additionally, an HNCP-enabled interior router is connected to the this home gateway network
including Internet, VOD, VPN and provides another 2 IoT services from VSP3 to the
user. VSP3 may create 2 PvDs associating IoT3 IoT. There are 3 Hosts in this set-
up. PC and setbox use "Internet" and IoT4 "VoD" PvDs respectively
for the interior router, subject to the user's subscription.

In this example, ISP provides basic internet service through a
homenet home gateway and VSPs provides multiple IoT services through
Host 3 uses both the HNCP home gateway "VPN" and the interior "IoT" PvD.

The four PVDs could be either implicit or explicit PvDs. Explicit
PvDs should be initially assigned to HNCP router. Since none
of the gateway devices are multihomed, CE router by ISP. And then
forwarded to interior routers and host. Given that all of the PvDs associate
corresponding network configuration with a specific service. The are
explicit in the case above, the "Internet" PvD
information is delivered by ISP forwarded to PC and VSPs through the corresponding
singlehomed interface.

4.2. Multihomed Homenet

<--------"Internet1" PvD of ISP1--------->
<-"LTE" PvD of ISP1---->
_____
+---------+ +-------+ ( )
|Internet1+------+ +-LTE--( ) +-----+
+---------+ | | ( ) | |
| | ( ISP1 )--+ |
<----------"IoT1"
"VOD" PvD of VSP--------------> | |
| | ( _) | |
+----+ +--------+ | | ( ____) | |
|IoT1+-+ + | | | | |
+----+ | |Interior| | HNCP | | |
|-+ HNCP +---+ Home | | VSP |
+----+ | | Router | |Gateway| | |
|IoT2+-+ + | | | _____ | |
+----+ +--------+ | | ( ) | |
| | __( ) | |
<----------"IoT2" PvD of VSP--------------> | |
| | ( ISP2 )--+ |
+---------+ | | ( __) | |
|Internet2+------+ +-PON-( _) +-----+
+---------+ +-------+ ( ____)

<-"PON" PvD of ISP2---->
<--------"Internet2" PvD of ISP2--------->

Figure 2

Figure 2 illustrates an example of multihomed HNCP home gateway. In
this example, two ISPs are connected with the HNCP home gateway and
both provide internet services. The interfaces used to SETBOX by the HNCP home
gateway for these 2 ISPs are LTE CE router, and PON, which are provisioned
within the LTE PvD of ISP1 "VPN" and PON PvD of ISP2. Another 2 PvD for
individual internet service "IoT" PvDs
are also created by ISP1 forwarded to interior HNCP router and ISP2
respectively. In principle, it is preferred in this example that the
2 PvDs of the same ISP then Host 3. The PvD_ID
should be merged as one hybrid PvD, which
associates the complete set of network configuration with both kept the
internet service and same when the corresponding uplink interface.

The interior HNCP router in this example PvDs are similiar to the one in
the previous example, providing 2 IoT services provisioned separately
by VSP. forwarded. However, it is worth mentioning that the IoT1 and IoT2 PvDs
information is not necessarily delivered from a fixed ISP because of
the nature of multihomed gateway. It is upto the VSP to make the
decision according to the available other
associated network resources.

Although not shown in Figure 2, the HNCP home gateway may also
directly provide IoT service from VSP. Since VSP is normally homed
with multiple ISPs, the multihomed HNCP home gateway may receive PvD
information from different ISPs for the IoT service. PvD configuration conflicts need (i.e. delegated prefixes) should be
changed accordingly.

4.2. Two CE Routers Connected to two ISPs with Shared Subnets

To be avoided in this case. added

4.3. One CE Routers Connected to two ISPs with Shared Subnets

To be added

5. PvD-aware node in homenet

PvD-aware

As defined in MIF, "PvD-aware node is a a node that supports the device where the provisioning domains and
associated
association of network configuration are set up. In information into PvDs and the examples given
in Section 4,
use of these PvDs to serve requests for network connections". In
Homenet, the HNCP home gateways CE router, interior router and Interior HNCP routers host are all PvD-aware PvD-
aware nodes.

The HNCP home gateway CE router PvD-related functionality is define as follows:

o Generates implicit PvDs for different uplink interfaces.

o Requests and receives MPvD identity all explicit PvDs provided by the connected
ISPs.

o Generates explicit PvDs for interior routers and associated network configuration from hosts referring
to the network ISP-provided PvDs and forwards them accordingly.

o Creates and forward stores the
MPvD information belonging PvD mapping between the PvD applied itself
the the one forwarded to interior routers. It is worth
mentioning that a PvD-aware node may also be a host in homenet,which
is not shown in routers and hosts using the given examples. For instance, a mobile device
connected with
assigned PvD_ID and prefix.

o Identify the prefix received from homenet nodes and performs PvD
selection based on PvD mapping.

The interior router may have MPvDs PvD-related functionality is defined as follows:

o Generates implicit PvDs for it's Wifi different homenet internal interface.

o Requests and
cellular interfaces, or for multiple services it subscribed to.

As introduced in RFC7556, typical information a PvD-aware node
learned from network by a provisioning domain including source
address prefixes for use receives all explicit PvDs provided by the connected
homenet routers.

o Generates explicit PvDs for interior routers and hosts within the PvD,IP
address(es) of referring
to the DNS server(s) homenet-router-provided PvDs and default gateway address. While
these information is maintained in forwards them accordingly.

o Creates and stores the PvD-aware node, it needs to
assign prefixes to PvD mapping between the connected PvD applied itself
the the one forwarded to interior routers and hosts within homenet using homenet-
defined approaches.

6. Conveying the
assigned PvD_ID and prefix.

o Identify the prefix received from homenet nodes and performs PvD information

The
selection based on PvD associated with an VSP service may be directly mapping.

The host PvD-related functionality is defined as follows:

o Generates implicit PvDs for different interfaces between host and
homenet routers.

o Requests and receives all explicit PvDs provided by
VSP using application layer approach, connected
homenet routers.

6. IPv4 compatibility

PvD in homenet can be either single-family or provided by the dual-stack. For
single-family PvD, the ISPs 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
which the VSP is homed if same PvD. In both
cases, there are collaboration between ISPs and
VSPs. can either be only one IPV4 PvD for each interface or
multiple IPV4 PvDs with different default gateway addresses.

7. Conveying PvD information

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 ISPs and VSPs ISP to the CE routers, 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 and
hosts, HNCP-related routers, HNCP-based approach need to be concerned. 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.

8. Acknowledgements

The author would like to thank Ted Lemon Lemon, Mark Townsley, Markus
Stenberg and Steven Barth for valuable initial discussions of and contributions
to this document.

9. IANA Considerations

This memo includes no request to IANA.

10. Security Considerations

TBA

10.

11. References

10.1.

11.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997. 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, DOI
10.17487/RFC2629, June 1999.

10.2. 1999,
<http://www.rfc-editor.org/info/rfc2629>.

11.2. Informative References

[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", RFC 6418, DOI
10.17487/RFC6418, November 2011. 2011,
<http://www.rfc-editor.org/info/rfc6418>.

[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
Weil, "IPv6 Home Networking Architecture Principles", RFC
7368, DOI 10.17487/RFC7368, October 2014. 2014,
<http://www.rfc-editor.org/info/rfc7368>.

Authors' Addresses

Liang Geng
China Mobile

Email: gengliang@chinamobile.com

Hui Deng
China Mobile

Email: denghui@chinamobile.com