idnits 2.17.1
draft-geng-coms-architecture-02.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 81 instances of too long lines in the document, the longest
one being 3 characters 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 (March 5, 2018) is 2244 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'I-D.boucadair-connectivity-provisioning-protocol' is
defined on line 468, but no explicit reference was found in the text
== Unused Reference: 'RFC5440' is defined on line 492, but no explicit
reference was found in the text
== Outdated reference: A later version (-22) exists of
draft-boucadair-connectivity-provisioning-protocol-15
Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 none L. Geng
3 Internet-Draft China Mobile
4 Intended status: Informational L. Qiang
5 Expires: September 6, 2018 Huawei
6 J. Ordonez
7 O. Adamuz-Hinojosa
8 P. Ameigeiras
9 University of Granada
10 D. Lopez
11 Telefonica I+D
12 L. Contreras
13 Telefonica
14 March 5, 2018
16 COMS Architecture
17 draft-geng-coms-architecture-02
19 Abstract
21 This document defines the overall architecture of a COMS based
22 network slicing system. COMS works on the top level network slice
23 orchestrator which directly communicates with the network slice
24 provider and enables the technology-independent network slice
25 management.
27 Status of This Memo
29 This Internet-Draft is submitted in full conformance with the
30 provisions of BCP 78 and BCP 79.
32 Internet-Drafts are working documents of the Internet Engineering
33 Task Force (IETF). Note that other groups may also distribute
34 working documents as Internet-Drafts. The list of current Internet-
35 Drafts is at https://datatracker.ietf.org/drafts/current/.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference
40 material or to cite them other than as "work in progress."
42 This Internet-Draft will expire on September 6, 2018.
44 Copyright Notice
46 Copyright (c) 2018 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents
51 (https://trustee.ietf.org/license-info) in effect on the date of
52 publication of this document. Please review these documents
53 carefully, as they describe your rights and restrictions with respect
54 to this document. Code Components extracted from this document must
55 include Simplified BSD License text as described in Section 4.e of
56 the Trust Legal Provisions and are provided without warranty as
57 described in the Simplified BSD License.
59 Table of Contents
61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
63 3. Overall Architecture . . . . . . . . . . . . . . . . . . . . 3
64 4. Advanced Architecture . . . . . . . . . . . . . . . . . . . . 4
65 5. Integration with NFV . . . . . . . . . . . . . . . . . . . . 6
66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
69 9. Informative References . . . . . . . . . . . . . . . . . . . 10
70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
72 1. Introduction
74 Network slicing itself is a new concept triggered by vertical
75 industry, but that doesn't mean new forwarding technology is needed.
76 As an example given by [draft-arkko-arch-virtualization] shows, there
77 are multiple existing technologies could be used for network slicing
78 - VLAN tags are used in an ethernet segment, MPLS or VPNs across the
79 domain. If the storage and computing resources are considered, there
80 will be more available technologies (e.g., SFC).
82 Let's follow IETF's routine and image what will happen from the
83 bottom-up view. At first, existing technologies evolve toward
84 network slicing at forwarding plane in their own scopes. Then slice
85 management related functions will be patched at management/control
86 planes. When a network slice is going to be deployed inside a
87 domain, one of implementation technology will be selected, and the NS
88 provider directly operates on the management plane of this selected
89 technology. For example, If VPN is selected as the implementation
90 technology, then a network slice is a VPN for the NS provider in this
91 domain. While if SFC is selected in other domain, then a network
92 slice is a SFC for NS provider. What will happen if a network slice
93 across both VPN and SFC domains? There is no uniform management
94 manner in this case.
96 Then try to consider from the top-down view. There is no doubt that
97 slicing requirement is generated from NS tenant. When a NS tenant
98 request for NS service, normally he will not specify which
99 implementation technology should be used. Similarly, when the tenant
100 operates/manages his purchased slice, he doesn't want to care about
101 the technical details.
103 We can easily observe that bottom-up and top-down approaches will
104 eventually converge on a technology-independent common management
105 plane, that is exactly what COMS (Common Operation and Management on
106 network Slices) doing.
108 This document will explain how COMS works, and define the
109 architecture of COMS. Architecture discussed in this document is
110 assumed to be used only inside Transport Network region, and the end-
111 to-end network slice/slicing also just refers to the slice/slicing
112 across multiple TN domains in this document.
114 2. Terminology
116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
118 document are to be interpreted as described in [RFC2119].
120 Other network slicing related words used in this document are
121 interpreted as description in [COMS-PS].
123 Notations used in this document are interpreted as follows:
125 T(x->y): end-to-end delay from x to y;
127 B(x->y): bandwidth from x to y;
129 S(x): storage space of x.
131 3. Overall Architecture
133 This section provides the overall architecture for a COMS based
134 network slicing system as shown in Figure 1. If multiple such kind
135 of systems deployed in different domains, these systems may stitches
136 together through the method discussed in [Stitching-Management] and
137 [Stitching-Data]. COMS works on the top network orchestrator inside
138 Transport Network region, which directly receives the network slice
139 service profile, operation and management requests for network
140 slices. Based on received information, the network orchestrator will
141 select the most appropriate implementation technologies, and map the
142 technology independent requests into the technology specific
143 configuration information that will be sent to the corresponding
144 network slice controller/orchestrator downwards.
146 | Network Slice
147 | Service Profile
148 |
149 +--------------------------v----------------------------+
150 | |
151 | Top Level Network Orchestrator based on COMS |
152 | |
153 +--------------------------+----------------------------+
154 |
155 +--------+------------------+-------+-----------+----------------+
156 | | | | |
157 | +------v--------+ +------v--------+ +-------v-------+ +----v----+
158 | | | | | | | | |
159 | | NS Ctrlr/Orch | | NS Ctrlr/Orch | | NS Ctrlr/Orch | | ... |
160 | | | | | | | | |
161 | +-------+-------+ +-------+-------+ +-------+-------+ +----+----+
162 | | | | |
163 | | | | |
164 ==v=========v==================v==================v================v=====
165 = =
166 = +------------+ +------------+ +------------+ +------------+ +-------+ =
167 = |Connectivity| | Computing | | Storage | |Generalized | | ... | =
168 = | | | | | | |Functions | | | =
169 = +------------+ +------------+ +------------+ +------------+ +-------+ =
170 = =
171 =========================================================================
173 Figure 1: Overall Architecture of COMS
175 4. Advanced Architecture
177 This section discusses the detailed architecture of a COMS based
178 network slicing system through an example shown in Figure 2. We do
179 not intend to design the inner framework of the top level network
180 slicing orchestrator but to explain how COMS works. Four components
181 insides the top level network orchestrator are logical components
182 that could be converged sometimes.
184 o Common Information Model: can be understood as the template,
185 according to which the received network slice service profile is
186 translated.
188 o Split Service Profile into Domains: the end-to-end service profile
189 is split into the service profiles inside different domains.
191 o Select Specific Implementation Technologies: there may be multiple
192 available implementation technologies inside a domain, select the
193 most appropriate one according to the service profile. As
194 Figure 2's example shows, since the end-to-end delay in Domain 1
195 is very small, the Flex-E will be selected. While in Domain 2 two
196 storage units are required, the NFV technology will be selected.
198 o Map to Selected Technologies: necessary mapping to the controller/
199 orchestrator of selected technologies.
201 |Network Slice Service Profile
202 |
203 **************************************************************************
204 *Top Level Network Orchestrator based on COMS *
205 * | *
206 * +-------------------------------v ---------------------------------+ *
207 * |Common Information Model | *
208 * | ................................................................ | *
209 * | . ~~~~~~~ T(A->B)<=10ms; B(A->B)>=10M ~~~~~~~ . | *
210 * | . ~ A ~---------------------------------------~ B ~ S(B)=1G. | *
211 * | . ~~~~~~~ ~~~~~~~ . | *
212 * | . | T(A->C)<=20ms; B(A->C)>=10M ~~~~~~~ . | *
213 * | . +-----------------------------------------~ C ~ S(C)=2G. | *
214 * | . ~~~~~~~ . | *
215 * | ................................................................ | *
216 * +--------------------------------+---------------------------------+ *
217 * | *
218 * +--------------------------------v---------------------------------+ *
219 * |Split Service Profile into Domains | *
220 * |................................. ................................| *
221 * |. Domain 1 . .Domain 2 .| *
222 * |. T(A->D)<=2ms . . T(D->B)<=8ms S(B)=1G .| *
223 * |. ~~~~~~~ B(A->D)>=10M ~~~~~~~ B(D->B)>=10M ~~~~~~~ .| *
224 * |. ~ A ~ --------------~ D ~-----------------~ B ~ .| *
225 * |. ~~~~~~~ ~~~~~~~ ~~~~~~~ .| *
226 * |. | T(A->E)<=2ms . . T(E->C)<=18ms S(C)=2G .| *
227 * |. | B(A->E)>=10M ~~~~~~~ B(E->C)>=10M ~~~~~~~ .| *
228 * |. +-----------------~ E ~-----------------~ C ~ .| *
229 * |. ~~~~~~~ ~~~~~~~ .| *
230 * |..................................................................| *
231 * +---------------------------------+--------------------------------+ *
232 * | *
233 * +---------------------------------v---------------------------------+ *
234 * |Select Specific Implementation Technologies | *
235 * | ............................. ............................ | *
236 * | .Domain 1 . .Domain 2 . | *
237 * | . Flex-E . . VPN+NFV . | *
238 * | ............................. ............................ | *
239 * +---------------+----------------------------------+----------------+ *
240 * | | *
241 * +---------------v----------------------------------v----------------+ *
242 * |Map to Selected Technologies | *
243 * +---------+------------------------+--------------------+-----------+ *
244 **************************************************************************
245 | | |
246 *********v*********** *********v******** **********v*********
247 * Flex-E Controller * * VPN Controller * * NFV Orchestrator *
248 *********+*********** *********+******** **********+*********
249 | | |
250 *********v*********** *********v********************v*********
251 * Physical/Logical * * Physical/Logical *
252 * Resources inside * * Resources inside *
253 * Domain 1 * * Domain 2 *
254 ********************* ****************************************
256 Figure 2: Advanced Architecture of COMS
258 5. Integration with NFV
260 This section details the integration of the NFV framework [NFV-MANO]
261 in the COMS architecture.
263 Network slice providers aim to accommodate a myriad of use cases and
264 application scenarios from multiple tenants over a common network
265 infrastructure. To that end, network slice providers build up
266 multiple network slice instances (NSIs), each customized to serve the
267 specific service demands of a particular tenant. An NSI is a logical
268 self-contained network instance that network slice providers offer to
269 a tenant, and that a tenant can consume. Although NSIs may span
270 across multiple network segments (e.g., RAN, transport, and core
271 network), this document only considers the transport network domain.
273 NFV may play a key role in network slicing, enabling its realization
274 in a cost-efficient manner. Using the flexibility and virtualization
275 capabilities that the NFV framework brings, a network slice provider
276 can create and operate multiple NSIs over a common shared network
277 infrastructure with isolation guarantees in terms of performance,
278 management, security, and privacy [Ordonez-Network-Slicing]. To
279 provide the tenant with the required performance and functionality,
280 an NSI includes one or more network services, each consisting of a
281 chained set of compassable atomic units called virtualized network
282 functions (VNFs). These VNFs are software-based implementations of
283 network functions that rely on computing, storage, and connectivity
284 resources for their execution and communication. To simultaneously
285 serve the requirements of multiple NSIs, the network slice provider
286 makes use of the resources that are at its disposal, and efficiently
287 orchestrate them across NSIs. Although the network slice provider
288 can own these resources, we consider it rents them from one or more
289 infrastructure owners following the Infrastructure-as-a-Service
290 (IaaS) paradigm. In this case, the network slice provider takes the
291 role of a network infrastructure tenant. Note that each of the three
292 actors presented here (network infrastructure owner, network slice
293 provider, and network slice tenant) defines a different
294 administrative domain.
296 The NSIs shown in Figure 3 run parallel on a common shared transport
297 network infrastructure. The transport network infrastructure
298 consists of connectivity resources that may span across multiple
299 administrative domains (i.e., different network infrastructure
300 owners). These resources include WAN nodes and links providing
301 reachability across geographically remote data centers, where the
302 VNFs from different NSIs run. In particular, they connect together
303 the network connectivity endpoints (e.g., gateways) of those data
304 centers.
306 To simultaneously serve the connectivity needs of the NSIs using
307 resources within its administrative domain, each network
308 infrastructure owner has a WAN Infrastructure Manager (WIM). The WIM
309 is a NFV functional block that performs control-management actions
310 over the underlying connectivity resources to deploy and operate a
311 number of L2/L3 virtual topologies with different levels of
312 abstractions. To enforces the connectivity required by an NSI, the
313 WIM abstracts the resources under its management, and creates a
314 customized virtual topology that logically connects the data centers
315 hosting the NSI's VNFs. The resources of each data center are
316 managed with a Virtual Infrastructure Manager (VIM). This NFV
317 functional block play a similar role to the WIM, but extending their
318 management domain to computing and storage resources.
320 The transport network resources, managed by the underlying network
321 infrastructure owners using their WIMs/VIMs are delivered to the
322 network slice provider logically placed on top of them. The network
323 slice provider makes use of these resources to deploy and operate the
324 NSIs that are under its management. For this end, it may rely on the
325 NFV Orchestrator (NFVO) functionality. According to the NFV
326 framework, NFVO is a functional block with two well-defined
327 functionalities: resource orchestration and network service
328 orchestration. The former focuses on orchestrating network
329 infrastructure resources across multiple VIMs/WIMs, while the latter
330 performs lifecycle management operations (e.g., instantiation,
331 scaling, updating, termination, etc.) over the network service(s)
332 built using those resources. Due to the different scope of these two
333 set of functions, the NFVO may be logically split into two functional
334 blocks: Resource Orchestrator and Network Service Orchestrator.
336 ^ +---------------------------------------------------------+
337 | | Cross-Segment Slice Manager |
338 | +-------------------------^-------------------------------+
339 | |
340 | +-------------------v------------------------+
341 | | Transport Network Slice Orchestrator <------+
342 | +----------------------------------^-----^---+ |
343 | | | |
344 | +------------------------------------ | ----+------+ |
345 | | NSI M | | |
346 | +--------------------------------------- | --------+ | |
347 | | NSI 1 | | | |
348 | +---------------------------+ +---v---+ | | |
349 Network | | Tenant SDN Controller <------> OSS | | | |
350 Slice | +--^-------^--------^----+--+ +---^---+ | | |
351 Provider | | | | | | | | |
352 Domain | +--v--+ +--v--+ | +--v--+ +------v-------+ | | |
353 | | VNF | | VNF | .. | | VNF | | Network | | | |
354 | | +--^--+ +--^--+ | +--^--+ | Service | | | |
355 | | | | | | | Orchestrator | | | |
356 | | | +-----+--------v--+ | +------^-------+ | | |
357 | | +-> vSwitch/vRouter <-+ | |-++ |
358 | | +-----------------+ | | | |
359 | +--------------------------------------- | --------+ | |
360 | | | |
361 | +------------------------------------------v-----------v--+ |
362 + | Resource Orchestrator <-+
363 +--------^-------------------^-------------------^--------+
364 +-------+ | | |
365 +-----v-----+ +-----v-----+ +-----v-----+
366 + | WIM | ... | VIM | ... | WIM |
367 | +-----+-----+ +-----+-----+ +-----+-----+
368 | | |
369 Network +-------+------+ +-----------------+ +------+-------+
370 Infrastructure | Connectivity | | +-------------+ | | Connectivity |
371 Owner | Resources | | | Computing/ | | | Resources |
372 Domain +--------------+ | | Storage/ | | +--------------+
373 | |Connectivity | |
374 | | | Resources | |
375 | | +-------------+ |
376 | | Data Center |
377 v +-----------------+
379 Figure 3: Integration of NFV framework in COMS architecture
381 To orchestrate the resources that are at its disposal (those provided
382 by the underlying network infrastructure owners), the network slice
383 provider has a single Resource Orchestrator. The main role of the
384 Resource Orchestrator is to dispatch this finite set of resources
385 across the operative NSIs in an optimal way, with the aim of
386 simultaneously satisfying their (potentially diverging) performance
387 requirements. To bring multiplexing gains and cost savings in this
388 task, the Resource Orchestrator may take advantage of resource
389 sharing. Resource sharing introduces flexibility and efficiency in
390 slice provisioning, as network slice provider's resources can be
391 dynamically allocated and released across NSIs according to the time-
392 varying resource requirements that their tenants impose. This
393 approach requires an adequate resource management framework for the
394 Resource Orchestrator that carefully finds an optimal solution,
395 enabling resource sharing among NSIs when necessary, while preserving
396 their performance isolation.
398 As shown in Figure 3, each of the operative NSIs serving a network
399 slice tenant comprises a tenant SDN controller, a Network Service
400 Orchestrator, and an Operation Support System (OSS). On the one
401 hand, the tenant SDN controller configures the VNFs at application
402 level, and chains them to dynamically build up the network service(s)
403 that are required in the NSI. For VNF configuration management, the
404 tenant SDN controller uses southbound configuration protocols such as
405 NETCONF. For VNF chaining management, it leverages the networking
406 capabilities provided by virtual switches/routers, sending them
407 appropriate forwarding instructions using southbound control
408 protocols such as OpenFlow. On the other hand, the Network Service
409 Orchestrator manages the lifecycle of the network service(s).
410 Finally, the OSS performs the intra-NSI management, bridging the gap
411 between the Network Service Orchestrator and the tenant SDN
412 controller, and coordinating their operations and management data.
413 The OSS is also the entry point of the NSI, providing management
414 capability exposure to external blocks. By way of example, the
415 network slice tenant can use the OSS to gain access to the NSI and
416 operate it at its convenience.
418 The description given above focuses on run-time phase, assuming the
419 NSIs are operative, and omitting the deployment steps referred in
420 Section 1. To trigger the deployment of a network slice, the network
421 slice provider needs other functional blocks. These functional
422 blocks include a Cross-Segment Slice Manager, and one or more Network
423 Slice Domain Orchestrators. The Cross-Segment Slice Manager receives
424 a network slice service profile from the tenant. This profile
425 contains the (end-to-end) slice requirements. The Cross-Segment
426 Slice Manager decompose these requirements into one or more network
427 slice domain slice requirements, and send them to the respective
428 Network Slice Domain Orchestrators (e.g., RAN Slice Orchestrator,
429 Transport Network Slice Orchestrator, Core Network Slice
430 Orchestrator). Since the architecture discussed in this document is
431 assumed to be inside the transport network domain, we only consider
432 the Network Slice Transport Orchestrator. The Network Slice
433 Transport Orchestrator uses the network slice transport requirements
434 to determine which VNFs and network service(s) are required, and what
435 are their resource requirements. Once checked the Resource
436 Orchestrator can provision them, the steps for deploying the slice
437 begin. First, the Resource Orchestrator creates the resource slice.
438 Then, the OSS takes over the resource slice and configures it,
439 resulting in a networking slice. Finally, the OSS (assisted by the
440 Network Service Orchestrator and the Tenant SDN controller),
441 instantiates one or more network services (and their constituent
442 VNFs) over this networking slice to realize a service slice, making
443 it usable for the network slice tenant.
445 6. Security Considerations
447 There is no security problems introduced by this document.
449 7. IANA Considerations
451 There is no IANA action required by this document.
453 8. Acknowledgements
455 TBD
457 9. Informative References
459 [COMS-PS] "Problem Statement of Supervised Heterogeneous Network
460 Slicing", .
463 [draft-arkko-arch-virtualization]
464 "Considerations on Network Virtualization and Slicing",
465 .
468 [I-D.boucadair-connectivity-provisioning-protocol]
469 Boucadair, M., Jacquenet, C., Zhang, D., and P.
470 Georgatsos, "Connectivity Provisioning Negotiation
471 Protocol (CPNP)", draft-boucadair-connectivity-
472 provisioning-protocol-15 (work in progress), December
473 2017.
475 [NFV-MANO]
476 ETSI GS NFV-MAN 001, "Network Functions Virtualisation
477 (NFV); Virtual Network Functions Architecture", V1.1.1,
478 December 2014.
480 [Ordonez-Network-Slicing]
481 Ordonez-Lucena, J., Ameigeiras, P., Lopez, D., Ramos-
482 Munoz, J., Lorca, J., and J. Folgueira, "Network Slicing
483 for 5G with SDN/NFV: Concepts, Architectures, and
484 Challenges", IEEE Communications Magazine, vol. 55, no. 5,
485 pp. 80-87, May 2017.
487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
488 Requirement Levels", BCP 14, RFC 2119,
489 DOI 10.17487/RFC2119, March 1997,
490 .
492 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
493 Element (PCE) Communication Protocol (PCEP)", RFC 5440,
494 DOI 10.17487/RFC5440, March 2009,
495 .
497 [Stitching-Data]
498 "Gateway Function for Network Slicing",
499 .
502 [Stitching-Management]
503 "Interconnecting (or Stitching) Network Slice Subnets",
504 .
507 Authors' Addresses
509 Liang Geng
510 China Mobile
512 Email: gengliang@chinamobile.com
514 Li Qiang
515 Huawei
517 Email: qiangli3@huawei.com
519 Jose Ordonez Lucena
520 University of Granada
522 Email: jordonez@ugr.es
523 Oscar Adamuz Hinojosa
524 University of Granada
526 Email: oadamuz@ugr.es
528 Pablo Ameigeiras
529 University of Granada
531 Email: pameigeiras@ugr.es
533 Diego Lopez
534 Telefonica I+D
536 Email: diego.r.lopez@telefonica.com
538 Luis Miguel Contreras Murillo
539 Telefonica
541 Email: luismiguel.contrerasmurillo@telefonica.com