idnits 2.17.1 draft-geng-homenet-mpvd-use-cases-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7368]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 3, 2015) is 3213 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2629' is defined on line 385, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Homenet Working Group L. Geng 2 Internet-Draft H. Deng 3 Intended status: Standards Track China Mobile 4 Expires: January 4, 2016 July 3, 2015 6 Use Cases for Multiple Provisioning Domain in Homenet 7 draft-geng-homenet-mpvd-use-cases-01 9 Abstract 11 This document describes the use cases of multiple provisioning domain 12 (MPVD) in homenet. Although most residential networks nowadays are 13 connected to a single ISP and normally subscribed to standard 14 internet service, it is expected that much wider range of devices and 15 services will become common in home networks. Homenet defines such 16 home network topologies with increasing number of devices with the 17 assumption that it requires minimum configuration by residential 18 user. As described in the homenet architecture ([RFC7368]), 19 multihoming and multi-service residential network will be more common 20 in the near future. Nodes in such network may commonly have multiple 21 interfaces or subscribe to multiple services. Potential types of 22 PVD-aware nodes concerning interface and service specific 23 provisioning domains are introduced in this document. Based on this, 24 different MPVD configuration examples are given. These examples 25 illustrate how PVD may be implemented in home network. PVDs provide 26 independent provisioning domains for different interfaces and 27 services, which enables robust and flexible network configuration for 28 these networks. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 4, 2016. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 66 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 67 3. Homenet with Multiple PvDs . . . . . . . . . . . . . . . . . 3 68 3.1. PvD associating an interface in homenet . . . . . . . . . 4 69 3.2. PvD associating a service in homenet . . . . . . . . . . 4 70 3.3. PvD for hybrid purposes in home network . . . . . . . . . 5 71 4. Examples of MPvD Configurations in Home Network . . . . . . . 5 72 4.1. Homenet Connected to a Single ISP . . . . . . . . . . . . 5 73 4.2. Multihomed Homenet . . . . . . . . . . . . . . . . . . . 7 74 5. PvD-aware node in homenet . . . . . . . . . . . . . . . . . . 8 75 6. Conveying PvD information . . . . . . . . . . . . . . . . . . 8 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 10.2. Informative References . . . . . . . . . . . . . . . . . 9 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 84 1. Introduction 86 It is believed that future residential network will more commonly be 87 multihomed, which potentially provides either resilience or more 88 flexible services. At the same time, more internal routing and 89 multiple subnets are expected to commonly exist in such networks. 90 For example, customer may want independent subnets for private and 91 guest usages. Homenet describes such future home network involving 92 multiple routers and subnets ([RFC7368]). 94 Multihoming and the increasing number of subnets bring challenges on 95 provisioning of the network. As stated in [RFC6418], such multihomed 96 scenarios with nodes attached to multiple upstream networks may 97 experience configuration conflicts, leading to a number of problems. 98 To deal with these problem, draft-ietf-mif-mpvd-arch-10 provides a 99 framework which introduces Provisioning Domain (PvD), which 100 associates a certain interface and its related network configuration 101 information. Hence, corresponding network configuration can be used 102 when packets are delivered through a particular interface. 104 This document focuses on the MPvD use cases in residential network, 105 particularly the IPV6-based homenet. Based on the homenet topology, 106 use cases of MPvD in homenet are described for both singlehomed and 107 multihomed network configurations. 109 1.1. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 2. Terminology and Abbreviations 117 The terminology and abbreviations used in this document are defined 118 in this section. 120 o ISP: Internet Service Provider. A traditional network operator 121 who provides internet access to customers. 123 o VSP: Virtual Service Provider. An service provider who typically 124 provides over-the-top services including but not limited to 125 Internet of Things services (IoT). 127 3. Homenet with Multiple PvDs 129 In the most common multihoming scenarios, the home network has 130 multiple physical connections to the ISP networks. Section 3.2.2.2 131 and 3.2.2.3 in [RFC7368] give the topology examples of such homenet. 132 In the examples, homenet hosts are connected to a single or multiple 133 customer edge routers (CE router), the CE routers are then connected 134 to separate ISP networks. For the particular topology with a single 135 CE router given in Section 3.2.2.3 in [RFC7368], the CE router is a 136 mif node since it has two interfaces connected to individual service 137 provider routers. Given that the CE router is a PvD-aware node, it 138 may have a single PvD as it is connected to only one ISP and an 139 additional PvD if connected to both. 141 Apart from the multihoming resulted from physical connections to 142 different ISPs, the future residential network may also logically 143 connected to multiple Over-the-top service providers(i.e. IoT 144 service providers), who do not directly provide internet access 145 service to customers. For example, one customer may subscribe to a 146 traditional service ISP for basic internet service, whilst subscribe 147 to other providers for Internet of Things service. The latter are 148 likely to be VSPs as defined in Section 2 of this document, who are 149 not bounded to any of the ISPs providing basic access service for the 150 residential network. In this case, a particular VSP may also use 151 PvDs for customized network configurations purposes. This enables 152 the VSPs to provide independent and flexible provisioning between on 153 its subscriber's network for different services. Meanwhile, VSPs may 154 also want to use independent PvDs to avoid the configuration 155 conflicts between each other as stated in RFC6418. 157 The following sections outline differenct types of PvD in homenet. 159 3.1. PvD associating an interface in homenet 161 One typical example of a PvD in home network is the one associating 162 an interface with network configuration. As described in 163 ([RFC7368]), a multihomed CE router in homnet connects with multiple 164 ISPs. It may have several different uplink interfaces (i.e. PON and 165 LTE). ISP can use PvDs to associate its network configurations with 166 specific uplink interface the CE router provides to its subscriber. 167 PvD information can be delivered by ISP through the corresponding 168 uplink interface of the CE router. 170 Another scenario is when the interior routers and hosts in homenet 171 have multiple uplink interfaces(i.e. LAN, WIFI, Zigbee). Depending 172 on the actual network implementation, PvDs for these interfaces can 173 be either configured by ISPs or VSPs. Since these devices connect 174 with the internet through the CE router within homnnet, mechanism 175 needs to be defined for PvD information delivery within homenet. 177 3.2. PvD associating a service in homenet 179 This type of PvD is useful in homenet when a provisioning domain is 180 needed for a specific service that a homenet user subscribe to. 181 Unlike the PvD associating an interface in homenet, this PvD 182 associates the network configuration with a service. The service can 183 be provided by any ISP or VSP that is available to the user. 185 In homenet, ISPs and VSPs can use this PvD for service-specific 186 provisioning in CE routers, interior routers and hosts. Service 187 providers could decide the number of PvDs they offer depending on the 188 services a user subscribes to. This enables complete dependency 189 between the provisioning of different services provided by either 190 same or different sources. 192 A good example of a device in homenet that may use such PvD is a IoT 193 box provided by VSP. This box may be connected to a CE router as an 194 interior router as demonstrated in section 3.2.2.1 of [RFC7368], or 195 integrated with the CE router or the host in some circumstances. 197 Since some services may need provisioning domain in multiple devices 198 in homenet(i.e. Both IoT service gateway and host need to be 199 provisioned), PvDs associated with the same service in different 200 devices should ideally be managed by a single provider. Hence, 201 necessary collaboration can be taken care of by the VSP/ISP. 203 3.3. PvD for hybrid purposes in home network 205 The coexistence of multiple interfaces and services is possible when 206 a device in homenet is both multihomed with more than one ISPs and 207 subscribed to multiple services. Assuming that a service provider 208 has access to the interface of the device on which its service is 209 provided, a provisioning domain associating both the service and 210 corresponding interface can be used for a simpler set-up. For 211 example, instead of separately maintaining a WIFI interface PvD and 212 an IoT service PvD, an VSP can merge the information of these to PvD 213 and only use a single PvD for hybrid provisioning. It is always 214 preferred that PvD for hybrid provisioning is used when possible, 215 since it offers better network configuration flexibility for service 216 provider and enables seamless coordination between interface and the 217 service runs on it. 219 4. Examples of MPvD Configurations in Home Network 221 This section gives some examples of MPvD configurations in home 222 network. 224 4.1. Homenet Connected to a Single ISP 225 <----"Internet" PvD of ISP----> 226 _____ 227 +--------+ +-------+ ( ) 228 |Internet+---+ + +------( ISP ) 229 +--------+ | | | ( ) 230 <------"IoT1" PvD of VSP1--------------> 231 +--------+ | | | ( ) +------+ 232 | IoT1 +---|--+ | ( )------+ VSP1 | 233 +--------+ | | | ( ) +------+ 234 <------"IoT2" PvD of VSP2--------------> 235 +--------+ | | | ( ) +------+ 236 | IoT2 +---+ + | ( )---+ VSP2 | 237 +--------+ | | ( ) +------+ 238 <------------"IoT3" PvD of VSP3------------------> 239 +----+ +--------+ | HNCP | ( ) +------+ 240 |IoT3+-+ + | | Home | ( ) | | 241 +----+ | |Interior| |Gateway| ( ) | | 242 |-+ HNCP +------+ | ( )------+ VSP3 | 243 +----+ | | Router | | | ( __) | | 244 |IoT4+-+ + | | | (___ ) | | 245 +----+ +--------+ +-------+ (__ ) +------+ 247 <------------"IoT4" PvD of VSP3------------------> 249 Figure 1 251 A homenet home gateway (CE router) is singlehomed with a single ISP 252 as seen in Figure 1. In this scenario, basic internet service is 253 provided by this ISP, IoT services are provided by 3 different VSPs. 254 Multiple PvDs are created for the CE router for the purpose of 255 service provisioning. The home gateway, connected with multiple 256 service providers, receives basic internet PvD information from the 257 connected ISP, IoT1 PvD information from VSP1 and IoT2 PvD 258 information from VSP2. 260 Additionally, an HNCP-enabled interior router is connected to the 261 home gateway and provides another 2 IoT services from VSP3 to the 262 user. VSP3 may create 2 PvDs associating IoT3 and IoT4 respectively 263 for the interior router, subject to the user's subscription. 265 In this example, ISP provides basic internet service through a 266 homenet home gateway and VSPs provides multiple IoT services through 267 both the HNCP home gateway and the interior HNCP router. Since none 268 of the gateway devices are multihomed, all of the PvDs associate 269 corresponding network configuration with a specific service. The PvD 270 information is delivered by ISP and VSPs through the corresponding 271 singlehomed interface. 273 4.2. Multihomed Homenet 275 <--------"Internet1" PvD of ISP1---------> 276 <-"LTE" PvD of ISP1----> 277 _____ 278 +---------+ +-------+ ( ) 279 |Internet1+------+ +-LTE--( ) +-----+ 280 +---------+ | | ( ) | | 281 | | ( ISP1 )--+ | 282 <----------"IoT1" PvD of VSP--------------> | | 283 | | ( _) | | 284 +----+ +--------+ | | ( ____) | | 285 |IoT1+-+ + | | | | | 286 +----+ | |Interior| | HNCP | | | 287 |-+ HNCP +---+ Home | | VSP | 288 +----+ | | Router | |Gateway| | | 289 |IoT2+-+ + | | | _____ | | 290 +----+ +--------+ | | ( ) | | 291 | | __( ) | | 292 <----------"IoT2" PvD of VSP--------------> | | 293 | | ( ISP2 )--+ | 294 +---------+ | | ( __) | | 295 |Internet2+------+ +-PON-( _) +-----+ 296 +---------+ +-------+ ( ____) 298 <-"PON" PvD of ISP2----> 299 <--------"Internet2" PvD of ISP2---------> 301 Figure 2 303 Figure 2 illustrates an example of multihomed HNCP home gateway. In 304 this example, two ISPs are connected with the HNCP home gateway and 305 both provide internet services. The interfaces used by the HNCP home 306 gateway for these 2 ISPs are LTE and PON, which are provisioned 307 within the LTE PvD of ISP1 and PON PvD of ISP2. Another 2 PvD for 308 individual internet service are also created by ISP1 and ISP2 309 respectively. In principle, it is preferred in this example that the 310 2 PvDs of the same ISP should be merged as one hybrid PvD, which 311 associates the complete set of network configuration with both the 312 internet service and the corresponding uplink interface. 314 The interior HNCP router in this example are similiar to the one in 315 the previous example, providing 2 IoT services provisioned separately 316 by VSP. However, it is worth mentioning that the IoT1 and IoT2 PvDs 317 information is not necessarily delivered from a fixed ISP because of 318 the nature of multihomed gateway. It is upto the VSP to make the 319 decision according to the available network resources. 321 Although not shown in Figure 2, the HNCP home gateway may also 322 directly provide IoT service from VSP. Since VSP is normally homed 323 with multiple ISPs, the multihomed HNCP home gateway may receive PvD 324 information from different ISPs for the IoT service. PvD 325 configuration conflicts need to be avoided in this case. 327 5. PvD-aware node in homenet 329 PvD-aware node is the device where the provisioning domains and 330 associated network configuration are set up. In the examples given 331 in Section 4, the HNCP home gateways and Interior HNCP routers are 332 all PvD-aware nodes. The HNCP home gateway receives MPvD identity 333 and associated network configuration from the network and forward the 334 MPvD information belonging to interior routers. It is worth 335 mentioning that a PvD-aware node may also be a host in homenet,which 336 is not shown in the given examples. For instance, a mobile device 337 connected with the interior router may have MPvDs for it's Wifi and 338 cellular interfaces, or for multiple services it subscribed to. 340 As introduced in RFC7556, typical information a PvD-aware node 341 learned from network by a provisioning domain including source 342 address prefixes for use by the connected hosts within the PvD,IP 343 address(es) of the DNS server(s) and default gateway address. While 344 these information is maintained in the PvD-aware node, it needs to 345 assign prefixes to the connected hosts within homenet using homenet- 346 defined approaches. 348 6. Conveying PvD information 350 The PvD associated with an VSP service may be directly provided by 351 VSP using application layer approach, or provided by the the ISPs in 352 which the VSP is homed if there are collaboration between ISPs and 353 VSPs. 355 At the time this document was written, the conveying of PvD 356 information was still under discussion in mif working group. Popular 357 choices include DHCP and Route Advertisement. For PvD information 358 provided from ISPs and VSPs to the CE routers, the approaches for PvD 359 information delivery defined by mif may be directly used. For PvD 360 information delivery within homenet between HNCP-enabled routers and 361 hosts, HNCP-related approach need to be concerned. The detail of how 362 homenet could support the delivery of PvD information is subjected to 363 further discussions and will be addressed in a separate document. 365 7. Acknowledgements 367 The author would like to thank Ted Lemon for valuable initial 368 discussions of this document. 370 8. IANA Considerations 372 This memo includes no request to IANA. 374 9. Security Considerations 376 TBA 378 10. References 380 10.1. Normative References 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, March 1997. 385 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 386 June 1999. 388 10.2. Informative References 390 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 391 Provisioning Domains Problem Statement", RFC 6418, 392 November 2011. 394 [RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 395 "IPv6 Home Networking Architecture Principles", RFC 7368, 396 October 2014. 398 Authors' Addresses 400 Liang Geng 401 China Mobile 403 Email: gengliang@chinamobile.com 405 Hui Deng 406 China Mobile 408 Email: denghui@chinamobile.com