--- 1/draft-ietf-teas-actn-framework-06.txt 2017-07-20 03:13:57.978619345 -0700 +++ 2/draft-ietf-teas-actn-framework-07.txt 2017-07-20 03:13:58.070621538 -0700 @@ -1,20 +1,20 @@ TEAS Working Group Daniele Ceccarelli (Ed) Internet Draft Ericsson Intended status: Informational Young Lee (Ed) -Expires: December 2017 Huawei +Expires: January 19, 2018 Huawei - June 13, 2017 + July 20, 2017 Framework for Abstraction and Control of Traffic Engineered Networks - draft-ietf-teas-actn-framework-06 + draft-ietf-teas-actn-framework-07 Abstract Traffic Engineered networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. @@ -40,21 +40,21 @@ Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on December 13, 2017. + This Internet-Draft will expire on January 19, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -62,65 +62,72 @@ respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................3 1.1. Terminology...............................................5 2. Business Model of ACTN.........................................9 - 2.1. Customers.................................................9 + 2.1. Customers................................................10 2.2. Service Providers........................................10 2.3. Network Providers........................................12 3. Virtual Network Service.......................................12 4. ACTN Base Architecture........................................13 4.1. Customer Network Controller..............................15 4.2. Multi Domain Service Coordinator.........................16 4.3. Physical Network Controller..............................17 4.4. ACTN Interfaces..........................................17 5. Advanced ACTN architectures...................................18 5.1. MDSC Hierarchy for scalability...........................18 5.2. Functional Split of MDSC Functions in Orchestrators......19 6. Topology Abstraction Method...................................21 - 6.1. No abstraction (native/white topology)...................22 - 6.2. One Virtual Node (black topology)........................23 - 6.3. Abstraction of TE tunnels for all pairs of border nodes - (grey topology)...............................................24 - 6.3.1. Grey topology type A: border nodes with a TE links - between them in a full mesh fashion........................25 - 6.3.2. Grey topology Type B................................25 - 6.4. Topology Abstraction Granularity Level example...........25 - 7. Access Points and Virtual Network Access Points...............27 - 7.1. Dual homing scenario.....................................29 - 8. Advanced ACTN Application: Multi-Destination Service..........30 - 8.1. Pre-Planned End Point Migration..........................31 - 8.2. On the Fly End Point Migration...........................32 - 9. Advanced Topic................................................32 - 10. Manageability Considerations.................................32 - 10.1. Policy..................................................33 - 10.2. Policy applied to the Customer Network Controller.......34 - 10.3. Policy applied to the Multi Domain Service Coordinator..34 - 10.4. Policy applied to the Physical Network Controller.......34 - 11. Security Considerations......................................35 + 6.1. Abstraction Factors......................................22 + 6.2. Abstraction Types........................................23 + 6.2.1. Native/White Topology...............................23 + 6.2.2. Black Topology......................................24 + 6.2.3. Grey Topology.......................................25 + + 6.3. Building Methods of Grey Topology........................27 + 6.3.1. Automatic generation of abstract topology by + configuration..............................................27 + 6.3.2. On-demand generation of supplementary topology via path + compute request/reply......................................28 + 6.4. Abstraction Configuration Consideration..................29 + 6.4.1. Packet Networks.....................................29 + 6.4.2. OTN Networks........................................29 + 6.4.3. WSON Networks.......................................30 + 6.5. Topology Abstraction Granularity Level example...........30 + 7. Access Points and Virtual Network Access Points...............32 + 7.1. Dual homing scenario.....................................34 + 8. Advanced ACTN Application: Multi-Destination Service..........35 + 8.1. Pre-Planned End Point Migration..........................36 + 8.2. On the Fly End Point Migration...........................37 + 9. Advanced Topic................................................37 + 10. Manageability Considerations.................................37 + 10.1. Policy..................................................38 + 10.2. Policy applied to the Customer Network Controller.......39 + 10.3. Policy applied to the Multi Domain Service Coordinator..39 + 10.4. Policy applied to the Physical Network Controller.......39 + 11. Security Considerations......................................40 11.1. Interface between the Customer Network Controller and Multi - Domain Service Coordinator (MDSC), CNC-MDSC Interface (CMI)...36 + Domain Service Coordinator (MDSC), CNC-MDSC Interface (CMI)...41 11.2. Interface between the Multi Domain Service Coordinator and - Physical Network Controller (PNC), MDSC-PNC Interface (MPI)...36 - 12. References...................................................37 - 12.1. Informative References..................................37 - 13. Contributors.................................................38 - Authors' Addresses...............................................39 + Physical Network Controller (PNC), MDSC-PNC Interface (MPI)...41 + 12. References...................................................42 + 12.1. Informative References..................................42 + 13. Contributors.................................................43 + Authors' Addresses...............................................44 APPENDIX A - Example of MDSC and PNC functions integrated in - Service/Network Orchestrator.....................................40 - APPENDIX B - Example of IP + Optical network with L3VPN service..40 - APPENDIX C - Example of ODU service connectivity................41 + Service/Network Orchestrator.....................................45 + APPENDIX B - Example of IP + Optical network with L3VPN service..45 1. Introduction Traffic Engineered networks have a variety of mechanisms to facilitate separation of data plane and control plane including distributed signaling for path setup and protection, centralized path computation for planning and traffic engineering, and a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. @@ -890,64 +895,132 @@ in [Service-YANG]. The MPI is a subset of network configuration model to support TE configuration. This model encompasses the MPI model plus other non-TE/non-ACTN models to control non-ACTN functions of the domain controller (e.g., L3VPN). Device configuration model is used by a controller to configure physical network elements. 6. Topology Abstraction Method - This section discusses topology abstraction types and their context - in ACTN architecture. Topology abstraction is useful in ACTN - architecture as a way to scale multi-domain network operation. As - the MDSC needs to coordinate with the PNCs in multi-domain networks - for determining a feasible domain sequence and provisioning the end- - to-end tunnel based on the determined domain sequence, topology - abstraction provides an efficient network scaling mechanism. Note + This section discusses topology abstraction factors, types and their + context in ACTN architecture. Topology abstraction is useful in ACTN + architecture as a way to scale multi-domain network operation. Note that this is the abstraction performed by the PNC to the MDSC or by the MDSC-L to the MDSC-H, and that this is different from the VN Type 2 topology (that is created and negotiated between the CNC and the MDSC as part of the VNS). The purpose of topology abstraction discussed in this section is for an efficient internal network operation based on abstraction principle. - Refer to [ACTN-Abstraction] for detailed discussions on factors that - affect topology abstraction, how to build topology abstraction, - various considerations and which method to pick based on abstraction - types and the nature of underlying transport technology (e.g., MPLS, - OTN, WSON, etc.). +6.1. Abstraction Factors -6.1. No abstraction (native/white topology) + This section provides abstraction factors in the ACTN architecture. + + The MDSC oversees the specific aspects of the different domains and + builds a single abstracted end-to-end network topology in order to + coordinate end-to-end path computation and path/service + provisioning. In order for the MDSC to perform its coordination + function, it depends on the coordination with the PNCs which are the + domain-level controllers especially as to what level of domain + network resource abstraction is agreed upon between the MDSC and the + PNCs. + + As discussed in [RFC7926], abstraction is tied with policy of the + networks. For instance, per an operational policy, the PNC would not + be allowed to provide any technology specific details (e.g., optical + parameters for WSON) in its update. In such case, the abstraction + level of the update will be in a generic nature. In order for the + MDSC to get technology specific topology information from the PNC, a + request/reply mechanism may be employed. + + In some cases, abstraction is also tied with the controller's + capability of abstraction as it involves some rules and algorithms + to be applied to the actual network resource information (which is + also known as network topology). + + [TE-Topology] describes YANG models for TE-network abstraction. + [PCEP-LS] describes PCEP Link-state mechanism that also allows for + transport of abstract topology in the context of Hierarchical PCE. + + There are factors that may impact the choice of abstraction. Here + are the most relevant: + + - The nature of underlying domain networks: Abstraction depends on + the nature of the underlying domain networks. For instance, packet + networks may have different level of abstraction requirements from + that of optical networks. Within optical networks, WSON may have + different level of abstraction requirements than the OTN networks. + + - The capability of the PNC: Abstraction depends on the capability + of the PNCs. As abstraction requires hiding details of the + underlying resource network resource information, the PNC + capability to run some internal optimization algorithm impacts the + feasibility of abstraction. Some PNC may not have the ability to + abstract native topology while other PNCs may have such an ability + to abstract actual topology by using sophisticated algorithms. + + - Scalability factor: Abstraction is a function of scalability. If + the actual network resource information is of small size, then the + need for abstraction would be less than the case where the native + network resource information is of large size. In some cases, + abstraction may not be needed at all. + + - The frequency of topology updates: The proper abstraction level + may depend on the frequency of topology updates and vice versa. + + - The capability/nature of the MDSC: The nature of the MDSC impacts + the degree/level of abstraction. If the MDSC is not capable of + handling optical parameters such as those specific to OTN/WSON, + then white topology abstraction may not work well. + + - The confidentiality: In some cases where the PNC would like to + hide key internal topological data from the MDSC, the abstraction + method should consider this aspect. + + - The scope of abstraction: All of the aforementioned factors are + equally applicable to both the MPI (MDSC-PNC Interface) and the + CMI (CNC-MDSC Interface). + +6.2. Abstraction Types + + This section defines the following three types of topology + abstraction: + + . Native/White Topology (Section 6.2.1) + . Black Topology (Section 6.2.2) + . Grey Topology (Section 6.2.3) + +6.2.1. Native/White Topology This is a case where the PNC provides the actual network topology to the MDSC without any hiding or filtering of information as shown in - Figure 6. In this case, the MDSC has the full knowledge of the + Figure 6a. In this case, the MDSC has the full knowledge of the underlying network topology and as such there is no need for the MDSC to send a path computation request to the PNC. The computation burden will fall on the MDSC to find an optimal end-to-end path and optimal per domain paths. +--+ +--+ +--+ +--+ +-+ +-----+ +-----+ +-----+ +-+ ++-+ ++-+ +-++ +-++ | | | | | | | | | | | | | | | | ++-+ ++-+ +-++ +-++ +-+ +-----+ +-----+ +-----+ +-+ +--+ +--+ +--+ +--+ Figure 6a: The native/white topology -6.2. One Virtual Node (black topology) +6.2.2. Black Topology The entire domain network is abstracted as a single virtual node (see the definition of virtual node in [RFC7926]) with the access/egress links without disclosing any node internal connectivity information. Figure 6b depicts a native topology with the corresponding black topology with one virtual node and inter-domain links. In this case, the MDSC has to make path computation requests to the PNCs before it can determine an end-to-end path. If there are a large number of inter-connected domains, this abstraction method may impose a heavy @@ -976,32 +1050,29 @@ | | | | | | | | +--+ +--+ +--------+ Figure 6b: The native topology and the corresponding black topology with one virtual node and inter-domain links -6.3. Abstraction of TE tunnels for all pairs of border nodes (grey - topology) +6.2.3. Grey Topology - This abstraction level, referred to a grey topology is between black - topology and white topology from a granularity point of view. As - shown in Figures 7a and 7b, we may further differentiate from a - perspective of how to abstract internal TE resources between the - pairs of border nodes: + This abstraction level, referred to a grey topology, represents a + compromise between black and white topology from a granularity point + of view. As shown in Figures 7a and 7b, we may further differentiate + from a perspective of how to abstract internal TE resources between + the pairs of border nodes: . Grey topology type A: border nodes with a TE links between them - in a full mesh fashion (See Figure 7a) - . Grey topology type B: border nodes with some internal - abstracted nodes and abstracted links (See Figure 7b) + in a full mesh fashion (See Figure 7a). +--+ +--+ +--+ +--+ +-+ +-----+ +-----+ +-----+ +-+ ++-+ ++-+ +-++ +-++ | | | | | | | | | | | | | | | | ++-+ ++-+ +-++ +-++ +-+ +-----+ +-----+ +-----+ +-+ @@ -1014,58 +1085,211 @@ | \/ | | /\ | | / \ | ++-+ +-++ +-+ +----+ +-+ +--+ +--+ Figure 7a: The native topology and the corresponding grey topology type A with TE links between border nodes + For each pair of ingress and egress nodes (i.e., border nodes + to/from the domain), TE link metric is provided with TE attributes + such as max bandwidth available, link delay, etc. This abstraction + depends on the underlying TE networks. + Note that this grey topology can also be represented as a single + abstract node with the connectivity matrix defined in [TE-Topology], + abstracting the internal connectivity information. The only thing + might be different is some additional information about the end + points of the links of the border nodes (i.e., links outward + customer-facing) as they cannot be included in the connectivity + matrix's termination points. + + . Grey topology type B: border nodes with some internal + abstracted nodes and abstracted links (See Figure 7b) +--+ +--+ +--+ +-+ +-----+ +-----+ +-+ ++-+ ++-+ +-++ | | | | | | | | ++-+ ++-+ +-++ +-+ +-----+ +-----+ +-+ +--+ +--+ +--+ Figure 7b: The grey topology type B with abstract nodes/links between border nodes - 6.3.1. Grey topology type A: border nodes with a TE links - between them in a full mesh fashion - - For each pair of ingress and egress nodes (i.e., border nodes - to/from the domain), TE link metric is provided with TE attributes - such as max bandwidth available, link delay, etc. This abstraction - depends on the underlying TE networks. - Note that this grey topology can also be represented as a single - abstract node with the connectivity matrix defined in [TE-Topology], - abstracting the internal connectivity information. The only thing - might be different is some additional information about the end - points of the links of the border nodes (i.e., links outward - customer-facing) as they cannot be included in the connectivity - matrix's termination points. - - 6.3.2. Grey topology Type B - The grey abstraction type B would allow the MDSC to have more information about the internals of the domain networks by the PNCs so that the MDSC can flexibly determine optimal paths. The MDSC may configure some of the internal virtual nodes (e.g., cross-connect) to redirect its traffic as it sees changes from the domain networks. -6.4. Topology Abstraction Granularity Level example +6.3. Building Methods of Grey Topology + + This section discusses two different methods of building a grey + topology: + + . Automatic generation of abstract topology by configuration + (Section 6.3.1) + . On-demand generation of supplementary topology via path + computation request/reply (Section 6.3.2) + +6.3.1. Automatic generation of abstract topology by configuration + + The "Automatic generation" method is based on the + abstraction/summarization of the whole domain by the PNC and its + advertisement on MPI interface once the abstraction level is + configured. The level of abstraction advertisement can be decided + based on some PNC configuration parameters (e.g. provide the + potential connectivity between any PE and any ASBR in an MPLS-TE + network. + + Note that the configuration parameters for this potential topology + can include available B/W, latency, or any combination of defined + parameters. How to generate such tunnel information is beyond the + scope of this document. + + Such potential topology needs to be periodically or + incrementally/asynchronously updated every time that a failure, a + recovery or the setup of new VNs causes a change in the + characteristics of the advertised grey topology (e.g. in our + previous case if due to changes in the network is it now possible to + provide connectivity between a given PE and a given ASBR with a + higher delay in the update). + +6.3.2. On-demand generation of supplementary topology via path compute + request/reply + + The "on-demand generation" of supplementary topology is to be + distinguished from automatic generation of abstract topology. While + abstract topology is generated and updated automatically by + configuration as explained in Section 6.3.1, additional + supplementary topology may be obtained by the MDSC via path compute + request/reply mechanism. Starting with a black topology + advertisement from the PNCs, the MDSC may need additional + information beyond the level of black topology from the PNCs. + + It is assumed that the black topology advertisement from PNCs would + give the MDSC each domain's the border node/link information. Under + this scenario, when the MDSC needs to allocate a new VN, the MDSC + can issue a number of Path Computation requests as described in + [ACTN-YANG] to different PNCs with constraints matching the VN + request. An example is provided in Figure 4, where the MDSC is + requesting to setup a P2P VN between AP1 and AP2. The MDSC can use + two different inter-domain links to get from Domain X to Domain Y, + namely the one between ASBRX.1 and ASBRY.1 and the one between + ASBRX.2 and ASBRY.2, but in order to choose the best end to end path + it needs to know what domain X and Y can offer in term of + connectivity and constraints between the PE nodes and the ASBR + nodes. + + ------- ------- + ( ) ( ) + - ASBRX.1------- ASBRY.1 - + (+---+ ) ( +---+) + -+---( |PE1| Dom.X ) ( Dom.Y |PE2| )---+- + | (+---+ ) ( +---+) | + AP1 - ASBRX.2------- ASBRY.2 - AP2 + ( ) ( ) + ------- ------- + + Figure 4: A multi-domain networks example + + A path computation request will be issued to PNC.X asking for + potential connectivity between PE1 and ASBRX.1 and between PE1 and + ASBRX.2 with related objective functions and TE metric constraints. + A similar request will be issued to PNC.Y and the results merged + together at the MDSC to be able to compute the optimal end-to-end + path including the inter domain links. + + The info related to the potential connectivity may be cached by the + MDSC for subsequent path computation processes or discarded, but in + this case the PNCs are not requested to keep the grey topology + updated. + +6.4. Abstraction Configuration Consideration + + This section provides a set of abstraction configuration + considerations. + + It is expected that the abstraction level be configured between the + CNC and the MDSC (i.e., the CMI) depending on the capability of the + CNC. This negotiated level of abstraction on the CMI may also impact + the way the MDSC and the PNCs configure and encode the abstracted + topology. For example, if the CNC is capable of sophisticated + technology specific operation, then this would impact the level of + abstraction at the MDSC with the PNCs. On the other hand, if the CNC + asks for a generic topology abstraction, then the level of + abstraction at the MDSC with the PNCs can be less technology + specific than the former case. + + The subsequent sections provide a list of possible abstraction + levels for various technology domain networks. + +6.4.1. Packet Networks + + - For grey abstraction, the type of abstraction and its parameters + can be defined and configured. + o Abstraction Level 1: TE-tunnel abstraction for all (S-D) + border pairs with: + . Maximum B/W available per Priority Level + . Minimum Latency + +6.4.2. OTN Networks + + For OTN networks, max bandwidth available may be per ODU 0/1/2/3 + switching level or aggregated across all ODU switching levels (i.e., + ODUj/k). Clearly, there is a trade-off between these two abstraction + methods. Some OTN switches can switch any level of ODUs and in such + case there is no need for ODU level abstraction. + + - For grey abstraction, the type of abstraction and its parameters + can be defined and configured. + + o Abstraction Level 1: Per ODU Switching level (i.e., ODU type + and number) TE-tunnel abstraction for all (S-D) border pairs + with: + . Maximum B/W available per Priority Level + . Minimum Latency + + o Abstraction Level 2: Aggregated TE-tunnel abstraction for all + (S-D) border pairs with: + . Maximum B/W available per Priority Level + . Minimum Latency + +6.4.3. WSON Networks + + For WSON networks, max bandwidth available may be per + lambda/frequency level (OCh) or aggregated across all + lambda/frequency level. Per OCh level abstraction gives more + detailed data to the MDSC at the expense of more information + processing. Either OCh-level or aggregated level abstraction should + factor in the RWA constraint (i.e., wavelength continuity) at the + PNC level. This means the PNC should have this capability and + advertise it as such. + + For grey abstraction, the type of abstraction and its parameters can + be defined and configured as follows: + + o Abstraction Level 1: Per Lambda/Frequency level TE-tunnel + abstraction for all (S-D) border pairs with: + . Maximum B/W available per Priority Level + . Minimum Latency + + o Abstraction Level 2: Aggregated TE-tunnel abstraction for all + (S-D) border pairs with: + . Maximum B/W available per Priority Level + +6.5. Topology Abstraction Granularity Level example This section illustrates how topology abstraction operates in different level of granularity over a hierarchy of MDSCs which is shown in Figure 8 below. +-----+ | CNC | CNC wants to create a VN +-----+ between CE A and CE B | | @@ -1117,24 +1341,23 @@ provides a grey topology abstraction in which to present only border nodes and links within and outside the domain. The abstract topology MDSC-L1 would operate is basically a combination of the two topologies the PNCs (PNC 1 and PNC 2) provide. Likewise, the abstract topology MDSC-L2 would operate is shown in Figure 8. Both MDSC-L1 and MDSC-L2 provide a black topology abstraction in which each PNC domain is presented as one virtual node to its top level MDSC-H. Then the MDSC-H combines these two topologies updated by MDSC-L1 and MDSC-L2 to create the abstraction topology to which it operates. MDSC-H sees the whole four domain networks as four virtual - nodes connected via virtual links. This illustrates the point - discussed in Section 5.1: The top level MDSC may operate on a higher - level of abstraction (i.e., less granular level) than the lower - level MSDCs. + nodes connected via virtual links. The top level MDSC may operate on + a higher level of abstraction (i.e., less granular level) than the + lower level MSDCs. 7. Access Points and Virtual Network Access Points In order not to share unwanted topological information between the customer domain and provider domain, a new entity is defined which is referred to as the Access Point (AP). See the definition of AP in Section 1.1. A customer node will use APs as the end points for the request of VNS as shown in Figure 9. @@ -1424,21 +1647,21 @@ and survivability. Furthermore, application access and type of virtual network service requested by the CNC, will be need adhere to specific access control policies. 10.3. Policy applied to the Multi Domain Service Coordinator A key objective of the MDSC is to help the customer express the application connectivity request via its CNC as set of desired business needs, therefore policy will play an important role. - Once authorised, the virtual network service will be instantiated + Once authorized, the virtual network service will be instantiated via the CNC-MDSC Interface (CMI), it will reflect the customer application and connectivity requirements, and specific service transport needs. The CNC and the MDSC components will have agreed connectivity end-points, use of these end-points should be defined as a policy expression when setting up or augmenting virtual network services. Ensuring that permissible end-points are defined for CNCs and applications will require the MDSC to maintain a registry of permissible connection points for CNCs and application types. It may also be necessary for the MDSC to resolve policy conflicts,