idnits 2.17.1 draft-wang-multihoming-icn-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 8) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 173 instances of too long lines in the document, the longest one being 16 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 46 has weird spacing: '...mission opera...' == Line 47 has weird spacing: '...flow to to ou...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 2018) is 1991 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 122, but not defined == Unused Reference: 'RFC7426' is defined on line 293, but no explicit reference was found in the text == Unused Reference: 'OF-SPEC' is defined on line 299, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT L.Wang 3 Intended Status:Informational Univ. Sci. & Tech. of China 4 Expires: April 2019 October 2018 6 POF-ICN based multihoming transmission framework 7 draft-wang-multihoming-icn-00 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Abstract 39 This document presents a POF-ICN based multihoming transmission 40 framework.POF is an SDN forwarding plane technology proposed by 41 Huawei,we use it to enable information-centric networking (ICN). 42 The purpose of the framework is to provide an overall picture of 43 the multihoming transmission system.we first describe the 44 relationships among the various components of mobile networks and 45 the newly added entities, such as Mobility management and Session 46 management.Then we describe the Multihoming transmission operation 47 flow to to outline what each components needs to accomplish and to 48 how these components and mechanisms fit together. 50 Copyright and License Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with 60 respect to this document. Code Components extracted from this 61 document must include Simplified BSD License text as described in 62 Section 4.e of the Trust Legal Provisions and are provided without 63 warranty as described in the Simplified BSD License. 65 Table of Contents 67 Table of Contents 69 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2 Framework Benefit . . . . . . . . . . . . . . . . . . . . . . . 4 72 2.1 Forwarding speed . . . . . . . . . . . . . . . . . . . . . . 4 73 2.2 Control plane . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.3 Session management . . . . . . . . . . . . . . . . . . . . . 5 75 3 Framework overview . . . . . . . . . . . . . . . . . . . . . . . 5 76 4 Operation flow . . . . . . . . . . . . . . . . . . . . . . . . 6 77 5 Security Considerations . . . . . . . . . . . . . . . . . . . . . 7 78 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 8 79 7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 8.1 Normative References . . . . . . . . . . . . . . . . . . . . . 8 82 8.2 Informative References . . . . . . . . . . . . . . . . . . . . 8 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 85 1. Introduction 87 Software-Defined Networking (SDN)[RFC7149] gives operators 88 programmatic control over their networks. In SDN, the control plane 89 is physically separate from the forwarding plane, and one control 90 plane controls multiple forwarding devices. In SDN, a common, open, 91 vendor-agnostic interface between the control plane and the 92 forwarding plane, which may contain forwarding devices from 93 different hardware and software vendors, is required. OpenFlow is 94 such an interface. 96 Huawei presents the Protocol Oblivious Forwarding (POF) technology 97 Base on openFlow. The basic idea is to denote any protocol field, 98 as well as the metadata, which is considered as one special 99 protocol header that can be configured by the controller, with a 100 triad of .POF also defines a set of protocol 101 oblivious forwarding actions/instructions. The actions/instructions 102 can realize the functions of all forwarding instructions/actions 103 defined in OpenFlow, not only for the existing protocols but also 104 for any new protocols.With the protocol oblivious data plane that 105 are composed of POF forwarding devices,we will use POF to enable 106 information-centric networking (ICN).In the following content we 107 will use POF-ICN to refer to it. 109 On the other hand,Multihoming support on IP hosts can greatly 110 improve the user experience. With the simultaneous use of multiple 111 access networks, multihoming brings better network connectivity, 112 reliability,and improved quality of communication.compared to 113 tcp/ip network,we will discuss how to realize multihoming in POF- 114 ICN. 116 1.1 Treminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 120 this document are to be interpreted as described in RFC 2119 121 [RFC2119]. 123 Software-Defined Networking (SDN) - A programmable networks 124 approach that supports the separation of control and forwarding 125 planes via standardized interfaces. 127 Forwarding Plane (FP) - The collection of resources across all 128 network devices responsible for forwarding traffic. 130 Control Plane (CP) - The collection of functions responsible for 131 controlling one or more network devices.CP instructs network 132 devices with respect to how to process and forward packets. The 133 control plane interacts primarily with the forwarding plane and, to 134 a lesser extent, with the operational plane. 136 Protocol Oblivious Forwarding (POF) - The protocol that is proposed 137 by Huawei to provide a new way to develop SDN. 139 2. Framework Benefit 141 To provide better multi-homed transmission services, POF-ICN 142 support for multi-hosting is reflected in the following aspects: 144 2.1 Forwarding speed 146 Forwarding speed of the forwarding plane is fast and the forwarding 147 path is controllable. Under the POF-ICN architecture, the control 148 plane is separate from the forwarding plane. The forwarding plane is 149 only responsible for simple flow table matching and data packet 150 forwarding, which greatly eases the switch processing burden. 151 Compared to the traditional TCP/IP architecture.Therefore, packet 152 forwarding is faster than traditional networks. On the other hand, 153 the flow entry on the switch is delivered by the POF controller, so 154 that the forwarding path can be controlled.multiple paths can be 155 used conveniently under multihoming scenario. In the traditional 156 network architecture, mutihoming needs to be implemented by using 157 multiple IP address pairs which is completely uncontrollable. 159 2.2 Control plane 160 The control plane can select the optimal content source and get 161 the optimal transmission path. The POF controller in the POF-ICN 162 architecture manages the underlying forwarding devices. Each POF 163 controller can obtain the interconnection information of the 164 switches in its control domain through the virtual layer.it can 165 control the forwarding rules between switch by issuing the flow 166 table.This feature brings great convenience to multihoming 167 transmission. In scenarios where the user needs multihoming 168 transmission, the POF controller can calculate the position of the 169 content source closest to the user in the network according to the 170 topology information. The TCP/IP network can not achieve that. In 171 the TCP/IP network architecture, content can usually only be 172 acquired via a fixed ip address. In POF-ICN, it is possible to 173 obtain the required content through the network cache. 175 2.3 Session management 177 The session management module is introduced.In the POF-ICN, a 178 session management module is introduced to maintain the request 179 connection through the user network address and the request 180 content name so that it can provide a basis for further 181 optimization of the algorithm. In the POF-ICN multihoming 182 transmission scenario, the session management obtains connection 183 information through the POF controller.it will use optimization 184 algorithm to obtain the optimal forwarding strategy . Finally, the 185 best solution to the solution is fed back to the controller. The 186 controller controls the underlying switch Forwarding rules to 187 maximize link utilization in multihoming transmissions. 189 3. Framework overview 191 This document provides a POF-ICN multihoming transport framework, as 192 shown in Figure 1. In addition to the existing network entities 193 (such as base stations and mobile gateways, POF switches, etc.), 194 some logical entities are defined, namely Mobility Management Entity 195 (MME), POF controller, and session management. 197 Mobility management is responsible for the management of terminals 198 and hosts. Each time the terminal starts a service, it interacts 199 with the MME to obtain multiple available hosts and MME will 200 allocates access bandwidth. When it leaves, it will log out at the 201 MME and release the bandwidth. The MME will update the network 202 conditions in real time, such as available bandwidth, available 203 hosts, access terminals, and so on. 205 Session management is responsible for the management and 206 transmission control of all multihoming services. The session 207 management firstly completes the access bandwidth allocation (host 208 resource management) through the interaction between the MME and the 209 terminal on the access side , then the controller completes path 210 planning and path bandwidth resource allocation on the ICN network 211 side. Session management implements a dynamic decision model by 212 randomly estimating the transmission rate and the transmission link 213 delay at both ends of the access switch and the content source 214 switch. 216 The POF controller is responsible for the transmission path planning. 217 According to the session management, a plurality of parallel paths 218 from the request side to the content source are planned for the 219 current network resources allocated by the multi-homed service, and 220 the path planning is implemented by issuing a flow table to the POF 221 switch of the forwarding plane. 223 4. Operation flow 225 The terminal in this example is equipped with WLAN and LTE 226 interfaces and is also equipped with multihoming features. It can 227 connect base stations and wireless POF switches The transmission 228 steps are as follows: 230 Step (1): The terminal is connected to multiple hosts such as a WLAN 231 and an LTE network. 233 Step (2): The host will register the access to the MME with the MME 234 and update it regularly 236 Step (3): When the terminal has service requirements, it needs to 237 report the service request first. Through the different access 238 networks, the current quality of service, network status, reported 239 to the MME; At the same time, the MME will periodically receive the 240 load of the cellular base station, Wi-Fi access point; 242 Step (4): After receiving the request, the MME considers the 243 different transmission characteristics of multiple wireless networks 244 and the respective network load conditions, and reasonably allocates 245 the services and resources among multiple networks, and sends the 246 resource allocation plan to the base station and The access point, 247 which simultaneously sends the distribution plan to the session 248 management module of the control plane 249 Step (5): The controller obtains the host and bandwidth allocated 250 for the terminal from the session management office,and parses the 251 location of the content source (possibly multiple), and combines the 252 above information to plan multiple paths between the terminal and 253 content source in the network topology. It will send the result to 254 the session management module. 256 Step (6): According to the result of the bandwidth allocation, the 257 session management module establishes a dynamic decision process 258 according to the service requirements.it calculates an end-to-end 259 multi-path transmission strategy, and invokes the controller to 260 create a flow table. 262 Step (7): The controller delivers a flow table to the forwarding 263 plane 265 Step (8): When the terminal moves or the network is abnormal, the 266 session management cooperates with the MME and the controller to 267 update the access host and the transmission path 269 Step (9): update and deliver new flow tables 271 5. Security Considerations 273 The mechanism described in this document does not raise any new 274 security issues for the PCEP protocols. 276 6. IANA Considerations 278 This document includes no request to IANA. 280 7. Conclusion 282 We describe the framework of our system. At the same time,we 283 describe the function of each module. 285 8. References 287 8.1 Normative References 289 [RFC7149] Boucadair, M., "Software-Defined Networking: A Perspective 290 from within a Service Provider Environment", RFC 7149, 291 March 2014. 293 [RFC7426] E. Haleplidis, Ed., "Software-Defined Networking (SDN): 294 Layers and Architecture Terminology", RFC 7426, January 295 2015. 297 8.2 Informative References 299 [OF-SPEC] Open Networking Foundation, "OpenFlow Switch 300 Specification, version 1.5.1", October 2015, 301 . 303 Authors' Addresses 305 Lei Wang 306 University of Science and Technology of China, 307 96 Jinzhai Rd., Hefei, Anhui, 230026, China. 309 EMail: wangl@ustc.edu.cn