idnits 2.17.1 draft-zhang-intarea-wifi-home-network-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 : ---------------------------------------------------------------------------- ** There are 17 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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 16, 2012) is 4300 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Intarea WG R. Zhang 3 Internet-Draft China Telecom 4 Intended status: Informational July 16, 2012 5 Expires: January 17, 2013 7 Carrier's Wifi at Home Network 8 draft-zhang-intarea-wifi-home-network-01 10 Abstract 12 Today operator could share the wifi network at subscriber's home for 13 their public subscribers. It need to upgrade the home router which 14 has integrated wifi already. Some technical requirements have been 15 clarified in this document. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 17, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Network Architecture . . . . . . . . . . . . . . . . . . . . . 3 59 3. Requirements for Carrier's home network . . . . . . . . . . . . 4 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 63 7. Normative References . . . . . . . . . . . . . . . . . . . . . 4 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 Lots of users are using Wifi at home, but they are not Carrier's 69 Wifi, using Carrier's ESSID at home could help to expand operator's 70 wifi network. Normally home wifi is integrated with home router, so 71 home router need to be updated to support both private home ESSID and 72 Carrier's ESSID. Operator could either subsidize or compensate some 73 price for user who could allow to share their home wifi for their 74 neighbors or passing-by people. 76 2. Network Architecture 78 The network architecture is shown as belowed figure 1, home router 79 will advertise two ESSIDs, one is for home user "Bob's home", the 80 other is Operator's ESSID. Sometime home user need to deploy his own 81 wifi AP2 to expand the coverage of wifi, that wifi will have the 82 diffculty to advertise operator's ESSID because this AP2 is bought by 83 user other than operator's free offer. 85 +----------------------------------+ +----------------------+ 86 | | | | 87 | ESSID 2: Operator's wifi | | +-------+ | 88 | ESSID 1: Bob's Home | | |Policy | | 89 | +----+ # | | +-------+ | 90 | |Home|- - - - - - - - - - >| | | | +-->Mobile | 91 | |User| _ - - - - - >+--------+ | | | Core | 92 | +----+ / | Home |CAPWAP +-------+ | | 93 | / | Router |--------| WLC | | | 94 | +--------+ / |Wifi AP1|========| BRAS |===+==>Internet| 95 | |Neighbor|- +--------+ | SR | | | 96 | |User | | | +-------+ | | 97 | +--------+ +--------+ | | | | +--->IPTV | 98 | |Wifi AP2|-----+ | | +------+ +------+ | 99 | +--------+ | | |Portal|--| AAA | | 100 | | | +------+ +------+ | 101 +----------------------------------+ +----------------------+ 103 Figure 1: Carrier's wifi at home 105 Operator's network architecture needs some upgrade which seems mostly 106 diffculty part, but actually feasible since it is software based 107 upgrade. WLC which support CAPWAP need to be considered to be 108 deployed standalone or integrate together with BRAS. Policy Server 109 which is used to assign QoS policy at home router, Wifi Portal page 110 need to be used to authenticate the opeartor's wifi user. 112 3. Requirements for Carrier's home network 114 The requirement for carrier's wifi at home could be listed below 116 1) The backhaul of home router need to upgrade to support CAPWAP 117 protocols, BRAS in the backend also need to route operator's wifi 118 traffic and CAPWAP control signaling to Wireless LAN Controller 119 correctly. 121 2) Operator's policy need to be downloaded into the home router to 122 configure QoS policy inside the homoe router. Mostly home user's 123 traffic has high priority than neighbor operator's user or visiting 124 operator's user 126 3) Neighbor and passying-by people need to be authenticated by the 127 operator's portal. 129 4) Home router need to differentiate different VLAN network for home 130 user and opeartor'wifi user. 132 4. IANA Considerations 134 This document makes no request of IANA. 136 Note to RFC Editor: this section may be removed on publication as an 137 RFC. 139 5. Security Considerations 141 Some applications may rely on the source address as the credentials, 142 it may need to reestablish the new credential after the application 143 switchs into a new source address. 145 6. Acknowledgements 147 The author thanks the discussion from et al. in the development of 148 this document. 150 7. Normative References 152 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 153 Requirement Levels", BCP 14, RFC 2119, March 1997. 155 Author's Address 157 Rong Zhang 158 China Telecom 159 No.109 Zhongshandadao avenue 160 Tianhe District, 161 Guangzhou 510630 162 China 164 Email: zhangr@gsta.com