idnits 2.17.1
draft-pentikousis-supa-mapping-05.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 document has examples using IPv4 documentation addresses according
to RFC6890, but does not use any IPv6 documentation addresses. Maybe
there should be IPv6 examples, too?
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 has text resembling
RFC 2119 boilerplate text.
-- The document date (May 11, 2015) is 3273 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'I-D.lhotka-netmod-routing-cfg' is defined on line
621, but no explicit reference was found in the text
== Unused Reference: 'I-D.strassner-supa-generic-policy-info-model' is
defined on line 626, but no explicit reference was found in the text
== Outdated reference: A later version (-02) exists of
draft-bi-supa-policy-model-01
== Outdated reference: A later version (-03) exists of
draft-contreras-supa-yang-network-topo-02
== Outdated reference: A later version (-05) exists of
draft-strassner-supa-generic-policy-info-model-00
== Outdated reference: A later version (-02) exists of
draft-zhou-supa-framework-00
Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group K. Pentikousis
3 Internet-Draft EICT GmbH
4 Intended status: Informational D. Zhang
5 Expires: November 12, 2015 May 11, 2015
7 Simplified Use of Policy Abstractions (SUPA): Configuration and Policy
8 Mapping
9 draft-pentikousis-supa-mapping-05
11 Abstract
13 Nowadays, the underlying network infrastructure grows in scale and
14 complexity, which make it challenging for network operators to manage
15 and configure the network. Deploying policy or configuration based
16 on an abstract view of the underlying network is much better than
17 manipulating each individual network element, however, in this case,
18 the policy and configuration cannot be recognized by the network
19 elements. This document describes guidelines for mapping said
20 abstract configuration and policy into device-level configuration and
21 the way in which such models will be processed by software to produce
22 configuration details for actual devices. The Simplified Use of
23 Policy Abstractions (SUPA) framework overview, exemplary mechanism
24 for exchanging service polices among the different elements
25 participating in their deployment and enforcement, and primary
26 procedures of mapping are described. Moreover, an exemplary mapping
27 scenario is provided to illustrate the defined mechanism.
29 Status of This Memo
31 This Internet-Draft is submitted in full conformance with the
32 provisions of BCP 78 and BCP 79.
34 Internet-Drafts are working documents of the Internet Engineering
35 Task Force (IETF). Note that other groups may also distribute
36 working documents as Internet-Drafts. The list of current Internet-
37 Drafts is at http://datatracker.ietf.org/drafts/current/.
39 Internet-Drafts are draft documents valid for a maximum of six months
40 and may be updated, replaced, or obsoleted by other documents at any
41 time. It is inappropriate to use Internet-Drafts as reference
42 material or to cite them other than as "work in progress."
44 This Internet-Draft will expire on November 12, 2015.
46 Copyright Notice
48 Copyright (c) 2015 IETF Trust and the persons identified as the
49 document authors. All rights reserved.
51 This document is subject to BCP 78 and the IETF Trust's Legal
52 Provisions Relating to IETF Documents
53 (http://trustee.ietf.org/license-info) in effect on the date of
54 publication of this document. Please review these documents
55 carefully, as they describe your rights and restrictions with respect
56 to this document. Code Components extracted from this document must
57 include Simplified BSD License text as described in Section 4.e of
58 the Trust Legal Provisions and are provided without warranty as
59 described in the Simplified BSD License.
61 Table of Contents
63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
66 4. Configuration and Policy Mapping . . . . . . . . . . . . . . 3
67 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
68 4.2. Mapping Procedure . . . . . . . . . . . . . . . . . . . . 5
69 4.3. SUPA Mapping Example . . . . . . . . . . . . . . . . . . 7
70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
74 8.1. Normative References . . . . . . . . . . . . . . . . . . 14
75 8.2. informative References . . . . . . . . . . . . . . . . . 14
76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
78 1. Introduction
80 As the underlying network infrastructure grows, new services are
81 introduced, and traffic volumes increase rapidly, it becomes
82 significantly more challenging and complicated to maintain the
83 network and deploy new services than in the past. Configuration
84 automation can provide significant benefits in deployment agility.
85 Simplified Use of Policy Abstractions (SUPA)
86 [I-D.zhou-supa-framework] aims to improve configuration automation by
87 introducing multi-level abstractions. In SUPA, a generic policy
88 information model [I-D.strassner-supa-generic-policy-info-model]is
89 defined, which defines a generic framework for representing policy
90 rules of any type, with this model, SUPA is capable to define a
91 common framework for representing different types of policies,
92 although the syntax and semantics of these policies are very
93 different. Based on the generic policy model, several policy data
94 models are defined to express different manners of policy
95 enforcement, such as ECA and intent-based polices. The information
96 models of various network services is also utilized in SUPA to allow
97 network operators to manipulate their infrastructure as a whole
98 rather than individual devices. Well-designed abstractions are able
99 to provide a wide range of granularity for various applications
100 needs. However, these information models cannot be directly utilized
101 by network elements, thus a mapping mechanism is necessary to bridge
102 the gap between these information models and network element-
103 recognized configuration.
105 SUPA employs Network Manager/Controller. Network Manager/Controllers
106 represent one or more entities that are able to control the operation
107 and management of a network infrastructure and mediate between the
108 Service Management and the network elements to provide, maintain and
109 deploy network services and policies. Each Network Manager/
110 Controller supports the SUPA interface/protocol and is a software
111 repository, which stores the information associated with each network
112 element. The mapping mechanism could be part of the Network Manager/
113 Controller implementation in order to map the SUPA model(s) into
114 specified configuration models (or so-called southbound interfaces),
115 which can be recognized by the network element(s).
117 2. Requirements Language
119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "Network Manager/Controller",
121 and "OPTIONAL" in this document are to be interpreted as described in
122 [RFC2119].
124 3. Terminology
126 This document uses the following terms:
128 Network element (NE): a physical or virtual entity that can be
129 locally managed and operated
131 SUPA: Simplified Use of Policy Abstractions
133 4. Configuration and Policy Mapping
135 This section introduces a framework for mapping configuration and
136 policy in the context of a network with several network elements and
137 one or more Service Managements.
139 4.1. Overview
141 The SUPA framework for mapping network-level configuration into
142 specific network management and controlling policies is illustrated
143 in Figure 1. It consists of i) Service Management, ii) Network
144 Manager/Controller and iii) NEs.
146 +------------------------+ -------------------------
147 | Service Management | |
148 | +--------------------+ | |
149 | | Policy | | |
150 | +--------------------+ | |
151 | +--------------------+ | |
152 | | Service Management | | |
153 | | | | |
154 | +--------------------+ | |
155 +------------------------+ |
156 | NetConf/RestConf |
157 | Network
158 +-----------------v--------------+ Level
159 | +------------------------+ | |
160 | | Network Resource | | |
161 | | | | |
162 | +------------------------+ | |
163 | Network | |
164 | Management/Controller -------------------------
165 | +-----------------+ | |
166 | |protocol-specific| | |
167 | | configuration | | |
168 | +-----------------+ | |
169 +-----------------^--------------+ Device
170 | Level
171 +-----------------+--------------------+ |
172 CLI/I2RS | | CLI/I2RS |
173 | | |
174 | | |
175 +---------------+ +---------------+ |
176 | | | | |
177 | NE | ... | NE | |
178 | | | | |
179 +---------------+ +---------------+----------
181 Figure 1: SUPA configuration and policy mapping overview
183 Service Management manages and programs the underlying network
184 elements indirectly based on the abstract view of the network
185 infrastructure. In practice, this means that Service Management can,
186 among others, configure the underlying network as a whole rather than
187 as a set of individual network elements. As a result, the diversity
188 of the actual network elements in active operation is abstracted,
189 which allows Service Management to manage and program the network in
190 a simpler, more maintainable and efficient manner. On the other end
191 of the spectrum, the NEs can continue their regular operation without
192 having to become cognizant of the fact that configuration is applied
193 at the network level.
195 In order to bridge the gap between configuration set by Service
196 Management and that required by the NEs, the Network Management and
197 Network Manager/Controller has to provide a mapping mechanism which
198 translates the configuration settings with high level of abstractions
199 to device-level configurations. This document considers three
200 modules in the SUPA framework to support such a mapping mechanism, as
201 follows.
203 First, a network resource module maintains the resource of the
204 infrastructure, such as topology of the network. It provides the
205 information of the resource, which maybe with high level of
206 abstraction to Service Management for management, and it also
207 provides the necessary information of each network element, which
208 with low level of abstraction, when mapping configuration from the
209 network-level to device-level. Second, the service management and
210 policy module, which is responsible for transmitting (send/receive)
211 and process the network-level configuration. Third, the protocol-
212 specific configuration produces the output of the mapping mechanism
213 and is responsible for distributing the device- level configuration
214 to the corresponding network elements.
216 In this framework, one would expect the introduction and use of
217 algorithms/strategies for specific network services which can
218 automatically generate device-level configuration based on the
219 Service Management policies/configurations. Note, however, that said
220 algorithms and strategies are out of the scope of this document.
222 4.2. Mapping Procedure
224 From the view point of Service Management:
226 Firstly, the operators or network administrators use a policy editor
227 GUI to generates a set of policies based on application requirements,
228 and sends these policies to the service management. It should be
229 noted that, the policies here maybe generated with different views,
230 such as business view and system view, for different users, however,
231 these polices and the interfaces between the application and the
232 Service Management are out of the scope of SUPA.
234 Secondly, in the Service Management, based on the generic policy
235 information model the policies generated in the previous step are
236 translated into the policy data models defined in SUPA. And then,
237 policy conflict analysis may be processed to verify the new policy
238 won't conflict the predefined policies.
240 Thirdly, if the new policy is valid, Service Management begin to
241 enforce this policy, in this step, it needs some context of the
242 underlying network if necessary, especially the infrastructure
243 (physical or logical) of the network, before it deploys a policy/
244 service to the network. For example, if Service Management attempts
245 to steer traffic from one path to another, it should have the
246 information of the existing paths first. Service Management requests
247 this context information from the network resource block of Network
248 Manager/Controller. This procedure does not have to be processed
249 every time Service Management deploys a policy/service.
251 Fourthly, service Management can obtain the current status of the
252 service, which will be affected by the new policy, for reference
253 before it deploys a new policy. In such a case, Service Management
254 sends a "GET" request to the Network Manager/Controller, and the
255 Network Manager/Controller encapsulates this information with the
256 models specified by SUPA network service models.
258 Thirdly, Based on the service and policy configuration, and also
259 service/network status if necessary, Service Management deploys the
260 action of the policy by sending a "POST" request to the Network
261 Manager/Controller.
263 From the view point of Network Manager/Controller:
265 Firstly, the Network Manager/Controller is responsible for
266 maintaining the infrastructure information, and it provides
267 information to Service Managements with the network resource models,
268 such as topology information model.
270 Secondly, once the Network Manager/Controller receives actions of a
271 policy from Service Managements, it maps these actions to protocol-
272 specific models. The intelligence/algorithms of how to do the
273 mapping is implementation-specific and out of the scope of this
274 specification, as are the protocol-specific models.
276 Thirdly, with the protocol-specific models, the device-level
277 configurations for heterogeneous devices can be generated and
278 conveyed by the Network Manager/Controller using, for example,
280 [RFC6020], [I-D.bierman-netconf-restconf],
281 [I-D.atlas-i2rs-architecture] and CLI, to the corresponding NEs.
283 4.3. SUPA Mapping Example
285 +-----------------------+
286 | +---------+ |
287 | |TE Policy| |
288 | +---------+ |
289 | Service Management |
290 +----------^------------+
291 |
292 | NETCONF/RESTCONF
293 |
294 +--------------v---------------+
295 | |
296 | Network Manager/Controller |
297 | |
298 +--------------^---- ----------+
299 | CLI/I2RS/NETCONF
300 |
301 +----------------v--------------------+
302 | |
304 192.0.2.1 192.0.2.2
305 +------+ +------+ +------+
306 | A +----------+ C +------------+ B +-----+
307 +-+--+-+ +------+ +---+--+ |
308 | | 192.0.2.3 | |
309 ++ | | |
310 | | | +---+--+
311 | | | | G |
312 +---+--+| | +---+--+
313 | F || | |
314 +------+| +--+---+ +---+--+ |
315 +-------+ D +-----------------+ E +-----+
316 +------+ +------+
317 192.0.2.4 192.0.2.5
319 Figure 2: Bandwidth use optimization for DC Interconnection
321 Figure 2 illustrates a simple example in which interoperability
322 between Service Management and Network Manager/Controller in an
323 inter-data center (inter-DC) environment is considered.
325 For the purposes of this example, let us focus on the dynamic
326 configuration of the IP path between the seven illustrated DCs,
327 labeled A, B, C, D, E, F and G, based on the policies. First of all,
328 we would like the IP path to be created based on certain constraints.
329 Secondly, we would like to map it to the device-level connections.
330 In this scenario, there are two paths from DC A to DC B. Typical IP
331 shortest-path routing would choose path A(192.0.2.1)-C(192.0.2.3) >
332 B(192.0.2.2). However, under certain conditions, such as, for
333 instance, when the bandwidth utiliaztion between A and B is beyond 80
334 percents, the Service Management can decide that is better to steer
335 traffic from path (A, C, B) to a new path which goes through a
336 specific node. This is a policy from business view, and it can be
337 expressed by the ECA policy data model defined in
338 [I-D.bi-supa-policy-model] but in this example, how this policy
339 translated into the ECA policy is not provided, because it is too
340 dependant on the implementation.
342 Figure 2 depicts the layer 3 topology of the underlying network.
344 First, Service Management needs some information about A, B, C, D and
345 the links between them. This information can be obtained from
346 Network Manager/Controller, and it is listed in the fragment below.
347 This information is derived from the Topology YANG model described in
348 [I-D.contreras-supa-yang-network-topo].
350
351
352 1111111100000000
353 mapping_topo
354 ip
355
356
357
358 192.0.2.1
359 A
360 physical
361 adminUp
362 up
363 1111111100000000
364
365
366 192.0.2.2
367 B
368 physical
369 adminUp
370 up
371 1111111100000000
372
374 ... skip ...
376
377 192.0.2.3
378 C
379 physical
380 adminUp
381 up
382 1111111100000000
383
384
385
386
387 1
388 A2C
389 telink
390 bidrectional
391 adminUp
392 up
393 192.0.2.1
394 192.0.2.3
395 1111111100000000
396
397 2000
398
399
401 ... skip ...
403
404 2
405 C2B
406 telink
407 bidrectional
408 adminUp
409 up
410 192.0.2.3
411 192.0.2.2
412 1111111100000000
413
414 50000
415
416
417
418
420 Figure 3: Information of the underlying network
422 Secondly, Service Management defines the policy using policy policy
423 models defined in SUPA, and then sends the steering information
424 derived from service and policy information to Network Manager/
425 Controller using a protocol such as [RFC6020], and
426 [I-D.bierman-netconf-restconf]. Figure 4 presents the policy for
427 traffic steering: the traffic (supaflow) with destination IP address
428 192.0.2.11/24 needs to be steered to DC B, the new path must go
429 through DC D. This configuration is derived from the YANG model
430 described in [I-D.bi-supa-policy-model]. An example of the steering
431 information is list in Figure 5, it specfies the traffic flow which
432 will be steered, and the constrains of the new path.
434
435
436
437 supa_vpn
438 L3VPN
439 supa_flow
440
441
442 4
443
444
445 3
446
447
448
449 bandwidth
450
451
452
453
454 utilization
455
456
457 above
458
459
460 80
461
462
463
464
465
466 192.0.2.4
467
468 pass
469
470
471
472
473
474
475
476
478 Figure 4: Example traffic steering policy
480
481 supa_flow
482 10000
483
484
485 192.0.2.0
486 24
487
488
489
490
491 path_1
492 auto
493
494
495 192.0.2.1
496 ingress
497 1
498
499
500 192.0.2.5
501 transit
502 2
503
504
505 192.0.2.2
506 egress
507 3
508
509
510
511
512
514 Figure 5: Example traffic steering information
516 Based on the steering information, the Network Manager/Controller
517 generates a path which meets the requirements: in this example, the
518 computed path is (A, D, E, B). Network Manager/Controller also has
519 to configure each device on the new path, not only the devices
520 specified by the configuration such as node D, but also the devices
521 in the underlying network which must be reconfigured, such as node E.
522 The topology information is also necessary when Network Manager/
523 Controller decides which device ought to be configured.
525 With the assistance of other information in Network Manager/
526 Controller, such as topology information, service/policy
527 configuration can be translated into protocol-specific yang models
528 (or southbound interface) first. Taking node D as an example, the
529 configuration expressed in the YANG model defined in
530 [I-D.lhotka-netmod-routing-cfg]could be as follows:
532
533
534 rtr0
535 Router D
536
537
538 rt:static
539 st0
540
541 Static routing is used for the internal network.
542
543
544
545
546
547 192.0.2.0/24
548
549
550
551 192.0.2.5
552
553
554
555
556
557
558
559
560
562 Figure 6: Example traffic steering requirements
564 The configuration of other nodes is similar. Based on this vendor-
565 neutral device-level configuration and the features of each NE, the
566 NE-specific configuration can be generated. Once nodes A, C, D and E
567 have received their respective NE-specific configurations, the
568 device-level configuration could be deployed and then, the traffic is
569 steered as Service Management specified.
571 5. Security Considerations
573 Security considerations will be discussed in an upcoming revision of
574 this document.
576 6. IANA Considerations
578 TBD
580 7. Acknowledgements
582 This document has benefited comments, suggestions, and proposed text
583 provided by Cathy Zhou and Will Liu (listed in alphabetical order).
584 Junru Lin and Zhayiyong contributed to an earlier version of this
585 draft.
587 8. References
589 8.1. Normative References
591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
592 Requirement Levels", BCP 14, RFC 2119, March 1997.
594 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
595 Network Configuration Protocol (NETCONF)", RFC 6020,
596 October 2010.
598 8.2. informative References
600 [I-D.atlas-i2rs-architecture]
601 Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
602 Nadeau, "An Architecture for the Interface to the Routing
603 System", draft-atlas-i2rs-architecture-02 (work in
604 progress), August 2013.
606 [I-D.bi-supa-policy-model]
607 Bi, J., Tadepalli, R., and M. Hayashi, "DDC Service Policy
608 YANG Data Model", draft-bi-supa-policy-model-01 (work in
609 progress), March 2015.
611 [I-D.bierman-netconf-restconf]
612 Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando,
613 "RESTCONF Protocol", draft-bierman-netconf-restconf-04
614 (work in progress), February 2014.
616 [I-D.contreras-supa-yang-network-topo]
617 Contreras, L., Qu, A., and Y. Zha, "A YANG Data Model for
618 Network Topologies", draft-contreras-supa-yang-network-
619 topo-02 (work in progress), January 2015.
621 [I-D.lhotka-netmod-routing-cfg]
622 Lhotka, L., "A YANG Data Model for Routing Configuration",
623 draft-lhotka-netmod-routing-cfg-00 (work in progress),
624 March 2011.
626 [I-D.strassner-supa-generic-policy-info-model]
627 Strassner, J., "Generic Policy Model for Simplified Use of
628 Policy Abstractions (SUPA)", draft-strassner-supa-generic-
629 policy-info-model-00 (work in progress), April 2015.
631 [I-D.zhou-supa-framework]
632 Zhou, C., Contreras, L., Qiong, Q., and P. Yegani, "The
633 Framework of Shared Unified Policy Automation (SUPA)",
634 draft-zhou-supa-framework-00 (work in progress), January
635 2015.
637 Authors' Addresses
639 Kostas Pentikousis
640 EICT GmbH
641 Torgauer Strasse 12-15
642 Berlin 10829
643 Germany
645 Email: k.pentikousis@eict.de
647 Dacheng Zhang
648 Chaoyang Dist
649 Beijing 100000
650 P.R. China
652 Email: Dacheng.zhang@gmail.com